Much like libtest, the mass rebuild has inadvertently bumped the soname
of libnfs. libnfs 6 was in dist-git but had never been built for
Rawhide (there were some attempts in side tags, but they all seem to
have been garbage collected). The mass rebuild built it, so now libnfs
has gone from 5.x to 6.x and soname libnfs.so.14 to libnfs.so.16. This
actually does include a major API change, see upstream:
https://github.com/sahlberg/libnfs/commit/5e8f7ce273308eb77f94248f4501e574a…
there are four external deps of libnfs that I can see:
gvfs-nfs-0:1.56.1-1.fc42.x86_64
qemu-block-nfs-2:9.2.0-3.fc42.x86_64
vlc-plugins-extra-1:3.0.21-15.fc42.x86_64
xine-lib-0:1.2.13-17.fc42.x86_64
qemu-block-nfs and gvfs-nfs are the most important there. qemu-block-
nfs not being installable is breaking at least one other build I'm
trying to do.
gvfs has a port to the new API already:
https://gitlab.gnome.org/GNOME/gvfs/-/merge_requests/257
I'm going to try and use that as a guide to patch qemu and get it
built. Otherwise we may have to try and unpick the soname bump :/
For the future I think we really need to consider some kind of
automated check for when dist-git is ahead of the most recently-tagged
package, when doing the mass rebuild. There are just too many problems
like this.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org
https://www.happyassassin.net
Hi!
In accordance with https://docs.fedoraproject.org/en-US/fesco/Mass_package_changes/,
I plan to do a "mass package change" to add sysusers.d config files for all packages
which currently call 'useradd' and 'groupadd' and drop the calls to
getent/id/useradd/groupadd/usermod/gpasswd.
This is part of https://fedoraproject.org/wiki/Changes/RPMSuportForSystemdSysusers.
Latest build of rpm will autocreate users and groups for all packages that
contain a sysusers.d config file. This means that, for those packages, we can drop
the scriptlets that do that. In fact, rpm will do this unconditionally, so the
scriptlets which are executed later are now noops and having them in the spec file
is unnecessary and confusing.
Once we have sysusers.d config and the metadata generated by rpm on packages, we want
to again enable generation of hard dependencies in rpm for users and groups used by
the rpm payloads. (A package which has a file or dir owned by a user or group,
specified via %attr, gets Requires:user(…) or Requires:group(…) autogenerated during
build.) This will allow rpm to order packages so that accounts are created before we
try to unpack files owned by those accounts and we don't get unexpected ownership.
For now this is a draft, I'm soliciting feedback. In fact, I didn't rebuild most of
the packages with the changes, so bugs may be lurking. After discussion is done, I
plan to open pull requests with the proposed changes.
The first batch:
https://in.waw.pl/~zbyszek/fedora/sysusers_mass_spec_change_v1.diff.html
Example change (without Release and %changelog boilerplate):
===================&<============================================================
diff --git znc/znc.spec znc/znc.spec.tmp
index f27442daf7..c6e08444cc 100644
--- znc/znc.spec
+++ znc/znc.spec.tmp
@@ -54,3 +54,2 @@ Obsoletes: znc-extra <= %{version}-%{release}
-Requires(pre): shadow-utils
BuildRequires: systemd
@@ -131,2 +130,7 @@ sed -ie 's!/usr/local/!/usr/!' man/znc.1
+# Create a sysusers.d config file
+cat >znc.sysusers.conf <<EOF
+u znc - 'Account for ZNC to run as' /var/lib/znc -
+EOF
+
%build
@@ -161,8 +165,5 @@ install -d "%{buildroot}%{_sharedstatedir}/znc"
+install -m0644 -D znc.sysusers.conf %{buildroot}%{_sysusersdir}/znc.conf
+
-%pre
-getent group znc >/dev/null || groupadd -r znc
-getent passwd znc >/dev/null || \
- useradd -r -g znc -d /var/lib/znc -s /sbin/nologin \
- -c "Account for ZNC to run as" znc
@@ -203,2 +204,3 @@ getent passwd znc >/dev/null || \
%attr(-,znc,znc) %{_sharedstatedir}/znc/
+%{_sysusersdir}/znc.conf
===================>&============================================================
Let me know what you think…
Zbyszek
Hi
I'll be updating to cgnslib-4.5.0 in rawhide, building to the
f42-build-side-104235 side tag. I'll also be rebuilding the following
dependencies:
gmsh
paraview
vtk
Thanks
Sandro
Dear all,
I have orphaned the grib_api package for Fedora (which is now also FTBFS
since the F42 mass rebuild), both due to lack of time and since grib_api
has now been unmaintained upstream for over 6 years. It is replaced by
eccodes for those architectures that supports it.
Upstream writes on https://confluence.ecmwf.int/display/ECC/ecCodes+Home:
ecCodes is now the primary GRIB encoding/decoding package used at ECMWF.
GRIB-API is no longer maintained (as of December 2018). Replacing
GRIB-API with ecCodes is expected to be transparent for current GRIB-API
users. In particular the "grib_" functions are included in the ecCodes
library. Users are strongly advised to start the migration process.
See also: https://confluence.ecmwf.int/display/ECC/GRIB-API+migration
Unfortunately eccodes does not support the i686, ppc64, and armv7hl
architectures. If users would need this I recommend them to file a
request at ECMWF to implement this for eccodes.
Jos
Hot news:
- no news today
Two weeks ago we had:
> * 24379spec files in Fedora
>
> * 30988license tags in all spec files
>
> * 161 tags are not SPDX compliant (number from line bellow minus packages with LicenseRef-Callaway-*)
>
> * 2325 tags have not been converted to SPDX yet
>
> * 21 tags can be trivially converted using `license-fedora2spdx`
>
> * Progress: 99.54% ░░░░░░░░░█100%
>
> ELN subset:
>
> 60 out of 2317 packages are not converted yet (progress 97.37%)
>
Today we have:
* 24401spec files in Fedora
* 31038license tags in all spec files
* 142 tags are not SPDX compliant (number from line bellow minus packages with LicenseRef-Callaway-*)
* 2289 tags have not been converted to SPDX yet
* 16 tags can be trivially converted using `license-fedora2spdx`
* Progress: 99.48% ░░░░░░░░░█100%
ELN subset:
61 out of 2316 packages are not converted yet (progress 97.41%)
Graph of these data with the burndown chart:
https://docs.google.com/spreadsheets/d/1QVMEzXWML-6_Mrlln02axFAaRKCQ8zE807r…
The list of packages needed to be converted is here:
https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-f…
List by package maintainers is here
https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-f…
Packages that are neither in SPDX nor in Callaway format (highest priority for now) - 35 packages:
https://pagure.io/copr/license-validate/blob/main/f/neither-nor-remaining-p…
Most of such packages has open issue in fedora-license-data. A lot of them are waiting for SPDX to approved the license
and assign ID.
There was no release of fedora-license-data.
12 licenses are waiting to be reviewed by SPDX.org (and then to be added to fedora-license-data)
https://gitlab.com/fedora/legal/fedora-license-data/-/issues/?label_name%5B…
If your package does not have neither git-log entry nor spec-changelog entry mentioning SPDX and you know your license
tag matches SPDX formula, you can put your package on ignore list
https://pagure.io/copr/license-validate/blob/main/f/ignore-packages.txt
Either pull-request or direct email to me is fine.
Miroslav