#archlinux32 | Logs for 2024-10-27
Back
[00:50:51] -!- kiska31 has joined #archlinux32
[00:52:41] -!- kiska3 has quit [Ping timeout: 265 seconds]
[00:52:42] kiska31 is now known as kiska3
[05:59:34] -!- drathir_tor has quit [Remote host closed the connection]
[05:59:58] -!- drathir_tor has joined #archlinux32
[06:09:37] -!- drathir_tor has quit [Remote host closed the connection]
[06:10:05] -!- drathir_tor has joined #archlinux32
[09:02:56] -!- n0tiz has quit [Quit: Bye]
[09:05:17] -!- n0tiz has joined #archlinux32
[09:06:17] -!- n0tiz has quit [Client Quit]
[09:07:56] -!- n0tiz has joined #archlinux32
[10:10:16] -!- drathir_tor has quit [Ping timeout: 260 seconds]
[10:10:40] -!- drathir_tor has joined #archlinux32
[10:50:33] -!- ssserpent has joined #archlinux32
[11:02:31] -!- ssserpent has quit [Quit: WeeChat 4.4.2]
[11:03:43] -!- ssserpent has joined #archlinux32
[11:46:15] -!- ssserpent has quit [Quit: WeeChat 4.4.2]
[15:03:00] <KitsuWhooa> I assume the wasm issue is because it's in extra-staging or testing
[15:03:09] <KitsuWhooa> if you can find out which package it is, I can push it to stable
[16:08:44] <bill-auger> KitsuWhooa: pacman -Ss wasi
[16:08:54] <bill-auger> 4 packjages total
[16:09:29] <KitsuWhooa> yes, but I can't tell what is needed to fix it
[16:09:39] <bill-auger> oh sry i had that mixed up
[16:09:48] <bill-auger> the wasi packages are already in extra - they sholud not be
[16:10:00] <KitsuWhooa> so the only way to fix them is to push whatever they need to extra as well
[16:10:09] <bill-auger> becuase it needs the llvm and clang which are in staging
[16:10:18] <KitsuWhooa> so if you can manually install packages from staging/testing until you get it working, I'll push those too
[16:10:21] <KitsuWhooa> > llvm
[16:10:23] <KitsuWhooa> oh
[16:10:28] <KitsuWhooa> yeah that's a problem
[16:10:33] <bill-auger> LLVM and clang, and anything else that depends on that specific version
[16:11:01] <KitsuWhooa> I have no idea how to push something and everything that depends on it unless I manually resolve all the dependencies
[16:11:03] <bill-auger> possibly anything else that was compiled against llvm-libs v18
[16:11:07] <KitsuWhooa> yeah
[16:11:13] <KitsuWhooa> it's a mess
[16:11:40] <KitsuWhooa> it's why python 3.12 is still sitting in staging
[16:11:57] <KitsuWhooa> I tried pushing python and it only pushed python itself to testing
[16:13:02] <KitsuWhooa> why on earth did buildmaster push wasi to stable
[16:13:49] <bill-auger> i have to wonder, the way things have been going, it may be best to not use staging or testing - tes every package manually and publish everything direct to extra
[16:14:15] <KitsuWhooa> 0 resources to do that
[16:14:50] <KitsuWhooa> the reason things are stuck in staging is because not everything has been built
[16:14:56] <bill-auger> my rationale for thst is quite practical - currently, i tell everyone to enable all testing and staging repos becuae usually that solves 99% of bugs
[16:15:16] <KitsuWhooa> and someone needs to go through and either blacklist what doesn't build or fix it
[16:15:18] <KitsuWhooa> and no one has done that
[16:15:27] <KitsuWhooa> there have been many instances where staging has been super broken
[16:15:34] <KitsuWhooa> I'd be fine with merging testing with main
[16:15:36] <KitsuWhooa> but not staging
[16:15:45] <bill-auger> in other words, the stable branches are _much_ buggier than the unstable branches, which clearly indicates a maintenance issue
[16:16:30] <KitsuWhooa> fwiw I run stable on my laptop
[16:16:47] <KitsuWhooa> whenever I see something break I try to fix it
[16:17:08] <KitsuWhooa> but having seen how builders can just break staging in an instant, I'd never advise to enable staging
[16:17:22] <KitsuWhooa> but again, this all stems because we don't have resources to fix broken packages
[16:17:39] <KitsuWhooa> if the packages didn't remain broken forever, we wouldn't be stuck with half broken packages because they had some vague dependency
[16:18:37] <bill-auger> normally i would not recommend it either - but the fact is that i need to enable testing or staging for most builds because there is almost always some incompatibilities in main
[16:18:49] <KitsuWhooa> yeah, I understand
[16:18:54] <KitsuWhooa> it just really sucks
[16:20:54] <bill-auger> well given the name "staging", it really should never be broken - semantically at least, the build server should not put anything into staging - that should always be done manually after manual testiong
[16:21:34] <bill-auger> when something enters the staging area, that essentially to indicate that it is ready for main, but i waiting for it's enteroge
[16:21:50] <bill-auger> (however that is spelled)
[16:22:27] <KitsuWhooa> the priority is currently stable > testing > staging
[16:22:30] <bill-auger> pedantically, "staging" is a place to accumulate things that are ready to move, once all parts to be moved are all collected - then they all migrate together to avoid breakage
[16:22:37] <KitsuWhooa> I agree, but I didn't name it :p
[16:22:44] <bill-auger> ok but that is wrong semantuically
[16:22:54] <KitsuWhooa> I think it's too late to fix
[16:23:03] <KitsuWhooa> unless we merge stable with testing
[16:23:03] <bill-auger> stable <- staging <- testing is the workflow
[16:23:42] <bill-auger> i think maybe i would do that - then remove testing from pacman.conf and you cuold still use it internally
[16:23:58] <KitsuWhooa> there will always be people who will have testing enabled
[16:24:03] <KitsuWhooa> and it'll put their systems at risk
[16:24:05] <KitsuWhooa> so idk
[16:24:19] <KitsuWhooa> but then I'm not a fan of the whole "we told you so in a blog post it's your fault for not reading it"
[16:25:04] <bill-auger> i would not worru about that - people on the testing aqnd staging channels should be aware that they are experimental - no promises whatso-evcer
[16:25:40] <bill-auger> no promises, including that staging and testing may not exist some day
[16:25:53] <KitsuWhooa> perhaps
[16:26:18] <bill-auger> put another IMHO staging and testing are for people who want to help the distro by finding and reporting bugs
[16:27:33] <bill-auger> users who are not ready to report the bugs they find in the unstable repo, are not entitled to an opinion about those repos
[16:28:35] <bill-auger> so i would not hestate to make big changes, if it would improve the distro over-all
[16:31:17] <bill-auger> in other words, using testing or staging is supposed to be risky- the system is at risk simply by using packages from unstable channels
[16:31:57] <KitsuWhooa> fair
[16:31:58] <bill-auger> those who want to avoid risk should use only the stable packages
[16:39:58] <bill-auger> put another way, as the user-base is small, then few bug reports would come out of testing or staging - in that case, you may as well not publish though repos at all - to have all users be using exactly the same packages , it could be a noticeable improvement in user feedback
[16:41:18] <KitsuWhooa> again, I disagree with not having one separate repo for packages that come out of the builders
[16:41:35] <KitsuWhooa> consider this: when upstream pushes python 3.13, things *will* break
[16:41:46] <KitsuWhooa> and a system without working python is unusable
[16:41:58] <bill-auger> you could keep all of the biuld tools how they are - just dont publish those repos
[16:42:00] <KitsuWhooa> just because someone opts into a repository to provide feedback doesn't mean they want their system to not work at all
[16:42:38] <KitsuWhooa> sure, so it goes back to me saying we should merge stable with testing
[16:42:45] <KitsuWhooa> whether staging is published or not, doesn't really matter imo
[16:42:46] <bill-auger> yes the python ecosystem is a great example
[16:43:37] <bill-auger> for most of the past year, python has been broken for all users, regardliess of the realease channel
[16:43:47] <KitsuWhooa> what do you mean?
[16:43:53] <KitsuWhooa> Most of the 3.11 packages have been built
[16:44:12] <KitsuWhooa> there definitely are issues, but I wouldn't call it broken
[16:44:31] <bill-auger> becuase during the transition from one python to the next, some packages require one version or the other
[16:44:41] <KitsuWhooa> ah
[16:44:48] <KitsuWhooa> again, that goes back to not all packages being built
[16:44:59] <KitsuWhooa> because they are broken
[16:45:04] <KitsuWhooa> and no one has the time to either get rid of or fix them
[16:47:08] <bill-auger> people on testinng/staging were using a different python than everyone else - for those people, all python programs for the older version in main would not work - for people using the main repos, all python programs for the next version would not work -
[16:48:19] <KitsuWhooa> well, yes, testing currently has 3.12 without any 3.12 packages
[16:48:50] <bill-auger> thats ok though - testing is allowed to be broken
[16:49:49] <bill-auger> it seem that what happened, is some python packages build fr the newer versiojn somehow leaking into main, replacing the ones that were compatible with the python in main
[16:50:06] <KitsuWhooa> that's because buildmaster thinks they can be moved to stable
[16:50:18] <KitsuWhooa> why? I have no idea
[16:50:30] <KitsuWhooa> maybe the upstream dependencies aren't correct, maybe there's a bug in the algorithm that checks for compatible dependencies
[16:50:55] <bill-auger> that is the purpose for staging - all of thiose packckges must be held-back until everything works consistently - then python and all python packages move together
[16:50:55] <KitsuWhooa> yeah
[16:51:07] <KitsuWhooa> but there's no one to do that
[16:51:13] <bill-auger> yea there are mny thiong that can complicate that simple sounding plan
[16:51:13] <KitsuWhooa> and there won't be anyone to do that
[16:51:25] <KitsuWhooa> https://archlinux32.org
[16:51:27] <phrik> Title: Arch Linux 32 - wasi-compiler-rt 18.1.8-2.0 (any) (at archlinux32.org)
[16:51:29] <KitsuWhooa> there's no version information for llvm
[16:51:42] <KitsuWhooa> and llvm is a makedepend
[16:51:45] <bill-auger> "18" is the version
[16:52:00] <KitsuWhooa> yes but there's nothing that says "depend in llvm=18"
[16:52:05] <KitsuWhooa> *on
[16:52:19] <bill-auger> i know - it is not obvious - i could show you the log though
[16:52:27] <KitsuWhooa> the only runtime dep is wasi-libc which has 0 dependencies
[16:52:29] <KitsuWhooa> https://archlinux32.org
[16:52:31] <phrik> Title: Arch Linux 32 - wasi-libc 1:0+392+b9ef79d7-1.0 (any) (at archlinux32.org)
[16:52:38] <KitsuWhooa> so buildmaster went "okay I can move all those packages to main as they don't depend on anything"
[16:52:45] <KitsuWhooa> but they do depend on llvm evidently
[16:53:02] <bill-auger> the conflict happens at runtime, when the compiler (compiling something else) looks for wasi support and can not find it
[16:53:31] <KitsuWhooa> I get it, I'm just explaining the problem of how packages creep into stable
[16:54:15] <bill-auger> the general solution is to add a specific pinned dependency - maybe then, the builder could check for dependency conflicts before moving anything into main
[16:54:29] <KitsuWhooa> which it does, no?
[16:54:44] <KitsuWhooa> the problem is that the package doesn't have enough dependency info
[16:54:57] <KitsuWhooa> and that's just an arch packaging thing in general
[16:55:01] <bill-auger> maybe it does, but that would not work now, becuase the dependency is not specific
[16:55:11] <KitsuWhooa> but it's not an issue upstream because they have the people there to make sure things work
[16:55:13] <KitsuWhooa> we don't
[16:55:26] <bill-auger> you would need to add a depends=( llvm-libs=18)
[16:55:37] <KitsuWhooa> that is correct, and it'd need to be automated
[17:02:32] <bill-auger> oj i ciukd show you this once script eli made - that may help
[17:03:06] <bill-auger> it sifts through a package binaries and report all linkages to other packages
[17:03:31] <bill-auger> exposing many of those "hidden" depenencies
[17:04:25] <bill-auger> https://github.com
[17:04:27] <phrik> Title: dotfiles/bin/pkg-list-linked-libraries at master · eli-schwartz/dotfiles · GitHub (at github.com)
[17:07:07] <KitsuWhooa> would be nice to integrate something like that, yeah
[17:08:45] <bill-auger> i thnk that would not help for those WASI packages though, because it is not a linkage problem - it is the compiler, searching the filesystem for files that may or may not have been put there from another package - theres probably no automatic way to detect that
[17:10:15] <bill-auger> but maybe could keep it own crude "knowlege base", associating groups of packages as a set, which must all move together
[17:13:51] <bill-auger> things like python would be a buge coupled set - basically every package strting with python-* would be in that set
[17:17:15] <bill-auger> (just thinking "out loud") i imagin that the buildmaster could send emails like "i compiled 'bar' successfully, and wanted to move to [extra]; but 'bar' v123 requires 'foo' v456, abd it is not yet ready"
[17:18:07] <bill-auger> which could alswer your earlier question like "how do i know what needs to move?"
[17:19:38] <bill-auger> in some casee, you would not know that at first - that knowlege base would need to be made manually and add constraints one by one as the buildmaster makes a bad move
[18:58:48] -!- socksins1 has quit [Quit: WeeChat 3.8]
[18:59:15] -!- socksinspace has quit [Remote host closed the connection]
[19:01:42] -!- socksinspace has joined #archlinux32
[19:05:39] -!- socksins1 has joined #archlinux32
[19:13:35] -!- socksinspace has quit [Remote host closed the connection]
[19:15:43] -!- socksins1 has quit [Quit: WeeChat 3.8]
[19:16:42] -!- socksinspace has joined #archlinux32
[19:17:03] -!- socksins1 has joined #archlinux32
[21:29:03] -!- phrik has quit [Read error: Connection reset by peer]
[21:30:54] -!- phrik has joined #archlinux32
[21:40:48] -!- bill-auger has quit [Ping timeout: 252 seconds]
[22:43:20] -!- bill-auger has joined #archlinux32
[23:02:36] -!- void09_ has joined #archlinux32
[23:07:28] <void09_> anywhere I can find more updated i486 isos?
[23:08:44] <KitsuWhooa> I don't think so unfortunately
[23:11:35] <void09_> :( trying to install in qemu, it fails pacstrap cause it can't write keys or something like that
[23:11:41] <void09_> read only boot medium
[23:12:47] <KitsuWhooa> is there any reason you want i486 specifically? Other than hardare
[23:12:49] <KitsuWhooa> *hardware
[23:13:04] <KitsuWhooa> you might be able to boot the normal iso and change the arch to i486 if you're doing this in qemu
[23:13:30] <void09_> i want to test if something runs on i486, and also for fun
[23:13:32] <KitsuWhooa> shouldn't have trouble booting the i686 iso in qemu even with tcg
[23:13:37] <KitsuWhooa> ah
[23:14:19] <void09_> well, i haven't installed arch manually in a decade, so not sure what i'd need to change to get 486 from 686 boot
[23:16:09] <void09_> can i just disable all keychecks in pacstrap with a cli argument I wonder
[23:17:09] <KitsuWhooa> IIRC you can just cp /etc/pacman.conf /tmp/486.conf, change the architecture there, and then when you call pacstrap you do pacstrap -C /tmp/486.conf
[23:18:50] <void09_> that makes sense. I am going to try to see if i can disable checks via some cli argument maybe first
[23:23:15] <void09_> well, didn't find, but same suggestion as your just SigLevel = Neveer