July 2021 - openSUSE Packaging - openSUSE Mailing Lists

python-google-resumable-media incorrect requirements in Factory
by Sean Marlow 30 Jul '21

30 Jul '21

Hi All, I was going to fix the runtime requirements for python-google- resumable-media [1] but realize it's a little more complex then adding the missing requirement [2]. There's different requirements for python2 vs python3 and I'm not familiar with how to handle this with latest single spec. Can you please provide some pointers here? For python3 we want python3-google-crc32c For python2 it's python2-crcmod These are currently listed as build requirements but missing from runtime requirements in spec. Based on the package setup.py file they should be required according to Python version as mentioned above. Also the aiohttp requirement is in build requirements list. However, it's an extra like requests so it seems like it should be a recommends: Recommends: python-aiohttp How do we handle python version specific requirements in spec with the multi python changes in Factory? [1]https://build.opensuse.org/package/show/devel:languages:python/python-goo… [2]https://github.com/googleapis/google-resumable-media-python/blob/master/s… Thanks, Sean

1 0

Re: Build an Arch Linux repository with Open Build Service
by Axel Braun 29 Jul '21

29 Jul '21

Hi, please answer to the list, not to me personally: Am Donnerstag, 29. Juli 2021, 09:02:59 CEST schrieb 山田ハヤオ: > I have already read the guidelines. > But it's a simple Arch Linux link to the WIki, nothing about the Open Build > Service. Looks like the documentation needs some love.... > I want to migrate the packages I post to AUR to Open Build > Service. > > There are various files in the osc package. > Which of them do you need for Arch Linux? osc as I can see from PKGBUILD. There are additional dependencies (python-m2crypto) where OBS takes care about. HTH Axel

1 0

how to fix unversioned Obsoletes
by Jason Craig 21 Jul '21

21 Jul '21

I was going to update python-colander (https://build.opensuse.org/package/show/home:jacraig:branches:devel:languag…) but RPM has this to say: [ 123s] RPM build errors: [ 123s] line 37: It's not recommended to have unversioned Obsoletes: Obsoletes: python2-colander-doc [ 123s] line 38: It's not recommended to have unversioned Obsoletes: Obsoletes: python2-colander-lang [ 123s] line 39: It's not recommended to have unversioned Obsoletes: Obsoletes: python3-colander-doc [ 123s] line 40: It's not recommended to have unversioned Obsoletes: Obsoletes: python3-colander-lang etc. It merely says it's not recommended yet refuses to build (I guess we can quibble about what recommended means). At any rate, how do I fix this? The Obsoletes were apparently added when the -doc and -lang packages were dropped. Would I replace the Obsoletes with e.g. Obsoletes: python2-colander-doc < 1.8.3 (etc.) where 1.8.3 is the new version that I would update to? Or use some other version? Or is the syntax different than that? The RPM documentation's short blurb about Obsoletes literally does not show any syntax nor does it mention anything about versions. Am I the only one who finds the documentation on rpm.org obtuse and less than helpful pretty much every time I look at it? thanks, -- Jason Craig

5 5

Utility to get outdated packages
by Danilo Spinella 17 Jul '21

17 Jul '21

Hi everyone! I have just written a little utility that fetches the list of maintained packages from build.opensuse.org and then it checks on repology if the package is outdated or not. For now it works only on Devel projects. Posting to get some feedback and checking if there is already some other utility that does the same. https://github.com/danyspin97/osutil Regards, Danilo

5 5

Bot enhancement: factory-maintainers set as maintainer on devel projects
by Dominique Leuenberger / DimStar 16 Jul '21

16 Jul '21

Dear Factory contributos and packagers, Hereby I inform you of an upcomig change in factory-auto (the first line of defence for factory submissions - a bot, loved by some, hated by others) I had requested an addition of a new check [0] into the bot, which has now been implemented and will go live soon™ (speak: today). The bot will newly check if the group 'factory-maintainers' is assigned the maintainer role in the devel project the submission is coming from. This requirement is not new at all, but it was checked manually and acted upon manually so far. Every now and then it was forgotten and resulted in errors when accepting requests into Factory (as convert-to- branch and devel prj initialisation, especially on new packages, did not work without these permissions). Instead of running into failures on accept (which can be frustrating, as they happen at the very end, often after days of working out issues), we will now reject the request (too many users tend to be slow on comments, but react fast on declines) and file an automaic add-role request for the factory-maintainers. Once this was accepted by the devel project maintainers, the original request can simply be reopened by the submitter and everything moves as usual. For all existing pasckages, this should not cause any issues, as the existing devel projects should all have the group assigned already. In Cheers, Dominique [0] https://github.com/openSUSE/openSUSE-release-tools/issues/2429

2 1

CentOS_8_Stream: unresolvable: nothing provides cargo
by Wong Hoi Sing Edison 16 Jul '21

16 Jul '21

Hi all, I would like to build https://github.com/systemd/zram-generator with OBS, and already able to handle packaging for both (see https://software.opensuse.org//download.html?project=home%3Aalvistack&packa…) - openSUSE Leap 15.3 / Tumbleweed - Fedora 33 / 34 - Debian 10 / 11 - Ubuntu 20.04 / 20.10 / 21.04 Since it is a Rust-based project, when packaging on CentOS 8 Stream I need to `BuildRequires: cargo` which is located in AppStream (see https://centos.pkgs.org/8-stream/centos-appstream-x86_64/cargo-1.52.1-1.mod…) I had add "CentOS:CentOS-8/appstream" as additional repository path under "CentOS_8_Stream" at https://build.opensuse.org/repositories/home:alvistack. Ideally cargo should be found but now display an error message as below (see https://build.opensuse.org/package/binaries/home:alvistack/zram-generator/C…) The build can not begin, because required packages are either missing or not explicitly defined. Repository has been published unresolvable: nothing provides cargo May I have some hints about how to install cargo for CentOS 8 Stream, therefore passing the packaging process? Regards, Edison Wong

2 2

Did the list just release all backlogged spam or something?
by Jason Craig 15 Jul '21

15 Jul '21

I'm hoping this isn't going to occur on the other lists too, I might unsubscribe if I'm going to be receiving hundreds of old spam messages on every list now. -- Jason Craig

2 2

python setuptools_scm and rpm versioning
by Martin Wilck 12 Jul '21

12 Jul '21

The "duplicity" package uses python's setuptools_scm module to substitute the package version in its own sources. For development versions that aren't tagged, setuptools_scm uses the format "$NEXT_VERSION.dev$N", where NEXT_VERSION is the guessed subsequent/future version, and $N is the commit distance from the last released version. This scheme doesn't work with rpm. AFAIK, for rpm we must use $NEXT_VERSION~$N instead to achieve the desired ordering: $CURRENT_VERSION < $NEXT_VERSION~$N < $NEXT_VERSION~$((N+1)) < $NEXT_VERSION Unfortunately the ".dev" format is hard-coded in setuptools. Has anyone encountered this issue before? Is there a smart solution to modify setuptools' behavior, or some other trick? Regards Martin

3 5

python setuptools_scm and rpm versioning
by Martin Wilck 09 Jul '21

09 Jul '21

The "duplicity" package uses python's setuptools_scm module to substitute the package version in its own sources. For development versions that aren't tagged, setuptools_scm uses the format "$NEXT_VERSION.dev$N", where NEXT_VERSION is the guessed subsequent/future version, and $N is the commit distance from the last released version. This scheme doesn't work with rpm. AFAIK, for rpm we must use $NEXT_VERSION~$N instead to achieve the desired ordering: $CURRENT_VERSION < $NEXT_VERSION~$N < $NEXT_VERSION~$((N+1)) < $NEXT_VERSION Unfortunately the ".dev" format is hard-coded in setuptools. Has anyone encountered this issue before? Is there a smart solution to modify setuptools' behavior, or some other trick? Regards Martin

1 0

A python packaging single spec issue when upgrading a package
by Lee Duncan 05 Jul '21

05 Jul '21

Hi All: I have a question about python single-spec packaging. [tl;dr: systemd targetcli service goes from enabled to disabled during upgrade.] [BACKGROUND] ------------ Quite a while ago I had to upgrade the "targetcli-fb" package in SLES and openSUSE. At that time, "single spec" was being heavily pushed, even though I would just as soon written a single package and SPEC file for python3. I spent quite a bit of time on the change. It turns out you have to have duplicate ("alternative") copies of everything in your python3-vs-python2 packages, so that they can co-exist, using single-spec. When I complained that I didn't need two version of things like man pages and systemd service files, I was told I should break my package into a "common" part (not python version dependent) and a python-version-dependent part. So with a bit of work I did that. So now targetcli-fb became two new packages: python3-targetcli-fb (assuming python3) and targetcli-fb-common. The "python3-targetcli-fb" package has a "requires" on "targetcli-fb-common", as well as "provides" of "targetcli" and "targetcli-fb". So when a user upgrades from openSUSE 12 to openSUSE 15, the software knows to replace "targetcli" or "targetcli-fb" with the newer "python3-targetcli-fb" and it's subpackage "targetcli-fb-common". [THE PROBLEM] ------------- The problem occurs when the user had the "targetcli.service" systemd service enabled in openSUSE 12 and they upgrade to 15. Ownership of the service file changes from "targetcli-fb" to "python-common-fb", and the install software (using zypper, I assume) fails to understand that the service that was under "targetcli-fb" didn't go away, it just changed ownership to "targetcli-fb-common", and should continue to be enabled. Is there any way to fix this? If not in this case, what should I do in the future to avoid this trap? Thank you for any wisdom you can share! -- Lee Duncan

2 1