Wiki: https://fedoraproject.org/wiki/Changes/Lua5.5
Discussion Thread:
https://discussion.fedoraproject.org/t/f45-change-proposal-lua5-5-systemwid…
**This is a proposed Change for Fedora Linux.**
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 ==
Update Fedora's Lua interpreter to 5.5.
== Owner ==
* Name: [[User:spot| Tom Callaway]]
* Email: spotrh(a)gmail.com
== Detailed Description ==
Lua is one of the critical languages supported in Fedora, notably, because
of RPM, but for a variety of other reasons as well. It is lightweight and
well maintained. Upstream released 5.5 on December 22, 2025, and we have
always kept Fedora on the current revision whenever possible. Its main new
features are declarations for global variables, named vararg tables, more
compact arrays, and major garbage collections done incrementally.
== Feedback ==
N/A
== Benefit to Fedora ==
Fedora has always been considered an excellent platform for lua users,
because of our quick adoption of the current lua interpreter, as well as
our willingness to aggressively patch for minor releases and known lua bugs
fixed in their upstream source. This change would continue that behavior.
Additionally, because lua is used in the internals of RPM, we inherit
performance improvements through newer lua that benefit RPM, which has a
broad impact on Fedora. Changing to lua 5.5 has low impact to end users,
the language itself remains mostly compatible with previous revisions. Most
of the gains here are in bug and performance fixes.
== Scope ==
* Proposal owners:
The following dependent packages need to be rebuilt (in a side-tag):
ClanLib06
apk-tools
aqualung
asc
asterisk
awesome
brltty
ceph
cgit
clingo
collectd
conky
corsix-th
darktable
domoticz
dovecot
eiskaltdcpp
fcitx
fennel
fillets-ng
fityk
funguloids
geeqie
gnuplot
golly
gpick
gplugin
grafx2
graphviz
grilo-plugins
haproxy
hexchat
highlight
httpd
ibus-libpinyin
ibus-pinyin
imapfilter
ipe
janus
libguestfs
libinput
libloc
librime
librs232
lighttpd
lite-xl
lsyncd
lua-alt-getopt
lua-argparse
lua-bit32
lua-cassowary
lua-cldr
lua-cliargs
lua-cosmo
lua-coxpcall
lua-cqueues
lua-cyrussasl
lua-dbi
lua-epnf
lua-ev
lua-event
lua-expat
lua-filesystem
lua-fluent
lua-inotify
lua-json
lua-ldap
lua-lgi
lua-linenoise
lua-loadkit
lua-lpeg
lua-luaossl
lua-luarepl
lua-luautf8
lua-lunitx
lua-luv
lua-lxc
lua-md5
lua-moonscript
lua-mosquitto
lua-mpack
lua-posix
lua-psl
lua-readline
lua-sec
lua-socket
lua-sql
lua-term
lua-timerwheel
lua-unbound
lua-vstruct
lua-zlib
luabind
luarocks
lujavrite
lumail
lutok
lxi-tools
mathgl
megaglest
mle
mm3d
mod_security
monotone
nbdkit
neomutt
opendkim
osm2pgsql
plplot
prosody
rpc2
rpm
rrdtool
scorched3d
sile
slurm
suricata
texworks
tio
tolua++
ucviewer
uwsgi
vis
vlc
weechat
wireplumber
wireshark
worker
xmake
xmoto
xournalpp
I expect these packages should rebuild with minimal changes.
* Other developers:
Barring any significant issues in the above packages, no other developers
should be impacted.
* Release engineering:
This feature should not require coordination with rel-eng, though, we
probably want to merge this _before_ the mass rebuild to make sure RPM is
intact.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: Yes, because it keeps Fedora on
current lua.
== Upgrade/compatibility impact ==
Should be none.
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? N
== How To Test ==
All existing lua scripts/scripting should continue to work as is. If not,
this is a bug we will address in conjunction with upstream.
== User Experience ==
The user experience should not be affected.
== Dependencies ==
Known dependencies are listed above. We have updated lua in the past and
feel confident there are not hidden dependencies.
== Contingency Plan ==
We can keep a lua54 compatibility package (I'm 99% sure we will need one in
order to update RPM, but we usually get rid of it before everything lands).
We can also rollback to lua 5.4 if we have issues rebuilding the
dependencies.
* Contingency mechanism: (What to do? Who will do it?) I will make a lua54
compatibility package that is generated from the lua package and contains
liblua-5.4. Packages unable to migrate can depend on it as long as
necessary.
* Contingency deadline: Beta freeze?
* Blocks release? Yes, because of RPM. If we get RPM going quickly, this
becomes a no.
== Documentation ==
https://www.lua.org/manual/5.5/readme.html#changes
== Release Notes ==
Fedora has updated to Lua 5.5.
--
*Allison King*
Senior Technical Project Manager, In-Vehicle OS
Red Hat <https://www.redhat.com/>
alking(a)redhat.com
<https://red.ht/sig>
--
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr…
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
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
Hi,
I plan to update cmocka in Fedora Rawhide to version 2.0.1. I've submitted it
first to openSUSE Tumbleweed. The package is staged and everything depending
on it gets automatically rebuilt. This allows you to figure out what might
break.
There was only one package which was failing and that was multipath-tools. The
Fedora package of multipath-tools doesn't have a %check sections so it doesn't
depend on cmocka and will not run into any issues.
However with multipath-tools failing to build, bugfixes have been implemented
after 2.0.0 and that resulted in the release of version 2.0.1.
It is still possible that there is a Fedora package which might run into
issues with the tests when building. If that should be the case, feel free to
contact me. However I don't really expect it.
Details:
https://blog.cryptomilk.org/2025/12/04/cmocka-2-0-released-enhancing-unit-t…
Best regards
Andreas
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
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 -