November 2022 - openSUSE Packaging - openSUSE Mailing Lists

Howto for packaging a JAVA application using maven?
by Johannes Kastl 26 Nov '22

26 Nov '22

Hi all, I noticed that openSUSE does not yet have a cryptomator package, so I wanted to try packaging it. Unfortunately this is some kind of java application with a pom.xml, that seems to be built using maven. The wiki page is very out of date (2010), so I am looking for packages that are built using maven, that I could copy from. Searching for maven of course only spits out the maven packages. Does anyone know a nice package that I could take as reference? Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl(a)b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

3 6

Working ansible and ansible-lint packages for Leap 15.4 / SLES15SP4: Open questions on the fine details of python packaging
by Johannes Kastl 25 Nov '22

25 Nov '22

TL;DR There are working packages for ansible, ansible-core and ansible-lint (and all of their dependencies) for Leap 15.4 and SLES15SP4 with python3.10. Hi all, as I had the request for ansible and ansible-lint packages for SLES15 SP4 I started the journey, and some 100 packages later I got it working. > https://build.opensuse.org/project/show/home:ojkastl_buildservice:ansible_f… > https://build.opensuse.org/project/show/home:ojkastl_buildservice:ansible-l… Which depend on and build against these projects: > https://build.opensuse.org/project/show/home:ojkastl_buildservice:cblas_for… > https://build.opensuse.org/project/show/home:ojkastl_buildservice:pytest_de… > https://build.opensuse.org/project/show/home:ojkastl_buildservice:pytest_fo… Due to my limited understanding of the python macros I used a simple prjconf to only build against the python3.10 version in the Python3 module of SLES15SP4. > %define pythons python310 > %define primary_python python310 > > Substitute: python3-base python310-base > > Macros: > %pythons python310 > %primary_python python310 > :Macros That did the trick for most of the packages, but I have two questions: 1. Several packages failed as they correctly BuildRequire python310-setuptools, but not python310-base. I added a line to their spec file and all was well. Example: > https://build.opensuse.org/package/show/home:ojkastl_buildservice:pytest_de… Question: Is this something that should be fixed, i.e. should I open SRs for those packages? Or this due to an error I made somehow in the prjconf? Should the setuptools package BuildRequire the corresponding python3*-base package? I do not want to frequently repair broken links in the packages, but I did not want to use Preinstall or similar from the prjconf. 2. I had to refine the spec files for ansible, ansible-core, ansible-lint. As those are just building against the default python in Tumbleweed (i.e. they are not available as python310-ansible-...). I made them kind-of-singlespec, while defining only one python version in the "%pythons" macro. But I had to use the %primary_python macro to properly set the Requires, as singlespec and the macros did not help there. And just using "%pythons" would make this fail on Tumbleweed where there are multiple python versions. And as the %pythons macro needs to be set inside the spec file to overwrite this on Tumbleweed, I had to define it again inside the package. Example: > https://build.opensuse.org/package/rdiff/home:ojkastl_buildservice:ansible_… I would like to forward the changes to the ansible packages in Tumbleweed. Question to the python packaging experts: Any hints or objections? Any flaws that might make this fail for $REASON? And: Is there a macro that contains the executable name for the primary python? The ansible-lint packages contains calls to python3.10 for %build and %install, not sure if those could be replaced by some macro-foo. Thanks in advance! Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl(a)b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

2 7

Regression: OBS does not install gzip when building Arch Linux packages, which breaks builds
by - - 23 Nov '22

23 Nov '22

Please refer to https://github.com/openSUSE/open-build-service/issues/13403 for details. (This issue has been forwarded to this list as per danidoni's instructions.)

1 0

obsoleting shared libraries (libsgutils)
by Martin Wilck 04 Nov '22

04 Nov '22

I know this has been discuseed before [1], but I couldn't figure out what the definitive answer was. sg3_utils uses a fine-grained SONAME for libsgutils, currently we have libsgutils2-1_47-2. As I'm preparing a pre-release of 1.48 with some important improvements, the new SONAME is now libsgutils2-1_48-2. No other packages except sg3_utils and libsgutils-devel seem to depend on this library, so it would make sense to uninstall the old version when sg3_utils is updated. zypper rm --clean-deps isn't going to help people who want to upgrade. Is there a trick that would not leave every TW user with two installed libsgutils packages when I push the update? I guess I could add a manual "Obsoletes", but that's both clumsy and against the Shared library packaging policy. Thanks, Martin [1] https://lists.opensuse.org/archives/list/packaging@lists.opensuse.org/threa…

2 2