Bug#1012362: transition: luajit
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. On Mon, 2022-06-20 at 22:10 +0200, Paul Gevers wrote: > Hi Mo, > > On 13-06-2022 05:20, M. Zhou wrote: > > So let's inform the reverse dependencies to remove ppc64el support, > > or switch back to lua. > > Just curious, have you already done so? If yes, care to share the bug > 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 > > --- 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.
Bug#1012362: transition: luajit
Hi Mo, On 13-06-2022 05:20, M. Zhou wrote: So let's inform the reverse dependencies to remove ppc64el support, or switch back to lua. Just curious, have you already done so? If yes, care to share the bug 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 --- 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. OpenPGP_signature Description: OpenPGP digital signature
Bug#1012362: transition: luajit
On Sun, 12 Jun 2022 20:20:50 -0700 "M. Zhou" wrote: > 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. 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. > The only outcome for this luajit2 transition is that s390x seems > working. That's a new arch for sysbench too. You gain some, you lose some. pgpoosJS0wW_p.pgp Description: OpenPGP digital signature
Bug#1012362: transition: luajit
On Sun, 2022-06-12 at 21:19 +0200, Paul Gevers wrote: > Hi Mo, > > On 10-06-2022 08:00, M. Zhou wrote: > > > There are some compilation flags tweakable. I'll try with > > > qemu to see whether I can make it work. > > > > 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. > > 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. 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.
Bug#1012362: transition: luajit
Hi Mo, On 10-06-2022 08:00, M. Zhou wrote: There are some compilation flags tweakable. I'll try with qemu to see whether I can make it work. 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. 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 OpenPGP_signature Description: OpenPGP digital signature
Bug#1012362: transition: luajit
On Thu, 2022-06-09 at 21:51 -0700, M. Zhou wrote: > > > 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: ---] > > There are some compilation flags tweakable. I'll try with > qemu to see whether I can make it work. 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.
Bug#1012362: transition: luajit
On Thu, 2022-06-09 at 13:58 +0200, Paul Gevers wrote: > 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=mipsel=1.13%2Bdfsg-1%2Bb2=1654771416=0 Yunqiang Su (@syq) volunteers to look into luajit issues on mips* architecture.
Bug#1012362: transition: luajit
On Thu, 2022-06-09 at 10:47 +0200, Paul Gevers wrote: > > 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]: > > > 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. > Yes. The libluajit-5.1-common has conflicts. Fixed in git: https://salsa.debian.org/lua-team/luajit/-/commit/0489ec840f2ab240785ecd8190962cb779858c29 > 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: ---] There are some compilation flags tweakable. I'll try with qemu to see whether I can make it work.
Bug#1012362: transition: luajit
Hi Mo, On 09-06-2022 13:58, Paul Gevers wrote: You may want to look at the FTBFS on mipsel for python-lupa. https://buildd.debian.org/status/fetch.php?pkg=python-lupa=mipsel=1.13%2Bdfsg-1%2Bb2=1654771416=0 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=ppc64el=1.0.20%2Bds-4=1654765356=0 OpenPGP_signature Description: OpenPGP digital signature
Bug#1012362: transition: luajit
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=mipsel=1.13%2Bdfsg-1%2Bb2=1654771416=0 Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1012362: transition: luajit
Hi Mo, On 08-06-2022 16:16, M. Zhou wrote: 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 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 OpenPGP_signature Description: OpenPGP digital signature
Bug#1012362: transition: luajit
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. On Tue, 2022-06-07 at 22:28 -0700, M. Zhou wrote: > 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? > > On Tue, 2022-06-07 at 20:37 -0700, M. Zhou wrote: > > On Tue, 2022-06-07 at 20:03 -0700, M. Zhou wrote: > > > > > > > > > > > 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. > > > > > > 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 > > > * ... > > > > > > > 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 > > 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 > > 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 > > 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 > > 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:
Bug#1012362: transition: luajit
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? On Tue, 2022-06-07 at 20:37 -0700, M. Zhou wrote: > On Tue, 2022-06-07 at 20:03 -0700, M. Zhou wrote: > > > > > > > > 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. > > > > 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 > > * ... > > > > 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 > 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 > 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 > 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 > 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 > 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 > Installed-Size: 218 > Conflicts: libluajit2-5.1-common > Replaces: libluajit2-5.1-common > >
Bug#1012362: transition: luajit
On Tue, 2022-06-07 at 20:03 -0700, M. Zhou wrote: > > > > > 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. > > 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 > * ... > 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 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 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 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 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 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 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 Installed-Size: 15 Depends: libluajit2-5.1-dev
Bug#1012362: transition: luajit
On Tue, 2022-06-07 at 21:21 +0200, Paul Gevers wrote: > Hi Mo, > > On 07-06-2022 17:36, M. Zhou wrote: > > This should be achievable by patching debian/control > > during build once detected IBM architectures. > > 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 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 > > IIRC adding new architecture without new binary package > > does not have to go through NEW. > > Indeed, they don't. > > > Does that sound good? > > 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. 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 * ... > 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. > """ Thanks. I was not aware of this.
Bug#1012362: transition: luajit
Hi Mo, On 07-06-2022 17:36, M. Zhou wrote: This should be achievable by patching debian/control during build once detected IBM architectures. 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. IIRC adding new architecture without new binary package does not have to go through NEW. Indeed, they don't. Does that sound good? 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. """ OpenPGP_signature Description: OpenPGP digital signature
Bug#1012362: transition: luajit
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. On Mon, 2022-06-06 at 20:45 +0200, Paul Gevers wrote: > Control: tag -1 confirmed > Control: forwarded -1 > https://release.debian.org/transitions/html/libluajit2-support.html > > Hi Mo, > > On 05-06-2022 19:30, M. Zhou wrote: > > 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. > > Please go ahead. > > Paul
Bug#1012362: transition: luajit
Control: tag -1 confirmed Control: forwarded -1 https://release.debian.org/transitions/html/libluajit2-support.html Hi Mo, On 05-06-2022 19:30, M. Zhou wrote: 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. Please go ahead. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1012362: transition: luajit
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition This bug is follow-up for this thread: https://lists.debian.org/debian-release/2022/06/msg9.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/561f846d9c845876715eef086aeb9ff0fd80
