#archlinux32 | Logs for 2024-02-05

Back
[03:19:50] -!- drathir_tor has quit [Ping timeout: 255 seconds]
[03:40:48] -!- drathir_tor has joined #archlinux32
[05:02:54] -!- epony has quit [Remote host closed the connection]
[05:03:58] -!- epony has joined #archlinux32
[05:41:13] -!- abouvier has quit [Quit: kthxbye]
[05:42:17] -!- abouvier has joined #archlinux32
[07:43:22] <KitsuWhooa> abaumann: the keyring package is still broken I think
[07:43:33] <KitsuWhooa> I tried https://aur.archlinux.org and that still hasn't fixed anything
[07:43:34] <phrik> Title: AUR (en) - archlinux32-keyring-git (at aur.archlinux.org)
[07:44:26] <KitsuWhooa> as for getting the whole thing unstuck, once we get it working, if we put the package in releng, then buildmaster should trust it
[07:44:39] <KitsuWhooa> as for the builders, we can temporarily put the releng repo at the top and it'll pull the package from releng instead
[07:45:05] <KitsuWhooa> but even if I can fix the keyring, I don't have a key that's trusted to sign it with...
[07:47:30] <KitsuWhooa> I guess I should try to build the one you made in packages
[07:56:32] <KitsuWhooa> yeah that doesn't work either
[08:15:03] <KitsuWhooa> > archlinux32-keyring-v20240131.tar.gz ... FAILED (unknown public key C17F1214114574A4)
[08:21:58] <KitsuWhooa> I do not understand why the keyring package doesn't work
[08:45:09] <KitsuWhooa> also, https://buildmaster.archlinux32.org checks the keyring that's in the database
[08:51:02] -!- drathir_tor has quit [Ping timeout: 255 seconds]
[08:53:11] -!- drathir_tor has joined #archlinux32
[08:53:48] -!- drathir_tor has quit [Remote host closed the connection]
[08:56:51] <KitsuWhooa> pacman-key gets things going again, so something is definitely up with the keyring package, but who knows what
[08:58:15] -!- drathir_tor has joined #archlinux32
[09:25:48] <KitsuWhooa> abaumann: Idk if you can figure this out, but here's a diff from before running pacman-key --refresh-keys and after (it works after) https://tasossah.com
[09:25:55] <KitsuWhooa> couldn't find a way to share a side by side diff as text
[09:40:59] -!- abouvier_ has joined #archlinux32
[09:41:04] -!- abouvier has quit [Ping timeout: 268 seconds]
[09:41:11] abouvier_ is now known as abouvier
[09:56:44] -!- epony has quit [Remote host closed the connection]
[09:57:22] -!- epony has joined #archlinux32
[10:18:13] <zxrom> KitsuWhooa, In my case the command 'pacman-key --refresh-keys' does not help.
[10:36:49] -!- abouvier_ has joined #archlinux32
[10:44:10] -!- abouvier has quit [*.net *.split]
[10:44:30] abouvier_ is now known as abouvier
[10:45:47] <KitsuWhooa> I suspect you need the new keyring package first for that to work
[10:58:39] <zxrom> KitsuWhooa, new keyring package?
[10:59:24] <zxrom> archlinux32-keyring 20231126-1.4
[11:26:58] <KitsuWhooa> the one from releng, https://mirror.archlinux32.org
[11:26:59] <phrik> Title: Index of /x86_64/releng (at mirror.archlinux32.org)
[11:36:33] <KitsuWhooa> > 2024-02-05 11:35:47: building package "archlinux32-keyring" (revisions 0000000000000000000000000000000000000000 ffe6d36470ef77d4f4f55755718d31a2a9039f84, repository core, straw :with_build_support:clean_chroot:) for pentium4 ... failed.
[11:36:37] <KitsuWhooa> there goes the chance of building the new keyring
[11:38:29] <KitsuWhooa> oh I think that's the old one again
[11:38:52] <KitsuWhooa> yup, it's the 2023 one
[14:52:22] -!- drathir_tor has quit [Remote host closed the connection]
[14:52:50] -!- drathir_tor has joined #archlinux32
[14:59:40] -!- epony has quit [Remote host closed the connection]
[15:00:17] -!- epony has joined #archlinux32
[16:02:08] -!- drathir_tor has quit [Ping timeout: 255 seconds]
[16:21:14] -!- drathir_tor has joined #archlinux32
[16:28:41] -!- abaumann has joined #archlinux32
[16:28:41] <buildmaster> Hi abaumann!
[16:28:42] <buildmaster> !rq abaumann
[16:28:42] <phrik> buildmaster: <abaumann> doesn't ## uncomment the #? ;-)
[16:28:56] <abaumann> the buildmaster builds the wrong git revision over and over again for archlinux32-keyring
[16:29:21] <abaumann> and the Arch32 releasing private key expired (hence the source package is not trusted for archlinux32-keyring)
[16:29:27] <abaumann> pub rsa4096 2020-01-20 [SC] [expired: 2023-12-31] 33CA3597B0D161AAE4173F65C17F1214114574A4
[16:29:30] <abaumann> uid [ expired] Archlinux 32 Release Key <release@archlinux32.org>
[16:31:19] <KitsuWhooa> abaumann: have you seen my messages?
[16:31:26] <abaumann> yep.
[16:31:31] <KitsuWhooa> even building the keyring manually, it is still broken for me
[16:31:51] <abaumann> ah, with the AUR package
[16:31:57] <KitsuWhooa> with the AUR package
[16:32:01] <KitsuWhooa> but also from core/archlinux32-keyring
[16:32:04] <abaumann> you have to build it,install it and do a pacman-key --populate archlinux32
[16:32:05] <KitsuWhooa> I cloned it and ran makepkg
[16:32:18] <KitsuWhooa> I can't run that inside my builders though
[16:32:25] <KitsuWhooa> as in, it won't work, will it?
[16:32:25] <abaumann> yep.
[16:32:35] <abaumann> I mean.. nope.
[16:32:50] <abaumann> I fear a henn and egg issue is on the horizon. :-)
[16:33:06] <KitsuWhooa> is it possible for the keyring package itself to fix this?
[16:33:10] <abaumann> I usually force things to a specific slave, then I inject the fix directly there.
[16:33:25] <KitsuWhooa> because as I said, we can inject the keyring from releng
[16:33:29] <abaumann> But this only works, if it stops to build the 2023 package and starts to use the proper one from 2024
[16:33:38] <KitsuWhooa> releng has the 2024 one
[16:33:40] <KitsuWhooa> and it is still broken
[16:33:57] <abaumann> so, we are back to the missing signatures from poli
[16:34:05] <KitsuWhooa> https://mirror.archlinux32.org
[16:34:08] <KitsuWhooa> this doesn't work
[16:34:12] -!- epony has quit [Quit: QUIT]
[16:34:19] <abaumann> mmh. let me fetch it and test it.
[16:34:34] <KitsuWhooa> it only worked for me after I installed it *and* ran pacman-key --refresh-keys
[16:34:39] <KitsuWhooa> and the diff was in that screenshot
[16:34:43] <KitsuWhooa> which I couldn't understand
[16:34:51] <abaumann> the pacman-key --refresh is enough.
[16:35:01] <abaumann> but it defies the purpose of having a new keyring, sort of.
[16:35:15] <KitsuWhooa> well, either way
[16:35:18] <abaumann> I thought, the builders are doing a pacman-key -refresh-keys before building?
[16:35:20] <KitsuWhooa> it did something that the keyring package didn't
[16:35:24] <KitsuWhooa> nope
[16:35:33] <KitsuWhooa> at least if it did, it'd work I think
[16:35:44] <abaumann> that's also an option: hack a local build-packages and just add a pacman-key --refresh inside the chroot or so
[16:35:56] <KitsuWhooa> that still won't fix the keyring package though
[16:35:58] <KitsuWhooa> even if it gets built
[16:36:57] <abaumann> I hate to admit it, but I'm still on caught on my weak spot: GPG. I simply cannot handle the simplest things there.. exchange keys, let them be signed, add them somwhere.
[16:37:02] <KitsuWhooa> if you look at this https://archlinux32.org
[16:37:12] <KitsuWhooa> it installed archlinux32-keyring-20240131-1
[16:37:24] <KitsuWhooa> yet my key was still marginal trust
[16:37:37] <KitsuWhooa> > but I'm still on caught on my weak spot: GPG. <-- likewise
[16:37:54] <abaumann> wget https://mirror.archlinux32.org
[16:38:05] <abaumann> pacman -U archlinux32-keyring-20240131-1-any.pkg.tar.zst
[16:38:08] <abaumann> pacman -S coreutils
[16:38:27] <abaumann> this works on a previously broken machine (coreutils is signed by your signing key)
[16:38:36] <KitsuWhooa> ...so why is it broken for me
[16:38:41] <abaumann> let me remove /etc/pacman.d/gnupg to make sure
[16:38:42] <KitsuWhooa> and buildmaster presumably
[16:38:49] <KitsuWhooa> buildmaster also has the 2024 package installed
[16:39:26] <abaumann> yes, but that one is only used for local pacman installations for 64-bit
[16:39:47] <KitsuWhooa> ah, hm
[16:40:01] <abaumann> maybe.
[16:40:07] <abaumann> otherwise it would work?
[16:40:13] <KitsuWhooa> I have no idea
[16:41:48] <abaumann> removing /etc/pacman.d/gnupg before installing the releng 2024 keyring
[16:41:54] <abaumann> and I can still install software
[16:42:11] <KitsuWhooa> okay, so, any idea what I can do to my builders to fix them? :p
[16:42:34] <KitsuWhooa> I already did rm -rf /var/lib/archbuild*
[16:43:05] <abaumann> First, does the signing happen inside the chroot or outside the chroot
[16:43:18] <abaumann> (more of a retorical question here, really)
[16:43:20] <KitsuWhooa> why does the signing matter?
[16:43:35] <abaumann> ah, it's outside.
[16:43:40] <abaumann> no, shouldn't matter.
[16:44:01] <KitsuWhooa> my current issue is that the builder won't install packages because it doesn't trust the signatures
[16:44:04] <abaumann> so it can only be the user of the build slave (builder or slave1, slave2 in my case) which has to have the proper keys installed for verification
[16:44:05] <KitsuWhooa> it doesn't even get to the part of building anything
[16:44:23] <abaumann> ah, before spawning the chroot.
[16:44:33] <KitsuWhooa> isn't it inside the chroot?
[16:44:34] <abaumann> So this is still the build user
[16:44:36] <KitsuWhooa> oh
[16:44:39] <KitsuWhooa> oh
[16:44:39] <abaumann> no, don't think so
[16:44:43] <KitsuWhooa> ...that explains things
[16:44:56] <KitsuWhooa> although I have the 2024 keyring on the build user
[16:45:05] <KitsuWhooa> as in, outside the chroot
[16:45:19] <abaumann> so, maybe exporting the keys (basically my master public key) and importing it into the build users gpg should work
[16:45:42] <abaumann> the build user doens't use /etc/pacman.d/gnupg I suppose.
[16:45:45] <abaumann> It uses .gnupg
[16:45:59] <KitsuWhooa> let's nuke both for good measure :p
[16:46:58] <abaumann> well gpg --refresh 38ACA6A026D25CDD227D24832F6399DCD2212195
[16:48:28] <KitsuWhooa> ...I think I just nuked my signing key from the builder
[16:48:30] <KitsuWhooa> whoops
[16:48:41] <abaumann> that's unfortunate
[16:48:50] <KitsuWhooa> I should be able to export it from another one
[16:48:53] <abaumann> yep
[16:49:10] <KitsuWhooa> okay yeah this appears to have fixed it
[16:49:13] <KitsuWhooa> I'm installing packages again
[16:49:38] <KitsuWhooa> and then I can look at the db to see why it's not building the new package
[16:49:40] <abaumann> there is still something on the buildmater maybe not accepting the key, I'm also trying to build something on eurobuild6-`
[16:49:43] <abaumann> 1
[16:50:54] <abaumann> ==> WARNING: Warnings have occurred while verifying the signatures. Please make sure you really trust them.
[16:50:57] <abaumann> mmh.
[16:51:13] <abaumann> most likely old keys in an old archbuild chroot
[16:51:18] <abaumann> openssl-3.2.1.tar.gz ... Passed (WARNING: the key has expired.)
[16:51:30] <abaumann> sure, now that one expired
[16:52:48] <KitsuWhooa> I ran refresh on another builder
[16:52:49] <KitsuWhooa> > gpg: key 2F6399DCD2212195: "Andreas Baumann <mail@andreasbaumann.cc>" not changed
[16:53:17] <KitsuWhooa> but on builder3 it succeeded
[16:55:51] <abaumann> downloading "https://arch.eckner.net/os/x86_64/archlinux32-keyring-20231126-1-any.pkg.tar.xz" ... failed. Next ...
[16:55:54] <abaumann> what the?
[16:56:02] <KitsuWhooa> that is a 404
[16:56:13] <abaumann> yes, why does it take the package from there?!
[16:56:18] <KitsuWhooa> oh
[16:56:20] <KitsuWhooa> that I do not know
[16:56:27] <abaumann> ==> Adding package 'archlinux32-keyring-20231126-1.5-any.pkg.tar.zst'
[16:56:29] <KitsuWhooa> maybe you have a local mirror set?
[16:56:39] <abaumann> -rw-r--r-- 1 http mirror 310 Feb 5 17:56 archlinux32-keyring-20231126-1.5-any.pkg.tar.zst.sig
[16:56:42] <abaumann> -rw-r--r-- 1 http mirror 37703 Feb 5 17:56 archlinux32-keyring-20231126-1.5-any.pkg.tar.zst
[16:56:54] <abaumann> yes, I can build a keyring, but now the scheduling of packages is just plain wrong.
[16:56:59] <abaumann> I want version 2024
[16:57:15] <abaumann> Ifn that doesn't work I doubt any dependency calculation is working currently in the buildmaster
[16:57:28] <abaumann> archlinux32-keyring 0000000000000000000000000000000000000000 ffe6d36470ef77d4f4f55755718d31a2a9039f84 0f244ec5d9f98315cda1e437b59150201a822118 core
[16:58:54] <KitsuWhooa> there are a lot of packages with priority 45 (highest)
[16:59:05] <KitsuWhooa> and I don't see the keyring anywhere
[16:59:19] <KitsuWhooa> oh there it is
[16:59:23] <abaumann> the priorization should solve that.
[16:59:26] <KitsuWhooa> ffe6d36470ef77d4f4f55755718d31a2a9039f84
[16:59:30] <KitsuWhooa> it
[16:59:34] <KitsuWhooa> it's going to build that one again
[16:59:34] <abaumann> ./prioritize-build-list -d -w <(printf '^archlinux32-keyring$\n' )
[16:59:48] <KitsuWhooa> have you ran get package updates?
[17:00:05] <abaumann> ffe6d36470ef77d4f4f55755718d31a2a9039f84 is old and Sun Nov 26 20:50:55 2023 +0100
[17:00:16] <abaumann> I want 0f244ec5d9f98315cda1e437b59150201a822118 with priority one
[17:00:23] <KitsuWhooa> yes, I know :p
[17:00:41] <KitsuWhooa> give me a bit to get the other two builders up and I'll look into it
[17:00:46] <KitsuWhooa> that said
[17:00:48] <KitsuWhooa> glibc failed to build
[17:00:59] <abaumann> almost everything fails to build, so yeah
[17:01:26] <abaumann> as I said: in the past I spent 2 hours a day patching all kind of packages, now sind 3/4 years not at all.
[17:01:28] <KitsuWhooa> configure: error: "CET is only supported on x86_64 or x32"
[17:01:36] <abaumann> I'm frankly surprised anything builds
[17:01:51] <abaumann> urgh,
[17:01:55] <KitsuWhooa> isn't x32 supposed to be 32 biut?
[17:01:56] <KitsuWhooa> *bit
[17:01:58] <abaumann> nope
[17:02:10] <abaumann> thats 64-bit kernel with 32-bit user space per process
[17:02:15] <KitsuWhooa> ah
[17:02:21] <abaumann> if that's true, we are doomed.
[17:02:29] <abaumann> or CET can be disabled.
[17:02:38] <KitsuWhooa> I assume so
[17:02:41] <abaumann> I think, the sedfu just completely failed to patch PKGBUILD
[17:02:48] <KitsuWhooa> perhaps
[17:03:02] <abaumann> it usually does and you don't get any feedback.
[17:05:22] <abaumann> I'm trying your ./schedule-for-rebuild-test-no-sort -w -j -p '^archlinux32-keyring$' -t now
[17:05:31] <abaumann> this should give me more than one version to build
[17:05:35] <KitsuWhooa> hopefully
[17:05:37] <abaumann> 1 any archlinux32-keyring 0000000000000000000000000000000000000000 ffe6d36470ef77d4f4f55755718d31a2
[17:05:43] <abaumann> and it hangs since a minute..
[17:05:47] <abaumann> ..let's hope :-)
[17:06:00] <KitsuWhooa> I doubt it
[17:06:08] <KitsuWhooa> actually, maybe
[17:08:11] <KitsuWhooa> something is holding a lock
[17:09:16] <abaumann> ah, it's not hanging. It wants me to choose that one (wrong) version :-)
[17:09:33] <KitsuWhooa> ah...
[17:09:38] <KitsuWhooa> have you ran get-package-updates?
[17:09:49] <abaumann> yes, long time ago.
[17:09:56] <KitsuWhooa> try running it again
[17:10:01] <KitsuWhooa> because it's not aware of the new keyring package at all
[17:10:03] <KitsuWhooa> if it doesn't show up in that list
[17:10:19] <KitsuWhooa> actually
[17:10:22] <KitsuWhooa> make a new commit on it first
[17:10:25] <KitsuWhooa> for good luck :p
[17:11:09] <abaumann> 76590297a10a77417206903bba7c35855891e773 new revision
[17:11:36] <abaumann> archlinux32-keyring 0000000000000000000000000000000000000000 76590297a10a77417206903bba7c35855891e773 core
[17:11:51] <KitsuWhooa> oh?
[17:11:52] <KitsuWhooa> did that work?
[17:11:59] <abaumann> in get-package-updates. Now I only have to wait to got through 20 minutes of haskell
[17:12:01] <KitsuWhooa> ah
[17:12:03] <KitsuWhooa> hahahaha
[17:12:03] <KitsuWhooa> yes
[17:12:07] <KitsuWhooa> sometimes it's really fast
[17:12:19] <abaumann> very soon I'm hacking this stuff out, it's just annoying
[17:12:53] <KitsuWhooa> okay, so to fix the keyring issues on my builders I just need to rm -rf /etc/pacman.d/gnupg, pacman-key --init, and then install the keyring packages
[17:13:02] <KitsuWhooa> ~/.gnupg doesn't affect anything
[17:13:16] <abaumann> not even the signing key?
[17:13:24] <KitsuWhooa> it shouldn't
[17:13:28] <KitsuWhooa> my signing key is still there and valid
[17:13:30] <KitsuWhooa> it never expired
[17:13:35] <abaumann> so it uses pacman keys for verification.
[17:13:54] <KitsuWhooa> well, yes
[17:13:55] <abaumann> so having just the signing key in the build users .gnupg is enough
[17:14:09] <KitsuWhooa> pacman is using its own keys when it's doing the equivalent of pacstrap in the chroot, no?
[17:14:20] <abaumann> yes
[17:14:23] <KitsuWhooa> I thought the issue was inside the chroot, which is why I was very confused
[17:14:40] <abaumann> yes, this _is_ very confusing
[17:17:28] <KitsuWhooa> okay, builders are up
[17:17:46] <KitsuWhooa> if you can queue up the keyring and it gets pushed to mine, it will build
[17:18:48] <abaumann> that's my hope too :-)
[17:19:34] <KitsuWhooa> builder 2 is currently uploading python-pytest-metadata
[17:19:36] <KitsuWhooa> so that's a good sign
[17:19:44] <KitsuWhooa> as in, it's adding it to the database
[17:19:48] <KitsuWhooa> so it passed validation
[17:19:50] <KitsuWhooa> yup
[17:20:06] <abaumann> good
[17:20:14] <KitsuWhooa> or, well, I don't know if you disabled it again in buildmaster
[17:20:18] <KitsuWhooa> but it definitely uploaded a file
[17:20:41] <abaumann> -rw-r--r-- 1 http mirror 566 Feb 5 18:19 python-pytest-metadata-3.1.0-1.0-any.pkg.tar.zst.sig
[17:20:44] <abaumann> -rw-r--r-- 1 http mirror 16384 Feb 5 18:19 python-pytest-metadata-3.1.0-1.0-any.pkg.tar.zst
[17:20:47] <abaumann> yep, looks good
[17:20:57] <abaumann> it wouldn't upload a file
[17:21:03] <KitsuWhooa> how's the haskell? :p
[17:21:09] <abaumann> it did yesterday when I hacked return-assignment
[17:21:35] <abaumann> but that's no problem, as the packages are signed ok, as soo the keyring lands, everyting is valid
[17:21:41] <abaumann> haskelling
[17:21:43] <KitsuWhooa> I hope so
[17:21:53] <abaumann> haskell-pem
[17:21:58] <KitsuWhooa> ouch
[17:22:02] <KitsuWhooa> it hasn't even gotten to haskell-s yet
[17:22:16] <abaumann> and this with caching pkginfo
[17:22:26] <KitsuWhooa> I think get-package-updates would be faster if it didn't constantly lock and unlock
[17:22:47] <KitsuWhooa> perhaps it should be configurable
[17:22:55] <abaumann> of course.
[17:23:18] <abaumann> I'm thinking about an option --fast-I-know-I-will-loose-dependencies-possibly
[17:23:22] <KitsuWhooa> this is fine for default behaviour, but when you're anxiously waiting for it to finish, it doesn't matter if it blocks everything else from running
[17:23:23] <KitsuWhooa> hahaha
[17:23:35] <KitsuWhooa> sounds worse than -ffast-math
[17:23:43] <KitsuWhooa> uploading another python package
[17:24:04] <abaumann> the development cycle with git push package, get-pacakge-updates, ~/force build must be as fast as possible
[17:24:15] <abaumann> otherwise life is just painful
[17:24:17] <KitsuWhooa> yes :p
[17:24:28] <KitsuWhooa> I think it'd also be nice if there was a way to fetch the local updates without checking upstream
[17:24:40] <KitsuWhooa> because it might fetch new packages and make things even worse
[17:24:48] <KitsuWhooa> local as in, mod commits
[17:25:36] <abaumann> the problem is that you have to execute get-package-updates just to get a new mod revision building, yes.
[17:25:43] <abaumann> this needs a shortcut
[17:26:18] <KitsuWhooa> built another python package
[17:26:26] <abaumann> archlinux32-devops has no errors anymore, or not any signing-related.
[17:26:55] <KitsuWhooa> yup
[17:37:06] <KitsuWhooa> any luck?
[17:37:16] <abaumann> Yes,
[17:37:17] <abaumann> sort of
[17:37:23] <abaumann> I could select the right version now
[17:37:38] <abaumann> -rw-r--r-- 1 http mirror 566 Feb 5 18:35 archlinux32-keyring-20240131-3.0-any.pkg.tar.zst.sig
[17:37:41] <abaumann> -rw-r--r-- 1 http mirror 37787 Feb 5 18:35 archlinux32-keyring-20240131-3.0-any.pkg.tar.zst
[17:37:43] <KitsuWhooa> ooooh!
[17:37:44] <abaumann> yep
[17:37:49] <abaumann> let me push it to stable
[17:37:55] <KitsuWhooa> sure enough, builder2 built it
[17:37:58] <KitsuWhooa> how do you push it to stable?
[17:38:07] <KitsuWhooa> I was looking at the scripts but I couldn't figure it out
[17:38:28] <abaumann> ~/pushall archlinux32-keyring > ~/x; source ~/x
[17:38:41] <abaumann> on the buildmaster, just a small shell script wrapper..
[17:38:47] <abaumann> ..and a dangerous one! :-)
[17:38:54] <KitsuWhooa> ah, I see
[17:39:05] <abaumann> firstly and mainly: there is no un-push ;-)
[17:39:28] <abaumann> oups. forced it a second time.. well..
[17:39:41] <abaumann> push moves from testing to stable and staging to testing
[17:39:49] <abaumann> so usually you have to force a single package twice
[17:40:01] <KitsuWhooa> I see
[17:41:17] <KitsuWhooa> the key graph still shows the 2023 one, hmmm
[17:41:47] <KitsuWhooa> staging now has a 2023 one
[17:41:49] <KitsuWhooa> hmm
[17:41:52] <KitsuWhooa> oh god no
[17:41:52] <KitsuWhooa> https://www.archlinux32.org
[17:42:05] * KitsuWhooa screams
[17:42:14] <abaumann> mmh?
[17:42:27] <KitsuWhooa> Error 500: Internal Server Error Inconsistency in Database found: buildmaster[version] != repositories[Version]: "20240131-3.0" != "20231126-1.4"
[17:42:39] <abaumann> sigh
[17:42:45] <KitsuWhooa> I suspect if you run a sanity check it'll fail
[17:43:02] <KitsuWhooa> staging has 20231126-1.5
[17:43:11] <KitsuWhooa> stable has 20240131-3.0
[17:43:21] <abaumann> this doesn't make any sense
[17:43:23] <KitsuWhooa> and it expects 20231126-1.4
[17:43:24] <KitsuWhooa> lovely
[17:43:36] <KitsuWhooa> sorry, I meant testing, not staging
[17:43:45] <KitsuWhooa> https://www.archlinux32.org
[17:43:48] <KitsuWhooa> > Error 404: Package Not Found In Buildmaster's Database
[17:43:49] <KitsuWhooa> you tell me
[17:44:02] <abaumann> this is just the web frontend
[17:44:06] <abaumann> I saw it breaking before
[17:44:06] <KitsuWhooa> ah, hm
[17:44:12] <abaumann> it might not be adapted to the git moves
[17:44:26] <abaumann> :: File /var/cache/pacman/pkg/archlinux32-keyring-20240131-3.0-any.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
[17:44:36] <KitsuWhooa> ...
[17:44:41] <abaumann> this is the only problem: henn-and-egg to install the new keyring
[17:44:56] <KitsuWhooa> are your builders trusted?
[17:45:10] <abaumann> I hope so ;-)
[17:45:10] <KitsuWhooa> as in, is your key still trusted
[17:45:15] <KitsuWhooa> if so, try building it on yours
[17:45:25] <abaumann> ah. good idea
[17:45:32] <KitsuWhooa> I'll shut mine down
[17:45:36] <KitsuWhooa> so it queues it up on yours
[17:45:55] <abaumann> I was _forcing_ them to my build slaves, but this never worked reliably
[17:46:26] <abaumann> or better: any ready slave can take away something which has been forced onto a spefic slave
[17:46:37] <KitsuWhooa> mhm
[17:46:44] <abaumann> archlinux32-keyring 0000000000000000000000000000000000000000 76590297a10a77417206903bba7c35855891e773 76590297a10a77417206903bba7c35855891e773 core
[17:46:47] <abaumann> archlinux32-keyring 0000000000000000000000000000000000000000 ffe6d36470ef77d4f4f55755718d31a2a9039f84 76590297a10a77417206903bba7c35855891e773 core
[17:46:50] <abaumann> mmh.
[17:47:07] <abaumann> well, I hope, it works automatically now too without choosing the right version.
[17:47:15] <KitsuWhooa> it won't
[17:47:20] <KitsuWhooa> it'll pick the last one
[17:47:35] <KitsuWhooa> yup
[17:47:48] <KitsuWhooa> https://tasossah.com
[17:48:05] <KitsuWhooa> and now it's building
[17:48:16] <abaumann> the wrong one
[17:48:19] <KitsuWhooa> yup
[17:48:25] <abaumann> but on the correct slave ;-)
[17:48:25] <KitsuWhooa> it seems to always pick the last one on the list
[17:48:29] <abaumann> progress (half-way)
[17:48:32] <KitsuWhooa> yup
[17:48:39] <KitsuWhooa> at least you can pick the right one :p
[17:49:03] -!- epony has joined #archlinux32
[17:49:11] <abaumann> 1 any archlinux32-keyring 0000000000000000000000000000000000000000 ffe6d36470ef77d4f4f55755718d31a2a9039f84 core
[17:49:14] <abaumann> mmh.
[17:49:15] <abaumann> that's better
[17:49:29] <abaumann> maybe it had a temporary transitional state?
[17:49:34] <KitsuWhooa> I have no idea
[17:49:45] <KitsuWhooa> isn't ffe the wrong one?
[17:49:50] <KitsuWhooa> that's the one that's queued up
[17:49:58] <abaumann> ah. right.
[17:50:04] <KitsuWhooa> we want the 765 one
[17:50:29] <abaumann> yeah, I didn't get it anymore as option..
[17:50:41] <KitsuWhooa> oh
[17:50:44] <KitsuWhooa> interesting
[17:50:51] <KitsuWhooa> uhhhh
[17:50:55] <abaumann> yeah, the buildmaster is buggy
[17:51:00] <KitsuWhooa> time to make another commit? :p
[17:51:02] <KitsuWhooa> and wait for haskell
[17:51:05] * KitsuWhooa shudders
[17:51:06] <abaumann> right.
[17:51:07] <abaumann> on it
[17:52:04] <abaumann> archlinux32-keyring 0000000000000000000000000000000000000000 cfd3357923c6bee35ce34e313c082384342e1e49 core
[17:52:10] <KitsuWhooa> better
[18:00:47] <abaumann> ls -altr archlinux32-keyring-*
[18:00:47] <abaumann> -rw-r--r-- 2 http mirror 310 Feb 13 2022 archlinux32-keyring-transition-20220209-1.0-any.pkg.tar.zst.sig
[18:00:50] <abaumann> -rw-r--r-- 2 http mirror 35881 Feb 13 2022 archlinux32-keyring-transition-20220209-1.0-any.pkg.tar.zst
[18:00:53] <abaumann> -rw-r--r-- 2 http mirror 310 Feb 5 18:40 archlinux32-keyring-20231126-1.5-any.pkg.tar.zst.sig
[18:00:56] <abaumann> -rw-r--r-- 2 http mirror 37786 Feb 5 18:40 archlinux32-keyring-20231126-1.5-any.pkg.tar.zst
[18:00:59] <abaumann> -rw-r--r-- 1 http mirror 310 Feb 5 18:50 archlinux32-keyring-20231126-1.7-any.pkg.tar.zst.sig
[18:01:02] <abaumann> -rw-r--r-- 1 http mirror 37760 Feb 5 18:50 archlinux32-keyring-20231126-1.7-any.pkg.tar.zst
[18:01:05] <abaumann> aha, the 2024 package even got removed.
[18:01:10] <KitsuWhooa> great :p
[18:01:20] <abaumann> let's hope it was a glitch
[18:01:48] <KitsuWhooa> it did it because you scheduled the 2023 one
[18:01:51] <KitsuWhooa> so it overwrote it
[18:01:56] <KitsuWhooa> at least that's how I see it
[18:02:57] <abaumann> a package should _never_ be overwritten.
[18:03:02] <KitsuWhooa> ah
[18:03:06] <abaumann> that would be new
[18:16:58] <abaumann> -rw-r--r-- 1 http mirror 310 Feb 5 19:14 archlinux32-keyring-20240131-4.0-any.pkg.tar.zst.sig
[18:17:01] <abaumann> -rw-r--r-- 1 http mirror 37730 Feb 5 19:14 archlinux32-keyring-20240131-4.0-any.pkg.tar.zst
[18:17:04] <abaumann> better? maybe?
[18:17:20] <KitsuWhooa> if it's trusted, yes
[18:17:46] <abaumann> mmh. how do I test now that, I have to go back in time.. aeh kerying.. ;-)
[18:18:26] <KitsuWhooa> I can try pacman -Syu on my laptop
[18:18:28] <KitsuWhooa> and see what happens
[18:18:36] <abaumann> oh, cool
[18:18:47] <abaumann> yeah, I also figured out a way to test it
[18:19:46] <abaumann> error: archlinux32-keyring: signature from "Andreas Baumann (sign) <mail@andreasbaumann.cc>" is unknown trust
[18:19:49] <abaumann> :: File /var/cache/pacman/pkg/archlinux32-keyring-20240131-4.0-any.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
[18:19:51] <KitsuWhooa> welp
[18:19:52] <abaumann> Do you want to delete it? [Y/n]
[18:19:55] <abaumann> same
[18:19:57] <KitsuWhooa> I guess we can't do anything then
[18:20:09] <KitsuWhooa> I can try enabling rechenknecht
[18:20:11] <KitsuWhooa> and see if that can build it
[18:21:13] <abaumann> ah, good point, but I think it has to do a pacman-key --refresh first
[18:21:21] <abaumann> but even then i couldn't install the new archlinux32-keyring
[18:21:31] <abaumann> "manual intervention needed"
[18:21:40] <KitsuWhooa> maybe
[18:21:52] <KitsuWhooa> but I haven't seen any errors that recheknecht's key isn't trusted
[18:21:57] <KitsuWhooa> but then it hasn't been building anything recently
[18:27:33] <abaumann> it does now.
[18:28:25] <KitsuWhooa> my laptop upgraded archlinux32-keyring just fine
[18:28:32] <abaumann> uff. good news.
[18:28:40] <KitsuWhooa> 20240131-4.0
[18:28:47] <abaumann> yep. same here.
[18:28:57] <abaumann> ok.. let's call it fixed. :-)
[18:29:07] <KitsuWhooa> I hope so
[18:29:08] <abaumann> (till furhter notice - aka complaints)
[18:30:22] <abaumann> ah. the 2023 package got the official one again on the mirror, the old 2024 was moved to the archive
[18:30:28] <abaumann> then the new 2024 was published
[18:30:30] <abaumann> all fine
[18:48:13] <abaumann> mmh. mixed feelings.
[18:48:29] <abaumann> I always had to do a pacman-key --refresh on two test machines
[18:48:40] <abaumann> I could install the 2024 keyring package, but then no other package after that
[18:49:16] <KitsuWhooa> I just did pacman -S archlinux32-keyring and everything else worked
[18:49:26] <KitsuWhooa> pacman -Syu failed because it didn't prioritise the keyring
[18:49:30] <KitsuWhooa> but I think that's arch/pacman in general
[18:49:46] <KitsuWhooa> wait
[18:49:49] <KitsuWhooa> wait no it didn't work
[18:50:01] <KitsuWhooa> pacman -Syu failed afterwards because it didn't trust my key
[18:50:10] <KitsuWhooa> so we're back to what I said about the new keyring package not working
[18:50:15] <KitsuWhooa> when I built it manually
[18:50:26] <KitsuWhooa> if I rm -rf /etc/pacman.d/gnupg and reinstall the package I bet it'll work
[18:53:06] <KitsuWhooa> so they keyring package itself was trusted, but it didn't make other things trusted
[18:53:20] <KitsuWhooa> my key is still marginal
[18:57:18] <abaumann> the last idea I have is actually, that they key has not been updated in the archlinux32-keyring source tarball
[18:57:21] <abaumann> ..and repo
[19:07:38] <abaumann> oh, no relase key and buff-di-wuff
[19:07:43] <abaumann> oh man.
[19:08:05] <KitsuWhooa> hm?
[19:08:26] <abaumann> it's not easy to get the new keyring sources up to somewhere PKGBUILD picks it up
[19:10:09] <abaumann> nobody should complain afterswards.. I have to read source code all the time to see what the tools are doing..
[19:14:39] <abaumann> sources.archlinux32.org: it seems to contain things uploaded via a makefile (which is broken to another server than the buildmaster) and a background process buff-di-wuff whcih fetches files from a download list, computes checksums and puts them into the same place
[19:14:43] <abaumann> not confusing at all :-)
[19:15:02] <abaumann> another get-package-updates round :-)
[19:17:18] <abaumann> I really hope the update-keys script in archlinux32-keyring does what it says it does.
[19:17:36] <abaumann> And I don't have to run it on a weird machine of sorts in order to produce valid keys
[19:17:49] <abaumann> they were different from the ones in 20240131
[19:18:47] <KitsuWhooa> well, let me know when it's built so that I'll test it on the laptop
[19:20:39] <abaumann> okidoke
[19:26:49] <KitsuWhooa> ...why is python3.11 in stable
[19:46:16] <abaumann> because of a forced move.. or becuase there was a timeout. I remember this happens when the buildmaster has to wait for a package too long
[19:46:46] <abaumann> this means, outstanding bugs have to be actively fixed in that time period, which might no longer be realistic
[19:50:05] <KitsuWhooa> welp
[19:53:23] <abaumann> /startdir/PKGBUILD: line 20: cd: /build/archlinux32-keyring/src/archlinux32-keyring-v20240131: No such file or directory
[19:53:26] <abaumann> cool.
[19:53:28] <abaumann> after one hour.
[19:53:39] <abaumann> one mistake and you go a long way over
[19:53:43] <abaumann> this is no fun
[19:53:50] <abaumann> I have this enough at work
[19:53:51] <KitsuWhooa> can you not makepkg it locally to see if it works?
[19:53:58] <abaumann> yes. I can.
[19:54:02] <abaumann> but if I forget
[19:54:15] <abaumann> remember: I didn't do anything in here for months
[19:54:20] <KitsuWhooa> ah, that's fair
[19:54:22] <abaumann> I forgot most of it :-)
[19:55:15] <abaumann> yeah, collosal messup between _pkgver and pkgver
[19:55:17] <abaumann> nice :-)
[19:55:26] <abaumann> and "do it again, Sam" :-)
[19:59:32] <KitsuWhooa> you're almost there I think
[20:00:49] -!- epony has quit [Remote host closed the connection]
[20:02:09] -!- epony has joined #archlinux32
[20:05:37] -!- epony has quit [Remote host closed the connection]
[20:14:15] -!- epony has joined #archlinux32
[20:29:36] <KitsuWhooa> or maybe not :p
[20:32:02] <abaumann> another key(ring)
[20:33:01] <abaumann> I still have to force it unto the system, but afterwards it seems ok.
[20:35:50] <abaumann> sigh, something is still weird.. giving up for today..
[20:36:20] <abaumann> but the keyring looks much less red now :-)
[20:36:28] <abaumann> https://buildmaster.archlinux32.org
[20:37:02] <abaumann> cu
[20:37:03] -!- abaumann has quit [Quit: leaving]
[20:39:34] <KitsuWhooa> thanks! See ya
[20:42:19] <KitsuWhooa> abaumann: It worked!!
[22:28:41] -!- zxrom has quit [Quit: Leaving]
[22:35:42] <KitsuWhooa> okay glibc is easy
[23:51:12] -!- mvchtz has quit [Ping timeout: 256 seconds]