From mtasaka at ioa.s.u-tokyo.ac.jp Fri May 1 03:51:28 2009 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Fri, 01 May 2009 12:51:28 +0900 Subject: [Fedora-packaging] ruby gem and library in C and debuginfo In-Reply-To: <1241120077.21702.66.camel@eagle.danny.cz> References: <1241120077.21702.66.camel@eagle.danny.cz> Message-ID: <49FA71C0.9060704@ioa.s.u-tokyo.ac.jp> Hello: Dan Hor?k wrote, at 05/01/2009 04:34 AM +9:00: > Hi, > > I am doing a review for a ruby gem package that includes a library > written in C (https://bugzilla.redhat.com/show_bug.cgi?id=497640) and > there are problems with proper generation of the debuginfo package. It > cannot find the source files, because the paths in the debugsources.list > contains the "ext/" part twice and that's wrong. > > + /usr/lib/rpm/find-debuginfo.sh > --strict-build-id /home/dan/rpmbuild/BUILD/rubygem-RedCloth-4.1.9 > extracting debug info > from /home/dan/rpmbuild/BUILDROOT/rubygem-RedCloth-4.1.9-3.fc10.x86_64/usr/lib64/ruby/site_ruby/1.8/x86_64-linux/redcloth_scan.so > cpio: > rubygem-RedCloth-4.1.9/usr/lib/ruby/gems/1.8/gems/RedCloth-4.1.9/ext/redcloth_scan/ext/redcloth_scan/redcloth_attributes.c: Cannot stat: No such file or directory > cpio: > rubygem-RedCloth-4.1.9/usr/lib/ruby/gems/1.8/gems/RedCloth-4.1.9/ext/redcloth_scan/ext/redcloth_scan/redcloth_attributes.c.rl: Cannot stat: No such file or directory This is because .%{geminstdir}/ext/redcloth/*.{c,ri} contains #line directive. For example, from redcloth_attributes.c: ----------------------------------------------------------------- 10 #line 15 "ext/redcloth_scan/redcloth_attributes.c.rl" 11 12 13 14 #line 15 "ext/redcloth_scan/redcloth_attributes.c" ----------------------------------------------------------------- In such case debuginfo tries to pick up files #line directive points to. So this is not rubygem specific. The easiest solution is something like ----------------------------------------------------------------- %install rm -rf %{buildroot} # For short-circuit rm -rf .%{geminstdir}/ext/redcloth_scan/ext/redcloth_scan .. .. cp -a .%{gemdir}/* %{buildroot}%{gemdir} .. .. # For debuginfo mkdir -p .%{geminstdir}/ext/redcloth_scan/ext/redcloth_scan cp -p .%{geminstdir}/ext/redcloth_scan/*.{c,rl} \ .%{geminstdir}/ext/redcloth_scan/ext/redcloth_scan ----------------------------------------------------------------- Regards, Mamoru From ville.skytta at iki.fi Sat May 2 10:34:56 2009 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sat, 2 May 2009 13:34:56 +0300 Subject: [Fedora-packaging] "Explicit requires" and "requiring base package" Message-ID: <200905021334.56366.ville.skytta@iki.fi> https://fedoraproject.org/wiki/Packaging/Guidelines#Explicit_Requires Packages must not contain explicit Requires on libraries except when absolutely necessary. [...] https://fedoraproject.org/wiki/Packaging/Guidelines#Requiring_Base_Package Devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release}. Usually, subpackages other than -devel should also require the base package using a fully versioned dependency. I think these two guidelines or their wording are more or less in conflict these days. Most -devel packages do not "absolutely necessarily" need an explicit dependency on the base package because rpm automatically adds soname dependencies from symlinks in -devel to the corresponding shared lib in the main/lib package. Ditto, many cases of other non-devel subpackages get automatic lib soname dependencies to the main/lib package. If the intent is to still require explicit deps like in "requiring base package" even though there are automatic ones that would usually work, just to be sure or for other reasons (possibility of compilation options, patchwork that affects some internal subpackages but not other -devel/lib package consumers), I think "requiring base packages" and "explicit requires" should be cross referenced noting that this is an exception and those explicit deps are indeed wanted. If not, IMO "requiring base package" should be softened so that it requires adding those explicit deps if no automatic ones are present, or just removed because that'd be redundant with "explicit requires" and the rest of the general dependency guidelines. From ville.skytta at iki.fi Sat May 2 10:52:15 2009 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sat, 2 May 2009 13:52:15 +0300 Subject: [Fedora-packaging] Package-internal static linkage Message-ID: <200905021352.16167.ville.skytta@iki.fi> Hello, Do the "no static linking" rules apply equally also to cases where the lib and the executable packaged are from the same package build? I'm packaging xz and intend to ship only shared libs, executables and devel files as usual, but upstream likes to link the executables statically with the rationale (liblzma comes from the same package, linkage would be done against the non-shipped static liblzma created during the build): ## Always link the command line tool statically against liblzma. It is ## faster on x86, because no need for PIC. We also have one dependency less, ## which allows users to more freely copy the xz binary to other boxes. It's easy enough to change this and link the executables dynamically, and I haven't bothered to get any numbers to check the upstream claim. But I suppose the primary security reason against static linkage doesn't really apply that much when the executable and the lib are results from the same package build, so I thought I'd ask if there are strong opinions on whether this would be a valid exception to the no static linkage guideline or not (none here). From rc040203 at freenet.de Sat May 2 13:56:48 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 02 May 2009 15:56:48 +0200 Subject: [Fedora-packaging] Package-internal static linkage In-Reply-To: <200905021352.16167.ville.skytta@iki.fi> References: <200905021352.16167.ville.skytta@iki.fi> Message-ID: <49FC5120.9070704@freenet.de> Ville Skytt? wrote: > Hello, > > Do the "no static linking" rules apply equally also to cases where the lib and > the executable packaged are from the same package build? Generally speaking, yes. From a bit more radical position: Yes, especially in these cases, because the savings on disc-space typically show best on in these cases. (Consider 10 statically linked application binaries + shared binaries. In worst case, this means 11 times duplicated object files) From a pragmatical position: There are probably 100s of packages, where this is done unnoticed. > I'm packaging xz and intend to ship only shared libs, executables and devel > files as usual, but upstream likes to link the executables statically with the > rationale (liblzma comes from the same package, linkage would be done against > the non-shipped static liblzma created during the build): OK, liblzma explains it ;) > ## Always link the command line tool statically against liblzma. It is > ## faster on x86, because no need for PIC. We also have one dependency less, > ## which allows users to more freely copy the xz binary to other boxes. Is this what they are telling you? Unless I am mistaken, lzma+liblzma have had several API/ABI breakages in the past. I am inclined to think there actual reasons might be elsewhere, ... > It's easy enough to change this and link the executables dynamically, and I > haven't bothered to get any numbers to check the upstream claim. But I > suppose the primary security reason against static linkage doesn't really > apply that much when the executable and the lib are results from the same > package build, so I thought I'd ask if there are strong opinions on whether > this would be a valid exception to the no static linkage guideline or not > (none here). Ralf From a.badger at gmail.com Sat May 2 15:25:23 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 02 May 2009 08:25:23 -0700 Subject: [Fedora-packaging] Package-internal static linkage In-Reply-To: <200905021352.16167.ville.skytta@iki.fi> References: <200905021352.16167.ville.skytta@iki.fi> Message-ID: <49FC65E3.6050305@gmail.com> Ville Skytt? wrote: > It's easy enough to change this and link the executables dynamically, and I > haven't bothered to get any numbers to check the upstream claim. But I > suppose the primary security reason against static linkage doesn't really > apply that much when the executable and the lib are results from the same > package build, so I thought I'd ask if there are strong opinions on whether > this would be a valid exception to the no static linkage guideline or not > (none here). I tend to agree that the primary reason for this is security and that claim is not as strong in this case. I have two thoughts to toss out: * Linking the utilities dynamically tests that dynamic linking works. mono w/ libmono on ppc caught this problem (although we're currently shipping that statically linked because F11 is too close and nothing else in-distro currently embeds the mono runtime :-( * If we allow this, reviewers and packagers will have to be careful about deciding whether the package really is the canonical place for the library. For instance, rsync builds against a private, slightly modified version of zlib. zsync does the same thing. These should not be allowed exceptions as the security concerns still apply. Ralf's point about saving disk space is also a negative. -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 lkundrak at v3.sk Sat May 2 20:56:23 2009 From: lkundrak at v3.sk (Lubomir Rintel) Date: Sat, 02 May 2009 22:56:23 +0200 Subject: [Fedora-packaging] Package-internal static linkage In-Reply-To: <200905021352.16167.ville.skytta@iki.fi> References: <200905021352.16167.ville.skytta@iki.fi> Message-ID: <1241297783.2226.4.camel@localhost.localdomain> On Sat, 2009-05-02 at 13:52 +0300, Ville Skytt? wrote: > Hello, > > Do the "no static linking" rules apply equally also to cases where the lib and > the executable packaged are from the same package build? Given the objective of the rule, which I believe is to prevent copies of compiled code being out of sync so that issues (especially security) won't stay unfixed an unnoticed for some of the copies, there's no problem with intra-package static link. That is, as long as you don't ship the static library that other packages could link against. One subtle advantage of dynamic linking would be saving space by making the executable image as well as text of the running process smaller, but I guess in your case (trading space for performance) is a quite good deal. -- "Excuse all the blood" -- Dead From lkundrak at v3.sk Sat May 2 20:58:57 2009 From: lkundrak at v3.sk (Lubomir Rintel) Date: Sat, 02 May 2009 22:58:57 +0200 Subject: [Fedora-packaging] Package-internal static linkage In-Reply-To: <1241297783.2226.4.camel@localhost.localdomain> References: <200905021352.16167.ville.skytta@iki.fi> <1241297783.2226.4.camel@localhost.localdomain> Message-ID: <1241297937.2226.6.camel@localhost.localdomain> On Sat, 2009-05-02 at 22:56 +0200, Lubomir Rintel wrote: > On Sat, 2009-05-02 at 13:52 +0300, Ville Skytt? wrote: > > Hello, > > > > Do the "no static linking" rules apply equally also to cases where the lib and > > the executable packaged are from the same package build? > > Given the objective of the rule, which I believe is to prevent copies of > compiled code being out of sync so that issues (especially security) > won't stay unfixed an unnoticed for some of the copies, there's no > problem with intra-package static link. That is, as long as you don't > ship the static library that other packages could link against. > > One subtle advantage of dynamic linking would be saving space by making > the executable image as well as text of the running process smaller, but > I guess in your case (trading space for performance) is a quite good > deal. Uff, sorry, no need for you to read my reply, pretty much repeating what Ralf and Toshio said. I should have refreshed mailbox once more before posting. -- "Excuse all the blood" -- Dead From rc040203 at freenet.de Sun May 3 07:39:19 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 03 May 2009 09:39:19 +0200 Subject: [Fedora-packaging] Package-internal static linkage In-Reply-To: <1241297783.2226.4.camel@localhost.localdomain> References: <200905021352.16167.ville.skytta@iki.fi> <1241297783.2226.4.camel@localhost.localdomain> Message-ID: <49FD4A27.7050303@freenet.de> Lubomir Rintel wrote: > On Sat, 2009-05-02 at 13:52 +0300, Ville Skytt? wrote: > One subtle advantage of dynamic linking would be saving space by making > the executable image as well as text of the running process smaller, but > I guess in your case (trading space for performance) is a quite good > deal. The key word in your sentence is "subtile" ... How much performance gains does static linkage actually provide in this particular case? In the overwhelming majority of general cases, such kind of performance gains are close to immeasurable, distorted/overlayed by other effects (ld.so caches, ld.preload, disk caches, etc.) and hardly ever user noticeable. Ralf From lkundrak at v3.sk Sun May 3 12:49:07 2009 From: lkundrak at v3.sk (Lubomir Rintel) Date: Sun, 03 May 2009 14:49:07 +0200 Subject: [Fedora-packaging] Package-internal static linkage In-Reply-To: <49FD4A27.7050303@freenet.de> References: <200905021352.16167.ville.skytta@iki.fi> <1241297783.2226.4.camel@localhost.localdomain> <49FD4A27.7050303@freenet.de> Message-ID: <1241354947.7402.7.camel@bimbo.lan> On Sun, 2009-05-03 at 09:39 +0200, Ralf Corsepius wrote: > Lubomir Rintel wrote: > > On Sat, 2009-05-02 at 13:52 +0300, Ville Skytt? wrote: > > > One subtle advantage of dynamic linking would be saving space by making > > the executable image as well as text of the running process smaller, but > > I guess in your case (trading space for performance) is a quite good > > deal. > > The key word in your sentence is "subtile" ... > > How much performance gains does static linkage actually provide in this > particular case? > > In the overwhelming majority of general cases, such kind of > performance gains are close to immeasurable, distorted/overlayed by > other effects (ld.so caches, ld.preload, disk caches, etc.) and hardly > ever user noticeable. I tend to agree with you, hardly being able to imagine the PLT jumps add any real overhead unless the every third instruction is a jump to library function. I'd be interested to see the results of benchmarks upstream has done, unfortunately they don't provide those (which don't contribute to the credibility of the claim anyhow). Point is that there's nothing really seriously wrong against using the static linkage internally, especially when upstream decided so for a reason. Asking for the explanation for the reason once unclear might be a good idea though. -- "Excuse all the blood" -- Dead From gagadget at gmail.com Mon May 4 09:12:58 2009 From: gagadget at gmail.com (Gagadget) Date: Mon, 4 May 2009 11:12:58 +0200 Subject: [Fedora-packaging] Macro question for rpm gurus Message-ID: Dear listers, BIND has a version numbering system like this : Major.Medium.Minor-Ppatchlevel, with -Ppatchlevel only exists if patchlevel > 0. For instance, the source are named like that : bind-9.5.2-P2.tar.gz bind-9.6.0-P1.tar.gz bind-9.2.9.tar.gz I try to define a generic spec file for BIND packaging, here is what I did : %define VERSION 9.6.0 %define PATCHVER 1 [ ... ] %if %{PATCHVER} Source0: ftp://ftp.isc.org/isc/bind9/%{VERSION}-P%{PATCHVER}/bind-%{VERSION}-P%{PATCHVER}.tar.gz %else Source0: ftp://ftp.isc.org/isc/bind9/%{VERSION}/bind-%{VERSION}.tar.gz %endif It works, but I'd like to know if there is a more recursive way to avoid if/else ? Using "?" macro or something like that ? Regards, Gael. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mharris at mharris.ca Mon May 4 09:37:22 2009 From: mharris at mharris.ca (Mike A. Harris) Date: Mon, 04 May 2009 05:37:22 -0400 Subject: [Fedora-packaging] Re: Macro question for rpm gurus In-Reply-To: References: Message-ID: <49FEB752.3010206@mharris.ca> Gagadget wrote: > Dear listers, > > BIND has a version numbering system like this : > Major.Medium.Minor-Ppatchlevel, with -Ppatchlevel only exists if > patchlevel > 0. For instance, the source are named like that : > > bind-9.5.2-P2.tar.gz > bind-9.6.0-P1.tar.gz > bind-9.2.9.tar.gz > > I try to define a generic spec file for BIND packaging, here is what I did : > > %define VERSION 9.6.0 This define is redundant and unnecessary. Just put the version directly in the "Version:" tag, and rpm does the right thing. Version: 9.6.0 From gagadget at gmail.com Mon May 4 09:41:52 2009 From: gagadget at gmail.com (Gagadget) Date: Mon, 4 May 2009 11:41:52 +0200 Subject: [Fedora-packaging] Re: Macro question for rpm gurus In-Reply-To: <49FEB752.3010206@mharris.ca> References: <49FEB752.3010206@mharris.ca> Message-ID: 2009/5/4 Mike A. Harris > Gagadget wrote: > >> Dear listers, >> >> BIND has a version numbering system like this : >> Major.Medium.Minor-Ppatchlevel, with -Ppatchlevel only exists if patchlevel >> > 0. For instance, the source are named like that : >> >> bind-9.5.2-P2.tar.gz >> bind-9.6.0-P1.tar.gz >> bind-9.2.9.tar.gz >> >> I try to define a generic spec file for BIND packaging, here is what I did >> : >> >> %define VERSION 9.6.0 >> > > This define is redundant and unnecessary. Just put the version directly in > the "Version:" tag, and rpm does the right thing. > > Version: 9.6.0 > rpmbuild refuse to have "-" in Version tag. > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > -------------- next part -------------- An HTML attachment was scrubbed... URL: From enrico.scholz at informatik.tu-chemnitz.de Mon May 4 09:53:55 2009 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 04 May 2009 11:53:55 +0200 Subject: [Fedora-packaging] Re: Macro question for rpm gurus In-Reply-To: (gagadget@gmail.com's message of "Mon\, 4 May 2009 11\:12\:58 +0200") References: Message-ID: <871vr5kxcc.fsf@sheridan.bigo.ensc.de> Gagadget writes: > %define VERSION 9.6.0 > %define PATCHVER 1 > [ ... ] > %if %{PATCHVER} > Source0: > ftp://ftp.isc.org/isc/bind9/%{VERSION}-P%{PATCHVER}/bind-%{VERSION}-P%{PATCHVER}.tar.gz > %else > Source0: > ftp://ftp.isc.org/isc/bind9/%{VERSION}/bind-%{VERSION}.tar.gz > %endif > > It works, but I'd like to know if there is a more recursive way to avoid > if/else ? Using "?" macro or something like that ? %global XVER %VERSION%{?PATCHVER:-P%PATCHVER} Source0: ftp://ftp.isc.org/isc/bind9/%XVER/bind-%XVER.tar.gz and do not define 'PATCHVER 0' Enrico From gagadget at gmail.com Mon May 4 10:34:25 2009 From: gagadget at gmail.com (Gagadget) Date: Mon, 4 May 2009 12:34:25 +0200 Subject: [Fedora-packaging] Re: Macro question for rpm gurus In-Reply-To: <871vr5kxcc.fsf@sheridan.bigo.ensc.de> References: <871vr5kxcc.fsf@sheridan.bigo.ensc.de> Message-ID: 2009/5/4 Enrico Scholz > Gagadget writes: > > > %define VERSION 9.6.0 > > %define PATCHVER 1 > > [ ... ] > > %if %{PATCHVER} > > Source0: > > > ftp://ftp.isc.org/isc/bind9/%{VERSION}-P%{PATCHVER}/bind-%{VERSION}-P%{PATCHVER}.tar.gz > > %else > > Source0: > > ftp://ftp.isc.org/isc/bind9/%{VERSION}/bind-%{VERSION}.tar.gz > > %endif > > > > It works, but I'd like to know if there is a more recursive way to avoid > > if/else ? Using "?" macro or something like that ? > > %global XVER %VERSION%{?PATCHVER:-P%PATCHVER} > Source0: ftp://ftp.isc.org/isc/bind9/%XVER/bind-%XVER.tar.gz > > and do not define 'PATCHVER 0' > Thank you, here is what I did : %define VERSION 9.6.0 %define PATCHVER 1 %define DISTVER mylocaldist %define PKGVER 1 [...] Version: %{VERSION} Release: %{?PATCHVER:P%PATCHVER.}%{DISTVER}.%{PKGVER} [...] Source0: ftp://ftp.isc.org/isc/bind9/%{VERSION}%{?PATCHVER:-P%PATCHVER}/bind-%{VERSION}%{?PATCHVER:-P%PATCHVER}.tar.gz [...] %prep %setup -q -n %{name}-%{VERSION}%{?PATCHVER:-P%PATCHVER} I can't define a BINDVER or XVER because I want to have the Patchlevel in the Release tag, and it refuse the "-". With the above, my rpm is named bind-9.6.0-P1.mylocaldist.1 One question : If i do # %define PATCHVER 1 The PATCHVER is still define, I have to delete it to get it work ??? Is it normal ? > > Enrico > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.badger at gmail.com Mon May 4 14:05:28 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 04 May 2009 07:05:28 -0700 Subject: [Fedora-packaging] Re: Macro question for rpm gurus In-Reply-To: References: <871vr5kxcc.fsf@sheridan.bigo.ensc.de> Message-ID: <49FEF628.8090500@gmail.com> Gagadget wrote: > Thank you, here is what I did : > > %define VERSION 9.6.0 > %define PATCHVER 1 > %define DISTVER mylocaldist > %define PKGVER 1 > [...] > Version: %{VERSION} Since you are not using the "-" in the version, you can remove the %define VERSION 9.6.0 and just use: Version: 9.6.0 Then future references to version will be %{version} > Release: %{?PATCHVER:P%PATCHVER.}%{DISTVER}.%{PKGVER} > [...] > Source0: > ftp://ftp.isc.org/isc/bind9/%{VERSION}%{?PATCHVER:-P%PATCHVER}/bind-%{VERSION}%{?PATCHVER:-P%PATCHVER}.tar.gz > [...] > %prep > %setup -q -n %{name}-%{VERSION}%{?PATCHVER:-P%PATCHVER} > > I can't define a BINDVER or XVER because I want to have the Patchlevel > in the Release tag, and it refuse the "-". With the above, my rpm is > named bind-9.6.0-P1.mylocaldist.1 > > One question : > > If i do > # %define PATCHVER 1 > > The PATCHVER is still define, I have to delete it to get it work ??? Is > it normal ? > Yes. macros are expanded even in comments. You can do this instead: # %%define PATCHVER 1 -Toshio From gagadget at gmail.com Mon May 4 14:47:26 2009 From: gagadget at gmail.com (Gagadget) Date: Mon, 4 May 2009 16:47:26 +0200 Subject: [Fedora-packaging] Re: Macro question for rpm gurus In-Reply-To: <49FEF628.8090500@gmail.com> References: <871vr5kxcc.fsf@sheridan.bigo.ensc.de> <49FEF628.8090500@gmail.com> Message-ID: 2009/5/4 Toshio Kuratomi > Gagadget wrote: > > Thank you, here is what I did : > > > > %define VERSION 9.6.0 > > %define PATCHVER 1 > > %define DISTVER mylocaldist > > %define PKGVER 1 > > [...] > > Version: %{VERSION} > > Since you are not using the "-" in the version, you can remove the > %define VERSION 9.6.0 > > and just use: > Version: 9.6.0 > > Then future references to version will be %{version} > > > Release: %{?PATCHVER:P%PATCHVER.}%{DISTVER}.%{PKGVER} > > [...] > > Source0: > > > ftp://ftp.isc.org/isc/bind9/%{VERSION}%{?PATCHVER:-P%PATCHVER}/bind-%{VERSION}%{?PATCHVER:-P%PATCHVER}.tar.gz > > [...] > > %prep > > %setup -q -n %{name}-%{VERSION}%{?PATCHVER:-P%PATCHVER} > > > > I can't define a BINDVER or XVER because I want to have the Patchlevel > > in the Release tag, and it refuse the "-". With the above, my rpm is > > named bind-9.6.0-P1.mylocaldist.1 > > > > One question : > > > > If i do > > # %define PATCHVER 1 > > > > The PATCHVER is still define, I have to delete it to get it work ??? Is > > it normal ? > > > Yes. macros are expanded even in comments. You can do this instead: > > # %%define PATCHVER 1 > Thank you for all those precious information. > > -Toshio > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > -------------- next part -------------- An HTML attachment was scrubbed... URL: From enrico.scholz at informatik.tu-chemnitz.de Mon May 4 15:12:12 2009 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 04 May 2009 17:12:12 +0200 Subject: [Fedora-packaging] Re: Macro question for rpm gurus In-Reply-To: (gagadget@gmail.com's message of "Mon\, 4 May 2009 12\:34\:25 +0200") References: <871vr5kxcc.fsf@sheridan.bigo.ensc.de> Message-ID: <87ws8wkilv.fsf@sheridan.bigo.ensc.de> Gagadget writes: > If i do > # %define PATCHVER 1 > > The PATCHVER is still define, I have to delete it to get it work ??? Is it > normal ? yes; '#' does not affect macro definitions. I usually replace the '%' with '#'; e.g. -%define PATCHVER 1 +#define PATCHVER 1 Enrico From makowski.fedora at gmail.com Mon May 4 16:08:50 2009 From: makowski.fedora at gmail.com (philippe makowski) Date: Mon, 4 May 2009 18:08:50 +0200 Subject: [Fedora-packaging] php firebird extension Message-ID: Hi, Firebird (SQL relational database management system) will be soon packaged for Fedora I wanted to see if it is possible to add firebird exension to PHP The Mandriva package for this only do the following : %global modname firebird %global dirname interbase %global soname interbase.so %global inifile 42_%{modname}.ini Summary: Firebird database module for PHP Name: php-%{modname} Version: 5.2.6 Release: 0%{?dist} Group: Development/Libraries URL: http://www.php.net License: PHP License Source0: %{modname}.ini BuildRequires: php-devel >= 5.2.0 BuildRequires: firebird-devel Provides: php-interbase = %{version}-%{release} BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot %description This is a dynamic shared object (DSO) for PHP that will add Firebird database support. %prep %setup -c -T cp -dpR %{_usrsrc}/php-devel/extensions/%{dirname}/* . %build %serverbuild phpize %configure2_5x \ --with-libdir=%{_lib} \ --with-interbase=%{_libdir}/firebird but with Fedora it fails, it seems that php-devel don't have all PHP sources and cp -dpR %{_usrsrc}/php-devel/extensions/%{dirname}/* . don't work From ville.skytta at iki.fi Mon May 4 18:14:53 2009 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Mon, 4 May 2009 21:14:53 +0300 Subject: [Fedora-packaging] Package-internal static linkage In-Reply-To: <49FC5120.9070704@freenet.de> References: <200905021352.16167.ville.skytta@iki.fi> <49FC5120.9070704@freenet.de> Message-ID: <200905042114.56195.ville.skytta@iki.fi> On Saturday 02 May 2009, Ralf Corsepius wrote: > Ville Skytt? wrote: > > > ## Always link the command line tool statically against liblzma. It is > > ## faster on x86, because no need for PIC. We also have one dependency > > less, ## which allows users to more freely copy the xz binary to other > > boxes. > > Is this what they are telling you? Kind of, the above is what it says in src/xz/Makefile.am, above xz_LDFLAGS = -static. There's another similar -static setting in src/xzdec/Makefile.am. BTW, I didn't realize that xz conflicts pretty badly with lzma and isn't a 100% compatible replacement but knew that it isn't really necessarily ready for packaging yet - I did it for curiosity and to take look at what xz can currently do. In case someone's interested, the specfile I was working on is at http://scop.fedorapeople.org/packages/xz.spec (I've already forwarded this to the Fedora lzma maintainers). From Fedora at FamilleCollet.com Mon May 4 19:06:04 2009 From: Fedora at FamilleCollet.com (Remi Collet) Date: Mon, 04 May 2009 21:06:04 +0200 Subject: [Fedora-packaging] php firebird extension In-Reply-To: References: Message-ID: <49FF3C9C.5040006@FamilleCollet.com> Le 04/05/2009 18:08, philippe makowski a ?crit : > Hi, > > Firebird (SQL relational database management system) will be soon > packaged for Fedora > I wanted to see if it is possible to add firebird exension to PHP > The Mandriva package for this only do the following : Better/simpler solution will be to enable this extension during build of main php package (others extensions build from php source were merged in main package after core/extras merge) You can open a RFE against php for this and/or discuss about this in fedora-php-devel-list Regards. From mharris at mharris.ca Wed May 6 07:24:10 2009 From: mharris at mharris.ca (Mike A. Harris) Date: Wed, 06 May 2009 03:24:10 -0400 Subject: [Fedora-packaging] Re: php firebird extension In-Reply-To: References: Message-ID: <4A013B1A.70002@mharris.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 philippe makowski wrote: > Hi, > > Firebird (SQL relational database management system) will be soon > packaged for Fedora Heh, that should be interesting... Didn't the Mozilla folks get a cease and desist letter from a "Firebird" trademark owner just prior to changing Mozilla Firebird into Firefox? Rinse, repeat as often as necessary. ;o) - -- Mike A. Harris http://mharris.ca | https://twitter.com/mikeaharris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with CentOS - http://enigmail.mozdev.org iD8DBQFKATsY4RNf2rTIeUARAvn8AJ4xok/hf4Dge3P9XWjjX0XYmeWPyQCfcUC8 7LTkexFxxBrjC0MJhYLXxrc= =TR8L -----END PGP SIGNATURE----- From ivazqueznet at gmail.com Wed May 6 08:29:22 2009 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Wed, 06 May 2009 04:29:22 -0400 Subject: [Fedora-packaging] Re: php firebird extension In-Reply-To: <4A013B1A.70002@mharris.ca> References: <4A013B1A.70002@mharris.ca> Message-ID: <1241598563.12122.195.camel@ignacio.lan> On Wed, 2009-05-06 at 03:24 -0400, Mike A. Harris wrote: > philippe makowski wrote: > > Hi, > > > > Firebird (SQL relational database management system) will be soon > > packaged for Fedora > > Heh, that should be interesting... Didn't the Mozilla folks get a cease > and desist letter from a "Firebird" trademark owner just prior to > changing Mozilla Firebird into Firefox? > > Rinse, repeat as often as necessary. > > ;o) This is the software that provoked the name change. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From tmz at pobox.com Fri May 8 17:35:09 2009 From: tmz at pobox.com (Todd Zullinger) Date: Fri, 8 May 2009 13:35:09 -0400 Subject: [Fedora-packaging] Broken DistTag link in NamingGuidelines Message-ID: <20090508173509.GX4433@inocybe.localdomain> http://fedoraproject.org/wiki/Packaging:NamingGuidelines#DistTag says "please refer to the DistTag documentation..." but the DistTag text is not a link to http://fedoraproject.org/wiki/Packaging:DistTag, which makes it harder for folks to find the needed DistTag docs. :) -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Wedding is destiny, and hanging likewise. -- John Heywood -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From tibbs at math.uh.edu Fri May 8 18:21:50 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 08 May 2009 13:21:50 -0500 Subject: [Fedora-packaging] Broken DistTag link in NamingGuidelines In-Reply-To: <20090508173509.GX4433@inocybe.localdomain> (Todd Zullinger's message of "Fri\, 8 May 2009 13\:35\:09 -0400") References: <20090508173509.GX4433@inocybe.localdomain> Message-ID: Fixed. (The link wasn't broken, it just wasn't a link.) - J< From tmz at pobox.com Fri May 8 18:39:55 2009 From: tmz at pobox.com (Todd Zullinger) Date: Fri, 8 May 2009 14:39:55 -0400 Subject: [Fedora-packaging] Broken DistTag link in NamingGuidelines In-Reply-To: References: <20090508173509.GX4433@inocybe.localdomain> Message-ID: <20090508183955.GY4433@inocybe.localdomain> Jason L Tibbitts III wrote: > Fixed. Thanks. > (The link wasn't broken, it just wasn't a link.) Heh, I said "broken" as it used to be a link, and was lost in the wiki conversion. :) -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Cover a war in a place where you can't drink beer or talk to a woman? Hell no!" -- Hunter S. Thompson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From a.badger at gmail.com Fri May 8 20:06:24 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 08 May 2009 13:06:24 -0700 Subject: [Fedora-packaging] Pre-review Gudelines Message-ID: <4A0490C0.5010109@gmail.com> FESCo approved a request brought by rel-eng to allow a small set of packages to be checked into cvs and built only into a side tag before they pass review. Once they are building and brought up to standard, they would be put up for a full review and only then be built for the distribution. FESCo did say that there were certain review criteria that should be met before the packages could even get to that initial step of being checked into cvs and built for the side tag. They mentioned Not-from-source checks and legal issues as being in this category. We need to decide if there are additional Packaging Guidelines that need to be followed in order for the packages to pass prereview and push that recommendation to FESCo. It's also our job to document what those Guidelines are. I've made a start with this page: https://fedoraproject.org/wiki/Pre-review_Guidelines_(draft) It lists these Guidelines: * Licensing:Main * Packaging:LicensingGuidelines * Packaging:SourceURL * Packaging:Guidelines#No_inclusion_of_pre-built_binaries_or_libraries * Packaging:Guidelines#Duplication_of_system_libraries The main concerns that I think we're trying to protect against are: 1) Is it legal for Fedora to distribute this package? 2) Reducing the chances that the package is going to do something that could cause issues for the build system. A third concern that I have but depends on whether the packages in the side tag will be moved over to the dist tags or if they will be rebuilt fresh in the dist tag is: 3) Protecting the toolchain from being built with malicious code. If the packages are going to be rebuilt fresh with our existing toolchain after a full review is done, then this wouldn't be a big issue to me as the full review either will or will not catch it as normal. If the packages built into the side tag will be moved over to the dist tag (or simply added as a buildroot override for the dist tag) in order to bootstrap the new packages then I would be concerned. fnasser, do you know if you guys need bootstrapping or will things be built fresh? -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 tcallawa at redhat.com Fri May 8 20:40:53 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 08 May 2009 16:40:53 -0400 Subject: [Fedora-packaging] Pre-review Gudelines In-Reply-To: <4A0490C0.5010109@gmail.com> References: <4A0490C0.5010109@gmail.com> Message-ID: <4A0498D5.2040801@redhat.com> On 05/08/2009 04:06 PM, Toshio Kuratomi wrote: > FESCo approved a request brought by rel-eng to allow a small set of > packages to be checked into cvs and built only into a side tag before > they pass review. Once they are building and brought up to standard, > they would be put up for a full review and only then be built for the > distribution. Wouldn't koji scratch builds be sufficient? I'm not sure I understand the motivation behind this request. ~spot From fnasser at redhat.com Fri May 8 21:29:20 2009 From: fnasser at redhat.com (Fernando Nasser) Date: Fri, 08 May 2009 17:29:20 -0400 Subject: [Fedora-packaging] Re: Pre-review Gudelines In-Reply-To: <4A0490C0.5010109@gmail.com> References: <4A0490C0.5010109@gmail.com> Message-ID: <4A04A430.4050205@redhat.com> Toshio Kuratomi wrote: > (...) > > 3) Protecting the toolchain from being built with malicious code. > > If the packages are going to be rebuilt fresh with our existing > toolchain after a full review is done, then this wouldn't be a big issue > to me as the full review either will or will not catch it as normal. If > the packages built into the side tag will be moved over to the dist tag > (or simply added as a buildroot override for the dist tag) in order to > bootstrap the new packages then I would be concerned. > > fnasser, do you know if you guys need bootstrapping or will things be > built fresh? > > Hi Toshio, Once they are boostrapped in the side tag, they need to be mass-tagged in the the main tag so we can just rebuild them (I suggest the side tag uses a different dist tag for clarity). If we would do the same process in the main tag we'd run into the same problem of having an unusable maven2 while the bootstrap process is going (it takes a while), which is just what we want to avoid with the side tag. We have a working maven2 2.0.4. It is old and no longer builds the new versions of things we need to build (for eclipse for instance), but it works and builds the current packages we have. We don't want to risk and have a broken toolchain for any period of time, so the side tag. Best regards, Fernando From dbhole at redhat.com Fri May 8 21:55:04 2009 From: dbhole at redhat.com (Deepak Bhole) Date: Fri, 8 May 2009 17:55:04 -0400 Subject: [Fedora-packaging] Pre-review Gudelines In-Reply-To: <4A0498D5.2040801@redhat.com> References: <4A0490C0.5010109@gmail.com> <4A0498D5.2040801@redhat.com> Message-ID: <20090508215504.GB11705@redhat.com> * Tom spot Callaway [2009-05-08 16:43]: > On 05/08/2009 04:06 PM, Toshio Kuratomi wrote: > > FESCo approved a request brought by rel-eng to allow a small set of > > packages to be checked into cvs and built only into a side tag before > > they pass review. Once they are building and brought up to standard, > > they would be put up for a full review and only then be built for the > > distribution. > > Wouldn't koji scratch builds be sufficient? I'm not sure I understand > the motivation behind this request. > Hi Tom, A scratch build wouldn't be sufficient in case of maven due to the sheer number of packages involved in the upgrade. When I worked on the maven 2.0.4 (current version in Fedora) to 2.0.8, this is the most efficient route I could find: -> yum install "maven2*" (installs 2.0.4) install tomcat5-servlet-2.4-api, tomcat5, geronimo-specs b+i maven2-common-poms b+i maven-wagon b+i saxpath b+i backport-util-concurrent b+i bndlib b+i pmd b+i plexus-classworlds b+i plexus-utils b+i plexus-containers b+i modello a15 b+i itext b+i plexus-cdc b+i plexus-maven-plugin b+i plexus-xmlrpc b+i plexus-cli b+i plexus-digest b+i dumbster b+i plexus-mail-sender b+i plexus-velocity b+i directory-naming b+i jakarta-commons-jxpath b+i jakarta-commons-configuration b+i jakarta-commons-dbcp b+i easymock b+i javacvs -> build maven2 in bootstrap mode (--with bootstrap), install that copy b+i maven-surefire b+i maven2-plugin-shade b+i plexus-resources b+i plexus-naming b+i plexus-registry b+i maven-doxia b+i maven-doxia-sitetools b+i maven-shared b+i maven-plugin-tools b+i maven-embedder b+i maven-scm b+i maven-enforcer-rule-api b+i maven-archiver Where b+i => build and then install Many of the packages mentioned above are new or need upgrades. Due to the complex interdependencies, it would be much easier to have a separate tag into which the above instructions are followed. It will allow for easy initial reviews and sanity checks. Cheers, Deepak > ~spot > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging From a.badger at gmail.com Fri May 8 22:43:24 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 08 May 2009 15:43:24 -0700 Subject: [Fedora-packaging] Pre-review Gudelines In-Reply-To: <20090508215504.GB11705@redhat.com> References: <4A0490C0.5010109@gmail.com> <4A0498D5.2040801@redhat.com> <20090508215504.GB11705@redhat.com> Message-ID: <4A04B58C.30708@gmail.com> Deepak Bhole wrote: > -> build maven2 in bootstrap mode (--with bootstrap), install that copy Hey Deepak, So from the discussion we had on IRC, I added a note that maven2 itself will need to bootstrap itself with binaries from its tarball. But I looked on the maven2 website and saw that they suggest bootstrapping with ant and then rebuilding with the newly built maven2: http://maven.apache.org/guides/development/guide-building-m2.html Is there some reason that those instructions don't work now? -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 dbhole at redhat.com Fri May 8 23:01:46 2009 From: dbhole at redhat.com (Deepak Bhole) Date: Fri, 8 May 2009 19:01:46 -0400 Subject: [Fedora-packaging] Pre-review Gudelines In-Reply-To: <4A04B58C.30708@gmail.com> References: <4A0490C0.5010109@gmail.com> <4A0498D5.2040801@redhat.com> <20090508215504.GB11705@redhat.com> <4A04B58C.30708@gmail.com> Message-ID: <20090508230146.GA15256@redhat.com> * Toshio Kuratomi [2009-05-08 18:45]: > Deepak Bhole wrote: > > -> build maven2 in bootstrap mode (--with bootstrap), install that copy > > Hey Deepak, > > So from the discussion we had on IRC, I added a note that maven2 itself > will need to bootstrap itself with binaries from its tarball. But I > looked on the maven2 website and saw that they suggest bootstrapping > with ant and then rebuilding with the newly built maven2: > > http://maven.apache.org/guides/development/guide-building-m2.html > > Is there some reason that those instructions don't work now? > Hi Toshio, We could use the ant build, but it offers no real advantage. The ant build still downloads the jars that we package in the tarball. There is no way around those dependencies. While using ant may knock off a very small subset of jars from the bootstrap tarball, it will vastly increase maintenance as we would have to set it up so that each version of each dependency is acquired from a local source. Cheers, Deepak From a.badger at gmail.com Fri May 8 23:14:04 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 08 May 2009 16:14:04 -0700 Subject: [Fedora-packaging] Pre-review Gudelines In-Reply-To: <20090508230146.GA15256@redhat.com> References: <4A0490C0.5010109@gmail.com> <4A0498D5.2040801@redhat.com> <20090508215504.GB11705@redhat.com> <4A04B58C.30708@gmail.com> <20090508230146.GA15256@redhat.com> Message-ID: <4A04BCBC.5070407@gmail.com> Deepak Bhole wrote: > * Toshio Kuratomi [2009-05-08 18:45]: >> So from the discussion we had on IRC, I added a note that maven2 itself >> will need to bootstrap itself with binaries from its tarball. But I >> looked on the maven2 website and saw that they suggest bootstrapping >> with ant and then rebuilding with the newly built maven2: >> >> http://maven.apache.org/guides/development/guide-building-m2.html >> >> Is there some reason that those instructions don't work now? >> > We could use the ant build, but it offers no real advantage. The ant build > still downloads the jars that we package in the tarball. There is no way > around those dependencies. While using ant may knock off a > very small subset of jars from the bootstrap tarball, it will vastly > increase maintenance as we would have to set it up so that each version > of each dependency is acquired from a local source. > Actually, it shouldn't. The koji buildroot shouldn't have network access so it will just fail. What's in the jars that are being used to bootstrap? It sounds as though it's not just maven itself? -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 Fri May 8 23:15:31 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 08 May 2009 18:15:31 -0500 Subject: [Fedora-packaging] Pre-review Gudelines In-Reply-To: <4A0490C0.5010109@gmail.com> (Toshio Kuratomi's message of "Fri\, 08 May 2009 13\:06\:24 -0700") References: <4A0490C0.5010109@gmail.com> Message-ID: >>>>> "TK" == Toshio Kuratomi writes: TK> FESCo approved a request brought by rel-eng to allow a small set TK> of packages to be checked into cvs and built only into a side tag TK> before they pass review. Uh, why? If the review process is broken surely there's a better way to address that than just saying that select packages just get to bypass it. The only justification I can think of would be that the packages have to go in absolutely immediately. But there was time for FESCo to meet about it, so that must not be the case. I may not be doing many reviews lately and may be a bit behind on the reviews that I'm doing, but if someone pinged and say that they had an emergency and needed something reviewed right away, I'd do whatever I possibly could. - J< From fnasser at redhat.com Fri May 8 23:32:40 2009 From: fnasser at redhat.com (Fernando Nasser) Date: Fri, 08 May 2009 19:32:40 -0400 Subject: [Fedora-packaging] Pre-review Gudelines In-Reply-To: <4A04BCBC.5070407@gmail.com> References: <4A0490C0.5010109@gmail.com> <4A0498D5.2040801@redhat.com> <20090508215504.GB11705@redhat.com> <4A04B58C.30708@gmail.com> <20090508230146.GA15256@redhat.com> <4A04BCBC.5070407@gmail.com> Message-ID: <4A04C118.2050700@redhat.com> Toshio Kuratomi wrote: > Deepak Bhole wrote: > >> * Toshio Kuratomi [2009-05-08 18:45]: >> >>> So from the discussion we had on IRC, I added a note that maven2 itself >>> will need to bootstrap itself with binaries from its tarball. But I >>> looked on the maven2 website and saw that they suggest bootstrapping >>> with ant and then rebuilding with the newly built maven2: >>> >>> http://maven.apache.org/guides/development/guide-building-m2.html >>> >>> Is there some reason that those instructions don't work now? >>> >>> >> We could use the ant build, but it offers no real advantage. The ant build >> still downloads the jars that we package in the tarball. There is no way >> around those dependencies. While using ant may knock off a >> very small subset of jars from the bootstrap tarball, it will vastly >> increase maintenance as we would have to set it up so that each version >> of each dependency is acquired from a local source. >> >> > Actually, it shouldn't. The koji buildroot shouldn't have network > access so it will just fail. > > What's in the jars that are being used to bootstrap? It sounds as > though it's not just maven itself? > Toshio, Maven itself doesn't do anything, it just call things in a certain order than can be configured if you can't just use the default. Everything is done by plugins, each with its independent lifecycle. A small set comes with maven but others are extenal. To build anything one needs many of those plugins, to build maven fully, most of them, so the set of packages in Deepak's list. You cannot build maven in full without all of those, and those packages do not build fully without a full maven and to make things worse these packages cannot be built without several of the others (and yes, there are circular dependencies). We go building thought that list 3 times! This is simple for the Apache folks as their build just grab binaries from the main maven repository and versions evolve daily by using SNAPSHOT releases, they never encounter the need to build using only a previous release set. At the end of it day they move their latest stuff closer to the next release, incrementally (yes, a change in a plugin breaks others that have to adjust). Regards, Fernando From jkeating at redhat.com Sat May 9 02:03:14 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 08 May 2009 19:03:14 -0700 Subject: [Fedora-packaging] Pre-review Gudelines In-Reply-To: References: <4A0490C0.5010109@gmail.com> Message-ID: <1241834594.2886.28.camel@localhost.localdomain> On Fri, 2009-05-08 at 18:15 -0500, Jason L Tibbitts III wrote: > Uh, why? If the review process is broken surely there's a better way > to address that than just saying that select packages just get to > bypass it. > > The only justification I can think of would be that the packages have > to go in absolutely immediately. But there was time for FESCo to meet > about it, so that must not be the case. I may not be doing many > reviews lately and may be a bit behind on the reviews that I'm doing, > but if someone pinged and say that they had an emergency and needed > something reviewed right away, I'd do whatever I possibly could. I'm told that in this case, the problem is getting packaging people to fix up the packaging issues with the software, not the reviewer side. The java team wished to move forward and get packages beat into shape as they find issues building the whole mess together before they concentrate on the packaging aspects of it. The timing worked out in that Fernando asked me today about it, and a FESCo meeting happened today. They're trying to get work started on Monday (in China no less). -- 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 tibbs at math.uh.edu Sat May 9 06:14:41 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sat, 09 May 2009 01:14:41 -0500 Subject: [Fedora-packaging] Pre-review Gudelines In-Reply-To: <1241834594.2886.28.camel@localhost.localdomain> (Jesse Keating's message of "Fri\, 08 May 2009 19\:03\:14 -0700") References: <4A0490C0.5010109@gmail.com> <1241834594.2886.28.camel@localhost.localdomain> Message-ID: >>>>> "JK" == Jesse Keating writes: JK> I'm told that in this case, the problem is getting packaging JK> people to fix up the packaging issues with the software, not the JK> reviewer side. And I suppose the problem is that they can't build the packages down in the chain because they have no private builder instance, so they need to use the actual distro buildsys with their stack already tagged into it. That seems, well, sort of an abuse of the system. I guess there's not much else to do if there's no free developer time to cobble together another solution, but can folks honestly say that this is really the way that we'd like things to work? And if not, then do we really want to go through the whole process of cooking up guidelines for it? It seems to me that ideally there'd either be some other koji instance or some way to get the main buildsys to associate a tag with an external repository so that they could build up their stack with their own packages without actually having to get those packages into the main collection. Actually, that would be really useful in general. - J< From pertusus at free.fr Sat May 9 09:45:06 2009 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 9 May 2009 11:45:06 +0200 Subject: [Fedora-packaging] Pre-review Gudelines In-Reply-To: References: <4A0490C0.5010109@gmail.com> <1241834594.2886.28.camel@localhost.localdomain> Message-ID: <20090509094506.GA4000@free.fr> On Sat, May 09, 2009 at 01:14:41AM -0500, Jason L Tibbitts III wrote: > >>>>> "JK" == Jesse Keating writes: > > That seems, well, sort of an abuse of the system. I guess there's not I don't think this i an abuse of the system, but I don't think this is related with packaging. FESCo/infras/whoever entitled can accept that Fedora builders are used for building any package (with special tags such that they don't end up in the collection, only on the builders or something like that), but this has nothing to do with packaging guidelines, in my opinion. Packages still need to be reviewed as usual. -- Pat From rjones at redhat.com Sat May 9 11:29:25 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Sat, 9 May 2009 12:29:25 +0100 Subject: [Fedora-packaging] Pre-review Gudelines In-Reply-To: <1241834594.2886.28.camel@localhost.localdomain> References: <4A0490C0.5010109@gmail.com> <1241834594.2886.28.camel@localhost.localdomain> Message-ID: <20090509112925.GA18888@amd.home.annexia.org> On Fri, May 08, 2009 at 07:03:14PM -0700, Jesse Keating wrote: > The java team wished to move forward and get packages beat into shape as > they find issues building the whole mess together before they > concentrate on the packaging aspects of it. That's a terrible excuse! With mingw we built the whole chain, nearly a hundred packages, outside the distribution before we submitted a single package to Fedora. In fact, we had a rolling build which built the whole chain against (at the time) Fedora 8, 9, 10 on i386 and x86_64. We even wrote a new tool (smock[1]) to automate the process. Rich. [1] http://hg.et.redhat.com/cgi-bin/hg-misc.cgi/fedora-mingw--devel/file/tip/smock -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw From jussi.lehtola at iki.fi Sat May 9 13:24:58 2009 From: jussi.lehtola at iki.fi (Jussi Lehtola) Date: Sat, 09 May 2009 16:24:58 +0300 Subject: [Fedora-packaging] Java guideline inconsistency Message-ID: <1241875498.1556.3.camel@localhost.localdomain> Hi, there seems to be an inconsistency with the Java guidelines: http://fedoraproject.org/wiki/Packaging/Java http://fedoraproject.org/wiki/Packaging/Java#Jar_file_naming states that if the package only contains a single .jar file it should have the same name as the package, but the ant and maven spec file templates install .jar files as cp -p [build path to jar] \ $RPM_BUILD_ROOT%{_javadir}/%{name}-%{version}.jar Also, I find it a bit inconsistent that java packages don't have to have a java- prefix as python, perl, php and so on packages have to. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From lemenkov at gmail.com Sat May 9 13:33:01 2009 From: lemenkov at gmail.com (Peter Lemenkov) Date: Sat, 9 May 2009 17:33:01 +0400 Subject: [Fedora-packaging] Java guideline inconsistency In-Reply-To: <1241875498.1556.3.camel@localhost.localdomain> References: <1241875498.1556.3.camel@localhost.localdomain> Message-ID: Hello All! 2009/5/9 Jussi Lehtola : [sorry, skipped] > Also, I find it a bit inconsistent that java packages don't have to have > a java- prefix as python, perl, php and so on packages have to. I'm afraid that the idea with adding such prefixes was (and is) very stupid. In order to separate lang-specific packages (except sub-packages, like someapp-somelang) we should add more rpm groups, like Development/Languages/FooLang -- With best regards! From jussi.lehtola at iki.fi Sat May 9 13:38:59 2009 From: jussi.lehtola at iki.fi (Jussi Lehtola) Date: Sat, 09 May 2009 16:38:59 +0300 Subject: [Fedora-packaging] Java guideline inconsistency In-Reply-To: References: <1241875498.1556.3.camel@localhost.localdomain> Message-ID: <1241876339.1556.5.camel@localhost.localdomain> On Sat, 2009-05-09 at 17:33 +0400, Peter Lemenkov wrote: > Hello All! > > 2009/5/9 Jussi Lehtola : > > [sorry, skipped] > > > Also, I find it a bit inconsistent that java packages don't have to have > > a java- prefix as python, perl, php and so on packages have to. > > I'm afraid that the idea with adding such prefixes was (and is) very > stupid. In order to separate lang-specific packages (except > sub-packages, like someapp-somelang) we should add more rpm groups, > like Development/Languages/FooLang Quite on the contrary. I think prefixes are quite useful, since many language specific packages might have otherwise conflicting names, e.g. I could imagine python-argparse, java-argparse and so on. RPM groups, on the other hand, aren't used for anything any more: comps are used instead. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From lemenkov at gmail.com Sat May 9 13:46:10 2009 From: lemenkov at gmail.com (Peter Lemenkov) Date: Sat, 9 May 2009 17:46:10 +0400 Subject: [Fedora-packaging] Java guideline inconsistency In-Reply-To: <1241876339.1556.5.camel@localhost.localdomain> References: <1241875498.1556.3.camel@localhost.localdomain> <1241876339.1556.5.camel@localhost.localdomain> Message-ID: 2009/5/9 Jussi Lehtola : > Quite on the contrary. I think prefixes are quite useful, since many > language specific packages might have otherwise conflicting names Not a names, but a *filenames*. This should be fixed as well - I don't think that there is a reason to maintain correspondence between %name field and the resulting rpm's filenames (or even to maintain human-readable rpm filenames), at least in main repositories. -- With best regards! From lemenkov at gmail.com Sat May 9 13:47:29 2009 From: lemenkov at gmail.com (Peter Lemenkov) Date: Sat, 9 May 2009 17:47:29 +0400 Subject: [Fedora-packaging] Java guideline inconsistency In-Reply-To: <1241876339.1556.5.camel@localhost.localdomain> References: <1241875498.1556.3.camel@localhost.localdomain> <1241876339.1556.5.camel@localhost.localdomain> Message-ID: 2009/5/9 Jussi Lehtola : > RPM groups, on the other hand, aren't used for anything any more: comps > are used instead. Whatever - rpm groups/comps/labels/tags. -- With best regards! From jkeating at redhat.com Sat May 9 15:41:45 2009 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 09 May 2009 08:41:45 -0700 Subject: [Fedora-packaging] Pre-review Gudelines In-Reply-To: References: <4A0490C0.5010109@gmail.com> <1241834594.2886.28.camel@localhost.localdomain> Message-ID: <1241883705.2886.56.camel@localhost.localdomain> On Sat, 2009-05-09 at 01:14 -0500, Jason L Tibbitts III wrote: > > It seems to me that ideally there'd either be some other koji instance > or some way to get the main buildsys to associate a tag with an > external repository so that they could build up their stack with their > own packages without actually having to get those packages into the > main collection. Actually, that would be really useful in general. Well we do now have external repo support so in theory we could have added an external repo to dist-f12-maven, done scratch builds of the newer bits and tossed them manually in the side repo. But what does that really accomplish? The packages are still going to get sucked into Koji buildroots for dist-f12-maven, and builds are still going to be tagged with dist-f12-maven, and private CVS branches are still going to be made of packages to work in this tag. What we're asking is a bit of leeway on getting a few new packages into the cvs repo to work on (we can put empty content or some other info content in devel/ and use a private cvs branch to have the actual .spec and such being worked on) so that they can easily be used while working on the rest of the maven update. When the packages are working well together, then they'd like to submit them for review. -- 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 jkeating at redhat.com Sat May 9 15:43:03 2009 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 09 May 2009 08:43:03 -0700 Subject: [Fedora-packaging] Pre-review Gudelines In-Reply-To: <20090509112925.GA18888@amd.home.annexia.org> References: <4A0490C0.5010109@gmail.com> <1241834594.2886.28.camel@localhost.localdomain> <20090509112925.GA18888@amd.home.annexia.org> Message-ID: <1241883783.2886.57.camel@localhost.localdomain> On Sat, 2009-05-09 at 12:29 +0100, Richard W.M. Jones wrote: > That's a terrible excuse! With mingw we built the whole chain, nearly > a hundred packages, outside the distribution before we submitted a > single package to Fedora. In fact, we had a rolling build which built > the whole chain against (at the time) Fedora 8, 9, 10 on i386 and > x86_64. > > We even wrote a new tool (smock[1]) to automate the process. Excuse or not, it's what they asked me if they could do. I fine tuned their request to have minimal impact upon the rest of the infrastructure and forwarded the request along to FESCo. FESCo approved it, and asked that the Packaging Committee come up with the bare level pre-review items to clear out, such as legal and build from source issues. -- 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 a.badger at gmail.com Sat May 9 17:11:15 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 09 May 2009 10:11:15 -0700 Subject: [Fedora-packaging] Java guideline inconsistency In-Reply-To: References: <1241875498.1556.3.camel@localhost.localdomain> <1241876339.1556.5.camel@localhost.localdomain> Message-ID: <4A05B933.6090202@gmail.com> Peter Lemenkov wrote: > 2009/5/9 Jussi Lehtola : > >> Quite on the contrary. I think prefixes are quite useful, since many >> language specific packages might have otherwise conflicting names > > Not a names, but a *filenames*. This should be fixed as well - I don't > think that there is a reason to maintain correspondence between %name > field and the resulting rpm's filenames (or even to maintain > human-readable rpm filenames), at least in main repositories. > There isn't a correspondence. Or rather, the correspondence you see is entirely cosmetic. the rpm _filenames_ are entirely for the convenience of the humans who have to deal with them. The rpm Name attribute is what rpm, yum, and the package manager depend on. And conflicts between the rpm Name attribute are very bad. If we had two different packages with Name: argparse and one was a library for java and one was for python we could rename the filenames so that they can both exist in the repositories. But the moment you go to install them you have a conflicting rpm name and have problems: * Which of the two packages will be installed when you run yum install argparse? * How do you install both packages at the same time? * How do you prevent one package from upgrading the other package since the name is the same in the rpm database? and so on and so forth. -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 a.badger at gmail.com Sat May 9 17:24:37 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 09 May 2009 10:24:37 -0700 Subject: [Fedora-packaging] Java guideline inconsistency In-Reply-To: <1241875498.1556.3.camel@localhost.localdomain> References: <1241875498.1556.3.camel@localhost.localdomain> Message-ID: <4A05BC55.10204@gmail.com> Jussi Lehtola wrote: > Hi, > > > there seems to be an inconsistency with the Java guidelines: > http://fedoraproject.org/wiki/Packaging/Java > > http://fedoraproject.org/wiki/Packaging/Java#Jar_file_naming states that > if the package only contains a single .jar file it should have the same > name as the package, but the ant and maven spec file templates > install .jar files as > > cp -p [build path to jar] \ > $RPM_BUILD_ROOT%{_javadir}/%{name}-%{version}.jar > I would lean towards Java#Jar_file_naming being clarified but I'm not a java guy. Andrew, Fernando, Deepak, someone want to write up a clarification of this? > > Also, I find it a bit inconsistent that java packages don't have to have > a java- prefix as python, perl, php and so on packages have to. I do to but I think this is the standard for enough packages that we shouldn't look at fixing it unless it's causing breakage. -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 overholt at redhat.com Sat May 9 20:44:11 2009 From: overholt at redhat.com (Andrew Overholt) Date: Sat, 9 May 2009 16:44:11 -0400 Subject: [Fedora-packaging] Java guideline inconsistency In-Reply-To: <4A05BC55.10204@gmail.com> References: <1241875498.1556.3.camel@localhost.localdomain> <4A05BC55.10204@gmail.com> Message-ID: <20090509204410.GA19362@redhat.com> * Toshio Kuratomi [2009-05-09 13:25]: > Jussi Lehtola wrote: > > > > there seems to be an inconsistency with the Java guidelines: > > http://fedoraproject.org/wiki/Packaging/Java > > > > http://fedoraproject.org/wiki/Packaging/Java#Jar_file_naming states that > > if the package only contains a single .jar file it should have the same > > name as the package, but the ant and maven spec file templates > > install .jar files as > > > > cp -p [build path to jar] \ > > $RPM_BUILD_ROOT%{_javadir}/%{name}-%{version}.jar > > > I would lean towards Java#Jar_file_naming being clarified but I'm not a > java guy. Andrew, Fernando, Deepak, someone want to write up a > clarification of this? Sure, I'll speak about this with Deepak and others and get something written up. > > Also, I find it a bit inconsistent that java packages don't have to have > > a java- prefix as python, perl, php and so on packages have to. > > I do to but I think this is the standard for enough packages that we > shouldn't look at fixing it unless it's causing breakage. Agreed. Most (all?) of this stuff came from JPackage and there's little point in breaking compatibility/naming. Andrew From fnasser at redhat.com Sat May 9 22:41:36 2009 From: fnasser at redhat.com (Fernando Nasser) Date: Sat, 9 May 2009 18:41:36 -0400 (EDT) Subject: [Fedora-packaging] Java guideline inconsistency In-Reply-To: <950572384.44781241908840320.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <217235831.44801241908896408.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Hi guys, I wouldn't waste much time on this. The new "de facto" standard for installation is the one defined by Maven anyway. Even Java software that does not build with Maven grabs data from maven repositories these days (with Ant , or something else). JPP 6, RHEL-based products and future Fedora Java package updates will all install the JARs following strictly the Maven standard layout with unversioned symlinks. One of the advantages of this is that it does not require any maven patch (although I'd like to keep the depmap) and facilitates regular (non-RPM) maven builds by developers. Another is that a maven repo installed with RPMs can be made available as a multi-platform remote Maven repository. Last but not least, it greatly facilitates parallel installation of diferent versions. Although that is not recommended, we have some unavoidable cases so better account for them. We will need to keep some of the old JAR file names as deprecated for a release or so for backwads compatibility or while the conversion takes place, but these are exactly like Jussi wants, unversioned. Some preliminary tests were already made with good results. Once we have ironed out some last details (I'd like a simpler mvn command line invocation for one thing and some scripts in jpackage-utils have to be enhanced or added) I can post a basic description of how each package should install its JARs for this to work. I need to find a good link describing the default maven repository layout as reference to keep it simple and authoritative. Regards to all, Fernando ----- Original Message ----- From: "Andrew Overholt" To: "Discussion of RPM packaging standards and practices for Fedora" Sent: Saturday, May 9, 2009 4:44:11 PM GMT -05:00 US/Canada Eastern Subject: Re: [Fedora-packaging] Java guideline inconsistency * Toshio Kuratomi [2009-05-09 13:25]: > Jussi Lehtola wrote: > > > > there seems to be an inconsistency with the Java guidelines: > > http://fedoraproject.org/wiki/Packaging/Java > > > > http://fedoraproject.org/wiki/Packaging/Java#Jar_file_naming states that > > if the package only contains a single .jar file it should have the same > > name as the package, but the ant and maven spec file templates > > install .jar files as > > > > cp -p [build path to jar] \ > > $RPM_BUILD_ROOT%{_javadir}/%{name}-%{version}.jar > > > I would lean towards Java#Jar_file_naming being clarified but I'm not a > java guy. Andrew, Fernando, Deepak, someone want to write up a > clarification of this? Sure, I'll speak about this with Deepak and others and get something written up. > > Also, I find it a bit inconsistent that java packages don't have to have > > a java- prefix as python, perl, php and so on packages have to. > > I do to but I think this is the standard for enough packages that we > shouldn't look at fixing it unless it's causing breakage. Agreed. Most (all?) of this stuff came from JPackage and there's little point in breaking compatibility/naming. Andrew -- Fedora-packaging mailing list Fedora-packaging at redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging From fnasser at redhat.com Sat May 9 22:59:39 2009 From: fnasser at redhat.com (Fernando Nasser) Date: Sat, 9 May 2009 18:59:39 -0400 (EDT) Subject: [Fedora-packaging] Java guideline inconsistency In-Reply-To: <1875937062.44901241909758862.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <1940051252.45001241909979238.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> I think this is a bit pertinent to the discussion so I thought I should mention it. A few Java developer communities have contacted jpackage.org in the past (some contacted myself personally) asking for the organization name to be used as a prefix. One of these was ObjectWeb. Have you noticed that asm became objectwb-asm? We have a conflict (I believe not on Fedora) with a package called hibernate. The conflict is not happening by chance, as the Java hibenate package was made hibernate3 when the release 3 appeared and the 2 was stil around. Conveniently, I have been recently questioned by some JBoss person why the package was not called jboss-hibernate. Maybe we should oblige :-) There are lots of Java packages that already follow this practice in most Linux distros and we ourselves have the jakarta-* and apache-* and geronimo-* and so on. So we are basically covered on the "N" side of things. The JAR file names are not a problem as they go under %{_javadir} and won't conflict with non-Jva packages (no more .so's with OpenJDK), The only remaining conflicts are for commands (wrapper scripts mostly for Java) that are installed in /usr/bin. Not all Java packages have scripts there though. In theory some SysV init scripts or /etc/sysconfig/ stuff could collide too, but in all these years we had no such case and we can always bury it under a subdirectory with the package name, so in practice only /usr/bin commands can conflict. One of the conflicting commands will have to be renamed if this ever happens. Note that this is not exclusive of Java, any two softwares written in any two languages can decide to call a command "twitter" for instance. Regards, Fernando ----- Original Message ----- From: "Toshio Kuratomi" To: "Discussion of RPM packaging standards and practices for Fedora" Sent: Saturday, May 9, 2009 1:11:15 PM GMT -05:00 US/Canada Eastern Subject: Re: [Fedora-packaging] Java guideline inconsistency Peter Lemenkov wrote: > 2009/5/9 Jussi Lehtola : > >> Quite on the contrary. I think prefixes are quite useful, since many >> language specific packages might have otherwise conflicting names > > Not a names, but a *filenames*. This should be fixed as well - I don't > think that there is a reason to maintain correspondence between %name > field and the resulting rpm's filenames (or even to maintain > human-readable rpm filenames), at least in main repositories. > There isn't a correspondence. Or rather, the correspondence you see is entirely cosmetic. the rpm _filenames_ are entirely for the convenience of the humans who have to deal with them. The rpm Name attribute is what rpm, yum, and the package manager depend on. And conflicts between the rpm Name attribute are very bad. If we had two different packages with Name: argparse and one was a library for java and one was for python we could rename the filenames so that they can both exist in the repositories. But the moment you go to install them you have a conflicting rpm name and have problems: * Which of the two packages will be installed when you run yum install argparse? * How do you install both packages at the same time? * How do you prevent one package from upgrading the other package since the name is the same in the rpm database? and so on and so forth. -Toshio -- Fedora-packaging mailing list Fedora-packaging at redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging From shakthimaan at gmail.com Sun May 10 13:10:50 2009 From: shakthimaan at gmail.com (Shakthi Kannan) Date: Sun, 10 May 2009 18:40:50 +0530 Subject: [Fedora-packaging] Packaging RPM presentation Message-ID: Hi, I have tried to make a simple presentation on packaging RPM. Can you please go through the following, and let me know if I have missed something, or there is anything that I overlooked (that needs changes), or something that will be good to include in the following? http://shakthimaan.com/downloads/glv/presentations/packaging-red-hot-paneer-butter-masala.pdf The sources are available at: http://shakthimaan.com/downloads/glv/presentations/packaging-red-hot-paneer-butter-masala.tar.gz Thanks! SK -- Shakthi Kannan http://www.shakthimaan.com From jonstanley at gmail.com Sun May 10 13:45:49 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Sun, 10 May 2009 09:45:49 -0400 Subject: [Fedora-packaging] Packaging RPM presentation In-Reply-To: References: Message-ID: On Sun, May 10, 2009 at 9:10 AM, Shakthi Kannan wrote: > I have tried to make a simple presentation on packaging RPM. Can you > please go through the following, and let me know if I have missed It's um, creative. But what's wrong with spot's existing presentation? http://spot.fedorapeople.org/Summit2008/ From shakthimaan at gmail.com Sun May 10 15:12:53 2009 From: shakthimaan at gmail.com (Shakthi Kannan) Date: Sun, 10 May 2009 20:42:53 +0530 Subject: [Fedora-packaging] Packaging RPM presentation In-Reply-To: References: Message-ID: Hi, --- On Sun, May 10, 2009 at 7:15 PM, Jon Stanley wrote: |?But what's wrong with spot's ?existing presentation? \-- No masala? Just kidding. Well, I didn't know about spot's presentation. I didn't want to call it yet another rpm presentation. I also wanted to display outputs, with some sort of work flow, and syntax highlighting, so I could walk through with the process. Regards, SK -- Shakthi Kannan http://www.shakthimaan.com From overholt at redhat.com Sun May 10 04:17:47 2009 From: overholt at redhat.com (Andrew Overholt) Date: Sun, 10 May 2009 00:17:47 -0400 Subject: [Fedora-packaging] Java guideline inconsistency In-Reply-To: <1940051252.45001241909979238.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> References: <1875937062.44901241909758862.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <1940051252.45001241909979238.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <20090510041747.GA20251@redhat.com> * Fernando Nasser [2009-05-09 18:59]: > (no more .so's with OpenJDK), The gcj .so files have never conflicted as they are in /usr/lib{,64}/gcj/ since they're not .so filess you'd want to link. Andrew From skasal at redhat.com Mon May 11 13:30:58 2009 From: skasal at redhat.com (Stepan Kasal) Date: Mon, 11 May 2009 15:30:58 +0200 Subject: [Fedora-packaging] Java -- how to use jni.h Message-ID: <20090511133058.GA26195@camelia.ucw.cz> Hello, I have found the hard way that jni.h need not to be in the default include path (like it is for gcj) and that the right include directories are maintained by alternatives, ready to use, so the following ensures the spec using jni bindings compiles under any java: BuildRequires: java-devel [...] for i in -I/usr/lib/jvm/java/include{,/linux}; do java_inc="$java_inc $i" done %configure CPPFLAGS="$java_inc" (see also http://bugzilla.redhat.com/498964#c2) Could this information be added to Packaging:Java? Is there anything I can do for it? (To save my successors a few days of investigation.) Cheers, Stepan From overholt at redhat.com Mon May 11 13:43:07 2009 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 11 May 2009 09:43:07 -0400 Subject: [Fedora-packaging] Java -- how to use jni.h In-Reply-To: <20090511133058.GA26195@camelia.ucw.cz> References: <20090511133058.GA26195@camelia.ucw.cz> Message-ID: <20090511134307.GB24936@redhat.com> * Stepan Kasal [2009-05-11 09:31]: > Could this information be added to Packaging:Java? > Is there anything I can do for it? > (To save my successors a few days of investigation.) Sure, it would be great if you could post a patch to the wiki page it would help. Andrew From rc040203 at freenet.de Tue May 12 12:07:29 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 12 May 2009 14:07:29 +0200 Subject: [Fedora-packaging] Re: Agenda for the 2009-05-12 Packaging Committee meeting In-Reply-To: References: Message-ID: <4A096681.6070302@freenet.de> Jason L Tibbitts III wrote: > The Packaging Committee will meet Tuesday, 2009-05-12 at 17:00UTC in > the #fedora-meeting channel on chat.freenode.net. As last time (and likely thoughout the whole daylight saving time), 17:00 UTC will very likely not work for me. Therefore, preliminary comments/votes interspersed: > FPC works from the agenda at > https://fedoraproject.org/wiki/Packaging/GuidelinesTodo; here are some > things which should be brought up for discussion at the next meeting: > > GConf scriptlets (revisit from previous meeting) - > https://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/GConf 0, same rationale as the last time. > Globus (revisit from previous meeting) - > https://fedoraproject.org/wiki/PackagingDrafts/Globus -1, same rationale as the list time. > Guidelines for package pre-reviews - > https://fedoraproject.org/wiki/Pre-review_Guidelines_(draft) -1, I don't consider this plan to be useful and do not support it. > Manpage guidelines - > https://fedoraproject.org/wiki/MAN_pages_which_exists_in_other_places(draft) -1, I don't see any need for adding such a guideline. Besides the fact that's often hardly possible to review man-pages and that Debian man-pages are of very varying quality, this is a packaging detail which I prefer to be left to discretion of each packager. Ralf From tcallawa at redhat.com Tue May 12 13:35:52 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 12 May 2009 09:35:52 -0400 Subject: [Fedora-packaging] FPC Availability Chart Message-ID: <4A097B38.6030905@redhat.com> With the available information, I made a chart in the wiki to show what possible availability each FPC member had for meeting times: https://fedoraproject.org/wiki/TomCallaway/FPC_Availability Xavier Lamien and Dominik Mierzejewski did not provide data as to their availability. However, due to the lack of any overlap between Hans de Goede and Toshio Kuratomi, it does not seem possible for us to pick any meeting time that will permit all of the FPC to attend. I'm open to suggestions as to how to resolve this. ~spot From a.badger at gmail.com Tue May 12 13:46:39 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 12 May 2009 06:46:39 -0700 Subject: [Fedora-packaging] FPC Availability Chart In-Reply-To: <4A097B38.6030905@redhat.com> References: <4A097B38.6030905@redhat.com> Message-ID: <4A097DBF.1050400@gmail.com> Tom "spot" Callaway wrote: > With the available information, I made a chart in the wiki to show what > possible availability each FPC member had for meeting times: > > https://fedoraproject.org/wiki/TomCallaway/FPC_Availability > > Xavier Lamien and Dominik Mierzejewski did not provide data as to their > availability. > > However, due to the lack of any overlap between Hans de Goede and Toshio > Kuratomi, it does not seem possible for us to pick any meeting time that > will permit all of the FPC to attend. > > I'm open to suggestions as to how to resolve this. > There's overlap during my night (I listed start times for everything) but unfortunately, that puts it even later for the US East Coast so it doesn't overlap with FPC members there. -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 a.badger at gmail.com Tue May 12 13:53:21 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 12 May 2009 06:53:21 -0700 Subject: [Fedora-packaging] FPC Availability Chart In-Reply-To: <4A097DBF.1050400@gmail.com> References: <4A097B38.6030905@redhat.com> <4A097DBF.1050400@gmail.com> Message-ID: <4A097F51.2000408@gmail.com> Toshio Kuratomi wrote: > Tom "spot" Callaway wrote: >> With the available information, I made a chart in the wiki to show what >> possible availability each FPC member had for meeting times: >> >> https://fedoraproject.org/wiki/TomCallaway/FPC_Availability >> >> Xavier Lamien and Dominik Mierzejewski did not provide data as to their >> availability. >> >> However, due to the lack of any overlap between Hans de Goede and Toshio >> Kuratomi, it does not seem possible for us to pick any meeting time that >> will permit all of the FPC to attend. >> >> I'm open to suggestions as to how to resolve this. >> > There's overlap during my night (I listed start times for everything) > but unfortunately, that puts it even later for the US East Coast so it > doesn't overlap with FPC members there. > Here's a suggestion... but only for half the year :-( I can go earlier during daylight savings. (8:00AM local time is the earliest I can make meetings). -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 dominik at greysector.net Tue May 12 14:56:42 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 12 May 2009 16:56:42 +0200 Subject: [Fedora-packaging] FPC Availability Chart In-Reply-To: <4A097B38.6030905@redhat.com> References: <4A097B38.6030905@redhat.com> Message-ID: <20090512145641.GA2500@mokona.greysector.net> On Tuesday, 12 May 2009 at 15:35, Tom spot Callaway wrote: > With the available information, I made a chart in the wiki to show what > possible availability each FPC member had for meeting times: > > https://fedoraproject.org/wiki/TomCallaway/FPC_Availability > > Xavier Lamien and Dominik Mierzejewski did not provide data as to their > availability. Added mine just now. 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 skasal at redhat.com Tue May 12 15:06:08 2009 From: skasal at redhat.com (Stepan Kasal) Date: Tue, 12 May 2009 17:06:08 +0200 Subject: [Fedora-packaging] Java -- how to use jni.h In-Reply-To: <20090511134307.GB24936@redhat.com> References: <20090511133058.GA26195@camelia.ucw.cz> <20090511134307.GB24936@redhat.com> Message-ID: <20090512150608.GA17304@camelia.ucw.cz> Hello Andrew, On Mon, May 11, 2009 at 09:43:07AM -0400, Andrew Overholt wrote: > Sure, it would be great if you could post a patch to the wiki page it > would help. attached please find a first approximation; patch to Packaging:Java wiki source. Cheers, Stepan Kasal -------------- next part -------------- Summary: Added subsection: How to build with jni.h generally --- packaging.orig 2009-05-12 16:58:30.000000000 +0200 +++ packaging-java 2009-05-12 16:59:28.000000000 +0200 @@ -344,6 +344,22 @@ {{Anchor|JNI}} == Packaging JAR files that use JNI == +=== Writing general spec file === +Keep in mind that your package should build under different flavors of Java. In order to achieve this, you have to instruct the C preprocessor to search for header file in the include subdirectories under /usr/lib/jvm/java, which is a symlink maintained by the alternatives system. +(Though file jni.h is +in the default gcc include path when gcj is used, it is not so for openjdk.) + +If the package uses Autoconf-generated configure script, follow this template: +
+BuildRequires: java-devel
+[...]
+%build
+for i in -I/usr/lib/jvm/java/include{,/linux}; do
+      java_inc="$java_inc $i"
+done
+%configure CPPFLAGS="$java_inc"
+
+ === Applicability === Java programs that wish to make calls into native libraries do so via the Java Native Interface (JNI). A Java package uses JNI if it contains a .so From overholt at redhat.com Tue May 12 15:11:43 2009 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 12 May 2009 11:11:43 -0400 Subject: [Fedora-packaging] Java -- how to use jni.h In-Reply-To: <20090512150608.GA17304@camelia.ucw.cz> References: <20090511133058.GA26195@camelia.ucw.cz> <20090511134307.GB24936@redhat.com> <20090512150608.GA17304@camelia.ucw.cz> Message-ID: <1242141103.3602.4.camel@vvvvt> On Tue, 2009-05-12 at 17:06 +0200, Stepan Kasal wrote: > On Mon, May 11, 2009 at 09:43:07AM -0400, Andrew Overholt wrote: > > Sure, it would be great if you could post a patch to the wiki page it > > would help. > > attached please find a first approximation; patch to Packaging:Java > wiki source. Thanks, Stepan. I'll see about getting this into the guidelines. Andrew From nicolas.mailhot at laposte.net Tue May 12 15:39:58 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 12 May 2009 17:39:58 +0200 (CEST) Subject: [Fedora-packaging] Java guideline inconsistency In-Reply-To: <217235831.44801241908896408.JavaMail.root@zmail02.collab.prod.int.phx 2.redhat.com> References: <217235831.44801241908896408.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <05587695e91aa63d109bd67dd9239658.squirrel@arekh.dyndns.org> Le Dim 10 mai 2009 00:41, Fernando Nasser a ?crit : >> > Also, I find it a bit inconsistent that java packages don't have >> to have >> > a java- prefix as python, perl, php and so on packages have to. >> >> I do to but I think this is the standard for enough packages that we >> shouldn't look at fixing it unless it's causing breakage. > > Agreed. Most (all?) of this stuff came from JPackage and there's > little > point in breaking compatibility/naming. Also, perl and python components are released from a centralised source, while java components aren't. The perl- prefix works because it's effectively a cpan- prefix Other languages like C which do not have a centralized source also do not use a common prefix. So java is consistent -- Nicolas Mailhot From a.badger at gmail.com Tue May 12 16:06:14 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 12 May 2009 09:06:14 -0700 Subject: [Fedora-packaging] Java guideline inconsistency In-Reply-To: <05587695e91aa63d109bd67dd9239658.squirrel@arekh.dyndns.org> References: <217235831.44801241908896408.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <05587695e91aa63d109bd67dd9239658.squirrel@arekh.dyndns.org> Message-ID: <4A099E76.3020507@gmail.com> Nicolas Mailhot wrote: > > Le Dim 10 mai 2009 00:41, Fernando Nasser a ?crit : > >>>> Also, I find it a bit inconsistent that java packages don't have >>> to have >>>> a java- prefix as python, perl, php and so on packages have to. >>> I do to but I think this is the standard for enough packages that we >>> shouldn't look at fixing it unless it's causing breakage. >> Agreed. Most (all?) of this stuff came from JPackage and there's >> little >> point in breaking compatibility/naming. > > Also, perl and python components are released from a centralised > source, while java components aren't. The perl- prefix works because > it's effectively a cpan- prefix > perl does but python does not. (pypi, in case that's what you're looking at, is a relatively recent invention as a distribution point and most of the projects there are only lightly tied to that.) But I do think the weight of java's history should count a lot for not inflicting a mass renaming on users and packagers. -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 kevin at tummy.com Wed May 13 00:29:17 2009 From: kevin at tummy.com (Kevin Fenzi) Date: Tue, 12 May 2009 18:29:17 -0600 Subject: [Fedora-packaging] /etc/dbus-1/system.d/ files. Message-ID: <20090512182917.69d5dc2c@ohm.scrye.com> Greetings. It's come up in the review of a package I have submitted that there is no guideline for /etc/dbus-1/system.d/ files. https://bugzilla.redhat.com/show_bug.cgi?id=500437 My understanding is that these are not really config files. End users should not be editing them. Many of the packages that have files in there do not mark them as config. Some packages do. I suppose they could be edited by end users, but I wouldn't think it would be very common or desired. Should we have a guideline for them (or add to an existing one)? Should the be marked config or not? Should they not be under /etc/ at all? Thoughts? kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From a.badger at gmail.com Wed May 13 04:07:47 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 12 May 2009 21:07:47 -0700 Subject: [Fedora-packaging] /etc/dbus-1/system.d/ files. In-Reply-To: <20090512182917.69d5dc2c@ohm.scrye.com> References: <20090512182917.69d5dc2c@ohm.scrye.com> Message-ID: <4A0A4793.9070505@gmail.com> Kevin Fenzi wrote: > Greetings. > > It's come up in the review of a package I have submitted that there is > no guideline for /etc/dbus-1/system.d/ files. > > https://bugzilla.redhat.com/show_bug.cgi?id=500437 > > My understanding is that these are not really config files. End users > should not be editing them. Many of the packages that have files in > there do not mark them as config. Some packages do. I suppose they > could be edited by end users, but I wouldn't think it would be very > common or desired. > > Should we have a guideline for them (or add to an existing one)? > > Should the be marked config or not? > > Should they not be under /etc/ at all? > > Thoughts? > I don't know enough about them to say. At first glance, I'm not certain whether they're configuration or not. They seem to define who is allowed to issue certain requests on the bus. If these are just defaults overridable elsewhere, then they are not config. If the administrator is meant to change these files to change the system defaults then they are. Maybe mclasen or davidz can tell us? -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 j.w.r.degoede at hhs.nl Wed May 13 10:51:39 2009 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 13 May 2009 12:51:39 +0200 Subject: [Fedora-packaging] FPC Availability Chart In-Reply-To: <4A097B38.6030905@redhat.com> References: <4A097B38.6030905@redhat.com> Message-ID: <4A0AA63B.6030400@hhs.nl> On 05/12/2009 03:35 PM, Tom "spot" Callaway wrote: > With the available information, I made a chart in the wiki to show what > possible availability each FPC member had for meeting times: > > https://fedoraproject.org/wiki/TomCallaway/FPC_Availability > > Xavier Lamien and Dominik Mierzejewski did not provide data as to their > availability. > > However, due to the lack of any overlap between Hans de Goede and Toshio > Kuratomi, it does not seem possible for us to pick any meeting time that > will permit all of the FPC to attend. > > I'm open to suggestions as to how to resolve this. > Erm, there are 24 hours in a day you know, the American centric way you've set up that table makes it looks like I'm almost never available. Anyways, I'm fine with meeting later in the evening (my time) too, so you can add an OK to the 1800 1900 and 2000 rows for all days for me, not sure if that helps but its a start. Regards, Hans From tcallawa at redhat.com Wed May 13 13:25:58 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 13 May 2009 09:25:58 -0400 Subject: [Fedora-packaging] FPC Availability Chart In-Reply-To: <4A0AA63B.6030400@hhs.nl> References: <4A097B38.6030905@redhat.com> <4A0AA63B.6030400@hhs.nl> Message-ID: <4A0ACA66.90205@redhat.com> On 05/13/2009 06:51 AM, Hans de Goede wrote: > Erm, there are 24 hours in a day you know, the American centric way you've > set up that table makes it looks like I'm almost never available. Yes, but unfortunately, since almost none of us are available outside of the boundaries of the table, it would simply inflate the table to show a LOT of blank space, so I minimized it to highlight the best possibilities. > Anyways, I'm fine with meeting later in the evening (my time) too, so you > can add an OK to the 1800 1900 and 2000 rows for all days for me, not sure > if that helps but its a start. I'll make that change right now. ~spot From kevin at tummy.com Wed May 13 16:40:16 2009 From: kevin at tummy.com (Kevin Fenzi) Date: Wed, 13 May 2009 10:40:16 -0600 Subject: [Fedora-packaging] /etc/dbus-1/system.d/ files. In-Reply-To: <4A0A4793.9070505@gmail.com> References: <20090512182917.69d5dc2c@ohm.scrye.com> <4A0A4793.9070505@gmail.com> Message-ID: <20090513104016.1b4ef9fd@ohm.scrye.com> On Tue, 12 May 2009 21:07:47 -0700 Toshio Kuratomi wrote: > I don't know enough about them to say. At first glance, I'm not > certain whether they're configuration or not. They seem to define > who is allowed to issue certain requests on the bus. If these are > just defaults overridable elsewhere, then they are not config. If the > administrator is meant to change these files to change the system > defaults then they are. Maybe mclasen or davidz can tell us? Are they on this list? From my review bug: --- Comment #7 from Bastien Nocera 2009-05-13 07:50:06 EDT --- dbus ".conf" files aren't config files. The only thing you'll manage to do is break the setup. Don't mark those as config files. > -Toshio kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From denis at poolshark.org Thu May 14 07:09:46 2009 From: denis at poolshark.org (Denis Leroy) Date: Thu, 14 May 2009 09:09:46 +0200 Subject: [Fedora-packaging] /etc/dbus-1/system.d/ files. In-Reply-To: <20090512182917.69d5dc2c@ohm.scrye.com> References: <20090512182917.69d5dc2c@ohm.scrye.com> Message-ID: <4A0BC3BA.50105@poolshark.org> On 05/13/2009 02:29 AM, Kevin Fenzi wrote: > Greetings. > > It's come up in the review of a package I have submitted that there is > no guideline for /etc/dbus-1/system.d/ files. > > https://bugzilla.redhat.com/show_bug.cgi?id=500437 > > My understanding is that these are not really config files. End users > should not be editing them. Many of the packages that have files in > there do not mark them as config. Some packages do. I suppose they > could be edited by end users, but I wouldn't think it would be very > common or desired. > > Should we have a guideline for them (or add to an existing one)? > > Should the be marked config or not? > > Should they not be under /etc/ at all? These look to me more like resource XML files than actual configuration files. As such, they are probably more suited for /usr/share/dbus-1/ (which already contains a bunch of other xml files). I would not block a review on this though, /etc contains a lot of "pseudo" configuration files like this (GConf schemas for example). From an upstream project perspective, they are configuration files, but from a Fedora desktop user, they are not meant to be modified... -denis From mclasen at redhat.com Thu May 14 14:13:32 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 14 May 2009 10:13:32 -0400 Subject: [Fedora-packaging] /etc/dbus-1/system.d/ files. In-Reply-To: <4A0BC3BA.50105@poolshark.org> References: <20090512182917.69d5dc2c@ohm.scrye.com> <4A0BC3BA.50105@poolshark.org> Message-ID: <1242310412.3964.4.camel@localhost.localdomain> On Thu, 2009-05-14 at 09:09 +0200, Denis Leroy wrote: > On 05/13/2009 02:29 AM, Kevin Fenzi wrote: > > Greetings. > > > > It's come up in the review of a package I have submitted that there is > > no guideline for /etc/dbus-1/system.d/ files. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=500437 > > > > My understanding is that these are not really config files. End users > > should not be editing them. Many of the packages that have files in > > there do not mark them as config. Some packages do. I suppose they > > could be edited by end users, but I wouldn't think it would be very > > common or desired. > > > > Should we have a guideline for them (or add to an existing one)? > > > > Should the be marked config or not? > > > > Should they not be under /etc/ at all? > > These look to me more like resource XML files than actual configuration > files. As such, they are probably more suited for /usr/share/dbus-1/ > (which already contains a bunch of other xml files). That seems like a very weak argument ("the look similar to other files in that other location") to make a change that will cause a bunch of needless packaging churn... > I would not block a review on this though, /etc contains a lot of > "pseudo" configuration files like this (GConf schemas for example). From > an upstream project perspective, they are configuration files, but from > a Fedora desktop user, they are not meant to be modified... Exactly. This is a big problem with the whole '/etc is for config' stanza: whats configuration from the dbus daemons perspective is not necessarily configuration from the distro or user perspective. The only thing users can achieve by 'configuring things in /etc/dbus-1/system are a) Break their system by preventing the sending of messages that are needed for a working system b) Opening security holes by allowing the sending of messages that the shipped dbus policy was meant to prevent Matthias From jonstanley at gmail.com Thu May 14 14:32:28 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Thu, 14 May 2009 10:32:28 -0400 Subject: [Fedora-packaging] Link to release criteria from packaging guidelines? Message-ID: This is obviously an offshoot of the thread o' doom on f-d-l. I'm hoping that cooler heads can prevail here :) I think that, while it's common sense, maybe rather than come up with an impossible packaging guideline about broken deps, a simple link from the packaging guidelines to the release criteria would be sufficient , noting that the overarching health of the distro should be taken into account when making packaging decisions. Thoughts/flames/suggestions? From tcallawa at redhat.com Thu May 14 14:34:14 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 14 May 2009 10:34:14 -0400 Subject: [Fedora-packaging] Link to release criteria from packaging guidelines? In-Reply-To: References: Message-ID: <4A0C2BE6.6040108@redhat.com> On 05/14/2009 10:32 AM, Jon Stanley wrote: > This is obviously an offshoot of the thread o' doom on f-d-l. I'm > hoping that cooler heads can prevail here :) > > I think that, while it's common sense, maybe rather than come up with > an impossible packaging guideline about broken deps, a simple link > from the packaging guidelines to the release criteria would be > sufficient , noting that the overarching health of the distro should > be taken into account when making packaging decisions. We probably should make sure that everything in the release criteria is covered in the Packaging Guidelines. ~spot From panemade at gmail.com Thu May 14 14:45:37 2009 From: panemade at gmail.com (=?UTF-8?B?UGFyYWcgTijgpKrgpLDgpL7gpZop?=) Date: Thu, 14 May 2009 20:15:37 +0530 Subject: [Fedora-packaging] Do we allow arch specific Requires: in spec? Message-ID: Hi all, Just found one old bugzilla link https://bugzilla.redhat.com/show_bug.cgi?id=235755 which tells rpm in rawhide allows arch specific Requires: in spec. Just want to know is it possible in Fedora and since which rpm version? I found link from comment #19 is not working. Is there any package in fedora currently using this? Just curious to know what will be the case where one really need arch specific Requires? I can't find anything related to this written in http://fedoraproject.org/wiki/Packaging/Guidelines#Requires Regards, Parag. From pertusus at free.fr Thu May 14 14:59:00 2009 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 14 May 2009 16:59:00 +0200 Subject: [Fedora-packaging] Link to release criteria from packaging guidelines? In-Reply-To: <4A0C2BE6.6040108@redhat.com> References: <4A0C2BE6.6040108@redhat.com> Message-ID: <20090514145900.GF11456@free.fr> On Thu, May 14, 2009 at 10:34:14AM -0400, Tom spot Callaway wrote: > > We probably should make sure that everything in the release criteria is > covered in the Packaging Guidelines. I am not sure that it primarily belongs there. Well, broken dependencies could be in the guidelines, like 'all the package requires and buildrequires should be satisfied by packages in the corresponding fedora release', but broken EVR paths mostly make sense for updates. I think that it should better be, for example, in http://fedoraproject.org/wiki/Package_update_guidelines -- Pat From paul at city-fan.org Thu May 14 15:05:06 2009 From: paul at city-fan.org (Paul Howarth) Date: Thu, 14 May 2009 16:05:06 +0100 Subject: [Fedora-packaging] Do we allow arch specific Requires: in spec? In-Reply-To: References: Message-ID: <4A0C3322.1050502@city-fan.org> Parag N(????) wrote: > Hi all, > Just found one old bugzilla link > https://bugzilla.redhat.com/show_bug.cgi?id=235755 which tells rpm in > rawhide allows arch specific Requires: in spec. > Just want to know is it possible in Fedora and since which rpm > version? I found link from comment #19 is not working. Is there any > package in fedora currently using this? Just curious to know what will > be the case where one really need arch specific Requires? > I can't find anything related to this written in > http://fedoraproject.org/wiki/Packaging/Guidelines#Requires Try this: Requires: somepackage%{?_isa} Paul. From Jochen at herr-schmitt.de Thu May 14 15:12:08 2009 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 14 May 2009 17:12:08 +0200 Subject: [Fedora-packaging] Do we allow arch specific Requires: in spec? In-Reply-To: <4A0C3322.1050502@city-fan.org> References: <4A0C3322.1050502@city-fan.org> Message-ID: <4A0C34C8.8000406@herr-schmitt.de> Paul Howarth schrieb: > > Try this: > > Requires: somepackage%{?_isa} > Therefor I have two question: Does the buildsystem support it? Can I specify several archs. I assume arch depending requirtes are not helpful yet. I have a package called fedora-ksplice which contains only shell scripts, so it may be a noarch package. But unfortunately it's depends on ksplice which is only available for %{x86} and x86_64. This caused, that the package could not build as an noarch package, because that make no sense to put a noarch fedora-ksplice package to a ppc repository. Best Regards: Jochen Schmitt From rc040203 at freenet.de Thu May 14 15:40:04 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 14 May 2009 17:40:04 +0200 Subject: [Fedora-packaging] Link to release criteria from packaging guidelines? In-Reply-To: References: Message-ID: <4A0C3B54.1040604@freenet.de> Jon Stanley wrote: > This is obviously an offshoot of the thread o' doom on f-d-l. I'm > hoping that cooler heads can prevail here :) > > I think that, while it's common sense, maybe rather than come up with > an impossible packaging guideline about broken deps, a simple link > from the packaging guidelines to the release criteria would be > sufficient , noting that the overarching health of the distro should > be taken into account when making packaging decisions. The criterion so far has been: "All packages must install without errors" => Broken deps are not permitted. Sad, but apparent, Fedora has attracted people, who don't bring along a sufficient amount of understanding packaging to take this kind of rule for granted, but need "regulations and laws" for everything :( Proposal: Let's add a sentence similar to what I wrote above as the 1st line https://fedoraproject.org/wiki/Packaging/ReviewGuidelines. Ralf From rc040203 at freenet.de Thu May 14 15:57:35 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 14 May 2009 17:57:35 +0200 Subject: [Fedora-packaging] Link to release criteria from packaging guidelines? In-Reply-To: <20090514145900.GF11456@free.fr> References: <4A0C2BE6.6040108@redhat.com> <20090514145900.GF11456@free.fr> Message-ID: <4A0C3F6F.1050605@freenet.de> Patrice Dumas wrote: > On Thu, May 14, 2009 at 10:34:14AM -0400, Tom spot Callaway wrote: >> We probably should make sure that everything in the release criteria is >> covered in the Packaging Guidelines. > > I am not sure that it primarily belongs there. Well, broken dependencies > could be in the guidelines, like 'all the package requires and buildrequires > should be satisfied by packages in the corresponding fedora release', but > broken EVR paths mostly make sense for updates. Wrong - They do not make sense! They are critical bugs that need to be fixed ASAP! From pertusus at free.fr Thu May 14 16:01:31 2009 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 14 May 2009 18:01:31 +0200 Subject: [Fedora-packaging] Link to release criteria from packaging guidelines? In-Reply-To: <4A0C3F6F.1050605@freenet.de> References: <4A0C2BE6.6040108@redhat.com> <20090514145900.GF11456@free.fr> <4A0C3F6F.1050605@freenet.de> Message-ID: <20090514160131.GG11456@free.fr> On Thu, May 14, 2009 at 05:57:35PM +0200, Ralf Corsepius wrote: > Patrice Dumas wrote: >> On Thu, May 14, 2009 at 10:34:14AM -0400, Tom spot Callaway wrote: >>> We probably should make sure that everything in the release criteria is >>> covered in the Packaging Guidelines. >> >> I am not sure that it primarily belongs there. Well, broken >> dependencies could be in the guidelines, like 'all the package requires >> and buildrequires >> should be satisfied by packages in the corresponding fedora release', but >> broken EVR paths mostly make sense for updates. > Wrong - They do not make sense! They are critical bugs that need to be > fixed ASAP! Sure, but they can only be introduced during updates, not during the package review. So, there could be a guideline, but it should (also) be linked from the update policy, since it is the place where broken EVR enters. -- Pat From rjones at redhat.com Thu May 14 16:23:59 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 14 May 2009 17:23:59 +0100 Subject: [Fedora-packaging] Link to release criteria from packaging guidelines? In-Reply-To: <4A0C3B54.1040604@freenet.de> References: <4A0C3B54.1040604@freenet.de> Message-ID: <20090514162359.GA26970@amd.home.annexia.org> On Thu, May 14, 2009 at 05:40:04PM +0200, Ralf Corsepius wrote: > Sad, but apparent, Fedora has attracted people, who don't bring along a > sufficient amount of understanding packaging to take this kind of rule > for granted, but need "regulations and laws" for everything :( Please don't disparage people who were doing things to try and help out other Fedora users. I worked very hard to get this package into shape for F10 and EPEL [Centos] 5 users who specifically asked me for it. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From rjones at redhat.com Thu May 14 16:24:45 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 14 May 2009 17:24:45 +0100 Subject: [Fedora-packaging] Link to release criteria from packaging guidelines? In-Reply-To: <4A0C2BE6.6040108@redhat.com> References: <4A0C2BE6.6040108@redhat.com> Message-ID: <20090514162445.GB26970@amd.home.annexia.org> On Thu, May 14, 2009 at 10:34:14AM -0400, Tom spot Callaway wrote: > On 05/14/2009 10:32 AM, Jon Stanley wrote: > > This is obviously an offshoot of the thread o' doom on f-d-l. I'm > > hoping that cooler heads can prevail here :) > > > > I think that, while it's common sense, maybe rather than come up with > > an impossible packaging guideline about broken deps, a simple link > > from the packaging guidelines to the release criteria would be > > sufficient , noting that the overarching health of the distro should > > be taken into account when making packaging decisions. > > We probably should make sure that everything in the release criteria is > covered in the Packaging Guidelines. +1 Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From rc040203 at freenet.de Fri May 15 04:13:30 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 15 May 2009 06:13:30 +0200 Subject: [Fedora-packaging] Link to release criteria from packaging guidelines? In-Reply-To: <20090514162359.GA26970@amd.home.annexia.org> References: <4A0C3B54.1040604@freenet.de> <20090514162359.GA26970@amd.home.annexia.org> Message-ID: <4A0CEBEA.8080105@freenet.de> Richard W.M. Jones wrote: > On Thu, May 14, 2009 at 05:40:04PM +0200, Ralf Corsepius wrote: >> Sad, but apparent, Fedora has attracted people, who don't bring along a >> sufficient amount of understanding packaging to take this kind of rule >> for granted, but need "regulations and laws" for everything :( > > Please don't disparage people who were doing things to try and help > out other Fedora users. I worked very hard to get this package into > shape for F10 and EPEL [Centos] 5 users who specifically asked me for > it. I have nothing to add. It's apparent, you ignored what has been taken for granted by all packagers throughout all the years Fedora exists. From herlimenezes at gmail.com Mon May 18 02:10:24 2009 From: herlimenezes at gmail.com (Herli Joaquim de Menezes) Date: Sun, 17 May 2009 23:10:24 -0300 Subject: [Fedora-packaging] Semantik-0.7.2 does not work under FC10 Message-ID: <8797b4980905171910t6e63a187n37bf55703d7fe949@mail.gmail.com> Hello, friends, I'm a Kdissert user and I have tried to upgrade to semantik-0.7.2. I run Fedora FC10, KDE4.2 desktop, at a amd64 machine. I followed all recommendations according to semantik web page, I have all requirements for running semantik. But as I tried to install it, i got some troubles with qt package, some files were not found. However, in some distributions (Mandriva) it works as well as at (k)ubuntu desktop. Any guess? Im sending anexed the last try config.log. -- Herli Menezes -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: application/octet-stream Size: 10772 bytes Desc: not available URL: From sumasamyukta at gmail.com Tue May 19 10:11:41 2009 From: sumasamyukta at gmail.com (suma sharma) Date: Tue, 19 May 2009 15:41:41 +0530 Subject: [Fedora-packaging] Error: libpython2.4 required for installing an RPM Message-ID: Hi, I have built an RPM for a toolchain based on GCC-4.3.3 on FC5. When I try installing the toolchain RPM on any machine other than FC5, I get the following error: ---------------------------------------------------------------------------- [root at linuxsrv8 i386]# rpm -ivh m16cm32c_elf-1-1.i386.rpm error: Failed dependencies: libpython2.4.so.1.0 is needed by m16cm32c_elf-1-1 [root at linuxsrv8 i386]# ---------------------------------------------------------------------------- Could anyone please help me out? Thanking you in advance. Regards, Sumasamyukta From dan at danny.cz Tue May 19 10:33:35 2009 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Tue, 19 May 2009 12:33:35 +0200 Subject: [Fedora-packaging] Error: libpython2.4 required for installing an RPM In-Reply-To: References: Message-ID: <1242729215.3789.61.camel@eagle.danny.cz> suma sharma p??e v ?t 19. 05. 2009 v 15:41 +0530: > Hi, > I have built an RPM for a toolchain based on GCC-4.3.3 on FC5. > When I try installing the toolchain RPM on any machine other than FC5, I get the > following error: > ---------------------------------------------------------------------------- > [root at linuxsrv8 i386]# rpm -ivh m16cm32c_elf-1-1.i386.rpm > error: Failed dependencies: > libpython2.4.so.1.0 is needed by m16cm32c_elf-1-1 > [root at linuxsrv8 i386]# > ---------------------------------------------------------------------------- > > Could anyone please help me out? Some of the binaries in your package is linked with Python 2.4 library and that's why it will be installable only on distro versions containing Python 2.4. The package must be rebuild when other Python version is used. Dan From sumasamyukta at gmail.com Tue May 19 11:47:43 2009 From: sumasamyukta at gmail.com (suma sharma) Date: Tue, 19 May 2009 17:17:43 +0530 Subject: [Fedora-packaging] Error: libpython2.4 required for installing an RPM In-Reply-To: <1242729215.3789.61.camel@eagle.danny.cz> References: <1242729215.3789.61.camel@eagle.danny.cz> Message-ID: Hi Dan, Thank you for your reply. It did resolve my issue :) Regards, Sumasamyukta On Tue, May 19, 2009 at 4:03 PM, Dan Hor?k wrote: > suma sharma p??e v ?t 19. 05. 2009 v 15:41 +0530: >> Hi, >> I have built an RPM for a toolchain based on GCC-4.3.3 on FC5. >> When I try installing the toolchain RPM on any machine other than FC5, I get the >> following error: >> ---------------------------------------------------------------------------- >> [root at linuxsrv8 i386]# rpm -ivh m16cm32c_elf-1-1.i386.rpm >> error: Failed dependencies: >> libpython2.4.so.1.0 is needed by m16cm32c_elf-1-1 >> [root at linuxsrv8 i386]# >> ---------------------------------------------------------------------------- >> >> Could anyone please help me out? > > Some of the binaries in your package is linked with Python 2.4 library > and that's why it will be installable only on distro versions containing > Python 2.4. The package must be rebuild when other Python version is > used. > > > Dan > > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > From Jochen at herr-schmitt.de Tue May 19 14:44:23 2009 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Tue, 19 May 2009 16:44:23 +0200 Subject: [Fedora-packaging] initddir vs initrddir Message-ID: <4A12C5C7.6090801@herr-schmitt.de> Hallo, on https://bugzilla.redhat.com/show_bug.cgi?id=501130 the submitter of a review request has posted the following coment: Well, /usr/lib/rpm/platform/i586-linux/macros from rpm-4.6+ shows following: %_initddir %{_sysconfdir}/rc.d/init.d # Deprecated misspelling %_initrddir %{_initddir} For clarification I want to ask for the current status of using _initrddir versus _initddir on the packaging guildelines. Best Regards: Jochen Schmitt From notting at redhat.com Tue May 19 15:31:08 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 19 May 2009 11:31:08 -0400 Subject: [Fedora-packaging] initddir vs initrddir In-Reply-To: <4A12C5C7.6090801@herr-schmitt.de> References: <4A12C5C7.6090801@herr-schmitt.de> Message-ID: <20090519153107.GD32715@nostromo.devel.redhat.com> Jochen Schmitt (Jochen at herr-schmitt.de) said: > Hallo, > > on https://bugzilla.redhat.com/show_bug.cgi?id=501130 the submitter > of a review request has posted the following coment: > > Well, /usr/lib/rpm/platform/i586-linux/macros from rpm-4.6+ shows following: > > %_initddir %{_sysconfdir}/rc.d/init.d > # Deprecated misspelling > %_initrddir %{_initddir} > > > For clarification I want to ask for the current status of using > _initrddir versus > _initddir on the packaging guildelines. Honestly? I'd say use neither, as _sysconfdir is an overridable macro, and if you actually use either _initrddir or _initddir in the case where _sysconfdir is overriden, your script won't work, at all. (That being said, _initddir is more correct, as the scripts aren't initrds.) Bill From Jochen at herr-schmitt.de Tue May 19 15:38:59 2009 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Tue, 19 May 2009 17:38:59 +0200 Subject: [Fedora-packaging] initddir vs initrddir In-Reply-To: <20090519153107.GD32715@nostromo.devel.redhat.com> References: <4A12C5C7.6090801@herr-schmitt.de> <20090519153107.GD32715@nostromo.devel.redhat.com> Message-ID: <4A12D293.7080307@herr-schmitt.de> Bill Nottingham schrieb: > Jochen Schmitt (Jochen at herr-schmitt.de) said: > >> Hallo, >> >> on https://bugzilla.redhat.com/show_bug.cgi?id=501130 the submitter >> of a review request has posted the following coment: >> >> Well, /usr/lib/rpm/platform/i586-linux/macros from rpm-4.6+ shows following: >> >> %_initddir %{_sysconfdir}/rc.d/init.d >> # Deprecated misspelling >> %_initrddir %{_initddir} >> >> >> For clarification I want to ask for the current status of using >> _initrddir versus >> _initddir on the packaging guildelines. >> > > Honestly? I'd say use neither, as _sysconfdir is an overridable macro, and > if you actually use either _initrddir or _initddir in the case where > _sysconfdir is overriden, your script won't work, at all. > > (That being said, _initddir is more correct, as the scripts aren't initrds.) > > If so, it may be nice, if someone can correct https://fedoraproject.org/wiki/Packaging/RPMMacros for clarification. Best Regards: Jochen Schmitt From tcallawa at redhat.com Tue May 19 15:44:17 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 19 May 2009 11:44:17 -0400 Subject: [Fedora-packaging] initddir vs initrddir In-Reply-To: <4A12D293.7080307@herr-schmitt.de> References: <4A12C5C7.6090801@herr-schmitt.de> <20090519153107.GD32715@nostromo.devel.redhat.com> <4A12D293.7080307@herr-schmitt.de> Message-ID: <4A12D3D1.7040600@redhat.com> On 05/19/2009 11:38 AM, Jochen Schmitt wrote: > If so, it may be nice, if someone can correct > > https://fedoraproject.org/wiki/Packaging/RPMMacros > > for clarification. Corrected. ~spot From mtasaka at ioa.s.u-tokyo.ac.jp Tue May 19 16:17:49 2009 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 20 May 2009 01:17:49 +0900 Subject: [Fedora-packaging] initddir vs initrddir In-Reply-To: <4A12D3D1.7040600@redhat.com> References: <4A12C5C7.6090801@herr-schmitt.de> <20090519153107.GD32715@nostromo.devel.redhat.com> <4A12D293.7080307@herr-schmitt.de> <4A12D3D1.7040600@redhat.com> Message-ID: <4A12DBAD.9010503@ioa.s.u-tokyo.ac.jp> Tom "spot" Callaway wrote, at 05/20/2009 12:44 AM +9:00: > On 05/19/2009 11:38 AM, Jochen Schmitt wrote: >> If so, it may be nice, if someone can correct >> >> https://fedoraproject.org/wiki/Packaging/RPMMacros >> >> for clarification. > > Corrected. > > ~spot Then would you correct this? https://fedoraproject.org/wiki/Packaging/SysVInitScript#Initscripts_on_the_filesystem Regards, Mamoru From tcallawa at redhat.com Tue May 19 18:00:54 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 19 May 2009 14:00:54 -0400 Subject: [Fedora-packaging] initddir vs initrddir In-Reply-To: <4A12DBAD.9010503@ioa.s.u-tokyo.ac.jp> References: <4A12C5C7.6090801@herr-schmitt.de> <20090519153107.GD32715@nostromo.devel.redhat.com> <4A12D293.7080307@herr-schmitt.de> <4A12D3D1.7040600@redhat.com> <4A12DBAD.9010503@ioa.s.u-tokyo.ac.jp> Message-ID: <4A12F3D6.7010209@redhat.com> On 05/19/2009 12:17 PM, Mamoru Tasaka wrote: > Tom "spot" Callaway wrote, at 05/20/2009 12:44 AM +9:00: >> On 05/19/2009 11:38 AM, Jochen Schmitt wrote: >>> If so, it may be nice, if someone can correct >>> >>> https://fedoraproject.org/wiki/Packaging/RPMMacros >>> >>> for clarification. >> >> Corrected. >> >> ~spot > > Then would you correct this? > https://fedoraproject.org/wiki/Packaging/SysVInitScript#Initscripts_on_the_filesystem Done. ~spot From ville.skytta at iki.fi Wed May 20 07:48:04 2009 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 20 May 2009 10:48:04 +0300 Subject: [Fedora-packaging] Do we allow arch specific Requires: in spec? In-Reply-To: <4A0C34C8.8000406@herr-schmitt.de> References: <4A0C3322.1050502@city-fan.org> <4A0C34C8.8000406@herr-schmitt.de> Message-ID: <200905201048.08019.ville.skytta@iki.fi> On Thursday 14 May 2009, Jochen Schmitt wrote: > I assume arch depending requirtes are not helpful yet. I have a package > called fedora-ksplice which contains only shell scripts, so it may be a > noarch > package. But unfortunately it's depends on ksplice which is only available > for %{x86} and x86_64. This caused, that the package could not build as an > noarch package, because that make no sense to put a noarch > fedora-ksplice package > to a ppc repository. As I suggested in bug 498707, you should be able to build it as noarch and use ExclusiveArch to limit the arch repos where it gets shipped. From pmatilai at laiskiainen.org Wed May 20 10:23:18 2009 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Wed, 20 May 2009 13:23:18 +0300 (EEST) Subject: [Fedora-packaging] Correction to guidelines on %define vs %global Message-ID: Apologies for missing this when the recommendation of %global over %define in Fedora guidelines was being discussed, but better late than never... https://fedoraproject.org/wiki/Packaging/Guidelines#.25global_preferred_over_.25define says "The two macro defining statements behave the same when they are a the top level of rpm's nesting level" but this is not correct: The body of a %global macro is expanded at definition time, whereas the body of a %define is expanded only when used. For many uses it doesn't make any difference but identical they are not, even on top level - for example see the attached example spec: $ rpmbuild -bp macroex.spec 2>/dev/null|grep ^case case1: first - second case2: second - %{xxx} Another example of this difference (in case of parametrized macros): https://bugzilla.redhat.com/show_bug.cgi?id=495658 - Panu - -------------- next part -------------- %global xxx first %global glob1 %{xxx} %define def1 %{xxx} %global glob2 %%{xxx} %define def2 %%{xxx} %global xxx second Name: macroex Version: 1 Release: 1 License: GPL Group: Testing Summary: global vs define %description %{summary} %prep echo case1: %{glob1} - %{def1} echo case2: %{glob2} - %{def2} From ville.skytta at iki.fi Wed May 20 13:22:10 2009 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Wed, 20 May 2009 16:22:10 +0300 Subject: [Fedora-packaging] initddir vs initrddir In-Reply-To: <4A12F3D6.7010209@redhat.com> References: <4A12C5C7.6090801@herr-schmitt.de> <4A12DBAD.9010503@ioa.s.u-tokyo.ac.jp> <4A12F3D6.7010209@redhat.com> Message-ID: <200905201622.11169.ville.skytta@iki.fi> On Tuesday 19 May 2009, Tom "spot" Callaway wrote: > On 05/19/2009 12:17 PM, Mamoru Tasaka wrote: > > Tom "spot" Callaway wrote, at 05/20/2009 12:44 AM +9:00: > >> On 05/19/2009 11:38 AM, Jochen Schmitt wrote: > >>> If so, it may be nice, if someone can correct > >>> > >>> https://fedoraproject.org/wiki/Packaging/RPMMacros > >>> > >>> for clarification. > >> > >> Corrected. > >> > >> ~spot > > > > Then would you correct this? > > https://fedoraproject.org/wiki/Packaging/SysVInitScript#Initscripts_on_th > >e_filesystem > > Done. Note that _initddir doesn't exist in F-9 or any EL versions at the moment, it would be good to mention especially the latter. See also https://bugzilla.redhat.com/455279 From jussilehtola at fedoraproject.org Wed May 20 18:39:31 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Wed, 20 May 2009 21:39:31 +0300 Subject: [Fedora-packaging] Use of macros for standard commands & wishlist of helper programs Message-ID: <1242844771.3110.15.camel@localhost.localdomain> Hi, First: should we have a policy of using macros for standard commands? RPM includes standard macros such as %{__mv}, %{__rm}, %{__mkdir}, %{__cp}, %{__python}, %{__perl} and so on, which are used by some people. I find that the use of these macros unnecessarily obscures the spec file and thus would like to have the ban on these as part of the Packaging Guidelines. Second, a packager's / reviewer's software wishlist: - Is there some tool to check out the redundancy of Requires and BuildRequires? If not, it should be quite trivial to code, since all the tool would need to do is pull the full requirement tree for each R and BR and crosscheck whether there is overlap. Of course, I would do this myself but I'm not as familiar as I should be with a) python, b) yum bindings or c) GUI programming to code such a thing. - Also a some kind of review helper tool would be nice. This should have preferably (skeleton) input files in text for different types of reviews: C libraries, python modules etc could all have a customized review checklist. The tool would then present the GUI checklist formed from the skeleton input file, with a tab of possible resolutions (e.g. OK, NEEDSWORK, N/A, ?) and a comment text box for each item. The output could be saved to a text file and pasted into the review in BZ (or the tool could even have a direct connection with BZ?). -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From tcallawa at redhat.com Wed May 20 18:52:09 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 20 May 2009 14:52:09 -0400 Subject: [Fedora-packaging] Use of macros for standard commands & wishlist of helper programs In-Reply-To: <1242844771.3110.15.camel@localhost.localdomain> References: <1242844771.3110.15.camel@localhost.localdomain> Message-ID: <4A145159.6090701@redhat.com> On 05/20/2009 02:39 PM, Jussi Lehtola wrote: > First: should we have a policy of using macros for standard commands? > RPM includes standard macros such as %{__mv}, %{__rm}, %{__mkdir}, > %{__cp}, %{__python}, %{__perl} and so on, which are used by some > people. > > I find that the use of these macros unnecessarily obscures the spec file > and thus would like to have the ban on these as part of the Packaging > Guidelines. They're not incorrect, so while I personally agree that these are generally unnecessary, I'm not sure it merits a ban. ~spot From a.badger at gmail.com Wed May 20 19:04:54 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 20 May 2009 12:04:54 -0700 Subject: [Fedora-packaging] Use of macros for standard commands & wishlist of helper programs In-Reply-To: <1242844771.3110.15.camel@localhost.localdomain> References: <1242844771.3110.15.camel@localhost.localdomain> Message-ID: <4A145456.9010302@gmail.com> On 05/20/2009 11:39 AM, Jussi Lehtola wrote: > Hi, > > > First: should we have a policy of using macros for standard commands? > RPM includes standard macros such as %{__mv}, %{__rm}, %{__mkdir}, > %{__cp}, %{__python}, %{__perl} and so on, which are used by some > people. > > I find that the use of these macros unnecessarily obscures the spec file > and thus would like to have the ban on these as part of the Packaging > Guidelines. > > They're unnecessary but not wrong and they don't obscure the meaning very much. I would be against having a ban in the Guidelines since it's adding something to the packager workload and another Guideline to have to look at when searching for what you really want for not much gain. > > Second, a packager's / reviewer's software wishlist: > > > - Is there some tool to check out the redundancy of Requires and > BuildRequires? If not, it should be quite trivial to code, since all the > tool would need to do is pull the full requirement tree for each R and > BR and crosscheck whether there is overlap. > > Of course, I would do this myself but I'm not as familiar as I should be > with a) python, b) yum bindings or c) GUI programming to code such a > thing. > > > > - Also a some kind of review helper tool would be nice. This should have > preferably (skeleton) input files in text for different types of > reviews: C libraries, python modules etc could all have a customized > review checklist. > > The tool would then present the GUI checklist formed from the skeleton > input file, with a tab of possible resolutions (e.g. OK, NEEDSWORK, > N/A, ?) and a comment text box for each item. > > The output could be saved to a text file and pasted into the review in > BZ (or the tool could even have a direct connection with BZ?). If you're interested in working on the coding for such a tool (or can find someone who is), I once worked on qa-assistant http://developer.berlios.de/projects/qa-assistant/ But I didn't have time for it anymore so I'd be happy to give someone interested in it access. Also, there's several command line tools out there that do automated checking (as opposed to creating a checklist). Those might be a better use of time to work on. -Toshio From paul at city-fan.org Wed May 20 20:05:36 2009 From: paul at city-fan.org (Paul Howarth) Date: Wed, 20 May 2009 21:05:36 +0100 Subject: [Fedora-packaging] Use of macros for standard commands & wishlist of helper programs In-Reply-To: <1242844771.3110.15.camel@localhost.localdomain> References: <1242844771.3110.15.camel@localhost.localdomain> Message-ID: <20090520210536.13e04e62@metropolis.intra.city-fan.org> On Wed, 20 May 2009 21:39:31 +0300 Jussi Lehtola wrote: > First: should we have a policy of using macros for standard commands? > RPM includes standard macros such as %{__mv}, %{__rm}, %{__mkdir}, > %{__cp}, %{__python}, %{__perl} and so on, which are used by some > people. > > I find that the use of these macros unnecessarily obscures the spec > file and thus would like to have the ban on these as part of the > Packaging Guidelines. I don't find them problematic in this way, especially not for the examples cited above, which all start with __ and hence the underlying commands all line up nicely with each other when you have a sequence of these commands in a spec file, and hence is perfectly readable IMHO. > Second, a packager's / reviewer's software wishlist: > > > - Is there some tool to check out the redundancy of Requires and > BuildRequires? If not, it should be quite trivial to code, since all > the tool would need to do is pull the full requirement tree for each > R and BR and crosscheck whether there is overlap. > > Of course, I would do this myself but I'm not as familiar as I should > be with a) python, b) yum bindings or c) GUI programming to code such > a thing. I don't think this is a good idea as determining the correct set of buildrequires isn't easily automatable. For instance, suppose we have a package P that uses two libraries, L1 & L2. And suppose that library L1 internally uses L2 and hence L1-devel requires L2-devel. A packager might well submit a package for P that buildrequires L1-devel and L2-devel (which would in fact be the right thing to do, since P actually uses these libraries directly). However, a na?ve application of a buildreq redundancy finding tool would suggest that P's buildreq of L2-devel was redundant, and the packager might accept that finding and remove it. All would be well until some time down the line when a new version of L1 came along that was built on a different underlying library L3 rather than L2, and so L1-devel changed its dependency of L2-devel to L3-devel. A new build of P would then fail because L2-devel wouldn't get pulled in. > - Also a some kind of review helper tool would be nice. This should > have preferably (skeleton) input files in text for different types of > reviews: C libraries, python modules etc could all have a customized > review checklist. > > The tool would then present the GUI checklist formed from the skeleton > input file, with a tab of possible resolutions (e.g. OK, NEEDSWORK, > N/A, ?) and a comment text box for each item. > > The output could be saved to a text file and pasted into the review in > BZ (or the tool could even have a direct connection with BZ?). That would be nice, yes, though you'd still want a full review checklist being available for things like library packages that provide bindings for multiple languages and don't fit nicely into a single language checklist. Paul. From katzj at redhat.com Wed May 20 20:27:31 2009 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 20 May 2009 16:27:31 -0400 Subject: [Fedora-packaging] Use of macros for standard commands & wishlist of helper programs In-Reply-To: <4A145159.6090701@redhat.com> References: <1242844771.3110.15.camel@localhost.localdomain> <4A145159.6090701@redhat.com> Message-ID: <20090520202731.GD22621@redhat.com> On Wednesday, May 20 2009, Tom spot Callaway said: > On 05/20/2009 02:39 PM, Jussi Lehtola wrote: > > First: should we have a policy of using macros for standard commands? > > RPM includes standard macros such as %{__mv}, %{__rm}, %{__mkdir}, > > %{__cp}, %{__python}, %{__perl} and so on, which are used by some > > people. > > > > I find that the use of these macros unnecessarily obscures the spec file > > and thus would like to have the ban on these as part of the Packaging > > Guidelines. > > They're not incorrect, so while I personally agree that these are > generally unnecessary, I'm not sure it merits a ban. And really, if we don't want them being used, then we should just not have them defined as rpm macros IMHO Jeremy From a.badger at gmail.com Thu May 21 00:46:18 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 20 May 2009 17:46:18 -0700 Subject: [Fedora-packaging] Phase out buildroot? Message-ID: <4A14A45A.6080903@gmail.com> Since the rpm version shipped in Fedora 10 and beyond defines a default buildroot, I think we can start phasing out the current buildroot Guideline. How about adding this to the start of the buildroot tag section? """ === Buildroot tag === {{{admon/note|The RPM in Fedora 10 defines a default buildroot so in Fedora 10 and above it is no longer necessary to define a buildroot tag. Fedora < 10 and EPEL 5 or less still need to have the tag.}}} [Current content remains until EPEL-5 is no longer maintained] """ https://fedoraproject.org/wiki/Phase_out_buildroot_tag_%28draft%29 -Toshio From a.badger at gmail.com Thu May 21 01:08:52 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 20 May 2009 18:08:52 -0700 Subject: [Fedora-packaging] Correction to guidelines on %define vs %global In-Reply-To: References: Message-ID: <4A14A9A4.9030800@gmail.com> On 05/20/2009 03:23 AM, Panu Matilainen wrote: > > Apologies for missing this when the recommendation of %global over > %define in Fedora guidelines was being discussed, but better late than > never... > > https://fedoraproject.org/wiki/Packaging/Guidelines#.25global_preferred_over_.25define > > says "The two macro defining statements behave the same when they are a > the top level of rpm's nesting level" but this is not correct: > > The body of a %global macro is expanded at definition time, whereas the > body of a %define is expanded only when used. For many uses it doesn't > make any difference but identical they are not, even on top level - for > example see the attached example spec: > > $ rpmbuild -bp macroex.spec 2>/dev/null|grep ^case > case1: first - second > case2: second - %{xxx} > > Another example of this difference (in case of parametrized macros): > https://bugzilla.redhat.com/show_bug.cgi?id=495658 > Hi Panu, How does this look? (Note, I haven't tested any of this code yet as I'm running out the door. I wrote it just from how I understand your message and bz#495658). Also note that I don't know what causes rpm to clear the %defines that have been defined. If you can fill that in that would be great. If it's too complex, we can figure out some way to rephrase around it. """ %global and %define are both used to define macros inside rpm spec files. We generally prefer using %global over %define. %define created macros when they are used in nested macro expansions (like in %{!?foo: ... } constructs theoretically only lasts until the end brace (local scope), while %global definitions have global scope. However, rpm currently doesn't clear the scope for the macros unless [Accurate information needed here]. So %define'd macros often last throughout a spec file. However, when they don't, it's often non-obvious why the spec file is failing as the failure is caused by something changing in another part of the spec file. %global has another major difference from %define that can cause problems when you first write the macro. %global is evaluated at the time that it is written whereas %define is evaluated separately everytime it occurs in a spec file. As an example, if you do the following in a spec file:: 
%build

%global foo FOO
%global bar %foo
%define baz %foo
echo %{bar} - %{baz}

%global foo FOOBAR
echo %{bar} - %{baz}

You get this:

FOO - FOO
FOO - FOOBAR
One place this becomes apparent is parameterized macros: 
%build
%global print_arg echo "Hello %1"
%print_arg World
because the %1 is evaluated when print_arg is defined, this prints Hello rather than "Hello World". Escaping the % fixes this usage: 
%global print_arg echo "Hello %%1"
""" -Toshio From cra at WPI.EDU Thu May 21 03:47:00 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 20 May 2009 23:47:00 -0400 Subject: [Fedora-packaging] Phase out buildroot? In-Reply-To: <4A14A45A.6080903@gmail.com> References: <4A14A45A.6080903@gmail.com> Message-ID: <20090521034700.GS4646@angus.ind.WPI.EDU> On Wed, May 20, 2009 at 05:46:18PM -0700, Toshio Kuratomi wrote: > Since the rpm version shipped in Fedora 10 and beyond defines a default > buildroot, I think we can start phasing out the current buildroot > Guideline. How about adding this to the start of the buildroot tag > section? I'd be concerned about accidentally blowing away people's systems if they take a src.rpm from Fedora and try to build it on an older Fedora or non-Fedora system. %install rm -rf $RPM_BUILD_ROOT ... %clean rm -rf $RPM_BUILD_ROOT From a.badger at gmail.com Thu May 21 06:05:57 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 20 May 2009 23:05:57 -0700 Subject: [Fedora-packaging] Phase out buildroot? In-Reply-To: <20090521034700.GS4646@angus.ind.WPI.EDU> References: <4A14A45A.6080903@gmail.com> <20090521034700.GS4646@angus.ind.WPI.EDU> Message-ID: <4A14EF45.2040407@gmail.com> On 05/20/2009 08:47 PM, Chuck Anderson wrote: > On Wed, May 20, 2009 at 05:46:18PM -0700, Toshio Kuratomi wrote: >> Since the rpm version shipped in Fedora 10 and beyond defines a default >> buildroot, I think we can start phasing out the current buildroot >> Guideline. How about adding this to the start of the buildroot tag >> section? > > I'd be concerned about accidentally blowing away people's systems if > they take a src.rpm from Fedora and try to build it on an older Fedora > or non-Fedora system. > > %install > rm -rf $RPM_BUILD_ROOT > ... > > %clean > rm -rf $RPM_BUILD_ROOT > What will this evaluate to on older systems? Won't it be "rm -rf\n"? Which actually won't remove anything? -Toshio From cra at WPI.EDU Thu May 21 06:39:48 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 21 May 2009 02:39:48 -0400 Subject: [Fedora-packaging] Phase out buildroot? In-Reply-To: <4A14EF45.2040407@gmail.com> References: <4A14A45A.6080903@gmail.com> <20090521034700.GS4646@angus.ind.WPI.EDU> <4A14EF45.2040407@gmail.com> Message-ID: <20090521063948.GN5211@angus.ind.WPI.EDU> On Wed, May 20, 2009 at 11:05:57PM -0700, Toshio Kuratomi wrote: > On 05/20/2009 08:47 PM, Chuck Anderson wrote: >> On Wed, May 20, 2009 at 05:46:18PM -0700, Toshio Kuratomi wrote: >>> Since the rpm version shipped in Fedora 10 and beyond defines a default >>> buildroot, I think we can start phasing out the current buildroot >>> Guideline. How about adding this to the start of the buildroot tag >>> section? >> >> I'd be concerned about accidentally blowing away people's systems if >> they take a src.rpm from Fedora and try to build it on an older Fedora >> or non-Fedora system. >> >> %install >> rm -rf $RPM_BUILD_ROOT >> ... >> >> %clean >> rm -rf $RPM_BUILD_ROOT >> > > What will this evaluate to on older systems? Won't it be "rm -rf\n"? > Which actually won't remove anything? Last I knew, it will evaluate to / and all hilarity will ensue. Once upon a time, the recommendation was to use something like this to prevent such disasters: [ "$RPM_BUILD_ROOT" != "/" ] && rm -rf $RPM_BUILD_ROOT That fell out of favor when the BuildRoot: tag was mandated in Fedora packages. If we remove the BuildRoot: requirement and instead rely upon the new rpmbuild default, we risk obliterating unsuspecting users' systems. I have a better idea. How about we get rpmbuild to automatically do the moral equivalent of "[ "$RPM_BUILD_ROOT" != "/" ] && rm -rf $RPM_BUILD_ROOT" internally before starting %install and %clean, and remove all such boilerplate from all Fedora specs. Then we can remove the BuildRoot: requirement as well, and older/non-Fedora systems will just break/pollute/fail to cleanup the build instead of blowing away the users system, a much lesser evil IMO. From loupgaroublond at gmail.com Thu May 21 07:00:55 2009 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Thu, 21 May 2009 03:00:55 -0400 (EDT) Subject: [Fedora-packaging] Correction to guidelines on %define vs %global In-Reply-To: <4A14A9A4.9030800@gmail.com> Message-ID: 2009/5/20 Toshio Kuratomi : > On 05/20/2009 03:23 AM, Panu Matilainen wrote: >> >> Apologies for missing this when the recommendation of %global over >> %define in Fedora guidelines was being discussed, but better late than >> never... >> >> >> https://fedoraproject.org/wiki/Packaging/Guidelines#.25global_preferred_over_.25define >> >> says "The two macro defining statements behave the same when they are a >> the top level of rpm's nesting level" but this is not correct: >> >> The body of a %global macro is expanded at definition time, whereas the >> body of a %define is expanded only when used. For many uses it doesn't >> make any difference but identical they are not, even on top level - for >> example see the attached example spec: >> >> $ rpmbuild -bp macroex.spec 2>/dev/null|grep ^case >> case1: first - second >> case2: second - %{xxx} >> >> Another example of this difference (in case of parametrized macros): >> https://bugzilla.redhat.com/show_bug.cgi?id=495658 >> > > > Hi Panu, How does this look? ?(Note, I haven't tested any of this code yet > as I'm running out the door. ?I wrote it just from how I understand your > message and bz#495658). ?Also note that I don't know what causes rpm to > clear the %defines that have been defined. ?If you can fill that in that > would be great. ?If it's too complex, we can figure out some way to rephrase > around it. > > """ > %global and %define are both used to define macros inside rpm spec files. > ?We generally prefer using %global over %define. > > %define created macros when they are used in nested macro expansions (like > in ?%{!?foo: ... } ?constructs theoretically only lasts until the end brace > (local scope), while %global definitions have global scope. However, rpm > currently doesn't clear the scope for the macros unless [Accurate > information needed here]. So %define'd macros often last throughout a spec > file. ?However, when they don't, it's often non-obvious why the spec file is > failing as the failure is caused by something changing in another part of > the spec file. This is somewhat strange behavior to a packager who is not the most skilled developers. Granted RPM spec files are pretty much a programming language, how often do we see it with all these different scoping and evaluation rules? Even more so when we use more complex macros to make the job easier for the packager and hide these details? > %global has another major difference from %define that can cause problems > when you first write the macro. ?%global is evaluated at the time that it is > written whereas %define is evaluated separately everytime it occurs in a > spec file. ?As an example, if you do the following in a spec file:: With my limited understanding of RPM internals, in order to maintain consistency, would we need perhaps another form of global? Just asking. What are the cons at looking at a '%macro' macro that will delay evaluation, unlike %global? -Yaakov -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 270 bytes Desc: OpenPGP digital signature URL: From caillon at redhat.com Thu May 21 15:34:23 2009 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 21 May 2009 08:34:23 -0700 Subject: [Fedora-packaging] Correction to guidelines on %define vs %global In-Reply-To: <4A14A9A4.9030800@gmail.com> References: <4A14A9A4.9030800@gmail.com> Message-ID: <4A15747F.8030102@redhat.com> On 05/20/2009 06:08 PM, Toshio Kuratomi wrote: > One place this becomes apparent is parameterized macros: > 
> %build
> %global print_arg echo "Hello %1"
> %print_arg World
>
> because the %1 is evaluated when print_arg is defined, this prints > Hello rather than "Hello World". nit: there would technically be a space after Hello, so Hello though that's probably not easy to see... Perhaps some tricks with punctuation could help. From a.badger at gmail.com Thu May 21 16:45:13 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 21 May 2009 09:45:13 -0700 Subject: [Fedora-packaging] Phase out buildroot? In-Reply-To: <20090521063948.GN5211@angus.ind.WPI.EDU> References: <4A14A45A.6080903@gmail.com> <20090521034700.GS4646@angus.ind.WPI.EDU> <4A14EF45.2040407@gmail.com> <20090521063948.GN5211@angus.ind.WPI.EDU> Message-ID: <4A158519.5050700@gmail.com> On 05/20/2009 11:39 PM, Chuck Anderson wrote: > On Wed, May 20, 2009 at 11:05:57PM -0700, Toshio Kuratomi wrote: >> On 05/20/2009 08:47 PM, Chuck Anderson wrote: >>> On Wed, May 20, 2009 at 05:46:18PM -0700, Toshio Kuratomi wrote: >>>> Since the rpm version shipped in Fedora 10 and beyond defines a default >>>> buildroot, I think we can start phasing out the current buildroot >>>> Guideline. How about adding this to the start of the buildroot tag >>>> section? >>> I'd be concerned about accidentally blowing away people's systems if >>> they take a src.rpm from Fedora and try to build it on an older Fedora >>> or non-Fedora system. >>> >>> %install >>> rm -rf $RPM_BUILD_ROOT >>> ... >>> >>> %clean >>> rm -rf $RPM_BUILD_ROOT >>> >> What will this evaluate to on older systems? Won't it be "rm -rf\n"? >> Which actually won't remove anything? > > Last I knew, it will evaluate to / and all hilarity will ensue. Once > upon a time, the recommendation was to use something like this to > prevent such disasters: > > [ "$RPM_BUILD_ROOT" != "/" ]&& rm -rf $RPM_BUILD_ROOT > > That fell out of favor when the BuildRoot: tag was mandated in Fedora > packages. If we remove the BuildRoot: requirement and instead rely > upon the new rpmbuild default, we risk obliterating unsuspecting > users' systems. > > I have a better idea. How about we get rpmbuild to automatically do > the moral equivalent of "[ "$RPM_BUILD_ROOT" != "/" ]&& rm -rf > $RPM_BUILD_ROOT" internally before starting %install and %clean, and > remove all such boilerplate from all Fedora specs. Then we can remove > the BuildRoot: requirement as well, and older/non-Fedora systems will > just break/pollute/fail to cleanup the build instead of blowing away > the users system, a much lesser evil IMO. > I thought that Panu posted something about this actually being the case but I can't find it in a quick look at the code in git. Perhaps that was an idea rather than actually coded or perhaps my memory is wrong. Panu care to weigh in on this ? -Toshio From mlichvar at redhat.com Mon May 25 15:55:40 2009 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Mon, 25 May 2009 17:55:40 +0200 Subject: [Fedora-packaging] [Draft] The use of alternatives In-Reply-To: <20090407205132.GA31068@mokona.greysector.net> References: <20090407205132.GA31068@mokona.greysector.net> Message-ID: <20090525155540.GI16047@localhost> On Tue, Apr 07, 2009 at 10:51:33PM +0200, Dominik 'Rathann' Mierzejewski wrote: > The UsingAlternatives draft[1] should now be ready for voting at the next > meeting. I've just made some finishing touches. I'd like to include > it in the agenda for the next FPC meeting. > > [1] https://fedoraproject.org/wiki/PackagingDrafts/UsingAlternatives I was considering %ghosting the files provided by alternatives in my packages (postfix and sendmail), but I'm not sure how to do the migration without breaking upgrades/removals. When only one installed package from the alternatives group uses %ghost, removing the package will remove also the symlinks. Is there a command that could be used in postun to restore the symlinks and not change auto/manual mode? Thanks, -- Miroslav Lichvar From pmatilai at laiskiainen.org Tue May 26 07:38:37 2009 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Tue, 26 May 2009 10:38:37 +0300 (EEST) Subject: [Fedora-packaging] Phase out buildroot? In-Reply-To: <4A158519.5050700@gmail.com> References: <4A14A45A.6080903@gmail.com> <20090521034700.GS4646@angus.ind.WPI.EDU> <4A14EF45.2040407@gmail.com> <20090521063948.GN5211@angus.ind.WPI.EDU> <4A158519.5050700@gmail.com> Message-ID: On Thu, 21 May 2009, Toshio Kuratomi wrote: > On 05/20/2009 11:39 PM, Chuck Anderson wrote: >> On Wed, May 20, 2009 at 11:05:57PM -0700, Toshio Kuratomi wrote: >>> On 05/20/2009 08:47 PM, Chuck Anderson wrote: >>>> On Wed, May 20, 2009 at 05:46:18PM -0700, Toshio Kuratomi wrote: >>>>> Since the rpm version shipped in Fedora 10 and beyond defines a default >>>>> buildroot, I think we can start phasing out the current buildroot >>>>> Guideline. How about adding this to the start of the buildroot tag >>>>> section? >>>> I'd be concerned about accidentally blowing away people's systems if >>>> they take a src.rpm from Fedora and try to build it on an older Fedora >>>> or non-Fedora system. >>>> >>>> %install >>>> rm -rf $RPM_BUILD_ROOT >>>> ... >>>> >>>> %clean >>>> rm -rf $RPM_BUILD_ROOT >>>> >>> What will this evaluate to on older systems? Won't it be "rm -rf\n"? >>> Which actually won't remove anything? >> >> Last I knew, it will evaluate to / and all hilarity will ensue. Once >> upon a time, the recommendation was to use something like this to >> prevent such disasters: >> >> [ "$RPM_BUILD_ROOT" != "/" ]&& rm -rf $RPM_BUILD_ROOT >> >> That fell out of favor when the BuildRoot: tag was mandated in Fedora >> packages. If we remove the BuildRoot: requirement and instead rely >> upon the new rpmbuild default, we risk obliterating unsuspecting >> users' systems. >> >> I have a better idea. How about we get rpmbuild to automatically do >> the moral equivalent of "[ "$RPM_BUILD_ROOT" != "/" ]&& rm -rf >> $RPM_BUILD_ROOT" internally before starting %install and %clean, and >> remove all such boilerplate from all Fedora specs. Then we can remove >> the BuildRoot: requirement as well, and older/non-Fedora systems will >> just break/pollute/fail to cleanup the build instead of blowing away >> the users system, a much lesser evil IMO. >> > I thought that Panu posted something about this actually being the case but I > can't find it in a quick look at the code in git. Perhaps that was an idea > rather than actually coded or perhaps my memory is wrong. Lots of ideas get tossed around, many of them get get forgotten before anybody gets around to do anything about them... :-/ > Panu care to weigh in on this ? There are no changes to rpm in this area that I recall. This could be done by just tweaking the build templates in redhat-rpm-config though, something like this in /usr/lib/rpm/redhat/macros: %__spec_install_pre %{___build_pre}\ [ "$RPM_BUILD_ROOT" != "/" ] && rm -rf "${RPM_BUILD_ROOT}"\ %{nil} This would also force fixing any packages that install stuff from %build. I remember openoffice being that way... hmm ok that was a long time ago, it's been fixed in F-9. Another possible alternative is what Suse does: remove and create the buildroot at beginning of the entire build (copy-pasted from suse macros): %__spec_build_pre %{___build_pre}\ %{?buildroot: %__rm -rf "$RPM_BUILD_ROOT"\ %__mkdir_p `dirname "$RPM_BUILD_ROOT"`\ %__mkdir "$RPM_BUILD_ROOT"\ } - Panu - From pmatilai at laiskiainen.org Tue May 26 09:38:03 2009 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Tue, 26 May 2009 12:38:03 +0300 (EEST) Subject: [Fedora-packaging] Correction to guidelines on %define vs %global In-Reply-To: <4A14A9A4.9030800@gmail.com> References: <4A14A9A4.9030800@gmail.com> Message-ID: On Wed, 20 May 2009, Toshio Kuratomi wrote: > On 05/20/2009 03:23 AM, Panu Matilainen wrote: >> >> Apologies for missing this when the recommendation of %global over >> %define in Fedora guidelines was being discussed, but better late than >> never... >> >> https://fedoraproject.org/wiki/Packaging/Guidelines#.25global_preferred_over_.25define >> >> says "The two macro defining statements behave the same when they are a >> the top level of rpm's nesting level" but this is not correct: >> >> The body of a %global macro is expanded at definition time, whereas the >> body of a %define is expanded only when used. For many uses it doesn't >> make any difference but identical they are not, even on top level - for >> example see the attached example spec: >> >> $ rpmbuild -bp macroex.spec 2>/dev/null|grep ^case >> case1: first - second >> case2: second - %{xxx} >> >> Another example of this difference (in case of parametrized macros): >> https://bugzilla.redhat.com/show_bug.cgi?id=495658 >> > > > Hi Panu, How does this look? (Note, I haven't tested any of this code yet as > I'm running out the door. I wrote it just from how I understand your message > and bz#495658). Also note that I don't know what causes rpm to clear the > %defines that have been defined. If you can fill that in that would be > great. If it's too complex, we can figure out some way to rephrase around > it. > > """ > %global and %define are both used to define macros inside rpm spec files. We > generally prefer using %global over %define. > > %define created macros when they are used in nested macro expansions (like in > %{!?foo: ... } constructs theoretically only lasts until the end brace > (local scope), while %global definitions have global scope. However, rpm > currently doesn't clear the scope for the macros unless [Accurate information > needed here]. So %define'd macros often last throughout a spec file. > However, when they don't, it's often non-obvious why the spec file is failing > as the failure is caused by something changing in another part of the spec > file. Locally scoped macros get freed (well, popped) on exit from parametrized macros - think of local variables in a function. The conditional construct %{!?bar: %define bar defined} is the special case where the define ends up on non-global scope but doesn't get freed immediately as this is not a parametrized macro. Note "immediately": it will get freed eventually if a "call" to parametrized macro happens: --- %prep %define myecho() echo %1 %2 %{!?bar: %define bar defined} echo 1: %{bar} %{myecho 2: %{bar}} echo 3: %{bar} --- gives: 1: defined 2: defined 3: %{bar} but if you use "%{!?bar: %global bar defined}" you get what you expect. I'm not sure if explaining details of such quirks of rpm macro language really belongs to packaging guidelines, to put it simply: Inside %{ } blocks you need to use %global to define global macros. This is not entirely unlike python variable scoping: by default variables only exist in the scope (local or global) they are created, unless "global" statement is used to force glocal scope. > %global has another major difference from %define that can cause problems > when you first write the macro. %global is evaluated at the time that it is > written whereas %define is evaluated separately everytime it occurs in a spec > file. As an example, if you do the following in a spec file:: [snip] Again I doubt spelling out the crazy details is terribly useful, the rules are basically: - Always create parametrized macros with %define. - Inside %{ } blocks you need to use %global to define global macros. - %define'd macro is evaluated at time of use, %global macro is evaluated at time of definition (otherwise it might have references to macros that have gone out of scope at time of use) - Panu - From dnovotny at redhat.com Tue May 26 13:13:08 2009 From: dnovotny at redhat.com (Daniel Novotny) Date: Tue, 26 May 2009 09:13:08 -0400 (EDT) Subject: [Fedora-packaging] "file listed twice" warning Message-ID: <1272415703.2984881243343588840.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> hello, I am now fixing stuff in a package for a merge review and this include getting rid of "file listed twice" warnings the situation is this: %files %{mmdir}/Mailman # ... %attr(0644, root, %{mmgroup}) %config(noreplace) %verify(not md5 size mtime) %{mmdir}/Mailman/mm_cfg.py so there's a directory, with lots of sub-directories and files, I want all of them included, but one file of those needs special permissions, directives and such: after that, rpmbuild tells me it's listed twice: once in the directory and once in the "%config", "%attr" definition is there a way around this? probably a directive "I know the file is already listed, just want to change the flags" -Daniel Novotny From tcallawa at redhat.com Tue May 26 13:37:34 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 26 May 2009 09:37:34 -0400 Subject: [Fedora-packaging] "file listed twice" warning In-Reply-To: <1272415703.2984881243343588840.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1272415703.2984881243343588840.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4A1BF09E.9000406@redhat.com> On 05/26/2009 09:13 AM, Daniel Novotny wrote: > hello, > > I am now fixing stuff in a package for a merge review and this include getting rid of "file listed twice" warnings > > the situation is this: > > %files > %{mmdir}/Mailman > # ... > %attr(0644, root, %{mmgroup}) %config(noreplace) %verify(not md5 size mtime) %{mmdir}/Mailman/mm_cfg.py > > so there's a directory, with lots of sub-directories and files, I want all of them included, > but one file of those needs special permissions, directives and such: > > after that, rpmbuild tells me it's listed twice: once in the directory and once in the "%config", "%attr" definition > > is there a way around this? probably a directive "I know the file is already listed, just want to change the flags" There is no simple directive here like you're suggesting. The correct fix is to do something like this: %files %defattr(-,root,root,-) %dir %{mmdir}/Mailman/ %{mmdir}/Mailman/subdirectory1/ %{mmdir}/Mailman/subdirectory2/ %{mmdir}/Mailman/subdirectory3/ # Use wildcards where appropriate, but be sure not to catch the special case. %{mmdir}/Mailman/file1.py* %{mmdir}/Mailman/file2.py* # Special case... shortened to fit on one line, for the purpose of illustration %attr(0644, root, %{mmgroup}) %{mmdir}/Mailman/mm_cfg.py ~spot From tmz at pobox.com Tue May 26 16:14:37 2009 From: tmz at pobox.com (Todd Zullinger) Date: Tue, 26 May 2009 12:14:37 -0400 Subject: [Fedora-packaging] Requiring xinetd when placing files into /etc/xinetd.d Message-ID: <20090526161437.GT4433@inocybe.localdomain> A conversation? on fedora-list reminded me of something I found a while back and never got around to asking about... It seems that about half of the packages that place files in /etc/xinetd.d require xinetd and half do not: $ repoquery --qf '%{name}' --whatprovides '/etc/xinetd.d/*' | \ sort -u | while read p; do repoquery --requires $p | \ grep -q xinet && echo "$p: YES" || echo "$p: NO" done amanda: YES apg: NO authd: YES bitlbee: YES cups-lpd: YES cvs: NO ebhttpd: NO ebnetd: NO finger-server: YES git-daemon: NO krb5-workstation-servers: YES ldminfod: NO leafnode: YES libident-tools: NO ltsp-server: NO ndtpd: NO node: YES nuttcp: NO proftpd: NO pure-ftpd: NO rsh-server: YES rsync: NO samba-swat: YES talk-server: YES telnet-server: YES tftp-server: YES uucp: NO uw-imap: YES vnc-ltsp-config: YES vtun: YES xinetd: YES I am sure there are a few valid reasons a package might place files into /etc/xinetd.d and not require xinetd, such as cvs or rsync, which both provide plenty of functionality without xinetd. A package like git-daemon on the other hand, which is a subpackage specifically designed to provide an xinetd service, really ought to require xinetd to give a good experience out of the box, correct? While it is possible to setup an init script to run git-daemon?, that's not how we ship it in the current packages. (I'm one of the git co-maintainers, and I'm leaning toward adding an xinetd requirement, unless I learn of good reasons not to do so. I'm slightly torn because adding an xinetd requirement may well annoy some folks that prefer to setup an init script.) I'm guessing that /etc/xinetd.d being provided by the filesystem package is designed to allow for cases like cvs and rsync, but that happened back in 2000, and the filesystem spec file doesn't leave any bugzilla breadcrumbs to follow to see what other reasons there might be for not requiring xinetd. If anyone has pointers that might help illustrate other cases where not requiring xinetd is the best course, I'd be glad to know about them. At the same time, if anyone is familiar with the packages in the "NO" category above, giving a closer look to whether any of them really should be requiring xinetd would probably be a good idea. ? http://www.redhat.com/archives/fedora-list/2009-May/msg01664.html ? https://bugzilla.redhat.com/480755 -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Reason obeys itself; and ignorance does whatever is dictated to it. -- Thomas Paine -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Tue May 26 21:07:07 2009 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 26 May 2009 23:07:07 +0200 Subject: [Fedora-packaging] Re: Requiring xinetd when placing files into /etc/xinetd.d In-Reply-To: <20090526161437.GT4433@inocybe.localdomain> (Todd Zullinger's message of "Tue\, 26 May 2009 12\:14\:37 -0400") References: <20090526161437.GT4433@inocybe.localdomain> Message-ID: <87ljojpo90.fsf@sheridan.bigo.ensc.de> Todd Zullinger writes: > A package like git-daemon on the other hand, which is a subpackage > specifically designed to provide an xinetd service, really ought to > require xinetd to give a good experience out of the box, correct? no; you can use it with every inetd like program. E.g. placing something like | start on starting local | respawn | exec /sbin/busybox tcpsvd 0 1234 /usr/bin/git-daemon ... into /etc/event.d/git-daemon provides an alternative way to invoke git-daemon and it's not more work than editing the xinetd setup. Keeping stuff configurable and do not require stuff which is not needed for core functionality is a good thing... Enrico From tmz at pobox.com Tue May 26 21:41:57 2009 From: tmz at pobox.com (Todd Zullinger) Date: Tue, 26 May 2009 17:41:57 -0400 Subject: [Fedora-packaging] Re: Requiring xinetd when placing files into /etc/xinetd.d In-Reply-To: <87ljojpo90.fsf@sheridan.bigo.ensc.de> References: <20090526161437.GT4433@inocybe.localdomain> <87ljojpo90.fsf@sheridan.bigo.ensc.de> Message-ID: <20090526214157.GE4433@inocybe.localdomain> Enrico Scholz wrote: > Todd Zullinger writes: > >> A package like git-daemon on the other hand, which is a subpackage >> specifically designed to provide an xinetd service, really ought to >> require xinetd to give a good experience out of the box, correct? > > no; you can use it with every inetd like program. E.g. placing > something like > > | start on starting local > | respawn > | exec /sbin/busybox tcpsvd 0 1234 /usr/bin/git-daemon ... > > into /etc/event.d/git-daemon provides an alternative way to invoke > git-daemon and it's not more work than editing the xinetd setup. > > > Keeping stuff configurable and do not require stuff which is not > needed for core functionality is a good thing... Even when it means that we're shipping something that doesn't work out of the box? It seems rude to expect users to install git-daemon, try to enable it using the standard chkconfig method, then have to manually install xinetd. I do understand keeping requirements to a minimum, but I think that also needs to be balanced against making packages work as smoothly as possible by default. I appreciate your opinion Enrico and I'm certainly interested to know what other folks think about this before I add an xinetd requirement to git-daemon. At the least, having a consistent approach to this would help users and packagers. Currently, some packages require xinetd and others do not. I think that leaves users of our packages in an uncomfortable position. If the goal really is to cater to users wanting to run the daemon via xinetd, upstart, init.d, etc, having subpackages for each would seem to be the way to go. But I'm certainly not interested in trying to play that game. I think that we should make a sane default choice for a given package and ensure that it works. At worst, those wanting to use some method other than xinetd are stuck with having xinetd pulled in (which costs ~376K of disk space). -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Once ... in the wilds of Afghanistan, I lost my corkscrew, and we were forced to live on nothing but food and water for days. -- W.C. Fields -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Tue May 26 22:29:37 2009 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 27 May 2009 00:29:37 +0200 Subject: [Fedora-packaging] Re: Requiring xinetd when placing files into /etc/xinetd.d In-Reply-To: <20090526214157.GE4433@inocybe.localdomain> (Todd Zullinger's message of "Tue\, 26 May 2009 17\:41\:57 -0400") References: <20090526161437.GT4433@inocybe.localdomain> <87ljojpo90.fsf@sheridan.bigo.ensc.de> <20090526214157.GE4433@inocybe.localdomain> Message-ID: <87hbz7pkfi.fsf@sheridan.bigo.ensc.de> Todd Zullinger writes: > Even when it means that we're shipping something that doesn't work out > of the box? Yes. When somebody wants to run git-daemon he has to think about security implications and has to know technical parameters (e.g. ports which must be opened in the firewall). This includes reading documentation where the requirements can be explicitly mentioned. For more end-user specific services some special packaging (e.g. moving core stuff into -core subpackage and providing initscripts in the main package) can be done. But for git-daemon this is overkill imo... > I do understand keeping requirements to a minimum, but I think that > also needs to be balanced against making packages work as smoothly as > possible by default. For me, preconfigured stuff like | user = nobody | server_args = ... -path=/var/lib/git is painful to handle (running as 'nobody' might be a temporary hack but nothing for production usage, and the path simply does not fit into my system). Writing setup/initscripts from scratch is here easier than to cope with the existing ones. Enrico From cweyl at alumni.drew.edu Fri May 29 07:18:17 2009 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Fri, 29 May 2009 00:18:17 -0700 Subject: [Fedora-packaging] Generic filtering macros... Message-ID: <7dd7ab490905290018n6c0e9f65l2aeede83c0cbbb84@mail.gmail.com> So, I have a number of macros that taken together create a generic filtering system for our autoprov/dep system. http://fedorapeople.org/~cweyl/macros.perl.local http://fedorapeople.org/~cweyl/macros.perl (suitable for ~/.rpmmacros inclusion) As this has a not insignificant amount to do with packaging, I'm looking for some feedback both on the macros themselves as well as on the best approach to get these included by default. (File a feature and get it approved? File a bug against rpm? A small ritual sacrifice? :)) Thanks! -Chris -- Chris Weyl Ex astris, scientia -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.klepek at brandforge.sk Sat May 30 18:38:17 2009 From: jan.klepek at brandforge.sk (Jan Klepek) Date: Sat, 30 May 2009 20:38:17 +0200 Subject: [Fedora-packaging] redmine package review Message-ID: <1243708697.3580.48.camel@localhost.localdomain> Hi, I'm working on unofficial package review for redmine ( https://bugzilla.redhat.com/show_bug.cgi?id=499959 ). Redmine is written in ruby and is using rubygem-actionwebservice, which is shipped with redmine. Rubygem-actionwebservice was abandoned by upstream like two years ago, and same happened for fedora package. My question is if redmine package should install it on system or it should be considered as blocker, until upstream of redmine migrate to activeresource. Second question is when redmine contains plugins which are separate applications/libraries (coderay is used by redmine for example) this applications/libraries should be shipped within this package or should be shipped in it's own package (and package should be created when it doesn't exists)? My thoughts are that it should be shipped separately, so it could be used by more applications. Thanks for help, Jan Klepek From cweyl at alumni.drew.edu Sun May 31 20:06:32 2009 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Sun, 31 May 2009 13:06:32 -0700 Subject: [Fedora-packaging] Re: Generic filtering macros... In-Reply-To: <7dd7ab490905290018n6c0e9f65l2aeede83c0cbbb84@mail.gmail.com> References: <7dd7ab490905290018n6c0e9f65l2aeede83c0cbbb84@mail.gmail.com> Message-ID: <7dd7ab490905311306k307dec89raab86d20d566db9@mail.gmail.com> On Fri, May 29, 2009 at 12:18 AM, Chris Weyl wrote: > So, I have a number of macros that taken together create a generic > filtering system for our autoprov/dep system. > > http://fedorapeople.org/~cweyl/macros.perl.local > http://fedorapeople.org/~cweyl/macros.perl(suitable for ~/.rpmmacros inclusion) > > As this has a not insignificant amount to do with packaging, I'm looking > for some feedback both on the macros themselves as well as on the best > approach to get these included by default. (File a feature and get it > approved? File a bug against rpm? A small ritual sacrifice? :)) > Following up to myself here, I've created a feature page that I intend to submit to FESCo: https://fedoraproject.org/wiki/Features/BetterRpmAutoReqProvFiltering Any feedback, good or bad, would be appreciated. -Chris -- Chris Weyl Ex astris, scientia -------------- next part -------------- An HTML attachment was scrubbed... URL: From forum at ru.bir.ru Sun May 31 21:18:30 2009 From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus)) Date: Mon, 01 Jun 2009 01:18:30 +0400 Subject: [Fedora-packaging] Re: Phase out buildroot? In-Reply-To: References: <4A14A45A.6080903@gmail.com> <20090521034700.GS4646@angus.ind.WPI.EDU> <4A14EF45.2040407@gmail.com> <20090521063948.GN5211@angus.ind.WPI.EDU> <4A158519.5050700@gmail.com> Message-ID: Panu Matilainen wrote: > There are no changes to rpm in this area that I recall. This could be > done by just tweaking the build templates in redhat-rpm-config though, > something like this in /usr/lib/rpm/redhat/macros: > > %__spec_install_pre %{___build_pre}\ > [ "$RPM_BUILD_ROOT" != "/" ] && rm -rf "${RPM_BUILD_ROOT}"\ > %{nil} This is very good idea. With remove BuildRoot from spec it is brilliant. AltLinux guidelines prohibit use BuildRoot tag in spec. Pavel.