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.