#archlinux32 | Logs for 2024-03-09

Back
[00:10:55] mavicaway is now known as mavica
[01:55:30] -!- morriset has quit [Remote host closed the connection]
[02:03:04] -!- finsternis has quit [Read error: Connection reset by peer]
[02:07:54] -!- finsternis has joined #archlinux32
[07:47:55] -!- bdju has quit [Ping timeout: 256 seconds]
[07:49:41] -!- bdju has joined #archlinux32
[08:41:04] -!- titus_livius has joined #archlinux32
[08:44:45] <KitsuWhooa> I pushed an update to python-bootstrap and it build python-setuptools
[08:44:49] <KitsuWhooa> and now it's building python-bootstrap
[08:44:53] <KitsuWhooa> it better not nuke setuptools out of staging
[09:13:38] mavica is now known as mavicaway
[11:47:26] -!- eschwartz has quit [Ping timeout: 252 seconds]
[11:49:07] -!- abaumann has joined #archlinux32
[11:49:07] <buildmaster> Hi abaumann!
[11:49:07] <buildmaster> !rq abaumann
[11:49:08] <phrik> buildmaster: <abaumann> *abaumann thinks it's not a good idea to cook and fix bugs in ffmpeg in parallel :-)
[11:49:43] <abaumann> KitsuWhooa: let's see what happens with python-bootstrap.
[11:49:52] <abaumann> euronuc so far is behaving ok with the updated devtools32
[11:49:55] <KitsuWhooa> abaumann: it built it
[11:50:00] <KitsuWhooa> and then it went insane
[11:50:05] <KitsuWhooa> haven't had time to fix the insanity yet
[11:50:14] <KitsuWhooa> https://buildmaster.archlinux32.org
[11:50:15] <phrik> Title: result of archlinux32 build master's sanity checksanity of the buildmaster's mysql database (at buildmaster.archlinux32.org)
[11:50:30] <KitsuWhooa> I've been trying to get python-lxml to build and it looks like I need to backport patches
[11:50:34] <KitsuWhooa> (it doesn't build upstream either)
[11:50:44] <abaumann> "package multiple times in equally stable repositories"
[11:50:47] <KitsuWhooa> if you want to fix that insanity that'd be great
[11:50:52] <abaumann> for this I had a SQL statement, which no longer works.
[11:50:55] <KitsuWhooa> ah
[11:51:04] <KitsuWhooa> I'll get to it then :p
[11:52:21] <abaumann> i686/{core-staging,core-staging}/libxml2
[11:52:26] <abaumann> core-staging and core-staging
[11:52:27] <abaumann> mmh.
[11:52:36] <KitsuWhooa> that definitely feels like incorrect locking
[11:52:51] <KitsuWhooa> either that or it asked two builders to build the same thing at once and it didn't reject the second one
[11:53:08] <abaumann> that definitely happens from time to time.
[11:53:19] <abaumann> but it should not accept both packages. one would be added..
[11:53:24] <abaumann> ..the other one rejected.
[11:53:35] <abaumann> (and the builder sees a message about building an outdated package)
[11:53:53] <KitsuWhooa> yup
[11:57:02] <KitsuWhooa> I think I'm going to have to update the package to lxml 5
[11:57:14] <KitsuWhooa> and hope the incompatibilities aren't bad
[12:01:44] -!- eschwartz has joined #archlinux32
[12:04:58] <abaumann> core-staging contains libxml2 and libxml2-docs twice in two different versions
[12:06:58] <KitsuWhooa> so maybe it's a matter of deleting the old one
[12:07:04] <abaumann> yes
[12:07:12] <abaumann> also, and especially in the database.
[12:07:29] <abaumann> I do it on the mirror
[12:07:31] <KitsuWhooa> there is a script that deletes packages from the database
[12:07:33] <KitsuWhooa> right?
[12:07:40] <abaumann> yeah, if it works.
[12:07:51] <KitsuWhooa> last I checked it did
[12:08:00] <KitsuWhooa> let me know what the old versions are at least
[12:08:02] <KitsuWhooa> before deleting them
[12:08:08] <KitsuWhooa> idk if the sanity check will say after you delete them
[12:08:13] <abaumann> sure
[12:08:23] <abaumann> 2.11.5-1.1 2.12.5-1.0-
[12:08:36] <abaumann> and by deleting I mean moving them to /root
[12:08:49] <abaumann> they are just symlinks in i686 and pentium4, so no harm to fiddle around there
[12:09:18] <KitsuWhooa> won't it then complain that they are on the pool and untracked?
[12:09:30] <KitsuWhooa> er
[12:09:34] <KitsuWhooa> only in the pool and not in the repos
[12:09:57] <abaumann> it will.
[12:10:10] <abaumann> but if we delete the right version from the database, this should fix itself then.
[12:11:02] <abaumann> now it's just complainint it has 2.11.5 in the database and not on the mirror or in the pacman datebases
[12:12:02] <KitsuWhooa> do you want to try the delete script, or should I?
[12:12:18] <abaumann> well. just go ahead. :-)
[12:13:57] <KitsuWhooa> wait I'm confused
[12:14:01] <KitsuWhooa> should I remove 2.11.5 or 2.12
[12:14:07] <abaumann> 2.11.5
[12:16:55] <KitsuWhooa> Hm, it's telling me nothing to delete
[12:17:01] <KitsuWhooa> I think I can't actually specify the version
[12:17:18] <abaumann> so we have to fiddle directly in the database
[12:17:39] <KitsuWhooa> Hm
[12:17:41] <KitsuWhooa> I must be doing something wrong
[12:17:46] <abaumann> or we leave 2.11.5 and 2.12.5 and change their stability (one in setaging, one in testing)
[12:17:59] <abaumann> but this creates maybe more issues (because there is somehting in testing already)
[12:18:17] <KitsuWhooa> oh
[12:18:22] <KitsuWhooa> I think I wrote it wrong
[12:18:22] <KitsuWhooa> hold on
[12:18:40] * abaumann holds on to a glass table of his desk
[12:18:47] <KitsuWhooa> hahaha
[12:19:45] <KitsuWhooa> nope
[12:19:49] <KitsuWhooa> I can't figure out the correct format in the file
[12:19:59] <KitsuWhooa> I've used it before
[12:20:12] <abaumann> yeah, documentation is usually the code.
[12:23:42] <KitsuWhooa> yeah I don't know
[12:24:04] <abaumann> ./delete-packages
[12:24:04] <abaumann> Build master is not sane.
[12:24:08] <KitsuWhooa> -i
[12:24:09] <abaumann> this would not work anyway.
[12:24:11] <abaumann> aj
[12:24:22] <KitsuWhooa> I've used it like delete-packages -i -f list
[12:24:28] <KitsuWhooa> and the list is a list of the packages to delete
[12:24:34] <KitsuWhooa> as in, it's a physical file
[12:25:06] <KitsuWhooa> I remember I would specify arch/repo/package and it'd then put the actual filename in there and then delete them
[12:25:15] <KitsuWhooa> but I can't even get it to work with arch/repo/package
[12:25:58] <KitsuWhooa> and I put all the previous lists in /tmp/ so they are long gone
[12:26:31] <abaumann> select * from binary_packages_in_repositories,binary_packages where binary_packages_in_repositories.package=binary_packages.id and pkgname='libxml2';
[12:26:38] <abaumann> then I get a set of ids
[12:26:53] <KitsuWhooa> yes but then you need to delete them from I think 3 tables
[12:27:04] <abaumann> mmh, true.
[12:27:16] <abaumann> and first one has to find the correct repository to delete them from.
[12:27:22] <KitsuWhooa> yup
[12:27:28] <KitsuWhooa> which is like 3 levels of indirection on its own :p
[12:27:37] <abaumann> select * from repositories where name='core-staging';
[12:27:37] <abaumann> +----+--------------+-----------+---------------------+--------------+
[12:27:37] <abaumann> | id | name | stability | is_on_master_mirror | architecture |
[12:27:37] <abaumann> +----+--------------+-----------+---------------------+--------------+
[12:27:37] <abaumann> | 38 | core-staging | 3 | | 2 |
[12:27:40] <abaumann> | 39 | core-staging | 3 | | 3 |
[12:27:42] <abaumann> | 40 | core-staging | 3 | | 4 |
[12:27:45] <abaumann> +----+--------------+-----------+---------------------+--------------+
[12:27:47] <abaumann> he. only 3 possibilies
[12:28:11] <abaumann> | 6767039 | 2549963 | 39 | 2023-08-12 15:38:53 | | 2549963 | 2101251 | 0 | 2.11.5 | 1 | 0 | | | libxml2 | 3 | 39bf45d8641cb4ac4c591dd6d7853599080a3a6eef77c0e2a365a79c827017ea37829ced01d87e155328f96eafaa338df644103dffd3560cb5be454b535d21aa | | 8 | 18 |
[12:28:16] <abaumann> | 19994793 | 6813194 | 38 | 2024-03-09 10:37:02 | | 6813194 | 6061704 | 0 | 2.11.5 | 1 | 1 | | | libxml2 | 2 | 0e615e619551d88a0b565b8b8630294570faaaaa69457d5c7d6e516ef97be904b6f51a9d3c2bbe87a0bf2ea30aaa95dbedac2ffe10656c6f695b3bce78910e20 | | 8 | 18 |
[12:28:21] <abaumann> those two are good candidates
[12:28:28] <KitsuWhooa> wanna nuke them? go ahead
[12:28:29] <KitsuWhooa> :p
[12:28:37] <abaumann> ./delete-packages -i -f 6767039
[12:28:37] <abaumann> Build master is not sane.
[12:28:37] <abaumann> Nothing to delete.
[12:28:38] <abaumann> mmh.
[12:35:25] <abaumann> ok, let's see. I might have nuked libxml2 now from staging
[12:35:44] <KitsuWhooa> seems to have worked for i686
[12:35:54] <abaumann> yeah. a little bit too good.
[12:36:09] <KitsuWhooa> I think you deleted the .12 one
[12:36:19] <KitsuWhooa> because it wants the 2.11 I think
[12:37:10] <abaumann> so, it nuked the new on (at least for i686)
[12:37:14] <abaumann> ah.
[12:37:19] <KitsuWhooa> honestly, that's fine
[12:37:19] <abaumann> but this is fixable on the mirror
[12:37:21] <KitsuWhooa> yes
[12:37:31] <abaumann> let me do that
[12:38:29] <KitsuWhooa> now just need to do it with libxml2-docs too
[12:38:29] <abaumann> the output of sanity-check is so bad, I never know in which direction I have to do somehting.
[12:38:51] <KitsuWhooa> I always struggle with it too, yeah :p
[12:38:53] <KitsuWhooa> granted it's gotten easier
[12:51:47] <KitsuWhooa> 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)).
[12:51:58] <KitsuWhooa> did your key expire?
[12:52:21] <abaumann> not really
[12:52:38] <KitsuWhooa> I'll delete the chroot and try again then
[12:52:57] <abaumann> I switched off euronuc
[12:53:06] <abaumann> maybe it's also a devtools32 upgrade issue.
[12:53:09] <KitsuWhooa> that was built earlier in the morning
[12:53:14] <KitsuWhooa> I really hope not
[12:53:20] <abaumann> but I don't have a way anymore to test it wihtout the buildmaster
[12:53:44] <KitsuWhooa> okay
[12:53:47] <KitsuWhooa> I deleted the chroot and it works now
[12:54:12] <KitsuWhooa> I don't know what it was about but I'm relieved
[13:06:10] <abaumann> -bash: recompress_gz: command not found
[13:06:12] <abaumann> -bash: failsafe_rsync: command not found
[13:06:15] <abaumann> in intensions.
[13:06:16] <abaumann> well.
[13:06:37] <abaumann> I had to remove all versions of libxml2-docs in staging now
[13:06:57] <KitsuWhooa> I think that was my mistake
[13:07:02] <KitsuWhooa> you can probably ignore those
[13:07:29] <abaumann> at least the double-stability error in sanity-check has gone now.
[13:07:36] <abaumann> now for the mess in mirror
[13:08:01] <abaumann> I'm actually quite positive that when I build the next version of libxml2 things will go wrong again. :->
[13:08:16] <abaumann> The following packages from the master mirror are not tracked in the database or vice versa:
[13:08:19] <abaumann> package-file i686/core-staging/libxml2-2.11.5-1.1-i686.pkg.tar.zst
[13:08:22] <abaumann> package-file i686/core-staging/libxml2-docs-2.11.5-1.1-i686.pkg.tar.zst
[13:08:24] <abaumann> package-file pentium4/core-staging/libxml2-2.11.5-1.1-pentium4.pkg.tar.zst
[13:08:27] <abaumann> package-file pentium4/core-staging/libxml2-docs-2.11.5-1.1-pentium4.pkg.tar.zst
[13:11:56] <abaumann> I remove libxml2-2.11.5-1.1-i686.pkg.tar.zst, it complains, I add it, it complains
[13:17:14] <abaumann> absolute nightmare
[13:17:33] <KitsuWhooa> I think it happens because they are still in the database
[13:18:43] <KitsuWhooa> yeah
[13:18:44] <abaumann> there is the database, the pacman databases per architecture, the pool and the archive
[13:18:53] <KitsuWhooa> they are still both in the binary_packages table
[13:18:56] <KitsuWhooa> in the mysql database
[13:19:02] <abaumann> and operations between those are simply not atomar
[13:19:21] <abaumann> do we have (temporary) sanity now?
[13:19:53] <KitsuWhooa> looks like it
[13:20:03] <KitsuWhooa> let's queue up libxml2 :p
[13:20:35] <abaumann> 1 any libxml2 0c6beaf4099ef83b4da46bed7d4ce962d339ec8a 0000000000000000000000000000000000000000 core
[13:20:38] <abaumann> 2 any libxml2 4bd34a1a70e98d458c9e0d851be072eb6677463c 0000000000000000000000000000000000000000 core
[13:20:41] <abaumann> 3 any libxml2 dc4033b60e6c88b8325af151a9716fa63215e5b0 0000000000000000000000000000000000000000 core
[13:20:44] <abaumann> 4 any libxml2 e00f29fa95c15f69ceb150242d4783801f24f3e7 0000000000000000000000000000000000000000 core
[13:20:46] <KitsuWhooa> 3
[13:20:47] <abaumann> mmmh
[13:20:49] <abaumann> which one
[13:20:55] <abaumann> I would have picked 1 or 4
[13:20:57] <KitsuWhooa> I've checked it before, it's 3
[13:20:58] <KitsuWhooa> 4 doesn't work
[13:21:01] <abaumann> ah.
[13:21:06] <abaumann> I would have picked 2 now..
[13:21:08] <abaumann> ;-)
[13:21:10] <abaumann> just for fun.
[13:21:11] <KitsuWhooa> :p
[13:21:12] <abaumann> ok.
[13:21:13] <abaumann> 3 it is.
[13:21:48] <KitsuWhooa> actually, 2 works too
[13:21:50] <KitsuWhooa> idk what the difference is
[13:22:00] <KitsuWhooa> ah
[13:22:21] <abaumann> let's see.
[13:22:22] <KitsuWhooa> actually I think 2 might've been better, idk
[13:22:25] <KitsuWhooa> 2 is a newer version
[13:22:28] <KitsuWhooa> but idk if that will break things
[13:22:37] <abaumann> libxml2 is quite stable
[13:22:48] <abaumann> so, I don't expect surprises from there
[13:22:51] <KitsuWhooa> I saw some things in the python-lxml changelog, that's why I said that
[13:22:52] <KitsuWhooa> but sure
[13:23:03] <KitsuWhooa> maybe that's why it broke
[13:23:08] <KitsuWhooa> I told it to build 3 and it then built 2
[13:23:16] <KitsuWhooa> it shouldn't break, but who knows
[13:23:31] <abaumann> I have to do some shopping, back in 10 minutes.. :-)
[13:23:34] <KitsuWhooa> see ya
[13:23:37] <abaumann> then we'll see the results.
[13:23:38] <abaumann> AFK
[13:35:36] <abaumann> ok, back :)
[13:35:59] <abaumann> -rw-r--r-- 1 http mirror 566 Mar 9 14:25 libxml2-docs-2.11.5-1.2-i686.pkg.tar.zst.sig
[13:36:02] <abaumann> -rw-r--r-- 1 http mirror 289442 Mar 9 14:25 libxml2-docs-2.11.5-1.2-i686.pkg.tar.zst
[13:36:06] <abaumann> -rw-r--r-- 1 http mirror 566 Mar 9 14:25 libxml2-2.11.5-1.2-i686.pkg.tar.zst.sig
[13:36:09] <abaumann> -rw-r--r-- 1 http mirror 877787 Mar 9 14:25 libxml2-2.11.5-1.2-i686.pkg.tar.zst
[13:36:12] <abaumann> -rw-r--r-- 1 http mirror 878520 Mar 9 14:26 libxml2-2.11.5-1.2-pentium4.pkg.tar.zst
[13:36:15] <abaumann> -rw-r--r-- 1 http mirror 566 Mar 9 14:26 libxml2-2.11.5-1.2-pentium4.pkg.tar.zst.sig
[13:36:18] <abaumann> -rw-r--r-- 1 http mirror 566 Mar 9 14:26 libxml2-docs-2.11.5-1.2-pentium4.pkg.tar.zst.sig
[13:36:21] <abaumann> -rw-r--r-- 1 http mirror 289302 Mar 9 14:26 libxml2-docs-2.11.5-1.2-pentium4.pkg.tar.zst
[13:36:24] <abaumann> Not bad
[13:36:24] <abaumann> let's try a '2'
[13:36:27] <abaumann> and no insanity
[13:43:07] <abaumann> -rw-r--r-- 1 http mirror 566 Mar 9 14:39 libxml2-2.12.5-1.0-i686.pkg.tar.zst.sig
[13:43:10] <abaumann> -rw-r--r-- 1 http mirror 883954 Mar 9 14:39 libxml2-2.12.5-1.0-i686.pkg.tar.zst
[13:43:13] <abaumann> -rw-r--r-- 1 http mirror 566 Mar 9 14:39 libxml2-docs-2.12.5-1.0-i686.pkg.tar.zst.sig
[13:43:16] <abaumann> -rw-r--r-- 1 http mirror 288920 Mar 9 14:39 libxml2-docs-2.12.5-1.0-i686.pkg.tar.zst
[13:43:19] <abaumann> -rw-r--r-- 1 http mirror 829174 Mar 9 14:40 libxml2-2.12.5-1.0-pentium4.pkg.tar.zst
[13:43:22] <abaumann> -rw-r--r-- 1 http mirror 310 Mar 9 14:40 libxml2-docs-2.12.5-1.0-pentium4.pkg.tar.zst.sig
[13:43:25] <abaumann> -rw-r--r-- 1 http mirror 288732 Mar 9 14:40 libxml2-docs-2.12.5-1.0-pentium4.pkg.tar.zst
[13:43:28] <abaumann> -rw-r--r-- 1 http mirror 310 Mar 9 14:40 libxml2-2.12.5-1.0-pentium4.pkg.tar.zst.sig
[13:43:31] <abaumann> ok
[13:56:15] <KitsuWhooa> looks good
[13:57:53] <KitsuWhooa> anyway, with setuptools now properly fixed, more python packages should build
[13:58:04] <KitsuWhooa> might be time to tackle sphinx
[13:58:33] <KitsuWhooa> also, I'll push python-lxml
[13:59:13] <abaumann> good
[14:03:10] <KitsuWhooa> IIRC the reason I want to get lxml building is because llvm wants it
[14:03:18] <KitsuWhooa> so once I get llvm17 built, I'll then tackle rust
[14:09:52] <KitsuWhooa> > ImportError: libicuuc.so.73: cannot open shared object file: No such file or directory
[14:09:53] <KitsuWhooa> oh no
[14:13:16] <KitsuWhooa> oh it's from libxslt
[14:15:23] <abaumann> icu73 shim package
[14:15:39] <abaumann> oh, we need a new one.
[14:15:47] <abaumann> the last one was icu72
[14:15:49] <KitsuWhooa> why do we need a ship?
[14:15:50] <KitsuWhooa> shim?
[14:16:15] <KitsuWhooa> I scheduled libxslt for rebuild
[14:16:15] <abaumann> it's easy to add makedepends+=(icu73)
[14:16:24] <abaumann> ah. maybe that is enough for this case
[14:16:35] <abaumann> but I think libxml2 depends on icu, not libxslt itself
[14:16:45] <KitsuWhooa> I ran ldd on libxslt.so
[14:16:51] <KitsuWhooa> and it complained about libicu missing
[14:16:53] <KitsuWhooa> anyway, it rebuilt
[14:16:58] <abaumann> lddtree /usr/lib/libxslt.so.1
[14:17:01] <abaumann> libxml2.so.2 => /usr/lib/libxml2.so.2
[14:17:03] <abaumann> libicuuc.so.74 => /usr/lib/libicuuc.so.74
[14:17:12] <abaumann> ldd is not usable really
[14:17:16] <KitsuWhooa> yes but we rebuilt libxml
[14:17:38] <abaumann> ah, true
[14:17:48] <abaumann> then just libxslt needs a rebuild. me wrong. :-)
[14:18:41] <abaumann> ah. libfido2 is a nightmare. it depends on systemd recurively and -Wno-dev is broken
[14:18:41] <KitsuWhooa> idk what it was, but it's fixed now
[14:19:38] <abaumann> _FORTIFY_SOURCE redefined.
[14:19:46] <abaumann> yeah why is this done in cmakelists.txt?
[14:19:52] <abaumann> this comes from the distro
[14:19:53] <abaumann> CFLAGS
[14:20:14] <KitsuWhooa> it should be fine to set it in cmake
[14:20:17] <KitsuWhooa> no?
[14:20:25] <KitsuWhooa> I guess it should check that it exists, idk
[14:21:13] <abaumann> "Library functionality for FIDO 2.0, including communication with a device over USB"
[14:21:18] <abaumann> ok, do we need that?
[14:21:29] <KitsuWhooa> if someone wants to use their yubikey, probably
[14:21:43] <abaumann> yeah, on a security-broken 32-bit machine,sure ;-)
[14:22:05] * KitsuWhooa shrugs
[14:22:17] <abaumann> the yubikey might have more computing power than the computer the USB stick is connected to.
[14:22:27] <KitsuWhooa> possibly :p
[14:23:54] <abaumann> my plan is currently to get systemd/mdadm/mkinitcpio up again, while you are tackling python and rust. I have seen some questions by downstream when we are "planning" to be ready for that. :-)
[14:25:06] <KitsuWhooa> I fixed the "can't upgrade systemd" by adding a stub dbus-units-whatever in build-support
[14:25:13] <KitsuWhooa> so you should be able to get further trying to build those
[14:25:14] <abaumann> ah. good.
[14:25:24] <KitsuWhooa> so I guess you can start by trying to get dbus to build
[14:25:28] <KitsuWhooa> either dbus-daemon or dbus-broker
[14:26:01] <KitsuWhooa> also I think you were right
[14:26:03] <KitsuWhooa> it was libxml2
[14:26:06] <KitsuWhooa> but it doesn't make sense
[14:26:21] <KitsuWhooa> how did we build libxml2 against a non existing libicu
[14:26:34] <KitsuWhooa> I'll nuke the chroot and try again
[14:27:07] <abaumann> is there an old patch for libxml2
[14:27:13] <KitsuWhooa> error: libxml2: signature from "TasosSah (Arch32 Package Signing Key) <arch32@tasossah.com>" is invalid
[14:27:13] <KitsuWhooa> :: File /var/cache/pacman/pkg/libxml2-2.12.5-1.0-i686.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
[14:27:17] <KitsuWhooa> ??????
[14:27:51] <KitsuWhooa> I deleted the chroot again and it worked
[14:27:52] <abaumann> Maybe there is a fix in devtool32 to make gpg and it's deamon behave.
[14:28:01] <abaumann> I meant, I saw something along those lines in there.
[14:28:19] <abaumann> Yeah. gpg-agent is not the best software around.
[14:28:23] <abaumann> and keyservers are a mess
[14:28:26] <KitsuWhooa> it's been fine until now
[14:29:01] <abaumann> there is no patch for libxml2 or so (arch32-specific one)
[14:29:11] <abaumann> so, no clue why it picked up the wrong icu
[14:29:12] <KitsuWhooa> even if there was
[14:29:22] <KitsuWhooa> we can't link against the wrong icu, right?>
[14:29:26] <abaumann> maybe something else draw in another icuXX?
[14:29:35] <abaumann> that's not so sure.
[14:29:35] <KitsuWhooa> oh maybe
[14:29:38] <abaumann> In theory not.
[14:29:42] <KitsuWhooa> let's see if it fails in a clean chroot
[14:29:45] <KitsuWhooa> if it does, I'll dig into it
[14:29:48] <abaumann> because icuXX shim packages contain only the shared libraries.
[14:29:55] <abaumann> good idea
[14:32:10] <KitsuWhooa> Oh! Tests are running
[14:32:11] <KitsuWhooa> and failed
[14:32:20] <KitsuWhooa> but we made it further
[14:33:15] <KitsuWhooa> eh, idk if I care :p
[14:33:45] <abaumann> tests are currently only nice to have, IMHO
[14:34:00] <KitsuWhooa> yeah
[14:35:19] <KitsuWhooa> https://git.archlinux32.org
[14:35:20] <phrik> Title: packages - Archlinux32 package modifications (at git.archlinux32.org)
[14:37:28] <abaumann> mmh. this will not work well when you upgrade things ahead of upstream
[14:37:41] <KitsuWhooa> I tried backporting patches and it was really difficult
[14:37:45] <KitsuWhooa> I think it'll be fine
[14:37:59] <KitsuWhooa> we don't really have a choice :p
[14:38:06] <abaumann> ah, then :-)
[14:38:11] <KitsuWhooa> the package doesn't build upstream as-is either right now
[14:38:18] <KitsuWhooa> as in, on arch64
[14:38:30] <KitsuWhooa> I was thinking of opening an issue but I suspect it'll get updated with python3.12
[14:38:47] <abaumann> it's already masrked as out-of-date
[14:38:51] <abaumann> so, no bug report necessary
[14:38:55] <KitsuWhooa> ah
[14:38:58] <KitsuWhooa> well
[14:39:03] <KitsuWhooa> out of date doesn't necessarily mean it doesn't build
[14:39:04] <KitsuWhooa> but yes
[14:39:17] <abaumann> that's a debate I had with upstream many times.
[14:39:29] <abaumann> but from their point of view they have a working package.
[14:39:37] <KitsuWhooa> I see
[14:39:44] <abaumann> if you expect everything to be rebuildable all the time, then you get tons of bug reports
[14:40:02] <abaumann> which have nothing to do with their product (aka the x86_64 package).
[14:40:12] <KitsuWhooa> yeah
[14:40:25] <KitsuWhooa> the end user isn't going to need to rebuild the same version under x86_64
[14:40:32] <abaumann> exactly
[14:40:50] <abaumann> especially glibc or gcc updates sometimes render 100nds of packages broken.
[14:41:19] <abaumann> You don't want 100 bugs of the kind "xxx is broken with new glibc", maintainers find out when they rebuild the package.
[14:41:36] <abaumann> in theory glibc should be ABI-compatible, so there is also no need to rebuild every single package.
[14:41:49] <KitsuWhooa> yeah
[14:41:57] <abaumann> This results in binary bit-rot of course. But the alternative is to have much more man and computer power
[14:42:07] <KitsuWhooa> eh
[14:42:20] <KitsuWhooa> I don't think upstream arch is going to binary bitrot anytime soon
[14:42:31] <KitsuWhooa> there'll be a new version of the package at some point anyway
[14:42:47] <KitsuWhooa> or it'll stop working because some other dependency changed the so version and will need to be rebuilt
[14:43:12] <abaumann> yes, but you also may have packages, which are currently installable and running, but as soon you rebuild them, you have to patch them or in the worst case, they don't build anymore at all.
[14:43:25] <KitsuWhooa> ah
[14:43:28] <KitsuWhooa> yes, like this one
[14:43:39] <abaumann> exactly
[14:44:00] <abaumann> usually upstream will - as you pointed out - do all of python on the next python update anyway - and notice :-)
[14:44:40] <abaumann> aeh, I started get-package-updates with the non-haskell-nuking-feature .. will take a while..
[14:44:49] <KitsuWhooa> ...uh oh
[14:44:59] <KitsuWhooa> I already started get-package-updates
[14:45:03] <KitsuWhooa> it's currently running
[14:45:08] <abaumann> ah.
[14:45:15] <KitsuWhooa> ...I really hope this doesn't fuck the database up
[14:45:22] <KitsuWhooa> is yours stuck at the beginning or is it running?
[14:45:35] <abaumann> mine is running, so yours is in wait :-)
[14:45:46] <KitsuWhooa> yes but mine is halfway there
[14:46:02] <KitsuWhooa> should I abort mine?
[14:46:03] <abaumann> mmh. again some missing locks?
[14:46:14] <abaumann> nono, just let it run. Shouldn't matter.
[14:46:15] <KitsuWhooa> I have no idea. Mine seems paused
[14:46:21] <KitsuWhooa> alright
[14:46:29] <KitsuWhooa> mine is running again
[14:46:41] <abaumann> mmh. maybe fine grained-locking..
[14:46:58] <KitsuWhooa> fingers crossed the db survives :p
[14:48:50] <KitsuWhooa> builder2 is building lxml
[14:49:40] <abaumann> ah, btw. what's with eurobuild6 again?
[14:49:50] <KitsuWhooa> Hm?
[14:50:15] <abaumann> nothing running, and if there is a big backlog for python, we can speed things up with more builders.
[14:50:35] <KitsuWhooa> I think the locking from multiple get package updates is slowing things down
[14:50:39] <KitsuWhooa> I thought eurobuild6 was broken
[14:50:44] <abaumann> ah, right. :-)
[14:50:49] <abaumann> Now, I remember.
[14:51:15] <KitsuWhooa> Done - mark decisions as final.
[14:51:23] <KitsuWhooa> it finished
[14:51:33] <abaumann> I don't like that, it sounds those scripts can run in parallel.
[14:51:50] * KitsuWhooa shrugs
[14:52:09] <KitsuWhooa> but yeah, eurobuild6 isn't running
[14:52:15] <KitsuWhooa> last connection 2024-03-06 18:49:22
[14:59:51] <abaumann> let's be brave and run eurobuild6 with the new devtools32 :-)
[15:12:03] <abaumann> why do I see haskell packages building? is the ignoring now fast , but not deleting the haskell packages from the build list?
[15:17:03] <abaumann> error: libxml2: signature from "Andreas Baumann (sign) <mail@andreasbaumann.cc>" is invalid
[15:17:06] <abaumann> :: File /var/cache/archbuild32/libxml2-2.12.5-1.0-pentium4.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
[15:17:09] <abaumann> Do you want to delete it? [Y/n] error: failed to commit transaction (invalid or corrupted package)
[15:17:12] <abaumann> aha.
[15:17:17] <abaumann> I also get those, also with the new devtools32
[15:18:33] <abaumann> it's random.
[15:25:42] <KitsuWhooa> Haskell packages get built it get package updates takes too long
[15:25:50] <KitsuWhooa> It queues them up before it has the chance to delete them
[15:26:00] <KitsuWhooa> It'll stop once it finishes
[15:29:38] <abaumann> ah, that's why.
[15:29:44] <abaumann> no worries, they fail anyway.. :-)
[16:05:18] -!- drathir_tor has quit [Ping timeout: 260 seconds]
[16:10:30] <KitsuWhooa> nice, lxml built
[16:10:57] <abaumann> good :-)
[16:12:17] -!- drathir_tor has joined #archlinux32
[16:13:49] <KitsuWhooa> my builder also just built openrct2
[16:13:50] <KitsuWhooa> nice :p
[16:14:22] <KitsuWhooa> there's a few sphinx packages that can probably be built, so I'll queue those up
[16:14:34] <KitsuWhooa> obviously won't do anything without sphinx itself but it's something for now
[16:14:52] <abaumann> definitely
[16:52:26] -!- zxrom has quit [Quit: Leaving]
[17:15:09] <KitsuWhooa> abaumann: libfido2 0000000000000000000000000000000000000000 43160a5cc3c537c86a28dbc9dbfd9345a22ed064 core "make_source_info" did not return a "pkgbase" - eh, what?
[17:15:10] <KitsuWhooa> >==> ERROR: pkgrel is not allowed to be empty.<
[17:15:10] <KitsuWhooa> >==> ERROR: pkgver is not allowed to be empty.<
[17:15:10] <KitsuWhooa> >==> ERROR: pkgname is not allowed to be empty.<
[17:53:24] <abaumann> 4c2f2615f13fda56ef3e545539379762f740666b is the diff in arch32 packages, this doesn't make any sense
[17:54:15] <abaumann> 1 any libfido2 0000000000000000000000000000000000000000 2b17e792eb787eea19c552ec14fd2888ab28283d core
[17:54:18] <abaumann> 2 any libfido2 4a5bcdfa1e6200369f22c96d119fd14bba01f887 0000000000000000000000000000000000000000 extra
[17:54:21] <abaumann> 3 any libfido2 a42e2c4f532ce9206a46e30aeafef816c395fc6a 0000000000000000000000000000000000000000 extra
[17:54:24] <abaumann> 4 any libfido2 afeaefd117434d7f0673a640d01b4f82688c5f41 0000000000000000000000000000000000000000 extra
[17:54:27] <abaumann> none of those are correct
[17:59:42] <abaumann> I disabled the pkginfo cache for now (or maybe alltogether) and let's hope it picks up the right pkg info then. I'll force libfido2 again afterwards.
[18:00:29] <KitsuWhooa> I got that when I was doing get-package-updates
[18:00:31] <KitsuWhooa> -ignore
[18:01:34] <abaumann> ui. that's slow.. :-(
[19:09:17] -!- abaumann has quit [Ping timeout: 240 seconds]
[19:09:58] -!- clemens3 has quit [Ping timeout: 268 seconds]
[19:22:55] -!- clemens3 has joined #archlinux32
[19:43:47] -!- phrik has quit [Read error: Connection reset by peer]
[19:45:06] -!- phrik has joined #archlinux32
[20:24:54] -!- zxrom has joined #archlinux32
[20:55:59] <KitsuWhooa> package multiple times in equally stable repositories: i486/{extra-staging,extra-staging}/python-sphinxcontrib-devhelp
[20:56:00] <KitsuWhooa> package multiple times in equally stable repositories: i486/{extra-staging,extra-staging}/python-sphinxcontrib-htmlhelp
[20:56:02] <KitsuWhooa> AAAAAAAAAAAAAAAA
[21:43:42] <KillerWasp> On the python channel everyone ran away in terror as soon as they found out that I was using a 32-bit system.
[21:43:51] <KillerWasp> !shrug
[21:43:52] <phrik> ¯\_(ツ)_/¯
[23:29:11] <bill-auger> which should be ironic, given that python is an interpreted language
[23:30:05] <bill-auger> next time, tell then you are running python on a 6502
[23:34:08] <zxrom> It’s better to immediately ask where to get python for abacus.
[23:34:10] <zxrom> :D
[23:41:50] <KitsuWhooa> abaumann: libfido2 is in extra, not core. I git mv'd your PKGBUILD