| dgriffi | what's the correct way to start pipewire along with pipewire-pulse? | 00:57 |
|---|---|---|
| rwp | dgriffi, That's been an often asked question and so far I have not seen an authoritative answer given. I think you just start it manually for the moment. Seems to me like an entry in ~/.xsessionrc is likely reasonable. (Or ~/.xinitrc for us throw-back cavepeople.) | 01:17 |
| rustyaxe | dgriffi: let pipewire start pipewire-pulse from the configuration file | 01:20 |
| rustyaxe | I have pipewire & wireplumber started in a script in my xsession as well, so it works across DEs | 01:20 |
| rwp | rustyaxe, You recommend installing wireplumber too? Is that the secret sauce? | 01:22 |
| rustyaxe | i mean if you run it, it will make life easier, yes. | 01:22 |
| dgriffi | does it help if I'm related to someone named "Luigi"? | 01:23 |
| rustyaxe | qpwgraph is good for fixing routing when it guesses wrong (assuming you're like me and have multiple sound devices) | 01:23 |
| rustyaxe | dgriffi: Only if the fact Dr Mario gave me a tetanus shot counts | 01:23 |
| dgriffi | rwp: what specific commands? Just "pipewire" and "pipewire-pulse" with no parameters? | 01:24 |
| dgriffi | rustyaxe: my great-great uncle was named "Luigi" and started a deli around 100 years ago that still exists. | 01:25 |
| dgriffi | deli/grocery/restaurant | 01:25 |
| rwp | dgriffi, I was literal in that I had not seen a canonical correct way to start it. I am not running anything myself. Just rawdogging alsa here for the moment. But pulseaudio is so much trouble for me that anything would be an improvement. | 01:26 |
| rwp | rustyaxe is running it though and actual experience is better than academic information. | 01:27 |
| dgriffi | just before asking this question, I started them from an xterm with no parameters. the result was the pointer no longer brought other windows into focus -- it was locked on that one xterm. | 01:28 |
| rustyaxe | ive been running pipewire exclusively for many months now. Been poopaudio-less for a couple years now as it made strife wiht my radios | 01:28 |
| rustyaxe | pipewire & wireplumber & | 01:28 |
| dgriffi | rustyaxe: "poopaudio". I like that. It meshes with my habit of naming scratch files poop, shit, fart, and so on. | 01:28 |
| rwp | dgriffi, Starting pipewire freezes window focus on the current window? How bizarre! | 01:29 |
| dgriffi | and debugging variables | 01:29 |
| rustyaxe | thats the entirety of my /etc/X11/Xsession.d/98-pipewire | 01:29 |
| rwp | Is /etc/X11/Xsession.d/98-pipewire packaged? Or your local creation? ("dpkg -S /etc/X11/Xsession.d/98-pipewire") | 01:29 |
| rustyaxe | no just put that content in it. maybe chmod 0755 it | 01:30 |
| rwp | Those files should not need to be executable. They are sourced into a /bin/sh script not executed independently. | 01:31 |
| rwp | See the bottom of the /etc/X11/Xsession script for the implementation. | 01:31 |
| dgriffi | I was perusing what Slackware did and it seems that they were doing something in /etc/rc.d with it | 01:32 |
| * dgriffi misses the ability to use ssh to make noises come out of a remote box | 01:32 | |
| dgriffi | cat /dev/audio|ssh -C my.friends.host.somewhere.at "cat - >/dev/audio" | 01:32 |
| rwp | It's not working for you? I rely upon that functionality to play videos on my media machine to my TV. | 01:32 |
| dgriffi | rwp: no. I'm talking about routing /dev/audio through a ssh tunnel and out the remote box's /dev/audio for laughs. | 01:33 |
| rwp | I am typically running mpv on a remote system to throw audio+video to the speakers and display. | 01:34 |
| dgriffi | quite amusing when a burp comes out of someone's sun box | 01:35 |
| rustyaxe | rwp: as i said, maybe chmod ;) | 01:35 |
| rustyaxe | dgriffi: you can still do that with padsp ;) | 01:36 |
| rustyaxe | pretty sure | 01:36 |
| rwp | Those particular files in /etc/X11/Xsession.d/* are not and should not be executable. They are not executed. They are sourced. | 01:36 |
| rwp | As the script comments say this is because they are all designed to interact together as one script and to be able to pass variable data among the different parts. | 01:38 |
| dgriffi | rustyaxe: I put those pipewire things in my .xinitrc and I see no sign of them running | 02:42 |
| rustyaxe | No idea, havent used xinit since the early 00s, sorry. | 02:50 |
| rwp | dgriffi, Unless you are starting X using startx or xinit then ~/.xinitrc is not relevant. Most DEs use the ~/.xsessionrc file. | 03:18 |
| gnarface | dgriffi: try piping arecord through the tunnel to aplay | 04:30 |
| gnarface | though i'm not sure why what you're doing isn't working, i haven't tried it that way since oss (and maybe if you install the alsa-oss package it will work that way) | 04:31 |
| rwp | I know /dev/audio is the old Sun sound system so arecord and aplay would be the Linux way. (It would be /dev/dsp or something if rawdogging it, right?) | 04:35 |
| gnarface | /dev/dsp would be the oss one | 04:36 |
| gnarface | the actual alsa ones are the ones in /dev/snd/ | 04:37 |
| gnarface | but if you're using pulseaudio or pipewire or the like, i'm not sure any of that will work | 04:37 |
| gnarface | what i do to avoid the pulseaudio requirement for Steam Remote Play (formerly known as "In-Home Streaming" which is not to be confused with the separate "Broadcast" mode) is set programs to use the Loopback alsa device provided by the snd-aloop kernel module, and then pipe arecord from that over netcat -u... to "aplay --buffer-time=50000..." | 04:39 |
| gnarface | (which eliminates most the annoying delay) | 04:40 |
| rwp | Clever! | 04:41 |
| gnarface | i can't admit to coming up with that myself. someone called debianuser in the former freenode #alsa gave me that tip | 04:41 |
| gnarface | works really well though | 04:42 |
| gnarface | if you're going to use it for an extended amount of time you also want to make sure to use "-t raw" on both the arecord and aplay commands, otherwise after a couple hours you're going to run into some max file size limit of the default pcm wav format | 04:44 |
| gnarface | (i wrote a script but it's ugly so i am embarrassed to show it, but if anyone has trouble debugging their own for this i'm happy to help) | 05:12 |
| Afdal | I just avoid cancer like Steam in the first place ;) | 05:51 |
| dgriffi | rwp: oops. I'd forgotten that | 06:01 |
| dgriffi | I have pipewire and wireplumber running from .xessionrc. It doesn't seem that MATE sees it as a pulseaudio replacement | 06:15 |
| gnarface | Afdal: well, the important part is this can be used for anything. it doesn't have to be Steam | 06:25 |
| gnarface | it's nice for Steam because otherwise you would need to use pulseaudio to do this, but it's also nice for anything that wouldn't otherwise have network audio support | 06:26 |
| gnarface | and it's nice that it doesn't require raw access or mangled config files | 06:27 |
| strato | Is there any information on release of Daedalus | 09:44 |
| debdog | strato: "No" or "As soon as it's finished". however AFAIK the repos themselfs are ready but the installer is not yet. Meaning dist-upgrading should™ be stable but fresh installations are still in the testing phase. | 09:50 |
| strato | Thanks for info | 09:54 |
| APic | Re Xorg and libgudev-1.0-0: I just got lazy and downgraded my System from unstable to daedalus instead of helping to debug the Issue 😉 | 12:00 |
| APic | Now my X works again | 12:00 |
| fsmithred | did pinning one package to the older version not work? | 12:01 |
| APic | fsmithred: Probably it worked, but i _thought_ my X still b0rked because Xorg.0.log still showed „(II) No input driver specified, ignoring this device.“ | 12:08 |
| APic | fsmithred: Now that You say it, i will try upgrading to unstable once again and check if the Mouse still works 😉 | 12:08 |
| onefang | (II) is Information, not Warning or Error. | 12:08 |
| onefang | If your actual input devices work, then you can ignore that. | 12:09 |
| APic | Yup, upgraded to ceres, and the Touchpad works again now. Thanks a Lot! | 12:14 |
| APic | s/now/still/ | 12:14 |
| fsmithred | Is that with libgudev pinned or not? | 12:14 |
| APic | WIth libgudev pinned | 12:14 |
| fsmithred | thanks | 12:14 |
| APic | yw | 12:14 |
| onefang | Digit: We now have #devuan-riscv if you want to discuss "can haz RISC-V ceres?" So we have begun to start the beginnings of thinking about it very recently. Something may actually happen, but we'll need some help the same way we have some ARM help in #devuan-arm. | 12:48 |
| Digit | thanks muchly. :) though, that effectively answers my question, as to where it's at. :) | 12:53 |
| not-demindiro | Is it fine if excalibur-{updates,security} "does not have a Release file"? Just excalibur seems to be fine | 18:14 |
| not-demindiro | From what I can find it is expected, so here goes | 18:16 |
| fsmithred | not-demindiro, yes, the testing and unstable suites use only one line in sources.list | 18:16 |
| systemdlete | uname -a shows me I am running 5.10.0-23-amd64. ls /boot shows vmlinuz-5.10.0-23-amd64 sitting there. Yet... apt upgrade wants to install vmlinuz-5.10.0-23-amd64 again. ??? | 18:16 |
| systemdlete | I know I must be missing something here. Just want to know what that missing part of my knowledge is exactly. | 18:31 |
| systemdlete | Anyone? | 18:48 |
| schillingklaus | anyone what? | 18:51 |
| systemdlete | see ^^ | 18:51 |
| fsmithred | systemdlete, run 'apt policy linux-image-5.10.0-23-amd64' | 18:51 |
| fsmithred | package numbers are the same but version numbers are different | 18:52 |
| systemdlete | the package names do not indicate there is any change though | 18:52 |
| fsmithred | I think that means you don't need to reboot | 18:52 |
| fsmithred | not certain of that, though | 18:53 |
| systemdlete | policy shows that it goes from 5.10.179-2 to5.10.179-3 | 18:53 |
| fsmithred | yup | 18:53 |
| systemdlete | still, why wouldn't the package NAME reflect that? | 18:53 |
| systemdlete | that's normal way of doing things, in nearly every other area I can think of. | 18:54 |
| systemdlete | I mean, when running "apt upgrade" | 18:54 |
| systemdlete | So I can see exactly why it wants to do an upgrade. | 18:54 |
| fsmithred | probably has to do with what kind of changes they made | 18:54 |
| systemdlete | shouldn't | 18:54 |
| systemdlete | package names should ALWAYS be unique. | 18:55 |
| fsmithred | is that what the debian policy manual says? | 18:55 |
| systemdlete | otherwise, what if you must roll back to a previous version? Sure, you can check this and check that, but it makes things 100% easier if the package names are unique. | 18:55 |
| systemdlete | No, not necessarily. I have no idea what debian policy manual says. I'm just saying this is how it is done through most of industry. | 18:56 |
| systemdlete | (And, no, I don't really want to read through the entire debian policy manual to confirm they are doing something in a rather unorthodox manner) | 18:56 |
| systemdlete | I mean, would it really kill them to indicate the version in the package name? How hard can that be? | 18:57 |
| * systemdlete SMH | 18:58 | |
| systemdlete | or at very least, could devuan's packaging system somehow add that info to the name of the package? | 18:59 |
| schillingklaus | that would cause too many incompatibilities | 18:59 |
| systemdlete | When they bump a package from 5.10.0-22 to 5.10.0-23, that doesn't cause too many incompatibilities, right? So why would bumping the name from 5.10.0-23-v2 to 5.10.0-23-v3 cause a problem? | 19:01 |
| systemdlete | Or, how about a simple scheme like 5.10.0-2302 to 5.10.0-2303 -- that way they probably don't have to do anything requiring pervasive changes in the scripts and so on? | 19:09 |
| unixman_home | Hmmm, using MATE on chimaera my Xorg memory use keep growing over time and never reduces. I eventually have to log out of X to clear the memory due to system memory swapping after the usage gets too large in Xorg. This has been happening for months now. I think we might have a small memory leak. | 21:07 |
| Xenguy | unixman_home, Huh, I use MATE on Beowulf, and this is a pretty old/slow laptop. I've never noticed such an issue AFAICT | 21:10 |
| unixman_home | Yeah, I don't recall this happening until I upgraded to Chimaera on my NUC. It has been happening for a while, and I am just putting up with it. | 21:55 |
| unixman_home | I do have to keep an eye on the memory use so I can cleanly close stuff out. It was causing OOM killer to kill stuff uncleanly before I figured out what was apparently happening. | 21:58 |
| smolcat | is there a set of instructions for upgrading debian 12 to devuan 5 on a vps? | 22:39 |
| smolcat | or would it be easier to install debian 11, upgrade it to devuan 4, and then dist-upgrade it to devuan 5? | 22:42 |
| bgstack15 | OK, after running updates today my X11 sessions cannot access the keyboard and mouse input... | 22:52 |
| bgstack15 | I cannot even get to CTRL+ALT+F3 to switch to a different virtual terminal. I can ssh in from another host, stop lightdm, and then switch to a virtual terminal on the console. | 22:53 |
| mason | bgstack15: I'd look at udev first. | 22:53 |
| bgstack15 | Does anyone know anything obvious, or maybe some tips to follow? | 22:53 |
| bgstack15 | OK | 22:53 |
| mason | If it updated, that's a good bet anyway. Maybe ssh in and see if it's running. | 22:53 |
| bgstack15 | it did not update. | 22:54 |
| bgstack15 | Is libgudev-1.0- (238-2) related? | 22:54 |
| bgstack15 | That's a systemd version... | 22:54 |
| debdog | bgstack15: testing or stable?! | 22:54 |
| bgstack15 | unstable | 22:54 |
| bgstack15 | Ceres | 22:54 |
| debdog | https://bugs.devuan.org/cgi/bugreport.cgi?bug=769 | 22:54 |
| bgstack15 | Yep, that looks like my error message in Xorg.0.log | 22:55 |
| bgstack15 | Thanks! | 22:55 |
| * debdog wonders why noone seems to care to mention their version. esp when it is not stable. | 22:55 | |
| bgstack15 | I will do better next time! | 22:56 |
| debdog | sorry bgstack15, you're not the first one with that problem and not the first not mentioning version. (half kidding, do not take it personally;)) | 22:57 |
| bgstack15 | I don't take it personally. I endeavor to provide useful debug info during each question I ask. | 22:58 |
| mason | ha ha only serious | 22:58 |
| debdog | right, I do find myself making similar mistakes | 22:58 |
| debdog | well, that's why I said "I wonder". but that would be a dialog for #OT | 22:59 |
| debdog | smolcat: not yet, AFAIK. but https://www.devuan.org/os/documentation/install-guides/chimaera/bullseye-to-chimaera should give an idea. ideally do that within a screen/tmux session on the vps. but, as the howto mentions "Migrating from a fresher, less customized Debian is likely to be less troublesome. Depending on your setup, significant issues may arise during the process so as always, proceed with caution and backup your data before proceeding." | 23:10 |
| debdog | smolcat: "or would it be easier to install debian 11, upgrade it to devuan 4..." why start with debian et all? in case of a fresh install why not do it with devuan itself (or is that vps provider thing)? | 23:11 |
| smolcat | the host doesn't provide a means (that i could see) to install devuan directly. | 23:14 |
| sfox | I'm still having issues installed the latest kernel patch-level | 23:15 |
| sfox | not building zfs dkms modules | 23:15 |
| mason | sfox: Can you repeat whatever your initial issue was? | 23:15 |
| sfox | mason, https://bugs.devuan.org/cgi/bugreport.cgi?bug=767 | 23:16 |
| smolcat | debdog: but thanks for your input. i think i'll try the second option. cheers. | 23:17 |
| mason | sfox: It's a bit more work, but you can avoid the DKMS entirely and build kmods you can install. | 23:17 |
| sfox | how does that work? | 23:17 |
| mason | sfox: The advantage is you build once, and cut your carbon footprint while removing some variables. | 23:17 |
| sfox | won't that break every time the kernel updates? I installed from apt-bpo so the package manager would handle things | 23:18 |
| mason | sfox: There are various things you can do, but in short, follow their custom packagte instructions for Debian kmods. | 23:18 |
| mason | sfox: It can, yes, but you can also whip up a quick metapackage to block new kernels for which you don't have ZFS built. | 23:18 |
| sfox | I don't even know what the package isn't building for this specific kernel version. I think there might be something wrong with the metadata for the latest kernel patch | 23:18 |
| sfox | dkms is expecting a version number, but instead it seems to read 'lts-lts' | 23:19 |
| sfox | that's probably not right | 23:19 |
| mason | sfox: Here's what I've been doing for some years: https://github.com/ChibaPet/bliss-zfs | 23:19 |
| mason | Debian and Devuan are interchangeable for this stuff, in terms of looking at docs. | 23:19 |
| sfox | mmm | 23:26 |
| sfox | seems like a lot of work having to maintain a second package manager | 23:27 |
| sfox | are kernel upgrades really that important? maybe I could just block that version | 23:27 |
| mason | sfox: Repository. | 23:27 |
| sfox | oh | 23:27 |
| mason | sfox: Well. Realize that they only tend to happen in response to security or stability issues. | 23:27 |
| mason | Yeah, what I do is a decent amount of extra work to set it up, but once it's in place, building new versions for kernels as they come out is scant minutes, most of which is the compiler running. | 23:28 |
| mason | Then again, this is feeding my entire infrastructure, so the time savings on that end is significant. | 23:29 |
| mason | For a single box DKMS would be entirely competitive, except for the bit where it's fragile, as you're seeing. | 23:29 |
| sfox | how can I block 5.10.178-3 specificly? | 23:34 |
| mason | apt pinning or a metapackage that conflicts would be the two straightforward ways | 23:35 |
| mason | Oh, or apt-mark hold | 23:41 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!