>From the buildlogs / testlogs / local tests (ppc64el qemu), it seems that there is completely no improvement for ppc64el. Simple scripts can still encounter segmentation faults (e.g., autopkgtest for src:lua-moses). s390x is newly enabled. I still have not seen enough test log to give any preliminary conclusion.
On Thu, 2022-06-09 at 16:19 +0200, Frédéric Bonnard wrote: > Hi Mo, Paul, > did you see any improvement with luajit2 ? > I was looking at luakit, which still fails "silently" on ppc64el, a lua > script generating a .h with no symbols with luajit2, where it does work > with lua. > Also I see that the autopkgtest of knot-resolver still fails on > ppc64el. > > F. > > On Thu, 19 May 2022 22:14:01 -0400 "M. Zhou" <lu...@debian.org> wrote: > > On Thu, 2022-05-19 at 16:30 +0200, Frédéric Bonnard wrote: > > > Hi, > > > > > > I've followed luajit closely since 2015 on ppc64el as a porter > > > without enough knowledge to port it, but trying to ease on the > > > packaging/Debian side (being both IBMer/DD). > > > That port has been a mixed effort between a code bounty and an IBM > > > effort (some devs) . > > > It didn't started well ( > > > https://www.freelists.org/post/luajit/PPC64le-port-status,1 ) > > > and it has never grown and be really part of the upstream project > > > sadly. > > > > > > With the years, I'm even less optimistic as no IBM nor external > > > developer seem to be working on that. Mike Pall seems to be around > > > though as you said there's no release (not necessarily a bad sign). > > > I can ping inside IBM but I'm not sure there will be any positive > > > feedback. > > > > > > So I'd say we have no choice, i.e. let's drop IBM arches . > > > What I did a few times for packages depending on libluajit was to use > > > liblua instead : > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892765 > > > > > > Thanks, > > > F. > > > > Nobody want to spend time on an bottomless hole ... > > I'll simply remove ppc64el architecture support from src:luajit, > > and give src:luajit2 (openresty) a try. > >
