openSUSE Packaging

packaging@lists.opensuse.org

13 participants
4084 discussions

by Ludwig Nussel

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)

1 day

Disable FORTIFY_SOURCE=3 and switch back to ...=2?

by Johannes Kastl

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

2 days, 23 hours

Base:System: Too many open files: coreutils %check failing

by Bernhard Voelker

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

3 days, 8 hours

Updating python-jsonschema: fixture 'issue' not found

by Johannes Kastl

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

4 days, 21 hours

tftpboot-installation package in Leap 15.4

by Stephan Schott

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 weeks, 1 day

Leap 15.4 security:tls repo

by Torsten Olschewski

Hi there, openSUSE Leap 15.4 is out but unfortunately there is no 15.4 repo under http://download.opensuse.org/repositories/security:/tls/. Are there plans to activate it in the near future? I use the 15.3 repo and would like to migrate my systems to 15.4. Thanks in advance Torsten

1 month, 1 week

%pyproject_wheel with test dependencies

by Axel Braun

Hi, I wanted to update python-pydyf to current version. The project has switched from setup.py to pyproject.toml. I run into an error while testing: pytest-3.8: error: unrecognized arguments: --flake8 --numprocesses=auto as probably some dependencies are not installed Is there a way to automate this. like in pip install pydyf[test] ? Thanks Axel

1 month, 2 weeks

libheif - how to handle conflicting files already on system

by David C. Rankin

All, I've package libheif for the hiec-convert feature, but there are various packages previously pulled in by darktable, gimp-plugin-heic and imagemagick heic files that conflict with the new libraries that are built with my libheif package. I need a way to tell zypper to uninstall the current conflicting packages and use the file from my package in their place. I know I can tell rpm with Provides: that my package provides that capability, but what else do I need to do so that the installed packages are removed and mine installed? The conflicts are: File /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-heif.so from install of libheif-1.12.0-dcr154.1.1.x86_64 (Plain RPM files cache) conflicts with file from package gdk-pixbuf-loader-libheif-1.12.0-150400.1.10.x86_64 (@System) File /usr/lib64/libheif.so from install of libheif-1.12.0-dcr154.1.1.x86_64 (Plain RPM files cache) conflicts with file from package libheif-devel-1.12.0-150400.1.10.x86_64 (@System) File /usr/lib64/libheif.so.1 from install of libheif-1.12.0-dcr154.1.1.x86_64 (Plain RPM files cache) conflicts with file from package libheif1-1.12.0-150400.1.10.x86_64 (@System) File /usr/lib64/pkgconfig/libheif.pc from install of libheif-1.12.0-dcr154.1.1.x86_64 (Plain RPM files cache) conflicts with file from package libheif-devel-1.12.0-150400.1.10.x86_64 (@System) On install of libheif-1.12.0-dcr154.1.1.x86_64, I need the following packages removed: gdk-pixbuf-loader-libheif libheif-devel libheif1 What is the best way to handle this? While TW provides a working libheif (with heic-convert for Apple .heic files), 15.4 doesn't, so that was the imputes for building this package. (works quite well to, though .spec will need a bit of experienced cleanup) -- David C. Rankin, J.D.,P.E.

1 month, 2 weeks

Handling transition from python3-docker-compose v1 to docker-compose v2

by Johannes Kastl

TL;DR: Which package should get Obsoletes and Requires? Hi all, I have packaged the latest updates for the python-based python-docker-compose as well as the newer v2 that is written in golang. https://build.opensuse.org/request/show/986041 https://build.opensuse.org/request/show/986039 I also prepared the docker-compose-switch package that upstream created to ease the transition from v1 to v2, as the latter is only a cli-plugin for docker and does not longer have a docker-compose binary. https://github.com/docker/compose-switch > Compose Switch is a replacement to the Compose V1 docker-compose (python) executable. It translates the command line into Compose V2 docker compose then run the latter. The python package already used update-alternatives to manage packages built for different python versions being installed simultaneously. I am not sure if anybody is still relying on features from v1, I do not think so. So I would put a "Obsoletes: ... <2.0.0" into one of the new golang-based packages. This would hopefully lead to the deinstallation of the python-based v1 package. The question is, which package should get this "Obsoletes"? I think it should go into the docker-compose-switch one, which has a Requires for docker-compose v2. This way I can only install docker-compose v2 and use "docker compose ..." (space instead of hyphen!), i.e. if I do not need the compatibility docker-compose binary. If I rely on a binary called docker-compose, I can install the docker-compose-switch package. Or I would get it automatically together with the v2 golang package, if I have the python-based one installed. Would that work? Any flaws that I missed? Better ideas? Thanks for your input. 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 months

Enable Leap 15.4 build for server:http

by Fusion Future

Hi dear maintainers: openSUSE Leap 15.4 has been released, but server:http still doesn't have builds for 15.4. Could you enable it? Thanks in advance.

2 months

Jump to page:

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging