MuseScore 4.0
by Jerry James
MuseScore is music composition and notation software, currently
available from Fedora in the mscore package. Version 4.0 was just
released. If anybody would like to try it out, it is available from
this COPR: https://copr.fedorainfracloud.org/coprs/jjames/MuseScore4/.
I do not intend to build for Fedora until some issues have been worked
out.
WARNING! WARNING! WARNING!
DO NOT TRY THIS IN A WAYLAND SESSION. It will run for anywhere from a
few seconds to a few minutes, then abruptly exit with a "Protocol
error". Run an X session to try MuseScore 4.0.
WARNING! WARNING! WARNING!
WARNING! WARNING! WARNING!
Configuration for MuseScore 3.x and 4.x differs in some important
respects. You may have to do a "factory reset" when switching
versions. Run "mscore -R" or "mscore -F" if it won't start. This
will clear out your list of recently opened scores, for example, so
backup your configuration before you do this.
WARNING! WARNING! WARNING!
To try it out, run:
sudo dnf copr enable jjames/MuseScore4
sudo dnf install musescore
Please try the video export option, which has bitrotted upstream. I
have attempted to update it for current ffmpeg. Please let me know if
it does or does not work for you. If it works well, I will submit my
patch upstream. Do this: "mscore --score-video <path_to_score> -o
filename.mp4", and optionally try the --resolution and --fps
arguments. Run "mscore --help" for more information. This
functionality does not seem to be available via the GUI.
Upstream bundles fluidsynth, apparently for the sole purpose of
implementing a caching soundfont loader that uses internal fluidsynth
APIs. I have unbundled fluidsynth for this repository, which means
there is no soundfont cache. If you switch soundfonts frequently,
please let me know if the performance is acceptable. If you are
familiar with the fluidsynth API and can implement a caching soundfont
loader using only public APIs, please do so and submit it upstream.
Several other products are bundled (beatroot-vamp, dtl, intervaltree,
rtf2html, and KDDockWidgets). Each of them has either been altered by
the MuseScore developers or, in the case of KDDockWidgets, internal
APIs are used so extensively that I cannot see how to unbundle
successfully. Thoughts on how any of these products might be
unbundled are welcome.
The COPR version makes a long-requested change: the package name
changes from mscore to musescore. Let me know if you encounter any
problems arising from that change.
A new font package is needed to build version 4.0 for Fedora. I would
appreciate a review from anybody who feels competent to review a font
package: https://bugzilla.redhat.com/show_bug.cgi?id=2152347. There
is a question about the appropriate foundry name. If you can help
answer that question, please chime in.
Regards,
--
Jerry James
http://www.jamezone.org/
1 year, 3 months
F37 Change Proposal: MAC Address Policy none (System-Wide Change)
by Vipul Siddharth
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
The `systemd-udev` package installs
`"/usr/lib/systemd/network/99-default.link"`,
which sets `Link.MACAddressPolicy=persistent`. This proposal is to
change it to set `Link.MACAddressPolicy=none` to stop changing the MAC address.
This is particularly important for bridge and bond devices.
This change can either only apply to bridge/bond devices, or to
various software devices. That is to be discussed.
== Owner ==
* Name: [[User:thaller|Thomas Haller]] (NetworkManager)
* Email: <thaller(a)redhat.com>
* Name: [[User:dustymabe| Dusty Mabe]] (Fedora CoreOS)
* Email: <dmabe(a)redhat.com>
== Detailed Description ==
On Fedora, udev by default changes the MAC address of a wide range of
software devices.
This was introduced by systemd 242 in early 2019 (Fedora 31), when
`MACAddressPolicy=` was
extended to affect more types of devices.
With `MACAddressPolicy=persistent` udev's aim is to provide a stable
MAC address, otherwise
the kernel will assign a random one. However, that can cause problems:
Firstly, software devices are always created by some tool that has
plans for the device. The tool may not
expect that udev is going to change the MAC address and races against
that. The best solution
for the tool is to set the MAC address when creating an interface.
This will prevent
udev from changing the MAC address according to the MACAddressPolicy.
Otherwise, the tool should wait for udev to initialize the device to
avoid the race. In theory, a
tool is always advised to wait for udev to initialize the device.
However, if it were not for MACAddressPolicy,
in common scenarios udev doesn't do anything relevant for software
devices to make that necessary.
Secondly, for interface types bridge and bond, an unset MAC address
has a special meaning
to the kernel and the MAC address of the first port is used. If udev
changes the MAC
address, that no longer works.
Now the generated MAC address is not directly discoverable as it is
based on `/etc/machine-id`
([https://www.man7.org/linux/man-pages/man5/machine-id.5.html
machine-id(5)]), among
other data. Even if there were a tool to easily calculate the MAC
address, it could be cumbersome
to use it without logging into the machine first. The MAC address can
directly affect the
assigned IP address, for example when using DHCP. When booting a new
virtual machine, the user might
know the MAC address of the (virtual) "physical" interfaces. When
bonding/bridging those
interfaces, the bond/bridge would get one of the well known MAC
addresses. `MACAddressPolicy=persistent`
interferes with that.
The goal of persistent policy is to provide a stable MAC address. Note
that if the
tool or user who created the interface would want a certain MAC address, they
have all the means to set it already. That applies regardless whether
the tool is
iproute2, NetworkManager, systemd-networkd. Neither NetworkManager nor
systemd-networkd
rely on udev's MACAddressPolicy for setting the MAC address. This
behavior is mostly
useful for plain `ip link add`, but it's unclear which real world user
wants this behavior.
Of course, the user is welcome to configure the MAC address in any way
they want. Including,
dropping a link file that sets `MACAddressPolicy=persistent`. The
problem is once udev sets a MAC address,
it cannot be unset. Which makes this problematic to do by default.
While Fedora inherited this behavior from upstream systemd, RHEL-9
does not follow this behavior
([https://gitlab.com/redhat/centos-stream/rpms/systemd/-/blob/c8953519504bf...
centos9],
[https://bugzilla.redhat.com/show_bug.cgi?id=1921094 rh#1921094]). For
RHEL-8, this doesn't
apply because the systemd there is too old to change the MAC address
of most software devices.
This could be either implemented by patching
`/usr/lib/systemd/network/99-default.link`
to have a different policy, or by dropping a link file with higher
priority. In the latter
case, that override could be shipped either by udev or even by NetworkManager.
Another option is to change the scope of this proposal to only change to
`MACAddressPolicy=none` for the device types where this causes the most issues
(bridge/bond/team).
== Feedback ==
This was also discussed on upstream systemd mailing list
[https://lists.freedesktop.org/archives/systemd-devel/2022-May/047893.html
here].
The upstream systemd maintainers' opinion is that the current udev
behavior is desirable, but accepts that distributions (or network
stacks such as NetworkManager) may choose to change the default
depending on their needs
([https://lists.freedesktop.org/archives/systemd-devel/2022-May/047943.html
reference]).
The goal here is to find out what the Fedora community thinks is the
most appropriate default.
The RHEL-9 bug is [https://bugzilla.redhat.com/show_bug.cgi?id=1921094
[rh#1921094]].
== Benefit to Fedora ==
Pros:
- Consistent behavior with RHEL8 and RHEL9.
- Avoid race of udev and the tool that creates the interface.
- Bridge and bond interfaces can get the MAC addresses from their first port.
In the case of `MACAddressPolicy=none` for a bond (or bridge) the bond will
get a MAC related to one of its physical NIC devices. In the case of
provisioning
new systems (especially in a large datacenter) information about the server
can be used to configure the network environment (DHCP, Firewall, etc) before
the server is ever even powered on. This does mean that you may have to update
your network environment configuration if you replace a NIC (con), but that you
won't have to update your network environment configuration if you re-install
your server (pro), which is what you'd have to do now with
`MACAddressPolicy=persistent`.
Cons:
- Deviate from upstream systemd.
It is desirable that RHEL and Fedora behaves similar. A possible outcome
could be the current behavior stays and RHEL 10 would change behavior. On the
other hand, different distributions (or even Fedora spins) have different
uses and needs. Deviating might be fine. In the same vein, there is also
a desire to stay close to upstream systemd behavior. But the uses of systemd
project go beyond Fedora/RHEL, so deviating here may also be fine.
== Scope ==
* Proposal owners:
The main goal of this request is to generate productive discussion and
find the desired behavior.
The implementation/changes are either way very simple.
* Other developers:
Other projects that wish a certain MAC address are welcome to
set it for their devices. Including using udev's MACAddressPolicy.
* Release engineering:
Not needed for this change.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
After the change, the MAC address for the affected device types changes.
== How To Test ==
1) Create a software device two times, for example `ip link add type
bridge`. Note
that the MAC address is either stable or random, depending on the
`MACAddressPolicy=`.
2) Note that if the software device has the MAC address set initially,
udev does not
change it (`ip link add address aa:aa:aa:aa:aa:aa type bridge`). That depends on
`/sys/class/net/$dev/addr_assign_type`.
3) Create a bridge/bond interface without setting the MAC address.
Note that if `MACAddressPolicy=none`,
the MAC address is random at first. Note that attaching the first port
will update the controller's MAC address.
On the other hand, with `MACAddressPolicy=persistent`, the MAC address
of the controller is fixed
and not inherited from the port.
4) Run
ip monitor link &
while : ; do
ip link del xxx
ip link add name xxx type dummy \
&& ip link set xxx addr aa:00:00:00:00:00 \
&& ip link show xxx | grep -q aa:00:00:00:00:00 \
|| break
done
to reproduce the race between a simple tool and udev changing the MAC address.
== User Experience ==
Bond/bridge devices would again get assigned the MAC address of the
first NIC added to the device.
If we chose to not limit the scope of this change to just
bonds/bridges then all software devices would get randomly assigned
MAC addresses.
== Dependencies ==
None.
== Contingency Plan ==
If the change is rejected, nothing needs to be done. The change
itself will be simple to implement.
Contingency deadline: beta freeze
Blocks release? No
== Documentation ==
TODO.
== Release Notes ==
--
Vipul Siddharth
He/His/Him
FPgM team member
1 year, 3 months
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, 3 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, 3 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, 3 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, 3 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, 3 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, 3 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, 4 months
