From j.w.r.degoede at hhs.nl Tue Apr 1 07:41:34 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 01 Apr 2008 09:41:34 +0200 Subject: [Fedora-packaging] Meeting Reminder: April 1, 2008 In-Reply-To: <1206975866.14969.652.camel@beck.corsepiu.local> References: <1206975130.2939.25.camel@localhost.localdomain> <1206975866.14969.652.camel@beck.corsepiu.local> Message-ID: <47F1E72E.9060700@hhs.nl> Ralf Corsepius wrote: > On Mon, 2008-03-31 at 10:52 -0400, Tom "spot" Callaway wrote: >> Just a reminder to FPC members: We will meet tomorrow, April 1, 2008 to >> try to work through more of the pending drafts. >> >> Sadly, this is not an April Fools joke. > At what time of day? > > Europe has changed to DST last weekend. > > => 17:00 UTC (19:00 CEST) would hardly possible for me to join. > Hmm, I rather like the move from 18 -> 19 CEST with the DST kicking into effect, that gives me just enough time to put the children in bed before the meeting starts. Regards, Hans From rc040203 at freenet.de Tue Apr 1 07:54:11 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 01 Apr 2008 09:54:11 +0200 Subject: [Fedora-packaging] Meeting Reminder: April 1, 2008 In-Reply-To: <47F1E72E.9060700@hhs.nl> References: <1206975130.2939.25.camel@localhost.localdomain> <1206975866.14969.652.camel@beck.corsepiu.local> <47F1E72E.9060700@hhs.nl> Message-ID: <1207036451.14969.792.camel@beck.corsepiu.local> On Tue, 2008-04-01 at 09:41 +0200, Hans de Goede wrote: > Ralf Corsepius wrote: > > On Mon, 2008-03-31 at 10:52 -0400, Tom "spot" Callaway wrote: > >> Just a reminder to FPC members: We will meet tomorrow, April 1, 2008 to > >> try to work through more of the pending drafts. > >> > >> Sadly, this is not an April Fools joke. > > At what time of day? > > > > Europe has changed to DST last weekend. > > > > => 17:00 UTC (19:00 CEST) would hardly possible for me to join. > > > > Hmm, I rather like the move from 18 -> 19 CEST with the DST kicking into > effect, that gives me just enough time to put the children in bed before the > meeting starts. 19:00-21:00 local-time is my family's dinner-time. It will cause me to quit the meeting very early or even prevent me to join at all. This had been an issue ever since FPC exists, and had FPC to decide to switch its meeting time when DST switches. Unfortunately, there is a window of very few weeks (IIRC, 1 or 2) between the dates the US and Europe switches - ATM, we are midst of one of these window. Ralf From j.w.r.degoede at hhs.nl Tue Apr 1 09:29:22 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 01 Apr 2008 11:29:22 +0200 Subject: [Fedora-packaging] Meeting Reminder: April 1, 2008 In-Reply-To: <1207036451.14969.792.camel@beck.corsepiu.local> References: <1206975130.2939.25.camel@localhost.localdomain> <1206975866.14969.652.camel@beck.corsepiu.local> <47F1E72E.9060700@hhs.nl> <1207036451.14969.792.camel@beck.corsepiu.local> Message-ID: <47F20072.8090104@hhs.nl> Ralf Corsepius wrote: > On Tue, 2008-04-01 at 09:41 +0200, Hans de Goede wrote: >> Ralf Corsepius wrote: >>> On Mon, 2008-03-31 at 10:52 -0400, Tom "spot" Callaway wrote: >>>> Just a reminder to FPC members: We will meet tomorrow, April 1, 2008 to >>>> try to work through more of the pending drafts. >>>> >>>> Sadly, this is not an April Fools joke. >>> At what time of day? >>> >>> Europe has changed to DST last weekend. >>> >>> => 17:00 UTC (19:00 CEST) would hardly possible for me to join. >>> >> Hmm, I rather like the move from 18 -> 19 CEST with the DST kicking into >> effect, that gives me just enough time to put the children in bed before the >> meeting starts. > > 19:00-21:00 local-time is my family's dinner-time. It will cause me to > quit the meeting very early or even prevent me to join at all. > > This had been an issue ever since FPC exists, and had FPC to decide to > switch its meeting time when DST switches. > Well 18:00 has worked reasonably for me sofar, so I can live with 16:00 UTC / 18:00 CEST too. Regards, Hans From a.badger at gmail.com Tue Apr 1 18:36:00 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 01 Apr 2008 11:36:00 -0700 Subject: [Fedora-packaging] Let's discuss... Javascript! Message-ID: <47F28090.90007@gmail.com> This has been kicking around in my head for a while but I haven't been able to come to a conclusion on my own. As we start to ship more web apps and more web frameworks we are shipping more javascript files. Some of these files are not app specific but libraries of code that have their own upstream releases. This raises questions about whether we should be packaging these libraries separate from the applications. I've written up some thoughts about the pros and cons of this here: http://fedoraproject.org/wiki/PackagingDrafts/Javascript If discussion here leads me to the conclusion that we do want to treat javascript libraries like other libraries in the system, I'll formalize that into something appropriate for the Guidelines. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From tibbs at math.uh.edu Tue Apr 1 19:14:32 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 01 Apr 2008 14:14:32 -0500 Subject: [Fedora-packaging] Let's discuss... Javascript! In-Reply-To: <47F28090.90007@gmail.com> References: <47F28090.90007@gmail.com> Message-ID: >>>>> "TK" == Toshio Kuratomi writes: TK> If discussion here leads me to the conclusion that we do want to TK> treat javascript libraries like other libraries in the system, TK> I'll formalize that into something appropriate for the Guidelines. I agree that we should try to do this when it makes sense. Unfortunately codifying "makes sense" into a guideline is kind of difficult. There is already at least one javascript package in Fedora: MochiKit. The package is clean and is something that we should look at when writing guidelines. - J< From a.badger at gmail.com Tue Apr 1 20:41:16 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 01 Apr 2008 13:41:16 -0700 Subject: [Fedora-packaging] Let's discuss... Javascript! In-Reply-To: References: <47F28090.90007@gmail.com> Message-ID: <47F29DEC.1000106@gmail.com> Jason L Tibbitts III wrote: >>>>>> "TK" == Toshio Kuratomi writes: > > TK> If discussion here leads me to the conclusion that we do want to > TK> treat javascript libraries like other libraries in the system, > TK> I'll formalize that into something appropriate for the Guidelines. > > I agree that we should try to do this when it makes sense. > Unfortunately codifying "makes sense" into a guideline is kind of > difficult. > > There is already at least one javascript package in Fedora: MochiKit. > The package is clean and is something that we should look at when > writing guidelines. > Added a bit of the MochiKit spec as a template. BTW: We have Ivazquez to thank for the excellent work on that package :-) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From tibbs at math.uh.edu Fri Apr 4 18:29:45 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 04 Apr 2008 13:29:45 -0500 Subject: [Fedora-packaging] Lua Message-ID: I see a few Lua packages have appeared in the review queue today. I checked out the specs and they all seem very clean. There are a few issues (/usr/lib/lua seems to be unowned in rawhide, although /usr/lib/lua/5.1 is owned by the lua package), the luasql packages leave /usr/lib/lua/5.1/luasql unowned, etc.) but these seem to be minor packaging issues. So, we need to decide whether we want to just go ahead with these packages, or whether we want to do the "wait for guidelines" game again. Is anyone interesting in writing some guidleines? It seems like they'd be pretty tiny. Hans, the main Lua package seems to be yours; are you interested in putting something together? - J< From tcallawa at redhat.com Fri Apr 4 18:34:10 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 04 Apr 2008 14:34:10 -0400 Subject: [Fedora-packaging] Lua In-Reply-To: References: Message-ID: <1207334050.4162.23.camel@localhost.localdomain> On Fri, 2008-04-04 at 13:29 -0500, Jason L Tibbitts III wrote: > I see a few Lua packages have appeared in the review queue today. > > I checked out the specs and they all seem very clean. There are a few > issues (/usr/lib/lua seems to be unowned in rawhide, although > /usr/lib/lua/5.1 is owned by the lua package), the luasql packages > leave /usr/lib/lua/5.1/luasql unowned, etc.) but these seem to be > minor packaging issues. > > So, we need to decide whether we want to just go ahead with these > packages, or whether we want to do the "wait for guidelines" game > again. Is anyone interesting in writing some guidleines? It seems > like they'd be pretty tiny. Hans, the main Lua package seems to be > yours; are you interested in putting something together? I don't see a reason for a hold here. I would love to see Hans (or someone qualified) whip up some guidelines. ~spot From a.badger at gmail.com Fri Apr 4 18:41:03 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 04 Apr 2008 11:41:03 -0700 Subject: [Fedora-packaging] Lua In-Reply-To: <1207334050.4162.23.camel@localhost.localdomain> References: <1207334050.4162.23.camel@localhost.localdomain> Message-ID: <47F6763F.6010202@gmail.com> Tom "spot" Callaway wrote: > On Fri, 2008-04-04 at 13:29 -0500, Jason L Tibbitts III wrote: >> I see a few Lua packages have appeared in the review queue today. >> >> I checked out the specs and they all seem very clean. There are a few >> issues (/usr/lib/lua seems to be unowned in rawhide, although >> /usr/lib/lua/5.1 is owned by the lua package), the luasql packages >> leave /usr/lib/lua/5.1/luasql unowned, etc.) but these seem to be >> minor packaging issues. >> >> So, we need to decide whether we want to just go ahead with these >> packages, or whether we want to do the "wait for guidelines" game >> again. Is anyone interesting in writing some guidleines? It seems >> like they'd be pretty tiny. Hans, the main Lua package seems to be >> yours; are you interested in putting something together? > > I don't see a reason for a hold here. I would love to see Hans (or > someone qualified) whip up some guidelines. > +1 -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From j.w.r.degoede at hhs.nl Fri Apr 4 21:12:21 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 04 Apr 2008 23:12:21 +0200 Subject: [Fedora-packaging] Lua In-Reply-To: <1207334050.4162.23.camel@localhost.localdomain> References: <1207334050.4162.23.camel@localhost.localdomain> Message-ID: <47F699B5.6090502@hhs.nl> Tom "spot" Callaway wrote: > On Fri, 2008-04-04 at 13:29 -0500, Jason L Tibbitts III wrote: >> I see a few Lua packages have appeared in the review queue today. >> >> I checked out the specs and they all seem very clean. There are a few >> issues (/usr/lib/lua seems to be unowned in rawhide, although >> /usr/lib/lua/5.1 is owned by the lua package), the luasql packages >> leave /usr/lib/lua/5.1/luasql unowned, etc.) but these seem to be >> minor packaging issues. >> >> So, we need to decide whether we want to just go ahead with these >> packages, or whether we want to do the "wait for guidelines" game >> again. Is anyone interesting in writing some guidleines? It seems >> like they'd be pretty tiny. Hans, the main Lua package seems to be >> yours; are you interested in putting something together? > > I don't see a reason for a hold here. I would love to see Hans (or > someone qualified) whip up some guidelines. > I also don't see a reason for a hold. As for me being the lua maintainer, thats only because it got orphaned and its used in a few games I maintain. My lua knowledge is limited. So lets first see how these new packages go, and if there is a need for lua specific guidelines at all. Regards, Hans From tibbs at math.uh.edu Fri Apr 4 21:24:56 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 04 Apr 2008 16:24:56 -0500 Subject: [Fedora-packaging] Lua In-Reply-To: <47F699B5.6090502@hhs.nl> References: <1207334050.4162.23.camel@localhost.localdomain> <47F699B5.6090502@hhs.nl> Message-ID: >>>>> "HdG" == Hans de Goede writes: HdG> I also don't see a reason for a hold. As for me being the lua HdG> maintainer, thats only because it got orphaned and its used in a HdG> few games I maintain. My lua knowledge is limited. No problem. Do you want me to file a bug about the unowned /usr/lib/lua? HdG> So lets first see how these new packages go, and if there is a HdG> need for lua specific guidelines at all. OK, I'll start reviewing them. - J< From j.w.r.degoede at hhs.nl Sat Apr 5 07:24:39 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 05 Apr 2008 09:24:39 +0200 Subject: [Fedora-packaging] Lua In-Reply-To: References: <1207334050.4162.23.camel@localhost.localdomain> <47F699B5.6090502@hhs.nl> Message-ID: <47F72937.5020305@hhs.nl> Jason L Tibbitts III wrote: > No problem. Do you want me to file a bug about the unowned > /usr/lib/lua? > Not necessary, this is currently building for rawhide: * Sat Apr 5 2008 Hans de Goede 5.1.3-4 - Not only own $libdir/lua/5.1 and $datadir/lua/5.1 but also $libdir/lua and $datadir/lua for proper removal of these dirs upon lua removal Regards, Hans From tibbs at math.uh.edu Sat Apr 5 16:00:41 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 05 Apr 2008 11:00:41 -0500 Subject: [Fedora-packaging] Lua In-Reply-To: <47F72937.5020305@hhs.nl> References: <1207334050.4162.23.camel@localhost.localdomain> <47F699B5.6090502@hhs.nl> <47F72937.5020305@hhs.nl> Message-ID: >>>>> "HdG" == Hans de Goede writes: HdG> Not necessary, this is currently building for rawhide: Thanks. I've reviewed those lua package submissions which were reviewable and so far everything was reasonably clean but I think every one of them had issues with compiler flags. It seems that the common build process is not amenable to passing your own CFLAGS. Annoying, but something that is pretty easy to handle. - J< From dtimms at iinet.net.au Sun Apr 6 08:17:51 2008 From: dtimms at iinet.net.au (David Timms) Date: Sun, 06 Apr 2008 18:17:51 +1000 Subject: [Fedora-packaging] Suggestion: require inclusion of cvs location in completed review request Message-ID: <47F8872F.9020907@iinet.net.au> Hi all, I am keen to get the packaging process modified to include a final item after ACCEPTED and CVS action done. This is simply to require the submitter to make a final entry into the review request that indicates the URL to the spec file on the fedora cvs server {or any future package source repo}. Preferably via the web interface viewcvs. While some people think that the package submission, review, maintenance can be burdensome, I think this would be an improvement to assist learning packagers in seeing what the final completed .spec looks like. At the moment, many .spec URLs that are hosted outside Fedora are taken down the moment or shortly after the process is complete. Hence it makes it difficult to learn from the efforts of others in a package review in Fedora because the .spec is no longer linked in the spec/SRPM urls provided by the submitter. The second issue is that browsing the cvs server is quite slow - mainly at the point where the "folder" has the complete list of {3000} package folders. This means we could immediately click through to the correct folder in the cvs server, rather than trawling from the top level. Any comments, rejections to this idea ? In the meantime, if you think it is a good idea, it would be appreciated for others to do this in any case - if that is allowed ? === Another idea along these lines would be to have a staging CVS server that the reviewer would be required to commit the original and changes to the spec under development. This could then be committed to the real cvs server after acceptance. The submitter would still put his srpms on his own url, not in the staging cvs server. This would make it simpler to get a live diff on what the submitter's changes have been, rather than viewing the spec as a whole and trying to find the changes. DaveT. From ville.skytta at iki.fi Sun Apr 6 09:52:35 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sun, 6 Apr 2008 12:52:35 +0300 Subject: [Fedora-packaging] My comments about the Java packaging guidelines draft Message-ID: <200804061252.36370.ville.skytta@iki.fi> There seems to have been some misunderstanding about for whom I spoke for when making comments about the Java guidelines even though I believe it should be pretty clear, and I was asked by Nicolas to make this statement in public, so FWIW: I spoke for myself (not for the JPackage project) thinking what I believe is best for Fedora. That also happens to be what I think would be best for JPackage, but for various reasons it's been quite a while since I've been active in JPackage or even using their deliverables, so I haven't tried pushing anything on their side for a long time nor am I up to date about JPackage's current consensus or future plans. From j.w.r.degoede at hhs.nl Sun Apr 6 13:45:34 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 06 Apr 2008 15:45:34 +0200 Subject: [Fedora-packaging] Suggestion: require inclusion of cvs location in completed review request In-Reply-To: <47F8872F.9020907@iinet.net.au> References: <47F8872F.9020907@iinet.net.au> Message-ID: <47F8D3FE.9090906@hhs.nl> David Timms wrote: > Hi all, > > I am keen to get the packaging process modified to include a final item > after ACCEPTED and CVS action done. This is simply to require the > submitter to make a final entry into the review request that indicates > the URL to the spec file on the fedora cvs server {or any future package > source repo}. Preferably via the web interface viewcvs. > > While some people think that the package submission, review, maintenance > can be burdensome, I think this would be an improvement to assist > learning packagers in seeing what the final completed .spec looks like. > > At the moment, many .spec URLs that are hosted outside Fedora are taken > down the moment or shortly after the process is complete. Hence it makes > it difficult to learn from the efforts of others in a package review in > Fedora because the .spec is no longer linked in the spec/SRPM urls > provided by the submitter. > > The second issue is that browsing the cvs server is quite slow - mainly > at the point where the "folder" has the complete list of {3000} package > folders. This means we could immediately click through to the correct > folder in the cvs server, rather than trawling from the top level. > > Any comments, rejections to this idea ? > -1 This means yet another step in getting a package included, we need less steps not more. For the rare circumstance when someone does need access to a spec there are several ways, almost all of them easier then first going through a bugzilla query to find the original review. Regards, Hans From dominik at greysector.net Sun Apr 6 13:53:21 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 6 Apr 2008 15:53:21 +0200 Subject: [Fedora-packaging] Suggestion: require inclusion of cvs location in completed review request In-Reply-To: <47F8872F.9020907@iinet.net.au> References: <47F8872F.9020907@iinet.net.au> Message-ID: <20080406135320.GA3198@ryvius.greysector.net> On Sunday, 06 April 2008 at 10:17, David Timms wrote: > Hi all, > > I am keen to get the packaging process modified to include a final item > after ACCEPTED and CVS action done. This is simply to require the submitter > to make a final entry into the review request that indicates the URL to the > spec file on the fedora cvs server {or any future package source repo}. > Preferably via the web interface viewcvs. > > While some people think that the package submission, review, maintenance > can be burdensome, I think this would be an improvement to assist learning > packagers in seeing what the final completed .spec looks like. > > At the moment, many .spec URLs that are hosted outside Fedora are taken > down the moment or shortly after the process is complete. Hence it makes > it difficult to learn from the efforts of others in a package review in > Fedora because the .spec is no longer linked in the spec/SRPM urls provided > by the submitter. > > The second issue is that browsing the cvs server is quite slow - mainly at > the point where the "folder" has the complete list of {3000} package > folders. This means we could immediately click through to the correct > folder in the cvs server, rather than trawling from the top level. > > Any comments, rejections to this idea ? I'm not opposed to the idea, but should be automated. I'm not thrilled about adding another manual step to the package submission process. -1 if done by hand, 0 otherwise. > In the meantime, if you think it is a good idea, it would be appreciated > for others to do this in any case - if that is allowed ? > === > Another idea along these lines would be to have a staging CVS server that > the reviewer would be required to commit the original and changes to the > spec under development. This could then be committed to the real cvs server > after acceptance. The submitter would still put his srpms on his own url, > not in the staging cvs server. It's a problem because you'd need to create some accounts to provide submitters who aren't yet sponsored with access. > This would make it simpler to get a live diff on what the submitter's > changes have been, rather than viewing the spec as a whole and trying to > find the changes. Granted, it might be useful in the handful of cases where the specfile is fairly large, but the majority of specfiles are small and changes are easily noticeable. -1 from me, as this puts more burden on both the submitter and the infrastructure for very little gain. 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 Sun Apr 6 15:26:34 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 06 Apr 2008 08:26:34 -0700 Subject: [Fedora-packaging] Suggestion: require inclusion of cvs location in completed review request In-Reply-To: <47F8872F.9020907@iinet.net.au> References: <47F8872F.9020907@iinet.net.au> Message-ID: <47F8EBAA.2060406@gmail.com> David Timms wrote: > At the moment, many .spec URLs that are hosted outside Fedora are taken > down the moment or shortly after the process is complete. Hence it makes > it difficult to learn from the efforts of others in a package review in > Fedora because the .spec is no longer linked in the spec/SRPM urls > provided by the submitter. > > The second issue is that browsing the cvs server is quite slow - mainly > at the point where the "folder" has the complete list of {3000} package > folders. This means we could immediately click through to the correct > folder in the cvs server, rather than trawling from the top level. > This is only a partial help since it's not easily discoverable by a new user but it will keep you from having to browse the complete foleder list on the cvs server:: http://cvs.fedoraproject.org/viewcvs/rpms/PKGNAME > Any comments, rejections to this idea ? > Like Rathann, I'm against this if it's a manual requirement but if it were automated it would be useful. If you would be willing to contribute some code, the cvs request needs to become something that is entered into the package database. The bugzilla address will be entered as part of this so that the cvs admin can continue to verify the reviews. So it would be possible to automate adding a link to viewcvs at the end of this process. > In the meantime, if you think it is a good idea, it would be appreciated > for others to do this in any case - if that is allowed ? If a packager wants to do this themselves they are welcome to do it. > === > Another idea along these lines would be to have a staging CVS server > that the reviewer would be required to commit the original and changes > to the spec under development. This could then be committed to the real > cvs server after acceptance. The submitter would still put his srpms on > his own url, not in the staging cvs server. > > This would make it simpler to get a live diff on what the submitter's > changes have been, rather than viewing the spec as a whole and trying to > find the changes. > This could be useful but it would be a separate process for people to learn and a separate cvs instance that would have to be maintained. I'm not sure that we want to do this because of the overhead. At least, we'd want to get the pkgdb's automated closing of package bugs written first so we could see if we could make an automated opening as well. (Note: This would require people, at minimum, to have signed the CLA before submitting their first package.) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From tibbs at math.uh.edu Sun Apr 6 19:54:58 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 06 Apr 2008 14:54:58 -0500 Subject: [Fedora-packaging] Suggestion: require inclusion of cvs location in completed review request In-Reply-To: <47F8D3FE.9090906@hhs.nl> References: <47F8872F.9020907@iinet.net.au> <47F8D3FE.9090906@hhs.nl> Message-ID: >>>>> "HdG" == Hans de Goede writes: HdG> This means yet another step in getting a package included, we HdG> need less steps not more. I agree; it's also yet another bit of bugspam in a process that generates a huge load of it as it is. As long as we keep the package name in the summary correct, the CVS location is trivially derived from that and thus entirely redundant. So sure, better document how to get to imported packages in the wiki all you want. But please, no additional demands on the already burdensome review process. - J< From michel.sylvan at gmail.com Sun Apr 6 20:16:00 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Sun, 6 Apr 2008 16:16:00 -0400 Subject: [Fedora-packaging] Lua In-Reply-To: References: Message-ID: On Fri, Apr 4, 2008 at 2:29 PM, Jason L Tibbitts III wrote: > I see a few Lua packages have appeared in the review queue today. > > I checked out the specs and they all seem very clean. There are a few > issues (/usr/lib/lua seems to be unowned in rawhide, although > /usr/lib/lua/5.1 is owned by the lua package), the luasql packages > leave /usr/lib/lua/5.1/luasql unowned, etc.) but these seem to be > minor packaging issues. > > So, we need to decide whether we want to just go ahead with these > packages, or whether we want to do the "wait for guidelines" game > again. Is anyone interesting in writing some guidleines? It seems > like they'd be pretty tiny. Hans, the main Lua package seems to be > yours; are you interested in putting something together? > Lua SIG, anyone? It's a potentially more exciting language than Python and Ruby: a properly functional scripting language! -- Michel Salim http://hircus.jaiku.com/ From opensource at till.name Sun Apr 6 20:19:59 2008 From: opensource at till.name (Till Maas) Date: Sun, 06 Apr 2008 22:19:59 +0200 Subject: [Fedora-packaging] Suggestion: require inclusion of cvs location in completed review request In-Reply-To: <47F8872F.9020907@iinet.net.au> References: <47F8872F.9020907@iinet.net.au> Message-ID: <200804062220.04043.opensource@till.name> On Sun April 6 2008, David Timms wrote: > The second issue is that browsing the cvs server is quite slow - mainly > at the point where the "folder" has the complete list of {3000} package > folders. This means we could immediately click through to the correct > folder in the cvs server, rather than trawling from the top level. > > Any comments, rejections to this idea ? Here is a shell script that gives you the url to the relevant spec files for any package, that is in Fedora cvs: #!/bin/bash PACKAGE_NAME=$1 echo CVS Basedir: echo http://cvs.fedoraproject.org/viewcvs/rpms/$PACKAGE_NAME echo CVS devel spec: echo http://cvs.fedoraproject.org/viewcvs/*checkout*/rpms/$PACKAGE_NAME/devel/$PACKAGE_NAME.spec echo CVS imported spec: echo http://cvs.fedoraproject.org/viewcvs/*checkout*/rpms/$PACKAGE_NAME/devel/$PACKAGE_NAME.spec?rev=1.1 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 opensource at till.name Sun Apr 6 21:05:10 2008 From: opensource at till.name (Till Maas) Date: Sun, 06 Apr 2008 23:05:10 +0200 Subject: [Fedora-packaging] Suggestion: require inclusion of cvs location in completed review request In-Reply-To: <200804062220.04043.opensource@till.name> References: <47F8872F.9020907@iinet.net.au> <200804062220.04043.opensource@till.name> Message-ID: <200804062305.19762.opensource@till.name> On Sun April 6 2008, Till Maas wrote: > On Sun April 6 2008, David Timms wrote: > > The second issue is that browsing the cvs server is quite slow - mainly > > at the point where the "folder" has the complete list of {3000} package > > folders. This means we could immediately click through to the correct > > folder in the cvs server, rather than trawling from the top level. > > > > Any comments, rejections to this idea ? > > Here is a shell script that gives you the url to the relevant spec files > for any package, that is in Fedora cvs: And here is a JavaScript application: http://till.fedorapeople.org/cvs_url.html 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 paul at city-fan.org Mon Apr 7 11:09:56 2008 From: paul at city-fan.org (Paul Howarth) Date: Mon, 07 Apr 2008 12:09:56 +0100 Subject: [Fedora-packaging] Packaging/SysVInitScript wiki page has wrong description for LSB header Required-Stop: Message-ID: <47FA0104.4060406@city-fan.org> There's a rather big error in the wiki description of the LSB "Required-Stop:" header. The wiki says: http://fedoraproject.org/wiki/Packaging/SysVInitScript "The # Required-Stop: line in the LSB Header lists any boot facilities which must be stopped before shutdown of this service can commence." The LSB says: http://refspecs.freestandards.org/LSB_2.0.0/LSB-Core/LSB-Core/initscrcomconv.html "... the "Required-Stop:" header defines which facilities shall still be available during the shutdown of that service. Hence, the init script system should avoid stopping shell scripts which provide those facilities until this shell script is stopped." This is just about the opposite of what the wiki ways. I think a sane rule of thumb is that the parameters needed for "Required-Stop:" are likely to be the same as for "Required-Start:". The description of the "Should-Stop:" header is similarly wrong. Paul. From tcallawa at redhat.com Mon Apr 7 12:42:48 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 07 Apr 2008 08:42:48 -0400 Subject: [Fedora-packaging] Packaging/SysVInitScript wiki page has wrong description for LSB header Required-Stop: In-Reply-To: <47FA0104.4060406@city-fan.org> References: <47FA0104.4060406@city-fan.org> Message-ID: <1207572168.2846.39.camel@localhost.localdomain> On Mon, 2008-04-07 at 12:09 +0100, Paul Howarth wrote: > There's a rather big error in the wiki description of the LSB > "Required-Stop:" header. > > The wiki says: > http://fedoraproject.org/wiki/Packaging/SysVInitScript > > "The # Required-Stop: line in the LSB Header lists any boot facilities > which must be stopped before shutdown of this service can commence." > > The LSB says: > > http://refspecs.freestandards.org/LSB_2.0.0/LSB-Core/LSB-Core/initscrcomconv.html > > "... the "Required-Stop:" header defines which facilities shall still > be available during the shutdown of that service. Hence, the init > script system should avoid stopping shell scripts which provide those > facilities until this shell script is stopped." > > This is just about the opposite of what the wiki ways. > > I think a sane rule of thumb is that the parameters needed for > "Required-Stop:" are likely to be the same as for "Required-Start:". > > The description of the "Should-Stop:" header is similarly wrong. I've corrected these mistakes, thanks! (Although, I think they were possibly more useful the way that they were incorrectly written... ;) ~spot From dtimms at iinet.net.au Mon Apr 7 14:38:47 2008 From: dtimms at iinet.net.au (David Timms) Date: Tue, 08 Apr 2008 00:38:47 +1000 Subject: [Fedora-packaging] Suggestion: require inclusion of cvs location - deemed not that useful ;-( In-Reply-To: <47F8872F.9020907@iinet.net.au> References: <47F8872F.9020907@iinet.net.au> Message-ID: <47FA31F7.6030808@iinet.net.au> David Timms wrote: > I am keen to get the packaging process modified to include a final item > after ACCEPTED and CVS action done. This is simply to require the > submitter to make a final entry into the review request that indicates > the URL to the spec file on the fedora cvs server {or any future package > source repo}. Preferably via the web interface viewcvs. OK, thanks for each of those responses summarized as: - would make even more bugmail: yuk perhaps a bugzilla field that points to the spec url {ie easy to click and view} ? And/Or a button to generate a diff between current and previous commits for the spec. - an extra step in devel of packages: but a frighteningly simple one - loads easier than writing the actual package spec itself. Perhaps we could have a web driven packager assistant that let's us click checkboxes as we develop the package, and gives hints and links on the next bit to do. - it's easy to find the cvs location: {but not even a link provided}, difficult to find in {slow} wiki.fedoraproject.org eg http://cvs.fedora.redhat.com/viewcvs/?root=fedora doesn't seem to be it. Let's say I'm a real fed-bie and went to http://fedoraproject.org/ : how do I get at that url i'm after for say openoffice calc ? - fits in to package database - agreed. a field containing a pointer to the top folder for the package, with all the patches etc would be great. a link from an obvious spot in the website/wiki would be even better. ie typing package database, then search, should put me on a brief page explaining purpose with the link. But fed-bie would still need to know to search for "package database". or "spec" etc. - fast find link for CLI and web - the web one is reasonable -given some spit and polish, could we include it in the wiki itself, or would it need to be an external link to Till's site. ===== Staging cvs server for spec files before acceptance: - extra infrastructure to build / maintain. - legal would still require CLA before allowing submission. - spec changes are easily noticeable - well not to me, and certainly not when the submitter doesn't change the url between versions, nor keeps the older specs available during / after acceptance process. As a near newbie packager, we try to learn from the spec dev process as documented in bugzilla package review requests. But we tend to only be able to see the final result, rather than what exactly was wrong with the original versions and subsequent improvements. ===== I also re-notice that it isn't possible to search the collosus of fedoraproject.org {including docs, ftp mirrors, relevant redhat docs etc}. Or perhaps we can direct a user to an advanced google search against site:.fedoraproject.org {or is this against marketing direction}. - it would be good to have a search all, as well as search for content of package, document, wiki, bug etc. A central "find it" spot that everyone naturally uses. Note wiki page content searches are extremely slow {~minute}, at least for remote users. Other than the packagedb suggestion / labour request, how else could such a thing be achieved. Are top-level / near top level edits of the wiki to organize some of this information OK ? Should I drop drafts somewhere first, and ask for review somewhere ? DaveT. From opensource at till.name Tue Apr 8 07:23:03 2008 From: opensource at till.name (Till Maas) Date: Tue, 08 Apr 2008 09:23:03 +0200 Subject: [Fedora-packaging] Suggestion: require inclusion of cvs location - deemed not that useful ;-( In-Reply-To: <47FA31F7.6030808@iinet.net.au> References: <47F8872F.9020907@iinet.net.au> <47FA31F7.6030808@iinet.net.au> Message-ID: <200804080923.13942.opensource@till.name> On Mon April 7 2008, David Timms wrote: > - fast find link for CLI and web - the web one is reasonable -given some > spit and polish, could we include it in the wiki itself, or would it > need to be an external link to Till's site. The web one should work in the current wiki, but afaik it won't work with mediawiki anymore. 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 tcallawa at redhat.com Tue Apr 8 21:51:31 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 08 Apr 2008 17:51:31 -0400 Subject: [Fedora-packaging] Static Library Policy Draft Changes Message-ID: <1207691491.3065.101.camel@localhost.localdomain> As promised, here is my new proposed draft for handling static libs: http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryPolicy I know that it won't make everyone happy (it doesn't just leave static bits in -devel), but we really do want to track who is building against static libraries. ~spot From orion at cora.nwra.com Tue Apr 8 22:05:44 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 08 Apr 2008 16:05:44 -0600 Subject: [Fedora-packaging] Static Library Policy Draft Changes In-Reply-To: <1207691491.3065.101.camel@localhost.localdomain> References: <1207691491.3065.101.camel@localhost.localdomain> Message-ID: <47FBEC38.2000402@cora.nwra.com> Tom "spot" Callaway wrote: > As promised, here is my new proposed draft for handling static libs: > > http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryPolicy > > I know that it won't make everyone happy (it doesn't just leave static > bits in -devel), but we really do want to track who is building against > static libraries. > > ~spot > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > I can live with it (and I deal with a lot of static libraries...) - Orion From a.badger at gmail.com Tue Apr 8 22:51:25 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 08 Apr 2008 15:51:25 -0700 Subject: [Fedora-packaging] Static Library Policy Draft Changes In-Reply-To: <1207691491.3065.101.camel@localhost.localdomain> References: <1207691491.3065.101.camel@localhost.localdomain> Message-ID: <47FBF6ED.6040902@gmail.com> Tom "spot" Callaway wrote: > As promised, here is my new proposed draft for handling static libs: > > http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryPolicy > > I know that it won't make everyone happy (it doesn't just leave static > bits in -devel), but we really do want to track who is building against > static libraries. > From item #2: """ If the *-static-noshared package is no longer necessary, it should be removed, and Provided/Obsoleted by the *-devel package (not by the *-static package). """ I don't think we want to be Providing *-static-noshared in this case although the Obsolete makes sense. From item #3: """ When a package only provides static libraries you can place all the static library files in the *-devel subpackage. When doing this you also have to have a virtual Provide for the *-static and *-static-noshared packages: """ It seems like we should only have a Provide for *-static-noshared as this is a special case of item #2. Thoughts on that? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From rc040203 at freenet.de Tue Apr 8 22:59:59 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 09 Apr 2008 00:59:59 +0200 Subject: [Fedora-packaging] Static Library Policy Draft Changes In-Reply-To: <1207691491.3065.101.camel@localhost.localdomain> References: <1207691491.3065.101.camel@localhost.localdomain> Message-ID: <1207695599.24618.85.camel@beck.corsepiu.local> On Tue, 2008-04-08 at 17:51 -0400, Tom "spot" Callaway wrote: > As promised, here is my new proposed draft for handling static libs: > > http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryPolicy -1 I don't understand the difference between #2 and #3. Also I don't find the *-nonshared packages useful. Ralf From bpepple at fedoraproject.org Tue Apr 8 23:55:40 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 08 Apr 2008 19:55:40 -0400 Subject: [Fedora-packaging] Static Library Policy Draft Changes In-Reply-To: <1207691491.3065.101.camel@localhost.localdomain> References: <1207691491.3065.101.camel@localhost.localdomain> Message-ID: <1207698940.10232.0.camel@kennedy> On Tue, 2008-04-08 at 17:51 -0400, Tom "spot" Callaway wrote: > As promised, here is my new proposed draft for handling static libs: > > http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryPolicy > > I know that it won't make everyone happy (it doesn't just leave static > bits in -devel), but we really do want to track who is building against > static libraries. Seems reasonable enough to me. Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From orion at cora.nwra.com Wed Apr 9 02:28:53 2008 From: orion at cora.nwra.com (orion at cora.nwra.com) Date: Tue, 8 Apr 2008 20:28:53 -0600 (MDT) Subject: [Fedora-packaging] Static Library Policy Draft Changes In-Reply-To: <1207695599.24618.85.camel@beck.corsepiu.local> References: <1207691491.3065.101.camel@localhost.localdomain> <1207695599.24618.85.camel@beck.corsepiu.local> Message-ID: <2111.71.208.56.11.1207708133.squirrel@www.cora.nwra.com> > > On Tue, 2008-04-08 at 17:51 -0400, Tom "spot" Callaway wrote: >> As promised, here is my new proposed draft for handling static libs: >> >> http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryPolicy > -1 > > I don't understand the difference between #2 and #3. > > Also I don't find the *-nonshared packages useful. > I assume the point would be to ban BR: *-static in Fedora packages, but allow BR: *-nonshared - i.e. when there is no alternative. Is that correct? - orion From notting at redhat.com Wed Apr 9 03:12:52 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 8 Apr 2008 23:12:52 -0400 Subject: [Fedora-packaging] Static Library Policy Draft Changes In-Reply-To: <1207691491.3065.101.camel@localhost.localdomain> References: <1207691491.3065.101.camel@localhost.localdomain> Message-ID: <20080409031252.GA27678@nostromo.devel.redhat.com> Tom spot Callaway (tcallawa at redhat.com) said: > As promised, here is my new proposed draft for handling static libs: > > http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryPolicy > > I know that it won't make everyone happy (it doesn't just leave static > bits in -devel), but we really do want to track who is building against > static libraries. I'd rather just require them to be in -static instead of -static-noshared - they can still be tracked that way. Bill From jkeating at redhat.com Wed Apr 9 11:37:07 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 09 Apr 2008 07:37:07 -0400 Subject: [Fedora-packaging] Static Library Policy Draft Changes In-Reply-To: <20080409031252.GA27678@nostromo.devel.redhat.com> References: <1207691491.3065.101.camel@localhost.localdomain> <20080409031252.GA27678@nostromo.devel.redhat.com> Message-ID: <1207741027.11614.10.camel@localhost.localdomain> On Tue, 2008-04-08 at 23:12 -0400, Bill Nottingham wrote: > I'd rather just require them to be in -static instead of -static-noshared > - they can still be tracked that way. The problem (as described to me) is that if you put them in -static, and you BR -static, you then potentially link against /all/ the static libraries, even those that have shared alternatives. The motivation was to isolate the static libraries which have no shared alternative from those that do. We can still "track" things which BR -static-noshared just as easily as we can track those that BR -static. -- 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: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Wed Apr 9 11:42:07 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 09 Apr 2008 07:42:07 -0400 Subject: [Fedora-packaging] Static Library Policy Draft Changes In-Reply-To: <1207695599.24618.85.camel@beck.corsepiu.local> References: <1207691491.3065.101.camel@localhost.localdomain> <1207695599.24618.85.camel@beck.corsepiu.local> Message-ID: <1207741327.11614.16.camel@localhost.localdomain> On Wed, 2008-04-09 at 00:59 +0200, Ralf Corsepius wrote: > I don't understand the difference between #2 and #3. It's a subtle distinction. In 2, you have some static libraries and some shared libraries, but the static librar{y,ies} don't have shared alternatives. We don't want to stuff the static ones into the -devel package as we then lose the ability to track what packages statically link against said library, and we don't want to put them in -static as we then run the risk of statically linking to /all/ the static libraries, even those that have shared alternatives. In 3, there is /only/ static libraries, which if we were to try splitting out the static libraries you'd wind up with an empty -devel subpackage. That's why it's OK then to put the static libraries directly in the -devel subpackage, but still packages which link to those static BR the -static provides. Nonshared subpackage is needed to isolate the static with no alternative libraries from the static with alternative libraries. This way you don't run the risk of statically linking to /all/ the static libraries, even those that have shared alternatives. -- 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: 197 bytes Desc: This is a digitally signed message part URL: From j.w.r.degoede at hhs.nl Wed Apr 9 12:17:34 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 09 Apr 2008 14:17:34 +0200 Subject: [Fedora-packaging] Static Library Policy Draft Changes In-Reply-To: <47FBF6ED.6040902@gmail.com> References: <1207691491.3065.101.camel@localhost.localdomain> <47FBF6ED.6040902@gmail.com> Message-ID: <47FCB3DE.8030306@hhs.nl> Toshio Kuratomi wrote: > Tom "spot" Callaway wrote: > From item #3: > """ > When a package only provides static libraries you can place all the > static library files in the *-devel subpackage. When doing this you also > have to have a virtual Provide for the *-static and *-static-noshared > packages: > """ > > It seems like we should only have a Provide for *-static-noshared as > this is a special case of item #2. Thoughts on that? > I actually think we only should have a Provide for *-static, so that people who want to use static libs now and in the future (when there may be a shared version) , can guarantee they will get the static version by BuildRequiring the -static, since very few packages will ever have a real *-static-noshared, having a virtual provides for this feels wrong. Regards, Hans From rc040203 at freenet.de Wed Apr 9 12:39:06 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 09 Apr 2008 14:39:06 +0200 Subject: [Fedora-packaging] Static Library Policy Draft Changes In-Reply-To: <1207741027.11614.10.camel@localhost.localdomain> References: <1207691491.3065.101.camel@localhost.localdomain> <20080409031252.GA27678@nostromo.devel.redhat.com> <1207741027.11614.10.camel@localhost.localdomain> Message-ID: <1207744746.24618.162.camel@beck.corsepiu.local> On Wed, 2008-04-09 at 07:37 -0400, Jesse Keating wrote: > On Tue, 2008-04-08 at 23:12 -0400, Bill Nottingham wrote: > > I'd rather just require them to be in -static instead of -static-noshared > > - they can still be tracked that way. > > The problem (as described to me) is that if you put them in -static, and > you BR -static, you then potentially link against /all/ the static > libraries, even those that have shared alternatives. How that? Our rule has been that *-static must Require *-devel, i.e. unless a package is playing nasty games with linking (or this packaging rule is being obeyed), it will always link dynamically. > The motivation was > to isolate the static libraries which have no shared alternative from > those that do. > > We can still "track" things which BR -static-noshared just as easily as > we can track those that BR -static. I still fail to see the usefulness of this. Our logic had been: Client-packages who intentionally want to link statically, must BR: *-static, those who don't care should BR: *-devel. With your approach above, client-packages will have to care about characteristics of a package providing a static library. This doesn't make any sense to me on the client-side. Ralf From jkeating at redhat.com Wed Apr 9 13:27:45 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 09 Apr 2008 09:27:45 -0400 Subject: [Fedora-packaging] Static Library Policy Draft Changes In-Reply-To: <1207744746.24618.162.camel@beck.corsepiu.local> References: <1207691491.3065.101.camel@localhost.localdomain> <20080409031252.GA27678@nostromo.devel.redhat.com> <1207741027.11614.10.camel@localhost.localdomain> <1207744746.24618.162.camel@beck.corsepiu.local> Message-ID: <1207747665.11614.27.camel@localhost.localdomain> On Wed, 2008-04-09 at 14:39 +0200, Ralf Corsepius wrote: > > The problem (as described to me) is that if you put them in -static, and > > you BR -static, you then potentially link against /all/ the static > > libraries, even those that have shared alternatives. > How that? Our rule has been that *-static must Require *-devel, i.e. > unless a package is playing nasty games with linking (or this packaging > rule is being obeyed), it will always link dynamically. Since spot was the person who described it to me, perhaps it would be best to get his input here. The way he stated it was that if there were static libs around at link time, they would get automatically linked, even if the didn't want them to. > > > The motivation was > > to isolate the static libraries which have no shared alternative from > > those that do. > > > > We can still "track" things which BR -static-noshared just as easily as > > we can track those that BR -static. > I still fail to see the usefulness of this. > > Our logic had been: Client-packages who intentionally want to link > statically, must BR: *-static, those who don't care should BR: *-devel. > > With your approach above, client-packages will have to care about > characteristics of a package providing a static library. > > This doesn't make any sense to me on the client-side. It is a minor annoyance on the client side, but the client side /should/ know if they are linking to anything static. In fact, if they do, they have to be on the initialcc of said static package. It's an extra burden you take on by linking statically. -- 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: 197 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Wed Apr 9 13:44:36 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 09 Apr 2008 09:44:36 -0400 Subject: [Fedora-packaging] Static Library Policy Draft Changes In-Reply-To: <47FCB3DE.8030306@hhs.nl> References: <1207691491.3065.101.camel@localhost.localdomain> <47FBF6ED.6040902@gmail.com> <47FCB3DE.8030306@hhs.nl> Message-ID: <1207748676.3000.12.camel@localhost.localdomain> On Wed, 2008-04-09 at 14:17 +0200, Hans de Goede wrote: > Toshio Kuratomi wrote: > > Tom "spot" Callaway wrote: > > From item #3: > > """ > > When a package only provides static libraries you can place all the > > static library files in the *-devel subpackage. When doing this you also > > have to have a virtual Provide for the *-static and *-static-noshared > > packages: > > """ > > > > It seems like we should only have a Provide for *-static-noshared as > > this is a special case of item #2. Thoughts on that? > > > > I actually think we only should have a Provide for *-static, so that people who > want to use static libs now and in the future (when there may be a shared > version) , can guarantee they will get the static version by BuildRequiring the > -static, since very few packages will ever have a real *-static-noshared, > having a virtual provides for this feels wrong. The problem is two-fold: 1. We want to be able to track when packages are building against static libraries, whether they are static or static-noshared. 2. When a package goes from only providing static libraries to providing some shared libraries (but not all), we want to be able to track these. If we have these packages BuildRequire the static provide, that won't be correct anymore (we want them to use the shared libraries + static-noshared). Realistically, what Toshio says is correct, we strictly speaking only need the Provide for *-static-noshared there. I kept the other *-static provide since it is how we used to do it. ~spot From tcallawa at redhat.com Wed Apr 9 13:47:37 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 09 Apr 2008 09:47:37 -0400 Subject: [Fedora-packaging] Static Library Policy Draft Changes In-Reply-To: <1207747665.11614.27.camel@localhost.localdomain> References: <1207691491.3065.101.camel@localhost.localdomain> <20080409031252.GA27678@nostromo.devel.redhat.com> <1207741027.11614.10.camel@localhost.localdomain> <1207744746.24618.162.camel@beck.corsepiu.local> <1207747665.11614.27.camel@localhost.localdomain> Message-ID: <1207748857.3000.16.camel@localhost.localdomain> On Wed, 2008-04-09 at 09:27 -0400, Jesse Keating wrote: > Since spot was the person who described it to me, perhaps it would be > best to get his input here. The way he stated it was that if there > were > static libs around at link time, they would get automatically linked, > even if the didn't want them to. > A lot of packages will look first for static libraries, then if (and only if) they are not found, look for shared libraries. By splitting into static and static-noshared, we can safely put in -devel and -static-noshared and avoid this confusion. ~spot From notting at redhat.com Wed Apr 9 14:33:57 2008 From: notting at redhat.com (Bill Nottingham) Date: Wed, 9 Apr 2008 10:33:57 -0400 Subject: [Fedora-packaging] Static Library Policy Draft Changes In-Reply-To: <1207748857.3000.16.camel@localhost.localdomain> References: <1207691491.3065.101.camel@localhost.localdomain> <20080409031252.GA27678@nostromo.devel.redhat.com> <1207741027.11614.10.camel@localhost.localdomain> <1207744746.24618.162.camel@beck.corsepiu.local> <1207747665.11614.27.camel@localhost.localdomain> <1207748857.3000.16.camel@localhost.localdomain> Message-ID: <20080409143357.GC32653@nostromo.devel.redhat.com> Tom spot Callaway (tcallawa at redhat.com) said: > > Since spot was the person who described it to me, perhaps it would be > > best to get his input here. The way he stated it was that if there > > were > > static libs around at link time, they would get automatically linked, > > even if the didn't want them to. > > A lot of packages will look first for static libraries, then if (and > only if) they are not found, look for shared libraries. By splitting > into static and static-noshared, we can safely put in -devel and > -static-noshared and avoid this confusion. That's not the case for anything that just passes -l. Can't we just fix those packages? Bill From rdieter at math.unl.edu Wed Apr 9 14:40:35 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 09 Apr 2008 09:40:35 -0500 Subject: [Fedora-packaging] Static Library Policy Draft Changes In-Reply-To: <20080409143357.GC32653@nostromo.devel.redhat.com> References: <1207691491.3065.101.camel@localhost.localdomain> <20080409031252.GA27678@nostromo.devel.redhat.com> <1207741027.11614.10.camel@localhost.localdomain> <1207744746.24618.162.camel@beck.corsepiu.local> <1207747665.11614.27.camel@localhost.localdomain> <1207748857.3000.16.camel@localhost.localdomain> <20080409143357.GC32653@nostromo.devel.redhat.com> Message-ID: <47FCD563.2030009@math.unl.edu> Bill Nottingham wrote: > Tom spot Callaway (tcallawa at redhat.com) said: >>> Since spot was the person who described it to me, perhaps it would be >>> best to get his input here. The way he stated it was that if there >>> were >>> static libs around at link time, they would get automatically linked, >>> even if the didn't want them to. >> A lot of packages will look first for static libraries, then if (and >> only if) they are not found, look for shared libraries. By splitting >> into static and static-noshared, we can safely put in -devel and >> -static-noshared and avoid this confusion. > > That's not the case for anything that just passes -l. Can't > we just fix those packages? +1 to bill's comment. I see static-noshared as nothing but a hack to get around what could/should be fixed in the offending packages. Unless there is some other purpose to it that I'm missing. Heightened paranoia, err, verification about what is being statically linked? -- Rex From rdieter at math.unl.edu Wed Apr 9 14:44:45 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 09 Apr 2008 09:44:45 -0500 Subject: [Fedora-packaging] Static Library Policy Draft Changes In-Reply-To: <1207748676.3000.12.camel@localhost.localdomain> References: <1207691491.3065.101.camel@localhost.localdomain> <47FBF6ED.6040902@gmail.com> <47FCB3DE.8030306@hhs.nl> <1207748676.3000.12.camel@localhost.localdomain> Message-ID: <47FCD65D.40202@math.unl.edu> Tom "spot" Callaway wrote: > On Wed, 2008-04-09 at 14:17 +0200, Hans de Goede wrote: >> I actually think we only should have a Provide for *-static, so that people who >> want to use static libs now and in the future (when there may be a shared >> version) , can guarantee they will get the static version by BuildRequiring the >> -static, since very few packages will ever have a real *-static-noshared, >> having a virtual provides for this feels wrong. > > The problem is two-fold: > ... Thanks, I think I finally have a grasp of all the motivations here, and agree the new draft is the best way forward. -- Rex p.s. static libraries suck From rc040203 at freenet.de Wed Apr 9 14:10:29 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 09 Apr 2008 16:10:29 +0200 Subject: [Fedora-packaging] Static Library Policy Draft Changes In-Reply-To: <1207748857.3000.16.camel@localhost.localdomain> References: <1207691491.3065.101.camel@localhost.localdomain> <20080409031252.GA27678@nostromo.devel.redhat.com> <1207741027.11614.10.camel@localhost.localdomain> <1207744746.24618.162.camel@beck.corsepiu.local> <1207747665.11614.27.camel@localhost.localdomain> <1207748857.3000.16.camel@localhost.localdomain> Message-ID: <1207750229.24618.169.camel@beck.corsepiu.local> On Wed, 2008-04-09 at 09:47 -0400, Tom "spot" Callaway wrote: > On Wed, 2008-04-09 at 09:27 -0400, Jesse Keating wrote: > > Since spot was the person who described it to me, perhaps it would be > > best to get his input here. The way he stated it was that if there > > were > > static libs around at link time, they would get automatically linked, > > even if the didn't want them to. > > > A lot of packages will look first for static libraries, then if (and > only if) they are not found, look for shared libraries. Examples? I am not aware of any such case. Also, this will never happen in a chroot unless a package BR:'s *-static or if a *-devel contains a static library. > By splitting > into static and static-noshared, we can safely put in -devel and > -static-noshared and avoid this confusion. Which confusion? I don't see any such confusion. The only situation such case may occur is with packages whose maintainers have been ignorant on the *-static/*-devel rule so far. Ralf From jkeating at redhat.com Thu Apr 10 02:35:33 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 09 Apr 2008 22:35:33 -0400 Subject: [Fedora-packaging] Static Library Policy Draft Changes In-Reply-To: <1207750229.24618.169.camel@beck.corsepiu.local> References: <1207691491.3065.101.camel@localhost.localdomain> <20080409031252.GA27678@nostromo.devel.redhat.com> <1207741027.11614.10.camel@localhost.localdomain> <1207744746.24618.162.camel@beck.corsepiu.local> <1207747665.11614.27.camel@localhost.localdomain> <1207748857.3000.16.camel@localhost.localdomain> <1207750229.24618.169.camel@beck.corsepiu.local> Message-ID: <1207794933.22822.47.camel@localhost.localdomain> On Wed, 2008-04-09 at 16:10 +0200, Ralf Corsepius wrote: > Also, this will never happen in a chroot unless a package BR:'s *-static > or if a *-devel contains a static library. > > > By splitting > > into static and static-noshared, we can safely put in -devel and > > -static-noshared and avoid this confusion. > > Which confusion? I don't see any such confusion. The only situation such > case may occur is with packages whose maintainers have been ignorant on > the *-static/*-devel rule so far. For the case where you have some shared, some static with matching shared, and some static only: If you put the static only in -devel, we can't reasonably detect all the things that link against the static library. We'd have to investigate anything that BRs the -devel package. If you put the static only in with the other statics in -static you then have all the statics in the chroot and run the risk that spot talks about of accidentally statically linking to things that have shared alternatives. -- 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: 197 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Thu Apr 10 02:54:47 2008 From: notting at redhat.com (Bill Nottingham) Date: Wed, 9 Apr 2008 22:54:47 -0400 Subject: [Fedora-packaging] Static Library Policy Draft Changes In-Reply-To: <1207794933.22822.47.camel@localhost.localdomain> References: <1207691491.3065.101.camel@localhost.localdomain> <20080409031252.GA27678@nostromo.devel.redhat.com> <1207741027.11614.10.camel@localhost.localdomain> <1207744746.24618.162.camel@beck.corsepiu.local> <1207747665.11614.27.camel@localhost.localdomain> <1207748857.3000.16.camel@localhost.localdomain> <1207750229.24618.169.camel@beck.corsepiu.local> <1207794933.22822.47.camel@localhost.localdomain> Message-ID: <20080410025447.GB30323@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > For the case where you have some shared, some static with matching > shared, and some static only: > > If you put the static only in -devel, we can't reasonably detect all the > things that link against the static library. We'd have to investigate > anything that BRs the -devel package. If you put the static only in > with the other statics in -static you then have all the statics in the > chroot and run the risk that spot talks about of accidentally statically > linking to things that have shared alternatives. The only way this can happen (AFAIK) is if they're linked by: - explicitly listing %{_libdir}/libfoo.a on the link line - explicitly passing -Wl,-bstatic Either of these things should be auditable. Bill From jkeating at redhat.com Thu Apr 10 03:17:16 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 09 Apr 2008 23:17:16 -0400 Subject: [Fedora-packaging] Static Library Policy Draft Changes In-Reply-To: <20080410025447.GB30323@nostromo.devel.redhat.com> References: <1207691491.3065.101.camel@localhost.localdomain> <20080409031252.GA27678@nostromo.devel.redhat.com> <1207741027.11614.10.camel@localhost.localdomain> <1207744746.24618.162.camel@beck.corsepiu.local> <1207747665.11614.27.camel@localhost.localdomain> <1207748857.3000.16.camel@localhost.localdomain> <1207750229.24618.169.camel@beck.corsepiu.local> <1207794933.22822.47.camel@localhost.localdomain> <20080410025447.GB30323@nostromo.devel.redhat.com> Message-ID: <1207797436.22822.51.camel@localhost.localdomain> On Wed, 2008-04-09 at 22:54 -0400, Bill Nottingham wrote: > The only way this can happen (AFAIK) is if they're linked by: > > - explicitly listing %{_libdir}/libfoo.a on the link line > - explicitly passing -Wl,-bstatic > > Either of these things should be auditable. Ok, if that's the case, we can relax the need for the -noshared subpackage. I'm really just going on the word of others here. -- 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: 197 bytes Desc: This is a digitally signed message part URL: From pertusus at free.fr Thu Apr 10 07:50:45 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 10 Apr 2008 09:50:45 +0200 Subject: [Fedora-packaging] Static Library Policy Draft Changes In-Reply-To: <1207748676.3000.12.camel@localhost.localdomain> References: <1207691491.3065.101.camel@localhost.localdomain> <47FBF6ED.6040902@gmail.com> <47FCB3DE.8030306@hhs.nl> <1207748676.3000.12.camel@localhost.localdomain> Message-ID: <20080410075044.GA3371@free.fr> On Wed, Apr 09, 2008 at 09:44:36AM -0400, Tom spot Callaway wrote: > > 2. When a package goes from only providing static libraries to providing > some shared libraries (but not all), we want to be able to track these. Does it happens? I guess that this is raised by a real life example, but is there more than one package providing some library as shared+static and some only as static? -- Pat From rc040203 at freenet.de Thu Apr 10 08:19:46 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 10 Apr 2008 10:19:46 +0200 Subject: [Fedora-packaging] Static Library Policy Draft Changes In-Reply-To: <1207748676.3000.12.camel@localhost.localdomain> References: <1207691491.3065.101.camel@localhost.localdomain> <47FBF6ED.6040902@gmail.com> <47FCB3DE.8030306@hhs.nl> <1207748676.3000.12.camel@localhost.localdomain> Message-ID: <1207815586.24618.261.camel@beck.corsepiu.local> On Wed, 2008-04-09 at 09:44 -0400, Tom "spot" Callaway wrote: > On Wed, 2008-04-09 at 14:17 +0200, Hans de Goede wrote: > > Toshio Kuratomi wrote: > > > Tom "spot" Callaway wrote: > > > From item #3: > > > """ > > > When a package only provides static libraries you can place all the > > > static library files in the *-devel subpackage. When doing this you also > > > have to have a virtual Provide for the *-static and *-static-noshared > > > packages: > > > """ > > > > > > It seems like we should only have a Provide for *-static-noshared as > > > this is a special case of item #2. Thoughts on that? > > > > > > > I actually think we only should have a Provide for *-static, so that people who > > want to use static libs now and in the future (when there may be a shared > > version) , can guarantee they will get the static version by BuildRequiring the > > -static, since very few packages will ever have a real *-static-noshared, > > having a virtual provides for this feels wrong. > > The problem is two-fold: > > 1. We want to be able to track when packages are building against static > libraries, whether they are static or static-noshared. What for? IMO this is simply bureaucracy. > 2. When a package goes from only providing static libraries to providing > some shared libraries (but not all), we want to be able to track these. But this isn't what your proposal does. Your proposal pesters/pollutes library-clients *.specs with a library's provider's packaging details, these library-clients are not interested in. > If we have these packages BuildRequire the static provide, that won't be > correct anymore (we want them to use the shared libraries + > static-noshared). > > Realistically, what Toshio says is correct, we strictly speaking only > need the Provide for *-static-noshared there. I kept the other *-static > provide since it is how we used to do it. This is something completely different. Here, you seem to be talking about "Additionally providing *-static-noshared" and NOT to pester library-clients with BR: *-static-nonshared". In real world, no library-client who needs a static library, needs know if this library is being provided "*-static-noshared" or "*-static". => Such kind of Provides is useless to the library-client. Ralf From rc040203 at freenet.de Thu Apr 10 08:23:54 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 10 Apr 2008 10:23:54 +0200 Subject: [Fedora-packaging] Static Library Policy Draft Changes In-Reply-To: <20080410075044.GA3371@free.fr> References: <1207691491.3065.101.camel@localhost.localdomain> <47FBF6ED.6040902@gmail.com> <47FCB3DE.8030306@hhs.nl> <1207748676.3000.12.camel@localhost.localdomain> <20080410075044.GA3371@free.fr> Message-ID: <1207815834.24618.267.camel@beck.corsepiu.local> On Thu, 2008-04-10 at 09:50 +0200, Patrice Dumas wrote: > On Wed, Apr 09, 2008 at 09:44:36AM -0400, Tom spot Callaway wrote: > > > > 2. When a package goes from only providing static libraries to providing > > some shared libraries (but not all), we want to be able to track these. > > Does it happens? This happens all the time. The critical case would be the opposite: A package going from providing shared libs to providing static libs only. I have never seen this happen, but provides the craziness of some upstreams, I would not exclude this to happen. > I guess that this is raised by a real life example, but > is there more than one package providing some library as shared+static > and some only as static? This isn't much of a problem. * If a library's client package BR:'s *-devel, it will pick up the shared library during the next rebuild. * If a library's client package BR:'s *-static, it will bomb out during the next rebuild. The only issue is library-client packages not being automatically notified that they might need to be rebuilt. To me, this is a negligible, minor issue, your proposal is too heavy weight for to find it appropriate. We have way more serious packaging issues than this minor detail. Ralf From pertusus at free.fr Thu Apr 10 11:38:19 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 10 Apr 2008 13:38:19 +0200 Subject: [Fedora-packaging] Static Library Policy Draft Changes In-Reply-To: <1207815834.24618.267.camel@beck.corsepiu.local> References: <1207691491.3065.101.camel@localhost.localdomain> <47FBF6ED.6040902@gmail.com> <47FCB3DE.8030306@hhs.nl> <1207748676.3000.12.camel@localhost.localdomain> <20080410075044.GA3371@free.fr> <1207815834.24618.267.camel@beck.corsepiu.local> Message-ID: <20080410113819.GC3371@free.fr> On Thu, Apr 10, 2008 at 10:23:54AM +0200, Ralf Corsepius wrote: > > On Thu, 2008-04-10 at 09:50 +0200, Patrice Dumas wrote: > > On Wed, Apr 09, 2008 at 09:44:36AM -0400, Tom spot Callaway wrote: > > > > > > 2. When a package goes from only providing static libraries to providing > > > some shared libraries (but not all), we want to be able to track these. > > > > Does it happens? > This happens all the time. I don't think so. Currently there are no such packages in fedora, with a mix of shared and static libs in -devel. I did the following: repoquery --whatprovides '*-static' --qf '%{name}' > provides_static_names for file in `grep -v -- '-static$' provides_static_names`; do repoquery -ql $file | grep '\.so$'; done /usr/lib/libruby.so /usr/lib/libfrysk-junit.so /usr/lib/libnettle.so /usr/libexec/p7zip/7z.so I filled a bug against nettle-devel, p7zip and frysk are false positives (they provides a file ending in -static), so ruby-devel is the only package doing that sort of thing, but the libraries have different names: /usr/lib/libruby-static.a /usr/lib/libruby.so But maybe you are referring to a package providing only static libraries then providing shared libraries (in -devel) and static libraries (in -static). In that case, I think it is not different from the case when a static library is rebuilt and therefoer the package linking against that library needs to be rebuilt too. This is covered by the guidelines: "If you link statically against a library, add yourself to the initialcc list for the library so you can watch for any security issues or bug fixes for which you'd want to rebuild your package against a new version of the library. Here are instructions for making that request." In my opinion this also covers going from static to shared, in that case the maitainer can fill himself a bug when going shared. > The critical case would be the opposite: A package going from providing > shared libs to providing static libs only. > > I have never seen this happen, but provides the craziness of some > upstreams, I would not exclude this to happen. Indeed, it may happen, but just following the existing guidelines in that case seems enough to me. > * If a library's client package BR:'s *-devel, > it will pick up the shared library during the next rebuild. > > * If a library's client package BR:'s *-static, > it will bomb out during the next rebuild. > > > The only issue is library-client packages not being automatically > notified that they might need to be rebuilt. As I said above, having the maintainer fill a bug when going shared should solve this issue, since packagers should already be in CC. The only issue I see is when a packager doesn't know that he is building against a static library. My investigations show that (with ruby excluded), the following -devel packages consist only of static libs and have dependent packages: --> factory-devel libfac-0:3.0.3-2.fc9.src Macaulay2-0:1.1-1.fc9.src --> flam3-devel qosmic-0:1.3.1-3.fc9.src --> g2clib-devel ncl-0:5.0.0-10.fc9.src --> libassuan-devel gnupg2-0:2.0.9-1.fc9.src dirmngr-0:1.0.1-2.fc9.src --> libfac-devel Macaulay2-0:1.1-1.fc9.src --> libnet-devel tcptraceroute-0:1.5-0.5.beta7.fc9.src dsniff-0:2.4-0.2.b1.fc9.src etherbat-0:1.0.1-4.fc9.src libnids-0:1.22-4.fc9.src heartbeat-0:2.1.3-1.fc9.src ettercap-0:0.7.3-22.fc9.src isic-0:0.07-2.fc9.src intuitively-0:0.7-13.fc9.src firewalk-0:5.0-2.fc9.src Also libmimedir-devel and osiv-devel requires the corresponding -static subpackages since there are no corresponding shared libraries, and uulib-static provides uulib-devel. This adds: # repoquery --whatrequires uulib-devel --archlist=src klibido-0:0.2.5-10.fc9.src # repoquery --whatrequires uulib-static --archlist=src nget-0:0.27.1-8.fc9.src # repoquery --whatrequires libmimedir-devel --archlist=src librra-0:0.11-2.fc9.src Also I noticed that some packages BuildRequires static packages, I filled few bugs, but most of the time, the -devel is also BuildRequires, and I guess that there is a good reason to BR the static sub package. -- Pat From rjones at redhat.com Fri Apr 11 09:40:05 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 11 Apr 2008 10:40:05 +0100 Subject: [Fedora-packaging] Static Library Policy Draft Changes In-Reply-To: <1207691491.3065.101.camel@localhost.localdomain> References: <1207691491.3065.101.camel@localhost.localdomain> Message-ID: <20080411094005.GA19924@amd.home.annexia.org> On Tue, Apr 08, 2008 at 05:51:31PM -0400, Tom spot Callaway wrote: > As promised, here is my new proposed draft for handling static libs: > > http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryPolicy > > I know that it won't make everyone happy (it doesn't just leave static > bits in -devel), but we really do want to track who is building against > static libraries. Can you remove the perjorative term "deficiency", since OCaml has good reasons for statically linking to do with software safety. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From rjones at redhat.com Fri Apr 11 09:46:18 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 11 Apr 2008 10:46:18 +0100 Subject: [Fedora-packaging] Static Library Policy Draft Changes In-Reply-To: <20080411094005.GA19924@amd.home.annexia.org> References: <1207691491.3065.101.camel@localhost.localdomain> <20080411094005.GA19924@amd.home.annexia.org> Message-ID: <20080411094618.GA19991@amd.home.annexia.org> On Fri, Apr 11, 2008 at 10:40:05AM +0100, Richard W.M. Jones wrote: > On Tue, Apr 08, 2008 at 05:51:31PM -0400, Tom spot Callaway wrote: > > As promised, here is my new proposed draft for handling static libs: > > > > http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryPolicy > > > > I know that it won't make everyone happy (it doesn't just leave static > > bits in -devel), but we really do want to track who is building against > > static libraries. > > Can you remove the perjorative term "deficiency", since OCaml has good > reasons for statically linking to do with software safety. Don't worry - I found I could edit that page myself. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From pertusus at free.fr Sun Apr 13 08:34:14 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 13 Apr 2008 10:34:14 +0200 Subject: [Fedora-packaging] updated ProvidesList proposal Message-ID: <20080413083413.GA3128@free.fr> Hello, I have added a rationale and removed a confusing text on: https://fedoraproject.org/wiki/PackagingDrafts/ProvidesList Please comment and modify. -- Pat From pertusus at free.fr Sun Apr 13 14:06:20 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 13 Apr 2008 16:06:20 +0200 Subject: [Fedora-packaging] forbid fedora or redhat in spec files? Message-ID: <20080413140620.GB2919@free.fr> Hello, I have seen people saying that we should avoid using 'fedora' and 'redhat' in spec files, to help reusing in other contexts (be it, selfishly, EPEL/RHEL/OLPC, or other distros or upstreams). I think it is a good idea, especially since there is a trademark on fedora and redhat (unless I am wrong). Should we have a guideline about that? Or on a 'trick' page? -- Pat From rc040203 at freenet.de Mon Apr 14 04:46:14 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 14 Apr 2008 06:46:14 +0200 Subject: [Fedora-packaging] forbid fedora or redhat in spec files? In-Reply-To: <20080413140620.GB2919@free.fr> References: <20080413140620.GB2919@free.fr> Message-ID: <1208148374.24618.576.camel@beck.corsepiu.local> On Sun, 2008-04-13 at 16:06 +0200, Patrice Dumas wrote: > Hello, > > I have seen people saying that we should avoid using 'fedora' and 'redhat' > in spec files, to help reusing in other contexts (be it, selfishly, > EPEL/RHEL/OLPC, or other distros or upstreams). I think it is a good > idea, especially since there is a trademark on fedora and redhat (unless > I am wrong). > > Should we have a guideline about that? Or on a 'trick' page? -1 ... unless there is any technical or legal reason (trademarks) to ban these strings, I do not see any need to add any such kind of restrictions. Ralf From denis at poolshark.org Mon Apr 14 07:03:59 2008 From: denis at poolshark.org (Denis Leroy) Date: Mon, 14 Apr 2008 09:03:59 +0200 Subject: [Fedora-packaging] forbid fedora or redhat in spec files? In-Reply-To: <20080413140620.GB2919@free.fr> References: <20080413140620.GB2919@free.fr> Message-ID: <480301DF.7080703@poolshark.org> Patrice Dumas wrote: > Hello, > > I have seen people saying that we should avoid using 'fedora' and 'redhat' > in spec files, to help reusing in other contexts (be it, selfishly, > EPEL/RHEL/OLPC, or other distros or upstreams). I think it is a good > idea, especially since there is a trademark on fedora and redhat (unless > I am wrong). > > Should we have a guideline about that? Or on a 'trick' page? A guideline for that seems a bit far-fetched to me, but what use of the terms did you want to target specifically ? I quick grep through the spec files mostly reveals usage in desktop-file-install ("--vendor" and "--add-category"), some "README.fedora" files, and conditionals such as "%if "%{?fedora}" > "5"" From jwilson at redhat.com Mon Apr 14 12:55:02 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 14 Apr 2008 08:55:02 -0400 Subject: [Fedora-packaging] forbid fedora or redhat in spec files? In-Reply-To: <480301DF.7080703@poolshark.org> References: <20080413140620.GB2919@free.fr> <480301DF.7080703@poolshark.org> Message-ID: <48035426.8010108@redhat.com> Denis Leroy wrote: > Patrice Dumas wrote: >> Hello, >> >> I have seen people saying that we should avoid using 'fedora' and >> 'redhat' >> in spec files, to help reusing in other contexts (be it, selfishly, >> EPEL/RHEL/OLPC, or other distros or upstreams). I think it is a good >> idea, especially since there is a trademark on fedora and redhat >> (unless I am wrong). >> >> Should we have a guideline about that? Or on a 'trick' page? > > A guideline for that seems a bit far-fetched to me, but what use of the > terms did you want to target specifically ? I quick grep through the > spec files mostly reveals usage in desktop-file-install ("--vendor" and > "--add-category"), some "README.fedora" files, and conditionals such as > "%if "%{?fedora}" > "5"" One use case that comes to mind: someone doing a spin that can't meet the Fedora criteria for still being called Fedora. In theory, simply replacing fedora-release and fedora-logos is sufficient, but in practice, Fedora (and/or Red Hat) shows up a few other places as well. In gnome, System->About Fedora still shows up, and System->About Fedora still says "Distributor: Red Hat, Inc." (this one probably ought to say "Fedora Project" for Fedora...). In web pages, the apache identifier string is still "Apache/2.2.8 (Fedora)", and I'm sure there are probably other cases as well. -- Jarod Wilson jwilson at redhat.com From ivazqueznet at gmail.com Mon Apr 14 13:07:14 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Mon, 14 Apr 2008 09:07:14 -0400 Subject: [Fedora-packaging] forbid fedora or redhat in spec files? In-Reply-To: <48035426.8010108@redhat.com> References: <20080413140620.GB2919@free.fr> <480301DF.7080703@poolshark.org> <48035426.8010108@redhat.com> Message-ID: <1208178434.586.5.camel@ignacio.lan> On Mon, 2008-04-14 at 08:55 -0400, Jarod Wilson wrote: > One use case that comes to mind: someone doing a spin that can't meet the > Fedora criteria for still being called Fedora. In theory, simply replacing > fedora-release and fedora-logos is sufficient, but in practice, Fedora (and/or > Red Hat) shows up a few other places as well. In gnome, System->About Fedora > still shows up, and System->About Fedora still says "Distributor: Red Hat, > Inc." (this one probably ought to say "Fedora Project" for Fedora...). In web > pages, the apache identifier string is still "Apache/2.2.8 (Fedora)", and I'm > sure there are probably other cases as well. Well then the theory is blatantly wrong. -- 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 jwilson at redhat.com Mon Apr 14 13:19:18 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 14 Apr 2008 09:19:18 -0400 Subject: [Fedora-packaging] forbid fedora or redhat in spec files? In-Reply-To: <1208178434.586.5.camel@ignacio.lan> References: <20080413140620.GB2919@free.fr> <480301DF.7080703@poolshark.org> <48035426.8010108@redhat.com> <1208178434.586.5.camel@ignacio.lan> Message-ID: <480359D6.2080800@redhat.com> Ignacio Vazquez-Abrams wrote: > On Mon, 2008-04-14 at 08:55 -0400, Jarod Wilson wrote: >> One use case that comes to mind: someone doing a spin that can't meet the >> Fedora criteria for still being called Fedora. In theory, simply replacing >> fedora-release and fedora-logos is sufficient, but in practice, Fedora (and/or >> Red Hat) shows up a few other places as well. In gnome, System->About Fedora >> still shows up, and System->About Fedora Oops, meant "System->About Gnome" there. >> still says "Distributor: Red Hat, >> Inc." (this one probably ought to say "Fedora Project" for Fedora...). In web >> pages, the apache identifier string is still "Apache/2.2.8 (Fedora)", and I'm >> sure there are probably other cases as well. > > Well then the theory is blatantly wrong. Yep, that's exactly what I'm sayin'. -- Jarod Wilson jwilson at redhat.com From jkeating at redhat.com Mon Apr 14 14:10:05 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 Apr 2008 10:10:05 -0400 Subject: [Fedora-packaging] forbid fedora or redhat in spec files? In-Reply-To: <48035426.8010108@redhat.com> References: <20080413140620.GB2919@free.fr> <480301DF.7080703@poolshark.org> <48035426.8010108@redhat.com> Message-ID: <1208182205.5136.3.camel@localhost.localdomain> On Mon, 2008-04-14 at 08:55 -0400, Jarod Wilson wrote: > One use case that comes to mind: someone doing a spin that can't meet the > Fedora criteria for still being called Fedora. In theory, simply replacing > fedora-release and fedora-logos is sufficient, but in practice, Fedora (and/or > Red Hat) shows up a few other places as well. In gnome, System->About Fedora > still shows up, and System->About Fedora still says "Distributor: Red Hat, > Inc." (this one probably ought to say "Fedora Project" for Fedora...). In web > pages, the apache identifier string is still "Apache/2.2.8 (Fedora)", and I'm > sure there are probably other cases as well. Well, there is a difference in saying that we got these packages from Fedora, and "We are Fedora", and this could wind up being a lengthy discussion with the RH legal team. -- 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: 197 bytes Desc: This is a digitally signed message part URL: From smooge at gmail.com Mon Apr 14 18:42:50 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 14 Apr 2008 12:42:50 -0600 Subject: [Fedora-packaging] forbid fedora or redhat in spec files? In-Reply-To: <1208182205.5136.3.camel@localhost.localdomain> References: <20080413140620.GB2919@free.fr> <480301DF.7080703@poolshark.org> <48035426.8010108@redhat.com> <1208182205.5136.3.camel@localhost.localdomain> Message-ID: <80d7e4090804141142mb5534f5y5b19eff021781621@mail.gmail.com> On Mon, Apr 14, 2008 at 8:10 AM, Jesse Keating wrote: > On Mon, 2008-04-14 at 08:55 -0400, Jarod Wilson wrote: > > > One use case that comes to mind: someone doing a spin that can't meet the > > Fedora criteria for still being called Fedora. In theory, simply replacing > > fedora-release and fedora-logos is sufficient, but in practice, Fedora (and/or > > Red Hat) shows up a few other places as well. In gnome, System->About Fedora > > still shows up, and System->About Fedora still says "Distributor: Red Hat, > > Inc." (this one probably ought to say "Fedora Project" for Fedora...). In web > > pages, the apache identifier string is still "Apache/2.2.8 (Fedora)", and I'm > > sure there are probably other cases as well. > > Well, there is a difference in saying that we got these packages from > Fedora, and "We are Fedora", and this could wind up being a lengthy > discussion with the RH legal team. Where the problem comes up is where a project is not saying they are Fedora/Red Hat/etc but the packages say they are.. and where that line is where lawyers get lots of money :). -- 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 rdieter at math.unl.edu Mon Apr 14 18:48:32 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 14 Apr 2008 13:48:32 -0500 Subject: [Fedora-packaging] forbid fedora or redhat in spec files? In-Reply-To: <80d7e4090804141142mb5534f5y5b19eff021781621@mail.gmail.com> References: <20080413140620.GB2919@free.fr> <480301DF.7080703@poolshark.org> <48035426.8010108@redhat.com> <1208182205.5136.3.camel@localhost.localdomain> <80d7e4090804141142mb5534f5y5b19eff021781621@mail.gmail.com> Message-ID: <4803A700.2090709@math.unl.edu> Stephen John Smoogen wrote: > On Mon, Apr 14, 2008 at 8:10 AM, Jesse Keating wrote: >> On Mon, 2008-04-14 at 08:55 -0400, Jarod Wilson wrote: >> >>> One use case that comes to mind: someone doing a spin that can't meet the >> > Fedora criteria for still being called Fedora. In theory, simply replacing >> > fedora-release and fedora-logos is sufficient, but in practice, Fedora (and/or >> > Red Hat) shows up a few other places as well. In gnome, System->About Fedora >> > still shows up, and System->About Fedora still says "Distributor: Red Hat, >> > Inc." (this one probably ought to say "Fedora Project" for Fedora...). In web >> > pages, the apache identifier string is still "Apache/2.2.8 (Fedora)", and I'm >> > sure there are probably other cases as well. >> >> Well, there is a difference in saying that we got these packages from >> Fedora, and "We are Fedora", and this could wind up being a lengthy >> discussion with the RH legal team. > > Where the problem comes up is where a project is not saying they are > Fedora/Red Hat/etc but the packages say they are.. and where that line > is where lawyers get lots of money :). Either way, sounds like it's more a fedora-legal issue, and outside the jurisdiction of fedora packaging guidelines. -- Rex From pertusus at free.fr Mon Apr 14 20:27:41 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 14 Apr 2008 22:27:41 +0200 Subject: [Fedora-packaging] forbid fedora or redhat in spec files? In-Reply-To: <4803A700.2090709@math.unl.edu> References: <20080413140620.GB2919@free.fr> <480301DF.7080703@poolshark.org> <48035426.8010108@redhat.com> <1208182205.5136.3.camel@localhost.localdomain> <80d7e4090804141142mb5534f5y5b19eff021781621@mail.gmail.com> <4803A700.2090709@math.unl.edu> Message-ID: <20080414202741.GB3047@free.fr> On Mon, Apr 14, 2008 at 01:48:32PM -0500, Rex Dieter wrote: > > Either way, sounds like it's more a fedora-legal issue, and outside the > jurisdiction of fedora packaging guidelines. There is a legal aspect but also a ease of reusage which may be of relevance for packaging guidelines. Besides I am not on fedora-legal and I think that it should be better if somebody from the packaging commitee contacted legal about this issue. -- Pat From a.badger at gmail.com Wed Apr 16 21:19:34 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 16 Apr 2008 14:19:34 -0700 Subject: [Fedora-packaging] GCJ Clarification (was Re: More Java guidelines questions) In-Reply-To: <4806383F.1090201@redhat.com> References: <870180fe0804141435g4fb385bdhe65422b426002df6@mail.gmail.com> <48047BD5.5070203@redhat.com> <4804C64F.9000501@gmail.com> <4806383F.1090201@redhat.com> Message-ID: <48066D66.4010004@gmail.com> Andrew Haley wrote: > Toshio Kuratomi wrote: >> Andrew Haley wrote: >>> Amazing -- I never even imagined that such a thing as an annotation-only >>> package might exist! The guidelines are intended to allow reasonable >>> people to interpret them sensibly. In this case, AOT-compiling wouldn't >>> hurt but wouldn't be of much benefit, so I don't think it matters. >>> >> Andrew, if you could propose some wording changes to the Guidelines for >> this it would be most appreciated. > > OK. > > "In some rare cases Java packages might not contain any executable code > whatsoever, so AOT-compiling for gcj would not be required. An example > of such a package would be one that contained only annotations." > This seems like a clarification rather than a change. If this breaks anyone's expectations and they wants to vote on it speak now and we can take this up at the FPC Meeting otherwise I'll just add it to the top of: http://fedoraproject.org/wiki/Packaging/GCJGuidelines -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From pmatilai at laiskiainen.org Wed Apr 16 22:02:46 2008 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 17 Apr 2008 01:02:46 +0300 (EEST) Subject: [Fedora-packaging] Lua In-Reply-To: <47F699B5.6090502@hhs.nl> References: <1207334050.4162.23.camel@localhost.localdomain> <47F699B5.6090502@hhs.nl> Message-ID: On Fri, 4 Apr 2008, Hans de Goede wrote: > Tom "spot" Callaway wrote: >> On Fri, 2008-04-04 at 13:29 -0500, Jason L Tibbitts III wrote: >>> I see a few Lua packages have appeared in the review queue today. >>> >>> I checked out the specs and they all seem very clean. There are a few >>> issues (/usr/lib/lua seems to be unowned in rawhide, although >>> /usr/lib/lua/5.1 is owned by the lua package), the luasql packages >>> leave /usr/lib/lua/5.1/luasql unowned, etc.) but these seem to be >>> minor packaging issues. >>> >>> So, we need to decide whether we want to just go ahead with these >>> packages, or whether we want to do the "wait for guidelines" game >>> again. Is anyone interesting in writing some guidleines? It seems >>> like they'd be pretty tiny. Hans, the main Lua package seems to be >>> yours; are you interested in putting something together? >> >> I don't see a reason for a hold here. I would love to see Hans (or >> someone qualified) whip up some guidelines. >> > > I also don't see a reason for a hold. As for me being the lua maintainer, > thats only because it got orphaned and its used in a few games I maintain. My > lua knowledge is limited. So lets first see how these new packages go, and if > there is a need for lua specific guidelines at all. Only noticed this now, duh... I briefly maintained Lua in fedora.us and would be happy to help with it if you want. Both rpm and apt-rpm have and use an embedded Lua interpreter to varying degrees so I've both interest and some experience in it. - Panu - From j.w.r.degoede at hhs.nl Thu Apr 17 08:41:06 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 17 Apr 2008 10:41:06 +0200 Subject: [Fedora-packaging] Lua In-Reply-To: References: <1207334050.4162.23.camel@localhost.localdomain> <47F699B5.6090502@hhs.nl> Message-ID: <48070D22.3050101@hhs.nl> Panu Matilainen wrote: > On Fri, 4 Apr 2008, Hans de Goede wrote: > >> Tom "spot" Callaway wrote: >>> On Fri, 2008-04-04 at 13:29 -0500, Jason L Tibbitts III wrote: >>>> I see a few Lua packages have appeared in the review queue today. >>>> >>>> I checked out the specs and they all seem very clean. There are a few >>>> issues (/usr/lib/lua seems to be unowned in rawhide, although >>>> /usr/lib/lua/5.1 is owned by the lua package), the luasql packages >>>> leave /usr/lib/lua/5.1/luasql unowned, etc.) but these seem to be >>>> minor packaging issues. >>>> >>>> So, we need to decide whether we want to just go ahead with these >>>> packages, or whether we want to do the "wait for guidelines" game >>>> again. Is anyone interesting in writing some guidleines? It seems >>>> like they'd be pretty tiny. Hans, the main Lua package seems to be >>>> yours; are you interested in putting something together? >>> >>> I don't see a reason for a hold here. I would love to see Hans (or >>> someone qualified) whip up some guidelines. >>> >> >> I also don't see a reason for a hold. As for me being the lua >> maintainer, thats only because it got orphaned and its used in a few >> games I maintain. My lua knowledge is limited. So lets first see how >> these new packages go, and if there is a need for lua specific >> guidelines at all. > > Only noticed this now, duh... > > I briefly maintained Lua in fedora.us and would be happy to help with it > if you want. Both rpm and apt-rpm have and use an embedded Lua > interpreter to varying degrees so I've both interest and some experience > in it. > I've just "given away" a whole bunch of packages to other to lighten my load a bit including lua, lua is now in the capable hands of Tim Niemueller (timn), I'm sure he will welcome co-maintainers, so if you want to comaintain lua you should ask him. Regards, Hans p.s. I don't see rpm requiring lua in any way, perhaps it would be better for rpm to be build against the system version of lua instead of using its own private copy? From sergiodj at linux.vnet.ibm.com Thu Apr 17 17:37:19 2008 From: sergiodj at linux.vnet.ibm.com (=?ISO-8859-1?Q?S=E9rgio?= Durigan =?ISO-8859-1?Q?J=FAnior?=) Date: Thu, 17 Apr 2008 14:37:19 -0300 Subject: [Fedora-packaging] 32- and 64-bit softwares living together Message-ID: <1208453839.7258.13.camel@miki> Hello folks, I would like to know if there are any efforts to make both 32- and 64-bit versions of the same package "live" together in a system. I've been finding some packages that unfortunately break when you install both versions from the RPM (one example is Perl). Basically, what usually happens is: - The executable files for both 32- and 64-bit versions have the same names (e.g., "perl", "python") - The libraries for both versions are installed under /usr/lib - Some other arch-dependent (therefore, bitness-dependent) files are installed at the same place for both versions Those 3 situations make the last installed version to override things from the previous one. So, do you intend to solve this problem in future versions of Fedora? Thanks in advance, -- S?rgio Durigan J?nior Linux on Power Toolchain - Software Engineer Linux Technology Center - LTC IBM Brazil From rdieter at math.unl.edu Thu Apr 17 17:41:50 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 17 Apr 2008 12:41:50 -0500 Subject: [Fedora-packaging] 32- and 64-bit softwares living together In-Reply-To: <1208453839.7258.13.camel@miki> References: <1208453839.7258.13.camel@miki> Message-ID: <48078BDE.1050001@math.unl.edu> S?rgio Durigan J?nior wrote: > Hello folks, > > I would like to know if there are any efforts to make both 32- and > 64-bit versions of the same package "live" together in a system. 32/64 bit versions of any/all packages? No. But if the pkg's in question satisfy fedora's notion/definition of multilib (which is complicated in itself), yes. Clear as mud? :) -- Rex From sergiodj at linux.vnet.ibm.com Thu Apr 17 18:16:25 2008 From: sergiodj at linux.vnet.ibm.com (=?ISO-8859-1?Q?S=E9rgio?= Durigan =?ISO-8859-1?Q?J=FAnior?=) Date: Thu, 17 Apr 2008 15:16:25 -0300 Subject: [Fedora-packaging] 32- and 64-bit softwares living together In-Reply-To: <48078BDE.1050001@math.unl.edu> References: <1208453839.7258.13.camel@miki> <48078BDE.1050001@math.unl.edu> Message-ID: <1208456185.7258.23.camel@miki> Hi Rex, On Thu, 2008-04-17 at 12:41 -0500, Rex Dieter wrote: > S?rgio Durigan J?nior wrote: > > Hello folks, > > > > I would like to know if there are any efforts to make both 32- and > > 64-bit versions of the same package "live" together in a system. > > 32/64 bit versions of any/all packages? No. > > But if the pkg's in question satisfy fedora's notion/definition of > multilib (which is complicated in itself), yes. Well, what happens is that in some archs (specifically PowerPC in our case) it's very common to have a biarch environment (i.e., 64-bit kernel and mixed 32/64-bit userspace), so it's not a strange thing to have both versions of some software installed in the system. I've used Perl as an example, but I can cite a lot more packages that may need to be installed correctly in a biarch environment (Python, PHP, Ruby, Apache). That's the rationale behind my question :-). BTW, can you please tell me where can I find the multilib definition? I've been reading http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks , but I don't know if it's official. Thanks, -- S?rgio Durigan J?nior Linux on Power Toolchain - Software Engineer Linux Technology Center - LTC IBM Brazil From rdieter at math.unl.edu Thu Apr 17 18:27:28 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 17 Apr 2008 13:27:28 -0500 Subject: [Fedora-packaging] 32- and 64-bit softwares living together In-Reply-To: <1208456185.7258.23.camel@miki> References: <1208453839.7258.13.camel@miki> <48078BDE.1050001@math.unl.edu> <1208456185.7258.23.camel@miki> Message-ID: <48079690.3000200@math.unl.edu> S?rgio Durigan J?nior wrote: > Well, what happens is that in some archs (specifically PowerPC in our > case) it's very common to have a biarch environment (i.e., 64-bit kernel > and mixed 32/64-bit userspace), so it's not a strange thing to have both > versions of some software installed in the system. Right. If there are 32/64 packages available, and they don't properly install/run, then that's generally considered a bug (that should be fixed). -- Rex From rc040203 at freenet.de Fri Apr 18 03:19:23 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 18 Apr 2008 05:19:23 +0200 Subject: [Fedora-packaging] 32- and 64-bit softwares living together In-Reply-To: <48079690.3000200@math.unl.edu> References: <1208453839.7258.13.camel@miki> <48078BDE.1050001@math.unl.edu> <1208456185.7258.23.camel@miki> <48079690.3000200@math.unl.edu> Message-ID: <1208488763.23627.69.camel@beck.corsepiu.local> On Thu, 2008-04-17 at 13:27 -0500, Rex Dieter wrote: > S?rgio Durigan J?nior wrote: > > > Well, what happens is that in some archs (specifically PowerPC in our > > case) it's very common to have a biarch environment (i.e., 64-bit kernel > > and mixed 32/64-bit userspace), so it's not a strange thing to have both > > versions of some software installed in the system. > > Right. If there are 32/64 packages available, and they don't properly > install/run, then that's generally considered a bug (that should be fixed). Here is one: # rpm -q --qf "%{name}.%{arch}\n" -f /lib/libgcc_s.so.1 libgcc.i386 # rpm -q --qf "%{name}.%{arch}\n" -f \ /usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so gcc.x86_64 # ls -l /usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so /usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so -> /lib/libgcc_s.so.1 i.e. an x86_64 package depending on an i386 package. Now try to install /lib/libgcc_s.so.1 in an x86_64 mock chroot. I am trying to package a package which needs to build and run some bits "-m32 compiled on x86_64". Works in a normal (multilib'ed x86_64) environment, but I haven't managed to get this working in mock. Ralf From skvidal at fedoraproject.org Fri Apr 18 03:33:32 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 17 Apr 2008 23:33:32 -0400 Subject: [Fedora-packaging] 32- and 64-bit softwares living together In-Reply-To: <1208488763.23627.69.camel@beck.corsepiu.local> References: <1208453839.7258.13.camel@miki> <48078BDE.1050001@math.unl.edu> <1208456185.7258.23.camel@miki> <48079690.3000200@math.unl.edu> <1208488763.23627.69.camel@beck.corsepiu.local> Message-ID: <1208489612.823.214.camel@cutter> On Fri, 2008-04-18 at 05:19 +0200, Ralf Corsepius wrote: > On Thu, 2008-04-17 at 13:27 -0500, Rex Dieter wrote: > > S?rgio Durigan J?nior wrote: > > > > > Well, what happens is that in some archs (specifically PowerPC in our > > > case) it's very common to have a biarch environment (i.e., 64-bit kernel > > > and mixed 32/64-bit userspace), so it's not a strange thing to have both > > > versions of some software installed in the system. > > > > Right. If there are 32/64 packages available, and they don't properly > > install/run, then that's generally considered a bug (that should be fixed). > > Here is one: > > # rpm -q --qf "%{name}.%{arch}\n" -f /lib/libgcc_s.so.1 > libgcc.i386 > > # rpm -q --qf "%{name}.%{arch}\n" -f \ > /usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so > gcc.x86_64 > > # ls -l /usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so > /usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so > -> /lib/libgcc_s.so.1 > > i.e. an x86_64 package depending on an i386 package. > > > Now try to install /lib/libgcc_s.so.1 in an x86_64 mock chroot. > > I am trying to package a package which needs to build and run some bits > "-m32 compiled on x86_64". Works in a normal (multilib'ed x86_64) > environment, but I haven't managed to get this working in mock. > > try using yum 3.2.14 from rawhide with mock and remove the silly exclude that's in mock currently for x86_64 builds. I know mdomsch and jkeating have tested it and had good success with multilib_policy=best -sv From rc040203 at freenet.de Fri Apr 18 04:04:02 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 18 Apr 2008 06:04:02 +0200 Subject: [Fedora-packaging] 32- and 64-bit softwares living together In-Reply-To: <1208489612.823.214.camel@cutter> References: <1208453839.7258.13.camel@miki> <48078BDE.1050001@math.unl.edu> <1208456185.7258.23.camel@miki> <48079690.3000200@math.unl.edu> <1208488763.23627.69.camel@beck.corsepiu.local> <1208489612.823.214.camel@cutter> Message-ID: <1208491442.23627.77.camel@beck.corsepiu.local> On Thu, 2008-04-17 at 23:33 -0400, seth vidal wrote: > On Fri, 2008-04-18 at 05:19 +0200, Ralf Corsepius wrote: > > On Thu, 2008-04-17 at 13:27 -0500, Rex Dieter wrote: > > > S?rgio Durigan J?nior wrote: > > > > > > > Well, what happens is that in some archs (specifically PowerPC in our > > > > case) it's very common to have a biarch environment (i.e., 64-bit kernel > > > > and mixed 32/64-bit userspace), so it's not a strange thing to have both > > > > versions of some software installed in the system. > > > > > > Right. If there are 32/64 packages available, and they don't properly > > > install/run, then that's generally considered a bug (that should be fixed). > > > > Here is one: > > > > # rpm -q --qf "%{name}.%{arch}\n" -f /lib/libgcc_s.so.1 > > libgcc.i386 > > > > # rpm -q --qf "%{name}.%{arch}\n" -f \ > > /usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so > > gcc.x86_64 > > > > # ls -l /usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so > > /usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so > > -> /lib/libgcc_s.so.1 > > > > i.e. an x86_64 package depending on an i386 package. > > > > > > Now try to install /lib/libgcc_s.so.1 in an x86_64 mock chroot. > > > > I am trying to package a package which needs to build and run some bits > > "-m32 compiled on x86_64". Works in a normal (multilib'ed x86_64) > > environment, but I haven't managed to get this working in mock. > > > > > > try using yum 3.2.14 from rawhide with mock and remove the silly exclude > that's in mock currently for x86_64 builds. OK, this will likely resolve the "mock" part of this issue (yet untested), but leaves other parts unclear: Which rpm "arch" and which package does the /usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so -> /lib/libgcc_s.so.1 symlink belong to? ATM, it is part of gcc.x86_86 and is a dangling symlink in "pure basearch" installs. Should it (or even the whole m32 subdir) be part of an *.i386 package? Or, conversely should /lib/libgcc_s.so.1 (clearly i386'ed) be part of a "multilib'ed" gcc.x86_64 package or libgcc.x86_64 package? I don't know. Ralf From ville.skytta at iki.fi Fri Apr 18 05:54:42 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Fri, 18 Apr 2008 08:54:42 +0300 Subject: [Fedora-packaging] Packaging/SysVInitScript reload() bug Message-ID: <200804180854.42463.ville.skytta@iki.fi> The init script template in Packaging/SysVInitScript makes the reload action invoke restart if the service is running. This is a bug wrt. LSB, there the reload action is specified as: "cause the configuration of the service to be reloaded without actually stopping and restarting the service" I'd suggest changing the default reload() in the template to something like (this is how it is in the current rpmdevtools init script template): reload() { # If config can be reloaded without restarting, implement it here, # remove the "exit", and add "reload" to the usage message below. action $"Service $prog does not support the reload action: " /bin/false exit 3 } ...and removing "reload" from the default usage message. From caillon at redhat.com Fri Apr 18 16:08:03 2008 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 18 Apr 2008 12:08:03 -0400 Subject: [Fedora-packaging] desktop file validation Message-ID: <4808C763.8010508@redhat.com> I got recently called out for using desktop-file-validate instead of desktop-file-install when the upstream .desktop file is correct, doesn't need to be changed, and make install already places it in the correct location. Since the purpose of this guideline is to validate, I propose to amend the section of the packaging guidelines on desktop-file-install usage[1] as follows: * Rename the sub-heading from "desktop-file-install" to ".desktop file installation and validation" * Change the first sentence to: << It is not simply enough to just include the .desktop file in the package, one MUST run desktop-file-install OR desktop-file-validate in %install (and have BuildRequires: desktop-file-utils), to help ensure .desktop file safety and spec-compliance. desktop-file-install MUST be used if the package does not install the file or there are changes desired to the .desktop file (such as add/removing categories, etc). desktop-file-validate MAY be used instead if the .desktop file's content/location does not need modification. Here are some examples of usage: >> * Add the following example: << desktop-file-validate %{buildroot}/%{_datadir}/applications/foo.desktop >> Thoughts? [1] http://fedoraproject.org/wiki/Packaging/Guidelines#head-d559ee7363418a5840ce63090c608c991cd39ce6 From rdieter at math.unl.edu Fri Apr 18 16:28:39 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 18 Apr 2008 11:28:39 -0500 Subject: [Fedora-packaging] desktop file validation In-Reply-To: <4808C763.8010508@redhat.com> References: <4808C763.8010508@redhat.com> Message-ID: <4808CC37.9010907@math.unl.edu> Christopher Aillon wrote: > * Add the following example: > << > desktop-file-validate %{buildroot}/%{_datadir}/applications/foo.desktop > >> > Thoughts? +1, could even go into %check section. I *think* I had advocated the same change way been when, and the argument against it was (paraphrasing with my biased glasses on): "keep it simple, don't confuse folks with extraneous options and examples." -- Rex From tcallawa at redhat.com Tue Apr 22 16:07:50 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 22 Apr 2008 12:07:50 -0400 Subject: [Fedora-packaging] New Fedora Packaging Committee Members Message-ID: <1208880470.12717.50.camel@localhost.localdomain> The Fedora Packaging Committee is proud to announce its newest members: Xavier Lamien and Denis Leroy We would also like to thank Ville Skytt?, who is retiring from the committee. ~spot From tcallawa at redhat.com Tue Apr 22 16:41:02 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 22 Apr 2008 12:41:02 -0400 Subject: [Fedora-packaging] Static Library Policy Draft Changes In-Reply-To: <1207797436.22822.51.camel@localhost.localdomain> References: <1207691491.3065.101.camel@localhost.localdomain> <20080409031252.GA27678@nostromo.devel.redhat.com> <1207741027.11614.10.camel@localhost.localdomain> <1207744746.24618.162.camel@beck.corsepiu.local> <1207747665.11614.27.camel@localhost.localdomain> <1207748857.3000.16.camel@localhost.localdomain> <1207750229.24618.169.camel@beck.corsepiu.local> <1207794933.22822.47.camel@localhost.localdomain> <20080410025447.GB30323@nostromo.devel.redhat.com> <1207797436.22822.51.camel@localhost.localdomain> Message-ID: <1208882462.12717.72.camel@localhost.localdomain> On Wed, 2008-04-09 at 23:17 -0400, Jesse Keating wrote: > On Wed, 2008-04-09 at 22:54 -0400, Bill Nottingham wrote: > > The only way this can happen (AFAIK) is if they're linked by: > > > > - explicitly listing %{_libdir}/libfoo.a on the link line > > - explicitly passing -Wl,-bstatic > > > > Either of these things should be auditable. > > Ok, if that's the case, we can relax the need for the -noshared > subpackage. I'm really just going on the word of others here. I've rewritten it to remove the need for the -noshared subpackage: http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryPolicy In plain English: When shared libraries exist, static libraries go into -static (whether they have a shared library counterpart or not). Any packages which link against static libraries must BuildRequire: the -static subpackage. If (and only if) there are no shared libraries provided, then the static libraries can go in -devel, but -devel must also provide -static. It is worth noting that this draft is no longer significantly different from the current policies, but is a clarification to try and eliminate confusion. ~spot From pertusus at free.fr Tue Apr 22 17:19:04 2008 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 22 Apr 2008 19:19:04 +0200 Subject: [Fedora-packaging] Static Library Policy Draft Changes In-Reply-To: <1208882462.12717.72.camel@localhost.localdomain> References: <20080409031252.GA27678@nostromo.devel.redhat.com> <1207741027.11614.10.camel@localhost.localdomain> <1207744746.24618.162.camel@beck.corsepiu.local> <1207747665.11614.27.camel@localhost.localdomain> <1207748857.3000.16.camel@localhost.localdomain> <1207750229.24618.169.camel@beck.corsepiu.local> <1207794933.22822.47.camel@localhost.localdomain> <20080410025447.GB30323@nostromo.devel.redhat.com> <1207797436.22822.51.camel@localhost.localdomain> <1208882462.12717.72.camel@localhost.localdomain> Message-ID: <20080422171903.GF24590@free.fr> On Tue, Apr 22, 2008 at 12:41:02PM -0400, Tom spot Callaway wrote: > > I've rewritten it to remove the need for the -noshared subpackage: > > http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryPolicy > > If > (and only if) there are no shared libraries provided, then the static > libraries can go in -devel, but -devel must also provide -static. I have 2 related questions, maybe they could be part of this, if they hapen to need a guideline. It is in the case of no shared libraries provided: 1. Is it permitted to have a subpackage called mylib-static which holds what is generally in a devel subpackage, and Provides: mylib-devel = %{version}-%{release} 2. Is it permitted to have the headers in devel and the static library in -static and have mylib-devel Requires: mylib-static = %{version}-%{release} -- Pat From tcallawa at redhat.com Tue Apr 22 17:25:07 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 22 Apr 2008 13:25:07 -0400 Subject: [Fedora-packaging] Static Library Policy Draft Changes In-Reply-To: <20080422171903.GF24590@free.fr> References: <20080409031252.GA27678@nostromo.devel.redhat.com> <1207741027.11614.10.camel@localhost.localdomain> <1207744746.24618.162.camel@beck.corsepiu.local> <1207747665.11614.27.camel@localhost.localdomain> <1207748857.3000.16.camel@localhost.localdomain> <1207750229.24618.169.camel@beck.corsepiu.local> <1207794933.22822.47.camel@localhost.localdomain> <20080410025447.GB30323@nostromo.devel.redhat.com> <1207797436.22822.51.camel@localhost.localdomain> <1208882462.12717.72.camel@localhost.localdomain> <20080422171903.GF24590@free.fr> Message-ID: <1208885107.12717.80.camel@localhost.localdomain> On Tue, 2008-04-22 at 19:19 +0200, Patrice Dumas wrote: > 1. Is it permitted to have a subpackage called > mylib-static which holds what is generally in a devel subpackage, and > Provides: mylib-devel = %{version}-%{release} No. > 2. Is it permitted to have the headers in > devel and the static library in -static and have > mylib-devel > Requires: mylib-static = %{version}-%{release} Yes. But you'd still need to have any packages which link against the static libraries BuildRequire: mylib-static. ~spot From pertusus at free.fr Tue Apr 22 17:41:11 2008 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 22 Apr 2008 19:41:11 +0200 Subject: [Fedora-packaging] Static Library Policy Draft Changes In-Reply-To: <1208885107.12717.80.camel@localhost.localdomain> References: <1207744746.24618.162.camel@beck.corsepiu.local> <1207747665.11614.27.camel@localhost.localdomain> <1207748857.3000.16.camel@localhost.localdomain> <1207750229.24618.169.camel@beck.corsepiu.local> <1207794933.22822.47.camel@localhost.localdomain> <20080410025447.GB30323@nostromo.devel.redhat.com> <1207797436.22822.51.camel@localhost.localdomain> <1208882462.12717.72.camel@localhost.localdomain> <20080422171903.GF24590@free.fr> <1208885107.12717.80.camel@localhost.localdomain> Message-ID: <20080422174111.GG24590@free.fr> On Tue, Apr 22, 2008 at 01:25:07PM -0400, Tom spot Callaway wrote: > On Tue, 2008-04-22 at 19:19 +0200, Patrice Dumas wrote: > > 1. Is it permitted to have a subpackage called > > mylib-static which holds what is generally in a devel subpackage, and > > Provides: mylib-devel = %{version}-%{release} > > No. I think that we shouldn't say too much in the guidelines, but maybe this should be said, since currently there is a package that does that. (I have filed the bug Bug 443649, package is uudeview). > > 2. Is it permitted to have the headers in > > devel and the static library in -static and have > > mylib-devel > > Requires: mylib-static = %{version}-%{release} > > Yes. But you'd still need to have any packages which link against the > static libraries BuildRequire: mylib-static. Indeed. As a side note, I would have said the same (No for 1., Yes for 2.). -- Pat From tcallawa at redhat.com Tue Apr 22 20:31:25 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 22 Apr 2008 16:31:25 -0400 Subject: [Fedora-packaging] FPC Members: Possible times Message-ID: <1208896285.12717.103.camel@localhost.localdomain> FPC Members, Please go through this chart and mark the times which are preferred for you: http://fedoraproject.org/wiki/Packaging/NewMeetingTime If a time is good for you (and no other group is using it, add your username to that field, like this): spot++ ~spot From timothy.selivanow at virtualxistenz.com Thu Apr 24 22:43:53 2008 From: timothy.selivanow at virtualxistenz.com (Timothy Selivanow) Date: Thu, 24 Apr 2008 15:43:53 -0700 Subject: [Fedora-packaging] Etiquette for contacting a package maintainer? Message-ID: <1209077033.8910.47.camel@denkiteki-penpen.easystreet.com> What is the proper etiquette for contacting a current package maintainer? I'm working on a package that uses a current package as a dependency, and I have some questions that need to be asked... --Tim ___________________________________________________________ / Not only is UNIX dead, it's starting to smell really bad. \ \ -- Rob Pike / ----------------------------------------------------------- \ \ \ \ /\ ( ) .( o ). From tcallawa at redhat.com Thu Apr 24 22:50:32 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 24 Apr 2008 18:50:32 -0400 Subject: [Fedora-packaging] Etiquette for contacting a package maintainer? In-Reply-To: <1209077033.8910.47.camel@denkiteki-penpen.easystreet.com> References: <1209077033.8910.47.camel@denkiteki-penpen.easystreet.com> Message-ID: <1209077432.12717.316.camel@localhost.localdomain> On Thu, 2008-04-24 at 15:43 -0700, Timothy Selivanow wrote: > What is the proper etiquette for contacting a current package > maintainer? I'm working on a package that uses a current package as a > dependency, and I have some questions that need to be asked... Email them, and be polite? :) ~spot From skvidal at fedoraproject.org Thu Apr 24 22:54:22 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 24 Apr 2008 18:54:22 -0400 Subject: [Fedora-packaging] Etiquette for contacting a package maintainer? In-Reply-To: <1209077432.12717.316.camel@localhost.localdomain> References: <1209077033.8910.47.camel@denkiteki-penpen.easystreet.com> <1209077432.12717.316.camel@localhost.localdomain> Message-ID: <1209077662.15548.7.camel@cutter> On Thu, 2008-04-24 at 18:50 -0400, Tom "spot" Callaway wrote: > On Thu, 2008-04-24 at 15:43 -0700, Timothy Selivanow wrote: > > What is the proper etiquette for contacting a current package > > maintainer? I'm working on a package that uses a current package as a > > dependency, and I have some questions that need to be asked... > > Email them, and be polite? :) > What??! Without a formal 6-part introduction and etiquette session, followed by tea ceremony and ritual beating? Crazy! in this day an age just emailing someone! What IS the world coming to? -sv From timothy.selivanow at virtualxistenz.com Thu Apr 24 23:26:07 2008 From: timothy.selivanow at virtualxistenz.com (Timothy Selivanow) Date: Thu, 24 Apr 2008 16:26:07 -0700 Subject: [Fedora-packaging] Etiquette for contacting a package maintainer? In-Reply-To: <1209077432.12717.316.camel@localhost.localdomain> References: <1209077033.8910.47.camel@denkiteki-penpen.easystreet.com> <1209077432.12717.316.camel@localhost.localdomain> Message-ID: <1209079567.8910.51.camel@denkiteki-penpen.easystreet.com> On Thu, 2008-04-24 at 18:50 -0400, Tom "spot" Callaway wrote: > On Thu, 2008-04-24 at 15:43 -0700, Timothy Selivanow wrote: > > What is the proper etiquette for contacting a current package > > maintainer? I'm working on a package that uses a current package as a > > dependency, and I have some questions that need to be asked... > > Email them, and be polite? :) If I don't /have/ their email address, I just use ${FASName}@fedoraproject.org? Part of the "etiquette" I think I was/am needing is /how/ to get their email address... --Tim __________________________________________________________________________ / Where it is a duty to worship the sun it is pretty sure to be a crime to \ | examine the laws of heat. | \ -- Christopher Morley / -------------------------------------------------------------------------- \ \ \ \ /\ ( ) .( o ). From tcallawa at redhat.com Thu Apr 24 23:58:09 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 24 Apr 2008 19:58:09 -0400 Subject: [Fedora-packaging] Etiquette for contacting a package maintainer? In-Reply-To: <1209079567.8910.51.camel@denkiteki-penpen.easystreet.com> References: <1209077033.8910.47.camel@denkiteki-penpen.easystreet.com> <1209077432.12717.316.camel@localhost.localdomain> <1209079567.8910.51.camel@denkiteki-penpen.easystreet.com> Message-ID: <1209081489.12717.318.camel@localhost.localdomain> On Thu, 2008-04-24 at 16:26 -0700, Timothy Selivanow wrote: > On Thu, 2008-04-24 at 18:50 -0400, Tom "spot" Callaway wrote: > > On Thu, 2008-04-24 at 15:43 -0700, Timothy Selivanow wrote: > > > What is the proper etiquette for contacting a current package > > > maintainer? I'm working on a package that uses a current package as a > > > dependency, and I have some questions that need to be asked... > > > > Email them, and be polite? :) > > If I don't /have/ their email address, I just use > ${FASName}@fedoraproject.org? Part of the "etiquette" I think I was/am > needing is /how/ to get their email address... Ah, yes. That should work for everyone. ~spot From jkeating at redhat.com Fri Apr 25 00:05:49 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 24 Apr 2008 17:05:49 -0700 Subject: [Fedora-packaging] Etiquette for contacting a package maintainer? In-Reply-To: <1209081489.12717.318.camel@localhost.localdomain> References: <1209077033.8910.47.camel@denkiteki-penpen.easystreet.com> <1209077432.12717.316.camel@localhost.localdomain> <1209079567.8910.51.camel@denkiteki-penpen.easystreet.com> <1209081489.12717.318.camel@localhost.localdomain> Message-ID: <1209081949.20320.17.camel@localhost.localdomain> On Thu, 2008-04-24 at 19:58 -0400, Tom "spot" Callaway wrote: > > > > If I don't /have/ their email address, I just use > > ${FASName}@fedoraproject.org? Part of the "etiquette" I think I was/am > > needing is /how/ to get their email address... > > Ah, yes. That should work for everyone. I would still like to at some point get @fedoraproject.org which would do a pkgdb lookup and mail all involved with said package. Then all bugzilla ownerships can just go to @fp.o etc, etc... -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From tmz at pobox.com Fri Apr 25 00:15:14 2008 From: tmz at pobox.com (Todd Zullinger) Date: Thu, 24 Apr 2008 20:15:14 -0400 Subject: [Fedora-packaging] Etiquette for contacting a package maintainer? In-Reply-To: <1209081949.20320.17.camel@localhost.localdomain> References: <1209077033.8910.47.camel@denkiteki-penpen.easystreet.com> <1209077432.12717.316.camel@localhost.localdomain> <1209079567.8910.51.camel@denkiteki-penpen.easystreet.com> <1209081489.12717.318.camel@localhost.localdomain> <1209081949.20320.17.camel@localhost.localdomain> Message-ID: <20080425001514.GY26399@inocybe.teonanacatl.org> Jesse Keating wrote: > I would still like to at some point get @fedoraproject.org > which would do a pkgdb lookup and mail all involved with said package. > Then all bugzilla ownerships can just go to @fp.o etc, etc... This would be a very nice thing. Of course, it would cut down on the fun that everyone who needs to contact a number of maintainers has in adding code to grab the list of {,co-}maintainers for each package. ;) -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There is no pleasure in having nothing to do; the fun is in having lots to do and not doing it. -- Mary Wilson Little -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From skvidal at fedoraproject.org Fri Apr 25 01:48:03 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 24 Apr 2008 21:48:03 -0400 Subject: [Fedora-packaging] Etiquette for contacting a package maintainer? In-Reply-To: <1209081949.20320.17.camel@localhost.localdomain> References: <1209077033.8910.47.camel@denkiteki-penpen.easystreet.com> <1209077432.12717.316.camel@localhost.localdomain> <1209079567.8910.51.camel@denkiteki-penpen.easystreet.com> <1209081489.12717.318.camel@localhost.localdomain> <1209081949.20320.17.camel@localhost.localdomain> Message-ID: <1209088083.15548.9.camel@cutter> On Thu, 2008-04-24 at 17:05 -0700, Jesse Keating wrote: > On Thu, 2008-04-24 at 19:58 -0400, Tom "spot" Callaway wrote: > > > > > > If I don't /have/ their email address, I just use > > > ${FASName}@fedoraproject.org? Part of the "etiquette" I think I was/am > > > needing is /how/ to get their email address... > > > > Ah, yes. That should work for everyone. > > I would still like to at some point get @fedoraproject.org > which would do a pkgdb lookup and mail all involved with said package. > Then all bugzilla ownerships can just go to @fp.o etc, etc... > umm - not sure that'll work. it would mean a namespace conflict b/t people whose username is 'yum' and the package. probably best to have packagename at packages.fedoraproject.org -sv From tcallawa at redhat.com Fri Apr 25 01:50:52 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 24 Apr 2008 21:50:52 -0400 Subject: [Fedora-packaging] Etiquette for contacting a package maintainer? In-Reply-To: <1209088083.15548.9.camel@cutter> References: <1209077033.8910.47.camel@denkiteki-penpen.easystreet.com> <1209077432.12717.316.camel@localhost.localdomain> <1209079567.8910.51.camel@denkiteki-penpen.easystreet.com> <1209081489.12717.318.camel@localhost.localdomain> <1209081949.20320.17.camel@localhost.localdomain> <1209088083.15548.9.camel@cutter> Message-ID: <1209088252.12717.320.camel@localhost.localdomain> On Thu, 2008-04-24 at 21:48 -0400, seth vidal wrote: > it would mean a namespace conflict b/t people whose username is 'yum' > and the package. > > probably best to have packagename at packages.fedoraproject.org Yep. Seems like a good idea. ~spot From notting at redhat.com Fri Apr 25 02:19:11 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 24 Apr 2008 22:19:11 -0400 Subject: [Fedora-packaging] Etiquette for contacting a package maintainer? In-Reply-To: <1209088252.12717.320.camel@localhost.localdomain> References: <1209077033.8910.47.camel@denkiteki-penpen.easystreet.com> <1209077432.12717.316.camel@localhost.localdomain> <1209079567.8910.51.camel@denkiteki-penpen.easystreet.com> <1209081489.12717.318.camel@localhost.localdomain> <1209081949.20320.17.camel@localhost.localdomain> <1209088083.15548.9.camel@cutter> <1209088252.12717.320.camel@localhost.localdomain> Message-ID: <20080425021911.GA11741@nostromo.devel.redhat.com> Tom spot Callaway (tcallawa at redhat.com) said: > On Thu, 2008-04-24 at 21:48 -0400, seth vidal wrote: > > > it would mean a namespace conflict b/t people whose username is 'yum' > > and the package. > > > > probably best to have packagename at packages.fedoraproject.org > > Yep. Seems like a good idea. Or -owner/-maintainers. Something unlikely to have a username collision. Bill From skvidal at fedoraproject.org Fri Apr 25 02:27:23 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 24 Apr 2008 22:27:23 -0400 Subject: [Fedora-packaging] Etiquette for contacting a package maintainer? In-Reply-To: <20080425021911.GA11741@nostromo.devel.redhat.com> References: <1209077033.8910.47.camel@denkiteki-penpen.easystreet.com> <1209077432.12717.316.camel@localhost.localdomain> <1209079567.8910.51.camel@denkiteki-penpen.easystreet.com> <1209081489.12717.318.camel@localhost.localdomain> <1209081949.20320.17.camel@localhost.localdomain> <1209088083.15548.9.camel@cutter> <1209088252.12717.320.camel@localhost.localdomain> <20080425021911.GA11741@nostromo.devel.redhat.com> Message-ID: <1209090443.15548.15.camel@cutter> On Thu, 2008-04-24 at 22:19 -0400, Bill Nottingham wrote: > Tom spot Callaway (tcallawa at redhat.com) said: > > On Thu, 2008-04-24 at 21:48 -0400, seth vidal wrote: > > > > > it would mean a namespace conflict b/t people whose username is 'yum' > > > and the package. > > > > > > probably best to have packagename at packages.fedoraproject.org > > > > Yep. Seems like a good idea. > > Or -owner/-maintainers. Something unlikely to have > a username collision. > one hang up I realized: the owner for a package under EL5 may not necessarily equal the owner under F9. should it just go to all maintainers/co-maintainers on every release? -sv From tcallawa at redhat.com Fri Apr 25 02:41:50 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 24 Apr 2008 22:41:50 -0400 Subject: [Fedora-packaging] Etiquette for contacting a package maintainer? In-Reply-To: <1209090443.15548.15.camel@cutter> References: <1209077033.8910.47.camel@denkiteki-penpen.easystreet.com> <1209077432.12717.316.camel@localhost.localdomain> <1209079567.8910.51.camel@denkiteki-penpen.easystreet.com> <1209081489.12717.318.camel@localhost.localdomain> <1209081949.20320.17.camel@localhost.localdomain> <1209088083.15548.9.camel@cutter> <1209088252.12717.320.camel@localhost.localdomain> <20080425021911.GA11741@nostromo.devel.redhat.com> <1209090443.15548.15.camel@cutter> Message-ID: <1209091310.12717.322.camel@localhost.localdomain> On Thu, 2008-04-24 at 22:27 -0400, seth vidal wrote: > On Thu, 2008-04-24 at 22:19 -0400, Bill Nottingham wrote: > > Tom spot Callaway (tcallawa at redhat.com) said: > > > On Thu, 2008-04-24 at 21:48 -0400, seth vidal wrote: > > > > > > > it would mean a namespace conflict b/t people whose username is 'yum' > > > > and the package. > > > > > > > > probably best to have packagename at packages.fedoraproject.org > > > > > > Yep. Seems like a good idea. > > > > Or -owner/-maintainers. Something unlikely to have > > a username collision. > > > > one hang up I realized: the owner for a package under EL5 may not > necessarily equal the owner under F9. > > should it just go to all maintainers/co-maintainers on every release? Perhaps just the rawhide owners? ~spot From skvidal at fedoraproject.org Fri Apr 25 03:53:41 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 24 Apr 2008 23:53:41 -0400 Subject: [Fedora-packaging] Etiquette for contacting a package maintainer? In-Reply-To: <1209091310.12717.322.camel@localhost.localdomain> References: <1209077033.8910.47.camel@denkiteki-penpen.easystreet.com> <1209077432.12717.316.camel@localhost.localdomain> <1209079567.8910.51.camel@denkiteki-penpen.easystreet.com> <1209081489.12717.318.camel@localhost.localdomain> <1209081949.20320.17.camel@localhost.localdomain> <1209088083.15548.9.camel@cutter> <1209088252.12717.320.camel@localhost.localdomain> <20080425021911.GA11741@nostromo.devel.redhat.com> <1209090443.15548.15.camel@cutter> <1209091310.12717.322.camel@localhost.localdomain> Message-ID: <1209095621.15548.19.camel@cutter> On Thu, 2008-04-24 at 22:41 -0400, Tom "spot" Callaway wrote: > Perhaps just the rawhide owners? > Here's something to generate the list for all committers - no matter which release. B/c not all packages have a rawhide branch - or, if they do, the don't have an owner. http://skvidal.fedorapeople.org/misc/owner-email.py thanks to toshio for showing me where to look to do that. -sv From dtimms at iinet.net.au Sat Apr 26 04:07:32 2008 From: dtimms at iinet.net.au (David Timms) Date: Sat, 26 Apr 2008 14:07:32 +1000 Subject: [Fedora-packaging] desktop file validation In-Reply-To: <4808C763.8010508@redhat.com> References: <4808C763.8010508@redhat.com> Message-ID: <4812AA84.5010801@iinet.net.au> Christopher Aillon wrote: > I got recently called out for using desktop-file-validate instead of > desktop-file-install when the upstream .desktop file is correct, doesn't > need to be changed, and make install already places it in the correct > location. This all makes good sense; but what are the actual differences between -validate and -install ? Does install call validate ? From mclasen at redhat.com Sat Apr 26 14:42:57 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Sat, 26 Apr 2008 10:42:57 -0400 Subject: [Fedora-packaging] desktop file validation In-Reply-To: <4812AA84.5010801@iinet.net.au> References: <4808C763.8010508@redhat.com> <4812AA84.5010801@iinet.net.au> Message-ID: <1209220977.6682.1.camel@localhost.localdomain> On Sat, 2008-04-26 at 14:07 +1000, David Timms wrote: > Christopher Aillon wrote: > > I got recently called out for using desktop-file-validate instead of > > desktop-file-install when the upstream .desktop file is correct, doesn't > > need to be changed, and make install already places it in the correct > > location. > > This all makes good sense; but what are the actual differences between > -validate and -install ? > > Does install call validate ? Install validates the file that gets installed, but additionally, it lets you make changes to the file before installing it, like adding/removing OnlyShowIn keys, or changing categories, etc. From tibbs at math.uh.edu Wed Apr 30 03:42:46 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 29 Apr 2008 22:42:46 -0500 Subject: [Fedora-packaging] Copyrighted specfiles. Message-ID: I have a specfile that begins with: # Copyright 2006-2008 Double Precision, Inc. # See COPYING for distribution information. It looks like the specfile is carried in the tarball and the maintainer just copies it out for the Fedora package. But this means that when you unpack the srpm, you get a spec that refers to a file which does not exist. Is it too much to ask that if for some reason you're going to copyright the specfile you at least indicate the license in the specfile? - J<