Re: needs suggestion on LuaJit's IBM architecture dilemma
>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" 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. > >
Re: needs suggestion on LuaJit's IBM architecture dilemma
Hi Frédéric, On 09-06-2022 16:19, Frédéric Bonnard wrote: did you see any improvement with luajit2 ? Improvements, yes. All fixed, no. 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. See also https://bugs.debian.org/1012362. Best to have the conversation there. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: needs suggestion on LuaJit's IBM architecture dilemma
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" 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. > signature.asc Description: PGP signature
Re: needs suggestion on LuaJit's IBM architecture dilemma
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.
Re: needs suggestion on LuaJit's IBM architecture dilemma
Hi Dipack, I filed an ITP bug for luajit2 and will look into it. Thank you! On Mon, 2022-05-16 at 16:22 +, Dipak Zope1 wrote: > Hello all, > It'd be better to switch to luajit2 if it is possible. We can see > right now the main issue with luajit project is no response from > upstream of LuaJIT to previous merge request attempts. And luajit2 > already contains almost everything needed for s390x support. > > Thanks, > -Dipak >
Re: needs suggestion on LuaJit's IBM architecture dilemma
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. On Wed, 11 May 2022 21:29:26 -0400 "M. Zhou" wrote: > Hi folks, > > I learned in disappointment after becoming LuaJit uploader that > the LuaJit upstream behaves uncooperatively especially for IBM > architectures [1]. IIUC, the upstream has no intention to care > about IBM architectures (ppc64el, s390x). > > The current ppc64el support on stable is done through cherry-picked > out-of-tree patch. And I learned that the patch is no longer > functional[2] for newer snapshots if we step away from that > ancient 2.1.0~beta3 release. > > However, architectures like amd64 needs relatively newer version[3], > while IBM architecture still has demand luajit[4] (only the > ancient version will possibly work on IBM archs). > > I'm looking for suggestions on what to do next: > > option 1: > drop IBM architectures that the upstream cannot support > from src:luajit, and provide archs like amd64 with relatively > newer snapshot versions[5]. > and package reliable alternatives (if any) for IBM archs. > option 2: > use latest source for amd64 architecture, and rollback the > source specifically for IBM architectures to keep it > functional. > option 3: > rollback to the ancient stable release and screw it > option 4: > ... > > Thanks. > > [1] https://github.com/LuaJIT/LuaJIT/pull/140 > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004511 > [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981808 > [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008858 > [5] Yes ... the upstream do not release anymore. > signature.asc Description: PGP signature
Re: needs suggestion on LuaJit's IBM architecture dilemma
Hello all, It'd be better to switch to luajit2 if it is possible. We can see right now the main issue with luajit project is no response from upstream of LuaJIT to previous merge request attempts. And luajit2 already contains almost everything needed for s390x support. Thanks, -Dipak From: M. Zhou Date: Thursday, 12 May 2022 at 8:07 AM To: debian-devel Subject: [EXTERNAL] needs suggestion on LuaJit's IBM architecture dilemma Hi folks, I learned in disappointment after becoming LuaJit uploader that the LuaJit upstream behaves uncooperatively especially for IBM architectures [1]. IIUC, the upstream has no intention to care about IBM architectures (ppc64el, s390x). The current ppc64el support on stable is done through cherry-picked out-of-tree patch. And I learned that the patch is no longer functional[2] for newer snapshots if we step away from that ancient 2.1.0~beta3 release. However, architectures like amd64 needs relatively newer version[3], while IBM architecture still has demand luajit[4] (only the ancient version will possibly work on IBM archs). I'm looking for suggestions on what to do next: option 1: drop IBM architectures that the upstream cannot support from src:luajit, and provide archs like amd64 with relatively newer snapshot versions[5]. and package reliable alternatives (if any) for IBM archs. option 2: use latest source for amd64 architecture, and rollback the source specifically for IBM architectures to keep it functional. option 3: rollback to the ancient stable release and screw it option 4: ... Thanks. [1] https://github.com/LuaJIT/LuaJIT/pull/140 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004511 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981808 [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008858 [5] Yes ... the upstream do not release anymore.
Re: needs suggestion on LuaJit's IBM architecture dilemma
Hi! On 5/12/22 03:29, M. Zhou wrote: > I learned in disappointment after becoming LuaJit uploader that > the LuaJit upstream behaves uncooperatively especially for IBM > architectures [1]. IIUC, the upstream has no intention to care > about IBM architectures (ppc64el, s390x). > > The current ppc64el support on stable is done through cherry-picked > out-of-tree patch. And I learned that the patch is no longer > functional[2] for newer snapshots if we step away from that > ancient 2.1.0~beta3 release. > > However, architectures like amd64 needs relatively newer version[3], > while IBM architecture still has demand luajit[4] (only the > ancient version will possibly work on IBM archs). I saw that Matej Cepl was replying in the thread who is a colleague of mine and who is the maintainer of the luajit package in openSUSE/SLE. Since SUSE has a commercial interest in working POWER/S390 support, he takes care of the package and makes sure it keeps working on these architectures. My suggestion would be to just pick the packages from openSUSE [1] since they are kept up-to-date. Adrian > [1] https://build.opensuse.org/package/show/devel:languages:lua/luajit -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
needs suggestion on LuaJit's IBM architecture dilemma
Hi folks, I learned in disappointment after becoming LuaJit uploader that the LuaJit upstream behaves uncooperatively especially for IBM architectures [1]. IIUC, the upstream has no intention to care about IBM architectures (ppc64el, s390x). The current ppc64el support on stable is done through cherry-picked out-of-tree patch. And I learned that the patch is no longer functional[2] for newer snapshots if we step away from that ancient 2.1.0~beta3 release. However, architectures like amd64 needs relatively newer version[3], while IBM architecture still has demand luajit[4] (only the ancient version will possibly work on IBM archs). I'm looking for suggestions on what to do next: option 1: drop IBM architectures that the upstream cannot support from src:luajit, and provide archs like amd64 with relatively newer snapshot versions[5]. and package reliable alternatives (if any) for IBM archs. option 2: use latest source for amd64 architecture, and rollback the source specifically for IBM architectures to keep it functional. option 3: rollback to the ancient stable release and screw it option 4: ... Thanks. [1] https://github.com/LuaJIT/LuaJIT/pull/140 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004511 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981808 [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008858 [5] Yes ... the upstream do not release anymore.
