openSUSE Packaging April 2022

packaging@lists.opensuse.org

14 participants
6 discussions

Packaging ansible-core aka ansible > 2.9: How to package, where to submit to, ...
by Johannes Kastl 27 Jun '22

27 Jun '22

TL;DR: - Package ansible-core in addition to ansible 2.9? - Where to submit to? systemsmanagement or a subproject for "all things ansible"? - Who can help getting the %checks working? Long version: Dear Lars, dear all, I have a lot of ansible related things at work at the moment, so I took a look at the openSUSE ansible package and was wondering why it was still at 2.9. While upstream is at 2.12. Or rather, the newly designed and re-structure ansible-core is at 2.12. Which I did not find for openSUSE. Which is needed for newer versions of ansible-lint (hence it fails to build at the moment). So, I tried to package it and got it building: > https://build.opensuse.org/project/show/home:ojkastl_buildservice:Branch_sy… (ansible-lint-5.4 built fine yesterday, apparently some pytest update broke the checks...) Caveats: - I only targeted Tumbleweed and ignored everything else, to just get it building - I had to disable most of the %check sections as the tests were failing out of the box and I had no time and no desire to dig into that - I kept the ansible-core spec file as short as possible, i.e. I ignored all the RHEL/Fedora/... related things that are present in the I tested the packages on a Tumbleweed VM and could successfully install ansible-base (the 2.10 version) or ansible-core. I added Conflicts to the spec so you can only install one of ansible, ansible-core or ansible-base, while all three of them "Provide" ansible. I could also install the 6.0.x version of ansible-lint and linted a small role (with the desired effect, finding things that the 5.4 version did not find/complain about). So, how should I proceed? 1. I am not sure if packaging only ansible-core (aka updating the ansible package to contain ansible-core) would create problems for users that are not aware of the changes (many modules were removed and are now available as collections via the Ansible Galaxy). Should we package ansible-core separately in addition to ansible 2.9? 2. Where to submit the packages to? Would it make sense to move all things related to ansible to a subproject of systemsmanagement? I guess the python-* dependencies could go to dlp* somewhere (not sure what the current layout is for python things, lost track ...) and could be maintained there. 3. Who could take a look at the packages and help in getting them nice and shiny? Especially the %check sections need a lot of love from someone more knowledgeable than me :-) 4. Not sure if it is worth the effort to try to package this for older distributions, e,g, Leap 15.3 / 15.4 or other distros like CentOS. The systemsmanagement project has a lot of build targets. :-) I can try to drive this and help as much as I can, but I would be glad for help and feedback (packaging guidelines that I missed, etc.). 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

3 9

Use FOSS (blob-free) driver for rtl8188eu wireless network adapter
by Suse User 26 Apr '22

26 Apr '22

Hello, I have been advised that Bugzilla is not the right place for suggesting a new driver to be used and that the packaging mailing list is a more proper place for this. So, I subscribe to this list and I share with you my findings and suggestion for replacing the current rtl8188eu driver which requires a proprietary blob for firmware with a FOSS one. Here are the details: https://bugzilla.suse.com/show_bug.cgi?id=1198655

4 12

hylafax - libfaxutil not removed
by Axel Braun 26 Apr '22

26 Apr '22

Hi, quick question to the packaging experts: The package hylafax+ [1] installs libfaxutil%{lib_version}. I just noticed, on an update, it does not remove the old libfaxutil. %post -n libfaxutil%{lib_version} -p /sbin/ldconfig %postun -n libfaxutil%{lib_version} -p /sbin/ldconfig does obviously not do the job. Does anyone know what the correct call is? Thanks Axel [1] https://build.opensuse.org/package/show/network:telephony/hylafax+

2 1

Re: Use FOSS (blob-free) driver for rtl8188eu wireless network adapter
by Suse User 23 Apr '22

23 Apr '22

On Thu, 21 Apr 2022 11:02:10 -0500 Larry Finger wrote: > I added am update to that bug describing that the firmware in your > driver is most likely embedded in the source code, and that you were > actually using proprietary code. Thank you for doing that. I will reply here to your Bugzilla comment to avoid using Bugzilla for discussions. > In the driver that comes from Realtek, either directly or indirectly, > the firmware is stored in the code as a big table., thus your test > was likely using such a driver, and you were in fact using a binary > blob that is published under a GPL v2 license, but it is not > available as source code for the imbedded CPU in the NIC. I understand what you mean. However, this contradicts the essence of software being free. On one hand we have the FOSS license which grants the 4 freedoms. OTOH you say it is not even open source. So we have the freedom to study, modify, and redistribute code. This means we also have the freedom to reverse engineer it as it is a form of studying and modification, and we are allowed to redistribute the modified (unobfuscated) version. > To get that firmware file, I merely copied that huge table into a > separate program that wrote the contents into a binary file. The > WHENCE file in the linux-firmware repo is as follows: > Driver: rtl8188eu - Realtek 802.11n WLAN driver for RTL8188EU > > Info: Taken from Realtek version > RTL8188EUS_linux_v4.1.4_6773.20130222 File: rtlwifi/rtl8188eufw.bin From your explanation I understand that you are using version 4.1.4 from 2013. Is that correct and (regardless of the outcome of this discussion) is it possible to upgrade to the newer one which I found? Disclaimer: I don't know who manages the Github repo I used but during my research I could not find any source code directly from Realtek. All sources seem to refer to the one I used. > Licence: Redistributable. See LICENCE.rtlwifi_firmware.txt > for details. > > The most pertinent part of the LICENCE file noted above is > * No reverse engineering, decompilation, or disassembly of > this software is permitted. I performed recursive grep for each of those keywords and there is no such text in the source code I used. > Yes, the driver files are FOSS, but information about the firmware is > never really open source, nor would disassembly be legal. As it seems, not for the source code I found. I understand that theoretically it is possible someone (including the Github repo's owner) to have removed/modified the license headers but since we have no proof of that (or of the opposite) it is legally correct to exercise the 4 freedoms which a license of a program found on Github grants. FWIW I also see your name in the comments. I suppose you are far more involved in that and an expert in that matter. Regarding the table you mention, I see a long series of hex codes in: rtl8188eus/hal/rtl8188e/hal8188e_s_fw.c rtl8188eus/hal/rtl8188e/hal8188e_t_fw.c rtl8188eus/rtw_security.c I don't know what role those tables play and it seems you are right that it is a form of blob. Without license restrictions though, anyone should be free to reverse engineer it (as long as one knows how). I would very much like to know what you think. Personally I would hate to know there might be a "FOSS" backdoor or malware in the wireless adapter I use.

1 1

Stripping a rust binary?
by Johannes Kastl 21 Apr '22

21 Apr '22

Hi all, I found hurl.dev recently and decided to try and package it. > https://build.opensuse.org/package/show/home:ojkastl_buildservice/hurl I could get it to build, even though I had to disable the checks (for now). However, rpmlint complains that the binary is not stripped. > [ 217s] hurl.x86_64: W: unstripped-binary-or-object /usr/bin/hurl > [ 217s] This executable should be stripped from debugging symbols, in order to take > [ 217s] less space and be loaded faster. This is usually done automatically at > [ 217s] buildtime by rpm. As I have no clue from rust, and the Rust packaging documentation does not mention stripping, how would I do that properly for a SUSE/openSUSE package? 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

3 4

Different source package versions building library with identical soname
by Aaron Puchert 10 Apr '22

10 Apr '22

Hi, I want to submit a package into Factory that provides a library with an soname identical to that provided by another package, but this seems to conflict with the convention to name such packages lib%{name}%{sonum}, since obviously the packages can't share the same name. [1] The background: Clang has both a stable API (the "C API" in libclang.so) and an instable API (the "C++ API" in libclang-cpp.so). Now upstream noticed that this should perhaps be reflected by not increasing the so number of libclang.so [2], so that with LLVM 14 we now have libclang-cpp.so -> libclang-cpp.so.14 libclang-cpp.so.14 libclang.so -> libclang.so.13 libclang.so.13 -> libclang.so.14.0.0 libclang.so.14.0.0 Of course libclang-cpp.so.* libraries need to be able to coexist, whereas libclang.so cannot coexist with the previous version that provides libclang.so.13 -> libclang.so.13.0.1 So I have to split up the libraries. But then both package versions provide libclang.so.13()(64bit) libclang.so.13(LLVM_13)(64bit) Indeed only the newer version should ever be needed, so should I stop building the older version or, more realistically, don't package it? (There are binaries in clang13 that use it, so I can't stop building or shipping it that easily. These binaries should of course also work with libclang.so.13 provided by LLVM 14.) Easier would be to keep shipping the old package, but have the new version obsolete it. Is that enough? Additionally, how should I name that package? Of course I can't also call it libclang13 unless I modify the LLVM 13 packaging to remove the library there, so should it be libclang14 or libclang13-14? The former would be the easiest, but rpmlint doesn't like it: libclang14.x86_64: E: shlib-policy-name-error SONAME: libclang.so.13, expected package suffix: 13 Best regards, Aaron [1] https://en.opensuse.org/openSUSE:Shared_library_packaging_policy [2] https://reviews.llvm.org/D105527

3 8

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging April 2022