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>)