From setuptools's documentation:
These files are not eggs, strictly speaking. They simply provide a way
to reference an egg that is not physically installed in the desired
location. They exist primarily as a cross-platform alternative to
symbolic links, to support "installing" code that is being developed in
a different location than the desired installation location.
If we read .egg-link using pkg_resources.Distribution it will
never have version as it is just list of directories which should be
taken into account.
We could change into that directories and add eggs from those locations
for parsing, but RPM's dependency generator already passing all files
from built RPM so it just does not make any sense to traverse those
directories.
After all written above, let's just ignore .egg-link files.
Signed-off-by: Igor Gnatenko <ignatenko@redhat.com>
In 49197c930b we introduced skipping
metadata which has no version, but it's better to show some warning.
Signed-off-by: Igor Gnatenko <ignatenko@redhat.com>
For example, reading .egg-link using pkg_resources.Distribution returns
actual metadata, but it does not contain version. It returns traceback like:
File "/usr/lib/rpm/pythondistdeps.py", line 113, in <module>
pyver_major = dist.py_version.split('.')[0]
AttributeError: 'NoneType' object has no attribute 'split'
Traceback (most recent call last):
File "/usr/lib/rpm/pythondistdeps.py", line 113, in <module>
pyver_major = dist.py_version.split('.')[0]
AttributeError: 'NoneType' object has no attribute 'split'
Let's just skip such errors as we can't do much about that.
Reference: https://bugzilla.redhat.com/show_bug.cgi?id=1368673
Reported-and-tested-by: Igor Gnatenko <ignatenko@redhat.com>
This patch lets debuginfo packages provide build-id like follows:
debuginfo(build-id) = c63cb23876c5fa85f36beaff58f8557e1bf22517
Originally this patch was written by Jan Blunck <jblunck@suse.de>.
Signed-off-by: Igor Gnatenko <ignatenko@redhat.com>
Introduce a new macro _unique_debug_names that when set will pass
--unique-debug-arch "%{_arch}" to find-debuginfo.sh to create debuginfo
files which end in "-<ver>-<rel>.<arch>.debug" instead of simply ".debug".
Adds testcases for dwz and buildid with and without unique debug file names.
Signed-off-by: Mark Wielaard <mjw@redhat.com>
Introduces _include_gdb_index macro and -i flag to find-debuginfo.sh to
enable or disable adding a .gdb_index section to debug files. Adds tests
to make sure the .gdb_index is really added (or not) when requested.
Checks that gdb-add-index is actually installed instead of silently
failing if not. Similar for dwz.
Signed-off-by: Mark Wielaard <mjw@redhat.com>
Introduce a new macro _unique_build_ids that when set will pass the
version and release to find-debuginfo.sh and debugedit to recalculate
the build-id of ELF files.
Includes two new testcases to make sure the new setting works as expected
both when set and unset.
Signed-off-by: Mark Wielaard <mjw@redhat.com>
This patch moves the main ELF file build-id symlinks from the
debuginfo package into the main package. And uses different
base directories for the main ELF file build-id symlink.
For the main build-id use /usr/lib/.build-id and for the debug
build-id use /usr/lib/debug/.build-id.
There are two reasons for doing this. The main package and the
debuginfo package might get out of sync, or the debuginfo package
might not be installed at all. In which case finding the main ELF
file through the build-id symlink becomes impossible. Secondly by
moving the main ELF build-id symlink in its own directory the
/usr/lib/debug directory gets populated with only debuginfo files
which is convenient if the user might want to have that directory
populated through a network mountpoint.
To support the new logic the symlink code has been moved from
find-debuginfo.sh to build/files.c.
This also includes support for a new config %_build_id_links that
defaults to compat. The other settings are none, alldebug (the old
style) and separate. compat is like separate, but adds a compatibility
link under /usr/lib/debug/.build-id for the main build-id symlink.
There are several new testcases added to test the various settings
using the new keyword "buildid".
Signed-off-by: Mark Wielaard <mjw@redhat.com>
Some old tools might still use the .gnu_debuglink section to find
separate debuginfo files instead of build-id style lookups. When
dwz has compresses the .debug files the original CRC in the main
ELF file will no longer match. Make sure to run sepdebugcrcfix
after dwz to recalculate the CRC.
The original fix was created by Jan Kratochvil based on code
from GNU binutils BFD. https://bugzilla.redhat.com/show_bug.cgi?id=971119
I added a testcase to make sure the CRCs were all correctly
updated after dwz has run to compress a debuginfo package.
And a change (plus testcase) to make sure implicit suid binaries
didn't accidentially got their suid flag bit.
Signed-off-by: Mark Wielaard <mjw@redhat.com>
Support for minisymtab (a minimal function symbol table in a compressed
section in the main binary) has been in gdb and elfutils based tools
since some years. Fedora has had this as rpm-4.10.0-minidebuginfo.patch
since 2012.
The patch adjusts macros to pass -m to find-debuginfo.sh when
_include_minidebuginfo has been set. find-debuginfo.sh now takes -m
as argument to generate the .gnu_debugdata ELF section to be added
to the main executable.
To support the testcases a new macros.debug is added that is used to
generate debuginfo packages in the rpmbuild.at testsuite.
The original support was added to Fedora rpm by Alexander Larsson.
Lubos Kardos fixed a bug in it when strip -g was used. I added some
configuration macros and two testcases to check the basic support works
and for the strip -g bug.
Signed-off-by: Mark Wielaard <mjw@redhat.com>
The fact that pyc and pyo doesn't have same the content doens't mean
an error. It just means they can't be hard linked but that is not
an error. In normal circumstances the file brp-python-hardlink from
the rpm packages is often overrided by the file from redhat-rpm-config
that is why this problem wasn't revealed earlier.
Per the recommendation of Nick Coghlan and Toshio Kuratomi,
pythonXegg(M) is being renamed to pythonX.Ydist(M).
An option has also been added to add a pythonXdist(M)
Provides for distributions that may prefer to have it.
The option '--majorver-provides' is intended for use
if only one Python stack per major version will be
available at a given time, as unexpected results may
occur if there are multiple independent Python stacks
per major version available.
Consequently, it will not be on by default when using
the generator for generating Provides.
Additionally, .egg-info data is being replaced with
.dist-info data, so we need to handle that case, too.
See for more details:
https://lists.fedoraproject.org/archives/list/python-devel%40lists.fedoraproject.org/thread/SQBSAS4T25HK5YJBNBSFDD7KDQWDELL6/
Also, Thierry Vignaud brought up on rpm-maint that Mageia
currently uses "pythonegg(X)(M)" (e.g. "pythonegg(3)(rpm)"
for python3 rpm bindings package) in their Python packages
to pull in Python dependencies and requested a way to
not break Mageia.
After discussing with Florian Festi about it, Mageia's
pythonegg(X)(M) will be supported by adding '--legacy'
as a switch to generate legacy Provides/Requires to maintain
compatibility with Mageia's existing usage.
The '--legacy-provides' switch will enable pythonegg(X)(M)
Provides in addition to the new pythonX.Ydist(M) format to
allow for a easier transition.
rationale:
1) typelib deps are unrelated to python
2) typelib deps are computed by suse generator
3) suse generator is not present upstream
4) let's not reinvent internal deps generator here...
This commit 0d5929ba5e tries to ignore
"use" and "require" within multi-line print statements that start with
line like this "print <<EOF" but it incorrectly parses lines in
following format "print <<EOF unless $o" and every "use" or "require"
below this line to the end of file is ignored. That causes that some
requires which was previously found are not found now. This commit
fixes this problem (#1268021).
Using '/usr/bin/env python' could lead to unexpected results,
so switching to this guarantees that it will use the system-wide
Python environment, instead of any virtual environments or whatnot.
This change was brought over from the fix used by Mageia to speed
up the extraction of Python dependencies. As Mageia found out
(and verified to be true with this generator too), the generator
is now called on every file in the package. This means that the
pkg_resources import time is now a drag on the performance of
generating dependencies.
For more details, see the following link:
http://gitweb.mageia.org/software/rpm/rpm-setup/commit/pythoneggs.py?id=b77d47f90289413e20f295b93ae8c51012f53e3d
The egg dependency generator was slightly inconsistent here.
While it would generate python2egg() for Py2 Requires/Recommends and
pythonegg() for Py3 Requires/Recommends, it would generate python3egg()
for Py3 Provides and pythonegg() for Py2 Provides. Rather than make a
decision on which is the "proper" Python here, let's just handle them
the same way: pythonXegg(), with "X" being the Python major version.
This way, it's absolutely clear which Python it is for, and as
new major versions of Python become a reality, we should be able to
handle that quite easily and (of course) sanely. The approach is
inspired by the method used in Mageia's python dependency generator.
In case the generator is being used in an environment where
Python 2 is the default still, the appropriate import to ensure
that print() works has been added.
Additionally, the string formatting calls have been refactored
to use string.format() instead of old-style printf-esque calls.
This enhances the readability slightly by making it so that '%'
isn't being used for anything but RPM stuff in strings.
- Now script perl.req ignores "use" and "requires" on lines that are
part of printing or assigning multi-line string i. e. string that
hasn't starting and ending quote on the same line.
(RhBug:1024517)
- script perl.req was able to parse only multi-line print statements
with quoted tag e.g. 'print <<"tag"' or "print <<'tag'". Now it can
also parse "print <<tag".
Igor Gnatenko