Dear all,
Now that F38 is branched, it's probably a good time to upgrade lua-
posix from 35.1 to 36.1.
Packages potentially affected:
❯ rpmdistro-repoquery fedora rawhide --whatrequires lua-posix
Last metadata expiration check: 0:02:18 ago on Thu Feb 9 13:15:29
2023.
Lmod-0:8.7.18-1.fc38.x86_64
copy-jdk-configs-0:4.1-2.fc38.noarch
lua-readline-0:3.2-2.fc38.x86_64
There are some breaking changes in 36.0, so I'm going to only update in
Rawhide and we can revisit if we need to update in 38 and stable
branches later, but I tend towards keeping them at 35.1 unless there's
a major issue we can't fix without upgrading.
https://github.com/luaposix/luaposix/releases
Incompatible Changes
posix.spawn always returns integer, string whether fork fails
immediately, or whatever waiting for the spawned process reports. When
the second result value is "exited", the first is the exit status; for
"killed" or "stopped" second value, the first is the signal number that
caused it; otherwise first the errno error number, followed by the
associated error string.
The documentation for posix.spawn has always been wrong up until
now, but this small change to simplify the returned results will
require checking whether the second result value is "exited", "killed",
"stopped" or any other string before interpreting the first result...
which was also necessary in prior versions too, but now the
interpretion of non-zero status by clients is less messy and somewhat
compatible with the happy path of using previous releases.
Argument type errors for posix.sys.msg.msgctl,
posix.sys.resource.setrlimit, posix.sys.socket.bind,
posix.sys.socket.connect, posix.sys.socket.getaddrinfo,
posix.sys.socket.sendto and posix.time.nanosleep all use "integer" in
full rather than "int".
Best regards,
--
Michel Alexandre Salim
identities:
https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
Hi all,
lua-filesystem has not been properly updated since 2015; we missed the
1.7.0 release in 2017 and the 1.8.0 release in April last year.
The changelogs seem to indicate this should be backward-compatible, but
if your package depends on the `lfs` module please test:
F32 https://bodhi.fedoraproject.org/updates/FEDORA-2021-aa4f097cbf
F33 https://bodhi.fedoraproject.org/updates/FEDORA-2021-01aeb6cf2b
This package is already in RHEL so there's no EPEL updates, but the
updated spec has been tested on EPEL8 as well.
Dependent packages:
```
❯ sudo dnf repoquery --whatrequires lua-filesystem
Lmod-0:8.4.1-1.fc33.x86_64
corsix-th-0:0.64-5.fc33.x86_64
lua-moonscript-0:0.5.0-6.fc33.noarch
lua-penlight-0:1.9.2-1.fc33.noarch
prosody-0:0.11.7-1.fc33.x86_64
prosody-0:0.11.7-2.fc33.x86_64
wordgrinder-0:0.7.2-6.fc33.x86_64
wordgrinder-0:0.8-1.fc33.x86_64
```
I've kept the stable autokarma to +3 and disabled the auto-promoting by
time to make sure this does not get accidentally promoted.
Thanks to Robert Scheck for helping modernize the spec (and is now co-
maintaining the package). I've further cleaned it up to match what will
be in the upcoming Lua packaging guidelines.
Best regards,
--
Michel Alexandre Salim
profile: https://keyoxide.org/michel@michel-slm.name
Hi all,
Some exciting updates re: Lua packaging
TL;DR we want to simplify the Lua packaging experience as much as
possible, across both Fedora and RHEL.
Some background:
- before RHEL 7, the Lua RPM does not provide "lua(abi) = MAJ.MIN" so a
package that ships Lua modules has to declare this to be safe:
Requires: lua >= MAJ.MIN
Requires: lua < MAJ.(MIN+1)
- we have a draft packaging spec that recommends defining luapkgdir
(noarch) and lualibdir (arched); this was later pre-defined as
lua_pkgdir and lua_libdir in lua-devel in Fedora and RHEL8 -- but
didn't get merged into lua in RHEL < 8.
- there's a %lua_requires macro that automatically generates the right
Requires line. But if it is not present on the system where the SRPM is
regenerated it cannot be used. And lua-devel is not pulled in by
redhat-rpm-config so that means this macro was never used.
- on Fedora >= 33 (and so RHEL >= 9 when it's out) a requires generator
will automatically generate the 'Requires: lua(abi)' line.
- third-party Lua modules are mostly not updated to use these macros,
and worse, EL RPMs can't
On Fri, 2020-08-28 at 19:43 -0700, Michel Alexandre Salim wrote:
>
> I've created a review request for the proposed new macro package
> here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1873676
>
> If this is accepted:
> - we can immediately branch and ship this for EL6 and EL7 so Lua
> packages for those releases can use macros
> - I'll get redhat-rpm-config to pull in lua-srpm-macros, the same way
> it pulls in other *-srpm-macros packages
> - I'll refactor lua in Fedora so lua-devel pulls in lua-rpm-macros
> rather than shipping macros.lua, then enable shipping macros.lua in
> lua-rpm-macros (right now it's excluded on Fedora to avoid file
> conflicts)
>
lua-rpm-macros is now live in Rawhide, and lua-5.4.0-7.fc34 requires
that package if rpm-build is installed.
spot is pushing a security update for Lua in F33, so the change is not
out yet on that release (I've merged in the changes from master though,
so lua-rpm-macros + lua-5.4.0-8.fc33 will have them).
I've also built lua-rpm-macros for EL6, EPEL7 and EPEL8 (on EPEL8 it
only generates lua-srpm-macros since macros.lua is already shipped by
lua-devel, and we can't refactor that easily as it's part of RHEL
Base):
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-1ced3b21fbhttps://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-f54c46aaf2https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-97b6a71d6d
Next step is to have redhat-rpm-config depend on lua-srpm-macros
(needed especially so that on Fedora < 33 and RHEL, we can use the
%lua_requires macro to automatically generate the right runtime
Requires: on the right Lua version).
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/105
One thing I'm not sure about is how to get redhat-rpm-config fixed for
stable releases (F31, F32). redhat-rpm-config normally gets updated by
bumping the version, but presumably cherry-picking this one change is
better than shipping the latest redhat-rpm-config on stable releases?
Also -- any idea how to get lua-srpm-macros available in the Koji
builders for EL6, EPEL7 and EPEL8? Presumably we can't touch redhat-
rpm-config there.
> I'll also look at creating an official SIG including having a mailing
> list.
>
The mailing list has been created (cc: ed on this post). I'd welcome
anyone interested in Lua packaging, especially those who maintains core
Lua packages, to subscribe to lua(a)lists.fedoraproject.org.
Best regards,
--
Michel Alexandre Salim
profile: https://keyoxide.org/michel@michel-slm.name
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2