From lutter at redhat.com Mon Nov 3 19:04:54 2008 From: lutter at redhat.com (David Lutterkort) Date: Mon, 03 Nov 2008 11:04:54 -0800 Subject: [Fedora-packaging] rubygem with extension written in C In-Reply-To: <490B46F7.3070906@ioa.s.u-tokyo.ac.jp> References: <490B46F7.3070906@ioa.s.u-tokyo.ac.jp> Message-ID: <1225739094.8424.7.camel@localhost.localdomain> On Sat, 2008-11-01 at 02:57 +0900, Mamoru Tasaka wrote: > Hello, all: > > During reviews (and also on my package) I met with some troubles > when packaging Ruby Gems containing extension libraries written > in C. > > Would you look at my proposition written in the following URL? > https://fedoraproject.org/wiki/User:Mtasaka/PackagingDrafts/RubyGem_with_C_code > > Any comments will be appreciated. Thank you in advance. First off, I think this is a very good step in the right direction. A couple of questions: * Is the example snippet from a spec file meant only for gems with extension libraries or for all gems ? * Do you have a full example somewhere that follows your recommendations ? * As for missing files in ext/, I would be happy either way; since the C sources for extensions are usually very small, it would be ok to install them as part of the rubygem- package. OTOH, I don't see much danger in leaving them out from the rubygem. The main point of building a rubygem- RPM is so that users can satisfy rubygem-level dependencies for other rubygems with the RPM-installed rubygem, i.e. if gem A is packaged as an rpm, and a user wants to 'gem install B' where B has a gem-level dep on A, that should still work. Users shouldn't expect that a 'gem uninstall A' would work - it would confuse RPM, anyway. David From mtasaka at ioa.s.u-tokyo.ac.jp Tue Nov 4 10:46:20 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 04 Nov 2008 19:46:20 +0900 Subject: [Fedora-packaging] rubygem with extension written in C In-Reply-To: <1225739094.8424.7.camel@localhost.localdomain> References: <490B46F7.3070906@ioa.s.u-tokyo.ac.jp> <1225739094.8424.7.camel@localhost.localdomain> Message-ID: <491027FC.7030601@ioa.s.u-tokyo.ac.jp> Thank you for reply. David Lutterkort wrote, at 11/04/2008 04:04 AM +9:00: > First off, I think this is a very good step in the right direction. A > couple of questions: > > * Is the example snippet from a spec file meant only for gems with > extension libraries or for all gems ? - Currently only with extention libraries. If rpm created from gem file is completely noarch, gem file can be installed under %{buildroot}%{gemdir} directly. (However, of course, there is no problem if we first install gem files under %{_builddir} first even if it is noarch) > * Do you have a full example somewhere that follows your > recommendations ? - I tried to rewrite spec files in Fedora related to rubygem, which I put under http://mtasaka.fedorapeople.org/rubygem_specs/ The easiest example is http://mtasaka.fedorapeople.org/rubygem_specs/rubygem-fastthread.spec > * As for missing files in ext/, I would be happy either way; since > the C sources for extensions are usually very small, it would be > ok to install them as part of the rubygem- package. OTOH, I > don't see much danger in leaving them out from the rubygem. The > main point of building a rubygem- RPM is so that users can > satisfy rubygem-level dependencies for other rubygems with the > RPM-installed rubygem, i.e. if gem A is packaged as an rpm, and > a user wants to 'gem install B' where B has a gem-level dep on > A, that should still work. Users shouldn't expect that a 'gem > uninstall A' would work - it would confuse RPM, anyway. - Thanks. I added some guideline proposal about files under ext/ C codes with reflecting your commends. > David Regards, Mamoru From lutter at redhat.com Thu Nov 6 03:09:44 2008 From: lutter at redhat.com (David Lutterkort) Date: Wed, 05 Nov 2008 19:09:44 -0800 Subject: [Fedora-packaging] rubygem with extension written in C In-Reply-To: <491027FC.7030601@ioa.s.u-tokyo.ac.jp> References: <490B46F7.3070906@ioa.s.u-tokyo.ac.jp> <1225739094.8424.7.camel@localhost.localdomain> <491027FC.7030601@ioa.s.u-tokyo.ac.jp> Message-ID: <1225940984.15894.24.camel@localhost.localdomain> On Tue, 2008-11-04 at 19:46 +0900, Mamoru Tasaka wrote: > Thank you for reply. > > David Lutterkort wrote, at 11/04/2008 04:04 AM +9:00: > > > First off, I think this is a very good step in the right direction. A > > couple of questions: > > > > * Is the example snippet from a spec file meant only for gems with > > extension libraries or for all gems ? > > - Currently only with extention libraries. > If rpm created from gem file is completely noarch, gem file can be installed > under %{buildroot}%{gemdir} directly. > (However, of course, there is no problem if we first install gem files > under %{_builddir} first even if it is noarch) Agreed. Ultimately, it would be nice to support more of this with some stock macros; but that has nothing to do with your proposal. > > * Do you have a full example somewhere that follows your > > recommendations ? > > - I tried to rewrite spec files in Fedora related to rubygem, which I put > under > http://mtasaka.fedorapeople.org/rubygem_specs/ > The easiest example is > http://mtasaka.fedorapeople.org/rubygem_specs/rubygem-fastthread.spec Nice, just tried it and it does produce a -debuginfo, complete with sources :) > > * As for missing files in ext/, I would be happy either way; since > > the C sources for extensions are usually very small, it would be > > ok to install them as part of the rubygem- package. OTOH, I > > don't see much danger in leaving them out from the rubygem. The > > main point of building a rubygem- RPM is so that users can > > satisfy rubygem-level dependencies for other rubygems with the > > RPM-installed rubygem, i.e. if gem A is packaged as an rpm, and > > a user wants to 'gem install B' where B has a gem-level dep on > > A, that should still work. Users shouldn't expect that a 'gem > > uninstall A' would work - it would confuse RPM, anyway. > > - Thanks. I added some guideline proposal about files under ext/ C codes with > reflecting your commends. The proposal looks really good - +1 from me. David From mtasaka at ioa.s.u-tokyo.ac.jp Thu Nov 6 08:30:06 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 06 Nov 2008 17:30:06 +0900 Subject: [Fedora-packaging] rubygem with extension written in C In-Reply-To: <1225940984.15894.24.camel@localhost.localdomain> References: <490B46F7.3070906@ioa.s.u-tokyo.ac.jp> <1225739094.8424.7.camel@localhost.localdomain> <491027FC.7030601@ioa.s.u-tokyo.ac.jp> <1225940984.15894.24.camel@localhost.localdomain> Message-ID: <4912AB0E.7080101@ioa.s.u-tokyo.ac.jp> Thank you again. David Lutterkort wrote, at 11/06/2008 12:09 PM +9:00: > On Tue, 2008-11-04 at 19:46 +0900, Mamoru Tasaka wrote: >> David Lutterkort wrote, at 11/04/2008 04:04 AM +9:00: >>> * Is the example snippet from a spec file meant only for gems with >>> extension libraries or for all gems ? >> - Currently only with extention libraries. >> If rpm created from gem file is completely noarch, gem file can be installed >> under %{buildroot}%{gemdir} directly. >> (However, of course, there is no problem if we first install gem files >> under %{_builddir} first even if it is noarch) > > Agreed. Ultimately, it would be nice to support more of this with some > stock macros; but that has nothing to do with your proposal. Currently I have no idea about what macros can be defined here, however for now I think we can think of this later. > The proposal looks really good - +1 from me. Thank you! One more issue: I found that even for non-Gem packages many packages use "extconf.rb" to create C library, and in such case "export CONFIGURE_ARGS=..." method can also be applied. So I wrote another proposal to use this method even for non-Gem ruby packages (on the last of : https://fedoraproject.org/wiki/User:Mtasaka/PackagingDrafts/RubyGem_with_C_code ) I would want to know how you would think about this. Regards, Mamoru From lutter at redhat.com Thu Nov 6 16:27:04 2008 From: lutter at redhat.com (David Lutterkort) Date: Thu, 06 Nov 2008 08:27:04 -0800 Subject: [Fedora-packaging] rubygem with extension written in C In-Reply-To: <4912AB0E.7080101@ioa.s.u-tokyo.ac.jp> References: <490B46F7.3070906@ioa.s.u-tokyo.ac.jp> <1225739094.8424.7.camel@localhost.localdomain> <491027FC.7030601@ioa.s.u-tokyo.ac.jp> <1225940984.15894.24.camel@localhost.localdomain> <4912AB0E.7080101@ioa.s.u-tokyo.ac.jp> Message-ID: <1225988824.15894.26.camel@localhost.localdomain> On Thu, 2008-11-06 at 17:30 +0900, Mamoru Tasaka wrote: > One more issue: > I found that even for non-Gem packages many packages use "extconf.rb" > to create C library, and in such case "export CONFIGURE_ARGS=..." method > can also be applied. > > So I wrote another proposal to use this method even for non-Gem ruby packages > (on the last of : > https://fedoraproject.org/wiki/User:Mtasaka/PackagingDrafts/RubyGem_with_C_code > ) > I would want to know how you would think about this. Yes, that makes perfect sense, and should be required for gem and non-gem packages in the same way. David From mtasaka at ioa.s.u-tokyo.ac.jp Thu Nov 6 17:26:07 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Fri, 07 Nov 2008 02:26:07 +0900 Subject: [Fedora-packaging] rubygem with extension written in C In-Reply-To: <1225988824.15894.26.camel@localhost.localdomain> References: <490B46F7.3070906@ioa.s.u-tokyo.ac.jp> <1225739094.8424.7.camel@localhost.localdomain> <491027FC.7030601@ioa.s.u-tokyo.ac.jp> <1225940984.15894.24.camel@localhost.localdomain> <4912AB0E.7080101@ioa.s.u-tokyo.ac.jp> <1225988824.15894.26.camel@localhost.localdomain> Message-ID: <491328AF.8000903@ioa.s.u-tokyo.ac.jp> David Lutterkort wrote, at 11/07/2008 01:27 AM +9:00: > On Thu, 2008-11-06 at 17:30 +0900, Mamoru Tasaka wrote: >> One more issue: >> I found that even for non-Gem packages many packages use "extconf.rb" >> to create C library, and in such case "export CONFIGURE_ARGS=..." method >> can also be applied. >> >> So I wrote another proposal to use this method even for non-Gem ruby packages >> (on the last of : >> https://fedoraproject.org/wiki/User:Mtasaka/PackagingDrafts/RubyGem_with_C_code >> ) >> I would want to know how you would think about this. > > Yes, that makes perfect sense, and should be required for gem and > non-gem packages in the same way. > > David Thank you. Again I updated my proposition wiki with reflecting your comment. I think the current contents can be included in the formal packaging guidelines. (The URL is still: https://fedoraproject.org/wiki/User:Mtasaka/PackagingDrafts/RubyGem_with_C_code ) Regards, Mamoru From gnu.boi at gmail.com Sat Nov 8 11:32:27 2008 From: gnu.boi at gmail.com (gnu boi) Date: Sat, 8 Nov 2008 17:17:27 +0545 Subject: [Fedora-packaging] Hi Message-ID: <775aa32d0811080332l7737b763q5b1b321c1f452a48@mail.gmail.com> hi to all -------------- next part -------------- An HTML attachment was scrubbed... URL: From kanarip at kanarip.com Sat Nov 8 13:47:05 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sat, 08 Nov 2008 14:47:05 +0100 Subject: [Fedora-packaging] Packaging rubygem-passenger and "mod_rails" Message-ID: <49159859.7070007@kanarip.com> Hi all, I'm interested in some feedback and hints as to how to tackle this problem I'm seeing: rubygem-passenger upstream is a Ruby on Rails deployment utility that practically makes installing a new version of a Ruby on Rails web application a drag-and-drop action. Anyway; One part of the upstream release is the Ruby Gem - which, when installed, offers a command that says; passenger-install-apache2-module which is mod_rails/mod_rack, and can be loaded in httpd so that it's all nice and integrated and nifty. Problem is, "passenger-install-apache2-module" is building the .so and now I'm seeing a chicken-or-egg problem; I need the gem to be installed to be able to build the httpd module, and the httpd module is built from the same source(s). I would appreciate some advice as to if splitting the packages and build-requiring the rubygem-passenger package for the mod_rails package is the way to go, or whether there's another route. Thanks in advance, Kind regards, Jeroen van Meeuwen -kanarip From mtasaka at ioa.s.u-tokyo.ac.jp Sat Nov 8 15:58:27 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sun, 09 Nov 2008 00:58:27 +0900 Subject: [Fedora-packaging] Packaging rubygem-passenger and "mod_rails" In-Reply-To: <49159859.7070007@kanarip.com> References: <49159859.7070007@kanarip.com> Message-ID: <4915B723.50201@ioa.s.u-tokyo.ac.jp> Jeroen van Meeuwen wrote, at 11/08/2008 10:47 PM +9:00: > rubygem-passenger upstream is a Ruby on Rails deployment utility that > practically makes installing a new version of a Ruby on Rails web > application a drag-and-drop action. Anyway; > > One part of the upstream release is the Ruby Gem - which, when > installed, offers a command that says; > > passenger-install-apache2-module > > which is mod_rails/mod_rack, and can be loaded in httpd so that it's all > nice and integrated and nifty. > > Problem is, "passenger-install-apache2-module" is building the .so and > now I'm seeing a chicken-or-egg problem; > > I need the gem to be installed to be able to build the httpd module, and > the httpd module is built from the same source(s). Hello. I don't know rubygem-passenger at all and only tried to write a spec file for this package very quickly (so I don't know how/if my spec file works), however I guess my quick draft can be useful: http://mtasaka.fedorapeople.org/rubygem_specs/rubygem-passenger.spec ! note: Currently this spec file makes many rpmlint errors or warnings but I just wrote this spec file quickly and didn't try to suppress these messages. ! note 2: Also please refer to the current discussion about rubygems with C code: https://www.redhat.com/archives/fedora-packaging/2008-November/msg00000.html https://fedoraproject.org/wiki/User:Mtasaka/PackagingDrafts/RubyGem_with_C_code Regards, Mamoru From mtasaka at ioa.s.u-tokyo.ac.jp Sat Nov 8 16:09:51 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sun, 09 Nov 2008 01:09:51 +0900 Subject: [Fedora-packaging] Packaging rubygem-passenger and "mod_rails" In-Reply-To: <4915B723.50201@ioa.s.u-tokyo.ac.jp> References: <49159859.7070007@kanarip.com> <4915B723.50201@ioa.s.u-tokyo.ac.jp> Message-ID: <4915B9CF.1040105@ioa.s.u-tokyo.ac.jp> Mamoru Tasaka wrote, at 11/09/2008 12:58 AM +9:00: > Jeroen van Meeuwen wrote, at 11/08/2008 10:47 PM +9:00: > >> rubygem-passenger upstream is a Ruby on Rails deployment utility that >> practically makes installing a new version of a Ruby on Rails web >> application a drag-and-drop action. Anyway; >> >> One part of the upstream release is the Ruby Gem - which, when >> installed, offers a command that says; >> >> passenger-install-apache2-module >> >> which is mod_rails/mod_rack, and can be loaded in httpd so that it's >> all nice and integrated and nifty. >> >> Problem is, "passenger-install-apache2-module" is building the .so and >> now I'm seeing a chicken-or-egg problem; >> >> I need the gem to be installed to be able to build the httpd module, >> and the httpd module is built from the same source(s). > > Hello. > > I don't know rubygem-passenger at all and only tried to write a spec file > for this package very quickly (so I don't know how/if my spec file works), > however I guess my quick draft can be useful: > > http://mtasaka.fedorapeople.org/rubygem_specs/rubygem-passenger.spec > > ! note: > Currently this spec file makes many rpmlint errors or warnings but > I just wrote this spec file quickly and didn't try to suppress these > messages. > > ! note 2: > Also please refer to the current discussion about rubygems with C code: > https://www.redhat.com/archives/fedora-packaging/2008-November/msg00000.html > > https://fedoraproject.org/wiki/User:Mtasaka/PackagingDrafts/RubyGem_with_C_code > I guess ruby-devel or so is missing from BuildRequires and perhaps some more fixes are needed.... Mamoru From kanarip at kanarip.com Sat Nov 8 22:15:04 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sat, 08 Nov 2008 23:15:04 +0100 Subject: [Fedora-packaging] Packaging rubygem-passenger and "mod_rails" In-Reply-To: <4915B9CF.1040105@ioa.s.u-tokyo.ac.jp> References: <49159859.7070007@kanarip.com> <4915B723.50201@ioa.s.u-tokyo.ac.jp> <4915B9CF.1040105@ioa.s.u-tokyo.ac.jp> Message-ID: <49160F68.2060200@kanarip.com> Mamoru Tasaka wrote: >> I don't know rubygem-passenger at all and only tried to write a spec file >> for this package very quickly (so I don't know how/if my spec file >> works), >> however I guess my quick draft can be useful: >> >> http://mtasaka.fedorapeople.org/rubygem_specs/rubygem-passenger.spec >> >> ! note: >> Currently this spec file makes many rpmlint errors or warnings but >> I just wrote this spec file quickly and didn't try to suppress these >> messages. >> >> ! note 2: >> Also please refer to the current discussion about rubygems with C code: >> https://www.redhat.com/archives/fedora-packaging/2008-November/msg00000.html >> >> https://fedoraproject.org/wiki/User:Mtasaka/PackagingDrafts/RubyGem_with_C_code >> > > I guess ruby-devel or so is missing from BuildRequires and perhaps > some more fixes are needed.... > > Mamoru Hi Mamoru, I've picked this up and there were some very useful hints in the spec you linked me. I'm just about to finish this package up for initial review submission along with the required rubygem-rake... Can I add you to the CC: when I submit it and ask you if you can take a sneak peak at the .spec file before anyone else sinks his teeth into the review? Kind regards, Jeroen van Meeuwen -kanarip From mtasaka at ioa.s.u-tokyo.ac.jp Sun Nov 9 17:51:57 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Mon, 10 Nov 2008 02:51:57 +0900 Subject: [Fedora-packaging] Packaging rubygem-passenger and "mod_rails" In-Reply-To: <49160F68.2060200@kanarip.com> References: <49159859.7070007@kanarip.com> <4915B723.50201@ioa.s.u-tokyo.ac.jp> <4915B9CF.1040105@ioa.s.u-tokyo.ac.jp> <49160F68.2060200@kanarip.com> Message-ID: <4917233D.2030108@ioa.s.u-tokyo.ac.jp> Jeroen van Meeuwen wrote, at 11/09/2008 07:15 AM +9:00: > Hi Mamoru, > > I've picked this up and there were some very useful hints in the spec > you linked me. I'm just about to finish this package up for initial > review submission along with the required rubygem-rake... Can I add you > to the CC: when I submit it and ask you if you can take a sneak peak at > the .spec file before anyone else sinks his teeth into the review? As you are already seeing this, I have assigned your review requests to myself. Regards, Mamoru From cchance at redhat.com Sun Nov 9 23:28:47 2008 From: cchance at redhat.com (Caius Carlos CHANCE) Date: Sun, 9 Nov 2008 18:28:47 -0500 (EST) Subject: [Fedora-packaging] Hi In-Reply-To: <775aa32d0811080332l7737b763q5b1b321c1f452a48@mail.gmail.com> Message-ID: <16689775.131226273325306.JavaMail.cchance@sashimi.bne.redhat.com> welcome :) ----- "gnu boi" wrote: > hi to all > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging -- Caius Carlos Chance < cchance AT redhat DOT com > Red Hat APAC | http://apac.redhat.com/disclaimer/ From mtasaka at ioa.s.u-tokyo.ac.jp Mon Nov 10 17:08:35 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 11 Nov 2008 02:08:35 +0900 Subject: [Fedora-packaging] rubygem with extension written in C In-Reply-To: <491328AF.8000903@ioa.s.u-tokyo.ac.jp> References: <490B46F7.3070906@ioa.s.u-tokyo.ac.jp> <1225739094.8424.7.camel@localhost.localdomain> <491027FC.7030601@ioa.s.u-tokyo.ac.jp> <1225940984.15894.24.camel@localhost.localdomain> <4912AB0E.7080101@ioa.s.u-tokyo.ac.jp> <1225988824.15894.26.camel@localhost.localdomain> <491328AF.8000903@ioa.s.u-tokyo.ac.jp> Message-ID: <49186A93.3070204@ioa.s.u-tokyo.ac.jp> Mamoru Tasaka wrote, at 11/07/2008 02:26 AM +9:00: > David Lutterkort wrote, at 11/07/2008 01:27 AM +9:00: >> Yes, that makes perfect sense, and should be required for gem and >> non-gem packages in the same way. >> >> David > > Thank you. Again I updated my proposition wiki with reflecting your comment. > I think the current contents can be included in the formal packaging guidelines. > (The URL is still: > https://fedoraproject.org/wiki/User:Mtasaka/PackagingDrafts/RubyGem_with_C_code ) I moved the wiki to https://fedoraproject.org/wiki/PackagingDrafts/RubyGem_with_C_code (old URL will be redirected) and added this to https://fedoraproject.org/wiki/PackagingDrafts/DraftsTodo Regards, Mamoru From uwe at kubosch.no Tue Nov 11 10:27:16 2008 From: uwe at kubosch.no (Uwe Kubosch) Date: Tue, 11 Nov 2008 11:27:16 +0100 Subject: [Fedora-packaging] Hi all! Message-ID: <1226399236.4040.31.camel@localhost> Hi all! I have just submitted zfs-fuse to Fedora and i am looking forward to further contributing to Fedora! When can I expect .fc10 packages to be signed? After Fedora 10 release on the 25th? -- With kind regards, Uwe Kubosch Norway -------------- 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 mefoster at gmail.com Wed Nov 12 12:36:52 2008 From: mefoster at gmail.com (Mary Ellen Foster) Date: Wed, 12 Nov 2008 13:36:52 +0100 Subject: [Fedora-packaging] *.h files in a directory under %{_libdir}? Message-ID: Yesterday, there was a bug report on pl (SWI Prolog), a package that I co-maintain (https://bugzilla.redhat.com/show_bug.cgi?id=471071), and I'm not sure what to do about it. I guess SWI assumes that it will be installed with all of its libraries and related files into a single directory structure, not following the normal LSB file layout. In the pl-devel package at the moment, the libraries etc. are under %{_libdir}/pl-%{version}, and this directory also ends up as the "PLBASE", but the include files are in their LSB-approved place under /usr/include/pl. What is the best way to respond to this? I assume it's not encouraged to put *.h files into %{_libdir}, but on the other hand, breaking upstream assumptions like this isn't great either. PLBASE is documented as "the home directory of SWI-Prolog", but I'm not sure if it's actually guaranteed anywhere that .h files will be in this directory. Suggestions welcome! MEF -- Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/ Informatik 6: Robotics and Embedded Systems, Technische Universit?t M?nchen and ICCS, School of Informatics, University of Edinburgh From mtasaka at ioa.s.u-tokyo.ac.jp Wed Nov 12 12:59:21 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 12 Nov 2008 21:59:21 +0900 Subject: [Fedora-packaging] *.h files in a directory under %{_libdir}? In-Reply-To: References: Message-ID: <491AD329.4070208@ioa.s.u-tokyo.ac.jp> Mary Ellen Foster wrote, at 11/12/2008 09:36 PM +9:00: > Yesterday, there was a bug report on pl (SWI Prolog), a package that I > co-maintain (https://bugzilla.redhat.com/show_bug.cgi?id=471071), and > I'm not sure what to do about it. > > I guess SWI assumes that it will be installed with all of its > libraries and related files into a single directory structure, not > following the normal LSB file layout. In the pl-devel package at the > moment, the libraries etc. are under %{_libdir}/pl-%{version}, and > this directory also ends up as the "PLBASE", but the include files are > in their LSB-approved place under /usr/include/pl. Cannot this be handled by creating symlink? Regards, Mamoru From rc040203 at freenet.de Wed Nov 12 13:33:55 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 12 Nov 2008 14:33:55 +0100 Subject: [Fedora-packaging] *.h files in a directory under %{_libdir}? In-Reply-To: References: Message-ID: <1226496835.3752.356.camel@beck.corsepiu.local> On Wed, 2008-11-12 at 13:36 +0100, Mary Ellen Foster wrote: > Yesterday, there was a bug report on pl (SWI Prolog), a package that I > co-maintain (https://bugzilla.redhat.com/show_bug.cgi?id=471071), and > I'm not sure what to do about it. > > I guess SWI assumes that it will be installed with all of its > libraries and related files into a single directory structure, not > following the normal LSB file layout. In the pl-devel package at the > moment, the libraries etc. are under %{_libdir}/pl-%{version}, and > this directory also ends up as the "PLBASE", but the include files are > in their LSB-approved place under /usr/include/pl. > > What is the best way to respond to this? I assume it's not encouraged > to put *.h files into %{_libdir}, Right, but there also is no strict ban on doing so. More precisely, there are situations when it's advisable to put headers into some directory below %{_libdir}. For example, multilib architecture dependent header files are such a case (c.f. glibc2-devel). > but on the other hand, breaking > upstream assumptions like this isn't great either. PLBASE is > documented as "the home directory of SWI-Prolog", but I'm not sure if > it's actually guaranteed anywhere that .h files will be in this > directory. I would doubt this. In general, any user expectation on where a set of headers is installed will inevitably be wrong somewhere and will require adaptation of applications build-files/makefile. > Suggestions welcome! The decision is more or less up to you. I would not move them to %{_libdir}. Ralf From jani at mikkonen.biz Wed Nov 12 18:08:49 2008 From: jani at mikkonen.biz (Jani Mikkonen) Date: Wed, 12 Nov 2008 20:08:49 +0200 Subject: [Fedora-packaging] patching datafile locations for upstream projects ? Message-ID: Hello. Say, i have few packages - mostly games - that rely that same datafiles that are found from cwd (or same path as executable as binary) and im wondering what is the right way to patch these so i could make functional packages out of them. 1) just force the pwd to the datadirectory in .desktop file and not patch the code 2) hardcode the paths or atleast make them defineable at compiletime ? 3) something else ? From pertusus at free.fr Wed Nov 12 20:45:24 2008 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 12 Nov 2008 21:45:24 +0100 Subject: [Fedora-packaging] patching datafile locations for upstream projects ? In-Reply-To: References: Message-ID: <20081112204524.GA2791@free.fr> On Wed, Nov 12, 2008 at 08:08:49PM +0200, Jani Mikkonen wrote: > Hello. > > Say, i have few packages - mostly games - that rely that same > datafiles that are found from cwd (or same path as executable as > binary) and im wondering what is the right way to patch these so i > could make functional packages out of them. > > 1) just force the pwd to the datadirectory in .desktop file and not > patch the code > > 2) hardcode the paths or atleast make them defineable at compiletime ? I think that this is the best, and even better is to be able to define compile time defaults, and allow command line args or env setting to override the directory. -- Pat From timandahaf at gmail.com Wed Nov 12 22:40:20 2008 From: timandahaf at gmail.com (Timandahaf) Date: Wed, 12 Nov 2008 17:40:20 -0500 (EST) Subject: [Fedora-packaging] Vim compile options in Fedora Message-ID: Hello, In the past few versions of Fedora, the Vim package (for instance, vim-enhanced 2:7.1.291-1.fc9) is compiled with the "clientserver" option turned off. So each time I upgrade, I'm forced to get the rpm source and recompile vim with this option turned on. I don't know the rationale for this, because this is a very useful option, and turning it on doesn't really come at any cost as far as I know. I suspect this option would be useful for a wider range of users too. (For more info, simply start up vim by typing "vim" and use the ":version" command. It lists the features vim was compiled with.) My question is, how do I go about placing a request to have this feature turned on? (I apologize in advance if this is not the appropriate list to ask this question.) Thanks in advance! From pertusus at free.fr Wed Nov 12 23:15:58 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 13 Nov 2008 00:15:58 +0100 Subject: [Fedora-packaging] Vim compile options in Fedora In-Reply-To: References: Message-ID: <20081112231557.GB2791@free.fr> On Wed, Nov 12, 2008 at 05:40:20PM -0500, Timandahaf wrote: > Hello, > > My question is, how do I go about placing a request to have this feature > turned on? You should enter it in fedora bugzilla located at: https://bugzilla.redhat.com/ > (I apologize in advance if this is not the appropriate list to ask this > question.) This is the wrong list, this list is about packaging practices and guidelines, not about package issues. If you want more audience than bugzilla (which you should use first), fedora-devel-list would be more appropriate. -- Pat From jussi.lehtola at iki.fi Thu Nov 13 10:21:16 2008 From: jussi.lehtola at iki.fi (Jussi Lehtola) Date: Thu, 13 Nov 2008 12:21:16 +0200 Subject: [Fedora-packaging] BuildRequires: /lib/ld-linux.so.2 + mock Message-ID: <1226571676.6721.8.camel@politzer.theorphys.helsinki.fi> Hi, I'm packaging the open64 compiler, see https://bugzilla.redhat.com/show_bug.cgi?id=470830 . The problem I'm facing is that the prebuilt compiler needs /lib/ld-linux.so.2 to operate. The package builds fine in mock for rawhide and f9 x86_64, but fails for x86_64 f8, epel4 and epel5 with the error ERROR: Bad build req: No Package Found for /lib/ld-linux.so.2. Exiting. Is this a bug in mock or should I formulate the dependency in another way? One way would of course be BR: glibc.i386 but that is not good since glibc.i686 is installed on modern systems... -- Jussi Lehtola From ivazqueznet at gmail.com Thu Nov 13 10:33:37 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Thu, 13 Nov 2008 05:33:37 -0500 Subject: [Fedora-packaging] BuildRequires: /lib/ld-linux.so.2 + mock In-Reply-To: <1226571676.6721.8.camel@politzer.theorphys.helsinki.fi> References: <1226571676.6721.8.camel@politzer.theorphys.helsinki.fi> Message-ID: <1226572417.16027.164.camel@ignacio.lan> On Thu, 2008-11-13 at 12:21 +0200, Jussi Lehtola wrote: > I'm packaging the open64 compiler, see > https://bugzilla.redhat.com/show_bug.cgi?id=470830 . > > The problem I'm facing is that the prebuilt compiler > needs /lib/ld-linux.so.2 to operate. Wait, it needs a specific version of the loader? How does that work? -- 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 jussi.lehtola at iki.fi Thu Nov 13 11:12:09 2008 From: jussi.lehtola at iki.fi (Jussi Lehtola) Date: Thu, 13 Nov 2008 13:12:09 +0200 Subject: [Fedora-packaging] BuildRequires: /lib/ld-linux.so.2 + mock In-Reply-To: <1226572417.16027.164.camel@ignacio.lan> References: <1226571676.6721.8.camel@politzer.theorphys.helsinki.fi> <1226572417.16027.164.camel@ignacio.lan> Message-ID: <1226574729.6721.13.camel@politzer.theorphys.helsinki.fi> On Thu, 2008-11-13 at 05:33 -0500, Ignacio Vazquez-Abrams wrote: > On Thu, 2008-11-13 at 12:21 +0200, Jussi Lehtola wrote: > > I'm packaging the open64 compiler, see > > https://bugzilla.redhat.com/show_bug.cgi?id=470830 . > > > > The problem I'm facing is that the prebuilt compiler > > needs /lib/ld-linux.so.2 to operate. > > Wait, it needs a specific version of the loader? How does that work? Umm, I'm not sure about that; I added the dependency only because /lib/ld-linux.so.2 exists on all platforms I've tested so far (EPEL 4 - Fedora rawhide). /lib/ld-linux.so.2 is a symlink anyways, in Fedora 9 it points to ld-2.8.so and in EPEL 4 to ld-2.3.4.so... -- Jussi Lehtola From ivazqueznet at gmail.com Thu Nov 13 11:31:15 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Thu, 13 Nov 2008 06:31:15 -0500 Subject: [Fedora-packaging] BuildRequires: /lib/ld-linux.so.2 + mock In-Reply-To: <1226574729.6721.13.camel@politzer.theorphys.helsinki.fi> References: <1226571676.6721.8.camel@politzer.theorphys.helsinki.fi> <1226572417.16027.164.camel@ignacio.lan> <1226574729.6721.13.camel@politzer.theorphys.helsinki.fi> Message-ID: <1226575875.16027.167.camel@ignacio.lan> On Thu, 2008-11-13 at 13:12 +0200, Jussi Lehtola wrote: > On Thu, 2008-11-13 at 05:33 -0500, Ignacio Vazquez-Abrams wrote: > > On Thu, 2008-11-13 at 12:21 +0200, Jussi Lehtola wrote: > > > I'm packaging the open64 compiler, see > > > https://bugzilla.redhat.com/show_bug.cgi?id=470830 . > > > > > > The problem I'm facing is that the prebuilt compiler > > > needs /lib/ld-linux.so.2 to operate. > > > > Wait, it needs a specific version of the loader? How does that work? > > Umm, I'm not sure about that; I added the dependency only > because /lib/ld-linux.so.2 exists on all platforms I've tested so far > (EPEL 4 - Fedora rawhide). Does it build properly on all platforms if you remove the dependency? -- 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 rjones at redhat.com Thu Nov 13 11:38:36 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 13 Nov 2008 11:38:36 +0000 Subject: [Fedora-packaging] *.h files in a directory under %{_libdir}? In-Reply-To: References: Message-ID: <20081113113836.GA30369@amd.home.annexia.org> On Wed, Nov 12, 2008 at 01:36:52PM +0100, Mary Ellen Foster wrote: > What is the best way to respond to this? I assume it's not encouraged > to put *.h files into %{_libdir}, but on the other hand, breaking > upstream assumptions like this isn't great either. PLBASE is > documented as "the home directory of SWI-Prolog", but I'm not sure if > it's actually guaranteed anywhere that .h files will be in this > directory. It's funny this should come up because I noticed that some glib & gtk packages do this (when packaging for MinGW). eg: $ find /usr/i686-pc-mingw32/sys-root/mingw/lib/ -name '*.h' /usr/i686-pc-mingw32/sys-root/mingw/lib/sigc++-2.0/include/sigc++config.h /usr/i686-pc-mingw32/sys-root/mingw/lib/glib-2.0/include/glibconfig.h /usr/i686-pc-mingw32/sys-root/mingw/lib/gdkmm-2.4/include/gdkmmconfig.h /usr/i686-pc-mingw32/sys-root/mingw/lib/glibmm-2.4/include/glibmmconfig.h /usr/i686-pc-mingw32/sys-root/mingw/lib/gtkmm-2.4/include/gtkmmconfig.h /usr/i686-pc-mingw32/sys-root/mingw/lib/gtk-2.0/include/gdkconfig.h /usr/i686-pc-mingw32/sys-root/mingw/lib/giomm-2.4/include/giommconfig.h I left it as the upstream package was for now, but I'm sure this will come up during review. No idea what the right thing to do is or why those packages put header files in such a weird place ... Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From rc040203 at freenet.de Thu Nov 13 11:55:12 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 13 Nov 2008 12:55:12 +0100 Subject: [Fedora-packaging] *.h files in a directory under %{_libdir}? In-Reply-To: <20081113113836.GA30369@amd.home.annexia.org> References: <20081113113836.GA30369@amd.home.annexia.org> Message-ID: <1226577312.3752.389.camel@beck.corsepiu.local> On Thu, 2008-11-13 at 11:38 +0000, Richard W.M. Jones wrote: > On Wed, Nov 12, 2008 at 01:36:52PM +0100, Mary Ellen Foster wrote: > > What is the best way to respond to this? I assume it's not encouraged > > to put *.h files into %{_libdir}, but on the other hand, breaking > > upstream assumptions like this isn't great either. PLBASE is > > documented as "the home directory of SWI-Prolog", but I'm not sure if > > it's actually guaranteed anywhere that .h files will be in this > > directory. > > It's funny this should come up because I noticed that some glib & gtk > packages do this (when packaging for MinGW). eg: > > $ find /usr/i686-pc-mingw32/sys-root/mingw/lib/ -name '*.h' > /usr/i686-pc-mingw32/sys-root/mingw/lib/sigc++-2.0/include/sigc++config.h > /usr/i686-pc-mingw32/sys-root/mingw/lib/glib-2.0/include/glibconfig.h > /usr/i686-pc-mingw32/sys-root/mingw/lib/gdkmm-2.4/include/gdkmmconfig.h > /usr/i686-pc-mingw32/sys-root/mingw/lib/glibmm-2.4/include/glibmmconfig.h > /usr/i686-pc-mingw32/sys-root/mingw/lib/gtkmm-2.4/include/gtkmmconfig.h > /usr/i686-pc-mingw32/sys-root/mingw/lib/gtk-2.0/include/gdkconfig.h > /usr/i686-pc-mingw32/sys-root/mingw/lib/giomm-2.4/include/giommconfig.h > > I left it as the upstream package was for now, but I'm sure this will > come up during review. No idea what the right thing to do The place you list above. These headers are architecture dependent. i.e. they need to be placed under a multilib'ed directory to be installable on multilib'ed system. > is or why > those packages put header files in such a weird place ... cf. above. Ralf From berrange at redhat.com Thu Nov 13 12:30:02 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 13 Nov 2008 12:30:02 +0000 Subject: [Fedora-packaging] *.h files in a directory under %{_libdir}? In-Reply-To: <20081113113836.GA30369@amd.home.annexia.org> References: <20081113113836.GA30369@amd.home.annexia.org> Message-ID: <20081113123002.GD8200@redhat.com> On Thu, Nov 13, 2008 at 11:38:36AM +0000, Richard W.M. Jones wrote: > On Wed, Nov 12, 2008 at 01:36:52PM +0100, Mary Ellen Foster wrote: > > What is the best way to respond to this? I assume it's not encouraged > > to put *.h files into %{_libdir}, but on the other hand, breaking > > upstream assumptions like this isn't great either. PLBASE is > > documented as "the home directory of SWI-Prolog", but I'm not sure if > > it's actually guaranteed anywhere that .h files will be in this > > directory. > > It's funny this should come up because I noticed that some glib & gtk > packages do this (when packaging for MinGW). eg: > > $ find /usr/i686-pc-mingw32/sys-root/mingw/lib/ -name '*.h' > /usr/i686-pc-mingw32/sys-root/mingw/lib/sigc++-2.0/include/sigc++config.h > /usr/i686-pc-mingw32/sys-root/mingw/lib/glib-2.0/include/glibconfig.h > /usr/i686-pc-mingw32/sys-root/mingw/lib/gdkmm-2.4/include/gdkmmconfig.h > /usr/i686-pc-mingw32/sys-root/mingw/lib/glibmm-2.4/include/glibmmconfig.h > /usr/i686-pc-mingw32/sys-root/mingw/lib/gtkmm-2.4/include/gtkmmconfig.h > /usr/i686-pc-mingw32/sys-root/mingw/lib/gtk-2.0/include/gdkconfig.h > /usr/i686-pc-mingw32/sys-root/mingw/lib/giomm-2.4/include/giommconfig.h > > I left it as the upstream package was for now, but I'm sure this will > come up during review. No idea what the right thing to do is or why > those packages put header files in such a weird place ... That's not a problem - that's standard practice even on the native builds of those packages. The config.h files here contain various macros / defines that are variable according to the build host. By putting them in the lib directory, you can have -devel packages for both 32-bit and 64-bit versions installed in parallel & get the correct definitions. Now this isn't important to MinGW since we only target Win32, but there's no need to move them. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From jussi.lehtola at iki.fi Thu Nov 13 14:05:00 2008 From: jussi.lehtola at iki.fi (Jussi Lehtola) Date: Thu, 13 Nov 2008 16:05:00 +0200 Subject: [Fedora-packaging] BuildRequires: /lib/ld-linux.so.2 + mock In-Reply-To: <1226575875.16027.167.camel@ignacio.lan> References: <1226571676.6721.8.camel@politzer.theorphys.helsinki.fi> <1226572417.16027.164.camel@ignacio.lan> <1226574729.6721.13.camel@politzer.theorphys.helsinki.fi> <1226575875.16027.167.camel@ignacio.lan> Message-ID: <1226585100.6721.16.camel@politzer.theorphys.helsinki.fi> On Thu, 2008-11-13 at 06:31 -0500, Ignacio Vazquez-Abrams wrote: > On Thu, 2008-11-13 at 13:12 +0200, Jussi Lehtola wrote: > > On Thu, 2008-11-13 at 05:33 -0500, Ignacio Vazquez-Abrams wrote: > > > On Thu, 2008-11-13 at 12:21 +0200, Jussi Lehtola wrote: > > > > I'm packaging the open64 compiler, see > > > > https://bugzilla.redhat.com/show_bug.cgi?id=470830 . > > > > > > > > The problem I'm facing is that the prebuilt compiler > > > > needs /lib/ld-linux.so.2 to operate. > > > > > > Wait, it needs a specific version of the loader? How does that work? > > > > Umm, I'm not sure about that; I added the dependency only > > because /lib/ld-linux.so.2 exists on all platforms I've tested so far > > (EPEL 4 - Fedora rawhide). > > Does it build properly on all platforms if you remove the dependency? No, it fails on x86_64 with the following error: opencc -march=anyx86 -m64 -D_SGI_SOURCE -D_LANGUAGE_C -Wformat -funsigned-char -D__GNU_BUG_WORKAROUND -c -DVENDOR_OSP -DHAVE_CONFIG_H -DLONGLONG -I../../libelf/lib -I../../libelf -m64 -DTARG_X8664 -D__STDC_LIMIT_MACROS -DKEY -DOSP_OPT -DPATHSCALE_MERGE -DPSC_TO_OPEN64 -DSHARED_BUILD -std=gnu99 -D_GNU_SOURCE -fpic -I../include -O3 -fno-fast-stdlib -D_MIPSEL -D_LONGLONG -D_MIPS_SZINT=32 -D_MIPS_SZPTR=64 -D_MIPS_SZLONG=64 -D_LP64 -MMD -O2 -g -Wall -fexceptions -m64 ../../libelf/lib/32.fsize.c -o 32.fsize.o sh: /builddir/build/BUILD/open64-4.2-0/opt/open64/bin/opencc: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory -- Jussi Lehtola From olivierbourdon38 at free.fr Sun Nov 16 22:58:12 2008 From: olivierbourdon38 at free.fr (Olivier Bourdon) Date: Sun, 16 Nov 2008 23:58:12 +0100 Subject: [Fedora-packaging] Questions about dependencies in rpm packages Message-ID: <4920A584.5090007@free.fr> Hello I have been using this wonderfull Fedora distro since FC2 and I am currently using FC8 migrating soon to FC10 as soon as it becomes official at the end of the month One thing just started puzzling me is when I look at the list of dependencies of say BackupPC rpm -qp --requires BackupPC-3.0.0-3.fc8.noarch.rpm | sort | uniq -c | sort -n | tail 1 rsync 1 /usr/bin/perl 1 /usr/sbin/useradd 1 /usr/sbin/usermod 2 chkconfig 2 perl(Archive::Zip) 2 perl(Compress::Zlib) 2 perl(XML::RSS) 3 initscripts 5 /bin/sh why are some of these duplicated ? I can guess from the src.rpm file for initscripts that this comes from the lines: Requires(preun): initscripts, chkconfig Requires(post): initscripts, chkconfig, %{_sbindir}/usermod Requires(postun): initscripts but what about /bin/sh ?? Furthermore using a specific formating string like rpm -q -p --qf '[%{REQUIRENAME} %|REQUIREFLAGS?{%{REQUIREFLAGS:depflags} %{REQUIREVERSION}}:{}|\n]' BackupPC-3.0.0-3.fc8.noarch.rpm what should be the format string to potentially get the "differences" between all expressed dependencies Tried several choices but without much success Thanks for your time & help From ivazqueznet at gmail.com Mon Nov 17 01:27:19 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sun, 16 Nov 2008 20:27:19 -0500 Subject: [Fedora-packaging] Questions about dependencies in rpm packages In-Reply-To: <4920A584.5090007@free.fr> References: <4920A584.5090007@free.fr> Message-ID: <1226885239.736.9.camel@ignacio.lan> On Sun, 2008-11-16 at 23:58 +0100, Olivier Bourdon wrote: > Hello > > I have been using this wonderfull Fedora distro since FC2 and I am > currently using FC8 migrating soon to > FC10 as soon as it becomes official at the end of the month > > One thing just started puzzling me is when I look at the list of > dependencies of say BackupPC > 5 /bin/sh > > why are some of these duplicated ? > > I can guess from the src.rpm file for initscripts that this comes from > the lines: > Requires(preun): initscripts, chkconfig > Requires(post): initscripts, chkconfig, %{_sbindir}/usermod > Requires(postun): initscripts > > but what about /bin/sh ?? /bin/sh is the default interpreter for the script sections of the package, therefore it gets added once per script. -- 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 ghosler at redhat.com Mon Nov 17 15:18:26 2008 From: ghosler at redhat.com (Gregory Hosler) Date: Mon, 17 Nov 2008 23:18:26 +0800 Subject: [Fedora-packaging] f11 build error Message-ID: <49218B42.7010305@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, not sure if this is the correct fedora mailing list or not to bring this up on... I came across a build error on X64, in F-11 I have been seeing this exact bug report my other distso users that have been building my package on other distro x64 platforms, and so far I do not know what the solution might be. When i do a libtool build on a library, I am seeing the following: /bin/sh ../libtool --tag=CC --mode=link gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 - -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic - -Wno-pointer-sign -funsigned-char -shared -fpic -fPIC -o libgyachi.so gytreeview.o gy_config.o gyachi_lib.o parsecfg.o theme_support.o sound_plugin.o plugins.o -lgtk-x11-2.0 - -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo - -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lltdl - -lX11 -lpthread libtool: link: gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions - -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wno-pointer-sign - -funsigned-char -fpic -fPIC -o libgyachi.so gytreeview.o gy_config.o gyachi_lib.o parsecfg.o theme_support.o sound_plugin.o plugins.o -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 - -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype - -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lltdl -lX11 -lpthread /usr/lib/gcc/x86_64-redhat-linux/4.3.2/../../../../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' collect2: ld returned 1 exit status ld is not treating this as a shared library, rather it is treating this as a main program. Anyone else see this ? any ideas as to what i'm doing wrong, or what I might do to fix this ? For what it's worth, this exact package, and this exact libtool line builds correctly on F-10 and ALL other earlier revs (F-9, F-8, F-7, F-6, etc. etc...) on X64 (and other platforms...) If this is not the right mailing list to bring this up on, please point me at a more proper list! :) All the best, - -Greg - -- +---------------------------------------------------------------------+ Please also check the log file at "/dev/null" for additional information. (from /var/log/Xorg.setup.log) | Greg Hosler ghosler at redhat.com | +---------------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFJIYs/404fl/0CV/QRAqRCAKCw2hw4PTPirHnfJz9NcPFy3faiCACgsR8Z gBLp0kciNEYhcd+QuJLiGHU= =QNrm -----END PGP SIGNATURE----- From notting at redhat.com Mon Nov 17 15:21:14 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 17 Nov 2008 10:21:14 -0500 Subject: [Fedora-packaging] f11 build error In-Reply-To: <49218B42.7010305@redhat.com> References: <49218B42.7010305@redhat.com> Message-ID: <20081117152114.GB3026@nostromo.devel.redhat.com> Gregory Hosler (ghosler at redhat.com) said: > not sure if this is the correct fedora mailing list or not to bring this up on... fedora-devel-list may be better, CC'ing it. > I came across a build error on X64, in F-11 > > I have been seeing this exact bug report my other distso users that have been building my > package on other distro x64 platforms, and so far I do not know what the solution might be. > > When i do a libtool build on a library, I am seeing the following: > > /bin/sh ../libtool --tag=CC --mode=link gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 > - -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic > - -Wno-pointer-sign -funsigned-char -shared -fpic -fPIC -o libgyachi.so gytreeview.o > gy_config.o gyachi_lib.o parsecfg.o theme_support.o sound_plugin.o plugins.o -lgtk-x11-2.0 > - -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo > - -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lltdl > - -lX11 -lpthread > libtool: link: gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > - -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wno-pointer-sign > - -funsigned-char -fpic -fPIC -o libgyachi.so gytreeview.o gy_config.o gyachi_lib.o > parsecfg.o theme_support.o sound_plugin.o plugins.o -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 > - -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype > - -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lltdl -lX11 -lpthread > /usr/lib/gcc/x86_64-redhat-linux/4.3.2/../../../../lib64/crt1.o: In function `_start': > (.text+0x20): undefined reference to `main' > collect2: ld returned 1 exit status > > ld is not treating this as a shared library, rather it is treating this as a main program. The F-11 tree has libtool-2.2.6, instead of libtool-1.5 as in Fedora 10 and earlier. I suspect that's what's tripping you up. There were people who had done mass rebuilds with the new libtool - they might be able to point out common problems are and what the fixes are. Bill From ghosler at redhat.com Tue Nov 18 07:06:32 2008 From: ghosler at redhat.com (Gregory Hosler) Date: Tue, 18 Nov 2008 15:06:32 +0800 Subject: [Fedora-packaging] f11 build error In-Reply-To: <20081117152114.GB3026@nostromo.devel.redhat.com> References: <49218B42.7010305@redhat.com> <20081117152114.GB3026@nostromo.devel.redhat.com> Message-ID: <49226978.4080006@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bill Nottingham wrote: > Gregory Hosler (ghosler at redhat.com) said: >> not sure if this is the correct fedora mailing list or not to bring this up on... > > fedora-devel-list may be better, CC'ing it. I actually am subscribed to fedora-devel-list, and my first inclination was to post to THAT list, but my post never showed up (and neither did your cross post reply). Any idea on THAT ? All the best, - -Greg - -- +---------------------------------------------------------------------+ Please also check the log file at "/dev/null" for additional information. (from /var/log/Xorg.setup.log) | Greg Hosler ghosler at redhat.com | +---------------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFJIml2404fl/0CV/QRAqRSAJ4na75kV+8OE72gbr+QJCs2flKDoQCfblJ7 WGLdovUtNyeZvluTX7/T75c= =T4al -----END PGP SIGNATURE----- From paul at city-fan.org Tue Nov 18 07:46:40 2008 From: paul at city-fan.org (Paul Howarth) Date: Tue, 18 Nov 2008 07:46:40 +0000 Subject: [Fedora-packaging] f11 build error In-Reply-To: <49226978.4080006@redhat.com> References: <49218B42.7010305@redhat.com> <20081117152114.GB3026@nostromo.devel.redhat.com> <49226978.4080006@redhat.com> Message-ID: <20081118074640.44cbe43a@metropolis.intra.city-fan.org> On Tue, 18 Nov 2008 15:06:32 +0800 Gregory Hosler wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Bill Nottingham wrote: > > Gregory Hosler (ghosler at redhat.com) said: > >> not sure if this is the correct fedora mailing list or not to > >> bring this up on... > > > > fedora-devel-list may be better, CC'ing it. > > I actually am subscribed to fedora-devel-list, and my first > inclination was to post to THAT list, but my post never showed up > (and neither did your cross post reply). > > Any idea on THAT ? > > All the best, > > - -Greg I don't see your post there, but Bill's reply made it: https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01173.html Paul. From tcallawa at redhat.com Tue Nov 18 17:23:58 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 18 Nov 2008 12:23:58 -0500 Subject: [Fedora-packaging] rubygem with extension written in C In-Reply-To: <49186A93.3070204@ioa.s.u-tokyo.ac.jp> References: <490B46F7.3070906@ioa.s.u-tokyo.ac.jp> <1225739094.8424.7.camel@localhost.localdomain> <491027FC.7030601@ioa.s.u-tokyo.ac.jp> <1225940984.15894.24.camel@localhost.localdomain> <4912AB0E.7080101@ioa.s.u-tokyo.ac.jp> <1225988824.15894.26.camel@localhost.localdomain> <491328AF.8000903@ioa.s.u-tokyo.ac.jp> <49186A93.3070204@ioa.s.u-tokyo.ac.jp> Message-ID: <1227029039.4098.4.camel@localhost.localdomain> On Tue, 2008-11-11 at 02:08 +0900, Mamoru Tasaka wrote: > Mamoru Tasaka wrote, at 11/07/2008 02:26 AM +9:00: > > David Lutterkort wrote, at 11/07/2008 01:27 AM +9:00: > >> Yes, that makes perfect sense, and should be required for gem and > >> non-gem packages in the same way. > >> > >> David > > > > Thank you. Again I updated my proposition wiki with reflecting your comment. > > I think the current contents can be included in the formal packaging guidelines. > > (The URL is still: > > https://fedoraproject.org/wiki/User:Mtasaka/PackagingDrafts/RubyGem_with_C_code ) > > I moved the wiki to > https://fedoraproject.org/wiki/PackagingDrafts/RubyGem_with_C_code > (old URL will be redirected) and added this to > https://fedoraproject.org/wiki/PackagingDrafts/DraftsTodo Mamoru, The example in your draft does not seem to match your proposal. Can you provide an example to illustrate the new case for "Ruby Gem with extension libraries written in C"? Thanks, ~spot From nicolas.mailhot at laposte.net Tue Nov 18 22:07:04 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 18 Nov 2008 23:07:04 +0100 Subject: [Fedora-packaging] New Fedora fonts packaging guidelines Message-ID: <1227046025.29090.7.camel@arekh.okg> Hi, After several public and private discussions, I'm now formally proposing http://fedoraproject.org/wiki/PackagingDrafts/Fonts_packaging_automation for approval by FPC. Behdad Esfahbod and Jens Petersen have kindly reviewed this proposal and agree with it. Best regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From mtasaka at ioa.s.u-tokyo.ac.jp Wed Nov 19 17:37:57 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 20 Nov 2008 02:37:57 +0900 Subject: [Fedora-packaging] rubygem with extension written in C In-Reply-To: <1227029039.4098.4.camel@localhost.localdomain> References: <490B46F7.3070906@ioa.s.u-tokyo.ac.jp> <1225739094.8424.7.camel@localhost.localdomain> <491027FC.7030601@ioa.s.u-tokyo.ac.jp> <1225940984.15894.24.camel@localhost.localdomain> <4912AB0E.7080101@ioa.s.u-tokyo.ac.jp> <1225988824.15894.26.camel@localhost.localdomain> <491328AF.8000903@ioa.s.u-tokyo.ac.jp> <49186A93.3070204@ioa.s.u-tokyo.ac.jp> <1227029039.4098.4.camel@localhost.localdomain> Message-ID: <49244EF5.9060401@ioa.s.u-tokyo.ac.jp> Hello. First of all, thank you for discussing my propositon and giving me feedback. Then; Tom "spot" Callaway wrote, at 11/19/2008 02:23 AM +9:00: > On Tue, 2008-11-11 at 02:08 +0900, Mamoru Tasaka wrote: >> I moved the wiki to >> https://fedoraproject.org/wiki/PackagingDrafts/RubyGem_with_C_code >> (old URL will be redirected) and added this to >> https://fedoraproject.org/wiki/PackagingDrafts/DraftsTodo > > Mamoru, > > The example in your draft does not seem to match your proposal. Can you > provide an example to illustrate the new case for "Ruby Gem with > extension libraries written in C"? > > Thanks, > > ~spot It seems that the macro %{_builddir}/%{buildsubdir} seems confusing because this macros is not used in the examples. Actually what I meant here is - At prep stage the proper directory must be created under %_builddir to get C code compiled under the directory, not under %buildroot When %setup -q -c -T is used %_builddir/%name-%version is created (on my usual usage %_builddir is ~/rpmbuild/BUILD) and %buildsubdir is then defined as %name-%version. - Then Gem file must be installed there at %build stage, not under %buildroot. So as it seems that writing "%setup -q -c -T must be called" is more easy to grasp, I wrote a revised proposition (with the original one undeleted) [1] And I wrote one easiest example [2] I appreciate any feedback for this one. [1] https://fedoraproject.org/wiki/PackagingDrafts/RubyGem_with_C_code [2] http://mtasaka.fedorapeople.org/rubygem_specs/rubygem-fastthread.spec Thanks, Mamoru From dan at danny.cz Mon Nov 24 14:30:26 2008 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Mon, 24 Nov 2008 15:30:26 +0100 Subject: [Fedora-packaging] underscore in tryton modules Message-ID: <1227537026.3634.23.camel@eagle.danny.cz> Hi, do Tryton (http://www.tryton.org) module names in format trytond_full_module_name-$version.tar.gz (see full list at http://downloads.tryton.org/1.0/) qualify for the underscore exception from the Naming Guideline? Dan From tcallawa at redhat.com Mon Nov 24 14:53:40 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 24 Nov 2008 09:53:40 -0500 Subject: [Fedora-packaging] underscore in tryton modules In-Reply-To: <1227537026.3634.23.camel@eagle.danny.cz> References: <1227537026.3634.23.camel@eagle.danny.cz> Message-ID: <1227538420.4519.44.camel@localhost.localdomain> On Mon, 2008-11-24 at 15:30 +0100, Dan Hor?k wrote: > Hi, > > do Tryton (http://www.tryton.org) module names in format > trytond_full_module_name-$version.tar.gz (see full list at > http://downloads.tryton.org/1.0/) qualify for the underscore exception > from the Naming Guideline? I'm inclined to say no... how painful would it be to use - in the package name instead? ~spot From dan at danny.cz Mon Nov 24 15:04:22 2008 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Mon, 24 Nov 2008 16:04:22 +0100 Subject: [Fedora-packaging] underscore in tryton modules In-Reply-To: <1227538420.4519.44.camel@localhost.localdomain> References: <1227537026.3634.23.camel@eagle.danny.cz> <1227538420.4519.44.camel@localhost.localdomain> Message-ID: <1227539062.3634.31.camel@eagle.danny.cz> Tom "spot" Callaway p??e v Po 24. 11. 2008 v 09:53 -0500: > On Mon, 2008-11-24 at 15:30 +0100, Dan Hor?k wrote: > > Hi, > > > > do Tryton (http://www.tryton.org) module names in format > > trytond_full_module_name-$version.tar.gz (see full list at > > http://downloads.tryton.org/1.0/) qualify for the underscore exception > > from the Naming Guideline? > > I'm inclined to say no... how painful would it be to use - in the > package name instead? Not much, just to put more intelligence into the spec file generator :-) Can I somehow convert the "-" in a %name into "_" (stored in some other variable) directly in the spec? Dan From tcallawa at redhat.com Mon Nov 24 17:58:38 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 24 Nov 2008 12:58:38 -0500 Subject: [Fedora-packaging] underscore in tryton modules In-Reply-To: <1227539062.3634.31.camel@eagle.danny.cz> References: <1227537026.3634.23.camel@eagle.danny.cz> <1227538420.4519.44.camel@localhost.localdomain> <1227539062.3634.31.camel@eagle.danny.cz> Message-ID: <1227549518.4519.51.camel@localhost.localdomain> On Mon, 2008-11-24 at 16:04 +0100, Dan Hor?k wrote: > Tom "spot" Callaway p??e v Po 24. 11. 2008 v 09:53 -0500: > > On Mon, 2008-11-24 at 15:30 +0100, Dan Hor?k wrote: > > > Hi, > > > > > > do Tryton (http://www.tryton.org) module names in format > > > trytond_full_module_name-$version.tar.gz (see full list at > > > http://downloads.tryton.org/1.0/) qualify for the underscore exception > > > from the Naming Guideline? > > > > I'm inclined to say no... how painful would it be to use - in the > > package name instead? > > Not much, just to put more intelligence into the spec file generator :-) > > Can I somehow convert the "-" in a %name into "_" (stored in some other > variable) directly in the spec? %define truename foo_bar %define dashedname %(echo %{truename} | tr '_' '-') ~spot From ivazqueznet at gmail.com Mon Nov 24 17:39:01 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Mon, 24 Nov 2008 12:39:01 -0500 Subject: [Fedora-packaging] underscore in tryton modules In-Reply-To: <1227539062.3634.31.camel@eagle.danny.cz> References: <1227537026.3634.23.camel@eagle.danny.cz> <1227538420.4519.44.camel@localhost.localdomain> <1227539062.3634.31.camel@eagle.danny.cz> Message-ID: <1227548341.6715.32.camel@ignacio.lan> On Mon, 2008-11-24 at 16:04 +0100, Dan Hor?k wrote: > Tom "spot" Callaway p??e v Po 24. 11. 2008 v 09:53 -0500: > > On Mon, 2008-11-24 at 15:30 +0100, Dan Hor?k wrote: > > > Hi, > > > > > > do Tryton (http://www.tryton.org) module names in format > > > trytond_full_module_name-$version.tar.gz (see full list at > > > http://downloads.tryton.org/1.0/) qualify for the underscore exception > > > from the Naming Guideline? > > > > I'm inclined to say no... how painful would it be to use - in the > > package name instead? > > Not much, just to put more intelligence into the spec file generator :-) > > Can I somehow convert the "-" in a %name into "_" (stored in some other > variable) directly in the spec? %global oldname %(shell echo "%{name}" | sed 's/-/_/g') After %name has been defined, of course. -- 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 cra at WPI.EDU Sat Nov 29 18:00:05 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Sat, 29 Nov 2008 13:00:05 -0500 Subject: [Fedora-packaging] LGPLv2.1 vs. LGPLv2 Message-ID: <20081129180005.GB21793@angus.ind.WPI.EDU> I see that the Licensing page [1] treats LGPLv2 and LGPLv2.1 as the same, with a short name of "LGPLv2". Also, rpmlint complains about LGPLv2.1 in spec files. Why is this? I'm packaging a program [2] that uses 2.1 in the README/COPYING and 2 in the source code headers. I've received clarification on the license from the author as LGPLv2.1+, but now I wonder if it makes any difference since the spec tag would be the same in either case. [1] http://fedoraproject.org/wiki/Licensing [2] https://bugzilla.redhat.com/show_bug.cgi?id=465897 From bashton at brennanashton.com Sun Nov 30 00:42:10 2008 From: bashton at brennanashton.com (Brennan Ashton) Date: Sat, 29 Nov 2008 16:42:10 -0800 Subject: [Fedora-packaging] Packaging Javadocs for subpackages Message-ID: <981da310811291642p2c927a44yb0a2cf99d3414dfe@mail.gmail.com> I have been trying to package a java package called: jeuclid that has these subpackages: jeuclid-mathviewer jeuclid-fop feuclid-cli Do I create jeuclid-javadocs jeuclid-mathviewer-javadocs jeuclid-fop-javadocs feuclid-cli-javadocs or just jeuclid-javadocs --Brenan Ashton From dominik at greysector.net Sun Nov 30 12:29:59 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 30 Nov 2008 13:29:59 +0100 Subject: [Fedora-packaging] Packaging Javadocs for subpackages In-Reply-To: <981da310811291642p2c927a44yb0a2cf99d3414dfe@mail.gmail.com> References: <981da310811291642p2c927a44yb0a2cf99d3414dfe@mail.gmail.com> Message-ID: <20081130122959.GA30047@mokona.greysector.net> On Sunday, 30 November 2008 at 01:42, Brennan Ashton wrote: > I have been trying to package a java package called: > jeuclid > that has these subpackages: > jeuclid-mathviewer > jeuclid-fop > feuclid-cli > > Do I create > jeuclid-javadocs > jeuclid-mathviewer-javadocs > jeuclid-fop-javadocs > feuclid-cli-javadocs > > or just > jeuclid-javadocs I'd say it depends on their relative size. If the individual packages are small, it makes sense to bundle them into one bigger package. If they're about the same size as the software packages they document, then I'd split them. The Packaging Guidelines leave that to your discretion, so just use your common sense. 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 tcallawa at redhat.com Sun Nov 30 13:55:52 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 30 Nov 2008 08:55:52 -0500 Subject: [Fedora-packaging] LGPLv2.1 vs. LGPLv2 In-Reply-To: <20081129180005.GB21793@angus.ind.WPI.EDU> References: <20081129180005.GB21793@angus.ind.WPI.EDU> Message-ID: <1228053353.3463.69.camel@localhost.localdomain> On Sat, 2008-11-29 at 13:00 -0500, Chuck Anderson wrote: > I see that the Licensing page [1] treats LGPLv2 and LGPLv2.1 as the > same, with a short name of "LGPLv2". Also, rpmlint complains about > LGPLv2.1 in spec files. Why is this? Because v2 and v2.1 are the same thing. ~spot