August 2022 - openSUSE Packaging - openSUSE Mailing Lists

Leap 15.4 security:tls repo
by Torsten Olschewski 19 Aug '22

19 Aug '22

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

2 2

%pyproject_wheel with test dependencies
by Axel Braun 16 Aug '22

16 Aug '22

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

2 1

libheif - how to handle conflicting files already on system
by David C. Rankin 12 Aug '22

12 Aug '22

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.

3 6

Handling transition from python3-docker-compose v1 to docker-compose v2
by Johannes Kastl 01 Aug '22

01 Aug '22

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 16

Enable Leap 15.4 build for server:http
by Fusion Future 01 Aug '22

01 Aug '22

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 1