#archlinux32 | Logs for 2025-03-16

Back
[06:04:05] -!- tippfehlr has quit [Read error: Connection reset by peer]
[06:06:06] -!- tippfehlr has joined #archlinux32
[08:25:06] -!- f_ has quit [Ping timeout: 246 seconds]
[08:25:57] -!- f_ has joined #archlinux32
[08:35:09] -!- SurfBlueCrab has joined #archlinux32
[08:49:20] -!- ssserpent has joined #archlinux32
[09:02:06] -!- ssserpent has quit [Ping timeout: 272 seconds]
[09:04:24] -!- jacobk_ has quit [Ping timeout: 260 seconds]
[09:04:35] -!- jacobk has joined #archlinux32
[09:14:56] -!- abaumann has joined #archlinux32
[09:14:57] <buildmaster> Hi abaumann!
[09:14:57] <buildmaster> !rq abaumann
[09:14:57] <phrik> buildmaster: <abaumann> sometimes I get the feeling that the only thing developing fast on Linux is the number of new bugs.
[09:15:36] <abaumann> so, having pacman-static, pacman-conf-static and bsdtar-static as the systems pacman, pacman-conf and bsdtar should make my build chroot able to build again..
[09:30:52] -!- ssserpent has joined #archlinux32
[09:33:51] -!- titus_livius has joined #archlinux32
[09:36:16] -!- buildmaster has joined #archlinux32
[10:04:23] -!- ssserpent has quit [Quit: WeeChat 4.5.2]
[10:06:08] -!- ssserpent has joined #archlinux32
[10:27:29] -!- ssserpent has quit [Ping timeout: 248 seconds]
[11:59:46] -!- ssserpent has joined #archlinux32
[12:18:58] <abaumann> now I have hen and egg problems with muon-meson and libarchive, this starts to get really annoying..
[12:19:32] <abaumann> depends=(pkgconf curl libarchive)
[12:19:40] <abaumann> well, I understand pkgconf, but curl? libarchive?
[12:20:09] <abaumann> a build tool should _NOT_ load anything from the internet. und unpacking can be done with tar/bsdtar, why do they have to embedd everything?
[12:20:23] <abaumann> And yeah, of course, it contains a samurai or ninja too, I'm sure..
[12:22:34] <KitsuWhooa> > a build tool should _NOT_ load anything from the internet
[12:22:36] <KitsuWhooa> the car goes
[12:22:39] <KitsuWhooa> :p
[12:22:59] <abaumann> the car also tracks your movements and sells it to marketing companies.. that's what a car is for.. ;-)
[12:23:21] <KitsuWhooa> while displaying ads in the centre console every time you stop :)
[12:23:29] <abaumann> it can be switched off, so I can muild a minimal version of muon-meson
[12:23:48] <abaumann> the libarchive/curl, not the ads - I'm afraid ;-)
[12:28:10] <abaumann> aha -D libarchive=false and it links with libarchive.so. nice./
[12:28:58] <KitsuWhooa> clean?
[12:29:03] <KitsuWhooa> as in, maybe it needs a clean
[12:29:05] <abaumann> new chroot
[12:29:07] <KitsuWhooa> rip
[12:29:42] <abaumann> src/external/meson.build looks, ahem..
[12:29:44] <abaumann> ..not so nice.
[12:30:47] <abaumann> ah, yes, found src/muon-v0.3.1/src/external/samurai
[12:30:58] <abaumann> so, embedded dependy management.
[12:31:28] <abaumann> ah, there is a bootstrap.sh script..
[12:32:05] <abaumann> which just links with everything and the kitchen sink. *sigh*
[12:32:26] <abaumann> libpkgconf
[12:32:29] <abaumann> actually only. mmh.
[12:33:06] <abaumann> I could just use the stage1 muon at build-stage1/muon
[12:34:05] <KitsuWhooa> meanwhile, I have no idea what muon is
[12:34:17] <KitsuWhooa> > An implementation of the meson build system in c99
[12:34:22] <abaumann> yes, the bootstrapping is ok. its failing in stage 2 (which is wrong in the AUR package because you need the same features as for stage 3)
[12:34:31] <abaumann> muon is a C implementation of meson.
[12:34:34] <abaumann> Actually really nice
[12:34:37] <KitsuWhooa> I didn't know it was possible
[12:34:45] <KitsuWhooa> because meson files are literally python, no?
[12:34:56] <abaumann> with a 'muon meson' subcommand which tries to be so close as possible to meson itself.
[12:35:29] <abaumann> I think so, yes.
[12:35:46] <abaumann> That's also something I'm wondering, you cannot possible reimplement half of python in muon..
[12:35:59] <abaumann> maybe it knows just some constructs..
[12:36:11] <abaumann> ..I didn't investigate the source in detail yet..
[12:36:35] <abaumann> ..but seems other people think that build tools should not be written in python.. :-)
[12:37:10] <KitsuWhooa> I am not looking forward to bootstrapping python
[12:38:18] <abaumann> There should really be something like a minimal python, eventually embedding all core python packages into one.
[12:38:35] <abaumann> so there would only be the need to have a single build-support python-minimal package
[12:38:58] <abaumann> all this separate python packages in Arch are nice, but they unpractical for bootstrapping.
[12:39:11] <KitsuWhooa> idk how debian does it
[12:39:19] * abaumann shrugs
[12:39:53] <KitsuWhooa> Honestly, I think we should try to use any arch packages as-is from upstream
[12:40:09] <KitsuWhooa> it'd make things like python and ruby and perl so much easier :p
[12:41:44] <abaumann> well, for building, yes. but the final packages should look like in upstream Archlinux, otherwise it's not Archlinux32 anymore.. :-)
[12:41:58] <KitsuWhooa> no, I mean for end users
[12:42:09] <abaumann> ah
[12:42:14] <KitsuWhooa> I don't see the point in us wasting resources building packages that will be identical
[12:42:19] <KitsuWhooa> but we have to fight dependency cycles for
[12:42:40] <KitsuWhooa> I'm talking about arch=any
[12:43:39] <abaumann> it's that 'reproducability of builds' thing
[12:44:10] <KitsuWhooa> it's not like upstream always has reproducible builds
[12:44:20] <KitsuWhooa> so us trying to do that with source material that isn't meant for it makes things even worse
[12:45:10] <KitsuWhooa> but we don't have the manpower for it anyway
[12:45:20] <abaumann> true.
[12:46:43] <abaumann> the easy way to fix libxml2 currently would have been just to reactivate the autoconfig configure.ac stuff..
[12:47:07] <abaumann> ..but having a non-Python replacement for meson has so much bigger potential benefits for other packages..
[12:47:59] <abaumann> mmh. stage2 muon doesn't understand options.
[12:48:13] <abaumann> well. the project is a nice example of how to bootstrap such a tool.
[12:48:26] <KitsuWhooa> :p
[12:48:41] <abaumann> actually, embedding a samurai is not the worst idea. otherwise you would most likely have to bootstrap with a shell and gnu make.
[12:51:32] <abaumann> amalgam.c: external/libarchive_null.c, ok, nice. stage1 is free of dependencies
[12:51:42] <KitsuWhooa> why are we amalgamating things in 2025
[12:51:48] <abaumann> for bootstrapping
[12:51:57] <KitsuWhooa> okay that makes sense
[12:52:03] <abaumann> it's an easy way to run 'cc -o stage1-muon *.c'
[12:52:22] <abaumann> it's just an include for .c files.
[12:52:37] <abaumann> So technically, it's not the amalgamation I know from sqlite3 for instance.
[12:52:49] <abaumann> but it's using the preprocessor to concatenate things.
[12:52:52] <abaumann> which is fine :-)
[12:55:30] <KitsuWhooa> yeah that's better :p
[12:56:31] <abaumann> build-stage1/muon has trouble with -D libpkgconf=false, which is weird, as it works with build-stage2/muon setup
[12:57:55] <abaumann> error unable to coerce 'false' into a feature meson_tests_repo ,type string.
[12:58:01] <abaumann> as if the hash of options is messed up..
[12:58:35] <abaumann> mmh. can we build stage3 with stage1? I doubt it..
[13:02:54] <abaumann> ah, boolean and feature
[13:03:07] <abaumann> one is true/false, the other disabled/enabled
[13:03:11] <abaumann> this is just - weird
[13:03:30] <abaumann> and the error message is bad
[13:05:20] <abaumann> ok. that's it. works.. :-)
[13:05:43] <abaumann> just some options have to be repeated from stage3 when building from stage 1
[13:05:54] <KitsuWhooa> 🎉
[13:06:02] <abaumann> modules/i18n.meson:241:30: error method 'version_compare' not found on void
[13:06:02] <abaumann> 241 | if not actual_version.version_compare(needed_version)
[13:06:07] <abaumann> oh intl issues..
[13:06:57] <abaumann> this is also something which gets lost: disabled i18n. I don't always want emoticon support in a binary build seed :-)
[13:07:20] <abaumann> modules/i18n.meson:241:30: error method 'version_compare' not found on void
[13:07:28] <abaumann> well, this could be something meson -> muon related
[13:07:48] <KitsuWhooa> yeah that's what I am thinking
[13:07:52] <abaumann> there is a -Dstatic=true for a static muon, this is nice
[13:08:21] <abaumann> ah, a test. who cares about tests :-)
[13:08:57] <abaumann> muon was able to build itself, three times, that's enough testing to prove the thing is working.
[13:09:50] <abaumann> let's hope libxml2 doens't croak later on in missing gettext support in meson/muon..
[15:39:55] <abaumann> new muon in build-support, libxml2 with -D icu=disabled builds, fine :-)
[15:44:09] -!- phrik has quit [Remote host closed the connection]
[15:44:48] -!- phrik has joined #archlinux32
[15:47:19] <abaumann> *sigh* libarchive breaks happilly in xar support because of libxml2 being minimal?
[15:47:27] <abaumann> or not providing some legacy api?
[15:48:04] <abaumann> an archive needs libxml2, ok, that's not a package format I can think of, let's try to disable libxml2 support in libarchive
[15:48:44] <abaumann> hehe, configure and --without-xml2
[15:50:40] -!- johancb has quit [Quit: Konversation terminated!]
[15:50:56] -!- johancb has joined #archlinux32
[15:51:33] <abaumann> ah, yeah, should know that, it's also built like that in pacman-static
[17:44:22] mavicaway is now known as mavica
[18:35:51] -!- ssserpent has quit [Ping timeout: 246 seconds]
[18:38:10] -!- ssserpent has joined #archlinux32
[18:51:25] -!- ssserpent has quit [Ping timeout: 260 seconds]
[18:54:12] -!- drathir_tor has quit [Ping timeout: 264 seconds]
[19:14:45] -!- drathir_tor has joined #archlinux32
[19:30:12] -!- abaumann has quit [Quit: leaving]
[20:48:05] mavica is now known as mavicaway
[21:07:12] -!- jacobk has quit [Ping timeout: 276 seconds]
[21:07:27] -!- jacobk has joined #archlinux32
[22:10:12] -!- jacobk_ has joined #archlinux32
[22:10:15] -!- jacobk has quit [Ping timeout: 276 seconds]