#archlinux32 | Logs for 2025-03-29

Back
[00:13:33] -!- sL1pKn07 has quit [Quit: Client Excited...]
[00:13:47] -!- sL1pKn07 has joined #archlinux32
[13:18:23] -!- abaumann has joined #archlinux32
[13:18:23] <buildmaster> Hi abaumann!
[13:18:23] <buildmaster> !rq abaumann
[13:18:24] <phrik> buildmaster: <abaumann> if analog tv would have been engineered nowadays with all this software nonsense, it would explode every second weekend..
[13:19:58] <abaumann> So, giving up on bootstrapping Python: ptyhon-bootstrap builds something, leading to trouble afterwards. All python-setutools, python-build, modules have a bootstrap=0/1 flag, which doesn't have correct checksums in the case bootstrap=1, I wonder, why this comes in a duplicate to python-bootstrap. Python people are just creating a big mess out of everything and upstream Arch is not well documented,
[13:20:02] -!- abaumann has quit [Client Quit]
[14:02:50] -!- drathir_tor has quit [Remote host closed the connection]
[14:03:15] -!- drathir_tor has joined #archlinux32
[15:40:42] <girls> I came to report, that named is crashing on pentium4 with "error while loading shared libraries: libicuuc.so.75: cannot open shared object file: No such file or directory" for me :-( I forced them onto euronuc now, I hope, that's ok for you, abaumann :)
[15:56:00] <girls> somehow, the caching of the PKGBUILDs seems broken, at least, the buildmaster is complaining, if I try to schedule bind again.
[16:01:15] <girls> ah, I see. Somehow, it tries to fetch two versions. Only one should be needed, though.
[16:25:43] -!- abaumann has joined #archlinux32
[16:25:44] <buildmaster> Hi abaumann!
[16:25:44] <buildmaster> !rq abaumann
[16:25:45] <phrik> buildmaster: <abaumann> still.. I'm close to declare pacman-static the official pacman :->
[16:25:52] <abaumann> girls: force ahead.. that's what euronuc is for.. :-)
[16:25:53] <girls> Hi abaumann!
[16:25:55] <abaumann> hi
[16:25:56] <girls> :D
[16:26:30] <girls> if I read the log correctly, the bind build currently fails with a checksum error :(
[16:26:50] <abaumann> it does? oh.
[16:27:06] <girls> at least on i486
[16:27:19] <abaumann> lemme see
[16:27:20] -!- srvntx has quit [Remote host closed the connection]
[16:27:20] -!- drathir_tor has quit [Read error: Connection reset by peer]
[16:27:32] <girls> the pentium4 and i686 builds went through
[16:27:34] <girls> strange
[16:27:44] -!- srvntx has joined #archlinux32
[16:27:50] -!- drathir_tor has joined #archlinux32
[16:28:05] <abaumann> there was an issue arount http+git sources which cannot be checksummed on i486 only..
[16:28:21] <girls> that would make sense
[16:29:04] <girls> ah, stupid me: the respective machine runs on stable repos - I should just have moved bind from testing to stable
[16:29:53] <abaumann> ah. :-)
[16:30:07] <girls> the i486 thing is real, though
[16:30:41] <girls> yeah, 9.20.7 is just not built for i486: https://www.archlinux32.org
[16:30:42] <phrik> Title: Arch Linux 32 - Package Search (at www.archlinux32.org)
[16:32:34] <abaumann> core-staging-i486-build builds
[16:32:59] <abaumann> at least on a x86_64 build chroot
[16:33:26] <girls> building for i486?
[16:33:33] <girls> that would be good :)
[16:33:36] <abaumann> yep. for a fast build.
[16:33:40] <abaumann> but now I
[16:33:47] <abaumann> 'm testing it on the 486 vm..
[16:39:12] -!- srvntx has quit [Ping timeout: 264 seconds]
[16:39:41] <girls> buildmaster: why don't you stabilize pentium/bind
[16:39:42] <buildmaster> girls: Cannot find package "pentium/bind"
[16:40:16] <girls> buildmaster: why don't you stabilize bind
[16:40:17] <buildmaster> girls: "pentium4/bind" is not tested.
[16:40:17] <buildmaster> "i686/bind" is not tested.
[16:40:39] <girls> lemme fix that >:-)
[16:41:08] -!- srvntx has joined #archlinux32
[16:41:28] <abaumann> bind9 ... FAILED
[16:41:30] <abaumann> yes, bingo
[16:44:21] <girls> buildmaster: why don't you stabilize pentium4/bind?
[16:44:23] <buildmaster> girls: "pentium4/bind" depends on "pentium4/readline","pentium4/xz","pentium4/aarch64-linux-gnu-glibc","pentium4/libxml2","pentium4/libcap","pentium4/liburcu" which must be moved simultanously
[16:44:23] <buildmaster> "pentium4/bind" replaces dependencies of "pentium4/sssd","pentium4/testssl.sh","pentium4/bind","pentium4/dnssec-tools" which must be replaced simulatanously
[16:48:43] <girls> buildmaster: why don't you unstage pentium4/bind?
[16:48:44] <buildmaster> girls: "pentium4/bind" depends on "pentium4/libedit","pentium4/openssl","pentium4/julia","pentium4/liburcu","pentium4/zlib","pentium4/gcc-libs","pentium4/gcc13","pentium4/krb5","pentium4/readline","pentium4/riscv64-linux-gnu-gcc","pentium4/libidn2","pentium4/bash","pentium4/aarch64-linux-gnu-gcc","pentium4/riscv64-linux-gnu-glibc","pentium4/libuv","pentium4/libxml2","pentium4/systemd-libs","pentium4/gcc13-libs" which must be moved s
[16:48:44] <buildmaster> "pentium4/bind" replaces dependencies of "pentium4/dnssec-tools","pentium4/sssd","pentium4/testssl.sh","pentium4/bind" which must be replaced simulatanously
[16:49:03] <girls> so many loose ends :-(
[16:50:48] <abaumann> tell me more. I just wanted to update my NAS and then ended up in a two week pacman/libarchive session. :-)
[16:56:37] <KitsuWhooa> <abaumann> So, giving up on bootstrapping Python: ptyhon-bootstrap builds something, leading to trouble afterwards. <-- did they change things again upstream?
[16:57:28] <abaumann> I have to read more, what they are doing. :-)
[17:00:09] <abaumann> Basically I don't know that the sequence is: python-bootstrap, then bootstrap=1 in some python packages, then with bootstrap=0?
[17:00:27] <girls> probably 'yes'
[17:00:46] <girls> maybe we should move all the bootstrap=1 packages into build-support?
[17:02:25] <girls> ModuleNotFoundError: No module named 'elftools'
[17:02:28] <girls> gnaaaa
[17:02:51] <abaumann> yes, python.. :-)
[17:02:56] <girls> I can't look into the linking error in named :(
[17:03:07] <girls> yeah, thought so
[17:10:07] <KitsuWhooa> bootstrap=0 wasn't a thing before
[17:10:09] <KitsuWhooa> Or 1
[17:10:35] <KitsuWhooa> Just copy all the upstream pre built packages into build support :)
[17:10:45] <KitsuWhooa> I'm not joking
[17:11:16] <KitsuWhooa> All the basic jaraco and setuptools stuff. Download it from upstream into build support and the builders will build stuff
[17:11:21] <girls> we could also just "proxy" the "any" packages for building somewhere
[17:41:45] <girls> That would actually be quite easy: The buildmaster could just download all any packages into a separate "any" repo, which would be available for all build slaves as a separate straw (or in the with-build-support straw). WDYT?
[18:07:24] -!- drathir_tor has quit [Ping timeout: 264 seconds]
[18:08:28] -!- abaumann has quit [Quit: leaving]
[18:19:00] -!- drathir_tor has joined #archlinux32
[18:35:53] -!- srvntx has quit [Remote host closed the connection]
[18:35:54] -!- drathir_tor has quit [Remote host closed the connection]
[18:36:25] -!- srvntx has joined #archlinux32
[18:40:53] -!- srvntx has quit [Remote host closed the connection]
[18:41:23] -!- srvntx has joined #archlinux32
[18:46:11] -!- drathir_tor has joined #archlinux32
[19:09:12] -!- drathir_tor has quit [Ping timeout: 264 seconds]
[19:15:46] -!- drathir_tor has joined #archlinux32
[19:33:56] <girls> this would add 28 packages from core and another 4965 from extra
[19:36:18] <girls> adding another 25999338342 bytes to the mirror(s)
[19:36:32] <girls> that's 26GB
[19:37:46] <girls> The buildmaster has enough space to accomodate this, but it's maybe a bit much for all downstream mirrors :-/
[20:14:54] <KitsuWhooa> <girls> That would actually be quite easy: The buildmaster could just download all any packages into a separate "any" repo, which would be available for all build slaves as a separate straw (or in the with-build-support straw). WDYT?
[20:15:20] <KitsuWhooa> I honestly think we should mirror upstream's packages that are "any" arch and not rebuild them ourselves
[20:16:33] <KitsuWhooa> Is there a way we can add upstream arch repos to our builders and filter only "any" packages?
[20:16:57] <KitsuWhooa> Maybe if we make a proxy that modifies the db on the fly
[20:17:34] <girls> I'm currently adding a separate repo containing all upstream any packages and would just add that to the builders
[20:17:49] <KitsuWhooa> That works too
[20:17:59] <KitsuWhooa> But I'd personally prefer if we didn't build the packages
[20:18:04] <girls> I'm not sure, that copying all any packages for arch32 is a good idea, though: some differ for arch32, even though, they are any
[20:18:16] <KitsuWhooa> We can override those
[20:18:40] <girls> yeah, but that's would be a different override mechanism than what we currently have
[20:18:44] <KitsuWhooa> If package has patch then build it, else copy it
[20:19:16] <girls> hmm, that would be a build-slave-only solution
[20:19:19] <girls> also not bad
[20:19:37] <KitsuWhooa> There are some theme packages that need node to build and block python
[20:19:44] <KitsuWhooa> Having those available as is would make life easier
[20:20:00] <KitsuWhooa> Not core python, but some python packages
[20:20:05] <girls> yeah, question is, whether it would also be ok to have them just in build-support for the builders
[20:20:21] <KitsuWhooa> To a certain extent, yes
[20:20:50] <KitsuWhooa> But I think with the lack of resources we have, it makes sense to copy the packages
[20:21:09] <KitsuWhooa> Maybe download, verify sig, resign with our builder keys, upload
[20:21:29] <girls> no need to resign, we can just tell people to also install the upstream keyring
[20:21:49] <KitsuWhooa> Ah, right
[20:21:58] <KitsuWhooa> The upstream keyring is also "any", right?
[20:22:03] <girls> yep
[20:22:09] <KitsuWhooa> So we won't have to risk it being unavoidable
[20:22:13] <KitsuWhooa> *unbuildable
[20:22:42] <KitsuWhooa> Also
[20:22:46] <KitsuWhooa> Glad to see you around :)
[20:22:50] <girls> :D
[20:24:23] <KillerWasp> I'm the people that wait a keyring that work fine. 🙂
[20:24:50] <girls> regarding the keyring: all hope is lost (or rather: I lost all hope)
[20:25:17] <KillerWasp> lol, What a fatalist
[20:25:49] <KillerWasp> which's the problem with the keyring?
[20:26:06] <girls> how about this: we add "any" packages in a separate repository. If we see, that this helps (automatically) building other packages, we keep them for builders only. If it keeps a mess, we add this repo to regular pacman.confs and remove unmodified any-packages from our repositories?
[20:26:26] <girls> the problem with the keyring is, that gpg is just a too-mighty tool for what arch and arch32 use it
[20:26:37] <KitsuWhooa> can you keep the mirror up to date?
[20:26:47] <KitsuWhooa> with no maintenance?
[20:26:51] <girls> sure, I'll add a cronjob to the buildmaster
[20:26:54] <KitsuWhooa> if so, then 100% go for it
[20:27:05] <KitsuWhooa> it will absolutely help with the builders
[20:27:18] <KitsuWhooa> I've been adding python and ruby and perl packages en masse to build support when I was bootstrapping them
[20:27:21] <KitsuWhooa> it made life so much easier
[20:27:28] <KitsuWhooa> *build support manual
[20:27:44] <girls> yes, I'm sure about that. The question is, whether any "any" packages remain unbuildable, still.
[20:27:53] <KitsuWhooa> there will be
[20:28:00] <KitsuWhooa> as I mentioned, documentation themes that need node
[20:28:04] <KitsuWhooa> but
[20:28:10] <KitsuWhooa> if we were to push this repo to the end users
[20:28:21] <KitsuWhooa> does pacman have a "priority" system?
[20:28:25] <girls> yes
[20:28:32] <girls> top to bottom
[20:28:36] <KillerWasp> It sounds like Arch32 needs a cryptography system that is beyond what GPG can offer.
[20:28:38] <KitsuWhooa> does it take versions into account?
[20:28:45] <KitsuWhooa> *way less than gpg
[20:28:49] <KitsuWhooa> it's too complicated
[20:29:09] <girls> crux did the right thing IMHO: they went for signify
[20:29:20] <KitsuWhooa> I'm thinking that if there's an old version of any package in our repo, but upstream has newer one, then will pacman prefer ours?
[20:29:26] <KitsuWhooa> that'd be an issue for end users
[20:29:39] <girls> KitsuWhooa: no, it just picks the first package, that it finds, going through the repos as defined in pacman.conf
[20:30:06] <KitsuWhooa> yes but if we give higher priority to the upstream any mirror clone, then we can't override packages
[20:30:11] <KitsuWhooa> again, for end users
[20:30:15] <girls> we would either need to put the any repo on top or clean our repositories from old/unmodified packages proactively
[20:30:27] <girls> yes
[20:30:30] <KitsuWhooa> the latter is not possible with buildmaster
[20:30:37] <KitsuWhooa> it won't be aware of the versions
[20:30:43] <girls> I think, the final state would be, that we only have overriding "any"s in our repos
[20:31:07] <girls> yes, we would need to write some filter for any packages: No modification -> don't schedule it for a build
[20:31:35] <KitsuWhooa> I was thinking of: i686 package depends on any
[20:31:37] <KitsuWhooa> ...
[20:32:17] <girls> right, we would not move "any" packages around like we do with architecture specific ones. That might be an issue for things like python. Hmm.
[20:32:19] <KitsuWhooa> I was thinking of: i686 package depends on "any" package. The "any" package is unbuildable now and our repos have an ancient version. If we remove the "any" package from our repos, then buildmaster won't build the i686 package because the "any" doesn't exist
[20:32:41] <girls> we could also kill those links in the buildmaster
[20:32:48] <KitsuWhooa> ah, hm
[20:32:51] <girls> then it wouldn't know, that such a dependency existed in the first place
[20:32:59] <KitsuWhooa> that sounds like it'll work
[20:33:10] <KitsuWhooa> the website won't show them though
[20:33:24] <girls> but still, you run into trouble if you have e.g. a architecture specific package, that depends on a specific version of an "any" package.
[20:33:41] <KitsuWhooa> it should be okay though, no?
[20:33:49] <KitsuWhooa> upstream will have the correct version
[20:34:03] <girls> e.g. something, that is compiled, but needs a specific version of a python packge.
[20:34:24] <KitsuWhooa> I think it'd need a rebuild anyway
[20:34:28] <girls> but our package will break, as soon as we replace the upstream any package with the newest version
[20:34:30] <KitsuWhooa> as it'd break because no one is holding python
[20:34:36] <girls> yes, but until that happens, it's broken
[20:34:52] <KitsuWhooa> it'll be broken anyway though
[20:35:06] <girls> no, it would work with the old version of the "any" package still
[20:35:21] <KitsuWhooa> do packages depend on minor versions?
[20:35:24] <KitsuWhooa> or rather
[20:35:30] <girls> the clean solution to this is, to move "any" packages (from upstream) through staging/testing/stable, too
[20:35:35] <KitsuWhooa> hm
[20:35:49] <girls> well, we can iterate from the "only for build slaves" solution :)
[20:35:55] <KitsuWhooa> yup
[20:36:21] <KitsuWhooa> When I get the time (ha ha) I'll try looking into seeing if I can make buildmaster pretend to build any packages by simply downloading them
[20:36:26] <KitsuWhooa> and leaving everything else the same
[20:37:29] <girls> could even be a separate script, that scrapes the db for build tasks, that should build an "any" package
[20:37:35] <girls> keep it modularized ;)
[20:37:57] <KitsuWhooa> I think that introduces more chances of race conditions
[20:38:07] <KitsuWhooa> and just things going wrong in general
[20:38:19] <girls> there is a filter, which slave can build which architecture (so e.g. you do not task a i486 slave with building for pentium4) - one could extend that to no longer hand out "any" packages to the builders
[20:38:47] <KitsuWhooa> mhm, yeah
[20:39:17] <girls> ah, no. You want to hand out _some_ "any" packages to the builders :-(
[20:40:12] <KitsuWhooa> oh, right
[20:40:15] <KitsuWhooa> yeah not all are the same
[20:40:28] <girls> there's "any" and "any" ;)
[20:40:40] <girls> and not any "any" will do
[20:41:22] <girls> hmm, the mirror script is quite slow. Maybe I should not make it check the sha256sum :-/
[20:48:09] <girls> checking file size seems almost similarly slow :-o
[20:51:11] <KitsuWhooa> Ouch
[22:29:15] <girls> ok, the mirror for any should now work. Though, this is a really weak "should". I'll have a look tomorrow, whether it actually does something. Next step will be to add these repos to the builders.