#archlinux32 | Logs for 2024-04-18
Back
[01:54:50] -!- zxrom has quit [Quit: Leaving]
[04:42:37] -!- phrik has quit [Remote host closed the connection]
[04:42:46] -!- phrik has joined #archlinux32
[05:03:35] -!- bdju has quit [Ping timeout: 264 seconds]
[05:05:29] -!- bdju has joined #archlinux32
[05:09:53] -!- bdju has quit [Client Quit]
[05:10:13] -!- bdju has joined #archlinux32
[06:02:32] -!- sunshavi has quit [Ping timeout: 256 seconds]
[06:22:46] -!- titus_livius has joined #archlinux32
[06:24:08] -!- buildmaster has quit [Read error: Connection reset by peer]
[06:27:04] -!- buildmaster has joined #archlinux32
[08:03:46] -!- AtleoS has quit [Quit: AtleoS]
[08:15:15] -!- abaumann has joined #archlinux32
[08:15:15] <buildmaster> Hi abaumann!
[08:15:15] <buildmaster> !rq abaumann
[08:15:16] <phrik> buildmaster: <abaumann> the Linux kernel goes the Firefox way a) create a foundation, b) let everybody code on it, c) build times exceed the 20 minute margin on modern hardware d) reprogram everything in rust
[08:16:06] <abaumann> bill-auger: this mkinitcpio thing drives me crazy. Last time I tried, the buildmaster just picks arbitrary wrong versions to build. Now both stable and testing are in this strange state..
[08:16:28] <abaumann> I was planning to wait a little bit till people complain about it :-)
[08:16:51] <abaumann> I know, there was a bug report before for quite a while..
[08:20:31] <abaumann> huh?
[08:20:37] <abaumann> now it works. Strange.
[08:21:15] <abaumann> aha, maybe KitsuWhooa fixed it.
[08:22:02] <abaumann> We should never use -mtune, that's my feeling. The other question is should i686 require SSE and thus enable forcefully -sse and -fmath=sse. No clue really.
[08:22:28] <abaumann> You could also enable it just for the packge webrtc-audio-processing-1 which benefits from it.
[08:23:07] <abaumann> IMHO it would be anyway better to build everything with 486, then enable instuction sets, where they really make a measurable difference (or where the code is optimized and has now plain C fallback).
[08:23:17] <abaumann> But this could be just too much effort.
[08:23:44] -!- abaumann has quit [Quit: leaving]
[08:29:19] -!- abaumann has joined #archlinux32
[08:29:19] <buildmaster> Hi abaumann!
[08:29:19] <buildmaster> !rq abaumann
[08:29:20] <phrik> buildmaster: <abaumann> pacman, the new backup software. ;-)
[08:29:34] <abaumann> really weird, my lxc containers show a different behaviour than my VMS?
[08:29:48] <abaumann> there the systemd/mkinitcpio conflict persists.
[08:30:16] <abaumann> 00:16:76:e0:d3:3f
[08:30:18] <abaumann> oups
[08:30:19] <abaumann> 00:16:76:e0:d3:3f
[08:30:25] <abaumann> double oups
[08:30:33] <abaumann> no worries, it's a generated MAC of a VM :-)
[08:31:00] <abaumann> I see that mkinitcpio just conflicts now with a specific older systemd version, so probably rebulding and pushing systemd is a possible solution, let me check.
[09:42:41] <abaumann> oups systemd i484, I'm running down a rabbit hole there with jinja2 and BPF compilation failing in clang (clang seems to be broken), want to fix that first (or required packages), so that I can build systemd on all subarchitectures (I know, probably nobody uses 486 - but I have plans).
[09:59:22] <abaumann> automake を実行している...
[09:59:22] <abaumann> autoconf を実行している...
[09:59:22] <abaumann> ートストラップスクリプトが正常に完了しました。
[09:59:31] <abaumann> mmh. this is really weird..
[10:03:14] <abaumann> configure: error: C compiler cannot create executables
[10:03:17] <abaumann> oh dear.
[10:33:19] <abaumann> aeh, python-markupsafe works everywhere but on i486, where it tries to downloadhttps://sources.archlinux32.org which doesn't exist.
[10:33:23] <abaumann> strange
[10:33:47] <abaumann> https://github.com
[10:34:05] <abaumann> ok, I think I have to disable this generates of git packages I never really understood how it works
[10:34:17] <abaumann> *generator
[10:35:49] <abaumann> mirrored_source_by_hash, that straw is active per default on i486? maybe it was way slow to use git on 486 vms in the past, could be..
[10:38:54] <abaumann> mh. straws_that_might_repair_failing_builds is not set.
[10:39:30] <abaumann> grep -q '^\(haskell\|python2\?\)-'; then
[10:39:36] <abaumann> oups, we should also fix that..
[10:44:23] <abaumann> setting straws_that_might_repair_failing_builds without mirror just plain fails.. ok.
[10:44:40] <abaumann> it should use git to checkout it from github.com, weird
[10:54:41] <abaumann> sha512sums=('449daf8db6f1356f865cdb814be7a11c02a3c6dc130207193c6e300f0055d877378aaee0eb3634b3ce052960c927
[10:54:59] <abaumann> aha. so it checks out via git and then fails to compute a checksum
[10:57:00] -!- socksinspace has quit [Ping timeout: 268 seconds]
[10:58:26] -!- socksinspace has joined #archlinux32
[11:02:51] <abaumann> # try to download source from sources.archlinux32.org by its hash
[11:02:52] <abaumann> if [ ${verifysource_trial} -eq 3 ]; then
[11:03:02] <abaumann> interesting.
[11:27:28] <abaumann> /usr/bin/msgfmt: error while loading shared libraries: libicuuc.so.73: cannot open shared object file: No such file or directory
[11:27:43] <abaumann> the rabbit hole just got a little bit deeper ;-)
[11:32:15] -!- socksinspace has quit [Quit: WeeChat 3.8]
[11:32:30] <abaumann> emacs: error while loading shared libraries: libicuuc.so.73: cannot open shared object file: No such file or directory
[11:32:43] <abaumann> ok. this is messy on 486
[11:32:51] <abaumann> basically everything is broken.
[11:33:20] <abaumann> ah. no icu73 shim package (which certainly doesn't build either).
[11:35:52] -!- socksinspace has joined #archlinux32
[11:37:47] <KitsuWhooa> abaumann: I never said to use mtune
[11:38:03] <KitsuWhooa> Just march=pentium3 which enables sse
[11:38:12] <KitsuWhooa> We do say we require sse on the website
[11:38:38] <KitsuWhooa> I wonder if it'd speed anything up
[11:40:05] <KitsuWhooa> In my mind, these old machines should get the best chance they can get to run things
[11:41:16] <abaumann> for i686 use march=pentium4
[11:41:19] <abaumann> aeh pentium3
[11:41:27] <abaumann> but that would mean you can drop i686
[11:41:30] <abaumann> which is not the idea
[11:43:03] <abaumann> march=i868 -msse -mmmx -mmath=sse would maybe be an option.
[11:44:20] <abaumann> your argument is basically, i686 now is defacto a pentium3. I just fear -march=pentium3 enables things we don't want, not just SSE
[11:44:46] <KitsuWhooa> sure, could do that
[11:44:52] <KitsuWhooa> but the gcc docs say it only enables SSE :p
[11:45:01] <KitsuWhooa> https://gcc.gnu.org
[11:45:02] <phrik> Title: x86 Options (Using the GNU Compiler Collection (GCC)) (at gcc.gnu.org)
[11:45:02] <abaumann> don't trust gcc
[11:45:36] <abaumann> as long you cannot guarantee with objdump, that this is the case and test on real hardware, don't take documentation for a legacy platform for granted.
[11:45:44] <KitsuWhooa> understood
[11:45:49] <abaumann> bas bitten with endbr32 there and multi-byte nops.
[11:46:04] <abaumann> also some "additional" mmx/sse registers, IIRC
[11:46:34] <abaumann> but, as said. You can always overwrite them on a package level in PKGBUILD
[11:46:52] <KitsuWhooa> I don't want to do it per package because there might be software that will benefit from having sse
[11:47:05] <KitsuWhooa> especially when we say we require it
[11:47:33] <abaumann> I would actually love to have more optimizations, but for that i486 must be more usable.
[11:47:42] <abaumann> otherwise you don't really have a fallback anymore.
[11:47:53] <KitsuWhooa> isn't i686 unusable on anything older in the first place due to the big initramfs?
[11:48:04] <abaumann> not really.
[11:48:32] <abaumann> man early AMDs have no SSE, so they require i486, some have some weird mixture, so i686 works now.
[11:48:43] <abaumann> And they have 512MB -> 1 GB RAM
[11:48:45] <abaumann> at least mine.
[11:48:46] <KitsuWhooa> Hm, I see
[11:48:52] <abaumann> so they boot just fine
[11:49:29] <abaumann> but you are right. we should ponder about those flags and if necessary change them..
[11:49:48] <KitsuWhooa> I'll enable SSE for that package for now, but
[11:49:56] <KitsuWhooa> I think we want to try to get i486 building in chroots
[11:50:00] <KitsuWhooa> because it is getting extremely unmaintainable
[11:50:01] <abaumann> I already have seen packages providing --with-sse and what they meant was actually SSE2 :-)
[11:50:14] <KitsuWhooa> and I don't have the machines or the resources for it
[11:50:27] <abaumann> This will not work, they will catch up too many stuff of the environemnt
[11:50:42] <abaumann> to be fair. that's also what i686 is doing (and sometimes even pentium4)
[11:50:46] <KitsuWhooa> yes
[11:50:54] <abaumann> but for i484 basically every package then needs patching
[11:51:04] <KitsuWhooa> I assume you've tried it before, right?
[11:51:08] <abaumann> or a special arch-chroot-i486 which mimichs /proc/cpuinfo or so
[11:51:35] <abaumann> yep. The average configure script either asks the compiler whether it can generate a certain SSE/SSE2 code or so..
[11:51:57] <abaumann> ..or they poke the runtime for some properties. grepping flags in /proc/cpuinfo is a fafourite. :-)
[11:52:04] <abaumann> *favourite
[11:52:23] <KitsuWhooa> I think it'd be better if we hacked whatever claims to support SSE rather than use VMs
[11:52:25] <abaumann> And then there is uname itself.
[11:52:26] <KitsuWhooa> but unfortunately I can't try it
[11:52:33] <abaumann> It doesn't say i486 in a 486 chroot.
[11:53:32] <KitsuWhooa> I unfortunately don't see much of a future with i486 as is
[11:53:36] <abaumann> "requires SSE" is more like "it might force you to have SSE in your CPU", not "we guarantee, that we use SSE so that your software benefits most"
[11:53:43] <KitsuWhooa> even i686 and pentium4 feel like they're at the end of their life
[11:53:47] <KitsuWhooa> so many packages run out of memory
[11:53:55] <abaumann> that's definitely true.
[11:54:10] <abaumann> I had euronuc going belly up with 8 GBs in a non-VM build of something.
[11:54:25] <KitsuWhooa> I meant 32 bit address space
[11:54:34] <KitsuWhooa> I saw a package that the compiler itself ran out of memory
[11:54:38] <KitsuWhooa> not even the linker
[11:55:34] <abaumann> uh.
[11:55:46] <abaumann> I recently saw also "internal compiler errors" due to memory issues.
[11:55:50] <KitsuWhooa> ooooh
[11:55:58] <KitsuWhooa> I saw a few of those but I didn't know they were memory related
[11:56:37] <abaumann> Just a suspicion of mine that it correlates, nothing proven :-)
[11:56:47] <KitsuWhooa> ah
[11:57:04] <KitsuWhooa> for what it's worth
[11:57:08] <KitsuWhooa> pentium4 uses -march=pentium4
[11:57:12] <KitsuWhooa> but I guess that makes sense
[11:57:35] <abaumann> the subarchitecture are historically really just that -march=$subarch
[11:57:48] <abaumann> the descriptions are something which came later
[11:57:53] <KitsuWhooa> Anyway, before we let this die for another 10 years again (joking), is there a more effective way to discuss SSE on i686?
[11:58:13] <KitsuWhooa> like, open a bug or something
[11:58:55] <abaumann> I would say, enable it for a really low level package like glibc or coreutils and then see, what crashes.
[11:59:01] <abaumann> this is also quite dangerous of course.
[11:59:13] <abaumann> the -fmath=sse is not clear to me.
[11:59:31] <KitsuWhooa> we can keep using x87 without it
[11:59:34] <abaumann> on a SSE-machine match should work better if using MMX/SSE instead of the old FPU instructions
[11:59:54] <KitsuWhooa> but also, I just had a thought
[12:00:03] <KitsuWhooa> i686 is built on chroots, and it runs on non SSE machines
[12:00:07] <abaumann> IIRC it had implications on the ABI calling of functions, so unless you are really careful you get stack faults when passing parameters
[12:00:16] <KitsuWhooa> ah, hm
[12:00:31] <abaumann> all chroots build on AMD64, which have SSE and leak it into the chroots
[12:00:53] <abaumann> you don't want to build anything on any real hardware from the aera :-)
[12:01:02] <KitsuWhooa> yes, but you did say i686 runs on non SSE machines
[12:01:04] <abaumann> *era
[12:01:15] <KitsuWhooa> I'm going to have to get hardware from that era and mess around
[12:01:31] <abaumann> ah. yes. that's another issue about testing..
[12:01:32] <KitsuWhooa> and if it means hacked chroots, sure
[12:04:23] <KitsuWhooa> also
[12:04:29] <KitsuWhooa> 11:21:15 <abaumann> aha, maybe KitsuWhooa fixed it. <-- I didn't touch anything
[12:04:45] <abaumann> oh. :-)
[12:05:04] <abaumann> mmh. no. I think I had intermediate versions in my LXC containers
[12:05:06] <KitsuWhooa> if buildmaster tries to build an older package version, it will go insane
[12:05:21] <abaumann> on the VMs (test VMS for testing and stable) I still experience the systemd/mkinitcpio issues.
[12:05:35] <abaumann> That's why I'm trying to fix systemd for i486 right now..
[12:05:40] <KitsuWhooa> it happens in stable too?!
[12:06:05] <abaumann> yes. it got published there now (after 2 weeks or so).. or I forced it by accident when experimenting with rebuilds.
[12:06:10] <KitsuWhooa> mmmhm
[12:06:14] <KitsuWhooa> let me fire up my laptop
[12:06:45] <abaumann> just don't uninstall systemd. ;-)
[12:08:10] <KitsuWhooa> I suspect it works in staging
[12:08:17] <KitsuWhooa> otherwise wouldn't the builders complain?
[12:08:30] <abaumann> yes, that's strange
[12:08:40] <abaumann> but if I push staging to testing, nothing happens
[12:09:36] <KitsuWhooa> yup
[12:09:39] <KitsuWhooa> it wants me to nuke systemd
[12:10:08] <abaumann> which.. in theory.. I would appreciate.. ;-)
[12:10:11] <KitsuWhooa> hah
[12:10:14] <KitsuWhooa> I like systemd :p
[12:11:00] <KitsuWhooa> I think some of the issues stem from i486 being left behind and the buildmaster having entries to old packages
[12:11:02] <KitsuWhooa> but also
[12:11:16] <KitsuWhooa> core has 252.4-2.0
[12:11:30] <KitsuWhooa> yeah we need 255.4-2 there
[12:11:39] <KitsuWhooa> testing is also too old
[12:11:44] <KitsuWhooa> staging is fine though
[12:11:51] <abaumann> yep. that's why mkinitcpio compains.
[12:12:02] <KitsuWhooa> so mkinitcpio got pushed but systemd didn't, I see
[12:12:09] <abaumann> ok.
[12:12:32] <abaumann> hah. now pushall works.
[12:12:34] <KitsuWhooa> m̶a̶y̶b̶e̶ ̶w̶e̶ ̶s̶h̶o̶u̶l̶d̶ ̶p̶u̶s̶h̶ ̶s̶t̶a̶g̶i̶n̶g̶ ̶t̶o̶ ̶s̶t̶a̶b̶l̶e̶ ̶a̶n̶d̶ ̶c̶a̶l̶l̶ ̶i̶t̶ ̶a̶ ̶d̶a̶y̶
[12:12:42] <KitsuWhooa> ah it did work
[12:12:46] <abaumann> ok. so, staging built systemd in the meantime, just not for i486
[12:13:09] <KitsuWhooa> I suggest building packages manually before asking the build system to rebuild them
[12:13:14] <KitsuWhooa> because it takes forever
[12:13:25] <KitsuWhooa> I suspect it didn't try i486 because it's stuck on other dependencies
[12:13:31] <KitsuWhooa> *try systemd for i486
[12:13:36] <abaumann> yes. doing that since the beginnig of the project :-)
[12:13:39] <KitsuWhooa> oh now staging got pushed to stable
[12:13:44] <KitsuWhooa> ah, sorry
[12:13:52] <abaumann> why. good. :-)
[12:14:07] <KitsuWhooa> now it can't upgrade systemd because dbus needs to be pushed
[12:14:08] <KitsuWhooa> :p
[12:14:25] <abaumann> ah.
[12:14:38] <KitsuWhooa> Oh right, to build systemd you need to get dbus built first
[12:14:49] <KitsuWhooa> which needs that dummy package I made in build support
[12:14:49] <abaumann> pushing dbus..
[12:15:31] <KitsuWhooa> now cryptsetup :p
[12:15:51] <abaumann> dbus-units?
[12:15:56] <abaumann> should it need that instead of dbus
[12:16:46] <KitsuWhooa> I think so
[12:16:48] <abaumann> so, very soon we have a icu73 shim
[12:16:52] <abaumann> this could also come in handy
[12:17:03] <KitsuWhooa> but I didn't have to touch the PKGBUILD for systemd
[12:17:22] <KitsuWhooa> https://git.archlinux32.org
[12:17:22] <phrik> Title: PKGBUILD « dbus-dummy-units « build-support - packages - Archlinux32 package modifications (at git.archlinux32.org)
[12:17:30] <KitsuWhooa> ah I remember now
[12:17:35] <KitsuWhooa> we just didn't have anything that provided dbus-units
[12:17:38] <KitsuWhooa> and that fixed it
[12:17:43] <abaumann> Yes
[12:18:11] <KitsuWhooa> now mdadm conflicts
[12:18:15] <abaumann> we just go full-steam ahead now. as stable is technically already broken..
[12:18:22] <KitsuWhooa> yeah
[12:18:33] <KitsuWhooa> we couldn't have gone back
[12:18:43] <abaumann> nope
[12:18:58] <KitsuWhooa> at least python 3.11 will be less broken now :p
[12:19:47] <abaumann> I just had to force build some stuff for i486, i686/pentium4 look ok
[12:21:49] <KitsuWhooa> can you also please push mdadm from testing to stable?
[12:22:45] <abaumann> yes. I just pushed all packages
[12:22:49] <KitsuWhooa> ah
[12:22:53] <abaumann> maybe mirrors have to catch up..
[12:23:27] <KitsuWhooa> fingers crossed the system reboots
[12:23:30] <abaumann> this looks promising..
[12:23:35] <KitsuWhooa> now it's complaining about lvm2
[12:23:39] <KitsuWhooa> yeah the mirrors probably need to catch up
[12:23:54] <KitsuWhooa> oh
[12:23:56] <abaumann> yep. wait..
[12:23:57] <KitsuWhooa> I'm using mirror.archlinux32.org
[12:24:21] <abaumann> mkinitcpio systemd lvm2 mdadm cryptsetup
[12:24:23] <KitsuWhooa> there we go
[12:24:36] <abaumann> let's check if those versions fit to https://archlinux.org
[12:24:37] <phrik> Title: Arch Linux - News: mkinitcpio hook migration and early microcode (at archlinux.org)
[12:24:47] <KitsuWhooa> I'm upgrading as we speak
[12:25:02] <abaumann> for really testing it you need a logical volume on a mdraid with encryption enabled probably.. :-)
[12:25:18] <KitsuWhooa> I think I'm fine without encryption on this machine thanks :p
[12:26:04] <abaumann> so, no my archlinux32.mirror has catched up..
[12:26:52] <abaumann> i486: there I have to force build systemd again (it got stuck in python-jinja and clang/bpf)
[12:27:06] <KitsuWhooa> mmmm
[12:27:07] <abaumann> I have local hacks in place now for i486 only which I'm currently testing..
[12:27:23] <abaumann> mmh?
[12:27:39] <KitsuWhooa> nothing, just that it didn't work
[12:27:45] <KitsuWhooa> systemd on i486 I mean
[12:27:51] <KitsuWhooa> I am still waiting for the upgrade to finish on my end
[12:28:00] <abaumann> ah. ok. :-)
[12:30:24] <abaumann> my lxc containers came up again.
[12:30:35] <abaumann> but they don't even have a new initramdisk
[12:30:43] <abaumann> so I have to rebuild them after merging mkinitcpio.conf
[12:31:17] <KitsuWhooa> that's arch in general though, right?
[12:31:42] <abaumann> of course.
[12:31:54] <abaumann> I just too often forget it. :-)
[12:33:10] <KitsuWhooa> I always forget to regenerate the grub config :p
[12:33:24] <KitsuWhooa> when say, installing a new kernel
[12:34:45] <abaumann> so, let's first reboot without mkinitcpio regeration.
[12:35:37] <abaumann> anyway, microcode hooks don't affect us anyway..
[12:35:45] <KitsuWhooa> they don't?
[12:35:56] <abaumann> I'm not away of a single patch of a 32-bit cpu
[12:36:01] <abaumann> from intel or amd that is.
[12:36:12] <abaumann> *aware
[12:36:16] <KitsuWhooa> I have at least one pentium3 machine where intel released newer microcode than what the bios provides
[12:36:18] <abaumann> there might be..
[12:36:25] <abaumann> ah, yes?
[12:36:29] <abaumann> interesting.
[12:36:55] <KitsuWhooa> model name : Pentium III (Katmai)
[12:36:55] <KitsuWhooa> microcode : 0xe
[12:37:13] <KitsuWhooa> there's a repo on github somewhere full of old microcodes
[12:37:28] <KitsuWhooa> ...I suspect upstream don't ship 32 bit microcodes
[12:37:30] <KitsuWhooa> maybe we should
[12:37:43] <abaumann> true
[12:38:01] <abaumann> rebooted, now lightdm is broken :-)
[12:38:11] <KitsuWhooa> when is it not /j
[12:38:36] <KitsuWhooa> I think here https://github.com
[12:40:11] <abaumann> yeah, and half of KDE is broken
[12:40:18] <KitsuWhooa> oh that I already knew
[12:40:20] <KitsuWhooa> I didn't get around to fixing kde
[12:40:27] <KitsuWhooa> I didn't realise we even had working kde
[12:40:42] <KitsuWhooa> it's a matter of bootstrapping KF6
[12:40:48] <KitsuWhooa> which isn't easy to do because of buildmaster ;p
[12:40:59] <abaumann> exactly
[12:41:51] <KitsuWhooa> kde framework
[12:41:53] <KitsuWhooa> ...
[12:41:56] <KitsuWhooa> https://api.kde.org
[12:41:57] <phrik> Title: API Documentation (at api.kde.org)
[12:42:02] <KitsuWhooa> at least they tell you which packages you can build first
[12:44:13] <abaumann> jwm
[12:44:13] <abaumann> jwm: symbol lookup error: /usr/lib/libpango-1.0.so.0: undefined symbol: g_once_init_leave_pointer
[12:44:23] <KitsuWhooa> ah, pango got rebuilt
[12:44:27] <KitsuWhooa> I guess we need to rebuild jwm?
[12:44:27] <abaumann> yea, this sounds more like gobject introspecion or so
[12:44:35] <KitsuWhooa> we do have working gobject introspection now
[12:44:37] <abaumann> librsvg-2.so.2 => /usr/lib/librsvg-2.so.2
[12:44:39] <abaumann> libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0
[12:44:45] <KitsuWhooa> oh
[12:44:50] <KitsuWhooa> rebuild librsvg then :p
[12:45:04] <abaumann> and librsvg is our belowed rust-librsvg or librsvg-og (which needs patching)
[12:45:14] <abaumann> librsvg-og is i486 only, so
[12:45:15] <KitsuWhooa> rust-librsvg should build just fine
[12:45:24] <abaumann> you fixed rust, right?
[12:45:25] <KitsuWhooa> yup
[12:45:28] <abaumann> so it should just build.
[12:45:30] <KitsuWhooa> it will
[12:45:32] <KitsuWhooa> it did for me
[12:45:42] <KitsuWhooa> I guess pango got built after librsvg
[12:45:47] <abaumann> so, everything else could just work afterwards too..
[12:45:52] <KitsuWhooa> yup
[12:45:58] <abaumann> rsvg and pango are quite deep in everything
[12:48:17] <KitsuWhooa> wish me luck
[12:48:18] <KitsuWhooa> ==> Initcpio image generation successful
[12:48:18] <KitsuWhooa> tasos@nightopia:~$ sudo reboot
[12:49:14] <abaumann> I hope this is not your daily driver. ;-)
[12:49:28] <KitsuWhooa> it is my personal laptop :p
[12:49:47] <abaumann> in this case.. good luck :-)
[12:49:52] <KitsuWhooa> thanks :p
[12:50:26] <KitsuWhooa> oh yeah lightdm is broken
[12:51:22] <abaumann> probably just the greeter
[12:52:30] <KitsuWhooa> /usr/bin/lightdm-gtk-greeter: symbol lookup error: /usr/lib/libpango-1.0.so.0: undefined symbol: g_once_init_leave_pointer
[12:52:32] <KitsuWhooa> yuup
[12:53:28] <abaumann> ok, also my vms came up after mkinitcpio..
[12:54:27] <KitsuWhooa> I think we need to rebuild libgtk then
[12:54:35] <KitsuWhooa> that's what depends on pango in my case
[12:54:41] <KitsuWhooa> well, gtk3
[12:55:25] <KitsuWhooa> https://tasossah.com
[12:55:26] <phrik> Title: lightdm pango (at tasossah.com)
[12:55:28] <KitsuWhooa> assuming I'm reading this correctly
[12:56:01] <abaumann> yep
[12:56:12] <KitsuWhooa> gtk3 was built after pango...
[12:56:14] <KitsuWhooa> I'm confused
[12:56:16] <KitsuWhooa> wait no
[12:56:21] <KitsuWhooa> gtk3 is from 2023?!
[12:56:27] <abaumann> and maybe also the greeter maybe
[12:56:35] <KitsuWhooa> I think the greeter will be fine, but we'll see
[12:56:42] <KitsuWhooa> I'll build gtk3 (and fight it if it doesn't :p)
[12:56:46] <abaumann> that's why it complains about a missing symbol further down
[12:57:07] <abaumann> so, have to do shopping for 10 minutes..
[12:57:10] <KitsuWhooa> have fun
[12:57:15] <abaumann> .. I'll be back in a bit..
[12:57:16] <KitsuWhooa> hopefully we'll have a working lightdm when you're back
[12:57:24] <abaumann> that would be great :-)
[12:57:25] <KitsuWhooa> builders are building gcc12
[12:57:31] <abaumann> uh..
[12:57:31] <KitsuWhooa> I am tempted to blacklist it
[12:57:44] <KitsuWhooa> it's needed for opencv and other things like that, that I suspect don't run on arch32
[12:57:54] <KitsuWhooa> 15:57:25 <KitsuWhooa> builders are building gcc12 <-- and failing
[12:57:55] <abaumann> it's still used to build some software which doesn't build with newest gcc
[12:58:04] <KitsuWhooa> https://archlinux.org
[12:58:07] <phrik> Title: Arch Linux - gcc12 12.3.0-6 (x86_64) (at archlinux.org)
[12:58:14] <KitsuWhooa> gcc12-fortran, mysql-workbench, and opencv
[12:58:23] <KitsuWhooa> and gcc12-fortran is for CUDA
[13:02:01] <KitsuWhooa> > Run-time dependency atk-bridge-2.0 found: NO (tried pkgconfig)
[13:03:14] <KitsuWhooa> at-spi2-core is built, hm
[13:09:13] <KitsuWhooa> Ah.... Back to > ModuleNotFoundError: No module named 'packaging'
[13:09:25] <KitsuWhooa> the module exists, but something in the chain doesn't depend on it because it needs a rebuild
[13:10:19] <abaumann> back.. I was dangerously low on coffee :-
[13:10:19] <abaumann> )
[13:11:39] <abaumann> I just recently needed gcc12 for something in the AUR..
[13:11:45] <KitsuWhooa> oooh
[13:11:47] <KitsuWhooa> okay, fair enough
[13:11:54] <KitsuWhooa> I'll look into getting it to build later, then
[13:11:55] <KitsuWhooa> but also
[13:11:58] <KitsuWhooa> how can I get a dependency graph?
[13:12:03] <KitsuWhooa> for a specific package
[13:12:11] <KitsuWhooa> preferably on both upstream and arhc32
[13:12:12] <KitsuWhooa> *arch32
[13:12:15] <KitsuWhooa> or even a tree or a list
[13:12:17] <KitsuWhooa> to compare
[13:12:21] <abaumann> don't recall
[13:12:24] <KitsuWhooa> :/
[13:12:38] <abaumann> not super important, gcc12
[13:12:43] <KitsuWhooa> gtk3 is though :p
[13:12:58] <abaumann> it needs all the good Gnome stuff, I suppose..
[13:13:09] <KitsuWhooa> most of it is built
[13:13:19] <KitsuWhooa> and the ones that aren't built need python-packaging which isn't being brought in...
[13:14:29] <KitsuWhooa> I wonder if it's gi-docgen
[13:14:57] <KitsuWhooa> nope, that's fine
[13:15:10] <abaumann> my real nas needs mdadm and stuff, let's see what happens after upgrading.. :-)
[13:16:13] <KitsuWhooa> I guess I'll ask in #archlinux and hope someone knows :p
[13:27:05] <abaumann> uff. my NAS survived, good :-)
[13:29:19] <KitsuWhooa> nice!
[13:29:29] <KitsuWhooa> So, for some reason at-spi2-core is not being installed?
[13:29:33] <KitsuWhooa> I'm confused
[13:29:55] <KitsuWhooa> :: at-spi2-core and atk are in conflict. Remove atk? [y/N]
[13:29:55] <KitsuWhooa> oh.
[13:30:04] <KitsuWhooa> abaumann: I might need to nuke atk from the repos...
[13:30:40] <KitsuWhooa> it gets installed instead of at-spi2-core
[13:31:02] <KitsuWhooa> unless you have a better idea
[13:36:52] <abaumann> If you explicitely add at-spi2-core as makedepends?
[13:37:32] <KitsuWhooa> hm
[13:37:35] <KitsuWhooa> let me try that
[13:37:49] <abaumann> otherwise I have no idea how you can force packages over others..
[13:38:32] <KitsuWhooa> adding at-spi2-core to makepends resulted in :: at-spi2-core and atk are in conflict. Remove atk? [y/N]
[13:38:35] <KitsuWhooa> pacman answered no
[13:38:36] <KitsuWhooa> and the build failed
[13:38:42] <abaumann> "pacman says no" ;-)
[13:39:30] <abaumann> nukeing.. mmh. but something might depend on atk.
[13:39:38] <KitsuWhooa> Maybe I can make a dummy package in build-support called atk that requires at-spi2-core and doesn't conflict with it
[13:39:40] <abaumann> have an attic repository where we move old things?
[13:39:51] <abaumann> ah, that's also an option
[13:40:04] <KitsuWhooa> 16:39:30 <abaumann> nukeing.. mmh. but something might depend on atk. <-- I suspect most of it is gtk, which is currently broken
[13:40:11] <KitsuWhooa> and it was built in 2022
[13:40:11] <abaumann> ah.
[13:40:18] <KitsuWhooa> so I somehow doubt it still works
[13:40:19] <abaumann> uh? really? so long ago?
[13:40:22] <KitsuWhooa> yup
[13:40:34] <KitsuWhooa> that's probably when upstream renamed it/whatever
[13:40:37] <KitsuWhooa> https://archlinux32.org
[13:40:39] <phrik> Title: Arch Linux 32 - atk 2.38.0-1.0 (pentium4) (at archlinux32.org)
[13:40:40] <abaumann> well, some window manager and login manager still worked.
[13:41:06] <KitsuWhooa> actually
[13:41:10] <KitsuWhooa> I can't make a package in build-support
[13:41:25] <abaumann> so, deleting it is the only option.
[13:41:26] <KitsuWhooa> it'll have to be called atk and buildmaster will ignore it
[13:41:37] <KitsuWhooa> yup...
[13:41:38] <abaumann> I don't recall, whether it is stored then in archive.archlinux32.org anyway.
[13:41:45] <abaumann> But I think so.
[13:41:51] <KitsuWhooa> it should be
[13:41:57] <KitsuWhooa> otherwise the archive isn't working :p
[13:41:59] <abaumann> fine. nuke ahead :-)
[13:42:29] <KitsuWhooa> I can't figure out what makepends package is supposed to bring in python-packaging
[13:42:35] <KitsuWhooa> I'll sort that out and then delete atk
[13:42:39] <KitsuWhooa> and hopefully gtk will build
[13:46:40] <KitsuWhooa> yeah no
[13:46:50] <KitsuWhooa> I'll just add python-packaging as a runtime dependency to gobject-introspect
[13:47:16] <abaumann> call to execv failed (No such file or directory)
[13:47:24] <abaumann> on testing. every hook fails in pacman
[13:47:30] <abaumann> -bash: /usr/bin/pacman: No such file or directory
[13:47:38] <KitsuWhooa> ...uh oh
[13:47:40] <abaumann> this looks absolutely horrible.
[13:47:59] <abaumann> do we have a glibc change in testing?
[13:48:22] <KitsuWhooa> only in staging
[13:48:57] <abaumann> my testing container is still ok, so, weird..
[13:50:20] <KitsuWhooa> > delete_package any sysfsutils core
[13:50:23] <KitsuWhooa> sysfsutils my beloved
[13:50:36] <KitsuWhooa> It is the 196th rebuild now :p
[13:50:46] <abaumann> oh, only, and still not good? ;-)
[13:50:52] <KitsuWhooa> imagine if it was gcc
[13:51:00] <KitsuWhooa> or mesa or llvm or something
[13:51:03] <KitsuWhooa> ...let's not jinx it
[13:53:25] <KitsuWhooa> ...buildmaster didn't pick up on gobject-introspection?
[13:53:45] <KitsuWhooa> did I make a typo or something...
[13:55:00] <KitsuWhooa> no, it's building fine for me
[13:55:04] <KitsuWhooa> wtf
[13:56:01] <KitsuWhooa> oh I'm dumb
[13:57:32] <abaumann> gobject-introspection looks ok to me
[13:57:37] <KitsuWhooa> it doesn't have a depends()
[13:57:39] <abaumann> the name, I mean
[13:57:40] <KitsuWhooa> that's why
[13:57:51] <KitsuWhooa> I have to add it here https://gitlab.archlinux.org
[13:57:53] <phrik> Title: PKGBUILD · main · Arch Linux / Packaging / Packages / gobject-introspection · GitLab (at gitlab.archlinux.org)
[13:58:46] <abaumann> pacman -Rs gobject-introspection
[13:58:52] <abaumann> I can remove it from my desktop?
[13:58:52] <abaumann> mmh.
[13:59:04] <abaumann> this sounds interesting
[13:59:38] <KitsuWhooa> I never figured out how pacman decides to remove packages
[14:01:00] <abaumann> darn. no busybox on the machine..
[14:01:07] <abaumann> otherwise I could debug what's missing
[14:01:25] <KitsuWhooa> time to copy a static binary :p
[14:01:29] <abaumann> ( 47/264) upgrading btrfs-progs [##################################] 100%
[14:01:32] <abaumann> call to execv failed (No such file or directory)
[14:01:34] <abaumann> error: command failed to execute correctly
[14:01:38] <abaumann> I do have pacman-static on the machine.
[14:01:41] <KitsuWhooa> ah
[14:01:47] <abaumann> that's basically the only binary still working :-)
[14:01:51] <KitsuWhooa> I was referring to a static busybo
[14:01:52] <KitsuWhooa> x
[14:01:58] <abaumann> now I have to find the package I have to downgrade..
[14:02:39] <abaumann> pacman-static -U /var/cache/pacman/pkg/coreutils-9.4-3.0-pentium4.pkg.tar.zst
[14:02:42] <abaumann> loading packages...
[14:02:44] <abaumann> error: GPGME error: Invalid crypto engine
[14:02:47] <abaumann> error: GPGME error: Invalid crypto engine
[14:02:47] <KitsuWhooa> oh dear
[14:02:49] <abaumann> error: '/var/cache/pacman/pkg/coreutils-9.4-3.0-pentium4.pkg.tar.zst': invalid or corrupted package (PGP signature)
[14:02:52] <abaumann> aha, this is an interesting case for pacman-static.
[14:02:57] <abaumann> It calls gpg somewhere..
[14:03:06] <abaumann> which also has to exist statically.
[14:03:17] <KitsuWhooa> gtk3 is compiling locally
[14:03:41] <KitsuWhooa> oh lol I just saw this
[14:03:41] <KitsuWhooa> # atk bridge is missing, fast hack to work around atk-bridge/atk conflicts
[14:03:41] <KitsuWhooa> depends+=('at-spi2-core')
[14:04:05] <KitsuWhooa> Maybe it worked in the past?
[14:04:14] <abaumann> uh.
[14:04:15] <abaumann> oups.
[14:04:22] <abaumann> sounds like a patch from me :-)
[14:04:41] <abaumann> yes, that might even have been necessary in the past, now it is most likely just bothering you :-)
[14:05:03] <KitsuWhooa> oh maybe it works under depends
[14:05:05] <KitsuWhooa> I tried makedepends
[14:05:50] <KitsuWhooa> I'll try it like that later. I tried builing without the arch32 patch
[14:06:06] <abaumann> removing unexpected build artifact "icu73-debug-73.2-1.0-i486.pkg.tar.zst"
[14:06:06] <abaumann> I was only expecting:
[14:06:17] <abaumann> uh, this is also bad. Arch now always builds debug packages
[14:06:19] <KitsuWhooa> that is normal, right?
[14:06:24] <KitsuWhooa> Yeah it's been like this for a long while now
[14:06:31] <KitsuWhooa> it's why rust wouldn't build, because it'd force enable debug symbols
[14:06:38] <abaumann> yes, but the i486 VM refuses to upload the icu73 package because it saw an unexpected icu73-debug packaeg
[14:06:48] <KitsuWhooa> that shouldn't be the case
[14:06:54] <KitsuWhooa> as in, it should be working
[14:06:59] <KitsuWhooa> it just ignores the debug package
[14:07:19] <abaumann> ah. ok.
[14:07:31] <KitsuWhooa> https://tasossah.com
[14:07:32] <phrik> Title: debug pkgs (at tasossah.com)
[14:07:39] <KitsuWhooa> and it goes on
[14:09:50] <abaumann> ldd /usr/bin/ls linux-vdso.so.1 (0x00007fff59706000) libcap.so.2 => /usr/lib/libcap.so.2 (0x00007fb4b53f3000) libc.so.6 => /usr/lib/libc.so.6 (0x00007fb4b5211000) /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fb4b5463000)
[14:09:57] <abaumann> so it must be libcap
[14:10:04] <KitsuWhooa> huh
[14:10:15] <KitsuWhooa> wait, x86-64?
[14:10:28] <abaumann> yes.
[14:10:34] <KitsuWhooa> ...huh
[14:10:35] <abaumann> the libraries should be the same on arch32
[14:10:52] <abaumann> the ldd is from my machine, on the vm I cannot execute anything
[14:10:56] <KitsuWhooa> ooooh
[14:10:59] <KitsuWhooa> okay that makes sense
[14:11:05] <abaumann> libcap is the only dependency which also changed in the update
[14:11:18] <abaumann> no libc, and no linker helper library.
[14:11:19] <abaumann> so
[14:11:28] <abaumann> let me try to fix that from outside somehow.
[14:12:16] <KitsuWhooa> okay, yeah, depends+=('at-spi2-core') seems to work
[14:12:28] <abaumann> fine.
[14:12:42] <KitsuWhooa> I'll leave it as-is for now
[14:12:49] <KitsuWhooa> is there a way to figure out which packages keep atk around?
[14:13:34] <abaumann> mmh. database?
[14:13:49] <abaumann> maybe arch32 package info..
[14:13:51] <KitsuWhooa> I was wondering if there was a script
[14:14:00] <abaumann> ah, not that I'm aware of.
[14:14:06] <abaumann> maybe the buildmaster chatbot..
[14:14:17] <KitsuWhooa> I wish :p
[14:14:31] <abaumann> it can do jokes though ;-)
[14:14:33] <KitsuWhooa> I'll have to figure something out then
[14:14:57] <KitsuWhooa> my favourite buildmaster joke is:
[14:14:58] <KitsuWhooa> 21:37:29 <buildmaster> girls, Tasos, please have a look at my dirty database
[14:14:58] <KitsuWhooa> 21:37:29 * buildmaster goes insane.
[14:15:11] <KitsuWhooa> :D
[14:15:13] <abaumann> LOL :-)
[14:23:27] <abaumann> ls -la usr/lib/libpcap*
[14:23:28] <abaumann> lrwxrwxrwx 1 root root 12 Jan 15 2023 usr/lib/libpcap.so -> libpcap.so.1
[14:23:30] <abaumann> lrwxrwxrwx 1 root root 17 Jan 15 2023 usr/lib/libpcap.so.1 -> libpcap.so.1.10.3
[14:23:33] <abaumann> -rwxr-xr-x 1 root root 325088 Jan 15 2023 usr/lib/libpcap.so.1.10.3
[14:23:38] <abaumann> that's on testing
[14:23:40] <KitsuWhooa> 2023
[14:23:40] <abaumann> [root@arch32-stable ~]# ldd /usr/bin/ls linux-gate.so.1 (0xb7f1c000) libcap.so.2 => /usr/lib/libcap.so.2 (0xb7e9f000) libc.so.6 => /usr/lib/libc.so.6 (0xb7ca7000) /lib/ld-linux.so.2 => /usr/lib/ld-linux.so.2 (0xb7f1e000)
[14:23:57] <abaumann> this sounds like the buildmaster built an old libpcap
[14:24:02] <KitsuWhooa> I doubt it
[14:24:09] <KitsuWhooa> it wouldn't have a 2023 date on the .so
[14:24:18] <KitsuWhooa> I think it's been sitting in staging for a while and got pushed to testing
[14:25:01] <KitsuWhooa> wait I'm confused
[14:25:16] <abaumann> me too, stable has the newer version than testing.
[14:25:19] <KitsuWhooa> you wrote libpcap
[14:25:20] <KitsuWhooa> not libcap
[14:25:27] <KitsuWhooa> I'm confused even more now
[14:25:30] <KitsuWhooa> I thought the problem was with libcap
[14:25:33] <abaumann> I meant libcap, sorry
[14:25:46] <KitsuWhooa> the files above are libpcap
[14:25:56] <abaumann> uh. really?
[14:25:56] <KitsuWhooa> libcap is in stable
[14:25:57] <KitsuWhooa> yes
[14:25:59] <abaumann> grmpf
[14:26:52] <abaumann> /usr/lib/libcap.so.2.69
[14:26:56] <abaumann> yeah, both the same
[14:26:58] <abaumann> mmh.
[14:30:31] <KitsuWhooa> ModuleNotFoundError: No module named 'packaging'
[14:30:33] <KitsuWhooa> I'm sorry, what
[14:30:58] <abaumann> python-packaging?
[14:31:02] <KitsuWhooa> https://archlinux32.org
[14:31:04] <KitsuWhooa> I don't see it here
[14:31:04] <phrik> Title: Arch Linux 32 - gobject-introspection 1.80.1-1.2 (pentium4) (at archlinux32.org)
[14:31:12] <KitsuWhooa> ..I added it
[14:31:46] <KitsuWhooa> I tested it locally and it worked
[14:31:47] <KitsuWhooa> ugh
[14:34:03] <KitsuWhooa> wtf did buildmaster do
[14:34:24] <abaumann> !wtf did you do?
[14:34:24] <phrik> abaumann: wtf [is] <something>
[14:34:38] <KitsuWhooa> let's force another rebuild I guess
[14:34:41] <KitsuWhooa> !help wtf
[14:34:42] <phrik> KitsuWhooa: (wtf [is] <something>) -- Returns wtf <something> is. 'wtf' is a Unix command that first appeared in NetBSD 1.5. In most Unices, it's available in some sort of 'bsdgames' package.
[14:34:50] <KitsuWhooa> ah
[14:35:04] <abaumann> -rw-r--r-- 1 http mirror 10845424 Apr 18 16:27 icu73-73.2-1.1-i486.pkg.tar.zst
[14:35:07] <abaumann> -rw-r--r-- 1 http mirror 310 Apr 18 16:27 icu73-73.2-1.1-i486.pkg.tar.zst.sig
[14:35:10] <abaumann> -rw-r--r-- 1 http mirror 10843810 Apr 18 16:26 icu73-73.2-1.1-i686.pkg.tar.zst
[14:35:11] <KitsuWhooa> nice!
[14:35:13] <abaumann> -rw-r--r-- 1 http mirror 310 Apr 18 16:26 icu73-73.2-1.1-i686.pkg.tar.zst.sig
[14:35:16] <abaumann> -rw-r--r-- 1 http mirror 10846773 Apr 18 16:26 icu73-73.2-1.1-pentium4.pkg.tar.zst
[14:35:20] <abaumann> -rw-r--r-- 1 http mirror 310 Apr 18 16:26 icu73-73.2-1.1-pentium4.pkg.tar.zst.sig
[14:35:22] <abaumann> that worked
[14:35:24] <KitsuWhooa> !wtf wtf
[14:35:25] <abaumann> so I can build gettext and systemd now on i486
[14:35:26] <phrik> KitsuWhooa: extra/bash-completion
[14:35:34] <KitsuWhooa> !wtf is wtf
[14:35:35] <phrik> KitsuWhooa: extra/bash-completion
[14:35:35] <abaumann> guestmount -a /var/lib/libvirt/images/arch32-testing-pentium4.qcow2 -m /dev/sda2 /media/disk
[14:35:39] <abaumann> /media/disk/usr/bin/pacman-static --arch=pentium4 -U --config /media/disk/etc/pacman.conf --root=/media/disk/ /media/disk/var/cache/pacman/pkg/coreutils-9.4-3.0-pentium4.pkg.tar.zst
[14:35:48] <abaumann> that's quite annoying, but possible :-)
[14:36:16] <abaumann> I could have made a snapshot before updating, but, well..
[14:36:52] <KitsuWhooa> no one does that :p
[14:39:17] <KitsuWhooa> I rebuilt it, same thing
[14:39:18] <KitsuWhooa> I don't understand
[14:39:47] <KitsuWhooa> in fact
[14:39:55] <KitsuWhooa> *all* of the other depends are missing
[14:40:10] <KitsuWhooa> I just realised
[14:40:22] <KitsuWhooa> gobject-introspection is supposed to depend on python-setuptools
[14:40:24] <KitsuWhooa> which depends on -packaging
[14:40:27] <KitsuWhooa> ...except it doesn't
[14:40:50] <KitsuWhooa> we don't remove any deps in our PKGBUILD
[14:40:54] <KitsuWhooa> where the fuck do the dependencies go
[14:41:10] <abaumann> depends=(x) instead of depends+=(x)?
[14:41:22] <KitsuWhooa> nope
[14:41:37] <KitsuWhooa> in fact, even before I tried adding python-packaging, we didn't have setuptools
[14:41:40] <KitsuWhooa> which is why it fails in the first place
[14:41:54] <KitsuWhooa> can our build system not handle depends() inside a package function?
[14:42:07] <KitsuWhooa> https://gitlab.archlinux.org
[14:42:08] <abaumann> no, it has to be outside
[14:42:08] <phrik> Title: PKGBUILD · main · Arch Linux / Packaging / Packages / gobject-introspection · GitLab (at gitlab.archlinux.org)
[14:42:17] <KitsuWhooa> well that explains a lot
[14:42:20] <KitsuWhooa> how do we make it support it? :p
[14:42:21] <abaumann> it has to be known before the evals happen
[14:42:37] <KitsuWhooa> upstream arch do it
[14:42:44] <abaumann> you can just add the depends in the diff-PKGBUILD, without any eval/build whatever
[14:42:58] <KitsuWhooa> yes, but why would I do that?
[14:43:02] <KitsuWhooa> In this case, we don't need to add anything
[14:43:09] <KitsuWhooa> the build system straight up ignores the upstream depends
[14:43:34] <KitsuWhooa> ..does it?
[14:43:39] <KitsuWhooa> no it doe snot
[14:43:41] <KitsuWhooa> *does not
[14:43:48] <KitsuWhooa> but it does ignore all the python- ones
[14:44:22] <KitsuWhooa> og https://gitlab.archlinux.org
[14:44:24] <phrik> Title: 1.80.1-3: Add python-setuptools dep (137aeb90) · Commits · Arch Linux / Packaging / Packages / gobject-introspection · GitLab (at gitlab.archlinux.org)
[14:44:24] <KitsuWhooa> *oh
[14:44:26] <abaumann> I'm sure there are examples somewhere for that patching somewhere in our diff PKGBUiLDs
[14:44:57] <KitsuWhooa> it works if I makechrootpkg locally though
[14:45:09] <KitsuWhooa> if that was the case it wouldn't work with that either, right?
[14:45:48] <KitsuWhooa> oh I'm so dumb
[14:45:52] <KitsuWhooa> so dumb
[14:45:58] <KitsuWhooa> eval "$(declare -f package_gobject-introspection | sed 's@python-setuptools@python-setuptools python-packaging@')"
[14:46:05] <KitsuWhooa> there is no python-setuptools in the version we're building
[14:46:10] <KitsuWhooa> because it was added upstream recently
[14:46:21] <KitsuWhooa> nevermind, sorry, I figured it out :p
[14:47:09] <abaumann> glad you did :-)
[14:47:30] <abaumann> Those eval diff PKGBUILD thingies are not so easy to read.
[14:47:42] <KitsuWhooa> I think I got used to it at this point
[14:49:34] <KitsuWhooa> python: can't open file '/build/gobject-introspection/pkg/gobject-introspection/python-setuptools': [Errno 2] No such file or directory
[14:49:59] <KitsuWhooa> I messed up the patching again
[14:50:02] <KitsuWhooa> I'll get there
[15:45:46] <KitsuWhooa> abaumann: can you push gtk3?
[15:47:40] <KitsuWhooa> (I'll spend the time to figure out how to move packages soon, I promise :p)
[15:52:44] <KitsuWhooa> let's see if that fixes lightdm on the laptop
[15:53:07] <KitsuWhooa> /usr/bin/gtk-query-immodules-3.0: symbol lookup error: /usr/lib/libpango-1.0.so.0: undefined symbol: g_once_init_leave_pointer
[15:53:45] <KitsuWhooa> I guess something else is fucky
[15:54:02] <KitsuWhooa> maybe pango needs a rebuild?
[15:56:33] <abaumann> ah, pango lacks a symbol in glib (g_once_init_leave_pointer), maybe pango got rebuild, then glib and glib dropped the g_once_init_leave_pointer symbol
[15:57:01] <KitsuWhooa> I think it's atk...
[15:57:04] <KitsuWhooa> https://old.reddit.com
[15:57:27] <KitsuWhooa> hm
[15:57:30] <abaumann> uh.
[15:57:39] <abaumann> yes, that seems to be the described issue
[15:57:50] <KitsuWhooa> maybe rebuild at-spi2-core
[15:57:51] <KitsuWhooa> let me try that
[15:58:12] <KitsuWhooa> but hey, now that we fixed this python issue, more gtk apps will build
[15:58:49] <abaumann> true that
[16:02:29] <KitsuWhooa> abaumann: rebuilding that got me further
[16:02:35] <KitsuWhooa> now I get /usr/bin/gtk-query-immodules-3.0: symbol lookup error: /usr/lib/libatspi.so.0: undefined symbol: g_once_init_leave_pointer
[16:02:39] <KitsuWhooa> so libatspi needs to be rebuilt
[16:02:53] <KitsuWhooa> wait
[16:02:56] <KitsuWhooa> I'm confused
[16:03:08] <KitsuWhooa> that is literally at-spi2-core
[16:03:20] <KitsuWhooa> something is in staging that isn't in stable...
[16:05:01] <KitsuWhooa> abaumann: glib2 wasn't pushed...
[16:06:08] <KitsuWhooa> and gobject-introspection also needs to be pushed
[16:09:02] <KitsuWhooa> and gio
[16:09:18] <KitsuWhooa> oh, that's from glib2
[16:11:35] <KitsuWhooa> yeah uh, lots of things need rebuilding
[16:12:38] <KitsuWhooa> lightdm-gtk-greeter did get rebuilt
[16:12:59] <KitsuWhooa> tasos@nightopia:~$ lightdm
[16:12:59] <KitsuWhooa> lightdm: /usr/lib/libmount.so.1: version `MOUNT_2_40' not found (required by /usr/lib/libgio-2.0.so.0)
[16:13:44] <KitsuWhooa> okay, util-linux needs to be pushed too
[16:15:44] <KitsuWhooa> including util-linux-libs
[16:16:19] <KitsuWhooa> I got lightdm up
[16:17:23] <KitsuWhooa> util-linux-libs util-linux glib2 libgirepository gobject-introspection-runtime gobject-introspection at-spi2-core at-spi2-core-docs
[16:17:28] <KitsuWhooa> these are what I had to upgrade from staging
[16:18:07] <KitsuWhooa> and now I have a working desktop again
[16:18:21] <abaumann> quite some modules
[16:18:42] <KitsuWhooa> let's now make sure the system reboots :p
[16:19:40] <KitsuWhooa> yup, works
[16:19:56] <abaumann> so, let's push those packages
[16:20:01] <KitsuWhooa> mhm
[16:20:05] <abaumann> I soon have a i486 systemd ready
[16:20:09] <KitsuWhooa> wesome
[16:20:11] <KitsuWhooa> awesome
[16:31:03] <abaumann> ah, now I have a dbus-units issue on i486.
[16:34:04] <abaumann> /usr/lib/systemd/system/dbus.service exists in both 'dbus' and 'dbus-broker-units'
[16:34:07] <abaumann> /usr/lib/systemd/user/dbus.service exists in both 'dbus' and 'dbus-broker-units'
[16:34:10] <abaumann> Errors occurred, no packages were upgraded.
[16:34:12] <abaumann> yea, I'll tackle this tomorrow..
[16:37:13] <abaumann> nice jwm, lightdm work :-)
[16:43:52] <KitsuWhooa> perfect
[16:43:59] <KitsuWhooa> You need to rebuild dbus
[19:27:55] -!- abaumann has quit [Ping timeout: 260 seconds]
[22:11:28] -!- bdju has quit [Ping timeout: 260 seconds]