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
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
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
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
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
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
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)
