openSUSE Packaging May 2021

packaging@lists.opensuse.org

22 participants
9 discussions

by Konstantin Voinov

Hi, It's a rarely case, but I need the link /usr/lib/libboost_filesystem.so -> /usr/lib/libboost_filesystem.so.1.76.0 for building 32bit-64bit version of yabridge https://github.com/robbert-vdh/yabridge keep an own branch of boost scares me a bit maybe there is a some trick where I can make a stump package with that link?

2 weeks, 5 days

Link broken: python-flask-jwt-extended

by Sean Marlow

Hi, I noticed that the devel package is broken for python-flask-jwt- extended [1]. It seems like the link is invalid. Any ideas on how to get this fixed so the package starts building again in devel and also in factory? [1] https://build.opensuse.org/package/show/devel:languages:python:flask/python… Thanks, Sean

2 weeks, 5 days

Re: Moving default configuration out of /etc - handling user modifications

by Dominique Leuenberger / DimStar

On Sat, 2021-05-29 at 00:09 +0200, Martin Wilck wrote: > On Sa, 2021-05-29 at 00:02 +0200, Dominique Leuenberger / DimStar > > hi Martin, > > > > sorry for the late reply on this topic; > > > > The wiki actually has some hints about how to handle this case: > > https://en.opensuse.org/openSUSE:Packaging_UsrEtc#Moving_of_configuration_f… > > > > Hope that helps, > > Thanks! I should have found that page :-/ > > Fortunately, it's pretty close to what I'd figured out, except that I > moved away the old .rpmsave files in %post, not %pre. AFAICS %post is > sufficient - no? in %post you already don't know anymore if the .rpmsave was there prior to the update, or not. So you risk to re-enable old moved config files. Cheers, Dominique

2 weeks, 6 days

devel:languages:python:aliyun in openSUSE:Factory

by Sean Marlow

Hi, I have a package in factory python3-img-proof which got new requirements on Aliyun SDK packages. Since the requirements were added the package (img-proof) fails to update in factory due to unresolvables [1]. I submitted the Aliyun SDK core package to factory but it fails because devel:languages:python:aliyun [2] is not a devel project of factory [3]. Can someone help get d:l:p:aliyun added as a devel project so these SDK packages can be included in factory? [1] https://build.opensuse.org/request/show/892113 [2] https://build.opensuse.org/project/show/devel:languages:python:aliyun [3] https://build.opensuse.org/request/show/895205 Thanks, Sean

3 weeks, 2 days

Moving default configuration out of /etc - handling user modifications

by Martin Wilck

Hi, The suse-module-tools package ships a couple of (default) configuration files that are currently installed under /etc/modprobe.d. I want to migrate them to /lib/modprobe.d (to be further migrated to /usr/lib when the usr merge happens). These files were meant to be user-modifyable, and were labelled with %config(noreplace) for that reason. How should I deal with modified files? The files under /etc aren't owned by the new package any more, as it now owns the corresponding files under /lib only. In the upgrade process, when the old version is uninstalled, rpm will notice the %config(noreplace) files being removed, and will rename them to .rpmsave. That's bad, because user modifications won't be applied any more. The system may fail to boot or otherwise misbehave. rpm will log these renames: warning: /etc/modprobe.d/60-blacklist_fs-nilfs2.conf saved as /etc/modprobe.d/60-blacklist_fs-nilfs2.conf.rpmsave but these messages might be easily overlooked, in particular if the user works with packagekit or the like. I've considered to detect these ".conf.rpmsave" files in a %posttrans script and rename them back to ".conf". That would work AFAICS, but I'm not sure if I can exclude weird side effects; in particular, I must take care not to restore previously created .rpmsave files, and I should only do this once, when upgrading from a previous version that still owned the files under /etc (I don't know how to detect that). In general, this approach feels pretty much like a hack. Another option I've tried is to add the /etc/modprobe.d/ files to the new package as %ghost files. That "works", too, the files aren't renamed to .rpmsave any more, and no immediate damage is done. The drawback is that every conf file is preserved, even those that were unchanged by the user (the "normal" case being that the user didn't modify any of these files). Thus my newly installed files under /lib wouldn't take effect. Future changes of the default configuration would be silently masked. What would be the preferred approach? Or is there another, better solution that I am overlooking? Hints welcome, Martin

3 weeks, 2 days

extremely weird packaging issue

by Mathias Homann

Hi guys, I am having an extremely weird problem with two packages that I'm building. I have been packaging the apps in question for years now, but now I'm trying to get OBS to produce a working rpm on Tumbleweed and it just DOES NOT WORK. The build on OBS succeeds just fine, but if I install the package the application crashes on start. The packages for Leap 15.2 and 15.3 built from the same spec and sources work just fine, even to the point that right now I'm using the 15.3 package on tumbleweed. and here is the REALLY weird part: If I take the whole content of the package directory from my obs project and copy it to rpmbuild/SOURCES on a Tumbleweed machine,. and build it locally with rpmbuild, the package I get works just fine. If I build locally with "obs build" the resulting binary crashes. I have NO idea where to begin looking - all I know right now is that a backtrace in gdb wasn't really helpful either... the crash happens somewhere in libstdc++ o.0 Anyone got any ideas? the packages in question are in home:lemmy04:snowglobe/ phoenix-firestorm-lgpl and home:lemmy04:phoenix-firestorm-release ... 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

1 month

Heads up: sunsetting mkinitrd

by Daniel Molkentin

Hi, with the pending submission of Dracut 054, which removes mkinitrd from the upstream sources, it's time to finally remove mkinitrd in Factory, too: Changes starting with 054 ------------------------- - mkinitrd will temporarily live in its own dracut-mkinitrd-deprecated package. It will still be installed when requiring "mkinitrd" and requires dracut, so nothing changes here. - If you only required dracut, but meant to require mkinitrd, you need to change this temporarily or change your scripts to directly call dracut. Rationale --------- mkinitrd has always been a rather mediocre wrapper that claimed to keep compatibility with the SLES 11 implementation. However: - it has a lot of bugs, quite some documented (!) flags have never worked, others are marked unimplemented or will say so only if invoked. I see little point in doing that given - it adds little value over just using plain Dracut Differences in calling dracut over calling mkinitrd: ---------------------------------------------------- - Dracut only updates the initrd for the currently running kernel, unless either a kernel version or --regenerate-all is called - mkinitrd updates the bootloader by default. Dracut has no such option. Then again, those are two different concerns that are only merged into a single command for convenience. Usually this should be invoked from the kernel install script. - mkinitrd parses the no longer existing /etc/sysconfig/kernel file. - mkinitrd handles xen-specific modules. I have not enough understanding of the state of Xen in Factory to judge whether this is still required. If so, it should be handled in a dracut module. However, judging by the fact that the default is sourced from the defunc'ed kernel sysconfig file, this is probably also dead. - mkinitrd has slightly different semantics on how to specify a boot device for NFS & Co. Point of Contact ---------------- If you have concerns how this affects your package, please let us (me, Thomas Blume or Neil) know. For the Kernel and other packages that are definitely impacted once mkinitrd would go away (e.g. YaST), we will reach out separately and / or file bugzilla issues. -- Daniel Molkentin <daniel.molkentin(a)suse.com> Senior Software Engineeer System Boot and Init SUSE Software Solutions Germany GmbH Maxfeldstrasse 5, 90409 Nuernberg, Germany HRB 36809 (AG Nürnberg) Geschäftsführer: Felix Imendörffer

1 month

Multi-Python application desktop file rpmlint issue

by Frank Kunz

I try to package a multi-python application and I got the build working so far, but when adding a desktop file I get this rpmlint problems: [ 42s] warning: absolute symlink: /usr/bin/NanoVNASaver -> /etc/alternatives/NanoVNASaver [ 42s] warning: absolute symlink: /usr/share/applications/nanovna-saver.desktop -> /etc/alternatives/nanovna-saver.desktop [ 42s] warning: absolute symlink: /usr/share/pixmaps/nanovna-saver.png -> /etc/alternatives/nanovna-saver.png [ 43s] error: lua script failed: [string "<lua>"]:4: cannot open file '/home/abuild/rpmbuild/BUILDROOT/nanovna-saver-0.3.8-2.1.x86_64/usr/share/applications/nanovna-saver.desktop' (No such file or directory) and finally: [ 46s] RPMLINT report: [ 46s] =============== [ 47s] /tmp/rpmlint.python39-nanovna-saver-0.3.8-2.1.noarch.rpm.jgk388ja/usr/share/applications/nanovna-saver.desktop: file does not exist [ 47s] 0 packages and 0 specfiles checked; 0 errors, 3 warnings. [ 47s] Traceback (most recent call last): [ 47s] File "rpmlint.py", line 378, in <module> [ 47s] File "rpmlint.py", line 166, in main [ 47s] File "rpmlint.py", line 224, in runChecks [ 47s] File "AbstractCheck.py", line 51, in check [ 47s] File "AbstractCheck.py", line 101, in check_binary [ 47s] File "MenuXDGCheck.py", line 92, in check_file [ 47s] File "MenuXDGCheck.py", line 34, in parse_desktop_file [ 47s] File "./codecs.py", line 905, in open [ 47s] FileNotFoundError: [Errno 2] No such file or directory: '/tmp/rpmlint.python39-nanovna-saver-0.3.8-2.1.noarch.rpm.jgk388ja/usr/share/applications/nanovna-saver.desktop' The package is built here: https://build.opensuse.org/package/show/home:frank_kunz/nanovna-saver I used this package as example https://build.opensuse.org/package/show/openSUSE:Factory/python-Twisted since this has man pages handled by python_alternative and my idea was to do it the same for a desktop file. I'm not sure if python_alternative is the right way to go for desktop files, or if there is an other possibility. The python packaging wiki(https://en.opensuse.org/openSUSE:Packaging_Python) does not list that. How can I fix that problem, or, if any, what is the better way to package the desktop file? Br, Frank

1 month

branching broken package

by Adam Mizerski

X11:lxde/mtpaint is broken, because it's linked to openSUSE:Factory, but it was removed from there. It's still possible to see original files under "Show unmerged sources" link in web ui. If I try to branch it, I get an error: BuildService API error: failed to branch: openSUSE:Factory/mtpaint: package 'mtpaint' does not exist Is it possible to branch it in a way that would give me unmerged sources?

1 month, 2 weeks

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging May 2021