#archlinux32 | Logs for 2024-08-15

Back
[00:20:21] -!- drathir_tor has quit [Ping timeout: 260 seconds]
[00:27:12] -!- drathir_tor has joined #archlinux32
[05:26:02] -!- T`aZ has quit [Remote host closed the connection]
[06:17:25] -!- ssserpent has joined #archlinux32
[06:25:33] -!- ssserpent has quit [Ping timeout: 252 seconds]
[06:27:43] -!- ssserpent has joined #archlinux32
[06:56:35] -!- abaumann has joined #archlinux32
[06:56:36] <buildmaster> Hi abaumann!
[06:56:36] <buildmaster> !rq abaumann
[06:56:37] <phrik> buildmaster: <abaumann> meson adds another layer of f*ups
[06:56:46] <abaumann> The buildmaster got an insanity on linux-api-headers.
[06:57:01] <abaumann> That's the package which should be on 6.10, was on 6.8 and got downgraded to 6.7
[06:57:29] <abaumann> Also, I seem unable to build a new xz (had to some some diff-PKGBUILD hacks for source)
[07:01:42] <abaumann> *do some
[07:09:10] <abaumann> :: File /var/cache/pacman/pkg/python-setuptools-1:69.0.3-4.0-any.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
[07:14:41] <KitsuWhooa> abaumann: that's exactly what happened earlier when I fixed the insanity
[07:15:39] <KitsuWhooa> I guess for some reason get package updates keeps seeing 6.7 and adding it
[07:22:26] <abaumann> Yes, I start to suspect that the get-updates packages doesn't update the git state revision of certain packages.
[07:22:44] <abaumann> xz and linux-api-headers would be two candidates. :-)
[07:22:51] <KitsuWhooa> When I last debugged this, what had happened was it was picking it up twice
[07:23:00] <KitsuWhooa> and the issue was in the state repo
[07:23:02] <abaumann> ah
[07:23:16] <KitsuWhooa> this -> the issue of it insisting to build new packages
[07:23:18] <KitsuWhooa> er
[07:23:21] <KitsuWhooa> build old packages as new
[07:23:26] <KitsuWhooa> and what I did was ignored that specific hash
[07:23:33] <abaumann> right
[07:23:57] <abaumann> I start to think that we must ensure consistency of the state and git package repos
[07:24:13] <abaumann> then we can device a list of hashes to be ignore (or packages) and make exception lists
[07:24:37] <abaumann> it would of course also help if upstream could do some automatic consistency checking when peoeple update the git state repo :->
[07:25:11] <KitsuWhooa> https://git.archlinux32.org
[07:25:12] <phrik> Title: get-package-updates: Ignore old python-snappy v4 - builder - Archlinux32 build system (at git.archlinux32.org)
[07:25:29] <KitsuWhooa> (ignore the - line, I was trying to get it to work)
[07:25:33] <abaumann> yes, I remember
[07:25:50] <KitsuWhooa> I suspect upstream isn't interested
[07:26:07] <KitsuWhooa> perhaps we should safeguard against this somehow
[07:26:38] <abaumann> when I can motivate myself, I could write some consistency checker :-)
[07:26:55] <KitsuWhooa> Maybe somehow sort by commit date (or version number) and then only keep the latest
[07:27:42] <abaumann> somebody is interested (Mr. Reproducability of Builds) ;-)
[07:29:47] <KitsuWhooa> that's definitely not me; build reproducibiility is the first thing I threw out the window
[07:29:50] <KitsuWhooa> :)
[07:32:25] <abaumann> checking if all packages are tracked correctly ...
[07:32:26] <abaumann> The following packages from the master mirror are not tracked in the database or vice versa:
[07:32:29] <abaumann> mysql i686/core-staging/linux-api-headers-6.10-1.1-i686.pkg.tar.zst
[07:32:31] <abaumann> package-file i686/core-staging/linux-api-headers-6.10-1.1-pentium4.pkg.tar.zst
[07:32:34] <abaumann> mysql i686/core-staging/linux-api-headers-6.7-1.0-any.pkg.tar.zst
[07:32:37] <abaumann> mysql pentium4/core-staging/linux-api-headers-6.10-1.1-pentium4.pkg.tar.zst
[07:32:39] <abaumann> SANITY CHECK FAILED passed.
[07:32:40] <abaumann> the packages for architecture any, now has a subarchitecture.
[07:32:45] <abaumann> maybe that's causing problems.
[07:33:04] <KitsuWhooa> wait, subarchitecture?
[07:33:23] <KitsuWhooa> oh
[07:33:31] <KitsuWhooa> yes, I think this is the same thing that happened with python-snappy
[07:33:39] <abaumann> ah.
[07:33:48] <KitsuWhooa> it used to be any
[07:33:51] <KitsuWhooa> and then turned architecture dependent
[07:34:39] <KitsuWhooa> #archlinux32/2024-05-14.log:[17:07:02] <abaumann> ./extra-x86_64/python-snappy
[07:34:41] <KitsuWhooa> #archlinux32/2024-05-14.log:[17:07:04] <abaumann> ./extra-any/python-snappy
[07:34:48] <abaumann> mmh. bingo
[07:34:51] <KitsuWhooa> it's the exact same issue...
[07:35:03] <abaumann> shouldn't that happen more often?
[07:35:10] <KitsuWhooa> they forgot to remove the old one
[07:35:18] <abaumann> oh dear.
[07:35:26] <KitsuWhooa> so there's both in the state repo now
[07:35:35] <KitsuWhooa> (this is just a guess, but it's what happened last time)
[07:35:42] <abaumann> a good guess
[07:35:58] <abaumann> ./core-any/linux-api-headers
[07:35:58] <abaumann> ./core-x86_64/linux-api-headers
[07:36:00] <abaumann> yep
[07:36:01] <KitsuWhooa> yup
[07:36:35] <abaumann> I'm pretty sure upstream will tell us this is not a bug, but a feature. ;-)
[07:37:16] <abaumann> cat core-x86_64/linux-api-headers
[07:37:16] <abaumann> linux-api-headers 6.10-1 6.10-1 864c32b826e937600c4f85bca67f33696c005a97
[07:37:25] <abaumann> that's the new one, fits
[07:37:40] <KitsuWhooa> so we need to ignore older ones somehow even if they are different arch
[07:37:54] <KitsuWhooa> can you also cat the old one?
[07:38:04] <abaumann> Simpler, just respect the newer one and ignore the old ones.
[07:38:09] <KitsuWhooa> yeah
[07:38:32] <KitsuWhooa> 10:37:54 <KitsuWhooa> can you also cat the old one? <-- and then make a commit like the one I linked and let's forget about it until it happens again :)
[07:38:52] <abaumann> lol :-)
[07:43:05] <abaumann> ./extra-x86_64/python-snappy
[07:43:05] <abaumann> ./extra-any/python-snappy
[07:43:09] <abaumann> still the same
[07:43:13] <KitsuWhooa> hah
[07:44:35] <abaumann> | grep -v 'pinentry' \
[07:44:51] <abaumann> aha, now I know why my rebuilds of pinentry were a little bit.. aeh.. not working ;-)
[07:44:59] <KitsuWhooa> oh >.>
[07:45:12] <abaumann> never mind :-)
[07:45:38] <abaumann> I was hoping to see a 'xz' there. That would have helped to understand, why that one didn't pick up new versions..
[07:47:40] <KitsuWhooa> I assume that's the -ignore one?
[07:47:45] <abaumann> yep :-)
[07:48:03] <KitsuWhooa> since the normal get-package-updates runs on its own, it would have picked up on it anyway
[07:48:08] <KitsuWhooa> but I'd say you can go ahead and remove pinentry from there
[07:48:31] <abaumann> yes, did that
[07:48:38] <KitsuWhooa> great!
[07:48:59] <KitsuWhooa> anything added there is because something would happen while I was working on an entirely different package, and it'd just break and annoy me
[07:49:03] <KitsuWhooa> so I'd add it to the ignore list
[07:49:47] <KitsuWhooa> at some point I'll merge it with the proper get-package-updates and add flags, and possibly make it read packages from a persistent file. Maybe have it even tell you at the beginning what it'll ignore
[07:49:51] <KitsuWhooa> so that this doesn't happen again
[07:50:50] <abaumann> yes, that's good. pinentry was a big mess..
[07:51:06] <abaumann> ..I had to break reproducability of build somewhat ;-)
[07:51:14] <KitsuWhooa> Do you see xz when you run get-package-updates?
[07:51:16] <KitsuWhooa> -ignore
[07:51:19] <abaumann> nope
[07:51:42] <abaumann> that's something completely different. I'll make a test again later without my source patch in the diff PKGBUILD
[07:51:48] <KitsuWhooa> yeah
[07:52:19] <abaumann> so, just run a get-package-updates with the linux-api-headers/any hash removed, let's inspect the mess now..
[07:52:34] <KitsuWhooa> it'll probably be fine I think
[07:52:47] <abaumann> minus some mirror/db diffs probably
[07:54:14] <KitsuWhooa> > +# also some sse2 breakage in qt6 libs on i686, so ignoring on all subarchs
[07:54:17] <KitsuWhooa> did it break again?
[07:54:22] -!- man has joined #archlinux32
[07:54:26] <KitsuWhooa> I thought I fixed it
[07:54:40] <abaumann> I saw some errors when compiling qgpgme-qt6 or some pinentry qt thing..
[07:54:50] <KitsuWhooa> uh oh
[07:55:37] <abaumann> that's why I removed it. It's really bad that those bindings are subpackages in the core/PKGBUILD of gpgme for instance. I made a gpgme-qt5 in the AUR for exactly that purpose, not to have high level graphical library dependencies breaking core packages.
[07:55:44] <KitsuWhooa> https://git.archlinux32.org this should've done it
[07:55:45] <phrik> Title: extra/qt6-base: Fix non SSE2 builds - packages - Archlinux32 package modifications (at git.archlinux32.org)
[07:55:49] <KitsuWhooa> I'll check pinentry again
[07:55:52] <abaumann> ok
[07:57:05] -!- gehidore has quit [Ping timeout: 248 seconds]
[07:57:07] <KitsuWhooa> oh, it wasn't pinentry
[07:57:12] <abaumann> then gpgme?
[07:57:15] <KitsuWhooa> yeah
[07:57:33] <abaumann> a0f974fb80836713825981db339ef64f14406a5d
[07:57:43] <abaumann> core/gpgme: disable qt6 subpackage for fast libassuan0 solution
[07:57:49] <KitsuWhooa> yup
[07:57:51] <KitsuWhooa> thanks
[07:58:00] <abaumann> btw. I put a libassuan0-libs into the build-support-pool-manual.
[07:58:07] <KitsuWhooa> that's fine
[07:58:15] <abaumann> I think, that's a good idea to keep manual and non-manual build-support apart. :-)
[07:58:44] <KitsuWhooa> most of the packages I've put in there are from upstream arch with any architecture for what it's worth
[07:58:51] <KitsuWhooa> just copy paste :p
[08:00:10] <abaumann> ah. and I extracted and manipulated libassuan 2.5, extracted just the shared libs and put them into a libassuan0-libs
[08:00:30] <KitsuWhooa> not bad honestly
[08:00:42] <KitsuWhooa> I've been meaning to dig up old libraries to get things like mingw to build again
[08:00:43] <abaumann> that's a good trick also for boost-libs or icu if you don't or can't rebuild a icuXX or boost-libsXX package
[08:00:46] <KitsuWhooa> because bootstrapping it is a massive pain
[08:00:48] <KitsuWhooa> yup
[08:00:52] <abaumann> eactly
[08:06:45] -!- man has quit [Ping timeout: 252 seconds]
[08:07:04] <KitsuWhooa> abaumann: I think gpgme doesn't build :p
[08:07:08] <KitsuWhooa> Reversed (or previously applied) patch detected! Skipping patch.
[08:07:10] <KitsuWhooa> 1 out of 1 hunk ignored -- saving rejects to file lang/python/tests/t-callbacks.py.rej
[08:07:48] <abaumann> huh? that's new.
[08:08:08] <KitsuWhooa> did they merge 0004-Avoid-Y2038-problem-on-32-bit-architectures.patch
[08:08:11] <KitsuWhooa> or osmething
[08:08:15] <abaumann> this just means, the patch has already been done upstream (original package or upstream arch).
[08:08:18] <abaumann> yes.
[08:08:21] <abaumann> just ommit the patch
[08:08:24] <KitsuWhooa> cool
[08:08:41] -!- gehidore has joined #archlinux32
[08:08:46] <abaumann> hard to believe, but yes, cool :-)
[08:08:47] <KitsuWhooa> I wonder if we can make patch not count these as failures
[08:09:14] <abaumann> mmh. well, if patches don't apply anymore one has to check if the patch has been applied or not.
[08:09:24] <abaumann> I don't like automatic things.
[08:09:28] <KitsuWhooa> in this case it explicitly says "reversed or previously applied"
[08:09:34] <abaumann> that's also why I prefer patch over some sed-fu
[08:09:36] <KitsuWhooa> so it sees that the changes have already been done
[08:09:54] <KitsuWhooa> not just accent any failure to apply the patch
[08:09:56] <KitsuWhooa> *accept
[08:10:02] <abaumann> ah. so based on the message you could infer that you can just ignore it, yes, right
[08:11:33] <KitsuWhooa> I think I might've broken something
[08:11:38] <KitsuWhooa> I think I tried to apply the patch twice somehow
[08:11:51] <KitsuWhooa> I'll start over...
[08:12:26] <KitsuWhooa> Yeah I think I applied our PKGBUILD twice....
[08:12:37] <KitsuWhooa> damn :(
[08:12:44] <abaumann> pkgctl repo clone --protocol=https --arch32 gpgme
[08:12:59] <KitsuWhooa> I really ought to start using that, yes
[08:13:10] <abaumann> almost everything is done automatically there
[08:13:33] <abaumann> and as a bonus you get a -- Arch32 marker, so you can snip the right diff after it into our diff PKGBUILD :-)
[08:13:47] <KitsuWhooa> I did git diff :p
[08:18:37] <KitsuWhooa> yeah, so, gpgme built just fine for me on i686
[08:18:42] <KitsuWhooa> with qt6
[08:18:45] <abaumann> mmh.
[08:18:50] <abaumann> maybe it was on pentium4?
[08:18:56] <abaumann> I don't recall exactly
[08:18:56] <KitsuWhooa> time to try pentium4 :p
[08:19:19] <abaumann> for i486 we definitely have to have the patch for not building qt5 or qt6
[08:20:24] <KitsuWhooa> yeah
[08:22:12] <KitsuWhooa> yeah it breaks on pentium4
[08:22:19] <KitsuWhooa> > /usr/include/qt6/QtCore/qfloat16.h:86:62: error: invalid conversion to type '_Float16' without option '-msse2'
[08:22:23] <KitsuWhooa> why is Qt6 built without msse2
[08:22:30] <KitsuWhooa> or this
[08:22:48] <abaumann> on pentium4 it should use sse2
[08:23:00] <KitsuWhooa> exactly
[08:24:14] <KitsuWhooa> Hmmm https://gitlab.archlinux.org
[08:24:18] <phrik> Title: qt6-base-cflags.patch · main · Arch Linux / Packaging / Packages / qt6-base · GitLab (at gitlab.archlinux.org)
[08:24:46] <abaumann> ah, on 64-bit sse2 is enabled implicitely, as the ISA is required to support sse2
[08:24:57] <abaumann> maybe we need a patch to explicitely add -msse2 for pentium4
[08:25:06] <KitsuWhooa> don't we add -msse2 in our CFLAGS though?
[08:25:54] <abaumann> in makepkg.conf.d/pentium4.conf I don't see that.
[08:26:28] <KitsuWhooa> actually sorry
[08:26:31] <abaumann> Adding it globally could have some strange effecct though
[08:26:31] <KitsuWhooa> I thought pentium4 implied msse2
[08:26:38] <abaumann> march=pentium4
[08:26:39] <abaumann> no
[08:26:50] <abaumann> there are versions out there with SSE2 and some without
[08:26:52] <abaumann> IIRC
[08:27:16] <abaumann> if we add -msse2 and math=sse2 in makepkg.conf for pentium4 we must keep an eye on things.
[08:27:27] <KitsuWhooa> ‘pentium4’
[08:27:29] <KitsuWhooa> ‘pentium4m’ Intel Pentium 4 CPU with MMX, SSE, SSE2 and FXSR instruction set support.
[08:27:32] <abaumann> I prefer to add it where it is required.
[08:27:44] <abaumann> so qt6-base in this case
[08:27:53] <KitsuWhooa> qt6-base did build though
[08:27:56] <KitsuWhooa> that's why I'm confused
[08:28:00] <abaumann> OTOH it could mean we have to patch too much.
[08:28:12] <abaumann> Not all build slaves have the newest devtools32 probably. they might differ
[08:28:20] <abaumann> at least in the past
[08:28:29] <abaumann> I hope I updated all of mine to the newest version now
[08:29:14] <KitsuWhooa> I wonder if gpgme is the one that overrides the flags
[08:30:11] <abaumann> Actually, only glibc/gcc should be careful with CFLAGS. And in the toolchain you usually override CFLAGS from makepkg.conf
[08:30:27] <KitsuWhooa> that's what I was thinking, yeah
[08:33:08] <KitsuWhooa> > For the x86-32 compiler, you must use -march=cpu-type, -msse or -msse2 switches to enable SSE extensions and make this option effective.
[08:33:10] <KitsuWhooa> I am very confused
[08:33:24] <KitsuWhooa> anything I"m reading seems to imply that march=pentium4 should be enough
[08:35:17] <abaumann> To generate SSE/SSE2 instructions automatically from floating-point code (as opposed to 387 instructions), see -mfpmath=sse.
[08:35:35] <abaumann> could be qt6 expects floating point to be sse (so sse2)
[08:36:58] <KitsuWhooa> on pentium4? That seems weird
[08:37:37] <abaumann> well, you break the ABI when you move from 8087 to SSE
[08:38:02] <abaumann> so maybe to keep ABI-compatibility you keep 8087 math usually and use just SSE/SSE2 inside of functions.
[08:38:29] <abaumann> that's a problem when we add fpmath globally, it could break quite some ABIs
[08:38:34] <KitsuWhooa> yeah
[08:39:11] <abaumann> what I think is that qt6-base expects the API to be SSE and not 8087, hence the cast error
[08:39:15] <abaumann> *ABI
[08:39:49] <KitsuWhooa> do we then apply the same i686 patch to pentium4 too?
[08:39:54] <KitsuWhooa> to make qt not use sse
[08:39:54] <abaumann> or qt6-base is build with SSE fpmath and gpgpme and all software using Qt6 has to enable fpmath=sse too.
[08:40:15] <abaumann> that's an option.
[08:40:24] <KitsuWhooa> only for floats, I mean
[08:40:47] <abaumann> yes, it would probably build this way.
[08:41:12] <abaumann> to be frank: the fpmath thing was never part of the subarchitecture discussions in the beginning. Though it should have been..
[08:41:43] <KitsuWhooa> I am very confused
[08:41:47] <KitsuWhooa> I just ran make and it worked
[08:41:57] <KitsuWhooa> (inside the chroot)
[08:41:59] <abaumann> huh?
[08:42:08] <abaumann> what's the flags in your makepkg.conf in the chroot?
[08:42:33] <KitsuWhooa> incoming spam
[08:42:40] <abaumann> lol
[08:43:09] <KitsuWhooa> CFLAGS="-march=pentium4 -mtune=generic -O2 -pipe -fno-plt -fexceptions \
[08:43:11] <KitsuWhooa> -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security \
[08:43:13] <KitsuWhooa> -fstack-clash-protection -fcf-protection \
[08:43:15] <KitsuWhooa> -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer"
[08:43:17] <KitsuWhooa> CXXFLAGS="$CFLAGS -Wp,-D_GLIBCXX_ASSERTIONS"
[08:43:19] <KitsuWhooa> bless weechat's multiline editor
[08:43:32] <abaumann> mmh. interesting
[08:43:42] <KitsuWhooa> I guess just running 'make' uses the default flags
[08:43:45] <abaumann> so maybe qmake enables some flags
[08:44:32] <abaumann> I seem not to be able to clean up the linux-api-headers mess in the buildmaster
[08:45:19] <KitsuWhooa> still insane?
[08:45:23] <abaumann> yep
[08:45:26] <KitsuWhooa> want me to give it a try?
[08:45:32] <abaumann> definitely :-)
[08:45:39] <abaumann> you are more experienced :-)
[08:45:44] <KitsuWhooa> I really am not :p
[08:46:02] <KitsuWhooa> I probably have things more fresh in my mind though
[08:46:16] <abaumann> definitely (take two) :-)
[08:46:23] <KitsuWhooa> heh
[08:54:47] <KitsuWhooa> Ah I see why it got complicated
[08:54:58] <abaumann> mmh?
[08:54:59] <KitsuWhooa> 6.10 got pushed to testing while staging had 6.7
[08:55:10] <abaumann> urgh
[08:58:07] <KitsuWhooa> 11:57:58 * buildmaster resumes sanity.
[08:58:10] <KitsuWhooa> ;)
[08:58:14] <abaumann> wow.
[08:58:23] <abaumann> thanks a bunch
[08:58:27] <KitsuWhooa> no worries
[08:58:34] <KitsuWhooa> What I did was SELECT * FROM binary_packages WHERE pkgname = 'linux-api-headers';
[08:58:42] <KitsuWhooa> deleted all the affected rows
[08:58:54] <abaumann> sounds good
[08:58:54] <KitsuWhooa> then repo-remove'd and deleted all the relevant packages from the mirror
[08:59:15] <KitsuWhooa> in this case WHERE pkgver IN ("6.7", "6.10")
[08:59:23] <KitsuWhooa> and finally deleted the files from the pool
[08:59:29] <KitsuWhooa> now we just need to reschedule linux-api-headers
[08:59:37] <abaumann> on it :-)
[09:08:01] -!- man has joined #archlinux32
[09:11:31] -!- gehidore has quit [Ping timeout: 264 seconds]
[09:11:42] <abaumann> -rw-r--r-- 1 http mirror 310 Aug 15 11:08 linux-api-headers-6.8-1.1-pentium4.pkg.tar.zst.sig
[09:11:45] <abaumann> -rw-r--r-- 1 http mirror 1284357 Aug 15 11:08 linux-api-headers-6.8-1.1-pentium4.pkg.tar.zst
[09:11:48] <abaumann> -rw-r--r-- 1 http mirror 566 Aug 15 11:08 linux-api-headers-6.8-1.1-i686.pkg.tar.zst.sig
[09:11:51] <abaumann> -rw-r--r-- 1 http mirror 1284206 Aug 15 11:08 linux-api-headers-6.8-1.1-i686.pkg.tar.zst
[09:11:54] <abaumann> -rw-r--r-- 1 http mirror 310 Aug 15 11:10 linux-api-headers-6.8-1.1-i486.pkg.tar.zst.sig
[09:11:57] <abaumann> -rw-r--r-- 1 http mirror 1284020 Aug 15 11:10 linux-api-headers-6.8-1.1-i486.pkg.tar.zst
[09:12:00] <abaumann> interesting, we are build 6.8 now. oh well.
[09:12:11] <KitsuWhooa> oh ddear :p
[09:12:20] <KitsuWhooa> we'll see
[09:12:30] <abaumann> It might have been scheduled some ages age..
[09:12:33] <abaumann> *ago
[09:12:47] <abaumann> I'm doing my xz experiment now..
[09:12:59] <KitsuWhooa> good luck!
[09:13:58] <KitsuWhooa> Oh I wonder if we need to run get-package-updates to schedule 6.10
[09:14:12] <KitsuWhooa> because deleting them removed the source entries too
[09:14:23] <KitsuWhooa> I think it'll be fine either way
[09:14:37] <KitsuWhooa> s/updates/updates-ignore/
[09:15:25] <abaumann> ah. I'm just running one
[09:15:35] <abaumann> for xz, but it might pick up linux-api-headers too
[09:22:55] -!- man has quit [Ping timeout: 264 seconds]
[09:24:20] -!- gehidore has joined #archlinux32
[09:46:24] <KitsuWhooa> 6.10-1.1 in staging
[09:54:46] <abaumann> perfect
[10:03:45] <abaumann> :: File /var/cache/archbuild32/linux-api-headers-6.10-1.1-i486.pkg.tar.zst is corrupted (invalid or corrupted package (checksum)).
[10:03:48] <abaumann> Do you want to delete it? [Y/n] error: failed to commit transaction (invalid or corrupted package)
[10:03:58] <abaumann> somewhere is a build machine with expired signing keys, it seems
[10:04:12] <abaumann> 486, those would be mine :-)
[10:06:28] <KitsuWhooa> I don't think it's a signing key issue
[10:06:30] <KitsuWhooa> it says checksum
[10:06:37] <KitsuWhooa> it's probably from me deleting the old package
[10:06:43] <abaumann> yes, but how can a checksum go wrong?
[10:06:49] <KitsuWhooa> downloading a 404 page :p
[10:07:00] <abaumann> mmh.
[10:07:09] <KitsuWhooa> oh no, I'm wrong
[10:07:11] <abaumann> maybe transient.
[10:07:16] <KitsuWhooa> yeah I think it was transient
[10:07:49] <abaumann> I'm building against a mirror, that one I'm synching with rsync. There can be transient inconsistencies between packages and the package databases.
[10:13:22] <abaumann> yes, was a temporary glitch, so was python-setuptools
[10:13:31] <abaumann> I need a more clever way to rsync mirrors.
[10:13:36] <abaumann> xz worked fine too:
[10:13:37] <abaumann> -rw-r--r-- 2 http mirror 310 Aug 15 11:57 xz-5.6.2-1.2-pentium4.pkg.tar.zst.sig
[10:13:41] <abaumann> -rw-r--r-- 2 http mirror 725433 Aug 15 11:57 xz-5.6.2-1.2-pentium4.pkg.tar.zst
[10:13:44] <abaumann> -rw-r--r-- 2 http mirror 310 Aug 15 12:00 xz-5.6.2-1.2-i686.pkg.tar.zst.sig
[10:13:47] <abaumann> -rw-r--r-- 2 http mirror 725183 Aug 15 12:00 xz-5.6.2-1.2-i686.pkg.tar.zst
[10:13:49] <abaumann> -rw-r--r-- 2 http mirror 310 Aug 15 12:04 xz-5.6.2-1.2-i486.pkg.tar.zst.sig
[10:13:52] <abaumann> -rw-r--r-- 2 http mirror 714343 Aug 15 12:04 xz-5.6.2-1.2-i486.pkg.tar.zst
[10:29:23] <abaumann> 9968 packages in the build queue, we dropped below 10k :-)
[10:34:31] <socksinspace> \o/
[10:34:58] <KitsuWhooa> can we throw packages in space too? Will make our lives much easher
[10:35:00] <KitsuWhooa> *easier
[10:35:31] <abaumann> I always loved pigsinspace ;-)
[11:12:16] -!- abaumann has quit [Quit: leaving]
[13:25:31] -!- drathir_tor has quit [Ping timeout: 260 seconds]
[13:28:00] -!- drathir_tor has joined #archlinux32
[16:28:06] -!- drathir_tor has quit [Ping timeout: 260 seconds]
[16:33:31] -!- drathir_tor has joined #archlinux32
[17:13:09] -!- ssserpent has quit [Quit: WeeChat 4.3.5]
[21:12:57] -!- dvzrv has quit [Quit: WeeChat 4.3.2]
[21:13:19] -!- dvzrv has joined #archlinux32
[23:42:38] -!- Cthuutloops has quit [Remote host closed the connection]