#archlinux32 | Logs for 2024-01-01
Back
[02:45:50] -!- epony has quit [Remote host closed the connection]
[02:47:53] -!- epony has joined #archlinux32
[10:39:37] -!- n0tiz has quit [Quit: Bye]
[10:41:14] -!- n0tiz has joined #archlinux32
[13:32:09] -!- Hobbyboy has quit [Quit: The BNC has broken!]
[13:35:36] -!- Hobbyboy has joined #archlinux32
[13:55:18] -!- epony has quit [Quit: QUIT]
[16:32:25] mavicaway is now known as mavica
[18:15:51] <mavica> i'm having a nagging issue i can't find a solution for anywhere... i've set up notification bells to play a sound over pipewire instead of the pcspeaker and that works just fine -- from the second time and forward. the first notif is always a loud pcspeaker beep
[18:16:48] <mavica> my xinitrc is in charge of starting pipewire for me and playing boot sound with aplay which works fine. i also tried adding rmmod pcspkr and snd_pcsp on that xinitrc. but the problem persists
[18:39:16] -!- epony has joined #archlinux32
[18:53:02] <KillerWasp> mavica: what graphic desktop you're use?
[18:53:45] <mavica> uhh, i'm using windowmaker that gets executed by xinitrc which i think means i technically "don't" have a DE?
[18:54:21] <mavica> the notifs are through libpipewire-module-x11-bell loaded into pactl
[18:56:12] <mavica> when a bell is played the first time each session both the bell.oga freedesktop sound _and_ pcspeaker beep play. from second bell onwards it's only the bell.oga
[18:56:30] <mavica> so the module is working, it's just that it takes once for the system to realize not to use pcspeaker
[18:57:02] <mavica> and... i can't find anyone with a similar issue online
[18:58:39] <KillerWasp> windowmaker is a window manager (WM)
[18:59:18] <KillerWasp> much of them is like a backend of DE
[19:01:04] <KillerWasp> i never touch of windowmaker, but your problem is like a multiple context, like each program have different configuration of audio, poionter of mouse, keyboard settings, etc
[19:01:21] <KillerWasp> pointer*
[19:02:45] <KillerWasp> and a mix of it can give strange behaviors
[19:03:56] <KillerWasp> even if you configure from WM it remains partially configured even if you restart it.
[19:07:17] <KillerWasp> I never found the solution, all you have to do is report the problem to the WM community and wait for them to update it.
[19:09:00] <KillerWasp> I speculate that mixing xlib with wayland causes conflicts, but I better not say anything. :|
[19:19:55] <mavica> i don't think windowmaker has any bearing on the bell
[19:20:10] <mavica> and i'm not sure i have a shred of wayland in this system, at least not intentionally
[19:20:36] <mavica> i think i can reproduce the bell without any graphical system by manually loading pipewire in a tty
[19:21:57] <mavica> from what i understand libcanberra is what replaces bell with audio, it is called upon by loading the appropriate module into pulseaudio which controls/meshes with pipewire
[19:21:58] <KitsuWhooa> You need to unload pcspkr
[19:22:13] <mavica> that's what i thought i was doing...
[19:22:30] <KitsuWhooa> sudo modprobe -r pcspkr
[19:23:27] <mavica> so, somehow that's not being run by xinitrc
[19:23:38] <KitsuWhooa> You don't want to put that there
[19:23:52] <KitsuWhooa> you probably want to blacklist it
[19:23:52] <mavica> then where
[19:24:10] <KitsuWhooa> /etc/modprobe.conf.d
[19:24:14] <KitsuWhooa> If I remember correctly
[19:24:17] <mavica> is there a solution that will keep it until i don't need it, rather than excommunicating it entirely
[19:24:24] <mavica> i.e. only until i start x
[19:24:32] <KitsuWhooa> That prevents it from loading automatically
[19:24:39] <KitsuWhooa> You can still modprobe pcspkr
[19:24:59] <mavica> i want to not have to manually load pcspkr when i need it but rather automatically unload it once i no longer need it
[19:25:02] <mavica> is that not an option?
[19:25:20] <KitsuWhooa> I don't think so, no
[19:25:30] <mavica> ok, thank you
[19:25:49] <KitsuWhooa> Most distributions that do anything about it just straight up blacklist it
[19:26:05] <mavica> yes, i'm aware, and i was intentionally avoiding that
[19:26:37] <KitsuWhooa> You don't use a DM, right?
[19:26:50] <mavica> from what i've been told, i think i've dodged that bullet
[19:27:05] <mavica> i think this is what people call "doing everything manually", even if i wasn't aware of it
[19:27:14] <KitsuWhooa> Yes
[19:27:19] <mavica> my "de" from what i can tell is "startx"
[19:27:22] <KitsuWhooa> You are in fact doing everything manually
[19:28:24] <mavica> which is what i thought would give me the flexibility to unload pcspkr once startx is called
[19:28:33] <mavica> without needing to shun it entirely from my system at boot with blacklist
[19:28:48] <KitsuWhooa> The reason I asked about a DM is because you might've been able to tell systemd to do it once it reaches the graphical session
[19:29:35] <KitsuWhooa> The reason it doesn't work in the xinitrc is probably because it expects an interactive terminal to ask for a password
[19:29:59] <KitsuWhooa> If you're using sudo. If you're not, I assume you're running X as a normal user
[19:30:06] <KitsuWhooa> Who can't unload / load modules
[19:32:38] <mavica> i get that. i was at first trying to poke at another angle at this though: if libcanberra knows to play a sample instead of bell'ing through the pcspeaker, why does it fumble only at the first occasion?
[19:32:57] <mavica> this seems like a more serious root issue that gets "swept under the rug" by simply blacklisting pcspkr.
[19:34:42] <KitsuWhooa> I don't think canberra has anything to do with pcspkr
[19:35:09] <KitsuWhooa> Vague guess. It's probably a race of whoever gets the event first and consumes it
[19:35:46] <mavica> that's how it feels, but only for the first beep. never happens again. like the system realizes, oh wait, i have a better path to go through for notifications
[19:36:10] <mavica> pcspkr doesn't get unloaded, yet it never beeps there again after the first occurrence
[19:36:29] <mavica> this, to me, is the ideal. not having to lose pcspkr but using audio when it's available
[19:37:09] <mavica> difficult because nobody else thought about it? maybe, but i thought that's what the hypercustomizability of linux was all about :) not having to be beholden to what my package's maintainer thinks is the right way to use a computer
[19:37:24] <mavica> i appreciate if you don't have an answer for it, but i think there's more at play here
[19:42:18] <KitsuWhooa> Yeah unfortunately I don't, sorry
[19:43:07] <mavica> np :)
[19:45:17] <KillerWasp> https://paste.rs - a problem that i have running valgrind.
[19:45:18] <phrik> Title: Source Code | Rocket Powered Pastebin (at paste.rs)
[19:46:05] <KillerWasp> can't run with the debug of a program
[19:46:58] <KillerWasp> it's from a old system, not updated
[19:47:36] <KillerWasp> Linux 5.15.44-1.1-lts
[19:54:42] <mavica> module-x11-bell is indeed responsible for trapping system bell events and preventing them from going to pc speaker. why it fails on the first one must be a configuration issue in my machine, or a bug. i'll move my search there
[21:31:52] <mavica> figured it out... `xset -b` in my xinitrc keeps canberra bell and keeps pcspeaker from firing on first occurrence, pcspeaker still confirmed working with beep
[22:25:02] <mavica> hmm, i tried pulling package dosbox under arch pentium4 and all it does is print the version and then crash with a SIGILL
[22:27:25] <KitsuWhooa> Welcome to hell :p
[22:27:41] <KitsuWhooa> Does your cpu support SSE2?
[22:29:21] <mavica> according to /cpu/procinfo yes
[22:29:46] <mavica> er /proc/cpuinfo
[22:47:11] <mavica> looks like dosbox-staging aur supports arch "any"... let's see if i can do the incredibly ill-advised feat of building it on a machine that really shouldn't be doing this
[22:51:21] <mavica> arrgh. dependency iir1 is 64bit only
[23:04:21] <mavica> version 0.78 doesn't require iir1 and only 1 of the dependencies is aur, and it seems to be happy to be building on pentium4 :D
[23:05:11] -!- bill-auger has quit [Remote host closed the connection]
[23:06:48] -!- bill-auger has joined #archlinux32
[23:10:03] <KitsuWhooa> You can modify any aur package to have the correct architecture
[23:10:46] <mavica> munt failed linking to qt6, bugger
[23:10:53] <KitsuWhooa> I'd look into why it fails, but it'll be pointless since I probably won't be able to get dosbox to build
[23:10:59] <KitsuWhooa> Do we even have qt6?
[23:11:13] <mavica> iir1 didn't have any 32bit archs so i didn't think lodging pentium4 in the list would work
[23:11:17] <KitsuWhooa> See if there's a way to build it against Qt5
[23:11:33] <mavica> my system does have qt6 yes
[23:11:48] <mavica> the lib is there but the link complained about a couple undefined references
[23:12:05] <KitsuWhooa> AUR packages usually don't have binaries so you can just add your arch to the list
[23:12:34] <mavica> well that's what i did with munt, since it did have i686 listed
[23:12:48] <KitsuWhooa> You can also just get upstream PKGBUIlDs and build them
[23:13:08] <mavica> is that not what i'm doing? is there a different way to use aur?
[23:13:18] <mavica> i'm just git cloning and makepkg'ing
[23:13:19] <KitsuWhooa> The aur is user submitted
[23:13:25] <KitsuWhooa> I'm talking about the official arch packages
[23:13:44] <mavica> ah, so to get dosbox rather than dosbox-staging
[23:13:48] <KitsuWhooa> Yup
[23:13:48] <mavica> and build that
[23:13:53] <KitsuWhooa> That might work a bit better
[23:16:41] <mavica> older munt does use qt5-multimedia instead of qt6-multimedia (though both packages exist in arch32), i'll see if i can build that first
[23:29:46] <mavica> munt 2.4.0 built :D
[23:30:39] <mavica> and... the dosbox-staging pkgbuild downloads libmt32emu (derived from munt) version 2.5.3 anyway lol
[23:30:48] <mavica> so it never truly needed the munt package as a dependency
[23:32:36] <mavica> i think qt is only needed for munt if you're using it standalone, since dosbox just uses it as a mt32 emu internally that'll probably just build fine since it'll link to sdl instead
[23:32:54] <mavica> dosbox-staging probably doesn't need munt as a package dependency
[23:46:49] -!- girls has quit [Quit: ZNC 1.8.2 - https://znc.in]
[23:48:02] -!- girls has joined #archlinux32