previous
2022-12-01
20:20:06 <rwp> bbliss, You might try installing a backports kernel in order to get a more recent kernel.
20:20:33 <rwp> For new hardware that needs the newest you might be better off using Unstable kernel bits.
20:21:00 <rwp> The kernel is pretty much separate from the userland and the two different parts of the OS can be different and that is okay.
23:22:09 <gnarface> if raverhaver9000 comes back tell him i meant dkms sorry, that was a bad typo :(
23:22:24 <gnarface> *ravehaver9000
23:22:35 <gnarface> someone should have double checked me on that
23:23:01 <gnarface> dpms has nothing to do with this
23:37:02 <gnarface> man i hope they figure it out
23:37:52 <gnarface> nvidia's driver needs kernel headers and dkms, i feel like that should have been clear by context but i really messed up by saying dpms instead
23:44:45 <gnarface> you don't need dpms but you also shouldn't have to do anything to get it
23:44:52 <gnarface> you do need acpid for the power management to work right
23:45:21 <gnarface> (but it still won't wake up completely correctly from sleep, some graphics or behaviors inevitably will get corrupted)
23:45:38 <gnarface> you might want colord because it can use it, but ... frankly i found the behavior to be annoying so i'd recommend against it
---------- 2022-12-02 ----------
00:02:58 <golinux> gnarface: It happens.
00:18:40 <gnarface> golinux: i blame aliens using mind control satellites to gaslight me
09:06:46 <JFaulk> Morning
09:07:16 <JFaulk> How is everyone?
09:42:32 <nemo> good morning
09:43:14 <nemo> gnarface: oh. on subject of "/etc/init.d/rcS status" and that one app's rather careless scan. do you think it's worth a bugreport to devuan as well?
09:44:02 <nemo> adding if [ "$1" = "status ];then echo "bad invocation";exit;fi to all the servers does seem to have fixed things
10:03:54 <gnarface> nemo: it's a good question, if it's a package from the debian repos i think the policy would be to place the bug report with debian, and if it's not in devuan or debian's repos, i think the official default policy is "nobody cares" but in this case since it's related to something in /etc/init.d/ maybe ask fsmithered if he as a different opinion (my opinion on the matter isn't official)
10:04:37 <gnarface> nemo: the actual misbehavior is with a 3rd party .deb, am i right?
10:06:16 <gnarface> if it's a 3rd party deb i think finding out what they decide to do is key... if they quickly accept blame and fix the behavior in their own tool that would be the easiest way out of this, the goal is to minimize the need to fork more packages in devuan
10:06:48 <gnarface> obviously they will if necessary but we don't want to be piling on more repeating work unnecessarily
10:11:30 <gnarface> actually it's not only about avoiding work, it's also about avoiding changing expected behavior if at all possible too
10:16:44 <nemo> gnarface: it's not with a deb, it's with an "enterprise" scan tool
10:16:54 <nemo> gnarface: the problem being, devuan is already on thin ice over here ☹
10:17:28 <nemo> ManageEngine Desktop Central Agent
10:17:49 <nemo> https://www.manageengine.com/products/desktop-central/
10:19:04 <nemo> I'm going to report it to ManageEngine - I don't count enormously on any success there, because, well I suspect they only barely care about non-systemd these days.
10:19:11 <nemo> the problem with this script is it really is kinda sucky
10:19:17 <nemo> it has no header information describing what it does
10:19:24 <nemo> if you invoke it without params it does not give usage info
10:19:41 <nemo> it's almost impossible to come up with a way to safely request status from non-systemd init.d which contains scripts like this
10:20:18 <nemo> their "list all contents and call status" is clearly problematic, but I'm hard pressed to find a way to do it otherwise aside from asking them to explicitly filter out rcS
10:20:33 <gnarface> well they should really be calling status in /etc/rc?.d/ is the thing
10:20:58 <nemo> that is a good point
10:21:02 <gnarface> where "?" is the current runlevel; that's what the symlinks are there for, they're calling status on scripts that might not even be in the current runlevel
10:21:19 <nemo> thanks. that's a stronger point to make
10:22:35 <gnarface> if that fails and nobody here thinks it's a good idea to alter rcS for this one misbehaved use case, may i recommend forking the package yourself and keeping it in a custom repo?
10:23:10 <gnarface> shouldn't be too hard for just that one change
10:24:22 <gnarface> rcS is in sysv-rc which appears to be entirely plain text
10:24:39 <gnarface> you'd just need to repackage
10:26:28 <gnarface> but the truth is they clearly didn't make sure they knew wtf they're doing when they created that behavior and didn't test it either, they're doing it wrong in a way that not only makes it harder on everyone else, it makes it harder on themselves
10:26:29 <nemo> gnarface: I could, but they do have a lot of customers so it probably doesn't just impact me
10:26:31 <gnarface> hopefully they'll see reason
10:26:38 <nemo> yeah. fingers crossed. I'm writing it up now
10:26:49 <gnarface> heh, hopefully your diplomacy skills are better than mine...
10:28:10 <gnarface> if they can't check the current runlevel (off the top of my head i forget exactly how to do it canonically too) then they can just hardcode it to "2" since it's probably always gonna be "2" on debian based systems
10:28:16 <nemo> they tend to start out well, then degrade after being bounced to the nth representative
10:28:23 <nemo> I made a crude sample of checking
10:28:48 <nemo> /bin/ls /etc/rc$(/sbin/runlevel | /usr/bin/awk '{print $NF}').d/S* | while read f;do "$f" status;done
10:29:33 <gnarface> ah, you're a step ahead of me, clever
10:30:21 <gnarface> i would think that approach should work on just about anything still using sysvinit
10:32:57 <gnarface> not sure but you might want to do it with cut instead of awk though because cut is in coreutils
10:33:14 <nemo> heh. I use what I'm familiar with 😉
10:33:19 <nemo> I don't know if their agent even uses scripts
10:33:22 <nemo> it was more an example
10:34:13 <gnarface> /sbin/runlevel |cut -d ' ' -f 2
10:34:52 <gnarface> to be honest i'm not sure which they'd actually prefer
10:35:09 <nemo> well. we'll see what the agent says
10:35:20 <nemo> my experience with 1st tier is they barely know how to follow the script
10:35:24 <nemo> much less read scripts ☺
10:35:30 <nemo> s/the script/their script/
10:41:50 <gnarface> you could check and see if $RUNLEVEL is defined in that context
10:42:03 <gnarface> the man page for runlevel mentions it but i'm not seeing it in the user's environment
10:42:26 <gnarface> actually maybe cut is safer
10:42:31 <gnarface> nevermind
10:42:41 <gnarface> should work on older systems too
10:46:06 <nemo> they seemed receptive. at least a ticket was filed
10:46:31 <nemo> they tried to get logs but I dodged on "probably not allowed" which might or might not be true, but I really didn't want to go to the effort anyway. the problem was pretty obvious
14:45:20 <Nrml> Howdy everyone. Trying to upgrade a really oldie (still Devuan Jessie), getting this error on `apt-get update`:
14:45:23 <Nrml> E: Release file for http://deb.devuan.org/merged/dists/jessie/InRelease is expired (invalid since 5d 19h 24min 9s). Updates for this repository will not be applied.
14:45:29 <Nrml> How do I work around it?
15:09:00 <rrq> Nrml: "jessie" is moved to archive.devuan.org
15:09:22 <rrq> change your sources.list to only:
15:09:48 <rrq> deb http://archive.devuan.org/merged jessie main contrib non-free
15:10:14 <rrq> (and same with "deb-src" if you need)
15:10:53 <rrq> see https://www.devuan.org/os/packages
15:13:59 <Nrml> thanks rrq! comprehensive answer as always!
2022-12-02
next