2025-03-01 11:02:25 <navi> i see alpine builds openrc with -Dpam=false -- noting here that this means openrc --user can't be automatically started at login
2025-03-01 11:05:46 <fossdd[m]> not sure but i think it should be doable enable it
2025-03-01 11:05:57 <fossdd[m]> it originally came from b02c2e706e32
2025-03-01 11:06:07 <fossdd[m]> b02c2e706e322e1013793d00c6e9f055aedd478e
2025-03-01 11:07:17 <navi> as is it'd require pulling in linux-pam as a dependency for the base system though
2025-03-01 11:14:24 <WhyNotHugo> can somebody merge !79075 and !80277
2025-03-01 11:15:06 <WhyNotHugo> navi: linux-pam is already in main, so it should be reasonable to have it as a makedepends.
2025-03-01 11:15:27 <WhyNotHugo> I'd suggest putting the pam module in a subpackage tho, so pam doesn't forcibly get pulled by openrc itself
2025-03-01 11:17:42 <navi> it'd need to adjust openrc's meson.build for that, but could be doable
2025-03-01 11:17:58 <navi> at the moment, we only build pam_openrc if -Dpam=true
2025-03-01 11:18:19 <navi> but that means all the tools become pam aware, including the supervisors
2025-03-01 11:19:19 <WhyNotHugo> what do supervisors do when being pam-aware?
2025-03-01 11:20:21 <navi> start pam sessions for the users they change into, i.e. `command_user=foo:nya` would call open_session and close_session for /etc/pam.d/$supervisor as `foo`
2025-03-01 11:21:06 <navi> but that also means they link against libpam, so, runtime dep, not make
2025-03-01 11:22:04 <WhyNotHugo> Yeah, sounds like you need separate flags
2025-03-01 11:23:04 <navi> building only pam_openrc and openrc-user against libpam and nothing else seems perfectly doable in the build files-- then the split package would have only those two, and only the split package would depend on linux-pam
2025-03-01 11:58:03 <donoban> is there any altenarive for "detect" logins? utmp already knows when users login without pam need
2025-03-01 12:01:39 <donoban> or just the desktop start could do it... if it doesn't need to read user passwords, fingerprints etc.. why use pam? just for notice that user logged in? 
2025-03-01 12:02:50 <navi> utmp is extremelly unreliable to which tools write to it and which don't (login does, xterm does, other terminal emulators don't), utmp doens't work under musl without utmps
2025-03-01 12:03:03 <navi> and it's not just about detecting
2025-03-01 12:03:27 <navi> the user init script is not running until you log in, there needs to be some kind of hook to symlink it and start it
2025-03-01 12:03:47 <donoban> well it was just an example that 'linux-pam' wasn't strictly needed 
2025-03-01 12:03:49 <navi> pam_openrc is still, however, optional. should you want you can call `openrc --user` any which way you want
2025-03-01 12:04:07 <navi> it is the most seamless experience i could come up with for users though
2025-03-01 12:04:42 <navi> so ideally we can do a split package, and users not wanting pam can just, not install it, and call `openrc --user` on their shell files or similar
2025-03-01 12:04:57 <donoban> imo all this "user service" is a complexity layer on the wrong direction... but it seems forced in some way for main desktop enviroments
2025-03-01 12:06:08 <navi> modern systems to have a dozen services that need to run an instance for each active user, i don't see another way (e.g. pipewire, dbus, notification daemons, mpd, ssh-agent, gpg-agent, xdg-desktop-portals)
2025-03-01 12:06:13 <navi> do have*
2025-03-01 12:15:37 <donoban> there "many" other ways, but it seems that starting your pipewire process using the main system service manager is more cool than starting it on your desktop init script... sure there are some "advantages" but also adds a layer of complexity (like adding linux-pam as dependency) 
2025-03-01 12:19:44 <navi> running pipewire on the desktop init script is not a solution, it's the sysvinit problem again. no supervision, no dependency resolution
2025-03-01 12:19:46 <navi> and, pam is optional. you can make use of the advantages without it by launching `openrc --user` manually on your desktop init script. the use for pam is exclusively to allow openrc to manage itself and thus play nicer with desktop environments
2025-03-01 12:19:58 <navi> so, let's just have a sub package and let users choose
2025-03-01 12:26:22 <donoban> everything is optional :)
2025-03-01 12:30:45 <prabu> m4r35n357, i faced file permission issues in pizero2w for picam..more details here in #16911 i used default setup-alpine and setup-devd udev.. not sure the error you face is caused by the same setting somewhere...
2025-03-01 13:03:00 <WhyNotHugo> donoban: you can run a user service manger via .profile (which is what I do)
2025-03-01 13:03:22 <WhyNotHugo> no need to entangle system services with user services
2025-03-01 13:09:06 <donoban> well I just use 'sway/config'
2025-03-01 13:13:38 <navi> that's too late for dbus but works if you don't need it
2025-03-01 13:20:44 <donoban> I launch sway with dbus-run-session
2025-03-01 13:21:07 <WhyNotHugo> navi: it's only "too late" if your dependency ordering is messed up
2025-03-01 13:21:29 <WhyNotHugo> we've talked about this: it's perfectly feasible to start dbus after the compostior. everything still works
2025-03-01 13:23:44 <donoban> I don't know details but is not dbus also some kind of "service launcher"? assuming you have dbus-daemon-launch-helper
2025-03-01 13:24:18 <WhyNotHugo> dbus-daemon-launch-helper is only required for the system instance, the session instance always auto-activates
2025-03-01 13:24:39 <WhyNotHugo> And yes, dbus-daemon will automatically start daemons (ignoring any service manager except systemd).
2025-03-01 13:24:49 <WhyNotHugo> other implementations are configurable (e.g.: dbus-broker)
2025-03-01 13:28:44 <donoban> in my case it didn't launch mako, but maybe I miss dependency
2025-03-01 13:28:50 <donoban> anyway I don't care launching it via sway/config
2025-03-01 17:46:14 <navi> WhyNotHugo: you can start dbus after, but you need to export the dbus address variable beforehand
2025-03-01 17:46:38 <navi> that or rely on dbus' heuristics with the .dbus folder
2025-03-01 17:46:40 <dalias> any ideas about this? https://gitlab.alpinelinux.org/alpine/aports/-/issues/16942
2025-03-01 18:47:21 <jvvv> is it correct that abuild's default.conf exports LDFLAGS twice?
2025-03-01 18:53:09 <ikke> It's no longer in master, so apparently has already been fixed
2025-03-01 18:54:58 <ikke> oh, it's added in the APKBUILD
2025-03-01 18:55:17 <ikke> So I suppose it's on purpose
2025-03-01 18:55:33 <ikke> And the 2nd time it is expanding them
2025-03-01 18:58:26 <jvvv> ok. i'm just looking at the history of the aport.
2025-03-01 18:59:19 <ikke> According to the comments, those options are only supported on specific arches
2025-03-01 19:00:40 <jvvv> yep, cased by arch
2025-03-01 19:16:30 <jvvv> while not affected mentioned issue, this may be interesting (some what related, i think): https://gitlab.com/qemu-project/qemu/-/commit/6d701c9bac1d3571e9ad511e01b27df7237f0b13
2025-03-02 00:48:39 <dalias> uhg
2025-03-02 00:48:59 <dalias> 32 bit host is one of the most importamt use cases for qemu
2025-03-02 00:49:11 <dalias> running stuff thats 64 bit exclusive
2025-03-02 00:54:44 <jvvv> reading that commit message was disappointing for me, to say the least
2025-03-02 01:14:38 <skarnet> ah yes, the emulator that stops emulating platforms that become available mainly via emulators
2025-03-02 01:14:47 <skarnet> perfect strategic move
2025-03-02 01:18:22 <psykose> what does 'emulating platforms that become available mainly via emulators' mean
2025-03-02 01:22:56 <skarnet> what has happened to you? I remember a not distant time where you weren't questioning in bad faith everything I said
2025-03-02 01:23:25 <skarnet> it's not particularly obscure, difficult to understand, or even badly formulated
2025-03-02 01:23:46 <psykose> uh, i mean it sincerely
2025-03-02 01:23:52 <skarnet> of course you do
2025-03-02 01:23:59 <psykose> i don't understand the sentence, neither literally not in relation to 32-bit host support
2025-03-02 01:24:11 <psykose> nor*
2025-03-02 01:24:19 <skarnet> as time goes by, 32-bit platforms become less and less available in the wild, as real, metal computers
2025-03-02 01:24:26 <psykose> yea
2025-03-02 01:24:44 <skarnet> so the main way to address them is via emulators
2025-03-02 01:24:49 <psykose> and that is still supported?
2025-03-02 01:25:10 <psykose> 32-bit host support means running on the 32-bit cpus directly to emulate e.g. 64-bit or another cpu arch from them
2025-03-02 01:25:23 <skarnet> oh, deprecation of 32-bit *host* support, I missed that
2025-03-02 01:25:37 <skarnet> yeah that's not as bad
2025-03-02 01:25:42 <skarnet> that's still annoying though
2025-03-02 01:25:52 <psykose> somewhat
2025-03-02 01:26:16 <psykose> it's nice to see that being confused about a misunderstanding is 'questioning in bad faith' though
2025-03-02 01:26:23 <skarnet> sorry about that
2025-03-02 01:27:10 <skarnet> I said that because it's not the first time it happened, but this time I was in the wrong
2025-03-02 01:27:22 <pj> casual 2am -devel banter
2025-03-02 02:16:20 <pj> why is lld missing in 3.21 on s390x?
2025-03-02 02:17:23 <psykose> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/80300 was after 3.21
2025-03-02 02:17:48 <pj> ye, I'm looking at https://gitlab.alpinelinux.org/alpine/aports/-/commit/abd73bcecf13ef986f01eeeea95f2df09ba07dbc
2025-03-02 10:45:47 <vkrishn> vim and kakoune(kak) works differently in 'lxc-console' (syntaxhighlight), i guess its by design
2025-03-02 12:44:44 <chereskata> Hi, hope you are all doing well
2025-03-02 12:45:32 <chereskata> I randomly saw, that the gstreamer package has some vulns listed in security.alpinelinux.org, albeit beeing already at 1.24.12, but 1.24.9 is listed as edge-main branch (https://security.alpinelinux.org/vuln/CVE-2024-47546)
2025-03-02 12:45:44 <chereskata> why does this happen
2025-03-02 12:45:51 <chereskata> Is the behavior expected?
2025-03-02 13:02:59 <ikke> chereskata: it should show the latest package on edge
2025-03-02 14:34:00 <yaboyfred> with openrc-0.60-r0, /etc/rc.conf is no longer loaded
2025-03-02 14:34:35 <yaboyfred> but this was fixed in the subsequent commit
2025-03-02 14:39:30 <ikke> yaboyfred: Would you be able to open an issue for that in aports?
2025-03-02 14:39:46 <yaboyfred> It was a simple actual parameter change, can I just pull request a patch?
2025-03-02 14:41:05 <ikke> Also fine, please include details in the commit message / MR description
2025-03-02 14:42:01 <yaboyfred> Sure
2025-03-02 15:12:50 <yaboyfred> !80775
2025-03-02 15:13:20 <navi> i was about to do the same in gentoo, while waiting for william to do a .1 release
2025-03-02 15:14:47 <ikke> yaboyfred: you need to bump pkgrel
2025-03-02 15:15:03 <yaboyfred> Yes I just noticed myself
2025-03-02 17:35:56 <PureTryOut> Hmm trying to start a service as a regular user with OpenRC 0.60, but it just reports that "You are attempting to run an openrc service on a system which openrc did not boot".
2025-03-02 17:39:09 <navi> create any runlevel in .config/rc/runlevels and `openrc --user <runlevel>`
2025-03-02 17:39:49 <navi> the lack of pam autostarting means the softlevel file doesn't exist
2025-03-02 17:42:51 <navi> (actually just the lack of a runlevel being launched)
2025-03-02 17:43:07 <navi> we can probably just remove that softlevel check from user-mode though
2025-03-02 17:44:38 <PureTryOut> ah, guess that needs to be added to /etc/skel by the distro then?
2025-03-02 17:45:44 <PureTryOut> Running openrc --user default after making that runlevel (which is just a directory right?) gives me Error: fopen(/var/log/rc.log) failed: Permission denied
2025-03-02 18:03:02 <navi> so i never tested it with rc_logger on huh
2025-03-02 18:03:35 <navi> set `rc_logger=NO` in .config/rc/rc.conf
2025-03-02 18:06:16 <navi> (or set rc_log_path to something your user can write)
2025-03-02 18:12:37 <PureTryOut> ah yeah setting that path works
2025-03-02 18:16:57 <navi> i'll open an issue so i don't forget to fix rc_logger
2025-03-02 18:18:35 <PureTryOut> 👍️
2025-03-02 18:20:20 <PureTryOut> Ok this works now, awesome. Ported the Pipewire package over to use the new user services, https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/80792
2025-03-02 18:22:22 <PureTryOut> Although, nothing runs on a fresh boot...
2025-03-02 18:22:54 <PureTryOut> Do I somehow need to run `openrc --user <my runlevel>` on boot every time?
2025-03-02 18:23:09 <navi> without pam yes
2025-03-02 18:23:19 <PureTryOut> but I do have pam
2025-03-02 18:23:25 <navi> alpine builds openrc without it
2025-03-02 18:23:28 <navi> -Dpam=false
2025-03-02 18:23:41 <navi> it's a thing i brought up yesterday i think
2025-03-02 18:24:01 <PureTryOut> oh... that's disappointing
2025-03-02 18:24:29 <navi> the current consideration is making a sub-package for user services where pam is enabled
2025-03-02 18:24:45 <navi> tho that still needs a login mechanism that uses pam (so, not busybox login)
2025-03-02 18:25:28 <PureTryOut> most desktops (where Pipewire is relevant) will use display managers to start their DE anyway which handles that
2025-03-02 18:25:55 <navi> yeah, pretty much any greeter will do
2025-03-02 18:38:42 <PureTryOut> But yeah I definitely need a OpenRC build with PAM support then...
2025-03-02 18:40:11 <minimal> well the suggestion of adding a openrc-user subpackage is the best way to go
2025-03-03 00:34:56 <quinq> Hummm, it seems that libtls is broken
2025-03-03 00:34:56 <quinq> /usr/lib/gcc/x86_64-alpine-linux-musl/14.2.0/../../../../x86_64-alpine-linux-musl/bin/ld: /usr/lib/gcc/x86_64-alpine-linux-musl/14.2.0/../../../../lib/libssl.a(libssl-lib-tls_common.o): in function `tls_free':
2025-03-03 00:35:02 <quinq> /home/buildozer/aports/main/openssl/src/openssl-3.3.3/ssl/record/methods/tls_common.c:1459: multiple definition of `tls_free'; /usr/lib/gcc/x86_64-alpine-linux-musl/14.2.0/../../../../lib/libtls.a(libtls_la-tls.o):tls.c:(.text+0x1365): first defined here
2025-03-03 00:36:32 <quinq> (happens when linking with tls_free symbol from libtls)
2025-03-03 00:39:41 <quinq> Not sure that's an Alpine bug per se (although it wasn't cought), looks like an upstream bug from this weird libretls
2025-03-03 00:41:05 <quinq> Ah, it's abandoned
2025-03-03 00:41:21 <quinq> Maybe Alpine should cure it off
2025-03-03 00:46:24 <quinq> Oh, and libressl-dev package is broken against openssl-dev on Alpine
2025-03-03 00:46:33 <quinq> ERROR: libressl-dev-4.0.0-r0: trying to overwrite usr/include/openssl/sha.h owned by openssl-dev-3.3.3-r0.
2025-03-03 00:46:38 <quinq> (on edge)
2025-03-03 00:47:33 <quinq> (just an excerpt of several more errors of the same type)
2025-03-03 03:28:35 <anjan> Hey, I need to downgrade haxe so I can package this thing I need
2025-03-03 03:28:37 <anjan> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/79319
2025-03-03 10:40:05 <skarnet> quinq: libretls, abandoned? where did you see that?
2025-03-03 11:03:37 <f_> skarnet: Last commit was over 2 years ago: https://git.causal.agency/libretls/log/
2025-03-03 11:04:04 <f_> but I guess I can ask
2025-03-03 11:14:09 <quinq> skarnet, what f_ said, I'm trying to follow the metrics I saw used here, that no code change means abandoned
2025-03-03 11:14:32 <f_> quinq: I have asked in the ascii.town irc channel anyway to confirm
2025-03-03 11:14:37 <quinq> I also read “bitrot” or something
2025-03-03 11:14:46 <f_> even though it might not be on-topic there :p
2025-03-03 11:14:46 <quinq> Thanks f_ :)
2025-03-03 11:16:46 <quinq> Also it's several versions behind upstream
2025-03-03 11:16:57 <quinq> But those are two separate problems
2025-03-03 11:43:56 <skarnet> the fact that it's behind upstream is indeed a problem, but if no code change in 2 years meant a project was abandoned, then I'd have a lot of abandoned projects, which they definitely aren't :/
2025-03-03 11:45:05 <quinq> I definitely agree with that
2025-03-03 11:45:13 <quinq> But.
2025-03-03 11:45:40 <ikke> skarnet: For a project like libretls, 2 years without commits does not sound healthy
2025-03-03 11:45:58 <skarnet> yeah I agree with that
2025-03-03 11:46:17 <skarnet> it should follow openssl releases closely
2025-03-03 11:49:06 <quinq> Well, both openssl and libressl (and rather the latter), because it's an hybrid of both
2025-03-03 11:51:55 <skarnet> no, it implements libtls on top of openssl, it needs to stick closely to openssl for security reasons; whereas on the LibreSSL side, it only needs to follow API changes to libtls, which don't happen often.
2025-03-03 11:57:51 <quinq> Not sure what the “no” is about because you just confirmed it's a hybrid of both, libretls api, and openssl back-end
2025-03-03 11:58:03 <quinq> anyway
2025-03-03 12:30:59 <telmich> I wonder if she should revert firefox also to 135.0 instead of 135.0..1 -> it crashes all the time -> https://github.com/void-linux/void-packages/issues/54403
2025-03-03 12:31:55 <telmich> Not sure if that one of void-linux is related to us: https://github.com/void-linux/void-packages/commit/4169011c915a0a4a2e8d7a3bbcc939cbb1551f0f
2025-03-03 12:49:31 <telmich> ... seems to be kernel related.
2025-03-03 12:53:08 <telmich> No, or not. opening matrix.ungleich.ch causes a freeze in firefox
2025-03-03 12:54:06 <ptrc> wait, which Alpine / Firefox version?
2025-03-03 12:54:38 <sam_> i've left a comment on the void bug, no idea if it's actually the same problem or not as i don't see any backtraces posted there
2025-03-03 12:55:40 <ptrc> i'd try and debug it, but for now on edge+135.0.1 i can't reproduce anything
2025-03-03 13:03:51 <telmich> it's 135.0.1 - I cannot reproduce on another machine using 135.0
2025-03-03 13:04:23 <telmich> hmm, are you also on intel/i915? For me it started happening today or yesterday
2025-03-03 13:04:32 <telmich> I'm on edge on all notebooks
2025-03-03 13:04:51 <telmich> I can try upgrading another machine, see if it breaks there, too
2025-03-03 13:06:14 <ptrc> oh, i *could* try on an intel machine
2025-03-03 13:12:06 <sam_> a backtrace would be welcome if you can get one
2025-03-03 14:44:03 <telmich> sam_: how would i create a backtrace of it?
2025-03-03 14:45:52 <sam_> run firefox under gdb or use e.g. minicoredumper to get a coredump and run gdb on that once it crashes
2025-03-03 14:46:10 <ikke> Try to run it with `ulimit -c unlimited` set
2025-03-03 14:51:36 <telmich> But it does not crash
2025-03-03 14:51:41 <telmich> It just hangs/freezes
2025-03-03 14:53:31 <telmich> gdb says "/usr/bin/firefox: not in executable format file format not recognized" - I assume it's a wrapper 
2025-03-03 14:54:03 <ptrc> yeah, /usr/lib/firefox/firefox
2025-03-03 14:54:31 <sam_> you said "crashes all the time"
2025-03-03 14:54:31 <telmich> yeap...running gdb with it, but it is detaching from all the forks firefox spawns
2025-03-03 14:54:42 <sam_> but for me, it freezes, and then crashes a while later
2025-03-03 14:54:50 <sam_> it may not be the same problem but a backtrace is useful if it is crashing at all either way
2025-03-03 14:55:03 <sam_> you can do `set follow-fork-mode child`, but i didn't have to in gentoo with our wrapper 
2025-03-03 14:55:20 <sam_> i think the signal got propagated back because of how firefox is designed rathe rthan it being the usual case
2025-03-03 14:56:15 <telmich> ha, sorry for the confusion
2025-03-03 14:56:28 <telmich> I meant to say it hangs up / freezes, does not actually ever exit
2025-03-03 14:56:40 <telmich> It stops drawing / refreshing though
2025-03-03 14:57:16 <sam_> fwiw, for me, it did exactly the same thing, just then ended up crashing because some session is disposed and something didn't check for that properly
2025-03-03 14:57:21 <sam_> but maybe it's just a coincidence and not the same problem
2025-03-03 14:57:26 <sam_> just the timing is interesting and sounds similar
2025-03-03 14:57:40 <telmich> For you it also started with 135.0.1?
2025-03-03 14:58:59 <telmich> It seems to be similar to other rendering issues I used to have with chromium before.  afair, removing some intel driver from xorg did fix this. However on that notebook I am already running with the modesetting driver
2025-03-03 15:00:02 <sam_> the problem is I was pissed off with it for a while and ignored it
2025-03-03 15:00:27 <sam_> someone bisected by versions at first and found 131 was the first bad version, but actually bisecting between that wasn't so useful 
2025-03-03 15:00:39 <telmich> Unfortunately understandable 
2025-03-03 15:00:57 <sam_> fwiw someone else filed a bug where they only hit it with no GLX and they've said the patch fixes that case too
2025-03-03 15:00:59 <sam_> very strange
2025-03-03 15:01:07 <sam_> I think it's very timing dependent -- I tried to repro under rr and couldn't
2025-03-03 15:01:13 <telmich> bbl -> it's shortly after midnight in Korea, will read up in the morning
2025-03-03 15:01:15 <sam_> i think it relies on the session being updated/disposed
2025-03-03 15:01:17 <telmich> ohhh..glx.. there was something
2025-03-03 15:01:18 <sam_> gn!
2025-03-03 15:02:28 <sam_> I guess my one at least was latent for quite some time, the upstream bug for it which has the patch that fixes it (and I believe it's the same root cause) is 2 years old
2025-03-03 15:02:34 <sam_> just.. happened to get a patch attached to it last month
2025-03-03 15:02:48 <sam_> so my guess is maybe they've had a bunch of people hitting it w/ the crash reporter and someone paid attention to it then
2025-03-03 15:03:39 <sam_> it also just might be a coincidence :D
2025-03-03 15:25:19 <eduardreforminai[m]> Hello 👋🏻
2025-03-03 15:37:48 <ptrc> hello \o
2025-03-03 15:38:24 <panekj> i suspect it's a bot
2025-03-03 15:39:15 <panekj> they just joined multiple channels in very short time span including channel for some other project that isn't really known that much
2025-03-03 15:40:32 <ptrc> would a bot introduce themselves so nicely? /j
2025-03-03 15:44:29 <panekj> ha
2025-03-03 15:44:42 <panekj> they DM'd a scam to me
2025-03-03 15:45:59 <ptrc> LMAO
2025-03-03 15:47:10 <panekj> "Hello 👋🏾 good day  panek you’re welcome to our trading platform(The home of life change opportunity, Are you ready to learn and start earning too...??
2025-03-03 15:59:53 <pj> ok, it's not bot but it is scam account lol
2025-03-03 16:01:35 <abby> never trust an emoji user 💀
2025-03-03 20:08:35 <craftyguy[m]> sertonix: do you know of a way to find all packages in aports that install relative symlinks to a certain path/dir?
2025-03-03 20:18:24 <sertonix[m]> Only with a local mirror of the repository. I think I attached a file with all symlinks in packages on some comment. It's a bit outdated though
2025-03-03 20:19:20 <craftyguy[m]> a local mirror of the binary repo?
2025-03-03 20:19:40 <sertonix[m]> Yes 🙃
2025-03-03 20:19:40 <craftyguy[m]> (I assume so, but just checkin)
2025-03-03 20:21:48 <sertonix[m]> craftyguy: Here the list I created 3 months ago https://gitlab.alpinelinux.org/alpine/aports/-/issues/16514#note_455305
2025-03-03 20:32:49 <craftyguy[m]> oh nice, and you reference my failed MR, sorry for missing this 😅
2025-03-03 20:56:59 <Ariadne> fwiw firefox 135.0.1 is stable for me on arm and loongarch, but those machines don't have intel gpu
2025-03-03 21:04:50 <quinq> For me it breaks reliably every-time I use some video capture feature
2025-03-03 21:05:07 <quinq> You can do one, close the window, start another one and it'll freeze forever until you kill it
2025-03-03 22:02:41 <staceee> hey guys, got problem with pipewire echo-cancel plugin: aec plugin audio.aec not available library.name aec/libspa-aec-webrtc
2025-03-03 22:09:27 <fossdd[m]> uhmmm
2025-03-03 22:09:59 <fossdd[m]> likely caused by !80799
2025-03-03 22:10:01 <fossdd[m]> but ive no idea why
2025-03-03 22:19:40 <fossdd[m]> staceee: can you check if !80856 fixes the issue?
2025-03-03 22:20:10 <staceee> right let me check that
2025-03-03 22:22:45 <staceee> fossdd[m]: it does
2025-03-03 22:23:01 <staceee> so pipewire build was not using the -2 version?
2025-03-03 22:23:50 <fossdd[m]> great thanks!
2025-03-03 22:23:51 <fossdd[m]> it was, but apparently it took -2 even if it was incompatible with it
2025-03-03 22:24:34 <staceee> latency seems better than before
2025-03-03 22:24:52 <staceee> well maybe placebo effect
2025-03-03 22:24:58 <fossdd[m]> hehe
2025-03-03 22:25:16 <staceee> thanks for the quick fix o/
2025-03-04 00:35:42 <francis[m]> From Trusted and Vouched Dealers... (full message at <https://matrix.org/oftc/media/v1/media/download/ATs_nRoOus5CI6bRlcOjqpbLp_CkNeZw2Gg6d8macT9GVTavhYs8fUE-M-0JH_p4o12ZJ2i16uVaXq9Xoa2I5pFCeVpq17_QAG1hdHJpeC5vcmcva0NhT2RhYVB5bUhScFVrc0xmWXJCdUd4>)
2025-03-04 05:51:06 <telmich> Good morning to sam_ and ptrc especially... I figured out that he firefox hang was an issue with pipewire not running correctly. Not sure exactly why pipewire had an issue, but killing it and relaunching fixes the problem. I discovered it when running pavucontrol-qt that listed no available devices
2025-03-04 05:52:34 <psykose> having zero outputs at all makes firefox hang trying to output something yeah
2025-03-04 05:53:00 <psykose> restarting pipewire probably makes firefox fall back to 'couldnt even connect to audio' instead of 'connected but 0 devices hang'
2025-03-04 10:01:27 <lotheac> can someone merge !78944 !78838 ? they've been open for so long that aports-qa-bot started complaining :)
2025-03-04 10:07:10 <fossdd[m]> added a kinda non-blocking comment to yaml-language-server
2025-03-04 10:07:25 <lotheac> addressing...
2025-03-04 10:34:14 <markand> can !79397 be merged? there are some lint warning about custom variables starting with '_' but there are dozen of APKBUILD doing this too
2025-03-04 10:35:22 <ikke> markand: doesn't mean you cannot improve it
2025-03-04 10:35:34 <markand> but what's the alternative?
2025-03-04 10:35:52 <markand> custom_variable=bar ?
2025-03-04 10:36:57 <ikke> It complains about the variables not starting with a _
2025-03-04 10:37:16 <markand> ah my bad
2025-03-04 10:37:18 <ikke> APKBUILD:20:2:prefix custom variable with _: with_dynarec
2025-03-04 10:37:24 <markand> let's go
2025-03-04 10:39:33 <fabricionaweb> Maybe its old aports
2025-03-04 10:39:56 <fabricionaweb> Imo is always good to follow/fix the linting 
2025-03-04 10:40:44 <markand> pushed
2025-03-04 10:42:26 <fossdd[m]> it would be really nice if someone could merge !80874
2025-03-04 10:42:58 <fossdd[m]> ( lesson learned, dont automate too much 😅 )
2025-03-04 10:48:13 <markand> oh gosh I pushed an older branch from my other machine brr
2025-03-04 10:48:15 <fossdd[m]> lotheac: thanks, can you also squash your commits (since its a new package, the development history is not that useful)
2025-03-04 10:54:57 <lotheac> fossdd[m]: squashed & rebased
2025-03-04 11:42:45 <vkrishn> sct(testing/), xsct(community/) both calculate color temperature differently
2025-03-04 11:43:28 <vkrishn> sct now has a versioned release, if someone still maintaining it
2025-03-04 12:14:11 <sam_> telmich: thanks for the update!
2025-03-04 13:47:21 <fossdd[m]> hey another ping if someone could merge !80874?
2025-03-04 13:48:23 <fossdd[m]> i broke a lot of users on stable 😅
2025-03-04 13:51:28 <vkrishn> congrats! 
2025-03-04 16:20:49 <fossdd[m]> ncopa: thank you very much! much appreciated!
2025-03-04 21:05:53 <ptrc> fwiw,  
2025-03-04 21:06:58 <ptrc> damn it, ansi keyboards; anyway: the firefox 126 update is blocked on latest ICU, unless we stop using the system version of it ( but i'd rather not.. )
2025-03-04 21:07:26 <ikke> I suppose you mean 136?
2025-03-04 21:07:29 <ptrc> yes
2025-03-04 21:09:14 <ptrc> one thing that slightly bothers me is that giving up on system libraries when it becomes annoying to use them - like here - could set a dangerous precedent
2025-03-04 21:09:23 <ikke> yup
2025-03-04 21:12:43 <ikke> What is holding ICU up?
2025-03-04 21:18:59 <ptrc> mostly the sheer amount of rebuilds needed
2025-03-04 21:19:26 <ptrc> especially with stuff like chromium
2025-03-04 21:20:53 <ikke> yeah, was afraid of that
2025-03-04 21:21:29 <ikke> Those version constraints are so anoying
2025-03-04 22:26:27 <sertonix[m]> I stopped using system icu for librewolf due to a fingerprinting issue and it didn't seem to take much longer. But generally I prefer using system libraries.
2025-03-04 23:56:29 <jvvv> playing around with more updated ltrace. very nice. pulls function defs from dwarf data.
2025-03-05 00:26:45 <craftyguy[m]> sertonix: I'm not quite sure how to implemnet what you suggested in the coreutils MR in a way that's simpler than what I already have. seems like I'd still have to loop over files in $pkgdir/bin, etc. do you have any hints?
2025-03-05 00:27:55 <craftyguy[m]> I'll keep trying to golf it
2025-03-05 09:13:33 <qaqland> i create an issue to record the progress #16961
2025-03-05 09:14:01 <qaqland> is it legal to directly drop it from community?
2025-03-05 09:35:57 <sertonix[m]> As long as no package depends on the package or any subpackage this is fine.
2025-03-05 11:07:29 <WhyNotHugo> Can somebody merge !79075 and !80277?
2025-03-05 16:26:14 <fabricionaweb> I cant resolve my comment on a MR why
2025-03-05 16:34:30 <ikke> fabricionaweb: no clue, what MR?
2025-03-05 16:34:46 <fabricionaweb> !80914
2025-03-05 16:35:34 <fabricionaweb> I think I added it as thread/commen and not review? I dont remember it was like that 
2025-03-05 16:37:04 <ikke> Probably only the author and users with the developer role can resolve it
2025-03-05 16:37:06 <ikke> not entirely sure
2025-03-05 16:41:53 <eletrotupi> any specific reason why the prometheus apk was pinned on a specific version/marked as LTS?
2025-03-05 16:42:25 <eletrotupi> i'm also having so much issues trying to fetch the comments on my mr
2025-03-05 17:48:03 <craftyguy[m]> I would appreciate more reviews (or merging) this one if someone has a bit of time, thanks! !80719
2025-03-05 17:58:31 <caleb_m> can't wait to try this tbh
2025-03-05 18:01:05 <eletrotupi> oh, i've never heard of this one
2025-03-05 18:01:14 <eletrotupi> but the cosmos have a face apparently: https://canto.eletrotupi.com/6ykOt.png
2025-03-05 20:30:34 <bl4ckb0ne> ty for the merge sweep ikke 
2025-03-05 20:30:41 <ikke> np
2025-03-05 20:40:50 <bl4ckb0ne> would it help for review if I cut !71645 into individual MRs ? 
2025-03-06 02:07:18 <Saijin_Naib[m]> Cosmic would be interesting for sure! Exciting! Cinnamon was too hard for me 🤣
2025-03-06 02:13:09 <qaqland> https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-user.in#L170
2025-03-06 02:14:16 <qaqland> doas itself set doas.d 750, but mkdir here override that to 755(i guess)
2025-03-06 02:45:57 <craftyguy[m]> Saijin_Naib: hopefully it can be merged soon 😅🤞
2025-03-06 04:19:53 <Saijin_Naib[m]> I am really excited to see it land. not sure I can adjust to a true TWM, but it is still something that will make Alpine more attractive to more folks for sure
2025-03-06 05:37:33 <jvvv> what is a true TWM? true Tab Window Manager? oh, maybe you mean tiling wm?
2025-03-06 09:17:13 <WhyNotHugo> For librespite (!80924), upstream would prefer if we build with the optional v8 support
2025-03-06 09:17:43 <WhyNotHugo> We don't seem to have a v8 package, is there a reason for this? I guess that chromium does use v8, but it's built as part of the same aport?
2025-03-06 12:50:55 <fossdd[m]> does abuild rootbld with with apk v3 for you?
2025-03-06 12:51:10 <fossdd[m]> im not sure if its related to my environment or if its actually apk/abuild's fault
2025-03-06 13:00:24 <sertonix[m]> apk3 inside of the chroot or outside?
2025-03-06 13:01:25 <fossdd[m]> outside
2025-03-06 13:08:21 <sertonix[m]> When the package cache isn't enabled it is broken. Is that the issue you get?
2025-03-06 13:08:41 <fossdd[m]> ah yes thats it
2025-03-06 16:32:04 <ncopa> ptrc: are you actively working on the ICU 76 upgrade? I have fixed a few of the builds locally
2025-03-06 16:54:04 <kpcyrd> are there any preferences on `--data-path ...` vs `export DATA_PATH=...` in openrc scripts?
2025-03-06 16:54:37 <kpcyrd> ah, maybe this belongs in .confd anyway
2025-03-06 18:01:27 <ptrc> ncopa: nope, i've put it away for now
2025-03-06 18:01:46 <ikke> We need to figure out how to get gst-plugins-bad compiling again
2025-03-06 22:03:31 <Ariadne> ikke: its an underlinking issue
2025-03-06 22:03:49 <Ariadne> one hackfix could be to force linking against `-lglib-2.0` by modifying LIBS
2025-03-06 22:10:05 <Ariadne> found the issue
2025-03-06 22:20:06 <Ariadne> cutting new pkgconf release, it was a regression in pkgconf's solver that bubbled up when we simplified a lot of stuff in 2.3.0
2025-03-06 22:23:32 <ptrc> yeeah, i made a hacky workaround by just including the deps manually; is that a pkgconf issue or a gstreamer issue?
2025-03-06 22:23:48 <ptrc> ( https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/80346#note_487594 )
2025-03-06 22:23:49 <Ariadne> it is a pkgconf issue, it is overoptimizing glib out of the solution
2025-03-06 22:24:25 <Ariadne> or more specifically: the flattener is not even getting glib as an input, because glib never gets collected as a dep node
2025-03-06 22:25:50 <Ariadne> https://github.com/pkgconf/pkgconf/commit/8b3dd835aee113ede402e98a502a0e9f1b7b1132
2025-03-06 22:28:10 <ptrc> yup, that fixes the issue ^^
2025-03-06 22:28:26 <ptrc> is there gonna be a new release or should we just backport that to alpine as a patch
2025-03-06 22:31:10 <Ariadne> 2.4.1 is out
2025-03-06 22:32:18 <Ariadne> the gst-plugins-bad change should be reverted
2025-03-06 22:37:21 <ptrc> done
2025-03-07 04:58:39 <bsbs83[m]> 𝐌𝐄𝐒𝐒𝐀𝐆𝐄  BlackHat_Nexus 𝐅𝐎𝐑 𝐀𝐍𝐘 𝐊𝐈𝐍𝐃 𝐎𝐅 𝐒𝐄𝐑𝐕𝐈𝐂𝐄 𝐑𝐄𝐂𝐎𝐕𝐄𝐑 𝐘𝐎𝐔𝐑 𝐀𝐂𝐂𝐎𝐔𝐍𝐓... (full message at <https://matrix.org/oftc/media/v1/media/download/AUdpxsuBfQjzGV6N3-bhc2bh0GGsDaXnyCAn4HkE71-tcNm_YQi9D_lNGU-jKrCvKv9k5d9KOA5CFtIUV8mi1A9CeVtxFMPAAG1hdHJpeC5vcmcvSUdzcEdqakhhSkVUTW93TUVmbHNnZ3pM>)
2025-03-07 10:10:22 <qaqland> 2eeb5ba01a0e5c2f3e6e96020d0fb91c198c6b7c this commit message...
2025-03-07 10:23:04 <fabricionaweb> I had the impression that the maintainer (and dev) doesnt cared much about the aport, shall I ask (more explicitly) to review the MR? !80525
2025-03-07 10:25:55 <pj> since the maintainer field wasn't accepted yet, it should be reverted
2025-03-07 10:26:54 <fossdd[m]> <qaqland> "2eeb5ba01a0e5c2f3e6e96020d0fb91c..." <- what about it?
2025-03-07 10:27:07 <fossdd[m]> pj: its fine to already add it i think, but its not mandatory
2025-03-07 10:30:44 <fabricionaweb> I have been progressive moving to, I think I had asked here some time ago
2025-03-07 10:37:26 <qaqland> fossdd[m]: sorry to comment but this commit message can be squashed
2025-03-07 10:38:31 <fossdd[m]> i think (as also explained in COMMITSTYLE.md) commits can(/should) be seperated in logical changes. its not always possible and doesnt make much sense, but generally i think thats best practise
2025-03-07 10:38:58 <fossdd[m]> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/COMMITSTYLE.md#organizing
2025-03-07 13:21:34 <ncopa> Ariadne: I think I have a deadlock in pkg-config
2025-03-07 13:22:49 <ncopa> happens when building libreoffice
2025-03-07 13:22:59 <ncopa> checking for libexecinfo...
2025-03-07 14:09:12 <ncopa> cat /usr/lib/pkgconfig/libclucene-core.pc
2025-03-07 14:09:29 <ncopa> as a ~ at the end which probably shouldnt be there
2025-03-07 14:12:12 <sam_> https://github.com/pkgconf/pkgconf/issues/384
2025-03-07 14:12:32 <sam_> see also the comments from dg0yt where there's another issue (I think) that I can't reproduce but some of our users could
2025-03-07 14:34:44 <ncopa> thats the one I have
2025-03-07 14:51:36 <navi> i've noticed that openrc's APKBUILD sets prefix, bindir, and sbindir to /, /bin, /sbin -- if the intention is to make it functional without /usr, --libdir and --libexecdir probably should also be set to /lib64 and /lib respectively
2025-03-07 14:52:13 <navi> (well, libdir should be arch-specific lib dir)
2025-03-07 14:57:53 <ikke> We don't have /lib64 (musl does not support multi-arch)
2025-03-07 15:00:02 <navi> then /lib, all i meant to say is currently the package is relying in files from /usr
2025-03-07 15:01:02 <navi>  /bin and /sbin makes sense in both split and merged usr, prefix to / less so which is why i ask
2025-03-07 15:01:08 <navi> just, wanting to be sure
2025-03-07 15:48:41 <craftyguy[m]> ncopa: would you mind taking a look at !80862 ? It fixes coreutils packaging so it's compatible with migrating to a merged /usr layout, while still using relative symlinks to coreutils as we discussed a while back
2025-03-07 16:09:55 <dalias> i know what you mean but "does not support multi-arch" is a poor characterization
2025-03-07 16:10:34 <dalias> we do support full multi-arch just not partly mixing related 32- and 64-bit archs using a "lib64" layout
2025-03-07 16:24:49 <ncopa> craftyguy[m]: done
2025-03-07 16:25:27 <craftyguy[m]> ncopa: thank you!
2025-03-07 17:48:08 <craftyguy[m]> anyone brave enough to merge !80719 ? :P (or tell me what else this is waiting on heh)
2025-03-07 18:23:03 <Ariadne> ncopa: i think 2.4.2 (pending) will fix it
2025-03-07 18:58:53 <Ariadne> ikke: /lib64 is multilib (you could hack it to work, I think, but why...?), /usr/$triplet/lib is multiarch (which is supported by musl)
2025-03-07 18:59:13 <ikke> Ariadne: ok, good to know
2025-03-07 22:22:09 <craftyguy[m]> welp... !81017
2025-03-07 23:44:36 <invoked> fossdd[m]: nmeum: there's a river-0.3.8 now, but needs zig-0.14.0 ... i can help.
2025-03-08 09:32:02 <caskd> Would nlplug-findfs unlock every luks device in a attempt to get a lvm vg ready?
2025-03-08 09:33:09 <caskd> I am considering to do lvm on luks and not the other way around to encrypt the drives and i was wondering if it would even attempt that.
2025-03-08 09:33:55 <caskd> Ommitting the LABEL/UUID searches, as those cause issues when rimage_0 is present, as it matches 
2025-03-08 11:44:03 <maxwel3844[m]> 𝐌𝐄𝐒𝐒𝐀𝐆𝐄  BlackHat_Nexus 𝐅𝐎𝐑 𝐀𝐍𝐘 𝐊𝐈𝐍𝐃 𝐎𝐅 𝐒𝐄𝐑𝐕𝐈𝐂𝐄 𝐑𝐄𝐂𝐎𝐕𝐄𝐑 𝐘𝐎𝐔𝐑 𝐀𝐂𝐂𝐎𝐔𝐍𝐓... (full message at <https://matrix.org/oftc/media/v1/media/download/ASB59Jw488L0XDbzd6O58uPE9SI9TERq-8lyh1irfrMapNflVS1ufJkQM_22PfSCEKYavYdtzTbIMNNYCmMPvzJCeVvarSWAAG1hdHJpeC5vcmcvSmVLWE9teFhtYk1SRWVwVGJISEZzV1FC>)
2025-03-08 12:21:59 <skarnet> use the fs, luks
2025-03-08 14:35:15 <donoban> alpine-baselayout-data-3.6.8-r1: installing file to etc/group.apk-new , is there some way for ignore this kind of files?
2025-03-08 14:42:07 <fossdd[m]> what do you mean?
2025-03-08 14:42:12 <fossdd[m]> the warning?
2025-03-08 14:42:21 <donoban> the creation of group.apk-new
2025-03-08 14:42:41 <fossdd[m]> its always been the case, since its been modified since the last time apk touched it, e.g. by a new group :p
2025-03-08 14:43:28 <donoban> yeah but i think that it would be nice to have some mechanism for ignore some of them, they add noisy for parsing the "important" new different conf files
2025-03-08 14:43:48 <donoban> /etc/hostname :)
2025-03-08 14:44:11 <fossdd[m]> they can be just as important, i think the best way is to regulary run update-conf and clean stuff up
2025-03-08 14:44:41 <fossdd[m]> but this issue is probably more apparopriate at #apk-tools or in apk's issue tracker
2025-03-08 14:46:23 <donoban> yeah I suppose that it would add complxity on apk for few benefit
2025-03-08 14:46:36 <donoban> maybe it's easy to tweak on "update-conf"
2025-03-08 14:46:53 <donoban> have a list of files where it always do the same action
2025-03-08 14:54:26 <donoban> fossdd[m]: could you check if there is something missing on !80404 ?
2025-03-08 14:55:07 <donoban> altought just today I discovered a bug :D, maybe better to wait for a fix or workaround
2025-03-08 19:33:40 <user0> hello
2025-03-08 19:34:05 <user0> I think this is the right place to ask: could someone test https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/81035?
2025-03-08 22:51:30 <craftyguy[m]> Could someone please merge !80719, or explain what else needs to be done before it's mergeable?
2025-03-08 22:51:58 <craftyguy[m]> Hmm where'd the bot go
2025-03-09 00:03:39 <craftyguy[m]> ptrc: thank you :)
2025-03-09 00:57:52 <ptrc> yw ^^
2025-03-09 02:37:30 <lotheac> could someone also merge !78944 and !78838
2025-03-09 05:06:21 <Saijin_Naib[m]> If I would like a change in a package in main (libwebp), is it best to make an Issue or make the MR with my changes?
2025-03-09 05:10:07 <Saijin_Naib[m]> At the very least, tiff-dev can be added to enable tiff image input support, it no longer causes a circular dependency issue
2025-03-09 05:10:40 <Saijin_Naib[m]> That would personally help me out a lot as I am using WebP to archive/optimize my entire image library which is a few hundred GBs pre-WebPing
2025-03-09 06:33:12 <craftyguy[m]> I think a patch would be best, if you're able to make/submit one
2025-03-09 06:33:34 <craftyguy[m]> Saijin_Naib ^
2025-03-09 06:36:34 <Saijin_Naib[m]> Yeah, I can. Just wary since the last time I wanted to change a package in main my changes had undesired effects, haha
2025-03-09 14:31:18 <janvhs> What is the requirement for things in testing to be promoted to community? I found turnstile in testing and I’m trying to make it run without erroring out right now.
2025-03-09 14:31:52 <pj> maintainer has to deem it working and somewhat stable
2025-03-09 14:40:15 <janvhs> Thank you. Does things like code quality get taken into account as well?
2025-03-09 14:41:53 <pj> it's only a package manifest, there isn't any code
2025-03-09 14:44:29 <janvhs> Sure, but for things to get into Alpine, doesn’t someone look at what’s actually distributed?
2025-03-09 14:44:59 <pj> some might do
2025-03-09 14:45:37 <pj> but if that was a barrier of entry, then stuff like nodejs should probably be thrown out
2025-03-09 14:48:01 <pj> anyway it's up to ptrc to move it to community if it's fine by her
2025-03-09 14:48:53 <janvhs> pj: Alrighty, thanks for the insight ^^
2025-03-09 14:50:10 <pj> i mean, in this particular case it's q66's code so it's most likely more than fine in terms of quality
2025-03-09 14:50:24 <pj> but not everyone has time or cares enough to code review every project
2025-03-09 14:51:13 <pj> it's mostly that when trying to build, something weird pops up and gets taken care of
2025-03-09 14:56:50 <marigi[m]> Привіт усім українцям.... (full message at <https://matrix.org/oftc/media/v1/media/download/Acdyje01K1mpg4ss9tdHyiYQNOGZEABWkSKJpH1YyLaUr5Ds52sT39FuOYOyXjHnE7ZA9oMtTgUXUFIL0-tKivZCeVw4Gr_AAG1hdHJpeC5vcmcvekNKTFRJSnpoa0l3TURvQWVZTmVkSGFx>)
2025-03-09 15:13:51 <realroot[m]> Hi can you see me?
2025-03-09 15:15:29 <invoked> you are seen. step forward and speak the blood oath
2025-03-09 15:16:39 <realroot[m]> I wonder if maybe someone  can do something to add custom script in the boot process as pmOS did. https://gitlab.alpinelinux.org/alpine/mkinitfs/-/issues/18
2025-03-09 15:18:44 <realroot[m]> this one has them IIUC https://github.com/illiliti/tinyramfs
2025-03-09 15:23:58 <invoked> that tinyramfs is neat.
2025-03-09 15:28:40 <janvhs> Tinyramfs is used by https://os.ewe.moe as well. I enjoy using mkinitcpio from Arch, too.
2025-03-09 15:50:24 <vkrishn> saw this, !79319, and was wondering if there is any clear set of rules how things move in testing when merged? or even while merging new ones?
2025-03-09 15:50:34 <vkrishn> pkgdesc="Pre-pre-pre-alpha experimental prototype work in progress. Nothing to see here!", very nice
2025-03-09 15:51:59 <vkrishn> if ok, do i start a issue in TSC(RFC)?
2025-03-09 15:53:22 <vkrishn> i have things on testing/ brewing for a while
2025-03-09 15:55:28 <ikke> https://gitlab.alpinelinux.org/alpine/aports/#testing
2025-03-09 16:12:09 <vkrishn> not opening
2025-03-09 16:13:54 <craftyguy[m]> Works fine for me
2025-03-09 16:14:30 <vkrishn> yes, ok, now
2025-03-09 16:14:41 <vkrishn> this is general part, read it before,
2025-03-09 16:15:14 <vkrishn> i am refering to cycle on input to merge to request for bumping next versions for pkgs in testing/
2025-03-09 16:15:16 <fabricionaweb> bot is 🛌
2025-03-09 16:16:11 <vkrishn> ikke: tsc issue or aports issue?
2025-03-09 16:16:36 <craftyguy[m]> 
ACTION has no clue what you are actually asking about

2025-03-09 16:17:18 <vkrishn> make an issue in TSC or aports in gitlab.a.o
2025-03-09 16:17:24 <craftyguy[m]> make a MR to move a package from testing to community, no gitlab issue needed
2025-03-09 16:18:21 <vkrishn> ok, will do in TSC, you can read it later
2025-03-09 16:19:36 <craftyguy[m]> You don't need to make a tsc issue to move a pkg from teating to community...
2025-03-09 16:20:11 <craftyguy[m]> The process for moving is in the link that Kevin posted above. It's actually quite simple/straight forward 🤷‍♂️
2025-03-09 16:21:33 <vkrishn> craftyguy[m]: you can thumbs down after reading, when done
2025-03-09 16:22:55 <craftyguy[m]> are you proposing some new process for that or ? I'm still not entirely sure what you are getting at 😉
2025-03-09 16:24:56 <vkrishn> does testing section here mention method of bumping versions, https://git.alpinelinux.org/aports/about/
2025-03-09 16:25:06 <vkrishn> or rules on it
2025-03-09 16:25:58 <vkrishn> yes, why are you opposing something that has not be done yet :)))
2025-03-09 16:26:44 <craftyguy[m]> I'm not opposing anything, just asking
2025-03-09 16:26:44 <vkrishn> i said i will put in TSC, you can participate there
2025-03-09 16:27:00 <vkrishn> clear here?
2025-03-09 16:27:14 <craftyguy[m]> seems like the apkbuild reference page would have guidance on when to bump pkgver and stuff: https://wiki.alpinelinux.org/wiki/APKBUILD_Reference
2025-03-09 16:27:23 <craftyguy[m]> clear as mud 😉
2025-03-09 16:27:41 <vkrishn> yes, mr abuser
2025-03-09 16:28:16 <vkrishn> respect is quid-pro-quo
2025-03-09 16:28:20 <ikke> https://wiki.alpinelinux.org/wiki/Repositories
2025-03-09 16:29:50 <craftyguy[m]> "mr abuser", me? /me confused
2025-03-09 16:31:18 <vkrishn> ikke: do i have enough previlege to add an issue in TSC?
2025-03-09 16:32:11 <vkrishn> craftyguy[m]: pls stop, u can say on the gitlab issue
2025-03-09 16:32:25 <ikke> vkrishn: anyone should be able to open an issue
2025-03-09 16:33:08 <vkrishn> thanks
2025-03-09 16:49:59 <funderscore> algitbot: you ok?
2025-03-09 16:53:27 <vkrishn> algitbot: here take two of these s/overload/pat{2}/ and call me in the morning
2025-03-09 16:58:51 <vkrishn> any one what is this system76, is it manufacturer for special devices?
2025-03-09 16:59:15 <pj> https://en.wikipedia.org/wiki/System76
2025-03-09 16:59:58 <vkrishn> have they offered free devices to AL for testing, seems we now building their lovely DE
2025-03-09 17:00:48 <invoked> i'm not sure that's how that works
2025-03-09 17:00:53 <craftyguy[m]> I packaged it in Alpine because folks (including me) are interested in running it
2025-03-09 17:01:27 <invoked> what little i read is they built it to be a whitelabel de, so you slap your own branding all over it
2025-03-09 17:01:49 <pj> vkrish: why would they offer any hardware and for what purpose
2025-03-09 17:02:09 <pj> cosmic desktop is general purpose DE that should work on any linux
2025-03-09 17:02:35 <vkrishn> they are well funded, should as token of appreciation
2025-03-09 17:02:43 <pj> for wha
2025-03-09 17:03:32 <pj> appreciation that someone is compiling the software? that is open source?
2025-03-09 17:03:35 <vkrishn> testing, coz i read somewhere on their site its special crafted device for their own org
2025-03-09 17:03:38 <craftyguy[m]> no one at system76 asked us to do anything. Will this also be answered in your TSC issue?
2025-03-09 17:04:16 <vkrishn> craftyguy[m]: you now annoyed, fighting like a kid
2025-03-09 17:04:27 <pj> it's special crafted for their own vision because they are the ones making it
2025-03-09 17:04:57 <pj> no one in alpine is specifically testing it for them
2025-03-09 17:05:08 <vkrishn> ah! thanks, so a device that needs no extra testing
2025-03-09 17:05:25 <pj> if they are, I don't see why alpine should benefit from it financially
2025-03-09 17:05:34 <pj> I have no idea why you keep talking about devices
2025-03-09 17:05:40 <pj> this is software
2025-03-09 17:05:41 <vkrishn> i am willing to test, if they send it to me :)
2025-03-09 17:05:54 <pj> please stop
2025-03-09 17:20:30 <vkrishn> "this is software", does not need testing?
2025-03-09 17:22:52 <vkrishn> invoked: thanks
2025-03-09 17:25:50 <craftyguy[m]> Companies shouldn't be expected to give away hardware because people in the community unrelated to the company decided to package software that the company distributes.
2025-03-09 17:29:05 <pj> I'm hungry, so if you want me to entertain you and your trolling, pay me
2025-03-09 17:29:17 <pj> otherwise I'm going to eat something
2025-03-09 18:01:13 <fabricionaweb> I think py3-qt6 failed on armhf how can I check the log
2025-03-09 18:01:52 <ikke> https://build.alpinelinux.org/buildlogs/build-edge-armhf/community/py3-qt6/
2025-03-09 18:03:30 <fabricionaweb> hm weird its there but pipeline is complaing
2025-03-09 18:09:18 <fabricionaweb> it is the qt6-qtmultimedia actually
2025-03-09 19:03:34 <Saijin_Naib[m]> !81074 is ready for review/comments as I know tweaking stuff in main needs careful consideration
2025-03-09 19:03:50 <Saijin_Naib[m]> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/81074
2025-03-09 19:04:00 <Saijin_Naib[m]> main/libwebp: enable TIFF input support
2025-03-09 19:04:28 <Saijin_Naib[m]> Would, personally, be a huge UX improvement for me and greatly appreciated
2025-03-09 19:18:11 <ikke> Saijin_Naib[m]: ncopa will need to handle that MR
2025-03-09 19:18:30 <ikke> Saijin_Naib[m]: You forgot to bump `pkgrel`
2025-03-09 19:18:40 <Saijin_Naib[m]> Of course I did. haha
2025-03-09 19:18:44 <Saijin_Naib[m]> Thank you, as ever
2025-03-09 19:20:03 <Saijin_Naib[m]> fixup and rebase, thanks ikke
2025-03-09 19:40:13 <Saijin_Naib[m]> ikke, will GitLab auto-assign ncopa? I can't assign anyone or tag anything
2025-03-09 19:40:35 <ikke> Yes, he already is assigned
2025-03-09 19:40:50 <Saijin_Naib[m]> Ah, okay, cool.
2025-03-09 19:41:01 <ikke> > aports-qa-bot assigned to @ncopa 15 minutes ago
2025-03-09 21:52:49 <craftyguy[m]> Is some chromium build failure clogging up the alpine builders? (I'm not totally sure how to interpret build.alpinelinux.org)
2025-03-09 21:54:37 <ikke> yes
2025-03-09 21:54:48 <ikke> some pipewire incompattibility
2025-03-09 21:55:11 <ikke> and pipewire is holding up rv64
2025-03-09 21:59:53 <craftyguy[m]> ahhh ok
2025-03-09 22:00:05 <psykose> jeez the `scanelf: ar: invalid number: -1` spam
2025-03-09 22:00:35 <ikke> nod
2025-03-09 22:00:38 <ikke> due to some test file
2025-03-09 22:00:47 <ikke> that on purpose is invalid
2025-03-09 22:02:23 <fossdd[m]> re pipewire rv64: not sure if the SIGILL test fail actually represents the binaries or if the builder hardware cant run them
2025-03-09 22:02:56 <fossdd[m]> on what hardware is the riscv64 builder running again?
2025-03-09 22:03:54 <ikke> milkv pioneer
2025-03-09 22:05:19 <fossdd[m]> i believe https://webrtc-review.googlesource.com/c/src/+/380500 fixes the chromium build
2025-03-09 22:05:20 <fossdd[m]> ill try backporting it
2025-03-09 22:08:03 <psykose> the pipewire thing is confusing tbh
2025-03-09 22:08:29 <fossdd[m]> yes
2025-03-09 22:08:35 <psykose> last we checked the kernels were booted with the thing that hides rvv, and pipewire does the standard getauxval hwcap + hwcap_rv('v')
2025-03-09 22:08:39 <psykose> and it returns true for some reason :^)
2025-03-09 22:08:55 <psykose> it should be false
2025-03-09 22:09:00 <fossdd[m]> oh great
2025-03-09 22:09:58 <fossdd[m]> downloading the chromium source takes longer than actually doing the backport,,,
2025-03-09 22:10:24 <ikke> wait until you get to extract the source :p
2025-03-09 22:10:52 <psykose> the rv builder kernel is booted with hide_v0p7_ext rite
2025-03-09 22:11:16 <ikke> how to check?
2025-03-09 22:11:27 <psykose> /proc/cmdline
2025-03-09 22:12:43 <ikke> hmm, not the edge builder host
2025-03-09 22:13:00 <psykose> :)
2025-03-09 22:13:02 <psykose> well gotta set it
2025-03-09 22:13:21 <ikke> carlo is out-of-office for a while
2025-03-09 22:27:25 <fossdd[m]> im not sure if i should run the ci for the chromium patch or if somebody just wants to merge it
2025-03-09 22:31:45 <fossdd[m]> !81083
2025-03-09 22:38:19 <user0> where's algitbot?
2025-03-09 22:38:45 <psykose> vacation
2025-03-09 22:38:49 <user0> ah ok
2025-03-09 22:39:00 <user0> algitbot: enjoy the vacation
2025-03-09 22:39:08 <user0> :D
2025-03-09 22:46:25 <vkrishn> here, sneak preview/skel to whats brewing, https://tpaste.us/doWL , nothing personal
2025-03-09 22:46:46 <vkrishn> simple rules
2025-03-09 22:47:53 <vkrishn> pls do not comment and ask on it
2025-03-09 22:48:12 <psykose> this adds 1 rule?
2025-03-09 22:51:25 <vkrishn> oh, you commented ;)
2025-03-09 22:52:13 <psykose> obviously? posting a bunch of text and saying "dont comment on it" is trolling
2025-03-09 22:53:36 <vkrishn> you probably need to read some lines before, wanna get you lines from logs?
2025-03-09 22:53:55 <vkrishn> psykose: why do you hate alpinelinux?
2025-03-09 22:54:03 <vkrishn> and me
2025-03-09 22:54:09 <lotheac> what.
2025-03-09 22:54:11 <fossdd[m]> ?????
2025-03-09 22:54:18 <fossdd[m]> where do you get that from?
2025-03-09 22:54:31 <vkrishn> ask psykose 
2025-03-09 22:54:43 <vkrishn> am i trolling?
2025-03-09 22:54:51 <lotheac> yes
2025-03-09 22:54:58 <vkrishn> how?
2025-03-09 22:55:11 <lotheac> good chance to reflect on that
2025-03-09 22:57:49 <fabricionaweb> I will pretend this never happened
2025-03-09 23:00:22 <ptrc> why post something and then say "do not comment on it"
2025-03-09 23:01:37 <skarnet> I love you all. I will not elaborate. Please don't comment on this message.
2025-03-09 23:01:47 <psykose> https://img.ayaya.dev/qd7BIJ7Y4swX
2025-03-09 23:02:05 <Ermine> haters gonna hate!
2025-03-09 23:02:46 <abby> shake it off
2025-03-09 23:03:11 <skarnet> psykose: "it's not discrimination, I hate everyone equally!"
2025-03-09 23:03:16 <psykose> :)
2025-03-09 23:03:25 <psykose> gnite chat
2025-03-09 23:03:27 <psykose> keep it trolling
2025-03-09 23:03:53 <fabricionaweb> Gn, I love you, ty for all
2025-03-09 23:04:48 <Ermine> skarnet: Sergeant Hartman's philosophy
2025-03-09 23:05:26 <skarnet> also Type O Negative's
2025-03-09 23:06:22 <vkrishn> that's is indiscriminate use of someones image without prior permission
2025-03-09 23:06:41 <vkrishn> as a friend, be careful next time
2025-03-09 23:14:30 <pj> as an enemy, I pray for your downfall
2025-03-09 23:16:17 <ptrc> as a frenemy, ERROR: Failed to open apk database: Invalid argument
2025-03-09 23:19:14 <abby> you're friends with Giancarlo Esposito?
2025-03-10 03:11:56 <BILL_GATES_SUCKS_C0CK>  
2025-03-10 07:49:27 <clandmeter> psykose: it should be set now
2025-03-10 07:49:33 <psykose> nice :)
2025-03-10 07:49:34 <clandmeter> its rebooting
2025-03-10 07:49:41 <psykose> hopefully that fixes it
2025-03-10 07:49:52 <clandmeter> not sure why it was missing
2025-03-10 07:55:58 <psykose> still fails
2025-03-10 07:55:58 <psykose> weird
2025-03-10 07:56:09 <psykose> which kernel is it
2025-03-10 07:56:13 <psykose> in uname -a
2025-03-10 08:05:14 <clandmeter> try again, i forgot to run update-grub :)
2025-03-10 08:10:52 <psykose> now it worked :)
2025-03-10 08:11:14 <qaqland> !80866 i feel like this port is a bit strange..
2025-03-10 13:37:13 <eletrotupi> !80666 can someone take a look at this fella? 
2025-03-10 13:39:31 <eletrotupi> oh, algitbot is still vacationing in the alps? 
2025-03-10 13:55:56 <fabricionaweb> dont you want take the over the maintainer eletrotupi?
2025-03-10 13:56:15 <user0> eletrotupi: yes algitbot is still in the alps
2025-03-10 15:07:38 <eletrotupi> fabricionaweb: i did 
2025-03-10 15:07:45 <eletrotupi> didn't i?
2025-03-10 15:08:17 <eletrotupi> hm, apparently i haven't
2025-03-10 16:04:51 <funderscore> I hope algitbot is having a great time in the alps
2025-03-10 16:10:44 <craftyguy[m]> Oh nice, fossdd figured out the chromium build failure thing blocking the builders... !81083
2025-03-10 16:21:49 <kpcyrd> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/80492 would be nice for RUSTSEC-2024-0436 (it's not a security update in itself, but helps deal with that advisory)
2025-03-10 16:23:51 <ikke> !81083
2025-03-10 16:25:51 <craftyguy[m]> yay welcome back algibot
2025-03-10 16:28:55 <funderscore> \o/
2025-03-10 16:29:10 <funderscore> hey welcome back algitbot I hope you had a great time in the alps :)
2025-03-10 16:31:37 <vkrishn> craftyguy[m], psykose , i have put the full text here, https://gitlab.alpinelinux.org/alpine/tsc/-/issues/93, pls feel free to comment
2025-03-10 16:32:10 <vkrishn> sorry for posting the draft earlier on IRC
2025-03-10 16:32:17 <vkrishn> gtg, thanks
2025-03-10 16:33:05 <psykose> marvellous piece of prose
2025-03-10 17:20:23 <invoked> in the case of tsc#2 (or, well, any rule) it would be implemented/enforced/constrained by gitlab
2025-03-10 17:20:54 <invoked> not like ... i pinky-swear to not flake on my packages
2025-03-10 17:24:21 <pj> if someone implements it in gitlab then yes
2025-03-10 17:32:31 <psykose> like 99.9999% of the rules are pinky swears
2025-03-10 17:45:38 <craftyguy[m]> Do the builders need to be poked somehow to get them to pick up the latest chromium patch?
2025-03-10 17:47:00 <pj> it failed to build with pipewire fix?
2025-03-10 17:47:36 <craftyguy[m]> Hmm it did?
2025-03-10 17:48:20 <pj> on aarch64 at least
2025-03-10 17:48:21 <pj> https://build.alpinelinux.org/buildlogs/build-edge-aarch64/community/chromium/chromium-134.0.6998.35-r0.log
2025-03-10 17:48:51 <fossdd[m]> no it doesnt have patch applied
2025-03-10 17:49:01 <fossdd[m]> i suppose the failure is still from last cycle
2025-03-10 17:49:06 <pj> ah wait, i misread algitbot
2025-03-10 17:49:50 <pj> could probably kick it with retry master
2025-03-10 17:50:47 <pj> although according to build.al.o it might be uploading packages from previous builds me thinks
2025-03-10 17:52:22 <pj> sorry, my brain is currently stuck on build failure due to that tsc issue
2025-03-10 18:08:34 <eletrotupi> i've asked this a couple of days ago, but why is the prometheus package locked away with a # LTS comment on it? do we decided to not upgrade for a while?
2025-03-10 18:08:59 <eletrotupi> i know that the new version has major breaking changes, do alpine have a specific policy to handle these sorts of upgrades?
2025-03-10 18:10:55 <fossdd[m]> usually if the other releases are not as long as supported as we have to (for community 6 months afte a alpine release)
2025-03-10 18:14:25 <Saijin_Naib[m]> fossdd, thanks for the comment on my libwebp MR. I am not understanding how the circular dependency works, since I thought those stopped successful builds
2025-03-10 18:16:31 <eletrotupi> sure
2025-03-10 18:16:51 <eletrotupi> i'll figure it out how long will the support for version 2 remain from upstream
2025-03-10 18:17:19 <eletrotupi> i'll file a ticket when i have more information available
2025-03-10 18:17:22 <eletrotupi> thanks Forza 
2025-03-10 18:17:35 <eletrotupi> oops, fossdd[m]
2025-03-10 18:27:48 <fossdd[m]> <Saijin_Naib[m]> "fossdd, thanks for the comment..." <- no youre only noticing it after bootstrapping alpine
2025-03-10 19:02:31 <ikke> Saijin_Naib[m]: when we bootstrap a new release, no packages are available. If both packages have a make / check dependency on eachother, neither package can be built
2025-03-10 19:02:53 <ikke> To build package A, you need package B, to build package B, you need package A
2025-03-10 19:23:58 <craftyguy[m]> pj: ya seems like the latest log is an attempt to build chromium without the patch that should fix it... I'm not sure how to retrigger the builder to try again from the latest in master
2025-03-10 19:24:28 <psykose> it was merely building it from ages ago
2025-03-10 19:24:40 <psykose> then the thing got merged, and then it failed
2025-03-10 20:21:06 <craftyguy[m]> yeah so how do we get it to retry?
2025-03-10 20:21:20 <ikke> it's already doing it
2025-03-10 20:21:31 <craftyguy[m]> ahhh ok, sorry, hadn't noticed :)
2025-03-10 20:21:40 <ikke> the last package mentioned on https://build.alpinelinux.org is the package being built right now
2025-03-10 20:44:38 <ikke> seems like electron needs the same patch
2025-03-10 20:53:15 <Saijin_Naib[m]> <ikke> "Saijin_Naib: when we bootstrap a..." <- Ahh, okay. So my MR is impossible to solve, then. Just close it? 
2025-03-10 21:07:20 <ikke> invoked: https://gitlab.alpinelinux.org/alpine/infra/aports-testing-ttl
2025-03-10 21:39:05 <invoked> ikke: nice. yeah, earlier, i neglected to say "ideally" ... my point was, it's (imo) somewhat pointless to add rules without some plan to tool around them
2025-03-10 21:39:21 <ikke> exactly, that's why clandmeter created that project
2025-03-10 21:51:36 <invoked> with this type of work, if gitlab can nag when stuff needs attention, then people can hopefully be less hypervigilant...
2025-03-10 21:52:28 <invoked> some people quit not because they don't have time, but that's a gross feeling to have all the time
2025-03-10 21:58:42 <dne> would someone like to merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/77609 after two months? ;-)
2025-03-10 21:58:56 <ikke> !77609
2025-03-10 21:59:37 <ikke> fluix: ping
2025-03-10 22:00:52 <dne> (last activity on gitlab was 3 months ago)
2025-03-10 22:04:34 <ikke> Ah, I see now in the irc history fluix gave green light to merge their packages 
2025-03-10 22:04:40 <ikke> they're busy atm
2025-03-10 22:05:53 <dne> thanks!
2025-03-11 07:04:12 <fluix> yep, still alive but busy. hoping to come back soon
2025-03-11 07:04:41 <fluix> ty to everyone still maintaining packages :)
2025-03-11 07:15:37 <jvvv> since apk-tools v2.14.9, apk update no longer fetches indexes from my local partial mirror unless i add --cache-max-age=-1
2025-03-11 07:19:10 <jvvv> well, also --cache-max-age=0 ... so far nothing else seems to work right
2025-03-11 07:26:54 <jvvv> hmmm, seems --cache-max-age=value, where value > -999999999999999999999999999 && value <= 0
2025-03-11 08:47:19 <ikke> fabled: ^
2025-03-11 09:06:39 <jvvv> maybe it's a problem on my mirror
2025-03-11 09:15:02 <fabled> APK copies the timestamp the server gives
2025-03-11 09:15:09 <fabled> Maybe time is in future?
2025-03-11 09:45:44 <z3ntu> ping for https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/78354
2025-03-11 09:46:10 <ikke> !78354
2025-03-11 09:47:12 <z3ntu> ikke: I think also !81068 only got half merged, you rebased it yesterday though ;)
2025-03-11 09:56:11 <jvvv> fabled: i'll look into that ... it's a distinct possiblity. thanks for the pointer.
2025-03-11 10:01:11 <jvvv> doesn't seem to be a time issue, but could be something with the http server. i've a few ideas to try, like different web server for starter
2025-03-11 12:01:38 <fossdd[m]> can someone merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/79209?
2025-03-11 12:01:46 <ikke> !79209
2025-03-11 17:24:07 <dalias> what gcc was musl 1.2.5-r1 built with?
2025-03-11 17:24:33 <dalias> fma.c seems to have been miscompiled and i'm trying to track down what gcc ver is buggy to see if we can repro it
2025-03-11 17:24:33 <psykose> in which branch
2025-03-11 17:24:42 <dalias> 3.20
2025-03-11 17:25:09 <dalias> but 3.21 seems to be buggy too per the list
2025-03-11 17:25:46 <psykose> 13.2.1_git20240309
2025-03-11 17:26:12 <dalias> hmm weird
2025-03-11 17:26:39 <dalias> when i compile musl myself with gcc version 13.2.1 20240309 (Alpine 13.2.1_git20240309)
2025-03-11 17:26:42 <dalias> it's fine
2025-03-11 17:26:58 <dalias> does alpine have some special CFLAGS making it into the musl build?
2025-03-11 17:28:27 <psykose> there's just -fstack-clash-protection -Wformat -Werror=format-security in the env
2025-03-11 17:29:13 <psykose> and -fno-plt i think
2025-03-11 17:29:16 <psykose> maybe that one would do it
2025-03-11 17:29:25 <psykose> only set on x86_64
2025-03-11 17:29:43 <psykose> can you reproduce by just adding -fno-plt
2025-03-11 17:29:45 <dalias> -fno-plt should not affect this
2025-03-11 17:29:57 <dalias> there is no external call here
2025-03-11 17:29:57 <psykose> nothing else then
2025-03-11 17:30:23 <dalias> what's happened is that it's folded line 56 and line 53 to the same code path
2025-03-11 17:30:33 <dalias> presumably deciding z==0 implies adding z is a no-op
2025-03-11 17:30:41 <dalias> which it's not because these are floats
2025-03-11 17:39:43 <dalias> see #musl: it was actually mismatched source, fixed in musl git last year
2025-03-11 17:39:55 <dalias> (i was pointing gdb to my current git source dir too, doh)
2025-03-11 17:53:09 <pc_magas> Hello I have this APKBUILD https://pastebin.com/yQwLAHG6 and I want to test it locally without needing to push my code upon github. Therefore I want to test it locally. my code resides in a folder instead ot a .tar.gz file.
2025-03-11 17:53:33 <pc_magas> How I can override the `source` on the fly in order to test my build locally?
2025-03-11 17:54:07 <pc_magas> what I want is to mate a test build locally before submitting this file upon alpine repository for publishing in alpine's repos.
2025-03-11 17:58:10 <ikke> pc_magas: symlink the tar.gz in src/
2025-03-11 17:58:35 <ikke> Though the name and sha512sums will still need to match
2025-03-11 17:59:11 <ikke> Or store / symlink it in /var/cache/distfiles
2025-03-11 17:59:27 <pc_magas> ikke: I do not have .tar.gz just a git project where both APKBUILD and my source code exists.
2025-03-11 18:00:17 <ikke> Then symlink that project in /src
2025-03-11 18:00:26 <ikke> as if it was extracted
2025-03-11 18:01:41 <pc_magas> What I was thinking is to make a script that creates a secondary APKBUILD and replaced the source and sha512sums with nessesary values.  Also what is the src full path that code should reside upon??
2025-03-11 18:03:54 <pc_magas> What I am asking is should a fixed structure exists in a similar fashion that rpm does???
2025-03-11 18:04:17 <ikke> No
2025-03-11 18:04:41 <ikke> It's not meant to combine the code and the build instructions in a single source
2025-03-11 18:06:01 <pc_magas> So I need to make a tar.gz first and define the path on it.
2025-03-11 18:06:11 <pc_magas> right?
2025-03-11 18:06:16 <ikke> It depends on what you want to achieve
2025-03-11 18:06:37 <pj> you could build it without making tarball, just make a symlink
2025-03-11 18:06:55 <pj> abuild can run specific phases so you can skip fetch/unpack
2025-03-11 18:07:43 <ikke> abuild deps prepare build check rootpkg
2025-03-11 18:08:55 <pc_magas> I have this project https://github.com/pc-magas/mkdotenv and I am trying to automate my release and version bumping procedure for both debian,. alpine and rpm releases. So far I have this APKBUILD https://github.com/pc-magas/mkdotenv/blob/master/alpinebuild/APKBUILD and I want try building my app in APK before submitting it to alpine repos Therefore, I want to test build my app fiurst locally and then make the nessasery APKBUILD for my Apine 
2025-03-11 18:08:55 <pc_magas> repos.
2025-03-11 18:10:24 <ikke> If you want a complete test, that would involve generating an archive and updating checksums
2025-03-11 18:11:36 <ikke> Otherwise, I'd go the symlink route, and run the other steps manually
2025-03-11 18:15:51 <pj> if you care about just building and are not afraid of containers then I would do something like: docker run -ti -v $(PWD):/app --workdir /app alpine:edge make
2025-03-11 18:16:15 <pj> (and have a makefile that install deps/builds the thing)
2025-03-11 18:17:00 <pj> might need 'apk add make ; make'
2025-03-11 18:35:16 <pc_magas> Already using docker: https://github.com/pc-magas/mkdotenv/blob/master/alpinebuild/runAlpine.sh
2025-03-11 18:36:00 <pc_magas> I want to replicate the steps that aports do without need to push upon github.
2025-03-11 18:40:28 <ikke> pc_magas: Part of what abuild does is fetching the source, verifying the checksum, and unpacking it. Without pushing to github and without modifying the APKBUILD, you need to skip those stips
2025-03-11 18:50:00 <pc_magas> ikke: How do I skip them??
2025-03-11 18:51:35 <ikke> pc_magas: Run the other steps explicitly: `abuild deps prepare build check rootpkg`
2025-03-11 18:51:59 <pc_magas> ikke: Thanks
2025-03-11 18:54:30 <pc_magas> Assumming that ABUILD resides /home/packager/ABUILD where should my source code exists in order to test my build though???
2025-03-11 18:55:43 <ikke> /home/packager/ABUILD/src/$pkgname-$pkgver/
2025-03-11 18:55:57 <ikke> Which can be a symlink
2025-03-11 18:57:15 <pc_magas> Good
2025-03-11 18:59:03 <eletrotupi> though, i must say, pc_magas 
2025-03-11 18:59:19 <eletrotupi> you can just push that code from the source repo to a branch
2025-03-11 18:59:27 <eletrotupi> and then update the apkbuild to grab from that branch instead
2025-03-11 18:59:38 <eletrotupi> https://docs.github.com/en/repositories/working-with-files/using-files/downloading-source-code-archives#source-code-archive-urls
2025-03-11 18:59:51 <eletrotupi> here's the URL ref table for grabbing an archive (i.e.: tar.gz)
2025-03-11 19:00:14 <pc_magas> eletrotupi: I want to test before pushing to a branch and fix any issues
2025-03-11 19:00:35 <psykose> pushing to branches doesn't cost anything and you can just delete them later though
2025-03-11 19:00:41 <eletrotupi> yeah, exactly
2025-03-11 19:00:56 <eletrotupi> you don't need to push to your dev/master/main branch
2025-03-11 19:01:07 <ikke> Also `git archive`
2025-03-11 19:01:18 <psykose> nothing stops you from making mytestbranch123 and pushing to it 99999999999 times and using a tarball of it
2025-03-11 19:01:21 <psykose> also git archive yea
2025-03-11 19:01:44 <eletrotupi> also, you probably want to actually test the software/whatever itself *before* actually think about packaging it
2025-03-11 19:02:28 <eletrotupi> so in the ideal scenario/order of things you want to make sure that the software/whatever is working properly, then just package it up/create an apkbuild for it
2025-03-11 19:02:38 <pc_magas> My release flow is develop -> test build dev, rpms, apks -> bump version -> release to Aports
2025-03-11 19:03:31 <pc_magas> And because I may make breaking changes I also need to fix my build procwedure for alpine as well.
2025-03-11 19:03:37 <eletrotupi> i mean, i would say that the real order of things is to decouple upstream from downstream, even if you are the only one actually packaging or whatever
2025-03-11 19:03:51 <eletrotupi> you software should work regardless of packaging etc etc
2025-03-11 19:04:06 <eletrotupi> but like others have mentioned, you can just pop a new branch 
2025-03-11 19:04:06 <pc_magas> But my build pilelines not.
2025-03-11 19:06:09 <psykose> make branch -> run tests and package steps -> fix x9999 to make it work -> squash everything and bump version -> put commit into actual branch and tag the version
2025-03-11 19:06:10 <psykose> works fine
2025-03-11 19:07:07 <eletrotupi> ^ that'll make your life 9999x easier 
2025-03-11 19:07:14 <eletrotupi> but ya know
2025-03-11 19:07:19 <eletrotupi> feel free to pick whatever path you want
2025-03-11 19:07:49 <psykose> in CI itself you can even just run `git archive` as part of the script running in ci and then copy the .tar.gz to where abuild wants it and then run `abuild checksum` + `abuild` and it needs no apkbuild changes
2025-03-11 19:13:19 <pc_magas> Can I define a local file in source of the abuild???
2025-03-11 19:14:09 <eletrotupi> man APKBUILD will give you that info, but yes
2025-03-11 19:14:09 <ikke> yes
2025-03-11 19:56:35 <craftyguy[m]> clandmeter: any chance you could take a look at !76940 ?
2025-03-11 20:47:17 <Ermine> Maybe "small, simple, secure" should be removed from the home page? Some people seem to interpret this motto in wild ways
2025-03-11 21:03:10 <funderscore> Some people seem to interpret lots of things in wild ways.
2025-03-11 21:03:46 <funderscore> Ermine: I wouldn't worry about it.
2025-03-11 21:38:37 <sertonix[m]> How do I check for ABI changes? I think the last tinyxml2 upgrade is ABI incompatible without a soname change.
2025-03-11 21:44:26 <psykose> abidiff from libabigail does some stuff
2025-03-11 21:44:50 <psykose> 95% of the output is stuff about 'indirect sub type changes' which is useless noise, but other stuff is useful and tells you what you want
2025-03-11 21:44:58 <psykose> to use abidiff you need the old and new so
2025-03-11 21:49:01 <abby> you rang
2025-03-11 21:49:46 <psykose> how do i use abby diff
2025-03-11 22:07:24 <sertonix[m]> So if I read the noise correctly these type changes are ABI breaking: https://github.com/leethomason/tinyxml2/commit/eb3ab0df5d184b84eb283c0806f6abee71e3409b
2025-03-11 22:07:24 <sertonix[m]> psykose: Do you have any idea if this is correct?
2025-03-11 22:08:35 <psykose> post the noise too
2025-03-11 22:10:09 <psykose> but as a guess (don't know much about c++ abi specifics) i am pretty sure changing stuff like this is breaking yea
2025-03-11 22:10:41 <psykose> it's a public class that is exposed in the shared object and the types changed
2025-03-11 22:11:05 <psykose> but in a way that running an executable will fail to load the .so instead of crashing later
2025-03-11 22:12:24 <craftyguy[m]> Ermine: what are you referring to?
2025-03-11 22:16:05 <psykose> they don't actually set the soversion to something meaningful, it's just whatever the big number is at any given time
2025-03-11 22:16:16 <psykose> just like most c++ libraries nobody really uses this as a .so except distro packagers
2025-03-11 22:16:47 <sertonix[m]> psykose: the noise https://paste.sr.ht/~sertonix/f3b1008d5bede51d655eb75d0b646c3afc068dee
2025-03-11 22:17:44 <psykose> yeah says what i expected
2025-03-11 22:26:48 <Ermine> craftyguy[m]: https://gitlab.alpinelinux.org/alpine/tsc/-/issues/93#note_489071
2025-03-11 22:35:44 <sertonix[m]> psykose: Thanks for the help! I created an issue upstream. They seem to care about the soversion
2025-03-11 22:49:02 <abby> xml libraries love breaking abi
2025-03-11 23:09:56 <ser2> I have a PKGBUILD that depends on mpv; when I try to build it, I get an `mpv (no such package):` error during the dependency analysis. The package is in community, and other packages depend on it; and I've restricted my arch to the mpv package's arch. What might I be missing?
2025-03-11 23:13:22 <ser2> The APKBUILD is here: https://files.catbox.moe/b7dc0l
2025-03-11 23:15:05 <craftyguy[m]> Ermine: 🤦
2025-03-11 23:21:05 <sertonix[m]> ser2: The APKBUILD seems correct. 'abuild deps' installs the dependencies just fine on my system. Are you maybe missing some repositories? Or maybe try apk update?
2025-03-11 23:53:00 <WhyNotHugo> Looks like compiling main/rust doesn't OOM as easily if we reduce the number of JOBS.
2025-03-11 23:53:18 <WhyNotHugo> My patches for UEFI support OOM 100% of the time with the default 24 jobs, but build okay with 16 jobs.
2025-03-11 23:53:34 <WhyNotHugo> The current version in master OOM's sometimes and needs to be retried.
2025-03-12 00:10:17 <sertonix[m]> I wish build systems could just wait until enough memory is available.
2025-03-12 00:24:41 <Hello71> suppose you have 8 GB free and 1000 files to compile. how many gcc instances do you start
2025-03-12 00:25:36 <Hello71> if the answer is "well each one probably won't use more than 1 GB so start 8" then that's just called -j8
2025-03-12 00:40:54 <khem> some large projects like chromium, I have seen keeping 2G per compiler invocation works without ooms most of times 
2025-03-12 10:02:54 <eloy_> are there some particular recommendations/guidelines for packaging a Rust tool? I'd like to have https://github.com/lldap/lldap/releases/tag/v0.6.1 as an Alpine package
2025-03-12 10:09:48 <fabricionaweb> I usually search for aports as examples, there is the cargo-auditable
2025-03-12 10:19:58 <WhyNotHugo> Do CI runner run builds on tmpfs?
2025-03-12 10:28:18 <eloy_> fabricionaweb: that works, but I wondered if those might contain outdated practices :)
2025-03-12 10:29:00 <eloy_> I've made an APKBUILD now, will try to test that and then submit it
2025-03-12 10:47:41 <telmich> It is possible we broke emacs in -edge, at least I get: "File is missing: Cannot open load file, No such file or directory, compat-26" at the moment when starting mu4e
2025-03-12 10:51:06 <ikke> WhyNotHugo: not explici5
2025-03-12 10:51:14 <ikke> Explicitly at least 
2025-03-12 10:58:40 <struan> ?
2025-03-12 11:00:27 <struan> Sorry if this question is asked all the time, but if my aports merge request is marked by aports-qa-bot as stale, is this just as there is a lot of merge requests for reviewers to get through or is there something that I need to do to mark it as ready?
2025-03-12 11:00:40 <struan> See https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/78530
2025-03-12 11:46:37 <eloy_> anyone knows what I'm doing wrong here? wrote the following APKBUILD: https://eloydegen.com/apkbuild_lldap.txt
2025-03-12 11:46:59 <eloy_> `abuild -r` errors with "error: could not find `Cargo.toml` in `/aports/testing/lldap/src` or any parent directory"
2025-03-12 11:48:02 <ikke> eloy_: that means builddir is not correct
2025-03-12 11:49:47 <ikke> It should be: `builddir=$pkgname-$pkgver` (no 'v')
2025-03-12 11:50:03 <ikke> `builddir=$src/$pkgname-$pkgver`
2025-03-12 11:50:07 <ikke> `builddir=$srcdir/$pkgname-$pkgver`
2025-03-12 11:50:17 <eloy_> thank you! 
2025-03-12 11:51:44 <ikke> eloy_: one hint if you want to upstream this package: we don't like replacing every value with variables. For example `https://github.com/$pkgname/$pkgname`. Reason is that doing it like that makes it harder to just copy the url if you want to go to the project url
2025-03-12 11:52:49 <eloy_> makes sense, good to know
2025-03-12 11:53:35 <fabricionaweb> I usually run abuild unpack and check how is the dir that it extracts to
2025-03-12 11:54:10 <ikke> and btw, that value for builddir is the default value and can be omitted (builddir="$srcdir/$pkgname-$pkgver")
2025-03-12 11:55:09 <eloy_> oh, nice!
2025-03-12 12:44:28 <eloy_> now it's essentially the same issue, but after compiling all make depends https://eloydegen.com/lldap_err.txt
2025-03-12 12:59:14 <fjdzqoFsDUV2> telmich: the only significant change i see in the apkbuild is the addition of the --with-native-compilation=no compile flag. would you try rebuilding and testing without that flag?
2025-03-12 13:05:39 <ikke> eloy_: make sure your rsa public key in ~/.abuild is added to /etc/apk/keys 
2025-03-12 13:06:07 <ikke> And your test() function should be called check()
2025-03-12 13:37:29 <eloy_> ikke: thanks again! 
2025-03-12 13:56:16 <ser2> sertonix: I'll try that, thanks.
2025-03-12 13:59:35 <ser> I just realized I was connected both with IRC and Matrix &_&
2025-03-12 15:05:51 <eloy_> is it possible to cache abuild stages so I can resume quickly around the fakeroot stage?
2025-03-12 15:06:07 <eloy_> compiling hundreds of Rust dependencies takes quite some time
2025-03-12 15:07:54 <eloy_> I need to reimplement this in the APKBUILD: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=lldap#n91
2025-03-12 15:09:07 <eloy_> (so: from line 91 to 95, docs should be in a separate package in Alpine)
2025-03-12 16:24:37 <donoban> eloy_: try with -K, but then I think that you have to specify call 'abuild -K build'
2025-03-12 16:25:15 <ikke> Not sure that works combined with rootbld (it may create a new root for each build anyway)
2025-03-12 16:25:37 <donoban> oh didn't know he is using rootbld
2025-03-12 16:25:40 <donoban> it doesn't work with rootbld
2025-03-12 16:25:58 <ikke> oh no, they mentioned fakeroot, not rootbld
2025-03-12 16:26:03 <ikke> misremembered
2025-03-12 16:28:35 <donoban> :)
2025-03-12 16:39:57 <eloy_> I'm getting loads of errors from the wasm-ld linker and I have no clue how to fix those: https://eloydegen.com/apkbuild_lldap_log.txt
2025-03-12 16:40:09 <eloy_> current APKBUILD: https://eloydegen.com/apkbuild_lldap.txt
2025-03-12 16:42:14 <ikke> That's out of my league
2025-03-12 16:42:49 <eloy_> fair :)
2025-03-12 16:43:14 <ikke> There are others here that may be able to help though
2025-03-12 16:52:49 <craftyguy[m]> Anyone got any thoughts on !76940 ?
2025-03-12 17:47:26 <eloy_> this is the error I'm getting, but not sure if it was fixed or not https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/68064#note_423018
2025-03-12 17:47:35 <eloy_> ptrc: ^ 
2025-03-12 17:48:04 <ptrc> ah, you have to unset some env
2025-03-12 17:48:24 <ptrc> see the diff immediately after the comment you linked
2025-03-12 17:51:39 <eloy_> aaaah
2025-03-12 17:51:44 <eloy_> lemme try that :)
2025-03-12 17:58:10 <eloy_> yup that makes this issue go away! thanks
2025-03-12 19:51:10 <realroot[m]> do you need to set some env to use qmake?
2025-03-12 19:51:15 <realroot[m]> qmkae6
2025-03-12 19:53:42 <realroot[m]> qt6ct source has been moved to https://www.opencode.net/trialuser/qt6ct
2025-03-12 20:21:22 <dalias> ok i've tracked down the breakage i hit a while back in GL stuff but i don't know how to fix it...
2025-03-12 20:21:39 <dalias> recent wxwidgets builds with egl instead of glx for opengl support
2025-03-12 20:21:50 <dalias> but glew is built with glx
2025-03-12 20:22:13 <dalias> and this makes it so wxwidgets apps that use glew just get no output (fail to init glew)
2025-03-12 20:22:42 <dalias> alpine should probably have some policy about which one is getting used everywhere :/
2025-03-12 20:22:54 <ikke> fun
2025-03-12 20:23:03 <dalias> i suspect the switch to egl is for wayland silliness reasons
2025-03-12 21:10:28 <humm> not so much “silliness” but “doesn’t require X”
2025-03-12 21:12:17 <humm> (assuming glx only works with X, which I don’t actually know)
2025-03-12 22:57:39 <craftyguy[m]> could someone please review/merge this one? !81147 Thank you :D
2025-03-12 23:58:37 <lotheac> could someone merge !78838 !78944 !81091 ?
2025-03-13 10:22:47 <caskd> is gitlab currently overloaded?
2025-03-13 10:22:55 <caskd> trying to open a MR but getting 500
2025-03-13 10:24:52 <ikke> caskd: new mr?
2025-03-13 10:25:04 <caskd> merge request
2025-03-13 10:25:06 <caskd> it got through
2025-03-13 10:25:10 <caskd> but had to retry 3 times
2025-03-13 10:25:54 <ikke> Hmm
2025-03-13 10:26:47 <ikke> What I mean is, was it when trying a new merge request?
2025-03-13 10:27:36 <caskd> yep
2025-03-13 10:27:51 <caskd> oh yeah, sorry, creating a new mr
2025-03-13 10:28:12 <caskd> just realised opening can have multiple meanings
2025-03-13 10:28:17 <caskd> ^^'
2025-03-13 10:28:50 <ikke> Ok, that's a known problem if your fork is behind too much 
2025-03-13 10:29:18 <ikke> gitaly times out and that results in a 500
2025-03-13 10:29:19 <caskd> the branch itself or the repo overall?
2025-03-13 10:29:31 <caskd> as the branch was fine
2025-03-13 10:29:50 <caskd> i do have some outdated branches i should purge though
2025-03-13 10:30:03 <ikke> The base branch 
2025-03-13 10:30:33 <caskd> that was fine
2025-03-13 10:30:46 <caskd> oh wait maybe not
2025-03-13 11:12:59 <fcolista> any way with apk to overwrite manually touched config file that are part of a package? I want that the manually modified got overwritten without .apk-new file 
2025-03-13 11:24:49 <ikke> fcolista: not that I'm aware of
2025-03-13 12:20:33 <fcolista> ok, thanks for confirming ikke 
2025-03-13 16:53:15 <eloy_> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/81263
2025-03-13 16:53:21 <eloy_> should I click on the rebase button here?
2025-03-13 16:53:44 <ikke> No, that's not necessary
2025-03-13 16:56:39 <eloy_> okay :)
2025-03-13 17:29:19 <eloy_> since this is a daemon, is an OpenRC config required before it can be merged?
2025-03-13 17:30:23 <ikke> It's not a requirement, but it would be nice
2025-03-13 17:32:09 <eloy_> makes sense, I'll try to add one
2025-03-13 17:34:08 <ikke> This is a nice guide for that: https://github.com/OpenRC/openrc/blob/master/service-script-guide.md
2025-03-13 20:05:53 <eloy_> everything should be resolved by now :) should I squash to commits myself?
2025-03-13 20:08:33 <ikke> yes, fixup commits should be squashed
2025-03-13 20:16:45 <eloy_> done, pipeline is running again 
2025-03-13 20:36:27 <eloy_> and everything passed :)
2025-03-13 22:13:13 <sertonix[m]> fabled: are you aware that converting the alpine indexes into the adb format results in larger files even with max compression? I can understand that maybe the new format is harder to compress but I didn't expect it to be larger in the end.
2025-03-14 06:01:41 <fabled> sertonix[m]: yes, i am not sure how much the difference is. it probably depends a lot on the data. but this is a tradeoff to get faster load times, and be able to mmap uncompressed indexes in the later stage.
2025-03-14 08:17:41 <eloy_> huh really weird, this tests passed before but no real change in between: https://gitlab.alpinelinux.org/eloydegen/aports/-/jobs/1766024#L2054
2025-03-14 08:18:09 <eloy_> connection timeouts, then it starts uninstalling makedeps and then suddenly test results arrive back
2025-03-14 08:20:39 <eloy_> it also does work fine on aarch64
2025-03-14 08:24:29 <ikke> Concurrency 
2025-03-14 08:37:52 <eloy_> let's see if re-running gives another result
2025-03-14 08:47:42 <eloy_> okay yay everything passed again now
2025-03-14 08:49:53 <eloy_> is merging into /testing/ fine if the tests are fragile like this?
2025-03-14 08:51:18 <eloy_> I'm not involved in upstream so don't know how/what to fix to make it reliable all the time
2025-03-14 10:06:27 <fabricionaweb> what to do when a package that is on main needs a new dependency? to create this dependency will go to testing and doesnt resolve 🥴
2025-03-14 10:10:01 <donoban> add directly to main
2025-03-14 10:15:28 <ikke> Ack
2025-03-14 10:49:19 <fabricionaweb> !81320
2025-03-14 10:49:43 <fabricionaweb> 😳
2025-03-14 10:50:57 <lotheac> what's the deal with new aport MR's? i have three of those open, two for more than a month, and have pinged a few times but just hearing crickets so far
2025-03-14 10:51:37 <lotheac> well, that's not entirely correct - i did receive some feedback on some of them and addressed it, but merging seems to be a sticking point?
2025-03-14 10:51:55 <fabricionaweb> I think people are just busy or maybe something else is been cooked
2025-03-14 10:52:26 <lotheac> should i keep bothering the channel about them periodically? :)
2025-03-14 11:51:02 <fossdd[m]> i believe !81239 is ready to merge
2025-03-14 11:51:59 <fossdd[m]> thanks!
2025-03-14 16:20:42 <eloy_> what's the usual timespan between aports merge and published package?
2025-03-14 16:21:04 <ikke> 15 minutes after build if the builders are not blocked
2025-03-14 16:21:09 <eloy_> nice :)
2025-03-14 16:26:45 <Priuss> Hi
2025-03-14 16:47:25 <PabloCorreaGomez[m]> fossdd: I've approved things for now, but can we batch 48 upgrades into the same MR?
2025-03-14 16:47:41 <PabloCorreaGomez[m]> It's going to be a lot less work for reviewers and people doing merges
2025-03-14 16:48:01 <PabloCorreaGomez[m]> And could avoid some inconsistencies, like with gnome-backgrounds and a-i-t
2025-03-14 17:20:22 <fossdd[m]> yes sure
2025-03-14 17:20:31 <fossdd[m]> now that the 48 upgrades are coming that makes sense
2025-03-14 19:10:12 <fossdd[m]> i opened now !81342 and closed the MRs it includes, i think that makes it easier to review
2025-03-14 20:02:41 <Hello71> "2025-03-09 22:02:56     fossdd[m]       on what hardware is the riscv64 builder running again?" "2025-03-09 22:03:54     @ikke   milkv pioneer" is that also for ci?
2025-03-14 20:03:37 <ikke> Hello71: yes, though, there should also be a banapi f3
2025-03-14 20:06:27 <Hello71> uh... what does that mean? random selection?
2025-03-14 20:10:24 <ikke> Yes, whichever is available
2025-03-14 20:53:56 <PabloCorreaGomez[m]> fossdd: thanks a lot!
2025-03-15 20:21:18 <eloy_> if the build fails because abuild says certain files cannot be found, can I peek inside the build directory during the build before abuild removes everything at the end?
2025-03-15 20:25:36 <ikke> eloy_: run abuild -rK
2025-03-15 20:26:18 <eloy_> ikke: thanks!
2025-03-15 20:39:31 <mio> if an aport is upgraded with an arch disabled, does the older package get removed from the cdn on that arch as well once the newer version is sent to the builders?
2025-03-15 20:43:34 <fossdd[m]> yes
2025-03-15 20:44:22 <mio> okay, thanks. figured it might get purged, confirming to be sure
2025-03-15 22:29:25 <Kladky> Could I please have someone take a look at !81048, !76487 and !78021 ? Thanks in advance
2025-03-15 22:45:44 <fossdd[m]> !81362 and !81207 would also be nice to merge :D
2025-03-15 23:27:46 <sertonix[m]> fossdd: could you upgrade tinyxml2 to 11.0.0 to avoid extra rebuilds?
2025-03-16 00:34:41 <fossdd[m]> <sertonix[m]> "fossdd: could you upgrade..." <- yessss added
2025-03-16 07:48:59 <NN708> Hi everyone, I wanted to kindly follow up on my merge request https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/77702 , which fixes the 'unless-stopped' restart policy to align with the Podman documentation. I submitted this two months ago, and it was recently flagged as inactive by the bot. Is there anything I can clarify to move this forward? I'd greatly appreciate your time and feedback.
2025-03-16 09:18:03 <ikke> NN708: It's waiting for greenlight from mpolanski, not sure why he's not responding to that MR
2025-03-16 13:01:30 <fossdd[m]> hii, it would be nice if !81342 could land soon-ish. i know its a big one but its getting a pain for the ci and it would help doing the next upgrades
2025-03-16 13:26:21 <EvTheFuture> Do I need to approve this !80982 MR in any other way than a comment?
2025-03-16 13:27:20 <fossdd[m]> no a comment is enough, but there are currently 800+ MRs open and it takes time to merge all of them :)
2025-03-16 13:31:52 <ikke> EvTheFuture: I've added you as guest to the project so that you can approve
2025-03-16 13:35:37 <EvTheFuture> ikke: Thanks
2025-03-16 13:36:01 <EvTheFuture> fossdd[m]: Fully understandable, thank you.
2025-03-16 18:38:10 <fossdd[m]> the ci for !81342 finished and i have some new upgrades local, i think it would be nice if it can get merged so i dont have to waste another 4.5h riscv ci time :)
2025-03-16 18:52:37 <Ermine> please take a look at !70869
2025-03-16 19:01:53 <Ermine> Also, should I consider github releases more secure source of tarballs than pypi?
2025-03-16 19:03:17 <ikke> If it's manually uploaded sources, then no
2025-03-16 19:05:23 <Ermine> seems like github always has links for auto-generated tarballs
2025-03-16 19:06:03 <ikke> yes
2025-03-16 19:10:39 <Ermine> well, i use those
2025-03-16 19:11:02 <ikke> Just wanted to make the destinction clear :)
2025-03-16 19:11:06 <ikke> distinction*
2025-03-17 04:07:49 <NN708> ikke: Thanks for your help! I just noticed that mpolanski said in another MR: "My free time is very limited past year so I'm going through the backlog of TODOs just bit by bit." Maybe I'll have to wait a little longer.
2025-03-17 04:35:10 <mio> MRs for the builders in case they might help !81435 !81434 !81425
2025-03-17 04:35:57 <mio> there are people already looking into hugo and miller on edge loongarch64
2025-03-17 04:36:43 <mio> cargo-deny maintainer also notified for s390x
2025-03-17 04:37:44 <mio> should cover most of the remaining build errors
2025-03-17 09:03:11 <sf-mensch> As the bot noted to ask here: is there anything "missing"? If not, can it be merged?
2025-03-17 09:03:11 <sf-mensch> MR 77911 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/77911 was rebased multiple times and is, again, outdated (though I don't think this is a problem here).
2025-03-17 09:38:43 <fabricionaweb> I also have one new aport MR opened !78515
2025-03-17 12:27:10 <Ermine> bl4ckb0ne: you may want to push !81465
2025-03-17 14:15:35 <strophy> Does anyone know where can I find documentation on the `amove` command/function, is this some built-in abuild thing or a separate binary?
2025-03-17 14:19:22 <fjdzqoFsDUV2> strophy: /usr/bin/abuild:71
2025-03-17 14:19:46 <fjdzqoFsDUV2> or at least ~:71
2025-03-17 14:20:07 <fjdzqoFsDUV2> depending on your version
2025-03-17 14:28:12 <strophy> Not much in the way of comments or docs there. Where is `pattern` defined, is the argument passed to `amove()`? What do `f` and `d` mean, file and directory maybe? From the examples I've seen it takes only a single argument, so I'm guessing it is a function to move anything matching the arguments passed into `$subpkgdir`?
2025-03-17 14:36:01 <psykose> yep
2025-03-17 16:06:59 <eletrotupi> ping on this boi !80666
2025-03-17 16:09:07 <psykose> it got updated in 00d5a2308c0ec969e2550909a3cfcc540334dcca already apparently
2025-03-17 16:19:30 <eletrotupi> oh
2025-03-17 16:21:30 <eletrotupi> will close that one and open one for adopting it then
2025-03-17 16:21:34 <eletrotupi> thanks, i guess?
2025-03-17 22:35:29 <Ermine> please remind me, should i bump pkgrel when moving stuff to community?
2025-03-17 22:38:04 <lotheac> don't think it's needed, i haven't
2025-03-17 22:43:18 <ikke> it's not needed, given there are no changes that users would need to get
2025-03-17 22:48:10 <Ermine> ok
2025-03-17 22:48:15 <Ermine> thank you
2025-03-18 07:47:14 <ncopa> this error looks nasty https://build.alpinelinux.org/buildlogs/build-edge-armv7/testing/certstrap/certstrap-1.3.0-r21.log
2025-03-18 07:47:25 <ncopa> i get the same on x86 (32bit)
2025-03-18 07:47:32 <ncopa>     expiry_test.go:138: Invalid expiry '2147483647 days' did not have expected value (wanted: 2017-01-01 00:00:00 +0000 UTC, got: -5877594-06-22 00:00:00 +0000 UTC)
2025-03-18 07:47:55 <ncopa> does this mean that with go 1.24.1 they switched from 64 bit time to 32 bit time?
2025-03-18 08:03:29 <fossdd[m]> i think its only the library
2025-03-18 08:04:01 <fossdd[m]> looks like it parses it into a 32-bit int https://github.com/square/certstrap/blob/master/cmd/expiry.go#L25
2025-03-18 08:22:47 <ikke> Ouch
2025-03-18 08:32:27 <lotheac> anyone able to merge !81091 !78944 !78838 ?
2025-03-18 08:40:24 <knuxify> hm, strange - i kept getting 500 errors when trying to create a merge request, but locally rebasing on latest master and dropping a stray commit that somehow ended up there fixed it
2025-03-18 08:40:41 <knuxify> (stray commit from my local branch, that is)
2025-03-18 08:57:32 <ikke> knuxify: it's a known issue that gitaly times out on the create MR page when the source branch is too far behind 
2025-03-18 09:37:23 <fabricionaweb> I also have some MR to review, one of them the maintainer which is also the app developer doesnt seem to care/answer me lol maybe I take it over or give up 😅
2025-03-18 09:40:48 <telmich> Hey everyone! I am so annoyed by the lack of webcam support in alpine at the moment that I am willing to put down a bounty of 1000 USD  for anyone who manages to enable alpine linux to use the ipu6 webcam on Lenovo X1 carbon gen12 and Dell XPS 13 by end of April this year. Condition would be that everything needed can be apk installable from main/community/testing so that everyone can benefit from it and I'd confirm it. I am unfortunately
2025-03-18 09:40:48 <telmich> too busy with being a fresh dad and needing to do useless administration tasks to tackle it myself, but if anyone is out there, I'm willing to support this financially. Alternatively, I can offer a 1 week stay in the Hacking Villa Diesbach (travel excluded).
2025-03-18 09:50:44 <ikke> telmich: congrats 
2025-03-18 09:51:23 <lotheac> seems like that should be just enabling CONFIG_VIDEO_INTEL_IPU6?
2025-03-18 09:55:39 <lotheac> not sure though, don't have a device like that :)
2025-03-18 09:57:24 <ncopa> im enabling that. thanks lotheac
2025-03-18 10:07:11 <telmich> I think it's a combination of that option plus linux-firmware update
2025-03-18 10:07:46 <telmich> However, I did try that manually a month or two ago and the result was that there were 30ish webcams visible in firefox, non usable. I believe somebody else reported this on gitlab as well. That is where my trail ended.
2025-03-18 10:30:12 <qaqland> hi, i think MR !77955 and !80909 are ready
2025-03-18 10:56:48 <sertonix[m]> @nico:ungleich.ch Are you able to use the camera from a different distro and can maybe figure out the kernel module that is used?
2025-03-18 10:57:26 <telmich> sertonix[m]: I recently retried latest ubuntu and on its stock / live version it did not work either.
2025-03-18 10:57:58 <telmich> The "best" results was using linux-edge + self built linux-firmware package with ipu6 blob in them, resulting in those many-but-none-usable cameras
2025-03-18 11:06:59 <sertonix[m]> It seems like it is working on Mint: https://forums.linuxmint.com/viewtopic.php?t=436491
2025-03-18 11:06:59 <sertonix[m]> Could you maybe check if this works for you too? Then we can check what mint is doing differently
2025-03-18 11:35:31 <ncopa> sertonix[m]: I think we need to make an abuild release. Are there any of the open MRs that are more important than the others?
2025-03-18 12:02:40 <sertonix[m]> abuild!370 if we don't want to breal pmOS
2025-03-18 12:03:10 <sertonix[m]> *break
2025-03-18 12:22:24 <PabloCorreaGomez[m]> sertonix ncopa ikke fossdd: for the APKv3 meeting fabled can't do after 15UTC. Would you be fine if I update timeslots to also include 12-15UTC? 
2025-03-18 12:24:17 <ncopa> sure
2025-03-18 12:24:50 <ikke> My options are more limited, but I do have some
2025-03-18 12:26:56 <fossdd[m]> yeah
2025-03-18 12:30:54 <ikke> Anyone a clue why I get this error when running abuild rootbld in an lxc container? 
2025-03-18 12:30:57 <ikke> bwrap: Can't mount proc on /newroot/proc: Operation not permitted
2025-03-18 12:35:29 <Habbie> https://wiki.alpinelinux.org/wiki/Build_with_abuild_rootbld_in_Docker_container might be interesting
2025-03-18 12:35:31 <Habbie> (i know it says docker)
2025-03-18 12:35:42 <Habbie> but it also mentions things like mount permissions
2025-03-18 12:36:17 <caleb_m> ikke missing the capability to unshare process namespace?
2025-03-18 12:39:31 <ikke> Seems like that requires CAP_SYS_ADMIN, which would not be good to give out
2025-03-18 12:39:42 <ikke> I seem to recall this having worked in the past though
2025-03-18 12:50:00 <jvvv> afaik, that CAP_SYS_ADMIN can be local to the unshared namespace, so problem could be lxc dropping caps or no_new_privs being set inside the lxc container
2025-03-18 12:50:51 <ikke> lxc does drop CAP_SYS_ADMNIN per container
2025-03-18 12:51:02 <ikke> Part of our default lxc container config
2025-03-18 12:51:58 <jvvv> yeah, so when bwrap can't do its thing inside that container, or so it would seem to me
2025-03-18 12:52:13 <jvvv> s/when/then/
2025-03-18 12:52:28 <ikke> That kind of means rootbld is not feasible in the current build architecture
2025-03-18 12:53:16 <jvvv> nested containers was always confusing to me
2025-03-18 12:56:27 <ikke> But I do recall it having worked in the past, so wonder what changed
2025-03-18 12:56:46 <ikke> (but maybe it's that I standardized the config of my container meaning dropping SYS_CAP_ADMIN again
2025-03-18 15:16:15 <sertonix[m]> ikke: see https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10162#note_469616
2025-03-18 19:27:55 <Ariadne> it is possible to do nested unprivileged containers without CAP_SYS_ADMIN
2025-03-18 19:28:05 <Ariadne> but you can't map multiple UIDs
2025-03-18 19:37:09 <ikke> Ariadne: is it expected that gobuilds_test runs something like `go version -m <file>` where <file> contains just a single module name as string? That just seems to return an error code, which is what we see failing
2025-03-18 19:37:25 <Ariadne> related to what?
2025-03-18 19:43:22 <ikke> sbom generation it appears
2025-03-18 19:43:33 <ikke> sbom, mt, err := g.sbom(ctx, file, appPath, fmt.Sprintf("%s-%s", appFileName, pf), si, g.sbomDir
2025-03-18 20:00:29 <Ariadne> i mean, related to what aport
2025-03-18 20:02:12 <Ariadne> if this is ko, i think that is what it assumes it can do.  this has probably broken in newer versions of the go toolchain...
2025-03-18 20:02:24 <Ariadne> i haven't looked at this code in years
2025-03-18 20:42:16 <ikke> Ariadne: ah, sorry, I thought I had mentioned ko
2025-03-18 20:45:59 <ikke> Ariadne: yeah, go1.23 -> exit code 0, go1.24 -> exit code 1
2025-03-18 20:46:08 <ikke> Both cases no output
2025-03-18 20:47:24 <ikke> curious what it was meant to test
2025-03-18 20:49:58 <Ariadne> i have no idea
2025-03-18 20:50:18 <Ariadne> i would just disable the test tbh, it seems meaningless
2025-03-18 20:50:29 <ikke> ack
2025-03-19 06:05:35 <moha-al> Hi! I just encountered a checksum error in the download stage when building the file package locally on edge and filed !81553 to fix it. Reviews appreciated.
2025-03-19 07:34:28 <mio> MRs to help a bit with the builders: !81500 !81543 !81543 !81555
2025-03-19 07:34:51 <lotheac> '
2025-03-19 07:34:53 <lotheac> oops
2025-03-19 07:35:13 <mio> sorry about the duplicate, !81552
2025-03-19 07:46:29 <fossdd[m]> can i interest somebody in taking a look at !81342? :p
2025-03-19 08:38:50 <fabricionaweb> may I take over this? the maintainer dont answers me !80525
2025-03-19 08:50:38 <fabricionaweb> may need review on this one !78515 
2025-03-19 10:34:50 <WhyNotHugo> when backporting a patch, it's preferrible to include the patch itself in the aports repo rather than include it in source= ?
2025-03-19 10:36:05 <ikke> Patches from github/gitlab are known to be volatile 
2025-03-19 10:36:30 <WhyNotHugo> sr.ht confirmed that patches are stable
2025-03-19 10:37:25 <WhyNotHugo> what is the preferrence in case of stable patch URLs (on the same host as the main source=.tar.gz)
2025-03-19 10:39:57 <WhyNotHugo> i don't understand if "vendor patches" is the general rule, or it's the exception for cases like github/gitlab.
2025-03-19 10:50:20 <ikke> I have a slight preference to vendored patches because the patch would be visible 
2025-03-19 11:37:01 <ikke> Advantage to remote patches is that you can be certain the patch has not been tampered with
2025-03-19 11:37:26 <WhyNotHugo> yeah, that was my main train of though. especially with patches that upgrade dependencies and lockfiles
2025-03-19 11:38:41 <ikke> WhyNotHugo: when you confirmed with sr.ht, what did they say? Because patches from github/gitlab are mostly stable, but still generated, which means the `index ..` lines can change
2025-03-19 11:40:00 <WhyNotHugo> I asked: are patches stable. E.g.: if I curl the following URL, will the checksum match regardless of changes in the repository
2025-03-19 11:40:07 <WhyNotHugo> answer was yes
2025-03-19 11:40:57 <ikke> okay
2025-03-19 11:41:58 <ikke> WhyNotHugo: https://gitlab.alpinelinux.org/alpine/infra/atools-go/-/issues/2
2025-03-19 11:42:10 <ncopa> mio: thanks!
2025-03-19 11:43:04 <ikke> WhyNotHugo: It seems that the git version is part of the patch, so that changing could affect the patch
2025-03-19 11:43:53 <WhyNotHugo> good catch!
2025-03-19 13:08:48 <fabricionaweb> Im going to take over the community/mise since the current maintainer didnot answer, review nor approve my bump !308703
2025-03-19 13:10:38 <fabricionaweb> wrong one !80525
2025-03-19 13:14:32 <ikke> fabricionaweb: they did answer now :-)
2025-03-19 13:14:54 <mio> ncopa: you're welcome, thanks for reviewing!
2025-03-19 13:24:19 <fabricionaweb> haha
2025-03-19 13:24:54 <fabricionaweb> well nice, I think i can help to keep it updated
2025-03-19 13:31:01 <jvvv> i have a similar issue as fabricionaweb with !79736. maintainer said i could take it over yet also said was still interested. i decided not to take it over for now, but the mr is getting stale.
2025-03-19 13:53:10 <jvvv> ikke: thanks!
2025-03-19 20:10:31 <PabloCorreaGomez[m]> ikke: it poped up today in a pmOS team chat. It's happened now a few times, that we are doing work on upstream tooling, e.g: abuild, and collaborating strongly with other pmOS people on preparing patches before sending them out
2025-03-19 20:10:51 <PabloCorreaGomez[m]> Now we are doing it from our own personal forks, and giving other people access ad-hoc
2025-03-19 20:11:21 <PabloCorreaGomez[m]> Might it make sense from your perspective to have a postmarketOS namespace to have those forks, that we could administer?
2025-03-19 21:03:50 <ikke> PabloCorreaGomez[m]: let me come back to that
2025-03-19 21:04:35 <PabloCorreaGomez[m]> Thanks!
2025-03-20 11:36:43 <Eighth_Doctor> hey folks, I'm the fedora apk-tools maintainer and I was wondering if apk-tools v3 final will be tagged sometime in the next few days?
2025-03-20 12:59:30 <PabloCorreaGomez[m]> fabled: may you have time to fill in the poll? There seems to be some fitting times
2025-03-20 12:59:51 <PabloCorreaGomez[m]> Conan Kudo: I'm trying to organize a meeting to basically figure that out :)
2025-03-20 13:00:30 <Eighth_Doctor> hey Pablo Correa Gomez :)
2025-03-20 13:01:22 <Eighth_Doctor> I only have a little over a week before Fedora 42 final freeze
2025-03-20 13:01:29 <Eighth_Doctor> so I need to be able to land it before then
2025-03-20 13:02:19 <PabloCorreaGomez[m]> Then IDK. Timing for v3.22 is beginning of April, but I'm not sure how much buffer there is
2025-03-20 14:46:35 <eletrotupi> just adopting the package for niri since ptrc upgraded and the maintainer said i could adopt it: !81646
2025-03-20 14:52:44 <fabled> PabloCorreaGomez[m]: updated now.
2025-03-20 14:54:44 <bl4ckb0ne> eletrotupi: could you link the message from the current owner stating he doesnt want to maintain it anymore?
2025-03-20 14:57:24 <eletrotupi> yeah, sure
2025-03-20 14:57:28 <eletrotupi> one sec
2025-03-20 14:58:10 <eletrotupi> do you want on the commit message or just the pr is fine?
2025-03-20 14:58:33 <eletrotupi> I dunno if there's a formality for it
2025-03-20 15:12:04 <bl4ckb0ne> both if possible
2025-03-20 15:12:09 <PabloCorreaGomez[m]> fabled: thanks! You should all have an invitation in your inbox
2025-03-20 23:16:10 <sertonix[m]> @_oftc_Ariadne:matrix.org : Could you take a look at https://gitlab.alpinelinux.org/alpine/aports/-/issues/16942 and maybe comment which patch you would prefer?
2025-03-21 03:07:56 <dalias> alpine gitlab emails to me are getting rejected for forged EHLO
2025-03-21 03:08:06 <dalias> someone broke the mailserver
2025-03-21 03:15:08 <humm> I thought the EHLO string is meaningless
2025-03-21 03:41:06 <dalias> humm, no, generally only spammers forge it. should be a valid hostname resolving to the smtp client's ip
2025-03-21 05:22:19 <anjan> ikke: please take a look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/79319 should be resolved
2025-03-21 06:24:51 <ikke> anjan: it would be good to includde a reason to downgrade haxe in the commit message and maybe a comment in the APKBUILD
2025-03-21 06:53:34 <qaqland> meilisearch in aports is 1.1.1 now, it was released on Apr 14 2023
2025-03-21 06:55:36 <qaqland> the version of this package is too low to use and it has not received much attention. I think it can be discarded.
2025-03-21 07:33:49 <craftyguy[m]> is atools no longer a thing? I see the repo for it was 'archived' on gitlab
2025-03-21 07:35:37 <ikke> craftyguy[m]: replaced by atools-go
2025-03-21 07:35:58 <ikke> I should maybe include a message
2025-03-21 07:37:59 <craftyguy[m]> ohh ok. I saw atools was being installed for apkbuild linting: https://gitlab.alpinelinux.org/alpine/infra/docker/apkbuild-lint-tools/-/blob/master/Dockerfile?ref_type=heads#L19
2025-03-21 07:38:38 <craftyguy[m]> but now I see that it's actually using apkbuild-lint from atools-go :P
2025-03-21 07:48:07 <ikke> Yes, as a way of transitioning 
2025-03-21 07:48:22 <ikke> Since atools-go only has apkbuild-lint atm
2025-03-21 09:27:32 <flix> could someone have a look on this one? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/81078
2025-03-21 09:27:48 <flix> it's a trivial version bump
2025-03-21 11:27:17 <flix> ikke: thank you :)
2025-03-21 11:28:27 <ikke> flix: You're welcome
2025-03-21 16:28:44 <nangel> Hey.
2025-03-21 16:29:37 <nangel> mr !81582 - kamailio 6.0.1 passsed...
2025-03-21 18:14:49 <bl4ckb0ne> is it ok if I self merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/71645 ? i managed to test it and its working great
2025-03-21 18:14:58 <bl4ckb0ne> got qsv working on jellyfin :D 
2025-03-21 18:15:14 <ikke> bl4ckb0ne: yes
2025-03-21 18:15:24 <bl4ckb0ne> o7
2025-03-21 18:15:34 <bl4ckb0ne> ty
2025-03-21 18:15:57 <bl4ckb0ne> they are working on moving to a more recent llvm version, ill keep an eye on the issue
2025-03-21 18:36:44 <witcher01> Could someone have a look at !53556 for merging?
2025-03-21 19:23:29 <witcher01> thanks ikke
2025-03-22 00:56:15 <anjan> ikke: done
2025-03-22 00:56:29 <anjan> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/79319
2025-03-22 14:12:32 <fabled> PabloCorreaGomez[m], ncopa: I had to cancel the planned APK3 meeting on my part. There was a conflicting family meeting not marked in my calendar. Sorry. Can we try for the week after? My next week is pretty fully booked.
2025-03-22 18:10:42 <caskd> How would one deprecate a package that is unmaintained and replace it with something that isn't necessarily the same or fully backwards compatible?
2025-03-22 18:11:49 <ikke> Maybe a post-install/upgrade message that would encourage users to use the other package?
2025-03-22 18:12:09 <caskd> Okay, well then there's another issue
2025-03-22 18:12:16 <caskd> they are literally named the same
2025-03-22 18:12:21 <caskd> as they fulfill the same function
2025-03-22 18:12:26 <caskd> but are not directly related
2025-03-22 18:12:37 <caskd> ^^'
2025-03-22 18:13:00 <caskd> Talking about: https://github.com/Tinkoff/libvirt-exporter and https://github.com/inovex/prometheus-libvirt-exporter
2025-03-22 18:13:06 <ikke> Then I think you would have to namespace one
2025-03-22 18:13:50 <ikke> I maintain a package for a tool called task, but there is also another package called task, but they are completely unrelated and do completely different things
2025-03-22 18:14:03 <ikke> The package I maintain was added later, so I called it go-task
2025-03-22 18:14:11 <caskd> hm
2025-03-22 18:14:28 <caskd> okay, i'll see
2025-03-22 18:14:32 <quinq> One is called libvirt-exporter, and the other prometheus-libvirt-exporter
2025-03-22 18:14:48 <caskd> yes but the package name is unfortunately called prometheus-libvirt-exporter
2025-03-22 18:14:57 <caskd> as almost all other exporters
2025-03-22 18:15:05 <caskd> prometheus-x-exporter
2025-03-22 18:15:45 <quinq> Ah, you mean that Tinkoff/libvirt-exporter package has been renamed prometheus-libvirt-exporter?
2025-03-22 18:15:58 <caskd> no, i mean that i packaged it as prometheus-libvirt-exporter
2025-03-22 18:16:05 <caskd> to fit the naming scheme
2025-03-22 18:16:16 <quinq> Yeah, that's exactly what I said ^^
2025-03-22 18:16:19 <ikke> If they are not compattibly, it would not be appropriate to replace one with another
2025-03-22 18:16:25 <ikke> compattible*
2025-03-22 18:16:29 <caskd> yeah
2025-03-22 18:16:42 <quinq> Let's at least learn from past mistake to avoid future ones
2025-03-22 18:16:47 <caskd> that's why i'm seeking some feedback and other opinions
2025-03-22 18:16:56 <quinq> But isn't there some kind of peer control review before adding new packages?
2025-03-22 18:17:12 <quinq> Like *do not* take the liberty to rename upstream packages
2025-03-22 18:17:20 <caskd> quinq: node_exporter is also named prometheus-node-exporter
2025-03-22 18:17:27 <caskd> this is the case for a lot of exporters
2025-03-22 18:17:28 <ikke> quinq: Sometimes we have to
2025-03-22 18:17:28 <quinq> (unless it's needed for a technical problem)
2025-03-22 18:17:51 <quinq> caskd, that's horrible :/
2025-03-22 18:17:52 <ikke> I mean, we prefix all python related packages with py3-, and similar for other ecosystems
2025-03-22 18:18:02 <ikke> So it's not without precedent
2025-03-22 18:18:06 <quinq> Yeah but that's a prefix
2025-03-22 18:18:12 <quinq> It's not a package renaming
2025-03-22 18:18:19 <ikke> prometheus-* could also be seen as a prefix
2025-03-22 18:18:22 <caskd> yeah
2025-03-22 18:18:35 <caskd> i just followed the usual pattern like with the other exporter examples
2025-03-22 18:18:45 <caskd> i think i even just copied the apkbuild and adapted it
2025-03-22 18:18:47 <quinq> If there was an actual upstream package named py3-foo, it wouldn't clash with the model, it could be (albeit a bit ugly) py3-py3-foo
2025-03-22 18:19:00 <quinq> ikke, could or is?
2025-03-22 18:19:24 <quinq> Are we going to actually make it a distribution-managed prefix?
2025-03-22 18:19:25 <ikke> quinq: https://pkgs.alpinelinux.org/packages?name=prometheus-*&branch=edge&repo=&arch=x86_64&origin=&flagged=&maintainer=
2025-03-22 18:20:45 <caskd> i think only a few exporters break the pattern
2025-03-22 18:21:24 <quinq> So the new package will be prometheus-prometheus-libvirt-exporter
2025-03-22 18:40:45 <caskd> oh, for some reason i misremembered as me maintaining this package
2025-03-22 18:41:42 <quinq> ikke, yeah, most of them are from the prometheus project, only ~4 aren't
2025-03-22 20:59:39 <ptrc> seems like abuild 3.14.0 added a funny regression
2025-03-22 20:59:54 <ptrc> exporting srcdir breaks some build systems that assume the env to be meant for them
2025-03-22 21:00:24 <ptrc> https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/372
2025-03-22 21:13:42 <ikke> ptrc: it seems with this version the pipeline button shows a popup again with inidividual arches again
2025-03-22 21:14:12 <ikke> (with child pipelines)
2025-03-22 21:14:31 <ptrc> ooooh, that's nice
2025-03-22 21:15:14 <ptrc> thanks for the upgrade ^^
2025-03-22 21:15:32 <ptrc> seems like there's some other nice things as well
2025-03-22 21:16:01 <ptrc> e.g. the comment icon on MRs changed to show just unresolved threads
2025-03-22 21:16:05 <ikke> yup
2025-03-22 21:21:30 <ikke> It does mean it harder to see if someone commented on an MR
2025-03-22 21:25:41 <ikke> btw, do the shortcuts to go to next and previous commits in an MR work for you? (c / x)?
2025-03-22 21:25:54 <ikke> For me they worked in the beginning, but stopped working at some point
2025-03-22 21:38:19 <ptrc> huh, i didn't even know those existed
2025-03-22 21:39:17 <fossdd[m]> but that sounds cool
2025-03-22 21:39:22 <ikke> If they work
2025-03-22 21:40:48 <fossdd[m]> in the ? keybinding its still listed
2025-03-22 21:44:45 <ikke> fossdd[m]: yes
2025-03-22 21:44:58 <ikke> Can someone test it here? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/81383/commits
2025-03-22 21:47:07 <ptrc> not working, either on the list or after clicking on some commit
2025-03-22 21:52:59 <ikke> alright, thanks for chekcing
2025-03-22 21:59:49 <ptrc> btw, do we have a timeline on switching to llvm20?
2025-03-22 22:07:42 <ikke> no more navigating to specific pages though :(
2025-03-22 22:07:46 <ikke> only next/previous
2025-03-22 22:29:32 <fossdd[m]> somebody here who wants to merge !80946 and !81207? ^^
2025-03-23 00:07:06 <mio> would like to say thanks for the gitlab.a.o upgrade as well, good to see the ci pipeline popup menu on MRs is back
2025-03-23 08:11:38 <ikke> 55 pending MRs..
2025-03-23 08:11:42 <ikke> sorry, pending jobs
2025-03-23 14:02:58 <EvTheFuture> is it just for me or has the gitlab web UI been down all day? I only get a 500: We're sorry something went wrong on our end. Request ID: 01JQ1MP51HVBN85MBC10R9CB72
2025-03-23 14:03:22 <ikke> EvTheFuture: It is working for me just fine
2025-03-23 14:03:30 <ikke> Let me check the logs
2025-03-23 14:03:56 <EvTheFuture> I'm just following an MR link
2025-03-23 14:04:36 <ikke> EvTheFuture: Creating a new MR?
2025-03-23 14:04:42 <EvTheFuture> YEs
2025-03-23 14:04:55 <ikke> Ok, that means the branch is too far out-of-date
2025-03-23 14:05:00 <EvTheFuture> But I created it yesterday but got the error and tried today again
2025-03-23 14:05:12 <EvTheFuture> Ok, I'll fix and retry
2025-03-23 14:05:23 <ikke> EvTheFuture: Try to make sure your master branch on your fork is updated
2025-03-23 14:05:30 <ikke> alternatively, use glab mr create instead
2025-03-23 14:05:56 <ikke> The problem is that for some reason it's an expensive operation and gitaly is timing out on aports
2025-03-23 14:07:10 <ikke> 0"exception.class": "Gitlab::Git::CommandTimedOut",
2025-03-23 14:14:56 <EvTheFuture> Now it worked. Thank you. I forgot that I used some time on this upgrade since the project has mooved etc.
2025-03-23 14:21:59 <ikke> nop
2025-03-23 14:22:01 <ikke> np
2025-03-23 15:16:56 <nangel> MR !ef048e9b - upgrade community/flashrom to v1.5.1
2025-03-23 15:18:34 <nangel> Sorry, that was the commit: !81824
2025-03-23 16:00:26 <fabricionaweb> Im trying to bump deno, no luck :/
2025-03-23 20:34:24 <ikke> ptrc: any feedback on https://gitlab.alpinelinux.org/alpine/infra/atools-go/-/issues/7? Wanna make a new release, and figuring out if I can include it or now
2025-03-23 20:34:48 <ptrc> ah, i forgot to reply
2025-03-23 20:34:49 <ptrc> one sec
2025-03-23 20:47:50 <ikke> thx
2025-03-23 23:55:56 <quinq> Looks like kaidan upgrade broke 
2025-03-23 23:57:12 <quinq> https://clbin.com/ZNGEP
2025-03-23 23:57:27 <quinq> (then exits with 255)
2025-03-24 00:15:16 <lotheac> could someone merge !81091 !78944 !78838 ? thanks!
2025-03-24 05:34:35 <prabu> while updating wiki, i have some doubts about tagged repository and pinned repository. i've raised it in wiki talk page https://wiki.alpinelinux.org/wiki/Talk:Alpine_Package_Keeper#Repository_pinning
2025-03-24 05:35:00 <prabu> i'll appreciate if someone can clarify/correct me here or there...
2025-03-24 06:50:39 <Saijin_Naib[m]> I think I finally have !79951 ready for review/merge if anyone has time
2025-03-24 08:29:28 <fabricionaweb> morning, who can merge this one !80525
2025-03-24 13:44:42 <bl4ckb0ne> fossdd[m]: why did you close !79695 ?
2025-03-24 14:51:57 <fossdd[m]> sdl2-compat and sdl2 are abi compatible so there is not much gain in rebuilding
2025-03-24 15:10:24 <fabricionaweb> would someone be interested in help to bump community/deno? I tried but its failing to link icu (seems related to v8) It is a bunch of things far far from my knowledge :/
2025-03-24 15:10:54 <fabricionaweb> I could fix some patches, it seems its going well but still failing, and Im out of ideas
2025-03-24 15:54:20 <bl4ckb0ne> fossdd[m]: i was thinking of dropping sdl2 at some point, but sdl2 is still getting some updates
2025-03-24 16:03:06 <craftyguy[m]> any chance we could get !81147 merged soon?
2025-03-24 16:18:15 <ncopa> fabricionaweb: I'm working on icu 76. deno is one of the things that fails. some test fails and I don't think it is related icu
2025-03-24 16:53:06 <fabricionaweb> ah ok thanks, well sadly I dont know how to fix, deno is too outdated and I'd like to dev on it, sadly theres no build to run it musl
2025-03-24 19:01:27 <Ermine> bl4ckb0ne: !81880 
2025-03-24 19:01:53 <bl4ckb0ne> ty
2025-03-24 19:01:57 <fossdd[m]> <bl4ckb0ne> "fossdd: i was thinking of..." <- ah i see. yeah that makes sense, i suppose i can update the mr again
2025-03-24 19:02:14 <bl4ckb0ne> ill keep an eye on the sdl2 release, idk what's their plan
2025-03-24 19:03:11 <fossdd[m]> yeah, for me it looks like theyre slowly phasing out sdl2 but idk just guessing
2025-03-24 19:05:59 <craftyguy[m]> seems like the alpine aarch64 builder is stuck for a while because it fails to build testing/ghostty, it seems this failure is only happening on the builder (I cannot repro locally, and it passed gitlab CI). Can we just revert the commit that upgrades this pkg so that the builder isn't blocked by this?
2025-03-24 19:06:23 <craftyguy[m]> I tried to debug it, but ya because it works locally, and I don' thave access to poke around the builder... not much I can do :P
2025-03-24 19:07:58 <ikke> craftyguy[m]: I'd be interested in looking why it's failing if I have some pointers
2025-03-24 19:08:23 <ikke> I already tried removing ~/.cache/zig, as mentioned in a github issue
2025-03-24 19:09:20 <craftyguy[m]> oh there's a github issue? heh. I tried looking for one yesterday but clearly failed to find it
2025-03-24 19:09:33 <ikke> I think about something similar
2025-03-24 19:09:39 <ikke> not sure the exact same issue
2025-03-24 19:09:49 <ikke> The problem is that the error is rather vague
2025-03-24 19:09:54 <craftyguy[m]> I don't really have any pointers, I have practically no experience building zig stuff
2025-03-24 19:10:01 <craftyguy[m]> yeah it's super vague
2025-03-24 19:10:14 <ikke> Oh, it was not github, but discourse
2025-03-24 19:10:15 <craftyguy[m]> maybe there's a way to get zig to be more verbose about why it's failing
2025-03-24 19:10:16 <ikke> https://ziggit.dev/t/error-command-terminated-unexpectedly/3684
2025-03-24 19:10:55 <craftyguy[m]> do you have the ability to retry without having to merge patches in aports? 
2025-03-24 19:11:16 <ikke> yes
2025-03-24 19:11:27 <ikke> I can stop the builder and then just try things
2025-03-24 19:11:37 <craftyguy[m]> like, if I could repro it locally, I would jsut try adding flags or whatever to get more info from zig (in theory, maybe), but I wouldn't want to make a lot of noise in aports git for that
2025-03-24 19:12:01 <craftyguy[m]> ok I have a few min right now, let me see if I can come up with some experiment to try 🤷
2025-03-24 19:15:23 <ikke> There seem to be all kinds of --verbose-* options
2025-03-24 19:17:52 <ikke> trying now with --verbose-link and --verbose-cc
2025-03-24 19:17:53 <craftyguy[m]> ya I was trying to look that up, they don't make it easy to find (zig -h goes no where, and zig build -h doesn't work outside the src dir lol)
2025-03-24 19:18:20 <ikke> craftyguy[m]: apparently it's zig build--help
2025-03-24 19:18:45 <ikke> https://ziglang.org/learn/build-system/
2025-03-24 19:18:48 <craftyguy[m]> ya it doesn't work outside a zig src dir... error: no build.zig file found, in the current directory or any parent directories
2025-03-24 19:19:19 <ikke> That's why I looked it up online
2025-03-24 19:19:34 <craftyguy[m]> oh dang, there's no space between build and --help 🙃
2025-03-24 19:20:11 <ikke> yup
2025-03-24 19:20:28 <ikke> https://tpaste.us/waqX
2025-03-24 19:20:30 <ikke> (wall of text)
2025-03-24 19:20:52 <ikke> Not sure if it's a lot more info
2025-03-24 19:21:54 <craftyguy[m]> yeah, there's a lot of noise..
2025-03-24 19:22:25 <ikke> errror: [command] <-lots -of -args>
2025-03-24 19:22:29 <ikke> that's helpful
2025-03-24 19:23:23 <craftyguy[m]> lol
2025-03-24 19:23:41 <craftyguy[m]> I wonder if you can 'fix' it by removing some of the features enabled with zig build args in the apkbuild
2025-03-24 19:23:53 <craftyguy[m]> like, maybe one of those features/things is triggering it
2025-03-24 19:24:09 <ikke> I can try
2025-03-24 19:24:45 <ikke> Seems like that says to use system libraries?
2025-03-24 19:25:13 <craftyguy[m]> oh ya, well maybe we an isolate it to some particular sys lib causing it to fail?
2025-03-24 19:25:18 <ikke> yeah
2025-03-24 19:25:22 <quinq> oh my
2025-03-24 19:25:26 <craftyguy[m]> remove all the --fsys stuff, see if it builds, then add one by one
2025-03-24 19:25:47 <ikke> trying to bisect instead
2025-03-24 19:25:52 <craftyguy[m]> the zig compiler/build system is doing us no favors heh
2025-03-24 19:26:05 <craftyguy[m]> what are you bisecting?
2025-03-24 19:26:16 <ikke> bisecting the build options
2025-03-24 19:26:18 <quinq> zig command lines are ~3 times as long as the portable minimum arg length guarantee
2025-03-24 19:26:21 <ikke> trying halve of them
2025-03-24 19:26:29 <craftyguy[m]> gotcha
2025-03-24 19:27:32 <craftyguy[m]> gotta step away for a few min
2025-03-24 19:32:09 <ikke> craftyguy[m]: even with all -fsys options removed it still fails
2025-03-24 19:43:01 <craftyguy[m]> dang. what about with --release=fast ?
2025-03-24 19:43:36 <ikke> I tried first without that option
2025-03-24 19:43:48 <ikke> But apparently safe is the default
2025-03-24 19:49:51 <ikke> craftyguy[m]: nope, that does not help
2025-03-24 19:53:19 <craftyguy[m]> I see there were some cache dirs that the apkbuild used to clean up, added in 8b9f56b016a3c2b364eec89d84207210d85cda48, but it links to a builder job log stating this fixes an issue there... the log shows the build was successful
2025-03-24 19:55:25 <ikke> craftyguy[m]: yes, but that did not help, and was removed later, after it was already failing on the builder
2025-03-24 19:55:35 <ikke> Or I mean, did not help with this specific build failure
2025-03-24 19:56:09 <ikke> and I already completely nuked that folder
2025-03-24 19:57:22 <craftyguy[m]> ok then I guess the commit is referencing the wrong builder log. did this start happening when the upgrade to support zig 0.14 was merged?
2025-03-24 19:57:47 <fossdd[m]> yes, but at this point i dont think its because of that
2025-03-24 19:58:23 <craftyguy[m]> ok I was just trying to get an idea of the timeline
2025-03-24 20:00:39 <ikke> seems to start failing after it was upgraded: http://dup.pw/alpine/aports/a539d8a08ac2
2025-03-24 20:00:55 <ikke> commit message seems to indicate a rebuild
2025-03-24 20:01:49 <craftyguy[m]> looks like they tagged a 1.1.3 a few hours ago: https://github.com/ghostty-org/ghostty/releases/tag/v1.1.3
2025-03-24 20:02:04 <craftyguy[m]> not sayin' it'll help, but it can't hurt to try it 🤷
2025-03-24 20:02:11 <ikke> yeah, let me try
2025-03-24 20:08:04 <ikke> /home/buildozer/aports/testing/ghostty/src/ghostty-1.1.3/build.zig.zon:2:13: error: expected enum literal 🤨
2025-03-24 20:08:10 <ikke> fails almost immediately
2025-03-24 20:08:32 <craftyguy[m]> this is some quality sw 🤦
2025-03-24 20:09:06 <ikke> https://github.com/ziglang/zig/issues/23104
2025-03-24 20:10:15 <ikke> I'm feeling like disabling ghostty on aarch64
2025-03-24 20:10:45 <fossdd[m]> i'd agree, but its going to be painful how to enable it again
2025-03-24 20:11:07 <fossdd[m]> but yeah if nothing helps, i wont be the one blocking you
2025-03-24 20:11:20 <craftyguy[m]> yeah bummer that the original issue seems to only happen on the builder (this enum thing is maybe reproducible locally?)
2025-03-24 20:11:43 <craftyguy[m]> does the builder use ccache?
2025-03-24 20:12:41 <ikke> craftyguy[m]: no
2025-03-24 20:19:11 <ikke> Just tried rootbld, and it failed there as welol
2025-03-24 20:19:13 <ikke> well
2025-03-24 20:19:21 <ikke> so nothing specific to the builder env iirc
2025-03-24 20:19:21 <craftyguy[m]> locally?
2025-03-24 20:19:26 <ikke> No, on the builder
2025-03-24 20:20:49 <craftyguy[m]> I was trying to learn more about the -Dcpu=baseline thing, like maybe the failure is triggered by that on the builder. the builder has native aarch64 CPUs right?
2025-03-24 20:20:58 <ikke> yesz
2025-03-24 20:21:28 <craftyguy[m]> what flavor of aarch64 cpu? ampere or ?
2025-03-24 20:21:43 <ikke> yup
2025-03-24 20:21:53 <ikke> https://tpaste.us/JN0V 
2025-03-24 20:22:19 <craftyguy[m]> I'll try using rootbld on my (aarch64) laptop, I hadn't tried that..
2025-03-24 20:25:48 <ikke> Are there any dependencies in testing that could affect ghostty?
2025-03-24 20:27:08 <craftyguy[m]> doesn't seem like it, the listed deps in the apkbuild are in main or community
2025-03-24 20:27:38 <craftyguy[m]> wait, gtk4-layer-shell is in testing
2025-03-24 20:28:26 <ikke> Seems like the latest version is available on the mirrors
2025-03-24 20:28:32 <ikke> so not a cause of difference
2025-03-24 20:30:28 <craftyguy[m]> local rootbld worked for me on my laptop. hmm
2025-03-24 20:30:30 <fjdzqoFsDUV2> i remember the ghostty author being on #zig. also i -Dcpu=baseline is disabling the default which is equivalent to explicitly saying -march=native with gcc/clang
2025-03-24 20:30:59 <craftyguy[m]> what if you drop that -Dcpu=baseline thing? might not be what we want to ship, but if it works then maybe that's a clue?
2025-03-24 20:31:05 <fjdzqoFsDUV2> i also can imagine that a new 0.14 zig brings backward incompat changes, and the code must be adopted to it.
2025-03-24 20:31:24 <fjdzqoFsDUV2> if you drop -Dcpu=baseline -then it will compile like -march=native with gcc
2025-03-24 20:31:24 <ikke> craftyguy[m]: I think I tried that, but let me try again
2025-03-24 20:31:26 <craftyguy[m]> ghostty claims to support 0.14
2025-03-24 20:31:31 <fjdzqoFsDUV2> ah. ok.
2025-03-24 20:32:09 <ikke> fjdzqoFsDUV2: is #zig on libera?
2025-03-24 20:32:09 <craftyguy[m]> ya it's probably wrong to drop -Dcpu=baseline in aports, but I was just curious if it 'fixed' the build issue on the builder
2025-03-24 20:32:18 <fjdzqoFsDUV2> yes, definitely
2025-03-24 20:32:47 <fjdzqoFsDUV2> yes. it is on libera
2025-03-24 20:33:17 <craftyguy[m]> FYI ghostty on zip 0.14: https://github.com/ghostty-org/ghostty/issues/5744
2025-03-24 20:33:21 <craftyguy[m]> *zig
2025-03-24 20:56:13 <ikke> atm *crickets* in #zig
2025-03-24 21:01:01 <craftyguy[m]> ya I'm kinda out of ideas
2025-03-24 21:05:05 <ikke> some progress\
2025-03-24 21:05:19 <ikke> it segfaults
2025-03-24 21:19:58 <craftyguy[m]> ohh, how did you find out?
2025-03-24 21:20:50 <ikke> in #zig they mentioned I could run the build command manually, after remove the -listen=- part
2025-03-24 21:21:00 <ikke> (the specific command that fialed)
2025-03-24 21:21:04 <ikke> failed)
2025-03-24 21:21:24 <craftyguy[m]> nice
2025-03-24 21:21:25 <ikke> Need to rebuild zig with debug symbols, probably going to take a while
2025-03-24 21:22:05 <ikke> 21kb command :D
2025-03-24 21:22:34 <craftyguy[m]> should we always build/pkg zig debug symbols, since zig is... uh... still somewhat far below a v1.0 ?
2025-03-24 21:23:02 <ikke> depends on how large they are
2025-03-24 21:23:03 <craftyguy[m]> 
ACTION not sure how often zig bugs/segfaults are found

2025-03-24 21:24:02 <ikke> me neitehr
2025-03-24 21:26:18 <fjdzqoFsDUV2> this is the first time i hear of one. and i have a project in zig, that runs in production.
2025-03-24 21:26:26 <fjdzqoFsDUV2> and i lurk on #zi
2025-03-24 21:26:29 <fjdzqoFsDUV2> g
2025-03-24 21:43:28 <ikke> Seems I need a dbg build of clang
2025-03-24 21:49:16 <khem> be ready to sacrifice multiple 10s of GBs of harddisk :)
2025-03-24 21:55:14 <craftyguy[m]> ouch
2025-03-24 22:37:52 <sertonix[m]> Is there any way to report issues to qemu outside of gitlab.com? I noticed that they are linking s390-ccw.img incorrectly.
2025-03-25 00:01:26 <craftyguy[m]> sertonix: I don't think so... but if you write it up I would be happy to post it for you
2025-03-25 05:30:05 <Saijin_Naib[m]> Anyone want to take on onevpl-intel-gpu from me and maybe move to Community?
2025-03-25 05:30:09 <Saijin_Naib[m]> Same goes for thermald
2025-03-25 06:14:10 <ikke> regarding zig / ghostty: https://tpaste.us/PQmD 
2025-03-25 13:38:51 <fossdd[m]> would be cool if !81207 can get merged
2025-03-25 14:47:00 <craftyguy[m]> ikke: do those ??? Resolve if you install musl-dbg?
2025-03-25 15:15:13 <ikke> craftyguy[m]: i had gdb installed, so that should've pulled it in
2025-03-25 15:22:02 <craftyguy[m]> do the folks on #zig have any other ideas? This seems to be deep inside zig, I have no ideas 😒
2025-03-25 15:24:44 <ikke> They asked me to open a bug report 
2025-03-25 15:24:52 <ikke> Which I still needed to do
2025-03-25 15:25:19 <ikke> craftyguy[m]: it does reproduce in my own lxc container on the same host btw
2025-03-25 15:32:09 <craftyguy[m]> woah, interesting. but we've only been able to reproduce it on that builder, right?
2025-03-25 15:36:58 <ikke> Yes
2025-03-25 15:53:17 <craftyguy[m]> Hmm so it seems like maybe it's the hw/cpu triggering it
2025-03-25 15:55:34 <ikke> Yup
2025-03-25 15:55:44 <ikke> That's my feeling 
2025-03-25 15:56:01 <ikke> CI is running in qemu, so that could mask it 
2025-03-25 16:10:35 <craftyguy[m]> Are the CI runners also ampere systems like the builder?
2025-03-25 16:11:54 <ikke> Yes, but Qemu VMs on such a server 
2025-03-25 16:13:14 <craftyguy[m]> Ya, what cpu param is passed to qemu for those VMs? IIRC there's an option to copy host cpuinfo to the VM, and I wonder if you could repro it in CI if that's set (might be more trouble than it's worth to test that)
2025-03-25 17:03:39 <ikke> craftyguy[m]: -cpu host
2025-03-25 20:23:26 <fossdd[m]> ptrc, uhmm ERROR: lld19-doc-19.1.7-r1: trying to overwrite usr/share/man/man1/ld.lld.1.gz owned by lld-doc-19.1.7-r1.
2025-03-25 20:23:33 <fossdd[m]> apk fix fixes it but its still weird
2025-03-25 21:02:55 <candrew> could someone please merge !79832
2025-03-25 21:03:16 <ptrc> whoops, needs a `replaces=` i guess
2025-03-25 21:07:26 <Saijin_Naib[m]> <Saijin_Naib[m]> "Same goes for thermald" <- Saw a user asking for it in general #_oftc_#alpine-linux:matrix.org chat, and I've been using it for almost five years now in testing and it seems fine
2025-03-25 21:07:44 <Saijin_Naib[m]> Or, is that a main candidate?
2025-03-25 21:08:01 <Saijin_Naib[m]> It being thermald, sorry
2025-03-26 07:30:02 <ncopa> i wonder if we can drop testing/php81. it is in the way for the ICU 76 upgrade
2025-03-26 07:30:23 <ncopa> I have to either spend time on fixing it or we could simply delete it
2025-03-26 07:32:54 <ncopa> andypost[m]: php81 moved from community to testing in April 2024. fd1aef8e84cee43e45146ff45fe3a459fc1edf69 what is the paln for php81?
2025-03-26 07:33:06 <ncopa> the plan*
2025-03-26 10:07:10 <donoban> Hi, qa-bot remembers me that !80404 stills opened
2025-03-26 10:10:45 <donoban> is there any problem with new aports? it looks quite slowly
2025-03-26 10:24:34 <donoban> thx :)
2025-03-26 10:39:23 <lotheac> i've been wondering the same, have a few new aports MRs open for longer than 2 months already...
2025-03-26 10:43:55 <ikke> Personally I'm focusing mostly on making sure existing aports getting updates 
2025-03-26 10:44:17 <ikke> We receive 60-80 MRs a day 
2025-03-26 10:44:56 <lotheac> understandable
2025-03-26 10:45:01 <sam_> you will struggle to find any distro which is established that accepts new packages at the same rate and with the same enthusiasm as work on existing packages
2025-03-26 10:45:05 <sam_> there's a reason for that
2025-03-26 10:45:13 <donoban> ah sorry just wondered if there is some special problem or policy change
2025-03-26 10:48:28 <andypost[m]> ncopa: I gonna drop php81 at the end of security support but if you find it blocker, let's get rid of it
2025-03-26 11:16:50 <f_> Generally there's just *a lot* of MRs that need review
2025-03-26 11:17:04 <f_> and not enough people to review them all quickly
2025-03-26 11:19:24 <ncopa> andypost[m]: i fixed it
2025-03-26 11:21:45 <ncopa> are anyone working on ghostty build failure on aarch64? i think we maybe should just disable aarch64 for now
2025-03-26 11:22:12 <ikke> ncopa: I was busy making a bug report
2025-03-26 11:22:43 <ikke> ncopa: https://tpaste.us/PQmD
2025-03-26 11:22:50 <ncopa> im disabling it for now, til someone is interested enough to pick it up and fix it
2025-03-26 11:22:59 <ikke> yes, that was my idea as well
2025-03-26 11:23:07 <ikke> ncopa: the problem
2025-03-26 11:23:11 <ikke> It does not trigger on CI
2025-03-26 11:32:06 <ikke> craftyguy[m]: it's also reproducable in docker directly on the host
2025-03-26 11:43:26 <lotheac> f_: if so, perhaps alpine needs more developers? :)
2025-03-26 11:45:08 <f_> people reviewing stuff are welcome
2025-03-26 11:47:29 <lotheac> now what exactly would that entail in practice? i could spare some time
2025-03-26 12:38:25 <f_> lotheac: just looking at MRs and spotting mistakes and such
2025-03-26 13:32:17 <lotheac> f_: guess i'm a bit unclear on the specifics. i assume there's a bunch of things you check and i further assume there's a way to record in an MR that it has been thusly checked by someone
2025-03-26 13:32:57 <f_> you really just comment on the MR
2025-03-26 13:33:12 <f_> pointing out things.
2025-03-26 13:33:43 <f_> Mostly all there is to it.
2025-03-26 13:34:04 <lotheac> you're suggesting i can just make LGTM comments on other people's MRs and it will help reduce your workload?
2025-03-26 13:34:39 <lotheac> (well, assuming they _do_ look good to me)
2025-03-26 13:54:28 <f_> You can point out things that might need changing on other people's MRs
2025-03-26 17:30:18 <WhyNotHugo> Any feedback for !80277 ?
2025-03-26 20:02:31 <realroot[m]> how can i use bemenu_
2025-03-26 20:03:54 <realroot[m]> wrong chanel
2025-03-26 20:04:15 <realroot[m]> *room
2025-03-26 20:24:51 <tomalok> hopefully a quck APKBUILD question -- edge build dependency (currently) has a maximum version for go (<1.24), but a version beyond that (1.24.1) is in edge...  is there a way to "borrow" 3.23.1's version when building the edge package?
2025-03-26 20:25:14 <tomalok> s/3.23.1/alpine 3.23/
2025-03-26 20:26:27 <fossdd[m]> if youre building on edge, you can only use edge packages. the better option would be to ask upstream to support go1.24 and backport it, maybe even take a look at it yourself and fix it
2025-03-26 20:30:18 <realroot[m]> will the matrix bridged be stopped?
2025-03-26 20:31:12 <tomalok> thanks.  docker upstream is working on go1.24 support, but is on their docker 29 milestone, not docker 28 which is having problems when built with 1.24
2025-03-26 20:31:15 <realroot[m]> pmOS is making one to replace it isn'it?
2025-03-26 20:42:28 <quinq> ptrc, any time for a webkit update? :>
2025-03-26 20:56:17 <fossdd[m]> * if youre building on edge, you can only use edge packages. the better option would be to ask upstream to support go1.24 and backport it, maybe even take a look at it yourself and fix it
2025-03-26 21:10:17 <ikke> fossdd[m]: this is apparently widespread issue without clear cause yet
2025-03-26 21:10:25 <ikke> (At least when I read the issue)
2025-03-26 21:10:39 <ikke> widespread meaning affecting more than just alpine
2025-03-26 21:17:06 <fossdd[m]> urghh, annoying
2025-03-26 21:18:44 <ikke> absolutely
2025-03-26 21:36:41 <f_> realroot[m]: yes the matrix.org bridge will go down
2025-03-26 21:37:00 <f_> and yes there is a new postmarketOS IRC<>Matrix bridge
2025-03-26 21:37:20 <f_> but no idea if it'll be used for alpine at all
2025-03-26 21:37:36 <f_> first need to ensure it is stable at all :p
2025-03-26 22:41:14 <jahway603> Can someone please merge !81933 and !81932? These are pre-cursor to a CVE release that I'm working on MRs for today.
2025-03-26 22:42:51 <jahway603> or do I close those MRs and just push new MRs with the new release that just was released less than an hour ago? 
2025-03-26 22:42:52 <jahway603> 1.127.1 is out: https://github.com/element-hq/synapse/releases/tag/v1.127.1 (fixes CVE-2025-30355)
2025-03-26 22:44:00 <jahway603> Can you please merge !81932 too?
2025-03-26 22:45:51 <fossdd[m]> you can just amend your commit and force push
2025-03-26 22:46:18 <fossdd[m]> or like that
2025-03-26 22:51:18 <jahway603> Please merge !81977 to fix CVE-2025-30355
2025-03-26 23:02:18 <jahway603> This CVE is actively being exploited
2025-03-26 23:43:43 <jahway603> Federation denial of service via malformed events - Description
2025-03-26 23:43:44 <jahway603> A malicious server can craft events which, when received, prevent Synapse version up to 1.127.0 from federating with other servers. The vulnerability has been exploited in the wild. Fixed in Synapse v1.127.1.
2025-03-26 23:43:44 <jahway603> Impact
2025-03-27 05:06:18 <Ariadne> jahway603: in future you can ping the security team directly in #alpine-security or on gitlab, and we'll fast-track a review for you
2025-03-27 09:13:51 <ncopa> I have spent last 4 weeks on fixing the builds with icu 76, and I have solved almost all now
2025-03-27 09:14:26 <ncopa> those still fails: deno zotero tinyfugue tectonic
2025-03-27 09:16:09 <ncopa> and firefox-esr thunderbird rspamd zim-tools electron
2025-03-27 09:16:31 <ncopa> i wonder if I can just push it, and we solve those breakages as we go?
2025-03-27 09:39:02 <fossdd[m]> makes sense
2025-03-27 10:00:37 <ncopa> im thinking, in worst case we can create an icu74-compat package with the binaries only as intermediate step
2025-03-27 12:02:08 <Kladky> btw, have the alpine maintainers been busier than usual in the last few weeks? Cause I have noticed that many of my recent MRs haven't been merged, despite not having any unresolved threads
2025-03-27 12:09:56 <ncopa> I have been pretty busy, yes. dont know about the others.
2025-03-27 12:10:03 <ncopa> we have alsmot 800 open MRs now
2025-03-27 12:10:30 <ncopa> the process of onboarding new devs is too slow
2025-03-27 12:10:51 <ikke> I've been mostly focussing on getting the trivial package upgrades merged
2025-03-27 12:17:44 <realroot[m]> will alpine use pmOS bridge? i hope that some bridge will exist
2025-03-27 12:21:03 <Kladky> what even is the process of onboarding new devs anyways?
2025-03-27 12:21:38 <ikke> Kladky: Someone proposes it to the TSC, the tsc discusses it at the next meeting
2025-03-27 12:21:55 <qaqland> another reason: the number of package is growing
2025-03-27 12:21:56 <ikke> before that, it helps to already be active in aports, show that you know how everything works
2025-03-27 12:22:57 <ncopa> im pushing icu-76 now
2025-03-27 12:23:12 <ncopa> will break a few things
2025-03-27 12:23:18 <ikke> 
ACTION sits tight

2025-03-27 12:23:21 <Kladky> TSC?
2025-03-27 12:23:32 <ncopa> technical steering commitee
2025-03-27 12:23:39 <qaqland> https://gitlab.alpinelinux.org/alpine/tsc
2025-03-27 12:24:03 <Kladky> Ah, right
2025-03-27 12:30:25 <Kladky> Maybe it might help to set some minimum requirements to become a "developer", so that it's not just done as one-offs, but instead more systematic
2025-03-27 12:31:14 <Kladky> Then every few meetings you can consider all developers that meet those requirements, and see if any of them should be added
2025-03-27 16:11:26 <durrendal> can someone volunteer to be considered for the developer role? Or I suppose, has anyone done this in the past?
2025-03-27 16:18:57 <ikke> durrendal: someone can certainly indicate that they are interested to be a developer
2025-03-27 16:20:25 <durrendal> well you know me ikke I'm always happy to help out :) and with ~200 package under my belt I could make a good argument for knowing how to do it at this point
2025-03-27 16:22:47 <ikke> ack
2025-03-27 16:24:49 <durrendal> thanks :) no expectations, but if you're considering people to help out, I am certainly willing to put my name on the list to be considered. I'll keep contributing regardless
2025-03-27 17:07:18 <ikke> One concern is security when you have a single system that has access to all your infra
2025-03-27 19:32:34 <ptrc> ncopa: is the firefox-esr build failure log posted somewhere? can't seem to find it
2025-03-27 19:32:48 <ptrc> quinq: good point! i'll try to push a MR today
2025-03-27 19:33:01 <ikke> ptrc: I think ncopa built it locally
2025-03-27 19:33:35 <ptrc> ah, hm
2025-03-27 19:33:56 <ptrc> though since the ICU upgrade is pushed, i can just test it locally
2025-03-27 19:34:06 <ptrc> ( if it's built for x86_64, that is )
2025-03-27 19:34:18 <ikke> yeah, x86_64 finished uploading main
2025-03-27 19:34:23 <ptrc> nice ^^
2025-03-27 19:34:30 <ptrc> then yeah, i'll try to check it out
2025-03-27 20:58:09 <jesse6> Hello. Is there a requirement for a Linux ELF executable (like sections) to run on Alpine? I have ones that I made myself, but all of them just 'seg fault' and crashes.
2025-03-27 20:59:00 <jesse6> One important thing is that I strip out a lot of sections from my executables (i.e., exterminate all GNUs in the file :D)...
2025-03-27 20:59:40 <jesse6> They work in all distros, except Alpine. But I think this time is not glibc the problem.
2025-03-27 21:00:27 <jesse6> One as simple as just importing `puts()` also crashes as mentioned above.
2025-03-27 21:02:53 <skarnet> glibc may not be the problem, but the path to your dynamic linker probably is.
2025-03-27 21:03:35 <skarnet> also, if you strip the .note.GNU-stack section, your binaries will run with an executable stack, which is not what you generally want.
2025-03-27 21:04:45 <jesse6> Thanks, I'll check this.
2025-03-27 21:06:00 <skarnet> for musl the linker is named /lib/ld-musl-${arch}.so.1
2025-03-27 21:06:08 <skarnet> that's the interp you want in your binaries
2025-03-27 21:06:19 <jesse6> Linking with 'ld' instead of gcc (and, by then, without a main() entry, using _start instead) could do trouble too?
2025-03-27 21:07:03 <jesse6> @skarnet, cool. Thanks, I probably will recompile them inside Alpine using their linker and then give feedback to you.
2025-03-27 21:07:59 <skarnet> unless you're making purely static binaries (which, if you're concerned about dumping them on any machine regardless of the distro and have them work, you should), skipping the C runtime isn't going to get you as much a win as you think it is.
2025-03-27 21:09:25 <skarnet> I get doing it for the sport and because it's fun to see small numbers (I've done that too), but if your concern is getting things to work, don't try to be too smart, just use the regular gcc compiler/linker driver, the Alpine toolchain was made to work with musl.
2025-03-27 21:09:36 <jesse6> Nope, I'm doing only PIEs. I stop doing static addressed ones as soon as I got PIE to work properly.
2025-03-27 21:10:54 <jesse6> I usually code pure assembly, hence why I prefer link with ld instead of gcc. But, sometimes, I do the complete task, by writing a main() function as entry point.
2025-03-27 21:14:00 <jesse6> Thanks for the help!
2025-03-27 21:15:18 <skarnet> gl!
2025-03-27 22:22:12 <humm> you can use assembly language and still use libc
2025-03-27 22:56:06 <jesse6> Yup, I do it. Easy. Algo GTK. But here, my problem is truly the dynamic linker. It is ld-linux...so.2, and I should change it to ...so.1.
2025-03-27 22:56:56 <jesse6> See you soon. Goin' to gym...
2025-03-28 01:30:34 <Ariadne> what jesse6 is looking for is -static-pie for the record
2025-03-28 01:30:36 <Ariadne> should he return
2025-03-28 01:36:46 <anjan> Hey, can someone please help me fix this issue? https://gitlab.alpinelinux.org/anjandev/aports/-/jobs/1786355
2025-03-28 04:47:09 <anjan> https://pkgs.alpinelinux.org/package/edge/testing/x86_64/snikket-sdk
2025-03-28 04:47:15 <anjan> this package is supposed to provide it
2025-03-28 05:50:09 <ikke> anjan: did you already found it?
2025-03-28 05:55:46 <ikke> anjan: I think the problem is that it contains an absolute reference to the library
2025-03-28 05:56:25 <ikke> https://tpaste.us/VYmJ
2025-03-28 08:01:40 <Saijin_Naib[m]> is Kevin Dault in here? I put a MR to update rtl8821ce-src since it finally builds against 6.12+ kernel, and has been broken since linux-lts switched off 6.6
2025-03-28 08:01:50 <Saijin_Naib[m]> !82037
2025-03-28 08:02:03 <Saijin_Naib[m]> I would love to get their review and hopefully a merge
2025-03-28 08:03:24 <Saijin_Naib[m]> Oh, crafty GitLab assigned them already
2025-03-28 08:17:54 <f_> Saijin_Naib[m]: Kevin is ikke
2025-03-28 10:26:44 <streampunk> Could somebody check if this is mergeable? I rebased it a moment ago to make sure there are not conflicts. https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/80633
2025-03-28 11:22:24 <ikke> streampunk: the new package should be a separate commit
2025-03-28 11:23:49 <ikke> Saijin_Naib[m]: have you tested the module?
2025-03-28 11:42:34 <Saijin_Naib[m]> <ikke> "Saijin_Naib: have you tested the..." <- Going to shortly, but prior to 6.12, I used this package on my two craptops, so historically, very useful
2025-03-28 11:42:42 <ikke> Saijin_Naib[m]: good to know
2025-03-28 11:42:58 <ikke> Saijin_Naib[m]: After you verified this, I can move it to community then
2025-03-28 12:01:16 <Saijin_Naib[m]> Doubles uplink/downlink speeds at least, way more stable connections, better RSSI
2025-03-28 12:01:28 <Saijin_Naib[m]> in-kernel module is basically unusable on the rtl8821ce
2025-03-28 12:28:54 <streampunk> Thanks, ikke I split the commit. Now it tries to link against so:libicuuc.so.74, while so:libicuuc.so.76 is current. But re2 has been rebuilt with so:libicuuc.so.76. How do you debug this problem?
2025-03-28 12:28:54 <streampunk> https://gitlab.alpinelinux.org/rhizoome/aports/-/jobs/1786704#L486
2025-03-28 12:29:43 <ikke> streampunk: the builders are still working on rebuilding community 
2025-03-28 12:31:26 <streampunk> I see. Thanks, I'll retrigger the build later.
2025-03-28 12:32:53 <Ermine> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/testing/rustdesk-server/cargo.lock.patch --- does one need to shuffle dep versions like this in rust packages?
2025-03-28 13:13:31 <Kladky> Q: when enabling a subpackage for a specific arch, does that need a pkgrel bump? (see !82018 for more info)
2025-03-28 13:23:06 <streampunk> kladky as far as I know, only a change in pkgver or pkgrel will trigger a build by the builders.
2025-03-28 13:24:03 <streampunk> https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package#pkgrel
2025-03-28 13:25:02 <Kladky> That link mentions for changing an existing package.
2025-03-28 13:25:20 <Kladky> The thing is that rust-wasm hasn't been built for s390x yet
2025-03-28 13:26:14 <Kladky> And from my understanding, when enabling a pacakge for an arch, unless you change something which effects other arches, you don't need to bump pkgrel
2025-03-28 13:39:30 <streampunk> kladky yes you are right. 
2025-03-28 13:39:30 <streampunk> https://gitlab.alpinelinux.org/rhizoome/aports/-/commit/bf1148632309c46dc2720b588a77b4bb7fd63977
2025-03-28 13:40:21 <Kladky> The thing is I'm not sure whether that also applies for subpackages.
2025-03-28 14:15:32 <streampunk> kladky at least lua-aports does check subpackages. and the builders seem to be using buildrepo from lua-aports. so it seems you do not need to increment pkgrel even for subpackages.
2025-03-28 14:15:32 <streampunk> https://gitlab.alpinelinux.org/alpine/lua-aports/-/blob/master/aports/pkg.lua#L75
2025-03-28 14:15:32 <streampunk> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/aports-build/aports-build
2025-03-28 14:33:16 <ikke> Kladky: yes, it must
2025-03-28 14:33:44 <ikke> Enabling a subpackage causes the package to be rebuilt 
2025-03-28 14:34:11 <Kladky> So I do need to bump the pkgrel?
2025-03-28 14:34:16 <ikke> And causes signature issues on the cdn if pkgrel is not bumped 
2025-03-28 14:34:19 <ikke> Yes
2025-03-28 14:34:24 <Kladky> Ok, thanks
2025-03-28 15:05:06 <Saijin_Naib[m]> ikke!82037 seems to work just fine thus far
2025-03-28 15:05:48 <Saijin_Naib[m]> I'm not sure if packaging rtw88/rtw89 into Community instead of hardware-specific src aports might not be better...
2025-03-28 15:05:53 <Saijin_Naib[m]> But I don't think it is setup for AKMS easily
2025-03-28 18:41:03 <Eighth_Doctor> hey folks, since there doesn't seem to be an apk-tools 3.0 release in sight, how bad would it be if I packaged 3.0~rc4 or the current HEAD for Fedora?
2025-03-28 20:05:14 <Ariadne> Eighth_Doctor: you want #apk-tools for that
2025-03-28 20:05:22 <Eighth_Doctor> ah okay
2025-03-28 20:05:53 <Eighth_Doctor> !join #oftc#apk-tools:matrix.org
2025-03-29 02:12:04 <jesse6> Hello...
2025-03-29 02:13:40 <jesse6> About the ELF executable crashes, I found something: apparently, I can use strip command with options: `-R eh_frame --strip-unneeded` and the executable works perfectly file in Alpine.
2025-03-29 02:14:51 <jesse6> So, no problem with de dynamic linker at all. I still keep ld-linux-x86-64.so.2, because I found it on my Alpine instalations.
2025-03-29 02:22:50 <jesse6> Also, I think the "seg fault" problem is related to '.comment', '.gnu.version', '.hash', and/or '.gnu.hash' sections then...
2025-03-29 02:31:34 <jesse6> Ah, yes, I almost forgot: still using entry _start direct instead of main(). I can't resist gaining one less stack frame creation procedure advantage against C programs! 😍 Among other things... 
2025-03-29 08:25:00 <maribu> Hi. I'm running regularly in compilation errors with GCC 14 starting to ignore #include_next with -std=c99, forcing to add -std=gnu99 instead. In most cases it is string.h from the fortify headers. So far I patched the package to use -std=gnu99 instead. I wonder if there is a more scalable approach.
2025-03-29 08:28:15 <maribu> What would IMO be ideal would be some way to override compiler settings akin to `#pragma diagnostics push`, `#pragma diagnostics <modification>`, `<evil piece of code>`, `#pragma diagnostics pop`. Is someone aware whether such a modifier exists to enable C extensions from within C?
2025-03-29 08:28:38 <maribu> I'm aware of __extension__, but I read the doc as this just disables pedantic warnings.
2025-03-29 10:23:33 <sertonix[m]> Can someone merge !82017 please?
2025-03-29 10:47:12 <Kladky> Could someone take a look at !81711 please? Ik the maintainer hasn't responsed, but they seem ot be slow to respond in general, and this is just a simple minor depdendency bump to get building grammars working again (which is very important, considering that current helix grammars we ship are borked)
2025-03-29 10:47:32 <Kladky> s/ot/to
2025-03-29 11:34:02 <ikke> rustc single-thread on a banapi f3 🥲
2025-03-29 12:32:42 <f_> Hope you're having lots of fun ikke
2025-03-29 12:34:07 <ikke> f_: I do
2025-03-29 12:34:20 <ikke> But CI was struggling a bit
2025-03-29 12:35:07 <f_> CI not as happy it seems
2025-03-29 12:36:47 <f_> 
ACTION pats CI a bit

2025-03-29 15:34:35 <Kladky> Btw, will Alpine switch to the monthly releases of Thunderbird, since that is now the default? 
2025-03-29 15:34:55 <Kladky> There was a release on the 5th
2025-03-29 15:36:31 <Kladky> cc ptrc 
2025-03-29 17:46:54 <fossdd[m]> can someone take a look at !80946?
2025-03-29 21:59:04 <ptrc> Kladky: yeah, i've been planning to switch to the release channel for a while now, but it was way easier to keep it on esr ^^;
2025-03-29 21:59:13 <ptrc> s/easier/less work for me/
2025-03-30 02:30:27 <anjan> ikke: do you know how I can make it a relative library?
2025-03-30 02:30:30 <anjan> I think you are right
2025-03-30 05:26:31 <ikke> anjan: no, not really
2025-03-30 12:31:01 <streampunk> ikke is there a workaround to continue developing when something like the icu update happens? all by dabuild calls break with libicu* conflics?
2025-03-30 12:31:18 <ikke> streampunk: not really, but it should be fixed now
2025-03-30 12:54:55 <streampunk> ikke I see now it is a libxml2 rebuild that is in the way, not libicu anymore... bad luck.
2025-03-30 12:55:07 <ikke> yup, I'm working on that
2025-03-30 12:56:08 <streampunk> ikke thanks!!
2025-03-30 14:27:57 <fazalmajid> What was the reason for reverting libxml2, the commit message didn't specify other than a terse "the world is not ready for this yet :("? I've encountered issues like this one: https://jira.mariadb.org/browse/MDEV-36427, but they are easily worked around.
2025-03-30 14:29:31 <ikke> gettext is failing as well
2025-03-30 14:29:41 <ikke> and possibly others
2025-03-30 14:29:50 <fazalmajid> Because of libxml2 or ICU?
2025-03-30 14:29:55 <ikke> libxml2
2025-03-30 14:30:00 <fazalmajid> Wow!
2025-03-30 14:30:39 <ikke> https://savannah.gnu.org/bugs/?66960
2025-03-30 14:32:07 <fazalmajid> Leading to this, which seems prett bad: https://gitlab.gnome.org/GNOME/libxml2/-/issues/884
2025-03-30 14:32:27 <fazalmajid> (insert 5 minutes of hate for XML here)
2025-03-30 14:32:31 <ikke> My impression of libxml gets worse with every upgrade
2025-03-30 14:32:35 <ikke> libxml2
2025-03-30 14:32:42 <ikke> Lots of breakages
2025-03-30 14:32:49 <fazalmajid> And SEVs
2025-03-30 14:32:58 <fazalmajid> Sorry, CVEs
2025-03-30 14:33:34 <fazalmajid> Thanks for dealing with the fallout, specially on a weekend!
2025-03-30 14:46:37 <ptrc> fazalmajid: yeah, sorry for the lacking message, it was late in the night and i realized i made a big mistake by merging it prematurely
2025-03-30 14:47:44 <ptrc> and looking at history of libxml2, the first release is usually followed up by a bunch of bug reports from downstream users
2025-03-30 14:47:46 <fazalmajid> No worries, I build my own stack from source and didn't encounter any build issues other than that MariaDB one, but then again if it's a silent data loss, as I don't use XML much other than RSS feed reading, I would not have noticed.
2025-03-30 14:48:10 <fazalmajid> Maybe I need to add unit tests for that
2025-03-30 14:48:37 <fazalmajid> But XML is such a convoluted standard with dark corners like XXEs that building a decent test suite is a non-trivial effort.
2025-03-30 14:51:12 <fossdd[m]> oh wow i didnt realise that it had a different abi. i wonder why i didnt notice it earlier
2025-03-30 14:52:02 <fossdd[m]> i think now that checkapk runs in abump that this shouldnt happen that easy again
2025-03-30 14:52:12 <fossdd[m]> but thanks for taking care of it! <3
2025-03-30 16:12:56 <invoked> what's going on with signal-desktop/electron/icu? feels like this stuff has been broken for a while
2025-03-30 16:13:04 <invoked> i can't really discern anything in gitlab
2025-03-30 16:13:52 <ikke> icu has been updated
2025-03-30 16:14:08 <ikke> electron needs to be rebuilt, which is still in the queue
2025-03-30 16:14:19 <invoked> ah. roger that. thanks
2025-03-30 16:24:10 <rhizoome> ikke current electron failed to build on dabuild. I locally built https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/82106
2025-03-30 16:26:11 <rhizoome> oh, 35.1.2 failed too...
2025-03-30 16:29:43 <rhizoome> electron 34 (current) fails with ld.lld: error: undefined symbol: icu_76::UnicodeString::doAppend(
2025-03-30 16:30:21 <rhizoome> I try to update the containers again, maybe it was bad timing.
2025-03-30 16:33:48 <mio> electron 34 at the moment is incompatible with icu 76, there's a bug report link in the electron with bundled icu MR with more details
2025-03-30 16:34:17 <mio> maintainer is working on the aport
2025-03-30 16:35:08 <mio> https://bugs.gentoo.org/943216
2025-03-30 16:35:55 <ikke> We first need to make sure main is fixed anyway
2025-03-30 16:36:14 <mio> yes
2025-03-30 16:38:36 <mio> was just replying to the UnicodeString error mentioned
2025-03-30 17:39:36 <rhizoome> I now sync all x86_64 repos and take snapshots, so I can revert if needed.
2025-03-30 21:14:46 <ptrc> hm, a silly issue: a lot of packages try to use the user's supplemental groups to do tests on stuff that involves changing ownership
2025-03-30 21:15:10 <ptrc> but, bwrap / rootbld makes them all 65534(nobody)
2025-03-30 21:15:15 <ptrc> and everything fails
2025-03-30 21:15:16 <ptrc> :/
2025-03-30 22:13:09 <skarnet> supplementary groups, the red-headed stepchild of Unix permissions. Everyone always forgets they exist, and they get left out of every hack :/
2025-03-31 05:54:05 <moha-al> Hi! I'm currently working on MRs for the llvm packages and have repeatedly seen the riscv64 build (of a single package) time out, even after increasing the CI/CD timeout of my fork to 10 hours (e.g. https://gitlab.alpinelinux.org/moha/aports/-/jobs/1785142). Is that expected?
2025-03-31 08:03:23 <f_> mmhmm looks like a lot of packages fail to build because of libxml2
2025-03-31 08:04:04 <f_> do the builders have some sort of priority thing where it'll prioritise deps before building packages that depend on them?
2025-03-31 08:04:17 <f_> e.g. google-cloud-cpp failed because libxml2 was not built yet
2025-03-31 08:05:23 <psykose> no, it's because all of main/ that depends on libxml needs to be rebuilt again
2025-03-31 08:08:56 <f_> ah, oof :/
2025-03-31 08:12:23 <psykose> it would also have to be done after getting riscv and armhf to upload unless people want to rebuild it an extra time after that too :-)
2025-03-31 08:13:51 <ikke> gettext on armhf is broken 
2025-03-31 08:14:27 <ikke> riscv64 might probably not even be affected 
2025-03-31 08:14:39 <ikke> It never saw the libxml2 upgrade 
2025-03-31 08:15:52 <psykose> it might have been built into packages/ at some point, would have to check
2025-03-31 08:16:00 <psykose> the uploaded to repo part doesn't matter
2025-03-31 08:16:19 <psykose> if not there then that saves some waiting
2025-03-31 08:17:57 <ikke> The builder was AWOL before the weekend 
2025-03-31 08:18:08 <ikke> Has just been restarted
2025-03-31 08:21:10 <psykose> nice then'
2025-03-31 08:25:01 <PureTryOut> has the rebuild for libxml2 not happened yet for main? build.a.o is working on community but is that because it's done with the rebuild in main already or because it hasn't been submitted yet?
2025-03-31 08:29:18 <ikke> PureTryOut: it has, but on some arches the rebuilds happened in the wrong order for some reason 
2025-03-31 08:30:39 <psykose> it's because there was an upgrade+rebuild then a downgrade+rebuild before it uploaded
2025-03-31 08:31:05 <psykose> non-repo version only gets deleted from packages/ at the end of a run so it just builds everything against the newer one anyway
2025-03-31 08:31:20 <psykose> downgrade+rebuild always takes two steps
2025-03-31 08:37:19 <ikke> Well, we did add constraints to make sure the downgraded version was picked
2025-03-31 08:38:20 <psykose> ah nice
2025-03-31 08:38:27 <psykose> do you have a link to the commit
2025-03-31 08:39:04 <ikke> Multiple commits, search for 'force libxml2'
2025-03-31 08:39:48 <psykose> it misses stuff like llvm in those
2025-03-31 08:40:46 <psykose> yeah everything that is currently `apk list -d so:libxml2.so.16` wasn't in those commits
2025-03-31 08:40:47 <psykose> i think
2025-03-31 08:41:13 <andypost[m]> yep, looks like llvm19 need the same 6e45fa13d0c6ec0dfd4c23ca5158db62c811d0e8
2025-03-31 08:41:38 <psykose> so yeah it's what i said, same old two-stage requirement (or versions in every makedepend)
2025-03-31 08:43:41 <psykose> when you said added constraints i thought you meant some buildrepo fix haha
2025-03-31 09:04:31 <qaqland> mesonlsp was archived https://github.com/JCWasmx86/mesonlsp
2025-03-31 09:52:55 <qaqland> https://pkgs.alpinelinux.org/contents?file=libxml2.so.16&path=&name=&branch=edge&repo=&arch=
2025-03-31 09:53:19 <qaqland> only armhf has libxml2.so.16, is this related to the recent rebuild?
2025-03-31 09:53:50 <qaqland> oh, i see
2025-03-31 10:49:31 <kpcyrd> is there something I can do to help with https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/80090 ? :)
2025-03-31 12:37:56 <rhizoome> qaqland: yes, libxml2 update related rebuild are still running on many archs.
2025-03-31 12:44:47 <rhizoome> actually the revert of it.
2025-03-31 13:04:22 <sigirneg2>  How do I find the offending package when I get "ERROR: unable to select packages" in apk?
2025-03-31 13:04:35 <sigirneg2> >required by: llvm19-libs-19.1.7-r4[so:libxml2.so.16]
2025-03-31 13:04:44 <sigirneg2>  apk info -r llvm19-libs returns nothing
2025-03-31 13:08:31 <rhizoome> sigirneg2: I think you got it. For a time builders would work on switching from libxml2.so.2 to libxml2.so.16. But it was reverted. So packages still wanting libxml2.so.16 where not rebuilt yet after the revert.
2025-03-31 13:09:06 <andypost[m]> it's rebuilding now
2025-03-31 13:09:57 <ikke> It's the opposite, the upgrade has been reverted 
2025-03-31 13:11:19 <rhizoome> ikke thats what I am saying. libxml2.so.2 is the old one. And many pacakges where rebuilt using libxml2.so.16 (the new one). we are working on fixing these pacakges right?
2025-03-31 13:11:55 <rhizoome> currently there is no libxml2.so.16, but many packages that where built with .16.
2025-03-31 13:12:41 <rhizoome> for example: https://pkgs.alpinelinux.org/package/edge/main/x86_64/llvm19-libs
2025-03-31 13:12:56 <andypost[m]> I mean llvm19 which I just bumped
2025-03-31 13:15:31 <rhizoome> yes, many was wrong, It is actually mostly llvm19.
2025-03-31 13:15:49 <ikke> Rh
2025-03-31 13:16:29 <ikke> rhizoome: an attempt was already made, but the timing meant they were still built against the newer version
2025-03-31 13:20:35 <rhizoome> ikke maybe it helps, here the way different archs are broken https://gist.github.com/rhizoome/39a789fa608c0dde90f95ccb62e4373c
2025-03-31 13:20:54 <rhizoome> based on this build: https://gitlab.alpinelinux.org/rhizoome/aports/-/pipelines/311500 (I retried everything an hour ago)
2025-03-31 13:24:23 <sigirneg2> Is there a way to find out which packages in my system depend on libxml2.so.16?
2025-03-31 13:25:51 <rhizoome> sigirneg2: I think the list apk gives you should be complete.
2025-03-31 13:26:24 <rhizoome> required by: ...
2025-03-31 13:27:25 <rhizoome> sigirneg2: try again after llvm19 has been rebuilt.
2025-03-31 13:27:54 <sigirneg2> The thing is they're not in world, and apk info --rdepends says nothing
2025-03-31 13:30:18 <rhizoome> sigirneg2: it works here, maybe because your world is broken? apk info --force-broken-world --rdepends llvm19-libs
2025-03-31 13:30:21 <sigirneg2> For instance there's bind-libs, apk info --rdepends bind-libs says nothing. If I remove bind-tools it disappears from the list. With llvm I odn't know what packages to remove. I tried bisecting but there must be multiple packages in world that depend on it
2025-03-31 13:31:14 <ikke> apk list --depends so:libxml2.so.16
2025-03-31 13:31:37 <ikke> Though that does not limit to installed packages
2025-03-31 13:32:14 <ikke> You can add --installed
2025-03-31 13:33:22 <sigirneg2> It doesn't seem to check transitive dependencies, and I trasversed all the tree and found nothing
2025-03-31 13:34:19 <sigirneg2> This is an apkovl install running edge, fwiw. I think that's not supported. i run into problems often
2025-03-31 13:35:26 <sigirneg2> --flrce-broken-world doesn't change anything
2025-03-31 13:37:14 <sigirneg2> I have no idea what could depend on llvm19-libs, I removed build-base and all compilers but still have this problem
2025-03-31 13:38:02 <sigirneg2> I will check pkgs.alpinelinux.org
2025-03-31 13:39:24 <rhizoome> sigirneg2: that is very strange. here my local output https://gist.github.com/rhizoome/0c31895b287273fb2a3e950806fbb27a so you can fix things. maybe it will work again when you world isn't broken anymore.
2025-03-31 13:43:37 <sigirneg2> Must be some mesa or qt6 thing, but my world is too big to check by hand. apk list and info don't show the same info as pkgs.alpinelinux.org for some reason
2025-03-31 13:44:39 <sigirneg2> apk update --no-cache is enough to get the latest repo right?
2025-03-31 13:46:45 <rhizoome> sigirneg2: apk update alone should be enough. are you using a mirror? maybe it is delayed.
2025-03-31 13:58:44 <sigirneg3> okay it's fixed now. bind-tools was the culprit, but I had to upgrade with --no-cache.
2025-03-31 13:59:24 <sigirneg3> thank you
2025-03-31 14:35:36 <qaqland> hope the gitlab-bot would show the soname and other changes in MR
2025-03-31 15:50:36 <fabricionaweb> electron is failing because of `libicui18n.so.74` I think it needs to rebuild again now that we have icu76 
2025-03-31 15:51:14 <ncopa> yes it does
2025-03-31 15:51:29 <ncopa> i just did not have time to fix the build. electron is a huge package
2025-03-31 15:52:18 <ncopa> or let me put it this way: i spent 3-4 weeks fixing all icu 76 issues, and then realized that it would never get merged unless I just did it and asked for help handling the breakages it caused
2025-03-31 15:52:37 <ncopa> but we have other more serious problem
2025-03-31 15:52:44 <ncopa>   so:libxml2.so.16 (no such package):
2025-03-31 15:52:49 <ncopa> something happened to libxml2
2025-03-31 15:53:00 <mio> fabricionaweb: maintainer is working on it
2025-03-31 15:53:04 <fabricionaweb> oh, this sounds bad, sorry for bother
2025-03-31 15:53:16 <ncopa> no worries
2025-03-31 15:54:41 <mio> fabricionaweb: it has a build error with icu 76, maintainer is working on fixing it, but added that it's in testing/, the builders still need to clear community/ first (blocked on deno)
2025-03-31 15:55:37 <mio> in the meantime also libxml2 rebuilding against the older version for main/ to be in good shape across arches
2025-03-31 15:56:06 <mio> s/libxml2// s/older version/older version of libxml2/
2025-03-31 15:56:28 <mio> armv7 is okay now, so slowly clearing
2025-03-31 15:56:40 <mio> it's been worked on over the weekend
2025-03-31 15:56:51 <ncopa> thank you mio <3
2025-03-31 15:57:08 <ncopa> i have a bump of abuild coming up
2025-03-31 15:57:28 <ncopa> but i wonder if I should wait a bit til the builders are ok before I introduce more breakages...
2025-03-31 15:57:32 <mio> not just me, others were working to clear as well, it's thanks to ikke and ptrc too
2025-03-31 15:58:22 <mio> also andypost[m] taking the next "shift" ... still working to clear, sorry it's going a bit slowly
2025-03-31 16:01:48 <fabricionaweb> thanks everyone for the hard work, I can image is a bit stressful, I wish I could help more
2025-03-31 16:17:02 <elagost> how can I set different arches for a subpackage? setting arch= in a subpackage function tells me to use 'subpackages=pkg:split:arch' instead but I'm not sure what that means.
2025-03-31 16:20:30 <ikke> elagost: you need to set it in the subpackages global variable 
2025-03-31 16:21:29 <ikke> subpackges="foo::noarch" for example 
2025-03-31 16:25:24 <elagost> oh ok, thank you.
2025-03-31 20:28:29 <amf3> Hello everyone,

2025-03-31 20:28:29 <amf3> I’m new here and looking for some guidance. I recently noticed an issue with the cloud-init defaults in Alpine Linux and submitted an MR with a potential fix. However, I’m unsure about the next steps for getting feedback.

2025-03-31 20:28:29 <amf3>  
2025-03-31 20:28:29 <amf3> I noticed that the community/cloud-init/APKBUILD maintainer field is empty, and from the history, it looks like the previous maintainer moved to contributor status. Given that, what’s the best way to get input on my MR?  https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/82091
2025-03-31 20:28:29 <amf3>  
2025-03-31 20:28:31 <amf3> I appreciate any advice you can share. Thanks!
2025-03-31 20:28:31 <amf3>  
2025-03-31 20:31:25 <fossdd[m]> given that i worked on it some time ago (!76346) i left a quick review
2025-03-31 20:32:48 <amf3> Awesome. Thank you. I'll take a look.
2025-03-31 20:44:52 <amf3> Hopefully my last update to the MR answered the question.  A second related question I have is how do we get the maintainer field populated?
2025-03-31 22:08:20 <amf3> @fossdd thanks for helping with the MR I opened. For the empty maintainer field, I created a new issue. https://gitlab.alpinelinux.org/alpine/aports/-/issues/17049 I'm traveling and need to drop off IRC. I'll keep an eye on the MR & new issue until later.