February 2022 - openSUSE Packaging - openSUSE Mailing Lists

Packages files from /etc to /usr/lib, how to adjust packages?
by Thorsten Kukuk 24 Feb '22

24 Feb '22

Hi, NetworkManager upstream moved many stuff from /etc/NetworkManager to /usr/lib/NetworkManager, like the dispatcher.d and VPN directories. We have many packages which still install their stuff into e.g. /etc/NetworkManager/dispatcher.d/ This is a specific example, but many other packages suffer from the same problem. So dbus upstream moved also many files from /etc/dbus-1 to /usr/share/dbus-1, and you can continue this list with other "infrastructure" packages. What would be a good way to: - inform all package maintainers that they have to move their files? - make sure new packages make it right from the beginning? I think one option would be to add new rules to rpmlint to forbid files in /etc/NetworkManager or /etc/dbus-1? Any toughts? Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Ivo Totev (HRB 36809, AG Nürnberg)

4 3

completion missing in cmctl: Can someone translate bazel to regular "go build" commands?
by Johannes Kastl 23 Feb '22

23 Feb '22

Hi all, recently I built cmctl, the CLI tool accompanying cert-manager. The tool itself works, but as Robert pointed out the completion is not active: https://cert-manager.io/docs/usage/cmctl/#completion $ cmctl completion help Error: unknown command "completion" for "cmctl" Run 'cmctl --help' for usage. unknown command "completion" for "cmctl" The help does not contain any hint of completion. The upstream package is built using bazel, while I created the RPM to build the pieces directly using "go build...". Can someone help out and "translate" the bazel configuration to something that I can use in OBS? https://github.com/cert-manager/cert-manager/blob/master/cmd/ctl/BUILD.baze… > go_binary( > name = "ctl", > out = "cmctl", > embed = [":go_default_library"], > pure = "on", > visibility = ["//visibility:public"], > x_defs = { > "github.com/cert-manager/cert-manager/cmd/ctl/pkg/build.name": "cmctl", > "github.com/cert-manager/cert-manager/cmd/ctl/pkg/build/commands.registerCom…": "true", > }, > ) Using bazel itself is not possible, this package requires 4.0.0 while OBS only has 3.7.x. And there would be lots of dependencies as far as I can see. Thanks in advance! 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

1 0

sysctl variables changes becoming active on upadting packages?
by Marcus Meissner 21 Feb '22

21 Feb '22

Hi, we are wondering if sysctl values in on of the /etc/sysctl* directories change via a packageupdate, if they should become active immediately, or only ever on next reboot. e.g. running /usr/lib/systemd/systemd-sysctl in %post of such packages would make them active, but could overwrite admin set values. Ciao, Marcus

2 1

Not packaging the same file twice with different names: packaging kubectl plugins
by Johannes Kastl 18 Feb '22

18 Feb '22

Hi again, what is the currently recommended way to have a file installed by a package with two different names? Many kubectl plugins can be run standalone or as a kubectl plugin. The latter only works, if the binary name is kubectl-foo. My first idea: Package /usr/bin/foo and create a link to /usr/bin/kubectl-foo. But how to do that best? Spec? During package installation? Or is there a better approach? Thanks in advance! 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 2

Using tar_scm service for kyverno creates funny archive name and wrong version
by Johannes Kastl 18 Feb '22

18 Feb '22

Hi all, I tried to package the kyverno CLI and kubectl plugin from https://github.com/kyverno/kyverno I used the same _service file structure that I used for lots of go-based packages recently: --- citation start --- <services> <service name="tar_scm" mode="disabled"> <param name="url">https://github.com/kyverno/kyverno</param> <param name="scm">git</param> <param name="exclude">.git</param> <param name="revision">v1.6.0</param> <param name="versionformat">@PARENT_TAG@</param> <param name="changesgenerate">enable</param> <param name="versionrewrite-pattern">v(.*)</param> </service> <service name="set_version" mode="disabled"> <param name="basename">kyverno</param> </service> <service name="recompress" mode="disabled"> <param name="file">*.tar</param> <param name="compression">gz</param> </service> <service name="go_modules" mode="disabled"> <param name="archive">kyverno-1.6.0.tar.gz</param> </service> </services> --- citation end--- For some reason, I end up having an archive called kyverno-helm-chart-2.2.0.tar.gz, which is neither the name I expected nor the version that I specified. Adding a filename parameter to the tar_scm service did not help. Nor does switching to obs_scm (which is not supported by the go modules service). I guess that this is caused by upstream having multiple things (code for docker images, CLI, helm chart, ...) in one repo and only one tag for each release. Nevertheless it would be nice if I could get this solved. Any way to tell tar_scm to use the right name and version? Thanks in advance! Kind Regards, Johannes P.S.: I commited both _service and spec to https://build.opensuse.org/package/show/home:ojkastl_buildservice:Branch_de… -- 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 2

Use of 'recommends' and 'suggests'
by Axel Braun 17 Feb '22

17 Feb '22

Hi, follow-up on my recent dependency mail, I was able to trace some dependencies: python3-weasyprint requires python3-FontTools python3-FontTools requires python3-sympy python3-sympy requires python3-mpmath >= 0.19 python3-sympy recommended python3-jupyter_ipython (comes from python3-ipython) python3-ipython recommended jupyter jupyter recommended jupyter-qtconsole jupyter-qtconsole requires python3-qtconsole = 5.2.1 python3-qtconsole requires python3-qt5 Looking at python-sympy in comaprison to https://packages.debian.org/sid/python3-sympy Debian lists the ipyton stuff under 'enhances', not even 'suggests' - which leads to the question, when to properly use recommends and suggests [1], and if not 'suggets may be the better approach here and there. Suggestions? Cheers Axel [1] https://en.opensuse.org/openSUSE:Build_Service_Tutorial#Create_Patterns

10 13

dependencies of a package
by Axel Braun 10 Feb '22

10 Feb '22

Hi, I'm looking for a tool that lists all dependencies of a package. Background: when installing package 'trytond' I get around 200 additional packages, and onl around 50 with --no-recommends. Some of the packages that are installed with all recommendations I would like to understand where they are coming from...like qt5 libraries and jupyter packages Thanks Axel

10 14

Building RPM packages directly from git without intermediate tarballs?
by Florian Haftmann 07 Feb '22

07 Feb '22

Hi *, I am currently working on an environment for software developers based on openSUSE Leap 15.3 (on WSL, but that should not matter in this context). The aim is to provide developers with a per-configured environment using RPM configuration packages, i. e. packages with add a bunch of environment-specific config files to the existing installation. (The choice to use the package system for configuration delivery is intentional: the package delivery infrastructure is already there and there neither need nor infrastructure for any dynamic configuration service like puppet or ansible, hence no need to blow up the technology stack.) Those configuration packages do not package an existing »foreign« tar ball (towards which rpmbuild seems to be optimized) but are maintained simply in a git repository containing the files according to their place in the file hierarchy. To make rpmbuild work properly, a tar ball has to be generated explicitly first. The current solution is to use a wrapper script that creates the tar ball from the contents of the git working directory and then calls rpmbuild. The problem with that approach is that that wrapper script must either be maintained in every package git simultaneously or by itself provided as an additional build tool in a dedicated package. Both solutions are a little odd. Hence I would prefer a solution which gets along without such auxiliary wrappers, ideally just by calling rpmbuild. (It would be still fine if different build steps rely on auxiliary scripts in the current git working directory or similar). Technically, the necessity to specify (at least) one source in the spec file is the core obstacle: the source, whatever it may be, must be provided somehow by an external script to make rpmbuild not choke on its absence. There might be tools for exactly that purpose, e. g. https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/man.gbp.buil… which is surely helpful, but it is difficult to judge what the most »canonical« or »established« tool is. Any hints appreciated. (I am happy to provide an example if needed but would first have to extract one from the existing material.) Cheers, Florian

3 3