packaging July 2021

packaging@lists.fedoraproject.org

4 participants
14 discussions

Summary/Minutes from today's FPC Meeting (2021-07-15 16:00 - 16:20 UTC)
by James Antill 15 Jul '21

15 Jul '21

====================== #fedora-meeting-1: fpc ====================== Meeting started by geppetto at 16:00:43 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2021-07-15/fpc.2021-07-1… . Meeting summary --------------- * Roll Call (geppetto, 16:00:43) * Schedule (geppetto, 16:10:28) * LINK: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… (geppetto, 16:10:32) * #pr-1072 Python Packaging Guidelines overhaul (geppetto, 16:11:44) * LINK: https://pagure.io/packaging-committee/pull-request/1072 (geppetto, 16:11:44) * Open Floor (geppetto, 16:15:17) Meeting ended at 16:21:09 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * geppetto (26) * zodbot (15) * mhroncok (10) * tibbs (9) * decathorpe (5) * Eighth_Doctor (4) * carlwgeorge (2) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

Re: Macro to smoke-test-import a Python module in %check
by Miro Hrončok 11 Jul '21

11 Jul '21

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

1 0

Directory ownership of %{_datadir}/icons/hicolor
by Otto Urpelainen 04 Jul '21

04 Jul '21

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_direct… [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1919639 [3]: https://docs.fedoraproject.org/en-US/packaging-guidelines/UnownedDirectorie…

4 8

Macro to smoke-test-import a Python module in %check
by Miro Hrončok 01 Jul '21

01 Jul '21

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.org… [1] https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/99 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

3 5

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging July 2021