rpmlint file-size-mismatch and github source URLs
by James Laska
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-plugin... = 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-plugin...
> < 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-plugin... > /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-plugin... = 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-plugin...').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
12 years, 1 month
Re: [Fedora-packaging] How to ignore LD_LIBRARY_PATH
by Orion Poplawski
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
12 years, 1 month
Are brackets around macros required?
by Göran Uddeborg
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?
12 years, 1 month
define versus global !?
by Farkas Levente
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!"
12 years, 1 month
ensuring a specific version of python
by Martin Krizek
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
12 years, 1 month
Systemd scriptlet comments
by Ville Skyttä
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.
12 years, 1 month
Mozilla Extension Guidelines
by David Michael
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
12 years, 2 months
Changelog guideline
by Susi Lehtola
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
12 years, 2 months
