#archlinux32 | Logs for 2024-01-08
Back
[03:40:27] -!- iamzim has joined #archlinux32
[03:55:40] -!- iamzim has parted #archlinux32
[04:30:35] -!- epony has quit [Ping timeout: 264 seconds]
[04:49:00] -!- epony has joined #archlinux32
[05:54:18] -!- epony has quit [Remote host closed the connection]
[05:56:49] -!- epony has joined #archlinux32
[10:31:05] -!- drathir_tor has quit [Remote host closed the connection]
[10:31:38] -!- drathir_tor has joined #archlinux32
[17:09:33] -!- ConSiGno has joined #archlinux32
[17:10:14] <ConSiGno> I discovered how to mount a floppy after going in circles for a month- it's just "udisksctl mount -b /dev/fd0"
[17:16:50] <ConSiGno> So if I may ask, have the build issues been worked around yet? :( It's been kind of a burden building packages on my own, but I manage somehow :)
[18:32:44] <KitsuWhooa> still trying
[18:49:08] <KillerWasp> KitsuWhooa: 💪
[19:29:19] <KitsuWhooa> Why on earth does python-trove-classifiers need pip
[19:35:19] -!- drathir_tor has quit [Ping timeout: 240 seconds]
[19:38:49] <KitsuWhooa> might be time to add it to bootstrap too...
[19:40:58] -!- drathir_tor has joined #archlinux32
[19:43:15] -!- drathir_tor has quit [Remote host closed the connection]
[19:52:10] <KitsuWhooa> well, pip seems to build, but buildmaster is not prioritizing it. Ugh
[19:56:08] -!- drathir_tor has joined #archlinux32
[20:08:23] -!- ConSiGno has quit [Quit: Client closed]
[20:09:19] -!- drathir_tor has quit [Ping timeout: 240 seconds]
[20:09:58] -!- drathir_tor has joined #archlinux32
[22:31:48] <bill-auger> just FWIW, any package which has makedepends on pip, rubygems, or similar, is technically not built from source, or least is not reproducible - because whatever pip pulls in at build-time would not be accounted for in the source package - ie: it is not possible to build it offline, which is one of our requirements
[22:34:30] <bill-auger> i have successfully "de-pipped" some of them, by packaging "whatever" pip would have pulled in, or in some cases, by unpacking the entire thing and installing the files explicitly in the package() function
[22:35:15] <Foxboron> bill-auger: this isn't necessarily true
[22:35:23] <Foxboron> if not all the dependencies are present, pip will pull them inn
[22:35:40] <Foxboron> but if they are declared and available in site-packages, pip will not actually fetch them
[22:35:58] <bill-auger> that is, some of them simply use pip to download something from pip repos and install it into the $pkgdir implicitly
[22:36:27] <Foxboron> I don't doubt some do, but they are not a majority of these packages
[22:36:39] <bill-auger> yes that is what i meant - those dependencies often are not packaged though, and so not in the depends array
[22:37:10] <Foxboron> They should be and if they are not it's a bug
[22:37:46] <bill-auger> that kinda suggests then, that no package should makedepends on pip
[22:37:52] <Foxboron> Upstreams change over time so sometimes something slips through, it's why we want to turn off network during build.
[22:38:00] <Foxboron> bill-auger: Thats a generalization, and that isn't really how it works
[22:38:30] <bill-auger> we package a lot of things from the AUR too - that is where i see most of that monkey business
[22:38:59] <Foxboron> It's the AUR, you need to do QA on those packages.
[22:43:04] <bill-auger> it would be good if arch strived to do all builds with networking off, or at least attempted to do so, and reported any failures - we have discussed that often, if arch could be rebuilt from source without networking - that may uncover some unconfortable results
[22:44:06] <bill-auger> we would like to complete ports for riscv and ppc9 for example, with no upstream to rely on - that is the one factor which could be a deal-breaker
[22:44:46] <Foxboron> I don't know who "we" are in this case.
[22:44:57] <bill-auger> "we" the parabola team
[22:45:09] <Foxboron> That's not relevant for this channel, but okay.
[22:45:27] <Foxboron> and ppc9 nor risc is official so what Arch proper does is not relevant for those ports
[22:45:39] <Foxboron> is not*
[22:45:48] <Foxboron> When it comes to offline support in devtools; https://gitlab.archlinux.org
[22:45:50] <phrik> Title: Draft: PoC: build offline support (!207) · Merge requests · Arch Linux / devtools · GitLab (at gitlab.archlinux.org)
[22:58:05] <bill-auger> just saying, it would be informative - if it is not possible to build all of arch from source without networking, then we would need to hack our way around that somehow - as of now, i just dunno
[22:58:05] <bill-auger> it is relevent to me, because it would be great if i could persuade the arch upstreams to adopt this goal of making everything build reproducibly offline
[22:59:35] <Foxboron> I don't understand what "no upstream to rely on" means when you are pulling from Arch.
[22:59:39] <Foxboron> You have an upstream then
[22:59:56] <bill-auger> yes but no upstream for riscv and ppc9
[23:00:16] <Foxboron> Which means in this context?
[23:00:54] <bill-auger> i would be nice to know if it is possible to complete those ports with all offline builds, before trying
[23:01:21] <Foxboron> So "no upstream" in the parabola world just means "don't pull binary packages from Arch"?
[23:01:39] <Foxboron> s/Arch/another source/
[23:02:13] <Foxboron> Regardless of that, your largest issue is going to be bootstrapping those ports. Good luck :)
[23:02:53] <bill-auger> we duid that already - the base systems are OK so far
[23:03:51] <bill-auger> but that may not hold as things get more "GUI", "rusty", "pythonic" and such
[23:04:10] <Foxboron> bootstrapping the toolchain is the hardest part.
[23:04:23] <Foxboron> Generally though; talk is cheap. If you want to see change then contribute upstream
[23:04:56] <bill-auger> what we are discussing is not a contribution issue though - it is a policy issue
[23:05:11] <Foxboron> Is there a difference?
[23:06:03] <bill-auger> is it possible to contribute to policy changes?
[23:06:12] <Foxboron> Didn't we announce an RFC process 2 years ago?
[23:06:14] <bill-auger> cause i have some ideas :)
[23:06:49] <Foxboron> Generally, same still applies. Talk is cheap. But if nobody is willing to write down concrete plans and willing to follow through with implementing them. Then nothing gets done
[23:07:03] <Foxboron> If it's a "policy" change or an "issue" it doesn't really matter
[23:14:28] <bill-auger> i understand - involvement is important - eli often pushed me to get more involved with arch
[23:15:03] <bill-auger> eg: now that gitlab is the bug tracker, i am more likely to propose precise changes than before
[23:15:29] <Foxboron> Which is one of the reasons why we spent 2-3 years and several hundred hours on getting the git migration done :)
[23:21:46] <bill-auger> FWIW, i am interested - it is only a matter of time, and that i was unsure how open arch was to policy suggestions
[23:22:23] <bill-auger> i wrote this proposal a few years ago that i never sent - maybe i should https://lists.parabola.nu
[23:22:24] <phrik> Title: [Dev] Update on the PKGBUILDs license (at lists.parabola.nu)