#archlinux32 | Logs for 2023-03-26

Back
[04:49:47] -!- oaken-so1rce has quit [Ping timeout: 260 seconds]
[04:51:43] -!- oaken-source has joined #archlinux32
[05:30:02] -!- iamawacko has quit [Ping timeout: 246 seconds]
[06:33:01] <KitsuWhooa> Is luajit broken again?
[06:33:06] <KitsuWhooa> Or has the package not made it in stable
[06:33:18] <KitsuWhooa> I did a pacman -Syu and I'm getting SIGILL again
[08:28:18] -!- abaumann has joined #archlinux32
[08:28:18] <buildmaster> Hi abaumann!
[08:28:18] <buildmaster> !rq abaumann
[08:28:19] <phrik> buildmaster: <abaumann> I have funny nice ideas again :-)
[08:28:32] <abaumann> KitsuWhooa: duno, I have to test
[08:30:25] <KitsuWhooa> > Build Date: 2023-03-10 12:07:07
[08:30:34] <KitsuWhooa> Maybe the patch isn't being applied at all
[08:31:18] <abaumann> Illegal instruction (core dumped)
[08:31:19] <abaumann> yep
[08:31:25] <abaumann> luajit 2.1.0.beta3.r471.g505e2c03-1.0
[08:31:33] <KitsuWhooa> I assume if the patch was rejected, it wouldn't build, right?
[08:31:47] <KitsuWhooa> s/was rejected/didn't apply/
[08:31:58] <abaumann> rejected sound so.. human.. ;-)
[08:32:02] <abaumann> we wouldn't do that.
[08:32:11] <abaumann> aeh. it's rather some sed-fu going wrong..
[08:32:13] <KitsuWhooa> by rejected I meant upstream changed something
[08:32:19] <KitsuWhooa> and it no longer applied
[08:32:22] <KitsuWhooa> but yeah, that's what's most likely happening
[08:32:34] <KitsuWhooa> either way, if for some reason it doesn't apply, let me know and I'll update it
[08:33:09] <abaumann> ( CARCH=i686; . PKGBUILD ; declare -f build )
[08:33:11] <abaumann> patch -p1 -i "$srcdir/c7815e1a1b49871e645252bb12e722fb4879df11.patch";
[08:33:15] <abaumann> before make
[08:33:17] <abaumann> looks ok.
[08:33:30] <KitsuWhooa> do you have the build log?
[08:33:33] <abaumann> -rw-r--r-- 1 http http 465537 Nov 27 09:54 luakit-2.3.3-1.0-i686.pkg.tar.zst
[08:33:36] <abaumann> -rw-r--r-- 1 http http 310 Nov 27 09:54 luakit-2.3.3-1.0-i686.pkg.tar.zst.sig
[08:33:39] <abaumann> -rw-r--r-- 1 http http 310 Nov 27 09:55 luakit-2.3.3-1.0-pentium4.pkg.tar.zst.sig
[08:33:42] <abaumann> -rw-r--r-- 1 http http 465641 Nov 27 09:55 luakit-2.3.3-1.0-pentium4.pkg.tar.zst
[08:33:45] <abaumann> aha.
[08:33:47] <abaumann> not rebuild on the buildmaster.
[08:33:55] <KitsuWhooa> That's luakit, not luajit though :p
[08:34:04] <abaumann> ahen..
[08:34:16] <abaumann> -rw-r--r-- 1 http http 310 Feb 26 15:59 luajit-2.1.0.beta3.r471.g505e2c03-1.0-i486.pkg.tar.zst.sig
[08:34:19] <abaumann> -rw-r--r-- 1 http http 339828 Feb 26 15:59 luajit-2.1.0.beta3.r471.g505e2c03-1.0-i486.pkg.tar.zst
[08:34:22] <abaumann> -rw-r--r-- 1 http http 310 Mar 7 12:25 luajit-2.1.0.beta3.r471.g505e2c03-1.0-pentium4.pkg.tar.zst.sig
[08:34:25] <abaumann> -rw-r--r-- 1 http http 338840 Mar 7 12:25 luajit-2.1.0.beta3.r471.g505e2c03-1.0-pentium4.pkg.tar.zst
[08:34:29] <abaumann> -rw-r--r-- 1 http http 310 Mar 10 10:07 luajit-2.1.0.beta3.r471.g505e2c03-1.0-i686.pkg.tar.zst.sig
[08:34:32] <abaumann> -rw-r--r-- 1 http http 338803 Mar 10 10:07 luajit-2.1.0.beta3.r471.g505e2c03-1.0-i686.pkg.tar.zst
[08:34:35] <abaumann> looks recent enough.
[09:01:46] <abaumann> You don't see much, when rebuilding. I have a SIGILL now here:
[09:01:46] <abaumann> 0xb7f6f273 in lua_newstate () from /usr/lib/libluajit-5.1.so.2
[09:01:46] <abaumann> => 0xb7f6f273 <lua_newstate+211>: 66 0f d4 c8 paddq %xmm0,%xmm1
[09:08:35] <KitsuWhooa> abaumann: I doubt anything significant changed in the code to cause it
[09:08:37] <KitsuWhooa> https://github.com
[09:08:57] <KitsuWhooa> none of that seems like it'd cause this
[09:09:36] <KitsuWhooa> I'll try building it manually
[09:10:36] <KitsuWhooa> Hmmm, this doesn't look good https://tasossah.com
[09:18:40] <KitsuWhooa> It's definitely a packaging/sed issue. I just built luajit-2.1.0.beta3.r471.g505e2c03-1-i686.pkg.tar.zst and it works
[09:25:19] <KitsuWhooa> abaumann: I see the issue. You included the wrong patch. https://git.archlinux32.org
[09:25:20] <phrik> Title: c7815e1a1b49871e645252bb12e722fb4879df11.patch « luajit « community - packages - Archlinux32 package modifications (at git.archlinux32.org)
[09:26:02] <KitsuWhooa> That one is supposed to just be https://github.com
[09:27:52] <KitsuWhooa> When I sent that patch initially via email, it was so that you git am it :p
[09:43:33] <abaumann> i'll try again. :-)
[10:34:52] <abaumann> the systemd thing looks like an unsupported ioctl in a time64 in a function on 32-bit kernels
[10:35:00] <abaumann> no, this doesn't look good
[10:37:01] <abaumann> I added your patchfile now in the luajit build, but there is no difference
[10:46:44] <KitsuWhooa> is it being applied at all?
[10:47:02] <abaumann> in PKGBUILD it's built with amalg
[10:47:14] <abaumann> sounds like amalgamtion, maybe, the patch is ignore then?
[10:47:35] <KitsuWhooa> I don't think it matters
[10:47:39] <KitsuWhooa> amalgamation is basically primitive LTO
[10:47:44] <KitsuWhooa> it concats every single file into one and compiles it
[10:55:55] <KitsuWhooa> abaumann: I just built the package exactly as-is and it works for me :p
[10:56:41] <KitsuWhooa> I took the upstream PKGBUILD, s/x86_64/i686/, cat upstream arch32 > PKGBUILD, makepkg
[10:57:59] <KitsuWhooa> https://tasossah.com
[10:58:00] <phrik> Title: luajit build log (at tasossah.com)
[10:59:28] <KitsuWhooa> So either the patch isn't being applied correctly, or it's because you're building on amd64 without the right flags
[10:59:29] <KitsuWhooa> hmmm
[11:09:46] <abaumann> At least the i486 version should be built on a 486 VM
[11:38:54] <abaumann> https://git.archlinux32.org
[11:38:56] <phrik> Title: PKGBUILD « luajit « community - packages - Archlinux32 package modifications (at git.archlinux32.org)
[11:39:00] <abaumann> https://git.archlinux32.org
[11:39:01] <phrik> Title: c7815e1a1b49871e645252bb12e722fb4879df11.patch « luajit « community - packages - Archlinux32 package modifications (at git.archlinux32.org)
[11:39:07] <abaumann> is that the correct version?
[11:39:45] <abaumann> I moved patching from build to prepare
[11:40:14] <abaumann> When you say, it works. Is this a real machine or a VM?
[12:33:43] <KitsuWhooa> real pentium 3 :p
[12:33:54] <KitsuWhooa> but built in a vm
[12:47:46] <KitsuWhooa> I can send you the built package if you want to test it yourself
[13:37:32] <KitsuWhooa> either way https://tasossah.com
[13:37:39] <KitsuWhooa> if that helps somehow
[13:37:48] <KitsuWhooa> 854afa455d44ef666762bbd5e56e44d1f923276813c3d1c4756cdcc902ea5d76
[14:54:24] <abaumann> he, thanks a lot, at least I can see, if this package runs on my real pentium 3. :-)
[14:55:08] <KitsuWhooa> I'm confident it'll run :p
[14:56:05] <KitsuWhooa> Where can I find the build logs?
[14:56:29] <abaumann> https://buildmaster.archlinux32.org
[14:56:30] <phrik> Title: Index of /build-logs (at buildmaster.archlinux32.org)
[14:56:46] <abaumann> but I'm not sure whether we keep "successful" builds. :-)
[14:57:37] <KitsuWhooa> https://buildmaster.archlinux32.org seems like this one is it
[14:57:47] <KitsuWhooa> oh
[14:57:48] <KitsuWhooa> namcap
[14:57:50] <KitsuWhooa> lol
[14:58:00] <KitsuWhooa> nevermind
[14:58:17] <KitsuWhooa> I see. So there's no way to see the logs for successful builds :p
[15:01:13] <abaumann> work. damit.
[15:01:15] <abaumann> ;-)
[15:07:27] <abaumann> aha, I was teseting my package only on i486
[15:09:17] <bill-auger> abaumann: any tip you may be able to give me about this error i get compiling linux?
[15:09:22] <bill-auger> zstd: error 11 : Allocation error : not enough memory
[15:09:32] <abaumann> yep.
[15:09:39] <abaumann> try some ultra -19 patching
[15:09:40] <KitsuWhooa> abaumann: I never tested i486
[15:09:47] <abaumann> where does it happen?
[15:09:52] <bill-auger> the arm and x86_64 buit with no problem - i686 gave that error
[15:10:09] <KitsuWhooa> I do not have an i486 machine readily available, but qemu might be able to do it
[15:10:28] <abaumann> KitsuWhooa: my point is: the i686 version might work jhust fine.
[15:10:34] <KitsuWhooa> it didn't work for me though
[15:10:34] <abaumann> i486 might need some patching.
[15:10:44] <KitsuWhooa> in theory i486 should be fine as it's using x87 math
[15:10:45] <abaumann> lemme see on a real "i686"
[15:10:49] <abaumann> true
[15:10:54] <KitsuWhooa> pentium4?
[15:10:57] <KitsuWhooa> pentium4 will work fine
[15:11:11] <bill-auger> honestly i dont know - i have not compiled the kernel too many times - here is the log https://termbin.com
[15:14:13] <KitsuWhooa> abaumann: luajit-2.1.0.beta3.r471.g505e2c03-1.1-i686.pkg.tar.zst runs fine for me on Pentium 3
[15:14:17] <KitsuWhooa> from staging
[15:14:42] <KitsuWhooa> Also, I'm sure my patch adds -msse
[15:14:50] <KitsuWhooa> you might want to remove it
[15:14:51] <abaumann> it does? yes. but that one has no patching and uses SSE2 and this is suyppose to work
[15:15:17] <KitsuWhooa> There's no way it works without being patched
[15:15:37] <KitsuWhooa> I'm 100% sure that package contains the patch
[15:16:16] <KitsuWhooa> the package is smaller because my patch completely prevents the JIT from being built
[15:17:12] <KitsuWhooa> When upgrading from community to community-staging: -0,22 MiB
[15:18:12] <abaumann> aha.
[15:18:17] <abaumann> my package also works on 686
[15:18:18] <abaumann> :-)_
[15:18:22] <abaumann> So, it's 486..
[15:18:31] <abaumann> ..which has a problem
[15:18:52] <KitsuWhooa> I never tested 486, but as I said, -march=i686 and -msse
[15:19:16] <KitsuWhooa> -CCOPT_x86= -march=i686 -msse -msse2 -mfpmath=sse
[15:19:18] <KitsuWhooa> +CCOPT_x86= -march=i686 -msse -mfpmath=sse
[15:19:25] <KitsuWhooa> try tweaking those for i486
[15:19:31] <abaumann> ah. ok.
[15:19:41] <abaumann> then I understand the xmm registers I see on 486.
[15:19:50] <KitsuWhooa> Yeah, it uses SSE, just not SSE2
[15:19:59] <abaumann> I added yoyr patch also for CARCH=i486, that
[15:20:04] <abaumann> 's why I got confused
[15:20:16] <KitsuWhooa> would pentium2 count as i486?
[15:20:30] <abaumann> mmh, no. should be 686
[15:20:44] <abaumann> I'm unlucky to have old AMDs (geode, Duran)
[15:20:45] <abaumann> etc.
[15:20:58] <abaumann> those are in theory 686, in practice not, so I have to resort to 486
[15:21:09] <KitsuWhooa> my geode runs i686 just fine :p
[15:21:12] <KitsuWhooa> same for the Duron
[15:21:19] <abaumann> maybe I can also go back to a pre 2.x (a 1.x version) of luajit.
[15:21:55] <KitsuWhooa> qemu seems to have a cpu called "486"
[15:21:57] <KitsuWhooa> I can try testing that
[15:22:23] <KitsuWhooa> so i486 assumes no x87?
[15:22:37] <KitsuWhooa> because without x87 there's no way luajit will ever work, and I don't think it worked before either
[15:23:05] <abaumann> 486 usually have x87
[15:23:12] <abaumann> unless they are a 486SX
[15:23:17] <KitsuWhooa> thought so
[15:23:28] <abaumann> so using x87 fpu is fine.
[15:23:41] <abaumann> just fpmath=sse is not good on 486 :-)
[15:24:15] <abaumann> but it makes perfect sense on a pentium ii. the only trouble are machines in between with might have mmx, 3dnow, but usually no sse
[15:34:10] <KitsuWhooa> qemu: uncaught target signal 4 (Illegal instruction) - core dumped
[15:34:12] <KitsuWhooa> nope
[15:34:22] <abaumann> 686?
[15:34:36] <KitsuWhooa> 486
[15:34:38] <KitsuWhooa> 686 works fine
[15:34:49] <abaumann> ah. yea 486 uses a xmm register
[15:35:00] <KitsuWhooa> I tried with -march=i486
[15:37:13] <KitsuWhooa> It's failing at a cmove
[15:38:36] <KitsuWhooa> seems to be a pentium pro instruction
[15:41:12] <abaumann> oh.
[15:42:38] <KitsuWhooa> qemu-i386 -g 1234 -cpu 486 ./luajit
[15:42:48] <KitsuWhooa> that's how I tested it
[15:43:10] <abaumann> cmov sounds reasonable, as my geode has cmov
[15:43:14] <abaumann> but misses other stuff
[15:46:02] <KitsuWhooa> -cpu pentium fails in the same place
[15:46:04] <KitsuWhooa> >0xfe776096 cmove %ecx,%edx
[15:46:21] <KitsuWhooa> I can send you the binary if you want to try it
[15:46:25] <KitsuWhooa> I don't have it packaged though
[15:46:54] <KitsuWhooa> -cpu pentium2 runs
[15:47:11] <KitsuWhooa> and it calculates 0.4+0.5 :p
[15:49:45] <KitsuWhooa> https://tasossah.com
[15:49:48] <KitsuWhooa> 360907a72bdeef250860c5f38de055aed57d02f2bd1808061243be35575379c9
[15:50:19] <abaumann> oh , thanks.
[15:52:20] <abaumann> => 0x004046e0 <_start+0>: f3 0f 1e fb endbr32
[15:52:22] <abaumann> oh.
[15:52:34] <abaumann> that's new, so it has branch mitigation code in it :-)
[15:52:41] <KitsuWhooa> oh uhhhhh
[15:52:45] <KitsuWhooa> whoops
[15:52:59] <abaumann> I had it recenytly even when building busybox and musl for a 486 floppy..
[15:53:08] <abaumann> ..this could easily also be a problem in the toolchain.
[15:53:31] <KitsuWhooa> I built it on my desktop, soooo
[15:53:34] <KitsuWhooa> let me try in my i686 vm
[15:55:40] <KitsuWhooa> my 686 vm has those too
[15:56:09] <KitsuWhooa> https://gcc.gnu.org
[15:56:12] <phrik> Title: 98667 – gcc generates endbr32 invalid opcode on -march=i486 (at gcc.gnu.org)
[15:57:05] <abaumann> Yeah, remember that. But I thought I fiddled with those CET flags in binutils, gcc
[15:57:27] <KitsuWhooa> I do not have a 486 setup anywhere
[15:57:30] <KitsuWhooa> so I guess I can't build for it
[15:57:35] <abaumann> no worries.
[15:57:46] <abaumann> there is much more wrong on 486 before I'll get to luajit.. :-)
[15:57:51] <KitsuWhooa> true, but still :p
[15:58:34] <abaumann> I'm also not convinced, that using luajit 2.x is such good idea, I'd personally rather stick to 1.x
[15:58:47] <abaumann> it will anyway not support more than lua 5.1, I suppose
[15:59:16] <KitsuWhooa> The patched v2.1 one passed this test suite https://github.com on i686
[15:59:21] <KitsuWhooa> so I'm fairly confident in it
[15:59:32] <KitsuWhooa> if i486 doesn't require any further patching, it should be reliable
[15:59:39] <abaumann> ok.
[16:01:33] <KitsuWhooa> Anyway, if you want, try applying this https://tasossah.com and see what happens. But unfortunately I can't test it on my end
[16:01:40] <KitsuWhooa> qemu is happy with endbr32 too
[16:01:48] <KitsuWhooa> *try applying it on top
[16:19:39] <abaumann> time luajit test3.lua
[16:19:39] <abaumann> fibonacci(31)=1346269
[16:19:41] <abaumann> works :-)
[16:20:09] <abaumann> actually, just your patch with the 486 march and fpmath=i87 is enough
[16:20:11] <abaumann> I'l add it
[16:20:21] <KitsuWhooa> nice
[16:20:21] <bill-auger> abaumann: any ideas for me?
[16:21:39] <abaumann> oh.. sorry. you are too silent.. :-)
[16:21:40] <abaumann> aeh..
[16:21:52] <bill-auger> no-ultra-zstd.patch maybe ?
[16:21:56] <abaumann> yes.
[16:21:59] <abaumann> exactly
[16:22:05] <bill-auger> you were busy - i did not want to interrupt
[16:22:09] <abaumann> maybe also you have to lower the compression level.
[16:22:38] <abaumann> yes, zstd -22 --ultra effectively goes wrong more often than not.
[16:22:52] <bill-auger> ok i see now you did answer me
[16:23:33] <abaumann> we have it in core/linux etc. and in devtools32 in makepkg.conf
[16:23:36] <abaumann> I did?
[16:23:48] <abaumann> too much parallelism :-)
[16:24:12] <bill-auger> unless you were giving a very similar advice to KitsuWhooa
[16:24:14] <bill-auger> <abaumann> try some ultra -19 patching
[16:24:26] <abaumann> ah.
[16:24:37] <abaumann> that was for you.. without the tagging :-)
[16:25:01] <bill-auger> i dont usually do the kernels - trying to sync the PKGBUILD across arch arch32 and archarm, the diffs are massive
[16:25:34] <abaumann> a, the default zstd for packages is in /etc/makepkg.conf and it is:
[16:25:36] <abaumann> COMPRESSZST=(zstd -c -z -q -)
[16:25:53] <abaumann> COMPRESSZST=(zstd -c -T0 --ultra -19 -)
[16:26:03] <abaumann> is the patch we have in the devtools
[16:26:17] <abaumann> -T0 is for no threading
[16:27:25] <abaumann> I don't think we have a lot of PKGBUILD-specific zstd patching
[17:34:52] -!- abaumann has quit [Quit: leaving]
[19:23:07] -!- ligma_1 has quit [Ping timeout: 246 seconds]
[20:53:22] -!- drathir_tor has quit [Remote host closed the connection]
[20:58:36] -!- drathir_tor has joined #archlinux32
[21:27:19] -!- iamawacko has joined #archlinux32
[22:47:31] -!- iamawacko has quit [Ping timeout: 276 seconds]