Re: Python dependency missing during RPM build
by Miro Hrončok
On 11/19/20 6:02 PM, Richard W.M. Jones wrote:
> It's not a big deal because I added the Python Requires: line by hand,
> but I want to make sure I understand why it happens and whether
> there's an easy fix.
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=55889416
> https://src.fedoraproject.org/rpms/nbdkit/blob/master/f/nbdkit.spec#_475
>
> This subpackage contains a Python file:
>
> $ rpm -qlp ./nbdkit-S3-plugin-1.23.9-1.fc34.x86_64.rpm
> /usr/lib64/nbdkit/plugins/nbdkit-S3-plugin <--- this one
> /usr/share/doc/nbdkit-S3-plugin
> /usr/share/doc/nbdkit-S3-plugin/README
> /usr/share/licenses/nbdkit-S3-plugin
> /usr/share/licenses/nbdkit-S3-plugin/LICENSE
> /usr/share/man/man1/nbdkit-S3-plugin.1.gz
>
> The automatically generated dependencies don't pick up the need for
> python3-boto3.
>
> $ grep ^import nbdkit-S3-plugin
> import nbdkit
> import boto3
>
> $ rpm -qRp ./nbdkit-S3-plugin-1.23.9-1.fc34.x86_64.rpm
> /usr/sbin/nbdkit
> nbdkit-python-plugin >= 1.22
> rpmlib(CompressedFileNames) <= 3.0.4-1
> rpmlib(FileDigests) <= 4.6.0-1
> rpmlib(PayloadFilesHavePrefix) <= 4.0-1
> rpmlib(PayloadIsZstd) <= 5.4.18-1
>
> (As I said above, I added it explicitly, which is why the RPM built in
> Koji above _does_ contain the boto3 dependency).
>
> Now admittedly the Python file doesn't end in .py and doesn't have a
> python shebang at the top. But:
>
> $ file nbdkit-S3-plugin
> nbdkit-S3-plugin: Python script, ASCII text executable
>
> which seems as if it matches the %__python_magic regexp in
> /usr/lib/rpm/fileattrs/python.attr. So perhaps it _ought_ to work and
> something is wrong on the machine I'm using to reproduce this?
>
> Alternatively is there another way to tell the dependency generator to
> take a special look at this file?
There are three dependency generators for Python and neither of them does what
you ask here.
/usr/lib/rpm/fileattrs/python.attr
This file makes sure that files installed into /usr/lib(64)/pythonX.Y require
python(abi) = X.Y.
/usr/lib/rpm/fileattrs/pythondist.attr
This file makes sure that Python packages (upstream term) require other Python
packages. E.g. that requests requires idna, chardet and urllib3. This is read
from upstream meatadata (.dist-info or egg-info directories/files). It has
nothing to do with imports. See for example data in
/usr/lib/python3.9/site-packages/requests-2.24.0-py3.9.egg-info/requires.txt.
/usr/lib/rpm/fileattrs/pythonname.attr
This file makes sure that packages called python3-requests provide
python-requests and python3.9-requests.
There is no generator that parses Python imports (and never has been), sorry.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
5 days, 21 hours
help wanted with modern Python packaging macros
(%generate_buildrequires, %tox)
by Felix Schwarz
Hi,
I wanted to update python-dns-lexicon. Version 3.4 uses poetry and tox so I
thought it would be a good idea to get a grip on %generate_buildrequires, %tox
etc.
Unfortunately I'm a bit stuck at the moment. Maybe this is just because I'm
starring for too long on some spec file (and probably my knowledge of
tox+macros is lacking).
I pushed the current state to:
https://src.fedoraproject.org/fork/fschwarz/rpms/python-dns-lexicon/commi...
My main problem is shown at the end of this mail: Somehow the Python extras
subpackage name is bad but I don't know how to debug this (without spending a
lot of time).
Additionally (but lower priority) just using %tox in %check fails (I think it
tries to download dependencies?).
Any help/pointers appreciated.
Felix
$ fedpkg --release=f33 mockbuild
…
Obsoletes: python-dns-lexicon < 3.4.0-1.fc33
Processing files: python3-dns-lexicon+easyname-3.4.0-1.fc33.noarch
Error: The package name contains an extras name `easyname` that was not found
in the metadata.
Check if the extras were removed from the project. If so, consider removing
the subpackage and obsoleting it from another.
error: Dependency tokens must begin with alpha-numeric, '_' or '/': ***
PYTHON_EXTRAS_NOT_FOUND_ERROR___SEE_STDERR ***
Error: The package name contains an extras name `easyname` that was not found
in the metadata.
Check if the extras were removed from the project. If so, consider removing
the subpackage and obsoleting it from another.
error: Dependency tokens must begin with alpha-numeric, '_' or '/': ***
PYTHON_EXTRAS_NOT_FOUND_ERROR___SEE_STDERR ***
Provides: python-dns-lexicon+easyname = 3.4.0-1.fc33
python3-dns-lexicon+easyname = 3.4.0-1.fc33 python3.9-dns-lexicon+easyname =
3.4.0-1.fc33
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests)
<= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Obsoletes: python-dns-lexicon+easyname < 3.4.0-1.fc33
RPM build errors:
absolute symlink: /usr/bin/lexicon-3 -> /usr/bin/lexicon-3.9
Dependency tokens must begin with alpha-numeric, '_' or '/': ***
PYTHON_EXTRAS_NOT_FOUND_ERROR___SEE_STDERR ***
Dependency tokens must begin with alpha-numeric, '_' or '/': ***
PYTHON_EXTRAS_NOT_FOUND_ERROR___SEE_STDERR ***
Finish: rpmbuild python-dns-lexicon-3.4.0-1.fc33.src.rpm
Finish: build phase for python-dns-lexicon-3.4.0-1.fc33.src.rpm
1 week, 1 day
Automated Python packaging?
by Peter Oliver
Thereʼs a Python module Iʼd like to package for Fedora. I made a start on Copr, but I rapidly got lost in a maze of missing dependencies and broken builds.
OTOH, running `pip install` takes seconds and everything just works.
I feel like someone must have come up with an easy way of building a chain of PyPI dependencies into a collection of RPMs. Am I missing a trick?
--
Peter Oliver
1 week, 2 days
RFC: Mangle Python shebangs to fully qualified interpreter (/usr/bin/pythonX.Y)
by Neal Gompa
Hey all,
An "interesting" Linux support issue at work with another Linux
distribution opened my eyes to the possibility of how badly things
would break if /usr/bin/python3 was swapped or otherwise altered by an
external force. In such a scenario where it was overridden to point to
another Python 3 interpreter that wasn't the system one, things would
break pretty badly.
Now that we've been moving toward a model where it becomes possible
for first-party or third-party multi-Python RPMs, I'm wondering if it
would make sense to evolve the shebang mangling for Python to resolve
to the fully qualified Python interpreter path (that is,
/usr/bin/pythonX.Y instead of /usr/bin/pythonX) for packaged Python
code. Presumably this may make things easier for switching Python
versions without everything breaking, too.
In practice, I don't think this is a *huge* issue Fedora-side, since
we don't manage /usr/bin/python3 via alternatives. But I can easily
see people wanting /usr/bin/python3 to be swappable in Red Hat
Enterprise Linux, while everything is still parallel installable and
fully functional. The Python interpreter packaging even mostly
supports this now.
What do y'all think? Is this doable? Is this desirable?
--
真実はいつも一つ！/ Always, there's only one truth!
3 weeks
