| * systemdlete once again wonders if his memory is playing tricks on them... | 01:14 | |
| systemdlete | Hotswapping drives used to work automatically, right? | 01:14 |
|---|---|---|
| systemdlete | Now it seems I have to echo "0 0 0" to some nasty path into the /sys fs. I don't ever recall doing that in the past when inserting or withdrawing a drive. | 01:15 |
| systemdlete | But, once again, maybe I just haven't done this in so long that perhaps the linux API has changed. I just don't know. | 01:15 |
| systemdlete | I am using a multi-bay disk unit which is connected to the mainboard directly (no card in between). The connectors are essentially just extensions of the cables which are, in turn, connected to the mainboard. | 01:16 |
| systemdlete | This is happening on two machines, one of which has an eSATA connector, but the behavior is the same on both: Neither one recognizes a drive when inserted into the unit. | 01:17 |
| systemdlete | btw, happy new year to all. | 01:19 |
| rwp | Automatically is depending upon a lot of details. Let's focus only on the hardware level and not the OS mounting side. | 01:26 |
| systemdlete | When I said "automatically" I just meant that I did not have to do anything special for hotswapping to work. | 01:27 |
| rwp | If an unmounted not-busy disk is ejected then I have not needed to "delete" (echo 1 > /sys/block/sdX/device/delete) it from the system in a long time. | 01:27 |
| rwp | And when I have inserted a SATA disk I have not needed to force a SATA bus rescan (echo "0 0 0" >/sys/class/scsi_host/host{N}/scan) in a long time. But that used to be needed. | 01:27 |
| systemdlete | really? "used to be needed?" | 01:27 |
| systemdlete | I never recall having done that. | 01:28 |
| rwp | But I could imagine that if either of those things did not happen then it might be needed to do those again. | 01:28 |
| rwp | Well... If it was never needed then why do those actions exist? Why do we even know about them? If it were always automatic then there would be no such action needed nor available. | 01:28 |
| systemdlete | no idea. | 01:28 |
| rwp | On the OS side it is most important to unmount devices before detatching them. If it is an mdadm raid then I can usually just detach them. | 01:29 |
| rwp | I have one Seagate disk that freaks out every 2-3 months and I have to eject it in order to power cycle it and then insert it again. Rather routinely. | 01:30 |
| systemdlete | I find that mdadm is pretty resilient, even to sudden disconnects. I don't recall losing an md device. | 01:30 |
| rwp | When I do that I have to mdadk --re-add it back into the raid. | 01:30 |
| systemdlete | well, right. | 01:30 |
| rwp | It usually sync's up quickly and no problem. | 01:30 |
| systemdlete | I have to re-add it also. But if I boot the system, mdadm finds the drives in the set and re-syncs them. | 01:31 |
| systemdlete | (yes, same here) | 01:31 |
| systemdlete | mdadm is finding the component drives by the uuid I think. | 01:31 |
| rwp | Yes. UUIDs. Most things use UUIDs internally now. Which is good. | 01:32 |
| systemdlete | robust and reliable | 01:32 |
| systemdlete | I've been reading through posts about this issue, and a lot of them are really old. I'm talking 2006 and 2009 old. | 01:33 |
| rwp | Looking through my notes I have at one point needed to "mdadm --manage /dev/md2 --fail /dev/sda2" and "mdadm --manage /dev/md2 --remove /dev/sda2" a disk for part in 2, 3, 4, 5, and then re-add them again after resetting that pesky Seagate drive. | 01:33 |
| rwp | Nothing has really changed since 2006 on this topic anyway. Those should all still be relevant. | 01:34 |
| systemdlete | Yeah. Sounds like that SG drive is a problem. I have 2 of them here, and both of them report smart values below their thresholds. One of them is BRAND NEW. | 01:34 |
| systemdlete | thankfully, all of my other drives are WD | 01:35 |
| rwp | Since 2019 until now I have had to power cycle this pesky Seagate 22 times by my logs of it. The Toshibas in the array have been okay the entire time. | 01:35 |
| rwp | I must run off but I will just leave this command here as useful: ls -l /dev/disk/by-id/ | awk '{print$NF,$(NF-2)}' | sed -n '/\.\.\/\.\.\//s/^......//p' | grep '^sd. ata' | sort | 01:36 |
| rwp | BBIAB | 01:37 |
| systemdlete | I have a script that does the same thing. | 01:37 |
| systemdlete | but thanks | 01:37 |
| systemdlete | At least a few others are having a similar experience: https://forums.linuxmint.com/viewtopic.php?t=398791 | 01:45 |
| hyperreal | I'm currently trying to host a Devuan mirror. I had my public key added to access via rsync, but now I'm seeing "host key verification failed". | 02:07 |
| onefang | Apologies hyperreal, I've been ill and on holiday recovering, so I've not managed to keep up with my package mirror herding work. | 02:10 |
| hyperreal | onefang: no worries. Can you just remove my mirror from the list? | 02:11 |
| onefang | Aww, sorry to see you go. I'll remove you. | 02:11 |
| hyperreal | Thank you | 02:12 |
| rrq | btw "host key verification failed" is usually the client end making noise about the server's key, typically that they don't having in their "known_hosts" file. | 02:14 |
| onefang | In this case could also be coming from a different IP than the one they told me about. | 02:15 |
| hyperreal | rrq right, I wouldn't mind having that issue resolved, but if no one is maintaining mirror admin then I don't see the point. | 02:15 |
| onefang | Or both, why not both? | 02:15 |
| onefang | If I wasn't bed ridden for most of December, this would have been sorted out then. | 02:17 |
| hyperreal | rrq: wait, let me check if it's in there. I thought I added it but it may have been for another user | 02:17 |
| rrq | yes in this case it was the client end missing setup; perhaps when you shifted from manual (testing mode) to automated | 02:17 |
| hyperreal | okay it's working now. onefang: you don't have to remove me | 02:19 |
| onefang | Yay! | 02:19 |
| onefang | Welcome back. | 02:19 |
| hyperreal | yeah silly me. I added it with my normal user but root is the one running the rsync command. | 02:19 |
| hyperreal | onefang: I'd be happy to help any way I could. Sorry you've been ill and such. | 02:20 |
| hyperreal | on the apt-panopticon page I see my mirror has some errors but I don't know what's causing them | 02:21 |
| onefang | Hopefully now that it's working your mirror will pass apt-panopticon's weekly update stats test in a weeks time, then I can fully activate it. | 02:21 |
| onefang | Well the big one is being fully up to date, which you failed coz your rsync wasn't working until a few minutes ago. | 02:22 |
| onefang | We should take this to #devuan-infra. | 02:23 |
| hyperreal | onefang: np | 02:23 |
| Xenguy | rawr | 03:29 |
| fluffywolf | I got a pair of bluetooth headphones today. I connected to them with bluetoothctl. now how do I send audio to them? alsa isn't showing anything. | 04:22 |
| fluffywolf | /etc/init.d/alsa-utils restart didn't find anything new either | 04:23 |
| brocashelm | have you also installed bluez-alsa-utils and libasound2-plugin-bluez? | 04:24 |
| brocashelm | also, have you added your user to the bluetooth and audio groups? | 04:25 |
| fluffywolf | E: Unable to locate package bluez-alsa-utils | 04:25 |
| fluffywolf | I didn't see anything that looked like it combined bluez and alsa when apt-cache searching... | 04:25 |
| brocashelm | what version of devuan? | 04:25 |
| brocashelm | shows for daedalus | 04:25 |
| fluffywolf | chimaera | 04:25 |
| fluffywolf | daedalus broke everything way too badly on the laptop I upgraded to it on, might skip it entirely on this one. | 04:26 |
| brocashelm | then it sounds like you'll have to compile it from source | 04:27 |
| brocashelm | for bluez-alsa-utils | 04:27 |
| fluffywolf | surely "chimaera doesn't have bluetooth" is not the answer here? | 04:27 |
| brocashelm | daedalus is the first devuan release to have those packages | 04:27 |
| brocashelm | no, i think it's just due to incompetent maintainers in debianland not getting the packages in sooner | 04:28 |
| brocashelm | if you compile it, you should be able to get alsa audio with bluetooth | 04:28 |
| brocashelm | sadly, doesn't seem like it'll get backported by them | 04:28 |
| fluffywolf | so you're saying there's no working bluetooth on chimaera, despite bluetooth being a standard for years and everyone using bluetooth earbuds and crap? | 04:28 |
| fluffywolf | that's... really sad if true. | 04:29 |
| brocashelm | don't ask me, that's on debian | 04:29 |
| brocashelm | there are software i use that i can't easily install on beowulf or chimaera, having to either compile or use some third-party deb as the only options | 04:30 |
| fluffywolf | but surely there's some other software that does something as basic as send audio to a bluetooth device, even if those packages don't exist yet? | 04:31 |
| fluffywolf | I don't have enough bandwidth left to try upgrading to daedalus right now even if I did want to risk breaking everything... might try frankendebianing it. | 04:32 |
| fluffywolf | bah, of course libc6 is very incompatible, and frankendebianing is not going to be easy. | 04:36 |
| onefang | Too much fluffy wolf fur in the way? | 04:37 |
| fluffywolf | ? | 04:39 |
| onefang | Getting between your blue teeth and your ears. | 04:39 |
| fluffywolf | aptitude wants to remove consolekit. will this break anything? | 04:40 |
| * fluffywolf always looks at the package lists very carefully when doing stupid things... | 04:41 | |
| fluffywolf | ok, bluealsa --help does not provide sufficient information to know how to use it. lol | 04:44 |
| gnarface | fluffywolf: AIUI pulseaudio absorbed bluetooth audio functionality and they removed bare alsa bluetooth audio support some releases back. (that they apparently re-added it to daedalus is in fact news to me) - data and gamepad inputs should have always been possible through that time with separate packages, but driver support has been so spotty that gambling a pair of devices would work together has been a bad bet in | 04:44 |
| gnarface | general | 04:44 |
| Xenguy | bluetooth, won't fix | 04:45 |
| fluffywolf | bluealsa: E: main.c:131: Couldn't acquire D-Bus name. Please check D-Bus configuration. Requested name: org.bluealsa | 04:45 |
| gnarface | ... even if they used to work before kernel 3.1, as i found out the hard way | 04:45 |
| brocashelm | xenguy: "your use case don't exist, go away" ~ debian bluetooth team | 04:46 |
| debdog | fluffywolf: this https://wiki.debian.org/BluetoothUser and this https://wiki.debian.org/BluetoothUser/a2dp seem to do without bluez. they mention bluealsa | 04:46 |
| fluffywolf | ah, has to be root... | 04:46 |
| fluffywolf | seems like it's doing things, but aplay -L still only shows the same devices. | 04:47 |
| Xenguy | brocashelm, When did Debian go so south ? | 04:48 |
| Xenguy | Or maybe it's upstream | 04:48 |
| Xenguy | Still a shrug | 04:48 |
| fluffywolf | this is being way too difficult. we won't have "linux on the desktop" if people can't make their earbuds work. lol | 04:50 |
| brocashelm | because a new audio server is being (re)written every 5-10 years | 04:51 |
| rrq | I had bluealasa working on chimaera | 04:51 |
| brocashelm | oss, alsa, portaudio, jack, pulseaudio, gstreamer, pipewire... | 04:52 |
| rrq | .. together with bluez .. there was some tweaking needed to get the dbus connection working | 04:52 |
| brocashelm | sdl/sdl2, too | 04:52 |
| fluffywolf | the bluealsa manpage references utilities which don't exist and I can't find a package for. | 04:52 |
| onefang | esound. | 04:52 |
| rrq | fluffywolf: you need bluez for hanlding the actual bluetooth networking | 04:53 |
| gnarface | i think i last had it working in debian sarge | 04:53 |
| gnarface | or maybe squeeze | 04:54 |
| gnarface | one of the "s" ones | 04:54 |
| gnarface | (putting devuan releases in alphabetical order was a smart call) | 04:54 |
| rrq | fluffywolf: then you can pair the headset | 04:54 |
| fluffywolf | rrq: I am paired with the headset. the problem is sending audio to it. | 04:55 |
| rrq | then the bluealsa process need to be started to be the a2p server that links alsa with bluetooth | 04:55 |
| rrq | then also need to be configured to pass audio to bluealsa | 04:56 |
| fluffywolf | and I have bluealsa running with -p a2dp-source -c LDAC | 04:56 |
| fluffywolf | gnarface: even smarter would be not putting "ae" in them. :P | 04:57 |
| rrq | right. your .asoundrc set up to pass "default" to bluealsa? | 04:57 |
| fluffywolf | I haven't done anything to my .asoundrc at all. I was expecting a card to appear when reloading alsa. | 04:58 |
| rrq | yes but program sends sound to "default" and you need a pcm of typ bluealsa | 04:59 |
| fluffywolf | a "bluealsa" device appeared without any of the normal controls you'd expect of an audio device, but if I try using it, I get: | 04:59 |
| fluffywolf | D: bluealsa-pcm.c:1309: Getting BlueALSA PCM: PLAYBACK 00:00:00:00:00:00 a2dp | 04:59 |
| fluffywolf | ALSA lib bluealsa-pcm.c:1313:(_snd_pcm_bluealsa_open) Couldn't get BlueALSA PCM: PCM not found | 04:59 |
| rrq | to guide it to... the blualsa pcm needs a "device" setting with macaddr and "profile" a2dp | 04:59 |
| rrq | 5 lines: | 05:00 |
| rrq | pcm.bt_aeropex { | 05:00 |
| rrq | type bluealsa | 05:00 |
| rrq | device 20:74:CF:C0:22:81 | 05:00 |
| rrq | profile a2dp | 05:00 |
| rrq | } | 05:00 |
| rrq | that's my pcm for my bone-conducting earphones | 05:00 |
| fluffywolf | bluealsa-aplay -l shows no devices, despite bluealsa finding and acting like it's doing things with the device. | 05:01 |
| rrq | it needs the device macaddr | 05:02 |
| onefang | That's the sort of thing I meant. Bone-conducting doesn't work so well when it has an extra layer of fluffy wolf fur in the way. B-) | 05:02 |
| rrq | bluealsa-aplay captures from a bluetooth mic | 05:04 |
| rrq | not for playback to blueooth | 05:04 |
| fluffywolf | yes, but it has a -l option that lists things, and it finds nothing. | 05:04 |
| fluffywolf | bluealsa seems to think it's working, and only works with -i hci0, so it's finding one device... | 05:05 |
| rrq | bluealsa is a sound deamon for both playback and capture | 05:06 |
| rrq | bluealsa-aplay talks to bluealsa asking for microphones | 05:06 |
| fluffywolf | yes | 05:06 |
| fluffywolf | bluealsa-aplay -l lists both input and output devices | 05:07 |
| rrq | bluealsa may be tied to a single macaddr via /etc/default/bluez-alsa | 05:07 |
| fluffywolf | ~$ bluealsa-aplay -l | 05:07 |
| fluffywolf | **** List of PLAYBACK Bluetooth Devices **** | 05:07 |
| fluffywolf | **** List of CAPTURE Bluetooth Devices **** | 05:07 |
| rrq | I have OPTIONS="-i 30:21:DC:50:9E:89" | 05:07 |
| fluffywolf | except it lists none, while every example I find online shows it listing things. | 05:07 |
| rrq | (that's my blueatooth Qudo speaker) | 05:09 |
| fluffywolf | ok, and does bluealsa-aplay -l list it? | 05:09 |
| rrq | (it's a bit loud so I have that wrapped within a "softvol" pcm) | 05:10 |
| rrq | it's not connected at the moment... I'm afraid that speaker is packed away atm | 05:10 |
| fluffywolf | I'm not finding anything googling about bluealsa thinking it's doing things, but bluealsa-aplay not... | 05:11 |
| rrq | the deal is still that alsa need a pcm set up for type bluealsa | 05:11 |
| rrq | forget bluealsa-aplay | 05:11 |
| rrq | biab | 05:12 |
| fluffywolf | ok.. progress. if I pair with the device AFTER running bluealsa, it shows up in bluealsa-aplay, even though bluealsa does the exact same things. | 05:15 |
| fluffywolf | and my headphones make... noises! | 05:15 |
| fluffywolf | the noises are not, however, the audio I'm playing. | 05:15 |
| fluffywolf | it sounds like it's dropping every other buffer | 05:16 |
| fluffywolf | no, it's playing every buffer... just with a 1/4s delay between each one. | 05:18 |
| fluffywolf | and the audio source (mpv) is counting time at roughly 1 second of file per 4 seconds of wall time | 05:19 |
| fluffywolf | ok... does bluealsa entire ignore the -c/--codec option? I'm trying to use different ones to see if it makes a difference, but as far as I can tell the option does nothing. | 05:22 |
| fluffywolf | grrrrrrrrrrrrrrrrrrrrr | 05:34 |
| fluffywolf | ... you know why LDAC doesn't work? | 05:35 |
| onefang | Fur? | 05:35 |
| fluffywolf | because I got sent the wrong headphones! | 05:35 |
| onefang | Oops! | 05:35 |
| fluffywolf | there's two versions that look identical... an old one and a new one. old ones only support SBC. | 05:35 |
| fluffywolf | which version isn't even labeled on the unit anywhere. the box is for the new version. | 05:36 |
| fluffywolf | this explains why bluealsa is ignoring the codec option... but doesn't explain why SBC is playing at 1/4 speed and skipping. | 05:37 |
| fluffywolf | so... why am I getting what sounds like buffer underruns, and playing at 1/4 speed? | 05:41 |
| Xenguy | You should play chess instead = ) | 05:46 |
| fluffywolf | it's way too late at night, and I haven't played chess in months. | 05:46 |
| Xenguy | Another time perhaps | 05:47 |
| fluffywolf | not finding much googling | 05:50 |
| rrq | mismatched sample rates? | 05:57 |
| fluffywolf | it seems to be intermittant... now it's playing fine. then before this it would play fine for a few seconds, then play 1/4 speed for a few seconds, then go back to fine... | 05:58 |
| fluffywolf | it's not a signal issue. | 05:58 |
| fluffywolf | bbl, bedtime for pissed off wolfies | 06:11 |
| fluffywolf | bluealsa: D: bluez.c:1247: Signal: org.freedesktop.DBus.Properties.PropertiesChanged(): org.bluez.MediaTransport1: Delay | 06:11 |
| fluffywolf | bluealsa is spamming these, may be related | 06:11 |
| fluffywolf | bbl | 06:12 |
| cousin_luigi | Can one start a service automatically with extra parameters? | 10:17 |
| cousin_luigi | I mean, dnsmasq has an "INSTANCE" parameter: can I pass it at startup somehow? | 10:17 |
| cousin_luigi | Or do I have to create two init files? | 10:17 |
| onefang | This might be useful /etc/default/ | 10:18 |
| flake | hello. running a dist-upgrade from 4 to 5. after apt upgrade on new repositories my computer got offline and ifup seems to not being able to pickup anything. any ideas. | 10:39 |
| flake | i was looking into this https://www.devuan.org/os/documentation/install-guides/chimaera/network-configuration | 10:40 |
| flake | but maybe im doing something wrong | 10:40 |
| gnarface | flake: were you using network-manager or anything like that? | 10:46 |
| gnarface | i think 5 is daedalus though, fyi | 10:47 |
| gnarface | yea, it's daedalus not chimaera | 10:47 |
| gnarface | if network fails after an update, the first thing you should usually check is if any graphical networking utilities you were using before got removed, or if you weren't using any, if any got added (in either case it can take down your network) | 10:49 |
| gnarface | if flake comes back, someone tell them that the non-free firmware required by many network devices got moved from "non-free" to "non-free-firmware" | 10:50 |
| cousin_luigi | onefang: ? | 10:55 |
| cousin_luigi | each instance also sources different files from /etc/default, but that comes later. | 10:55 |
| cousin_luigi | I need to pass /etc/init.d/foo start bar | 10:56 |
| rrq | hmm "service dnsmasq start blaha" offers "blaha" as 2nd argument to the /etc/init.d/dnsmasq service script ... isn't that what you want? | 11:07 |
| cousin_luigi | rrq: Yes. Can I do it on startup? | 11:11 |
| rrq | mmm no doesn't seem like there's a trivial way to do that | 11:13 |
| rrq | hacking the service script is probably the easiest option | 11:14 |
| rrq | like changing ${2} to ${2-blaha} and make that an invocation default | 11:15 |
| rrq | ... and thereby make that ... | 11:16 |
| flake | im on tty1 but on 7 is my graphical interface | 11:19 |
| flake | but doesnt loqd anymore | 11:19 |
| flake | just a background | 11:19 |
| flake | yes its daedalus. i am going frim chimaera, uwing this last 1.5 years | 11:20 |
| flake | if i run nmcli i see my wlan connected but iam clearly offline. wonder if thats a remain on my vpn which i cant access now or smth to do with changes through the upgrade. | 11:26 |
| flake | made it work. it was the hanging vpn | 12:29 |
| flake | however after reboot i dont see any vpn connections and wire is deaf as well. doni have to install non free software as well | 12:30 |
| gnarface | flake: note that they moved all the non-free drivers and firmware packages from "non-free" to "non-free-firmware" as of daedalus | 12:31 |
| gnarface | so if you didn't make that change to your sources.list, the upgrade may have removed your wifi firmware package without replacing it | 12:32 |
| flake | actually made it apl work. thank you | 13:23 |
| flake | happy user of devuan 5 now | 13:23 |
| flake | btw will there be se gnome upgrades? | 13:24 |
| flake | *some | 13:24 |
| cousin_luigi | rrq: Yeah, that's what I thought. It was worth asking though. | 14:23 |
| Besnik_b | Hello! Clicking “Generate package download script” in Synaptic returns a window saying “Nothing to install/upgrade Please select the “Mark all Upgrades” button or some packages to install/upgrade” Is that the normal behaviour? | 16:16 |
| Besnik_b | (I was expecting some script or some message about some script…) | 16:17 |
| gnarface | i don't use Synaptic, i could only guess that it probably means that if you're already up-to-date then there's no packages to download to put in a download script in the first place unless you mark something new to be installed | 16:18 |
| Besnik_b | gnarface, thanks I just wanted to create the script for my new installation of Devuan | 16:19 |
| gnarface | but i'm guessing at what this means too, because i've never used it | 16:19 |
| Besnik_b | It works, the message is wrong | 16:19 |
| Besnik_b | It does produce the script | 16:19 |
| Besnik_b | But one have to choose all packages first | 16:20 |
| gnarface | ah | 16:20 |
| gnarface | lemme know if the script succeeds | 16:20 |
| gnarface | i'm just curious | 16:20 |
| Besnik_b | You might be right doubting as I don’t see any entry for importing such script in Synaptic… | 16:23 |
| Besnik_b | such a mees | 16:23 |
| Besnik_b | mess | 16:23 |
| Besnik_b | Is there another way to do that? Command libe maybe? | 16:30 |
| Besnik_b | I’ll install the same distro and the same programs I have in this one from where I’m writing (I booted it through SystemRescue) | 16:31 |
| gnarface | uh... check into refracta tools maybe, though i'm not sure if they can create something that's not a live iso | 16:32 |
| gnarface | my method is more sloppy | 16:32 |
| gnarface | (i just backup the output of dpkg --get-selections and debconf-get-selections to text files in /root/ and then use tar to archive the whole thing) | 16:38 |
| gnarface | ^ there's no automatic recovery process for this though, because neither of those text files can be reliably fed back into anything unaltered) | 16:39 |
| Besnik_b | grep " install " /var/log/dpkg.log and grep " install " /var/log/dpkg.log.1 will be enough for me, just to remember the programs I added to vanilla. I did not make any important change to Daedalus, I did not have time… :D | 16:41 |
| gnarface | i mean, in theory you could use debconf-get-selections in a preseeding file, but in practice you usually can't get reproducible results from anything more than a very minimal install | 16:41 |
| gnarface | you'd have to clean it up by hand or have carefully selected packages that have clean debconf output | 16:42 |
| gnarface | the important thing about my method is it should preserve all relevant data in a form where the install can be reconstituted by hand, albeit ignoring the forensic effort that might be required to do so | 16:44 |
| gnarface | i thought there was a refracta tool for this though | 16:46 |
| gnarface | just not seeing anything in the repo with a description that doesn't claim to be explicitly for live isos | 16:47 |
| Besnik_b | dpkg --set-selections > installed-applications.txt gets me all packages added by me | 16:49 |
| Besnik_b | dpkg --set-selections < installed-applications.txt gets all packages added by me to my new system | 16:50 |
| gnarface | yea, like with debconf-get-selections, it might work with a fresh new system, but the problem comes when you have a older system and that list has more than just a clean list of installs and it chokes on it at input | 16:51 |
| gnarface | might work fine for fresh, new, minimal installs, but there are pitfalls past there, can't be relied on | 16:52 |
| gnarface | you will find you might have to touch the file up by hand | 16:52 |
| gnarface | like removing entries for broken packages in partial install status, etc | 16:52 |
| gnarface | debconf strings are supposed to represent the package configuration in a way that can be fed back in as a selection cleanly but in practice they can't enforce it, so some packages don't represent their state in a way that can reproduce said state | 16:58 |
| gnarface | it's kinda a mess | 16:58 |
| gnarface | (or sometimes it's worse and they can represent the default state correctly but some configurations not) | 16:59 |
| fsmithred | should be --get-selections on one of those, shouldn't there? | 17:01 |
| gnarface | i assumed it was a typo | 17:01 |
| fsmithred | I did write a script for get/set selections long ago. I'll find a link. It'e probably still useful, but be careful. | 17:02 |
| gnarface | yea, should be "dpkg --get-selections > installed-applications.txt" and dpkg --set-selections < installed-applications.txt" | 17:02 |
| gnarface | er, should be "dpkg --get-selections > installed-applications.txt" and "dpkg --set-selections < installed-applications.txt" (forgot a quote) | 17:02 |
| fsmithred | https://github.com/fsmithred/scripts get-selections.sh and set-selections.sh | 17:03 |
| fsmithred | Besnik_b, ^^^ | 17:03 |
| Besnik_b | Thank you, fsmithred! | 17:04 |
| fsmithred | be careful. using those script is the only time I've gotten a full paragraph warning asking if I'm sure that I really want to do that. | 17:04 |
| fsmithred | Because there's a place in there where you could wipe out the whole system. | 17:04 |
| Besnik_b | I’ try first with the Synaptic script, then with installed-applications.txt method | 17:05 |
| fsmithred | you could just run the commands instead of the script itself | 17:05 |
| fsmithred | I prefer to make a live-iso of the system for reinstall, but if you want to use debian/devuan installer, that doesn't work. | 17:06 |
| fsmithred | refractainstaller works, but has some limitations | 17:06 |
| fsmithred | bbl | 17:10 |
| fluffywolf | should bluealsa have an init script? | 17:46 |
| fluffywolf | "The main component of BlueALSA is a program called bluealsa. By default, this program shall be run as a root during system startup." per their github, but there's no init script for it that I can see. | 17:49 |
| fluffywolf | I guess this is an issue where I'm insufficiently familiar with devuan. The package appears to provide /lib/systemd/system/bluealsa.service. Do these somehow get executed on devuan, or not? Should the package also provide an /etc/init.d/bluealsa or such? Is not doing so a bug? | 17:56 |
| gnarface | fluffywolf: no, the systemd service files do not get used. they are vestigial. unless the thing i mentioned before about it expecting something else (like your session manager or something) to start it then it's a bug | 18:57 |
| fluffywolf | from what I can tell, it's supposed to start on boot, but only has systemd stuff, no sysvinit stuff. | 18:57 |
| fluffywolf | and I don't know if it's a bug, since debian's policy pages now seem to say packages shouldn't bother with init scripts. :( | 18:58 |
| gnarface | look in /usr/share/doc/bluealsa/ and see if there are old sysvinit examples | 18:58 |
| gnarface | failing that, if it's in a previous debian release maybe you can steal the init script from there | 18:59 |
| fluffywolf | only changelog and copyright in there | 18:59 |
| gnarface | and if not, they're not that hard to write, usually | 18:59 |
| gnarface | and to be clear, no, debian won't consider this a bug, but i think devuan does | 18:59 |
| gnarface | not a bug worth forking the package over probably, but someone is keeping a package of orphaned sysvinit scripts around here somewhere | 19:00 |
| fluffywolf | does a script that goes in init.d and parses enough of a systemd unit to pretend to work exist? | 19:01 |
| gnarface | for this particular package, i could not say | 19:02 |
| gnarface | ask fsmithred | 19:02 |
| fluffywolf | at least looking at bluealsa's file, "ExecStart=" seems to be the only thing in there relevant whatsoever. heh. | 19:02 |
| gnarface | well all an init script really has to do is react to start and stop | 19:02 |
| fluffywolf | if I'm going to write my own init script, it's going to be one that looks for a .service file with the same name as the init script and tries to get relevant bits from it... | 19:04 |
| gnarface | that sounds... unnecessary and perverse, but have fun | 19:04 |
| fluffywolf | but not today. today is sunny. | 19:04 |
| nietz | apols about that, gettin nicks in | 20:11 |
| fsmithred | fluffywolf, look at /lib/init/init-d-script to make a generic init script. I thought there was one to convert a systemd unit file to init script, but I don't see it. | 20:38 |
| fsmithred | That file is part of sysvinit-utils package | 20:38 |
| fluffywolf | https://fossies.org/linux/sysvinit/contrib/sysd2v.sh | 21:01 |
| fsmithred | fluffywolf, thanks. I bookmarked it. | 21:05 |
| fluffywolf | is included in 3.00-1+devuan1 source | 21:06 |
| fluffywolf | sysvinit, that is | 21:06 |
| fsmithred | but it doesn't go into the package? | 21:06 |
| fluffywolf | not sure, I have 2.something installed, and it's not in the source for it | 21:08 |
| fsmithred | it's not in my daedalus install | 21:09 |
| fluffywolf | yeah, not in sysvinit-core_3.00-1+devuan1_amd64.deb | 21:11 |
| fluffywolf | haven't checked the other packages built from the same source | 21:12 |
| fluffywolf | looks like it doesn't end up in any packages | 21:13 |
| fluffywolf | generates a valid-looking init-d-script from the bluealsa.service... | 21:15 |
| fsmithred | cool | 21:15 |
| fsmithred | I think we'll be seeing more use of that script | 21:16 |
| fluffywolf | since it's in a forked source package already, should we make sysvinit-utils or something contain it, so it gets installed? | 21:18 |
| fluffywolf | I need to rtfm on init-d-script more | 21:23 |
| fsmithred | LeePen would be the one to talk to about including that script. | 21:31 |
| fsmithred | maybe file a wishlist bug report to devuan | 21:31 |
| rrq | that "bluealsa.service" file is actually a declaration for an org.bluealsa.service file via the systemd facility to create such on the fly | 21:40 |
| rrq | mine is at http://paste.rrq.au/GfHsxFvcxE/org.bluealsa.service, to be placed at /usr/share/dbus-1/system-services/org.bluealsa.service | 21:42 |
| rrq | there is alread a /etc/dbus-1/system.d/bluealsa.conf for its permissions | 21:43 |
| fluffywolf | I don't have the background to understand that. never done anything with dbus. | 21:44 |
| fluffywolf | also, 404 | 21:44 |
| rrq | by that blualsa will be started on demand | 21:45 |
| fluffywolf | by... dbus? | 21:45 |
| rrq | yes | 21:45 |
| rrq | hmm the 404 is boring.. must be my fault | 21:46 |
| fluffywolf | I had no idea dbus did things like that. | 21:46 |
| fluffywolf | ... why is anything with "bus" in the name involved with starting services? | 21:46 |
| rrq | should be https not http | 21:47 |
| fluffywolf | that's an unusual cause of a 404. | 21:48 |
| rrq | not for that site :) | 21:48 |
| fluffywolf | https is "runtime error: invalid memory address or nil pointer dereference" | 21:48 |
| fluffywolf | even more fun. | 21:48 |
| fluffywolf | lol | 21:48 |
| rrq | put these 4 lines into /usr/share/dbus-1/system-services/org.bluealsa.service | 21:49 |
| rrq | [D-BUS Service] | 21:49 |
| rrq | Name=org.bluealsa | 21:49 |
| rrq | User=root | 21:49 |
| rrq | Exec=/usr/bin/bluealsa -p a2dp-sink -p a2dp-source -S | 21:49 |
| rrq | change to your program argument | 21:50 |
| fluffywolf | will that start it before bluetoothctl pairs? I found the order is very important. if you pair first, then run bluealsa, it looks like it's working but doesn't. | 21:51 |
| rrq | mmm it tarts when a program requests the org.bluealsa service from dbus | 21:52 |
| rrq | I think the answer is "no" | 21:52 |
| rustyaxe | -.- my xfce-terminal recently stopped being able to display unicode | 21:52 |
| fluffywolf | the script above generates an init file that starts it on boot, which is how the github page says it should be ran... | 21:53 |
| fluffywolf | why is it that the more I use anything from fd.o, the more I hate fd.o? | 21:56 |
| rrq | well the systemd service thingy is actually on-the-fly dbus service confgiuration; dbus has been tied to systemd in that way ... but I agree that an init service is a good alternative | 21:57 |
| rrq | even if I don't have one | 21:57 |
| fluffywolf | that seems like a larger issue that devuan will need to address | 21:59 |
| fluffywolf | i.e. this isn't going to be the only package with this problem | 21:59 |
| rustyaxe | fluffywolf: I feel you on there | 21:59 |
| rustyaxe | fd.o i swear exists to make linux desktop as bad as windows | 21:59 |
| brocashelm | indeed | 22:00 |
| rrq | agree. and several dbus services has been change to use that way for their startup definitions | 22:00 |
| rrq | (have been changed) | 22:00 |
| fluffywolf | so the current state of devuan is all those packages, except ones that have been forked, don't work, without non-obvious manual configuration? | 22:01 |
| rrq | would be right I think | 22:02 |
| rustyaxe | Speaking of | 22:03 |
| fluffywolf | in this case, making bluetooth headphones/earbuds work is a pretty common end-user desktop experience thing, and we shouldn't have it broken. heh. | 22:03 |
| rustyaxe | Yesterday or day before i had to manually fix eudev initscript | 22:03 |
| rustyaxe | it couldnt find sed so i had to add the /usr/bin/ path in single user mode to get it to run and get back into X ;o | 22:04 |
| fluffywolf | I think bluez-alsa-utils definitely counts as bugged, but we'd need to fork it to fix it... | 22:04 |
| fluffywolf | or solve what will likely be an increasing problem of packages wanting to be started by dbus but not working on devuan. | 22:05 |
| fluffywolf | in addition to the no-init-script problem... | 22:06 |
| rustyaxe | Linux sound is a nightmare worse now than the OSS/early alsa split days i swear | 22:07 |
| fluffywolf | alsa still works fine | 22:07 |
| rustyaxe | I deal with a lot of non-gui programs that need to deal with pipewire without an X session, that's its own dread. | 22:07 |
| fluffywolf | I haven't played with pipewire yet. | 22:08 |
| rustyaxe | Where usable, yes. Unfortunately to do a bit more advanced things than alsa can do as i hook radios to PBXes and other weird shit ;) | 22:08 |
| rustyaxe | That gets even more dreadful trying to throw an audio processing chain in.. For now i have to just start up a VNC display that sits detached , so pipewire runs, etc | 22:09 |
| fluffywolf | rrq: with your dbus thingy, it fails the first time and works the second time, but both are after pairing anyway and will not actually work based on what I saw. | 22:09 |
| fluffywolf | rrq: http://paste.debian.net/1303376/ it seems to get started *after* it's needed, so only works the second time. | 22:09 |
| fluffywolf | and... how do you stop it or interact with it? (other than kill, of course) | 22:10 |
| rrq | yes it's on the crap end of the quality scale | 22:11 |
| fluffywolf | I think starting it with an init script is the better option anyway. lol. does it suck like this on systemd systems too? | 22:11 |
| rrq | I ended up looking into dbus ... and there I had quite a time with small-headedness | 22:12 |
| rrq | (like binary padding before the data unit) | 22:12 |
| fluffywolf | how do you stop or otherwise interact with things started by dbus? | 22:13 |
| rrq | /usr/bin/kill | 22:13 |
| fluffywolf | i.e. now that it's started an org.bluealsa service, what if I want to stop it? heh | 22:13 |
| fluffywolf | yeah, I've been killall bluealsa'ing it, but that can't be the right method. :P | 22:14 |
| rrq | as root | 22:14 |
| rrq | it also has a timeout, so that'd be the /user/rest/mojito app | 22:14 |
| fluffywolf | googling only finds systemd things | 22:15 |
| fluffywolf | with systemctl | 22:15 |
| rustyaxe | in systemdos, the kernel only exists to boot the system, then it takes over and replaces most of the userland with one massive pile of suck :P | 22:16 |
| rrq | afact the dbus protocol only has "start" and not "stop" so it would have to be an internal service function | 22:16 |
| rrq | (and "start" is convoluted of course) | 22:17 |
| fluffywolf | googling says systemctl does it. no idea how it does it. also can change when it starts, prevent it from starting, etc. | 22:17 |
| fluffywolf | sounds like dbus and systemd are very tightly related. | 22:17 |
| rrq | yes | 22:19 |
| fluffywolf | so devuan has dbus, but no tool to manage services in place of systemctl? | 22:20 |
| rrq | the systemd kiddies have hooks into almost everything (elogind, eudev, dbus, ...) and patching around it while preserving useful functionality is becoming impossible | 22:21 |
| rrq | I can't see a sane reason for doing any of what they do, so I assume there's money and commercial interests involved | 22:22 |
| fluffywolf | this is getting into too much of a project than I have time for right now... I don't mean just today, but in general. sounds like a lot of coding is going to be needed to make a more-general solution instead of just making my headphones work for me. | 22:24 |
| won43 | im confused... i see talk about not being able to install/run Mullvad VPN on Devuan because it requires systemd, however it installed/runs just fine for me... why is this? | 22:47 |
| won43 | topics such as this https://github.com/mullvad/mullvadvpn-app/issues/4894 | 22:49 |
| fluffywolf | I'm not familiar with that program, but devuan is continually working on improving compatability, and it could be whatever you saw has been fixed. | 22:49 |
| brocashelm | it's not a debian package, so not forked/blacklisted, which means it's a risk you're willing to take | 22:51 |
| brocashelm | why not use openvpn as your client (whether in command line or with a graphical networking tool like connman) with the mullvad vpn ovpn files? | 22:52 |
| won43 | im just curious why it is working on my system when it should not be... | 22:52 |
| won43 | i do have the systemctl-replacement installed.. | 22:52 |
| won43 | if that might have to do with it | 22:53 |
| fluffywolf | that might definitely have to do with it, and be one of the improvements I mentioned. lol | 22:53 |
| won43 | mullvad, according to them, does not support non-systemd systems | 22:53 |
| won43 | ok | 22:53 |
| won43 | weird | 22:54 |
| fluffywolf | oh, is that the docker-only one? I may be confused. | 22:54 |
| won43 | it's the one that devuan installs by default (i think) | 22:55 |
| won43 | i dont remember installing it. it's definitely in the devuan repos tho | 22:56 |
| won43 | https://i.imgur.com/ItUvgeX.png | 22:57 |
| won43 | oh well. not like im complaining. it works. just odd | 22:57 |
| fluffywolf | it's not odd. things are supposed to work. lol. | 22:58 |
| won43 | like i said, according to mullvad, systemd is required. | 23:00 |
| brocashelm | yeah, the daemonless systemctl that devuan forked exists solely to make such packages "work" | 23:00 |
| brocashelm | if i recall correctly, i had problems getting radeon-profile to install without that faux systemctl | 23:01 |
| won43 | i see | 23:01 |
| fluffywolf | won43: it seems that rather than systemd being required, only systemctl is required. | 23:01 |
| fluffywolf | that is, the program doesn't use any systemd features, just wants systemd to start it, with systemctl. | 23:01 |
| won43 | if that's the case, i wonder why they (mullvad) doesnt offer that as a simple solution. | 23:02 |
| won43 | yes | 23:02 |
| won43 | ok | 23:02 |
| brocashelm | sadly, can't say the same about avoiding certain parts of systemd that are needed for a full desktop experience: elogind and eudev come to mind | 23:02 |
| won43 | im happy :) | 23:03 |
| brocashelm | the dummy-logind exists, but it would require a bit of a workaround to get things like polkit/pkexec "working" | 23:03 |
| brocashelm | consolekit2 might work | 23:03 |
| plasma41 | from a brief glance, it looks like they'd need to generalize their debian package to use the 'service' command rather than the 'systemctl' command in order to work on Devuan without the 'systemctl-replacement' workaround package installed | 23:10 |
| won43 | interesting | 23:12 |
| won43 | yes, it installs fine, but it hangs on a post-install script. however it installs fine, you just need to start the service manually. | 23:12 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
