openSUSE Packaging

packaging@lists.opensuse.org

19 participants
3989 discussions

by Jason Craig

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

1 week

Utility to get outdated packages

by Danilo Spinella

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

1 week, 4 days

Bot enhancement: factory-maintainers set as maintainer on devel projects

by Dominique Leuenberger / DimStar

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

1 week, 5 days

CentOS_8_Stream: unresolvable: nothing provides cargo

by Wong Hoi Sing Edison

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

1 week, 5 days

Did the list just release all backlogged spam or something?

by Jason Craig

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

1 week, 5 days

python setuptools_scm and rpm versioning

by Martin Wilck

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

2 weeks, 2 days

python setuptools_scm and rpm versioning

by Martin Wilck

2 weeks, 5 days

A python packaging single spec issue when upgrading a package

by Lee Duncan

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

3 weeks, 2 days

Building appimages on OBS

by Mathias Homann

Hi, I'm trying to build an appimage on OBS, but all I get is a (huge) binary that segfaults when I try to run it. Here's my package: https://build.opensuse.org/package/show/ home:lemmy04:branches:OBS:AppImage:Templates:Leap:15.2/XEphemAppImage and by the way, even the unmodified appimage template produces something that simply segfaults... see https://build.opensuse.org/package/show/OBS:AppImage:Templates/ AppImageTemplate Any ideas? Cheers MH -- Mathias Homann Mathias.Homann(a)openSUSE.org OBS: lemmy04 Jabber (XMPP): lemmy(a)tuxonline.tech IRC: [Lemmy] on freenode and ircnet (bouncer active) telegram: https://telegram.me/lemmy98 keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102

3 weeks, 2 days

Packaging weirdness for TW

by Mathias Homann

Hi guys, I have a package on OBS that shows extremely weird behaviour when I build for TW... I have %debug_package in the spec file, and that makes the build fail on TW, with *lots* of unpackaged files that are all those files that would normally go into the debug package. The package builds just fine on Leap, and used to build just fine on TW, and still does when I comment out %debug_package (d'oh). Now here's the weird thing: when I comment out %debug_package, wait for that build to finish, and then activate it again, the package builds fine on TW once! Then the next revision of the package starts the failing thing again, until I build it without %debug_package once. WHAT could that be, and how to fix it? Package in question is here:- https://build.opensuse.org/package/show/home:lemmy04:snowglobe/phoenix-fire… Cheers MH -- Mathias Homann Mathias.Homann(a)openSUSE.org OBS: lemmy04 Jabber (XMPP): lemmy(a)tuxonline.tech IRC: [Lemmy] on freenode and ircnet (bouncer active) telegram: https://telegram.me/lemmy98 keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102

3 weeks, 2 days

Jump to page:

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging