#archlinux32 | Logs for 2024-05-09

Back
[00:57:55] -!- AtleoS has joined #archlinux32
[05:20:06] -!- bdju has quit [Ping timeout: 268 seconds]
[05:22:02] -!- bdju has joined #archlinux32
[05:33:16] -!- bdju has quit [Quit: Reconnecting]
[05:33:36] -!- bdju has joined #archlinux32
[05:42:39] -!- T`aZ has quit [Remote host closed the connection]
[06:43:57] <KitsuWhooa> that's an issue
[06:44:05] <KitsuWhooa> nm-applet: error while loading shared libraries: libgcr-4.so.4: cannot open shared object file: No such file or directory
[06:44:16] <KitsuWhooa> I also know nothing about X fonts
[06:50:15] <KitsuWhooa> I do have misc in my path though
[06:50:18] <KitsuWhooa> Font Path:
[06:50:18] <KitsuWhooa> /usr/share/fonts/misc/,/usr/share/fonts/TTF/,/usr/share/fonts/OTF/,/usr/share/fonts/100dpi/,/usr/share/fonts/75dpi/,/usr/share/fonts/misc,/usr/share/fonts/TTF,/usr/share/fonts/OTF,/usr/share/fonts/100dpi,/usr/share/fonts/75dpi,built-ins
[06:50:31] -!- abaumann has joined #archlinux32
[06:50:31] <buildmaster> Hi abaumann!
[06:50:31] <buildmaster> !rq abaumann
[06:50:32] <phrik> buildmaster: <abaumann> I remember the old saying in archlinux: "core" is for the things we need to boot the system and build the system. So meson is now part of core?
[06:52:18] <abaumann> KillerWasp: xterm belongs to the Xorg multiverse, which has been badly maintained over the recent years, to be nice. With Wayland replacing Xorg, Xorg will either have to be forked and maintained or it will just be dropped and dissapear from history. Sad, but reality. fonts on X were a disaster to begin with (I just say font server). I don't really know enough how xterm fetches the font definitions
[06:52:24] <abaumann> (which are now managed by fontconfig?).
[06:53:03] <KitsuWhooa> abaumann: Xorg isn't going anywhere
[06:53:18] <KitsuWhooa> Xwayland is X
[06:53:25] <abaumann> yeah.
[06:53:31] <KitsuWhooa> that said
[06:53:31] <abaumann> this is just a bridge to keep things alive.
[06:53:41] <KitsuWhooa> do yourself a favour and use urxvt or something :p
[06:53:52] <KitsuWhooa> although urxvt is similar
[06:54:03] <abaumann> That's my problem with this whole Xorg -> Wayland migration: there is a move from a client/server architecure to a much more limited architectural view.
[06:54:07] <abaumann> Things might just get lost.
[06:54:13] <abaumann> nope.
[06:54:19] <abaumann> I'm pretty happy with xterm :-)
[06:54:38] <KitsuWhooa> I don't remember why I stopped using it
[06:54:45] <abaumann> I need my Tectronics Terminal emulation ;-)
[06:54:59] <KitsuWhooa> I think it was a unicode issue
[06:55:51] <abaumann> I need very simple things and I am happy: like middle mouse copy-paste in _ALL_ applications.
[06:56:11] <abaumann> which doesn't work sometimes, not in electron apps sometimes, etc.
[06:56:38] <abaumann> I usually write code in a text editor and I copy paste a lot of commands into a terminal.
[06:56:50] <abaumann> Just matter of habit, I suppose.
[06:57:03] <abaumann> And some brain memory way back from the Oberon system. :-)
[06:57:06] <KitsuWhooa> there's a reason I brought urxvt back
[06:57:11] <KitsuWhooa> s/back/up/
[06:57:19] <KitsuWhooa> it behaves like xterm
[06:57:25] <KitsuWhooa> with a few extra stuff on top
[06:57:29] * abaumann laughs
[06:57:45] <KitsuWhooa> I see :p
[06:58:26] <KitsuWhooa> as a sidenote
[06:58:30] <KitsuWhooa> I see there's a gcc13 package
[06:58:36] <KitsuWhooa> are we up to gcc 14 already or something
[06:58:42] <abaumann> yep. Which - I'm sure - doesn't build :-)
[06:58:48] <abaumann> yes, probably
[06:59:01] <abaumann> easy, we just have to copy the patch from gcc to the gcc14 package
[06:59:03] <KitsuWhooa> it did build
[06:59:07] <abaumann> then it should build again
[06:59:10] <abaumann> ah?
[06:59:13] <KitsuWhooa> gcc13 doesn't
[06:59:15] <abaumann> ok, maybe just i486 then.
[06:59:48] <KitsuWhooa> I have no idea how to copy a url from w3m
[06:59:57] <abaumann> mmh. a segfault in rustc of some rust package. fun. :-)
[07:00:03] <abaumann> not.
[07:00:17] <abaumann> that's what I meant with copy-paste-everywhere.
[07:00:23] <abaumann> luakit I think was another one
[07:00:29] <abaumann> ripcord, a discord clone.
[07:00:49] <abaumann> I don't know what people are thinking. copy-paste is a must in every application.
[07:01:03] <abaumann> hence there were usability guidelines stating that for Windows and MacOS
[07:01:18] <abaumann> ui.
[07:01:25] <abaumann> quite some patches you did there :-)
[07:01:32] <KitsuWhooa> I know that's not what you meant
[07:01:42] <KitsuWhooa> but I wanted to link to the gcc 14 package
[07:01:45] <KitsuWhooa> and I don't know how
[07:01:47] <KitsuWhooa> time to rtfm
[07:02:13] <abaumann> aeh. you can maybe just set CC,CXX or you have to pass configure/meson whatever options.
[07:02:16] <abaumann> depends on the package
[07:02:32] <KitsuWhooa> ah, this works https://www.archlinux32.org
[07:02:45] <KitsuWhooa> anyway
[07:05:18] <abaumann> I'm building gcc 13 with gcc 14? Mmh. What can possibly go wrong.. :-)
[07:05:54] <KitsuWhooa> should be okay(tm)
[07:06:18] <abaumann> should be backward compatible..
[07:06:50] <abaumann> mmh. I need eurobuild6 for that.. otherwise I wait for hours..
[07:07:48] <KitsuWhooa> At some point I'll try faking CPU detection inside chroots
[07:08:38] <abaumann> That's a fun project. :-)
[07:08:45] <KitsuWhooa> There's just so many things to do
[07:09:01] <KitsuWhooa> I noticed that the numpy SSE patch broke yesterday and I fixed it
[07:09:19] <KitsuWhooa> RuntimeError: NumPy was built with baseline optimizations:
[07:09:19] <KitsuWhooa> (SSE SSE2) but your machine doesn't support:
[07:09:20] <KitsuWhooa> (SSE2).
[07:10:06] <abaumann> I don't know if you have ever seen my half-successful attempt to scan binaries/libraries for opcodes?
[07:10:20] <KitsuWhooa> nope
[07:10:30] <KitsuWhooa> but I suspect it doesn't work well statically
[07:10:43] <KitsuWhooa> because binaries can have instructions that are not executed dynamically
[07:10:55] <abaumann> well, the just scanned the binary and checked for offending use of registers or/and opcodes.
[07:10:55] <KitsuWhooa> which is why I was hoping I could do it with qemu
[07:10:58] <KitsuWhooa> yeah
[07:11:03] <abaumann> exactly.
[07:11:09] <abaumann> things like embree IIRC
[07:11:14] <KitsuWhooa> but qemu runs SSE2 with -cpu pentium3
[07:11:20] <abaumann> Also glibc has architecture-runtime stuff now.
[07:11:32] <KitsuWhooa> openblas too
[07:11:45] <abaumann> but the majority of packages just does some half-assed check of some properties and then enabled -msseX whatever.
[07:12:12] <abaumann> Anyway. The check (as it was in shell) took a little bit too long too :-)
[07:12:25] <abaumann> And it caused false alerts over the place.
[07:12:29] <abaumann> That's why I took it out.
[07:12:40] <abaumann> It is still somewhere there in the git repo of the builder ..
[07:13:14] <abaumann> Faking properties in a chroot might be hard, because the kernel exposes /proc to the container with the wrong properties.
[07:13:27] <abaumann> But there is also a personalities syscall which is shared with the host
[07:18:26] <KitsuWhooa> I was thinking of mounting a fake proc on top
[07:18:53] <abaumann> that should work
[07:19:14] <KitsuWhooa> if it looks at cpuid there's nothing we can do
[07:19:32] <KitsuWhooa> but yeah, mount --bind will be fine after the chroot is created
[07:20:05] <abaumann> linux32: does it change the personality?
[07:22:01] <KitsuWhooa> huh?
[07:22:31] <abaumann> setarch it is called, I think, from util-linux
[07:23:16] <KitsuWhooa> hm
[07:23:26] <abaumann> setarch --list
[07:23:29] <abaumann> shows a nice list.
[07:23:37] <abaumann> not sure, what effect it really has in the container
[07:23:50] <abaumann> I was hopping at least uname shows something faked then.
[07:23:54] <KitsuWhooa> I doubt it
[07:24:36] <KitsuWhooa> but also TIL uname is a syscall
[07:25:04] <KitsuWhooa> I suspect build systems aren't going to be running the uname syscall directly though, so just faking the uname binary should be fine
[07:25:22] <abaumann> I recall something here..
[07:25:54] <abaumann> pythonpackages/core/coreutils/coreutils-9.5-uname-i486.patch
[07:25:57] <abaumann> strcpy(name.machine, "i486");
[07:25:58] <abaumann> :-)
[07:26:23] <KitsuWhooa> the problem with uname is that it only says i686 for pentium4
[07:26:23] <abaumann> s/pythonpackages/packages
[07:27:05] <abaumann> the SSE/SSE2 stuff I don't see how it can rely on uname, so /proc is the only option there
[07:27:32] <abaumann> the far worse problem is that probing is sometimes done the following way: "Does gcc support -sse2?"
[07:27:43] <abaumann> by checking if the compiler can emit those opcodes.
[07:27:49] <abaumann> And of course it can, also on a 486.
[07:28:22] <abaumann> but to be fair, this also needs patching on a 486 VM.
[07:30:19] <KitsuWhooa> and on a real machine too
[07:30:24] <abaumann> true that
[07:45:52] <KitsuWhooa> I don't understand
[07:46:01] <KitsuWhooa> libnma links against libgcr
[07:46:09] <KitsuWhooa> I forced a rebuild, it linked against some libgcr and it still doesn't work
[07:47:09] <KitsuWhooa> ...gcr-4 is a makedepend?
[07:48:12] <abaumann> looks like
[07:48:31] <abaumann> gcr is 3.41.2
[07:48:43] <abaumann> gcr-4 is 4.2.1
[07:49:08] <abaumann> I would have expected it the other way round gcr3 and gcr, more suite for a rolling release?
[07:49:56] <KitsuWhooa> it gets more confusing
[07:50:01] <KitsuWhooa> in /usr/lib I have libgcr-4.so.0.0.0 libgcr-4.so.4.0.0
[07:50:06] <KitsuWhooa> er
[07:50:30] <KitsuWhooa> /usr/lib/libgcr-4.so /usr/lib/libgcr-4.so.0.0.0 /usr/lib/libgcr-4.so.4.0.0
[07:50:40] <abaumann> oeh. strange
[07:50:47] <KitsuWhooa> but there's no libgcr-4.so.4
[07:50:59] <KitsuWhooa> which is what the rebuild libnma expects
[07:51:02] <KitsuWhooa> *rebuilt
[07:51:40] <abaumann> those files belong all to gcr-4?
[07:52:01] <KitsuWhooa> ...
[07:52:05] <KitsuWhooa> I see the issue
[07:52:11] <KitsuWhooa> gcr-4 is in testing
[07:52:15] <KitsuWhooa> need to push it to stable...
[07:52:19] <abaumann> ah
[07:52:44] <KitsuWhooa> yeah okay it makes more sense now
[07:56:25] <KitsuWhooa> okay we're back in business
[07:56:39] <abaumann> business? I smell money here.. ;-)
[07:56:42] <KitsuWhooa> hahahaha
[07:57:00] <KitsuWhooa> the money I'm spending on electricity to run my builders
[08:05:56] <KitsuWhooa> abaumann: any idea who's supposed to be building gcc13?
[08:06:00] <KitsuWhooa> I see two eurobuild and two mine
[08:07:58] <abaumann> oeh. I forced into eurobuild6 machines.. but the buildmaster sometimes decides to build packages on several machines.
[08:08:04] <abaumann> there seems to be a race condition here
[08:08:15] <abaumann> no worries, it just wastes electrons - aeh money ;-)
[08:08:54] <abaumann> mmh. yes, it duplicated i686 and pentium4
[08:13:09] <KitsuWhooa> ...I bet it will go insane if they all succeed
[08:13:16] <KitsuWhooa> anyway, back to python
[08:25:47] <abaumann> uh, nss (which needs some mercurial python thingy) checks out. :-)
[08:25:53] <abaumann> this looks promising.
[08:26:47] <KitsuWhooa> I made a script to call schedule-for-rebuild for all the broken python packages
[08:26:57] <KitsuWhooa> not the best idea. it takes forever to run
[08:27:12] <KitsuWhooa> I thought I'd put all the packages in a regex but it only picked up on the forst 20 or so
[08:27:19] <KitsuWhooa> s/forst/first/
[08:37:04] <abaumann> 69 | # error "OPENSSL_THREADS is not defined, Python requires thread-safe OpenSSL"
[08:37:21] <abaumann> on i486. interesting. I'm used to that with wolfssl or so,..
[08:38:33] <abaumann> OPENSSL_THREADS is not defined, aha.
[08:39:07] <KitsuWhooa> thread-safe openssl, hm
[08:39:21] <KitsuWhooa> could it have something to do with latomic when building openssl?
[08:39:27] <abaumann> definitely
[08:39:45] <abaumann> we build it with some "no-assembly, i386-linux" setup or so.
[08:39:57] <abaumann> maybe the code never got made thread-safe in those corners..
[08:40:55] <abaumann> s@enable-ktls@enable-ktls 386 no-threads@
[08:40:59] <KitsuWhooa> ah
[08:40:59] <abaumann> yea, well.
[08:41:04] <abaumann> mea culpa :-)
[08:41:28] <abaumann> though, I might not have excluded it just for fun.. let's see, what happens, if I build openssl with threads on 486..
[08:41:39] <abaumann> ..my guess is - -latomic missing :-)
[08:42:37] <KitsuWhooa> is there no way to just have -latomic by default on i486?
[08:42:39] <KitsuWhooa> or am I missing something
[08:42:55] <abaumann> you have to add -latomic to LDFLAGS. That's all usually.
[08:43:34] <abaumann> For some strange reasons atomic support is intrisic to gcc for almost every platform out there, but not for i486 (and also some 32-bit ARM IIRC) and some others.
[08:43:44] <abaumann> There you have to link to an external library.
[08:44:49] <KitsuWhooa> Maybe we can tell the linker to always add it
[08:44:56] <abaumann> he. openssl builds with threads. cool. I can run it on a multi-core SMP 486 now ;-)
[08:45:01] <KitsuWhooa> hahaha
[08:45:11] <abaumann> I wouldn't add it generally.
[08:45:26] <abaumann> Just for packges which need it.. and there are not too many.
[08:45:58] <abaumann> /usr/src/debug/openssl/openssl-3.3.0/crypto/threads_pthread.c:330:(.text+0x7ff): undefined reference to `__atomic_fetch_sub_8'
[08:46:01] <abaumann> ok.
[08:46:04] <KitsuWhooa> ah
[08:46:23] <KitsuWhooa> I wonder if -latomic doesn't have that
[08:46:38] <abaumann> I have a strange feeling (and dejavu) here
[08:49:34] <KitsuWhooa> >cloning gcc git repo
[08:49:43] <KitsuWhooa> Why
[08:49:53] <KitsuWhooa> Doesn't it have to clone the entire thing first?
[08:50:10] <abaumann> Because using gcc releases is so 2023.. ;-)
[08:53:50] <abaumann> seriously. cherry-picking patches is much easier, if based on a git tag. And you almost always have to cherry-pick something.
[08:54:14] <abaumann> but this means nobody cares about proper releasing a software anymore. hence. :-)
[08:54:25] <KitsuWhooa> it's more that it takes forever to clone that annoys me
[08:55:07] <abaumann> well, SSDs have been invented exactly for this purpose. ;-)
[08:55:35] <KitsuWhooa> ADSL :p
[08:56:01] <abaumann> aeh. oupsi. I'm lucky to have FTTH
[09:34:00] <abaumann> {standard input}:1653394: Warning: end of file not at end of a line; newline inserted
[09:34:03] <abaumann> {standard input}:1653408: Error: unknown pseudo-op: `.l'
[09:34:05] <abaumann> {standard input}: Error: open CFI at the end of file; missing .cfi_endproc directive
[09:34:08] <abaumann> oups. on 486 gcc13
[09:35:42] <abaumann> out of memory or parallel builds? let's try again..
[09:39:09] <KitsuWhooa> if you're trying to reschedule something, you'll need to wait
[09:39:11] <KitsuWhooa> my script is still running :p
[09:39:14] <KitsuWhooa> and also
[09:39:33] <KitsuWhooa> python-mpd 29eb985196e33e22e33ddb4f1d9fd43609ddfad7 0000000000000000000000000000000000000000 e1ce53fde3609d07340270ea267d9b6ea987add6 extra
[09:39:33] <KitsuWhooa> "make_source_info" did not return a "pkgbase" - eh, what?
[09:39:33] <KitsuWhooa> >curl: (22) The requested URL returned error: 500<
[09:39:36] <KitsuWhooa> this might be worth looking into
[09:39:52] <abaumann> gambas3 d6a048e52ab4e4a6e1ecc02915602f7c2693bf86 0000000000000000000000000000000000000000 extra "make_source_info" did not return a "pkgbase" - eh, what?
[09:39:55] <abaumann> same
[09:41:06] <abaumann> timeouts.. mmh.
[09:42:55] <abaumann> max_execution_time = 30
[09:42:56] <abaumann> aha.
[09:55:25] -!- drathir_tor has quit [Remote host closed the connection]
[09:56:25] -!- drathir_tor has joined #archlinux32
[10:43:19] <KitsuWhooa> still waiting for schedule-for-rebuild to finish
[10:43:30] <KitsuWhooa> next time I'm going to do it more efficiently
[10:43:38] <KitsuWhooa> because it completely blocks all the builders
[10:54:04] -!- ssserpent has joined #archlinux32
[11:02:53] -!- AtleoS has quit [Ping timeout: 240 seconds]
[11:03:24] -!- AtleoS has joined #archlinux32
[11:35:55] <KitsuWhooa> we're building more python now, that's good
[11:36:02] <KitsuWhooa> as in, it's building and succeeding
[11:37:28] -!- johancb has joined #archlinux32
[11:54:17] <KitsuWhooa> who knows, maybe at this rate the state of python3.12 will be better than what 3.11 was
[11:54:26] <KitsuWhooa> on arch32 I mean
[11:54:48] <abaumann> yeah, let's hope. I'll add some eurobuild6 builders later when over with my stuff..
[11:54:59] <KitsuWhooa> thanks!
[11:55:02] <KitsuWhooa> also I don't know if you saw
[11:55:08] <KitsuWhooa> euronuc ran out of memory building clang last time
[11:55:18] <KitsuWhooa> maybe you need even more swap :p
[11:55:23] <abaumann> euronuc constantly runs out of memory on something.
[11:55:34] <KitsuWhooa> poor nuc
[11:55:39] <abaumann> it has 8 GB, but that proves not to be enough.
[11:55:43] <abaumann> indeed.
[12:01:24] -!- ssserpent has quit [Ping timeout: 256 seconds]
[12:03:09] <KitsuWhooa> ==> WARNING: Sonames differ in python-websockets!
[12:03:09] <KitsuWhooa> speedups.cpython-39-i386-linux-gnu.so=speedups.cpython-39-i38 | speedups.cpython-312-i386-linux-gnu.so=speedups.cpython-312-i
[12:03:17] <KitsuWhooa> it was last built for python 3.9?!
[12:03:19] <KitsuWhooa> ouch
[12:03:23] <abaumann> uh.
[12:03:31] <KitsuWhooa> (that's the output of the builder)
[12:48:33] -!- ssserpent has joined #archlinux32
[13:07:15] -!- johancb has quit [Ping timeout: 272 seconds]
[13:10:09] -!- drathir_tor has quit [Remote host closed the connection]
[13:10:59] -!- drathir_tor has joined #archlinux32
[13:42:12] <abaumann> ok, python builds (locally), so I force a rebuilt of python (only the python package)
[13:42:38] <KitsuWhooa> nice
[13:50:51] -!- AtleoS has quit [Ping timeout: 256 seconds]
[14:57:30] -!- abaumann has quit [Quit: leaving]
[15:00:54] -!- ssserpent has quit [Ping timeout: 255 seconds]
[18:29:24] -!- socksinspace has quit [Quit: brb, rebooting]
[18:30:56] -!- socksinspace has joined #archlinux32
[19:27:06] -!- drathir_tor has quit [Ping timeout: 260 seconds]
[19:28:55] -!- drathir_tor has joined #archlinux32
[19:50:34] -!- ssserpent has joined #archlinux32
[21:11:44] -!- dmc has quit [Quit: WeeChat 4.2.1]
[21:14:39] -!- dmc has joined #archlinux32
[21:27:29] -!- ssserpent has quit [Quit: WeeChat 4.2.2]
[22:19:47] -!- zxrom has quit [Quit: Leaving]
[22:27:00] -!- zxrom has joined #archlinux32
[23:46:34] -!- drathir_tor has quit [Ping timeout: 260 seconds]
[23:52:58] -!- drathir_tor has joined #archlinux32