From rc040203 at freenet.de Wed Jul 1 05:16:11 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 01 Jul 2009 07:16:11 +0200 Subject: [Fedora-packaging] next FPC meeting In-Reply-To: <4A4A618D.1000107@gmail.com> References: <4A4A618D.1000107@gmail.com> Message-ID: <4A4AF11B.9050106@freenet.de> Toshio Kuratomi wrote: > Hey guys, looks like with all the vacations and conferences that people > have been attending, we've lost track of the weeks that we want to be > doing meetings again. > > Spot has another commitment on July 7th. How does July 14th sound for > the next one? If there's quorum for a July 7th meeting we can meet then > as well/instead.... I'll stick my hand up and say I'm available on both > days. July 7th ... no, vacation. July 14th ... a << 50% possibility for yes. Still a road-blocker issue for me: The meeting time. 17:00 UTC does not work for me. Ralf From Fedora at FamilleCollet.com Wed Jul 1 05:30:15 2009 From: Fedora at FamilleCollet.com (Remi Collet) Date: Wed, 01 Jul 2009 07:30:15 +0200 Subject: [Fedora-packaging] Should Scintilla be package as a shared library ? Message-ID: <4A4AF467.2040906@FamilleCollet.com> Hi, http://www.scintilla.org/ is a free source code editing component. Upstream provides only a makefile for a static library. Of course, it's quite easy to create a shared library, but without versionning as upstream doesn't handle this. At least scite (in fedora repo) use this library, but probably other projects (I have no way to detect this). I'm working in MySQL Workbench, which also use it (and some other bundled libraries, as curl, boost, ..., more easy to remove) What sould I do ? - package scintilla as a shared lib (this will imply rebuilding all applications on scintilla update and probably issue with applications using different version) or - package MySQL Workbench with the bundled scintilla (the simple solution, but against good pratices) Thanks for your comment on this. Remi. From dominik at greysector.net Wed Jul 1 12:42:58 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 1 Jul 2009 14:42:58 +0200 Subject: [Fedora-packaging] Should Scintilla be package as a shared library ? In-Reply-To: <4A4AF467.2040906@FamilleCollet.com> References: <4A4AF467.2040906@FamilleCollet.com> Message-ID: <20090701124258.GC14891@mokona.greysector.net> Hi, On Wednesday, 01 July 2009 at 07:30, Remi Collet wrote: > Hi, [...] > What sould I do ? > > - package scintilla as a shared lib > > (this will imply rebuilding all applications on scintilla update and > probably issue with applications using different version) > > or > - package MySQL Workbench with the bundled scintilla > > (the simple solution, but against good pratices) 3. Ask upstream to add an option to build a shared lib. You can also make it easier for them by sending a patch. While there's no official ABI versioning, use something like libscintilla-VERSION.so.0 for SONAME to ensure ABI version changes with scintilla version (if necessary). You probably know how to track ABI changes. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From dominik at greysector.net Wed Jul 1 12:23:24 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 1 Jul 2009 14:23:24 +0200 Subject: [Fedora-packaging] next FPC meeting In-Reply-To: <4A4A618D.1000107@gmail.com> References: <4A4A618D.1000107@gmail.com> Message-ID: <20090701122324.GB14891@mokona.greysector.net> On Tuesday, 30 June 2009 at 21:03, Toshio Kuratomi wrote: > Hey guys, looks like with all the vacations and conferences that people > have been attending, we've lost track of the weeks that we want to be > doing meetings again. > > Spot has another commitment on July 7th. How does July 14th sound for > the next one? If there's quorum for a July 7th meeting we can meet then > as well/instead.... I'll stick my hand up and say I'm available on both > days. Both days are fine for me at 17:00 UTC. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From steve at lonetwin.net Wed Jul 1 14:20:16 2009 From: steve at lonetwin.net (steve) Date: Wed, 01 Jul 2009 16:20:16 +0200 Subject: [Fedora-packaging] Problem with tags for a package that does not use the %dist tag Message-ID: <4A4B70A0.1010609@lonetwin.net> Hi, I've submitted the Linux Device Driver book as a package: https://bugzilla.redhat.com/show_bug.cgi?id=507915 I decided to not use the %{dist} tag in the release number versioning based on the reasoning in the ticket. This package was approved and I check the package into cvs. When I did the initial check-in into the devel/ branch all the files got tagged as ldd_pdf-3.0-2 (notice the absence of %{dist}). Now I can build the package in the devel branch. However, I now have a problem, how do I build the package for F-10 and F-11 ? - Do I need to create a different tag 'manually' for each of these branches ? (since "make tag" tries to create the same tag as that of the devel branch) - If I do the above, would make build work ? what is the procedure followed by other packages which do not use the %dist tag ? regards, -steve From tibbs at math.uh.edu Wed Jul 1 15:48:26 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 01 Jul 2009 10:48:26 -0500 Subject: [Fedora-packaging] Problem with tags for a package that does not use the %dist tag In-Reply-To: <4A4B70A0.1010609@lonetwin.net> (steve@lonetwin.net's message of "Wed\, 01 Jul 2009 16\:20\:16 +0200") References: <4A4B70A0.1010609@lonetwin.net> Message-ID: >>>>> "s" == steve writes: s> I decided to not use the %{dist} tag in the release number s> versioning based on the reasoning in the ticket. This package was s> approved and I check the package into cvs. And in the review for one of the other packages you submitted (javanotes) I told you that you'd have tagging problems if you did this. You seem to have ignored that advice. s> Now I can build the package in the devel branch. However, I now s> have a problem, how do I build the package for F-10 and F-11 ? As I wrote in the javanotes review, you have to make sure that they have different release numbers that still sort properly. The easiest way to do this is to use the dist tag. s> - Do I need to create a different tag 'manually' for each of these s> branches ? No, just use the dist tag. s> what is the procedure followed by other packages which do not use s> the %dist tag ? Manually keep track of the release numbers. Assign release 3 to devel, release 2 to F11 and release 1 to F10 (except that you can't do that, since you already tagged release 1, so you'll need to start at release 4 in devel. And then if you have to update, you have more pain. You seem to think that not using the dist tag saves something somewhere; in reality, it just causes you exactly the trouble that you're having and doesn't really buy anything since each release is signed with a different key and so the packages have to be different anyway. - J< From steve at lonetwin.net Wed Jul 1 16:47:40 2009 From: steve at lonetwin.net (steve) Date: Wed, 01 Jul 2009 18:47:40 +0200 Subject: [Fedora-packaging] Problem with tags for a package that does not use the %dist tag In-Reply-To: References: <4A4B70A0.1010609@lonetwin.net> Message-ID: <4A4B932C.2020500@lonetwin.net> Hi Jason, Thanks for your comments, ... Jason L Tibbitts III wrote: >>>>>> "s" == steve writes: > > s> I decided to not use the %{dist} tag in the release number > s> versioning based on the reasoning in the ticket. This package was > s> approved and I check the package into cvs. > > And in the review for one of the other packages you submitted > (javanotes) I told you that you'd have tagging problems if you did > this. You seem to have ignored that advice. > I did not intend to deliberately ignore your advice, I just wanted to incorporate all the the comments received on my first accepted package (of this nature) into all of my other submissions. Since the ldd-pdf package was already 'approved' by the time you made the comment, I assumed that it would be ok. It's my mistake for not reading your comments on javanotes more closely. I was too hasty and over eager to get this done. > <...snip...> > You seem to think that not using the dist tag saves something > somewhere; in reality, it just causes you exactly the trouble that > you're having and doesn't really buy anything since each release is > signed with a different key and so the packages have to be different > anyway. > Well, now I do see the problems and also the mistake of assuming that there'd be something to gain. So, considering this wouldn't it be a good idea to document this reasoning and actively discourage the exclusion of the dist tag on this wiki page -- https://fedoraproject.org/wiki/Packaging:DistTag It states "Using the %{dist} tag is not mandatory,..." at the beginning and then leaves the decision up to the maintainer ... https://fedoraproject.org/wiki/Packaging:DistTag#Do_I_Have_To_Use_the_Dist_Tag.3F IMHO, the problems with building and tagging should be mentioned in the page to avoid further issues like this. Thanks everyone for your comments here and on the bz. cheers, - stev From tcallawa at redhat.com Wed Jul 1 17:08:40 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 01 Jul 2009 13:08:40 -0400 Subject: [Fedora-packaging] Problem with tags for a package that does not use the %dist tag In-Reply-To: References: <4A4B70A0.1010609@lonetwin.net> Message-ID: <4A4B9818.7090501@redhat.com> On 07/01/2009 11:48 AM, Jason L Tibbitts III wrote: > You seem to think that not using the dist tag saves something > somewhere; in reality, it just causes you exactly the trouble that > you're having and doesn't really buy anything since each release is > signed with a different key and so the packages have to be different > anyway. It's worth noting that this was not true when this document was originally written. It could probably use some additional discussion around how to deal with the cases where the dist tag is not in use. Anyone want to take a shot at that? ~spot From jussilehtola at fedoraproject.org Wed Jul 1 18:59:43 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Wed, 01 Jul 2009 20:59:43 +0200 Subject: [Fedora-packaging] Problem with tags for a package that does not use the %dist tag In-Reply-To: <4A4B9818.7090501@redhat.com> References: <4A4B70A0.1010609@lonetwin.net> <4A4B9818.7090501@redhat.com> Message-ID: <1246474783.4136.1.camel@hawking.theorphys.helsinki.fi> On Wed, 2009-07-01 at 13:08 -0400, Tom "spot" Callaway wrote: > On 07/01/2009 11:48 AM, Jason L Tibbitts III wrote: > > > You seem to think that not using the dist tag saves something > > somewhere; in reality, it just causes you exactly the trouble that > > you're having and doesn't really buy anything since each release is > > signed with a different key and so the packages have to be different > > anyway. > > It's worth noting that this was not true when this document was > originally written. It could probably use some additional discussion > around how to deal with the cases where the dist tag is not in use. > Anyone want to take a shot at that? I wasn't aware of the complications either, since they aren't documented anywhere. Could we just do things the easy way, and propose the %{?dist} tag to be made mandatory? -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From notting at redhat.com Wed Jul 1 19:37:56 2009 From: notting at redhat.com (Bill Nottingham) Date: Wed, 1 Jul 2009 15:37:56 -0400 Subject: [Fedora-packaging] Problem with tags for a package that does not use the %dist tag In-Reply-To: <1246474783.4136.1.camel@hawking.theorphys.helsinki.fi> References: <4A4B70A0.1010609@lonetwin.net> <4A4B9818.7090501@redhat.com> <1246474783.4136.1.camel@hawking.theorphys.helsinki.fi> Message-ID: <20090701193756.GB16043@nostromo.devel.redhat.com> Jussi Lehtola (jussilehtola at fedoraproject.org) said: > > > You seem to think that not using the dist tag saves something > > > somewhere; in reality, it just causes you exactly the trouble that > > > you're having and doesn't really buy anything since each release is > > > signed with a different key and so the packages have to be different > > > anyway. > > > > It's worth noting that this was not true when this document was > > originally written. It could probably use some additional discussion > > around how to deal with the cases where the dist tag is not in use. > > Anyone want to take a shot at that? > > I wasn't aware of the complications either, since they aren't documented > anywhere. > > Could we just do things the easy way, and propose the %{?dist} tag to be > made mandatory? Well, we have a proposal on the table to move to one global signing key, which removes one argument. Bill From kanarip at kanarip.com Sat Jul 4 03:59:14 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sat, 04 Jul 2009 05:59:14 +0200 Subject: [Fedora-packaging] Re: About my proposal of moving the stage to expand gem files In-Reply-To: <4A4E40C1.8060806@ioa.s.u-tokyo.ac.jp> References: <4A4E40C1.8060806@ioa.s.u-tokyo.ac.jp> Message-ID: <42f6f86279b0d9565b01f376c618e66a@localhost> On Sat, 04 Jul 2009 02:32:49 +0900, Mamoru Tasaka wrote: > Hello, all: > > Two weeks ago I wrote the proposal to move the stage to expand > rubygem files from %install to %prep as: > > https://www.redhat.com/archives/fedora-packaging/2009-June/msg00069.html > https://fedoraproject.org/wiki/PackagingDrafts/Gem_expand_stage_change > > I would appreciate it if you would write some opinion for my proposal > on fedora-packaging mailing list. > In my opinion, the guidelines requiring the use of the .gem instead of the .zip/.tar.gz is the root cause of the problem. If only we are allowed to use the .zip/.tar.gz, then in most cases we could extract the .zip/.tar.gz in %prep, apply patches in %prep, build the .gem in %build (if needed), do additional compiling in %build, and properly install in %install. I've never really understood the requirement to use the .gem anyway, so maybe that's what I'm missing. --Jeroen From kanarip at kanarip.com Sat Jul 4 04:21:07 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sat, 04 Jul 2009 06:21:07 +0200 Subject: [Fedora-packaging] Re: About my proposal of moving the stage to expand gem files Message-ID: <42f6f86279b0d9565b01f376c618e66a@localhost> Replying to myself.., this did not come out exactly as I wanted... .gem are basically a difficult .zip with stuff one should be able to generate (give or take a patch or additional sourceX), and so I think the solution to the problem is to spend a little more build time to generate the .gem where needed (from the .zip), then it is to mess up with %prep 'installing' the .gem and %build not doing anything just because the guidelines require the use of .gem in source. IMHO, in the long run, this proposed solution is going to make packaging more difficult and more prone to error. -- Jeroen @ android, early in the morning, so goodnight! ;) Jeroen van Meeuwen wrote: > >On Sat, 04 Jul 2009 02:32:49 +0900, Mamoru Tasaka > wrote: >> Hello, all: >> >> Two weeks ago I wrote the proposal to move the stage to expand >> rubygem files from %install to %prep as: >> >> https://www.redhat.com/archives/fedora-packaging/2009-June/msg00069.html >> https://fedoraproject.org/wiki/PackagingDrafts/Gem_expand_stage_change >> >> I would appreciate it if you would write some opinion for my proposal >> on fedora-packaging mailing list. >> > >In my opinion, the guidelines requiring the use of the .gem instead of the >.zip/.tar.gz is the root cause of the problem. > >If only we are allowed to use the .zip/.tar.gz, then in most cases we could >extract the .zip/.tar.gz in %prep, apply patches in %prep, build the .gem >in %build (if needed), do additional compiling in %build, and properly >install in %install. > >I've never really understood the requirement to use the .gem anyway, so >maybe that's what I'm missing. > >--Jeroen From jussilehtola at fedoraproject.org Mon Jul 6 13:37:19 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Mon, 06 Jul 2009 16:37:19 +0300 Subject: [Fedora-packaging] Use of optimization flags Message-ID: <1246887439.3076.8.camel@politzer.theorphys.helsinki.fi> Hi, atlas is not using %{optflags} at the moment [1], which results among other things in empty debuginfo files. Should this issue be raised with FeSCo? [1] https://bugzilla.redhat.com/show_bug.cgi?id=509813 -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From mtasaka at ioa.s.u-tokyo.ac.jp Mon Jul 6 13:44:14 2009 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Mon, 06 Jul 2009 22:44:14 +0900 Subject: [Fedora-packaging] Use of optimization flags In-Reply-To: <1246887439.3076.8.camel@politzer.theorphys.helsinki.fi> References: <1246887439.3076.8.camel@politzer.theorphys.helsinki.fi> Message-ID: <4A51FFAE.9060406@ioa.s.u-tokyo.ac.jp> Jussi Lehtola wrote, at 07/06/2009 10:37 PM +9:00: > Hi, > > > atlas is not using %{optflags} at the moment [1], which results among > other things in empty debuginfo files. Should this issue be raised with > FeSCo? > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=509813 This is against Fedora's policy and _must_ be fixed. Mamoru From jonathan.underwood at gmail.com Mon Jul 6 17:41:58 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 6 Jul 2009 18:41:58 +0100 Subject: [Fedora-packaging] Should Scintilla be package as a shared library ? In-Reply-To: <4A4AF467.2040906@FamilleCollet.com> References: <4A4AF467.2040906@FamilleCollet.com> Message-ID: <645d17210907061041h72271936g4abceb22442dc1eb@mail.gmail.com> 2009/7/1 Remi Collet : > Hi, > > http://www.scintilla.org/ is a free source code editing component. > > Upstream provides only a makefile for a static library. > > Of course, it's quite easy to create a shared library, but without > versionning as upstream doesn't handle this. > > At least scite (in fedora repo) use this library, but probably other > projects (I have no way to detect this). > > I'm working in MySQL Workbench, which also use it (and some other > bundled libraries, as curl, boost, ..., more easy to remove) > > What sould I do ? > > ? ? ? ?- package scintilla as a shared lib > > (this will imply rebuilding all applications on scintilla update and > probably issue with applications using different version) > > or > ? ? ? ?- package MySQL Workbench with the bundled scintilla > > (the simple solution, but against good pratices) > > Thanks for your comment on this. > Remi. Geany is another such application. From a.badger at gmail.com Mon Jul 6 18:08:31 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 06 Jul 2009 11:08:31 -0700 Subject: [Fedora-packaging] Should Scintilla be package as a shared library ? In-Reply-To: <645d17210907061041h72271936g4abceb22442dc1eb@mail.gmail.com> References: <4A4AF467.2040906@FamilleCollet.com> <645d17210907061041h72271936g4abceb22442dc1eb@mail.gmail.com> Message-ID: <4A523D9F.5050706@gmail.com> On 07/06/2009 10:41 AM, Jonathan Underwood wrote: > 2009/7/1 Remi Collet : >> Hi, >> >> http://www.scintilla.org/ is a free source code editing component. >> >> Upstream provides only a makefile for a static library. >> >> Of course, it's quite easy to create a shared library, but without >> versionning as upstream doesn't handle this. >> >> At least scite (in fedora repo) use this library, but probably other >> projects (I have no way to detect this). >> >> I'm working in MySQL Workbench, which also use it (and some other >> bundled libraries, as curl, boost, ..., more easy to remove) >> >> What sould I do ? >> >> - package scintilla as a shared lib >> >> (this will imply rebuilding all applications on scintilla update and >> probably issue with applications using different version) >> Talk to scintilla upstream about this. If they're amenable to shipping shared libraries in the future, this is the best thing to do. We can make it more attractive by offering to write the patches to enable building shared libraries if it helps (If scintilla uses autoconf/automake/libtool, this shouldn't be too hard to write). If they do not want to ship shared libraries then the scintilla maintainer needs to decide whether to ship shared libraries or just static. >> or >> - package MySQL Workbench with the bundled scintilla >> >> (the simple solution, but against good pratices) >> Don't do this. If you must, build scintilla as static libraries in its own package. Then follow the Guidelines related to static libraries for linking MySQL Workbench against it. The Guidelines for static linking were designed to make it as easy as possible for packages consuming static libraries to watch for problems in the libraries and do rebuilds whenever that occurred. Bundling, OTOH, makes it easy for applications to carry old versions of buggy libraries around for a long time. > Geany is another such application. > Yeap, having to track the problems with a single library in multiple applications is one of the reasons not to bundle even if we just build it as a static library. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From ultrafredde at gmail.com Mon Jul 6 20:18:57 2009 From: ultrafredde at gmail.com (Federico Hernandez) Date: Mon, 6 Jul 2009 22:18:57 +0200 Subject: [Fedora-packaging] License reference for additional, non-essential example files of a package Message-ID: <690f5ac90907061318o46f778e4iddda39bf4d4e7502@mail.gmail.com> Hi! The upstream project has some additional, non essential files (in this case vim syntax files which the upstream project "make install"s under the docdir). How should these reference to a license information? Do they have to include a license information? I ask as Bram Moolenaar has asked the upstream project to not have any license reference in the syntax files (the upstream project has submitted them to be included in the vim distribution). Would a reference to the license in a corresponding README file be enough? /Federico -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcallawa at redhat.com Mon Jul 6 20:52:21 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 06 Jul 2009 16:52:21 -0400 Subject: [Fedora-packaging] License reference for additional, non-essential example files of a package In-Reply-To: <690f5ac90907061318o46f778e4iddda39bf4d4e7502@mail.gmail.com> References: <690f5ac90907061318o46f778e4iddda39bf4d4e7502@mail.gmail.com> Message-ID: <4A526405.50802@redhat.com> On 07/06/2009 04:18 PM, Federico Hernandez wrote: > Hi! > > The upstream project has some additional, non essential files (in this > case vim syntax files which the upstream project "make install"s under > the docdir). How should these reference to a license information? Do > they have to include a license information? I ask as Bram Moolenaar has > asked the upstream project to not have any license reference in the > syntax files (the upstream project has submitted them to be included in > the vim distribution). Would a reference to the license in a > corresponding README file be enough? As a rule, any file which contains copyrightable material should contain license attribution in the header of that file. The full text of the license in the header is the optimal scenario, however, a description of the license along with a pointer to the license text (either to a separate file or a URL) is generally acceptable. Please avoid doing things like: # License text can be found in COPYING As files tend to move and be copied in and out of different software distributions, the COPYING file that was originally referred to is left behind, or completely different from the original. Instead, if the license text is too long to reasonably include in the header, use something like: # This file is available under the GNU Public License version 2 or later. # For the full text of this license, see COPYING. As to Bram's request that syntax files not have any license reference, I think that this is extremely poor practice on his part. However, at a minimum, a reference to the license in a corresponding README file, listing the explicit filenames which are under the license terms, is better than nothing. ~spot From jonathan.underwood at gmail.com Mon Jul 6 23:12:25 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 7 Jul 2009 00:12:25 +0100 Subject: [Fedora-packaging] Should Scintilla be package as a shared library ? In-Reply-To: <4A523D9F.5050706@gmail.com> References: <4A4AF467.2040906@FamilleCollet.com> <645d17210907061041h72271936g4abceb22442dc1eb@mail.gmail.com> <4A523D9F.5050706@gmail.com> Message-ID: <645d17210907061612s44d1620cyf440326c6e01bf4@mail.gmail.com> 2009/7/6 Toshio Kuratomi : > Don't do this. ?If you must, build scintilla as static libraries in its > own package. ?Then follow the Guidelines related to static libraries for > linking MySQL Workbench against it. ?The Guidelines for static linking > were designed to make it as easy as possible for packages consuming > static libraries to watch for problems in the libraries and do rebuilds > whenever that occurred. ?Bundling, OTOH, makes it easy for applications > to carry old versions of buggy libraries around for a long time. > >> Geany is another such application. >> > Yeap, having to track the problems with a single library in multiple > applications is one of the reasons not to bundle even if we just build > it as a static library. Yeah, fully agreed. There's some resistance upstream though, eg. http://sourceforge.net/tracker/index.php?func=detail&aid=2488121&group_id=2439&atid=352439 From ville.skytta at iki.fi Tue Jul 7 05:28:22 2009 From: ville.skytta at iki.fi (Ville =?windows-1252?q?Skytt=E4?=) Date: Tue, 7 Jul 2009 08:28:22 +0300 Subject: [Fedora-packaging] Use of optimization flags In-Reply-To: <1246887439.3076.8.camel@politzer.theorphys.helsinki.fi> References: <1246887439.3076.8.camel@politzer.theorphys.helsinki.fi> Message-ID: <200907070828.27742.ville.skytta@iki.fi> On Monday 06 July 2009, Jussi Lehtola wrote: > Hi, > > > atlas is not using %{optflags} at the moment [1], which results among > other things in empty debuginfo files. Should this issue be raised with > FeSCo? > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=509813 See also https://bugzilla.redhat.com/show_bug.cgi?id=501772 From jonstanley at gmail.com Tue Jul 7 13:25:14 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Tue, 7 Jul 2009 09:25:14 -0400 Subject: [Fedora-packaging] Fwd: Python package distribution standards In-Reply-To: <87bpnwpr26.fsf@benfinney.id.au> References: <87bpnwpr26.fsf@benfinney.id.au> Message-ID: If you are interested in Python packaging standards and not subscribed to the distributions list (where cross-distro collaboration happens), now would be a good time to do so :) ---------- Forwarded message ---------- From: Ben Finney Date: Tue, Jul 7, 2009 at 9:21 AM Subject: Python package distribution standards To: distributions at lists.freedesktop.org Cc: Distutils-Sig at python.org Howdy all, I'm cross-posting between the Python distutils discussion forum and the Freedesktop distributions discussion forum. If you think any OS-specific discussion forums need to be involved, please ask a representative to join one or more of these forums so the discussion doesn't get too attenuated. For a number of weeks now, the Python package distribution standards have been undergoing intensive scrutiny in the wake of much face-to-face discussion at Pycon 2009. Many goals are being juggled in an attempt to get a beneficial result for everyone affected by these standards. The discussion has reached a point of some ?open questions? on the current draft of PEP 376 , which has re-raised the issue of how Python distribution standards could be improved with regard to OS distribution packaging requirements. I've made a case for metadata that would be beneficial to OS packagers , but I am not very cognizant of the needs of specific OS packaging systems. We need input from others who know and care about how Python packages should fit into specific operating system package management systems. If you feel you have constructive input on how Python's package distribution metadata can be improved for the needs of OS packagers (along with other needs being targeted by such metadata), please read the standards drafts, join this discussion, and weigh in now while the topic is hot. -- ?\ ? ? ? ??The industrial system is profoundly dependent on commercial | ?`\ ? television and could not exist in its present form without it.? | _o__) ? ? ? ??John Kenneth Galbraith, _The New Industrial State_, 1967 | Ben Finney _______________________________________________ Distributions mailing list Distributions at lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/distributions From shakthimaan at gmail.com Wed Jul 8 11:03:12 2009 From: shakthimaan at gmail.com (Shakthi Kannan) Date: Wed, 8 Jul 2009 16:33:12 +0530 Subject: [Fedora-packaging] Packaging RPM workflow Message-ID: Hi, I have tried to put a very brief, to the point documentation on packaging RPM work-flow to be used for newbie packagers: http://shakthimaan.com/downloads/glv/howtos/packaging-rpm-workflow.html I'd appreciate any feedback on the same -- something that I have missed, or that needs to be added, modified, or fixed in the documentation. Thanks! SK -- Shakthi Kannan http://www.shakthimaan.com From lemenkov at gmail.com Wed Jul 8 11:12:28 2009 From: lemenkov at gmail.com (Peter Lemenkov) Date: Wed, 8 Jul 2009 15:12:28 +0400 Subject: [Fedora-packaging] Packaging RPM workflow In-Reply-To: References: Message-ID: Hello All! 2009/7/8 Shakthi Kannan : > Hi, > > I have tried to put a very brief, to the point documentation on > packaging RPM work-flow to be used for newbie packagers: > http://shakthimaan.com/downloads/glv/howtos/packaging-rpm-workflow.html > > I'd appreciate any feedback on the same -- something that I have > missed, or that needs to be added, modified, or fixed in the > documentation. Awesome! Would you mind if someone (me, for example) will translate it to other languages? -- With best regards! From shakthimaan at gmail.com Wed Jul 8 11:15:21 2009 From: shakthimaan at gmail.com (Shakthi Kannan) Date: Wed, 8 Jul 2009 16:45:21 +0530 Subject: [Fedora-packaging] Packaging RPM workflow In-Reply-To: References: Message-ID: Hi, --- On Wed, Jul 8, 2009 at 4:42 PM, Peter Lemenkov wrote: | Would you mind if someone (me, for example) will translate it to other | languages? \-- Sure! Please feel free to translate, re-use the documentation. SK -- Shakthi Kannan http://www.shakthimaan.com From jussilehtola at fedoraproject.org Wed Jul 8 11:24:32 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Wed, 08 Jul 2009 14:24:32 +0300 Subject: [Fedora-packaging] Packaging RPM workflow In-Reply-To: References: Message-ID: <1247052272.3501.3.camel@politzer.theorphys.helsinki.fi> On Wed, 2009-07-08 at 16:33 +0530, Shakthi Kannan wrote: > Hi, > > I have tried to put a very brief, to the point documentation on > packaging RPM work-flow to be used for newbie packagers: > http://shakthimaan.com/downloads/glv/howtos/packaging-rpm-workflow.html > > I'd appreciate any feedback on the same -- something that I have > missed, or that needs to be added, modified, or fixed in the > documentation. Looks fine, but isn't this duplicating pre-existing documentation [1]? Maybe this could be integrated in the existing version? [1] http://fedoraproject.org/wiki/PackageMaintainers/Join -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From shakthimaan at gmail.com Wed Jul 8 11:33:15 2009 From: shakthimaan at gmail.com (Shakthi Kannan) Date: Wed, 8 Jul 2009 17:03:15 +0530 Subject: [Fedora-packaging] Packaging RPM workflow In-Reply-To: <1247052272.3501.3.camel@politzer.theorphys.helsinki.fi> References: <1247052272.3501.3.camel@politzer.theorphys.helsinki.fi> Message-ID: Hi, --- On Wed, Jul 8, 2009 at 4:54 PM, Jussi Lehtola wrote: | Looks fine, but isn't this duplicating pre-existing documentation [1]? | Maybe this could be integrated in the existing version? | | [1] http://fedoraproject.org/wiki/PackageMaintainers/Join \-- This was more like a reference manual, to me. There was just too much text! The one I had prepared is a HOWTO, where one could go from start to finish. One could do that with a reference manual too, with time to read, and a bit of patience. SK -- Shakthi Kannan http://www.shakthimaan.com From wolfy at nobugconsulting.ro Wed Jul 8 11:31:18 2009 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Wed, 08 Jul 2009 14:31:18 +0300 Subject: [Fedora-packaging] Packaging RPM workflow In-Reply-To: References: Message-ID: <4A548386.5070708@nobugconsulting.ro> Shakthi Kannan wrote: > Hi, > > I have tried to put a very brief, to the point documentation on > packaging RPM work-flow to be used for newbie packagers: > http://shakthimaan.com/downloads/glv/howtos/packaging-rpm-workflow.html > > I'd appreciate any feedback on the same -- something that I have > missed, or that needs to be added, modified, or fixed in the > documentation. > > Thanks! > > SK > > I would not use "Send the package" in the last paragraph but "Push the package into the public repository" or something along this line. Otherwise the recipe is very nice, despite duplicating some existing pages. From tcallawa at redhat.com Wed Jul 8 11:53:34 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 08 Jul 2009 07:53:34 -0400 Subject: [Fedora-packaging] Packaging RPM workflow In-Reply-To: References: <1247052272.3501.3.camel@politzer.theorphys.helsinki.fi> Message-ID: <4A5488BE.8010301@redhat.com> On 07/08/2009 07:33 AM, Shakthi Kannan wrote: > Hi, > > --- On Wed, Jul 8, 2009 at 4:54 PM, Jussi > Lehtola wrote: > | Looks fine, but isn't this duplicating pre-existing documentation [1]? > | Maybe this could be integrated in the existing version? > | > | [1] http://fedoraproject.org/wiki/PackageMaintainers/Join > \-- > > This was more like a reference manual, to me. There was just too much text! > > The one I had prepared is a HOWTO, where one could go from start to > finish. One could do that with a reference manual too, with time to > read, and a bit of patience. Except... you're missing steps. At least: http://fedoraproject.org/wiki/PackageMaintainers/Join#Install_the_Client_Tools_.28Koji.29 That is pretty necessary to be successful in following your howto. I'm of the opinion that it is better to have the extra text than to have people confused as to how to accomplish a task, but perhaps someone with better documentation/wiki writing skills than I could merge these two documents into something where the short text expands out to the more thorough longer text by clicking.... ~spot From shakthimaan at gmail.com Wed Jul 8 12:18:08 2009 From: shakthimaan at gmail.com (Shakthi Kannan) Date: Wed, 8 Jul 2009 17:48:08 +0530 Subject: [Fedora-packaging] Packaging RPM workflow In-Reply-To: <4A5488BE.8010301@redhat.com> References: <1247052272.3501.3.camel@politzer.theorphys.helsinki.fi> <4A5488BE.8010301@redhat.com> Message-ID: Hi, --- On Wed, Jul 8, 2009 at 5:23 PM, Tom "spot" Callaway wrote: | Except... you're missing steps. At least: | | http://fedoraproject.org/wiki/PackageMaintainers/Join#Install_the_Client_Tools_.28Koji.29 \-- Thanks! SK -- Shakthi Kannan http://www.shakthimaan.com From bruno at wolff.to Thu Jul 9 20:34:54 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Thu, 9 Jul 2009 15:34:54 -0500 Subject: [Fedora-packaging] Version name for prerelease when upstream used date based versions Message-ID: <20090709203454.GA23382@wolff.to> I am looking a the suggested version name for a prerelease when upstream uses dates for their versions. I am close to having a package (colossus) ready, but one sticking point is that upstream is probably a week or two away from putting up a new public build (essentially a snapshot they want to recommend to general users). The code has changed a lot since their last public release, so that a snapshot now is really much more of a prerelease package than a post release. Some things have changed from the last public build to make it more suitable for packaging in Fedora, so packaging that version isn't very practical. Upstream is considering changing to more normal version names, but probably won't make such a change before the next public build. I could hold off on putting the package into rawhide until after they make the next public build making the issue moot. (I wasn't going to put the package into a released version of Fedora until then in any case.) I could also use a current date for the version of the package, but that won't correspond to any actual release made by the upstream. I could also use the date of the last public build even though the code has diverged since then. (I am not sure if the interface has changed much since then since for my own use I have been running current svn check outs for over a year and don't use the public build versions.) From wolfy at nobugconsulting.ro Thu Jul 9 20:41:43 2009 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Thu, 09 Jul 2009 23:41:43 +0300 Subject: [Fedora-packaging] Version name for prerelease when upstream used date based versions In-Reply-To: <20090709203454.GA23382@wolff.to> References: <20090709203454.GA23382@wolff.to> Message-ID: <4A565607.1070706@nobugconsulting.ro> On 07/09/2009 11:34 PM, Bruno Wolff III wrote: > I am looking a the suggested version name for a prerelease when upstream > uses dates for their versions. > Doesn't http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages , "example (pre-release svn checkout)" help ? > I am close to having a package (colossus) ready, but one sticking point is > that upstream is probably a week or two away from putting up a new public > build (essentially a snapshot they want to recommend to general users). The > code has changed a lot since their last public release, so that a snapshot > now is really much more of a prerelease package than a post release. Some > things have changed from the last public build to make it more suitable > for packaging in Fedora, so packaging that version isn't very practical. > > Upstream is considering changing to more normal version names, but probably > won't make such a change before the next public build. > > I could hold off on putting the package into rawhide until after they > make the next public build making the issue moot. (I wasn't going to put > the package into a released version of Fedora until then in any case.) > I could also use a current date for the version of the package, but that > won't correspond to any actual release made by the upstream. I could also > use the date of the last public build even though the code has diverged > since then. (I am not sure if the interface has changed much since then > since for my own use I have been running current svn check outs for over > a year and don't use the public build versions.) > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > -- Manuel Wolfshant linux registered user #131416 IT manager NoBug Consulting SRL A: Yes. >Q: Are you sure? >>A: Because it reverses the logical flow of conversation. >>>Q: Why is top posting frowned upon? From oget.fedora at gmail.com Thu Jul 9 20:42:33 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Thu, 9 Jul 2009 16:42:33 -0400 Subject: [Fedora-packaging] Version name for prerelease when upstream used date based versions In-Reply-To: <20090709203454.GA23382@wolff.to> References: <20090709203454.GA23382@wolff.to> Message-ID: On Thu, Jul 9, 2009 at 4:34 PM, Bruno Wolff III wrote: > I am looking a the suggested version name for a prerelease when upstream > uses dates for their versions. > > I am close to having a package (colossus) ready, but one sticking point is > that upstream is probably a week or two away from putting up a new public > build (essentially a snapshot they want to recommend to general users). The > code has changed a lot since their last public release, so that a snapshot > now is really much more of a prerelease package than a post release. Some > things have changed from the last public build to make it more suitable > for packaging in Fedora, so packaging that version isn't very practical. > > Upstream is considering changing to more normal version names, but probably > won't make such a change before the next public build. > > I could hold off on putting the package into rawhide until after they > make the next public build making the issue moot. (I wasn't going to put > the package into a released version of Fedora until then in any case.) > I could also use a current date for the version of the package, but that > won't correspond to any actual release made by the upstream. I could also > use the date of the last public build even though the code has diverged > since then. (I am not sure if the interface has changed much since then > since for my own use I have been running current svn check outs for over > a year and don't use the public build versions.) > I would use Version: 0 Release: 0.1.20090709%{?dist} and if there's an update next week Version: 0 Release: 0.2.20090716%{?dist} or something close. Orcan From bruno at wolff.to Fri Jul 10 04:59:52 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Thu, 9 Jul 2009 23:59:52 -0500 Subject: [Fedora-packaging] Version name for prerelease when upstream used date based versions In-Reply-To: <4A565607.1070706@nobugconsulting.ro> References: <20090709203454.GA23382@wolff.to> <4A565607.1070706@nobugconsulting.ro> Message-ID: <20090710045952.GA10075@wolff.to> On Thu, Jul 09, 2009 at 23:41:43 +0300, Manuel Wolfshant wrote: > On 07/09/2009 11:34 PM, Bruno Wolff III wrote: >> I am looking a the suggested version name for a prerelease when upstream >> uses dates for their versions. >> > Doesn't > http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages > , "example (pre-release svn checkout)" help ? If you know what the name of the version will be when it's released. However I don't know what the next release date, and hence version name, will be. So I can't do the prelease the way it is suggested there. From bruno at wolff.to Fri Jul 10 05:04:58 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Fri, 10 Jul 2009 00:04:58 -0500 Subject: [Fedora-packaging] Version name for prerelease when upstream used date based versions In-Reply-To: References: <20090709203454.GA23382@wolff.to> Message-ID: <20090710050458.GB10075@wolff.to> On Thu, Jul 09, 2009 at 16:42:33 -0400, Orcan Ogetbil wrote: > I would use > Version: 0 > Release: 0.1.20090709%{?dist} Calling it version 0 until upstream actually started using version numbers is one possibility I considered. I'd probably want to add in the svn rev number in addition to the date in the release name. From makowski.fedora at gmail.com Fri Jul 10 14:48:57 2009 From: makowski.fedora at gmail.com (philippe makowski) Date: Fri, 10 Jul 2009 16:48:57 +0200 Subject: [Fedora-packaging] /srv usage Message-ID: Hi, I would like to know if there is any rule about using /srv ? Firebird package need a place to store databases files, and reading the FHS rules, it seems that it is the right place for that instead of /var/lib From limb at jcomserv.net Fri Jul 10 14:50:34 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 10 Jul 2009 09:50:34 -0500 Subject: [Fedora-packaging] /srv usage In-Reply-To: References: Message-ID: <4A57553A.3030601@jcomserv.net> philippe makowski wrote: > Hi, > > I would like to know if there is any rule about using /srv ? > Firebird package need a place to store databases files, and reading > the FHS rules, it seems that it is the right place for that instead of > /var/lib > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > Other dmbs use /var/lib. Why is Firebird different? It was my understanding that we never touch /srv. -- in your fear, speak only peace in your fear, seek only love -d. bowie From jonstanley at gmail.com Fri Jul 10 14:56:38 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Fri, 10 Jul 2009 10:56:38 -0400 Subject: [Fedora-packaging] /srv usage In-Reply-To: <4A57553A.3030601@jcomserv.net> References: <4A57553A.3030601@jcomserv.net> Message-ID: On Fri, Jul 10, 2009 at 10:50 AM, Jon Ciesla wrote: > Other dmbs use /var/lib. ?Why is Firebird different? ?It was my > understanding that we never touch /srv. /srv is for site-specific data, which the site can layout however they like. We cannot place anything in /srv. If the user wishes to do so, they can change the configuration of the package (or if it doesn't support that, bind mount the dir, symlink it, or whatever :) ). From tcallawa at redhat.com Fri Jul 10 15:09:22 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 10 Jul 2009 11:09:22 -0400 Subject: [Fedora-packaging] /srv usage In-Reply-To: References: Message-ID: <4A5759A2.9080402@redhat.com> On 07/10/2009 10:48 AM, philippe makowski wrote: > Hi, > > I would like to know if there is any rule about using /srv ? > Firebird package need a place to store databases files, and reading > the FHS rules, it seems that it is the right place for that instead of > /var/lib https://fedoraproject.org/wiki/Packaging/Guidelines#No_Files_or_Directories_under_.2Fsrv Basically, you can't use /srv in Fedora packages. ~spot From makowski.fedora at gmail.com Fri Jul 10 15:26:26 2009 From: makowski.fedora at gmail.com (philippe makowski) Date: Fri, 10 Jul 2009 17:26:26 +0200 Subject: [Fedora-packaging] /srv usage In-Reply-To: <4A5759A2.9080402@redhat.com> References: <4A5759A2.9080402@redhat.com> Message-ID: 2009/7/10 Tom "spot" Callaway : > On 07/10/2009 10:48 AM, philippe makowski wrote: >> Hi, >> >> I would like to know if there is any rule about using /srv ? >> Firebird package need a place to store databases files, and reading >> the FHS rules, it seems that it is the right place for that instead of >> /var/lib > > https://fedoraproject.org/wiki/Packaging/Guidelines#No_Files_or_Directories_under_.2Fsrv > > Basically, you can't use /srv in Fedora packages. ok it was just a question thanks answering From makowski.fedora at gmail.com Fri Jul 10 16:52:32 2009 From: makowski.fedora at gmail.com (philippe makowski) Date: Fri, 10 Jul 2009 18:52:32 +0200 Subject: [Fedora-packaging] /srv usage In-Reply-To: <4A5759A2.9080402@redhat.com> References: <4A5759A2.9080402@redhat.com> Message-ID: 2009/7/10 Tom "spot" Callaway : > https://fedoraproject.org/wiki/Packaging/Guidelines#No_Files_or_Directories_under_.2Fsrv > Basically, you can't use /srv in Fedora packages. one more question to be sure is it possible that the package create /srv/firebird for instance with %config(noreplace) ? or in other word, is that possible to create a directory under /srv that would not be own after by the package ? From limb at jcomserv.net Fri Jul 10 16:55:10 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 10 Jul 2009 11:55:10 -0500 Subject: [Fedora-packaging] /srv usage In-Reply-To: References: <4A5759A2.9080402@redhat.com> Message-ID: <4A57726E.9020808@jcomserv.net> philippe makowski wrote: > 2009/7/10 Tom "spot" Callaway : > >> https://fedoraproject.org/wiki/Packaging/Guidelines#No_Files_or_Directories_under_.2Fsrv >> Basically, you can't use /srv in Fedora packages. >> > > one more question to be sure > is it possible that the package create /srv/firebird for instance with > %config(noreplace) ? > or in other word, is that possible to create a directory under /srv > that would not be own after by the package ? > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > That would be accomplished with %ghost, not %config(noreplace), but still a no-no. -- in your fear, speak only peace in your fear, seek only love -d. bowie From jkeating at redhat.com Fri Jul 10 17:25:17 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 10 Jul 2009 10:25:17 -0700 Subject: [Fedora-packaging] /srv usage In-Reply-To: References: <4A5759A2.9080402@redhat.com> Message-ID: <1247246717.2969.67.camel@localhost.localdomain> On Fri, 2009-07-10 at 18:52 +0200, philippe makowski wrote: > one more question to be sure > is it possible that the package create /srv/firebird for instance with > %config(noreplace) ? > or in other word, is that possible to create a directory under /srv > that would not be own after by the package ? No. We can't assume what the site admin wants to do with /srv/. Perhaps they have an internal software project called 'firebird' and want to store data in /srv/ for it. By having a package touch things in /srv/ or expect to read things from /srv/ we would be trampling on the site admin's local config and could cause data loss or corruption. /srv/ is a no fly zone, period. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- 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 fnasser at redhat.com Fri Jul 10 18:00:35 2009 From: fnasser at redhat.com (Fernando Nasser) Date: Fri, 10 Jul 2009 14:00:35 -0400 Subject: [Fedora-packaging] Version name for prerelease when upstream used date based versions In-Reply-To: <20090710050458.GB10075@wolff.to> References: <20090709203454.GA23382@wolff.to> <20090710050458.GB10075@wolff.to> Message-ID: <4A5781C3.4030800@redhat.com> +1 for Version: 0 Bruno Wolff III wrote: > On Thu, Jul 09, 2009 at 16:42:33 -0400, > Orcan Ogetbil wrote: > >> I would use >> Version: 0 >> Release: 0.1.20090709%{?dist} >> > > Calling it version 0 until upstream actually started using version numbers > is one possibility I considered. I'd probably want to add in the svn > rev number in addition to the date in the release name. > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > > From tcallawa at redhat.com Fri Jul 10 17:59:58 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 10 Jul 2009 13:59:58 -0400 Subject: [Fedora-packaging] /srv usage In-Reply-To: References: <4A5759A2.9080402@redhat.com> Message-ID: <4A57819E.3050001@redhat.com> On 07/10/2009 12:52 PM, philippe makowski wrote: > one more question to be sure > is it possible that the package create /srv/firebird for instance with > %config(noreplace) ? > or in other word, is that possible to create a directory under /srv > that would not be own after by the package ? Please don't do this. Packages must own all directories they create and packages can't own directories in /srv. ~spot From makowski.fedora at gmail.com Fri Jul 10 20:42:05 2009 From: makowski.fedora at gmail.com (philippe makowski) Date: Fri, 10 Jul 2009 22:42:05 +0200 Subject: [Fedora-packaging] /srv usage In-Reply-To: <4A57819E.3050001@redhat.com> References: <4A5759A2.9080402@redhat.com> <4A57819E.3050001@redhat.com> Message-ID: 2009/7/10 Tom "spot" Callaway : > On 07/10/2009 12:52 PM, philippe makowski wrote: >> one more question to be sure >> is it possible that the package create /srv/firebird for instance with >> %config(noreplace) ? >> or in other word, is that possible to create a directory under /srv >> that would not be own after by the package ? > > Please don't do this. Packages must own all directories they create and > packages can't own directories in /srv. Thanks for all your answers all is clear From tcallawa at redhat.com Fri Jul 10 22:20:49 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 10 Jul 2009 18:20:49 -0400 Subject: [Fedora-packaging] Open Seat on the Fedora Packaging Committee Message-ID: <4A57BEC1.1010000@redhat.com> The Fedora Packaging Committee has an open seat. Are you interested in helping to decide the packaging standards and guidelines for Fedora? Are you familiar with the inner workings of RPM and its spec file magic? Are you clinically insane? (Well, the last one isn't mandatory, but it helps.) Members of the Fedora Packaging Committee get: * My neverending gratitude * The ability to tell people "I'm on the Fedora Packaging Committee" * Good karma The FPC meets biweekly. In theory. (In practice, we meet less than that). If you're interested in this seat, please email me. ~spot From bruno at wolff.to Mon Jul 13 02:56:40 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Sun, 12 Jul 2009 21:56:40 -0500 Subject: [Fedora-packaging] Feedback on documentation Message-ID: <20090713025640.GA10794@wolff.to> I am a new packager following: http://fedoraproject.org/wiki/PackageMaintainers/Join And read the following note: Running ssh-add before doing any cvs operations is a very good idea. It will save you from having to type your key password for every operation. You only have to run ssh-add once per session, it will remember it until you log out or reboot. If "ssh-add" reports "Could not open a connection to your authentication agent.", start a new shell under it using "exec ssh-agent bash". However I was never asked for a password. I assume that my Fedora cert is just being picked up. Did I do something odd or is this note out of date? From alcapcom at gmail.com Mon Jul 13 07:56:15 2009 From: alcapcom at gmail.com (alcapcom) Date: Mon, 13 Jul 2009 09:56:15 +0200 Subject: [Fedora-packaging] EclipsePlugins guideline need a one line modification Message-ID: <4ccd9dcb0907130056q43a062a3u6ce73061ab9bb84a@mail.gmail.com> Hi there, Can you please apply the attached patch to the EclipsePlugins guideline - It only modify eclipse-mylyn link. Thanks, Alphonse -------------- next part -------------- --- EclipsePlugins.mediawiki.ori 2009-07-13 09:45:38.871815931 +0200 +++ EclipsePlugins.mediawiki 2009-07-13 09:47:19.640818278 +0200 @@ -239,7 +239,7 @@ $ -However, we end up with the plugin classes themselves being expanded in the org directory. [https://bugzilla.redhat.com/273881 Bug #273881] causes build failures when building debuginfo packages in this case. The acceptable workaround is to modify the build.properties file in the plugin to JAR the plugin code separately (ex. mylyn-webcore.jar) and include it within this expanded plugin directory. An example of this work-around can be seen in [http://cvs.fedoraproject.org/viewcvs/devel/eclipse-mylyn/ eclipse-mylyn] (specifically the patches related to org.eclipse.mylyn.webcore). +However, we end up with the plugin classes themselves being expanded in the org directory. [https://bugzilla.redhat.com/273881 Bug #273881] causes build failures when building debuginfo packages in this case. The acceptable workaround is to modify the build.properties file in the plugin to JAR the plugin code separately (ex. mylyn-webcore.jar) and include it within this expanded plugin directory. An example of this work-around can be seen in [http://cvs.fedoraproject.org/viewvc/devel/eclipse-mylyn/?pathrev=eclipse-mylyn-2_3_2-6_fc10 eclipse-mylyn] (specifically the patches related to org.eclipse.mylyn.webcore). === OSGi === OSGi bundles contain metadata just like RPMs do. This metadata can be used to automatically generate Provides and Requires similar to how it is done for mono packages. This functionality exists in Fedora's current rpm package but requires some investigation as at the time of this writing it does not appear to be functioning properly. From jussilehtola at fedoraproject.org Mon Jul 13 19:13:18 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Mon, 13 Jul 2009 22:13:18 +0300 Subject: [Fedora-packaging] make install INSTALL="install -p" to guidelines Message-ID: <1247512398.2592.20.camel@localhost.localdomain> Hi, could somebody add a mention of adding INSTALL="install -p" to argument of 'make install' as a fix of preserving the time stamp during install to the packaging guidelines? http://fedoraproject.org/wiki/Packaging/Guidelines#Timestamps This really should be in the spec file templates as well, since it's such a common packaging bug (and shouldn't break anything either). -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From rc040203 at freenet.de Tue Jul 14 03:04:14 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 14 Jul 2009 05:04:14 +0200 Subject: [Fedora-packaging] make install INSTALL="install -p" to guidelines In-Reply-To: <1247512398.2592.20.camel@localhost.localdomain> References: <1247512398.2592.20.camel@localhost.localdomain> Message-ID: <4A5BF5AE.4040008@freenet.de> Jussi Lehtola wrote: > Hi, > > > > could somebody add a mention of adding INSTALL="install -p" to argument > of 'make install' as a fix of preserving the time stamp during install > to the packaging guidelines? > > http://fedoraproject.org/wiki/Packaging/Guidelines#Timestamps > > This really should be in the spec file templates as well, since it's > such a common packaging bug (and shouldn't break anything either). Well, you are a new-comer to packaging, aren't you? Otherwise you'd likely know that "install -p" is highly controversal, because it doesn't guarantee consistency of timestamps and is mostly "eye-candy". Ralf From a.badger at gmail.com Tue Jul 14 05:07:02 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 13 Jul 2009 22:07:02 -0700 Subject: [Fedora-packaging] Feedback on documentation In-Reply-To: <20090713025640.GA10794@wolff.to> References: <20090713025640.GA10794@wolff.to> Message-ID: <4A5C1276.2030509@gmail.com> On 07/12/2009 07:56 PM, Bruno Wolff III wrote: > I am a new packager following: > http://fedoraproject.org/wiki/PackageMaintainers/Join > And read the following note: > Running ssh-add before doing any cvs operations is a very good idea. It will save you from having to type your key password for every operation. You only have to run ssh-add once per session, it will remember it until you log out or reboot. If "ssh-add" reports "Could not open a connection to your authentication agent.", start a new shell under it using "exec ssh-agent bash". > > However I was never asked for a password. I assume that my Fedora cert > is just being picked up. Did I do something odd or is this note out of date? > This is fedora-devel-list material. What it probably means is that you are not password protecting your ssh private key. This is insecure (if someone compromises your computer, they can pretend to be you for checking things into cvs, logging onto other fedora computers, etc). To remedy the situation, use: ssh-keygen -p -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From Fedora at FamilleCollet.com Tue Jul 14 16:38:22 2009 From: Fedora at FamilleCollet.com (Remi Collet) Date: Tue, 14 Jul 2009 18:38:22 +0200 Subject: [Fedora-packaging] For FPC : Change proposal to PHP Guidelines Message-ID: <4A5CB47E.2040602@FamilleCollet.com> Hi, We have some pending minor issues/questions with PHP packaging we should make clearer : 1/ use of /usr/share/php => 1 folder per library 2/ conditional in ABI check and in post/postun scriplet This conditions are present to maintain compatibility with older PHP version (5.1.6 on EL-5) and could be removed if package requires a recent version (> 5.2) 3/ ABI check With the update of PHP 5.3.0 in rawhide, I discover that a lot of C extensions doesn't use ABI check, Guidelines set is mandatory for PECL extension. Package could be installed, but extension couldn't be load, with the standard PHP error : Module compiled with module API=20060613 PHP compiled with module API=20090626 It seems clear it should be mandatory for all C extension. See bugs : cups https://bugzilla.redhat.com/show_bug.cgi?id=511106 ice https://bugzilla.redhat.com/show_bug.cgi?id=511068 graphviz https://bugzilla.redhat.com/show_bug.cgi?id=511092 uuid https://bugzilla.redhat.com/show_bug.cgi?id=511115 Please review my change proposal https://fedoraproject.org/wiki/PackagingDrafts/PHP Remi From makowski.fedora at gmail.com Wed Jul 15 14:38:48 2009 From: makowski.fedora at gmail.com (philippe makowski) Date: Wed, 15 Jul 2009 16:38:48 +0200 Subject: [Fedora-packaging] need help for a init script Message-ID: Hi, in the init script I do the following : INSTANCE=default FIREBIRD=/usr/lib/firebird MANAGER=$FIREBIRD/bin/fbmgr.bin .... start) echo -n "Starting $FULLNAME " daemon --user=$FBRunUser export FIREBIRD LD_LIBRARY_PATH;echo; $MANAGER -pidfile $pidfile -start -forever RETVAL=$? [ $RETVAL -eq 0 ] && touch /var/lock/subsys/$name echo ;; but is seems that the OK come too fast, certainly after the "export" not the "$MANAGER -pidfile $pidfile -start -forever" From dsd at laptop.org Wed Jul 15 16:06:03 2009 From: dsd at laptop.org (Daniel Drake) Date: Wed, 15 Jul 2009 17:06:03 +0100 Subject: [Fedora-packaging] request to use Conflicts in new package olpc-bootanim Message-ID: <1247673963.2176.33.camel@polyethylene> Hi, We'd like to get olpc-bootanim into Fedora. It provides the boot animation for the OLPC XO OS. However, this package provides /usr/bin/plymouth. It has to, since that's what the init scripts call into. As such, I think we have to add a Conflict with plymouth. Is that OK? We can't use plymouth at the moment, because it adds about 20 seconds to the boot time of the OLPC XO. Our own boot animation is simple and optimized. Thanks, Daniel From tcallawa at redhat.com Wed Jul 15 19:50:03 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 15 Jul 2009 15:50:03 -0400 Subject: [Fedora-packaging] request to use Conflicts in new package olpc-bootanim In-Reply-To: <1247673963.2176.33.camel@polyethylene> References: <1247673963.2176.33.camel@polyethylene> Message-ID: <4A5E32EB.1090501@redhat.com> On 07/15/2009 12:06 PM, Daniel Drake wrote: > Hi, > > We'd like to get olpc-bootanim into Fedora. It provides the boot > animation for the OLPC XO OS. > > However, this package provides /usr/bin/plymouth. It has to, since > that's what the init scripts call into. As such, I think we have to add > a Conflict with plymouth. > > Is that OK? Maybe if this only went into the OLPC branches... I'd almost prefer to see this converted into a proper plymouth theme... ~spot From oget.fedora at gmail.com Thu Jul 16 00:42:28 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Wed, 15 Jul 2009 20:42:28 -0400 Subject: [Fedora-packaging] Open Seat on the Fedora Packaging Committee In-Reply-To: <4A57BEC1.1010000@redhat.com> References: <4A57BEC1.1010000@redhat.com> Message-ID: On Fri, Jul 10, 2009 at 6:20 PM, Tom "spot" Callaway wrote: > The Fedora Packaging Committee has an open seat. It seems that FPC hasn't met for the last six weeks. Are you sure the number of open seats is just one? :) Orcan From tibbs at math.uh.edu Thu Jul 16 01:42:08 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 15 Jul 2009 20:42:08 -0500 Subject: [Fedora-packaging] Open Seat on the Fedora Packaging Committee In-Reply-To: (Orcan Ogetbil's message of "Wed\, 15 Jul 2009 20\:42\:28 -0400") References: <4A57BEC1.1010000@redhat.com> Message-ID: >>>>> "OO" == Orcan Ogetbil writes: OO> It seems that FPC hasn't met for the last six weeks. Are you sure OO> the number of open seats is just one? :) Yes, that is the number of empty seats. - J< From a.badger at gmail.com Fri Jul 17 08:54:46 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 17 Jul 2009 01:54:46 -0700 Subject: [Fedora-packaging] Draft to prohibit use of #!/usr/bin/env Message-ID: <4A603C56.60303@gmail.com> https://fedoraproject.org/wiki/Script_Interpreters_(draft) I've just submitted this draft. This seems to support the following feature which I need to find the owner of and coordinate with: https://fedoraproject.org/wiki/Features/SystemPythonExecutablesUseSystemPython DMalcolm, is that your Feature? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From dmalcolm at redhat.com Fri Jul 17 14:05:21 2009 From: dmalcolm at redhat.com (David Malcolm) Date: Fri, 17 Jul 2009 10:05:21 -0400 Subject: [Fedora-packaging] Re: Draft to prohibit use of #!/usr/bin/env In-Reply-To: <4A603C56.60303@gmail.com> References: <4A603C56.60303@gmail.com> Message-ID: <1247839521.6558.22.camel@radiator.bos.redhat.com> On Fri, 2009-07-17 at 01:54 -0700, Toshio Kuratomi wrote: > https://fedoraproject.org/wiki/Script_Interpreters_(draft) > > I've just submitted this draft. This seems to support the following > feature which I need to find the owner of and coordinate with: > > https://fedoraproject.org/wiki/Features/SystemPythonExecutablesUseSystemPython > > DMalcolm, is that your Feature? > I wrote that page. I hope the information in it is accurate and that the policy it expresses is worthwhile. However I don't have the time to own the feature and push it to completion [1]. If someone else wants to own it that would be great. (perhaps I should have put it in the drafts namespace?) Dave [1] doomed with $DAY_JOB stuff at the moment From lists at timj.co.uk Sat Jul 18 09:57:47 2009 From: lists at timj.co.uk (Tim Jackson) Date: Sat, 18 Jul 2009 10:57:47 +0100 Subject: [Fedora-packaging] Re: [Fedora-php-devel-list] For FPC : Change proposal to PHP Guidelines In-Reply-To: <4A5CB47E.2040602@FamilleCollet.com> References: <4A5CB47E.2040602@FamilleCollet.com> Message-ID: <4A619C9B.2030100@timj.co.uk> On 14/07/09 17:38, Remi Collet wrote: > We have some pending minor issues/questions with PHP packaging we should > make clearer : Thanks for doing this work Remi. > 1/ use of /usr/share/php > > => 1 folder per library Agreed, but I would change the word "extension" to "software" to avoid confusion with binary extensions, and re-word this a bit make the text clearer and more specific, for example: "Non-PEAR PHP software which provides shared libraries should put its PHP source files for such shared libraries in a subfolder of /usr/share/php, named according to the name of the software. For example, a library called "Whizz_Bang" (with a RPM called php-something-Whizz-Bang) would put the PHP source files for its shared libraries in /usr/share/php/Whizz_Bang ." > 2/ conditional in ABI check and in post/postun scriplet > > This conditions are present to maintain compatibility with older PHP > version (5.1.6 on EL-5) and could be removed if package requires a > recent version (> 5.2) I would suggest an easier-to-read introduction: "To be certain that a binary extension will run correctly with a particular version of PHP, it is necessary to check that a particular package has both API and ABIs matching the installed version of PHP. The mechanism for doing this has evolved over time and is as follows:" For the second part, I would split the specfile template into three parts as follows: For Fedora (all current versions): BuildRequires: php-devel Requires: php(zend-abi) = %{php_zend_api} Requires: php(api) = %{php_core_api} For Fedora EPEL 5: BuildRequires: php-devel Requires: php-api = %{php_apiver} There is no way of checking the ABI with packages for Fedora EPEL 5. For a spec file which is compatible with both Fedora and EPEL 5: BuildRequires: php-devel %if %{?php_zend_api}0 Requires: php(zend-abi) = %{php_zend_api} Requires: php(api) = %{php_core_api} %else Requires: php-api = %{php_apiver} %endif No API/ABI dependencies are available for Fedora EPEL 4 packages. > 3/ ABI check [...] > Module compiled with module API=20060613 > PHP compiled with module API=20090626 > > It seems clear it should be mandatory for all C extension. Definitely. Tim From Fedora at FamilleCollet.com Sat Jul 18 10:47:59 2009 From: Fedora at FamilleCollet.com (Remi Collet) Date: Sat, 18 Jul 2009 12:47:59 +0200 Subject: [Fedora-packaging] Re: [Fedora-php-devel-list] For FPC : Change proposal to PHP Guidelines In-Reply-To: <4A619C9B.2030100@timj.co.uk> References: <4A5CB47E.2040602@FamilleCollet.com> <4A619C9B.2030100@timj.co.uk> Message-ID: <4A61A85F.5020807@FamilleCollet.com> Le 18/07/2009 11:57, Tim Jackson a ?crit : Thanks for your corrections (applied) > There is no way of checking the ABI with packages for Fedora EPEL 5. In fact, when I rebuild all extensions (for 5.3) I notice the solution used by APC which is very specific to EL-5 %global php_zendabiver %((echo 0; php -i 2>/dev/null | sed -n 's/^PHP Extension => //p') | tail -1) Requires: php-zend-abi = %{php_zendabiver} Could be usefull, as php 5.1.x and 5.2.x provides both the same API (20041225) but different ABI (20050922 < 20060613) $ rpm -qp --provides /tmp/php-common-5.1.6-23.el5.i386.rpm | grep 200 php-api = 20041225 php-zend-abi = 20050922 Remi. From tibbs at math.uh.edu Sat Jul 18 14:00:49 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sat, 18 Jul 2009 09:00:49 -0500 Subject: [Fedora-packaging] Issue with PHP Naming guidelines Message-ID: The PHP guidelines seem rather clear that PHP modules all require a "php-" prefix (with some types of modules requiring additional designations like "php-pear-"). Recently I noticed that two modules, phpFlickr and phpSmug, were both submitted and approved. I held off on doing CVS for the latter; the reviewer's reasoning is as follows: "The php guidelines not withstanding, php-phpSmug struck me as unnecessary duplication and the same with php-phpFlickr." https://bugzilla.redhat.com/show_bug.cgi?id=510979 In general, I think it's the job of the reviewer to point out issues in the guidelines rather than to simply ignore them. However, what's done is done (unless we want to force a rename of phpFlickr, which has already been imported) but I figured I'd ask if FPC wants to consider ammending the guidelines to cover this case, or suggest another name for this package. Personally I'm not really inclined to an exception, because we have other packages like php-pear-PHP-CodeSniffer.noarch, php-pear-PHPUnit.noarch, php-pear-PhpDocumentor.noarch with no complaints about naming, but also phpTodo, phpMyAdmin and phpPgAdmin which are not modules but applications which happen to have PHP in their names. - J< From chris.stone at gmail.com Sat Jul 18 15:48:44 2009 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 18 Jul 2009 08:48:44 -0700 Subject: [Fedora-packaging] Issue with PHP Naming guidelines In-Reply-To: References: Message-ID: On Sat, Jul 18, 2009 at 7:00 AM, Jason L Tibbitts III wrote: > The PHP guidelines seem rather clear that PHP modules all require a > "php-" prefix (with some types of modules requiring additional > designations like "php-pear-"). ?Recently I noticed that two modules, > phpFlickr and phpSmug, were both submitted and approved. ?I held off > on doing CVS for the latter; the reviewer's reasoning is as follows: > > "The php guidelines not withstanding, php-phpSmug struck me as > unnecessary duplication and the same with php-phpFlickr." > > https://bugzilla.redhat.com/show_bug.cgi?id=510979 > > In general, I think it's the job of the reviewer to point out issues > in the guidelines rather than to simply ignore them. ?However, what's > done is done (unless we want to force a rename of phpFlickr, which has > already been imported) but I figured I'd ask if FPC wants to consider > ammending the guidelines to cover this case, or suggest another name > for this package. ?Personally I'm not really inclined to an exception, > because we have other packages like php-pear-PHP-CodeSniffer.noarch, > php-pear-PHPUnit.noarch, php-pear-PhpDocumentor.noarch with no > complaints about naming, but also phpTodo, phpMyAdmin and phpPgAdmin > which are not modules but applications which happen to have PHP in > their names. I think these applications fall under the: "Note that web applications that happen to be written in PHP do not belong under the php-* namespace." part of the PHP guidelines. These applications are not installing .so files in %{_libdir}/php, but rather php files in %{_datadir}/php Well atleast phpSmug, I did not look at phpFlickr. Hope this clarifies things, please correct me if I'm mistaken. Best Regards, Chris From tibbs at math.uh.edu Sat Jul 18 16:01:14 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sat, 18 Jul 2009 11:01:14 -0500 Subject: [Fedora-packaging] Issue with PHP Naming guidelines In-Reply-To: (Christopher Stone's message of "Sat\, 18 Jul 2009 08\:48\:44 -0700") References: Message-ID: >>>>> "CS" == Christopher Stone writes: CS> I think these applications fall under the: "Note that web CS> applications that happen to be written in PHP do not belong under CS> the php-* namespace." part of the PHP guidelines. I'm not sure I understood this response. The only reason I mentioned applications was to point out that there are a few packages which start with php* that aren't PHP modules, but that the two packages I was questioning explicitly do not fit into that category. Maybe I shouldn't have mentioned them at all, because it seems to have confused the issue. Do I need to re-post my original message without that mention? CS> These applications are not installing .so files in %{_libdir}/php, CS> but rather php files in %{_datadir}/php Well atleast phpSmug, I CS> did not look at phpFlickr. My understanding is that phpSmug and phpFlickr are indeed PHP modules, no different from php-Smarty. Since they're not pear or pecl modules, they fall under "Other packages should be named php-PackageName-%{version}-%{release}.%{arch}.rpm; %{arch} can be "noarch" where appropriate." http://fedoraproject.org/wiki/Packaging:PHP#Naming_scheme - J< From chris.stone at gmail.com Sat Jul 18 16:14:18 2009 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 18 Jul 2009 09:14:18 -0700 Subject: [Fedora-packaging] Issue with PHP Naming guidelines In-Reply-To: References: Message-ID: On Sat, Jul 18, 2009 at 9:01 AM, Jason L Tibbitts III wrote: >>>>>> "CS" == Christopher Stone writes: > > CS> I think these applications fall under the: "Note that web > CS> applications that happen to be written in PHP do not belong under > CS> the php-* namespace." part of the PHP guidelines. > > I'm not sure I understood this response. ?The only reason I mentioned > applications was to point out that there are a few packages which > start with php* that aren't PHP modules, but that the two packages I > was questioning explicitly do not fit into that category. ?Maybe I > shouldn't have mentioned them at all, because it seems to have > confused the issue. ?Do I need to re-post my original message > without that mention? > > CS> These applications are not installing .so files in %{_libdir}/php, > CS> but rather php files in %{_datadir}/php Well atleast phpSmug, I > CS> did not look at phpFlickr. > > My understanding is that phpSmug and phpFlickr are indeed PHP modules, > no different from php-Smarty. ?Since they're not pear or pecl modules, > they fall under "Other packages should be named > php-PackageName-%{version}-%{release}.%{arch}.rpm; %{arch} can be > "noarch" where appropriate." > > http://fedoraproject.org/wiki/Packaging:PHP#Naming_scheme No, I'm arguing that a php module as being defined as something which puts a .so file under %{_libdir}/php. I too was just considering the php-Smarty case. It is a package which I own, but was originally owned by someone else. I tried to find the review request on php-Smarty to see if this issue came up, but could not find it (my searching skillz might need improvement), if you can find the review and it mentions this issue, please provide a link. However, I would think that php-Smarty could (and perhaps should) be actually named just "Smarty". From tibbs at math.uh.edu Sat Jul 18 16:19:07 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sat, 18 Jul 2009 11:19:07 -0500 Subject: [Fedora-packaging] Issue with PHP Naming guidelines In-Reply-To: (Christopher Stone's message of "Sat\, 18 Jul 2009 09\:14\:18 -0700") References: Message-ID: >>>>> "CS" == Christopher Stone writes: CS> No, I'm arguing that a php module as being defined as something CS> which puts a .so file under %{_libdir}/php. So pear packages aren't PHP modules? They're all noarch (pretty much by definition) and so don't have .so files. - J< From Fedora at FamilleCollet.com Sat Jul 18 16:37:00 2009 From: Fedora at FamilleCollet.com (Remi Collet) Date: Sat, 18 Jul 2009 18:37:00 +0200 Subject: [Fedora-packaging] Issue with PHP Naming guidelines In-Reply-To: References: Message-ID: <4A61FA2C.9020903@FamilleCollet.com> Le 18/07/2009 18:19, Jason L Tibbitts III a ?crit : >>>>>> "CS" == Christopher Stone writes: > > CS> No, I'm arguing that a php module as being defined as something > CS> which puts a .so file under %{_libdir}/php. > > So pear packages aren't PHP modules? They're all noarch (pretty much > by definition) and so don't have .so files. I think tibbs is right in his first post PHP Web app, (generally under /usr/share/appname) is out of php-* namespace and is called appname (phpMyAdmin, glpi, foo) A PHP extension, written in PHP, providing some classes, is installed under /usr/share/php (to benefit of default include_path) and is under the php-* namespace, so must be called php-foo (according to the actual PHP Guidelines) If I well understand, the question is Should we make an exception if name already start by php to avoid php-phpxxx. Personaly, I think php- prefix should be add to "all" extensions. + From chris.stone at gmail.com Sat Jul 18 17:00:53 2009 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 18 Jul 2009 10:00:53 -0700 Subject: [Fedora-packaging] Issue with PHP Naming guidelines In-Reply-To: <4A61FA2C.9020903@FamilleCollet.com> References: <4A61FA2C.9020903@FamilleCollet.com> Message-ID: On Sat, Jul 18, 2009 at 9:37 AM, Remi Collet wrote: > Le 18/07/2009 18:19, Jason L Tibbitts III a ?crit : >>>>>>> "CS" == Christopher Stone writes: >> >> CS> No, I'm arguing that a php module as being defined as something >> CS> which puts a .so file under %{_libdir}/php. >> >> So pear packages aren't PHP modules? ?They're all noarch (pretty much >> by definition) and so don't have .so files. > > I think tibbs is right in his first post > > PHP Web app, (generally under /usr/share/appname) is out of php-* > namespace and is called appname (phpMyAdmin, glpi, foo) > > A PHP extension, written in PHP, providing some classes, is installed > under /usr/share/php (to benefit of default include_path) and is under > the php-* namespace, so must be called php-foo (according to the actual > PHP Guidelines) > > If I well understand, the question is > Should we make an exception if name already start by php to avoid > php-phpxxx. > > Personaly, I think php- prefix should be add to "all" extensions. Okay, I found the review[1] and the exact same discussion took place in Oct 2005 ;-) I stand corrected. Thanks. :) [1] https://bugzilla.redhat.com/show_bug.cgi?id=170701 From lists at timj.co.uk Sat Jul 18 17:04:13 2009 From: lists at timj.co.uk (Tim Jackson) Date: Sat, 18 Jul 2009 18:04:13 +0100 Subject: [Fedora-packaging] Issue with PHP Naming guidelines In-Reply-To: References: Message-ID: <4A62008D.3070903@timj.co.uk> On 18/07/09 15:00, Jason L Tibbitts III wrote: > The PHP guidelines seem rather clear that PHP modules all require a > "php-" prefix (with some types of modules requiring additional > designations like "php-pear-"). Recently I noticed that two modules, > phpFlickr and phpSmug, were both submitted and approved. I held off > on doing CVS for the latter; the reviewer's reasoning is as follows: > > "The php guidelines not withstanding, php-phpSmug struck me as > unnecessary duplication and the same with php-phpFlickr." I can see the point, but I agree think we should leave the guidelines as is. php-phpFlickr *does* sound a bit clumsy, but at least it's consistent. Otherwise, if I saw phpXXX in a package listing, I would think it's an app like phpMyAdmin, rather than a library. Tim From chris.stone at gmail.com Sat Jul 18 17:06:51 2009 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 18 Jul 2009 10:06:51 -0700 Subject: [Fedora-packaging] Issue with PHP Naming guidelines In-Reply-To: <4A62008D.3070903@timj.co.uk> References: <4A62008D.3070903@timj.co.uk> Message-ID: On Sat, Jul 18, 2009 at 10:04 AM, Tim Jackson wrote: > On 18/07/09 15:00, Jason L Tibbitts III wrote: > >> The PHP guidelines seem rather clear that PHP modules all require a >> "php-" prefix (with some types of modules requiring additional >> designations like "php-pear-"). ?Recently I noticed that two modules, >> phpFlickr and phpSmug, were both submitted and approved. ?I held off >> on doing CVS for the latter; the reviewer's reasoning is as follows: >> >> "The php guidelines not withstanding, php-phpSmug struck me as >> unnecessary duplication and the same with php-phpFlickr." > > I can see the point, but I agree think we should leave the guidelines as is. > php-phpFlickr *does* sound a bit clumsy, but at least it's consistent. > Otherwise, if I saw phpXXX in a package listing, I would think it's an app > like phpMyAdmin, rather than a library. I don't know if the guidelines would strictly allow for it, but it seems php-Smug, php-Flickr would be an acceptable compromise. Regards, Chris From lists at timj.co.uk Sat Jul 18 17:40:30 2009 From: lists at timj.co.uk (Tim Jackson) Date: Sat, 18 Jul 2009 18:40:30 +0100 Subject: [Fedora-packaging] Issue with PHP Naming guidelines In-Reply-To: References: <4A62008D.3070903@timj.co.uk> Message-ID: <4A62090E.9030308@timj.co.uk> On 18/07/09 18:06, Christopher Stone wrote: > I don't know if the guidelines would strictly allow for it, but it > seems php-Smug, php-Flickr would be an acceptable compromise. Maybe, but it makes it sound like the library is called "Flickr" rather than "phpFlickr". I wouldn't necessarily think that "php-Flickr" is the same thing as "phpFlickr". So I'd personally prefer the clumsier but more accurate php-phpFlickr. Tim From christoph.wickert at googlemail.com Sun Jul 19 11:15:13 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Sun, 19 Jul 2009 13:15:13 +0200 Subject: [Fedora-packaging] make install INSTALL="install -p" to guidelines In-Reply-To: <4A5BF5AE.4040008@freenet.de> References: <1247512398.2592.20.camel@localhost.localdomain> <4A5BF5AE.4040008@freenet.de> Message-ID: <1248002113.3720.31.camel@localhost> Am Dienstag, den 14.07.2009, 05:04 +0200 schrieb Ralf Corsepius: > Jussi Lehtola wrote: > > Hi, > > > > > > > > could somebody add a mention of adding INSTALL="install -p" to argument > > of 'make install' as a fix of preserving the time stamp during install > > to the packaging guidelines? > > > > http://fedoraproject.org/wiki/Packaging/Guidelines#Timestamps > > > > This really should be in the spec file templates as well, since it's > > such a common packaging bug (and shouldn't break anything either). > > Well, you are a new-comer to packaging, aren't you? > > Otherwise you'd likely know that "install -p" is highly controversal, > because it doesn't guarantee consistency of timestamps and is mostly > "eye-candy". I consider myself an old stager, nevertheless I hear this for the first time. Can you please tell me where this was discussed in the past? I couldn't find anything on fedora-devel or fedora-packaging. I think you tend to describe your POV as the only valid one - even on controversial topics. > Ralf Regards, Christoph From xjakub at fi.muni.cz Sun Jul 19 11:51:49 2009 From: xjakub at fi.muni.cz (Milos Jakubicek) Date: Sun, 19 Jul 2009 13:51:49 +0200 Subject: [Fedora-packaging] need help for a init script In-Reply-To: References: Message-ID: <4A6308D5.1090304@fi.muni.cz> Hi, On 15.7.2009 16:38, philippe makowski wrote: > start) > echo -n "Starting $FULLNAME " > daemon --user=$FBRunUser export FIREBIRD LD_LIBRARY_PATH;echo; > $MANAGER -pidfile $pidfile -start -forever > RETVAL=$? > [ $RETVAL -eq 0 ]&& touch /var/lock/subsys/$name > echo > ;; > > > but is seems that the OK come too fast, certainly after the "export" > not the "$MANAGER -pidfile $pidfile -start -forever" Yes, you have to quote the argument passed as the command to the daemon() function, otherwise it is currently interpreted as three separate commands: 1) daemon --user=$FBRunUser export FIREBIRD LD_LIBRARY_PATH; 2) echo; 3) $MANAGER -pidfile $pidfile -start -forever ...while you probably wanted: daemon --user=$FBRunUser "export FIREBIRD LD_LIBRARY_PATH;echo;$MANAGER -pidfile $pidfile -start -forever" (I also don't really understand the "echo;" part...wouldn't removing the "-n" parameter from the previous echo call do the same job? Just a side note...) Regards, Milos From jonathan.underwood at gmail.com Sun Jul 19 12:11:07 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 19 Jul 2009 13:11:07 +0100 Subject: [Fedora-packaging] Draft to prohibit use of #!/usr/bin/env In-Reply-To: <4A603C56.60303@gmail.com> References: <4A603C56.60303@gmail.com> Message-ID: <645d17210907190511v28e6a0a7p182dee2aee200ff7@mail.gmail.com> 2009/7/17 Toshio Kuratomi : > https://fedoraproject.org/wiki/Script_Interpreters_(draft) > > I've just submitted this draft. ?This seems to support the following This part: "Also, RPM does dependency additions based on script interpreter lines. If a script has #! /usr/bin/env python, the dependency added to the resulting rpm is on /usr/bin/env, not on the actual python interpreter. This may lead to incorrect dependencies, and broken scripts." really sounds like something that could/should be fixed up in rpm automatic dependency generator(s). From rc040203 at freenet.de Sun Jul 19 15:16:28 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 19 Jul 2009 17:16:28 +0200 Subject: [Fedora-packaging] make install INSTALL="install -p" to guidelines In-Reply-To: <1248002113.3720.31.camel@localhost> References: <1247512398.2592.20.camel@localhost.localdomain> <4A5BF5AE.4040008@freenet.de> <1248002113.3720.31.camel@localhost> Message-ID: <4A6338CC.7090102@freenet.de> On 07/19/2009 01:15 PM, Christoph Wickert wrote: > Am Dienstag, den 14.07.2009, 05:04 +0200 schrieb Ralf Corsepius: >> Jussi Lehtola wrote: >>> Hi, >>> >>> >>> >>> could somebody add a mention of adding INSTALL="install -p" to argument >>> of 'make install' as a fix of preserving the time stamp during install >>> to the packaging guidelines? >>> >>> http://fedoraproject.org/wiki/Packaging/Guidelines#Timestamps >>> >>> This really should be in the spec file templates as well, since it's >>> such a common packaging bug (and shouldn't break anything either). >> >> Well, you are a new-comer to packaging, aren't you? >> >> Otherwise you'd likely know that "install -p" is highly controversal, >> because it doesn't guarantee consistency of timestamps and is mostly >> "eye-candy". > > I consider myself an old stager, nevertheless I hear this for the first > time. Can you please tell me where this was discussed in the past? I > couldn't find anything on fedora-devel or fedora-packaging. Ohh, it has been discussed numerous times, so many times I don't have any particular reference to one of these. The points behind these discussions are: * People believe in "timestamps" matter for rpm. rpm doesn't and must not care about timestamps, otherwise share files between packages doesn't work. All "install -p" does in such situations is using different timestamps than when not using "install -p" - Many packages don't use "INSTALL" (automake generated Makefiles do) - Using INSTALL="install -p" basically is eye-candy, assuring timestamps on "non-generated installed files" match with those inside of the sources. On generated files (generated scripts, headers, compiled binaries/libraries ...) it doesn't have any impact. All "install -p" does in such situations is using different timestamps than when not using "install -p" - Many packages don't use "INSTALL" (automake generated Makefiles do), some use "INSTALL" in a completely different meaning. > I think you tend to describe your POV as the only valid one - even on > controversial topics. Well, I don't do so. I am saying "INSTALL=install -p" is stylishness and functionally mostly meaningless. Ralf From jkeating at j2solutions.net Sun Jul 19 15:28:54 2009 From: jkeating at j2solutions.net (Jesse Keating) Date: Sun, 19 Jul 2009 08:28:54 -0700 Subject: [Fedora-packaging] make install INSTALL="install -p" to guidelines In-Reply-To: <4A6338CC.7090102@freenet.de> References: <1247512398.2592.20.camel@localhost.localdomain> <4A5BF5AE.4040008@freenet.de> <1248002113.3720.31.camel@localhost> <4A6338CC.7090102@freenet.de> Message-ID: <1E4D06C2-CD57-4349-9C61-C73E6734E9BF@j2solutions.net> On Jul 19, 2009, at 8:16, Ralf Corsepius wrote: > On 07/19/2009 01:15 PM, Christoph Wickert wrote: >> Am Dienstag, den 14.07.2009, 05:04 +0200 schrieb Ralf Corsepius: >>> Jussi Lehtola wrote: >>>> Hi, >>>> >>>> >>>> >>>> could somebody add a mention of adding INSTALL="install -p" to >>>> argument >>>> of 'make install' as a fix of preserving the time stamp during >>>> install >>>> to the packaging guidelines? >>>> >>>> http://fedoraproject.org/wiki/Packaging/Guidelines#Timestamps >>>> >>>> This really should be in the spec file templates as well, since >>>> it's >>>> such a common packaging bug (and shouldn't break anything either). >>> >>> Well, you are a new-comer to packaging, aren't you? >>> >>> Otherwise you'd likely know that "install -p" is highly >>> controversal, >>> because it doesn't guarantee consistency of timestamps and is mostly >>> "eye-candy". >> >> I consider myself an old stager, nevertheless I hear this for the >> first >> time. Can you please tell me where this was discussed in the past? I >> couldn't find anything on fedora-devel or fedora-packaging. > Ohh, it has been discussed numerous times, so many times I don't > have any particular reference to one of these. > > The points behind these discussions are: > * People believe in "timestamps" matter for rpm. > rpm doesn't and must not care about timestamps, otherwise share > files between packages doesn't work. > > I thought timestamps mattered for multilib situations causing file conflicts. -- Jes From a.badger at gmail.com Sun Jul 19 15:42:15 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 19 Jul 2009 08:42:15 -0700 Subject: [Fedora-packaging] Draft to prohibit use of #!/usr/bin/env In-Reply-To: <645d17210907190511v28e6a0a7p182dee2aee200ff7@mail.gmail.com> References: <4A603C56.60303@gmail.com> <645d17210907190511v28e6a0a7p182dee2aee200ff7@mail.gmail.com> Message-ID: <4A633ED7.6050306@gmail.com> On 07/19/2009 05:11 AM, Jonathan Underwood wrote: > 2009/7/17 Toshio Kuratomi : >> https://fedoraproject.org/wiki/Script_Interpreters_(draft) >> >> I've just submitted this draft. This seems to support the following > > This part: > > "Also, RPM does dependency additions based on script interpreter > lines. If a script has #! /usr/bin/env python, the dependency added to > the resulting rpm is on /usr/bin/env, not on the actual python > interpreter. This may lead to incorrect dependencies, and broken > scripts." > > really sounds like something that could/should be fixed up in rpm > automatic dependency generator(s). > It's not easy to fix 100% correctly, though. #!/usr/bin/myinterp Argument Rpm can put a dependency on the file /usr/bin/myinterp. Pretty easy. #!/usr/bin/env myinterp Rpm can put a dependency on /usr/bin/env. Then it has to have a special case for /usr/bin/env that says look at the next argument and treat that as a dependency also. Then it has to resolve what myinterp is. The big thing there is that there's no guarantee that the building host has myinterp installed. Many scripting languages are fine if you use install (or cp) to install the script to the proper directory and don't need to have the interpreter installed until runtime. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From nicolas.mailhot at laposte.net Sun Jul 19 16:09:37 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 19 Jul 2009 18:09:37 +0200 Subject: [Fedora-packaging] make install INSTALL="install -p" to guidelines In-Reply-To: <4A6338CC.7090102@freenet.de> References: <1247512398.2592.20.camel@localhost.localdomain> <4A5BF5AE.4040008@freenet.de> <1248002113.3720.31.camel@localhost> <4A6338CC.7090102@freenet.de> Message-ID: <1248019777.11752.4.camel@arekh.okg> Le dimanche 19 juillet 2009 ? 17:16 +0200, Ralf Corsepius a ?crit : > All "install -p" does in such situations is using different timestamps > than when not using "install -p" Appart from the rpm aspects, it is very convenient when you need to debug a problem to be able to easily check which files changed latest? That does not work when rpms replace everything with the build farm creation time. You may agree that's just a convenience, but timestamps are everything about convenience, and no one ise seriously arguing to remove them. ? and git is a major PITA from this POW -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From rdieter at math.unl.edu Sun Jul 19 16:34:24 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 19 Jul 2009 11:34:24 -0500 Subject: [Fedora-packaging] make install INSTALL="install -p" to guidelines In-Reply-To: <1E4D06C2-CD57-4349-9C61-C73E6734E9BF@j2solutions.net> References: <1247512398.2592.20.camel@localhost.localdomain> <4A5BF5AE.4040008@freenet.de> <1248002113.3720.31.camel@localhost> <4A6338CC.7090102@freenet.de> <1E4D06C2-CD57-4349-9C61-C73E6734E9BF@j2solutions.net> Message-ID: <4A634B10.6030604@math.unl.edu> Jesse Keating wrote: > I thought timestamps mattered for multilib situations causing file > conflicts. Afair, timestamps did matter at one point in the past(?), but not anymore. (?) at which point that was addressed in rpm, I don't recall. -- Rex From giallu at gmail.com Sun Jul 19 17:18:13 2009 From: giallu at gmail.com (Gianluca Sforna) Date: Sun, 19 Jul 2009 19:18:13 +0200 Subject: [Fedora-packaging] Issue with PHP Naming guidelines In-Reply-To: <4A62090E.9030308@timj.co.uk> References: <4A62008D.3070903@timj.co.uk> <4A62090E.9030308@timj.co.uk> Message-ID: On Sat, Jul 18, 2009 at 7:40 PM, Tim Jackson wrote: > Maybe, but it makes it sound like the library is called "Flickr" rather than > "phpFlickr". I wouldn't necessarily think that "php-Flickr" is the same > thing as "phpFlickr". So I'd personally prefer the clumsier but more > accurate php-phpFlickr. What about adding an exception for the "add the php- prefix" rule to packages that includes "php in their name? Pyhton has something similar: If the upstream source has "py" (or "Py") in its name, you can use that name for the package. So, for example, pygtk is acceptable. -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna From a.badger at gmail.com Sun Jul 19 17:25:33 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 19 Jul 2009 10:25:33 -0700 Subject: [Fedora-packaging] Issue with PHP Naming guidelines In-Reply-To: References: <4A62008D.3070903@timj.co.uk> <4A62090E.9030308@timj.co.uk> Message-ID: <4A63570D.10202@gmail.com> On 07/19/2009 10:18 AM, Gianluca Sforna wrote: > On Sat, Jul 18, 2009 at 7:40 PM, Tim Jackson wrote: >> Maybe, but it makes it sound like the library is called "Flickr" rather than >> "phpFlickr". I wouldn't necessarily think that "php-Flickr" is the same >> thing as "phpFlickr". So I'd personally prefer the clumsier but more >> accurate php-phpFlickr. > > What about adding an exception for the "add the php- prefix" rule to > packages that includes "php in their name? > > Pyhton has something similar: > If the upstream source has "py" (or "Py") in its name, you can use > that name for the package. So, for example, pygtk is acceptable. > That's possible. OTOH, I personally have argued for removing that from the python Guidelines (old package grandfathered in, new packages needing to be python-pygtk, for example). -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From chris.stone at gmail.com Sun Jul 19 19:17:36 2009 From: chris.stone at gmail.com (Christopher Stone) Date: Sun, 19 Jul 2009 12:17:36 -0700 Subject: [Fedora-packaging] Issue with PHP Naming guidelines In-Reply-To: References: <4A62008D.3070903@timj.co.uk> <4A62090E.9030308@timj.co.uk> Message-ID: On Sun, Jul 19, 2009 at 10:18 AM, Gianluca Sforna wrote: > What about adding an exception for the "add the php- prefix" rule ?to > packages that includes "php in their name? So, a package called "graphplotter" would be valid because it has php it its name? From nicolas.mailhot at laposte.net Sun Jul 19 19:31:10 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 19 Jul 2009 21:31:10 +0200 Subject: [Fedora-packaging] Issue with PHP Naming guidelines In-Reply-To: References: <4A62008D.3070903@timj.co.uk> <4A62090E.9030308@timj.co.uk> Message-ID: <1248031870.11446.9.camel@arekh.okg> Le dimanche 19 juillet 2009 ? 12:17 -0700, Christopher Stone a ?crit : > On Sun, Jul 19, 2009 at 10:18 AM, Gianluca Sforna wrote: > > What about adding an exception for the "add the php- prefix" rule to > > packages that includes "php in their name? > > So, a package called "graphplotter" would be valid because it has php > it its name? The way we do it with fonts is that we require the -fonts suffix but forbid repetition in the root name So you can not have bigfonts-foofont, bigfoofont-fonts or fontofbigfoo-fonts but only big-foo-fonts. Also we require lowercase names and use - as word separator (like other sensible distros such as Debian or Suse who didn't let their package namespace polluted by WeirdCamelCaseNames). Arguably, the decision was easier to make since font authors do not follow any particular logic in naming their archives and a typical font includes many layers of naming that usually do not agree on case and separators. Anyway, that was mainly to dispell the impression our naming conventions are consistent accross sigs. Every SIG makes its own rules and as long as they are internally consistent (all packages of the same kind are named the same way) no one cares much. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jonathan.underwood at gmail.com Mon Jul 20 13:26:33 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 20 Jul 2009 14:26:33 +0100 Subject: [Fedora-packaging] make install INSTALL="install -p" to guidelines In-Reply-To: <4A6338CC.7090102@freenet.de> References: <1247512398.2592.20.camel@localhost.localdomain> <4A5BF5AE.4040008@freenet.de> <1248002113.3720.31.camel@localhost> <4A6338CC.7090102@freenet.de> Message-ID: <645d17210907200626o3808362ax9c833f57ff0b8b9e@mail.gmail.com> 2009/7/19 Ralf Corsepius : > - Using INSTALL="install -p" basically is eye-candy, assuring timestamps on > "non-generated installed files" match with those inside of the sources. On > generated files (generated scripts, headers, compiled binaries/libraries > ...) it doesn't have any impact. > All "install -p" does in such situations is using different timestamps than > when not using "install -p" I don't have an opinion on whether INSTALL="install -p" should be universal, but to give a concrete example of when it is needed: When building emacs add ons, it's necessary to install the byte compiled (*.elc) files with -p so that when both the uncompiled (*.el)and byte compiled files are installed emacs will read the byte compiled sources - emacs looks at the timestamps of both the el and elc and loads the elc if it's mtime is later than the .el. Not using -p often results in emacs disregarding the elc file if the el source file is installed, negating the usefulness of byte compilation. From jonathan.underwood at gmail.com Mon Jul 20 13:28:41 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 20 Jul 2009 14:28:41 +0100 Subject: [Fedora-packaging] make install INSTALL="install -p" to guidelines In-Reply-To: <645d17210907200626o3808362ax9c833f57ff0b8b9e@mail.gmail.com> References: <1247512398.2592.20.camel@localhost.localdomain> <4A5BF5AE.4040008@freenet.de> <1248002113.3720.31.camel@localhost> <4A6338CC.7090102@freenet.de> <645d17210907200626o3808362ax9c833f57ff0b8b9e@mail.gmail.com> Message-ID: <645d17210907200628uf36bbd5x148e316d653698e8@mail.gmail.com> 2009/7/20 Jonathan Underwood : > When building emacs add ons, it's necessary to install the byte > compiled (*.elc) files with -p so that when both the uncompiled > (*.el)and byte compiled files are installed emacs will read the byte > compiled sources - emacs looks at the timestamps of both the el and > elc and loads the elc if it's mtime is later than the .el. Not using > -p often results in emacs disregarding the elc file if the el source > file is installed, negating the usefulness of byte compilation. > Um, sorry, I got that backwards - the non byte compiled .el files need to be installed with -p, sorry. But you get the point. From rc040203 at freenet.de Mon Jul 20 14:19:46 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 20 Jul 2009 16:19:46 +0200 Subject: [Fedora-packaging] make install INSTALL="install -p" to guidelines In-Reply-To: <645d17210907200628uf36bbd5x148e316d653698e8@mail.gmail.com> References: <1247512398.2592.20.camel@localhost.localdomain> <4A5BF5AE.4040008@freenet.de> <1248002113.3720.31.camel@localhost> <4A6338CC.7090102@freenet.de> <645d17210907200626o3808362ax9c833f57ff0b8b9e@mail.gmail.com> <645d17210907200628uf36bbd5x148e316d653698e8@mail.gmail.com> Message-ID: <4A647D02.9030003@freenet.de> On 07/20/2009 03:28 PM, Jonathan Underwood wrote: > 2009/7/20 Jonathan Underwood: >> When building emacs add ons, it's necessary to install the byte >> compiled (*.elc) files with -p so that when both the uncompiled >> (*.el)and byte compiled files are installed emacs will read the byte >> compiled sources - emacs looks at the timestamps of both the el and >> elc and loads the elc if it's mtime is later than the .el. Not using >> -p often results in emacs disregarding the elc file if the el source >> file is installed, negating the usefulness of byte compilation. >> > > Um, sorry, I got that backwards - the non byte compiled .el files need > to be installed with -p, sorry. But you get the point. Firstly, I don't deny that there are (very few) special cases in which INSTALL="install -p" might be necessary to work-around particular issues with certain packages (IIRC, some java packages have a similar problem). However, it's equally easy to produce examples, in which INSTALL="install -p" has harmful effects. That said, to me, INSTALL="install -p" is just a special case of environment variables, similar to many other special environment variables needed by certain packages. Ralf [I for one would read your issue's description as an upstream bug. If they have special demands on timestamps, they need to take care about it.] From eric.tanguy at univ-nantes.fr Mon Jul 20 16:55:51 2009 From: eric.tanguy at univ-nantes.fr (Eric Tanguy) Date: Mon, 20 Jul 2009 18:55:51 +0200 Subject: [Fedora-packaging] touch Message-ID: <4A64A197.2000401@univ-nantes.fr> I need to touch a file in spec file. I think the better place is at the end of %prep ? I need to BR something special for this ? Is it ok to do this ? Thanks Eric From rc040203 at freenet.de Mon Jul 20 17:07:18 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 20 Jul 2009 19:07:18 +0200 Subject: [Fedora-packaging] touch In-Reply-To: <4A64A197.2000401@univ-nantes.fr> References: <4A64A197.2000401@univ-nantes.fr> Message-ID: <4A64A446.3000808@freenet.de> On 07/20/2009 06:55 PM, Eric Tanguy wrote: > I need to touch a file in spec file. I think the better place is at the > end of %prep ? Depends on what you actually are doing. "touch" may serve for different purposes. > I need to BR something special for this ? No, touch is part of coreutils, which can safely be assumed to be present. > Is it ok to do this ? Again, depends on what you intend to do. Ralf From bruno at wolff.to Mon Jul 20 17:10:18 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 20 Jul 2009 12:10:18 -0500 Subject: [Fedora-packaging] touch In-Reply-To: <4A64A197.2000401@univ-nantes.fr> References: <4A64A197.2000401@univ-nantes.fr> Message-ID: <20090720171018.GA13077@wolff.to> On Mon, Jul 20, 2009 at 18:55:51 +0200, Eric Tanguy wrote: > I need to touch a file in spec file. I think the better place is at the > end of %prep ? > I need to BR something special for this ? > Is it ok to do this ? "touch" is in coreutils which doesn't need to be BR'd. See: http://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions_2 From eric.tanguy at univ-nantes.fr Mon Jul 20 18:28:24 2009 From: eric.tanguy at univ-nantes.fr (Eric Tanguy) Date: Mon, 20 Jul 2009 20:28:24 +0200 Subject: [Fedora-packaging] touch In-Reply-To: <4A64A446.3000808@freenet.de> References: <4A64A197.2000401@univ-nantes.fr> <4A64A446.3000808@freenet.de> Message-ID: <4A64B748.9030206@univ-nantes.fr> Le 20/07/2009 19:07, Ralf Corsepius a ?crit : > On 07/20/2009 06:55 PM, Eric Tanguy wrote: >> I need to touch a file in spec file. I think the better place is at the >> end of %prep ? > Depends on what you actually are doing. > "touch" may serve for different purposes. I need to touch the configuration file for Qt Assistant in a manual package to make Assistant update the cache during an update. You can follow the discussion upstream : https://sourceforge.net/forum/forum.php?thread_id=3333352&forum_id=708156 > >> I need to BR something special for this ? > No, touch is part of coreutils, which can safely be assumed to be > present. > >> Is it ok to do this ? > Again, depends on what you intend to do. > > Ralf > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging From bruno at wolff.to Tue Jul 21 13:28:33 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Tue, 21 Jul 2009 08:28:33 -0500 Subject: [Fedora-packaging] touch In-Reply-To: <4A64B748.9030206@univ-nantes.fr> References: <4A64A197.2000401@univ-nantes.fr> <4A64A446.3000808@freenet.de> <4A64B748.9030206@univ-nantes.fr> Message-ID: <20090721132833.GA1193@wolff.to> On Mon, Jul 20, 2009 at 20:28:24 +0200, Eric Tanguy wrote: > Le 20/07/2009 19:07, Ralf Corsepius a ?crit : >> On 07/20/2009 06:55 PM, Eric Tanguy wrote: >>> I need to touch a file in spec file. I think the better place is at the >>> end of %prep ? >> Depends on what you actually are doing. >> "touch" may serve for different purposes. > I need to touch the configuration file for Qt Assistant in a manual > package to make Assistant update the cache during an update. You can > follow the discussion upstream : > https://sourceforge.net/forum/forum.php?thread_id=3333352&forum_id=708156 If the touch needs to happen when the update is applied, then it probably needs to be in post (and maybe postun as well). And for stuff done in post and postun you can't assume coreutils and will need to add appropriate requires. Requires(post): coreutils Requires(postun): coreutils From eric.tanguy at univ-nantes.fr Wed Jul 22 06:22:49 2009 From: eric.tanguy at univ-nantes.fr (Eric Tanguy) Date: Wed, 22 Jul 2009 08:22:49 +0200 Subject: [Fedora-packaging] .desktop file Message-ID: <4A66B039.6070702@univ-nantes.fr> Is it possible to indicate a category for KDE and another one for all the other WM ? Thanks From braden at endoframe.com Wed Jul 22 06:54:25 2009 From: braden at endoframe.com (Braden McDaniel) Date: Wed, 22 Jul 2009 02:54:25 -0400 Subject: [Fedora-packaging] Draft to prohibit use of #!/usr/bin/env In-Reply-To: <4A603C56.60303@gmail.com> References: <4A603C56.60303@gmail.com> Message-ID: <1248245665.4653.10480.camel@localhost> On Fri, 2009-07-17 at 01:54 -0700, Toshio Kuratomi wrote: > https://fedoraproject.org/wiki/Script_Interpreters_(draft) > > I've just submitted this draft. This seems to support the following > feature which I need to find the owner of and coordinate with: The problem I see with this is that it's bound to result in patches that some upstream developers will find unpalatable. Can non-Fedora-specific arguments be made against this practice *that are sufficiently compelling to justify the potential for long-term maintenance of patches*? I say, "non-Fedora-specific" because this is a lot more compelling if the project can say, unequivocally, that Fedora is taking a stand against a generally harmful practice. If, however, the reasons driving this are mostly Fedora-specific, it's a harder sell. Broadly speaking, a distribution like Fedora should be doing its best to adapt to what upstream developers deliver. -- Braden McDaniel From rc040203 at freenet.de Wed Jul 22 07:25:35 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 22 Jul 2009 09:25:35 +0200 Subject: [Fedora-packaging] Draft to prohibit use of #!/usr/bin/env In-Reply-To: <1248245665.4653.10480.camel@localhost> References: <4A603C56.60303@gmail.com> <1248245665.4653.10480.camel@localhost> Message-ID: <4A66BEEF.3010108@freenet.de> On 07/22/2009 08:54 AM, Braden McDaniel wrote: > On Fri, 2009-07-17 at 01:54 -0700, Toshio Kuratomi wrote: >> https://fedoraproject.org/wiki/Script_Interpreters_(draft) >> >> I've just submitted this draft. This seems to support the following >> feature which I need to find the owner of and coordinate with: > > The problem I see with this is that it's bound to result in patches that > some upstream developers will find unpalatable. Can non-Fedora-specific > arguments be made against this practice *that are sufficiently > compelling to justify the potential for long-term maintenance of > patches*? Well, the primary reason for using #!/usr/bin/env is script-portability to support cases, in which using a hard-coded interpreter is not feasible. Such cases typically are a) there is no "standardized location" for an interpreter. e.g. though presuming presence of /bin/bash is pretty safe on Linuxes, there is no "standardized location" for bash on "non" Linuxes. b) /usr/bin/env is handy for cases in which not using the "standard interpreter" is not desired. Examples would be - testing/development purposes (e.g. when developing on such an interpreter, e.g. a new bash) - testsuites to be run inside of a package. They typically want to use the newly built interpreter and do not the system-wide version. As b) is suiteable for distribution and development purposes, it is a pretty compelling approach to keep a package simple on the developer's part. > I say, "non-Fedora-specific" because this is a lot more compelling if > the project can say, unequivocally, that Fedora is taking a stand > against a generally harmful practice. If, however, the reasons driving > this are mostly Fedora-specific, it's a harder sell. Broadly speaking, > a distribution like Fedora should be doing its best to adapt to what > upstream developers deliver. IMO, /usr/bin/env is not necessarily harmful. It may cause undesired side-effects if being carelessly used. That said, my attitude on this is ambivalent and I am not convinced, banning /usr/bin/env is a good idea. One one hand, banning /usr/bin/env restricts the distro and helps assuring consistency withing the distro, on the other hand, it restricts usability of distro (for development purposes) and forces either developers or packagers to _generating_ scripts. Ralf From jussilehtola at fedoraproject.org Wed Jul 22 08:37:53 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Wed, 22 Jul 2009 11:37:53 +0300 Subject: [Fedora-packaging] Draft for the use of environment-modules Message-ID: <1248251873.18128.7.camel@hawking.theorphys.helsinki.fi> Hi, I have worked out a rough draft for the use of environment-modules instead of alternatives. Feel free to comment or modify it. I'd also like to suggest a feature that all MPI compilers/libraries use solely environment-modules (no alternatives support). Currently, the only MPI compiler in Fedora that still uses alternatives is mpich2. https://fedoraproject.org/wiki/PackagingDrafts/EnvironmentModules -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From rdieter at math.unl.edu Wed Jul 22 12:30:10 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 22 Jul 2009 07:30:10 -0500 Subject: [Fedora-packaging] .desktop file In-Reply-To: <4A66B039.6070702@univ-nantes.fr> References: <4A66B039.6070702@univ-nantes.fr> Message-ID: <4A670652.2000901@math.unl.edu> Eric Tanguy wrote: > Is it possible to indicate a category for KDE and another one for all > the other WM ? Yes, using 2 .desktop files, but... why? -- Rex From eric.tanguy at univ-nantes.fr Wed Jul 22 12:52:27 2009 From: eric.tanguy at univ-nantes.fr (Eric Tanguy) Date: Wed, 22 Jul 2009 14:52:27 +0200 Subject: [Fedora-packaging] .desktop file In-Reply-To: <4A670652.2000901@math.unl.edu> References: <4A66B039.6070702@univ-nantes.fr> <4A670652.2000901@math.unl.edu> Message-ID: <4A670B8B.9030906@univ-nantes.fr> Le 22/07/2009 14:30, Rex Dieter a ?crit : > Eric Tanguy wrote: >> Is it possible to indicate a category for KDE and another one for all >> the other WM ? > > Yes, using 2 .desktop files, but... why? > > -- Rex > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging I think i find a solution without this. You can follow the discussion : https://bugzilla.redhat.com/show_bug.cgi?id=510968#c5 Eric From xjakub at fi.muni.cz Wed Jul 22 14:10:22 2009 From: xjakub at fi.muni.cz (Milos Jakubicek) Date: Wed, 22 Jul 2009 16:10:22 +0200 Subject: [Fedora-packaging] Draft for the use of environment-modules In-Reply-To: <1248251873.18128.7.camel@hawking.theorphys.helsinki.fi> References: <1248251873.18128.7.camel@hawking.theorphys.helsinki.fi> Message-ID: <4A671DCE.1080909@fi.muni.cz> On 22.7.2009 10:37, Jussi Lehtola wrote: > Hi, > > > I have worked out a rough draft for the use of environment-modules > instead of alternatives. Feel free to comment or modify it. > > I'd also like to suggest a feature that all MPI compilers/libraries use > solely environment-modules (no alternatives support). Currently, the > only MPI compiler in Fedora that still uses alternatives is mpich2. > > https://fedoraproject.org/wiki/PackagingDrafts/EnvironmentModules +1 for the proposal as well as for the suggestion regarding MPI compilers. I'm currently working on orsa to use the MPI via environment-modules, the way OpenMPI is currently packaged is just fine and it would be great if packages of other MPI implementations would follow it. Thanks for writing this up, Milos From a.badger at gmail.com Wed Jul 22 15:44:43 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 22 Jul 2009 08:44:43 -0700 Subject: [Fedora-packaging] Draft to prohibit use of #!/usr/bin/env In-Reply-To: <1248245665.4653.10480.camel@localhost> References: <4A603C56.60303@gmail.com> <1248245665.4653.10480.camel@localhost> Message-ID: <4A6733EB.7010503@gmail.com> On 07/21/2009 11:54 PM, Braden McDaniel wrote: > On Fri, 2009-07-17 at 01:54 -0700, Toshio Kuratomi wrote: >> https://fedoraproject.org/wiki/Script_Interpreters_(draft) >> >> I've just submitted this draft. This seems to support the following >> feature which I need to find the owner of and coordinate with: > > The problem I see with this is that it's bound to result in patches that > some upstream developers will find unpalatable. Can non-Fedora-specific > arguments be made against this practice *that are sufficiently > compelling to justify the potential for long-term maintenance of > patches*? > > I say, "non-Fedora-specific" because this is a lot more compelling if > the project can say, unequivocally, that Fedora is taking a stand > against a generally harmful practice. If, however, the reasons driving > this are mostly Fedora-specific, it's a harder sell. Broadly speaking, > a distribution like Fedora should be doing its best to adapt to what > upstream developers deliver. > I see this falling into two cases: 1) /usr/bin/env was cut and pasted into the script by upstream without understanding what the tradeoffs are with /usr/bin/INTERPRETER. In these cases, upstream may be willing to accept a patch to use /usr/bin/INTERPRETER when we explain that some system administrators install multiple versions of the INTERPRETER on a system in different directories and rely on their path to sort things out for their site-local scripts. 2) /usr/bin/env is being used upstream purposefully. This would be when the upstream is trying to work in situations where INTERPRETER isn't installed in /usr/bin/INTERPRETER and they are not concerned by multiple versions of the INTERPRETER conflicting. This is a case where I think it is appropriate for Fedora to carry a Fedora-specific patch. Reasoning: Upstream and Fedora have different aims in this case. Upstream is trying to ensure that their script runs on as many different operating systems as possible. Fedora is trying to ensure that the script runs on Fedora systems even if local admins have installed extra interpreter versins. /usr/bin/env supports upstream's case but breaks the Fedora case. So this is something that we should be changing locally as it makes the scripts more robust on Fedora and the change is reasonably simple - change the first line of executable files. A solution that would meet both upstream and Fedora's usage would be to change the build scripts of the packages to substitute the interpreter lines in at build time. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From jussilehtola at fedoraproject.org Wed Jul 22 15:51:07 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Wed, 22 Jul 2009 18:51:07 +0300 Subject: [Fedora-packaging] Draft for the use of environment-modules In-Reply-To: <4A671DCE.1080909@fi.muni.cz> References: <1248251873.18128.7.camel@hawking.theorphys.helsinki.fi> <4A671DCE.1080909@fi.muni.cz> Message-ID: <1248277867.12023.24.camel@hawking.theorphys.helsinki.fi> On Wed, 2009-07-22 at 16:10 +0200, Milos Jakubicek wrote: > On 22.7.2009 10:37, Jussi Lehtola wrote: > > Hi, > > > > > > I have worked out a rough draft for the use of environment-modules > > instead of alternatives. Feel free to comment or modify it. > > > > I'd also like to suggest a feature that all MPI compilers/libraries use > > solely environment-modules (no alternatives support). Currently, the > > only MPI compiler in Fedora that still uses alternatives is mpich2. > > > > https://fedoraproject.org/wiki/PackagingDrafts/EnvironmentModules > > +1 for the proposal as well as for the suggestion regarding MPI > compilers. I'm currently working on orsa to use the MPI via > environment-modules, the way OpenMPI is currently packaged is just fine > and it would be great if packages of other MPI implementations would > follow it. Maybe we should also discuss about the way MPI programs are packaged. Some possible options: 1. Package only using preferred Fedora compiler (OpenMPI at the moment) 2. Package at least using preferred Fedora compiler (OpenMPI), packages for other compilers is up to the packager 3. Make packages for every MPI compiler in the distribution. I'm leaning towards 2 (or maybe 3). This requires, however, some standard on naming. Often parallelized software can also be compiled in serial mode. My suggestion for the naming would be foo - serial program foo_mpi (or foo_ompi, or foo_openmpi) - parallel, OpenMPI foo_mpich2 - parallel, mpich2 foo_lam - parallel, LAM (has been obsoleted for years but still available in Fedora) foo_mvapich - parallel, MVAPICH (not yet in Fedora) foo_mvapich2 - parallel, MVAPICH (not yet in Fedora) -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From mclasen at redhat.com Wed Jul 22 15:53:14 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 22 Jul 2009 11:53:14 -0400 Subject: [Fedora-packaging] Draft to prohibit use of #!/usr/bin/env In-Reply-To: <4A66BEEF.3010108@freenet.de> References: <4A603C56.60303@gmail.com> <1248245665.4653.10480.camel@localhost> <4A66BEEF.3010108@freenet.de> Message-ID: <1248277994.1693.4.camel@planemask> On Wed, 2009-07-22 at 09:25 +0200, Ralf Corsepius wrote: > > That said, my attitude on this is ambivalent and I am not convinced, > banning /usr/bin/env is a good idea. > I'm not strongly convinced either. However, if we decide not to ban it, we should make find-requires smart enough to recognize that #!/usr/bin/env python indicates a Python script. I just tracked down some missing deps due to that ... Matthias From jussilehtola at fedoraproject.org Wed Jul 22 16:37:10 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Wed, 22 Jul 2009 19:37:10 +0300 Subject: [Fedora-packaging] Draft for the use of environment-modules In-Reply-To: <1248277867.12023.24.camel@hawking.theorphys.helsinki.fi> References: <1248251873.18128.7.camel@hawking.theorphys.helsinki.fi> <4A671DCE.1080909@fi.muni.cz> <1248277867.12023.24.camel@hawking.theorphys.helsinki.fi> Message-ID: <1248280630.12023.28.camel@hawking.theorphys.helsinki.fi> On Wed, 2009-07-22 at 18:51 +0300, Jussi Lehtola wrote: > On Wed, 2009-07-22 at 16:10 +0200, Milos Jakubicek wrote: > > +1 for the proposal as well as for the suggestion regarding MPI > > compilers. I'm currently working on orsa to use the MPI via > > environment-modules, the way OpenMPI is currently packaged is just fine > > and it would be great if packages of other MPI implementations would > > follow it. > > Maybe we should also discuss about the way MPI programs are packaged. > Some possible options: Actually, I wrote a draft for this as well. Please have a look at https://fedoraproject.org/wiki/PackagingDrafts/MPI -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From xjakub at fi.muni.cz Thu Jul 23 21:56:04 2009 From: xjakub at fi.muni.cz (Milos Jakubicek) Date: Thu, 23 Jul 2009 23:56:04 +0200 Subject: [Fedora-packaging] Draft for the use of environment-modules In-Reply-To: <1248280630.12023.28.camel@hawking.theorphys.helsinki.fi> References: <1248251873.18128.7.camel@hawking.theorphys.helsinki.fi> <4A671DCE.1080909@fi.muni.cz> <1248277867.12023.24.camel@hawking.theorphys.helsinki.fi> <1248280630.12023.28.camel@hawking.theorphys.helsinki.fi> Message-ID: <4A68DC74.8020605@fi.muni.cz> On 22.7.2009 18:37, Jussi Lehtola wrote: >> >> Maybe we should also discuss about the way MPI programs are packaged. >> Some possible options: > > Actually, I wrote a draft for this as well. Please have a look at > https://fedoraproject.org/wiki/PackagingDrafts/MPI Well done, I think you could take also some inspiration from hints made by Doug Ledford in BZ#511099: - what about making the $MPI_HOME, $MPI_BIN and $MPI_LIB variables a MUST? - we should make the sample of specfile from the BZ#511099 part of the draft Some other things that come to my mind: - the libraries must have the suffix OR they could be installed under %{_libdir}/%{name}/%{version}-/lib (i.e. there should similar two choices as for the binaries) - each MPI build of shared libraries should have a separate -devel subpackage (having them in a single -devel subpackage would need a require of all MPI builds for it, which is imho not good) - the main package should be always built without MPI support, if that is possible (i.e. a MUST would be: build at least without MPI (if possible) and with OpenMPI) I'm also CCing Deji Akingunola and Doug Ledford who are the maintainers of MPI compilers currently available in Fedora, not sure whether they follow this discussion, but they definitely should. Regards, Milos From kevin at tummy.com Thu Jul 23 22:04:53 2009 From: kevin at tummy.com (Kevin Fenzi) Date: Thu, 23 Jul 2009 16:04:53 -0600 Subject: [Fedora-packaging] Draft for the use of environment-modules In-Reply-To: <1248251873.18128.7.camel@hawking.theorphys.helsinki.fi> References: <1248251873.18128.7.camel@hawking.theorphys.helsinki.fi> Message-ID: <20090723160453.5ca5c21d@ohm.scrye.com> On Wed, 22 Jul 2009 11:37:53 +0300 Jussi Lehtola wrote: > Hi, > > > I have worked out a rough draft for the use of environment-modules > instead of alternatives. Feel free to comment or modify it. > > I'd also like to suggest a feature that all MPI compilers/libraries > use solely environment-modules (no alternatives support). Currently, > the only MPI compiler in Fedora that still uses alternatives is > mpich2. > > https://fedoraproject.org/wiki/PackagingDrafts/EnvironmentModules This looks pretty good to me. Thanks for writing this up! kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From braden at endoframe.com Fri Jul 24 05:58:14 2009 From: braden at endoframe.com (Braden McDaniel) Date: Fri, 24 Jul 2009 01:58:14 -0400 Subject: [Fedora-packaging] Draft to prohibit use of #!/usr/bin/env In-Reply-To: <4A6733EB.7010503@gmail.com> References: <4A603C56.60303@gmail.com> <1248245665.4653.10480.camel@localhost> <4A6733EB.7010503@gmail.com> Message-ID: <1248415094.4404.164.camel@localhost> On Wed, 2009-07-22 at 08:44 -0700, Toshio Kuratomi wrote: [snip] > A solution that would meet both upstream and Fedora's usage would be to > change the build scripts of the packages to substitute the interpreter > lines in at build time. This suggestion really goes to the heart of what makes me uncomfortable with your proposal: it comes down to asking packages to do something special for Fedora. And the most compelling reason for this request appears to be that Fedora's toolchain can't cope. The philosophical direction this seems to represent is not one I'd like to see Fedora take. -- Braden McDaniel From a.badger at gmail.com Fri Jul 24 06:20:50 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 23 Jul 2009 23:20:50 -0700 Subject: [Fedora-packaging] Draft to prohibit use of #!/usr/bin/env In-Reply-To: <1248415094.4404.164.camel@localhost> References: <4A603C56.60303@gmail.com> <1248245665.4653.10480.camel@localhost> <4A6733EB.7010503@gmail.com> <1248415094.4404.164.camel@localhost> Message-ID: <4A6952C2.7070904@gmail.com> On 07/23/2009 10:58 PM, Braden McDaniel wrote: > On Wed, 2009-07-22 at 08:44 -0700, Toshio Kuratomi wrote: > > [snip] > >> A solution that would meet both upstream and Fedora's usage would be to >> change the build scripts of the packages to substitute the interpreter >> lines in at build time. > > This suggestion really goes to the heart of what makes me uncomfortable > with your proposal: it comes down to asking packages to do something > special for Fedora. And the most compelling reason for this request > appears to be that Fedora's toolchain can't cope. The philosophical > direction this seems to represent is not one I'd like to see Fedora > take. > The toolchain is only a minor point. The major point is that it causes breakage for some end users. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From dledford at redhat.com Fri Jul 24 12:46:00 2009 From: dledford at redhat.com (Doug Ledford) Date: Fri, 24 Jul 2009 08:46:00 -0400 Subject: [Fedora-packaging] Draft for the use of environment-modules In-Reply-To: <4A68DC74.8020605@fi.muni.cz> References: <1248251873.18128.7.camel@hawking.theorphys.helsinki.fi> <4A671DCE.1080909@fi.muni.cz> <1248277867.12023.24.camel@hawking.theorphys.helsinki.fi> <1248280630.12023.28.camel@hawking.theorphys.helsinki.fi> <4A68DC74.8020605@fi.muni.cz> Message-ID: On Jul 23, 2009, at 5:56 PM, Milos Jakubicek wrote: > On 22.7.2009 18:37, Jussi Lehtola wrote: >>> >>> Maybe we should also discuss about the way MPI programs are >>> packaged. >>> Some possible options: >> >> Actually, I wrote a draft for this as well. Please have a look at >> https://fedoraproject.org/wiki/PackagingDrafts/MPI > > Well done, I think you could take also some inspiration from hints > made by Doug Ledford in BZ#511099: > > - what about making the $MPI_HOME, $MPI_BIN and $MPI_LIB variables a > MUST? I would strongly support this. > - we should make the sample of specfile from the BZ#511099 part of > the draft > > Some other things that come to my mind: > > - the libraries must have the suffix OR they could be installed > under %{_libdir}/%{name}/%{version}-/lib (i.e. there > should similar two choices as for the binaries) I would say the libraries MUST be installed under $MPI_LIB and any resulting binaries MUST be installed under $MPI_BIN. This makes is so that loading the MPI environment module automatically gets you all the associated binaries and libraries needed. > - each MPI build of shared libraries should have a separate -devel > subpackage (having them in a single -devel subpackage would need a > require of all MPI builds for it, which is imho not good) This is probably good, and would need to be under $MPI_INCLUDE maybe? It might be worth while to consider simply making it a rule that the following directories always exist: $MPI_HOME/bin $MPI_HOME/lib $MPI_HOME/include $MPI_HOME/man and that they are the standard destination for MPI built programs. The man directory is somewhat optional as man pages should be able to go in /usr/share/man and simply be reused from the base package, they don't normally vary from a non-MPI build to an MPI build. However, the man dir is needed for the MPI packages themselves as they all have rather extensive, competing man pages. > - the main package should be always built without MPI support, if > that is possible (i.e. a MUST would be: build at least without MPI > (if possible) and with OpenMPI) You can't do a must as there are some MPI only apps out there (mpitests is an easy example). But a strong should would work. > I'm also CCing Deji Akingunola and Doug Ledford who are the > maintainers of MPI compilers currently available in Fedora, not sure > whether they follow this discussion, but they definitely should. So, as per our conversation in IRC, here's the directory struction I would recommend. This is brought out by the fact that the current MPI directory structure I'm using seriously abuses %{_libdir} by putting way too much stuff under there. We don't really want to use /opt (even though that's really the perfect place for this) because of the whole issue of wanting this to be able to be mounted as a read only network filesystem and putting it in /opt adds a new mount point (and also adds complexity to drive partitioning issues). So, keeping it under /usr would seem to be a very important goal. However, we have binaries, man pages, libraries, include files, and now we are talking about other packages tossing their stuff under these directories too. That is a rather excessive abuse of %{_libdir}. The FHS doesn't really have an option to cover this. At all. I don't think we can accomplish what needs done while adhering strictly to the FHS. So, I think there are two options: 1) Create a suitable MPI_HOME that can hold the entire bunch of stuff from a given MPI package (maybe something like /usr/opt, /usr/local/ mpi, or /usr/mpi) and under that top level directory install the multiple mpi packages and also allow for the installation of mpi linked libraries and binaries. 2) Try to split things up into normal FHS locations, but don't use binary name suffixes or library name suffixes in the normal directories, instead use things like /bin/%{name}-%{_arch}%{? opt_cc_suffix}, %{_libdir}/%{name}%{?opt_cc_suffix}, %{_includedir}/% {name}-%{_arch}%{?opt_cc_suffix}, %{_datadir}/%{name}-%{_arch}%{? opt_cc_suffix}, %{_datadir}/%{name}-%{_arch}%{?opt_cc_suffix}/man. While the above is somewhat clumsy, and also eliminates the possibility of MPI_HOME being useful as we would now need independent definitions of all the various MPI locations, it does have the benefit of being mostly FHS compliant. Regardless of which way people would prefer to go, I do think we should go ahead and standardize all the config files in %{_sysconfdir}/ %{name}-%{_arch}%{?opt_cc_suffix} so that they won't possibly be on a read only filesystem. Thoughts? If we can get this standard more or less agree on, I'll get the F-11 and devel packages of both lam and openmpi updated the same day. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford InfiniBand Specific RPMS http://people.redhat.com/dledford/Infiniband -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 203 bytes Desc: This is a digitally signed message part URL: From jussilehtola at fedoraproject.org Fri Jul 24 13:17:52 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Fri, 24 Jul 2009 16:17:52 +0300 Subject: [Fedora-packaging] Draft for the use of environment-modules In-Reply-To: References: <1248251873.18128.7.camel@hawking.theorphys.helsinki.fi> <4A671DCE.1080909@fi.muni.cz> <1248277867.12023.24.camel@hawking.theorphys.helsinki.fi> <1248280630.12023.28.camel@hawking.theorphys.helsinki.fi> <4A68DC74.8020605@fi.muni.cz> Message-ID: <1248441472.2646.28.camel@localhost.localdomain> Hi all, I've done some updates on the draft at https://fedoraproject.org/wiki/PackagingDrafts/MPI according to Milos' suggestions. I'm not quite sure if MPI software spec files, too, should be 3rd party compiler compatible as the MPI compiler spec files. On Fri, 2009-07-24 at 08:46 -0400, Doug Ledford wrote: > On Jul 23, 2009, at 5:56 PM, Milos Jakubicek wrote: > > Well done, I think you could take also some inspiration from hints > > made by Doug Ledford in BZ#511099: > > > > - what about making the $MPI_HOME, $MPI_BIN and $MPI_LIB variables a > > MUST? > > I would strongly support this. OK, but I really don't see what these are used for. AFAIK they're not used by the MPI compiler for anything, as everything is done by the wrappers. > > - we should make the sample of specfile from the BZ#511099 part of > > the draft > > > > Some other things that come to my mind: > > > > - the libraries must have the suffix OR they could be installed > > under %{_libdir}/%{name}/%{version}-/lib (i.e. there > > should similar two choices as for the binaries) > > I would say the libraries MUST be installed under $MPI_LIB and any > resulting binaries MUST be installed under $MPI_BIN. This makes is so > that loading the MPI environment module automatically gets you all the > associated binaries and libraries needed. That's a valid option, but makes updating the MPI compiler impossible since at least currently with openmpi the dirs are versioned: setenv MPI_BIN /usr/lib/openmpi/1.3.3-gcc/bin setenv MPI_LIB /usr/lib/openmpi/1.3.3-gcc/lib setenv MPI_HOME /usr/lib/openmpi/1.3.3-gcc Of course, installing in a non-versioned directory is a valid option, this would just need a couple of definitions more in the MPI module files. I'd rename the existing MPI_{BIN,LIB,HOME} variables to MPICORE_{BIN,LIB,HOME} and define the following variables: MPI_BIN %{_libdir}/openmpi/gcc/bin MPI_LIB %{_libdir}/openmpi/gcc/lib MPI_MAN %{_libdir}/openmpi/gcc/man MPI_INCLUDE %{_libdir}/openmpi/gcc/include MPI_HOME %{_libdir}/openmpi/gcc/ Out of these, include and man are not usually needed. > > - each MPI build of shared libraries should have a separate -devel > > subpackage (having them in a single -devel subpackage would need a > > require of all MPI builds for it, which is imho not good) > > This is probably good, and would need to be under $MPI_INCLUDE maybe? > It might be worth while to consider simply making it a rule that the > following directories always exist: This is very important and as such is a MUST. > So, as per our conversation in IRC, here's the directory struction I > would recommend. This is brought out by the fact that the current MPI > directory structure I'm using seriously abuses %{_libdir} by putting > way too much stuff under there. We don't really want to use /opt > (even though that's really the perfect place for this) because of the > whole issue of wanting this to be able to be mounted as a read only > network filesystem and putting it in /opt adds a new mount point (and > also adds complexity to drive partitioning issues). So, keeping it > under /usr would seem to be a very important goal. However, we have > binaries, man pages, libraries, include files, and now we are talking > about other packages tossing their stuff under these directories too. > That is a rather excessive abuse of %{_libdir}. The FHS doesn't > really have an option to cover this. At all. I don't think we can > accomplish what needs done while adhering strictly to the FHS. So, I > think there are two options: This is an issue I have been having for a long time with some packages that have general names of binaries. > 1) Create a suitable MPI_HOME that can hold the entire bunch of stuff > from a given MPI package (maybe something like /usr/opt, /usr/local/ > mpi, or /usr/mpi) and under that top level directory install the > multiple mpi packages and also allow for the installation of mpi > linked libraries and binaries. /usr/mpi sounds like a good idea. But it needs to be multiarch/multilib compatible, e.g. 32-bit and 64-bit libraries need to be able to coexist. (Well, we can always use e.g. /usr/mpi/openmpi/lib and /usr/mpi/openmpi/lib64...) > 2) Try to split things up into normal FHS locations, but don't use > binary name suffixes or library name suffixes in the normal > directories, instead use things like /bin/%{name}-%{_arch}%{? > opt_cc_suffix}, %{_libdir}/%{name}%{?opt_cc_suffix}, %{_includedir}/% > {name}-%{_arch}%{?opt_cc_suffix}, %{_datadir}/%{name}-%{_arch}%{? > opt_cc_suffix}, %{_datadir}/%{name}-%{_arch}%{?opt_cc_suffix}/man. > While the above is somewhat clumsy, and also eliminates the > possibility of MPI_HOME being useful as we would now need independent > definitions of all the various MPI locations, it does have the benefit > of being mostly FHS compliant. OK, this holds for MPI compilers, and the directories can be reused for other software, but may be a bit messy.. > Regardless of which way people would prefer to go, I do think we > should go ahead and standardize all the config files in %{_sysconfdir}/ > %{name}-%{_arch}%{?opt_cc_suffix} so that they won't possibly be on a > read only filesystem. So far I haven't seen any MPI software with a config file in /etc. > Thoughts? If we can get this standard more or less agree on, I'll get > the F-11 and devel packages of both lam and openmpi updated the same > day. BTW I think the openmpi spec file does things a bit wrong: ./configure --prefix=%{_libdir}/%{mpidir} --with-libnuma=/usr \ --with-openib=/usr --enable-mpirun-prefix-by-default \ --mandir=%{_libdir}/%{mpidir}/man --enable-mpi-threads \ --with-ft=cr --with-valgrind \ --with-wrapper-cflags="%{?opt_cflags} %{?modeflag}" \ --with-wrapper-cxxflags="%{?opt_cxxflags} %{?modeflag}" \ --with-wrapper-fflags="%{?opt_fflags} %{?modeflag}" \ --with-wrapper-fcflags="%{?opt_fcflags} %{?modeflag}" \ CC=%{opt_cc} CXX=%{opt_cxx} \ LDFLAGS='-Wl,-z,noexecstack' \ CFLAGS="%{?opt_cflags} $RPM_OPT_FLAGS $XFLAGS" \ CXXFLAGS="%{?opt_cxxflags} $RPM_OPT_FLAGS $XFLAGS" \ FC=%{opt_fc} FCFLAGS="%{?opt_fcflags} $RPM_OPT_FLAGS $XFLAGS" \ F77=%{opt_f77} FFLAGS="%{?opt_fflags} $RPM_OPT_FLAGS $XFLAGS" IMHO if opt_*flags are defined then $RPM_OPT_FLAGS should not be used, since the compiler might support the flags in $RPM_OPT_FLAGS. Also, you should use %{optflags} instead of $RPM_OPT_FLAGS as you're using %{buildroot} instead of $RPM_BUILD_ROOT. The wrapper flags shouldn't use opt_*flags since they're not using %{optflags} either - the wrapper flags end up in the compiler call within mpi{cc,cxx,f77,f90}... -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From dledford at redhat.com Fri Jul 24 14:43:00 2009 From: dledford at redhat.com (Doug Ledford) Date: Fri, 24 Jul 2009 10:43:00 -0400 Subject: [Fedora-packaging] Draft for the use of environment-modules In-Reply-To: <1248441472.2646.28.camel@localhost.localdomain> References: <1248251873.18128.7.camel@hawking.theorphys.helsinki.fi> <4A671DCE.1080909@fi.muni.cz> <1248277867.12023.24.camel@hawking.theorphys.helsinki.fi> <1248280630.12023.28.camel@hawking.theorphys.helsinki.fi> <4A68DC74.8020605@fi.muni.cz> <1248441472.2646.28.camel@localhost.localdomain> Message-ID: <2983DF2C-F401-4252-92B4-8C778B963AC3@redhat.com> On Jul 24, 2009, at 9:17 AM, Jussi Lehtola wrote: > Hi all, > > > > I've done some updates on the draft at > https://fedoraproject.org/wiki/PackagingDrafts/MPI > according to Milos' suggestions. > > I'm not quite sure if MPI software spec files, too, should be 3rd > party > compiler compatible as the MPI compiler spec files. With properly functioning MPI installations, there are only very minor differences for 3rd party specs. They could build all mpi versions in one go from a single src rpm, or they could have very slightly different src rpms, one for each mpi. If they opt to build all of them in one go, they could do something like this: Name: mpipackage %package openmpi BuildRequires: openmpi-devel %package mpich2 BuildRequires: mpich2-devel %package lam BuildRequires: lam-devel %install . /etc/profile.d/modules.sh export CC=mpicc for mpi in openmpi mpich2 lam; do make clean module load ${mpi}-%{_arch} ./configure --bindir=$MPI_BIN --libdir=$MPI_LIB --includedir= $MPI_INCLUDE --mandir=$MPI_MAN --datadir=$MPI_DATA --sysconfdir=$MPI_ETC make make DESTDIR=%{buildroot} install find %{builroot}$MPI_BIN %{builroot}$MPI_MAN %{buildroot}$MPI_DATA \ %{buildroot}$MPI_ETC %{buildroot}$MPI_INCLUDE ! -type d \ > $mpi.filelist module unload ${mpi}-%{_arch} done %files openmpi -f openmpi.filelist %files mpich2 -f mpich2.filelist %files lam -f lam.filelist Something like this would work for simple packages. It would be up to the package maintainer to determine if there should be separate base and -devel versions of each package (some have no need of a -devel package, they are not libraries). If things needs splitting up, then modifying the find to create two filelists would work. However, doing a static filelist would likely be problematic as that would present a real headache in dealing with things like mpis compiled with a different compiler. > > On Fri, 2009-07-24 at 08:46 -0400, Doug Ledford wrote: >> On Jul 23, 2009, at 5:56 PM, Milos Jakubicek wrote: >>> Well done, I think you could take also some inspiration from hints >>> made by Doug Ledford in BZ#511099: >>> >>> - what about making the $MPI_HOME, $MPI_BIN and $MPI_LIB variables a >>> MUST? >> >> I would strongly support this. > > OK, but I really don't see what these are used for. AFAIK they're not > used by the MPI compiler for anything, as everything is done by the > wrappers. For installation purposes. It's to ease the burden of packaging up programs compiled against different MPIs. >>> - we should make the sample of specfile from the BZ#511099 part of >>> the draft >>> >>> Some other things that come to my mind: >>> >>> - the libraries must have the suffix OR they could be installed >>> under %{_libdir}/%{name}/%{version}-/lib (i.e. there >>> should similar two choices as for the binaries) >> >> I would say the libraries MUST be installed under $MPI_LIB and any >> resulting binaries MUST be installed under $MPI_BIN. This makes is >> so >> that loading the MPI environment module automatically gets you all >> the >> associated binaries and libraries needed. > > That's a valid option, but makes updating the MPI compiler impossible > since at least currently with openmpi the dirs are versioned: > > setenv MPI_BIN /usr/lib/openmpi/1.3.3-gcc/bin > setenv MPI_LIB /usr/lib/openmpi/1.3.3-gcc/lib > setenv MPI_HOME /usr/lib/openmpi/1.3.3-gcc lam is already non-versioned, and as of openmpi-1.3.2, they expect version upgrades to no longer be binary incompatible, so I intend to unversion it as well. At a minimum we could always leave the current version unversioned and just make it so that if someone wants to install an older version, then they need to put the version back. > Of course, installing in a non-versioned directory is a valid option, > this would just need a couple of definitions more in the MPI module > files. I'd rename the existing MPI_{BIN,LIB,HOME} variables to > MPICORE_{BIN,LIB,HOME} and define the following variables: > > MPI_BIN %{_libdir}/openmpi/gcc/bin > MPI_LIB %{_libdir}/openmpi/gcc/lib > MPI_MAN %{_libdir}/openmpi/gcc/man > MPI_INCLUDE %{_libdir}/openmpi/gcc/include > MPI_HOME %{_libdir}/openmpi/gcc/ > > Out of these, include and man are not usually needed. This is doable, but would mean we also need both the MPICORE_BIN and MPI_BIN added to the PATH, and MPICORE_LIB and MPI_LIB added to the LD_LIBRARY_PATH. >>> - each MPI build of shared libraries should have a separate -devel >>> subpackage (having them in a single -devel subpackage would need a >>> require of all MPI builds for it, which is imho not good) >> >> This is probably good, and would need to be under $MPI_INCLUDE maybe? >> It might be worth while to consider simply making it a rule that the >> following directories always exist: > > This is very important and as such is a MUST. > >> So, as per our conversation in IRC, here's the directory struction I >> would recommend. This is brought out by the fact that the current >> MPI >> directory structure I'm using seriously abuses %{_libdir} by putting >> way too much stuff under there. We don't really want to use /opt >> (even though that's really the perfect place for this) because of the >> whole issue of wanting this to be able to be mounted as a read only >> network filesystem and putting it in /opt adds a new mount point (and >> also adds complexity to drive partitioning issues). So, keeping it >> under /usr would seem to be a very important goal. However, we have >> binaries, man pages, libraries, include files, and now we are talking >> about other packages tossing their stuff under these directories too. >> That is a rather excessive abuse of %{_libdir}. The FHS doesn't >> really have an option to cover this. At all. I don't think we can >> accomplish what needs done while adhering strictly to the FHS. So, I >> think there are two options: > > This is an issue I have been having for a long time with some packages > that have general names of binaries. > >> 1) Create a suitable MPI_HOME that can hold the entire bunch of stuff >> from a given MPI package (maybe something like /usr/opt, /usr/local/ >> mpi, or /usr/mpi) and under that top level directory install the >> multiple mpi packages and also allow for the installation of mpi >> linked libraries and binaries. > > /usr/mpi sounds like a good idea. But it needs to be multiarch/ > multilib > compatible, e.g. 32-bit and 64-bit libraries need to be able to > coexist. > (Well, we can always use e.g. /usr/mpi/openmpi/lib > and /usr/mpi/openmpi/lib64...) I'm leary of trying to put 64bit and 32bit binaries in the same tree. I'm not at all certain that a 64bit mpi runtime from all the various mpis can run a 32bit application. So, given that uncertainty, I would prefer that the 32bit and 64bit versions be entirely separate, including separate bindirs and include dirs (in particular, I think most every single mpi has different include files for 32bit and 64bit due to fortran module binding differences). >> 2) Try to split things up into normal FHS locations, but don't use >> binary name suffixes or library name suffixes in the normal >> directories, instead use things like /bin/%{name}-%{_arch}%{? >> opt_cc_suffix}, %{_libdir}/%{name}%{?opt_cc_suffix}, %{_includedir}/% >> {name}-%{_arch}%{?opt_cc_suffix}, %{_datadir}/%{name}-%{_arch}%{? >> opt_cc_suffix}, %{_datadir}/%{name}-%{_arch}%{?opt_cc_suffix}/man. >> While the above is somewhat clumsy, and also eliminates the >> possibility of MPI_HOME being useful as we would now need independent >> definitions of all the various MPI locations, it does have the >> benefit >> of being mostly FHS compliant. > > OK, this holds for MPI compilers, and the directories can be reused > for > other software, but may be a bit messy.. It is messy, I don't argue that one bit ;-) But I suspect we are less likely to get yelled at for this than, say, creating /usr/mpi (just think back to how much people complained about /usr/java, and they did away with /usr/X11 entirely, I just expect they would see /usr/mpi as a step in the wrong direction). >> Regardless of which way people would prefer to go, I do think we >> should go ahead and standardize all the config files in % >> {_sysconfdir}/ >> %{name}-%{_arch}%{?opt_cc_suffix} so that they won't possibly be on a >> read only filesystem. > > So far I haven't seen any MPI software with a config file in /etc. By default, openmpi and lam both have some files they would put in / etc/ if I didn't have their --prefix set to MPI_HOME. And I got yelled at on f-d for having the etc files in MPI_HOME/etc since someone might want to make local modifications while MPI_HOME might be on a read only network fs mount. >> Thoughts? If we can get this standard more or less agree on, I'll >> get >> the F-11 and devel packages of both lam and openmpi updated the same >> day. > > BTW I think the openmpi spec file does things a bit wrong: > > ./configure --prefix=%{_libdir}/%{mpidir} --with-libnuma=/usr \ > --with-openib=/usr --enable-mpirun-prefix-by-default \ > --mandir=%{_libdir}/%{mpidir}/man --enable-mpi-threads \ > --with-ft=cr --with-valgrind \ > --with-wrapper-cflags="%{?opt_cflags} %{?modeflag}" \ > --with-wrapper-cxxflags="%{?opt_cxxflags} %{?modeflag}" \ > --with-wrapper-fflags="%{?opt_fflags} %{?modeflag}" \ > --with-wrapper-fcflags="%{?opt_fcflags} %{?modeflag}" \ > CC=%{opt_cc} CXX=%{opt_cxx} \ > LDFLAGS='-Wl,-z,noexecstack' \ > CFLAGS="%{?opt_cflags} $RPM_OPT_FLAGS $XFLAGS" \ > CXXFLAGS="%{?opt_cxxflags} $RPM_OPT_FLAGS $XFLAGS" \ > FC=%{opt_fc} FCFLAGS="%{?opt_fcflags} $RPM_OPT_FLAGS $XFLAGS" \ > F77=%{opt_f77} FFLAGS="%{?opt_fflags} $RPM_OPT_FLAGS $XFLAGS" > > IMHO if opt_*flags are defined then $RPM_OPT_FLAGS should not be used, > since the compiler might support the flags in $RPM_OPT_FLAGS. There might be some options that aren't supported by other compilers, but there are a lot of general options in optflags that we would like to preserve. For alternate compilers, I think it's reasonable to have people use sed to remove unwanted options. > Also, you > should use %{optflags} instead of $RPM_OPT_FLAGS as you're using > %{buildroot} instead of $RPM_BUILD_ROOT. But then they can't use sed to filter out the options they don't want ;-) In order to sed filter the options, they have to be a shell variable not an rpm macro. > The wrapper flags shouldn't use opt_*flags since they're not using > %{optflags} either - the wrapper flags end up in the compiler call > within mpi{cc,cxx,f77,f90}... This was intentional. The opt_*flags variables are specifically intended for compiler specific options. We have all the right options since we use gcc, but for icc they likely might want different optimization flags, etc. The opt_*flags are intended to be the place for that. And since the optional compiler wrappers will be calling the optional compiler, they should be passed on down to the mpi* wrappers. While it's a bit of work to get right, the idea was that people would filter out options from RPM_OPT_FLAGS that flat don't work with their compiler, they would set only just the necessary compiler specific options in opt_*flags, they would set the correct modeflag for their compiler (I kept it separate to make sure it was always set, using a non-primary arch mpicc fails otherwise), and the necessary items in opt_*flags and modeflag would go on to the eventual mpicc invocation, while our build opts in RPM_OPT_FLAGS would only be used on our build. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford InfiniBand Specific RPMS http://people.redhat.com/dledford/Infiniband -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 203 bytes Desc: This is a digitally signed message part URL: From jussilehtola at fedoraproject.org Fri Jul 24 15:27:36 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Fri, 24 Jul 2009 18:27:36 +0300 Subject: [Fedora-packaging] Draft for the use of environment-modules In-Reply-To: <2983DF2C-F401-4252-92B4-8C778B963AC3@redhat.com> References: <1248251873.18128.7.camel@hawking.theorphys.helsinki.fi> <4A671DCE.1080909@fi.muni.cz> <1248277867.12023.24.camel@hawking.theorphys.helsinki.fi> <1248280630.12023.28.camel@hawking.theorphys.helsinki.fi> <4A68DC74.8020605@fi.muni.cz> <1248441472.2646.28.camel@localhost.localdomain> <2983DF2C-F401-4252-92B4-8C778B963AC3@redhat.com> Message-ID: <1248449256.2606.25.camel@localhost.localdomain> On Fri, 2009-07-24 at 10:43 -0400, Doug Ledford wrote: > > I'm not quite sure if MPI software spec files, too, should be 3rd > > party > > compiler compatible as the MPI compiler spec files. > > With properly functioning MPI installations, there are only very minor > differences for 3rd party specs. They could build all mpi versions in > one go from a single src rpm, or they could have very slightly > different src rpms, one for each mpi. If they opt to build all of > them in one go, they could do something like this: clip AFAIK you must do off-root builds in %build and install in %install to conform to the RPM standard. The spec file template in the MPI draft does this. > > That's a valid option, but makes updating the MPI compiler impossible > > since at least currently with openmpi the dirs are versioned: > > > > setenv MPI_BIN /usr/lib/openmpi/1.3.3-gcc/bin > > setenv MPI_LIB /usr/lib/openmpi/1.3.3-gcc/lib > > setenv MPI_HOME /usr/lib/openmpi/1.3.3-gcc > > lam is already non-versioned, and as of openmpi-1.3.2, they expect > version upgrades to no longer be binary incompatible, so I intend to > unversion it as well. At a minimum we could always leave the current > version unversioned and just make it so that if someone wants to > install an older version, then they need to put the version back. Those directories are meant only for packaged software. I think less directories is better, especially if you might end up with unowned directories as in the versioned case. Thus you shouldn't have to care about possible incompatibities: if the compiler is upgraded the software has to be rebuilt. So, it is good to have a versioned MPI directory. Maybe we need versioned Requires: on the MPI runtime in MPI enabled software to cope with the directory problem? > >> 2) Try to split things up into normal FHS locations, but don't use > >> binary name suffixes or library name suffixes in the normal > >> directories, instead use things like /bin/%{name}-%{_arch}%{? > >> opt_cc_suffix}, %{_libdir}/%{name}%{?opt_cc_suffix}, %{_includedir}/% > >> {name}-%{_arch}%{?opt_cc_suffix}, %{_datadir}/%{name}-%{_arch}%{? > >> opt_cc_suffix}, %{_datadir}/%{name}-%{_arch}%{?opt_cc_suffix}/man. > >> While the above is somewhat clumsy, and also eliminates the > >> possibility of MPI_HOME being useful as we would now need independent > >> definitions of all the various MPI locations, it does have the > >> benefit > >> of being mostly FHS compliant. > > > > OK, this holds for MPI compilers, and the directories can be reused > > for > > other software, but may be a bit messy.. > > It is messy, I don't argue that one bit ;-) But I suspect we are less > likely to get yelled at for this than, say, creating /usr/mpi (just > think back to how much people complained about /usr/java, and they did > away with /usr/X11 entirely, I just expect they would see /usr/mpi as > a step in the wrong direction). The architecture problem in the first option has convinced me that it is not so simple as it appeared to be at first glance. So I think we end up with the second option. > >> Regardless of which way people would prefer to go, I do think we > >> should go ahead and standardize all the config files in % > >> {_sysconfdir}/ > >> %{name}-%{_arch}%{?opt_cc_suffix} so that they won't possibly be on a > >> read only filesystem. > > > > So far I haven't seen any MPI software with a config file in /etc. > > By default, openmpi and lam both have some files they would put in / > etc/ if I didn't have their --prefix set to MPI_HOME. And I got > yelled at on f-d for having the etc files in MPI_HOME/etc since > someone might want to make local modifications while MPI_HOME might be > on a read only network fs mount. OK, MPI compilers and runtime may have such config files. I was thinking about software. > > IMHO if opt_*flags are defined then $RPM_OPT_FLAGS should not be used, > > since the compiler might support the flags in $RPM_OPT_FLAGS. > > There might be some options that aren't supported by other compilers, > but there are a lot of general options in optflags that we would like > to preserve. For alternate compilers, I think it's reasonable to have > people use sed to remove unwanted options. Maybe they just make their own macro to put them in and #define opt_*flags %{_proprietary_optflags}. Or write the flags explicitly in the spec file. In either case, I don't think you should use $RPM_OPT_FLAGS if opt_*flags are defined. > > Also, you > > should use %{optflags} instead of $RPM_OPT_FLAGS as you're using > > %{buildroot} instead of $RPM_BUILD_ROOT. > > But then they can't use sed to filter out the options they don't > want ;-) In order to sed filter the options, they have to be a shell > variable not an rpm macro. Then declare a shell variable in the spec file and initialize it with %{optflags}. That way you aren't breaking the guidelines :-) -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From xjakub at fi.muni.cz Fri Jul 24 23:33:12 2009 From: xjakub at fi.muni.cz (Milos Jakubicek) Date: Sat, 25 Jul 2009 01:33:12 +0200 Subject: [Fedora-packaging] Draft for the use of environment-modules In-Reply-To: References: <1248251873.18128.7.camel@hawking.theorphys.helsinki.fi> <4A671DCE.1080909@fi.muni.cz> <1248277867.12023.24.camel@hawking.theorphys.helsinki.fi> <1248280630.12023.28.camel@hawking.theorphys.helsinki.fi> <4A68DC74.8020605@fi.muni.cz> Message-ID: <4A6A44B8.9050004@fi.muni.cz> On 24.7.2009 14:46, Doug Ledford wrote: > This is probably good, and would need to be under $MPI_INCLUDE maybe? It > might be worth while to consider simply making it a rule that the > following directories always exist: > > $MPI_HOME/bin > $MPI_HOME/lib > $MPI_HOME/include > $MPI_HOME/man > > and that they are the standard destination for MPI built programs. The > man directory is somewhat optional as man pages should be able to go in > /usr/share/man and simply be reused from the base package, they don't > normally vary from a non-MPI build to an MPI build. However, the man dir > is needed for the MPI packages themselves as they all have rather > extensive, competing man pages. Well, I think the same applies also for the include dir. Headers can be simply split into a separate -headers subpackage and required by every -devel subpackage -- or can you think of a case with different headers for different MPI implementations? >> - the main package should be always built without MPI support, if that >> is possible (i.e. a MUST would be: build at least without MPI (if >> possible) and with OpenMPI) > > You can't do a must as there are some MPI only apps out there (mpitests > is an easy example). But a strong should would work. Yes yes, that's what I meant by "must (if possible)" :) Regards, Milos From jussilehtola at fedoraproject.org Sun Jul 26 12:38:57 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Sun, 26 Jul 2009 15:38:57 +0300 Subject: [Fedora-packaging] MPI and Fortran drafts Message-ID: <1248611938.2615.19.camel@localhost.localdomain> Hello again, I have updated the MPI draft at https://fedoraproject.org/wiki/PackagingDrafts/MPI to take into account the comments that araised in discussion on the list. As I have been dealing with quite a few Fortran packages I have realized that the current laissez-faire mentality may not be enough and a standard is needed for file placement. https://fedoraproject.org/wiki/PackagingDrafts/Fortran As before, comments are welcome. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From xjakub at fi.muni.cz Sun Jul 26 15:22:34 2009 From: xjakub at fi.muni.cz (Milos Jakubicek) Date: Sun, 26 Jul 2009 17:22:34 +0200 Subject: [Fedora-packaging] MPI and Fortran drafts In-Reply-To: <1248611938.2615.19.camel@localhost.localdomain> References: <1248611938.2615.19.camel@localhost.localdomain> Message-ID: <4A6C74BA.8020403@fi.muni.cz> On 26.7.2009 14:38, Jussi Lehtola wrote: > Hello again, > > > I have updated the MPI draft at > https://fedoraproject.org/wiki/PackagingDrafts/MPI > to take into account the comments that araised in discussion on the > list. Looks great, just three minor comments: 1) Shouldn't the suffix for OpenMPI be just "openmpi" instead of "mpi"? It would be consistent with other suffixes (simply the %{name} of the compiler package) and self-explanatory what implementation it is. 2) With the current directory layout (i.e. a FHS-friendly one), the suffixes for binaries and libraries are not necessary anymore, am I right? In that case I think they are even not desirable (what MPI implementation (or no MPI) is used will be controlled by the environment-modules so this would be just annoying when writing e.g. scripts using MPI software etc.) 3) I've modified the draft with a SHOULD: split headers into %{name}-headers. In this case %{name}-%{mpi}-devel needs to require only %{name}-headers (otherwise %{name}-devel will pull in %{name} unnecessarily). In my POV this could be even a MUST (the depedency on the non-MPI build is really not needed). Please review the wiki diff from its history! Thanks for your effort! Milos From pertusus at free.fr Sun Jul 26 16:19:10 2009 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 26 Jul 2009 18:19:10 +0200 Subject: [Fedora-packaging] MPI and Fortran drafts In-Reply-To: <1248611938.2615.19.camel@localhost.localdomain> References: <1248611938.2615.19.camel@localhost.localdomain> Message-ID: <20090726161910.GA8671@free.fr> On Sun, Jul 26, 2009 at 03:38:57PM +0300, Jussi Lehtola wrote: > Hello again, > > > As I have been dealing with quite a few Fortran packages I have realized > that the current laissez-faire mentality may not be enough and a > standard is needed for file placement. > https://fedoraproject.org/wiki/PackagingDrafts/Fortran Unless I don't recall well, https://fedoraproject.org/wiki/PackagingDrafts/FortranModulesDir was accepted as a guideline. I think that instead of a new guideline, the current should be improved. More precisely I think that the placement of .mod files should always be below %_fmoddir, and putting them right in %_fmoddir or below a subdirectory should be left to the packager, with a word telling that a subdirectory should be used if one of the a .mod file installed name is too generic. That way, .mod files rightly named will be used without adding any flag while those that can clash (or those that are to be installed in parallel) can be below a subdirectory. -- Pat From jussilehtola at fedoraproject.org Sun Jul 26 16:34:41 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Sun, 26 Jul 2009 19:34:41 +0300 Subject: [Fedora-packaging] MPI and Fortran drafts In-Reply-To: <20090726161910.GA8671@free.fr> References: <1248611938.2615.19.camel@localhost.localdomain> <20090726161910.GA8671@free.fr> Message-ID: <20090726193441.12516qi4giyhd5ep@webmail.helsinki.fi> Quoting "Patrice Dumas" : > On Sun, Jul 26, 2009 at 03:38:57PM +0300, Jussi Lehtola wrote: >> As I have been dealing with quite a few Fortran packages I have realized >> that the current laissez-faire mentality may not be enough and a >> standard is needed for file placement. >> https://fedoraproject.org/wiki/PackagingDrafts/Fortran > > Unless I don't recall well, > https://fedoraproject.org/wiki/PackagingDrafts/FortranModulesDir > was accepted as a guideline. That would explain the existence of %{_fmoddir} in RPM and %configure. But why is it still in PackagingDrafts? > I think that instead of a new guideline, the current should be improved. > More precisely I think that the placement of .mod files should always be > below %_fmoddir, and putting them right in %_fmoddir or below a subdirectory > should be left to the packager, with a word telling that a subdirectory > should be used if one of the a .mod file installed name is too generic. > That way, .mod files rightly named will be used without adding any flag > while those that can clash (or those that are to be installed in parallel) > can be below a subdirectory. Yes. However, there is still the issue about the include files - where should they be placed? %{_fmoddir} could be also used for this. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From pertusus at free.fr Sun Jul 26 16:40:44 2009 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 26 Jul 2009 18:40:44 +0200 Subject: [Fedora-packaging] MPI and Fortran drafts In-Reply-To: <20090726193441.12516qi4giyhd5ep@webmail.helsinki.fi> References: <1248611938.2615.19.camel@localhost.localdomain> <20090726161910.GA8671@free.fr> <20090726193441.12516qi4giyhd5ep@webmail.helsinki.fi> Message-ID: <20090726164044.GB8671@free.fr> On Sun, Jul 26, 2009 at 07:34:41PM +0300, Jussi Lehtola wrote: > Quoting "Patrice Dumas" : > > That would explain the existence of %{_fmoddir} in RPM and %configure. > But why is it still in PackagingDrafts? I don't know. > Yes. However, there is still the issue about the include files - where > should they be placed? %{_fmoddir} could be also used for this. No, _fmoddir is arch specific while include files are not. I think that they should simply be placed below %_includedir. I am not sure that it would be right to have them in a specific location since c++ files are also in %_includedir. -- Pat From jussilehtola at fedoraproject.org Sun Jul 26 17:00:37 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Sun, 26 Jul 2009 20:00:37 +0300 Subject: [Fedora-packaging] MPI and Fortran drafts In-Reply-To: <4A6C74BA.8020403@fi.muni.cz> References: <1248611938.2615.19.camel@localhost.localdomain> <4A6C74BA.8020403@fi.muni.cz> Message-ID: <20090726200037.16636nglbvwmj99x@webmail.helsinki.fi> Quoting "Milos Jakubicek" : > On 26.7.2009 14:38, Jussi Lehtola wrote: >> Hello again, >> >> >> I have updated the MPI draft at >> https://fedoraproject.org/wiki/PackagingDrafts/MPI >> to take into account the comments that araised in discussion on the >> list. > > Looks great, just three minor comments: > > 1) Shouldn't the suffix for OpenMPI be just "openmpi" instead of > "mpi"? It would be consistent with other suffixes (simply the > %{name} of the compiler package) and self-explanatory what > implementation it is. Yes, that would be more consistent. However, it would break compatibility with the current naming of apps and users would have to re-learn the names of the binaries :) Also, I'd like to stress OpenMPI since AFAIK it is, all in all, the best implementation out there. But, as the interface to the whole MPI stack is going to change anyway, it is maybe better to change to a consistent naming right away. Changed. > 2) With the current directory layout (i.e. a FHS-friendly one), the > suffixes for binaries and libraries are not necessary anymore, am I > right? In that case I think they are even not desirable (what MPI > implementation (or no MPI) is used will be controlled by the > environment-modules so this would be just annoying when writing e.g. > scripts using MPI software etc.) IMHO having the suffix is still better, that way you can run the serial version as well if you need it for something. In scripts this is very easy, as you can use ${MPI_SUFFIX} e.g. #!/bin/bash # Load LAM #module load lam-x86_64 # Load Open MPI module load openmpi-x86_64 # Load MPICH2 #module load mpich2-x86_64 # Preprocess in serial mode foo < foo.in # Run calculation mpirun -np 4 foo${MPI_SUFFIX} # Run more processing mpirun -np 4 bar${MPI_SUFFIX} > 3) I've modified the draft with a SHOULD: split headers into > %{name}-headers. In this case %{name}-%{mpi}-devel needs to require > only %{name}-headers (otherwise %{name}-devel will pull in %{name} > unnecessarily). In my POV this could be even a MUST (the depedency > on the non-MPI build is really not needed). Please review the wiki > diff from its history! OK, this is in case the headers are the same in all of the cases. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From xjakub at fi.muni.cz Sun Jul 26 19:12:27 2009 From: xjakub at fi.muni.cz (Milos Jakubicek) Date: Sun, 26 Jul 2009 21:12:27 +0200 Subject: [Fedora-packaging] MPI and Fortran drafts In-Reply-To: <20090726164044.GB8671@free.fr> References: <1248611938.2615.19.camel@localhost.localdomain> <20090726161910.GA8671@free.fr> <20090726193441.12516qi4giyhd5ep@webmail.helsinki.fi> <20090726164044.GB8671@free.fr> Message-ID: <4A6CAA9B.1030604@fi.muni.cz> On 26.7.2009 18:40, Patrice Dumas wrote: > On Sun, Jul 26, 2009 at 07:34:41PM +0300, Jussi Lehtola wrote: >> Quoting "Patrice Dumas": >> >> That would explain the existence of %{_fmoddir} in RPM and %configure. >> But why is it still in PackagingDrafts? > > I don't know. > It's a pain that this happens pretty often. I accidentally started a long flame some time ago when I just asked about the status of The Flags Draft, most people did not know it has been already approved. Would it be possible for somebody from the Packaging Committee to check all the current content of PackagingDrafts/* for drafts that have been already approved? (And move them of course.) Thanks in advance for taking time for this, I know its annoying but I think that it will take much less time for members of the Packaging Committee than for anybody else to do this! Milos From rdieter at math.unl.edu Sun Jul 26 19:22:46 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 26 Jul 2009 14:22:46 -0500 Subject: [Fedora-packaging] MPI and Fortran drafts In-Reply-To: <4A6CAA9B.1030604@fi.muni.cz> References: <1248611938.2615.19.camel@localhost.localdomain> <20090726161910.GA8671@free.fr> <20090726193441.12516qi4giyhd5ep@webmail.helsinki.fi> <20090726164044.GB8671@free.fr> <4A6CAA9B.1030604@fi.muni.cz> Message-ID: <4A6CAD06.7020905@math.unl.edu> On 07/26/2009 02:12 PM, Milos Jakubicek wrote: > Would it be possible for somebody from the Packaging Committee to check > all the current content of PackagingDrafts/* for drafts that have been > already approved? (And move them of course.) To be clear (and as I understand things), the mere presence of something in PackagingDrafts in no way speaks to whether something has been approved or not. However, in a perfect world, ratified proposals could be marked as such or moved from PackagingDrafts, agreed. -- Rex From Axel.Thimm at ATrpms.net Mon Jul 27 03:23:49 2009 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 27 Jul 2009 06:23:49 +0300 Subject: [Fedora-packaging] Re: Draft to prohibit use of #!/usr/bin/env In-Reply-To: <4A603C56.60303@gmail.com> References: <4A603C56.60303@gmail.com> Message-ID: <20090727032349.GA5985@victor.nirvana> Just as a data point, I rememeber that teTeX had tons of scripts doing the env trick on purpose for maximum portability. I think TeX Live has inherited a lot and is probably still using them for being portable to non-FHS systems. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From panemade at gmail.com Mon Jul 27 06:07:37 2009 From: panemade at gmail.com (=?UTF-8?B?UGFyYWcgTijgpKrgpLDgpL7gpZop?=) Date: Mon, 27 Jul 2009 11:37:37 +0530 Subject: [Fedora-packaging] Merge-review questions.... Message-ID: Hi, I got some questions on Merge-reviews 1) If as per review guidelines merge-review of any package does not got any blocker but missing to follow some packaging guidelines like missing to follow timestamps, should I just ask in review and approve that merge-review or wait for developer to fix spec file? 2) If developer does not replies within a month time or asking me as a reviewer to commit in cvs what should I do for merge-review (Assume I am always there to help and complete merge-review)? Thanks & Regards, Parag. From giallu at gmail.com Mon Jul 27 10:00:02 2009 From: giallu at gmail.com (Gianluca Sforna) Date: Mon, 27 Jul 2009 12:00:02 +0200 Subject: [Fedora-packaging] ScriptletSnippets weirdness Message-ID: I just noticed the page: https://fedoraproject.org/wiki/Packaging:ScriptletSnippets has a weird syntax in gconf scriptlets: export GCONF_CONFIG_SOURCE=gconftool-2 --get-default-source The old wiki page looks good: http://fedoraproject.org/wikiold/Packaging/ScriptletSnippets so I think that was a conversion issue. -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna From jussilehtola at fedoraproject.org Mon Jul 27 16:18:33 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Mon, 27 Jul 2009 19:18:33 +0300 Subject: [Fedora-packaging] MPI and Fortran drafts In-Reply-To: <20090726161910.GA8671@free.fr> References: <1248611938.2615.19.camel@localhost.localdomain> <20090726161910.GA8671@free.fr> Message-ID: <1248711513.32461.3.camel@hawking.theorphys.helsinki.fi> On Sun, 2009-07-26 at 18:19 +0200, Patrice Dumas wrote: > On Sun, Jul 26, 2009 at 03:38:57PM +0300, Jussi Lehtola wrote: > > Hello again, > > > > > > As I have been dealing with quite a few Fortran packages I have realized > > that the current laissez-faire mentality may not be enough and a > > standard is needed for file placement. > > https://fedoraproject.org/wiki/PackagingDrafts/Fortran > > Unless I don't recall well, > https://fedoraproject.org/wiki/PackagingDrafts/FortranModulesDir > was accepted as a guideline. Actually, this guideline is broken [1], the directory has to be versioned [2]. [1] https://bugzilla.redhat.com/show_bug.cgi?id=513985 [2] https://bugzilla.redhat.com/show_bug.cgi?id=483765 -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From tcallawa at redhat.com Mon Jul 27 17:42:16 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 27 Jul 2009 13:42:16 -0400 Subject: [Fedora-packaging] Fedora Packaging Committee Seat Filled Message-ID: <4A6DE6F8.6000103@redhat.com> Thanks to everyone who applied for this open seat. We got a lot of very qualified individuals who were interested in filling the open seat on the Fedora Packaging Committee. After much discussion and thought, I've asked Jon Ciesla to fill the open seat and he has accepted. I'm sure that we will have additional openings on the FPC in the future, as people move on to other tasks, or get committed to various mental institutions. ;) Please feel free to throw your name in the ring for future openings! A few points that I felt might be worth making: * If you're not an active package maintainer in Fedora, it definitely hurts your chances of being on the FPC, as we're always looking for people who are intimately involved with Fedora packaging. * If you haven't done many Fedora Package Reviews, it's a great way to increase your visibility in the Fedora Packaging Community space, and also is a good way to show us that you have a solid understanding of the existing Fedora Packaging Guidelines. Plus, it helps us get new packages into Fedora! Thanks again to all who applied, ~spot From pertusus at free.fr Mon Jul 27 19:15:40 2009 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 27 Jul 2009 21:15:40 +0200 Subject: [Fedora-packaging] MPI and Fortran drafts In-Reply-To: <1248711513.32461.3.camel@hawking.theorphys.helsinki.fi> References: <1248611938.2615.19.camel@localhost.localdomain> <20090726161910.GA8671@free.fr> <1248711513.32461.3.camel@hawking.theorphys.helsinki.fi> Message-ID: <20090727191540.GA3009@free.fr> On Mon, Jul 27, 2009 at 07:18:33PM +0300, Jussi Lehtola wrote: > On Sun, 2009-07-26 at 18:19 +0200, Patrice Dumas wrote: > > On Sun, Jul 26, 2009 at 03:38:57PM +0300, Jussi Lehtola wrote: > > > Hello again, > > > > > > > > > As I have been dealing with quite a few Fortran packages I have realized > > > that the current laissez-faire mentality may not be enough and a > > > standard is needed for file placement. > > > https://fedoraproject.org/wiki/PackagingDrafts/Fortran > > > > Unless I don't recall well, > > https://fedoraproject.org/wiki/PackagingDrafts/FortranModulesDir > > was accepted as a guideline. > > Actually, this guideline is broken [1], the directory has to be > versioned [2]. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=513985 > [2] https://bugzilla.redhat.com/show_bug.cgi?id=483765 This was discussed afterwards, if I recall well, it was said that it was not necessarily broken at each gfortran release, such that we would do rebuild only when we notice a change. In fact it is said as such in the guideline: Each gfortran release (from 4.1 to 4.2) may lead to an incompatible change in the .mod files. Therefore for each such gfortran update, this issue should be investigated, and a rebuild of the package that provide the .mod asked for on the devel announce file and done by the maintainers if needed. Are you unhappy with that? The problem with a versionned directory is that it would lead to many unneeded rebuilds since most of the minor gcc don't break the .mod formats and there are many minor gcc releases. Personnally, I am not opposed to having a versionned directory. In fact this would only mean a change in the _fmoddir macro definition, and maybe somebody willing to organize an automatic rebuild of all the packages installing .mod files. -- Pat From Axel.Thimm at ATrpms.net Mon Jul 27 19:43:25 2009 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 27 Jul 2009 22:43:25 +0300 Subject: [Fedora-packaging] Many unowned directories in /usr/share/man Message-ID: <20090727194325.GA3750@victor.nirvana> Hi, there are some locale that are unowned under /usr/share/man. These directories need to be owned by a package. Many of the more used locales are owned by man/man-pages, but some more exotic are not. It looks like there are about 63 unowned directories coming from the following locale ca da eo es et gl hu id nb nl nn pt pt_BR sk sr sv tr zh_CN zh_TW https://bugzilla.redhat.com/show_bug.cgi?id=220265#c17 The current suggestion is to have the package with the man pages to own these, for example the subtree under /usr/share/man/sv/ shoule be owned by dcraw-8.91-1.fc11.x86_64 fakeroot-1.12.2-21.fc11.x86_64 jwhois-4.0-13.fc11.x86_64 shadow-utils-4.1.2-13.fc11.x86_64 This doesn't seem like a clean or scaling solution and I think it would be better to have these owned by man/man-pages. This probably requires a new guideline, could you please push a matching guideline out, or perhaps just clarify what's there, as I think the intention of the guideline is indeed that the man* packages should own all such directories. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From jussilehtola at fedoraproject.org Mon Jul 27 19:55:58 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Mon, 27 Jul 2009 22:55:58 +0300 Subject: [Fedora-packaging] Many unowned directories in /usr/share/man In-Reply-To: <20090727194325.GA3750@victor.nirvana> References: <20090727194325.GA3750@victor.nirvana> Message-ID: <1248724558.2913.37.camel@hawking.theorphys.helsinki.fi> On Mon, 2009-07-27 at 22:43 +0300, Axel Thimm wrote: > Hi, > > there are some locale that are unowned under /usr/share/man. These > directories need to be owned by a package. Many of the more used > locales are owned by man/man-pages, but some more exotic are not. It > looks like there are about 63 unowned directories coming from the > following locale > > ca da eo es et gl hu id nb nl nn pt pt_BR sk sr sv tr zh_CN zh_TW Wouldn't it be best just to make 'filesystem' own the whole directory structure, and make the other packages just own the pages? On my F11 system 'filesystem' owns /usr/share/man and /usr/share/man* except for /usr/share/manl which isn't owned by anything. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From Axel.Thimm at ATrpms.net Mon Jul 27 20:02:31 2009 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 27 Jul 2009 23:02:31 +0300 Subject: [Fedora-packaging] Re: Many unowned directories in /usr/share/man In-Reply-To: <1248724558.2913.37.camel@hawking.theorphys.helsinki.fi> References: <20090727194325.GA3750@victor.nirvana> <1248724558.2913.37.camel@hawking.theorphys.helsinki.fi> Message-ID: <20090727200231.GA15525@victor.nirvana> On Mon, Jul 27, 2009 at 10:55:58PM +0300, Jussi Lehtola wrote: > On Mon, 2009-07-27 at 22:43 +0300, Axel Thimm wrote: > > Hi, > > > > there are some locale that are unowned under /usr/share/man. These > > directories need to be owned by a package. Many of the more used > > locales are owned by man/man-pages, but some more exotic are not. It > > looks like there are about 63 unowned directories coming from the > > following locale > > > > ca da eo es et gl hu id nb nl nn pt pt_BR sk sr sv tr zh_CN zh_TW > > Wouldn't it be best just to make 'filesystem' own the whole directory > structure, and make the other packages just own the pages? Yes, I agree. Also man can be removed form the system as nothing requires it (but man-pages and redhat-lsb) and suddenly these directories become unowned. But I would go with any solution that doesn't push the ownership down to the packages just offering man pages. As another packager pointed out, the fix he now has to add to own Hungarian locale may become a bug the moment man or man-pages get a Hungarian translation, and the same is true of the other 18 locale. > On my F11 system 'filesystem' owns /usr/share/man and /usr/share/man* > except for /usr/share/manl which isn't owned by anything. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From jussilehtola at fedoraproject.org Mon Jul 27 20:04:54 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Mon, 27 Jul 2009 23:04:54 +0300 Subject: [Fedora-packaging] MPI and Fortran drafts In-Reply-To: <20090727191540.GA3009@free.fr> References: <1248611938.2615.19.camel@localhost.localdomain> <20090726161910.GA8671@free.fr> <1248711513.32461.3.camel@hawking.theorphys.helsinki.fi> <20090727191540.GA3009@free.fr> Message-ID: <1248725094.2913.48.camel@hawking.theorphys.helsinki.fi> On Mon, 2009-07-27 at 21:15 +0200, Patrice Dumas wrote: > On Mon, Jul 27, 2009 at 07:18:33PM +0300, Jussi Lehtola wrote: > > On Sun, 2009-07-26 at 18:19 +0200, Patrice Dumas wrote: > > > Unless I don't recall well, > > > https://fedoraproject.org/wiki/PackagingDrafts/FortranModulesDir > > > was accepted as a guideline. > > > > Actually, this guideline is broken [1], the directory has to be > > versioned [2]. > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=513985 > > [2] https://bugzilla.redhat.com/show_bug.cgi?id=483765 > > This was discussed afterwards, if I recall well, it was said that it was > not necessarily broken at each gfortran release, such that we would do > rebuild only when we notice a change. In fact it is said as such in the > guideline: > > Each gfortran release (from 4.1 to 4.2) may lead to an incompatible change in the .mod files. Therefore for each such gfortran update, this issue should be investigated, and a rebuild of the package that provide the .mod asked for on the devel announce file and done by the maintainers if needed. > > Are you unhappy with that? The problem with a versionned directory is > that it would lead to many unneeded rebuilds since most of the minor gcc > don't break the .mod formats and there are many minor gcc releases. > > Personnally, I am not opposed to having a versionned directory. In fact > this would only mean a change in the _fmoddir macro definition, and maybe > somebody willing to organize an automatic rebuild of all the packages > installing .mod files. That was the opinion of Jakub Jelinek, one of the gcc maintainers. I agree with you that normally that shouldn't have any effect as rebuilds of all packages take place when gfortran is upgraded, but given that on RHEL 5.3 there are two versions of gfortran (the default 4.1 series and the tech preview, gcc43-gfortran, to be updated to gcc44-gfortran in 5.4), this might have an effect. And, as you said, it would only require the redefinition of the _fmoddir macro and a couple of rebuilds. I have modified my proposal to account for the versioned directory. https://fedoraproject.org/wiki/PackagingDrafts/Fortran -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From kevin at tummy.com Mon Jul 27 21:22:45 2009 From: kevin at tummy.com (Kevin Fenzi) Date: Mon, 27 Jul 2009 15:22:45 -0600 Subject: [Fedora-packaging] Merge-review questions.... In-Reply-To: References: Message-ID: <20090727152245.58eac694@ohm.scrye.com> On Mon, 27 Jul 2009 11:37:37 +0530 Parag N(????) wrote: > Hi, > I got some questions on Merge-reviews > 1) If as per review guidelines merge-review of any package does not > got any blocker but missing to follow some packaging guidelines like > missing to follow timestamps, should I just ask in review and approve > that merge-review or wait for developer to fix spec file? I would ask them if they minded if you just commited those fixes, then you could mark it fixed. If they are not review blockers, then you could also just mark it approved and leave it at that. > 2) If developer does not replies within a month time or asking me as a > reviewer to commit in cvs what should I do for merge-review (Assume I > am always there to help and complete merge-review)? I would send them a personal email, wait a bit more, then note this to fedora-devel, then perhaps wait a bit more and bring it up to fesco. There seems to be lots of questions that come up on merge reviews. ;( To help this out, I have started a wiki page at: https://fedoraproject.org/wiki/Merge_Reviews Perhaps we can polish that up and note it to interested Merge reviewers? Feedback welcome. > Thanks & Regards, > Parag. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From pertusus at free.fr Mon Jul 27 21:30:50 2009 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 27 Jul 2009 23:30:50 +0200 Subject: [Fedora-packaging] MPI and Fortran drafts In-Reply-To: <1248725094.2913.48.camel@hawking.theorphys.helsinki.fi> References: <1248611938.2615.19.camel@localhost.localdomain> <20090726161910.GA8671@free.fr> <1248711513.32461.3.camel@hawking.theorphys.helsinki.fi> <20090727191540.GA3009@free.fr> <1248725094.2913.48.camel@hawking.theorphys.helsinki.fi> Message-ID: <20090727213050.GA28471@free.fr> On Mon, Jul 27, 2009 at 11:04:54PM +0300, Jussi Lehtola wrote: > > That was the opinion of Jakub Jelinek, one of the gcc maintainers. But it stirred more conversation, the whole thread started at https://www.redhat.com/archives/fedora-packaging/2007-October/msg00006.html I have reread it, gfortran developpers, in general didn't thought that it should be version specific. > I agree with you that normally that shouldn't have any effect as > rebuilds of all packages take place when gfortran is upgraded, but given > that on RHEL 5.3 there are two versions of gfortran (the default 4.1 > series and the tech preview, gcc43-gfortran, to be updated to > gcc44-gfortran in 5.4), this might have an effect. That doesn't necessarily call for a versionned directory for %_fmoddir. The %_fmoddir of the main compiler may still not be versionned. It calls for a specific subdirectory for gcc43-gfortran .mod files, though normally it should not be used by EPEL/RHEL packages. But this is not really needed for packaging, it is something users could even set on their own -- unless some packages require the tech preview, in that case they should not use _fmoddir anyway. -- Pat From jussilehtola at fedoraproject.org Mon Jul 27 22:07:24 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Tue, 28 Jul 2009 01:07:24 +0300 Subject: [Fedora-packaging] MPI and Fortran drafts In-Reply-To: <20090727213050.GA28471@free.fr> References: <1248611938.2615.19.camel@localhost.localdomain> <20090726161910.GA8671@free.fr> <1248711513.32461.3.camel@hawking.theorphys.helsinki.fi> <20090727191540.GA3009@free.fr> <1248725094.2913.48.camel@hawking.theorphys.helsinki.fi> <20090727213050.GA28471@free.fr> Message-ID: <1248732444.2564.1.camel@hawking.theorphys.helsinki.fi> On Mon, 2009-07-27 at 23:30 +0200, Patrice Dumas wrote: > On Mon, Jul 27, 2009 at 11:04:54PM +0300, Jussi Lehtola wrote: > > > > That was the opinion of Jakub Jelinek, one of the gcc maintainers. > > But it stirred more conversation, the whole thread started at > https://www.redhat.com/archives/fedora-packaging/2007-October/msg00006.html > I have reread it, gfortran developpers, in general didn't thought > that it should be version specific. Thanks for the link, I came to the same conclusion. I've asked Jakub for more explanation at https://bugzilla.redhat.com/show_bug.cgi?id=513985 -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From chkr at fedoraproject.org Mon Jul 27 22:12:24 2009 From: chkr at fedoraproject.org (Christian Krause) Date: Tue, 28 Jul 2009 00:12:24 +0200 Subject: [Fedora-packaging] "Code versus Content" clarification Message-ID: <4A6E2648.7040704@fedoraproject.org> Hi, During one of my last reviews I've stumbled again over some "Code versus Content" issues. After reviewing https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content carefully I've come to the following understanding: Legal status of the content --------------------------- If Fedora somehow publishes the files in any form (source or binary RPM) then they must be under an acceptable license and redistribution must be legally permitted. Additionally it must met the Fedora's criteria described in the packaging guidelines (content should not be offensive, no mp3 files, ...). If the legal as well as Fedora's criteria are not met, the files must not be shipped in any way and so they must be even stripped off from the source files. Question 1: How much investigation is needed from the packager or reviewer? Is asking upstream for an official statement sufficient? Content or example ------------------ If the files can be considered as examples they can just be included in the packages without any interaction with FeSCO. The explicit criteria is not defined, but the following seems quite logical to me: If the files contain rather small demonstrations of the package's capabilities then they are examples (e.g. some midi files in an audio related package). If the files contain a rather detailed or complete work (e.g. if the midi file would contain a thoroughly arranged concert), then they are clearly content. Question 2: If it is undecided, who should make the final decision whether something is just an example? Inclusion of content -------------------- If the files are considered as "real" content and are legally permissable then FeSCO has the final word about the inclusion. Does this summary reflects the intention behind the packaging guidelines correctly? Best regards, Christian From tcallawa at redhat.com Mon Jul 27 22:47:52 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 27 Jul 2009 18:47:52 -0400 Subject: [Fedora-packaging] "Code versus Content" clarification In-Reply-To: <4A6E2648.7040704@fedoraproject.org> References: <4A6E2648.7040704@fedoraproject.org> Message-ID: <4A6E2E98.90908@redhat.com> On 07/27/2009 06:12 PM, Christian Krause wrote: > Question 1: How much investigation is needed from the packager or > reviewer? Is asking upstream for an official statement sufficient? If the reviewer thinks something is legally questionable or would not be appropriate for Fedora, they should flag the package review with FE-Legal. Fedora Legal will advise on whether: * The package is legally acceptable * Whether it contains acceptable code or content, depending on the situation If Fedora Legal is unable to come to a conclusion as to whether content is acceptable (or, you happen to disagree with the conclusion of Fedora Legal), FESCo makes the final call on whether it can be included in Fedora. If it is not permissable due to a licensing or legal issue, Fedora Legal has the final say. Either Fedora Legal or FESCo can be overridden by the Fedora Board, as it has oversight over everything. :) However, from a practical perspective, that's not likely to happen. Does that help answer your questions? ~spot From tcallawa at redhat.com Mon Jul 27 22:49:34 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 27 Jul 2009 18:49:34 -0400 Subject: [Fedora-packaging] Many unowned directories in /usr/share/man In-Reply-To: <1248724558.2913.37.camel@hawking.theorphys.helsinki.fi> References: <20090727194325.GA3750@victor.nirvana> <1248724558.2913.37.camel@hawking.theorphys.helsinki.fi> Message-ID: <4A6E2EFE.3020108@redhat.com> On 07/27/2009 03:55 PM, Jussi Lehtola wrote: >> ca da eo es et gl hu id nb nl nn pt pt_BR sk sr sv tr zh_CN zh_TW > > Wouldn't it be best just to make 'filesystem' own the whole directory > structure, and make the other packages just own the pages? I'm inclined to agree with this. Does anyone think this is a bad idea? ~spot From rc040203 at freenet.de Mon Jul 27 23:02:04 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 28 Jul 2009 01:02:04 +0200 Subject: [Fedora-packaging] Many unowned directories in /usr/share/man In-Reply-To: <4A6E2EFE.3020108@redhat.com> References: <20090727194325.GA3750@victor.nirvana> <1248724558.2913.37.camel@hawking.theorphys.helsinki.fi> <4A6E2EFE.3020108@redhat.com> Message-ID: <4A6E31EC.7070707@freenet.de> On 07/28/2009 12:49 AM, Tom "spot" Callaway wrote: > On 07/27/2009 03:55 PM, Jussi Lehtola wrote: >>> ca da eo es et gl hu id nb nl nn pt pt_BR sk sr sv tr zh_CN zh_TW >> >> Wouldn't it be best just to make 'filesystem' own the whole directory >> structure, and make the other packages just own the pages? > > I'm inclined to agree with this. Does anyone think this is a bad idea? IIRC, we discussed this topic several years ago and already agreed up it, then :) IIRC?, the only problem left had been agreeing upon which "languages to carry" and how let this "extended filesystem" interact with rpm --excludedocs. [Problem: ATM, these lang-subdirs are installed by individual packages, i.e. most users only see a subset of "all languages". With an "extended filesystem" people would see all of them, with most of them being empty. %ghosting them?] Ralf From a.badger at gmail.com Mon Jul 27 23:03:22 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 27 Jul 2009 16:03:22 -0700 Subject: [Fedora-packaging] Many unowned directories in /usr/share/man In-Reply-To: <4A6E2EFE.3020108@redhat.com> References: <20090727194325.GA3750@victor.nirvana> <1248724558.2913.37.camel@hawking.theorphys.helsinki.fi> <4A6E2EFE.3020108@redhat.com> Message-ID: <4A6E323A.6070708@gmail.com> On 07/27/2009 03:49 PM, Tom "spot" Callaway wrote: > On 07/27/2009 03:55 PM, Jussi Lehtola wrote: >>> ca da eo es et gl hu id nb nl nn pt pt_BR sk sr sv tr zh_CN zh_TW >> >> Wouldn't it be best just to make 'filesystem' own the whole directory >> structure, and make the other packages just own the pages? > > I'm inclined to agree with this. Does anyone think this is a bad idea? > This seems like the proper thing to do. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From tibbs at math.uh.edu Mon Jul 27 23:41:26 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 27 Jul 2009 18:41:26 -0500 Subject: [Fedora-packaging] Many unowned directories in /usr/share/man In-Reply-To: <4A6E2EFE.3020108@redhat.com> References: <20090727194325.GA3750@victor.nirvana> <1248724558.2913.37.camel@hawking.theorphys.helsinki.fi> <4A6E2EFE.3020108@redhat.com> Message-ID: >>>>> "TC" == Tom \"spot\" Callaway writes: TC> I'm inclined to agree with this. Does anyone think this is a bad TC> idea? Makes sense to me. The only issue I see is how much bureaucracy it takes to get a new directory added to that package. - J< From jussilehtola at fedoraproject.org Tue Jul 28 00:28:06 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Tue, 28 Jul 2009 03:28:06 +0300 Subject: [Fedora-packaging] MPI draft & EPEL specific packages Message-ID: <1248740886.22040.7.camel@hawking.theorphys.helsinki.fi> Hi, I have added today the Fortran and Python module locations to the MPI draft, and written a bit about the required changes. http://fedoraproject.org/wiki/PackagingDrafts/MPI Related to the draft, what's the process of getting EPEL specific packages? An unified interface on Fedora and EPEL would require a wrapper package for openmpi and lam on RHEL 4 and 5. And last: is the FPC meeting today? I couldn't find any meeting schedules. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From pertusus at free.fr Tue Jul 28 08:42:06 2009 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 28 Jul 2009 10:42:06 +0200 Subject: [Fedora-packaging] MPI draft & EPEL specific packages In-Reply-To: <1248740886.22040.7.camel@hawking.theorphys.helsinki.fi> References: <1248740886.22040.7.camel@hawking.theorphys.helsinki.fi> Message-ID: <20090728084206.GA2947@free.fr> On Tue, Jul 28, 2009 at 03:28:06AM +0300, Jussi Lehtola wrote: > Hi, > > > I have added today the Fortran and Python module locations to the MPI > draft, and written a bit about the required changes. > > http://fedoraproject.org/wiki/PackagingDrafts/MPI > > Related to the draft, what's the process of getting EPEL specific > packages? An unified interface on Fedora and EPEL would require a > wrapper package for openmpi and lam on RHEL 4 and 5. It is said here: https://fedoraproject.org/wiki/EPEL/FAQ#Is_it_possible_to_get_a_package_only_into_EPEL_and_not_Fedora.3F I already maintain one package only in EPEL 4 (tetex-lineno) that has been merged into more recent tetex/texlive. -- Pat From limb at jcomserv.net Tue Jul 28 12:23:25 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 28 Jul 2009 07:23:25 -0500 Subject: [Fedora-packaging] Many unowned directories in /usr/share/man In-Reply-To: References: <20090727194325.GA3750@victor.nirvana> <1248724558.2913.37.camel@hawking.theorphys.helsinki.fi> <4A6E2EFE.3020108@redhat.com> Message-ID: <4A6EEDBD.8020303@jcomserv.net> Jason L Tibbitts III wrote: >>>>>> "TC" == Tom \"spot\" Callaway writes: >>>>>> > > TC> I'm inclined to agree with this. Does anyone think this is a bad > TC> idea? > > Makes sense to me. The only issue I see is how much bureaucracy it takes to > get a new directory added to that package. > > - J< > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > Sounds rational. WTR bureaucracy, would anything beyond a BZ be required? -- in your fear, seek only peace in your fear, seek only love -d. bowie From dgregor at redhat.com Tue Jul 28 13:52:59 2009 From: dgregor at redhat.com (Dennis Gregorovic) Date: Tue, 28 Jul 2009 09:52:59 -0400 Subject: [Fedora-packaging] Many unowned directories in /usr/share/man In-Reply-To: <4A6E31EC.7070707@freenet.de> References: <20090727194325.GA3750@victor.nirvana> <1248724558.2913.37.camel@hawking.theorphys.helsinki.fi> <4A6E2EFE.3020108@redhat.com> <4A6E31EC.7070707@freenet.de> Message-ID: <1248789179.4525.7.camel@localhost.localdomain> On Tue, 2009-07-28 at 01:02 +0200, Ralf Corsepius wrote: > On 07/28/2009 12:49 AM, Tom "spot" Callaway wrote: > > On 07/27/2009 03:55 PM, Jussi Lehtola wrote: > >>> ca da eo es et gl hu id nb nl nn pt pt_BR sk sr sv tr zh_CN zh_TW > >> > >> Wouldn't it be best just to make 'filesystem' own the whole directory > >> structure, and make the other packages just own the pages? > > > > I'm inclined to agree with this. Does anyone think this is a bad idea? > > IIRC, we discussed this topic several years ago and already agreed up > it, then :) > > IIRC?, the only problem left had been agreeing upon which "languages to > carry" and how let this "extended filesystem" interact with rpm > --excludedocs. Will the list of languages to carry be explicitly defined, or will it just be the set of all languages that have one or man pages in the group of @everything packages for that Fedora release? > > [Problem: ATM, these lang-subdirs are installed by individual packages, > i.e. most users only see a subset of "all languages". With an "extended > filesystem" people would see all of them, with most of them being empty. > %ghosting them?] > > Ralf > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging From tcallawa at redhat.com Tue Jul 28 15:01:15 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 28 Jul 2009 11:01:15 -0400 Subject: [Fedora-packaging] Many unowned directories in /usr/share/man In-Reply-To: <4A6EEDBD.8020303@jcomserv.net> References: <20090727194325.GA3750@victor.nirvana> <1248724558.2913.37.camel@hawking.theorphys.helsinki.fi> <4A6E2EFE.3020108@redhat.com> <4A6EEDBD.8020303@jcomserv.net> Message-ID: <4A6F12BB.5040101@redhat.com> On 07/28/2009 08:23 AM, Jon Ciesla wrote: > WTR bureaucracy, would anything beyond a BZ be required? I doubt it. The only question remaining is: * Which locale directories should be created and how is that determined? I'm inclined to say that it should be: for locale in aa af am an ar as az be bg bn bo br bs ca cs cy da de dv dz el en eo es et eu \ fa fi fo fr fy ga gd gl gu gv ha he hi hr ht hu hy id ig ik is it iu iw ja ka kk kl km kn ko ks ku kw \ ky lg li lo lt lv mg mi mk ml mn mr ms mt nb ne nl nn no nr oc om or pa pl pt pt_BR ro ru rw sa \ sc sd se si sk sl so sq sr ss st sv ta te tg th ti tk tl tn tr ts tt ug uk ur uz ve vi wa wo xh yi \ yo zh zh_CN zh_TW zu; do mkdir %{buildroot}%{_mandir}/$locale for a in `seq 0 3`; do mkdir %{buildroot}%{_mandir}/$locale/man$ap done for b in `seq 0 9`; do mkdir %{buildroot}%{_mandir}/$locale/man$b done done That covers everything glibc currently knows about. ~spot From giallu at gmail.com Wed Jul 29 07:59:12 2009 From: giallu at gmail.com (Gianluca Sforna) Date: Wed, 29 Jul 2009 09:59:12 +0200 Subject: [Fedora-packaging] Re: ScriptletSnippets weirdness In-Reply-To: References: Message-ID: On Mon, Jul 27, 2009 at 12:00 PM, Gianluca Sforna wrote: > I just noticed the page: > https://fedoraproject.org/wiki/Packaging:ScriptletSnippets > has a weird syntax in gconf scriptlets: > > export GCONF_CONFIG_SOURCE=gconftool-2 --get-default-source > > The old wiki page looks good: > http://fedoraproject.org/wikiold/Packaging/ScriptletSnippets > so I think that was a conversion issue. Spot, I see you updated the page but it still does not look right as you just removed the tags without adding the backticks as in: export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` Sorry for the trouble G. -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna From a.badger at gmail.com Wed Jul 29 14:22:14 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 29 Jul 2009 07:22:14 -0700 Subject: [Fedora-packaging] Re: ScriptletSnippets weirdness In-Reply-To: References: Message-ID: <4A705B16.8010203@gmail.com> On 07/29/2009 12:59 AM, Gianluca Sforna wrote: > On Mon, Jul 27, 2009 at 12:00 PM, Gianluca Sforna wrote: >> I just noticed the page: >> https://fedoraproject.org/wiki/Packaging:ScriptletSnippets >> has a weird syntax in gconf scriptlets: >> >> export GCONF_CONFIG_SOURCE=gconftool-2 --get-default-source >> >> The old wiki page looks good: >> http://fedoraproject.org/wikiold/Packaging/ScriptletSnippets >> so I think that was a conversion issue. > > Spot, I see you updated the page but it still does not look right as > you just removed the tags without adding the backticks as in: > > export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` > I think it's fixed now Thanks! -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From jussilehtola at fedoraproject.org Thu Jul 30 00:20:02 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Thu, 30 Jul 2009 03:20:02 +0300 Subject: [Fedora-packaging] Environment-modules & MPI drafts Message-ID: <1248913202.4938.22.camel@localhost.localdomain> Hi, I think I am reasonably happy with the current versions of the Environment modules and MPI drafts, as they should cover everything. The environment module part is quite simple, the MPI part took quite some amount of work to get everything (such as Python and Fortran modules) in it. For a while I was not quite sure which was better: not having an MPI binary suffix, or having one. On one hand not having a suffix may be easier on behalf of the user (then again running the serial version is harder when an MPI module is loaded). On the other hand, I think that it's better to run the wanted MPI version explicitly instead of blindly trusting what is in the $PATH. For consistency in binary naming we MUST have a guideline on the suffixes. My gut feeling is that suffixing is better (normally MPI enabled software makefiles produce suffixed binaries when MPI is on), thus I have ended up with suffixes (if nobody has strong negative feelings about this). As F12 is drawing nearer quite fast, I'm hoping for these guidelines to be decided upon ASAP, so the packaging side can be taken care of in time. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org