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
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
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
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
> >
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
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
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*
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
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
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
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
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://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:
> >
> > >
> > >
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
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
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
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
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
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
19 matches
Mail list logo
