Hi everyone,
I have just orphaned magic-wormhole (the original one written in
Python) and its dependencies. I no longer use it, I have no time to
fix the packages for new Python versions, and upstream is pretty much
dead since they started porting the project to Rust.
- python-magic-wormhole
- python-magic-wormhole-mailbox-server
- python-magic-wormhole-transit-relay
- python-txtorcon
- python-spake2
- python-hkdf
There is an alternative Go implementation of the "Wormhole Protocol"
(wormhole-william), for which eclipseo already submitted a review
request. It seems to be better maintained than the Python original, if
we want to have a Wormhole client in Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=1922806
The official port of magic-wormhole to Rust also seems to be
progressing, we might want to package that one instead once it's
released:
https://github.com/magic-wormhole/magic-wormhole.rs
Fabio
HI,
Development has effectively ended. For years Red Hat drove development for
its RHGS product, but with the EOL of RHGS at the end of 2024 [1], and the
disbanding of RHGS engineering at Red Hat, no development is being done.
The last update (11.1) was on 6 Nov., 2023. Little or no, development is
taking place in the greater Gluster community (such as it is), and no new
updates appear to be forthcoming from any direction.
Over in the CentOS world, the CentOS Storage SIG members have decided not
to build GlusterFS RPMs for Stream 10.
Therefore I intend to retire the GlusterFS package in Fedora 42, unless
someone else would like to step in and take over as package owner.
[1] https://access.redhat.com/support/policy/updates/rhs/
--
Kaleb
Hi everyone!
RPM 4.19 added automatic sysuser handling [1]. In Fedora 39 this feature
was not enabled right away [2] as it requires some care to properly
transition to it. Also going back to 4.18 was technically still the
fallback option during this change.
I just noticed in an issue in the RPM upstream repository [3] that the
sysuser feature is still not enabled. May be right now might be a good
time to get this going for Fedora 41. I am happy to help with the
technical details but would prefer if this effort was driven from within
Fedora.
Currently users are either done manually by calling useradd in
scriptlets or using the macros in systemd-rpm-macros which is a sub
package of the systemd package. RPM's mechanism is switched off by
rpm-4.18.92-disable-sysusers.patch in the rpm package.
This whole thing probably needs to be a Global Change involving a change
to the Packaging Guidelines [4] and may be an Mass Package Change
(although that might be avoided by changing the macros in
systemd-rpm-macros to NOPs).
Anyone interested in picking this up? I remember quite a few people
being exited about this when it was announced with the rpm-4.19 Change.
Florian
[1]
https://rpm-software-management.github.io/rpm/manual/users_and_groups.html
[2] https://fedoraproject.org/wiki/Changes/RPM-4.19
[3] https://github.com/rpm-software-management/rpm/issues/3073
[4] https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups
Hello!
Latest live555-2024.03.08 comes with an SONAME bump from 107 to 112.
The only consumer seems to be vlc, which I'll rebuild in a side-tag
(f41-build-side-87311) and submit together as an update.
This is rawhide only.
Regards,
Dominik
--
Fedora https://fedoraproject.org
Deep in the human unconscious is a pervasive need for a logical universe that
makes sense. But the real universe is always one step beyond logic.
-- from "The Sayings of Muad'Dib" by the Princess Irulan
Hi,
Phoronix recently release article[1] about Intel's Clear Linux with some
cool graphs showing nice performance gain compared to Xubuntu.
I didn't have time to dig in and look how it's performing against Fedora,
but I'd assume Fedora can be compared to Xubuntu in terms of compiler
settings.
I think i'll be interesting to look into it and find out if Fedora can't
tweak compiler settings (eg use LTO for critical things like Mesa, Kernel,
...). I think it could be interesting fo Fedora users to have this enabled
if there are not any disadvantages other than compile time, compile memory
usage and so on.
What do you think?
[1]
http://www.phoronix.com/scan.php?page=article&item=intel-clr-opengl&num=1
--
Best regards / S pozdravem,
František Zatloukal
Project Coordinator
Red Hat
I'm trying to figure out the best way to handle the situation where a
project decides to use submodules in Git. The archive generated doesn't
incorporate the submodule files.
I've done some searching on this, and haven't really come up with much.
I've reviewed: Packaging:Github
<https://fedoraproject.org/wiki/Packaging:SourceURL?rd=Packaging/SourceURL#G…>
; but that really doesn't address the submodule issue.
I looked through some packages that are currently in the Fedora repository
and found where a few folks have rebuilt the tarball and referenced that
version as the Source in the spec file; then they put in a comment stating:
The source of this package was pulled from upstreams' vcs. Use the
following
commands to generate the tarball:
...
- git clone
...
- git submodule init
- git submodule update
...
This approach is the best that I've found. Any other suggestions?
Thanks much!
Hi Folks,
We would like to replace power-profiles-daemon with tuned. There are
many power-related software that offer similar functions. Advanced
users may install several power management tools, for example, tuned
and power-profiles-daemon (ppd), and get confused about which tools
manage the system and cause unexpected behaviors for the system. By
integrating power-profiles-daemon with tuned, the user can get extra
features to finetune the system, and the basic feature provided by ppd
can be used according to the user's demand. It also can reduce the
efforts of the maintainer.
The impact of this plan would be gnome-control-center (power panel),
KDE, sysprof, and tuned (or some projects depending on ppd). We should
move the ppd API and features to tuned to provide the same features of
it. From the API aspect, we also can design a new API for the basic
feature, ppd provided but the software dependent on ppd should be
modified to use the new API. Although, for the long-term plan, a set
of new API is a good option. For the short-term plan, moving the
original one to tuned is good for those applications depending on ppd.
Moreover, the detailed change proposal can be found here.
https://fedoraproject.org/wiki/Changes/TunedReplacesPower-profiles-daemon
If you have any suggestions, please let us know.
Thank you. :)
--
BR,
Kate
We've been looking at the AppStream extractor issues in Fedora, and
we've come across a few broken applications. Broken apps are not
visible in the application installer. The apps include:
* albumart
* apitrace-gui
* appstream
* asylum
* audience
* bomber
* bovo
* calligra-braindump
* cervisia
* choqok
* classified-ads
* crrcsim
* cube
* curblaster
* dsi
* escape
* ettercap
* font-manager
* freedink-engine
* gap-core
* gnofract4d
* gvrng
* hgview
* hyperrogue
* kaddressbook
* key-mon
* kgraphviewer
* knotes
* konqueror
* LabPlot
* nextcloud-client (maybe fixed in distgit)
* openms
* openvibe
* owncloud-client
* pingus
* pioneer
* portecle
* qdigidoc
* qjackctl
* qsynth
* qtikz
* recoll
* renku
* rodent
* screengrab
* screenruler
* simple-ccsm
* slashem
* spectacle
* speed-dreams
* tennix
* tilp2
* tortoisehg
* trophy
* tzclock
* uzbl-defaults
* vdrift
* vegastrike
* wireshark-gtk
* xfce4-power-manager
* xfpanel-switch
* xskat
* yakuake
* zanshin
* zathura
The full list, along with what failed is available here:
https://dl.fedoraproject.org/pub/alt/screenshots/f26/failed.html
If you want any suggestions or advice, I'm happy to help. Most of the
failures are pretty self explanatory, e.g. "No <summary> in AppData"
or "icon was too small 24x24" -- our guidelines are here:
https://github.com/hughsie/appstream-glib/blob/master/README.md#guidelines-…
As a reminder, you can validate AppData files using: appstream-util
validate-relax file.appdata.xml
Thanks, and comments welcome. I can set up a script that sends email
to the package maintainer if this would be helpful, but I thought we
might be able to get the majority of these sorted with this email.
Richard.
Dear colleagues,
as the changes described in
https://fedoraproject.org/wiki/Changes/OpensslDeprecateEngine
were approved and implemented and a week or two has passed, we can
summarize the consequences.
Lack of openssl/engine.h file moved to a separate package is not
processed correctly by packages and requires changes in specs which
also comes with a cost. OpenSSL ABI is kept.
On the other hand, CentOS stream uses a different approach when
openssl keeps ABI, doesn't ship openssl/engine.h, and defines
OPENSSL_NO_ENGINE explicitly, so old applications keep working and at
the same time new application can mostly be rebuilt without
significant problems.
I understand that Fedora has much more packages but there are much
less complaints from CentOS/RHEL than from Fedora.
So I wonder if it's worth changing the engine deprecation mechanism in
Fedora to the one we have in CentOS and if yes, what is the mechanism
for such a change.
--
Dmitry Belyavskiy