Hi,
Fedora Workstation Working Group is tentatively planning to remove the
ABRT user interface (gnome-abrt) in Fedora 44. For more information,
see:
https://pagure.io/fedora-workstation/issue/130#comment-992075
ABRT is currently in maintenance mode, receiving primarily bugfixes
rather than feature development. The Working Group would prefer to keep
gnome-abrt, but only if it were to receive considerable new feature
development. If anybody is interested in working on ABRT, help would be
welcome.
Removing the user interface will not affect the automatic crash report
functionality. Crashes will still be reported to
https://retrace.fedoraproject.org/faf/summary/ which contains a
treasure trove of crash telemetry. It's a shame that Fedora developers
rarely look at it! This data could be quite useful for improving
software quality. If anybody is interested in this topic, it might be a
good opportunity to integrate AI, which could identify crash patterns
or perhaps even suggest fixes.
So that's two possible projects, in case anybody is looking for an itch
to scratch.
Michael
Hello!
When I'm observing java stack, its usage, and adaptation of eclipse
temurin JDKs, I'm happily surprised by what I see. It seems that
temurin JDKs are used extensively, even more than our in-distro JDKs.
Originally - in https://fedoraproject.org/wiki/Changes/ThirdPartyLegacyJdks - I wrote
that jdk21 will be removed in f45, but it seems it can be removed
already in f44. From total java-stack(546 packages), only 26 requires
jdk21 for build[1]. Dropping jdk21 already for f44 would help our
quite constrained resources and also have a net benefit on the
infrastructure, since keeping it in Fedora 44 means keeping 21 alive
until May 2027 which is too long of a time for a duplicate legacy JDK,
especially when such a great and working alternative exist.
WDYT?
Best regards,
J.
[1]
apache-commons-modeler-0:2.0.1-43.fc42.src
apache-commons-text-0:1.10.0-8.fc42.src
apache-sshd-1:2.11.0-2.fc41.src
decentxml-0:1.4-36.fc41.src
fop-0:2.9-9.fc41.src
Java-WebSocket-0:1.6.0-4.fc43.src
l10n-maven-plugin-0:1.1.0-2.fc43.src
maven-archetype-0:3.2.1.0.8b3bdb6-14.fc41.src
resteasy-0:3.0.26-32.fc42.src
xmlgraphics-commons-0:2.11-1.fc43.src
javapoet-0:1.7.0-27.fc43.src
java-runtime-decompiler-0:10.0-6.fc43.src
jol-0:0.17-10.fc43.src
juniversalchardet-0:2.4.0-16.fc43.src
plexus-velocity-0:2.2.1-2.fc43.src
stringtemplate4-0:4.3.4-9.fc43.src
xbean-0:4.24-8.fc43.src
xbean-0:4.24-9.fc43.src
icedtea-web-0:1.8.8-10.fc43.src
java-21-openjdk-portable-1:21.0.8.0.9-1.fc43.2.src
ldapjdk-0:5.6.0-0.1.alpha1.fc43.3.src
ldapjdk-0:5.6.0-1.fc43.src
mecab-java-0:0.996-14.fc43.src
openjdk-asmtools-0:9.0.0.b12.ea.eb1979669-0.fc43.src
mecab-java-0:0.996-14.fc43.src
fop-0:2.9-9.fc41.src
nekohtml-0:1.9.22-29.fc42.src
jedit-0:5.6.0-8.fc43.src
Seem like I'm maintaining quite a few of them anyway....
--
Jiri Vanek <j.vanek(a)ibm.com>
Principal JDK QA engineer
IBM Middleware Czechia s.r.o.
+420 775 39 01 09
I'm trying to do something like this in %check:
%{?with_xwayland:xwayland-run -- } %ctest --verbose || :
but I'm ending up with just:
xwayland-run --
/usr/bin/ctest --test-dir "redhat-linux-build-${mpi:-serial}" \
because %ctest starts with a newline:
%ctest(:-:h:j:u:v:A:C:D:E:F:H:I:L:M:N:O:Q:R:S:T:U:V:) \
%__ctest --test-dir "%{__cmake_builddir}" \\\
...
So I have to do the strange:
%{?with_xwayland:xwayland-run -- \ } %ctest --verbose || :
Can we get some kind of standard that rpm macros should not be defined
to start with a newline? Or is there some other better way to handle
this in general? Because if %ctest were changed to not start with a new
line, then I believe this last construct would break.
Thanks
--
Orion Poplawski
he/him/his - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 https://www.nwra.com/
Hello,
I'm trying to upload widelands-1.3.tar.gz for widelands package update:
$ fedpkg new-sources widelands-1.3.tar.gz
Uploading: widelands-1.3.tar.gz to
https://src.fedoraproject.org/repo/pkgs/upload.cgi
Uploading: widelands-1.3.tar.gz
########################################################################
100.0%
Could not execute new_sources: Fail to upload files. Server returns
status 502
I've watched while the progress was around 98-99% something, then looked
briefly elsewhere and voila, error.
Repeated several times, not watching closely (as it is taking 10-20
minutes) and repeated failing.
Upload speed seems to be bellow what my uplink permits.
Sizes:
$ ls -1hs *.tar.gz
437M widelands-1.2.1.tar.gz
447M widelands-1.3.tar.gz
Meaning:
- I was able to upload widelands-1.2.1.tar.gz before
- I'm failing to upload widelands-1.3.tar.gz now
Any tips?
Thank you in advance.
Sincerely
Peter
--
Peter Hanecak <hanecak(a)hany.sk>
https://hany.sk/~hany/
GnuPG: https://hany.sk/~hany/gpg/key.txt
Hey all,
I was originally hoping to flick the switch as soon as
https://fedoraproject.org/wiki/Changes/Enforcing_signature_checking_by_defa…
got accepted, but in my test-builds, an unexpected setback appeared.
That setback is now resolved (a silly one-liner cmake issue causing a
miscompilation), but it's now also getting quite close to the X-mas
break. Apparently a lot of folks will be heading off next week already,
and then I myself will be unavailable for more than two weeks. This just
doesn't seem like a good time to do a potentially disruptive change. So,
instead of creating unnecessary stress just before X-mas, lets just push
this to 2026. The plan is now to flick signature enforcing mode on in
RPM on week 3 of 2026, Jan 13th most likely.
For those wanting to test it in advance, f44-build-side-123720 side-tag
has an RPM with the enforcing mode enabled. There's no intention to
merge this side-tag, it's purely for testing purposes so feel free to
test builds if needed and so on. I've built one package (popt) there to
verify that building in koji works with the enforcing mode enabled. It
does, and Fedora CI passes for the change itself, so at least basic
operation of the buildsystem seems to work. For all the things out there
that I don't even know about, we'll see. If it uses dnf with
appropriately configured gpgcheck= entries on repos, it should continue
to work without modifications.
- Panu -
Dear package maintainers currently using Zuul,
Packit as Fedora dist-git CI has recently reached feature-parity with
the Zuul CI, and as the first step
in the final phase implementation of the "Packit as dist-git CI" change
[1] we are migrating
the current Zuul CI users to packit Fedora CI [2] and disabling the Zuul
runners on
src.fedoraproject.org/rpms/* for the time being.
Our plan is to automatically migrate the Zuul dist-git packages on
2026-01-12 (January 12).
Please let us know of any concerns you might have with the migration up
until then so we can decide whether
we can go forward with it. We will send another reminder of this as a
reply to this announcement one week
before the migration 2026-01-05 (January 5).
After the packages are migrated we will monitor your feedback [3-6] on
this migration and decide if we can go ahead
with the Zuul deprecation and disablement or need to resolve any
blocking issues first. We could also keep the
Zuul CI temporarily running on a small subset of packages if requested.
We are looking forward to your feedback on this matter.
PS: The migration of the other Zuul jobs that are linked to pagure.io
[7] will be addressed at a later
time as these require custom handling and are tied with the forge
migration. We do not have a timeline
for this part yet, but we will provide an update as soon as we have a
plan for this.
[1]: https://fedoraproject.org/wiki/Changes/PackitDistgitCI
[2]: https://github.com/packit/deployment/pull/672
[3]: Fedora CI channel https://matrix.to/#/#fedora-ci:fedoraproject.org
[4]: Packit channel https://matrix.to/#/#packit:fedora.im
[5]: Packit issues
https://github.com/packit/packit-service/issues/new?template=fedora-ci.yml
[6]: This email and discussion thread
[7]:
https://pagure.io/fedora-project-config/blob/master/f/resources/fedora-sour…
Hi,
GNU Guile 3.0.10 was released over a year ago, but Fedora's guile30
package is still based on 3.0.9:
https://bugzilla.redhat.com/show_bug.cgi?id=2294649
Half a year ago a build of 3.0.10 was tried. Apparently there was a
build failure on i686. (I have not been able to find the logs of that
build.) I'm not aware of an attempt to fix this failure. Nor was it
decided to exclude i686 from future builds of GNU Guile.
As far as I can see Tomáš is pretty active in Fedora
(https://src.fedoraproject.org/user/tkorbar lists 75 packages!). So
there was no reason to check whether Tomáš is non responsive regarding
those other packages. It's unfortunate that, in order to get this
package unstuck, I have to follow the (public) non-responsive
maintainer procedure.
Kind regards,
Paul Bolle
Hi,
I'd like to switch gnome-software in rawhide to use a dnf5 plugin, to
move away from its dependency on the PackageKit. This had been
announced together with the dnf5 change proposal some time ago [1], but
due to some missing work on the gnome-software side it had been
postponed. As the work is ready, I'd like to finally finish this
part [2] of that Change as well.
I'll wait for two weeks and unless some strong objection is arose here
I'll do the switch to the dnf5 plugin in rawhide, for the Fedora 43.
Bye,
Milan
[1] https://fedoraproject.org/wiki/Changes/SwitchToDnf5
[2] https://fedoraproject.org/wiki/Changes/SwitchToDnf5#GNOME_Software_support
Hi list,
after upgrading to fiber I have noticed that fedpkg new-sources did not
get much faster despite my upload bandwith going up 12 times. I have
then noticed that my laptop equipped with semi-recent 4500U APU is at
100% CPU usage when uploading new mame [1] sources.
Is this normal, and can anything be done about it? For tiny sources it
is not a real issue, but for mame uploading the new sources to lookaside
cache is by far the slowest part of the update process. Thanks!
Best regards,
Julian
[1] https://github.com/mamedev/mame/archive/refs/tags/mame0281.tar.gz