September 2022 - openSUSE Packaging - openSUSE Mailing Lists

Base:System: Too many open files: coreutils %check failing
by Bernhard Voelker 28 Oct '22

28 Oct '22

Hi *, since a couple days, Base:System/coreutils fails during 'make check'. [ 239s] FAIL: tests/split/r-chunk [ 239s] ========================= [ 239s] [ 239s] ./tests/split/r-chunk.sh: pipe error: Too many open files [ 239s] stat: cannot statx 'x*': No such file or directory [ 239s] FAIL tests/split/r-chunk.sh (exit status: 1) The test looks quite innocent: # Ensure we fall back to appending to a file at a time # if we hit the limit for the number of open files. rm x* (ulimit -n 20 && yes | head -n90 | split -n r/30 ) || fail=1 It's not split(1) which is failing, but the calling shell process is unable to create the pipe for yes|head|split. I added some more test statement (https://build.opensuse.org/build/home:berny:branches:Base:System/openSUSE_T…) (ulimit -n 20 && yes | ls -l /proc/self/fd ) || fail=1 and we can see that the calling shell now has a lot of file descriptors open: [ 249s] + ulimit -n 20 [ 249s] + yes [ 249s] + ls -l /proc/self/fd [ 249s] total 0 [ 249s] lr-x------ 1 abuild abuild 64 Sep 26 06:45 0 -> pipe:[63339] [ 249s] l-wx------ 1 abuild abuild 64 Sep 26 06:45 1 -> /home/abuild/rpmbuild/BUILD/coreutils-9.1/tests/split/r-chunk.log [ 249s] l-wx------ 1 abuild abuild 64 Sep 26 06:45 10 -> /tmp/GmIHNZVW [ 249s] l-wx------ 1 abuild abuild 64 Sep 26 06:45 11 -> /tmp/GmIHNZVW [ 249s] l-wx------ 1 abuild abuild 64 Sep 26 06:45 12 -> /tmp/GmIHNZVW [ 249s] l-wx------ 1 abuild abuild 64 Sep 26 06:45 13 -> /tmp/GmIHNZVW [ 249s] l-wx------ 1 abuild abuild 64 Sep 26 06:45 14 -> /tmp/GmIHNZVW [ 249s] l-wx------ 1 abuild abuild 64 Sep 26 06:45 15 -> /tmp/GmIHNZVW [ 249s] l-wx------ 1 abuild abuild 64 Sep 26 06:45 16 -> /tmp/GmIHNZVW [ 249s] l-wx------ 1 abuild abuild 64 Sep 26 06:45 17 -> /tmp/GmIHNZVW [ 249s] lr-x------ 1 abuild abuild 64 Sep 26 06:45 18 -> /proc/4390/fd [ 249s] l-wx------ 1 abuild abuild 64 Sep 26 06:45 2 -> /home/abuild/rpmbuild/BUILD/coreutils-9.1/tests/split/r-chunk.log [ 249s] l-wx------ 1 abuild abuild 64 Sep 26 06:45 20 -> /tmp/GmIHNZVW [ 249s] l-wx------ 1 abuild abuild 64 Sep 26 06:45 21 -> /tmp/GmIHNZVW [ 249s] l-wx------ 1 abuild abuild 64 Sep 26 06:45 3 -> /tmp/GmIHNZVW [ 249s] l-wx------ 1 abuild abuild 64 Sep 26 06:45 4 -> /tmp/GmIHNZVW [ 249s] l-wx------ 1 abuild abuild 64 Sep 26 06:45 5 -> /tmp/GmIHNZVW [ 249s] lrwx------ 1 abuild abuild 64 Sep 26 06:45 6 -> /tmp/GmIHNZVW [ 249s] l-wx------ 1 abuild abuild 64 Sep 26 06:45 7 -> /tmp/GmIHNZVW [ 249s] l-wx------ 1 abuild abuild 64 Sep 26 06:45 8 -> /tmp/GmIHNZVW [ 249s] lrwx------ 1 abuild abuild 64 Sep 26 06:45 9 -> /tmp/Gm5FnqeH (deleted) Was there a recent change in the kernel/glibc/bash which would show such fd leaking? P.S. I see that also the 'dtc' package fails with the same EMFILE error during compilation: https://build.opensuse.org/package/live_build_log/Base:System/dtc/openSUSE_… [ 4723s] cc -I libfdt -I . -DFDT_ASSUME_MASK=0 -DNO_VALGRIND -g -Os -fPIC -Werror -Wall -Wpointer-arith \ -Wcast-qual -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wredundant-decls -Wshadow -O2 -Wall \ -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables \ -fstack-clash-protection -Werror=return-type -flto=auto -g -pie -o dtc.o -c dtc.c [ 4723s] util.c:20:10: fatal error: libfdt/unistd.h: Too many open files Thanks & have a nice day, Berny

5 8

git pseudo tags in spec files?
by Ludwig Nussel 29 Sep '22

29 Sep '22

Hi, Some spec files contain commented pseudo tags like e.g #Git-Web: http://git.kernel.org/?p=utils/kernel/kmod/kmod.git;a=summary #Git-Clone: git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod The format is too widespread to be coincidence. Is this convention documented somewhere or just packagers adopting it randomly? Usually such a URL leads to the main upstream development branch. However for the context of the spec file it might be interesting to also specify the exact tag or commit the package is about. With that information one could simplify importing patches to git before rebase to a new version. So in case of kmod the spec file could have: #Git-Tag: v30 cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Ivo Totev HRB 36809 (AG Nürnberg)

3 2

Disable FORTIFY_SOURCE=3 and switch back to ...=2?
by Johannes Kastl 27 Sep '22

27 Sep '22

Hi all, I failed to find instructions on how to revert the change to FORTIFY_SOURCE=3 for a single package. I thought there was a thread on the factory list, but fail to find it again. I did not find anything regarding FORTIFY_SOURCE=3 in the wiki, the only page I found was this: https://en.opensuse.org/openSUSE:Build_system_recipes > The %configure macro will set CFLAGS, CXXFLAGS, FFLAGS to %optflags if they have not been previously set. To add in your own flags, put on a line before %configure: > > export CPPFLAGS="-Dpreprocessor_options -Ihere" But apparently setting the CPPFLAGS like this overrides all of the previously set flags, and does not only add something (as Dominique pointed out in SR#1005907). Maybe someone can enlighten me on how to properly revert FORTIFY_SOURCE=3? :-) Thanks in advance! Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl(a)b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

5 9

Updating python-jsonschema: fixture 'issue' not found
by Johannes Kastl 25 Sep '22

25 Sep '22

Hi all, ansible-lint requires a very recent version of python-jsonschema. Unfortunately, I get an error when building 4.10.0 or later: > [ 60s] file /home/abuild/rpmbuild/BUILD/jsonschema-4.10.0/jsonschema/tests/_helpers.py, line 21 > [ 60s] def test_suite_bug(issue): > [ 60s] E fixture 'issue' not found > [ 60s] > available fixtures: cache, capfd, capfdbinary, caplog, capsys, capsysbinary, doctest_namespace, monkeypatch, pytestconfig, record_property, record_testsuite_property, record_xml_attribute, recwarn, tmp_path, tmp_path_factory, tmpdir, tmpdir_factory > [ 60s] > use 'pytest --fixtures [testpath]' for help on them. > https://build.opensuse.org/project/monitor/home:ojkastl_buildservice:Branch… Unfortunately "issue" is a bad keyword for an internet search, as it comes up with lots of GitHub issues for pytest... :-) This issue looks familiar, unfortunately bug reporter and upstream seem to have some history and thus there is no solution: > https://github.com/python-jsonschema/jsonschema/issues/980 Does anyone have a hint for me? Am I missing a BuildRequires or just a newer version of pytest? I am not familiar enough with the internals of python testing to judge if there is another way to do that. Any help is highly appreciated. Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl(a)b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

2 3

tftpboot-installation package in Leap 15.4
by Stephan Schott 07 Sep '22

07 Sep '22

Dear OpenSuse devs, I was pointed to this address from the Uyuni Github. For some reason the package for tftpboot-installation in Leap 15.4 seems to be disabled under https://build.opensuse.org/package/show/openSUSE:Leap:15.4/installation-ima… . Is there any reason for that, or could it be built again? I made a branch and built it myself for now, but it would make sense to have it in the official repo. Best regards, Stephan Schott V. Bioquímico / Licenciado en Bioquímica

3 6