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
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
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.
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.
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
>
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.17https://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
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.17https://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
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.
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
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.