August 2021 - openSUSE Packaging - openSUSE Mailing Lists

%posttrans, %transfiletriggerin, and script ordering
by Martin Wilck 30 Aug '21

30 Aug '21

Can anyone tell what exactly happens if an rpm transaction contains both calls to %posttrans and %transfiletriggerin? Is there any reliable order in which these scripts are called in the posttrans stage? Or putting it differently, is there any way to make sure the %posttrans script of package A runs after the %transfiletriggerin of package B, or vice versa? Regards Martin

3 2

spec file rewrite on local rebuilds deliberately removes comments
by Hans-Peter Jansen 20 Aug '21

20 Aug '21

Hi, building https://build.opensuse.org/package/show/home:frispete:test/freerdp locally with osc, I noticed a very unpleasant behavior. The spec file rewriter removed all lines of the third comment on top of this file. In fact, anything commented out in this area deliberately gets removed. Is this on purpose? I guess, the spec is piped through spec-cleaner, and it even removes this: #nospeccleaner Urmpf. Best, Pete

3 5

Enabling i586 arch in multimedia:libs
by Antonio Larrosa 17 Aug '21

17 Aug '21

Hi, Someone mentioned that the pipewire *-32bit packages were not being generated in multimedia:libs for Leap (even if pipewire has a proper baselibs.conf file). I noticed then that the -32bit packages were not being generated in multimedia:libs for any package at all and it seems to be caused by the Leap repositories having only the x86_64 arch in the project's meta. But afaik, we don't want to publish i586 packages for Leap, right? Is the correct way to fix this to add the i586 arch in the meta and then disable the "Publish flag" for the i586 arch? or is there some other recommended way? Thanks, -- Antonio Larrosa

7 10

packages pointing to wrong project
by Axel Braun 10 Aug '21

10 Aug '21

Hi, I'm currently preparing the next release of GNU Health and Tryton. What I did: - copied the files from Application:ERP:GNUHealth:Factory (Development Repo for Factory) to Application:ERP:GNUHealth:4.0 (the next release) - updated all tryton* packages to version 6 - Created a Project Application:ERP:Tryton:6.0 and copied all packages from Application:ERP:Tryton:5.0 to this directory Now copied the already upgraded tryton6 packages from Application:ERP:GNUHealth:4.0 to Application:ERP:Tryton:6.0, and checked this out locally ~/buildservice/Application:ERP:Tryton:6.0 So far so good. But the tryton6 files in A:E:T:6.0 coming from GNUHealth:4.0 still point to the A:E:G:4.0 project. Is there an easy way to fix this? Thanks Axel

2 1

SLE package submissions and Factory
by Lars Vogdt 06 Aug '21

06 Aug '21

Hi @ll You might have noticed, that SUSE started with the next service pack (SP4) for SLE-15 already. As there is a general guideline for all packagers to submit their packages to "Factory first", we noticed that there might be some conflicts with packages, that will differ between SLE and Factory. The following is especially interesting for SUSE packagers (but reading it being a "Factory only submitter" will not harm ;-), submitting to SLE: To make all our life a bit more easy, please consider to review the following page: https://en.opensuse.org/openSUSE:Packaging_for_Leap There is already a table with "Agreed differences from Factory". Please use this table, if your package needs to drift away from Factory in SLE. The reviewers will use this table during the review - and Marketing might use it as well for release-notes later. - A note about Changes files - We also noticed that some use the opportunity that SLE-15-SP4 will be a feature release (including new package versions and features), to jump with their SLE package on the version in Factory. While we see this as a good step in general, we often see differences in the .changes file. We decided to accept such differences - with a few exceptions. Most important are: * bugzilla references are kept * CVE references are kept * Changelog stays in chronological order * patches added/removed with the new submission While this might result in more work in the beginning (and additional changes entries for keeping bsc# or CVE numbers), there is meanwhile a lot tooling around these bsc#, boo# and CVE numbers. This tooling might break and give everyone headaches in a few years, if we need to check if a bug or CVE is already fixed in the current package version. So feel free to take your Factory package and submit it to SLE. But please review the old package in SLE-15-SP3 before and grep out all the bug- and CVE numbers. Those, which are missing, can be added as new changes entry. - Get in touch - And finally: if submitting a package to Factory or SLE via osc - please remember that you have the chance to inform the reviewers via the comment for this submit request. The comment (which is create by calling 'osc sr') per default just contains a copy of the last changes entry, but this can be changed. Feel free to inform the reviewers about your big changes upfront, so they don't need to decline the package first. Knowing, that a changes entry has a big diff by intention - or that you rewrote the whole spec file - gives the reviewer a good feeling, that your submission was not done by mistake... with kind regards, Lars

1 0

Jupyter: split and obsolete files
by Ben Greiner 04 Aug '21

04 Aug '21

Hi, A few days ago I updated the python-ipykernel package to version 6, which dropped support for Python 3.6. In order not to have to fix all Jupyter/IPython packages I decided to also create python-ipykernel5 which is supposed to provide python36-ipykernel = 5.5.5-$release. Now in the same strike, I decided to drop the unflavored jupyter-ipykernel package, which provided the Jupyter kernelspec for the primary flavor only. Instead now all the python3X flavored packages provide their own kernelspec. In order to keep the upgrade path, the primary python3 flavor package provides/obsoletes jupyter-ipykernel now. The planned situation would be: >> python38-ipykernel-6.0.3-1.1.noarch.rpm Provides: python3-ipykernel = 6.0.3-1.1 Obsoletes: python3-ipykernel < 6.0.3-1.1 Provides: jupyter-ipykernel = 6.0.3-1.1 Obsoletes: jupyter-ipykernel < 6.0.3-1.1 >> python39-ipykernel-6.0.3-1.1.noarch.rpm *None of the above primary flavor only tags* >> python36-ipykernel5-5.5.5-2.1.noarch.rpm Provides: python36-ipykernel = 5.5.5-2.1 Obsoletes: python36-ipykernel < 5.5.5-2.1 >> No jupyter-ipykernel-X.Y.Z-Rm.Rn.noarch.rpm >> jupyter.spec BuildRequires: %{python_module ipykernel} BUT: Right now in the Tumbleweed repos/Factory, there still exists python-ipykernel version 5.5.5 with the subpackages jupyter-ipykernel-5.5.5 and >> python36-ipykernel-5.5.5-1.1.noarch.rpm Requires: jupyter-ipykernel = 5.5.5 So I get: ~:devel:languages:python:jupyter/jupyter> osc buildinfo -d ... <error>unresolvable: conflict for providers of jupyter-ipykernel = 5.5.5 needed by python36-ipykernel (provider jupyter-ipykernel is obsoleted by python38-ipykernel)</error> ... added python36-ipykernel@openSUSE:Tumbleweed/dod because of python36-ipykernel (direct dep) Here I thought the Obsoletes tag in python-ipykernel5 would be enough to tell OBS to take the higher ordered split package instead of the still existing python36-ipykernel-5.5.5. Any ideas how to solve this without editing all specfiles requiring ipykernel? Regards, Ben

1 0

The upstream of man-pages-zh_CN is too old.
by W 02 Aug '21

02 Aug '21

This package: https://build.opensuse.org/package/show/openSUSE:Factory/man-… is too old.The upstream of this package has not been updated for a long time, and distributions such as debian/ubuntu have switched to the new upstream. The new upstream of man-pages-zh_CN: man-pages-zh/man-pages-translation: Translation working repo for man-pages-zh (github.com)

3 2