#archlinux32 | Logs for 2023-07-03

Back
[06:46:18] -!- drathir_tor has quit [Ping timeout: 240 seconds]
[08:33:24] -!- drathir_tor has joined #archlinux32
[09:14:38] -!- mvchtz has quit [Quit: WeeChat 3.5]
[09:16:21] -!- mvchtz has joined #archlinux32
[15:27:01] -!- abaumann has joined #archlinux32
[15:27:02] <buildmaster> Hi abaumann!
[15:27:02] <buildmaster> !rq abaumann
[15:27:03] <phrik> buildmaster: <abaumann> easy: I just make sure I have the fastest hardware :-)
[15:27:22] <abaumann> KituWhooa: I have two ideas here: if makesrcinfo is failing, then no new packages are fed into the buildmaster.
[15:27:55] <abaumann> OTOH. The existing queued 13'000 packages are all forced to rechenknecht, so maybe that simply takes to long and the build jobs should be equally spread across the cluster..
[15:28:21] <abaumann> ..I don't know, if that's the case, so: whether forcing a package to a build machine is just a hint or mandatory.
[15:28:36] <abaumann> anyways, I have to fix the pkginfo thingy now anyway first..
[15:29:10] <abaumann> I think I can just temporarily add the missing install file locally in arch32 packages for nvme-cli.
[15:40:07] <KitsuWhooa> Someone didn't tab auto compete :p
[15:40:26] <KitsuWhooa> Yeah I'm not sure
[15:50:49] <abaumann> nvme-cli 247bbbd1a8c09ea1bbc63ac926ceb4d70aae4b3b 0000000000000000000000000000000000000000 extra "make_source_info" did not return a "pkgbase" - eh, what?
[15:51:05] <Foxboron> heh
[15:51:06] <abaumann> huh. I have committed a local nvme-cli nvme.cli.install?
[15:51:07] <Foxboron> abaumann: sorry
[15:51:36] <Foxboron> https://gitlab.archlinux.org lets just say I fucked up yesterday
[15:51:38] <phrik> Title: Commits · main · Arch Linux / Packaging / Packages / nvme-cli · GitLab (at gitlab.archlinux.org)
[15:52:16] <abaumann> Foxboron: easy, our build system should really be able to cope with that, I just added new fancy caching stuff (which is not yet working). :-)
[15:52:19] <KitsuWhooa> abaumann: is there a reason those packages are doe rechenknecht?
[15:52:24] <KitsuWhooa> *are for
[15:52:41] <KitsuWhooa> I can't readily check what my builders are doing atm
[15:52:42] <Foxboron> abaumann: Argueably I should not have been able to make that mistake on our end either :)
[15:52:50] <abaumann> aeh. I think at the time when they were forced all other build machines didn't exist or were broken.
[15:52:56] <KitsuWhooa> Ah
[15:53:17] <KitsuWhooa> I suspect my builders are mostly idle at this point, so I wouldn't mind having work thrown my way
[15:53:45] <abaumann> KitsuWhooa: it could be worse, they produce packages which don't work after building :-)
[15:53:53] <abaumann> it's just wasted electrons..
[15:54:53] <abaumann> Foxboron: my bigger problem is, that the process on our side is supposed to pick up the modified_git_revision (where I fixed things), but it insists telling me it wants to build revision 0000000000000000000000000000000000000000 (which is the checksum equivalent of a null pointer).
[15:55:30] <KitsuWhooa> Hah
[15:55:31] <abaumann> and bugs should just be protocolled and the process should continue with the 99.999% ok packages.
[15:55:59] <KitsuWhooa> I wonder if nmap has been rebuilt yet
[15:56:08] <KitsuWhooa> Last time I needed to use it, it depended on missing libssl
[15:56:28] <abaumann> -rw-rw-r-- 1 http http 310 Nov 12 2020 nmap-7.91-1.0-pentium4.pkg.tar.zst.sig
[15:56:31] <abaumann> -rw-rw-r-- 1 http http 5714921 Nov 12 2020 nmap-7.91-1.0-pentium4.pkg.tar.zst
[15:56:34] <abaumann> -rw-rw-r-- 1 http http 566 Nov 12 2020 nmap-7.91-1.0-i686.pkg.tar.zst.sig
[15:56:36] <KitsuWhooa> That's a no then
[15:56:37] <abaumann> -rw-rw-r-- 1 http http 5715031 Nov 12 2020 nmap-7.91-1.0-i686.pkg.tar.zst
[15:56:40] <abaumann> -rw-r--r-- 1 http http 310 Nov 18 2022 nmap-7.93-1.0-i486.pkg.tar.zst.sig
[15:56:43] <abaumann> -rw-r--r-- 1 http http 5820314 Nov 18 2022 nmap-7.93-1.0-i486.pkg.tar.zst
[15:56:45] <abaumann> urgh.
[15:57:12] <KitsuWhooa> I wonder if there's a way to run a script that installs packages and checks for missing libraries
[15:57:27] <KitsuWhooa> I think namcap kind of checks for libraries
[15:57:46] <KitsuWhooa> But it's been a few years now and there are still packages depending on long gone libraries
[15:57:57] <KitsuWhooa> And the build pipeline is basically stalled...
[15:58:12] <KitsuWhooa> Granted idk if it depends on python and what's why it can't be rebuilt
[15:58:39] <KitsuWhooa> *that's why
[15:58:45] <KitsuWhooa> Auto cucumber in full force
[15:59:27] <abaumann> many things can be blamed on Python ATM ;-)
[16:00:12] <abaumann> I just wanted to add some code lately for the _slow_ pkginfo creation and the code overwhelmed me..
[16:00:30] <abaumann> ..the build system is not something I really know well - or better at all
[16:00:42] <KitsuWhooa> Still more than I do :p
[16:17:50] <abaumann> manipullating package_sources didn't help :-(
[16:21:07] <abaumann> curl https://buildmaster.archlinux32.org fails too, why, what is this revision?
[16:22:08] <abaumann> 01bac14394831542e84e98e4193b8daf49dde23f does not exist in https://gitlab.archlinux.org
[16:22:09] <phrik> Title: Arch Linux / Packaging / Packages / nvme-cli · GitLab (at gitlab.archlinux.org)
[16:22:11] <abaumann> *sigh*
[16:23:08] <abaumann> and I cannot have two package_sources with same git and mod_git revision (there is a constraint on it)
[16:29:06] <abaumann> ok, I'm unable to move anything..
[16:29:08] -!- abaumann has quit [Quit: leaving]
[17:09:39] <KitsuWhooa> Ouch