packaging April 2009

packaging@lists.fedoraproject.org

32 participants
21 discussions

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging April 2009