openSUSE Packaging September 2021

packaging@lists.opensuse.org

33 participants
17 discussions

OBS: file system performance problem? tests timing out

by Bernhard Voelker

Hi *, in a couple of coreutils-testsuite builds, I see the tests timing out always in the same test (the one _after_ 'tests/misc/invalid-opt.pl' ... which is 'tests/rm/ext3-perf.sh' [1]. [ 575s] make check-TESTS check-local [ 575s] make[5]: Entering directory '/home/abuild/rpmbuild/BUILD/coreutils-9.0' [ 575s] make[6]: Entering directory '/home/abuild/rpmbuild/BUILD/coreutils-9.0' [ 580s] PASS: tests/misc/help-version.sh [ 581s] PASS: tests/misc/help-version-getopt.sh [ 582s] PASS: tests/tail-2/inotify-race.sh [ 583s] PASS: tests/tail-2/inotify-race2.sh [ 585s] PASS: tests/misc/invalid-opt.pl [ 5994s] qemu-kvm: terminating on signal 15 from pid 26826 (fuser) Job seems to be stuck here, killed. (after 5400 seconds of inactivity) I've seen this on 'i586' and 'x86_64' with both the older v8.32 in B:S/coreutils and the brand-new v9.0 in my home project [3]. Unfortunately, the qemu-vm is directly killed, so I think I can't even see the log output of that test. Maybe it is already killed during the test setup where a lot of files are created, or it's the program under test - 'rm' - that suffers from a regression. Of course, I could simply exempt that particular test case on OBS, but this smells like a problem outside of coreutils which may be worth fixing ... yes, that test has run for a long time without problems and just recently started to fail. New glibc version maybe? Any hints / comments / ideas? [1] https://git.sv.gnu.org/cgit/coreutils.git/tree/tests/rm/ext3-perf.sh?h=v9.0… [2] https://build.opensuse.org/package/live_build_log/Base:System/coreutils:tes… [3] https://build.opensuse.org/package/live_build_log/home:berny:branches:Base:… Thanks & have a nice day, Berny

7 months, 2 weeks

sudden build fails on TW

by Mathias Homann

Hi, I'm getting sudden build fails on tumbleweed, can someone see why? I can't - the files where the build dies haven't changed in ages... and the build only dies on TW, Leap 15.2 and 15.3 are building fine. package is on obs, home:lemmy04:snowglobe/phoenix-firestorm-lgpl I'd be thankful for any help... cheers MH -- Mathias Homann Mathias.Homann(a)openSUSE.org 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

7 months, 3 weeks

Packaging java apps

by Luigi Baldoni

Hi, I'm new to packaging java applications and I've stumbled upon a small problem: first, how do I request openjdk >= 16 without naming it explicitly? And more importantly, how do I detect and invoke the correct jvm in the launch script at runtime? Perhaps there's an obvious answer, but I couldn't find it. Thanks in advance. Hi, I'm new to packaging java applications and I've stumbled upon a small problem. First, how do I request openjdk >= 16 without naming it explicitly? And more importantly, how do I invoke the correct jvm in the launch script at runtime? Perhaps there's an obvious answer, but I couldn't find it. Thanks in advance.

7 months, 3 weeks

Re: The alternative for "update-alternatives" ---> libalternatives

by Andrei Borzenkov

On 24.09.2021 16:28, Michal Suchánek wrote: >> The negative is mostly that extra exec() overhead (and if you ever find >> it's significantly more in some scenario, it's a bug :). Another issue >> is it's not immediately clear *what* you are running since execution >> depends no the argv[0] and config file and not target binary of a >> symlink. This is an issue with things like AppArmor. > > How is it a problem with apparmor? > > If it limits exec() it will just happen one step later when > libalternative does it. > > Or am I missing something? > Apparmor needs to allow every possible alternative binary instead of just one canonical path.

7 months, 3 weeks

Re: The alternative for "update-alternatives" ---> libalternatives

by Manfred Schwarb

Am 21.09.21 um 09:47 schrieb Danilo Spinella: > libalternatives is imho a big improvement over update-alternatives. But the question remains: what about performance? If I have a small program that is called in a loop, is performance severely hampered? I.e. how does the following a=`cat <<EOF for ((i=0; i<10000; ++i)); do awk 'BEGIN { print "hallo" }' done EOF` #> time -c "$a" >/dev/null perform with libalternatives in contrast to /usr/bin/gawk? > > Is there any plan to upstream its support? I think the Open Source > ecosystem would greatly benefit from doing so and we wouldn't have to > maintain libalternatives support for the packages. Plus, I am a big fan > of upstreaming and letting the spec file just run > make && make install. > > Let me know if you need any help regarding this. > > Regards, > Danilo > > On Mon, 2021-09-20 at 09:19 +0200, Stefan Schubert wrote: >> Hi, >> >> most of you are already familiar with the usage of update- >> alternatives. >> Update-alternatives, at its core, is a symlink management system. >> This >> system is then mostly used as means for administrators of a system to >> select a default application. >> For example, if we have vim or emacs installed, the admin can then >> make >> one accessible as an editor application. >> Update-alternatives manages these tasks by symbolic file links which >> has >> worked out, that it could become quite instable in older updated >> systems. >> Adam Majer has established a new concept how to handle the >> update-alternatives tasks: libalternatives >> Libalternatives does not use file links anymore but little >> configuration >> files which is much more stable and quite easy to handle by the >> administrator. >> Have a look to https://github.com/openSUSE/libalternatives for more >> information. >> One additional benefit of libalternatives is that it does not create >> entries in the /etc directory anymore. In the future the /etc >> directory >> will be used for entries/changes ONLY which >> have been done by the administrator and do not belong to packages or >> have been created by package installation. >> >> I have already switched about 40 packages to the new libalternatives >> which we need around MicroOS and have submitted it to factory. >> >> This list includes a lot of python packages. Python packages are >> using >> nice RPM macros for handling update-alternatives stuff. >> Currently the fixes are made manually in the spec files and it will >> not >> be done by macros anymore. >> I have done this step at first in order to get a feeling what is >> needed >> for using/updating these macros at first. >> Now I will patch the alternatives macros or will write new one in >> order >> to simplify it again. >> And yes, I will update the regarding python packages again. So >> please, >> do not panic :-) >> >> Please inform us if you have any comments, suggestions or even >> doubts. >> >> Greetings >> Stefan >> >> -- >> ********************************************************************* >> ********** >> Stefan Schubert >> e-mail: schubi(a)suse.de >> --------------------------------------------------------------------- >> ---------- >> SUSE Software Solutions Germany GmbH >> Maxfeldstr. 5 >> 90409 Nürnberg >> Germany >> >> (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer >

7 months, 3 weeks

[neard] neard release v0.17

by Krzysztof Kozlowski

Hi all, v0.17 ===== After quiet period, the neard user-space counterpart of Linux kernel NFC stack, gets a new release - v0.17. The release includes several fixes (including potential security fixes) and improvements, plus few new features. Source code release: https://git.kernel.org/pub/scm/network/nfc/neard.git/tag/?h=v0.17 https://git.kernel.org/pub/scm/network/nfc/neard.git/snapshot/neard-0.17.ta… Few notes on new names and maintainers ====================================== The neard package was previously maintained Samuel Ortiz and Marcel Holtmann, which were also main contributors. Last years Mark Greer was looking after neard. I joined in 2021, both as a maintainer of Linux kernel NFC stack and the neard. The project development still happens via linux-nfc mailing list but also got a second home on GitHub: https://github.com/linux-nfc/neard Under GitHub I set up also Continuous Integration: https://github.com/linux-nfc/neard/actions Feel free join and hack via both channels. Best regards, Krzysztof

7 months, 4 weeks

[neard] neard release v0.17

by Krzysztof Kozlowski

7 months, 4 weeks

Re: The alternative for "update-alternatives" ---> libalternatives

by Danilo Spinella

On Tue, 2021-09-21 at 10:06 +0200, Jan Engelhardt wrote: > > On Tuesday 2021-09-21 09:47, Danilo Spinella wrote: > > > libalternatives is imho a big improvement over update-alternatives. > > > > Is there any plan to upstream its support? > > Upstream to where? > Most if not all uses of update-alternatives exist because a *distro* > chose to provide two or more implementations with the same name. > > /etc/alternatives/ctags exists because openSUSE wanted to ship > both ctags and emacs-ctags. The emacs project in itself would not, > and probably does not, care about the non-emacs-ctags variant in > any way, in the scope of the upstream project. > For example it could be upstreamed for iptables and ebtables; same for util-linux, binutils, llvm. But yea, it does not apply to all projects. I still think it could be worth a try for most ones.

7 months, 4 weeks

The alternative for "update-alternatives" ---> libalternatives

by Stefan Schubert

Hi, most of you are already familiar with the usage of update-alternatives. Update-alternatives, at its core, is a symlink management system. This system is then mostly used as means for administrators of a system to select a default application. For example, if we have vim or emacs installed, the admin can then make one accessible as an editor application. Update-alternatives manages these tasks by symbolic file links which has worked out, that it could become quite instable in older updated systems. Adam Majer has established a new concept how to handle the update-alternatives tasks: libalternatives Libalternatives does not use file links anymore but little configuration files which is much more stable and quite easy to handle by the administrator. Have a look to https://github.com/openSUSE/libalternatives for more information. One additional benefit of libalternatives is that it does not create entries in the /etc directory anymore. In the future the /etc directory will be used for entries/changes ONLY which have been done by the administrator and do not belong to packages or have been created by package installation. I have already switched about 40 packages to the new libalternatives which we need around MicroOS and have submitted it to factory. This list includes a lot of python packages. Python packages are using nice RPM macros for handling update-alternatives stuff. Currently the fixes are made manually in the spec files and it will not be done by macros anymore. I have done this step at first in order to get a feeling what is needed for using/updating these macros at first. Now I will patch the alternatives macros or will write new one in order to simplify it again. And yes, I will update the regarding python packages again. So please, do not panic :-) Please inform us if you have any comments, suggestions or even doubts. Greetings Stefan -- ******************************************************************************* Stefan Schubert e-mail: schubi(a)suse.de ------------------------------------------------------------------------------- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer

7 months, 4 weeks

Need help with how to add package to OpenSUSE repos

by Giovani Candido

Hi! I created a cli tool with python. I built an rpm and signed it with gpg2. It's available in my GitHub. How can I add it to one of the OpenSUSE repos? I'm currently thinking of adding it to my home project using OBS. But, it'd be nice to add to a official repo. Thanks in advance.

8 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging September 2021