How/Where to put git_archieve.tar.gz for packaging?
by Ming Lei
Hello Richard and Guys,
I am trying to figure out one PR for ubdsrv to sync with upstream.
I found the following change in history update:
commit 2ab1e571717a13edddc572269608e918e449a3b8 (origin/main)
Author: Richard W.M. Jones <rjones(a)redhat.com>
Date: Thu Nov 3 11:33:42 2022 +0000
Move to a newer tag (1.0-rc3 + a couple of upstream patches)
diff --git a/sources b/sources
index 47e83d8..1735716 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (ubdsrv-698c92c9d292903adae142a86d2fee10fce91850.tar.gz) = a12e218b6d97631b9726cdaa2e14dfb7f4df422dd77265701f40ba8704c7d4ccac6c632f635115863f8694bd626f06f67e2ebdf93ae92778a0dae3cddb0259c6
+SHA512 (ubdsrv-ca8baff898868f2ee6f5cdda9c16cf8d94435262.tar.gz) = 9d85271cc73026e7ff8a58153cffb4fd9f760c136d790e0b681cd6b903813cd9d9b98bba934c7ef1248ee0514fe7a6967d3ee65afd6cc44ea0bd3a0796c62ff3
diff --git a/ubdsrv.spec b/ubdsrv.spec
'fedpkg build' needs ubdsrv-698c92c9d292903adae142a86d2fee10fce91850.tar.gz to be
put somethere, and I guess when I sync with upstream for ubdsrv new change,
I need to generate ubdsrv-${GIT_HASH}.tar.gz & its sha512sum, and put it
somewhere so that 'fedpkg' can find it and test it first.
Can anyone help to share how/where to upload ubdsrv-${GIT_HASH}.tar.gz?
Also I don't know how to figure out the sha512sum hash? I tried to do that for
ubdsrv-698c92c9d292903adae142a86d2fee10fce91850.tar.gz by plain sha512sum, but
get different result compared with the value in above commit even though the
comment of .tar.gz is same(same prefix, same 'diff -u').
Thanks,
Ming
1 year, 2 months
Improving Fedora boot time when libvirt is installed
by Gordon Messmer
(apologies for the long-ish message, but I'd like to save people the
trouble of re-reading a year-old very long email thread)
Early last year there was a thread on this list (Re: "Is
NetworkManager-wait-online.service necessary by default?") in which
maintainers discussed the issue of boot times increasing when libvirt
was installed as a result of iscsi creating a service order dependency
between network-online and remote-fs-pre. If I'm not mistaken, it was
unanimously agreed that it was undesirable for this dependency to exist.
This delay is still the most common cause that I find among people who
complain that it takes a long time to boot Fedora, and unfortunately the
most common advice given to those people is "disable network-online".
It's difficult to explain why this is a Bad Thing (TM).
A number of possible solutions were discussed in that thread.
Unfortunately many of them don't work (or don't work reliably), which I
assume is why the problem is not solved, so I'm hoping to revive
discussion of the ones that will work. The problem occurs because: 1)
libvirt requires libvirt-daemon-driver-storage-iscsi and
iscsi-initiator-utils, 2) iscsi.service is enabled by default (per
https://pagure.io/fesco/issue/2386), 3) iscsi.service is ordered after
network-online and 4) before remote-fs-pre.target.
iscsi.service already has a "ConditionDirectoryNotEmpty", but that's
evaluated when the service would be executed, so the ordering dependency
between network-online and remote-fs-pre exists even though iscsi won't
start. There was some discussion of using ".path" units, but that seems
to have the same problem.
There was also discussion of disabling the service by default and using
a generator to enable the service, and Lennart thought this was the best
solution. I started work to add a simple generator, but the
documentation for systemd.generator states "Non-essential file systems
like /var/ and /home/ are mounted after generators have run," and the
purpose of the generator would be to enable the service when there are
files in /var/lib/iscsi/nodes.
Several people suggested using a weak dependency (Suggests:) on the
iscsi driver, but I don't think that would solve the problem for most
users because weak dependencies are installed by default and nothing
really communicates to users that unless they add an obscure option,
their boot times will increase.
So, things that could work:
The package dependency could be dropped from libvirt entirely. Libvirt
users who want iscsi support can install that storage driver manually.
(addressing condition 1)
A generator would work if the iscsi node configs were in /etc instead of
/var. Would we consider changing the package layout? Possibly, moving
the node configurations to /etc and changing /var/lib/iscsi/nodes to a
symlink, with a pre-install script to handle existing installations?
We'd also need to change the default service state to disabled.
(addressing condition 2)
The ordering dependency on remote-fs-pre.target could be dropped, though
I expect that there will be objections and that option wouldn't be
considered. (addressing condition 4)
FESCo could also revisit 2386 and reconsider whether enabled by default
is the right decision for this service. I assume there was an explicit
decision for this because of the policy that an enabled-by-default
service "must not require manual configuration to function", which iscsi
does. Maybe the fact that it requires manual configuration means that
interested users should also be required to enable the service, given
the pain that the status quo causes for what seems like the far more
common case that this service is installed by all users of libvirt but
not needed by most of them. (also addressing condition 2)
1 year, 2 months
Orphaned packages looking for new maintainers
by Miro Hrončok
The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will fail to install and/or build when the affected package gets retired.
Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/<pkgname>
Full report available at:
https://churchyard.fedorapeople.org/orphans-2023-01-30.txt
grep it for your FAS username and follow the dependency chain.
For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan
Package (co)maintainers Status Change
==============================================================================
belle-sip orphan, sdgathman 1 weeks ago
golang-github-cockroachdb-cockroach go-sig, orphan 3 weeks ago
golang-github-deepmap-oapi-codegen go-sig, orphan 1 weeks ago
golang-github-deislabs-oras go-sig, orphan 2 weeks ago
golang-github-docker-swarmkit go-sig, orphan 3 weeks ago
golang-github-skynetservices-skydns go-sig, jchaloup, orphan 1 weeks ago
humanity-icon-theme orphan 2 weeks ago
libeXosip2 orphan 1 weeks ago
libosip2 orphan 1 weeks ago
light-themes orphan 2 weeks ago
linphone orphan, sdgathman 1 weeks ago
lizardfs orphan 0 weeks ago
lnst jtluka, orphan, rpazdera 3 weeks ago
ocaml-dose3 orphan 2 weeks ago
ocaml-mccs orphan 2 weeks ago
ocaml-opam-file-format orphan 2 weeks ago
ortp orphan, sdgathman 1 weeks ago
percona-xtrabackup orphan, slaanesh 0 weeks ago
python-yubikey-manager orphan 3 weeks ago
python3-script orphan 2 weeks ago
rust-iter-read orphan, rust-sig 2 weeks ago
rust-lmdb orphan, rust-sig 2 weeks ago
rust-peresil orphan, rust-sig 2 weeks ago
rust-protoc orphan, rust-sig 2 weeks ago
rust-rawslice orphan, rust-sig 2 weeks ago
rust-sudo_plugin-sys orphan, rust-sig 2 weeks ago
rust-unreachable orphan, rust-sig 2 weeks ago
stgit orphan 2 weeks ago
validns orphan 2 weeks ago
The following packages require above mentioned packages:
Depending on: golang-github-deepmap-oapi-codegen (7), status change: 2023-01-19
(1 weeks ago)
golang-github-exoscale-egoscale (maintained by: carlwgeorge, go-sig)
golang-github-exoscale-egoscale-0.38.0-6.fc38.src requires
golang(github.com/deepmap/oapi-codegen/pkg/runtime) = 1.8.2-6.fc38
golang-github-exoscale-egoscale-devel-0.38.0-6.fc38.noarch requires
golang(github.com/deepmap/oapi-codegen/pkg/runtime) = 1.8.2-6.fc38
golang-github-acme-lego (maintained by: eclipseo, go-sig)
golang-github-acme-lego-4.4.0-8.fc37.src requires
golang(github.com/exoscale/egoscale) = 0.38.0-6.fc38
golang-github-acme-lego-devel-4.4.0-8.fc37.noarch requires
golang(github.com/exoscale/egoscale) = 0.38.0-6.fc38
golang-github-acme-lego-3 (maintained by: eclipseo, go-sig)
golang-github-acme-lego-3-3.9.0-7.fc37.src requires
golang(github.com/exoscale/egoscale) = 0.38.0-6.fc38
golang-github-acme-lego-3-devel-3.9.0-7.fc37.noarch requires
golang(github.com/exoscale/egoscale) = 0.38.0-6.fc38
golang-github-caddyserver-caddy-1 (maintained by: eclipseo, go-sig)
golang-github-caddyserver-caddy-1-1.0.4-11.fc38.src requires
golang(github.com/go-acme/lego/v3/certcrypto) = 3.9.0-7.fc37,
golang(github.com/go-acme/lego/v3/challenge) = 3.9.0-7.fc37,
golang(github.com/go-acme/lego/v3/challenge/tlsalpn01) = 3.9.0-7.fc37,
golang(github.com/mholt/certmagic-0.8) = 0.8.3-4.fc35
golang-github-caddyserver-caddy-1-devel-1.0.4-11.fc38.noarch requires
golang(github.com/go-acme/lego/v3/certcrypto) = 3.9.0-7.fc37,
golang(github.com/go-acme/lego/v3/challenge) = 3.9.0-7.fc37,
golang(github.com/go-acme/lego/v3/challenge/tlsalpn01) = 3.9.0-7.fc37,
golang(github.com/mholt/certmagic-0.8) = 0.8.3-4.fc35
golang-github-mholt-certmagic-0.8 (maintained by: eclipseo, go-sig)
golang-github-mholt-certmagic-0.8-0.8.3-4.fc35.src requires
golang(github.com/go-acme/lego/v3/acme) = 3.9.0-7.fc37,
golang(github.com/go-acme/lego/v3/certcrypto) = 3.9.0-7.fc37,
golang(github.com/go-acme/lego/v3/certificate) = 3.9.0-7.fc37,
golang(github.com/go-acme/lego/v3/challenge) = 3.9.0-7.fc37,
golang(github.com/go-acme/lego/v3/challenge/dns01) = 3.9.0-7.fc37,
golang(github.com/go-acme/lego/v3/challenge/http01) = 3.9.0-7.fc37,
golang(github.com/go-acme/lego/v3/challenge/tlsalpn01) = 3.9.0-7.fc37,
golang(github.com/go-acme/lego/v3/lego) = 3.9.0-7.fc37,
golang(github.com/go-acme/lego/v3/registration) = 3.9.0-7.fc37
golang-github-mholt-certmagic-devel-0.8-0.8.3-4.fc35.noarch requires
golang(github.com/go-acme/lego/v3/acme) = 3.9.0-7.fc37,
golang(github.com/go-acme/lego/v3/certcrypto) = 3.9.0-7.fc37,
golang(github.com/go-acme/lego/v3/certificate) = 3.9.0-7.fc37,
golang(github.com/go-acme/lego/v3/challenge) = 3.9.0-7.fc37,
golang(github.com/go-acme/lego/v3/challenge/dns01) = 3.9.0-7.fc37,
golang(github.com/go-acme/lego/v3/challenge/http01) = 3.9.0-7.fc37,
golang(github.com/go-acme/lego/v3/challenge/tlsalpn01) = 3.9.0-7.fc37,
golang(github.com/go-acme/lego/v3/lego) = 3.9.0-7.fc37,
golang(github.com/go-acme/lego/v3/registration) = 3.9.0-7.fc37
golang-github-coredns-corefile-migration (maintained by: eclipseo, go-sig)
golang-github-coredns-corefile-migration-1.0.11-10.fc38.src requires
golang(github.com/caddyserver/caddy-1/caddyfile) = 1.0.4-11.fc38
golang-github-coredns-corefile-migration-devel-1.0.11-10.fc38.noarch requires
golang(github.com/caddyserver/caddy-1/caddyfile) = 1.0.4-11.fc38
golang-k8s-kubernetes (maintained by: eclipseo, go-sig)
golang-k8s-kubernetes-1.22.0-2.fc36~bootstrap.src requires
golang(github.com/coredns/corefile-migration/migration) = 1.0.11-10.fc38
golang-k8s-kubernetes-devel-1.22.0-2.fc36~bootstrap.noarch requires
golang(github.com/coredns/corefile-migration/migration) = 1.0.11-10.fc38
Depending on: golang-github-deislabs-oras (1), status change: 2023-01-09 (2
weeks ago)
golang-helm-3 (maintained by: dcavalca, go-sig)
golang-helm-3-3.5.4-2.fc35.src requires
golang(github.com/deislabs/oras/pkg/auth) = 0.11.1-4.fc36,
golang(github.com/deislabs/oras/pkg/auth/docker) = 0.11.1-4.fc36,
golang(github.com/deislabs/oras/pkg/content) = 0.11.1-4.fc36,
golang(github.com/deislabs/oras/pkg/context) = 0.11.1-4.fc36,
golang(github.com/deislabs/oras/pkg/oras) = 0.11.1-4.fc36
golang-helm-3-devel-3.5.4-2.fc35.noarch requires
golang(github.com/deislabs/oras/pkg/auth) = 0.11.1-4.fc36,
golang(github.com/deislabs/oras/pkg/auth/docker) = 0.11.1-4.fc36,
golang(github.com/deislabs/oras/pkg/content) = 0.11.1-4.fc36,
golang(github.com/deislabs/oras/pkg/context) = 0.11.1-4.fc36,
golang(github.com/deislabs/oras/pkg/oras) = 0.11.1-4.fc36
Depending on: humanity-icon-theme (2), status change: 2023-01-11 (2 weeks ago)
light-themes (maintained by: orphan)
monochrome-icon-theme-16.10-15.20180421bzr625.fc38.noarch requires
humanity-icon-theme = 0.6.15-10.fc38
yaru-theme (maintained by: atim)
yaru-icon-theme-22.10.3-2.fc38.noarch requires humanity-icon-theme =
0.6.15-10.fc38
Depending on: libeXosip2 (2), status change: 2023-01-19 (1 weeks ago)
linphone (maintained by: orphan, sdgathman)
linphone-3.6.1-50.fc38.i686 requires libeXosip2.so.7
linphone-3.6.1-50.fc38.src requires libeXosip2-devel = 3.6.0-29.fc38
linphone-3.6.1-50.fc38.x86_64 requires libeXosip2.so.7()(64bit)
sipwitch (maintained by: nucleo, smani)
sipwitch-1.9.15-19.fc38.src requires libeXosip2-devel = 3.6.0-29.fc38
sipwitch-1.9.15-19.fc38.x86_64 requires libeXosip2.so.7()(64bit)
sipwitch-runtime-1.9.15-19.fc38.i686 requires libeXosip2.so.7
sipwitch-runtime-1.9.15-19.fc38.x86_64 requires libeXosip2.so.7()(64bit)
Depending on: libosip2 (3), status change: 2023-01-19 (1 weeks ago)
libeXosip2 (maintained by: orphan)
libeXosip2-3.6.0-29.fc38.i686 requires libosip2.so.7, libosipparser2.so.7
libeXosip2-3.6.0-29.fc38.src requires libosip2-devel = 3.6.0-25.fc38
libeXosip2-3.6.0-29.fc38.x86_64 requires libosip2.so.7()(64bit),
libosipparser2.so.7()(64bit)
libeXosip2-devel-3.6.0-29.fc38.i686 requires libosip2-devel = 3.6.0-25.fc38
libeXosip2-devel-3.6.0-29.fc38.x86_64 requires libosip2-devel = 3.6.0-25.fc38
linphone (maintained by: orphan, sdgathman)
linphone-3.6.1-50.fc38.i686 requires libeXosip2.so.7, libosip2.so.7,
libosipparser2.so.7
linphone-3.6.1-50.fc38.src requires libeXosip2-devel = 3.6.0-29.fc38,
libosip2-devel = 3.6.0-25.fc38
linphone-3.6.1-50.fc38.x86_64 requires libeXosip2.so.7()(64bit),
libosip2.so.7()(64bit), libosipparser2.so.7()(64bit)
sipwitch (maintained by: nucleo, smani)
sipwitch-1.9.15-19.fc38.x86_64 requires libeXosip2.so.7()(64bit),
libosipparser2.so.7()(64bit)
sipwitch-runtime-1.9.15-19.fc38.i686 requires libeXosip2.so.7,
libosipparser2.so.7
sipwitch-runtime-1.9.15-19.fc38.x86_64 requires libeXosip2.so.7()(64bit),
libosipparser2.so.7()(64bit)
sipwitch-1.9.15-19.fc38.src requires libeXosip2-devel = 3.6.0-29.fc38
Depending on: ocaml-dose3 (4), status change: 2023-01-14 (2 weeks ago)
opam (maintained by: jjames)
opam-2.1.3-5.fc38.src requires ocaml-dose3-devel = 7.0.0-11.fc38
ocaml-benchmark (maintained by: andyli)
ocaml-benchmark-1.6-3.fc38.src requires opam-installer = 2.1.3-5.fc38
ocaml-sha (maintained by: andyli)
ocaml-sha-1.15.2-3.fc38.src requires opam-installer = 2.1.3-5.fc38
haxe (maintained by: andyli, rjones)
haxe-4.2.5-5.fc38.src requires ocaml-sha-devel = 1.15.2-3.fc38
Depending on: ocaml-mccs (4), status change: 2023-01-14 (2 weeks ago)
opam (maintained by: jjames)
opam-2.1.3-5.fc38.src requires ocaml-mccs-devel = 1.1-40.14.fc38
ocaml-benchmark (maintained by: andyli)
ocaml-benchmark-1.6-3.fc38.src requires opam-installer = 2.1.3-5.fc38
ocaml-sha (maintained by: andyli)
ocaml-sha-1.15.2-3.fc38.src requires opam-installer = 2.1.3-5.fc38
haxe (maintained by: andyli, rjones)
haxe-4.2.5-5.fc38.src requires ocaml-sha-devel = 1.15.2-3.fc38
Depending on: ocaml-opam-file-format (4), status change: 2023-01-14 (2 weeks ago)
opam (maintained by: jjames)
opam-2.1.3-5.fc38.src requires ocaml-opam-file-format-devel = 2.1.4-7.fc38
ocaml-benchmark (maintained by: andyli)
ocaml-benchmark-1.6-3.fc38.src requires opam-installer = 2.1.3-5.fc38
ocaml-sha (maintained by: andyli)
ocaml-sha-1.15.2-3.fc38.src requires opam-installer = 2.1.3-5.fc38
haxe (maintained by: andyli, rjones)
haxe-4.2.5-5.fc38.src requires ocaml-sha-devel = 1.15.2-3.fc38
Depending on: ortp (3), status change: 2023-01-19 (1 weeks ago)
libeXosip2 (maintained by: orphan)
libeXosip2-3.6.0-29.fc38.src requires ortp-devel = 2:0.23.0-8.fc35
linphone (maintained by: orphan, sdgathman)
linphone-3.6.1-50.fc38.i686 requires libeXosip2.so.7, libortp.so.9,
ortp(x86-32) = 2:0.23.0-8.fc35
linphone-3.6.1-50.fc38.src requires libeXosip2-devel = 3.6.0-29.fc38,
ortp-devel = 2:0.23.0-8.fc35
linphone-3.6.1-50.fc38.x86_64 requires libeXosip2.so.7()(64bit),
libortp.so.9()(64bit), ortp(x86-64) = 2:0.23.0-8.fc35
linphone-devel-3.6.1-50.fc38.i686 requires pkgconfig(ortp) = 0.23.0
linphone-devel-3.6.1-50.fc38.x86_64 requires pkgconfig(ortp) = 0.23.0
linphone-mediastreamer-3.6.1-50.fc38.i686 requires libortp.so.9
linphone-mediastreamer-3.6.1-50.fc38.x86_64 requires libortp.so.9()(64bit)
linphone-mediastreamer-devel-3.6.1-50.fc38.i686 requires ortp-devel(x86-32) =
2:0.23.0-8.fc35, pkgconfig(ortp) = 0.23.0
linphone-mediastreamer-devel-3.6.1-50.fc38.x86_64 requires ortp-devel(x86-64)
= 2:0.23.0-8.fc35, pkgconfig(ortp) = 0.23.0
sipwitch (maintained by: nucleo, smani)
sipwitch-1.9.15-19.fc38.src requires libeXosip2-devel = 3.6.0-29.fc38
sipwitch-1.9.15-19.fc38.x86_64 requires libeXosip2.so.7()(64bit)
sipwitch-runtime-1.9.15-19.fc38.i686 requires libeXosip2.so.7
sipwitch-runtime-1.9.15-19.fc38.x86_64 requires libeXosip2.so.7()(64bit)
Depending on: rust-lmdb (1), status change: 2023-01-14 (2 weeks ago)
fapolicy-analyzer (maintained by: jwass3)
fapolicy-analyzer-0.6.8-1.fc38.src requires rust-lmdb-devel = 0.8.0-9.fc38
See dependency chains of your packages at
https://packager-dashboard.fedoraproject.org/
See all orphaned packages at https://packager-dashboard.fedoraproject.org/orphan
Affected (co)maintainers (either directly or via packages' dependencies):
andyli: ocaml-dose3, ocaml-opam-file-format, ocaml-mccs
atim: humanity-icon-theme
carlwgeorge: golang-github-deepmap-oapi-codegen
dcavalca: golang-github-deislabs-oras
eclipseo: golang-github-deepmap-oapi-codegen
go-sig: golang-github-skynetservices-skydns,
golang-github-cockroachdb-cockroach, golang-github-deepmap-oapi-codegen,
golang-github-docker-swarmkit, golang-github-deislabs-oras
jchaloup: golang-github-skynetservices-skydns
jjames: ocaml-dose3, ocaml-opam-file-format, ocaml-mccs
jtluka: lnst
jwass3: rust-lmdb
nucleo: libosip2, ortp, libeXosip2
rjones: ocaml-dose3, ocaml-opam-file-format, ocaml-mccs
rpazdera: lnst
rust-sig: rust-unreachable, rust-rawslice, rust-lmdb, rust-peresil,
rust-iter-read, rust-sudo_plugin-sys, rust-protoc
sdgathman: ortp, libosip2, belle-sip, linphone, libeXosip2
slaanesh: percona-xtrabackup
smani: libosip2, ortp, libeXosip2
--
The script creating this output is run and developed by Fedora
Release Engineering. Please report issues at its pagure instance:
https://pagure.io/releng/
The sources of this script can be found at:
https://pagure.io/releng/blob/main/f/scripts/find_unblocked_orphans.py
Report finished at 2023-01-30 09:53:02 UTC
1 year, 2 months
Schedule for Tuesday's FESCo Meeting (2023-01-31)
by Zbigniew Jędrzejewski-Szmek
Following is the list of topics that will be discussed in the
FESCo meeting Tuesday at 17:00UTC in #fedora-meeting on
irc.libera.chat.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/UTCHowto
or run:
date -d '2023-01-31 17:00 UTC'
Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda
= Discussed and Voted in the Ticket =
#2942 Change: IPP-USB as a weak dependency of CUPS and sane-airscan
https://pagure.io/fesco/issue/2942
APPROVED (+3,0,-0)
#2941 Go 1.19 in Fedora 36
https://pagure.io/fesco/issue/2941
APPROVED (+4, 0, 0)
#2939 Change: Unfiltered Flathub
https://pagure.io/fesco/issue/2939
APPROVED (+3,1,-0)
#2938 Change: Noto CJK Variable Fonts
https://pagure.io/fesco/issue/2938
APPROVED (+3,0,-0)
= Followups =
= New business =
#2934 Restore Provides: singularity to apptainer packaging
https://pagure.io/fesco/issue/2934
= Open Floor =
For more complete details, please visit each individual
issue. The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda
If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
1 year, 2 months
HEADS-UP: Upcoming retirement of long-term-unused packages for Rust crates
by Fabio Valentini
Hi all,
I've been collecting data about the dependency graph of Rust packages
in Fedora for over a year now, and I would like to start the process
of removing some accumulated cruft. In particular, I've been keeping
track of which packages for *library* packages (i.e. they ship only
source code but no binaries) have been leaf packages.
List of Rust library-only packages, which no other package in Fedora
has depended on, for over a year (365 days+):
- rust-compiletest_rs
- rust-constant_time_eq
- rust-conv
- rust-counted-array
- rust-dbus-tokio
- rust-defmac
- rust-dialoguer
- rust-enumset
- rust-failure-tools
- rust-fake-simd
- rust-fbthrift_codegen_includer_proc_macro
- rust-fdlimit
- rust-hamcrest2
- rust-html2pango
- rust-imgref
- rust-ioctl-rs
- rust-lipsum
- rust-listenfd
- rust-loggerv
- rust-lzw
- rust-macro-attr
- rust-mdl
- rust-mktemp
- rust-mnt
- rust-newtype_derive
- rust-odds
- rust-osstrtools
- rust-parse_cfg
- rust-permutate
- rust-piper
- rust-podio
- rust-proc-quote-impl
- rust-process_path
- rust-progress-streams
- rust-protoc-rust
- rust-quickersort
- rust-rand_jitter
- rust-rand_os
- rust-read_input
- rust-relay
- rust-rustc_tools_util
- rust-rustdoc-stripper
- rust-rustfilt
- rust-safe-transmute
- rust-scoped-tls-hkt
- rust-serde-pickle
- rust-serial-core
- rust-sluice
- rust-smallstr
- rust-spinning_top
- rust-spmc
- rust-ssh-key-dir
- rust-stb_truetype
- rust-string_cache_shared
- rust-strings
- rust-sudo_plugin
- rust-sxd-document
- rust-synom
- rust-sysctl
- rust-tabwriter
- rust-take
- rust-timerfd
- rust-tower-test
- rust-tower-util
- rust-ucd-util
- rust-unic-ucd-category
- rust-url_serde
- rust-urlocator
- rust-utf8-ranges
- rust-watchman_client
Some of these packages are dependencies of things that will be worked
on at some point in the future (for example, packaging of GStreamer
plugins that are written in Rust), but others look very much like
accumulated cruft.
If you see a package on this list that you would like to keep for some
reason, please speak up, and I will exclude it from future dependency
graph analysis. Otherwise I will soon start retiring packages that
have been unused for over a year.
The packages that would be in the list above, but which I *know* will
get some use soon, are:
- rust-curve25519-dalek
- rust-gstreamer-audio
- rust-gstreamer-editing-services
- rust-gstreamer-player
I will probably start the cleanup process with packages for crates
that no longer have any dependent crates listed on the crates.io
registry (which is a good indicator that they are indeed obsolete),
and then continue with crates for which the longest amount of time has
passed since the last upstream release (which is "more than 5 years
ago" for some crates ...).
Fabio
1 year, 2 months
Proposal: explicitly require full process to resubmit rejected
proposals to FESCo
by Ben Cotton
As a result of concerns about how the re-vote on the frame pointers
Change, it makes sense to clarify the requirements for FESCo
re-considering rejected proposals. FESCo #action bcotton'ed in the 10
January meeting[1] to develop a proposal.
I have drafted a proposal that you can find as fesco-docs#71[2] and
presented here for convenience:
> Proposals that are rejected may be submitted by reconsideration, but they must go through whatever process was originally required before FESCo begins voting. For example, this means a rejected Change proposal must be resubmitted to the Change Wrangler as outlined in the Changes process.
I intentionally wrote this to apply to all proposals generally instead
of Changes specifically. It makes sense to me that we address the
general case instead of waiting until another process needs a similar
policy adjustment. However, I can see this potentially being a poor
fit for long-fuse processes like the inactive maintainers policy
(although it seems less likely that a request would be rejected and
immediately be resubmitted).
Anyway, the proposal is presented here for comment. I'll open a FESCo
ticket in a week for formal approval.
[1] https://meetbot.fedoraproject.org/fedora-meeting/2023-01-10/fesco.2023-01...
[2] https://pagure.io/fesco/fesco-docs/pull-request/71
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 2 months
Orphaning lizardfs
by Jonathan Dieter
I've just orphaned lizardfs. Lizardfs is a clustered network
filesystem that has very efficient small file / metadata performance,
but hasn't seen any upstream point releases since the end of 2017 and
now FTBFS in the latest mass rebuild.
Jonathan
1 year, 2 months
-fno-omit-frame-pointer does not work as advertised
by Kevin Kofler
Hi,
to those who are pushing the -fno-omit-frame-pointer change: Are you aware
that neither that flag nor even -mno-omit-leaf-frame-pointer actually
guarantee that every leaf function is going to carry a frame pointer, as
required for your backtraces?
See for yourself:
https://godbolt.org/z/TjzTsWoWT
The only way to get GCC to generate a frame pointer for this function is to
not use any optimization at all (-O0, or just leave the flags empty, which
unfortunately defaults to -O0 in GCC).
I have tried:
* just -O2
* -O2 -fno-omit-frame-pointer
* -O2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
and all of them produce just imul+mov+ret, which means that an unwinder
based purely on frame pointers will NOT be able to locate the caller of this
function if the profiler snapshots it in the middle.
Another issue is that even if the function does have a frame pointer, it
takes time to set up the frame pointer (push rbp; mov rbp, rsp), and it also
needs to be popped at the end (pop rbp) before returning (ret), so a
randomly sampled snapshot can always happen to be taken in the short time
window where the frame pointer is not ready, which will also lead to the
caller being unable to be located. This inherently makes purely frame-
pointer-based unwinding unreliable.
Frame pointers sound like a simple solution to unwinding, but they are not.
They are no complete replacement for unwinding information.
Kevin Kofler
1 year, 2 months
What should we do about "shopping list" groups in comps?
by Adam Williamson
Hey folks!
I've sort of happened into doing some maintenance of fedora-comps over
the last few years. Something that bugs me while working on this is how
many "shopping list" groups we still have. I'm talking about things
like the network-server group:
<id>network-server</id>
<_name>Network Servers</_name>
<_description>These packages include network-based servers such as DHCP, Kerberos and NIS.</_description>
<default>false</default>
<uservisible>true</uservisible>
<packagelist>
<packagereq type="optional">389-ds-base</packagereq>
<packagereq type="optional">ahcpd</packagereq>
<packagereq type="optional">amanda-server</packagereq>
<packagereq type="optional">babeld</packagereq>
<packagereq type="optional">cobbler</packagereq>
<packagereq type="optional">dhcp-relay</packagereq>
<packagereq type="optional">dhcp-server</packagereq>
<packagereq type="optional">dnsmasq</packagereq>
<packagereq type="optional">freeradius</packagereq>
...etc etc...
I'd define a "shopping list" group as one based around a vague theme
and whose packages are all (or almost all) optional - it's clearly not
a group that's meant to be installed as a whole, or as a part of a
system deployment. These groups were instead designed as lists to pick
individual packages from, in the old anaconda installer interface that
let you do individual package selection (this is, what, a decade or so
ago now?), and in software installation apps that similarly let you
pick packages from the comps groups.
Neither GNOME Software nor KDE Discover uses these "shopping list"
groups. (The older GNOME tool that preceded Software did, I think;
again, that was years ago now). However, dnfdragora (which is the main
package manager on some smaller desktops, and may still be installed on
KDE alongside Discover by default, I'm not sure) *does* - you can
browse by comps group (and 'category', which are collections of comps
groups intended for this purpose, different from the 'environments'
used by anaconda) in dnfdragora. Maybe some other GUI packaging tools
do as well, I'm not sure of any others to check.
It does not appear to me like anyone besides me does much maintenance
on these groups. For instance, I don't think anyone but me has touched
the network-server group since 2019.
These are the groups I'd identify as "shopping list groups":
cloud-infrastructure
directory-server
dns-server (one 'default' package)
editors
education
ftp-server (one 'mandatory' package)
games (the games spin does not use this group, it has its own list)
graphical-internet
graphics
legacy-network-server
libreoffice-development
network-server
neuron-modelling-simulators
news-server (one 'mandatory' package)
office
server-cfg (one 'default' package)
sound-and-video
text-internet
window-managers
there are a few other groups that don't fit strictly into the
definition but are still of rather dubious usefulness, like the 'web-
server' group which is rather stuck in the 2000s (including php, php-
ldap, php-mysqlnd, squid and webalizer by default - is this how anyone
"deploys a web server" these days?) Being stuck in the 2000s is kind of
a defining feature of these groups - any time you see a vaguely modern
package, it's probably been put there by me, replacing something that
got orphaned. Otherwise most of them seem to have been defined back
then and rarely or never updated since. (Another example: the last time
the 'games' group was updated by anyone but me was 2017, adding one
game; the last update before that seems to have been in 2013).
So, I'm wondering what folks think we should do with these. We could,
of course, just get rid of them. But perhaps they are still of value to
someone? Is anyone still "package shopping" via dnfdragora or some
other tool, using these groups? Does anyone want to step up and
actively 'own' some of them for maintenance? Any other thoughts?
Thanks folks!
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
1 year, 2 months
