| jkfwhf | how to configure what power button (the actual button, not on keyboard) does? | 02:25 |
|---|---|---|
| jkfwhf | e.g. so it does nothing | 02:26 |
| gnarface | on a PC with a ATX power supply? you just unplug it from the motherboard | 02:27 |
| gnarface | of course then turning it back on becomes a complication... | 02:27 |
| gnarface | usually a decent BIOS/EFI will have some behavioral variations for it but "disabled" usually isn't one of them | 02:29 |
| gnarface | i suppose you might be able to get it to still power up by keyboard in some of those cases, so maybe unplugging it isn't a showstopper | 02:30 |
| fsmithred_ | tape a bottle cap over the power button | 02:32 |
| rwp | jkfwhf, Power events in Linux are handled through the ACPI system. | 03:13 |
| rwp | Everyone will want acpi-support-base and acpid installed but if you remove those then the power button generally stops working. | 03:13 |
| rwp | I suggest keeping those installed and then looking at /etc/acpi/powerbtn-acpi-support.sh for how things work and adjusting things there. | 03:14 |
| rwp | But you could remove the package as a brute force approach. | 03:14 |
| jkfwhf | gnarface I mean, the linux hooks when device driver detect button press | 03:49 |
| jkfwhf | only long-power-button-press causes firmware to actually shut down power. short press makes it send some ACPI event or something | 03:50 |
| jkfwhf | short press is on OS-level | 03:50 |
| jkfwhf | on Debian it is https://wiki.debian.org/ConfigurePowerButton /etc/acpi/events/powerbtn-acpi-support | 03:51 |
| jkfwhf | but on Devuan? I guess other init system may play a role, maybe other dev (udev???) and overall things can change, so I thought better ask here. | 03:51 |
| jkfwhf | rwp right, so no change from Debian? | 03:52 |
| rwp | jkfwhf, No change from Debian. And you are right that the long push hold 10 seconds power drop is motherboard firmware. Would need to unplug the wire to avoid that. | 04:05 |
| rwp | Devuan is an overlay of about 100 some packages only to avoid systemd dependencies and acpi is not one of the forked ones. | 04:06 |
| rwp | For everything else Devuan is Debian verbatim. | 04:06 |
| rwp | AFAIK the init system is not related to the initial triggering of power (and laptop lid) events. But on Debian systemd does take over all of those events after the event has been triggered. | 04:08 |
| gnarface | jkfwhf: no, depends on motherboard firmware settings | 04:15 |
| gnarface | there's some opportunity for software hooks in there but for them to work the motherboard has to allow it | 04:16 |
| gnarface | and actually safely making it do nothing from userspace software, i can't be sure that's possible with all harware | 04:17 |
| gnarface | hardware* | 04:17 |
| gnarface | if the bios is set to something like "pwrbttn < 4s: instant off" it's gonna shut off | 04:18 |
| gnarface | ymmv | 04:18 |
| rwp | Unplug the wire. | 04:21 |
| gnarface | i could imagine with newer laptops that don't have that bios setting and only have a soft power button to begin with, things may be different | 04:22 |
| gnarface | but on your typical PC where the power button connects by two wires to the motherboard, the motherboard firmware is what gets first pick at what happens | 04:23 |
| gnarface | and their options to hand off different button-length presses to userspace vary | 04:23 |
| gnarface | true though, acpi is what handles that in userspace, so whatever options there are are in those scripts | 04:24 |
| gnarface | (systemd absorbed that functionality into itself afaik) | 04:25 |
| gnarface | you can probably stop it from going to sleep or hibernating on button press, but you probably cannot completely disable it | 04:25 |
| gnarface | anyway, i don't mean to discourage you from looking into acpi, but i thought you just wanted to be sure it was completely inert | 04:27 |
| gnarface | and note that if you do end up just unplugging it for those reasons, you'll probably want to unplug the reset button too (if furnished) | 04:29 |
| gnarface | rwp: wait, systemd didn't replace acpid? i thought they did | 05:13 |
| gnarface | or did they just not remove it yet | 05:14 |
| mason | It's still packaged. | 05:21 |
| mason | acpid and acpica-tools | 05:21 |
| gnarface | do they actually use it or does systemd supersede it in their default installs? | 05:22 |
| mason | ur, acpica-tools might be something quite different | 05:23 |
| mason | gnarface: Pretty sure systemd-logind has oozed over that domain as well. | 05:23 |
| mason | but they work if you use sysvinit etc. | 05:23 |
| jkfwhf | file /etc/acpi/events/powerbtn-acpi-support doesnt exist | 06:08 |
| jkfwhf | there area other files in that dir, for lid and AC power | 06:10 |
| jkfwhf | nevermind all ok. just install acpid | 06:15 |
| jkfwhf | still happens... something else handles that acpi event?? | 06:22 |
| jkfwhf | putting exit 1 on top of that script doesnt help... | 06:35 |
| gnarface | jkfwhf: i seem to recall there being some other source of scripts... not sure what package they're in but they might get pulled in if you install the "task-laptop" meta-package | 06:52 |
| gnarface | have you looked at the bios settings at all for this machine? | 06:53 |
| gnarface | there may or may not be something relevant in there | 06:53 |
| gnarface | some setting about power button handling switched from something like "instant-off" to "soft-off" may enable handoff to the script | 06:54 |
| gnarface | no guarantees they'll have furnished such an option but worth looking anyway | 06:54 |
| rrq | jkfwhf: if you have elogin installed, then it will want to handle "power key' and power off the system. | 07:02 |
| rrq | edit /etc/elogind/logind.conf and make HandlePowerKey=ignore | 07:02 |
| jkfwhf | *linux moment* | 07:26 |
| jkfwhf | 52 ways to do things, mostly conflicting and with no good central roadmap nor list what does what. at least it's not the sound subsystem | 07:26 |
| jkfwhf | gnarface it is ACPI event, the linux handles it. probably the elong thing | 07:27 |
| jkfwhf | elogind was installed. but changing to =ignore did NOT help | 07:33 |
| rrq | after restarted logind ? | 07:33 |
| jkfwhf | restarted entire machine | 07:34 |
| gnarface | oh, i keep forgetting elogind can handle it too. i'm not using that here. | 07:34 |
| jkfwhf | sadly who-ever handles it, doesn't seem to write to system log to admit it's him | 07:34 |
| jkfwhf | a common sin among developers | 07:35 |
| gnarface | could still happening in the bios then | 07:35 |
| jkfwhf | gnarface no... how | 07:35 |
| jkfwhf | gnarface linux is reacting. it's not computer cutting power. | 07:35 |
| gnarface | oh, you see a shutdown process happen? | 07:35 |
| jkfwhf | yea | 07:36 |
| gnarface | you sure absolutely nothing in the logs? tried tailing them all at once? | 07:36 |
| jkfwhf | how to tell org.bluez to not spam logs? | 07:36 |
| rrq | maye some "power management" thingy with the desktop environment? like "upower" ? | 07:36 |
| gnarface | bluez is related to bluetooth, but org.* stuff might be coming from dbus i think | 07:37 |
| gnarface | or ... gvfsd or whatever that's called, if you installed it | 07:37 |
| jkfwhf | it exits with code 1, like 100 times | 07:37 |
| rrq | with "dpkg -l | grep -i power" you'd get a package list | 07:38 |
| gnarface | are you using bluetooth? | 07:38 |
| jkfwhf | hardware for it is not present, no | 07:38 |
| gnarface | maybe if you just disable /etc/init.d/bluetooth temporarily that'll be enough to stop the log spam while you check for acpi events | 07:39 |
| gnarface | i'm sure there's a better way to do it | 07:39 |
| gnarface | although, now that i'm thinking of it, maybe you're missing firmware and that's why it's exiting `1 | 07:39 |
| gnarface | check "dmesg |grep -i firmware" for errors | 07:39 |
| gnarface | it's pretty common for bluetooth devices to need non-free firmware | 07:40 |
| jkfwhf | shutdown: shutting down for system halt (but will not tell you why, lol) | 07:40 |
| jkfwhf | init: Switching to runlevel: 0 | 07:41 |
| jkfwhf | nothing more | 07:43 |
| jkfwhf | I am in text console while pressing power. no DM is running at all | 07:43 |
| gnarface | you remembered to uncomment that HandlePowerKey line, right? | 07:44 |
| jkfwhf | yes | 07:45 |
| jkfwhf | =ignore | 07:45 |
| gnarface | make sure that line has no "#" at the front of it | 07:45 |
| gnarface | and the line you put in the acpi script, is it still there? | 07:46 |
| jkfwhf | the exit 1, yes | 07:47 |
| gnarface | maybe add an echo | 07:47 |
| jkfwhf | hours-days of debugging can save you minutes of adding printf debug explaining who does what and why ;) | 07:47 |
| gnarface | i'm sure there's a better way to deal with this but i am not an expert on shutting down computers. i usually just leave mine on. | 07:48 |
| gnarface | which release were you on? chimaera? daedalus? | 07:49 |
| jkfwhf | chimeaera | 07:50 |
| rrq | hmm there seems to be a udev rules file talking power button; mayb trye disarming that file by making an empty same-named file in /etc/udev/rules.d/ | 07:54 |
| rrq | less /lib/udev/rules.d/70-power-switch.rules | 07:54 |
| jkfwhf | added "logger" to the ACPI script. it IS called when I press button. yes, still, despite exit 1 right below it, shutdown[2310]: shutting down for system halt happens in same second | 07:55 |
| jkfwhf | should user just edit /lib/udev/ files? I guess a work around for now but | 07:57 |
| gnarface | no you should put your versions in /etc/udev/rules.d | 07:57 |
| gnarface | should override the ones named the same i think... | 07:58 |
| gnarface | test that to be sure | 07:58 |
| jkfwhf | k | 07:58 |
| jkfwhf | reload somehow? | 07:58 |
| rrq | restarting udev or eudev should be ok | 07:58 |
| jkfwhf | created empty 70-power.......rules there in /etc/.... | 07:58 |
| jkfwhf | restarted. power button still did same thing - linux shutdown | 07:59 |
| gnarface | why would the acpid script continue after exit 1? that's not a bash vs dash difference is it? | 07:59 |
| jkfwhf | im pretty sure it exits, but something else runs other script or just a program sees event and does some syscall? | 08:00 |
| jkfwhf | will add more debug to confirm exit worked | 08:00 |
| gnarface | jkfwhf: do you have a file at /etc/acpi/events/powerbtn-acpi-support? | 08:01 |
| gnarface | or anything else in /etc/acpi/events/ for that matter? | 08:01 |
| rrq | I missed some backlog: the "exit 1" statememnt is in /etc/acpi/powerbtn-acpi-support.sh i guess | 08:03 |
| jkfwhf | all else is as default | 08:03 |
| rrq | did you try stoping acipd, udevd and elogind-daemon then check the power button ... if it still reacts, then it's something additional | 08:05 |
| jkfwhf | fixxeed | 08:05 |
| * jkfwhf wonders what he did last | 08:05 | |
| rrq | great | 08:06 |
| jkfwhf | I removed also brtltty and task-console-productivity to stop log spam... but why power btn disabling works now | 08:06 |
| jkfwhf | pressing button sure calls the /etc/acpi/powerbtn....sh, and the exit 1 there DOES work | 08:06 |
| gnarface | maybe it's the type of thing where you had to disable all the possible handlers at once | 08:10 |
| jkfwhf | ok it was the empty /etc/udev/rules.d/70-power-switch.rules though this change takes effect after reboot of computer, not after service restart eudev | 08:11 |
| jkfwhf | (and probably as well needs the change to /etc/acpi/powerbtn.... yes) | 08:12 |
| gnarface | yea, udev rules are weirdly sticky... i've found that when i'm working on them i had to figure out a double udevadm call to actually fully flush them without rebooting the whole machine | 08:13 |
| gnarface | i forget exactly but it's not always enough to just restart udev with the init script, but you can pull it off with udevadm, i think called twice with different parameters | 08:13 |
| gnarface | or maybe just one udevadm call then restarting udev, not sure | 08:13 |
| jkfwhf | isnt udev just creating devices? who handles that, if not just the /etc/acpi/powerbtn | 08:14 |
| gnarface | i don't know, but i know it's not just limited to creating devices, it can also be running commands or assigning scripts to events related to them | 08:16 |
| gnarface | check that original 70-power-switch.rules for clues maybe. i don't have that one here. | 08:16 |
| gnarface | for all i know there could be a line in there hardcoded to call shutdown directly | 08:19 |
| * jkfwhf enjoys pressing the power button while nothing happens at all | 08:19 | |
| jkfwhf | another victory of humans over machines | 08:20 |
| gnarface | you should make it play sounds | 08:20 |
| jkfwhf | that leads to the other problems mentioned above - soundsystems - hot seating... how to even play sound in console 1 while I am in console 2? not to mention from a script run on no seat by root | 08:20 |
| gnarface | well pulseaudio and pipewire and the like can significantly complicate this, but they both rely on alsa and any user in the "audio" group should be able to access alsa | 08:21 |
| jkfwhf | and not in group audio? only white his seat is active? | 08:22 |
| gnarface | i'm not even sure seats have anything to do with it where they're relevant, which afaik was after chimaera | 08:23 |
| gnarface | pulseaudio and pipewire might react to seatd in some way on later releases, i don't know | 08:23 |
| gnarface | the last release i have relevant pulseaudio experience with though is beowulf, and there it's just about whoever is logged in currently | 08:24 |
| gnarface | in the default configuration i'd seen, pulseaudio was started by kde as the logged-in user | 08:24 |
| gnarface | audio group may have been necessary still, not sure | 08:24 |
| gnarface | note that this is something systemd will do differently, as systemd just grants full admin access to all devices to the logged in user | 08:26 |
| gnarface | it basically just ignores permissions in /dev/ if you're locally logged in | 08:26 |
| gnarface | just start by putting yourself in the audio group and assume that only root can play audio otherwise | 08:27 |
| gnarface | pulseaudio might obviate that while you're logged in but i'm not sure | 08:28 |
| gnarface | (the benefit of this of course is that you can play sounds while not logged in too, if you wish) | 08:39 |
| gnarface | (for example on a timer, or while logged in remotely) | 08:39 |
| brocashelm | if i want to use daedalus, how would i be able to pin certain packages from ceres (because they aren't available on daedalus)? for example, packages like corectrl, which are only found on ceres and (eventually) excalibur | 09:47 |
| clemens3 | I just read: https://weblog.antranigv.am/posts/2023/08/freebsd-jail-devuan-linux-openrc/ | 11:07 |
| clemens3 | very col | 11:07 |
| clemens3 | col=cool | 11:08 |
| bb|hcb | brocashelm: I can share what I would do - get the package source and build a backported .deb for daedalus... Like apt -t ceres source package; apt build-dep package; etc, etc... | 13:33 |
| EHeM | The backports archive has version 6.1.27-1~bpo11+1 of linux-source-6.1, but unstable has 6.1.38-1; given the current situation I get the suspicion backports is lagging a bit on security updates. | 20:52 |
| EHeM | Hmm, perhaps not. | 20:55 |
| EHeM | Hrmm, looks like unstable though is lagging a bit since Debian had 6.1.38-2, 3 days ago. | 20:58 |
| EHeM | (this is also a security update so a bit urgent) | 21:08 |
| Guest58 | quick Q | 22:07 |
| debdog | faster A | 22:08 |
| Guest58 | running Chimaera, is there a package for python 3.8 that I missing? needed for dependancies for a manual package | 22:08 |
| Guest58 | trying to upgrade OBS to something compiled in the last two years, as teh default package is VERY out of date | 22:10 |
| debdog | can you provide a detailed error message? maybe a file it's looking for or such | 22:11 |
| Guest58 | apt install ./obs-studio_29.1.3-0obsproject1.focal_amd64.deb | 22:11 |
| Guest58 | Reading package lists... Done | 22:11 |
| Guest58 | Building dependency tree... Done | 22:11 |
| Guest58 | Reading state information... Done | 22:11 |
| Guest58 | Note, selecting 'obs-studio' instead of './obs-studio_29.1.3-0obsproject1.focal_amd64.deb' | 22:11 |
| Guest58 | Some packages could not be installed. This may mean that you have | 22:11 |
| Guest58 | requested an impossible situation or if you are using the unstable | 22:11 |
| Guest58 | distribution that some required packages have not yet been created | 22:11 |
| Guest58 | or been moved out of Incoming. | 22:11 |
| Guest58 | The following information may help to resolve the situation: | 22:11 |
| Guest58 | The following packages have unmet dependencies: | 22:11 |
| Guest58 | obs-studio : Depends: libpython3.8 (>= 3.8.2) but it is not installable | 22:12 |
| Guest58 | Depends: libx264-155 but it is not installable | 22:12 |
| Guest58 | E: Unable to correct problems, you have held broken packages. | 22:12 |
| Guest58 | python3 --version | 22:13 |
| Guest58 | Python 3.9.2 | 22:13 |
| debdog | I do not actually use python so this is just a guess: it explicitly looks for "libpython3.8" and not 3.9 | 22:16 |
| Guest58 | all this cased by wanting an OBS version that is somewhat recent, as the version in teh repo is more than 2 years old. | 22:16 |
| Guest58 | (26.1.2, released jan 8th, 2021) | 22:17 |
| Guest58 | Yes, ists dep'd on 3.8 | 22:18 |
| debdog | mayhap you're able to download that package somewhere and install it manually. (dpkg prolly will warn you if it conflicts with the 3.9 version) | 22:19 |
| Guest58 | yeah. I may have to try that. of course the repo search is useless. it tells me the package exists, but not where... | 22:21 |
| Guest58 | maybe I'll get luck an its in one of the additional repos | 22:22 |
| jonadab | Python is a real pain about version compatibility, more than nearly any other language. | 22:24 |
| debdog | https://packages.debian.org/search?keywords=libpython3.8&searchon=names&suite=all§ion=all that is not encouraging. maybe the OBS folks know how to satisfy that dependency? | 22:24 |
| jonadab | Code written for one verison won't necessarily work with a later version. | 22:24 |
| Guest58 | python is a pain, period. | 22:24 |
| jonadab | Which, all languages occasionally have instances of that. | 22:24 |
| jonadab | But Python has more than its fair share of it. | 22:25 |
| Guest58 | I've never liked python, probably never will. whitespace is NOT a deliminator. | 22:25 |
| jonadab | I'm not a huge fan of it either. | 22:25 |
| debdog | butbutbut... what about Monty? | 22:26 |
| jonadab | Though it's better than Node.js | 22:26 |
| jonadab | debdog: Monty is full. | 22:26 |
| jonadab | Why do you ask? | 22:26 |
| * Guest58 bangs head against the wall. | 22:27 | |
| debdog | well.... Monty... Python... | 22:28 |
| jonadab | That's a deep subject. | 22:28 |
| Guest58 | MInistry os Silly Codes. | 22:28 |
| Guest58 | I'll try reaching out to the OBS devs and ask WTF... | 22:32 |
| debdog | search results suggest there may have been a libpython3.8 package for debian, like https://packages.debian.org/de/sid/libpython3.8-dev | 22:33 |
| Guest58 | BUT, at the same time... why teh feck does the chimaera repo have a package that was deprecated almost 3 years ago.... | 22:33 |
| debdog | mayhap it never went stable | 22:33 |
| debdog | well, chimaera is quite old by now | 22:33 |
| debdog | you may update to daedalus | 22:34 |
| Guest58 | didn't realize that was a thing | 22:35 |
| Guest58 | latest release on the website is chimaera | 22:35 |
| jonadab | Man, I'm still trying to track down and update all the systems that still have beowulf. | 22:36 |
| debdog | well, it's not quite release yet (but that, AFAIK, is because of the installer and not the repos) | 22:36 |
| jonadab | Well, by "trying" I mean I will get around to it eventually. | 22:36 |
| debdog | *released | 22:36 |
| jonadab | Ah, so is it probably going to release relatively soon then? Interesting. | 22:37 |
| * Guest58 shrugs. its worth a shot. apt-get distro-upgrade. ;) | 22:37 | |
| jonadab | I will keep a weather eye peeled for that. | 22:37 |
| debdog | Guest58: just out of curiousity, what is OBS? | 22:38 |
| debdog | ahh, obs-studio | 22:38 |
| Guest58 | Open Broadcast Studio | 22:39 |
| jonadab | Desktop recording and streaming software. | 22:39 |
| Guest58 | redundant package name is stupid | 22:39 |
| debdog | Guest58: daedalus ships with version obs-studio (29.0.2+dfsg-1 | 22:39 |
| jonadab | Guest58: It's not redundant, it's recursive. | 22:40 |
| Guest58 | yeah, that will fix most of my problem | 22:40 |
| jonadab | Recursive RAS-Syndrom acronyms are often helpful for clarity. | 22:41 |
| bb|hcb | Guest58: daedalus is ready and released, just install .ISO files and website are not ready. If you upgrade, you should be file | 22:42 |
| Guest58 | time to edit sources then. ;-) | 22:42 |
| debdog | I was just looking at OBS' build instructions and they are not straight forward... https://github.com/obsproject/obs-studio/wiki/build-instructions-for-linux | 22:43 |
| jonadab | Can't be any more complicated than building OpenSRF. | 22:44 |
| Guest58 | no, their build instructions are far worse than 'non-straightforward' | 22:44 |
| Guest58 | probably qualify as total-shite | 22:44 |
| debdog | hehe | 22:44 |
| debdog | well, not that funny, actually | 22:44 |
| Guest58 | nope | 22:44 |
| jonadab | Oh, eww, cmake. | 22:45 |
| Guest58 | but its true, so we laugh so we dont cry. | 22:45 |
| jonadab | *Still* not as bad as OpenSRF/OpenILS. | 22:45 |
| Guest58 | kicking off the upgrade now. finders crossed. | 22:47 |
| Guest58 | *fingers | 22:48 |
| Guest58 | hopefully it doesn't fuck up all of my pulseaudio fixes... | 22:48 |
| jonadab | Good luck with that. pulseaudio is ridiculously brittle. | 22:49 |
| Guest58 | audio on linux is rediculously fucking bad. | 22:50 |
| bb|hcb | ... and reason #1 is pulse :( | 22:50 |
| jonadab | It didn't matter so much that avahi was brittle, because absolutely nothing depended on it working, so when it broke, nobody noticed. | 22:50 |
| jonadab | There were issues even before pulse. Mostly related to some software wanting to use esound and other software not wanting to use esound. | 22:51 |
| Guest58 | maybe I'll get lucky and this will fix my sudoers issue as well. | 22:51 |
| jonadab | But yes, pulse is bad. | 22:51 |
| jonadab | The stated issues that it was supposed to solve, were real issues, and the features it promised, would be useful if they worked. | 22:52 |
| Guest58 | linux audio has been flakey since kernel 0.5, when audio started working... | 22:52 |
| jonadab | If it had had something like esound from the very early days, it would've been better. Because pretty much everything could've used that. | 22:53 |
| jonadab | But because it was introduced too late, a lot of software didn't use it. | 22:53 |
| jonadab | And that created problems. | 22:53 |
| jonadab | ALSA for its part is good, but does not provide everything that's wanted. | 22:54 |
| Guest58 | yeah, and there was a lot of drama around ALSA for a while. | 22:55 |
| jonadab | Oh, I don't remember that; perhaps I was oblivious to it. | 22:57 |
| Guest58 | was around 2002 | 22:58 |
| Guest58 | really early years | 22:58 |
| jonadab | I mean, I started using Debian in 1998. | 22:58 |
| jonadab | Back in the dselect era. Wasn't *that* a pile of garbage. | 22:59 |
| Guest58 | there were some real flame wars about linux audio for a while | 22:59 |
| Guest58 | I remember how happy I was when the first slak release happened and we could stop hex-editing bootloaders onto the drives. | 23:00 |
| debdog | maybe that's because of re-engineering because manufacturers became more secretive about their audio chip's datasheets | 23:01 |
| Guest58 | might get dropped with the upgrade | 23:02 |
| Guest58 | but yeah, linux audio has never been great, which sucks | 23:04 |
| Guest58 | because there's so many good OSS audio tools | 23:05 |
| brocashelm | bb|hcb: ok, i'll try that later, thanks | 23:07 |
| brocashelm | (regarding the backports for daedalus) | 23:07 |
| EHeM | Guest58: You're overrating how good Linux audio isn't. | 23:09 |
| jonadab | Eh, it's not really that much worse than BSD. | 23:15 |
| Guest5811 | yeah, it dropped me | 23:22 |
| Guest5811 | oh well | 23:22 |
| Guest5811 | at least my OBS upgraded ;) | 23:23 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!