packaging August 2011

packaging@lists.fedoraproject.org

24 participants
9 discussions

rpmlint file-size-mismatch and github source URLs
by James Laska 25 Aug '11

25 Aug '11

Greetings, While performing a package review, I noticed that rpmlint doesn't like Source URL's that point to github. Rpmlint emits a 'file-size-mismatch' warning for the package I am reviewing, and a quick google search highlights additional package reviews with github source URL's having the same issue. I've not yet seen a recommended resolution in the other package reviews, so I thought this might be appropriate for the list. I see the following warning ... > $ rpmlint -i nagios-plugins-rhev-1.0.0-2.fc16.src.rpm > nagios-plugins-rhev.src: W: file-size-mismatch nagios-plugins-rhev-1.0.0.tar.gz = 9941, https://github.com/dougsland/nagios-plugins-rhev/raw/master/nagios-plugins-… = 1 > The size of the file in the package does not match the size indicated by > peeking at its URL. Verify that the file in the package has the intended > contents. A quick inspection of --verbose output from curl made me believe that a redirect might be confusing rpmlint ... > < HTTP/1.1 302 Found > < Server: nginx/1.0.4 > < Date: Wed, 24 Aug 2011 12:10:07 GMT > < Content-Type: text/html; charset=utf-8 > < Connection: keep-alive > < Status: 302 Found > < X-RateLimit-Limit: 100 > < Location: > https://raw.github.com/dougsland/nagios-plugins-rhev/master/nagios-plugins-… > < X-RateLimit-Remaining: 100 > < X-Runtime: 108ms > < Content-Length: 158 I adjusted the SourceURL in the spec file to the redirected URL, but the original problem remains. I'm confused, curl seems to think everything matches (size=9941)... > $ curl -v > https://raw.github.com/dougsland/nagios-plugins-rhev/master/nagios-plugins-… > /dev/null > <snip> > < HTTP/1.1 200 OK > <snip> > < Content-Length: 9941 But rpmlint is still upset ... > nagios-plugins-rhev.src: W: file-size-mismatch > nagios-plugins-rhev-1.0.0.tar.gz = 9941, > https://raw.github.com/dougsland/nagios-plugins-rhev/master/nagios-plugins-… = 1 Looking into rpmlint a bit further, abstractCheck::check_url() is discovering a content-length of 1. When I check the value of 'Content-Length' using urllib2.urlopen ... I get the expected value. > >>> urllib2.urlopen('https://raw.github.com/dougsland/nagios-plugins-rhev/master/nagios-plugins-…').info().get('Content-Length') > '9941' I suspect something is amiss with rpmlint abstractCheck and the custom _HeadRequest.get_method(). Removing it, resolves the problem. Perhaps I should take this to the rpmlint development list as it seems related to an intentional upstream fix (http://rpmlint.zarb.org/cgi-bin/trac.cgi/ticket/165). Any thoughts/suggestions? Thanks, James

6 7

Re: [Fedora-packaging] How to ignore LD_LIBRARY_PATH
by Orion Poplawski 24 Aug '11

24 Aug '11

On 08/23/2011 12:47 PM, Thomas Moschny wrote: > 2011/8/23 Orion Poplawski<orion(a)cora.nwra.com>: >> See https://bugzilla.redhat.com/show_bug.cgi?id=719785 for the motivation >> >> The environment module system allows users to modify their environment in a >> predictable way, including setting LD_LIBRARY_PATH. However, this makes it >> possible to break the modulecmd binary by putting an incompatible TCL (or >> other) library earlier in the path. It would be great if modulecmd were made >> impervious to such things, but I don't know the best or acceptable method to >> do this. I'm guessing using rpaths would be the easiest. >> >> Thoughts/suggestions? > > Would something like this work? > > module () > { > eval `/lib64/ld-linux-x86-64.so.2 --library-path '' > /usr/bin/modulecmd bash $*` > } > > (on a 64bit system; on a 32bit system it would need to use /lib/ld-linux.so.2). > > - Thomas Hmm, I like this idea. I think it would protect the default system, but still allow for end users to override it for some reason. It might even be acceptable upstream. I'm CC'ing the packaging list to get their thoughts. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion(a)cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com

1 0

Are brackets around macros required?
by Göran Uddeborg 20 Aug '11

20 Aug '11

In a package review recently I was asked to put brackets around all macro usages. That is, writing %{name}.desktop rather than %name.desktop I personally think these superfluous brackets clutter the spec file and reduce the readability. So when they are not necessary I always omit them. To me it somewhat strange that using brackets is more common than not doing so. The situation is quite analogous to shell scripts. In (ba)sh it is always ALLOWED to have brackets around variables, but only rarely REQUIRED. Exactly as it is for macros in spec files. But while you almost never see a shell script with brackets where they are not needed, it is quite common in spec files. Should the packaging guidelines have a ruling on this? There isn't any as far as I can find. The closest I found was the choice between %{buildroot} and ${RPM_BUILD_ROOT}, and in that case the only requirement was consistency. Is consistency the only requirement in the choice between %{name} and %name too? Or is the use of %{name} with brackets actually required?

10 15

define versus global !?
by Farkas Levente 19 Aug '11

19 Aug '11

hi, sorry for cross posting but may be someone on the packaging/rpm side can help me. i'm getting really angry about the debug packages:-) does anybody who can tell me the real reason of why: ------------------------------------ %define __debug_install_post %{mingw_debug_install_post} ------------------------------------ works why ------------------------------------ %global __debug_install_post %{mingw_debug_install_post} ------------------------------------ not? imho if i can know the answer to this question i can solve my only remaining issue with generated spec file for mingw. if why this in the spec file working: ------------------------------------ %define __debug_install_post %{mingw_debug_install_post} ------------------------------------ while this not: test: ------------------------------------ echo "%define __debug_install_post %{mingw_debug_install_post}" ------------------------------------ and in the spec file: ------------------------------------ %global test sh /tmp/test %{expand:%(%{test})} ------------------------------------ ??? the same thing is working for all other macro except for __debug_install_post. thanks in advance. regards. -- Levente "Si vis pacem para bellum!"

5 7

rpmlint error: htaccessfile
by Ankur Sinha 16 Aug '11

16 Aug '11

Hello, rpmlint spews out "htaccess-file" while reviewing one of my srpms, openemr[1] . I'm not much of a web dev, could someone tell me how I should go about correcting this error please? -- Thanks, Regards, Ankur: "FranciscoD" http://fedoraproject.org/wiki/User:Ankursinha http://dodoincfedora.wordpress.com/

5 7

ensuring a specific version of python
by Martin Krizek 10 Aug '11

10 Aug '11

Is there a proper, 'Packaging Guidelines friendly' way to ensure a specific version of python? Is following fine? Requires: python >= 2.6 BuildRequires: python2-devel >= 2.6 Thanks, Martin

5 7

Systemd scriptlet comments
by Ville Skyttä 09 Aug '11

09 Aug '11

Some comments on systemd scriptlets at http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd 1) I don't think the versioned trigger logic will work too well at all in the (not that rare) cases where the previous distro had sysv scripts and one does a version bump in the previous distro - the trigger in the next one will no longer run on distro upgrades because of the versioning. Wouldn't it work better to just drop the version from the trigger altogether, and instead check if the old init script exists? For example: %triggerun -- httpd [ -e %{_initddir}/httpd ] || exit 0 # rest of the migration stuff goes here 2) Cosmetic: there are unnecessary '|| :'s sprinkled in the scriptlets, only the final exit status of a script has any effect. 3) More or less cosmetic: why hardwire absolute paths everywhere? The vast majority of other scriptlet snippets don't do that.

6 22

Mozilla Extension Guidelines
by David Michael 05 Aug '11

05 Aug '11

Hi, I am considering packaging a Mozilla extension, but I thought it best to try to clarify some things beforehand. The only guidance (draft) I found[1] doesn't seem to be followed by existing packages, but I agree with it in principle. Until there are official guidelines, I have two questions: Is it acceptable to follow the draft guidelines, or should new packages attempt to conform to the existing packages' (not quite consistent) structure? Is it appropriate to support any/all applications listed in the install.rdf, even if they are not available in Fedora? (I don't see a downside to this if the draft guidelines are followed, and it would allow locally managed applications to take advantage of extensions installed from RPMs.) Thanks for any suggestions. David 1. https://fedoraproject.org/wiki/User:Kalev/MozillaExtensionsDraft

3 5

Changelog guideline
by Susi Lehtola 03 Aug '11

03 Aug '11

Hi, I was wondering about the use of cluttered email addresses in changelogs. The first example of the guideline at http://fedoraproject.org/wiki/Packaging/Guidelines#Changelogs uses an address of the type <joe at gmail.com>. However, right after that it is said that one of the ensuing formats must be used, and they all contain the explicit email address. How should this guideline be interpreted? -- Jussi Lehtola Fedora Project Contributor jussilehtola(a)fedoraproject.org

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging August 2011