2026-07-01 07:53:05 <knuxify|m> could somebody take a look at aports!103066?
2026-07-01 08:20:50 <jvvv> knuxify|m: Thanks for the tag! I hope you don't mind I grabbed up your changes. I liked the way you handled the vendored lib but still needed to add py3-typing-extensions.
2026-07-01 08:21:54 <jvvv> Looking back on it, I could have just commented on your MR. My hind sight is 20/20.
2026-07-01 08:40:50 <RustBotCachy> Hello! Just testing a minimalist IRC client I wrote in Rust. Is anyone around?
2026-07-01 08:41:52 <llllllllll> hola
2026-07-01 08:46:01 <fabricionaweb> couldnt test it within another channel
2026-07-01 08:47:46 <fabricionaweb> Hi, I have one PR waiting for review !102821
2026-07-01 09:00:40 <qaqland> it's hard to review !104548 :(
2026-07-01 09:06:28 <qaqland> https://www.x-cmd.com/start/support-us#faq
2026-07-01 09:15:17 <fabricionaweb> why is all inside package? eish
2026-07-01 09:44:53 <ncopa> do we really need an x-cmd apk package? I'm not sure what benefit it brings for alpine
2026-07-01 09:46:01 <ncopa> i think x-cmd looks shady
2026-07-01 09:47:25 <ncopa> it took a while to find out exactly what problem x-cmd is supposed to solve
2026-07-01 09:51:47 <bdprom> i still can't figure out what it does
2026-07-01 09:56:35 <jvvv> At first glanse it looks like a function library for script kiddies
2026-07-01 09:58:30 <f_> the MR description looks a bit llm-generated
2026-07-01 09:58:35 <f_> maybe they just used a translator
2026-07-01 09:59:15 <ncopa> i think it is a tool to circumvent package signing, so you don't need to be root to install things. I believe it is "useful" for AI to circumvent all kinds of protections
2026-07-01 09:59:27 <f_> website looks AI generated
2026-07-01 09:59:39 <bdprom> jvvv: yeah, it looks like a stdlib for people who are trying to solve X, but apparently cant google for the tool/5 LOC that solved it 20 years ago, i dont understand who whould use this
2026-07-01 09:59:47 <f_> I dunno, probably doesn't need to be an alpine package
2026-07-01 10:00:00 <ncopa> i dont think it needs to be alpine package
2026-07-01 10:00:23 <f_> "Shell Superpowers for AI Agents" ok right I'm excited for when another one of these runs rm -rf --no-preserve-root /*
2026-07-01 10:00:26 <bdprom> they're trying way too hard with the massive testimonial section, and too AI heavy, looks icky
2026-07-01 10:00:34 <ncopa> they can use eval "$(<URL>)"
2026-07-01 10:00:43 <ncopa> to install it if they want it
2026-07-01 10:00:58 <f_> 
ACTION never understood why you'd want to give shell access to an AI

2026-07-01 10:01:03 <bdprom> ncopa: hard agree
2026-07-01 10:01:21 <f_> 
ACTION doesn't even trust other people to give shell access to on his laptop, why would he trust an LLM for this

2026-07-01 10:01:22 <bdprom> this level of slop doesnt need to be in aports imho
2026-07-01 10:01:37 <f_> ncopa: agreed
2026-07-01 10:02:22 <f_> the apkbuild also looks like llm slop I guess (though not good at figuring that out)
2026-07-01 10:05:03 <ncopa> if the APKBUILD is slop or not is kind of irrelevant IMHO. I wouldn't want this in apk even if it was all human made
2026-07-01 10:05:36 <ncopa> it looks to me like a tool to install and run all kinds of tools as user. no root required
2026-07-01 10:05:54 <f_> Fair
2026-07-01 10:05:55 <ncopa> so you could just run everything as root, in a container
2026-07-01 10:06:17 <fabricionaweb> I cant say if is slop but it doesnt look good
2026-07-01 10:06:47 <bdprom> MR message looks sloppy (em-dashes), but it's hard to tell these days
2026-07-01 10:07:05 <fabricionaweb> 
ACTION doest even know how to do em-dashes

2026-07-01 10:07:16 <f_> honestly I really hate when some people use em-dashes and they get accused for using AI
2026-07-01 10:07:24 <f_> em-dashes existed before AI
2026-07-01 10:07:41 <fabricionaweb> how do you do em-dash on your keeb?
2026-07-01 10:07:49 <f_> but looking at this I think it's fair to assume they probably used a translator
2026-07-01 10:08:09 <f_> I only get suspicious about em-dashes when someone I know doesn't use them suddently starts using them
2026-07-01 10:08:17 <bdprom> f_: of course, but they were hardly ever used before LLMs, now they're a good signal that something was potentially written by one
2026-07-01 10:08:28 <ekatwired> bdprom: bdprom: I use em dashes
2026-07-01 10:08:57 <ncopa> I think think it is irrelevant if its AI or not. Its unclear what problem it solve, what value it brings to the table
2026-07-01 10:09:13 <f_> ^
2026-07-01 10:09:24 <ncopa> and after 5-10 mins look at it, it looks like it does it all wrong
2026-07-01 10:09:30 <f_> I feel we might be wasting our time with figuring out what part is written by AI
2026-07-01 10:09:49 <f_> guess no need to find more reasons to not accept it
2026-07-01 10:09:50 <ncopa> on basically every level
2026-07-01 10:31:48 <ekatwired> I really feel the urge to document libapk.
2026-07-01 10:31:55 <ekatwired> Is that something that would be welcome?
2026-07-01 10:53:47 <june> achill, hi i saw that you recently merged some atproto-related MRs by fabricio, one of which was a pds impl. would you maybe also want to look at !104392 ?
2026-07-01 11:12:47 <Sertonix[m]> WhyNotHugo: Do you want to open the maintainer= proposal or should I do that with your text?
2026-07-01 11:58:23 <lotheac> fabricionaweb: compose key or IME usually. https://lotheac.fi/s/fcitx-emdash.png (it's option number nine in the IME popup, after I typed "-")
2026-07-01 12:00:07 <fabricionaweb> thanks, I also figured on macos you can type option -
2026-07-01 12:00:21 <fabricionaweb> 
ACTION – I am not AI

2026-07-01 12:02:17 <WhyNotHugo> Sertonix[m]: I can open it. https://paste.sr.ht/blob/39e6b7228afbf2b2679b2806fd1c67521ca6a713 look good?
2026-07-01 12:03:08 <WhyNotHugo> fabricionaweb: I use compose: https://whynothugo.nl/journal/2024/07/12/typing-non-english-characters/
2026-07-01 12:03:44 <WhyNotHugo> compose-- = —
2026-07-01 12:03:52 <Sheila> shift-opt-hyphen will get you an em-dash—opt-hyphen by itself will only give you an en-dash.
2026-07-01 12:22:39 <Sertonix[m]> WhyNotHugo: looks good
2026-07-01 12:23:53 <WhyNotHugo> Sertonix[m]: this would be tsc, not aports, correct?
2026-07-01 12:31:00 <Sertonix[m]> Better would be https://gitlab.alpinelinux.org/alpine/council/-/work_items
2026-07-01 12:36:14 <achill> isnt that a purely technical decision?
2026-07-01 12:45:45 <WhyNotHugo> Sertonix[m]: ugh, sorry, already opened in tsc. Can you move it or shall I close and re-open?
2026-07-01 12:48:40 <Sertonix[m]> achill: it effects peoples workflow, they should be able to raise their concerns and have them addressed. Otherwise I expect that to be accepted relatively quickly (as in a few months)
2026-07-01 12:48:51 <Sertonix[m]> WhyNotHugo: I don't seem to have access for that
2026-07-01 12:54:32 <bdprom> any ideas why `abuild rootbld` (in community/neovim) would be failing with: "patch: **** Failed to set the owner of file runtime/ftplugin/lua.lua.oUIGIgl : Invalid argument"
2026-07-01 12:54:38 <bdprom> this seems to happen with all patches
2026-07-01 12:59:30 <achill> Sertonix[m]: i mean sure but that is still one of tsc's duties. the council handles community management and governance afaik
2026-07-01 13:00:48 <f_> but the tsc is broken?
2026-07-01 13:02:07 <Sertonix[m]> It seemed to me like the tsc was replaced with the council but I don't know
2026-07-01 13:02:14 <Sertonix[m]> bdprom: Which alpine/abuild version?
2026-07-01 13:03:15 <bdprom> Sertonix[m]: latest alpine edge abuild-3.18.0_rc1-r0
2026-07-01 13:08:20 <achill> f_: i mean thats no way to circumvint the tsc
2026-07-01 13:08:50 <achill> Sertonix[m]: no. technically the tsc is established again. its just waiting for the council to set an initial date of meet.
2026-07-01 13:15:36 <Sertonix[m]> bdprom: The output with the following patch might help to debug this: https://gitlab.alpinelinux.org/sertonix/aports/-/commit/e44d13e0f25a754fc39d619a46ad82270038aa07
2026-07-01 13:15:57 <f_> "the tsc is established again." nice!
2026-07-01 13:23:08 <bdprom> Sertonix[m]: https://dpaste.com/2X8XDP8KH
2026-07-01 13:23:38 <bdprom> i added -y to decode fds
2026-07-01 13:24:21 <bdprom> why does it need to chgrp to nobody :/
2026-07-01 13:31:21 <Sertonix[m]> Can you try with the strace... command replaced by "id"?
2026-07-01 13:32:56 <bdprom> uid=1000(user) gid=1000(user) groups=65534(nobody),65534(nobody),65534(nobody),65534(nobody),65534(nobody),65534(nobody),65534(nobody),1000(user)
2026-07-01 13:40:25 <Sertonix[m]> Maybe this?: stat $builddir/runtime/ftplugin/lua.lua
2026-07-01 13:42:39 <bdprom> https://dpaste.com/FJHFGGY7R
2026-07-01 13:51:00 <Sertonix[m]> Hm, that should have group 1000. What about the parent directory: stat $srcdir
2026-07-01 13:52:03 <bdprom> same:  Access: (2755/drwxr-sr-x)  Uid: ( 1000/    user)   Gid: (65534/  nobody)
2026-07-01 13:55:28 <Sertonix[m]> The sticky bit might be causing the issues here
2026-07-01 13:59:02 <ajhalili2006> good evening from the Philippines, could someone merge !103818 on my behalf (I already gave the new maintainer the LGTM) for me?
2026-07-01 14:01:35 <bdprom> Sertonix[m]: yeah thanks, i just noticed a load of my sys folders have +s for some reason.. wth.. `apk fix --directory-permissions` seems to have helped
2026-07-01 14:03:44 <Sertonix[m]> Ok, I might change something on the abuild side as well.
2026-07-01 14:04:15 <bdprom> nice, gonna reboot and test again with perms fixed
2026-07-01 14:05:58 <bdprom> yup, patch works now :)
2026-07-01 14:06:12 <bdprom> thanks for your help
2026-07-01 14:26:16 <alexaandru> Hi all! I got a few MRs: !103818 !103127 !103156 !103088 - if someone could look into them I'd appreciate it. Thank you!! :-)
2026-07-01 17:40:55 <witcher01> i'm trying to use coccinelle and get the error regarding python not being able to resolve a symbol in line 4 here: https://paste.sr.ht/~witcher/65b8ce289d6f771524a0bcb89a5ffb8281d95040. can someone share some advice on how to start debugging this?
2026-07-01 19:21:01 <Saijin_Naib[m]> If anyone has bandwidth, I would really appreciate a review of !97292 !97494 !99156
2026-07-01 19:44:17 <roselandgoose> jvvv, Sertonix: hmm, ok. In that case, what is the point of `update-conf -i` ?
2026-07-01 19:45:31 <roselandgoose> (if it no longer serves a function, I'd be happy to submit a PR/patch making its behavior non-optional)
2026-07-01 19:52:44 <JustSouptheyhe[m]> Where are the rules for atools-go pulled from? I see there's a lot of A# rules, but I'm unsure if they are just numbered in order of addition or if there's a separate document that explains them.
2026-07-01 19:56:10 <JustSouptheyhe[m]> (To clarify, I know they come from CODINGSTYLE.md, but I'm just asking what the order of the numbers in the A# means)
2026-07-01 19:57:19 <WhyNotHugo> JustSouptheyhe[m]: the best I can see is the filenames in atools-go's testdata, which have descriptive names.
2026-07-01 19:57:36 <WhyNotHugo> But doesn't atools-go also show the descriptions for them? There's  a Description field in the source for each one.
2026-07-01 19:58:49 <Sertonix[m]> roselandgoose: I think it should work for any files in /etc except for /etc/init.d. I don't use it though
2026-07-01 19:59:05 <JustSouptheyhe[m]> WhyNotHugo: Sorry, I seem very bad at explaining right now. What I mean is, what is the ordering system for the rules numbers. Does each rule just increment the number by one, is it in order of MR or of addition, etc?
2026-07-01 20:00:13 <Sertonix[m]> (Without checking I would guess that it's the index in an array)
2026-07-01 20:01:49 <roselandgoose> Right, update-conf works for everything but /etc/init.d.. but -i is specifically about init.d scripts... yet its behavior is redundant (at least in the case of all my systems) since it always ends up "updating" anyways, just via a different path through the script.
2026-07-01 20:03:53 <roselandgoose> (aside: the man page uses "accept" and "use", but the tool is called "update-" all refering to the same action xD)
2026-07-02 06:51:27 <puretryout[m]1> @achill: any clue about this fwupd build failure? https://gitlab.alpinelinux.org/alpine/aports/-/jobs/2419198#L1416 Seems a file should be generated while it's not but I'm unsure why this is happening
2026-07-02 06:53:58 <sam_> 99% sure it's a samurai vs ninja thing
2026-07-02 06:54:17 <sam_> (so a missing dep on the meson side)
2026-07-02 07:15:56 <jvvv> Has there been any talk about making abuild-rootbld overlay mount the whole APORTSDIR into the container so that aports like zfs-lts, xtables-addons-lts, et cetera, can be built with rootbld?
2026-07-02 07:16:31 <jvvv> Well, not overlay mounting it, but bind mounting into the overlay
2026-07-02 07:28:48 <jvvv> There is a catch-22 going on so that if you currently have the out of tree module package installed, it depends on the kernel it is built against, so now you can not build the new one without a rootbld, but rootbld will fail because the out-of-tree module aport references the kernel aport's APKBUILD, but in the rootbld container it does not exist
2026-07-02 07:30:17 <jvvv> I can work around all this by using a separate container / chroot, but its seems pretty messy
2026-07-02 09:31:58 <achill> puretryout[m]1: commented
2026-07-02 10:05:56 <Sertonix[m]> jvvv: The fix is to not source other APKBUILDs in an APKBUILD. I think I have a draft MR for that
2026-07-02 10:08:45 <Sertonix[m]> New abuild RC for alpine edge, breakages are probably a bug: gitlab.alpinelinux.org/alpine/abuild/-/compare/3.18.0_rc1...3.18.0_rc2
2026-07-02 10:18:02 <achill> thank you!
2026-07-02 11:12:19 <WhyNotHugo> Any feedback for !104788?
2026-07-02 12:23:34 <f_> btw, FYI in case anyone planned to upgrade kernels today, that https://cdn.kernel.org/pub/linux/kernel is a 404 now
2026-07-02 12:27:02 <f_> so you might hold off from upgrading kernels for now
2026-07-02 12:27:08 <f_> you might want to hold off from*
2026-07-02 14:56:24 <ikke> JustSouptheyhe[m]: ipsw has checksum failures
2026-07-02 14:56:58 <ikke> Can you confirm? https://tpaste.us/eNPE
2026-07-02 15:00:06 <Sertonix[m]> WhyNotHugo: Re cosmic review, I suspect the bump to be non-trivial but would be happy to find a way
2026-07-02 15:00:28 <Sertonix[m]> *the dependency patching
2026-07-02 15:04:08 <WhyNotHugo> Sertonix[m]: if the fix is in a newer release of the dependency, it should be just a matter of updating the lockfile.
2026-07-02 15:04:57 <WhyNotHugo> ikke: odd, checksums matched in CI
2026-07-02 15:05:34 <ikke> Doesn't match now, checked it locally
2026-07-02 15:06:31 <WhyNotHugo> ikke: https://gitlab.alpinelinux.org/justsoup/aports/-/commit/e415eee1757015dbe9e66e2ffede4f88dff90a9e
2026-07-02 15:06:54 <ikke> 2 weeks ago
2026-07-02 15:06:54 <WhyNotHugo> checksum here is the failing one, CI built fine
2026-07-02 15:07:19 <WhyNotHugo> for the checksum to change, upstream would have had to rewrite the tag
2026-07-02 15:07:22 <ikke> projects tend to republish source archives
2026-07-02 15:07:25 <ikke> yes
2026-07-02 15:07:30 <ikke> that happens more than you think
2026-07-02 15:08:00 <ikke> if someone still has the original archive, we can use diffoscope to see what's changed
2026-07-02 16:09:08 <JustSouptheyhe[m]> It doesn't surprise me. That project doesn't scream good practices. It looks like they rewrote the tag to update some CI key or something.
2026-07-02 16:12:31 <JustSouptheyhe[m]> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/104818
2026-07-02 16:12:54 <ikke> ftr, pkgrel bump is not required, but I can fix that
2026-07-02 16:13:55 <JustSouptheyhe[m]> I guess the sources aren't stored in the index, so there's no need for their checksums to be either. That makes sense then. Thanks
2026-07-02 16:14:05 <ikke> The package has not been built yet
2026-07-02 16:14:17 <JustSouptheyhe[m]> Sorry that it immediately exploded. I might just fork ipsw and use that source since upstream is a bit volatile.
2026-07-02 18:43:05 <jvvv> Sertonix[m]: I think that what you say about APKBUILDs not sourcing other APKBUILD has merit. Unfortunately I am unsure of the best way forward
2026-07-02 19:20:31 <Sertonix[m]> Long term it would be good to have source and binary repository consistency analysis. I have some notes for that but not yet well usable.
2026-07-02 19:58:46 <jvvv> Ok. I am interested to help with this topic, I would just be more comfortable if it handled slowly so that the aports the will be effected can be adjusted in an amicable way.
2026-07-03 00:07:46 <Sertonix[m]> jvvv: Most APKBUILDs use test -f which avoids the failures in the sandbox. Not mounting APORTSDIR was mandatory since the APORTSDIR detection is broken for third-party repositories and other edge cases.
2026-07-03 00:20:52 <jvvv> Sertonix[m]: That all makes sense to me. I will look at the aports that source other APKBUILDs and see if I can incorporate the test -f or something akin to that.
2026-07-03 00:31:41 <jvvv> It would not be as invasive as I had thought. Most of the ones I have looked at are already using the test -f block and so far those that are not look like would be not to bad to convert
2026-07-03 06:53:55 <ncopa> Hey all devs... congrats on building the future most popular distro in the world! \o/ https://www.reddit.com/r/linux/comments/1um4n4k/linux_has_won_os_race/
2026-07-03 07:01:32 <jvvv> \o/
2026-07-03 07:25:18 <fabricionaweb> didnt notice that apple container became 1.0
2026-07-03 08:10:27 <jvoisin> \o/
2026-07-03 08:43:49 <ncopa> i didnt know that apple container supports nested virtualization
2026-07-03 08:50:03 <wener> Hi, mr like this !104379 unable to build in 1h, what shuold i do ?
2026-07-03 08:51:47 <bitfehler> wener: you can set the timeout for pipelines in the settings of your fork project, settings>CI/CD>General pipelines
2026-07-03 09:22:06 <wener> thx, i'll try that
2026-07-03 09:23:13 <fabricionaweb> would someone mind to take a review on this one !102821 
2026-07-03 12:21:06 <WhyNotHugo> I wish we had an env var NO_VENDOR, which tells all build processes to use system dependencies instead of vendored ones. So instead if setting dozens a different variable for each package/dependency, there's a global one they all respect.
2026-07-03 12:21:34 <WhyNotHugo> The hard part might be getting buy-in from upstreams.
2026-07-03 12:32:36 <sam_> https://lore.kernel.org/distributions/b0726076ea438d59d8b7b5d0f44a4ed6ca11d418.camel@gentoo.org/
2026-07-03 12:36:28 <dne> lol
2026-07-03 12:38:26 <abby> > Proposing something that contradicts the GNU Coding Standards is a non-starter.
2026-07-03 12:40:16 <f_> > Meson will not implement this environment variable either
2026-07-03 12:40:17 <f_> :\
2026-07-03 12:58:44 <jvoisin> sick sad world
2026-07-03 13:06:06 <elibrokeit> the target userbase for such a variable is projects that think vendoring is a good idea and add vendored dependencies in their code
2026-07-03 13:06:22 <elibrokeit> consider the obvious conflict of interest
2026-07-03 13:08:52 <abby> yep
2026-07-03 13:21:30 <f_>  08:53 <@ncopa> Hey all devs... congrats on building the future most popular distro in the world! \o/ https://www.reddit.com/r/linux/comments/1um4n4k/linux_has_won_os_race/
2026-07-03 13:21:34 <f_> >  Post is awaiting moderator approval. 
2026-07-03 13:21:35 <f_> :(
2026-07-03 13:21:40 <f_> I didn't get to see that :(
2026-07-03 15:50:50 <strophy> Could I get a review of !95951 please while it is still fresh and passing
2026-07-03 16:50:33 <wener> !104379 grpc is almost ready, rerun riscv64 only for 6h timeout, hope this help abseil-cpp
2026-07-03 16:51:49 <alexaandru> hello! If someone could take a look at !103818 I'd appreciate it. It is a security update: https://github.com/cli/cli/releases/tag/v2.96.0
2026-07-03 17:03:48 <andypost[m]> something is wrong with Gitlab - even after rebase it said merge conflicts  !104869
2026-07-03 21:08:59 <roselandgoose> jvvv, Sertonix[m]: do either of you have any sense of where one might expect to find 'editing packaged init.d scripts is discouraged' ?
2026-07-03 21:09:03 <roselandgoose> perhaps https://wiki.alpinelinux.org/wiki/OpenRC
2026-07-03 21:09:42 <roselandgoose> since that is linked from the Overview/FAQ pages a new user would likely visit
2026-07-03 21:10:14 <roselandgoose> but on the other hand https://wiki.alpinelinux.org/wiki/Writing_Init_Scripts is perhaps more likely to be read when a user is trying to achieve some specific init.d goal
2026-07-03 21:10:36 <roselandgoose> also, if anyone disagrees with the quoted sentiment, please let me know!
2026-07-03 21:53:54 <jvvv> roselandgoose: Just so that you don't think you are being ignored, I have been looking into finding where a rule about the topic of etc/init.d policy. I haven't found it, but that does not mean it does not exist.
2026-07-03 21:57:30 <jvvv> If it exists, then we probably need a it to be better placed or linked to.
2026-07-03 22:00:45 <roselandgoose> thanks for letting me know :)
2026-07-03 23:09:45 <Sertonix[m]> There might not exist much information aside of the apk-tools source code
2026-07-04 07:37:49 <Saijin_Naib[m]> If anyone has bandwidth, I would really appreciate a review of !97292 !97494 !99156, as these have been open like four months and I could really use them for working
2026-07-04 13:09:06 <vmignot> Is there any way to diagnostic an issue that only appears when launching a service through supervise-daemon ? For few weeks, the mumble-server service keeps crashing (flagged as stopped) right after being started and I can't reproduce it by lauching the server myself
2026-07-04 13:14:35 <quinq> vmignot, make sure it's running with same users and parameters
2026-07-04 13:14:49 <vmignot> Yup, already did it
2026-07-04 13:16:27 <quinq> And environment
2026-07-04 13:21:10 <vmignot> even running it through `env -i` does not reproduce the issue
2026-07-04 13:22:00 <vmignot> And there is nothing in the logfile of course
2026-07-04 13:23:22 <vmignot> is there a way to make algitbot link to a specific commit ?
2026-07-04 13:29:34 <vmignot> that maybe related to a55a088d651ba6c32087aee9c17a074d952980eb
2026-07-04 15:59:52 <ekatwired> Yalls i heard some rumours about systemd getting packaged for Alpine
2026-07-04 16:07:53 <JustSouptheyhe[m]> Where did you hear that?
2026-07-04 16:10:00 <ekatwired> JustSouptheyhe[m]: i don't exactly know, i heard it from someone.
2026-07-04 16:12:13 <ekatwired> That's why I am asking as i could not find evidence.
2026-07-04 16:12:50 <JustSouptheyhe[m]> Well, its not true. There's a lot that would need to go into such a decision, both technical and social, and that hasn't been brought up yet. It could happen one day, but there's no real plans for that any time soon.
2026-07-04 16:13:07 <f_> I have a question though
2026-07-04 16:13:31 <f_> why do so many people care if systemd is packaged in alpine or not
2026-07-04 16:13:48 <quinq> Because it's a virus
2026-07-04 16:13:58 <f_> systemd getting packages in alpine means nothing
2026-07-04 16:14:05 <quinq> It does
2026-07-04 16:14:12 <f_> especially if it's just in testing/
2026-07-04 16:14:38 <ekatwired> systemd ain't baad
2026-07-04 16:14:45 <f_> alpine is already packaging bits and pieces of systemd anyway
2026-07-04 16:14:47 <quinq> Until you have to use it
2026-07-04 16:14:55 <f_> (eudev, elogind...)
2026-07-04 16:14:55 <ekatwired> This is so 2012
2026-07-04 16:15:04 <f_> quinq: but you don't have to use it
2026-07-04 16:15:10 <quinq> When it wasn't poisoned 
2026-07-04 16:15:19 <quinq> f_, that's the naive thinking
2026-07-04 16:15:21 <f_> systemd getting packaged doesn't mean openrc is getting replaced
2026-07-04 16:15:29 <quinq> lel
2026-07-04 16:15:37 <quinq> Ask the other system that said the same thing
2026-07-04 16:15:42 <quinq> s/system/&s/
2026-07-04 16:15:48 <ekatwired> Oh dear what have i done.
2026-07-04 16:15:53 <f_> who? postmarketOS? We still provide OpenRC support in postmarketOS
2026-07-04 16:16:04 <f_> ¯\_(ツ)_/¯
2026-07-04 16:16:10 <quinq> any system
2026-07-04 16:16:13 <ekatwired> I like systemd because it is useful for me. Could be better as anything
2026-07-04 16:16:19 <quinq> If you don't know, then obviously you don't know much
2026-07-04 16:16:35 <f_> Debian also supports non-systemd init systems just fine
2026-07-04 16:16:52 <f_> you can literally install openrc from their repos and use it
2026-07-04 16:17:05 <quinq> Have you done it?
2026-07-04 16:17:28 <f_> I don't run debian, but I've seen quite a bit of chatter around debian openrc support in #openrc
2026-07-04 16:17:38 <f_> and I've skimmed through their docs too
2026-07-04 16:17:58 <ekatwired> quinq: i may assure you that i use Linux systems for over 15 years and I genuinely like using systemd.Yea, they do some crazy stuff, esp. lately but it is for fucks sake just software.
2026-07-04 16:18:19 <ekatwired> It is not like NixOS which is more like religion than software (/s)
2026-07-04 16:18:44 <f_> this message was written from postmarketOS running openrc, and as you know, postmarketOS also has systemd supported.
2026-07-04 16:18:46 <quinq> ekatwired, I assure you I believe that you do
2026-07-04 16:18:51 <quinq> But this isn't really about you
2026-07-04 16:18:55 <ekatwired> It isn't
2026-07-04 16:19:02 <ekatwired> I am not making feature request.
2026-07-04 16:19:10 <ekatwired> I just asked if a thing i heard is true.
2026-07-04 16:19:29 <quinq> Sorry, must have missed it, I'm answering f_'s question
2026-07-04 16:19:44 <ekatwired> quinq: sorry then?
2026-07-04 16:19:50 <ekatwired> Chat got messy
2026-07-04 16:20:22 <f_> but as I said alpine already packages bits and pieces of systemd anyway
2026-07-04 16:24:54 <JustSouptheyhe[m]> ekatwired: You did nothing wrong. Some people have... opinions.
2026-07-04 16:26:36 <f_> and to be clear I'm not the kind of person who would say "yay use systemd it's the best thing ever". I run openrc lol, on all my devices, and I find efforts to build alternative init systems very interesting and glad they're there. That said, I'm not anti-systemd either
2026-07-04 16:27:20 <ekatwired> I think systemd ain't great but i like it more than shell scripts
2026-07-04 16:27:53 <f_> eh, honestly I find openrc scripts to be quite interesting.. like, they can be quite declarative if you want, but they can also be functional as needed
2026-07-04 16:28:09 <f_> which I think is pretty neat
2026-07-04 16:28:18 <ekatwired> I have a big ick in having a non-pure language for these things
2026-07-04 16:29:03 <ekatwired> We now have package manager which defines stuff in Lua with io access and stuff and it is a nightmare to work with without actually executing the actions.
2026-07-04 16:30:10 <quinq> ekatwired, no need to apologize, it's a discussion :)
2026-07-04 16:30:29 <quinq> We can disagree on some things maybe, it's not an issue in itself
2026-07-04 16:30:35 <ekatwired> I would be all for having a systemd replacement but in a way PipeWire displaced Pulse
2026-07-04 16:30:42 <f_> oh
2026-07-04 16:30:52 <f_> pipewire replaced pulse in a very cool way I think
2026-07-04 16:30:54 <ekatwired> Wanna see something in also reinvent-the-world refreshing style as systemd.
2026-07-04 16:31:16 <quinq> JustSouptheyhe[m], everybody have opinions yeah
2026-07-04 16:31:43 <f_> I guess the main issue people have with systemd is it's not just an init system, but a rather huge collection of tools also
2026-07-04 16:31:55 <ekatwired> That is the least problem i have with it myself
2026-07-04 16:32:10 <f_> to the point where it probably becomes incorrect to call systemd an init system as a whole
2026-07-04 16:32:15 <ekatwired> I don't think init system is a good thing to think about it
2026-07-04 16:32:17 <ekatwired> Yea
2026-07-04 16:32:43 <f_> especially given quite a few of these utils *can* run without systemd (the init) as PID1
2026-07-04 16:33:11 <f_> like, take systemd-backlight for example xD
2026-07-04 16:33:22 <ekatwired> systemd core itself is more of a... dependency system state thingee.
2026-07-04 16:33:44 <f_> you can even build systemd-udev standalone nowadays
2026-07-04 16:33:45 <ekatwired> Declare what you want and based on what is fulfilled stuff happen.
2026-07-04 16:33:57 <ekatwired> libudev-zero my behated
2026-07-04 16:35:31 <f_> and like
2026-07-04 16:35:40 <f_> I'm honestly very happy people are working on alternatives
2026-07-04 16:36:08 <f_> systemd is what's widely used today, but who knows, maybe in the future everyone will toss it out as better solutions materialize
2026-07-04 16:36:18 <f_> just like everyone stopped running on bare sysvinit
2026-07-04 16:37:00 <ekatwired> It is 2026, i am horrified on what will come next.
2026-07-04 16:37:05 <f_> xD
2026-07-04 16:37:26 <f_> dunno, openrc and s6 are interesting to me, gardenhouse too
2026-07-04 16:37:26 <ekatwired> Funnily enough, I am a mostly Rust dev and stuff and I am scared when i see some Rust rewrite of stuff.
2026-07-04 16:37:42 <ekatwired> I saw some S6 code.
2026-07-04 16:37:47 <ekatwired> I wanna unsee that
2026-07-04 16:38:47 <ekatwired> Many of Rust rewrites are:- vibe slop
2026-07-04 16:38:47 <ekatwired> - oh look we rewrited this C thing in Rust. Nah nah. If you are rewriting something really, do actually make something new. Fix architectural issues.
2026-07-04 16:39:35 <f_> ekatwired: can you join #alpine-offtopic btw
2026-07-04 16:39:47 <ekatwired> Tbh ye would be better
2026-07-04 16:39:54 <f_> ^^
2026-07-04 17:11:09 <skarnet> ekatwired: if you have constructive criticism of s6's code, I'm all ears
2026-07-04 17:40:50 <Ermine> inb4 semicolons after spaces
2026-07-04 17:42:12 <ekatwired> skarnet: just very scuuched together, unclear meaning of what each things done.
2026-07-04 17:42:18 <quinq> That's like a weird way of saying space before simocolons
2026-07-04 17:42:28 <ekatwired> that is the least thing that concerns me
2026-07-04 17:42:33 <ekatwired> if (verbosity >= 2) strerr_warni3x(PROG, ": connected to ", argv[0]) ;
2026-07-04 17:42:33 <ekatwired>  if (localname)
2026-07-04 17:42:33 <ekatwired>  size_t n = strlen(localname) ;
2026-07-04 17:42:33 <ekatwired>  {
2026-07-04 17:42:33 <ekatwired>  if (n > IPCPATH_MAX) n = IPCPATH_MAX ;
2026-07-04 17:42:34 <ekatwired>  memcpy(modif + i, localname, n) ;
2026-07-04 17:42:34 <ekatwired>  i += n ; modif[i++] = 0 ;
2026-07-04 17:42:36 <ekatwired>  }
2026-07-04 17:42:36 <ekatwired>  like this concerns me more
2026-07-04 17:42:47 <ekatwired> one single-line if no braces with another underneath…
2026-07-04 17:43:12 <ekatwired> naming of variables give absolutely no clue what they are.
2026-07-04 17:44:53 <quinq> localname most likely means local name
2026-07-04 17:45:06 <quinq> n is the idiom name for a number/length
2026-07-04 17:45:12 <Ermine> in this example, i don't see unclear names either
2026-07-04 17:45:13 <quinq> modif is a modifiable buffer
2026-07-04 17:45:27 <ekatwired> oh names was not related to that snippet
2026-07-04 17:45:30 <ekatwired> mostly of the if thing
2026-07-04 17:45:51 <quinq> i is some kind of index but I lack context
2026-07-04 17:46:33 <quinq> I'm not a huge fan of single-line if either
2026-07-04 17:46:38 <ekatwired> APK source code is nice
2026-07-04 17:47:34 <ekatwired> i can Control+F/B through it and can ± say what it does
2026-07-04 17:47:44 <Ermine> i don't like single-line if without braces, but like... it's not the hill i'd die on
2026-07-04 17:48:26 <ekatwired> https://github.com/skarnet/s6/blob/main/src/supervision/s6-notify-fd-from-socket.c what the hell are the names of these variables idk
2026-07-04 17:48:56 <Ermine> the snippet clearly appends value of localname to modif, up to a limit
2026-07-04 17:49:22 <Ermine> you gave an example but your concerns are not related to it...
2026-07-04 17:51:19 <Ermine> what i can agree with is that you need to know skalibs to make sense of the code
2026-07-04 17:52:15 <skarnet> variables named addr for an address, addrlen for the length of an address, sock for a socket, buf for a buffer, and found for a boolean that tells you if a notification has been found... they sound unintuitive to you?
2026-07-04 17:52:18 <skarnet> okay
2026-07-04 17:53:18 <skarnet> you don't like if one-liners? that's your right. They're practical though.
2026-07-04 17:53:36 <skarnet> if these are the only concerns you have with the code, I can rest easy. :)
2026-07-04 17:53:43 <Ermine> wgola
2026-07-04 17:55:08 <skarnet> unhappy with all the gol things, but how would you name "variable holding the arguments of argument-taking options after calling the primitive"?
2026-07-04 17:55:44 <skarnet> difficult to have intuitive naming for something as specialized, unless you make it very long, which I don't want to because it's used everywhere afterwards
2026-07-04 17:55:54 <skarnet> the only solution is to have a convention and stick to it
2026-07-04 17:57:43 <Ermine> i mean if you know the context you'll have no problem figuring out the meaning
2026-07-04 17:59:37 <Ermine> the convention you've set serves primarily to you, and it will serve you well, and you'll most probably have no problem recalling things after like 2-month vacation
2026-07-04 18:00:02 <skarnet> and if you don't know the context then you study the code, like you do with every single piece of code you're unfamiliar with 
2026-07-04 18:00:03 <Ermine> for outsiders, though, the first stop is skalibs documentation and code
2026-07-04 18:00:30 <skarnet> yes, the lack of skalibs documentation is a real issue, but that's not what was said
2026-07-04 18:00:58 <Ermine> i'm not saying that's bad actually
2026-07-04 18:01:38 <Ermine> If I say "typmod" you'll likely fail to understand
2026-07-04 18:02:50 <skarnet> without context I won't understand, but if you show me a few pieces of code where it's consistently used in the same manner, I will eventually derive the meaning
2026-07-04 18:04:15 <Ermine> it has something to do with postgresql's records/types and i don't understand it myself :]
2026-07-04 18:04:25 <skarnet> XD
2026-07-04 18:04:54 <Ermine> Speaking of large codebases, good luck grokking them without a cross-referencer
2026-07-04 22:46:12 <f_> skarnet: my main concern about the code style is why do you keep putting a space before a semicolon? xD
2026-07-04 22:46:29 <f_> but I honestly do if one-liners too from time to time
2026-07-04 22:48:49 <abby> it's a french thing !
2026-07-04 22:49:54 <f_> oh, I guess ?
2026-07-04 22:50:34 <f_> but I mean, the code style is alright
2026-07-04 22:50:41 <f_> I've seen faaaaaaar worse
2026-07-04 22:53:02 <quinq> abby, only for those, not for ;!
2026-07-04 22:53:21 <f_> such as https://github.com/hardkernel/u-boot/blob/odroidc2-v2015.01/drivers/mmc/aml_sd_emmc.c xD
2026-07-04 22:53:28 <f_> good ol' bsp code
2026-07-04 22:53:36 <f_> and that's just u-boot
2026-07-04 22:53:49 <f_> (downstream u-boot to be clear, not the upstream u-boot)
2026-07-04 22:54:03 <quinq> Doesn't look so bad
2026-07-04 22:54:22 <f_> it looks bad
2026-07-04 22:54:46 <quinq> You've got an easy C life
2026-07-04 22:54:56 <f_> weird commented code everywhere, inconsistent tabs v.s. spaces
2026-07-04 22:55:03 <f_> you got it all
2026-07-04 22:55:33 <f_> strange `#if 1` preprocessor directives xD
2026-07-04 22:56:01 <quinq> You mean if 0
2026-07-04 22:56:12 <f_> oh there's #if 1 too
2026-07-04 22:56:18 <quinq> It's not cleaned up but then again, it's quite readable
2026-07-04 22:56:30 <f_> or there was in another file..
2026-07-04 22:57:20 <f_> quinq: what you see here is code used in production
2026-07-04 22:57:33 <quinq> Well, that's just U-Boot
2026-07-04 22:57:40 <f_> that's downstream u-boot fork
2026-07-04 22:57:51 <quinq> That what U-Boot is
2026-07-04 22:57:55 <quinq> downstream forks
2026-07-04 22:57:58 <f_> that amlogic gives out to its customers
2026-07-04 22:58:06 <quinq> Like any other vendor
2026-07-04 22:58:10 <f_> indeed
2026-07-04 22:58:36 <f_> and my god it's chatty over serial
2026-07-04 22:58:48 <f_> all sorts of debug messages
2026-07-04 23:02:22 <quinq> Don't def SD_DEBUG_ENABLE
2026-07-04 23:02:46 <f_> no I mean on consumer devices that ship with this junk
2026-07-04 23:02:59 <f_> I never compiled this, it requires ancient versions of gcc
2026-07-04 23:03:11 <f_> and you need to disable warnings and all that...
2026-07-04 23:27:39 <Ermine> downstream code is also subtly broken sometimes...
2026-07-05 09:05:28 <ncopa> I updated kernel to 6.18.38 but I get errors. unable to handle page fault for address ...
2026-07-05 11:20:29 <adhawkins> Any chance someone could take a quick look at my Merge Request? Will the CI failures stop it being merged? I can't see why it should only fail on those two. https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/104839
2026-07-05 11:22:38 <JustSouptheyhe[m]> It failing to build on an arch is a blocker. You can either try fixing the issue with that arch, which would mean patching the program, or just disable it if it would be way too much to fix.
2026-07-06 09:08:07 <adhawkins> Thanks JustSouptheyhe[m]. I seem to remember seeing something similar on one arch on a previous update, but the other one is new I believe.
2026-07-06 09:08:14 <adhawkins> Will look in to it.
2026-07-06 09:19:22 <lindsay> Regarding !104934, When download some source tarball from download.kde.org, "Connection reset by peer" error occurs in all 5 retries on ppc64le. The source tarball that fails each time is different. I don't known how to deal with it.
2026-07-06 09:29:26 <lindsay> It is possible that download.kde.org randomly redirects to mirrors.xtom.com, and mirrors.xtom.com blocks our ppc64le runner IP
2026-07-06 10:01:47 <lindsay> Oh, it's because the tls certificate of mirrors.xtom.com has expired.
2026-07-06 10:27:26 <f_> hi, can I get some review on !97202 ? It's been sitting for a little while now
2026-07-06 12:13:25 <Habbie> first time i'm doing a confd file, any comments? (will MR soon) https://gitlab.alpinelinux.org/Habbie/aports/-/commit/f2562599b486b8ec19d99f682377fb7ec2aed271
2026-07-06 12:31:37 <Habbie> now !104950
2026-07-06 13:34:38 <adhawkins> Is there a way I can run the riscv64 tests locally to try to fix the issue I'm having with !104839 ?
2026-07-06 15:34:38 <roselandgoose> adhawkins: there is certainly a way, but I dont know how easy.. I havent tried myself. assuming you dont have any riscv hardware: do you have experience with qemu or cross-compiling?
2026-07-06 15:35:19 <adhawkins> I've found some instructions on setting up docker to use qemu to emulate. Seems to be working and getting similar build errors. Now to work out why it's failing!
2026-07-06 15:36:07 <roselandgoose> nice :) glad to know there's good docs out there for quickly spinning that up!
2026-07-06 15:39:05 <adhawkins> I hate to say it, but Google's API did the trick...
2026-07-06 15:39:20 <adhawkins> a/API/AI/
2026-07-06 16:09:13 <Sertonix[m]> On a typical alpine system it would be: doas apk add abuild-rootbld && doas rc-service procfs start && rc-service binfmt start && CBUILD=riscv64 abuild rootbld
2026-07-06 19:11:38 <Habbie> we don't have Olivier Mauras (maintainer of main/lmdb) in here?
2026-07-06 19:22:17 <dne> Habbie: he hasn't been maintainer since 2017, according to git history
2026-07-06 19:22:32 <Habbie> oh i totally mixed up those two lines
2026-07-06 19:22:42 <Habbie> ncopa, hi. if you are ever tempted to bump main/lmdb to 1.0, don't
2026-07-06 19:23:01 <Habbie> ncopa, you'd join a growing list of distros that did that instead of making a separate lmdb1 package and regret the day
2026-07-06 19:23:19 <Habbie> this week's winner is https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=296530
2026-07-06 19:24:35 <dne> indeed: https://github.com/LMDB/lmdb/blob/mdb.master3/libraries/liblmdb/upgrading.doc#L15-L21
2026-07-06 19:25:13 <Habbie> yes
2026-07-06 19:25:31 <Habbie> and the 1.0 lib doesn't even have the decency of telling you "this is an old version file" instead of "this is not a database"
2026-07-06 19:25:40 <dne> heh
2026-07-06 19:26:00 <Habbie> so we had a Moment today where we (powerdns, a liblmdb consumer) thought we really messed up
2026-07-06 19:26:16 <Habbie> only saving grace was that the user reporting it was a known chaos monkey, so i didn't worry immediately
2026-07-06 19:32:51 <dne> (sub)packaging mdb_dump/mdb_load might be useful in the meantime
2026-07-06 19:33:39 <Habbie> openbsd's lmdb 1.0 port also builds mdb_dump-0.9, which is a neat trick
2026-07-06 19:33:46 <Habbie> dne, but, in what meantime?
2026-07-06 19:36:06 <dne> not sure :)
2026-07-06 19:37:04 <Habbie> ack
2026-07-06 19:37:15 <Habbie> i'm not even sure what the right approach is
2026-07-06 19:37:22 <Habbie> i just know 'bump it to 1.0 and call it a day' is not
2026-07-06 20:39:19 <ncopa> thanks for the headsup
2026-07-06 20:44:05 <Habbie> np
2026-07-06 20:44:10 <Habbie> feel free to ping me when the time comes
2026-07-06 20:44:13 <Habbie> i'll likely have more thoughts
2026-07-06 21:29:36 <Saijin_Naib[m]> Thanks for the kew merge, mio
2026-07-06 21:29:58 <Saijin_Naib[m]> The dev appreciates me keeping current and is really responsive
2026-07-06 21:33:30 <Saijin_Naib[m]> If anyone has bandwidth, I would really appreciate a review of !97292 !97494 !99156
2026-07-06 21:33:51 <Saijin_Naib[m]> I like pitivi, but it is broken currently. I want to fix it and use it
2026-07-06 21:34:12 <Saijin_Naib[m]> Textpieces helps me do regex and transforms and other stuff I find tricky in my documentation work
2026-07-07 09:59:56 <ptrc> https://git.alpinelinux.org/aports/tree/community/claws-mail/APKBUILD#n107
2026-07-07 10:00:03 <ptrc> is it just me, or is that technically a syntax error?
2026-07-07 10:00:10 <ptrc> the last '} should not be there
2026-07-07 10:01:09 <Habbie> it renders in black on black so that seems legal to me ;)
2026-07-07 10:01:13 <Habbie> (what is up with this color scheme)
2026-07-07 10:01:24 <ptrc> oof, right
2026-07-07 10:01:29 <Habbie> 
ACTION git pull

2026-07-07 10:01:51 <ptrc> https://ptrc.gay/LVFyKuVm.png
2026-07-07 10:01:57 <ptrc> with the offending character highlighted :p
2026-07-07 10:02:48 <Habbie> i see it
2026-07-07 10:03:01 <Habbie> so we actually call tr '-' '_}'
2026-07-07 10:03:04 <Habbie> and tr doesn't care about the second char
2026-07-07 10:03:09 <ptrc> mmhm
2026-07-07 10:05:18 <Habbie> and i learned that this works
2026-07-07 10:05:20 <Habbie>  # echo _ }
2026-07-07 10:05:22 <Habbie> _ }
2026-07-07 10:05:29 <Habbie> shell doesn't go "that's not matching an opening"
2026-07-07 10:06:26 <ptrc> the wonders of an underspecified syntax
2026-07-07 10:06:48 <adhawkins> Going back to my MR (!104839) is it possible / acceptable to disable tests for a single architecture until the test issue is resolved?
2026-07-07 10:07:03 <Habbie> adhawkins, plenty of ports do that
2026-07-07 10:13:14 <Sertonix[m]> ptrc: IIRC between a token and a } you always need a newline or ; as seperation (maybe some others are possible as well).
2026-07-07 10:13:37 <ptrc> so not a syntax error, buuut still a typo :3
2026-07-07 10:14:56 <Sertonix[m]> Yes
2026-07-07 10:48:06 <staceee> is there know constraints over fanotify api call on the gitlab CI runners?
2026-07-07 10:53:22 <ikke> Only in so far docker / kubernetes would block it (seccomp, etc)
2026-07-07 11:00:36 <staceee> context: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/104988#note_628889
2026-07-07 11:01:48 <staceee> right apparently this is related to docker CAP_SYS_ADMIN capability
2026-07-07 11:10:58 <ikke> unfortunate
2026-07-07 11:27:56 <adhawkins> Habbie: How would I go about disabling checks for a specific arch?
2026-07-07 11:30:23 <Habbie> find an apkbuild that uses CARCH to set !check, like pdns-recursor or assimp
2026-07-07 11:30:45 <Habbie> an alternative can be seen in pdns, which is entirely disabled on s390x because of the failing test suite
2026-07-07 11:30:49 <Habbie> that's a choice you can think about
2026-07-07 11:31:04 <ikke> adhawkins: do all tests need to be disabled, or only specific tests?
2026-07-07 13:40:10 <Sertonix[m]> Is there any (intentional) usage of the contributor comment in APKBUILDs generated by newapkbuild, apkbuild-pypi, apkbuild-cpan?
2026-07-07 13:50:19 <ptrc> bleh: https://ptrc.gay/ywApJlRi.txt
2026-07-07 13:50:23 <ptrc> i'm not even sure why this happens
2026-07-07 13:51:02 <ptrc> does it run post-upgrade with pre-upgrade files?
2026-07-07 13:51:24 <ptrc> actually.. i guess so?
2026-07-07 14:00:05 <Sertonix[m]> Did it upgrade libskarnet/libutmps before execline?
2026-07-07 14:01:31 <ptrc> yup
2026-07-07 14:07:19 <Sertonix[m]> With a quick test package the post-upgrade script is run after the new files are commited. Which arch / alpine version is this?
2026-07-07 14:16:16 <Sertonix[m]> It seems like coreutils readlink has thrown that error.
2026-07-07 14:24:29 <Sertonix[m]> Hm, apk-tools doesn't know that upgrading libskarnet, then running a post-upgrade script and then upgrading  utmps-libs doesn't work when the post-upgrade script is using coreutils commands.
2026-07-07 14:29:43 <Sertonix[m]> It might be necessary to mandate that install scripts run 'busybox <cmd>' to avoid issues like this and https://gitlab.alpinelinux.org/alpine/aports/-/work_items/16928
2026-07-07 15:06:53 <skarnet> Sertonix[m]: that makes sense, I'll update the post-upgrade scripts, I'll make a release in a week or so anyway
2026-07-07 15:07:33 <skarnet> completely forgot that coreutils was linked against utmps so you can't rely on them in the middle of a major upgrade
2026-07-07 15:07:58 <skarnet> bb will have the same issue but there's busybox.static, isn't it?
2026-07-07 15:09:14 <ikke> but busybox.static is not installed by default
2026-07-07 15:09:39 <Sertonix[m]> bb does not have the issue due to packages using install scripts getting a dependency on /bin/sh with all implementations depending on busybox. So busybox is always usable once install scripts (that aren't self hosted) are run
2026-07-07 15:11:13 <skarnet> so as long as there's no post-upgrade script in utmps itself it should work because bb will always be upgraded first?
2026-07-07 15:12:20 <Sertonix[m]> busybox is using utmps-static so even a post-upgrade script in utmps should work
2026-07-07 15:13:29 <skarnet> awesome
2026-07-07 19:24:36 <jvvv> !104997 assigned @fabled because the MR initially had a grub change. I split that out, but fabled is still assigned. Can / should that be changed? I don't think fabled should have to be assigned at this point unless he wanted to be.
2026-07-07 19:35:25 <jvvv> ikke: Thank you!
2026-07-07 20:18:08 <jvvv> Could I get a review of !103066? I sent an email to the AntoniAloyTorrens[m] three weeks ago, but no response. I can back off on the taking over maintainership... I only did that because the package has been in a broken state for so long and has had three MRs to fix it but still no joy.
2026-07-07 22:56:03 <Ariadne> jvvv: does radxa dragon q6a boot in EL2 or is it behind gunyah?
2026-07-07 23:04:02 <jvvv> Ariadne: You are definitely more knowledgable about EL2, so I need to do some reading to fully understand how to answer that. If it helps, I am booting on bare metal using efi via grub.
2026-07-07 23:04:18 <Ariadne> dmesg | grep EL2 should tell you
2026-07-07 23:05:28 <jvvv> That returned nothing, so not EL2 I think. I can post the full dmesg log if you like?
2026-07-07 23:05:36 <Ariadne> yeah that would be awesome
2026-07-07 23:07:13 <jvvv> https://tpaste.us/JLNg
2026-07-07 23:08:12 <Ariadne> [    0.011769] CPU: All CPU(s) started at EL1
2026-07-07 23:08:14 <Ariadne> bummer :(
2026-07-07 23:08:55 <Ariadne> i had heard that radxa might be fused in a way that allows it to run in EL2 by default, but it seems qcom still has their malware in it
2026-07-07 23:09:20 <Ariadne> and yes, in the context of a general purpose computer, gunyah is definitely malware ;)
2026-07-07 23:10:17 <jvvv> There might be a setting in the bios I can flip, I just need to hook up my ttl with  minicom
2026-07-07 23:10:42 <Ariadne> nah the configuration is fused into the SoC
2026-07-07 23:11:31 <Ariadne> i am also told that 'qualcomm snapdragon elite x2' SoCs no longer have this malware, but i am not going to spend $4k buying a machine with one to find out right now
2026-07-07 23:12:05 <Ariadne> (why $4k?  because my country has been taken over by fascists who are also, frankly, idiots and do not understand economics)
2026-07-07 23:12:26 <jvvv> I think we live in same country
2026-07-07 23:12:53 <Ariadne> (also AI boom affecting DRAM pricing, which is clearly a cartel and...)
2026-07-07 23:13:30 <jvvv> It is all pretty depressing and/or infuriating
2026-07-07 23:14:34 <Ariadne> it is ok, we could buy memory from the chinese and break the back of the cartel immediately, but that would make too much sense, but apparently there are 'national security' concerns with this idea :D
2026-07-07 23:17:13 <jvvv> There is a switch in the bios to enable EL2. I'm booting that now, will let you know
2026-07-07 23:18:32 <jvvv> https://tpaste.us/84BV
2026-07-07 23:20:41 <jvvv> [    0.012085] CPU: All CPU(s) started at EL2
2026-07-07 23:21:22 <jvvv> Ariadne: Thanks for asking me about that. I need to do that reading so I can try to understand the ramifications.
2026-07-07 23:21:42 <Ariadne> oh, nice.
2026-07-07 23:22:04 <Ariadne> EL2 means gunyah is gone and you can run KVM guests (or any other hypervisor)
2026-07-07 23:22:20 <Ariadne> thanks, i've ordered one :)
2026-07-07 23:23:07 <jvvv> Ah, nice. That is cool, because I was hoping to do some messing around with just that. Now you have help to make that much more possible
2026-07-07 23:24:20 <jvvv> Cool, if you ever have any input about the aports I have going for it, I will gladly welcome input
2026-07-07 23:34:04 <jvvv> Ariadne: I am using the radxa 7056A armored case / heat sink which works really good on low/medium load. A small fan when I am compiling helps keep the temps down (45-62C). It was pretty reasonable at $15usd or so.
2026-07-07 23:35:16 <jvvv> When compiling the kernel, and using the added fan, most temps stayed in the mid 50s
2026-07-07 23:41:34 <Ariadne> there is a mechanism to make gunyah uninstall itself at runtime but it depends on tcblaunch.exe from windows :(
2026-07-07 23:42:46 <Ariadne> when the radxa arrives, i am going to see if it supports microsoft secure launch to gain EL2, and if so, build a harness to allow for automated fuzzing of the MS-SL surface
2026-07-08 00:08:00 <jvvv> There is a 'Window RhProxy driver state' setting that may pertain that, I'm not certain
2026-07-08 00:08:52 <Ariadne> nah
2026-07-08 00:09:20 <Ariadne> like the main reason sllaunch is necessary is because it isn't easy to build a harness around laptops
2026-07-08 00:09:31 <Ariadne> this code was written by morons, it has tons of security problems
2026-07-08 00:11:45 <Habbie> well that's one confusing organisation name https://github.com/quic/gunyah-hypervisor
2026-07-08 00:15:24 <Ariadne> unfortunately the module that enables tcblaunch.exe to work is not in there
2026-07-08 00:34:46 <Ariadne> however, the radxa EL2 process is interesting
2026-07-08 00:53:10 <jdknight> Looking for some insights towards submitting packages. Added a package on aports (!86746) that has been sitting open for over a year for 'testing'. While I keep maintaining the merge request, not sure what else I should be doing to progress it. My goal is to eventually get it into 'community', if at all possible.
2026-07-08 08:10:43 <adhawkins> ikke: Apologies, only just seen this. There are only a few tests that fail, but the way the tests run (parametrize_from_file) might make it difficult to disable specific ones.
2026-07-08 08:17:54 <adhawkins> Actually, upstream reports that it could be due to an out-of-date version of py3-inform. The log shows the riscv64 CI run installing py3-inform v1.36, but the version in Edge is v1.37. Any idea why this might be?
2026-07-08 08:18:46 <adhawkins> https://gitlab.alpinelinux.org/adhawkins/aports/-/jobs/2423676
2026-07-08 08:19:08 <adhawkins> https://pkgs.alpinelinux.org/package/edge/community/riscv64/py3-inform
2026-07-08 08:19:44 <adhawkins> https://pkgs.alpinelinux.org/package/edge/community/x86_64/py3-inform
2026-07-08 08:20:32 <adhawkins> x86_64 is 1.37-r0, but riscv64 is 1.36-r1.
2026-07-08 12:04:03 <Sertonix[m]> The riscv64 is behind on building packages and they will only be uploaded once that is done. Tests would likely pass on the builders if that is the only dofference.
2026-07-08 12:51:16 <adhawkins> Sertonix[m]: Ah ok. How long are we talking before it will catch up, any idea?
2026-07-08 13:03:39 <Sertonix[m]> At the moment it is not catching up
2026-07-08 13:04:41 <adhawkins> Ok. What's the best thing I can do for my MR (!104839) to allow it to continue? Just make a note that these tests should pass once it catches up?
2026-07-08 13:13:09 <Sertonix[m]> Adding that node might help
2026-07-08 13:14:19 <adhawkins> I'll do that and see where we get to. Thanks Sertonix[m].
2026-07-08 20:57:28 <bl4ckb0ne> is there a way to keep the files when abuild rootbld fails?
2026-07-08 20:57:56 <bl4ckb0ne> it seems to ignore -K
2026-07-08 21:00:13 <bl4ckb0ne> regular build is failing, the aport folder is mounted through sshfs and im getting operation not permitted when trying to apply the patches
2026-07-08 21:11:09 <jvvv> bl4ckb0ne: for rootbld, you need to look in /var/tmp/abuild.XXXXXX (tmpfile suffix transformed)
2026-07-08 21:11:46 <jvvv> It will be in something like: /var/tmp/abuild.XXXXXX/tmp/{src,pkg}
2026-07-08 21:13:22 <bl4ckb0ne> empty
2026-07-08 21:14:18 <bl4ckb0ne> > intel-compute-runtime: Cleaning up build chroot
2026-07-08 21:14:21 <bl4ckb0ne> hm that explains why
2026-07-08 21:16:16 <bl4ckb0ne> got it!
2026-07-08 21:16:20 <bl4ckb0ne> abuild -K rootbld
2026-07-08 21:16:29 <bl4ckb0ne> and /var/tmp has it, thanks jvvv 
2026-07-08 21:16:42 <jvvv> np
2026-07-08 21:17:27 <jvvv> I thought you were issuing 'abuild -K rootbld' before, so I am a bit confused
2026-07-08 21:18:10 <bl4ckb0ne> i was doing `abuild rootbld -K`
2026-07-08 21:18:31 <jvvv> Ah, yeah, that makes sense
2026-07-08 21:19:22 <bl4ckb0ne> i had to check the sources to see why it wasnt working at first
2026-07-08 21:20:55 <jvvv> You will probably need root priv to remove that abuild.XXXXXX directory. Container privs are weird
2026-07-08 21:22:08 <bl4ckb0ne> gotcha thanks
2026-07-09 02:56:52 <jvvv> I don't if I have asked this before: for MR reviews, should the reviewer or the MR author resolve an open thread?
2026-07-09 03:00:58 <lotheac> there is no established process. i try to usually give the reviewer a chance to react but in my experience most won't resolve any threads
2026-07-09 03:01:33 <lotheac> i think it's fine to resolve it yourself as the author if you think the feedback has been addressed
2026-07-09 03:19:43 <jvvv> Thanks
2026-07-09 04:49:20 <ikke> Yeah, that should be fine
2026-07-09 06:29:59 <wener> can someone take a look !105042 !104941  , and !104379 , this takes way too long to build, last is all green, but clicked the rebase (with pipline, my bad), currently still building.
2026-07-09 07:38:38 <thwr> Hey, I've noticed that the clang/ld issue has been fixed, but the packages haven't been rebuiilt yet?
2026-07-09 12:14:40 <midasi> Could I get a review on the MRs !104128 !104125 !103660 !103658 !103656 !103350 ? I prepared them some weeks ago and rebased today.
2026-07-09 12:58:12 <durrendal> Can I also get a review on the following MRs? I cannot upgrade saltstack until at minimum py3-saltext-alpine gets merged back in, otherwise the package will break on all Alpine installs. And the internet archive package is necessary for us to start migrating unsupported apk repos to the Internet Archive for long term archival reference/use. !102522 !103015 !103016 !103225
2026-07-09 12:58:14 <durrendal> !104314
2026-07-09 14:05:18 <lotheac> durrendal: i'm a bit puzzled why you have !check but still define check(). is the idea that you'll enable the checks if the required packages become available at some point?
2026-07-09 14:05:25 <lotheac> (in the saltext packages)
2026-07-09 14:06:16 <durrendal> yes that's the hope, I tried to package the salt package deps ~a year ago but it languished and never got merged.
2026-07-09 14:07:37 <lotheac> ok, then i guess those are fine
2026-07-09 14:07:50 <durrendal> I maintain saltext-alpine, nebula, and incus upstream though, so I am testing these elsewhere fairly thoroughly. If it helps
2026-07-09 14:08:25 <durrendal> s/salt package deps/salt test deps/
2026-07-09 14:12:19 <lotheac> merged the salt stuff and left review comments on py3-internetarchive
2026-07-09 14:16:18 <durrendal> <3 thank you so much lotheac 
2026-07-09 14:19:44 <durrendal> also making the changes requested in the ia mr, should be ready in a second, just making sure it builds first.
2026-07-09 17:19:09 <fabricionaweb> Who could give a review here? !102821 
2026-07-10 06:14:09 <PureTryOut> Sertonix: I can't build various packages with rootbld due to `ERROR: alpine-baselayout-3.7.2-r1: failed to commit var/run: Is a directory`. Is that an abuild bug by any chance?
2026-07-10 06:42:08 <caskd> this might seem like a inconsistency between the version of baselayout installed in the bwrap root dir to what is done within the build dir
2026-07-10 06:42:54 <caskd> i've tried to have a short look but i don't notice anything obvious 
2026-07-10 08:09:27 <Sertonix[m]> abuild>=3.17.0 should only create that directory if PACKAGER_PRIVKEY starts with /var/run. I would guess that one package installed before alpine-baselayout includes /var/run even through it should only use /run.
2026-07-10 08:22:11 <adhawkins> Can someone explain (or point me to an example) of how to disable some (or all) tests for a particular architecture? My MR (!104839) is being held up because the riscv64 build fails tests due to the builders for that arch lagging behind (and hence containing an old version of a package which breaks the tests).
2026-07-10 12:35:13 <hannesbraun> adhawkins: do you mean something like this? https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/varlink/APKBUILD#L18
2026-07-10 14:14:16 <adhawkins> hannesbraun: That's what I've ended up doing. I wanted to skip specific tests, but as the tests are specified using parametrize_from_file I couldn't work out how to do that.
2026-07-11 09:55:35 <quinq> Why do cabal depends on both llvm15-libs and llvm16-libs? sounds weird
2026-07-11 12:49:26 <ekatwired> quinq: Sounds like typical Haskell
2026-07-11 13:02:43 <quinq> ^^
2026-07-11 13:03:12 <quinq> $ doas apk del cabal
2026-07-11 13:03:13 <quinq> After this operation, 1378.8 MiB of disk space will be freed.
2026-07-11 13:03:17 <quinq> Yes please
2026-07-11 19:39:59 <vpzom> Looks like the crates.io API now blocks requests with the curl user agent, so the packages that use that as a source are failing to build
2026-07-12 07:55:29 <Saijin_Naib[m]> Thanks for the pitivi takeover merge, ikke. Now I can edit video again, haha
2026-07-12 10:21:33 <ikke> yw
2026-07-12 10:46:45 <ikke> Anyone knows how to increase the go test timeout in aws-lc (using cmake)?
2026-07-12 10:46:55 <ikke> it fails on rv64 on the default 10m timeout
2026-07-12 10:47:46 <ikke> The go code lives in ssl/test/runner, but cannot figure out what is invoking those tests
2026-07-12 11:05:05 <Asmadeus> https://github.com/aws/aws-lc/blob/main/CMakeLists.txt#L1538 ? You should be able to set AWS_LC_GO_TEST_TIMEOUT env to something like 30m (see around line 1417 where it's used)
2026-07-12 11:05:24 <Asmadeus> ikke: ^
2026-07-12 11:13:06 <ikke> Ah ok, will try, thanks!
2026-07-12 13:42:05 <Sertonix[m]> Another abuild RC for alpine edge, notably with using some XDG directories. But still any breakage of existing things is probably a bug. https://gitlab.alpinelinux.org/alpine/abuild/-/compare/3.18.0_rc2...3.18.0_rc3
2026-07-12 16:15:36 <elibrokeit> hello. codeberg has broken archive checksums again: https://codeberg.org/Codeberg/Community/issues/2861
2026-07-12 16:16:25 <elibrokeit> presumably all distros are affected, so be forewarned 
2026-07-12 16:22:43 <quinq> “But we don't particularly consider the checksum of a on-deman archive generation to be stable” wat
2026-07-12 16:25:48 <panekj> quinq: it's backed by git-archive which doesn't generally have stability guarantee because of different tar/gzip implementations, GitHub had same issue before
2026-07-12 16:27:03 <panekj> https://github.blog/open-source/git/update-on-the-future-stability-of-source-code-archives-and-hashes/
2026-07-12 16:29:14 <elibrokeit> git fixed it by guaranteeing that they always shell out to gzip as was traditional, therefore opting out of "git upstream can break us"
2026-07-12 16:29:25 <elibrokeit> *github fixed it
2026-07-12 16:29:56 <elibrokeit> codeberg appears to have "fixed it" by adding a switch on git commit date to choose whether to use internal or external compressor
2026-07-12 16:30:26 <elibrokeit> which means they are entirely unable to restore to older versions of the git builtin 
2026-07-12 16:30:33 <elibrokeit> insane
2026-07-12 16:31:01 <HRio> the flac upgrade that was just merged seems to make pyside6-dev uninstallable, due to this req: "required by: libsndfile-1.2.2-r2[so:libFLAC.so.12]"
2026-07-12 16:31:10 <panekj> imo works (and has worked) as intended
2026-07-12 16:31:59 <panekj> never has it been promised those endpoints will give stable format
2026-07-12 16:33:14 <elibrokeit> the fundamental utility of offering endpoints at all, is in offering stable ones
2026-07-12 16:33:15 <HRio> fossdd: heads-up on the flac issue and libsndfile
2026-07-12 16:33:24 <elibrokeit> this is a ridiculous copout, sorry
2026-07-12 16:33:50 <f_> btw, can someone remove the "mr-stable" label on !97202 ? It's not stale, it's just waiting for review
2026-07-12 16:34:00 <quinq> That's a bit f*cked-up if your compression algorithm/implementation doesn't give out reproducible results
2026-07-12 16:34:16 <panekj> it's reproducible
2026-07-12 16:34:25 <quinq> So what's the issue?
2026-07-12 16:34:30 <panekj> different libraries and tools have different defaults
2026-07-12 16:34:47 <elibrokeit> git internally reimplements gzip "so you don't have to shell out on windows msys2"
2026-07-12 16:35:02 <elibrokeit> and git changes their byte stream for gzip, from version to version of git
2026-07-12 16:35:02 <quinq> Right, so that's the caller's responsibility to make sure it's configured as expected
2026-07-12 16:35:53 <panekj> you can crank compression level up or down and you will suddenly have checksum mismatch, which is why it's stupid to think that this will be a stable interface in any way
2026-07-12 16:36:02 <panekj> if you absolutely need stability then you can just check out the repo
2026-07-12 16:36:04 <elibrokeit> by configuring it to use /usr/bin/gzip -cn, yes 
2026-07-12 16:36:10 <elibrokeit> and codeberg doesn't do this
2026-07-12 16:36:41 <elibrokeit> they switch on external gzip and internal "lmao no idea what it produces" depending on analysis of git commit metadata 
2026-07-12 16:36:50 <quinq> I don't think that's good advice to tell people to clone always as a mean of dist
2026-07-12 16:36:58 <panekj> why not?
2026-07-12 16:37:08 <quinq> Because it's a big waste of resources
2026-07-12 16:37:14 <panekj> how so?
2026-07-12 16:37:16 <quinq> It doesn't scale
2026-07-12 16:37:26 <panekj> and it scales that git-archives does the same?
2026-07-12 16:37:50 <quinq> That's internal implementation, it's not worse at least
2026-07-12 16:38:00 <panekj> you can get a single ref --depth=1, how is that worse than git-archive
2026-07-12 16:38:22 <quinq> The user doesn't know what's used internally
2026-07-12 16:38:38 <elibrokeit> excuse my my good friend
2026-07-12 16:38:42 <elibrokeit> this is a distro channel
2026-07-12 16:38:43 <panekj> we're talking about devs here
2026-07-12 16:38:57 <elibrokeit> presumably alpine doesn't git clone in an APKBUILD 
2026-07-12 16:39:19 <quinq> A developer is a user in terms of interface, it's not a “job” matter
2026-07-12 16:39:31 <panekj> a slight improvement over current status would be to allow multiple hashes
2026-07-12 17:29:28 <Sertonix[m]> The number of possible gzip implementations is probably >= 100. Multiple hashes (alone) don't seem to help for such things.
2026-07-12 17:32:25 <Sertonix[m]> Hashing the decompressed content is something to consider but should be done with care IMHO
2026-07-12 20:03:30 <ikke> I think in general you want to verify the content before you process it in any kind
2026-07-12 20:20:43 <ikke> ayakael7: is there an electron update pending? It needs to be rebuilt against flac, so would be nice if that can be combined
2026-07-12 20:20:53 <ikke> !105233
2026-07-12 20:30:16 <Sertonix[m]> ikke: wget/curl are already processing it and might even have decompressed some parts. But yes the attack surface is something to be concerned about.
2026-07-12 20:30:57 <ikke> why would curl/wget decompress parts of an archive?
2026-07-12 20:31:29 <ikke> Shouldn't those tools treat it as opaque bytes (unless you explicitly tell it to do something with it)?
2026-07-12 20:33:38 <Sertonix[m]> Cause HTTP spec allows for compressed data transmission.
2026-07-12 20:39:21 <craftyguy[m]> could a maintainer please take a look at !105194 ? thanks!
2026-07-12 20:41:37 <ikke> craftyguy[m]: I'd like ncopa to confirm this, I won't merge this without his approval
2026-07-12 20:42:07 <craftyguy[m]> ok np, I thought it might be trivial enough, since this is following the documented behavior of pam.d
2026-07-12 20:42:33 <craftyguy[m]> (and technically everything currently installing into /etc/pam.d should use /usr... 😅)
2026-07-12 20:43:01 <quinq> Transport layer compression is different from content compression
2026-07-12 20:43:26 <quinq> That would be very hacky at best mixing both, but most likely just ready to break anytime
2026-07-12 20:44:32 <ikke> quinq: thanks, I was pondering how to word it, but that was my thought as well
2026-07-12 20:45:38 <quinq> Yes curl has some option to mix both, in order to work around misconfigured http servers, but it's not really make for transparently decompress content data
2026-07-12 20:45:50 <quinq> s/make/made/
2026-07-12 21:04:23 <Sertonix[m]> I mean that exposing decompression code to unchecked input is already the case. So we already violate "I think in general you want to verify the content before you process it in any kind"
2026-07-12 21:04:55 <Sertonix[m]> I don't mean messing with compression on the HTTP layer.
2026-07-12 21:14:20 <elibrokeit> executing a hash function is already "processing" the opaque bytestream, so I think there's no need to be overly pedantic about it
2026-07-12 21:15:11 <elibrokeit> the biggest danger is that tarball extraction is far, far, far, far, far, far, far less safe than zlib decompression
2026-07-12 21:15:35 <elibrokeit> and cannot be made safer since it inherently involves asking the contents of the tarball to politely tell you what filenames to extract to
2026-07-12 21:16:05 <elibrokeit> tar extractors have had entirely too many CVEs around this, and even are reluctant to promise that it's safe to extract an unknown tarball at all
2026-07-12 21:17:02 <elibrokeit> it is blatantly unreasonable to ask downstream users to "simply" validate the unpacked contents 
2026-07-12 21:18:17 <elibrokeit> the best you could do is ask downstream users to decompress and then do validations on the uncompressed *.tar file, which seems much harder to specify in a package manager, and means doing nontrivial work *twice*
2026-07-12 21:19:02 <elibrokeit> and *still* doesn't solve the fact that upstream git occasionally flirts with threatening to change the tar stream too, not just the gzip stream
2026-07-12 21:19:53 <elibrokeit> and it also unfortunately means that caching systems break if you allow the download to vary, regardless of what level the validator runs at
2026-07-12 21:36:40 <Sertonix[m]> The tar stream could probably be normalized to prevent most git changes from having an effect.
2026-07-12 21:37:32 <quinq> We could standardize tar and call it pax
2026-07-12 21:58:00 <elibrokeit> Sertonix[m]: this sounds like a revolutionary discovery that you should certainly explain to the authors of tools which include this file format parser, so they can solve 40 years of security bug reports with one tiny change they just didn't think of
2026-07-13 02:34:27 <comk> are we talking about the fun feature that tar will treat `-f foo:bar.tar` as a host:path argument and try connecting to the `foo` host over network unless filename prefixed with ./ or path made absolute ? otherwise thats a trivia i found surprising at some point
2026-07-13 02:40:47 <elibrokeit> I care more about the long history of CVEs with regard to stuff like symlink escapes
2026-07-13 05:06:28 <quinq> comk, that's GNU for you
2026-07-13 05:07:13 <Ariadne> how on earth does it connect to the remote end
2026-07-13 05:07:22 <Ariadne> like what protocol is it expecting to speak lol
2026-07-13 05:09:50 <ikke> Ariadne: context?
2026-07-13 05:10:13 <quinq> rsh of course :D
2026-07-13 05:10:23 <quinq> (or ssh)
2026-07-13 05:10:33 <quinq> “The remote machine should have the rmt(8) command installed.”
2026-07-13 05:11:12 <quinq> ikke, in the context of GNU tar trying to connect to the remoste host "foo" when passed an archive filename of "foo:whatever.tar"
2026-07-13 05:13:48 <ikke> ah
2026-07-13 07:36:36 <hannesbraun> Does someone have an idea why the lang split function fails on pretty much every package I'm trying to build? Did I miss something? I noticed this in !105233
2026-07-13 07:39:03 <ikke> hannesbraun: my mr failed as well indeed. No idea yet 
2026-07-13 09:29:27 <ikke> Sertonix[m]: any change in abuild that could explain that?
2026-07-13 09:31:06 <ikke> https://gitlab.alpinelinux.org/alpine/abuild/-/commit/ddc695168a22ba35c6236ae2b8e07a3e6e0678d2 perhaps
2026-07-13 10:04:15 <Sertonix[m]> I think I found the issue, will push a fix
2026-07-13 10:15:39 <PureTryOut> Yeah a bunch of packages on mine are failing on that as well while they actually succeeded in CI (so I guess that ran before an abuild upgrade). It's blocking the builders now
2026-07-13 10:16:58 <Sertonix[m]> !105257
2026-07-13 10:29:31 <PureTryOut> That fixed it yeah, thanks!
2026-07-13 14:17:24 <roselandgoose> regarding users editing init.d scripts
2026-07-13 14:17:57 <roselandgoose> now that I see how much can be done with conf.d files, I see why editing init.d shouldn't be neccessary
2026-07-13 14:18:56 <roselandgoose> but imo some notes need to be added advising users who would reach for adding "after foo" to an inti.d depend() should instead add 'rc_after="foo"' to conf.d
2026-07-13 14:19:18 <ikke> nod
2026-07-13 14:19:47 <roselandgoose> I guess now is the time for me to figure out how contributing to the wiki works hehe...
2026-07-13 14:20:05 <ikke> Let me know if you have issues
2026-07-13 14:51:01 <WhyNotHugo> `Running split function lang` seems to be failing for various packages, even on rootbld without changes, and also in CI.
2026-07-13 14:51:35 <PureTryOut> Yeah it was fixed today, read back this chat a few messages up
2026-07-13 15:32:01 <Sertonix[m]> Need to wait for gcc compilation to be fixed on x86_64.
2026-07-13 15:33:45 <ikke> lotheac is working on something
2026-07-13 17:56:54 <ikke> Rebooting deu-t1-1, which also hosts dev containers
2026-07-13 18:10:16 <roselandgoose> contributing to wiki was easy! I expected more friction, given these days of AI spam. Glad to see the clankers and trolls haven't soiled this wiki yet :)
2026-07-13 18:12:05 <ikke> heh
2026-07-13 18:12:17 <ikke> There are some spam protections, but they only trigger if you try to add links
2026-07-13 18:33:43 <borgserk> Hello folks. I am trying to setup rsyslog in alpine to receive http logs. To my surprise, the rsyslog-http package does not include imhttp.so module. Can this be included?
2026-07-13 18:36:27 <ikke> borgserk: could you open an issue at https://gitlab.alpinelinux.org/alpine/aports/-/work_items?
2026-07-13 18:47:52 <borgserk> There is an issue for this already: alpine/aports#17935, but someone has closed it
2026-07-13 18:49:10 <ikke> "The metric names are invalid, so I don’t think it’s actually usable"
2026-07-13 19:10:06 <borgserk> Thanks for the context, but this looks like a very specific bug in the /metrics endpoint. My use case is posting http messages from my js client to my alpine server. imhttp does it efficiently if I am wrong, since it is written in C.
2026-07-13 19:10:27 <borgserk> *if I am not wrong
2026-07-13 19:16:27 <ikke> ok, perhaps you can open a new issue, outlying your specific usecase
2026-07-13 19:18:43 <borgserk> thanks ikke, will do
2026-07-13 20:21:52 <Sertonix[m]> WhyNotHugo: If you have any ideas on how to make APKBUILD(5) a more usable/complete spec help would be appreciate with https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/546
2026-07-13 21:47:28 <ikke> In case anyone is interested, this is the script I've been testing to rebase + merge MRs. I use it together with nq to queue merges
2026-07-13 22:41:18 <ryandrfr> hello
2026-07-14 04:01:46 <lotheac> ikke: i am interested in that script but i don't see an actual link
2026-07-14 04:02:12 <ikke> https://tpaste.us/dWo8?hl=true
2026-07-14 04:02:38 <lotheac> thanks
2026-07-14 09:52:44 <caskd> regarding !103264, if a critical functionality of the package fails tests wouldn't it make more sense to disable that arch than provide a potentially broken implementation?
2026-07-14 09:56:30 <caskd> i will imply yes but feel free to tune in if you use lego on x86/armhf and it works fine for you
2026-07-14 10:17:05 <dne> well, it's only one of many dns providers
2026-07-14 10:19:07 <caskd> no i mean, the PEM tests
2026-07-14 10:19:13 <caskd> the dns provider isnt critical i would say
2026-07-14 10:19:20 <dne> ah, ok
2026-07-14 10:19:32 <caskd> as i assume most people would want PEM not pkcs/DER
2026-07-14 10:20:01 <caskd> and if the encoding is incorrect it could cause weird issues
2026-07-14 10:21:01 <dne> right, the test that used to be skipped
2026-07-14 10:21:11 <caskd> yeah
2026-07-14 10:21:27 <caskd> it probs has to do something with 32 bit if only those specific archs fail
2026-07-14 10:43:23 <skarnet> go-away is preventing me from accessing gitlab (and creating an MR and stuff), what's the standard procedure to get past it?
2026-07-14 10:46:05 <skarnet> I solved it by going to the home page, I was logged out, I signed in, and then go-away was gucci
2026-07-14 10:46:12 <skarnet> it just wants to see an id!
2026-07-14 10:48:56 <caskd> it might help to use a git user agent sometimes but this heavily depends on the deployment config
2026-07-14 11:18:48 <ikke> skarnet: would be good to have a request id to see what is happening
2026-07-14 11:25:39 <skarnet> ikke: I closed the tab now, but if it happens again (probably when I get logged out in a month) I'll keep the request id for you
2026-07-14 11:52:47 <achill> ikke: re merge script: maybe we can make a contrib/ dir in abuild to collect these kind of maintainer scripts
2026-07-14 11:52:48 <achill> i also have a bunch of them lying around
2026-07-14 12:08:32 <skarnet> Could someone please merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/105325 whenever they have the time? thanks!
2026-07-14 12:09:16 <skarnet> algitbot, you there? \o/
2026-07-14 12:09:35 <skarnet> you got go-awayed like me, didn't you algitbot?
2026-07-14 12:19:26 <skarnet> achill: that was fast, thanks!
2026-07-14 12:33:39 <Sertonix[m]> achill: I would rather have such scripts linked in the wiki or similar. In my experience the best scripts are highly opinionated rather than good for most people. Everybody can create a repo on gitlab.a.o and maintain that in the commit/code/stability style they are comfortable with. For example I can just force push to the main branch of my alpine-scripts repo :)
2026-07-14 12:34:21 <achill> i mean ikkes script worked without changes for me and is a huge relief
2026-07-14 12:35:19 <achill> having that available for all mergers in a alpine repo would make it easier to discover etc
2026-07-14 12:37:37 <achill> it could be a  place where people can just store their scripts and others can get inspired by them, adapt it to their needs, make some stuff easier for new contributors like finding all packages to be rebuilt
2026-07-14 12:38:01 <Sertonix[m]> Having it linked somewhere allows discovery as well.
2026-07-14 12:38:15 <PureTryOut> What merged script is this?
2026-07-14 12:38:22 <PureTryOut> *merge script
2026-07-14 12:38:31 <achill> https://tpaste.us/dWo8
2026-07-14 12:38:43 <achill> takes care of rebases and merges for aports MRs
2026-07-14 12:38:51 <Sertonix[m]> I would rather not use a repository that is already >= 500MB when cloned as cloud for people to host their scripts.
2026-07-14 12:39:32 <achill> then maybe we can make a seperate abuild-contrib repo in the alpine/ namespace
2026-07-14 12:39:47 <achill> also e.g. ncopa's releng script is also what i had in mind
2026-07-14 12:40:39 <Sertonix[m]> Or we save some time of the infra team and use the user namespaces that gitlab already gives access to.
2026-07-14 12:41:33 <achill> the alpine namespace would make it easier to discover tho
2026-07-14 12:41:34 <Sertonix[m]> And I will probably have my scripts on codeberg, which would need to be linked to anyways.
2026-07-14 12:41:34 <PureTryOut> Oh if I merge something I just do it via Gitlab's web UI 🤔
2026-07-14 12:41:55 <achill> PureTryOut: me aswell, but batching a bunch of MRs and waiting for rebases can be time consuming here
2026-07-14 12:42:33 <Sertonix[m]> achill: besides the dead go, gcc-patches and similar outdated repos that would be misleading if people were to look at these
2026-07-14 12:42:48 <achill> then we should archive them lol?
2026-07-14 12:42:54 <PureTryOut> I wrote a Python thing to do bulk updates for KDE and such. Can select packages on a version, the group= variable/comment I add to a few things or what changed compared to git master and can then mass bump version, pkgrel or build it all. Quite useful
2026-07-14 12:43:01 <PureTryOut> achill: yeah fair enough I suppose
2026-07-14 12:43:16 <achill> archived repos are hidden from the default view
2026-07-14 12:43:26 <Sertonix[m]> Ether way, what is the problem with linking external repositories?
2026-07-14 12:43:46 <achill> i like having a canonical repo in the alpine namespace that e.g. other alpine devs can merge and stuff
2026-07-14 12:44:07 <PureTryOut> It would be nice to have a central place for such useful maintainer stuff tbh
2026-07-14 12:44:20 <achill> yea
2026-07-14 12:45:20 <Sertonix[m]> At least I run my scripts from the git repo and need them to work on command, so having other alpine devs merge stuff would be a bad thing at least for me.
2026-07-14 12:46:34 <achill> well, then verify commits when you git pull or idk. but i dont want to gatekeep a contrib repo, i want it to be accessible
2026-07-14 12:47:03 <achill> i would also trust other devs to merge stuff when they'd think "it works" and thats enough for me
2026-07-14 12:47:23 <Sertonix[m]> How is there a gatekeep when a scripts is linked, copiable and changable?
2026-07-14 12:47:33 <achill> i meant re merging stuff
2026-07-14 12:47:35 <Sertonix[m]> *and republishable
2026-07-14 12:49:18 <Sertonix[m]> Scripts still "work" if you rename an option or change a default but loose the advantage of being opinionated.
2026-07-14 12:49:20 <achill> also since i want to bump the bus factor for releng. having a repo where ncopas script is stored, would help someone do the work. and a abuild-contrib repo sounds easy enough for that
2026-07-14 12:50:35 <achill> Sertonix[m]: then maintain a local branch or idk, you dont have to use it. i just want a place where people can change each others scripts and dont need to reinvent the wheel. because thats what i do, when i dont know everybody's git repo or home directory
2026-07-14 12:51:24 <Sertonix[m]> Or git clone, git push to a new repo and change url. Has a bus-factor of ~8 billion
2026-07-14 12:51:54 <achill> and is very annoying instead of just giving all alpine devs access 🤷
2026-07-14 12:51:57 <achill> i dont get why no
2026-07-14 12:52:00 <achill> *not
2026-07-14 12:54:28 <achill> (if the problem is work for the infra team, i dont know why we cant just give all devs permission to create new repos in alpine/ and be done with it)
2026-07-14 12:57:09 <Sertonix[m]> Princible of least privilidged is something which would be better for security of the alpine infra.
2026-07-14 12:58:06 <achill> sure, that just means more work for the infra team. somewhere is the line between "permissions of devs" vs. "more work for the infra team".
2026-07-14 12:58:52 <achill> and generally speaking, imo we trust all developers, remove permissions after they are inactive for x time, so I'm fine with giving them more permissions
2026-07-14 12:59:02 <Sertonix[m]> You are only there if you require some scripts to be in the alpine/ namespace.
2026-07-14 12:59:46 <achill> or merge any other MR in any other repo :)
2026-07-14 13:42:00 <ikke> I have merged a ton of MRs last couple of days using that script
2026-07-14 13:42:03 <ikke> just queue one after the other
2026-07-14 13:42:15 <ikke> (well, with some helper scripts that invoke nq)
2026-07-14 16:05:57 <WhyNotHugo> I see that openrc scripts are all over the place when it comes to logging. Many discard logs, some pipe to syslog, other write to a specific log file, other have the service write its own logs.
2026-07-14 16:06:08 <WhyNotHugo> I think we should have some guideline and attempt to align all of them.
2026-07-14 16:06:53 <achill> i think that would be cool but how do you come to a solution that 1. doesn't break everyones setup 2. makes everyone happy
2026-07-14 16:07:19 <WhyNotHugo> In particular, I think having the service write its own log file is never preferred. And ideally logs shouldn't be discarded (which is openrc's default)
2026-07-14 16:07:43 <WhyNotHugo> achill: yeah, that's the tricky part. Perhaps what we want is a "global" config, have all services inherit that, and make that easily configurable.
2026-07-14 16:08:36 <achill> maybe yeah. maybe navi also has some ideas about that
2026-07-14 16:11:44 <jahway603[m]> That's a good idea to standardize the openrc service logging.
2026-07-14 16:15:03 <navi> after i manage to release 0.64, the main focus of 0.65 will be logging
2026-07-14 16:15:55 <achill> nice
2026-07-14 16:17:00 <navi> i'm trying to consider many things, but it'd like to a) have every service log somewhere by default, and b) avoid a fully custom logging structure that would make it harder to integrate with existing workflows
2026-07-14 16:17:30 <navi> better syslog integration and usage of posix's `logger` as the default sink per-service is a current consideration, i think
2026-07-14 16:18:19 <navi> would be nice if we could also have some way to introspect logs, specially for `rc-service ... status`, though doing this, and `b` at the same time is where the challenge rests
2026-07-14 16:52:03 <Sertonix[m]> If doing log introspection it would seem best to me to have users/loggers specify how that is done (or if it is even possible)
2026-07-14 16:52:54 <navi> one consideration i had was two variables, file and pattern, which status() would use to fetch them
2026-07-14 16:53:43 <navi> didn't think much about it yet
2026-07-14 16:54:22 <Sertonix[m]> Which would prevent any remote or custom file format logging to work?
2026-07-14 16:55:02 <navi> if the logs are sent remotely only, then there's nothing local to display, custom things can define a custom function
2026-07-14 16:55:33 <navi> we could however make it a function that uses file and pattern, so that things can drop-in their custom functions, i suppose
2026-07-14 16:55:51 <navi> so there's no need to define a whole custom status()
2026-07-14 20:59:45 <WhyNotHugo> I don't realy like syslog / logger due to one big reason: every process for every  user writes to a single datagram stream, and then the logging service needs to figure out how to un-mix all the streams that have been blended together.
2026-07-14 21:00:07 <WhyNotHugo> Anyone with the most modest of privileges can pipe logs that look like the came from other services.
2026-07-14 21:03:28 <WhyNotHugo> I'm not sure openrc should take it upon itself to print logs though. That seems like a big stretch in scope. It obviously needs to pipe the stdout/stderr for services, but consuming logs sits at the other end of a pipeline.
2026-07-14 21:10:48 <skarnet> WhyNotHugo: use the s6 backend, which has the native s6 logging architecture ;)
2026-07-14 21:15:12 <WhyNotHugo> skarnet: that would require making s6 and s6-log part of the default install. Not sure how convinced others are of such a change.
2026-07-14 21:16:28 <skarnet> oh, this is #alpine-devel, I thought it was #openrc, my bad. If we're talking in the context of Alpine, yeah, that's doable at an individual level, not yet at a systemic level (but I'm still working on it)
2026-07-14 21:17:20 <skarnet> the latest s6-frontend release has improved usability, and I'm now going to work on the init scripts
2026-07-14 22:28:02 <Piraty> achill et al. : voidliux has useful scripts for maintainers in https://github.com/leahneukirchen/xtools . some useful stuff is distro-agnostic and other stuff is easily portable to apk . you should definetely have your atools repo ;)
2026-07-14 22:29:13 <Piraty> helps a lot with clean git-log  too
2026-07-14 22:29:22 <navi> WhyNotHugo: syslog is kind of a trust basis, but any alternative would mean a custom structure that may or may not work with what people need
2026-07-14 22:29:48 <navi> a big example for syslog is being able to send logs remotely, with granularity
2026-07-14 22:39:42 <WhyNotHugo> syslog is "trust everyone on the host is well-behaved"
2026-07-14 22:40:26 <WhyNotHugo> But the idea of "just merge all streams and then use regex to split them apart again" is obviously poor design, you don't need to run regex to split servies and blindly trust every process if you just don't merge them all together in the first place
2026-07-14 22:40:40 <WhyNotHugo> You don't **need** syslog to transfer logs over the network
2026-07-14 23:01:10 <navi> no but i'm not keen in inventing a new logging structure with granular loggin and networking capabilities in openrc
2026-07-14 23:01:13 <navi> and that's mostly it, syslog won't be the only option, obviously, but by all we have, and by what distros currently ship, it seems like the best default?
2026-07-14 23:03:20 <navi> i mean i'm also open to suggestions on how the default should be, but not having to worry about rotation or networking or api or much of filesystem structure, instead leaving that to the system admin, is a plus
2026-07-14 23:20:11 <WhyNotHugo> navi: what I'd like to see is a way to declare `output_logger` globally (being able to use $RC_SVCNAME inside of it, and have that apply to all services by default. Someone wanting to use POSIX logger can just use `output_logger="logger -t $RC_SVCNAME -p daemon.info"`.
2026-07-14 23:20:22 <WhyNotHugo> But anyone wanting anything else can use whatever.
2026-07-14 23:20:33 <sam_> I think we agreed on that in openrc like 2 years ago
2026-07-14 23:20:42 <sam_> just we had someone saying it shouldn't do that by default and it got a bit derailed 
2026-07-14 23:20:49 <sam_> I agree that's a nice solution
2026-07-15 02:13:07 <WhyNotHugo> sam_: the default (upstream) value can be a no-op anyway, keeping the current behaviour. Distros can choose to use a fitting default.
2026-07-15 02:38:35 <WhyNotHugo> Would appreciate some feedback for !104769
2026-07-15 03:10:25 <Sertonix[m]> Couldn't this be done with a simple provider?
2026-07-15 04:45:47 <WhyNotHugo> What do you mean?
2026-07-15 04:52:02 <WhyNotHugo> nvm, link in comment in clear
2026-07-15 08:00:44 <fabricionaweb> good morning, should I patch a package that requires higher go version that we current have?
2026-07-15 08:04:52 <ikke> fabricionaweb: Yeah, if it fails just because it insists on a specific patch version of go without that patch version actually adding anything required by that project, I don't see any issue in patching that
2026-07-15 08:05:11 <ikke> imho the `go` directive should be the lowest possible version that is working for a project
2026-07-15 08:06:26 <fabricionaweb> ok, would be using a .patch the best approach? It probably fail on next upgrade, but maybe that is indeed best so it can be removed
2026-07-15 08:07:41 <ikke> I was tempted earlier to add something like this: https://tpaste.us/4Pvj
2026-07-15 08:08:50 <ikke> Ideally we'd ask upstream to reconsider the approach, but I suppose they have workflows that depend on that being the most recent version
2026-07-15 08:15:46 <fabricionaweb> yeah, I thought in sed too
2026-07-15 08:27:03 <fabricionaweb> eh, didnt work because a dependency asks for it lol
2026-07-15 08:27:12 <fabricionaweb> guess Im going wait :D
2026-07-15 08:39:03 <ikke> lesigh
2026-07-15 09:18:26 <sam_> WhyNotHugo: yes, that's true
2026-07-15 09:18:30 <sam_> WhyNotHugo: and perhaps a good idea in pushing for the upstream behaviour to change too
2026-07-15 09:18:34 <sam_> it hadn't occurred to me here but I don't think it'd be unreasonable to do this downstream
2026-07-15 09:18:38 <sam_> especially as it's intended for users to customise it anyway if they wish
2026-07-15 11:12:25 <navi> WhyNotHugo: you can already set output_logger in rc.conf
2026-07-15 11:12:47 <navi> i do have `output_logger="logger -t rc[$RC_SVCNAME]"` on mine
2026-07-15 11:13:12 <navi> every service sources rc.conf, so vars work too
2026-07-15 11:13:15 <navi> the main issue is the default
2026-07-15 11:14:30 <navi> sam_: i think if we merged error_logger into output_logger when the former is unset, it'd make this simpler to be set downstream
2026-07-15 11:45:30 <navi> oh there's a bug on the rc.conf sourcing ofc
2026-07-15 13:45:32 <WhyNotHugo> navi: wasn't aware of that, nice.
2026-07-15 13:45:57 <WhyNotHugo> I think it's perfectly reasonable then for us to add a distro-wide default, and trim all the custom/diverging init scripts which specify something else.
2026-07-15 13:46:16 <navi> atm openrc-run.sh is sourcing the wrong file, making it just not work, but i have a dumb fix already
2026-07-15 13:46:20 <navi> gonna commit a bit later today
2026-07-15 13:46:49 <WhyNotHugo> navi: do ping me when you merge that, I'll see if it's sensible to backport.
2026-07-15 13:46:54 <navi> the major complaint about logger as the default is "if you're not running a syslog, it's a dead process per service"
2026-07-15 13:47:22 <WhyNotHugo> IIRC, syslog is enabled by default on Alpine. Will need to double check
2026-07-15 15:01:21 <sam_> navi: sounds good
2026-07-15 15:22:40 <craftyguy[m]> could a maintainer please merge !105355? aarch64 CI failed because of a http fetch error (pkg builds fine locally) and if I retry CI it'll tie up a aarch64 runner for 2-3 hours. doesn't seem worth it :P
2026-07-15 15:25:12 <ikke> I'll take a look at it
2026-07-15 15:25:17 <ikke> (add it to my queue)
2026-07-15 15:26:35 <craftyguy[m]> thanks!
2026-07-15 16:09:35 <WhyNotHugo> I'm trying to run a pipeline for a fork of https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci, but the pipeline is in status "stuck"
2026-07-15 16:09:41 <WhyNotHugo> Do I need some special permisson for runners to pick it up?
2026-07-15 16:09:42 <WhyNotHugo> https://gitlab.alpinelinux.org/WhyNotHugo/alpine-gitlab-ci/-/pipelines/455310
2026-07-15 16:11:15 <ikke> WhyNotHugo: yeah, I need to assign an image runner to the project
2026-07-15 16:12:44 <ikke> WhyNotHugo: done
2026-07-15 16:13:19 <WhyNotHugo> Thanks!
2026-07-15 16:14:11 <WhyNotHugo> I'm prototypeing adding a options="cross" to APKBUILDs to mark them as "known to cross-compile", and then a single CI job to validate this. Very early and hacky, but should give us clearer visibility as to what properly cross-compiles :)
2026-07-15 16:33:12 <Sertonix[m]> Please not an extra option. Checking if makedepends_host or makedepends_build is set would be more viable IMHO
2026-07-15 22:22:09 <WhyNotHugo> Some packages cross-compile fine and don't have makedepends_host or makedepends_build. `CBUILD=aarch64 abuild -r` works fine for `hare-lsp`. Do you think it should explicitly use either makedepends_host or makedepends_build regardless?
2026-07-15 22:41:19 <Sertonix[m]> IIRC I was experimenting with this logic: [ -n "$makedepends_host$makedepends_build" ] || [ -z "$makedepends" ]
2026-07-15 22:44:51 <Sertonix[m]> But I think that needing to explicitly opt-into cross compilation will be extra churn between pqckage maintainers who don't have the time to test/fix it and people who regularly cross compile stuff. What is the problem with the current approach of having cross compiling be a self service?
2026-07-15 23:19:46 <WhyNotHugo> Sertonix[m]: wdym self-service?
2026-07-15 23:20:36 <WhyNotHugo> Right now some packages cross-compile fine, and other don't work. You don't know until you try basically, and I'd like to (a) improve cross-compilability for a lot of them (b) have a way to tag which ones are known to cross fine
2026-07-15 23:21:02 <Sertonix[m]> If you want to cross compile an APKBUILD you can patch it yourself without needing anybody else to spend time on it.
2026-07-15 23:21:45 <WhyNotHugo> I know, I don't intend to make it somebody else's problem, I want to patch them myself :)
2026-07-15 23:26:12 <Sertonix[m]> "which ones are know to cross fine" Cross fine from x86_64 to armhf, s390x to riscv64, alpine stable to alpine edge, or chimera to alpine? There will be many packages were only some of these work. Meaning that we ether need a large test matrix and complex annotation or the situation will continue to be "you have to try".
2026-07-15 23:27:19 <Sertonix[m]> There have also been some reports of binutils not cross compiling to some targets that I could never reproduce...
2026-07-15 23:29:51 <Sertonix[m]> For generally improving cross-compatibility I think the best places would be the abuild bug tracker or #alpine-ports.
2026-07-15 23:30:43 <WhyNotHugo> There's a diffrence betweena package where cross-compilation has been taken into account (which might fail for some edge cases) and one where it's never been done, and its entire dependency tree is known to have limitations.
2026-07-15 23:31:30 <WhyNotHugo> I do agree that testing all cross combinations in unfeasible.
2026-07-15 23:31:43 <WhyNotHugo> I have no expectation of anyone doing so.
2026-07-15 23:32:27 <WhyNotHugo> But testing just one single combination via CI would help determine the most basic support (e.g.: makedepends separation).
2026-07-15 23:34:17 <Sertonix[m]> I would try to find ways where APKBUILDs don't need special casing besides maybe usikg makedepends_*. Having a CI might result in dozens of inconsistent cross compiling logic in APKBUILDs that barely work for the combination tested in CI.
2026-07-15 23:34:23 <abby> on void (where we do cross by default for non-x86), we have a nocross variable for things that don't cross-compile (options="!cross" in apkbuild, i guess) that's separate from a broken variable (which can be set in a conditional/case for per-archness).
2026-07-15 23:34:47 <abby> also we have makedepends (things for target) and hostmakedepends (things for host) as our naming scheme
2026-07-15 23:36:40 <abby> the pair of nocross and broken can cover basically all cases of "this doesn't build in a specific setup but nominally should build"
2026-07-15 23:37:41 <Sertonix[m]> The foundation that abuild provides for doing cross compilation is a bit fragile. I would like to improve that before building stuff in APKBUILDs on top of that
2026-07-15 23:44:36 <Sertonix[m]> Eg. https://www.openwall.com/lists/musl/2025/03/05/1
2026-07-16 00:10:57 <WhyNotHugo> Sertonix[m]: Indeed, ideally we'd have as little special casing as possible.
2026-07-16 00:11:28 <WhyNotHugo> But, for example, anything Rust-based is known to *not* cross-compile right now because we don't build Rust with any cross-compilation support.
2026-07-16 00:13:16 <Sertonix[m]> Last time I checked 2 environment variables and a  different path for the install commands makes most cargo based packages cross compile fine.
2026-07-16 00:14:20 <Sertonix[m]> *and the typical makedepends change
2026-07-16 00:14:22 <WhyNotHugo> Sertonix[m]: on Alpine? Our rust package isn't built with that support, it only has support for the host architecture, wasm and uefi.
2026-07-16 00:14:42 <Sertonix[m]> Yes, native alpine rust/cargo package
2026-07-16 00:15:25 <WhyNotHugo> Do you remember which variables and some sample package where I can try this?
2026-07-16 00:15:57 <Sertonix[m]> You basically install the cross rust stdlib like other cross libraries into CBUILDROOT and point rust to it.
2026-07-16 00:17:46 <Sertonix[m]> Not sure when I have time to make an example package
2026-07-16 00:42:59 <WhyNotHugo> I've been using `CBUILD=armv7 abuild` to cross-compile, and it's worked fine… but is `CTARGET=armv7 abuild` the correct usage?
2026-07-16 00:43:16 <WhyNotHugo> *but is CARCH=armv7 the correct usage?
2026-07-16 09:02:31 <quinq> $ apk info -r clang22
2026-07-16 09:02:32 <quinq> clang22-22.1.8-r0 is required by:
2026-07-16 09:02:40 <quinq> $ doas apk del clang22
2026-07-16 09:02:40 <quinq> World updated, but the following packages are not removed due to: clang22: clang
2026-07-16 09:02:51 <quinq> Isn't that a bit weird?
2026-07-16 09:04:09 <ikke> apk list --origin clang22
2026-07-16 09:04:53 <quinq> Is that an answer to my question? ;p
2026-07-16 09:05:25 <ikke> Not necessarily, but it may help
2026-07-16 09:05:26 <quinq> Maybe it wasn't clear either
2026-07-16 09:06:09 <quinq> My question is, on one point apk tells me that nothing requires a package, but then apk tells me that it cannor remove it because it's required
2026-07-16 09:06:18 <ikke> yes
2026-07-16 09:06:27 <quinq> Could this be improved by actually listing the (virtual) package that requires it?
2026-07-16 09:06:50 <quinq> Maybe apk-query does a different thing, let-me check
2026-07-16 09:08:19 <quinq> Yeah, it does list some other packages, actually more than apk-del
2026-07-16 09:09:29 <ikke> What command did you run?
2026-07-16 09:13:36 <quinq> $ apk query --fields reverse-depends clang22
2026-07-16 09:21:29 <quinq> $ apk query --fields reverse-depends clang
2026-07-16 09:21:38 <quinq> That returns nothing though :D
2026-07-16 09:22:21 <quinq> oh my bad, needs --installed option
2026-07-16 09:24:59 <quinq> Feels a bit weird also that it gives remote info by default and needs a flag to restrict it to the actually installed packages, but I suppose this can be filed as “it's like your opinion man”
2026-07-16 09:25:42 <ikke> I think it by default looks at the index
2026-07-16 09:38:30 <Sertonix[m]> WhyNotHugo: You mean CHOST=armv7 abuild? That would seem correct to me
2026-07-16 09:41:48 <PureTryOut> I always used CARCH 🤔
2026-07-16 09:42:16 <ikke> Heh, 3 persons, 3 variables 
2026-07-16 09:43:05 <PureTryOut> we should probably figure out a single one to use lol
2026-07-16 09:44:59 <ikke> One standard to rule them all
2026-07-16 09:48:40 <Sertonix[m]> Setting CARCH like that breaks the assumption that each triplet maps to exactly one architecture.
2026-07-16 10:55:33 <Sertonix[m]> WhyNotHugo: There are some issues that should be fixed but this can do cross compile a cargo package: https://gitlab.alpinelinux.org/sertonix/aports/-/commit/c980fbbe494ad7268fd33b10bbf47e160e9f4158
2026-07-16 14:17:13 <WhyNotHugo> Sertonix[m]: nice. Do you think the `CARGO_TARGET_` block of variables could live in abuild's default.conf with CARGO_ variables?
2026-07-16 14:20:13 <Sertonix[m]> We need a mechanism in abuild to setup environment variables later or in some dependency order.
2026-07-16 14:21:12 <Sertonix[m]> At the time of default.conf the values of CBUILD/CHOST/CTARGET might still change
2026-07-16 17:39:28 <ikke> gitlab will be upgraded at 18:00 UTC and it will be offline for a couple of minutes
2026-07-16 18:01:41 <ikke> gitlab is being upgraded
2026-07-16 18:11:17 <ikke> It's back
2026-07-16 18:30:36 <ikke> something is not working properly yet
2026-07-16 18:58:08 <ikke> Ok, I think it's fixed now
2026-07-16 19:01:20 <jvvv> Is the go-away filter still enabled? Connection seems almost too instantaneous
2026-07-16 19:02:22 <ikke> yes, it still is
2026-07-16 19:03:00 <ikke> I had to redo the database upgrade. There were some tables missing for some reason
2026-07-16 19:03:38 <ikke> I still had the migration databases (separate containers) running. I stopped them, but it probably caused issues during the gitlab database migration
2026-07-16 19:05:21 <jvvv> You sure got to root cause quick, imo
2026-07-16 19:06:26 <ikke> Logs pointed out that it could not find certain tables
2026-07-16 20:39:59 <ikke> riscv64 now needs to build 811 packages :(
2026-07-16 20:42:22 <ncopa> lol
2026-07-16 20:42:56 <ikke> Keeping track of it
2026-07-16 20:43:10 <ikke> Went from 488 to 810
2026-07-16 20:52:57 <ncopa> could it be 98268b47c7ed163901bf27624586445b47a3ae7c?
2026-07-16 20:54:02 <Sertonix[m]> I would guess it was the recent go upgrade
2026-07-16 20:54:18 <ikke> ncopa: that commit does not have pkgrel bumps
2026-07-16 20:54:19 <ncopa> yeah, i forgot to git pull
2026-07-16 22:12:28 <Sertonix[m]> Would it be possible to have the CI be part of the build infra so that (under the right conditions) the result of the last CI can be resigned to be the final package?
2026-07-16 22:43:48 <WhyNotHugo> CI runs untrusted code from anyone opening an MR
2026-07-16 22:43:59 <WhyNotHugo> In theory builds are isolated, but any sandbox escape is direct access to builders.
2026-07-16 22:51:40 <Sertonix[m]> I know but a pre-merge job could be just as trusted as the code that is run on the builders when triggered by a dev.
2026-07-16 23:31:40 <jvvv> I'm getting a lint error for var expansion in the form of: "$pkgdir/$_pypath"/PySide6/Qt/libexec/"$_f"
2026-07-16 23:32:16 <jvvv> Should I just quote the whole thing?
2026-07-16 23:32:43 <jvvv> re: https://gitlab.alpinelinux.org/jvvv/aports/-/jobs/2437728
2026-07-16 23:38:04 <panekj> i think it just gets stupid because of "$var1/$var2"
2026-07-16 23:41:43 <jvvv> Ok, thanks. That is about what I was thinking, more or less. I could shut it up with the right shellcheck comment
2026-07-17 00:29:22 <jvvv> The pyside6-6.11.1-r0 packages for riscv64 never made it to dl-cdn.a.o
2026-07-17 00:30:08 <jvvv> The build log exists for it and was successful, but somehow the packages never got uploaded it seems
2026-07-17 00:37:30 <lotheac> uploads only happen once the builder finishes building the repo (eg community)
2026-07-17 00:44:42 <ikke> Sertonix[m]: in general ir wo
2026-07-17 00:44:49 <ikke> It won't work 
2026-07-17 00:44:58 <ikke> The result3 
2026-07-17 00:45:09 <ikke> Needs to be consistent 
2026-07-17 01:02:07 <jvvv> lotheac: It was from over a month ago. I think it had to do with the change between different build machines for the 3.24 release. Not a blame thing, just a conjecture on how it could have happened
2026-07-17 01:04:00 <jvvv> gotta reboot, brb
2026-07-17 01:09:40 <lotheac> ah ok
2026-07-17 01:12:23 <jvvv> I'm preparing an -r1 for pyside6 and was hoping to avoid a whole slew of rebuilds, just not sure now about that working out for riscv64 since there is a soname change that the lost packages should have taken care of
2026-07-17 01:13:10 <jvvv> s/should/would/
2026-07-17 03:11:33 <jvvv> To me, this does not look like an actual soname difference: https://gitlab.alpinelinux.org/jvvv/aports/-/jobs/2437736#L4266
2026-07-17 03:14:15 <jvvv> I have always thought that the relevent part the output of `objdump -p path_to_so_lib | grep SONAME`
2026-07-17 03:15:28 <jvvv> I'm not saying that I think checkapk should be changed, I'm just trying to confirm whether or not I need to do a batch of bump commits for that
2026-07-17 04:05:48 <ikke> Correct. The library version changed, but the SONAME remained the same
2026-07-17 04:13:10 <jvvv> Thanks. I thought I remembered that right, though it is nice to have it confirmed
2026-07-17 04:17:44 <jvvv> So the missing pyside6 packages for riscv64 is a non-issue. Actually the current MR will help to rectify the situation
2026-07-17 07:11:00 <Saijin_Naib[m]> Anyone able to review !96399, !99156, and !97494
2026-07-17 07:11:35 <Saijin_Naib[m]> !97494 once it goes in will have a follow-up MR with a pkgrel bump and adding them as depends for pitivi to enable audio beat detection in pitivi
2026-07-17 10:28:51 <JustSouptheyhe[m]> Are the riscv builders having trouble? The current pipewire version on riscv was built on 2026-05-27, while every other arch has 2026-07-15
2026-07-17 10:55:43 <ikke> JustSouptheyhe[m]: just behind 
2026-07-17 10:56:48 <JustSouptheyhe[m]> Is there somewhere where what is building can be tracked? Pipewire had a breaking change that we would like to mitigate downstream, but it depends on a subpackage that doesn't exist on riscv yet.
2026-07-17 10:57:10 <ikke> https://build.alpinelinux.org/
2026-07-17 10:57:56 <ikke> All the rebuilds that are happening are not helping
2026-07-17 10:58:17 <JustSouptheyhe[m]> Ah, there was a Go update, wasn't there
2026-07-17 11:19:10 <ikke> Yup, before that, it was around 400 packeges
2026-07-17 13:39:05 <ncopa> JustSouptheyhe[m]: https://fosstodon.org/@ncopa/116931630323924369
2026-07-17 13:39:39 <ncopa> new (re)builds comes in faster than the current builders are able to handle
2026-07-17 13:40:01 <JustSouptheyhe[m]> Oh goodness. That's a pretty bad snowball.
2026-07-17 13:40:48 <ncopa> would be great if go and rust stopped doing releases
2026-07-17 13:41:10 <ncopa> or if everyone went back to dynamic linking
2026-07-17 13:41:51 <ncopa> so one security fix only trigger a single rebuild not 300-400
2026-07-17 13:43:30 <ikke> I did take a brief look if it was possible to link dynamically with go. There was a feature, but it's not supported and testing indicated it doesn't work well
2026-07-17 13:43:53 <ncopa> does not help if not go projects supports it
2026-07-17 13:44:43 <ncopa> the entire idea of go is to avoid the dynamic linking. its kinda the point of using go in the first place
2026-07-17 13:45:51 <ikke> Perhaps we should change go APKs to compile on install :P
2026-07-17 13:46:39 <ncopa> or let the users of those binaries download the binary from upstream, like upstream usually prefers
2026-07-17 13:46:57 <ncopa> eg stop shipping go and rust packages
2026-07-17 13:47:16 <ikke> Nice thing about having it as packages is that they are automatically updated
2026-07-17 13:47:32 <ikke> Install them manually, and you suddenly need to start keeping track of that
2026-07-17 13:47:43 <ncopa> yup
2026-07-17 13:48:01 <ncopa> its a trade-off
2026-07-17 13:48:14 <ikke> But our mirrors are overflowing
2026-07-17 13:48:22 <ikke> and builders are strugling
2026-07-17 13:48:27 <ncopa> not everyone wants automattic updates. people want pinned versions
2026-07-17 13:48:55 <ikke> They still can install it manually if they want
2026-07-17 13:49:18 <ikke> But software more and more just breaks things left and right instead of providing stable software that can just be updated
2026-07-17 13:49:46 <ikke> Want a sucurity upgrade, here, get this breaking change as well
2026-07-17 13:50:00 <ncopa> heh
2026-07-17 13:50:16 <ncopa> yeah, the github generation as i used to call them
2026-07-17 13:50:26 <ncopa> i feel old :)
2026-07-17 13:50:42 <ikke> "Old man yells at cloud"
2026-07-17 13:50:53 <ncopa> yup
2026-07-17 13:53:29 <JustSouptheyhe[m]> Please don't drop Go and Rust packages. They are quite heavily used and most people don't want to download and manually compile them. There's also the issue of GUIs and core programs that use those languages. Dropping them should be a last-resort.
2026-07-17 13:53:40 <ikke> JustSouptheyhe[m]: We won't, we're just venting
2026-07-17 14:08:27 <andar1an> happy friday. Wondering if anyone has encountered a libc::timespec compile error before for rust projects (seems to be specific to armhf or x86), trying to look into what musl does, but I don't want to spend too much time on this and would be grateful for any pointer
2026-07-17 14:09:29 <andar1an> nvm, i see patches related. SHould have looked first. My bad
2026-07-17 14:20:27 <ikke> aelin knows about it
2026-07-17 14:21:04 <andar1an> I think it may be in interprocess/src/os/unix/c_wrappers.rs where I need to do something like https://gitlab.alpinelinux.org/andar1an/aports/-/blob/master/community/firefox/time64.patch. Does this make sense? 
2026-07-17 14:31:00 <andar1an> Think I figured out, there was some help from musl chat that I think got me understanding. Will update when I figure out or fail haha
2026-07-17 15:45:04 <ikke> 778 packages left to build for rv64
2026-07-17 16:20:26 <andar1an> timespec patch seems to work, on to a crate trying to select x86_64 arch for x86 haha.
2026-07-17 16:20:40 <ikke> :D
2026-07-17 17:25:46 <ikke> ayakael71: The git-annex source is 404, and we don't have it on distfiles
2026-07-17 17:26:03 <ikke> git-annex-10.20260601.tar.gz
2026-07-17 17:45:43 <lnl> ncopa: A new problem with go rebuilds is also that chromium was included this time 😶
2026-07-17 17:46:06 <ikke> But that does not affect rv64
2026-07-17 17:46:47 <lnl> Oh sorry missed that part
2026-07-17 17:48:12 <ikke> ayakael71: I can generate an archive, but it has a different hash
2026-07-17 17:54:33 <lnl> But anyway, how are the go rebuilds generated? I think it could be skipped in the future because it's entirely a build-time codegen script
2026-07-17 17:56:05 <ikke> What is a build-time codegen script?
2026-07-17 17:57:29 <ikke> You mean the thing that got fixed?
2026-07-17 18:05:39 <achill> lnl: its me sourcing all APKBUILDs and checking for $makedepends. i can skip chromium the next times
2026-07-17 18:07:17 <ikke> ah, understand it now
2026-07-17 18:13:22 <ikke> gtksourcview5: - GLib-FATAL-ERROR: ../glib/gmem.c:106: failed to allocate 2147483648 bytes
2026-07-17 18:13:32 <ikke> on 32-bits
2026-07-17 19:55:15 <Sertonix[m]> I think that test should be skipped or using a size adequate for a 32-bit address space
2026-07-17 19:57:47 <Biswa96[m]> would anyone like to review this MR please? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/104891
2026-07-17 20:01:09 <ikke> Biswa96[m]: It fails on ppc64le
2026-07-17 20:01:19 <ikke> error: invalid parameter combination for AltiVec intrinsic '__builtin_vec_ld'
2026-07-17 20:05:52 <jvvv> This looks relevent: https://github.com/schismtracker/schismtracker/commit/5509849f2b7eded9a9f3865289bd93bc1284d99e
2026-07-17 20:09:13 <jvvv> Seems worth a test run. I was specified to work on big endian, but authors suggests that it should/could work for le as well
2026-07-17 20:09:27 <jvvv> s/I was/It was/
2026-07-17 20:19:29 <ikke> 730 packages left to build for rv64
2026-07-17 20:19:33 <ikke> (+ change)
2026-07-17 20:20:16 <jvvv> Biswa96[m]: Might also need https://github.com/schismtracker/schismtracker/commit/98cc72c413bd26df40b848bb22488e8cd639ab91 as well, then add autoreconf to prepare
2026-07-17 20:20:37 <ikke> Pretty please do not open any new MRs today, kthxbye
2026-07-17 20:34:10 <Biswa96[m]> @jvvv thanks, I'll follow that upstream issue.
2026-07-17 20:34:47 <jvvv> yw
2026-07-18 01:05:57 <WhyNotHugo> The configs for linux-stable are not in the format produced by menuconfig or nconfig. How do I operate on the file? Any change that I make ends up in a gigantic diff.
2026-07-18 01:08:20 <Sertonix[m]> You need to convert them to the small form with savedefconfig or just use the prepareupdate/updateconfigs functions as intended.
2026-07-18 01:08:55 <WhyNotHugo> Can you explain the "as intended" part?
2026-07-18 01:09:40 <Sertonix[m]> For upgrade or just changing a config option?
2026-07-18 01:09:55 <WhyNotHugo> I'm changing some options.
2026-07-18 01:10:01 <WhyNotHugo> (one plus its dependencies)
2026-07-18 01:11:10 <Sertonix[m]> If you know the config options that should change it might be possible to run: CONFIG_FOO=bar abuild prepareupdate updateconfigs
2026-07-18 01:12:15 <Sertonix[m]> If you want to use menuconfig it might be a bit more difficult.
2026-07-18 01:16:28 <Sertonix[m]> (the generall concept seems to be expand, change, reduce for each arch seperately)
2026-07-18 01:17:45 <WhyNotHugo> I don't strictly need menuconfig; it just usually tidies things up for me and makes it obvious when dependencies are missing. But
2026-07-18 01:22:01 <WhyNotHugo> `abuild prepareupdate updateconfigs` by itself is removing a lot of modules: https://gitlab.alpinelinux.org/WhyNotHugo/aports/-/commit/35244ba4871e3f80059b91e3eae2658f5b8ef167
2026-07-18 01:22:08 <WhyNotHugo> Is this just due to the config beign out of sync?
2026-07-18 01:24:25 <Sertonix[m]> It is likely that (many) previous upgrades did not use the updateconfigs mechanism and probably changed options in unintended way cause of that. achill is to say
2026-07-18 01:27:46 <WhyNotHugo> `make defconfig` expands these minimal configs to include all values. Some of the ones in that diff match the default, others end up absent. None mismatch.
2026-07-18 08:11:55 <Ariadne> woof.  i am almost done rebasing our GCC patches onto 16.1.  when would be a good time to push?
2026-07-18 08:26:54 <ikke> I suppose it doesn't matter too much. The riscv builder is behind anyway 
2026-07-18 08:30:25 <Ariadne> i'll do on sunday.  want to let it bake a little locally.
2026-07-18 15:00:03 <ikke> 622 packages left to build for rv64
2026-07-18 15:00:38 <f_|m> go rv64, go!
2026-07-18 15:09:37 <ikke> 52 builds without failure streak
2026-07-18 15:21:49 <ikke> And now gst-plugins-good fail, same reason as gst-plugins-bad
2026-07-18 15:21:58 <ikke> Would be nice if someone could look at it
2026-07-18 15:22:13 <ikke> ninja: job terminated due to signal 11: /usr/bin/orcc --include glib.h --header -o gst/videomixer/videomixerorc.h ../gst/videomixer/videomixerorc.orc
2026-07-18 15:22:15 <ikke> ninja: job terminated due to signal 11: /usr/bin/orcc --include glib.h --implementation -o gst/videomixer/videomixerorc.c ../gst/videomixer/videomixerorc.orc
2026-07-20 00:56:24 <anjan> Sertonix[m]: can you please review: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/105366?__goaway_challenge=cookie&__goaway_id=f9e3ef1a12073fb67389cc9ba55a677c
2026-07-20 03:15:37 <qaqland> !105366
2026-07-20 11:18:29 <JustSouptheyhe[m]> Would any devs like to take another look at !103388 ? Its ready, just waiting on reviews.
2026-07-20 16:52:23 <sam_> PureTryOut: if you could test my latest patch for https://github.com/mesonbuild/meson/issues/15601, it'd be much appreciated
2026-07-20 16:52:26 <sam_> i'm sorry it took a little whlie
2026-07-20 16:52:27 <sam_> while*
2026-07-20 17:23:31 <el_cubano> Hola everyone! I created a MR a few months ago for a new port. I have updated recently (about 10 days ago) for the latest release. I am curious to know if there is something specific that I need to do in order to get the MR officially reviewed and merged. Or do I just need to continue being patient?
2026-07-20 17:36:18 <ikke> el_cubano: there is a bit of a queue of MRs for new aports
2026-07-20 17:37:07 <el_cubano> 
ACTION nods

2026-07-20 17:37:36 <ikke> Keeping it up-to-date from time-to-time does help
2026-07-20 17:38:46 <el_cubano> Thanks. I'll make sure to keep it up to date.
2026-07-20 17:39:14 <ikke> And thanks for your patience
2026-07-20 17:40:34 <el_cubano> And thanks to the Alpine team for an awesome distro.
2026-07-20 17:45:21 <PureTryOut> sam_: uh yeah, I'll have to get a setup for that again. Will report back if it works, thanks for working on it!
2026-07-20 17:50:58 <ikke> 550 packages to build for rv64
2026-07-20 19:35:13 <ayakael71> ikke: thanks for flagging this. I put up some AI blocks the other day, may be what's causing the 404 errors.
2026-07-20 19:43:24 <ayakael71> ikke: in any case, the 404 should be fixed now
2026-07-20 23:00:59 <WhyNotHugo> Is packaging firmware from https://github.com/armbian/firmware/tree/master/brcm acceptable somehow? The licensing terms seem to be… undefined.
2026-07-20 23:01:24 <WhyNotHugo> I specifically need brcmfmac43752-pcie, which isn't on linux-firmware
2026-07-21 01:10:06 <Arnavion> linux-firmware is full of fw with questionable licensing already so...
2026-07-21 02:17:54 <craftyguy[m]> I thought it had to be submitted by OEMs though
2026-07-21 02:24:16 <Arnavion> Counter-example that I know of:   https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=e39831b1a9d75eb91af5c1711082edea5e259d3f
2026-07-21 02:25:30 <aelin> there's also plenty of ath10/11/12k wireless firmware files that are not OEM approved
2026-07-21 02:26:02 <aelin> you can just send them to the maintainer with some source reference and they will add them
2026-07-21 04:49:54 <craftyguy[m]> oof
2026-07-21 05:07:01 <ikke> We were, for a brief moment, below 1000 open MRs yesterday
2026-07-21 07:55:06 <WhyNotHugo> So I should just submit the firmware to that list? Sounds straightforward enough (:
2026-07-21 08:09:12 <adhawkins> Anyone any thoughts on when v1.37 of py3-inform will be processed by the riscv64 builder? One of my other packages is failing tests due to the old version.
2026-07-21 08:09:21 <adhawkins> https://pkgs.alpinelinux.org/package/edge/community/riscv64/py3-inform
2026-07-21 08:10:07 <ikke> adhawkins: The problem is not when that specific package is built, the problem is when the builder will finish the entire repo, because that's when the packages actually get uploaded
2026-07-21 08:10:22 <ikke> For now, we have to ignore these dependency failures for rv64
2026-07-21 08:10:36 <ikke> because it's going to take a while before it is able to catch up with all the new builds that are still getting pushed
2026-07-21 08:10:43 <ikke> (It is catching up, though)
2026-07-21 08:11:08 <ikke> ~400 packages left to build, from >800 last week
2026-07-21 08:11:23 <ikke> https://build.alpinelinux.org
2026-07-21 08:37:25 <ncopa> progress. good!
2026-07-21 08:42:44 <adhawkins> ikke: Ok, thanks. I have a draft update to the package that's failing that is reinstating the tests for riscv64. I'll continue to monitor to see when the package actually updates.
2026-07-21 08:51:21 <ikke> adhawkins: You can also leave a comment on the MR with the reason, and we'll just merge it for now
2026-07-21 08:57:59 <adhawkins> I think I'd rather wait until the package is updated on riscv64, just to make sure the tests then succeed. The new version of the package (borg-space) is already in place, the MR is just reinstating the tests on riscv64
2026-07-21 08:58:21 <adhawkins> !105182
2026-07-21 09:18:26 <ikke> Alright
2026-07-21 10:48:12 <panekj> ntfs3 module is gone from the kernel
2026-07-21 10:50:16 <panekj> https://tpaste.us/eNOO 
2026-07-21 10:54:23 <ikke> linux-stable, ftr
2026-07-21 11:09:39 <panekj> it got lost in 7.0->7.1 bump, as ntfs module took its place
2026-07-21 11:11:10 <achill> can you open a issue and assign me?
2026-07-21 11:12:24 <panekj> did you mean "work item"? /s
2026-07-21 11:12:37 <panekj> https://tpaste.us/kQEr 
2026-07-21 11:14:59 <panekj> #18352
2026-07-21 11:15:16 <panekj> can't assign
2026-07-21 11:17:05 <panekj> generally I'm ok with sticking to ntfs module (since I've been waiting for it this whole time), I just didn't expect issues during kernel upgrade
2026-07-21 11:17:35 <panekj> probably wouldn't notice if I had nofail on my disk (like I do now)
2026-07-21 15:53:41 <ikke> 996 open MRs!
2026-07-21 15:55:52 <ikke> And rv64 has 366 packages left to build
2026-07-21 15:57:41 <f_> go rv64, go!
2026-07-21 15:57:49 <f_> I know you can do it!
2026-07-21 16:04:26 <ikke> Sertonix[m]: fdo gitlab is timing out :(
2026-07-21 16:06:14 <Sertonix[m]> git clone seens to still work
2026-07-21 16:06:22 <ikke> ok
2026-07-21 16:47:43 <panekj> did something change with mpv? it seems to hang few secs into video
2026-07-21 17:25:04 <quinq> panekj, is it reproducible?
2026-07-21 17:51:13 <panekj> yes
2026-07-21 17:51:54 <panekj> hm, I don't like that it froze plasmashell until it got killed
2026-07-21 21:20:45 <WhyNotHugo> panekj: if the compositor froze, then it's a bug in the compositor, on in the client.
2026-07-21 21:21:03 <WhyNotHugo> *not in the client
2026-07-21 21:34:12 <panekj> how is mpv going "not responding" a bug in compositor
2026-07-21 21:34:44 <WhyNotHugo> If it froze the compositor, it's a bug in the compostior; a compositor needs to be resilient to clients misbehaving.
2026-07-21 21:35:10 <WhyNotHugo> I.e.: if your browser freezes when a servers sends a malformed paged, the freeze is a bug in the browser.
2026-07-21 21:35:48 <panekj> ok, yes, I know that, it doesn't help the fact that mpv is freezing
2026-07-22 01:32:16 <jvvv> WhyNotHugo: Thank you for taking the time for the review. Much appreciated
2026-07-22 11:06:55 <aparcar[m]> is anyone planing to spin up the reproducible CI tests again? https://tests.reproducible-builds.org/alpine/alpine.html
2026-07-22 11:23:52 <ncopa> not that I know, but it woudl be nice indeed
2026-07-22 11:27:51 <PureTryOut> That could probably be a good cause for a grant
2026-07-22 12:04:22 <aparcar[m]> I'm doing the work right now for OpenWrt (https://rebuilderd.n.aparcar.org/?distro=openwrt-image) and it's somewhat straight forward, happy to help
2026-07-22 12:04:57 <mini_bomba[m]> speaking of reproducibility... was cargo or the rust toolchain updated in the last two weeks? my !104889 aports MR was rebased today and the tests have suddenly failed on every arch with tests enabled and i'm kinda confused about how that would even happen
2026-07-22 12:05:55 <mini_bomba[m]> and to be fair, this isn't some breakage limited to us, since upstream's CI also appears to be failing in the same way
2026-07-22 12:18:21 <Asmadeus> looking at jobs logs, ( 6/22) Installing rust (1.96.1-r0) vs ( 6/22) Installing rust (1.97.0-r0)
2026-07-22 12:22:09 <mini_bomba[m]> okay now i'm embarrased that i didn't think of diffing the job logs lol, thanks
2026-07-22 13:01:34 <WhyNotHugo> aparcar[m], ncopa: I'd like to work on reproducible in a few months when my schedule clear a bit.
2026-07-22 13:01:39 <WhyNotHugo> If nobody picks it up first that is.
2026-07-22 13:02:07 <WhyNotHugo> PureTryOut: that's on my mind too :)
2026-07-22 14:22:21 <bl4ckb0ne> did something change recently with abuild permissions? I cant even do a `abuild checksum` without hitting permission errors
2026-07-22 14:30:26 <bl4ckb0ne> mh i think thats a sshfs issue
2026-07-22 14:37:39 <ikke> right, haven't noticed any issues myself
2026-07-22 14:57:51 <bl4ckb0ne> i have a weird setup, im building on an alpine vm with the aports folder mounted from the host through sshfs
2026-07-22 14:58:13 <bl4ckb0ne> and it seems like all kinds of symlinks are now choking, but it went fine before
2026-07-22 14:58:28 <bl4ckb0ne> maybe i should move it to virtiofs instead
2026-07-22 15:02:14 <Biswa96[m]> if you only want to build it, containers would be eaiser.
2026-07-22 15:04:30 <bl4ckb0ne> mh i do remember getting issues a while when trying to build aports through a container
2026-07-22 15:07:06 <bl4ckb0ne> got it working with virtiofs, no symlink issue
2026-07-22 15:07:24 <bl4ckb0ne> iirc at the time i did the setup virtiofs was borked in debian so i went with sshfs
2026-07-22 15:07:42 <bl4ckb0ne> but now i moved to forky and it seems to be going well
2026-07-22 15:07:54 <Sertonix[m]> There have been changes in abuild but I think nothing changed around symlinks
2026-07-22 15:09:59 <bl4ckb0ne> could be something on my host
2026-07-22 15:18:21 <bl4ckb0ne> ha nice, it even fixed my llvm17 rootbld issue
2026-07-22 15:35:41 <ikke> bl4ckb0ne: both the builders, as me build everything in lxc containers, and CI builds in docker containers
2026-07-22 15:41:09 <bl4ckb0ne> i tried with docker a while ago but it was inconclusive, i think it was that root abuild issue
2026-07-22 15:42:44 <ikke> You would not need to use rootbld in docker
2026-07-22 15:46:43 <bl4ckb0ne> the rootbld was different issue though
2026-07-22 15:51:53 <ikke> rootbld in containers requires additional privileges
2026-07-22 19:01:06 <WhyNotHugo> bl4ckb0ne: if a symlink points to outside the sshfs mountpoint, then it will most likely be broken.
2026-07-22 19:01:16 <WhyNotHugo> Since the symlink itself gets mounted, but not its target
2026-07-22 19:10:53 <quinq> Also pretty sure sshfs doesn't follow links out anyway, regarding of their final target presence or nto
2026-07-22 19:10:56 <quinq> s/nto/not/
2026-07-22 19:12:07 <WhyNotHugo> if the target is inside the mountpoint, the symlink would work (even if sshfs doesn't follow it)
2026-07-22 19:13:24 <quinq> Yes, but I was talking about *out*
2026-07-22 21:58:11 <craftyguy[m]> where can I request adding a new group to gitlab, "team/cosmic" ?
2026-07-22 21:58:28 <craftyguy[m]> (there's already a team/gnome and team/kde for example)
2026-07-23 03:48:45 <Saijin_Naib[m]> Here is what I did thus far for xfce: https://gitlab.alpinelinux.org/alpine/infra/gitlab-tf/-/work_items/2
2026-07-23 05:37:35 <craftyguy[m]> thanks!
2026-07-23 11:37:18 <ikke> 169 packages left to build for rv64!
2026-07-23 12:33:14 <PureTryOut> It's actually doing it, damn
2026-07-23 13:13:39 <Sertonix[m]> ptrc: I think we need to copy this patch: https://bugzilla.mozilla.org/show_bug.cgi?id=2049559
2026-07-23 15:37:25 <craftyguy[m]> could a maintainer take a look at !105844 ?
2026-07-23 20:57:04 <WhyNotHugo> Builders run on a tmpfs?
2026-07-23 20:57:40 <WhyNotHugo> Small Rust-based projects can use like 10GB of RAM to compile. So using non-RAM storage might aleviate memory usage subtantially (at the price of build time).
2026-07-23 20:57:46 <WhyNotHugo> Er, I mean CI, not builders tho.
2026-07-23 20:57:54 <WhyNotHugo> Thinking of Firefox/Librewolf, for example
2026-07-23 22:42:16 <Sertonix[m]> If the ratio of disk and memory usage is unkown/varying the best option in my experience is swap+tmpfs. Maybe the CI does similarly?
2026-07-24 02:41:10 <anjan> WhyNotHugo: can you please review https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/105366?__goaway_challenge=cookie&__goaway_id=f5fb1a3ce6f1836cc3f866cc6fb5c5ab
2026-07-24 05:00:41 <ikke> No tmpfs is used
2026-07-24 05:15:36 <jvvv> ikke: Thank you for the assignee change to !104999 and the rebase. Having ncopa look at that can not hurt (when/if he has time, of course)
2026-07-24 05:28:21 <ikke> Less than 50 packages left to build for the rv64 builder
2026-07-24 05:29:48 <jvvv> Wow, it just might make it tonight or tommorw! \o/
2026-07-24 09:14:54 <ikke> <30 to go
2026-07-24 09:53:48 <Biswa96[m]> Hi, is anyone working to update xfce to 4.21.x ? I am thinking to give it a try.
2026-07-24 09:55:12 <Sertonix[m]> ikke: I think kmime had a version downgrade that needs some manual fixing on the riscv builder to install the right version while building some KDE packages: https://build.alpinelinux.org/buildlogs/build-edge-riscv64/community/kimap/kimap-26.04.3-r0.log
2026-07-24 09:58:53 <Sertonix[m]> 0f3e71f3776e5970ffb4236c32a11f8b9ce8f8c5
2026-07-24 12:13:44 <fabricionaweb> Hi, I saw we closed the MR that were about removing some go flags, mind if I ask what happened? I thought removing it was cool a clean up
2026-07-24 12:15:35 <Sertonix[m]> It was very outdated at least
2026-07-24 12:17:06 <fabricionaweb> but the idea is cool, right? when doing upgrade we can review and remove it?
2026-07-24 12:57:53 <Sertonix[m]> Yes, it should still be done
2026-07-24 13:00:47 <Saijin_Naib[m]> @Biswa96 that is a testing/unstable release. Stable are even (4.18, 4.20, etc)
2026-07-24 13:15:38 <Biswa96[m]> Understand. Thanks.
2026-07-24 14:39:50 <rtmongold> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/103991 was merged in June, but `riscv64` still hasn't built. Should I do anything, or just wait?
2026-07-24 15:03:53 <Sertonix[m]> Just wait, the was up to 800 package builds behind but is now catching up (just 14 left)
2026-07-24 16:02:24 <rtmongold> thank you I will hold off
2026-07-25 03:18:22 <Saijin_Naib[m]> @Biswa96 if you know of anything xfce outdated in edge, I will try to take a look and bump it
2026-07-25 03:56:00 <Biswa96[m]> Nah, I was planning to add xfwl4 as it was asked in an issue. Repology may help with your query.
2026-07-25 10:24:35 <ikke> w00t, rv64 finished community
2026-07-25 11:03:48 <Sertonix[m]> ikke: Why are there 3 firefox versions in the edge community riscv64 repository?!
2026-07-25 11:07:32 <ikke> Sertonix[m]: apparently permission issues after moving the builder around
2026-07-25 11:07:35 <ikke> fixing
2026-07-25 11:07:58 <Sertonix[m]> Thanks!
2026-07-25 11:08:13 <ikke> There are probably more
2026-07-25 17:11:33 <WhyNotHugo> I'm confused by packages that lack options="net" but require network to build (and fail with rootbld). Does that mean they never went through CI?
2026-07-25 17:18:08 <ikke> It's only rootbld that enforces it
2026-07-25 17:18:15 <ikke> rootbld is not really required for CI
2026-07-25 17:18:33 <WhyNotHugo> I thougth CI enforce no-network too, only builders skipepd that?
2026-07-25 17:18:58 <ikke> No, neither CI, nor builders currently sever network during build
2026-07-25 17:19:33 <WhyNotHugo> In CI it might be trickky due to the dockerise environment
2026-07-25 17:19:37 <ikke> For CI, there is not really a good hook and mechanism to do that. One mechanism we could use is to break DNS, but we need good hooks to know when to enable and disable it again
2026-07-25 17:19:44 <WhyNotHugo> (although deleting /etc/resolv.conf would catch the obvious cases)
2026-07-25 17:20:47 <ikke> And before we enable it in CI, we would need to audit it
2026-07-25 17:21:15 <Sertonix[m]> Especially since CI needs netwotking to update git repo and packages.
2026-07-25 17:21:29 <ikke> And ideally, we would have some mechanism to download rust/go/* modules separately so that we do not to add `net` to all of them
2026-07-25 17:22:04 <WhyNotHugo> I think I mentioned this before: but downloading rust/go modules at build time is a problem for GPL-compliance (we don't keep the sources for the package we build).
2026-07-25 17:26:06 <fabricionaweb> is gitlab down? I think im been considered a bot 🤖
2026-07-25 17:27:08 <WhyNotHugo> fabricionaweb: works her
2026-07-25 17:27:53 <fabricionaweb> oh it passed now but well damn that took minutes
2026-07-25 17:35:23 <Sertonix[m]> [andypost](https://matrix.to/#/@andypost:matrix.org) testing/php81 tests seem to fail due to an expired certificated. Could you take a look at that?
2026-07-25 17:41:16 <andypost[m]> Sertonix: thanks, will check tonight!
2026-07-25 17:49:35 <craftyguy[m]> could a maintainer please take a look at !105346 ? Thank you!
2026-07-25 17:52:15 <andypost[m]> Sertonix: quickly searched and look we need to backport https://github.com/php/php-src/pull/22873 and probably 21617
2026-07-25 20:50:52 <proycon> fossdd: Could you take a look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/102439 sometime when convenient? I'm stuck on a failing aarch64 build which I don't know how to solve and I wonder if we should just release for x86_64 only if we can't find a fix, since the current package is broken anyway
2026-07-26 09:16:12 <pfzetto> Hi, I'm currently trying to package cryptpad.fr. What is the recommended path to install nodejs packages to? I'm currently using /usr/share/cryptpad for the entire project including node_modules.
2026-07-26 09:45:41 <iodomi[m]> does anybody know what happend to linux-hardened package? i think i saw it being used somewhere in the past, but its no longer in repos
2026-07-26 10:29:06 <ikke> It was removed in 2018
2026-07-26 10:29:17 <ikke> I think Ariadne wanted to bring one back, but that never materialized
2026-07-26 10:29:27 <ikke> 94a65a421705eb0152c2a6cdeb0bffd269c58e97
2026-07-26 10:45:06 <jvvv> Wasn't there an issue with the main hardening patch(es) becoming nonfree?
2026-07-26 10:46:08 <ikke> Yes, the grsec patches became closed
2026-07-26 10:46:27 <ikke> https://github.com/edera-dev/linux-openpax would be the replacement
2026-07-26 11:28:23 <jvvv> Ah, yes, that does sound familiar. I haven't looked into the openpax patches
2026-07-26 11:50:02 <Sertonix[m]> There is community/linux-openpax
2026-07-27 00:59:57 <Sertonix[m]> [andypost](https://matrix.to/#/@andypost:matrix.org) Same issue with testing/php82 it seems
2026-07-27 01:12:19 <Sertonix[m]> dalias: Have you seen https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/105685#note_633409 ?
2026-07-27 09:44:59 <ptrc> seems like Signal is broken on edge, tries to download a pre-compiled Chromium build into /tmp and fails horribly
2026-07-27 09:45:16 <ptrc> https://ptrc.gay/HpiFUYWm.png
2026-07-27 09:57:53 <ptrc> actually i'm not even sure what it's trying to download
2026-07-27 09:58:00 <ptrc> it segfaults when i try to run it on Debian
2026-07-27 10:08:22 <Sertonix[m]> Did you do apk upgrade --available? There was a downgrade IIRC
2026-07-27 10:11:20 <ptrc> ooooh
2026-07-27 10:11:21 <ptrc> right
2026-07-27 10:11:33 <ptrc> i didn't do an upgrade in the past few days, fair enough
2026-07-27 10:11:52 <ptrc> just checked that my version is the latest x.x
2026-07-27 10:11:53 <ptrc> thank you
2026-07-27 10:11:59 <ptrc> works now :3
2026-07-27 11:44:47 <skarnet> in what package is Alpine's initramfs built? it looks like linux-lts has the kernel but not the initramfs
2026-07-27 11:59:55 <vmignot> skarnet: mkinitfs I guess ?
2026-07-27 12:03:54 <skarnet> mkinitfs looks like the mechanism, i.e. the mkinitfs tool
2026-07-27 12:04:10 <skarnet> I want to know where that tool is used and the initramfs is produced and how I can look inside of it
2026-07-27 12:04:52 <dalias> sertonix[m], no, i'll check it out
2026-07-27 12:06:10 <skarnet> vmignot: oh it looks like it is actually invoked in the trigger in the mkinitfs aport
2026-07-27 12:06:21 <vmignot> yup
2026-07-27 12:06:44 <skarnet> I was looking at the mkinitfs project in g.a.o/alpine, not at the aport
2026-07-27 12:11:37 <vmignot> skarnet: sorry if it was unclear !
2026-07-27 12:11:56 <skarnet> it's not on you, it's on me for not checking XD
2026-07-27 12:12:28 <skarnet> doesn't look like mkinitfs takes a staging area in the filesystem though
2026-07-27 12:12:52 <skarnet> which makes an initramfs as difficult to study as ever :/
2026-07-27 12:31:40 <jvvv> skarnet: initramfs is generated via apk hook script. package updates to kernel, grub, stuff like that will trigger (re)building
2026-07-27 12:32:07 <jvvv> to look at the hook script, see aports/main/mkinitfs/mkinitfs.trigger
2026-07-27 12:32:13 <skarnet> yeah, I've seen it
2026-07-27 12:32:34 <skarnet> what I'm looking for is a full view of a rebuilt initramfs before it goes into the cpio
2026-07-27 12:32:46 <skarnet> but it doesn't seem like there is such a thing
2026-07-27 12:33:22 <jvvv> I usually uncompress and cpio it to a directory for inspection
2026-07-27 12:33:34 <jvvv> un-cpio, I guess
2026-07-27 12:33:59 <jvvv> of course that is after the fact
2026-07-27 12:36:30 <jvvv> for just a file listing, I do 'doas zcat /boot/initramfs-$(flavor) | cpio -t | less'
2026-07-27 12:36:50 <skarnet> yeah, I wanted to avoid reverse-engineering it
2026-07-27 12:36:54 <skarnet> but it's nbd
2026-07-27 12:38:51 <jvvv> ah, well, i usually find the long way around things, so my ideas are often obtuse (but usually get it done). sorry I don't have better insight
2026-07-27 14:16:20 <andypost[m]> @Sertinix: I will care about php82 tomorrow as new releases tagged
2026-07-27 17:38:09 <grossaffe[m]> Are there any plans to bring in any of the mesa bugfix releases on Alpine 3.24?  The current version (26.1.1) contains a bug that I believe is responsible for giving a strong red tint to some content streamed by jellyfin.  Release notes from 26.1.2 indicate that it fixed a bug that sounds like the one I'm experiencing.
2026-07-27 17:47:10 <grossaffe[m]> Was also talking with a jellyfin developer about some jellyfin-ffmpeg segfaults I've been seeing and he suspects something vulkan-related in mesa may be the cause there, too.
2026-07-27 17:56:06 <ncopa> we should probably bump mesa-26.1.2 in edge first. I don't see any reason to not backport that to v3.24
2026-07-27 17:56:32 <grossaffe[m]> There have been other bugfix releases since then, too.  We're up to 26.1.5 now.
2026-07-27 18:00:24 <ncopa> do we have MR for that?
2026-07-27 18:01:51 <grossaffe[m]> I don't think I saw anything for that when I as poking around the gitlab to see if there was already anything in the pipeline
2026-07-27 18:23:24 <grossaffe[m]> And as long as I'm asking about packages that relate to jellyfin, I saw that there's a version of skiasharp that delivers libharfbuzzsharp in the edge repository which is needed by jellyfin for some things.  Do you know if there are plans for that back-porting into 3.24?
2026-07-28 01:41:43 <qaqland> could someone help take a look at !97123 !101901 !103899
2026-07-28 09:09:06 <panekj> are there any plans to bump openssl?
2026-07-28 09:09:32 <sicelo> hi. with `install_if`, is it possible to express "install this subpackage if X and A or B are installed"? i.e. valid combinations are AX or BX or ABX
2026-07-28 09:09:40 <panekj> also what's the deal with another major release
2026-07-28 09:09:48 <sicelo> or "or" relationship cannot be expressed?
2026-07-28 09:12:10 <panekj> i think it would need a 2 (sub)packages each with own install_if and a dependency on package you want
2026-07-28 09:16:10 <panekj> https://tpaste.us/PJpb 
2026-07-28 09:18:21 <sicelo> panekj: that's a nice idea
2026-07-28 09:18:45 <panekj> uhm, i'm wrong, X should be in install_if as well
2026-07-28 09:18:48 <panekj> not in depends
2026-07-28 09:19:20 <panekj> but >1 (sub)package is needed because install_if is just sum of all packages required
2026-07-28 09:43:08 <WhyNotHugo> github .patch files which are in the master branch (e.g.: non-PR) are non-volatile. These are okay for sources= yet?
2026-07-28 09:43:11 <WhyNotHugo> *yes?
2026-07-28 09:46:52 <PureTryOut> Yes
2026-07-28 09:48:54 <jvoisin> panekj: https://transitions.ubuntu.com/html/openssl4.html#!good,bad,partial,unknown,!notintesting ubuntu is doing it, and it's a lot of non-fun apparently
2026-07-28 09:50:10 <WhyNotHugo> it always sadens me that libressl didn't really gain traction 
2026-07-28 09:51:52 <jvoisin> libressl, openssl, boringssl, aws-lc, …
2026-07-28 09:52:00 <jvoisin> rustls too :P
2026-07-28 09:54:25 <skarnet> bearssl first and foremost
2026-07-28 09:57:35 <panekj> jvoisin: arch did/does it and I'm getting build failure issues on projects i maintain
2026-07-28 09:58:56 <jvoisin> https://www.bearssl.org/changelog.html is it even maintained?
2026-07-28 10:05:12 <ncopa> openssl 3.5 is LTS https://openssl-library.org/policies/releasestrat/index.html I think it may be good to stick to LTS releases?
2026-07-28 10:06:28 <panekj> would it be possible to provide v4 separately?
2026-07-28 10:06:38 <panekj> at least on edge
2026-07-28 10:07:02 <ncopa> everything is possible. the impossible just takes longer time
2026-07-28 10:11:19 <WhyNotHugo> Can I have eyes on !106097? The impact of this bug is rather nasty (unbound memory usage in compositor, eventual crash).
2026-07-28 10:13:06 <lindsay> I noticed my Emacs configuration treats initd service files as scripts and always add exec perm when saving. (Seems I'm not the only one doing this).
2026-07-28 10:13:24 <lindsay> initd files in the aports repository have a mix of 644 and 755 permissions. Hope it doesn't cause problems.
2026-07-28 10:13:48 <WhyNotHugo> In theory you can run them directly (they have the right shebang)
2026-07-28 10:18:11 <lindsay> WhyNotHugo: I known, I use `/etc/init.d/XXX start` always :). I mean initd files in the aports git repository have different permission flags before packaging.
2026-07-28 10:20:10 <Sertonix[m]> Packages generally ignore the file mode when installing it to $pkgdir so it should be fine.
2026-07-28 12:41:46 <iodomi[m]> ikke: looks quite unmaintained
2026-07-28 14:58:57 <ayakael71> ptrc: yeah that's new and I havn't had the time to figure out why Signal would do something so evil as to download a whole pre-compiled Chromium build
2026-07-28 14:59:15 <ayakael71> ptrc: it'll stay on the current signal version till I take a stab at it
2026-07-28 15:11:28 <ptrc> ayakael71: thank you!
2026-07-28 15:38:11 <WhyNotHugo> Signal downloads all kind of binaries from all over the place for its builds
2026-07-28 15:38:36 <WhyNotHugo> For all their fine knowledge of cryptography, I questoin their supply-chain practices.
2026-07-28 16:01:05 <Sertonix[m]> Electron is intended to be used with a precompiled binaries. Not very specific to signal.
2026-07-28 16:02:57 <ikke> Electron is not supposed to be used :P
2026-07-28 16:07:17 <quinq> :>
2026-07-28 16:07:59 <panekj> Generally, but Signal seems to be some kind of next-level evil
2026-07-28 18:55:40 <Sertonix[m]> I am looking into it and there is nothing downloaded. It just looks like an incorrectly linked binary.
2026-07-28 22:01:43 <bdprom> anyone have any idea why `abuild rootbld` in a newly created pkg dir would cause OSError: [Errno 30] Read-only file system: '/home/user/aports/community/vkquake/output' ?
2026-07-28 22:02:07 <bdprom> the permissions are no different to other pkg dirs i've tried (and successfully) built in
2026-07-28 22:04:47 <bdprom> https://dpaste.com/BLQ7NT2JD
2026-07-28 22:11:53 <Sertonix[m]> I would guess builddir is not set correctly
2026-07-28 22:21:22 <bdprom> thanks ill look into that
2026-07-29 02:25:03 <Sertonix[m]> Some main/cryptsetup test failure seems to happen on the loongarch64 builders
2026-07-29 04:45:48 <ikke> Yes, but not clear what 
2026-07-29 12:14:42 <Sertonix[m]> ikke: The test passes in qemu. Maybe force the builder to try again?
2026-07-29 12:15:15 <ikke> Sertonix[m]: I've asked about it on #-loongarch, they looked at it. Apparently related to whether the twofish_* modules are loaded or not
2026-07-29 12:15:49 <ikke> ie, whether /proc/crypto contains ecb(twofish) or something like that
2026-07-29 12:16:37 <Sertonix[m]> So we probably want to skip that test for now?
2026-07-29 12:17:17 <ikke> I tried removing the modules
2026-07-29 12:17:23 <ikke> But didn't check if they have been loaded again
2026-07-29 12:17:53 <ikke> They have
2026-07-29 12:23:00 <Sertonix[m]> It's running the xts twofish tests even though it has detected xts(twofish) to not be available
2026-07-29 12:32:01 <ikke> It passed now, I've blacklisted the modules
2026-07-29 12:36:49 <Sertonix[m]> Thanks!
2026-07-29 13:45:03 <Sertonix[m]> new abuild rc on edge. Notably APKBUILD(5) overhaul and abuild rootbld being able to do real cross compilation.
2026-07-29 14:20:06 <SpieringsAE> I just encountered some issues with crun, I am running postmarketos with plasma-mobile on my device (thus systemd)
2026-07-29 14:20:16 <SpieringsAE> but crun is built with systemd support disabled
2026-07-29 14:20:53 <SpieringsAE> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/crun/APKBUILD#L38
2026-07-29 14:21:18 <ikke> Alpine does not have systemd
2026-07-29 14:21:33 <SpieringsAE> I believe there is some support for it being enabled no?
2026-07-29 14:21:43 <ikke> Not in alpine linux
2026-07-29 14:22:37 <ikke> At most we have subpackages for service files
2026-07-29 14:23:47 <SpieringsAE> like this https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/93661/diffs
2026-07-29 14:23:48 <SpieringsAE> yeah
2026-07-29 14:24:02 <SpieringsAE> okay but this would not be a thing I can change?
2026-07-29 14:25:27 <ikke> Depends on what it requires, the consequences, and the maintainer
2026-07-29 14:28:18 <SpieringsAE> it needs the systemd-dev package, figuring out now whether that is from the postmarketos repos
2026-07-29 14:28:43 <ikke> It is
2026-07-29 14:30:33 <SpieringsAE> yeah it is dang
2026-07-29 14:37:23 <Sertonix[m]> It would be fine if it would interface with systemd without libsystemd
2026-07-29 14:37:45 <ikke> Or use an open standard so that it's not tied to systemd
2026-07-29 14:40:28 <Sertonix[m]> They do interface with stuff like cgroupfs without libsystemd but I don't know if that works on the systemd side
2026-07-29 14:43:17 <Sertonix[m]> Similar with syslog. SpieringsAE, are you sure systemd can't interface with these shared interfaces?
2026-07-29 14:48:42 <SpieringsAE> it didn't want to work when I tried it. I had been debugging it for a while now
2026-07-29 14:49:28 <SpieringsAE> if I forced podman with --cgroup-manager cgroupfs
2026-07-29 14:49:40 <SpieringsAE> it would still error about systemd not being supported or something
2026-07-29 14:50:18 <SpieringsAE> just did a clean install let me test some more, there was some other funky stuff about that install
2026-07-29 14:55:14 <SpieringsAE> --cgroup-manager string       Cgroup manager to use ("cgroupfs"|"systemd") (default "cgroupfs")
2026-07-29 14:55:23 <SpieringsAE> it tries cgroupfs by default
2026-07-29 14:57:30 <SpieringsAE> Failed to add conmon to cgroupfs sandbox cgroup: creating cgroup path conmon: mkdir /sys/fs/cgroup/conmon: permission denied
2026-07-29 14:57:37 <SpieringsAE> hmm okay thats not fully what I remember
2026-07-29 15:00:16 <SpieringsAE> guess I might need some kind of group
2026-07-29 15:10:27 <lotheac> did you try asking on #postmarketos?
2026-07-29 15:10:46 <lotheac> this isn't a support channel anyways...
2026-07-29 15:16:04 <SpieringsAE> jeah, thats where I did all my triaging, with this conversation combined, its moved back to making a downstream package there
2026-07-29 15:18:35 <bdprom> SpieringsAE: if you're sure the cause of the problem is the missing crun ./configure flag then it's relatively easy to clone the aports/pmaports pkg tree and rebuild a single package
2026-07-29 15:20:16 <SpieringsAE> yeah thats what I did to test it
2026-07-29 15:21:48 <bdprom> ah cool
2026-07-29 16:53:59 <Sertonix[m]> abuild pc provider/dependency detection is subtle broken on edge. I will try fix that soon.
2026-07-29 17:59:21 <mini_bomba[m]> to aports managers: my 4 week old !104889 MR is passing the pipeline again
2026-07-29 21:49:09 <elagost> could someone look at this? !103937 finally got the pipeline to pass again after riscv builders got through enough stuff
2026-07-30 02:07:02 <qaqland> when i'm using abuild rootbld, it shows:
2026-07-30 02:07:04 <qaqland>   Executing alpine-baselayout-3.7.2-r1.post-install
2026-07-30 02:07:04 <qaqland>   Executing alpine-baselayout-3.7.2-r1.pre-install
2026-07-30 02:07:04 <qaqland> (27/75) Installing alpine-baselayout (3.7.2-r1)
2026-07-30 02:07:04 <qaqland>   * chown: etc/shadow: Invalid argument
2026-07-30 02:07:50 <qaqland> has anyone else met this?
2026-07-30 02:09:31 <jvvv> yes, I just checked a build log from a build done earlier today, the same
2026-07-30 02:16:10 <jvvv> I am betting this is a container permissions issue, similar to trying mknod in an unprivileged container
2026-07-30 02:23:26 <jvvv> That does not seem to follow, though because the error message should reflect
2026-07-30 02:26:50 <jvvv> I wonder about adding '--no-scripts' to the containers base install (abuild line 2567)
2026-07-30 02:30:37 <jvvv> I think that would break installing builddeps, but perhaps to apk invokes one for baselayout and one for builddeps
2026-07-30 02:30:50 <jvvv> s/to apk/two apk/
2026-07-30 02:40:13 <jvvv> Since the error does not effect the build, though, no change may be best
2026-07-30 05:41:14 <jvvv> mio: Thanks for catching that mistake in !106186 and pointing me to !106150
2026-07-30 06:16:57 <mio> jvvv: you're welcome
2026-07-30 07:54:28 <qaqland> !105809 is so weird, it works fine locally and only fails on x86 and x86_64 in CI
2026-07-30 08:08:17 <lotheac> sounds kinda familiar... i think the python test failures that happen on those architectures were also signal related
2026-07-30 08:08:31 <lotheac> i really need to dig into what's going on in there
2026-07-30 09:58:45 <Sertonix[m]> qaqland: The etc/shadow error can be ignored: https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/495
2026-07-30 11:26:35 <panekj> !105352 could be closed? edge is on 153 already (cc: ptrc)
2026-07-30 11:30:04 <panekj> also !105758 could be merged mayhaps?
2026-07-30 12:31:47 <WhyNotHugo> Using `openrc_depends` on APKBUILD is supported?
2026-07-30 12:39:00 <WhyNotHugo> Oh, it's depends_openrc
2026-07-30 16:19:00 <jvoisin> is there a way to mark a package (eg. py3-six) as deprecated?
2026-07-30 16:21:17 <Sertonix[m]> No
2026-07-30 16:23:48 <jvoisin> grmbl
2026-07-30 16:24:00 <jvoisin> https://gitlab.alpinelinux.org/alpine/aports/-/work_items/17822 is still making me sad
2026-07-30 19:25:16 <xordspar0> Is anyone intersted in taking over maintenance of community/lua-language-server? It's a couple minor versions behind because of test failures on RISC-V. See !96325
2026-07-30 19:26:26 <xordspar0> I'm a regular user of helix editor + lua-language-server, but the frequent small updates and flaky test suite have gotten tiring.
2026-07-30 19:28:39 <jvoisin> sounds like something that should be addressed upstream, shouldn't it?
2026-07-30 19:42:40 <ikke> gitlab will be restarted at 19:00 UTC (in ~20 minutes) for upgrades and will be briefly unavailable
2026-07-30 19:44:55 <ikke> sorry, 20:00 UTC
2026-07-30 19:51:30 <Habbie> can confirm, it's almost 20:00 UTC
2026-07-30 19:51:34 <Habbie> 19:42Z <@ikke> gitlab will be restarted at 19:00 UTC (in ~20 minutes) for upgrades and will be briefly unavailable
2026-07-30 19:51:51 <ikke> Classic off-by-one
2026-07-30 20:00:15 <ikke> gitlab is being upgraded, should be back soon
2026-07-30 20:05:49 <ikke> gitlab is back
2026-07-31 05:51:30 <ionxt> When will a new version be built for mesa? Mesa 26.1.1 has an awfull bug on older intel graphics.
2026-07-31 05:56:39 <grossaffe[m]> ionxt: AMD, too.  I was asking about it in here a couple days ago, but might still need a proper gitlab ticket.  Edge still has 26.1.1 in it, too, so it needs to go through that process before bringing into stable.
2026-07-31 06:14:54 <ionxt> Mesa is now on 26.1.6 why a new built needs a ticked?
2026-07-31 06:16:31 <ionxt> ticket
2026-07-31 06:31:09 <ikke>  ionxt: For documentation purposes, to notify the maintainer
2026-07-31 07:32:02 <alexaandru> hi all! When someone has a chance, !106231 is a security upgrade. TIA!