#archlinux32 | Logs for 2024-05-14

Back
[00:08:39] -!- bdju has quit [Quit: Reconnecting]
[00:08:55] -!- bdju has joined #archlinux32
[00:14:55] -!- drathir_tor has joined #archlinux32
[02:40:09] -!- dmc has quit [Quit: WeeChat 4.2.1]
[03:21:17] -!- dmc has joined #archlinux32
[08:11:18] <KitsuWhooa> lets see how quickly buildmaster goes insane again
[08:11:39] <KitsuWhooa> as a sidenote, I think I'm going to push python3.12 to stable
[08:14:18] -!- zxrom_ has joined #archlinux32
[08:16:17] -!- zxrom has quit [Ping timeout: 272 seconds]
[08:16:49] -!- AtleoS has joined #archlinux32
[08:21:32] zxrom_ is now known as zxrom
[09:45:38] -!- ssserpent has joined #archlinux32
[10:12:08] -!- ssserpent has quit [Quit: WeeChat 4.2.2]
[10:13:17] -!- ssserpent has joined #archlinux32
[10:20:30] -!- ssserpent has quit [Quit: WeeChat 4.2.2]
[10:21:35] -!- ssserpent has joined #archlinux32
[10:47:02] -!- ssserpent has quit [Quit: WeeChat 4.2.2]
[10:48:18] -!- ssserpent has joined #archlinux32
[13:47:26] -!- ssserpent has quit [Read error: Connection reset by peer]
[13:53:38] -!- ssserpent has joined #archlinux32
[13:58:38] -!- abaumann has joined #archlinux32
[13:58:38] <buildmaster> Hi abaumann!
[13:58:39] <buildmaster> !rq abaumann
[13:58:39] <phrik> buildmaster: <abaumann> *abaumann does some hackeroo on his rsync-woodo-script..
[13:58:51] <abaumann> KitsuWhooa: python 3.12 to stable, cannot get worse ;-)
[13:59:19] <abaumann> jacko1: thanks for the offer. We always welcome some helping hands. :-)
[13:59:30] <abaumann> Just out of curiousity: do you run some old machines?
[14:00:04] <abaumann> The skills we need are pretty much accross shell scripting, mysql, Archlinux packaging, ISO master, python hacking (archbuild), etc.
[14:00:09] <abaumann> *across
[14:01:03] <abaumann> The build system is a beast of its own, and it exists exactly once - as productive system. Usually reading a lot, thing even more, then changing things is required there :-)
[14:01:13] <abaumann> *think
[14:01:44] <abaumann> There is also some php stuff (web page, package view) etc. which could be interesting to do
[14:02:17] <abaumann> package multiple times in equally stable repositories: i686/{extra-staging,extra-staging}/python-snappy
[14:02:18] <KitsuWhooa> I suspect they won't rejoin >.>
[14:02:20] <abaumann> package multiple times in equally stable repositories: pentium4/{extra-staging,extra-staging}/python-snappy
[14:02:23] <abaumann> yep, again.
[14:02:26] <KitsuWhooa> abaumann: yes, it keeps happening
[14:02:30] <abaumann> mmh.
[14:02:42] <KitsuWhooa> it thinks that any/python-snappy is different from the other ones
[14:02:45] <abaumann> along to the mnumerics? and sysfsutils which get build the 1000nds time.
[14:02:46] <KitsuWhooa> and so it builds both
[14:02:58] <KitsuWhooa> but then it tries to replace the any with the arch-specific one and fails
[14:03:00] <KitsuWhooa> because the version is older
[14:03:10] <KitsuWhooa> I think it's something to do with the state repo
[14:03:14] <abaumann> we could just copy the PKGBUILD from upstream and change arch?
[14:03:51] <KitsuWhooa> might be worth a try, but we can't keep doing this for every arch-dependent package turend into any
[14:03:56] <KitsuWhooa> I suspect this isn't going to be a one off
[14:04:14] <abaumann> it was just to test the hypotheses. ;-)
[14:04:38] <abaumann> the PKGBUILD of python-snappy doesn't look that terribly compliated and different.
[14:04:45] <abaumann> nothing obvious for sure.
[14:05:03] <abaumann> it could also be, that it's not the package at all but just bad luck with the state in the database.
[14:05:15] <KitsuWhooa> I manually deleted all traces I could find of 0.6
[14:05:21] <KitsuWhooa> and get-package-updates picked up on it and re-added it
[14:05:34] <KitsuWhooa> 17:05:15 <KitsuWhooa> I manually deleted all traces I could find of 0.6 <-- from the database
[14:05:56] <KitsuWhooa> but you can give it a try too if you want :p
[14:06:04] <abaumann> I had some other packages I had the suspicion it took up an old version. Like the filesystem one..
[14:06:25] <abaumann> there could be inconsistencies in the git state database (maybe python-snappy exists twice?)_
[14:06:30] <KitsuWhooa> it might
[14:06:40] <KitsuWhooa> I have no idea how it works, that's why I haven't dug into it already
[14:06:43] <KitsuWhooa> (and haven't had the time of course)
[14:07:02] <abaumann> ./extra-x86_64/python-snappy
[14:07:04] <abaumann> ./extra-any/python-snappy
[14:07:08] <abaumann> this cannot be good
[14:07:21] <KitsuWhooa> wait, x86_64?
[14:07:23] <abaumann> upstream is somewhat stubborn.
[14:07:28] <KitsuWhooa> oh
[14:07:29] <KitsuWhooa> OH
[14:07:37] <KitsuWhooa> yes that explains it I think'
[14:07:39] <abaumann> I really wish they would make some git hooks to test basic consistency of the state repo
[14:07:45] <KitsuWhooa> any is 0.7, x86_64 is 0.6
[14:07:49] <abaumann> aha.
[14:07:52] <KitsuWhooa> but why is it still there?
[14:07:53] <abaumann> somebody forgot to remove it
[14:08:00] <abaumann> kick upstream, I would suggest. :-)
[14:08:04] <KitsuWhooa> who do we bug about it? :p
[14:08:26] <abaumann> that's always a problem. normally they say: "the binary package built fine, this is not a bug"
[14:08:40] <abaumann> we could also compare the versions and pick the newer one in case we have both
[14:08:47] <KitsuWhooa> yes, but I assume they wouldn't want an outdated package around though
[14:09:01] <abaumann> but I have to admit. I never read the buildmaster got around the new git state handling
[14:09:30] <abaumann> The modern way is to write a php web page and an automatic script doing a check
[14:09:40] <KitsuWhooa> I was not around pre-git, so :p
[14:09:56] <abaumann> see. if jacko1 appears again, I have tons of ideas, what can be implemented. :-)
[14:10:10] <KitsuWhooa> I was going to ask them to try to get things building
[14:10:11] <KitsuWhooa> like node
[14:10:31] <KitsuWhooa> also, for i686/pentium4, python is doing pretty well
[14:10:46] <KitsuWhooa> https://archlinux32.org
[14:10:48] <abaumann> I think, it will also work somewhat again on i486
[14:10:51] <KitsuWhooa> there aren't that many broken packages
[14:11:02] <abaumann> In the end, we have to bring rust to i486 probably for that.
[14:11:03] <KitsuWhooa> and some of them depend on things like cuda
[14:11:11] <KitsuWhooa> yeah
[14:11:14] <KitsuWhooa> I also wanted to look into that
[14:11:31] <KitsuWhooa> I also wanted to bring wine back
[14:11:33] <abaumann> as long as python/meson and some basic modules work, it should not matter if packages are broken on i486.
[14:11:37] <abaumann> *python packages, I meant
[14:11:42] <KitsuWhooa> yeah
[14:12:06] <abaumann> I have to see, what t2sde is doing for getting rust onto i486
[14:12:19] <abaumann> though their way is via cross-compilation and somewhat different probably.
[14:12:35] <abaumann> Then the gcc-rust and python modules requiring rust would not be an issue anymore.
[14:12:46] <KitsuWhooa> can we not use the prebuilt rust to build a dumbed down one?
[14:12:52] <KitsuWhooa> our builders can run SSE2 just fine :p
[14:13:04] <KitsuWhooa> actually, I suspect the issue is you're in a VM and it runs out of memory
[14:13:15] <KitsuWhooa> that's the other reason I wanted to get i486 in a chroot
[14:13:19] <abaumann> yes, that's quite likely
[14:13:39] <abaumann> I did once some tests with mrust and bootstrapping rust this way, but that's just painful
[14:14:02] <abaumann> there you get C++ (mrust) as dependency and and the result is an unsafe rust.
[14:14:11] <abaumann> but a rust which can build a proper rust afterwards.
[14:14:21] <abaumann> but there might be atomic and other stuff missing in rust for i486
[14:14:25] <KitsuWhooa> maybe something we can have in build-support
[14:15:09] <abaumann> btw: extra-x86_64/python-snappy, you can just do an "if" in the builder and ignore that one.
[14:15:24] <abaumann> I think I did similar things for the kde/gnome-testing repos.
[14:15:31] <KitsuWhooa> doing that per builder sounds.... not good :p
[14:15:33] <KitsuWhooa> for repos, sure
[14:15:35] <KitsuWhooa> but for packages?
[14:15:50] <KitsuWhooa> I think it's best to have get-package-updates not pick up on it in the first place
[14:15:54] <abaumann> just temporary. there can't be that many duplicates in git repo
[14:16:01] <KitsuWhooa> if we're going to hack something, we might as well hack it there I think
[14:16:12] <abaumann> that's where this happens, IIRC
[14:16:43] <abaumann> while read -r pkgbase repository git_revision mod_git_revision; do
[14:16:44] <abaumann> if test "$repository" = "kde-unstable"; then
[14:16:44] <abaumann> continue
[14:16:44] <abaumann> fi
[14:16:44] <abaumann> if test "$repository" = "gnome-unstable"; then
[14:16:46] <abaumann> continue
[14:16:48] <abaumann> fi
[14:17:11] <KitsuWhooa> ah
[14:17:16] <abaumann> ok, we just have pkgbase and git_revision there
[14:17:21] <abaumann> ok, but that also works.
[14:17:27] <KitsuWhooa> yeah because it won't be updated
[14:18:00] <abaumann> if we ignore the git_revision of the 0.6 and and let the 0.7 one past?
[14:18:14] <KitsuWhooa> 0.7 and any other ones
[14:18:45] <abaumann> right.
[14:18:47] <KitsuWhooa> 03fd4a0a1cee6144848a5e5de6e03f0319e9d118
[14:18:50] <KitsuWhooa> that's the 0.6 one
[14:19:06] <abaumann> "...it's just an if..." ;-)
[14:19:07] <KitsuWhooa> https://gitlab.archlinux.org
[14:19:08] <phrik> Title: upgpkg: 0.6.1-4: Rebuild with Python 3.12 (c4d79fe8) · Commits · Arch Linux / Packaging / Packages / python-snappy · GitLab (at gitlab.archlinux.org)
[14:19:34] <abaumann> pkgctl can do repo migrations and checkins. It could also check for duplicates..
[14:20:02] <abaumann> but still, people could use git directly to create new git states.. mmh.
[14:20:07] <KitsuWhooa> yeah
[14:20:10] <abaumann> I stand by the idea if git hooks.
[14:21:15] <abaumann> schroedingerbot: detects states of packages.. ;-)
[14:23:15] <KitsuWhooa> 🐈
[15:48:54] -!- drathir_tor has quit [Ping timeout: 260 seconds]
[15:54:58] -!- drathir_tor has joined #archlinux32
[16:24:08] -!- AtleoS has quit [Ping timeout: 268 seconds]
[17:06:31] -!- abaumann has quit [Remote host closed the connection]
[19:54:41] -!- ssserpent has quit [Quit: WeeChat 4.2.2]
[20:42:17] -!- zxrom has quit [Remote host closed the connection]
[20:42:41] -!- zxrom has joined #archlinux32
[23:40:02] mavicaway is now known as mavica