From jkeating at redhat.com Wed Aug 1 00:27:40 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 31 Jul 2007 20:27:40 -0400 Subject: When are kernels removed from the download repository? (was Re: Policy for retiring packages?) In-Reply-To: <20070731232706.GA22441@puariko.nirvana> References: <20070704125900.GA25570@puariko.nirvana> <20070704164122.GB600@puariko.nirvana> <1183569153.3628.27.camel@localhost.localdomain> <200707042216.37679.jkeating@redhat.com> <20070731232706.GA22441@puariko.nirvana> Message-ID: <20070731202740.4c3609ec@ender> On Wed, 1 Aug 2007 01:27:06 +0200 Axel Thimm wrote: > This seems to not hold true for the kernel packages, currently both 33 > and 41 are in updates-released. > > (not that I mind, but I wanted to understand the retiring policy to be > able to react better with kernel supproting packages, aka kmdls) Erm, the only way this can happen is if you're looking at a half updated mirror. The canonical source for this in the Fedora colo in Phoenix has... $ ls /mnt/koji/mash/updates/f7-updates/i386/kernel-* |grep 33 [jkeating at koji scripts]$ -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lmacken at redhat.com Wed Aug 1 00:29:52 2007 From: lmacken at redhat.com (Luke Macken) Date: Tue, 31 Jul 2007 20:29:52 -0400 Subject: delete old pending updates from Bodhi In-Reply-To: <1185912715.9716.4.camel@eagle.danny.cz> References: <1185912715.9716.4.camel@eagle.danny.cz> Message-ID: <20070801002952.GF13879@tomservo> On Tue, Jul 31, 2007 at 10:11:55PM +0200, Dan Hor?k wrote: > Hello, > > please, can someone delete old pending updates from Bodhi? There are > many packages that were replaced with a newer version even before > getting into updates-testing. The oldest one is from June 1st. If no one else gets to it before me, I'll throw together some periodic cleanup and nagmail scripts into bodhi. I won't be able to tackle this for at least a week though. luke From Axel.Thimm at ATrpms.net Wed Aug 1 06:11:28 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 1 Aug 2007 08:11:28 +0200 Subject: When are kernels removed from the download repository? (was Re: Policy for retiring packages?) In-Reply-To: <20070731202740.4c3609ec@ender> References: <20070704125900.GA25570@puariko.nirvana> <20070704164122.GB600@puariko.nirvana> <1183569153.3628.27.camel@localhost.localdomain> <200707042216.37679.jkeating@redhat.com> <20070731232706.GA22441@puariko.nirvana> <20070731202740.4c3609ec@ender> Message-ID: <20070801061128.GE22441@puariko.nirvana> On Tue, Jul 31, 2007 at 08:27:40PM -0400, Jesse Keating wrote: > On Wed, 1 Aug 2007 01:27:06 +0200 > Axel Thimm wrote: > > > This seems to not hold true for the kernel packages, currently both 33 > > and 41 are in updates-released. > > > > (not that I mind, but I wanted to understand the retiring policy to be > > able to react better with kernel supproting packages, aka kmdls) > > Erm, the only way this can happen is if you're looking at a half > updated mirror. The canonical source for this in the Fedora colo in > Phoenix has... > > $ ls /mnt/koji/mash/updates/f7-updates/i386/kernel-* |grep 33 > [jkeating at koji scripts]$ What about http://download.fedora.redhat.com/pub/fedora/linux/updates/7/SRPMS/ When I wrote the above post it contained both kernels. Can that be a "half updated mirror"? If so this should be fixed to present changes atomically and also authitative, e.g. update download.fedora.redhat.com first ion the scripts then push to the rsync hosts. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Wed Aug 1 08:43:18 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 1 Aug 2007 10:43:18 +0200 Subject: Error: Missing Dependency: group(ctapiusers) is needed by package ctapi-cyberjack Message-ID: <20070801084318.GA26205@puariko.nirvana> Wasn't updates-released supposed to be protected against missing dependencies? Failing that can we make the skip-broken-dependencies plugin turned on by default? All automated updating is breaking on such dependency issues. -- 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 Aug 1 09:08:14 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 1 Aug 2007 11:08:14 +0200 Subject: Error: Missing Dependency: group(ctapiusers) is needed by package ctapi-cyberjack In-Reply-To: <20070801084318.GA26205@puariko.nirvana> References: <20070801084318.GA26205@puariko.nirvana> Message-ID: <20070801110814.637f71a2.bugs.michael@gmx.net> On Wed, 1 Aug 2007 10:43:18 +0200, Axel Thimm wrote: > Wasn't updates-released supposed to be protected against missing > dependencies? It isn't. At least, it's not implemented yet afaik. Extras repoclosure has caught that broken dep for FE6, however. Owner has got the report. Very seldomly an owner mails back and asks about how to proceed. From gilboad at gmail.com Wed Aug 1 12:19:41 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Wed, 01 Aug 2007 15:19:41 +0300 Subject: Bodhi doesn't recognize new builds Message-ID: <1185970781.14536.39.camel@gilboa-work-dev.localdomain> Hello all, Weird problem. A couple of days ago I send out the first approved build of kdebluetooth (B29). Once it was built (by koji) I opened a bodhi ticket about it. Two days later I had to change the ExcludeArch line (missing obexftp in ppc) so I issued a new build. (B31). However, once I went to bodhi to create a new ticket, I couldn't find the new build (B31) - only the previous one (B29, still pending) was present. Fearing a mistake on my side, I reissued the koji build command, but got a "FAILED: GenericError: Build already exists" error. So, what am I doing wrong? - Gilboa From gilboad at gmail.com Wed Aug 1 12:23:38 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Wed, 01 Aug 2007 15:23:38 +0300 Subject: Bodhi doesn't recognize new builds In-Reply-To: <1185970781.14536.39.camel@gilboa-work-dev.localdomain> References: <1185970781.14536.39.camel@gilboa-work-dev.localdomain> Message-ID: <1185971018.14536.41.camel@gilboa-work-dev.localdomain> On Wed, 2007-08-01 at 15:19 +0300, Gilboa Davara wrote: > Hello all, > > Weird problem. > A couple of days ago I send out the first approved build of kdebluetooth > (B29). > Once it was built (by koji) I opened a bodhi ticket about it. > Two days later I had to change the ExcludeArch line (missing obexftp in > ppc) so I issued a new build. (B31). > However, once I went to bodhi to create a new ticket, I couldn't find > the new build (B31) - only the previous one (B29, still pending) was > present. > Fearing a mistake on my side, I reissued the koji build command, but got > a "FAILED: GenericError: Build already exists" error. > > So, what am I doing wrong? > > - Gilboa Strike that. I removed the pending update and the new one appeared. - Gilboa From jkeating at redhat.com Wed Aug 1 13:35:01 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 1 Aug 2007 09:35:01 -0400 Subject: When are kernels removed from the download repository? (was Re: Policy for retiring packages?) In-Reply-To: <20070801061128.GE22441@puariko.nirvana> References: <20070704125900.GA25570@puariko.nirvana> <20070704164122.GB600@puariko.nirvana> <1183569153.3628.27.camel@localhost.localdomain> <200707042216.37679.jkeating@redhat.com> <20070731232706.GA22441@puariko.nirvana> <20070731202740.4c3609ec@ender> <20070801061128.GE22441@puariko.nirvana> Message-ID: <20070801093501.0ee9f9a0@localhost.localdomain> On Wed, 1 Aug 2007 08:11:28 +0200 Axel Thimm wrote: > When I wrote the above post it contained both kernels. Can that be a > "half updated mirror"? If so this should be fixed to present changes > atomically and also authitative, e.g. update > download.fedora.redhat.com first ion the scripts then push to the > rsync hosts. d.f.r.c /is/ the rsync host. Content gets rsynced to a netapp store in Raleigh, NC. netapp is constantly 'snapmirror' to mirror that content out to public facing netapps which are both d.f.r.c and also the rsync points for the rest of the mirroring system. So it is somewhat possible to catch a public mirror in a half updated state. The only workable ways around this are to limit all changes to the content to once or twice a day and have strict sync times to ensure that the data is fully set. That means no more rushed updates, no more "instant" appearance of extras pushes, etc.... -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Wed Aug 1 13:43:21 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 1 Aug 2007 15:43:21 +0200 Subject: When are kernels removed from the download repository? (was Re: Policy for retiring packages?) In-Reply-To: <20070801093501.0ee9f9a0@localhost.localdomain> References: <20070704125900.GA25570@puariko.nirvana> <20070704164122.GB600@puariko.nirvana> <1183569153.3628.27.camel@localhost.localdomain> <200707042216.37679.jkeating@redhat.com> <20070731232706.GA22441@puariko.nirvana> <20070731202740.4c3609ec@ender> <20070801061128.GE22441@puariko.nirvana> <20070801093501.0ee9f9a0@localhost.localdomain> Message-ID: <20070801134321.GA28709@puariko.nirvana> On Wed, Aug 01, 2007 at 09:35:01AM -0400, Jesse Keating wrote: > On Wed, 1 Aug 2007 08:11:28 +0200 > Axel Thimm wrote: > > > When I wrote the above post it contained both kernels. Can that be a > > "half updated mirror"? If so this should be fixed to present changes > > atomically and also authitative, e.g. update > > download.fedora.redhat.com first ion the scripts then push to the > > rsync hosts. > > d.f.r.c /is/ the rsync host. Content gets rsynced to a netapp store in > Raleigh, NC. netapp is constantly 'snapmirror' to mirror that content > out to public facing netapps which are both d.f.r.c and also the rsync > points for the rest of the mirroring system. So it is somewhat > possible to catch a public mirror in a half updated state. Yes, but it was download.fedora.redhat.com itself that had both kernels, that doesn't match quite with what you write. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Wed Aug 1 13:45:17 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 1 Aug 2007 09:45:17 -0400 Subject: When are kernels removed from the download repository? (was Re: Policy for retiring packages?) In-Reply-To: <20070801134321.GA28709@puariko.nirvana> References: <20070704125900.GA25570@puariko.nirvana> <20070704164122.GB600@puariko.nirvana> <1183569153.3628.27.camel@localhost.localdomain> <200707042216.37679.jkeating@redhat.com> <20070731232706.GA22441@puariko.nirvana> <20070731202740.4c3609ec@ender> <20070801061128.GE22441@puariko.nirvana> <20070801093501.0ee9f9a0@localhost.localdomain> <20070801134321.GA28709@puariko.nirvana> Message-ID: <20070801094517.2935880c@localhost.localdomain> On Wed, 1 Aug 2007 15:43:21 +0200 Axel Thimm wrote: > Yes, but it was download.fedora.redhat.com itself that had both > kernels, that doesn't match quite with what you write. Given that we can only write to one point of the netapp, and snapmirror is continuously running to sync up other points of the netapp set, this is the problem set. What I'm saying is that we updated the source for these first, there is no possible way to update d.f.r.c first, and then the rsync points. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tibbs at math.uh.edu Wed Aug 1 16:33:16 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 01 Aug 2007 11:33:16 -0500 Subject: Summary of the 2007-07-31 Packaging Committee meeting Message-ID: Meeting minutes and full logs of the packaging committee meeting which occurred on 2007-07-31 are online: http://fedoraproject.org/wiki/Packaging/Minutes http://fedoraproject.org/wiki/Packaging/Minutes20070731 Issues pending FESCO ratification: The license tag refinements requested by the board: * http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag * Accepted (7 - 1) * Voting for: rdieter f13 tibbs lutter abadger1999 spot scop * Voting against: racor (on-list) * Dynamic user and group creation policy: * http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups * Accepted (6 - 0) * Voting for: spot lutter scop abadger1999 tibbs rdieter * Abstaining: f13 The following additional items were discussed; see the logs for full details: * OnlyShowIn in desktop files - J< From Axel.Thimm at ATrpms.net Wed Aug 1 18:03:42 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 1 Aug 2007 20:03:42 +0200 Subject: Summary of the 2007-07-31 Packaging Committee meeting In-Reply-To: References: Message-ID: <20070801180342.GB15928@puariko.nirvana> On Wed, Aug 01, 2007 at 11:33:16AM -0500, Jason L Tibbitts III wrote: > * Dynamic user and group creation policy: > * http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups Hurray! Too bad I missed this meeting! Going to celebrate now on my own ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Wed Aug 1 18:40:19 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 1 Aug 2007 10:40:19 -0800 Subject: Summary of the 2007-07-31 Packaging Committee meeting In-Reply-To: <20070801180342.GB15928@puariko.nirvana> References: <20070801180342.GB15928@puariko.nirvana> Message-ID: <604aa7910708011140n6973ba87gbdf9aae6e4a868f3@mail.gmail.com> On 8/1/07, Axel Thimm wrote: > On Wed, Aug 01, 2007 at 11:33:16AM -0500, Jason L Tibbitts III wrote: > > * Dynamic user and group creation policy: > > * http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups > > Hurray! Too bad I missed this meeting! Going to celebrate now on my > own ;) Hmm... let's see if I can find the time this weekend to get my safekeep package still pending review updated to use this new policy. -jef From jsafranek at redhat.com Thu Aug 2 10:35:55 2007 From: jsafranek at redhat.com (Jan Safranek) Date: Thu, 02 Aug 2007 12:35:55 +0200 Subject: Koji cannot build openldap Message-ID: <46B1B38B.50407@redhat.com> Two days ago I have successfully compiled openldap-2.3.37-1.fc8, see http://koji.fedoraproject.org/koji/taskinfo?taskID=83328 Today I cannot compile any openldap package, even the .src.rpm, which was compilable two days ago - I downloaded it from koji and executed "koji build --scratch dist-f8 openldap-2.3.37-1.fc8.src.rpm" with following result (see http://koji.fedoraproject.org/koji/taskinfo?taskID=85652 ): cc -c -I. -I../dist/.. -D_GNU_SOURCE -D_REENTRANT -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_REENTRANT -fPIC ../dist/../dbm/dbm.c -fPIC -DPIC -o .libs/dbm.o ../dist/../dbm/dbm.c: In function '__db_ndbm_open_openldap_slapd_rhl_42': ../dist/../dbm/dbm.c:241: error: expected identifier before '(' token There is nothing suspicious in the dbm.c, it was compilable for several years without any problem. My (virtualized) rawhide updated today is able to compile the .src.rpm without any problem. Something has changed in the buildroot so koji cannot compile my package anymore. Was here any change I should be aware of? Or how can I make my openldap to compile again? Thanks in advance Jan From jakub at redhat.com Thu Aug 2 11:55:09 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 2 Aug 2007 07:55:09 -0400 Subject: Koji cannot build openldap In-Reply-To: <46B1B38B.50407@redhat.com> References: <46B1B38B.50407@redhat.com> Message-ID: <20070802115509.GQ2063@devserv.devel.redhat.com> On Thu, Aug 02, 2007 at 12:35:55PM +0200, Jan Safranek wrote: > Two days ago I have successfully compiled openldap-2.3.37-1.fc8, see > http://koji.fedoraproject.org/koji/taskinfo?taskID=83328 > > Today I cannot compile any openldap package, even the .src.rpm, which > was compilable two days ago - I downloaded it from koji and executed > "koji build --scratch dist-f8 openldap-2.3.37-1.fc8.src.rpm" with > following result (see > http://koji.fedoraproject.org/koji/taskinfo?taskID=85652 ): > cc -c -I. -I../dist/.. -D_GNU_SOURCE -D_REENTRANT -O2 -g -pipe -Wall > -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > --param=ssp-buffer-size=4 -m64 -mtune=generic -D_REENTRANT -fPIC > ../dist/../dbm/dbm.c -fPIC -DPIC -o .libs/dbm.o > ../dist/../dbm/dbm.c: In function '__db_ndbm_open_openldap_slapd_rhl_42': > ../dist/../dbm/dbm.c:241: error: expected identifier before '(' token > > There is nothing suspicious in the dbm.c, it was compilable for several > years without any problem. My (virtualized) rawhide updated today is > able to compile the .src.rpm without any problem. > > Something has changed in the buildroot so koji cannot compile my package > anymore. Was here any change I should be aware of? Or how can I make > my openldap to compile again? dbm.c is buggy. It includes , which provides open, and POSIX allows functions to be defined as function-like macros. Until recently glibc didn't define open as a function like macro, but in glibc 2.6.90 and later it does when -D_FORTIFY_SOURCE=2, to enforce correct use of open/open64/openat/openat64. But dbm.c uses dbm->open (x, y, z, a);, which works when open is not defined as a function-like macro, but of course can break badly if it is defined as a function-like macro. The fix is use () to avoid it being expanded as function-like macro: (dbm->open) (x, y, z, a); Jakub From qspencer at ieee.org Thu Aug 2 15:48:50 2007 From: qspencer at ieee.org (Quentin Spencer) Date: Thu, 02 Aug 2007 10:48:50 -0500 Subject: Splitting a package--reviews needed? Message-ID: <46B1FCE2.7030604@ieee.org> I am the maintainer of octave-forge, a set of add-on packages for octave. The structure of the source package has been changed to separate it into a number of sub-packages. I think it would be a good idea to follow this structure in the Fedora package, particularly since some sub-packages have external dependencies that not all users may really need. The octave-forge package would become a meta-package that just installs all of the sub-packages. The question here is, should each of the new sub-packages be subject to its own review? It's a total of almost 40 packages, considerably more than I currently maintain, and I'm worried that this will significantly increase the time commitment, which I'm not sure I can do. Is there anyone out there who has a particular interest in any of the octave-forge sub-packages who may be interested in maintaining it? Quentin From silfreed at silfreed.net Thu Aug 2 18:29:57 2007 From: silfreed at silfreed.net (Douglas E. Warner) Date: Thu, 2 Aug 2007 14:29:57 -0400 Subject: Licensing guidelines changes In-Reply-To: <1186077406.9748.166.camel@localhost.localdomain> References: <1186077406.9748.166.camel@localhost.localdomain> Message-ID: <200708021429.57697.silfreed@silfreed.net> On Thursday 02 August 2007, Tom "spot" Callaway wrote: > Q. I have a question that you've not covered here, what should I do? > A. Ask it. I'll try to answer it. :) Should we still email the maintainers list when we change these licenses from things like "GPL" to "GPLv2"? -Doug -------------- 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 Thu Aug 2 18:33:51 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 2 Aug 2007 14:33:51 -0400 Subject: Licensing guidelines changes In-Reply-To: <200708021429.57697.silfreed@silfreed.net> References: <1186077406.9748.166.camel@localhost.localdomain> <200708021429.57697.silfreed@silfreed.net> Message-ID: <20070802143351.2d1bb83a@localhost.localdomain> On Thu, 2 Aug 2007 14:29:57 -0400 "Douglas E. Warner" wrote: > Should we still email the maintainers list when we change these > licenses from things like "GPL" to "GPLv2"? If you're clarifying the license tag in your spec but the software itself isn't changing licenses, I don't think that's necessary. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Thu Aug 2 18:35:29 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 02 Aug 2007 14:35:29 -0400 Subject: Licensing guidelines changes In-Reply-To: <200708021429.57697.silfreed@silfreed.net> References: <1186077406.9748.166.camel@localhost.localdomain> <200708021429.57697.silfreed@silfreed.net> Message-ID: <1186079729.9748.168.camel@localhost.localdomain> On Thu, 2007-08-02 at 14:29 -0400, Douglas E. Warner wrote: > On Thursday 02 August 2007, Tom "spot" Callaway wrote: > > Q. I have a question that you've not covered here, what should I do? > > A. Ask it. I'll try to answer it. :) > > Should we still email the maintainers list when we change these licenses from > things like "GPL" to "GPLv2"? No, thats just a clarification. You only need to send out notification when your code actually changes license. ~spot From jspaleta at gmail.com Thu Aug 2 18:42:12 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 2 Aug 2007 10:42:12 -0800 Subject: Licensing guidelines changes In-Reply-To: <20070802143351.2d1bb83a@localhost.localdomain> References: <1186077406.9748.166.camel@localhost.localdomain> <200708021429.57697.silfreed@silfreed.net> <20070802143351.2d1bb83a@localhost.localdomain> Message-ID: <604aa7910708021142r12d5040aid22e0a90c2f9069c@mail.gmail.com> On 8/2/07, Jesse Keating wrote: > If you're clarifying the license tag in your spec but the software > itself isn't changing licenses, I don't think that's necessary. I would concur. It's vitally important to do our best to communicate to the other maintainers if the licensing is actually changing. Communicating licensing changes as widely as possible is "shout it from the rooftops" important. The re-tagging of existing packages for clarification is an orthogonal development which will help us moving forward with internal efforts to identify and address licensing issues. Important...but not "shout it from the rooftops" important. From dcantrell at redhat.com Thu Aug 2 19:52:56 2007 From: dcantrell at redhat.com (David Cantrell) Date: Thu, 2 Aug 2007 15:52:56 -0400 Subject: dhcpv6 license correction Message-ID: <20070802155256.cbfcf820.dcantrell@redhat.com> The dhcpv6 package has incorrectly identified its license for quite some time. The spec file noted the license was GPL. The license is actually BSD, so the spec file has been updated and the package in devel has been rebuilt. The BSD license covers the following packages related to dhcpv6: dhcpv6 dhcpv6-client libdhcp6client libdhcp6client-devel libdhcp6client-static -- David Cantrell Red Hat / Westford, MA -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jsafranek at redhat.com Fri Aug 3 06:45:53 2007 From: jsafranek at redhat.com (Jan Safranek) Date: Fri, 03 Aug 2007 08:45:53 +0200 Subject: Koji cannot build openldap In-Reply-To: <20070802115509.GQ2063@devserv.devel.redhat.com> References: <46B1B38B.50407@redhat.com> <20070802115509.GQ2063@devserv.devel.redhat.com> Message-ID: <46B2CF21.80107@redhat.com> Jakub Jelinek wrote: > dbm.c is buggy. It includes , which provides open, and POSIX > allows functions to be defined as function-like macros. > Until recently glibc didn't define open as a function like macro, but > in glibc 2.6.90 and later it does when -D_FORTIFY_SOURCE=2, to enforce > correct use of open/open64/openat/openat64. > But dbm.c uses dbm->open (x, y, z, a);, which works when open is > not defined as a function-like macro, but of course can break badly > if it is defined as a function-like macro. > The fix is use () to avoid it being expanded as function-like macro: > (dbm->open) (x, y, z, a); Maybe POSIX does allow such behavior, but it will break lot of packages - for example all packages who use Berkeley DB (which is my case). I Patching the DB would result in >500 changed lines and I am bit skeptical about upstream accepting such patch - it would break API compatibility. Is here any way how to tell compiler/glibc not to define open() as macro and still have -D_FORTIFY_SOURCE=2? Jan From tgl at redhat.com Fri Aug 3 07:49:56 2007 From: tgl at redhat.com (Tom Lane) Date: Fri, 03 Aug 2007 03:49:56 -0400 Subject: Koji cannot build openldap In-Reply-To: <46B2CF21.80107@redhat.com> References: <46B1B38B.50407@redhat.com> <20070802115509.GQ2063@devserv.devel.redhat.com> <46B2CF21.80107@redhat.com> Message-ID: <5269.1186127396@sss.pgh.pa.us> Jan Safranek writes: > Jakub Jelinek wrote: >> dbm.c is buggy. It includes , which provides open, and POSIX >> allows functions to be defined as function-like macros. > Maybe POSIX does allow such behavior, but it will break lot of packages > - for example all packages who use Berkeley DB (which is my case). I I wasted several unexpected hours tonight patching mysql for this, and I am now afraid to recompile any of my other packages :-(. This sort of hacking may be legal by a narrow reading of the specification, but that doesn't make it a good idea. This isn't the first time this kind of thing has happened, either. I propose that the gcc/glibc boys be responsible for fixing packages that break when they whack around system headers --- that would perhaps make them weigh the consequences of their actions a bit more carefully. Right now, they appear to put zero weight on the effort that must be expended by other people in response to their changes. > Patching the DB would result in >500 changed lines and I am bit > skeptical about upstream accepting such patch That's not going to happen for me, either, which means that this "improvement" will represent a permanent maintenance headache and incompatibility with the rest of the world. regards, tom lane From jakub at redhat.com Fri Aug 3 08:00:44 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Fri, 3 Aug 2007 04:00:44 -0400 Subject: Koji cannot build openldap In-Reply-To: <5269.1186127396@sss.pgh.pa.us> References: <46B1B38B.50407@redhat.com> <20070802115509.GQ2063@devserv.devel.redhat.com> <46B2CF21.80107@redhat.com> <5269.1186127396@sss.pgh.pa.us> Message-ID: <20070803080044.GV2063@devserv.devel.redhat.com> On Fri, Aug 03, 2007 at 03:49:56AM -0400, Tom Lane wrote: > I wasted several unexpected hours tonight patching mysql for this, and > I am now afraid to recompile any of my other packages :-(. This sort of > hacking may be legal by a narrow reading of the specification, but that > doesn't make it a good idea. It is certainly a good idea, just eyeball fedora-devel-list from yesterday and you'll see it already discovered one real bug (in kst), for approx. 2 days in the build system. We haven't done any mass rebuild, I guess such a common mistake (not passing 3 arguments to open when O_CREAT is used) is present in dozens if not hundreds places all around the distribution. Being able to define standard system functions as function-like macro is something glibc and other C libraries are using for years for various functions and packages have always been able to cope with it. Just open has not been among them so far. > > Patching the DB would result in >500 changed lines and I am bit > > skeptical about upstream accepting such patch > > That's not going to happen for me, either, which means that this > "improvement" will represent a permanent maintenance headache and > incompatibility with the rest of the world. This change is not Fedora specific, it is a change made in upstream glibc. So if upstream mysql doesn't want to bother, it will simply not build on Linux since various other distros start using new glibc release (which will be released approx. in the fall). Jakub From jakub at redhat.com Fri Aug 3 08:22:52 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Fri, 3 Aug 2007 04:22:52 -0400 Subject: Koji cannot build openldap In-Reply-To: <46B2CF21.80107@redhat.com> References: <46B1B38B.50407@redhat.com> <20070802115509.GQ2063@devserv.devel.redhat.com> <46B2CF21.80107@redhat.com> Message-ID: <20070803082252.GX2063@devserv.devel.redhat.com> On Fri, Aug 03, 2007 at 08:45:53AM +0200, Jan Safranek wrote: > Maybe POSIX does allow such behavior, but it will break lot of packages > - for example all packages who use Berkeley DB (which is my case). I > > Patching the DB would result in >500 changed lines and I am bit > skeptical about upstream accepting such patch - it would break API > compatibility. Excuse me, but how does adding a parenthesis pair affect API compatibility? If you write (dbm->open) (one, two, three, four); then it is the right way to avoid open (or replace open with any kind of standard function defined in the system headers) from being expanded as function-like macro. > Is here any way how to tell compiler/glibc not to define > open() as macro and still have -D_FORTIFY_SOURCE=2? You can #undef open after including the standard headers, and eventhough even this is standard conforming way to deal with it, you then lose all the checking in case you use a real 2 arguments open anywhere. The new macro will for open ("abc", O_CREAT | O_RDWR); issue a compile error, for open ("abc", O_RDWR); it will just call the normal open with two arguments, for open ("abc", flags, 0644) normal open with 3 arguments, but for open ("abc", flags); where it can't find out at compile time whether flags contains O_CREAT or not will arrange a special checking open alternate entry point to be called, which will check that flags doesn't contain O_CREAT at runtime. When you use parenthesis, you get both standard conforming code and the open argument checking for when it is a real call. Jakub From jsafranek at redhat.com Fri Aug 3 08:53:34 2007 From: jsafranek at redhat.com (Jan Safranek) Date: Fri, 03 Aug 2007 10:53:34 +0200 Subject: Koji cannot build openldap In-Reply-To: <20070803082252.GX2063@devserv.devel.redhat.com> References: <46B1B38B.50407@redhat.com> <20070802115509.GQ2063@devserv.devel.redhat.com> <46B2CF21.80107@redhat.com> <20070803082252.GX2063@devserv.devel.redhat.com> Message-ID: <46B2ED0E.7050700@redhat.com> Jakub Jelinek wrote: > On Fri, Aug 03, 2007 at 08:45:53AM +0200, Jan Safranek wrote: >> Maybe POSIX does allow such behavior, but it will break lot of packages >> - for example all packages who use Berkeley DB (which is my case). I >> >> Patching the DB would result in >500 changed lines and I am bit >> skeptical about upstream accepting such patch - it would break API >> compatibility. > > Excuse me, but how does adding a parenthesis pair affect API compatibility? > If you write (dbm->open) (one, two, three, four); then it is the right > way to avoid open (or replace open with any kind of standard function > defined in the system headers) from being expanded as function-like macro. That's it, you have to write (dbm->open) (...). You have to modify the sources of all applications using Berkeley DB, even if the structure member name is the same as before. In my interpretation of the word it is incompatibility (while yours may be different and I respect that). Jan From jonathan.underwood at gmail.com Fri Aug 3 10:48:34 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 3 Aug 2007 11:48:34 +0100 Subject: Possible problem with licensing of liberation-fonts Message-ID: <645d17210708030348t3167f8b0j246a8977352a7b1d@mail.gmail.com> Hi, I can't find any discussion of this in the archives, so apologies if this has come up before, but there seems to be a bit of a problem regarding the GPL+restrictions nature of the liberation fonts we have packaged for Fedora. See the Debian discussion here: http://www.mail-archive.com/debian-legal at lists.debian.org/msg36584.html These arguments would seem to apply equally well to inclusion/exclusion of liberation fonts in Fedora as well. Thoughts? Jonathan. From laxathom at fedoraproject.org Fri Aug 3 12:41:06 2007 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Fri, 3 Aug 2007 08:41:06 -0400 Subject: Koji question Message-ID: <62bc09df0708030541t1e78eb0fndecd3e6daa54812d@mail.gmail.com> Hello folks, Is there a way to build a package against another one which has been pushed to "dist-fc7-updates-testing" with koji ? Regards, -- Xavier.t Lamien -- French Fedora Ambassador Fedora/EPEL Contributor | http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcallawa at redhat.com Fri Aug 3 12:41:54 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 03 Aug 2007 08:41:54 -0400 Subject: Possible problem with licensing of liberation-fonts In-Reply-To: <645d17210708030348t3167f8b0j246a8977352a7b1d@mail.gmail.com> References: <645d17210708030348t3167f8b0j246a8977352a7b1d@mail.gmail.com> Message-ID: <1186144914.9748.231.camel@localhost.localdomain> On Fri, 2007-08-03 at 11:48 +0100, Jonathan Underwood wrote: > Hi, > > I can't find any discussion of this in the archives, so apologies if > this has come up before, but there seems to be a bit of a problem > regarding the GPL+restrictions nature of the liberation fonts we have > packaged for Fedora. See the Debian discussion here: > > http://www.mail-archive.com/debian-legal at lists.debian.org/msg36584.html > > These arguments would seem to apply equally well to > inclusion/exclusion of liberation fonts in Fedora as well. Thoughts? Talking to the FSF, to see what they think. ~spot From mtasaka at ioa.s.u-tokyo.ac.jp Fri Aug 3 12:51:05 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Fri, 03 Aug 2007 21:51:05 +0900 Subject: Koji question In-Reply-To: <62bc09df0708030541t1e78eb0fndecd3e6daa54812d@mail.gmail.com> References: <62bc09df0708030541t1e78eb0fndecd3e6daa54812d@mail.gmail.com> Message-ID: <46B324B9.6020209@ioa.s.u-tokyo.ac.jp> Xavier Lamien wrote, at 08/03/2007 09:41 PM +9:00: > Hello folks, > > Is there a way to build a package against another one which has been > pushed to "dist-fc7-updates-testing" with koji ? > > Regards, Ask rel-eng at fedoraproject.org to add the needed not-yet-published rpms to build tree. (Well are there any wiki which mentions about this situation?) Mamoru From jonathan.underwood at gmail.com Fri Aug 3 13:47:40 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 3 Aug 2007 14:47:40 +0100 Subject: Possible problem with licensing of liberation-fonts In-Reply-To: <1186144914.9748.231.camel@localhost.localdomain> References: <645d17210708030348t3167f8b0j246a8977352a7b1d@mail.gmail.com> <1186144914.9748.231.camel@localhost.localdomain> Message-ID: <645d17210708030647qc64f97bi49a31c2a53e91f4b@mail.gmail.com> On 03/08/07, Tom spot Callaway wrote: > > On Fri, 2007-08-03 at 11:48 +0100, Jonathan Underwood wrote: > > Hi, > > > > I can't find any discussion of this in the archives, so apologies if > > this has come up before, but there seems to be a bit of a problem > > regarding the GPL+restrictions nature of the liberation fonts we have > > packaged for Fedora. See the Debian discussion here: > > > > http://www.mail-archive.com/debian-legal at lists.debian.org/msg36584.html > > > > These arguments would seem to apply equally well to > > inclusion/exclusion of liberation fonts in Fedora as well. Thoughts? > > Talking to the FSF, to see what they think. OK Thanks. Actually, a related issue is that the License.txt file refers to GPL v2, and grants exceptions to that (which is the point of centention with Debian) *but* the COPYING file that is distributed with the fonts is the LGPL v2 file. That is presumably in error. J. J. > > ~spot > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From tcallawa at redhat.com Fri Aug 3 13:47:52 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 03 Aug 2007 09:47:52 -0400 Subject: Possible problem with licensing of liberation-fonts In-Reply-To: <645d17210708030647qc64f97bi49a31c2a53e91f4b@mail.gmail.com> References: <645d17210708030348t3167f8b0j246a8977352a7b1d@mail.gmail.com> <1186144914.9748.231.camel@localhost.localdomain> <645d17210708030647qc64f97bi49a31c2a53e91f4b@mail.gmail.com> Message-ID: <1186148872.9748.258.camel@localhost.localdomain> On Fri, 2007-08-03 at 14:47 +0100, Jonathan Underwood wrote: > On 03/08/07, Tom spot Callaway wrote: > > > > On Fri, 2007-08-03 at 11:48 +0100, Jonathan Underwood wrote: > > > Hi, > > > > > > I can't find any discussion of this in the archives, so apologies if > > > this has come up before, but there seems to be a bit of a problem > > > regarding the GPL+restrictions nature of the liberation fonts we have > > > packaged for Fedora. See the Debian discussion here: > > > > > > http://www.mail-archive.com/debian-legal at lists.debian.org/msg36584.html > > > > > > These arguments would seem to apply equally well to > > > inclusion/exclusion of liberation fonts in Fedora as well. Thoughts? > > > > Talking to the FSF, to see what they think. > > OK Thanks. > > Actually, a related issue is that the License.txt file refers to GPL > v2, and grants exceptions to that (which is the point of centention > with Debian) *but* the COPYING file that is distributed with the fonts > is the LGPL v2 file. That is presumably in error. Yeah. That needs to be pointed out to upstream (Red Hat legal). I'll do that. ~spot From tcallawa at redhat.com Fri Aug 3 13:50:49 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 03 Aug 2007 09:50:49 -0400 Subject: Possible problem with licensing of liberation-fonts In-Reply-To: <1186148872.9748.258.camel@localhost.localdomain> References: <645d17210708030348t3167f8b0j246a8977352a7b1d@mail.gmail.com> <1186144914.9748.231.camel@localhost.localdomain> <645d17210708030647qc64f97bi49a31c2a53e91f4b@mail.gmail.com> <1186148872.9748.258.camel@localhost.localdomain> Message-ID: <1186149049.9748.260.camel@localhost.localdomain> On Fri, 2007-08-03 at 09:47 -0400, Tom "spot" Callaway wrote: > On Fri, 2007-08-03 at 14:47 +0100, Jonathan Underwood wrote: > > On 03/08/07, Tom spot Callaway wrote: > > > > > > On Fri, 2007-08-03 at 11:48 +0100, Jonathan Underwood wrote: > > > > Hi, > > > > > > > > I can't find any discussion of this in the archives, so apologies if > > > > this has come up before, but there seems to be a bit of a problem > > > > regarding the GPL+restrictions nature of the liberation fonts we have > > > > packaged for Fedora. See the Debian discussion here: > > > > > > > > http://www.mail-archive.com/debian-legal at lists.debian.org/msg36584.html > > > > > > > > These arguments would seem to apply equally well to > > > > inclusion/exclusion of liberation fonts in Fedora as well. Thoughts? > > > > > > Talking to the FSF, to see what they think. > > > > OK Thanks. > > > > Actually, a related issue is that the License.txt file refers to GPL > > v2, and grants exceptions to that (which is the point of centention > > with Debian) *but* the COPYING file that is distributed with the fonts > > is the LGPL v2 file. That is presumably in error. I double checked, and in liberation-fonts-0.2, COPYING is the GPLv2, not the LGPLv2. ~spot From mclasen at redhat.com Fri Aug 3 13:54:23 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 03 Aug 2007 09:54:23 -0400 Subject: Possible problem with licensing of liberation-fonts In-Reply-To: <1186149049.9748.260.camel@localhost.localdomain> References: <645d17210708030348t3167f8b0j246a8977352a7b1d@mail.gmail.com> <1186144914.9748.231.camel@localhost.localdomain> <645d17210708030647qc64f97bi49a31c2a53e91f4b@mail.gmail.com> <1186148872.9748.258.camel@localhost.localdomain> <1186149049.9748.260.camel@localhost.localdomain> Message-ID: <1186149263.3194.2.camel@localhost.localdomain> On Fri, 2007-08-03 at 09:50 -0400, Tom "spot" Callaway wrote: > On Fri, 2007-08-03 at 09:47 -0400, Tom "spot" Callaway wrote: > > On Fri, 2007-08-03 at 14:47 +0100, Jonathan Underwood wrote: > > > On 03/08/07, Tom spot Callaway wrote: > > > > > > > > On Fri, 2007-08-03 at 11:48 +0100, Jonathan Underwood wrote: > > > > > Hi, > > > > > > > > > > I can't find any discussion of this in the archives, so apologies if > > > > > this has come up before, but there seems to be a bit of a problem > > > > > regarding the GPL+restrictions nature of the liberation fonts we have > > > > > packaged for Fedora. See the Debian discussion here: > > > > > > > > > > http://www.mail-archive.com/debian-legal at lists.debian.org/msg36584.html > > > > > > > > > > These arguments would seem to apply equally well to > > > > > inclusion/exclusion of liberation fonts in Fedora as well. Thoughts? > > > > > > > > Talking to the FSF, to see what they think. > > > > > > OK Thanks. > > > > > > Actually, a related issue is that the License.txt file refers to GPL > > > v2, and grants exceptions to that (which is the point of centention > > > with Debian) *but* the COPYING file that is distributed with the fonts > > > is the LGPL v2 file. That is presumably in error. > > I double checked, and in liberation-fonts-0.2, COPYING is the GPLv2, not > the LGPLv2. This problem was fixed some time ago. From jonathan.underwood at gmail.com Fri Aug 3 14:00:55 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 3 Aug 2007 15:00:55 +0100 Subject: Possible problem with licensing of liberation-fonts In-Reply-To: <1186149263.3194.2.camel@localhost.localdomain> References: <645d17210708030348t3167f8b0j246a8977352a7b1d@mail.gmail.com> <1186144914.9748.231.camel@localhost.localdomain> <645d17210708030647qc64f97bi49a31c2a53e91f4b@mail.gmail.com> <1186148872.9748.258.camel@localhost.localdomain> <1186149049.9748.260.camel@localhost.localdomain> <1186149263.3194.2.camel@localhost.localdomain> Message-ID: <645d17210708030700q52b9c6afged836ffd0eea6ae3@mail.gmail.com> On 03/08/07, Matthias Clasen wrote: > > > > Actually, a related issue is that the License.txt file refers to GPL > > > > v2, and grants exceptions to that (which is the point of centention > > > > with Debian) *but* the COPYING file that is distributed with the fonts > > > > is the LGPL v2 file. That is presumably in error. > > > > I double checked, and in liberation-fonts-0.2, COPYING is the GPLv2, not > > the LGPLv2. > > This problem was fixed some time ago. > Nope, not here: liberation-fonts-0.1-9.fc7 COPYING begins with the line: GNU LIBRARY GENERAL PUBLIC LICENSE It is the early version of the LGPL, to be seen here: http://www.gnu.org/licenses/old-licenses/library.txt (before the "L" came to mean "Lesser"). Jonathan. From tcallawa at redhat.com Fri Aug 3 14:15:32 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 03 Aug 2007 10:15:32 -0400 Subject: Possible problem with licensing of liberation-fonts In-Reply-To: <645d17210708030700q52b9c6afged836ffd0eea6ae3@mail.gmail.com> References: <645d17210708030348t3167f8b0j246a8977352a7b1d@mail.gmail.com> <1186144914.9748.231.camel@localhost.localdomain> <645d17210708030647qc64f97bi49a31c2a53e91f4b@mail.gmail.com> <1186148872.9748.258.camel@localhost.localdomain> <1186149049.9748.260.camel@localhost.localdomain> <1186149263.3194.2.camel@localhost.localdomain> <645d17210708030700q52b9c6afged836ffd0eea6ae3@mail.gmail.com> Message-ID: <1186150532.9748.271.camel@localhost.localdomain> On Fri, 2007-08-03 at 15:00 +0100, Jonathan Underwood wrote: > On 03/08/07, Matthias Clasen wrote: > > > > > Actually, a related issue is that the License.txt file refers to GPL > > > > > v2, and grants exceptions to that (which is the point of centention > > > > > with Debian) *but* the COPYING file that is distributed with the fonts > > > > > is the LGPL v2 file. That is presumably in error. > > > > > > I double checked, and in liberation-fonts-0.2, COPYING is the GPLv2, not > > > the LGPLv2. > > > > This problem was fixed some time ago. > > > > Nope, not here: > > liberation-fonts-0.1-9.fc7 > > COPYING begins with the line: GNU LIBRARY GENERAL PUBLIC LICENSE > > It is the early version of the LGPL, to be seen here: > > http://www.gnu.org/licenses/old-licenses/library.txt > > (before the "L" came to mean "Lesser"). Welp, then the maintainer of that package needs to update to liberation-fonts-0.2. :) ~spot From jonathan.underwood at gmail.com Fri Aug 3 14:27:50 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 3 Aug 2007 15:27:50 +0100 Subject: Possible problem with licensing of liberation-fonts In-Reply-To: <1186150532.9748.271.camel@localhost.localdomain> References: <645d17210708030348t3167f8b0j246a8977352a7b1d@mail.gmail.com> <1186144914.9748.231.camel@localhost.localdomain> <645d17210708030647qc64f97bi49a31c2a53e91f4b@mail.gmail.com> <1186148872.9748.258.camel@localhost.localdomain> <1186149049.9748.260.camel@localhost.localdomain> <1186149263.3194.2.camel@localhost.localdomain> <645d17210708030700q52b9c6afged836ffd0eea6ae3@mail.gmail.com> <1186150532.9748.271.camel@localhost.localdomain> Message-ID: <645d17210708030727k74258877x1bdb9ce8c81e34d4@mail.gmail.com> On 03/08/07, Tom spot Callaway wrote: > Welp, then the maintainer of that package needs to update to > liberation-fonts-0.2. :) > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=250753 J. From alan at redhat.com Fri Aug 3 14:32:35 2007 From: alan at redhat.com (Alan Cox) Date: Fri, 3 Aug 2007 10:32:35 -0400 Subject: Possible problem with licensing of liberation-fonts In-Reply-To: <1186144914.9748.231.camel@localhost.localdomain> References: <645d17210708030348t3167f8b0j246a8977352a7b1d@mail.gmail.com> <1186144914.9748.231.camel@localhost.localdomain> Message-ID: <20070803143235.GA25124@devserv.devel.redhat.com> On Fri, Aug 03, 2007 at 08:41:54AM -0400, Tom spot Callaway wrote: > > http://www.mail-archive.com/debian-legal at lists.debian.org/msg36584.html > > > > These arguments would seem to apply equally well to > > inclusion/exclusion of liberation fonts in Fedora as well. Thoughts? > > Talking to the FSF, to see what they think. And mozilla, and firefox and the fedora naming, and ... this is trademark and very different from copyright. I'm suprised the Debian people don't take a bigger exception to the "shall be governed by the laws of the USSA..." From jonathan.underwood at gmail.com Fri Aug 3 14:41:20 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 3 Aug 2007 15:41:20 +0100 Subject: Possible problem with licensing of liberation-fonts In-Reply-To: <20070803143235.GA25124@devserv.devel.redhat.com> References: <645d17210708030348t3167f8b0j246a8977352a7b1d@mail.gmail.com> <1186144914.9748.231.camel@localhost.localdomain> <20070803143235.GA25124@devserv.devel.redhat.com> Message-ID: <645d17210708030741x634adeb2j7e101a3c31eca855@mail.gmail.com> On 03/08/07, Alan Cox wrote: > On Fri, Aug 03, 2007 at 08:41:54AM -0400, Tom spot Callaway wrote: > > > http://www.mail-archive.com/debian-legal at lists.debian.org/msg36584.html > > > > > > These arguments would seem to apply equally well to > > > inclusion/exclusion of liberation fonts in Fedora as well. Thoughts? > > > > Talking to the FSF, to see what they think. > > And mozilla, and firefox and the fedora naming, and ... > > this is trademark and very different from copyright. > > I'm suprised the Debian people don't take a bigger exception to the > "shall be governed by the laws of the USSA..." UIt's not specifically the content of the trademark requirements that cause the problem as I understand it, but rather that taking the GPLv2 license and adding restrictions may be creating a license which is impossible to comply with. From tmz at pobox.com Fri Aug 3 16:01:19 2007 From: tmz at pobox.com (Todd Zullinger) Date: Fri, 3 Aug 2007 12:01:19 -0400 Subject: libgpod soname bump Message-ID: <20070803160119.GF29372@psilocybe.teonanacatl.org> Hi all, I'd like to push a libgpod update to rawhide soon (and F7 a bit after that), which includes a bump in the library version. If you have a package that depends on libgpod and isn't in the list below, speak up so we can take a look and make sure the pacakge will work with the updated libgpod before we push it. In rawhide, the following packages have deps on either libgpod or python-gpod: amarok-0:1.4.6-2.fc8.i386 elisa-0:0.1.6-4.fc8.noarch exaile-0:0.2.10-1.fc8.i386 gtkpod-0:0.99.8-3.fc7.i386 kipi-plugins-0:0.1.4-1.fc8.i386 quodlibet-0:1.0-1.fc7.i386 rhythmbox-0:0.11.1-1.fc8.i386 Additionally, listen-0:0.5-15.fc7.1.i386 can use python-gpod if it's available, but it doesn't have any requirement on it. Amarok, kipi-plugins, and rhythmbox will just need a rebuilt. Gtkpod will get an update for the new libgpod. Elisa, exaile, and listen both use python-gpod and do not need rebuilt. Quod libet uses python-gpod and needs a small patch. I did rebuilds to test and put them here: http://fedorapeople.org/~tmz/libgpod-0.5.2-update/ Once everything is updated in CVS, we can kick off a chain-build or otherwise coordinate the builds to minimize any broken deps. I filed a bug to track this and I'll add the owners of the packages above. Please add yourself if you've got an affected package I didn't catch. https://bugzilla.redhat.com/250781 Thanks, -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It's a little childish and stupid, but then, so is high school. -- Ferris Bueller's Day Off -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From buildsys at fedoraproject.org Fri Aug 3 16:38:19 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 3 Aug 2007 12:38:19 -0400 (EDT) Subject: Package EVR problems in Fedora 2007-08-03 Message-ID: <20070803163819.115C7152131@buildsys.fedoraproject.org> Axel.Thimm AT ATrpms.net: smart FE6 > F7-updates (0:0.50-47.fc6 > 0:0.50-46.fc7) FE6 > F8 (0:0.50-47.fc6 > 0:0.50-46.fc8) alexl AT redhat.com: xdg-user-dirs F7-updates > F8 (0:0.8-3.fc7 > 0:0.8-2.fc8) bos AT serpentine.com: gtk2hs FE6 > F7 (0:0.9.12-1.fc6 > 0:0.9.11-4.fc7) FE6 > F8 (0:0.9.12-1.fc6 > 0:0.9.11-4.fc7) caillon AT redhat.com: thunderbird F7-updates-testing > F8 (0:2.0.0.5-2.fc7 > 0:2.0.0.0-3.fc8) cweyl AT alumni.drew.edu: perl-Algorithm-C3 FE5 > F7 (0:0.07-1.fc5 > 0:0.06-1.fc7) FE6 > F7 (0:0.07-1.fc6 > 0:0.06-1.fc7) perl-CGI-Ex FE5 > F7 (0:2.13-1.fc5 > 0:2.12-1.fc7) FE6 > F7 (0:2.13-1.fc6 > 0:2.12-1.fc7) perl-Class-C3 FE5 > F7 (0:0.18-1.fc5 > 0:0.14-1.fc6) FE6 > F7 (0:0.18-1.fc6 > 0:0.14-1.fc6) perl-Class-C3-XS FE5 > F7 (0:0.06-1.fc5 > 0:0.04-1.fc7) FE6 > F7 (0:0.06-1.fc6 > 0:0.04-1.fc7) perl-Class-Data-Accessor FE5 > F7 (0:0.04001-1.fc5 > 0:0.04000-3.fc7) FE6 > F7 (0:0.04001-1.fc6 > 0:0.04000-3.fc7) perl-Class-MOP FE5 > F7 (0:0.38-1.fc5 > 0:0.37-1.fc7) FE6 > F7 (0:0.38-1.fc6 > 0:0.37-1.fc7) perl-Data-Alias FE5 > F7 (0:1.05-1.fc5 > 0:1.04-1.fc7) FE6 > F7 (0:1.05-1.fc6 > 0:1.04-1.fc7) perl-Event FE6 > F7 (0:1.09-1.fc6 > 0:1.08-1.fc7) perl-Gtk2-Notify FE6 > F7 (0:0.03-1.fc6 > 0:0.02-4.fc7) perl-Gtk2-TrayIcon FE5 > F7 (0:0.06-1.fc5 > 0:0.03-3.fc6) FE6 > F7 (0:0.06-1.fc6 > 0:0.03-3.fc6) perl-JSON-XS FE5 > F7 (0:1.22-1.fc5 > 0:1.21-3.fc7) FE6 > F7 (0:1.22-1.fc6 > 0:1.21-3.fc7) perl-Moose FE5 > F7 (0:0.22-1.fc5 > 0:0.21-1.fc7) FE6 > F7 (0:0.22-1.fc6 > 0:0.21-1.fc7) perl-POE-Component-Server-SOAP FE5 > F7 (0:1.11-1.fc5 > 0:1.10-1.fc6) FE6 > F7 (0:1.11-1.fc6 > 0:1.10-1.fc6) perl-POE-Component-SimpleDBI FE5 > F7 (0:1.16-1.fc5 > 0:1.15-1.fc6) FE6 > F7 (0:1.16-1.fc6 > 0:1.15-1.fc6) perl-POE-Component-SSLify FE5 > F7 (0:0.08-1.fc5 > 0:0.07-1.fc7) FE6 > F7 (0:0.08-1.fc6 > 0:0.07-1.fc7) perl-Sub-Exporter FE5 > F7 (0:0.974-1.fc5 > 0:0.972-1.fc7) FE6 > F7 (0:0.974-1.fc6 > 0:0.972-1.fc7) davidz AT redhat.com: dbus-python F7-updates-testing > F8 (0:0.82.0-2.fc7 > 0:0.82.0-1.fc8) redhat-artwork F7-updates > F8 (0:7.0.0-11.fc7 > 0:7.0.0-10.fc8) ed AT eh3.com: scrip FE6 > F7 (0:1.4-7.fc6 > 0:1.4-6.fc6) FE6 > F8 (0:1.4-7.fc6 > 0:1.4-6.fc6) enrico.scholz AT informatik.tu-chemnitz.de: fedora-usermgmt FE6 > F7 (0:0.10-1.fc6 > 0:0.9-2.fc7) libtasn1 FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE5 > F8 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE6 > F7 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) FE6 > F8 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) mimetic FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7) FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7) util-vserver FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7) FE6 > F7 (0:0.30.213-1.fc6 > 0:0.30.212-3.fc7) xmlrpc-c FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7) FE6 > F7 (0:1.06.16-1.fc6 > 0:1.06.11-2.fc7) foolish AT guezz.net: gtranslator F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8) perl-Net-Libdnet F7-updates > F8 (0:0.01-3.fc7.1 > 0:0.01-2.fc8) perl-Nmap-Parser F7-updates > F8 (0:1.05-4.fc7 > 0:1.05-3.fc8) hellwolf.misty AT gmail.com: fuse-convmvfs FE6 > F8 (0:0.2.4-2.fc6 > 0:0.2.4-1.fc8) F7-updates > F8 (0:0.2.4-3.fc7 > 0:0.2.4-1.fc8) jakub AT redhat.com: gcc FC6-updates > F7 (0:4.1.2-13.fc6 > 0:4.1.2-12) jeff AT ocjtech.us: jrtplib FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) jjohnstn AT redhat.com: eclipse-cdt FC6-updates > F7 (1:3.1.2-4.fc6 > 1:3.1.2-3.fc7) FC6-updates > F8 (1:3.1.2-4.fc6 > 1:3.1.2-3.fc7) lkundrak AT redhat.com: cjet FE6 > F8 (0:0.8.9-2.fc6 > 0:0.8.9-1.fc8) lxtnow AT gmail.com: gammu F7-updates-testing > F8 (0:1.12.92-1.fc7 > 0:1.11.0-1.fc8) specto FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8) F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8) meme AT daughtersoftiresias.org: fortune-firefly FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6) FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6) mfleming+rpm AT enlartenment.com: innotop FE6 > F7-updates (0:1.4.3-2.fc6 > 0:1.4.2-4.fc7) mikeb AT redhat.com: python-cheetah FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) FE6 > F8 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) nhorman AT redhat.com: irqbalance FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6) FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7) FC5-updates > F8 (2:0.55-4.fc5 > 2:0.55-3.fc8) paul AT xelerance.com: xl2tpd FE6 > F7 (0:1.1.11-2.fc6 > 0:1.1.09-1.fc7) pawsa AT theochem.kth.se: balsa FE5 > F7 (0:2.3.16-3.fc5 > 0:2.3.14-1.fc7) FE6 > F7 (0:2.3.17-1.fc6 > 0:2.3.14-1.fc7) rc040203 AT freenet.de: perl-Algorithm-Dependency FE6 > F7 (0:1.103-1.fc6 > 0:1.102-2.fc6) perl-DBIx-DBSchema FE6 > F7 (0:0.33-1.fc6 > 0:0.32-1.fc7) perl-File-Remove FE6 > F7 (0:0.37-1.fc6 > 0:0.34-1.fc7) perl-Params-Util FE5 > F7 (0:0.25-1.fc5 > 0:0.24-1.fc7) FE6 > F7 (0:0.25-1.fc6 > 0:0.24-1.fc7) perl-Want FE6 > F7 (0:0.15-1.fc6 > 0:0.14-1.fc7) rdieter AT math.unl.edu: kdeartwork-extras FE6 > F7 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) FE6 > F8 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) maxima FE5 > F7-updates (0:5.12.0-3.fc5 > 0:5.12.0-2.fc7) FE6 > F7-updates (0:5.12.0-3.fc6 > 0:5.12.0-2.fc7) redhat-bugzilla AT camperquake.de: audacious-plugins FE6 > F8 (0:1.3.5-2.fc6 > 0:1.3.5-1.fc8) F7-updates > F8 (0:1.3.5-2.fc7 > 0:1.3.5-1.fc8) sandmann AT redhat.com: libgtop2 FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7) splinux AT fedoraproject.org: lostirc FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7) FE6 > F8 (0:0.4.6-3.fc6 > 0:0.4.6-2.fc8) than AT redhat.com: kdemultimedia FC6-updates > F7-updates (6:3.5.7-1.fc6 > 6:3.5.7-0.1.fc7) kdepim F7-updates > F8 (6:3.5.7-3.fc7 > 6:3.5.7-2.fc8) veillard AT redhat.com: libxml2 FC6-updates > F8 (0:2.6.29-1.fc6 > 0:2.6.29-1) F7-updates > F8 (0:2.6.29-1.fc7 > 0:2.6.29-1) wolters.liste AT gmx.net: speedcrunch FE6 > F7 (0:0.8-4.fc6 > 0:0.7-1.fc7) ---------------------------------------------------------------------- audacious-plugins: redhat-bugzilla AT camperquake.de FE6 > F8 (0:1.3.5-2.fc6 > 0:1.3.5-1.fc8) F7-updates > F8 (0:1.3.5-2.fc7 > 0:1.3.5-1.fc8) balsa: pawsa AT theochem.kth.se FE5 > F7 (0:2.3.16-3.fc5 > 0:2.3.14-1.fc7) FE6 > F7 (0:2.3.17-1.fc6 > 0:2.3.14-1.fc7) cjet: lkundrak AT redhat.com FE6 > F8 (0:0.8.9-2.fc6 > 0:0.8.9-1.fc8) dbus-python: davidz AT redhat.com F7-updates-testing > F8 (0:0.82.0-2.fc7 > 0:0.82.0-1.fc8) eclipse-cdt: jjohnstn AT redhat.com FC6-updates > F7 (1:3.1.2-4.fc6 > 1:3.1.2-3.fc7) FC6-updates > F8 (1:3.1.2-4.fc6 > 1:3.1.2-3.fc7) fedora-usermgmt: enrico.scholz AT informatik.tu-chemnitz.de FE6 > F7 (0:0.10-1.fc6 > 0:0.9-2.fc7) fortune-firefly: meme AT daughtersoftiresias.org FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6) FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6) fuse-convmvfs: hellwolf.misty AT gmail.com FE6 > F8 (0:0.2.4-2.fc6 > 0:0.2.4-1.fc8) F7-updates > F8 (0:0.2.4-3.fc7 > 0:0.2.4-1.fc8) gammu: lxtnow AT gmail.com F7-updates-testing > F8 (0:1.12.92-1.fc7 > 0:1.11.0-1.fc8) gcc: jakub AT redhat.com FC6-updates > F7 (0:4.1.2-13.fc6 > 0:4.1.2-12) gtk2hs: bos AT serpentine.com FE6 > F7 (0:0.9.12-1.fc6 > 0:0.9.11-4.fc7) FE6 > F8 (0:0.9.12-1.fc6 > 0:0.9.11-4.fc7) gtranslator: foolish AT guezz.net F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8) innotop: mfleming+rpm AT enlartenment.com FE6 > F7-updates (0:1.4.3-2.fc6 > 0:1.4.2-4.fc7) irqbalance: nhorman AT redhat.com FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6) FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7) FC5-updates > F8 (2:0.55-4.fc5 > 2:0.55-3.fc8) jrtplib: jeff AT ocjtech.us FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) kdeartwork-extras: rdieter AT math.unl.edu FE6 > F7 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) FE6 > F8 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) kdemultimedia: than AT redhat.com FC6-updates > F7-updates (6:3.5.7-1.fc6 > 6:3.5.7-0.1.fc7) kdepim: than AT redhat.com F7-updates > F8 (6:3.5.7-3.fc7 > 6:3.5.7-2.fc8) libgtop2: sandmann AT redhat.com FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7) libtasn1: enrico.scholz AT informatik.tu-chemnitz.de FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE5 > F8 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE6 > F7 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) FE6 > F8 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) libxml2: veillard AT redhat.com FC6-updates > F8 (0:2.6.29-1.fc6 > 0:2.6.29-1) F7-updates > F8 (0:2.6.29-1.fc7 > 0:2.6.29-1) lostirc: splinux AT fedoraproject.org FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7) FE6 > F8 (0:0.4.6-3.fc6 > 0:0.4.6-2.fc8) maxima: rdieter AT math.unl.edu FE5 > F7-updates (0:5.12.0-3.fc5 > 0:5.12.0-2.fc7) FE6 > F7-updates (0:5.12.0-3.fc6 > 0:5.12.0-2.fc7) mimetic: enrico.scholz AT informatik.tu-chemnitz.de FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7) FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7) perl-Algorithm-C3: cweyl AT alumni.drew.edu FE5 > F7 (0:0.07-1.fc5 > 0:0.06-1.fc7) FE6 > F7 (0:0.07-1.fc6 > 0:0.06-1.fc7) perl-Algorithm-Dependency: rc040203 AT freenet.de FE6 > F7 (0:1.103-1.fc6 > 0:1.102-2.fc6) perl-CGI-Ex: cweyl AT alumni.drew.edu FE5 > F7 (0:2.13-1.fc5 > 0:2.12-1.fc7) FE6 > F7 (0:2.13-1.fc6 > 0:2.12-1.fc7) perl-Class-C3: cweyl AT alumni.drew.edu FE5 > F7 (0:0.18-1.fc5 > 0:0.14-1.fc6) FE6 > F7 (0:0.18-1.fc6 > 0:0.14-1.fc6) perl-Class-C3-XS: cweyl AT alumni.drew.edu FE5 > F7 (0:0.06-1.fc5 > 0:0.04-1.fc7) FE6 > F7 (0:0.06-1.fc6 > 0:0.04-1.fc7) perl-Class-Data-Accessor: cweyl AT alumni.drew.edu FE5 > F7 (0:0.04001-1.fc5 > 0:0.04000-3.fc7) FE6 > F7 (0:0.04001-1.fc6 > 0:0.04000-3.fc7) perl-Class-MOP: cweyl AT alumni.drew.edu FE5 > F7 (0:0.38-1.fc5 > 0:0.37-1.fc7) FE6 > F7 (0:0.38-1.fc6 > 0:0.37-1.fc7) perl-Data-Alias: cweyl AT alumni.drew.edu FE5 > F7 (0:1.05-1.fc5 > 0:1.04-1.fc7) FE6 > F7 (0:1.05-1.fc6 > 0:1.04-1.fc7) perl-DBIx-DBSchema: rc040203 AT freenet.de FE6 > F7 (0:0.33-1.fc6 > 0:0.32-1.fc7) perl-Event: cweyl AT alumni.drew.edu FE6 > F7 (0:1.09-1.fc6 > 0:1.08-1.fc7) perl-File-Remove: rc040203 AT freenet.de FE6 > F7 (0:0.37-1.fc6 > 0:0.34-1.fc7) perl-Gtk2-Notify: cweyl AT alumni.drew.edu FE6 > F7 (0:0.03-1.fc6 > 0:0.02-4.fc7) perl-Gtk2-TrayIcon: cweyl AT alumni.drew.edu FE5 > F7 (0:0.06-1.fc5 > 0:0.03-3.fc6) FE6 > F7 (0:0.06-1.fc6 > 0:0.03-3.fc6) perl-JSON-XS: cweyl AT alumni.drew.edu FE5 > F7 (0:1.22-1.fc5 > 0:1.21-3.fc7) FE6 > F7 (0:1.22-1.fc6 > 0:1.21-3.fc7) perl-Moose: cweyl AT alumni.drew.edu FE5 > F7 (0:0.22-1.fc5 > 0:0.21-1.fc7) FE6 > F7 (0:0.22-1.fc6 > 0:0.21-1.fc7) perl-Net-Libdnet: foolish AT guezz.net F7-updates > F8 (0:0.01-3.fc7.1 > 0:0.01-2.fc8) perl-Nmap-Parser: foolish AT guezz.net F7-updates > F8 (0:1.05-4.fc7 > 0:1.05-3.fc8) perl-Params-Util: rc040203 AT freenet.de FE5 > F7 (0:0.25-1.fc5 > 0:0.24-1.fc7) FE6 > F7 (0:0.25-1.fc6 > 0:0.24-1.fc7) perl-POE-Component-Server-SOAP: cweyl AT alumni.drew.edu FE5 > F7 (0:1.11-1.fc5 > 0:1.10-1.fc6) FE6 > F7 (0:1.11-1.fc6 > 0:1.10-1.fc6) perl-POE-Component-SimpleDBI: cweyl AT alumni.drew.edu FE5 > F7 (0:1.16-1.fc5 > 0:1.15-1.fc6) FE6 > F7 (0:1.16-1.fc6 > 0:1.15-1.fc6) perl-POE-Component-SSLify: cweyl AT alumni.drew.edu FE5 > F7 (0:0.08-1.fc5 > 0:0.07-1.fc7) FE6 > F7 (0:0.08-1.fc6 > 0:0.07-1.fc7) perl-Sub-Exporter: cweyl AT alumni.drew.edu FE5 > F7 (0:0.974-1.fc5 > 0:0.972-1.fc7) FE6 > F7 (0:0.974-1.fc6 > 0:0.972-1.fc7) perl-Want: rc040203 AT freenet.de FE6 > F7 (0:0.15-1.fc6 > 0:0.14-1.fc7) python-cheetah: mikeb AT redhat.com FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) FE6 > F8 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) redhat-artwork: davidz AT redhat.com F7-updates > F8 (0:7.0.0-11.fc7 > 0:7.0.0-10.fc8) scrip: ed AT eh3.com FE6 > F7 (0:1.4-7.fc6 > 0:1.4-6.fc6) FE6 > F8 (0:1.4-7.fc6 > 0:1.4-6.fc6) smart: Axel.Thimm AT ATrpms.net FE6 > F7-updates (0:0.50-47.fc6 > 0:0.50-46.fc7) FE6 > F8 (0:0.50-47.fc6 > 0:0.50-46.fc8) specto: lxtnow AT gmail.com FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8) F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8) speedcrunch: wolters.liste AT gmx.net FE6 > F7 (0:0.8-4.fc6 > 0:0.7-1.fc7) thunderbird: caillon AT redhat.com F7-updates-testing > F8 (0:2.0.0.5-2.fc7 > 0:2.0.0.0-3.fc8) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7) FE6 > F7 (0:0.30.213-1.fc6 > 0:0.30.212-3.fc7) xdg-user-dirs: alexl AT redhat.com F7-updates > F8 (0:0.8-3.fc7 > 0:0.8-2.fc8) xl2tpd: paul AT xelerance.com FE6 > F7 (0:1.1.11-2.fc6 > 0:1.1.09-1.fc7) xmlrpc-c: enrico.scholz AT informatik.tu-chemnitz.de FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7) FE6 > F7 (0:1.06.16-1.fc6 > 0:1.06.11-2.fc7) From jkeating at redhat.com Fri Aug 3 17:15:00 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 3 Aug 2007 13:15:00 -0400 Subject: libgpod soname bump In-Reply-To: <20070803160119.GF29372@psilocybe.teonanacatl.org> References: <20070803160119.GF29372@psilocybe.teonanacatl.org> Message-ID: <20070803131500.6eb48acc@ender> On Fri, 3 Aug 2007 12:01:19 -0400 Todd Zullinger wrote: > I filed a bug to track this and I'll add the owners of the packages > above. Please add yourself if you've got an affected package I didn't > catch. > > https://bugzilla.redhat.com/250781 That's awesome Todd! Thanks for going through the work to coordinate something like this. This should shine as an example of the kind of cooperation we seek out of our package maintainers. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Fri Aug 3 17:40:32 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 03 Aug 2007 13:40:32 -0400 Subject: Possible problem with licensing of liberation-fonts In-Reply-To: <645d17210708030348t3167f8b0j246a8977352a7b1d@mail.gmail.com> References: <645d17210708030348t3167f8b0j246a8977352a7b1d@mail.gmail.com> Message-ID: <1186162832.9748.314.camel@localhost.localdomain> On Fri, 2007-08-03 at 11:48 +0100, Jonathan Underwood wrote: > Hi, > > I can't find any discussion of this in the archives, so apologies if > this has come up before, but there seems to be a bit of a problem > regarding the GPL+restrictions nature of the liberation fonts we have > packaged for Fedora. See the Debian discussion here: > > http://www.mail-archive.com/debian-legal at lists.debian.org/msg36584.html > > These arguments would seem to apply equally well to > inclusion/exclusion of liberation fonts in Fedora as well. Thoughts? The FSF says the license is Free but GPL-Incompatible, so its fine for Fedora. Added it to the Fonts table. ~spot From jspaleta at gmail.com Fri Aug 3 18:24:18 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 3 Aug 2007 10:24:18 -0800 Subject: libgpod soname bump In-Reply-To: <20070803160119.GF29372@psilocybe.teonanacatl.org> References: <20070803160119.GF29372@psilocybe.teonanacatl.org> Message-ID: <604aa7910708031124r42ba560eg47ada2b99597eb05@mail.gmail.com> On 8/3/07, Todd Zullinger wrote: > In rawhide, the following packages have deps on either libgpod or > python-gpod: You might want to run that again in a couple of days. Rawhide just unfroze. I know for example that I pushed a gpodder update.. just missed the freeze. So gpodder will be in rawhide soonish with a python-gpod dep. -jef From tmz at pobox.com Fri Aug 3 18:59:03 2007 From: tmz at pobox.com (Todd Zullinger) Date: Fri, 3 Aug 2007 14:59:03 -0400 Subject: libgpod soname bump In-Reply-To: <604aa7910708031124r42ba560eg47ada2b99597eb05@mail.gmail.com> References: <20070803160119.GF29372@psilocybe.teonanacatl.org> <604aa7910708031124r42ba560eg47ada2b99597eb05@mail.gmail.com> Message-ID: <20070803185903.GD2564@psilocybe.teonanacatl.org> Jeff Spaleta wrote: > You might want to run that again in a couple of days. Rawhide just > unfroze. I know for example that I pushed a gpodder update.. just > missed the freeze. So gpodder will be in rawhide soonish with a > python-gpod dep. Good point. I shall do that. I'll keep an eye on the rawhide build report as well. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We are not to expect to be transported from despotism to liberty in a featherbed. -- Thomas Jefferson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Fri Aug 3 21:16:32 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 03 Aug 2007 23:16:32 +0200 Subject: Weird build problem, need help Message-ID: <46B39B30.3040409@hhs.nl> Hi all, Today I've tried building arm-gp2x-linux-glibc, which builds fine on my devel machine, but on the buildsys something weird happens, see: http://koji.fedoraproject.org/koji/getfile?taskID=88097&name=build.log The log ends with: --- Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.2187 + umask 022 + cd /builddir/build/BUILD + cd arm-gp2x-linux-glibc-2.3.6 + DOCDIR=/var/tmp/arm-gp2x-linux-glibc-2.3.6-3.fc8-kojibuilder/usr/share/doc/arm-gp2x-linux-glibc-2.3.6 + export DOCDIR + rm -rf /var/tmp/arm-gp2x-linux-glibc-2.3.6-3.fc8-kojibuilder/usr/share/doc/arm-gp2x-linux-glibc-2.3.6 + /bin/mkdir -p /var/tmp/arm-gp2x-linux-glibc-2.3.6-3.fc8-kojibuilder/usr/share/doc/arm-gp2x-linux-glibc-2.3.6 + cp -pr glibc-2.3.6/BUGS glibc-2.3.6/CANCEL-FCT-WAIVE glibc-2.3.6/CANCEL-FILE-WAIVE glibc-2.3.6/CONFORMANCE glibc-2.3.6/COPYING glibc-2.3.6/COPYING.LIB glibc-2.3.6/ChangeLog glibc-2.3.6/ChangeLog.1 glibc-2.3.6/ChangeLog.10 glibc-2.3.6/ChangeLog.11 glibc-2.3.6/ChangeLog.12 glibc-2.3.6/ChangeLog.13 glibc-2.3.6/ChangeLog.14 glibc-2.3.6/ChangeLog.15 glibc-2.3.6/ChangeLog.2 glibc-2.3.6/ChangeLog.3 glibc-2.3.6/ChangeLog.4 glibc-2.3.6/ChangeLog.5 glibc-2.3.6/ChangeLog.6 glibc-2.3.6/ChangeLog.7 glibc-2.3.6/ChangeLog.8 glibc-2.3.6/ChangeLog.9 glibc-2.3.6/FAQ /var/tmp/arm-gp2x-linux-glibc-2.3.6-3.fc8-kojibuilder/usr/share/doc/arm-gp2x-linux-glibc-2.3.6 + cp -pr glibc-2.3.6/LICENSES glibc-2.3.6/README /var/tmp/arm-gp2x-linux-glibc-2.3.6-3.fc8-kojibuilder/usr/share/doc/arm-gp2x-linux-glibc-2.3.6 + cp -pr glibc-2.3.6/README.libm README.fedora /var/tmp/arm-gp2x-linux-glibc-2.3.6-3.fc8-kojibuilder/usr/share/doc/arm-gp2x-linux-glibc-2.3.6 + exit 0 --- And then it just stops instead of listing requires and provides and starting to write rpms, also I think koji should flag a build as failed if no rpms where produced, even if the build command exit status was 0. Regards, Hans From mikeb at redhat.com Fri Aug 3 21:31:52 2007 From: mikeb at redhat.com (Mike Bonnet) Date: Fri, 03 Aug 2007 17:31:52 -0400 Subject: Weird build problem, need help In-Reply-To: <46B39B30.3040409@hhs.nl> References: <46B39B30.3040409@hhs.nl> Message-ID: <1186176712.28296.81.camel@liffey.home> On Fri, 2007-08-03 at 23:16 +0200, Hans de Goede wrote: > And then it just stops instead of listing requires and provides and starting to > write rpms, also I think koji should flag a build as failed if no rpms where > produced, even if the build command exit status was 0. There are times when it is valid for a build to generate no rpms, like kernel-xen on i386 and ppc{,64}. If a build fails, it should exit with a non-zero status. From bnocera at redhat.com Fri Aug 3 22:41:09 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Fri, 03 Aug 2007 23:41:09 +0100 Subject: libgpod soname bump In-Reply-To: <20070803131500.6eb48acc@ender> References: <20070803160119.GF29372@psilocybe.teonanacatl.org> <20070803131500.6eb48acc@ender> Message-ID: <1186180869.3386.37.camel@snoogens.fab.redhat.com> On Fri, 2007-08-03 at 13:15 -0400, Jesse Keating wrote: > On Fri, 3 Aug 2007 12:01:19 -0400 > Todd Zullinger wrote: > > > I filed a bug to track this and I'll add the owners of the packages > > above. Please add yourself if you've got an affected package I didn't > > catch. > > > > https://bugzilla.redhat.com/250781 > > That's awesome Todd! Thanks for going through the work to coordinate > something like this. This should shine as an example of the kind of > cooperation we seek out of our package maintainers. The great advantage of having an upstream maintainer as the package maintainer. Thanks Todd! From Axel.Thimm at ATrpms.net Fri Aug 3 23:06:59 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 4 Aug 2007 01:06:59 +0200 Subject: Weird build problem, need help In-Reply-To: <1186176712.28296.81.camel@liffey.home> References: <46B39B30.3040409@hhs.nl> <1186176712.28296.81.camel@liffey.home> Message-ID: <20070803230659.GD3653@puariko.nirvana> On Fri, Aug 03, 2007 at 05:31:52PM -0400, Mike Bonnet wrote: > On Fri, 2007-08-03 at 23:16 +0200, Hans de Goede wrote: > > And then it just stops instead of listing requires and provides and starting to > > write rpms, also I think koji should flag a build as failed if no rpms where > > produced, even if the build command exit status was 0. > > There are times when it is valid for a build to generate no rpms, like > kernel-xen on i386 and ppc{,64}. How can that be valid? Not technically, but semantically? > If a build fails, it should exit with a non-zero status. -- 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 SteveD at redhat.com Sat Aug 4 09:54:49 2007 From: SteveD at redhat.com (Steve Dickson) Date: Sat, 04 Aug 2007 05:54:49 -0400 Subject: system-config-lvm Message-ID: <46B44CE9.7050304@RedHat.com> Hello, I notice with f7 that system-config-lvm is no longer installed by default and if I remember correctly there was not even an option to choose it... Just curious as to what happen and why? I personally find it to be a excellent tool, especially when configuring xen/kvm guests... tia, steved. From enrico.scholz at informatik.tu-chemnitz.de Sat Aug 4 11:36:54 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 04 Aug 2007 13:36:54 +0200 Subject: open() is buggy in recent glibc (was: Koji cannot build openldap) In-Reply-To: <20070802115509.GQ2063@devserv.devel.redhat.com> (Jakub Jelinek's message of "Thu, 2 Aug 2007 07:55:09 -0400") References: <46B1B38B.50407@redhat.com> <20070802115509.GQ2063@devserv.devel.redhat.com> Message-ID: <878x8r1qg9.fsf_-_@kosh.bigo.ensc.de> Jakub Jelinek writes: > It includes , which provides open, and POSIX allows > functions to be defined as function-like macros. Until recently > glibc didn't define open as a function like macro, but in glibc > 2.6.90 and later it does when -D_FORTIFY_SOURCE=2, to enforce > correct use of open/open64/openat/openat64. New code seems to be buggy and fails at legitimate use of open() | fd = open(file, O_RDONLY); with | src/vlimit.c: In function 'readFile': | src/vlimit.c:280: warning: ISO C forbids empty initializer braces | src/vlimit.c:280: error: zero or negative size array '___arr' | src/vlimit.c:280: warning: ISO C forbids zero-size array '__open_too_many_args' | src/vlimit.c:280: warning: ISO C forbids braced-groups within expressions http://koji.fedoraproject.org/koji/getfile?taskID=88648&name=build.log Beside the error, it clutters the build with bogus 'ISO C forbids ...' warnings. 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 Sat Aug 4 14:22:03 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 4 Aug 2007 10:22:03 -0400 Subject: system-config-lvm In-Reply-To: <46B44CE9.7050304@RedHat.com> References: <46B44CE9.7050304@RedHat.com> Message-ID: <20070804102203.26ab10f1@ender> On Sat, 04 Aug 2007 05:54:49 -0400 Steve Dickson wrote: > Hello, > > I notice with f7 that system-config-lvm is no longer installed > by default and if I remember correctly there was not even an > option to choose it... > > Just curious as to what happen and why? I personally find it > to be a excellent tool, especially when configuring > xen/kvm guests... It just didn't find it's way to the manifest. https://hosted.fedoraproject.org/projects/pungi/browser/config/f8-fedora.manifest Either system-config-lvm should be added to the manifest, or made a default in one of the groups we already include, that is if we (Fedora) deem system-config-lvm to be necessary on the media we spin. Maybe an entry of system-config-* in the manifest, not sure. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jakub at redhat.com Sat Aug 4 20:14:46 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Sat, 4 Aug 2007 16:14:46 -0400 Subject: open() is buggy in recent glibc (was: Koji cannot build openldap) In-Reply-To: <878x8r1qg9.fsf_-_@kosh.bigo.ensc.de> References: <46B1B38B.50407@redhat.com> <20070802115509.GQ2063@devserv.devel.redhat.com> <878x8r1qg9.fsf_-_@kosh.bigo.ensc.de> Message-ID: <20070804201446.GA2063@devserv.devel.redhat.com> On Sat, Aug 04, 2007 at 01:36:54PM +0200, Enrico Scholz wrote: > Jakub Jelinek writes: > > > It includes , which provides open, and POSIX allows > > functions to be defined as function-like macros. Until recently > > glibc didn't define open as a function like macro, but in glibc > > 2.6.90 and later it does when -D_FORTIFY_SOURCE=2, to enforce > > correct use of open/open64/openat/openat64. > > New code seems to be buggy and fails at legitimate use of open() > > | fd = open(file, O_RDONLY); > > with > > | src/vlimit.c: In function 'readFile': > | src/vlimit.c:280: warning: ISO C forbids empty initializer braces > | src/vlimit.c:280: error: zero or negative size array '___arr' > | src/vlimit.c:280: warning: ISO C forbids zero-size array '__open_too_many_args' > | src/vlimit.c:280: warning: ISO C forbids braced-groups within expressions > > http://koji.fedoraproject.org/koji/getfile?taskID=88648&name=build.log > > > Beside the error, it clutters the build with bogus 'ISO C forbids ...' > warnings. Should be fixed in glibc CVS, see http://sources.redhat.com/ml/glibc-cvs/2007-q3/msg00564.html We just forgot to enclose it into __extension__ (the bits/fcntl2.h is only ever included when compiling with GCC). Will build a fixed glibc rpm soonish. Jakub From debarshi.ray at gmail.com Sun Aug 5 03:55:27 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Sun, 5 Aug 2007 09:25:27 +0530 Subject: BuildError: package bouml not in list for tag dist-fc7-updates-candidate Message-ID: <3170f42f0708042055y4a3034ffq832e28944d171ce5@mail.gmail.com> While importing the package bouml (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247417) into the CVS, my network connection broke. I tried to revert all the changes made to the CVS (eg. import.log, sources, etc.), and again ran the cvs-import.sh followed by 'make build'. However I keep getting "BuildError: package bouml not in list for tag dist-fc7-updates-candidate". See http://koji.fedoraproject.org/koji/taskinfo?taskID=89330 What is to be done to resolve this? Can the CVS module be re-created so that I can do it from scratch? Thanks, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From belegdol at gmail.com Sun Aug 5 10:37:52 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Sun, 05 Aug 2007 12:37:52 +0200 Subject: mock woes - ftp mirror setup trouble Message-ID: <46B5A880.7070801@gmail.gom> Hello folks, I was trying to set up mock to use the fastest mirror available, as according to yum-fastestmirror plugin data. I set it up as follows: [fedora] name=fedora #mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-7&arch=x86_64 ftp://ftp.pwr.wroc.pl/pub/linux/fedora/linux/releases/7/Everything/x86_64/os/ [updates-released] name=updates #mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f7&arch=x86_64 ftp://ftp.pwr.wroc.pl/pub/linux/fedora/linux/updates/7/x86_64/ Yet, it was moaning about repomd.xml not being found, despite the fact it is present: [jsikorski at snowball SRPMS]$ mock --rebuildcache goffice04-0.4.2-1.fc7.src.rpm init clean prep This may take a while Error: Cannot open/read repomd.xml file for repository: updates-released Error performing yum command: /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-7-x86_64/root install buildsys-build ending mock-helper: error: /var/lib/mock/fedora-7-x86_64/root/dev/pts: No such file or directory Traceback (most recent call last): File "/usr/bin/mock", line 1145, in main() File "/usr/bin/mock", line 1142, in main do_rebuild(config_opts, srpms) File "/usr/bin/mock", line 1007, in do_rebuild my.close() File "/usr/bin/mock", line 415, in close self._umountall() File "/usr/bin/mock", line 513, in _umountall self._umount(self.mounts[key]) File "/usr/bin/mock", line 506, in _umount raise RootError, "could not umount %s error was: %s" % (path, output) __main__.RootError: could not umount /var/lib/mock/fedora-7-x86_64/root/dev/pts error was: mock-helper: error: /var/lib/mock/fedora-7-x86_64/root/dev/pts: No such file or directory [jsikorski at snowball SRPMS]$ Am I missing something here? Thanks. Regards, Julian From belegdol at gmail.com Sun Aug 5 10:41:38 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Sun, 05 Aug 2007 12:41:38 +0200 Subject: mock woes - ftp mirror setup trouble In-Reply-To: <46B5A880.7070801@gmail.gom> References: <46B5A880.7070801@gmail.gom> Message-ID: <46B5A962.3040206@gmail.gom> Julian Sikorski pisze: > Hello folks, > > I was trying to set up mock to use the fastest mirror available, as > according to yum-fastestmirror plugin data. I set it up as follows: > > [fedora] > name=fedora > #mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-7&arch=x86_64 > ftp://ftp.pwr.wroc.pl/pub/linux/fedora/linux/releases/7/Everything/x86_64/os/ > > [updates-released] > name=updates > #mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f7&arch=x86_64 > ftp://ftp.pwr.wroc.pl/pub/linux/fedora/linux/updates/7/x86_64/ > > Yet, it was moaning about repomd.xml not being found, despite the fact > it is present: > > [jsikorski at snowball SRPMS]$ mock --rebuildcache > goffice04-0.4.2-1.fc7.src.rpm > init > clean > prep > This may take a while > Error: Cannot open/read repomd.xml file for repository: updates-released > > Error performing yum command: /usr/sbin/mock-helper yum --installroot > /var/lib/mock/fedora-7-x86_64/root install buildsys-build > ending > mock-helper: error: /var/lib/mock/fedora-7-x86_64/root/dev/pts: No such > file or directory > > Traceback (most recent call last): > File "/usr/bin/mock", line 1145, in > main() > File "/usr/bin/mock", line 1142, in main > do_rebuild(config_opts, srpms) > File "/usr/bin/mock", line 1007, in do_rebuild > my.close() > File "/usr/bin/mock", line 415, in close > self._umountall() > File "/usr/bin/mock", line 513, in _umountall > self._umount(self.mounts[key]) > File "/usr/bin/mock", line 506, in _umount > raise RootError, "could not umount %s error was: %s" % (path, output) > __main__.RootError: could not umount > /var/lib/mock/fedora-7-x86_64/root/dev/pts error was: mock-helper: > error: /var/lib/mock/fedora-7-x86_64/root/dev/pts: No such file or directory > > [jsikorski at snowball SRPMS]$ > > Am I missing something here? Thanks. > > Regards, > Julian > > I am missing baseurl :). Please ignore my stupidity, I was partying long last night. Regards, Julian From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Aug 6 08:15:46 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 6 Aug 2007 10:15:46 +0200 Subject: New license question regarding libcaca Message-ID: <20070806101546.1dbbb115@python3.es.egwn.lan> Hi, Libaca is licensed under the "DO WHAT THE F**K YOU WANT TO PUBLIC LICENSE". Here is the full text (it's so short) : DO WHAT THE F**K YOU WANT TO PUBLIC LICENSE Version 2, December 2004 Copyright (C) 2004 Sam Hocevar 22 rue de Plaisance, 75014 Paris, France Everyone is permitted to copy and distribute verbatim or modified copies of this license document, and changing it is allowed as long as the name is changed. DO WHAT THE F**K YOU WANT TO PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. You just DO WHAT THE F**K YOU WANT TO. Permanent link : http://sam.zoy.org/wtfpl/COPYING It's pretty much Public Domain with the obligation of changing the name for redistribution. What should I do regarding the license field of the package? Do we need to add a new "WTFPL" possible entry? :-) The libcaca sources also come with copies of the GPLv2 and LGPLv2, but those aren't referenced anywhere in the source code, except the autotools part. Matthias PS: The original License text doesn't have the "**". -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.22.1-27.fc7 Load : 0.61 0.50 0.52 From peter at thecodergeek.com Mon Aug 6 08:27:23 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 06 Aug 2007 01:27:23 -0700 Subject: New license question regarding libcaca In-Reply-To: <20070806101546.1dbbb115@python3.es.egwn.lan> References: <20070806101546.1dbbb115@python3.es.egwn.lan> Message-ID: <1186388843.30653.2.camel@tuxhugs> On Mon, 2007-08-06 at 10:15 +0200, Matthias Saou wrote: > Libaca is licensed under the "DO WHAT THE F**K YOU WANT TO PUBLIC > LICENSE". Here is the full text (it's so short) : According to an old post [1] on the debian-legal mailing list, the FSF says that this license is a valid Free Software license. (Highly amusing, but Free nonetheless.) Therefore, I can imagine that this would be legally acceptable for Fedora, also. [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: 189 bytes Desc: This is a digitally signed message part URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Aug 6 08:32:11 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 6 Aug 2007 10:32:11 +0200 Subject: New license question regarding libcaca In-Reply-To: <1186388843.30653.2.camel@tuxhugs> References: <20070806101546.1dbbb115@python3.es.egwn.lan> <1186388843.30653.2.camel@tuxhugs> Message-ID: <20070806103211.0692ebf5@python3.es.egwn.lan> Peter Gordon wrote : > On Mon, 2007-08-06 at 10:15 +0200, Matthias Saou wrote: > > Libaca is licensed under the "DO WHAT THE F**K YOU WANT TO PUBLIC > > LICENSE". Here is the full text (it's so short) : > > > According to an old post [1] on the debian-legal mailing list, the FSF > says that this license is a valid Free Software license. (Highly > amusing, but Free nonetheless.) > > Therefore, I can imagine that this would be legally acceptable for > Fedora, also. > > [1] http://lists.debian.org/debian-legal/2002/09/msg00032.html Yes, my question wasn't really is it was acceptable or not, as it seemed pretty clear that it was. It's just not listed in the wiki "Licensing" page, and now that we're trying to stick to clearly defined strings for the package License field, I just don't know what to put there. My guess is that we'll need to add a "WTFPL" line :-/ Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.22.1-27.fc7 Load : 0.51 0.47 0.45 From paul at city-fan.org Mon Aug 6 08:35:05 2007 From: paul at city-fan.org (Paul Howarth) Date: Mon, 06 Aug 2007 09:35:05 +0100 Subject: New license question regarding libcaca In-Reply-To: <20070806101546.1dbbb115@python3.es.egwn.lan> References: <20070806101546.1dbbb115@python3.es.egwn.lan> Message-ID: <46B6DD39.1080809@city-fan.org> Matthias Saou wrote: > Hi, > > Libaca is licensed under the "DO WHAT THE F**K YOU WANT TO PUBLIC > LICENSE". Here is the full text (it's so short) : > > DO WHAT THE F**K YOU WANT TO PUBLIC LICENSE > Version 2, December 2004 > > Copyright (C) 2004 Sam Hocevar > 22 rue de Plaisance, 75014 Paris, France > Everyone is permitted to copy and distribute verbatim or modified > copies of this license document, and changing it is allowed as long > as the name is changed. > > DO WHAT THE F**K YOU WANT TO PUBLIC LICENSE > TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION > > 0. You just DO WHAT THE F**K YOU WANT TO. > > Permanent link : http://sam.zoy.org/wtfpl/COPYING > > It's pretty much Public Domain with the obligation of changing the name > for redistribution. The name-changing obligation seems to refer to the license document itself and not the covered works by my reading of that paragraph. Paul. From j.w.r.degoede at hhs.nl Mon Aug 6 08:40:30 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 06 Aug 2007 10:40:30 +0200 Subject: New license question regarding libcaca In-Reply-To: <20070806101546.1dbbb115@python3.es.egwn.lan> References: <20070806101546.1dbbb115@python3.es.egwn.lan> Message-ID: <46B6DE7E.9@hhs.nl> Matthias Saou wrote: > Hi, > > Libaca is licensed under the "DO WHAT THE F**K YOU WANT TO PUBLIC > LICENSE". Here is the full text (it's so short) : > > DO WHAT THE F**K YOU WANT TO PUBLIC LICENSE > Version 2, December 2004 > > Copyright (C) 2004 Sam Hocevar > 22 rue de Plaisance, 75014 Paris, France > Everyone is permitted to copy and distribute verbatim or modified > copies of this license document, and changing it is allowed as long > as the name is changed. > > DO WHAT THE F**K YOU WANT TO PUBLIC LICENSE > TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION > > 0. You just DO WHAT THE F**K YOU WANT TO. > > Permanent link : http://sam.zoy.org/wtfpl/COPYING > > It's pretty much Public Domain with the obligation of changing the name > for redistribution. What should I do regarding the license field of the > package? Do we need to add a new "WTFPL" possible entry? :-) The > libcaca sources also come with copies of the GPLv2 and LGPLv2, but > those aren't referenced anywhere in the source code, except the > autotools part. > > Matthias > > PS: The original License text doesn't have the "**". > This license is already on the list of approved licenses: http://fedoraproject.org/wiki/Licensing The Short form for in the spec file is: WTFPL Regards, Hans p.s. Great to still see you active, as you've been very quiet with regards to rpmfusion. Thorsten has got us a workable infra, all we are really waiting for before moving forward is you, so if you could please spare 15 minutes to tell us where you stand that would be awesome! From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Aug 6 09:27:57 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 6 Aug 2007 11:27:57 +0200 Subject: New license question regarding libcaca In-Reply-To: <46B6DE7E.9@hhs.nl> References: <20070806101546.1dbbb115@python3.es.egwn.lan> <46B6DE7E.9@hhs.nl> Message-ID: <20070806112757.741d9eec@python3.es.egwn.lan> Hans de Goede wrote : > This license is already on the list of approved licenses: > http://fedoraproject.org/wiki/Licensing > > The Short form for in the spec file is: WTFPL Eek, indeed! I wonder how I missed it when searching through the page :-/ Sorry for the noise! > p.s. > > Great to still see you active, as you've been very quiet with regards to > rpmfusion. Thorsten has got us a workable infra, all we are really waiting for > before moving forward is you, so if you could please spare 15 minutes to tell > us where you stand that would be awesome! I should be somewhat more available for the next weeks, since things just started to "calm down" with many co-workers now on holiday ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.22.1-27.fc7 Load : 0.22 0.45 0.60 From bnocera at redhat.com Mon Aug 6 10:11:58 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Mon, 06 Aug 2007 11:11:58 +0100 Subject: New license question regarding libcaca In-Reply-To: <20070806101546.1dbbb115@python3.es.egwn.lan> References: <20070806101546.1dbbb115@python3.es.egwn.lan> Message-ID: <1186395118.6353.2.camel@snoogens.fab.redhat.com> On Mon, 2007-08-06 at 10:15 +0200, Matthias Saou wrote: > Hi, > > Libaca is licensed under the "DO WHAT THE F**K YOU WANT TO PUBLIC > LICENSE". Here is the full text (it's so short) : Version 1.x is pretty much the same, and was used by a number of contributions made to WindowMaker, back at the beginning of the decade. It was the Thai contributor ]d who invented that license then, usually under the name "Anonymous" ;) From jkeating at redhat.com Mon Aug 6 12:26:55 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 6 Aug 2007 08:26:55 -0400 Subject: New license question regarding libcaca In-Reply-To: <20070806103211.0692ebf5@python3.es.egwn.lan> References: <20070806101546.1dbbb115@python3.es.egwn.lan> <1186388843.30653.2.camel@tuxhugs> <20070806103211.0692ebf5@python3.es.egwn.lan> Message-ID: <20070806082655.4b50300f@ender> On Mon, 6 Aug 2007 10:32:11 +0200 Matthias Saou wrote: > My guess is that we'll need to add a "WTFPL" line :-/ There is already such a line at http://fedoraproject.org/wiki/Licensing -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Aug 6 12:52:14 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 6 Aug 2007 14:52:14 +0200 Subject: Dealing with ppc64 BRs Message-ID: <20070806125214.GK18009@puariko.nirvana> Hi, when ppc64 is missing some BRs the builds fail. I feel like it's overshooting to start having ExclusiveArchs/ExlcudeArchs, but maybe that's the way one needs to go with modern build systems ... :/ More concrete mediawiki BR-depends on ocaml and that seems not to exist on ppc64 booming all builds. What's the proper way to fix this? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dennis at ausil.us Mon Aug 6 12:58:50 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 6 Aug 2007 07:58:50 -0500 Subject: Dealing with ppc64 BRs In-Reply-To: <20070806125214.GK18009@puariko.nirvana> References: <20070806125214.GK18009@puariko.nirvana> Message-ID: <200708060758.51131.dennis@ausil.us> Once upon a time Monday 06 August 2007, Axel Thimm wrote: > Hi, > > when ppc64 is missing some BRs the builds fail. I feel like it's > overshooting to start having ExclusiveArchs/ExlcudeArchs, but maybe > that's the way one needs to go with modern build systems ... :/ > > More concrete mediawiki BR-depends on ocaml and that seems not to > exist on ppc64 booming all builds. What's the proper way to fix this? Get what you need built fpr ppc64. Dennis From Axel.Thimm at ATrpms.net Mon Aug 6 13:01:44 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 6 Aug 2007 15:01:44 +0200 Subject: Dealing with ppc64 BRs In-Reply-To: <200708060758.51131.dennis@ausil.us> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> Message-ID: <20070806130144.GN18009@puariko.nirvana> On Mon, Aug 06, 2007 at 07:58:50AM -0500, Dennis Gilmore wrote: > Once upon a time Monday 06 August 2007, Axel Thimm wrote: > > Hi, > > > > when ppc64 is missing some BRs the builds fail. I feel like it's > > overshooting to start having ExclusiveArchs/ExlcudeArchs, but maybe > > that's the way one needs to go with modern build systems ... :/ > > > > More concrete mediawiki BR-depends on ocaml and that seems not to > > exist on ppc64 booming all builds. What's the proper way to fix this? > > Get what you need built fpr ppc64. ? Should I volunteer to maintain package foo and bar on ppc64 becasue they are BRs to my baz? -- 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 Mon Aug 6 13:11:08 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 6 Aug 2007 08:11:08 -0500 Subject: Dealing with ppc64 BRs In-Reply-To: <20070806130144.GN18009@puariko.nirvana> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> <20070806130144.GN18009@puariko.nirvana> Message-ID: <20070806081108.4346141c@weaponx.rchland.ibm.com> On Mon, 6 Aug 2007 15:01:44 +0200 Axel Thimm wrote: > On Mon, Aug 06, 2007 at 07:58:50AM -0500, Dennis Gilmore wrote: > > Once upon a time Monday 06 August 2007, Axel Thimm wrote: > > > Hi, > > > > > > when ppc64 is missing some BRs the builds fail. I feel like it's > > > overshooting to start having ExclusiveArchs/ExlcudeArchs, but maybe > > > that's the way one needs to go with modern build systems ... :/ > > > > > > More concrete mediawiki BR-depends on ocaml and that seems not to > > > exist on ppc64 booming all builds. What's the proper way to fix this? > > > > Get what you need built fpr ppc64. > > ? > > Should I volunteer to maintain package foo and bar on ppc64 becasue > they are BRs to my baz? David was working on ocaml at one point. For now, ExcludeArch it and file the appropriate ExcludeArch bug. When ocaml is built, you can remove it and rebuild. josh From Axel.Thimm at ATrpms.net Mon Aug 6 14:35:28 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 6 Aug 2007 16:35:28 +0200 Subject: Make ppc64 secondary arch - don't block builds (was: Dealing with ppc64 BRs) In-Reply-To: <20070806081108.4346141c@weaponx.rchland.ibm.com> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> <20070806130144.GN18009@puariko.nirvana> <20070806081108.4346141c@weaponx.rchland.ibm.com> Message-ID: <20070806143528.GA15391@puariko.nirvana> On Mon, Aug 06, 2007 at 08:11:08AM -0500, Josh Boyer wrote: > On Mon, 6 Aug 2007 15:01:44 +0200 > Axel Thimm wrote: > > > On Mon, Aug 06, 2007 at 07:58:50AM -0500, Dennis Gilmore wrote: > > > Once upon a time Monday 06 August 2007, Axel Thimm wrote: > > > > Hi, > > > > > > > > when ppc64 is missing some BRs the builds fail. I feel like it's > > > > overshooting to start having ExclusiveArchs/ExlcudeArchs, but maybe > > > > that's the way one needs to go with modern build systems ... :/ > > > > > > > > More concrete mediawiki BR-depends on ocaml and that seems not to > > > > exist on ppc64 booming all builds. What's the proper way to fix this? > > > > > > Get what you need built fpr ppc64. > > > > ? > > > > Should I volunteer to maintain package foo and bar on ppc64 becasue > > they are BRs to my baz? > > David was working on ocaml at one point. For now, ExcludeArch it and > file the appropriate ExcludeArch bug. When ocaml is built, you can > remove it and rebuild. Ugly - we need to artificially bump the release to exclude it and later bump to undo the ugliness. In the meantime we enforce users to download this twice (or trice) and not only for the affected distros, as fiddling with release tags has a domino effect to later releases (not that it matters in this case, devel is missing ocaml.ppc64 just the same). And all that for archs that are already scheduled to become secondary archs, e.g. not block builds? ppc/ppc64 were supposed to become secondary archs if another arch was to be found to be secondary and we already have arm for filling that requirement, so since it's already a closed deal, why do we need to go through this pain? And shouldn't ppc64 (or any half-built arch) had been automatically introduced as a secondary arch anyway to not mess with normal packaging workflow? Even if the intention were to elevate it later to a primary arch someday? What will happen with the next arch that will be added? Have all packages ExcludeArch it to start with? -- 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 Mon Aug 6 14:46:48 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 6 Aug 2007 09:46:48 -0500 Subject: Make ppc64 secondary arch - don't block builds (was: Dealing with ppc64 BRs) In-Reply-To: <20070806143528.GA15391@puariko.nirvana> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> <20070806130144.GN18009@puariko.nirvana> <20070806081108.4346141c@weaponx.rchland.ibm.com> <20070806143528.GA15391@puariko.nirvana> Message-ID: <20070806094648.7fb586e9@weaponx.rchland.ibm.com> On Mon, 6 Aug 2007 16:35:28 +0200 Axel Thimm wrote: > > David was working on ocaml at one point. For now, ExcludeArch it and > > file the appropriate ExcludeArch bug. When ocaml is built, you can > > remove it and rebuild. > > Ugly - we need to artificially bump the release to exclude it and > later bump to undo the ugliness. In the meantime we enforce users to > download this twice (or trice) and not only for the affected distros, > as fiddling with release tags has a domino effect to later releases > (not that it matters in this case, devel is missing ocaml.ppc64 just > the same). Or you could just do it on the next update and pick up the ppc64 build at that time... > And all that for archs that are already scheduled to become secondary > archs, e.g. not block builds? ppc/ppc64 were supposed to become > secondary archs if another arch was to be found to be secondary and we > already have arm for filling that requirement, so since it's already a > closed deal, why do we need to go through this pain? ARM is not an official secondary arch to my knowledge. The Fedora buildsystem isn't able to handle secondary arch stuff yet. And I suspect SPARC will be there first anyway. Even with secondary arches, you'll still need to do the ExcludeArch if it really doesn't build properly. Or someone will anyway. > And shouldn't ppc64 (or any half-built arch) had been automatically > introduced as a secondary arch anyway to not mess with normal > packaging workflow? Even if the intention were to elevate it later to > a primary arch someday? What will happen with the next arch that will > be added? Have all packages ExcludeArch it to start with? See above about buildsys not being exactly ready. As for the new secondary arches, I highly doubt they will be elevated. You'd need an architecture as popular and prevalent as x86/x86_64 to come along and take over the world. josh From Axel.Thimm at ATrpms.net Mon Aug 6 15:11:56 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 6 Aug 2007 17:11:56 +0200 Subject: Make ppc64 secondary arch - don't block builds (was: Dealing with ppc64 BRs) In-Reply-To: <20070806094648.7fb586e9@weaponx.rchland.ibm.com> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> <20070806130144.GN18009@puariko.nirvana> <20070806081108.4346141c@weaponx.rchland.ibm.com> <20070806143528.GA15391@puariko.nirvana> <20070806094648.7fb586e9@weaponx.rchland.ibm.com> Message-ID: <20070806151156.GD15391@puariko.nirvana> On Mon, Aug 06, 2007 at 09:46:48AM -0500, Josh Boyer wrote: > ARM is not an official secondary arch to my knowledge. The Fedora > buildsystem isn't able to handle secondary arch stuff yet. And I > suspect SPARC will be there first anyway. Didn't fesco vote on arm already on June the 12th? And yes, the buildsystem is not capable to handle secondary arch, that's my speech, e.g. this is a reuqest to implement this sooner than later to not have packagers do the exclude/include jumbo. The work to support secondary archs is needed anyway, and doing it now will save lots of specfile messing. -- 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 Mon Aug 6 15:20:02 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 6 Aug 2007 16:20:02 +0100 Subject: Possible problem with licensing of liberation-fonts In-Reply-To: <1186162832.9748.314.camel@localhost.localdomain> References: <645d17210708030348t3167f8b0j246a8977352a7b1d@mail.gmail.com> <1186162832.9748.314.camel@localhost.localdomain> Message-ID: <645d17210708060820yec878ber8e14e7f4b7f5ad38@mail.gmail.com> On 03/08/07, Tom spot Callaway wrote: > The FSF says the license is Free but GPL-Incompatible, so its fine for > Fedora. Added it to the Fonts table. OK, thanks for following it up Tom. (does that make the task less thankless? :) Jonathan From jkeating at redhat.com Mon Aug 6 15:24:46 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 6 Aug 2007 11:24:46 -0400 Subject: Make ppc64 secondary arch - don't block builds (was: Dealing with ppc64 BRs) In-Reply-To: <20070806151156.GD15391@puariko.nirvana> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> <20070806130144.GN18009@puariko.nirvana> <20070806081108.4346141c@weaponx.rchland.ibm.com> <20070806143528.GA15391@puariko.nirvana> <20070806094648.7fb586e9@weaponx.rchland.ibm.com> <20070806151156.GD15391@puariko.nirvana> Message-ID: <20070806112446.0ad53afe@ender> On Mon, 6 Aug 2007 17:11:56 +0200 Axel Thimm wrote: > And yes, the buildsystem is not capable to handle secondary arch, > that's my speech, e.g. this is a reuqest to implement this sooner than > later to not have packagers do the exclude/include jumbo. The work to > support secondary archs is needed anyway, and doing it now will save > lots of specfile messing. But we're not talking about a secondary arch, we're talking about a primary arch. Like it or not, ppc (and thus ppc64) is a primary arch set and must addressed just like the other primary arches. As for secondary arches, the current proposal would not stop you from building your package if the build fails on the secondary arch. It's up to the secondary arch team to either get your build working, or work with you to insert an ExcludeArch. But it doesn't have to be done immediately to get your primary update out. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tgl at redhat.com Mon Aug 6 15:48:34 2007 From: tgl at redhat.com (Tom Lane) Date: Mon, 06 Aug 2007 11:48:34 -0400 Subject: Make ppc64 secondary arch - don't block builds (was: Dealing with ppc64 BRs) In-Reply-To: <20070806112446.0ad53afe@ender> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> <20070806130144.GN18009@puariko.nirvana> <20070806081108.4346141c@weaponx.rchland.ibm.com> <20070806143528.GA15391@puariko.nirvana> <20070806094648.7fb586e9@weaponx.rchland.ibm.com> <20070806151156.GD15391@puariko.nirvana> <20070806112446.0ad53afe@ender> Message-ID: <28075.1186415314@sss.pgh.pa.us> Jesse Keating writes: > But we're not talking about a secondary arch, we're talking about a > primary arch. Like it or not, ppc (and thus ppc64) is a primary arch > set and must addressed just like the other primary arches. I really find it troublesome that anyone thinks they shouldn't be primary. If the only primary arches are x86/x86_64, then packagers will basically not have any forcing function to make them worry about whether the code is portable to any non-Intel platform. I think that at minimum we need a bigendian arch or two in the primary set, just so that there's at least a token requirement for portability. Else the secondary arches are *all* doomed to failure in the long run. regards, tom lane From tcallawa at redhat.com Mon Aug 6 15:51:15 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 06 Aug 2007 11:51:15 -0400 Subject: Possible problem with licensing of liberation-fonts In-Reply-To: <645d17210708060820yec878ber8e14e7f4b7f5ad38@mail.gmail.com> References: <645d17210708030348t3167f8b0j246a8977352a7b1d@mail.gmail.com> <1186162832.9748.314.camel@localhost.localdomain> <645d17210708060820yec878ber8e14e7f4b7f5ad38@mail.gmail.com> Message-ID: <1186415475.3839.23.camel@dhcp67.install.boston.redhat.com> On Mon, 2007-08-06 at 16:20 +0100, Jonathan Underwood wrote: > On 03/08/07, Tom spot Callaway wrote: > > The FSF says the license is Free but GPL-Incompatible, so its fine for > > Fedora. Added it to the Fonts table. > > OK, thanks for following it up Tom. (does that make the task less thankless? :) Not anymore! :) ~spot From jkeating at redhat.com Mon Aug 6 16:03:50 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 6 Aug 2007 12:03:50 -0400 Subject: Make ppc64 secondary arch - don't block builds (was: Dealing with ppc64 BRs) In-Reply-To: <28075.1186415314@sss.pgh.pa.us> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> <20070806130144.GN18009@puariko.nirvana> <20070806081108.4346141c@weaponx.rchland.ibm.com> <20070806143528.GA15391@puariko.nirvana> <20070806094648.7fb586e9@weaponx.rchland.ibm.com> <20070806151156.GD15391@puariko.nirvana> <20070806112446.0ad53afe@ender> <28075.1186415314@sss.pgh.pa.us> Message-ID: <20070806120350.6e8d3c3b@ender> On Mon, 06 Aug 2007 11:48:34 -0400 Tom Lane wrote: > I really find it troublesome that anyone thinks they shouldn't be > primary. If the only primary arches are x86/x86_64, then packagers > will basically not have any forcing function to make them worry about > whether the code is portable to any non-Intel platform. I think that > at minimum we need a bigendian arch or two in the primary set, just > so that there's at least a token requirement for portability. Else > the secondary arches are *all* doomed to failure in the long run. But I find it troublesome that we're going to make /everybody/ care about something that 1% of our user base has, so that the 1% has a better life. Isn't open source about scratching your own itch and making it easy for others to scratch theirs? We're providing a way for non-maintstream arches to play along side the main stream and have access to fix things when they go awry, but asking volunteers to care about exotic arches is just silly and rude. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Mon Aug 6 16:09:57 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 6 Aug 2007 11:09:57 -0500 Subject: Make ppc64 secondary arch - don't block builds (was: Dealing with ppc64 BRs) In-Reply-To: <20070806151156.GD15391@puariko.nirvana> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> <20070806130144.GN18009@puariko.nirvana> <20070806081108.4346141c@weaponx.rchland.ibm.com> <20070806143528.GA15391@puariko.nirvana> <20070806094648.7fb586e9@weaponx.rchland.ibm.com> <20070806151156.GD15391@puariko.nirvana> Message-ID: <20070806110957.03e4e743@weaponx.rchland.ibm.com> On Mon, 6 Aug 2007 17:11:56 +0200 Axel Thimm wrote: > On Mon, Aug 06, 2007 at 09:46:48AM -0500, Josh Boyer wrote: > > ARM is not an official secondary arch to my knowledge. The Fedora > > buildsystem isn't able to handle secondary arch stuff yet. And I > > suspect SPARC will be there first anyway. > > Didn't fesco vote on arm already on June the 12th? No. On July 12, we approved the Secondary arch proposal in general. We didn't approve any architectures as official secondary arches. It would be pointless to do so, since the buildsystem isn't setup yet. josh From aph at redhat.com Mon Aug 6 16:16:06 2007 From: aph at redhat.com (Andrew Haley) Date: Mon, 6 Aug 2007 17:16:06 +0100 Subject: Make ppc64 secondary arch - don't block builds (was: Dealing with ppc64 BRs) In-Reply-To: <20070806120350.6e8d3c3b@ender> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> <20070806130144.GN18009@puariko.nirvana> <20070806081108.4346141c@weaponx.rchland.ibm.com> <20070806143528.GA15391@puariko.nirvana> <20070806094648.7fb586e9@weaponx.rchland.ibm.com> <20070806151156.GD15391@puariko.nirvana> <20070806112446.0ad53afe@ender> <28075.1186415314@sss.pgh.pa.us> <20070806120350.6e8d3c3b@ender> Message-ID: <18103.18758.879595.291982@zebedee.pink> Jesse Keating writes: > On Mon, 06 Aug 2007 11:48:34 -0400 > Tom Lane wrote: > > I really find it troublesome that anyone thinks they shouldn't be > > primary. If the only primary arches are x86/x86_64, then > > packagers will basically not have any forcing function to make > > them worry about whether the code is portable to any non-Intel > > platform. I think that at minimum we need a bigendian arch or > > two in the primary set, just so that there's at least a token > > requirement for portability. Else the secondary arches are *all* > > doomed to failure in the long run. > > But I find it troublesome that we're going to make /everybody/ care > about something that 1% of our user base has, so that the 1% has a > better life. Bugs found when chasing down portability problems are often real bugs, not just non-portable code. For that reason, 100% of our users benefit from portable code, not just the 1% who use minor architectures. It's in everyone's interest that Fedora code is real C (or C++). Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From tgl at redhat.com Mon Aug 6 16:23:27 2007 From: tgl at redhat.com (Tom Lane) Date: Mon, 06 Aug 2007 12:23:27 -0400 Subject: Make ppc64 secondary arch - don't block builds (was: Dealing with ppc64 BRs) In-Reply-To: <20070806120350.6e8d3c3b@ender> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> <20070806130144.GN18009@puariko.nirvana> <20070806081108.4346141c@weaponx.rchland.ibm.com> <20070806143528.GA15391@puariko.nirvana> <20070806094648.7fb586e9@weaponx.rchland.ibm.com> <20070806151156.GD15391@puariko.nirvana> <20070806112446.0ad53afe@ender> <28075.1186415314@sss.pgh.pa.us> <20070806120350.6e8d3c3b@ender> Message-ID: <28529.1186417407@sss.pgh.pa.us> Jesse Keating writes: > But I find it troublesome that we're going to make /everybody/ care > about something that 1% of our user base has, so that the 1% has a > better life. Isn't open source about scratching your own itch and > making it easy for others to scratch theirs? We're providing a way for > non-maintstream arches to play along side the main stream and have > access to fix things when they go awry, but asking volunteers to care > about exotic arches is just silly and rude. What I'm worried about is that the distribution will go from x86-centric to x86-only, with large chunks of functionality that simply doesn't work on any non-Intel architecture and with no interest on the part of the primary maintainer in making it work. A few volunteers handling a secondary arch aren't going to get any traction in that environment. Now, if you think it's a good thing for Intel to have a monopoly on processor design, and if you think that Red Hat will soon abandon support for all non-Intel processors in RHEL (note: I do not actually know what our plans are in that respect), then sure, make Fedora x86-specific. Up to now, Fedora Core was known to be reasonably portable because the same engineer handling any Core package had to also build it for RHEL, but with the disappearance of the distinction between Core and Extras that's not much comfort anymore. My point is basically that I want to see Extras trying to achieve the portability Core had, not allow Core to slide down to the non-portability Extras had. regards, tom lane From jkeating at redhat.com Mon Aug 6 16:29:37 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 6 Aug 2007 12:29:37 -0400 Subject: Make ppc64 secondary arch - don't block builds (was: Dealing with ppc64 BRs) In-Reply-To: <28529.1186417407@sss.pgh.pa.us> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> <20070806130144.GN18009@puariko.nirvana> <20070806081108.4346141c@weaponx.rchland.ibm.com> <20070806143528.GA15391@puariko.nirvana> <20070806094648.7fb586e9@weaponx.rchland.ibm.com> <20070806151156.GD15391@puariko.nirvana> <20070806112446.0ad53afe@ender> <28075.1186415314@sss.pgh.pa.us> <20070806120350.6e8d3c3b@ender> <28529.1186417407@sss.pgh.pa.us> Message-ID: <20070806122937.78bfcdd9@ender> On Mon, 06 Aug 2007 12:23:27 -0400 Tom Lane wrote: > Up to now, Fedora Core was known to be reasonably portable because the > same engineer handling any Core package had to also build it for RHEL, > but with the disappearance of the distinction between Core and Extras > that's not much comfort anymore. My point is basically that I want to > see Extras trying to achieve the portability Core had, not allow Core > to slide down to the non-portability Extras had. Yes, it's "easy" to care about other arches when you're paid to do so. But we have this goal that we want Fedora to be accessible and worked on by more than just Red Hat engineering. And the sad reality of today is that x86 is the prevalent arch and that's the lions share of volunteers we're going to get. Forcing them to care about whatever arches Red Hat deems is necessary for their business strategy will likely cut our volunteers by quite a bit and send them somewhere else that doesn't force them to cater to $BigCorp business concerns. We could go back to Fedora being a purely Red Hat thing with only Red Hat employees paid to work on it and then we'd be sure that everybody would "care" about those non-x86 arches, but then where would that leave the distribution? -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Aug 6 16:31:13 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 6 Aug 2007 12:31:13 -0400 Subject: Make ppc64 secondary arch - don't block builds (was: Dealing with ppc64 BRs) In-Reply-To: <18103.18758.879595.291982@zebedee.pink> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> <20070806130144.GN18009@puariko.nirvana> <20070806081108.4346141c@weaponx.rchland.ibm.com> <20070806143528.GA15391@puariko.nirvana> <20070806094648.7fb586e9@weaponx.rchland.ibm.com> <20070806151156.GD15391@puariko.nirvana> <20070806112446.0ad53afe@ender> <28075.1186415314@sss.pgh.pa.us> <20070806120350.6e8d3c3b@ender> <18103.18758.879595.291982@zebedee.pink> Message-ID: <20070806123113.1f11f437@ender> On Mon, 6 Aug 2007 17:16:06 +0100 Andrew Haley wrote: > Bugs found when chasing down portability problems are often real bugs, > not just non-portable code. For that reason, 100% of our users > benefit from portable code, not just the 1% who use minor > architectures. It's in everyone's interest that Fedora code is real C > (or C++). But when that bug doesn't effect the majority of our user base, do those users really care? Should the? Yes. Do they? No. "It works for me and my major arch, why should I care that it broke on your silly arch?" -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From aph at redhat.com Mon Aug 6 16:42:30 2007 From: aph at redhat.com (Andrew Haley) Date: Mon, 6 Aug 2007 17:42:30 +0100 Subject: Make ppc64 secondary arch - don't block builds (was: Dealing with ppc64 BRs) In-Reply-To: <20070806123113.1f11f437@ender> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> <20070806130144.GN18009@puariko.nirvana> <20070806081108.4346141c@weaponx.rchland.ibm.com> <20070806143528.GA15391@puariko.nirvana> <20070806094648.7fb586e9@weaponx.rchland.ibm.com> <20070806151156.GD15391@puariko.nirvana> <20070806112446.0ad53afe@ender> <28075.1186415314@sss.pgh.pa.us> <20070806120350.6e8d3c3b@ender> <18103.18758.879595.291982@zebedee.pink> <20070806123113.1f11f437@ender> Message-ID: <18103.20342.717121.200533@zebedee.pink> Jesse Keating writes: > On Mon, 6 Aug 2007 17:16:06 +0100 > Andrew Haley wrote: > > > Bugs found when chasing down portability problems are often real > > bugs, not just non-portable code. For that reason, 100% of our > > users benefit from portable code, not just the 1% who use minor > > architectures. It's in everyone's interest that Fedora code is > > real C (or C++). > > But when that bug doesn't effect the majority of our user base, How do you know until you have analyzed the bug? Every bug revealed during portability testing is potentially a real bug on the primary arch. > do those users really care? Should the? Yes. Do they? No. "It > works for me and my major arch, why should I care that it broke on > your silly arch?" You are painfully close to assuming that our users are fools; I don't believe it. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From jkeating at redhat.com Mon Aug 6 16:43:31 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 6 Aug 2007 12:43:31 -0400 Subject: Make ppc64 secondary arch - don't block builds (was: Dealing with ppc64 BRs) In-Reply-To: <18103.20342.717121.200533@zebedee.pink> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> <20070806130144.GN18009@puariko.nirvana> <20070806081108.4346141c@weaponx.rchland.ibm.com> <20070806143528.GA15391@puariko.nirvana> <20070806094648.7fb586e9@weaponx.rchland.ibm.com> <20070806151156.GD15391@puariko.nirvana> <20070806112446.0ad53afe@ender> <28075.1186415314@sss.pgh.pa.us> <20070806120350.6e8d3c3b@ender> <18103.18758.879595.291982@zebedee.pink> <20070806123113.1f11f437@ender> <18103.20342.717121.200533@zebedee.pink> Message-ID: <20070806124331.6ab478b5@ender> On Mon, 6 Aug 2007 17:42:30 +0100 Andrew Haley wrote: > You are painfully close to assuming that our users are fools; I don't > believe it. No, right now we've got a pretty self selected set of users. By nature of how we put our distro together and how we make people get it we've got a 'you must be this high to ride' sign. That's neat. Why can't we get other users too? Or are we happy with the elitism? -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From aph at redhat.com Mon Aug 6 16:52:16 2007 From: aph at redhat.com (Andrew Haley) Date: Mon, 6 Aug 2007 17:52:16 +0100 Subject: Make ppc64 secondary arch - don't block builds (was: Dealing with ppc64 BRs) In-Reply-To: <20070806124331.6ab478b5@ender> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> <20070806130144.GN18009@puariko.nirvana> <20070806081108.4346141c@weaponx.rchland.ibm.com> <20070806143528.GA15391@puariko.nirvana> <20070806094648.7fb586e9@weaponx.rchland.ibm.com> <20070806151156.GD15391@puariko.nirvana> <20070806112446.0ad53afe@ender> <28075.1186415314@sss.pgh.pa.us> <20070806120350.6e8d3c3b@ender> <18103.18758.879595.291982@zebedee.pink> <20070806123113.1f11f437@ender> <18103.20342.717121.200533@zebedee.pink> <20070806124331.6ab478b5@ender> Message-ID: <18103.20928.692537.851078@zebedee.pink> Jesse Keating writes: > On Mon, 6 Aug 2007 17:42:30 +0100 > Andrew Haley wrote: > > > You are painfully close to assuming that our users are fools; I don't > > believe it. > > No, right now we've got a pretty self selected set of users. A couple of millions of them, apparently. > By nature of how we put our distro together and how we make people > get it we've got a 'you must be this high to ride' sign. That's > neat. Why can't we get other users too? Or are we happy with the > elitism? This seems to be a different argument. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From oliver at linux-kernel.at Mon Aug 6 17:19:05 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 06 Aug 2007 19:19:05 +0200 Subject: Make ppc64 secondary arch - don't block builds In-Reply-To: <20070806124331.6ab478b5@ender> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> <20070806130144.GN18009@puariko.nirvana> <20070806081108.4346141c@weaponx.rchland.ibm.com> <20070806143528.GA15391@puariko.nirvana> <20070806094648.7fb586e9@weaponx.rchland.ibm.com> <20070806151156.GD15391@puariko.nirvana> <20070806112446.0ad53afe@ender> <28075.1186415314@sss.pgh.pa.us> <20070806120350.6e8d3c3b@ender> <18103.18758.879595.291982@zebedee.pink> <20070806123113.1f11f437@ender> <18103.20342.717121.200533@zebedee.pink> <20070806124331.6ab478b5@ender> Message-ID: <46B75809.7030303@linux-kernel.at> Jesse Keating schrieb: > On Mon, 6 Aug 2007 17:42:30 +0100 > Andrew Haley wrote: > >> You are painfully close to assuming that our users are fools; I don't >> believe it. > > No, right now we've got a pretty self selected set of users. By nature > of how we put our distro together and how we make people get it we've > got a 'you must be this high to ride' sign. That's neat. Why can't we > get other users too? Or are we happy with the elitism? Our >users< aren't fools (and (most) of 'em aren't rocket scientist either. :-) Speaking about both RHEL and Fedora. However, I think the *biggest* part of our >package monkeys< (the people who need to *support* those arches) are quite well educated and have strong Linux knowledge... Maybe I'm totally wrong - I don't hope so. The way we put together the distro... Yes, without mp3 support for example. I often heared: It's to difficult for me to use Fedora, because they don't support this and that (out of the box)... Well mp3 *many* times... :-) That's why it comes to mind mind first. And the silly, dumb userbase who want Linux preinstalled on their computers with printed handbook, some DVD and stickers and whatever... We aren't going to support them with FLOSS only software anytime soon... Some elitism is there for sure :-) 2 cent. -of From oliver at linux-kernel.at Mon Aug 6 17:33:30 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 06 Aug 2007 19:33:30 +0200 Subject: Make ppc64 secondary arch - don't block builds In-Reply-To: <20070806123113.1f11f437@ender> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> <20070806130144.GN18009@puariko.nirvana> <20070806081108.4346141c@weaponx.rchland.ibm.com> <20070806143528.GA15391@puariko.nirvana> <20070806094648.7fb586e9@weaponx.rchland.ibm.com> <20070806151156.GD15391@puariko.nirvana> <20070806112446.0ad53afe@ender> <28075.1186415314@sss.pgh.pa.us> <20070806120350.6e8d3c3b@ender> <18103.18758.879595.291982@zebedee.pink> <20070806123113.1f11f437@ender> Message-ID: <46B75B6A.5090103@linux-kernel.at> Jesse Keating schrieb: > On Mon, 6 Aug 2007 17:16:06 +0100 > Andrew Haley wrote: > >> Bugs found when chasing down portability problems are often real bugs, >> not just non-portable code. For that reason, 100% of our users >> benefit from portable code, not just the 1% who use minor >> architectures. It's in everyone's interest that Fedora code is real C >> (or C++). > > But when that bug doesn't effect the majority of our user base, do > those users really care? Should the? Yes. Do they? No. "It works > for me and my major arch, why should I care that it broke on your silly > arch?" If we think this way... Well then we must stop the pedantic check of open from latest glibc (I think it's already disabled however.)... Seems 100% of our userbase could have lived without that check... And it also seems that *many* of our packagers could as well - they now need to write patches and send 'em upstream. I don't want to imagine what some upstream maintainers will say..... We then could also ignore any kind of -Werror :-P OK, /me comes back from sarkasm. Jesse, we had this topic a few times already - on this list. I can understand if someone says: Ignore it, it's ARM or ignore it, it's Alpha (well, as Alpha-maintainer I don't really *want* to hear that). But for ppc - I guess there are already quite a lot people out there using Fedora on ppc(64). Isn't it? For the "blocking builds" topic. Well, if it doesn't work on ppc64 - the only primary-non-intel-64bit arch in Fedora (as far as I know), we should really block it and have a look... If it's an security-update, push it ASAP... If not, try to fix it or find someone who can fix it. There are usually people out there willing to help. -of From Axel.Thimm at ATrpms.net Mon Aug 6 20:21:18 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 6 Aug 2007 22:21:18 +0200 Subject: Make ppc64 secondary arch - don't block builds (was: Dealing with ppc64 BRs) In-Reply-To: <20070806110957.03e4e743@weaponx.rchland.ibm.com> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> <20070806130144.GN18009@puariko.nirvana> <20070806081108.4346141c@weaponx.rchland.ibm.com> <20070806143528.GA15391@puariko.nirvana> <20070806094648.7fb586e9@weaponx.rchland.ibm.com> <20070806151156.GD15391@puariko.nirvana> <20070806110957.03e4e743@weaponx.rchland.ibm.com> Message-ID: <20070806202118.GC23470@puariko.nirvana> On Mon, Aug 06, 2007 at 11:09:57AM -0500, Josh Boyer wrote: > On Mon, 6 Aug 2007 17:11:56 +0200 > Axel Thimm wrote: > > > On Mon, Aug 06, 2007 at 09:46:48AM -0500, Josh Boyer wrote: > > > ARM is not an official secondary arch to my knowledge. The Fedora > > > buildsystem isn't able to handle secondary arch stuff yet. And I > > > suspect SPARC will be there first anyway. > > > > Didn't fesco vote on arm already on June the 12th? > > No. On July 12, we approved the Secondary arch proposal in general. I didn't make that up ... * Board approves and welcomes ARM as a secondary architecture > We didn't approve any architectures as official secondary arches. It > would be pointless to do so, since the buildsystem isn't setup yet. The same board decided shortly before that once there is another secondary arch besides ppc they would both be treated as such. So on June 12 the boards decided that ppc and arm are secondary arches. (Yes, I mistaked fesco for the board in my original quote, so maybe your talking about fesco and I'm talking about the board, board wins ;) -- 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 Aug 6 20:22:50 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 6 Aug 2007 16:22:50 -0400 (EDT) Subject: Package EVR problems in Fedora 2007-08-06 Message-ID: <20070806202250.DEDFC152131@buildsys.fedoraproject.org> Axel.Thimm AT ATrpms.net: mediawiki F7-updates > F8 (0:1.9.3-34.0.2.fc7 > 0:1.9.2-33.fc7) smart FE6 > F7-updates (0:0.50-47.fc6 > 0:0.50-46.fc7) FE6 > F8 (0:0.50-47.fc6 > 0:0.50-46.fc8) alexl AT redhat.com: xdg-user-dirs F7-updates > F8 (0:0.8-3.fc7 > 0:0.8-2.fc8) belegdol AT gmail.com: gchempaint F7-updates-testing > F8 (0:0.8.2-2.fc7 > 0:0.6.9-1.fc7) gnome-chemistry-utils F7-updates-testing > F8 (0:0.8.2-3.fc7 > 0:0.8.2-2.fc8) bos AT serpentine.com: gtk2hs FE6 > F8 (0:0.9.12-1.fc6 > 0:0.9.11-4.fc7) F7-updates > F8 (0:0.9.12-1.fc7 > 0:0.9.11-4.fc7) caillon AT redhat.com: thunderbird F7-updates-testing > F8 (0:2.0.0.5-2.fc7 > 0:2.0.0.0-3.fc8) cweyl AT alumni.drew.edu: perl-Algorithm-C3 FE5 > F7 (0:0.07-1.fc5 > 0:0.06-1.fc7) FE6 > F7 (0:0.07-1.fc6 > 0:0.06-1.fc7) perl-CGI-Ex FE5 > F7 (0:2.13-1.fc5 > 0:2.12-1.fc7) FE6 > F7 (0:2.13-1.fc6 > 0:2.12-1.fc7) perl-Class-C3 FE5 > F7 (0:0.18-1.fc5 > 0:0.14-1.fc6) FE6 > F7 (0:0.18-1.fc6 > 0:0.14-1.fc6) perl-Class-C3-XS FE5 > F7 (0:0.06-1.fc5 > 0:0.04-1.fc7) FE6 > F7 (0:0.06-1.fc6 > 0:0.04-1.fc7) perl-Class-Data-Accessor FE5 > F7 (0:0.04001-1.fc5 > 0:0.04000-3.fc7) FE6 > F7 (0:0.04001-1.fc6 > 0:0.04000-3.fc7) perl-Class-MOP FE5 > F7 (0:0.38-1.fc5 > 0:0.37-1.fc7) FE6 > F7 (0:0.38-1.fc6 > 0:0.37-1.fc7) perl-Data-Alias FE5 > F7 (0:1.05-1.fc5 > 0:1.04-1.fc7) FE6 > F7 (0:1.05-1.fc6 > 0:1.04-1.fc7) perl-Event FE6 > F7 (0:1.09-1.fc6 > 0:1.08-1.fc7) perl-Gtk2-Notify FE6 > F7 (0:0.03-1.fc6 > 0:0.02-4.fc7) perl-Gtk2-TrayIcon FE5 > F7 (0:0.06-1.fc5 > 0:0.03-3.fc6) FE6 > F7 (0:0.06-1.fc6 > 0:0.03-3.fc6) perl-JSON-XS FE5 > F7 (0:1.22-1.fc5 > 0:1.21-3.fc7) FE6 > F7 (0:1.22-1.fc6 > 0:1.21-3.fc7) perl-Moose FE5 > F7 (0:0.22-1.fc5 > 0:0.21-1.fc7) FE6 > F7 (0:0.22-1.fc6 > 0:0.21-1.fc7) perl-POE-Component-Server-SOAP FE5 > F7 (0:1.11-1.fc5 > 0:1.10-1.fc6) FE6 > F7 (0:1.11-1.fc6 > 0:1.10-1.fc6) perl-POE-Component-SimpleDBI FE5 > F7 (0:1.16-1.fc5 > 0:1.15-1.fc6) FE6 > F7 (0:1.16-1.fc6 > 0:1.15-1.fc6) perl-POE-Component-SSLify FE5 > F7 (0:0.08-1.fc5 > 0:0.07-1.fc7) FE6 > F7 (0:0.08-1.fc6 > 0:0.07-1.fc7) perl-Sub-Exporter FE5 > F7 (0:0.974-1.fc5 > 0:0.972-1.fc7) FE6 > F7 (0:0.974-1.fc6 > 0:0.972-1.fc7) davidz AT redhat.com: dbus-python F7-updates-testing > F8 (0:0.82.0-2.fc7 > 0:0.82.0-1.fc8) redhat-artwork F7-updates > F8 (0:7.0.0-11.fc7 > 0:7.0.0-10.fc8) devrim AT commandprompt.com: postgresql-pgpool FE6 > F7 (0:3.4-1.fc6 > 0:3.2-1.fc7) postgresql-pgpool-II FE6 > F7-updates (0:1.2-1.fc6 > 0:1.1.1-1.fc7) ed AT eh3.com: scrip FE6 > F7 (0:1.4-7.fc6 > 0:1.4-6.fc6) FE6 > F8 (0:1.4-7.fc6 > 0:1.4-6.fc6) enrico.scholz AT informatik.tu-chemnitz.de: clamav F7-updates-testing > F8 (0:0.91.1-1.fc7 > 0:0.91.1-0.fc8) fedora-usermgmt FE6 > F7 (0:0.10-1.fc6 > 0:0.9-2.fc7) libtasn1 FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE5 > F8 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE6 > F7 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) FE6 > F8 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) mimetic FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7) FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7) util-vserver FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7) FE6 > F7 (0:0.30.213-2.fc6 > 0:0.30.212-3.fc7) xmlrpc-c FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7) FE6 > F7 (0:1.06.16-1.fc6 > 0:1.06.11-2.fc7) foolish AT guezz.net: gtranslator F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8) perl-Net-Libdnet F7-updates > F8 (0:0.01-3.fc7.1 > 0:0.01-2.fc8) perl-Nmap-Parser F7-updates > F8 (0:1.05-4.fc7 > 0:1.05-3.fc8) hellwolf.misty AT gmail.com: fuse-convmvfs FE6 > F8 (0:0.2.4-2.fc6 > 0:0.2.4-1.fc8) F7-updates > F8 (0:0.2.4-3.fc7 > 0:0.2.4-1.fc8) jakub AT redhat.com: gcc FC6-updates > F7 (0:4.1.2-13.fc6 > 0:4.1.2-12) jeff AT ocjtech.us: jrtplib FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) jjohnstn AT redhat.com: eclipse-cdt FC6-updates > F8 (1:3.1.2-4.fc6 > 1:3.1.2-3.fc7) F7-updates-testing > F8 (1:3.1.2-6.fc7 > 1:3.1.2-3.fc7) jonathan.underwood AT gmail.com: emacs-auctex FE6 > F7 (0:11.84-3.fc6 > 0:11.84-2.fc7) emacs-common-muse FE6 > F7-updates (0:3.03-4.fc6 > 0:3.03-3.fc7) lemenkov AT gmail.com: stratagus FE6 > F7 (0:2.2.4-1.fc6 > 0:2.2.3-1.fc7) lxtnow AT gmail.com: gammu F7-updates-testing > F8 (0:1.12.92-1.fc7 > 0:1.11.0-1.fc8) specto FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8) F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8) meme AT daughtersoftiresias.org: fortune-firefly FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6) FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6) mgarski AT post.pl: smb4k FE6 > F8 (0:0.8.4-1.fc6 > 0:0.8.3-1.fc7) F7-updates > F8 (0:0.8.4-1.fc7 > 0:0.8.3-1.fc7) mikeb AT redhat.com: python-cheetah FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) FE6 > F8 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) nhorman AT redhat.com: irqbalance FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6) FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7) FC5-updates > F8 (2:0.55-4.fc5 > 2:0.55-3.fc8) paul AT xelerance.com: xl2tpd FE6 > F7 (0:1.1.11-2.fc6 > 0:1.1.09-1.fc7) pawsa AT theochem.kth.se: balsa F7-updates > F8 (0:2.3.17-2.fc7 > 0:2.3.17-1.fc8) rc040203 AT freenet.de: perl-Algorithm-Dependency FE6 > F7 (0:1.103-1.fc6 > 0:1.102-2.fc6) perl-DBIx-DBSchema FE6 > F7 (0:0.33-1.fc6 > 0:0.32-1.fc7) perl-File-Remove FE6 > F7 (0:0.37-1.fc6 > 0:0.34-1.fc7) perl-Params-Util FE5 > F7 (0:0.25-1.fc5 > 0:0.24-1.fc7) FE6 > F7 (0:0.25-1.fc6 > 0:0.24-1.fc7) perl-Want FE6 > F7 (0:0.15-1.fc6 > 0:0.14-1.fc7) rcritten AT redhat.com: jss FE6 > F7-updates (0:4.2.5-1.fc6 > 0:4.2.4-6.fc7) rdieter AT math.unl.edu: kdeartwork-extras FE6 > F7 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) FE6 > F8 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) maxima FE5 > F7-updates (0:5.12.0-3.fc5 > 0:5.12.0-2.fc7) FE6 > F7-updates (0:5.12.0-3.fc6 > 0:5.12.0-2.fc7) sandmann AT redhat.com: libgtop2 FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7) splinux AT fedoraproject.org: lostirc FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7) FE6 > F8 (0:0.4.6-3.fc6 > 0:0.4.6-2.fc8) than AT redhat.com: kdemultimedia FC6-updates > F7-updates (6:3.5.7-1.fc6 > 6:3.5.7-0.1.fc7) kdepim F7-updates > F8 (6:3.5.7-3.fc7 > 6:3.5.7-2.fc8) veillard AT redhat.com: libxml2 FC6-updates > F8 (0:2.6.29-1.fc6 > 0:2.6.29-1) F7-updates > F8 (0:2.6.29-1.fc7 > 0:2.6.29-1) wolters.liste AT gmx.net: speedcrunch FE6 > F7 (0:0.8-4.fc6 > 0:0.7-1.fc7) ---------------------------------------------------------------------- balsa: pawsa AT theochem.kth.se F7-updates > F8 (0:2.3.17-2.fc7 > 0:2.3.17-1.fc8) clamav: enrico.scholz AT informatik.tu-chemnitz.de F7-updates-testing > F8 (0:0.91.1-1.fc7 > 0:0.91.1-0.fc8) dbus-python: davidz AT redhat.com F7-updates-testing > F8 (0:0.82.0-2.fc7 > 0:0.82.0-1.fc8) eclipse-cdt: jjohnstn AT redhat.com FC6-updates > F8 (1:3.1.2-4.fc6 > 1:3.1.2-3.fc7) F7-updates-testing > F8 (1:3.1.2-6.fc7 > 1:3.1.2-3.fc7) emacs-auctex: jonathan.underwood AT gmail.com FE6 > F7 (0:11.84-3.fc6 > 0:11.84-2.fc7) emacs-common-muse: jonathan.underwood AT gmail.com FE6 > F7-updates (0:3.03-4.fc6 > 0:3.03-3.fc7) fedora-usermgmt: enrico.scholz AT informatik.tu-chemnitz.de FE6 > F7 (0:0.10-1.fc6 > 0:0.9-2.fc7) fortune-firefly: meme AT daughtersoftiresias.org FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6) FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6) fuse-convmvfs: hellwolf.misty AT gmail.com FE6 > F8 (0:0.2.4-2.fc6 > 0:0.2.4-1.fc8) F7-updates > F8 (0:0.2.4-3.fc7 > 0:0.2.4-1.fc8) gammu: lxtnow AT gmail.com F7-updates-testing > F8 (0:1.12.92-1.fc7 > 0:1.11.0-1.fc8) gcc: jakub AT redhat.com FC6-updates > F7 (0:4.1.2-13.fc6 > 0:4.1.2-12) gchempaint: belegdol AT gmail.com F7-updates-testing > F8 (0:0.8.2-2.fc7 > 0:0.6.9-1.fc7) gnome-chemistry-utils: belegdol AT gmail.com F7-updates-testing > F8 (0:0.8.2-3.fc7 > 0:0.8.2-2.fc8) gtk2hs: bos AT serpentine.com FE6 > F8 (0:0.9.12-1.fc6 > 0:0.9.11-4.fc7) F7-updates > F8 (0:0.9.12-1.fc7 > 0:0.9.11-4.fc7) gtranslator: foolish AT guezz.net F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8) irqbalance: nhorman AT redhat.com FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6) FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7) FC5-updates > F8 (2:0.55-4.fc5 > 2:0.55-3.fc8) jrtplib: jeff AT ocjtech.us FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) jss: rcritten AT redhat.com FE6 > F7-updates (0:4.2.5-1.fc6 > 0:4.2.4-6.fc7) kdeartwork-extras: rdieter AT math.unl.edu FE6 > F7 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) FE6 > F8 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) kdemultimedia: than AT redhat.com FC6-updates > F7-updates (6:3.5.7-1.fc6 > 6:3.5.7-0.1.fc7) kdepim: than AT redhat.com F7-updates > F8 (6:3.5.7-3.fc7 > 6:3.5.7-2.fc8) libgtop2: sandmann AT redhat.com FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7) libtasn1: enrico.scholz AT informatik.tu-chemnitz.de FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE5 > F8 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE6 > F7 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) FE6 > F8 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) libxml2: veillard AT redhat.com FC6-updates > F8 (0:2.6.29-1.fc6 > 0:2.6.29-1) F7-updates > F8 (0:2.6.29-1.fc7 > 0:2.6.29-1) lostirc: splinux AT fedoraproject.org FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7) FE6 > F8 (0:0.4.6-3.fc6 > 0:0.4.6-2.fc8) maxima: rdieter AT math.unl.edu FE5 > F7-updates (0:5.12.0-3.fc5 > 0:5.12.0-2.fc7) FE6 > F7-updates (0:5.12.0-3.fc6 > 0:5.12.0-2.fc7) mediawiki: Axel.Thimm AT ATrpms.net F7-updates > F8 (0:1.9.3-34.0.2.fc7 > 0:1.9.2-33.fc7) mimetic: enrico.scholz AT informatik.tu-chemnitz.de FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7) FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7) perl-Algorithm-C3: cweyl AT alumni.drew.edu FE5 > F7 (0:0.07-1.fc5 > 0:0.06-1.fc7) FE6 > F7 (0:0.07-1.fc6 > 0:0.06-1.fc7) perl-Algorithm-Dependency: rc040203 AT freenet.de FE6 > F7 (0:1.103-1.fc6 > 0:1.102-2.fc6) perl-CGI-Ex: cweyl AT alumni.drew.edu FE5 > F7 (0:2.13-1.fc5 > 0:2.12-1.fc7) FE6 > F7 (0:2.13-1.fc6 > 0:2.12-1.fc7) perl-Class-C3: cweyl AT alumni.drew.edu FE5 > F7 (0:0.18-1.fc5 > 0:0.14-1.fc6) FE6 > F7 (0:0.18-1.fc6 > 0:0.14-1.fc6) perl-Class-C3-XS: cweyl AT alumni.drew.edu FE5 > F7 (0:0.06-1.fc5 > 0:0.04-1.fc7) FE6 > F7 (0:0.06-1.fc6 > 0:0.04-1.fc7) perl-Class-Data-Accessor: cweyl AT alumni.drew.edu FE5 > F7 (0:0.04001-1.fc5 > 0:0.04000-3.fc7) FE6 > F7 (0:0.04001-1.fc6 > 0:0.04000-3.fc7) perl-Class-MOP: cweyl AT alumni.drew.edu FE5 > F7 (0:0.38-1.fc5 > 0:0.37-1.fc7) FE6 > F7 (0:0.38-1.fc6 > 0:0.37-1.fc7) perl-Data-Alias: cweyl AT alumni.drew.edu FE5 > F7 (0:1.05-1.fc5 > 0:1.04-1.fc7) FE6 > F7 (0:1.05-1.fc6 > 0:1.04-1.fc7) perl-DBIx-DBSchema: rc040203 AT freenet.de FE6 > F7 (0:0.33-1.fc6 > 0:0.32-1.fc7) perl-Event: cweyl AT alumni.drew.edu FE6 > F7 (0:1.09-1.fc6 > 0:1.08-1.fc7) perl-File-Remove: rc040203 AT freenet.de FE6 > F7 (0:0.37-1.fc6 > 0:0.34-1.fc7) perl-Gtk2-Notify: cweyl AT alumni.drew.edu FE6 > F7 (0:0.03-1.fc6 > 0:0.02-4.fc7) perl-Gtk2-TrayIcon: cweyl AT alumni.drew.edu FE5 > F7 (0:0.06-1.fc5 > 0:0.03-3.fc6) FE6 > F7 (0:0.06-1.fc6 > 0:0.03-3.fc6) perl-JSON-XS: cweyl AT alumni.drew.edu FE5 > F7 (0:1.22-1.fc5 > 0:1.21-3.fc7) FE6 > F7 (0:1.22-1.fc6 > 0:1.21-3.fc7) perl-Moose: cweyl AT alumni.drew.edu FE5 > F7 (0:0.22-1.fc5 > 0:0.21-1.fc7) FE6 > F7 (0:0.22-1.fc6 > 0:0.21-1.fc7) perl-Net-Libdnet: foolish AT guezz.net F7-updates > F8 (0:0.01-3.fc7.1 > 0:0.01-2.fc8) perl-Nmap-Parser: foolish AT guezz.net F7-updates > F8 (0:1.05-4.fc7 > 0:1.05-3.fc8) perl-Params-Util: rc040203 AT freenet.de FE5 > F7 (0:0.25-1.fc5 > 0:0.24-1.fc7) FE6 > F7 (0:0.25-1.fc6 > 0:0.24-1.fc7) perl-POE-Component-Server-SOAP: cweyl AT alumni.drew.edu FE5 > F7 (0:1.11-1.fc5 > 0:1.10-1.fc6) FE6 > F7 (0:1.11-1.fc6 > 0:1.10-1.fc6) perl-POE-Component-SimpleDBI: cweyl AT alumni.drew.edu FE5 > F7 (0:1.16-1.fc5 > 0:1.15-1.fc6) FE6 > F7 (0:1.16-1.fc6 > 0:1.15-1.fc6) perl-POE-Component-SSLify: cweyl AT alumni.drew.edu FE5 > F7 (0:0.08-1.fc5 > 0:0.07-1.fc7) FE6 > F7 (0:0.08-1.fc6 > 0:0.07-1.fc7) perl-Sub-Exporter: cweyl AT alumni.drew.edu FE5 > F7 (0:0.974-1.fc5 > 0:0.972-1.fc7) FE6 > F7 (0:0.974-1.fc6 > 0:0.972-1.fc7) perl-Want: rc040203 AT freenet.de FE6 > F7 (0:0.15-1.fc6 > 0:0.14-1.fc7) postgresql-pgpool: devrim AT commandprompt.com FE6 > F7 (0:3.4-1.fc6 > 0:3.2-1.fc7) postgresql-pgpool-II: devrim AT commandprompt.com FE6 > F7-updates (0:1.2-1.fc6 > 0:1.1.1-1.fc7) python-cheetah: mikeb AT redhat.com FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) FE6 > F8 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) redhat-artwork: davidz AT redhat.com F7-updates > F8 (0:7.0.0-11.fc7 > 0:7.0.0-10.fc8) scrip: ed AT eh3.com FE6 > F7 (0:1.4-7.fc6 > 0:1.4-6.fc6) FE6 > F8 (0:1.4-7.fc6 > 0:1.4-6.fc6) smart: Axel.Thimm AT ATrpms.net FE6 > F7-updates (0:0.50-47.fc6 > 0:0.50-46.fc7) FE6 > F8 (0:0.50-47.fc6 > 0:0.50-46.fc8) smb4k: mgarski AT post.pl FE6 > F8 (0:0.8.4-1.fc6 > 0:0.8.3-1.fc7) F7-updates > F8 (0:0.8.4-1.fc7 > 0:0.8.3-1.fc7) specto: lxtnow AT gmail.com FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8) F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8) speedcrunch: wolters.liste AT gmx.net FE6 > F7 (0:0.8-4.fc6 > 0:0.7-1.fc7) stratagus: lemenkov AT gmail.com FE6 > F7 (0:2.2.4-1.fc6 > 0:2.2.3-1.fc7) thunderbird: caillon AT redhat.com F7-updates-testing > F8 (0:2.0.0.5-2.fc7 > 0:2.0.0.0-3.fc8) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7) FE6 > F7 (0:0.30.213-2.fc6 > 0:0.30.212-3.fc7) xdg-user-dirs: alexl AT redhat.com F7-updates > F8 (0:0.8-3.fc7 > 0:0.8-2.fc8) xl2tpd: paul AT xelerance.com FE6 > F7 (0:1.1.11-2.fc6 > 0:1.1.09-1.fc7) xmlrpc-c: enrico.scholz AT informatik.tu-chemnitz.de FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7) FE6 > F7 (0:1.06.16-1.fc6 > 0:1.06.11-2.fc7) From Axel.Thimm at ATrpms.net Mon Aug 6 20:25:48 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 6 Aug 2007 22:25:48 +0200 Subject: Make ppc64 secondary arch - don't block builds (was: Dealing with ppc64 BRs) In-Reply-To: <20070806112446.0ad53afe@ender> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> <20070806130144.GN18009@puariko.nirvana> <20070806081108.4346141c@weaponx.rchland.ibm.com> <20070806143528.GA15391@puariko.nirvana> <20070806094648.7fb586e9@weaponx.rchland.ibm.com> <20070806151156.GD15391@puariko.nirvana> <20070806112446.0ad53afe@ender> Message-ID: <20070806202548.GD23470@puariko.nirvana> On Mon, Aug 06, 2007 at 11:24:46AM -0400, Jesse Keating wrote: > But we're not talking about a secondary arch, we're talking about a > primary arch. Like it or not, ppc (and thus ppc64) is a primary arch > set and must addressed just like the other primary arches. Are you sure, check out http://fedoraproject.org/wiki/Board/Meetings/2007-06-12 Maybe someone should look again in the logs, the summary says: # PPC will remain a primary architecture until: 1. secondary arch process is finalized 2. there are no other secondary architectures # Board approves and welcomes ARM as a secondary architecture item 2. was already fulfilled by the same board meeting, so the above boils down to: # ppc and arm will become secondary archs once the infrastructure/process is in place So they already are secondary archs waiting for the implementation (which mainly means that koji doesn't tag task build failures for these archs as fatal, doesn't sound too difficult to implement). We now have the 1% gain for 100% pain situation the secondary arch proposal wanted to avoid. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Aug 6 20:38:14 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 6 Aug 2007 22:38:14 +0200 Subject: Make ppc64 secondary arch - don't block builds (was: Dealing with ppc64 BRs) In-Reply-To: <28075.1186415314@sss.pgh.pa.us> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> <20070806130144.GN18009@puariko.nirvana> <20070806081108.4346141c@weaponx.rchland.ibm.com> <20070806143528.GA15391@puariko.nirvana> <20070806094648.7fb586e9@weaponx.rchland.ibm.com> <20070806151156.GD15391@puariko.nirvana> <20070806112446.0ad53afe@ender> <28075.1186415314@sss.pgh.pa.us> Message-ID: <20070806203814.GE23470@puariko.nirvana> On Mon, Aug 06, 2007 at 11:48:34AM -0400, Tom Lane wrote: > Jesse Keating writes: > > But we're not talking about a secondary arch, we're talking about a > > primary arch. Like it or not, ppc (and thus ppc64) is a primary arch > > set and must addressed just like the other primary arches. > > I really find it troublesome that anyone thinks they shouldn't be > primary. If the only primary arches are x86/x86_64, then packagers will > basically not have any forcing function to make them worry about whether > the code is portable to any non-Intel platform. So by forcing packagers to rebuilding with ExclusiveArchs and users to redownload artificially bumped packages w/o any content changes you make anyonw worry about ppc support? I for one felt like this is a big PITA and was not motivated at all to find the ppc specific issues. > I think that at minimum we need a bigendian arch or two in the > primary set, just so that there's at least a token requirement for > portability. Why not add some 8bit arch to ensure even more portability? Or 31bits to make it at least useful? Let's worry about portability when the arch we want to port to appears and not use some archs to *practice* portability. > Else the secondary arches are *all* doomed to failure in the long > run. bof! -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Aug 6 20:45:46 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 6 Aug 2007 16:45:46 -0400 Subject: Make ppc64 secondary arch - don't block builds (was: Dealing with ppc64 BRs) In-Reply-To: <20070806202548.GD23470@puariko.nirvana> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> <20070806130144.GN18009@puariko.nirvana> <20070806081108.4346141c@weaponx.rchland.ibm.com> <20070806143528.GA15391@puariko.nirvana> <20070806094648.7fb586e9@weaponx.rchland.ibm.com> <20070806151156.GD15391@puariko.nirvana> <20070806112446.0ad53afe@ender> <20070806202548.GD23470@puariko.nirvana> Message-ID: <20070806164546.3707ee61@ender> On Mon, 6 Aug 2007 22:25:48 +0200 Axel Thimm wrote: > (which mainly means that koji doesn't tag task build failures for > these archs as fatal, doesn't sound too difficult to implement). Oh gee, thanks for completely missing the work needed here and trivializing all that we're trying to do. That's so helpful. Gee, why couldn't we have this done yesterday. It's so clear to me now. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Mon Aug 6 20:51:31 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 06 Aug 2007 16:51:31 -0400 Subject: Make ppc64 secondary arch - don't block builds (was: Dealing with ppc64 BRs) In-Reply-To: <20070806202118.GC23470@puariko.nirvana> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> <20070806130144.GN18009@puariko.nirvana> <20070806081108.4346141c@weaponx.rchland.ibm.com> <20070806143528.GA15391@puariko.nirvana> <20070806094648.7fb586e9@weaponx.rchland.ibm.com> <20070806151156.GD15391@puariko.nirvana> <20070806110957.03e4e743@weaponx.rchland.ibm.com> <20070806202118.GC23470@puariko.nirvana> Message-ID: <1186433491.3839.48.camel@dhcp67.install.boston.redhat.com> On Mon, 2007-08-06 at 22:21 +0200, Axel Thimm wrote: > The same board decided shortly before that once there is another > secondary arch besides ppc they would both be treated as such. I actually attended that meeting, and this is not what the board decided. They decided to defer the question of where ppc would land until another secondary arch was successfully implemented. Until then, it remains a primary arch. ~spot From Axel.Thimm at ATrpms.net Mon Aug 6 20:57:07 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 6 Aug 2007 22:57:07 +0200 Subject: Make ppc64 secondary arch - don't block builds (was: Dealing with ppc64 BRs) In-Reply-To: <20070806164546.3707ee61@ender> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> <20070806130144.GN18009@puariko.nirvana> <20070806081108.4346141c@weaponx.rchland.ibm.com> <20070806143528.GA15391@puariko.nirvana> <20070806094648.7fb586e9@weaponx.rchland.ibm.com> <20070806151156.GD15391@puariko.nirvana> <20070806112446.0ad53afe@ender> <20070806202548.GD23470@puariko.nirvana> <20070806164546.3707ee61@ender> Message-ID: <20070806205707.GG23470@puariko.nirvana> On Mon, Aug 06, 2007 at 04:45:46PM -0400, Jesse Keating wrote: > On Mon, 6 Aug 2007 22:25:48 +0200 > Axel Thimm wrote: > > > (which mainly means that koji doesn't tag task build failures for > > these archs as fatal, doesn't sound too difficult to implement). > > Oh gee, thanks for completely missing the work needed here and > trivializing all that we're trying to do. That's so helpful. Gee, why > couldn't we have this done yesterday. It's so clear to me now. I'm sorry, I didn't want to step on anybody's toes, but from the bird's view it does seem quite that trivial, yes. Wasn't that was "secondary arch" politely means? Allow the build to go to valhalla and have a SIG worry itself sick instead of all non-ppc users out here? Wasn't that the state of the build system before ppc64 entered as a primary arch? Implementation looks trivial, politics probably not. So take the above with your grain of salt. -- 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 Mon Aug 6 21:01:11 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 6 Aug 2007 16:01:11 -0500 Subject: Make ppc64 secondary arch - don't block builds (was: Dealing with ppc64 BRs) In-Reply-To: <1186433491.3839.48.camel@dhcp67.install.boston.redhat.com> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> <20070806130144.GN18009@puariko.nirvana> <20070806081108.4346141c@weaponx.rchland.ibm.com> <20070806143528.GA15391@puariko.nirvana> <20070806094648.7fb586e9@weaponx.rchland.ibm.com> <20070806151156.GD15391@puariko.nirvana> <20070806110957.03e4e743@weaponx.rchland.ibm.com> <20070806202118.GC23470@puariko.nirvana> <1186433491.3839.48.camel@dhcp67.install.boston.redhat.com> Message-ID: <20070806160111.4150821c@weaponx.rchland.ibm.com> On Mon, 06 Aug 2007 16:51:31 -0400 "Tom \"spot\" Callaway" wrote: > > On Mon, 2007-08-06 at 22:21 +0200, Axel Thimm wrote: > > The same board decided shortly before that once there is another > > secondary arch besides ppc they would both be treated as such. > > I actually attended that meeting, and this is not what the board > decided. > > They decided to defer the question of where ppc would land until another > secondary arch was successfully implemented. Until then, it remains a > primary arch. Right. And until the buildsys bits are in place, none of this matters. It's very simple. The concept of Secondary arches has been approved. The implementation of it doesn't yet exist. Until it can be technically achieved, the Board and ack whatever arches they want and it doesn't matter. josh From Axel.Thimm at ATrpms.net Mon Aug 6 21:01:30 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 6 Aug 2007 23:01:30 +0200 Subject: Make ppc64 secondary arch - don't block builds (was: Dealing with ppc64 BRs) In-Reply-To: <1186433491.3839.48.camel@dhcp67.install.boston.redhat.com> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> <20070806130144.GN18009@puariko.nirvana> <20070806081108.4346141c@weaponx.rchland.ibm.com> <20070806143528.GA15391@puariko.nirvana> <20070806094648.7fb586e9@weaponx.rchland.ibm.com> <20070806151156.GD15391@puariko.nirvana> <20070806110957.03e4e743@weaponx.rchland.ibm.com> <20070806202118.GC23470@puariko.nirvana> <1186433491.3839.48.camel@dhcp67.install.boston.redhat.com> Message-ID: <20070806210130.GH23470@puariko.nirvana> On Mon, Aug 06, 2007 at 04:51:31PM -0400, Tom spot Callaway wrote: > > On Mon, 2007-08-06 at 22:21 +0200, Axel Thimm wrote: > > The same board decided shortly before that once there is another > > secondary arch besides ppc they would both be treated as such. > > I actually attended that meeting, and this is not what the board > decided. OK, someone please fix the recap then: http://fedoraproject.org/wiki/Board/Meetings/2007-06-12 > They decided to defer the question of where ppc would land until another > secondary arch was successfully implemented. Until then, it remains a > primary arch. "PPC will remain a primary architecture until " I read it differently, but whoever has the logs and is empowered to fix the summary should do so. In this case take my request to finalize this topic. Unless a relevant arch is tagged as secondary *before* there is a mechanism to deal with secondary archs there will never be a secondary arch mechanism, and if all archs save themselves into the primary arch boat that way, we'll live forever in a catch22, e.g. we'll only have primary archs support ot no support at all. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Mon Aug 6 21:03:11 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 6 Aug 2007 16:03:11 -0500 Subject: Make ppc64 secondary arch - don't block builds (was: Dealing with ppc64 BRs) In-Reply-To: <20070806202548.GD23470@puariko.nirvana> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> <20070806130144.GN18009@puariko.nirvana> <20070806081108.4346141c@weaponx.rchland.ibm.com> <20070806143528.GA15391@puariko.nirvana> <20070806094648.7fb586e9@weaponx.rchland.ibm.com> <20070806151156.GD15391@puariko.nirvana> <20070806112446.0ad53afe@ender> <20070806202548.GD23470@puariko.nirvana> Message-ID: <20070806160311.32baf308@weaponx.rchland.ibm.com> On Mon, 6 Aug 2007 22:25:48 +0200 Axel Thimm wrote: > On Mon, Aug 06, 2007 at 11:24:46AM -0400, Jesse Keating wrote: > > But we're not talking about a secondary arch, we're talking about a > > primary arch. Like it or not, ppc (and thus ppc64) is a primary arch > > set and must addressed just like the other primary arches. > > Are you sure, check out > > http://fedoraproject.org/wiki/Board/Meetings/2007-06-12 > > Maybe someone should look again in the logs, the summary says: > > # PPC will remain a primary architecture until: > > 1. secondary arch process is finalized > 2. there are no other secondary architectures > > # Board approves and welcomes ARM as a secondary architecture > > item 2. was already fulfilled by the same board meeting, so the above > boils down to: > > # ppc and arm will become secondary archs once the > infrastructure/process is in place No. PPC may become a secondary arch once another secondary arch is up and running. E.g. ARM/SPARC are _operating_ successfully as a secondary arch. josh From katzj at redhat.com Mon Aug 6 21:14:08 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 06 Aug 2007 17:14:08 -0400 Subject: Font packages changes required for dropping chkfontpath/xfs In-Reply-To: <1185826371.2794.180.camel@localhost.localdomain> References: <1185821548.11086.9.camel@hinata.boston.redhat.com> <46AE3B7F.80903@ioa.s.u-tokyo.ac.jp> <1185823650.2794.177.camel@localhost.localdomain> <46AE43F7.1080201@ioa.s.u-tokyo.ac.jp> <1185826371.2794.180.camel@localhost.localdomain> Message-ID: <1186434848.20556.80.camel@erebor.boston.redhat.com> On Mon, 2007-07-30 at 16:12 -0400, Adam Jackson wrote: > On Tue, 2007-07-31 at 05:03 +0900, Mamoru Tasaka wrote: > > Adam Jackson wrote, at 07/31/2007 04:27 AM +9:00: > > > Seriously. What does a relative symlink win you here? > > > > As I said "from packaging issue", current Fedora's packaging policy is: > > --------------------------------------------------------------------------- > > $ rpmlint -I symlink-should-be-relative > > symlink-should-be-relative : > > Absolute symlinks are problematic eg. when working with chroot environments. > > --------------------------------------------------------------------------- > > This is merely an rpmlink complaint. Symlinks aren't mentioned in the > packaging policy at all. The chroot concern is real, though. And unless there's a really good reason for it, symlinks _should_ be relative. Even if all they have in common is /. Jeremy From tgl at redhat.com Mon Aug 6 23:32:13 2007 From: tgl at redhat.com (Tom Lane) Date: Mon, 06 Aug 2007 19:32:13 -0400 Subject: Font packages changes required for dropping chkfontpath/xfs In-Reply-To: <1186434848.20556.80.camel@erebor.boston.redhat.com> References: <1185821548.11086.9.camel@hinata.boston.redhat.com> <46AE3B7F.80903@ioa.s.u-tokyo.ac.jp> <1185823650.2794.177.camel@localhost.localdomain> <46AE43F7.1080201@ioa.s.u-tokyo.ac.jp> <1185826371.2794.180.camel@localhost.localdomain> <1186434848.20556.80.camel@erebor.boston.redhat.com> Message-ID: <4603.1186443133@sss.pgh.pa.us> Jeremy Katz writes: > On Mon, 2007-07-30 at 16:12 -0400, Adam Jackson wrote: >> This is merely an rpmlink complaint. Symlinks aren't mentioned in the >> packaging policy at all. > The chroot concern is real, though. And unless there's a really good > reason for it, symlinks _should_ be relative. Even if all they have in > common is /. Can you show an example where that actually helps? I can think of a number of cases where it'd be a bad idea, and none where it really solves a problem. I'm interested in this because I'm about to stick a symlink to /usr/share/zoneinfo into one of my packages, and I cannot see a good reason to spell it as ../../../../usr/share/zoneinfo. regards, tom lane From zaitcev at redhat.com Mon Aug 6 23:48:44 2007 From: zaitcev at redhat.com (Pete Zaitcev) Date: Mon, 6 Aug 2007 16:48:44 -0700 Subject: Font packages changes required for dropping chkfontpath/xfs In-Reply-To: <4603.1186443133@sss.pgh.pa.us> References: <1185821548.11086.9.camel@hinata.boston.redhat.com> <46AE3B7F.80903@ioa.s.u-tokyo.ac.jp> <1185823650.2794.177.camel@localhost.localdomain> <46AE43F7.1080201@ioa.s.u-tokyo.ac.jp> <1185826371.2794.180.camel@localhost.localdomain> <1186434848.20556.80.camel@erebor.boston.redhat.com> <4603.1186443133@sss.pgh.pa.us> Message-ID: <20070806164844.82853644.zaitcev@redhat.com> On Mon, 06 Aug 2007 19:32:13 -0400, Tom Lane wrote: > I'm interested in this because I'm about to stick a symlink to > /usr/share/zoneinfo into one of my packages, and I cannot see a good > reason to spell it as ../../../../usr/share/zoneinfo. The chroot itself is not affected. The problem is a chroot when it's NOT set up, but you run something in it, e.g. /mnt/rhel5/usr/bin/ls. Usually you learn not to use absolute links when manupulating NFS roots. But I think the worst surprise of the sort that I received was when I untarred something with somehting like (cd /mnt/badger/var/spool && tar xf -) and the cd target was an absolute symlink. Hilarity ensued. > I can think of a number of cases where [a relative symlink would] > be a bad idea, and none where it really solves a problem. I'd like to hear how a relative symlink can be a bad idea. It seems obvious to me that all symlinks should be relative, but equally obviously I'm forgetting something. What do you have in mind? -- Pete From tgl at redhat.com Tue Aug 7 00:00:00 2007 From: tgl at redhat.com (Tom Lane) Date: Mon, 06 Aug 2007 20:00:00 -0400 Subject: Font packages changes required for dropping chkfontpath/xfs In-Reply-To: <20070806164844.82853644.zaitcev@redhat.com> References: <1185821548.11086.9.camel@hinata.boston.redhat.com> <46AE3B7F.80903@ioa.s.u-tokyo.ac.jp> <1185823650.2794.177.camel@localhost.localdomain> <46AE43F7.1080201@ioa.s.u-tokyo.ac.jp> <1185826371.2794.180.camel@localhost.localdomain> <1186434848.20556.80.camel@erebor.boston.redhat.com> <4603.1186443133@sss.pgh.pa.us> <20070806164844.82853644.zaitcev@redhat.com> Message-ID: <4942.1186444800@sss.pgh.pa.us> Pete Zaitcev writes: > On Mon, 06 Aug 2007 19:32:13 -0400, Tom Lane wrote: >> I can think of a number of cases where [a relative symlink would] >> be a bad idea, and none where it really solves a problem. > I'd like to hear how a relative symlink can be a bad idea. > It seems obvious to me that all symlinks should be relative, > but equally obviously I'm forgetting something. What do you have > in mind? Well, aside from the PITA factor of setting it up (how do you determine the number of ".."s to use), there are a couple of things that make me not want to do it that way: 1. Can't move the referencing package's contents around, at least not up or down any directory levels. 2. The symlink will be actively wrong while doing the RPM build/install, because it won't account for the BuildRoot: directories. I don't currently try to do any active testing on the post-%install fileset, but if I did it would not work with a relative symlink. The counterexamples you mention are interesting but don't seem particularly relevant to a read-only reference to a standard system directory. I entirely agree that relative symlinks are appropriate for cross-references between parts of a single software package. I'm not convinced about references to system components that are unrelated to the package doing the referencing. regards, tom lane From jkeating at redhat.com Tue Aug 7 00:00:00 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 6 Aug 2007 20:00:00 -0400 Subject: Font packages changes required for dropping chkfontpath/xfs In-Reply-To: <4942.1186444800@sss.pgh.pa.us> References: <1185821548.11086.9.camel@hinata.boston.redhat.com> <46AE3B7F.80903@ioa.s.u-tokyo.ac.jp> <1185823650.2794.177.camel@localhost.localdomain> <46AE43F7.1080201@ioa.s.u-tokyo.ac.jp> <1185826371.2794.180.camel@localhost.localdomain> <1186434848.20556.80.camel@erebor.boston.redhat.com> <4603.1186443133@sss.pgh.pa.us> <20070806164844.82853644.zaitcev@redhat.com> <4942.1186444800@sss.pgh.pa.us> Message-ID: <20070806200000.6ae42c64@ender> On Mon, 06 Aug 2007 20:00:00 -0400 Tom Lane wrote: > 2. The symlink will be actively wrong while doing the RPM > build/install, because it won't account for the BuildRoot: > directories. I don't currently try to do any active testing on the > post-%install fileset, but if I did it would not work with a relative > symlink. This is false. In fact, with relative, they'll be right more often than not. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tgl at redhat.com Tue Aug 7 00:48:25 2007 From: tgl at redhat.com (Tom Lane) Date: Mon, 06 Aug 2007 20:48:25 -0400 Subject: Font packages changes required for dropping chkfontpath/xfs In-Reply-To: <20070806200000.6ae42c64@ender> References: <1185821548.11086.9.camel@hinata.boston.redhat.com> <46AE3B7F.80903@ioa.s.u-tokyo.ac.jp> <1185823650.2794.177.camel@localhost.localdomain> <46AE43F7.1080201@ioa.s.u-tokyo.ac.jp> <1185826371.2794.180.camel@localhost.localdomain> <1186434848.20556.80.camel@erebor.boston.redhat.com> <4603.1186443133@sss.pgh.pa.us> <20070806164844.82853644.zaitcev@redhat.com> <4942.1186444800@sss.pgh.pa.us> <20070806200000.6ae42c64@ender> Message-ID: <5919.1186447705@sss.pgh.pa.us> Jesse Keating writes: > Tom Lane wrote: >> 2. The symlink will be actively wrong while doing the RPM >> build/install, because it won't account for the BuildRoot: >> directories. > This is false. In fact, with relative, they'll be right more often > than not. Hmm? To get down to cases, the symlink I need is going to live at /usr/share/pgsql/timezone (barring relocation of the package, something I'd someday like to have work), and needs to point to /usr/share/zoneinfo. I believe you're suggesting that I create it as ../zoneinfo. That is not going to work when it's sitting in /var/tmp/postgresql-something-root/usr/share/pgsql, because the zoneinfo files are not part of my package; there will not be anything at /var/tmp/postgresql-something-root/usr/share/zoneinfo. If they *were* part of my package then you'd be correct. regards, tom lane From katzj at redhat.com Tue Aug 7 00:52:14 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 06 Aug 2007 20:52:14 -0400 Subject: Font packages changes required for dropping chkfontpath/xfs In-Reply-To: <4603.1186443133@sss.pgh.pa.us> References: <1185821548.11086.9.camel@hinata.boston.redhat.com> <46AE3B7F.80903@ioa.s.u-tokyo.ac.jp> <1185823650.2794.177.camel@localhost.localdomain> <46AE43F7.1080201@ioa.s.u-tokyo.ac.jp> <1185826371.2794.180.camel@localhost.localdomain> <1186434848.20556.80.camel@erebor.boston.redhat.com> <4603.1186443133@sss.pgh.pa.us> Message-ID: <1186447934.3128.1.camel@localhost.localdomain> On Mon, 2007-08-06 at 19:32 -0400, Tom Lane wrote: > Jeremy Katz writes: > > On Mon, 2007-07-30 at 16:12 -0400, Adam Jackson wrote: > >> This is merely an rpmlink complaint. Symlinks aren't mentioned in the > >> packaging policy at all. > > > The chroot concern is real, though. And unless there's a really good > > reason for it, symlinks _should_ be relative. Even if all they have in > > common is /. > > Can you show an example where that actually helps? I can think of a > number of cases where it'd be a bad idea, and none where it really > solves a problem. The case where your chroot is fully formed, but the system outside is something entirely different. The installer environment being one good example where this has bitten in the past :-) To the point where we actually have checks to avoid problems on upgrades looking at certain things and making sure that they're relative rather than absolute symlinks Jeremy From tgl at redhat.com Tue Aug 7 01:14:38 2007 From: tgl at redhat.com (Tom Lane) Date: Mon, 06 Aug 2007 21:14:38 -0400 Subject: Font packages changes required for dropping chkfontpath/xfs In-Reply-To: <1186447934.3128.1.camel@localhost.localdomain> References: <1185821548.11086.9.camel@hinata.boston.redhat.com> <46AE3B7F.80903@ioa.s.u-tokyo.ac.jp> <1185823650.2794.177.camel@localhost.localdomain> <46AE43F7.1080201@ioa.s.u-tokyo.ac.jp> <1185826371.2794.180.camel@localhost.localdomain> <1186434848.20556.80.camel@erebor.boston.redhat.com> <4603.1186443133@sss.pgh.pa.us> <1186447934.3128.1.camel@localhost.localdomain> Message-ID: <6594.1186449278@sss.pgh.pa.us> Jeremy Katz writes: > On Mon, 2007-08-06 at 19:32 -0400, Tom Lane wrote: >> Can you show an example where that actually helps? I can think of a >> number of cases where it'd be a bad idea, and none where it really >> solves a problem. > The case where your chroot is fully formed, but the system outside is > something entirely different. The installer environment being one good > example where this has bitten in the past :-) OK, but if the system outside is incompatible then it will fail to execute code that belongs inside the chroot anyway, no? regards, tom lane From jkeating at redhat.com Tue Aug 7 01:13:55 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 6 Aug 2007 21:13:55 -0400 Subject: Font packages changes required for dropping chkfontpath/xfs In-Reply-To: <5919.1186447705@sss.pgh.pa.us> References: <1185821548.11086.9.camel@hinata.boston.redhat.com> <46AE3B7F.80903@ioa.s.u-tokyo.ac.jp> <1185823650.2794.177.camel@localhost.localdomain> <46AE43F7.1080201@ioa.s.u-tokyo.ac.jp> <1185826371.2794.180.camel@localhost.localdomain> <1186434848.20556.80.camel@erebor.boston.redhat.com> <4603.1186443133@sss.pgh.pa.us> <20070806164844.82853644.zaitcev@redhat.com> <4942.1186444800@sss.pgh.pa.us> <20070806200000.6ae42c64@ender> <5919.1186447705@sss.pgh.pa.us> Message-ID: <20070806211355.7f751fb5@ender> On Mon, 06 Aug 2007 20:48:25 -0400 Tom Lane wrote: > /usr/share/pgsql/timezone (barring relocation of the package, > something I'd someday like to have work), and needs to point to > /usr/share/zoneinfo. I believe you're suggesting that I create it as > ../zoneinfo. That is not going to work when it's sitting in > /var/tmp/postgresql-something-root/usr/share/pgsql, because the > zoneinfo files are not part of my package; there will not be anything > at /var/tmp/postgresql-something-root/usr/share/zoneinfo. If they > *were* part of my package then you'd be correct. Surely your package requires the whatever package provides the zoneinfo files, so that when your package is installed into a chroot it doesn't matter if I'm /inside/ the chroot or not, your symlink will always point to the right target, not something /outside/ the chroot. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Tue Aug 7 01:45:39 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 06 Aug 2007 21:45:39 -0400 Subject: Font packages changes required for dropping chkfontpath/xfs In-Reply-To: <6594.1186449278@sss.pgh.pa.us> References: <1185821548.11086.9.camel@hinata.boston.redhat.com> <46AE3B7F.80903@ioa.s.u-tokyo.ac.jp> <1185823650.2794.177.camel@localhost.localdomain> <46AE43F7.1080201@ioa.s.u-tokyo.ac.jp> <1185826371.2794.180.camel@localhost.localdomain> <1186434848.20556.80.camel@erebor.boston.redhat.com> <4603.1186443133@sss.pgh.pa.us> <1186447934.3128.1.camel@localhost.localdomain> <6594.1186449278@sss.pgh.pa.us> Message-ID: <1186451139.3128.6.camel@localhost.localdomain> On Mon, 2007-08-06 at 21:14 -0400, Tom Lane wrote: > Jeremy Katz writes: > > On Mon, 2007-08-06 at 19:32 -0400, Tom Lane wrote: > >> Can you show an example where that actually helps? I can think of a > >> number of cases where it'd be a bad idea, and none where it really > >> solves a problem. > > > The case where your chroot is fully formed, but the system outside is > > something entirely different. The installer environment being one good > > example where this has bitten in the past :-) > > OK, but if the system outside is incompatible then it will fail to > execute code that belongs inside the chroot anyway, no? Not necessarily. The installer has the same kernel, libraries... just not always where you think they are (or, in some cases, a minimal set) Jeremy From tgl at redhat.com Tue Aug 7 02:02:59 2007 From: tgl at redhat.com (Tom Lane) Date: Mon, 06 Aug 2007 22:02:59 -0400 Subject: Font packages changes required for dropping chkfontpath/xfs In-Reply-To: <1186451139.3128.6.camel@localhost.localdomain> References: <1185821548.11086.9.camel@hinata.boston.redhat.com> <46AE3B7F.80903@ioa.s.u-tokyo.ac.jp> <1185823650.2794.177.camel@localhost.localdomain> <46AE43F7.1080201@ioa.s.u-tokyo.ac.jp> <1185826371.2794.180.camel@localhost.localdomain> <1186434848.20556.80.camel@erebor.boston.redhat.com> <4603.1186443133@sss.pgh.pa.us> <1186447934.3128.1.camel@localhost.localdomain> <6594.1186449278@sss.pgh.pa.us> <1186451139.3128.6.camel@localhost.localdomain> Message-ID: <7666.1186452179@sss.pgh.pa.us> Jeremy Katz writes: > On Mon, 2007-08-06 at 21:14 -0400, Tom Lane wrote: >> OK, but if the system outside is incompatible then it will fail to >> execute code that belongs inside the chroot anyway, no? > Not necessarily. The installer has the same kernel, libraries... just > not always where you think they are (or, in some cases, a minimal set) Hm, fair. Still I'm not aware of anyone wanting to run Postgres during install. The $64 concern I have here is the one I mentioned in passing: package relocatability. The upstream Postgres package can be pushed around to different installation locations because it goes out of its way to make all its internal dependencies be relative. If I stick a relative symlink to an unrelated fileset into it, I break that. While I realize that relocatable RPMs aren't popular, I don't want to permanently throw away any possibility of making the postgresql RPM relocatable. This is a hot-button issue for me because installing multiple versions of Postgres at once is a tremendous help for people doing major version upgrades of their database. Debian can do that today (has done so for awhile) and we are at a competitive disadvantage because we can't. regards, tom lane From dwmw2 at infradead.org Tue Aug 7 05:19:29 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 07 Aug 2007 13:19:29 +0800 Subject: Make ppc64 secondary arch - don't block builds (was: Dealing with ppc64 BRs) In-Reply-To: <20070806122937.78bfcdd9@ender> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> <20070806130144.GN18009@puariko.nirvana> <20070806081108.4346141c@weaponx.rchland.ibm.com> <20070806143528.GA15391@puariko.nirvana> <20070806094648.7fb586e9@weaponx.rchland.ibm.com> <20070806151156.GD15391@puariko.nirvana> <20070806112446.0ad53afe@ender> <28075.1186415314@sss.pgh.pa.us> <20070806120350.6e8d3c3b@ender> <28529.1186417407@sss.pgh.pa.us> <20070806122937.78bfcdd9@ender> Message-ID: <1186463969.30408.190.camel@shinybook.infradead.org> On Mon, 2007-08-06 at 12:29 -0400, Jesse Keating wrote: > Yes, it's "easy" to care about other arches when you're paid to do so. > But we have this goal that we want Fedora to be accessible and worked > on by more than just Red Hat engineering. And the sad reality of > today is that x86 is the prevalent arch and that's the lions share of > volunteers we're going to get. And that's fine. > Forcing them to care about whatever arches Red Hat deems is > necessary for their business strategy will likely cut our volunteers > by quite a bit and send them somewhere else that doesn't force them to > cater to $BigCorp business concerns. That's just nonsense, Jesse. We don't "force them to care". If they have a problem on PPC and they just resort to using ExcludeArch, that's fine. It's suboptimal if they do that without even _looking_ at the failure -- one would hope that our package maintainers are more conscientious than that, and for the most part they _are_. But we don't _force_ them to be. We have this working well _already_. If a packager doesn't care or can't fix the problem, or just doesn't feel like bothering, they can just exclude _any_ arch they like, for whatever reason. All we require is that they file a corresponding ExcludeArch bug to explain their reasons and allow interested parties to fix it up themselves. It turns out that the _majority_ of the bugs on the PPC ExcludeArch tracker end up being be _generic_ bugs. If they didn't bite on i386 at the time, that was purely a coincidence -- due to timing on SMP build machines, the precise choices the compiler happened to make that day, the phase of the moon, etc. They'd have bitten i386 eventually, and we _do_ improve Fedora/i386 quality by fixing them before that happens. I offer accounts to people who report problems on PPC. I don't recall a single case where they _haven't_ taken me up on it and looked into the problem. They usually seem _pleased_ of the opportunity to act as a conscientious package maintainer. Nobody is _forced_ to do anything, however often you repeat that nonsense. Ignoring build failures when they're _likely_ to be a generic problem is not something which is going to be good for Fedora. -- dwmw2 From dwmw2 at infradead.org Tue Aug 7 05:38:16 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 07 Aug 2007 13:38:16 +0800 Subject: Make ppc64 secondary arch - don't block builds (was: Dealing with ppc64 BRs) In-Reply-To: <20070806143528.GA15391@puariko.nirvana> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> <20070806130144.GN18009@puariko.nirvana> <20070806081108.4346141c@weaponx.rchland.ibm.com> <20070806143528.GA15391@puariko.nirvana> Message-ID: <1186465096.30408.206.camel@shinybook.infradead.org> On Mon, 2007-08-06 at 16:35 +0200, Axel Thimm wrote: > And shouldn't ppc64 (or any half-built arch) had been automatically > introduced as a secondary arch anyway to not mess with normal > packaging workflow? ppc64 is a bit of a special case. We never used to build Extras for ppc64, and with the merge we suddenly started to do so. Mostly things just work, but anything 'special' like ocaml needed to be ported (which I've mostly done but needs more testing and final debugging -- freetennis segfaults after startup). So it's not like any other 'new' arch would be, where we would attempt to build all the packages offline and would have all necessary ExcludeArches in place _before_ we add the new arch to the build system. You should just add the ExcludeArch, with corresponding bug on the ppc64 ExcludeArch tracker. When we get ocaml built, we'll round up the dependent packages and rebuild them too. > Even if the intention were to elevate it later to > a primary arch someday? What will happen with the next arch that will > be added? Have all packages ExcludeArch it to start with? All packages which don't build would have the necessary ExcludeArch and corresponding bug filed in advance, yes. And the packages which _do_ build would be present in the builder's repository when it comes online. Any package which fails to build when it _used_ to build OK is probably worth at least glancing at, because it's actually quite likely to be a generic problem . But you don't _have_ to -- nothing prevents package maintainers from just filing an ExcludeArch if they can't be bothered to look, just as nothing prevents them from closing all bugs WORKSFORME just because they don't happen to trip them up in their own usage of the package. For packages which have never built on ppc64 and which don't build when you first try them, I don't think anyone can fault you for just excluding ppc64 and waiting for the arch team to deal with it. Please do remember to file the bug and put it on the tracker though. -- dwmw2 From tgl at redhat.com Tue Aug 7 05:48:49 2007 From: tgl at redhat.com (Tom Lane) Date: Tue, 07 Aug 2007 01:48:49 -0400 Subject: Make ppc64 secondary arch - don't block builds (was: Dealing with ppc64 BRs) In-Reply-To: <1186465096.30408.206.camel@shinybook.infradead.org> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> <20070806130144.GN18009@puariko.nirvana> <20070806081108.4346141c@weaponx.rchland.ibm.com> <20070806143528.GA15391@puariko.nirvana> <1186465096.30408.206.camel@shinybook.infradead.org> Message-ID: <11390.1186465729@sss.pgh.pa.us> David Woodhouse writes: > On Mon, 2007-08-06 at 16:35 +0200, Axel Thimm wrote: >> And shouldn't ppc64 (or any half-built arch) had been automatically >> introduced as a secondary arch anyway to not mess with normal >> packaging workflow? > ppc64 is a bit of a special case. We never used to build Extras for > ppc64, and with the merge we suddenly started to do so. Again: this is a matter of trying to bring Extras up to a portability standard we have long held Core to. I have little respect for any Extras-package maintainer who won't at least try to meet the challenge. If you're stuck because you depend on some other package that doesn't build on ppc64, then of course it's not your fault --- but if *you* are the roadblock, it's time to pull the socks up. regards, tom lane From dwmw2 at infradead.org Tue Aug 7 07:26:44 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 07 Aug 2007 15:26:44 +0800 Subject: Make ppc64 secondary arch - don't block builds (was: Dealing with ppc64 BRs) In-Reply-To: <11390.1186465729@sss.pgh.pa.us> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> <20070806130144.GN18009@puariko.nirvana> <20070806081108.4346141c@weaponx.rchland.ibm.com> <20070806143528.GA15391@puariko.nirvana> <1186465096.30408.206.camel@shinybook.infradead.org> <11390.1186465729@sss.pgh.pa.us> Message-ID: <1186471604.30408.230.camel@shinybook.infradead.org> On Tue, 2007-08-07 at 01:48 -0400, Tom Lane wrote: > Again: this is a matter of trying to bring Extras up to a portability > standard we have long held Core to. I have little respect for any > Extras-package maintainer who won't at least try to meet the > challenge. > If you're stuck because you depend on some other package that doesn't > build on ppc64, then of course it's not your fault --- but if *you* > are the roadblock, it's time to pull the socks up. I think that's perhaps a little harsh in some cases. Take the blocker in Ralf's case, for example -- ocaml. I wouldn't necessarily expect a package maintainer to be willing and able to port its code generation back end to any new architecture which we happen to add to Fedora; that really is the job of the 'arch team'. (I am inclined to agree with you in the cases where the build failure is something simpler like stupid assumptions about wordsize, char signedness, endianness, etc. -- but there are extremely vocal Fedora contributors who disagree even with that, and who believe that it's acceptable for a packager to be responsible for a package even if they don't understand the language it's written in, and are completely incapable of dealing with or even _understanding_ any bugs in it. Quantity, not quality, is the apparent motivation.) For architectures which are newly added to Fedora's build system, I don't think it's reasonable to expect package maintainers to handle the _first_ build of their package on that architecture. The arch team responsible for the new arch should attempt to build all packages in advance, and each package should either have an ExcludeArch filed or a binary package present in the builder's repository before the big switch is flipped to incorporate that arch into the build system. We should probably consider PPC64 to be a 'new arch' for Extras packages, because we never built Extras for PPC64 before. So it's acceptable for people to just file an ExcludeArch if they build their package for the first time since the merge and it fails on PPC64. Most of our packagers are conscientious enough to take a look and see if it's something they can fix. Some are even insane enough to embark upon real porting work (and I'm happy to give them accounts). But I don't think it's reasonable to _expect_ them to go that far for a new architecture. Once the package in question is known to have been OK on a given architecture and if it _later_ starts to fail, that's something we'd expect the package maintainer to at least glance at. But not the _first_ build on the architecture in question. -- dwmw2 From oliver at linux-kernel.at Tue Aug 7 07:31:44 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Tue, 07 Aug 2007 09:31:44 +0200 Subject: ocaml on 'non-intel-arch' (WAS: Re: Make ppc64 secondary arch - don't block builds) In-Reply-To: <1186471604.30408.230.camel@shinybook.infradead.org> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> <20070806130144.GN18009@puariko.nirvana> <20070806081108.4346141c@weaponx.rchland.ibm.com> <20070806143528.GA15391@puariko.nirvana> <1186465096.30408.206.camel@shinybook.infradead.org> <11390.1186465729@sss.pgh.pa.us> <1186471604.30408.230.camel@shinybook.infradead.org> Message-ID: <46B81FE0.6060109@linux-kernel.at> Hi David! On 08/07/2007 09:26 AM, David Woodhouse wrote: > I think that's perhaps a little harsh in some cases. Take the blocker > in Ralf's case, for example -- ocaml. I wouldn't necessarily expect a > package maintainer to be willing and able to port its code generation > back end to any new architecture which we happen to add to Fedora; > that really is the job of the 'arch team'. [ ... ] I also see problems compiling ocaml on Alpha - maybe you can tell me your progress on that? Best, Oliver From dwmw2 at infradead.org Tue Aug 7 07:55:59 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 07 Aug 2007 15:55:59 +0800 Subject: ocaml on 'non-intel-arch' (WAS: Re: Make ppc64 secondary arch - don't block builds) In-Reply-To: <46B81FE0.6060109@linux-kernel.at> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> <20070806130144.GN18009@puariko.nirvana> <20070806081108.4346141c@weaponx.rchland.ibm.com> <20070806143528.GA15391@puariko.nirvana> <1186465096.30408.206.camel@shinybook.infradead.org> <11390.1186465729@sss.pgh.pa.us> <1186471604.30408.230.camel@shinybook.infradead.org> <46B81FE0.6060109@linux-kernel.at> Message-ID: <1186473359.30408.235.camel@shinybook.infradead.org> On Tue, 2007-08-07 at 09:31 +0200, Oliver Falk wrote: > Hi David! > > On 08/07/2007 09:26 AM, David Woodhouse wrote: > > I think that's perhaps a little harsh in some cases. Take the blocker > > in Ralf's case, for example -- ocaml. I wouldn't necessarily expect a > > package maintainer to be willing and able to port its code generation > > back end to any new architecture which we happen to add to Fedora; > > that really is the job of the 'arch team'. > > [ ... ] > > I also see problems compiling ocaml on Alpha - maybe you can tell me > your progress on that? I haven't looked at it. What's the problem? I know ocaml is working fine on ppc, and mostly OK on ppc64 (where 'mostly' means the compiler itself and most test programs seem to run, although freetennis segfaults after startup. Which is why it isn't in the build system yet). It looks like it ought to have Alpha support too. -- dwmw2 From dwmw2 at infradead.org Tue Aug 7 07:59:37 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 07 Aug 2007 15:59:37 +0800 Subject: Make ppc64 secondary arch - don't block builds (was: Dealing with ppc64 BRs) In-Reply-To: <1186471604.30408.230.camel@shinybook.infradead.org> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> <20070806130144.GN18009@puariko.nirvana> <20070806081108.4346141c@weaponx.rchland.ibm.com> <20070806143528.GA15391@puariko.nirvana> <1186465096.30408.206.camel@shinybook.infradead.org> <11390.1186465729@sss.pgh.pa.us> <1186471604.30408.230.camel@shinybook.infradead.org> Message-ID: <1186473577.30408.239.camel@shinybook.infradead.org> On Tue, 2007-08-07 at 15:26 +0800, David Woodhouse wrote: > I think that's perhaps a little harsh in some cases. Take the blocker in > Ralf's case, for example -- ocaml. s/Ralf/Axel/ Sorry, brain melting because I looked at ML code again. -- dwmw2 From oliver at linux-kernel.at Tue Aug 7 09:50:39 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Tue, 07 Aug 2007 11:50:39 +0200 Subject: ocaml on 'non-intel-arch' (WAS: Re: Make ppc64 secondary arch - don't block builds) In-Reply-To: <1186473359.30408.235.camel@shinybook.infradead.org> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> <20070806130144.GN18009@puariko.nirvana> <20070806081108.4346141c@weaponx.rchland.ibm.com> <20070806143528.GA15391@puariko.nirvana> <1186465096.30408.206.camel@shinybook.infradead.org> <11390.1186465729@sss.pgh.pa.us> <1186471604.30408.230.camel@shinybook.infradead.org> <46B81FE0.6060109@linux-kernel.at> <1186473359.30408.235.camel@shinybook.infradead.org> Message-ID: <46B8406F.7040503@linux-kernel.at> On 08/07/2007 09:55 AM, David Woodhouse wrote: > On Tue, 2007-08-07 at 09:31 +0200, Oliver Falk wrote: >> Hi David! >> >> On 08/07/2007 09:26 AM, David Woodhouse wrote: >>> I think that's perhaps a little harsh in some cases. Take the blocker >>> in Ralf's case, for example -- ocaml. I wouldn't necessarily expect a >>> package maintainer to be willing and able to port its code generation >>> back end to any new architecture which we happen to add to Fedora; >>> that really is the job of the 'arch team'. >> [ ... ] >> >> I also see problems compiling ocaml on Alpha - maybe you can tell me >> your progress on that? > > I haven't looked at it. What's the problem? > > I know ocaml is working fine on ppc, and mostly OK on ppc64 (where > 'mostly' means the compiler itself and most test programs seem to run, > although freetennis segfaults after startup. Which is why it isn't in > the build system yet). It looks like it ought to have Alpha support too. ok. understood, that ppc also has problems with ocaml - but compile problems... i'll try to rebuild it again and let you know - maybe you can help me out. :-) thx, -of From dwmw2 at infradead.org Tue Aug 7 10:17:12 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 07 Aug 2007 18:17:12 +0800 Subject: ocaml on 'non-intel-arch' (WAS: Re: Make ppc64 secondary arch - don't block builds) In-Reply-To: <46B8406F.7040503@linux-kernel.at> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> <20070806130144.GN18009@puariko.nirvana> <20070806081108.4346141c@weaponx.rchland.ibm.com> <20070806143528.GA15391@puariko.nirvana> <1186465096.30408.206.camel@shinybook.infradead.org> <11390.1186465729@sss.pgh.pa.us> <1186471604.30408.230.camel@shinybook.infradead.org> <46B81FE0.6060109@linux-kernel.at> <1186473359.30408.235.camel@shinybook.infradead.org> <46B8406F.7040503@linux-kernel.at> Message-ID: <1186481832.2877.26.camel@shinybook.infradead.org> On Tue, 2007-08-07 at 11:50 +0200, Oliver Falk wrote: > ok. understood, that ppc also has problems with ocaml - but compile > problems... i'll try to rebuild it again and let you know - maybe you > can help me out. :-) I'm not aware of any problems on PPC. Only PPC64 -- and that was just because it wasn't ported to PPC64 at all. -- dwmw2 From dennis at ausil.us Tue Aug 7 12:04:19 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 7 Aug 2007 07:04:19 -0500 Subject: ocaml on 'non-intel-arch' (WAS: Re: Make ppc64 secondary arch - don't block builds) In-Reply-To: <46B81FE0.6060109@linux-kernel.at> References: <20070806125214.GK18009@puariko.nirvana> <1186471604.30408.230.camel@shinybook.infradead.org> <46B81FE0.6060109@linux-kernel.at> Message-ID: <200708070704.24763.dennis@ausil.us> Once upon a time Tuesday 07 August 2007, Oliver Falk wrote: > Hi David! > > On 08/07/2007 09:26 AM, David Woodhouse wrote: > > I think that's perhaps a little harsh in some cases. Take the blocker > > in Ralf's case, for example -- ocaml. I wouldn't necessarily expect a > > package maintainer to be willing and able to port its code generation > > back end to any new architecture which we happen to add to Fedora; > > that really is the job of the 'arch team'. > > [ ... ] > > I also see problems compiling ocaml on Alpha - maybe you can tell me > your progress on that? I have ocmal built on sparc. I will do some run time tests and see if it actually works. im thinking it will since ppc works. It is not built sparc64 yet. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From dwmw2 at infradead.org Tue Aug 7 12:17:19 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 07 Aug 2007 20:17:19 +0800 Subject: ocaml on 'non-intel-arch' (WAS: Re: Make ppc64 secondary arch - don't block builds) In-Reply-To: <200708070704.24763.dennis@ausil.us> References: <20070806125214.GK18009@puariko.nirvana> <1186471604.30408.230.camel@shinybook.infradead.org> <46B81FE0.6060109@linux-kernel.at> <200708070704.24763.dennis@ausil.us> Message-ID: <1186489039.2877.52.camel@shinybook.infradead.org> On Tue, 2007-08-07 at 07:04 -0500, Dennis Gilmore wrote: > I have ocmal built on sparc. I will do some run time tests and see if > it actually works. im thinking it will since ppc works. That doesn't necessarily follow. It has its own compiler. Written in ML. Have fun :) -- dwmw2 From blizzard at redhat.com Tue Aug 7 19:23:32 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 07 Aug 2007 15:23:32 -0400 Subject: Make ppc64 secondary arch - don't block builds (was: Dealing with ppc64 BRs) In-Reply-To: <20070806202548.GD23470@puariko.nirvana> References: <20070806125214.GK18009@puariko.nirvana> <200708060758.51131.dennis@ausil.us> <20070806130144.GN18009@puariko.nirvana> <20070806081108.4346141c@weaponx.rchland.ibm.com> <20070806143528.GA15391@puariko.nirvana> <20070806094648.7fb586e9@weaponx.rchland.ibm.com> <20070806151156.GD15391@puariko.nirvana> <20070806112446.0ad53afe@ender> <20070806202548.GD23470@puariko.nirvana> Message-ID: <1186514612.14907.4.camel@localhost.localdomain> On Mon, 2007-08-06 at 22:25 +0200, Axel Thimm wrote: > > # ppc and arm will become secondary archs once the > infrastructure/process is in place There wasn't consensus on that at the meeting. I'm not sure why that ended up in the notes. --Chris From seg at haxxed.com Tue Aug 7 21:35:25 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 07 Aug 2007 16:35:25 -0500 Subject: Interested in holding a session at Virtual FudCon? In-Reply-To: <604aa7910707301558k49ed2790q2d41018826c33dce@mail.gmail.com> References: <604aa7910707301558k49ed2790q2d41018826c33dce@mail.gmail.com> Message-ID: <1186522525.28919.12.camel@localhost> On Mon, 2007-07-30 at 14:58 -0800, Jeff Spaleta wrote: > I am putting a draft together for the Online UnFudcon aka (Virtual Fudcon) > http://fedoraproject.org/wiki/JefSpaleta/VirtualFudCon We could jump on the fad-wagon and have sessions in Second Life, unfortunately voice chat is a closed source no-show on Linux at the moment. Currently uploading 1.18.0.6, uploading a full set of builds which weigh in at 200mb+ takes about 2 hours with my outgoing bandwidth... https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233946 -------------- 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 petersen at redhat.com Wed Aug 8 06:23:46 2007 From: petersen at redhat.com (Jens Petersen) Date: Wed, 08 Aug 2007 16:23:46 +1000 Subject: Font packages changes required for dropping chkfontpath/xfs In-Reply-To: <1185821868.11086.11.camel@hinata.boston.redhat.com> References: <1185821548.11086.9.camel@hinata.boston.redhat.com> <1185821868.11086.11.camel@hinata.boston.redhat.com> Message-ID: <46B96172.6040101@redhat.com> >> According to repoquery, the following require chkfontpath: >> fonts-KOI8-R-75dpi-0:1.0-9.1.1.noarch >> efont-unicode-bdf-0:0.4.2-6.1.fc6.noarch >> fonts-KOI8-R-100dpi-0:1.0-9.1.1.noarch >> fonts-ISO8859-2-0:1.0-17.1.noarch >> fonts-japanese-0:0.20061016-6.fc7.noarch >> fonts-korean-0:1.0.11-9.1.1.noarch >> fonts-x11-apl-0:4.20.2-19.fc8.x86_64 >> wqy-bitmap-fonts-0:0.8.1-6.fc8.noarch >> fonts-truetype-apl-0:4.20.2-19.fc8.x86_64 >> x3270-x11-0:3.3.4p7-5.fc6.x86_64 >> libdockapp-fonts-0:0.6.1-3.fc8.x86_64 >> fonts-ISO8859-2-100dpi-0:1.0-17.1.noarch >> grace-0:5.1.21-1.fc7.x86_64 >> urw-fonts-0:2.3-6.1.1.noarch >> fonts-chinese-0:3.03-4.fc7.noarch >> fonts-ISO8859-2-75dpi-0:1.0-17.1.noarch >> fonts-KOI8-R-0:1.0-9.1.1.noarch >> terminus-font-x11-0:4.20-5.fc6.noarch >> zvbi-fonts-0:0.2.25-1.fc8.x86_64 Can we have a tracking bug for this, which bugs filed against these packages can block? Thanks, Jens From john at curioussymbols.com Wed Aug 8 13:21:36 2007 From: john at curioussymbols.com (John Pye) Date: Wed, 08 Aug 2007 23:21:36 +1000 Subject: two questions Message-ID: <46B9C360.1030801@curioussymbols.com> Hi all, I have contributed two packages now, and I have some questions that don't seem to have been clearly addressed in a way that I've actaully understood: (1) after my package review, I get to add my files to CVS and build the package that ultimately gets into Fedora. What is to stop me from uploading something subtly (or even maliciously) different from the files that were actually reviewed? Thinking about that, wouldn't it be better if CVS access (or some other kind of controlled file space) were used from the *start* of the package review process, rather than only at the end? (2) once my package is uploaded at it gets the NEXTRELEASE status, how does my package, which is currently shown with 'dist-fc7-updates-candidate' tag in koji, end up eventually in the Fedora Updates repository? Are there more steps that I need to follow? Is there some other review happening? Cheers JP From debarshi.ray at gmail.com Wed Aug 8 13:34:05 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Wed, 8 Aug 2007 19:04:05 +0530 Subject: two questions In-Reply-To: <46B9C360.1030801@curioussymbols.com> References: <46B9C360.1030801@curioussymbols.com> Message-ID: <3170f42f0708080634u3c99e2c8md686fd63ec6b48e2@mail.gmail.com> > (2) once my package is uploaded at it gets the NEXTRELEASE status, how > does my package, which is currently shown with > 'dist-fc7-updates-candidate' tag in koji, end up eventually in the > Fedora Updates repository? Are there more steps that I need to follow? > Is there some other review happening? http://fedoraproject.org/wiki/PackageMaintainers/Join#head-5fe724060ca02046dde01278eb83f8a02dca3929 You basically use Bodhi to request the package to be pushed to updates-testing. After staying there for a week or so, if there are no bugs you again request it to be pushed to updates. Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From pertusus at free.fr Wed Aug 8 13:29:11 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 8 Aug 2007 15:29:11 +0200 Subject: two questions In-Reply-To: <46B9C360.1030801@curioussymbols.com> References: <46B9C360.1030801@curioussymbols.com> Message-ID: <20070808132911.GD15409@free.fr> On Wed, Aug 08, 2007 at 11:21:36PM +1000, John Pye wrote: > Hi all, > > I have contributed two packages now, and I have some questions that > don't seem to have been clearly addressed in a way that I've actaully > understood: > > (1) after my package review, I get to add my files to CVS and build the > package that ultimately gets into Fedora. What is to stop me from > uploading something subtly (or even maliciously) different from the > files that were actually reviewed? Thinking about that, wouldn't it be Nothing, except other people eyes. > better if CVS access (or some other kind of controlled file space) were > used from the *start* of the package review process, rather than only at > the end? Another fedora contributor (including the reviewer) can check that the md5sum in the 'sources' file are the same than during the review. In any case the same issue happens for every upstream update of the source tarball. At that point you'll have to change the sources file. Somebody may check that you used the right source, but if not you may install something malicious. You can also do malicious things in the scriptlets, but it is much more likely to be caught. > (2) once my package is uploaded at it gets the NEXTRELEASE status, how > does my package, which is currently shown with > 'dist-fc7-updates-candidate' tag in koji, end up eventually in the > Fedora Updates repository? Are there more steps that I need to follow? > Is there some other review happening? I wouldn't call it a review, but there is a process to push things to stable releases: http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem/Bodhi-info-DRAFT -- Pat From Axel.Thimm at ATrpms.net Wed Aug 8 14:15:07 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 8 Aug 2007 16:15:07 +0200 Subject: two questions In-Reply-To: <46B9C360.1030801@curioussymbols.com> References: <46B9C360.1030801@curioussymbols.com> Message-ID: <20070808141507.GA17341@puariko.nirvana> On Wed, Aug 08, 2007 at 11:21:36PM +1000, John Pye wrote: > (1) after my package review, I get to add my files to CVS and build the > package that ultimately gets into Fedora. What is to stop me from > uploading something subtly (or even maliciously) different from the > files that were actually reviewed? Subtly different in the sense of having additional fixes is OK. malicious is not. Just don't do it. ;) Actually that's the part where the mentors step in - you earn your trust by (hopefully) being watched by them, and if you behave well for a couple of packages you have enough trust points gained. -- 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 jorton at redhat.com Wed Aug 8 16:13:44 2007 From: jorton at redhat.com (Joe Orton) Date: Wed, 8 Aug 2007 17:13:44 +0100 Subject: expat soname bump & mass rebuilds Message-ID: <20070808161344.GA3946@redhat.com> I'm looking into upgrading expat to 2.0, which means a soname bump requiring rebuilds of about 65 packages. (currently I'm churning through mock rebuilds to see what breaks) Is a mass rebuild planned at any point during this development cycle? e.g. for the buildid stuff? I think it would make sense to put off the expat update until then, if so, to avoid doing this many unnecessary builds. Regards, joe From jkeating at redhat.com Wed Aug 8 16:21:52 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 8 Aug 2007 12:21:52 -0400 Subject: expat soname bump & mass rebuilds In-Reply-To: <20070808161344.GA3946@redhat.com> References: <20070808161344.GA3946@redhat.com> Message-ID: <20070808122152.606458c8@ender> On Wed, 8 Aug 2007 17:13:44 +0100 Joe Orton wrote: > Is a mass rebuild planned at any point during this development > cycle? e.g. for the buildid stuff? I think it would make sense to > put off the expat update until then, if so, to avoid doing this many > unnecessary builds. Yes, as well as for buildflags on ppc and for picking up licensing clarifications. No date has emerged yet for this though, and test2 is rapidly approaching. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Wed Aug 8 16:30:06 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 08 Aug 2007 18:30:06 +0200 Subject: EPEL report week 31 2007 Message-ID: <46B9EF8E.1020108@leemhuis.info> http://fedoraproject.org/wiki/EPEL/Reports/Week31 (sorry, a bit late this time; was quite busy at work and a family visit) = Weekly EPEL Summary = Week 31/2007 == Most important happenings == * Noting major == EPEL SIG Meeting == === Attending === >From the Steering Committee: * dgilmore (DennisGilmore) * nirik (KevinFenzi) (vacation) * mmcgrath (MikeMcGrath) * quaid (KarstenWade) Missing from the Steering Committee: * Jeff_S (Jeff Sheltren) * knurd (ThorstenLeemhuis) * stahnma (MichaelStahnke) Others that participated the meeting: warren, rsc === Summary === * what did everyone think of how things have gone since the announcement? * we probably should have a link on the front page of fp.o and fp.o/wiki; or perhaps a epel.fedoraproject.org cname? * some discussions about collecting and publishing statistics * branch for EPEL if Fedora maintainer does not react * more discussions on the list * new push scripts for pushing to testing, adjust mock configs to use * dgilmore will take care of it * security will need manual handling; nirik is willing to help * EPEL announcement happened -- what next? * nirik> | more packages, more maintainers, more users. ;) * nirik> | if we could move to koji at some point and bodhi that would be good... dgilmore> | needs to be done but requires coders * dgilmore> | does anyone have ideas on how to get more packages in EPEL? nirik> | I have some more I am going to do, but haven't had time... hopefully soon I will get munin in and possibly will look at Xfce (matching the centos extra versions so we don't conflict if possible) === Full Log === https://www.redhat.com/archives/epel-devel-list/2007-August/msg00014.html == Stats == === General === Number of EPEL Contributors 6 We welcome 6 new contributors: chris_AT_chrisgrau.com james.antill_AT_redhat.com jhrozek_AT_redhat.com mccann0011_AT_hotmail.com smilner_AT_redhat.com tmraz_AT_redhat.com === EPEL 5 === Number of source packages: 510 Number of binary packages: 938 There are 26 new Packages: * bacula | Cross platform network backup for Linux, Unix, Mac and Windows * cairomm | Cairomm is the C++ API for the cairo graphics library * cfitsio | Library for manipulating FITS data files * fping | Scriptable, parallelized ping-like utility * freetds | Implementation of the TDS (Tabular DataStream) protocol * gtkmm24 | C++ interface for GTK2 (a GUI library for X) * irssi | Modular text mode IRC client with Perl scripting * iverilog | Icarus Verilog is a verilog compiler and simulator * nail | Enhanced implementation of the mailx command * net6 | A TCP protocol abstraction for library C++ * obby | A library which provides synced document buffers * octave | A high-level language for numerical computations * perl-AnyData | Easy access to data in many formats * perl-Apache-LogRegex | Parse a line from an Apache logfile into a hash * perl-Cache-Mmap | Shared data cache using memory mapped files * perl-Class-Accessor | Automated accessor generation * perl-Class-Data-Inheritable | Inheritable, overridable class data * perl-Clone | Recursively copy perl datatypes * perl-CPAN-DistnameInfo | CPAN::DistnameInfo Perl module * perl-MIME-Types | MIME types module for Perl * perl-Module-CoreList | Perl core modules indexed by perl versions * perl-Test-Tester | Ease testing test modules built with Test::Builder * perl-UNIVERSAL-require | Require() modules from a variable * perl-XML-XPath | XPath parser and evaluator for Perl * timidity++ | A software wavetable MIDI synthesizer. * wxGTK | GTK2 port of the wxWidgets GUI library === EPEL 4 === Number of source packages: 313 Number of binary packages: 621 There are 18 new Packages: * cfitsio | Library for manipulating FITS data files * fping | Scriptable, parallelized ping-like utility * freetds | Implementation of the TDS (Tabular DataStream) protocol * irssi | Modular text mode IRC client with Perl scripting * iverilog | Icarus Verilog is a verilog compiler and simulator * nail | Enhanced implementation of the mailx command * perl-AnyData | Easy access to data in many formats * perl-Apache-LogRegex | Parse a line from an Apache logfile into a hash * perl-Cache-Mmap | Shared data cache using memory mapped files * perl-Class-Accessor | Automated accessor generation * perl-Class-Data-Inheritable | Inheritable, overridable class data * perl-Clone | Recursively copy perl datatypes * perl-CPAN-DistnameInfo | CPAN::DistnameInfo Perl module * perl-Test-Tester | Ease testing test modules built with Test::Builder * perl-UNIVERSAL-require | Require() modules from a variable * perl-XML-XPath | XPath parser and evaluator for Perl * svnmailer | Tool to post subversion repository commit information * timidity++ | A software wavetable MIDI synthesizer. ---- ["CategoryEPELReports"] From tibbs at math.uh.edu Wed Aug 8 17:08:01 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 08 Aug 2007 12:08:01 -0500 Subject: Summary of the 2007-08-07 Packaging Committee meeting Message-ID: Meeting minutes and full logs of the packaging committee meeting which occurred on 2007-XXX are online: http://fedoraproject.org/wiki/Packaging/Minutes http://fedoraproject.org/wiki/Packaging/Minutes20070807 Executive summary: The following drafts are now official guidelines, having been accepted by FESCO last week: * The license tag refinements requested by the board: * http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag * Dynamic user and group creation policy: * http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups These should be written into the guidelines soon if this hasn't already been done by the time you read this. There are no issues pending FESCO ratification this week. Misc business: * Clarifying what the License: tag refers to (source or resulting binary): * http://fedoraproject.org/wiki/PackagingDrafts/LicenseClarification * There was plenty of interesting discussion here; it's a delicate issue but the current tendency is to let License: refer to the license on the source packages. - J< From j.w.r.degoede at hhs.nl Wed Aug 8 17:36:35 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 08 Aug 2007 19:36:35 +0200 Subject: Summary of the 2007-08-07 Packaging Committee meeting In-Reply-To: References: Message-ID: <46B9FF23.5020904@hhs.nl> Jason L Tibbitts III wrote: > * Clarifying what the License: tag refers to (source or resulting > binary): > * http://fedoraproject.org/wiki/PackagingDrafts/LicenseClarification > * There was plenty of interesting discussion here; it's a delicate > issue but the current tendency is to let License: refer to the > license on the source packages. > Erm, can we word that as "let License: refer to the license of the parts of the sources used to build the binaries. IOW not any licenses inherited from libraries used" This clarification is important to me because for example bochs contains a src file which is GPLv2 only, where as the rest is GPLv2+, but unless a configure option we don't use is passed, this GPLv2 only file isn't compiled in so the resulting binaries are GPLv2+. Also the way it is phrased now, there us no use in doing sub-packages for different licensed parts as is currently adviced, since the sources as a whole are under the most restrictive license. And even with the clarification, I'm not at all sure this is wise. I think it would be better to say that this practice is concidered OK, because a packager is not expected to trace all the licenses of all linked in libs (and their deps), but that if the packager knows that a more restrictive license from a lib makes the package itself more restrictively licensed then the package source license, that the packager then is encouraged to put in the more restrictive license? This is esp important for libs, so that people can check license issues with libs, without having to walk the entire dep chain. For example I've just split of the id3tag plugin for imlib2 into its own subpackage because libid3tag is GPL licensed, whereas imlib and its other deps are MIT/BSD (ish), and I've used GPLv2+ as License: field for this subpackage. Regards, Hans From tibbs at math.uh.edu Wed Aug 8 17:47:26 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 08 Aug 2007 12:47:26 -0500 Subject: Summary of the 2007-08-07 Packaging Committee meeting In-Reply-To: <46B9FF23.5020904@hhs.nl> References: <46B9FF23.5020904@hhs.nl> Message-ID: >>>>> "HdG" == Hans de Goede writes: HdG> Erm, can we word that as "let License: refer to the license of HdG> the parts of the sources used to build the binaries. IOW not any HdG> licenses inherited from libraries used" Please read the logs; perhaps my summary was deficient. Which is why I usually avoid attempting to summarize, and will remind myself to avoid doing so in the future. - J< From jeff.gilchrist at gmail.com Wed Aug 8 17:57:30 2007 From: jeff.gilchrist at gmail.com (Jeff Gilchrist) Date: Wed, 8 Aug 2007 13:57:30 -0400 Subject: Build Error/Job Failed but package created successfully Message-ID: I'm having some strange build error/job failed problems. This is happening for a package on both FC-6 and EL-5 which built fine on FC-7 a week ago. I get an e-mail saying there were build errors and the job failed but looking at the logs I don't see where it is failing and it looks like the package was created successfully. The message states: Build Error (Job 35515): pbzip2-1_0_2-2_fc6 on fedora-6-extras Job failed on arch x86_64 FC6 build log: http://buildsys.fedoraproject.org/logs/fedora-6-extras/35515-pbzip2-1.0.2-2.fc6/x86_64/build.log EL5 build log: http://buildsys.fedoraproject.org/logs/fedora-5-epel/35516-pbzip2-1.0.2-2.el5/i386/build.log Anyone know what is going on? Thanks, Jeff. From j.w.r.degoede at hhs.nl Wed Aug 8 18:00:49 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 08 Aug 2007 20:00:49 +0200 Subject: Summary of the 2007-08-07 Packaging Committee meeting In-Reply-To: References: <46B9FF23.5020904@hhs.nl> Message-ID: <46BA04D1.3000901@hhs.nl> Jason L Tibbitts III wrote: >>>>>> "HdG" == Hans de Goede writes: > > HdG> Erm, can we word that as "let License: refer to the license of > HdG> the parts of the sources used to build the binaries. IOW not any > HdG> licenses inherited from libraries used" > > Please read the logs; perhaps my summary was deficient. Which is why > I usually avoid attempting to summarize, and will remind myself to > avoid doing so in the future. > Okay, the logs clear up my first issue, but still leave the rest of my mail open, I'm especially curious how I should handle my example at the end. --- And even with the clarification, I'm not at all sure this is wise. I think it would be better to say that this practice is concidered OK, because a packager is not expected to trace all the licenses of all linked in libs (and their deps), but that if the packager knows that a more restrictive license from a lib makes the package itself more restrictively licensed then the package source license, that the packager then is encouraged to put in the more restrictive license? This is esp important for libs, so that people can check license issues with libs, without having to walk the entire dep chain. For example I've just split of the id3tag plugin for imlib2 into its own subpackage because libid3tag is GPL licensed, whereas imlib and its other deps are MIT/BSD (ish), and I've used GPLv2+ as License: field for this subpackage. Regards, Hans From limb at jcomserv.net Wed Aug 8 17:47:16 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 8 Aug 2007 12:47:16 -0500 (CDT) Subject: Build Error/Job Failed but package created successfully In-Reply-To: References: Message-ID: <10865.65.192.24.164.1186595236.squirrel@mail.jcomserv.net> > I'm having some strange build error/job failed problems. This is > happening for a package on both FC-6 and EL-5 which built fine on FC-7 > a week ago. I get an e-mail saying there were build errors and the > job failed but looking at the logs I don't see where it is failing and > it looks like the package was created successfully. > > The message states: > Build Error (Job 35515): pbzip2-1_0_2-2_fc6 on fedora-6-extras > Job failed on arch x86_64 > > FC6 build log: > http://buildsys.fedoraproject.org/logs/fedora-6-extras/35515-pbzip2-1.0.2-2.fc6/x86_64/build.log > > EL5 build log: > http://buildsys.fedoraproject.org/logs/fedora-5-epel/35516-pbzip2-1.0.2-2.el5/i386/build.log > > Anyone know what is going on? I had this happen a week or so ago, and then retried the build a few days after, making no changes, and it was fine. > Thanks, > Jeff. > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- novus ordo absurdum From krh at redhat.com Wed Aug 8 20:13:41 2007 From: krh at redhat.com (Kristian =?ISO-8859-1?Q?H=F8gsberg?=) Date: Wed, 08 Aug 2007 16:13:41 -0400 Subject: Font packages changes required for dropping chkfontpath/xfs In-Reply-To: <4603.1186443133@sss.pgh.pa.us> References: <1185821548.11086.9.camel@hinata.boston.redhat.com> <46AE3B7F.80903@ioa.s.u-tokyo.ac.jp> <1185823650.2794.177.camel@localhost.localdomain> <46AE43F7.1080201@ioa.s.u-tokyo.ac.jp> <1185826371.2794.180.camel@localhost.localdomain> <1186434848.20556.80.camel@erebor.boston.redhat.com> <4603.1186443133@sss.pgh.pa.us> Message-ID: <1186604021.20954.3.camel@hinata.boston.redhat.com> On Mon, 2007-08-06 at 19:32 -0400, Tom Lane wrote: > Jeremy Katz writes: > > On Mon, 2007-07-30 at 16:12 -0400, Adam Jackson wrote: > >> This is merely an rpmlink complaint. Symlinks aren't mentioned in the > >> packaging policy at all. > > > The chroot concern is real, though. And unless there's a really good > > reason for it, symlinks _should_ be relative. Even if all they have in > > common is /. > > Can you show an example where that actually helps? I can think of a > number of cases where it'd be a bad idea, and none where it really > solves a problem. In the x fontpath case the chroot complaint is not valid. It's as big a problem as having, say, the location of the rgb file compiled into the X server. The symlinks are only dereferenced at run-time at which point your chroot better be in effect. Kristian From roland at redhat.com Wed Aug 8 20:56:33 2007 From: roland at redhat.com (Roland McGrath) Date: Wed, 8 Aug 2007 13:56:33 -0700 (PDT) Subject: packagers note: do not run ld directly Message-ID: <20070808205633.C88354D04C4@magilla.localdomain> An easy mistake sometimes made in packages' build setup is to run ld directly rather than via gcc, e.g. when creating a shared library. It is always wrong to run ld directly when a linking user-mode executable or shared library. This rule is not Fedora-specific, so be sure to get the makefile fixes upstream. e.g. a makefile line: $(LD) -shared -o $@ $(objs) should be: $(CC) -shared -o $@ $(objs) Best practice is to use consistently the flags otherwise passed to the compiler, and also use LDFLAGS, i.e.: $(CC) $(CFLAGS) $(LDFLAGS) -shared -o $@ $(objs) If you use higher-level tools rather than writing these command lines by hand in makefiles or elsewhere, those tools should already be doing the right thing. For DSOs especially, linking the wrong way causes several subtle bugs though things may work correctly when you test them right after the build. Letting the compiler run the linker with the correct details is always the right way to be sure you get a kosher binary. In Fedora 8 (and rawhide as of very soon), a binary built incorrectly in this way is likely to be detected at rpm build time and prevent your rpm being built. You may see errors like: *** ERROR: No build ID note found in /var/tmp/buildroot/.../some-binary The most likely cause of that error is an improper linking command used to create "some-binary". If your package runs ld directly for the final link to create an executable or DSO, and it seems more complex than the simple mistakes I've described, please post here for advice. The initial presumption should be that the use of ld is probably wrong. If there is a special need, there is probably a better way to address it. Thanks, Roland From jorton at redhat.com Wed Aug 8 21:06:21 2007 From: jorton at redhat.com (Joe Orton) Date: Wed, 8 Aug 2007 22:06:21 +0100 Subject: expat soname bump & mass rebuilds In-Reply-To: <20070808122152.606458c8@ender> References: <20070808161344.GA3946@redhat.com> <20070808122152.606458c8@ender> Message-ID: <20070808210621.GA9230@redhat.com> On Wed, Aug 08, 2007 at 12:21:52PM -0400, Jesse Keating wrote: > On Wed, 8 Aug 2007 17:13:44 +0100 > Joe Orton wrote: > > > Is a mass rebuild planned at any point during this development > > cycle? e.g. for the buildid stuff? I think it would make sense to > > put off the expat update until then, if so, to avoid doing this many > > unnecessary builds. > > Yes, as well as for buildflags on ppc and for picking up licensing > clarifications. No date has emerged yet for this though, and test2 is > rapidly approaching. OK. I am away all of next week - if the mass rebuild happens then, would it be possible to put the new expat into the tree first? I have built the package here, untagged: http://koji.fedoraproject.org/koji/taskinfo?taskID=94243 and the library compat package will be needed also to avoid a bootstrapping nightmare since some key packages are linked against the old expat e.g. python; it is ready to import once reviewed by Some Kind Soul: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=251361 I've mock-rebuilt about two dozen packages against the new expat today without any problems; I'll attempt to go through them all by the end of this week. Regards, joe From Axel.Thimm at ATrpms.net Wed Aug 8 22:39:14 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 9 Aug 2007 00:39:14 +0200 Subject: Summary of the 2007-08-07 Packaging Committee meeting In-Reply-To: <46B9FF23.5020904@hhs.nl> References: <46B9FF23.5020904@hhs.nl> Message-ID: <20070808223914.GC19195@puariko.nirvana> On Wed, Aug 08, 2007 at 07:36:35PM +0200, Hans de Goede wrote: > > * There was plenty of interesting discussion here; it's a delicate > > issue but the current tendency is to let License: refer to the > > license on the source packages. > Erm, can we word that as "let License: refer to the license of the > parts of the sources used to build the binaries. IOW not any > licenses inherited from libraries used" The source package by itself is already derived work, which someone can use to build from all sources. E.g. you cannot restrict to what you actually use, for a hyperbole's sake: someone could take the kernel tar.gz, find a public domain file in there and republish the kernel tar.gz as public domain as he only used that one file of the tarball :) I think the magic attitude here is to note that this Licensing tag is just to aid some preparsing stuff for real humans to look at. Best is to put the most restrictive tag in License: that results from the whole of the sources and clarify within the package if need be. -- 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 john at curioussymbols.com Thu Aug 9 00:24:04 2007 From: john at curioussymbols.com (John Pye) Date: Thu, 09 Aug 2007 10:24:04 +1000 Subject: two questions In-Reply-To: <3170f42f0708080634u3c99e2c8md686fd63ec6b48e2@mail.gmail.com> References: <46B9C360.1030801@curioussymbols.com> <3170f42f0708080634u3c99e2c8md686fd63ec6b48e2@mail.gmail.com> Message-ID: <46BA5EA4.5020105@curioussymbols.com> Hi Debarshi, Debarshi 'Rishi' Ray wrote: >> (2) once my package is uploaded at it gets the NEXTRELEASE status, how >> does my package, which is currently shown with >> 'dist-fc7-updates-candidate' tag in koji, end up eventually in the >> Fedora Updates repository? Are there more steps that I need to follow? >> Is there some other review happening? >> > > http://fedoraproject.org/wiki/PackageMaintainers/Join#head-5fe724060ca02046dde01278eb83f8a02dca3929 > > You basically use Bodhi to request the package to be pushed to > updates-testing. After staying there for a week or so, if there are no > bugs you again request it to be pushed to updates. > How do I push to Fedora 6? Is there a way? I presume that because F-8 is not yet released I don't need to 'push' to that system? Note that the nomenclature in Bodhi is 'push to stable', not 'push to updates'. Cheers JP From jwboyer at jdub.homelinux.org Thu Aug 9 01:01:04 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 8 Aug 2007 20:01:04 -0500 Subject: packagers note: do not run ld directly In-Reply-To: <20070808205633.C88354D04C4@magilla.localdomain> References: <20070808205633.C88354D04C4@magilla.localdomain> Message-ID: <20070808200104.5001e11b@vader.jdub.homelinux.org> On Wed, 8 Aug 2007 13:56:33 -0700 (PDT) Roland McGrath wrote: > An easy mistake sometimes made in packages' build setup is to run ld > directly rather than via gcc, e.g. when creating a shared library. > It is always wrong to run ld directly when a linking user-mode > executable or shared library. This rule is not Fedora-specific, so > be sure to get the makefile fixes upstream. Not questioning you, but I'm curious as to why exactly. I've seen this in many projects over the years and while it always made me nervous, I didn't really see any problems pop out. josh From roland at redhat.com Thu Aug 9 01:17:52 2007 From: roland at redhat.com (Roland McGrath) Date: Wed, 8 Aug 2007 18:17:52 -0700 (PDT) Subject: packagers note: do not run ld directly In-Reply-To: Josh Boyer's message of Wednesday, 8 August 2007 20:01:04 -0500 <20070808200104.5001e11b@vader.jdub.homelinux.org> Message-ID: <20070809011752.EA16B4D04C4@magilla.localdomain> > Not questioning you, but I'm curious as to why exactly. I've seen this > in many projects over the years and while it always made me nervous, I > didn't really see any problems pop out. The most common problem historically is failing to include proper DT_NEEDED dependencies and symbol version bindings for other DSOs referred to by the DSO you're building. This means you've created a DSO which the system will happily load into a program that is actually using incompatible ABIs. Its calls will go to incompatible functions, and crash or misbehave in worse ways. At the packaging level, you won't have the correct automatic dependencies to that ordinarily let rpm/yum help you avoid installing things that could be broken in such ways when you run them. These are problems that won't show up any time soon in testing, but will come back to haunt your users later on, years from now. You also fail to include the magic crt* objects that may be necessary for initializers and finalizers (constructors and destructors) in your library to work right. You omit standard switches like --eh-frame-hdr and --hash-style=gnu, which may make your DSO perform poorly, or can even break exception handling. The recent new reason it's wrong is that you omit --build-id. This will be detected by debuginfo generation as a bug in your package. Thanks, Roland From roland at redhat.com Thu Aug 9 01:32:16 2007 From: roland at redhat.com (Roland McGrath) Date: Wed, 8 Aug 2007 18:32:16 -0700 (PDT) Subject: F8 packagers note: new find-debuginfo.sh script Message-ID: <20070809013216.1EB524D04C4@magilla.localdomain> Coming soon to a dist-f8 near you will be an rpm-build package that includes a revamped find-debuginfo.sh script. This will be a new rpm-build > 4.4.2.1-3. You can find an unofficial build with the new script right now in http://koji.fedoraproject.org/scratch/roland/task_94236/ Most maintainers should not need to worry about the new script. It should silently do the right thing without any attention from you. If you see any new problems, please harrass me immediately. For any packages doing special non-default debuginfo packaging, please talk to me directly. I've taken care of kernel and glibc, which are the only special cases I know of. The only problem I know to expect is improperly built DSOs, where broken package makefiles run ld -shared directly instead of via gcc. I just posted about the details of this: https://www.redhat.com/archives/fedora-maintainers/2007-August/msg00135.html If this hits you, it was already a bug in your package, and now the tools are telling you about it early. If you see any messages like: *** ERROR: No build ID note found in ... then look into how the named binaries are linked. If it's not a simple case of changing ld -shared to $(CC) -shared, you can always contact me for help figuring it out. If anything else about the find-debuginfo.sh part of your build.log, or the -debuginfo rpm that results, looks suspect to you, don't hesitate to contact me. The intended changes are the build-id magic, smart handling of hard links and symlinks, and generating all the correct %dir lines. Thanks, Roland From orion at cora.nwra.com Thu Aug 9 01:43:37 2007 From: orion at cora.nwra.com (orion at cora.nwra.com) Date: Wed, 8 Aug 2007 19:43:37 -0600 (MDT) Subject: two questions In-Reply-To: <46BA5EA4.5020105@curioussymbols.com> References: <46B9C360.1030801@curioussymbols.com> <3170f42f0708080634u3c99e2c8md686fd63ec6b48e2@mail.gmail.com> <46BA5EA4.5020105@curioussymbols.com> Message-ID: <3375.71.208.209.229.1186623817.squirrel@www.cora.nwra.com> > > How do I push to Fedora 6? Is there a way? F6 still uses the old "plague" build system - builds are pushed automatically. > I presume that because F-8 is not yet released I don't need to 'push' to > that system? Essentially, yes. From debarshi.ray at gmail.com Thu Aug 9 03:42:14 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Thu, 9 Aug 2007 09:12:14 +0530 Subject: two questions In-Reply-To: <46BA5EA4.5020105@curioussymbols.com> References: <46B9C360.1030801@curioussymbols.com> <3170f42f0708080634u3c99e2c8md686fd63ec6b48e2@mail.gmail.com> <46BA5EA4.5020105@curioussymbols.com> Message-ID: <3170f42f0708082042tf47928flef30374611de8a8c@mail.gmail.com> > How do I push to Fedora 6? Is there a way? Fedora Core 6 uses Plague, of which I do not know much, > I presume that because F-8 is not yet released I don't need to 'push' to > that system? If 'make tag build' is successful in the 'deve' branch, you just sit back and the package appears automatically in the 'development' repository in the next Rawhide push. > Note that the nomenclature in Bodhi is 'push to stable', not 'push to > updates'. Yes. They are the same. :-) The name of the repository is 'updates' though. Cheers, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From jnovy at redhat.com Thu Aug 9 09:01:00 2007 From: jnovy at redhat.com (Jindrich Novy) Date: Thu, 9 Aug 2007 11:01:00 +0200 Subject: New db4 update and package changes Message-ID: <20070809090100.GA1165@dhcp-lab-186.brq.redhat.com> Hi folks, you may have noticed Oracle released db-4.6.18 recently. The update is now prepared in CVS, old db-4.5.20 is now moved to compat-db so the new db4 is ready to hit rawhide soon. I want to announce a change I made in the new db4, that may affect you from the packaging POV if your package is dependent on db4. It is that I moved all the C++ stuff to db4-cxx and db4-cxx-devel subpackages to reduce dependency bloat (#220484). If you have any proposals/objections related to the update, please speak up. Thanks, Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From Axel.Thimm at ATrpms.net Thu Aug 9 09:51:57 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 9 Aug 2007 11:51:57 +0200 Subject: build-id magic (was: F8 packagers note: new find-debuginfo.sh script) In-Reply-To: <20070809013216.1EB524D04C4@magilla.localdomain> References: <20070809013216.1EB524D04C4@magilla.localdomain> Message-ID: <20070809095157.GA2797@puariko.nirvana> On Wed, Aug 08, 2007 at 06:32:16PM -0700, Roland McGrath wrote: > The intended changes are the build-id magic, [...] I've seen this floating around a lot lately, but did not have the time to follow up the discussions. Is there a pointer to some nice summary of what this does and why we should buy it? :) Thanks! -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From roland at redhat.com Thu Aug 9 09:53:25 2007 From: roland at redhat.com (Roland McGrath) Date: Thu, 9 Aug 2007 02:53:25 -0700 (PDT) Subject: build-id magic (was: F8 packagers note: new find-debuginfo.sh script) In-Reply-To: Axel Thimm's message of Thursday, 9 August 2007 11:51:57 +0200 <20070809095157.GA2797@puariko.nirvana> Message-ID: <20070809095325.3BFCE4D04C4@magilla.localdomain> > I've seen this floating around a lot lately, but did not have the time > to follow up the discussions. Is there a pointer to some nice summary > of what this does and why we should buy it? :) http://fedoraproject.org/wiki/Releases/FeatureBuildId From oliver at linux-kernel.at Thu Aug 9 10:21:24 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 09 Aug 2007 12:21:24 +0200 Subject: ocaml on 'non-intel-arch' (WAS: Re: Make ppc64 secondary arch - don't block builds) In-Reply-To: <200708070704.24763.dennis@ausil.us> References: <20070806125214.GK18009@puariko.nirvana> <1186471604.30408.230.camel@shinybook.infradead.org> <46B81FE0.6060109@linux-kernel.at> <200708070704.24763.dennis@ausil.us> Message-ID: <46BAEAA4.60703@linux-kernel.at> On 08/07/2007 02:04 PM, Dennis Gilmore wrote: > Once upon a time Tuesday 07 August 2007, Oliver Falk wrote: >> Hi David! >> >> On 08/07/2007 09:26 AM, David Woodhouse wrote: >>> I think that's perhaps a little harsh in some cases. Take the blocker >>> in Ralf's case, for example -- ocaml. I wouldn't necessarily expect a >>> package maintainer to be willing and able to port its code generation >>> back end to any new architecture which we happen to add to Fedora; >>> that really is the job of the 'arch team'. >> [ ... ] >> >> I also see problems compiling ocaml on Alpha - maybe you can tell me >> your progress on that? > I have ocmal built on sparc. I will do some run time tests and see if it > actually works. im thinking it will since ppc works. It is not built > sparc64 yet. Well, after some testing now... ocaml builds fine on Alpha. BUT with the old non-relaxed binutils... The new binutils with relax enabled by default doesn't work. I was also not able to use --no-relax... However. Best, Oliver From Axel.Thimm at ATrpms.net Thu Aug 9 10:49:52 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 9 Aug 2007 12:49:52 +0200 Subject: build-id magic (was: F8 packagers note: new find-debuginfo.sh script) In-Reply-To: <20070809095325.3BFCE4D04C4@magilla.localdomain> References: <20070809095157.GA2797@puariko.nirvana> <20070809095325.3BFCE4D04C4@magilla.localdomain> Message-ID: <20070809104952.GB2797@puariko.nirvana> On Thu, Aug 09, 2007 at 02:53:25AM -0700, Roland McGrath wrote: > > I've seen this floating around a lot lately, but did not have the time > > to follow up the discussions. Is there a pointer to some nice summary > > of what this does and why we should buy it? :) > > http://fedoraproject.org/wiki/Releases/FeatureBuildId Thanks, that's more than just a summary, it's a very good project documentation and planning, I wish this colors off to the rest of us :) So I guess once everything is in place (all NEEDED parts in the wiki removed) we will have a scheduled mass-rebuild of everything that is not noarch. I think there were also other items in need of mass-rebuilds (license changes, maybe more), so the rel-eng team would probably have to strategically place one mass-rebuild somewhere in http://fedoraproject.org/wiki/Releases/8/Schedule Maybe between test2 and test3 as there is not really enough time until test2 (and many maintainers are low on power during vacation time). -- 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 jeff.gilchrist at gmail.com Thu Aug 9 11:37:36 2007 From: jeff.gilchrist at gmail.com (Jeff Gilchrist) Date: Thu, 9 Aug 2007 07:37:36 -0400 Subject: Build Error/Job Failed but package created successfully In-Reply-To: <10865.65.192.24.164.1186595236.squirrel@mail.jcomserv.net> References: <10865.65.192.24.164.1186595236.squirrel@mail.jcomserv.net> Message-ID: On 8/8/07, Jon Ciesla wrote: > I had this happen a week or so ago, and then retried the build a few days > after, making no changes, and it was fine. I tried again this morning without any changes and it seemed to work this time. Not sure what happened but didn't get any errors this time. Thanks, Jeff. From john at curioussymbols.com Thu Aug 9 11:56:35 2007 From: john at curioussymbols.com (John Pye) Date: Thu, 09 Aug 2007 21:56:35 +1000 Subject: two questions In-Reply-To: <3170f42f0708080634u3c99e2c8md686fd63ec6b48e2@mail.gmail.com> References: <46B9C360.1030801@curioussymbols.com> <3170f42f0708080634u3c99e2c8md686fd63ec6b48e2@mail.gmail.com> Message-ID: <46BB00F3.8000204@curioussymbols.com> Debarshi 'Rishi' Ray wrote: >> (2) once my package is uploaded at it gets the NEXTRELEASE status, how >> does my package, which is currently shown with >> 'dist-fc7-updates-candidate' tag in koji, end up eventually in the >> Fedora Updates repository? Are there more steps that I need to follow? >> Is there some other review happening? >> > > http://fedoraproject.org/wiki/PackageMaintainers/Join#head-5fe724060ca02046dde01278eb83f8a02dca3929 > > You basically use Bodhi to request the package to be pushed to > updates-testing. After staying there for a week or so, if there are no > bugs you again request it to be pushed to updates. > OK, as far as I can tell, I have pushed both 'fityk' and 'sundials' to Fedora Updates Testing. Should I expect to see them here? http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/7/i386/ If not, where? Or is there a delay? And where can I check to see that the package has gone out to FC6 users? (is there a 'testing' repository for that one too?) Cheers JP From john at curioussymbols.com Thu Aug 9 12:15:04 2007 From: john at curioussymbols.com (John Pye) Date: Thu, 09 Aug 2007 22:15:04 +1000 Subject: packages.fedoraproject.org? Message-ID: <46BB0548.6010609@curioussymbols.com> Hi all I wonder if there's been any effort to set up a similar package browser to that offered by Debian and Ubuntu. It's really invaluable to be able to easily see what depends on what, what *suggests* what, what bugs are associated with each package, and what versions are provided for different releases. http://packages.ubuntu.com/ http://packages.ubuntu.com/feisty/gnome/abiword-plugins I know that there is a 'repobrowser' installed (somewhere) on the Fedora servers, but I would like to point out that it's rather hard to find (doesn't click through from anywhere that I've noticed, and doesn't come on a google search) http://www.google.com/search?q=fedora+packages http://www.google.com/search?q=fedora+repository+browser http://www.google.com/search?q=fedora+rpms http://www.google.com/search?q=fedora+repository http://www.google.com/search?q=fedoraproject+repository http://www.google.com/search?q=fedoraproject+packages Can I suggest that a repository browser be made that has a bit more page layout (branding etc) and a bit more cross-linking with other Fedora services, and that it be made prominent on the Fedora homepage and/or developers' wiki? Is this something that has been suggested before? A good package browser is a good thing when users are trying to find software that performs a particular task, and are a good thing when developers are trying to tracking down packages and versions etc, for distros/releases, especially if they're not being run locally. Cheers JP From Axel.Thimm at ATrpms.net Thu Aug 9 12:27:49 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 9 Aug 2007 14:27:49 +0200 Subject: New db4 update and package changes In-Reply-To: <20070809090100.GA1165@dhcp-lab-186.brq.redhat.com> References: <20070809090100.GA1165@dhcp-lab-186.brq.redhat.com> Message-ID: <20070809122749.GA10454@puariko.nirvana> Hi, On Thu, Aug 09, 2007 at 11:01:00AM +0200, Jindrich Novy wrote: > you may have noticed Oracle released db-4.6.18 recently. The update is > now prepared in CVS, old db-4.5.20 is now moved to compat-db so the new > db4 is ready to hit rawhide soon. > > I want to announce a change I made in the new db4, that may affect > you from the packaging POV if your package is dependent on db4. It is > that I moved all the C++ stuff to db4-cxx and db4-cxx-devel subpackages > to reduce dependency bloat (#220484). > > If you have any proposals/objections related to the update, please speak up. I can understand the splitting of the runtime bits, but why split the *-devel package? If we start splitting devel we would need guidelines as to how far to split: foo-cxx-devel, foo-f90-devel, foo-python-devel? Or foo-gtk-devel, foo-qt-devel, foo-cxx-qt-3-but-not-4-devel etc. foo-devel is currently sacred, even library packages w/o such a subpackage have to provide it so, the packagers of build-dependent packages can simply trust that BR: foo-devel will ensure the bits are there. Now they would have to check whether foo has foo-cxx-devel, too, and whether that goes unnoticed by their bar detection scripts (e.g. bar just simlently builds C bindings etc). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Thu Aug 9 12:24:52 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 9 Aug 2007 14:24:52 +0200 Subject: packages.fedoraproject.org? In-Reply-To: <46BB0548.6010609@curioussymbols.com> References: <46BB0548.6010609@curioussymbols.com> Message-ID: <20070809122452.GB2927@free.fr> On Thu, Aug 09, 2007 at 10:15:04PM +1000, John Pye wrote: > Hi all > > I wonder if there's been any effort to set up a similar package browser > to that offered by Debian and Ubuntu. It's really invaluable to be able Yes, there is such effort, it should use the new repoview version. I launched such a subject some days ago. repoview doesn't offer everything that is in the ubuntu viewer. Maybe rpmfind would give more informtion (with links to provides/requires), but if I recall well it isn't maintained anymore. -- Pat From john at curioussymbols.com Thu Aug 9 12:43:34 2007 From: john at curioussymbols.com (John Pye) Date: Thu, 09 Aug 2007 22:43:34 +1000 Subject: packages.fedoraproject.org? In-Reply-To: <20070809122452.GB2927@free.fr> References: <46BB0548.6010609@curioussymbols.com> <20070809122452.GB2927@free.fr> Message-ID: <46BB0BF6.7040302@curioussymbols.com> Patrice Dumas wrote: > On Thu, Aug 09, 2007 at 10:15:04PM +1000, John Pye wrote: > >> Hi all >> >> I wonder if there's been any effort to set up a similar package browser >> to that offered by Debian and Ubuntu. It's really invaluable to be able >> > > Yes, there is such effort, it should use the new repoview version. I > launched such a subject some days ago. repoview doesn't offer > everything that is in the ubuntu viewer. Maybe rpmfind would give > more informtion (with links to provides/requires), but if I recall well > it isn't maintained anymore. > Great! Is there a wiki page where plans for this are being fleshed out? Cheers JP From tcallawa at redhat.com Thu Aug 9 12:58:43 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 09 Aug 2007 08:58:43 -0400 Subject: [Fedora-packaging] Re: New db4 update and package changes In-Reply-To: <20070809122749.GA10454@puariko.nirvana> References: <20070809090100.GA1165@dhcp-lab-186.brq.redhat.com> <20070809122749.GA10454@puariko.nirvana> Message-ID: <1186664323.5583.28.camel@localhost.localdomain> On Thu, 2007-08-09 at 14:27 +0200, Axel Thimm wrote: > Hi, > > On Thu, Aug 09, 2007 at 11:01:00AM +0200, Jindrich Novy wrote: > > you may have noticed Oracle released db-4.6.18 recently. The update is > > now prepared in CVS, old db-4.5.20 is now moved to compat-db so the new > > db4 is ready to hit rawhide soon. > > > > I want to announce a change I made in the new db4, that may affect > > you from the packaging POV if your package is dependent on db4. It is > > that I moved all the C++ stuff to db4-cxx and db4-cxx-devel subpackages > > to reduce dependency bloat (#220484). > > > > If you have any proposals/objections related to the update, please speak up. > > I can understand the splitting of the runtime bits, but why split the > *-devel package? +1. Splitting the -devel package is a rather significant alteration, for little benefit (and shouldn't increase dependency bloat). ~spot From tcallawa at redhat.com Thu Aug 9 13:03:09 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 09 Aug 2007 09:03:09 -0400 Subject: two questions In-Reply-To: <46BB00F3.8000204@curioussymbols.com> References: <46B9C360.1030801@curioussymbols.com> <3170f42f0708080634u3c99e2c8md686fd63ec6b48e2@mail.gmail.com> <46BB00F3.8000204@curioussymbols.com> Message-ID: <1186664590.5583.31.camel@localhost.localdomain> On Thu, 2007-08-09 at 21:56 +1000, John Pye wrote: > Debarshi 'Rishi' Ray wrote: > >> (2) once my package is uploaded at it gets the NEXTRELEASE status, how > >> does my package, which is currently shown with > >> 'dist-fc7-updates-candidate' tag in koji, end up eventually in the > >> Fedora Updates repository? Are there more steps that I need to follow? > >> Is there some other review happening? > >> > > > > http://fedoraproject.org/wiki/PackageMaintainers/Join#head-5fe724060ca02046dde01278eb83f8a02dca3929 > > > > You basically use Bodhi to request the package to be pushed to > > updates-testing. After staying there for a week or so, if there are no > > bugs you again request it to be pushed to updates. > > > > OK, as far as I can tell, I have pushed both 'fityk' and 'sundials' to > Fedora Updates Testing. Should I expect to see them here? > http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/7/i386/ > > If not, where? Or is there a delay? > > And where can I check to see that the package has gone out to FC6 users? > (is there a 'testing' repository for that one too?) Packages built in the FC-6/ branch (make build) will go out without any additional work. Packages built in the F-7/ branch (and future stable branches) will need to have an update generated in bodhi and be pushed to either testing or updates before they will show up in either the testing or updates repository. You'll get an email notifying you when this happens, there is a slight delay here. Packages built in the devel/ branch will go into the repo without any additional work. ~spot From tmraz at redhat.com Thu Aug 9 13:09:13 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 09 Aug 2007 15:09:13 +0200 Subject: [Fedora-packaging] Re: New db4 update and package changes In-Reply-To: <1186664323.5583.28.camel@localhost.localdomain> References: <20070809090100.GA1165@dhcp-lab-186.brq.redhat.com> <20070809122749.GA10454@puariko.nirvana> <1186664323.5583.28.camel@localhost.localdomain> Message-ID: <1186664953.3653.5.camel@vespa.kabelta.loc> On Thu, 2007-08-09 at 08:58 -0400, Tom "spot" Callaway wrote: > On Thu, 2007-08-09 at 14:27 +0200, Axel Thimm wrote: > > Hi, > > > > On Thu, Aug 09, 2007 at 11:01:00AM +0200, Jindrich Novy wrote: > > > you may have noticed Oracle released db-4.6.18 recently. The update is > > > now prepared in CVS, old db-4.5.20 is now moved to compat-db so the new > > > db4 is ready to hit rawhide soon. > > > > > > I want to announce a change I made in the new db4, that may affect > > > you from the packaging POV if your package is dependent on db4. It is > > > that I moved all the C++ stuff to db4-cxx and db4-cxx-devel subpackages > > > to reduce dependency bloat (#220484). > > > > > > If you have any proposals/objections related to the update, please speak up. > > > > I can understand the splitting of the runtime bits, but why split the > > *-devel package? > > +1. Splitting the -devel package is a rather significant alteration, for > little benefit (and shouldn't increase dependency bloat). It means that the db4-devel must require both db4 and db4-cxx packages. So there is a little bit of dependency bloat there. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From bugs.michael at gmx.net Thu Aug 9 13:13:08 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 9 Aug 2007 15:13:08 +0200 Subject: Build Error/Job Failed but package created successfully In-Reply-To: References: <10865.65.192.24.164.1186595236.squirrel@mail.jcomserv.net> Message-ID: <20070809151308.72b5f72f.bugs.michael@gmx.net> On Thu, 9 Aug 2007 07:37:36 -0400, Jeff Gilchrist wrote: > On 8/8/07, Jon Ciesla wrote: > > > I had this happen a week or so ago, and then retried the build a few days > > after, making no changes, and it was fine. > > I tried again this morning without any changes and it seemed to work > this time. Not sure what happened but didn't get any errors this > time. The problem is not gone, however. See fedora-devel-list, where it's reported that package "ssss" failed to built, although the logs don't contain any obvious error message and all binary rpms are available. Might be that there's a race condition in plague somewhere when building for multiple archs on a single build server. From Axel.Thimm at ATrpms.net Thu Aug 9 13:17:05 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 9 Aug 2007 15:17:05 +0200 Subject: New db4 update and package changes In-Reply-To: <1186664953.3653.5.camel@vespa.kabelta.loc> References: <20070809090100.GA1165@dhcp-lab-186.brq.redhat.com> <20070809122749.GA10454@puariko.nirvana> <1186664323.5583.28.camel@localhost.localdomain> <1186664953.3653.5.camel@vespa.kabelta.loc> Message-ID: <20070809131705.GA15517@puariko.nirvana> On Thu, Aug 09, 2007 at 03:09:13PM +0200, Tomas Mraz wrote: > > On Thu, 2007-08-09 at 08:58 -0400, Tom "spot" Callaway wrote: > > On Thu, 2007-08-09 at 14:27 +0200, Axel Thimm wrote: > > > Hi, > > > > > > On Thu, Aug 09, 2007 at 11:01:00AM +0200, Jindrich Novy wrote: > > > > you may have noticed Oracle released db-4.6.18 recently. The update is > > > > now prepared in CVS, old db-4.5.20 is now moved to compat-db so the new > > > > db4 is ready to hit rawhide soon. > > > > > > > > I want to announce a change I made in the new db4, that may affect > > > > you from the packaging POV if your package is dependent on db4. It is > > > > that I moved all the C++ stuff to db4-cxx and db4-cxx-devel subpackages > > > > to reduce dependency bloat (#220484). > > > > > > > > If you have any proposals/objections related to the update, please speak up. > > > > > > I can understand the splitting of the runtime bits, but why split the > > > *-devel package? > > > > +1. Splitting the -devel package is a rather significant alteration, for > > little benefit (and shouldn't increase dependency bloat). > It means that the db4-devel must require both db4 and db4-cxx packages. > So there is a little bit of dependency bloat there. Yes, but this is "just" build dependency bloat, not runtime, e.g. the end user is saved from the bloat, which is the main aspect of avoiding bloat. If you like compare it to the presence of both glibc and stdlibc++ in the default buildroot setup in Fedora, even if only a fraction of packages really builds for C++. -- 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 john at curioussymbols.com Thu Aug 9 13:48:11 2007 From: john at curioussymbols.com (John Pye) Date: Thu, 09 Aug 2007 23:48:11 +1000 Subject: two questions In-Reply-To: <1186664590.5583.31.camel@localhost.localdomain> References: <46B9C360.1030801@curioussymbols.com> <3170f42f0708080634u3c99e2c8md686fd63ec6b48e2@mail.gmail.com> <46BB00F3.8000204@curioussymbols.com> <1186664590.5583.31.camel@localhost.localdomain> Message-ID: <46BB1B1B.9020600@curioussymbols.com> Tom "spot" Callaway wrote: > On Thu, 2007-08-09 at 21:56 +1000, John Pye wrote: > >> Debarshi 'Rishi' Ray wrote: >> >>>> (2) once my package is uploaded at it gets the NEXTRELEASE status, how >>>> does my package, which is currently shown with >>>> 'dist-fc7-updates-candidate' tag in koji, end up eventually in the >>>> Fedora Updates repository? Are there more steps that I need to follow? >>>> Is there some other review happening? >>>> >>>> >>> http://fedoraproject.org/wiki/PackageMaintainers/Join#head-5fe724060ca02046dde01278eb83f8a02dca3929 >>> >>> You basically use Bodhi to request the package to be pushed to >>> updates-testing. After staying there for a week or so, if there are no >>> bugs you again request it to be pushed to updates. >>> >>> >> OK, as far as I can tell, I have pushed both 'fityk' and 'sundials' to >> Fedora Updates Testing. Should I expect to see them here? >> http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/7/i386/ >> >> If not, where? Or is there a delay? >> >> And where can I check to see that the package has gone out to FC6 users? >> (is there a 'testing' repository for that one too?) >> > > Packages built in the FC-6/ branch (make build) will go out without any > additional work. > I tried to find them in the 'repobrowser' but they're not there yet. What's the delay on that? Perhaps if I'm guessing, the repobrowser static pages are rebuilt nightly? > Packages built in the F-7/ branch (and future stable branches) will need > to have an update generated in bodhi and be pushed to either testing or > updates before they will show up in either the testing or updates > repository. You'll get an email notifying you when this happens, there > is a slight delay here. > Should I take that to mean minutes, hours or days? Where can I check authoritatively to determine that they are now available for general download? > Packages built in the devel/ branch will go into the repo without any > additional work. > OK Cheers JP From tcallawa at redhat.com Thu Aug 9 13:53:52 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 09 Aug 2007 09:53:52 -0400 Subject: two questions In-Reply-To: <46BB1B1B.9020600@curioussymbols.com> References: <46B9C360.1030801@curioussymbols.com> <3170f42f0708080634u3c99e2c8md686fd63ec6b48e2@mail.gmail.com> <46BB00F3.8000204@curioussymbols.com> <1186664590.5583.31.camel@localhost.localdomain> <46BB1B1B.9020600@curioussymbols.com> Message-ID: <1186667632.5583.41.camel@localhost.localdomain> On Thu, 2007-08-09 at 23:48 +1000, John Pye wrote: > I tried to find them in the 'repobrowser' but they're not there yet. > What's the delay on that? Perhaps if I'm guessing, the repobrowser > static pages are rebuilt nightly? I think that's right, but I'm not 100% sure on that. I know that you can almost immediately use built packages as BuildRequires for other packages here. There is a short delay while the packages are signed (which happens once a day, usually). > > Packages built in the F-7/ branch (and future stable branches) will need > > to have an update generated in bodhi and be pushed to either testing or > > updates before they will show up in either the testing or updates > > repository. You'll get an email notifying you when this happens, there > > is a slight delay here. > > > > Should I take that to mean minutes, hours or days? Where can I check > authoritatively to determine that they are now available for general > download? A day at the most. Logging into Bodhi and looking at "My Updates" will show you authoritatively where they are in the process. ~spot From bugs.michael at gmx.net Thu Aug 9 14:00:50 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 9 Aug 2007 16:00:50 +0200 Subject: two questions In-Reply-To: <46BB1B1B.9020600@curioussymbols.com> References: <46B9C360.1030801@curioussymbols.com> <3170f42f0708080634u3c99e2c8md686fd63ec6b48e2@mail.gmail.com> <46BB00F3.8000204@curioussymbols.com> <1186664590.5583.31.camel@localhost.localdomain> <46BB1B1B.9020600@curioussymbols.com> Message-ID: <20070809160050.b6f822a3.bugs.michael@gmx.net> On Thu, 09 Aug 2007 23:48:11 +1000, John Pye wrote: > Tom "spot" Callaway wrote: > > On Thu, 2007-08-09 at 21:56 +1000, John Pye wrote: > > > >> Debarshi 'Rishi' Ray wrote: > >> > >>>> (2) once my package is uploaded at it gets the NEXTRELEASE status, how > >>>> does my package, which is currently shown with > >>>> 'dist-fc7-updates-candidate' tag in koji, end up eventually in the > >>>> Fedora Updates repository? Are there more steps that I need to follow? > >>>> Is there some other review happening? > >>>> > >>>> > >>> http://fedoraproject.org/wiki/PackageMaintainers/Join#head-5fe724060ca02046dde01278eb83f8a02dca3929 > >>> > >>> You basically use Bodhi to request the package to be pushed to > >>> updates-testing. After staying there for a week or so, if there are no > >>> bugs you again request it to be pushed to updates. > >>> > >>> > >> OK, as far as I can tell, I have pushed both 'fityk' and 'sundials' to > >> Fedora Updates Testing. Should I expect to see them here? > >> http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/7/i386/ > >> > >> If not, where? Or is there a delay? > >> > >> And where can I check to see that the package has gone out to FC6 users? > >> (is there a 'testing' repository for that one too?) > >> > > > > Packages built in the FC-6/ branch (make build) will go out without any > > additional work. > > > > I tried to find them in the 'repobrowser' but they're not there yet. > What's the delay on that? Perhaps if I'm guessing, the repobrowser > static pages are rebuilt nightly? http://download.fedora.redhat.com/pub/fedora/linux/extras/6/SRPMS/repoview/ Plus the Fedora Extras build report sent to fedora-devel-list. From rjones at redhat.com Thu Aug 9 15:10:22 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 09 Aug 2007 16:10:22 +0100 Subject: ocaml on 'non-intel-arch' (WAS: Re: Make ppc64 secondary arch - don't block builds) In-Reply-To: <46BAEAA4.60703@linux-kernel.at> References: <20070806125214.GK18009@puariko.nirvana> <1186471604.30408.230.camel@shinybook.infradead.org> <46B81FE0.6060109@linux-kernel.at> <200708070704.24763.dennis@ausil.us> <46BAEAA4.60703@linux-kernel.at> Message-ID: <46BB2E5E.5020309@redhat.com> Oliver Falk wrote: > Well, after some testing now... ocaml builds fine on Alpha. BUT with the > old non-relaxed binutils... The new binutils with relax enabled by > default doesn't work. I was also not able to use --no-relax... However. Sorry, just seen this thread - it was rather buried :-) OCaml is supported on Alpha. Whether the RPM in Fedora works is another matter. Do you get an error with the "relax binutils" above? Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From oliver at linux-kernel.at Thu Aug 9 15:26:22 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 09 Aug 2007 17:26:22 +0200 Subject: ocaml on 'non-intel-arch' (WAS: Re: Make ppc64 secondary arch - don't block builds) In-Reply-To: <46BB2E5E.5020309@redhat.com> References: <20070806125214.GK18009@puariko.nirvana> <1186471604.30408.230.camel@shinybook.infradead.org> <46B81FE0.6060109@linux-kernel.at> <200708070704.24763.dennis@ausil.us> <46BAEAA4.60703@linux-kernel.at> <46BB2E5E.5020309@redhat.com> Message-ID: <46BB321E.4020503@linux-kernel.at> On 08/09/2007 05:10 PM, Richard W.M. Jones wrote: > Oliver Falk wrote: >> Well, after some testing now... ocaml builds fine on Alpha. BUT with the >> old non-relaxed binutils... The new binutils with relax enabled by >> default doesn't work. I was also not able to use --no-relax... However. > > Sorry, just seen this thread - it was rather buried :-) > > OCaml is supported on Alpha. Whether the RPM in Fedora works is another > matter. > > Do you get an error with the "relax binutils" above? Yes. Some of those "relocation truncated to fit"... Don't have the logs any more :-( However, working (alpha) ocaml: http://buildsys.zero42.at/koji/buildinfo?buildID=9172 Best, Oliver From Matt_Domsch at dell.com Thu Aug 9 16:40:07 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Thu, 9 Aug 2007 11:40:07 -0500 Subject: expat soname bump & mass rebuilds In-Reply-To: <20070808122152.606458c8@ender> References: <20070808161344.GA3946@redhat.com> <20070808122152.606458c8@ender> Message-ID: <20070809164007.GA20452@auslistsprd01.us.dell.com> On Wed, Aug 08, 2007 at 12:21:52PM -0400, Jesse Keating wrote: > On Wed, 8 Aug 2007 17:13:44 +0100 > Joe Orton wrote: > > > Is a mass rebuild planned at any point during this development > > cycle? e.g. for the buildid stuff? I think it would make sense to > > put off the expat update until then, if so, to avoid doing this many > > unnecessary builds. > > Yes, as well as for buildflags on ppc and for picking up licensing > clarifications. No date has emerged yet for this though, and test2 is > rapidly approaching. As an aside, I'm (still) trying to get a complete rebuild run done privately, to post as usual on linux.dell.com. It's taking a bit longer than expected mostly due to problems on my end, but hopefully I'll have nagmails to send by this weekend for everything that hasn't rebuilt cleanly against rawhide in the past 2 weeks. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From coldwell at redhat.com Thu Aug 9 19:45:10 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Thu, 9 Aug 2007 15:45:10 -0400 (EDT) Subject: Koji cannot build emacs Message-ID: Well, I think I've run into the same problem that openldap hit here https://www.redhat.com/archives/fedora-maintainers/2007-August/msg00013.html My build log has this gcc -c -D_BSD_SOURCE -Demacs -DHAVE_CONFIG_H -DUSE_GTK -I. -I/builddir/build/BUILD/emacs-22.1/src -D_BSD_SOURCE -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/freetype2 -DMAIL_USE_LOCKF -DSYSTEM_PURESIZE_EXTRA=16777216 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic sound.c sound.c: In function 'wav_play': sound.c:618: warning: pointer targets in passing argument 2 of 'sd->write' differ in signedness sound.c: In function 'au_play': sound.c:712: warning: pointer targets in passing argument 2 of 'sd->write' differ in signedness sound.c: In function 'Fplay_sound_internal': sound.c:1453: warning: pointer targets in passing argument 2 of '__builtin___strcpy_chk' differ in signedness sound.c:1453: warning: pointer targets in passing argument 2 of '__strcpy_ichk' differ in signedness sound.c:1472:51: error: macro "open" requires 3 arguments, but only 1 given sound.c:1472: warning: statement with no effect make[2]: *** [sound.o] Error 1 make[2]: Leaving directory `/builddir/build/BUILD/emacs-22.1/src' make[1]: *** [bootstrap-build] Error 2 make[1]: Leaving directory `/builddir/build/BUILD/emacs-22.1' make: *** [bootstrap] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.86876 (%build) What should I do ? Drop "-D_FORTIFY_SOURCE=2" from the CFLAGS? Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From jkeating at redhat.com Thu Aug 9 19:58:53 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 9 Aug 2007 15:58:53 -0400 Subject: Koji cannot build emacs In-Reply-To: References: Message-ID: <20070809155853.098e17b5@mentok.boston.redhat.com> On Thu, 9 Aug 2007 15:45:10 -0400 (EDT) Chip Coldwell wrote: > sound.c:1472:51: error: macro "open" requires 3 arguments, but only 1 > given sound.c:1472: warning: statement with no effect Jakub will tell you that you need to use your open better. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From roland at redhat.com Thu Aug 9 19:59:53 2007 From: roland at redhat.com (Roland McGrath) Date: Thu, 9 Aug 2007 12:59:53 -0700 (PDT) Subject: Koji cannot build emacs In-Reply-To: Chip Coldwell's message of Thursday, 9 August 2007 15:45:10 -0400 Message-ID: <20070809195954.9BC9C4D04CB@magilla.localdomain> > sound.c:1472:51: error: macro "open" requires 3 arguments, but only 1 given [...] > What should I do ? Drop "-D_FORTIFY_SOURCE=2" from the CFLAGS? Nope. Fix the program to be POSIX-compliant by not assuming open is not a macro. You can replace open or foo->open with (open) or (foo->open), or you can add an #undef open where it's used. The former is better. From roland at redhat.com Thu Aug 9 20:02:43 2007 From: roland at redhat.com (Roland McGrath) Date: Thu, 9 Aug 2007 13:02:43 -0700 (PDT) Subject: Koji cannot build emacs In-Reply-To: Jesse Keating's message of Thursday, 9 August 2007 15:58:53 -0400 <20070809155853.098e17b5@mentok.boston.redhat.com> Message-ID: <20070809200244.5FBF94D04CB@magilla.localdomain> > Jakub will tell you that you need to use your open better. Jakub is on vacation this week, so I'm telling you. :-) From coldwell at redhat.com Thu Aug 9 20:03:02 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Thu, 9 Aug 2007 16:03:02 -0400 (EDT) Subject: Koji cannot build emacs In-Reply-To: <20070809195954.9BC9C4D04CB@magilla.localdomain> References: <20070809195954.9BC9C4D04CB@magilla.localdomain> Message-ID: On Thu, 9 Aug 2007, Roland McGrath wrote: > > sound.c:1472:51: error: macro "open" requires 3 arguments, but only 1 given > [...] > > What should I do ? Drop "-D_FORTIFY_SOURCE=2" from the CFLAGS? > > Nope. Fix the program to be POSIX-compliant by not assuming open is not a > macro. You can replace open or foo->open with (open) or (foo->open), > or you can add an #undef open where it's used. The former is > better. This patch works: --- emacs-22.1/src/sound.c~ 2007-03-06 07:14:14.000000000 -0500 +++ emacs-22.1/src/sound.c 2007-08-09 15:54:52.117018000 -0400 @@ -1469,7 +1469,7 @@ Internal use only, use `play-sound' inst error ("No usable sound device driver found"); /* Open the device. */ - current_sound_device->open (current_sound_device); + (current_sound_device->open) (current_sound_device); /* Play the sound. */ current_sound->play (current_sound, current_sound_device); And I'm happy to build this way, however ... "open" has to be one of the most overloaded names in programming. Changing the semantics of that name is something that should be done very carefully and very reluctantly, and I don't care what POSIX says about it. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From alexl at users.sourceforge.net Fri Aug 10 08:48:48 2007 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Fri, 10 Aug 2007 01:48:48 -0700 Subject: Splitting a package--reviews needed? In-Reply-To: <46B1FCE2.7030604@ieee.org> (Quentin Spencer's message of "Thu\, 02 Aug 2007 10\:48\:50 -0500") References: <46B1FCE2.7030604@ieee.org> Message-ID: >>>>> "QS" == Quentin Spencer writes: QS> I am the maintainer of octave-forge, a set of add-on packages for QS> octave. The structure of the source package has been changed to QS> separate it into a number of sub-packages. I think it would be a QS> good idea to follow this structure in the Fedora package, QS> particularly since some sub-packages have external dependencies QS> that not all users may really need. The octave-forge package would QS> become a meta-package that just installs all of the QS> sub-packages. The question here is, should each of the new QS> sub-packages be subject to its own review? It's a total of almost QS> 40 packages, considerably more than I currently maintain, and I'm QS> worried that this will significantly increase the time commitment, QS> which I'm not sure I can do. Is there anyone out there who has a QS> particular interest in any of the octave-forge sub-packages who QS> may be interested in maintaining it? Hi Quentin, I'm interested in helping maintain octave-forge. I'm using octave quite extensively now, although I'm not sure how many packages I use are part of octave-forge itself, either way, I'm interested in keeping as many octave-forge packages alive in Fedora. I currently maintain the bioperl and biopython packages (and some dependencies), see: http://fedoraproject.org/wiki/AlexLancaster I looked a bit at the new octave-forge system, perhaps we could put all the octave-forge packages in the "Main" repository into one package and separately package the "Extras" packages if they require some extra large dependencies. That would cut down on the number of new packages to review. Alex From jnovy at redhat.com Fri Aug 10 08:47:50 2007 From: jnovy at redhat.com (Jindrich Novy) Date: Fri, 10 Aug 2007 10:47:50 +0200 Subject: New db4 update and package changes In-Reply-To: <20070809131705.GA15517@puariko.nirvana> References: <20070809090100.GA1165@dhcp-lab-186.brq.redhat.com> <20070809122749.GA10454@puariko.nirvana> <1186664323.5583.28.camel@localhost.localdomain> <1186664953.3653.5.camel@vespa.kabelta.loc> <20070809131705.GA15517@puariko.nirvana> Message-ID: <20070810084750.GB30469@dhcp-lab-186.brq.redhat.com> On Thu, Aug 09, 2007 at 03:17:05PM +0200, Axel Thimm wrote: > On Thu, Aug 09, 2007 at 03:09:13PM +0200, Tomas Mraz wrote: > > > > On Thu, 2007-08-09 at 08:58 -0400, Tom "spot" Callaway wrote: > > > On Thu, 2007-08-09 at 14:27 +0200, Axel Thimm wrote: > > > > Hi, > > > > > > > > On Thu, Aug 09, 2007 at 11:01:00AM +0200, Jindrich Novy wrote: > > > > > you may have noticed Oracle released db-4.6.18 recently. The update is > > > > > now prepared in CVS, old db-4.5.20 is now moved to compat-db so the new > > > > > db4 is ready to hit rawhide soon. > > > > > > > > > > I want to announce a change I made in the new db4, that may affect > > > > > you from the packaging POV if your package is dependent on db4. It is > > > > > that I moved all the C++ stuff to db4-cxx and db4-cxx-devel subpackages > > > > > to reduce dependency bloat (#220484). > > > > > > > > > > If you have any proposals/objections related to the update, please speak up. > > > > > > > > I can understand the splitting of the runtime bits, but why split the > > > > *-devel package? > > > > > > +1. Splitting the -devel package is a rather significant alteration, for > > > little benefit (and shouldn't increase dependency bloat). > > > It means that the db4-devel must require both db4 and db4-cxx packages. > > So there is a little bit of dependency bloat there. > > Yes, but this is "just" build dependency bloat, not runtime, e.g. the > end user is saved from the bloat, which is the main aspect of avoiding > bloat. > Ok, I removed the db4-cxx-devel and put the C++ stuff back to db4-devel. I don't like this solution too much as it introduces some bloat even though it's -devel, but let it be if it eases things for packagers. Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From jorton at redhat.com Fri Aug 10 09:32:12 2007 From: jorton at redhat.com (Joe Orton) Date: Fri, 10 Aug 2007 10:32:12 +0100 Subject: expat soname bump & mass rebuilds In-Reply-To: <20070809164007.GA20452@auslistsprd01.us.dell.com> References: <20070808161344.GA3946@redhat.com> <20070808122152.606458c8@ender> <20070809164007.GA20452@auslistsprd01.us.dell.com> Message-ID: <20070810093211.GA17811@redhat.com> On Thu, Aug 09, 2007 at 11:40:07AM -0500, Matt Domsch wrote: > As an aside, I'm (still) trying to get a complete rebuild run done > privately, to post as usual on linux.dell.com. It's taking a bit > longer than expected mostly due to problems on my end, but hopefully > I'll have nagmails to send by this weekend for everything that hasn't > rebuilt cleanly against rawhide in the past 2 weeks. This would be really useful. I've so far rebuilt 54 packages and had 6 break due to the glibc open() changes. If this is a representative sample, there are a lot of broken packages out there needing work. joe From buildsys at fedoraproject.org Fri Aug 10 20:22:32 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 10 Aug 2007 16:22:32 -0400 (EDT) Subject: Package EVR problems in Fedora 2007-08-10 Message-ID: <20070810202232.970AF152134@buildsys.fedoraproject.org> Axel.Thimm AT ATrpms.net: smart FE6 > F7-updates (0:0.50-47.fc6 > 0:0.50-46.fc7) FE6 > F8 (0:0.50-47.fc6 > 0:0.50-46.fc8) alexl AT redhat.com: xdg-user-dirs F7-updates > F8 (0:0.8-3.fc7 > 0:0.8-2.fc8) cweyl AT alumni.drew.edu: perl-Algorithm-C3 FE5 > F7 (0:0.07-1.fc5 > 0:0.06-1.fc7) FE6 > F7 (0:0.07-1.fc6 > 0:0.06-1.fc7) perl-CGI-Ex FE5 > F7 (0:2.13-1.fc5 > 0:2.12-1.fc7) FE6 > F7 (0:2.13-1.fc6 > 0:2.12-1.fc7) perl-Class-C3 FE5 > F7 (0:0.18-1.fc5 > 0:0.14-1.fc6) FE6 > F7 (0:0.18-1.fc6 > 0:0.14-1.fc6) perl-Class-C3-XS FE5 > F7 (0:0.06-1.fc5 > 0:0.04-1.fc7) FE6 > F7 (0:0.08-1.fc6 > 0:0.04-1.fc7) perl-Class-Data-Accessor FE5 > F7 (0:0.04001-1.fc5 > 0:0.04000-3.fc7) FE6 > F7 (0:0.04001-1.fc6 > 0:0.04000-3.fc7) perl-Class-MOP FE5 > F7 (0:0.38-1.fc5 > 0:0.37-1.fc7) FE6 > F7 (0:0.38-1.fc6 > 0:0.37-1.fc7) perl-Data-Alias FE5 > F7 (0:1.05-1.fc5 > 0:1.04-1.fc7) FE6 > F7 (0:1.05-1.fc6 > 0:1.04-1.fc7) perl-DBD-Mock FE6 > F7 (0:1.35-1.fc6 > 0:1.34-2.fc7) perl-Event FE6 > F7 (0:1.09-1.fc6 > 0:1.08-1.fc7) perl-Gtk2-Notify FE6 > F7 (0:0.03-1.fc6 > 0:0.02-4.fc7) perl-Gtk2-TrayIcon FE5 > F7 (0:0.06-1.fc5 > 0:0.03-3.fc6) FE6 > F7 (0:0.06-1.fc6 > 0:0.03-3.fc6) perl-JSON-XS FE5 > F7 (0:1.22-1.fc5 > 0:1.21-3.fc7) FE6 > F7 (0:1.43-1.fc6 > 0:1.21-3.fc7) perl-Moose FE5 > F7 (0:0.22-1.fc5 > 0:0.21-1.fc7) FE6 > F7 (0:0.22-1.fc6 > 0:0.21-1.fc7) perl-Net-DBus FE6 > F7 (0:0.33.5-1.fc6 > 0:0.33.4-3.fc7) perl-POE-Component-Server-SOAP FE5 > F7 (0:1.11-1.fc5 > 0:1.10-1.fc6) FE6 > F7 (0:1.11-1.fc6 > 0:1.10-1.fc6) perl-POE-Component-SimpleDBI FE5 > F7 (0:1.16-1.fc5 > 0:1.15-1.fc6) FE6 > F7 (0:1.16-1.fc6 > 0:1.15-1.fc6) perl-POE-Component-SSLify FE5 > F7 (0:0.08-1.fc5 > 0:0.07-1.fc7) FE6 > F7 (0:0.08-1.fc6 > 0:0.07-1.fc7) perl-Sub-Exporter FE5 > F7 (0:0.974-1.fc5 > 0:0.972-1.fc7) FE6 > F7 (0:0.975-1.fc6 > 0:0.972-1.fc7) davidz AT redhat.com: dbus-python F7-updates-testing > F8 (0:0.82.0-2.fc7 > 0:0.82.0-1.fc8) redhat-artwork F7-updates > F8 (0:7.0.0-11.fc7 > 0:7.0.0-10.fc8) ed AT eh3.com: scrip FE6 > F7 (0:1.4-7.fc6 > 0:1.4-6.fc6) FE6 > F8 (0:1.4-7.fc6 > 0:1.4-6.fc6) enrico.scholz AT informatik.tu-chemnitz.de: clamav F7-updates-testing > F8 (0:0.91.1-1.fc7 > 0:0.91.1-0.fc8) fedora-usermgmt FE6 > F7 (0:0.10-1.fc6 > 0:0.9-2.fc7) libtasn1 FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE5 > F8 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE6 > F7 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) FE6 > F8 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) mimetic FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7) FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7) util-vserver FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7) FE6 > F7 (0:0.30.213-2.fc6 > 0:0.30.212-3.fc7) xmlrpc-c FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7) FE6 > F7 (0:1.06.16-1.fc6 > 0:1.06.11-2.fc7) foolish AT guezz.net: gtranslator F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8) perl-Net-Libdnet F7-updates > F8 (0:0.01-3.fc7.1 > 0:0.01-2.fc8) perl-Nmap-Parser F7-updates > F8 (0:1.05-4.fc7 > 0:1.05-3.fc8) harald AT redhat.com: udev F7-updates > F8 (0:113-9.fc7 > 0:113-8.fc8) jakub AT redhat.com: gcc FC6-updates > F7 (0:4.1.2-13.fc6 > 0:4.1.2-12) jeff AT ocjtech.us: jrtplib FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) jjohnstn AT redhat.com: eclipse-cdt FC4-updates > F8 (1:3.0.0_fc-1.FC4 > 0:4.0.0-1.fc8) FC5 > F8 (1:3.0.2-1jpp_2fc > 0:4.0.0-1.fc8) FC6-updates > F8 (1:3.1.2-4.fc6 > 0:4.0.0-1.fc8) F7-updates-testing > F8 (1:3.1.2-6.fc7 > 0:4.0.0-1.fc8) kevin AT tummy.com: twinkle FE6 > F7-updates (0:1.1-2.fc6 > 0:1.1-1.fc7) kzak AT redhat.com: util-linux F7-updates-testing > F8 (0:2.13-0.54.fc7 > 0:2.13-0.52.fc7) lemenkov AT gmail.com: stratagus FE6 > F7 (0:2.2.4-1.fc6 > 0:2.2.3-1.fc7) lxtnow AT gmail.com: gammu FE6 > F8 (0:1.12.92-1.fc6 > 0:1.11.0-1.fc8) F7-updates-testing > F8 (0:1.12.92-1.fc7 > 0:1.11.0-1.fc8) python-gammu FE6 > F7-updates (0:0.21-1.fc6 > 0:0.20-1.fc7) FE6 > F8 (0:0.21-1.fc6 > 0:0.20-1.fc7) specto FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8) F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8) mdehaan AT redhat.com: cobbler FE6 > F7 (0:0.6.0-1.fc6 > 0:0.4.8-1.fc7) FE6 > F8 (0:0.6.0-1.fc6 > 0:0.4.8-1.fc7) koan FE6 > F7-updates (0:0.6.0-1.fc6 > 0:0.4.0-2.fc7) FE6 > F8 (0:0.6.0-1.fc6 > 0:0.4.0-2.fc7) meme AT daughtersoftiresias.org: fortune-firefly FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6) FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6) mikeb AT redhat.com: python-cheetah FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) FE6 > F8 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) nhorman AT redhat.com: irqbalance FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6) FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7) FC5-updates > F8 (2:0.55-4.fc5 > 2:0.55-3.fc8) paul AT xelerance.com: xl2tpd FE6 > F7 (0:1.1.11-2.fc6 > 0:1.1.09-1.fc7) pawsa AT theochem.kth.se: balsa F7-updates > F8 (0:2.3.17-2.fc7 > 0:2.3.17-1.fc8) rdieter AT math.unl.edu: kdeartwork-extras FE6 > F7 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) FE6 > F8 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) maxima FE5 > F7-updates (0:5.12.0-3.fc5 > 0:5.12.0-2.fc7) FE6 > F7-updates (0:5.12.0-3.fc6 > 0:5.12.0-2.fc7) ruben AT rubenkerkhof.com: perl-MogileFS-Utils FE6 > F7-updates (0:2.12-1.fc6 > 0:2.11-1.fc7) sandmann AT redhat.com: libgtop2 FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7) splinux AT fedoraproject.org: lostirc FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7) FE6 > F8 (0:0.4.6-3.fc6 > 0:0.4.6-2.fc8) than AT redhat.com: kdemultimedia FC6-updates > F7-updates (6:3.5.7-1.fc6 > 6:3.5.7-0.1.fc7) kdepim F7-updates > F8 (6:3.5.7-3.fc7 > 6:3.5.7-2.fc8) veillard AT redhat.com: libxml2 FC6-updates > F8 (0:2.6.29-1.fc6 > 0:2.6.29-1) F7-updates > F8 (0:2.6.29-1.fc7 > 0:2.6.29-1) ville.skytta AT iki.fi: em8300 FE6 > F7-updates (0:0.16.3-0.1.rc3.fc6 > 0:0.16.3-0.1.rc2.fc7) FE6 > F8 (0:0.16.3-0.1.rc3.fc6 > 0:0.16.3-0.1.rc2.fc8) em8300-kmod FE6 > F7-updates (0:0.16.3-0.2.rc3.2.6.22.1_32.fc6 > 0:0.16.3-0.1.rc2.2.6.22.1_41.fc7) wolters.liste AT gmx.net: speedcrunch FE6 > F7 (0:0.8-4.fc6 > 0:0.7-1.fc7) ---------------------------------------------------------------------- balsa: pawsa AT theochem.kth.se F7-updates > F8 (0:2.3.17-2.fc7 > 0:2.3.17-1.fc8) clamav: enrico.scholz AT informatik.tu-chemnitz.de F7-updates-testing > F8 (0:0.91.1-1.fc7 > 0:0.91.1-0.fc8) cobbler: mdehaan AT redhat.com FE6 > F7 (0:0.6.0-1.fc6 > 0:0.4.8-1.fc7) FE6 > F8 (0:0.6.0-1.fc6 > 0:0.4.8-1.fc7) dbus-python: davidz AT redhat.com F7-updates-testing > F8 (0:0.82.0-2.fc7 > 0:0.82.0-1.fc8) eclipse-cdt: jjohnstn AT redhat.com FC4-updates > F8 (1:3.0.0_fc-1.FC4 > 0:4.0.0-1.fc8) FC5 > F8 (1:3.0.2-1jpp_2fc > 0:4.0.0-1.fc8) FC6-updates > F8 (1:3.1.2-4.fc6 > 0:4.0.0-1.fc8) F7-updates-testing > F8 (1:3.1.2-6.fc7 > 0:4.0.0-1.fc8) em8300: ville.skytta AT iki.fi FE6 > F7-updates (0:0.16.3-0.1.rc3.fc6 > 0:0.16.3-0.1.rc2.fc7) FE6 > F8 (0:0.16.3-0.1.rc3.fc6 > 0:0.16.3-0.1.rc2.fc8) em8300-kmod: ville.skytta AT iki.fi FE6 > F7-updates (0:0.16.3-0.2.rc3.2.6.22.1_32.fc6 > 0:0.16.3-0.1.rc2.2.6.22.1_41.fc7) fedora-usermgmt: enrico.scholz AT informatik.tu-chemnitz.de FE6 > F7 (0:0.10-1.fc6 > 0:0.9-2.fc7) fortune-firefly: meme AT daughtersoftiresias.org FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6) FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6) gammu: lxtnow AT gmail.com FE6 > F8 (0:1.12.92-1.fc6 > 0:1.11.0-1.fc8) F7-updates-testing > F8 (0:1.12.92-1.fc7 > 0:1.11.0-1.fc8) gcc: jakub AT redhat.com FC6-updates > F7 (0:4.1.2-13.fc6 > 0:4.1.2-12) gtranslator: foolish AT guezz.net F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8) irqbalance: nhorman AT redhat.com FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6) FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7) FC5-updates > F8 (2:0.55-4.fc5 > 2:0.55-3.fc8) jrtplib: jeff AT ocjtech.us FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) kdeartwork-extras: rdieter AT math.unl.edu FE6 > F7 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) FE6 > F8 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) kdemultimedia: than AT redhat.com FC6-updates > F7-updates (6:3.5.7-1.fc6 > 6:3.5.7-0.1.fc7) kdepim: than AT redhat.com F7-updates > F8 (6:3.5.7-3.fc7 > 6:3.5.7-2.fc8) koan: mdehaan AT redhat.com FE6 > F7-updates (0:0.6.0-1.fc6 > 0:0.4.0-2.fc7) FE6 > F8 (0:0.6.0-1.fc6 > 0:0.4.0-2.fc7) libgtop2: sandmann AT redhat.com FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7) libtasn1: enrico.scholz AT informatik.tu-chemnitz.de FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE5 > F8 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE6 > F7 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) FE6 > F8 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) libxml2: veillard AT redhat.com FC6-updates > F8 (0:2.6.29-1.fc6 > 0:2.6.29-1) F7-updates > F8 (0:2.6.29-1.fc7 > 0:2.6.29-1) lostirc: splinux AT fedoraproject.org FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7) FE6 > F8 (0:0.4.6-3.fc6 > 0:0.4.6-2.fc8) maxima: rdieter AT math.unl.edu FE5 > F7-updates (0:5.12.0-3.fc5 > 0:5.12.0-2.fc7) FE6 > F7-updates (0:5.12.0-3.fc6 > 0:5.12.0-2.fc7) mimetic: enrico.scholz AT informatik.tu-chemnitz.de FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7) FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7) perl-Algorithm-C3: cweyl AT alumni.drew.edu FE5 > F7 (0:0.07-1.fc5 > 0:0.06-1.fc7) FE6 > F7 (0:0.07-1.fc6 > 0:0.06-1.fc7) perl-CGI-Ex: cweyl AT alumni.drew.edu FE5 > F7 (0:2.13-1.fc5 > 0:2.12-1.fc7) FE6 > F7 (0:2.13-1.fc6 > 0:2.12-1.fc7) perl-Class-C3: cweyl AT alumni.drew.edu FE5 > F7 (0:0.18-1.fc5 > 0:0.14-1.fc6) FE6 > F7 (0:0.18-1.fc6 > 0:0.14-1.fc6) perl-Class-C3-XS: cweyl AT alumni.drew.edu FE5 > F7 (0:0.06-1.fc5 > 0:0.04-1.fc7) FE6 > F7 (0:0.08-1.fc6 > 0:0.04-1.fc7) perl-Class-Data-Accessor: cweyl AT alumni.drew.edu FE5 > F7 (0:0.04001-1.fc5 > 0:0.04000-3.fc7) FE6 > F7 (0:0.04001-1.fc6 > 0:0.04000-3.fc7) perl-Class-MOP: cweyl AT alumni.drew.edu FE5 > F7 (0:0.38-1.fc5 > 0:0.37-1.fc7) FE6 > F7 (0:0.38-1.fc6 > 0:0.37-1.fc7) perl-Data-Alias: cweyl AT alumni.drew.edu FE5 > F7 (0:1.05-1.fc5 > 0:1.04-1.fc7) FE6 > F7 (0:1.05-1.fc6 > 0:1.04-1.fc7) perl-DBD-Mock: cweyl AT alumni.drew.edu FE6 > F7 (0:1.35-1.fc6 > 0:1.34-2.fc7) perl-Event: cweyl AT alumni.drew.edu FE6 > F7 (0:1.09-1.fc6 > 0:1.08-1.fc7) perl-Gtk2-Notify: cweyl AT alumni.drew.edu FE6 > F7 (0:0.03-1.fc6 > 0:0.02-4.fc7) perl-Gtk2-TrayIcon: cweyl AT alumni.drew.edu FE5 > F7 (0:0.06-1.fc5 > 0:0.03-3.fc6) FE6 > F7 (0:0.06-1.fc6 > 0:0.03-3.fc6) perl-JSON-XS: cweyl AT alumni.drew.edu FE5 > F7 (0:1.22-1.fc5 > 0:1.21-3.fc7) FE6 > F7 (0:1.43-1.fc6 > 0:1.21-3.fc7) perl-MogileFS-Utils: ruben AT rubenkerkhof.com FE6 > F7-updates (0:2.12-1.fc6 > 0:2.11-1.fc7) perl-Moose: cweyl AT alumni.drew.edu FE5 > F7 (0:0.22-1.fc5 > 0:0.21-1.fc7) FE6 > F7 (0:0.22-1.fc6 > 0:0.21-1.fc7) perl-Net-DBus: cweyl AT alumni.drew.edu FE6 > F7 (0:0.33.5-1.fc6 > 0:0.33.4-3.fc7) perl-Net-Libdnet: foolish AT guezz.net F7-updates > F8 (0:0.01-3.fc7.1 > 0:0.01-2.fc8) perl-Nmap-Parser: foolish AT guezz.net F7-updates > F8 (0:1.05-4.fc7 > 0:1.05-3.fc8) perl-POE-Component-Server-SOAP: cweyl AT alumni.drew.edu FE5 > F7 (0:1.11-1.fc5 > 0:1.10-1.fc6) FE6 > F7 (0:1.11-1.fc6 > 0:1.10-1.fc6) perl-POE-Component-SimpleDBI: cweyl AT alumni.drew.edu FE5 > F7 (0:1.16-1.fc5 > 0:1.15-1.fc6) FE6 > F7 (0:1.16-1.fc6 > 0:1.15-1.fc6) perl-POE-Component-SSLify: cweyl AT alumni.drew.edu FE5 > F7 (0:0.08-1.fc5 > 0:0.07-1.fc7) FE6 > F7 (0:0.08-1.fc6 > 0:0.07-1.fc7) perl-Sub-Exporter: cweyl AT alumni.drew.edu FE5 > F7 (0:0.974-1.fc5 > 0:0.972-1.fc7) FE6 > F7 (0:0.975-1.fc6 > 0:0.972-1.fc7) python-cheetah: mikeb AT redhat.com FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) FE6 > F8 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) python-gammu: lxtnow AT gmail.com FE6 > F7-updates (0:0.21-1.fc6 > 0:0.20-1.fc7) FE6 > F8 (0:0.21-1.fc6 > 0:0.20-1.fc7) redhat-artwork: davidz AT redhat.com F7-updates > F8 (0:7.0.0-11.fc7 > 0:7.0.0-10.fc8) scrip: ed AT eh3.com FE6 > F7 (0:1.4-7.fc6 > 0:1.4-6.fc6) FE6 > F8 (0:1.4-7.fc6 > 0:1.4-6.fc6) smart: Axel.Thimm AT ATrpms.net FE6 > F7-updates (0:0.50-47.fc6 > 0:0.50-46.fc7) FE6 > F8 (0:0.50-47.fc6 > 0:0.50-46.fc8) specto: lxtnow AT gmail.com FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8) F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8) speedcrunch: wolters.liste AT gmx.net FE6 > F7 (0:0.8-4.fc6 > 0:0.7-1.fc7) stratagus: lemenkov AT gmail.com FE6 > F7 (0:2.2.4-1.fc6 > 0:2.2.3-1.fc7) twinkle: kevin AT tummy.com FE6 > F7-updates (0:1.1-2.fc6 > 0:1.1-1.fc7) udev: harald AT redhat.com F7-updates > F8 (0:113-9.fc7 > 0:113-8.fc8) util-linux: kzak AT redhat.com F7-updates-testing > F8 (0:2.13-0.54.fc7 > 0:2.13-0.52.fc7) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7) FE6 > F7 (0:0.30.213-2.fc6 > 0:0.30.212-3.fc7) xdg-user-dirs: alexl AT redhat.com F7-updates > F8 (0:0.8-3.fc7 > 0:0.8-2.fc8) xl2tpd: paul AT xelerance.com FE6 > F7 (0:1.1.11-2.fc6 > 0:1.1.09-1.fc7) xmlrpc-c: enrico.scholz AT informatik.tu-chemnitz.de FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7) FE6 > F7 (0:1.06.16-1.fc6 > 0:1.06.11-2.fc7) From overholt at redhat.com Fri Aug 10 21:00:55 2007 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 10 Aug 2007 17:00:55 -0400 Subject: Package rename upstream Message-ID: <20070810210053.GA9229@redhat.com> Hi, Mylar (eclipse-mylar) has been renamed upstream to Mylyn for trademark reasons. Ben Konrath and I did the work to rename the package and add Provides/Obsoletes in the specfile and I've committed it all to its devel branch. However, I left the specfile as eclipse-mylar.spec. Can we/should we re-name the specfile and/or the CVS module? I couldn't find anything related to this on the wiki. Does searching even work? I tried searching for text that I *knew* was on a page (Renaming) and it found no results. What gives? Thanks, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Fri Aug 10 21:03:37 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 11 Aug 2007 02:33:37 +0530 Subject: Package rename upstream In-Reply-To: <20070810210053.GA9229@redhat.com> References: <20070810210053.GA9229@redhat.com> Message-ID: <46BCD2A9.1060104@fedoraproject.org> Andrew Overholt wrote: e? > > I couldn't find anything related to this on the wiki. Does searching > even work? I tried searching for text that I *knew* was on a page > (Renaming) and it found no results. What gives? What did you search for and what page is it in? Did you click on the text instead of title for searching? Rahul From dcantrell at redhat.com Fri Aug 10 21:28:59 2007 From: dcantrell at redhat.com (David Cantrell) Date: Fri, 10 Aug 2007 17:28:59 -0400 Subject: pyparted relicensed Message-ID: <20070810172859.14bdbea4.dcantrell@redhat.com> pyparted has been relicensed under the GPL v2 or any later version starting with pyparted-1.8.9-1.fc8 -- David Cantrell Red Hat / Westford, MA -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Fri Aug 10 21:29:01 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 11 Aug 2007 02:59:01 +0530 Subject: build-id magic In-Reply-To: <20070809095157.GA2797@puariko.nirvana> References: <20070809013216.1EB524D04C4@magilla.localdomain> <20070809095157.GA2797@puariko.nirvana> Message-ID: <46BCD89D.306@fedoraproject.org> Axel Thimm wrote: > On Wed, Aug 08, 2007 at 06:32:16PM -0700, Roland McGrath wrote: >> The intended changes are the build-id magic, [...] > > I've seen this floating around a lot lately, but did not have the time > to follow up the discussions. Is there a pointer to some nice summary > of what this does and why we should buy it? :) http://fedoraproject.org/wiki/Releases/FeatureBuildId Rahul From j.w.r.degoede at hhs.nl Fri Aug 10 21:49:31 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 10 Aug 2007 23:49:31 +0200 Subject: pyparted relicensed In-Reply-To: <20070810172859.14bdbea4.dcantrell@redhat.com> References: <20070810172859.14bdbea4.dcantrell@redhat.com> Message-ID: <46BCDD6B.8020107@hhs.nl> David Cantrell wrote: > pyparted has been relicensed under the GPL v2 or any later version starting with pyparted-1.8.9-1.fc8 > Coming from? If it was GPL v2 only, I don't think its necessary to announce packages going to a wider choice of license options. Spot (or others in the know) is it? Regards, Hans From jspaleta at gmail.com Fri Aug 10 22:02:13 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 10 Aug 2007 14:02:13 -0800 Subject: pyparted relicensed In-Reply-To: <46BCDD6B.8020107@hhs.nl> References: <20070810172859.14bdbea4.dcantrell@redhat.com> <46BCDD6B.8020107@hhs.nl> Message-ID: <604aa7910708101502l3fdcf0c4i3b778b6d87a0830b@mail.gmail.com> On 8/10/07, Hans de Goede wrote: > Coming from? If it was GPL v2 only, I don't think its necessary to announce > packages going to a wider choice of license options. Spot (or others in the > know) is it? actually is still useful to know, because it gives people more options that might have otherwise been restricted. While not as critical in terms of need-to-know communication, its still appreciated. -jef From jkeating at redhat.com Fri Aug 10 21:59:54 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 10 Aug 2007 17:59:54 -0400 Subject: pyparted relicensed In-Reply-To: <46BCDD6B.8020107@hhs.nl> References: <20070810172859.14bdbea4.dcantrell@redhat.com> <46BCDD6B.8020107@hhs.nl> Message-ID: <20070810175954.4335edf9@ender> On Fri, 10 Aug 2007 23:49:31 +0200 Hans de Goede wrote: > Coming from? If it was GPL v2 only, I don't think its necessary to > announce packages going to a wider choice of license options. Spot > (or others in the know) is it? 2+ means it can be received as gplv3, or contributed to as gplv3 which has some interesting complications. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tibbs at math.uh.edu Fri Aug 10 22:30:55 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 10 Aug 2007 17:30:55 -0500 Subject: Package rename upstream In-Reply-To: <20070810210053.GA9229@redhat.com> References: <20070810210053.GA9229@redhat.com> Message-ID: >>>>> "AO" == Andrew Overholt writes: AO> I couldn't find anything related to this on the wiki. http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure "If you need other special changes done which cannot be handled by the template fields, like renaming of a package, or complete removal of a package or branch due to rare circumstances, please state your desire and justification below the template in your Bugzilla comment." - J< From jspaleta at gmail.com Sat Aug 11 04:50:51 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 10 Aug 2007 20:50:51 -0800 Subject: This week: Virtual FudCon8 !!! In-Reply-To: <604aa7910708102149u457edcc0o2d670858f508eb2a@mail.gmail.com> References: <604aa7910708102149u457edcc0o2d670858f508eb2a@mail.gmail.com> Message-ID: <604aa7910708102150u28ec8ac7h17f4e4912fc1ee8@mail.gmail.com> Announcing Fedora 8's Online FUDCon: http://fedoraproject.org/wiki/FUDCon/FUDConF8 Come join us over the next few days for our first online community conference where Fedora developers will be discussing features and projects that will be impacting Fedora 8 and beyond. <-> When <-> Aug 11 - Aug 15 <-> What <-> This FudCon will be organized as a collection of IRC based topical sessions, supplemented by Fedora's new call-in sip server. Due to the global nature of the Fedora development community, sessions are scheduled individually by presenters. If you are interested in attending a session please check the session schedule each day for scheduling updates. <-> Where <-> Sessions will be making use of the Freenode IRC network (irc://irc.freenode.net). Presentations will nominally be held in channel: #fudcon . Some presentations may also make use of Fedora's new collaborative call-in server using conference room: sip:fudcon at fedoraproject.org . Please check the session schedule for specific session topics, times and locations. <-> Schedule <-> The current schedule of events can be found at: http://fedoraproject.org/wiki/JefSpaleta/VirtualFudCon The session schedule is still evolving. If you are interested in attending session please check the the schedule page for updates for time and location. New session presenters are also invited to add a session later in the FudCon period. Please see the schedule page for instructions on how to add a session topic. -jef From Jochen at herr-schmitt.de Sun Aug 12 21:01:34 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Sun, 12 Aug 2007 23:01:34 +0200 Subject: License review for new itext version Message-ID: <46BF752E.4030500@herr-schmitt.de> Hello, in the past we have removed itext and pdftk which depends on itext from the Fedora distribution due license issue. In the new iText package itext-2.0.4 I have found a text file about the licensing situation of the source file coming from Sun Corporation Inc. I have uploaded this file for review on http://www.herr-schmitt.de/pub/itext/sun.txt I want to know, it this ok for Fedora. But I assume, that the last term about usage this file for nuclear weapons may be a blocker. Best Regards: Jochen Schmitt From jonathan.underwood at gmail.com Sun Aug 12 21:07:10 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 12 Aug 2007 22:07:10 +0100 Subject: License review for new itext version In-Reply-To: <46BF752E.4030500@herr-schmitt.de> References: <46BF752E.4030500@herr-schmitt.de> Message-ID: <645d17210708121407t6221f887r8f27bcce91a93245@mail.gmail.com> On 12/08/07, Jochen Schmitt wrote: > Hello, > > in the past we have removed itext and pdftk which depends on itext from > the Fedora distribution due > license issue. > > In the new iText package itext-2.0.4 I have found a text file about the > licensing situation of the > source file coming from Sun Corporation Inc. > > I have uploaded this file for review on > > http://www.herr-schmitt.de/pub/itext/sun.txt > > I want to know, it this ok for Fedora. But I assume, that the last term > about usage this > file for nuclear weapons may be a blocker. Not wishing to be pedantic, but "nuclear facility" does not necessarily imply "nuclear weapons". From sundaram at fedoraproject.org Sun Aug 12 21:12:47 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 13 Aug 2007 02:42:47 +0530 Subject: License review for new itext version In-Reply-To: <46BF752E.4030500@herr-schmitt.de> References: <46BF752E.4030500@herr-schmitt.de> Message-ID: <46BF77CF.5090404@fedoraproject.org> Jochen Schmitt wrote: > Hello, > > in the past we have removed itext and pdftk which depends on itext from > the Fedora distribution due > license issue. > > In the new iText package itext-2.0.4 I have found a text file about the > licensing situation of the > source file coming from Sun Corporation Inc. > > I have uploaded this file for review on > > http://www.herr-schmitt.de/pub/itext/sun.txt > > I want to know, it this ok for Fedora. But I assume, that the last term > about usage this > file for nuclear weapons may be a blocker. This looks like the revised BSD license with a use restriction that makes it non-free. Rahul From j.w.r.degoede at hhs.nl Sun Aug 12 21:13:44 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 12 Aug 2007 23:13:44 +0200 Subject: License review for new itext version In-Reply-To: <46BF752E.4030500@herr-schmitt.de> References: <46BF752E.4030500@herr-schmitt.de> Message-ID: <46BF7808.4090309@hhs.nl> Jochen Schmitt wrote: > Hello, > > in the past we have removed itext and pdftk which depends on itext from > the Fedora distribution due > license issue. > > In the new iText package itext-2.0.4 I have found a text file about the > licensing situation of the > source file coming from Sun Corporation Inc. > > I have uploaded this file for review on > > http://www.herr-schmitt.de/pub/itext/sun.txt > > I want to know, it this ok for Fedora. But I assume, that the last term > about usage this > file for nuclear weapons may be a blocker. > > Best Regards: > > Jochen Schmitt > The second license is fine, its plain 2 clause BSD, the nuclear facility text means: If you use this in a nuclear facility (say a power plant) and the facility goes BOOM because of a bug in this software, don't sue us, we told you there were no guarantees. Its just added boilerplate to the guarantee disclaimer. The first might be a problem though, esp the second clause: ii) Licensee does not utilize the software in a manner which is disparaging to Sun Microsystems. Looking up "to disparage" in my dictionary ... it means you cannot use this software in a manner which criticises Sun Microsystems, sounds like a use restriction to me and thus non free, you will need to ask Sun to waive this requirement. But IANAL the definitive person to ask things like this is Spot (who AFAIK is not a lawyer either, but still he is the one). Regards, Hans From j.w.r.degoede at hhs.nl Sun Aug 12 21:16:39 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 12 Aug 2007 23:16:39 +0200 Subject: License review for new itext version In-Reply-To: <46BF77CF.5090404@fedoraproject.org> References: <46BF752E.4030500@herr-schmitt.de> <46BF77CF.5090404@fedoraproject.org> Message-ID: <46BF78B7.7020304@hhs.nl> Rahul Sundaram wrote: > Jochen Schmitt wrote: >> Hello, >> >> in the past we have removed itext and pdftk which depends on itext from >> the Fedora distribution due >> license issue. >> >> In the new iText package itext-2.0.4 I have found a text file about the >> licensing situation of the >> source file coming from Sun Corporation Inc. >> >> I have uploaded this file for review on >> >> http://www.herr-schmitt.de/pub/itext/sun.txt >> >> I want to know, it this ok for Fedora. But I assume, that the last term >> about usage this >> file for nuclear weapons may be a blocker. > > This looks like the revised BSD license with a use restriction that > makes it non-free. > Its not a use restriction, it reads: "You acknowledge that Software is not designed,licensed or intended for use in the design, construction, operation or maintenance of any nuclear facility." Oh darn it is a use restriction, notice the not licensed, I thought it was just a warning (which it would be if you remove the work licensed from the sentence). So again ask Sun for a waiver, in this case just removing the work "licensed" from this sentence will do. Regards, Hans From tcallawa at redhat.com Sun Aug 12 21:30:56 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 12 Aug 2007 17:30:56 -0400 Subject: License review for new itext version In-Reply-To: <46BF752E.4030500@herr-schmitt.de> References: <46BF752E.4030500@herr-schmitt.de> Message-ID: <1186954256.4243.82.camel@new-host-2> On Sun, 2007-08-12 at 23:01 +0200, Jochen Schmitt wrote: > Hello, > > in the past we have removed itext and pdftk which depends on itext from > the Fedora distribution due > license issue. > > In the new iText package itext-2.0.4 I have found a text file about the > licensing situation of the > source file coming from Sun Corporation Inc. > > I have uploaded this file for review on > > http://www.herr-schmitt.de/pub/itext/sun.txt > > I want to know, it this ok for Fedora. But I assume, that the last term > about usage this > file for nuclear weapons may be a blocker. The primary license doesn't meet the criteria for Fedora acceptance. It has a use-case restriction that's painfully vague: "Licensee does not utilize the software in a manner which is disparaging to Sun Microsystems." I'd bet 10 bucks the FSF thinks that makes it non-free. If you disagree and want me to process that through the FSF in a formal review, I will (otherwise, I won't waste their time). The secondary license also has a use-case restriction: "You acknowledge that Software is not designed,licensed or intended for use in the design, construction, operation or maintenance of any nuclear facility." As Hans pointed out, the word "licensed" is the problem here. Acknowledging that the software isn't designed or intended for any particular use case is fine, but when you say that the "software is not licensed for use...", then you're making a use case restriction. Sorry Jochen, this is still no-go. ~spot From jwboyer at jdub.homelinux.org Sun Aug 12 22:31:47 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 12 Aug 2007 17:31:47 -0500 Subject: License review for new itext version In-Reply-To: <645d17210708121407t6221f887r8f27bcce91a93245@mail.gmail.com> References: <46BF752E.4030500@herr-schmitt.de> <645d17210708121407t6221f887r8f27bcce91a93245@mail.gmail.com> Message-ID: <20070812173147.459a9a7a@vader.jdub.homelinux.org> On Sun, 12 Aug 2007 22:07:10 +0100 "Jonathan Underwood" wrote: > On 12/08/07, Jochen Schmitt wrote: > > Hello, > > > > in the past we have removed itext and pdftk which depends on itext > > from the Fedora distribution due > > license issue. > > > > In the new iText package itext-2.0.4 I have found a text file about > > the licensing situation of the > > source file coming from Sun Corporation Inc. > > > > I have uploaded this file for review on > > > > http://www.herr-schmitt.de/pub/itext/sun.txt > > > > I want to know, it this ok for Fedora. But I assume, that the last > > term about usage this > > file for nuclear weapons may be a blocker. > > Not wishing to be pedantic, but "nuclear facility" does not > necessarily imply "nuclear weapons". True. Which makes it even more restrictive. But it doesn't really matter. It could say "not licensed for use in Josh Boyer's toaster" and it would still be a restriction. josh Because I _so_ want a toaster that runs Linux and uses iText! Imagine... a pdf burned onto your morning toast! From ssorce at redhat.com Mon Aug 13 01:01:35 2007 From: ssorce at redhat.com (Simo Sorce) Date: Sun, 12 Aug 2007 21:01:35 -0400 Subject: License review for new itext version In-Reply-To: <20070812173147.459a9a7a@vader.jdub.homelinux.org> References: <46BF752E.4030500@herr-schmitt.de> <645d17210708121407t6221f887r8f27bcce91a93245@mail.gmail.com> <20070812173147.459a9a7a@vader.jdub.homelinux.org> Message-ID: <1186966895.22941.79.camel@localhost.localdomain> On Sun, 2007-08-12 at 17:31 -0500, Josh Boyer wrote: > Because I _so_ want a toaster that runs Linux and uses iText! > Imagine... a pdf burned onto your morning toast! Only if it is a nuclear powered toaster ;-) Simo. From dwmw2 at infradead.org Mon Aug 13 02:53:29 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 13 Aug 2007 10:53:29 +0800 Subject: License review for new itext version In-Reply-To: <20070812173147.459a9a7a@vader.jdub.homelinux.org> References: <46BF752E.4030500@herr-schmitt.de> <645d17210708121407t6221f887r8f27bcce91a93245@mail.gmail.com> <20070812173147.459a9a7a@vader.jdub.homelinux.org> Message-ID: <1186973609.3973.34.camel@shinybook.infradead.org> On Sun, 2007-08-12 at 17:31 -0500, Josh Boyer wrote: > Because I _so_ want a toaster that runs Linux and uses iText! > Imagine... a pdf burned onto your morning toast! http://aaisp.net.uk/aa/laser/example.html -- dwmw2 From jwboyer at jdub.homelinux.org Mon Aug 13 03:41:29 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 12 Aug 2007 22:41:29 -0500 Subject: License review for new itext version In-Reply-To: <1186973609.3973.34.camel@shinybook.infradead.org> References: <46BF752E.4030500@herr-schmitt.de> <645d17210708121407t6221f887r8f27bcce91a93245@mail.gmail.com> <20070812173147.459a9a7a@vader.jdub.homelinux.org> <1186973609.3973.34.camel@shinybook.infradead.org> Message-ID: <20070812224129.51868cd0@Nokia-N800-26> On Mon, 13 Aug 2007 10:53:29 +0800 David Woodhouse wrote: > On Sun, 2007-08-12 at 17:31 -0500, Josh Boyer wrote: > > Because I _so_ want a toaster that runs Linux and uses iText! > > Imagine... a pdf burned onto your morning toast! > > http://aaisp.net.uk/aa/laser/example.html > Yes! josh From alan at redhat.com Mon Aug 13 09:56:12 2007 From: alan at redhat.com (Alan Cox) Date: Mon, 13 Aug 2007 05:56:12 -0400 Subject: License review for new itext version In-Reply-To: <645d17210708121407t6221f887r8f27bcce91a93245@mail.gmail.com> References: <46BF752E.4030500@herr-schmitt.de> <645d17210708121407t6221f887r8f27bcce91a93245@mail.gmail.com> Message-ID: <20070813095612.GC14455@devserv.devel.redhat.com> On Sun, Aug 12, 2007 at 10:07:10PM +0100, Jonathan Underwood wrote: > > I want to know, it this ok for Fedora. But I assume, that the last term > > about usage this > > file for nuclear weapons may be a blocker. > > Not wishing to be pedantic, but "nuclear facility" does not > necessarily imply "nuclear weapons". And nuclear weapons people don't need to ask permission 8) The clause says "You acknowledge that Software is not designed,licensed or intended for use in the design, construction, operation or maintenance of any nuclear facility." It does not say you may not do so, it just says on your own head be it. I don't know if that warning needs to be propogated to the basic fedora docs or info but its not itself a restriction There is a different problem however "ii) Licensee does not utilize the software in a manner which is disparaging to Sun Microsystems." This is incompatible with open source. (As indeed would be one which forbid its use disparaging to Fedora). Alan From aph at redhat.com Mon Aug 13 10:04:24 2007 From: aph at redhat.com (Andrew Haley) Date: Mon, 13 Aug 2007 11:04:24 +0100 Subject: License review for new itext version In-Reply-To: <20070813095612.GC14455@devserv.devel.redhat.com> References: <46BF752E.4030500@herr-schmitt.de> <645d17210708121407t6221f887r8f27bcce91a93245@mail.gmail.com> <20070813095612.GC14455@devserv.devel.redhat.com> Message-ID: <18112.11432.410194.722769@zebedee.pink> Alan Cox writes: > On Sun, Aug 12, 2007 at 10:07:10PM +0100, Jonathan Underwood wrote: > > > I want to know, it this ok for Fedora. But I assume, that the last term > > > about usage this > > > file for nuclear weapons may be a blocker. > > > > Not wishing to be pedantic, but "nuclear facility" does not > > necessarily imply "nuclear weapons". > > And nuclear weapons people don't need to ask permission 8) > > The clause says > > "You acknowledge that Software is not designed,licensed or intended for use in > the design, construction, operation or maintenance of any nuclear facility." It says it isn't licensed: if there is no license is it not a breach of copyright to use the software? > "ii) Licensee does not utilize the software in a manner which is > disparaging to Sun Microsystems." > > This is incompatible with open source. (As indeed would be one > which forbid its use disparaging to Fedora). Indeed. It's a silly clause anyway; how on earth could it be enforced? Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From Jochen at herr-schmitt.de Mon Aug 13 15:40:36 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 13 Aug 2007 17:40:36 +0200 Subject: License review for new itext version In-Reply-To: <1186954256.4243.82.camel@new-host-2> References: <46BF752E.4030500@herr-schmitt.de> <1186954256.4243.82.camel@new-host-2> Message-ID: <0MKwpI-1IKc2X0Z6I-0007pd@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 12 Aug 2007 17:30:56 -0400, you wrote: >As Hans pointed out, the word "licensed" is the problem here. >Acknowledging that the software isn't designed or intended for any >particular use case is fine, but when you say that the "software is not >licensed for use...", then you're making a use case restriction. > >Sorry Jochen, this is still no-go. Thank your for your response. You have committed my mind, that the text contains conditions which blocks the usage of this software in Fedora. So iTex will still be dead for Fedora Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.1 (Build 1012) Charset: us-ascii wj8DBQFGwHuTT2AHK6txfgwRAhskAJ9nMkOIG+AdW02X/lxbUYnGeVsHMACgs8wb /1X9dnVmEWL8NUYXrbThh7M= =LMeV -----END PGP SIGNATURE----- From Jochen at herr-schmitt.de Mon Aug 13 16:05:44 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 13 Aug 2007 18:05:44 +0200 Subject: License review for new itext version In-Reply-To: <1186954256.4243.82.camel@new-host-2> References: <46BF752E.4030500@herr-schmitt.de> <1186954256.4243.82.camel@new-host-2> Message-ID: <0ML2xA-1IKcQY0vMW-0001cF@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 12 Aug 2007 17:30:56 -0400, you wrote: > >As Hans pointed out, the word "licensed" is the problem here. >Acknowledging that the software isn't designed or intended for any >particular use case is fine, but when you say that the "software is not >licensed for use...", then you're making a use case restriction. I have sent a mail to the project mailing list to notifiy the developers about the licensing issues. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.1 (Build 1012) Charset: us-ascii wj8DBQFGwIFkT2AHK6txfgwRAk9kAKDy4GiHxF5mdQZJKcPo7GKsoIji3QCfYpDx R5r64ojfy3gNTUdHMsIWbnI= =M8K9 -----END PGP SIGNATURE----- From j.w.r.degoede at hhs.nl Mon Aug 13 16:55:53 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 13 Aug 2007 18:55:53 +0200 Subject: License review for new itext version In-Reply-To: <0ML2xA-1IKcQY0vMW-0001cF@mrelayeu.kundenserver.de> References: <46BF752E.4030500@herr-schmitt.de> <1186954256.4243.82.camel@new-host-2> <0ML2xA-1IKcQY0vMW-0001cF@mrelayeu.kundenserver.de> Message-ID: <46C08D19.1050503@hhs.nl> Jochen Schmitt wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Sun, 12 Aug 2007 17:30:56 -0400, you wrote: >> As Hans pointed out, the word "licensed" is the problem here. >> Acknowledging that the software isn't designed or intended for any >> particular use case is fine, but when you say that the "software is not >> licensed for use...", then you're making a use case restriction. > > I have sent a mail to the project mailing list to notifiy the > developers about the licensing issues. > Ah yes, that sounds much better then the "So iTex will still be dead for Fedora" sentence from your other mail. Usually when a license is so close, and upstream is not dead, the chances are quite good upstream will be willing to change the license. Notice that some (severe) stubbornness from yuor side may be needed to get to the point where the license actually gets changed. Regards, Hans (who has had several licenses ammended, though those where hobiest projects and this is Sun, where everything needs to get past the lawyers). From jwboyer at jdub.homelinux.org Mon Aug 13 17:24:55 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 13 Aug 2007 12:24:55 -0500 Subject: Zod -> Moonshine -> ? Moonshine is a , is a Message-ID: <20070813122455.724d7df4@weaponx.rchland.ibm.com> That's right... it's time to start naming the Fedora 8 release. Fill in your suggestion for the blanks. Remember the rules: 1) must have some link to Moonshine 2) The link between and Moonshine cannot be the same as between Zod and Moonshine Suggestions will be run through the legal queue and an election will happen for Fedora contributors to pick the next Fedora name. Let the naming begin! josh From smooge at gmail.com Mon Aug 13 17:40:06 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 13 Aug 2007 11:40:06 -0600 Subject: Zod -> Moonshine -> ? Moonshine is a , is a In-Reply-To: <20070813122455.724d7df4@weaponx.rchland.ibm.com> References: <20070813122455.724d7df4@weaponx.rchland.ibm.com> Message-ID: <80d7e4090708131040v6a37a7e7m54bd5314914608f@mail.gmail.com> On 8/13/07, Josh Boyer wrote: > That's right... it's time to start naming the Fedora 8 release. Fill > in your suggestion for the blanks. Remember the rules: > > 1) must have some link to Moonshine > 2) The link between and Moonshine cannot be the same as between > Zod and Moonshine > > Suggestions will be run through the legal queue and an election will > happen for Fedora contributors to pick the next Fedora name. > > Let the naming begin! Well the official links between Zod and Moonshine will need to be published for useful combinations. Here are my suggestions for FC8 Moonshine -> RojoToro [EnergyDrink] Moonshine -> Charger Moonshine -> Chatham Moonshine -> Traveler Moonshine -> Mason -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From overholt at redhat.com Mon Aug 13 17:46:46 2007 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 13 Aug 2007 13:46:46 -0400 Subject: Package rename upstream In-Reply-To: <46BCD2A9.1060104@fedoraproject.org> References: <20070810210053.GA9229@redhat.com> <46BCD2A9.1060104@fedoraproject.org> Message-ID: <1187027206.5512.0.camel@localhost.localdomain> On Sat, 2007-08-11 at 02:33 +0530, Rahul Sundaram wrote: > > I couldn't find anything related to this on the wiki. Does > searching > > even work? I tried searching for text that I *knew* was on a page > > (Renaming) and it found no results. What gives? > > What did you search for and what page is it in? Did you click on the > text instead of title for searching? I see the Title vs. Text buttons now. In the post-Google age, why is searching in the full text not the default? Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ajackson at redhat.com Mon Aug 13 17:46:09 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 13 Aug 2007 13:46:09 -0400 Subject: Zod -> Moonshine -> ? Moonshine is a , is a In-Reply-To: <20070813122455.724d7df4@weaponx.rchland.ibm.com> References: <20070813122455.724d7df4@weaponx.rchland.ibm.com> Message-ID: <1187027169.2876.99.camel@localhost.localdomain> On Mon, 2007-08-13 at 12:24 -0500, Josh Boyer wrote: > That's right... it's time to start naming the Fedora 8 release. Fill > in your suggestion for the blanks. Remember the rules: > > 1) must have some link to Moonshine > 2) The link between and Moonshine cannot be the same as between > Zod and Moonshine Which, for those who don't remember, was "record labels". > Suggestions will be run through the legal queue and an election will > happen for Fedora contributors to pick the next Fedora name. Suggested links: Banned or restricted liquors (although this might be getting old) Film titles from Sundance Vampire movies Synonym for "foolish idea" Accidental industry starters (yay nascar) - ajax From pjones at redhat.com Mon Aug 13 17:57:49 2007 From: pjones at redhat.com (Peter Jones) Date: Mon, 13 Aug 2007 13:57:49 -0400 Subject: Zod -> Moonshine -> ? Moonshine is a , is a In-Reply-To: <20070813122455.724d7df4@weaponx.rchland.ibm.com> References: <20070813122455.724d7df4@weaponx.rchland.ibm.com> Message-ID: <46C09B9D.8010808@redhat.com> Josh Boyer wrote: > That's right... it's time to start naming the Fedora 8 release. Fill > in your suggestion for the blanks. Remember the rules: > > 1) must have some link to Moonshine > 2) The link between and Moonshine cannot be the same as between > Zod and Moonshine Moonshine -> Oboe (both codenames for British RADAR related technologies in WW2) -- Peter From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Aug 13 18:01:26 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 13 Aug 2007 20:01:26 +0200 Subject: Zod -> Moonshine -> ? Moonshine is a , is a In-Reply-To: <20070813122455.724d7df4@weaponx.rchland.ibm.com> References: <20070813122455.724d7df4@weaponx.rchland.ibm.com> Message-ID: <20070813200126.435b3e43@python3.es.egwn.lan> Josh Boyer wrote : > That's right... it's time to start naming the Fedora 8 release. Fill > in your suggestion for the blanks. Remember the rules: > > 1) must have some link to Moonshine > 2) The link between and Moonshine cannot be the same as between > Zod and Moonshine > > Suggestions will be run through the legal queue and an election will > happen for Fedora contributors to pick the next Fedora name. > > Let the naming begin! Moonsine (Music) -> Ninja (Tune), a label with some of my favourite artists :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.22.1-41.fc7 Load : 0.43 0.34 0.32 From ajackson at redhat.com Mon Aug 13 18:00:43 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 13 Aug 2007 14:00:43 -0400 Subject: Zod -> Moonshine -> ? Moonshine is a , is a In-Reply-To: <20070813200126.435b3e43@python3.es.egwn.lan> References: <20070813122455.724d7df4@weaponx.rchland.ibm.com> <20070813200126.435b3e43@python3.es.egwn.lan> Message-ID: <1187028043.2876.102.camel@localhost.localdomain> On Mon, 2007-08-13 at 20:01 +0200, Matthias Saou wrote: > Josh Boyer wrote : > > > That's right... it's time to start naming the Fedora 8 release. Fill > > in your suggestion for the blanks. Remember the rules: > > > > 1) must have some link to Moonshine > > 2) The link between and Moonshine cannot be the same as between > > Zod and Moonshine > > > > Suggestions will be run through the legal queue and an election will > > happen for Fedora contributors to pick the next Fedora name. > > > > Let the naming begin! > > Moonsine (Music) -> Ninja (Tune), a label with some of my favourite > artists :-) That was the Zod->Moonshine connection, so no. - ajax From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Aug 13 18:10:02 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 13 Aug 2007 20:10:02 +0200 Subject: Zod -> Moonshine -> ? Moonshine is a , is a In-Reply-To: <1187028043.2876.102.camel@localhost.localdomain> References: <20070813122455.724d7df4@weaponx.rchland.ibm.com> <20070813200126.435b3e43@python3.es.egwn.lan> <1187028043.2876.102.camel@localhost.localdomain> Message-ID: <20070813201002.194676aa@python3.es.egwn.lan> Adam Jackson wrote : > On Mon, 2007-08-13 at 20:01 +0200, Matthias Saou wrote: > > Josh Boyer wrote : > > > > > That's right... it's time to start naming the Fedora 8 release. Fill > > > in your suggestion for the blanks. Remember the rules: > > > > > > 1) must have some link to Moonshine > > > 2) The link between and Moonshine cannot be the same as between > > > Zod and Moonshine > > > > > > Suggestions will be run through the legal queue and an election will > > > happen for Fedora contributors to pick the next Fedora name. > > > > > > Let the naming begin! > > > > Moonsine (Music) -> Ninja (Tune), a label with some of my favourite > > artists :-) > > That was the Zod->Moonshine connection, so no. Oh, I thought it was some alcohol related link, sorry. Then I'll have to suggest "Gn?le", which is our own home made "nasty" alcohol ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.22.1-41.fc7 Load : 0.58 0.47 0.37 From jwboyer at jdub.homelinux.org Mon Aug 13 18:13:05 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 13 Aug 2007 13:13:05 -0500 Subject: Zod -> Moonshine -> ? Moonshine is a , is a In-Reply-To: <80d7e4090708131040v6a37a7e7m54bd5314914608f@mail.gmail.com> References: <20070813122455.724d7df4@weaponx.rchland.ibm.com> <80d7e4090708131040v6a37a7e7m54bd5314914608f@mail.gmail.com> Message-ID: <20070813131305.65d1ff3e@weaponx.rchland.ibm.com> On Mon, 13 Aug 2007 11:40:06 -0600 "Stephen John Smoogen" wrote: > On 8/13/07, Josh Boyer wrote: > > That's right... it's time to start naming the Fedora 8 release. Fill > > in your suggestion for the blanks. Remember the rules: > > > > 1) must have some link to Moonshine > > 2) The link between and Moonshine cannot be the same as between > > Zod and Moonshine > > > > Suggestions will be run through the legal queue and an election will > > happen for Fedora contributors to pick the next Fedora name. > > > > Let the naming begin! > > Well the official links between Zod and Moonshine will need to be > published for useful combinations. What?? You don't remember?!? ;) The old link was "record labels" > Here are my suggestions for FC8 > > Moonshine -> RojoToro [EnergyDrink] > Moonshine -> Charger > Moonshine -> Chatham > Moonshine -> Traveler > Moonshine -> Mason Links? josh From caillon at redhat.com Mon Aug 13 18:15:10 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 13 Aug 2007 14:15:10 -0400 Subject: Zod -> Moonshine -> ? Moonshine is a , is a In-Reply-To: <20070813122455.724d7df4@weaponx.rchland.ibm.com> References: <20070813122455.724d7df4@weaponx.rchland.ibm.com> Message-ID: <46C09FAE.20909@redhat.com> Josh Boyer wrote: > That's right... it's time to start naming the Fedora 8 release. Fill > in your suggestion for the blanks. Remember the rules: > > 1) must have some link to Moonshine > 2) The link between and Moonshine cannot be the same as between > Zod and Moonshine Moonshine typically hasn't been aged properly. Traci... hmm, nevermind. From jwboyer at jdub.homelinux.org Mon Aug 13 18:19:05 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 13 Aug 2007 13:19:05 -0500 Subject: Zod -> Moonshine -> ? Moonshine is a , is a In-Reply-To: <20070813122455.724d7df4@weaponx.rchland.ibm.com> References: <20070813122455.724d7df4@weaponx.rchland.ibm.com> Message-ID: <20070813131905.6311018c@weaponx.rchland.ibm.com> On Mon, 13 Aug 2007 12:24:55 -0500 Josh Boyer wrote: > That's right... it's time to start naming the Fedora 8 release. Fill > in your suggestion for the blanks. Remember the rules: > > 1) must have some link to Moonshine > 2) The link between and Moonshine cannot be the same as between > Zod and Moonshine > > Suggestions will be run through the legal queue and an election will > happen for Fedora contributors to pick the next Fedora name. > > Let the naming begin! My entry: Jack. Both Jack and Moonshine are names of mountains. josh From skvidal at fedoraproject.org Mon Aug 13 18:37:17 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 13 Aug 2007 14:37:17 -0400 Subject: Package rename upstream In-Reply-To: <1187027206.5512.0.camel@localhost.localdomain> References: <20070810210053.GA9229@redhat.com> <46BCD2A9.1060104@fedoraproject.org> <1187027206.5512.0.camel@localhost.localdomain> Message-ID: <1187030237.13822.33.camel@cutter> On Mon, 2007-08-13 at 13:46 -0400, Andrew Overholt wrote: > On Sat, 2007-08-11 at 02:33 +0530, Rahul Sundaram wrote: > > > I couldn't find anything related to this on the wiki. Does > > searching > > > even work? I tried searching for text that I *knew* was on a page > > > (Renaming) and it found no results. What gives? > > > > What did you search for and what page is it in? Did you click on the > > text instead of title for searching? > > I see the Title vs. Text buttons now. In the post-Google age, why is > searching in the full text not the default? > b/c it is expensive cpu-wise. -sv From smooge at gmail.com Mon Aug 13 19:06:39 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 13 Aug 2007 13:06:39 -0600 Subject: Zod -> Moonshine -> ? Moonshine is a , is a In-Reply-To: <20070813131305.65d1ff3e@weaponx.rchland.ibm.com> References: <20070813122455.724d7df4@weaponx.rchland.ibm.com> <80d7e4090708131040v6a37a7e7m54bd5314914608f@mail.gmail.com> <20070813131305.65d1ff3e@weaponx.rchland.ibm.com> Message-ID: <80d7e4090708131206h3c566banbedfcbeacb4e5f6a@mail.gmail.com> On 8/13/07, Josh Boyer wrote: > On Mon, 13 Aug 2007 11:40:06 -0600 > "Stephen John Smoogen" wrote: > > > On 8/13/07, Josh Boyer wrote: > > > That's right... it's time to start naming the Fedora 8 release. Fill > > > in your suggestion for the blanks. Remember the rules: > > > > > > 1) must have some link to Moonshine > > > 2) The link between and Moonshine cannot be the same as between > > > Zod and Moonshine > > > > > > Suggestions will be run through the legal queue and an election will > > > happen for Fedora contributors to pick the next Fedora name. > > > > > > Let the naming begin! > > > > Well the official links between Zod and Moonshine will need to be > > published for useful combinations. > > What?? You don't remember?!? ;) > > The old link was "record labels" > > > Here are my suggestions for FC8 > > > > Moonshine -> RojoToro [EnergyDrink] > > Moonshine -> Charger > > Moonshine -> Chatham > > Moonshine -> Traveler > > Moonshine -> Mason > > Links? > Sorry in the old days.. we werent supposed to say what the links were in public email. sigh.. Moonshine / RojoToro are 'Energy Drinks' to some people Moonshine / Charger ... the Dodge Charger was used a lot in a show about moonshiners Moonshine / Chatham ... Chatham County was the Moonshine Capitol of the South for many years Moonshine / Traveler .. A very famous car that drove moonshine around Moonshine / Mason .. what one drinks southern moonshine from. Mason has a bunch of other items that can be moved from. > josh > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From simonb at thoughtpolice.co.uk Mon Aug 13 19:07:16 2007 From: simonb at thoughtpolice.co.uk (Simon B) Date: Mon, 13 Aug 2007 21:07:16 +0200 Subject: Package rename upstream In-Reply-To: <1187030237.13822.33.camel@cutter> References: <20070810210053.GA9229@redhat.com> <46BCD2A9.1060104@fedoraproject.org> <1187027206.5512.0.camel@localhost.localdomain> <1187030237.13822.33.camel@cutter> Message-ID: <1187032036.3009.0.camel@sb-home> Am Montag, den 13.08.2007, 14:37 -0400 schrieb seth vidal: > On Mon, 2007-08-13 at 13:46 -0400, Andrew Overholt wrote: > > On Sat, 2007-08-11 at 02:33 +0530, Rahul Sundaram wrote: > > > > I couldn't find anything related to this on the wiki. Does > > > searching > > > > even work? I tried searching for text that I *knew* was on a page > > > > (Renaming) and it found no results. What gives? > > > > > > What did you search for and what page is it in? Did you click on the > > > text instead of title for searching? > > > > I see the Title vs. Text buttons now. In the post-Google age, why is > > searching in the full text not the default? > > > > b/c it is expensive cpu-wise. > > -sv > It's expensive human-wise too, the search takes so long it may as well be removed. Can't it use an index :) Google to the rescue.. From dcantrell at redhat.com Mon Aug 13 19:19:15 2007 From: dcantrell at redhat.com (David Cantrell) Date: Mon, 13 Aug 2007 15:19:15 -0400 Subject: Zod -> Moonshine -> ? Moonshine is a , is a In-Reply-To: <80d7e4090708131206h3c566banbedfcbeacb4e5f6a@mail.gmail.com> References: <20070813122455.724d7df4@weaponx.rchland.ibm.com> <80d7e4090708131040v6a37a7e7m54bd5314914608f@mail.gmail.com> <20070813131305.65d1ff3e@weaponx.rchland.ibm.com> <80d7e4090708131206h3c566banbedfcbeacb4e5f6a@mail.gmail.com> Message-ID: <20070813151915.1ededeb4.dcantrell@redhat.com> On Mon, 13 Aug 2007 13:06:39 -0600 "Stephen John Smoogen" wrote: > On 8/13/07, Josh Boyer wrote: > > On Mon, 13 Aug 2007 11:40:06 -0600 > > "Stephen John Smoogen" wrote: > > > > > On 8/13/07, Josh Boyer wrote: > > > > That's right... it's time to start naming the Fedora 8 release. Fill > > > > in your suggestion for the blanks. Remember the rules: > > > > > > > > 1) must have some link to Moonshine > > > > 2) The link between and Moonshine cannot be the same as between > > > > Zod and Moonshine > > > > > > > > Suggestions will be run through the legal queue and an election will > > > > happen for Fedora contributors to pick the next Fedora name. > > > > > > > > Let the naming begin! > > > > > > Well the official links between Zod and Moonshine will need to be > > > published for useful combinations. > > > > What?? You don't remember?!? ;) > > > > The old link was "record labels" > > > > > Here are my suggestions for FC8 > > > > > > Moonshine -> RojoToro [EnergyDrink] > > > Moonshine -> Charger > > > Moonshine -> Chatham > > > Moonshine -> Traveler > > > Moonshine -> Mason > > > > Links? > > > > Sorry in the old days.. we werent supposed to say what the links were > in public email. sigh.. > > Moonshine / RojoToro are 'Energy Drinks' to some people > Moonshine / Charger ... the Dodge Charger was used a lot in a show > about moonshiners We should offer a theme for F8 inspired by "The General". > Moonshine / Chatham ... Chatham County was the Moonshine Capitol of > the South for many years I say no to this because no one will know how to correctly pronounce it. > Moonshine / Traveler .. A very famous car that drove moonshine around > Moonshine / Mason .. what one drinks southern moonshine from. Mason > has a bunch of other items that can be moved from. On this theme... Moonshine / Bandit ... someone needs to run protection for you through the dry counties. -- David Cantrell Red Hat / Westford, MA -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Mon Aug 13 19:23:49 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 13 Aug 2007 15:23:49 -0400 Subject: Zod -> Moonshine -> ? Moonshine is a , is a In-Reply-To: <20070813122455.724d7df4@weaponx.rchland.ibm.com> References: <20070813122455.724d7df4@weaponx.rchland.ibm.com> Message-ID: <1187033029.4921.26.camel@localhost.localdomain> On Mon, 2007-08-13 at 12:24 -0500, Josh Boyer wrote: > That's right... it's time to start naming the Fedora 8 release. Fill > in your suggestion for the blanks. Remember the rules: > > 1) must have some link to Moonshine More specifically, the link should be Moonshine is a and NewName is a Where blank is the same for both Jeremy From buildsys at fedoraproject.org Mon Aug 13 19:31:02 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 13 Aug 2007 15:31:02 -0400 (EDT) Subject: Package EVR problems in Fedora 2007-08-13 Message-ID: <20070813193102.9C572152133@buildsys.fedoraproject.org> Axel.Thimm AT ATrpms.net: smart FE6 > F7-updates (0:0.50-47.fc6 > 0:0.50-46.fc7) FE6 > F8 (0:0.50-47.fc6 > 0:0.50-46.fc8) alexl AT redhat.com: xdg-user-dirs F7-updates > F8 (0:0.8-3.fc7 > 0:0.8-2.fc8) davidz AT redhat.com: dbus-python F7-updates-testing > F8 (0:0.82.0-2.fc7 > 0:0.82.0-1.fc8) denis AT poolshark.org: galeon F7-updates > F8 (0:2.0.3-10.fc7 > 0:2.0.3-9.fc8) ed AT eh3.com: scrip FE6 > F7 (0:1.4-7.fc6 > 0:1.4-6.fc6) FE6 > F8 (0:1.4-7.fc6 > 0:1.4-6.fc6) enrico.scholz AT informatik.tu-chemnitz.de: clamav F7-updates-testing > F8 (0:0.91.1-1.fc7 > 0:0.91.1-0.fc8) fedora-usermgmt FE6 > F7 (0:0.10-1.fc6 > 0:0.9-2.fc7) libtasn1 FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE5 > F8 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE6 > F7 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) FE6 > F8 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) mimetic FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7) FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7) util-vserver FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7) FE6 > F7 (0:0.30.213-2.fc6 > 0:0.30.212-3.fc7) xmlrpc-c FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7) FE6 > F7 (0:1.06.16-1.fc6 > 0:1.06.11-2.fc7) foolish AT guezz.net: gtranslator F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8) perl-Net-Libdnet F7-updates > F8 (0:0.01-3.fc7.1 > 0:0.01-2.fc8) perl-Nmap-Parser F7-updates > F8 (0:1.05-4.fc7 > 0:1.05-3.fc8) tcptraceroute FE6 > F7-updates (0:1.5-0.2.beta7.fc6 > 0:1.5-0.1.beta7.fc7) gauret AT free.fr: awstats F7-updates-testing > F8 (0:6.7-1.fc7 > 0:6.6-1.fc7) jakub AT redhat.com: gcc FC6-updates > F7 (0:4.1.2-13.fc6 > 0:4.1.2-12) jeff AT ocjtech.us: jrtplib FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) kzak AT redhat.com: util-linux F7-updates-testing > F8 (0:2.13-0.54.fc7 > 0:2.13-0.52.fc7) lemenkov AT gmail.com: stratagus FE6 > F7 (0:2.2.4-1.fc6 > 0:2.2.3-1.fc7) lkundrak AT redhat.com: cjet F7-updates > F8 (0:0.8.9-4.fc7 > 0:0.8.9-2.fc8) lxtnow AT gmail.com: gammu FE6 > F8 (0:1.12.92-1.fc6 > 0:1.11.0-1.fc8) F7-updates-testing > F8 (0:1.12.92-1.fc7 > 0:1.11.0-1.fc8) python-gammu FE6 > F7-updates (0:0.21-1.fc6 > 0:0.20-1.fc7) FE6 > F8 (0:0.21-1.fc6 > 0:0.20-1.fc7) specto FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8) F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8) meme AT daughtersoftiresias.org: fortune-firefly FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6) FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6) mikeb AT redhat.com: python-cheetah FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) FE6 > F8 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) nhorman AT redhat.com: irqbalance FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6) FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7) FC5-updates > F8 (2:0.55-4.fc5 > 2:0.55-3.fc8) opensource AT till.name: iasl F7-updates-testing > F8 (0:20061109-3.fc7 > 0:20061109-2.fc7) paul AT xelerance.com: xl2tpd FE6 > F7 (0:1.1.11-2.fc6 > 0:1.1.09-1.fc7) pawsa AT theochem.kth.se: balsa F7-updates > F8 (0:2.3.17-2.fc7 > 0:2.3.17-1.fc8) rdieter AT math.unl.edu: kdeartwork-extras FE6 > F7 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) FE6 > F8 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) maxima FE5 > F7-updates (0:5.12.0-3.fc5 > 0:5.12.0-2.fc7) FE6 > F7-updates (0:5.12.0-3.fc6 > 0:5.12.0-2.fc7) sandmann AT redhat.com: libgtop2 FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7) splinux AT fedoraproject.org: lostirc FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7) FE6 > F8 (0:0.4.6-3.fc6 > 0:0.4.6-2.fc8) than AT redhat.com: kdemultimedia FC6-updates > F7-updates (6:3.5.7-1.fc6 > 6:3.5.7-0.1.fc7) kdepim F7-updates > F8 (6:3.5.7-3.fc7 > 6:3.5.7-2.fc8) toshio AT tiki-lounge.com: python-docutils F7-updates-testing > F8 (0:0.4-5.fc7 > 0:0.4-4.fc7) veillard AT redhat.com: libxml2 FC6-updates > F8 (0:2.6.29-1.fc6 > 0:2.6.29-1) F7-updates > F8 (0:2.6.29-1.fc7 > 0:2.6.29-1) ville.skytta AT iki.fi: em8300 FE6 > F7-updates (0:0.16.3-0.1.rc3.fc6 > 0:0.16.3-0.1.rc2.fc7) em8300-kmod FE6 > F7-updates (0:0.16.3-0.2.rc3.2.6.22.1_32.fc6 > 0:0.16.3-0.1.rc2.2.6.22.1_41.fc7) html401-dtds F7-updates-testing > F8 (0:4.01-19991224.5 > 0:4.01-19991224.3.fc6) zhu AT redhat.com: stardict F7-updates > F8 (0:3.0.0-1.fc7 > 0:2.4.8-3.fc8) ---------------------------------------------------------------------- awstats: gauret AT free.fr F7-updates-testing > F8 (0:6.7-1.fc7 > 0:6.6-1.fc7) balsa: pawsa AT theochem.kth.se F7-updates > F8 (0:2.3.17-2.fc7 > 0:2.3.17-1.fc8) cjet: lkundrak AT redhat.com F7-updates > F8 (0:0.8.9-4.fc7 > 0:0.8.9-2.fc8) clamav: enrico.scholz AT informatik.tu-chemnitz.de F7-updates-testing > F8 (0:0.91.1-1.fc7 > 0:0.91.1-0.fc8) dbus-python: davidz AT redhat.com F7-updates-testing > F8 (0:0.82.0-2.fc7 > 0:0.82.0-1.fc8) em8300: ville.skytta AT iki.fi FE6 > F7-updates (0:0.16.3-0.1.rc3.fc6 > 0:0.16.3-0.1.rc2.fc7) em8300-kmod: ville.skytta AT iki.fi FE6 > F7-updates (0:0.16.3-0.2.rc3.2.6.22.1_32.fc6 > 0:0.16.3-0.1.rc2.2.6.22.1_41.fc7) fedora-usermgmt: enrico.scholz AT informatik.tu-chemnitz.de FE6 > F7 (0:0.10-1.fc6 > 0:0.9-2.fc7) fortune-firefly: meme AT daughtersoftiresias.org FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6) FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6) galeon: denis AT poolshark.org F7-updates > F8 (0:2.0.3-10.fc7 > 0:2.0.3-9.fc8) gammu: lxtnow AT gmail.com FE6 > F8 (0:1.12.92-1.fc6 > 0:1.11.0-1.fc8) F7-updates-testing > F8 (0:1.12.92-1.fc7 > 0:1.11.0-1.fc8) gcc: jakub AT redhat.com FC6-updates > F7 (0:4.1.2-13.fc6 > 0:4.1.2-12) gtranslator: foolish AT guezz.net F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8) html401-dtds: ville.skytta AT iki.fi F7-updates-testing > F8 (0:4.01-19991224.5 > 0:4.01-19991224.3.fc6) iasl: opensource AT till.name F7-updates-testing > F8 (0:20061109-3.fc7 > 0:20061109-2.fc7) irqbalance: nhorman AT redhat.com FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6) FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7) FC5-updates > F8 (2:0.55-4.fc5 > 2:0.55-3.fc8) jrtplib: jeff AT ocjtech.us FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) kdeartwork-extras: rdieter AT math.unl.edu FE6 > F7 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) FE6 > F8 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) kdemultimedia: than AT redhat.com FC6-updates > F7-updates (6:3.5.7-1.fc6 > 6:3.5.7-0.1.fc7) kdepim: than AT redhat.com F7-updates > F8 (6:3.5.7-3.fc7 > 6:3.5.7-2.fc8) libgtop2: sandmann AT redhat.com FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7) libtasn1: enrico.scholz AT informatik.tu-chemnitz.de FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE5 > F8 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE6 > F7 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) FE6 > F8 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) libxml2: veillard AT redhat.com FC6-updates > F8 (0:2.6.29-1.fc6 > 0:2.6.29-1) F7-updates > F8 (0:2.6.29-1.fc7 > 0:2.6.29-1) lostirc: splinux AT fedoraproject.org FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7) FE6 > F8 (0:0.4.6-3.fc6 > 0:0.4.6-2.fc8) maxima: rdieter AT math.unl.edu FE5 > F7-updates (0:5.12.0-3.fc5 > 0:5.12.0-2.fc7) FE6 > F7-updates (0:5.12.0-3.fc6 > 0:5.12.0-2.fc7) mimetic: enrico.scholz AT informatik.tu-chemnitz.de FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7) FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7) perl-Net-Libdnet: foolish AT guezz.net F7-updates > F8 (0:0.01-3.fc7.1 > 0:0.01-2.fc8) perl-Nmap-Parser: foolish AT guezz.net F7-updates > F8 (0:1.05-4.fc7 > 0:1.05-3.fc8) python-cheetah: mikeb AT redhat.com FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) FE6 > F8 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) python-docutils: toshio AT tiki-lounge.com F7-updates-testing > F8 (0:0.4-5.fc7 > 0:0.4-4.fc7) python-gammu: lxtnow AT gmail.com FE6 > F7-updates (0:0.21-1.fc6 > 0:0.20-1.fc7) FE6 > F8 (0:0.21-1.fc6 > 0:0.20-1.fc7) scrip: ed AT eh3.com FE6 > F7 (0:1.4-7.fc6 > 0:1.4-6.fc6) FE6 > F8 (0:1.4-7.fc6 > 0:1.4-6.fc6) smart: Axel.Thimm AT ATrpms.net FE6 > F7-updates (0:0.50-47.fc6 > 0:0.50-46.fc7) FE6 > F8 (0:0.50-47.fc6 > 0:0.50-46.fc8) specto: lxtnow AT gmail.com FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8) F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8) stardict: zhu AT redhat.com F7-updates > F8 (0:3.0.0-1.fc7 > 0:2.4.8-3.fc8) stratagus: lemenkov AT gmail.com FE6 > F7 (0:2.2.4-1.fc6 > 0:2.2.3-1.fc7) tcptraceroute: foolish AT guezz.net FE6 > F7-updates (0:1.5-0.2.beta7.fc6 > 0:1.5-0.1.beta7.fc7) util-linux: kzak AT redhat.com F7-updates-testing > F8 (0:2.13-0.54.fc7 > 0:2.13-0.52.fc7) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7) FE6 > F7 (0:0.30.213-2.fc6 > 0:0.30.212-3.fc7) xdg-user-dirs: alexl AT redhat.com F7-updates > F8 (0:0.8-3.fc7 > 0:0.8-2.fc8) xl2tpd: paul AT xelerance.com FE6 > F7 (0:1.1.11-2.fc6 > 0:1.1.09-1.fc7) xmlrpc-c: enrico.scholz AT informatik.tu-chemnitz.de FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7) FE6 > F7 (0:1.06.16-1.fc6 > 0:1.06.11-2.fc7) From dyoung at mesd.k12.or.us Mon Aug 13 19:48:58 2007 From: dyoung at mesd.k12.or.us (Dan Young) Date: Mon, 13 Aug 2007 12:48:58 -0700 Subject: Package rename upstream In-Reply-To: <1187032036.3009.0.camel@sb-home> References: <20070810210053.GA9229@redhat.com> <46BCD2A9.1060104@fedoraproject.org> <1187027206.5512.0.camel@localhost.localdomain> <1187030237.13822.33.camel@cutter> <1187032036.3009.0.camel@sb-home> Message-ID: <994441ae0708131248m3ab3e59y1036a15a919fefb5@mail.gmail.com> On 8/13/07, Simon B wrote: > Am Montag, den 13.08.2007, 14:37 -0400 schrieb seth vidal: > > On Mon, 2007-08-13 at 13:46 -0400, Andrew Overholt wrote: > > > On Sat, 2007-08-11 at 02:33 +0530, Rahul Sundaram wrote: > > > > > I couldn't find anything related to this on the wiki. Does > > > > searching > > > > > even work? I tried searching for text that I *knew* was on a page > > > > > (Renaming) and it found no results. What gives? > > > > > > > > What did you search for and what page is it in? Did you click on the > > > > text instead of title for searching? > > > > > > I see the Title vs. Text buttons now. In the post-Google age, why is > > > searching in the full text not the default? > > > > > > > b/c it is expensive cpu-wise. > > > > -sv > > > > It's expensive human-wise too, the search takes so long it may as well > be removed. Can't it use an index :) > > Google to the rescue.. Index it? http://moinmoin.wikiwikiweb.de/HelpOnSearching/LupySearch -- Dan Young Multnomah ESD - Technology Services 503-257-1562 From alan at redhat.com Mon Aug 13 23:53:26 2007 From: alan at redhat.com (Alan Cox) Date: Mon, 13 Aug 2007 19:53:26 -0400 Subject: Zod -> Moonshine -> ? Moonshine is a , is a In-Reply-To: <1187027169.2876.99.camel@localhost.localdomain> References: <20070813122455.724d7df4@weaponx.rchland.ibm.com> <1187027169.2876.99.camel@localhost.localdomain> Message-ID: <20070813235326.GB30040@devserv.devel.redhat.com> On Mon, Aug 13, 2007 at 01:46:09PM -0400, Adam Jackson wrote: > > 2) The link between and Moonshine cannot be the same as between > > Zod and Moonshine > > Which, for those who don't remember, was "record labels". > > > Suggestions will be run through the legal queue and an election will > > happen for Fedora contributors to pick the next Fedora name. > > Suggested links: > > Banned or restricted liquors (although this might be getting old) > Film titles from Sundance > Vampire movies > Synonym for "foolish idea" > Accidental industry starters (yay nascar) Moonshine is also a common name for an achillea which gives us tons of interesting options for other achillea including fun ones like - Nosebleed - Cammock - Sneezeweed - Milfoil - Mace Admittedly some of them sound like things out of Harry Potter but there we go, they are real. FC8 Nosebleed... Alan From jonathan.underwood at gmail.com Tue Aug 14 00:23:37 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 14 Aug 2007 01:23:37 +0100 Subject: Zod -> Moonshine -> ? Moonshine is a , is a In-Reply-To: <1187033029.4921.26.camel@localhost.localdomain> References: <20070813122455.724d7df4@weaponx.rchland.ibm.com> <1187033029.4921.26.camel@localhost.localdomain> Message-ID: <645d17210708131723s6b7c0f8ck928a3147c76e5d86@mail.gmail.com> On 13/08/07, Jeremy Katz wrote: > On Mon, 2007-08-13 at 12:24 -0500, Josh Boyer wrote: > > That's right... it's time to start naming the Fedora 8 release. Fill > > in your suggestion for the blanks. Remember the rules: > > > > 1) must have some link to Moonshine > > More specifically, the link should be > Moonshine is a and > NewName is a > > Where blank is the same for both How about Jaberwocky? "Moonshine" is a synonym for nonsense. "Jaberwocky" is a synonym for nonsense. http://en.wikipedia.org/wiki/Nonsense [For example Eben Moglen's describing CEO's claims about the GPL as "moonshine"] From jonathan.underwood at gmail.com Tue Aug 14 00:29:16 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 14 Aug 2007 01:29:16 +0100 Subject: Zod -> Moonshine -> ? Moonshine is a , is a In-Reply-To: <645d17210708131723s6b7c0f8ck928a3147c76e5d86@mail.gmail.com> References: <20070813122455.724d7df4@weaponx.rchland.ibm.com> <1187033029.4921.26.camel@localhost.localdomain> <645d17210708131723s6b7c0f8ck928a3147c76e5d86@mail.gmail.com> Message-ID: <645d17210708131729gbbbd3d8tc6f4baa9e85f03ad@mail.gmail.com> On 14/08/07, Jonathan Underwood wrote: > On 13/08/07, Jeremy Katz wrote: > > On Mon, 2007-08-13 at 12:24 -0500, Josh Boyer wrote: > > > That's right... it's time to start naming the Fedora 8 release. Fill > > > in your suggestion for the blanks. Remember the rules: > > > > > > 1) must have some link to Moonshine > > > > More specifically, the link should be > > Moonshine is a and > > NewName is a > > > > Where blank is the same for both > > How about Jaberwocky? > > "Moonshine" is a synonym for nonsense. > "Jaberwocky" is a synonym for nonsense. > > http://en.wikipedia.org/wiki/Nonsense > > [For example Eben Moglen's describing CEO's claims about the GPL as "moonshine"] > Um ... s/CEO/SCO From peter at thecodergeek.com Mon Aug 13 21:19:37 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 13 Aug 2007 14:19:37 -0700 Subject: Zod -> Moonshine -> ? Moonshine is a , is a In-Reply-To: <20070813122455.724d7df4@weaponx.rchland.ibm.com> References: <20070813122455.724d7df4@weaponx.rchland.ibm.com> Message-ID: <1187039977.28113.19.camel@tuxhugs> How about "Singularity"? Both of these (including Moonshine) are mathematical theories. See: http://en.wikipedia.org/wiki/Moonshine_theory http://en.wikipedia.org/wiki/Singularity_theory -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From john at curioussymbols.com Tue Aug 14 04:38:14 2007 From: john at curioussymbols.com (John Pye) Date: Tue, 14 Aug 2007 14:38:14 +1000 Subject: fedora 6 updates? Message-ID: <46C131B6.8000802@curioussymbols.com> Hi all I have managed to get my two packages Fityk and SUNDIALS into Fedora 7 Updates, but for some reason I haven't seen them in Fedora 6 updates just yet. I understood that for Fedora 6, the package ended up in Updates automatically. Is there something I forgot to do? Cheers JP From dwmw2 at infradead.org Tue Aug 14 05:02:40 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 14 Aug 2007 13:02:40 +0800 Subject: Zod -> Moonshine -> ? Moonshine is a , is a In-Reply-To: <20070813201002.194676aa@python3.es.egwn.lan> References: <20070813122455.724d7df4@weaponx.rchland.ibm.com> <20070813200126.435b3e43@python3.es.egwn.lan> <1187028043.2876.102.camel@localhost.localdomain> <20070813201002.194676aa@python3.es.egwn.lan> Message-ID: <1187067760.3707.66.camel@shinybook.infradead.org> On Mon, 2007-08-13 at 20:10 +0200, Matthias Saou wrote: > Then I'll have to suggest "Gn?le", which is our own home made "nasty" > alcohol ;-) Which meets my requirement of having non-ASCII in it. +1 -- dwmw2 From seg at haxxed.com Tue Aug 14 07:37:35 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 14 Aug 2007 02:37:35 -0500 Subject: Zod -> Moonshine -> ? Moonshine is a , is a In-Reply-To: <20070813122455.724d7df4@weaponx.rchland.ibm.com> References: <20070813122455.724d7df4@weaponx.rchland.ibm.com> Message-ID: <1187077055.4904.9.camel@localhost> Peace Love Freedom Liberty Rainbow Sunshine Hope Harmony Sunflower Maryjane Summer Karma Butterfly Charity Stardust Lennon Beetle Berkeley Woodstock Wavy Gravy (The theme is "Hippies", Moonshine sounds like a hippie to me.) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugs.michael at gmx.net Tue Aug 14 07:49:06 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 14 Aug 2007 09:49:06 +0200 Subject: fedora 6 updates? In-Reply-To: <46C131B6.8000802@curioussymbols.com> References: <46C131B6.8000802@curioussymbols.com> Message-ID: <20070814094906.e889e726.bugs.michael@gmx.net> On Tue, 14 Aug 2007 14:38:14 +1000, John Pye wrote: > Hi all > > I have managed to get my two packages Fityk and SUNDIALS into Fedora 7 > Updates, but for some reason I haven't seen them in Fedora 6 updates > just yet. > > I understood that for Fedora 6, the package ended up in Updates > automatically. Is there something I forgot to do? > > Cheers > JP Perhaps you've not looked in the right repository? Or maybe you've searched for all-capitals "SUNDIALS" instead of "sundials"? sundials is here: https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00537.html fityk is in the repo since 21-Jul-2007 (!) already. From john at curioussymbols.com Tue Aug 14 08:12:56 2007 From: john at curioussymbols.com (John Pye) Date: Tue, 14 Aug 2007 18:12:56 +1000 Subject: fedora 6 updates? In-Reply-To: <20070814094906.e889e726.bugs.michael@gmx.net> References: <46C131B6.8000802@curioussymbols.com> <20070814094906.e889e726.bugs.michael@gmx.net> Message-ID: <46C16408.8020102@curioussymbols.com> I was trying to find it at http://download.fedora.redhat.com/pub/fedora/linux/core/updates/6/i386/ but I don't see it there. Reason why? Cheers JP Michael Schwendt wrote: > On Tue, 14 Aug 2007 14:38:14 +1000, John Pye wrote: > > >> Hi all >> >> I have managed to get my two packages Fityk and SUNDIALS into Fedora 7 >> Updates, but for some reason I haven't seen them in Fedora 6 updates >> just yet. >> >> I understood that for Fedora 6, the package ended up in Updates >> automatically. Is there something I forgot to do? >> >> Cheers >> JP >> > > Perhaps you've not looked in the right repository? Or maybe > you've searched for all-capitals "SUNDIALS" instead of "sundials"? > > sundials is here: > https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00537.html > > fityk is in the repo since 21-Jul-2007 (!) already. > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From bugs.michael at gmx.net Tue Aug 14 08:19:02 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 14 Aug 2007 10:19:02 +0200 Subject: fedora 6 updates? In-Reply-To: <46C16408.8020102@curioussymbols.com> References: <46C131B6.8000802@curioussymbols.com> <20070814094906.e889e726.bugs.michael@gmx.net> <46C16408.8020102@curioussymbols.com> Message-ID: <20070814101902.66ee2546.bugs.michael@gmx.net> On Tue, 14 Aug 2007 18:12:56 +1000, John Pye wrote: > I was trying to find it at > http://download.fedora.redhat.com/pub/fedora/linux/core/updates/6/i386/ > > but I don't see it there. Reason why? For Fedora 6 and earlier, it's a "Fedora Extras" package, not a Core package: http://download.fedora.redhat.com/pub/fedora/linux/extras/6/ From pmatilai at redhat.com Tue Aug 14 09:24:17 2007 From: pmatilai at redhat.com (Panu Matilainen) Date: Tue, 14 Aug 2007 12:24:17 +0300 (EEST) Subject: Popt package split planning Message-ID: Thought I'd post this to -maintainers for potential discussion first before going to -devel-announce... As you might know, popt is one of the long-time offenders in that the main package provides both runtime and development libraries + includes. That's about to change now. This involves quite a few changes: 1) Currently popt package is built from within rpm package, which is just nuts because popt has it's own versioning and bundling within rpm causes nasty complications because of that. Popt will be split off into a separate package, review request is at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249352 2) As rpm depends on it, popt has been always installed everywhere and because it has included the development environment too, few packages explicitly buildrequire it. 3) A *lot* of packages actually on popt. See attached requires-popt.txt file, generated with 'repoquery --repoid=development --whatrequires --alldeps popt --queryformat "%{sourcerpm}"|sort -u' Quite a few of these will probably be covered by popt-devel in lower level libraries (some gnome-devel package requiring popt-devel or such) but not all. To ease transition, starting from the next rawhide push, the popt package that's still built from rpm.spec adds Provides: popt-devel = %{version}-%{release} so you can start adding the buildrequires for the packages needing it already. Once the new popt package is reviewed and published to repositories, rpm will be changed to build against that and drop the internal popt entirely. popt-1.12 (the new package in review) is supposed to be ABI and API compatible to the current one (1.10.2.1) but a rebuild of depending packages against the new version might not be a bad idea anyway... Did I miss anything / other comments? - Panu - From ville.skytta at iki.fi Tue Aug 14 09:45:50 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Tue, 14 Aug 2007 12:45:50 +0300 Subject: Popt package split planning In-Reply-To: References: Message-ID: <200708141245.50847.ville.skytta@iki.fi> On Tuesday 14 August 2007, Panu Matilainen wrote: > 3) A *lot* of packages actually on popt. See attached requires-popt.txt [...] > Did I miss anything The attachment? :) From pmatilai at redhat.com Tue Aug 14 09:58:49 2007 From: pmatilai at redhat.com (Panu Matilainen) Date: Tue, 14 Aug 2007 12:58:49 +0300 (EEST) Subject: Popt package split planning In-Reply-To: References: Message-ID: On Tue, 14 Aug 2007, Panu Matilainen wrote: > > 3) A *lot* of packages actually on popt. See attached requires-popt.txt file, > generated with > 'repoquery --repoid=development --whatrequires --alldeps popt --queryformat > "%{sourcerpm}"|sort -u' Duh, and the actual attachment... well, inlining here instead: abiword-2.4.6-5.fc7.src.rpm agave-0.4.2-4.fc8.src.rpm alleyoop-0.9.3-2.fc6.src.rpm anaconda-11.3.0.18-1.src.rpm anjuta-2.2.0-2.fc8.src.rpm anjuta-gdl-0.7.3-1.fc7.src.rpm apt-0.5.15lorg3.92-2.fc8.src.rpm atomix-2.14.0-2.fc6.src.rpm autobuild-applet-1.0.3-3.fc7.src.rpm bacula-2.0.3-9.fc8.src.rpm balsa-2.3.17-1.fc8.src.rpm blam-1.8.3-6.fc8.src.rpm bluefish-1.0.7-1.fc7.src.rpm brasero-0.6.0-1.fc8.src.rpm bug-buddy-2.18.0-2.fc7.src.rpm buoh-0.8.2-2.fc7.src.rpm byzanz-0.1.1-4.fc6.src.rpm callweaver-1.2-0.1.rc3.svn2861.fc8.src.rpm celestia-1.4.1-7.fc7.src.rpm chkconfig-1.3.35-1.src.rpm chkfontpath-1.10.1-1.1.src.rpm compiz-0.5.2-3.fc8.src.rpm conglomerate-0.9.1-3.fc7.src.rpm contact-lookup-applet-0.16-2.fc8.src.rpm contacts-0.6-1.fc8.src.rpm control-center-2.19.6-3.fc8.src.rpm cryptsetup-luks-1.0.5-4.fc8.src.rpm dasher-4.5.2-2.fc8.src.rpm dates-0.4.4-1.fc8.src.rpm deskbar-applet-2.19.5-1.fc8.src.rpm dia-0.96.1-2.fc8.src.rpm drivel-2.1.0-0.4.20060527cvs.fc7.src.rpm eds-feed-0.5.0-6.fc7.src.rpm eel2-2.19.6-1.fc8.src.rpm eiciel-0.9.4-1.fc7.src.rpm ekiga-2.0.9-1.fc7.src.rpm empathy-0.8-1.fc8.src.rpm eog-2.19.4-4.fc8.src.rpm epiphany-2.19.6-3.fc8.src.rpm etherape-0.9.7-5.fc7.src.rpm evince-0.9.3-4.fc8.src.rpm evolution-2.11.6.1-1.fc8.src.rpm evolution-bogofilter-0.2.0-5.fc7.src.rpm evolution-data-server-1.11.6-1.fc8.src.rpm evolution-exchange-2.11.5-2.fc8.src.rpm evolution-sharp-0.13.1-1.fc8.src.rpm evolution-webcal-2.10.0-1.fc7.src.rpm fast-user-switch-applet-2.18.0-1.fc8.src.rpm file-roller-2.19.4-1.fc8.src.rpm firefox-2.0.0.6-2.fc8.src.rpm firestarter-1.0.3-16.fc8.src.rpm flac123-0.0.11-1.fc8.src.rpm gai-0.5.10-10.fc7.src.rpm gai-pal-0.7-11.src.rpm gai-temp-0.1.1-7.src.rpm galeon-2.0.3-9.fc8.src.rpm gcdmaster-1.2.2-1.fc6.src.rpm gchempaint-0.8.2-2.fc8.src.rpm gconf-editor-2.18.0-1.fc7.src.rpm gdesklets-0.35.4-8.fc8.src.rpm gedit-2.19.3-1.fc8.src.rpm gedit-plugins-2.18.0-2.fc7.src.rpm genius-0.7.7-2.fc7.src.rpm ghex-2.19.0-1.1.src.rpm glabels-2.0.4-6.fc8.src.rpm glade2-2.12.1-9.fc8.src.rpm glipper-0.95.1-2.fc7.src.rpm glom-1.5.2-1.fc8.src.rpm glunarclock-0.32.4-9.fc8.src.rpm gmrun-0.9.2-7.fc7.src.rpm gnome-applet-music-2.2.0-1.fc8.src.rpm gnome-applet-netspeed-0.14-1.fc8.src.rpm gnome-applets-2.19.1-7.fc8.src.rpm gnome-applet-sensors-1.8.1-3.fc8.src.rpm gnome-applet-timer-1.3.3-1.fc7.src.rpm gnome-applet-vm-0.1.2-2.fc7.src.rpm gnomebaker-0.6.0-4.fc8.src.rpm gnome-bluetooth-0.9.1-1.fc8.src.rpm gnome-build-0.1.4-2.fc7.src.rpm gnome-commander-1.2.4-3.fc8.src.rpm gnome-desktop-2.19.6-1.fc8.src.rpm gnome-games-2.19.90b-1.fc8.src.rpm gnome-keyring-manager-2.18.0-3.fc8.src.rpm gnome-launch-box-0.4-3.fc8.src.rpm gnome-media-2.18.0-3.fc7.src.rpm gnome-mount-0.7-0.git20070725.1.fc8.src.rpm gnome-netstatus-2.12.1-1.fc7.src.rpm gnome-panel-2.19.5-6.fc8.src.rpm gnome-phone-manager-0.8-5.fc7.src.rpm gnome-pilot-2.0.15-5.fc7.src.rpm gnome-pilot-conduits-2.0.15-3.fc7.src.rpm gnome-power-manager-2.19.6-1.fc8.src.rpm gnome-python2-2.19.2-1.fc8.src.rpm gnome-python2-desktop-2.19.2-1.fc8.src.rpm gnome-python2-extras-2.19.1-4.fc8.src.rpm gnomeradio-1.6-3.fc6.src.rpm gnomescan-0.4.0.2-1.fc7.src.rpm gnome-screensaver-2.19.6-4.fc8.src.rpm gnome-session-2.19.6-5.fc8.src.rpm gnome-sharp-2.16.0-4.fc8.src.rpm gnome-spell-1.0.7-4.fc7.src.rpm gnomesword-2.2.3-4.fc8.src.rpm gnome-terminal-2.18.1-1.fc8.src.rpm gnome-translate-0.99-11.fc7.src.rpm gnome-utils-2.18.1-2.fc8.src.rpm gnome-volume-manager-2.17.0-7.fc7.src.rpm gnotime-2.2.2-7.fc6.src.rpm gnubiff-2.2.7-1.fc8.src.rpm gnucash-2.2.0-2.fc8.src.rpm gnumeric-1.6.3-9.fc8.src.rpm goffice04-0.4.2-1.fc8.src.rpm gok-1.3.1-1.fc8.src.rpm gossip-0.26-4.fc8.src.rpm gphoto2-2.4.0-1.fc8.src.rpm gphpedit-0.9.91-3.fc6.src.rpm gpp-0.6.6-3.fc6.src.rpm gpsim-0.22.0-3.fc7.src.rpm grhino-0.16.0-1.fc7.src.rpm grip-3.2.0-16.fc7.src.rpm gstm-1.2-6.fc7.src.rpm gsynaptics-0.9.12-2.fc8.src.rpm gthumb-2.10.5-2.fc8.src.rpm GtkAda-2.8.0-7.fc7.src.rpm gtkhtml3-3.15.6.1-1.fc8.src.rpm gtkhtml38-3.12.3-5.fc8.src.rpm gtkmathview-0.7.6-5.fc6.src.rpm gtk-qt-engine-0.70-5.20070811svn.fc8.src.rpm gtk-sharp-1.0.10-12.fc7.src.rpm gtranslator-1.1.7-3.fc8.src.rpm gtweakui-0.4.0-4.src.rpm gucharmap-1.10.0-1.fc7.src.rpm gweled-0.7-8.fc7.src.rpm gwget-0.99-1.fc8.src.rpm heliodor-0.2.1-2.fc8.src.rpm icewm-1.2.30-13.fc7.src.rpm icon-slicer-0.3-8.src.rpm im-chooser-0.4.1-3.fc8.src.rpm inkscape-0.45.1-1.fc7.src.rpm k3d-0.6.7.0-2.fc8.src.rpm keepalived-1.1.13-7.fc8.src.rpm krb5-auth-dialog-0.7-2.src.rpm ldapvi-1.7-1.fc8.src.rpm libbonoboui-2.19.6-1.fc8.src.rpm libdv-1.0.0-1.fc7.src.rpm libgail-gnome-1.19.5-1.fc8.src.rpm libgnome-2.19.1-3.fc8.src.rpm libgnome-java-2.12.4-6.fc7.src.rpm libgnomekbd-2.19.90-1.fc8.src.rpm libgnomemm26-2.18.0-1.src.rpm libgnomeprint22-2.18.1-1.fc8.src.rpm libgnomeui-2.19.1-1.fc8.src.rpm libgnomeuimm26-2.18.0-1.src.rpm libopensync-plugin-evolution2-0.22-1.fc7.src.rpm librsync-0.9.7-10.fc7.src.rpm libtomoe-gtk-0.6.0-1.fc8.src.rpm libuser-0.56.4-2.src.rpm lock-keys-applet-1.0-13.fc8.src.rpm logjam-4.5.3-9.fc7.1.src.rpm logrotate-3.7.6-1.fc8.src.rpm mail-notification-4.1-3.fc8.src.rpm mkinitrd-6.0.9-9.src.rpm monkey-bubble-0.4.0-7.fc8.src.rpm mugshot-1.1.49-1.fc8.src.rpm mysql-gui-tools-5.0r12-2.fc8.src.rpm nautilus-2.19.6-3.fc8.src.rpm nautilus-actions-1.4.1-1.fc8.src.rpm nautilus-cd-burner-2.19.6-1.fc8.src.rpm nautilus-open-terminal-0.7-3.fc6.src.rpm nautilus-python-0.4.3-4.fc7.src.rpm nautilus-search-tool-0.2-2.fc6.src.rpm nautilus-sendto-0.10-4.fc7.src.rpm nemiver-0.4.0-1.fc8.src.rpm net-snmp-5.4.1-1.fc8.src.rpm NetworkManager-0.6.5-8.fc8.src.rpm NetworkManager-openvpn-0.3.2-7.fc6.src.rpm NetworkManager-vpnc-0.6.4-3.fc7.src.rpm newt-0.52.7-2.fc8.src.rpm ocaml-lablgtk-2.6.0-8.20060908cvs.fc8.src.rpm OpenIPMI-2.0.6-7.fc7.src.rpm openpbx-1.2-3.rc3.svn2540.fc7.src.rpm openvrml-0.16.6-2.fc8.src.rpm oprofile-0.9.3-2.fc8.src.rpm ots-0.4.2-11.fc7.src.rpm panelfm-1.2-2.fc7.1.src.rpm passwd-0.74-3.fc7.src.rpm perl-RPM2-0.67-2.fc7.src.rpm pidgin-2.1.0-1.fc8.src.rpm pilot-link-0.12.2-4.fc8.src.rpm planner-0.14.2-8.fc8.src.rpm PolicyKit-gnome-0.5-0.git20070731.4.fc8.src.rpm polyxmass-bin-0.9.3-2.fc6.src.rpm qalculate-gtk-0.9.6-1.fc8.src.rpm referencer-1.0.4-2.fc8.src.rpm resapplet-0.1.1-5.fc7.src.rpm rhgb-0.17.6-4.fc8.src.rpm rhythmbox-0.11.1-1.fc8.src.rpm rpm-4.4.2.1-6.fc8.src.rpm rsync-2.6.9-2.fc7.src.rpm ruby-gnome2-0.16.0-10.fc8.src.rpm samba-3.0.25b-3.fc8.src.rpm scim-tomoe-0.6.0-1.fc8.src.rpm seahorse-1.0.1-7.fc8.src.rpm seamonkey-1.1.3-6.fc8.src.rpm sound-juicer-2.19.2-1.fc8.src.rpm synaptic-0.57.2-12.fc8.src.rpm synce-software-manager-0.9.0-7.fc6.src.rpm synce-trayicon-0.9.0-8.fc6.src.rpm system-config-securitylevel-1.7.0-5.1.fc8.src.rpm tasks-0.10-2.fc8.src.rpm totem-2.19.4-2.fc8.src.rpm tracker-0.6.1-1.fc8.src.rpm tsclient-0.150-2.fc8.src.rpm ttywatch-0.14-7.fc6.src.rpm tux-3.2.18-9.fc6.src.rpm uim-1.4.1-4.fc8.src.rpm usbsink-0.3.1-1.fc7.src.rpm util-linux-2.13-0.52.fc7.src.rpm v4l2-tool-1.0.2-2.fc7.src.rpm verbiste-0.1.20-1.fc7.src.rpm vino-2.19.5-1.fc8.src.rpm wbxml2-0.9.2-8.fc7.src.rpm workrave-1.8.4-3.fc7.src.rpm wp_tray-0.5.3-4.fc7.src.rpm xchat-gnome-0.18-2.fc8.src.rpm xfce4-xfapplet-plugin-0.1.0-3.fc7.src.rpm xsri-2.1.0-10.fc6.src.rpm yelp-2.19.1-4.fc8.src.rpm From ville.skytta at iki.fi Tue Aug 14 11:57:16 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Tue, 14 Aug 2007 14:57:16 +0300 Subject: Should Rawhide inherit from dist-f7-updates-testing? Message-ID: <200708141457.16445.ville.skytta@iki.fi> Hi, I pushed a html401-dtds update to F7 updates-testing assuming that Rawhide would pick it up from there. But it looks like Rawhide pulls only from dist-fc7-updates, not dist-fc7-updates-testing. Is this intentional? https://koji.fedoraproject.org/koji/taginfo?tagID=12 From icon at fedoraproject.org Tue Aug 14 12:41:59 2007 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Tue, 14 Aug 2007 08:41:59 -0400 Subject: Zod -> Moonshine -> ? Moonshine is a , is a In-Reply-To: <20070813122455.724d7df4@weaponx.rchland.ibm.com> References: <20070813122455.724d7df4@weaponx.rchland.ibm.com> Message-ID: Kvass Moonshine is a home-made alcoholic drink Kvass is also a home-made mildly alcoholic drink http://en.wikipedia.org/wiki/Kvass -- Konstantin Ryabitsev Montr?al, Qu?bec From jkeating at redhat.com Tue Aug 14 13:57:11 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 14 Aug 2007 09:57:11 -0400 Subject: Should Rawhide inherit from dist-f7-updates-testing? In-Reply-To: <200708141457.16445.ville.skytta@iki.fi> References: <200708141457.16445.ville.skytta@iki.fi> Message-ID: <20070814095711.4f6d82fd@mentok.boston.redhat.com> On Tue, 14 Aug 2007 14:57:16 +0300 "Ville Skytt?" wrote: > I pushed a html401-dtds update to F7 updates-testing assuming that > Rawhide would pick it up from there. But it looks like Rawhide pulls > only from dist-fc7-updates, not dist-fc7-updates-testing. Is this > intentional? Yes, this is intentional. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Tue Aug 14 14:36:03 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 14 Aug 2007 09:36:03 -0500 Subject: Zod -> Moonshine -> ? Moonshine is a , is a In-Reply-To: <1187077055.4904.9.camel@localhost> References: <20070813122455.724d7df4@weaponx.rchland.ibm.com> <1187077055.4904.9.camel@localhost> Message-ID: <20070814093603.29196f27@vader.jdub.homelinux.org> On Tue, 14 Aug 2007 02:37:35 -0500 Callum Lerwick wrote: > Peace > Love > Freedom > Liberty > Rainbow > Sunshine > Hope > Harmony > Sunflower > Maryjane > Summer > Karma > Butterfly > Charity > Stardust > Lennon > Beetle > Berkeley > Woodstock > Wavy Gravy > > (The theme is "Hippies", Moonshine sounds like a hippie to me.) Pick one or two of the above. I'm not submitting all those. josh From alan at redhat.com Tue Aug 14 14:53:02 2007 From: alan at redhat.com (Alan Cox) Date: Tue, 14 Aug 2007 10:53:02 -0400 Subject: Zod -> Moonshine -> ? Moonshine is a , is a In-Reply-To: <20070814093603.29196f27@vader.jdub.homelinux.org> References: <20070813122455.724d7df4@weaponx.rchland.ibm.com> <1187077055.4904.9.camel@localhost> <20070814093603.29196f27@vader.jdub.homelinux.org> Message-ID: <20070814145302.GA7882@devserv.devel.redhat.com> > > (The theme is "Hippies", Moonshine sounds like a hippie to me.) > > Pick one or two of the above. I'm not submitting all those. Not eligible IMHO - Sounds like a hippie - needs to find a real hippie. From harald at redhat.com Tue Aug 14 15:02:59 2007 From: harald at redhat.com (Harald Hoyer) Date: Tue, 14 Aug 2007 17:02:59 +0200 Subject: Zod -> Moonshine -> ? Moonshine is a , is a In-Reply-To: <20070813122455.724d7df4@weaponx.rchland.ibm.com> References: <20070813122455.724d7df4@weaponx.rchland.ibm.com> Message-ID: <46C1C423.5070507@redhat.com> Moonshine movie http://imdb.com/find?s=all&q=moonshine -> I would prefer "23" (http://imdb.com/title/tt0126765/) :-) I also like the mathematical theories chain http://en.wikipedia.org/wiki/Moonshine_theory -> Orbifold (http://en.wikipedia.org/wiki/Orbifold) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3623 bytes Desc: S/MIME Cryptographic Signature URL: From pix at crazyfrogs.org Tue Aug 14 15:06:43 2007 From: pix at crazyfrogs.org (Pix) Date: Tue, 14 Aug 2007 17:06:43 +0200 Subject: Zod -> Moonshine -> ? Moonshine is a , is a In-Reply-To: <20070813122455.724d7df4@weaponx.rchland.ibm.com> References: <20070813122455.724d7df4@weaponx.rchland.ibm.com> Message-ID: <1187104003.26128.4.camel@ruatha.wyplay.int> My cents: Apollo (a greek god, link with NASA / Moon missions) Spectrum (Sunshine is the total spectrum of the electromagnetic radiation given off by the Sun - wikipedia) Shadow (Link with sunshine / moonshine) Cheers :) Le lundi 13 ao?t 2007 ? 12:24 -0500, Josh Boyer a ?crit : > That's right... it's time to start naming the Fedora 8 release. Fill > in your suggestion for the blanks. Remember the rules: > > 1) must have some link to Moonshine > 2) The link between and Moonshine cannot be the same as between > Zod and Moonshine > > Suggestions will be run through the legal queue and an election will > happen for Fedora contributors to pick the next Fedora name. > > Let the naming begin! > > josh > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jochen at herr-schmitt.de Tue Aug 14 15:21:58 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Tue, 14 Aug 2007 17:21:58 +0200 Subject: License review for new itext version In-Reply-To: <46C08D19.1050503@hhs.nl> References: <46BF752E.4030500@herr-schmitt.de> <1186954256.4243.82.camel@new-host-2> <0ML2xA-1IKcQY0vMW-0001cF@mrelayeu.kundenserver.de> <46C08D19.1050503@hhs.nl> Message-ID: <0ML31I-1IKyDL1VnA-0002bH@mrelayeu.kundenserver.de> On Mon, 13 Aug 2007 18:55:53 +0200, you wrote: >Ah yes, that sounds much better then the "So iTex will still be dead for >Fedora" sentence from your other mail. Usually when a license is so close, and >upstream is not dead, the chances are quite good upstream will be willing to >change the license. Notice that some (severe) stubbornness from yuor side may >be needed to get to the point where the license actually gets changed. When I wrote 'IText sill dead for Fedora' this described the current state, but any upstream should has the chance to change the situation by clarification the licensing conditions. The main issue, I see, is the fact, that the source code which cause the licensing issue are comming from Sun Inc. Best Regards: Jochen Schmitt From nicolas.mailhot at laposte.net Tue Aug 14 15:30:24 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 14 Aug 2007 17:30:24 +0200 (CEST) Subject: Zod -> Moonshine -> ? Moonshine is a , is a In-Reply-To: <1187104003.26128.4.camel@ruatha.wyplay.int> References: <20070813122455.724d7df4@weaponx.rchland.ibm.com> <1187104003.26128.4.camel@ruatha.wyplay.int> Message-ID: <30045.192.54.193.51.1187105424.squirrel@rousalka.dyndns.org> Oh, well A very obvious one: werewolf (can use a non-english translation to get some non-ascii chars) -- Nicolas Mailhot From alan at redhat.com Tue Aug 14 16:45:39 2007 From: alan at redhat.com (Alan Cox) Date: Tue, 14 Aug 2007 12:45:39 -0400 Subject: Zod -> Moonshine -> ? Moonshine is a , is a In-Reply-To: <1187104003.26128.4.camel@ruatha.wyplay.int> References: <20070813122455.724d7df4@weaponx.rchland.ibm.com> <1187104003.26128.4.camel@ruatha.wyplay.int> Message-ID: <20070814164539.GA13871@devserv.devel.redhat.com> On Tue, Aug 14, 2007 at 05:06:43PM +0200, Pix wrote: > My cents: > > Apollo (a greek god, link with NASA / Moon missions) > Spectrum (Sunshine is the total spectrum of the > electromagnetic radiation given off by the Sun - wikipedia) > Shadow (Link with sunshine / moonshine) > Also in that theme Earthlight - which is the equivalent of moonshine from the other surface From fedora at leemhuis.info Tue Aug 14 17:03:47 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 14 Aug 2007 19:03:47 +0200 Subject: EPEL report week 32 2007 Message-ID: <46C1E073.6030805@leemhuis.info> = Weekly EPEL Summary = Week 32/2007 == Most important happenings == * Noting major == EPEL SIG Meeting == === Attending === >From the Steering Committee: * dgilmore (DennisGilmore) * knurd (ThorstenLeemhuis) * mmcgrath (MikeMcGrath) * Jeff_S (Jeff Sheltren) (very late ;-) ) Missing from the Steering Committee: * quaid (KarstenWade) (traveling) * nirik (KevinFenzi) * stahnma (MichaelStahnke) Others that participated the meeting: nobody === Summary === * meetings * some discussions around the format; some quotes: "we maybe should do more stuff on the list and less in the meeting" "move meetings to every other week?" "seems we don't get all the important or interested people into the meeting so maybe doing them only every two week and instead finish some stuff on the list might be easier for everyone. Discuss this on the list further * new push scripts for pushing to testing, adjust mock configs to use testing -- dgilmore * still on the todo-list * "branch for EPEL if Fedora maintainer does not react"? * some discussions if the wording is clear enough * yum for EPEL4 * Jeff_S will investigate if it's possible to ship yum without a yum.conf === Full Log === https://www.redhat.com/archives/epel-devel-list/2007-August/msg00062.html == Stats == Nothing new over the past days. ---- ["CategoryEPELReports"] From overholt at redhat.com Tue Aug 14 17:32:50 2007 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 14 Aug 2007 13:32:50 -0400 Subject: FeatureEclipse33 Status Message-ID: <1187112770.11441.17.camel@localhost.localdomain> Hi, Here's the status of the Fedora 8 feature of updating the Eclipse stack to the 3.3 (Europa) base [1]. I've CC'd all of the maintainers. Please reply with answers where you can. SDK (Ben Konrath) - largely done - working through a build-id issue - needs jetty5 review and inclusion (bug #202334) - need to investigate tweaking memory limits in eclipse.ini if IcedTea gets into F8 Mylyn (Andrew Overholt) - awaiting CVS rename - otherwise good to go EMF (Andrew Overholt) - would require a *tonne* of changes: probably multiple new SRPMs, lots of Provides and Obsoletes - since nothing depends upon it, I propose we drop it from Fedora 8 - anyone object? care to take it over? GEF (Andrew Overholt) - since nothing depends upon it, I propose we drop it from Fedora 8 - see last comment under EMF :) ChangeLog (Jeff Johnston) - mostly complete (I think) - Jeff? CDT & autotools (Jeff Johnston) - ready AFAIK - Jeff? Subclipse (Robert Marcano) - ready, right, Robert? PyDev (Igor Foox) - Igor: can you update to latest version that works with 3.3? If not, can you orphan it? Ben says he can take it over if you don't have time. - would be nice to get Mylyn integration in when we update sdl-nls, nlspackager (Andrew Overholt) - I'm going to remove these since there are no translations for 3.3 upstream checkstyle (Rob Myers) - things are good to go, right, Rob? quickrex (Alphonse Van Assche) - things work with 3.3, right, Alphonse? phpeclipse (Brandon Holbrook) - do things work with 3.3, Brandon? specfile editor (Alphonse Van Assche ... yes, I'm perhaps jumping the gun a bit here ;) - are we good to get this in by test2, Alphonse? Thanks, Andrew [1] http://fedoraproject.org/wiki/FeatureEclipse33 -------------- 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 packages at amiga-hardware.com Tue Aug 14 19:00:15 2007 From: packages at amiga-hardware.com (Ian Chapman) Date: Tue, 14 Aug 2007 20:00:15 +0100 Subject: Zod -> Moonshine -> ? Moonshine is a , is a In-Reply-To: <20070813122455.724d7df4@weaponx.rchland.ibm.com> References: <20070813122455.724d7df4@weaponx.rchland.ibm.com> Message-ID: <46C1FBBF.2030403@amiga-hardware.com> Josh Boyer wrote: > That's right... it's time to start naming the Fedora 8 release. Fill > in your suggestion for the blanks. Remember the rules: > > 1) must have some link to Moonshine > 2) The link between and Moonshine cannot be the same as between > Zod and Moonshine = Photon Moonshine (as in light) being made of photons. -- Ian Chapman. From SteveD at redhat.com Tue Aug 14 21:34:31 2007 From: SteveD at redhat.com (Steve Dickson) Date: Tue, 14 Aug 2007 17:34:31 -0400 Subject: system-config-lvm In-Reply-To: <20070804102203.26ab10f1@ender> References: <46B44CE9.7050304@RedHat.com> <20070804102203.26ab10f1@ender> Message-ID: <46C21FE7.2080508@RedHat.com> Jesse Keating wrote: > On Sat, 04 Aug 2007 05:54:49 -0400 > Steve Dickson wrote: > >> Hello, >> >> I notice with f7 that system-config-lvm is no longer installed >> by default and if I remember correctly there was not even an >> option to choose it... >> >> Just curious as to what happen and why? I personally find it >> to be a excellent tool, especially when configuring >> xen/kvm guests... > > It just didn't find it's way to the manifest. > > https://hosted.fedoraproject.org/projects/pungi/browser/config/f8-fedora.manifest > > Either system-config-lvm should be added to the manifest, or made a > default in one of the groups we already include, that is if we (Fedora) > deem system-config-lvm to be necessary on the media we spin. How one make this happen... And who make those decisions? Not having away to configure my LVM was a bit of a pain when I went to f7... I would think if the installer configures LVM partitions that a way to configure them would be needed... by default... steved. From jkeating at redhat.com Tue Aug 14 21:38:05 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 14 Aug 2007 17:38:05 -0400 Subject: system-config-lvm In-Reply-To: <46C21FE7.2080508@RedHat.com> References: <46B44CE9.7050304@RedHat.com> <20070804102203.26ab10f1@ender> <46C21FE7.2080508@RedHat.com> Message-ID: <20070814173805.2fd046dd@mentok.boston.redhat.com> On Tue, 14 Aug 2007 17:34:31 -0400 Steve Dickson wrote: > How one make this happen... Typically you file a bug against Distribution and state your case, or you edit comps and you make the package a default in one of the groups that are referenced in the manifest. > And who make those decisions? Release Engineering and other such folks. Ultimately I have the commit access to the manifest file, but I'm pretty open to suggestions and typically run things through a set of peers (whomever is on IRC at the time...) > Not having away to configure my LVM was a bit of a pain when I went > to f7... I would think if the installer configures LVM partitions > that a way to configure them would be needed... by default... -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From SteveD at redhat.com Tue Aug 14 22:04:40 2007 From: SteveD at redhat.com (Steve Dickson) Date: Tue, 14 Aug 2007 18:04:40 -0400 Subject: system-config-lvm In-Reply-To: <20070814173805.2fd046dd@mentok.boston.redhat.com> References: <46B44CE9.7050304@RedHat.com> <20070804102203.26ab10f1@ender> <46C21FE7.2080508@RedHat.com> <20070814173805.2fd046dd@mentok.boston.redhat.com> Message-ID: <46C226F8.7000305@RedHat.com> Jesse Keating wrote: > On Tue, 14 Aug 2007 17:34:31 -0400 > Steve Dickson wrote: > >> How one make this happen... > > Typically you file a bug against Distribution and state your case, or > you edit comps and you make the package a default in one of the groups > that are referenced in the manifest. Ok.. I open up the following bug against devel: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=252252 > >> And who make those decisions? > > Release Engineering and other such folks. Ultimately I have the commit > access to the manifest file, but I'm pretty open to suggestions and > typically run things through a set of peers (whomever is on IRC at the > time...) Why was it removed from the manifest? Any particular reason? steved. From alcapcom at gmail.com Tue Aug 14 19:27:08 2007 From: alcapcom at gmail.com (Alphonse Van Assche) Date: Tue, 14 Aug 2007 21:27:08 +0200 Subject: FeatureEclipse33 Status In-Reply-To: <1187112770.11441.17.camel@localhost.localdomain> References: <1187112770.11441.17.camel@localhost.localdomain> Message-ID: <46C2020C.4050304@gmail.com> Andrew Overholt a ?crit : > quickrex (Alphonse Van Assche) > - things work with 3.3, right, Alphonse? Yes, I have tested it with the eclipse version in rawhide and it work like expect. > specfile editor (Alphonse Van Assche ... yes, I'm perhaps jumping the > gun a bit here ;) > - are we good to get this in by test2, Alphonse? :) I think, I'm waiting the update of the changelog plugin (2.4.1 or so) because of namespaces incompatibility between the current version (2.3.4) and the specfile editor. Btw, I have just finished packaging Remote System Explorer (RSE) plugins, I think that there isn't many work to do on it to be able to get it right for test2. Cheers, Alphonse From smooge at gmail.com Tue Aug 14 16:55:49 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 14 Aug 2007 10:55:49 -0600 Subject: Zod -> Moonshine -> ? Moonshine is a , is a In-Reply-To: <20070814164539.GA13871@devserv.devel.redhat.com> References: <20070813122455.724d7df4@weaponx.rchland.ibm.com> <1187104003.26128.4.camel@ruatha.wyplay.int> <20070814164539.GA13871@devserv.devel.redhat.com> Message-ID: <80d7e4090708140955q6be9e036o8f81d649e381a45b@mail.gmail.com> On 8/14/07, Alan Cox wrote: > On Tue, Aug 14, 2007 at 05:06:43PM +0200, Pix wrote: > > My cents: > > > > Apollo (a greek god, link with NASA / Moon missions) > > Spectrum (Sunshine is the total spectrum of the > > electromagnetic radiation given off by the Sun - wikipedia) > > Shadow (Link with sunshine / moonshine) > > > > Also in that theme Earthlight - which is the equivalent of moonshine from > the other surface > Apollo would be an interesting loop (RHL-5.2) . Diana or Artemis would be an interesting play on the theme. Or any number of moon ladies who ruled the night sky. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From icon at fedoraproject.org Tue Aug 14 20:59:12 2007 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Tue, 14 Aug 2007 16:59:12 -0400 Subject: Zod -> Moonshine -> ? Moonshine is a , is a In-Reply-To: <20070813122455.724d7df4@weaponx.rchland.ibm.com> References: <20070813122455.724d7df4@weaponx.rchland.ibm.com> Message-ID: On 8/13/07, Josh Boyer wrote: > 1) must have some link to Moonshine > 2) The link between and Moonshine cannot be the same as between > Zod and Moonshine Brandywine which then lets us go to LOTR and all of other things (e.g. the list here http://en.wikipedia.org/wiki/Brandywine). -- Konstantin Ryabitsev Montr?al, Qu?bec From seg at haxxed.com Wed Aug 15 06:07:22 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 15 Aug 2007 01:07:22 -0500 Subject: Zod -> Moonshine -> ? Moonshine is a , is a In-Reply-To: <20070814093603.29196f27@vader.jdub.homelinux.org> References: <20070813122455.724d7df4@weaponx.rchland.ibm.com> <1187077055.4904.9.camel@localhost> <20070814093603.29196f27@vader.jdub.homelinux.org> Message-ID: <1187158042.11414.3.camel@localhost> On Tue, 2007-08-14 at 09:36 -0500, Josh Boyer wrote: > Pick one or two of the above. I'm not submitting all those. Was just kinda brainstorming. The ones I like best: Freedom Liberty Karma Woodstock Wavy Gravy -------------- 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 mmaslano at redhat.com Wed Aug 15 09:52:31 2007 From: mmaslano at redhat.com (=?ISO-8859-2?Q?Marcela_Ma=B9l=E1=F2ov=E1?=) Date: Wed, 15 Aug 2007 11:52:31 +0200 Subject: Licence of upstream project Message-ID: <46C2CCDF.1020500@redhat.com> I started upstream of vixie-cron with license BSD (original), which isn't GPLv2 compatible. Could I change the license or I have to stay with BSD? Marcela Maslanova From sundaram at fedoraproject.org Wed Aug 15 09:52:21 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 15 Aug 2007 15:22:21 +0530 Subject: Licence of upstream project In-Reply-To: <46C2CCDF.1020500@redhat.com> References: <46C2CCDF.1020500@redhat.com> Message-ID: <46C2CCD5.10807@fedoraproject.org> Marcela Ma?l??ov? wrote: > I started upstream of vixie-cron with license BSD (original), which > isn't GPLv2 compatible. Could I change the license or I have to stay > with BSD? If you are the sole copyright holder, you are free to relicense, but if there are other contributors with copyrightable patches then they would need to agree to relicense or you would need to rewrite inorder for you to able to relicense. Rahul From jkeating at redhat.com Wed Aug 15 11:34:56 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 15 Aug 2007 07:34:56 -0400 Subject: system-config-lvm In-Reply-To: <46C226F8.7000305@RedHat.com> References: <46B44CE9.7050304@RedHat.com> <20070804102203.26ab10f1@ender> <46C21FE7.2080508@RedHat.com> <20070814173805.2fd046dd@mentok.boston.redhat.com> <46C226F8.7000305@RedHat.com> Message-ID: <20070815073456.121d8150@ender> On Tue, 14 Aug 2007 18:04:40 -0400 Steve Dickson wrote: > Why was it removed from the manifest? Any particular reason? It wasn't removed per se. In the past (<=FC6) there was no manifest. Whatever we had inside the RH firewall for Fedora (Core) was on the media. We gave no real thought as to what should be on the media and what should be on the mirrors, we just put it all on. This obviously doesn't scale once we merged core and Extras, as we'd be shipping 3+ DVDs worth of packages for a release. Instead we played around with the idea of multiple targetted spins, like a Desktop spin, a Server spin, a KDE spin, etc.. all with a specific package set, sharing something of a common core. This didn't pan out well, lots of different opinions and ideas as to what should be in those spins, plus lots of overlap with things like the Live images. Instead what we did was a "classic" spin for the installable target that hit the same usage cases as "Core" did in the past. F-7 was the first release using this new method and so there are bound to be some holes in the manifest. It just takes folks like you noticing missing functionality that we feel strongly about having on the media that everybody downloads. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From SteveD at redhat.com Wed Aug 15 12:56:22 2007 From: SteveD at redhat.com (Steve Dickson) Date: Wed, 15 Aug 2007 08:56:22 -0400 Subject: system-config-lvm In-Reply-To: <20070815073456.121d8150@ender> References: <46B44CE9.7050304@RedHat.com> <20070804102203.26ab10f1@ender> <46C21FE7.2080508@RedHat.com> <20070814173805.2fd046dd@mentok.boston.redhat.com> <46C226F8.7000305@RedHat.com> <20070815073456.121d8150@ender> Message-ID: <46C2F7F6.30807@RedHat.com> Jesse Keating wrote: > On Tue, 14 Aug 2007 18:04:40 -0400 > Steve Dickson wrote: > >> Why was it removed from the manifest? Any particular reason? > > It wasn't removed per se. In the past (<=FC6) there was no manifest. > Whatever we had inside the RH firewall for Fedora (Core) was on the > media. We gave no real thought as to what should be on the media and > what should be on the mirrors, we just put it all on. This obviously > doesn't scale once we merged core and Extras, as we'd be shipping 3+ > DVDs worth of packages for a release. Instead we played around with > the idea of multiple targetted spins, like a Desktop spin, a Server > spin, a KDE spin, etc.. all with a specific package set, sharing > something of a common core. This didn't pan out well, lots of > different opinions and ideas as to what should be in those spins, plus > lots of overlap with things like the Live images. Instead what we did > was a "classic" spin for the installable target that hit the same usage > cases as "Core" did in the past. F-7 was the first release using this > new method and so there are bound to be some holes in the manifest. It > just takes folks like you noticing missing functionality that we feel > strongly about having on the media that everybody downloads. Cool... Next time, if there is one, you might want to post what is on the manifest so people have a chance to add or detract from from it... Maybe it was posted and I just missed it... which is a real possibility ;-) email has not been my friend lately... :-\ steved. From jkeating at redhat.com Wed Aug 15 13:39:52 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 15 Aug 2007 09:39:52 -0400 Subject: system-config-lvm In-Reply-To: <46C2F7F6.30807@RedHat.com> References: <46B44CE9.7050304@RedHat.com> <20070804102203.26ab10f1@ender> <46C21FE7.2080508@RedHat.com> <20070814173805.2fd046dd@mentok.boston.redhat.com> <46C226F8.7000305@RedHat.com> <20070815073456.121d8150@ender> <46C2F7F6.30807@RedHat.com> Message-ID: <20070815093952.472441e3@mentok.boston.redhat.com> On Wed, 15 Aug 2007 08:56:22 -0400 Steve Dickson wrote: > Cool... Next time, if there is one, you might want to post what > is on the manifest so people have a chance to add or detract from > from it... Maybe it was posted and I just missed it... which > is a real possibility ;-) email has not been my friend lately... :-\ It was posted frequently and often during the Fedora 7 development cycle. I begged for feedback. Alas.... -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From charlescurley at charlescurley.com Wed Aug 15 01:44:58 2007 From: charlescurley at charlescurley.com (Charles Curley) Date: Tue, 14 Aug 2007 19:44:58 -0600 Subject: Zod -> Moonshine -> ? Moonshine is a , is a In-Reply-To: <1187039977.28113.19.camel@tuxhugs> References: <20070813122455.724d7df4@weaponx.rchland.ibm.com> <1187039977.28113.19.camel@tuxhugs> Message-ID: <20070815014458.GC25120@charlescurley.com> On Mon, Aug 13, 2007 at 02:19:37PM -0700, Peter Gordon wrote: > How about "Singularity"? Are you suggesting that Fedora is bloatware? Or that things that go into Fedora never come out again? "By Hawking, that *is* a vast pile of Fedora DVDs with a strange actinic glare we're being pulled into! Quick, Worsel, the repulsor beams!" -- Charles Curley /"\ ASCII Ribbon Campaign Looking for fine software \ / Respect for open standards and/or writing? X No HTML/RTF in email http://www.charlescurley.com / \ No M$ Word docs in email Key fingerprint = CE5C 6645 A45A 64E4 94C0 809C FFF6 4C48 4ECD DFDB -------------- 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 Wed Aug 15 15:51:46 2007 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Wed, 15 Aug 2007 17:51:46 +0200 Subject: Zod -> Moonshine -> ? Moonshine is a , is a In-Reply-To: <20070813122455.724d7df4@weaponx.rchland.ibm.com> References: <20070813122455.724d7df4@weaponx.rchland.ibm.com> Message-ID: <668bb39a0708150851v50e6eb74yc823ef5772002889@mail.gmail.com> Changes Safe Living In The Moonlight and Moonshine are names of albums by Collage - Polish rock band. http://pl.wikipedia.org/wiki/Collage_(grupa_muzyczna) - look at "Dyskografia" -- Micha? Bentkowski mr.ecik at gmail.com From laurent.rineau__fedora at normalesup.org Wed Aug 15 16:07:29 2007 From: laurent.rineau__fedora at normalesup.org (Laurent Rineau) Date: Wed, 15 Aug 2007 18:07:29 +0200 Subject: Licence of upstream project In-Reply-To: <46C2CCD5.10807@fedoraproject.org> References: <46C2CCDF.1020500@redhat.com> <46C2CCD5.10807@fedoraproject.org> Message-ID: <200708151807.30190@rineau.tsetse> On Wednesday 15 August 2007 11:52:21 Rahul Sundaram wrote: > If you are the sole copyright holder, you are free to relicense, but if > there are other contributors with copyrightable patches then they > would need to agree to relicense or you would need to rewrite inorder > for you to able to relicense. Maybe a stupid question: What are "copyrightable patches"? -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From rnorwood at redhat.com Wed Aug 15 16:10:46 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Wed, 15 Aug 2007 12:10:46 -0400 Subject: Zod -> Moonshine -> ? Moonshine is a , is a In-Reply-To: <46C09FAE.20909@redhat.com> (Christopher Aillon's message of "Mon, 13 Aug 2007 14:15:10 -0400") References: <20070813122455.724d7df4@weaponx.rchland.ibm.com> <46C09FAE.20909@redhat.com> Message-ID: Christopher Aillon writes: > Josh Boyer wrote: >> That's right... it's time to start naming the Fedora 8 release. Fill >> in your suggestion for the blanks. Remember the rules: >> 1) must have some link to Moonshine >> 2) The link between and Moonshine cannot be the same as between >> Zod and Moonshine > > > Moonshine typically hasn't been aged properly. > Traci... hmm, nevermind. On that note...how about 'jailbait'? -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From alan at redhat.com Wed Aug 15 16:17:36 2007 From: alan at redhat.com (Alan Cox) Date: Wed, 15 Aug 2007 12:17:36 -0400 Subject: Licence of upstream project In-Reply-To: <200708151807.30190@rineau.tsetse> References: <46C2CCDF.1020500@redhat.com> <46C2CCD5.10807@fedoraproject.org> <200708151807.30190@rineau.tsetse> Message-ID: <20070815161736.GA16836@devserv.devel.redhat.com> On Wed, Aug 15, 2007 at 06:07:29PM +0200, Laurent Rineau wrote: > > would need to agree to relicense or you would need to rewrite inorder > > for you to able to relicense. > > Maybe a stupid question: What are "copyrightable patches"? Ones that are sufficient to qualify for copyright protection. Not all changes are. From alan at redhat.com Wed Aug 15 17:03:48 2007 From: alan at redhat.com (Alan Cox) Date: Wed, 15 Aug 2007 13:03:48 -0400 Subject: Zod -> Moonshine -> ? Moonshine is a , is a In-Reply-To: <20070815014458.GC25120@charlescurley.com> References: <20070813122455.724d7df4@weaponx.rchland.ibm.com> <1187039977.28113.19.camel@tuxhugs> <20070815014458.GC25120@charlescurley.com> Message-ID: <20070815170348.GA19767@devserv.devel.redhat.com> On Tue, Aug 14, 2007 at 07:44:58PM -0600, Charles Curley wrote: > Are you suggesting that Fedora is bloatware? Or that things that go > into Fedora never come out again? Things that go into a singularity kind of come out again. Information which goes into a singularity is lost. Actually that sounds even worse 8) From mmaslano at redhat.com Wed Aug 15 17:09:53 2007 From: mmaslano at redhat.com (=?ISO-8859-2?Q?Marcela_Ma=B9l=E1=F2ov=E1?=) Date: Wed, 15 Aug 2007 19:09:53 +0200 Subject: Licence of upstream project In-Reply-To: <200708151807.30190@rineau.tsetse> References: <46C2CCDF.1020500@redhat.com> <46C2CCD5.10807@fedoraproject.org> <200708151807.30190@rineau.tsetse> Message-ID: <46C33361.6040100@redhat.com> Laurent Rineau wrote: > On Wednesday 15 August 2007 11:52:21 Rahul Sundaram wrote: > >> If you are the sole copyright holder, you are free to relicense, but if >> there are other contributors with copyrightable patches then they >> would need to agree to relicense or you would need to rewrite inorder >> for you to able to relicense. >> > > I'm the only contributor. > Maybe a stupid question: What are "copyrightable patches"? > > The copyrightable patches are these with license from http://fedoraproject.org/wiki/Licensing Then you have to add to License in spec file for example BSD and GPLv2. From stickster at gmail.com Wed Aug 15 19:37:50 2007 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 15 Aug 2007 15:37:50 -0400 Subject: Zod -> Moonshine -> ? Moonshine is a , is a In-Reply-To: <645d17210708131723s6b7c0f8ck928a3147c76e5d86@mail.gmail.com> References: <20070813122455.724d7df4@weaponx.rchland.ibm.com> <1187033029.4921.26.camel@localhost.localdomain> <645d17210708131723s6b7c0f8ck928a3147c76e5d86@mail.gmail.com> Message-ID: <1187206670.9928.47.camel@localhost.localdomain> On Tue, 2007-08-14 at 01:23 +0100, Jonathan Underwood wrote: > On 13/08/07, Jeremy Katz wrote: > > On Mon, 2007-08-13 at 12:24 -0500, Josh Boyer wrote: > > > That's right... it's time to start naming the Fedora 8 release. Fill > > > in your suggestion for the blanks. Remember the rules: > > > > > > 1) must have some link to Moonshine > > > > More specifically, the link should be > > Moonshine is a and > > NewName is a > > > > Where blank is the same for both > > How about Jaberwocky? > > "Moonshine" is a synonym for nonsense. > "Jaberwocky" is a synonym for nonsense. > > http://en.wikipedia.org/wiki/Nonsense > > [For example Eben Moglen's describing CEO's claims about the GPL as "moonshine"] +1, the best suggestion thus far. Plus this offers excellent ways out through association with Monty Python, poetry, and so forth: http://en.wikipedia.org/wiki/Jabberwocky_%28disambiguation%29 -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://fedoraproject.org/wiki/PaulWFrields irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Axel.Thimm at ATrpms.net Wed Aug 15 20:05:32 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 15 Aug 2007 22:05:32 +0200 Subject: Licence of upstream project In-Reply-To: <46C33361.6040100@redhat.com> References: <46C2CCDF.1020500@redhat.com> <46C2CCD5.10807@fedoraproject.org> <200708151807.30190@rineau.tsetse> <46C33361.6040100@redhat.com> Message-ID: <20070815200532.GB24027@puariko.nirvana> On Wed, Aug 15, 2007 at 11:52:31AM +0200, Marcela Ma?l??ov? wrote: > I started upstream of vixie-cron with license BSD (original), which > isn't GPLv2 compatible. Could I change the license or I have to > stay with BSD? On Wednesday 15 August 2007 11:52:21 Rahul Sundaram wrote: > If you are the sole copyright holder, you are free to relicense, but > if there are other contributors with copyrightable patches then they > would need to agree to relicense or you would need to rewrite > inorder for you to able to relicense. > I'm the only contributor. Only contributor of vixie-cron? Are you confusing package maintenance with upstream authoring? By definition of its name vixie-cron has Paul Vixie as a author, and the sources say: | Many people have contributed to cron. Many more than I can | remember, [many names mentioned] So if you want to change the license you will have to get the consent of all these people, you can't relicense just because you package it. But maybe I misunderstood what you meant with "I started upstream of vixie-cron". If you are rewriting this from scratch w/o using code from vixie-cron then you can license it however you like. But you should probably not call it vixie-cron. -- 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 jakub at redhat.com Wed Aug 15 23:45:31 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 15 Aug 2007 19:45:31 -0400 Subject: Licensing change: binutils GPLv2 -> GPLv3 Message-ID: <20070815234531.GU2063@devserv.devel.redhat.com> Hi! Upstream binutils switched to GPLv3+ already more than a month ago. While I guess I can delay switch to binutils-2.17.50.0.18 for a few days, I can't do that forever. Under GPLv3+ will be licensed both the programs (I don't imagine how that could be a problem) but also libfd and libopcodes. Checking current rawhide, following packages BuildRequire binutils-devel and therefore very likely link against libbfd or libopcodes. Can the maintainers check if their licensing isn't incompatible with GPLv3+ licensed libbfd.a resp. libopcodes.a? Thanks. alleyoop frysk gcl kdesdk lush oprofile pfmon sblim-wbemcli sysprof Jakub From SteveD at redhat.com Thu Aug 16 00:56:10 2007 From: SteveD at redhat.com (Steve Dickson) Date: Wed, 15 Aug 2007 20:56:10 -0400 Subject: The open() system call in f8 really broken... Message-ID: <46C3A0AA.7090106@RedHat.com> Can some please explain why my process dies with the following error: *** invalid open64 call: O_CREAT without mode ***: /home/src/fc/nfs-utils/devel/nfs-utils-1.1.0/utils/exportfs/exportfs terminated and the following change stops the error: - if ((fd = open(fname, readonly? O_RDONLY : (O_RDWR|O_CREAT))) < 0) { + if ((fd = (open)(fname, readonly? O_RDONLY : (O_RDWR|O_CREAT))) < 0) { xlog(L_WARNING, "could not open %s for locking", fname); return -1; } Which does not change the fact I'm using O_CREAT w/out a mode So what is the point of killing the process??? Now If I'm not mistaken, its been legal since the 70s to use O_CREAT without a mode because (depending on the OS) the mode of parent directory will be used (or something similar)... But the main point here is why are going to piss off the entire community by killing processes that have run for years and years because *we* decided to change the how the open system call is interrupted... If we want to strictly enforce the meaning of open() that is fine... fixing broken code is always a good thing... but don't kill process because of a misinterpretation that happen years ago... Give the developers a chance to fix the problem be throwing out a warning or something... but *don't* kill the process! What happens if /sbin/init has a bad open, we going to bring down a system out of principal? Please, for f8 give us a chance and change the kill to a warning... and I sure in the end, by f9 all of the developers (if we have any at that point) will be using the open() system call correctly... steved. From sgrubb at redhat.com Thu Aug 16 01:00:35 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Wed, 15 Aug 2007 21:00:35 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <46C3A0AA.7090106@RedHat.com> References: <46C3A0AA.7090106@RedHat.com> Message-ID: <200708152100.35912.sgrubb@redhat.com> On Wednesday 15 August 2007 20:56:10 Steve Dickson wrote: > Now If I'm not mistaken, its been legal since the 70s to use > O_CREAT without a mode because (depending on the OS) the mode > of parent directory will be used (or something similar)... The problem is that without a mode being passed, the kernel uses whatever the stack contents are. And yes, its conceivable the stack contents could create a world writable setuid file which cannot ever be the intended operation. -Steve From pertusus at free.fr Thu Aug 16 00:57:36 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 16 Aug 2007 02:57:36 +0200 Subject: lesstif API change Message-ID: <20070816005736.GA2995@free.fr> Hello, To conform better to openmotif API, the structures MotifWmHints, MwmHints PropMotifWmHints have been changed, with a change that only shows on 64 bit platforms. It could be needed to rebuild the lesstif dependent packages to verify that they still build and don't use that API, or check that they don't use that structure. It is possible that the ABI break requires a rebuild even if this API isn't used. I guess that packages that break with the new API will show up in Matt rebuilds. The soname won't change so it is important to verify that the applications still build with the new API and is still ABI compatible. -- Pat From ivazqueznet at gmail.com Thu Aug 16 01:13:36 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Wed, 15 Aug 2007 21:13:36 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <200708152100.35912.sgrubb@redhat.com> References: <46C3A0AA.7090106@RedHat.com> <200708152100.35912.sgrubb@redhat.com> Message-ID: <1187226816.11280.20.camel@ignacio.lan> On Wed, 2007-08-15 at 21:00 -0400, Steve Grubb wrote: > On Wednesday 15 August 2007 20:56:10 Steve Dickson wrote: > > Now If I'm not mistaken, its been legal since the 70s to use > > O_CREAT without a mode because (depending on the OS) the mode > > of parent directory will be used (or something similar)... > > The problem is that without a mode being passed, the kernel uses whatever the > stack contents are. And yes, its conceivable the stack contents could create > a world writable setuid file which cannot ever be the intended operation. So then why not default to a mode of 0 instead, which will do the equivalent of bolting a big, flashing "BROKEN" sign to the app? -- Ignacio Vazquez-Abrams -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From SteveD at redhat.com Thu Aug 16 01:19:00 2007 From: SteveD at redhat.com (Steve Dickson) Date: Wed, 15 Aug 2007 21:19:00 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <200708152100.35912.sgrubb@redhat.com> References: <46C3A0AA.7090106@RedHat.com> <200708152100.35912.sgrubb@redhat.com> Message-ID: <46C3A604.3080002@RedHat.com> Steve Grubb wrote: > On Wednesday 15 August 2007 20:56:10 Steve Dickson wrote: >> Now If I'm not mistaken, its been legal since the 70s to use >> O_CREAT without a mode because (depending on the OS) the mode >> of parent directory will be used (or something similar)... > > The problem is that without a mode being passed, the kernel uses whatever the > stack contents are. well the man pages does something about using "the mode of the parent directory", but all implantations are different... > And yes, its conceivable the stack contents could create > a world writable setuid file which cannot ever be the intended operation. The key word being "conceivable"... a hole that size would have been found a long time ago... and because of these new constraints a hole of this type not happen, which is a good thing... but just because some this is conceivable does not justify killing processes... exportfs does not write setuid files, but it can cause a lost of thousand of dollars when a entire development department is idle because they can't log in because we decided to change the meaning of open()... it just does not make sense to me... Again, creating good program habits is a good thing, but at what cost? steved. From sgrubb at redhat.com Thu Aug 16 01:22:17 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Wed, 15 Aug 2007 21:22:17 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <1187226816.11280.20.camel@ignacio.lan> References: <46C3A0AA.7090106@RedHat.com> <200708152100.35912.sgrubb@redhat.com> <1187226816.11280.20.camel@ignacio.lan> Message-ID: <200708152122.18771.sgrubb@redhat.com> On Wednesday 15 August 2007 21:13:36 Ignacio Vazquez-Abrams wrote: > On Wed, 2007-08-15 at 21:00 -0400, Steve Grubb wrote: > > On Wednesday 15 August 2007 20:56:10 Steve Dickson wrote: > > > Now If I'm not mistaken, its been legal since the 70s to use > > > O_CREAT without a mode because (depending on the OS) the mode > > > of parent directory will be used (or something similar)... > > > > The problem is that without a mode being passed, the kernel uses whatever > > the stack contents are. And yes, its conceivable the stack contents could > > create a world writable setuid file which cannot ever be the intended > > operation. > > So then why not default to a mode of 0 instead, which will do the > equivalent of bolting a big, flashing "BROKEN" sign to the app? Cause then I think you get another error away from the actual error and windup troubleshooting the wrong problem. This *is* a big flashing "BROKEN" sign at the right point in the software to tell you what really went wrong. -Steve From sgrubb at redhat.com Thu Aug 16 01:25:52 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Wed, 15 Aug 2007 21:25:52 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <46C3A604.3080002@RedHat.com> References: <46C3A0AA.7090106@RedHat.com> <200708152100.35912.sgrubb@redhat.com> <46C3A604.3080002@RedHat.com> Message-ID: <200708152125.53738.sgrubb@redhat.com> On Wednesday 15 August 2007 21:19:00 Steve Dickson wrote: > > And yes, its conceivable the stack contents could create > > a world writable setuid file which cannot ever be the intended operation. > > The key word being "conceivable"... a hole that size would have been > found a long time ago... This did in-fact happen in the wild and that's why its fixed this way. Its a serious problem and it should be treated that way. -Steve From sandeen at redhat.com Thu Aug 16 01:27:10 2007 From: sandeen at redhat.com (Eric Sandeen) Date: Wed, 15 Aug 2007 20:27:10 -0500 Subject: The open() system call in f8 really broken... In-Reply-To: <46C3A604.3080002@RedHat.com> References: <46C3A0AA.7090106@RedHat.com> <200708152100.35912.sgrubb@redhat.com> <46C3A604.3080002@RedHat.com> Message-ID: <46C3A7EE.2080405@redhat.com> Steve Dickson wrote: > Steve Grubb wrote: >> On Wednesday 15 August 2007 20:56:10 Steve Dickson wrote: >>> Now If I'm not mistaken, its been legal since the 70s to use >>> O_CREAT without a mode because (depending on the OS) the mode >>> of parent directory will be used (or something similar)... >> The problem is that without a mode being passed, the kernel uses whatever the >> stack contents are. > well the man pages does something about using "the mode of the parent > directory", but all implantations are different... hmm isn't that talking about what the group defaults to? It also says: mode must be specified when O_CREAT is in the flags, and is ignored otherwise. Hard to argue with the "must" >> And yes, its conceivable the stack contents could create >> a world writable setuid file which cannot ever be the intended operation. > The key word being "conceivable"... a hole that size would have been > found a long time ago... and because of these new constraints a > hole of this type not happen, which is a good thing... but just because > some this is conceivable does not justify killing processes... > > exportfs does not write setuid files, but it can cause a lost > of thousand of dollars when a entire development department > is idle because they can't log in because we decided to change > the meaning of open()... it just does not make sense to me... > > Again, creating good program habits is a good thing, but at > what cost? Is there an explicit security risk to exposing the stack via the uninitialized mode, in this way? [esandeen at neon tmp]$ while true; do rm -f testfile; ./test testfile; ls -l testfile; done --wSrwx--- 1 esandeen esandeen 0 Aug 15 20:21 testfile ---s--s--- 1 esandeen esandeen 0 Aug 15 20:21 testfile --wxr-x--- 1 esandeen esandeen 0 Aug 15 20:21 testfile -r--rws--T 1 esandeen esandeen 0 Aug 15 20:21 testfile -r-s--x--- 1 esandeen esandeen 0 Aug 15 20:21 testfile -r-S--x--- 1 esandeen esandeen 0 Aug 15 20:21 testfile -rws-ws--T 1 esandeen esandeen 0 Aug 15 20:21 testfile .... -Eric From SteveD at redhat.com Thu Aug 16 01:49:08 2007 From: SteveD at redhat.com (Steve Dickson) Date: Wed, 15 Aug 2007 21:49:08 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <200708152125.53738.sgrubb@redhat.com> References: <46C3A0AA.7090106@RedHat.com> <200708152100.35912.sgrubb@redhat.com> <46C3A604.3080002@RedHat.com> <200708152125.53738.sgrubb@redhat.com> Message-ID: <46C3AD14.80909@RedHat.com> Steve Grubb wrote: > On Wednesday 15 August 2007 21:19:00 Steve Dickson wrote: >>> And yes, its conceivable the stack contents could create >>> a world writable setuid file which cannot ever be the intended operation. >> The key word being "conceivable"... a hole that size would have been >> found a long time ago... > > This did in-fact happen in the wild and that's why its fixed this way. Its a > serious problem and it should be treated that way. I'm not say is a problem that shouldn't be fixed... but I'm arguing that killing process is not the appropriate way to deal with it... at least right away.. make it a warning, which give developers a chance to fix the problem and then, in the next OS release take a stronger stance... steved. From SteveD at redhat.com Thu Aug 16 02:10:15 2007 From: SteveD at redhat.com (Steve Dickson) Date: Wed, 15 Aug 2007 22:10:15 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <46C3A7EE.2080405@redhat.com> References: <46C3A0AA.7090106@RedHat.com> <200708152100.35912.sgrubb@redhat.com> <46C3A604.3080002@RedHat.com> <46C3A7EE.2080405@redhat.com> Message-ID: <46C3B207.9070206@RedHat.com> Eric Sandeen wrote: > It also says: > > mode must be specified when O_CREAT is in the flags, and is > ignored otherwise. > > Hard to argue with the "must" point... I did miss this in the man page. Thank you for pointing this out... >>> And yes, its conceivable the stack contents could create >>> a world writable setuid file which cannot ever be the intended operation. >> The key word being "conceivable"... a hole that size would have been >> found a long time ago... and because of these new constraints a >> hole of this type not happen, which is a good thing... but just because >> some this is conceivable does not justify killing processes... >> >> exportfs does not write setuid files, but it can cause a lost >> of thousand of dollars when a entire development department >> is idle because they can't log in because we decided to change >> the meaning of open()... it just does not make sense to me... >> >> Again, creating good program habits is a good thing, but at >> what cost? > > Is there an explicit security risk to exposing the stack via the > uninitialized mode, in this way? Yes.. I totally agree with (and understand) the security risk of using uninitialized stack data... its wrong! But the question is how we deal with it and how we give our development community a chance to deal with it. Coming out with an OS that blindly kills processes is just not the way to handle it... imho... Make it a warning so developers have a chance to fix it and then take stronger measures in a later release would be a better way to handle this... again imho... steved. From ivazqueznet at gmail.com Thu Aug 16 02:36:21 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Wed, 15 Aug 2007 22:36:21 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <200708152122.18771.sgrubb@redhat.com> References: <46C3A0AA.7090106@RedHat.com> <200708152100.35912.sgrubb@redhat.com> <1187226816.11280.20.camel@ignacio.lan> <200708152122.18771.sgrubb@redhat.com> Message-ID: <1187231781.11280.23.camel@ignacio.lan> On Wed, 2007-08-15 at 21:22 -0400, Steve Grubb wrote: > On Wednesday 15 August 2007 21:13:36 Ignacio Vazquez-Abrams wrote: > > On Wed, 2007-08-15 at 21:00 -0400, Steve Grubb wrote: > > > On Wednesday 15 August 2007 20:56:10 Steve Dickson wrote: > > > > Now If I'm not mistaken, its been legal since the 70s to use > > > > O_CREAT without a mode because (depending on the OS) the mode > > > > of parent directory will be used (or something similar)... > > > > > > The problem is that without a mode being passed, the kernel uses whatever > > > the stack contents are. And yes, its conceivable the stack contents could > > > create a world writable setuid file which cannot ever be the intended > > > operation. > > > > So then why not default to a mode of 0 instead, which will do the > > equivalent of bolting a big, flashing "BROKEN" sign to the app? > > Cause then I think you get another error away from the actual error and windup > troubleshooting the wrong problem. This *is* a big flashing "BROKEN" sign at > the right point in the software to tell you what really went wrong. I also find it difficult to understand why forcing code to use (foo->open)() is a good idea. I understand that's a side effect of C's, uh... "legacy", but it still bites. -- Ignacio Vazquez-Abrams -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Thu Aug 16 02:49:40 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 15 Aug 2007 22:49:40 -0400 Subject: Licensing change: binutils GPLv2 -> GPLv3 In-Reply-To: <20070815234531.GU2063@devserv.devel.redhat.com> References: <20070815234531.GU2063@devserv.devel.redhat.com> Message-ID: <1187232580.3439.75.camel@dhcp83-165.boston.redhat.com> On Wed, 2007-08-15 at 19:45 -0400, Jakub Jelinek wrote: > Hi! > > Upstream binutils switched to GPLv3+ already more than a month ago. > While I guess I can delay switch to binutils-2.17.50.0.18 for a few > days, I can't do that forever. > > Under GPLv3+ will be licensed both the programs (I don't imagine > how that could be a problem) but also libfd and libopcodes. > Checking current rawhide, following packages BuildRequire > binutils-devel and therefore very likely link against libbfd > or libopcodes. Can the maintainers check if their licensing > isn't incompatible with GPLv3+ licensed libbfd.a resp. libopcodes.a? > > Thanks. > > alleyoop GPLv2+ (no problem, although, the spec License tag is WRONG!) > frysk GPLv2 with exception This is almost certainly a problem. Looks to be linking against libopcodes.a. (also, the spec License tag is WRONG!) > gcl GPL+ and LGPLv2+ (no problem, but again, the spec License tag is WRONG!) > kdesdk GPLv2+ with exception (i'm sounding like a broken record here, but no problem, except for the spec license tag being WRONG!) > lush GPLv2+ (once more, no problem, spec License tag is WRONG!) > oprofile GPLv2+ (no problem, spec License tag is WRONG!) > pfmon GPLv2+ (no problem, spec License tag is WRONG!) > sblim-wbemcli CPL. Well, if we were linking to this, it might be a problem (CPL is GPL incompatible), but its only using some very basic header information from binutils-devel, and no linking to it, so its fine. > sysprof GPLv2+ (no problem, spec License tag is WRONG!) *sigh* Only one of these packages had a valid License tag in the spec file. ~spot From tcallawa at redhat.com Thu Aug 16 03:01:35 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 15 Aug 2007 23:01:35 -0400 Subject: GPL and LGPL not acceptable for Fedora! Message-ID: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> Got your attention? Good. GPL and LGPL are NOT acceptable License tags for Fedora. You cannot simply use "GPL" or "LGPL" as a license tag anymore. You have to use one of the following tags: GPL+, GPLv2, GPLv2+, GPLv3, GPLv3+, LGPLv2, LGPLv2+, LGPLv3, LGPLv3+ GPL+: If there is no version specified anywhere, and it only says GPL, then it is GPL+. It is also GPL+ if the code is licensed as "GPL version 1 or later". GPLv2: If the code only says "version 2 of the License." and does NOT say "or later version", then it is GPLv2 only. GPLv2+: If the code is GPL v2 and it says "either version 2 of the License, or (at your option) any later version.", then it is GPLv2 or later. GPLv3: Same as GPLv2 only, except, GPLv3 only. GPLv3+: Same as GPLv2 or later, except GPLv3 or later. LGPLv2+: If there is no version specified anywhere, and it only says LGPL, then it is LGPLv2+. Also, use this tag if it is LGPL v2 (or 2.1) and it says "or (at your option) any later version." in the code. LGPLv2: If the code only says "version 2 (or 2.1) of the License." and does NOT say "or later version", then it is LGPLv2 only. LGPLv3: Same as LGPLv2 only, except LGPLv3 only. LGPLv3+: Same as LGPLv2 or later, except LGPLv3 or later. NOTE: Don't trust COPYING. Look at the source code itself. Please, please, please do this. Take a minute and go through your packages and correct the specs so that they are using the new License tagging schema. Thanks in advance, ~spot From sandeen at redhat.com Thu Aug 16 04:01:37 2007 From: sandeen at redhat.com (Eric Sandeen) Date: Wed, 15 Aug 2007 23:01:37 -0500 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> Message-ID: <46C3CC21.80908@redhat.com> Tom "spot" Callaway wrote: > NOTE: Don't trust COPYING. Look at the source code itself. So, I own xfsprogs. source code itself only says things like: * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License as * published by the Free Software Foundation. but then the included COPYING file says: The library named "libhandle" and some specific header files (including ) are licensed under the GNU Lesser General Public License. All other components are licensed under the GNU General Public License. ... and then COPYING includes the text of LGPL2.1 and GPL2, specifically. I'll ask sgi for clarification but in the months while their lawyers go read the GPLv3, does it look like it would be appropriate to assume GPLv2 and LGPLv2 for now, based on the included COPYING file? (oh - and can my package be both GPLv2 and LGPLv2, or do I need to tease this apart into 2 packages now...) Thanks, -Eric From skvidal at fedoraproject.org Thu Aug 16 04:01:55 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 16 Aug 2007 00:01:55 -0400 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> Message-ID: <1187236915.13822.196.camel@cutter> On Wed, 2007-08-15 at 23:01 -0400, Tom "spot" Callaway wrote: > Got your attention? Good. > > GPL and LGPL are NOT acceptable License tags for Fedora. You cannot > simply use "GPL" or "LGPL" as a license tag anymore. > > You have to use one of the following tags: > > GPL+, GPLv2, GPLv2+, GPLv3, GPLv3+, LGPLv2, LGPLv2+, LGPLv3, LGPLv3+ > seahorse contains both GPLv2+ and LGPLv2+ components should I have it labeled as both? thanks, -sv From tibbs at math.uh.edu Thu Aug 16 04:22:30 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 15 Aug 2007 23:22:30 -0500 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <1187236915.13822.196.camel@cutter> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <1187236915.13822.196.camel@cutter> Message-ID: >>>>> "sv" == seth vidal writes: sv> seahorse contains both GPLv2+ and LGPLv2+ components sv> should I have it labeled as both? Yes, see "Multiple Licensing Scenarios" in http://fedoraproject.org/wiki/Packaging/LicensingGuidelines - J< From j.w.r.degoede at hhs.nl Thu Aug 16 04:57:16 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 16 Aug 2007 06:57:16 +0200 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <46C3CC21.80908@redhat.com> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <46C3CC21.80908@redhat.com> Message-ID: <46C3D92C.1050601@hhs.nl> Eric Sandeen wrote: > Tom "spot" Callaway wrote: > >> NOTE: Don't trust COPYING. Look at the source code itself. > > So, I own xfsprogs. > > source code itself only says things like: > > * This program is free software; you can redistribute it and/or > * modify it under the terms of the GNU General Public License as > * published by the Free Software Foundation. > > but then the included COPYING file says: > > The library named "libhandle" and some specific header files (including > ) are licensed under the GNU Lesser General Public License. > > All other components are licensed under the GNU General Public License. > > ... and then COPYING includes the text of LGPL2.1 and GPL2, specifically. > > I'll ask sgi for clarification but in the months while their lawyers go > read the GPLv3, does it look like it would be appropriate to assume > GPLv2 and LGPLv2 for now, based on the included COPYING file? > > (oh - and can my package be both GPLv2 and LGPLv2, or do I need to tease > this apart into 2 packages now...) > The version of the COPYING[.lib] file is not relevant if the sourcecoe doesn't contain a version its GPL+ resp. LGPLv2+ About GPL and LGPL. If libhandle is distributed as a seperate file under /usr/lib, then the license tag would be: License: GPL+ and LGPLv2+ If libhandle is statically linked into the binaries and not distributed seperately in /usr/lib, then the GPL trums the LGPL and the license tag becomes: License: GPLv2+ (The v2 comes from the LGPL code incorperated into the binaries) If you distribute the lib under /usr/lib, you may want todo a -libs subpackage for that and use "License: GPL+" for the main package and "License: LGPLv2+" for the -libss and -devel sub-packages. The idea behind this tags is that interpackage licensing issues can be checked by a script, using: License: GPL+ and LGPLv2+ Is not going to help this script, resulting in people still needing to check things manually. Regards, Hans (Who has 2 packages of his 150 left todo and then the License tagging operation is completed for me). From tmz at pobox.com Thu Aug 16 04:59:58 2007 From: tmz at pobox.com (Todd Zullinger) Date: Thu, 16 Aug 2007 00:59:58 -0400 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> Message-ID: <20070816045958.GL29583@psilocybe.teonanacatl.org> Tom spot Callaway wrote: > Please, please, please do this. Take a minute and go through your > packages and correct the specs so that they are using the new > License tagging schema. FWIW, in the few weeks since the new guidelines were announced, ~1269 spec files have been updated. As of 2007-08-16 04:30 UTC, in the devel branch: 72.81% of spec files (3392 out of 4659) have invalid licenses -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In my life, I have prayed but one prayer: oh Lord, make my enemies ridiculous. And God granted it. -- Voltaire -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Thu Aug 16 05:02:56 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 16 Aug 2007 07:02:56 +0200 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <1187236915.13822.196.camel@cutter> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <1187236915.13822.196.camel@cutter> Message-ID: <46C3DA80.1040706@hhs.nl> seth vidal wrote: > On Wed, 2007-08-15 at 23:01 -0400, Tom "spot" Callaway wrote: >> Got your attention? Good. >> >> GPL and LGPL are NOT acceptable License tags for Fedora. You cannot >> simply use "GPL" or "LGPL" as a license tag anymore. >> >> You have to use one of the following tags: >> >> GPL+, GPLv2, GPLv2+, GPLv3, GPLv3+, LGPLv2, LGPLv2+, LGPLv3, LGPLv3+ >> > > seahorse contains both GPLv2+ and LGPLv2+ components > > should I have it labeled as both? > That depends, do any of the build binaries contain only LGPLv2+ parts? If not, then the GPL trumps the LGPL and the license tag should be just: License: GPLv2+ If there are binaries which are build from LGPL code only, and these are in the same rpm, then it would be: License: GPLv2+ and LGPLv2+ However, assuming that the LGPL licensed stuff is a lib, which not only gets used during building, but also installed under /usr/lib[64], then please concider doing a -libs subpackage and use "License: GPL+" for the main package and "License: LGPLv2+" for the -libss and -devel sub-packages. The idea behind this tags is that interpackage licensing issues can be checked by a script, using: License: GPLv2+ and LGPLv2+ Is not going to help this script, resulting in people still needing to check things manually. Regards, Hans (Who has 2 packages of his 150 left todo and then the License tagging operation is completed for me). From esandeen at redhat.com Thu Aug 16 05:11:20 2007 From: esandeen at redhat.com (Eric Sandeen) Date: Thu, 16 Aug 2007 00:11:20 -0500 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <46C3D92C.1050601@hhs.nl> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <46C3CC21.80908@redhat.com> <46C3D92C.1050601@hhs.nl> Message-ID: <46C3DC78.8030502@redhat.com> Hans de Goede wrote: > The version of the COPYING[.lib] file is not relevant if the sourcecoe doesn't > contain a version its GPL+ resp. LGPLv2+ So if sourcecode doesn't mention a version but COPYING does, it's still interpreted as "or any later version?" Hm... that strikes me as odd. > About GPL and LGPL. If libhandle is distributed as a seperate file under > /usr/lib, then the license tag would be: > > License: GPL+ and LGPLv2+ Yup that's it... I guess I'll look into making a -libs package in my spare time. :) Thanks, -Eric From j.w.r.degoede at hhs.nl Thu Aug 16 05:10:18 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 16 Aug 2007 07:10:18 +0200 Subject: Licensing change: binutils GPLv2 -> GPLv3 In-Reply-To: <1187232580.3439.75.camel@dhcp83-165.boston.redhat.com> References: <20070815234531.GU2063@devserv.devel.redhat.com> <1187232580.3439.75.camel@dhcp83-165.boston.redhat.com> Message-ID: <46C3DC3A.8050603@hhs.nl> Tom "spot" Callaway wrote: > On Wed, 2007-08-15 at 19:45 -0400, Jakub Jelinek wrote: >> Hi! >> >> Upstream binutils switched to GPLv3+ already more than a month ago. >> While I guess I can delay switch to binutils-2.17.50.0.18 for a few >> days, I can't do that forever. >> >> Under GPLv3+ will be licensed both the programs (I don't imagine >> how that could be a problem) but also libfd and libopcodes. >> Checking current rawhide, following packages BuildRequire >> binutils-devel and therefore very likely link against libbfd >> or libopcodes. Can the maintainers check if their licensing >> isn't incompatible with GPLv3+ licensed libbfd.a resp. libopcodes.a? >> >> Thanks. >> > >> frysk > > GPLv2 with exception > > This is almost certainly a problem. Looks to be linking against > libopcodes.a. > Has anyone tried contacting upstream? I've contacted upstream for all my GPLv2 (only) packages and sofar all who have replied have promised me that the next version will be either GPLv2+ or "GPLv2 and GPLv3" (luckily they were all pretty much one man projects, so upstream has the power to do this). One upstream has even done a new release with just the copyrightheaders changed esp. for this. Sometimes it takes some explaining why GPLv2 only is going to be a problem once glibc hits LGPLv3, but usually upstreams are very willing to help in my experience. The only problematic packages I currently have are goffice and gnumeric (gnome really should have kept a better watch there GRRR). Regards, Hans From wart at kobold.org Thu Aug 16 05:12:05 2007 From: wart at kobold.org (Wart) Date: Wed, 15 Aug 2007 22:12:05 -0700 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> Message-ID: <46C3DCA5.9080909@kobold.org> Tom "spot" Callaway wrote: > Got your attention? Good. > > GPL and LGPL are NOT acceptable License tags for Fedora. You cannot > simply use "GPL" or "LGPL" as a license tag anymore. > > You have to use one of the following tags: > > GPL+, GPLv2, GPLv2+, GPLv3, GPLv3+, LGPLv2, LGPLv2+, LGPLv3, LGPLv3+ > > GPL+: If there is no version specified anywhere, and it only says GPL, > then it is GPL+. It is also GPL+ if the code is licensed as "GPL version > 1 or later". > > GPLv2: If the code only says "version 2 of the License." and does NOT > say "or later version", then it is GPLv2 only. > [...] > > NOTE: Don't trust COPYING. Look at the source code itself. I've got ~40 packages to go through, so this may take a while. Any offers of help are appreciated. abe contains only a COPYING file that says 'Version 2', and no copyright or license info in the source files themselves. In the absence of anything in the source files, does this qualify abe for 'GPL+' or 'GPLv2'? --Wart From j.w.r.degoede at hhs.nl Thu Aug 16 05:23:23 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 16 Aug 2007 07:23:23 +0200 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <46C3DCA5.9080909@kobold.org> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <46C3DCA5.9080909@kobold.org> Message-ID: <46C3DF4B.9040105@hhs.nl> Wart wrote: > Tom "spot" Callaway wrote: >> Got your attention? Good. >> >> GPL and LGPL are NOT acceptable License tags for Fedora. You cannot >> simply use "GPL" or "LGPL" as a license tag anymore. >> >> You have to use one of the following tags: >> >> GPL+, GPLv2, GPLv2+, GPLv3, GPLv3+, LGPLv2, LGPLv2+, LGPLv3, LGPLv3+ >> >> GPL+: If there is no version specified anywhere, and it only says GPL, >> then it is GPL+. It is also GPL+ if the code is licensed as "GPL version >> 1 or later". >> >> GPLv2: If the code only says "version 2 of the License." and does NOT >> say "or later version", then it is GPLv2 only. >> > [...] >> >> NOTE: Don't trust COPYING. Look at the source code itself. > > I've got ~40 packages to go through, so this may take a while. Any > offers of help are appreciated. > Heh, sorry I'm about to finish doing my 149th and 150th package today (after days of working on this), and I really do _not_ feel like doing any more license reviews. I'm happy to answer any questions though. > abe contains only a COPYING file that says 'Version 2', and no copyright > or license info in the source files themselves. In the absence of > anything in the source files, does this qualify abe for 'GPL+' or 'GPLv2'? > GPL+, the version in the COPYING file is irrelevant. Regards, Hans From lightsolphoenix at gmail.com Thu Aug 16 05:27:31 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Thu, 16 Aug 2007 01:27:31 -0400 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <46C3DC78.8030502@redhat.com> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <46C3D92C.1050601@hhs.nl> <46C3DC78.8030502@redhat.com> Message-ID: <200708160127.32860.lightsolphoenix@gmail.com> On Thursday, August 16, 2007 1:11:20 am Eric Sandeen wrote: > So if sourcecode doesn't mention a version but COPYING does, it's still > interpreted as "or any later version?" Hm... that strikes me as odd. I BELIEVE what they're trying to say is that if both the source and COPYING contain different licence numbers, the source trumps the COPYING file. Most of the time, the COPYING file is simply the GPL/LGPL copied verbatim from the FSF site. As a result, I can understand why they would say look at the source code. However, I'd suspect in that case, the stuff in the COPYING is what counts. I BELIEVE that the point of the "check the source" rule is to avoid situations where the COPYING file conflicts with the source itself. -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From jgranado at redhat.com Thu Aug 16 09:10:45 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Thu, 16 Aug 2007 11:10:45 +0200 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> Message-ID: <46C41495.6000809@redhat.com> > NOTE: Don't trust COPYING. Look at the source code itself. > > Please, please, please do this. Take a minute and go through your > packages and correct the specs so that they are using the new License > tagging schema. > > Thanks in advance, > > ~spot > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > Just to be clear, process here is: 1. go through the packages in FC-5, FC-6, FC-7 and devel, correct as indicated. 2. build if changed. right? -- Joel Andres Granados From wolters.liste at gmx.net Thu Aug 16 09:28:14 2007 From: wolters.liste at gmx.net (Roland Wolters) Date: Thu, 16 Aug 2007 11:28:14 +0200 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> Message-ID: <200708161128.19636.wolters.liste@gmx.net> Once upon a time Tom "spot" Callaway wrote: > Got your attention? Good. > > GPL and LGPL are NOT acceptable License tags for Fedora. You cannot > simply use "GPL" or "LGPL" as a license tag anymore. > [...] > NOTE: Don't trust COPYING. Look at the source code itself. > So now I have "either version 2 of the License, or (at your option) any later version" in my source files. Should be clear GPLv2+ you might guess. However, KDE and of course Qt are clearly GPLv2 only. So what should I add now in the licecen tag? Roland -- "Nein danke, dieses Auto ist eine Fehlkonstruktion." -- Henry Ford II, als ihm nach Kriegsende das Volkswagenwerk zur kostenlosen ?bernahme angeboten wurde, 1945 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From alan at redhat.com Thu Aug 16 09:37:21 2007 From: alan at redhat.com (Alan Cox) Date: Thu, 16 Aug 2007 05:37:21 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <46C3A0AA.7090106@RedHat.com> References: <46C3A0AA.7090106@RedHat.com> Message-ID: <20070816093721.GA2070@devserv.devel.redhat.com> On Wed, Aug 15, 2007 at 08:56:10PM -0400, Steve Dickson wrote: > Which does not change the fact I'm using O_CREAT w/out a mode > So what is the point of killing the process??? Its explicitly permitted, as is opening for write while setting read only permission and other vairants. Any change to that would be a bug From bugs.michael at gmx.net Thu Aug 16 09:31:30 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 16 Aug 2007 11:31:30 +0200 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <46C41495.6000809@redhat.com> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <46C41495.6000809@redhat.com> Message-ID: <20070816113130.90abcbe3.bugs.michael@gmx.net> On Thu, 16 Aug 2007 11:10:45 +0200, Joel Andres Granados wrote: > > > NOTE: Don't trust COPYING. Look at the source code itself. > > > > Please, please, please do this. Take a minute and go through your > > packages and correct the specs so that they are using the new License > > tagging schema. > > > > Thanks in advance, > > > > ~spot > Just to be clear, process here is: > 1. go through the packages in FC-5, FC-6, FC-7 and devel, correct as > indicated. > 2. build if changed. > > right? Not right. FC-5 has reached end-of-life long ago, so save yourself the commits to a dead branch. And don't rebuild packages outside "devel" just for these licence clarifications. In the non-"devel" branches, feel free to commit the spec changes, but don't rebuild. From alan at redhat.com Thu Aug 16 09:39:59 2007 From: alan at redhat.com (Alan Cox) Date: Thu, 16 Aug 2007 05:39:59 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <46C3A0AA.7090106@RedHat.com> References: <46C3A0AA.7090106@RedHat.com> Message-ID: <20070816093959.GB2070@devserv.devel.redhat.com> On Wed, Aug 15, 2007 at 08:56:10PM -0400, Steve Dickson wrote: > and the following change stops the error: > > - if ((fd = open(fname, readonly? O_RDONLY : (O_RDWR|O_CREAT))) < 0) { > + if ((fd = (open)(fname, readonly? O_RDONLY : (O_RDWR|O_CREAT))) < 0) { > xlog(L_WARNING, "could not open %s for locking", fname); > return -1; > } > > Which does not change the fact I'm using O_CREAT w/out a mode > So what is the point of killing the process??? > > Now If I'm not mistaken, its been legal since the 70s to use > O_CREAT without a mode because (depending on the OS) the mode > of parent directory will be used (or something similar)... Sorry ignore the previous email I misunderstood what was going on. You can open a file O_CREAT with neither read or write, you can open a file with O_CREAT|O_WRONLY but not give permissions in the file mode. You must provide the third argument so the abort is right. If you don't then the permissions are set based on the random values (eg the return address) From alan at redhat.com Thu Aug 16 09:45:21 2007 From: alan at redhat.com (Alan Cox) Date: Thu, 16 Aug 2007 05:45:21 -0400 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <200708160127.32860.lightsolphoenix@gmail.com> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <46C3D92C.1050601@hhs.nl> <46C3DC78.8030502@redhat.com> <200708160127.32860.lightsolphoenix@gmail.com> Message-ID: <20070816094521.GC2070@devserv.devel.redhat.com> On Thu, Aug 16, 2007 at 01:27:31AM -0400, Kelly wrote: > On Thursday, August 16, 2007 1:11:20 am Eric Sandeen wrote: > > So if sourcecode doesn't mention a version but COPYING does, it's still > > interpreted as "or any later version?" Hm... that strikes me as odd. > > I BELIEVE what they're trying to say is that if both the source and COPYING > contain different licence numbers, the source trumps the COPYING file. Take the most restrictive in tht case I think ? From ville.skytta at iki.fi Thu Aug 16 10:03:00 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Thu, 16 Aug 2007 13:03:00 +0300 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <200708161128.19636.wolters.liste@gmx.net> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <200708161128.19636.wolters.liste@gmx.net> Message-ID: <200708161303.02241.ville.skytta@iki.fi> On Thursday 16 August 2007, Roland Wolters wrote: > Once upon a time Tom "spot" Callaway wrote: > > Got your attention? Good. > > > > GPL and LGPL are NOT acceptable License tags for Fedora. You cannot > > simply use "GPL" or "LGPL" as a license tag anymore. > > [...] > > NOTE: Don't trust COPYING. Look at the source code itself. > > So now I have "either version 2 of the License, or (at your option) any > later version" in my source files. Should be clear GPLv2+ you might guess. > However, KDE and of course Qt are clearly GPLv2 only. > > So what should I add now in the licecen tag? GPLv2+, I think. See http://fedoraproject.org/wiki/PackagingDrafts/LicenseClarification From ssorce at redhat.com Thu Aug 16 12:18:50 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 16 Aug 2007 08:18:50 -0400 Subject: Licensing change: binutils GPLv2 -> GPLv3 In-Reply-To: <1187232580.3439.75.camel@dhcp83-165.boston.redhat.com> References: <20070815234531.GU2063@devserv.devel.redhat.com> <1187232580.3439.75.camel@dhcp83-165.boston.redhat.com> Message-ID: <1187266730.27768.9.camel@localhost.localdomain> On Wed, 2007-08-15 at 22:49 -0400, Tom "spot" Callaway wrote: > > kdesdk > > GPLv2+ with exception (i'm sounding like a broken record here, but no > problem, except for the spec license tag being WRONG!) IANAL but if the code it links to does not have the same exception they are probably incompatible as you end up link GPLv2 w/o exception with the exception code. Simo. From ssorce at redhat.com Thu Aug 16 12:30:02 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 16 Aug 2007 08:30:02 -0400 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <46C3DF4B.9040105@hhs.nl> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <46C3DCA5.9080909@kobold.org> <46C3DF4B.9040105@hhs.nl> Message-ID: <1187267402.27768.13.camel@localhost.localdomain> On Thu, 2007-08-16 at 07:23 +0200, Hans de Goede wrote: > Wart wrote: > > Tom "spot" Callaway wrote: > >> Got your attention? Good. > >> > >> GPL and LGPL are NOT acceptable License tags for Fedora. You cannot > >> simply use "GPL" or "LGPL" as a license tag anymore. > >> > >> You have to use one of the following tags: > >> > >> GPL+, GPLv2, GPLv2+, GPLv3, GPLv3+, LGPLv2, LGPLv2+, LGPLv3, LGPLv3+ > >> > >> GPL+: If there is no version specified anywhere, and it only says GPL, > >> then it is GPL+. It is also GPL+ if the code is licensed as "GPL version > >> 1 or later". > >> > >> GPLv2: If the code only says "version 2 of the License." and does NOT > >> say "or later version", then it is GPLv2 only. > >> > > [...] > >> > >> NOTE: Don't trust COPYING. Look at the source code itself. > > > > I've got ~40 packages to go through, so this may take a while. Any > > offers of help are appreciated. > > > > Heh, sorry I'm about to finish doing my 149th and 150th package today (after > days of working on this), and I really do _not_ feel like doing any more > license reviews. I'm happy to answer any questions though. > > > abe contains only a COPYING file that says 'Version 2', and no copyright > > or license info in the source files themselves. In the absence of > > anything in the source files, does this qualify abe for 'GPL+' or 'GPLv2'? > > > > GPL+, the version in the COPYING file is irrelevant. IANAL, but I don't think this is right at all. The author expressed in COPYING what the license is and it is v2. You can't ignore the author intentions at all. And in general if COPYING does not reflect the content that's a BUG. Upstream should be notified and asked to fix it with the correct information. Simo. From jwboyer at jdub.homelinux.org Thu Aug 16 12:39:03 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 16 Aug 2007 07:39:03 -0500 Subject: Licensing change: binutils GPLv2 -> GPLv3 In-Reply-To: <1187232580.3439.75.camel@dhcp83-165.boston.redhat.com> References: <20070815234531.GU2063@devserv.devel.redhat.com> <1187232580.3439.75.camel@dhcp83-165.boston.redhat.com> Message-ID: <20070816073903.27d41be7@vader.jdub.homelinux.org> On Wed, 15 Aug 2007 22:49:40 -0400 "Tom \"spot\" Callaway" wrote: > > sblim-wbemcli > > CPL. Well, if we were linking to this, it might be a problem (CPL is > GPL incompatible), but its only using some very basic header > information from binutils-devel, and no linking to it, so its fine. There is a fairly old version of this package in devel at the moment. 1.5.3 was released a while ago. The entire sblim-* package set got relicensed under the EPL (which likely has little bearing on the matter at hand). josh From adel.gadllah at gmail.com Thu Aug 16 12:56:22 2007 From: adel.gadllah at gmail.com (Adel Gadllah) Date: Thu, 16 Aug 2007 14:56:22 +0200 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <46C3DF4B.9040105@hhs.nl> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <46C3DCA5.9080909@kobold.org> <46C3DF4B.9040105@hhs.nl> Message-ID: <46C44976.7030208@gmail.com> Hans de Goede wrote: > > > GPL+, the version in the COPYING file is irrelevant. this sounds wrong ... if the source says nothing and the copying says gplv2 it _is_ gplv2. From dwmw2 at infradead.org Thu Aug 16 13:05:43 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 16 Aug 2007 21:05:43 +0800 Subject: The open() system call in f8 really broken... In-Reply-To: <20070816093959.GB2070@devserv.devel.redhat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> Message-ID: <1187269543.2778.311.camel@shinybook.infradead.org> On Thu, 2007-08-16 at 05:39 -0400, Alan Cox wrote: > Sorry ignore the previous email I misunderstood what was going on. > > You can open a file O_CREAT with neither read or write, you can open a file > with O_CREAT|O_WRONLY but not give permissions in the file mode. You must > provide the third argument so the abort is right. If you don't then the permissions > are set based on the random values (eg the return address) Return address? Even on crappy register-starved architectures like i386 we'd have the three arguments in registers, wouldn't we? The permissions are set based on the contents of some register, surely? -- dwmw2 From jakub at redhat.com Thu Aug 16 13:12:25 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 16 Aug 2007 09:12:25 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <1187269543.2778.311.camel@shinybook.infradead.org> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <1187269543.2778.311.camel@shinybook.infradead.org> Message-ID: <20070816131225.GZ2063@devserv.devel.redhat.com> On Thu, Aug 16, 2007 at 09:05:43PM +0800, David Woodhouse wrote: > On Thu, 2007-08-16 at 05:39 -0400, Alan Cox wrote: > > Sorry ignore the previous email I misunderstood what was going on. > > > > You can open a file O_CREAT with neither read or write, you can open a file > > with O_CREAT|O_WRONLY but not give permissions in the file mode. You must > > provide the third argument so the abort is right. If you don't then the permissions > > are set based on the random values (eg the return address) > > Return address? > > Even on crappy register-starved architectures like i386 we'd have the > three arguments in registers, wouldn't we? The permissions are set based > on the contents of some register, surely? i386 passes arguments on the stack (unless regparm is used, which open doesn't, but even then, regparm doesn't affect varargs). So, on some architectures like i?86 open ("foo", O_CREAT | O_RDWR); passes stack content as mode, while on most architectures it is content of some register. But whether it is stack slot or register doesn't change anything on that if mode passed to open makes sense, it is by pure luck. Jakub From aph at redhat.com Thu Aug 16 13:14:39 2007 From: aph at redhat.com (Andrew Haley) Date: Thu, 16 Aug 2007 14:14:39 +0100 Subject: The open() system call in f8 really broken... In-Reply-To: <1187269543.2778.311.camel@shinybook.infradead.org> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <1187269543.2778.311.camel@shinybook.infradead.org> Message-ID: <18116.19903.661970.874942@zebedee.pink> David Woodhouse writes: > On Thu, 2007-08-16 at 05:39 -0400, Alan Cox wrote: > > Sorry ignore the previous email I misunderstood what was going on. > > > > You can open a file O_CREAT with neither read or write, you can open a file > > with O_CREAT|O_WRONLY but not give permissions in the file mode. You must > > provide the third argument so the abort is right. If you don't then the permissions > > are set based on the random values (eg the return address) > > Return address? > > Even on crappy register-starved architectures like i386 we'd have the > three arguments in registers, wouldn't we? No: in userland all args are passed on the stack. subl $24, %esp #, movl $66, 4(%esp) #, movl $.LC0, (%esp) #, call open # Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From dwmw2 at infradead.org Thu Aug 16 13:18:50 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 16 Aug 2007 21:18:50 +0800 Subject: The open() system call in f8 really broken... In-Reply-To: <18116.19903.661970.874942@zebedee.pink> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <1187269543.2778.311.camel@shinybook.infradead.org> <18116.19903.661970.874942@zebedee.pink> Message-ID: <1187270330.2778.313.camel@shinybook.infradead.org> On Thu, 2007-08-16 at 14:14 +0100, Andrew Haley wrote: > No: in userland all args are passed on the stack. > > subl $24, %esp #, > movl $66, 4(%esp) #, > movl $.LC0, (%esp) #, > call open # Ew. Ew. Ew. Ew. -- dwmw2 From Hit-Booster at redhat.com Fri Aug 17 03:57:08 2007 From: Hit-Booster at redhat.com (Hit-Booster at redhat.com) Date: 16 Aug 2007 20:57:08 -0700 Subject: No Matter what you are selling - Hit-Booster will send targeted visitors to your website! Message-ID: <200708161338.l7GDcMsh023418@mx1.redhat.com> New Break-through Automation Technology WILL Pull in hordes of Within 15 minutes you will have your own website traffic generator that will bring in an ever increasing amount of hits to your websites! Automatically This software is perfect for bringing real traffic to your site... even if... it's an affiliate link where you have no control over the website content! Using my automated program I have developed, just insert your url... ...choose a category... ...have HIT-BOOSTER send thousands of targeted visitors to your site. Let me tell you what Hit-Booster can do for you ...Hit-Booster will start sending hits to your website instantly at $0 cost to you! ...No matter what you are selling or offering - HIT BOOSTER will pull in hordes of potential customers to your website or affiliate website! ...sets this up completely for you on Auto-Pilot! ...Use it for all of your websites - there is no limit . ...Receive my personal support and email address with your purchase so I can help you to succeed! ...your web site will quickly achieve Ultra High Link Popularity on the Major Search Engines ...you'll get 1000's of Highly Targeted visitors to your web site or affiliate web site overnight ...many are getting more Customers and Sales than they can handle For Full Details please download the attached .html file Unsubscribe Please read the attached .txt file -------------- next part -------------- A non-text attachment was scrubbed... Name: hitbooster.htm Type: application/octet-stream Size: 390 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Unsubscribe email.txt Type: application/octet-stream Size: 25 bytes Desc: not available URL: From limb at jcomserv.net Thu Aug 16 13:28:49 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 16 Aug 2007 08:28:49 -0500 (CDT) Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> Message-ID: <44153.65.192.24.164.1187270929.squirrel@mail.jcomserv.net> > Got your attention? Good. > > GPL and LGPL are NOT acceptable License tags for Fedora. You cannot > simply use "GPL" or "LGPL" as a license tag anymore. > > You have to use one of the following tags: > > GPL+, GPLv2, GPLv2+, GPLv3, GPLv3+, LGPLv2, LGPLv2+, LGPLv3, LGPLv3+ > > GPL+: If there is no version specified anywhere, and it only says GPL, > then it is GPL+. It is also GPL+ if the code is licensed as "GPL version > 1 or later". > > GPLv2: If the code only says "version 2 of the License." and does NOT > say "or later version", then it is GPLv2 only. > > GPLv2+: If the code is GPL v2 and it says "either version 2 of the > License, or (at your option) any later version.", then it is GPLv2 or > later. > > GPLv3: Same as GPLv2 only, except, GPLv3 only. > > GPLv3+: Same as GPLv2 or later, except GPLv3 or later. > > LGPLv2+: If there is no version specified anywhere, and it only says > LGPL, then it is LGPLv2+. Also, use this tag if it is LGPL v2 (or 2.1) > and it says "or (at your option) any later version." in the code. > > LGPLv2: If the code only says "version 2 (or 2.1) of the License." and > does NOT say "or later version", then it is LGPLv2 only. > > LGPLv3: Same as LGPLv2 only, except LGPLv3 only. > > LGPLv3+: Same as LGPLv2 or later, except LGPLv3 or later. > > NOTE: Don't trust COPYING. Look at the source code itself. > > Please, please, please do this. Take a minute and go through your > packages and correct the specs so that they are using the new License > tagging schema. I may have missed this, if so, my apologies, but: A. Do we need to update all branches, or only devel? B. Do we need to rebuild for any branches? FWIW, I've updated all those I maintain. Might get to those I co-maintain if there's time. . . > Thanks in advance, > > ~spot > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- novus ordo absurdum From alan at redhat.com Thu Aug 16 13:52:34 2007 From: alan at redhat.com (Alan Cox) Date: Thu, 16 Aug 2007 09:52:34 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <1187270330.2778.313.camel@shinybook.infradead.org> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <1187269543.2778.311.camel@shinybook.infradead.org> <18116.19903.661970.874942@zebedee.pink> <1187270330.2778.313.camel@shinybook.infradead.org> Message-ID: <20070816135234.GA15605@devserv.devel.redhat.com> On Thu, Aug 16, 2007 at 09:18:50PM +0800, David Woodhouse wrote: > > movl $66, 4(%esp) #, > > movl $.LC0, (%esp) #, > > call open # > > Ew. Ew. Ew. Ew. Perhaps but the x86 processor isn't a processor that runs x86 instructions, it takes a compressed instruction stream in an old compact format and turns it into something sane - so this is much less of an isssue than you might think From tcallawa at redhat.com Thu Aug 16 13:47:34 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 16 Aug 2007 09:47:34 -0400 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <46C44976.7030208@gmail.com> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <46C3DCA5.9080909@kobold.org> <46C3DF4B.9040105@hhs.nl> <46C44976.7030208@gmail.com> Message-ID: <1187272054.3439.109.camel@dhcp83-165.boston.redhat.com> On Thu, 2007-08-16 at 14:56 +0200, Adel Gadllah wrote: > Hans de Goede wrote: > > > > > > GPL+, the version in the COPYING file is irrelevant. > this sounds wrong ... if the source says nothing and the copying says > gplv2 it _is_ gplv2. COPYING does not signal licensing intent (it might not seem intuitive, but this is what Red Hat legal told us, and we're going by that). The order of operations goes like this: 1. What does the code say? If it specifies a version, that's what it is. 2. Does the code conflict with itself? (file1.c and file2.c are compiled together but have different licensing) 2A. Are the conflicting licenses compatible? 2AA. Does one license overpower the other one? (GPL/LGPL does this) If so, the strictest license wins. 3. What does the documentation say? This signals the author(s) intentions from a legal perspective, although, not as binding as in the source. If the documentation specifies a version when the source does not, then we can use the documentation as our source. NOTE: COPYING does not count as documentation, since the author(s) didn't write it. 4. If neither the source, nor the upstream composed documentation says anything about the license version, then it could be under _ANY_ version of the GPL. The version listed in COPYING is irrelevant from this perspective. Now, keep in mind that most upstreams are probably leaving the versioning out by accident. If you get to case 4, you definitely want to let upstream know that you are unable to determine the applicable version(s) of the license from the source and documentation. They'll almost certainly let you know what their intended license version is, and (hopefully) correct it in the upstream source. ~spot From tjanouse at redhat.com Thu Aug 16 14:06:00 2007 From: tjanouse at redhat.com (Tomas Janousek) Date: Thu, 16 Aug 2007 16:06:00 +0200 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <1187272054.3439.109.camel@dhcp83-165.boston.redhat.com> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <46C3DCA5.9080909@kobold.org> <46C3DF4B.9040105@hhs.nl> <46C44976.7030208@gmail.com> <1187272054.3439.109.camel@dhcp83-165.boston.redhat.com> Message-ID: <20070816140600.GA23010@redhat.com> Hi, On Thu, Aug 16, 2007 at 09:47:34AM -0400, Tom spot Callaway wrote: > COPYING does not signal licensing intent (it might not seem intuitive, > but this is what Red Hat legal told us, and we're going by that). > > [...] > > 4. If neither the source, nor the upstream composed documentation says > anything about the license version, then it could be under _ANY_ version > of the GPL. The version listed in COPYING is irrelevant from this > perspective. If COPYING does not signal licensing intent, why "any version of the GPL", why not "unknown license, if any" ? -- TJ. (Brno, CZ), BaseOS, Red Hat From sundaram at fedoraproject.org Thu Aug 16 14:04:43 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 16 Aug 2007 19:34:43 +0530 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <1187272054.3439.109.camel@dhcp83-165.boston.redhat.com> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <46C3DCA5.9080909@kobold.org> <46C3DF4B.9040105@hhs.nl> <46C44976.7030208@gmail.com> <1187272054.3439.109.camel@dhcp83-165.boston.redhat.com> Message-ID: <46C4597B.2020707@fedoraproject.org> Tom "spot" Callaway wrote: > The order of operations goes like this: > > 1. What does the code say? If it specifies a version, that's what it is. > 2. Does the code conflict with itself? (file1.c and file2.c are compiled > together but have different licensing) > 2A. Are the conflicting licenses compatible? > 2AA. Does one license overpower the other one? (GPL/LGPL does this) If > so, the strictest license wins. > 3. What does the documentation say? This signals the author(s) > intentions from a legal perspective, although, not as binding as in the > source. If the documentation specifies a version when the source does > not, then we can use the documentation as our source. NOTE: COPYING does > not count as documentation, since the author(s) didn't write it. > 4. If neither the source, nor the upstream composed documentation says > anything about the license version, then it could be under _ANY_ version > of the GPL. The version listed in COPYING is irrelevant from this > perspective. > > Now, keep in mind that most upstreams are probably leaving the > versioning out by accident. If you get to case 4, you definitely want to > let upstream know that you are unable to determine the applicable > version(s) of the license from the source and documentation. They'll > almost certainly let you know what their intended license version is, > and (hopefully) correct it in the upstream source. You might want to put this in the licensing wiki page. This looks like repeatedly asked for information. Rahul From ssorce at redhat.com Thu Aug 16 14:09:30 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 16 Aug 2007 10:09:30 -0400 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <1187272054.3439.109.camel@dhcp83-165.boston.redhat.com> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <46C3DCA5.9080909@kobold.org> <46C3DF4B.9040105@hhs.nl> <46C44976.7030208@gmail.com> <1187272054.3439.109.camel@dhcp83-165.boston.redhat.com> Message-ID: <1187273370.27768.25.camel@localhost.localdomain> On Thu, 2007-08-16 at 09:47 -0400, Tom "spot" Callaway wrote: > NOTE: COPYING does > not count as documentation, since the author(s) didn't write it. > 4. If neither the source, nor the upstream composed documentation says > anything about the license version, then it could be under _ANY_ > version > of the GPL. The version listed in COPYING is irrelevant from this > perspective. I am sure it is worth mentioning that this is true when COPYING is copied over mindlessly and not modified, while if it has obviously been modified by the author it counts as documentation. Simo. From SteveD at redhat.com Thu Aug 16 14:12:24 2007 From: SteveD at redhat.com (Steve Dickson) Date: Thu, 16 Aug 2007 10:12:24 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <20070816093959.GB2070@devserv.devel.redhat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> Message-ID: <46C45B48.3000607@RedHat.com> Alan Cox wrote: > On Wed, Aug 15, 2007 at 08:56:10PM -0400, Steve Dickson wrote: >> and the following change stops the error: >> >> - if ((fd = open(fname, readonly? O_RDONLY : (O_RDWR|O_CREAT))) < 0) { >> + if ((fd = (open)(fname, readonly? O_RDONLY : (O_RDWR|O_CREAT))) < 0) { >> xlog(L_WARNING, "could not open %s for locking", fname); >> return -1; >> } >> >> Which does not change the fact I'm using O_CREAT w/out a mode >> So what is the point of killing the process??? >> >> Now If I'm not mistaken, its been legal since the 70s to use >> O_CREAT without a mode because (depending on the OS) the mode >> of parent directory will be used (or something similar)... > > Sorry ignore the previous email I misunderstood what was going on. > > You can open a file O_CREAT with neither read or write, you can open a file > with O_CREAT|O_WRONLY but not give permissions in the file mode. You must > provide the third argument so the abort is right. This is were I disagree because a presidents has been set (for a large number of years) that this is *not* an abort-able offense. Now if we want to change the rules to make things like this an abort-able offense... that's fine... I'm all for cleaning up dangerous code... But lets change these rules in a less disruptive way... Bring down servers, costing people time and money because apps that have run for years suddenly abort is just not the right way to handle this.. imho.. Give people a chance to correct their code, with stern warnings, and then, in the next release, have the applications abort... Why is this such a bad idea? Also how is the going to fly in the RHEL world? Alan, your a master word smith, I truly do enjoy the way you use your words (as long as you don't use them against me of course ;-) ), but even you I think would have a hard time selling the reason why 90% of Disney's rendering applications just abort because we changed the rules (or presidents)... Personally I think is going to be major pr nightmare and it does not have to be if handled correctly... because in the end we are doing the right thing, but we just have to do it the right way... steved. From oliver at linux-kernel.at Thu Aug 16 14:16:16 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 16 Aug 2007 16:16:16 +0200 Subject: The open() system call in f8 really broken... In-Reply-To: <46C45B48.3000607@RedHat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> Message-ID: <46C45C30.8050001@linux-kernel.at> On 08/16/2007 04:12 PM, Steve Dickson wrote: > > > Alan Cox wrote: >> On Wed, Aug 15, 2007 at 08:56:10PM -0400, Steve Dickson wrote: >>> and the following change stops the error: >>> >>> - if ((fd = open(fname, readonly? O_RDONLY : (O_RDWR|O_CREAT))) < 0) { >>> + if ((fd = (open)(fname, readonly? O_RDONLY : (O_RDWR|O_CREAT))) < 0) { >>> xlog(L_WARNING, "could not open %s for locking", fname); >>> return -1; >>> } >>> >>> Which does not change the fact I'm using O_CREAT w/out a mode >>> So what is the point of killing the process??? >>> >>> Now If I'm not mistaken, its been legal since the 70s to use >>> O_CREAT without a mode because (depending on the OS) the mode >>> of parent directory will be used (or something similar)... >> >> Sorry ignore the previous email I misunderstood what was going on. >> >> You can open a file O_CREAT with neither read or write, you can open a >> file >> with O_CREAT|O_WRONLY but not give permissions in the file mode. You must >> provide the third argument so the abort is right. > This is were I disagree because a presidents has been set (for > a large number of years) that this is *not* an abort-able offense. > > Now if we want to change the rules to make things like this > an abort-able offense... that's fine... I'm all for cleaning > up dangerous code... But lets change these rules in a less > disruptive way... > > Bring down servers, costing people time and money because apps > that have run for years suddenly abort is just not the right > way to handle this.. imho.. > > Give people a chance to correct their code, with stern warnings, > and then, in the next release, have the applications abort... > Why is this such a bad idea? > > Also how is the going to fly in the RHEL world? Alan, your > a master word smith, I truly do enjoy the way you use your > words (as long as you don't use them against me of course ;-) ), > but even you I think would have a hard time selling the reason > why 90% of Disney's rendering applications just abort > because we changed the rules (or presidents)... > > Personally I think is going to be major pr nightmare and > it does not have to be if handled correctly... because > in the end we are doing the right thing, but we just > have to do it the right way... Next disney film will come 5 years l8er :-P -of From cagney at redhat.com Thu Aug 16 14:21:14 2007 From: cagney at redhat.com (Andrew Cagney) Date: Thu, 16 Aug 2007 10:21:14 -0400 Subject: Licensing change: binutils GPLv2 -> GPLv3 In-Reply-To: <1187232580.3439.75.camel@dhcp83-165.boston.redhat.com> References: <20070815234531.GU2063@devserv.devel.redhat.com> <1187232580.3439.75.camel@dhcp83-165.boston.redhat.com> Message-ID: <46C45D5A.80501@redhat.com> > GPLv2 with exception > > This is almost certainly a problem. Looks to be linking against > libopcodes.a. The link is static so the push has no immediate affect; to be addressed in next update. Andrew From jakub at redhat.com Thu Aug 16 14:24:37 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 16 Aug 2007 10:24:37 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <46C45B48.3000607@RedHat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> Message-ID: <20070816142437.GA2063@devserv.devel.redhat.com> On Thu, Aug 16, 2007 at 10:12:24AM -0400, Steve Dickson wrote: > Bring down servers, costing people time and money because apps > that have run for years suddenly abort is just not the right > way to handle this.. imho.. Only people that run their $$$$$$ servers on rawhide... > Give people a chance to correct their code, with stern warnings, > and then, in the next release, have the applications abort... > Why is this such a bad idea? It is not yet F8test2, there is plenty of time to fix all or most of these bugs still in rawhide. Most uses of open(1) are actually with compile time constant second argument and in that case glibc will issue compile time errors when open ("foo", O_CREAT|O_RDWR); etc. is seen. Only when it is known only at runtime we do runtime checking. Jakub From jkeating at redhat.com Thu Aug 16 14:25:01 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 16 Aug 2007 10:25:01 -0400 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <20070816140600.GA23010@redhat.com> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <46C3DCA5.9080909@kobold.org> <46C3DF4B.9040105@hhs.nl> <46C44976.7030208@gmail.com> <1187272054.3439.109.camel@dhcp83-165.boston.redhat.com> <20070816140600.GA23010@redhat.com> Message-ID: <20070816102501.5bcd7777@mentok.boston.redhat.com> On Thu, 16 Aug 2007 16:06:00 +0200 Tomas Janousek wrote: > If COPYING does not signal licensing intent, why "any version of the > GPL", why not "unknown license, if any" ? An unmodified COPYING file from FSF contains: "If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation." -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From oliver at linux-kernel.at Thu Aug 16 14:32:50 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 16 Aug 2007 16:32:50 +0200 Subject: The open() system call in f8 really broken... In-Reply-To: <20070816142437.GA2063@devserv.devel.redhat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> Message-ID: <46C46012.3060904@linux-kernel.at> On 08/16/2007 04:24 PM, Jakub Jelinek wrote: > On Thu, Aug 16, 2007 at 10:12:24AM -0400, Steve Dickson wrote: >> Bring down servers, costing people time and money because apps >> that have run for years suddenly abort is just not the right >> way to handle this.. imho.. > > Only people that run their $$$$$$ servers on rawhide... Very unlikely that Disney or any other big company does that :-) And if they for sure have good admins (well, do good admins run rawhide on their $$$$ servers?) to fix it - if not, they are doomed. :-P [ ... ] -of From SteveD at redhat.com Thu Aug 16 14:34:03 2007 From: SteveD at redhat.com (Steve Dickson) Date: Thu, 16 Aug 2007 10:34:03 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <20070816142437.GA2063@devserv.devel.redhat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> Message-ID: <46C4605B.1000407@RedHat.com> Jakub Jelinek wrote: > On Thu, Aug 16, 2007 at 10:12:24AM -0400, Steve Dickson wrote: >> Bring down servers, costing people time and money because apps >> that have run for years suddenly abort is just not the right >> way to handle this.. imho.. > > Only people that run their $$$$$$ servers on rawhide... No.. but they do on RHEL and today's rawhide is tomorrow's RHEL... > >> Give people a chance to correct their code, with stern warnings, >> and then, in the next release, have the applications abort... >> Why is this such a bad idea? > > It is not yet F8test2, there is plenty of time to fix all or most > of these bugs still in rawhide. > Most uses of open(1) are actually with compile time constant > second argument and in that case glibc will issue compile time > errors when open ("foo", O_CREAT|O_RDWR); etc. is seen. > Only when it is known only at runtime we do runtime checking. So is there a possibility of making that runtime check a warning instead of an abort? steved. From opensource at till.name Thu Aug 16 14:34:48 2007 From: opensource at till.name (Till Maas) Date: Thu, 16 Aug 2007 16:34:48 +0200 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <1187272054.3439.109.camel@dhcp83-165.boston.redhat.com> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <46C44976.7030208@gmail.com> <1187272054.3439.109.camel@dhcp83-165.boston.redhat.com> Message-ID: <200708161634.54496.opensource@till.name> On Thursday 16 August 2007 15:47:34 Tom "spot" Callaway wrote: > The order of operations goes like this: > > 1. What does the code say? If it specifies a version, that's what it is. What if the code only says "see COPYING ", is it then ok to use the version information from COPYING? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From oliver at linux-kernel.at Thu Aug 16 14:40:06 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 16 Aug 2007 16:40:06 +0200 Subject: The open() system call in f8 really broken... In-Reply-To: <46C4605B.1000407@RedHat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4605B.1000407@RedHat.com> Message-ID: <46C461C6.5080302@linux-kernel.at> On 08/16/2007 04:34 PM, Steve Dickson wrote: > Jakub Jelinek wrote: >> On Thu, Aug 16, 2007 at 10:12:24AM -0400, Steve Dickson wrote: >>> Bring down servers, costing people time and money because apps >>> that have run for years suddenly abort is just not the right >>> way to handle this.. imho.. >> >> Only people that run their $$$$$$ servers on rawhide... > No.. but they do on RHEL and today's rawhide is tomorrow's RHEL... But Steve, they will not simply do a yum upgrade on their EL5 boxes to upgrade to EL6... The open change in glibc will be mentioned in the release notes and every good admin has test environments to test a new distro before actually going live and in production.... Same here at my company... Don't be afraid, I doubt this glibc will make it into EL4 or EL5 updates... [ ... ] -of From ville.skytta at iki.fi Thu Aug 16 14:41:22 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Thu, 16 Aug 2007 17:41:22 +0300 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <1187273370.27768.25.camel@localhost.localdomain> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <1187272054.3439.109.camel@dhcp83-165.boston.redhat.com> <1187273370.27768.25.camel@localhost.localdomain> Message-ID: <200708161741.23522.ville.skytta@iki.fi> On Thursday 16 August 2007, Simo Sorce wrote: > On Thu, 2007-08-16 at 09:47 -0400, Tom "spot" Callaway wrote: > > NOTE: COPYING does > > not count as documentation, since the author(s) didn't write it. > > 4. If neither the source, nor the upstream composed documentation says > > anything about the license version, then it could be under _ANY_ > > version > > of the GPL. The version listed in COPYING is irrelevant from this > > perspective. > > I am sure it is worth mentioning that this is true when COPYING is > copied over mindlessly and not modified, while if it has obviously been > modified by the author it counts as documentation. The GPL license text does not allow modification. "Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed." Uh... by the way, doesn't that make the license doc non-free, and thus not okay to distribute in Fedora? :) From jkeating at redhat.com Thu Aug 16 14:43:25 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 16 Aug 2007 10:43:25 -0400 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <200708161634.54496.opensource@till.name> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <46C44976.7030208@gmail.com> <1187272054.3439.109.camel@dhcp83-165.boston.redhat.com> <200708161634.54496.opensource@till.name> Message-ID: <20070816104325.749655a1@mentok.boston.redhat.com> On Thu, 16 Aug 2007 16:34:48 +0200 Till Maas wrote: > What if the code only says "see COPYING ", is it then ok to use the > version information from COPYING? I do believe that counts as documentation, and since unmodified COPYING is basically GPL+ that would be your license. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sgrubb at redhat.com Thu Aug 16 14:43:54 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Thu, 16 Aug 2007 10:43:54 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <46C45B48.3000607@RedHat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> Message-ID: <200708161043.55455.sgrubb@redhat.com> On Thursday 16 August 2007 10:12:24 Steve Dickson wrote: > This is were I disagree because a presidents has been set (for > a large number of years) that this is *not* an abort-able offense. What about buffer overflows? This is detected and an immediate abort occurs. This is the same kind of thing. > Give people a chance to correct their code, with stern warnings, > and then, in the next release, have the applications abort... > Why is this such a bad idea? I think a mass rebuild will flush out the majority of the problem places. An app that does not have a mode when O_CREATE is passed should cause the compiler to error out. -Steve From jakub at redhat.com Thu Aug 16 14:46:17 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 16 Aug 2007 10:46:17 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <46C4605B.1000407@RedHat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4605B.1000407@RedHat.com> Message-ID: <20070816144617.GB2063@devserv.devel.redhat.com> On Thu, Aug 16, 2007 at 10:34:03AM -0400, Steve Dickson wrote: > >Only people that run their $$$$$$ servers on rawhide... > No.. but they do on RHEL and today's rawhide is tomorrow's RHEL... Well, next years or so, that's different. There is plenty of time to fix these bugs. > >It is not yet F8test2, there is plenty of time to fix all or most > >of these bugs still in rawhide. > >Most uses of open(1) are actually with compile time constant > >second argument and in that case glibc will issue compile time > >errors when open ("foo", O_CREAT|O_RDWR); etc. is seen. > >Only when it is known only at runtime we do runtime checking. > So is there a possibility of making that runtime check a warning > instead of an abort? No. But if you want to make sure packages you built successfully against glibc-2.6.90-* or later don't die at runtime for these errors, it is pretty easy to just check all calls to __open{,at}{,64}_2 functions (i.e. calls which don't pass mode argument to open* and it is not clear whether O_CREAT is or is not used at compile time), they will be pretty rare and in each case you can study the code to determine if the passed flags can contain O_CREAT or not. If they can, you must supply the mode argument, if it can't, you are ok. Jakub From jakub at redhat.com Thu Aug 16 14:48:58 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 16 Aug 2007 10:48:58 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <46C461C6.5080302@linux-kernel.at> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4605B.1000407@RedHat.com> <46C461C6.5080302@linux-kernel.at> Message-ID: <20070816144858.GC2063@devserv.devel.redhat.com> On Thu, Aug 16, 2007 at 04:40:06PM +0200, Oliver Falk wrote: > Don't be afraid, I doubt this glibc will make it into EL4 or EL5 updates... It can't, not even to F7. It requires 4 new libc.so.6 symbols with @@GLIBC_2.7 symver, so if we added it there, it would mean we'd have to upgrade whole glibc there to glibc 2.7 or later. That's just not going to happen. Jakub From oliver at linux-kernel.at Thu Aug 16 14:54:46 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 16 Aug 2007 16:54:46 +0200 Subject: The open() system call in f8 really broken... In-Reply-To: <20070816144858.GC2063@devserv.devel.redhat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4605B.1000407@RedHat.com> <46C461C6.5080302@linux-kernel.at> <20070816144858.GC2063@devserv.devel.redhat.com> Message-ID: <46C46536.3000707@linux-kernel.at> On 08/16/2007 04:48 PM, Jakub Jelinek wrote: > On Thu, Aug 16, 2007 at 04:40:06PM +0200, Oliver Falk wrote: >> Don't be afraid, I doubt this glibc will make it into EL4 or EL5 updates... > > It can't, not even to F7. It requires 4 new libc.so.6 symbols with > @@GLIBC_2.7 symver, so if we added it there, it would mean we'd have to > upgrade whole glibc there to glibc 2.7 or later. That's just not going to > happen. Well, so my doubts are correct :-) -of From SteveD at redhat.com Thu Aug 16 14:55:20 2007 From: SteveD at redhat.com (Steve Dickson) Date: Thu, 16 Aug 2007 10:55:20 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <46C461C6.5080302@linux-kernel.at> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4605B.1000407@RedHat.com> <46C461C6.5080302@linux-kernel.at> Message-ID: <46C46558.1000905@RedHat.com> Oliver Falk wrote: > On 08/16/2007 04:34 PM, Steve Dickson wrote: >> Jakub Jelinek wrote: >>> On Thu, Aug 16, 2007 at 10:12:24AM -0400, Steve Dickson wrote: >>>> Bring down servers, costing people time and money because apps >>>> that have run for years suddenly abort is just not the right >>>> way to handle this.. imho.. >>> Only people that run their $$$$$$ servers on rawhide... >> No.. but they do on RHEL and today's rawhide is tomorrow's RHEL... > > But Steve, they will not simply do a yum upgrade on their EL5 boxes to > upgrade to EL6... Agreed... And I'll concede moving from one RHEL release to another RHEL release is a good time to make people recompile their code esp for security issues... and their code should not compile if there is a security issue... But thats not the case here! My code compile and then aborted... and even worse I was able to avoid the abort without fixing the security hole.. so the abort was basically meaningless... imo... So I guess what I'm saying, if you can't catch the security issue and fail the compilation, don't abort the process at run time. Issue a warning instead... Let the developers decide how grievous the problem, not glibc... steved. From ssorce at redhat.com Thu Aug 16 14:59:58 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 16 Aug 2007 10:59:58 -0400 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <20070816104325.749655a1@mentok.boston.redhat.com> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <46C44976.7030208@gmail.com> <1187272054.3439.109.camel@dhcp83-165.boston.redhat.com> <200708161634.54496.opensource@till.name> <20070816104325.749655a1@mentok.boston.redhat.com> Message-ID: <1187276398.27768.43.camel@localhost.localdomain> On Thu, 2007-08-16 at 10:43 -0400, Jesse Keating wrote: > On Thu, 16 Aug 2007 16:34:48 +0200 > Till Maas wrote: > > > What if the code only says "see COPYING ", is it then ok to use the > > version information from COPYING? > > I do believe that counts as documentation, and since unmodified COPYING > is basically GPL+ that would be your license. While this is strictly true I think the best action is to ask upstream to resolve the issue by explicitly stating their choice in a document. /me imagines an angry author shouting at C violation by Fedora because we mark something GPL+ instead of GPLv2+ or GPLv3+ From tcallawa at redhat.com Thu Aug 16 14:58:44 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 16 Aug 2007 10:58:44 -0400 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <1187276398.27768.43.camel@localhost.localdomain> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <46C44976.7030208@gmail.com> <1187272054.3439.109.camel@dhcp83-165.boston.redhat.com> <200708161634.54496.opensource@till.name> <20070816104325.749655a1@mentok.boston.redhat.com> <1187276398.27768.43.camel@localhost.localdomain> Message-ID: <1187276324.3439.133.camel@dhcp83-165.boston.redhat.com> On Thu, 2007-08-16 at 10:59 -0400, Simo Sorce wrote: > On Thu, 2007-08-16 at 10:43 -0400, Jesse Keating wrote: > > On Thu, 16 Aug 2007 16:34:48 +0200 > > Till Maas wrote: > > > > > What if the code only says "see COPYING ", is it then ok to use the > > > version information from COPYING? > > > > I do believe that counts as documentation, and since unmodified COPYING > > is basically GPL+ that would be your license. > > While this is strictly true I think the best action is to ask upstream > to resolve the issue by explicitly stating their choice in a document. > > /me imagines an angry author shouting at C violation by Fedora because > we mark something GPL+ instead of GPLv2+ or GPLv3+ Agreed. Asking upstream is the best way to resolve that case. However, we're not liable for any mistaken tagging of the License in our package, because the License: tag isn't legally binding. ~spot From ssorce at redhat.com Thu Aug 16 15:08:06 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 16 Aug 2007 11:08:06 -0400 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <1187276324.3439.133.camel@dhcp83-165.boston.redhat.com> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <46C44976.7030208@gmail.com> <1187272054.3439.109.camel@dhcp83-165.boston.redhat.com> <200708161634.54496.opensource@till.name> <20070816104325.749655a1@mentok.boston.redhat.com> <1187276398.27768.43.camel@localhost.localdomain> <1187276324.3439.133.camel@dhcp83-165.boston.redhat.com> Message-ID: <1187276886.27768.45.camel@localhost.localdomain> On Thu, 2007-08-16 at 10:58 -0400, Tom "spot" Callaway wrote: > On Thu, 2007-08-16 at 10:59 -0400, Simo Sorce wrote: > > /me imagines an angry author shouting at C violation by Fedora because > > we mark something GPL+ instead of GPLv2+ or GPLv3+ > > Agreed. Asking upstream is the best way to resolve that case. > > However, we're not liable for any mistaken tagging of the License in our > package, because the License: tag isn't legally binding. Yeah in fact I said shouting not taking legal action :-) Simo. From tmraz at redhat.com Thu Aug 16 15:08:08 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 16 Aug 2007 17:08:08 +0200 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <200708161741.23522.ville.skytta@iki.fi> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <1187272054.3439.109.camel@dhcp83-165.boston.redhat.com> <1187273370.27768.25.camel@localhost.localdomain> <200708161741.23522.ville.skytta@iki.fi> Message-ID: <1187276889.14791.12.camel@vespa.kabelta.loc> On Thu, 2007-08-16 at 17:41 +0300, Ville Skytt? wrote: > On Thursday 16 August 2007, Simo Sorce wrote: > > On Thu, 2007-08-16 at 09:47 -0400, Tom "spot" Callaway wrote: > > > NOTE: COPYING does > > > not count as documentation, since the author(s) didn't write it. > > > 4. If neither the source, nor the upstream composed documentation says > > > anything about the license version, then it could be under _ANY_ > > > version > > > of the GPL. The version listed in COPYING is irrelevant from this > > > perspective. > > > > I am sure it is worth mentioning that this is true when COPYING is > > copied over mindlessly and not modified, while if it has obviously been > > modified by the author it counts as documentation. > > The GPL license text does not allow modification. > > "Everyone is permitted to copy and distribute verbatim copies > of this license document, but changing it is not allowed." If the modification of the COPYING file consists of adding some text like specification of the exact GPL version which is chosen by author before and/or after the GPL license text, this doesn't change the GPL license text and thus is clearly allowed. (IANAL) -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From oliver at linux-kernel.at Thu Aug 16 15:08:15 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 16 Aug 2007 17:08:15 +0200 Subject: The open() system call in f8 really broken... In-Reply-To: <46C46558.1000905@RedHat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4605B.1000407@RedHat.com> <46C461C6.5080302@linux-kernel.at> <46C46558.1000905@RedHat.com> Message-ID: <46C4685F.8080601@linux-kernel.at> On 08/16/2007 04:55 PM, Steve Dickson wrote: > Oliver Falk wrote: >> On 08/16/2007 04:34 PM, Steve Dickson wrote: >>> Jakub Jelinek wrote: >>>> On Thu, Aug 16, 2007 at 10:12:24AM -0400, Steve Dickson wrote: >>>>> Bring down servers, costing people time and money because apps >>>>> that have run for years suddenly abort is just not the right >>>>> way to handle this.. imho.. >>>> Only people that run their $$$$$$ servers on rawhide... >>> No.. but they do on RHEL and today's rawhide is tomorrow's RHEL... >> >> But Steve, they will not simply do a yum upgrade on their EL5 boxes to >> upgrade to EL6... > Agreed... And I'll concede moving from one RHEL release to another > RHEL release is a good time to make people recompile their code > esp for security issues... and their code should not compile if > there is a security issue... But thats not the case here! > > My code compile and then aborted... and even worse I was able > to avoid the abort without fixing the security hole.. so the > abort was basically meaningless... imo... > > So I guess what I'm saying, if you can't catch the security issue > and fail the compilation, don't abort the process at run time. > Issue a warning instead... Let the developers decide how > grievous the problem, not glibc... Most developers I know, don't worry about >warnings<, but do if their code aborts. If a developer then doesn't worry about the real (security) problem, but only about the abort itself and just workaround that - it's simply a fault... The other option? stderr "FIX YOUR OPEN :-P"; sleep 600. :-) If you compile the whole Fedora tree, how many warnings will you see? How many warnings are about 'better use mkstemp' - for security reasons... If you don't abort you'll not catch the developers attention... It's too bad, but true... Don't want to step on dev's toes of course - it's for sure not true for *all* developers! -of From SteveD at redhat.com Thu Aug 16 15:08:34 2007 From: SteveD at redhat.com (Steve Dickson) Date: Thu, 16 Aug 2007 11:08:34 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <20070816144617.GB2063@devserv.devel.redhat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4605B.1000407@RedHat.com> <20070816144617.GB2063@devserv.devel.redhat.com> Message-ID: <46C46872.5090005@RedHat.com> Jakub Jelinek wrote: > No. But if you want to make sure packages you built successfully > against glibc-2.6.90-* or later don't die at runtime for these errors, > it is pretty easy to just check all calls to __open{,at}{,64}_2 > functions (i.e. calls which don't pass mode argument to open* > and it is not clear whether O_CREAT is or is not used at compile time), > they will be pretty rare and in each case you can study the code to > determine if the passed flags can contain O_CREAT or not. If they can, > you must supply the mode argument, if it can't, you are ok. How about instead of aborting the process... just fail the open call with some like EINVAL? Would that accomplish the exact same thing? *Anything* is better than having glibc calling abort()... imho... steved. From tcallawa at redhat.com Thu Aug 16 15:06:00 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 16 Aug 2007 11:06:00 -0400 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <1187276886.27768.45.camel@localhost.localdomain> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <46C44976.7030208@gmail.com> <1187272054.3439.109.camel@dhcp83-165.boston.redhat.com> <200708161634.54496.opensource@till.name> <20070816104325.749655a1@mentok.boston.redhat.com> <1187276398.27768.43.camel@localhost.localdomain> <1187276324.3439.133.camel@dhcp83-165.boston.redhat.com> <1187276886.27768.45.camel@localhost.localdomain> Message-ID: <1187276760.3439.142.camel@dhcp83-165.boston.redhat.com> On Thu, 2007-08-16 at 11:08 -0400, Simo Sorce wrote: > On Thu, 2007-08-16 at 10:58 -0400, Tom "spot" Callaway wrote: > > On Thu, 2007-08-16 at 10:59 -0400, Simo Sorce wrote: > > > > /me imagines an angry author shouting at C violation by Fedora because > > > we mark something GPL+ instead of GPLv2+ or GPLv3+ > > > > Agreed. Asking upstream is the best way to resolve that case. > > > > However, we're not liable for any mistaken tagging of the License in our > > package, because the License: tag isn't legally binding. > > Yeah in fact I said shouting not taking legal action :-) Shouting I'm not worried about. People shout at me all day long. ;) ~spot From oliver at linux-kernel.at Thu Aug 16 15:11:13 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 16 Aug 2007 17:11:13 +0200 Subject: The open() system call in f8 really broken... In-Reply-To: <46C46872.5090005@RedHat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4605B.1000407@RedHat.com> <20070816144617.GB2063@devserv.devel.redhat.com> <46C46872.5090005@RedHat.com> Message-ID: <46C46911.4010304@linux-kernel.at> On 08/16/2007 05:08 PM, Steve Dickson wrote: > Jakub Jelinek wrote: >> No. But if you want to make sure packages you built successfully >> against glibc-2.6.90-* or later don't die at runtime for these errors, >> it is pretty easy to just check all calls to __open{,at}{,64}_2 >> functions (i.e. calls which don't pass mode argument to open* >> and it is not clear whether O_CREAT is or is not used at compile time), >> they will be pretty rare and in each case you can study the code to >> determine if the passed flags can contain O_CREAT or not. If they can, >> you must supply the mode argument, if it can't, you are ok. > How about instead of aborting the process... just fail the open call > with some like EINVAL? Would that accomplish the exact same thing? > > *Anything* is better than having glibc calling abort()... imho... Wouldn't most programs - I can think of some big commercial DB - then abort as well? -of From SteveD at redhat.com Thu Aug 16 15:16:54 2007 From: SteveD at redhat.com (Steve Dickson) Date: Thu, 16 Aug 2007 11:16:54 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <46C4685F.8080601@linux-kernel.at> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4605B.1000407@RedHat.com> <46C461C6.5080302@linux-kernel.at> <46C46558.1000905@RedHat.com> <46C4685F.8080601@linux-kernel.at> Message-ID: <46C46A66.8060300@RedHat.com> Oliver Falk wrote: > Most developers I know, don't worry about >warnings<, but do if their > code aborts. If a developer then doesn't worry about the real (security) > problem, but only about the abort itself and just workaround that - it's > simply a fault... The other option? stderr "FIX YOUR OPEN :-P"; sleep > 600. :-) > > If you compile the whole Fedora tree, how many warnings will you see? > How many warnings are about 'better use mkstemp' - for security > reasons... If you don't abort you'll not catch the developers > attention... It's too bad, but true... Don't want to step on dev's toes > of course - it's for sure not true for *all* developers! I was talking about runtime warnings... Really nasty looking messages so they couldn't be ignored... steved. From tjanouse at redhat.com Thu Aug 16 15:19:36 2007 From: tjanouse at redhat.com (Tomas Janousek) Date: Thu, 16 Aug 2007 17:19:36 +0200 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <20070816102501.5bcd7777@mentok.boston.redhat.com> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <46C3DCA5.9080909@kobold.org> <46C3DF4B.9040105@hhs.nl> <46C44976.7030208@gmail.com> <1187272054.3439.109.camel@dhcp83-165.boston.redhat.com> <20070816140600.GA23010@redhat.com> <20070816102501.5bcd7777@mentok.boston.redhat.com> Message-ID: <20070816151936.GA25173@redhat.com> Hello, On Thu, Aug 16, 2007 at 10:25:01AM -0400, Jesse Keating wrote: > Tomas Janousek wrote: > > > If COPYING does not signal licensing intent, why "any version of the > > GPL", why not "unknown license, if any" ? > > An unmodified COPYING file from FSF contains: > > "If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation." Yes, of course, but does The Law say that anybody should actually look at the contents of the COPYING file and assume that the program is licensed in terms of that license, even if not mentiened anywhere? What I'm trying to say is that if The Program does not mention what license it is being licensed in *at all*, does it really mean it's GPL? -- TJ. (Brno, CZ), BaseOS, Red Hat From SteveD at redhat.com Thu Aug 16 15:20:55 2007 From: SteveD at redhat.com (Steve Dickson) Date: Thu, 16 Aug 2007 11:20:55 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <46C46911.4010304@linux-kernel.at> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4605B.1000407@RedHat.com> <20070816144617.GB2063@devserv.devel.redhat.com> <46C46872.5090005@RedHat.com> <46C46911.4010304@linux-kernel.at> Message-ID: <46C46B57.9090500@RedHat.com> Oliver Falk wrote: >> *Anything* is better than having glibc calling abort()... imho... > > Wouldn't most programs - I can think of some big commercial DB - then > abort as well? Letting commercial DB abort is much different than having glibc abort They are making the decision on what to do, not glibc. Leaving those types of decisions in the handles of the apps is much better than having glibc playing God.. imho... steved. From jkeating at redhat.com Thu Aug 16 15:23:56 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 16 Aug 2007 11:23:56 -0400 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <20070816151936.GA25173@redhat.com> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <46C3DCA5.9080909@kobold.org> <46C3DF4B.9040105@hhs.nl> <46C44976.7030208@gmail.com> <1187272054.3439.109.camel@dhcp83-165.boston.redhat.com> <20070816140600.GA23010@redhat.com> <20070816102501.5bcd7777@mentok.boston.redhat.com> <20070816151936.GA25173@redhat.com> Message-ID: <20070816112356.603905ab@mentok.boston.redhat.com> On Thu, 16 Aug 2007 17:19:36 +0200 Tomas Janousek wrote: > What I'm trying to say is that if The Program does not mention what > license it is being licensed in *at all*, does it really mean it's > GPL? Only if the COPYING file unmodified exists along side it. If there is no mention of license, and there is no COPYING file, or no other such documentation that would give a hint as to what the license of the software is, it would be unlicensed, and we should stay away from it until the author(s) apply some sort of license. We can helpfully suggest a few, like the wtfpl... -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From oliver at linux-kernel.at Thu Aug 16 15:24:31 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 16 Aug 2007 17:24:31 +0200 Subject: The open() system call in f8 really broken... In-Reply-To: <46C46A66.8060300@RedHat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4605B.1000407@RedHat.com> <46C461C6.5080302@linux-kernel.at> <46C46558.1000905@RedHat.com> <46C4685F.8080601@linux-kernel.at> <46C46A66.8060300@RedHat.com> Message-ID: <46C46C2F.5040701@linux-kernel.at> On 08/16/2007 05:16 PM, Steve Dickson wrote: > Oliver Falk wrote: >> Most developers I know, don't worry about >warnings<, but do if their >> code aborts. If a developer then doesn't worry about the real (security) >> problem, but only about the abort itself and just workaround that - it's >> simply a fault... The other option? stderr "FIX YOUR OPEN :-P"; sleep >> 600. :-) >> >> If you compile the whole Fedora tree, how many warnings will you see? >> How many warnings are about 'better use mkstemp' - for security >> reasons... If you don't abort you'll not catch the developers >> attention... It's too bad, but true... Don't want to step on dev's toes >> of course - it's for sure not true for *all* developers! > I was talking about runtime warnings... Really nasty looking messages > so they couldn't be ignored... Oh well: [of at pils ~]# banner nasty warning # # # ##### ####### # # ## # # # # # # # # # # # # # # # # # # # # # # ##### # # # # # ####### # # # # ## # # # # # # # # # # ##### # # # # # ###### # # ### # # ##### # # # # # # # ## # # ## # # # # # # # # # # # # # # # # # # # # # # # ###### # # # # # # # # #### # # # ####### # # # # # # # # # # # # # # # # # # # ## # # ## # # ## ## # # # # # # ### # # ##### Yes, Steve I know what you meant - but I'm not sure if it will help - especially GUI apps, where you wouldn't see the stderr... Many apps on my desktop JustWork(tm), but in background they spot some ugly messages... -of From jakub at redhat.com Thu Aug 16 15:27:29 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 16 Aug 2007 11:27:29 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <46C46A66.8060300@RedHat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4605B.1000407@RedHat.com> <46C461C6.5080302@linux-kernel.at> <46C46558.1000905@RedHat.com> <46C4685F.8080601@linux-kernel.at> <46C46A66.8060300@RedHat.com> Message-ID: <20070816152729.GD2063@devserv.devel.redhat.com> On Thu, Aug 16, 2007 at 11:16:54AM -0400, Steve Dickson wrote: > Oliver Falk wrote: > >Most developers I know, don't worry about >warnings<, but do if their > >code aborts. If a developer then doesn't worry about the real (security) > >problem, but only about the abort itself and just workaround that - it's > >simply a fault... The other option? stderr "FIX YOUR OPEN :-P"; sleep > >600. :-) > > > >If you compile the whole Fedora tree, how many warnings will you see? > >How many warnings are about 'better use mkstemp' - for security > >reasons... If you don't abort you'll not catch the developers > >attention... It's too bad, but true... Don't want to step on dev's toes > >of course - it's for sure not true for *all* developers! > I was talking about runtime warnings... Really nasty looking messages > so they couldn't be ignored... Even a runtime warning is a wrong thing to do, aborting immediately is the only sane thing. If you let it through, it can create a file with random mode. Say if a root process creates a file with 4777 perms, do you really want to risk that while that process is scheduled away somebody copies a shell into that file and runs it? Jakub From oliver at linux-kernel.at Thu Aug 16 15:31:02 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 16 Aug 2007 17:31:02 +0200 Subject: The open() system call in f8 really broken... In-Reply-To: <46C46B57.9090500@RedHat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4605B.1000407@RedHat.com> <20070816144617.GB2063@devserv.devel.redhat.com> <46C46872.5090005@RedHat.com> <46C46911.4010304@linux-kernel.at> <46C46B57.9090500@RedHat.com> Message-ID: <46C46DB6.4030608@linux-kernel.at> On 08/16/2007 05:20 PM, Steve Dickson wrote: > Oliver Falk wrote: >>> *Anything* is better than having glibc calling abort()... imho... >> >> Wouldn't most programs - I can think of some big commercial DB - then >> abort as well? > Letting commercial DB abort is much different than having glibc abort > They are making the decision on what to do, not glibc. Leaving those > types of decisions in the handles of the apps is much better than > having glibc playing God.. imho... In both cases the process would no longer run... And glibc is god when it comes to open and glibc's god is kernel. :-P -of From sundaram at fedoraproject.org Thu Aug 16 15:29:56 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 16 Aug 2007 20:59:56 +0530 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <44153.65.192.24.164.1187270929.squirrel@mail.jcomserv.net> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <44153.65.192.24.164.1187270929.squirrel@mail.jcomserv.net> Message-ID: <46C46D74.6020704@fedoraproject.org> Jon Ciesla wrote: > > I may have missed this, if so, my apologies, but: > > A. Do we need to update all branches, or only devel? > All > B. Do we need to rebuild for any branches? No Rahul From SteveD at redhat.com Thu Aug 16 15:38:21 2007 From: SteveD at redhat.com (Steve Dickson) Date: Thu, 16 Aug 2007 11:38:21 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <20070816152729.GD2063@devserv.devel.redhat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4605B.1000407@RedHat.com> <46C461C6.5080302@linux-kernel.at> <46C46558.1000905@RedHat.com> <46C4685F.8080601@linux-kernel.at> <46C46A66.8060300@RedHat.com> <20070816152729.GD2063@devserv.devel.redhat.com> Message-ID: <46C46F6D.8040601@RedHat.com> Jakub Jelinek wrote: > Even a runtime warning is a wrong thing to do, aborting immediately is the > only sane thing. I guess I have different definition of sanity... 8-) > If you let it through, it can create a file with random mode. Say if a root > process creates a file with 4777 perms, do you really want to risk that > while that process is scheduled away somebody copies a shell into that file > and runs it? Again.. just fail the open and put the decision of what to do in the hands of the app... where it belongs... steved. From sgrubb at redhat.com Thu Aug 16 15:38:33 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Thu, 16 Aug 2007 11:38:33 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <20070816152729.GD2063@devserv.devel.redhat.com> References: <46C3A0AA.7090106@RedHat.com> <46C46A66.8060300@RedHat.com> <20070816152729.GD2063@devserv.devel.redhat.com> Message-ID: <200708161138.33994.sgrubb@redhat.com> On Thursday 16 August 2007 11:27:29 Jakub Jelinek wrote: > > >If you compile the whole Fedora tree, how many warnings will you see? > > >How many warnings are about 'better use mkstemp' - for security > > >reasons... If you don't abort you'll not catch the developers > > >attention... It's too bad, but true... Don't want to step on dev's toes > > >of course - it's for sure not true for *all* developers! > > > > I was talking about runtime warnings... Really nasty looking messages > > so they couldn't be ignored... > > Even a runtime warning is a wrong thing to do, aborting immediately is the > only sane thing. +1 > If you let it through, it can create a file with random mode. ?Say if a > root process creates a file with 4777 perms, do you really want to risk > that while that process is scheduled away somebody copies a shell into that > file and runs it? SE Linux probably won't help here since users are unconfined in targeted policy (unless you did some tweeking with the roles). So, we need another mechanism to prevent the general problem. I'd also like to remind people that a few releases ago we had buffer overflow problems. Now, most of those are cleaned up. This is just a temporary problem until we clean things up. This is what rawhide is for. -Steve From overholt at redhat.com Thu Aug 16 15:43:49 2007 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 16 Aug 2007 11:43:49 -0400 Subject: FeatureEclipse33 Status In-Reply-To: <46C2020C.4050304@gmail.com> References: <1187112770.11441.17.camel@localhost.localdomain> <46C2020C.4050304@gmail.com> Message-ID: <1187279029.19623.17.camel@localhost.localdomain> On Tue, 2007-08-14 at 21:27 +0200, Alphonse Van Assche wrote: > Andrew Overholt a ?crit : > > quickrex (Alphonse Van Assche) > > - things work with 3.3, right, Alphonse? > Yes, I have tested it with the eclipse version in rawhide and it work > like expect. Great, thanks. > > specfile editor (Alphonse Van Assche ... yes, I'm perhaps jumping the > > gun a bit here ;) > > - are we good to get this in by test2, Alphonse? > :) I think, I'm waiting the update of the changelog plugin (2.4.1 or so) > because of namespaces incompatibility between the current version > (2.3.4) and the specfile editor. Yeah, I'm trying to get that sorted out. You should see it hit rawhide in the next day or so. > Btw, I have just finished packaging Remote System Explorer (RSE) > plugins, I think that there isn't many work to do on it to be able to > get it right for test2. Sweet. Andrew -------------- 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 mitr at redhat.com Thu Aug 16 15:45:14 2007 From: mitr at redhat.com (Miloslav Trmac) Date: Thu, 16 Aug 2007 17:45:14 +0200 Subject: The open() system call in f8 really broken... In-Reply-To: <46C46F6D.8040601@RedHat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4605B.1000407@RedHat.com> <46C461C6.5080302@linux-kernel.at> <46C46558.1000905@RedHat.com> <46C4685F.8080601@linux-kernel.at> <46C46A66.8060300@RedHat.com> <20070816152729.GD2063@devserv.devel.redhat.com> <46C46F6D.8040601@RedHat.com> Message-ID: <46C4710A.6080008@redhat.com> Steve Dickson napsal(a): > Again.. just fail the open and put the decision of what to do in the > hands of the app... where it belongs... The application has already _decided_ to crash by using invalid code. If the code is invalid, how can you expect the application currently has error handling that _correctly_ handles the case of invalid open () invocation? There is no EBACKTOSCHOOL in . Mirek From ssorce at redhat.com Thu Aug 16 15:54:14 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 16 Aug 2007 11:54:14 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <46C46B57.9090500@RedHat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4605B.1000407@RedHat.com> <20070816144617.GB2063@devserv.devel.redhat.com> <46C46872.5090005@RedHat.com> <46C46911.4010304@linux-kernel.at> <46C46B57.9090500@RedHat.com> Message-ID: <1187279654.27768.51.camel@localhost.localdomain> On Thu, 2007-08-16 at 11:20 -0400, Steve Dickson wrote: > Oliver Falk wrote: > >> *Anything* is better than having glibc calling abort()... imho... > > > > Wouldn't most programs - I can think of some big commercial DB - then > > abort as well? > Letting commercial DB abort is much different than having glibc abort > They are making the decision on what to do, not glibc. Leaving those > types of decisions in the handles of the apps is much better than > having glibc playing God.. imho... +1 not that I am a big fan of proprietary software (not at all), but aborting a DB (or any other software that manages complex structures) with the risk of corrupting the DB is definitely WRONG. Simo. From oliver at linux-kernel.at Thu Aug 16 15:58:04 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 16 Aug 2007 17:58:04 +0200 Subject: The open() system call in f8 really broken... In-Reply-To: <1187279654.27768.51.camel@localhost.localdomain> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4605B.1000407@RedHat.com> <20070816144617.GB2063@devserv.devel.redhat.com> <46C46872.5090005@RedHat.com> <46C46911.4010304@linux-kernel.at> <46C46B57.9090500@RedHat.com> <1187279654.27768.51.camel@localhost.localdomain> Message-ID: <46C4740C.8020307@linux-kernel.at> On 08/16/2007 05:54 PM, Simo Sorce wrote: > On Thu, 2007-08-16 at 11:20 -0400, Steve Dickson wrote: >> Oliver Falk wrote: >>>> *Anything* is better than having glibc calling abort()... imho... >>> Wouldn't most programs - I can think of some big commercial DB - then >>> abort as well? >> Letting commercial DB abort is much different than having glibc abort >> They are making the decision on what to do, not glibc. Leaving those >> types of decisions in the handles of the apps is much better than >> having glibc playing God.. imho... > > +1 not that I am a big fan of proprietary software (not at all), but > aborting a DB (or any other software that manages complex structures) > with the risk of corrupting the DB is definitely WRONG. I'm also not a big fan... But if you run proprietary software it's usually supported under specific distributions. And the vendor will hit that bug and will not support that distro until they have fixed the code. Also, as I already mentioned. You don't get EL6 (or whatever), copy your software to the new machine and take it into production... You'll usually test your software first, don't you? -of From SteveD at redhat.com Thu Aug 16 15:59:22 2007 From: SteveD at redhat.com (Steve Dickson) Date: Thu, 16 Aug 2007 11:59:22 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <46C4710A.6080008@redhat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4605B.1000407@RedHat.com> <46C461C6.5080302@linux-kernel.at> <46C46558.1000905@RedHat.com> <46C4685F.8080601@linux-kernel.at> <46C46A66.8060300@RedHat.com> <20070816152729.GD2063@devserv.devel.redhat.com> <46C46F6D.8040601@RedHat.com> <46C4710A.6080008@redhat.com> Message-ID: <46C4745A.80304@RedHat.com> Miloslav Trmac wrote: > Steve Dickson napsal(a): >> Again.. just fail the open and put the decision of what to do in the >> hands of the app... where it belongs... > The application has already _decided_ to crash by using invalid code. No... glibc made the decision... without give the app any warning or time to clean up... thats wrong.. imho... > > If the code is invalid, how can you expect the application currently has > error handling that _correctly_ handles the case of invalid open () > invocation? There is no EBACKTOSCHOOL in . Its not glibc's place (or anybody else) to make such judgments on the ability of the application or the developer... steved. From walters at redhat.com Thu Aug 16 16:00:29 2007 From: walters at redhat.com (Colin Walters) Date: Thu, 16 Aug 2007 12:00:29 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <46C3A604.3080002@RedHat.com> References: <46C3A0AA.7090106@RedHat.com> <200708152100.35912.sgrubb@redhat.com> <46C3A604.3080002@RedHat.com> Message-ID: > > exportfs does not write setuid files, but it can cause a lost > of thousand of dollars when a entire development department > is idle because they can't log in because we decided to change > the meaning of open()... it just does not make sense to me... Except that this error would have been caught way before it got to any kind of production environment because there's a test suite for it...right? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakub at redhat.com Thu Aug 16 16:06:27 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 16 Aug 2007 12:06:27 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <46C4740C.8020307@linux-kernel.at> References: <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4605B.1000407@RedHat.com> <20070816144617.GB2063@devserv.devel.redhat.com> <46C46872.5090005@RedHat.com> <46C46911.4010304@linux-kernel.at> <46C46B57.9090500@RedHat.com> <1187279654.27768.51.camel@localhost.localdomain> <46C4740C.8020307@linux-kernel.at> Message-ID: <20070816160626.GE2063@devserv.devel.redhat.com> On Thu, Aug 16, 2007 at 05:58:04PM +0200, Oliver Falk wrote: > On 08/16/2007 05:54 PM, Simo Sorce wrote: > Also, as I already mentioned. You don't get EL6 (or whatever), copy your > software to the new machine and take it into production... You'll > usually test your software first, don't you? Well, you would need to recompile your software on EL6, F8, ... (the open checking only affects newly recompiled code and only that where you ask for the security checks by using -D_FORTIFY_SOURCE{,=2}) and don't bother testing what you compiled. Jakub From ssorce at redhat.com Thu Aug 16 16:07:27 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 16 Aug 2007 12:07:27 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <46C4740C.8020307@linux-kernel.at> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4605B.1000407@RedHat.com> <20070816144617.GB2063@devserv.devel.redhat.com> <46C46872.5090005@RedHat.com> <46C46911.4010304@linux-kernel.at> <46C46B57.9090500@RedHat.com> <1187279654.27768.51.camel@localhost.localdomain> <46C4740C.8020307@linux-kernel.at> Message-ID: <1187280447.27768.55.camel@localhost.localdomain> On Thu, 2007-08-16 at 17:58 +0200, Oliver Falk wrote: > On 08/16/2007 05:54 PM, Simo Sorce wrote: > > On Thu, 2007-08-16 at 11:20 -0400, Steve Dickson wrote: > >> Oliver Falk wrote: > >>>> *Anything* is better than having glibc calling abort()... imho... > >>> Wouldn't most programs - I can think of some big commercial DB - then > >>> abort as well? > >> Letting commercial DB abort is much different than having glibc abort > >> They are making the decision on what to do, not glibc. Leaving those > >> types of decisions in the handles of the apps is much better than > >> having glibc playing God.. imho... > > > > +1 not that I am a big fan of proprietary software (not at all), but > > aborting a DB (or any other software that manages complex structures) > > with the risk of corrupting the DB is definitely WRONG. > > I'm also not a big fan... But if you run proprietary software it's > usually supported under specific distributions. And the vendor will hit > that bug and will not support that distro until they have fixed the code. True, if that is a compile time error, but this is runtime, and is something that may happen just maybe in a very little exercised code path like an exotic error handling routine. > Also, as I already mentioned. You don't get EL6 (or whatever), copy your > software to the new machine and take it into production... You'll > usually test your software first, don't you? Fair 'nuf. Simo. From walters at redhat.com Thu Aug 16 16:33:47 2007 From: walters at redhat.com (Colin Walters) Date: Thu, 16 Aug 2007 12:33:47 -0400 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> Message-ID: On 8/15/07, Tom spot Callaway wrote: > > Got your attention? Good. > > GPL and LGPL are NOT acceptable License tags for Fedora. You cannot > simply use "GPL" or "LGPL" as a license tag anymore. > > You have to use one of the following tags: > > GPL+, GPLv2, GPLv2+, GPLv3, GPLv3+, LGPLv2, LGPLv2+, LGPLv3, LGPLv3+ I would like to repeat again that I believe this problem is ~90% automatable, and in doing so would be far more likely to catch not just current problems, but problems introduced in the future. -------------- next part -------------- An HTML attachment was scrubbed... URL: From skvidal at fedoraproject.org Thu Aug 16 16:57:35 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 16 Aug 2007 12:57:35 -0400 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> Message-ID: <1187283455.13210.28.camel@cutter> On Thu, 2007-08-16 at 12:33 -0400, Colin Walters wrote: > On 8/15/07, Tom spot Callaway wrote: > Got your attention? Good. > > GPL and LGPL are NOT acceptable License tags for Fedora. You > cannot > simply use "GPL" or "LGPL" as a license tag anymore. > > You have to use one of the following tags: > > GPL+, GPLv2, GPLv2+, GPLv3, GPLv3+, LGPLv2, LGPLv2+, LGPLv3, > LGPLv3+ > > I would like to repeat again that I believe this problem is ~90% > automatable, and in doing so would be far more likely to catch not > just current problems, but problems introduced in the future. Colin, This is with all sincerity and not at all meant to be dismissive: If you have the time to automate this I think we'll be glad to listen. Right now a lot of folks are having trouble parsing the version differences with a purely human parser - and human parsers for regular expressions and variable-strings are typically much better than computer-based ones, however, if you've got a solution to this, please let us know. -sv From alan at redhat.com Thu Aug 16 17:04:56 2007 From: alan at redhat.com (Alan Cox) Date: Thu, 16 Aug 2007 13:04:56 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <46C4745A.80304@RedHat.com> References: <20070816142437.GA2063@devserv.devel.redhat.com> <46C4605B.1000407@RedHat.com> <46C461C6.5080302@linux-kernel.at> <46C46558.1000905@RedHat.com> <46C4685F.8080601@linux-kernel.at> <46C46A66.8060300@RedHat.com> <20070816152729.GD2063@devserv.devel.redhat.com> <46C46F6D.8040601@RedHat.com> <46C4710A.6080008@redhat.com> <46C4745A.80304@RedHat.com> Message-ID: <20070816170456.GD26771@devserv.devel.redhat.com> On Thu, Aug 16, 2007 at 11:59:22AM -0400, Steve Dickson wrote: > >The application has already _decided_ to crash by using invalid code. > No... glibc made the decision... without give the app any warning > or time to clean up... thats wrong.. imho... I think the glibc folks are right, providing they don't suddenely turn this on for a RHEL5 update. > Its not glibc's place (or anybody else) to make such judgments > on the ability of the application or the developer... The alternative is telepathically deducing the authors intent. Thats even harder. Better it fails in rawhide and FC devel and people fix stuff. For RHEL people will get zapped in RHEL6 betas and soon fix any From SteveD at redhat.com Thu Aug 16 17:13:42 2007 From: SteveD at redhat.com (Steve Dickson) Date: Thu, 16 Aug 2007 13:13:42 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: References: <46C3A0AA.7090106@RedHat.com> <200708152100.35912.sgrubb@redhat.com> <46C3A604.3080002@RedHat.com> Message-ID: <46C485C6.4090904@RedHat.com> Colin Walters wrote: > > > exportfs does not write setuid files, but it can cause a lost > of thousand of dollars when a entire development department > is idle because they can't log in because we decided to change > the meaning of open()... it just does not make sense to me... > > > Except that this error would have been caught way before it got to any > kind of production environment because there's a test suite for it...right? You know what they say about assumptions... ;-) Plus can one realistically test every single open in every single application that runs in production? There is no question in my mind that glibc calling abort will end bring down a very critical application which in turn will bring down an entire production environment... Its only a matter of time... imho... I bet the Open Solaris people are loving we are doing this... :-\ steved. From oliver at linux-kernel.at Thu Aug 16 17:12:17 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 16 Aug 2007 19:12:17 +0200 Subject: The open() system call in f8 really broken... In-Reply-To: <20070816160626.GE2063@devserv.devel.redhat.com> References: <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4605B.1000407@RedHat.com> <20070816144617.GB2063@devserv.devel.redhat.com> <46C46872.5090005@RedHat.com> <46C46911.4010304@linux-kernel.at> <46C46B57.9090500@RedHat.com> <1187279654.27768.51.camel@localhost.localdomain> <46C4740C.8020307@linux-kernel.at> <20070816160626.GE2063@devserv.devel.redhat.com> Message-ID: <46C48571.6040000@linux-kernel.at> Jakub Jelinek schrieb: > On Thu, Aug 16, 2007 at 05:58:04PM +0200, Oliver Falk wrote: >> On 08/16/2007 05:54 PM, Simo Sorce wrote: >> Also, as I already mentioned. You don't get EL6 (or whatever), copy your >> software to the new machine and take it into production... You'll >> usually test your software first, don't you? > > Well, you would need to recompile your software on EL6, F8, ... (the open > checking only affects newly recompiled code and only that where you ask > for the security checks by using -D_FORTIFY_SOURCE{,=2}) and don't bother > testing what you compiled. Oh well. I got the impression, it will also affect old code... Hm. Then the problem isn't worse... It's just bad :-) Nobody will recompile his $$$$ software on a newly installed distribution and not testing it.... glibc's just right POINT. -of From SteveD at redhat.com Thu Aug 16 17:17:05 2007 From: SteveD at redhat.com (Steve Dickson) Date: Thu, 16 Aug 2007 13:17:05 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <20070816170456.GD26771@devserv.devel.redhat.com> References: <20070816142437.GA2063@devserv.devel.redhat.com> <46C4605B.1000407@RedHat.com> <46C461C6.5080302@linux-kernel.at> <46C46558.1000905@RedHat.com> <46C4685F.8080601@linux-kernel.at> <46C46A66.8060300@RedHat.com> <20070816152729.GD2063@devserv.devel.redhat.com> <46C46F6D.8040601@RedHat.com> <46C4710A.6080008@redhat.com> <46C4745A.80304@RedHat.com> <20070816170456.GD26771@devserv.devel.redhat.com> Message-ID: <46C48691.60007@RedHat.com> Alan Cox wrote: >> Its not glibc's place (or anybody else) to make such judgments >> on the ability of the application or the developer... > > The alternative is telepathically deducing the authors intent. Thats even > harder. Better it fails in rawhide and FC devel and people fix stuff. For > RHEL people will get zapped in RHEL6 betas and soon fix any This is assuming every open will be tested in the beta... which I don't thinks is a wise assumption... esp when you consider error paths... steved. From oliver at linux-kernel.at Thu Aug 16 17:15:27 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 16 Aug 2007 19:15:27 +0200 Subject: The open() system call in f8 really broken... In-Reply-To: <46C485C6.4090904@RedHat.com> References: <46C3A0AA.7090106@RedHat.com> <200708152100.35912.sgrubb@redhat.com> <46C3A604.3080002@RedHat.com> <46C485C6.4090904@RedHat.com> Message-ID: <46C4862F.1040807@linux-kernel.at> Steve Dickson schrieb: > > > Colin Walters wrote: >> >> >> exportfs does not write setuid files, but it can cause a lost >> of thousand of dollars when a entire development department >> is idle because they can't log in because we decided to change >> the meaning of open()... it just does not make sense to me... >> >> >> Except that this error would have been caught way before it got to any >> kind of production environment because there's a test suite for >> it...right? > You know what they say about assumptions... ;-) > > Plus can one realistically test every single open in every single > application that runs in production? There is no question in my > mind that glibc calling abort will end bring down a very critical > application which in turn will bring down an entire production > environment... Its only a matter of time... imho... Bugs in the apps will be found, by abort() sooner than by warning out... And I don't expect any critical production system to go down over night.... There where other problems (I can remeber filesystem corruptions in older release) that where far more worse! > > I bet the Open Solaris people are loving we are doing this... :-\ > Open Solaris my a........ :-P -of From tcallawa at redhat.com Thu Aug 16 17:14:02 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 16 Aug 2007 13:14:02 -0400 Subject: Licensing FAQ Message-ID: <1187284442.3439.159.camel@dhcp83-165.boston.redhat.com> I've started a FAQ, to hopefully clarify some of the common licensing questions people are asking me. You can find it here: http://fedoraproject.org/wiki/Licensing/FAQ Thanks, ~spot From jspaleta at gmail.com Thu Aug 16 17:26:50 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 16 Aug 2007 09:26:50 -0800 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <1187276398.27768.43.camel@localhost.localdomain> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <46C44976.7030208@gmail.com> <1187272054.3439.109.camel@dhcp83-165.boston.redhat.com> <200708161634.54496.opensource@till.name> <20070816104325.749655a1@mentok.boston.redhat.com> <1187276398.27768.43.camel@localhost.localdomain> Message-ID: <604aa7910708161026h28271922v1708ddb0fa0fd54e@mail.gmail.com> On 8/16/07, Simo Sorce wrote: > /me imagines an angry author shouting at C violation by Fedora because > we mark something GPL+ instead of GPLv2+ or GPLv3+ Any upstream that would get in a huff over this should already be at our door with pitchforks and torches in hand for just using the string "GPL" in the past. As we clean it up I have no doubt we will get some of them wrong, but thats OKAY. I welcome as much communication as necessary with upstream developers to clarify exactly what variation of GPL is being used in more complicated cases. -jef From SteveD at redhat.com Thu Aug 16 17:32:15 2007 From: SteveD at redhat.com (Steve Dickson) Date: Thu, 16 Aug 2007 13:32:15 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <46C4862F.1040807@linux-kernel.at> References: <46C3A0AA.7090106@RedHat.com> <200708152100.35912.sgrubb@redhat.com> <46C3A604.3080002@RedHat.com> <46C485C6.4090904@RedHat.com> <46C4862F.1040807@linux-kernel.at> Message-ID: <46C48A1F.5090901@RedHat.com> Oliver Falk wrote: > > Bugs in the apps will be found, by abort() sooner than by warning out... But won't error out the call do exactly the same thing?? It closes the security hole by stopping the app in its tracks and allow the app to recover... I just don't understand why that is so wrong... Please educate me... > And I don't expect any critical production system to go down over > night.... There where other problems (I can remeber filesystem > corruptions in older release) that where far more worse! yes... and there was no recovery from that... but we just called that a hardware problem... ;-) steved. From ssorce at redhat.com Thu Aug 16 17:39:36 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 16 Aug 2007 13:39:36 -0400 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <604aa7910708161026h28271922v1708ddb0fa0fd54e@mail.gmail.com> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <46C44976.7030208@gmail.com> <1187272054.3439.109.camel@dhcp83-165.boston.redhat.com> <200708161634.54496.opensource@till.name> <20070816104325.749655a1@mentok.boston.redhat.com> <1187276398.27768.43.camel@localhost.localdomain> <604aa7910708161026h28271922v1708ddb0fa0fd54e@mail.gmail.com> Message-ID: <1187285976.27768.71.camel@localhost.localdomain> On Thu, 2007-08-16 at 09:26 -0800, Jeff Spaleta wrote: > On 8/16/07, Simo Sorce wrote: > > /me imagines an angry author shouting at C violation by Fedora because > > we mark something GPL+ instead of GPLv2+ or GPLv3+ > > Any upstream that would get in a huff over this should already be at > our door with pitchforks and torches in hand for just using the string > "GPL" in the past. As we clean it up I have no doubt we will get some > of them wrong, but thats OKAY. I welcome as much communication as > necessary with upstream developers to clarify exactly what variation > of GPL is being used in more complicated cases. This is my wish as well, that's why I just strongly suggest contacting the upstream developers in case of doubt. I suggest nothing else, the current practice as just today amended by Spot is quite sane FWICS. Simo. From jmoyer at redhat.com Thu Aug 16 17:55:24 2007 From: jmoyer at redhat.com (Jeff Moyer) Date: Thu, 16 Aug 2007 13:55:24 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <46C48A1F.5090901@RedHat.com> (Steve Dickson's message of "Thu\, 16 Aug 2007 13\:32\:15 -0400") References: <46C3A0AA.7090106@RedHat.com> <200708152100.35912.sgrubb@redhat.com> <46C3A604.3080002@RedHat.com> <46C485C6.4090904@RedHat.com> <46C4862F.1040807@linux-kernel.at> <46C48A1F.5090901@RedHat.com> Message-ID: Steve Dickson writes: > Oliver Falk wrote: >> >> Bugs in the apps will be found, by abort() sooner than by warning out... > But won't error out the call do exactly the same thing?? It closes > the security hole by stopping the app in its tracks and allow > the app to recover... I just don't understand why that is > so wrong... Please educate me... First, if your application needed to create a file and failed to, what will it do next? Retry? That will fail. Exit? How is this better than an abort with more useful information? Steve, honestly, take a step back. The tools found a bug in your code for you. Celebrate. End the day 15 minutes early and have a beer. That's free work. -Jeff From SteveD at redhat.com Thu Aug 16 18:15:33 2007 From: SteveD at redhat.com (Steve Dickson) Date: Thu, 16 Aug 2007 14:15:33 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: References: <46C3A0AA.7090106@RedHat.com> <200708152100.35912.sgrubb@redhat.com> <46C3A604.3080002@RedHat.com> <46C485C6.4090904@RedHat.com> <46C4862F.1040807@linux-kernel.at> <46C48A1F.5090901@RedHat.com> Message-ID: <46C49445.2050104@RedHat.com> Jeff Moyer wrote: > > First, if your application needed to create a file and failed to, what > will it do next? Retry? That will fail. Exit? How is this > better than an abort with more useful information? This is an uniform judgment as to how an application will do its error recover... System libraries simply can't do that... When a system library detect an error, it should return it to the application to let it handle it! steved. From wolters.liste at gmx.net Thu Aug 16 19:23:53 2007 From: wolters.liste at gmx.net (Roland Wolters) Date: Thu, 16 Aug 2007 21:23:53 +0200 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <200708161303.02241.ville.skytta@iki.fi> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <200708161128.19636.wolters.liste@gmx.net> <200708161303.02241.ville.skytta@iki.fi> Message-ID: <200708162124.00014.wolters.liste@gmx.net> Once upon a time Ville Skytt? wrote: > GPLv2+, I think. > See http://fedoraproject.org/wiki/PackagingDrafts/LicenseClarification > So be it. Thanks for the answer. Roland -- "Wer bin ich, und wenn ja wie viele?" -- Verwirrtheit -------------- 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 zaitcev at redhat.com Thu Aug 16 19:37:46 2007 From: zaitcev at redhat.com (Pete Zaitcev) Date: Thu, 16 Aug 2007 12:37:46 -0700 Subject: The open() system call in f8 really broken... In-Reply-To: <46C3A0AA.7090106@RedHat.com> References: <46C3A0AA.7090106@RedHat.com> Message-ID: <20070816123746.006d0e7e.zaitcev@redhat.com> On Wed, 15 Aug 2007 20:56:10 -0400, Steve Dickson wrote: > *** invalid open64 call: O_CREAT without mode ***: > /home/src/fc/nfs-utils/devel/nfs-utils-1.1.0/utils/exportfs/exportfs > terminated Enabling such checks in Rawhide is the way we do things. For example, I saw applications failing with: ***MEMORY-WARNING***: [3894]: GSlice: g_thread_init() must be called before all other GLib functions; memory corruption due to late invocation of g_thread_init() There is simply nothing unusual or unexpected about it. > - if ((fd = open(fname, readonly? O_RDONLY : (O_RDWR|O_CREAT))) < 0) { > + if ((fd = (open)(fname, readonly? O_RDONLY : (O_RDWR|O_CREAT))) < 0) { Now you're just being unfriendly about it by finding ways to defeat a helpful check instead of adding the missing mode. What point are you trying to prove by doing this? -- Pete From limb at jcomserv.net Thu Aug 16 19:21:17 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 16 Aug 2007 14:21:17 -0500 (CDT) Subject: The open() system call in f8 really broken... In-Reply-To: <20070816123746.006d0e7e.zaitcev@redhat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816123746.006d0e7e.zaitcev@redhat.com> Message-ID: <21438.65.192.24.164.1187292077.squirrel@mail.jcomserv.net> > On Wed, 15 Aug 2007 20:56:10 -0400, Steve Dickson > wrote: > >> *** invalid open64 call: O_CREAT without mode ***: >> /home/src/fc/nfs-utils/devel/nfs-utils-1.1.0/utils/exportfs/exportfs >> terminated > > Enabling such checks in Rawhide is the way we do things. For example, > I saw applications failing with: > > ***MEMORY-WARNING***: [3894]: GSlice: g_thread_init() must be called > before all other GLib functions; memory corruption due to late invocation > of g_thread_init() > > There is simply nothing unusual or unexpected about it. > >> - if ((fd = open(fname, readonly? O_RDONLY : (O_RDWR|O_CREAT))) < 0) { >> + if ((fd = (open)(fname, readonly? O_RDONLY : (O_RDWR|O_CREAT))) < 0) { > > Now you're just being unfriendly about it by finding ways to defeat > a helpful check instead of adding the missing mode. What point are > you trying to prove by doing this? What would the preferred fix look like? I'd like to get this sorted out, as I'd like to send a patch for one of my affected packages upstream. > -- Pete > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- novus ordo absurdum From oliver at linux-kernel.at Thu Aug 16 19:47:35 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 16 Aug 2007 21:47:35 +0200 Subject: The open() system call in f8 really broken... In-Reply-To: <21438.65.192.24.164.1187292077.squirrel@mail.jcomserv.net> References: <46C3A0AA.7090106@RedHat.com> <20070816123746.006d0e7e.zaitcev@redhat.com> <21438.65.192.24.164.1187292077.squirrel@mail.jcomserv.net> Message-ID: <46C4A9D7.4020809@linux-kernel.at> Jon Ciesla schrieb: >> On Wed, 15 Aug 2007 20:56:10 -0400, Steve Dickson >> wrote: >> >>> *** invalid open64 call: O_CREAT without mode ***: >>> /home/src/fc/nfs-utils/devel/nfs-utils-1.1.0/utils/exportfs/exportfs >>> terminated >> Enabling such checks in Rawhide is the way we do things. For example, >> I saw applications failing with: >> >> ***MEMORY-WARNING***: [3894]: GSlice: g_thread_init() must be called >> before all other GLib functions; memory corruption due to late invocation >> of g_thread_init() >> >> There is simply nothing unusual or unexpected about it. >> >>> - if ((fd = open(fname, readonly? O_RDONLY : (O_RDWR|O_CREAT))) < 0) { >>> + if ((fd = (open)(fname, readonly? O_RDONLY : (O_RDWR|O_CREAT))) < 0) { >> Now you're just being unfriendly about it by finding ways to defeat >> a helpful check instead of adding the missing mode. What point are >> you trying to prove by doing this? > > What would the preferred fix look like? I'd like to get this sorted out, > as I'd like to send a patch for one of my affected packages upstream. Preferred? Simply pass a mode - see man 2 open: int open(const char *pathname, int flags, mode_t mode); if ((fd = open(fname, readonly? O_RDONLY : (O_RDWR|O_CREAT), 0022)) < 0) { For example... -of From zaitcev at redhat.com Thu Aug 16 20:02:01 2007 From: zaitcev at redhat.com (Pete Zaitcev) Date: Thu, 16 Aug 2007 13:02:01 -0700 Subject: The open() system call in f8 really broken... In-Reply-To: <21438.65.192.24.164.1187292077.squirrel@mail.jcomserv.net> References: <46C3A0AA.7090106@RedHat.com> <20070816123746.006d0e7e.zaitcev@redhat.com> <21438.65.192.24.164.1187292077.squirrel@mail.jcomserv.net> Message-ID: <20070816130201.17950e19.zaitcev@redhat.com> On Thu, 16 Aug 2007 14:21:17 -0500 (CDT), "Jon Ciesla" wrote: > >> - if ((fd = open(fname, readonly? O_RDONLY : (O_RDWR|O_CREAT))) < 0) { > >> + if ((fd = (open)(fname, readonly? O_RDONLY : (O_RDWR|O_CREAT))) < 0) { > > > > Now you're just being unfriendly about it by finding ways to defeat > > a helpful check instead of adding the missing mode. What point are > > you trying to prove by doing this? > > What would the preferred fix look like? I'd like to get this sorted out, > as I'd like to send a patch for one of my affected packages upstream. I would go for this myself, using Steve's example: - if ((fd = open(fname, readonly? O_RDONLY : (O_RDWR|O_CREAT))) < 0) { + if (readonly) + fd = open(fname, O_RDONLY); + else + fd = open(fname, O_RDWR|O_CREAT, S_IRUSR|S_IWUSR); + if (fd < 0) { But please do what your programmer's sense suggests. You're the master of your code. -- Pete From jakub at redhat.com Thu Aug 16 20:01:36 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 16 Aug 2007 16:01:36 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <21438.65.192.24.164.1187292077.squirrel@mail.jcomserv.net> References: <46C3A0AA.7090106@RedHat.com> <20070816123746.006d0e7e.zaitcev@redhat.com> <21438.65.192.24.164.1187292077.squirrel@mail.jcomserv.net> Message-ID: <20070816200136.GJ2063@devserv.devel.redhat.com> On Thu, Aug 16, 2007 at 02:21:17PM -0500, Jon Ciesla wrote: > > There is simply nothing unusual or unexpected about it. > > > >> - if ((fd = open(fname, readonly? O_RDONLY : (O_RDWR|O_CREAT))) < 0) { > >> + if ((fd = (open)(fname, readonly? O_RDONLY : (O_RDWR|O_CREAT))) < 0) { > > > > Now you're just being unfriendly about it by finding ways to defeat > > a helpful check instead of adding the missing mode. What point are > > you trying to prove by doing this? > > What would the preferred fix look like? I'd like to get this sorted out, > as I'd like to send a patch for one of my affected packages upstream. Supplying a third argument to open, of course. So if ((fd = open(fname, readonly? O_RDONLY : (O_RDWR|O_CREAT), 0644)) < 0) { is the right fix, judging from touch $(DESTDIR)$(statedir)/xtab; chmod 644 $(DESTDIR)$(statedir)/xtab touch $(DESTDIR)$(statedir)/etab; chmod 644 $(DESTDIR)$(statedir)/etab touch $(DESTDIR)$(statedir)/rmtab; chmod 644 $(DESTDIR)$(statedir)/rmtab and xflock being used on xtab/etab/rmtab. Jakub From zaitcev at redhat.com Thu Aug 16 20:06:44 2007 From: zaitcev at redhat.com (Pete Zaitcev) Date: Thu, 16 Aug 2007 13:06:44 -0700 Subject: The open() system call in f8 really broken... In-Reply-To: <46C4A9D7.4020809@linux-kernel.at> References: <46C3A0AA.7090106@RedHat.com> <20070816123746.006d0e7e.zaitcev@redhat.com> <21438.65.192.24.164.1187292077.squirrel@mail.jcomserv.net> <46C4A9D7.4020809@linux-kernel.at> Message-ID: <20070816130644.be738b6f.zaitcev@redhat.com> On Thu, 16 Aug 2007 21:47:35 +0200, Oliver Falk wrote: > if ((fd = open(fname, readonly? O_RDONLY : (O_RDWR|O_CREAT), 0022)) < 0) { This was my first idea, but then I remembered how printk complains about extra arguments for a format. BTW, 022 is an strange mode. It looks like you used the umask. -- Pete From oliver at linux-kernel.at Thu Aug 16 20:02:59 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 16 Aug 2007 22:02:59 +0200 Subject: The open() system call in f8 really broken... In-Reply-To: <20070816200136.GJ2063@devserv.devel.redhat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816123746.006d0e7e.zaitcev@redhat.com> <21438.65.192.24.164.1187292077.squirrel@mail.jcomserv.net> <20070816200136.GJ2063@devserv.devel.redhat.com> Message-ID: <46C4AD73.3000303@linux-kernel.at> Jakub Jelinek schrieb: > On Thu, Aug 16, 2007 at 02:21:17PM -0500, Jon Ciesla wrote: >>> There is simply nothing unusual or unexpected about it. >>> >>>> - if ((fd = open(fname, readonly? O_RDONLY : (O_RDWR|O_CREAT))) < 0) { >>>> + if ((fd = (open)(fname, readonly? O_RDONLY : (O_RDWR|O_CREAT))) < 0) { >>> Now you're just being unfriendly about it by finding ways to defeat >>> a helpful check instead of adding the missing mode. What point are >>> you trying to prove by doing this? >> What would the preferred fix look like? I'd like to get this sorted out, >> as I'd like to send a patch for one of my affected packages upstream. > > Supplying a third argument to open, of course. > So > if ((fd = open(fname, readonly? O_RDONLY : (O_RDWR|O_CREAT), 0644)) < 0) { > is the right fix, judging from > touch $(DESTDIR)$(statedir)/xtab; chmod 644 $(DESTDIR)$(statedir)/xtab > touch $(DESTDIR)$(statedir)/etab; chmod 644 $(DESTDIR)$(statedir)/etab > touch $(DESTDIR)$(statedir)/rmtab; chmod 644 $(DESTDIR)$(statedir)/rmtab > and xflock being used on xtab/etab/rmtab. Well... Jakub does take more time and not simply random numbers like me... :-) -of From davej at redhat.com Thu Aug 16 20:21:38 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 16 Aug 2007 16:21:38 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <46C4685F.8080601@linux-kernel.at> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4605B.1000407@RedHat.com> <46C461C6.5080302@linux-kernel.at> <46C46558.1000905@RedHat.com> <46C4685F.8080601@linux-kernel.at> Message-ID: <20070816202138.GA15542@redhat.com> On Thu, Aug 16, 2007 at 05:08:15PM +0200, Oliver Falk wrote: > If you compile the whole Fedora tree, how many warnings will you see? So I grepped across a make prep'd tree of devel (all 63 gig of it). Here's the fallout.. openmpi/openmpi-1.2.3/orte/runtime/orte_abort.c fd = open(abort_file, O_CREAT); jython/jython-svn-Release_2_2beta1/CPythonLib/test/test_unicode_file.py:f = os.open(TESTFN_ENCODED, os.O_CREAT) perl/perl-5.8.8/t/op/taint.t: eval { sysopen(my $cr, $evil, &O_CREAT) }; proftpd/proftpd-1.3.0a/contrib/mod_rewrite.c: if ((fifo_lockfd = open(fifo_lockname, O_CREAT)) < 0) pwlib/pwlib-1.10.7/configure:sem_t *s = sem_open("test", O_CREAT) pwlib/pwlib-1.10.7/configure.ac: [sem_t *s = sem_open("test", O_CREAT)], python/Python-2.5.1/Lib/test/test_unicode_file.py: f = os.open(filename, os.O_CREAT) python-docs/Python-2.5.1/Lib/test/test_unicode_file.py: f = os.open(filename, os.O_CREAT) xca/xca-0.6.3/_tmp_root/usr/lib/python2.5/test/test_unicode_file.py: f = os.open(filename, os.O_CREAT) Not too bad considering. Dave -- http://www.codemonkey.org.uk From davej at redhat.com Thu Aug 16 20:36:37 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 16 Aug 2007 16:36:37 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <20070816202138.GA15542@redhat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4605B.1000407@RedHat.com> <46C461C6.5080302@linux-kernel.at> <46C46558.1000905@RedHat.com> <46C4685F.8080601@linux-kernel.at> <20070816202138.GA15542@redhat.com> Message-ID: <20070816203637.GA10486@redhat.com> On Thu, Aug 16, 2007 at 04:21:38PM -0400, Dave Jones wrote: > On Thu, Aug 16, 2007 at 05:08:15PM +0200, Oliver Falk wrote: > > > If you compile the whole Fedora tree, how many warnings will you see? > > So I grepped across a make prep'd tree of devel (all 63 gig of it). > Here's the fallout.. > > openmpi/openmpi-1.2.3/orte/runtime/orte_abort.c fd = open(abort_file, O_CREAT); > jython/jython-svn-Release_2_2beta1/CPythonLib/test/test_unicode_file.py:f = os.open(TESTFN_ENCODED, os.O_CREAT) > perl/perl-5.8.8/t/op/taint.t: eval { sysopen(my $cr, $evil, &O_CREAT) }; > proftpd/proftpd-1.3.0a/contrib/mod_rewrite.c: if ((fifo_lockfd = open(fifo_lockname, O_CREAT)) < 0) > pwlib/pwlib-1.10.7/configure:sem_t *s = sem_open("test", O_CREAT) > pwlib/pwlib-1.10.7/configure.ac: [sem_t *s = sem_open("test", O_CREAT)], > python/Python-2.5.1/Lib/test/test_unicode_file.py: f = os.open(filename, os.O_CREAT) > python-docs/Python-2.5.1/Lib/test/test_unicode_file.py: f = os.open(filename, os.O_CREAT) > xca/xca-0.6.3/_tmp_root/usr/lib/python2.5/test/test_unicode_file.py: f = os.open(filename, os.O_CREAT) > > Not too bad considering. Bah, my regexp was imperfect. I'll fix up and rerun. Dave -- http://www.codemonkey.org.uk From SteveD at redhat.com Thu Aug 16 20:36:03 2007 From: SteveD at redhat.com (Steve Dickson) Date: Thu, 16 Aug 2007 16:36:03 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <20070816123746.006d0e7e.zaitcev@redhat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816123746.006d0e7e.zaitcev@redhat.com> Message-ID: <46C4B533.7020604@RedHat.com> Pete Zaitcev wrote: > >> - if ((fd = open(fname, readonly? O_RDONLY : (O_RDWR|O_CREAT))) < 0) { >> + if ((fd = (open)(fname, readonly? O_RDONLY : (O_RDWR|O_CREAT))) < 0) { > > Now you're just being unfriendly about it by finding ways to defeat > a helpful check instead of adding the missing mode. What point are > you trying to prove by doing this? The point I was trying to prove is by simply adding the '()' I could avoid the runtime abort and still have the security hole.... concluding the runtime check is very buggy so this check should never call abort() since it can't be correct 100% of time... steved. From jakub at redhat.com Thu Aug 16 20:38:15 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 16 Aug 2007 16:38:15 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <20070816202138.GA15542@redhat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4605B.1000407@RedHat.com> <46C461C6.5080302@linux-kernel.at> <46C46558.1000905@RedHat.com> <46C4685F.8080601@linux-kernel.at> <20070816202138.GA15542@redhat.com> Message-ID: <20070816203815.GL2063@devserv.devel.redhat.com> On Thu, Aug 16, 2007 at 04:21:38PM -0400, Dave Jones wrote: > On Thu, Aug 16, 2007 at 05:08:15PM +0200, Oliver Falk wrote: > > > If you compile the whole Fedora tree, how many warnings will you see? > > So I grepped across a make prep'd tree of devel (all 63 gig of it). > Here's the fallout.. > > openmpi/openmpi-1.2.3/orte/runtime/orte_abort.c fd = open(abort_file, O_CREAT); > jython/jython-svn-Release_2_2beta1/CPythonLib/test/test_unicode_file.py:f = os.open(TESTFN_ENCODED, os.O_CREAT) > perl/perl-5.8.8/t/op/taint.t: eval { sysopen(my $cr, $evil, &O_CREAT) }; > proftpd/proftpd-1.3.0a/contrib/mod_rewrite.c: if ((fifo_lockfd = open(fifo_lockname, O_CREAT)) < 0) > pwlib/pwlib-1.10.7/configure:sem_t *s = sem_open("test", O_CREAT) > pwlib/pwlib-1.10.7/configure.ac: [sem_t *s = sem_open("test", O_CREAT)], > python/Python-2.5.1/Lib/test/test_unicode_file.py: f = os.open(filename, os.O_CREAT) > python-docs/Python-2.5.1/Lib/test/test_unicode_file.py: f = os.open(filename, os.O_CREAT) > xca/xca-0.6.3/_tmp_root/usr/lib/python2.5/test/test_unicode_file.py: f = os.open(filename, os.O_CREAT) > > Not too bad considering. You grepped only for O_CREAT and no other bits in flags? Otherwise the list is way too short IMHO. fd = open(abort_file, O_CREAT); is broken not just for one reason, but for 2... 1) POSIX says: Applications shall specify exactly one of the first three values (file access modes) below in the value of oflag: O_RDONLY, O_WRONLY, O_RDWR Any combination of the following may be used: ... many ... Eventhough Linux defines O_RDONLY to 0, so O_CREAT alone is actually O_CREAT | O_RDONLY, e.g. on the Hurd O_RDONLY is 1, O_WRONLY 2 and O_RDWR 3, so not giving any of those is a serious error there and just a portability issue on Linux. 2) missing mode for O_CREAT Anyway, cases where open has compile time constant oflag argument will be handled by the compile time error if mode is missing and O_CREAT is present, so no need to worry about it - the mass rebuild will find them all. The case steved was moaning about is when oflag is not __builtin_constant_p. We can check even those cases after the mass rebuild, simply check what programs or shared libraries use __open{,at}{,64}_2@@GLIBC_2.7 symbols and check all those manually. Jakub From oliver at linux-kernel.at Thu Aug 16 20:36:59 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 16 Aug 2007 22:36:59 +0200 Subject: The open() system call in f8 really broken... In-Reply-To: <20070816202138.GA15542@redhat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4605B.1000407@RedHat.com> <46C461C6.5080302@linux-kernel.at> <46C46558.1000905@RedHat.com> <46C4685F.8080601@linux-kernel.at> <20070816202138.GA15542@redhat.com> Message-ID: <46C4B56B.8050000@linux-kernel.at> Dave Jones schrieb: > On Thu, Aug 16, 2007 at 05:08:15PM +0200, Oliver Falk wrote: > > > If you compile the whole Fedora tree, how many warnings will you see? > > So I grepped across a make prep'd tree of devel (all 63 gig of it). > Here's the fallout.. > > openmpi/openmpi-1.2.3/orte/runtime/orte_abort.c fd = open(abort_file, O_CREAT); > jython/jython-svn-Release_2_2beta1/CPythonLib/test/test_unicode_file.py:f = os.open(TESTFN_ENCODED, os.O_CREAT) > perl/perl-5.8.8/t/op/taint.t: eval { sysopen(my $cr, $evil, &O_CREAT) }; > proftpd/proftpd-1.3.0a/contrib/mod_rewrite.c: if ((fifo_lockfd = open(fifo_lockname, O_CREAT)) < 0) > pwlib/pwlib-1.10.7/configure:sem_t *s = sem_open("test", O_CREAT) > pwlib/pwlib-1.10.7/configure.ac: [sem_t *s = sem_open("test", O_CREAT)], > python/Python-2.5.1/Lib/test/test_unicode_file.py: f = os.open(filename, os.O_CREAT) > python-docs/Python-2.5.1/Lib/test/test_unicode_file.py: f = os.open(filename, os.O_CREAT) > xca/xca-0.6.3/_tmp_root/usr/lib/python2.5/test/test_unicode_file.py: f = os.open(filename, os.O_CREAT) I wasn't talking about *only* open warnings... But hey, that's not too bad.... But I can't imagine this is true :-) -of From tcallawa at redhat.com Thu Aug 16 20:34:02 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 16 Aug 2007 16:34:02 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <46C4B533.7020604@RedHat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816123746.006d0e7e.zaitcev@redhat.com> <46C4B533.7020604@RedHat.com> Message-ID: <1187296442.3439.174.camel@dhcp83-165.boston.redhat.com> On Thu, 2007-08-16 at 16:36 -0400, Steve Dickson wrote: > Pete Zaitcev wrote: > > > >> - if ((fd = open(fname, readonly? O_RDONLY : (O_RDWR|O_CREAT))) < 0) { > >> + if ((fd = (open)(fname, readonly? O_RDONLY : (O_RDWR|O_CREAT))) < 0) { > > > > Now you're just being unfriendly about it by finding ways to defeat > > a helpful check instead of adding the missing mode. What point are > > you trying to prove by doing this? > The point I was trying to prove is by simply adding the '()' I > could avoid the runtime abort and still have the security hole.... > concluding the runtime check is very buggy so this check should > never call abort() since it can't be correct 100% of time... This logic is flawed... if everytime it triggers is correct, we shouldn't remove the check because it misses possible cases. We'd really only want to remove it if found false positives. ~spot, who is amazed at the effort expended on this thread rather than simply FIXING the security bug From SteveD at redhat.com Thu Aug 16 20:39:27 2007 From: SteveD at redhat.com (Steve Dickson) Date: Thu, 16 Aug 2007 16:39:27 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <20070816130201.17950e19.zaitcev@redhat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816123746.006d0e7e.zaitcev@redhat.com> <21438.65.192.24.164.1187292077.squirrel@mail.jcomserv.net> <20070816130201.17950e19.zaitcev@redhat.com> Message-ID: <46C4B5FF.2060705@RedHat.com> Pete Zaitcev wrote: > On Thu, 16 Aug 2007 14:21:17 -0500 (CDT), "Jon Ciesla" wrote: > >>>> - if ((fd = open(fname, readonly? O_RDONLY : (O_RDWR|O_CREAT))) < 0) { >>>> + if ((fd = (open)(fname, readonly? O_RDONLY : (O_RDWR|O_CREAT))) < 0) { >>> Now you're just being unfriendly about it by finding ways to defeat >>> a helpful check instead of adding the missing mode. What point are >>> you trying to prove by doing this? >> What would the preferred fix look like? I'd like to get this sorted out, >> as I'd like to send a patch for one of my affected packages upstream. > > I would go for this myself, using Steve's example: > > - if ((fd = open(fname, readonly? O_RDONLY : (O_RDWR|O_CREAT))) < 0) { > + if (readonly) > + fd = open(fname, O_RDONLY); > + else > + fd = open(fname, O_RDWR|O_CREAT, S_IRUSR|S_IWUSR); > + if (fd < 0) { I did this way because I thought it made the code more readable if I broke things into separate statements... I've never been a fan of inlining statements... steved. From jima at beer.tclug.org Thu Aug 16 20:47:49 2007 From: jima at beer.tclug.org (Jima) Date: Thu, 16 Aug 2007 15:47:49 -0500 (CDT) Subject: The open() system call in f8 really broken... In-Reply-To: <20070816203815.GL2063@devserv.devel.redhat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4605B.1000407@RedHat.com> <46C461C6.5080302@linux-kernel.at> <46C46558.1000905@RedHat.com> <46C4685F.8080601@linux-kernel.at> <20070816202138.GA15542@redhat.com> <20070816203815.GL2063@devserv.devel.redhat.com> Message-ID: On Thu, 16 Aug 2007, Jakub Jelinek wrote: > Anyway, cases where open has compile time constant oflag argument > will be handled by the compile time error if mode is missing and O_CREAT > is present, so no need to worry about it - the mass rebuild will find > them all. The case steved was moaning about is when oflag is not > __builtin_constant_p. We can check even those cases after the mass rebuild, > simply check what programs or shared libraries use > __open{,at}{,64}_2@@GLIBC_2.7 symbols and check all those manually. Assuming you can even get the package to build. I've got a bizarre corner case in alsa-oss that I can't make heads or tails of. :-( Jima From SteveD at redhat.com Thu Aug 16 20:48:25 2007 From: SteveD at redhat.com (Steve Dickson) Date: Thu, 16 Aug 2007 16:48:25 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <1187296442.3439.174.camel@dhcp83-165.boston.redhat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816123746.006d0e7e.zaitcev@redhat.com> <46C4B533.7020604@RedHat.com> <1187296442.3439.174.camel@dhcp83-165.boston.redhat.com> Message-ID: <46C4B819.2030808@RedHat.com> Tom "spot" Callaway wrote: > On Thu, 2007-08-16 at 16:36 -0400, Steve Dickson wrote: >> Pete Zaitcev wrote: >>>> - if ((fd = open(fname, readonly? O_RDONLY : (O_RDWR|O_CREAT))) < 0) { >>>> + if ((fd = (open)(fname, readonly? O_RDONLY : (O_RDWR|O_CREAT))) < 0) { >>> Now you're just being unfriendly about it by finding ways to defeat >>> a helpful check instead of adding the missing mode. What point are >>> you trying to prove by doing this? >> The point I was trying to prove is by simply adding the '()' I >> could avoid the runtime abort and still have the security hole.... >> concluding the runtime check is very buggy so this check should >> never call abort() since it can't be correct 100% of time... > > This logic is flawed... if everytime it triggers is correct, we > shouldn't remove the check because it misses possible cases. We'd really > only want to remove it if found false positives. And how would find that false positive? Which DB, controlling what, will come tumbling down? If you going to kill off process... I would think you would want to be correct 100% of the time... and this case the shows the check does not it right 100% of the time... and just so happen it errored on the side not to abort. steved. From jkeating at redhat.com Thu Aug 16 20:59:52 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 16 Aug 2007 16:59:52 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <46C4B819.2030808@RedHat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816123746.006d0e7e.zaitcev@redhat.com> <46C4B533.7020604@RedHat.com> <1187296442.3439.174.camel@dhcp83-165.boston.redhat.com> <46C4B819.2030808@RedHat.com> Message-ID: <20070816165952.53db35b3@mentok.boston.redhat.com> On Thu, 16 Aug 2007 16:48:25 -0400 Steve Dickson wrote: > If you going to kill off process... I would think you would want to > be correct 100% of the time... and this case the shows the check > does not it right 100% of the time... You want 100% of the times you abort to be 100% correct in that it was a flaw. This happened here. Where it didn't abort it couldn't be sure that it should abort, and thus it didn't. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sandeen at redhat.com Thu Aug 16 21:18:50 2007 From: sandeen at redhat.com (Eric Sandeen) Date: Thu, 16 Aug 2007 16:18:50 -0500 Subject: The open() system call in f8 really broken... In-Reply-To: <20070816142437.GA2063@devserv.devel.redhat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> Message-ID: <46C4BF3A.6040702@redhat.com> Jakub Jelinek wrote: > On Thu, Aug 16, 2007 at 10:12:24AM -0400, Steve Dickson wrote: >> Bring down servers, costing people time and money because apps >> that have run for years suddenly abort is just not the right >> way to handle this.. imho.. > > Only people that run their $$$$$$ servers on rawhide... > >> Give people a chance to correct their code, with stern warnings, >> and then, in the next release, have the applications abort... >> Why is this such a bad idea? > > It is not yet F8test2, there is plenty of time to fix all or most > of these bugs still in rawhide. > Most uses of open(1) are actually with compile time constant > second argument and in that case glibc will issue compile time > errors when open ("foo", O_CREAT|O_RDWR); etc. is seen. > Only when it is known only at runtime we do runtime checking. Hmm is that what killed my e2sfprogs build? This looks like a bug in the check: 195 memset(data, 0, sizeof(struct test_private_data)); 196 data->magic = EXT2_ET_MAGIC_TEST_IO_CHANNEL; 197 if (test_io_backing_manager) { 198 retval = test_io_backing_manager->open(name, flags, 199 &data->real); 200 if (retval) 201 goto cleanup; 202 } else 203 data->real = 0; test_io.c: In function 'test_open': test_io.c:198: error: expected identifier before '(' token make[2]: *** [test_io.o] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: Leaving directory `/builddir/build/BUILD/e2fsprogs-1.40.2/lib/ext2fs' make[1]: *** [all-libs-recursive] Error 1 make[1]: Leaving directory `/builddir/build/BUILD/e2fsprogs-1.40.2' make: *** [all] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.43284 (%build) Note that it will probably stumble on a bona-fide open-create-with-no-mode later ;-) -Eric From jakub at redhat.com Thu Aug 16 21:26:32 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 16 Aug 2007 17:26:32 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <46C4BF3A.6040702@redhat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4BF3A.6040702@redhat.com> Message-ID: <20070816212632.GM2063@devserv.devel.redhat.com> On Thu, Aug 16, 2007 at 04:18:50PM -0500, Eric Sandeen wrote: > Hmm is that what killed my e2sfprogs build? This looks like a bug in > the check: > > > 195 memset(data, 0, sizeof(struct test_private_data)); > 196 data->magic = EXT2_ET_MAGIC_TEST_IO_CHANNEL; > 197 if (test_io_backing_manager) { > 198 retval = test_io_backing_manager->open(name, flags, > 199 &data->real); > 200 if (retval) > 201 goto cleanup; > 202 } else > 203 data->real = 0; > > test_io.c: In function 'test_open': > test_io.c:198: error: expected identifier before '(' token This has been mentioned here several times already in other threads. In this case you are not calling open(1), but some function pointer. And therefore it is undesirable to let it be expanded as function-like macro (which POSIX allows). The right fix is to use one of: retval = (test_io_backing_manager->open)(name, flags, &data->real); retval = (*test_io_backing_manager->open)(name, flags, &data->real); retval = test_io_backing_manager->(open)(name, flags, &data->real); or, far less desirable, but what standard allows, #undef open above this. The last one means that no open(1) error checking will be done in the rest of the source file, which is not a good idea. Jakub From sandeen at redhat.com Thu Aug 16 21:24:58 2007 From: sandeen at redhat.com (Eric Sandeen) Date: Thu, 16 Aug 2007 16:24:58 -0500 Subject: The open() system call in f8 really broken... In-Reply-To: <20070816212632.GM2063@devserv.devel.redhat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4BF3A.6040702@redhat.com> <20070816212632.GM2063@devserv.devel.redhat.com> Message-ID: <46C4C0AA.4030004@redhat.com> Jakub Jelinek wrote: >> test_io.c: In function 'test_open': >> test_io.c:198: error: expected identifier before '(' token > > This has been mentioned here several times already in other threads. Ah, sorry for missing that. Can't keep up... > In this case you are not calling open(1), but some function pointer. > And therefore it is undesirable to let it be expanded as function-like > macro (which POSIX allows). > The right fix is to use one of: > retval = (test_io_backing_manager->open)(name, flags, &data->real); > retval = (*test_io_backing_manager->open)(name, flags, &data->real); > retval = test_io_backing_manager->(open)(name, flags, &data->real); > or, far less desirable, but what standard allows, > #undef open > above this. The last one means that no open(1) error checking will be > done in the rest of the source file, which is not a good idea. Ok, thanks. -Eric From jima at beer.tclug.org Thu Aug 16 21:49:35 2007 From: jima at beer.tclug.org (Jima) Date: Thu, 16 Aug 2007 16:49:35 -0500 (CDT) Subject: The open() system call in f8 really broken... In-Reply-To: <20070816212632.GM2063@devserv.devel.redhat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4BF3A.6040702@redhat.com> <20070816212632.GM2063@devserv.devel.redhat.com> Message-ID: On Thu, 16 Aug 2007, Jakub Jelinek wrote: > This has been mentioned here several times already in other threads. > In this case you are not calling open(1), but some function pointer. > And therefore it is undesirable to let it be expanded as function-like > macro (which POSIX allows). > The right fix is to use one of: > retval = (test_io_backing_manager->open)(name, flags, &data->real); > retval = (*test_io_backing_manager->open)(name, flags, &data->real); > retval = test_io_backing_manager->(open)(name, flags, &data->real); > or, far less desirable, but what standard allows, > #undef open > above this. The last one means that no open(1) error checking will be > done in the rest of the source file, which is not a good idea. I've gone with the last of these suggestions for alsa-oss, partly because that's what someone (lpoetter?) chose to do for alsa-lib. Bad practice, perhaps, but the standard disclaimer applies: patches accepted. ;-) Jima From alan at redhat.com Thu Aug 16 22:19:53 2007 From: alan at redhat.com (Alan Cox) Date: Thu, 16 Aug 2007 18:19:53 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <20070816212632.GM2063@devserv.devel.redhat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4BF3A.6040702@redhat.com> <20070816212632.GM2063@devserv.devel.redhat.com> Message-ID: <20070816221953.GA12881@devserv.devel.redhat.com> On Thu, Aug 16, 2007 at 05:26:32PM -0400, Jakub Jelinek wrote: > In this case you are not calling open(1), but some function pointer. > And therefore it is undesirable to let it be expanded as function-like > macro (which POSIX allows). > The right fix is to use one of: Gak... Can we go back to C as used in the real world please From coldwell at redhat.com Thu Aug 16 22:29:12 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Thu, 16 Aug 2007 18:29:12 -0400 (Eastern Daylight Time) Subject: The open() system call in f8 really broken... In-Reply-To: <20070816212632.GM2063@devserv.devel.redhat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4BF3A.6040702@redhat.com> <20070816212632.GM2063@devserv.devel.redhat.com> Message-ID: On Thu, 16 Aug 2007, Jakub Jelinek wrote: > On Thu, Aug 16, 2007 at 04:18:50PM -0500, Eric Sandeen wrote: > > Hmm is that what killed my e2sfprogs build? This looks like a bug in > > the check: > > > > > > 195 memset(data, 0, sizeof(struct test_private_data)); > > 196 data->magic = EXT2_ET_MAGIC_TEST_IO_CHANNEL; > > 197 if (test_io_backing_manager) { > > 198 retval = test_io_backing_manager->open(name, flags, > > 199 &data->real); > > 200 if (retval) > > 201 goto cleanup; > > 202 } else > > 203 data->real = 0; > > > > test_io.c: In function 'test_open': > > test_io.c:198: error: expected identifier before '(' token > > This has been mentioned here several times already in other threads. Yup. One of those was mine (emacs). > In this case you are not calling open(1), but some function pointer. > And therefore it is undesirable to let it be expanded as function-like > macro (which POSIX allows). POSIX allows all sorts of things that one shouldn't do. This change is going to break a lot of existing code. I hope it's for a real benefit. "open" has to be the single most overloaded word in programming. I personally don't think we should mess with it. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From roland at redhat.com Thu Aug 16 22:33:30 2007 From: roland at redhat.com (Roland McGrath) Date: Thu, 16 Aug 2007 15:33:30 -0700 (PDT) Subject: The open() system call in f8 really broken... In-Reply-To: Chip Coldwell's message of Thursday, 16 August 2007 18:29:12 -0400 Message-ID: <20070816223330.4D45D4D0461@magilla.localdomain> > POSIX allows all sorts of things that one shouldn't do. This change is > going to break a lot of existing code. I hope it's for a real benefit. > "open" has to be the single most overloaded word in programming. I > personally don't think we should mess with it. Right after read and write. We survived those. From sandeen at redhat.com Thu Aug 16 22:32:21 2007 From: sandeen at redhat.com (Eric Sandeen) Date: Thu, 16 Aug 2007 17:32:21 -0500 Subject: The open() system call in f8 really broken... In-Reply-To: <20070816212632.GM2063@devserv.devel.redhat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4BF3A.6040702@redhat.com> <20070816212632.GM2063@devserv.devel.redhat.com> Message-ID: <46C4D075.6070106@redhat.com> Jakub Jelinek wrote: > The right fix is to use one of: > retval = (test_io_backing_manager->open)(name, flags, &data->real); > retval = (*test_io_backing_manager->open)(name, flags, &data->real); One unfortunate side-effect of this is that cscope doesn't find these as "open" callers now. Maybe I need a smarter cscope. It gets it to build, though. > retval = test_io_backing_manager->(open)(name, flags, &data->real); FWIW this didn't help, build failed same as before. -Eric > or, far less desirable, but what standard allows, > #undef open > above this. The last one means that no open(1) error checking will be > done in the rest of the source file, which is not a good idea. > > Jakub From roland at redhat.com Thu Aug 16 22:36:24 2007 From: roland at redhat.com (Roland McGrath) Date: Thu, 16 Aug 2007 15:36:24 -0700 (PDT) Subject: The open() system call in f8 really broken... In-Reply-To: Eric Sandeen's message of Thursday, 16 August 2007 17:32:21 -0500 <46C4D075.6070106@redhat.com> Message-ID: <20070816223625.0092C4D0461@magilla.localdomain> > One unfortunate side-effect of this is that cscope doesn't find these as > "open" callers now. Maybe I need a smarter cscope. It gets it to > build, though. Yes, cscope should learn C. > > retval = test_io_backing_manager->(open)(name, flags, &data->real); > > FWIW this didn't help, build failed same as before. I'm not sure we believe you. From tmraz at redhat.com Thu Aug 16 22:40:22 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Fri, 17 Aug 2007 00:40:22 +0200 Subject: The open() system call in f8 really broken... In-Reply-To: References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4BF3A.6040702@redhat.com> <20070816212632.GM2063@devserv.devel.redhat.com> Message-ID: <1187304022.14791.36.camel@vespa.kabelta.loc> On Thu, 2007-08-16 at 16:49 -0500, Jima wrote: > On Thu, 16 Aug 2007, Jakub Jelinek wrote: > > This has been mentioned here several times already in other threads. > > In this case you are not calling open(1), but some function pointer. > > And therefore it is undesirable to let it be expanded as function-like > > macro (which POSIX allows). > > The right fix is to use one of: > > retval = (test_io_backing_manager->open)(name, flags, &data->real); > > retval = (*test_io_backing_manager->open)(name, flags, &data->real); > > retval = test_io_backing_manager->(open)(name, flags, &data->real); > > or, far less desirable, but what standard allows, > > #undef open > > above this. The last one means that no open(1) error checking will be > > done in the rest of the source file, which is not a good idea. > > I've gone with the last of these suggestions for alsa-oss, partly because > that's what someone (lpoetter?) chose to do for alsa-lib. Bad practice, > perhaps, but the standard disclaimer applies: patches accepted. ;-) IMO, in this case (alsa-oss library is overriding the standard library open call) it is the exactly right thing to do. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From sandeen at redhat.com Thu Aug 16 22:48:18 2007 From: sandeen at redhat.com (Eric Sandeen) Date: Thu, 16 Aug 2007 17:48:18 -0500 Subject: The open() system call in f8 really broken... In-Reply-To: <20070816223625.0092C4D0461@magilla.localdomain> References: <20070816223625.0092C4D0461@magilla.localdomain> Message-ID: <46C4D432.1090808@redhat.com> Roland McGrath wrote: >> One unfortunate side-effect of this is that cscope doesn't find these as >> "open" callers now. Maybe I need a smarter cscope. It gets it to >> build, though. > > Yes, cscope should learn C. > >>> retval = test_io_backing_manager->(open)(name, flags, &data->real); >> FWIW this didn't help, build failed same as before. > > I'm not sure we believe you. sorry, different failure. test_io.c: In function ?test_open?: test_io.c:198: error: expected identifier before ?(? token make[2]: *** [test_io.o] Error 1 bash-3.2# cat -n lib/ext2fs/test_io.c | grep 198 198 retval = test_io_backing_manager->(open)(name, flags, &data->real); *shrug* maybe I'm just dense and/or worn out today. I'll go with what works. -Eric From jakub at redhat.com Thu Aug 16 23:04:20 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 16 Aug 2007 19:04:20 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <46C4D432.1090808@redhat.com> References: <20070816223625.0092C4D0461@magilla.localdomain> <46C4D432.1090808@redhat.com> Message-ID: <20070816230420.GN2063@devserv.devel.redhat.com> On Thu, Aug 16, 2007 at 05:48:18PM -0500, Eric Sandeen wrote: > Roland McGrath wrote: > >> One unfortunate side-effect of this is that cscope doesn't find these as > >> "open" callers now. Maybe I need a smarter cscope. It gets it to > >> build, though. > > > > Yes, cscope should learn C. > > > >>> retval = test_io_backing_manager->(open)(name, flags, &data->real); > >> FWIW this didn't help, build failed same as before. > > > > I'm not sure we believe you. > > sorry, different failure. > > *shrug* maybe I'm just dense and/or worn out today. I'll go with what > works. Oops, sorry, shouldn't have listed that as alternative, that is not valid. retval = (test_io_backing_manager->open)(name, flags, &data->real); and retval = (*test_io_backing_manager->open)(name, flags, &data->real); are though. Jakub From davej at redhat.com Thu Aug 16 23:06:08 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 16 Aug 2007 19:06:08 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <20070816203637.GA10486@redhat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4605B.1000407@RedHat.com> <46C461C6.5080302@linux-kernel.at> <46C46558.1000905@RedHat.com> <46C4685F.8080601@linux-kernel.at> <20070816202138.GA15542@redhat.com> <20070816203637.GA10486@redhat.com> Message-ID: <20070816230608.GA18576@redhat.com> On Thu, Aug 16, 2007 at 04:36:37PM -0400, Dave Jones wrote: > On Thu, Aug 16, 2007 at 04:21:38PM -0400, Dave Jones wrote: > > On Thu, Aug 16, 2007 at 05:08:15PM +0200, Oliver Falk wrote: > > > > > If you compile the whole Fedora tree, how many warnings will you see? > > > > So I grepped across a make prep'd tree of devel (all 63 gig of it). > > Here's the fallout.. > > > > openmpi/openmpi-1.2.3/orte/runtime/orte_abort.c fd = open(abort_file, O_CREAT); > > jython/jython-svn-Release_2_2beta1/CPythonLib/test/test_unicode_file.py:f = os.open(TESTFN_ENCODED, os.O_CREAT) > > perl/perl-5.8.8/t/op/taint.t: eval { sysopen(my $cr, $evil, &O_CREAT) }; > > proftpd/proftpd-1.3.0a/contrib/mod_rewrite.c: if ((fifo_lockfd = open(fifo_lockname, O_CREAT)) < 0) > > pwlib/pwlib-1.10.7/configure:sem_t *s = sem_open("test", O_CREAT) > > pwlib/pwlib-1.10.7/configure.ac: [sem_t *s = sem_open("test", O_CREAT)], > > python/Python-2.5.1/Lib/test/test_unicode_file.py: f = os.open(filename, os.O_CREAT) > > python-docs/Python-2.5.1/Lib/test/test_unicode_file.py: f = os.open(filename, os.O_CREAT) > > xca/xca-0.6.3/_tmp_root/usr/lib/python2.5/test/test_unicode_file.py: f = os.open(filename, os.O_CREAT) > > > > Not too bad considering. > > Bah, my regexp was imperfect. I'll fix up and rerun. More like it. 267 hits. Dave Checking ./aqbanking/aqbanking-2.3.2/src/libs/aqbanking/httpsession.c Found open with O_CREAT and no mode. fdWrite = open(DIALOG_LOGFILE_BASE ".out", O_WRONLY | O_CREAT); Checking ./aqbanking/aqbanking-2.3.2/src/plugins/backends/aqhbci/plugin/msglayer/message.c Found open with O_CREAT and no mode. fd = open(logFile, O_RDWR | O_CREAT | O_APPEND); Checking ./grass/grass-6.2.2-fedora/raster/r.drain/main.c Found open with O_CREAT and no mode. fe = open(tempfile1, O_RDWR | O_CREAT); fd = open(tempfile2, O_RDWR | O_CREAT); Checking ./grass/grass-6.2.2-fedora/raster/r.fill.dir/main.c Found open with O_CREAT and no mode. fe = open(tempfile1, O_RDWR | O_CREAT); /* elev */ fd = open(tempfile2, O_RDWR | O_CREAT); /* dirn */ fm = open(tempfile3, O_RDWR | O_CREAT); /* problems */ Checking ./openmpi/openmpi-1.2.3/orte/runtime/orte_abort.c Found open with O_CREAT and no mode. fd = open(abort_file, O_CREAT); Checking ./compat-gcc-32/gcc-3.2.3-20040701/gcc/collect2.c Found open with O_CREAT and no mode. redir_handle = open(redir, O_WRONLY | O_TRUNC | O_CREAT); Checking ./nessus-core/nessus-core/nessusd/detached.c Found open with O_CREAT and no mode. int f = open(fname, O_CREAT | O_WRONLY | O_TRUNC); Checking ./libxml2/libxml2-2.6.29/nanohttp.c Found open with O_CREAT and no mode. fd = open(filename, O_CREAT | O_WRONLY); Checking ./hdf5/hdf5-1.6.5/perform/pio_engine.c Found open with O_CREAT and no mode. hrc = do_fopen(¶m, fname, &fd, PIO_CREATE | PIO_WRITE); Checking ./hdf5/hdf5-1.6.5/perform/zip_perf.c Found open with O_CREAT and no mode. output = open(filename, O_RDWR | O_CREAT); Checking ./dd_rescue/dd_rescue/dd_rescue.c Found open with O_CREAT and no mode. c = openfile(lname, O_WRONLY | O_CREAT /*| O_EXCL */ ); Checking ./hal/hal-0.5.10/tools/hal-acl-tool.c Found open with O_CREAT and no mode. open(PACKAGE_LOCALSTATEDIR "/lib/hal/acl-list", O_CREAT | O_RDWR); Checking ./ettercap/ettercap-NG-0.7.3/src/ec_log.c Found open with O_CREAT and no mode. fd->fd = open(filename, O_CREAT | O_TRUNC | O_RDWR | O_BINARY); Checking ./openhpi/openhpi-2.8.1/utils/uid_utils.c Found open with O_CREAT and no mode. file = open(uid_map_file, O_WRONLY | O_CREAT | O_TRUNC); Checking ./openhpi/openhpi-2.8.1/utils/t/epath/uid_utils.c Found open with O_CREAT and no mode. file = open(uid_map_file, O_WRONLY | O_CREAT | O_TRUNC); Checking ./openhpi/openhpi-2.8.1/utils/t/uid/uid_utils.c Found open with O_CREAT and no mode. file = open(uid_map_file, O_WRONLY | O_CREAT | O_TRUNC); Checking ./openhpi/openhpi-2.8.1/utils/t/rpt/uid_utils.c Found open with O_CREAT and no mode. file = open(uid_map_file, O_WRONLY | O_CREAT | O_TRUNC); Checking ./openhpi/openhpi-2.8.1/utils/t/sahpi/uid_utils.c Found open with O_CREAT and no mode. file = open(uid_map_file, O_WRONLY | O_CREAT | O_TRUNC); Checking ./libburn/libburn-0.2.6.3/cdrskin/cdrfifo.c Found open with O_CREAT and no mode. fd = open(argv[i] + 3, O_WRONLY | O_CREAT); Checking ./snort/snort-2.6.1.4/src/util.c Found open with O_CREAT and no mode. open("/tmp/snort.debug", O_CREAT | O_RDWR); Checking ./snort/snort-2.6.1.4/src/preprocessors/flow/portscan/server_stats.c Found open with O_CREAT and no mode. fd = open(filename, O_CREAT | O_TRUNC | O_SYNC | O_WRONLY); Checking ./tgif/tgif-QPL-4.1.45/util.c Found open with O_CREAT and no mode. fd = open(buf, O_CREAT | O_EXCL | O_WRONLY); Checking ./tgif/tgif-QPL-4.1.45/file.c Found open with O_CREAT and no mode. int fd = open(buf, O_CREAT | O_EXCL | O_WRONLY); Checking ./neon/neon-0.25.5/test/request.c Found open with O_CREAT and no mode. fd = open(fn, O_RDWR | O_CREAT); Checking ./yap/Yap-5.1.1/C/alloc.c Found open with O_CREAT and no mode. fd = open(file, O_CREAT | O_RDWR); fd = open(file, O_CREAT | O_RDWR); Checking ./allegro/allegro-4.2.2/src/file.c Found open with O_CREAT and no mode. _al_open(tmp_name, O_RDWR | O_BINARY | O_CREAT | O_EXCL); Checking ./dx/dx-4.4.4/src/exec/libdx/fileio.c Found open with O_CREAT and no mode. fd = open(name, O_WRONLY | O_CREAT); Checking ./acpid/acpid-1.0.4/acpid.c Found open with O_CREAT and no mode. logfd = open(logfile, O_WRONLY | O_CREAT | O_APPEND); Checking ./aircrack-ng/aircrack-ng-0.9.1/src/aireplay-ng.c Found open with O_CREAT and no mode. dev.nofcs = open(location, O_WRONLY | O_CREAT); Checking ./mbuffer/mbuffer-20070502/mbuffer.c Found open with O_CREAT and no mode. Tmp = open(Tmpfile, O_RDWR | O_CREAT | O_EXCL); Checking ./initscripts/initscripts-8.55/src/rename_device.c Found open with O_CREAT and no mode. lockfd = open(LOCKFILE, O_RDWR | O_CREAT | O_EXCL); Checking ./elinks/elinks-0.11.3/src/osdep/win32/win32.c Found open with O_CREAT and no mode. return open(tempname, O_CREAT | O_WRONLY | O_EXCL | O_BINARY); Checking ./mysql/mysql-5.0.45/netware/my_manage.c Found open with O_CREAT and no mode. wiring.outfd = open(output, O_WRONLY | O_CREAT | O_TRUNC); wiring.errfd = open(error, O_WRONLY | O_CREAT | O_TRUNC); Checking ./nessus-libraries/nessus-libraries/libnessus/network.c Found open with O_CREAT and no mode. lock_fd = open(NESSUS_CNX_LOCK, O_RDWR | O_CREAT); Checking ./compat-erlang/otp_src_R10B-10/erts/etc/unix/run_erl.c Found open with O_CREAT and no mode. lfd = open_log(lognum, O_RDWR | O_APPEND | O_CREAT | O_SYNC); *lfd = open_log(*log_num, O_RDWR | O_CREAT | O_TRUNC | O_SYNC); Checking ./doodle/doodle-0.6.6/src/doodle/doodled.c Found open with O_CREAT and no mode. nullfd = open("/dev/null", O_CREAT | O_RDWR | O_APPEND); Checking ./xorg-x11-drv-i810/xf86-video-intel-2.1.0/src/bios_reader/bios_dumper.c Found open with O_CREAT and no mode. fd = open(argv[1], O_RDWR | O_CREAT | O_TRUNC); Checking ./openais/openais-0.80.1/exec/keygen.c Found open with O_CREAT and no mode. authkey_fd = open("/etc/ais/authkey", O_CREAT | O_WRONLY); Checking ./elektra/elektra-0.6.10/src/backends/ini/helpers.c Found open with O_CREAT and no mode. fd = open(filename, posix_mode | O_CREAT); Checking ./libdsk/libdsk-1.1.12/tools/serslave.c Found open with O_CREAT and no mode. outfd = open(filename, O_CREAT | O_WRONLY | O_APPEND | O_NONBLOCK); Checking ./ImageMagick/ImageMagick-6.3.2/magick/delegate.c Found open with O_CREAT and no mode. destination_file = open(destination, O_WRONLY | O_BINARY | O_CREAT); Checking ./Coin2/Coin-2.4.6/src/tidbits.c Found open with O_CREAT and no mode. nullfd = open(tmpname, O_CREAT | O_WRONLY); Checking ./cdogs-sdl/cdogs-sdl-0.4/src/files.c Found open with O_CREAT and no mode. f = open(filename, O_WRONLY | O_CREAT | O_TRUNC); Checking ./dietlibc/dietlibc-0.30/test/mmap_test.c Found open with O_CREAT and no mode. fd = open(FILENAME, O_RDWR | O_CREAT); Checking ./rhythmbox/rhythmbox-0.11.1/plugins/daap/rb-daap-structure.c Found open with O_CREAT and no mode. fd = open(PARSE_DEBUG_FILE, O_WRONLY | O_CREAT); Checking ./gwenhywfar/gwenhywfar-2.6.1/test/gwentest.c Found open with O_CREAT and no mode. fd = open(outFile, O_CREAT | O_WRONLY); fd = open(outFile, O_CREAT | O_WRONLY); fd = open(outFile, O_CREAT | O_WRONLY); Checking ./libchewing/libchewing-0.3.0/src/porting_layer/src/plat_mmap_posix.c Found open with O_CREAT and no mode. handle->fd = open(file, O_RDWR | O_CREAT); Checking ./kst/kst-1.4.0/kst/src/datasources/dirfile/getdata.c Found open with O_CREAT and no mode. R->fp = open(datafilename, O_RDWR | O_CREAT); Checking ./jfsutils/jfsutils-1.1.11/libfs/fssubs.c Found open with O_CREAT and no mode. fd = open(TEST_FILE, O_RDWR | O_CREAT); Checking ./arm-gp2x-linux-glibc/arm-gp2x-linux-glibc-2.3.6/glibc-2.3.6/login/tst-grantpt.c Found open with O_CREAT and no mode. fd = open(file, O_RDWR | O_CREAT); Checking ./heartbeat/heartbeat-2.0.8/lib/clplumbing/cl_msg.c Found open with O_CREAT and no mode. return open(filename, O_WRONLY | O_CREAT | O_APPEND); Checking ./brltty/brltty-3.7.2/Programs/config.c Found open with O_CREAT and no mode. int fd = open(preferencesFile, O_WRONLY | O_CREAT | O_TRUNC); Checking ./brltty/brltty-3.7.2/BrailleDrivers/EcoBraille/braille.c Found open with O_CREAT and no mode. brl_log = open("/tmp/brllog", O_CREAT | O_WRONLY); Checking ./t1lib/t1lib-5.1.1/lib/t1lib/t1outline.c if with ; at EOL! if (ipath->type == TEXTTYPE); Checking ./bombardier/bombardier-0.8.2/hof.c Found open with O_CREAT and no mode. fd = open("/var/games/bombardier/bdscore", O_RDWR | O_CREAT); Checking ./squid/squid-2.6.STABLE14/src/fs/diskd/store_dir_diskd.c Found open with O_CREAT and no mode. fd = file_open(path, O_WRONLY | O_CREAT | O_BINARY); fd = file_open(swaplog_path, O_WRONLY | O_CREAT | O_BINARY); fd = file_open(new_path, O_WRONLY | O_CREAT | O_TRUNC | O_BINARY); file_open(state->new, O_WRONLY | O_CREAT | O_TRUNC | O_BINARY); Checking ./squid/squid-2.6.STABLE14/src/fs/aufs/store_dir_aufs.c Found open with O_CREAT and no mode. fd = file_open(path, O_WRONLY | O_CREAT | O_BINARY); fd = file_open(swaplog_path, O_WRONLY | O_CREAT | O_BINARY); fd = file_open(new_path, O_WRONLY | O_CREAT | O_TRUNC | O_BINARY); file_open(state->new, O_WRONLY | O_CREAT | O_TRUNC | O_BINARY); Checking ./squid/squid-2.6.STABLE14/src/fs/aufs/store_io_aufs.c Found open with O_CREAT and no mode. fd = file_open(path, O_WRONLY | O_CREAT | O_TRUNC | O_BINARY); Checking ./squid/squid-2.6.STABLE14/src/fs/coss/store_dir_coss.c Found open with O_CREAT and no mode. fd = file_open(path, O_WRONLY | O_CREAT | O_BINARY); cs->fd = file_open(stripePath(sd), O_RDWR | O_CREAT | O_BINARY); fd = file_open(swaplog_path, O_WRONLY | O_CREAT | O_BINARY); fd = file_open(new_path, O_WRONLY | O_CREAT | O_TRUNC | O_BINARY); file_open(state->new, O_WRONLY | O_CREAT | O_TRUNC | O_BINARY); Checking ./squid/squid-2.6.STABLE14/src/fs/ufs/store_dir_ufs.c Found open with O_CREAT and no mode. fd = file_open(path, O_WRONLY | O_CREAT | O_BINARY); fd = file_open(swaplog_path, O_WRONLY | O_CREAT | O_BINARY); fd = file_open(new_path, O_WRONLY | O_CREAT | O_TRUNC | O_BINARY); file_open(state->new, O_WRONLY | O_CREAT | O_TRUNC | O_BINARY); Checking ./squid/squid-2.6.STABLE14/src/tools.c Found open with O_CREAT and no mode. fd = file_open(f, O_WRONLY | O_CREAT | O_TRUNC | O_TEXT); Checking ./squid/squid-2.6.STABLE14/src/logfile.c Found open with O_CREAT and no mode. int fd = file_open(path, O_WRONLY | O_CREAT | O_TEXT); lf->fd = file_open(lf->path, O_WRONLY | O_CREAT | O_TEXT); Checking ./postgresql/postgresql-8.2.4/src/backend/storage/smgr/md.c Found open with O_CREAT and no mode. v->mdfd_chain = _mdfd_openseg(reln, segno, O_CREAT); Checking ./nethack-vultures/vultures-2.1.0/slashem/win/gem/bitmfile.c Found open with O_CREAT and no mode. file = open(filename, O_WRONLY | O_CREAT | O_TRUNC); Checking ./nethack-vultures/vultures-2.1.0/slashem/util/recover.c Found open with O_CREAT and no mode. out = open(iconfile, O_WRONLY | O_TRUNC | O_CREAT); Checking ./nethack-vultures/vultures-2.1.0/nethack/win/gem/bitmfile.c Found open with O_CREAT and no mode. file = open(filename, O_WRONLY | O_CREAT | O_TRUNC); Checking ./nethack-vultures/vultures-2.1.0/nethack/util/recover.c Found open with O_CREAT and no mode. out = open(iconfile, O_WRONLY | O_TRUNC | O_CREAT); Checking ./nethack-vultures/vultures-2.1.0/nethack/util/lev_main.c Found open with O_CREAT and no mode. fout = open(lbuf, O_WRONLY | O_CREAT | O_BINARY); Checking ./nethack/nethack-3.4.3/win/gem/bitmfile.c Found open with O_CREAT and no mode. file = open(filename, O_WRONLY | O_CREAT | O_TRUNC); Checking ./nethack/nethack-3.4.3/util/recover.c Found open with O_CREAT and no mode. out = open(iconfile, O_WRONLY | O_TRUNC | O_CREAT); Checking ./nethack/nethack-3.4.3/util/lev_main.c Found open with O_CREAT and no mode. fout = open(lbuf, O_WRONLY | O_CREAT | O_BINARY); Checking ./callweaver/callweaver-r2861/apps/app_voicemail.c Found open with O_CREAT and no mode. fd = open(full_fn, O_RDWR | O_CREAT | O_TRUNC); Checking ./callweaver/callweaver-r2861/channels/chan_zap.c Found open with O_CREAT and no mode. myfd = open(argv[4], O_CREAT | O_WRONLY); Checking ./callweaver/callweaver-r2861/codecs/codec_speex.c Found open with O_CREAT and no mode. fd = open("speex.raw", O_WRONLY | O_TRUNC | O_CREAT); Checking ./e2fsprogs/e2fsprogs-1.40.2/lib/ext2fs/ismounted.c Found open with O_CREAT and no mode. fd = open(TEST_FILE, O_RDWR | O_CREAT); Checking ./initng/initng-0.6.10.1/plugins/logfile/initng_logfile.c Found open with O_CREAT and no mode. fd = open(filename, O_WRONLY | O_CREAT | O_APPEND); Checking ./mysqlclient14/mysql-4.1.14/netware/my_manage.c Found open with O_CREAT and no mode. wiring.outfd = open(output, O_WRONLY | O_CREAT | O_TRUNC); wiring.errfd = open(error, O_WRONLY | O_CREAT | O_TRUNC); Checking ./mysqlclient14/mysql-4.1.14/mysql-test/my_manage.c Found open with O_CREAT and no mode. wiring.outfd = open(output, O_WRONLY | O_CREAT | O_TRUNC); wiring.errfd = open(error, O_WRONLY | O_CREAT | O_TRUNC); Checking ./compat-gcc-34/gcc-3.4.6-20060404/gcc/collect2.c Found open with O_CREAT and no mode. redir_handle = open(redir, O_WRONLY | O_TRUNC | O_CREAT); Checking ./TeXmacs/TeXmacs-1.0.6.10-src/plugins/r/src/tm_r.c Found open with O_CREAT and no mode. LOG = open("/tmp/log", O_CREAT | O_WRONLY); Checking ./lirc/lirc-0.8.2/daemons/slinke.c Found open with O_CREAT and no mode. fd = open(remote->name, O_CREAT | O_EXCL | O_RDWR); Checking ./ortp/ortp-0.13.1/src/tests/mrtprecv.c Found open with O_CREAT and no mode. open(filename, _O_BINARY | O_WRONLY | O_CREAT | O_TRUNC); Checking ./ortp/ortp-0.13.1/src/tests/tevmrtprecv.c Found open with O_CREAT and no mode. open(filename, _O_BINARY | O_WRONLY | O_CREAT | O_TRUNC); Checking ./libsilc/silc-toolkit-1.0.2/lib/silcclient/client_ftp.c Found open with O_CREAT and no mode. session->fd = silc_file_open(path, O_RDWR | O_CREAT | O_EXCL); Checking ./sane-backends/sane-backends-1.0.18/backend/fujitsu.c Found open with O_CREAT and no mode. s->duplex_fd = open (filename, O_RDWR | O_CREAT | O_EXCL); Checking ./tor/tor-0.1.2.16/src/common/util.c Found open with O_CREAT and no mode. nullfd = open("/dev/null", O_CREAT | O_RDWR | O_APPEND); Checking ./unzip/unzip-5.52/fileio.c Found open with O_CREAT and no mode. fd = open(G.filename, O_WRONLY | O_LARGEFILE | O_CREAT); Checking ./tetex/tetex-src-3.0/texk/web2c/lib/coredump.c Found open with O_CREAT and no mode. int handle = open("core", O_WRONLY | O_CREAT | O_TRUNC | O_BINARY); Checking ./net-snmp/net-snmp-5.4/agent/mibgroup/util_funcs.c Found open with O_CREAT and no mode. fd = open(name, O_CREAT | O_EXCL | O_WRONLY); Checking ./zaptel/zaptel-1.4.2.1/fxotune.c Found open with O_CREAT and no mode. configfd = open(configfile, O_CREAT | O_TRUNC | O_WRONLY); Checking ./ecryptfs-utils/ecryptfs-utils-18/src/testcases/llseek.c Found open with O_CREAT and no mode. fd = open(FILENAME, (O_CREAT | O_EXCL | O_WRONLY)); Checking ./ecryptfs-utils/ecryptfs-utils-18/src/testcases/open_close.c Found open with O_CREAT and no mode. fd = open(filename, (O_CREAT | O_EXCL)); Checking ./xfsdump/xfsdump-2.2.45/inventory/inv_stobj.c Found open with O_CREAT and no mode. int tmpfd = open("moids", O_RDWR | O_CREAT); Checking ./xfsdump/xfsdump-2.2.45/invutil/invidx.c Found open with O_CREAT and no mode. new_fd = open(dst_idxfile, O_CREAT | O_RDWR); Checking ./libxml/libxml-1.8.17/nanohttp.c Found open with O_CREAT and no mode. fd = open(filename, O_CREAT | O_WRONLY); Checking ./ddrescue/dd_rescue/dd_rescue.c Found open with O_CREAT and no mode. c = openfile(lname, O_WRONLY | O_CREAT /*| O_EXCL */ ); Checking ./pilot-link/pilot-link-0.12.2/src/pilot-schlep.c Found open with O_CREAT and no mode. fd = open(filename, O_WRONLY | O_CREAT | O_TRUNC); Checking ./nano/nano-2.0.6/src/files.c Found open with O_CREAT and no mode. fd_source = open(realname, O_RDONLY | O_CREAT); fd_source = open(tempname, O_RDONLY | O_CREAT); Checking ./erlang/otp_src_R11B-2/erts/etc/unix/run_erl.c Found open with O_CREAT and no mode. lfd = open_log(lognum, O_RDWR | O_APPEND | O_CREAT | O_SYNC); *lfd = open_log(*log_num, O_RDWR | O_CREAT | O_TRUNC | O_SYNC); Checking ./xcdroast/xcdroast-0.98alpha15/src/io.c Found open with O_CREAT and no mode. fd = open(fname, O_WRONLY | O_CREAT); Checking ./freeciv/freeciv-2.0.9/client/connectdlg_common.c Found open with O_CREAT and no mode. fd = open(logfile, O_WRONLY | O_CREAT); Checking ./isomaster/isomaster-1.0/isobrowser.c Found open with O_CREAT and no mode. destFile = open(openIsoPathAndName, O_WRONLY | O_CREAT); Checking ./vim/vim71/src/memfile.c Found open with O_CREAT and no mode. mf_do_open(mfp, fname, O_RDWR | O_CREAT | O_EXCL); /* try to open the file */ Checking ./mtx/mtx-1.3.11/mam2debug2.c Found open with O_CREAT and no mode. outfile = open(argv[2], O_CREAT | O_WRONLY); Checking ./mtx/mtx-1.3.11/mam2debug.c Found open with O_CREAT and no mode. outfile = open(argv[2], O_CREAT | O_WRONLY); Checking ./linphone/linphone-1.7.1/oRTP/src/tests/mrtprecv.c Found open with O_CREAT and no mode. open(filename, _O_BINARY | O_WRONLY | O_CREAT | O_TRUNC); Checking ./linphone/linphone-1.7.1/oRTP/src/tests/tevmrtprecv.c Found open with O_CREAT and no mode. open(filename, _O_BINARY | O_WRONLY | O_CREAT | O_TRUNC); Checking ./nx/nx-2.1.0/nx-X11/programs/xmh/miscfuncs.c Found open with O_CREAT and no mode. new_fid = open(tmp_file, O_RDWR | O_CREAT); Checking ./rgmanager/rgmanager-2.0.23/src/daemons/clurmtabd_lib.c Found open with O_CREAT and no mode. close(open(filename, O_WRONLY | O_SYNC | O_CREAT)); Checking ./glibc/glibc-20070804T2027/login/tst-grantpt.c Found open with O_CREAT and no mode. fd = open(file, O_RDWR | O_CREAT); Checking ./busybox/busybox-1.6.1/archival/unzip.c Found open with O_CREAT and no mode. dst_fd = xopen(dst_fn, O_WRONLY | O_CREAT | O_TRUNC); Checking ./busybox/busybox-1.6.1/e2fsprogs/old_e2fsprogs/ext2fs/ismounted.c Found open with O_CREAT and no mode. fd = open(TEST_FILE, O_RDWR | O_CREAT); Checking ./busybox/busybox-1.6.1/runit/svlogd.c Found open with O_CREAT and no mode. fd = xopen(ld->fnsave, O_WRONLY | O_NDELAY | O_TRUNC | O_CREAT); close(xopen("state", O_WRONLY | O_NDELAY | O_TRUNC | O_CREAT)); fd = xopen("newstate", O_WRONLY | O_NDELAY | O_TRUNC | O_CREAT); Checking ./busybox/busybox-1.6.1/miscutils/rx.c Found open with O_CREAT and no mode. filefd = xopen(fn, O_RDWR | O_CREAT | O_TRUNC); Checking ./busybox/busybox-1.6.1/networking/ftpgetput.c Found open with O_CREAT and no mode. fd_local = xopen(local_path, O_CREAT | O_TRUNC | O_WRONLY); Checking ./jed/jed-0.99-18/src/file.c Found open with O_CREAT and no mode. return open(file, O_WRONLY | O_APPEND | O_CREAT | O_BINARY); Checking ./mono/mono-1.2.4/mono/arch/alpha/test.c Found open with O_CREAT and no mode. int fd = open("bad.out", O_CREAT | O_TRUNC); Checking ./proftpd/proftpd-1.3.0a/modules/mod_xfer.c Found open with O_CREAT and no mode. stor_fh = pr_fsio_open(session.xfer.path, O_CREAT | O_WRONLY); Checking ./proftpd/proftpd-1.3.0a/src/fsio.c Found open with O_CREAT and no mode. dst_fh = pr_fsio_open(dst, O_WRONLY | O_CREAT); Checking ./dvb-apps/linuxtv-dvb-apps-1.1.1/test/test.c Found open with O_CREAT and no mode. int vout = open("qv", O_RDWR | O_CREAT); int aout = open("qa", O_RDWR | O_CREAT); -- http://www.codemonkey.org.uk From ssorce at redhat.com Thu Aug 16 23:07:26 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 16 Aug 2007 19:07:26 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <46C4D432.1090808@redhat.com> References: <20070816223625.0092C4D0461@magilla.localdomain> <46C4D432.1090808@redhat.com> Message-ID: <1187305646.27768.83.camel@localhost.localdomain> On Thu, 2007-08-16 at 17:48 -0500, Eric Sandeen wrote: > Roland McGrath wrote: > >> One unfortunate side-effect of this is that cscope doesn't find these as > >> "open" callers now. Maybe I need a smarter cscope. It gets it to > >> build, though. > > > > Yes, cscope should learn C. > > > >>> retval = test_io_backing_manager->(open)(name, flags, &data->real); > >> FWIW this didn't help, build failed same as before. > > > > I'm not sure we believe you. > > sorry, different failure. > > test_io.c: In function ?test_open?: > test_io.c:198: error: expected identifier before ?(? token > make[2]: *** [test_io.o] Error 1 > > bash-3.2# cat -n lib/ext2fs/test_io.c | grep 198 > 198 retval = test_io_backing_manager->(open)(name, > flags, &data->real); > > *shrug* maybe I'm just dense and/or worn out today. I'll go with what > works. Imo the "right" fix should be to not use "open" as I'd consider it a reserved word, and change it to something like tio_open ... cscope would be happy as well. Simo. From tjanouse at redhat.com Thu Aug 16 23:20:30 2007 From: tjanouse at redhat.com (Tomas Janousek) Date: Fri, 17 Aug 2007 01:20:30 +0200 Subject: The open() system call in f8 really broken... In-Reply-To: <46C4D075.6070106@redhat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4BF3A.6040702@redhat.com> <20070816212632.GM2063@devserv.devel.redhat.com> <46C4D075.6070106@redhat.com> Message-ID: <20070816232030.GA9596@redhat.com> Hi, On Thu, Aug 16, 2007 at 05:32:21PM -0500, Eric Sandeen wrote: > > The right fix is to use one of: > > retval = (test_io_backing_manager->open)(name, flags, &data->real); > > retval = (*test_io_backing_manager->open)(name, flags, &data->real); > > One unfortunate side-effect of this is that cscope doesn't find these as > "open" callers now. Maybe I need a smarter cscope. It gets it to > build, though. It does here. [tjanouse at tjanouse ~]$ rpm -q cscope cscope-15.5-15.fc6.1 (rhel-5 machine though) So does cscope-15.6-3 on debian. -- TJ. (Brno, CZ), BaseOS, Red Hat From walters at redhat.com Thu Aug 16 23:41:21 2007 From: walters at redhat.com (Colin Walters) Date: Thu, 16 Aug 2007 19:41:21 -0400 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <1187283455.13210.28.camel@cutter> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <1187283455.13210.28.camel@cutter> Message-ID: On 8/16/07, seth vidal wrote: > > Colin, > This is with all sincerity and not at all meant to be dismissive: If > you have the time to automate this I think we'll be glad to listen. There are a lot of components to automation of this kind of thing; in fact people have made entire companies and product lines around (as far as I can tell) essentially this problem: http://www.blackducksoftware.com/ However, I was fairly sure there had to already be something open source out there to use as a start. My initial googling wasn't too successful (a lot of things called licenses), but then I had the bright idea to add "Debian" to my search. Turns out there's a license analyzing script in one of their packages: http://packages.debian.org/unstable/devel/devscripts There is also: http://www.murrayc.com/blog/permalink/2006/10/04/debian-repository-analyzer-for-license-compliance/ Which looks kind of frightening but maybe useful. The Debian script supports far fewer licenses the Fedora wiki page on this topic; however, it would probably be pretty useful to run over the whole source tree as a start; I bet you'd find a number of cases where things today are specified just as GPL but have some other stuff. Moving more advanced from that, associate the wiki license list set with a list of fuzzy text segments combined with regular expressions. -------------- next part -------------- An HTML attachment was scrubbed... URL: From buildsys at fedoraproject.org Thu Aug 16 23:44:04 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 16 Aug 2007 19:44:04 -0400 (EDT) Subject: Package EVR problems in Fedora 2007-08-16 Message-ID: <20070816234404.2269D152131@buildsys.fedoraproject.org> Axel.Thimm AT ATrpms.net: smart FE6 > F7-updates (0:0.50-47.fc6 > 0:0.50-46.fc7) FE6 > F8 (0:0.50-47.fc6 > 0:0.50-46.fc8) alexl AT redhat.com: xdg-user-dirs F7-updates > F8 (0:0.8-3.fc7 > 0:0.8-2.fc8) davidz AT redhat.com: dbus-python F7-updates-testing > F8 (0:0.82.0-2.fc7 > 0:0.82.0-1.fc8) ed AT eh3.com: scrip FE6 > F7 (0:1.4-7.fc6 > 0:1.4-6.fc6) FE6 > F8 (0:1.4-7.fc6 > 0:1.4-6.fc6) enrico.scholz AT informatik.tu-chemnitz.de: clamav F7-updates-testing > F8 (0:0.91.1-1.fc7 > 0:0.91.1-0.fc8) fedora-usermgmt FE6 > F7 (0:0.10-1.fc6 > 0:0.9-2.fc7) libtasn1 FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE5 > F8 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE6 > F7 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) FE6 > F8 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) mimetic FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7) FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7) util-vserver FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7) FE6 > F7 (0:0.30.213-2.fc6 > 0:0.30.212-3.fc7) xmlrpc-c FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7) FE6 > F7 (0:1.06.16-1.fc6 > 0:1.06.11-2.fc7) foolish AT guezz.net: gtranslator F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8) perl-Net-Libdnet F7-updates > F8 (0:0.01-3.fc7.1 > 0:0.01-2.fc8) perl-Nmap-Parser F7-updates > F8 (0:1.05-4.fc7 > 0:1.05-3.fc8) tcptraceroute FE6 > F7-updates (0:1.5-0.2.beta7.fc6 > 0:1.5-0.1.beta7.fc7) harald AT redhat.com: k3b F7-updates > F8 (0:1.0.3-2.fc7 > 0:1.0.3-1.fc8) jakub AT redhat.com: gcc FC6-updates > F7 (0:4.1.2-13.fc6 > 0:4.1.2-12) jeff AT ocjtech.us: jrtplib FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) lemenkov AT gmail.com: stratagus FE6 > F7 (0:2.2.4-1.fc6 > 0:2.2.3-1.fc7) lkundrak AT redhat.com: cjet F7-updates > F8 (0:0.8.9-4.fc7 > 0:0.8.9-2.fc8) lxtnow AT gmail.com: gammu FE6 > F8 (0:1.12.92-1.fc6 > 0:1.11.0-1.fc8) F7-updates-testing > F8 (0:1.12.92-1.fc7 > 0:1.11.0-1.fc8) python-gammu FE6 > F7-updates (0:0.21-1.fc6 > 0:0.20-1.fc7) FE6 > F8 (0:0.21-1.fc6 > 0:0.20-1.fc7) specto FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8) F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8) meme AT daughtersoftiresias.org: fortune-firefly FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6) FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6) nethack-vultures FE6 > F7 (0:2.1.0-10.fc6 > 0:2.1.0-9.fc7) mikeb AT redhat.com: python-cheetah FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) FE6 > F8 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) nhorman AT redhat.com: irqbalance FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6) FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7) FC5-updates > F8 (2:0.55-4.fc5 > 2:0.55-3.fc8) paul AT xelerance.com: xl2tpd FE6 > F7 (0:1.1.11-2.fc6 > 0:1.1.09-1.fc7) pawsa AT theochem.kth.se: balsa F7-updates > F8 (0:2.3.17-2.fc7 > 0:2.3.17-1.fc8) rdieter AT math.unl.edu: kdeartwork-extras FE6 > F7 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) FE6 > F8 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) kdegraphics-extras FE6 > F7 (0:3.5.7-1.fc6 > 0:3.5.5-1.fc7) FE6 > F8 (0:3.5.7-1.fc6 > 0:3.5.5-1.fc7) kdemultimedia-extras FE6 > F7 (6:3.5.7-1.fc6.5 > 6:3.5.6-5.fc7) FE6 > F8 (6:3.5.7-1.fc6.5 > 6:3.5.6-5.fc7) maxima FE5 > F7-updates (0:5.12.0-3.fc5 > 0:5.12.0-2.fc7) FE6 > F7-updates (0:5.12.0-3.fc6 > 0:5.12.0-2.fc7) rmeggins AT redhat.com: fedora-ds-base FE6 > F8 (0:1.1.0-1.1.fc6 > 0:1.1.0-0.3.20070720.fc8) F7-updates > F8 (0:1.1.0-1.1.fc7 > 0:1.1.0-0.3.20070720.fc8) sandmann AT redhat.com: libgtop2 FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7) splinux AT fedoraproject.org: lostirc FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7) FE6 > F8 (0:0.4.6-3.fc6 > 0:0.4.6-2.fc8) than AT redhat.com: kdepim F7-updates > F8 (6:3.5.7-3.fc7 > 6:3.5.7-2.fc8) tscherf AT redhat.com: Democracy F7-updates > F8 (0:0.9.6-2.fc7 > 0:0.9.5.1-11.fc8) veillard AT redhat.com: libxml2 FC6-updates > F8 (0:2.6.29-1.fc6 > 0:2.6.29-1) F7-updates > F8 (0:2.6.29-1.fc7 > 0:2.6.29-1) ville.skytta AT iki.fi: em8300 FE6 > F7-updates (0:0.16.3-0.1.rc3.fc6 > 0:0.16.3-0.1.rc2.fc7) em8300-kmod FE6 > F7-updates (0:0.16.3-0.2.rc3.2.6.22.1_32.fc6 > 0:0.16.3-0.1.rc2.2.6.22.1_41.fc7) html401-dtds F7-updates-testing > F8 (0:4.01-19991224.5 > 0:4.01-19991224.3.fc6) ---------------------------------------------------------------------- balsa: pawsa AT theochem.kth.se F7-updates > F8 (0:2.3.17-2.fc7 > 0:2.3.17-1.fc8) cjet: lkundrak AT redhat.com F7-updates > F8 (0:0.8.9-4.fc7 > 0:0.8.9-2.fc8) clamav: enrico.scholz AT informatik.tu-chemnitz.de F7-updates-testing > F8 (0:0.91.1-1.fc7 > 0:0.91.1-0.fc8) dbus-python: davidz AT redhat.com F7-updates-testing > F8 (0:0.82.0-2.fc7 > 0:0.82.0-1.fc8) Democracy: tscherf AT redhat.com F7-updates > F8 (0:0.9.6-2.fc7 > 0:0.9.5.1-11.fc8) em8300: ville.skytta AT iki.fi FE6 > F7-updates (0:0.16.3-0.1.rc3.fc6 > 0:0.16.3-0.1.rc2.fc7) em8300-kmod: ville.skytta AT iki.fi FE6 > F7-updates (0:0.16.3-0.2.rc3.2.6.22.1_32.fc6 > 0:0.16.3-0.1.rc2.2.6.22.1_41.fc7) fedora-ds-base: rmeggins AT redhat.com FE6 > F8 (0:1.1.0-1.1.fc6 > 0:1.1.0-0.3.20070720.fc8) F7-updates > F8 (0:1.1.0-1.1.fc7 > 0:1.1.0-0.3.20070720.fc8) fedora-usermgmt: enrico.scholz AT informatik.tu-chemnitz.de FE6 > F7 (0:0.10-1.fc6 > 0:0.9-2.fc7) fortune-firefly: meme AT daughtersoftiresias.org FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6) FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6) gammu: lxtnow AT gmail.com FE6 > F8 (0:1.12.92-1.fc6 > 0:1.11.0-1.fc8) F7-updates-testing > F8 (0:1.12.92-1.fc7 > 0:1.11.0-1.fc8) gcc: jakub AT redhat.com FC6-updates > F7 (0:4.1.2-13.fc6 > 0:4.1.2-12) gtranslator: foolish AT guezz.net F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8) html401-dtds: ville.skytta AT iki.fi F7-updates-testing > F8 (0:4.01-19991224.5 > 0:4.01-19991224.3.fc6) irqbalance: nhorman AT redhat.com FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6) FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7) FC5-updates > F8 (2:0.55-4.fc5 > 2:0.55-3.fc8) jrtplib: jeff AT ocjtech.us FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) k3b: harald AT redhat.com F7-updates > F8 (0:1.0.3-2.fc7 > 0:1.0.3-1.fc8) kdeartwork-extras: rdieter AT math.unl.edu FE6 > F7 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) FE6 > F8 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) kdegraphics-extras: rdieter AT math.unl.edu FE6 > F7 (0:3.5.7-1.fc6 > 0:3.5.5-1.fc7) FE6 > F8 (0:3.5.7-1.fc6 > 0:3.5.5-1.fc7) kdemultimedia-extras: rdieter AT math.unl.edu FE6 > F7 (6:3.5.7-1.fc6.5 > 6:3.5.6-5.fc7) FE6 > F8 (6:3.5.7-1.fc6.5 > 6:3.5.6-5.fc7) kdepim: than AT redhat.com F7-updates > F8 (6:3.5.7-3.fc7 > 6:3.5.7-2.fc8) libgtop2: sandmann AT redhat.com FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7) libtasn1: enrico.scholz AT informatik.tu-chemnitz.de FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE5 > F8 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE6 > F7 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) FE6 > F8 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) libxml2: veillard AT redhat.com FC6-updates > F8 (0:2.6.29-1.fc6 > 0:2.6.29-1) F7-updates > F8 (0:2.6.29-1.fc7 > 0:2.6.29-1) lostirc: splinux AT fedoraproject.org FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7) FE6 > F8 (0:0.4.6-3.fc6 > 0:0.4.6-2.fc8) maxima: rdieter AT math.unl.edu FE5 > F7-updates (0:5.12.0-3.fc5 > 0:5.12.0-2.fc7) FE6 > F7-updates (0:5.12.0-3.fc6 > 0:5.12.0-2.fc7) mimetic: enrico.scholz AT informatik.tu-chemnitz.de FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7) FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7) nethack-vultures: meme AT daughtersoftiresias.org FE6 > F7 (0:2.1.0-10.fc6 > 0:2.1.0-9.fc7) perl-Net-Libdnet: foolish AT guezz.net F7-updates > F8 (0:0.01-3.fc7.1 > 0:0.01-2.fc8) perl-Nmap-Parser: foolish AT guezz.net F7-updates > F8 (0:1.05-4.fc7 > 0:1.05-3.fc8) python-cheetah: mikeb AT redhat.com FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) FE6 > F8 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) python-gammu: lxtnow AT gmail.com FE6 > F7-updates (0:0.21-1.fc6 > 0:0.20-1.fc7) FE6 > F8 (0:0.21-1.fc6 > 0:0.20-1.fc7) scrip: ed AT eh3.com FE6 > F7 (0:1.4-7.fc6 > 0:1.4-6.fc6) FE6 > F8 (0:1.4-7.fc6 > 0:1.4-6.fc6) smart: Axel.Thimm AT ATrpms.net FE6 > F7-updates (0:0.50-47.fc6 > 0:0.50-46.fc7) FE6 > F8 (0:0.50-47.fc6 > 0:0.50-46.fc8) specto: lxtnow AT gmail.com FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8) F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8) stratagus: lemenkov AT gmail.com FE6 > F7 (0:2.2.4-1.fc6 > 0:2.2.3-1.fc7) tcptraceroute: foolish AT guezz.net FE6 > F7-updates (0:1.5-0.2.beta7.fc6 > 0:1.5-0.1.beta7.fc7) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7) FE6 > F7 (0:0.30.213-2.fc6 > 0:0.30.212-3.fc7) xdg-user-dirs: alexl AT redhat.com F7-updates > F8 (0:0.8-3.fc7 > 0:0.8-2.fc8) xl2tpd: paul AT xelerance.com FE6 > F7 (0:1.1.11-2.fc6 > 0:1.1.09-1.fc7) xmlrpc-c: enrico.scholz AT informatik.tu-chemnitz.de FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7) FE6 > F7 (0:1.06.16-1.fc6 > 0:1.06.11-2.fc7) From dominik at greysector.net Fri Aug 17 00:14:14 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 17 Aug 2007 02:14:14 +0200 Subject: Package EVR problems in Fedora 2007-08-16 In-Reply-To: <20070816234404.2269D152131@buildsys.fedoraproject.org> References: <20070816234404.2269D152131@buildsys.fedoraproject.org> Message-ID: <20070817001414.GB15608@ryvius.pekin.waw.pl> On Friday, 17 August 2007 at 01:44, buildsys at fedoraproject.org wrote: [...] > jakub AT redhat.com: > gcc > FC6-updates > F7 (0:4.1.2-13.fc6 > 0:4.1.2-12) Can someone buy Jakub a pint of his favourite beverage so that he finally fixes this? Or whack him with a cluebat, whichever is more effective. This is really important. Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From a.badger at gmail.com Fri Aug 17 01:31:34 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 16 Aug 2007 18:31:34 -0700 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <1187272054.3439.109.camel@dhcp83-165.boston.redhat.com> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <46C3DCA5.9080909@kobold.org> <46C3DF4B.9040105@hhs.nl> <46C44976.7030208@gmail.com> <1187272054.3439.109.camel@dhcp83-165.boston.redhat.com> Message-ID: <46C4FA76.4020005@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom "spot" Callaway wrote: > On Thu, 2007-08-16 at 14:56 +0200, Adel Gadllah wrote: >> Hans de Goede wrote: >>> >>> GPL+, the version in the COPYING file is irrelevant. >> this sounds wrong ... if the source says nothing and the copying says >> gplv2 it _is_ gplv2. > > COPYING does not signal licensing intent (it might not seem intuitive, > but this is what Red Hat legal told us, and we're going by that). > > The order of operations goes like this: > > 1. What does the code say? If it specifies a version, that's what it is. > 2. Does the code conflict with itself? (file1.c and file2.c are compiled > together but have different licensing) > 2A. Are the conflicting licenses compatible? > 2AA. Does one license overpower the other one? (GPL/LGPL does this) If > so, the strictest license wins. > 3. What does the documentation say? This signals the author(s) > intentions from a legal perspective, although, not as binding as in the > source. If the documentation specifies a version when the source does > not, then we can use the documentation as our source. NOTE: COPYING does > not count as documentation, since the author(s) didn't write it. > 4. If neither the source, nor the upstream composed documentation says > anything about the license version, then it could be under _ANY_ version > of the GPL. The version listed in COPYING is irrelevant from this > perspective. > > Now, keep in mind that most upstreams are probably leaving the > versioning out by accident. If you get to case 4, you definitely want to > let upstream know that you are unable to determine the applicable > version(s) of the license from the source and documentation. They'll > almost certainly let you know what their intended license version is, > and (hopefully) correct it in the upstream source. > Actually spot, I have to disagree with you slightly here. If COPYING doesn't signal licensing intent, then those programs which have no license information in the source (like abe, apparently) *are not licensed*. Which means that we can't distribute them. This could even be carried out to mean that a program which lacks licensing information in one necessary source file would make the whole work not licensed for us to do anything with. Either COPYING has a meaning or it doesn't. OTOH, it is probably more common for there to be a COPYING(v2 or v3) file in the source tarball and a source header that says "GPL". In that case, I would say we *should not put GPL+ in the License field* if at all possible. The reason is that whatever the legal technicalities of the situation are, the author of the software included a GPLv3 license file and wrote something that was a common shorthand for that license file at the time the software was written. Whether or not we're legally correct in writing GPL+, we don't want to piss off (and possibly get [unsuccessfully] sued by) an author that says, "I meant GPLvX who the fuck are you to steal my work?" In an even more practical vein, if we put GPL+ in the license field and someone takes our word for it, goes off and starts using it as a GPLv1 instead of GPLv3, then we're right in the middle of causing everybody a lot of pain when the licensing is clarified for all involved. If, OTOH, we write GPLv3+, (which is legal for us to do even if the original is technically GPL+) and someone licenses their code as GPLv3 because of it, the most harm we've done is caused someone to use the GPLv3 when they could have used GPL+. Please, go back to common sense with this one and do what the vast majority of authors intended by putting a GPLv2 COPYING file in their source tarball, not what we know is the most liberal licensing that we can legally distribute their code under. - -Toshi -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGxPp2X6yAic2E7kgRAuPmAJ9DvKuJyZAgaQjsCZ5LiwDLcOUJMQCfYAB5 TWMJ6Zqn3bMAmgBsmbXn66k= =c1lx -----END PGP SIGNATURE----- From jwboyer at jdub.homelinux.org Fri Aug 17 01:47:01 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 16 Aug 2007 20:47:01 -0500 Subject: The open() system call in f8 really broken... In-Reply-To: <20070816230608.GA18576@redhat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4605B.1000407@RedHat.com> <46C461C6.5080302@linux-kernel.at> <46C46558.1000905@RedHat.com> <46C4685F.8080601@linux-kernel.at> <20070816202138.GA15542@redhat.com> <20070816203637.GA10486@redhat.com> <20070816230608.GA18576@redhat.com> Message-ID: <20070816204701.30ea8bdf@vader.jdub.homelinux.org> On Thu, 16 Aug 2007 19:06:08 -0400 Dave Jones wrote: > On Thu, Aug 16, 2007 at 04:36:37PM -0400, Dave Jones wrote: > > On Thu, Aug 16, 2007 at 04:21:38PM -0400, Dave Jones wrote: > > > On Thu, Aug 16, 2007 at 05:08:15PM +0200, Oliver Falk wrote: > > > > > > > If you compile the whole Fedora tree, how many warnings will > > > > you see? > > > > > > So I grepped across a make prep'd tree of devel (all 63 gig of > > > it). Here's the fallout.. > > > > > > openmpi/openmpi-1.2.3/orte/runtime/orte_abort.c fd = > > > open(abort_file, O_CREAT); > > > jython/jython-svn-Release_2_2beta1/CPythonLib/test/test_unicode_file.py:f > > > = os.open(TESTFN_ENCODED, os.O_CREAT) > > > perl/perl-5.8.8/t/op/taint.t: eval { sysopen(my $cr, $evil, > > > &O_CREAT) }; proftpd/proftpd-1.3.0a/contrib/mod_rewrite.c: > > > if ((fifo_lockfd = open(fifo_lockname, O_CREAT)) < 0) > > > pwlib/pwlib-1.10.7/configure:sem_t *s = sem_open("test", > > > O_CREAT) pwlib/pwlib-1.10.7/configure.ac: > > > [sem_t *s = sem_open("test", O_CREAT)], > > > python/Python-2.5.1/Lib/test/test_unicode_file.py: f = > > > os.open(filename, os.O_CREAT) > > > python-docs/Python-2.5.1/Lib/test/test_unicode_file.py: > > > f = os.open(filename, os.O_CREAT) > > > xca/xca-0.6.3/_tmp_root/usr/lib/python2.5/test/test_unicode_file.py: > > > f = os.open(filename, os.O_CREAT) > > > > > > Not too bad considering. > > > > Bah, my regexp was imperfect. I'll fix up and rerun. > > More like it. 267 hits. > Checking ./jfsutils/jfsutils-1.1.11/libfs/fssubs.c > Found open with O_CREAT and no mode. > fd = open(TEST_FILE, O_RDWR | O_CREAT); Hrm. I'll take a look at this one soon. > Checking ./glibc/glibc-20070804T2027/login/tst-grantpt.c > Found open with O_CREAT and no mode. > fd = open(file, O_RDWR | O_CREAT); Hehe... I find that ironic. josh From rc040203 at freenet.de Fri Aug 17 03:50:06 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 17 Aug 2007 05:50:06 +0200 Subject: Successful build failed Message-ID: <1187322606.14035.423.camel@mccallum.corsepiu.local> A successful build job failed: ----snip ---- Job failed on arch noarch Build logs may be found at http://buildsys.fedoraproject.org/logs/fedora-6-extras/35707-perl-Class-ReturnValue-0.54-1.fc6/ ------------------------------------------------- Files=1, Tests=32, 0 wallclock secs ( 0.06 cusr + 0.01 csys = 0.07 CPU) + exit 0 Processing files: perl-Class-ReturnValue-0.54-1.fc6 Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.32659 + umask 022 + cd /builddir/build/BUILD + cd Class-ReturnValue-0.54 + DOCDIR=/var/tmp/perl-Class-ReturnValue-0.54-1.fc6-root-mockbuild/usr/share/doc/perl-Class-ReturnValue-0.54 + export DOCDIR + rm -rf /var/tmp/perl-Class-ReturnValue-0.54-1.fc6-root-mockbuild/usr/share/doc/perl-Class-ReturnValue-0.54 + /bin/mkdir -p /var/tmp/perl-Class-ReturnValue-0.54-1.fc6-root-mockbuild/usr/share/doc/perl-Class-ReturnValue-0.54 + cp -pr Changes /var/tmp/perl-Class-ReturnValue-0.54-1.fc6-root-mockbuild/usr/share/doc/perl-Class-ReturnValue-0.54 + exit 0 Provides: perl(Class::ReturnValue) = 0.54 Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(VersionedDependencies) <= 3.0.3-1 Requires: perl(:MODULE_COMPAT_5.8.8) perl(Carp) perl(Data::Dumper) perl(Devel::StackTrace) perl(Exporter) perl(overload) perl(strict) perl(vars) perl(warnings) Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/perl-Class-ReturnValue-0.54-1.fc6-root-mockbuild warning: Could not canonicalize hostname: ppc2.fedora.redhat.com Wrote: /builddir/build/RPMS/perl-Class-ReturnValue-0.54-1.fc6.noarch.rpm Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.32659 + umask 022 + cd /builddir/build/BUILD + cd Class-ReturnValue-0.54 + rm -rf /var/tmp/perl-Class-ReturnValue-0.54-1.fc6-root-mockbuild + exit 0 Executing(--clean): /bin/sh -e /var/tmp/rpm-tmp.32659 + umask 022 + cd /builddir/build/BUILD + rm -rf Class-ReturnValue-0.54 + exit 0 ---- snip ---- I can't spot what's wrong with it. From skvidal at fedoraproject.org Fri Aug 17 03:55:22 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 16 Aug 2007 23:55:22 -0400 Subject: Successful build failed In-Reply-To: <1187322606.14035.423.camel@mccallum.corsepiu.local> References: <1187322606.14035.423.camel@mccallum.corsepiu.local> Message-ID: <1187322922.22540.23.camel@cutter> On Fri, 2007-08-17 at 05:50 +0200, Ralf Corsepius wrote: > A successful build job failed: > > Build logs may be found at > http://buildsys.fedoraproject.org/logs/fedora-6-extras/35707-perl-Class-ReturnValue-0.54-1.fc6/ > > I can't see a failure here, either. however, it's extremely ironic to me that we're looking for a return code from a package called Class-ReturnValue. -sv From lightsolphoenix at gmail.com Fri Aug 17 04:23:33 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Fri, 17 Aug 2007 00:23:33 -0400 Subject: Successful build failed In-Reply-To: <1187322606.14035.423.camel@mccallum.corsepiu.local> References: <1187322606.14035.423.camel@mccallum.corsepiu.local> Message-ID: <200708170023.34257.lightsolphoenix@gmail.com> On Thursday, August 16, 2007 11:50:06 pm Ralf Corsepius wrote: > A successful build job failed: I don't want to insult anybody, so don't take this the wrong way, but... Who is the idiot who wrote THAT error message? It makes no sense at all. If the job failed, it isn't successful, is it? -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From rc040203 at freenet.de Fri Aug 17 04:28:16 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 17 Aug 2007 06:28:16 +0200 Subject: Successful build failed In-Reply-To: <200708170023.34257.lightsolphoenix@gmail.com> References: <1187322606.14035.423.camel@mccallum.corsepiu.local> <200708170023.34257.lightsolphoenix@gmail.com> Message-ID: <1187324896.14035.427.camel@mccallum.corsepiu.local> On Fri, 2007-08-17 at 00:23 -0400, Kelly wrote: > On Thursday, August 16, 2007 11:50:06 pm Ralf Corsepius wrote: > > A successful build job failed: > > I don't want to insult anybody, so don't take this the wrong way, but... > > Who is the idiot who wrote THAT error message? It makes no sense at all. If > the job failed, it isn't successful, is it? Too little coffee this morning or too much brews this evening (Depending on your timezone), I presuppose ? Building actually was successful, but plague bogusly reported it as having failed! Ralf From ville.skytta at iki.fi Fri Aug 17 06:00:32 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Fri, 17 Aug 2007 09:00:32 +0300 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <46C4FA76.4020005@gmail.com> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <1187272054.3439.109.camel@dhcp83-165.boston.redhat.com> <46C4FA76.4020005@gmail.com> Message-ID: <200708170900.32388.ville.skytta@iki.fi> On Friday 17 August 2007, Toshio Kuratomi wrote: > Please, go back to common sense with this one and do what the vast > majority of authors intended by putting a GPLv2 COPYING file in their > source tarball, not what we know is the most liberal licensing that we > can legally distribute their code under. -1 Again, the COPYING they put there explicitly says "If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation." Guessing that they actually meant v2 or something else when the files they actually put in the distribution themselves _explicitly say otherwise_, and labeling them according to our guess without asking for clarification would be pretty damn arrogant, and plain wrong. From harald at redhat.com Fri Aug 17 06:02:42 2007 From: harald at redhat.com (Harald Hoyer) Date: Fri, 17 Aug 2007 08:02:42 +0200 Subject: Package EVR problems in Fedora 2007-08-16 In-Reply-To: <20070816234404.2269D152131@buildsys.fedoraproject.org> References: <20070816234404.2269D152131@buildsys.fedoraproject.org> Message-ID: <46C53A02.703@redhat.com> buildsys at fedoraproject.org schrieb: > gcc: jakub AT redhat.com > FC6-updates > F7 (0:4.1.2-13.fc6 > 0:4.1.2-12) This also hit me in the process of updating to F7... -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3623 bytes Desc: S/MIME Cryptographic Signature URL: From ville.skytta at iki.fi Fri Aug 17 06:03:48 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Fri, 17 Aug 2007 09:03:48 +0300 Subject: The open() system call in f8 really broken... In-Reply-To: <20070816230608.GA18576@redhat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816203637.GA10486@redhat.com> <20070816230608.GA18576@redhat.com> Message-ID: <200708170903.48698.ville.skytta@iki.fi> On Friday 17 August 2007, Dave Jones wrote: > > More like it. 267 hits. Thanks, Dave! > Checking ./lirc/lirc-0.8.2/daemons/slinke.c > Found open with O_CREAT and no mode. > fd = open(remote->name, O_CREAT | O_EXCL | O_RDWR); > > Checking ./dvb-apps/linuxtv-dvb-apps-1.1.1/test/test.c > Found open with O_CREAT and no mode. > int vout = open("qv", O_RDWR | O_CREAT); > int aout = open("qa", O_RDWR | O_CREAT); Neither of these are compiled in the current lirc and dvb-apps packages. test.c is compiled in <= F-7 dvb-apps, but the resulting executable is not invoked during build nor shipped. Will send patches upstream anyway. From rc040203 at freenet.de Fri Aug 17 06:25:13 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 17 Aug 2007 08:25:13 +0200 Subject: Successful build failed In-Reply-To: <1187322922.22540.23.camel@cutter> References: <1187322606.14035.423.camel@mccallum.corsepiu.local> <1187322922.22540.23.camel@cutter> Message-ID: <1187331913.14035.431.camel@mccallum.corsepiu.local> On Thu, 2007-08-16 at 23:55 -0400, seth vidal wrote: > On Fri, 2007-08-17 at 05:50 +0200, Ralf Corsepius wrote: > > A successful build job failed: > > > > Build logs may be found at > > http://buildsys.fedoraproject.org/logs/fedora-6-extras/35707-perl-Class-ReturnValue-0.54-1.fc6/ > > > > > > I can't see a failure here, either. Another one: http://buildsys.fedoraproject.org/logs/fedora-6-extras/35710-perl-Class-Inspector-1.17-1.fc6/noarch/ Common to both build errors: building a noarch-perl package on ppc2 (ppc64) > however, it's extremely ironic to me > that we're looking for a return code from a package called > Class-ReturnValue. ;) Ralf From fedora at leemhuis.info Fri Aug 17 06:31:12 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 17 Aug 2007 08:31:12 +0200 Subject: Successful build failed In-Reply-To: <1187331913.14035.431.camel@mccallum.corsepiu.local> References: <1187322606.14035.423.camel@mccallum.corsepiu.local> <1187322922.22540.23.camel@cutter> <1187331913.14035.431.camel@mccallum.corsepiu.local> Message-ID: <46C540B0.1040704@leemhuis.info> On 17.08.2007 08:25, Ralf Corsepius wrote: > On Thu, 2007-08-16 at 23:55 -0400, seth vidal wrote: >> On Fri, 2007-08-17 at 05:50 +0200, Ralf Corsepius wrote: >>> A successful build job failed: >>> Build logs may be found at >>> http://buildsys.fedoraproject.org/logs/fedora-6-extras/35707-perl-Class-ReturnValue-0.54-1.fc6/ >> I can't see a failure here, either. > Another one: [...] Just a fyi note: that seems to be a problem that's happening now and then since some days with plague -- iirc I've seen similar reports from people building for EPEL. Not sure how they fixed it, but "simply rebuilding some hours later" was the workaround afaik. CU thl From a.badger at gmail.com Fri Aug 17 06:46:39 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 16 Aug 2007 23:46:39 -0700 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <200708170900.32388.ville.skytta@iki.fi> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <1187272054.3439.109.camel@dhcp83-165.boston.redhat.com> <46C4FA76.4020005@gmail.com> <200708170900.32388.ville.skytta@iki.fi> Message-ID: <46C5444F.9040308@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ville Skytt? wrote: > On Friday 17 August 2007, Toshio Kuratomi wrote: > >> Please, go back to common sense with this one and do what the vast >> majority of authors intended by putting a GPLv2 COPYING file in their >> source tarball, not what we know is the most liberal licensing that we >> can legally distribute their code under. > > -1 > > Again, the COPYING they put there explicitly says "If the Program does not > specify a version number of this License, you may choose any version ever > published by the Free Software Foundation." > > Guessing that they actually meant v2 or something else when the files they > actually put in the distribution themselves _explicitly say otherwise_, and > labeling them according to our guess without asking for clarification would > be pretty damn arrogant, and plain wrong. > Labeling them as GPLv1+ is also arrogant and just as wrong to a non-lawyer. When I read that clause and used the GPLv2 COPYING file with my own code, I assumed that putting a GPLv2 COPYING file counted as "specify a version number of this License". This mumble jumbo about "it only counts if you modify the COPYING file to show that you actually mean it" is something I heartily disagree with. Fortunately I'm not a lawyer, so *legally* I'm wrong ;-) But I think I'm very much right common sensically. If I were to write a COPYING file that was word-for-word the GPLv2 but everyone knew that I had written it, then it would be GPLv2 or later? Whereas if I stick the GPLv2 license from the FSF in the tarball it is GPL1+? It's not common sense that including a GPLv2 COPYING file makes a work GPLv1, as spot says: "COPYING does not signal licensing intent (it might not seem intuitive, but this is what Red Hat legal told us, and we're going by that)." If my assessment of damage done by legally releasing as GPLv1+ despite the author's intent vs legally releasing as GPLv(COPYING file version)+ despite the author's intent is correct, then it seems much more damaging to err on the side of the earlier version than on the later one. As an alternative, we could have some boilerplate that specifically explains the situation to the upstream author when we encounter a bare "GPL" in the source code: ''' Hi, We're packaging your software for Fedora 8. As part of the process we're trying to make sure that every piece of software is tagged with the proper license information. We noticed that you have a copy of the GPLv2 in your source tarball but your code contains simple, unversioned GPL licensing. According to the GPLv2, section 9 "If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation." This means that your work is officially being published under any version of the GPL (currently GPLv1, v2, or v3). Please let us know if this is your intent or if you A) wanted to license it under a specific version (GPLv2) or B) wanted to license it under a specific version or later (GPLv2 or later). In addition, changing the information in the sources to reflect the version you desire will make it all legally official and stop you from getting this same message from other distributions when they decide to do a license audit :-) Thanks for clarifying this for us, Your Friendly Neighborhood Fedora Packager ''' P.S.: Do you agree or disagree with my assessment that a COPYING file in the tarball and no licensing information in the source means the program is unlicensed and therefore we must get a license from the author or have to stop shipping the package in Fedora? - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGxURPX6yAic2E7kgRAiOTAJ0WQV2kj3OMRgiMvFMD3ApoKNJdygCghZMr OQQob+SFMTXudSBNYso9o0M= =Qt9H -----END PGP SIGNATURE----- From oliver at linux-kernel.at Fri Aug 17 07:15:13 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 17 Aug 2007 09:15:13 +0200 Subject: The open() system call in f8 really broken... In-Reply-To: <20070816230608.GA18576@redhat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4605B.1000407@RedHat.com> <46C461C6.5080302@linux-kernel.at> <46C46558.1000905@RedHat.com> <46C4685F.8080601@linux-kernel.at> <20070816202138.GA15542@redhat.com> <20070816203637.GA10486@redhat.com> <20070816230608.GA18576@redhat.com> Message-ID: <46C54B01.3050600@linux-kernel.at> On 08/17/2007 01:06 AM, Dave Jones wrote: > On Thu, Aug 16, 2007 at 04:36:37PM -0400, Dave Jones wrote: > > On Thu, Aug 16, 2007 at 04:21:38PM -0400, Dave Jones wrote: > > > On Thu, Aug 16, 2007 at 05:08:15PM +0200, Oliver Falk wrote: > > > > > > > If you compile the whole Fedora tree, how many warnings will you see? > > > > > > So I grepped across a make prep'd tree of devel (all 63 gig of it). > > > Here's the fallout.. > > > > > > openmpi/openmpi-1.2.3/orte/runtime/orte_abort.c fd = open(abort_file, O_CREAT); > > > jython/jython-svn-Release_2_2beta1/CPythonLib/test/test_unicode_file.py:f = os.open(TESTFN_ENCODED, os.O_CREAT) > > > perl/perl-5.8.8/t/op/taint.t: eval { sysopen(my $cr, $evil, &O_CREAT) }; > > > proftpd/proftpd-1.3.0a/contrib/mod_rewrite.c: if ((fifo_lockfd = open(fifo_lockname, O_CREAT)) < 0) > > > pwlib/pwlib-1.10.7/configure:sem_t *s = sem_open("test", O_CREAT) > > > pwlib/pwlib-1.10.7/configure.ac: [sem_t *s = sem_open("test", O_CREAT)], > > > python/Python-2.5.1/Lib/test/test_unicode_file.py: f = os.open(filename, os.O_CREAT) > > > python-docs/Python-2.5.1/Lib/test/test_unicode_file.py: f = os.open(filename, os.O_CREAT) > > > xca/xca-0.6.3/_tmp_root/usr/lib/python2.5/test/test_unicode_file.py: f = os.open(filename, os.O_CREAT) > > > > > > Not too bad considering. > > > > Bah, my regexp was imperfect. I'll fix up and rerun. > > More like it. 267 hits. > > Dave > > Checking ./aqbanking/aqbanking-2.3.2/src/libs/aqbanking/httpsession.c > Found open with O_CREAT and no mode. > fdWrite = open(DIALOG_LOGFILE_BASE ".out", O_WRONLY | O_CREAT); > > Checking ./aqbanking/aqbanking-2.3.2/src/plugins/backends/aqhbci/plugin/msglayer/message.c > Found open with O_CREAT and no mode. > fd = open(logFile, O_RDWR | O_CREAT | O_APPEND); > > Checking ./grass/grass-6.2.2-fedora/raster/r.drain/main.c > Found open with O_CREAT and no mode. > fe = open(tempfile1, O_RDWR | O_CREAT); > fd = open(tempfile2, O_RDWR | O_CREAT); > > Checking ./grass/grass-6.2.2-fedora/raster/r.fill.dir/main.c > Found open with O_CREAT and no mode. > fe = open(tempfile1, O_RDWR | O_CREAT); /* elev */ > fd = open(tempfile2, O_RDWR | O_CREAT); /* dirn */ > fm = open(tempfile3, O_RDWR | O_CREAT); /* problems */ > > Checking ./openmpi/openmpi-1.2.3/orte/runtime/orte_abort.c > Found open with O_CREAT and no mode. > fd = open(abort_file, O_CREAT); > > Checking ./compat-gcc-32/gcc-3.2.3-20040701/gcc/collect2.c > Found open with O_CREAT and no mode. > redir_handle = open(redir, O_WRONLY | O_TRUNC | O_CREAT); > > Checking ./nessus-core/nessus-core/nessusd/detached.c > Found open with O_CREAT and no mode. > int f = open(fname, O_CREAT | O_WRONLY | O_TRUNC); > > Checking ./libxml2/libxml2-2.6.29/nanohttp.c > Found open with O_CREAT and no mode. > fd = open(filename, O_CREAT | O_WRONLY); > > Checking ./hdf5/hdf5-1.6.5/perform/pio_engine.c > Found open with O_CREAT and no mode. > hrc = do_fopen(¶m, fname, &fd, PIO_CREATE | PIO_WRITE); > > Checking ./hdf5/hdf5-1.6.5/perform/zip_perf.c > Found open with O_CREAT and no mode. > output = open(filename, O_RDWR | O_CREAT); > > Checking ./dd_rescue/dd_rescue/dd_rescue.c > Found open with O_CREAT and no mode. > c = openfile(lname, O_WRONLY | O_CREAT /*| O_EXCL */ ); > > Checking ./hal/hal-0.5.10/tools/hal-acl-tool.c > Found open with O_CREAT and no mode. > open(PACKAGE_LOCALSTATEDIR "/lib/hal/acl-list", O_CREAT | O_RDWR); > > Checking ./ettercap/ettercap-NG-0.7.3/src/ec_log.c > Found open with O_CREAT and no mode. > fd->fd = open(filename, O_CREAT | O_TRUNC | O_RDWR | O_BINARY); > > Checking ./openhpi/openhpi-2.8.1/utils/uid_utils.c > Found open with O_CREAT and no mode. > file = open(uid_map_file, O_WRONLY | O_CREAT | O_TRUNC); > > Checking ./openhpi/openhpi-2.8.1/utils/t/epath/uid_utils.c > Found open with O_CREAT and no mode. > file = open(uid_map_file, O_WRONLY | O_CREAT | O_TRUNC); > > Checking ./openhpi/openhpi-2.8.1/utils/t/uid/uid_utils.c > Found open with O_CREAT and no mode. > file = open(uid_map_file, O_WRONLY | O_CREAT | O_TRUNC); > > Checking ./openhpi/openhpi-2.8.1/utils/t/rpt/uid_utils.c > Found open with O_CREAT and no mode. > file = open(uid_map_file, O_WRONLY | O_CREAT | O_TRUNC); > > Checking ./openhpi/openhpi-2.8.1/utils/t/sahpi/uid_utils.c > Found open with O_CREAT and no mode. > file = open(uid_map_file, O_WRONLY | O_CREAT | O_TRUNC); > > Checking ./libburn/libburn-0.2.6.3/cdrskin/cdrfifo.c > Found open with O_CREAT and no mode. > fd = open(argv[i] + 3, O_WRONLY | O_CREAT); > > Checking ./snort/snort-2.6.1.4/src/util.c > Found open with O_CREAT and no mode. > open("/tmp/snort.debug", O_CREAT | O_RDWR); > > Checking ./snort/snort-2.6.1.4/src/preprocessors/flow/portscan/server_stats.c > Found open with O_CREAT and no mode. > fd = open(filename, O_CREAT | O_TRUNC | O_SYNC | O_WRONLY); > > Checking ./tgif/tgif-QPL-4.1.45/util.c > Found open with O_CREAT and no mode. > fd = open(buf, O_CREAT | O_EXCL | O_WRONLY); > > Checking ./tgif/tgif-QPL-4.1.45/file.c > Found open with O_CREAT and no mode. > int fd = open(buf, O_CREAT | O_EXCL | O_WRONLY); > > Checking ./neon/neon-0.25.5/test/request.c > Found open with O_CREAT and no mode. > fd = open(fn, O_RDWR | O_CREAT); > > Checking ./yap/Yap-5.1.1/C/alloc.c > Found open with O_CREAT and no mode. > fd = open(file, O_CREAT | O_RDWR); > fd = open(file, O_CREAT | O_RDWR); > > Checking ./allegro/allegro-4.2.2/src/file.c > Found open with O_CREAT and no mode. > _al_open(tmp_name, O_RDWR | O_BINARY | O_CREAT | O_EXCL); > > Checking ./dx/dx-4.4.4/src/exec/libdx/fileio.c > Found open with O_CREAT and no mode. > fd = open(name, O_WRONLY | O_CREAT); > > Checking ./acpid/acpid-1.0.4/acpid.c > Found open with O_CREAT and no mode. > logfd = open(logfile, O_WRONLY | O_CREAT | O_APPEND); > > Checking ./aircrack-ng/aircrack-ng-0.9.1/src/aireplay-ng.c > Found open with O_CREAT and no mode. > dev.nofcs = open(location, O_WRONLY | O_CREAT); > > Checking ./mbuffer/mbuffer-20070502/mbuffer.c > Found open with O_CREAT and no mode. > Tmp = open(Tmpfile, O_RDWR | O_CREAT | O_EXCL); > > Checking ./initscripts/initscripts-8.55/src/rename_device.c > Found open with O_CREAT and no mode. > lockfd = open(LOCKFILE, O_RDWR | O_CREAT | O_EXCL); > > Checking ./elinks/elinks-0.11.3/src/osdep/win32/win32.c > Found open with O_CREAT and no mode. > return open(tempname, O_CREAT | O_WRONLY | O_EXCL | O_BINARY); > > Checking ./mysql/mysql-5.0.45/netware/my_manage.c > Found open with O_CREAT and no mode. > wiring.outfd = open(output, O_WRONLY | O_CREAT | O_TRUNC); > wiring.errfd = open(error, O_WRONLY | O_CREAT | O_TRUNC); > > Checking ./nessus-libraries/nessus-libraries/libnessus/network.c > Found open with O_CREAT and no mode. > lock_fd = open(NESSUS_CNX_LOCK, O_RDWR | O_CREAT); > > Checking ./compat-erlang/otp_src_R10B-10/erts/etc/unix/run_erl.c > Found open with O_CREAT and no mode. > lfd = open_log(lognum, O_RDWR | O_APPEND | O_CREAT | O_SYNC); > *lfd = open_log(*log_num, O_RDWR | O_CREAT | O_TRUNC | O_SYNC); > > Checking ./doodle/doodle-0.6.6/src/doodle/doodled.c > Found open with O_CREAT and no mode. > nullfd = open("/dev/null", O_CREAT | O_RDWR | O_APPEND); > > Checking ./xorg-x11-drv-i810/xf86-video-intel-2.1.0/src/bios_reader/bios_dumper.c > Found open with O_CREAT and no mode. > fd = open(argv[1], O_RDWR | O_CREAT | O_TRUNC); > > Checking ./openais/openais-0.80.1/exec/keygen.c > Found open with O_CREAT and no mode. > authkey_fd = open("/etc/ais/authkey", O_CREAT | O_WRONLY); > > Checking ./elektra/elektra-0.6.10/src/backends/ini/helpers.c > Found open with O_CREAT and no mode. > fd = open(filename, posix_mode | O_CREAT); > > Checking ./libdsk/libdsk-1.1.12/tools/serslave.c > Found open with O_CREAT and no mode. > outfd = open(filename, O_CREAT | O_WRONLY | O_APPEND | O_NONBLOCK); > > Checking ./ImageMagick/ImageMagick-6.3.2/magick/delegate.c > Found open with O_CREAT and no mode. > destination_file = open(destination, O_WRONLY | O_BINARY | O_CREAT); > > Checking ./Coin2/Coin-2.4.6/src/tidbits.c > Found open with O_CREAT and no mode. > nullfd = open(tmpname, O_CREAT | O_WRONLY); > > Checking ./cdogs-sdl/cdogs-sdl-0.4/src/files.c > Found open with O_CREAT and no mode. > f = open(filename, O_WRONLY | O_CREAT | O_TRUNC); > > Checking ./dietlibc/dietlibc-0.30/test/mmap_test.c > Found open with O_CREAT and no mode. > fd = open(FILENAME, O_RDWR | O_CREAT); > > Checking ./rhythmbox/rhythmbox-0.11.1/plugins/daap/rb-daap-structure.c > Found open with O_CREAT and no mode. > fd = open(PARSE_DEBUG_FILE, O_WRONLY | O_CREAT); > > Checking ./gwenhywfar/gwenhywfar-2.6.1/test/gwentest.c > Found open with O_CREAT and no mode. > fd = open(outFile, O_CREAT | O_WRONLY); > fd = open(outFile, O_CREAT | O_WRONLY); > fd = open(outFile, O_CREAT | O_WRONLY); > > Checking ./libchewing/libchewing-0.3.0/src/porting_layer/src/plat_mmap_posix.c > Found open with O_CREAT and no mode. > handle->fd = open(file, O_RDWR | O_CREAT); > > Checking ./kst/kst-1.4.0/kst/src/datasources/dirfile/getdata.c > Found open with O_CREAT and no mode. > R->fp = open(datafilename, O_RDWR | O_CREAT); > > Checking ./jfsutils/jfsutils-1.1.11/libfs/fssubs.c > Found open with O_CREAT and no mode. > fd = open(TEST_FILE, O_RDWR | O_CREAT); > > Checking ./arm-gp2x-linux-glibc/arm-gp2x-linux-glibc-2.3.6/glibc-2.3.6/login/tst-grantpt.c > Found open with O_CREAT and no mode. > fd = open(file, O_RDWR | O_CREAT); > > Checking ./heartbeat/heartbeat-2.0.8/lib/clplumbing/cl_msg.c > Found open with O_CREAT and no mode. > return open(filename, O_WRONLY | O_CREAT | O_APPEND); > > Checking ./brltty/brltty-3.7.2/Programs/config.c > Found open with O_CREAT and no mode. > int fd = open(preferencesFile, O_WRONLY | O_CREAT | O_TRUNC); > > Checking ./brltty/brltty-3.7.2/BrailleDrivers/EcoBraille/braille.c > Found open with O_CREAT and no mode. > brl_log = open("/tmp/brllog", O_CREAT | O_WRONLY); > > Checking ./t1lib/t1lib-5.1.1/lib/t1lib/t1outline.c > if with ; at EOL! > if (ipath->type == TEXTTYPE); > > Checking ./bombardier/bombardier-0.8.2/hof.c > Found open with O_CREAT and no mode. > fd = open("/var/games/bombardier/bdscore", O_RDWR | O_CREAT); > > Checking ./squid/squid-2.6.STABLE14/src/fs/diskd/store_dir_diskd.c > Found open with O_CREAT and no mode. > fd = file_open(path, O_WRONLY | O_CREAT | O_BINARY); > fd = file_open(swaplog_path, O_WRONLY | O_CREAT | O_BINARY); > fd = file_open(new_path, O_WRONLY | O_CREAT | O_TRUNC | O_BINARY); > file_open(state->new, O_WRONLY | O_CREAT | O_TRUNC | O_BINARY); > > Checking ./squid/squid-2.6.STABLE14/src/fs/aufs/store_dir_aufs.c > Found open with O_CREAT and no mode. > fd = file_open(path, O_WRONLY | O_CREAT | O_BINARY); > fd = file_open(swaplog_path, O_WRONLY | O_CREAT | O_BINARY); > fd = file_open(new_path, O_WRONLY | O_CREAT | O_TRUNC | O_BINARY); > file_open(state->new, O_WRONLY | O_CREAT | O_TRUNC | O_BINARY); > > Checking ./squid/squid-2.6.STABLE14/src/fs/aufs/store_io_aufs.c > Found open with O_CREAT and no mode. > fd = file_open(path, O_WRONLY | O_CREAT | O_TRUNC | O_BINARY); > > Checking ./squid/squid-2.6.STABLE14/src/fs/coss/store_dir_coss.c > Found open with O_CREAT and no mode. > fd = file_open(path, O_WRONLY | O_CREAT | O_BINARY); > cs->fd = file_open(stripePath(sd), O_RDWR | O_CREAT | O_BINARY); > fd = file_open(swaplog_path, O_WRONLY | O_CREAT | O_BINARY); > fd = file_open(new_path, O_WRONLY | O_CREAT | O_TRUNC | O_BINARY); > file_open(state->new, O_WRONLY | O_CREAT | O_TRUNC | O_BINARY); > > Checking ./squid/squid-2.6.STABLE14/src/fs/ufs/store_dir_ufs.c > Found open with O_CREAT and no mode. > fd = file_open(path, O_WRONLY | O_CREAT | O_BINARY); > fd = file_open(swaplog_path, O_WRONLY | O_CREAT | O_BINARY); > fd = file_open(new_path, O_WRONLY | O_CREAT | O_TRUNC | O_BINARY); > file_open(state->new, O_WRONLY | O_CREAT | O_TRUNC | O_BINARY); > > Checking ./squid/squid-2.6.STABLE14/src/tools.c > Found open with O_CREAT and no mode. > fd = file_open(f, O_WRONLY | O_CREAT | O_TRUNC | O_TEXT); > > Checking ./squid/squid-2.6.STABLE14/src/logfile.c > Found open with O_CREAT and no mode. > int fd = file_open(path, O_WRONLY | O_CREAT | O_TEXT); > lf->fd = file_open(lf->path, O_WRONLY | O_CREAT | O_TEXT); > > Checking ./postgresql/postgresql-8.2.4/src/backend/storage/smgr/md.c > Found open with O_CREAT and no mode. > v->mdfd_chain = _mdfd_openseg(reln, segno, O_CREAT); > > Checking ./nethack-vultures/vultures-2.1.0/slashem/win/gem/bitmfile.c > Found open with O_CREAT and no mode. > file = open(filename, O_WRONLY | O_CREAT | O_TRUNC); > > Checking ./nethack-vultures/vultures-2.1.0/slashem/util/recover.c > Found open with O_CREAT and no mode. > out = open(iconfile, O_WRONLY | O_TRUNC | O_CREAT); > > Checking ./nethack-vultures/vultures-2.1.0/nethack/win/gem/bitmfile.c > Found open with O_CREAT and no mode. > file = open(filename, O_WRONLY | O_CREAT | O_TRUNC); > > Checking ./nethack-vultures/vultures-2.1.0/nethack/util/recover.c > Found open with O_CREAT and no mode. > out = open(iconfile, O_WRONLY | O_TRUNC | O_CREAT); > > Checking ./nethack-vultures/vultures-2.1.0/nethack/util/lev_main.c > Found open with O_CREAT and no mode. > fout = open(lbuf, O_WRONLY | O_CREAT | O_BINARY); > > Checking ./nethack/nethack-3.4.3/win/gem/bitmfile.c > Found open with O_CREAT and no mode. > file = open(filename, O_WRONLY | O_CREAT | O_TRUNC); > > Checking ./nethack/nethack-3.4.3/util/recover.c > Found open with O_CREAT and no mode. > out = open(iconfile, O_WRONLY | O_TRUNC | O_CREAT); > > Checking ./nethack/nethack-3.4.3/util/lev_main.c > Found open with O_CREAT and no mode. > fout = open(lbuf, O_WRONLY | O_CREAT | O_BINARY); > > Checking ./callweaver/callweaver-r2861/apps/app_voicemail.c > Found open with O_CREAT and no mode. > fd = open(full_fn, O_RDWR | O_CREAT | O_TRUNC); > > Checking ./callweaver/callweaver-r2861/channels/chan_zap.c > Found open with O_CREAT and no mode. > myfd = open(argv[4], O_CREAT | O_WRONLY); > > Checking ./callweaver/callweaver-r2861/codecs/codec_speex.c > Found open with O_CREAT and no mode. > fd = open("speex.raw", O_WRONLY | O_TRUNC | O_CREAT); > > Checking ./e2fsprogs/e2fsprogs-1.40.2/lib/ext2fs/ismounted.c > Found open with O_CREAT and no mode. > fd = open(TEST_FILE, O_RDWR | O_CREAT); > > Checking ./initng/initng-0.6.10.1/plugins/logfile/initng_logfile.c > Found open with O_CREAT and no mode. > fd = open(filename, O_WRONLY | O_CREAT | O_APPEND); > > Checking ./mysqlclient14/mysql-4.1.14/netware/my_manage.c > Found open with O_CREAT and no mode. > wiring.outfd = open(output, O_WRONLY | O_CREAT | O_TRUNC); > wiring.errfd = open(error, O_WRONLY | O_CREAT | O_TRUNC); > > Checking ./mysqlclient14/mysql-4.1.14/mysql-test/my_manage.c > Found open with O_CREAT and no mode. > wiring.outfd = open(output, O_WRONLY | O_CREAT | O_TRUNC); > wiring.errfd = open(error, O_WRONLY | O_CREAT | O_TRUNC); > > Checking ./compat-gcc-34/gcc-3.4.6-20060404/gcc/collect2.c > Found open with O_CREAT and no mode. > redir_handle = open(redir, O_WRONLY | O_TRUNC | O_CREAT); > > Checking ./TeXmacs/TeXmacs-1.0.6.10-src/plugins/r/src/tm_r.c > Found open with O_CREAT and no mode. > LOG = open("/tmp/log", O_CREAT | O_WRONLY); > > Checking ./lirc/lirc-0.8.2/daemons/slinke.c > Found open with O_CREAT and no mode. > fd = open(remote->name, O_CREAT | O_EXCL | O_RDWR); > > Checking ./ortp/ortp-0.13.1/src/tests/mrtprecv.c > Found open with O_CREAT and no mode. > open(filename, _O_BINARY | O_WRONLY | O_CREAT | O_TRUNC); > > Checking ./ortp/ortp-0.13.1/src/tests/tevmrtprecv.c > Found open with O_CREAT and no mode. > open(filename, _O_BINARY | O_WRONLY | O_CREAT | O_TRUNC); > > Checking ./libsilc/silc-toolkit-1.0.2/lib/silcclient/client_ftp.c > Found open with O_CREAT and no mode. > session->fd = silc_file_open(path, O_RDWR | O_CREAT | O_EXCL); > > Checking ./sane-backends/sane-backends-1.0.18/backend/fujitsu.c > Found open with O_CREAT and no mode. > s->duplex_fd = open (filename, O_RDWR | O_CREAT | O_EXCL); > > Checking ./tor/tor-0.1.2.16/src/common/util.c > Found open with O_CREAT and no mode. > nullfd = open("/dev/null", O_CREAT | O_RDWR | O_APPEND); > > Checking ./unzip/unzip-5.52/fileio.c > Found open with O_CREAT and no mode. > fd = open(G.filename, O_WRONLY | O_LARGEFILE | O_CREAT); > > Checking ./tetex/tetex-src-3.0/texk/web2c/lib/coredump.c > Found open with O_CREAT and no mode. > int handle = open("core", O_WRONLY | O_CREAT | O_TRUNC | O_BINARY); > > Checking ./net-snmp/net-snmp-5.4/agent/mibgroup/util_funcs.c > Found open with O_CREAT and no mode. > fd = open(name, O_CREAT | O_EXCL | O_WRONLY); > > Checking ./zaptel/zaptel-1.4.2.1/fxotune.c > Found open with O_CREAT and no mode. > configfd = open(configfile, O_CREAT | O_TRUNC | O_WRONLY); > > Checking ./ecryptfs-utils/ecryptfs-utils-18/src/testcases/llseek.c > Found open with O_CREAT and no mode. > fd = open(FILENAME, (O_CREAT | O_EXCL | O_WRONLY)); > > Checking ./ecryptfs-utils/ecryptfs-utils-18/src/testcases/open_close.c > Found open with O_CREAT and no mode. > fd = open(filename, (O_CREAT | O_EXCL)); > > Checking ./xfsdump/xfsdump-2.2.45/inventory/inv_stobj.c > Found open with O_CREAT and no mode. > int tmpfd = open("moids", O_RDWR | O_CREAT); > > Checking ./xfsdump/xfsdump-2.2.45/invutil/invidx.c > Found open with O_CREAT and no mode. > new_fd = open(dst_idxfile, O_CREAT | O_RDWR); > > Checking ./libxml/libxml-1.8.17/nanohttp.c > Found open with O_CREAT and no mode. > fd = open(filename, O_CREAT | O_WRONLY); > > Checking ./ddrescue/dd_rescue/dd_rescue.c > Found open with O_CREAT and no mode. > c = openfile(lname, O_WRONLY | O_CREAT /*| O_EXCL */ ); > > Checking ./pilot-link/pilot-link-0.12.2/src/pilot-schlep.c > Found open with O_CREAT and no mode. > fd = open(filename, O_WRONLY | O_CREAT | O_TRUNC); > > Checking ./nano/nano-2.0.6/src/files.c > Found open with O_CREAT and no mode. > fd_source = open(realname, O_RDONLY | O_CREAT); > fd_source = open(tempname, O_RDONLY | O_CREAT); > > Checking ./erlang/otp_src_R11B-2/erts/etc/unix/run_erl.c > Found open with O_CREAT and no mode. > lfd = open_log(lognum, O_RDWR | O_APPEND | O_CREAT | O_SYNC); > *lfd = open_log(*log_num, O_RDWR | O_CREAT | O_TRUNC | O_SYNC); > > Checking ./xcdroast/xcdroast-0.98alpha15/src/io.c > Found open with O_CREAT and no mode. > fd = open(fname, O_WRONLY | O_CREAT); > > Checking ./freeciv/freeciv-2.0.9/client/connectdlg_common.c > Found open with O_CREAT and no mode. > fd = open(logfile, O_WRONLY | O_CREAT); > > Checking ./isomaster/isomaster-1.0/isobrowser.c > Found open with O_CREAT and no mode. > destFile = open(openIsoPathAndName, O_WRONLY | O_CREAT); > > Checking ./vim/vim71/src/memfile.c > Found open with O_CREAT and no mode. > mf_do_open(mfp, fname, O_RDWR | O_CREAT | O_EXCL); /* try to open the file */ > > Checking ./mtx/mtx-1.3.11/mam2debug2.c > Found open with O_CREAT and no mode. > outfile = open(argv[2], O_CREAT | O_WRONLY); > > Checking ./mtx/mtx-1.3.11/mam2debug.c > Found open with O_CREAT and no mode. > outfile = open(argv[2], O_CREAT | O_WRONLY); > > Checking ./linphone/linphone-1.7.1/oRTP/src/tests/mrtprecv.c > Found open with O_CREAT and no mode. > open(filename, _O_BINARY | O_WRONLY | O_CREAT | O_TRUNC); > > Checking ./linphone/linphone-1.7.1/oRTP/src/tests/tevmrtprecv.c > Found open with O_CREAT and no mode. > open(filename, _O_BINARY | O_WRONLY | O_CREAT | O_TRUNC); > > Checking ./nx/nx-2.1.0/nx-X11/programs/xmh/miscfuncs.c > Found open with O_CREAT and no mode. > new_fid = open(tmp_file, O_RDWR | O_CREAT); > > Checking ./rgmanager/rgmanager-2.0.23/src/daemons/clurmtabd_lib.c > Found open with O_CREAT and no mode. > close(open(filename, O_WRONLY | O_SYNC | O_CREAT)); > > Checking ./glibc/glibc-20070804T2027/login/tst-grantpt.c > Found open with O_CREAT and no mode. > fd = open(file, O_RDWR | O_CREAT); > > Checking ./busybox/busybox-1.6.1/archival/unzip.c > Found open with O_CREAT and no mode. > dst_fd = xopen(dst_fn, O_WRONLY | O_CREAT | O_TRUNC); > > Checking ./busybox/busybox-1.6.1/e2fsprogs/old_e2fsprogs/ext2fs/ismounted.c > Found open with O_CREAT and no mode. > fd = open(TEST_FILE, O_RDWR | O_CREAT); > > Checking ./busybox/busybox-1.6.1/runit/svlogd.c > Found open with O_CREAT and no mode. > fd = xopen(ld->fnsave, O_WRONLY | O_NDELAY | O_TRUNC | O_CREAT); > close(xopen("state", O_WRONLY | O_NDELAY | O_TRUNC | O_CREAT)); > fd = xopen("newstate", O_WRONLY | O_NDELAY | O_TRUNC | O_CREAT); > > Checking ./busybox/busybox-1.6.1/miscutils/rx.c > Found open with O_CREAT and no mode. > filefd = xopen(fn, O_RDWR | O_CREAT | O_TRUNC); > > Checking ./busybox/busybox-1.6.1/networking/ftpgetput.c > Found open with O_CREAT and no mode. > fd_local = xopen(local_path, O_CREAT | O_TRUNC | O_WRONLY); > > Checking ./jed/jed-0.99-18/src/file.c > Found open with O_CREAT and no mode. > return open(file, O_WRONLY | O_APPEND | O_CREAT | O_BINARY); > > Checking ./mono/mono-1.2.4/mono/arch/alpha/test.c > Found open with O_CREAT and no mode. > int fd = open("bad.out", O_CREAT | O_TRUNC); > > Checking ./proftpd/proftpd-1.3.0a/modules/mod_xfer.c > Found open with O_CREAT and no mode. > stor_fh = pr_fsio_open(session.xfer.path, O_CREAT | O_WRONLY); > > Checking ./proftpd/proftpd-1.3.0a/src/fsio.c > Found open with O_CREAT and no mode. > dst_fh = pr_fsio_open(dst, O_WRONLY | O_CREAT); > > Checking ./dvb-apps/linuxtv-dvb-apps-1.1.1/test/test.c > Found open with O_CREAT and no mode. > int vout = open("qv", O_RDWR | O_CREAT); > int aout = open("qa", O_RDWR | O_CREAT); Well that list looks more like a *complete list* :-) Thx Dave! -of From ville.skytta at iki.fi Fri Aug 17 07:48:07 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Fri, 17 Aug 2007 10:48:07 +0300 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <46C5444F.9040308@gmail.com> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <200708170900.32388.ville.skytta@iki.fi> <46C5444F.9040308@gmail.com> Message-ID: <200708171048.08207.ville.skytta@iki.fi> On Friday 17 August 2007, Toshio Kuratomi wrote: > Labeling them as GPLv1+ is also arrogant and just as wrong to a > non-lawyer. When I read that clause and used the GPLv2 COPYING file > with my own code, I assumed that putting a GPLv2 COPYING file counted as > "specify a version number of this License". I agree it's not far fetched to guess this is what has happened in a lot of cases. But FWIW, my strong opinion remains that until upstream clarifies the intent (and clarification *should* really be asked if at all possible), the only possible choice for us is to comply with what is actually written in the license text. > As an alternative, we could have some boilerplate that specifically > explains the situation to the upstream author when we encounter a bare > "GPL" in the source code: This would be very useful indeed. Your boilerplate looks good to me, although I'd add some line breaks to make it slightly lighter to read. > P.S.: Do you agree or disagree with my assessment that a COPYING file in > the tarball and no licensing information in the source means the program > is unlicensed and therefore we must get a license from the author or > have to stop shipping the package in Fedora? I don't really have an informed nor a strong opinion about that, but perhaps I'm slightly leaning towards that this wouldn't be a show-stopper. Clarification should absolutely be asked in this case though. From rc040203 at freenet.de Fri Aug 17 07:57:12 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 17 Aug 2007 09:57:12 +0200 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <200708171048.08207.ville.skytta@iki.fi> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <200708170900.32388.ville.skytta@iki.fi> <46C5444F.9040308@gmail.com> <200708171048.08207.ville.skytta@iki.fi> Message-ID: <1187337432.14035.447.camel@mccallum.corsepiu.local> On Fri, 2007-08-17 at 10:48 +0300, Ville Skytt? wrote: > On Friday 17 August 2007, Toshio Kuratomi wrote: > > P.S.: Do you agree or disagree with my assessment that a COPYING file in > > the tarball and no licensing information in the source means the program > > is unlicensed and therefore we must get a license from the author or > > have to stop shipping the package in Fedora? > > I don't really have an informed nor a strong opinion about that, What matters to courts is the copyright holder having "pronounced/communicated his intention of how a package's sources may be used and how binaries being built from it may-be used/distributed". How he communicates his is intention, basically is up to himself. There are ways which are claimed to be "safer" some which are claimed to be "less safer" ways. Which ways a court would accept is a different question. > but perhaps > I'm slightly leaning towards that this wouldn't be a show-stopper. > Clarification should absolutely be asked in this case though. Doing so is impossible in many cases. Ralf From harald at redhat.com Fri Aug 17 09:50:13 2007 From: harald at redhat.com (Harald Hoyer) Date: Fri, 17 Aug 2007 11:50:13 +0200 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <1187283455.13210.28.camel@cutter> Message-ID: <46C56F55.3060503@redhat.com> Colin Walters schrieb: > However, I was fairly sure there had to already be something open source > out there to use as a start. My initial googling wasn't too successful > (a lot of things called licenses), but then I had the bright idea to add > "Debian" to my search. Turns out there's a license analyzing script in ... s.th. like the attached perl script might be a start.. is there a public fedora cvs where I can check that in, so that it can be extended? btw, I'm not perl guru, don't expect nice code.. -------------- next part -------------- A non-text attachment was scrubbed... Name: checklicense.pl Type: application/x-perl Size: 3001 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3623 bytes Desc: S/MIME Cryptographic Signature URL: From harald at redhat.com Fri Aug 17 11:44:05 2007 From: harald at redhat.com (Harald Hoyer) Date: Fri, 17 Aug 2007 13:44:05 +0200 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <46C56F55.3060503@redhat.com> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <1187283455.13210.28.camel@cutter> <46C56F55.3060503@redhat.com> Message-ID: <46C58A05.3060005@redhat.com> Harald Hoyer schrieb: > Colin Walters schrieb: >> However, I was fairly sure there had to already be something open >> source out there to use as a start. My initial googling wasn't too >> successful (a lot of things called licenses), but then I had the >> bright idea to add "Debian" to my search. Turns out there's a license >> analyzing script in > ... > s.th. like the attached perl script might be a start.. > is there a public fedora cvs where I can check that in, so that it can > be extended? > btw, I'm not perl guru, don't expect nice code.. ok, with the attached perl script, I quickly spotted for my packages: initscripts: Found Licenses: GPLv2, GPL (no version mentioned), GPLv2+ What makes that? GPLv2 ?? cdrkit: Found Licenses: LGPLv2+, GPLv2, GPL (no version mentioned), LGPLv2.1+, GPLv2+, What makes that? GPLv2 ?? nmap: Found Licenses: LGPLv2+, BSD (no advertise clause), GPLv2, BSD (with advertise clause, not GPL conform), GPLv2+ uhh, bad one... -------------- next part -------------- A non-text attachment was scrubbed... Name: checklicense.pl Type: application/x-perl Size: 8702 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3623 bytes Desc: S/MIME Cryptographic Signature URL: From opensource at till.name Fri Aug 17 12:40:18 2007 From: opensource at till.name (Till Maas) Date: Fri, 17 Aug 2007 14:40:18 +0200 Subject: how to rename a packge? Message-ID: <200708171440.25780.opensource@till.name> Hiyas, cryptsetup-luks has been renamed to cryptsetup, so if I want to reflect this change in Fedora, how can this be done? http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife only mentions how to remove cryptsetup-luks but not how the new cryptsetup "branch"(?) in cvs is created (and all the other stuff, e.g. copying the acl and add a new component to Bugzilla, ...) Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From ville.skytta at iki.fi Fri Aug 17 13:06:48 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Fri, 17 Aug 2007 16:06:48 +0300 Subject: how to rename a packge? In-Reply-To: <200708171440.25780.opensource@till.name> References: <200708171440.25780.opensource@till.name> Message-ID: <200708171606.48384.ville.skytta@iki.fi> On Friday 17 August 2007, Till Maas wrote: > Hiyas, > > cryptsetup-luks has been renamed to cryptsetup, so if I want to reflect > this change in Fedora, how can this be done? Packaging related instructions: http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-3cfc1ea19d28975faad9d56f70a6ae55661d3c3d > http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife only > mentions how to remove cryptsetup-luks but not how the new > cryptsetup "branch"(?) in cvs is created (and all the other stuff, e.g. > copying the acl and add a new component to Bugzilla, ...) I suppose that would be just like adding any new package. Be sure also to add information about the rename so the CVS admins know what's going on. http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure From opensource at till.name Fri Aug 17 13:08:11 2007 From: opensource at till.name (Till Maas) Date: Fri, 17 Aug 2007 15:08:11 +0200 Subject: how to rename a packge? In-Reply-To: <200708171440.25780.opensource@till.name> References: <200708171440.25780.opensource@till.name> Message-ID: <200708171508.16504.opensource@till.name> On Fr August 17 2007, Till Maas wrote: > cryptsetup-luks has been renamed to cryptsetup, so if I want to reflect > this change in Fedora, how can this be done? It seems to be a little more complicated, because there was some time already cryptsetup in cvs, at least there is a bugzilla component where bugs get reported that are wanted to be reported against cryptsetup-luks and therefore have been overseen. So, within the renaming procedure, it would be nice to make sure that there is either only the cryptsetup component afterwards or that cryptsetup-luks is an alias of cryptsetup (don't know, whether this is possible). Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From mmcgrath at redhat.com Fri Aug 17 13:23:07 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 17 Aug 2007 08:23:07 -0500 Subject: Successful build failed In-Reply-To: <1187322606.14035.423.camel@mccallum.corsepiu.local> References: <1187322606.14035.423.camel@mccallum.corsepiu.local> Message-ID: <46C5A13B.5030404@redhat.com> Ralf Corsepius wrote: > A successful build job failed: > > ----snip ---- > > Job failed on arch noarch > > > Build logs may be found at > http://buildsys.fedoraproject.org/logs/fedora-6-extras/35707-perl-Class-ReturnValue-0.54-1.fc6/ > Hmm, we've seen this over the last week or so from rsc as well and had hoped it was an isolated incident. So far we've been completely clueless as to why it would be happening, I'll take a closer look. In the meantime if people could report successful-failed builds here: https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/125 -Mike From nphilipp at redhat.com Fri Aug 17 13:29:20 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 17 Aug 2007 15:29:20 +0200 Subject: The open() system call in f8 really broken... In-Reply-To: <20070816230608.GA18576@redhat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4605B.1000407@RedHat.com> <46C461C6.5080302@linux-kernel.at> <46C46558.1000905@RedHat.com> <46C4685F.8080601@linux-kernel.at> <20070816202138.GA15542@redhat.com> <20070816203637.GA10486@redhat.com> <20070816230608.GA18576@redhat.com> Message-ID: <1187357360.3197.14.camel@gibraltar.stuttgart.redhat.com> On Thu, 2007-08-16 at 19:06 -0400, Dave Jones wrote: > Checking ./sane-backends/sane-backends-1.0.18/backend/fujitsu.c > Found open with O_CREAT and no mode. > s->duplex_fd = open (filename, O_RDWR | O_CREAT | O_EXCL); That's bogus. This line contains a correct sibling that'd be active if _POSIX_SOURCE were defined... if it wasn't in a huge commented out block anyway ;-). 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 jima at beer.tclug.org Fri Aug 17 13:40:45 2007 From: jima at beer.tclug.org (Jima) Date: Fri, 17 Aug 2007 08:40:45 -0500 (CDT) Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <46C5444F.9040308@gmail.com> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <1187272054.3439.109.camel@dhcp83-165.boston.redhat.com> <46C4FA76.4020005@gmail.com> <200708170900.32388.ville.skytta@iki.fi> <46C5444F.9040308@gmail.com> Message-ID: On Thu, 16 Aug 2007, Toshio Kuratomi wrote: > As an alternative, we could have some boilerplate that specifically > explains the situation to the upstream author when we encounter a bare > "GPL" in the source code: I emailed an upstream with a similar message yesterday when I encountered a COPYING file but no copyright/licensing-related comments in the source. They responded immediately agreeing that they should add copyright information, and even going so far as to ask my opinion on whether they should use a specific version of the GPL or not. (Wow, what a cooperative upstream.) FWIW, this was Coraid, upstream for aoetools and vblade. I'm definitely a proponent of contacting upstream for clarification. Hopefully all of them will be so friendly, especially since clearing this up now could save them problems down the road. Jima From jima at beer.tclug.org Fri Aug 17 13:45:04 2007 From: jima at beer.tclug.org (Jima) Date: Fri, 17 Aug 2007 08:45:04 -0500 (CDT) Subject: The open() system call in f8 really broken... In-Reply-To: <46C54B01.3050600@linux-kernel.at> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4605B.1000407@RedHat.com> <46C461C6.5080302@linux-kernel.at> <46C46558.1000905@RedHat.com> <46C4685F.8080601@linux-kernel.at> <20070816202138.GA15542@redhat.com> <20070816203637.GA10486@redhat.com> <20070816230608.GA18576@redhat.com> <46C54B01.3050600@linux-kernel.at> Message-ID: On Fri, 17 Aug 2007, Oliver Falk wrote: > On 08/17/2007 01:06 AM, Dave Jones wrote: *snip* > > Well that list looks more like a *complete list* :-) Enh, I think there are probably some more bizarre corner cases that it might not catch, but it's certainly a lot more complete than the previous one. (Of course, in my case, the strange incantation failed to build, which is probably fairly fortunate.) > Thx Dave! +1 Jima From rc040203 at freenet.de Fri Aug 17 13:46:05 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 17 Aug 2007 15:46:05 +0200 Subject: Successful build failed In-Reply-To: <46C5A13B.5030404@redhat.com> References: <1187322606.14035.423.camel@mccallum.corsepiu.local> <46C5A13B.5030404@redhat.com> Message-ID: <1187358365.14035.470.camel@mccallum.corsepiu.local> On Fri, 2007-08-17 at 08:23 -0500, Mike McGrath wrote: > Ralf Corsepius wrote: > > A successful build job failed: > > > > ----snip ---- > > > > Job failed on arch noarch > > > > > > Build logs may be found at > > http://buildsys.fedoraproject.org/logs/fedora-6-extras/35707-perl-Class-ReturnValue-0.54-1.fc6/ > > > > Hmm, we've seen this over the last week or so from rsc as well and had > hoped it was an isolated incident. FWIW: I had 4 of them in total today (The last one date ca. 08:00 UTC) http://buildsys.fedoraproject.org/logs/fedora-6-extras/35707-perl-Class-ReturnValue-0.54-1.fc6/ http://buildsys.fedoraproject.org/logs/fedora-6-extras/35708-perl-Class-ReturnValue-0.54-1.fc6/ http://buildsys.fedoraproject.org/logs/fedora-6-extras/35710-perl-Class-Inspector-1.17-1.fc6/ http://buildsys.fedoraproject.org/logs/fedora-6-extras/35711-perl-Class-ReturnValue-0.54-1.fc6/ Build rebuild attempts after ca. 12:00 UTC succeeded: http://buildsys.fedoraproject.org/logs/fedora-6-extras/35712-perl-Class-ReturnValue-0.54-1.fc6/ http://buildsys.fedoraproject.org/logs/fedora-6-extras/35713-perl-Class-Inspector-1.17-1.fc6/ So something having touched the system between ca. 08:00 UTC and 12:00 UTC seems to have "magically" fixed this issue. Ralf From limb at jcomserv.net Fri Aug 17 13:45:21 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 17 Aug 2007 08:45:21 -0500 (CDT) Subject: The open() system call in f8 really broken... In-Reply-To: <20070816230608.GA18576@redhat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4605B.1000407@RedHat.com> <46C461C6.5080302@linux-kernel.at> <46C46558.1000905@RedHat.com> <46C4685F.8080601@linux-kernel.at> <20070816202138.GA15542@redhat.com> <20070816203637.GA10486@redhat.com> <20070816230608.GA18576@redhat.com> Message-ID: <58089.65.192.24.164.1187358321.squirrel@mail.jcomserv.net> > On Thu, Aug 16, 2007 at 04:36:37PM -0400, Dave Jones wrote: > > On Thu, Aug 16, 2007 at 04:21:38PM -0400, Dave Jones wrote: > > > On Thu, Aug 16, 2007 at 05:08:15PM +0200, Oliver Falk wrote: > > > > > > > If you compile the whole Fedora tree, how many warnings will you > see? > > > > > > So I grepped across a make prep'd tree of devel (all 63 gig of it). > > > Here's the fallout.. > > > > > > openmpi/openmpi-1.2.3/orte/runtime/orte_abort.c fd = > open(abort_file, O_CREAT); > > > jython/jython-svn-Release_2_2beta1/CPythonLib/test/test_unicode_file.py:f > = os.open(TESTFN_ENCODED, os.O_CREAT) > > > perl/perl-5.8.8/t/op/taint.t: eval { sysopen(my $cr, $evil, > &O_CREAT) }; > > > proftpd/proftpd-1.3.0a/contrib/mod_rewrite.c: if ((fifo_lockfd = > open(fifo_lockname, O_CREAT)) < 0) > > > pwlib/pwlib-1.10.7/configure:sem_t *s = sem_open("test", O_CREAT) > > > pwlib/pwlib-1.10.7/configure.ac: [sem_t *s = > sem_open("test", O_CREAT)], > > > python/Python-2.5.1/Lib/test/test_unicode_file.py: f = > os.open(filename, os.O_CREAT) > > > python-docs/Python-2.5.1/Lib/test/test_unicode_file.py: f = > os.open(filename, os.O_CREAT) > > > xca/xca-0.6.3/_tmp_root/usr/lib/python2.5/test/test_unicode_file.py: > f = os.open(filename, os.O_CREAT) > > > > > > Not too bad considering. > > > > Bah, my regexp was imperfect. I'll fix up and rerun. > > More like it. 267 hits. > > Dave > Checking ./ettercap/ettercap-NG-0.7.3/src/ec_log.c > Found open with O_CREAT and no mode. > fd->fd = open(filename, O_CREAT | O_TRUNC | O_RDWR | O_BINARY); > Checking ./bombardier/bombardier-0.8.2/hof.c > Found open with O_CREAT and no mode. > fd = open("/var/games/bombardi Wow. Thanks, these are mine, and this made it easy to find, patch, build, test, send upstream, and build for devel. > > > -- > http://www.codemonkey.org.uk > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- novus ordo absurdum From a.badger at gmail.com Fri Aug 17 16:05:46 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 17 Aug 2007 09:05:46 -0700 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <1187272054.3439.109.camel@dhcp83-165.boston.redhat.com> <46C4FA76.4020005@gmail.com> <200708170900.32388.ville.skytta@iki.fi> <46C5444F.9040308@gmail.com> Message-ID: <46C5C75A.5030604@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jima wrote: > On Thu, 16 Aug 2007, Toshio Kuratomi wrote: >> As an alternative, we could have some boilerplate that specifically >> explains the situation to the upstream author when we encounter a bare >> "GPL" in the source code: > > I emailed an upstream with a similar message yesterday when I > encountered a COPYING file but no copyright/licensing-related comments > in the source. They responded immediately agreeing that they should add > copyright information, and even going so far as to ask my opinion on > whether they should use a specific version of the GPL or not. (Wow, > what a cooperative upstream.) FWIW, this was Coraid, upstream for > aoetools and vblade. > > I'm definitely a proponent of contacting upstream for clarification. > Hopefully all of them will be so friendly, especially since clearing > this up now could save them problems down the road. > Yeah, I don't forsee any difficulties when upstream is actively developing the software. It's when upstream is dead or has hundreds of contributors that we could run into problems. If upstream is dead I suppose that assuming GPL+ or GPLv2+ makes no difference as upstream won't complain and change the license later :-) If upstream is merely unresponsive (extended "vacation" someone new picks up development later, etc) we could run into problems where upstream's stance upon resumption conflicts with ours. If upstream has hundreds of contributors, we have to decide what to license as while they hash out how to deal with the situation (Looks like legally they can put it to a vote of the current contributors as to what version they want at that point.) - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGxcdaX6yAic2E7kgRAgILAKCmyOB2t1cAfQ8aKVhBtXLipycUcwCfSeUz FlsHjp0uvOIj5EXA4qD+EEs= =axKP -----END PGP SIGNATURE----- From dominik at greysector.net Fri Aug 17 16:27:43 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 17 Aug 2007 18:27:43 +0200 Subject: The open() system call in f8 really broken... In-Reply-To: <20070816230608.GA18576@redhat.com> References: <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4605B.1000407@RedHat.com> <46C461C6.5080302@linux-kernel.at> <46C46558.1000905@RedHat.com> <46C4685F.8080601@linux-kernel.at> <20070816202138.GA15542@redhat.com> <20070816203637.GA10486@redhat.com> <20070816230608.GA18576@redhat.com> Message-ID: <20070817162743.GB9424@ryvius.pekin.waw.pl> On Friday, 17 August 2007 at 01:06, Dave Jones wrote: > On Thu, Aug 16, 2007 at 04:36:37PM -0400, Dave Jones wrote: > > On Thu, Aug 16, 2007 at 04:21:38PM -0400, Dave Jones wrote: > > > On Thu, Aug 16, 2007 at 05:08:15PM +0200, Oliver Falk wrote: > > > > > > > If you compile the whole Fedora tree, how many warnings will you see? > > > > > > So I grepped across a make prep'd tree of devel (all 63 gig of it). > > > Here's the fallout.. > > > > > > openmpi/openmpi-1.2.3/orte/runtime/orte_abort.c fd = open(abort_file, O_CREAT); > > > jython/jython-svn-Release_2_2beta1/CPythonLib/test/test_unicode_file.py:f = os.open(TESTFN_ENCODED, os.O_CREAT) > > > perl/perl-5.8.8/t/op/taint.t: eval { sysopen(my $cr, $evil, &O_CREAT) }; > > > proftpd/proftpd-1.3.0a/contrib/mod_rewrite.c: if ((fifo_lockfd = open(fifo_lockname, O_CREAT)) < 0) > > > pwlib/pwlib-1.10.7/configure:sem_t *s = sem_open("test", O_CREAT) > > > pwlib/pwlib-1.10.7/configure.ac: [sem_t *s = sem_open("test", O_CREAT)], > > > python/Python-2.5.1/Lib/test/test_unicode_file.py: f = os.open(filename, os.O_CREAT) > > > python-docs/Python-2.5.1/Lib/test/test_unicode_file.py: f = os.open(filename, os.O_CREAT) > > > xca/xca-0.6.3/_tmp_root/usr/lib/python2.5/test/test_unicode_file.py: f = os.open(filename, os.O_CREAT) > > > > > > Not too bad considering. > > > > Bah, my regexp was imperfect. I'll fix up and rerun. > > More like it. 267 hits. > > Dave > [...] > Checking ./dx/dx-4.4.4/src/exec/libdx/fileio.c > Found open with O_CREAT and no mode. > fd = open(name, O_WRONLY | O_CREAT); I'll patch this up and send fix upstream. Thanks! Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From loganjerry at gmail.com Fri Aug 17 03:38:49 2007 From: loganjerry at gmail.com (Jerry James) Date: Thu, 16 Aug 2007 21:38:49 -0600 Subject: Take over jlint Message-ID: <870180fe0708162038p53cbbcf2v93ccfebaebd6ec48@mail.gmail.com> On the orphaned packages wiki page, jlint is shown as having been orphaned nearly a year ago. I would like to take over maintainership of that package. Since the package has been orphaned for over 3 months, I have opened a new review request: 253134. The SRPM contains a patch to make it work on 64-bit systems. While this patch has been submitted upstream, I do not expect them to take it as is, since it requires the presence of . That's fine for all current Fedora systems, but not for some of the old systems the developers appear to want to target. -- Jerry James http://jjames.fedorapeople.org/ From igorfoox at gmail.com Fri Aug 17 13:13:41 2007 From: igorfoox at gmail.com (Igor Foox) Date: Fri, 17 Aug 2007 09:13:41 -0400 Subject: FeatureEclipse33 Status In-Reply-To: <1187112770.11441.17.camel@localhost.localdomain> References: <1187112770.11441.17.camel@localhost.localdomain> Message-ID: <29c1e9a40708170613v3caa3d9bs88c72ce71ed8758d@mail.gmail.com> Hi all, On 8/14/07, Andrew Overholt wrote: > Hi, > > Here's the status of the Fedora 8 feature of updating the Eclipse stack > to the 3.3 (Europa) base [1]. I've CC'd all of the maintainers. Please > reply with answers where you can. > > PyDev (Igor Foox) > - Igor: can you update to latest version that works with 3.3? If not, > can you orphan it? Ben says he can take it over if you don't have time. > - would be nice to get Mylyn integration in when we update I won't have the time to update PyDev for this release unfortunately. I would appreciate it if Ben could take over for now. I will probably be able to take it back in a month or two. Igor From a.badger at gmail.com Fri Aug 17 17:12:56 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 17 Aug 2007 10:12:56 -0700 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <200708171048.08207.ville.skytta@iki.fi> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <200708170900.32388.ville.skytta@iki.fi> <46C5444F.9040308@gmail.com> <200708171048.08207.ville.skytta@iki.fi> Message-ID: <46C5D718.3080008@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here's some boilerplate for the "COPYING file but no license in the sources" problem. I think this needs some work as it has become extremely unclear to me what files need to bear a license in order for the work as a whole to be licensed if COPYING cannot be considered to have any bearing on the author's intent to license the code. I need to understand that in order to write a coherent query to the gnome-common maintainers. (BTW, gnome-common is almost entirely autoconf macros and Makefile snippets intended for building gnome based apps. I'm unclear if there's any code in there that they can stick a GPL license on without it appearing in the code included in their downstream gnome apps. Will they need GPLvX with exceptions or does this cross some magical boundary to not be a derived work?) ''' Hi, I'm packaging your software for Fedora 8. As part of the Fedora 8 process we're trying to make sure that every piece of software is tagged with the proper license information. I noticed that you have a copy of the GPLv2 in the source tarball but the code doesn't contain any licensing information. This puts the package on tricky legal grounds where our legal advice says that the programs produced by the package may not have a license attached to it; meaning that we can't ship it at all. Since I strongly suspect your intent is to release this as OSS under the GPL, it would be great if you could clarify this situation. We need the following things taken care of: 1) Which version of the GPL do you want the code licensed under? GPL versions that we currently have seen are GPL (any version), GPLv2, GPLv2 or later, GPLv3, GPLv3 or later. 2) Add the license information to the code so that it definitively falls under the GPL(version). Thanks for taking the time to look at this problem, Your Friendly Neighborhood Packager ''' - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGxdcYX6yAic2E7kgRAg8cAJwOvPrrSOJY5QyWULIWRzB+tGSMpwCeMQ2C PEJQLqb81Hb9fxPqzK6RfWI= =Uaaw -----END PGP SIGNATURE----- From wart at kobold.org Fri Aug 17 17:13:24 2007 From: wart at kobold.org (Michael Thomas) Date: Fri, 17 Aug 2007 10:13:24 -0700 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <46C58A05.3060005@redhat.com> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <1187283455.13210.28.camel@cutter> <46C56F55.3060503@redhat.com> <46C58A05.3060005@redhat.com> Message-ID: <46C5D734.4070805@kobold.org> Harald Hoyer wrote: > Harald Hoyer schrieb: >> Colin Walters schrieb: >>> However, I was fairly sure there had to already be something open >>> source out there to use as a start. My initial googling wasn't too >>> successful (a lot of things called licenses), but then I had the >>> bright idea to add "Debian" to my search. Turns out there's a >>> license analyzing script in >> ... >> s.th. like the attached perl script might be a start.. >> is there a public fedora cvs where I can check that in, so that it can >> be extended? >> btw, I'm not perl guru, don't expect nice code.. > > ok, with the attached perl script, I quickly spotted for my packages: This is _most_ useful, especially for a package like bsd-games with 421 source files to examine[1]. Many thanks for posting this. --Wart [1]Found Licenses: BSD (no advertise clause), BSD (with advertise clause, not GPL conform) From buildsys at fedoraproject.org Fri Aug 17 18:11:02 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 17 Aug 2007 14:11:02 -0400 (EDT) Subject: Package EVR problems in Fedora 2007-08-17 Message-ID: <20070817181102.CAA29152131@buildsys.fedoraproject.org> alexl AT fedoraproject.org: xdg-user-dirs F7-updates > F8 (0:0.8-3.fc7 > 0:0.8-2.fc8) athimm AT fedoraproject.org: smart FE6 > F7-updates (0:0.50-47.fc6 > 0:0.50-46.fc7) FE6 > F8 (0:0.50-47.fc6 > 0:0.50-46.fc8) corsepiu AT fedoraproject.org: perl-capitalization FE6 > F7 (0:0.03-5.fc6 > 0:0.03-4.fc6) FE6 > F8 (0:0.03-5.fc6 > 0:0.03-4.fc6) perl-Class-Inspector FE6 > F7 (0:1.17-1.fc6 > 0:1.16-3.fc7) perl-Class-ReturnValue FE6 > F7 (0:0.54-1.fc6 > 0:0.53-6.fc7) davidz AT fedoraproject.org: dbus-python F7-updates-testing > F8 (0:0.82.0-2.fc7 > 0:0.82.0-1.fc8) devrim AT fedoraproject.org: postgresql-pgpool-II FE6 > F7-updates (0:1.2-4.fc6 > 0:1.2-1.fc7) edhill AT fedoraproject.org: scrip FE6 > F7 (0:1.4-7.fc6 > 0:1.4-6.fc6) FE6 > F8 (0:1.4-7.fc6 > 0:1.4-6.fc6) ensc AT fedoraproject.org: clamav F7-updates-testing > F8 (0:0.91.1-1.fc7 > 0:0.91.1-0.fc8) fedora-usermgmt FE6 > F7 (0:0.10-1.fc6 > 0:0.9-2.fc7) libtasn1 FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE5 > F8 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE6 > F7 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) FE6 > F8 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) mimetic FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7) FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7) util-vserver FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7) FE6 > F7 (0:0.30.213-2.fc6 > 0:0.30.212-3.fc7) xmlrpc-c FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7) FE6 > F7 (0:1.06.17-1.fc6 > 0:1.06.11-2.fc7) harald AT fedoraproject.org: k3b F7-updates > F8 (0:1.0.3-2.fc7 > 0:1.0.3-1.fc8) iburrell AT fedoraproject.org: ack FE6 > F7-updates (0:1.64-1.fc6 > 0:1.62-2.fc7) perl-SVK FE6 > F7-updates (0:2.0.2-1.fc6 > 0:2.0.1-2.fc7) FE6 > F8 (0:2.0.2-1.fc6 > 0:2.0.1-2.fc8) jakub AT fedoraproject.org: gcc FC6-updates > F7 (0:4.1.2-13.fc6 > 0:4.1.2-12) jcollie AT fedoraproject.org: jrtplib FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) jgu AT fedoraproject.org: emacs-common-muse FE6 > F8 (0:3.10-1.fc6 > 0:3.03-4.fc8) F7-updates-testing > F8 (0:3.10-1.fc7 > 0:3.03-4.fc8) laxathom AT fedoraproject.org: gammu FE6 > F8 (0:1.12.92-1.fc6 > 0:1.11.0-1.fc8) F7-updates-testing > F8 (0:1.12.92-1.fc7 > 0:1.11.0-1.fc8) python-gammu FE6 > F7-updates (0:0.21-1.fc6 > 0:0.20-1.fc7) FE6 > F8 (0:0.21-1.fc6 > 0:0.20-1.fc7) specto FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8) F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8) limb AT fedoraproject.org: tiquit F7-updates > F8 (0:2.4-5.fc7 > 0:2.4-4.fc7) liquidat AT fedoraproject.org: ktorrent FE6 > F7-updates (0:2.2.1-3.fc6 > 0:2.2.1-1.fc7) rsibreak FE6 > F7 (0:0.8.0-2.fc6 > 0:0.8.0-1.fc6) speedcrunch FE6 > F7-updates (0:0.8-5.fc6 > 0:0.8-4.fc7) lkundrak AT fedoraproject.org: cjet F7-updates > F8 (0:0.8.9-4.fc7 > 0:0.8.9-2.fc8) meme AT fedoraproject.org: fortune-firefly FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6) FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6) nethack-vultures FE6 > F7 (0:2.1.0-10.fc6 > 0:2.1.0-9.fc7) mikeb AT fedoraproject.org: python-cheetah FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) FE6 > F8 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) nhorman AT fedoraproject.org: irqbalance FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6) FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7) FC5-updates > F8 (2:0.55-4.fc5 > 2:0.55-3.fc8) nphilipp AT fedoraproject.org: system-config-date F7-updates-testing > F8 (0:1.9.5-1.fc7 > 0:1.9.4-1.fc8) pawsa AT fedoraproject.org: balsa F7-updates > F8 (0:2.3.17-2.fc7 > 0:2.3.17-1.fc8) peter AT fedoraproject.org: stratagus FE6 > F7 (0:2.2.4-1.fc6 > 0:2.2.3-1.fc7) pwouters AT fedoraproject.org: xl2tpd FE6 > F7 (0:1.1.11-2.fc6 > 0:1.1.09-1.fc7) rdieter AT fedoraproject.org: kdeartwork-extras FE6 > F7 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) FE6 > F8 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) kdegraphics-extras FE6 > F7 (0:3.5.7-1.fc6 > 0:3.5.5-1.fc7) FE6 > F8 (0:3.5.7-1.fc6 > 0:3.5.5-1.fc7) kdemultimedia-extras FE6 > F7 (6:3.5.7-1.fc6.5 > 6:3.5.6-5.fc7) FE6 > F8 (6:3.5.7-1.fc6.5 > 6:3.5.6-5.fc7) maxima FE5 > F7-updates (0:5.12.0-3.fc5 > 0:5.12.0-2.fc7) FE6 > F7-updates (0:5.12.0-3.fc6 > 0:5.12.0-2.fc7) scop AT fedoraproject.org: em8300 FE6 > F7-updates (0:0.16.3-0.1.rc3.fc6 > 0:0.16.3-0.1.rc2.fc7) em8300-kmod FE6 > F7-updates (0:0.16.3-0.2.rc3.2.6.22.1_32.fc6 > 0:0.16.3-0.1.rc2.2.6.22.1_41.fc7) html401-dtds F7-updates-testing > F8 (0:4.01-19991224.5 > 0:4.01-19991224.3.fc6) sindrepb AT fedoraproject.org: gtranslator F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8) perl-Net-Libdnet F7-updates > F8 (0:0.01-3.fc7.1 > 0:0.01-2.fc8) perl-Nmap-Parser F7-updates > F8 (0:1.05-4.fc7 > 0:1.05-3.fc8) tcptraceroute FE6 > F7-updates (0:1.5-0.2.beta7.fc6 > 0:1.5-0.1.beta7.fc7) splinux AT fedoraproject.org: lostirc FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7) FE6 > F8 (0:0.4.6-3.fc6 > 0:0.4.6-2.fc8) ssp AT fedoraproject.org: libgtop2 FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7) than AT fedoraproject.org: kdepim F7-updates > F8 (6:3.5.7-3.fc7 > 6:3.5.7-2.fc8) veillard AT fedoraproject.org: libxml2 FC6-updates > F8 (0:2.6.29-1.fc6 > 0:2.6.29-1) F7-updates > F8 (0:2.6.29-1.fc7 > 0:2.6.29-1) ---------------------------------------------------------------------- ack: iburrell at fedoraproject org FE6 > F7-updates (0:1.64-1.fc6 > 0:1.62-2.fc7) balsa: pawsa at fedoraproject org F7-updates > F8 (0:2.3.17-2.fc7 > 0:2.3.17-1.fc8) cjet: lkundrak at fedoraproject org F7-updates > F8 (0:0.8.9-4.fc7 > 0:0.8.9-2.fc8) clamav: ensc at fedoraproject org F7-updates-testing > F8 (0:0.91.1-1.fc7 > 0:0.91.1-0.fc8) dbus-python: davidz at fedoraproject org F7-updates-testing > F8 (0:0.82.0-2.fc7 > 0:0.82.0-1.fc8) em8300: scop at fedoraproject org FE6 > F7-updates (0:0.16.3-0.1.rc3.fc6 > 0:0.16.3-0.1.rc2.fc7) em8300-kmod: scop at fedoraproject org FE6 > F7-updates (0:0.16.3-0.2.rc3.2.6.22.1_32.fc6 > 0:0.16.3-0.1.rc2.2.6.22.1_41.fc7) emacs-common-muse: jgu at fedoraproject org FE6 > F8 (0:3.10-1.fc6 > 0:3.03-4.fc8) F7-updates-testing > F8 (0:3.10-1.fc7 > 0:3.03-4.fc8) fedora-usermgmt: ensc at fedoraproject org FE6 > F7 (0:0.10-1.fc6 > 0:0.9-2.fc7) fortune-firefly: meme at fedoraproject org FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6) FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6) gammu: laxathom at fedoraproject org FE6 > F8 (0:1.12.92-1.fc6 > 0:1.11.0-1.fc8) F7-updates-testing > F8 (0:1.12.92-1.fc7 > 0:1.11.0-1.fc8) gcc: jakub at fedoraproject org FC6-updates > F7 (0:4.1.2-13.fc6 > 0:4.1.2-12) gtranslator: sindrepb at fedoraproject org F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8) html401-dtds: scop at fedoraproject org F7-updates-testing > F8 (0:4.01-19991224.5 > 0:4.01-19991224.3.fc6) irqbalance: nhorman at fedoraproject org FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6) FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7) FC5-updates > F8 (2:0.55-4.fc5 > 2:0.55-3.fc8) jrtplib: jcollie at fedoraproject org FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) k3b: harald at fedoraproject org F7-updates > F8 (0:1.0.3-2.fc7 > 0:1.0.3-1.fc8) kdeartwork-extras: rdieter at fedoraproject org FE6 > F7 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) FE6 > F8 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) kdegraphics-extras: rdieter at fedoraproject org FE6 > F7 (0:3.5.7-1.fc6 > 0:3.5.5-1.fc7) FE6 > F8 (0:3.5.7-1.fc6 > 0:3.5.5-1.fc7) kdemultimedia-extras: rdieter at fedoraproject org FE6 > F7 (6:3.5.7-1.fc6.5 > 6:3.5.6-5.fc7) FE6 > F8 (6:3.5.7-1.fc6.5 > 6:3.5.6-5.fc7) kdepim: than at fedoraproject org F7-updates > F8 (6:3.5.7-3.fc7 > 6:3.5.7-2.fc8) ktorrent: liquidat at fedoraproject org FE6 > F7-updates (0:2.2.1-3.fc6 > 0:2.2.1-1.fc7) libgtop2: ssp at fedoraproject org FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7) libtasn1: ensc at fedoraproject org FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE5 > F8 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE6 > F7 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) FE6 > F8 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) libxml2: veillard at fedoraproject org FC6-updates > F8 (0:2.6.29-1.fc6 > 0:2.6.29-1) F7-updates > F8 (0:2.6.29-1.fc7 > 0:2.6.29-1) lostirc: splinux at fedoraproject org FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7) FE6 > F8 (0:0.4.6-3.fc6 > 0:0.4.6-2.fc8) maxima: rdieter at fedoraproject org FE5 > F7-updates (0:5.12.0-3.fc5 > 0:5.12.0-2.fc7) FE6 > F7-updates (0:5.12.0-3.fc6 > 0:5.12.0-2.fc7) mimetic: ensc at fedoraproject org FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7) FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7) nethack-vultures: meme at fedoraproject org FE6 > F7 (0:2.1.0-10.fc6 > 0:2.1.0-9.fc7) perl-capitalization: corsepiu at fedoraproject org FE6 > F7 (0:0.03-5.fc6 > 0:0.03-4.fc6) FE6 > F8 (0:0.03-5.fc6 > 0:0.03-4.fc6) perl-Class-Inspector: corsepiu at fedoraproject org FE6 > F7 (0:1.17-1.fc6 > 0:1.16-3.fc7) perl-Class-ReturnValue: corsepiu at fedoraproject org FE6 > F7 (0:0.54-1.fc6 > 0:0.53-6.fc7) perl-Net-Libdnet: sindrepb at fedoraproject org F7-updates > F8 (0:0.01-3.fc7.1 > 0:0.01-2.fc8) perl-Nmap-Parser: sindrepb at fedoraproject org F7-updates > F8 (0:1.05-4.fc7 > 0:1.05-3.fc8) perl-SVK: iburrell at fedoraproject org FE6 > F7-updates (0:2.0.2-1.fc6 > 0:2.0.1-2.fc7) FE6 > F8 (0:2.0.2-1.fc6 > 0:2.0.1-2.fc8) postgresql-pgpool-II: devrim at fedoraproject org FE6 > F7-updates (0:1.2-4.fc6 > 0:1.2-1.fc7) python-cheetah: mikeb at fedoraproject org FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) FE6 > F8 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) python-gammu: laxathom at fedoraproject org FE6 > F7-updates (0:0.21-1.fc6 > 0:0.20-1.fc7) FE6 > F8 (0:0.21-1.fc6 > 0:0.20-1.fc7) rsibreak: liquidat at fedoraproject org FE6 > F7 (0:0.8.0-2.fc6 > 0:0.8.0-1.fc6) scrip: edhill at fedoraproject org FE6 > F7 (0:1.4-7.fc6 > 0:1.4-6.fc6) FE6 > F8 (0:1.4-7.fc6 > 0:1.4-6.fc6) smart: athimm at fedoraproject org FE6 > F7-updates (0:0.50-47.fc6 > 0:0.50-46.fc7) FE6 > F8 (0:0.50-47.fc6 > 0:0.50-46.fc8) specto: laxathom at fedoraproject org FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8) F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8) speedcrunch: liquidat at fedoraproject org FE6 > F7-updates (0:0.8-5.fc6 > 0:0.8-4.fc7) stratagus: peter at fedoraproject org FE6 > F7 (0:2.2.4-1.fc6 > 0:2.2.3-1.fc7) system-config-date: nphilipp at fedoraproject org F7-updates-testing > F8 (0:1.9.5-1.fc7 > 0:1.9.4-1.fc8) tcptraceroute: sindrepb at fedoraproject org FE6 > F7-updates (0:1.5-0.2.beta7.fc6 > 0:1.5-0.1.beta7.fc7) tiquit: limb at fedoraproject org F7-updates > F8 (0:2.4-5.fc7 > 0:2.4-4.fc7) util-vserver: ensc at fedoraproject org FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7) FE6 > F7 (0:0.30.213-2.fc6 > 0:0.30.212-3.fc7) xdg-user-dirs: alexl at fedoraproject org F7-updates > F8 (0:0.8-3.fc7 > 0:0.8-2.fc8) xl2tpd: pwouters at fedoraproject org FE6 > F7 (0:1.1.11-2.fc6 > 0:1.1.09-1.fc7) xmlrpc-c: ensc at fedoraproject org FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7) FE6 > F7 (0:1.06.17-1.fc6 > 0:1.06.11-2.fc7) From walters at redhat.com Fri Aug 17 18:23:16 2007 From: walters at redhat.com (Colin Walters) Date: Fri, 17 Aug 2007 14:23:16 -0400 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <46C58A05.3060005@redhat.com> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <1187283455.13210.28.camel@cutter> <46C56F55.3060503@redhat.com> <46C58A05.3060005@redhat.com> Message-ID: On 8/17/07, Harald Hoyer wrote: > > > ok, with the attached perl script, I quickly spotted for my packages: Cool. I briefly toyed with this problem yesterday but am unlikely to have a chance to improve my script in the next few days, so I'll just post it now because it has some architectural differences to yours. * I have a feeling that regular expressions are only going to be part of the answer. Files out there are messy. Turns out Python has this neat "difflib" library for fuzzy text matching. * It operates on all files, not just *.[ch] * It uses Python's leet generator functionality to cleanly mix traversing a directory tree and searching -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: analyze-directory Type: application/octet-stream Size: 1740 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Aug 17 18:53:10 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 17 Aug 2007 20:53:10 +0200 Subject: No python in koji Message-ID: <20070817185310.GK10980@puariko.nirvana> Hi, trying to build something that uses Requires: python-abi = %(%{__python} -c "import sys ; print sys.version[:3]") or similar breaks in koji with sh: /usr/bin/python: No such file or directory sh: python: command not found error: line 33: Version required: Requires: python-abi = See for example the smart builds for F7 and F8: http://koji.fedoraproject.org/koji/getfile?taskID=106564&name=root.log http://koji.fedoraproject.org/koji/getfile?taskID=106560&name=root.log also there are lots of non-fatal mount: XXXX already mounted or /var/lib/mock/YYY/root/XXX busy which don't seem kosher either. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Aug 17 18:58:44 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 17 Aug 2007 14:58:44 -0400 Subject: No python in koji In-Reply-To: <20070817185310.GK10980@puariko.nirvana> References: <20070817185310.GK10980@puariko.nirvana> Message-ID: <20070817145844.05360e52@ender> On Fri, 17 Aug 2007 20:53:10 +0200 Axel Thimm wrote: > trying to build something that uses > > Requires: python-abi = %(%{__python} -c "import sys ; print > sys.version[:3]") You're not supposed to use that, for quite some time now. > or similar breaks in koji with > > sh: /usr/bin/python: No such file or directory > sh: python: command not found > error: line 33: Version required: Requires: python-abi = > > See for example the smart builds for F7 and F8: > > http://koji.fedoraproject.org/koji/getfile?taskID=106564&name=root.log > http://koji.fedoraproject.org/koji/getfile?taskID=106560&name=root.log again not supposed to use that. And if you are building a python package, you need to BuildRequire python-devel. > also there are lots of non-fatal > > mount: XXXX already mounted or /var/lib/mock/YYY/root/XXX busy > > which don't seem kosher either. These are fine. There are some disagreements between koji and mock about mount points, koji does it for mock and cleans up after mock should mock go awry. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Aug 17 19:15:16 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 17 Aug 2007 21:15:16 +0200 Subject: No python in koji In-Reply-To: <20070817145844.05360e52@ender> References: <20070817185310.GK10980@puariko.nirvana> <20070817145844.05360e52@ender> Message-ID: <20070817191516.GM10980@puariko.nirvana> On Fri, Aug 17, 2007 at 02:58:44PM -0400, Jesse Keating wrote: > On Fri, 17 Aug 2007 20:53:10 +0200 > Axel Thimm wrote: > > > trying to build something that uses > > > > Requires: python-abi = %(%{__python} -c "import sys ; print > > sys.version[:3]") > > You're not supposed to use that, for quite some time now. OK, but that's only half the story, what about %{!?python_sitearch:%global python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)")} which is not defined and needed. And for anything that will require a call to perl/python/ruby etc. to determine some parameters. It looks like koji expands the specfile macros before it pulls in the dependencies, so if it isn't in the minimal buildroot you can't use something in %(). > > or similar breaks in koji with > > > > sh: /usr/bin/python: No such file or directory > > sh: python: command not found > > error: line 33: Version required: Requires: python-abi = > > > > See for example the smart builds for F7 and F8: > > > > http://koji.fedoraproject.org/koji/getfile?taskID=106564&name=root.log > > http://koji.fedoraproject.org/koji/getfile?taskID=106560&name=root.log > > again not supposed to use that. And if you are building a python > package, you need to BuildRequire python-devel. That's what I do, still no joy - see for yourself at http://cvs.fedora.redhat.com/viewcvs/*checkout*/rpms/smart/devel/smart.spec > > also there are lots of non-fatal > > > > mount: XXXX already mounted or /var/lib/mock/YYY/root/XXX busy > > > > which don't seem kosher either. > > These are fine. There are some disagreements between koji and mock > about mount points, koji does it for mock and cleans up after mock > should mock go awry. Hm, not really comforting though that two basic building blocks don't communicate better. Sounds like mock needs an option like --do-not-setup-chroot-I-ll-do-that-for-you. -- 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 jjohnstn at redhat.com Fri Aug 17 19:19:40 2007 From: jjohnstn at redhat.com (Jeff Johnston) Date: Fri, 17 Aug 2007 15:19:40 -0400 Subject: FeatureEclipse33 Status In-Reply-To: <1187112770.11441.17.camel@localhost.localdomain> References: <1187112770.11441.17.camel@localhost.localdomain> Message-ID: <46C5F4CC.4040604@redhat.com> Andrew Overholt wrote: > Hi, > > Here's the status of the Fedora 8 feature of updating the Eclipse stack > to the 3.3 (Europa) base [1]. I've CC'd all of the maintainers. Please > reply with answers where you can. > > > ChangeLog (Jeff Johnston) > - mostly complete (I think) > - Jeff? Missing removed files support (major usability issue). The entry seems to stop when there are strange files (e.g. gifs or binary files it knows nothing about) (major bug). New files should just put: New file comment beside them (minor nit). If all of these are fixed, then I would say it is complete. > > CDT & autotools (Jeff Johnston) > - ready AFAIK > - Jeff? Ready enough. Would like to add template support for the autoconf editor. Would like to add sample wizards for new autotools executable project, new autotools library project, possibly a few more... From jkeating at redhat.com Fri Aug 17 19:23:00 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 17 Aug 2007 15:23:00 -0400 Subject: No python in koji In-Reply-To: <20070817191516.GM10980@puariko.nirvana> References: <20070817185310.GK10980@puariko.nirvana> <20070817145844.05360e52@ender> <20070817191516.GM10980@puariko.nirvana> Message-ID: <20070817152300.31862cb8@ender> On Fri, 17 Aug 2007 21:15:16 +0200 Axel Thimm wrote: > OK, but that's only half the story, what about > > %{!?python_sitearch:%global python_sitearch %(%{__python} -c "from > distutils.sysconfig import get_python_lib; print get_python_lib(1)")} > > which is not defined and needed. And for anything that will require a > call to perl/python/ruby etc. to determine some parameters. It looks > like koji expands the specfile macros before it pulls in the > dependencies, so if it isn't in the minimal buildroot you can't use > something in %(). Which is harmless for every case we've seen. Since you don't list Requires: python-abi stuff anymore the Requires line isn't evaluated at this moment when the spec file is parsed for what the BuildRequires are. Once the BuildRequires are in place and the build is started, all those things are there to do the evaluation and complete the build. If you continue to get build failures /after/ removing the Requires: python-abi stuff let me know and show me the logs. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Aug 17 19:36:53 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 17 Aug 2007 21:36:53 +0200 Subject: No python in koji In-Reply-To: <20070817152300.31862cb8@ender> References: <20070817185310.GK10980@puariko.nirvana> <20070817145844.05360e52@ender> <20070817191516.GM10980@puariko.nirvana> <20070817152300.31862cb8@ender> Message-ID: <20070817193653.GO10980@puariko.nirvana> On Fri, Aug 17, 2007 at 03:23:00PM -0400, Jesse Keating wrote: > On Fri, 17 Aug 2007 21:15:16 +0200 > Axel Thimm wrote: > > > OK, but that's only half the story, what about > > > > %{!?python_sitearch:%global python_sitearch %(%{__python} -c "from > > distutils.sysconfig import get_python_lib; print get_python_lib(1)")} > > > > which is not defined and needed. And for anything that will require a > > call to perl/python/ruby etc. to determine some parameters. It looks > > like koji expands the specfile macros before it pulls in the > > dependencies, so if it isn't in the minimal buildroot you can't use > > something in %(). > > Which is harmless for every case we've seen. Since you don't list > Requires: python-abi stuff anymore the Requires line isn't evaluated at > this moment when the spec file is parsed for what the BuildRequires > are. Once the BuildRequires are in place and the build is started, all > those things are there to do the evaluation and complete the build. > > If you continue to get build failures /after/ removing the Requires: > python-abi stuff let me know and show me the logs. No, I guess it won't, it only errored out on the Requires. But I still feel this is very thin ice we're walking on. For one we break with RHEL (which doesn't have python-abi in older releases, OK, as Fedora we sometimes don't care about RHEL), for another we preclude many use cases of %() in specfiles, e.g. anything that will break rpm's specfile parses if %() returns %{nil}. Anyway, I'm good to go with the issue at hand and don't really feel like improving the rest of the world today ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Aug 17 19:43:24 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 17 Aug 2007 15:43:24 -0400 Subject: No python in koji In-Reply-To: <20070817193653.GO10980@puariko.nirvana> References: <20070817185310.GK10980@puariko.nirvana> <20070817145844.05360e52@ender> <20070817191516.GM10980@puariko.nirvana> <20070817152300.31862cb8@ender> <20070817193653.GO10980@puariko.nirvana> Message-ID: <20070817154324.7df61aff@ender> On Fri, 17 Aug 2007 21:36:53 +0200 Axel Thimm wrote: > No, I guess it won't, it only errored out on the Requires. But I still > feel this is very thin ice we're walking on. For one we break with > RHEL (which doesn't have python-abi in older releases, OK, as Fedora > we sometimes don't care about RHEL), Our RHEL4 "initial build root" is quite a bit fatter than Fedora's, and includes python so this is a non-issue there. > for another we preclude many use > cases of %() in specfiles, e.g. anything that will break rpm's > specfile parses if %() returns %{nil}. But it has to be something that is hit while just querying for the (Build)Requires, so a pretty narrow scope. > > Anyway, I'm good to go with the issue at hand and don't really feel > like improving the rest of the world today ;) Cheers! -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tibbs at math.uh.edu Fri Aug 17 19:47:12 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 17 Aug 2007 14:47:12 -0500 Subject: No python in koji In-Reply-To: <20070817193653.GO10980@puariko.nirvana> References: <20070817185310.GK10980@puariko.nirvana> <20070817145844.05360e52@ender> <20070817191516.GM10980@puariko.nirvana> <20070817152300.31862cb8@ender> <20070817193653.GO10980@puariko.nirvana> Message-ID: >>>>> "AT" == Axel Thimm writes: AT> No, I guess it won't, it only errored out on the Requires. But I AT> still feel this is very thin ice we're walking on. The method is required for everything else that wants to encode some information into the spec which is gathered by running something which is BuildRequire:d. All Ruby and PHP packages, for example. AT> for another we preclude many use cases of %() in specfiles, AT> e.g. anything that will break rpm's specfile parses if %() returns AT> %{nil}. You define your macros in such a way that they are provided meaningless but syntactically correct values in the case that the necessary executables aren't there. - J< From wart at kobold.org Fri Aug 17 19:58:11 2007 From: wart at kobold.org (Michael Thomas) Date: Fri, 17 Aug 2007 12:58:11 -0700 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <1187272054.3439.109.camel@dhcp83-165.boston.redhat.com> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <46C3DCA5.9080909@kobold.org> <46C3DF4B.9040105@hhs.nl> <46C44976.7030208@gmail.com> <1187272054.3439.109.camel@dhcp83-165.boston.redhat.com> Message-ID: <46C5FDD3.7070507@kobold.org> Tom "spot" Callaway wrote: > On Thu, 2007-08-16 at 14:56 +0200, Adel Gadllah wrote: >> Hans de Goede wrote: >>> >>> GPL+, the version in the COPYING file is irrelevant. >> this sounds wrong ... if the source says nothing and the copying says >> gplv2 it _is_ gplv2. > > COPYING does not signal licensing intent (it might not seem intuitive, > but this is what Red Hat legal told us, and we're going by that). > > The order of operations goes like this: > > 1. What does the code say? If it specifies a version, that's what it is. > 2. Does the code conflict with itself? (file1.c and file2.c are compiled > together but have different licensing) > 2A. Are the conflicting licenses compatible? > 2AA. Does one license overpower the other one? (GPL/LGPL does this) If > so, the strictest license wins. > 3. What does the documentation say? This signals the author(s) > intentions from a legal perspective, although, not as binding as in the > source. If the documentation specifies a version when the source does > not, then we can use the documentation as our source. NOTE: COPYING does > not count as documentation, since the author(s) didn't write it. > 4. If neither the source, nor the upstream composed documentation says > anything about the license version, then it could be under _ANY_ version > of the GPL. The version listed in COPYING is irrelevant from this > perspective. As a slight variant to this, the standard Tcl 'license.terms' file contains the following boilerplate: "The following terms apply to all files associated with the software unless explicitly disclaimed in individual files." Does this qualify as the same irrelevance as COPYING because it was not written by the author? Some Tcl packages (bwidget) contain only this license file, but no reference to the license file in any of the source files. Shouldn't this still be enough to qualify the license as 'TCL'? --Wart [1]http://fedoraproject.org/wiki/Licensing/TCL From Axel.Thimm at ATrpms.net Fri Aug 17 19:59:34 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 17 Aug 2007 21:59:34 +0200 Subject: No python in koji In-Reply-To: References: <20070817185310.GK10980@puariko.nirvana> <20070817145844.05360e52@ender> <20070817191516.GM10980@puariko.nirvana> <20070817152300.31862cb8@ender> <20070817193653.GO10980@puariko.nirvana> Message-ID: <20070817195934.GA562@puariko.nirvana> On Fri, Aug 17, 2007 at 02:47:12PM -0500, Jason L Tibbitts III wrote: > >>>>> "AT" == Axel Thimm writes: > > AT> No, I guess it won't, it only errored out on the Requires. But I > AT> still feel this is very thin ice we're walking on. > > The method is required for everything else that wants to encode some > information into the spec which is gathered by running something which > is BuildRequire:d. All Ruby and PHP packages, for example. > > AT> for another we preclude many use cases of %() in specfiles, > AT> e.g. anything that will break rpm's specfile parses if %() returns > AT> %{nil}. > > You define your macros in such a way that they are provided > meaningless but syntactically correct values in the case that the > necessary executables aren't there. So all the say PHP stuff like Requires: php(zend-abi) = %{php_zend_api} Requires: php(api) = %{php_core_api} Requires: php-api = %{php_apiver} have such failsafe definitions in the rhs macros? Obviously they do. I understand the chicken-and-egg situation with %() in BRs, so BRs should be kind of macro-less, but the rest should be able to use anything the BRs provide w/o having to go through loops. I think the workaround of requiring such careful design of macros is more work than fixing koji. Anyway my packages are in the build queue, if they get out successfully (which they will, I hope) I'm a happy man, what else does a man want of his life? ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Aug 17 19:58:34 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 17 Aug 2007 15:58:34 -0400 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <46C5FDD3.7070507@kobold.org> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <46C3DCA5.9080909@kobold.org> <46C3DF4B.9040105@hhs.nl> <46C44976.7030208@gmail.com> <1187272054.3439.109.camel@dhcp83-165.boston.redhat.com> <46C5FDD3.7070507@kobold.org> Message-ID: <20070817155834.3c872bf6@ender> On Fri, 17 Aug 2007 12:58:11 -0700 Michael Thomas wrote: > As a slight variant to this, the standard Tcl 'license.terms' file > contains the following boilerplate: > > "The following terms apply to all files associated with the software > unless explicitly disclaimed in individual files." > > Does this qualify as the same irrelevance as COPYING because it was > not written by the author? Some Tcl packages (bwidget) contain only > this license file, but no reference to the license file in any of the > source files. Shouldn't this still be enough to qualify the license > as 'TCL'? If it's not modified we have to follow the letter of the file. In the case of GPL and COPYING, the letter of the file states that if no version is indicated, /any/ version can be used, which results in "GPL+". I'd have to examine the license.terms file closely but the basic idea is that whatever is in the file counts. One would hope that the license.terms doesn't have such an open ended pitfall within it. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Aug 17 20:00:43 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 17 Aug 2007 16:00:43 -0400 Subject: No python in koji In-Reply-To: <20070817195934.GA562@puariko.nirvana> References: <20070817185310.GK10980@puariko.nirvana> <20070817145844.05360e52@ender> <20070817191516.GM10980@puariko.nirvana> <20070817152300.31862cb8@ender> <20070817193653.GO10980@puariko.nirvana> <20070817195934.GA562@puariko.nirvana> Message-ID: <20070817160043.2f9a8e5e@ender> On Fri, 17 Aug 2007 21:59:34 +0200 Axel Thimm wrote: > I think the workaround of requiring such careful design of macros is > more work than fixing koji. "fixing koji" to do what exactly? Use a full install in the chroot when querying the spec and building the srpm? Maybe the problem lies in RPM and not koji, to make RPM ignore it's Requires: stuff when you only care about the BuildRequires? (although isn't it fun that BuildRequires /are/ Requires in the source rpm?) -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Aug 17 20:46:43 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 17 Aug 2007 22:46:43 +0200 Subject: No python in koji In-Reply-To: <20070817160043.2f9a8e5e@ender> References: <20070817185310.GK10980@puariko.nirvana> <20070817145844.05360e52@ender> <20070817191516.GM10980@puariko.nirvana> <20070817152300.31862cb8@ender> <20070817193653.GO10980@puariko.nirvana> <20070817195934.GA562@puariko.nirvana> <20070817160043.2f9a8e5e@ender> Message-ID: <20070817204643.GB562@puariko.nirvana> On Fri, Aug 17, 2007 at 04:00:43PM -0400, Jesse Keating wrote: > On Fri, 17 Aug 2007 21:59:34 +0200 > Axel Thimm wrote: > > > I think the workaround of requiring such careful design of macros is > > more work than fixing koji. > > "fixing koji" to do what exactly? Use a full install in the chroot > when querying the spec and building the srpm? Maybe the problem lies > in RPM and not koji, to make RPM ignore it's Requires: stuff when you > only care about the BuildRequires? No, what I use in my ancient-dumber-than-kiss chroot builder is to extract the BRs, install them and then kickstart any rpmbuild machinery. > (although isn't it fun that BuildRequires /are/ Requires in the > source rpm?) and you get the fact that these "Requires" are already macro expanded so no chicken/egg situation here even if the BRs had had been macroized. So koji could do the following pseudo-code and avoid all troubles: rpm -qRp foo-1-2.src.rpm | xargs yum --root=xxx --yes install rpmbuild --root xxx ... -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Aug 17 21:00:22 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 17 Aug 2007 17:00:22 -0400 Subject: No python in koji In-Reply-To: <20070817204643.GB562@puariko.nirvana> References: <20070817185310.GK10980@puariko.nirvana> <20070817145844.05360e52@ender> <20070817191516.GM10980@puariko.nirvana> <20070817152300.31862cb8@ender> <20070817193653.GO10980@puariko.nirvana> <20070817195934.GA562@puariko.nirvana> <20070817160043.2f9a8e5e@ender> <20070817204643.GB562@puariko.nirvana> Message-ID: <20070817170022.10e935f4@ender> On Fri, 17 Aug 2007 22:46:43 +0200 Axel Thimm wrote: > No, what I use in my ancient-dumber-than-kiss chroot builder is to > extract the BRs, install them and then kickstart any rpmbuild > machinery. How do you extract the BRs? Are you doing it on the host machine, which could have an ancient rpm, or ancient tools that are needed for macro expansion? Do you have an Everything install on it, or at least every piece of software you could expect to run across in a macro? What about new languages that aren't built for the machine you're doing the BR extraction from? > > > (although isn't it fun that BuildRequires /are/ Requires in the > > source rpm?) > > and you get the fact that these "Requires" are already macro expanded > so no chicken/egg situation here even if the BRs had had been > macroized. > > So koji could do the following pseudo-code and avoid all troubles: > > rpm -qRp foo-1-2.src.rpm | xargs yum --root=xxx --yes install > rpmbuild --root xxx ... Where does the srpm come from? Koji works from cvs tags to ensure that what you build is actually what came from CVS, so you have to construct the srpm out of the spec and sources (and oh yeah, sources come from the lookaside, no trojan sources in random srpm tossed in) -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jamatos at fc.up.pt Fri Aug 17 21:07:10 2007 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Fri, 17 Aug 2007 22:07:10 +0100 Subject: Failed access to koji Message-ID: <200708172207.10888.jamatos@fc.up.pt> Hi, when logging in to koji I get an error koji.fedoraproject.org has received an incorrect or unexpected message. Error Code -12227 This is the error message I get with firefox, konqueror fails as well. -- Jos? Ab?lio From jkeating at redhat.com Fri Aug 17 22:00:51 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 17 Aug 2007 18:00:51 -0400 Subject: Failed access to koji In-Reply-To: <200708172207.10888.jamatos@fc.up.pt> References: <200708172207.10888.jamatos@fc.up.pt> Message-ID: <20070817180051.21b02a73@ender> On Fri, 17 Aug 2007 22:07:10 +0100 "Jos? Matos" wrote: > when logging in to koji I get an error > koji.fedoraproject.org has received an incorrect or unexpected > message. Error Code -12227 > > This is the error message I get with firefox, konqueror fails > as well. Have you ran through fedora-packager-setup.sh and followed the instructions on importing the ssl cert into your browser? -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Aug 17 22:57:38 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 18 Aug 2007 00:57:38 +0200 Subject: No python in koji In-Reply-To: <20070817170022.10e935f4@ender> References: <20070817185310.GK10980@puariko.nirvana> <20070817145844.05360e52@ender> <20070817191516.GM10980@puariko.nirvana> <20070817152300.31862cb8@ender> <20070817193653.GO10980@puariko.nirvana> <20070817195934.GA562@puariko.nirvana> <20070817160043.2f9a8e5e@ender> <20070817204643.GB562@puariko.nirvana> <20070817170022.10e935f4@ender> Message-ID: <20070817225738.GD562@puariko.nirvana> On Fri, Aug 17, 2007 at 05:00:22PM -0400, Jesse Keating wrote: > On Fri, 17 Aug 2007 22:46:43 +0200 > Axel Thimm wrote: > > > No, what I use in my ancient-dumber-than-kiss chroot builder is to > > extract the BRs, install them and then kickstart any rpmbuild > > machinery. > > How do you extract the BRs? Are you doing it on the host machine, > which could have an ancient rpm, or ancient tools that are needed for > macro expansion? Do you have an Everything install on it, or at least > every piece of software you could expect to run across in a macro? > What about new languages that aren't built for the machine you're doing > the BR extraction from? I think you got me there. But that just means that BRs are not to be macroized. > > > (although isn't it fun that BuildRequires /are/ Requires in the > > > source rpm?) > > > > and you get the fact that these "Requires" are already macro expanded > > so no chicken/egg situation here even if the BRs had had been > > macroized. > > > > So koji could do the following pseudo-code and avoid all troubles: > > > > rpm -qRp foo-1-2.src.rpm | xargs yum --root=xxx --yes install > > rpmbuild --root xxx ... > > Where does the srpm come from? Koji works from cvs tags to ensure that > what you build is actually what came from CVS, so you have to construct > the srpm out of the spec and sources (and oh yeah, sources come from > the lookaside, no trojan sources in random srpm tossed in) So we have trojan detection in CVS and lookaside now? ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sat Aug 18 00:35:48 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 17 Aug 2007 20:35:48 -0400 Subject: No python in koji In-Reply-To: <20070817225738.GD562@puariko.nirvana> References: <20070817185310.GK10980@puariko.nirvana> <20070817145844.05360e52@ender> <20070817191516.GM10980@puariko.nirvana> <20070817152300.31862cb8@ender> <20070817193653.GO10980@puariko.nirvana> <20070817195934.GA562@puariko.nirvana> <20070817160043.2f9a8e5e@ender> <20070817204643.GB562@puariko.nirvana> <20070817170022.10e935f4@ender> <20070817225738.GD562@puariko.nirvana> Message-ID: <20070817203548.3c392614@ender> On Sat, 18 Aug 2007 00:57:38 +0200 Axel Thimm wrote: > I think you got me there. But that just means that BRs are not to be > macroized. But unfortunately, as you've noticed, Rs get processed too when trying to find BRs. I don't know if it's possible to stop this at the rpm level but it might be nice (: > > > > (although isn't it fun that BuildRequires /are/ Requires in the > > > > source rpm?) > > > > > > and you get the fact that these "Requires" are already macro > > > expanded so no chicken/egg situation here even if the BRs had had > > > been macroized. > > > > > > So koji could do the following pseudo-code and avoid all troubles: > > > > > > rpm -qRp foo-1-2.src.rpm | xargs yum --root=xxx --yes install > > > rpmbuild --root xxx ... > > > > Where does the srpm come from? Koji works from cvs tags to ensure > > that what you build is actually what came from CVS, so you have to > > construct the srpm out of the spec and sources (and oh yeah, > > sources come from the lookaside, no trojan sources in random srpm > > tossed in) > > So we have trojan detection in CVS and lookaside now? ;) Heh, well... no. It's just slightly harder to chuck your own srpm with your own source tarball into the build system for a "official" build. You actually have to go through the cvs procedure where there are a few more eyes watching. Now, an interesting idea would be to continuously run some sort of analyzer across the tarballs on the lookaside cache. Would be interesting if you could find anything there. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From harald at redhat.com Sat Aug 18 06:43:00 2007 From: harald at redhat.com (Harald Hoyer) Date: Sat, 18 Aug 2007 08:43:00 +0200 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <1187283455.13210.28.camel@cutter> <46C56F55.3060503@redhat.com> <46C58A05.3060005@redhat.com> Message-ID: <46C694F4.8040301@redhat.com> Colin Walters schrieb: > On 8/17/07, *Harald Hoyer* > wrote: > > > ok, with the attached perl script, I quickly spotted for my packages: > > > Cool. I briefly toyed with this problem yesterday but am unlikely to > have a chance to improve my script in the next few days, so I'll just > post it now because it has some architectural differences to yours. > > * I have a feeling that regular expressions are only going to be part of > the answer. Files out there are messy. Turns out Python has this neat > "difflib" library for fuzzy text matching. uh, I didn't want to be to fuzzy.. better display the header, than to match a false positive.. > * It operates on all files, not just *.[ch] err.. just a matter of command line options and/or the find ... > * It uses Python's leet generator functionality to cleanly mix > traversing a directory tree and searching fine :) /me was just lazy and hacked the script in 10 minutes, as you may tell from the source... But yes, yours may be better :) From jnovy at redhat.com Sat Aug 18 08:38:47 2007 From: jnovy at redhat.com (Jindrich Novy) Date: Sat, 18 Aug 2007 10:38:47 +0200 Subject: strange failure for dependency against libdb-4.5.so In-Reply-To: <20070817130838.35ba3fa8@ender> References: <46C50CD8.4080706@ioa.s.u-tokyo.ac.jp> <20070817083026.GA2498@dhcp-lab-186.brq.redhat.com> <200708171157.52240.ville.skytta@iki.fi> <20070817120819.GA2978@dhcp-lab-186.brq.redhat.com> <46C5C2AF.6080409@ioa.s.u-tokyo.ac.jp> <46C5C3ED.8070805@ioa.s.u-tokyo.ac.jp> <20070817183026.e23489d3.mschwendt.tmp0701.nospam@arcor.de> <20070817130838.35ba3fa8@ender> Message-ID: <20070818083847.GA7918@dhcp-lab-186.brq.redhat.com> On Fri, Aug 17, 2007 at 01:08:38PM -0400, Jesse Keating wrote: > On Fri, 17 Aug 2007 18:30:26 +0200 > Michael Schwendt wrote: > > > If RPM in the build environment is a version that obsoletes packages > > based on virtual provides, these Provides/Obsoletes in compat-db are > > the culprit. In short, when compat-db "Provides: db4 = > > some-low-version", the "db4" packages with a higher version upgrades > > compat-db. Some background can be found here: > > https://bugzilla.redhat.com/111071 It has effected multiple packages > > since FC =~ 1 > > > > Recently, Panu has mentioned that this "feature" in RPM will go away > > in a future release of RPM. But until then, don't use such virtual > > provides. They break. > > > Yes, in this case the automatic library provides in the compat-db > package should be well enough to satisfy anything that /needs/ the > older libraries to function. Ok, the new compat-db without db4-* provides is now built. I'm Cc'ing fedora-maintainers as well so that everyone is aware that direct library dependencies are now needed for packages using older db4s. Jindrich --- Jindrich Novy http://people.redhat.com/jnovy/ From mmahut at fedoraproject.org Sat Aug 18 09:02:23 2007 From: mmahut at fedoraproject.org (Marek Mahut) Date: Sat, 18 Aug 2007 11:02:23 +0200 Subject: build fails without reason, bug in plague? Message-ID: <46C6B59F.3070200@fedoraproject.org> Hello maintainers, Today, I received an error that my build failed, but after deep look on logs I found that there was no real reason why this build failed [1]. Adel Gadllah told me that it isn't the first time it happens. Thoughts? [1] http://buildsys.fedoraproject.org/logs/fedora-4-epel/35730-cvsweb-3.0.5-2.el4/noarch/ -- Marek Mahut http://www.fedoraproject.org/ Fedora Project http://www.jamendo.com/ From mmahut at fedoraproject.org Sat Aug 18 09:16:01 2007 From: mmahut at fedoraproject.org (Marek Mahut) Date: Sat, 18 Aug 2007 11:16:01 +0200 Subject: build fails without reason, bug in plague? In-Reply-To: <46C6B59F.3070200@fedoraproject.org> References: <46C6B59F.3070200@fedoraproject.org> Message-ID: <46C6B8D1.8000709@fedoraproject.org> Marek Mahut wrote: > Hello maintainers, > > Today, I received an error that my build failed, but after deep look on > logs I found that there was no real reason why this build failed [1]. > Adel Gadllah told me that it isn't the first time it happens. > > Thoughts? Hmm, the same here, http://buildsys.fedoraproject.org/logs/fedora-4-epel/35731-cvsweb-3.0.5-2.el4/ http://buildsys.fedoraproject.org/logs/fedora-5-epel/35732-cvsweb-3.0.6-4.el5/ I will maybe try later. -- Marek Mahut http://www.fedoraproject.org/ Fedora Project http://www.jamendo.com/ From opensource at till.name Sat Aug 18 09:13:14 2007 From: opensource at till.name (Till Maas) Date: Sat, 18 Aug 2007 11:13:14 +0200 Subject: build fails without reason, bug in plague? In-Reply-To: <46C6B59F.3070200@fedoraproject.org> References: <46C6B59F.3070200@fedoraproject.org> Message-ID: <200708181113.20631.opensource@till.name> On Sa August 18 2007, Marek Mahut wrote: > Hello maintainers, > > Today, I received an error that my build failed, but after deep look on > logs I found that there was no real reason why this build failed [1]. > Adel Gadllah told me that it isn't the first time it happens. https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/125 See also the "Successful build failed" thread on this list. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From mtasaka at ioa.s.u-tokyo.ac.jp Sat Aug 18 11:43:36 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sat, 18 Aug 2007 20:43:36 +0900 Subject: strange failure for dependency against libdb-4.5.so In-Reply-To: <20070818083847.GA7918@dhcp-lab-186.brq.redhat.com> References: <46C50CD8.4080706@ioa.s.u-tokyo.ac.jp> <20070817083026.GA2498@dhcp-lab-186.brq.redhat.com> <200708171157.52240.ville.skytta@iki.fi> <20070817120819.GA2978@dhcp-lab-186.brq.redhat.com> <46C5C2AF.6080409@ioa.s.u-tokyo.ac.jp> <46C5C3ED.8070805@ioa.s.u-tokyo.ac.jp> <20070817183026.e23489d3.mschwendt.tmp0701.nospam@arcor.de> <20070817130838.35ba3fa8@ender> <20070818083847.GA7918@dhcp-lab-186.brq.redhat.com> Message-ID: <46C6DB68.3010102@ioa.s.u-tokyo.ac.jp> Jindrich Novy wrote, at 08/18/2007 05:38 PM +9:00: > On Fri, Aug 17, 2007 at 01:08:38PM -0400, Jesse Keating wrote: >> On Fri, 17 Aug 2007 18:30:26 +0200 >> Michael Schwendt wrote: >> >>> If RPM in the build environment is a version that obsoletes packages >>> based on virtual provides, these Provides/Obsoletes in compat-db are >>> the culprit. In short, when compat-db "Provides: db4 = >>> some-low-version", the "db4" packages with a higher version upgrades >>> compat-db. Some background can be found here: >>> https://bugzilla.redhat.com/111071 It has effected multiple packages >>> since FC =~ 1 >>> >>> Recently, Panu has mentioned that this "feature" in RPM will go away >>> in a future release of RPM. But until then, don't use such virtual >>> provides. They break. >> >> Yes, in this case the automatic library provides in the compat-db >> package should be well enough to satisfy anything that /needs/ the >> older libraries to function. > > Ok, the new compat-db without db4-* provides is now built. I'm Cc'ing > fedora-maintainers as well so that everyone is aware that direct > library dependencies are now needed for packages using older db4s. > > Jindrich Now (scratch) rebuild of oyranos (under review) is okay. For libdb-4.5.so dependency it is now solved. http://koji.fedoraproject.org/koji/taskinfo?taskID=108270 Thank you, everyone! Mamoru From tmz at pobox.com Sat Aug 18 19:08:20 2007 From: tmz at pobox.com (Todd Zullinger) Date: Sat, 18 Aug 2007 15:08:20 -0400 Subject: tor security updates Message-ID: <20070818190820.GB18032@psilocybe.teonanacatl.org> Someone asked on fedora-list about updates to tor which fix some security issues. The version in F7 is 0.1.2.13, while the latest upstream is 0.1.2.16. Looking in Koji, 0.1.2.1{4,5,6} have all been built (with 0.1.2.16 having been built on August 2*), yet all of them are in the pending state still. Does anyone know the reason they're not being pushed to updates-testing? * successfully for F7, but failed for rawhide with what looks like one of the "open_missing_mode" errors. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A little inaccuracy sometimes saves a ton of explanation. -- H. H. Munro (Saki) (1870-1916) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From bugs.michael at gmx.net Sat Aug 18 19:22:57 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 18 Aug 2007 21:22:57 +0200 Subject: tor security updates In-Reply-To: <20070818190820.GB18032@psilocybe.teonanacatl.org> References: <20070818190820.GB18032@psilocybe.teonanacatl.org> Message-ID: <20070818212257.90333b25.bugs.michael@gmx.net> On Sat, 18 Aug 2007 15:08:20 -0400, Todd Zullinger wrote: > Someone asked on fedora-list about updates to tor which fix some > security issues. The version in F7 is 0.1.2.13, while the latest > upstream is 0.1.2.16. Looking in Koji, 0.1.2.1{4,5,6} have all been > built (with 0.1.2.16 having been built on August 2*), yet all of them > are in the pending state still. Does anyone know the reason they're > not being pushed to updates-testing? > > * successfully for F7, but failed for rawhide with what looks like one > of the "open_missing_mode" errors. Have you pushed them using Bodhi, the "Fedora Updates System"? https://admin.fedoraproject.org/updates From opensource at till.name Sat Aug 18 19:36:31 2007 From: opensource at till.name (Till Maas) Date: Sat, 18 Aug 2007 21:36:31 +0200 Subject: tor security updates In-Reply-To: <20070818212257.90333b25.bugs.michael@gmx.net> References: <20070818190820.GB18032@psilocybe.teonanacatl.org> <20070818212257.90333b25.bugs.michael@gmx.net> Message-ID: <200708182136.37384.opensource@till.name> On Sa August 18 2007, Michael Schwendt wrote: > On Sat, 18 Aug 2007 15:08:20 -0400, Todd Zullinger wrote: > > Someone asked on fedora-list about updates to tor which fix some > > security issues. The version in F7 is 0.1.2.13, while the latest > > upstream is 0.1.2.16. Looking in Koji, 0.1.2.1{4,5,6} have all been > > built (with 0.1.2.16 having been built on August 2*), yet all of them > > are in the pending state still. Does anyone know the reason they're > > not being pushed to updates-testing? > > > > * successfully for F7, but failed for rawhide with what looks like one > > of the "open_missing_mode" errors. > > Have you pushed them using Bodhi, the "Fedora Updates System"? > https://admin.fedoraproject.org/updates Enrico Scholz is afaik the maintainer of tor[1], I put him into CC, Regards, Till [1] https://admin.fedoraproject.org/pkgdb/packages/name/tor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From tmz at pobox.com Sat Aug 18 19:36:36 2007 From: tmz at pobox.com (Todd Zullinger) Date: Sat, 18 Aug 2007 15:36:36 -0400 Subject: tor security updates In-Reply-To: <20070818212257.90333b25.bugs.michael@gmx.net> References: <20070818190820.GB18032@psilocybe.teonanacatl.org> <20070818212257.90333b25.bugs.michael@gmx.net> Message-ID: <20070818193636.GC18032@psilocybe.teonanacatl.org> Michael Schwendt wrote: > On Sat, 18 Aug 2007 15:08:20 -0400, Todd Zullinger wrote: > >> Someone asked on fedora-list about updates to tor which fix some >> security issues. The version in F7 is 0.1.2.13, while the latest >> upstream is 0.1.2.16. Looking in Koji, 0.1.2.1{4,5,6} have all >> been built (with 0.1.2.16 having been built on August 2*), yet all >> of them are in the pending state still. Does anyone know the >> reason they're not being pushed to updates-testing? >> >> * successfully for F7, but failed for rawhide with what looks like >> one of the "open_missing_mode" errors. > > Have you pushed them using Bodhi, the "Fedora Updates System"? > https://admin.fedoraproject.org/updates I'm not the maintainer, Enrico Scholz is. So we'd have to ask him that. (I'm also not a tor user, I was just made curious when I looked into it to try and answer the question on fedora-list.) It definitely seems odd that the packages were built quite quickly after the upstream releases were made and then left to sit in the pending state for so long. For the reference of others, here are the relevant links to Bodhi and Koji: https://admin.fedoraproject.org/updates/tor http://koji.fedoraproject.org/koji/packageinfo?packageID=4002 -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Chemistry is applied theology. -- Augustus Owsley Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From a.badger at gmail.com Sat Aug 18 21:28:07 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 18 Aug 2007 14:28:07 -0700 Subject: License for Extracted API Documentation Message-ID: <46C76467.9020808@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If a package has API Documentation extracted from source via doxygen, gtk-doc, or similar, can the documentation have a separate license from the code-source? In the particular case I'm looking at (qof) the source is currently under the GPLv2+ and the doxygen main page lists GFDL as the license for the documentation. The code in question has multiple contributors but I don't know whether the inline documentation was all created by a single person (who could dual license) or not. I can ask if that's important but would like to understand whether I need to or not first. - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGx2RnX6yAic2E7kgRAtLDAKCZ/VDFKl0uZv0JqJbkhIZli6RTJQCfbdGQ cgjwn/CpHOgq9sksVt1YgA8= =iete -----END PGP SIGNATURE----- From tcallawa at redhat.com Sat Aug 18 22:02:05 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sat, 18 Aug 2007 18:02:05 -0400 Subject: License for Extracted API Documentation In-Reply-To: <46C76467.9020808@gmail.com> References: <46C76467.9020808@gmail.com> Message-ID: <1187474525.3439.231.camel@dhcp83-165.boston.redhat.com> On Sat, 2007-08-18 at 14:28 -0700, Toshio Kuratomi wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > If a package has API Documentation extracted from source via doxygen, > gtk-doc, or similar, can the documentation have a separate license from > the code-source? In the particular case I'm looking at (qof) the source > is currently under the GPLv2+ and the doxygen main page lists GFDL as > the license for the documentation. The code in question has multiple > contributors but I don't know whether the inline documentation was all > created by a single person (who could dual license) or not. I can ask > if that's important but would like to understand whether I need to or > not first. GFDL and GPL are compatible licenses, so I'm going to say this is ok. ~spot From sundaram at fedoraproject.org Sat Aug 18 22:11:46 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 19 Aug 2007 03:41:46 +0530 Subject: License for Extracted API Documentation In-Reply-To: <1187474525.3439.231.camel@dhcp83-165.boston.redhat.com> References: <46C76467.9020808@gmail.com> <1187474525.3439.231.camel@dhcp83-165.boston.redhat.com> Message-ID: <46C76EA2.5000004@fedoraproject.org> Tom "spot" Callaway wrote: > GFDL and GPL are compatible licenses, so I'm going to say this is ok. > They are not. GNU FDL can have invariant sections for example. Rahul From lmacken at redhat.com Sat Aug 18 22:20:28 2007 From: lmacken at redhat.com (Luke Macken) Date: Sat, 18 Aug 2007 18:20:28 -0400 Subject: tor security updates In-Reply-To: <20070818190820.GB18032@psilocybe.teonanacatl.org> References: <20070818190820.GB18032@psilocybe.teonanacatl.org> Message-ID: <20070818222028.GE13706@crow> On Sat, Aug 18, 2007 at 03:08:20PM -0400, Todd Zullinger wrote: > Someone asked on fedora-list about updates to tor which fix some > security issues. The version in F7 is 0.1.2.13, while the latest > upstream is 0.1.2.16. Looking in Koji, 0.1.2.1{4,5,6} have all been > built (with 0.1.2.16 having been built on August 2*), yet all of them > are in the pending state still. Does anyone know the reason they're > not being pushed to updates-testing? > > * successfully for F7, but failed for rawhide with what looks like one > of the "open_missing_mode" errors. I updated the tor-0.1.2.16-1.fc7 update[0] with the references from the past two unreleased updates, and submitted it for pushing. luke [0]: https://admin.fedoraproject.org/updates/pending/F7/tor-0.1.2.16-1.fc7 From a.badger at gmail.com Sat Aug 18 22:25:45 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 18 Aug 2007 15:25:45 -0700 Subject: License for Extracted API Documentation In-Reply-To: <46C76EA2.5000004@fedoraproject.org> References: <46C76467.9020808@gmail.com> <1187474525.3439.231.camel@dhcp83-165.boston.redhat.com> <46C76EA2.5000004@fedoraproject.org> Message-ID: <46C771E9.8010407@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rahul Sundaram wrote: > Tom "spot" Callaway wrote: > >> GFDL and GPL are compatible licenses, so I'm going to say this is ok. >> > > They are not. GNU FDL can have invariant sections for example. In this particular case, the license is:: Permission is granted to copy, distribute, and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGx3HpX6yAic2E7kgRAtZ0AKCeeZdi0ASvzQ5XBWy9x9xDXBs7cQCfah6f DeiLqETDaT2WZXw7GHpc368= =DCQq -----END PGP SIGNATURE----- From mmcgrath at redhat.com Sun Aug 19 00:00:32 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 18 Aug 2007 19:00:32 -0500 Subject: build fails without reason, bug in plague? In-Reply-To: <46C6B59F.3070200@fedoraproject.org> References: <46C6B59F.3070200@fedoraproject.org> Message-ID: <46C78820.2040406@redhat.com> Marek Mahut wrote: > Hello maintainers, > > Today, I received an error that my build failed, but after deep look on > logs I found that there was no real reason why this build failed [1]. > Adel Gadllah told me that it isn't the first time it happens. > > Thoughts? > > [1] > http://buildsys.fedoraproject.org/logs/fedora-4-epel/35730-cvsweb-3.0.5-2.el4/noarch/ > > Please add any of these you find to the following ticket. https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/125 -Mike From mmahut at fedoraproject.org Sun Aug 19 06:50:46 2007 From: mmahut at fedoraproject.org (Marek Mahut) Date: Sun, 19 Aug 2007 08:50:46 +0200 Subject: build fails without reason, bug in plague? In-Reply-To: <46C78820.2040406@redhat.com> References: <46C6B59F.3070200@fedoraproject.org> <46C78820.2040406@redhat.com> Message-ID: <46C7E846.5040106@fedoraproject.org> Mike McGrath wrote: > Marek Mahut wrote: >> Hello maintainers, >> >> Today, I received an error that my build failed, but after deep look on >> logs I found that there was no real reason why this build failed [1]. >> Adel Gadllah told me that it isn't the first time it happens. >> >> Thoughts? >> >> [1] >> http://buildsys.fedoraproject.org/logs/fedora-4-epel/35730-cvsweb-3.0.5-2.el4/noarch/ >> >> >> > > Please add any of these you find to the following ticket. > https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/125 Done. FYI, last build failed again. > -Mike -- Marek Mahut http://www.fedoraproject.org/ Fedora Project http://www.jamendo.com/ From mmahut at fedoraproject.org Sun Aug 19 07:49:40 2007 From: mmahut at fedoraproject.org (Marek Mahut) Date: Sun, 19 Aug 2007 09:49:40 +0200 Subject: License of .spec files Message-ID: <46C7F614.2080405@fedoraproject.org> Hello all, I have a question, probably for spot, what's the license of .spec file it-self? Is it under license of a product or indirectly signed by CLA? Is it a good idea to include the license specification about the spec file in the .spec file? Thanks, -- Marek Mahut http://www.fedoraproject.org/ Fedora Project http://www.jamendo.com/ From bugs.michael at gmx.net Sun Aug 19 09:12:35 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 19 Aug 2007 11:12:35 +0200 Subject: tor security updates In-Reply-To: <20070818193636.GC18032@psilocybe.teonanacatl.org> References: <20070818190820.GB18032@psilocybe.teonanacatl.org> <20070818212257.90333b25.bugs.michael@gmx.net> <20070818193636.GC18032@psilocybe.teonanacatl.org> Message-ID: <20070819111235.096e8a2c.bugs.michael@gmx.net> On Sat, 18 Aug 2007 15:36:36 -0400, Todd Zullinger wrote: > Michael Schwendt wrote: > > On Sat, 18 Aug 2007 15:08:20 -0400, Todd Zullinger wrote: > > > >> Someone asked on fedora-list about updates to tor which fix some > >> security issues. The version in F7 is 0.1.2.13, while the latest > >> upstream is 0.1.2.16. Looking in Koji, 0.1.2.1{4,5,6} have all > >> been built (with 0.1.2.16 having been built on August 2*), yet all > >> of them are in the pending state still. Does anyone know the > >> reason they're not being pushed to updates-testing? > >> > >> * successfully for F7, but failed for rawhide with what looks like > >> one of the "open_missing_mode" errors. > > > > Have you pushed them using Bodhi, the "Fedora Updates System"? > > https://admin.fedoraproject.org/updates > > I'm not the maintainer, Enrico Scholz is. So we'd have to ask him > that. (I'm also not a tor user, I was just made curious when I looked > into it to try and answer the question on fedora-list.) It definitely > seems odd that the packages were built quite quickly after the > upstream releases were made and then left to sit in the pending state > for so long. > > For the reference of others, here are the relevant links to Bodhi and > Koji: > > https://admin.fedoraproject.org/updates/tor > http://koji.fedoraproject.org/koji/packageinfo?packageID=4002 Enrico has had trouble before inside Bodhi, the updates system, with other packages. It wouldn't surprise me if he's unhappy with the extra burden and waits for a convenient "make release" or similar. From lmacken at redhat.com Sun Aug 19 10:22:14 2007 From: lmacken at redhat.com (Luke Macken) Date: Sun, 19 Aug 2007 06:22:14 -0400 Subject: tor security updates In-Reply-To: <20070819111235.096e8a2c.bugs.michael@gmx.net> References: <20070818190820.GB18032@psilocybe.teonanacatl.org> <20070818212257.90333b25.bugs.michael@gmx.net> <20070818193636.GC18032@psilocybe.teonanacatl.org> <20070819111235.096e8a2c.bugs.michael@gmx.net> Message-ID: <20070819102214.GA26730@crow> On Sun, Aug 19, 2007 at 11:12:35AM +0200, Michael Schwendt wrote: > On Sat, 18 Aug 2007 15:36:36 -0400, Todd Zullinger wrote: > > > Michael Schwendt wrote: > > > On Sat, 18 Aug 2007 15:08:20 -0400, Todd Zullinger wrote: > > > > > >> Someone asked on fedora-list about updates to tor which fix some > > >> security issues. The version in F7 is 0.1.2.13, while the latest > > >> upstream is 0.1.2.16. Looking in Koji, 0.1.2.1{4,5,6} have all > > >> been built (with 0.1.2.16 having been built on August 2*), yet all > > >> of them are in the pending state still. Does anyone know the > > >> reason they're not being pushed to updates-testing? > > >> > > >> * successfully for F7, but failed for rawhide with what looks like > > >> one of the "open_missing_mode" errors. > > > > > > Have you pushed them using Bodhi, the "Fedora Updates System"? > > > https://admin.fedoraproject.org/updates > > > > I'm not the maintainer, Enrico Scholz is. So we'd have to ask him > > that. (I'm also not a tor user, I was just made curious when I looked > > into it to try and answer the question on fedora-list.) It definitely > > seems odd that the packages were built quite quickly after the > > upstream releases were made and then left to sit in the pending state > > for so long. > > > > For the reference of others, here are the relevant links to Bodhi and > > Koji: > > > > https://admin.fedoraproject.org/updates/tor > > http://koji.fedoraproject.org/koji/packageinfo?packageID=4002 > > Enrico has had trouble before inside Bodhi, the updates system, with > other packages. It wouldn't surprise me if he's unhappy with the extra > burden and waits for a convenient "make release" or similar. He hasn't reported any problems upstream, nor has he made the effort to comment on any of his updates regarding said issues. Many people have given feedback on his updates, and he receives an email for each one. If he is unhappy with the burden of being a maintainer, we need to figure out why so we can address it properly, and possibly find a co-maintainer willing to utilize our existing tools while we resolve the problem. luke From bugs.michael at gmx.net Sun Aug 19 10:48:34 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 19 Aug 2007 12:48:34 +0200 Subject: tor security updates In-Reply-To: <20070819102214.GA26730@crow> References: <20070818190820.GB18032@psilocybe.teonanacatl.org> <20070818212257.90333b25.bugs.michael@gmx.net> <20070818193636.GC18032@psilocybe.teonanacatl.org> <20070819111235.096e8a2c.bugs.michael@gmx.net> <20070819102214.GA26730@crow> Message-ID: <20070819124834.d6d57d47.bugs.michael@gmx.net> On Sun, 19 Aug 2007 06:22:14 -0400, Luke Macken wrote: > > Enrico has had trouble before inside Bodhi, the updates system, with > > other packages. It wouldn't surprise me if he's unhappy with the extra > > burden and waits for a convenient "make release" or similar. > > He hasn't reported any problems upstream, nor has he made the effort to > comment on any of his updates regarding said issues. Many people have > given feedback on his updates, and he receives an email for each one. > If he is unhappy with the burden of being a maintainer, we need to > figure out why so we can address it properly, and possibly find a > co-maintainer willing to utilize our existing tools while we resolve the > problem. Let me suggest the following: somebody from FESCo talks to Enrico and other packagers, whose F7 updates are missing for a long time according to the "EVR problems" report, to find out whether there are any problems with the work-flow and hurdles. It belongs to the "make sure we don't suck" area of activity. Missing updates, missing security updates, upgrade problems and unresolved dependency problems make Fedora look bad. From fedora at leemhuis.info Sun Aug 19 12:26:47 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 19 Aug 2007 14:26:47 +0200 Subject: EPEL report week 33 2007 Message-ID: <46C83707.1080605@leemhuis.info> = Weekly EPEL Summary = Week 33/2007 == Most important happenings == * reminder: now that EPEL is officially announced all new and updates EPEL packages go straight to EPEL-testing and *not* to the stable repo. EPEL-testing packages will (if everything is sane) get moved to stable repo in parallel with a quarterly RHEL update. If you have a security update that needs to go to EPEL-stable build normally and contact ThorstenLeemhuis There are some discussion to adjust that scheme (sync more often, push new packages directly or after a small warning period to stable, ...); see the list for details at https://www.redhat.com/archives/epel-devel-list/2007-August/msg00083.html * some discussion on the list to do much more on the mailiglist instead of in the meetings -- see https://www.redhat.com/archives/epel-devel-list/2007-August/msg00071.html * two RFC's which might be approved soon got posted to the list -- * Job description: https://www.redhat.com/archives/epel-devel-list/2007-August/msg00082.html * communication plan: https://www.redhat.com/archives/epel-devel-list/2007-August/msg00081.html if you don't like something speak up now From: http://fedoraproject.org/wiki/EPEL/Reports/Week33 == EPEL SIG Meeting == === Attending === >From the Steering Committee: * knurd (ThorstenLeemhuis) * mmcgrath (MikeMcGrath) * Jeff_S (Jeff Sheltren) * quaid (KarstenWade) * nirik (KevinFenzi) * stahnma (MichaelStahnke) Missing from the Steering Committee: * dgilmore (DennisGilmore) (missed it by a few minutes) === Summary === * new push scripts for pushing to testing, adjust mock configs to use testing -- dgilmore * finished ; thx for your work dgilmore * we need to do more stuff with the scripts to be able to push to stable easily; knurd will take a look * branch for EPEL if Fedora maintainer does not react * finished; dgilmore enhanced the text to fix something knurd complained about. The last sentence reads now: "If the Fedora maintainer later decides to participate in EPEL, then the Fedora maintainer will become co-maintainer for EPEL. (Of course co-maintainership can be extended to Fedora)" * yum for EPEL4 -- Jeff_S * "How to do it" also got finished :) -- we take the CentOS srpms as base, ship them with a lower release to do no harm to CentOS and remove the yum.conf, as yum without a RHEL4-repo can not be used to install stuff from EPEL, but is of value for stuff like yum-utils or mock * EPEL announcement happened -- are we satisfied with how everything worked out? * was discussed in the past meetings -- we'll remove it from the schedule, move on and discuss stuff as needed * RHX and EPEL -- quaid * quiad: "nothing new ; but I haven't asked in a while; forgot it could be on the agenda " * communication plan for enterprise customers/ISVs/IHVs -- stahnma, quaid * will get send to the list for final discussions * Generic Job Description -- quaid * will get send to the list for final discussions * ExcludeArch TrackerBugs for EPEL -- notting/knurd * knurd doesn't find the time for it atm; any volunteers? * FESCo mandate/how to move on with SIG and SteeringCommittee * current mandate for the EPEL SIG and its Steering Committee is limited until end of September; do we want to move on with the current scheme ? or do we want to elect a sterring committee? * some people wondered if elections really make sense * we could recommend to FESCo an extension of the mandate for e.g. 6 months * stahnma> "I think right now growth of the repo and user-base is where we should putting effort not into politics " * quaid> "we seem to have a manageable group without adding or subtracting " * mmcgrath> "I guess a specific goal would be good. I mean the obvious goal is there but do we also want to aggressively add more packages? Add more packagers? Add more documentation? Marketing? " * "more packages" is still a important goal * stahnma> "allow for hostile takeover of maintainane :) " * knurd> "maybe we need a sponsor-way for EPEL-only contributors that want to maintain existing packages " * we stopped there and will continue this topic on the list and in the next meeting * Free discussion around EPEL * mmcgrath> "just wanted to say I think the EPEL community is pretty healthy right now, lots of people and packages being built and we're still very young. " * Jeff_S_> "I'm happy to try to do most communication on the list and then just finalize things in meetings -- that way we can speed through these faster :) " * stahnma> "I liked the speed of today's meeting " === Full Log === https://www.redhat.com/archives/epel-devel-list/2007-August/msg00115.html == Stats == === General === Number of EPEL Contributors -- now that the pgkdb is in production it's for now not easily determinable (AFAIK) === EPEL 5 === Number of source packages: 590 Number of binary packages: 1146 There are 79 new Packages (might include some old packages that were moved to testing right before the EPEL announcement): * arj | Archiver for .arj files * audio-entropyd | Generate entropy from audio output * bcfg2 | Configuration management system * bugzilla | Bug tracking system * cabextract | Utility for extracting cabinet (.cab) archives * chmlib | Library for dealing with ITSS/CHM format files * evolution-bogofilter | A plugin for bogofilter support in evolution * freeze | freeze/melt/fcat compression utilities * gdal | GIS file format library * geos | GEOS is a C++ port of the Java Topology Suite * gnome-screensaver-frogs | GNOME Screensaver Slideshow of Frogs * google-perftools | Very fast malloc and performance analysis tools * guile-cairo | The Cairo graphics library for Guile Scheme * guile-lib | A repository of useful code written in Guile Scheme * JSDoc | Produces javadoc-style documentation from JavaScript sourcefiles * lasi | C++ library for creating Postscript documents * libdap | The C++ DAP2 library from OPeNDAP * libgeotiff | GeoTIFF format library * limph | A PHP5-compatible network host/service poller with web interface * lzop | Real-time file compressor * mapserver | Environment for building spatially-enabled internet applications * mfstools | Utilities for TiVo drive upgrades * moodle | A Course Management System * netgo | Networking profile manager * nikto | Web server scanner * nomarch | GPLed Arc de-archiver * ogdi | Open Geographic Datastore Interface * oneko | Cat chases the cursor * pbzip2 | Parallel implementation of bzip2 * Perlbal | Reverse-proxy load balancer and webserver * perl-Convert-TNEF | Perl module to read TNEF files * perl-Convert-UUlib | Perl interface to the uulib library * perl-Danga-Socket | Event loop and event-driven async socket base class * perl-Device-SerialPort | Linux/POSIX emulation of Win32::SerialPort functions * perl-ExtUtils-F77 | Simple interface to F77 libs * perl-Gearman-Client-Async | Asynchronous Client for the Gearman distributed job system * perl-Gearman | Distributed job system * perl-Gearman-Server | Function call "router" and load balancer * perl-Image-ExifTool | Utility for reading and writing image meta info * perl-IO-AIO | Asynchronous Input/Output * perl-libwhisker2 | Perl module geared specificly for HTTP testing * perl-Mail-SPF-Query | Query Sender Policy Framework * perl-MogileFS-Utils | Utilities for MogileFS * perl-Net-CIDR-Lite | Net::CIDR::Lite Perl module * perl-Net-Pcap | Interface to pcap(3) LBL packet capture library * perl-Razor-Agent | Use a Razor catalogue server to filter spam messages * perl-Sys-Syscall | Access system calls that Perl doesn't normally provide access to * perl-Test-Base | Data Driven Testing Framework * perltidy | Tool for indenting and reformatting Perl scripts * php-pear-PHP-CodeSniffer | PHP coding standards enforcement tool * physfs | Library to provide abstract access to various archives * plplot | Library of functions for making scientific plots * postgresql-pgpool | Pgpool is a connection pooling/replication server for PostgreSQL * proftpd | Flexible, stable and highly-configurable FTP server * proj | Cartographic projection software (PROJ.4) * pv | A tool for monitoring the progress of data through a pipeline * pychart | Python library for generating chart images * python-Coherence | Python framework to participate in digital living networks * python-iniparse | Python Module for Accessing and Modifying Configuration Data in INI files * python-lxml | ElementTree-like Python bindings for libxml2 and libxslt * python-pygments | A syntax highlighting engine written in Python * pyxdg | Python library to access freedesktop.org standards * qhull | General dimension convex hull programs * qucs | Circuit simulator * SDL_mixer | Simple DirectMedia Layer - Sample Mixer Library * ser2net | Proxy that allows tcp connections to serial ports * stripesnoop | Magnetic Stripe Reader * svgalib | Low-level fullscreen SVGA graphics library * svnmailer | Tool to post subversion repository commit information * tcpxtract | Tool for extracting files from network traffic * tidy | Utility to clean up and pretty print HTML/XHTML/XML * translate-toolkit | A collection of tools to assist software localization * udunits | A library for manipulating units of physical quantities * ustr | String library, very low memory overhead, simple to import * vpnc | IPSec VPN client compatible with Cisco equipment * xerces-c | Validating XML Parser * xkeycaps | Graphical front end to xmodmap * xsupplicant | Open Source Implementation of IEEE 802.1x * zabbix | Open-source monitoring solution for your IT infrastructure === EPEL 4 === Number of source packages: 377 Number of binary packages: 778 There are 62 new Packages (might include some old packages that were moved to testing right before the EPEL announcement): * arj | Archiver for .arj files * audio-entropyd | Generate entropy from audio output * bcfg2 | Configuration management system * bugzilla | Bug tracking system * chmlib | Library for dealing with ITSS/CHM format files * cobbler | Boot server configurator * freeze | freeze/melt/fcat compression utilities * geos | GEOS is a C++ port of the Java Topology Suite * gnome-screensaver-frogs | GNOME Screensaver Slideshow of Frogs * google-perftools | Very fast malloc and performance analysis tools * JSDoc | Produces javadoc-style documentation from JavaScript sourcefiles * libdap | The C++ DAP2 library from OPeNDAP * libgeotiff | GeoTIFF format library * limph | A PHP5-compatible network host/service poller with web interface * lzop | Real-time file compressor * mfstools | Utilities for TiVo drive upgrades * mimedefang | E-Mail filtering framework using Sendmail's Milter interface * mock | Builds packages inside chroots * mod_security | Security module for the Apache HTTP Server * moodle | A Course Management System * netgo | Networking profile manager * nikto | Web server scanner * nomarch | GPLed Arc de-archiver * oneko | Cat chases the cursor * pbzip2 | Parallel implementation of bzip2 * perl-Convert-TNEF | Perl module to read TNEF files * perl-Convert-UUlib | Perl interface to the uulib library * perl-Danga-Socket | Event loop and event-driven async socket base class * perl-Device-SerialPort | Linux/POSIX emulation of Win32::SerialPort functions * perl-ExtUtils-F77 | Simple interface to F77 libs * perl-Image-ExifTool | Utility for reading and writing image meta info * perl-IO-AIO | Asynchronous Input/Output * perl-libwhisker2 | Perl module geared specificly for HTTP testing * perl-Mail-SPF-Query | Query Sender Policy Framework * perl-Net-CIDR-Lite | Net::CIDR::Lite Perl module * perl-Net-Server | Extensible, general Perl server engine * perl-Razor-Agent | Use a Razor catalogue server to filter spam messages * perl-SOAP-Lite | Client and server side SOAP implementation * perl-Sys-Syscall | Access system calls that Perl doesn't normally provide access to * physfs | Library to provide abstract access to various archives * postgresql-dbi-link | Partial implementation of the SQL/MED portion of the SQL:2003 specification * postgresql-pgpoolAdmin | PgpoolAdmin - web-based pgpool administration * postgresql-pgpool | Pgpool is a connection pooling/replication server for PostgreSQL * proj | Cartographic projection software (PROJ.4) * pychart | Python library for generating chart images * python-Coherence | Python framework to participate in digital living networks * python-lxml | ElementTree-like Python bindings for libxml2 and libxslt * pyxdg | Python library to access freedesktop.org standards * qucs | Circuit simulator * SDL_mixer | Simple DirectMedia Layer - Sample Mixer Library * ser2net | Proxy that allows tcp connections to serial ports * specto | An desktop application that will watch configurable events * sqlgrey | Postfix grey-listing policy service * stripesnoop | Magnetic Stripe Reader * svgalib | Low-level fullscreen SVGA graphics library * trac | Enhanced wiki and issue tracking system * trac-webadmin | Web interface for administration of Trac * udunits | A library for manipulating units of physical quantities * xerces-c | Validating XML Parser * xkeycaps | Graphical front end to xmodmap * xsupplicant | Open Source Implementation of IEEE 802.1x * zabbix | Open-source monitoring solution for your IT infrastructure ---- ["CategoryEPELReports"] From tcallawa at redhat.com Sun Aug 19 13:52:20 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 19 Aug 2007 09:52:20 -0400 Subject: License of .spec files In-Reply-To: <46C7F614.2080405@fedoraproject.org> References: <46C7F614.2080405@fedoraproject.org> Message-ID: <1187531540.3439.248.camel@dhcp83-165.boston.redhat.com> On Sun, 2007-08-19 at 09:49 +0200, Marek Mahut wrote: > Hello all, > > I have a question, probably for spot, what's the license of .spec file > it-self? Is it under license of a product or indirectly signed by CLA? > Is it a good idea to include the license specification about the spec > file in the .spec file? FWIW, licensing the .spec files never made much sense to me. 1. There's very little original copyrightable work in a spec file. 2. The license of the spec file itself would have nothing to do with the contents of the RPM, other than that the spec file would also be included as a separate file inside the RPM. So, the spec file is not automatically under the same license as the bits being packaged up. 3. Is it indirectly signed by the CLA? More like directly. Since spec files would fall within your Contribution, anyone getting them from Fedora can reproduce, make derived works of, display, publicly perform ("A Tale Of Two Spec Files"), sublicense, and distribute them freely. There really is no need to sublicense the spec files, but you're permitted to do so if you're so motivated. I highly suggest that you do not, because it will confuse others. ~spot From rc040203 at freenet.de Sun Aug 19 15:21:14 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 19 Aug 2007 17:21:14 +0200 Subject: License of .spec files In-Reply-To: <1187531540.3439.248.camel@dhcp83-165.boston.redhat.com> References: <46C7F614.2080405@fedoraproject.org> <1187531540.3439.248.camel@dhcp83-165.boston.redhat.com> Message-ID: <1187536875.31667.48.camel@mccallum.corsepiu.local> On Sun, 2007-08-19 at 09:52 -0400, Tom "spot" Callaway wrote: > On Sun, 2007-08-19 at 09:49 +0200, Marek Mahut wrote: > > Hello all, > > > > I have a question, probably for spot, what's the license of .spec file > > it-self? Is it under license of a product or indirectly signed by CLA? > > Is it a good idea to include the license specification about the spec > > file in the .spec file? > > FWIW, licensing the .spec files never made much sense to me. > > 1. There's very little original copyrightable work in a spec file. > 2. The license of the spec file itself would have nothing to do with the > contents of the RPM, other than that the spec file would also be > included as a separate file inside the RPM. So, the spec file is not > automatically under the same license as the bits being packaged up. > 3. Is it indirectly signed by the CLA? More like directly. > > > You hereby grant to Red Hat, Inc., on behalf of the Project, and to > recipients of software distributed by the Project: > > 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; > > > > Since spec files would fall within your Contribution, anyone getting > them from Fedora can reproduce, make derived works of, display, publicly > perform ("A Tale Of Two Spec Files"), sublicense, and distribute them > freely. IMO, this section attempts to implement additional clauses on works having been derived from other party's GPL'ed works - I therefore think the CLA is incompatible to and non-applicable to GPL/LGPL'ed packages. Other major linux distributions acknowledge this fact and add # This file and all modifications and additions to the pristine # package are under the same license as the package itself. to their specs. I do the same for all spec files containing major (likely copyrightable) works and major patches. From fedora at leemhuis.info Sun Aug 19 16:00:04 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 19 Aug 2007 18:00:04 +0200 Subject: License of .spec files In-Reply-To: <1187531540.3439.248.camel@dhcp83-165.boston.redhat.com> References: <46C7F614.2080405@fedoraproject.org> <1187531540.3439.248.camel@dhcp83-165.boston.redhat.com> Message-ID: <46C86904.2090301@leemhuis.info> On 19.08.2007 15:52, Tom "spot" Callaway wrote: > On Sun, 2007-08-19 at 09:49 +0200, Marek Mahut wrote: >> Hello all, >> >> I have a question, probably for spot, what's the license of .spec file >> it-self? Is it under license of a product or indirectly signed by CLA? >> Is it a good idea to include the license specification about the spec >> file in the .spec file? > > FWIW, licensing the .spec files never made much sense to me. > > 1. There's very little original copyrightable work in a spec file. Well, some spec files can be quite complex. More complex than some small scripts that come with a copyright notice that often is longer than the script-part itself. > 2. The license of the spec file itself would have nothing to do with the > contents of the RPM, other than that the spec file would also be > included as a separate file inside the RPM. So, the spec file is not > automatically under the same license as the bits being packaged up. +1 -- I'd say if we license them then the maintainer or Fedora as a whole should pick a license for their spec files. > 3. Is it indirectly signed by the CLA? More like directly.[...] Maybe, but that's not obvious to outside parties. Let's say a outside 3rd party that maintains a public rpm-repo wants to pick up a Fedora package and its spec file for its repo. Then that 3rd party repo wants to be sure that Fedora doesn't sue them today or in the future for taking Fedora's spec file. Explicitly licensing our spec files would make would solve this problem -- currently it's more a grey area. IOW: I think putting a short license text in the spec files (e.g. this is "Public Domain" or "licensed as WTFPL" ) would be a good idea. CU knurd From packages at amiga-hardware.com Sun Aug 19 16:06:58 2007 From: packages at amiga-hardware.com (Ian Chapman) Date: Sun, 19 Aug 2007 17:06:58 +0100 Subject: openmsx & cbios Message-ID: <46C86AA2.6060208@amiga-hardware.com> Hi, With glew now being allowed in Fedora, thanks to the efforts of Hans, would OpenMSX in combination with CBIOS be suitable for entry? OpenMSX is GPL and IIRC cbios is BSD. Cbios is a third party BIOS so you don't need to obtain a BIOS from a real MSX. http://openmsx.sourceforge.net/ http://cbios.sourceforge.net/ -- Ian Chapman. From mmahut at fedoraproject.org Sun Aug 19 16:24:03 2007 From: mmahut at fedoraproject.org (Marek Mahut) Date: Sun, 19 Aug 2007 18:24:03 +0200 Subject: License of .spec files In-Reply-To: <46C86904.2090301@leemhuis.info> References: <46C7F614.2080405@fedoraproject.org> <1187531540.3439.248.camel@dhcp83-165.boston.redhat.com> <46C86904.2090301@leemhuis.info> Message-ID: <46C86EA3.1030202@fedoraproject.org> Thorsten Leemhuis wrote: > On 19.08.2007 15:52, Tom "spot" Callaway wrote: >> On Sun, 2007-08-19 at 09:49 +0200, Marek Mahut wrote: >>> Hello all, >>> >>> I have a question, probably for spot, what's the license of .spec file >>> it-self? Is it under license of a product or indirectly signed by CLA? >>> Is it a good idea to include the license specification about the spec >>> file in the .spec file? >> FWIW, licensing the .spec files never made much sense to me. >> >> 1. There's very little original copyrightable work in a spec file. > > Well, some spec files can be quite complex. More complex than some small > scripts that come with a copyright notice that often is longer than the > script-part itself. > >> 2. The license of the spec file itself would have nothing to do with the >> contents of the RPM, other than that the spec file would also be >> included as a separate file inside the RPM. So, the spec file is not >> automatically under the same license as the bits being packaged up. > > +1 -- I'd say if we license them then the maintainer or Fedora as a > whole should pick a license for their spec files. > >> 3. Is it indirectly signed by the CLA? More like directly.[...] > > Maybe, but that's not obvious to outside parties. Let's say a outside > 3rd party that maintains a public rpm-repo wants to pick up a Fedora > package and its spec file for its repo. Then that 3rd party repo wants > to be sure that Fedora doesn't sue them today or in the future for > taking Fedora's spec file. Explicitly licensing our spec files would > make would solve this problem -- currently it's more a grey area. > > IOW: I think putting a short license text in the spec files (e.g. this > is "Public Domain" or "licensed as WTFPL" ) would be a good idea. And what happens when I want to import (modified) spec file from other project (upstream) licensed under GPLv2 for example? > CU > knurd -- Marek Mahut http://www.fedoraproject.org/ Fedora Project http://www.jamendo.com/ From rc040203 at freenet.de Sun Aug 19 16:35:06 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 19 Aug 2007 18:35:06 +0200 Subject: License of .spec files In-Reply-To: <46C86EA3.1030202@fedoraproject.org> References: <46C7F614.2080405@fedoraproject.org> <1187531540.3439.248.camel@dhcp83-165.boston.redhat.com> <46C86904.2090301@leemhuis.info> <46C86EA3.1030202@fedoraproject.org> Message-ID: <1187541306.31667.54.camel@mccallum.corsepiu.local> On Sun, 2007-08-19 at 18:24 +0200, Marek Mahut wrote: > Thorsten Leemhuis wrote: > > On 19.08.2007 15:52, Tom "spot" Callaway wrote: > > IOW: I think putting a short license text in the spec files (e.g. this > > is "Public Domain" or "licensed as WTFPL" ) would be a good idea. > > And what happens when I want to import (modified) spec file from other > project (upstream) licensed under GPLv2 for example? This spec clearly is a derived work. As such your spec file will have to have GPLv2 compatible license. Ralf From tibbs at math.uh.edu Sun Aug 19 16:40:44 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 19 Aug 2007 11:40:44 -0500 Subject: License of .spec files In-Reply-To: <1187531540.3439.248.camel@dhcp83-165.boston.redhat.com> References: <46C7F614.2080405@fedoraproject.org> <1187531540.3439.248.camel@dhcp83-165.boston.redhat.com> Message-ID: >>>>> "TC" == Tom \"spot\" Callaway writes: TC> FWIW, licensing the .spec files never made much sense to me. You might want to take a look at all of these crazy Java packages that start with long license boilerplate. When I see that I just move on and look for another package to review. - J< From ville.skytta at iki.fi Sun Aug 19 16:45:59 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sun, 19 Aug 2007 19:45:59 +0300 Subject: License of .spec files In-Reply-To: <1187541306.31667.54.camel@mccallum.corsepiu.local> References: <46C7F614.2080405@fedoraproject.org> <46C86EA3.1030202@fedoraproject.org> <1187541306.31667.54.camel@mccallum.corsepiu.local> Message-ID: <200708191945.59841.ville.skytta@iki.fi> On Sunday 19 August 2007, Ralf Corsepius wrote: > This spec clearly is a derived work. As such your spec file will have to > have GPLv2 compatible license. I think JPackage's approach to this is a pretty sensible one: http://www.jpackage.org/jpplicense.php From fedora at leemhuis.info Sun Aug 19 16:49:38 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 19 Aug 2007 18:49:38 +0200 Subject: License of .spec files In-Reply-To: <1187541306.31667.54.camel@mccallum.corsepiu.local> References: <46C7F614.2080405@fedoraproject.org> <1187531540.3439.248.camel@dhcp83-165.boston.redhat.com> <46C86904.2090301@leemhuis.info> <46C86EA3.1030202@fedoraproject.org> <1187541306.31667.54.camel@mccallum.corsepiu.local> Message-ID: <46C874A2.2090803@leemhuis.info> On 19.08.2007 18:35, Ralf Corsepius wrote: > On Sun, 2007-08-19 at 18:24 +0200, Marek Mahut wrote: >> Thorsten Leemhuis wrote: >>> On 19.08.2007 15:52, Tom "spot" Callaway wrote: > >>> IOW: I think putting a short license text in the spec files (e.g. this >>> is "Public Domain" or "licensed as WTFPL" ) would be a good idea. >> And what happens when I want to import (modified) spec file from other >> project (upstream) licensed under GPLv2 for example? Is that different from the situation we have today already? See below. > This spec clearly is a derived work. As such your spec file will have to > have GPLv2 compatible license. Assuming that's right (?) then you likely should not take parts of a GPLed spec file even today afaics, as by the CLA you grand Red Hat/the Fedora Project rights on the stuff you submit, which you can't, if the stuff you commit is not yours. Or am I missing something here? CU knurd (?) -- I'm not a licensing expert, but that might depend on the fact if the part you take is copyrightable or if it's just trivial and not protectable (?) You hereby grant to Red Hat, Inc., on behalf of the Project, and to recipients of software distributed by the Project: 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; From roland at redhat.com Sun Aug 19 22:13:50 2007 From: roland at redhat.com (Roland McGrath) Date: Sun, 19 Aug 2007 15:13:50 -0700 (PDT) Subject: bodhi always closes bugs? Message-ID: <20070819221350.EC45D4D058F@magilla.localdomain> Does bodhi always automatically close the bugzilla bugs whose #s you list in the update? The old updates system (for FC-6) has a checkbox for this. This seems like a bad thing. I like to list the related #s, while a) sometimes giving reporters a chance to verify before closing them and b) listing some that were reported against fc6 or devel in the f7 update and vice versa. This is for updates where devel, F-, and F- are all getting the same rpm modulo %dist at the same time. It's anal overkill to clone each bug for each other version, and I'm not going to do it. It's just unfriendly to the users to omit the bug # from the update just because it's a bug only reported for a different Fedora release, so I don't want to do that either. It's not the end of the world for fc6 and devel bugs to get closed by a robot saying "this here F-7 update fixed it", but it's not really what I as the maintainer this robot serves want it doing in my name. I didn't file this at https://hosted.fedoraproject.org/projects/bodhi/newticket because "TICKET_CREATE privileges are required to perform this operation". Thanks, Roland From Axel.Thimm at ATrpms.net Sun Aug 19 23:01:33 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 20 Aug 2007 01:01:33 +0200 Subject: License of .spec files In-Reply-To: <1187541306.31667.54.camel@mccallum.corsepiu.local> References: <46C7F614.2080405@fedoraproject.org> <1187531540.3439.248.camel@dhcp83-165.boston.redhat.com> <46C86904.2090301@leemhuis.info> <46C86EA3.1030202@fedoraproject.org> <1187541306.31667.54.camel@mccallum.corsepiu.local> Message-ID: <20070819230133.GB29990@puariko.nirvana> On Sun, Aug 19, 2007 at 06:35:06PM +0200, Ralf Corsepius wrote: > On Sun, 2007-08-19 at 18:24 +0200, Marek Mahut wrote: > > Thorsten Leemhuis wrote: > > > On 19.08.2007 15:52, Tom "spot" Callaway wrote: > > > > IOW: I think putting a short license text in the spec files (e.g. this > > > is "Public Domain" or "licensed as WTFPL" ) would be a good idea. > > > > And what happens when I want to import (modified) spec file from other > > project (upstream) licensed under GPLv2 for example? > This spec clearly is a derived work. As such your spec file will have to > have GPLv2 compatible license. Well, not only compatible, but it will have to be GPLv2 itself. E.g. you can't take a specfile from a GPL project and license the derived specfile under the compatible BSD license. -- 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 peter at thecodergeek.com Sun Aug 19 23:11:13 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Sun, 19 Aug 2007 16:11:13 -0700 Subject: bodhi always closes bugs? In-Reply-To: <20070819221350.EC45D4D058F@magilla.localdomain> References: <20070819221350.EC45D4D058F@magilla.localdomain> Message-ID: <1187565073.12353.1.camel@tuxhugs> El dom, 19-08-2007 a las 15:13 -0700, Roland McGrath escribi?: > I didn't file this at https://hosted.fedoraproject.org/projects/bodhi/newticket > because "TICKET_CREATE privileges are required to perform this operation". You need to click the Login link near the top right-hand corner of the page, then enter your FAS username/password. That worked for me. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Esta parte del mensaje est? firmada digitalmente URL: From wart at kobold.org Mon Aug 20 00:47:17 2007 From: wart at kobold.org (Wart) Date: Sun, 19 Aug 2007 17:47:17 -0700 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> Message-ID: <46C8E495.1020407@kobold.org> Tom "spot" Callaway wrote: > Got your attention? Good. > > GPL and LGPL are NOT acceptable License tags for Fedora. You cannot > simply use "GPL" or "LGPL" as a license tag anymore. > > You have to use one of the following tags: [...] I hope this is the right forum to ask questions to help clarify which license to use for various packages. If not, then please direct me to the correct forum. Many files in the iwidgets package use the following: # Permission is hereby granted, without written agreement and without # license or royalty fees, to use, copy, modify, and distribute this # software and its documentation for any purpose, provided that the # above copyright notice and the following two paragraphs appear in # all copies of this software. This seems to be basically the MIT license, but with some minor rephrasing. Before I start tagging the package as 'MIT and ...', I'd like to verify that I can use 'MIT' here. --Wart From jkeating at redhat.com Mon Aug 20 02:15:25 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 19 Aug 2007 22:15:25 -0400 Subject: bodhi always closes bugs? In-Reply-To: <20070819221350.EC45D4D058F@magilla.localdomain> References: <20070819221350.EC45D4D058F@magilla.localdomain> Message-ID: <20070819221525.3c12562e@ender> On Sun, 19 Aug 2007 15:13:50 -0700 (PDT) Roland McGrath wrote: > This seems like a bad thing. I like to list the related #s, while a) > sometimes giving reporters a chance to verify before closing them Isn't that what updates-testing is for? -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Mon Aug 20 03:46:45 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 19 Aug 2007 23:46:45 -0400 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <46C8E495.1020407@kobold.org> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <46C8E495.1020407@kobold.org> Message-ID: <1187581605.3439.252.camel@dhcp83-165.boston.redhat.com> On Sun, 2007-08-19 at 17:47 -0700, Wart wrote: > Tom "spot" Callaway wrote: > > Got your attention? Good. > > > > GPL and LGPL are NOT acceptable License tags for Fedora. You cannot > > simply use "GPL" or "LGPL" as a license tag anymore. > > > > You have to use one of the following tags: > [...] > > I hope this is the right forum to ask questions to help clarify which > license to use for various packages. If not, then please direct me to > the correct forum. > > Many files in the iwidgets package use the following: > > # Permission is hereby granted, without written agreement and without > # license or royalty fees, to use, copy, modify, and distribute this > # software and its documentation for any purpose, provided that the > # above copyright notice and the following two paragraphs appear in > # all copies of this software. > > This seems to be basically the MIT license, but with some minor > rephrasing. Before I start tagging the package as 'MIT and ...', I'd > like to verify that I can use 'MIT' here. Without seeing the whole text of the license, I can't be sure, but that beginning part sounds very much like MIT. Please send me a copy of the full license text, and I'll let you know for sure. ~spot From wart at kobold.org Mon Aug 20 04:26:16 2007 From: wart at kobold.org (Wart) Date: Sun, 19 Aug 2007 21:26:16 -0700 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <1187581605.3439.252.camel@dhcp83-165.boston.redhat.com> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <46C8E495.1020407@kobold.org> <1187581605.3439.252.camel@dhcp83-165.boston.redhat.com> Message-ID: <46C917E8.1070706@kobold.org> Tom "spot" Callaway wrote: > On Sun, 2007-08-19 at 17:47 -0700, Wart wrote: >> Tom "spot" Callaway wrote: >>> Got your attention? Good. >>> >>> GPL and LGPL are NOT acceptable License tags for Fedora. You cannot >>> simply use "GPL" or "LGPL" as a license tag anymore. >>> >>> You have to use one of the following tags: >> [...] >> >> I hope this is the right forum to ask questions to help clarify which >> license to use for various packages. If not, then please direct me to >> the correct forum. >> >> Many files in the iwidgets package use the following: >> >> # Permission is hereby granted, without written agreement and without >> # license or royalty fees, to use, copy, modify, and distribute this >> # software and its documentation for any purpose, provided that the >> # above copyright notice and the following two paragraphs appear in >> # all copies of this software. >> >> This seems to be basically the MIT license, but with some minor >> rephrasing. Before I start tagging the package as 'MIT and ...', I'd >> like to verify that I can use 'MIT' here. > > Without seeing the whole text of the license, I can't be sure, but that > beginning part sounds very much like MIT. > > Please send me a copy of the full license text, and I'll let you know > for sure. Here is the full text of the license from one of the source files: # ---------------------------------------------------------------------- # Copyright (c) 1995 Mark L. Ulferts # ====================================================================== # Permission is hereby granted, without written agreement and without # license or royalty fees, to use, copy, modify, and distribute this # software and its documentation for any purpose, provided that the # above copyright notice and the following two paragraphs appear in # all copies of this software. # # IN NO EVENT SHALL THE COPYRIGHT HOLDER BE LIABLE TO ANY PARTY FOR # DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES # ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN # IF THE COPYRIGHT HOLDER HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH # DAMAGE. # # THE COPYRIGHT HOLDER SPECIFICALLY DISCLAIMS ANY WARRANTIES, INCLUDING, # BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND # FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS # ON AN "AS IS" BASIS, AND THE COPYRIGHT HOLDER HAS NO OBLIGATION TO # PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS. Some of the files also reference 'license.terms', which reads almost the same and is attached. Thanks, --Wart -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: license.terms URL: From roland at redhat.com Mon Aug 20 04:38:53 2007 From: roland at redhat.com (Roland McGrath) Date: Sun, 19 Aug 2007 21:38:53 -0700 (PDT) Subject: bodhi always closes bugs? In-Reply-To: Jesse Keating's message of Sunday, 19 August 2007 22:15:25 -0400 <20070819221525.3c12562e@ender> Message-ID: <20070820043853.B2F3E4D058F@magilla.localdomain> > On Sun, 19 Aug 2007 15:13:50 -0700 (PDT) > Roland McGrath wrote: > > > This seems like a bad thing. I like to list the related #s, while a) > > sometimes giving reporters a chance to verify before closing them > > Isn't that what updates-testing is for? You didn't respond to b). From sundaram at fedoraproject.org Mon Aug 20 07:51:19 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 20 Aug 2007 13:21:19 +0530 Subject: License of .spec files In-Reply-To: <1187536875.31667.48.camel@mccallum.corsepiu.local> References: <46C7F614.2080405@fedoraproject.org> <1187531540.3439.248.camel@dhcp83-165.boston.redhat.com> <1187536875.31667.48.camel@mccallum.corsepiu.local> Message-ID: <46C947F7.6000800@fedoraproject.org> Ralf Corsepius wrote: > IMO, this section attempts to implement additional clauses on works > having been derived from other party's GPL'ed works - I therefore think > the CLA is incompatible to and non-applicable to GPL/LGPL'ed packages. The CLA is only applicable to original work. Rahul From lmacken at redhat.com Mon Aug 20 08:15:31 2007 From: lmacken at redhat.com (Luke Macken) Date: Mon, 20 Aug 2007 04:15:31 -0400 Subject: bodhi always closes bugs? In-Reply-To: <20070819221350.EC45D4D058F@magilla.localdomain> References: <20070819221350.EC45D4D058F@magilla.localdomain> Message-ID: <20070820081531.GA28008@crow> On Sun, Aug 19, 2007 at 03:13:50PM -0700, Roland McGrath wrote: > Does bodhi always automatically close the bugzilla bugs whose #s you list > in the update? The old updates system (for FC-6) has a checkbox for this. Bodhi now has this checkbox as well[0]. I will be updating the production instance hopefully this week. > This seems like a bad thing. I like to list the related #s, while a) > sometimes giving reporters a chance to verify before closing them and b) > listing some that were reported against fc6 or devel in the f7 update and > vice versa. This is for updates where devel, F-, and F- are all > getting the same rpm modulo %dist at the same time. It's anal overkill to > clone each bug for each other version, and I'm not going to do it. It's > just unfriendly to the users to omit the bug # from the update just because > it's a bug only reported for a different Fedora release, so I don't want to > do that either. It's not the end of the world for fc6 and devel bugs to > get closed by a robot saying "this here F-7 update fixed it", but it's not > really what I as the maintainer this robot serves want it doing in my name. Agreed. So, right now in the current production instance, bodhi comments on bugs when an update is pushed to updates-testing. When it is moved to Stable, then it will close them all. As I mentioned above, this will be completely optional soon. > I didn't file this at https://hosted.fedoraproject.org/projects/bodhi/newticket > because "TICKET_CREATE privileges are required to perform this operation". Did you login first ? luke [0]: https://hosted.fedoraproject.org/projects/bodhi/attachment/wiki/Screenshots/bodhi-new.png From dwmw2 at infradead.org Mon Aug 20 08:35:00 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 20 Aug 2007 09:35:00 +0100 Subject: The open() system call in f8 really broken... In-Reply-To: <20070816221953.GA12881@devserv.devel.redhat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4BF3A.6040702@redhat.com> <20070816212632.GM2063@devserv.devel.redhat.com> <20070816221953.GA12881@devserv.devel.redhat.com> Message-ID: <1187598900.3137.16.camel@shinybook.infradead.org> On Thu, 2007-08-16 at 18:19 -0400, Alan Cox wrote: > On Thu, Aug 16, 2007 at 05:26:32PM -0400, Jakub Jelinek wrote: > > In this case you are not calling open(1), but some function pointer. > > And therefore it is undesirable to let it be expanded as function-like > > macro (which POSIX allows). > > The right fix is to use one of: > > Gak... > > Can we go back to C as used in the real world please Out of interest, why isn't it sufficient to just make _compilation_ fail for offending programs. Why do we have to do it at runtime? -- dwmw2 From jakub at redhat.com Mon Aug 20 08:40:49 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Mon, 20 Aug 2007 04:40:49 -0400 Subject: The open() system call in f8 really broken... In-Reply-To: <1187598900.3137.16.camel@shinybook.infradead.org> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4BF3A.6040702@redhat.com> <20070816212632.GM2063@devserv.devel.redhat.com> <20070816221953.GA12881@devserv.devel.redhat.com> <1187598900.3137.16.camel@shinybook.infradead.org> Message-ID: <20070820084049.GU2063@devserv.devel.redhat.com> On Mon, Aug 20, 2007 at 09:35:00AM +0100, David Woodhouse wrote: > On Thu, 2007-08-16 at 18:19 -0400, Alan Cox wrote: > > On Thu, Aug 16, 2007 at 05:26:32PM -0400, Jakub Jelinek wrote: > > > In this case you are not calling open(1), but some function pointer. > > > And therefore it is undesirable to let it be expanded as function-like > > > macro (which POSIX allows). > > > The right fix is to use one of: > > > > Gak... > > > > Can we go back to C as used in the real world please > > Out of interest, why isn't it sufficient to just make _compilation_ fail > for offending programs. Why do we have to do it at runtime? Cases like int foo (int flags) { return open ("/tmp/foobar", flags); } ... foo (O_CREAT | O_RDWR); are not detectable at compile time. The non-constant flags for open is orders of magnitude less common and after the mass rebuild we can investigate all the places in the distro which call __open_2 etc. Jakub From rc040203 at freenet.de Mon Aug 20 09:14:15 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 20 Aug 2007 11:14:15 +0200 Subject: License of .spec files In-Reply-To: <46C947F7.6000800@fedoraproject.org> References: <46C7F614.2080405@fedoraproject.org> <1187531540.3439.248.camel@dhcp83-165.boston.redhat.com> <1187536875.31667.48.camel@mccallum.corsepiu.local> <46C947F7.6000800@fedoraproject.org> Message-ID: <1187601255.31667.62.camel@mccallum.corsepiu.local> On Mon, 2007-08-20 at 13:21 +0530, Rahul Sundaram wrote: > Ralf Corsepius wrote: > > > IMO, this section attempts to implement additional clauses on works > > having been derived from other party's GPL'ed works - I therefore think > > the CLA is incompatible to and non-applicable to GPL/LGPL'ed packages. > > The CLA is only applicable to original work. In many cases, spec files are original works of a package maintainer. In most cases, spec files modify the original works of an upstream. In all cases, spec files are recipes to produce derivative works (binary rpm, src.rpm) from an "upstream source". => In case of GPL'ed sources you can not apply the CLA. => The CLA endangers package maintainers by shifting them onto muddy ground. From sundaram at fedoraproject.org Mon Aug 20 09:17:19 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 20 Aug 2007 14:47:19 +0530 Subject: License of .spec files In-Reply-To: <1187601255.31667.62.camel@mccallum.corsepiu.local> References: <46C7F614.2080405@fedoraproject.org> <1187531540.3439.248.camel@dhcp83-165.boston.redhat.com> <1187536875.31667.48.camel@mccallum.corsepiu.local> <46C947F7.6000800@fedoraproject.org> <1187601255.31667.62.camel@mccallum.corsepiu.local> Message-ID: <46C95C1F.2060607@fedoraproject.org> Ralf Corsepius wrote: > > => In case of GPL'ed sources you can not apply the CLA. > => The CLA endangers package maintainers by shifting them onto muddy > ground. Can you explain in detail how? If it's not applicable in certain instances how does it muddy anything? Rahul From tcallawa at redhat.com Mon Aug 20 12:34:41 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 20 Aug 2007 08:34:41 -0400 Subject: GPL and LGPL not acceptable for Fedora! In-Reply-To: <46C917E8.1070706@kobold.org> References: <1187233295.3439.86.camel@dhcp83-165.boston.redhat.com> <46C8E495.1020407@kobold.org> <1187581605.3439.252.camel@dhcp83-165.boston.redhat.com> <46C917E8.1070706@kobold.org> Message-ID: <1187613282.3439.273.camel@dhcp83-165.boston.redhat.com> On Sun, 2007-08-19 at 21:26 -0700, Wart wrote: > >> This seems to be basically the MIT license, but with some minor > >> rephrasing. Before I start tagging the package as 'MIT and ...', I'd > >> like to verify that I can use 'MIT' here. Both of these are MIT. I'm adding them to the Licensing/MIT list. ~spot From dcantrell at redhat.com Mon Aug 20 13:57:34 2007 From: dcantrell at redhat.com (David Cantrell) Date: Mon, 20 Aug 2007 09:57:34 -0400 Subject: License of .spec files In-Reply-To: <1187531540.3439.248.camel@dhcp83-165.boston.redhat.com> References: <46C7F614.2080405@fedoraproject.org> <1187531540.3439.248.camel@dhcp83-165.boston.redhat.com> Message-ID: <20070820095734.1d1d1d94.dcantrell@redhat.com> On Sun, 19 Aug 2007 09:52:20 -0400 "Tom \"spot\" Callaway" wrote: > On Sun, 2007-08-19 at 09:49 +0200, Marek Mahut wrote: > > Hello all, > > > > I have a question, probably for spot, what's the license of .spec file > > it-self? Is it under license of a product or indirectly signed by CLA? > > Is it a good idea to include the license specification about the spec > > file in the .spec file? > > FWIW, licensing the .spec files never made much sense to me. > > 1. There's very little original copyrightable work in a spec file. > 2. The license of the spec file itself would have nothing to do with the > contents of the RPM, other than that the spec file would also be > included as a separate file inside the RPM. So, the spec file is not > automatically under the same license as the bits being packaged up. But I think it does. In GPLv2, there was always this paragraph: "The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable." The 'plus the scripts used to control compilation and installation of the executable' meant what you, the packager, used to create the executable you are delivering to the recipient. The FSF has certainly looked the other way with this clause and I'm not sure [that I even care] what the GPLv3 says about this. Many commercial vendors ship tarballs+patches and claim the 'scripts used to control compilation of the exectuable' are the Makefile templates and configure scripts. Sure, I guess, but what did _you_ run to get the executable you are delivering to me. A spec file definitely delivers more information about how we constructed the package we are handing the customer, which in my opinion is actually how you should comply with the terms of the GPLv2. > There really is no need to sublicense the spec files, but you're > permitted to do so if you're so motivated. I highly suggest that you do > not, because it will confuse others. I think it should be consider part of the complete source code for GPL projects. That aside, the spec files _are_ the instructions for the distribution, if not intertwined and confusing. But they document what we do to construct the distribution. Should that collection of knowledge not be licensed? -- David Cantrell Red Hat / Westford, MA -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Mon Aug 20 14:11:53 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 20 Aug 2007 10:11:53 -0400 Subject: License of .spec files In-Reply-To: <20070820095734.1d1d1d94.dcantrell@redhat.com> References: <46C7F614.2080405@fedoraproject.org> <1187531540.3439.248.camel@dhcp83-165.boston.redhat.com> <20070820095734.1d1d1d94.dcantrell@redhat.com> Message-ID: <1187619114.3439.281.camel@dhcp83-165.boston.redhat.com> On Mon, 2007-08-20 at 09:57 -0400, David Cantrell wrote: > I think it should be consider part of the complete source code for GPL projects. > That aside, the spec files _are_ the instructions for the distribution, if not > intertwined and confusing. But they document what we do to construct the > distribution. Should that collection of knowledge not be licensed? My argument is that the CLA covers the licensing of original works in Fedora by CLA signers. However, since the CLA permits sublicensing, you could easily say that your spec files are under the GPL. As long as the license that you choose for your spec file doesn't limit the rights granted by the CLA, you're fine. ~spot From dcbw at redhat.com Mon Aug 20 14:18:55 2007 From: dcbw at redhat.com (Dan Williams) Date: Mon, 20 Aug 2007 10:18:55 -0400 Subject: build fails without reason, bug in plague? In-Reply-To: <46C78820.2040406@redhat.com> References: <46C6B59F.3070200@fedoraproject.org> <46C78820.2040406@redhat.com> Message-ID: <1187619535.31150.13.camel@xo-13-A4-25.localdomain> On Sat, 2007-08-18 at 19:00 -0500, Mike McGrath wrote: > Marek Mahut wrote: > > Hello maintainers, > > > > Today, I received an error that my build failed, but after deep look on > > logs I found that there was no real reason why this build failed [1]. > > Adel Gadllah told me that it isn't the first time it happens. > > > > Thoughts? > > > > [1] > > http://buildsys.fedoraproject.org/logs/fedora-4-epel/35730-cvsweb-3.0.5-2.el4/noarch/ > > > > > > Please add any of these you find to the following ticket. > > https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/125 The error comes from the _watch_mock() function in builder.py on the builders; if somebody could add some logging to the plauge-builder RPM and then deploy it, that would help: def _watch_mock(self, good_exit, bad_exit): (aux_pid, status) = os.waitpid(self._childpid, os.WNOHANG) status = os.WEXITSTATUS(status) if aux_pid: + self._log("_watch_mock(): PID %d exit status %d\n" % (self._childpid, status)) self._childpid = 0 if status == 0: self._done_status = good_exit elif status > 0: self._done_status = bad_exit self._copy_mock_output_to_log() self._start_cleanup() Dan > -Mike > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers From mmcgrath at redhat.com Mon Aug 20 15:10:57 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 20 Aug 2007 10:10:57 -0500 Subject: build fails without reason, bug in plague? In-Reply-To: <1187619535.31150.13.camel@xo-13-A4-25.localdomain> References: <46C6B59F.3070200@fedoraproject.org> <46C78820.2040406@redhat.com> <1187619535.31150.13.camel@xo-13-A4-25.localdomain> Message-ID: <46C9AF01.3090804@redhat.com> Dan Williams wrote: > On Sat, 2007-08-18 at 19:00 -0500, Mike McGrath wrote: > >> Marek Mahut wrote: >> >>> Hello maintainers, >>> >>> Today, I received an error that my build failed, but after deep look on >>> logs I found that there was no real reason why this build failed [1]. >>> Adel Gadllah told me that it isn't the first time it happens. >>> >>> Thoughts? >>> >>> [1] >>> http://buildsys.fedoraproject.org/logs/fedora-4-epel/35730-cvsweb-3.0.5-2.el4/noarch/ >>> >>> >>> >> Please add any of these you find to the following ticket. >> >> https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/125 >> > > The error comes from the _watch_mock() function in builder.py on the > builders; if somebody could add some logging to the plauge-builder RPM > and then deploy it, that would help: > > def _watch_mock(self, good_exit, bad_exit): > (aux_pid, status) = os.waitpid(self._childpid, os.WNOHANG) > status = os.WEXITSTATUS(status) > if aux_pid: > + self._log("_watch_mock(): PID %d exit status %d\n" % (self._childpid, status)) > self._childpid = 0 > if status == 0: > self._done_status = good_exit > elif status > 0: > self._done_status = bad_exit > > self._copy_mock_output_to_log() > self._start_cleanup() > > Dan > > > Thanks dan, I've added this to the builders and it appears to be working. All people with this failed sucess please resubmit and let us know how it goes. http://buildsys.fedoraproject.org/logs/fedora-5-epel/35767-nagios-2.9-1.el5/i386/job.log <-- working example. -Mike From bugs.michael at gmx.net Mon Aug 20 15:26:55 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 20 Aug 2007 17:26:55 +0200 Subject: build fails without reason, bug in plague? In-Reply-To: <46C9AF01.3090804@redhat.com> References: <46C6B59F.3070200@fedoraproject.org> <46C78820.2040406@redhat.com> <1187619535.31150.13.camel@xo-13-A4-25.localdomain> <46C9AF01.3090804@redhat.com> Message-ID: <20070820172655.c985e9e4.bugs.michael@gmx.net> On Mon, 20 Aug 2007 10:10:57 -0500, Mike McGrath wrote: > Dan Williams wrote: > > On Sat, 2007-08-18 at 19:00 -0500, Mike McGrath wrote: > > > >> Marek Mahut wrote: > >> > >>> Hello maintainers, > >>> > >>> Today, I received an error that my build failed, but after deep look on > >>> logs I found that there was no real reason why this build failed [1]. > >>> Adel Gadllah told me that it isn't the first time it happens. > >>> > >>> Thoughts? > >>> > >>> [1] > >>> http://buildsys.fedoraproject.org/logs/fedora-4-epel/35730-cvsweb-3.0.5-2.el4/noarch/ > >>> > >>> > >>> > >> Please add any of these you find to the following ticket. > >> > >> https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/125 > >> > > > > The error comes from the _watch_mock() function in builder.py on the > > builders; if somebody could add some logging to the plauge-builder RPM > > and then deploy it, that would help: > > > > def _watch_mock(self, good_exit, bad_exit): > > (aux_pid, status) = os.waitpid(self._childpid, os.WNOHANG) > > status = os.WEXITSTATUS(status) > > if aux_pid: > > + self._log("_watch_mock(): PID %d exit status %d\n" % (self._childpid, status)) > > self._childpid = 0 > > if status == 0: > > self._done_status = good_exit > > elif status > 0: > > self._done_status = bad_exit > > > > self._copy_mock_output_to_log() > > self._start_cleanup() > > > > Dan > > > > > > > Thanks dan, I've added this to the builders and it appears to be > working. All people with this failed sucess please resubmit and let us > know how it goes. > > http://buildsys.fedoraproject.org/logs/fedora-5-epel/35767-nagios-2.9-1.el5/i386/job.log > <-- working example. Hmmm... the one added line cannot fix anything. It just adds a log message. From mmcgrath at redhat.com Mon Aug 20 15:28:24 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 20 Aug 2007 10:28:24 -0500 Subject: build fails without reason, bug in plague? In-Reply-To: <20070820172655.c985e9e4.bugs.michael@gmx.net> References: <46C6B59F.3070200@fedoraproject.org> <46C78820.2040406@redhat.com> <1187619535.31150.13.camel@xo-13-A4-25.localdomain> <46C9AF01.3090804@redhat.com> <20070820172655.c985e9e4.bugs.michael@gmx.net> Message-ID: <46C9B318.5000401@redhat.com> Michael Schwendt wrote: > On Mon, 20 Aug 2007 10:10:57 -0500, Mike McGrath wrote: > > >> Dan Williams wrote: >> >>> On Sat, 2007-08-18 at 19:00 -0500, Mike McGrath wrote: >>> >>> >>>> Marek Mahut wrote: >>>> >>>> >>>>> Hello maintainers, >>>>> >>>>> Today, I received an error that my build failed, but after deep look on >>>>> logs I found that there was no real reason why this build failed [1]. >>>>> Adel Gadllah told me that it isn't the first time it happens. >>>>> >>>>> Thoughts? >>>>> >>>>> [1] >>>>> http://buildsys.fedoraproject.org/logs/fedora-4-epel/35730-cvsweb-3.0.5-2.el4/noarch/ >>>>> >>>>> >>>>> >>>>> >>>> Please add any of these you find to the following ticket. >>>> >>>> https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/125 >>>> >>>> >>> The error comes from the _watch_mock() function in builder.py on the >>> builders; if somebody could add some logging to the plauge-builder RPM >>> and then deploy it, that would help: >>> >>> def _watch_mock(self, good_exit, bad_exit): >>> (aux_pid, status) = os.waitpid(self._childpid, os.WNOHANG) >>> status = os.WEXITSTATUS(status) >>> if aux_pid: >>> + self._log("_watch_mock(): PID %d exit status %d\n" % (self._childpid, status)) >>> self._childpid = 0 >>> if status == 0: >>> self._done_status = good_exit >>> elif status > 0: >>> self._done_status = bad_exit >>> >>> self._copy_mock_output_to_log() >>> self._start_cleanup() >>> >>> Dan >>> >>> >>> >>> >> Thanks dan, I've added this to the builders and it appears to be >> working. All people with this failed sucess please resubmit and let us >> know how it goes. >> >> http://buildsys.fedoraproject.org/logs/fedora-5-epel/35767-nagios-2.9-1.el5/i386/job.log >> <-- working example. >> > > Hmmm... the one added line cannot fix anything. It just adds a log > message. > Thats why I want people to resubmit and let us know what that log line says. -Mike From jamatos at fc.up.pt Mon Aug 20 17:39:58 2007 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Mon, 20 Aug 2007 18:39:58 +0100 Subject: Failed access to koji In-Reply-To: <20070817180051.21b02a73@ender> References: <200708172207.10888.jamatos@fc.up.pt> <20070817180051.21b02a73@ender> Message-ID: <200708201839.58244.jamatos@fc.up.pt> On Friday 17 August 2007 23:00:51 Jesse Keating wrote: > Have you ran through fedora-packager-setup.sh and followed the > instructions on importing the ssl cert into your browser? Yes, I had. :-) The only problem was that the certificate had expired a few minutes before sending this message. :-( After renewing the certificate everything works as expected. Thank you for the feedback. :-) > -- > Jesse Keating > Fedora -- All my bits are free, are yours? -- Jos? Ab?lio From dominik at greysector.net Mon Aug 20 20:04:09 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 20 Aug 2007 22:04:09 +0200 Subject: The open() system call in f8 really broken... In-Reply-To: <20070820084049.GU2063@devserv.devel.redhat.com> References: <46C3A0AA.7090106@RedHat.com> <20070816093959.GB2070@devserv.devel.redhat.com> <46C45B48.3000607@RedHat.com> <20070816142437.GA2063@devserv.devel.redhat.com> <46C4BF3A.6040702@redhat.com> <20070816212632.GM2063@devserv.devel.redhat.com> <20070816221953.GA12881@devserv.devel.redhat.com> <1187598900.3137.16.camel@shinybook.infradead.org> <20070820084049.GU2063@devserv.devel.redhat.com> Message-ID: <20070820200409.GA10207@ryvius.pekin.waw.pl> On Monday, 20 August 2007 at 10:40, Jakub Jelinek wrote: [...] Forgive me for being off topic, but will you please bump gcc package release number so that it's higher in F-7 than in FC-6? This has been laying around for weeks if not months. You haven't responded to the bugzilla ticket I filed (#251035). Please take care of this soon. Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From wart at kobold.org Mon Aug 20 21:58:35 2007 From: wart at kobold.org (Wart) Date: Mon, 20 Aug 2007 14:58:35 -0700 Subject: SGI Message-ID: <46CA0E8B.3040709@kobold.org> Can someone explain to this legally-challenged person what prevents the SGI Free Software License B from being acceptable in Fedora? --Wart [1]http://oss.sgi.com/projects/FreeB/ From tibbs at math.uh.edu Mon Aug 20 22:28:03 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 20 Aug 2007 17:28:03 -0500 Subject: SGI In-Reply-To: <46CA0E8B.3040709@kobold.org> References: <46CA0E8B.3040709@kobold.org> Message-ID: >>>>> "W" == Wart writes: W> Can someone explain to this legally-challenged person what prevents W> the SGI Free Software License B from being acceptable in Fedora? I'm not an expert either, but it seems to me that it contains a use restriction: "No License for Hardware Implementations". - J< From jwboyer at jdub.homelinux.org Mon Aug 20 22:37:57 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 20 Aug 2007 17:37:57 -0500 Subject: SGI In-Reply-To: References: <46CA0E8B.3040709@kobold.org> Message-ID: <20070820173757.4e4504ba@vader.jdub.homelinux.org> On 20 Aug 2007 17:28:03 -0500 Jason L Tibbitts III wrote: > >>>>> "W" == Wart writes: > > W> Can someone explain to this legally-challenged person what prevents > W> the SGI Free Software License B from being acceptable in Fedora? > > I'm not an expert either, but it seems to me that it contains a use > restriction: "No License for Hardware Implementations". I don't think that is the largest issue. josh From tibbs at math.uh.edu Mon Aug 20 23:13:58 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 20 Aug 2007 18:13:58 -0500 Subject: SGI In-Reply-To: <20070820173757.4e4504ba@vader.jdub.homelinux.org> References: <46CA0E8B.3040709@kobold.org> <20070820173757.4e4504ba@vader.jdub.homelinux.org> Message-ID: >>>>> "JB" == Josh Boyer writes: JB> I don't think that is the largest issue. I didn't intend to indicate that it was. Care to let us in on what you believe the largest issue is, then? - J< From buildsys at fedoraproject.org Tue Aug 21 00:27:18 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 20 Aug 2007 20:27:18 -0400 (EDT) Subject: Package EVR problems in Fedora 2007-08-20 Message-ID: <20070821002718.23EBB152131@buildsys.fedoraproject.org> Axel Thimm AT ATrpms net: smart FE6 > F8 (0:0.50-47.fc6 > 0:0.50-46.fc8) F7-updates-testing > F8 (0:0.50-47.fc7 > 0:0.50-46.fc8) alexl AT redhat com: xdg-user-dirs F7-updates > F8 (0:0.8-3.fc7 > 0:0.8-2.fc8) andreas bierfert AT lowlatency de: wine-docs F7-updates-testing > F8 (0:0.9.43-1.fc7 > 0:0.9.42-1.fc8) davidz AT redhat com: dbus-python F7-updates-testing > F8 (0:0.82.0-2.fc7 > 0:0.82.0-1.fc8) devrim AT commandprompt com: postgresql-pgpool-II FE6 > F7-updates (0:1.2-4.fc6 > 0:1.2-1.fc7) ed AT eh3 com: scrip FE6 > F7 (0:1.4-7.fc6 > 0:1.4-6.fc6) FE6 > F8 (0:1.4-7.fc6 > 0:1.4-6.fc6) enrico scholz AT informatik tu-chemnitz de: clamav F7-updates-testing > F8 (0:0.91.1-1.fc7 > 0:0.91.1-0.fc8) fedora-usermgmt FE6 > F7 (0:0.10-1.fc6 > 0:0.9-2.fc7) libtasn1 FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE5 > F8 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE6 > F7 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) FE6 > F8 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) mimetic FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7) FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7) tor F7-updates > F8 (0:0.1.2.16-1.fc7 > 0:0.1.2.15-1.fc8) util-vserver FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7) FE6 > F7 (0:0.30.213-2.fc6 > 0:0.30.212-3.fc7) xmlrpc-c FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7) FE6 > F7 (0:1.06.17-1.fc6 > 0:1.06.11-2.fc7) faucamp AT csir co za: espeak F7-updates-testing > F8 (0:1.28-1.fc7 > 0:1.26-1.fc8) foolish AT guezz net: gtranslator F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8) perl-Net-Libdnet F7-updates > F8 (0:0.01-3.fc7.1 > 0:0.01-2.fc8) perl-Nmap-Parser F7-updates > F8 (0:1.05-4.fc7 > 0:1.05-3.fc8) tcptraceroute FE6 > F7-updates (0:1.5-0.2.beta7.fc6 > 0:1.5-0.1.beta7.fc7) gemi AT bluewin ch: gauche-gtk FE6 > F7 (0:0.4.1-15.fc6 > 0:0.4.1-12.fc7) FE6 > F8 (0:0.4.1-15.fc6 > 0:0.4.1-12.fc7) jakub AT redhat com: gcc FC6-updates > F7 (0:4.1.2-13.fc6 > 0:4.1.2-12) jeff AT ocjtech us: jrtplib FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) karen-pease AT uiowa edu: fortune-firefly FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6) FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6) nethack-vultures FE6 > F7 (0:2.1.0-10.fc6 > 0:2.1.0-9.fc7) lemenkov AT gmail com: stratagus FE6 > F7 (0:2.2.4-1.fc6 > 0:2.2.3-1.fc7) lxtnow AT gmail com: gammu FE6 > F8 (0:1.12.92-1.fc6 > 0:1.11.0-1.fc8) F7-updates-testing > F8 (0:1.12.92-1.fc7 > 0:1.11.0-1.fc8) python-gammu FE6 > F7-updates (0:0.21-1.fc6 > 0:0.20-1.fc7) FE6 > F8 (0:0.21-1.fc6 > 0:0.20-1.fc7) specto FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8) F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8) mikeb AT redhat com: python-cheetah FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) FE6 > F8 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) nhorman AT redhat com: irqbalance FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6) FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7) FC5-updates > F8 (2:0.55-4.fc5 > 2:0.55-3.fc8) pawsa AT theochem kth se: balsa F7-updates > F8 (0:2.3.17-2.fc7 > 0:2.3.17-1.fc8) rc040203 AT freenet de: perl-capitalization FE6 > F7 (0:0.03-5.fc6 > 0:0.03-4.fc6) perl-Class-Inspector FE6 > F7 (0:1.17-1.fc6 > 0:1.16-3.fc7) perl-Class-ReturnValue FE6 > F7 (0:0.54-1.fc6 > 0:0.53-6.fc7) rdieter AT math unl edu: kdeartwork-extras FE6 > F7 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) FE6 > F8 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) kdegraphics-extras FE6 > F7 (0:3.5.7-1.fc6 > 0:3.5.5-1.fc7) FE6 > F8 (0:3.5.7-1.fc6 > 0:3.5.5-1.fc7) kdemultimedia-extras FE6 > F7 (6:3.5.7-1.fc6.5 > 6:3.5.6-5.fc7) FE6 > F8 (6:3.5.7-1.fc6.5 > 6:3.5.6-5.fc7) maxima FE5 > F7-updates (0:5.12.0-3.fc5 > 0:5.12.0-2.fc7) FE6 > F7-updates (0:5.12.0-3.fc6 > 0:5.12.0-2.fc7) roland AT redhat com: elfutils F7-updates-testing > F8 (0:0.129-1.fc7 > 0:0.128-2.fc8) sandmann AT redhat com: libgtop2 FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7) splinux25 AT gmail com: lostirc FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7) FE6 > F8 (0:0.4.6-3.fc6 > 0:0.4.6-2.fc8) spr AT astrax fis ucm es: funtools F7-updates-testing > F8 (0:1.4.0-1.fc7 > 0:1.3.0-0.5.b34.fc8) than AT redhat com: kdepim F7-updates > F8 (6:3.5.7-3.fc7 > 6:3.5.7-2.fc8) tsmetana AT redhat com: procps F7-updates > F8 (0:3.2.7-15.fc7 > 0:3.2.7-14.fc8) veillard AT redhat com: libxml2 FC6-updates > F8 (0:2.6.29-1.fc6 > 0:2.6.29-1) F7-updates > F8 (0:2.6.29-1.fc7 > 0:2.6.29-1) ville skytta AT iki fi: em8300-kmod FE6 > F7-updates (0:0.16.3-1.2.6.22.2_42.fc6 > 0:0.16.3-0.1.rc2.2.6.22.1_41.fc7) FE6 > F8 (0:0.16.3-1.2.6.22.2_42.fc6 > 0:0.16.3-0.6.rc2.2.6.23_0.45.rc0.git16.fc8) wolters liste AT gmx net: ktorrent FE6 > F7-updates (0:2.2.1-3.fc6 > 0:2.2.1-1.fc7) rsibreak FE6 > F7 (0:0.8.0-2.fc6 > 0:0.8.0-1.fc6) speedcrunch FE6 > F7-updates (0:0.8-5.fc6 > 0:0.8-4.fc7) ---------------------------------------------------------------------- balsa: pawsa AT theochem kth se F7-updates > F8 (0:2.3.17-2.fc7 > 0:2.3.17-1.fc8) clamav: enrico scholz AT informatik tu-chemnitz de F7-updates-testing > F8 (0:0.91.1-1.fc7 > 0:0.91.1-0.fc8) dbus-python: davidz AT redhat com F7-updates-testing > F8 (0:0.82.0-2.fc7 > 0:0.82.0-1.fc8) elfutils: roland AT redhat com F7-updates-testing > F8 (0:0.129-1.fc7 > 0:0.128-2.fc8) em8300-kmod: ville skytta AT iki fi FE6 > F7-updates (0:0.16.3-1.2.6.22.2_42.fc6 > 0:0.16.3-0.1.rc2.2.6.22.1_41.fc7) FE6 > F8 (0:0.16.3-1.2.6.22.2_42.fc6 > 0:0.16.3-0.6.rc2.2.6.23_0.45.rc0.git16.fc8) espeak: faucamp AT csir co za F7-updates-testing > F8 (0:1.28-1.fc7 > 0:1.26-1.fc8) fedora-usermgmt: enrico scholz AT informatik tu-chemnitz de FE6 > F7 (0:0.10-1.fc6 > 0:0.9-2.fc7) fortune-firefly: karen-pease AT uiowa edu FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6) FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6) funtools: spr AT astrax fis ucm es F7-updates-testing > F8 (0:1.4.0-1.fc7 > 0:1.3.0-0.5.b34.fc8) gammu: lxtnow AT gmail com FE6 > F8 (0:1.12.92-1.fc6 > 0:1.11.0-1.fc8) F7-updates-testing > F8 (0:1.12.92-1.fc7 > 0:1.11.0-1.fc8) gauche-gtk: gemi AT bluewin ch FE6 > F7 (0:0.4.1-15.fc6 > 0:0.4.1-12.fc7) FE6 > F8 (0:0.4.1-15.fc6 > 0:0.4.1-12.fc7) gcc: jakub AT redhat com FC6-updates > F7 (0:4.1.2-13.fc6 > 0:4.1.2-12) gtranslator: foolish AT guezz net F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8) irqbalance: nhorman AT redhat com FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6) FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7) FC5-updates > F8 (2:0.55-4.fc5 > 2:0.55-3.fc8) jrtplib: jeff AT ocjtech us FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) kdeartwork-extras: rdieter AT math unl edu FE6 > F7 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) FE6 > F8 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) kdegraphics-extras: rdieter AT math unl edu FE6 > F7 (0:3.5.7-1.fc6 > 0:3.5.5-1.fc7) FE6 > F8 (0:3.5.7-1.fc6 > 0:3.5.5-1.fc7) kdemultimedia-extras: rdieter AT math unl edu FE6 > F7 (6:3.5.7-1.fc6.5 > 6:3.5.6-5.fc7) FE6 > F8 (6:3.5.7-1.fc6.5 > 6:3.5.6-5.fc7) kdepim: than AT redhat com F7-updates > F8 (6:3.5.7-3.fc7 > 6:3.5.7-2.fc8) ktorrent: wolters liste AT gmx net FE6 > F7-updates (0:2.2.1-3.fc6 > 0:2.2.1-1.fc7) libgtop2: sandmann AT redhat com FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7) libtasn1: enrico scholz AT informatik tu-chemnitz de FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE5 > F8 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE6 > F7 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) FE6 > F8 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) libxml2: veillard AT redhat com FC6-updates > F8 (0:2.6.29-1.fc6 > 0:2.6.29-1) F7-updates > F8 (0:2.6.29-1.fc7 > 0:2.6.29-1) lostirc: splinux25 AT gmail com FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7) FE6 > F8 (0:0.4.6-3.fc6 > 0:0.4.6-2.fc8) maxima: rdieter AT math unl edu FE5 > F7-updates (0:5.12.0-3.fc5 > 0:5.12.0-2.fc7) FE6 > F7-updates (0:5.12.0-3.fc6 > 0:5.12.0-2.fc7) mimetic: enrico scholz AT informatik tu-chemnitz de FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7) FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7) nethack-vultures: karen-pease AT uiowa edu FE6 > F7 (0:2.1.0-10.fc6 > 0:2.1.0-9.fc7) perl-capitalization: rc040203 AT freenet de FE6 > F7 (0:0.03-5.fc6 > 0:0.03-4.fc6) perl-Class-Inspector: rc040203 AT freenet de FE6 > F7 (0:1.17-1.fc6 > 0:1.16-3.fc7) perl-Class-ReturnValue: rc040203 AT freenet de FE6 > F7 (0:0.54-1.fc6 > 0:0.53-6.fc7) perl-Net-Libdnet: foolish AT guezz net F7-updates > F8 (0:0.01-3.fc7.1 > 0:0.01-2.fc8) perl-Nmap-Parser: foolish AT guezz net F7-updates > F8 (0:1.05-4.fc7 > 0:1.05-3.fc8) postgresql-pgpool-II: devrim AT commandprompt com FE6 > F7-updates (0:1.2-4.fc6 > 0:1.2-1.fc7) procps: tsmetana AT redhat com F7-updates > F8 (0:3.2.7-15.fc7 > 0:3.2.7-14.fc8) python-cheetah: mikeb AT redhat com FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) FE6 > F8 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) python-gammu: lxtnow AT gmail com FE6 > F7-updates (0:0.21-1.fc6 > 0:0.20-1.fc7) FE6 > F8 (0:0.21-1.fc6 > 0:0.20-1.fc7) rsibreak: wolters liste AT gmx net FE6 > F7 (0:0.8.0-2.fc6 > 0:0.8.0-1.fc6) scrip: ed AT eh3 com FE6 > F7 (0:1.4-7.fc6 > 0:1.4-6.fc6) FE6 > F8 (0:1.4-7.fc6 > 0:1.4-6.fc6) smart: Axel Thimm AT ATrpms net FE6 > F8 (0:0.50-47.fc6 > 0:0.50-46.fc8) F7-updates-testing > F8 (0:0.50-47.fc7 > 0:0.50-46.fc8) specto: lxtnow AT gmail com FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8) F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8) speedcrunch: wolters liste AT gmx net FE6 > F7-updates (0:0.8-5.fc6 > 0:0.8-4.fc7) stratagus: lemenkov AT gmail com FE6 > F7 (0:2.2.4-1.fc6 > 0:2.2.3-1.fc7) tcptraceroute: foolish AT guezz net FE6 > F7-updates (0:1.5-0.2.beta7.fc6 > 0:1.5-0.1.beta7.fc7) tor: enrico scholz AT informatik tu-chemnitz de F7-updates > F8 (0:0.1.2.16-1.fc7 > 0:0.1.2.15-1.fc8) util-vserver: enrico scholz AT informatik tu-chemnitz de FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7) FE6 > F7 (0:0.30.213-2.fc6 > 0:0.30.212-3.fc7) wine-docs: andreas bierfert AT lowlatency de F7-updates-testing > F8 (0:0.9.43-1.fc7 > 0:0.9.42-1.fc8) xdg-user-dirs: alexl AT redhat com F7-updates > F8 (0:0.8-3.fc7 > 0:0.8-2.fc8) xmlrpc-c: enrico scholz AT informatik tu-chemnitz de FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7) FE6 > F7 (0:1.06.17-1.fc6 > 0:1.06.11-2.fc7) From jwboyer at jdub.homelinux.org Tue Aug 21 00:32:14 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 20 Aug 2007 19:32:14 -0500 Subject: SGI In-Reply-To: References: <46CA0E8B.3040709@kobold.org> <20070820173757.4e4504ba@vader.jdub.homelinux.org> Message-ID: <20070820193214.2afc7c75@vader.jdub.homelinux.org> On 20 Aug 2007 18:13:58 -0500 Jason L Tibbitts III wrote: > >>>>> "JB" == Josh Boyer writes: > > JB> I don't think that is the largest issue. > > I didn't intend to indicate that it was. Care to let us in on what > you believe the largest issue is, then? No. I would prefer if spot did that. josh From tcallawa at redhat.com Tue Aug 21 01:32:46 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 20 Aug 2007 21:32:46 -0400 Subject: SGI In-Reply-To: <46CA0E8B.3040709@kobold.org> References: <46CA0E8B.3040709@kobold.org> Message-ID: <1187659966.3439.292.camel@dhcp83-165.boston.redhat.com> On Mon, 2007-08-20 at 14:58 -0700, Wart wrote: > Can someone explain to this legally-challenged person what prevents the > SGI Free Software License B from being acceptable in Fedora? From: http://www.fsf.org/licensing/licenses/ The SGI Free Software License B, although its name says "free", is not a free software License. It has three major problems. 1. It restricts its patent license to unmodified versions of the software. 2. It terminates if your use of the software infringes copyrights or patents which are not SGI's. This is problematic because it gives SGI grounds to sue you even when you have done nothing to them. 3. The license requires you to inform SGI of legal problems with the software. This violates your privacy rights, and can conflict with professional confidentiality requirements, such as attorney-client privilege. To put it simply: code under SGI Free B cannot be modified without violating the license. ~spot From kzak at redhat.com Tue Aug 21 07:39:03 2007 From: kzak at redhat.com (Karel Zak) Date: Tue, 21 Aug 2007 09:39:03 +0200 Subject: how to rename a packge? In-Reply-To: <200708171440.25780.opensource@till.name> References: <200708171440.25780.opensource@till.name> Message-ID: <20070821073903.GA3154@petra.dvoda.cz> On Fri, Aug 17, 2007 at 02:40:18PM +0200, Till Maas wrote: > Hiyas, > > cryptsetup-luks has been renamed to cryptsetup, so if I want to reflect this > change in Fedora, how can this be done? I did same thing in last days (util-linux -> util-linux-ng). cryptosetup (=new package): http://fedoraproject.org/wiki/PackageMaintainers/NewPackageProcess cryptsetup-luks (=dead package): http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife + mail to rel-eng at fedoraproject.org Karel -- Karel Zak From giallu at gmail.com Tue Aug 21 08:18:15 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 21 Aug 2007 10:18:15 +0200 Subject: build fails without reason, bug in plague? In-Reply-To: <46C9AF01.3090804@redhat.com> References: <46C6B59F.3070200@fedoraproject.org> <46C78820.2040406@redhat.com> <1187619535.31150.13.camel@xo-13-A4-25.localdomain> <46C9AF01.3090804@redhat.com> Message-ID: On 8/20/07, Mike McGrath wrote: > > > > def _watch_mock(self, good_exit, bad_exit): > > (aux_pid, status) = os.waitpid(self._childpid, os.WNOHANG) > > status = os.WEXITSTATUS(status) > > if aux_pid: > > + self._log("_watch_mock(): PID %d exit status %d\n" % (self._childpid, status)) > > self._childpid = 0 > > if status == 0: > > self._done_status = good_exit > > elif status > 0: > > self._done_status = bad_exit > > > > self._copy_mock_output_to_log() > > self._start_cleanup() > > > > Dan > > > > > > > Thanks dan, I've added this to the builders and it appears to be > working. All people with this failed sucess please resubmit and let us > know how it goes. > > http://buildsys.fedoraproject.org/logs/fedora-5-epel/35767-nagios-2.9-1.el5/i386/job.log > <-- working example. I just had a "failed" build here: http://buildsys.fedoraproject.org/logs/fedora-6-extras/35774-sysprof-kmod-1.0.8-1.2.6.22.2_42.fc6/i586/job.log _watch_mock(): PID 7083 exit status 0 From cbalint at redhat.com Tue Aug 21 13:18:44 2007 From: cbalint at redhat.com (Balint Cristian) Date: Tue, 21 Aug 2007 15:18:44 +0200 Subject: Fwd: gdal in EPEL Message-ID: <200708211518.44256.cbalint@redhat.com> Hello folks, Recently i builded some packages in EPEL sucessfully but it cant be seen in the repo: http://download.fedora.redhat.com/pub/epel/5/i386/ Does it after build require some further step for being seen ? e.g gdal, ogdi, libgeotiff ---------- Forwarded Message ---------- Subject: gdal in EPEL Date: Monday 20 August 2007 From: "Frederick (Rick) A Niles" To: Balint Cristian I've waited a few days in case there was delay, but I'm still not see any GDAL packages at: http://download.fedora.redhat.com/pub/epel/5/i386/ am I looking at the right place? Thanks, Rick Niles. Balint Cristian wrote: > On Thursday 09 August 2007, Frederick (Rick) A Niles wrote: > > FYI, > > I just pushed in EPEL EL-5 branch gdal and its subdependents (geotiff,ogdi) ! > You can start use gdal from there. ------------------------------------------------------- -- Balint Cristian (Red Hat Release Engineering Team) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From fedora at leemhuis.info Tue Aug 21 14:05:04 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 21 Aug 2007 16:05:04 +0200 Subject: Fwd: gdal in EPEL In-Reply-To: <200708211518.44256.cbalint@redhat.com> References: <200708211518.44256.cbalint@redhat.com> Message-ID: <46CAF110.5080802@leemhuis.info> On 21.08.2007 15:18, Balint Cristian wrote: > > Recently i builded some packages in EPEL sucessfully but it cant be seen in the repo: > http://download.fedora.redhat.com/pub/epel/5/i386/ > > Does it after build require some further step for being seen ? > > e.g gdal, ogdi, libgeotiff Hehe ;-) -- two days ago I send this mail https://www.redhat.com/archives/fedora-maintainers/2007-August/msg00475.html on this list which contained: >> Reminder: now that EPEL is officially announced all new and updates >> EPEL packages go straight to EPEL-testing and *not* to the stable repo. >> EPEL-testing packages will (if everything is sane) get moved to stable >> repo in parallel with a quarterly RHEL update. [...] So you can find your packages in http://download.fedora.redhat.com/pub/epel/testing/5/i386/ There are some discussions to push more often to stable, put pushing to testing by default seems to be the safest bet to make sure we have repo without broken deps with packages that actually work. Especially due to the fact that we in the initial EPEL buildup phase (e.g. until the annoucement) we had lots of broken deps (which one also could imply as: "the maintainer built blindly without even checking once if the package actually works"). CU knurd From loganjerry at gmail.com Tue Aug 21 04:20:31 2007 From: loganjerry at gmail.com (Jerry James) Date: Mon, 20 Aug 2007 22:20:31 -0600 Subject: Jpackage: follow or lead? Message-ID: <870180fe0708202120v23d3d224w69823123df3a273d@mail.gmail.com> I'd like to get findbugs into Fedora. Findbugs can optionally use ASM instead of BCEL. I would like to get ASM into Fedora first, then, so we don't have any pesky options that don't work. Jpackage.org has an ASM package already; two of them in fact. The package named "asm" contains version 1.5.3, and the package named "asm2" contains version 2.1. However, the current ASM release is version 3.0 (as of November 2006). Should I follow jpackage.org and go with an "asm2" package until they release a version 3, or should I cut to the chase and create a version 3 package for Fedora? In the latter case, I presume it should be named "asm3" and have a version number containing "jpp"; is there any reason to do otherwise? Thanks, -- Jerry James http://loganjerry.googlepages.com/ http://jjames.fedorapeople.org/ From jwboyer at jdub.homelinux.org Tue Aug 21 14:32:02 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 21 Aug 2007 09:32:02 -0500 Subject: Jpackage: follow or lead? In-Reply-To: <870180fe0708202120v23d3d224w69823123df3a273d@mail.gmail.com> References: <870180fe0708202120v23d3d224w69823123df3a273d@mail.gmail.com> Message-ID: <20070821093202.5532b5c8@weaponx.rchland.ibm.com> On Mon, 20 Aug 2007 22:20:31 -0600 "Jerry James" wrote: > I'd like to get findbugs into Fedora. Findbugs can optionally use ASM > instead of BCEL. I would like to get ASM into Fedora first, then, so > we don't have any pesky options that don't work. Jpackage.org has an > ASM package already; two of them in fact. The package named "asm" > contains version 1.5.3, and the package named "asm2" contains version > 2.1. However, the current ASM release is version 3.0 (as of November > 2006). Should I follow jpackage.org and go with an "asm2" package > until they release a version 3, or should I cut to the chase and > create a version 3 package for Fedora? In the latter case, I presume > it should be named "asm3" and have a version number containing "jpp"; > is there any reason to do otherwise? Thanks, asm2 is already in Fedora. It's just never been built. It's owner is Permaine Cheung (pcheung). josh From Fedora at FamilleCollet.com Tue Aug 21 15:16:02 2007 From: Fedora at FamilleCollet.com (Remi Collet) Date: Tue, 21 Aug 2007 17:16:02 +0200 Subject: PackagingDrafts/PHP is ready for FPC Message-ID: <46CB01B2.1080604@FamilleCollet.com> Hi, I've work on a update of the PHP Guidelines. Main goal is to add registration of PECL extension (possible with pear 1.6.x available in rawhide/F-8 which defines new macros) and some R/BR cleanups. "Packages with Channels" still in "TODO" state, but at least uninstall scriptlet could be add. Should I add it to PackagingDrafts/DraftsTodo ? (which owner, me or a FPC member ?) Thanks, Remi From tcallawa at redhat.com Tue Aug 21 15:14:07 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 21 Aug 2007 11:14:07 -0400 Subject: PackagingDrafts/PHP is ready for FPC In-Reply-To: <46CB01B2.1080604@FamilleCollet.com> References: <46CB01B2.1080604@FamilleCollet.com> Message-ID: <1187709247.3439.297.camel@dhcp83-165.boston.redhat.com> On Tue, 2007-08-21 at 17:16 +0200, Remi Collet wrote: > Hi, > > I've work on a update of the PHP Guidelines. > > Main goal is to add registration of PECL extension (possible with pear > 1.6.x available in rawhide/F-8 which defines new macros) and some R/BR > cleanups. > > "Packages with Channels" still in "TODO" state, but at least uninstall > scriptlet could be add. > > > Should I add it to PackagingDrafts/DraftsTodo ? (which owner, me or a > FPC member ?) Please add it. What you set to "owner" is not terribly important. ~spot From ville.skytta at iki.fi Tue Aug 21 16:06:22 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Tue, 21 Aug 2007 19:06:22 +0300 Subject: Lots of pkgdb mail on commits list Message-ID: <200708211906.22500.ville.skytta@iki.fi> Hello, Operations on the pkgdb appear to result in lots and lots of mail on the commits list, one high level operation such as orphaning a package appears to often spew around ten mails. This makes following the commits list much harder than before. Is reducing the number of these messages being worked on (eg. grouping results of a single high level operation into one mail instead of sending one for each bit)? I can of course add local filters to take care of it, but that's just a band aid. From rc040203 at freenet.de Tue Aug 21 16:16:52 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 21 Aug 2007 18:16:52 +0200 Subject: Lots of pkgdb mail on commits list In-Reply-To: <200708211906.22500.ville.skytta@iki.fi> References: <200708211906.22500.ville.skytta@iki.fi> Message-ID: <1187713012.31667.150.camel@mccallum.corsepiu.local> On Tue, 2007-08-21 at 19:06 +0300, Ville Skytt? wrote: > Hello, > > Operations on the pkgdb appear to result in lots and lots of mail on the > commits list, one high level operation such as orphaning a package appears to > often spew around ten mails. While we're at it, would somebody please explain the rationale for orphaning Fedora 1 to Fedora 5 packages? > This makes following the commits list much harder than before. Is reducing > the number of these messages being worked on (eg. grouping results of a > single high level operation into one mail instead of sending one for each > bit)? I can of course add local filters to take care of it, but that's just > a band aid. +1 - commits@ had become less readable than ever. Ralf From loganjerry at gmail.com Tue Aug 21 16:18:17 2007 From: loganjerry at gmail.com (Jerry James) Date: Tue, 21 Aug 2007 10:18:17 -0600 Subject: Jpackage: follow or lead? In-Reply-To: <20070821093202.5532b5c8@weaponx.rchland.ibm.com> References: <870180fe0708202120v23d3d224w69823123df3a273d@mail.gmail.com> <20070821093202.5532b5c8@weaponx.rchland.ibm.com> Message-ID: <870180fe0708210918x30a71086r9820d96568051e74@mail.gmail.com> On 8/21/07, Josh Boyer wrote: > asm2 is already in Fedora. It's just never been built. It's owner is > Permaine Cheung (pcheung). Thanks for the information. I will contact Permaine. -- Jerry James http://loganjerry.googlepages.com/ From a.badger at gmail.com Tue Aug 21 16:39:21 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 21 Aug 2007 09:39:21 -0700 Subject: Lots of pkgdb mail on commits list In-Reply-To: <200708211906.22500.ville.skytta@iki.fi> References: <200708211906.22500.ville.skytta@iki.fi> Message-ID: <46CB1539.7060206@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ville Skytt? wrote: > Hello, > > Operations on the pkgdb appear to result in lots and lots of mail on the > commits list, one high level operation such as orphaning a package appears to > often spew around ten mails. > If you're getting ten messages then there's something wrong. Orphaning packages is currently generating one notification per branch[1]_.... > This makes following the commits list much harder than before. Is reducing > the number of these messages being worked on (eg. grouping results of a > single high level operation into one mail instead of sending one for each > bit)? I can of course add local filters to take care of it, but that's just > a band aid. > ...but I definitely agree that there is too much mail being sent even if it's only half that amount. The question is what to do about it? In the case of orphaning a package, for instance, there is no high level "orphaned package" operation anymore. It's now owned and orphaned per package-branch. So achieving this is somewhat less than ideal. Some options: 1) I can't see any reason for people to orphan/own/etc packages in EOL collections. Changing the interface to not show these by default needs to be done at some point and discourages people from pressing "orphan package" for that collection. This will cut down the amount of mail sent because people will be working with less collections. 2) Just don't send mail for EOL collections. If someone makes a change there, who cares? This is somewhat a question of what we want commits list to be. Do we want it to record all changes to packages or just changes that we feel we want to know about? 3) Have an asynchronous process that periodically reads the logs that the packagedb is keeping and sends one mail per package (or package branch) when a change occurred to that package since the last log scan. 4) Disable messages from the pkgdb to commits altogether. #4 is easy. #2 is somewhat easy. #1 & #3 will take some time to implement. #1 is something that should be done at some point anyway. #3 seems like the right approach for the future. Comments, other options? I'm currently leaning towards implementing #2 short term (by end of week) and working on #3 and #1 on a broader time frame. - -Toshio P.S. Thanks to Ralf for suggesting #2 .. _[1]: https://www.redhat.com/archives/fedora-extras-commits/2007-August/thread.html .. _[2]: https://www.redhat.com/archives/fedora-extras-commits/2007-August/msg05329.html - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGyxU5X6yAic2E7kgRAsvfAJ9s10o/KrukszR91T44y/EfdB+aIwCfapUE T0jnUcPPQwPRuEoOctyeDsc= =DX3U -----END PGP SIGNATURE----- From jkeating at redhat.com Tue Aug 21 16:43:25 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 21 Aug 2007 12:43:25 -0400 Subject: Lots of pkgdb mail on commits list In-Reply-To: <46CB1539.7060206@gmail.com> References: <200708211906.22500.ville.skytta@iki.fi> <46CB1539.7060206@gmail.com> Message-ID: <20070821124325.3442ff39@mentok.boston.redhat.com> On Tue, 21 Aug 2007 09:39:21 -0700 Toshio Kuratomi wrote: > Comments, other options? I'm currently leaning towards implementing > #2 short term (by end of week) and working on #3 and #1 on a broader > time frame. Have a --global option that acts globally and generates only one message. Useful instead of listing each and every active branch when dropping a package or changing ownership. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Tue Aug 21 16:52:41 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 21 Aug 2007 18:52:41 +0200 Subject: Lots of pkgdb mail on commits list In-Reply-To: <46CB1539.7060206@gmail.com> References: <200708211906.22500.ville.skytta@iki.fi> <46CB1539.7060206@gmail.com> Message-ID: <1187715161.31667.160.camel@mccallum.corsepiu.local> On Tue, 2007-08-21 at 09:39 -0700, Toshio Kuratomi wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Ville Skytt? wrote: > > Hello, > > > > Operations on the pkgdb appear to result in lots and lots of mail on the > > commits list, one high level operation such as orphaning a package appears to > > often spew around ten mails. > > > If you're getting ten messages then there's something wrong. Orphaning > packages is currently generating one notification per branch[1]_.... May-be, I am wrong, but as it seems to seems me, in cases somebody orphans a package entirely, up to 8 mails (one per branch) are being send to commits at . In cases of perl-packages add up to 8 further mails. At least I have been swamped in such mails throughout today (some referring to Fedora 1-5) and meanwhile have set up a filter to dump all pkgdb mails. > ...but I definitely agree that there is too much mail being sent even if > it's only half that amount. > > The question is what to do about it? Not sending them to commits@ at all. Commits@ become what it once originally was: A list to take CVS commits on rpms only. Ralf From ville.skytta at iki.fi Tue Aug 21 17:01:50 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Tue, 21 Aug 2007 20:01:50 +0300 Subject: Lots of pkgdb mail on commits list In-Reply-To: <46CB1539.7060206@gmail.com> References: <200708211906.22500.ville.skytta@iki.fi> <46CB1539.7060206@gmail.com> Message-ID: <200708212001.51268.ville.skytta@iki.fi> On Tuesday 21 August 2007, Toshio Kuratomi wrote: > Ville Skytt? wrote: > > Hello, > > > > Operations on the pkgdb appear to result in lots and lots of mail on the > > commits list, one high level operation such as orphaning a package > > appears to often spew around ten mails. > > If you're getting ten messages then there's something wrong. Orphaning > packages is currently generating one notification per branch[1]_.... Ok, that seems to be true, but my example was just a general one. The orphaning case seems to be related to people for some reason tweaking EOLd branches. > > This makes following the commits list much harder than before. Is > > reducing the number of these messages being worked on (eg. grouping > > results of a single high level operation into one mail instead of sending > > one for each bit)? I can of course add local filters to take care of it, > > but that's just a band aid. > > ...but I definitely agree that there is too much mail being sent even if > it's only half that amount. Yep, and for some things such as "add Joe Packager as a co-maintainer for foo" it's even worse than that, for example adding Dmitry as co-maintainer for mail-notification has resulted in 24 mails thus far. elinks -dump https://www.redhat.com/archives/fedora-extras-commits/2007-August/thread.html | grep '\[pkgdb\].*mail-notification' > Some options: [...] > Comments, other options? I'm currently leaning towards implementing #2 > short term (by end of week) and working on #3 and #1 on a broader time > frame. 1-3 sound fine to me, but I'd also like to suggest considering either directing the pkgdb messages to a completely separate list, or adding some topic categories in mailman config for the commits list. From jonathan.underwood at gmail.com Tue Aug 21 17:29:43 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 21 Aug 2007 18:29:43 +0100 Subject: This list isn't working out. Or, why do we have fedora-devel and fedora-maintainers Message-ID: <645d17210708211029y4717366pf927665eb37ec8e6@mail.gmail.com> Hi, In recent weeks a lot of mailing list traffic I would have expected to come to this list has gone to fedora-devel. People seem confused as to what should be discussed where wrt to these two lists. Heck, in recent weeks, it's not clear to me. Can we either get a lot more disciplined about pointing out when people are using the wrong list or (this would be my choice) kill off fedora-maintainers. Jonathan. From jkeating at redhat.com Tue Aug 21 17:33:56 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 21 Aug 2007 13:33:56 -0400 Subject: This list isn't working out. Or, why do we have fedora-devel and fedora-maintainers In-Reply-To: <645d17210708211029y4717366pf927665eb37ec8e6@mail.gmail.com> References: <645d17210708211029y4717366pf927665eb37ec8e6@mail.gmail.com> Message-ID: <20070821133356.61e17560@mentok.boston.redhat.com> On Tue, 21 Aug 2007 18:29:43 +0100 "Jonathan Underwood" wrote: > In recent weeks a lot of mailing list traffic I would have expected to > come to this list has gone to fedora-devel. People seem confused as to > what should be discussed where wrt to these two lists. Heck, in recent > weeks, it's not clear to me. Can we either get a lot more disciplined > about pointing out when people are using the wrong list or (this would > be my choice) kill off fedora-maintainers. I'm +1 for killing -maintainers. Now that we have fedora-devel-announce people can, if they wish, not get all the "noise" of fedora-devel and instead just get the announcements. Since fedora-devel-announce postings go to fedora-devel-list as well, you don't have to subscribe to yet another announce list if you don't want to. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Tue Aug 21 18:20:17 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 21 Aug 2007 13:20:17 -0500 Subject: This list isn't working out. Or, why do we have fedora-devel and fedora-maintainers In-Reply-To: <20070821133356.61e17560@mentok.boston.redhat.com> References: <645d17210708211029y4717366pf927665eb37ec8e6@mail.gmail.com> <20070821133356.61e17560@mentok.boston.redhat.com> Message-ID: <20070821132017.3fb1500f@weaponx.rchland.ibm.com> On Tue, 21 Aug 2007 13:33:56 -0400 Jesse Keating wrote: > On Tue, 21 Aug 2007 18:29:43 +0100 > "Jonathan Underwood" wrote: > > > In recent weeks a lot of mailing list traffic I would have expected to > > come to this list has gone to fedora-devel. People seem confused as to > > what should be discussed where wrt to these two lists. Heck, in recent > > weeks, it's not clear to me. Can we either get a lot more disciplined > > about pointing out when people are using the wrong list or (this would > > be my choice) kill off fedora-maintainers. > > I'm +1 for killing -maintainers. Now that we have > fedora-devel-announce people can, if they wish, not get all the "noise" > of fedora-devel and instead just get the announcements. Since > fedora-devel-announce postings go to fedora-devel-list as well, you > don't have to subscribe to yet another announce list if you don't want > to. +1 to killing it. josh From bkonrath at redhat.com Tue Aug 21 18:38:50 2007 From: bkonrath at redhat.com (Ben Konrath) Date: Tue, 21 Aug 2007 14:38:50 -0400 Subject: FeatureEclipse33 Status In-Reply-To: <29c1e9a40708170613v3caa3d9bs88c72ce71ed8758d@mail.gmail.com> References: <1187112770.11441.17.camel@localhost.localdomain> <29c1e9a40708170613v3caa3d9bs88c72ce71ed8758d@mail.gmail.com> Message-ID: <1187721530.4264.11.camel@toast.toronto.redhat.com> On Fri, 2007-08-17 at 09:13 -0400, Igor Foox wrote: > Hi all, > > On 8/14/07, Andrew Overholt wrote: > > Hi, > > > > Here's the status of the Fedora 8 feature of updating the Eclipse stack > > to the 3.3 (Europa) base [1]. I've CC'd all of the maintainers. Please > > reply with answers where you can. > > > > PyDev (Igor Foox) > > - Igor: can you update to latest version that works with 3.3? If not, > > can you orphan it? Ben says he can take it over if you don't have time. > > - would be nice to get Mylyn integration in when we update > > I won't have the time to update PyDev for this release unfortunately. > I would appreciate it if Ben could take over for now. I will probably > be able to take it back in a month or two. Ok, can you add me to the ACL and I'll update it for this release? Why don't we say that we're co-maintaining pydev so that you can still help out when you have time. Thanks, Ben From jima at beer.tclug.org Tue Aug 21 19:16:47 2007 From: jima at beer.tclug.org (Jima) Date: Tue, 21 Aug 2007 14:16:47 -0500 (CDT) Subject: This list isn't working out. Or, why do we have fedora-devel and fedora-maintainers In-Reply-To: <645d17210708211029y4717366pf927665eb37ec8e6@mail.gmail.com> References: <645d17210708211029y4717366pf927665eb37ec8e6@mail.gmail.com> Message-ID: On Tue, 21 Aug 2007, Jonathan Underwood wrote: > Can we either get a lot more disciplined about pointing out when people > are using the wrong list or (this would be my choice) kill off > fedora-maintainers. +1, death to -maintainers. :-) Jima (Err...the list; put down the pitchforks.) From martin.sourada at seznam.cz Tue Aug 21 19:30:41 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Tue, 21 Aug 2007 21:30:41 +0200 Subject: This list isn't working out. Or, why do we have fedora-devel and fedora-maintainers In-Reply-To: References: <645d17210708211029y4717366pf927665eb37ec8e6@mail.gmail.com> Message-ID: <1187724641.9578.115.camel@pc-notebook> On Tue, 2007-08-21 at 21:16 +0200, Jima wrote: > On Tue, 21 Aug 2007, Jonathan Underwood wrote: > > Can we either get a lot more disciplined about pointing out when people > > are using the wrong list or (this would be my choice) kill off > > fedora-maintainers. > > +1, death to -maintainers. :-) > > Jima > > (Err...the list; put down the pitchforks.) > I am also for the death for the -maintainers as it is now, as I completely don't know sometimes, what is the difference between -maintainers and -devel. But I think that maintainers should be a subset of -devel, i.e. -devel is for all development discussion, while -maintainers should be only for package maintainers and should be only about packaging issues, which is currently not and in the current state of things it would really be better to kill this list... Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From wolters.liste at gmx.net Tue Aug 21 19:43:22 2007 From: wolters.liste at gmx.net (Roland Wolters) Date: Tue, 21 Aug 2007 21:43:22 +0200 Subject: This list isn't working out. Or, why do we have fedora-devel and fedora-maintainers In-Reply-To: <645d17210708211029y4717366pf927665eb37ec8e6@mail.gmail.com> References: <645d17210708211029y4717366pf927665eb37ec8e6@mail.gmail.com> Message-ID: <200708212143.30179.wolters.liste@gmx.net> Once upon a time Jonathan Underwood wrote: > kill off fedora-maintainers. > Well, I would totally agree with that - however, once or twice in the past I actually had questions regarding the maintaining of packages. And -devel is *no* option for me, I just don't have time to deal with that. So what should people like me (maintaining just a few packages) do? Roland -------------- 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 tmraz at redhat.com Tue Aug 21 19:54:52 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Tue, 21 Aug 2007 21:54:52 +0200 Subject: openssl097a package retirement Message-ID: <1187726092.3852.37.camel@vespa.kabelta.loc> If there will not be any serious objections I'll retire openssl097a package in rawhide. It doesn't make much sense to maintain this old version of openssl in Fedora. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From tmz at pobox.com Tue Aug 21 20:09:15 2007 From: tmz at pobox.com (Todd Zullinger) Date: Tue, 21 Aug 2007 16:09:15 -0400 Subject: This list isn't working out. Or, why do we have fedora-devel and fedora-maintainers In-Reply-To: <200708212143.30179.wolters.liste@gmx.net> References: <645d17210708211029y4717366pf927665eb37ec8e6@mail.gmail.com> <200708212143.30179.wolters.liste@gmx.net> Message-ID: <20070821200915.GE28116@psilocybe.teonanacatl.org> Roland Wolters wrote: > Well, I would totally agree with that - however, once or twice in > the past I actually had questions regarding the maintaining of > packages. And -devel is *no* option for me, I just don't have time > to deal with that. > > So what should people like me (maintaining just a few packages) do? You could subscribe to fedora-devel-announce and fedora-devel-list. Set your fedora-devel subscription to nomail so that you can still post there (I'm assuming posting it restricted to subscribers, but if I wasn't so lazy I'd verify that). That way you can still ask the occasional question that you might have and then just check the archives for replies (and/or ask to be CC:d). -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Giving a politician access to your wallet is like giving a dog access to your refrigerator. -- Tim Barber -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From a.badger at gmail.com Tue Aug 21 20:37:00 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 21 Aug 2007 13:37:00 -0700 Subject: Lots of pkgdb mail on commits list In-Reply-To: <20070821124325.3442ff39@mentok.boston.redhat.com> References: <200708211906.22500.ville.skytta@iki.fi> <46CB1539.7060206@gmail.com> <20070821124325.3442ff39@mentok.boston.redhat.com> Message-ID: <46CB4CEC.3070307@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating wrote: > On Tue, 21 Aug 2007 09:39:21 -0700 > Toshio Kuratomi wrote: > >> Comments, other options? I'm currently leaning towards implementing >> #2 short term (by end of week) and working on #3 and #1 on a broader >> time frame. > > Have a --global option that acts globally and generates only one > message. Useful instead of listing each and every active branch when > dropping a package or changing ownership. > This sort of works for cvsadmins using the commandline client but doesn't work for endusers using the webUI. Where it breaks down even for the cvsadmins is what to do when there are different owners on different package-branches. For instance, Foo is the owner in RHL8-FC2. Bar is the FC3-devel owner, and Baz is the EL5 owner. I don't think that admins will often want to change all of those. - --global could error out when it encounters such a situation.... But this is going to become more common because we probably don't want or need to change ownership on EOL releases. - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGy0yhX6yAic2E7kgRAopNAJ49t/qRL3kib5bYth6M4H/2LAFnTQCgh8sn x9+azjoiFmeQ1xQz1wBJ2+U= =vO5e -----END PGP SIGNATURE----- From jkeating at redhat.com Tue Aug 21 20:43:50 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 21 Aug 2007 16:43:50 -0400 Subject: Lots of pkgdb mail on commits list In-Reply-To: <46CB4CEC.3070307@gmail.com> References: <200708211906.22500.ville.skytta@iki.fi> <46CB1539.7060206@gmail.com> <20070821124325.3442ff39@mentok.boston.redhat.com> <46CB4CEC.3070307@gmail.com> Message-ID: <20070821164350.18abecef@mentok.boston.redhat.com> On Tue, 21 Aug 2007 13:37:00 -0700 Toshio Kuratomi wrote: > Where it breaks down even for the cvsadmins is what to do when there > are different owners on different package-branches. For instance, > Foo is the owner in RHL8-FC2. Bar is the FC3-devel owner, and Baz is > the EL5 owner. I don't think that admins will often want to change > all of those. Actually that happens /very/ frequently within Red Hat engineering, where packages as a whole are reassigned to a different maintainer. > - --global could error out when it encounters such a situation.... But > this is going to become more common because we probably don't want or > need to change ownership on EOL releases. --global would just plain ignore EOL release branches. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Tue Aug 21 20:58:20 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 21 Aug 2007 13:58:20 -0700 Subject: Lots of pkgdb mail on commits list In-Reply-To: <20070821164350.18abecef@mentok.boston.redhat.com> References: <200708211906.22500.ville.skytta@iki.fi> <46CB1539.7060206@gmail.com> <20070821124325.3442ff39@mentok.boston.redhat.com> <46CB4CEC.3070307@gmail.com> <20070821164350.18abecef@mentok.boston.redhat.com> Message-ID: <46CB51EC.7030501@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating wrote: > On Tue, 21 Aug 2007 13:37:00 -0700 > Toshio Kuratomi wrote: > >> Where it breaks down even for the cvsadmins is what to do when there >> are different owners on different package-branches. For instance, >> Foo is the owner in RHL8-FC2. Bar is the FC3-devel owner, and Baz is >> the EL5 owner. I don't think that admins will often want to change >> all of those. > > Actually that happens /very/ frequently within Red Hat engineering, > where packages as a whole are reassigned to a different maintainer. > I don't disagree with the idea of changing all the active branches when all the active branches belong to the same person. But when the active branches belong to different people I don't think you can assume that the intention is to set the owner on all branches. >> - --global could error out when it encounters such a situation.... But >> this is going to become more common because we probably don't want or >> need to change ownership on EOL releases. > > --global would just plain ignore EOL release branches. Don't ask don't tell WRT EOL branches could make sense and just error out on differences in active branches. - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGy1HsX6yAic2E7kgRAiM2AJ0aS1PNBeibAR+y1inaKc08We1MLACgrrg0 iy0IQQDtG40V+Od9YfsRwBM= =9F04 -----END PGP SIGNATURE----- From katzj at redhat.com Tue Aug 21 21:10:42 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 21 Aug 2007 17:10:42 -0400 Subject: Anyone want to own the mercurial package? Message-ID: <1187730642.4781.67.camel@localhost.localdomain> There's a pile of bugs filed against the mercurial package and I a) don't really have a whole lot of time and b) aren't really working on any projects using hg now. Do you have an interest in it, if so, let me know :-) Jeremy From jkeating at redhat.com Tue Aug 21 21:13:35 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 21 Aug 2007 17:13:35 -0400 Subject: Lots of pkgdb mail on commits list In-Reply-To: <46CB51EC.7030501@gmail.com> References: <200708211906.22500.ville.skytta@iki.fi> <46CB1539.7060206@gmail.com> <20070821124325.3442ff39@mentok.boston.redhat.com> <46CB4CEC.3070307@gmail.com> <20070821164350.18abecef@mentok.boston.redhat.com> <46CB51EC.7030501@gmail.com> Message-ID: <20070821171335.18b3eb91@ender> On Tue, 21 Aug 2007 13:58:20 -0700 Toshio Kuratomi wrote: > I don't disagree with the idea of changing all the active branches > when all the active branches belong to the same person. But when the > active branches belong to different people I don't think you can > assume that the intention is to set the owner on all branches. Unless all owners fall under the same sponsor/manager. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Tue Aug 21 21:24:49 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 21 Aug 2007 14:24:49 -0700 Subject: Lots of pkgdb mail on commits list In-Reply-To: <20070821171335.18b3eb91@ender> References: <200708211906.22500.ville.skytta@iki.fi> <46CB1539.7060206@gmail.com> <20070821124325.3442ff39@mentok.boston.redhat.com> <46CB4CEC.3070307@gmail.com> <20070821164350.18abecef@mentok.boston.redhat.com> <46CB51EC.7030501@gmail.com> <20070821171335.18b3eb91@ender> Message-ID: <46CB5821.70508@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating wrote: > On Tue, 21 Aug 2007 13:58:20 -0700 > Toshio Kuratomi wrote: > >> I don't disagree with the idea of changing all the active branches >> when all the active branches belong to the same person. But when the >> active branches belong to different people I don't think you can >> assume that the intention is to set the owner on all branches. > > Unless all owners fall under the same sponsor/manager. > Well... not really even then. This assumption works if the manager is handing out packages to workers to take care of. It does not work if a manager is in charge of people who are working on projects. - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGy1ghX6yAic2E7kgRAqFqAJ9bCYyUVQoy3OS/z85z9wGW3Go1cwCfYWrZ xJqnHjpzZM/68OvslqJHeRQ= =b52o -----END PGP SIGNATURE----- From ndbecker2 at gmail.com Tue Aug 21 23:58:07 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 21 Aug 2007 19:58:07 -0400 Subject: Anyone want to own the mercurial package? In-Reply-To: <1187730642.4781.67.camel@localhost.localdomain> References: <1187730642.4781.67.camel@localhost.localdomain> Message-ID: <200708211958.08018.ndbecker2@gmail.com> On Tuesday 21 August 2007, Jeremy Katz wrote: > There's a pile of bugs filed against the mercurial package and I a) > don't really have a whole lot of time and b) aren't really working on > any projects using hg now. Do you have an interest in it, if so, let me > know :-) > I use hg and have interest in it. I don't know the internals, but would be willing to work with upstream (I have followed this project for some time). From bugs.michael at gmx.net Wed Aug 22 08:32:02 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 22 Aug 2007 10:32:02 +0200 Subject: Don't rebuild licence updates for old dists Message-ID: <20070822103202.97a8cf35.bugs.michael@gmx.net> Some packagers not only check in the licence updates to older branches (F-7, FC-6, FC-5), they also submit build jobs for them. Please don't do that. If every packager does that for all packages, we would rebuild the entire distribution and flood our users with superfluous updates. From andreas.bierfert at lowlatency.de Wed Aug 22 08:59:22 2007 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Wed, 22 Aug 2007 10:59:22 +0200 Subject: build fails without reason, bug in plague? In-Reply-To: <46C6B59F.3070200@fedoraproject.org> References: <46C6B59F.3070200@fedoraproject.org> Message-ID: <20070822105922.66ac0215@alkaid.a.lan> On Sat, 18 Aug 2007 11:02:23 +0200 Marek Mahut wrote: > Hello maintainers, > > Today, I received an error that my build failed, but after deep look on > logs I found that there was no real reason why this build failed [1]. > Adel Gadllah told me that it isn't the first time it happens. > > Thoughts? > > [1] > http://buildsys.fedoraproject.org/logs/fedora-4-epel/35730-cvsweb-3.0.5-2.el4/noarch/ > Does this also fall in this build [1] category? Spec files for FC-6, F-7, EL-4, EL-5 and devel are the same and the build only seems to fail on devel :| - Andreas -- Andreas Bierfert, B.Sc. | 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 wolters.liste at gmx.net Wed Aug 22 12:28:36 2007 From: wolters.liste at gmx.net (Roland Wolters) Date: Wed, 22 Aug 2007 14:28:36 +0200 Subject: This list isn't working out. Or, why do we have fedora-devel and fedora-maintainers In-Reply-To: <20070821200915.GE28116@psilocybe.teonanacatl.org> References: <645d17210708211029y4717366pf927665eb37ec8e6@mail.gmail.com> <200708212143.30179.wolters.liste@gmx.net> <20070821200915.GE28116@psilocybe.teonanacatl.org> Message-ID: <200708221428.46398.wolters.liste@gmx.net> Once upon a time Todd Zullinger wrote: > Roland Wolters wrote: > > Well, I would totally agree with that - however, once or twice in > > the past I actually had questions regarding the maintaining of > > packages. And -devel is *no* option for me, I just don't have time > > to deal with that. > > > > So what should people like me (maintaining just a few packages) do? > > You could subscribe to fedora-devel-announce and fedora-devel-list. > Set your fedora-devel subscription to nomail so that you can still > post there (I'm assuming posting it restricted to subscribers, but if > I wasn't so lazy I'd verify that). That way you can still ask the > occasional question that you might have and then just check the > archives for replies (and/or ask to be CC:d). Hm, nice idea, thanks :) Roland -- "Aus Anonymit?tsgr?nden nennen wir sie Lisa S. Oder nein, doch lieber L. Simpson." -- Schuldirektor Skinner -------------- 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 mike.cohler at gmail.com Tue Aug 21 15:12:43 2007 From: mike.cohler at gmail.com (Mike Cohler) Date: Tue, 21 Aug 2007 16:12:43 +0100 Subject: Zod -> Moonshine -> ? Moonshine is a , is a Message-ID: <3dd77c60708210812j6eb6579i5c6029ffffaaa71@mail.gmail.com> Moutai is a Mandarin word meaning clear liqueur just like Moonshine Also moutai sounds almost the same as a Zulu word "muti" which refers to medicine - and fedora is a good medicine to cure woes with certain other OSes, but the word comes from the Zulu for "tree"... and the Fedora tree of development would fit nicely into this thread, and has international links as Fedora does! -- mike cohler From igorfoox at gmail.com Tue Aug 21 18:50:02 2007 From: igorfoox at gmail.com (Igor Foox) Date: Tue, 21 Aug 2007 14:50:02 -0400 Subject: FeatureEclipse33 Status In-Reply-To: <1187721530.4264.11.camel@toast.toronto.redhat.com> References: <1187112770.11441.17.camel@localhost.localdomain> <29c1e9a40708170613v3caa3d9bs88c72ce71ed8758d@mail.gmail.com> <1187721530.4264.11.camel@toast.toronto.redhat.com> Message-ID: <29c1e9a40708211150p36e21566h2b4ed9974e99f430@mail.gmail.com> Hey Ben, That sounds great, but I don't have access to fedora stuff atm, because I don't have all the certs set up. I don't think you need me to add you to the ACL, I believe you should be able to ask to be added. Of course I could be wrong. :) Igor On 8/21/07, Ben Konrath wrote: > On Fri, 2007-08-17 at 09:13 -0400, Igor Foox wrote: > > Hi all, > > > > On 8/14/07, Andrew Overholt wrote: > > > Hi, > > > > > > Here's the status of the Fedora 8 feature of updating the Eclipse stack > > > to the 3.3 (Europa) base [1]. I've CC'd all of the maintainers. Please > > > reply with answers where you can. > > > > > > PyDev (Igor Foox) > > > - Igor: can you update to latest version that works with 3.3? If not, > > > can you orphan it? Ben says he can take it over if you don't have time. > > > - would be nice to get Mylyn integration in when we update > > > > I won't have the time to update PyDev for this release unfortunately. > > I would appreciate it if Ben could take over for now. I will probably > > be able to take it back in a month or two. > > Ok, can you add me to the ACL and I'll update it for this release? Why > don't we say that we're co-maintaining pydev so that you can still help > out when you have time. > > Thanks, Ben > > From fnasser at redhat.com Wed Aug 22 15:09:02 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Wed, 22 Aug 2007 11:09:02 -0400 Subject: Jpackage: follow or lead? In-Reply-To: <870180fe0708210918x30a71086r9820d96568051e74@mail.gmail.com> References: <870180fe0708202120v23d3d224w69823123df3a273d@mail.gmail.com> <20070821093202.5532b5c8@weaponx.rchland.ibm.com> <870180fe0708210918x30a71086r9820d96568051e74@mail.gmail.com> Message-ID: <46CC518E.2000608@redhat.com> Jerry James wrote: > On 8/21/07, Josh Boyer wrote: >> asm2 is already in Fedora. It's just never been built. It's owner is >> Permaine Cheung (pcheung). > > Thanks for the information. I will contact Permaine. Hi, Do you know how backwards-compatible is this Asm 3.x version? In any case, I think we should go with a asm3 one. This end up being used by some software that require certification and changing the version used is always troublesome for their developers. I can get asm3 into JPackage 5.0, perhaps into the devel area and could even import it and build. But I suspect, even being a versioned package of asm, one would still have to propose it using the usual proceedure. regards, Fernando From loganjerry at gmail.com Wed Aug 22 15:31:24 2007 From: loganjerry at gmail.com (Jerry James) Date: Wed, 22 Aug 2007 09:31:24 -0600 Subject: Jpackage: follow or lead? In-Reply-To: <46CC518E.2000608@redhat.com> References: <870180fe0708202120v23d3d224w69823123df3a273d@mail.gmail.com> <20070821093202.5532b5c8@weaponx.rchland.ibm.com> <870180fe0708210918x30a71086r9820d96568051e74@mail.gmail.com> <46CC518E.2000608@redhat.com> Message-ID: <870180fe0708220831w14110c2cpf44ceb9aedaaceb2@mail.gmail.com> On 8/22/07, Fernando Nasser wrote: > Do you know how backwards-compatible is this Asm 3.x version? Well, there are changes to the API: http://asm.objectweb.org/jdiff223to30/changes.html Whether those changes affect any particular application will require examining that application, of course. In my case, I want to get findbugs [1] into Fedora, but current findbugs uses ASM 3.0, hence this thread. Permaine is working on getting the current jpackage.org asm2 package into Fedora, but there doesn't seem to be anyone working on ASM 3.0. > In any case, I think we should go with a asm3 one. This end up being > used by some software that require certification and changing the > version used is always troublesome for their developers. Yes. My worry is that with the current naming scheme, we will find ourselves making asm3 packages now, asm4 packages next year, asm5 packages after that, etc. I would think it would be better to have an asm-3.0 package now, and compat-asm-2.x versions if needed. However, that runs contrary to the jpackage naming scheme. > I can get asm3 into JPackage 5.0, perhaps into the devel area and could > even import it and build. > > But I suspect, even being a versioned package of asm, one would still > have to propose it using the usual proceedure. Right. I am certainly interested in seeing ASM 3.0 get into Fedora one way or another. Take that as an offer to help. :-) [1] http://findbugs.sourceforge.net/ -- Jerry James http://loganjerry.googlepages.com/ From loganjerry at gmail.com Wed Aug 22 15:46:40 2007 From: loganjerry at gmail.com (Jerry James) Date: Wed, 22 Aug 2007 09:46:40 -0600 Subject: 64-bit login available? Message-ID: <870180fe0708220846ib20f70j277cfa5be3f9bb34@mail.gmail.com> Due to a recent job change, I have lost access to some x86_64 Fedora machines. Now I just have my old personal computer, which is a 32-bit Pentium 4 machine. Once upon a time, I built up a small collection of RPMs, some of which I intended to migrate to Fedora [1]. Some had to be patched to build or operate correctly on 64-bit systems. I would still like to submit some of those packages, but I can no longer check the correctness of my 64-bit patches. Can anyone offer me a login on a 64-bit machine that I can use for that purpose, at least until I feel rich enough to upgrade my personal machine? I pledge to use such a login only for the purpose of developing 64-bit-related patches for Fedora-bound packages; patching unrelated to 64-bitness will be done on my own machine. I'm willing to sign something to that effect. I can also lend a hand with Fedora-related tasks in exchange. [1] http://jjames.fedorapeople.org/ Thanks, -- Jerry James http://loganjerry.googlepages.com/ From kevin at tummy.com Wed Aug 22 16:10:25 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Wed, 22 Aug 2007 10:10:25 -0600 Subject: 64-bit login available? In-Reply-To: <870180fe0708220846ib20f70j277cfa5be3f9bb34@mail.gmail.com> References: <870180fe0708220846ib20f70j277cfa5be3f9bb34@mail.gmail.com> Message-ID: <20070822101025.264e134b@ghistelwchlohm.scrye.com> On Wed, 22 Aug 2007 09:46:40 -0600 loganjerry at gmail.com ("Jerry James") wrote: > Due to a recent job change, I have lost access to some x86_64 Fedora > machines. Now I just have my old personal computer, which is a 32-bit > Pentium 4 machine. Once upon a time, I built up a small collection of > RPMs, some of which I intended to migrate to Fedora [1]. Some had to > be patched to build or operate correctly on 64-bit systems. I would > still like to submit some of those packages, but I can no longer check > the correctness of my 64-bit patches. Can anyone offer me a login on > a 64-bit machine that I can use for that purpose, at least until I > feel rich enough to upgrade my personal machine? I pledge to use such > a login only for the purpose of developing 64-bit-related patches for > Fedora-bound packages; patching unrelated to 64-bitness will be done > on my own machine. I'm willing to sign something to that effect. I > can also lend a hand with Fedora-related tasks in exchange. Sure, I can provide you access to a x86_64 rawhide test box... Will send details in private email. > [1] http://jjames.fedorapeople.org/ > > Thanks, kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fnasser at redhat.com Wed Aug 22 16:47:45 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Wed, 22 Aug 2007 12:47:45 -0400 Subject: asm3 [Was: Jpackage: follow or lead?] In-Reply-To: <870180fe0708220831w14110c2cpf44ceb9aedaaceb2@mail.gmail.com> References: <870180fe0708202120v23d3d224w69823123df3a273d@mail.gmail.com> <20070821093202.5532b5c8@weaponx.rchland.ibm.com> <870180fe0708210918x30a71086r9820d96568051e74@mail.gmail.com> <46CC518E.2000608@redhat.com> <870180fe0708220831w14110c2cpf44ceb9aedaaceb2@mail.gmail.com> Message-ID: <46CC68B1.4050209@redhat.com> Hi Jerry, Jerry James wrote: > On 8/22/07, Fernando Nasser wrote: >> Do you know how backwards-compatible is this Asm 3.x version? > > Well, there are changes to the API: > > http://asm.objectweb.org/jdiff223to30/changes.html > Yeah, certainly not a drop-in replacement.... > Whether those changes affect any particular application will require > examining that application, of course. In my case, I want to get > findbugs [1] into Fedora, but current findbugs uses ASM 3.0, hence > this thread. Permaine is working on getting the current jpackage.org > asm2 package into Fedora, but there doesn't seem to be anyone working > on ASM 3.0. > I think it is just because nobody asked for it I guess... findbugs uses bcel in the JPP build. BTW, why not using bcel? >> In any case, I think we should go with a asm3 one. This end up being >> used by some software that require certification and changing the >> version used is always troublesome for their developers. > > Yes. My worry is that with the current naming scheme, we will find > ourselves making asm3 packages now, asm4 packages next year, asm5 > packages after that, etc. I would think it would be better to have an > asm-3.0 package now, and compat-asm-2.x versions if needed. However, > that runs contrary to the jpackage naming scheme. > It wil all depend on upstream projects upgrading from asm 1.x and 2.x I guess, of some of us patching them to use the newer version instead. I'd still say we add an asm3 to JPP and import it in here. >> I can get asm3 into JPackage 5.0, perhaps into the devel area and could >> even import it and build. >> >> But I suspect, even being a versioned package of asm, one would still >> have to propose it using the usual proceedure. > > Right. I am certainly interested in seeing ASM 3.0 get into Fedora > one way or another. Take that as an offer to help. :-) > Let me see if I can build asm3 But I stil wonder why not use bcel, which we already have? BTW, have you looked at the findbugs package in JPP 5.0? > [1] http://findbugs.sourceforge.net/ From loganjerry at gmail.com Wed Aug 22 18:30:04 2007 From: loganjerry at gmail.com (Jerry James) Date: Wed, 22 Aug 2007 12:30:04 -0600 Subject: asm3 [Was: Jpackage: follow or lead?] In-Reply-To: <46CC68B1.4050209@redhat.com> References: <870180fe0708202120v23d3d224w69823123df3a273d@mail.gmail.com> <20070821093202.5532b5c8@weaponx.rchland.ibm.com> <870180fe0708210918x30a71086r9820d96568051e74@mail.gmail.com> <46CC518E.2000608@redhat.com> <870180fe0708220831w14110c2cpf44ceb9aedaaceb2@mail.gmail.com> <46CC68B1.4050209@redhat.com> Message-ID: <870180fe0708221130l59d93ea0o280c1fc54152fd12@mail.gmail.com> Thanks for the quick reply, Fernando. On 8/22/07, Fernando Nasser wrote: > Hi Jerry, > > Jerry James wrote: > > Whether those changes affect any particular application will require > > examining that application, of course. In my case, I want to get > > findbugs [1] into Fedora, but current findbugs uses ASM 3.0, hence > > this thread. Permaine is working on getting the current jpackage.org > > asm2 package into Fedora, but there doesn't seem to be anyone working > > on ASM 3.0. > > > > I think it is just because nobody asked for it I guess... findbugs uses > bcel in the JPP build. > > BTW, why not using bcel? The JPP build of findbugs is at version 0.9.6, before ASM support was added. The current version is 1.2.1. Building a current findbugs successfully will require one of the following: (1) Use the ASM jars that come with findbugs to build and either: (a) Install the ASM jars as part of the findbugs package until somebody complains; or (b) Don't install the ASM jars and somehow advertise that ASM support doesn't work so you'd better use BCEL (2) Patch findbugs to rip out all references to ASM. (3) Get ASM 3.0 into Fedora first. I think that (3) is the best option. > > Yes. My worry is that with the current naming scheme, we will find > > ourselves making asm3 packages now, asm4 packages next year, asm5 > > packages after that, etc. I would think it would be better to have an > > asm-3.0 package now, and compat-asm-2.x versions if needed. However, > > that runs contrary to the jpackage naming scheme. > > > > It wil all depend on upstream projects upgrading from asm 1.x and 2.x I > guess, of some of us patching them to use the newer version instead. > > I'd still say we add an asm3 to JPP and import it in here. Okay. > Let me see if I can build asm3 > > But I stil wonder why not use bcel, which we already have? Answered above. > BTW, have you looked at the findbugs package in JPP 5.0? Likewise. Thanks, -- Jerry James http://loganjerry.googlepages.com/ From fnasser at redhat.com Wed Aug 22 18:46:34 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Wed, 22 Aug 2007 14:46:34 -0400 Subject: asm3 [Was: Jpackage: follow or lead?] In-Reply-To: <870180fe0708221130l59d93ea0o280c1fc54152fd12@mail.gmail.com> References: <870180fe0708202120v23d3d224w69823123df3a273d@mail.gmail.com> <20070821093202.5532b5c8@weaponx.rchland.ibm.com> <870180fe0708210918x30a71086r9820d96568051e74@mail.gmail.com> <46CC518E.2000608@redhat.com> <870180fe0708220831w14110c2cpf44ceb9aedaaceb2@mail.gmail.com> <46CC68B1.4050209@redhat.com> <870180fe0708221130l59d93ea0o280c1fc54152fd12@mail.gmail.com> Message-ID: <46CC848A.8020602@redhat.com> Jerry James wrote: > Thanks for the quick reply, Fernando. > > On 8/22/07, Fernando Nasser wrote: >> Hi Jerry, >> >> Jerry James wrote: >>> Whether those changes affect any particular application will require >>> examining that application, of course. In my case, I want to get >>> findbugs [1] into Fedora, but current findbugs uses ASM 3.0, hence >>> this thread. Permaine is working on getting the current jpackage.org >>> asm2 package into Fedora, but there doesn't seem to be anyone working >>> on ASM 3.0. >>> >> I think it is just because nobody asked for it I guess... findbugs uses >> bcel in the JPP build. >> >> BTW, why not using bcel? > > The JPP build of findbugs is at version 0.9.6, before ASM support was > added. The current version is 1.2.1. Building a current findbugs > successfully will require one of the following: > > (1) Use the ASM jars that come with findbugs to build and either: > (a) Install the ASM jars as part of the findbugs package until somebody > complains; or > (b) Don't install the ASM jars and somehow advertise that ASM support > doesn't work so you'd better use BCEL > (2) Patch findbugs to rip out all references to ASM. > (3) Get ASM 3.0 into Fedora first. > > I think that (3) is the best option. > I totally agree. Let me start looking into the asm3 package. I have a release on Friday so this is not an easy week, but I will do my best. I am also interested in a newer findbugs for JPP 5.0 as well, and may ask you for some help with that. Regards, Fernando >>> Yes. My worry is that with the current naming scheme, we will find >>> ourselves making asm3 packages now, asm4 packages next year, asm5 >>> packages after that, etc. I would think it would be better to have an >>> asm-3.0 package now, and compat-asm-2.x versions if needed. However, >>> that runs contrary to the jpackage naming scheme. >>> >> It wil all depend on upstream projects upgrading from asm 1.x and 2.x I >> guess, of some of us patching them to use the newer version instead. >> >> I'd still say we add an asm3 to JPP and import it in here. > > Okay. > >> Let me see if I can build asm3 >> >> But I stil wonder why not use bcel, which we already have? > > Answered above. > >> BTW, have you looked at the findbugs package in JPP 5.0? > > Likewise. Thanks, From jorton at redhat.com Wed Aug 22 18:54:18 2007 From: jorton at redhat.com (Joe Orton) Date: Wed, 22 Aug 2007 19:54:18 +0100 Subject: expat soname bump & mass rebuilds In-Reply-To: <20070808161344.GA3946@redhat.com> References: <20070808161344.GA3946@redhat.com> Message-ID: <20070822185417.GA9375@redhat.com> Since the manual-mass-rebuild seems to be happening now, I am going to push the new expat & compat-expat1 into the repository today, so it's picked up by as many rebuilds as possible. joe From fnasser at redhat.com Wed Aug 22 19:08:43 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Wed, 22 Aug 2007 15:08:43 -0400 Subject: asm3 [Was: Jpackage: follow or lead?] In-Reply-To: <46CC848A.8020602@redhat.com> References: <870180fe0708202120v23d3d224w69823123df3a273d@mail.gmail.com> <20070821093202.5532b5c8@weaponx.rchland.ibm.com> <870180fe0708210918x30a71086r9820d96568051e74@mail.gmail.com> <46CC518E.2000608@redhat.com> <870180fe0708220831w14110c2cpf44ceb9aedaaceb2@mail.gmail.com> <46CC68B1.4050209@redhat.com> <870180fe0708221130l59d93ea0o280c1fc54152fd12@mail.gmail.com> <46CC848A.8020602@redhat.com> Message-ID: <46CC89BB.6000401@redhat.com> Is objectweb-asm OK for the Asm 3.0 package? An old request from some people I know from the ObjectWeb consortium. Regards, Fernando Fernando Nasser wrote: > Jerry James wrote: >> Thanks for the quick reply, Fernando. >> >> On 8/22/07, Fernando Nasser wrote: >>> Hi Jerry, >>> >>> Jerry James wrote: >>>> Whether those changes affect any particular application will require >>>> examining that application, of course. In my case, I want to get >>>> findbugs [1] into Fedora, but current findbugs uses ASM 3.0, hence >>>> this thread. Permaine is working on getting the current jpackage.org >>>> asm2 package into Fedora, but there doesn't seem to be anyone working >>>> on ASM 3.0. >>>> >>> I think it is just because nobody asked for it I guess... findbugs uses >>> bcel in the JPP build. >>> >>> BTW, why not using bcel? >> >> The JPP build of findbugs is at version 0.9.6, before ASM support was >> added. The current version is 1.2.1. Building a current findbugs >> successfully will require one of the following: >> >> (1) Use the ASM jars that come with findbugs to build and either: >> (a) Install the ASM jars as part of the findbugs package until >> somebody >> complains; or >> (b) Don't install the ASM jars and somehow advertise that ASM support >> doesn't work so you'd better use BCEL >> (2) Patch findbugs to rip out all references to ASM. >> (3) Get ASM 3.0 into Fedora first. >> >> I think that (3) is the best option. >> > > I totally agree. Let me start looking into the asm3 package. I have a > release on Friday so this is not an easy week, but I will do my best. > > I am also interested in a newer findbugs for JPP 5.0 as well, and may > ask you for some help with that. > > Regards, > Fernando > > > >>>> Yes. My worry is that with the current naming scheme, we will find >>>> ourselves making asm3 packages now, asm4 packages next year, asm5 >>>> packages after that, etc. I would think it would be better to have an >>>> asm-3.0 package now, and compat-asm-2.x versions if needed. However, >>>> that runs contrary to the jpackage naming scheme. >>>> >>> It wil all depend on upstream projects upgrading from asm 1.x and 2.x I >>> guess, of some of us patching them to use the newer version instead. >>> >>> I'd still say we add an asm3 to JPP and import it in here. >> >> Okay. >> >>> Let me see if I can build asm3 >>> >>> But I stil wonder why not use bcel, which we already have? >> >> Answered above. >> >>> BTW, have you looked at the findbugs package in JPP 5.0? >> >> Likewise. Thanks, > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From fnasser at redhat.com Wed Aug 22 20:06:43 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Wed, 22 Aug 2007 16:06:43 -0400 Subject: asm3 [Was: Jpackage: follow or lead?] In-Reply-To: <46CC89BB.6000401@redhat.com> References: <870180fe0708202120v23d3d224w69823123df3a273d@mail.gmail.com> <20070821093202.5532b5c8@weaponx.rchland.ibm.com> <870180fe0708210918x30a71086r9820d96568051e74@mail.gmail.com> <46CC518E.2000608@redhat.com> <870180fe0708220831w14110c2cpf44ceb9aedaaceb2@mail.gmail.com> <46CC68B1.4050209@redhat.com> <870180fe0708221130l59d93ea0o280c1fc54152fd12@mail.gmail.com> <46CC848A.8020602@redhat.com> <46CC89BB.6000401@redhat.com> Message-ID: <46CC9753.7060206@redhat.com> Jerry, please try this: http://fnasser.fedorapeople.org/objectweb-asm-3.0-1jpp.src.rpm Fernando Nasser wrote: > Is objectweb-asm OK for the Asm 3.0 package? An old request from some > people I know from the ObjectWeb consortium. > > Regards, > Fernando > > Fernando Nasser wrote: >> Jerry James wrote: >>> Thanks for the quick reply, Fernando. >>> >>> On 8/22/07, Fernando Nasser wrote: >>>> Hi Jerry, >>>> >>>> Jerry James wrote: >>>>> Whether those changes affect any particular application will require >>>>> examining that application, of course. In my case, I want to get >>>>> findbugs [1] into Fedora, but current findbugs uses ASM 3.0, hence >>>>> this thread. Permaine is working on getting the current jpackage.org >>>>> asm2 package into Fedora, but there doesn't seem to be anyone working >>>>> on ASM 3.0. >>>>> >>>> I think it is just because nobody asked for it I guess... findbugs >>>> uses >>>> bcel in the JPP build. >>>> >>>> BTW, why not using bcel? >>> >>> The JPP build of findbugs is at version 0.9.6, before ASM support was >>> added. The current version is 1.2.1. Building a current findbugs >>> successfully will require one of the following: >>> >>> (1) Use the ASM jars that come with findbugs to build and either: >>> (a) Install the ASM jars as part of the findbugs package until >>> somebody >>> complains; or >>> (b) Don't install the ASM jars and somehow advertise that ASM >>> support >>> doesn't work so you'd better use BCEL >>> (2) Patch findbugs to rip out all references to ASM. >>> (3) Get ASM 3.0 into Fedora first. >>> >>> I think that (3) is the best option. >>> >> >> I totally agree. Let me start looking into the asm3 package. I have >> a release on Friday so this is not an easy week, but I will do my best. >> >> I am also interested in a newer findbugs for JPP 5.0 as well, and may >> ask you for some help with that. >> >> Regards, >> Fernando >> >> >> >>>>> Yes. My worry is that with the current naming scheme, we will find >>>>> ourselves making asm3 packages now, asm4 packages next year, asm5 >>>>> packages after that, etc. I would think it would be better to have an >>>>> asm-3.0 package now, and compat-asm-2.x versions if needed. However, >>>>> that runs contrary to the jpackage naming scheme. >>>>> >>>> It wil all depend on upstream projects upgrading from asm 1.x and 2.x I >>>> guess, of some of us patching them to use the newer version instead. >>>> >>>> I'd still say we add an asm3 to JPP and import it in here. >>> >>> Okay. >>> >>>> Let me see if I can build asm3 >>>> >>>> But I stil wonder why not use bcel, which we already have? >>> >>> Answered above. >>> >>>> BTW, have you looked at the findbugs package in JPP 5.0? >>> >>> Likewise. Thanks, >> >> -- >> Fedora-maintainers mailing list >> Fedora-maintainers at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-maintainers >> > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From a.badger at gmail.com Wed Aug 22 20:07:34 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 22 Aug 2007 13:07:34 -0700 Subject: Lots of pkgdb mail on commits list In-Reply-To: <1187715161.31667.160.camel@mccallum.corsepiu.local> References: <200708211906.22500.ville.skytta@iki.fi> <46CB1539.7060206@gmail.com> <1187715161.31667.160.camel@mccallum.corsepiu.local> Message-ID: <46CC9786.4060807@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ralf Corsepius wrote: > On Tue, 2007-08-21 at 09:39 -0700, Toshio Kuratomi wrote: >> The question is what to do about it? > Not sending them to commits@ at all. > That would be fine by me. Does anyone want the email to be delivered to the commits list? It's currently recorded in the database (but no interface for viewing the log yet) and sent to owner + watchers. Note that you will still get a fair amount of email when something happens to a branch you are watching/own until #3 and #1 are implemented. But you won't be getting it via commits-list as well. - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGzJeGX6yAic2E7kgRApvDAJ9Kmcg9rXX9RmMS7c/NlTfrB51IAQCgnnhn rvv03AfObqdX4OFc5YaXC/4= =qPoH -----END PGP SIGNATURE----- From a.badger at gmail.com Wed Aug 22 21:13:02 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 22 Aug 2007 14:13:02 -0700 Subject: Lots of pkgdb mail on commits list In-Reply-To: <200708212001.51268.ville.skytta@iki.fi> References: <200708211906.22500.ville.skytta@iki.fi> <46CB1539.7060206@gmail.com> <200708212001.51268.ville.skytta@iki.fi> Message-ID: <46CCA6DE.7020806@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ville Skytt? wrote: > 1-3 sound fine to me, but I'd also like to suggest considering either > directing the pkgdb messages to a completely separate list, or adding some > topic categories in mailman config for the commits list. > I've setup topics. To use them to stop delivery of PackageDB mail follow these steps: 1) Login to: https://www.redhat.com/mailman/options/fedora-extras-commits 3) Scroll down to the end. You are looking for: "Which topic categories would you like to subscribe to?" "Do you want to receive messages that do not match any topic filter?" 4) For topic categories, select "Package Commits" 5) For "receive messages that do not match any topic" select "Yes". This will give you all email to commits except those from the PackageDB, just like it was in the good old days. If you don't want to receive anything but Commits messages, you can select "No" for "receive messages that do not match any topic". Let me know how this works -- I'm going to be pushing down the priority of the other things that mitigate or solve this unless I hear that topics are unworkable (or someone sends me a patch :-) - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGzKbeX6yAic2E7kgRAtR5AJ9l2jyY44SR8CFI54HeW1yxZ1bXZgCdFIV3 E1rbsTZXQG/Nbsg9Fuhu28I= =zJkc -----END PGP SIGNATURE----- From robert at fedoraproject.org Wed Aug 22 21:18:27 2007 From: robert at fedoraproject.org (Robert Scheck) Date: Wed, 22 Aug 2007 23:18:27 +0200 Subject: Popt package split planning In-Reply-To: References: Message-ID: <20070822211827.GA13419@hurricane.linuxnetz.de> Good evening all, On Tue, 14 Aug 2007, Panu Matilainen wrote: > Thought I'd post this to -maintainers for potential discussion first before > going to -devel-announce... thank you to Panu at first. When is a good point to spam via -maintainers? Once the package got built? Before? Now? > To ease transition, starting from the next rawhide push, the popt package > that's still built from rpm.spec adds > Provides: popt-devel = %{version}-%{release} > so you can start adding the buildrequires for the packages needing it Hopefully everybody added the correct dependency. If not, do so otherwise your package will break at the next rebuild... > already. Once the new popt package is reviewed and published to > repositories, rpm will be changed to build against that and drop the > internal popt entirely. It's likely, that tomorrow will be the day, where popt will get rebuilt for the development branch (once CVS is done). After that, RPM needs to get the internal popt removed. > popt-1.12 (the new package in review) is supposed to be ABI and API > compatible to the current one (1.10.2.1) but a rebuild of depending > packages against the new version might not be a bad idea anyway... As from a diff, I can see nothing what would suppose any ABI or API change, but I'm no programmer. If there are concerns regarding this change, feel free to contact Panu or me, maybe we're able to help you ;-) Greetings, Robert From dkl at redhat.com Wed Aug 22 21:39:01 2007 From: dkl at redhat.com (Dave Lawrence) Date: Wed, 22 Aug 2007 17:39:01 -0400 Subject: Bugzilla Server Outage Announcement Message-ID: <46CCACF5.8040300@redhat.com> S E R V E R O U T A G E A N N O U N C E M E N T ================================================= Scheduled Date: 8/24/2007 Scheduled Time: 19:00 EDT (-0400) Estimated Time Required: 8-10 Hours Performed By: Red Hat Engineering Operations People/Groups Impacted: Bugzilla/Hardware Catalog Users Site/Services Affected: Bugzilla.redhat.com, Hardware.redhat.com Impact: Bugzilla/Hardware db and web will be completely unavailable until migration is complete. Description: We will be doing the final migration to a new external co-located Bugzilla environment. Changes - Now using native MySQL replication. Master w/ Slave hot backup - Now utilizing two fail over web servers - Login names lowercased: no longer permit mixed case. All duplicates have been removed. - Cookies: authentication has been modified since it is no longer possible to authenticate based on ip address. Everyone will need to re-login. Contact Please email us at bugzilla-owner at redhat.com if you have any concerns. From mmcgrath at redhat.com Thu Aug 23 03:11:47 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 22 Aug 2007 22:11:47 -0500 Subject: Orphaning packages Message-ID: <46CCFAF3.2070506@redhat.com> Doing a little house cleaning. In particular OTRS and BackupPC upstream have been doing some very cool things but I don't use those packages anymore and have been neglecting them. Orphaning: OTRS BackupPC sqlite2 -Mike From loganjerry at gmail.com Thu Aug 23 04:01:12 2007 From: loganjerry at gmail.com (Jerry James) Date: Wed, 22 Aug 2007 22:01:12 -0600 Subject: asm3 [Was: Jpackage: follow or lead?] In-Reply-To: <46CC9753.7060206@redhat.com> References: <870180fe0708202120v23d3d224w69823123df3a273d@mail.gmail.com> <20070821093202.5532b5c8@weaponx.rchland.ibm.com> <870180fe0708210918x30a71086r9820d96568051e74@mail.gmail.com> <46CC518E.2000608@redhat.com> <870180fe0708220831w14110c2cpf44ceb9aedaaceb2@mail.gmail.com> <46CC68B1.4050209@redhat.com> <870180fe0708221130l59d93ea0o280c1fc54152fd12@mail.gmail.com> <46CC848A.8020602@redhat.com> <46CC89BB.6000401@redhat.com> <46CC9753.7060206@redhat.com> Message-ID: <870180fe0708222101q7b358276ue5353a55c0f5abf@mail.gmail.com> Hi Fernando, On 8/22/07, Fernando Nasser wrote: > Jerry, please try this: > > http://fnasser.fedorapeople.org/objectweb-asm-3.0-1jpp.src.rpm Thanks! The package builds fine. It will take me a little time to try it out; I'll get back to you as soon as I can. I should note that the README.txt marked as documentation describes the source distribution, so is of little value in a binary RPM. Otherwise, it built and installed with no hassles. Regards, -- Jerry James http://loganjerry.googlepages.com/ From tibbs at math.uh.edu Thu Aug 23 07:07:48 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 23 Aug 2007 02:07:48 -0500 Subject: Summary of the 2007-08-21 Packaging Committee meeting Message-ID: Sorry for sending this notice out late this week; the summary has been in the wiki but I was having trouble with email access today. Meeting minutes and full logs of the packaging committee meeting which occurred on 2007-08-21 are online: http://fedoraproject.org/wiki/Packaging/Minutes http://fedoraproject.org/wiki/Packaging/Minutes20070821 Executive summary: No new guidelines this week as there was no FPC meeting last week. Issues pending FESCO ratification: * Guidelines for addons for the various versions of emacs: http://fedoraproject.org/wiki/PackagingDrafts/EmacsenAddOns Other discussion: * Whether the buildsys should fail builds that result in empty debuginfo packages. * What the License: tag actually applies to. - J< From pmatilai at redhat.com Thu Aug 23 07:31:05 2007 From: pmatilai at redhat.com (Panu Matilainen) Date: Thu, 23 Aug 2007 10:31:05 +0300 (EEST) Subject: Popt package split planning In-Reply-To: <20070822211827.GA13419@hurricane.linuxnetz.de> References: <20070822211827.GA13419@hurricane.linuxnetz.de> Message-ID: On Wed, 22 Aug 2007, Robert Scheck wrote: > Good evening all, > > On Tue, 14 Aug 2007, Panu Matilainen wrote: >> Thought I'd post this to -maintainers for potential discussion first before >> going to -devel-announce... > > thank you to Panu at first. When is a good point to spam via -maintainers? > Once the package got built? Before? Now? I'd say right now. And also drop a note to fedora-devel-announce. >> To ease transition, starting from the next rawhide push, the popt package >> that's still built from rpm.spec adds >> Provides: popt-devel = %{version}-%{release} >> so you can start adding the buildrequires for the packages needing it > > Hopefully everybody added the correct dependency. If not, do so otherwise > your package will break at the next rebuild... A quick grep of full up-to-date cvs tree shows that nobody did. Oh well... >> already. Once the new popt package is reviewed and published to >> repositories, rpm will be changed to build against that and drop the >> internal popt entirely. > > It's likely, that tomorrow will be the day, where popt will get rebuilt for > the development branch (once CVS is done). After that, RPM needs to get the > internal popt removed. Yup, mostly done and will be committing the changes to cvs in a moment to be ready for just make tag + build once the new popt goes in. - Panu - From jorton at redhat.com Thu Aug 23 09:30:41 2007 From: jorton at redhat.com (Joe Orton) Date: Thu, 23 Aug 2007 10:30:41 +0100 Subject: RFC: retire bazaar Message-ID: <20070823093041.GA24795@redhat.com> The bazaar build is broken because of the glibc open() changes, and now also because of the neon 0.27 API changes. Patches for these are trivial but the maintainer has orphaned the package. If anybody wants to take on maintenance of this package I can supply patches; otherwise I think we should retire it. joe From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Aug 23 10:35:30 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 23 Aug 2007 12:35:30 +0200 Subject: Orphaning or even removing xmms-skins Message-ID: <20070823123530.42b0c69b@python3.es.egwn.lan> Hi, I'm currently the maintainer of the xmms-skins package. It's a historical package, containing skins that used to be bundled in the xmms source rpm but split off as a sub-package. When the xmms package cleanup happened, they got split out in their own noarch package, which made much more sense. But... When trying to update the License field of the package, I realized that most (if not all) of the skins contained in the package : 1) Are *VERY* old 2) Do not contain any license information I could probably hunt down all of the original authors and ask them for license clarifications etc. but since many URLs (and possibly email addresses) from the docs in those skin archives aren't valid anymore, it wouldn't be that easy... and is probably not worth it. So if someone really wants to do this and take over the package, no problem for me, but otherwise I think the best will be to retire the package and/or remove it entirely from Fedora. My current thought, since the content is probably acceptable for Fedora (but in need of clarification) would be to retire the package, have it removed before Fedora 8, but leave it as-is for Fedora 7 and earlier, as it's not as if it contained any files clearly identified as having an incompatible license. Please yell if that doesn't seem like the right thing to do. Otherwise I'll be doing that in a few days. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.22.2-57.fc7 Load : 0.01 0.10 0.30 From a.badger at gmail.com Thu Aug 23 13:39:33 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 23 Aug 2007 06:39:33 -0700 Subject: RFC: retire bazaar In-Reply-To: <20070823093041.GA24795@redhat.com> References: <20070823093041.GA24795@redhat.com> Message-ID: <46CD8E15.30905@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joe Orton wrote: > The bazaar build is broken because of the glibc open() changes, and now > also because of the neon 0.27 API changes. Patches for these are > trivial but the maintainer has orphaned the package. > > If anybody wants to take on maintenance of this package I can supply > patches; otherwise I think we should retire it. > I would like to see it retired. AFAIK upstream has stopped development of bazaar 1.x in favor of bzr (will be bazaar 2.x) The naming has been a source of confusion for people wanting to try out bzr. - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGzY4VX6yAic2E7kgRAga2AJsHdbFJ8ohAaTBHelGlDZ+Sed9zYwCffTqn B1FuedtYhnBFCF3wKwnyCqE= =uzRa -----END PGP SIGNATURE----- From tsmetana at redhat.com Thu Aug 23 14:15:09 2007 From: tsmetana at redhat.com (=?UTF-8?B?VG9tw6HFoQ==?= Smetana) Date: Thu, 23 Aug 2007 16:15:09 +0200 Subject: gnomebaker ownership Message-ID: <20070823161509.b2ce33b4.tsmetana@redhat.com> Hi all, I'd take the gnomebaker package (orphaned since 21st Aug) if there are no objections. -- Tom?? Smetana Base OS Software Engineer, Red Hat RH IRC: #brno #devel #base-os -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Thu Aug 23 15:09:24 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Thu, 23 Aug 2007 18:09:24 +0300 Subject: Orphaning or even removing xmms-skins In-Reply-To: <20070823123530.42b0c69b@python3.es.egwn.lan> References: <20070823123530.42b0c69b@python3.es.egwn.lan> Message-ID: <200708231809.24608.ville.skytta@iki.fi> On Thursday 23 August 2007, Matthias Saou wrote: > When trying to update the License field of the package, I realized that > most (if not all) of the skins contained in the package : > 1) Are *VERY* old > 2) Do not contain any license information [...] > My current thought, since the content is probably acceptable for Fedora > (but in need of clarification) would be to retire the package, have it > removed before Fedora 8, but leave it as-is for Fedora 7 and earlier, > as it's not as if it contained any files clearly identified as having > an incompatible license. > > Please yell if that doesn't seem like the right thing to do. Otherwise > I'll be doing that in a few days. No objections. In fact, the exact same thing applies to the gkrellm-themes package, and I plan to invoke the same process for it. From jamatos at fc.up.pt Thu Aug 23 14:13:11 2007 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Thu, 23 Aug 2007 15:13:11 +0100 Subject: Ownership of packages (PyRTF, PyX and rman) Message-ID: <200708231513.11582.jamatos@fc.up.pt> Hi, I have been maintaining three packages PyRTF, PyX and rman ever since mpeters went AWOL. At the time to change the ownership it was enough to change the owners.txt file. I have not changed that file but now that pkgdb is working I would like to know what should I do to change the status of the packages. Regards, -- Jos? Ab?lio From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Aug 23 15:31:46 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 23 Aug 2007 17:31:46 +0200 Subject: Orphaning or even removing xmms-skins In-Reply-To: <200708231809.24608.ville.skytta@iki.fi> References: <20070823123530.42b0c69b@python3.es.egwn.lan> <200708231809.24608.ville.skytta@iki.fi> Message-ID: <20070823173146.685b4312@python3.es.egwn.lan> Ville Skytt? wrote : > On Thursday 23 August 2007, Matthias Saou wrote: > > > When trying to update the License field of the package, I realized that > > most (if not all) of the skins contained in the package : > > 1) Are *VERY* old > > 2) Do not contain any license information > [...] > > My current thought, since the content is probably acceptable for Fedora > > (but in need of clarification) would be to retire the package, have it > > removed before Fedora 8, but leave it as-is for Fedora 7 and earlier, > > as it's not as if it contained any files clearly identified as having > > an incompatible license. > > > > Please yell if that doesn't seem like the right thing to do. Otherwise > > I'll be doing that in a few days. > > No objections. In fact, the exact same thing applies to the gkrellm-themes > package, and I plan to invoke the same process for it. I don't use the xmms-skins anymore, but I definitely still use gkrellm, and always cycle through all the themes when I change desktop background, so I'd really like to see them stay. I'll try to have a look at gkrellm-themes and see if at least a few can be kept, then add some more from there little by little once licenses get added or clarified. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.22.2-57.fc7 Load : 1.35 1.13 0.93 From fnasser at redhat.com Thu Aug 23 15:50:16 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Thu, 23 Aug 2007 11:50:16 -0400 Subject: asm3 [Was: Jpackage: follow or lead?] In-Reply-To: <870180fe0708222101q7b358276ue5353a55c0f5abf@mail.gmail.com> References: <870180fe0708202120v23d3d224w69823123df3a273d@mail.gmail.com> <20070821093202.5532b5c8@weaponx.rchland.ibm.com> <870180fe0708210918x30a71086r9820d96568051e74@mail.gmail.com> <46CC518E.2000608@redhat.com> <870180fe0708220831w14110c2cpf44ceb9aedaaceb2@mail.gmail.com> <46CC68B1.4050209@redhat.com> <870180fe0708221130l59d93ea0o280c1fc54152fd12@mail.gmail.com> <46CC848A.8020602@redhat.com> <46CC89BB.6000401@redhat.com> <46CC9753.7060206@redhat.com> <870180fe0708222101q7b358276ue5353a55c0f5abf@mail.gmail.com> Message-ID: <46CDACB8.4090407@redhat.com> Jerry James wrote: > Hi Fernando, > > On 8/22/07, Fernando Nasser wrote: >> Jerry, please try this: >> >> http://fnasser.fedorapeople.org/objectweb-asm-3.0-1jpp.src.rpm > > Thanks! The package builds fine. It will take me a little time to > try it out; I'll get back to you as soon as I can. I should note that > the README.txt marked as documentation describes the source > distribution, so is of little value in a binary RPM. Otherwise, it > built and installed with no hassles. Regards, Right. I will try and add some real documentation (besides the javadoc) to the 2jpp revision. Regards, Fernando From a.badger at gmail.com Thu Aug 23 16:35:47 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 23 Aug 2007 09:35:47 -0700 Subject: Ownership of packages (PyRTF, PyX and rman) In-Reply-To: <200708231513.11582.jamatos@fc.up.pt> References: <200708231513.11582.jamatos@fc.up.pt> Message-ID: <46CDB763.4080701@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jos? Matos wrote: > Hi, > I have been maintaining three packages PyRTF, PyX and rman ever since mpeters > went AWOL. > > At the time to change the ownership it was enough to change the owners.txt > file. I have not changed that file but now that pkgdb is working I would like > to know what should I do to change the status of the packages. > A cvsadmin can orphan those packages and you can pick them up or they can reassign them to you directly. What parts of the AWOL process have been completed already? Do you need immediate access to some of the packages (because of closed commit acls or etc?) - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGzbdjX6yAic2E7kgRAllZAJ0f/X7dvoo24gzEnpFRq9uKmLvVTgCeLYqP 33y1k84dnkFu61UeVAnwnAs= =Cq8r -----END PGP SIGNATURE----- From bkonrath at redhat.com Thu Aug 23 16:46:27 2007 From: bkonrath at redhat.com (Ben Konrath) Date: Thu, 23 Aug 2007 12:46:27 -0400 Subject: FeatureEclipse33 Status In-Reply-To: <29c1e9a40708211150p36e21566h2b4ed9974e99f430@mail.gmail.com> References: <1187112770.11441.17.camel@localhost.localdomain> <29c1e9a40708170613v3caa3d9bs88c72ce71ed8758d@mail.gmail.com> <1187721530.4264.11.camel@toast.toronto.redhat.com> <29c1e9a40708211150p36e21566h2b4ed9974e99f430@mail.gmail.com> Message-ID: <1187887587.25375.1.camel@plug> On Tue, 2007-08-21 at 14:50 -0400, Igor Foox wrote: > Hey Ben, > > That sounds great, but I don't have access to fedora stuff atm, > because I don't have all the certs set up. I don't think you need me > to add you to the ACL, I believe you should be able to ask to be > added. Of course I could be wrong. :) Yep, you're wrong :) You have to to approve my requests for commit access here: https://admin.fedoraproject.org/pkgdb/ If you can't do this, let me know and I'll request to have the ownership of eclipse-pydev moved to me. Thanks, Ben > Igor > > On 8/21/07, Ben Konrath wrote: > > On Fri, 2007-08-17 at 09:13 -0400, Igor Foox wrote: > > > Hi all, > > > > > > On 8/14/07, Andrew Overholt wrote: > > > > Hi, > > > > > > > > Here's the status of the Fedora 8 feature of updating the Eclipse stack > > > > to the 3.3 (Europa) base [1]. I've CC'd all of the maintainers. Please > > > > reply with answers where you can. > > > > > > > > PyDev (Igor Foox) > > > > - Igor: can you update to latest version that works with 3.3? If not, > > > > can you orphan it? Ben says he can take it over if you don't have time. > > > > - would be nice to get Mylyn integration in when we update > > > > > > I won't have the time to update PyDev for this release unfortunately. > > > I would appreciate it if Ben could take over for now. I will probably > > > be able to take it back in a month or two. > > > > Ok, can you add me to the ACL and I'll update it for this release? Why > > don't we say that we're co-maintaining pydev so that you can still help > > out when you have time. > > > > Thanks, Ben > > > > From ville.skytta at iki.fi Thu Aug 23 18:53:40 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Thu, 23 Aug 2007 21:53:40 +0300 Subject: Orphaning or even removing xmms-skins In-Reply-To: <20070823173146.685b4312@python3.es.egwn.lan> References: <20070823123530.42b0c69b@python3.es.egwn.lan> <200708231809.24608.ville.skytta@iki.fi> <20070823173146.685b4312@python3.es.egwn.lan> Message-ID: <200708232153.40410.ville.skytta@iki.fi> On Thursday 23 August 2007, Matthias Saou wrote: > Ville Skytt? wrote : > > > > No objections. In fact, the exact same thing applies to the > > gkrellm-themes package, and I plan to invoke the same process for it. > > I don't use the xmms-skins anymore, but I definitely still use gkrellm, > and always cycle through all the themes when I change desktop > background, so I'd really like to see them stay. > > I'll try to have a look at gkrellm-themes and see if at least a few can > be kept, then add some more from there little by little once licenses > get added or clarified. Go ahead and assign the package yourself if you like. There are a couple of skins that do have some copyright notices included, and if you're inclined to look for more, I wouldn't mind it if ShinyMetal-Blue would stay ;) From packages at amiga-hardware.com Thu Aug 23 20:36:31 2007 From: packages at amiga-hardware.com (Ian Chapman) Date: Thu, 23 Aug 2007 21:36:31 +0100 Subject: possible open() problem again Message-ID: <46CDEFCF.7020608@amiga-hardware.com> Hi all, I'm wondering if any C guru can help with this. I've already fixed a few of my packages to use correct parameters when calling open() but this one is beyond my limited knowledge. I'm assuming this particular problem is related anyway. When compiling against devel I get: ... ... then mv -f ".deps/chains.Tpo" ".deps/chains.Plo"; else rm -f ".deps/chains.Tpo"; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -D_REENTRANT -D_GNU_SOURCE -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buf fer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -MT chains.lo -MD -MP -MF .deps/chains.Tpo -c chains.c -fPIC -DPIC -o .libs/chains .o chains.c:171: error: expected identifier or '(' before '__extension__' make[4]: *** [chains.lo] Error 1 make[4]: *** Waiting for unfinished jobs.... make[4]: Leaving directory `/builddir/build/BUILD/zvbi-0.2.25/src' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/builddir/build/BUILD/zvbi-0.2.25/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/builddir/build/BUILD/zvbi-0.2.25/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/builddir/build/BUILD/zvbi-0.2.25' make: *** [all] Error 2 The line it refers to is: int open(const char *pathname, int flags, ...) { va_list args; mode_t mode = 0; CHECK_INIT(); va_start(args, flags); if (flags & O_CREAT) { if (sizeof(int) >= sizeof(mode_t)) { mode = va_arg(args, int); } else { mode = va_arg(args, mode_t); } } va_end(args);# ... ... A work in progress SRPM (~770k) is available here, if anyone would be kind enough to have a look. Thanks. http://dribble.org.uk/reviews/zvbi-0.2.25-2.src.rpm -- Ian Chapman. From dominik at greysector.net Thu Aug 23 20:38:20 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 23 Aug 2007 22:38:20 +0200 Subject: possible open() problem again In-Reply-To: <46CDEFCF.7020608@amiga-hardware.com> References: <46CDEFCF.7020608@amiga-hardware.com> Message-ID: <20070823203820.GB17879@ryvius.pekin.waw.pl> On Thursday, 23 August 2007 at 22:36, Ian Chapman wrote: > Hi all, > > I'm wondering if any C guru can help with this. I've already fixed a few > of my packages to use correct parameters when calling open() but this > one is beyond my limited knowledge. I'm assuming this particular problem > is related anyway. When compiling against devel I get: > > > ... > ... > then mv -f ".deps/chains.Tpo" ".deps/chains.Plo"; else rm -f > ".deps/chains.Tpo"; exit 1; fi > gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -D_REENTRANT -D_GNU_SOURCE -O2 > -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > --param=ssp-buf > fer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables > -MT chains.lo -MD -MP -MF .deps/chains.Tpo -c chains.c -fPIC -DPIC -o > .libs/chains > .o > chains.c:171: error: expected identifier or '(' before '__extension__' > make[4]: *** [chains.lo] Error 1 > make[4]: *** Waiting for unfinished jobs.... > make[4]: Leaving directory `/builddir/build/BUILD/zvbi-0.2.25/src' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory `/builddir/build/BUILD/zvbi-0.2.25/src' > make[2]: *** [all] Error 2 > make[2]: Leaving directory `/builddir/build/BUILD/zvbi-0.2.25/src' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/builddir/build/BUILD/zvbi-0.2.25' > make: *** [all] Error 2 > > > > The line it refers to is: > > > > int open(const char *pathname, int flags, ...) > { > va_list args; > mode_t mode = 0; > > CHECK_INIT(); > > va_start(args, flags); > if (flags & O_CREAT) > { > if (sizeof(int) >= sizeof(mode_t)) > { > mode = va_arg(args, int); > } > else > { > mode = va_arg(args, mode_t); > } > } > va_end(args);# > ... > ... > If this function is not used outside that source file, try making it static. Otherwise rename it to something else. Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From jakub at redhat.com Thu Aug 23 20:43:19 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 23 Aug 2007 16:43:19 -0400 Subject: possible open() problem again In-Reply-To: <46CDEFCF.7020608@amiga-hardware.com> References: <46CDEFCF.7020608@amiga-hardware.com> Message-ID: <20070823204318.GZ2063@devserv.devel.redhat.com> On Thu, Aug 23, 2007 at 09:36:31PM +0100, Ian Chapman wrote: > > int open(const char *pathname, int flags, ...) When it defines its own open implementation, you should just prevent expanding it as function-like macro. So int (open)(const char *pathname, int flags, ...) { ... } Jakub From denis at poolshark.org Thu Aug 23 20:45:25 2007 From: denis at poolshark.org (Denis Leroy) Date: Thu, 23 Aug 2007 22:45:25 +0200 Subject: possible open() problem again In-Reply-To: <20070823204318.GZ2063@devserv.devel.redhat.com> References: <46CDEFCF.7020608@amiga-hardware.com> <20070823204318.GZ2063@devserv.devel.redhat.com> Message-ID: <46CDF1E5.5070805@poolshark.org> Jakub Jelinek wrote: > On Thu, Aug 23, 2007 at 09:36:31PM +0100, Ian Chapman wrote: >> >> int open(const char *pathname, int flags, ...) > > When it defines its own open implementation, you should just > prevent expanding it as function-like macro. > So > int (open)(const char *pathname, int flags, ...) > { > ... > } I can't help but cringe at this horrible open() macro hack we have to deal with now. I mean, this was perfectly legal C code and we can't compile it ?! From packages at amiga-hardware.com Thu Aug 23 20:58:14 2007 From: packages at amiga-hardware.com (Ian Chapman) Date: Thu, 23 Aug 2007 21:58:14 +0100 Subject: possible open() problem again In-Reply-To: <20070823204318.GZ2063@devserv.devel.redhat.com> References: <46CDEFCF.7020608@amiga-hardware.com> <20070823204318.GZ2063@devserv.devel.redhat.com> Message-ID: <46CDF4E6.1070909@amiga-hardware.com> Jakub Jelinek wrote: > When it defines its own open implementation, you should just > prevent expanding it as function-like macro. Thanks very much Jakub, that fixed it. In hindsight ISTR seeing this solution posted a week or so back. Doh! Much appreciated. -- Ian Chapman. From jakub at redhat.com Thu Aug 23 21:05:53 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 23 Aug 2007 17:05:53 -0400 Subject: possible open() problem again In-Reply-To: <46CDF1E5.5070805@poolshark.org> References: <46CDEFCF.7020608@amiga-hardware.com> <20070823204318.GZ2063@devserv.devel.redhat.com> <46CDF1E5.5070805@poolshark.org> Message-ID: <20070823210553.GA2063@devserv.devel.redhat.com> On Thu, Aug 23, 2007 at 10:45:25PM +0200, Denis Leroy wrote: > >So > >int (open)(const char *pathname, int flags, ...) > >{ > >... > >} > > I can't help but cringe at this horrible open() macro hack we have to > deal with now. I mean, this was perfectly legal C code and we can't > compile it ?! Well, ISO C doesn't cover fcntl.h, if it would, it would certainly not be a perfectly legal C code, as per ISO C99, 7.1.3/1. As fcntl.h is a POSIX header, you need to consider that standard and that standard says that this code is not perfectly legal. See http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_01.html#tag_02_01 http://www.opengroup.org/onlinepubs/009695399/basedefs/fcntl.h.html Jakub From jamatos at fc.up.pt Thu Aug 23 20:31:29 2007 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Thu, 23 Aug 2007 21:31:29 +0100 Subject: Ownership of packages (PyRTF, PyX and rman) In-Reply-To: <46CDB763.4080701@gmail.com> References: <200708231513.11582.jamatos@fc.up.pt> <46CDB763.4080701@gmail.com> Message-ID: <200708232131.29135.jamatos@fc.up.pt> On Thursday 23 August 2007 17:35:47 Toshio Kuratomi wrote: > A cvsadmin can orphan those packages and you can pick them up or they > can reassign them to you directly. OK. > What parts of the AWOL process have been completed already? I would guess all of them. :-) This happened more than one year ago. At the time I have added myself to cc and started maintaining the packages. Michael A. Peters (mpeters) maintained several packages https://admin.fedoraproject.org/pkgdb/users/packages/mpeters Searching back to the mailing list here are the important points: - After the general mass rebuild for FC6 there were packages not rebuilt (in the lot there were Michael's packages): http://marc.info/?l=fedora-extras-list&m=115861278717537&w=2 - I proposed to (co-)maintain some: http://marc.info/?l=fedora-extras-list&m=115868564015534&w=2 > Do you need immediate access to some of the > packages (because of closed commit acls or etc?) I have acl access to all of them. Since the original maintainer is absent I would like to take that role since that is what I have been doing for one year. :-) Until sometime ago that was not a problem, but now with pkgdb working this matters. > -Toshio -- Jos? Ab?lio From bugs.michael at gmx.net Thu Aug 23 22:05:18 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 24 Aug 2007 00:05:18 +0200 Subject: Lots of pkgdb mail on commits list In-Reply-To: <46CCA6DE.7020806@gmail.com> References: <200708211906.22500.ville.skytta@iki.fi> <46CB1539.7060206@gmail.com> <200708212001.51268.ville.skytta@iki.fi> <46CCA6DE.7020806@gmail.com> Message-ID: <20070824000518.1c81270e.bugs.michael@gmx.net> On Wed, 22 Aug 2007 14:13:02 -0700, Toshio Kuratomi wrote: > I've setup topics. To use them to stop delivery of PackageDB mail > follow these steps: > > 1) Login to: > https://www.redhat.com/mailman/options/fedora-extras-commits > > 3) Scroll down to the end. You are looking for: > "Which topic categories would you like to subscribe to?" > "Do you want to receive messages that do not match any topic filter?" > > 4) For topic categories, select "Package Commits" > > 5) For "receive messages that do not match any topic" select "Yes". > > This will give you all email to commits except those from the PackageDB, > just like it was in the good old days. If you don't want to receive > anything but Commits messages, you can select "No" for "receive messages > that do not match any topic". > > Let me know how this works -- I'm going to be pushing down the priority > of the other things that mitigate or solve this unless I hear that > topics are unworkable (or someone sends me a patch :-) There is no topic for the "fedora" cvs commits. From alan at redhat.com Thu Aug 23 22:29:35 2007 From: alan at redhat.com (Alan Cox) Date: Thu, 23 Aug 2007 18:29:35 -0400 Subject: possible open() problem again In-Reply-To: <46CDF1E5.5070805@poolshark.org> References: <46CDEFCF.7020608@amiga-hardware.com> <20070823204318.GZ2063@devserv.devel.redhat.com> <46CDF1E5.5070805@poolshark.org> Message-ID: <20070823222935.GA11286@devserv.devel.redhat.com> On Thu, Aug 23, 2007 at 10:45:25PM +0200, Denis Leroy wrote: > I can't help but cringe at this horrible open() macro hack we have to > deal with now. I mean, this was perfectly legal C code and we can't > compile it ?! Something like /* Stupid Fedora stuff, don't push upstream */ #undef open Works fine for turning FC8 back into a proper sane C environment From alan at redhat.com Thu Aug 23 22:34:29 2007 From: alan at redhat.com (Alan Cox) Date: Thu, 23 Aug 2007 18:34:29 -0400 Subject: possible open() problem again In-Reply-To: <20070823210553.GA2063@devserv.devel.redhat.com> References: <46CDEFCF.7020608@amiga-hardware.com> <20070823204318.GZ2063@devserv.devel.redhat.com> <46CDF1E5.5070805@poolshark.org> <20070823210553.GA2063@devserv.devel.redhat.com> Message-ID: <20070823223429.GC11286@devserv.devel.redhat.com> On Thu, Aug 23, 2007 at 05:05:53PM -0400, Jakub Jelinek wrote: > Well, ISO C doesn't cover fcntl.h, if it would, it would certainly not > be a perfectly legal C code, as per ISO C99, 7.1.3/1. > As fcntl.h is a POSIX header, you need to consider that standard > and that standard says that this code is not perfectly legal. Yes. And the ANSI C spec also makes structure assignment internally self-inconsistent, forbids using pointers out of the allocated range even for comparison and so on... That doesn't create an excuse for doing these things, and doing them breaks lots of code and annoys people. You'll figure this out when you try and push it in a product people pay for, and also that just about everything the idiot macro hack does can be done by a 1 line of perl search of the source trees. From sandeen at redhat.com Thu Aug 23 22:53:03 2007 From: sandeen at redhat.com (Eric Sandeen) Date: Thu, 23 Aug 2007 17:53:03 -0500 Subject: possible open() problem again In-Reply-To: <20070823223429.GC11286@devserv.devel.redhat.com> References: <46CDEFCF.7020608@amiga-hardware.com> <20070823204318.GZ2063@devserv.devel.redhat.com> <46CDF1E5.5070805@poolshark.org> <20070823210553.GA2063@devserv.devel.redhat.com> <20070823223429.GC11286@devserv.devel.redhat.com> Message-ID: <46CE0FCF.6080008@redhat.com> Alan Cox wrote: > On Thu, Aug 23, 2007 at 05:05:53PM -0400, Jakub Jelinek wrote: >> Well, ISO C doesn't cover fcntl.h, if it would, it would certainly not >> be a perfectly legal C code, as per ISO C99, 7.1.3/1. >> As fcntl.h is a POSIX header, you need to consider that standard >> and that standard says that this code is not perfectly legal. > > Yes. And the ANSI C spec also makes structure assignment internally > self-inconsistent, forbids using pointers out of the allocated range even > for comparison and so on... > > That doesn't create an excuse for doing these things, and doing them breaks > lots of code and annoys people. You'll figure this out when you try and > push it in a product people pay for, and also that just about everything > the idiot macro hack does can be done by a 1 line of perl search of the > source trees. Hm, in fact, *if* this is only for the F8 devel phase (is it?) then maybe an rpm macro in the prep phase to do that perl search would be less painful... Just a thought. -Eric From a.badger at gmail.com Thu Aug 23 23:00:24 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 23 Aug 2007 16:00:24 -0700 Subject: Lots of pkgdb mail on commits list In-Reply-To: <20070824000518.1c81270e.bugs.michael@gmx.net> References: <200708211906.22500.ville.skytta@iki.fi> <46CB1539.7060206@gmail.com> <200708212001.51268.ville.skytta@iki.fi> <46CCA6DE.7020806@gmail.com> <20070824000518.1c81270e.bugs.michael@gmx.net> Message-ID: <46CE1188.70501@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schwendt wrote: > On Wed, 22 Aug 2007 14:13:02 -0700, Toshio Kuratomi wrote: > >> I've setup topics. To use them to stop delivery of PackageDB mail >> follow these steps: >> >> 1) Login to: >> https://www.redhat.com/mailman/options/fedora-extras-commits >> >> 3) Scroll down to the end. You are looking for: >> "Which topic categories would you like to subscribe to?" >> "Do you want to receive messages that do not match any topic filter?" >> >> 4) For topic categories, select "Package Commits" >> >> 5) For "receive messages that do not match any topic" select "Yes". >> >> This will give you all email to commits except those from the PackageDB, >> just like it was in the good old days. If you don't want to receive >> anything but Commits messages, you can select "No" for "receive messages >> that do not match any topic". >> >> Let me know how this works -- I'm going to be pushing down the priority >> of the other things that mitigate or solve this unless I hear that >> topics are unworkable (or someone sends me a patch :-) > > There is no topic for the "fedora" cvs commits. > Craft me a regex and I'll add it. If you just want to get fedora cvs commits mail in addition to the Package Commits mail, there's now a topic to do that. - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGzhGIX6yAic2E7kgRAq73AJ0XB8s0w6k0e0giQ7z2KVl7u06snQCeL9OO EmvwVYM2v5plx+l96TkvV8o= =qC2L -----END PGP SIGNATURE----- From robert at fedoraproject.org Thu Aug 23 23:09:14 2007 From: robert at fedoraproject.org (Robert Scheck) Date: Fri, 24 Aug 2007 01:09:14 +0200 Subject: POPT got splitted out of RPM, please adjust your BuildRequires In-Reply-To: References: <20070822211827.GA13419@hurricane.linuxnetz.de> Message-ID: <20070823230914.GA32719@hurricane.linuxnetz.de> Hello everbody, popt, the C library for parsing command line parameters, is one of the few packages which was in the past included into rpm, but it is its own package and so it got split out now. Every package depending on popt has to buildrequire "popt-devel" in order to get build sucessfully. Unfortunately nobody of the package maintainers used the chance to add this requirement in the days after Panu Matilainen's initial announcement regarding this split-out. If you want to see, whether your package is affected, just check whether it currently depends on popt. If so, you've to add "BuildRequires: popt-devel" to your spec file. A more or less complete list of packages was created by Panu Matilainen and sent to fedora-maintainers mailing list some time ago. Greetings, Robert From jwboyer at jdub.homelinux.org Fri Aug 24 00:05:39 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 23 Aug 2007 19:05:39 -0500 Subject: possible open() problem again In-Reply-To: <46CE0FCF.6080008@redhat.com> References: <46CDEFCF.7020608@amiga-hardware.com> <20070823204318.GZ2063@devserv.devel.redhat.com> <46CDF1E5.5070805@poolshark.org> <20070823210553.GA2063@devserv.devel.redhat.com> <20070823223429.GC11286@devserv.devel.redhat.com> <46CE0FCF.6080008@redhat.com> Message-ID: <20070823190539.05b216fc@vader.jdub.homelinux.org> On Thu, 23 Aug 2007 17:53:03 -0500 Eric Sandeen wrote: > Alan Cox wrote: > > On Thu, Aug 23, 2007 at 05:05:53PM -0400, Jakub Jelinek wrote: > >> Well, ISO C doesn't cover fcntl.h, if it would, it would certainly not > >> be a perfectly legal C code, as per ISO C99, 7.1.3/1. > >> As fcntl.h is a POSIX header, you need to consider that standard > >> and that standard says that this code is not perfectly legal. > > > > Yes. And the ANSI C spec also makes structure assignment internally > > self-inconsistent, forbids using pointers out of the allocated range even > > for comparison and so on... > > > > That doesn't create an excuse for doing these things, and doing them breaks > > lots of code and annoys people. You'll figure this out when you try and > > push it in a product people pay for, and also that just about everything > > the idiot macro hack does can be done by a 1 line of perl search of the > > source trees. > > Hm, in fact, *if* this is only for the F8 devel phase (is it?) then > maybe an rpm macro in the prep phase to do that perl search would be > less painful... I think this will show up in upstream glibc 2.7 when it is released. josh From pmatilai at laiskiainen.org Fri Aug 24 06:25:57 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Fri, 24 Aug 2007 09:25:57 +0300 (EEST) Subject: POPT got splitted out of RPM, please adjust your BuildRequires In-Reply-To: <20070823230914.GA32719@hurricane.linuxnetz.de> References: <20070822211827.GA13419@hurricane.linuxnetz.de> <20070823230914.GA32719@hurricane.linuxnetz.de> Message-ID: On Fri, 24 Aug 2007, Robert Scheck wrote: > Hello everbody, > > popt, the C library for parsing command line parameters, is one of the few > packages which was in the past included into rpm, but it is its own package > and so it got split out now. > > Every package depending on popt has to buildrequire "popt-devel" in order > to get build sucessfully. Unfortunately nobody of the package maintainers > used the chance to add this requirement in the days after Panu Matilainen's > initial announcement regarding this split-out. > > If you want to see, whether your package is affected, just check whether it > currently depends on popt. If so, you've to add "BuildRequires: popt-devel" > to your spec file. A more or less complete list of packages was created by > Panu Matilainen and sent to fedora-maintainers mailing list some time ago. Here's the list, regenerated minutes ago in case something has changed. Before everybody goes adding BR's to their packages: I believe that large amount of these will be covered by a suitably placed "Requires: popt-devel" somewhere in GNOME -devel package(s) (possibly libgnome-devel, but I'm not sufficiently familiar with the GNOME stack to say if that's the right spot) instead of needing an explicit popt-devel BR. abiword-2.4.6-5.fc7.src.rpm agave-0.4.2-4.fc8.src.rpm alleyoop-0.9.3-2.fc6.src.rpm anaconda-11.3.0.19-1.src.rpm anjuta-2.2.0-2.fc8.src.rpm anjuta-gdl-0.7.3-1.fc7.src.rpm apt-0.5.15lorg3.92-2.fc8.src.rpm atomix-2.14.0-2.fc6.src.rpm autobuild-applet-1.0.3-3.fc7.src.rpm bacula-2.0.3-9.fc8.src.rpm balsa-2.3.17-1.fc8.src.rpm blam-1.8.3-7.fc8.src.rpm bluefish-1.0.7-1.fc7.src.rpm brasero-0.6.0-1.fc8.src.rpm bug-buddy-2.18.0-2.fc7.src.rpm buoh-0.8.2-2.fc7.src.rpm byzanz-0.1.1-4.fc6.src.rpm callweaver-1.2-0.1.rc3.svn2861.fc8.src.rpm celestia-1.4.1-7.fc7.src.rpm chkconfig-1.3.35-1.src.rpm chkfontpath-1.10.1-1.1.src.rpm compiz-0.5.2-6.0ec3ec.fc8.src.rpm conglomerate-0.9.1-3.fc7.src.rpm contact-lookup-applet-0.16-2.fc8.src.rpm contacts-0.7-1.fc8.src.rpm control-center-2.19.90-3.fc8.src.rpm cryptsetup-luks-1.0.5-4.fc8.src.rpm dasher-4.5.2-2.fc8.src.rpm dates-0.4.4-2.fc8.src.rpm deskbar-applet-2.19.5-1.fc8.src.rpm dia-0.96.1-2.fc8.src.rpm drivel-2.1.0-0.4.20060527cvs.fc7.src.rpm eds-feed-0.5.0-6.fc7.src.rpm eel2-2.19.90-1.fc8.src.rpm eiciel-0.9.4-1.fc7.src.rpm ekiga-2.0.9-1.fc7.src.rpm empathy-0.8-1.fc8.src.rpm eog-2.19.5-3.fc8.src.rpm epiphany-2.19.90-1.fc8.src.rpm etherape-0.9.7-5.fc7.src.rpm evince-0.9.3-5.fc8.src.rpm evolution-2.11.90-2.fc8.src.rpm evolution-bogofilter-0.2.0-5.fc7.src.rpm evolution-data-server-1.11.90-2.fc8.src.rpm evolution-exchange-2.11.90-1.fc8.src.rpm evolution-sharp-0.13.2-1.fc8.src.rpm evolution-webcal-2.10.0-1.fc7.src.rpm fast-user-switch-applet-2.18.0-1.fc8.src.rpm file-roller-2.19.90-1.fc8.src.rpm firefox-2.0.0.6-3.fc8.src.rpm firestarter-1.0.3-16.fc8.src.rpm flac123-0.0.11-1.fc8.src.rpm gai-0.5.10-10.fc7.src.rpm gai-pal-0.7-11.src.rpm gai-temp-0.1.1-8.src.rpm galeon-2.0.3-10.fc8.src.rpm gcdmaster-1.2.2-1.fc6.src.rpm gchempaint-0.8.2-2.fc8.src.rpm gconf-editor-2.18.0-1.fc7.src.rpm gdesklets-0.35.4-8.fc8.src.rpm gedit-2.19.90-1.fc8.src.rpm gedit-plugins-2.18.0-2.fc7.src.rpm genius-0.7.7-2.fc7.src.rpm ghex-2.19.90-1.src.rpm gimp-2.4.0-0.rc1.1.fc8.src.rpm glabels-2.0.4-6.fc8.src.rpm glade2-2.12.1-9.fc8.src.rpm glipper-0.95.1-2.fc7.src.rpm glom-1.5.2-1.fc8.src.rpm glunarclock-0.32.4-9.fc8.src.rpm gmrun-0.9.2-7.fc7.src.rpm gnome-applet-music-2.2.0-1.fc8.src.rpm gnome-applet-netspeed-0.14-1.fc8.src.rpm gnome-applets-2.19.1-7.fc8.src.rpm gnome-applet-sensors-1.8.1-3.fc8.src.rpm gnome-applet-timer-1.3.3-1.fc7.src.rpm gnome-applet-vm-0.1.2-2.fc7.src.rpm gnomebaker-0.6.0-4.fc8.src.rpm gnome-bluetooth-0.9.1-1.fc8.src.rpm gnome-build-0.1.4-2.fc7.src.rpm gnome-commander-1.2.4-3.fc8.src.rpm gnome-compiz-manager-0.10.4-1.fc8.src.rpm gnome-desktop-2.19.90-3.fc8.src.rpm gnome-games-2.19.90.1-1.fc8.src.rpm gnome-keyring-manager-2.18.0-3.fc8.src.rpm gnome-launch-box-0.4-3.fc8.src.rpm gnome-media-2.18.0-3.fc7.src.rpm gnome-mount-0.7-0.git20070725.1.fc8.src.rpm gnome-netstatus-2.12.1-1.fc7.src.rpm gnome-panel-2.19.6-1.fc8.src.rpm gnome-phone-manager-0.10-1.fc8.src.rpm gnome-pilot-2.0.15-5.fc7.src.rpm gnome-pilot-conduits-2.0.15-3.fc7.src.rpm gnome-power-manager-2.19.6-1.fc8.src.rpm gnome-python2-2.19.2-1.fc8.src.rpm gnome-python2-desktop-2.19.2-1.fc8.src.rpm gnome-python2-extras-2.19.1-4.fc8.src.rpm gnomeradio-1.6-3.fc6.src.rpm gnomescan-0.4.0.2-1.fc7.src.rpm gnome-screensaver-2.19.6-4.fc8.src.rpm gnome-session-2.19.90-1.fc8.src.rpm gnome-sharp-2.16.0-4.fc8.src.rpm gnome-spell-1.0.7-4.fc7.src.rpm gnomesword-2.2.3-4.fc8.src.rpm gnome-terminal-2.18.1-1.fc8.src.rpm gnome-translate-0.99-11.fc7.src.rpm gnome-utils-2.19.90-1.fc8.src.rpm gnome-volume-manager-2.17.0-7.fc7.src.rpm gnotime-2.2.2-7.fc6.src.rpm gnubiff-2.2.7-1.fc8.src.rpm gnucash-2.2.0-2.fc8.src.rpm gnumeric-1.6.3-9.fc8.src.rpm goffice04-0.4.2-1.fc8.src.rpm gok-1.3.1-1.fc8.src.rpm gossip-0.27-1.fc8.src.rpm gphoto2-2.4.0-1.fc8.src.rpm gphpedit-0.9.91-3.fc6.src.rpm gpp-0.6.6-3.fc6.src.rpm gpsim-0.22.0-3.fc7.src.rpm grhino-0.16.0-1.fc7.src.rpm grip-3.2.0-16.fc7.src.rpm gstm-1.2-6.fc7.src.rpm gsynaptics-0.9.12-2.fc8.src.rpm gthumb-2.10.5-2.fc8.src.rpm GtkAda-2.8.0-7.fc7.src.rpm gtkhtml3-3.15.90-1.fc8.src.rpm gtkhtml38-3.12.3-5.fc8.src.rpm gtkmathview-0.7.6-5.fc6.src.rpm gtk-qt-engine-0.70-5.20070811svn.fc8.src.rpm gtk-sharp-1.0.10-12.fc7.src.rpm gtranslator-1.1.7-3.fc8.src.rpm gtweakui-0.4.0-4.src.rpm gucharmap-1.10.0-1.fc7.src.rpm gweled-0.7-8.fc7.src.rpm gwget-0.99-1.fc8.src.rpm heliodor-0.2.1-2.fc8.src.rpm icewm-1.2.30-13.fc7.src.rpm icon-slicer-0.3-8.src.rpm im-chooser-0.4.1-3.fc8.src.rpm inkscape-0.45.1-1.fc7.src.rpm k3d-0.6.7.0-2.fc8.src.rpm keepalived-1.1.13-7.fc8.src.rpm krb5-auth-dialog-0.7-3.src.rpm ldapvi-1.7-1.fc8.src.rpm libbonoboui-2.19.6-1.fc8.src.rpm libdv-1.0.0-1.fc7.src.rpm libgail-gnome-1.19.5-1.fc8.src.rpm libgnome-2.19.1-4.fc8.src.rpm libgnome-java-2.12.4-6.fc7.src.rpm libgnomekbd-2.19.90-2.fc8.src.rpm libgnomemm26-2.18.0-1.src.rpm libgnomeprint22-2.18.1-1.fc8.src.rpm libgnomeui-2.19.1-1.fc8.src.rpm libgnomeuimm26-2.18.0-1.src.rpm libopensync-plugin-evolution2-0.22-1.fc7.src.rpm librsync-0.9.7-10.fc7.src.rpm libtomoe-gtk-0.6.0-1.fc8.src.rpm libuser-0.56.4-2.src.rpm lock-keys-applet-1.0-13.fc8.src.rpm logjam-4.5.3-9.fc7.1.src.rpm logrotate-3.7.6-1.fc8.src.rpm mail-notification-4.1-3.fc8.src.rpm mdbtools-0.6-0.3.cvs20051109.fc8.src.rpm mkinitrd-6.0.9-9.src.rpm monkey-bubble-0.4.0-7.fc8.src.rpm mugshot-1.1.49-1.fc8.src.rpm mysql-gui-tools-5.0r12-2.fc8.src.rpm nautilus-2.19.90-1.fc8.src.rpm nautilus-actions-1.4.1-1.fc8.src.rpm nautilus-cd-burner-2.19.6-1.fc8.src.rpm nautilus-open-terminal-0.8-1.fc8.src.rpm nautilus-python-0.4.3-4.fc7.src.rpm nautilus-search-tool-0.2.2-1.fc8.src.rpm nautilus-sendto-0.12-2.fc8.src.rpm nemiver-0.4.0-1.fc8.src.rpm net-snmp-5.4.1-1.fc8.src.rpm NetworkManager-0.6.5-9.fc8.src.rpm NetworkManager-openvpn-0.3.2-7.fc6.src.rpm NetworkManager-vpnc-0.6.4-4.fc8.src.rpm newt-0.52.7-2.fc8.src.rpm ocaml-lablgtk-2.6.0-8.20060908cvs.fc8.src.rpm OpenIPMI-2.0.11-2.fc8.src.rpm openpbx-1.2-3.rc3.svn2540.fc7.src.rpm openvrml-0.16.6-2.fc8.src.rpm oprofile-0.9.3-2.fc8.src.rpm ots-0.4.2-11.fc7.src.rpm padevchooser-0.9.4-0.2.svn20070816.fc8.src.rpm panelfm-1.2-2.fc7.1.src.rpm passwd-0.74-3.fc7.src.rpm perl-RPM2-0.67-2.fc7.src.rpm pidgin-2.1.0-2.fc8.src.rpm pilot-link-0.12.2-4.fc8.src.rpm planner-0.14.2-8.fc8.src.rpm PolicyKit-gnome-0.5-0.git20070731.4.fc8.src.rpm polyxmass-bin-0.9.3-2.fc6.src.rpm qalculate-gtk-0.9.6-1.fc8.src.rpm referencer-1.0.4-2.fc8.src.rpm resapplet-0.1.1-5.fc7.src.rpm rhgb-0.17.6-4.fc8.src.rpm rhythmbox-0.11.1-1.fc8.src.rpm rpm-4.4.2.1-8.fc8.src.rpm rsync-2.6.9-2.fc7.src.rpm ruby-gnome2-0.16.0-10.fc8.src.rpm samba-3.0.25b-3.fc8.src.rpm scim-tomoe-0.6.0-1.fc8.src.rpm seahorse-1.0.1-7.fc8.src.rpm seamonkey-1.1.3-6.fc8.src.rpm sound-juicer-2.19.3-1.fc8.src.rpm stardict-3.0.0-1.fc8.src.rpm synaptic-0.57.2-12.fc8.src.rpm synce-software-manager-0.9.0-7.fc6.src.rpm synce-trayicon-0.9.0-8.fc6.src.rpm system-config-securitylevel-1.7.0-5.1.fc8.src.rpm tasks-0.11-1.fc8.src.rpm totem-2.19.6-4.fc8.src.rpm tracker-0.6.1-1.fc8.src.rpm tsclient-0.150-2.fc8.src.rpm ttywatch-0.14-8.fc8.src.rpm tux-3.2.18-9.fc6.src.rpm uim-1.4.1-6.fc8.src.rpm usbsink-0.3.1-1.fc7.src.rpm util-linux-2.13-0.55.fc8.src.rpm v4l2-tool-1.0.2-2.fc7.src.rpm verbiste-0.1.20-1.fc7.src.rpm vino-2.19.90-1.fc8.src.rpm wbxml2-0.9.2-8.fc7.src.rpm workrave-1.8.4-3.fc7.src.rpm wp_tray-0.5.3-4.fc7.src.rpm xchat-gnome-0.18-2.fc8.src.rpm xfce4-xfapplet-plugin-0.1.0-3.fc7.src.rpm xsri-2.1.0-10.fc6.src.rpm yelp-2.19.90-1.fc8.src.rpm - Panu - From debarshi.ray at gmail.com Fri Aug 24 07:05:03 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Fri, 24 Aug 2007 12:35:03 +0530 Subject: gnomebaker ownership In-Reply-To: <20070823161509.b2ce33b4.tsmetana@redhat.com> References: <20070823161509.b2ce33b4.tsmetana@redhat.com> Message-ID: <3170f42f0708240005g3b0660c2n90aec13fca1ff99c@mail.gmail.com> > I'd take the gnomebaker package (orphaned since 21st Aug) if there are > no objections. You can mention your intent on http://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages too. Cheers, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From bugs.michael at gmx.net Fri Aug 24 08:15:45 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 24 Aug 2007 10:15:45 +0200 Subject: gnomebaker ownership In-Reply-To: <3170f42f0708240005g3b0660c2n90aec13fca1ff99c@mail.gmail.com> References: <20070823161509.b2ce33b4.tsmetana@redhat.com> <3170f42f0708240005g3b0660c2n90aec13fca1ff99c@mail.gmail.com> Message-ID: <20070824101545.93e0c050.bugs.michael@gmx.net> On Fri, 24 Aug 2007 12:35:03 +0530, Debarshi 'Rishi' Ray wrote: > > I'd take the gnomebaker package (orphaned since 21st Aug) if there are > > no objections. > > You can mention your intent on > http://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages too. We should kill that page. It doesn't match the activity in the pkgdb. From opensource at till.name Fri Aug 24 08:31:07 2007 From: opensource at till.name (Till Maas) Date: Fri, 24 Aug 2007 10:31:07 +0200 Subject: POPT got splitted out of RPM, please adjust your BuildRequires In-Reply-To: References: <20070823230914.GA32719@hurricane.linuxnetz.de> Message-ID: <200708241031.13510.opensource@till.name> On Fr August 24 2007, Panu Matilainen wrote: > Here's the list, regenerated minutes ago in case something has changed. Maybe you can generate the list with the FAS-username in the first column in sorted by it, this will it make easier for maintainers to identify their packages. But I do not know, how. > cryptsetup-luks-1.0.5-4.fc8.src.rpm I updated it and made a scratch rebuild, I noticed that the old one only required libpopt.so.0 (and a lot of not popt related stuff), but the new one also has a libpopt.so.0(LIBPOPT_0) requirement. Is this worth a rebuild? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From giallu at gmail.com Fri Aug 24 08:38:31 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Fri, 24 Aug 2007 10:38:31 +0200 Subject: POPT got splitted out of RPM, please adjust your BuildRequires In-Reply-To: References: <20070822211827.GA13419@hurricane.linuxnetz.de> <20070823230914.GA32719@hurricane.linuxnetz.de> Message-ID: On 8/24/07, Panu Matilainen wrote: > Before everybody goes adding BR's to their packages: I believe that large > amount of these will be covered by a suitably placed "Requires: > popt-devel" somewhere in GNOME -devel package(s) (possibly libgnome-devel, > but I'm not sufficiently familiar with the GNOME stack to say if that's > the right spot) instead of needing an explicit popt-devel BR. So, who's in charge for deciding how do we fix this? From nicolas.mailhot at laposte.net Fri Aug 24 08:55:07 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 24 Aug 2007 10:55:07 +0200 (CEST) Subject: POPT got splitted out of RPM, please adjust your BuildRequires In-Reply-To: References: <20070822211827.GA13419@hurricane.linuxnetz.de> <20070823230914.GA32719@hurricane.linuxnetz.de> Message-ID: <14234.192.54.193.51.1187945707.squirrel@rousalka.dyndns.org> Le Ven 24 ao?t 2007 10:38, Gianluca Sforna a ?crit : > On 8/24/07, Panu Matilainen wrote: > >> Before everybody goes adding BR's to their packages: I believe that >> large >> amount of these will be covered by a suitably placed "Requires: >> popt-devel" somewhere in GNOME -devel package(s) (possibly >> libgnome-devel, >> but I'm not sufficiently familiar with the GNOME stack to say if >> that's >> the right spot) instead of needing an explicit popt-devel BR. > > So, who's in charge for deciding how do we fix this? I'd ask the desktop list -- Nicolas Mailhot From z.kota at gmx.net Fri Aug 24 09:49:09 2007 From: z.kota at gmx.net (Zoltan Kota) Date: Fri, 24 Aug 2007 11:49:09 +0200 (CEST) Subject: RFC: retire bazaar In-Reply-To: <46CD8E15.30905@gmail.com> References: <20070823093041.GA24795@redhat.com> <46CD8E15.30905@gmail.com> Message-ID: On Thu, 23 Aug 2007, Toshio Kuratomi wrote: > Joe Orton wrote: > > The bazaar build is broken because of the glibc open() changes, and now > > also because of the neon 0.27 API changes. Patches for these are > > trivial but the maintainer has orphaned the package. > > > > If anybody wants to take on maintenance of this package I can supply > > patches; otherwise I think we should retire it. > > > I would like to see it retired. AFAIK upstream has stopped development > of bazaar 1.x in favor of bzr (will be bazaar 2.x) > > The naming has been a source of confusion for people wanting to try out bzr. Maybe we could keep it for the F8 lifetime at least?! Users then would have some more time for migration to bzr. Upstream we still use baz. (I will discuss the migration issue with the upstream developer anyway.) So if you agree, and nobody else wants to take it I can get the ownership (for a while). Joe, patches would be very welcome! ;-) Zoltan From paul at city-fan.org Fri Aug 24 10:31:03 2007 From: paul at city-fan.org (Paul Howarth) Date: Fri, 24 Aug 2007 11:31:03 +0100 Subject: POPT got splitted out of RPM, please adjust your BuildRequires In-Reply-To: <14234.192.54.193.51.1187945707.squirrel@rousalka.dyndns.org> References: <20070822211827.GA13419@hurricane.linuxnetz.de> <20070823230914.GA32719@hurricane.linuxnetz.de> <14234.192.54.193.51.1187945707.squirrel@rousalka.dyndns.org> Message-ID: <46CEB367.2000208@city-fan.org> Nicolas Mailhot wrote: > Le Ven 24 ao?t 2007 10:38, Gianluca Sforna a ?crit : >> On 8/24/07, Panu Matilainen wrote: >> >>> Before everybody goes adding BR's to their packages: I believe that >>> large >>> amount of these will be covered by a suitably placed "Requires: >>> popt-devel" somewhere in GNOME -devel package(s) (possibly >>> libgnome-devel, >>> but I'm not sufficiently familiar with the GNOME stack to say if >>> that's >>> the right spot) instead of needing an explicit popt-devel BR. >> So, who's in charge for deciding how do we fix this? > > I'd ask the desktop list /usr/include/libgnome-2.0/libgnome/gnome-program.h from libgnome-devel references popt.h, so I think libgnome-devel should indeed have the dependency on popt-devel (#254124). Paul. From ajackson at redhat.com Fri Aug 24 10:57:40 2007 From: ajackson at redhat.com (Adam Jackson) Date: Fri, 24 Aug 2007 06:57:40 -0400 Subject: possible open() problem again In-Reply-To: <20070823190539.05b216fc@vader.jdub.homelinux.org> References: <46CDEFCF.7020608@amiga-hardware.com> <20070823204318.GZ2063@devserv.devel.redhat.com> <46CDF1E5.5070805@poolshark.org> <20070823210553.GA2063@devserv.devel.redhat.com> <20070823223429.GC11286@devserv.devel.redhat.com> <46CE0FCF.6080008@redhat.com> <20070823190539.05b216fc@vader.jdub.homelinux.org> Message-ID: <1187953060.1175.427.camel@localhost.localdomain> On Thu, 2007-08-23 at 19:05 -0500, Josh Boyer wrote: > On Thu, 23 Aug 2007 17:53:03 -0500 > Eric Sandeen wrote: > > Alan Cox wrote: > > > On Thu, Aug 23, 2007 at 05:05:53PM -0400, Jakub Jelinek wrote: > > >> Well, ISO C doesn't cover fcntl.h, if it would, it would certainly not > > >> be a perfectly legal C code, as per ISO C99, 7.1.3/1. > > >> As fcntl.h is a POSIX header, you need to consider that standard > > >> and that standard says that this code is not perfectly legal. > > > > > > Yes. And the ANSI C spec also makes structure assignment internally > > > self-inconsistent, forbids using pointers out of the allocated range even > > > for comparison and so on... > > > > > > That doesn't create an excuse for doing these things, and doing them breaks > > > lots of code and annoys people. You'll figure this out when you try and > > > push it in a product people pay for, and also that just about everything > > > the idiot macro hack does can be done by a 1 line of perl search of the > > > source trees. > > > > Hm, in fact, *if* this is only for the F8 devel phase (is it?) then > > maybe an rpm macro in the prep phase to do that perl search would be > > less painful... > > I think this will show up in upstream glibc 2.7 when it is released. That's sort of a tautology. glibc releases when Fedora releases, at this point. - ajax From bugs.michael at gmx.net Fri Aug 24 10:16:17 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 24 Aug 2007 12:16:17 +0200 Subject: Lots of pkgdb mail on commits list In-Reply-To: <46CE1188.70501@gmail.com> References: <200708211906.22500.ville.skytta@iki.fi> <46CB1539.7060206@gmail.com> <200708212001.51268.ville.skytta@iki.fi> <46CCA6DE.7020806@gmail.com> <20070824000518.1c81270e.bugs.michael@gmx.net> <46CE1188.70501@gmail.com> Message-ID: <20070824121617.6d4acd36.bugs.michael@gmx.net> On Thu, 23 Aug 2007 16:00:24 -0700, Toshio Kuratomi wrote: > >> I've setup topics. To use them to stop delivery of PackageDB mail > >> follow these steps: > >> > >> 1) Login to: > >> https://www.redhat.com/mailman/options/fedora-extras-commits > >> > >> 3) Scroll down to the end. You are looking for: > >> "Which topic categories would you like to subscribe to?" > >> "Do you want to receive messages that do not match any topic filter?" > >> > >> 4) For topic categories, select "Package Commits" > >> > >> 5) For "receive messages that do not match any topic" select "Yes". > >> > >> This will give you all email to commits except those from the PackageDB, > >> just like it was in the good old days. If you don't want to receive > >> anything but Commits messages, you can select "No" for "receive messages > >> that do not match any topic". > >> > >> Let me know how this works -- I'm going to be pushing down the priority > >> of the other things that mitigate or solve this unless I hear that > >> topics are unworkable (or someone sends me a patch :-) > > > > There is no topic for the "fedora" cvs commits. > > > Craft me a regex and I'll add it. The modules in fedora cvs don't have a common prefix, so only a complex and fragile negation would suffice. > If you just want to get fedora cvs commits mail in addition to the > Package Commits mail, there's now a topic to do that. It hasn't appeared on the mailman settings page yet, though. From ivazqueznet at gmail.com Fri Aug 24 11:26:16 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Fri, 24 Aug 2007 07:26:16 -0400 Subject: Lots of pkgdb mail on commits list In-Reply-To: <20070824121617.6d4acd36.bugs.michael@gmx.net> References: <200708211906.22500.ville.skytta@iki.fi> <46CB1539.7060206@gmail.com> <200708212001.51268.ville.skytta@iki.fi> <46CCA6DE.7020806@gmail.com> <20070824000518.1c81270e.bugs.michael@gmx.net> <46CE1188.70501@gmail.com> <20070824121617.6d4acd36.bugs.michael@gmx.net> Message-ID: <1187954776.21771.23.camel@ignacio.lan> On Fri, 2007-08-24 at 12:16 +0200, Michael Schwendt wrote: > On Thu, 23 Aug 2007 16:00:24 -0700, Toshio Kuratomi wrote: > > If you just want to get fedora cvs commits mail in addition to the > > Package Commits mail, there's now a topic to do that. > > It hasn't appeared on the mailman settings page yet, though. It has, but it's on fedora-extras-commits, not fedora-cvs-commits. Which brings up another question: Why do we have more than 1 commits mailing list? -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugs.michael at gmx.net Fri Aug 24 11:34:16 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 24 Aug 2007 13:34:16 +0200 Subject: Lots of pkgdb mail on commits list In-Reply-To: <1187954776.21771.23.camel@ignacio.lan> References: <200708211906.22500.ville.skytta@iki.fi> <46CB1539.7060206@gmail.com> <200708212001.51268.ville.skytta@iki.fi> <46CCA6DE.7020806@gmail.com> <20070824000518.1c81270e.bugs.michael@gmx.net> <46CE1188.70501@gmail.com> <20070824121617.6d4acd36.bugs.michael@gmx.net> <1187954776.21771.23.camel@ignacio.lan> Message-ID: <20070824133416.56408292.bugs.michael@gmx.net> On Fri, 24 Aug 2007 07:26:16 -0400, Ignacio Vazquez-Abrams wrote: > On Fri, 2007-08-24 at 12:16 +0200, Michael Schwendt wrote: > > On Thu, 23 Aug 2007 16:00:24 -0700, Toshio Kuratomi wrote: > > > If you just want to get fedora cvs commits mail in addition to the > > > Package Commits mail, there's now a topic to do that. > > > > It hasn't appeared on the mailman settings page yet, though. > > It has, but it's on fedora-extras-commits, not fedora-cvs-commits. I refer to fedora-extras-commits list. After a second look, perhaps Toshio wants me to subscribe to the "All cvs commits" topic, provided it does include the commits to fedora cvs. That might do the trick. From jwboyer at jdub.homelinux.org Fri Aug 24 11:58:35 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 24 Aug 2007 06:58:35 -0500 Subject: possible open() problem again In-Reply-To: <1187953060.1175.427.camel@localhost.localdomain> References: <46CDEFCF.7020608@amiga-hardware.com> <20070823204318.GZ2063@devserv.devel.redhat.com> <46CDF1E5.5070805@poolshark.org> <20070823210553.GA2063@devserv.devel.redhat.com> <20070823223429.GC11286@devserv.devel.redhat.com> <46CE0FCF.6080008@redhat.com> <20070823190539.05b216fc@vader.jdub.homelinux.org> <1187953060.1175.427.camel@localhost.localdomain> Message-ID: <20070824065835.28a94af3@vader.jdub.homelinux.org> On Fri, 24 Aug 2007 06:57:40 -0400 Adam Jackson wrote: > On Thu, 2007-08-23 at 19:05 -0500, Josh Boyer wrote: > > On Thu, 23 Aug 2007 17:53:03 -0500 > > Eric Sandeen wrote: > > > Alan Cox wrote: > > > > On Thu, Aug 23, 2007 at 05:05:53PM -0400, Jakub Jelinek wrote: > > > >> Well, ISO C doesn't cover fcntl.h, if it would, it would certainly not > > > >> be a perfectly legal C code, as per ISO C99, 7.1.3/1. > > > >> As fcntl.h is a POSIX header, you need to consider that standard > > > >> and that standard says that this code is not perfectly legal. > > > > > > > > Yes. And the ANSI C spec also makes structure assignment internally > > > > self-inconsistent, forbids using pointers out of the allocated range even > > > > for comparison and so on... > > > > > > > > That doesn't create an excuse for doing these things, and doing them breaks > > > > lots of code and annoys people. You'll figure this out when you try and > > > > push it in a product people pay for, and also that just about everything > > > > the idiot macro hack does can be done by a 1 line of perl search of the > > > > source trees. > > > > > > Hm, in fact, *if* this is only for the F8 devel phase (is it?) then > > > maybe an rpm macro in the prep phase to do that perl search would be > > > less painful... > > > > I think this will show up in upstream glibc 2.7 when it is released. > > That's sort of a tautology. glibc releases when Fedora releases, at > this point. Yes... my point was that this was going to be a _permanent_ change. Not "...only for the F8 devel phase". josh From jorton at redhat.com Fri Aug 24 12:21:21 2007 From: jorton at redhat.com (Joe Orton) Date: Fri, 24 Aug 2007 13:21:21 +0100 Subject: RFC: retire bazaar In-Reply-To: References: <20070823093041.GA24795@redhat.com> <46CD8E15.30905@gmail.com> Message-ID: <20070824122121.GA23085@redhat.com> On Fri, Aug 24, 2007 at 11:49:09AM +0200, Zoltan Kota wrote: > Maybe we could keep it for the F8 lifetime at least?! Users then would > have some more time for migration to bzr. Upstream we still use baz. > (I will discuss the migration issue with the upstream developer > anyway.) > > So if you agree, and nobody else wants to take it I can get the > ownership (for a while). Joe, patches would be very welcome! ;-) Attached. -------------- next part -------------- --- thelove at canonical.com---dists--bazaar--1.4/src/hackerlab/vu/vu.c.macropen 2005-06-20 23:00:03.000000000 +0100 +++ thelove at canonical.com---dists--bazaar--1.4/src/hackerlab/vu/vu.c 2007-08-09 09:21:27.000000000 +0100 @@ -939,7 +939,7 @@ int fd; handler = vu_path_dispatch (path); - fd = handler->vtable->open(errn, path, flags, mode, handler->closure); + fd = (handler->vtable->open)(errn, path, flags, mode, handler->closure); if (fd >= 0) { if ((ar_size (fd_handlers.void_ptr) <= fd) || !fd_handlers.hp [fd].vtable) -------------- next part -------------- --- thelove at canonical.com---dists--bazaar--1.4/src/baz/libarch/pfs-sftp.c.neon026 2005-06-20 22:59:37.000000000 +0100 +++ thelove at canonical.com---dists--bazaar--1.4/src/baz/libarch/pfs-sftp.c 2007-08-22 16:15:27.000000000 +0100 @@ -1496,7 +1496,7 @@ */ arch_uri_heuristics (&parsed_uri); - *user = str_save (0, parsed_uri.authinfo); + *user = str_save (0, parsed_uri.userinfo); *hostname = str_save (0, parsed_uri.host); if (parsed_uri.port) { --- thelove at canonical.com---dists--bazaar--1.4/src/baz/libarch/pfs.c.neon026 2007-08-22 16:15:27.000000000 +0100 +++ thelove at canonical.com---dists--bazaar--1.4/src/baz/libarch/pfs.c 2007-08-22 16:15:51.000000000 +0100 @@ -513,10 +513,10 @@ char *at_pos = str_chr_index (parsed_uri->host, '@'); if (!at_pos) return; - parsed_uri->authinfo = str_replace (parsed_uri->authinfo, - str_alloc_cat (0, parsed_uri->authinfo, "@")); - parsed_uri->authinfo = str_replace (parsed_uri->authinfo, - str_alloc_cat_n (0, parsed_uri->authinfo, parsed_uri->host, at_pos - parsed_uri->host)); + parsed_uri->userinfo = str_replace (parsed_uri->userinfo, + str_alloc_cat (0, parsed_uri->userinfo, "@")); + parsed_uri->userinfo = str_replace (parsed_uri->userinfo, + str_alloc_cat_n (0, parsed_uri->userinfo, parsed_uri->host, at_pos - parsed_uri->host)); parsed_uri->host = str_replace (parsed_uri->host, str_save (0, at_pos + 1)); } --- thelove at canonical.com---dists--bazaar--1.4/src/baz/libarch/tests/unit-sftp.c.neon026 2005-06-20 22:59:37.000000000 +0100 +++ thelove at canonical.com---dists--bazaar--1.4/src/baz/libarch/tests/unit-sftp.c 2007-08-22 16:15:27.000000000 +0100 @@ -44,7 +44,7 @@ invariant_str_cmp (parsed_uri.host, "email.com at host.phwoar"); arch_uri_heuristics (&parsed_uri); invariant_str_cmp (parsed_uri.host, "host.phwoar"); - invariant_str_cmp (parsed_uri.authinfo, "user at email.com"); + invariant_str_cmp (parsed_uri.userinfo, "user at email.com"); invariant_int_cmp (parsed_uri.port, 0); ne_uri_free(&parsed_uri); From jkeating at redhat.com Fri Aug 24 13:12:21 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 24 Aug 2007 09:12:21 -0400 Subject: Orphaning ipvsadm Message-ID: <20070824091221.150636a0@ender> This landed on me when the merge happened. The Red Hat owner does not wish to maintain it in Fedora as it may soon be removed from RHEL. I have no use for it, and it looks like the last upstream release was in 2005 ( http://www.linuxvirtualserver.org/software/ipvs.html ). If nobody claims it by the Feature Freeze (Tuesday) I'm going to dead.package it. It seems that ldirectord from the heartbeat package requires it, so perhaps Kevin you'd like to pick up ipvsadm? -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From z.kota at gmx.net Fri Aug 24 13:18:44 2007 From: z.kota at gmx.net (Zoltan Kota) Date: Fri, 24 Aug 2007 15:18:44 +0200 (CEST) Subject: RFC: retire bazaar In-Reply-To: <20070824122121.GA23085@redhat.com> References: <20070823093041.GA24795@redhat.com> <46CD8E15.30905@gmail.com> <20070824122121.GA23085@redhat.com> Message-ID: On Fri, 24 Aug 2007, Joe Orton wrote: > On Fri, Aug 24, 2007 at 11:49:09AM +0200, Zoltan Kota wrote: > > Maybe we could keep it for the F8 lifetime at least?! Users then would > > have some more time for migration to bzr. Upstream we still use baz. > > (I will discuss the migration issue with the upstream developer > > anyway.) > > > > So if you agree, and nobody else wants to take it I can get the > > ownership (for a while). Joe, patches would be very welcome! ;-) > > Attached. > Thanks! Should I follow the instructions of the wiki pages 'OrphanedPackages' and 'CVSAdminProcedure' to get ownership or through the PackageDB I can arrange everything. I haven't found any docs describing the use of pkgdb. Zoltan From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Aug 24 13:21:31 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 24 Aug 2007 15:21:31 +0200 Subject: Orphaning ipvsadm In-Reply-To: <20070824091221.150636a0@ender> References: <20070824091221.150636a0@ender> Message-ID: <20070824152131.4b815f34@python3.es.egwn.lan> Jesse Keating wrote : > This landed on me when the merge happened. The Red Hat owner does not > wish to maintain it in Fedora as it may soon be removed from RHEL. I > have no use for it, and it looks like the last upstream release was in > 2005 ( http://www.linuxvirtualserver.org/software/ipvs.html ). > > If nobody claims it by the Feature Freeze (Tuesday) I'm going to > dead.package it. > > It seems that ldirectord from the heartbeat package requires it, so > perhaps Kevin you'd like to pick up ipvsadm? I use LVS a lot. So I also use ipvsadm a lot. Is there another tool which I'm not aware of that obsoleted it or something? If not, I definitely don't want to see it go, and volunteer to take care of it! Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.22.2-57.fc7 Load : 2.08 2.04 1.57 From jkeating at redhat.com Fri Aug 24 13:24:12 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 24 Aug 2007 09:24:12 -0400 Subject: Orphaning ipvsadm In-Reply-To: <20070824152131.4b815f34@python3.es.egwn.lan> References: <20070824091221.150636a0@ender> <20070824152131.4b815f34@python3.es.egwn.lan> Message-ID: <20070824092412.20b92079@ender> On Fri, 24 Aug 2007 15:21:31 +0200 Matthias Saou wrote: > I use LVS a lot. So I also use ipvsadm a lot. Is there another tool > which I'm not aware of that obsoleted it or something? Not that I'm aware of. > If not, I > definitely don't want to see it go, and volunteer to take care of it! Ok, I'll assign it to you in pkgdb. It will need a rebuild for BuildID. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From alan at redhat.com Fri Aug 24 13:51:37 2007 From: alan at redhat.com (Alan Cox) Date: Fri, 24 Aug 2007 09:51:37 -0400 Subject: possible open() problem again In-Reply-To: <20070823190539.05b216fc@vader.jdub.homelinux.org> References: <46CDEFCF.7020608@amiga-hardware.com> <20070823204318.GZ2063@devserv.devel.redhat.com> <46CDF1E5.5070805@poolshark.org> <20070823210553.GA2063@devserv.devel.redhat.com> <20070823223429.GC11286@devserv.devel.redhat.com> <46CE0FCF.6080008@redhat.com> <20070823190539.05b216fc@vader.jdub.homelinux.org> Message-ID: <20070824135137.GA20061@devserv.devel.redhat.com> On Thu, Aug 23, 2007 at 07:05:39PM -0500, Josh Boyer wrote: > > Hm, in fact, *if* this is only for the F8 devel phase (is it?) then > > maybe an rpm macro in the prep phase to do that perl search would be > > less painful... > > I think this will show up in upstream glibc 2.7 when it is released. That will do wonders for the reputation of glibc. gcc 2.96 all over again Alan From rc040203 at freenet.de Fri Aug 24 14:12:06 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 24 Aug 2007 16:12:06 +0200 Subject: Downgrading OpenSceneGraph in rawhide? Message-ID: <1187964726.31667.601.camel@mccallum.corsepiu.local> Hi, Is it possible to downgrade a package or replace a package with an older version in rawhide without having to bump the epochs? Background Short version: I plan to replace OpenSceneGraph-2.0 with OpenSceneGraph-1.x and to add a OpenSceneGraph2 package in rawhide (similar to what gtk did during the gtk-1 -> gtk-2 transition), due to other packages still carrying deps on OpenSceneGraph-1.x Longer version: I pushed OpenSceneGraph-2.0 into rawhide (API/ABI/SONAME wise completely incompatible to OpenSceneGraph-1.x (as currently in FC-7) Unfortunately, for various reasons, other packages have not been/have not been able to upgraded to OpenSceneGraph-2.0, so far. This forces me to continue shipping OpenSceneGraph-1.x and OpenSceneGraph-2.0. Now, I am planning to introduce an OpenSceneGraph2 package (a modified version of the OpenSceneGraph package currently in Rawhide) and to replace OpenSceneGraph with a modified version of the OpenSceneGraph package in FC-7. Both packages's runtime-packages would be modified to be installable in parallel, but the *-devel packages would likely conflict. Ralf From sundaram at fedoraproject.org Fri Aug 24 14:16:25 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 24 Aug 2007 19:46:25 +0530 Subject: Downgrading OpenSceneGraph in rawhide? In-Reply-To: <1187964726.31667.601.camel@mccallum.corsepiu.local> References: <1187964726.31667.601.camel@mccallum.corsepiu.local> Message-ID: <46CEE839.3020406@fedoraproject.org> Ralf Corsepius wrote: > Hi, > > Is it possible to downgrade a package or replace a package with an older > version in rawhide without having to bump the epochs? > > > Background > > Short version: > > I plan to replace OpenSceneGraph-2.0 with OpenSceneGraph-1.x and to add > a OpenSceneGraph2 package in rawhide (similar to what gtk did during the > gtk-1 -> gtk-2 transition), due to other packages still carrying deps on > OpenSceneGraph-1.x > Couldn't you introduce a package named OpenSceneGraph1-x.y? It would be inconsistent with the packaging naming prevalent in the repository but it can be a way to avoid disrupting the existing packages and introducing epochs. Rahul From a.badger at gmail.com Fri Aug 24 14:23:13 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 24 Aug 2007 07:23:13 -0700 Subject: Lots of pkgdb mail on commits list In-Reply-To: <20070824121617.6d4acd36.bugs.michael@gmx.net> References: <200708211906.22500.ville.skytta@iki.fi> <46CB1539.7060206@gmail.com> <200708212001.51268.ville.skytta@iki.fi> <46CCA6DE.7020806@gmail.com> <20070824000518.1c81270e.bugs.michael@gmx.net> <46CE1188.70501@gmail.com> <20070824121617.6d4acd36.bugs.michael@gmx.net> Message-ID: <46CEE9D1.2050108@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schwendt wrote: > On Thu, 23 Aug 2007 16:00:24 -0700, Toshio Kuratomi wrote: >>>> Let me know how this works -- I'm going to be pushing down the priority >>>> of the other things that mitigate or solve this unless I hear that >>>> topics are unworkable (or someone sends me a patch :-) >>> There is no topic for the "fedora" cvs commits. >>> >> Craft me a regex and I'll add it. > > The modules in fedora cvs don't have a common prefix, so only a complex > and fragile negation would suffice. > >> If you just want to get fedora cvs commits mail in addition to the >> Package Commits mail, there's now a topic to do that. > > It hasn't appeared on the mailman settings page yet, though. > It's topic: "All cvs commits" - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGzunQX6yAic2E7kgRAr2hAJ0QQ6Z7yYTdAhb9OVIBml5iubdE4gCgpNMR WJMSzqXP9oZTnQFNoXDhdWo= =XseD -----END PGP SIGNATURE----- From rc040203 at freenet.de Fri Aug 24 14:41:31 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 24 Aug 2007 16:41:31 +0200 Subject: Downgrading OpenSceneGraph in rawhide? In-Reply-To: <46CEE839.3020406@fedoraproject.org> References: <1187964726.31667.601.camel@mccallum.corsepiu.local> <46CEE839.3020406@fedoraproject.org> Message-ID: <1187966491.31667.605.camel@mccallum.corsepiu.local> On Fri, 2007-08-24 at 19:46 +0530, Rahul Sundaram wrote: > Ralf Corsepius wrote: > > Hi, > > > > Is it possible to downgrade a package or replace a package with an older > > version in rawhide without having to bump the epochs? > > > > > > Background > > > > Short version: > > > > I plan to replace OpenSceneGraph-2.0 with OpenSceneGraph-1.x and to add > > a OpenSceneGraph2 package in rawhide (similar to what gtk did during the > > gtk-1 -> gtk-2 transition), due to other packages still carrying deps on > > OpenSceneGraph-1.x > > > > Couldn't you introduce a package named OpenSceneGraph1-x.y? No, this package name would be backward incompatible to FC-7. > It would be > inconsistent with the packaging naming prevalent in the repository but > it can be a way to avoid disrupting the existing packages and > introducing epochs. We are talking about rawhide. Ralf From a.badger at gmail.com Fri Aug 24 14:42:31 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 24 Aug 2007 07:42:31 -0700 Subject: RFC: retire bazaar In-Reply-To: References: <20070823093041.GA24795@redhat.com> <46CD8E15.30905@gmail.com> <20070824122121.GA23085@redhat.com> Message-ID: <46CEEE57.6030901@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Zoltan Kota wrote: > Should I follow the instructions of the wiki pages 'OrphanedPackages' and > 'CVSAdminProcedure' to get ownership or through the PackageDB I can > arrange everything. I haven't found any docs describing the use of pkgdb. > Pkgdb hasn't had an official announcement yet -- it's still beta testing. The easiest way to do this, though, is to have the current maintainer release ownership of the package in the packagedb. Then you can take ownership. This can all happen through the webUI. - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGzu5XX6yAic2E7kgRArINAKCgTQwpNUHt0iapRFFv53fdqKwTGwCcDVuk WaKfTJ9DNS5mvKjgKOWm3XQ= =T0EZ -----END PGP SIGNATURE----- From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Aug 24 14:51:24 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 24 Aug 2007 16:51:24 +0200 Subject: Orphaning ipvsadm In-Reply-To: <20070824092412.20b92079@ender> References: <20070824091221.150636a0@ender> <20070824152131.4b815f34@python3.es.egwn.lan> <20070824092412.20b92079@ender> Message-ID: <20070824165124.11eb3d3d@python3.es.egwn.lan> Jesse Keating wrote : > On Fri, 24 Aug 2007 15:21:31 +0200 > Matthias Saou > > wrote: > > > I use LVS a lot. So I also use ipvsadm a lot. Is there another tool > > which I'm not aware of that obsoleted it or something? > > Not that I'm aware of. > > > If not, I > > definitely don't want to see it go, and volunteer to take care of it! > > Ok, I'll assign it to you in pkgdb. It will need a rebuild for BuildID. Thanks! I gave the package a little comfort... it should be good as new ;-) I'll check if there are any open bugs against it and reassign them to me. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.22.2-57.fc7 Load : 0.32 0.29 0.27 From a.badger at gmail.com Fri Aug 24 16:24:25 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 24 Aug 2007 09:24:25 -0700 Subject: Ownership of packages (PyRTF, PyX and rman) In-Reply-To: <200708232131.29135.jamatos@fc.up.pt> References: <200708231513.11582.jamatos@fc.up.pt> <46CDB763.4080701@gmail.com> <200708232131.29135.jamatos@fc.up.pt> Message-ID: <46CF0639.5080707@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jos? Matos wrote: > On Thursday 23 August 2007 17:35:47 Toshio Kuratomi wrote: >> What parts of the AWOL process have been completed already? > > I would guess all of them. :-) > This happened more than one year ago. At the time I have added myself to cc > and started maintaining the packages. > > Michael A. Peters (mpeters) maintained several packages > https://admin.fedoraproject.org/pkgdb/users/packages/mpeters > > Searching back to the mailing list here are the important points: > > - After the general mass rebuild for FC6 there were packages not rebuilt (in > the lot there were Michael's packages): > http://marc.info/?l=fedora-extras-list&m=115861278717537&w=2 > > - I proposed to (co-)maintain some: > http://marc.info/?l=fedora-extras-list&m=115868564015534&w=2 > Done. I left mpeters on as a comaintainer. - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGzwY5X6yAic2E7kgRAupBAJ49M2YgoktYDRPssOtyyhM4K0XZIgCff/qR urHI01y2Vn6pYpTwu3DbC7g= =r2dM -----END PGP SIGNATURE----- From mmcgrath at redhat.com Fri Aug 24 16:32:45 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 24 Aug 2007 11:32:45 -0500 Subject: Default Buildroot and missing deps (awk) Message-ID: <46CF082D.3030908@redhat.com> The builders had awk disappear from the default buildroots this week and that has caused some issues. On the wiki we had two lists, one was the "Exceptions" list: http://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions The other was the FullExceptionsList: http://fedoraproject.org/wiki/Packaging/FullExceptionList?action=recall&rev=13 (previous version) The Exceptions list was explicit and the FullExceptionList was implicit. Unfortunately the implicit list is a moving target and as a result, caused the mistaken assumption that awk (and other binaries) would be there always. The minimal list does still exist on the Guidelines page. If you'd like something to be added or removed please send that request through FESCo as it could alter the way the binaries are made and ultimately decisions on a policy like that is up to them. The FullExceptionsList has been removed as it was misleading. Sorry for any inconvenience this has caused. -Mike From a.badger at gmail.com Fri Aug 24 16:45:41 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 24 Aug 2007 09:45:41 -0700 Subject: gnomebaker ownership In-Reply-To: <20070824101545.93e0c050.bugs.michael@gmx.net> References: <20070823161509.b2ce33b4.tsmetana@redhat.com> <3170f42f0708240005g3b0660c2n90aec13fca1ff99c@mail.gmail.com> <20070824101545.93e0c050.bugs.michael@gmx.net> Message-ID: <46CF0B35.90202@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schwendt wrote: > On Fri, 24 Aug 2007 12:35:03 +0530, Debarshi 'Rishi' Ray wrote: > >>> I'd take the gnomebaker package (orphaned since 21st Aug) if there are >>> no objections. >> You can mention your intent on >> http://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages too. > > We should kill that page. It doesn't match the activity in the pkgdb. > Is the page currently up to date? Should I sync orphaned status from there to the pkgdb before redirecting people? I'd like to replace the page with brief instructions on orphaning a package like: '''To orphan a package, log into the [https://admin.fedoraproject.org/pkgdb/users/packages/ Package Database] and select the package you want to orphan. Then hit the "Release Ownership" button for each active branch that you want to orphan. To take on an orphaned package, log into the package database and select the package you want to become the owner for. Then press the button to "Take Ownership". To see what packages are currently available, look at this list of [https://admin.fedoraproject.org/pkgdb/users/packages/orphan orphaned packages]. ''' -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGzws1X6yAic2E7kgRAgQ3AJ9b2vqb5J30hNLuGSvKNW3OjFUOvgCeJvHo GE5wCC/PsbkKDCGC8VOJ6pk= =a1Vy -----END PGP SIGNATURE----- From jwboyer at jdub.homelinux.org Fri Aug 24 16:46:54 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 24 Aug 2007 11:46:54 -0500 Subject: Default Buildroot and missing deps (awk) In-Reply-To: <46CF082D.3030908@redhat.com> References: <46CF082D.3030908@redhat.com> Message-ID: <20070824114654.60ba7556@weaponx.rchland.ibm.com> On Fri, 24 Aug 2007 11:32:45 -0500 Mike McGrath wrote: > The builders had awk disappear from the default buildroots this week and > that has caused some issues. On the wiki we had two lists, one was the > "Exceptions" list: > > http://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions > > The other was the FullExceptionsList: > > http://fedoraproject.org/wiki/Packaging/FullExceptionList?action=recall&rev=13 > (previous version) Did we ever figure out what changed to cause awk to disappear? josh From tibbs at math.uh.edu Fri Aug 24 17:16:18 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 24 Aug 2007 12:16:18 -0500 Subject: RFC: licensing issue with lft Message-ID: I picked up the lft (Layer Four Traceroute, http://pwhois.org/lft/) after it was orphaned a while back. I am not familiar with what happened to the package before I picked it up or how it made it into Fedora in the first place. Now there's a new version out, but also the license (the "VOSTROM Public License") is strange and had never been officially checked for acceptability in Fedora. The package also requires a rebuild to pick up the buildID changes. So, since the feature freeze is Tuesday, should I: Leave License: tag as is (even though it's not listed in the acceptable list) and push updated version to rawhide? Leave License: tag as is, push a plain rebuild to rawhide? Assume the license is non-free and remove the package from rawhide? - J< From tibbs at math.uh.edu Fri Aug 24 17:23:47 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 24 Aug 2007 12:23:47 -0500 Subject: RFC: licensing issue with lft In-Reply-To: References: Message-ID: >>>>> "JLT" == Jason L Tibbitts writes: JLT> but also the license (the "VOSTROM Public License") is strange JLT> and had never been officially checked for acceptability in JLT> Fedora. In case anyone wants to see the license, it't actually not on the upstream website but I've extracted it from the tarball: http://www.math.uh.edu/~tibbs/vostrom-license.txt - J< From sundaram at fedoraproject.org Fri Aug 24 17:28:45 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 24 Aug 2007 22:58:45 +0530 Subject: RFC: licensing issue with lft In-Reply-To: References: Message-ID: <46CF154D.9050605@fedoraproject.org> Jason L Tibbitts III wrote: >>>>>> "JLT" == Jason L Tibbitts writes: > > JLT> but also the license (the "VOSTROM Public License") is strange > JLT> and had never been officially checked for acceptability in > JLT> Fedora. > > In case anyone wants to see the license, it't actually not on the > upstream website but I've extracted it from the tarball: > http://www.math.uh.edu/~tibbs/vostrom-license.txt What do you think is strange about this license? Looks permissive to me. Rahul From tcallawa at redhat.com Fri Aug 24 17:33:38 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 24 Aug 2007 13:33:38 -0400 Subject: RFC: licensing issue with lft In-Reply-To: <46CF154D.9050605@fedoraproject.org> References: <46CF154D.9050605@fedoraproject.org> Message-ID: <1187976818.3439.885.camel@dhcp83-165.boston.redhat.com> On Fri, 2007-08-24 at 22:58 +0530, Rahul Sundaram wrote: > Jason L Tibbitts III wrote: > >>>>>> "JLT" == Jason L Tibbitts writes: > > > > JLT> but also the license (the "VOSTROM Public License") is strange > > JLT> and had never been officially checked for acceptability in > > JLT> Fedora. > > > > In case anyone wants to see the license, it't actually not on the > > upstream website but I've extracted it from the tarball: > > http://www.math.uh.edu/~tibbs/vostrom-license.txt > > What do you think is strange about this license? Looks permissive to me. Clauses 5 and 7 are problematic. It's been at the FSF for a while now, they're backlogged from us and IcedTea. ~spot From jamatos at fc.up.pt Fri Aug 24 16:39:36 2007 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Fri, 24 Aug 2007 17:39:36 +0100 Subject: Ownership of packages (PyRTF, PyX and rman) In-Reply-To: <46CF0639.5080707@gmail.com> References: <200708231513.11582.jamatos@fc.up.pt> <200708232131.29135.jamatos@fc.up.pt> <46CF0639.5080707@gmail.com> Message-ID: <200708241739.38518.jamatos@fc.up.pt> On Friday 24 August 2007 17:24:25 Toshio Kuratomi wrote: > Done. ?I left mpeters on as a comaintainer. OK. Thank you. :-) > -Toshio -- Jos? Ab?lio From bugs.michael at gmx.net Fri Aug 24 17:36:40 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 24 Aug 2007 19:36:40 +0200 Subject: gnomebaker ownership In-Reply-To: <46CF0B35.90202@gmail.com> References: <20070823161509.b2ce33b4.tsmetana@redhat.com> <3170f42f0708240005g3b0660c2n90aec13fca1ff99c@mail.gmail.com> <20070824101545.93e0c050.bugs.michael@gmx.net> <46CF0B35.90202@gmail.com> Message-ID: <20070824193640.3b172a0c.bugs.michael@gmx.net> On Fri, 24 Aug 2007 09:45:41 -0700, Toshio Kuratomi wrote: > >>> I'd take the gnomebaker package (orphaned since 21st Aug) if there are > >>> no objections. > >> You can mention your intent on > >> http://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages too. > > > > We should kill that page. It doesn't match the activity in the pkgdb. > > > Is the page currently up to date? See: https://www.redhat.com/archives/fedora-maintainers/2007-February/msg00598.html I'm not aware of anyone who has tried to keep the page, owners.list, bugzilla tickets, cvs and the repo in sync. > Should I sync orphaned status from > there to the pkgdb before redirecting people? cvs owners.list should be accurate up to 2007-02-20, and the green box on the page shows which orphans have been removed from the repos and disabled in %prep in cvs. After 2007-02-20 there is no guarantee that orphans have been marked as such in owners.list and have been added to the page. In the past there have been a few fruitless discussions about a policy on orphans. Objections against removing orphans from the repos, and we've only agreed on pruning extras-devel. Potentially unmaintained packages are not covered anywhere else. A flag in the pkgdb should be able do to that. > I'd like to replace the page with brief instructions on orphaning a > package like: > > '''To orphan a package, log into the > [https://admin.fedoraproject.org/pkgdb/users/packages/ Package Database] > and select the package you want to orphan. Then hit the "Release > Ownership" button for each active branch that you want to orphan. > > To take on an orphaned package, log into the package database and select > the package you want to become the owner for. Then press the button to > "Take Ownership". > > To see what packages are currently available, look at this list of > [https://admin.fedoraproject.org/pkgdb/users/packages/orphan orphaned > packages]. > ''' Go ahead with killing the Wiki list of orphans. The pkgdb should take over. From smooge at gmail.com Fri Aug 24 19:58:23 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 24 Aug 2007 13:58:23 -0600 Subject: RFC: licensing issue with lft In-Reply-To: <1187976818.3439.885.camel@dhcp83-165.boston.redhat.com> References: <46CF154D.9050605@fedoraproject.org> <1187976818.3439.885.camel@dhcp83-165.boston.redhat.com> Message-ID: <80d7e4090708241258m3ec1dc38waaac36c873866a99@mail.gmail.com> On 8/24/07, Tom spot Callaway wrote: > > On Fri, 2007-08-24 at 22:58 +0530, Rahul Sundaram wrote: > > Jason L Tibbitts III wrote: > > >>>>>> "JLT" == Jason L Tibbitts writes: > > > > > > JLT> but also the license (the "VOSTROM Public License") is strange > > > JLT> and had never been officially checked for acceptability in > > > JLT> Fedora. > > > > > > In case anyone wants to see the license, it't actually not on the > > > upstream website but I've extracted it from the tarball: > > > http://www.math.uh.edu/~tibbs/vostrom-license.txt > > > > What do you think is strange about this license? Looks permissive to me. > > Clauses 5 and 7 are problematic. It's been at the FSF for a while now, > they're backlogged from us and IcedTea. > I would vote pull from rawhide or revert to 'ok version' until settled. The functionality looks to be covered by the default tcptraceroute (which wasnt available) -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From debarshi.ray at gmail.com Fri Aug 24 20:04:16 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Sat, 25 Aug 2007 01:34:16 +0530 Subject: [cross posted] Taking over Straw Message-ID: <3170f42f0708241304n43383443m83fc59b937bc9d37@mail.gmail.com> https://admin.fedoraproject.org/pkgdb/packages/name/straw It looks like straw is orphaned in Fedora. I am interested in taking it over, if no one is already planning to do so. Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From a.badger at gmail.com Fri Aug 24 20:08:35 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 24 Aug 2007 13:08:35 -0700 Subject: Orphaned Package Page (was Re: gnomebaker ownership) In-Reply-To: <20070824193640.3b172a0c.bugs.michael@gmx.net> References: <20070823161509.b2ce33b4.tsmetana@redhat.com> <3170f42f0708240005g3b0660c2n90aec13fca1ff99c@mail.gmail.com> <20070824101545.93e0c050.bugs.michael@gmx.net> <46CF0B35.90202@gmail.com> <20070824193640.3b172a0c.bugs.michael@gmx.net> Message-ID: <46CF3AC3.5080301@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schwendt wrote: > > Go ahead with killing the Wiki list of orphans. The pkgdb should > take over. I've started the rewrite of this page: http://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages Some things to do: * Solicit feedback on the new strategy for unorphaning: In the past we had time frames for unorphaning packages. Packages that were orphaned less than a week ago needed to be given time between the announcement and taking of ownership. Packages orphaned for longer than three months needed to be re-reviewed. ATM, this is hard to do with the PackageDB. - We need to add log events for when a package was orphaned befor eit was imported into the packagedb. - We need to extract the Orphaned events from the log when we generate the list of orphaned/retired packages. - We need to display the date of the orphaning only on the orphaned pkgs page. Instead of doing this, I'd like to have a different policy. If the last update of the spec file (extractable via cvs log -r HEAD *.spec) is older than X months (for now, the page says 3), the package needs to be re-reviewed. Does this sound reasonable? * Mark the retired packages (from http://fedoraproject.org/wiki/Extras/RetiredPackages) as retired in the packagedb instead of orphaned. Then delete this page. * Sync entries from the orphan package list to the packagedb. When in doubt, send email to the package maintainer to make sure the package should be orphaned. After this is done, delete this list from the wiki. * Perhaps, formalize the procedure for Potentially unmaintained packages: Set yourself to be a comaintainer. Then orphan the package. - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGzzrDX6yAic2E7kgRAtOQAJ9VI60+5VPAP+k8RnuHnXWCZwsg8ACgl5sq qfEJMY6uuT1swbvFnvZU0kg= =JV55 -----END PGP SIGNATURE----- From debarshi.ray at gmail.com Fri Aug 24 20:23:25 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Sat, 25 Aug 2007 01:53:25 +0530 Subject: [cross posted] Taking over Sirius Message-ID: <3170f42f0708241323h44c27d72jedc061c0d09993d7@mail.gmail.com> https://admin.fedoraproject.org/pkgdb/packages/name/sirius It looks like sirius is orphaned in Fedora. I am interested in taking it over, if no one is already planning to do so. Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From ivazqueznet at gmail.com Fri Aug 24 20:43:19 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Fri, 24 Aug 2007 16:43:19 -0400 Subject: Downgrading OpenSceneGraph in rawhide? In-Reply-To: <1187966491.31667.605.camel@mccallum.corsepiu.local> References: <1187964726.31667.601.camel@mccallum.corsepiu.local> <46CEE839.3020406@fedoraproject.org> <1187966491.31667.605.camel@mccallum.corsepiu.local> Message-ID: <1187988199.21771.27.camel@ignacio.lan> On Fri, 2007-08-24 at 16:41 +0200, Ralf Corsepius wrote: > On Fri, 2007-08-24 at 19:46 +0530, Rahul Sundaram wrote: > > Couldn't you introduce a package named OpenSceneGraph1-x.y? > No, this package name would be backward incompatible to FC-7. How so? Name: OpenSceneGraph1 ... Obsoletes: OpenSceneGraph < 2 Packages depending on OSG1 and OSG should be pulling in by library, not package name anyways, correct? -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- 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 ivazqueznet at gmail.com Fri Aug 24 20:45:24 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Fri, 24 Aug 2007 16:45:24 -0400 Subject: Default Buildroot and missing deps (awk) In-Reply-To: <46CF082D.3030908@redhat.com> References: <46CF082D.3030908@redhat.com> Message-ID: <1187988324.21771.30.camel@ignacio.lan> On Fri, 2007-08-24 at 11:32 -0500, Mike McGrath wrote: > The Exceptions list was explicit and the FullExceptionList was > implicit. Can't we just remove the clause that states that we can assume that deps of packages in the Exceptions list are guaranteed to be there? If there are some packages that should *always* be there then we should add them to the Exceptions list directly. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Sat Aug 25 03:46:36 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 25 Aug 2007 05:46:36 +0200 Subject: Downgrading OpenSceneGraph in rawhide? In-Reply-To: <1187988199.21771.27.camel@ignacio.lan> References: <1187964726.31667.601.camel@mccallum.corsepiu.local> <46CEE839.3020406@fedoraproject.org> <1187966491.31667.605.camel@mccallum.corsepiu.local> <1187988199.21771.27.camel@ignacio.lan> Message-ID: <1188013597.31667.635.camel@mccallum.corsepiu.local> On Fri, 2007-08-24 at 16:43 -0400, Ignacio Vazquez-Abrams wrote: > On Fri, 2007-08-24 at 16:41 +0200, Ralf Corsepius wrote: > > On Fri, 2007-08-24 at 19:46 +0530, Rahul Sundaram wrote: > > > Couldn't you introduce a package named OpenSceneGraph1-x.y? > > No, this package name would be backward incompatible to FC-7. > > How so? > > Name: OpenSceneGraph1 > ... > Obsoletes: OpenSceneGraph < 2 This would only work for the run-time packages, but would not work for the devel packages. > Packages depending on OSG1 and OSG should be pulling in by library, not > package name anyways, correct? No, the problem is the *-devel packages: BuildRequires: OpenSceneGraph-devel Those packages which current break, expect OpenSceneGraph-devel to contain OSG-1 packages. Ralf From j.w.r.degoede at hhs.nl Sat Aug 25 06:09:32 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 25 Aug 2007 08:09:32 +0200 Subject: Downgrading OpenSceneGraph in rawhide? In-Reply-To: <1188013597.31667.635.camel@mccallum.corsepiu.local> References: <1187964726.31667.601.camel@mccallum.corsepiu.local> <46CEE839.3020406@fedoraproject.org> <1187966491.31667.605.camel@mccallum.corsepiu.local> <1187988199.21771.27.camel@ignacio.lan> <1188013597.31667.635.camel@mccallum.corsepiu.local> Message-ID: <46CFC79C.3090705@hhs.nl> Ralf Corsepius wrote: > On Fri, 2007-08-24 at 16:43 -0400, Ignacio Vazquez-Abrams wrote: >> On Fri, 2007-08-24 at 16:41 +0200, Ralf Corsepius wrote: >>> On Fri, 2007-08-24 at 19:46 +0530, Rahul Sundaram wrote: I say just put an epoch in there and be done with it, epoch's where invented for situations like this, they aren't pretty. But they aren't evil or something either, and they are a way better solution then the other hacks suggested. Regards, Hans From rc040203 at freenet.de Sat Aug 25 08:00:22 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 25 Aug 2007 10:00:22 +0200 Subject: Downgrading OpenSceneGraph in rawhide? In-Reply-To: <46CFC79C.3090705@hhs.nl> References: <1187964726.31667.601.camel@mccallum.corsepiu.local> <46CEE839.3020406@fedoraproject.org> <1187966491.31667.605.camel@mccallum.corsepiu.local> <1187988199.21771.27.camel@ignacio.lan> <1188013597.31667.635.camel@mccallum.corsepiu.local> <46CFC79C.3090705@hhs.nl> Message-ID: <1188028822.31667.674.camel@mccallum.corsepiu.local> On Sat, 2007-08-25 at 08:09 +0200, Hans de Goede wrote: > Ralf Corsepius wrote: > > On Fri, 2007-08-24 at 16:43 -0400, Ignacio Vazquez-Abrams wrote: > >> On Fri, 2007-08-24 at 16:41 +0200, Ralf Corsepius wrote: > >>> On Fri, 2007-08-24 at 19:46 +0530, Rahul Sundaram wrote: > > > > I say just put an epoch in there and be done with it, epoch's where invented > for situations like this, they aren't pretty. But they aren't evil or something > either, and they are a way better solution then the other hacks suggested. Well, there is another alternative: Not doing anything. Most of the packages, the upgrade to OSG-2 breaks, are dead upstream anyway, or can be build against OSG-2 with a couple of tweaks ;) Ralf From enrico.scholz at informatik.tu-chemnitz.de Sat Aug 25 09:22:12 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 25 Aug 2007 11:22:12 +0200 Subject: tor security updates In-Reply-To: <20070819111235.096e8a2c.bugs.michael@gmx.net> (Michael Schwendt's message of "Sun, 19 Aug 2007 11:12:35 +0200") References: <20070818190820.GB18032@psilocybe.teonanacatl.org> <20070818212257.90333b25.bugs.michael@gmx.net> <20070818193636.GC18032@psilocybe.teonanacatl.org> <20070819111235.096e8a2c.bugs.michael@gmx.net> Message-ID: <87y7g0hsu3.fsf@kosh.bigo.ensc.de> Michael Schwendt writes: > Enrico has had trouble before inside Bodhi, It simply does not work for me; probably due to some ad- and/or javascript blocking (although the javascript console does not report any error). E.g. the button right of the RPM name is always greyed out, I can only add comments, rest of form entries are read-only and I have only an 'Add comment' button but nothing which changes state of RPM. Afair, there was some discussion to move packages into the repository after 7 (??) days automatically, so I did not cared about it. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From andreas.bierfert at lowlatency.de Sat Aug 25 12:23:09 2007 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Sat, 25 Aug 2007 14:23:09 +0200 Subject: bodhi broken? Message-ID: <20070825142309.22ea7cc0@alkaid.a.lan> Hi, I when I try to add a new update into bodhi I get this message: 500 Internal error The server encountered an unexpected condition which prevented it from fulfilling the request. Would be nice if somebody could look at it :) Regards, Andreas -- Andreas Bierfert, B.Sc. | 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 adel.gadllah at gmail.com Sat Aug 25 12:24:15 2007 From: adel.gadllah at gmail.com (Adel Gadllah) Date: Sat, 25 Aug 2007 14:24:15 +0200 Subject: bodhi broken? In-Reply-To: <20070825142309.22ea7cc0@alkaid.a.lan> References: <20070825142309.22ea7cc0@alkaid.a.lan> Message-ID: <46D01F6F.50008@gmail.com> Andreas Bierfert wrote: > Hi, > > I when I try to add a new update into bodhi I get this message: > > 500 Internal error > > The server encountered an unexpected condition which prevented it from > fulfilling the request. > > Would be nice if somebody could look at it :) > It can be related to the fact that bugzilla is currently down (bodhi interacts with bugzilla) From tibbs at math.uh.edu Sat Aug 25 15:38:01 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 25 Aug 2007 10:38:01 -0500 Subject: RFC: licensing issue with lft In-Reply-To: <80d7e4090708241258m3ec1dc38waaac36c873866a99@mail.gmail.com> References: <46CF154D.9050605@fedoraproject.org> <1187976818.3439.885.camel@dhcp83-165.boston.redhat.com> <80d7e4090708241258m3ec1dc38waaac36c873866a99@mail.gmail.com> Message-ID: >>>>> "SJS" == Stephen John Smoogen writes: SJS> I would vote pull from rawhide or revert to 'ok version' until SJS> settled. There is no version which has a different license. - J< From sundaram at fedoraproject.org Sat Aug 25 15:40:25 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 25 Aug 2007 21:10:25 +0530 Subject: RFC: licensing issue with lft In-Reply-To: References: <46CF154D.9050605@fedoraproject.org> <1187976818.3439.885.camel@dhcp83-165.boston.redhat.com> <80d7e4090708241258m3ec1dc38waaac36c873866a99@mail.gmail.com> Message-ID: <46D04D69.4010702@fedoraproject.org> Jason L Tibbitts III wrote: >>>>>> "SJS" == Stephen John Smoogen writes: > > SJS> I would vote pull from rawhide or revert to 'ok version' until > SJS> settled. > > There is no version which has a different license. If the package has no other dependencies, pull it out till the license issue is resolved. Rahul From j.w.r.degoede at hhs.nl Sun Aug 26 07:22:17 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 26 Aug 2007 09:22:17 +0200 Subject: childsplay and childsplay_plugins license change Message-ID: <46D12A29.1060109@hhs.nl> Hi All, childsplay and childsplay_plugins have there license changed from GPLv2 to GPLv3. Regards, Hans From fedora at leemhuis.info Sun Aug 26 13:22:13 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 26 Aug 2007 15:22:13 +0200 Subject: EPEL report week 34 2007 Message-ID: <46D17E85.8010709@leemhuis.info> = Weekly EPEL Summary = Week 34/2007 == Most important happenings == * None == EPEL SIG Meeting == === Attending === >From the Steering Committee: * knurd (ThorstenLeemhuis) * mmcgrath (MikeMcGrath) * Jeff_S (Jeff Sheltren) * nirik (KevinFenzi) * stahnma (MichaelStahnke) Missing from the Steering Committee: * dgilmore (DennisGilmore) (missed it by a few minutes) * quaid (KarstenWade) === Summary === * EPEL Meeting|push to stable easily -- knurd * knurd talked to mschwendt about it but didn't find time for more yet; more work underway (which is in progress already when this report got written) * we'll make nirik a pusher as well to spread the burden of the work * new meeting time? -- all (see also http://fedoraproject.org/wiki/EPEL/NewMeetingTime ) * stahnma suggested to do alternating meetings (and not in the middle of the work-day), like some other Fedora groups. Another old idea mentioned earlier was to do bi-weekly meetings (maybe a mix of both?). Discuss further on the list. * Metadata for all Packages available to contributors. -- stahnma * The thread that was brought up about this is very interesting; basically, the EPEL community has no exact list of packages in RHEL/RHN proper; and even if we get a list of packages, we still need metadata; to see if we're conflicting with RH packages * some discussion around this; see log for full details; But its a complicated topic, so continue on the list * the new License tags and EPEL * nirik will consult spot how to handle the tags for EPEL and post to the list about it * is anybody reading the weekly reports? * some people said they do. But its a boring job, so tell me if I'm wasing my time ;-) === Full Log === https://www.redhat.com/archives/epel-devel-list/2007-August/msg00135.html == Stats == === General === Number of EPEL Contributors: unknown -- now that the pgkdb is in production it's not easily determinable for now (AFAIK) === EPEL 5 === Number of source packages: 597 Number of binary packages: 1156 There are 6 new Packages: * ccache | C/C++ compiler cache * cvsgraph | CVS/RCS repository grapher * libpqxx | C++ client API for PostgreSQL * nginx | Robust, small and high performance http and reverse proxy server * python-sqlalchemy | Modular and flexible ORM library for python * radiusclient-ng | RADIUS protocol client library === EPEL 4 === Number of source packages: 382 Number of binary packages: 785 There are 5 new Packages: * cvsgraph | A CVS/RCS repository grapher * libpqxx | C++ client API for PostgreSQL * nginx | Robust, small and high performance http and reverse proxy server * python-kid | Kid - A simple and pythonic XML template language * sqlite | Library that implements an embeddable SQL database engine ---- ["CategoryEPELReports"] From chris.stone at gmail.com Sun Aug 26 18:21:02 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Sun, 26 Aug 2007 11:21:02 -0700 Subject: Fwd: In-Reply-To: <200708260731.l7Q7VKTo015861@releng1.fedora.phx.redhat.com> References: <200708260731.l7Q7VKTo015861@releng1.fedora.phx.redhat.com> Message-ID: Can we please populate the CC list in the e-mails? The CC list should come from the owners.list CC field. Thanks. ---------- Forwarded message ---------- From: buildsys at fedoraproject.org Date: Aug 26, 2007 12:31 AM Subject: To: From: buildsys at fedoraproject.org To: xulchris at fedoraproject.org Cc: Subject: Broken dependencies: osgcal osgcal has broken dependencies in the development tree: On ppc: osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 On x86_64: osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) On i386: osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 Please resolve this as soon as possible. From jkeating at redhat.com Sun Aug 26 18:51:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 26 Aug 2007 14:51:36 -0400 Subject: Fwd: In-Reply-To: References: <200708260731.l7Q7VKTo015861@releng1.fedora.phx.redhat.com> Message-ID: <20070826145136.40d7b03c@ender> On Sun, 26 Aug 2007 11:21:02 -0700 "Christopher Stone" wrote: > Can we please populate the CC list in the e-mails? The CC list should > come from the owners.list CC field. git://git.fedoraproject.org/git/hosted/mash See utils/spam-o-matic . Patches gleefully reviewed (: owners.list is dead, all is driven from the pkgdb, so the spam-o-matic utility should either query pkgdb for each mail it will send, or if it's quicker just get a dump and build up a dictionary at the start and do lookups on the internal dictionary for each mail. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From chris.stone at gmail.com Sun Aug 26 19:01:13 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Sun, 26 Aug 2007 12:01:13 -0700 Subject: Fwd: In-Reply-To: <20070826145136.40d7b03c@ender> References: <200708260731.l7Q7VKTo015861@releng1.fedora.phx.redhat.com> <20070826145136.40d7b03c@ender> Message-ID: On 8/26/07, Jesse Keating wrote: > On Sun, 26 Aug 2007 11:21:02 -0700 > "Christopher Stone" wrote: > > > Can we please populate the CC list in the e-mails? The CC list should > > come from the owners.list CC field. > > git://git.fedoraproject.org/git/hosted/mash See utils/spam-o-matic . > Patches gleefully reviewed (: > > owners.list is dead, all is driven from the pkgdb, so the spam-o-matic > utility should either query pkgdb for each mail it will send, or if > it's quicker just get a dump and build up a dictionary at the start and > do lookups on the internal dictionary for each mail. Hi, I'm really pressed for time these days, can someone do this for me please? Thanks. From triad at df.lth.se Sun Aug 26 19:42:05 2007 From: triad at df.lth.se (Linus Walleij) Date: Sun, 26 Aug 2007 21:42:05 +0200 (CEST) Subject: This list isn't working out. Or, why do we have fedora-devel and fedora-maintainers In-Reply-To: <645d17210708211029y4717366pf927665eb37ec8e6@mail.gmail.com> References: <645d17210708211029y4717366pf927665eb37ec8e6@mail.gmail.com> Message-ID: On Tue, 21 Aug 2007, Jonathan Underwood wrote: > Can we either get a lot more disciplined > about pointing out when people are using the wrong list or (this would > be my choice) kill off fedora-maintainers. Can we please just kill it, it's confusing me too. Linus From smooge at gmail.com Sun Aug 26 23:20:52 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Sun, 26 Aug 2007 17:20:52 -0600 Subject: This list isn't working out. Or, why do we have fedora-devel and fedora-maintainers In-Reply-To: References: <645d17210708211029y4717366pf927665eb37ec8e6@mail.gmail.com> Message-ID: <80d7e4090708261620r9569fa5s8e4c377448cb2850@mail.gmail.com> On 8/26/07, Linus Walleij wrote: > On Tue, 21 Aug 2007, Jonathan Underwood wrote: > > > Can we either get a lot more disciplined > > about pointing out when people are using the wrong list or (this would > > be my choice) kill off fedora-maintainers. > > Can we please just kill it, it's confusing me too. > What lists should someone working with/for Fedora be subscribed to these days? Could we just have a fedora-memo-list and fedora-tech-list and be done with it? -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From jonathan.underwood at gmail.com Sun Aug 26 23:41:25 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 27 Aug 2007 00:41:25 +0100 Subject: This list isn't working out. Or, why do we have fedora-devel and fedora-maintainers In-Reply-To: <80d7e4090708261620r9569fa5s8e4c377448cb2850@mail.gmail.com> References: <645d17210708211029y4717366pf927665eb37ec8e6@mail.gmail.com> <80d7e4090708261620r9569fa5s8e4c377448cb2850@mail.gmail.com> Message-ID: <645d17210708261641w33787f0u98083c0d2089a25@mail.gmail.com> On 27/08/07, Stephen John Smoogen wrote: > On 8/26/07, Linus Walleij wrote: > > On Tue, 21 Aug 2007, Jonathan Underwood wrote: > > > > > Can we either get a lot more disciplined > > > about pointing out when people are using the wrong list or (this would > > > be my choice) kill off fedora-maintainers. > > > > Can we please just kill it, it's confusing me too. > > > > What lists should someone working with/for Fedora be subscribed to > these days? Could we just have a fedora-memo-list and fedora-tech-list > and be done with it? Those could/would be fedora-devel-announce and fedora-devel respectively if we were to get rid of fedora-mainters list (which so far noone seems to be speaking out against doing). From Christian.Iseli at licr.org Mon Aug 27 07:13:43 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Mon, 27 Aug 2007 09:13:43 +0200 Subject: EPEL report week 34 2007 In-Reply-To: <46D17E85.8010709@leemhuis.info> References: <46D17E85.8010709@leemhuis.info> Message-ID: <20070827091343.7d67b656@ludwig-alpha.unil.ch> On Sun, 26 Aug 2007 15:22:13 +0200, Thorsten Leemhuis wrote: > * is anybody reading the weekly reports? Yes I am. Helps me keep up to date with what is happening in EPEL. C From tsmetana at redhat.com Mon Aug 27 08:33:44 2007 From: tsmetana at redhat.com (=?UTF-8?B?VG9tw6HFoQ==?= Smetana) Date: Mon, 27 Aug 2007 10:33:44 +0200 Subject: gnomebaker ownership In-Reply-To: <20070824193640.3b172a0c.bugs.michael@gmx.net> References: <20070823161509.b2ce33b4.tsmetana@redhat.com> <3170f42f0708240005g3b0660c2n90aec13fca1ff99c@mail.gmail.com> <20070824101545.93e0c050.bugs.michael@gmx.net> <46CF0B35.90202@gmail.com> <20070824193640.3b172a0c.bugs.michael@gmx.net> Message-ID: <20070827103344.ae836a0a.tsmetana@redhat.com> On Fri, 24 Aug 2007 19:36:40 +0200 Michael Schwendt wrote: > > To see what packages are currently available, look at this list of > > [https://admin.fedoraproject.org/pkgdb/users/packages/orphan orphaned > > packages]. > > Go ahead with killing the Wiki list of orphans. The pkgdb should > take over. What is the key for a package to get to the list of orphans in pkgdb? I can see there is also "my" nmap, which is orphaned only in RHL8 and RHL9. But there's nothing I can do about that -- I think the ownership for these old releases can't be changed. Maybe the list should take only FC-6 and newer in account. And maybe it's only not generated as frequently as I thought... -- Tom?? Smetana Base OS Software Engineer, Red Hat RH IRC: #brno #devel #base-os From buc at odusz.so-cdu.ru Mon Aug 27 10:01:24 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Mon, 27 Aug 2007 14:01:24 +0400 Subject: RFC: licensing issue with lft In-Reply-To: <80d7e4090708241258m3ec1dc38waaac36c873866a99@mail.gmail.com> References: <46CF154D.9050605@fedoraproject.org> <1187976818.3439.885.camel@dhcp83-165.boston.redhat.com> <80d7e4090708241258m3ec1dc38waaac36c873866a99@mail.gmail.com> Message-ID: <46D2A0F4.40102@odu.neva.ru> Stephen John Smoogen wrote: > On 8/24/07, Tom spot Callaway wrote: > >> Clauses 5 and 7 are problematic. It's been at the FSF for a while now, >> they're backlogged from us and IcedTea. >> >> > > I would vote pull from rawhide or revert to 'ok version' until > settled. The functionality looks to be covered by the default > tcptraceroute (which wasnt available) > > Note, that new Fedora's "standard" traceroute already covers this as well (-T) And the rawhide version has a lot of more... See http://traceroute.sourceforge.net for details. Dmitry Butskoy http://www.fedoraproject.org/wiki/DmitryButskoy From gilboad at gmail.com Mon Aug 27 12:50:07 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Mon, 27 Aug 2007 15:50:07 +0300 Subject: plauge-client down? Message-ID: <1188219007.2262.21.camel@gilboa-work-dev.localdomain> Hello all, I'm trying to mass build packages with update license tags and all my EL-5/FC-6 builds fail due to plague-client timeouts. Buildsys down? (Or am I missing something?) - Gilboa From bugs.michael at gmx.net Mon Aug 27 13:08:27 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 27 Aug 2007 15:08:27 +0200 Subject: plauge-client down? In-Reply-To: <1188219007.2262.21.camel@gilboa-work-dev.localdomain> References: <1188219007.2262.21.camel@gilboa-work-dev.localdomain> Message-ID: <20070827150827.58f43098.bugs.michael@gmx.net> On Mon, 27 Aug 2007 15:50:07 +0300, Gilboa Davara wrote: > Hello all, > > I'm trying to mass build packages with update license tags and all my > EL-5/FC-6 builds fail due to plague-client timeouts. > > Buildsys down? (Or am I missing something?) Can't reproduce. There's one active job from ~15 mins ago, and I've successfully submitted another one (albeit killed it meanwhile). From mmcgrath at redhat.com Mon Aug 27 13:12:14 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 27 Aug 2007 08:12:14 -0500 Subject: plauge-client down? In-Reply-To: <1188219007.2262.21.camel@gilboa-work-dev.localdomain> References: <1188219007.2262.21.camel@gilboa-work-dev.localdomain> Message-ID: <46D2CDAE.8090101@redhat.com> Gilboa Davara wrote: > Hello all, > > I'm trying to mass build packages with update license tags and all my > EL-5/FC-6 builds fail due to plague-client timeouts. > > Buildsys down? (Or am I missing something?) > It actually looks like it had hung. Give it a try now. -Mike From bugs.michael at gmx.net Mon Aug 27 13:22:50 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 27 Aug 2007 15:22:50 +0200 Subject: plauge-client down? In-Reply-To: <46D2CDAE.8090101@redhat.com> References: <1188219007.2262.21.camel@gilboa-work-dev.localdomain> <46D2CDAE.8090101@redhat.com> Message-ID: <20070827152250.1e2929de.bugs.michael@gmx.net> On Mon, 27 Aug 2007 08:12:14 -0500, Mike McGrath wrote: > Gilboa Davara wrote: > > Hello all, > > > > I'm trying to mass build packages with update license tags and all my > > EL-5/FC-6 builds fail due to plague-client timeouts. > > > > Buildsys down? (Or am I missing something?) > > > > It actually looks like it had hung. Give it a try now. It was fully responsive, but had high memory usage (17% total) and increased swap usage. Build job for the 30K "poster" package was listed as running for 30+ minutes. From gilboad at gmail.com Mon Aug 27 13:41:10 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Mon, 27 Aug 2007 16:41:10 +0300 Subject: plauge-client down? In-Reply-To: <46D2CDAE.8090101@redhat.com> References: <1188219007.2262.21.camel@gilboa-work-dev.localdomain> <46D2CDAE.8090101@redhat.com> Message-ID: <1188222070.2262.25.camel@gilboa-work-dev.localdomain> On Mon, 2007-08-27 at 08:12 -0500, Mike McGrath wrote: > Gilboa Davara wrote: > > Hello all, > > > > I'm trying to mass build packages with update license tags and all my > > EL-5/FC-6 builds fail due to plague-client timeouts. > > > > Buildsys down? (Or am I missing something?) > > > > It actually looks like it had hung. Give it a try now. > > -Mike No go - timeout. - Gilboa From mmcgrath at redhat.com Mon Aug 27 13:41:33 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 27 Aug 2007 08:41:33 -0500 Subject: plauge-client down? In-Reply-To: <1188222070.2262.25.camel@gilboa-work-dev.localdomain> References: <1188219007.2262.21.camel@gilboa-work-dev.localdomain> <46D2CDAE.8090101@redhat.com> <1188222070.2262.25.camel@gilboa-work-dev.localdomain> Message-ID: <46D2D48D.9000804@redhat.com> Gilboa Davara wrote: > On Mon, 2007-08-27 at 08:12 -0500, Mike McGrath wrote: > >> Gilboa Davara wrote: >> >>> Hello all, >>> >>> I'm trying to mass build packages with update license tags and all my >>> EL-5/FC-6 builds fail due to plague-client timeouts. >>> >>> Buildsys down? (Or am I missing something?) >>> >>> >> It actually looks like it had hung. Give it a try now. >> >> -Mike >> > > No go - timeout. > Are you able to access: http://buildsys.fedoraproject.org/build-status/index.psp ? -Mike From gilboad at gmail.com Mon Aug 27 13:59:18 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Mon, 27 Aug 2007 16:59:18 +0300 Subject: plauge-client down? In-Reply-To: <46D2D48D.9000804@redhat.com> References: <1188219007.2262.21.camel@gilboa-work-dev.localdomain> <46D2CDAE.8090101@redhat.com> <1188222070.2262.25.camel@gilboa-work-dev.localdomain> <46D2D48D.9000804@redhat.com> Message-ID: <1188223158.2262.32.camel@gilboa-work-dev.localdomain> On Mon, 2007-08-27 at 08:41 -0500, Mike McGrath wrote: > Gilboa Davara wrote: > > On Mon, 2007-08-27 at 08:12 -0500, Mike McGrath wrote: > > > >> Gilboa Davara wrote: > >> > >>> Hello all, > >>> > >>> I'm trying to mass build packages with update license tags and all my > >>> EL-5/FC-6 builds fail due to plague-client timeouts. > >>> > >>> Buildsys down? (Or am I missing something?) > >>> > >>> > >> It actually looks like it had hung. Give it a try now. > >> > >> -Mike > >> > > > > No go - timeout. > > > > Are you able to access: > http://buildsys.fedoraproject.org/build-status/index.psp ? > > -Mike Yep. (via elinks) - Gilboa From mmcgrath at redhat.com Mon Aug 27 14:05:46 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 27 Aug 2007 09:05:46 -0500 Subject: plauge-client down? In-Reply-To: <1188223158.2262.32.camel@gilboa-work-dev.localdomain> References: <1188219007.2262.21.camel@gilboa-work-dev.localdomain> <46D2CDAE.8090101@redhat.com> <1188222070.2262.25.camel@gilboa-work-dev.localdomain> <46D2D48D.9000804@redhat.com> <1188223158.2262.32.camel@gilboa-work-dev.localdomain> Message-ID: <46D2DA3A.3080508@redhat.com> Gilboa Davara wrote: > On Mon, 2007-08-27 at 08:41 -0500, Mike McGrath wrote: > >> Gilboa Davara wrote: >> >>> On Mon, 2007-08-27 at 08:12 -0500, Mike McGrath wrote: >>> >>> >>>> Gilboa Davara wrote: >>>> >>>> >>>>> Hello all, >>>>> >>>>> I'm trying to mass build packages with update license tags and all my >>>>> EL-5/FC-6 builds fail due to plague-client timeouts. >>>>> >>>>> Buildsys down? (Or am I missing something?) >>>>> >>>>> >>>>> >>>> It actually looks like it had hung. Give it a try now. >>>> >>>> -Mike >>>> >>>> >>> No go - timeout. >>> >>> >> Are you able to access: >> http://buildsys.fedoraproject.org/build-status/index.psp ? >> >> -Mike >> > > Yep. (via elinks) > - Gilboa > Stop by #fedora-admin on irc.freenode.net if you get a moment, we'll troubleshoot there. -Mike From gilboad at gmail.com Mon Aug 27 14:17:35 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Mon, 27 Aug 2007 17:17:35 +0300 Subject: plauge-client down? In-Reply-To: <46D2DA3A.3080508@redhat.com> References: <1188219007.2262.21.camel@gilboa-work-dev.localdomain> <46D2CDAE.8090101@redhat.com> <1188222070.2262.25.camel@gilboa-work-dev.localdomain> <46D2D48D.9000804@redhat.com> <1188223158.2262.32.camel@gilboa-work-dev.localdomain> <46D2DA3A.3080508@redhat.com> Message-ID: <1188224255.2262.36.camel@gilboa-work-dev.localdomain> On Mon, 2007-08-27 at 09:05 -0500, Mike McGrath wrote: > Gilboa Davara wrote: > > On Mon, 2007-08-27 at 08:41 -0500, Mike McGrath wrote: > > > >> Gilboa Davara wrote: > >> > >>> On Mon, 2007-08-27 at 08:12 -0500, Mike McGrath wrote: > >>> > >>> > >>>> Gilboa Davara wrote: > >>>> > >>>> > >>>>> Hello all, > >>>>> > >>>>> I'm trying to mass build packages with update license tags and all my > >>>>> EL-5/FC-6 builds fail due to plague-client timeouts. > >>>>> > >>>>> Buildsys down? (Or am I missing something?) > >>>>> > >>>>> > >>>>> > >>>> It actually looks like it had hung. Give it a try now. > >>>> > >>>> -Mike > >>>> > >>>> > >>> No go - timeout. > >>> > >>> > >> Are you able to access: > >> http://buildsys.fedoraproject.org/build-status/index.psp ? > >> > >> -Mike > >> > > > > Yep. (via elinks) > > - Gilboa > > > > Stop by #fedora-admin on irc.freenode.net if you get a moment, we'll > troubleshoot there. > > -Mike Sadly enough, I'm @work while my build machine is @home. I'll try again once I get home. (Including the IRC part) - Gilboa From lkundrak at redhat.com Mon Aug 27 15:48:53 2007 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Mon, 27 Aug 2007 17:48:53 +0200 Subject: plauge-client down? In-Reply-To: <20070827152250.1e2929de.bugs.michael@gmx.net> References: <1188219007.2262.21.camel@gilboa-work-dev.localdomain> <46D2CDAE.8090101@redhat.com> <20070827152250.1e2929de.bugs.michael@gmx.net> Message-ID: <1188229733.26377.96.camel@pluto.englab.brq.redhat.com> On Mon, 2007-08-27 at 15:22 +0200, Michael Schwendt wrote: > On Mon, 27 Aug 2007 08:12:14 -0500, Mike McGrath wrote: > > > Gilboa Davara wrote: > > > Hello all, > > > > > > I'm trying to mass build packages with update license tags and all my > > > EL-5/FC-6 builds fail due to plague-client timeouts. > > > > > > Buildsys down? (Or am I missing something?) > > > > > > > It actually looks like it had hung. Give it a try now. > > It was fully responsive, but had high memory usage (17% total) and > increased swap usage. Build job for the 30K "poster" package was > listed as running for 30+ minutes. Well, that was my job and failed twice [1][2] during mock clean. I did not submit it again as I though that maybe build server is too loaded to finish mock cleans on time and decided to wait instead. The message from plague: > Waiting for repository to unlock before starting the build... > Job waited too long for repo to unlock. Killing it... > Killing build process... > Cleaning up the buildroot... > /usr/bin/setarch ppc32 /usr/bin/mock clean --uniqueext=44377c3af811565ad287a626c70a6f10a11a7a9b -r fedora-6-ppc-core > Killed. > Waiting for child process 28868 to exit. [1] http://buildsys.fedoraproject.org/logs/fedora-6-extras/35928-poster-20060221-4.fc6/ [2] http://buildsys.fedoraproject.org/logs/fedora-6-extras/35929-poster-20060221-4.fc6/ May I build the package now? -- Lubomir Kundrak (Red Hat Security Response Team) From skasal at redhat.com Mon Aug 27 15:59:04 2007 From: skasal at redhat.com (Stepan Kasal) Date: Mon, 27 Aug 2007 17:59:04 +0200 Subject: Default Buildroot and missing deps (awk) In-Reply-To: <20070824114654.60ba7556@weaponx.rchland.ibm.com> References: <46CF082D.3030908@redhat.com> <20070824114654.60ba7556@weaponx.rchland.ibm.com> Message-ID: <20070827155903.GA4410@camelia.ucw.cz.> Hi, On Fri, Aug 24, 2007 at 11:46:54AM -0500, Josh Boyer wrote: > Did we ever figure out what changed to cause awk to disappear? I do not think it is important. IIRC, the chain from a pkg from ExceptionList to gawk was quiote long (I tried to figure out a few months ago). If you suppose an existence of something, there should be a known short sequience of dependencies which guarantees that the feature is available. For example, you can take ld for granted, because binutils are required by gcc. (Yet it might be better to add binutils to ExceptionList.) OTOH, I think that each package which installs *.info manual should BuildRequire: info or /sbin/install-info. Currently, the program is installed, because many packages (e.g., coreutils and diffutils) have Requires(post): /sbin/install-info But who knows, that requirement may change in the future. So unless "info" is added to the ExceptionList, you should better BuildRequire: /sbin/install-info With the above in mind, I would really prefer to add things like binutils to the ExceptionList, and stating that whatever is not explicitly listed has to be BuildRequired, as was proposed in another mail in this thread. Stepan Kasal From bugs.michael at gmx.net Mon Aug 27 16:02:10 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 27 Aug 2007 18:02:10 +0200 Subject: plauge-client down? In-Reply-To: <1188229733.26377.96.camel@pluto.englab.brq.redhat.com> References: <1188219007.2262.21.camel@gilboa-work-dev.localdomain> <46D2CDAE.8090101@redhat.com> <20070827152250.1e2929de.bugs.michael@gmx.net> <1188229733.26377.96.camel@pluto.englab.brq.redhat.com> Message-ID: <20070827180210.d9b7b401.bugs.michael@gmx.net> On Mon, 27 Aug 2007 17:48:53 +0200, Lubomir Kundrak wrote: > [1] http://buildsys.fedoraproject.org/logs/fedora-6-extras/35928-poster-20060221-4.fc6/ > [2] http://buildsys.fedoraproject.org/logs/fedora-6-extras/35929-poster-20060221-4.fc6/ > > May I build the package now? Building "poster" should be done in a few minutes. Other build jobs have completed meanwhile and took only a few minutes, too. From kevin at tummy.com Mon Aug 27 16:22:06 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Mon, 27 Aug 2007 10:22:06 -0600 Subject: plauge-client down? In-Reply-To: <1188219007.2262.21.camel@gilboa-work-dev.localdomain> References: <1188219007.2262.21.camel@gilboa-work-dev.localdomain> Message-ID: <20070827102206.48de6e10@ghistelwchlohm.scrye.com> On Mon, 27 Aug 2007 15:50:07 +0300 gilboad at gmail.com (Gilboa Davara) wrote: > Hello all, > > I'm trying to mass build packages with update license tags and all my > EL-5/FC-6 builds fail due to plague-client timeouts. Is this just for license tag updates? There is not any reason to rebuild them there for that change... just check in the changes to CVS and they will be updated the next time you need to push out a real update. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gilboad at gmail.com Mon Aug 27 16:42:00 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Mon, 27 Aug 2007 19:42:00 +0300 Subject: plauge-client down? In-Reply-To: <20070827102206.48de6e10@ghistelwchlohm.scrye.com> References: <1188219007.2262.21.camel@gilboa-work-dev.localdomain> <20070827102206.48de6e10@ghistelwchlohm.scrye.com> Message-ID: <1188232920.11791.0.camel@gilboa-work-dev.localdomain> On Mon, 2007-08-27 at 10:22 -0600, Kevin Fenzi wrote: > On Mon, 27 Aug 2007 15:50:07 +0300 > gilboad at gmail.com (Gilboa Davara) wrote: > > > Hello all, > > > > I'm trying to mass build packages with update license tags and all my > > EL-5/FC-6 builds fail due to plague-client timeouts. > > Is this just for license tag updates? > > There is not any reason to rebuild them there for that change... just > check in the changes to CVS and they will be updated the next time > you need to push out a real update. > > kevin ... Not only security tag... I'm adding a couple of small fixes that were accumulated since the last release(s). - Gilboa From mszpak at wp.pl Mon Aug 27 17:54:38 2007 From: mszpak at wp.pl (=?UTF-8?B?TWFyY2luIFphasSFY3prb3dza2k=?=) Date: Mon, 27 Aug 2007 19:54:38 +0200 Subject: EPEL report week 34 2007 In-Reply-To: <46D17E85.8010709@leemhuis.info> References: <46D17E85.8010709@leemhuis.info> Message-ID: <46D30FDE.6070108@wp.pl> On 2007-08-26 15:22:13 +0200, Thorsten Leemhuis wrote: (...) > * is anybody reading the weekly reports? I usually have a look at it to check what new, fascinated packages were "ported" to EPEL. Regards Marcin From a.badger at gmail.com Mon Aug 27 19:10:50 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 27 Aug 2007 12:10:50 -0700 Subject: gnomebaker ownership In-Reply-To: <20070827103344.ae836a0a.tsmetana@redhat.com> References: <20070823161509.b2ce33b4.tsmetana@redhat.com> <3170f42f0708240005g3b0660c2n90aec13fca1ff99c@mail.gmail.com> <20070824101545.93e0c050.bugs.michael@gmx.net> <46CF0B35.90202@gmail.com> <20070824193640.3b172a0c.bugs.michael@gmx.net> <20070827103344.ae836a0a.tsmetana@redhat.com> Message-ID: <46D321BA.5050301@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom?? Smetana wrote: > On Fri, 24 Aug 2007 19:36:40 +0200 > Michael Schwendt wrote: > >>> To see what packages are currently available, look at this list of >>> [https://admin.fedoraproject.org/pkgdb/users/packages/orphan orphaned >>> packages]. >> Go ahead with killing the Wiki list of orphans. The pkgdb should >> take over. > > What is the key for a package to get to the list of orphans in pkgdb? > I can see there is also "my" nmap, which is orphaned only in RHL8 and > RHL9. But there's nothing I can do about that -- I think the ownership > for these old releases can't be changed. Maybe the list should take > only FC-6 and newer in account. And maybe it's only not generated as > frequently as I thought... > The key is whether the package is "owned" by the orphan user. So this is a bug. If you would open a ticket so the issue doesn't get lost, that would be appreciated: https://hosted.fedoraproject.org/projects/packagedb/newticket I'll either not use EOL distributions for the user lists or segregate them in a separate list. - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG0yG6X6yAic2E7kgRAstKAJ9man2pIK2LBvRxvZyAdBUdQalJOQCfW6PQ ekgX70GpWtm06neWk9n4J0U= =4qIM -----END PGP SIGNATURE----- From buildsys at fedoraproject.org Mon Aug 27 21:33:09 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 27 Aug 2007 17:33:09 -0400 (EDT) Subject: Package EVR problems in Fedora 2007-08-27 Message-ID: <20070827213309.2AE30152131@buildsys.fedoraproject.org> Axel Thimm AT ATrpms net: smart FE6 > F8 (0:0.50-47.fc6 > 0:0.50-46.fc8) F7-updates-testing > F8 (0:0.50-47.fc7 > 0:0.50-46.fc8) alexl AT users sourceforge net: perl-Convert-Binary-C FE6 > F7 (0:0.68-2.fc6 > 0:0.67-4.fc7) perl-Graph FE6 > F7 (0:0.83-3.fc6 > 0:0.81-1.fc7) perl-SVG FE6 > F7 (0:2.34-2.fc6 > 0:2.33-2.fc7) perl-XML-Writer FE6 > F7 (0:0.603-2.fc6 > 0:0.602-3.fc7) cgoorah AT yahoo com au: kshutdown FE6 > F7-updates (0:1.0.1-1.fc6 > 0:1.0-3.fc7) dakingun AT gmail com: texmaker FE6 > F7-updates (1:1.6-3.fc6 > 1:1.6-2.fc7) davidz AT redhat com: dbus-python F7-updates-testing > F8 (0:0.82.0-2.fc7 > 0:0.82.0-1.fc8) devrim AT commandprompt com: postgresql-pgpool-II FE6 > F7-updates (0:1.2-4.fc6 > 0:1.2-1.fc7) ed AT eh3 com: scrip FE6 > F7 (0:1.4-7.fc6 > 0:1.4-6.fc6) enrico scholz AT informatik tu-chemnitz de: fedora-usermgmt FE6 > F7 (0:0.10-1.fc6 > 0:0.9-2.fc7) libextractor FE6 > F7 (0:0.5.18a-1.fc6 > 0:0.5.17a-1.fc7) libtasn1 FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE5 > F8 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE6 > F7 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) FE6 > F8 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) mimetic FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7) FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7) util-vserver FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7) FE6 > F7 (0:0.30.213-2.fc6 > 0:0.30.212-3.fc7) xmlrpc-c FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7) FE6 > F7 (0:1.06.17-1.fc6 > 0:1.06.11-2.fc7) foolish AT guezz net: gtranslator F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8) perl-Net-Libdnet F7-updates > F8 (0:0.01-3.fc7.1 > 0:0.01-2.fc8) perl-Nmap-Parser F7-updates > F8 (0:1.05-4.fc7 > 0:1.05-3.fc8) tcptraceroute FE6 > F7-updates (0:1.5-0.2.beta7.fc6 > 0:1.5-0.1.beta7.fc7) gemi AT bluewin ch: plt-scheme F7-updates-testing > F8 (0:371-1.fc7 > 0:370-3.fc8) gilboad AT gmail com: cgdb F7-updates-testing > F8 (0:0.6.4-2.fc7 > 0:0.6.4-1.fc7) ianburrell AT gmail com: jigdo F7-updates-testing > F8 (0:0.7.3-4.fc7 > 0:0.7.3-3.fc7) jakub AT redhat com: gcc FC6-updates > F7 (0:4.1.2-13.fc6 > 0:4.1.2-12) jdennis AT redhat com: setroubleshoot F7-updates-testing > F8 (0:1.10.1-1.fc7 > 0:1.9.7-1.fc8) jeff AT ocjtech us: jrtplib FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) radiusclient-ng FE6 > F7-updates (0:0.5.6-2.fc6 > 0:0.5.5.1-1.fc7) jkeating AT redhat com: mock F7-updates-testing > F8 (0:0.7.6-1.fc7 > 0:0.7.5-2.fc8) jonathan underwood AT gmail com: emacs-vm FE6 > F7-updates (0:8.0.3.495-2.fc6 > 0:8.0.2.482-4.fc7) karen-pease AT uiowa edu: fortune-firefly FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6) FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6) nethack-vultures FE6 > F7 (0:2.1.0-10.fc6 > 0:2.1.0-9.fc7) kwizart AT gmail com: PythonCAD FE6 > F7 (0:0.1.36-2.fc6 > 0:0.1.35-7.fc7) lemenkov AT gmail com: stratagus FE6 > F7 (0:2.2.4-1.fc6 > 0:2.2.3-1.fc7) lxtnow AT gmail com: gammu FE6 > F8 (0:1.12.92-1.fc6 > 0:1.11.0-1.fc8) F7-updates-testing > F8 (0:1.12.92-1.fc7 > 0:1.11.0-1.fc8) python-gammu FE6 > F7-updates (0:0.21-1.fc6 > 0:0.20-1.fc7) FE6 > F8 (0:0.21-1.fc6 > 0:0.20-1.fc7) specto FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8) F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8) mebrown AT michaels-house net: firmware-addon-dell F7-updates-testing > F8 (0:1.4.8-1.fc7 > 0:1.4.7-1.fc8) firmware-tools F7-updates-testing > F8 (0:1.5.6-1.fc7 > 0:1.5.5-1.fc8) mikeb AT redhat com: python-cheetah FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) nhorman AT redhat com: irqbalance FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6) FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7) FC5-updates > F8 (2:0.55-4.fc5 > 2:0.55-3.fc8) pmatilai AT redhat com: rpm FC6-updates > F7 (0:4.4.2.1-1.fc6 > 0:4.4.2-46.fc7) rc040203 AT freenet de: perl-capitalization FE6 > F7 (0:0.03-5.fc6 > 0:0.03-4.fc6) perl-Class-Inspector FE6 > F7 (0:1.17-1.fc6 > 0:1.16-3.fc7) perl-Class-ReturnValue FE6 > F7 (0:0.54-1.fc6 > 0:0.53-6.fc7) rdieter AT math unl edu: kdeartwork-extras FE6 > F7 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) FE6 > F8 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) kdegraphics-extras FE6 > F7 (0:3.5.7-1.fc6 > 0:3.5.5-1.fc7) FE6 > F8 (0:3.5.7-1.fc6 > 0:3.5.5-1.fc7) kdemultimedia-extras FE6 > F7 (6:3.5.7-1.fc6.5 > 6:3.5.6-5.fc7) FE6 > F8 (6:3.5.7-1.fc6.5 > 6:3.5.6-5.fc7) maxima FE5 > F7-updates (0:5.12.0-3.fc5 > 0:5.12.0-2.fc7) FE6 > F7-updates (0:5.12.0-3.fc6 > 0:5.12.0-2.fc7) rnorwood AT redhat com: perl-Crypt-SSLeay F7-updates-testing > F8 (0:0.56-1.fc7 > 0:0.55-2.fc8) sandmann AT redhat com: libgtop2 FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7) snecklifter AT gmail com: jokosher F7-updates > F8 (0:0.9-5.fc7 > 0:0.9-4.fc8) splinux25 AT gmail com: lostirc FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7) FE6 > F8 (0:0.4.6-3.fc6 > 0:0.4.6-2.fc8) tcallawa AT redhat com: winpdb F7-updates-testing > F8 (0:1.2.2-1.fc7.1 > 0:1.1.4-1.fc8) tsmetana AT redhat com: fann FE6 > F7-updates (0:2.0.0-4.fc6 > 0:2.0.0-3.fc7) ville skytta AT iki fi: em8300 FE6 > F7-updates (0:0.16.3-1.fc6 > 0:0.16.3-0.1.rc2.fc7) em8300-kmod FE6 > F7-updates (0:0.16.3-1.2.6.22.2_42.fc6 > 0:0.16.3-0.1.rc2.2.6.22.1_41.fc7) wolfy AT nobugconsulting ro: qfaxreader FE6 > F7-updates (0:0.3.1-8.fc6.1 > 0:0.3.1-7.fc7) ssmtp FE6 > F7 (0:2.61-11.3.fc6.1 > 0:2.61-11.1.fc7) ---------------------------------------------------------------------- cgdb: gilboad AT gmail com F7-updates-testing > F8 (0:0.6.4-2.fc7 > 0:0.6.4-1.fc7) dbus-python: davidz AT redhat com F7-updates-testing > F8 (0:0.82.0-2.fc7 > 0:0.82.0-1.fc8) em8300: ville skytta AT iki fi FE6 > F7-updates (0:0.16.3-1.fc6 > 0:0.16.3-0.1.rc2.fc7) em8300-kmod: ville skytta AT iki fi FE6 > F7-updates (0:0.16.3-1.2.6.22.2_42.fc6 > 0:0.16.3-0.1.rc2.2.6.22.1_41.fc7) emacs-vm: jonathan underwood AT gmail com FE6 > F7-updates (0:8.0.3.495-2.fc6 > 0:8.0.2.482-4.fc7) fann: tsmetana AT redhat com FE6 > F7-updates (0:2.0.0-4.fc6 > 0:2.0.0-3.fc7) fedora-usermgmt: enrico scholz AT informatik tu-chemnitz de FE6 > F7 (0:0.10-1.fc6 > 0:0.9-2.fc7) firmware-addon-dell: mebrown AT michaels-house net F7-updates-testing > F8 (0:1.4.8-1.fc7 > 0:1.4.7-1.fc8) firmware-tools: mebrown AT michaels-house net F7-updates-testing > F8 (0:1.5.6-1.fc7 > 0:1.5.5-1.fc8) fortune-firefly: karen-pease AT uiowa edu FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6) FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6) gammu: lxtnow AT gmail com FE6 > F8 (0:1.12.92-1.fc6 > 0:1.11.0-1.fc8) F7-updates-testing > F8 (0:1.12.92-1.fc7 > 0:1.11.0-1.fc8) gcc: jakub AT redhat com FC6-updates > F7 (0:4.1.2-13.fc6 > 0:4.1.2-12) gtranslator: foolish AT guezz net F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8) irqbalance: nhorman AT redhat com FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6) FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7) FC5-updates > F8 (2:0.55-4.fc5 > 2:0.55-3.fc8) jigdo: ianburrell AT gmail com F7-updates-testing > F8 (0:0.7.3-4.fc7 > 0:0.7.3-3.fc7) jokosher: snecklifter AT gmail com F7-updates > F8 (0:0.9-5.fc7 > 0:0.9-4.fc8) jrtplib: jeff AT ocjtech us FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) kdeartwork-extras: rdieter AT math unl edu FE6 > F7 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) FE6 > F8 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) kdegraphics-extras: rdieter AT math unl edu FE6 > F7 (0:3.5.7-1.fc6 > 0:3.5.5-1.fc7) FE6 > F8 (0:3.5.7-1.fc6 > 0:3.5.5-1.fc7) kdemultimedia-extras: rdieter AT math unl edu FE6 > F7 (6:3.5.7-1.fc6.5 > 6:3.5.6-5.fc7) FE6 > F8 (6:3.5.7-1.fc6.5 > 6:3.5.6-5.fc7) kshutdown: cgoorah AT yahoo com au FE6 > F7-updates (0:1.0.1-1.fc6 > 0:1.0-3.fc7) libextractor: enrico scholz AT informatik tu-chemnitz de FE6 > F7 (0:0.5.18a-1.fc6 > 0:0.5.17a-1.fc7) libgtop2: sandmann AT redhat com FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7) libtasn1: enrico scholz AT informatik tu-chemnitz de FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE5 > F8 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE6 > F7 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) FE6 > F8 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) lostirc: splinux25 AT gmail com FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7) FE6 > F8 (0:0.4.6-3.fc6 > 0:0.4.6-2.fc8) maxima: rdieter AT math unl edu FE5 > F7-updates (0:5.12.0-3.fc5 > 0:5.12.0-2.fc7) FE6 > F7-updates (0:5.12.0-3.fc6 > 0:5.12.0-2.fc7) mimetic: enrico scholz AT informatik tu-chemnitz de FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7) FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7) mock: jkeating AT redhat com F7-updates-testing > F8 (0:0.7.6-1.fc7 > 0:0.7.5-2.fc8) nethack-vultures: karen-pease AT uiowa edu FE6 > F7 (0:2.1.0-10.fc6 > 0:2.1.0-9.fc7) perl-capitalization: rc040203 AT freenet de FE6 > F7 (0:0.03-5.fc6 > 0:0.03-4.fc6) perl-Class-Inspector: rc040203 AT freenet de FE6 > F7 (0:1.17-1.fc6 > 0:1.16-3.fc7) perl-Class-ReturnValue: rc040203 AT freenet de FE6 > F7 (0:0.54-1.fc6 > 0:0.53-6.fc7) perl-Convert-Binary-C: alexl AT users sourceforge net FE6 > F7 (0:0.68-2.fc6 > 0:0.67-4.fc7) perl-Crypt-SSLeay: rnorwood AT redhat com F7-updates-testing > F8 (0:0.56-1.fc7 > 0:0.55-2.fc8) perl-Graph: alexl AT users sourceforge net FE6 > F7 (0:0.83-3.fc6 > 0:0.81-1.fc7) perl-Net-Libdnet: foolish AT guezz net F7-updates > F8 (0:0.01-3.fc7.1 > 0:0.01-2.fc8) perl-Nmap-Parser: foolish AT guezz net F7-updates > F8 (0:1.05-4.fc7 > 0:1.05-3.fc8) perl-SVG: alexl AT users sourceforge net FE6 > F7 (0:2.34-2.fc6 > 0:2.33-2.fc7) perl-XML-Writer: alexl AT users sourceforge net FE6 > F7 (0:0.603-2.fc6 > 0:0.602-3.fc7) plt-scheme: gemi AT bluewin ch F7-updates-testing > F8 (0:371-1.fc7 > 0:370-3.fc8) postgresql-pgpool-II: devrim AT commandprompt com FE6 > F7-updates (0:1.2-4.fc6 > 0:1.2-1.fc7) python-cheetah: mikeb AT redhat com FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) python-gammu: lxtnow AT gmail com FE6 > F7-updates (0:0.21-1.fc6 > 0:0.20-1.fc7) FE6 > F8 (0:0.21-1.fc6 > 0:0.20-1.fc7) PythonCAD: kwizart AT gmail com FE6 > F7 (0:0.1.36-2.fc6 > 0:0.1.35-7.fc7) qfaxreader: wolfy AT nobugconsulting ro FE6 > F7-updates (0:0.3.1-8.fc6.1 > 0:0.3.1-7.fc7) radiusclient-ng: jeff AT ocjtech us FE6 > F7-updates (0:0.5.6-2.fc6 > 0:0.5.5.1-1.fc7) rpm: pmatilai AT redhat com FC6-updates > F7 (0:4.4.2.1-1.fc6 > 0:4.4.2-46.fc7) scrip: ed AT eh3 com FE6 > F7 (0:1.4-7.fc6 > 0:1.4-6.fc6) setroubleshoot: jdennis AT redhat com F7-updates-testing > F8 (0:1.10.1-1.fc7 > 0:1.9.7-1.fc8) smart: Axel Thimm AT ATrpms net FE6 > F8 (0:0.50-47.fc6 > 0:0.50-46.fc8) F7-updates-testing > F8 (0:0.50-47.fc7 > 0:0.50-46.fc8) specto: lxtnow AT gmail com FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8) F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8) ssmtp: wolfy AT nobugconsulting ro FE6 > F7 (0:2.61-11.3.fc6.1 > 0:2.61-11.1.fc7) stratagus: lemenkov AT gmail com FE6 > F7 (0:2.2.4-1.fc6 > 0:2.2.3-1.fc7) tcptraceroute: foolish AT guezz net FE6 > F7-updates (0:1.5-0.2.beta7.fc6 > 0:1.5-0.1.beta7.fc7) texmaker: dakingun AT gmail com FE6 > F7-updates (1:1.6-3.fc6 > 1:1.6-2.fc7) util-vserver: enrico scholz AT informatik tu-chemnitz de FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7) FE6 > F7 (0:0.30.213-2.fc6 > 0:0.30.212-3.fc7) winpdb: tcallawa AT redhat com F7-updates-testing > F8 (0:1.2.2-1.fc7.1 > 0:1.1.4-1.fc8) xmlrpc-c: enrico scholz AT informatik tu-chemnitz de FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7) FE6 > F7 (0:1.06.17-1.fc6 > 0:1.06.11-2.fc7) From lmacken at redhat.com Tue Aug 28 00:38:05 2007 From: lmacken at redhat.com (Luke Macken) Date: Mon, 27 Aug 2007 20:38:05 -0400 Subject: bodhi broken? In-Reply-To: <46D01F6F.50008@gmail.com> References: <20070825142309.22ea7cc0@alkaid.a.lan> <46D01F6F.50008@gmail.com> Message-ID: <20070828003805.GA20753@crow.myhome.westell.com> On Sat, Aug 25, 2007 at 02:24:15PM +0200, Adel Gadllah wrote: > Andreas Bierfert wrote: >> Hi, >> >> I when I try to add a new update into bodhi I get this message: >> >> 500 Internal error >> >> The server encountered an unexpected condition which prevented it from >> fulfilling the request. >> >> Would be nice if somebody could look at it :) >> > > It can be related to the fact that bugzilla is currently down (bodhi > interacts with bugzilla) Yeah, I made some changes today to hopefully resolve the Bugzilla issue. Please file a ticket[0] if you're still having problems. luke [0]: https://hosted.fedoraproject.org/projects/bodhi/newticket From dennis at ausil.us Tue Aug 28 03:37:04 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 27 Aug 2007 22:37:04 -0500 Subject: Orphaned Packages Message-ID: <200708272237.09759.dennis@ausil.us> Hi All, I have orphaned 2 of my packages. hamlib and ktrack. if anyone is intrested then please feel free to pick them up. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From tsmetana at redhat.com Tue Aug 28 06:27:35 2007 From: tsmetana at redhat.com (=?UTF-8?B?VG9tw6HFoQ==?= Smetana) Date: Tue, 28 Aug 2007 08:27:35 +0200 Subject: gnomebaker ownership In-Reply-To: <46D321BA.5050301@gmail.com> References: <20070823161509.b2ce33b4.tsmetana@redhat.com> <3170f42f0708240005g3b0660c2n90aec13fca1ff99c@mail.gmail.com> <20070824101545.93e0c050.bugs.michael@gmx.net> <46CF0B35.90202@gmail.com> <20070824193640.3b172a0c.bugs.michael@gmx.net> <20070827103344.ae836a0a.tsmetana@redhat.com> <46D321BA.5050301@gmail.com> Message-ID: <20070828082735.df590f57.tsmetana@redhat.com> On Mon, 27 Aug 2007 12:10:50 -0700 Toshio Kuratomi wrote: > The key is whether the package is "owned" by the orphan user. So this > is a bug. If you would open a ticket so the issue doesn't get lost, > that would be appreciated: > https://hosted.fedoraproject.org/projects/packagedb/newticket OK. Here you are: https://hosted.fedoraproject.org/projects/packagedb/ticket/55 -- Tom?? Smetana Base OS Software Engineer, Red Hat RH IRC: #brno #devel #base-os From habig at neutrino.d.umn.edu Tue Aug 28 14:27:04 2007 From: habig at neutrino.d.umn.edu (Alec T. Habig) Date: Tue, 28 Aug 2007 09:27:04 -0500 Subject: cvs ACLs and the package directory tree Message-ID: <20070828142704.GC14627@neutrino.d.umn.edu> Hi, Hopefully a simple case of new operator error, but in trying to update the new yum-cron package (the initial build of which has now propagated everywhere properly), I've rebuilt an updated SRPM, and am trying to import it using the common/cvs-import.sh script. This fails with: cvs commit... **** Access denied: habig is not in ACL for rpms/yum-cron cvs commit: Pre-commit check failed **** Access allowed: habig is in ACL for rpms/yum-cron/devel. cvs [commit aborted]: correct above errors first! So, a number of questions here. 1) Why do I need access to the package root directory, as far as I can tell all the actual package-related stuff I want to change is in the tagged subdirectories? 2) Why did it work in my initial builts for {devel, F-7, EL-5, FC-6} but is failing now? 3) Is using the cvs-import script still appropriate for maintenance as opposed to initial setup? All the how-tos and wiki's I could find are aimed at how to get things set up, but I couldn't find any info for the regular maintenance cycle. and lastly of course, 4) What do I need to do to get past this error and back to actually maintaining the package? Thanks, Alec -- Alec Habig, University of Minnesota Duluth Physics Dept. habig at neutrino.d.umn.edu http://neutrino.d.umn.edu/~habig/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Tue Aug 28 14:56:34 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 28 Aug 2007 07:56:34 -0700 Subject: cvs ACLs and the package directory tree In-Reply-To: <20070828142704.GC14627@neutrino.d.umn.edu> References: <20070828142704.GC14627@neutrino.d.umn.edu> Message-ID: <46D437A2.6000201@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alec T. Habig wrote: > Hi, > > Hopefully a simple case of new operator error, but in trying to update > the new yum-cron package (the initial build of which has now propagated > everywhere properly), I've rebuilt an updated SRPM, and am trying to > import it using the common/cvs-import.sh script. This fails with: > > cvs commit... > **** Access denied: habig is not in ACL for rpms/yum-cron > cvs commit: Pre-commit check failed > **** Access allowed: habig is in ACL for rpms/yum-cron/devel. > cvs [commit aborted]: correct above errors first! > > So, a number of questions here. > > 1) Why do I need access to the package root directory, as far as I can > tell all the actual package-related stuff I want to change is in the > tagged subdirectories? > > 2) Why did it work in my initial builts for {devel, F-7, EL-5, FC-6} but > is failing now? > > 3) Is using the cvs-import script still appropriate for maintenance as > opposed to initial setup? All the how-tos and wiki's I could find > are aimed at how to get things set up, but I couldn't find any info > for the regular maintenance cycle. > > and lastly of course, > > 4) What do I need to do to get past this error and back to actually > maintaining the package? > You're running into the issue documented here: https://www.redhat.com/archives/fedora-devel-list/2007-August/msg01122.html I haven't received any feedback on that script so I've gone ahead and imported it into the common directory. cvs update to get the new version into the cvs-import.sh script and give it a try. - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG1DeiX6yAic2E7kgRAh1RAJ4lzknsjL8uGbIKmkr1FloEqxBdOQCdF2Wh hFtB1TPgcwmtO5Sr5sKhuhc= =mHfA -----END PGP SIGNATURE----- From mlichvar at redhat.com Tue Aug 28 15:15:57 2007 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Tue, 28 Aug 2007 17:15:57 +0200 Subject: qsf license change Message-ID: <20070828151557.GG31757@localhost> Hi, qsf is now licensed under Artistic 2.0 (was Artistic). -- Miroslav Lichvar From bugs.michael at gmx.net Tue Aug 28 21:11:58 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 28 Aug 2007 23:11:58 +0200 Subject: This list isn't working out. Or, why do we have fedora-devel and fedora-maintainers In-Reply-To: <80d7e4090708261620r9569fa5s8e4c377448cb2850@mail.gmail.com> References: <645d17210708211029y4717366pf927665eb37ec8e6@mail.gmail.com> <80d7e4090708261620r9569fa5s8e4c377448cb2850@mail.gmail.com> Message-ID: <20070828231158.7bff7d73.bugs.michael@gmx.net> On Sun, 26 Aug 2007 17:20:52 -0600, Stephen John Smoogen wrote: > > On Tue, 21 Aug 2007, Jonathan Underwood wrote: > > > > > Can we either get a lot more disciplined > > > about pointing out when people are using the wrong list or (this would > > > be my choice) kill off fedora-maintainers. > > > > Can we please just kill it, it's confusing me too. I'm convinced, too, that this list doesn't work at all. Too many lists and no clear guidelines which topics belong onto which list. > What lists should someone working with/for Fedora be subscribed to > these days? Could we just have a fedora-memo-list and fedora-tech-list > and be done with it? Yes, please. At least one announce-list with mandatory subscription where you can be sure you can reach all contributors. In particular, FESCo and other leadership people need a way to address all contributors anyway. On this list it doesn't work out. From bugs.michael at gmx.net Tue Aug 28 21:59:52 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 28 Aug 2007 23:59:52 +0200 Subject: Don't rebuild licence updates for old dists In-Reply-To: <20070822103202.97a8cf35.bugs.michael@gmx.net> References: <20070822103202.97a8cf35.bugs.michael@gmx.net> Message-ID: <20070828235952.e4c898fa.bugs.michael@gmx.net> On Wed, 22 Aug 2007 10:32:02 +0200, Michael Schwendt wrote: > Some packagers not only check in the licence updates to older branches > (F-7, FC-6, FC-5), they also submit build jobs for them. > > Please don't do that. > > If every packager does that for all packages, we would rebuild the > entire distribution and flood our users with superfluous updates. And a few more have arrived... I'm going to drop the following from the FE6 needsign queue. cgdb : only licence update rebuild digitemp : only licence update rebuild eggdrop : only licence update rebuild gmrun : only licence update rebuild mksh : only licence update rebuild wavbreaker : only release bump rebuild (%changelog refers to F8 rebuild) From packages at amiga-hardware.com Tue Aug 28 22:06:25 2007 From: packages at amiga-hardware.com (Ian Chapman) Date: Tue, 28 Aug 2007 23:06:25 +0100 Subject: Weird build failure - fc6 Message-ID: <46D49C61.80303@amiga-hardware.com> Hi all, Can any shed some light on why the following might have failed? I can't seem to see why, it looks like it's OK to me. http://buildsys.fedoraproject.org/logs/fedora-6-extras/36021-cbios-0.21-3.fc6/noarch/ -- Ian Chapman. From bugs.michael at gmx.net Tue Aug 28 22:12:02 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 29 Aug 2007 00:12:02 +0200 Subject: Weird build failure - fc6 In-Reply-To: <46D49C61.80303@amiga-hardware.com> References: <46D49C61.80303@amiga-hardware.com> Message-ID: <20070829001202.7fb191cd.bugs.michael@gmx.net> On Tue, 28 Aug 2007 23:06:25 +0100, Ian Chapman wrote: > Hi all, > > Can any shed some light on why the following might have failed? I can't > seem to see why, it looks like it's OK to me. > > http://buildsys.fedoraproject.org/logs/fedora-6-extras/36021-cbios-0.21-3.fc6/noarch/ > Very likely related to last week's topic on this list. Join: https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/125 From packages at amiga-hardware.com Tue Aug 28 22:18:32 2007 From: packages at amiga-hardware.com (Ian Chapman) Date: Tue, 28 Aug 2007 23:18:32 +0100 Subject: Weird build failure - fc6 In-Reply-To: <20070829001202.7fb191cd.bugs.michael@gmx.net> References: <46D49C61.80303@amiga-hardware.com> <20070829001202.7fb191cd.bugs.michael@gmx.net> Message-ID: <46D49F38.7060900@amiga-hardware.com> Michael Schwendt wrote: > Very likely related to last week's topic on this list. Join: > https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/125 Thanks, at least I'm not going insane! :) I've that build to the ticket. -- Ian Chapman. From robert at fedoraproject.org Wed Aug 29 00:16:46 2007 From: robert at fedoraproject.org (Robert Scheck) Date: Wed, 29 Aug 2007 02:16:46 +0200 Subject: POPT got splitted out of RPM, please adjust your BuildRequires In-Reply-To: <200708241031.13510.opensource@till.name> References: <20070823230914.GA32719@hurricane.linuxnetz.de> <200708241031.13510.opensource@till.name> Message-ID: <20070829001646.GA31064@hurricane.linuxnetz.de> Hello Till, On Fri, 24 Aug 2007, Till Maas wrote: > I updated it and made a scratch rebuild, I noticed that the old one only > required libpopt.so.0 (and a lot of not popt related stuff), but the new one > also has a libpopt.so.0(LIBPOPT_0) requirement. Is this worth a rebuild? sorry, I overlooked your e-mail. It doesn't really matter whether your package depends on libpopt.so.0 and/or libpopt.so.0(LIBPOPT_0). The new popt version uses exports which are detected and catched up by rpm. As the library is ABI and API compatible & named same, this is not of any belong. Greetings, Robert From mtasaka at ioa.s.u-tokyo.ac.jp Wed Aug 29 02:11:45 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 29 Aug 2007 11:11:45 +0900 Subject: build hang on koji? Message-ID: <46D4D5E1.1020905@ioa.s.u-tokyo.ac.jp> Hello. Could someone check what is happening on the following koji task? http://koji.fedoraproject.org/koji/taskinfo?taskID=135384 This task is now building xscreensaver on x86_64, which usually takes less than 20 minutes (for i386 build, actually it took 12 minutes to be completed: http://koji.fedoraproject.org/koji/taskinfo?taskID=135385 ) However for this task it is not yet finished even after 6 hours. >From build.log it seems to be hanging on debuginfo script. Regards, Mamoru From sandeen at redhat.com Wed Aug 29 05:34:09 2007 From: sandeen at redhat.com (Eric Sandeen) Date: Wed, 29 Aug 2007 00:34:09 -0500 Subject: bugzilla confused on package ownership? Message-ID: <46D50551.4090603@redhat.com> So, tonight I got a new bug for elfutils (262461). Interesting as I'm not the owner. Last night tsmetana assigned an e2fsprogs bug (258381) over to me, it originally went to him for some reason. I searched tonight and found one other newly opened e2fsprogs bug initially assigned to rvokal (254841), not me. Any idea what's going on here? And package owners might want to search for wayward bugs :) -Eric From garrick at usc.edu Wed Aug 29 07:05:30 2007 From: garrick at usc.edu (Garrick Staples) Date: Wed, 29 Aug 2007 00:05:30 -0700 Subject: bugzilla confused on package ownership? In-Reply-To: <46D50551.4090603@redhat.com> References: <46D50551.4090603@redhat.com> Message-ID: <20070829070530.GK19043@polop.usc.edu> On Wed, Aug 29, 2007 at 12:34:09AM -0500, Eric Sandeen alleged: > So, tonight I got a new bug for elfutils (262461). Interesting as I'm > not the owner. > > Last night tsmetana assigned an e2fsprogs bug (258381) over to me, it > originally went to him for some reason. > > I searched tonight and found one other newly opened e2fsprogs bug > initially assigned to rvokal (254841), not me. > > Any idea what's going on here? > > And package owners might want to search for wayward bugs :) Something is definitely broken. Last night a new anaconda bug was incorrectly assigned to me, but "reassign to package owner" seems to work. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jgranado at redhat.com Wed Aug 29 07:18:55 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Wed, 29 Aug 2007 09:18:55 +0200 Subject: bugzilla confused on package ownership? In-Reply-To: <46D50551.4090603@redhat.com> References: <46D50551.4090603@redhat.com> Message-ID: <46D51DDF.7080106@redhat.com> Eric Sandeen wrote: > So, tonight I got a new bug for elfutils (262461). Interesting as I'm > not the owner. > > Last night tsmetana assigned an e2fsprogs bug (258381) over to me, it > originally went to him for some reason. > > I searched tonight and found one other newly opened e2fsprogs bug > initially assigned to rvokal (254841), not me. > > Any idea what's going on here? > > And package owners might want to search for wayward bugs :) > > -Eric > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > Seems this is due to the recent bugzilla changes. I have sent a mail to kbaker about the issue. Regards -- Joel Andres Granados From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Aug 29 08:08:48 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 29 Aug 2007 10:08:48 +0200 Subject: bugzilla confused on package ownership? In-Reply-To: <20070829070530.GK19043@polop.usc.edu> References: <46D50551.4090603@redhat.com> <20070829070530.GK19043@polop.usc.edu> Message-ID: <20070829100848.1ed96257@python3.es.egwn.lan> Garrick Staples wrote : > On Wed, Aug 29, 2007 at 12:34:09AM -0500, Eric Sandeen alleged: > > So, tonight I got a new bug for elfutils (262461). Interesting as I'm > > not the owner. > > > > Last night tsmetana assigned an e2fsprogs bug (258381) over to me, it > > originally went to him for some reason. > > > > I searched tonight and found one other newly opened e2fsprogs bug > > initially assigned to rvokal (254841), not me. > > > > Any idea what's going on here? > > > > And package owners might want to search for wayward bugs :) > > Something is definitely broken. Last night a new anaconda bug was incorrectly > assigned to me, but "reassign to package owner" seems to work. I also got a kernel bug assigned to me... /me shivers! ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.22.2-57.fc7 Load : 0.27 0.41 0.39 From wolters.liste at gmx.net Wed Aug 29 15:38:14 2007 From: wolters.liste at gmx.net (Roland Wolters) Date: Wed, 29 Aug 2007 17:38:14 +0200 Subject: Orphaned Packages In-Reply-To: <200708272237.09759.dennis@ausil.us> References: <200708272237.09759.dennis@ausil.us> Message-ID: <200708291738.19772.wolters.liste@gmx.net> Once upon a time Dennis Gilmore wrote: > I have orphaned 2 of my packages. hamlib and ktrack. if anyone is > intrested then please feel free to pick them up. > What about knetworkmanager? Have you orphaned that, or do you need a co-maintainer? There are three open bugs without any reaction so far :/ Roland -- Ich bin weit ?ber die F?higkeit rationalen Denkens hinaus entsetzt. -- Egon aus Ghostbusters -------------- 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 limb at jcomserv.net Wed Aug 29 15:22:23 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 29 Aug 2007 10:22:23 -0500 (CDT) Subject: Netpanzer Message-ID: <10637.65.192.24.164.1188400943.squirrel@mail.jcomserv.net> With release 0.8.2, upstream has merged the program and data tarballs. I'm thinking of merging netpanzer-data into netpanzer and obsoleting netpanzer-data. Any objections? Jon -- novus ordo absurdum From robert at marcanoonline.com Wed Aug 29 16:16:02 2007 From: robert at marcanoonline.com (Robert Marcano) Date: Wed, 29 Aug 2007 12:16:02 -0400 Subject: Invalid key for elfutils? Message-ID: <1188404163.2972.3.camel@localhost.localdomain> Instaling the new update of elfutils, i found the following message Downloading Packages: warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID 30c9ecf8 Public key for elfutils-libelf-0.129-1.fc7.i386.rpm is not installed I looked on another mirrors just to check if the RPM compromised but I found the same error, all other RPM from fedora-updates are being verified correctly Anyone has noticed this??? ________________________________________ Robert Marcano ????????????????? web: http://www.marcanoonline.com/ gpg --keyserver hkp://pgp.mit.edu/ --recv-key 72A0DCFD From mmcgrath at redhat.com Wed Aug 29 16:20:31 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 29 Aug 2007 11:20:31 -0500 Subject: Invalid key for elfutils? In-Reply-To: <1188404163.2972.3.camel@localhost.localdomain> References: <1188404163.2972.3.camel@localhost.localdomain> Message-ID: <46D59CCF.2000908@redhat.com> Robert Marcano wrote: > Instaling the new update of elfutils, i found the following message > > Downloading Packages: > warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID 30c9ecf8 > > > Public key for elfutils-libelf-0.129-1.fc7.i386.rpm is not installed > > I looked on another mirrors just to check if the RPM compromised but I > found the same error, all other RPM from fedora-updates are being > verified correctly > > Anyone has noticed this??? > This is a known issue and is being worked on. -Mike From a.badger at gmail.com Wed Aug 29 17:00:44 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 29 Aug 2007 10:00:44 -0700 Subject: Netpanzer In-Reply-To: <10637.65.192.24.164.1188400943.squirrel@mail.jcomserv.net> References: <10637.65.192.24.164.1188400943.squirrel@mail.jcomserv.net> Message-ID: <46D5A63C.8080208@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jon Ciesla wrote: > With release 0.8.2, upstream has merged the program and data tarballs. > I'm thinking of merging netpanzer-data into netpanzer and obsoleting > netpanzer-data. Any objections? > Isn't the netpanzer data large and not subject to as much change as the engine? If so, there are still reasons to keep the data separate from the game engine. - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG1aY8X6yAic2E7kgRAmWXAJ9e9CznBV3M7iI9XFjx6zjetB8sSgCgku0j 3/Egpklmd5si9103jP34dHc= =EPip -----END PGP SIGNATURE----- From tmraz at redhat.com Wed Aug 29 17:01:28 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 29 Aug 2007 19:01:28 +0200 Subject: possible open() problem again In-Reply-To: <20070824135137.GA20061@devserv.devel.redhat.com> References: <46CDEFCF.7020608@amiga-hardware.com> <20070823204318.GZ2063@devserv.devel.redhat.com> <46CDF1E5.5070805@poolshark.org> <20070823210553.GA2063@devserv.devel.redhat.com> <20070823223429.GC11286@devserv.devel.redhat.com> <46CE0FCF.6080008@redhat.com> <20070823190539.05b216fc@vader.jdub.homelinux.org> <20070824135137.GA20061@devserv.devel.redhat.com> Message-ID: <1188406888.2949.18.camel@vespa.kabelta.loc> On Fri, 2007-08-24 at 09:51 -0400, Alan Cox wrote: > On Thu, Aug 23, 2007 at 07:05:39PM -0500, Josh Boyer wrote: > > > Hm, in fact, *if* this is only for the F8 devel phase (is it?) then > > > maybe an rpm macro in the prep phase to do that perl search would be > > > less painful... > > > > I think this will show up in upstream glibc 2.7 when it is released. > > That will do wonders for the reputation of glibc. gcc 2.96 all over again Note that it will do the wonders only when _FORTIFY_SOURCE is defined and > 0 -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From j.w.r.degoede at hhs.nl Wed Aug 29 17:01:29 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 29 Aug 2007 19:01:29 +0200 Subject: Netpanzer In-Reply-To: <46D5A63C.8080208@gmail.com> References: <10637.65.192.24.164.1188400943.squirrel@mail.jcomserv.net> <46D5A63C.8080208@gmail.com> Message-ID: <46D5A669.1020608@hhs.nl> Toshio Kuratomi wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jon Ciesla wrote: >> With release 0.8.2, upstream has merged the program and data tarballs. >> I'm thinking of merging netpanzer-data into netpanzer and obsoleting >> netpanzer-data. Any objections? >> > Isn't the netpanzer data large and not subject to as much change as the > engine? If so, there are still reasons to keep the data separate from > the game engine. > If upstream distributes things in one tarbal, they should be in one SRPM, and then splitting is no use. Also AFAIK netpanzer doesn't get frequent package updates. Regards, Hans From limb at jcomserv.net Wed Aug 29 16:42:15 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 29 Aug 2007 11:42:15 -0500 (CDT) Subject: Netpanzer In-Reply-To: <46D5A669.1020608@hhs.nl> References: <10637.65.192.24.164.1188400943.squirrel@mail.jcomserv.net> <46D5A63C.8080208@gmail.com> <46D5A669.1020608@hhs.nl> Message-ID: <18195.65.192.24.164.1188405735.squirrel@mail.jcomserv.net> > Toshio Kuratomi wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Jon Ciesla wrote: >>> With release 0.8.2, upstream has merged the program and data tarballs. >>> I'm thinking of merging netpanzer-data into netpanzer and obsoleting >>> netpanzer-data. Any objections? >>> >> Isn't the netpanzer data large and not subject to as much change as the >> engine? If so, there are still reasons to keep the data separate from >> the game engine. >> > > If upstream distributes things in one tarbal, they should be in one SRPM, > and > then splitting is no use. This rationale is also why xmoto-edit was split from xmoto when upstream split them. > Also AFAIK netpanzer doesn't get frequent package updates. My thoughts as well. I'll get to work, and keep watching this space for further discussion. Thanks! > Regards, > > Hans > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- novus ordo absurdum From a.badger at gmail.com Wed Aug 29 17:18:44 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 29 Aug 2007 10:18:44 -0700 Subject: Netpanzer In-Reply-To: <46D5A669.1020608@hhs.nl> References: <10637.65.192.24.164.1188400943.squirrel@mail.jcomserv.net> <46D5A63C.8080208@gmail.com> <46D5A669.1020608@hhs.nl> Message-ID: <46D5AA74.1070100@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hans de Goede wrote: > Toshio Kuratomi wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Jon Ciesla wrote: >>> With release 0.8.2, upstream has merged the program and data >>> tarballs. I'm thinking of merging netpanzer-data into netpanzer and >>> obsoleting >>> netpanzer-data. Any objections? >>> >> Isn't the netpanzer data large and not subject to as much change as the >> engine? If so, there are still reasons to keep the data separate from >> the game engine. >> > > If upstream distributes things in one tarbal, they should be in one > SRPM, and then splitting is no use. > It is of use to end users. Not having to redownload the data everytime the game engine is updated is a win for end users. The downside is that you end up with two SRPMs of equal size (due to the new tarball containing the data files both for the data and the engine package). > Also AFAIK netpanzer doesn't get frequent package updates. > That's been my experience in the past as well. But the real question is whether the data files are updated at the same frequency as the engine... which has several permutations as well: 1) Does upstream update the data files when they release a new netpanzer tarball or do releases get made where the data files are unchanged? 2) Is the package maintainer going to backport changes from upstream ever? ie: if a segfault or security vulnerability were discovered in netpanzer, will you backport a fix from upstream instead of waiting for them to make their next release? If these cases occur then end users will appreciate only having to get a new version of the engine without having to download the data. - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG1ap0X6yAic2E7kgRAhBIAJ9K82wxcTNnVeBLkSXpncYc/8R5FgCdFf8v 8hmH1En6fJh/8Sbq+LzoGgg= =puCA -----END PGP SIGNATURE----- From limb at jcomserv.net Wed Aug 29 17:07:12 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 29 Aug 2007 12:07:12 -0500 (CDT) Subject: Netpanzer In-Reply-To: <46D5AA74.1070100@gmail.com> References: <10637.65.192.24.164.1188400943.squirrel@mail.jcomserv.net> <46D5A63C.8080208@gmail.com> <46D5A669.1020608@hhs.nl> <46D5AA74.1070100@gmail.com> Message-ID: <40822.65.192.24.164.1188407232.squirrel@mail.jcomserv.net> > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hans de Goede wrote: >> Toshio Kuratomi wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Jon Ciesla wrote: >>>> With release 0.8.2, upstream has merged the program and data >>>> tarballs. I'm thinking of merging netpanzer-data into netpanzer and >>>> obsoleting >>>> netpanzer-data. Any objections? >>>> >>> Isn't the netpanzer data large and not subject to as much change as the >>> engine? If so, there are still reasons to keep the data separate from >>> the game engine. >>> >> >> If upstream distributes things in one tarbal, they should be in one >> SRPM, and then splitting is no use. >> > It is of use to end users. Not having to redownload the data everytime > the game engine is updated is a win for end users. > > The downside is that you end up with two SRPMs of equal size (due to the > new tarball containing the data files both for the data and the engine > package). > >> Also AFAIK netpanzer doesn't get frequent package updates. >> > That's been my experience in the past as well. But the real question is > whether the data files are updated at the same frequency as the > engine... which has several permutations as well: > > 1) Does upstream update the data files when they release a new netpanzer > tarball or do releases get made where the data files are unchanged? I recall a release of code and no update to data. Once. > 2) Is the package maintainer going to backport changes from upstream > ever? ie: if a segfault or security vulnerability were discovered in > netpanzer, will you backport a fix from upstream instead of > waiting for them to make their next release? I generally go with the new release, as upstream seems to respond fairly quickly. > If these cases occur then end users will appreciate only having to get a > new version of the engine without having to download the data. Agreed, but I think they do not, often anyway, for netpanzer. > - -Toshio > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFG1ap0X6yAic2E7kgRAhBIAJ9K82wxcTNnVeBLkSXpncYc/8R5FgCdFf8v > 8hmH1En6fJh/8Sbq+LzoGgg= > =puCA > -----END PGP SIGNATURE----- > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- novus ordo absurdum From mszpak at wp.pl Wed Aug 29 17:52:35 2007 From: mszpak at wp.pl (=?ISO-8859-2?Q?Marcin_Zaj=B1czkowski?=) Date: Wed, 29 Aug 2007 19:52:35 +0200 Subject: How to call default browser Message-ID: <46D5B263.1070205@wp.pl> Hi, I have a package where default browser to be used by a program should be defined in a Makefile. There is firefox typed by default, but it's always annoying when an app calls not your preferred browser. There can be default browser defined in Fedora, but how can I call it from a command line (I searched in alternatives, but without success)? Btw, there is no default *graphical* text editor. What do you think could be defined as that? Regards Marcin From sundaram at fedoraproject.org Wed Aug 29 17:53:42 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 29 Aug 2007 23:23:42 +0530 Subject: How to call default browser In-Reply-To: <46D5B263.1070205@wp.pl> References: <46D5B263.1070205@wp.pl> Message-ID: <46D5B2A6.7000409@fedoraproject.org> Marcin Zaj?czkowski wrote: > Hi, > > > I have a package where default browser to be used by a program should be > defined in a Makefile. There is firefox typed by default, but it's > always annoying when an app calls not your preferred browser. > There can be default browser defined in Fedora, but how can I call it > from a command line (I searched in alternatives, but without success)? xdg-open from xdg-utils might be useful. You can include a local copy. > Btw, there is no default *graphical* text editor. What do you think > could be defined as that? Gedit Rahul From jdennis at redhat.com Wed Aug 29 18:08:35 2007 From: jdennis at redhat.com (John Dennis) Date: Wed, 29 Aug 2007 14:08:35 -0400 Subject: How to call default browser In-Reply-To: <46D5B263.1070205@wp.pl> References: <46D5B263.1070205@wp.pl> Message-ID: <1188410915.8472.24.camel@finch.boston.redhat.com> On Wed, 2007-08-29 at 19:52 +0200, Marcin Zaj?czkowski wrote: > Hi, > > > I have a package where default browser to be used by a program should be > defined in a Makefile. There is firefox typed by default, but it's > always annoying when an app calls not your preferred browser. > There can be default browser defined in Fedora, but how can I call it > from a command line (I searched in alternatives, but without success)? try /usr/bin/htmlview in the package htmlview -- John Dennis From mmcgrath at redhat.com Wed Aug 29 18:14:33 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 29 Aug 2007 13:14:33 -0500 Subject: bugzilla confused on package ownership? In-Reply-To: <46D51DDF.7080106@redhat.com> References: <46D50551.4090603@redhat.com> <46D51DDF.7080106@redhat.com> Message-ID: <46D5B789.7090902@redhat.com> Joel Andres Granados wrote: > Eric Sandeen wrote: >> So, tonight I got a new bug for elfutils (262461). Interesting as I'm >> not the owner. >> >> Last night tsmetana assigned an e2fsprogs bug (258381) over to me, it >> originally went to him for some reason. >> >> I searched tonight and found one other newly opened e2fsprogs bug >> initially assigned to rvokal (254841), not me. >> >> Any idea what's going on here? >> >> And package owners might want to search for wayward bugs :) >> >> -Eric >> >> -- >> Fedora-maintainers mailing list >> Fedora-maintainers at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-maintainers >> > Seems this is due to the recent bugzilla changes. I have sent a mail > to kbaker > about the issue. > Regards > Also see - https://bugzilla.redhat.com/show_bug.cgi?id=264561 -Mike From tibbs at math.uh.edu Wed Aug 29 18:22:56 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 29 Aug 2007 13:22:56 -0500 Subject: Summary of the 2007-08-28 Packaging Committee meeting Message-ID: Meeting minutes and full logs of the packaging committee meeting which occurred on 2007-XXX are online: http://fedoraproject.org/wiki/Packaging/Minutes http://fedoraproject.org/wiki/Packaging/Minutes20070828 Executive summary: The following draft is now official an guideline, having been accepted by FESCO last week: * Guidelines for addons for the various versions of emacs: http://fedoraproject.org/wiki/PackagingDrafts/EmacsenAddOns These should be written into the guidelines soon if this hasn't already been done by the time you read this. Issues pending FESCO ratification: * The first three sections of http://fedoraproject.org/wiki/PackagingDrafts/PHP (Requires and Provides for PEAR and PECL packages and Macros and Scriptlets for PECL packages). * Accepted (7 - 0) * A clarification/rewording of the "File and Directory Ownership" guideline: https://www.redhat.com/archives/fedora-packaging/2007-August/msg00084.html * Accepted (5 - 0) Misc business: * Guidelines for packaging Python eggs: https://fedoraproject.org/wiki/PackagingDrafts/PythonEggs May be ready for a vote next week; please read the draft and prepare your comments. - J< From dkl at redhat.com Wed Aug 29 18:37:25 2007 From: dkl at redhat.com (Dave Lawrence) Date: Wed, 29 Aug 2007 14:37:25 -0400 Subject: bugzilla confused on package ownership? In-Reply-To: <46D5B789.7090902@redhat.com> References: <46D50551.4090603@redhat.com> <46D51DDF.7080106@redhat.com> <46D5B789.7090902@redhat.com> Message-ID: <46D5BCE5.7030901@redhat.com> Sorry for the problem with this. It should be resolved now in the enter_bug.cgi page. Please reassign any improperly assigned bug reports to the default component owner. Dave Mike McGrath wrote: > Joel Andres Granados wrote: >> Eric Sandeen wrote: >>> So, tonight I got a new bug for elfutils (262461). Interesting as I'm >>> not the owner. >>> >>> Last night tsmetana assigned an e2fsprogs bug (258381) over to me, it >>> originally went to him for some reason. >>> >>> I searched tonight and found one other newly opened e2fsprogs bug >>> initially assigned to rvokal (254841), not me. >>> >>> Any idea what's going on here? >>> >>> And package owners might want to search for wayward bugs :) >>> >>> -Eric >>> >>> -- >>> Fedora-maintainers mailing list >>> Fedora-maintainers at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-maintainers >>> >> Seems this is due to the recent bugzilla changes. I have sent a mail >> to kbaker >> about the issue. >> Regards >> > Also see - https://bugzilla.redhat.com/show_bug.cgi?id=264561 > > -Mike > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers From mszpak at wp.pl Wed Aug 29 18:37:36 2007 From: mszpak at wp.pl (=?ISO-8859-2?Q?Marcin_Zaj=B1czkowski?=) Date: Wed, 29 Aug 2007 20:37:36 +0200 Subject: How to call default text editor? (Was: Re: How to call default browser) In-Reply-To: <46D5B2A6.7000409@fedoraproject.org> References: <46D5B263.1070205@wp.pl> <46D5B2A6.7000409@fedoraproject.org> Message-ID: <46D5BCF0.7040907@wp.pl> On 2007-08-29 19:53:42 +0200, Rahul Sundaram wrote: > Marcin Zaj?czkowski wrote: >> I have a package where default browser to be used by a program should be >> defined in a Makefile. There is firefox typed by default, but it's >> always annoying when an app calls not your preferred browser. >> There can be default browser defined in Fedora, but how can I call it >> from a command line (I searched in alternatives, but without success)? > > xdg-open from xdg-utils might be useful. You can include a local copy. Nice. I'm thinking about adding it to Requires section (to be up-to-date in every Fedora release). >> Btw, there is no default *graphical* text editor. What do you think >> could be defined as that? > > Gedit Gnome is a default desktop environment, so KDE users have no luck ;). Is there planned to have also default text editor in Fedora? Thanks Marcin From wolters.liste at gmx.net Wed Aug 29 19:45:32 2007 From: wolters.liste at gmx.net (Roland Wolters) Date: Wed, 29 Aug 2007 21:45:32 +0200 Subject: Wiki discussions Message-ID: <200708292145.38028.wolters.liste@gmx.net> Hi list, where is the appropriate place to discuss pages in the wiki? I often come across pages where I miss important information or where I would like to mention an issue or two and I always fail to do so due to the fact that there is no separate discussion page (as for example the MediaWiki engine provides). However, with the current Wiki configuration (and as someone who is used to MediaWiki I already have enough problems with MoinMoin-like Wikis) this is not possible. So what to do? Roland -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From skvidal at fedoraproject.org Wed Aug 29 19:49:47 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 29 Aug 2007 15:49:47 -0400 Subject: Wiki discussions In-Reply-To: <200708292145.38028.wolters.liste@gmx.net> References: <200708292145.38028.wolters.liste@gmx.net> Message-ID: <1188416987.27085.158.camel@cutter> On Wed, 2007-08-29 at 21:45 +0200, Roland Wolters wrote: > Hi list, > > where is the appropriate place to discuss pages in the wiki? I often come > across pages where I miss important information or where I would like to > mention an issue or two and I always fail to do so due to the fact that there > is no separate discussion page (as for example the MediaWiki engine > provides). > However, with the current Wiki configuration (and as someone who is used to > MediaWiki I already have enough problems with MoinMoin-like Wikis) this is > not possible. So what to do? > It's possible to add discussion pages to a moin page. There's even a faq about it at moin. Check it out. -sv From pertusus at free.fr Wed Aug 29 20:32:38 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 29 Aug 2007 22:32:38 +0200 Subject: How to call default browser In-Reply-To: <46D5B263.1070205@wp.pl> References: <46D5B263.1070205@wp.pl> Message-ID: <20070829203238.GG4024@free.fr> On Wed, Aug 29, 2007 at 07:52:35PM +0200, Marcin Zaj?czkowski wrote: > Hi, > > > I have a package where default browser to be used by a program should be > defined in a Makefile. There is firefox typed by default, but it's > always annoying when an app calls not your preferred browser. > There can be default browser defined in Fedora, but how can I call it > from a command line (I searched in alternatives, but without success)? htmlview can be used for the browser, but the generic command is xdg-open. > Btw, there is no default *graphical* text editor. What do you think > could be defined as that? xdg-open could do that too. When opening a text file it will use the corresponding freedesktop application. In fact it could be used to open any type of file/URL. xdg-open will do the right thing in gnome, kde, xfce, and in any environment with /usr/bin/mimeopen from perl-File-MimeInfo, and lastly use $BROWSER htmlview:firefox:mozilla:netscape:links:lynx. -- Pat From jamatos at fc.up.pt Wed Aug 29 20:45:04 2007 From: jamatos at fc.up.pt (=?iso-8859-2?q?Jos=E9_Matos?=) Date: Wed, 29 Aug 2007 21:45:04 +0100 Subject: How to call default text editor? (Was: Re: How to call default browser) In-Reply-To: <46D5BCF0.7040907@wp.pl> References: <46D5B263.1070205@wp.pl> <46D5B2A6.7000409@fedoraproject.org> <46D5BCF0.7040907@wp.pl> Message-ID: <200708292145.05153.jamatos@fc.up.pt> On Wednesday 29 August 2007 19:37:36 Marcin Zaj?czkowski wrote: > >> Btw, there is no default *graphical* text editor. What do you think > >> could be defined as that? > > > > Gedit > > Gnome is a default desktop environment, so KDE users have no luck ;). > > Is there planned to have also default text editor in Fedora? xgd-open takes into account the desktop environment where you are so that we could have (we have) different defaults for different environments. You can overrule the defaults if you want to, that is the whole point of the exercise. :-) > Thanks > Marcin -- Jos? Ab?lio From gemi at bluewin.ch Wed Aug 29 22:29:36 2007 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Thu, 30 Aug 2007 00:29:36 +0200 Subject: How to call default browser In-Reply-To: <20070829203238.GG4024@free.fr> References: <46D5B263.1070205@wp.pl> <20070829203238.GG4024@free.fr> Message-ID: <1188426576.3554.1.camel@localhost.localdomain> On Wed, 2007-08-29 at 22:32 +0200, Patrice Dumas wrote: > > Btw, there is no default *graphical* text editor. What do you think > > could be defined as that? > > xdg-open could do that too. When opening a text file it will use the > corresponding freedesktop application. In fact it could be used to > open > any type of file/URL. However, it is probably meant to really use a text editor and not whatever is associated with the file type, so xdg-open is not adequate. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From pertusus at free.fr Wed Aug 29 22:51:09 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 30 Aug 2007 00:51:09 +0200 Subject: How to call default browser In-Reply-To: <1188426576.3554.1.camel@localhost.localdomain> References: <46D5B263.1070205@wp.pl> <20070829203238.GG4024@free.fr> <1188426576.3554.1.camel@localhost.localdomain> Message-ID: <20070829225109.GJ4024@free.fr> On Thu, Aug 30, 2007 at 12:29:36AM +0200, G?rard Milmeister wrote: > However, it is probably meant to really use a text editor and not > whatever is associated with the file type, so xdg-open is not adequate. Indeed if it is just to open a text editor and not to edit a file or if it is to edit a file which hasn't a mimetype corresponding with text/plain, xdg-open cannot be used. -- Pat From skvidal at fedoraproject.org Thu Aug 30 01:35:12 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 29 Aug 2007 21:35:12 -0400 Subject: Wiki discussions In-Reply-To: <1188436096.9369.2.camel@shuttle> References: <200708292145.38028.wolters.liste@gmx.net> <1188416987.27085.158.camel@cutter> <1188436096.9369.2.camel@shuttle> Message-ID: <1188437712.27085.193.camel@cutter> On Thu, 2007-08-30 at 02:08 +0100, Dimitris Glezos wrote: > ???? 29-08-2007, ????? ???, ??? ??? 15:49 -0400, ?/? seth vidal ??????: > > On Wed, 2007-08-29 at 21:45 +0200, Roland Wolters wrote: > > > Hi list, > > > > > > where is the appropriate place to discuss pages in the wiki? I often come > > > across pages where I miss important information or where I would like to > > > mention an issue or two and I always fail to do so due to the fact that there > > > is no separate discussion page (as for example the MediaWiki engine > > > provides). > > > However, with the current Wiki configuration (and as someone who is used to > > > MediaWiki I already have enough problems with MoinMoin-like Wikis) this is > > > not possible. So what to do? > > > > > > > It's possible to add discussion pages to a moin page. There's even a faq > > about it at moin. Check it out. > > Well, one could always add a `== Discussion ==` section at the bottom of > the page, right? Or a /Discussion page which is linked from the main > article. Linked discussion pages is what I was thinking about, yah. then again - the people to talk to about the wiki we're using is the websites and infrastructure groups. I like moin and I like python but I suspect I'll be fine using any of the open source wikis. -sv From bugs.michael at gmx.net Thu Aug 30 12:20:20 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 30 Aug 2007 14:20:20 +0200 Subject: Lots of pkgdb mail on commits list In-Reply-To: <46CEE9D1.2050108@gmail.com> References: <200708211906.22500.ville.skytta@iki.fi> <46CB1539.7060206@gmail.com> <200708212001.51268.ville.skytta@iki.fi> <46CCA6DE.7020806@gmail.com> <20070824000518.1c81270e.bugs.michael@gmx.net> <46CE1188.70501@gmail.com> <20070824121617.6d4acd36.bugs.michael@gmx.net> <46CEE9D1.2050108@gmail.com> Message-ID: <20070830142020.965f59be.bugs.michael@gmx.net> > It's topic: "All cvs commits" Is anybody else also missing some commit messages? I'm subscribed to [X] Replies (Details) [X] All cvs commits (Details) but what arrives here seems to be incomplete. Examples: I cannot find any of Robert Scheck's commits to bitlbee, https://www.redhat.com/archives/fedora-extras-commits/2007-August/msg10862.html and as another example I only received the import.log commit for xorg-x11-proto-devel, but not the subsequent messages, such as: https://www.redhat.com/archives/fedora-extras-commits/2007-August/msg10842.html or yesterday's commits to trac-bazaar-plugin are missing, too: https://www.redhat.com/archives/fedora-extras-commits/2007-August/msg10928.html From lkundrak at redhat.com Thu Aug 30 12:20:05 2007 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Thu, 30 Aug 2007 14:20:05 +0200 Subject: Weird build failure - fc6 In-Reply-To: <20070829001202.7fb191cd.bugs.michael@gmx.net> References: <46D49C61.80303@amiga-hardware.com> <20070829001202.7fb191cd.bugs.michael@gmx.net> Message-ID: <1188476405.26377.189.camel@pluto.englab.brq.redhat.com> On Wed, 2007-08-29 at 00:12 +0200, Michael Schwendt wrote: > On Tue, 28 Aug 2007 23:06:25 +0100, Ian Chapman wrote: > > > Hi all, > > > > Can any shed some light on why the following might have failed? I can't > > seem to see why, it looks like it's OK to me. > > > > http://buildsys.fedoraproject.org/logs/fedora-6-extras/36021-cbios-0.21-3.fc6/noarch/ > > > > Very likely related to last week's topic on this list. Join: > https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/125 That ticket is still unassigned and the number of packages that can't be build due to this seems to grow. -- Lubomir Kundrak (Security Response Team) Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic Registered in Brno under #CZ27690016 From dimitris at glezos.com Thu Aug 30 01:08:16 2007 From: dimitris at glezos.com (Dimitris Glezos) Date: Thu, 30 Aug 2007 02:08:16 +0100 Subject: Wiki discussions In-Reply-To: <1188416987.27085.158.camel@cutter> References: <200708292145.38028.wolters.liste@gmx.net> <1188416987.27085.158.camel@cutter> Message-ID: <1188436096.9369.2.camel@shuttle> ???? 29-08-2007, ????? ???, ??? ??? 15:49 -0400, ?/? seth vidal ??????: > On Wed, 2007-08-29 at 21:45 +0200, Roland Wolters wrote: > > Hi list, > > > > where is the appropriate place to discuss pages in the wiki? I often come > > across pages where I miss important information or where I would like to > > mention an issue or two and I always fail to do so due to the fact that there > > is no separate discussion page (as for example the MediaWiki engine > > provides). > > However, with the current Wiki configuration (and as someone who is used to > > MediaWiki I already have enough problems with MoinMoin-like Wikis) this is > > not possible. So what to do? > > > > It's possible to add discussion pages to a moin page. There's even a faq > about it at moin. Check it out. Well, one could always add a `== Discussion ==` section at the bottom of the page, right? Or a /Discussion page which is linked from the main article. -d -- 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 oliver at linux-kernel.at Thu Aug 30 08:20:32 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 30 Aug 2007 10:20:32 +0200 Subject: [pkgdb] mapserver: oliver has requested commit In-Reply-To: <200708300815.l7U8FZEs025587@app3.fedora.phx.redhat.com> References: <200708300815.l7U8FZEs025587@app3.fedora.phx.redhat.com> Message-ID: <46D67DD0.90106@linux-kernel.at> On 08/30/2007 10:15 AM, Oliver Falk wrote: > Oliver Falk (oliver) has requested the commit acl on mapserver (Fedora 7) > > To make changes to this package see: > https://admin.fedoraproject.org/pkgdb/packages/name/mapserver May please someone with ultimate pkgdb rights approve this! Thx, Oliver From buildsys at fedoraproject.org Thu Aug 30 13:46:47 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 30 Aug 2007 09:46:47 -0400 (EDT) Subject: Package EVR problems in Fedora 2007-08-30 Message-ID: <20070830134647.300F3152133@buildsys.fedoraproject.org> Axel Thimm AT ATrpms net: smart FE6 > F8 (0:0.50-47.fc6 > 0:0.50-46.fc8) F7-updates-testing > F8 (0:0.50-47.fc7 > 0:0.50-46.fc8) devrim AT commandprompt com: postgresql-pgpool-II FE6 > F7-updates (0:1.2-4.fc6 > 0:1.2-1.fc7) ed AT eh3 com: scrip FE6 > F7 (0:1.4-7.fc6 > 0:1.4-6.fc6) enrico scholz AT informatik tu-chemnitz de: fedora-usermgmt FE6 > F7 (0:0.10-1.fc6 > 0:0.9-2.fc7) libextractor FE6 > F7 (0:0.5.18a-1.fc6 > 0:0.5.17a-1.fc7) libtasn1 FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE5 > F8 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE6 > F7 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) FE6 > F8 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) mimetic FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7) FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7) util-vserver FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7) FE6 > F7 (0:0.30.213-2.fc6 > 0:0.30.212-3.fc7) xmlrpc-c FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7) FE6 > F7 (0:1.06.17-1.fc6 > 0:1.06.11-2.fc7) foolish AT guezz net: gtranslator F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8) perl-Net-Libdnet F7-updates > F8 (0:0.01-3.fc7.1 > 0:0.01-2.fc8) perl-Nmap-Parser F7-updates > F8 (0:1.05-4.fc7 > 0:1.05-3.fc8) tcptraceroute FE6 > F7-updates (0:1.5-0.2.beta7.fc6 > 0:1.5-0.1.beta7.fc7) jdennis AT redhat com: setroubleshoot F7-updates-testing > F8 (0:1.10.1-1.fc7 > 0:1.9.7-1.fc8) jeff AT ocjtech us: jrtplib FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) john AT ncphotography com: wordpress F7-updates-testing > F8 (0:2.2.2-0.fc7 > 0:2.2.1-1.fc7) karen-pease AT uiowa edu: fortune-firefly FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6) FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6) nethack-vultures FE6 > F7 (0:2.1.0-10.fc6 > 0:2.1.0-9.fc7) lemenkov AT gmail com: stratagus FE6 > F7 (0:2.2.4-1.fc6 > 0:2.2.3-1.fc7) lxtnow AT gmail com: gammu FE6 > F8 (0:1.12.92-1.fc6 > 0:1.11.0-1.fc8) F7-updates-testing > F8 (0:1.12.92-1.fc7 > 0:1.11.0-1.fc8) python-gammu FE6 > F7-updates (0:0.21-1.fc6 > 0:0.20-1.fc7) FE6 > F8 (0:0.21-1.fc6 > 0:0.20-1.fc7) specto FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8) F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8) mfleming+rpm AT enlartenment com: mcabber FE6 > F7-updates (0:0.9.3-3.fc6 > 0:0.9.3-2.fc7) mikeb AT redhat com: python-cheetah FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) nhorman AT redhat com: irqbalance FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6) FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7) notting AT redhat com: gnucash F7-updates-testing > F8 (0:2.2.1-2.fc7 > 0:2.2.0-2.fc8) rc040203 AT freenet de: perl-capitalization FE6 > F7 (0:0.03-5.fc6 > 0:0.03-4.fc6) perl-Class-Inspector FE6 > F7 (0:1.17-1.fc6 > 0:1.16-3.fc7) perl-Class-ReturnValue FE6 > F7 (0:0.54-1.fc6 > 0:0.53-6.fc7) rdieter AT math unl edu: gnupg2 F7-updates-testing > F8 (0:2.0.6-2.fc7 > 0:2.0.6-1.fc8) kdeartwork-extras FE6 > F7 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) FE6 > F8 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) kdegraphics-extras FE6 > F7 (0:3.5.7-1.fc6 > 0:3.5.5-1.fc7) FE6 > F8 (0:3.5.7-1.fc6 > 0:3.5.5-1.fc7) kdemultimedia-extras FE6 > F7 (6:3.5.7-1.fc6.5 > 6:3.5.6-5.fc7) FE6 > F8 (6:3.5.7-1.fc6.5 > 6:3.5.6-5.fc7) roland AT redhat com: monotone FE6 > F7 (0:0.36-2.fc6 > 0:0.35-3.fc7) sandmann AT redhat com: libgtop2 FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7) snecklifter AT gmail com: jokosher F7-updates > F8 (0:0.9-5.fc7 > 0:0.9-4.fc8) splinux25 AT gmail com: lostirc FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7) FE6 > F8 (0:0.4.6-3.fc6 > 0:0.4.6-2.fc8) wolfy AT nobugconsulting ro: ssmtp FE6 > F7 (0:2.61-11.3.fc6.1 > 0:2.61-11.1.fc7) ---------------------------------------------------------------------- fedora-usermgmt: enrico scholz AT informatik tu-chemnitz de FE6 > F7 (0:0.10-1.fc6 > 0:0.9-2.fc7) fortune-firefly: karen-pease AT uiowa edu FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6) FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6) gammu: lxtnow AT gmail com FE6 > F8 (0:1.12.92-1.fc6 > 0:1.11.0-1.fc8) F7-updates-testing > F8 (0:1.12.92-1.fc7 > 0:1.11.0-1.fc8) gnucash: notting AT redhat com F7-updates-testing > F8 (0:2.2.1-2.fc7 > 0:2.2.0-2.fc8) gnupg2: rdieter AT math unl edu F7-updates-testing > F8 (0:2.0.6-2.fc7 > 0:2.0.6-1.fc8) gtranslator: foolish AT guezz net F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8) irqbalance: nhorman AT redhat com FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6) FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7) jokosher: snecklifter AT gmail com F7-updates > F8 (0:0.9-5.fc7 > 0:0.9-4.fc8) jrtplib: jeff AT ocjtech us FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) kdeartwork-extras: rdieter AT math unl edu FE6 > F7 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) FE6 > F8 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) kdegraphics-extras: rdieter AT math unl edu FE6 > F7 (0:3.5.7-1.fc6 > 0:3.5.5-1.fc7) FE6 > F8 (0:3.5.7-1.fc6 > 0:3.5.5-1.fc7) kdemultimedia-extras: rdieter AT math unl edu FE6 > F7 (6:3.5.7-1.fc6.5 > 6:3.5.6-5.fc7) FE6 > F8 (6:3.5.7-1.fc6.5 > 6:3.5.6-5.fc7) libextractor: enrico scholz AT informatik tu-chemnitz de FE6 > F7 (0:0.5.18a-1.fc6 > 0:0.5.17a-1.fc7) libgtop2: sandmann AT redhat com FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7) libtasn1: enrico scholz AT informatik tu-chemnitz de FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE5 > F8 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE6 > F7 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) FE6 > F8 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) lostirc: splinux25 AT gmail com FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7) FE6 > F8 (0:0.4.6-3.fc6 > 0:0.4.6-2.fc8) mcabber: mfleming+rpm AT enlartenment com FE6 > F7-updates (0:0.9.3-3.fc6 > 0:0.9.3-2.fc7) mimetic: enrico scholz AT informatik tu-chemnitz de FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7) FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7) monotone: roland AT redhat com FE6 > F7 (0:0.36-2.fc6 > 0:0.35-3.fc7) nethack-vultures: karen-pease AT uiowa edu FE6 > F7 (0:2.1.0-10.fc6 > 0:2.1.0-9.fc7) perl-capitalization: rc040203 AT freenet de FE6 > F7 (0:0.03-5.fc6 > 0:0.03-4.fc6) perl-Class-Inspector: rc040203 AT freenet de FE6 > F7 (0:1.17-1.fc6 > 0:1.16-3.fc7) perl-Class-ReturnValue: rc040203 AT freenet de FE6 > F7 (0:0.54-1.fc6 > 0:0.53-6.fc7) perl-Net-Libdnet: foolish AT guezz net F7-updates > F8 (0:0.01-3.fc7.1 > 0:0.01-2.fc8) perl-Nmap-Parser: foolish AT guezz net F7-updates > F8 (0:1.05-4.fc7 > 0:1.05-3.fc8) postgresql-pgpool-II: devrim AT commandprompt com FE6 > F7-updates (0:1.2-4.fc6 > 0:1.2-1.fc7) python-cheetah: mikeb AT redhat com FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) python-gammu: lxtnow AT gmail com FE6 > F7-updates (0:0.21-1.fc6 > 0:0.20-1.fc7) FE6 > F8 (0:0.21-1.fc6 > 0:0.20-1.fc7) scrip: ed AT eh3 com FE6 > F7 (0:1.4-7.fc6 > 0:1.4-6.fc6) setroubleshoot: jdennis AT redhat com F7-updates-testing > F8 (0:1.10.1-1.fc7 > 0:1.9.7-1.fc8) smart: Axel Thimm AT ATrpms net FE6 > F8 (0:0.50-47.fc6 > 0:0.50-46.fc8) F7-updates-testing > F8 (0:0.50-47.fc7 > 0:0.50-46.fc8) specto: lxtnow AT gmail com FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8) F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8) ssmtp: wolfy AT nobugconsulting ro FE6 > F7 (0:2.61-11.3.fc6.1 > 0:2.61-11.1.fc7) stratagus: lemenkov AT gmail com FE6 > F7 (0:2.2.4-1.fc6 > 0:2.2.3-1.fc7) tcptraceroute: foolish AT guezz net FE6 > F7-updates (0:1.5-0.2.beta7.fc6 > 0:1.5-0.1.beta7.fc7) util-vserver: enrico scholz AT informatik tu-chemnitz de FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7) FE6 > F7 (0:0.30.213-2.fc6 > 0:0.30.212-3.fc7) wordpress: john AT ncphotography com F7-updates-testing > F8 (0:2.2.2-0.fc7 > 0:2.2.1-1.fc7) xmlrpc-c: enrico scholz AT informatik tu-chemnitz de FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7) FE6 > F7 (0:1.06.17-1.fc6 > 0:1.06.11-2.fc7) From bugs.michael at gmx.net Thu Aug 30 14:30:50 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 30 Aug 2007 16:30:50 +0200 Subject: Lots of pkgdb mail on commits list In-Reply-To: <20070830142020.965f59be.bugs.michael@gmx.net> References: <200708211906.22500.ville.skytta@iki.fi> <46CB1539.7060206@gmail.com> <200708212001.51268.ville.skytta@iki.fi> <46CCA6DE.7020806@gmail.com> <20070824000518.1c81270e.bugs.michael@gmx.net> <46CE1188.70501@gmail.com> <20070824121617.6d4acd36.bugs.michael@gmx.net> <46CEE9D1.2050108@gmail.com> <20070830142020.965f59be.bugs.michael@gmx.net> Message-ID: <20070830163050.81207bf9.bugs.michael@gmx.net> On Thu, 30 Aug 2007 14:20:20 +0200, Michael Schwendt wrote: > > It's topic: "All cvs commits" > > Is anybody else also missing some commit messages? > > I'm subscribed to > > [X] Replies (Details) > [X] All cvs commits (Details) > > but what arrives here seems to be incomplete. Perhaps a catch-all regexp at the bottom of the topic list is not possible? As in "if an earlier regexp in the list matches but user is not subscribed to the topic, the mail is thrown away and the rest of the regexp list is not evaluated". As a test I've now subscribed also to "Package commits" which comes earlier in the list. From skasal at redhat.com Thu Aug 30 16:57:02 2007 From: skasal at redhat.com (Stepan Kasal) Date: Thu, 30 Aug 2007 18:57:02 +0200 Subject: FESCo: Proposal to amend Exception List Message-ID: <20070830165702.GA3639@camelia.ucw.cz.> Dear FESCo members, I have written a detailed justification why certain packages should be added to the exception list. Please find it at: http://fedoraproject.org/wiki/StepanKasal/Add_to_Exception_List I'd be glad if I could present this on today's FESCo mtg. Cheers, Stepan Kasal From jgranado at redhat.com Thu Aug 30 16:58:35 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Thu, 30 Aug 2007 18:58:35 +0200 Subject: cvs ACLs and the package directory tree In-Reply-To: <46D437A2.6000201@gmail.com> References: <20070828142704.GC14627@neutrino.d.umn.edu> <46D437A2.6000201@gmail.com> Message-ID: <46D6F73B.40006@redhat.com> Toshio Kuratomi wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Alec T. Habig wrote: > >> Hi, >> >> Hopefully a simple case of new operator error, but in trying to update >> the new yum-cron package (the initial build of which has now propagated >> everywhere properly), I've rebuilt an updated SRPM, and am trying to >> import it using the common/cvs-import.sh script. This fails with: >> >> cvs commit... >> **** Access denied: habig is not in ACL for rpms/yum-cron >> cvs commit: Pre-commit check failed >> **** Access allowed: habig is in ACL for rpms/yum-cron/devel. >> cvs [commit aborted]: correct above errors first! >> >> So, a number of questions here. >> >> 1) Why do I need access to the package root directory, as far as I can >> tell all the actual package-related stuff I want to change is in the >> tagged subdirectories? >> >> 2) Why did it work in my initial builts for {devel, F-7, EL-5, FC-6} but >> is failing now? >> >> 3) Is using the cvs-import script still appropriate for maintenance as >> opposed to initial setup? All the how-tos and wiki's I could find >> are aimed at how to get things set up, but I couldn't find any info >> for the regular maintenance cycle. >> >> and lastly of course, >> >> 4) What do I need to do to get past this error and back to actually >> maintaining the package? >> >> > You're running into the issue documented here: > > https://www.redhat.com/archives/fedora-devel-list/2007-August/msg01122.html > > I haven't received any feedback on that script so I've gone ahead and > imported it into the common directory. cvs update to get the new > version into the cvs-import.sh script and give it a try. > > - -Toshio > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFG1DeiX6yAic2E7kgRAh1RAJ4lzknsjL8uGbIKmkr1FloEqxBdOQCdF2Wh > hFtB1TPgcwmtO5Sr5sKhuhc= > =mHfA > -----END PGP SIGNATURE----- > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > getting the same error in my commits as well. I am using the referenced cvs-commit file. anybody else having this problem, while using Toshios file? Thinking that it might be my account as well, Whom do I bug about my account? Regards -- Joel Andres Granados From mszpak at wp.pl Thu Aug 30 18:10:50 2007 From: mszpak at wp.pl (=?ISO-8859-2?Q?Marcin_Zaj=B1czkowski?=) Date: Thu, 30 Aug 2007 20:10:50 +0200 Subject: How to call default text editor? (Was: Re: How to call default browser) In-Reply-To: <20070829225109.GJ4024@free.fr> References: <46D5B263.1070205@wp.pl> <20070829203238.GG4024@free.fr> <1188426576.3554.1.camel@localhost.localdomain> <20070829225109.GJ4024@free.fr> Message-ID: <46D7082A.2040207@wp.pl> Thanks for all your comments. On 2007-08-30 0:51:09 +0200, Patrice Dumas wrote: > On Thu, Aug 30, 2007 at 12:29:36AM +0200, G?rard Milmeister wrote: >> However, it is probably meant to really use a text editor and not >> whatever is associated with the file type, so xdg-open is not adequate. > > Indeed if it is just to open a text editor and not to edit a file > or if it is to edit a file which hasn't a mimetype corresponding with > text/plain, xdg-open cannot be used. That program (ISO Master) in the newest version has an ability to View and Edit files. Author designed web browser (by default firefox) to be a viewer and some text editor (by default mousepad - I didn't have it installed) to be an editor. Idea with xdg-open for a view operation is very good. A File will be viewed by an assigned viewer (even default with original idea). But not with edit command. HTML , XML, file no extension despite of their mime type all should be opened in a text editor. Is there way to call default text editor and force it to open any (text) file? Something like: default-text-editor some-file Regards Marcin From lmacken at redhat.com Thu Aug 30 19:59:41 2007 From: lmacken at redhat.com (Luke Macken) Date: Thu, 30 Aug 2007 15:59:41 -0400 Subject: tor security updates In-Reply-To: <87y7g0hsu3.fsf@kosh.bigo.ensc.de> References: <20070818190820.GB18032@psilocybe.teonanacatl.org> <20070818212257.90333b25.bugs.michael@gmx.net> <20070818193636.GC18032@psilocybe.teonanacatl.org> <20070819111235.096e8a2c.bugs.michael@gmx.net> <87y7g0hsu3.fsf@kosh.bigo.ensc.de> Message-ID: <20070830195941.GE2944@crow.myhome.westell.com> On Sat, Aug 25, 2007 at 11:22:12AM +0200, Enrico Scholz wrote: > Michael Schwendt writes: > > > Enrico has had trouble before inside Bodhi, > > It simply does not work for me; probably due to some ad- and/or > javascript blocking (although the javascript console does not report > any error). E.g. the button right of the RPM name is always greyed > out, I can only add comments, rest of form entries are read-only and > I have only an 'Add comment' button but nothing which changes state > of RPM. Hrm? Bodhi should be able to work fine without javascript. It only uses it for some shiny stuffy, such as the auto-completion list, and some menus. The *icon* to the right of the package name is not a button, it's a spinner that becomes active when it is building the list of builds after typing in the name of a package. If you don't have javascript enabled, then simply type the full name of the build in the package field. Only the submitter of each update (or releng) will have the ability to perform actions against an update, aside from commenting. So, it sounds like there were a few misunderstandings about some parts of bodhi. However, I don't see how anything mentioned above would prevent you from submitting any updates. Please try and give it another shot, and let us know[0] if something doesn't work as expected. Thanks, luke [0]: https://hosted.fedoraproject.org/projects/bodhi/newticket From lmacken at redhat.com Thu Aug 30 20:01:07 2007 From: lmacken at redhat.com (Luke Macken) Date: Thu, 30 Aug 2007 16:01:07 -0400 Subject: tor security updates In-Reply-To: <20070819124834.d6d57d47.bugs.michael@gmx.net> References: <20070818190820.GB18032@psilocybe.teonanacatl.org> <20070818212257.90333b25.bugs.michael@gmx.net> <20070818193636.GC18032@psilocybe.teonanacatl.org> <20070819111235.096e8a2c.bugs.michael@gmx.net> <20070819102214.GA26730@crow> <20070819124834.d6d57d47.bugs.michael@gmx.net> Message-ID: <20070830200107.GF2944@crow.myhome.westell.com> On Sun, Aug 19, 2007 at 12:48:34PM +0200, Michael Schwendt wrote: > On Sun, 19 Aug 2007 06:22:14 -0400, Luke Macken wrote: > > > > Enrico has had trouble before inside Bodhi, the updates system, with > > > other packages. It wouldn't surprise me if he's unhappy with the extra > > > burden and waits for a convenient "make release" or similar. > > > > He hasn't reported any problems upstream, nor has he made the effort to > > comment on any of his updates regarding said issues. Many people have > > given feedback on his updates, and he receives an email for each one. > > If he is unhappy with the burden of being a maintainer, we need to > > figure out why so we can address it properly, and possibly find a > > co-maintainer willing to utilize our existing tools while we resolve the > > problem. > > Let me suggest the following: somebody from FESCo talks to Enrico and > other packagers, whose F7 updates are missing for a long time > according to the "EVR problems" report, to find out whether there are > any problems with the work-flow and hurdles. It belongs to the "make > sure we don't suck" area of activity. Missing updates, missing security > updates, upgrade problems and unresolved dependency problems make Fedora > look bad. Sounds like a plan. I'll try and generate a list of maintainers who haven't touched bodhi, or haven't been able to accomplish anything productive with it yet. luke From a.badger at gmail.com Thu Aug 30 20:41:06 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 30 Aug 2007 13:41:06 -0700 Subject: Lots of pkgdb mail on commits list In-Reply-To: <20070830142020.965f59be.bugs.michael@gmx.net> References: <200708211906.22500.ville.skytta@iki.fi> <46CB1539.7060206@gmail.com> <200708212001.51268.ville.skytta@iki.fi> <46CCA6DE.7020806@gmail.com> <20070824000518.1c81270e.bugs.michael@gmx.net> <46CE1188.70501@gmail.com> <20070824121617.6d4acd36.bugs.michael@gmx.net> <46CEE9D1.2050108@gmail.com> <20070830142020.965f59be.bugs.michael@gmx.net> Message-ID: <46D72B62.8000105@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schwendt wrote: >> It's topic: "All cvs commits" > > Is anybody else also missing some commit messages? > > I'm subscribed to > > [X] Replies (Details) > [X] All cvs commits (Details) > > but what arrives here seems to be incomplete. Examples: > > I cannot find any of Robert Scheck's commits to bitlbee, > https://www.redhat.com/archives/fedora-extras-commits/2007-August/msg10862.html > > and as another example I only received the import.log commit for > xorg-x11-proto-devel, but not the subsequent messages, such as: > https://www.redhat.com/archives/fedora-extras-commits/2007-August/msg10842.html > > or yesterday's commits to trac-bazaar-plugin are missing, too: > https://www.redhat.com/archives/fedora-extras-commits/2007-August/msg10928.html > Something is going on. I got this: https://www.redhat.com/archives/fedora-extras-commits/2007-August/msg11355.html But not this one right afterwards: https://www.redhat.com/archives/fedora-extras-commits/2007-August/msg11356.html Did that happen for you as well? (Investigating further) - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG1ytiX6yAic2E7kgRAhvCAJ97NZq2b8ewgwYnSwRYbPMwg7xKyACgnT1x YkUF5sWEX9hEzm6q/PU3QGc= =Adsj -----END PGP SIGNATURE----- From a.badger at gmail.com Thu Aug 30 23:04:08 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 30 Aug 2007 16:04:08 -0700 Subject: Lots of pkgdb mail on commits list In-Reply-To: <20070830163050.81207bf9.bugs.michael@gmx.net> References: <200708211906.22500.ville.skytta@iki.fi> <46CB1539.7060206@gmail.com> <200708212001.51268.ville.skytta@iki.fi> <46CCA6DE.7020806@gmail.com> <20070824000518.1c81270e.bugs.michael@gmx.net> <46CE1188.70501@gmail.com> <20070824121617.6d4acd36.bugs.michael@gmx.net> <46CEE9D1.2050108@gmail.com> <20070830142020.965f59be.bugs.michael@gmx.net> <20070830163050.81207bf9.bugs.michael@gmx.net> Message-ID: <46D74CE8.1010302@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schwendt wrote: > On Thu, 30 Aug 2007 14:20:20 +0200, Michael Schwendt wrote: > >>> It's topic: "All cvs commits" >> Is anybody else also missing some commit messages? >> >> I'm subscribed to >> >> [X] Replies (Details) >> [X] All cvs commits (Details) >> >> but what arrives here seems to be incomplete. > > Perhaps a catch-all regexp at the bottom of the topic list is not > possible? As in "if an earlier regexp in the list matches but user is not > subscribed to the topic, the mail is thrown away and the rest of the > regexp list is not evaluated". > > As a test I've now subscribed also to "Package commits" which comes > earlier in the list. > That would have been my thought as well except that I had tested that when I first started creating the topics. I think I've fixed it now although there's something I'm not understanding about the flavour of regular expression our mailman instance is using. The difference in subjects that are being caught and topics that aren't are in the whitespace: Caught: rpms/bzrtools/devel bzrtools.spec,1.20,1.21 Not caught: rpms/bzr/EL-5 .cvsignore, 1.12, 1.13 bzr.spec, 1.16, 1.17 sources, 1.12, 1.13 This is with any of the following regular expressions: ^.*,[ ]*([0-9]+\.[0-9]+|NONE),[ ]*([0-9]+\.[0-9]+|NONE)$ ^.*,[ ]?([0-9]+\.[0-9]+|NONE),[ ]?([0-9]+\.[0-9]+|NONE)$ ^.*, ?([0-9]+\.[0-9]+|NONE), ?([0-9]+\.[0-9]+|NONE)$ I've modified the regular expression to this: ^.*,[^,]*([0-9]+\.[0-9]+|NONE),[^,]*([0-9]+\.[0-9]+|NONE)$ and it now seems to catch both subjects with spaces between the version numbers and subjects without. - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG10znX6yAic2E7kgRAnLOAJ4/S7WmfQUhuXVlhQvCxEaADtQ6dQCbBA/K AfmULS2WFuVhu9mqUEp0ld4= =rSuc -----END PGP SIGNATURE----- From belegdol at gmail.com Thu Aug 30 23:05:45 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Fri, 31 Aug 2007 01:05:45 +0200 Subject: multilib woes - bug #262721 Message-ID: <46D74D49.40207@gmail.gom> Hi folks, to cut the story short: 0.6.x gchempaint was multilib for some reason, but due to program redesign, 0.8.x is not. This is causing conflicts upon an upgrade attempt. I tried adding Obsoletes: gchempaint < 0.8.0 to the spec, but it did not help. Does anybody have some suggestions how to handle this problem? Thanks in advance. Regards, Julian From a.badger at gmail.com Thu Aug 30 23:21:59 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 30 Aug 2007 16:21:59 -0700 Subject: Lots of pkgdb mail on commits list In-Reply-To: <46D74CE8.1010302@gmail.com> References: <200708211906.22500.ville.skytta@iki.fi> <46CB1539.7060206@gmail.com> <200708212001.51268.ville.skytta@iki.fi> <46CCA6DE.7020806@gmail.com> <20070824000518.1c81270e.bugs.michael@gmx.net> <46CE1188.70501@gmail.com> <20070824121617.6d4acd36.bugs.michael@gmx.net> <46CEE9D1.2050108@gmail.com> <20070830142020.965f59be.bugs.michael@gmx.net> <20070830163050.81207bf9.bugs.michael@gmx.net> <46D74CE8.1010302@gmail.com> Message-ID: <46D75117.7000700@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Toshio Kuratomi wrote: > > This is with any of the following regular expressions: > ^.*,[ ]*([0-9]+\.[0-9]+|NONE),[ ]*([0-9]+\.[0-9]+|NONE)$ > ^.*,[ ]?([0-9]+\.[0-9]+|NONE),[ ]?([0-9]+\.[0-9]+|NONE)$ > ^.*, ?([0-9]+\.[0-9]+|NONE), ?([0-9]+\.[0-9]+|NONE)$ > > I've modified the regular expression to this: > ^.*,[^,]*([0-9]+\.[0-9]+|NONE),[^,]*([0-9]+\.[0-9]+|NONE)$ > > and it now seems to catch both subjects with spaces between the version > numbers and subjects without. > I love how mailman can contradict me the moment I send out a message. This went through and I didn't get it: https://www.redhat.com/archives/fedora-extras-commits/2007-August/msg11481.html I still don't know why the regex isn't working but I'll go back to the recipe in my orginal mail since it's the only thing I can prove works and understand why: If you want to get everything except packagedb mail, select: [x] Package Commits (Details) [x] Replies (Details) [x] All cvs commits (Details) And: Do you want to receive messages that do not match any topic filter? [x] Yes - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG11EXX6yAic2E7kgRAirAAJ9NfVHvO80YfrTG4uiHF8IKjbe2cQCfTrWR XB6G3bkT0s6LGTQ/iAIQw4M= =7Gsp -----END PGP SIGNATURE----- From bugs.michael at gmx.net Thu Aug 30 23:50:15 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 31 Aug 2007 01:50:15 +0200 Subject: Lots of pkgdb mail on commits list In-Reply-To: <46D75117.7000700@gmail.com> References: <200708211906.22500.ville.skytta@iki.fi> <46CB1539.7060206@gmail.com> <200708212001.51268.ville.skytta@iki.fi> <46CCA6DE.7020806@gmail.com> <20070824000518.1c81270e.bugs.michael@gmx.net> <46CE1188.70501@gmail.com> <20070824121617.6d4acd36.bugs.michael@gmx.net> <46CEE9D1.2050108@gmail.com> <20070830142020.965f59be.bugs.michael@gmx.net> <20070830163050.81207bf9.bugs.michael@gmx.net> <46D74CE8.1010302@gmail.com> <46D75117.7000700@gmail.com> Message-ID: <20070831015015.ea952c5f.bugs.michael@gmx.net> On Thu, 30 Aug 2007 16:21:59 -0700, Toshio Kuratomi wrote: > Toshio Kuratomi wrote: > > > > This is with any of the following regular expressions: > > ^.*,[ ]*([0-9]+\.[0-9]+|NONE),[ ]*([0-9]+\.[0-9]+|NONE)$ > > ^.*,[ ]?([0-9]+\.[0-9]+|NONE),[ ]?([0-9]+\.[0-9]+|NONE)$ > > ^.*, ?([0-9]+\.[0-9]+|NONE), ?([0-9]+\.[0-9]+|NONE)$ > > > > I've modified the regular expression to this: > > ^.*,[^,]*([0-9]+\.[0-9]+|NONE),[^,]*([0-9]+\.[0-9]+|NONE)$ > > > > and it now seems to catch both subjects with spaces between the version > > numbers and subjects without. > > > I love how mailman can contradict me the moment I send out a message. > This went through and I didn't get it: > https://www.redhat.com/archives/fedora-extras-commits/2007-August/msg11481.html Since I had subscribed to "Package commits" a few hours ago, I've received that mail. But... would it be easier to modify the cvs syncmailer to add a topic marker to its subject line depending on the cvsroot? Then you could create a mailman topic for each cvsroot. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Aug 31 08:37:49 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 31 Aug 2007 10:37:49 +0200 Subject: Imminent package removal request : d4x Message-ID: <20070831103749.38cf20b9@python3.es.egwn.lan> Hi, Unless I'm mistaken, d4x (downloader for X) is licensed under the _original_ Artistic license. As such, it is not acceptable for inclusion in Fedora, so should be removed. I've notified the author a few weeks ago, asking him if he'd be willing to switch to the clarified or 2.0 versions of the Artistic license (which are acceptable for Fedora), but only got one first answer, nothing since... and nothing happened. So I have no other choice than to retire the package and ask rel-eng to remove it from development. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.22.5-71.fc7 Load : 0.58 0.72 0.83 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Aug 31 12:31:49 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 31 Aug 2007 14:31:49 +0200 Subject: Fedora branding and fedorapeople.org Message-ID: <20070831143149.68f63584@python3.es.egwn.lan> Hi, I've sort of "ripped off" some existing Fedora CSS to use on my own Fedora hosted page. I've looked at the "Trademark Guidelines" linked from that very page, but I have to admit that it's a bit too long and complex for me to understand. Since I'm not spinning off or forking anything, and using it as part of the Fedora project itself, is it okay for me to do so? http://thias.fedorapeople.org/ Just wondering :-) If not, I'll just have to spend a little time on creating a different layout. Matthias (If anyone is curious about the .htaccess I use for IndexOptions and SSI, feel free to peek around my home directory, the .htaccess should be readable through ssh, unlike through http) -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.22.5-71.fc7 Load : 0.45 0.63 0.58 From tla at rasmil.dk Fri Aug 31 12:51:52 2007 From: tla at rasmil.dk (Tim Lauridsen) Date: Fri, 31 Aug 2007 14:51:52 +0200 Subject: Fedora branding and fedorapeople.org In-Reply-To: <20070831143149.68f63584@python3.es.egwn.lan> References: <20070831143149.68f63584@python3.es.egwn.lan> Message-ID: <46D80EE8.9030408@rasmil.dk> Matthias Saou wrote: > Hi, > > I've sort of "ripped off" some existing Fedora CSS to use on my own > Fedora hosted page. I've looked at the "Trademark Guidelines" linked > from that very page, but I have to admit that it's a bit too long and > complex for me to understand. > > Since I'm not spinning off or forking anything, and using it as part of > the Fedora project itself, is it okay for me to do so? > > http://thias.fedorapeople.org/ > > Just wondering :-) If not, I'll just have to spend a little time on > creating a different layout. > > Matthias > > (If anyone is curious about the .htaccess I use for IndexOptions and > SSI, feel free to peek around my home directory, the .htaccess should > be readable through ssh, unlike through http) > > Look great, i just had to try it out for my own fedora people page. http://timlau.fedorapeople.org/ Tim From oliver at linux-kernel.at Fri Aug 31 13:03:07 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 31 Aug 2007 15:03:07 +0200 Subject: maven... Message-ID: <46D8118B.4020109@linux-kernel.at> Hi! As someone tried to rebuild maven stuff in dist-f8? If I look into koji, it doesn't seem so. However, there are for sure problems with ant 1.7. ant 1.6.5 is good :-) I don't know if there might be other problems as well, but I would suggest to try rebuilding maven stuff... Best, Oliver From fnasser at redhat.com Fri Aug 31 13:13:53 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Fri, 31 Aug 2007 09:13:53 -0400 Subject: maven... In-Reply-To: <46D8118B.4020109@linux-kernel.at> References: <46D8118B.4020109@linux-kernel.at> Message-ID: <46D81411.4020908@redhat.com> OK, Deepak and I will take a look. Oliver Falk wrote: > Hi! > > As someone tried to rebuild maven stuff in dist-f8? If I look into koji, > it doesn't seem so. > > However, there are for sure problems with ant 1.7. ant 1.6.5 is good :-) > > I don't know if there might be other problems as well, but I would > suggest to try rebuilding maven stuff... > > Best, > Oliver > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From tcallawa at redhat.com Fri Aug 31 14:10:27 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 31 Aug 2007 10:10:27 -0400 Subject: Imminent package removal request : d4x In-Reply-To: <20070831103749.38cf20b9@python3.es.egwn.lan> References: <20070831103749.38cf20b9@python3.es.egwn.lan> Message-ID: <1188569428.7665.6.camel@new-host> On Fri, 2007-08-31 at 10:37 +0200, Matthias Saou wrote: > Hi, > > Unless I'm mistaken, d4x (downloader for X) is licensed under the > _original_ Artistic license. As such, it is not acceptable for > inclusion in Fedora, so should be removed. > > I've notified the author a few weeks ago, asking him if he'd be willing > to switch to the clarified or 2.0 versions of the Artistic license > (which are acceptable for Fedora), but only got one first answer, > nothing since... and nothing happened. > > So I have no other choice than to retire the package and ask rel-eng to > remove it from development. Before we pull it (which we can do), if you want to try to keep it in Fedora, send one last email to the upstream maintainer, letting him know that unless he relicenses it (either to an acceptable Artistic alternative, or dual licensed with something acceptable), we will be removing it. ~spot From martin.sourada at seznam.cz Fri Aug 31 14:12:29 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Fri, 31 Aug 2007 16:12:29 +0200 Subject: Fedora branding and fedorapeople.org In-Reply-To: <20070831143149.68f63584@python3.es.egwn.lan> References: <20070831143149.68f63584@python3.es.egwn.lan> Message-ID: <1188569549.3097.28.camel@pc-notebook> On Fri, 2007-08-31 at 14:31 +0200, Matthias Saou wrote: > Hi, > > I've sort of "ripped off" some existing Fedora CSS to use on my own > Fedora hosted page. I've looked at the "Trademark Guidelines" linked > from that very page, but I have to admit that it's a bit too long and > complex for me to understand. > > Since I'm not spinning off or forking anything, and using it as part of > the Fedora project itself, is it okay for me to do so? > > http://thias.fedorapeople.org/ > > Just wondering :-) If not, I'll just have to spend a little time on > creating a different layout. > > Matthias > > (If anyone is curious about the .htaccess I use for IndexOptions and > SSI, feel free to peek around my home directory, the .htaccess should > be readable through ssh, unlike through http) > Great! Thanks for the work. I used it as well, only I made it xhtml 1.1 valid (well with a mime type warning, but when I use xhtml extensions it seems to fail quite fast even to render, as you can see on /index.xhtml... XML types probably need different including) :) http://mso.fedorapeople.org/ Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Aug 31 14:23:33 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 31 Aug 2007 16:23:33 +0200 Subject: Imminent package removal request : d4x In-Reply-To: <1188569428.7665.6.camel@new-host> References: <20070831103749.38cf20b9@python3.es.egwn.lan> <1188569428.7665.6.camel@new-host> Message-ID: <20070831162333.3bfad6fa@python3.es.egwn.lan> Tom "spot" Callaway wrote : > On Fri, 2007-08-31 at 10:37 +0200, Matthias Saou wrote: > > Hi, > > > > Unless I'm mistaken, d4x (downloader for X) is licensed under the > > _original_ Artistic license. As such, it is not acceptable for > > inclusion in Fedora, so should be removed. > > > > I've notified the author a few weeks ago, asking him if he'd be willing > > to switch to the clarified or 2.0 versions of the Artistic license > > (which are acceptable for Fedora), but only got one first answer, > > nothing since... and nothing happened. > > > > So I have no other choice than to retire the package and ask rel-eng to > > remove it from development. > > Before we pull it (which we can do), if you want to try to keep it in > Fedora, send one last email to the upstream maintainer, letting him know > that unless he relicenses it (either to an acceptable Artistic > alternative, or dual licensed with something acceptable), we will be > removing it. I've already sent two such emails over the past few weeks, hoping something would happen, but got no answer to those (hence "only got one first answer", but I could have detailed). I'll send a third now, just in case... who knows, with summer holidays and such. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.22.5-71.fc7 Load : 1.48 1.46 1.51 From skvidal at fedoraproject.org Fri Aug 31 14:27:58 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 31 Aug 2007 10:27:58 -0400 Subject: Fedora branding and fedorapeople.org In-Reply-To: <1188569549.3097.28.camel@pc-notebook> References: <20070831143149.68f63584@python3.es.egwn.lan> <1188569549.3097.28.camel@pc-notebook> Message-ID: <1188570478.27085.412.camel@cutter> On Fri, 2007-08-31 at 16:12 +0200, Martin Sourada wrote: > On Fri, 2007-08-31 at 14:31 +0200, Matthias Saou wrote: > > Hi, > > > > I've sort of "ripped off" some existing Fedora CSS to use on my own > > Fedora hosted page. I've looked at the "Trademark Guidelines" linked > > from that very page, but I have to admit that it's a bit too long and > > complex for me to understand. > > > > Since I'm not spinning off or forking anything, and using it as part of > > the Fedora project itself, is it okay for me to do so? > > > > http://thias.fedorapeople.org/ > > > > Just wondering :-) If not, I'll just have to spend a little time on > > creating a different layout. > > > > Matthias > > > > (If anyone is curious about the .htaccess I use for IndexOptions and > > SSI, feel free to peek around my home directory, the .htaccess should > > be readable through ssh, unlike through http) > > > Okay - the above look really good, imo. What if we made them the default for index outputs for the system? -sv From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Aug 31 14:33:04 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 31 Aug 2007 16:33:04 +0200 Subject: Fedora branding and fedorapeople.org In-Reply-To: <1188570478.27085.412.camel@cutter> References: <20070831143149.68f63584@python3.es.egwn.lan> <1188569549.3097.28.camel@pc-notebook> <1188570478.27085.412.camel@cutter> Message-ID: <20070831163304.41055e4c@python3.es.egwn.lan> seth vidal wrote : > > On Fri, 2007-08-31 at 16:12 +0200, Martin Sourada wrote: > > On Fri, 2007-08-31 at 14:31 +0200, Matthias Saou wrote: > > > Hi, > > > > > > I've sort of "ripped off" some existing Fedora CSS to use on my own > > > Fedora hosted page. I've looked at the "Trademark Guidelines" linked > > > from that very page, but I have to admit that it's a bit too long and > > > complex for me to understand. > > > > > > Since I'm not spinning off or forking anything, and using it as part of > > > the Fedora project itself, is it okay for me to do so? > > > > > > http://thias.fedorapeople.org/ > > > > > > Just wondering :-) If not, I'll just have to spend a little time on > > > creating a different layout. > > > > > > Matthias > > > > > > (If anyone is curious about the .htaccess I use for IndexOptions and > > > SSI, feel free to peek around my home directory, the .htaccess should > > > be readable through ssh, unlike through http) > > > > > > > Okay - the above look really good, imo. What if we made them the default > for index outputs for the system? Dunno... maybe some people like the default apache listings. And some things are a matter of taste (I prefer without the icons for instance). But the default "AllowOverride All" is already pretty cool, as it lets anyone customize their page quite a bit. Either way, I don't really care, since we'll all still be able to override whatever we want ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.22.5-71.fc7 Load : 2.03 1.57 1.47 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Aug 31 14:26:10 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 31 Aug 2007 16:26:10 +0200 Subject: Imminent package removal request : d4x In-Reply-To: <20070831162333.3bfad6fa@python3.es.egwn.lan> References: <20070831103749.38cf20b9@python3.es.egwn.lan> <1188569428.7665.6.camel@new-host> <20070831162333.3bfad6fa@python3.es.egwn.lan> Message-ID: <20070831162610.1690aeae@python3.es.egwn.lan> Matthias Saou wrote : > Tom "spot" Callaway wrote : > > > On Fri, 2007-08-31 at 10:37 +0200, Matthias Saou wrote: > > > Hi, > > > > > > Unless I'm mistaken, d4x (downloader for X) is licensed under the > > > _original_ Artistic license. As such, it is not acceptable for > > > inclusion in Fedora, so should be removed. > > > > > > I've notified the author a few weeks ago, asking him if he'd be willing > > > to switch to the clarified or 2.0 versions of the Artistic license > > > (which are acceptable for Fedora), but only got one first answer, > > > nothing since... and nothing happened. > > > > > > So I have no other choice than to retire the package and ask rel-eng to > > > remove it from development. > > > > Before we pull it (which we can do), if you want to try to keep it in > > Fedora, send one last email to the upstream maintainer, letting him know > > that unless he relicenses it (either to an acceptable Artistic > > alternative, or dual licensed with something acceptable), we will be > > removing it. > > I've already sent two such emails over the past few weeks, hoping > something would happen, but got no answer to those (hence "only got one > first answer", but I could have detailed). > > I'll send a third now, just in case... who knows, with summer holidays > and such. Good news, everyone! "Oh, sorry, was busy a bit. I' try to release new version with Artistics2 license in a week. Sorry again for delays" Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.22.5-71.fc7 Load : 0.98 1.21 1.40 From skvidal at fedoraproject.org Fri Aug 31 14:37:43 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 31 Aug 2007 10:37:43 -0400 Subject: Fedora branding and fedorapeople.org In-Reply-To: <20070831163304.41055e4c@python3.es.egwn.lan> References: <20070831143149.68f63584@python3.es.egwn.lan> <1188569549.3097.28.camel@pc-notebook> <1188570478.27085.412.camel@cutter> <20070831163304.41055e4c@python3.es.egwn.lan> Message-ID: <1188571063.27085.414.camel@cutter> On Fri, 2007-08-31 at 16:33 +0200, Matthias Saou wrote: > Dunno... maybe some people like the default apache listings. And some > things are a matter of taste (I prefer without the icons for instance). > > But the default "AllowOverride All" is already pretty cool, as it lets > anyone customize their page quite a bit. > Well the AllowOverride isn't ALL it is: AllowOverride FileInfo AuthConfig Limit Indexes -sv From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Aug 31 14:47:44 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 31 Aug 2007 16:47:44 +0200 Subject: Fedora branding and fedorapeople.org In-Reply-To: <1188571063.27085.414.camel@cutter> References: <20070831143149.68f63584@python3.es.egwn.lan> <1188569549.3097.28.camel@pc-notebook> <1188570478.27085.412.camel@cutter> <20070831163304.41055e4c@python3.es.egwn.lan> <1188571063.27085.414.camel@cutter> Message-ID: <20070831164744.5190d521@python3.es.egwn.lan> seth vidal wrote : > On Fri, 2007-08-31 at 16:33 +0200, Matthias Saou wrote: > > > Dunno... maybe some people like the default apache listings. And some > > things are a matter of taste (I prefer without the icons for instance). > > > > But the default "AllowOverride All" is already pretty cool, as it lets > > anyone customize their page quite a bit. > > Well the AllowOverride isn't ALL it is: > > AllowOverride FileInfo AuthConfig Limit Indexes My bad :-) About the index, if the default is changed to something with a nice Fedora look, then it should probably only contain the header and footer, since a side menu wouldn't make much sense, except maybe if it's something very simple like only "Parent Directory" (../) and "Website Home" (/). If anyone feels like cooking something up, the html/css was taken from the pkgdb page, and the IndexOptions from : http://httpd.apache.org/docs/2.2/mod/mod_autoindex.html#indexoptions Seems like it would be pretty trivial to put the header, footer, css and image somewhere and choose default index options to go with them. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.22.5-71.fc7 Load : 3.95 2.87 1.94 From oliver at linux-kernel.at Fri Aug 31 15:26:38 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 31 Aug 2007 17:26:38 +0200 Subject: maven... In-Reply-To: <46D81411.4020908@redhat.com> References: <46D8118B.4020109@linux-kernel.at> <46D81411.4020908@redhat.com> Message-ID: <46D8332E.8070501@linux-kernel.at> Fernando Nasser schrieb: > OK, Deepak and I will take a look. Geat. Thx. -of > Oliver Falk wrote: >> Hi! >> >> As someone tried to rebuild maven stuff in dist-f8? If I look into koji, >> it doesn't seem so. >> >> However, there are for sure problems with ant 1.7. ant 1.6.5 is good :-) >> >> I don't know if there might be other problems as well, but I would >> suggest to try rebuilding maven stuff... >> >> Best, >> Oliver >> >> -- >> Fedora-maintainers mailing list >> Fedora-maintainers at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-maintainers >> > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers From jspaleta at gmail.com Fri Aug 31 19:08:00 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 31 Aug 2007 11:08:00 -0800 Subject: Fedora branding and fedorapeople.org In-Reply-To: <1188570478.27085.412.camel@cutter> References: <20070831143149.68f63584@python3.es.egwn.lan> <1188569549.3097.28.camel@pc-notebook> <1188570478.27085.412.camel@cutter> Message-ID: <604aa7910708311208h770e59b0n1be27f7e25025642@mail.gmail.com> On 8/31/07, seth vidal wrote: > Okay - the above look really good, imo. What if we made them the default > for index outputs for the system? I'm fine with site-specific defaults which are not apache defaults. -jef From skvidal at fedoraproject.org Fri Aug 31 19:57:18 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 31 Aug 2007 15:57:18 -0400 Subject: Fedora branding and fedorapeople.org In-Reply-To: <604aa7910708311208h770e59b0n1be27f7e25025642@mail.gmail.com> References: <20070831143149.68f63584@python3.es.egwn.lan> <1188569549.3097.28.camel@pc-notebook> <1188570478.27085.412.camel@cutter> <604aa7910708311208h770e59b0n1be27f7e25025642@mail.gmail.com> Message-ID: <1188590238.29226.35.camel@cutter> On Fri, 2007-08-31 at 11:08 -0800, Jeff Spaleta wrote: > On 8/31/07, seth vidal wrote: > > Okay - the above look really good, imo. What if we made them the default > > for index outputs for the system? > > > I'm fine with site-specific defaults which are not apache defaults. > oh - yah - I just meant for fedorapeople.org sites. I'll go bug websites list, too -sv From dbhole at redhat.com Fri Aug 31 20:27:15 2007 From: dbhole at redhat.com (Deepak Bhole) Date: Fri, 31 Aug 2007 16:27:15 -0400 Subject: maven... In-Reply-To: <46D8118B.4020109@linux-kernel.at> References: <46D8118B.4020109@linux-kernel.at> Message-ID: <1188592035.7886.23.camel@tocatta.toronto.redhat.com> On Fri, 2007-08-31 at 15:03 +0200, Oliver Falk wrote: > Hi! > > As someone tried to rebuild maven stuff in dist-f8? If I look into koji, > it doesn't seem so. > I briefly looked into it a couple of days ago. I got side-tracked with some other stuff, but plan to get back to maven shortly. > However, there are for sure problems with ant 1.7. ant 1.6.5 is good :-) Yes, you're right unfortunately :( there are some compatibility issues in modules like maven-artifact-ant that have classes inheriting from ant.jar, as the api in ant has changed. I am going to try to patch them. > > I don't know if there might be other problems as well, but I would > suggest to try rebuilding maven stuff... > By biggest worry is ppc. Last time it was tried, there were failures specific to ppc. While it can be exclude arch'd, I would really like to avoid doing that. Here is the ppc bug for the record: https://bugzilla.redhat.com/show_bug.cgi?id=239123 Cheers, Deepak From dwmw2 at infradead.org Fri Aug 31 23:09:47 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 01 Sep 2007 00:09:47 +0100 Subject: maven... In-Reply-To: <1188592035.7886.23.camel@tocatta.toronto.redhat.com> References: <46D8118B.4020109@linux-kernel.at> <1188592035.7886.23.camel@tocatta.toronto.redhat.com> Message-ID: <1188601787.985.260.camel@pmac.infradead.org> On Fri, 2007-08-31 at 16:27 -0400, Deepak Bhole wrote: > By biggest worry is ppc. Last time it was tried, there were failures > specific to ppc. While it can be exclude arch'd, I would really like to > avoid doing that. > > Here is the ppc bug for the record: > https://bugzilla.redhat.com/show_bug.cgi?id=239123 I went rushing to check on that... and then realised you meant ppc64, not ppc. We keep the ppc ExcludeArch list fairly much empty, but ppc64 userspace is less of a priority (since we actually run everything 32-bit even on ppc64 hardware, unless there's some real _benefit_ to using 64-bit userspace). I had a brief look, but even with bootstrap mode enabled it seems to require maven-* packages which aren't available. If you need an account on a suitable machine to poke at this, let me have a SSH public key. -- dwmw2