#archlinux32 | Logs for 2024-08-28

Back
[00:05:59] -!- bill-auger has quit [Ping timeout: 255 seconds]
[00:15:26] mavica is now known as mavicaway
[00:16:39] -!- ssserpent has quit [Ping timeout: 260 seconds]
[00:18:43] -!- ssserpent has joined #archlinux32
[00:24:34] -!- T`aZ has quit [Ping timeout: 272 seconds]
[00:26:07] -!- T`aZ has joined #archlinux32
[00:30:03] <KitsuWhooa> Okay, wasted enough time on Ruby. MJIT is getting disabled. If someone wants it, they can fix it themselves.
[00:32:00] <KitsuWhooa> also, abaumann: What do we do about /home/slave2/builder/bin/build-packages: line 582: multilib-staging-with-build-support-pentium4-build: command not found
[00:32:10] <KitsuWhooa> Can we make a script that build stuff and puts it in extra or something?
[00:32:39] <KitsuWhooa> s/build/builds/
[00:33:49] <KitsuWhooa> abaumann: one more thing; please don't patch packages to disable pandoc
[03:05:14] -!- ssserpent has quit [Ping timeout: 260 seconds]
[06:18:41] -!- ssserpent has joined #archlinux32
[06:19:51] -!- ssserpent has quit [Client Quit]
[06:21:23] -!- ssserpent has joined #archlinux32
[07:20:45] -!- abouvier has quit [Read error: Connection reset by peer]
[07:20:45] -!- titus_livius has quit [Ping timeout: 246 seconds]
[07:21:57] -!- titus_livius has joined #archlinux32
[08:49:01] -!- bill-auger has joined #archlinux32
[12:20:40] -!- lithium_pt has quit [Quit: ZNC 1.9.1 - https://znc.in]
[12:21:01] -!- lithiumpt has joined #archlinux32
[12:46:17] -!- ssserpent has quit [Quit: WeeChat 4.4.1]
[12:47:46] -!- ssserpent has joined #archlinux32
[13:36:59] -!- ssserpent has quit [Ping timeout: 260 seconds]
[13:38:50] -!- ssserpent has joined #archlinux32
[13:49:09] -!- abaumann has joined #archlinux32
[13:49:09] <buildmaster> Hi abaumann!
[13:49:09] <buildmaster> !rq abaumann
[13:49:10] <phrik> buildmaster: <abaumann> I like hacking tools :-)
[13:49:35] <abaumann> KitsuWhooa: ah, yes, I did it the old way and removed pandoc, reverted on libavif, I forgot you can build against core-staging-with-build-support-i486-build with a pandoc shim.
[13:50:03] <abaumann> multilib-staging-with-build-support-pentium4-build, mmh. make no sense as there should be no multilib packages scheduled at all.
[14:25:25] <KitsuWhooa> Wine is
[14:25:38] <KitsuWhooa> I don't know how to make it non multilib
[14:38:14] <abaumann> mmh. we should just build it in 32-bit way and put a full PKGBUILD in extra or so?
[14:38:26] <abaumann> multilib should be blocked automatically by the buildmaster, not?
[14:50:23] -!- abaumann has quit [Quit: leaving]
[15:00:38] <KitsuWhooa> we already have a pkgbuild there but how do you put it in extra
[15:04:21] <girls> good question: either there should be logic, that ignores multilib or it should be automatically translated to extra
[15:06:36] <KitsuWhooa> I guess multilib didn't exist 4 or so years ago?
[15:26:42] <KitsuWhooa> we're down to 7.9k packages
[15:38:43] <girls> it did
[15:39:30] <girls> the original i686-deprecation notice for example specifically mentions, that multilib will keep existing as-is
[15:39:48] <girls> purpose was tho host 32-bit things, that are not available on 64-bit - like wine
[15:40:10] <girls> and that purpose is probably even as old as x86_64 itself ;)
[15:41:28] <KitsuWhooa> oh, hm
[15:41:37] <KitsuWhooa> so why did wine suddenly decide not to build
[15:41:52] <KitsuWhooa> we already have https://archlinux32.org
[15:41:53] <girls> no idea, haven't checked
[15:41:53] <phrik> Title: Arch Linux 32 - wine 5.14-1.0 (i686) (at archlinux32.org)
[15:42:08] <KitsuWhooa> well, it complains about multilib-staging-with-build-support-pentium4-build not being found
[15:42:11] <KitsuWhooa> I meant why it's trying to use that now
[15:42:14] <girls> maybe the problem is, that we move multilib packages to community and that no longer exists?
[15:42:16] <girls> lemme check
[15:42:18] <KitsuWhooa> oh
[15:42:20] <KitsuWhooa> that might do it
[15:45:45] <girls> jup, multilib lands in community
[15:46:14] <KitsuWhooa> nice
[15:46:26] <girls> but then it should try to build with community-...-build
[15:46:46] <KitsuWhooa> maybe it doesn't because it can't add them to community
[15:46:48] <KitsuWhooa> unsude
[15:46:50] <KitsuWhooa> *unsure
[15:47:26] <girls> I'll fix the repo anyways
[15:47:37] <girls> ... or I'll break the db completely >:-)
[15:47:49] <KitsuWhooa> do I get to keep both of the pieces? :p
[15:47:59] <girls> only TWO pieces?
[15:48:11] <KitsuWhooa> what, you want to share? Absolutely not
[15:48:13] <KitsuWhooa> :p
[15:49:43] <girls> mariadb buildmaster -e 'select * from repositories fr join repositories tr on fr.architecture=tr.architecture and fr.stability=tr.stability and fr.name like "community%" and tr.name like "extra%"'
[15:49:45] <girls> for a start
[15:50:33] <KitsuWhooa> we're turkish and french now?
[15:50:37] <KitsuWhooa> :p
[15:50:44] <girls> from-repo and to-repo
[15:50:56] <girls> this connects fitting community* to extra* repos
[15:51:06] <KitsuWhooa> yeah, I understand. Just being silly
[15:51:20] <girls> sry for not seeing this
[15:51:24] <girls> :D
[15:51:25] <KitsuWhooa> it's fine :p
[15:56:26] <girls> mariadb buildmaster -e 'update upstream_repositories'"$(mysql_join_upstream_repositories_repository_moves)"' left join (select fr.id as fid, tr.id as tid from repositories fr join repositories tr on fr.architecture=tr.architecture and fr.stability=tr.stability and fr.name like "community%" and tr.name like "extra%") as qf on qf.fid=from_repository join (select fr.id as fid, tr.id as tid from repositories fr join repositories tr on f
[15:56:28] <girls> r.architecture=tr.architecture and fr.stability=tr.stability and fr.name like "community%" and tr.name like "extra%") as qt on qt.fid=to_repository set from_repository=coalesce(qf.tid,from_repository),to_repository=qt.tid where upstream_repositories.name="multilib"'
[15:56:30] <girls> objections?
[15:56:32] <girls> 3
[15:56:34] <girls> 2
[15:56:36] <girls> 1
[15:56:42] <girls> done
[15:56:46] <girls> :-p
[15:56:50] <KitsuWhooa> we'll find out
[15:56:52] <KitsuWhooa> :p
[15:58:08] <girls> yeah, looks good
[15:58:22] <girls> let's see, whether this actually fixes the build
[15:59:41] <KitsuWhooa> then there's the uphill battle of patching it to build :p
[16:03:15] <girls> there I'm out of my depth
[16:12:44] <girls> maybe we should re-think the current approach of blacklisting: when a pkgbase is blacklisted, we still need to pull it and updates for it, because it will transitively also block all dependent packages. It would be a lot faster, if we would just drop this requirement and blacklist all dependent packages themself - then we could directly filter out all those pkgbases and not even run `makepkg --printsrcinfo` on them. Though, this mig
[16:12:44] <girls> ht be tricky, if the package is not blacklisted in all architectures, maybe.
[16:13:37] <KitsuWhooa> ideally, yes
[16:13:44] <KitsuWhooa> but sometimes a package can still be built even with another blacklisted
[16:14:04] <KitsuWhooa> that said, that's what get-package-updates-ignore is for :p
[16:14:19] <KitsuWhooa> it's for when I'm not patient and I don't want it to go through the entirety of haskell
[16:16:55] <girls> ah, now I remember
[16:17:09] <girls> the assumption is, that we _track_ everything, but we do not actually _build_ blacklisted stuff
[16:17:22] <girls> so it should only be relevant, when e.g. haskell gets an update
[16:17:42] <KitsuWhooa> it goes through every blacklisted package every time
[16:17:50] <girls> then that's a bug :(
[16:17:53] <KitsuWhooa> not whenever it's updated
[16:18:52] <girls> maybe I got the muse to wrap my brain around the respective mysql queries this evening - let's see :D
[16:21:34] <KitsuWhooa> but hey, I was able to fix mpdecimal being rebuilt every time get-package-update ran! :p
[16:21:45] <girls> \o/
[16:21:47] <girls> how?
[16:21:56] <KitsuWhooa> upstream moved it from extra to core
[16:22:04] <KitsuWhooa> it was stuck in extra on our end
[16:22:14] <KitsuWhooa> so I gave it a little push in the DB :p
[16:22:23] <girls> great :)
[16:22:31] <KitsuWhooa> https://archlinux32.org
[16:22:32] <phrik> Title: Arch Linux 32 - mpdecimal 4.0.0-2.335 (pentium4) (at archlinux32.org)
[16:22:37] <KitsuWhooa> version 4 only got rebuilt 335 times
[16:22:48] <KitsuWhooa> those poor electrons
[16:22:49] <girls> there once was some logic for moves between extra and community - but I suspected, that it was always buggy/broken
[17:12:32] -!- ssserpent has quit [Ping timeout: 252 seconds]
[17:14:37] -!- ssserpent has joined #archlinux32
[17:14:55] <girls> incredible: it does exactly, what it's told
[17:15:25] <KitsuWhooa> amazing
[17:17:03] <girls> the problem is, that we cannot distinguish (in the db) between a package, that is deleted, because it's blacklisted and one, that's deleted, because it was deleted upstream
[17:17:21] <KitsuWhooa> time to add a deletion reason
[17:17:28] <girls> in the first case, we do _not_ want to react on a diff between upstream and local, in the second case, we want to
[17:17:32] <girls> yeah
[17:18:56] <girls> another repository (besides deletion-list) might be another option
[17:19:01] <girls> like [black-list]
[17:20:20] <girls> let me ponder this, while I clean some children
[17:22:31] <girls> a separate repository has the advantage, that we do not need to change the db schema and that the deletion reason column would only make sense, when is_to_be_deleted is true.
[17:24:16] <girls> hmm, should all packages, which are removed due to being dependent on a blacklisted package, be on the deletion-list or on the black-list?
[17:24:26] <girls> probably the former
[17:24:40] <girls> ah, no
[17:25:06] <girls> even if they were on the black-list, we would still pull updates for them and notice, if the dependencies changes, so they would become buildable
[17:41:07] <girls> hmm, do we actually need to distinguish? If the most-recent-upstream package is on the deletion-list, then we should not re-schedule (and possibly then delete) it again - right?
[17:41:26] <girls> no matter the reason for being on the deletion-list
[17:50:33] <girls> I'm tempted to simply revert https://git.archlinux32.org - but I'm afraid, it is there, because it fixed _something_
[17:50:35] <phrik> Title: bin/get-package-updates: ignore to_be_deleted packages - builder - Archlinux32 build system (at git.archlinux32.org)
[17:52:39] <KitsuWhooa> say thanks to your past self :P
[17:52:44] <KitsuWhooa> for not explaining why
[17:52:51] <girls> it explains the "why"
[17:53:05] <KitsuWhooa> I mean, what it fixes
[17:53:19] <girls> much has changed since then - I'll just give it a try. If you see "package $xyz is on the deletion-list and the build-list", then simply re-apply that commit
[17:53:27] <KitsuWhooa> alright
[17:55:24] <girls> I tried to be a bit more explanatory than back then
[17:55:33] <girls> let's see, what my future self says to that :D
[17:56:13] <girls> but first I'll see, what get-package-updates says, when running it manually :)
[17:56:41] <KitsuWhooa> fingers crossed
[17:59:19] <girls> it's a lot faster - as expected :)
[18:01:34] <KitsuWhooa> /usr/lib/gcc/i686-w64-mingw32/13.1.0/../../../../i686-w64-mingw32/bin/ld: /build/efifs/src/EfiFs-ia32/src/..//grub/libgrub.a: error adding symbols: archive has no index; run ranlib to add one
[18:01:37] <KitsuWhooa> this is going well
[18:13:54] <KitsuWhooa> oh https://stackoverflow.com
[18:13:54] <phrik> Title: gcc - could not read symbols: Archive has no index; run ranlib to add one - Stack Overflow (at stackoverflow.com)
[18:20:37] <girls> it still runs delete_package on all black-listed packages, making it _somewhat_ slow
[19:17:13] -!- AtleoS has joined #archlinux32
[19:25:48] <KitsuWhooa> it's deleting so many packages in community
[19:25:58] <KitsuWhooa> that doesn't seem right?
[19:26:03] <KitsuWhooa> aren't they already deleted and not updated anymore?
[19:26:21] <KitsuWhooa> maybe we should ignore community entirely
[19:36:51] -!- drathir_tor has quit [Ping timeout: 260 seconds]
[19:38:13] <KitsuWhooa> Hmmm this seems wrong
[19:38:23] <KitsuWhooa> this is 6.5 https://archlinux.org
[19:38:25] <phrik> Title: Arch Linux - breeze-icons 6.5.0-1 (x86_64) (at archlinux.org)
[19:38:25] <KitsuWhooa> we have 6.1
[19:39:02] <KitsuWhooa> it hasn't picked up the new hash
[19:52:39] -!- drathir_tor has joined #archlinux32
[19:52:50] <KitsuWhooa> a feature for the future would be nice to have an implied order of things to be built
[19:53:28] <KitsuWhooa> dependencies should do that, but shrug
[20:47:15] -!- ssserpent has quit [Quit: WeeChat 4.4.1]
[21:37:25] mavicaway is now known as mavica