- Package:
- release.debian.org
- Source:
- release.debian.org
- Submitter:
- "M. Zhou"
- Date:
- 2022-07-12 20:03:03 UTC
- Severity:
- normal
- Tags:
This bug is follow-up for this thread: https://lists.debian.org/debian-release/2022/06/msg00009.html The original LuaJIT upstream does not care about IBM architectures, which causes problem in downstreams including us. I packaged src:luajit2 which seems to be working well for IBM architectures. src:luajit2 can be used as a drop-in replacement for src:luajit. So, currently I have a pending commit[2] modifying the dependency template[1], so that src:luajit reverse dependencies can be rebuilt without source modification to allow library fallback. Specifically, before transition, luajit reverse dependencies will have: Depends: libluajit-5.1-2 After transition, they should have: Depends: libluajit-5.1-2 | libluajit2-5.1-2 And the only thing we need to do is to upload the pending commit[2] once approved. Then we just trigger a rebuild for all luajit reverse dependencies. This is a special transition that should not break any package at all, as it is just inserting an alternative dependency. (I don't know how to write a correct ben file for such special case.) Ben file: title = "luajit"; is_affected = .depends ~ "libluajit-5.1-2" | .depends ~ "libluajit-5.1-2"; is_good = .depends ~ "libluajit2-5.1-2"; is_bad = .depends ~ "libluajit-5.1-2"; Thank you for using reportbug [1] deb-symbols(5), this is an less-known advanced usage. [2] https://salsa.debian.org/lua-team/luajit/-/commit/561f846d9c84587ffff6715eef086aeb9ff0fd80
Hi Mo, Please go ahead. Paul
I have uploaded luajit/unstable 2.1.0~beta3+git20210112+dfsg-2, but please hold on. I should have split the ppc64el architecture removal to a future revision... Now that the ppc64el architecture is missing for src:luajit, and we still cannot safely remove luajit:ppc64el without manually changing their build depends into libluajit2-5.1-2 [ppc64el s390x] | libluajit-5.1-2 ... I'm thinking of yet another solution for the IBM architecture transition. It's to add ppc64el and s390x back into src:luajit, but make all binary packages transitional dummy packages, i.e. Package: libluajit-5.1-2 Architecture: ppc64el s390x Depends: libluajit2-5.1-2 Description: transitional dummy package This should be achievable by patching debian/control during build once detected IBM architectures. IIRC adding new architecture without new binary package does not have to go through NEW. So this architecture-specific transitional dummy package solution should be able to help us smoothly deal with IBM architectures. Does that sound good? If so I'll prepare another upload before we really start the transition.
Hi Mo, This is not allowed. I currently fail to find where that's written down, but I'm fairly sure that the relevant parties agree that debian/control must not be mangled with during build. The ftp-reject list touches upon it, albeit for a different reason [1]. debian/control has to be unchanged in source. But, maybe you can try to add two stanza's for the same binary name, one with the Archs !s390x !ppc64el and another for s390x and ppc64el. I'm not totally sure if that's allowed and if the tools handle it well, but may be worth a try. Indeed, they don't. Yes, except for the part about patching d/control. We'll have to find another way. An alternative to what I wrote before is a extension of the description to say that the binary is empty on s390x and ppc64el. Paul [1] https://ftp-master.debian.org/REJECT-FAQ.html : debian/control breakage #2 """ which basically means that everything must be defined at the beginning of the build. """
Indeed that's not allowed, although I should have seen some of such examples years ago IIRC. Apart from that, additional binary package entry with different architecture will be deemed as duplicate: dh: error: debian/control has a duplicate entry for luajit So both patching control and double stanza do not work. Currently the only solution that I can think of is to upload a NEW empty dummy source package: src:luajit-ibm-transition * bin:luajit Architecture: ppc64el s390x Depends: luajit2 * ... Thanks. I was not aware of this.
I realized that the solution is very simple. I can simply re-enable ppc64el s390x, and install nothing into the binary packages. Simple tweak on Depends/Conclicts/Replaces should be enough: https://salsa.debian.org/lua-team/luajit/-/commit/0cc94e0caf8f78568c42c8fdf8db0c34766710fa I built the package locally, and additionally with sbuild/qemu ppc64el. See following the trimmed debc information. I'm uploading this revision shortly. ===================================================================== libluajit-5.1-2_2.1.0~beta3+git20220320+dfsg-2_amd64.deb -------------------------------------------------------- new Debian package, version 2.0. size 256424 bytes: control archive=1760 bytes. 833 bytes, 20 lines control 240 bytes, 3 lines md5sums 66 bytes, 1 lines shlibs 4702 bytes, 148 lines symbols 67 bytes, 2 lines triggers Package: libluajit-5.1-2 Source: luajit Version: 2.1.0~beta3+git20220320+dfsg-2 Architecture: amd64 Maintainer: Debian Lua Team <pkg-lua-devel@lists.alioth.debian.org> Installed-Size: 581 Depends: libluajit-5.1-common (= 2.1.0~beta3+git20220320+dfsg-2), libc6 (>= 2.29), libgcc-s1 (>= 3.3) Conflicts: libluajit2-5.1-2 Replaces: libluajit2-5.1-2 libluajit-5.1-common_2.1.0~beta3+git20220320+dfsg-2_all.deb ----------------------------------------------------------- new Debian package, version 2.0. size 49592 bytes: control archive=1104 bytes. 523 bytes, 15 lines control 1503 bytes, 19 lines md5sums Package: libluajit-5.1-common Source: luajit Version: 2.1.0~beta3+git20220320+dfsg-2 Architecture: all Maintainer: Debian Lua Team <pkg-lua-devel@lists.alioth.debian.org> Installed-Size: 218 Conflicts: libluajit2-5.1-common Replaces: libluajit2-5.1-common libluajit-5.1-dev_2.1.0~beta3+git20220320+dfsg-2_amd64.deb ---------------------------------------------------------- new Debian package, version 2.0. size 275064 bytes: control archive=916 bytes. 537 bytes, 16 lines control 710 bytes, 10 lines md5sums Package: libluajit-5.1-dev Source: luajit Version: 2.1.0~beta3+git20220320+dfsg-2 Architecture: amd64 Maintainer: Debian Lua Team <pkg-lua-devel@lists.alioth.debian.org> Installed-Size: 771 Depends: libluajit-5.1-2 (= 2.1.0~beta3+git20220320+dfsg-2) Conflicts: libluajit2-5.1-dev Replaces: libluajit2-5.1-dev luajit_2.1.0~beta3+git20220320+dfsg-2_amd64.deb ----------------------------------------------- new Debian package, version 2.0. size 262800 bytes: control archive=888 bytes. 857 bytes, 19 lines control 254 bytes, 4 lines md5sums Package: luajit Version: 2.1.0~beta3+git20220320+dfsg-2 Architecture: amd64 Maintainer: Debian Lua Team <pkg-lua-devel@lists.alioth.debian.org> Installed-Size: 592 Depends: libluajit-5.1-2 (= 2.1.0~beta3+git20220320+dfsg-2), libluajit-5.1-common (= 2.1.0~beta3+git20220320+dfsg-2), libc6 (>= 2.29), libgcc-s1 (>= 3.3) Conflicts: luajit2 Replaces: luajit2 ====================================================================== libluajit-5.1-2_2.1.0~beta3+git20220320+dfsg-2_ppc64el.deb ---------------------------------------------------------- new Debian package, version 2.0. size 7584 bytes: control archive=780 bytes. 703 bytes, 18 lines control 158 bytes, 2 lines md5sums Package: libluajit-5.1-2 Source: luajit Version: 2.1.0~beta3+git20220320+dfsg-2 Architecture: ppc64el Maintainer: Debian Lua Team <pkg-lua-devel@lists.alioth.debian.org> Installed-Size: 15 Depends: libluajit2-5.1-2 libluajit-5.1-common_2.1.0~beta3+git20220320+dfsg-2_all.deb ----------------------------------------------------------- new Debian package, version 2.0. size 49592 bytes: control archive=1104 bytes. 523 bytes, 15 lines control 1503 bytes, 19 lines md5sums Package: libluajit-5.1-common Source: luajit Version: 2.1.0~beta3+git20220320+dfsg-2 Architecture: all Maintainer: Debian Lua Team <pkg-lua-devel@lists.alioth.debian.org> Installed-Size: 218 Conflicts: libluajit2-5.1-common Replaces: libluajit2-5.1-common libluajit-5.1-dev_2.1.0~beta3+git20220320+dfsg-2_ppc64el.deb ------------------------------------------------------------ new Debian package, version 2.0. size 7444 bytes: control archive=636 bytes. 447 bytes, 14 lines control 162 bytes, 2 lines md5sums Package: libluajit-5.1-dev Source: luajit Version: 2.1.0~beta3+git20220320+dfsg-2 Architecture: ppc64el Maintainer: Debian Lua Team <pkg-lua-devel@lists.alioth.debian.org> Installed-Size: 15 Depends: libluajit2-5.1-dev luajit_2.1.0~beta3+git20220320+dfsg-2_ppc64el.deb ------------------------------------------------- new Debian package, version 2.0. size 7556 bytes: control archive=760 bytes. 684 bytes, 17 lines control 140 bytes, 2 lines md5sums Package: luajit Version: 2.1.0~beta3+git20220320+dfsg-2 Architecture: ppc64el Maintainer: Debian Lua Team <pkg-lua-devel@lists.alioth.debian.org> Installed-Size: 15 Depends: luajit2
https://buildd.debian.org/status/package.php?p=luajit All green, including ppc64el and s390x (arch-specific transitional dummy package) Seems we are ready to start the rebuild?
https://qa.debian.org/excuses.php?package=luajit autopkgtest on ibm archs encountered somewhat regression, since I only removed Conflicts+Replaces from the src:luajit side. I fixed this issue and uploaded src:luajit2 https://salsa.debian.org/lua-team/luajit2/-/commit/12818940efdf76cf48b8e2cfea2dfaa5dc11664a luajit2 (2.1-20220411-5) unstable Now it should be fine after several hours when we retry the autopkgtest.
Hi Mo,
I think there one more *test* issue, the first test in src:luajit
doens't explicitly declare dependencies, which means it implicitly has
has '@'. Quoting [1]:
``@`` stands for the package(s) generated by the source package
containing the tests; each dependency (strictly, or-clause, which
may contain ``|``\ s but not commas) containing ``@`` is replicated
once for each such binary package, with the binary package name
substituted for each ``@`` (but normally ``@`` should occur only
once and without a version restriction).
Which means that autopkgtest asks apt to make sure all packages from
src:luajit are installed, but the dependency tree of bin:luajit
conflicts with some. This can be solved by only depending on luajit, as
that pulls in the required packages anyways.
lua-moses autopkgtest failure [2] looks bad (still a segmentation fault):
autopkgtest [07:20:14]: test command9: luajit debian/tests/simple.lua
autopkgtest [07:20:14]: test command9: [-----------------------
bash: line 1: 1240 Segmentation fault bash -ec 'luajit
debian/tests/simple.lua' 2> >(tee -a
/tmp/autopkgtest-lxc.u7chaju_/downtmp/command9-stderr >&2) > >(tee -a
/tmp/autopkgtest-lxc.u7chaju_/downtmp/command9-stdout)
autopkgtest [07:20:14]: test command9: -----------------------]
Paul
[1]
https://salsa.debian.org/ci-team/autopkgtest/-/raw/master/doc/README.package-tests.rst
[2]
https://ci.debian.net/data/autopkgtest/testing/ppc64el/l/lua-moses/22519476/log.gz
Hi Mo, You may want to look at the FTBFS on mipsel for python-lupa. https://buildd.debian.org/status/fetch.php?pkg=python-lupa&arch=mipsel&ver=1.13%2Bdfsg-1%2Bb2&stamp=1654771416&raw=0 Paul
Hi Mo, The maintainer of sysbench switched to luajit2 completely. The package FTBFS [1] on ppc64el though as it triggers SEGFAULTs in it's tests. + /bin/bash: line 2: 1941783 Segmentation fault sysbench $SBTEST_SCRIPTDIR/oltp_read_write.lua help + [139] Paul https://buildd.debian.org/status/fetch.php?pkg=sysbench&arch=ppc64el&ver=1.0.20%2Bds-4&stamp=1654765356&raw=0
https://salsa.debian.org/lua-team/luajit/-/commit/0489ec840f2ab240785ecd8190962cb779858c29 There are some compilation flags tweakable. I'll try with qemu to see whether I can make it work.
Yunqiang Su (@syq) volunteers to look into luajit issues on mips* architecture.
I tried to tweak some compilation flags, and did not manage to make it work on ppc64el (qemu), even if I use the -DLUAJIT_DISABLE_JIT macro. Segfault persists. So src:luajit2 is still seemingly badly broken for ppc64el.
Hi Mo, Do you have a proposal how to continue? If you believe this can be fixed soon (with help from upstream?) I'm OK with trying, but otherwise we should inform the reverse dependencies on ppc64el that they have to either remove themselves on ppc64el or switch to lua if that works for them too. I don't want this lingering for months. src:luajit is out-of-sync between testing and unstable since January already. Paul
After browsing the corresponding github issues I think there is virtually nobody working on the ppc64el port. And I don't have any idea on how to fix it. So let's inform the reverse dependencies to remove ppc64el support, or switch back to lua. The only outcome for this luajit2 transition is that s390x seems working.
Looking at the buildlogs for sysbench, running the upstream testsuite triggers (apparently) identical segfaults for both ppc64el and ppc64, so in all likelihood the latter is also affected by the underlying issue. That's a new arch for sysbench too. You gain some, you lose some.
Hi Mo,
report numbers? Otherwise I assume you expected me to file those bugs?
Paul
elbrus@coccia:~$ dak rm --no-action -R --suite testing luajit
--architecture=ppc64elW: -a/--architecture implies -p/--partial.
Will remove the following packages from testing:
libluajit-5.1-2 | 2.1.0~beta3+dfsg-6 | ppc64el
libluajit-5.1-dev | 2.1.0~beta3+dfsg-6 | ppc64el
luajit | 2.1.0~beta3+dfsg-6 | source, ppc64el
Maintainer: Enrico Tassi <gareuselesinge@debian.org>
------------------- Reason -------------------
----------------------------------------------
Checking reverse dependencies...
# Broken Depends:
lua-ljsyscall: lua-ljsyscall
# Broken Build-Depends:
bpfcc: libluajit-5.1-dev
luajit
cantor: libluajit-5.1-dev
dnsjit: libluajit-5.1-dev
luajit
efl: libluajit-5.1-dev
fastnetmon: libluajit-5.1-dev
love: libluajit-5.1-dev
lua-ljsyscall: luajit
nageru: libluajit-5.1-dev
nginx: libluajit-5.1-dev
obs-studio: libluajit-5.1-dev
suricata: libluajit-5.1-dev
uftrace: libluajit-5.1-dev
wrk: libluajit-5.1-dev
luajit
Dependency problem found.
Hi Paul, I did not file the corresponding bugs. According to our workflow, will I or the release team file those bugs? If it is me who should file those bugs, I think the default severity should be serious. When all related bugs are resolved by reverse dependencies, I plan to remove ppc64el architecture from both src:luajit and src:luajit2, so that malfunctional binary packages are no longer built for it.
Hi Mo, Bug were filed and several packages were removed from testing. Nginx was fixed but required luajit to migrate, so that happened today. I'll ask ftp-master to remove the ppc64el binaries now. Paul