openSUSE Packaging December 2020

packaging@lists.opensuse.org

29 participants
7 discussions

Multi-spec packages only need a single .changes file now
by Fabian Vogt 05 Jan '21

05 Jan '21

Hi, Previously, packages with multiple spec files (e.g. systemd, which has both systemd.spec and systemd-mini.spec) needed a .changes file for each .spec. As the vast majority of changes (e.g. version updates) affect all "flavors", this requirement got dropped and only a single .changes file with the name used for the submit request is needed. It's used for all .spec files during build. References: https://github.com/openSUSE/obs-service-source_validator/pull/88 https://github.com/openSUSE/openSUSE-release-tools/pull/2507 Cheers, Fabian

2 2

Python 3 parallel install (Re: Tumbleweed - Review of the week 2020/52)
by Ben Greiner 26 Dec '20

26 Dec '20

Hello, my apologies in advance if this mail reaches you up to three times, but in my opinion the topic is relevant and important to reach people subscribed to all three mailing lists. Am 25.12.20 um 18:34 schrieb Dominique Leuenberger / DimStar an factory(a)lists.opensuse.org: > * Multiple python 3 versions parallel installable. Adding to python > 3.8, version 3.6 will be reintroduced. Python modules will be built > for both versions. This line sounds rather innocent, but it has severe implications: Every package python-foo, which uses the so called singlespec macro %python_subpackages, will also try to build a python36-foo package. The whole build process will fail if a step in that particular flavor fails or if building for more than one flavor will create conflicts. We took care [1] of all the packages in Ring0 and Ring1, which popped up as problematic in the staging project. But there are many more packages, which will see the change the first time, when the staging project will be accepted into Factory. You can refer to the documented changes in [1] for examples how to fix a package. There are also some updates to the wiki [2] and the documentation of python-rpm-macros [3]. In particular, look out for: - Packages already skipping Python 2 will start to produce more than one package. Avoid duplicate files by using update-alternatives (there are macros for it in python-rpm-macros), or put common files into unflavored subpackages. - If you provide or require python3-foo, it will only do that for the primary python interpreter. Replace `BuildRequires python3-foo` by `BuildRequires %{python_module foo}` and let the %python_subpackages macro do the work for all Tags and macros where it can replace the unflavored variants e.g.: * `Requires: python-bar` instead of python3-bar. * `%python_sitelib` instead of `%python3_sitelib` in `%files` - Some packages need extra packages backporting stuff to Python 3.6, e.g. importlib-metadata or dataclasses. See black as an example how to deal with this [4] - If upstream does not support python 3.6 anymore (Numpy already deprecates to support it in new releases, according to NEP 29 [5]) you can use `%define skip_python36 1`. All depending packages need to do the same. Alternatively a branched package can provide an older version for this flavor, e.g. python-ipython715 has been created to provide the last version which support Python 3.6. - Python "apps" not following the flavored python-foo naming scheme, will only collect files for one (hopefully the primary python3 providing) flavor during the packaging phase. Remove %python_modules, %python_build, %python_install, %python_expand and the sort, as it unnecessarily pulls in packages for all python flavors and tries to build and install into multiple sitelib/sitearch directories. Replace by calling python3 directly or use the equivalent %python3_* macros. - Some non-singlespec packages only create python3-foo. They will either need an update to include python36-foo, python38-foo (and python39-foo in the near future), or all depending packages must only build for the primary python3, too. `%define pythons python3` or skip all non-primary interpreters. - The previous item is also true for many packages, which have a python bindings subpackage but are not Python only. We introduced %python_subpackage_only so that these packages now can take advantage of the singlespec macros as well. The tracker comment on GitHub [6] has links to a few examples how to use it. - %ifpython3 and %python3_only are evil. They have been deprecated for some months already. Essentially, they fail to recognize the new flavors python36 and python38 which replace python3. OTOH, older distributions will continue to use the python3 flavor. We have introduced a new %python_provides macro, but did not modify %ifpython3 or %python3_only to incorporate this, because it is not automatically clear whether the conditioned code block shall apply to all flavors of Python3 packages or only to the primary interpreter. Replace by something like * `%if "%{python_flavor}" == "python3" || "%{?python_provides}" == "python3"` for sections only provided by the primary flavor. * `%if 0%{python_version_nodots} > 34` or `%if "%{python_flavor}" != "python2"` for section applicable to all Python 3 flavors. Cheers and happy coding, Ben [1] https://github.com/openSUSE/python-rpm-macros/issues/66 [2] https://en.opensuse.org/openSUSE:Packaging_Python [3] https://github.com/openSUSE/python-rpm-macros/blob/master/README.md [4] https://build.opensuse.org/request/show/853412 [5] https://numpy.org/neps/nep-0029-deprecation_policy.html [6] https://github.com/openSUSE/python-rpm-macros/issues/66#issuecomment-715538…

3 3

looking for Python.h
by Axel Braun 21 Dec '20

21 Dec '20

Hi, as subject tells, does anyone know in thich package Python.h is hidden? (Its not python3-devel nor python3-pybind11-devel) Thanks in advance! Axel

4 5

Re: Please create OBS project Application:Hardware
by Mark Stopka 18 Dec '20

18 Dec '20

Perhaps HardwareDevelopment would be better... -- Sent from mobile Best regards / S pozdravem, BSc. Mark Stopka, BBA Managing Partner @ PERLUR Group mobile: +420 704 373 561 website: www.perlur.cloud On Fri, Dec 18, 2020, 00:13 Mark Stopka <mstopka(a)opensuse.org> wrote: > -- > Best regards / S pozdravem, > BSc. Mark Stopka, BBA > Managing Partner (at) PERLUR Group > > mobile: +420 704 373 561 > website: www.perlur.cloud > > > ---------- Forwarded message --------- > From: Mark Stopka <mstopka(a)opensuse.org> > Date: Thu, Dec 17, 2020 at 6:58 PM > Subject: Please create OBS project Application:Hardware > To: <heroes(a)lists.opensuse.org> > Cc: oS-project <project(a)lists.opensuse.org> > > > Hi, > can you please create an OBS project Application:Hardware and assign > me as owner? The repository is intended to include HW development > tools such as FPGA synthesis tools from SymbiFlow project and > functional verification tools such as cocotb, iverilog, verilator,... > > Please see thread below, it is a migration from CentOS to openSUSE as > a open hardware development platform... > > https://github.com/tropicsquare/tassic/discussions/1 > -- > Best regards / S pozdravem, > BSc. Mark Stopka, BBA > Managing Partner (at) PERLUR Group > > mobile: +420 704 373 561 > website: www.perlur.cloud >

2 2

move restart-on-update to posttrans
by Olaf Hering 16 Dec '20

16 Dec '20

Did anyone already explore the potential pitfalls of moving "restart on update" from %postun to %posttrans? There are two bugs with the current approach: First, having "restart on update" handling in %service_del_postun gives control to the old and potentially broken package. This alone should already be enough reason to change the flow of events. Second, the current approach makes it practically impossible to remove empty configuration files from the rpm packages. There are already a number of packages which have code like this: %pre test -f /etc/%{name}.conf.rpmsave && mv -v /etc/%{name}.conf.rpmsave /etc/%{name}.conf.rpmsave.old %posttrans test -f /etc/%{name}.conf.rpmsave && mv -v /etc/%{name}.conf.rpmsave /etc/%{name}.conf This will fail for configuration files required by daemons which will be restarted via 'systemctrl try-restart' in the %postun of the old package. Since the removed config is renamed to *.rpmsave prior %postun, and renamed back after the 'try-restart' in %posttrans, the daemon will find no config file. Some of the daemons start without a config, which means the daemon runs with its default configuration. Other daemons will fail to restart due to the lack of config file. The actual state whether a systemd service was running is lost, no way to attempt another restart in %posttrans. I think the following steps are required to get out of this bad situation: - all packages with a %service_del_postun/_without_restart need to get a %service_add_posttrans/_without_restart into their %posttrans. For packages without existing %posttrans the change will look like this, to make sure they remain compatible: %if %{defined service_add_posttrans} %posttrans %service_add_posttrans %{name}.service %endif Packages with a %postrans: %posttrans %if %{defined service_add_posttrans} %service_add_posttrans %{name}.service %endif - once all packages in Factory have received the change, adjust the package which owns %service_del_postun/%service_add_posttrans and actually carry out the bugfix: * %service_add_pre will rename /etc/sysconfig/services:DISABLE_RESTART_ON_UPDATE= to a new, to-be-found variable name. * %service_add_pre will set /etc/sysconfig/services:DISABLE_RESTART_ON_UPDATE= to yes so that the old, expanded "%_restart_on_update" does no damage anymore in the existing %postun scripts * %service_del_postun will lose the code which does 'systemctrl try-restart' * %service_add_posttrans will do the 'systemctrl try-restart', hopefully based on a better %_restart_on_update. The current one does 'exit 0' ... - adjust yast to deal with the renamed DISABLE_RESTART_ON_UPDATE= - adjust documentation, describe why the change had to be done Olaf

8 22

colored osc build output
by Hans-Peter Jansen 10 Dec '20

10 Dec '20

Hi, is it possible to trick a local osc build into producing colored output without much fuzz? The point is, if I 'osc chroot' into the package and trigger a build manually, colored output is generated. Therefor I guess, rpmbuild ignores/avoids certain environment values (COLORTERM?) for better parsebility. For local builds of huge projects, colored output would be much nicer, since it would be easier to distinguish between warnings and errors. Cheers, Pete

6 12

Logrotate, /var/log but logging disabled by default
by Thorsten Kukuk 07 Dec '20

07 Dec '20

Hi, we have quite some packages, which: 1. require logrotate and ship a logrotate configuration file 2. have a special directory in /var/log 3. never create a log file as they are controlled by systemd The reason the packages never write to the log file by default is, that they log to stdout/stderr and systemd/journald captures them. What should we do with such packages? Requiring logrotate, even if never used by default, is already a bad idea. It runs regular (so uses resources) without doing anything. Clobbering /var/log with special directories and files owned by special users will also only trigger actions, even if never used. What would be a good solution? I understand that some people may want to run this tools without control by systemd. But on the other side, in this cases the people have to adjust the configuration anyways. Maybe a good solution could be: - continue to ship the logrotate configuration file - only Recommend logrotate, not require it - let the admin create the configuration file and directory Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)

12 30

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging December 2020