July 2019 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] Proposal: Use /usr/libexec for libexec content
by Neal Gompa 02 Sep '19

02 Sep '19

Hello, I'd like to propose adding /usr/libexec to the openSUSE FHS and reverting the definition of %_libexecdir in rpm back to /usr/libexec so that libexec content is installed there. Currently, openSUSE overrides rpm to define %_libexecdir as /usr/lib, which leads to pollution of the /usr/lib directory with executable content as well as 64-bit content when there shouldn't be any. The /usr/libexec has been in use on RH/Fedora and Mageia systems in the Linux world, but has its origins in BSD and is still used today in BSDs and variants (like Mac OS X). The usage of /usr/libexec for libexec content has also been recognized by FHS with v3.0, released in 2015. In the Linux distribution landscape (that is, all major families, not just RPM ones), /usr/libexec is in use on Red Hat, Mandrake, Gentoo, and Slackware families. This is a breaking change, as it means that as packages are rebuilt, libexec content *should* migrate from /usr/lib to /usr/libexec. The major advantage of migrating the libexec content is that it will make openSUSE consistent with other major RPM-based Linux distributions, and ease efforts in supporting SUSE distributions along with Red Hat ones by removing the need for hacks and tweaks to support two different hierarchies. This simplifies the portability headaches in supporting both distribution families, and makes it easier for applications that were originally aimed for RHEL/CentOS to run on SLE/openSUSE Leap. This change would be done in three stages: 1. Make the change to the filesystem package to add /usr/libexec to the hierarchy. 2. Add /usr/libexec to allowed prefixes in rpmlint-checks and remove spec-cleaner rule that assumes /usr/lib == %_libexecdir. 3. Make the change to the rpm package to set %_libexecdir back to /usr/libexec. This one will cause a fair bit of work to fix packages that do the wrong thing one way or another with %_libexecdir. What do you all think? Best regards, Neal -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 3

[opensuse-packaging] [Proposal] Stop requiring bundled static libs in foo-devel-static subpackages - use bundled() instead
by Dan Cermak 26 Aug '19

26 Aug '19

Hi list, I would like to propose a change in our packaging guidelines, specifically the part about bundling static libraries in a *-devel-static subpackage (see: https://en.opensuse.org/openSUSE:Packaging_guidelines#Exception). How about we follow what Fedora does and instead of putting the static lib in a subpackages, we put it in the "main" package instead and add a: Provides: bundled(foo) = $version into the spec file? The full guidelines are here: https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packaging:Bundled_Libra… This has the advantage that we don't have this additional -static package, which is relatively pointless beside keeping track of bundled libraries. Querying the bundled packages can be then done as follows: rpm -qa --qf "%{name} %{providename}\n"|grep bundled or via zypper: zypper search --provides 'bundled(*)' Any opinions/thoughts? Cheers, Dan -- Dan Čermák <dcermak(a)suse.com> Software Engineer Development tools SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg)

8 20

[opensuse-packaging] Re: [opensuse-factory] Proposal: Use /usr/libexec for libexec content
by Neal Gompa 26 Aug '19

26 Aug '19

On Tue, Jul 23, 2019 at 7:33 AM Richard Brown <rbrown(a)suse.de> wrote: > > On Mon, 2019-07-22 at 15:28 +0200, Thorsten Kukuk wrote: > > On Mon, Jul 22, Neal Gompa wrote: > > > > > This change would be done in three stages: > > > > > > 1. Make the change to the filesystem package to add /usr/libexec to > > > the hierarchy. > > > 2. Add /usr/libexec to allowed prefixes in rpmlint-checks and > > > remove > > > spec-cleaner rule that assumes /usr/lib == %_libexecdir. > > > 3. Make the change to the rpm package to set %_libexecdir back to > > > /usr/libexec. This one will cause a fair bit of work to fix > > > packages > > > that do the wrong thing one way or another with %_libexecdir. > > > > > > What do you all think? > > > > I don't see really a problem with this subdirectories in /usr/lib, > > as this is nothing a normal user should care about, and for > > packages, RPM does take care of if the package uses the correct > > macros. But I would not vote against it, too. > > > > I have a much bigger problem with all the configuration files in > > /usr/lib and subdirectories, because this makes it really hard > > and difficult for admins to find the right one. > > While I agree with Thorsten's additional problem, I don't think the > existance of that issue negates Neal's points. > > I would quite like to see /usr/libexec established in openSUSE..but how > we will handle executables that currently live in /usr/lib for the 32- > bit version and /usr/lib64 for the 64-bit version? > The last time this had been brought up, it sounded like those were packaging mistakes, and that binaries being installed into /usr/lib64 needed to be fixed anyway. I don't know how many of those are like that (I don't have an easy way to get all the spec files and grep through them like I do for Fedora package specs...), but I think those would just be fixed so that binaries would be installed correctly into /usr/libexec. I don't know of a circumstance where we need multiarch *binaries* along with multiarch *libraries*. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 4

[opensuse-packaging] New macro to limit resources allocation per thread
by Tomas Chvatal 23 Aug '19

23 Aug '19

Hello all, For use in libreoffice, chromium and others I've created macro that should allow you to limit jobs based on some constraints you can set later on in the spec to avoid OOM crashes. The usage is pretty straight forward (Once it is accepted in Tumbleweed): === BuildRequires: memory-constraints %build # require 2GB mem per thread %limit_build -m 2000 make %{?_smp_mflags} ==== Here the _smp_mflags vaule for 8GB machine would be 4 while default is number of cores (lets say 16)... Both macros %jobs and %_smp_mflags are overriden as such the integration should be really painless if you need to do something like this. Tom

7 12

[opensuse-packaging] Conditionals and BuildRequires
by Sean Marlow 31 Jul '19

31 Jul '19

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi fellow packagers, I'm attempting to add a conditional in spec for running tests in a package. The goal is to have an option to disable the tests in %check and conditionally removing the related build requirements. The example is a python package [1]. The conditional is "%bcond_without test" and the test requirements are wrapped in an if clause like: %if %{with test} BuildRequires: %{python_module blinker} ... %endif Similarly the %check section looks like: %if %{with test} %pytest %endif I've added the following to the project config: Macros: %_without_test 1 :Macros However, OBS does not respect the conditonal and complains that some of the BuildRequires inside the if block are unresolvable. I've tested this with another package where there are no missing build requirements and OBS skips the tests as expected. Is there a way to have OBS ignore the BuildRequires inside a conditional like this? [1] https://build.opensuse.org/package/show/home:seanmarlow:branches:devel:lang… Thanks, - -- Sean Marlow Public Cloud Developer sean.marlow(a)suse.com -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEqA16xWoe2L38VgYCJ30GzZDdUEsFAl1BthQACgkQJ30GzZDd UEvIwxAAli4YLTwvMt9xHTWtAgNATPA+xuyAPlPK5t4yAXdEyRFY2X7QQVm1Uc3T H0odA/s46260OW0qiCA+moVN9Yvv1ooeWWat1Ybz0rdXJ5cB70QJ40Nd1Hx60b81 G7S3OSbJWEQf8OOCBsorcFZMsUTRoyyKiyN0V4ulWvV42UCLuIY+mj7/yIgrJG1s 35KtIoFSxaHWAvJCulWhtamoleRZdwlc8G6WdyW7nhvQI8LjVjvveFKSOGLZqofn rtn+0zYhNZMvGU0BttPbs1zm1kofx5jMKu/K7VkRJzfZuaFru37kSf2xl2qt6bWs rQXPy8L3848puYoBrHFJsFFaQRrQjSz2gRs+Bjs0LcBkgeReWdEwnH1AW2DSR1EA 0MLaXjpS034yjqud7gWdLLK1LqXQeBOiCyAvdAZhYuvp9lZNI/JmEENoeMvL5KJz X7CnVvY7Qn+cPDEcwignVXaPcVy/9db2OUTjtG4Wq5B4owbk95ytcl3o70w8yvdc auJe/rZRY1mSjFQx442MstSXtLzdw0LnRHRkoP6YKHSasr7ZJQfUWcm3qJjkE1QJ PsQe01SiVCrm842kLuJ7HVYh/0mibqIVfrV321nD0z2FxAhDEbOU/ufQK07khhM+ /3zAJ5P0jLFbyoQwLSoYJFOKZwOEVulyBmgSNIprMBWmMtQKwSE= =XiDg -----END PGP SIGNATURE----- N��r��y隊Z)z{.��ZrF��x>�{.n�+��Ǩ��r��i�m��0��ޙ��$j��0��Ǩ�

3 3

[opensuse-packaging] Re: [opensuse-factory] Update on configuration location below /usr
by Hans-Peter Jansen 30 Jul '19

30 Jul '19

Dear Manfred, dear Richard, Am Dienstag, 30. Juli 2019, 15:01:46 CEST schrieb Richard Brown: > On Mon, 2019-07-29 at 18:54 +0200, Manfred Hollstein wrote: > > > I'd prefer /usr/config or /usr/cfg over /usr/etc. Aside from the > > > collision in usage, "etc" is a terrible name for the configuration > > > directory ("etc" was a catch-all directory originally, which is why > > > so > > > many executable shell scripts were in there...), and we can do > > > better > > > than that in 2019. > > > > +1 for /usr/etc for obvious reasons: > > everyone coming from a *NIX background *knows* what /etc is and > > probably can deduct, what /usr/etc is. Even if you believe it was a > > terrible name, it *is* a name known to a lot of people, at least > > > > from > > > > a generation before 2019 or maybe more ;) Even M$ adopted it... (do > > you know where their /etc/hosts equivalent lives ;) ? ) > > +1 for /usr/etc from me also. > > It's important that we establish the relationship between /etc and > /usr/etc, and that's easiest done with reflecting that in their names. Well, allow me to bring an answer from Thorsten to your attention (as of Sun, 28 Jul 2019 10:38:07 +0200): > > Hmm, do you have any pointer on such distributions and their usage pattern > > of /usr/etc? I wasn't able to find something, that really matters in this > > regard. > > OSTree is using /usr/etc to store data for their three-way-diff-merge > of configuration files. > On *BSD, users have to edit the files in /usr/etc, while in our case, > this should be "read-only", and user have to create the changes in /etc. > There are distributions who did the "UsrMerge" by moving /etc to > /usr/etc and makeing /etc a symlink to /usr I don't care much about *BSD layout, but since OSTree seems an interesting project, as well as the last point renders this approach problematic at least. So he concludes: > What would happen if we choose /usr/etc and other distributions cannot > follow us? > 1. we are the only one who are doing, and will always be different > 2. The others will come up with another standard, and either we are > > alone/different, or have to do the work a second time. > > I don't like any of this options. Let me add: we should not interfere with libostree based projects (which would make libostree based projects unfeasible for our platform, especially since some Fedora-based projects adapt this already). So this is enough evidence of not using /usr/etc, no matter how much we all agree on this choice otherwise, isn't it? Cheers, Pete -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] Re: RFC: configuration files in /etc
by Thorsten Kukuk 29 Jul '19

29 Jul '19

Hi, to come back to this, original email as reference below. Looks like Lennart Poettering wants to do something similar with Fedora for systemd.volatile, /etc should only contain the user modified files, everything distribution provided should be located in /usr. I only don't like to fill up /usr/lib with even more stuff people will not find anymore afterwards. The discussions on the FHS mailing list were mixed, but in the end: FHS will not specify anything, we should just do it. The most promising suggestions were: - /usr/sysconfig - /usr/config - /usr/etc Starting doing the changes and moving the stuff around is simple, we only need to agree on a location. What's the opinion here? Thorsten On Mon, Jun 03, Thorsten Kukuk wrote: > > Hi, > > for this, who don't want to read a lot of text, there is a video of > my talk about this topic from openSUSE Conference: > https://youtu.be/ony0ajC0PWA > > The slides can be found here: > https://github.com/thkukuk/atomic-updates_and_etc/tree/master/Slides > > and the full, detailed abstract can be found here: > https://github.com/thkukuk/atomic-updates_and_etc/blob/master/README.md > > > What is this about? > > RPM has a really very simple configuration file handling: overwrite > the config, move it away and write the new config or write the new config > in a different file (*.rpmsave and *.rpmnew). > If the rpm contains a configuration file marked as %config, and the > packager fixes a typo in a comment, RPM will move the by the admin > modified and adjusted configuration file away and put's the default > configuration file there, which means, your service will not work until > you merge the configuration files. > > This is already bad, but it's getting really worse if you think about > atomic updates (transactional-updates on openSUSE): > - admin modifies configuration files > - admin starts an transactional update, the configuration file will > be modified > - admin makes changes to the configuration file > - admin reboots to active the changes > -> admin needs to find out which changes where done by whom and needs to > merge them all to get the service working again > > While this shouldn't happen very often, more really seldom, if it happens, > it's really bad. Especially, if you think about big clusters with many > machines and not only a few workstations. > > > So I started looking into different solutions. > The first thing is: we are not alone with the problem, every distribution > with atomic updates has it, but every distribution has their own solution. > Which reminds me on the pre-FHS times, when you had to learn for every > distribution again where the configuration files and other tools could > be found. > So we need something, which helps everybody and is good enough specified, > that people will use this solution. > > The second thing is: people want to have the configuration files in one > place, so that it is easy to find. > > And at least, no, there is not the perfect solution solving everything, > for some I even have no idea, but for others we make big improvements > compared to today. > > The goal is to provide a concept working for all Linux Distributors (like > the FHS, preferred is to get this into the FHS). Short to midterm, it should > solve the problems with atomic updates. Midterm to longterm, the result > should be, that no package installs anything in /etc, it should only contain > changes made by the system administrator or configuration files managed by > the system administrator. > > The current proposals are: > https://github.com/thkukuk/atomic-updates_and_etc/blob/master/README.md#pro… > > A short summary: > > Application configuration files: > Do something similar to what systemd is already doing today (See > https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Examples, > "Overriding vendor settings"). Put the default, by a Linux distributor > shipped configuration files somewhere below /usr, and /etc only contains > the overwrite. > > This sounds like a lot of work, but in reality, many applications we > have on openSUSE Tumbleweed alredy support different locations for > configuration files and overwrite of them, like sysctl, dracut, PAM and > many more. For this, this is only a packaging exercise and rpmlint > checks. > > > System databases: > This are files in /etc like rpc, services and protocols. > We can put them somewhere below /usr, and /etc/ only contains the changes. > A glibc NSS module could merge them automatcially, different implementations > do exist already today for this. > > > /etc/passwd, /etc/group and /etc/shadow: > This is the big, open problem. We looked at many possible solutions, > but didn't found the real, generic one. > > > So, what is the expected outcome of this mail? > 1. We need to agree, if we want to solve the problem or not > In my opinion, there is no real choice, if we don't do it > coordinated as Linux distributor, this will happen in a chaotic way. > 2. We need to agree on the goal, so for me, this would be: > - short term: solve the problem for packages on openSUSE MicroOS > - mid term: solve the problem for openSUSE Tumbleweed > - long term: /etc/ only contains admin created files, a Linux > Distribution does not install there anything > 3. We need to agree on a path below /usr for the default configuration > files > 4. We need to agree on how we want to solve it. > > > > Your comments and feedback? > > Thanks, > Thorsten > > > -- > Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS > SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany > GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg) > -- > To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org > To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

10 22

[opensuse-packaging] Warning on the use of the %limit_build macro
by Dave Plater 25 Jul '19

25 Jul '19

The new %optflag -flto=n gets it's n from the same place as %_smp_mflags so if you have placed the %limit_build macro after %optflags you may have a higher number of threads for lto than you have for make. I really don't know if this is harmful to runtime but it brought back intermittent build failures to graphics/blender. I've written a warning in the wiki entry for %limit_build Regards Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] Mailinglist outage yesterday
by Christian Boltz 19 Jul '19

19 Jul '19

Hello, (sorry for the massive cross-post - if you answer, please reply only on one mailinglist) TL;DR: If you sent a mail to one of the openSUSE mailinglists yesterday and it didn't arrive, please re-send it. Please also re-send any mail you sent to admin(a)o.o or board(a)o.o yesterday. Longer version: As you probably noticed by observing the silence in your inbox, the mailinglists were down yesterday. This downtime which had two reasons: a) postfix not starting on our outgoing mailserver after a kernel update and reboot - one of the server's IPs wasn't configured fast enough on boot and prevented starting postfix b) our mailinglist software needing additional AppArmor permissions after a kernel update. This is a known change for newer kernel versions, but shouldn't happen as part of a kernel update, therefore I opened https://bugzilla.opensuse.org/show_bug.cgi?id=1142120 The downtime started around 7:00 UTC (9:00 CEST). I noticed it in the evening, and around 21:50 UTC (23:50 CEST) everything worked again. a) wouldn't be too bad - the sending mailservers queues the mails, and they "just" get delayed. Unfortunately issue b) is more problematic - it seems the mailinglist software failed with $? = 0 so postfix thought the mails were successfully delivered, but in fact they are more or less lost. (Our mailinglist admin found them in the incoming/ directory, but he's on vacation with terrible internet access and probably can't do much about this in the next days. Sending out the then-old mails when he's back doesn't really make sense IMHO.) Therefore: If you sent a mail to one of our mailinglists yesterday and it didn't arrive, please re-send it. Please also re-send any mail you sent to admin(a)o.o or board(a)o.o yesterday. Regards, Christian Boltz -- Should you ever feel lonely or be overwhelmed with spare time: you know where to find us. [Dominique Leuenberger in opensuse-project] -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] Need an RSA key for openssl signing, please create a new key
by Adam Mizerski 15 Jul '19

15 Jul '19

I wanted to fix wireguard package (my branch: https://build.opensuse.org/package/show/home:etamPL:branches:network:vpn:wi…). Builds are failing with error "Need an RSA key for openssl signing, please create a new key". I found this thread: https://lists.opensuse.org/opensuse-buildservice/2014-11/msg00012.html It says I should run "osc signkey --create <project>". I did it and got "<status code="ok" />". There's also a button in webui in my home project labeled "GPG Key / SSL Certificate" and it shows some key. But when I run "osc signkey --sslcert home:etamPL:branches:network:vpn:wireguard", I get this: home:etamPL:branches:network:vpn:wireguard home:etamPL:branches:network:vpn:wireguard has no key, trying home:etamPL:branches:network:vpn home:etamPL:branches:network:vpn has no key, trying home:etamPL:branches:network home:etamPL:branches:network has no key, trying home:etamPL:branches home:etamPL:branches has no key, trying home:etamPL home:etamPL has no key, trying home Server returned an error: HTTP Error 404: Not Found home Do I need to fix anything with my key, or should I create a bug report? -- Adam Mizerski

2 2