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