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/88https://github.com/openSUSE/openSUSE-release-tools/pull/2507
Cheers,
Fabian
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…
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
>
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
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
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)
