From fedora at leemhuis.info Fri Jan 6 10:41:02 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 06 Jan 2006 11:41:02 +0100 Subject: [Fedora-packaging] Heads-up: "RFC: kernel-modules in Fedora Extras" now on fedora-extras-list In-Reply-To: <1136543456.3146.19.camel@localhost.localdomain> References: <1136543456.3146.19.camel@localhost.localdomain> Message-ID: <1136544062.3146.30.camel@localhost.localdomain> Hi all! Sorry for crossposting, but I think a short heads-up is needed here. The Fedora Extras Steering Committee (FESCo) agreed on a standard for packaging kernel-modules in Fedora Extras. To look at the details see this mail: https://www.redhat.com/archives/fedora-extras-list/2006-January/msg00219.html The last chance to comment on it before it is getting used in devel/FC5 is: Now. Please use fedora-extras-list for the discussion -- please don't reply to this mail on this list. Instead click on reply and change the To: field to fedora-extras-list at redhat.com (the threading hopefully should work fine if you do it like this). Thanks! CU thl -- Thorsten Leemhuis From andreas at bawue.net Wed Jan 25 00:41:29 2006 From: andreas at bawue.net (Andreas Thienemann) Date: Wed, 25 Jan 2006 01:41:29 +0100 (CET) Subject: [Fedora-packaging] Specfile suggestion for subpackages with differently linked binaries Message-ID: Hi, I'm currently trying to package ser, the sip express router. Depending on the variables passed at compile time, the resulting binary is either linking against mysql or postgresql. IN order not to pull in unneeded dependencies I'd like to package it as ser (no database support/no persistant storage), ser-mysql, ser-pgsql and ser-common for the rest Is there a template/example spec file somewhere detailing how one would package such a software? Right now I'm wondering how to manage the %install phase and how to get the binaries with the same name, but different dependencies installed and listed in the %files section. thx, andreas From alan at balclutha.org Thu Jan 26 03:50:56 2006 From: alan at balclutha.org (Alan Milligan) Date: Thu, 26 Jan 2006 14:50:56 +1100 Subject: [Fedora-packaging] Python eggs Message-ID: <43D84720.8070505@balclutha.org> Hi, Unfortunately, the Python community is becoming intoxicated with eggs! Is there a strategy (preferably backed by rpm macros) to deal with this - ie sanely packaging all egg'd installed prerequisites?? Alan From hunter at userfriendly.net Thu Jan 26 03:56:32 2006 From: hunter at userfriendly.net (Michael Weiner) Date: Wed, 25 Jan 2006 22:56:32 -0500 Subject: [Fedora-packaging] Python eggs In-Reply-To: <43D84720.8070505@balclutha.org> References: <43D84720.8070505@balclutha.org> Message-ID: On 1/25/06, Alan Milligan wrote: > Hi, > > Unfortunately, the Python community is becoming intoxicated with eggs! > > Is there a strategy (preferably backed by rpm macros) to deal with this > - ie sanely packaging all egg'd installed prerequisites?? > I have been watching this too and wondering the best response to packaging requirements myself. Any thoughts? Michael Weiner From sopwith at redhat.com Thu Jan 26 04:54:52 2006 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 25 Jan 2006 23:54:52 -0500 (EST) Subject: [Fedora-packaging] Python eggs In-Reply-To: References: <43D84720.8070505@balclutha.org> Message-ID: On Wed, 25 Jan 2006, Michael Weiner wrote: > > Unfortunately, the Python community is becoming intoxicated with eggs! > > > > Is there a strategy (preferably backed by rpm macros) to deal with this > > - ie sanely packaging all egg'd installed prerequisites?? Having just become familiar with this stuff myself yesterday, it seems like it should be fairly simple to package up the .egg's themselves. I think the main challenge is to come up with a way of automatically turning egg dependencies (both provides & requires) into rpm dependencies... This should be doable with minimal rpm modifications. .egg's already have all the information necessary to do this. The biggest challenge I ran into was getting setuptools to recognize the existence of some non-eggd dependencies. For example, python-elementtree was installed but setuptools keeps insisting that it couldn't find cElementTree >= 0.2. This is more of a pythonland issue than an rpmland issue, but we'll definitely have to address it in order to make .eggs work nicely. Perhaps the maintainer of the python-setuptools package can shed additional insights, since that's where all the magic happens. Best, -- Elliot From ivazquez at ivazquez.net Thu Jan 26 05:10:34 2006 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 26 Jan 2006 00:10:34 -0500 Subject: [Fedora-packaging] Python eggs In-Reply-To: References: <43D84720.8070505@balclutha.org> Message-ID: <1138252234.3795.9.camel@ignacio.lan> On Wed, 2006-01-25 at 23:54 -0500, Elliot Lee wrote: > On Wed, 25 Jan 2006, Michael Weiner wrote: > > > > Unfortunately, the Python community is becoming intoxicated with eggs! > > > > > > Is there a strategy (preferably backed by rpm macros) to deal with this > > > - ie sanely packaging all egg'd installed prerequisites?? > > Having just become familiar with this stuff myself yesterday, it seems > like it should be fairly simple to package up the .egg's themselves. I > think the main challenge is to come up with a way of automatically turning > egg dependencies (both provides & requires) into rpm dependencies... This > should be doable with minimal rpm modifications. .egg's already have all > the information necessary to do this. Certainly it is feasible to write a script that could look at setup.py after the fact and extract the requirements from there, or even to inject a bit of code into setuptools itself. Provides might require a little more work unless we switch to using the python() namespace. > The biggest challenge I ran into was getting setuptools to recognize the > existence of some non-eggd dependencies. For example, python-elementtree > was installed but setuptools keeps insisting that it couldn't find > cElementTree >= 0.2. This is more of a pythonland issue than an rpmland > issue, but we'll definitely have to address it in order to make .eggs work > nicely. Unfortunately [c]ElementTree et al will be a persistent issue until either setuptools becomes part of Core, or the maintainers of the Python packages in Core are convinced to include additional information within the package (which may or may not be egg information). If you look at how I did it in TurboGears you see that I commented out the packages in setup.py that don't provide egg/package information, but this certainly isn't something we want to do long-term. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugs.michael at gmx.net Thu Jan 26 11:19:26 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 26 Jan 2006 12:19:26 +0100 Subject: [Fedora-packaging] Specfile suggestion for subpackages with differently linked binaries In-Reply-To: References: Message-ID: <20060126121926.6144b7e5.bugs.michael@gmx.net> On Wed, 25 Jan 2006 01:41:29 +0100 (CET), Andreas Thienemann wrote: > Hi, > > I'm currently trying to package ser, the sip express router. > > Depending on the variables passed at compile time, the resulting binary is > either linking against mysql or postgresql. > IN order not to pull in unneeded dependencies I'd like to package it as > ser (no database support/no persistant storage), ser-mysql, ser-pgsql and > ser-common for the rest > > Is there a template/example spec file somewhere detailing how one would > package such a software? "ulogd" in Extras is similar with regard to sub-packages for database support. But it doesn't require running %configure twice. Your description is a bit vague (also see below). Does the software build multiple plugins for database support? Or does it create a single executable only, which is linked to a single chosen database library? In that case, your packages would conflict, because you would have two executables, one linked against mysql, the other linked against pgsql. Bad. In case you need to %configure and "make" the source code twice, you can't avoid compiling the code once, moving built files into a temporary directory, then compiling the code again with a modified configuration. In the %install section you would install the built files from the first pass manually and install the rest as usual. In case of file name conflicts, however, you need to find a different solution (like giving files changed names). > Right now I'm wondering how to manage the %install phase and how to get > the binaries with the same name, but different dependencies installed and > listed in the %files section. "binaries with the same name" sounds like a conflict. If you want mutually exclusive sub-packages ser-mysql and ser-pgsql, you still need non-conflicting file names and a mechanism like "alternatives" to activate the desired database version after installation. From skvidal at linux.duke.edu Thu Jan 26 22:45:52 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 26 Jan 2006 17:45:52 -0500 Subject: [Fedora-packaging] Python eggs In-Reply-To: <1138252234.3795.9.camel@ignacio.lan> References: <43D84720.8070505@balclutha.org> <1138252234.3795.9.camel@ignacio.lan> Message-ID: <1138315552.22125.0.camel@cutter> On Thu, 2006-01-26 at 00:10 -0500, Ignacio Vazquez-Abrams wrote: > On Wed, 2006-01-25 at 23:54 -0500, Elliot Lee wrote: > > On Wed, 25 Jan 2006, Michael Weiner wrote: > > > > > > Unfortunately, the Python community is becoming intoxicated with eggs! > > > > > > > > Is there a strategy (preferably backed by rpm macros) to deal with this > > > > - ie sanely packaging all egg'd installed prerequisites?? > > > > Having just become familiar with this stuff myself yesterday, it seems > > like it should be fairly simple to package up the .egg's themselves. I > > think the main challenge is to come up with a way of automatically turning > > egg dependencies (both provides & requires) into rpm dependencies... This > > should be doable with minimal rpm modifications. .egg's already have all > > the information necessary to do this. > > Certainly it is feasible to write a script that could look at setup.py > after the fact and extract the requirements from there, or even to > inject a bit of code into setuptools itself. Provides might require a > little more work unless we switch to using the python() namespace. > > > The biggest challenge I ran into was getting setuptools to recognize the > > existence of some non-eggd dependencies. For example, python-elementtree > > was installed but setuptools keeps insisting that it couldn't find > > cElementTree >= 0.2. This is more of a pythonland issue than an rpmland > > issue, but we'll definitely have to address it in order to make .eggs work > > nicely. > > Unfortunately [c]ElementTree et al will be a persistent issue until > either setuptools becomes part of Core, or the maintainers of the Python > packages in Core are convinced to include additional information within > the package (which may or may not be egg information). If you look at > how I did it in TurboGears you see that I commented out the packages in > setup.py that don't provide egg/package information, but this certainly > isn't something we want to do long-term. > Why can't we do what debian and conary is doing already for eggs. there's some option you can pass in for packaging this sort of thing, iirc. -sv From orion at cora.nwra.com Fri Jan 27 00:50:26 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 26 Jan 2006 17:50:26 -0700 Subject: [Fedora-packaging] Re: Replacing LAM with OpenMPI in Fedora Core In-Reply-To: <1136491078.20505.115.camel@ernie> References: <1136226300.30006.345.camel@ernie> <1136491078.20505.115.camel@ernie> Message-ID: <43D96E52.9080203@cora.nwra.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ed Hill wrote: > On Thu, 2006-01-05 at 11:59 -0700, Orion Poplawski wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Ed Hill wrote: >>> I understand that OpenMPI is supposed to [at least, for some people's >>> perception! ;-)] become the "one true MPI" implementation that eclipses >>> all others due to its very cool new modular design and other features. >>> But, even so, I think it would be a good idea to have and maintain other >>> MPI versions (such as MPICH v1 & v2, LAM, etc.) in Extras so that people >>> have some flexibility. And to do that, we'll very likely need to setup >>> the multiple MPI packages using alternatives. >> >> While we are thinking about this, it would be good to be able to support >> multiple versions of a particular MPI compiled with different compilers. >> Locally I maintain LAM compiled with PGF90 and IFORT and it would be >> nice to be able to have all three installed simultaneously. > > Hi Orion, > > Yes, we also have groups of machines where we maintain combinations of > compilers, MPI libs, etc.: > > MPI: LAM, mpich, mpich-vmi, etc. > Compilers: GNU (multiple versions), Intel, PGI, etc. > > and we do it with an install framework that looks something like: > > /opt/pkg/${PKG_NAME} and/or /usr/local/pkg/${PKG_NAME} > > and then let users dynamically chose which packages or combinations of > packages to use with the environment modules scripts: > > http://modules.sourceforge.net/ > > I like the above setup because: > > + its quite flexible and can handle dependencies between > the packages pretty gracefully > + it can be made to work (play nicely!) with the in-Core MPI > setup and/or any number of additional MPI setups which > might be installed (perhas someday?) through Fedora Extras > or local installs > + its an increasingly popular arrangement for scientific and > high-performance computing systems > > I'd like to see as much of the above as possible included in Fedora > Extras and [given what little free time I have! :-)] I'm doing what I > can to try and get the necessary parts packaged, etc. I have a modules > package in progress and will be glad to share my unfinished bits with > anyone who is interested. > > Do you have any objections to the above or maybe suggestions for > improvements? > > Ed > I've been poking around a bit with this using alternatives, and I've think I've reached a dead end with that approach. It's okay for a couple binaries and man pages, but it quickly gets unwieldy with collections of shared libraries and sets of API man pages. Also, alternatives works reasonably well for *system* wide defaults. Less well for per user defaults. I've submitted the modules system for Extras for use there. So, what are the restrictions in Fedora as to where we can install things? In particular, I think we may need to install most of the binaries somewhere other than /usr/bin, and we *definitely* need the man3 pages somewhere other than /usr/share/man/man3 (and maybe the rest as well). How to we switch default paths between different bin and man directories? Entries in /etc/profile.d managed via alternatives? Some bugs tracking this discussion: Bug 178967 ? Future of lam - use alternatives https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178967 Bug 173719 ? Review Request: openmpi - a new MPI implementation https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173719 Bug 171993 ? Review Request: mpich2 - An implementation of MPI https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171993 - - Orion -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFD2W5RORnzrtFC2/sRAvDpAJwLTjdtmiKU4iZSTa1LUSNzI8I+NQCfRffM lFHmzvw3LTP5N6YMdTH+61U= =0Vu5 -----END PGP SIGNATURE----- From andreas at bawue.net Sat Jan 28 13:27:20 2006 From: andreas at bawue.net (Andreas Thienemann) Date: Sat, 28 Jan 2006 14:27:20 +0100 (CET) Subject: [Fedora-packaging] Specfile suggestion for subpackages with differently linked binaries In-Reply-To: <20060126121926.6144b7e5.bugs.michael@gmx.net> References: <20060126121926.6144b7e5.bugs.michael@gmx.net> Message-ID: On Thu, 26 Jan 2006, Michael Schwendt wrote: > "ulogd" in Extras is similar with regard to sub-packages for database > support. Thanks for that suggestion. I'll take a look at it, and see what I can do about it. > Or does it create a single executable only, which is linked to a single > chosen database library? In that case, your packages would conflict, > because you would have two executables, one linked against mysql, the > other linked against pgsql. Bad. That is the case. > "binaries with the same name" sounds like a conflict. If you want > mutually exclusive sub-packages ser-mysql and ser-pgsql, you still need > non-conflicting file names and a mechanism like "alternatives" to > activate the desired database version after installation. Hmpf. That's what I feared. I think, I'll have to do some more hacking on this .spec. bye, andreas From sopwith at redhat.com Tue Jan 31 21:24:08 2006 From: sopwith at redhat.com (Elliot Lee) Date: Tue, 31 Jan 2006 16:24:08 -0500 (EST) Subject: [Fedora-packaging] Python eggs In-Reply-To: <1138252234.3795.9.camel@ignacio.lan> References: <43D84720.8070505@balclutha.org> <1138252234.3795.9.camel@ignacio.lan> Message-ID: On Thu, 26 Jan 2006, Ignacio Vazquez-Abrams wrote: > Unfortunately [c]ElementTree et al will be a persistent issue until > either setuptools becomes part of Core, or the maintainers of the Python > packages in Core are convinced to include additional information within > the package (which may or may not be egg information). If you look at > how I did it in TurboGears you see that I commented out the packages in > setup.py that don't provide egg/package information, but this certainly > isn't something we want to do long-term. Yea, I think it'd be good to figure out a way to fake the egg information in the main python package. Mihai, do you have any thoughts in this area? Best, -- Elliot