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
Hi Jeff, hi all,
apparently kubescape (https://github.com/armosec/kubescape) reorganized their
repository structure and moved/split up the go.mod file from the root of the
repository to some directories in "core" and "cmd".
So the vendoring approach currently being used in the package does no longer
work, as only one of the go.mod files will be found by the obs-service-go_modules.
> https://build.opensuse.org/package/show/devel:kubic/kubescape
> INFO:obs-service-go_modules:Using go.mod found at /home/Buildservice/Branches/Branch_devel_kubic/kubescape/tmp_35r3omj.go_modules.service/kubescape-2.0.150/core/go.mod
I found no hints in the docs, so I guess there is no way to tell the service to
use more than one go.mod? Or to tell it which one to use?
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
Hi,
While the emails are sent under Dominique's name, I made
some changes to the underlying script, so I would like to
make you aware of some changes you might see in your inbox
tonight.
The whole reminder was lifted to include more cases of a
problematic package, so you will see "reminders" of problems
you haven't heard of before.
What we do so far: for failing packages we
- send an email one week after the first failure
- send a reminder the week after
- include the package in a mail to factory@opensuse
for the wider audience after 4 weeks
- create a delete request after 6 weeks
What's new now:
- unresolvable packages in openSUSE:Factory will get the
same 6 weeks before drop as failing packages.
- packages with multibuild flavors failing will get the
same 6 weeks
- packages with 2nd spec files failing will get the same
6 weeks
- i586 failures also get the same 6 weeks. If you don't
care for i586, it's fine for me but then use ExclusiveArch or
ExcludeArch
- uninstallable packages will also get the same 6 weeks.
Including packages uninstallable on i586. For this case,
I now add the installcheck output as comment to the package
in openSUSE:Factory (as the reminder links there). This
already triggers a comment email notification if you're
subscribed to it.
Greetings, Stephan
It was submitted to Factory in parallel:
https://build.opensuse.org/request/show/962550
Dne 18. 03. 22 v 10:13 wengel napsal(a):
> Script 'mail_helper' called by wengel
>
> Hi sbrabec(a)suse.com,
> /work/src/done/SLE15-SP4-STAGING/package-translations was not checked in by wengel for the following reasons:
> (submitrequest 267818 on https://build.suse.de)
>
> Please also submit to Factory
>
>
>
> your dist/autobuild team.
>
--
Best Regards / S pozdravem,
Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o. e-mail: sbrabec(a)suse.com
Křižíkova 148/34 (Corso IIa) tel: +420 284 084 060
186 00 Praha 8-Karlín fax: +420 284 084 001
Czech Republic http://www.suse.cz/
PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76
Script 'mail_helper' called by wengel
Hi sbrabec(a)suse.com,
/work/src/done/SLE15-SP4-STAGING/package-translations was not checked in by wengel for the following reasons:
(submitrequest 267818 on https://build.suse.de)
Please also submit to Factory
your dist/autobuild team.
Hi,
I am faced with a dilemma.
A bunch of users are asking me to activate the OptiX renderer for Blender.
Unlike CUDA, OptiX requires some non-free include files during build[1].
The idea is to fetch the headers, that are provided by NVidia with wget
in order to avoid packaging them up in the source rpm.
I understand, that this is a problem, but is there any chance to get this
going. E.g. using the download service, but not packaging it later on.
If I look at builds like gradle or rancher-desktop, they all end up fetching
huge amounts of binaries from some web resources.
Here; we're talking about a few header files, that we just should avoid to
redistribute.
Here's my current state of affairs[2].
Cheers,
Pete
--
Life without chameleons is possible, but pointless.
[1] https://devtalk.blender.org/t/blender-2-8-cycles-optix-packaging/12533/14
[2] https://build.opensuse.org/package/show/home:frispete:blender/blender-310
Historically, modprobe configuration files have been installed in
/etc/modprobe.d on openSUSE. This has a number of disadvantages.
- packages should generally avoid shipping files under /etc
- customization requires %config or %config(noreplace), with the
well-known issues this may cause on upgrades.
The more "modern" style to enable user customization is to place
distribution-shipped configuration files under /lib/modprobe.d or
/usr/lib/modprobe.d, and let users override them by files of the same
name under /etc/modprobe.d if they desire. This technique has been
supported by kmod for years, and is well established these days by
systemd, udev, dracut, etc., which use the same scheme.
I've started an effort to move all modprobe configuration files shipped
by packages into /usr/lib/modprobe.d on Factory, and /lib/modprobe.d on
Leap. The %config or %config(noreplace) file attributes for the
distribution-shipped defaults are removed.
If the user has modified some of the distro-shipped %config files,
they'll be renamed to .rpmsave by rpm when the update package moves the
config file out of /etc. This would undo user customizations, which is
undesirable. To avoid it, code is added to the spec files of affected
packages, which looks like this (example from "bluez"):
%global modprobe_d_files 50-bluetooth.conf
%pre
# Avoid restoring pre-existing .rpmsave files in %posttrans later by renaming them
for _f in %{?modprobe_d_files}; do
[ ! -f "%{_sysconfdir}/modprobe.d/${_f}.rpmsave" ] || \
mv -f "%{_sysconfdir}/modprobe.d/${_f}.rpmsave" "%{_sysconfdir}/modprobe.d/${_f}.rpmsave.%{name}-%{VERSION}-%{RELEASE}" || :
done
%posttrans
# Modified config files are renamed to .rpmsave by rpm when moved to /usr/lib.
# Restore the user's customizations.
for _f in %{?modprobe_d_files}; do
[ ! -f "%{_sysconfdir}/modprobe.d/${_f}.rpmsave" ] || \
mv -fv "%{_sysconfdir}/modprobe.d/${_f}.rpmsave" "%{_sysconfdir}/modprobe.d/${_f}" || :
done
The current status can be seen on OBS in the home:mwilck:modprobe.d
project (currently WIP).
There has been some confusion about the correct path
(/usr/lib/modprobe.d vs. /lib/modprobe.d). Here's a short summary of
the discussion:
- upstream kmod does supports /lib/modprobe.d only.
- SUSE's kmod is currently patched to support both /lib/modprobe.d and
/usr/lib/modprobe.d.
- On usr-merged Factory, /lib/modprobe.d is an alias for
/usr/lib/modprobe.d, thus they can be used interchangeably. For
correctness and to avoid filename clashes, we use /usr/lib.
- on non-usr-merged distros, we keep the upstream path
/lib/modprobe.d.
Scripts and "consumers" of modprobe.d files can safely look them up
under /lib/modprobe.d, which will "work" on both usr-merged and non-
usr-merged variants.
In the future, %_modprobedir should be used by packages. Currently
though, %_modprobedir is (wrongly) set to /usr/lib/modprobe.d in the
systemd-rpm-macros package on SLE/Leap up to 15.3. Likewise, the
filesystem package on Leap currently contains /usr/lib/modprobe.d but
not /lib/modprobe.d. This will be fixed sooner or later, but spec files
currently need to work around this issue with a conditional. packages
that install into %_modprobedir should add a "%dir %{_modprobedir}"
line to the %files list to avoid build errors.
Furthermore, discussion is ongoing whether the definition of
%_modprobedir should be moved to a different package, and which.
Regards
Martin
PS: @maintainers of affected packages: I've sent a bunch of OBS
requests on Friday and revoked them, because I hadn't added the code
for restoring user modifications yet and I figured I should rather do
that first.