packaging April 2009

packaging@lists.fedoraproject.org

32 participants
21 discussions

[Draft] The use of alternatives
by Dominik 'Rathann' Mierzejewski 25 May '09

25 May '09

Hi. 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. Regards, R. [1] https://fedoraproject.org/wiki/PackagingDrafts/UsingAlternatives -- 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"

3 4

ruby gem and library in C and debuginfo
by Dan Horák 01 May '09

01 May '09

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/<libname>" 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 cpio: rubygem-RedCloth-4.1.9/usr/lib/ruby/gems/1.8/gems/RedCloth-4.1.9/ext/redcloth_scan/ext/redcloth_scan/redcloth_inline.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_inline.c.rl: 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_scan.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_scan.c.rl: Cannot stat: No such file or directory Dan

2 1

Question about triggers
by Alan Evans 29 Apr '09

29 Apr '09

Can triggers be assigned to arbitrary capabilities or only by actual packages? All the docs I have read give me the impression that triggers are only triggered by packages and not arbitrary capabilities. Regards, -Alan

2 1

FPC meeting time proposal
by Jason L Tibbitts III 29 Apr '09

29 Apr '09

I wasn't sure if I should just directly mail this to the FPC members, but I figured this should work as well. At the last meeting those present discussed moving the meeting to better accommodate folks who have a tough time making it now. My understanding is that we can go at most two hours earlier because that puts the meeting at 8AM US Pacific time. We have to move at least one hour earlier to accommodate our friends in CET/CEST. The proposal discussed at the meeting is to move to Wednesdays at 15:00UTC. This would give us a two hour block and still give us (me) sufficient time before the FESCo meeting to get a report in. Unfortunately Toshio realized this morning that he would have to miss the first 30 minutes of that meeting due to another commitment. Thus I propose 15:30UTC on Wednesdays, which still gives us 90 minutes of channel time. I'd like to see a reply from each of the committee members indicating whether this works or not. Otherwise I'll mail you personally. - J<

7 12

Allowing only one package to provide a virtual capability
by Alan Evans 29 Apr '09

29 Apr '09

I am sorry if this is the wrong place but it seems that the rpm-list does not exist any more and this list looks to be the best fit otherwise. I am trying to create a few packages that all provide a virtual capability but would like to allow only one of these packages to be installed at a time. Has to be compatible with RPM 4.2 and greater. (RHEL4 and RHEL5) <snip> Name: package-a Provides: package-a config(package) </snip> <snip> Name: package-b Provides: package-b config(package) </snip> <snip> Name: package-c Provides: package-c config(package) </snip> I could obviously add Conflicts: package-b package-c to package package-a and so on, but every time I add a new package-X I have to manually go through my spec files and update the Conflicts tags. Again I suppose I could script the update but it seems less elegant. I tried: <snip> Name: package-a Provides: package-a config(package) Conflicts: config(package) </snip> But the result is: config(package) conflicts with package-a-1.1-1.svn20090428.noarch I thought I saw something like this in another list, will post link if I can find it. Where the goal was to only allow one package that provides a particular virtual capability. Anyone know how to accomplish this or if this is the wrong list can you direct me to a better resource? Regards, -Alan

3 2

Re: Agenda for the 2009-04-28 Packaging Committee meeting
by Ralf Corsepius 28 Apr '09

28 Apr '09

Jason L Tibbitts III wrote: > The Packaging Committee will meet Tuesday, 2009-04-14 at 17:00UTC in > the #fedora-meeting channel on chat.freenode.net. 17:00 UTC will likely not work for me. Therefore, votes and comments interspersed below > 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 - > https://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/GConf 0 ... this proposal needs further discussion. It's way too complex and way too intrusive to be able to comment on in a short emails. > Globus - > https://fedoraproject.org/wiki/PackagingDrafts/Globus In my understanding, the globus package set is an arbitrary set of packages like many 1000 others in Fedora and therefore doesn't need specialized rules in the FPG. => My vote: -1 > Compiler Flags - > https://fedoraproject.org/wiki/Compiler_Flags_(draft) I would presume this kind of "wisdom" to be "elementary and basic knowledge", people without should not package packages for Fedora. Apart of this, this proposal is misleading ("should honor", IMO "must honor"), partially wrong (make CFLAGS=... is wrong for modern autotools based packages), ... I don't find this proposal helpful. => My vote: -1 Ralf

3 3

about compiler flags
by Orcan Ogetbil 28 Apr '09

28 Apr '09

I have 2 questions. The first one is brought to my attention by a first time reviewer and he has got an interesting point. The guidelines at https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler_flags say: "Adding to and overriding or filtering parts of these flags is permitted if there's a good reason to do so; the rationale for doing so should be reviewed and documented in the specfile especially in the override and filter cases." As you probably know that some packages add their own compiler flags on top of what we specified as %optflags. Until now, I did not do anything about these flags unless they override our %optflags. Now, having a second thought, I realized that the above statement can be interpreted in two ways: 1- The extra flags are added by the packager: This is the way I used to interpret the guideline, and I always document if I add additional flags on top of %{optflags} 2- The extra flags are added by the build script of upstream: Here is the question: Do we need to document such cases in the specfile? I know that we have hundreds (maybe thousands) of packages which don't document this case in the specfile. Are such packages violating the above guideline? Second question: From the same link above: "Compilers used to build packages should honor the applicable compiler flags set in the system rpm configuration." Does this apply to the stage where the compiler is doing the linking, i.e: "gcc -shared -lthis -lthat..."? Do we need to honor %optflags in this stage too? Again, I know many packages that don't pass %optflags to the compiler during the linking. Do these pakcages violate the guideline? Orcan

5 8

New Draft Packaging Guideline - Fixing Gconf schema registration
by Shawn Starr 22 Apr '09

22 Apr '09

Hello everyone, I have created a draft guideline using OpenSuSE's existing macros.gconf2 script for Fedora. You can find this at: https://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/GConf I have done an initial test with the .spec file mentioned as an example in this draft. Seems to work fine. Since this the first iteration, I would like people to comment so we can get this finalized for Fedora 12 and rejoice in speedy installs and yum updates. Thanks! -- Shawn Starr Software Developer, Open Source Grid Development Center (OSGDC) Platform Computing 3760 14th Avenue Markham, ON L3R3T7 direct: 905.948.4229 http://www.platform.com

3 3

Packaging guideline draft for globus toolkit
by Toshio Kuratomi 22 Apr '09

22 Apr '09

Mattias Ellert has proposed guidelines for packaging things from the Globus toolkit. It's a long document so I figured I'd give people a heads up so you don't come to the Meeting expecting to read it all there ;-) I've added a few small comments to the talk page: https://fedoraproject.org/wiki/Talk:PackagingDrafts/Globus Since I'm writing this, I'll add them here as well: * Could ./globus-spec.pl be put into a package? * Obtaining sources should also include copying over the the license file Mattias, let me know if it's better for you to have discussion on fedora-packaging list or on the talk page. -Toshio

1 0

Sysreport is still in rawhide - why?
by Jussi Lehtola 21 Apr '09

21 Apr '09

Hi, why is sysreport still available in rawhide? # yum --enablerepo=rawhide list sysreport Loaded plugins: downloadonly, refresh-packagekit Available Packages sysreport.noarch 1.4.4-3 rawhide # yum install sysreport Loaded plugins: downloadonly, refresh-packagekit Setting up Install Process Parsing package install arguments Package sysreport is obsoleted by sos, trying to install sos-1.8-9.fc10.noarch instead Package sos-1.8-9.fc10.noarch already installed and latest version Nothing to do -- Jussi Lehtola Fedora Project Contributor jussilehtola(a)fedoraproject.org

2 1

Packaging of license file in case of extracted sources
by Mattias Ellert 21 Apr '09

21 Apr '09

Hi! I have several very similar packages being reviewed and two different reviewers reviewing different packages have reach contradicting conclusions about how the packaging guidelines should be interpreted. Since it doesn't make sense that the same issue is resolved differently depending on who happens to be the reviewer, and the reviewers have failed to reach a common viewpoint I send this mail to this list in the hope that there will be a way to resolve the issue consistently for all packages. Here is a description of the problem at hand: When upstream distributes sources in a gigantic installer containing the sources for 300+ packages it doesn't make sense to include this full tarfile for each SRPM, since less than 1% of it is used to compile each package. Instead the relevant subdirectory is extracted from this beast (properly documented in the specfile in accordance to the packaging guidelines). Then the question is how should the following guideline be interpreted: "If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc." Does this text refer to the big gigantic installer or the extracted source tarfile in this case. One reviewer strongly argues the first point and will only approve packages where the license file is included, the other strongly argues the second point and will only approve packages where the license file is not included. Both quote the above rule as the foundation for there standpoint. Since it doesn't make sense to do things differently depending on who happens to be the reviewer, I would like to have an official view of the packaging experts on this issue. Mattias

6 17

How to create a subdir in %{_docdir}/%{name}-%{version}
by Christoph Wickert 20 Apr '09

20 Apr '09

Hi, I want to create an "examples" folder inside %{_docdir}/%{name}-%{version}. Here is my test case: > %install > mkdir -p $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version}/examples/ > touch $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version}/examples/test > > %files -f %{name}.lang > %defattr(-,root,root,-) > %doc AUTHORS COPYING ChangeLog README > %doc %{_docdir}/%{name}-%{version}/examples/ This wont work as the first %doc line deletes and re-creates %{_docdir}/%{name}-%{version}, so rpmbuild will fail with: "... /usr/share/doc/foo/examples/test: cpio: Bad magic" Any idea how I can have a subdir then? Christoph

3 2

Re: Packaging of license file in case of extracted sources
by Orcan Ogetbil 20 Apr '09

20 Apr '09

On 04/20/2009 06:28 AM, Mattias Ellert wrote: > The question at hand is not whether the tarball contains inlined or > detached licenses. The question is which tarball the guideline refers > to. If it is the large upstream installer it does include a detached > license file. If it is the extracted tarball it does not. I want to make clear that the disagreement does not depend on whether we extract source tarballs from a larger tree or not. Let me talk over a toy example to demonstrate the situation: Suppose I am packaging MyApp. MyApp source tree has this layout: src/A/ src/B/ I am making MyApp-A and MyApp-B subpackages. Now there is a COPYING file under src/A/ Should I put that COPYING file into the %doc of the MyApp-B package, if - B requires A? - B doesn't require A? Let's make this clear, so that we can apply the general consensus on the new packages. Orcan

3 2

Mono's dll/exe and debugpackage
by Simon Wesp 14 Apr '09

14 Apr '09

Hey all, I have a problem with a mono package. It creates only an *.exe file and some *.dll files in libdir. i can't create a debug package with this. Is there a trick for this? -- Mit freundlichen Grüßen aus dem schönen Hainzell Simon Wesp The G in GNU stands for GNU http://fedoraproject.org/wiki/SimonWesp

2 1

FW: [Bug 495529] rpmlint incorrect warning for missing-lsb-keyword Default-Stop
by Matt Domsch 13 Apr '09

13 Apr '09

Packaging Committee: either rpmlint is correct, or the guidelines are correct; but at the moment they conflict. Please see this bugzilla and review. Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux -----Original Message----- From: bugzilla(a)redhat.com [mailto:bugzilla@redhat.com] Sent: Mon 4/13/2009 3:42 PM To: Domsch, Matt Subject: [Bug 495529] rpmlint incorrect warning for missing-lsb-keyword Default-Stop Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=495529 Ville Skyttä <ville.skytta(a)iki.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |NOTABUG --- Comment #1 from Ville Skyttä <ville.skytta(a)iki.fi> 2009-04-13 16:42:46 EDT --- I think the documentation cited draws wrong conclusions/interpretations from the LSB spec. One may very well want to have a service stopped by default in some runlevels even if it is not started in any by default. The LSB specs are quite vague too, which has resulted in rpmlint drawing its own conclusions, the one of which in effect here is that there should be no need not to have a Default-Stop in all init scripts, thus it always recommends adding one in all init scripts, even if empty. $ rpmlint -I missing-lsb-keyword missing-lsb-keyword: The package contains an init script that does not contain one of the LSB init script comment block convention keywords that are recommendable for all init scripts. If there is nothing to add to a keyword's value, include the keyword in the script with an empty value. Note that as of version 3.2, the LSB specification does not mandate presence of any keywords. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You reported the bug.

1 0

[Fedora-Packagers] SciLab
by Ankur Sinha 12 Apr '09

12 Apr '09

hi, Is scilab in the repos? I haven't been able to find the latest release.. It's an open source alternative to Matlab.. http://www.scilab.org/download/index_download.php?page=release#linux The license looks open source.. :) http://www.scilab.org/legal/ Can someone please package it ? The older version is present in the Dries repos though.. http://dries.ulyssis.org/rpm/packages/scilab/info.html regards, Ankur

2 1

wordpress guidelines -- ping?
by Ian Weller 08 Apr '09

08 Apr '09

During the most recent meeting it was decided that I would be contacted about a few issues with the WordPress plugin packaging guidelines; https://fedoraproject.org/wiki/User:Ianweller/WordPress_plugin_packaging_gu… I wasn't contacted, but I did ask spot what the issue was, and he reported that we needed to know if there would be a case where the plugin may not function on either platform (mu or lack thereof). The answer is a strong "yes" from upstream. What are we waiting on? Is a list vote possible to get this moving along? -- Ian Weller <ianweller(a)gmail.com> GnuPG fingerprint: E51E 0517 7A92 70A2 4226 B050 87ED 7C97 EFA8 4A36

5 8

Use of %{_libdir}/gfortran
by Jussi Lehtola 08 Apr '09

08 Apr '09

Hi, the Fortran flags in Fedora 10 read FFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -I/usr/lib64/gfortran/modules' However, # yum provides /usr/lib64/gfortran finds no match. What package is supposed to provide the aforementioned directory, and what is it supposed to be used for? Should all Fortran module files be installed in that directory? -- Jussi Lehtola Fedora Project Contributor jussilehtola(a)fedoraproject.org

1 0

gnome-do 0.8.0
by Luca Foppiano 04 Apr '09

04 Apr '09

Hi, here the updated gnome-do 0.8.0. SPEC: http://lfoppiano.fedorapeople.org/gnome-do.spec RPM (x86_64): http://lfoppiano.fedorapeople.org/gnome-do-0.8.0-1.fc10.x86_64.rpm http://lfoppiano.fedorapeople.org/gnome-do-devel-0.8.0-1.fc10.x86_64.rpm SRPM: http://lfoppiano.fedorapeople.org/gnome-do-0.8.0-1.fc10.src.rpm I just updated the package version and check it with mock and rpmlint (both finished without errors). Thanks in advance :) Luca -- Today is Prickle-Prickle, the 69th day of Chaos in the YOLD 3175 AIX - the Unix from the universe where Spock has a beard.

3 4

How to package a patched older version of libvmime in Fedora best?
by Robert Scheck 04 Apr '09

04 Apr '09

Good evening, I've the situation, that a package unluckily requires an older version of libvmime and some specific/individual patches as well. The question is now, how to package that best for Fedora and EPEL? What I'm requiring is libvmime 0.7.1 + patches, while upstream is at 0.9.1 which is unluckily ABI and API incompatible. There are now multiple solutions how to deal with this as I can't use 0.9.1 now and in foreseeable future: a) Build libvmime 0.7.1 + patches in before of the software requiring it and link statically against it. This would make sense in this case, even if static linking is discouraged in Fedora, but nothing except that piece of software requires actually libvmime 0.7.1 + individual patches. b) Build libvmime 0.7.1 + patches as own package and call it e.g. something like foobar-libvmime and rename libvmime.so.* to foobar-libvmime.so.* or similar. That would bring me to -lfoobar-libvmime linking or something similar, right? Just providing a compat-libvmime seems not suitable, as compat-* in Fedora is only providing the library, not -devel stuff which is actually needed to build the other software requiring the old libvmime 0.7.1 + patches. As of overlapping *.so filenames, it is not possible to avoid renaming the patched version. Question is, which is better and which one will go through the package review or are there better ideas how to solve this? Yes, some far day, upstream will accept all of the individual patches and the other software will support latest libvmime version, but this won't be in the next time as libvmime support is somehow seemingly less interested in being backward compatible. Greetings, Robert

5 8

Need advice pertaining to GSoC proposal
by Debayan Banerjee 03 Apr '09

03 Apr '09

Dear List, I need some feedback on the feasibility of the proposal below from this list. ADDING ONE CLICK INSTALL SUPPORT TO FEDORA (Package-Kit in effect) To install a package x in Fedora one has to add the repository via the command line (or gui) and then type "yum install x" to get the package installed. In the one-click-install feature we have an xml file per-package which contains information in it such as package name,version,repository links (for installing further dependencies), GPG key etc. One may upload these xml files on the web and an user may click on these xml files in a browser. Once downloaded the a parser parses the contents of the file and automatically adds the requisite repositories and downloads requisite packages for dependency preservation. I have been discussing this topic simultaneously on 2 lists because of the nature of the problem. Here are the 2 threads: [1] http://lists.freedesktop.org/archives/packagekit/2009-March/004569.html [2] http://groups.google.com/group/redhat-summer/browse_thread/thread/50de9e16d… I think its time to summarise my proposal. The way I see it, there are 4 things to do: 1) Add .oci support to package-kit. 2) Add pluggable policies 3) Add voting system to package manager 4) A server that receives these votes and maintains a list of repos in sorted order. The distro maintains this. Leave it to the user which repo he wants to add now. Explanation: 1)Add .oci support to package-kit: This involves adding C code to Package-Kit. Much of the work has been done by Dorian Perkins and is available at http://www.cs.ucr.edu/~dperkins/projects/pk-oci/. 2)Pluggable Policies: The policy of what to allow to install will not be agreed across all distributions. So instead of discussing a policy that will never get unanimous approval the install policy pluggable, and allowing the distribution to choose the policy may be better. Some example policies would be * Only allow packages in the distribution itself * Only allow packages that are whitelisted or in whitelisted repository * Allow installation of anything that is not on a blacklist * Allow installation of anything" (In words of Benji Webber) 3) Add voting system to Package Manager: The word trust has to mean something that the end user understands, as opposed to GPG keys. One way of defining trust is by votes. It is my proposal that we enable a voting system at the package manager end so that every time a repository is added and a package installed for the first time users are asked for a "Recommend" vs "Do not recommend" vote. Conversely, every time a user disables/removes a repository he is asked whether he votes "Do not recommend". These votes go to a centrallised server I was advised on the Fedora list by Patrick Barnes to use the voting approach. I thought it made sense since it will keep evil people (repositories) away the same way wikipedia protects itself from evil people. Also there may be admins, like me, who shall ban a particular repository from the listings if it is found to be a malicious repository. If a repo is evil, there *will* be several "do not recommend" votes to it too which will attract attention. 4) A server that receives votes and maintains a listing of repositories in sorted order: We could make modifications to <https://admin.fedoraproject.org/pkgdb> so that it provides one-click-install links to all packages thus. Similar efforts are at: [1] http://www.apturl.net/ [2] http://packages.opensuse-community.org/ [3] http://www.allmyapps.com/ I can set up a prototype server which accepts these votes and displays reposiories/packages accordingly. Once I have successfully built all the things I have mentioned, I dont mind buying hosting space to host it as a proof of concept. -- Be Intelligent, Use GNU/Linux http://debayanin.googlepages.com/ http://debayan.wordpress.com http://lug.nitdgp.ac.in

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging April 2009