2025-11-01 02:05:31 <anjan> Hi, can someone review: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/91543
2025-11-01 05:37:11 <craftyguy[m]> sertonix: for ruff on 64K page systems... any reason why we just don't build it with JEMALLOC_SYS_WITH_LG_PAGE=16 so the vendored jemalloc works?
2025-11-01 10:43:43 <f_> omni: are you around for a little bit? I'd like to take over meli maintainership, is that ok to you?
2025-11-01 10:44:29 <f_> the package is a little bit out of date and seeing that you're busy on so many other things at the same time I think that would be less work for you
2025-11-01 10:44:53 <f_> (and I also need a reason to maintain packages in alpine, lol)
2025-11-01 10:56:45 <achill> fwiw there is !91726
2025-11-01 10:57:18 <f_> oh, cool, but I still want to takeover if that's ok
2025-11-01 11:06:43 <omni> no
2025-11-01 11:09:48 <f_> omni: then I still want to help out
2025-11-01 11:10:06 <f_> if I can help out in any way
2025-11-01 11:23:02 <f_> so if there's anything I can do to help feel free to let me know
2025-11-01 11:23:40 <f_> (rereading my messages, I guess it might've seemed a bit harsh, I didn't mean it to be)
2025-11-01 11:34:59 <omni> the only thing that is out-of-date is the version number, functionally it is up-to-date with the latest release
2025-11-01 11:40:45 <f_> oh, right
2025-11-01 11:41:02 <f_> I think there should be a new release coming soon™ also
2025-11-01 12:12:24 <raspbeguy> Hello, can someone merge those MRs please? !87884 !90941 !91118 !91337 !91546
2025-11-01 12:37:52 <Sertonix[m]> craftyguy: All advantages of devendoring apply: patch without rebuilding everything and duplicating the patches, avoid wasting cpu-cycles while compiling, pobably reduce size, faster security upgrades
2025-11-01 12:40:55 <Sertonix[m]> So I would question if there is any good reason to use the vendored jemalloc
2025-11-01 12:45:43 <omni> and rather give it the same treatment as fd just got !92264
2025-11-01 16:05:45 <WhyNotHugo> I have a list of 130 packages that need to be built, and need to do a topological sort on the dependency graph. Do we have any tool that does this already?
2025-11-01 16:05:51 <WhyNotHugo> I'm using APKBUILD as source here, not built apk
2025-11-01 16:23:40 <craftyguy[m]> sertonix: because it's literally a 1 line change in the apkbuild to fix that bug if we keep using the vendored jemalloc :P
2025-11-01 16:24:40 <craftyguy[m]> by de-vendoring don't we risk introducing possible bugs where maybe the app is incompatible somehow with a newer version we package?
2025-11-01 16:27:16 <achill> WhyNotHugo: lua-aports has some scrips that generate a package list
2025-11-01 16:27:51 <achill> https://gitlab.alpinelinux.org/alpine/lua-aports/-/blob/master/bin/ap.lua?ref_type=heads#L63
2025-11-01 16:28:59 <WhyNotHugo> achill: thansk!
2025-11-01 16:37:11 <WhyNotHugo> lua-aports only works intra-repository, but can't find dependants in community for a package in main?
2025-11-01 16:54:34 <WhyNotHugo> Passing multiple `-d` flags to `ap` handles them separately, so won't find cross-repo dependencies. I take it that patching this should not break any usage scenario?
2025-11-01 17:09:04 <WhyNotHugo> Fixed it: https://gitlab.alpinelinux.org/alpine/lua-aports/-/merge_requests/19
2025-11-01 17:14:32 <WhyNotHugo> Here I was writing lots of horrible code when  `ap recursive-revdeps python3 | xargs ap builddirs`  does exactly what I needed!
2025-11-01 22:14:45 <Ariadne> Sertonix[m]: we can't ship fd with musl malloc-ng, it aggressively does multithread scatter-gather work, which basically kills malloc performance
2025-11-01 22:15:21 <Ariadne> 
ACTION does not care if we ship vendored jemalloc or unvendored jemalloc, but simply changing to musl malloc isn't going to yield acceptable performance

2025-11-01 22:16:56 <Sertonix[m]> It's already using unvendored jemalloc
2025-11-01 22:17:10 <Ariadne> oh sorry, i thought we were talking about fd, not ruff
2025-11-01 22:17:23 <Ariadne> regardless, switching to musl malloc is almost always a mistake with rust programs
2025-11-01 23:38:40 <tokyovigilante> hi, I've just updated the Nim package to 2.2.6, would appreciate a review - https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/76837
2025-11-03 00:39:56 <angeloverlain[m]> would be nice to have another set of eyes on https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/206. maybe ncopa 👀
2025-11-03 07:35:34 <prabu> thanks ikke for merging !90460
2025-11-03 14:55:09 <WhyNotHugo> angeloverlain[m]: can we potentially move regular LUKS into hooks too?
2025-11-03 19:39:31 <realroot[m]> is it already possible to use unl0kr? I guess that it's better wait for mkinitfs hooks MR though
2025-11-03 21:46:01 <WhyNotHugo> Sertonix[m]: have you considered inserting the LUKS password into the kernel keyring and then using cryptsetup with --volume-key-keyring ?
2025-11-03 21:56:29 <Sertonix[m]> I haven't but I also didn't have the time to work on a (in my opinion) good mkinitfs flexibility improvment. Big question would be if it can supersede all previous methoda. If it can that would be great. But without looking into the details I doubt one can implement a good retry functionality with it.
2025-11-03 21:59:26 <angeloverlain[m]> WhyNotHugo: yes. we can potentially move that and even LVM into hooks 
2025-11-03 21:59:56 <angeloverlain[m]> <realroot[m]> "is it already possible to use..." <- I don’t think it’s currently possible 
2025-11-03 22:00:59 <WhyNotHugo> Retrying is the tricky part, because it needs to re-exec the prompter.
2025-11-03 22:02:00 <Sertonix[m]> angeloverlain[m]: It is. You can use the (arguably not very good) CRYPTKEY=EXEC= or overwrite the init script which is a documented mkinitfs option.
2025-11-03 22:03:19 <Sertonix[m]> WhyNotHugo: The tricky part is that it depends on the promper whether or not it should be re-executed or signaled to a still running process (eg. unl0kr).
2025-11-03 22:07:23 <angeloverlain[m]> <Sertonix[m]> "It is. You can use the (arguably..." <- ohh nice. I forget about that. the nice thing with hooks is that you can have TPM automatically try to unlock the disk, and when that fails, you can then launch unl0kr to try decrypt it. not sure if that’s currently possible unless you write a script 
2025-11-03 22:08:22 <angeloverlain[m]> but yeah hooks might also allow the initramfs to be more modular (the file systems still want to be in nlplug-findfs tho for now).
2025-11-03 22:08:51 <angeloverlain[m]> the most exciting use case for me is actually having plymouth
2025-11-03 22:12:15 <Sertonix[m]> angeloverlain[m]: That's very much a use case for setting init= in /etc/mkinitfs/mkinitfs.conf instead.
2025-11-03 22:14:36 <WhyNotHugo> Sertonix[m]: you're suggesting different providers for initramfs-init?
2025-11-03 22:25:57 <angeloverlain[m]> <Sertonix[m]> "That's very much a use case..." <- can you expand on that ?
2025-11-03 22:28:04 <Sertonix[m]> WhyNotHugo: Not really. I think that power users are better off overwrite that file and for everything else mkinitfs!206 is a footgun.
2025-11-03 22:29:32 <Sertonix[m]> algibot: Not quite
2025-11-03 22:30:06 <angeloverlain[m]> Sertonix[m]: how does that work when you set init= ?
2025-11-03 22:30:30 <angeloverlain[m]> this is how arch’s plymouth hook looks like btw https://gitlab.archlinux.org/archlinux/packaging/packages/plymouth/-/blob/12df42855251af1d5f6e380968d3e2b51600c14d/plymouth.initcpio_hook
2025-11-03 22:30:48 <angeloverlain[m]> it’s just running a daemon while in the initramfs
2025-11-03 22:31:18 <WhyNotHugo> Sertonix[m]: mkinitfs!206 has 5 hooks for 2½ use cases. I'm not convinced by it.
2025-11-03 22:31:58 <angeloverlain[m]> WhyNotHugo: what do you mean ?
2025-11-03 22:33:03 <WhyNotHugo> angeloverlain[m]: is there a use case for the 'early' hook, or is it "just in case we need it"?
2025-11-03 22:33:16 <Sertonix[m]> <angeloverlain[m]> "can you expand on that ?" <- I think you can do `cp /usr/share/mkinitfs/initramfs-init /etc/mkinitfs/init && echo init=/etc/mkinitfs/init >> /etx/mkinitfs/mkinitfs.conf && $EDITOR /etc/mkinitfs/init` and edit the script to whatever you want
2025-11-03 22:36:09 <Sertonix[m]> I also feel like and good hook implementarion would make stull like clevis useless due to everything that clevis can do being better integrated when interacting with the components that clevis is using directly.
2025-11-03 22:38:40 <angeloverlain[m]> WhyNotHugo: the early hook might probably be used to support additional filesystems, but not sure it’s in scope right now (delegated to nlplug)
2025-11-03 22:41:11 <Sertonix[m]> WhyNotHugo: If you have any other ideas the best place would probably be https://gitlab.alpinelinux.org/alpine/aports/-/issues/17603 cause it involves making mkinitfs easier to use safely.
2025-11-03 22:41:17 <angeloverlain[m]> <Sertonix[m]> "I think you can do `cp /usr/..." <- the only issue with this approach is that of course, as updates go on, you will need to resync /usr init with your duplicated /init in /etc. 
2025-11-03 22:41:17 <angeloverlain[m]> and of course, I’m thinking about upstreaming everything here. If you make a copy of the init, only you will benefit from the changes, while when hooks are supported, users can create, install and use hooks that add several new functionality (additively)
2025-11-03 22:42:42 <angeloverlain[m]> Sertonix[m]: I think making mkinitfs less of a monolith is probably the best first step, but I know we will probably disagree on this
2025-11-03 22:42:49 <Sertonix[m]> As I said, power users don't benefit from upstreaming, for everything else it's a footgun.
2025-11-03 22:44:49 <angeloverlain[m]> Sertonix[m]: how is having TPM disk encryption, a nice boot menu and a TPM input on touchscreens for power users? I fail to understand the logic used here.
2025-11-03 22:44:49 <angeloverlain[m]> most general purpose distros have this (e.g. fedora, ubuntu, even pmOS). not sure why alpine should be stuck 2 decades ago 😅
2025-11-03 22:45:23 <angeloverlain[m]> I also think TPM attestation is used severely on server infra on boot
2025-11-03 22:46:12 <angeloverlain[m]> anyway, to cut this short, If you think mkinitfs!206 is not the right approach, I can stop working on it to save some time and effort
2025-11-03 22:46:22 <Sertonix[m]> angeloverlain[m]: Less monolithic sure but exposing API which we will ether need to break in the near future or be unable to improve mkinitfs further (due to design limitations) is not really a path forward in my opinion
2025-11-03 22:48:18 <angeloverlain[m]> Sertonix[m]: what are the design limitations? and why need we break the API « soon » ?
2025-11-03 22:50:01 <Sertonix[m]> angeloverlain[m]: That's the footgun. Interacting with a TPM in a way that is's actually useful is **very** difficult (and depending on the hardware and who you ask impossible). Tempting users with doing DIY crpto for their disk encryption setup will in 99% of the cases end in very weak to no security. That can't be a good fit for alpine
2025-11-03 22:51:42 <Sertonix[m]> (Implying that the way the hooks are implemented encourages (bad) DIY solutions more that a more stricter API which tries to make safe usage easier than unsafe one)
2025-11-03 22:54:25 <angeloverlain[m]> Sertonix[m]: no it’s not…? this is all you need to encrypt your disk with TPM: clevis luks bind -d /dev/tpm2 '{"pcr_ids":"1,7"}'. this ensures that your disk will automatically be decrypted on boot as long as secure boot is on and the UEFI settings haven’t changed. this has been a thing on most other OSes for atleast a decade too, so it’s not something new…
2025-11-03 22:54:25 <angeloverlain[m]> anyway, I gave atleast 2 other examples, and I’m very sure that configuring TPM is not the hardest thing one can do in alpine 
2025-11-03 22:56:51 <angeloverlain[m]> <Sertonix[m]> "(Implying that the way the hooks..." <- the alternative you gave is an even more bad DIY solution (imo), while with hooks available, one would need to (1) apk add clevis-tpm2-hook (or similar) (2) add clevis-tpm2 to mkinitfs features (3) bind their disk to clevis
2025-11-03 22:57:41 <angeloverlain[m]> anyway I think there’s a lot of bikeshedding here, so I’ll be pulling away my MR. thanks
2025-11-03 22:57:46 <angeloverlain[m]> im done
2025-11-03 23:00:11 <Sertonix[m]> Did you check if the hardware uses an easy to MITM external TPM chip? Did you inform the user about the fact that an untrusted booting operating system can look 100% the same as one that has been verified by secure boot? That's stuff I hope to tackle some day in #17603 but it's unfortunatly a minefield of footguns
2025-11-04 07:19:16 <fcolista> morning all
2025-11-04 08:49:07 <lassebq> gm
2025-11-04 16:01:39 <raspbeguy> Hello, can someone merge those MRs please? !87884 !90941 !91118 !91337 !91546
2025-11-04 17:55:14 <Ariadne> personally, i would rather replace mkinitfs than grow it further
2025-11-04 19:22:20 <Sertonix[m]> I was considering a rewrite. But yes, growing the current code may may not be a good way forward.
2025-11-04 20:30:49 <Ariadne> software in general has a lifecycle, and a lot of alpine components are basically reaching the end of their useful life
2025-11-04 20:31:13 <Ariadne> where alpine is today is very different from where alpine was when alpine-conf, mkinitfs and even abuild were created
2025-11-04 20:32:11 <Ariadne> this isn't to say that we haven't gotten meaningful use out of these packages, but rather that it is probably worth taking a step back and examining whether we should be replacing these components rather than growing them further
2025-11-04 21:40:39 <Sertonix[m]> lua-aports would be on my priority for being replaced or made redundant. I try to ignore the existance of alpine-conf but personal preference is the main reason for that.
2025-11-04 21:50:48 <Ariadne> i agree, we should build something better in go
2025-11-04 21:50:55 <Ariadne> especially buildrepo keeps me up at night
2025-11-04 21:57:30 <angeloverlain[m]> very interested to have this discussion. I think the folks at pmOS have a rewrite of mkinitfs in go (without the /init). maybe that can be considered ? not sure what to do about alpine-conf and abuild though
2025-11-04 21:57:31 <angeloverlain[m]> the only frustration I have is that alpine projects seem to be very slow-moving
2025-11-04 21:58:16 <Ariadne> alpine will always move slower than pmOS.  that is why it is important that both projects exist and maintain distinct identities.
2025-11-04 21:59:05 <Ariadne> the risk calculus is wildly different for both projects.
2025-11-04 22:00:39 <craftyguy[m]> yeah we use a differnet mkinitfs, you give it lists of stuff (modules, files, hooks, whatever) to compose an initramfs. we package the actual init script separately
2025-11-04 22:01:04 <Ariadne> at present a breaking change to pmOS is at most an inconvenience for most people using pmOS
2025-11-04 22:01:41 <craftyguy[m]> (I'm not advocating you use our mkinitfs, use whatever makes sense for Alpine :D)
2025-11-04 22:01:45 <Ariadne> so, if it happens, we pursue a fix as quickly as possible, and it's not a big deal
2025-11-04 22:03:42 <craftyguy[m]> our mkinitfs is basically just a fancy cpio/archive generator, that can resolve+include dependencies for given binaries and kernel modules, and write paths to given things to put them elsewhere in the archive
2025-11-04 22:04:48 <Ariadne> but alpine is a different story.  large swaths of the modern world run on alpine.  so we have to be very careful and thoughtful about how we evolve the system over time.
2025-11-04 22:04:51 <craftyguy[m]> you have to bring your own init though
2025-11-04 22:07:48 <Ariadne> i think we could switch to the pmOS mkinitfs upstream
2025-11-04 22:08:01 <Ariadne> obviously not right now, but in the next iteration
2025-11-04 22:08:48 <Ariadne> my point is simply that alpine moves slowly because it is necessary
2025-11-04 22:09:10 <WhyNotHugo> Sertonix[m]: what's the big issue with lua-aports? 
2025-11-04 22:09:39 <WhyNotHugo> What are general thoughts on running init from the initfs, so that mounting and early services all fall within the same architecture?
2025-11-04 22:09:47 <Ariadne> WhyNotHugo: iteration of the "aports database" is not stable
2025-11-04 22:10:32 <Ariadne> it is why if there is a build failure you can sometimes ask the builders to retry and it will go down a different chain of dependencies instead of the failed package
2025-11-04 22:11:18 <Ariadne> it also spawns a shell process for every APKBUILD it processes
2025-11-04 22:13:50 <WhyNotHugo> I noticed today that determining the build order was not quite right (for the py3.14 rebuild), and it would sometimes list a package before one of its dependencies.
2025-11-04 22:14:08 <invoked> what problems are being solved in alpine mkinitfs & other compnonents (beyond vague technical debt) that makes it worthwhile? that's unclear to me
2025-11-04 22:15:09 <WhyNotHugo> invoked: missing features include being able to use unl0ckr, having multiple partitions with the same LUKS passphrase
2025-11-04 22:15:30 <WhyNotHugo> TBF, we ought to have a distinction between mkinitfs and mkinitfs-init, the latter is currently replaceble.
2025-11-04 22:15:35 <Ariadne> kmscon for unicode terminal
2025-11-04 22:15:48 <invoked> alright
2025-11-04 22:16:25 <WhyNotHugo> kmscon? Just put a compositor in there with a LUKS prompter. Later re-use the compositor for greeters.
2025-11-04 22:16:47 <Ariadne> for a text-only session ?
2025-11-04 22:17:09 <craftyguy[m]> yeah the actual init implements support for runtime stuff on boot. mkinitfs is just a tool to make an archive you can use as the initramfs (which should include an init in it). at least that's how we treat them in pmOS, mkinitfs and the init it bundles are separate things
2025-11-04 22:22:04 <invoked> i also suppose stuff like dracut was ruled out for good reasons
2025-11-04 22:22:23 <Ariadne> dracut i believe depends on systemd these days and starts systemd in initramfs
2025-11-04 22:22:50 <invoked> mm, aye that would be a good reason
2025-11-04 22:23:01 <craftyguy[m]> dracut is also slooow
2025-11-04 22:24:10 <WhyNotHugo> dracut is quite far from "simple".
2025-11-04 22:24:15 <WhyNotHugo> It depends on systemd now?
2025-11-04 22:24:31 <Ariadne> at least on my fedora system, it starts systemd in the initramfs
2025-11-04 22:24:35 <Ariadne> soooo
2025-11-04 22:27:12 <WhyNotHugo> IMHO, starting an init in the initfs is not a bad idea. you want a few service up, so why not have the service supervisor?
2025-11-04 22:27:34 <Ariadne> i did not say that it was a bad idea.  i said it was not a good fit *for alpine*
2025-11-04 22:28:35 <Ariadne> because, like it or not, alpine itself is not going to switch from openrc to systemd
2025-11-04 22:29:11 <Ariadne> maybe there will be systemd derivatives of alpine in the future (like pmOS is experimenting with today), but these would be distinct derivatives and not alpine itself
2025-11-04 22:30:00 <WhyNotHugo> Totally on the same page
2025-11-04 22:32:21 <abby> dracut doesn't *require* on systemd
2025-11-04 22:32:41 <abby> it's the default on void, works fine without it
2025-11-04 22:32:57 <Sertonix[m]> Ariadne: Everything except for go please.
2025-11-04 22:33:14 <Ariadne> ok, great, but dracut would have to be modified to support alpine features like run-from-ram
2025-11-04 22:34:17 <Ariadne> my advice to anyone wanting to pursue dracut is -- show us an ISO that runs from ram and uses dracut as initramfs
2025-11-04 22:34:28 <abby> void has one?
2025-11-04 22:34:36 <Ariadne> not like alpine runs from ram
2025-11-04 22:35:05 <Ariadne> on alpine, we compose a tmpfs using apk and then pivot into it
2025-11-04 22:35:10 <abby> •If rd.live.ram=1 is used in this situation, the full, uncompressed root filesystem is copied during boot to /run/initramfs/rootfs.img in the /run tmpfs.
2025-11-04 22:35:26 <Ariadne> that isn't the same thing as alpine's run from ram
2025-11-04 22:35:34 <pj> go is in community, rust is in main :>
2025-11-04 22:35:54 <Sertonix[m]> WhyNotHugo: lua-aports tends to be out of sync, slow and badly documented. I am already working on something which will completely replace it for me at least with also scans everything for recursive dependencies.
2025-11-04 22:37:52 <Ariadne> alpine's initramfs builds a tmpfs based on either default configuration or user-supplied configuration in an "overlay file"
2025-11-04 22:38:07 <Ariadne> the overlay file is a tar which contains configuration data like /etc/apk/world
2025-11-04 22:38:38 <Sertonix[m]> Not really a fan of rust ether but I would take ot over go. But in my opinion the programming language should be chosen to fit the requirments but we haven't agreed on requirements of a potential mkinitfs replacement/rewrite yet.
2025-11-04 22:39:08 <Ariadne> the reason i suggested go for lua-aports is because there are already go libraries for dealing with aports
2025-11-04 22:41:34 <Ariadne> but i am not convinced you can actually iterate aports "fast"
2025-11-04 22:41:39 <Sertonix[m]> Ariadne: Regardless of what others do I will sooner or (more likely) later finish and publish my project which is currently shell+awk (and targets simple+fast)
2025-11-04 22:41:51 <Ariadne> we have some APKBUILDs which do nasty stuff
2025-11-04 22:42:34 <Ariadne> like to determine what outputs a given APKBUILD will generate, you have to evaluate it
2025-11-04 22:42:39 <Sertonix[m]> Do you consider 1.9s for all edge aports including building a dependency graph in awk and running a recursion check as fast enough :)
2025-11-04 22:43:02 <Ariadne> i think that is a significant improvement given the current situation, sure
2025-11-04 22:43:41 <Ariadne> but if we did not have to physically evaluate APKBUILDs to learn their outputs, it could be even faster
2025-11-04 22:44:11 <Ariadne> because you have stuff like [ "$CARCH" = "foo" ] && subpackages="$subpackages bar"
2025-11-04 22:47:23 <Sertonix[m]> You have do do that for each target, fair. I have considered parsing APKBUILDs differently but it would make stuff like community/libreoffice ether difficult to parse or make the APKBUILD more complex
2025-11-04 22:47:34 <Sertonix[m]> *to do
2025-11-04 22:48:33 <Ariadne> i think the solution is to use structured data for package metadata section, like melange
2025-11-04 22:48:54 <Ariadne> so you could have, say
2025-11-04 22:49:39 <Ariadne> subpackages: [{"bar": {"architectures": ["all", "!riscv64"]}]
2025-11-04 22:50:14 <Ariadne> the problem is that the metadata can change as a side effect of shell evaluation
2025-11-04 22:52:24 <Sertonix[m]> Regarding the "init system" in initramfs discussion above: I feel like most service manager complexity is created by needing to connect inconsistent interfaces. By requring hooks/services/whatever to adhere to a strict (and simple to implement) interface we can probably avoid the need for any full blown service managmentm
2025-11-04 22:52:46 <Ariadne> agreed
2025-11-04 22:54:59 <skarnet> I still don't get why anyone would need a service manager in initramfs. It's not supposed to be a permanent system. It's not supposed to be so complex that you cannot remember what daemons you have launched and cannot kill them before execing the real init.
2025-11-04 22:55:30 <skarnet> sure, there might be a lot of work to do in the initramfs, but isn't most of it short-lived, like, forking normal processes and waiting for them?
2025-11-04 22:57:56 <Sertonix[m]> Regarding APKBUILD metadata: So far my conclusion has always been "too complicated/breaking for too little advantages". I am sometimes simplifying APKBUILDs in a way which may make them easier to statically analyze. Trying to do that for all APKBUILDs would require abuild to grow a lot of (probably package specific) features and would therefor probably make it a lot less feasable for software independent of abuild to parse APBUILDs
2025-11-04 22:57:56 <Sertonix[m]> correctly.
2025-11-04 22:58:03 <Ariadne> Sertonix[m]: re: community/libreoffice, something like https://github.com/wolfi-dev/os/blob/main/glibc.yaml#L569 might be a solution
2025-11-04 22:59:53 <WhyNotHugo> skarnet: right now we run mdev in the initramfs and them mdevd/eudev after the root_pivot. You could run just one.
2025-11-04 23:00:00 <Sertonix[m]> skarnet: Maybe service manager is a bad comparison. It's more like ninja build for mounting filesystems
2025-11-04 23:00:17 <WhyNotHugo> It's a short-lived service which is later replaced by another long-lived service which does the same
2025-11-04 23:00:26 <skarnet> yeah and it's a good thing
2025-11-04 23:00:47 <Sertonix[m]> WhyNotHugo: I think mdev is used in a one shot style
2025-11-04 23:01:10 <Sertonix[m]> Bit I would need to check the source for that
2025-11-04 23:01:15 <skarnet> daemons don't run in the same context in an initramfs and in the final system, it's good that nothing leaks from the initramfs
2025-11-04 23:01:36 <skarnet> kill the extra stuff before execing into init and run the real daemon later, it's fine
2025-11-04 23:01:41 <skarnet> don't try to optimize on that
2025-11-04 23:01:54 <Ariadne> notably, the initramfs might have older dependencies that haven't received security fixes
2025-11-04 23:02:02 <skarnet> that too
2025-11-04 23:02:02 <WhyNotHugo> Sertonix[m]: yeah, mdev is only run until the root fs is found. My point is that starting mdevd at that point would simplify things
2025-11-04 23:02:12 <Sertonix[m]> To be more percise: suspend to RAM requires initramfs and others to be independant
2025-11-04 23:02:13 <Ariadne> so we don't want those processes sticking around for that reason amongst others
2025-11-04 23:02:33 <WhyNotHugo> Ariadne: shouldn't you update the initramfs if there have been security updates?
2025-11-04 23:02:44 <Ariadne> yes, but there is not a mechanism right now to enforce that
2025-11-04 23:04:31 <Ariadne> such a mechanism wouldn't be hard to build, mind
2025-11-04 23:05:09 <Ariadne> but right now, mkinitfs only runs to regenerate the initramfs if a kernel update happens
2025-11-04 23:05:34 <Ariadne> if you upgrade busybox, to patch a CVE for example, the initramfs won't be regenerated automatically
2025-11-04 23:05:39 <Sertonix[m]> Probably by converting the trigger to something that always runs
2025-11-04 23:06:01 <WhyNotHugo> Allowing other packages to trigger a rebuild is also a missing feature.
2025-11-04 23:06:12 <Ariadne> yes, *but* we only want to actually run if there is a reason to
2025-11-04 23:06:23 <Ariadne> otherwise, rebuilding mkinitfs every time is just slow for no reason :p
2025-11-04 23:06:30 <WhyNotHugo> pmOS's mkinitfs does support this, by having each package place a file with its version in a directory which triggers a rebuild.
2025-11-04 23:06:35 <WhyNotHugo> Not sure if elegant or hacky or both.
2025-11-04 23:06:59 <Ariadne> i would say hacky
2025-11-04 23:07:16 <Sertonix[m]> Ether hash or timestamp the input and config files may be enough
2025-11-04 23:07:54 <Ariadne> yeah the solution is to put a manifest file in the initramfs, like /.manifest or such
2025-11-04 23:08:07 <Ariadne> which lists the hashes of the files in the initramfs
2025-11-04 23:08:11 <Sertonix[m]> Would be an expensive way to check though
2025-11-04 23:08:51 <Ariadne> if you arrange for the manifest to be the first block of the cpio, it probably wouldn't be that bad
2025-11-04 23:09:09 <Ariadne> because we can stop parsing the initramfs cpio once we have the manifest
2025-11-04 23:10:15 <Sertonix[m]> I mean probing all files on the host fs including checking if any glob pattern evaluates differently now
2025-11-04 23:10:25 <Sheila> maybe it could store mtimes too, and trigger a fuller scan if mtimes change?
2025-11-04 23:10:26 <Ariadne> if we have a way of telling mkinitfs what files changed in the last apk transaction, it could be even faster :)
2025-11-04 23:10:57 <iggy> reading through all that... one thing I'll say for the go bindings... they are _not_ fast
2025-11-04 23:12:32 <Ariadne> they are not, because the bottleneck is having to evaluate the APKBUILD as a shell script
2025-11-04 23:12:42 <Ariadne> this is going to be a problem in any language
2025-11-04 23:13:19 <WhyNotHugo> At least in go you can trivially do this concurrently.
2025-11-04 23:13:33 <Sertonix[m]> Ariadne: I have been thing of potentially special commit hooks getting null terminated paths from stdin. But unfortunatly commit hooks don't have a file ending to reliably destinguish such a new type
2025-11-04 23:13:35 <Ariadne> and put the system under heavy PID pressure
2025-11-04 23:13:53 <WhyNotHugo> Just use a semaphor with max 12 goroutines
2025-11-04 23:14:33 <Ariadne> my experiences working with go engineers is that they just send it
2025-11-04 23:14:36 <Ariadne> :p
2025-11-04 23:14:55 <Ariadne> 100GB image in ram?  why not, google servers have TBs of RAM
2025-11-04 23:16:47 <Ariadne> anyway, lots of lessons we can learn from melange re: build recipe metadata
2025-11-04 23:17:51 <Ariadne> but i think that moving to structured metadata in aports is a tall ask, since there's tens of thousands of APKBUILDs that would have be converted
2025-11-04 23:20:07 <WhyNotHugo> Looking at https://github.com/chainguard-dev/melange, I can't say that I understand the examples in the README
2025-11-04 23:22:56 <Ariadne> what is not understandable about them?  you have a pipeline, the pipeline does stuff
2025-11-04 23:23:07 <Ariadne> at the end, you have build output, which becomes APK
2025-11-04 23:23:39 <craftyguy[m]> WhyNotHugo: ya what we do to trigger rebuilds is hacky. but our mkinitfs is fast. like really fast. often <1 second (longer time is usually from the deploy script that it calls to install things to slow boot storage)
2025-11-04 23:25:36 <WhyNotHugo> Ariadne: The script format uses "uses: autoconf/make-install". Is this a bespoke scripting language which calls `autoconfig && make install`?
2025-11-04 23:25:58 <Ariadne> not a scripting language per se
2025-11-04 23:26:00 <WhyNotHugo> The syntax of this is not at all obvious from the README
2025-11-04 23:26:25 <Ariadne> melange pipelines are an AST
2025-11-04 23:26:45 <Ariadne> `runs` refers to a block of shell script, `uses` refers to an external pipeline
2025-11-04 23:27:14 <Ariadne> my point, incidentally, has nothing to do with using melange, but rather melange's *structured metadata* would be useful for aports
2025-11-04 23:27:47 <Ariadne> but anyway, `uses: autoconf/make-install` means "use the autoconf/make-install pipeline"
2025-11-04 23:28:12 <WhyNotHugo> I think APKBUILD files are extremely simple to read. The first time I saw one it waas clear how it worked.
2025-11-04 23:28:24 <Ariadne> ok?
2025-11-04 23:28:30 <WhyNotHugo> I have no idea what an "external pipeline" is in this context.
2025-11-04 23:28:34 <pj> I think they are absolutely terrible to read
2025-11-04 23:28:53 <Ariadne> again, i am not proposing we switch aports to melange
2025-11-04 23:28:56 <pj> lots of internal functions that do "things"
2025-11-04 23:29:26 <skarnet> pj: any package building system is going to have lots of internal functions that do things
2025-11-04 23:29:33 <skarnet> this is not imputable to APKBUILD
2025-11-04 23:29:56 <skarnet> the functionality is inherently complex
2025-11-04 23:30:04 <WhyNotHugo> Ariadne: what kind of structured metadata format do you have in mind?
2025-11-04 23:30:14 <invoked> any change should be intuitive, not a step towards yocto-ification
2025-11-04 23:30:42 <Ariadne> that also has not been proposed
2025-11-04 23:30:46 <skarnet> invoked: what happened with yocto?
2025-11-04 23:31:17 <invoked> skarnet: nothing
2025-11-04 23:32:30 <Ariadne> WhyNotHugo: the metadata format from melange, where PACKAGE METADATA is static
2025-11-04 23:32:49 <Ariadne> this is NOT proposing using melange itself, melange pipelines, or anything other than the metadata part
2025-11-04 23:33:34 <Ariadne> the largest problem with APKBUILD is that to determine anything about an APKBUILD, you must evaluate it as a shell script
2025-11-04 23:33:42 <Ariadne> i am proposing solving THAT problem and THAT problem ALONE
2025-11-04 23:33:49 <ikke> Ariadne: you have been mentioning cue in the past, do you still think that would be a good format?
2025-11-04 23:34:10 <Ariadne> i think cue has run out of gas, sadly
2025-11-04 23:34:14 <Sertonix[m]> melange is essentially equivalent to symbolic execution of current APKBUILDs
2025-11-04 23:34:22 <ikke> Too sad
2025-11-04 23:34:23 <Ariadne> yes
2025-11-04 23:34:56 <pj> people like KDL now
2025-11-04 23:35:15 <ikke> https://kdl.dev/?
2025-11-04 23:35:52 <Ariadne> the point is that evaluating an APKBUILD (and having side effects from doing so, which means you must use a subshell to do this safely) to learn what architectures and subpackages it generates is the performance bottleneck
2025-11-04 23:36:20 <Ariadne> so the idea is you would have
2025-11-04 23:36:33 <pj> or whatever was the apple config format
2025-11-04 23:36:37 <Ariadne> package.name: whatever
2025-11-04 23:36:38 <Ariadne> [...]
2025-11-04 23:36:39 <Ariadne> ---
2025-11-04 23:36:47 <Ariadne> prepare() { default_prepare }
2025-11-04 23:36:49 <Ariadne> [...]
2025-11-04 23:36:53 <ikke> separate metadata from build instructions
2025-11-04 23:37:02 <invoked> pj: plist
2025-11-04 23:37:10 <ikke> But like you said, there are APKBUILDs which do some dynamic stuff
2025-11-04 23:37:17 <pj> invoked: no, that's just xml
2025-11-04 23:37:19 <Ariadne> yes, i am saying this is Bad Actually
2025-11-04 23:37:29 <WhyNotHugo> If you design a static metadata format, you need to contemplate all the weird cases which are currently scripted. Value can be overriden per-architecture, and any field can use as variables some other field.
2025-11-04 23:37:55 <Ariadne> thank you for explaining operating system design to me
2025-11-04 23:38:00 <WhyNotHugo> Anytime!
2025-11-04 23:38:01 <skarnet> I understand the safety+security problems with having to interpret APKBUILDS with a shell, but is *performance* really a concern?
2025-11-04 23:38:05 <pj> https://github.com/apple/pkl
2025-11-04 23:38:23 <skarnet> is it slow to the point it is impacting builds?
2025-11-04 23:38:37 <Ariadne> yes, it is
2025-11-04 23:38:50 <invoked> pj: oh right "pickle"
2025-11-04 23:38:57 <Sertonix[m]> skarnet: Not using a subshell is kind of UB and usinf subshells for each APLBUILD is slow
2025-11-04 23:39:25 <skarnet> yeah the fact that you have to use a subshell is probably terrible for performance
2025-11-04 23:39:28 <WhyNotHugo> My point is that you can't just pick up the existing fields and make them static, the format needs to contemplate *all* cases.
2025-11-04 23:39:38 <WhyNotHugo> skarnet: findign all pacakges which depend on python3-dev takes 3s on my laptop
2025-11-04 23:39:44 <Sertonix[m]> It's 12000 subshells as far as I remember
2025-11-04 23:40:28 <Ariadne> WhyNotHugo: my point is that (1) i already know this, and (2) it's not helpful to the discussion, but rather is a form of "stop energy"
2025-11-04 23:40:30 <Sertonix[m]> WhyNotHugo: only checking the main repo?
2025-11-04 23:40:48 <WhyNotHugo> Sertonix[m]: only checking main
2025-11-04 23:41:07 <skarnet> I thought abuild built a global dependency tree once and that's what it checked afterwards
2025-11-04 23:41:15 <skarnet> the initial reading has to be slow, yes
2025-11-04 23:41:22 <Ariadne> abuild has no understanding of dependencies
2025-11-04 23:41:28 <skarnet> hm
2025-11-04 23:41:31 <Ariadne> at least not in that way
2025-11-04 23:41:34 <ikke> lua-aports is doing that
2025-11-04 23:41:46 <Ariadne> (obviously it knows what dependencies need to be installed)
2025-11-04 23:42:43 <Sertonix[m]> *lua-aports can't analyze subpackage dependencies
2025-11-04 23:42:53 <WhyNotHugo> that explains a lot
2025-11-04 23:43:11 <Ariadne> Sertonix[m]: yes, which is why the build order is sometimes wrong
2025-11-04 23:43:15 <ikke> correct, because you would need to execute functions
2025-11-04 23:45:05 <WhyNotHugo> Can we generalise depends_dev and depends_doc to depends_$subpkg?
2025-11-04 23:45:29 <Ariadne> sure, but if we are going to do that, we might as well just do metadata right to begin with
2025-11-04 23:45:39 <Ariadne> it's not that much more of a lift
2025-11-04 23:45:46 <Sertonix[m]> WhyNotHugo: Yes but no. It needs eval and I try to remove it im abuild
2025-11-04 23:47:37 <Sertonix[m]> And some dependencies are only every known post-build which means that this issue will always percist in some way even with a different format
2025-11-04 23:47:49 <ikke> Sertonix[m]: any example of that?
2025-11-04 23:48:10 <WhyNotHugo> Are you talkign about soname tracing?
2025-11-04 23:48:18 <WhyNotHugo> We know the -dev dependency in that case, which is enough to determine build order.
2025-11-04 23:48:20 <ikke> Or do you mean like automatically detected so depetendencies?
2025-11-04 23:48:21 <Ariadne> Sertonix[m]: outside of so:[...] and py:[...] dependencies, which don't matter for determining the build order, what is there?
2025-11-04 23:49:24 <Sertonix[m]> If a package includes a .pc files it will have a pkgconf dependency added but pkgconf was likely never in makedepends. This example is hidden by the fact that abuild depends on pkgconf but I hope the ideas is clear.
2025-11-04 23:49:46 <Ariadne> you do not need pkgconf to generate a .pc file
2025-11-04 23:50:38 <Sertonix[m]> I have seen many .pc.in files in repos. Or do you mean to read the .pc files?
2025-11-04 23:51:04 <Ariadne> .pc.in files are templates for sed expressions to generate the real .pc file
2025-11-04 23:51:12 <Ariadne> pkgconf does not have a generator for .pc files
2025-11-04 23:51:40 <Sertonix[m]> I missed the "not" in your message O_O
2025-11-04 23:52:11 <Ariadne> my point is that abuild adding `pkgconf` dep here does not influence build order
2025-11-04 23:52:24 <Ariadne> (though i am not sure it should do that)
2025-11-04 23:53:02 <Sertonix[m]> Yes, but is's enough to avoid the issue for all relevant cases.
2025-11-04 23:53:58 <WhyNotHugo> Ariadne: personally I think we should add pkgocnf. I'm not a fan of build-base being an implicit dependency for everything, as many packages don't need those depends.
2025-11-04 23:54:35 <Ariadne> we inherited that particular wart from debian's build-essential, but i agree
2025-11-04 23:55:13 <Ariadne> (re: build-base being harmful)
2025-11-04 23:55:34 <Sertonix[m]> Reducing build-base is a bit difficult but generally I agree
2025-11-04 23:56:40 <Ariadne> one option could be to replace the metadata section with lua
2025-11-04 23:57:08 <Ariadne> that gives us an escape hatch for dynamic evaluation, while still avoiding the subshell problem
2025-11-04 23:58:02 <WhyNotHugo> How can I say no to lua? How would you store the lua metadata and shell script functions?
2025-11-04 23:58:16 <Ariadne> use a delimeter
2025-11-04 23:58:21 <Ariadne> package = "foo"
2025-11-04 23:58:25 <Sertonix[m]> Advantage of lua would be easy sandboxing. Disadvantage is lua version differences.
2025-11-04 23:58:27 <Ariadne> version = 123
2025-11-04 23:58:29 <Ariadne> ---
2025-11-04 23:58:33 <Ariadne> shell code here
2025-11-04 23:59:30 <WhyNotHugo> Ariadne: I like it. Variables resolved from the lua metadata are exported to the shell?
2025-11-04 23:59:35 <Ariadne> yes
2025-11-04 23:59:51 <Ariadne> this would also allow us to clean up a lot of really meh stuff we currently do
2025-11-05 00:00:11 <Ariadne> like stacks of POSIX shell substitutions to mutate a variable
2025-11-05 00:00:35 <WhyNotHugo> How else would one learn every single form of POSIX shell substitution if not by working on APKBUILDS!?
2025-11-05 00:00:38 <angeloverlain[m]> @craftyguy:postmarketos.org I'm assuming postmarketos' mkinitfs is a drop-in replacement for alpine's mkinitfs right (without the initramfs-init bit)
2025-11-05 00:01:04 <Ariadne> WhyNotHugo: tbh i would rather arrive at a future where there is very little shell scripting in APKBUILDs
2025-11-05 00:01:23 <Ariadne> we do not need to be doing build() { ./configure; make; make install } all the time
2025-11-05 00:01:24 <WhyNotHugo> angeloverlain[m]: not really, the pmOS one handles installation of the file too (into different locations dependngin on hardware). The one on Alpine simply writes to an output path.
2025-11-05 00:01:31 <Ariadne> we can just say "this is an autoconf project"
2025-11-05 00:01:53 <skarnet> uh, no
2025-11-05 00:02:04 <Ariadne> (that was the goal of melange's symbolic execution design, that you shouldn't ever have to use shell unless you are working on something exotic)
2025-11-05 00:02:26 <skarnet> ./configure is an interface, and not all projects that follow this interface are autoconf, tyvm
2025-11-05 00:02:27 <WhyNotHugo> Ariadne: I'd rather see `./configure; make; make install` in packages that do that, and the explicit commands in packages that do something else. The indirection hurts readability.
2025-11-05 00:02:33 <skarnet> if you make that assumption things will break
2025-11-05 00:02:40 <abby> we have "build styles" for this on void
2025-11-05 00:02:41 <ikke> ncopa mentioned he wants to avoid too many magic templates
2025-11-05 00:03:00 <abby> build_style=gnu-configure for autoconf, =configure for non-autoconf ./configure
2025-11-05 00:03:19 <Sertonix[m]> Not that the how to interface with build systems is independant of using something like lua
2025-11-05 00:04:05 <Ariadne> WhyNotHugo: the problem is that the indirection helps with keeping things *consistent* at scale
2025-11-05 00:04:10 <WhyNotHugo> OpenBSD ports also have this "build style" interface. It's really hard to properly grasp what's being executed, compared to a current APKBUILD.
2025-11-05 00:04:56 <Ariadne> for example, with cmake and meson, we want to occasionally change settings across every APKBUILD that uses these systems
2025-11-05 00:05:18 <angeloverlain[m]> @_oftc_WhyNotHugo:matrix.org it seems you can just do `--no-bootdeploy`, in which case I assume it will just keep the "build artifacts" in the "work directory"
2025-11-05 00:05:22 <Sertonix[m]> Do we really want to discuss build styles? I have a lot to say about that :)
2025-11-05 00:05:42 <Ariadne> if every APKBUILD spells everything out, then we have to update every APKBUILD directly
2025-11-05 00:05:57 <WhyNotHugo> angeloverlain[m]: I don't recall the details. It's not a drop-in replacement in the sense that you need to use different flags, but it can be used in place of the alpine mkinitfs with some minor tinkering.
2025-11-05 00:05:59 <Ariadne> this is about to bite us hard with the usr-merge
2025-11-05 00:06:18 <Ariadne> because basically ~none of our autoconf builds are consistent
2025-11-05 00:07:12 <WhyNotHugo> Doesn't something like abuild-meson help here? abuild-autoconf?
2025-11-05 00:07:14 <Sertonix[m]> To make it short: In my opinion APKBUILDs should express their intend and when using a known build system abuild can make sure that the expressed intend is actually done in a sane way
2025-11-05 00:07:42 <Ariadne> WhyNotHugo: it does, but this is still indirection
2025-11-05 00:07:59 <Ariadne> what is the difference between "abuild-meson" and "build_type=meson"
2025-11-05 00:08:23 <Sertonix[m]> abuild-meson only helps a bit. Mainly suffering from abuild (and environment variables set for abuild) not being able to express things proplerly
2025-11-05 00:08:31 <angeloverlain[m]> @_oftc_WhyNotHugo:matrix.org it seems it would work very easily, if we create a file /usr/share/deviceinfo/00-alpine with a few of these options set to just place the generated image in /boot. https://wiki.postmarketos.org/wiki/Deviceinfo_reference
2025-11-05 00:08:43 <invoked> Sertonix[m]: aye, if we're gonna change things it should make reviews less work
2025-11-05 00:09:37 <Ariadne> to be clear, i designed melange as an anti-abuild
2025-11-05 00:10:02 <Ariadne> the internal design documentation literally says: when in doubt, do the exact opposite of whatever abuild does
2025-11-05 00:10:43 <Ariadne> i recognize that is not realistic for alpine, but the current design of APKBUILD hurts us bad when it comes to enforcing consistency
2025-11-05 00:10:50 <Sertonix[m]> So if I make abuild better you will make melange worse :)
2025-11-05 00:11:13 <Ariadne> Sertonix[m]: i will not make melange anything, i work elsewhere for years now
2025-11-05 00:11:34 <ikke> Sertonix[m]: I guess that would count as mission accomplished
2025-11-05 00:13:05 <Ariadne> if abuild is better, then that is good for alpine
2025-11-05 00:13:17 <angeloverlain[m]> anyway, re: supervisor in initramfs, it seems arch supports running either systemd or a busybox init as /init (https://wiki.archlinux.org/title/Mkinitcpio)
2025-11-05 00:14:03 <angeloverlain[m]> re: melange. I also agree that it's considerably harder to parse than current abuild, but maybe it comes with time
2025-11-05 00:14:29 <Ariadne> again: i am not proposing alpine use melange
2025-11-05 00:14:43 <Ariadne> i am just saying we can learn lessons from melange
2025-11-05 00:15:02 <angeloverlain[m]> yeah, we can definitely learn some things there
2025-11-05 00:15:05 <ikke> How are we going to avoid shedding bikes?
2025-11-05 00:15:15 <WhyNotHugo> Anyone tried using Arch's mkinitcpio on Alpine? I guess the explicit usage of bash is really weird.
2025-11-05 00:15:21 <Ariadne> we can also learn lessons from void
2025-11-05 00:15:26 <Sertonix[m]> Ariadne: If you want me to look into any of the discussed things in more depths feel free to create an issue on gitlab. Otherwise some stuff may be handled with very low speed/priority on my side.
2025-11-05 00:15:43 <WhyNotHugo> Ariadne: I think chimera also has something like build styles.
2025-11-05 00:15:44 <angeloverlain[m]> Sertonix[m]: yeah, I would follow that issue too :)
2025-11-05 00:16:12 <Ariadne> WhyNotHugo: yes
2025-11-05 00:16:28 <WhyNotHugo> Of course you knew this :P
2025-11-05 00:16:44 <Ariadne> right now, however, i think our largest concern is the fact that someone can send an alpine dev a patch that exfiltrates their signing key
2025-11-05 00:16:44 <angeloverlain[m]> @_oftc_WhyNotHugo:matrix.org never tried it, but what I like about it is that everything is cleanly separated into "hooks" (https://wiki.archlinux.org/title/Mkinitcpio#Common_hooks)
2025-11-05 00:17:04 <Sertonix[m]> Hot take: Write meson files for everthing so that buildstyle=meson can be an implicit constant :)
2025-11-05 00:17:05 <Ariadne> without even running `abuild`
2025-11-05 00:17:27 <WhyNotHugo> angeloverlain[m]: yeah. and hooks have an explicit order specified in the config.
2025-11-05 00:17:51 <abby> <WhyNotHugo> Ariadne: I think chimera also has something like build styles. <- chimera's package build system started out as a rewrite of void's
2025-11-05 00:18:29 <angeloverlain[m]> @_oftc_WhyNotHugo:matrix.org yeah, which is why I was so excited for mkinitfs!206, but I think we probably want something completely new
2025-11-05 00:18:35 <WhyNotHugo> Sertonix[m]: New precondition for packaging in alpine: upstream must use meson. :)
2025-11-05 00:18:46 <Ariadne> i don't think that is realistic, sadly
2025-11-05 00:18:51 <Sertonix[m]> Ariadne: Protecting the signing key also needs remote signing which is an open MR on the apk-tools repository.
2025-11-05 00:19:53 <Ariadne> Sertonix[m]: my point is, if i am not very careful, and `git apply` something, and then use `buildrepo` or `ap`, i can wind up executing code that hurts me
2025-11-05 00:20:59 <Sertonix[m]> Yes. Also on my TODO list for my mentioned, yet to be finished project :)
2025-11-05 00:21:02 <Ariadne> be that signing key exfiltration, be that personal data exfiltration, whatever
2025-11-05 00:21:04 <Ariadne> :p
2025-11-05 00:21:24 <Ariadne> i would normally say "crypto wallet" here, but i personally think crypto is bullshit and thus don't have one
2025-11-05 00:22:19 <Ariadne> so i think moving APKBUILD metadata to lua is a good start
2025-11-05 00:22:27 <Sertonix[m]> Signing from a non-file source is all we need.
2025-11-05 00:22:52 <angeloverlain[m]> 
ACTION wonders why lua

2025-11-05 00:22:58 <Sertonix[m]> Your "start" is one of the most complicated things :p
2025-11-05 00:23:11 <Ariadne> because alpine already use lua
2025-11-05 00:23:21 <WhyNotHugo> Ariadne: home banking cookies?
2025-11-05 00:23:35 <angeloverlain[m]> well, I'd say that alpine also uses shell scripts :p
2025-11-05 00:24:08 <Ariadne> Sertonix[m]: the issue is that if there is a boobytrap in APKBUILD, it will run when aports is enumerated
2025-11-05 00:24:21 <skarnet> angeloverlain[m]: because Arch does something doesn't mean it's a good idea. Running a generic init system in an initramfs does not sound useful, and if initramfs need a supervisor that can run as pid 1 and *also* exec into something else to run the real system, I have a better fit than what Arch uses. :P
2025-11-05 00:24:43 <skarnet> but really, a shell script or whatever should be amply sufficient
2025-11-05 00:25:39 <Ariadne> in fact, i think we have just gotten really lucky that this hasn't already happened
2025-11-05 00:25:49 <Ariadne> it seems like a fairly obvious attack to me
2025-11-05 00:26:00 <WhyNotHugo> Ariadne: do you apply patches before reading them?
2025-11-05 00:26:02 <Sertonix[m]> Yes, to me as well
2025-11-05 00:26:25 <Ariadne> WhyNotHugo: yes, all the time, because that's the point of a git worktree
2025-11-05 00:26:32 <abby> mkinitcpio doesn't use busybox /bin/init as init, it's a custom script, and same for systemd-style, systemd is not pid1
2025-11-05 00:27:01 <WhyNotHugo> Considering the "enumeration implies execution" angle only further convinces me that we should ought to use lua for metadata
2025-11-05 00:27:32 <Ariadne> WhyNotHugo: i think lua is fine, we can restrict it
2025-11-05 00:27:36 <angeloverlain[m]> @_oftc_skarnet:matrix.org @_oftc_abby:matrix.org  I think what we would want is to have an /bin/init that can execute other different "programs", instead of having one big shell script.
2025-11-05 00:27:40 <abby> (fwiw i do work on mkinitcpio, mostly for void compat, and i don't understand the point of sysd-ini-initramfs)
2025-11-05 00:27:44 <ikke> atools-go / apkgquery can evaluate APKBUILDs without execution
2025-11-05 00:28:14 <ikke> (it obviously has to ignore subshells that exec)
2025-11-05 00:28:18 <Ariadne> ikke: can it do so reliably?  does it handle [ "$CARCH" = "foo" ] && subpackages="$subpackages bar" ?
2025-11-05 00:28:22 <ikke> yes
2025-11-05 00:28:26 <ikke> It should
2025-11-05 00:28:41 <ikke> But let met check to be really sure
2025-11-05 00:28:41 <Ariadne> how do you handle that without evaluating it?
2025-11-05 00:29:06 <skarnet> angeloverlain[m]: what do you mean by "execute other different programs"? because executing other different programs is something sh does pretty well, but I understand you have other requirements :)
2025-11-05 00:29:39 <Ariadne> ikke: a good test would be community/libreoffice
2025-11-05 00:29:45 <Sertonix[m]> Metadata values can be a trap themselfs so it can't really fulfil any thread model alone
2025-11-05 00:29:46 <ikke> Ariadne: ok
2025-11-05 00:30:26 <Ariadne> Sertonix[m]: metadata values can't execute rm -rf /
2025-11-05 00:31:14 <Ariadne> at least, not normally
2025-11-05 00:31:37 <angeloverlain[m]> @_oftc_skarnet:matrix.org alpine's initramfs-init is 1105 lines long, it would be nice to separate that into different "features" that can be toggled while building the image (and thus never make it into the initramfs). like completely disabling zfs. or (hypothetical example) in the future, add support for bcachefs, without having to make initramfs-init even more complex
2025-11-05 00:31:50 <Sertonix[m]> Pretty sure that metadata can be enough to execute rm -rf / on your next build
2025-11-05 00:32:07 <Ariadne> i prefer to drop bcachefs support :p
2025-11-05 00:32:29 <angeloverlain[m]> I also don't use it, was just an example
2025-11-05 00:32:52 <Sertonix[m]> ikke: Even better test is community/gdal
2025-11-05 00:33:04 <skarnet> angeloverlain[m]: ah, so, you mean modularity at build time. That's very different from modularity at boot time.
2025-11-05 00:33:08 <angeloverlain[m]> better examples would be TPM2-based disk decryption, disk decryption on touch screens (with unl0kr), kmscon, plymouth, etc...
2025-11-05 00:33:42 <angeloverlain[m]> @_oftc_skarnet:matrix.org yes exactly, sometimes it's hard for me to make my point clear :)
2025-11-05 00:34:37 <Ariadne> Sertonix[m]: community/gdal is a great example of why letting people commit crimes is bad
2025-11-05 00:35:14 <WhyNotHugo> Arch Linux initramfs generation tools
2025-11-05 00:35:20 <WhyNotHugo> getvar() { eval "printf '%s\n' \"\${$1:-$2}\"" }
2025-11-05 00:35:21 <Ariadne> okay maybe that isn't kind :p
2025-11-05 00:35:31 <WhyNotHugo> (ignore arch message, accidental paste)
2025-11-05 00:39:26 <Ariadne> anyway my point is that dynamic code execution to determine package outputs is Bad(tm)
2025-11-05 00:39:43 <Ariadne> and the ideal end state is one where we no longer do that
2025-11-05 00:40:08 <Ariadne> (or at least where this dynamic code execution is heavily constrained)
2025-11-05 00:52:56 <elibrokeit> 19:28 <Ariadne> ikke: can it do so reliably?  does it handle [ "$CARCH" = "foo" ] && subpackages="$subpackages bar" ?
2025-11-05 00:53:26 <elibrokeit> poor design imo :P subpackages_amd64="..." is the better way to avoid code execution here
2025-11-05 00:53:39 <Ariadne> you don't see me disagreeing...
2025-11-05 00:54:48 <elibrokeit> Gentoo just uses a micro-language, so you'd end up with subpackages=" amd64? ( .... ) universal-subpackages"
2025-11-05 01:00:26 <elibrokeit> (the mini language is actually "build options" but CARCH is a forced-on global build option provided by the builder itself to all packages)
2025-11-05 01:37:20 <lotheac> i'm a bit late to the discussion, but separating metadata from the build code makes a lot of sense to me so i would support such an endeavour
2025-11-05 01:37:51 <lotheac> perhaps even regardless of metadata language; it doesn't matter terribly much :p
2025-11-05 01:38:31 <elibrokeit> one file or two? :P
2025-11-05 01:38:39 <lotheac> doesn't matter
2025-11-05 01:39:23 <elibrokeit> I'd say it does matter, polyglot files are how you end up with GNU m4sh
2025-11-05 01:39:48 <lotheac> i even had this weird idle thought that with the delimiter-approach someone might propose shell for the build instructions and... shell for the metadata :D but that would really only help solve part of the problem
2025-11-05 01:40:13 <lotheac> elibrokeit: yeah fair enough, let's hope we don't go that far :p
2025-11-05 01:41:18 <lotheac> APKBUILD i feel like generally are not directly fed to shell as is anyway so i don't see a terribly big problem changing the format a little bit
2025-11-05 01:41:25 <lotheac> but, not my bikeshed to paint
2025-11-05 01:41:33 <elibrokeit> if it's just a security issue, you could try an absolute ban on external commands in global scope and evaluate metadata using a restricted parser 
2025-11-05 01:41:58 <lotheac> there's the performance aspect too
2025-11-05 01:42:31 <lotheac> and "absolute ban" would need some kind of automatic enforcement
2025-11-05 01:42:48 <elibrokeit> depending on how you define the limits, it could be as simple as a safe simple subset of shell that can be parsed from any language
2025-11-05 01:43:03 <lotheac> right, but at that point it doesn't really need to be shell
2025-11-05 01:43:35 <elibrokeit> e.g. Gentoo's make.conf syntax is shell compatible but parsed via python shlex
2025-11-05 01:44:43 <elibrokeit> and Gentoo ebuilds are shell, but the tool automstically enforces an absolute ban on external commands during metadata parsing :D
2025-11-05 01:45:02 <ikke> ftr, ncopa has always spoken against splitting things up in multiple files
2025-11-05 01:46:46 <elibrokeit> it could be as simple as using rbash / bash -r
2025-11-05 01:47:43 <elibrokeit> which isn't strictly an absolute security boundary but does get you most of the way there -- anything that can escape rbash could likely also be caught easily during eyeball review
2025-11-05 01:49:02 <Ariadne> 
ACTION is not in favor of switching from GCC to clang as default system C compiler

2025-11-05 01:49:53 <Ariadne> 
ACTION is also not in favor of dropping vector support from loongarch64 port

2025-11-05 08:38:58 <Sertonix[m]> Through the power of PATH= I already can tell that tr is the only external command (actively) used in aports and external commands are already banned in the global scope. The missing thing is to enforce such a rule.
2025-11-05 11:28:45 <ikke> only one is gdal, it executes tr
2025-11-05 11:48:46 <lindsay> Some subpackage will change pkgdesc and install_if in their sub functions, I think it's not enough to only eval top-level expressions.
2025-11-05 12:02:05 <WhyNotHugo> lindsay: some also change their depends in the sub functions, that's kinda what led to this discussion: it's quite non-trivial to extract this information.
2025-11-05 13:05:13 <Sertonix[m]> One has to be clear that determining the dependencies of the final packages is a non-goal due to being impossible. The only intresting thing is to determine which APKBUILDs need to be build before any given other APKBUILD.
2025-11-05 13:13:40 <WhyNotHugo> Right, we only want to know build-dependencies.
2025-11-05 13:24:34 <elibrokeit> determining the dependencies of the final packages would be possible with a spec change, if it's simply a matter of statically overriding in sub functions. depends_$subpkg="..." -- if you want to support dynamic conditional computation e.g. modifying metadata variables based on the ELF metadata of built files, that's hopeless regardless of whether sub functions get evaluated via 
2025-11-05 13:24:34 <elibrokeit> untrusted bash, so it's not worth discussing 
2025-11-05 13:30:48 <elibrokeit> if you don't mind it being dangerously untrusted shell execution, there's even another option -- archlinux makepkg has some very clever code to evaluate sub-functions via `declare` piped to grep to locate assignments, for extracting variables out of a function without running the side effects of the function
2025-11-05 13:35:38 <WhyNotHugo> Any feedback for !92200? Probably okay to merge.
2025-11-05 13:36:13 <WhyNotHugo> Ditto !92480
2025-11-05 14:15:18 <raspbeguy> Hello, can someone merge those MRs please? !87884 !90941 !91118 !91337 !91546
2025-11-05 15:36:32 <Biswa96[m]> shai has an unresolved review.
2025-11-06 00:27:14 <elagost> is there a place where the install hooks are stored in a package?
2025-11-06 00:27:37 <elagost> or on the filesystem after install?
2025-11-06 00:29:44 <ikke> (/usr)/lib/apk/db/scripts.tar
2025-11-06 00:31:40 <elagost> oh weird, why in a tar file?
2025-11-06 00:33:33 <elagost> thanks, and I didn't mean to be rude, just curious why that decision was made.
2025-11-06 00:34:38 <ikke> I wasn't there, so can only guess
2025-11-06 11:30:10 <ncopa> hi. im back from kcd porto
2025-11-06 11:30:32 <ncopa> how are things going?
2025-11-06 12:00:19 <ikke> I've copied the distfiles data to a new volume, so it should be more stable again
2025-11-06 12:06:12 <ncopa> thanks!
2025-11-06 13:56:02 <qaqland> !88695 is ready to merge
2025-11-06 14:44:06 <bl4ckb0ne> is there a rule for installing packages into /usr/sbin rather than /usr/bin ?
2025-11-06 14:47:58 <skarnet> I don't know about rules, but generally speaking, if it only makes sense for a binary to be run by root (and there's zero use case for a normal user running it), /usr/sbin is reasonable, in all other cases /usr/bin it is
2025-11-06 14:48:29 <skarnet> but then again there are root-only binaries in /usr/bin as well, so... <shrug>
2025-11-06 14:48:30 <bl4ckb0ne> thats what i though, a binary for a service has no place there
2025-11-06 14:48:45 <skarnet> probably not
2025-11-06 15:00:24 <elibrokeit> the traditional counter-argument is that it is "reasonable" for a normal user to run its --help text
2025-11-06 15:00:55 <elibrokeit> though that argument is used for abolishing the separation of directories and making sbin a symlink to bin
2025-11-06 15:01:10 <skarnet> yeah
2025-11-06 15:01:23 <skarnet> the distinction is arbitrary and kinda obsolete nowadays
2025-11-06 15:01:27 <elibrokeit> generally upstream will configure to install specific programs into --sbindir and you don't have to make that decision
2025-11-06 15:02:00 <skarnet> there is more of a semantic difference between /bin and /usr/bin than between /bin and /sbin
2025-11-06 15:02:15 <skarnet> so in a post-usrmerge world, the difference between /usr/bin and /usr/sbin is... small
2025-11-06 15:03:14 <elibrokeit> (every makefile in existence *should* be using ./configure, no exceptions, come on people it's absolutely trivial to write a two line configure.ac that finishes configuring in sub-second times and properly supports decision logic for your makefile)
2025-11-06 20:57:02 <AledCuda[m]> Where is the set of cross toolchains that get built for gcc on a given architecture configured
2025-11-06 20:58:07 <AledCuda[m]> I want to add a microblaze cross toolchain to aarch64 to support uboot on zynqmp but I don't see the where in the apk built that's configured
2025-11-06 20:58:37 <AledCuda[m]> Even though I do see gcc cross toolchains available on aarch64 for msp430/avr/etc
2025-11-06 20:58:47 <AledCuda[m]> *APKBUILD
2025-11-06 22:04:28 <elagost> I'm porting to a device and trying to get FDE working - I'm getting 'encrypted_key: failed to alloc_cipher (-2)' when I try to decrypt with unl0kr. It also shows 'device-mapper:table:254:0: crypt: unknonw target type'. What am I missing?
2025-11-06 22:13:52 <craftyguy[m]> elagost: unl0kr doesn't do any decryption, that message is from cryptsetup. Maybe the kernel is missing some config?
2025-11-06 22:17:28 <elagost> hm. It's just the standard rpi kernel. I've got an encrypted alpine install on another sd card and it unlocks fine. 
2025-11-06 22:19:58 <elagost> possible the initramfs doesn't have the requisite kernel modules baked in?
2025-11-06 22:23:06 <AledCuda[m]> Ah do these come from https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/gcc-cross-embedded/APKBUILD
2025-11-06 22:26:39 <elagost> got into the debug shell; it's having trouble loading the dm_crypt module? wild!
2025-11-06 22:32:14 <AledCuda[m]> Because the cross toolchains are built in community does that mean uboot can't depend on them for any platforms?
2025-11-06 22:32:26 <AledCuda[m]> Or can a u-boot subpackages be in community
2025-11-06 22:33:05 <AledCuda[m]> This is to build the firmware for the hard microblaze PMU which is needed for a number of things
2025-11-06 22:33:47 <AledCuda[m]> It might be possible to make a blob generic enough for any of the zynqmp boards and then presumably get that into linux-firmware?
2025-11-06 22:40:54 <elagost> oh interesting, even with `modprobe -f encrypted_keys` in a rescue shell I'm getting 'exec format error'. I have no idea how or why that could be the case.
2025-11-06 22:48:34 <ncopa> we have circular dep: qemu -> ceph19 -> libnbd -> qemu
2025-11-06 23:18:28 <mio> ncopa: may be due to ceph19 19.2.3 upgrade enabled libnbd?
2025-11-07 06:41:13 <qaqland> !88712 is ready, or is there anything else i need to do?
2025-11-07 10:00:41 <omni> damn, looks like I was about to merge that three weeks ago, no idea why I didn't
2025-11-07 10:22:24 <moha-al> Hi! Might I ask for a review of !92560 ?
2025-11-07 10:24:49 <ncopa> Or due to qemu-img in checkdepends. Don’t know 
2025-11-07 10:26:31 <ncopa> moha-al: is the fix in edge? Add a link to commit the shows that it is fixed in edge. So we don’t get a regression in 3.23
2025-11-07 10:31:14 <moha-al> @ncopa: Yes, it is. Was merged via !92316 , cherry-pick reference is in commit/PR message of 92560, just double-checked.
2025-11-07 12:31:30 <qaqland> ncopa: request to drop a package in !92723 
2025-11-07 12:43:15 <Sertonix[m]> ncopa: Disabling checks of libnbd solves the recursive makedependency. Not sure if it's a good fix though
2025-11-07 12:52:26 <ncopa> Sounds like a good tradeoff
2025-11-07 13:10:34 <JozefMlich[m]> Hi, I’m wondering what I can do to help move this merge request forward https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/89793
2025-11-07 14:23:00 <nero> did someone from the alpine-linux project contribute to the UAPI LFSH standard? https://uapi-group.org/specifications/specs/linux_file_system_hierarchy/
2025-11-07 17:29:15 <pj> nero: is there anything specific you want to ask about?
2025-11-07 17:40:15 <quinq> Why does it look like it's been written without thinking about its application
2025-11-07 23:56:29 <Kladky> Could someone review !86084 please? It's been open for over 4 months with no review
2025-11-08 01:32:32 <ayakael> Hi! Could someone review https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/87569, it'd be nice for postmarketOS devices to have koreader on next latest.
2025-11-08 02:14:30 <ayakael> I also fixed the build for my openterface aport: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/80072
2025-11-09 00:01:43 <ikke> Gitlab is being upgraded to 18.5 and should be back soon
2025-11-09 02:31:45 <elagost> gitlab now has the dark mode 404 page nice :)
2025-11-09 08:24:45 <Daniel[m]> https://t.me/+fk5a2eNOe9BhY2I8https://t.me/+fk5a2eNOe9BhY2I8
2025-11-09 09:24:39 <Daniel[m]> Happy Sunday ‼️ Happy Sunday  ‼️ Happy Sunday ‼️
2025-11-09 09:24:41 <Daniel[m]> Inbox on how to get started
2025-11-09 09:24:41 <Daniel[m]> #Invest your money and make a lot of profit, don't just sit there and watch people earn.
2025-11-09 09:24:43 <Daniel[m]> https://t.me/+fk5a2eNOe9BhY2I8
2025-11-09 09:24:43 <Daniel[m]> https://t.me/+fk5a2eNOe9BhY2I8
2025-11-09 16:10:17 <ovf> mio: whoops https://gitlab.alpinelinux.org/alpine/aports/-/commit/86166502e92be24a3373f6ae5ce585432b56ffa2#b9760473be86328dbdf351ae426f951558cd0181 want me to revert this?
2025-11-09 16:10:43 <ovf> sorry i should double-check what's in my git index
2025-11-09 16:11:31 <mio> it's fine, will remove, that's on me
2025-11-09 16:12:00 <mio> sorry, should have caught that
2025-11-09 16:18:32 <mio> s/remove/restore/ done
2025-11-09 16:28:56 <ovf> thank you!
2025-11-09 16:29:33 <mio> you're welcome
2025-11-09 16:30:10 <ovf> as a penitence i should actually get to figuring out test failures in newer scryer-prolog and update the apkbuild...
2025-11-09 16:30:53 <funderscore> 7191
2025-11-09 16:31:55 <mio> not as penitence, as contribution
2025-11-09 17:09:32 <quinq> Only the penitent man shall commit
2025-11-09 20:04:22 <ikke> fyi, shellcheck in apkbuild-lint-tools is updated from 0.10.0 to 0.11.0. Please let me know if there are any unexpected issues
2025-11-09 20:05:00 <andypost[m]> ncopa: 3.22 is broken after 109065ba85232c827f11084becba4da1b25096f7 as both cryptography and setproctitle in community
2025-11-10 08:50:48 <indy> hi all is there way to abort installation of library if there are missing symbols?
2025-11-10 08:52:11 <indy> like using ldd in post-install script to verify that all needed symbols are ok
2025-11-10 10:57:58 <quinq> indy, that would rather be a job for the build system, not something that should be done at runtime
2025-11-10 11:03:08 <indy> quinq, like abuild?
2025-11-10 11:04:44 <quinq> yeah
2025-11-10 11:07:13 <indy> quinq, how do you mean it? abuild already dynamically detects so version, but if somebody forgot put constraints to apkbuild regarding versions you can end up with missing symbols
2025-11-10 11:08:00 <indy> can i create own provides? like "symbol:someshittycppmangledsymbol"?
2025-11-10 11:10:36 <ncopa> andypost[m]: thanks. thats what i got for skipping the CI...
2025-11-10 11:14:45 <ncopa> does anyone know what this is about? https://www.reddit.com/r/AlpineLinux/comments/1ot6rub/alpine_update_broke_all_my_docker_based_services/
2025-11-10 11:43:44 <jvvv> ncopa: at first blush, it looks like the breakage is related to this: https://www.reddit.com/r/docker/comments/1op6e1a/impossible_to_run_docker/
2025-11-10 11:46:16 <nero> F https://github.com/opencontainers/runc/issues/4968
2025-11-10 11:49:24 <jvvv> looking at containerd issues, i found this comment with a supposed hotfix: https://github.com/containerd/containerd/issues/12484#issuecomment-3500919333
2025-11-10 11:53:25 <jvvv> i don't have any lxc or proxmox containers setup, so i can't test it rn
2025-11-10 11:56:03 <jvvv> the containerd issue comment is referencing the runc issue that nero pointed to
2025-11-10 12:20:48 <ncopa> thanks!
2025-11-10 12:27:18 <ncopa> wow. what a mess
2025-11-10 13:00:19 <quinq> indy, indeed that's what I mean, there's already a system there to manage it
2025-11-10 13:00:38 <quinq> And yes, bugs happen, but that's why there's review and testing stages
2025-11-10 13:01:05 <quinq> Also maybe the existing system isn't enough and could be improved, but I think it should be done at this level, when building
2025-11-10 13:01:08 <quinq> once
2025-11-10 13:01:16 <quinq> Not every time a package is installed somewhere by somebody
2025-11-10 14:04:36 <invoked> if it ain't a mess,  it'll do till the mess gets here
2025-11-10 14:07:05 <skarnet> if it ain't a mess, don't worry, it's just a question of time
2025-11-10 16:41:27 <raspbeguy> Hello, can someone take care of the following MRs please? !87884 !90941 !91118 !91572
2025-11-10 18:23:40 <durrendal> raspbeguy: I think the focus is currently set on getting things ready for 3.23, it might take a bit to get new aports in.
2025-11-10 20:06:17 <angeloverlain[m]> I asked a while back, but will ask again. is it possible to make diskless installs use an exact set of packages? when you update the cache with apk cache download -a, and reboot, the packages on your system will be the latest, but I would like every diskless ovl to use the exact same package versions as when it was created
2025-11-10 20:28:13 <raspbeguy> durrendal: i see. Well, then please at least !90941 as it also modify a community aport
2025-11-10 23:17:52 <omni> angeloverlain[m]: if you to your own apk cache/mirror where you keep stale packages, but are you running edge or why do you want to do this? (assuming stable releases should be stable and only receive bug and security fixes)
2025-11-11 11:23:45 <Kladky> Can someone please look at !88569? It's been ready for a while, and also is one of the items on #17311
2025-11-12 00:45:06 <logan2611> Working on MR !92823, why does my check cause an Illegal Instruction? I was not able to reproduce this locally. https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/92823#note_558104
2025-11-12 00:45:18 <logan2611> Specifically on armhf, my bad
2025-11-12 00:46:31 <logan2611> I should also clarify that it's the runner that is having that issue
2025-11-12 05:37:31 <logan2611> Never mind, I take that back. I thought bcachefs-tools compiled correctly on armhf, apparently that is no longer the case as of 2025
2025-11-12 07:17:41 <angeloverlain[m]> @_oftc_WhyNotHugo:matrix.org what happened to https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/231?
2025-11-12 07:24:07 <angeloverlain[m]> ah, I think I misunderstood. I wanted to have every manpage be published like arch linux does
2025-11-12 10:00:10 <Newbyte> Is there anything I could do to get !92427 merged?
2025-11-12 10:25:33 <ncopa> Newbyte: added a suggestion
2025-11-12 10:30:56 <Newbyte> thank you!
2025-11-12 13:49:08 <jahway603[m]> Can I get !92900 merged please?
2025-11-12 15:51:10 <andypost[m]> [@jahway603:meowchat.xyz](https://matrix.to/#/@jahway603:meowchat.xyz) done
2025-11-12 15:56:18 <Minus888> The website currently associates CVE-2023-27482 with the source package `supervisor`
2025-11-12 15:56:18 <Minus888> Hi Alpine Security team,
2025-11-12 15:56:18 <Minus888> “supervisor · CVE-2023-27482”). This looks incorrect.
2025-11-12 15:56:18 <Minus888> CVE-2023-27482 is an authentication bypass in **Home Assistant Supervisor**,
2025-11-12 15:56:18 <Minus888> (e.g., https://security.alpinelinux.org/srcpkg/supervisor and branch views showing
2025-11-12 15:56:20 <Minus888> - NVD: https://nvd.nist.gov/vuln/detail/CVE-2023-27482
2025-11-12 15:56:20 <Minus888> not the UNIX process-control tool `supervisor`. Upstream references:
2025-11-12 15:56:22 <Minus888> - Home Assistant disclosure: https://www.home-assistant.io/blog/2023/03/08/supervisor-security-disclosure/
2025-11-12 15:56:22 <Minus888> Impact scope per upstream:
2025-11-12 15:56:24 <Minus888> - Affects Home Assistant installations using **Supervisor ≤ 2023.01.1**.
2025-11-12 15:56:24 <Minus888> - Not related to the `supervisor` process-control package.
2025-11-12 15:56:26 <Minus888> Request:
2025-11-12 15:56:26 <Minus888> - Fixed in Supervisor 2023.03.1 / Core 2023.3.0+.
2025-11-12 15:56:28 <Minus888>   as **not affected / false positive** for CVE-2023-27482 on the tracker.
2025-11-12 15:56:28 <Minus888> - Please remove the linkage from the Alpine `supervisor` package and mark it
2025-11-12 15:56:30 <Minus888> - Source package page shows CVE-2023-27482 as unresolved for `supervisor`.
2025-11-12 15:56:30 <Minus888> References on the tracker showing the mislink:
2025-11-12 15:56:32 <Minus888> - Branch pages (e.g., 3.18-main, 3.22-main) list `supervisor · CVE-2023-27482`.
2025-11-12 15:56:32 <Minus888> Thanks!
2025-11-12 16:07:40 <jahway603[m]> Hi Minus888, there is a separate chat for security discussions - #alpine-security
2025-11-12 16:09:59 <Minus888> My bad, thanks for the feedback
2025-11-12 16:14:47 <ikke> Minus888: Would you mind opening an issue for it? A bit easier to read than an IRC chat
2025-11-12 16:19:22 <Minus888> @ikke A bit new with Alpine, could you give me a link to open an issue ?
2025-11-12 16:20:26 <ikke> https://gitlab.alpinelinux.org/alpine/security/secdb/-/issues
2025-11-12 16:30:17 <Minus888> Ticket openned: https://gitlab.alpinelinux.org/alpine/security/secdb/-/issues/15
2025-11-12 16:30:23 <ikke> Thanks, saw the notification
2025-11-13 04:08:52 <jvvv> openrc's default etc/conf.d/consolefont has 'consolefont="default8x16.psf.gz"'. the closest match i have found is default8x16.psfu.gz from the kbd-misc package. should the openrc patch (0004-make-consolefont-service-compatible-with-busyboxs-se.patch) be updated? seems like a pretty minor nit, so maybe i'll revisit after 3.23 is released.
2025-11-13 05:52:38 <craftyguy[m]> could someone please merge !92480? thanks!
2025-11-13 06:00:56 <quinq> “Extremely fast Python” huhu
2025-11-13 06:04:56 <lotheac> well it's not written in python :p
2025-11-13 06:08:58 <lotheac> craftyguy[m]: done
2025-11-13 06:11:54 <quinq> Ah right, I misread :)
2025-11-13 06:37:56 <craftyguy[m]> lotheac: thank you!
2025-11-13 06:50:32 <Ariadne> jvvv: i would say it is worth fixing after 3.23 is released
2025-11-13 09:49:09 <liske> Could someone please take a look at !92714 ? Without the patch it is currently not possible to use bird_exporter with bird2 in 3.22 :-(
2025-11-13 09:52:23 <lotheac> merged
2025-11-13 09:56:18 <liske> lotheac: Thanks! :)
2025-11-13 12:02:28 <raspbeguy> Hello, can someone take care of these MRs please ? (only upgrade MRs as I undestand that new aports are not the priority at this time because of 3.23 release proximity) !91572 !92914
2025-11-13 15:29:27 <ikke> ^ have been merged
2025-11-13 15:29:35 <ikke> (not by me ftr)
2025-11-13 15:53:02 <ikke> mick_ibm: Not sure if you are the right person to ask, or someone else, but openblas currently has a test failure on ppc64le for the 3.23 release 'TEST 125/127 kernel_regress:skx_avx [FAIL]
2025-11-13 15:53:04 <ikke>   ERR: test_kernel_regress.c:50  expected 0.000e+00, got 2.226e+02 (diff -2.226e+02, tol 1.000e-10)"
2025-11-13 15:53:51 <ikke> mick_ibm: Would someone be available to take a look at it?
2025-11-13 15:56:39 <mick_ibm> do you have a link to share? i might not be able to help but i could maybe bring it to the attention of the right people
2025-11-13 15:56:46 <ikke> https://build.alpinelinux.org/buildlogs/build-3-23-ppc64le/community/openblas/openblas-0.3.30-r0.log
2025-11-13 15:56:50 <ikke> Not yet an issue
2025-11-13 16:08:51 <ikke> mick_ibm: https://gitlab.alpinelinux.org/alpine/aports/-/work_items/17714
2025-11-13 16:35:17 <jvvv> Ariadne: thanks for the input, that is what will do
2025-11-13 17:32:42 <ncopa> PureTryOut: do you think you can help with pyside6? it fails on all builders
2025-11-13 17:39:16 <PureTryOut> I know, I haven't figured out the problem yet. I'm going to ask some KDE people if they know what's up
2025-11-13 18:50:45 <ncopa> I started to look at it today but didn’t come to any conclusion. I get the feeling that the 
2025-11-13 18:50:45 <ncopa> LD
2025-11-13 18:51:34 <ncopa> LD library path env var gets wrong for some reason
2025-11-13 18:51:42 <Ariadne> what is "libshiboken6.abi3.so.6.10"?
2025-11-13 18:52:40 <ncopa> some sort of library provided by pyside6
2025-11-13 18:53:05 <ikke> But 6.9, not .10, at least, what I saw in pkgs.a.o
2025-11-13 18:53:22 <Ariadne> its locally built though
2025-11-13 18:53:24 <ncopa> It is in the build tree. It is just not found
2025-11-13 18:54:42 <ncopa> LD_LIBRARY_PATH is set, but it looks like it is set to wrong path
2025-11-13 18:58:14 <ncopa> $ find -name libshiboken6.abi3.so.6.10 
2025-11-13 18:58:14 <ncopa> ./src/pyside-setup-everywhere-src-6.10.0/build/sources/shiboken6/libshiboken/libshiboken6.abi3.so.6.10
2025-11-13 19:02:09 <ncopa> curl --silent https://build.alpinelinux.org/buildlogs/build-edge-s390x/community/pyside6/pyside6-6.10.0-r0.log | grep LD_LIBRARY_PATH
2025-11-13 19:29:15 <PureTryOut> You got into the builder to do that find command?
2025-11-13 20:20:02 <ncopa> no, I reproduced it locally
2025-11-13 20:20:21 <ncopa> built the qt6-* stuff (except webengine)
2025-11-13 20:20:32 <ncopa> and then built pyside6
2025-11-13 22:48:53 <omni> you can also infer it from the build log
2025-11-13 22:48:55 <omni> curl --silent https://gitlab.alpinelinux.org/alpine/aports/-/jobs/2091504/raw | grep libshiboken6.abi3.so.6.10
2025-11-14 07:17:34 <JozefMlich[m]> Is there something I can do to merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/89793 ?
2025-11-14 08:22:01 <JozefMlich[m]> fossdd: 3>
2025-11-14 08:22:06 <JozefMlich[m]> * fossdd: <3
2025-11-14 10:12:04 <PureTryOut> Jozef Mlich: any plans on porting it to Qt6 soon? We're slowly.trying to get rid of Qt5 in Alpine
2025-11-14 10:12:06 <PureTryOut> (since it's EOL)
2025-11-14 10:24:41 <omni> PureTryOut: are you getting anywhere with pyside6?
2025-11-14 10:24:48 <omni> I feel like I have no idea what I'm doing
2025-11-14 10:40:31 <omni> it's really not my area and I've spent so many hours on this the past couple of days
2025-11-14 10:40:42 <omni> if no one has any ideas and we cannot find a way to fix the pyside6 build we should probably revert the Qt 6.10 upgrade, we were in feature freeze after all
2025-11-14 11:24:27 <JozefMlich[m]> <PureTryOut> "Jozef Mlich: any plans on..." <- We haven't started with transition to Qt6 so far.
2025-11-14 11:51:37 <PureTryOut> perhaps we can just revert that package bump for now. idk if builders will pick that up properly
2025-11-14 11:51:47 <PureTryOut> (the pyside bump that is)
2025-11-14 11:51:54 <achill> if you also bump the pkgrel the builder will pick it up
2025-11-14 11:52:01 <PureTryOut> ok, will do that then
2025-11-14 11:52:05 <achill> thanks!
2025-11-14 11:59:22 <PureTryOut> I didn't realize we were in a feature freeze btw, I seem to have missed that memo 🤔
2025-11-14 12:00:02 <achill> i guess its more of a "core packages freeze" like the toolchain, but, yeah, maybe qt is part of it
2025-11-14 12:21:46 <PureTryOut> ok pyside6 builds with Qt 6.10 now. aarch64 at least passed, so builder is unblocked
2025-11-14 12:46:55 <ncopa> sorry about not clearly communicate the feature freeze
2025-11-14 12:47:08 <ncopa> ... clear enough
2025-11-14 12:47:25 <ncopa> how should that be communicated best?
2025-11-14 12:47:43 <ncopa> thanks for following it up
2025-11-14 12:47:51 <achill> i like the gitlab notifcations on the top
2025-11-14 12:52:37 <PureTryOut> Yeah those are pretty good. We have to go through GitLab to do things anyway so it's hard to miss
2025-11-14 13:00:18 <qaqland> have a question, why we drop qt5 so quickly, there are still some many packages depends on gtk2
2025-11-14 13:03:50 <PureTryOut> GTK2 is not my responsibility, Qt5 is
2025-11-14 13:03:56 <PureTryOut> also idk if GTK2 is EOL yet, Qt5 definitely is
2025-11-14 13:04:33 <PureTryOut> quick search reveals gtk2 being EOL since 2020, so then yes it should also get dropped
2025-11-14 13:05:45 <Noisytoot1> HexChat still relies on GTK2
2025-11-14 13:11:01 <PureTryOut> afaik HexChat is unmaintained upstream since quite a while though
2025-11-14 13:35:09 <Sertonix[m]> I have been thinking about having a public list about all the packages with unmaintained/EOL/deprecated upstream to check which ones we really want
2025-11-14 14:07:34 <PureTryOut> Is such a list maintainable though? It's not like there is a single way for devs to mark stuff as unmaintained
2025-11-14 14:10:44 <jvvv> perhaps such a list could be invented
2025-11-14 14:14:28 <PureTryOut> But often individuals dropping support for their software can't be bothered to notify people about that, so I don't really see how that could be done automatically
2025-11-14 14:15:59 <jvvv> oh, automagically, well no, probably not with any consistency. though any list, even if manually created/maintained would be helpful i think
2025-11-14 14:16:43 <PureTryOut> yeah I suppose. Could at least be crowd-sourced
2025-11-14 14:17:59 <jvvv> true
2025-11-14 14:26:47 <invoked> there's a lot of things (i'll just randomly pick one: heirloom-doctools) which are just 'finished software' and will go years between any updates.
2025-11-14 14:28:25 <jvvv> a good point and i think such software should not be on this kind of list
2025-11-14 14:30:36 <invoked> i think the list is a good idea, but the idea of EOL seems fuzzy to me
2025-11-14 14:33:40 <navi> i didn't testing yet, and is a PoC (because seems fragile) but might be interesting for alpine: https://github.com/OpenRC/openrc/pull/948
2025-11-14 14:37:15 <Sertonix[m]> invoked: I wouldn't intend to include finished software but it is definetly fuzzy
2025-11-14 14:39:01 <invoked> navi: fwiw sysconf is posix, not that such things matter anymore :)
2025-11-14 14:39:36 <navi> that's sysctl, not sysconf?
2025-11-14 14:39:44 <invoked> same thing
2025-11-14 14:39:49 <navi> no...?
2025-11-14 14:39:54 <navi> sysconf queries system variables
2025-11-14 14:39:59 <navi> sysctl sets kernel parameters
2025-11-14 14:41:13 <invoked> i'm thinking they were joined at the hip.  (i'm not looking this up, sorry)
2025-11-14 14:42:07 <navi> by all i know they're not, really, and sysctl is not in posix nor any standard i know of
2025-11-14 14:45:36 <invoked> you're probably correct. and i've gone senile
2025-11-14 14:50:12 <jvvv> navi: alpine's sysctl rc script does not use 'sysctl --system': https://git.alpinelinux.org/aports/tree/main/openrc/sysctl.initd
2025-11-14 14:50:39 <navi> yes, busybox's sysctl (and now toybox's too) do not support it
2025-11-14 14:51:01 <navi> the idea is to have a path in the upstream script that doesn't require it
2025-11-14 14:51:31 <navi> i just don't know yet if what i'm trying there is reasonable or stupid //
2025-11-14 14:53:06 <jvvv> right, i see what you are getting at. looks reasonable at a glance. a moment and i'll try it out.
2025-11-14 15:14:57 <jvvv> navi: i've a couple nits
2025-11-14 15:15:52 <navi> u can leave them in the issue if you'd like, or just tell me here
2025-11-14 15:15:58 <navi> s/issue/pr
2025-11-14 15:16:01 <jvvv> busybox throws error even with the '-q' switch, so a ' > /dev/null 2>&1' would be nice
2025-11-14 15:19:58 <jvvv> adding something like '[ "$f" = "/etc/sysctl.d/*.conf" ] && break' to the start of the loop @ line 75 would also silence another unnecessary warning (sysctl: /etc/sysctl.d/*.conf: No such file or directory                         [ ok ])
2025-11-14 15:21:23 <navi> noted
2025-11-14 15:25:04 <jvvv> otherwise, seems good to me. i can add comment to the PR if you would like. up to you.
2025-11-14 15:30:57 <navi> i made local notes so it's fine
2025-11-14 15:30:59 <navi> i'll push v2 in a moment
2025-11-14 18:46:16 <Ariadne> re: openblas failure on ppc64
2025-11-14 18:46:27 <Ariadne> i just noticed the failing testname is referencing AVX
2025-11-14 18:46:38 <Ariadne> most likely we need to skip this test on non-x86
2025-11-14 18:58:56 <Ariadne> oh i see, tests were already disabled on ppc64, and upstream has "helpfully" changed the behavior of the "all" target.  so when we do the ILP64 build, it runs the broken tests.
2025-11-14 19:05:08 <ikke> that explains why it still fails while the checks had been disabeld
2025-11-14 19:05:22 <ikke> Ariadne: checksum is missing for the patch file
2025-11-14 19:05:38 <Ariadne> yes, i did it on purpose to ensure the builder wasn't serving me cached logs :P
2025-11-14 19:05:41 <ikke> ah
2025-11-14 19:06:38 <Ariadne> we really need better build infrastructure :D
2025-11-14 19:11:11 <quinq> Always :D
2025-11-14 19:59:58 <realroot[m]> I'm updating on edge I can't install nehko makedeps caue of blender
2025-11-14 20:00:54 <realroot[m]> qt6ct needs to be rebuilt
2025-11-14 20:01:25 <realroot[m]> ERROR: unable to select packages:
2025-11-14 20:01:25 <realroot[m]>   openexr-libiex-3.4.2-r0:
2025-11-14 20:03:29 <Biswa96[m]> alpine container can be used to build packages to prevent cluttering host system. 
2025-11-14 20:31:06 <Ariadne> use `abuild rootbld` when building packages, actually.
2025-11-14 20:32:27 <achill> that would be https://gitlab.alpinelinux.org/alpine/tsc/-/issues/33
2025-11-14 20:33:11 <Ariadne> no.  tsc#33 is about making the *builders* use rootbld.
2025-11-14 20:34:30 <Ariadne> which is *not* superceded by tsc#82 btw
2025-11-14 23:52:56 <omni> I'm glad that the pyside6 aport got sorted in a way (I tested clicking around a bit in freecad without issues) and that we didn't have do revert the Qt 6.10 upgrade
2025-11-14 23:59:01 <omni> and wrt feature freeze - I start to think about it around when the builders begin the builds for the next release and from then try to take more care with the master branch/edge until there's a new release branch
2025-11-14 23:59:12 <omni> (this is how I reason about this)
2025-11-14 23:59:49 <omni> then ncopa said at (at least) one point recently that we're at feature freeze
2025-11-15 00:02:43 <omni> it might actually have been before I did the rust upgrade (thank you to those who helped, commented and gave valuable input), that I still wanted in but took extra precautions to try to make sure that it wouldn't break anything (like testing rebuilds of all rust aports in main/ and a few in community/ (and even in testing/))
2025-11-15 00:04:01 <omni> I did get a bit worried when I saw the "community/chromium: fix build with rust 1.91" MR, but then saw that it was just about removing a couple of pre 1.91 patches
2025-11-15 00:07:06 <omni> and obviously we're still doing other upgrades, but aports/projects with larger potential impact (with a lot of dependants) should be handled with care and possibly be skipped for the looming release
2025-11-15 00:12:50 <omni> I also consider there to be some leeway with community/ as long as no builder has moved past building main/ (again, my own reasoning about this)
2025-11-15 00:14:12 <omni> but if you start introducing too radical changes after the release builds have started, you may miss things with aports that are already built but wouldn't with these new changes
2025-11-15 00:15:31 <omni> and isn't one of the aims with the release builds to try to have as much of a clean bootstrap build as possible?
2025-11-15 00:21:29 <omni> ncopa: perhaps "feature freeze" could be communicated in /topic? (and gitlab message?)
2025-11-15 07:12:26 <Biswa96[m]> could anyone explain this CI error please? https://gitlab.alpinelinux.org/Biswa96/aports/-/pipelines/378658/failures
2025-11-15 07:55:17 <realroot[m]> I see build-edge-x86_64 idle shouldn't it rebuild testing?
2025-11-15 07:55:43 <realroot[m]> qt apps need to be rebuilt
2025-11-15 08:06:54 <ncopa> Ariadne: could you please help and have a look at the openrc upgrade? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/91552
2025-11-15 08:08:04 <ncopa> i would prefer if we dropped the custom patch for now, til it got accepted upstream, but im also ok with a rebase
2025-11-15 08:10:00 <Ariadne> just drop it
2025-11-15 08:13:52 <ncopa> 👍
2025-11-15 08:35:23 <Ariadne> the context is that i worked at a startup that made a networking OS based on alpine, but instead of running services in VRFs in the host namespace, we switched to using containers to launch openrc sub-instances
2025-11-15 08:36:14 <Ariadne> so it is obsolete :p
2025-11-15 09:05:23 <navi> i might still look at vrf support itself when looking into namespaced services support
2025-11-15 09:05:32 <navi> but it's good to know there's no big rush
2025-11-15 09:07:14 <Newbyte> Do you have any idea why it might be that abuild cannot fetch https://source.puri.sm/Librem5/librem5-base/-/archive/pureos/69pureos2/librem5-base-pureos-69pureos2.tar.gz both in postmarketOS CI and locally on my PC?
2025-11-15 09:07:19 <Newbyte> I can fetch it just fine via Firefox
2025-11-15 09:08:07 <ncopa> Can you fetch it with busybox wget? curl?
2025-11-15 09:09:03 <ncopa> What is the exact error message?
2025-11-15 09:09:46 <Newbyte> Seems like it fails with BusyBox wget but succeeds with Curl
2025-11-15 09:10:04 <ikke> bb wget does not set a UA, maybe that's the issue?
2025-11-15 09:10:18 <Newbyte> wget: can't connect to remote host: Connection refused
2025-11-15 09:10:43 <ncopa> Could ssl related
2025-11-15 09:10:58 <Newbyte> GNU wget works too
2025-11-15 09:11:36 <ncopa> My guess is that it is ssl_client failing
2025-11-15 09:12:07 <ncopa> Can you create an issue?
2025-11-15 09:12:13 <ikke> connection refused sounds like it happens even before ssl_client would matter?
2025-11-15 09:12:25 <ncopa> Could be
2025-11-15 09:12:30 <Newbyte> ncopa: In abuild? 
2025-11-15 09:12:45 <ncopa> No, in busybox wget
2025-11-15 09:12:45 <ikke> I guess aports if it's bb wget that as the issue
2025-11-15 09:13:21 <ncopa> Can you also strace it and paste the output in the issue
2025-11-15 09:14:31 <ncopa> You car work around it by installing curl. IIRC a build will use curl if available and fall back to wget
2025-11-15 09:16:52 <Newbyte> ncopa: Would that be at https://bugs.busybox.net/?
2025-11-15 09:17:48 <Newbyte> It seems like busybox.net is down
2025-11-15 09:17:52 <ikke> If only that would work
2025-11-15 09:17:58 <ikke> yeah, for ages
2025-11-15 09:18:03 <ikke> I guess it's scraped to death
2025-11-15 09:18:54 <Newbyte> Okay, so aports issue then?
2025-11-15 09:19:39 <ikke> Or the mailing list, not sure
2025-11-15 09:23:25 <Newbyte> ikke: BusyBox mailing list you mean?
2025-11-15 09:23:31 <ikke> yes
2025-11-15 09:24:00 <Newbyte> https://busybox.net/lists.html is down. Where do I send my email?
2025-11-15 09:24:12 <ikke> https://lists.busybox.net/mailman/listinfo
2025-11-15 09:27:23 <ikke> Newbyte: busybox wget https://source.puri.sm/Librem5/librem5-base/-/archive/pureos/69pureos2/librem5-base-pureos-69pureos2.tar.gz works for me
2025-11-15 09:27:37 <Newbyte> curious
2025-11-15 09:27:48 <Newbyte> which version of BusyBox?
2025-11-15 09:28:00 <ikke> BusyBox v1.37.0 (2025-10-07 13:42:21 UTC) multi-call binary.
2025-11-15 09:28:42 <Newbyte> Mine has a slightly newer build date but otherwise it's the same version
2025-11-15 09:28:44 <Arnavion> I get connection refused also, with the same version as ikke   >Connecting to source.puri.sm ([2a01:4ff:f0:a4b6::1]:443)   >wget: can't connect to remote host: Connection refused
2025-11-15 09:29:06 <ikke> ipv6
2025-11-15 09:29:10 <Newbyte> https://gitlab.postmarketos.org/postmarketOS/pmaports/-/jobs/1451090
2025-11-15 09:29:11 <Newbyte> It happens in our CI too
2025-11-15 09:29:27 <ikke> Yeah, fails for me with ipv6
2025-11-15 09:29:29 <Newbyte> ikke: You don't have IPv6?
2025-11-15 09:29:33 <Newbyte> Oh I see
2025-11-15 09:29:36 <ikke> Not in the container I was testing it in
2025-11-15 09:29:42 <Arnavion> busybox wget doesn't seem to have a flag for forcing v4 it seems
2025-11-15 09:29:50 <Arnavion> Let me block it at network layer to force it to fallback
2025-11-15 09:29:56 <Newbyte> Okay, good to know
2025-11-15 09:29:57 <ikke> It does not implement happy eyeballs
2025-11-15 09:30:07 <Arnavion> Okay, /etc/hosts then
2025-11-15 09:30:09 <Newbyte> happy eyeballs?
2025-11-15 09:30:21 <ikke> Newbyte: try both ipv6 and ipv4 and use which works
2025-11-15 09:30:32 <ikke> (with a small delay for ipv4 to prefer ipv6)
2025-11-15 09:30:59 <Arnavion> Yes, v4 works. v6 fails
2025-11-15 09:31:05 <Arnavion> So it must be misconfiguration on their end
2025-11-15 09:31:09 <ikke> yes
2025-11-15 09:31:22 <ikke> they publish AAAA records, but nothing is listening
2025-11-15 09:31:36 <ikke> or firewall
2025-11-15 09:32:02 <Newbyte> Why does Curl and GNU wget work then?
2025-11-15 09:32:20 <Arnavion> They fallback to v4
2025-11-15 09:32:26 <Arnavion> Do curl -6 and you'll get the same error
2025-11-15 09:33:00 <ikke> https://tpaste.us/PQDe 
2025-11-15 09:33:29 <ikke> curl (and I assume gnu wget) do implement happy eyeballs
2025-11-15 09:33:37 <Arnavion> With -vvvv you'll also see curl's logs about happy eyeballs   >01:33:09.544313 [0-0] == Info: connect to 2a01:4ff:f0:a4b6::1 port 443 from 2001:470:e965:2::2 port 44566 failed: Connection refused
2025-11-15 09:41:40 <Newbyte> I sent Purism support an email about this, I guess we'll see how it goes
2025-11-15 09:55:46 <socksinspace> have any of you folks that worked on/played with slow "legacy" architectures tried setting up package builds with distcc?
2025-11-15 09:56:38 <skarnet> Arnavion: the decision to prioritize v4 over v6 is made... at compile-time, in busybox
2025-11-15 09:56:47 <skarnet> that's certainly a design choice
2025-11-15 09:56:50 <skarnet> but it is what it is
2025-11-15 09:57:19 <ikke> skarnet: apparently it prefers v6 over v4, which is why it fails
2025-11-15 09:57:55 <skarnet> yes
2025-11-15 09:58:10 <skarnet> because Alpine does not set that switch in its bb configuration when building it
2025-11-15 09:58:19 <skarnet> which is sane
2025-11-15 09:58:25 <ikke> yes
2025-11-15 09:58:57 <ikke> Doesn't bb just rely on what gai (or similar) returns?
2025-11-15 10:01:39 <skarnet> apparently not, results are sorted by v4/v6 as well
2025-11-15 10:01:58 <ikke> ah ok
2025-11-15 10:58:37 <tw_> hey!
2025-11-15 11:38:56 <ncopa> hi
2025-11-15 11:39:29 <ncopa> Sertonix[m]: I wonder if you can help me to mark the abuild MRs that needs to be included for alpine 3.23
2025-11-15 11:39:54 <ncopa> MRs and issues that needs to be merged/solved for alpine 3.23
2025-11-15 11:40:23 <ncopa> im working on setting up so you can set milestones in abuild project
2025-11-15 18:26:26 <realroot[m]> i tried to build qt-creator but it fails
2025-11-15 18:50:29 <funderscore> how does it fail?
2025-11-16 00:16:17 <AafreightServices[m]> https://t.me/hightimes_ukmarket/54
2025-11-16 11:07:59 <telmich> After running merge-usr, which had conflics, I cannot run apk anymore: apk del merge-usr returns ERROR: Unable to lock database: Symbolic link loop
2025-11-16 11:08:26 <telmich> lrwxrwxrwx 1 root root 25 Nov 16 12:02 /usr/lib/apk/db/installed -> /usr/lib/apk/db/installed
2025-11-16 11:08:27 <telmich> This seems to be the culprit
2025-11-16 11:08:53 <telmich> Same for: lrwxrwxrwx 1 root root 20 Nov 16 12:02 /usr/lib/apk/db/lock -> /usr/lib/apk/db/lock
2025-11-16 11:10:35 <telmich> Deleting the lock and the broken installed link results into: `apk fix apk` -> `ERROR:`` Package 'apk' not found`
2025-11-16 11:10:51 <telmich>  apk update does succeed though
2025-11-16 11:11:37 <telmich> apk fix apk-tools results into usr_merge_nag.sh: execve: Symbolic link loop
2025-11-16 11:12:05 <telmich> lrwxrwxrwx 1 root root 44 Nov 16 12:02 /usr/lib/apk/commit_hooks.d/usr_merge_nag.sh -> /usr/lib/apk/commit_hooks.d/usr_merge_nag.sh
2025-11-16 11:12:36 <telmich> rm /usr/lib/apk/commit_hooks.d/usr_merge_nag.sh -> makes apk fix apk-tools work
2025-11-16 11:13:11 <telmich> Now running apk info | xargs  apk fix
2025-11-16 11:16:06 <telmich> For many packages I get an info/error message like ( 660/1836) [APK unavailable, skipped] Reinstalling electron (36.8.1-r1)
2025-11-16 11:18:38 <ikke> telmich: ouch, could you open an issue for it?
2025-11-16 11:20:48 <telmich> ikke: in https://gitlab.alpinelinux.org/alpine/apk-tools ?
2025-11-16 11:24:18 <telmich> it's getting more strange...
2025-11-16 11:24:59 <telmich> I did an apk upgrade -aU before merge-usr. Now after I finished the pk info | xargs  apk fix, a lot of old packages seem to be there. The same apk upgrade -aU is installing 921 packages
2025-11-16 11:31:27 <ikke> telmich: in alpine/aports
2025-11-16 14:09:41 <Sertonix[m]> ncopa: https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/459 and https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/457 would be good for stable. I am also considering to remove the /usr-merge logic for the stable release due to the issues mentioned in  https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/447
2025-11-16 14:15:54 <Sertonix[m]> socksinspace: I never tried distcc. I mainly use ccache to be able to speed up restarting failed builds. I tried sccache (for rust only) and it just made things slower. I am working on a tool which may be able to distribute builds on the aports level but networking may make things slower.
2025-11-16 14:21:19 <socksinspace> Sertonix[m]: i was planning to use it with cross compilers, to not be slowed down as much by qemu, as far as i understand it, plain distcc just "outsources" the CC part, while configure, preprocessing and linking would happen on the "correct" machine, so it should work around some of the issues one would normally have with cross compilation
2025-11-16 14:23:11 <socksinspace> i'll see if i can get to work once i buildrepo has built distcc and the toolchain parts
2025-11-16 15:19:19 <invoked> good luck. cross is fiddly enough as it is. with gentoo i used distcc+ccache a lot (this was 20+ years ago) and while it worked most of the time just for x86, i never got it to a state where i could just walk away and let it bootstrap a new system.
2025-11-16 16:38:14 <socksinspace> yeah, there is a distinct chance of it not working, but if i can avoid the waste of power and time i have from building in qemu, that would be worth it
2025-11-16 19:47:35 <ayakael> Heads up, I'm almost done with dotnet10 aport, now that it was released a few days ago: !92484 
2025-11-16 19:48:12 <ayakael> I would like to target it for v3.23.
2025-11-16 21:59:14 <ayakael> !92484 now ready for review.
2025-11-17 10:53:48 <qaqland> does aports have https://www.sphinx-doc.org/en/master/usage/extensions/graphviz.html#module-sphinx.ext.graphviz ?
2025-11-17 12:09:33 <fabricionaweb> dont abump supports rootbld?
2025-11-17 12:11:38 <fabricionaweb> maybe if I set the $ABUILD_OPTS
2025-11-17 12:15:36 <fabricionaweb> https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abump.in?ref_type=heads#L148
2025-11-17 12:31:40 <maribu> I wonder if someone of the core team wants to take over the maintainer role of `intel-ucode`? I think that package has become relevant enought that it is a bit odd that I have that role. Also, with returning my Intel based work machine to my former employer, the most recent Intel CPU I have at hands is a Core 2 Duo. I cannot really do much debugging of issues with that :D
2025-11-17 12:43:55 <ncopa> Sertonix[m]: will https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/459 require rebuild of packages?
2025-11-17 12:53:20 <Sertonix[m]> The only noticable effect of rebuilding would be to clean up apk dot --errors. So I don't think we need to unless someone complains
2025-11-17 13:12:33 <ncopa> ok
2025-11-17 14:16:52 <jahway603[m]> Can I get !93192 merged? It fixes Issue #17711.
2025-11-17 14:29:56 <jahway603> Can I get !93192 merged? It fixes Issue #17711.
2025-11-17 14:39:45 <jahway603> ikke, how do I check what other aports packages depend on py3-typing-extensions so that I can determine if there are any potential backwards incompatible changes by upgrading it? is there a way to do this with apk?
2025-11-17 14:48:07 <ikke> jahway603: we should not only think about dependencies from aports 
2025-11-17 15:54:19 <achill> test
2025-11-17 15:55:01 <liske> \o/
2025-11-17 16:01:28 <clandmeter> test fail
2025-11-17 16:02:04 <achill> yay bridge up again
2025-11-17 16:15:11 <fabricionaweb> my abuild is faliing now, ERROR: /usr/lib/ld-musl-x86_64.so.1: Could not find owner package, any idea?
2025-11-17 16:18:54 <ikke> https://pkgs.alpinelinux.org/contents?file=ld-musl-x86_64.so.1&path=&name=&branch=edge&repo=&arch=
2025-11-17 16:19:04 <ikke> Are you on a usr-merged system?
2025-11-17 16:19:55 <achill> fabricionaweb: thats !90642 i think
2025-11-17 16:20:10 <fabricionaweb> yes I am
2025-11-17 16:20:29 <fabricionaweb> bot is :bed: 
2025-11-17 16:20:33 <fabricionaweb> 🛏️
2025-11-17 16:20:54 <ikke> !90642
2025-11-17 16:26:40 <ikke> So:
2025-11-17 16:26:42 <ikke> export CFLAGS="$CFLAGS -DLIBC_SO=\\\"libc.musl-$CARCH.so.1\\\""
2025-11-17 16:26:44 <ikke> export CXXFLAGS="$CXXFLAGS -DLIBC_SO=\\\"libc.musl-$CARCH.so.1\\\""
2025-11-17 16:26:46 <ikke> ?
2025-11-17 16:40:54 <skarnet> s/libc\./ld-/ ?
2025-11-17 16:42:15 <fabricionaweb> I mean, sorry should I try it?
2025-11-17 16:42:29 <ikke> That's what that closed MR changed (among others)
2025-11-17 16:42:38 <ikke> I have no idea if that's the proposed fix or not
2025-11-17 17:28:12 <Sertonix[m]> Are you trying to build on edge or stable?
2025-11-17 17:30:14 <Sertonix[m]> The issue is supposed to be fixed already so the question is if you are not using the latest version of something or if the fix didn't work.
2025-11-17 18:26:41 <fabricionaweb> it is edge
2025-11-17 19:40:53 <jahway603[m]> Can I please get !93202 merged?
2025-11-17 20:41:41 <ncopa> i think we should try get the builders complete 3.23 this week so we get the rc1 out
2025-11-17 20:41:49 <ncopa> we need to tag the release next week
2025-11-17 20:42:08 <ncopa> ppc64le is behind
2025-11-17 20:42:09 <ikke> There are still some packages blocking things
2025-11-17 20:42:20 <ncopa> can we delete them? :)
2025-11-17 20:42:36 <ikke> fine with me ;-)
2025-11-17 20:43:11 <ncopa> we should probably start with notifying the maintainers
2025-11-17 20:43:17 <ikke> We should create issues for them and assign them to the maintainer
2025-11-17 20:43:19 <ikke> hah
2025-11-17 20:43:34 <ncopa> py3-dask has blocked ppc64le for 2 days
2025-11-17 20:43:40 <ikke> ouch
2025-11-17 20:43:52 <ncopa> i feel for disabling it on ppc64le as punishment
2025-11-17 20:43:54 <ikke> We should probably also look at open vulnerabilities
2025-11-17 20:44:32 <ncopa> yeah, i saw you had a stab at gnutls
2025-11-17 20:44:49 <ikke> yes
2025-11-17 20:45:02 <ncopa> samba also need fix. tevent fails in tests in CI, but I havent been able to reproduce it
2025-11-17 20:45:11 <ncopa> we should report it upstream
2025-11-17 20:45:50 <ikke> I have been working on security.a.o to make it a bit more usefull
2025-11-17 20:45:57 <ikke> small steps
2025-11-17 20:46:28 <ncopa> i had a look at tevent test code the other day, and it tests setting a hook and then execute run_once something (run a single iteration of the eventloop). but apparently it never fire the hook
2025-11-17 20:46:36 <ncopa> thats very helpful
2025-11-17 20:46:43 <ikke> anoying
2025-11-17 20:46:47 <ikke> only in CI?
2025-11-17 20:46:56 <ncopa> afaik yes
2025-11-17 20:47:04 <ncopa> i tried to reproduce in docker
2025-11-17 20:47:09 <ncopa> but failed
2025-11-17 20:47:21 <ikke> Did you try build-base image?
2025-11-17 20:47:28 <ikke> Not sure if it would make any difference
2025-11-17 20:48:20 <ncopa> IIRC i tried that as well
2025-11-17 20:48:54 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/92842 and https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/81034'
2025-11-17 20:49:43 <ncopa> I was tempted to merge it anyway with the excuse that test was flaky, but since this consistently happens in CI it may be a real bug
2025-11-17 20:50:10 <ikke> "System library tevent of version 0.16.2 not found, and bundling disabled"
2025-11-17 20:50:12 <ikke> this?
2025-11-17 20:50:58 <ncopa> also this https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/90421
2025-11-17 20:51:18 <Ariadne> i am working on libsmbios
2025-11-17 20:51:23 <Ariadne> i just fixed libfprint
2025-11-17 20:51:38 <ncopa> ikke: no. its: failure: test_trace_event_fd__free_in_handler [
2025-11-17 20:51:38 <ncopa> ../../tests/test_tevent_trace.c:529: error: Failure!
2025-11-17 20:51:38 <ncopa> ]
2025-11-17 20:51:38 <ncopa> tctx->before_handler
2025-11-17 20:51:47 <ikke> right
2025-11-17 20:51:51 <ncopa> Ariadne: thanks alot!
2025-11-17 20:52:01 <ncopa> really appreciate your help
2025-11-17 20:53:05 <ncopa> someone helping report samba/tevent issue? can be reported here: https://bugzilla.samba.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&field0-0-0=product&field0-0-1=component&field0-0-2=alias&field0-0-3=short_desc&field0-0-4=status_whiteboard&field0-0-5=content&list_id=52313&order=c
2025-11-17 20:53:05 <ncopa> hangeddate%20DESC%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id&query_format=advanced&type0-0-0=substring&type0-0-1=substring&type0-0-2=substring&type0-0-3=substring&type0-0-4=substring&type0-0-5=matches&value0-0-0=tevent&value0-0-1=tevent&value0-0-2=tevent&value0-0-3=tevent&value0-0-4=tevent&value0-0-5=%22tevent%22
2025-11-17 20:54:01 <ncopa> it happens on all architectures and in CI only. I havent been able to reproduce in LXC, or in docker or anything
2025-11-17 20:54:22 <Ariadne> ...strange
2025-11-17 20:54:40 <Ariadne> let me fix smbios and i will dig into this tevent issue
2025-11-17 20:54:45 <Ariadne> i suspect the test is flawed
2025-11-17 20:55:32 <ncopa> i dunno. the test did look ok when I looked at it
2025-11-17 20:55:49 <ncopa> really tricky when you cant repro
2025-11-17 20:59:03 <ncopa> what happened with opencv deps? https://build.alpinelinux.org/buildlogs/build-3-23-loongarch64/community/opencv/opencv-4.12.0-r3.log
2025-11-17 21:01:05 <ikke> vtk6-dev?
2025-11-17 21:02:57 <ncopa> dunno. it builds in rootbld in edge
2025-11-17 21:04:44 <ikke> something pulls in vtk-dev, which needs ffmpeg6-dev
2025-11-17 21:05:58 <ikke> opencv itself
2025-11-17 21:07:10 <ikke> It also fails on x86_64
2025-11-17 21:07:14 <ikke> not just loongarch
2025-11-17 21:09:19 <Ariadne> if opencv wants ffmpeg7 and vtk wants ffmpeg6, it is going to be a problem
2025-11-17 21:09:37 <ncopa> e96c38ed4d4ceee8a03aec3a8a0bd8c3e84f4fb6 didnt bump pkgrel
2025-11-17 21:10:15 <Ariadne> that would do it
2025-11-17 21:10:33 <ncopa> yeah
2025-11-17 21:10:49 <ncopa> but does vtk need ffmpeg6?
2025-11-17 21:11:13 <Ariadne> my assumption is: probably
2025-11-17 21:12:33 <Ariadne> lucene++ seems busted universally
2025-11-17 21:12:38 <ncopa> ha
2025-11-17 21:13:47 <ncopa> time for bed. thanks!
2025-11-17 21:22:09 <Ariadne> testing if vtk builds with upstream ffmpeg
2025-11-17 21:24:33 <ncopa> it passed, but I dont know if it skipped ffmpeg
2025-11-17 21:24:44 <ncopa> didnt link to anything ffmpeg at least
2025-11-17 21:27:01 <Ariadne> indeed...
2025-11-17 21:27:07 <Ariadne> why then is this -dev here
2025-11-17 21:28:54 <Ariadne> the only thing referencing ffmpeg is a cmake macro
2025-11-17 21:29:27 <Ariadne> -rw-r--r-- root/root      6275 2025-11-17 13:21 usr/lib/cmake/vtk-9.3/FindFFMPEG.cmake
2025-11-17 21:29:33 <Ariadne> this macro, it seems
2025-11-17 21:30:35 <Ariadne> ncopa: imo we should drop ffmpeg-dev as dependency here
2025-11-17 21:30:56 <Ariadne> testing that in rootbld
2025-11-17 21:31:41 <Ariadne> my guess is that at one point, vtk used ffmpeg, but no longer
2025-11-17 21:37:40 <Ariadne> ah... it is optional feature, which we have never enabled anyway.
2025-11-17 21:42:43 <ikke> Trying to run a failing c test program with pdb, but even if I set the breakpoint to main, when I run it, it exits with an error code, any idea?
2025-11-17 21:42:55 <ikke> [Inferior 1 (process 67293) exited with code 01]
2025-11-17 21:43:26 <ikke> https://tpaste.us/meDx 
2025-11-17 21:48:16 <Ariadne> br main
2025-11-17 21:48:36 <Ariadne> oh you did that
2025-11-17 21:48:38 <ikke> yeah
2025-11-17 21:48:40 <Ariadne> that's weird...
2025-11-17 21:48:48 <Ariadne> try br __libc_start_main
2025-11-17 21:49:16 <Ariadne> i may have fixed lucene++
2025-11-17 21:49:29 <ikke> It gets a few steps and then exits
2025-11-17 21:49:35 <ikke> 92      in src/env/__libc_start_main.c
2025-11-17 21:50:49 <Ariadne> can you tpaste the full log
2025-11-17 21:52:37 <Ariadne> lucene++ depends on undefined behavior in IndexOutputTest
2025-11-17 21:52:48 <Ariadne> i'm just going to disable the broken test
2025-11-17 21:52:50 <ikke> Ariadne: hold on, pointing gdb to musl source
2025-11-17 21:59:52 <ikke> Ariadne: ok, it works if I start from there
2025-11-17 21:59:58 <ikke> for some reason
2025-11-17 22:06:10 <ikke> It exits if I next over __libc_start_init(); If I step in it, and then return, it continues
2025-11-17 22:06:14 <ikke> (in gdb)
2025-11-17 22:14:18 <Sertonix[m]> Maybe it's some tail call optimization which is messing with gdb?
2025-11-17 22:14:40 <Sertonix[m]> I think I have seen such issues too
2025-11-17 22:43:26 <Ariadne> this digikam thing is lolsob
2025-11-17 22:46:48 <ikke> ok, seems like I just need to add brotli-dev and zstd-dev 
2025-11-17 22:48:45 <ikke> Finally! PASS: system-override-compress-cert.sh
2025-11-17 22:48:58 <ikke> and just because it does not give any error output
2025-11-17 22:49:10 <ikke> (apparently only when enabling debug somehow)
2025-11-17 22:49:28 <ikke> I had to debug through the code to find out that it did not know about those compression methods
2025-11-17 22:49:37 <ikke> which are apparently hardcoded in the tests
2025-11-17 22:51:48 <ikke> lesigh: FAIL: certtool.sh
2025-11-17 22:58:17 <ikke> LOL: https://gitlab.alpinelinux.org/alpine/aports/-/blob/4a60f9a48d61331899598f29adb027db5231d9fa/main/gnutls/tests-certtool.patch
2025-11-17 23:08:29 <ikke> double sigh
2025-11-17 23:08:39 <ikke> ktls tests still fail on 32-bits platforms :-/
2025-11-17 23:11:15 <ikke> I give up
2025-11-17 23:16:17 <Ariadne> just disable tests on gnutls
2025-11-17 23:16:29 <Ariadne> i give up on git-branchable
2025-11-17 23:16:36 <Ariadne> er, branchless
2025-11-17 23:18:47 <Ariadne> i think i am done for today with NMUs, this git-branchless thing annoyed me
2025-11-18 07:26:38 <ncopa> thanks!
2025-11-18 07:26:58 <ncopa> seems like py3-fastapi deadlocks on all arm
2025-11-18 07:32:07 <ncopa> i restarted them
2025-11-18 09:59:26 <ncopa> nemo-qml-plugin-systemsettings does not build with timed built against qt6
2025-11-18 10:00:08 <ncopa> we need to either buildtimed with both qt6 and qt5, or we disable timed from nemo-qml-plugin-systemsettings, or we nuke it
2025-11-18 10:04:30 <ncopa> PureTryOut: can we nuke nemo-qml-plugin-systemsettings? it requires timed-qt5 that we no longer support since e8ca5fbdcf27e24734a82204e608679cfba4cd25
2025-11-18 10:39:51 <lotheac> i've been wondering why we even have those sailfishos nemo* packages, my impression was they are not useful outside of sailfish
2025-11-18 10:40:20 <lotheac> but maybe i'm mistaken
2025-11-18 14:38:02 <PureTryOut> ncopa: we can not, things depend on it. or well we can, but then we'd have to disable those things. Sadly simply reverting the upgrade which would be my preference doesn't mean it'll build it seems...
2025-11-18 14:38:25 <PureTryOut> lotheac: you can `grep -r nemo-` and see what depends on it. We ship AsteroidUI which is based on large portions of the SailfishOS stack
2025-11-18 14:39:39 <lotheac> ah, okay. well that was lazy on my part :)
2025-11-18 15:41:03 <ncopa> so we need to add a timed-qt5 package something
2025-11-18 16:28:01 <ncopa> everything that depends on timed uses qt5
2025-11-18 16:50:06 <PureTryOut> Yeah it needs to be qt5, but like I said simply reverting the commit that made it qt6 doesn't work, it doesn't currently compile
2025-11-18 19:35:32 <PureTryOut> I think I'll just disable AsteroidUI for now. timed has always been a pain and it is now. Hopefully upstream can move it all to Qt6 at some point
2025-11-18 20:31:47 <AkatsukiLevi> Heya!
2025-11-18 20:33:38 <AkatsukiLevi> So, the aports-qa-bot has just told me that my MR(testing/fchat-horizon) went into stale due to some lack of updates on it (actually my fault), but just pushed a update to the 1.35.0 version (and i just saw CI failed cuz the path to the icon is wrong lul)
2025-11-18 20:33:58 <AkatsukiLevi> But, is there any extra missing step I'm forgetting to get my package accepted into the testing branch?
2025-11-18 20:35:01 <ikke> AkatsukiLevi: Sorry about that, there is nothing you forgot. There's a bit of a queue for new packages (they take longer to review) and especially now we're more focused on getting the new release out
2025-11-18 20:35:54 <ikke> AkatsukiLevi: Don't be afraid we'll close the MRs. We won't indiscriminately close them.
2025-11-18 20:36:37 <AkatsukiLevi> No worries! I actually thought I had forgot something, and alright! No rush to get it merged up!
2025-11-18 20:37:02 <AkatsukiLevi> Also field-testing the package on my laptop to make sure everything is smooth, so it gives a bit more time to catch any runaway bug
2025-11-18 21:22:05 <ikke> ncopa: regarding gnutls, what do you think about disabling the ktls tests again, they fail on halve the arches
2025-11-18 21:23:32 <ikke> client:102: client: Error: Decryption has failed.
2025-11-18 21:24:41 <ikke> I noticed fedora has this as well: https://src.fedoraproject.org/rpms/gnutls/blob/rawhide/f/gnutls-3.8.8-tests-ktls-skip-tls12-chachapoly.patch
2025-11-18 22:20:39 <Ariadne> this weasyprint one is ugly
2025-11-18 22:23:10 <mio> !92423
2025-11-18 22:34:53 <Ariadne> auto-merge enabled
2025-11-18 22:43:00 <ikke> mergedf
2025-11-18 22:44:07 <ikke> edk2 version is anoying regarding security.a.o. We use 0.0.<date>. Upstream used <date>. and now edk2stable-<date>
2025-11-18 22:44:19 <ikke> This means all package versions we have are marked potentially vulnerable
2025-11-19 09:51:25 <fabricionaweb> Error relocating /usr/bin/node: EVP_MD_CTX_get_size_ex: symbol not found
2025-11-19 09:52:00 <fabricionaweb> getting this from a fresh edge image, seems I need to upgrade -U but I wonder if is a problem
2025-11-19 10:45:57 <ncopa> do you mix edge with stable?
2025-11-19 10:46:07 <ncopa> you need upgrade with -U -a
2025-11-19 10:46:28 <ncopa> I think this may be a problem in gcc: https://build.alpinelinux.org/buildlogs/build-3-23-armv7/community/libaec/libaec-1.1.4-r1.log
2025-11-19 10:46:37 <ncopa> it looks like it generates wrong assembly
2025-11-19 10:47:47 <ncopa> dropping -Os makes it build
2025-11-19 10:54:02 <ncopa> thats a bug in gcc for armv7
2025-11-19 11:38:00 <fabricionaweb> not mixing, just docker alpine:edge straight and install nodejs
2025-11-19 11:38:08 <fabricionaweb> ok cool, thanks!!
2025-11-19 12:00:29 <ncopa> we should update the edge image
2025-11-19 12:00:39 <ncopa> i dont remember why we didnt do so yet
2025-11-19 12:12:48 <fabricionaweb> where or how to update it? sorry if is a silly question just to get it better... 
2025-11-19 12:20:04 <ikke> ncopa: you were waiting for the builders to get idle 
2025-11-19 12:21:00 <ikke> fabricionaweb: ncopa needs to tag an edge snapshot. That will provide a minirootfs, which is then used to create a new docker base image 
2025-11-19 12:53:31 <angeloverlain[m]> is it possible to point apk to a different file than /etc/apk/world ?
2025-11-19 13:25:17 <ncopa> unlikely
2025-11-19 13:26:53 <ncopa> lxqt 2.3 is out, but i dont know if we want upgrade until after alpine 3.23
2025-11-19 15:03:32 <ncopa> anybody available to help with py3-dask? seems like there is an update but given the list of skipped tests im afraid to touch it
2025-11-19 15:03:52 <ncopa> fails on riscv64: https://build.alpinelinux.org/buildlogs/build-3-23-riscv64/community/py3-dask/py3-dask-2024.11.0-r0.log
2025-11-19 15:12:36 <raspbeguy> could someone help me understand why tests are failing on !93226 ? They are running fine on my machine
2025-11-19 15:28:21 <bl4ckb0ne> seems like a time issue? have you tried to run `abuild rootbld` on your machine?
2025-11-19 15:28:23 <bl4ckb0ne> maybe it needs net
2025-11-19 15:31:58 <quinq> Hi
2025-11-19 15:32:15 <quinq> It seems there's a bug in the net-tools package
2025-11-19 15:32:21 <quinq> $ apk info -W /usr/bin/hostname
2025-11-19 15:32:21 <quinq> ERROR: /usr/bin/hostname: Could not find owner package
2025-11-19 15:32:40 <quinq> But net-tools is correctly installed
2025-11-19 15:33:05 <quinq> (that's on edge)
2025-11-19 15:33:07 <lotheac> try /bin/hostname, could be a usr-merge thing
2025-11-19 15:33:22 <quinq> Ah, correct
2025-11-19 15:33:25 <quinq> You found the bug :)
2025-11-19 15:33:39 <quinq> I suppose it should be fixed to install in /usr/bin instead
2025-11-19 16:14:41 <Sertonix[m]> quinq: No, it is important for the /usr-merge to keep it in /bin
2025-11-19 16:18:39 <quinq> But then the default path is wrong
2025-11-19 16:18:50 <quinq> It says that the tool is in /usr/bin/hostname
2025-11-19 16:18:55 <quinq> s/in/at/
2025-11-19 18:04:39 <Ariadne> Sertonix[m]: why?
2025-11-19 18:08:33 <Sertonix[m]> The merge-usr script needs not to have conflicting binaries in /bin and /usr/bin (conflicting meaning that they refer to different binaries when resolved). Otherwise there is no universally correct way to resolve the conflict and the script will abort
2025-11-19 18:09:02 <Sertonix[m]> And busybox creates the symlink in /bin/hostname
2025-11-19 18:09:04 <Ariadne> why can't the script update the apkdb then?
2025-11-19 18:10:06 <Sertonix[m]> What would that fix?
2025-11-19 18:10:13 <Ariadne> apk audit, amongst other things
2025-11-19 18:10:57 <Sertonix[m]> It would be broken anyways just due to /bin being a symlink.
2025-11-19 18:11:10 <Ariadne> not if the apkdb is fixed
2025-11-19 18:12:56 <Ariadne> i think we are going to see a lot of feedback from usr-merged users that apk is behaving strangely due to the apkdb not matching reality
2025-11-19 18:14:28 <Sertonix[m]> So you are proposing to make apkdb not match the packages that are found on the repos? If I don't missing anything the apkdb patching would need to be re-applied after each upgrade.
2025-11-19 18:14:54 <Ariadne> i am proposing making apkdb match where the files are actually physically installed
2025-11-19 18:15:08 <Ariadne> so, yes, apk needs to be improved too
2025-11-19 18:15:37 <Sertonix[m]> But the unavoidable side effect is being inconsistent with the repositories.
2025-11-19 18:16:02 <ikke> fabled already brought that issue up
2025-11-19 18:16:12 <ikke> apk audit being broken after user merge
2025-11-19 18:16:28 <Ariadne> the .apk packages are intended to provide the files, but not necessarily the final paths on the system
2025-11-19 18:17:00 <ikke> Ariadne: hmm?
2025-11-19 18:17:23 <funderscore> it does, does it?
2025-11-19 18:17:57 <Sertonix[m]> But as I said the /bin symlink would ether show up in apk audit or be additional.
2025-11-19 18:17:57 <Ariadne> if installing a file results in the physical location of that file being different than what is in the apk, that is fine, as long as apk can deal with the discrepancy
2025-11-19 18:18:10 <funderscore> is your idea having apk recognise that e.g. /bin is a symlink to /usr/bin?
2025-11-19 18:18:27 <Ariadne> no
2025-11-19 18:18:28 <ikke> funderscore: I suppose more like a field saying what the final location is
2025-11-19 18:18:38 <Ariadne> yes
2025-11-19 18:19:01 <funderscore> So having it recognise that symlink .. basically?
2025-11-19 18:19:07 <Sertonix[m]> There is no such thing as a "final location" as soon as mount points are involved (and they are)
2025-11-19 18:19:08 <Ariadne> no
2025-11-19 18:19:33 <Ariadne> cool
2025-11-19 18:19:40 <Ariadne> well if we can't make this work, it should be reverted
2025-11-19 18:19:51 <funderscore> by which I mean "Installed to /bin/xyz, points to /usr/bin/xyz, final path = /usr/bin/xyz"?
2025-11-19 18:19:52 <Ariadne> because otherwise, we are going to get tons of these bug reports
2025-11-19 18:20:05 <Ariadne> funderscore: no
2025-11-19 18:20:10 <ikke> funderscore: more explicit
2025-11-19 18:20:21 <Ariadne> "installed to /usr/bin/xyz"
2025-11-19 18:20:27 <ikke> telling apk: file x from package y is now located at z
2025-11-19 18:20:28 <Ariadne> is all you need in apkdb
2025-11-19 18:21:06 <funderscore> and how are you going to tell that to apk?
2025-11-19 18:21:24 <Ariadne>  /lib/apk/db/installed is a text file
2025-11-19 18:21:50 <funderscore> yeah, it is, is your idea having the merge-usr script tamper with that?
2025-11-19 18:22:08 <Ariadne> "tamper" implies malice
2025-11-19 18:22:13 <ikke> It could be a new apk command
2025-11-19 18:22:38 <funderscore> Ariadne: heh, sorry, not a native english speaker at all :p
2025-11-19 18:22:46 <funderscore> I more meant 'auto-modify'
2025-11-19 18:22:58 <ikke> just modify suffices :)
2025-11-19 18:23:08 <funderscore> :)
2025-11-19 18:24:16 <Ariadne> while i appreciate the effort put into this, and see the end result as an improvement to alpine, i think this usr-merge thing was not planned properly
2025-11-19 18:24:41 <Ariadne> `apk info -W /usr/bin/hostname` still working should have been considered essential success criteria
2025-11-19 18:25:34 <Ariadne> that means the apkdb is in a broken state, and this will cause fundamental problems
2025-11-19 18:26:20 <Ariadne> for example: orphaned files not being cleaned up
2025-11-19 18:26:30 <funderscore> What is it supposed to return?
2025-11-19 18:26:52 <Sertonix[m]> Ariadne: I think the last consensus was to make sure non-/usr-merged stays possible until everything can be switchted (and the issue goes away by itself). I would much rather spend my time with something different instead of over engineering a temporary migration code or having to worry about stuff breaking due to more than 1 migration aproach being implemented at the same time. But I do agree that too many things have been broken.
2025-11-19 18:26:56 <funderscore> $ doas apk info -W /usr/bin/hostname
2025-11-19 18:26:57 <ikke> funderscore: But net-tools is correctly installed
2025-11-19 18:27:00 <funderscore> /usr/bin/hostname symlink target is owned by busybox-1.37.0-r24
2025-11-19 18:27:03 <funderscore> Seems working, no?
2025-11-19 18:27:44 <Sertonix[m]> No, cause apk -W follows symlinks and is not actually checking the path you gave it
2025-11-19 18:28:03 <Sertonix[m]> It checks ownership of /bin/busybox in your case
2025-11-19 18:28:21 <ikke> funderscore: `apk add net-tools; apk info -W /usr/bin/hostname` -> Could not find owner package
2025-11-19 18:28:37 <funderscore> right.
2025-11-19 18:29:22 <Ariadne> Sertonix[m]: i guess my point is, i would have switched the packages to use /usr and not done a manual migration step
2025-11-19 18:30:36 <Sertonix[m]> That unfortunatly doesn't work due to stuff like /lib/firmware sometimes having admin created files or mount points for good reasons)
2025-11-19 18:30:58 <Ariadne> it has worked for other distributions
2025-11-19 18:32:16 <Sertonix[m]> Yes, it may have caused less issues but there would be many issues regardless.
2025-11-19 18:34:59 <Ariadne> i think the usr-merge nag script should be disabled until this apkdb issue is resolved
2025-11-19 18:35:26 <Ariadne> we should not tell people to do this in its current state
2025-11-19 18:41:38 <Ariadne> $ apk info -W $(which fsfreeze)
2025-11-19 18:41:38 <Ariadne> ERROR: /usr/sbin/fsfreeze: Could not find owner package
2025-11-19 18:41:47 <Ariadne> yes, this is absolutely going to break people
2025-11-19 18:45:24 <Ariadne> i would ask the TSC to, you know, do something, but evidence suggests that they haven't actually met in nearly 6 months
2025-11-19 19:01:43 <invoked> imo it should be automagic. in release notes ... but no nagging, no manual intervention, it should just work(tm)
2025-11-19 19:06:07 <Ariadne> agree
2025-11-19 19:06:21 <Ariadne> but either way it shouldn't leave apkdb in this state
2025-11-19 21:49:08 <ncopa> i found out tevent issue
2025-11-19 21:49:16 <ncopa> for samba
2025-11-19 21:49:29 <ncopa> and a way to reproduce it
2025-11-19 21:49:48 <ncopa> https://bugzilla.samba.org/show_bug.cgi?id=15952
2025-11-19 21:50:09 <ncopa> we can work around it in our CI with: `make check </dev/null`
2025-11-19 21:51:59 <ncopa> TSC is sort of broken
2025-11-19 21:52:11 <ncopa> i tried to set up a meeting 3 times now
2025-11-19 22:41:52 <Ariadne> how can we fix the TSC?
2025-11-19 22:49:23 <ikke> Shift members to people who are actively involved, async decisions
2025-11-19 22:51:33 <Ariadne> i have a bunch of opinions about how alpine should evolve governance-wise
2025-11-19 22:52:21 <Ariadne> happy to outline them, they are based on talking to many people over the past couple of years :)
2025-11-19 23:11:09 <angeloverlain[m]> I, for one, would like to hear your ideas :D
2025-11-19 23:48:44 <vkrishn> Ariadne: Sertonix[m]: re: "why can't the script update the apkdb then?", <- some thoughts, https://tpaste.us/LyQl
2025-11-19 23:55:41 <invoked> quorum shouldn't be necessary to reverse on a course of action that is resulting in breakage
2025-11-20 00:27:55 <lnl> Hi, could someone merge !93247?
2025-11-20 01:19:31 <timlegge> is the x86 builder stuck?
2025-11-20 05:24:54 <ikke> timlegge: it was just idle, but not sure why it didn't continue.
2025-11-20 05:25:39 <ikke> it just failed on qt5-qtwebengine
2025-11-20 07:15:32 <Sheila> awilfox: update: going to be meeting with the person doing the VoiceOver/macOS class on the 9th for an evaluation.
2025-11-20 07:18:04 <funderscore> Sheila: Wrong channel? ;)
2025-11-20 07:18:14 <Sheila> yup, sorry.
2025-11-20 07:18:19 <funderscore> nw
2025-11-20 07:18:48 <Sheila> and also told her that *yesterday* in the *right* channel.
2025-11-20 07:19:01 <Sheila> ADHD fox is ADHD shocker, film at 11.
2025-11-20 07:20:09 <funderscore> it happens :)
2025-11-20 07:51:39 <Ariadne> lnl: gitlab is unfortunately not letting me rebase your MR
2025-11-20 11:21:12 <timlegge> Thanks ikke 
2025-11-20 12:21:29 <ncopa> Ariadne: can you help with linux-openpax? seems like there is a checksum error on riscv64 https://build.alpinelinux.org/buildlogs/build-3-23-riscv64/community/linux-openpax/linux-openpax-6.11.2-r0.log
2025-11-20 12:59:13 <ikke> ncopa: what do you think of adding a short random sleep to aports-build before running git pull. The fact that the builders all are pulling at the same time (especially for less active builders, have more to pull) is causing a high load on gitlab
2025-11-20 12:59:44 <ikke> I did switch the older stable builders to git.a.o atm
2025-11-20 13:00:18 <ikke> sleep $((RANDOM%8)); # or something like that
2025-11-20 13:19:44 <qaqland> oh, git pull is expensive
2025-11-20 13:20:09 <ikke> It can be expensive, yes
2025-11-20 14:46:48 <Saijin_Naib[m]> Is a boost bump the type of thing that means everything built with it needs a rebuild?
2025-11-20 14:53:45 <ikke> Generally yes
2025-11-20 14:53:54 <ikke> But depends if the soname changes
2025-11-20 15:04:44 <Habbie> or if you care about a change they put in a header
2025-11-20 15:04:54 <ncopa> a random sleep sounds like a cheap way to work around it
2025-11-20 15:29:30 <tomalok> fwiw, Docker 29 has landed, but they've made enough changes that it's not building in the way that we build things.  Unfortunately I don't have the time (or the golang experience) necessry to detangle this in the near term -- is there any volunteers out there that want to have a go at it?
2025-11-20 15:30:44 <ikke> tomalok: what kind of changes or challenges?
2025-11-20 15:35:06 <panekj> well matrix is terrible
2025-11-20 15:35:19 <panekj> ikke: module path is github.com/moby/moby now
2025-11-20 15:37:26 <panekj> they also changed tags
2025-11-20 15:37:31 <ikke> I see the APKBUILD disables go modules (docker previously did not support it)
2025-11-20 15:39:18 <ikke> So I suppose we would need to switch to use them now
2025-11-20 15:41:48 <panekj> I've been building docker <29 with modules on chimera so far
2025-11-20 15:42:40 <tomalok> ikke as far as i've gotten is that what used to be docker/moby module is now moby/moby (or similar), and that messes up how we set up the build environment to build the dynbinaries -- there may be more beyond this
2025-11-20 15:43:55 <tomalok> the supported way to build docker is to build docker with docker (which would probably be in docker in docker on the build hosts?), and the base image they use for all that is glibc based...
2025-11-20 15:44:52 <ikke> We don't support running docker on the builders
2025-11-20 15:45:03 <ikke> And honestly, you should be able to build docker without docker
2025-11-20 15:45:14 <tomalok> yep
2025-11-20 15:46:03 <tomalok> i think the challenge is essentially to get the rootbld env right and things available where golang expects them to be to build stuff.
2025-11-20 15:46:52 <tomalok> i did try some symlinks which seemed to have made it past the first part, but then it had trouble finding some nfttables module
2025-11-20 15:48:55 <tomalok> panekj - github.com/moby/moby now also wanted a v2 dir in that path
2025-11-20 15:49:46 <tomalok> ikke will give it a go turning gomodules on again
2025-11-20 15:51:51 <ikke> I don't know too much about building docker, but I would imagine that could simplify a few things
2025-11-20 15:53:41 <tomalok> wow, if that's all it was, undoing that tweak from the past...
2025-11-20 15:55:30 <pj> for me it's "go: open vendor.mod: no such file or directory"
2025-11-20 15:56:43 <tomalok> still not quite able to get at package libnftables, but got past the github.com/moby/moby/v2 part...  has some output that might be useful - pkg-config --cflags -- libnftables
2025-11-20 15:58:55 <ikke> What is the error you are getting for libnftables?
2025-11-20 16:00:08 <tomalok> ---> Making bundle: dynbinary (in bundles/dynbinary)
2025-11-20 16:00:08 <tomalok> # github.com/moby/moby/v2/daemon/libnetwork/internal/nftables
2025-11-20 16:00:08 <tomalok> # [pkg-config --cflags  -- libnftables]
2025-11-20 16:00:08 <tomalok> Building dynamic bundles/dynbinary-daemon/dockerd (linux/amd64)...
2025-11-20 16:00:08 <tomalok> Package libnftables was not found in the pkg-config search path.
2025-11-20 16:00:09 <tomalok> to the PKG_CONFIG_PATH environment variable
2025-11-20 16:00:09 <tomalok> Perhaps you should add the directory containing `libnftables.pc'
2025-11-20 16:00:11 <tomalok> Package 'libnftables' not found
2025-11-20 16:00:11 <tomalok> >>> ERROR: docker: build failed
2025-11-20 16:01:01 <tomalok> src/moby-docker-v29.0.1/daemon/libnetwork/internal/nftables/ does exist in the tarball
2025-11-20 16:01:42 <ikke> did you add nftables-dev to makedepends?
2025-11-20 16:01:54 <ikke> apk search pc:libnftables
2025-11-20 16:03:18 <tomalok> nope it's not there -- aha, it is a new dependency for 29
2025-11-20 16:04:20 <ikke> docker gets nftables support now
2025-11-20 16:09:49 <tomalok> yay, got through building dockerd and docker-proxy -- needs some work for cli yet -- but i think i'm unblocked -- thanks!
2025-11-20 16:11:21 <ikke> cool
2025-11-20 16:14:24 <panekj> for me it dies during build
2025-11-20 16:17:20 <panekj> Package libnftables was not found in the pkg-config search path.
2025-11-20 16:17:33 <panekj> go build logs are so fun to parse
2025-11-20 16:19:42 <tomalok> panekj - added libnftables-dev to makedepends
2025-11-20 16:20:01 <panekj> yeah this is for chimera though
2025-11-20 16:20:33 <panekj> and I have nftables-devel... but will take that outside #alpine-*
2025-11-20 16:21:09 <tomalok> i'm through cli now -- but looks like rootless stuff moved somewhere else
2025-11-20 16:53:18 <Ariadne> s390x builder seems stalled
2025-11-20 16:55:04 <ikke> which release?
2025-11-20 16:55:14 <Ariadne> 3.23
2025-11-20 19:07:07 <ncopa> so i thought it was smart to skip CI for idris2-stage0 rebuild (which built fine on x86)
2025-11-20 19:07:42 <ncopa> got some help from chatgpt to run debugger: https://github.com/cisco/ChezScheme/issues/995
2025-11-20 19:09:02 <ncopa> i wonder if we just disable idris2 on arm* for now
2025-11-20 19:10:12 <Ariadne> i was thinking the same, it seems to be arm-specific, but the generated code was not particularly enlightening
2025-11-20 19:14:03 <Ariadne> ncopa: there is only 27 commits between chez 10.2 and 10.3
2025-11-20 19:17:13 <ncopa> so it shouldnt be that hard to find fix. btw, i also saw something re s390x which we also have disabled
2025-11-20 19:17:20 <ncopa> and there is idris2 0.8.0 out now too
2025-11-20 19:17:30 <ncopa> (which fails with same error with chez)
2025-11-20 19:17:57 <ncopa> it was vibe debugging so...
2025-11-20 19:17:58 <Ariadne> https://github.com/cisco/ChezScheme/compare/v10.2.0...v10.3.0#diff-41fd70fb19a7a189c557528c4ab613498613313a87f73f6a1ef6e4c44a803edbR298
2025-11-20 19:18:13 <ncopa> but occationally chatgpt said things that made sense
2025-11-20 19:18:27 <Ariadne> https://github.com/cisco/ChezScheme/compare/v10.2.0...v10.3.0#diff-41fd70fb19a7a189c557528c4ab613498613313a87f73f6a1ef6e4c44a803edbR433
2025-11-20 19:18:57 <ncopa> looks suspicjous: https://github.com/cisco/ChezScheme/commit/b3fb895a07a0c2719ac656c23898683c9cee3dff
2025-11-20 19:20:14 <ncopa> scrap that. they all look suspicious to me :) (except doc changes)
2025-11-20 19:21:11 <Ariadne> i think it is https://github.com/cisco/ChezScheme/commit/6b333eec67b24d2118ad1beb84461314db77213c
2025-11-20 19:23:10 <ncopa> its all greek to me :) 
2025-11-20 19:24:18 <ncopa> im disabling armhf for now. still curious if it affects anythign else. https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/93421
2025-11-20 19:25:27 <ncopa> but we are moving forward. riscv64 is now below 1000 left to build
2025-11-20 20:08:09 <ncopa> im working on nymphcast
2025-11-20 20:11:52 <Ariadne> i just fixed it...
2025-11-20 20:12:31 <ncopa> how? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/93422
2025-11-20 20:13:48 <ncopa> i dont see any recent nymphcast MRs or commits in master
2025-11-20 20:14:13 <Ariadne> i haven't pushed the fix yet
2025-11-20 20:14:31 <Ariadne> i am testing it on all archs
2025-11-20 20:14:55 <Ariadne> almost done :)
2025-11-20 20:15:27 <ncopa> i pushed the MR to test on the arches ^^^
2025-11-20 20:15:45 <ncopa> curious how you solved it
2025-11-20 20:16:15 <ncopa> im calling it a day now. feel free to merge anythign that helps us move the builds forward
2025-11-20 20:17:45 <Ariadne> loongarch64 is done
2025-11-20 20:19:11 <ncopa> ha! I like how you solved it! it proves Im not a complete idiot :D
2025-11-20 20:19:44 <ncopa> thanks! and good night!
2025-11-20 20:23:02 <ncopa> Ariadne: i think you should have bumped pkgrel for nymphcast
2025-11-20 20:23:33 <ncopa> not big deal, but would have been good to rebuild it equally on edge
2025-11-20 20:25:57 <Ariadne> i didn't see the need since the resulting binary is basically ~same
2025-11-20 20:27:48 <Ariadne> i think build-3-23-aarch64 is stuck
2025-11-20 20:38:23 <Ariadne> working on qt5-qtwebengine
2025-11-20 20:55:42 <Saijin_Naib[m]> @ikke @Habbie , okay, yeah. I wanted to try packaging sunlight streaming server since we have moonlight (and it would solve my broken laptop screen issue nicely) but it needs a boost bump
2025-11-20 20:56:12 <Saijin_Naib[m]> That's a huge undertaking foe justv that testing aport
2025-11-20 20:58:28 <ikke> And it would have to wait until after the 3.23 release
2025-11-20 20:59:40 <Saijin_Naib[m]> Yeah, into the later folder it goes
2025-11-20 22:00:05 <Ariadne> i have an ugly fix for git-branchless
2025-11-21 06:12:36 <Ariadne> i don't know how to fix ocrmypdf, but it looks quite busted
2025-11-21 06:31:30 <lotheac> just two failed tests, maybe it's enough to just disable them and report upstream
2025-11-21 06:33:45 <lotheac> that said those might be quite important tests
2025-11-21 06:37:09 <Ariadne> they looked important
2025-11-21 06:37:15 <lotheac> yeah
2025-11-21 06:38:09 <lotheac> but they also looked like jpeg-decoding related errors, so maybe it doesn't affect all inputs. who knows
2025-11-21 06:39:31 <Ariadne> https://github.com/ocrmypdf/OCRmyPDF/commit/f4c6c8121ba8178ff3a1cb8f70037bbc3a31391b
2025-11-21 06:39:34 <Ariadne> maybe we backport this
2025-11-21 06:40:15 <lotheac> seems reasonable
2025-11-21 06:40:56 <Ariadne> with that commit, tests do pass
2025-11-21 06:43:09 <Ariadne> aarch64 now uploading
2025-11-21 06:43:11 <Ariadne> nice :)
2025-11-21 06:43:43 <lotheac> nice one
2025-11-21 06:49:33 <Ariadne> keycloak is because JDK 25 is not supported
2025-11-21 06:49:43 <Ariadne> going to hackfix in something to steer it to JDK 21
2025-11-21 07:05:41 <raspbeguy> bl4ckb0ne: yes I always build as rootbld
2025-11-21 07:05:41 <raspbeguy> > seems like a time issue? have you tried to run `abuild rootbld` on your machine?
2025-11-21 07:51:15 <caskd> Does someone maintain a database of the current package content indexes anywhere?
2025-11-21 07:51:51 <caskd> Right now the package contents is quite slow online, and i could do a query on my own rsync mirror of the packages but that would take ages
2025-11-21 07:52:43 <caskd> I'm wondering if there's a central "index" of the current package contents that can be used downstream for queries rather than relying on the online one
2025-11-21 07:53:30 <pj> a "central" "index" would be the one from alpine
2025-11-21 07:53:41 <caskd> well, yes, but i mean the index itself
2025-11-21 07:53:48 <caskd> not the frontend for querying it
2025-11-21 07:53:53 <pj> if you have mirror set-up you can run apkbrowser to index it
2025-11-21 07:54:06 <pj> I don't really understand
2025-11-21 07:54:45 <caskd> well, does apkbrowser query just-in-time or does it build a index?
2025-11-21 07:55:00 <pj> https://dl-cdn.alpinelinux.org/latest-stable/main/x86_64/APKINDEX.tar.gz
2025-11-21 07:55:32 <caskd> the APKINDEX doesn't contain file listings though?
2025-11-21 07:55:35 <caskd> or am i wrong
2025-11-21 07:57:03 <pj> well, it's central index of packages and you can then get file content by querying each package
2025-11-21 07:57:27 <pj> apkbrowser does that, it scans index and packages on repo update and puts all of that into own db
2025-11-21 07:57:44 <caskd> well, okay, but this db isn't shared anywhere, no?
2025-11-21 07:58:16 <caskd> i want to avoid iterating over everything just for a few small queries but also want to avoid using the central frontend because it sometimes is painfully slow
2025-11-21 07:58:39 <caskd> that's why i was wondering if there are snapshots of this DB for reuse anywhere or similar
2025-11-21 08:00:29 <caskd> it's not a dealbreaker, but it would be great for convenience
2025-11-21 08:01:50 <pj> I don't think it's available anywhere, it is trivial to build the db oneself
2025-11-21 08:02:19 <ikke> caskd: ftr, you'll probably going to experience the slowness even if you have the db 
2025-11-21 08:02:40 <ikke> It's not the frontend itself that is slow 
2025-11-21 08:02:56 <pj> too much packages is usually the problem
2025-11-21 08:02:57 <pj> and wide filter
2025-11-21 08:03:21 <pj> so it's best to focus specific repo (main|community|testing) and architecture
2025-11-21 08:03:46 <iggy> I've often felt like it could use some saner defaults
2025-11-21 08:04:12 <caskd> yeah but sometimes i have queries which i wanna span across all repos
2025-11-21 08:04:19 <caskd> ikke: how many resources does the main instance have?
2025-11-21 08:04:42 <caskd> i can throw >100GB of ram at it on-demand
2025-11-21 08:05:11 <pj> if you put the whole thing in ramdisk then maybe you can squeeze few ms out of it
2025-11-21 08:06:22 <pj> ikke: i've meant to ask, is alpine py version of apkbrowser on gitlab?
2025-11-21 08:07:26 <iggy> link at bottom of the page?
2025-11-21 08:08:08 <pj> I'm old and my eyes don't see that well
2025-11-21 08:14:03 <ikke> 10https://gitlab.alpinelinux.org/alpine/infra/apkbrowser
2025-11-21 08:14:07 <ikke> https://gitlab.alpinelinux.org/alpine/infra/apkbrowser
2025-11-21 08:21:06 <iggy> wonder if instead of updating the existing database in place if you create new ones (or copy existing ones and update) then mv the new ones on top of the old ones... just noodling because it's not always slow, but sometimes painfully so
2025-11-21 08:22:48 <iggy> as if there is some scheduled task making it slow down (but it could just be normal traffic patterns)
2025-11-21 08:27:39 <qaqland> caskd: i want to index it myself but don't have time. now i have this one with limited search field https://pkgs.qaq.land
2025-11-21 08:29:36 <caskd> oh thats cool
2025-11-21 08:29:50 <caskd> i got what i wanted but i'll keep it in mind for the next time
2025-11-21 08:29:51 <caskd> :D
2025-11-21 08:30:21 <qaqland> pkgs.a.o still use %like% patten in sqlite to search, i think it would be faster with fts5
2025-11-21 09:00:16 <ncopa> im testing things on build-3-23-ppc64le. I was not able to reproduce the test errors in my dev lxc
2025-11-21 10:01:20 <ncopa> im workign py3-dask
2025-11-21 10:01:35 <ncopa> PureTryOut: do you mind if we upgrade py3-dask to 2025.11.0?
2025-11-21 10:13:02 <PureTryOut> I do not
2025-11-21 10:13:11 <PureTryOut> I should've gotten to it myself already tbh, sorry for that
2025-11-21 10:37:13 <ncopa> no worries. I know how it is to not reach everything
2025-11-21 11:42:07 <Newbyte> Is there any reasoning why some warnings are emitted by abuild and other ones by apkbuild-lint?
2025-11-21 11:44:21 <ikke> One major reason (but not complete): dynamic versus static checking
2025-11-21 11:45:02 <ikke> another reason: abuild can enforce certain rules, while apkbuild-lint is easier to integrate into your editor
2025-11-21 11:45:18 <Newbyte> ikke: Makes sense. I'm asking because we're trying to figure out how to best fix this issue long-term: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/issues/4032
2025-11-21 11:45:36 <Newbyte> The warnings emitted by abuild are easy to miss and apkbuild-lint doesn't pick this up
2025-11-21 11:46:34 <ikke> Doing that statically is difficulty
2025-11-21 11:46:38 <ikke> difficult*
2025-11-21 11:47:46 <ikke> not impossible, and by making some assumtions at the cost of accuracy, even doable
2025-11-21 11:48:51 <Newbyte> Is it something you would want to do?
2025-11-21 11:50:38 <ikke> Question, could abuild treat it as an error rather than a warning? Then it's no longer possible to miss 
2025-11-21 11:50:52 <ikke> Not sure if there are false positives 
2025-11-21 11:51:53 <Newbyte> That would be an acceptable solution to me. Although, maybe a general "-Werror" mode would be nice rather than singling this out.
2025-11-21 11:52:57 <ikke> There are already other checks that are fatal
2025-11-21 11:53:38 <ikke> So it's rather raising a warning to an error, rather then singling out this warning
2025-11-21 11:54:14 <ikke> die ".."
2025-11-21 11:55:17 <ikke> Newbyte: It could probably still be included in apkbuild-lint to get rapid feedback, mind you
2025-11-21 11:57:15 <ikke> so https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L321 s/warning/die
2025-11-21 11:57:40 <ikke> But not sure what the impact of that will be
2025-11-21 11:58:23 <ikke> https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/410 -> ""There might be false positive warnings on local/development builds"
2025-11-21 12:00:23 <ikke> One check for apkbuild-lint is to check if a non-local install variable is defined in any function.
2025-11-21 12:32:16 <angeloverlain[m]> qaqland: nice. how large is the database?
2025-11-21 12:34:27 <ncopa> ok I think py3-dask is ready to be merged
2025-11-21 12:34:59 <ncopa> its almost there
2025-11-21 12:57:16 <vkrishn> For folks using /cache to freeze snapshot their diskless installs, and having difficulty with it,
2025-11-21 12:57:31 <vkrishn> I have added 2 more pages(part 4 & 5) to "local repository" series, URL: https://wiki.insteps.net/AlpineLinux/How-to-manage-shared-apks-repo
2025-11-21 12:57:57 <vkrishn> hopefully should be good read and useful.
2025-11-21 12:58:16 <qaqland> angeloverlain[m]: the search website i created has very limited functionality. it's powered by meilisearch with at least 1.5G ram
2025-11-21 14:16:16 <Sertonix[m]> Newbyte: My current plan is a -Werror like option that would be used in the alpine lint CI.
2025-11-21 14:25:13 <Sertonix[m]> Does pmOS has a seperate CI job for warnings?
2025-11-21 16:15:41 <Newbyte> <Sertonix[m]> "Does pmOS has a seperate CI..." <- We have the build jobs for various architectures and then a separate apkbuild-lint job. 
2025-11-21 16:15:47 <Newbyte> Not sure if I'm understanding your question correctly.
2025-11-21 16:18:37 <Newbyte> Also would be nice if someone involved with abuild/APKBUILD stuff could give some feedback on this: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/issues/4097
2025-11-21 16:35:12 <Sertonix[m]> I generelly try to keep style things split from abuild itself but in aports there are also some rules worked on to make APKBUILDs more uniform
2025-11-21 16:38:14 <ikke> yeah, abuild should not enforce style
2025-11-21 16:50:08 <socksinspace> are main/py3-pytest and main/py3-iniconfig not in a circular dependency? I needed to add a "options="!check"" to py3-iniconfig, but i assume the builds for 3.23 would've run into that too, so maybe i'm doing something wrong
2025-11-21 16:50:42 <ikke> options="!check" # causes bootstrapping issues because of checkdepends
2025-11-21 16:50:46 <ikke> that's in edge
2025-11-21 16:51:34 <ikke> (which is what's 3.23 is building atm
2025-11-21 16:52:22 <socksinspace> yes, in py3-pytest, which depends on py3-iniconfig, which checkdepends on py3-pytest
2025-11-21 16:52:56 <ikke> py3-pytest disables checks already, which breaks the circular dependency
2025-11-21 16:53:06 <Newbyte> Sertonix ikke To be clear, I'm not suggesting abuild should enforce style, but rather whether you think it would be worthwhile to have for instance apkbuild-lint do this.
2025-11-21 16:54:23 <ikke> We already have apkbuild-lint warning for style issues
2025-11-21 16:54:53 <Newbyte> Even style issues as in formatting issues?
2025-11-21 16:55:46 <ikke> https://man.archlinux.org/man/alint.5.en
2025-11-21 16:55:52 <Sertonix[m]> socksinspace: Yes there is. You can disable checks in py3-iniconfig. I didn't bother to upstream the fix yet
2025-11-21 16:56:24 <socksinspace> Sertonix[m]: okay, that's what i did too :)
2025-11-21 16:56:54 <socksinspace> just wanted to check i wasn't just being dense
2025-11-21 16:57:59 <ikke> Newbyte: things like omitting superfluous braces and quotes for example are style issues
2025-11-21 16:58:52 <ikke> Newbyte: So as long as something is an official policy, I'm fine to adding it to apkbuild-lint
2025-11-21 16:59:08 <Newbyte> ikke: Do you think it would make sense to have apkbuild-lint care about things like intended end quotations?
2025-11-21 16:59:22 <Newbyte> intented*
2025-11-21 16:59:26 <Newbyte> indented* I guess I can't type today
2025-11-21 16:59:37 <ikke> Newbyte: If we get it documented as policy, sure
2025-11-21 16:59:57 <Sertonix[m]> Newbyte: Generally I think it's good as long as there are very few (ideally no) false positives and adapting the new style is not interupting regulat maintainance too much.
2025-11-21 16:59:57 <Newbyte> Okay, thank you!
2025-11-21 17:00:06 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/CODINGSTYLE.md
2025-11-21 17:01:05 <ikke> yes, I've ported atools to go to reduce the amount of false positives for certain linters
2025-11-21 17:01:16 <ikke> (ie, it properly parses the APKBUILD instead of relying on things like grep / awk
2025-11-21 17:02:35 <ikke> At some point, we could even faile the linting job on for example major style issues
2025-11-21 17:02:38 <ikke> fail*
2025-11-21 17:02:44 <ikke> Right now it's only warning
2025-11-21 17:03:45 <Sertonix[m]> As long as false failures don't prevent merging that seems fine
2025-11-21 17:04:37 <ikke> yes
2025-11-21 17:37:29 <ncopa> i think the current nodejs related build failures happens due to machine runs out of memory
2025-11-21 17:38:05 <ikke> ncopa: yes, I was already stopping builders to reduce it
2025-11-21 17:38:12 <ikke> at least at the time, aarch64 was still building chromium
2025-11-21 17:39:44 <ikke> ncopa: What do you think would be the best appraoch for gnutls? There are still tests failing. Most are regarding ktls. On armhf, there was another test failing.
2025-11-21 17:54:11 <ncopa> oh you already were stopping them. I killed the build-edge-aarch64 build now
2025-11-21 17:54:26 <ncopa> and started the build-3-23-armhf
2025-11-21 17:54:50 <ncopa> is the test failure reported upstream?
2025-11-21 17:55:00 <ncopa> the best thing would be to fix them
2025-11-21 17:55:28 <ncopa> do we know what ktls fails?
2025-11-21 17:55:44 <ikke> From the logs, I believe it's the poly-chacha test
2025-11-21 17:55:47 <ncopa> oh its ktls, kernel tls
2025-11-21 17:56:06 <ikke> I saw on older patch for fedora to disable it, but not sure if that's a good idea
2025-11-21 17:56:13 <ncopa> we may not have the kernel module loaded I guess
2025-11-21 17:56:17 <ikke> ncopa: the hard part is often even finding out why the test is failing
2025-11-21 17:56:29 <ikke> ncopa: possibly
2025-11-21 17:56:43 <ncopa> so, a wild guess, it needs something from kernel, which may be autoloaded as a module
2025-11-21 17:56:56 <ncopa> excpect that in a container you cannot autload kernel modules
2025-11-21 17:57:07 <ikke> right
2025-11-21 17:57:24 <ncopa> so I would think it is safe to disable the ktls tests
2025-11-21 17:57:52 <ncopa> that said, it should then also be possible to make the tests pass locally, not in container?
2025-11-21 17:58:11 <ncopa> if fedora disable the tests, the I think we also can
2025-11-21 17:58:12 <ikke> ncopa: It succeeds in my dev container
2025-11-21 17:58:26 <ncopa> ok, maybe the host has whatever needed from kernel enabled
2025-11-21 17:58:31 <ikke> fedora disabled it for 3.8, not 3.10 if I understand it correctly
2025-11-21 17:59:01 <ncopa> lets disable them for now
2025-11-21 17:59:23 <ikke> aesni_intel perhaps?
2025-11-21 17:59:45 <ikke> or a variant thereof
2025-11-21 18:04:27 <ikke> On s390x I see for example s390_aes, but I do not see something equivalent on ppc64le
2025-11-21 19:43:04 <logan2611> Is there a good way to restrict AKMS to building only for kernels within a range or newer than X(.Y.Z)? It doesn't look like an Alpine package has had to do this before. https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/93473#note_561637
2025-11-21 20:25:04 <Ariadne> bl4ckb0ne: can you help with this intel-graphics-compiler FTBFS?
2025-11-21 20:25:17 <bl4ckb0ne> FTBFs ?
2025-11-21 20:25:24 <Ariadne> failure to build from source
2025-11-21 20:25:32 <Ariadne> https://build.alpinelinux.org/buildlogs/build-3-23-x86_64/community/intel-graphics-compiler/intel-graphics-compiler-2.14.1-r0.log
2025-11-21 20:26:05 <bl4ckb0ne> hold on, it one of the issue i fixed today when trying to upgrade
2025-11-21 20:26:20 <Ariadne> i think upgrading this to latest release should resolve the problem, but there are many pieces
2025-11-21 20:27:13 <bl4ckb0ne> it wont, it fails to compile elsewhere
2025-11-21 20:27:22 <bl4ckb0ne> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/93528/diffs#diff-content-dc0e176ed6b750380d00365ff8a998bd75a23204
2025-11-21 20:27:26 <bl4ckb0ne> you need this patch
2025-11-21 20:27:48 <bl4ckb0ne> basically they are _still_ on llvm 16.0.6 and it is somehow still maintained by llvm who backports patches
2025-11-21 20:27:58 <bl4ckb0ne> so the rev never changes but the content change
2025-11-21 20:28:14 <Ariadne> thanks, i hate it
2025-11-21 20:28:19 <bl4ckb0ne> yeah same
2025-11-21 20:28:32 <bl4ckb0ne> there's an ongoign issue where people complain about the llvm rev being old and deprecated
2025-11-21 20:28:35 <bl4ckb0ne> it was 15 a year ago
2025-11-21 20:29:23 <bl4ckb0ne> https://github.com/intel/intel-graphics-compiler/issues/380 thats where I got today
2025-11-21 20:29:39 <bl4ckb0ne> and you might need https://github.com/intel/intel-graphics-compiler/pull/375 
2025-11-21 20:30:03 <bl4ckb0ne> https://github.com/intel/intel-graphics-compiler/issues/289 and the issue where people whine 
2025-11-21 20:33:14 <iggy> intel keeping things updated isn't going to get better
2025-11-21 20:33:37 <bl4ckb0ne> yeah their support lately on the compute runtime/graphics compiler has been bad
2025-11-21 20:35:42 <iggy> when you go from 132k employees 3 years ago to 85k by the end of the year...
2025-11-21 20:41:12 <bl4ckb0ne> probably not a big fix but i doubt ill get any answer from them soon
2025-11-21 20:41:37 <bl4ckb0ne> the strerror_r is a user contrib
2025-11-21 21:35:21 <ikke> Newbyte: https://gitlab.alpinelinux.org/alpine/infra/atools-go/-/merge_requests/77
2025-11-21 21:35:44 <Newbyte> ikke: Thank you!
2025-11-21 21:35:47 <Newbyte> Much appreciated
2025-11-21 21:36:03 <ikke> Testing and feedback are welcome
2025-11-21 21:39:33 <Newbyte> ikke: So, it's acceptable to have `install` in a subpackage if it's a local variable?
2025-11-21 21:40:07 <ikke> Yes, then it cannot affect the global scope, so it must be used for something internal to the function
2025-11-21 21:40:27 <Newbyte> Oh, I guess abuild won't pick it up at all then?
2025-11-21 21:40:27 <ikke> It's not recommended to do so out of confusion, but not wrong
2025-11-21 21:40:32 <ikke> yeah
2025-11-21 21:40:50 <Newbyte> That makes sense, thanks for clarifying
2025-11-21 21:41:02 <ikke> abuild runs the subpkg version, and whatever the value of those variables are in the global scope, that's what's used
2025-11-21 21:41:08 <ikke> subpkg function*
2025-11-21 21:41:16 <Newbyte> I won't be able to test it right now. Too late in the day and I don't have the Go toolchain set up.
2025-11-21 21:41:23 <ikke> No worries
2025-11-21 21:47:37 <ikke> "had a go" lol :)
2025-11-21 21:49:05 <Newbyte> I assure you that pun was wholly unintentional
2025-11-21 21:49:47 <ikke> :)
2025-11-21 21:50:01 <Habbie> punintentional
2025-11-21 23:51:00 <HarryN[m]> Is this the right channel to ask questions about contributing packages?
2025-11-22 00:14:41 <Sertonix[m]> Sure
2025-11-22 00:57:12 <HarryN[m]> So I wanted to create a package for [wuffs](https://github.com/google/wuffs) the library as well as the header to use it, but it is packaged as a C file that uses a definition for whether it should include the implementations for the functions. How should I package the header?
2025-11-22 03:21:23 <skarnet> HarryN[m]: if there's a way to package it with only the declarations in .h and the code itself in .a and .so, please do so. Header-only libraries are generally a bad idea.
2025-11-22 03:24:20 <HarryN[m]> Issue is that the library is designed for the C file to be included and not defining WUFFS_IMPLEMENTATION, would it be fine just packaging the hypothetical package libwuffs-dev as the C file renamed to be a header file?
2025-11-22 03:26:01 <HarryN[m]> Packaging the library as a static and dynamic library should be no issue
2025-11-22 04:32:15 <adrian> does anyone have an idea how kbd passes its tests on the builders and in CI?
2025-11-22 04:32:29 <adrian> i cannot get them to pass on ppc64 or x86_64 when running abuild -r or abuild rootbld
2025-11-22 04:32:41 <adrian> it just lacks permissions to access the console in both cases and fails a test due to that
2025-11-22 10:49:49 <Sertonix[m]> adrian: You probably need to skip some tests. A fix should be in the not yet packaged 2.9.0 version: https://github.com/legionus/kbd/issues/143
2025-11-22 10:50:40 <adrian> ah ok, well i disabled the tests for now anyways, will revisit this when 2.9 is packaged
2025-11-22 10:51:03 <adrian> the only package i cannot get to build in main now is subversion which does not seem to like swig 4.4
2025-11-22 11:29:17 <adrian> Sertonix[m]: actually nvm, the test that fails is https://github.com/legionus/kbd/blob/master/tests/libcommon/libcommon-test03.c
2025-11-22 11:29:25 <adrian> that was not touched in 2.9.0
2025-11-22 11:29:36 <adrian> (and it still fails with 2.9.0 on x86_64)
2025-11-22 12:30:26 <caskd> any further things i should change for https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/91709 to be merged? 
2025-11-22 12:46:43 <ikke> skarnet, pabloyoyoista ^?
2025-11-22 13:09:18 <skarnet> the latest version can be merged and should fix the issue
2025-11-22 13:09:31 <skarnet> nothing further to add :)
2025-11-22 13:16:56 <caskd> i'll rebase it then
2025-11-22 15:30:31 <AkatsukiLevi> Hiya hiya! Small question
2025-11-22 15:30:53 <AkatsukiLevi> Anyone else having troubles loading the alpine gitlab? every single page I open just end up with nearly 90% of the page failing with HTTP 429
2025-11-22 15:41:22 <ikke> Oh, they just left :(
2025-11-23 17:26:07 <elagost> when moving a package from testing to community does the pkgrel need to be updated?
2025-11-23 17:27:14 <ikke> No, not for just the move
2025-11-23 17:28:20 <elagost> thanks. would you mind looking at !93542 if you have a sec? It would be nice to have before 3.23.
2025-11-23 17:42:10 <elagost> thank you! It'll be great to have that in stable.
2025-11-23 21:39:29 <Ermine> bl4ckb0ne: wayland-protocols 1.46 mr !93641
2025-11-24 09:21:34 <ncopa> looks like linux 6.18 is planned for next weekend
2025-11-24 09:22:16 <ncopa> i dont know if we dare ship alpine 3.23 with 6.18. But I think it would be nice if we did
2025-11-24 09:37:28 <PureTryOut> Are we in a feature freeze yet or can we still merge major and/or minor package upgrades?
2025-11-24 09:39:04 <ikke> Nothing that would require a lot of packages to be rebuilt. And ideally nothing that would keep the builders stuck.
2025-11-24 09:42:30 <PureTryOut> Ok I'll keep off of a merge then 😛
2025-11-24 09:43:06 <PureTryOut> I mean, nothing I would merge would keep the builders stuck or require a lot of rebuilds but they upgrade a lot of packages at once
2025-11-24 10:03:47 <skarnet> can someone please merge !93647 before more people run usrmerge? thanks ^^'
2025-11-24 10:24:16 <liske> py3-wgnlpy seems to be orphan for about 4 years (with open issues). With ifstate 2.2 have been merged recently there is no package depending on it (ifstate now uses pyroute2's WireGuard implementation). Can I still consider removing it from the repository? Is this still possible as it has been already built for 3.23?
2025-11-24 10:28:24 <ikke> liske: are there packages depending on it?
2025-11-24 10:28:40 <liske> I did not find (grep) any in aports
2025-11-24 10:31:23 <ikke> Then I think it should be safe to remove it
2025-11-24 10:48:22 <liske> ikke: thanks !93652
2025-11-24 11:16:37 <lotheac> hmm... achill: i think elogind upgrade in commit 79233d28f376e66d672f086a37cee0ffd2fab7c3 broke openrc user services but i am not entirely sure how. i'm relying on pam_logind.so to set XDG_RUNTIME_DIR, and it seems it still does appear to get set if i log in normally on a tty, but pam_openrc fails to start user.$USER (and rc-service user.$USER start also fails the same way) with: "XDG_RUNTIME_DIR unset, user services cannot start."
2025-11-24 11:16:58 <lotheac> downgrading to 255.17-r0 helps, but so does installing pam-rundir
2025-11-24 11:18:07 <achill> uhm interesting. maybe report it to either elogind and/or openrc
2025-11-24 11:18:14 <lotheac> pam-rundir helping is why i don't entirely understand why it broke
2025-11-24 11:18:18 <achill> have no clue what couldve gone wrong
2025-11-24 11:19:17 <lotheac> yeah, i will probably have a closer look later... just wanted you to be aware of it for now
2025-11-24 11:21:53 <lotheac> navi: also if you have any ideas ^
2025-11-24 11:23:29 <navi> there was a commit on elogind that explicitly added some exceptions to openrc-user (that upstream are done for systemd-user)
2025-11-24 11:24:15 <lotheac> sounds like a good place to start, thanks
2025-11-24 11:24:22 <navi> so maybe that could've caused it? fwiw i'm also getting openrc user failures on my one elogind gentoo system after updating, just didn't have time to debug it yet
2025-11-24 11:26:11 <navi> https://github.com/elogind/elogind/commit/d21a97a8625294afb632850bd85e09bafc151e00 commit in question
2025-11-24 11:41:50 <lotheac> thanks. https://github.com/elogind/elogind/commit/ff4c383caa3963bee0df0b92c7f851ef1c161e66 in v255 branch. reverting it fixes my issue, so achill maybe we want to revert it in the package until we know more?
2025-11-24 11:42:10 <achill> can do that
2025-11-24 11:42:34 <lotheac> one sec, will MR
2025-11-24 11:42:55 <achill> would be good to keep a issue open in some project
2025-11-24 11:43:10 <lotheac> yeah, of course
2025-11-24 11:43:28 <lotheac> will open an issue too
2025-11-24 11:44:09 <lotheac> in aports to start with, we can triage later if/when we find out why it broke
2025-11-24 11:50:33 <lotheac> !93653
2025-11-24 12:22:25 <pu> Morning everybody, I haven't found anything in the TSC notes, so I'll ask here - what is the strategy for systemd in Alpine Linux? Just postmarketOS support, alternative to openRC or way to go?
2025-11-24 12:24:07 <pu> Or the future direction of init, since there have also been discussions to replace openRC by something else than systemd.
2025-11-24 12:46:34 <achill> nothing is really decided yet, so currently just -systemd subpkgs for postmarketos and the usr-merge
2025-11-24 12:48:12 <achill> there were several discussions about the init system but without a real conclusion, but tldr: openrc will never go away as the default, but technically it might be possible to install another init system as openrc
2025-11-24 12:49:11 <achill> there are already other init systems (like dinit) packaged, but not usable without hacks (like apk add dinit -t openrc=9999 i guess)
2025-11-24 13:15:41 <pu> That's good to hear. I guess that there are quite some systemd-avoiders who use Alpine Linux, and the appearance of systemd artefacts without any "public" explanation has irritated some ;) 
2025-11-24 13:17:02 <achill> its literally a few text files faw away in subpackages 🤷
2025-11-24 13:17:40 <achill> and even if systemd would be pacakged, nobody should be afraid, it would be just like any other package: you dont have to install it, but other who want, can
2025-11-24 13:22:55 <pu> Well you know how the internet and people in general work, so it's good to be clear about the direction.
2025-11-24 13:22:55 <pu> People have been complaining about MX Linux going essentially systemd-only.
2025-11-24 13:22:55 <pu> On a personal note, I also appreciate that my favorite distro in not slowly moving to systemd, especially with systemd now working on musl libc compatibility.
2025-11-24 13:30:16 <skarnet> achill: as soon as s6-frontend is out I'll start working on a framework for support of multiple init systems in Alpine
2025-11-24 13:31:05 <skarnet> so OpenRC will remain the default but people will be able to choose s6 if they want, and later on you can add dinit or systemd to the list if you wish, the framework will be there
2025-11-24 13:32:10 <skarnet> ikke: thanks for the merge!
2025-11-24 13:33:51 <ikke> 👍
2025-11-24 14:00:24 <PureTryOut> skarnet: sounds great, looking forward to your work!
2025-11-24 15:21:48 <qaqland> lots of systemd subpackage now, it make me really confused.
2025-11-24 15:23:06 <qaqland> Can we add a flag in abuild that is off by default to skip packaging systemd? This way, pmos can enable it manually
2025-11-24 15:28:34 <PureTryOut> the whole point is that we don't have to fork a bunch of stuff just to be able to ship a few text files. And this way at least people notice there are systemd files in there, previously it was often missed and shipped with the main package (so unwillingly installed on a lot of machines) rather than removed
2025-11-24 15:29:27 <PureTryOut> and note that on a regular Alpine installation these subpackages are not installed, so it shouldn't hurt anybody
2025-11-24 15:32:53 <qaqland> This change happened quietly, there wasn’t even a post on the https://alpinelinux.org/posts/
2025-11-24 15:34:59 <PureTryOut> Not that quietly, a MR has been open on abuild for ages. And I don't see why a default implementation of a subpackage function should be posted on a blog. It's literally just splitting of some text files into it's own package
2025-11-24 15:36:53 <ikke> qaqland: that's not a change we would post there
2025-11-24 15:58:34 <realroot[m]> is there a plan to rebuil qps , qt-creator etc in edge? x86_64
2025-11-24 15:59:58 <realroot[m]> does the build system have something to automatically rebuild?
2025-11-24 16:00:43 <realroot[m]> like that arch package https://github.com/max-baz/rebuild-detector
2025-11-24 16:00:59 <realroot[m]> useful for personal repo too
2025-11-24 16:10:58 <PureTryOut> hmm would be nice if we had a CI job or something which would detect needed rebuilds and fail if those rebuilds are not included in the MR
2025-11-24 16:52:48 <funderscore> qaqland: (Un)Ironically, adding support for systemd packages actually means properly handling systemd services by not shipping them on an OpenRC install (in a cleaner way)
2025-11-24 16:53:37 <funderscore> right now there are no plans to switch the support to systemd AFAIK, but I see some people are still interested in being able to use systemd in alpine, and more generally being able to use other non-OpenRC init systems without too much hassle.
2025-11-24 16:53:56 <funderscore> skarnet: that's great to hear ^^
2025-11-24 16:55:13 <funderscore> quite excited about all this TBH :)
2025-11-24 16:55:48 <Ariadne> skarnet: i already have most of a framework that can represent services in systemd or openrc format
2025-11-24 16:56:59 <Ariadne> with the caveat that generated service definitions have to exist in the limits of their underlying service manager, e.g. openrc does not (presently) support attaching ebpf policy for "jailing" while systemd does.
2025-11-24 16:58:47 <Ariadne> pu: in general, i don't think anyone has anything to worry about re: alpine switching to systemd.  the use of busybox and openrc are a key part of alpine's identity.  but we should allow derivatives to have different policy.  this is something to figure out as alpine continues growing into becoming a metadistribution like debian or gentoo.
2025-11-24 17:12:59 <skarnet> Ariadne: sure, a unified format for service files will help a lot, but no rush, that can come in later. What I'm thinking of focusing on is very basic and pedestrian: the structure of boot scripts and the switching framework, so a user can move seamlessly to an init system or another
2025-11-24 17:13:20 <skarnet> there isn't much theory in it, just very hands-in-the-grease engineering
2025-11-24 17:16:08 <achill> isn't systemd already a unified format that is very widely used, declerative and what else does it also need to be?
2025-11-24 17:49:01 <skarnet> achill: not at all, no. It's only "very widely used" in the systemd world, which is very different from the rest of the ecosystem. It's also full of systemd idiosyncrasies that don't translate well. Like the rest of systemd, it uses its format (here, what variables are defined) to subtly push towards adoption of the systemd architecture.
2025-11-24 17:49:20 <skarnet> see my attempt to analyze the unit file variables here: https://skarnet.org/software/s6/unit-conversion.html
2025-11-24 17:50:47 <skarnet> it is kinda declarative, but it doesn't make it good: for instance, User= is a terrible variable because it means two very different things depending on the value given, so it's a footgun for the user
2025-11-24 17:51:07 <skarnet> systemd unifies these two different things, but other service managers (rightly) do not
2025-11-24 17:53:00 <skarnet> generally speaking, when the goal is for a framework to be usable by a non-systemd ecosystem, you should absolutely not trust anything provided by systemd, because designs that come from systemd are 100% systemd-centric and disregard that other designs can even be possible
2025-11-24 17:53:24 <skarnet> if it is intentional, it is malicious; if it is not intentional, it is incompetent
2025-11-24 18:07:14 <Ariadne> while i agree that user= should take usernames only, it is common for distributions to want to run services as less privileged users and indeed we do so with openrc
2025-11-24 18:16:36 <skarnet> I'm not saying "don't run services unprivileged"
2025-11-24 18:17:37 <skarnet> I'm saying "using fixed uids and running getpwnam() on every service start are two different operations"
2025-11-24 18:17:48 <skarnet> so we should have two differently named variables to do this
2025-11-24 18:17:54 <skarnet> e.g. user= and uid=
2025-11-24 20:16:19 <Sertonix[m]> achill: dinit is bootable without hacks. You just keep openrc (it won't hurt you) or not use alpine-base.
2025-11-24 20:40:40 <achill> ah nice then i assumed wrong
2025-11-24 21:35:39 <Ariadne> skarnet: yes, i think we are on the same page here :)
2025-11-24 21:36:54 <Ariadne> in general, i also think that musl-based systemd users should not use the seccomp-bpf stuff that systemd has.  at least not right now.  there are behavioral differences between musl and glibc that probably need to be accounted for with those policies
2025-11-24 21:43:19 <p_6f3Ik7Suw> can confirm, i generate seccomp rules automatically by extracting strace logs, and they differ significantly between glibc and musl
2025-11-24 21:44:46 <p_6f3Ik7Suw> (stracing unittests and the processing those into seccomp rules, minijail has the necessary tooling for strace -> bpf)
2025-11-24 21:47:07 <Ariadne> p_6f3Ik7Suw: yes, this is also why alpine does not yet integrate apparmor
2025-11-24 21:47:46 <Ariadne> 
ACTION would like alpine to integrate apparmor, but it is tedious work

2025-11-24 21:58:09 <Arnavion> Even in systemd distros, tuning the syscall filter too tightly breaks across things like glibc upgrades. That's why even `systemd-analyze security` only tells you to block the broad groups of syscalls like `@cpu-emulation` rather than individual syscalls
2025-11-25 10:34:40 <socksinspace> is there a somewhat elegant way to deal with volatile checksums, like for example main/libyuv, when building packages yourself? if no elegant way is available, hacky workarounds are also appreciated
2025-11-25 10:36:12 <ncopa> afaik, no elegant way. workaround is to store the tarball yourself somewhere. we use archive.alpinelinux.org for that
2025-11-25 10:36:37 <ncopa> sorry. https://dev.alpinelinux.org/archive/
2025-11-25 10:37:10 <ncopa> anyone available to help fix intel-graphics-compiler build?
2025-11-25 10:37:54 <ncopa> im working on py3-dask on ppc64le
2025-11-25 10:45:35 <lotheac> i might be able to take a look at intel-graphics-compiler in a bit
2025-11-25 10:48:47 <ncopa> awesome! thanks!
2025-11-25 10:49:34 <ncopa> im giving up py3-dask. I will just manually package build on ppc64le and move on
2025-11-25 10:49:54 <ncopa> it will break in stable branch in future if there are any sec fixes or similar
2025-11-25 10:50:13 <ncopa> i think the problem is a deadlock in xdist, when collecting the results
2025-11-25 10:50:18 <ncopa> but im not sure
2025-11-25 10:50:35 <ncopa> i *think* i may have observed it in CI on x86_64 as well
2025-11-25 10:50:41 <ncopa> but it eventually passed there
2025-11-25 13:53:15 <angeloverlain[m]> re: service managers, 66 is one of them I was interested about
2025-11-25 13:53:18 <angeloverlain[m]> https://web.obarun.org/software/66/0.8.2.1/66-frontend.md/
2025-11-25 13:53:35 <angeloverlain[m]> except development seem to have stalled (it seems to be a one-person show)
2025-11-25 14:00:44 <skarnet> angeloverlain[m]: being a one-person show isn't a showstopper; since 66 piggybacks onto s6, when the framework is in place you'll be able to install it if you want
2025-11-25 14:01:22 <skarnet> but my goal is to make it irrelevant because why have the copy when you can have the original :P
2025-11-25 14:01:42 <angeloverlain[m]> nice
2025-11-25 14:01:56 <angeloverlain[m]> 
ACTION wonders how s6-frontend might look like

2025-11-25 14:03:21 <skarnet> don't expect anything miraculous at first, it's my first time writing a normie user-facing thing and it will probably suck and only improve with ux returns
2025-11-25 14:03:51 <skarnet> also I want to ship it early just so I can work on the thing that really interests me, i.e. the flexibility framework XD
2025-11-25 16:25:47 <adrian> how is openjdk currently bootstrapped for new architectures?
2025-11-25 16:26:13 <adrian> i can only see some magic archives with prebuilt jdks and no real explanation how they came to be
2025-11-25 16:29:18 <ikke> You have to ask Bratkartofel or celeste, but they are not in this channel
2025-11-25 17:09:55 <achill> would be good to document that for transparency reasons
2025-11-25 17:10:56 <adrian> there is nice documentation for bootstrapping of e.g. dotnet
2025-11-25 17:11:17 <adrian> though i guess dotnet is also one of the "easier" bootstraps since it can be done cross
2025-11-25 17:26:13 <Sertonix[m]> You can cross compile the packages after modifying the APKBUILDs. I really need to figure that out again and upstream it
2025-11-25 19:57:22 <haesbaert> any special reason why EFI defaults to grub in the installation?
2025-11-25 20:02:46 <Biswa96[m]> grub is default in setup-alpine script. other bootloaders can be installed manually. 
2025-11-25 20:10:16 <haesbaert> thanks
2025-11-25 20:20:24 <ikke> achill: adrian There was a plan to have it be done more transparrently through -stage0 packages
2025-11-25 20:33:59 <lonjil> If anyone has time, now or after v3.23 is out, could someone review my new package MR (88454)? The bot marked it stale 2 months ago, but I finally got around to setting up my bouncer again to chat here.
2025-11-25 21:49:39 <quinq> Hi
2025-11-25 21:49:47 <quinq> It seems there's a problem with the Calibre build
2025-11-25 21:50:04 <quinq> There are error messages like:
2025-11-25 21:50:04 <quinq> qt.core.plugin.loader: Failed to find metadata in lib /usr/lib/calibre/calibre/plugins/sqlite_custom.so: '/usr/lib/calibre/calibre/plugins/sqlite_custom.so' is not a Qt plugin (metadata not found)
2025-11-25 21:50:36 <quinq> For basically all .so there (more or less)
2025-11-25 21:51:45 <quinq> And then it says:
2025-11-25 21:51:46 <quinq> qt.qpa.plugin: Could not find the Qt platform plugin "headless" in "/usr/lib/calibre/calibre/plugins"
2025-11-25 21:51:55 <Ariadne> quinq: afaik Qt plugins are not ABI-stable across different Qt releases, so we probably need to rebuild calibre
2025-11-25 21:51:58 <quinq> Although
2025-11-25 21:51:59 <quinq> qt.core.plugin.loader: Found metadata in lib /usr/lib/calibre/calibre/plugins/libheadless.so, metadata=
2025-11-25 21:52:02 <quinq> qt.core.plugin.factoryloader: Got keys from plugin meta data QList("headless")
2025-11-25 21:52:16 <quinq> (I have no idea how that's supposed to work though :D)
2025-11-25 21:52:20 <quinq> Oh ok Ariadne 
2025-11-25 21:53:41 <quinq> I suppose not much people use Calibre (I rarely do)
2025-11-25 23:36:58 <jvoisin> quinq: it's the least terrible software to manage epub, it has a significant amount of (sad) users unfortunately
2025-11-25 23:43:01 <quinq> Why said? :D
2025-11-25 23:43:06 <quinq> s/said/sad/
2025-11-25 23:43:28 <quinq> I like its embedded convertion profile for my Kindle DX, it has good rendering
2025-11-25 23:43:58 <Imbus> What software are you speaking about?
2025-11-25 23:45:01 <quinq> It's a secret
2025-11-25 23:45:33 <Imbus> ouff spicy
2025-11-25 23:45:58 <Imbus> million bucks on calibre
2025-11-25 23:47:46 <quinq> gg :)
2025-11-26 00:12:39 <invoked> i recall calibre being one of the few options to connect to libraries & do the drm book thing
2025-11-26 11:52:27 <maribu> Assuming I have a pkg `foo` and some `py3-foo-bar` and some `py3-foo-bar-baz` subpkgs of the `foo` pkg. Should there be a `py3-foo-bar-pyc` *and* a `py3-foo-bar-baz-pyc`, or just a signle `py3-foo-bar-pyc` that would also contain the cached bytecode for `py3-foo-bar-baz`?
2025-11-26 11:53:50 <maribu> Specifically: I was wondering how to make use of the default split function when two subpackages with python modules are present.
2025-11-26 12:02:00 <ncopa> shall we try to get the alpine release out next Monday or Tuesday?
2025-11-26 12:09:36 <achill> dont have anything blocking
2025-11-26 12:10:03 <achill> we should fill the release notes: https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.23.0
2025-11-26 12:10:51 <ncopa> yes
2025-11-26 12:44:04 <pabloyoyoista> fabled: any thoughts about https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/93778 ?
2025-11-26 12:48:46 <fabled> pabloyoyoista: looking at it. Can you confirm the commit that caused it? I would suspect https://gitlab.alpinelinux.org/alpine/apk-tools/-/commit/01185484c5a353e0c2de1c821d029e03d0372d4b is more likely than the logging rework
2025-11-26 12:50:18 <fabled> I suspect dev/FD needs explicit bind mount
2025-11-26 12:51:25 <pabloyoyoista> I don't think we have a reproducer right now, since it's working locally for all of us, have to wait for infra people to be available to test in the actual runners
2025-11-26 12:52:02 <fabled> possibly due to nested filesystem namespaces then
2025-11-26 12:52:47 <pabloyoyoista> Do you think it's sane to blindly revert that commit in alpine for now? Or do we wait for our infra people to be able to test it?
2025-11-26 12:55:27 <fabled> let me give a temporary workaround patch in a sec. i think best is to disable unshare if root
2025-11-26 12:55:46 <pabloyoyoista> Big thanks
2025-11-26 12:56:56 <fabled> pabloyoyoista: lets try https://tpaste.us/5Q8E
2025-11-26 13:02:02 <pabloyoyoista> fabled: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/93778 updated and issue in https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/11161
2025-11-26 13:02:49 <fabled> pabloyoyoista: thanks.
2025-11-26 13:03:29 <pabloyoyoista> To you for the fast responses!
2025-11-26 13:03:42 <fabled> pabloyoyoista: what is the builder setup? as in, is it containers (within containers)?
2025-11-26 13:06:34 <pabloyoyoista> I'm not totally sure to be honest. I'm trying to find the manifest
2025-11-26 13:08:11 <fabled> what i'm interested is how the `mount` output looks like in the default container
2025-11-26 13:08:31 <fabled> i suspect /dev is private, unshareable mount and the recursive bind mount fails to expose /dev/fd
2025-11-26 13:09:48 <pabloyoyoista> Per the documentation, it seems the setup is just an alpine linux virtual machine
2025-11-26 13:13:09 <pabloyoyoista> And pmbootstrap currently just uses chroots. But it's possible that dev maybe is not propragated enough?
2025-11-26 13:15:39 <fabled> pabloyoyoista: oh, didn't realize that there is --root xxx involved. is apk running as root or non-root when this is done?
2025-11-26 13:17:16 <pabloyoyoista> As root
2025-11-26 13:22:08 <fabled> pabloyoyoista: can you verify it the workaround works?
2025-11-26 13:25:23 <pabloyoyoista> On it
2025-11-26 13:27:45 <pabloyoyoista> fabled: yes, it does :)
2025-11-26 13:29:13 <fabled> pabloyoyoista: thanks. strange indeed. i'm pretty sure its something how the mount flags are setup differently. sorry for the breakage. i'll try to figure out how to fix it properly, or if we just apply the workaround for now on apk git too
2025-11-26 13:30:07 <pabloyoyoista> I pinged the infra people that should have access to the builders in that issue. So for further testing, probably talk to them
2025-11-26 13:30:11 <pabloyoyoista> And huge thanks for the fast reaction!
2025-11-26 13:40:16 <fabled> pabloyoyoista: actually, it might be some interaction with pmbootstrap, https://builds.sr.ht/~postmarketos/job/1615147#task-pmbootstrap_build-41 shows you mount the dev for the chroot
2025-11-26 13:41:50 <pabloyoyoista> Could be? But that's also the case locally
2025-11-26 13:42:52 <fabled> pabloyoyoista: yes, i'm actually pretty sure now what happens
2025-11-26 13:43:13 <fabled> the virtual machine host, does not have proper /dev. it's missing the fd -> /proc/self/fd symlink
2025-11-26 13:43:41 <fabled> and on apk, the detection looks only the $ROOT/dev/fd to exist
2025-11-26 13:44:24 <fabled> the change, made it unconditional to bind mount the /dev/ from root to $ROOT/dev, and then the script chroot ended up without /dev/fd but the detection code still said its there
2025-11-26 13:44:34 <fabled> hum
2025-11-26 13:45:07 <fabled> I think apk should not be doing bind mounts if the paths look initialized
2025-11-26 13:45:15 <fabled> i'll write more in the apk-tools issue
2025-11-26 14:01:20 <achill> i think this is how the VMs are booted: https://git.sr.ht/~sircmpwn/builds.sr.ht/tree/master/item/images/control#L50
2025-11-26 14:28:25 <ncopa> anyone can help find out why https://build.alpinelinux.org/buildlogs/build-3-23-ppc64le/community/py3-niaaml/py3-niaaml-2.1.2-r0.log
2025-11-26 14:28:34 <ncopa> its a blocker for 3.23
2025-11-26 14:32:02 <achill> can you open a issue pinging the maintainer? seems like they are also the upstream maintainer
2025-11-26 16:00:29 <socksinspace> there might be an issue with our ca-certificates, or something else along the way, when trying to build main/tinc i get "ERROR: cannot verify www.tinc-vpn.org's certificate, issued by 'CN=E8,O=Let\'s Encrypt,C=US': Unable to locally verify the issuer's authority."
2025-11-26 16:02:52 <socksinspace> fails in gnu wget, busybox wget, and curl, works in librewolf, but that uses nss, i think
2025-11-26 16:06:37 <ikke> socksinspace: do they send the intermediate certificate?
2025-11-26 16:06:49 <ikke> That's often an issue
2025-11-26 16:07:44 <ikke> Browsers can cache them, so they often have the intermediates already available, but cli tools only have the root certs, so if the server does not provide the intermediates, there is no way to validate the entire chain
2025-11-26 16:08:33 <dne> they don't: https://www.ssllabs.com/ssltest/analyze.html?d=www.tinc%2dvpn.org&s=46.226.104.40&latest
2025-11-26 16:10:08 <socksinspace> thx for looking that up dne, my reply would've been: i don't have a clue
2025-11-26 16:12:25 <socksinspace> so, do i open an issue for that, or just ignore it? if yes, for what package?
2025-11-26 16:20:38 <dne> try prodding them to fix it on irc?
2025-11-26 16:21:12 <socksinspace> yes, but who do i prod for that?
2025-11-26 17:46:18 <fubap> What is the "firstboot" service for? The init script only seems to do some SSH configuration.
2025-11-26 18:24:48 <quinq> Well, you have it :)
2025-11-26 18:55:55 <ncopa> i think the firstboot service is technically not needed anymore with the tiny-cloud support
2025-11-26 19:13:28 <ncopa> i think i finally was able to fix gnutls-3.8.11 build
2025-11-26 19:17:50 <ikke> ncopa: Nice!
2025-11-26 19:23:29 <WhyNotHugo> !91581 should be okay to merge
2025-11-26 19:25:55 <ncopa> sorry but I have full focus on 3.23 release now so I ignore testing/* til 3.23 is out
2025-11-26 19:26:29 <ncopa> unless there is some strong reason to get the new aports into 3.23 release, but its a bit late for that now
2025-11-26 23:37:53 <adrian> is there something like abuild cleanoldpkg... but for an entire repo?
2025-11-26 23:38:16 <adrian> or is the way to go about that to just script running it in every package
2025-11-26 23:55:43 <Sertonix[m]> rm -r ~/packages/<repo> ?
2025-11-26 23:56:40 <Sertonix[m]> Ah, only old ones. Then the current way would be running it  for each pqckage
2025-11-27 00:02:58 <adrian> that's not really viable with the time it takes
2025-11-27 00:03:18 <adrian> it takes a few hundred ms per package
2025-11-27 00:03:52 <adrian> for the 8000 packages i have that'll take too long to run regularly
2025-11-27 04:03:28 <sam_> ncopa: wrt https://gitlab.alpinelinux.org/alpine/aports/-/commit/551543889184c28ca9d6212fc6c4fa353fe13bd4, pretty sure it's not a miscompilation; that test is extremely sensitive to the memory being "wiped" at the right time
2025-11-27 04:03:40 <sam_> ncopa: of course you should check it out more but i suspect it's not actually a problem
2025-11-27 04:03:58 <sam_> (I reported some such problems before and they all resulted in gnulib tweaks to make the test more robust, nothing else)
2025-11-27 05:18:55 <ikke> adrian: you can check what aports-build does
2025-11-27 05:49:56 <ncopa> sam_: ok, i just concluded that from the comment in test code
2025-11-27 05:50:31 <ncopa> and I had another issue with armv7 recently that I think was miscompilation with -Os
2025-11-27 05:51:53 <ncopa> unfortunately im overloaded atm, so I have not had time to investigate any further
2025-11-27 06:57:40 <ncopa> I think we need help with ppc64le
2025-11-27 07:12:24 <ncopa> do we have a contact for ppc64le?
2025-11-27 07:29:57 <ikke> Mick Tarsel
2025-11-27 07:50:13 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/issues/17753
2025-11-27 08:16:25 <ncopa> looks like we dont run tests at all for py3-numpy
2025-11-27 08:16:42 <ncopa> i think the ppc64le issues are related numpy
2025-11-27 12:25:34 <ncopa> or openblas
2025-11-27 12:25:41 <ncopa> the tests in openblas are completely disabled
2025-11-27 13:30:42 <ncopa> i think this may solve our ppc64le issues: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/93826
2025-11-27 13:32:00 <ikke> ncopa: can we enable checks again then?
2025-11-27 13:32:23 <ikke> or are they still failing
2025-11-27 13:57:05 <ncopa> so there was one test related to avxsomething that failed
2025-11-27 13:57:22 <ncopa> with the new flag that test passed but failed with something else
2025-11-27 13:58:25 <ncopa> i noticed that fedora had the NO_AVX2=1 on all arches but I didnt watn to touch anything excpet ppc64le
2025-11-27 16:04:09 <qaqland> I'm sorry I don't have much time for #17499 and #17558 :(
2025-11-27 16:08:18 <ikke> We're now focussing on the 3.23 release anyway
2025-11-27 16:09:22 <ikke> We haven't noticed packages failing to build after Oct 31
2025-11-27 16:23:40 <ncopa> i was too optimistic about have fixed ppc64le issues
2025-11-27 16:23:52 <ikke> :(
2025-11-27 16:24:02 <ncopa> but now I have found upstream fixes. I have backported them and lets hoe they work better
2025-11-27 16:24:05 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/93836
2025-11-27 16:28:07 <ncopa> py3-patsy passes now
2025-11-27 18:48:56 <ikke> I may have a fix for py3-skia-pathops
2025-11-27 18:48:58 <ikke> testing it now
2025-11-27 18:56:30 <ncopa> It’s only 3 packages left. I think we can disable them
2025-11-27 18:57:08 <ncopa> njs need a fix for the test. Inserted work on it but had to go out
2025-11-27 19:00:23 <ikke> I found this for skia: https://bugzilla.mozilla.org/show_bug.cgi?id=1990823
2025-11-27 19:01:15 <ikke> But the change does not appear to help
2025-11-27 19:15:34 <ikke> ncopa: the idea of the change does work, it's just that the macro is not defined apparently
2025-11-27 19:32:53 <mio> got a passing build, along the same idea
2025-11-27 19:36:02 <mio> !93844
2025-11-27 19:36:59 <mio> will clean up and try merging it shortly
2025-11-27 19:37:56 <ikke> mio: ah, thanks
2025-11-27 19:38:30 <ikke> But I'm puzzled why !defined(__PPC64__) does not seem to work, even though gcc -dM -E - < /dev/null
2025-11-27 19:38:32 <ikke> returns it
2025-11-27 20:30:09 <ncopa> nice!
2025-11-27 20:30:22 <ncopa> I have a fix for njs: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/93846
2025-11-27 20:30:29 <ncopa> ppc64le is done
2025-11-27 20:42:32 <ncopa> i think ostree is broken on riscv64
2025-11-27 20:46:14 <ncopa> i just disabled ostree-push on riscv64
2025-11-27 20:46:22 <ncopa> i think it will complete now
2025-11-27 20:52:17 <ncopa> we should merge those or move the to new milestone https://gitlab.alpinelinux.org/groups/alpine/-/milestones/23#tab-issues
2025-11-27 21:04:46 <mio> moved the two python ones to the next milestone. did the openblas fix also worked on R and suitesparse?
2025-11-27 21:05:40 <mio> 17553 can be closed in that case, if there's no need to track the two anymore
2025-11-27 21:07:21 <ncopa> i didnt test if openblas fix solves R or suitparse. its quite possible it does
2025-11-27 21:08:12 <ncopa> im going to bed now. will look at tagging abuild, mdev-conf mkinitfs alpine-conf tomorrow
2025-11-27 21:09:29 <mio> good night, thanks for the fixes!
2025-11-27 21:09:52 <ncopa> likewise
2025-11-28 12:53:06 <Kladky> Could someone please retry the failed pipelines for !93418? It seems it they only failed because of a network error, so hopefully retrying them could fix the issue, so that Alpine 3.23 releases with the latest Plasma
2025-11-28 13:14:47 <socksinspace> question for the rust folks, if i want to bootstrap rust for a "new" architecture (x86 without sse2 in this case) do i need to rebuild rust on my host first, or should it "just work"
2025-11-28 13:21:38 <ikke> There's also #alpine-rust
2025-11-28 13:22:19 <ncopa> i am still on the fence if we should try upgrade linux-lts to 6.18
2025-11-28 13:22:36 <ncopa> it is very late in the release for it, but it would be nice to have it
2025-11-28 13:22:56 <ncopa> achill: did you test build the 3rd party mods?
2025-11-28 14:07:39 <ncopa> please do not merge anything heavy now, so we can get rc1 out
2025-11-28 14:08:43 <PureTryOut> Kladky: I'm not merging that MR (I'm the author) before Alpine 3.23 is out to keep the builders at rest and available to fix more pressing issues blocking the release. Once 3.23 is out I'll just apply the MR to both branches
2025-11-28 14:20:10 <Kladky> ikke ncopa is ^ a reasonable concern? It's just that with a package as important (to the desktop at least) as plasma, you wouldn't want to ship an outdated version without a very good reason
2025-11-28 14:20:45 <PureTryOut> Eh, this particular upgrade is not that pressing
2025-11-28 14:28:15 <Kladky> Even so, there isn't any harm in double-checking whether it should be posponed
2025-11-28 14:32:59 <ncopa> I dont mind merging it if the CI is green and it does not "gets in the way", eg while I'm sleeping :) 
2025-11-28 14:33:41 <ncopa> a possibility may be soon after rc1 is out
2025-11-28 14:34:23 <ncopa> > fix more pressing issues blocking the release.
2025-11-28 14:34:39 <ncopa> thank you! it is appreciated
2025-11-28 14:50:19 <ncopa> ok, im tagging 3.23.0_rc1 now
2025-11-28 15:09:46 <ncopa> s390x failed to build rc1.  mk-s390image is missing whatever that is
2025-11-28 15:10:48 <ncopa> fafef6d0afc3b404ae48cd9726ea00bff97c26f2
2025-11-28 15:15:09 <Sertonix[m]> Should be in the s390-tools package
2025-11-28 15:15:18 <ncopa> the symlink s broken
2025-11-28 15:15:27 <ncopa> lrwxrwxrwx    1 root     root            44 Nov 28 15:11 /usr/bin/mk-s390image -> ../usr/share/s390-tools/netboot/mk-s390image
2025-11-28 15:16:23 <Sertonix[m]> I guess that was me
2025-11-28 15:16:41 <ncopa> happens. care to do a fix?
2025-11-28 15:16:51 <ncopa> should be ../../usr/share
2025-11-28 15:16:57 <ncopa> or just ../share
2025-11-28 15:17:43 <ncopa> im gonna do a cheat release
2025-11-28 15:17:46 <ncopa> of rc1
2025-11-28 15:17:52 <ncopa> so we dont need to do rc2
2025-11-28 15:17:56 <ncopa> today
2025-11-28 15:18:06 <f_> did i hear cheating
2025-11-28 15:18:43 <ncopa> no you didnt
2025-11-28 15:19:00 <f_> ok carry on then :D
2025-11-28 15:19:13 <ncopa> :)
2025-11-28 15:19:18 <Sertonix[m]> I opened a MR (and hope that it's coreect now)
2025-11-28 15:19:31 <ncopa> sounds promising...
2025-11-28 15:20:26 <ncopa> this time I made sure everythign is coreect
2025-11-28 15:21:38 <ncopa> ok rc1 is actually out
2025-11-28 16:32:02 <ncopa> Was there something about the wording in the usr merge nag script?
2025-11-28 16:33:26 <ncopa> Any volunteers to create a release notes merge request for alpine-mksite 
2025-11-28 16:46:51 <Sertonix[m]> The wording has been fixed on master
2025-11-28 19:28:51 <Kladky> PureTryOut: there's your seal of approval, so I guess you can merge it once ncopa is asleep :D 
2025-11-28 19:41:32 <angeloverlain[m]> cc [Sertonix](https://matrix.to/#/@sertonix:mozilla.org)what do you think about mkinitfs!206
2025-11-28 19:42:03 <angeloverlain[m]> [algitbot](https://matrix.to/#/@_oftc_algitbot:matrix.org)hmmm not quite
2025-11-28 20:03:01 <PureTryOut> Kladky: lol ok sure, since ncopa said so then 😅 I suppose at the same time I'll merge the Qt upgrade then
2025-11-28 20:20:02 <Kladky> thanks! :D
2025-11-28 20:55:43 <Sertonix[m]> [@angeloverlain:matrix.org](https://matrix.to/#/@angeloverlain:matrix.org) I would prefer the discussed nlplug-findfs approach
2025-11-28 21:39:04 <angeloverlain[m]> I don’t know how it works or lua so I can’t really help here except maybe the high levels
2025-11-28 21:49:12 <logan2611> aarch64 linux-stable in edge doesn't seem to boot in qemu anymore
2025-11-28 22:14:22 <logan2611> Also is someone able to review !93473? Going from 3.22 -> 3.23 will make bcachefs partitions unreadable currently, and if 3.23 is bumping linux-lts to 6.18 then the AKMS issue won't be relevant anymore.
2025-11-29 07:56:48 <Ariadne> i would like to propose removing the usr-merge message for now.  merged /usr needs to be rethought, this time with all stakeholders being involved.
2025-11-29 08:01:18 <Ariadne> like, seriously, i think in the current state, we do not want to encourage people to run the script
2025-11-29 08:01:45 <Ariadne> i hate to apply "stop energy" here, but we need to stop and rethink this
2025-11-29 08:02:31 <ncopa> * WARNING: The current system is not /usr-merged.
2025-11-29 08:02:31 <ncopa> * You are encouraged to migrate manually to ensure system reliability.
2025-11-29 08:02:55 <skarnet> if it is not viable as is, will there be a script to undo the merge for early adopters and testers on edge?
2025-11-29 08:03:00 <ncopa> option 1: remove it completely for 3.23 and re-add it for edge shortly after
2025-11-29 08:03:02 <Ariadne> yes, i am saying that we should not encourage people to do this right now, until apkdb issues are fixed
2025-11-29 08:03:21 <ncopa> option 2: change it to INFO instead of WARNING
2025-11-29 08:03:44 <ncopa> and soemthing like: You are encouraged to migrate manually to help testing
2025-11-29 08:03:47 <ncopa> or similar
2025-11-29 08:04:13 <ncopa> "to ensure system reliability." should be reworded
2025-11-29 08:04:34 <Ariadne> option 3: consider the current TSC change proposal an error, print nothing at all until it is actually ready and a new TSC proposal has been approved outlining the risks accurately
2025-11-29 08:05:29 <ncopa> TSC is sort of malfunctioning right now
2025-11-29 08:05:54 <Ariadne> yes, it is
2025-11-29 08:06:22 <ncopa> but i thought there was some sort of migration plan already
2025-11-29 08:06:23 <Ariadne> hence why i think we should stop pushing messaging telling people to run a script that breaks apkdb
2025-11-29 08:06:33 <Ariadne> and revisit this after fixing TSC
2025-11-29 08:07:14 <Ariadne> again: i have no objection to merged-/usr, but not at the cost of breaking our root of integrity measurement
2025-11-29 08:07:54 <Ariadne> we must find a path that ensures system integrity can still be measured, we owe that to our users and to ourselves as developers
2025-11-29 08:07:55 <skarnet> sorry to insist, but for systems that *have done* the merge, there needs to be a way to either fix apkdb / rejoin the eventual Alpine state, or to revert to pre-usrmerge
2025-11-29 08:08:19 <Ariadne> skarnet: i am trying to figure out how to revert it
2025-11-29 08:09:37 <lotheac> ncopa: there may be a plan, but while it stays only a plan, i gotta agree with Ariadne here. probably not a good idea to advocate people to run the merge script in the current state
2025-11-29 08:12:17 <Ariadne> in the absence of a functioning TSC, a decision must be made.  at present, i cannot comfortably say that people should use 3.23 without masking usr-merge-nag at the least.
2025-11-29 08:13:02 <Ariadne> *I* do not feel comfortable making that decision, as *I* am not involved with alpine governance, but a decision needs to be made regardless
2025-11-29 08:14:22 <Ariadne> I am incidentally happy to become involved with Alpine governance again if it would help, but right now IMO we cannot release 3.23 in a state where people are being told to run a tool which breaks system integrity measurement
2025-11-29 08:14:55 <ncopa> so, the original idea was that, usr-merge is a big deal for pmos. it save them for lots of work long term. it usually makes sense to fix things as high up upstream as possible.
2025-11-29 08:15:13 <Ariadne> yes, again, i have no objection to usr-merge as a concept
2025-11-29 08:15:28 <Ariadne> the reason it is a problem is because `apk info -W $(which busybox)` is now broken
2025-11-29 08:16:03 <Ariadne> `apk audit --system`, which people use to determine if their system has been tampered with, is also broken for the same reason
2025-11-29 08:16:04 <ncopa> the deal was that 1. they do the work. 2. they deal with maintenance, 3. I should not need to get involved at all
2025-11-29 08:16:24 <ncopa> it turned out to be much more complicated than originally thought
2025-11-29 08:16:56 <Ariadne> i understand that, and i am not blaming you for the current situation (or anyone else for that matter).  this is a *process* failure.
2025-11-29 08:17:39 <ncopa> do we have an issue for reverting the nag script?
2025-11-29 08:18:29 <Ariadne> i can create one.  where do you want it?
2025-11-29 08:18:44 <ncopa> i suppose aports
2025-11-29 08:18:59 <ncopa> thanks!
2025-11-29 08:19:05 <Ariadne> can i then go fix the bug by disabling the nag script's install-by-default for now?
2025-11-29 08:19:43 <ncopa> you can create a merge request for it at least. just want to run it with postmarket people who have been working on it
2025-11-29 08:20:24 <ncopa> fwiw, we are workingk on the TSC as well, but the release is a higher prio atm, and then there is vacation and stuff
2025-11-29 08:20:28 <ncopa> so its gonna take time
2025-11-29 08:21:07 <ncopa> Ariadne: thank you for you help with this
2025-11-29 08:21:08 <Ariadne> something has to give.  i can't tell people to use alpine 3.23 in good faith if it is going to advise them to do something which breaks their ability to determine if their system has been tampered with...
2025-11-29 08:21:20 <ncopa> yeah. i get that
2025-11-29 08:22:16 <ncopa> Ariadne: may I ask about your opinion on updating linux-lts to 6.18?
2025-11-29 08:22:31 <Ariadne> i think it is worthwhile
2025-11-29 08:22:44 <ncopa> it will probably mean that people caring about stability should not upgrade until 3.23.2 or something
2025-11-29 08:22:50 <ncopa> wait a couple of months
2025-11-29 08:23:01 <Ariadne> do we know 6.18 will be the next lts?
2025-11-29 08:23:22 <ncopa> one issue is zfs. we'd need to ship it with zfs 2.4.0-rc
2025-11-29 08:23:32 <ikke> To be honest, my understanding of usr-merge was that the actual migration would be done once everything was already in place (properly moved to /usr)
2025-11-29 08:23:33 <ncopa> the lts has traditionally been the last release every year
2025-11-29 08:23:35 <Ariadne> in that case, i think we should stick with 6.12
2025-11-29 08:24:27 <Ariadne> i guess what i am trying to say is
2025-11-29 08:25:15 <Ariadne> we are entering a time with multiple state-level threat actors which appear willing to target more broadly
2025-11-29 08:25:48 <Ariadne> and we are meeting that moment by giving advice that makes it easier for those threat actors to hide their rootkits, etc
2025-11-29 08:26:27 <Ariadne> should we do /usr merge?  sure
2025-11-29 08:26:48 <Ariadne> should we do it in a way that makes the system unauditable?  no
2025-11-29 08:27:33 <ncopa> got it
2025-11-29 08:28:32 <ncopa> you absolutely have good points
2025-11-29 08:28:42 <Ariadne> in a way, postmarketOS is *vital* to fighting this future, and we *should* help them in any way we can as upstream project
2025-11-29 08:29:43 <ncopa> *nod*
2025-11-29 08:30:09 <Ariadne> but one way we help them is through engineering leadership: to ensure that we, and them as downstream, work together to ensure they produce output that protects the user
2025-11-29 08:31:27 <Ariadne> it is why we make sure the loongarch port is insulated from loongson -- we recognize that loongson is controlled in part by the CCP, and thus, we do not allow loongson to have access to our signing keys
2025-11-29 08:31:55 <ncopa> that applies to all architectures
2025-11-29 08:31:57 <Ariadne> in the same way, we should help our users by ensuring they can still audit their device's integrity :)
2025-11-29 08:32:21 <ncopa> thats why we spearated the signing keys per arch
2025-11-29 08:32:23 <Ariadne> sure, but loongarch is one where the ties to state intelligence are more... direct :P
2025-11-29 08:33:17 <ncopa> i suppose one way to revert the usr-merge is: apk add apk-tools-static busybox-static; cp /bin/busybox.static /sbin/apk.static / ;  rm -rf /usr /lib ; ./apk.static fix ...
2025-11-29 08:34:08 <Ariadne> yeah that is basically what i was about to do
2025-11-29 08:35:07 <ncopa> the nice thing with apk is that as longs as you have your /etc/apk/world you can always re-install
2025-11-29 08:38:36 <ncopa> oh.
2025-11-29 08:38:39 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/commit/859a6644da60a12f8912a5289c0b81885904cfaa
2025-11-29 08:38:53 <ncopa> and https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/93907
2025-11-29 08:41:00 <ncopa> so the wording is already changed. was just not applied
2025-11-29 08:41:46 <ncopa> Ariadne: i think still you should create an issue and/or MR to remove the nag script for the 3.23 release. we can re-enable it in edge later
2025-11-29 08:41:55 <Ariadne> yes, i am on it :)
2025-11-29 08:42:02 <ncopa> but I want to run it with the pmos ppl before merging it
2025-11-29 08:42:14 <Ariadne> i do not think they get a "veto" here
2025-11-29 08:42:26 <ncopa> thanks a alot
2025-11-29 08:43:11 <ncopa> well, we should at least listen
2025-11-29 08:43:43 <Ariadne> i support listening, but we can listen to them in the form of a new TSC work item once the TSC has been fixed
2025-11-29 08:44:26 <ikke> https://gitlab.alpinelinux.org/alpine/tsc/-/issues/100, but with adjusted timeline
2025-11-29 08:44:43 <Ariadne> while it may be inconvenient somehow for pmOS, there is no real urgency here: pmOS can still tell people to test the merge-usr scripts while we determine what success criteria should be
2025-11-29 08:59:05 <Ariadne> ncopa: https://gitlab.alpinelinux.org/alpine/aports/-/issues/17759
2025-11-29 09:09:06 <skarnet> careful with "rm -rf /usr", there's /usr/local in there, and while I don't think it's a good place to put local modifications (they should be entirely outside /usr), it's a widely adopted convention, so...
2025-11-29 09:09:32 <ikke> yes, indeed
2025-11-29 09:17:11 <iggy> `rm -rf /usr` sounds like a terrible idea in general (pretty sure a ton of docs still list /usr/src as the kernel directory, python system/local installs which are warned against but still wildly prevalent, etc)
2025-11-29 09:23:10 <Ariadne> i did the following:
2025-11-29 09:23:26 <Ariadne> 1. apk add busybox-static apk-tools-static
2025-11-29 09:23:40 <Ariadne> 2. cp /bin/busybox.static /; cp /sbin/apk.static /
2025-11-29 09:23:47 <Ariadne> 3. mv usr usr.old
2025-11-29 09:23:53 <Ariadne> 4. rm bin sbin lib
2025-11-29 09:24:34 <Ariadne> 5. cat /etc/apk/world | grep -v usr-merge-nag | xargs apk fix -rud
2025-11-29 09:24:40 <Ariadne> 6. rm -rf usr.old
2025-11-29 09:24:50 <Ariadne> seems to be fine...
2025-11-29 09:25:45 <Ariadne> apk.static*
2025-11-29 09:34:54 <Ariadne> after that, apk audit --system seems happy enough
2025-11-29 09:38:42 <WhyNotHugo> GitLab is sending multiple email (usually 3+) per comment or per event.
2025-11-29 09:39:13 <WhyNotHugo> I've been seeing this for a few days already.
2025-11-29 09:39:55 <WhyNotHugo> They have distinct Message-ID, so definitely not an issue on the receiver side.
2025-11-29 09:44:19 <Ariadne> 
ACTION patiently waits for git push

2025-11-29 09:46:43 <quinq> Patient bear, will be ready when you are
2025-11-29 09:47:18 <Ariadne> here is the bottom line, that usr-merge-nag thing needs to be disabled for now
2025-11-29 09:48:42 <quinq> Just to get some context, is it about stable, or also edge?
2025-11-29 09:48:49 <Ariadne> this is in edge/3.23
2025-11-29 09:48:59 <quinq> 'k
2025-11-29 09:49:30 <quinq> I did that usrmerge because the script really said “Do it now or face problems soon”
2025-11-29 09:49:59 <Ariadne> congrats, now the NSA can mess with /bin/busybox and you'll never know
2025-11-29 09:50:13 <quinq> Yep, I warned about this a few days ago too
2025-11-29 09:50:22 <quinq> (well, not the NSA, but at least the technical issue)
2025-11-29 09:50:33 <Ariadne> well whatever adversary you choose :P
2025-11-29 09:50:38 <Ariadne> there's so many!
2025-11-29 09:53:57 <ikke> WhyNotHugo: trying to figure out why that happens
2025-11-29 09:54:27 <skarnet> Ariadne: currently following your steps and for some reason the apk db was in /usr/lib/apk so it ends up moved in /usr.old
2025-11-29 09:54:39 <Ariadne> oh yes, you need to move the apkdb by hand
2025-11-29 09:55:02 <skarnet> why is it actually stored under /usr rather than /var
2025-11-29 09:55:16 <Ariadne> great question
2025-11-29 09:55:32 <Ariadne> originally it was under /lib, so it got moved to /usr/lib :p
2025-11-29 09:55:39 <Ariadne> i agree that apkdb should relocate to /var tho
2025-11-29 09:56:00 <skarnet> so should I move the db to /lib/apk rather than /var/lib/apk ?
2025-11-29 09:56:06 <Ariadne> yes to /lib/apk
2025-11-29 09:57:30 <Ariadne> ncopa: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/93916
2025-11-29 09:58:21 <skarnet> usr_merge_nag.sh: execve: No such file or directory
2025-11-29 09:58:28 <skarnet> what package has that
2025-11-29 09:58:38 <skarnet> it's not usr-merge-nag, I have no such package
2025-11-29 09:58:54 <Ariadne> it was originally as part of alpine-baselayout
2025-11-29 09:59:03 <Ariadne> i moved the nag script out so i could shut it up
2025-11-29 09:59:11 <skarnet> where is it located
2025-11-29 09:59:25 <Ariadne> the execve is because /bin/sh is missing
2025-11-29 09:59:28 <skarnet> if you're going to post instructions they need to actually *work for other people*
2025-11-29 09:59:39 <ikke> /lib/apk/commit_hooks.d/usr_merge_nag.sh
2025-11-29 09:59:43 <skarnet> thanks
2025-11-29 10:00:24 <Ariadne> skarnet: i thought i had captured the important parts, sorry :)
2025-11-29 10:00:45 <Ariadne> please note i intend to merge that MR in 24 hours if it is not merged before
2025-11-29 10:01:13 <skarnet> well I'm alpha testing it for you :P
2025-11-29 10:02:14 <Ariadne> i am not trying to be a dick here, but breaking apkdb so badly that anything installed to /bin just doesn't get tracked by apk anymore is not acceptable
2025-11-29 10:02:59 <Ariadne> maybe other distros find that to be acceptable, but our tag line is literally "Small. Simple. Secure." damnit!
2025-11-29 10:03:29 <skarnet> friendly reminder that the whole usrmerge idea was initiated by systemd
2025-11-29 10:04:00 <Ariadne> well in an idyllic s6 world, we would abandon FHS entirely
2025-11-29 10:04:13 <Ariadne> there are good reasons for usrmerge
2025-11-29 10:04:13 <Sheila> I was never clear on why / -> /usr anyway, tbh
2025-11-29 10:04:36 <skarnet> I'm working on that world when I don't have to waste time because my distro breaks
2025-11-29 10:06:21 <skarnet> also
2025-11-29 10:06:26 <skarnet> why do I have a /nix now
2025-11-29 10:06:44 <Ariadne> wut
2025-11-29 10:06:51 <skarnet> yes
2025-11-29 10:07:38 <skarnet> I have a Nix store in my root directory now
2025-11-29 10:07:41 <skarnet> with wonky dates
2025-11-29 10:07:48 <WhyNotHugo> skarnet: systemd? but solaris is also doing it, it must be a great idea! /s
2025-11-29 10:07:50 <Ariadne> were you using Nix?
2025-11-29 10:07:56 <skarnet> I was not
2025-11-29 10:08:33 <skarnet> I *may* have run it once long ago, but I could swear I *have* looked at my / since and I had no /nix
2025-11-29 10:08:42 <Ariadne> anyway to get back on point, i recognize pmOS is working hard on this, but it is not in a state where we should be pushing people to do this experiment in v3.23
2025-11-29 10:09:27 <Ariadne> i will, again, point out that i do not work for an enterprise linux vendor anymore, and am happy to join the TSC if wanted
2025-11-29 10:10:15 <Ariadne> if that is what i can do to ensure this never happens again, i will *gladly* do it
2025-11-29 10:10:36 <Ariadne> but mostly i just want an outcome where this never happens again
2025-11-29 10:10:50 <skarnet> I support that because in the following months I will bring forward proposals that will need studying by the TSC and I will need it to move rather quickly
2025-11-29 10:11:01 <skarnet> and having you in it is a way to ensure that  :)
2025-11-29 10:11:10 <ncopa> Ariadne: noted. Appreciate your willingness to help
2025-11-29 10:11:17 <Ariadne> i also think pmOS should have representation on TSC
2025-11-29 10:11:27 <ncopa> 👍
2025-11-29 10:11:35 <Ariadne> but regardless: we cannot ship usr-merge-nag in 3.23
2025-11-29 10:22:42 <quinq> skarnet, don't blindy copy paste commands from IRC ;p
2025-11-29 10:23:05 <skarnet> rm -rf /
2025-11-29 10:23:15 <quinq> WAIT
2025-11-29 10:46:31 <ikke> !93916 has been merged
2025-11-29 10:49:06 <quinq> Can't wait for the usr-unmerge-warn
2025-11-29 10:58:54 <socksinspace> I'm glad that we seem to have reached an agreement to try the usr-merge more calmly, the back and forth was getting me stressed out, and i'm not even involved in it :)
2025-11-29 11:00:37 <quinq> Coslpay cats also make me nervous, though I don't see anybody doing something about it
2025-11-29 11:03:02 <socksinspace> you can rip my catboys, catgirls and catenbies from my cold dead hands :P
2025-11-29 11:04:12 <socksinspace> anyway, i have my fingers crossed for a smooth 2.23 release
2025-11-29 11:04:48 <quinq> :)
2025-11-29 11:21:58 <Ariadne> to be clear, i am in support of usr-merge.  but we must do it in a way that is safe
2025-11-29 11:22:12 <Ariadne> to do it safely will need more work in apk-tools
2025-11-29 11:23:03 <skarnet> quinq: =^.^=
2025-11-29 11:23:07 <achill> regarding TSC representation by pmOS: i would certainly be down too to join the TSC
2025-11-29 11:23:35 <socksinspace> Ariadne: i trust your judgement on that matter :)
2025-11-29 11:24:54 <Ariadne> i say this not just for direct alpine users, but also pmOS users.  we are entering a time where self-attestable device security is critical, and pmOS is clearly a solution to that problem.  i have so many thoughts, but it is hard to lay them out in a chatroom.
2025-11-29 11:26:24 <Ariadne> the main point, however, is that we all look to the TSC for foundational technical leadership on how to build alpine in a way that keeps ourselves and our users secure.
2025-11-29 11:26:53 <Ariadne> as a project, we must fix the TSC
2025-11-29 11:28:06 <Ariadne> it is vitally important that security-impacting work, such as /usr-merge is properly analyzed and planned.  this is something we have to get right, because getting it wrong is a security problem
2025-11-29 11:29:31 <Ariadne> also, if i may be bold, i think pmOS is about to have a similar moment as Alpine did 10 years ago with Docker as people begin to realize that we need to adopt libre operating systems in mobile devices
2025-11-29 11:29:40 <Ariadne> for our own personal security
2025-11-29 11:45:12 <Ariadne> Sheila: the idea is that distribution components go into /usr, and customizations go into /
2025-11-29 11:45:20 <Ariadne> (and i guess we just get rid of /usr/local)
2025-11-29 11:47:22 <achill> yeah /usr/local is a historic piece of mess,
2025-11-29 11:47:54 <ikke> But it's currently still supported and used
2025-11-29 11:49:23 <achill> its still a unsolved problem i guess
2025-11-29 11:49:26 <Ariadne> anyway, this is a hard problem to solve, and so it is hard work.  i am appreciative of everyone who has worked on this so far :)
2025-11-29 11:50:18 <achill> (see https://gitlab.freedesktop.org/FHS/fhs-spec/-/issues/5)
2025-11-29 11:52:51 <ikke> https://gitlab.freedesktop.org/FHS/fhs-spec/-/issues/5#note_2649314
2025-11-29 11:57:09 <quinq> /opt, the place where to put stuff when you gave up about fixing a problem
2025-11-29 11:57:39 <Sheila> that seems like an inversion of the original intent of /usr, tbh.
2025-11-29 11:57:47 <pabloyoyoista> Ariadne: thanks for looking into this. I dearly missed having a TSC that could have guided us in the technical implementation and reviewed issues as they came
2025-11-29 11:58:08 <pabloyoyoista> And I'm sorry I couldn't do better
2025-11-29 11:58:13 <Ariadne> pabloyoyoista: yes, as i keep saying, this is nobody's personal failure.  it is a process failure
2025-11-29 11:58:30 <Ariadne> everyone here is acting in good faith and is trying to make alpine better
2025-11-29 11:59:01 <Sheila> but distro design is hard, especially when it comes to big changes like this, so ultimately I just hope we get a solution that meets everyone's needs. :)
2025-11-29 11:59:17 <Ariadne> there is nothing to apologize for
2025-11-29 12:01:34 <pabloyoyoista> :)
2025-11-29 12:01:51 <Ariadne> i worry for our future though.  we can'
2025-11-29 12:02:00 <Ariadne> we can't function as a project the way we are going
2025-11-29 12:02:46 <Ariadne> frankly, i worry that the dysfunctionality might get somebody killed
2025-11-29 12:03:28 <pabloyoyoista> Good thing is that I think many people recognize those process issues
2025-11-29 12:03:36 <pabloyoyoista> So maybe we can actually fix them :)
2025-11-29 12:04:08 <Ariadne> i also worry that if we cannot get the foundation right, it will be worse for us when pmOS has its own "docker moment"
2025-11-29 12:04:19 <Sheila> tbh it kinda feels like whenever Ariadne steps away things start falling apart after a while.
2025-11-29 12:09:12 <Ariadne> (to be clear: i want pmOS to have a moment similar to alpine's docker moment.  pmOS is, in my mind, one of our best shots at fighting the future that the tech oligarchs are building around us.)
2025-11-29 12:11:48 <invoked> quinq: /opt came in with sysv, iirc
2025-11-29 12:12:13 <Ariadne> Sheila: alpine needs to grow beyond individual ego
2025-11-29 12:12:29 <Sheila> yeah, I agree.
2025-11-29 12:13:56 <Ariadne> brb
2025-11-29 12:14:14 <invoked> Ariadne: i've wondered if the 6 month release cadence factored into usr-merge being in the state it is
2025-11-29 12:17:11 <Ariadne> invoked: maybe to an extent.  the larger problem was lack of movement from key stakeholders (e.g. people who know apk-tools internals), which resulted in unclear acceptance criteria
2025-11-29 12:17:43 <Ariadne> the need to tie things to a release cadence certainly may have put pressure on people to push to "get it done"
2025-11-29 12:17:55 <invoked> yeah, that's what i mean.
2025-11-29 12:18:18 <Ariadne> but that is mostly a planning issue
2025-11-29 12:18:28 <Kladky> WhyNotHugo: I reported this issue with multiple emails in #alpine-infra, but I forget if it ever moves to a gitlab issue
2025-11-29 12:20:22 <ikke> Kladky: it hasn't
2025-11-29 12:21:47 <Kladky> ikke: which repo should I report this in?
2025-11-29 12:22:18 <ikke> alpine/infra/infra
2025-11-29 12:27:10 <ncopa> i thin kI have all 3rd party modules built for 6.18-rc7 now
2025-11-29 12:33:31 <Ariadne> alpine has been a part of basically my entire adult life, and this community has always been here, through good and bad.  i care *deeply* about the community and the OS we have built together.  it is one of the most important things to me.
2025-11-29 12:36:44 <ncopa> <3
2025-11-29 12:37:02 <ncopa> we will solve it
2025-11-29 12:37:22 <ncopa> but not today. it will take some time
2025-11-29 12:38:09 <Ariadne> of course :)
2025-11-29 12:38:37 <Sheila> Ariadne: tbh you're part of why I came back, even if I haven't really gotten as involved as I was in early days.
2025-11-29 12:39:13 <Sheila> (still working through some personal shit, but I'm hoping once I get it all sorted I can feel comfortable getting more involved.)
2025-11-29 12:39:14 <Ariadne> i want people to be involved in alpine because it is rewarding, not because i'm doing it :p
2025-11-29 12:39:38 <Sheila> well, yes.
2025-11-29 12:41:52 <Sheila> it's more I was reminded I have shit I should be taking care of, lol.
2025-11-29 12:42:32 <invoked> alpine is really the only thing keeping me using linux at all.
2025-11-29 12:43:17 <f_> alpine is my favourite linux distro, it's the kind of distro I'd love contributing to, and using, and it's also the kind of community I'd enjoy being part of
2025-11-29 12:43:19 <Ariadne> anyway, i have a higher degree of confidence in the 3.23 release now than i did earlier tonight, and i am hopeful that we will take a pause for a moment on /usr merge and figure out a path that is led by apk-tools first
2025-11-29 12:44:51 <Sheila> if not for alpine (and adélie) I would probably have gone back to, idk, dreamhost or some shit so I didn't have to deal with sysadmin. (I accidentally my server once when I ran debian on it, and apk doesn't let that kind of thing happen.)
2025-11-29 12:46:14 <f_> I wish I had discovered alpine sooner
2025-11-29 12:46:48 <Ariadne> the question i have now is not discovering alpine, but discovering pmOS
2025-11-29 12:48:01 <Ariadne> it really is IMO the new frontier
2025-11-29 12:48:19 <f_> absolutely
2025-11-29 12:57:59 <Ariadne> and as i said earlier, i think pmOS is about to have a similar moment to alpine + docker.  people are starting to realize that their devices are not necessarily working for *them*, but rather for corporations
2025-11-29 12:58:46 <invoked> i feel that way about linux generally.
2025-11-29 12:59:42 <Ariadne> i mean, i agree that alpine feels more empowering than what we see in GNU/Linux world these days
2025-11-29 13:00:34 <Ariadne> but i don't think GNU/Linux is as bad as say, macOS or modern windows
2025-11-29 13:01:09 <invoked> but i'm old, and when i got into linux from the bsd world, the committees weren't dominated by corporations yet
2025-11-29 13:02:06 <Sheila> I'm really looking forward to the new accessibility stuff Gnome et al have been working on, because I really would like to move off of macOS someday. but I can't do that without a usable screen reader.
2025-11-29 13:03:23 <Sheila> (it'd be easier if I could use a Braille display, but unfortunately my fingers just aren't sensitive enough for that to be practical.)
2025-11-29 13:03:54 <Ariadne> i'm told that the braille person in linux is... not great
2025-11-29 13:04:44 <Sheila> why am I not surprised.
2025-11-29 14:27:53 <Sertonix[m]> Ariadne: Thanks!
2025-11-29 18:36:06 <Noisytoot> <Ariadne> frankly, i worry that the dysfunctionality might get somebody killed
2025-11-29 18:36:08 <Noisytoot> how?
2025-11-29 18:36:33 <Noisytoot> I don't see how usr-merge getting into a release before it is ready could possibly result in that
2025-11-29 18:48:52 <Sheila> Noisytoot: unauditable systems make it easier for a state actor to slip in rootkits or other malware to someone's server, which in turn means that that state actor can see what someone's up to.
2025-11-29 18:49:41 <Sheila> this is not even an unlikely scenario; Alpine is used in a _lot_ of places, some of which has security implications.
2025-11-29 20:01:05 <quinq> Software used in human-hazard places are actually audited, as in passing certification
2025-11-29 21:24:32 <roselandgoose> I assumed the "getting some killed" part referred to a state actor killing a "subversive," identified through a hypothetically compromised system. Not sabataouge of some system in a human-hazardous industry.
2025-11-29 22:37:18 <Ariadne> yes basically
2025-11-29 22:58:02 <Ariadne> the idea in the merge-usr case is that someone installs a modified busybox binary at /usr/bin/busybox, which apk does not detect anymore
2025-11-29 23:48:44 <Ariadne> thanks to the magic of having multi-gigabit fiber at home, i have done some basic analysis of every single apk in the pending alpine 3.23 release.  i think if we chose to spend a week fixing the packages we could have the entire /usr-merge completed in the 3.24 iteration.
2025-11-29 23:49:30 <Ariadne> then we simply adjust alpine-baselayout to reflect the merge
2025-11-30 09:46:25 <Imbus64> I'm curious, what type of work would be required to finalize this usr-merge? Hunting down individual packages and patching them to install into /usr? 
2025-11-30 09:47:09 <Imbus64> I was under the impression that this already landed in 3.22, is this not the case?
2025-11-30 10:17:51 <lonjil> Imbus64: it is not the case. Still some packages that install into /bin, /sbin/, and /lib.
2025-11-30 10:21:06 <Sertonix[m]> More important is to search for packages that only check for specific files in /bin, /sbin or /lib.
2025-11-30 10:21:09 <Imbus64> Is this a hard fix? Or is it just a matter of coordination with upstream?
2025-11-30 15:42:27 <ikke> It's hard to find those hidden assumptions
2025-11-30 16:03:43 <elibrokeit> unless the issue is alpine specific non-portable patches, this is a non-issue without assumptions to worry about
2025-11-30 16:04:33 <elibrokeit> and I'm pretty sure it's a non-issue even if there are such patches
2025-11-30 16:04:59 <abby> is alpine not creating /lib -> /usr/lib, /bin -> /usr/bin, etc symlinks? that should solve almost all issues of relying on non-merged dirs
2025-11-30 16:05:23 <elibrokeit> s/almost//
2025-11-30 16:06:06 <ikke> abby: they are
2025-11-30 16:06:17 <ikke> That's what the merge-usr script does
2025-11-30 16:06:54 <ikke> But if everything has been moved, it could even be part of alpine-baselayout
2025-11-30 16:28:48 <Antiz> Hi 👋
2025-11-30 16:29:04 <Antiz> What does it takes for a package to move from testing to community?
2025-11-30 16:29:14 <ikke> A merge request + review
2025-11-30 16:29:41 <Antiz> Oh, alright. I'll submit it then :)
2025-11-30 16:30:50 <Antiz> The context is: I'd like to submit a MR to bump a package which is in [community], but said package now requires a make dependency that is still in [testing].
2025-11-30 16:35:47 <ikke> Ok, you could combine it then
2025-11-30 16:35:49 <ikke> in a single MR
2025-11-30 16:35:58 <Antiz> Ah, good to know. Thanks!
2025-11-30 16:36:16 <ikke> Are you the maintainer of the package in testing?
2025-11-30 16:36:21 <Antiz> I'm not
2025-11-30 16:36:31 <ikke> Ok, then we'll notify the maintainer
2025-11-30 16:36:40 <ikke> (In the MR)
2025-11-30 16:36:49 <Antiz> Maintainer is Jakub :)
2025-11-30 16:54:15 <ikke> Antiz: ftr, each package should have a separate commit
2025-11-30 16:55:21 <Antiz> ikke: Ah, so one commit for the move from testing to community for granite7 and one for the swaync bump?
2025-11-30 16:55:30 <ikke> yes
2025-11-30 16:55:38 <Antiz> Alright, I'll fix it in a sec
2025-11-30 17:10:20 <Antiz> Done :)
2025-11-30 20:50:51 <ncopa> im looking ath the 6.18 kernel config. do we still want the legacy iptables kernel stuff?
2025-11-30 20:51:23 <ncopa> our iptables now uses nftables backend i think
2025-11-30 20:52:12 <ncopa> but it may be that someone wants to run legacy iptables in container?
2025-11-30 20:52:23 <ncopa> i suppose we can disable and re-enable as soon someone complains
2025-11-30 20:56:15 <ikke> As long as docker and awall still work, I'm okay with it 
2025-11-30 20:56:54 <ikke> But they should already work with the nft backend