openSUSE Packaging May 2023

packaging@lists.opensuse.org

18 participants
8 discussions

Is it recommended that Recommended are switched off?
by Matěj Cepl 28 May '23

28 May '23

See https://bugzilla.suse.com/1211446 … it seems to me that this attitude, that everybody switch off Recommends, because they bring too much garbage, so it is all right that packages bring too much garbage, is rather evil. Any comments on it? Best, Matěj -- https://matej.ceplovi.cz/blog/, @mcepl@floss.social GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Don’t anthropomorphize computers. They don’t like it.

7 7

Re: Is it recommended that Recommended are switched off?
by Manfred Schwarb 26 May '23

26 May '23

Sorry, reply button turned into a personal response to the poster, instead heading towards the list. Am 26.05.23 um 09:51 schrieb Manfred Schwarb: > Am 25.05.23 um 10:52 schrieb Thorsten Kukuk: >> On Wed, May 24, Matěj Cepl wrote: >> > > [...] > >> Now with Requires, Recommends and Suggests it's a little bit better, but >> yes, there is still far too much "crap" in it. Quite some people only >> changed their Requires to Recommends, so if you install package X, it >> will still pull in mariadb, postgresql, ... and other databases at the >> same time. That's why many people disable recommends... >> >> And of course there is MicroOS and containers, where we really only want >> the bare minimal and nothing "may be usefull", thus we disabled >> recommends by default. >> >> Requires: the package will not work in any case without this dependency >> Recommends: the package will work without this dependency installed, but >> this could mean, that not all features are useable. This should be a >> usefull, minimal set of dependencies, which allows the user to use >> common functionality of the package without the need to install >> additional packages. >> Suggests: packages which could be usefull >> > > While there is "zypper install --recommends", there is no such thing for > suggests. If the user can't install suggested packages by a single command, > the dependency tag "Suggests:" remains useless. If "Suggests:" would be > functional, one could think of migrating some entries from "Recommends:" to > "Suggests:". > "Suggests:" should really be similar to "Recommends:", just turned off by default, > and with corresponding tooling support. > > Cheers, > Manfred >

1 0

Safely testing the new python3.11 stack on Leap15/SLE15?
by Johannes Kastl 24 May '23

24 May '23

Hi all, I think I got everything I new for Ansible and its ecosystem building and running on SLES15/Leap15 with the 3.11 python stack. Except the actual python stack. Which repositories would I need to add to get it (for testing if there are any runtime dependencies that I missed)? I tried to understand the setup of the SLE15/Leap15 projects in OBS. But as far as I understood those are coming from a download-on-demand repo on http://suse-sle-mirror. And at that point I gave up and decided to ask how to do that. :-) 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 3

New to OBS python package won't build - for accessing PST files
by Greg Freemyer 22 May '23

22 May '23

All, I won't to be able access PST files from python. python-libratom is a package for doing that. It layers on top of libpff, which is already in factory. I've got my initial OBS package at: home:gregfreemyer:Tools-for-forensic-boot-cd/python-libratom [https://build.opensuse.org/package/show/home:gregfreemyer:Tools-for-forensi…] Unfortunately, %python_build is failing as shown in the below log. Can anyone tell how this package should be built? ===== [ 26s] + python_flavor=python39 [ 26s] + /usr/bin/python3.9 setup.py build '--executable=/usr/bin/python3.9 -s' [ 27s] /usr/lib/python3.9/site-packages/setuptools/__init__.py:84: _DeprecatedInstaller: setuptools.installer and fetch_build_eggs are deprecated. [ 27s] !! [ 27s] [ 27s] ******************************************************************************** [ 27s] Requirements should be satisfied by a PEP 517 installer. [ 27s] If you are using pip, you can try `pip install --use-pep517`. [ 27s] ******************************************************************************** [ 27s] [ 27s] !! [ 27s] dist.fetch_build_eggs(dist.setup_requires) [ 27s] WARNING: The wheel package is not available. [ 27s] Error parsing [ 27s] Traceback (most recent call last): [ 27s] File "/usr/lib/python3.9/site-packages/pbr/core.py", line 105, in pbr [ 27s] attrs = util.cfg_to_args(path, dist.script_args) [ 27s] File "/usr/lib/python3.9/site-packages/pbr/util.py", line 272, in cfg_to_args [ 27s] pbr.hooks.setup_hook(config) [ 27s] File "/usr/lib/python3.9/site-packages/pbr/hooks/__init__.py", line 25, in setup_hook [ 27s] metadata_config.run() [ 27s] File "/usr/lib/python3.9/site-packages/pbr/hooks/base.py", line 27, in run [ 27s] self.hook() [ 27s] File "/usr/lib/python3.9/site-packages/pbr/hooks/metadata.py", line 25, in hook [ 27s] self.config['version'] = packaging.get_version( [ 27s] File "/usr/lib/python3.9/site-packages/pbr/packaging.py", line 874, in get_version [ 27s] raise Exception("Versioning for this project requires either an sdist" [ 27s] Exception: Versioning for this project requires either an sdist tarball, or access to an upstream git repository. It's also possible that there is a mismatch between the package name in setup.cfg and the argument given to pbr.version.VersionInfo. Project name libratom was given, but was not able to be found. [ 27s] error in setup command: Error parsing /home/abuild/rpmbuild/BUILD/libratom-0.7.1/setup.cfg: Exception: Versioning for this project requires either an sdist tarball, or access to an upstream git repository. It's also possible that there is a mismatch between the package name in setup.cfg and the argument given to pbr.version.VersionInfo. Project name libratom was given, but was not able to be found. [ 27s] error: Bad exit status from /var/tmp/rpm-tmp.mhkE0b (%build) Thanks, Greg -- Greg Freemyer Advances are made by answering questions. Discoveries are made by questioning answers. — Bernard Haisch

3 3

Building a python module only for x86_64?
by Johannes Kastl 15 May '23

15 May '23

Good <insert-time-of-day> everyone, I am trying to package pynitrokey for openSUSE, which requires https://github.com/nxp-mcuxpresso/pypemicro I packaged it and it builds successfully, but only on x86_64. All other architectures fail, as apparently the module does not support it. I am in clarification with upstream. If x86_64 is really the only architecture, how would I prevent builds for other architectures? Simply disable the build targets in my branched project, submit to dlp (and disable them there too) and submit to Factory asking to only build for x86_64? Or is there something I should add inside the spec? ExclusiveArch or ExcludeArch sound like they could do the job, not sure if they are being used for openSUSE? 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

3 6

How to properly BuildRequire an older version of a python package?
by Johannes Kastl 12 May '23

12 May '23

Hi all, python-ansible-compat had a new release 4.0.2, which brings improvements but is not compatible with the older 3.0.2 release. ansible-lint works with the new one, molecule does not yet. I wanted to package both until molecule gets updated, but as soon as the new one is present, molecule is "unresolvable". And I thought this worked for similar problems in the past, so I might just miss something. > https://build.opensuse.org/project/show/home:ojkastl_buildservice:Branch_sy… python-ansible-compat is 4.0.2 python-ansible-compat-3 is 3.0.2 Both have "Use for build" enabled. molecule has this in the spec: BuildRequires: (%{ansible_python}-ansible-compat >= 2.2.0 with %{ansible_python}-ansible-compat < 4) I also tried to use "... >= 3.0.0" or "== 3.0.2", but I only get this: unresolvable: nothing provides python311-ansible-compat = 3.0.2 (got version 4.0.2-lp154.28.2) or unresolvable: nothing provides python3-ansible-compat = 3.0.2 (got version 4.0.2-28.3) Can someone spot my mistake? What am I missing? 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 5

sle15_python_module_pythons
by Eric Schirra 08 May '23

08 May '23

I see more and more %{?sle15_python_module_pythons} and %{sle15modernpython} in packages changes. But i can't find any documentation about it. Not in wiki and not in python-rpm-macro. So what's the deal with "%{?sle15_python_module_pythons}" ? And what's the deal with "%{sle15modernpython}" ? Regards Eric

7 24

openSUSE:Factory i586
by Arjen de Korte 03 May '23

03 May '23

In many development repositories, packages are being build for openSUSE:Factory not only for x86_64, but also for i586. Since the vast majority of packages are excluded in the i586 in openSUSE:Factory, this means that quite a number are build with packages that are no longer up-to-date. It is my understanding that for the i586 flavor one should build for openSUSE:Factory:LegacyX86 instead. Am I correct in this? Should development repositories cease to build i586 packages for openSUSE:Factory and use openSUSE:Factory:LegacyX86 instead? If so, can this be somehow automated, since there are lots of development repositories that still happily build i586 packages in openSUSE:Factory.

2 1

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging May 2023