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
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)
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
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
-----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�����Ǩ�
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
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
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
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
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