Re: Macro to smoke-test-import a Python module in %check
by Miro Hrončok
On 11. 07. 21 21:05, Richard Shaw wrote:
> Trying this with python-pyside2...
>
> + /usr/bin/python3 -c 'import PySide2'
> PySide2/__init__.py: Unable to import shiboken2 from ,
> /builddir/build/BUILDROOT/python-pyside2-5.15.2-4.fc35.x86_64/usr/lib64/python3.10/site-packages,
> /builddir/build/BUILDROOT/python-pyside2-5.15.2-4.fc35.x86_64/usr/lib/python3.10/site-packages,
> /usr/lib64/python310.zip, /usr/lib64/python3.10,
> /usr/lib64/python3.10/lib-dynload, /usr/lib64/python3.10/site-packages,
> /usr/lib/python3.10/site-packages
> Traceback (most recent call last):
> File "<string>", line 1, in <module>
> File
> "/builddir/build/BUILDROOT/python-pyside2-5.15.2-4.fc35.x86_64/usr/lib64/python3.10/site-packages/PySide2/__init__.py",
> line 107, in <module>
> _setupQtDirectories()
> File
> "/builddir/build/BUILDROOT/python-pyside2-5.15.2-4.fc35.x86_64/usr/lib64/python3.10/site-packages/PySide2/__init__.py",
> line 58, in _setupQtDirectories
> import shiboken2
> File
> "/builddir/build/BUILDROOT/python-pyside2-5.15.2-4.fc35.x86_64/usr/lib64/python3.10/site-packages/shiboken2/__init__.py",
> line 27, in <module>
> from .shiboken2 import *
> ImportError: libshiboken2.cpython-310-x86_64-linux-gnu.so.5.15: cannot open
> shared object file: No such file or directory
>
> Worked fine once installed. The 5.15 file is a symlink to 5.15.2 which is the
> actual library file name, but I don't see why it would follow symlinks once
> installed but not here?
Is it possible that the symbolic link is absolute and hence not resolvable
during the build (because it does not lead to the buildroot)?
Not sure how the macro could compensate for that.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
2 years, 9 months
Directory ownership of %{_datadir}/icons/hicolor
by Otto Urpelainen
Hello packagers,
I have problems interpreting Packaging Guidelines section File and
Directory Ownership [1] for icons application place in
%{_datadir}/icons/hicolor. I ran into this during package review for
dosbox-x [2], but I think the issue is more general than that, because
many applications add their icons to the (default, fallback) hicolor theme.
So the package places application's icon to
%{_datadir}/icons/hicolor/scalable/apps/dosbox-x.svg. From the
guidelines, it is clear that for all directories in the chain, one of
the following has to be true:
1. Package owns the directory
2. A dependency package owns the directory
3. _filesystem_, _man_ or "other explicitly created -filesystem
package" own the directory
Item 3 takes care of %{_datadir}/icons part, because that is included in
_filesystem_. The remainder hicolor/scalable/apps is unclear for me.
Method 1 could be used. But there is also package _hicolor-icon-theme_.
Is that package an "explicitly created -filesystem package", so method 3
could be used? That would feel natural, because hicolor is the fallback
theme that must exist according to freedesktop.org specification.
Related but separate question about the guidelines: Section Unowned
Directories:Inaccessible Directories [3] discusses a problem that is
only relevant to Fedora < 9 and RHEL < 5.3. It does not really contain
any information that is relevant today. Should that section simply be
removed?
Otto
[1]:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_dire...
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=1919639
[3]:
https://docs.fedoraproject.org/en-US/packaging-guidelines/UnownedDirector...
2 years, 9 months
Macro to smoke-test-import a Python module in %check
by Miro Hrončok
Hello Python RPM packagers,
based on some discussion in the "F35 Change: Python Packaging Guidelines
overhaul (System-Wide Change proposal)" thread [0], I've drafted a macro that
can help to test-import a Python module in %check when no other tests exist or
are when they cannot be executed during build [1].
The semantics is quite simple:
%check
%py3_check_import mymodule mymodule.submodule
When all listed modules are successfully imported, "nothing happens", when at
lest one fails to import, the entire build fails. The above line is translated
very-roughly to `python3 -c 'import mymodule, mymodule.submodule'` (see the
implementation [0] for more accurate representation). Given the Python
semantics, it is possible to use commas as module separators as well (but no
parentheses).
The %buildroot's %pythn3_site{lib,arch} is added to PYTHONPATH.
The runtime dependencies are obviously needed for this to work, so they need to
be manually BuildRequired or even better, generated in %generate_buildrequires
via `%pyproject_buildrequires -r` to use this macro.
The macro can be used repeatedly when importing multiple modules at once is
undesired (e.g. when only one module can be imported from the same Python
interpreter):
%check
%py3_check_import mymodule.either
%py3_check_import mymodule.or
Before I merge this and backport to all Fedoras and EPELs, I'd like to know:
- Do you have better ideas for the macro name?
- Do you have better ideas for the macro semantics?
[0]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
[1] https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/99
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
2 years, 9 months
