previous
2022-12-01
10:20:06 <rwp> bbliss, You might try installing a backports kernel in order to get a more recent kernel.
10:20:33 <rwp> For new hardware that needs the newest you might be better off using Unstable kernel bits.
10: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.
13:22:09 <gnarface> if raverhaver9000 comes back tell him i meant dkms sorry, that was a bad typo :(
13:22:24 <gnarface> *ravehaver9000
13:22:35 <gnarface> someone should have double checked me on that
13:23:01 <gnarface> dpms has nothing to do with this
13:37:02 <gnarface> man i hope they figure it out
13: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
13:44:45 <gnarface> you don't need dpms but you also shouldn't have to do anything to get it
13:44:52 <gnarface> you do need acpid for the power management to work right
13:45:21 <gnarface> (but it still won't wake up completely correctly from sleep, some graphics or behaviors inevitably will get corrupted)
13: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
14:02:58 <golinux> gnarface: It happens.
14:18:40 <gnarface> golinux: i blame aliens using mind control satellites to gaslight me
23:06:46 <JFaulk> Morning
23:07:16 <JFaulk> How is everyone?
23:42:32 <nemo> good morning
23: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?
23:44:02 <nemo> adding if [ "$1" = "status ];then echo "bad invocation";exit;fi to all the servers does seem to have fixed things
---------- 2022-12-02 ----------
00: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)
00:04:37 <gnarface> nemo: the actual misbehavior is with a 3rd party .deb, am i right?
00: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
00:06:48 <gnarface> obviously they will if necessary but we don't want to be piling on more repeating work unnecessarily
00:11:30 <gnarface> actually it's not only about avoiding work, it's also about avoiding changing expected behavior if at all possible too
00:16:44 <nemo> gnarface: it's not with a deb, it's with an "enterprise" scan tool
00:16:54 <nemo> gnarface: the problem being, devuan is already on thin ice over here ☹
00:17:28 <nemo> ManageEngine Desktop Central Agent
00:17:49 <nemo> https://www.manageengine.com/products/desktop-central/
00: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.
00:19:11 <nemo> the problem with this script is it really is kinda sucky
00:19:17 <nemo> it has no header information describing what it does
00:19:24 <nemo> if you invoke it without params it does not give usage info
00: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
00: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
00:20:33 <gnarface> well they should really be calling status in /etc/rc?.d/ is the thing
00:20:58 <nemo> that is a good point
00: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
00:21:19 <nemo> thanks. that's a stronger point to make
00: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?
00:23:10 <gnarface> shouldn't be too hard for just that one change
00:24:22 <gnarface> rcS is in sysv-rc which appears to be entirely plain text
00:24:39 <gnarface> you'd just need to repackage
00: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
00:26:29 <nemo> gnarface: I could, but they do have a lot of customers so it probably doesn't just impact me
00:26:31 <gnarface> hopefully they'll see reason
00:26:38 <nemo> yeah. fingers crossed. I'm writing it up now
00:26:49 <gnarface> heh, hopefully your diplomacy skills are better than mine...
00: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
00:28:16 <nemo> they tend to start out well, then degrade after being bounced to the nth representative
00:28:23 <nemo> I made a crude sample of checking
00:28:48 <nemo> /bin/ls /etc/rc$(/sbin/runlevel | /usr/bin/awk '{print $NF}').d/S* | while read f;do "$f" status;done
00:29:33 <gnarface> ah, you're a step ahead of me, clever
00:30:21 <gnarface> i would think that approach should work on just about anything still using sysvinit
00:32:57 <gnarface> not sure but you might want to do it with cut instead of awk though because cut is in coreutils
00:33:14 <nemo> heh. I use what I'm familiar with 😉
00:33:19 <nemo> I don't know if their agent even uses scripts
00:33:22 <nemo> it was more an example
00:34:13 <gnarface> /sbin/runlevel |cut -d ' ' -f 2
00:34:52 <gnarface> to be honest i'm not sure which they'd actually prefer
00:35:09 <nemo> well. we'll see what the agent says
00:35:20 <nemo> my experience with 1st tier is they barely know how to follow the script
00:35:24 <nemo> much less read scripts ☺
00:35:30 <nemo> s/the script/their script/
00:41:50 <gnarface> you could check and see if $RUNLEVEL is defined in that context
00:42:03 <gnarface> the man page for runlevel mentions it but i'm not seeing it in the user's environment
00:42:26 <gnarface> actually maybe cut is safer
00:42:31 <gnarface> nevermind
00:42:41 <gnarface> should work on older systems too
00:46:06 <nemo> they seemed receptive. at least a ticket was filed
00: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
04:45:20 <Nrml> Howdy everyone. Trying to upgrade a really oldie (still Devuan Jessie), getting this error on `apt-get update`:
04: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.
04:45:29 <Nrml> How do I work around it?
05:09:00 <rrq> Nrml: "jessie" is moved to archive.devuan.org
05:09:22 <rrq> change your sources.list to only:
05:09:48 <rrq> deb http://archive.devuan.org/merged jessie main contrib non-free
05:10:14 <rrq> (and same with "deb-src" if you need)
05:10:53 <rrq> see https://www.devuan.org/os/packages
05:13:59 <Nrml> thanks rrq! comprehensive answer as always!
2022-12-02
next