| bbliss | rwp, yeah, that's what I'm trying to influence. I'm trying to influence the devuan-dev folks' choices for how to configure the kernel, and which optional modules to include alongside it. Right now, the 6.0.0-5 kernel does not have a suitable driver included or configured. The "linux on T2" wiki indicates that such a kernel module exists, but it's not present in Daedalus by default, apparently? | 00:15 |
|---|---|---|
| bbliss | (required dkms and git clone'ing a random github repo) | 00:15 |
| bbliss | (not sure what mainline Debian is doing with it, though, if anybody happens to know?) | 00:16 |
| rwp | If it requires something from Github then that is probably on you to add as you are doing then. | 00:52 |
| rwp | Since something from a 3rd party on Github means that it has not made it into the Linux kernel main source. | 00:52 |
| rwp | And if it isn't there then I would not expect any software distribution to include it. | 00:52 |
| rwp | Also the Linux kernel packages in Devuan are direct pass-through from Debian. Not just identical but the actual same package. | 00:53 |
| rwp | Devuan is the same as Debian for the kernel and hardware support of this type. | 00:53 |
| rwp | (The Devuan installers are somewhat different however and have included needed firmware.) | 00:54 |
| bbliss | Ok. Seems likely then that Daedalus won't install on Intel MacBooks without a USB keyboard then :-( | 00:54 |
| bbliss | (I tried doing this with Beowulf, it would not boot, I tried Chimaera, it wouldn't boot, Daedalus is the first release that has a >5.7 kernel in the box that can even boot a MacBook. I was assuming more people used Devuan on MacBooks, but apparently nobody does) | 00:56 |
| bbliss | well, T2 macbooks at least, I guess | 00:57 |
| rwp | bbliss, You might try installing a backports kernel in order to get a more recent kernel. | 02:20 |
| rwp | For new hardware that needs the newest you might be better off using Unstable kernel bits. | 02:20 |
| 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. | 02:21 |
| gnarface | fuck | 05:21 |
| gnarface | if raverhaver9000 comes back tell him i meant dkms sorry, that was a bad typo :( | 05:22 |
| gnarface | *ravehaver9000 | 05:22 |
| gnarface | someone should have double checked me on that | 05:22 |
| gnarface | dpms has nothing to do with this | 05:23 |
| gnarface | man i hope they figure it out | 05:37 |
| 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 | 05:37 |
| gnarface | you don't need dpms but you also shouldn't have to do anything to get it | 05:44 |
| gnarface | you do need acpid for the power management to work right | 05:44 |
| gnarface | (but it still won't wake up completely correctly from sleep, some graphics or behaviors inevitably will get corrupted) | 05:45 |
| 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 | 05:45 |
| golinux | gnarface: It happens. | 06:02 |
| gnarface | golinux: i blame aliens using mind control satellites to gaslight me | 06:18 |
| JFaulk | Morning | 15:06 |
| JFaulk | How is everyone? | 15:07 |
| nemo | good morning | 15:42 |
| 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? | 15:43 |
| nemo | adding if [ "$1" = "status ];then echo "bad invocation";exit;fi to all the servers does seem to have fixed things | 15:44 |
| 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) | 16:03 |
| gnarface | nemo: the actual misbehavior is with a 3rd party .deb, am i right? | 16:04 |
| 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 | 16:06 |
| gnarface | obviously they will if necessary but we don't want to be piling on more repeating work unnecessarily | 16:06 |
| gnarface | actually it's not only about avoiding work, it's also about avoiding changing expected behavior if at all possible too | 16:11 |
| nemo | gnarface: it's not with a deb, it's with an "enterprise" scan tool | 16:16 |
| nemo | gnarface: the problem being, devuan is already on thin ice over here ☹ | 16:16 |
| nemo | ManageEngine Desktop Central Agent | 16:17 |
| nemo | https://www.manageengine.com/products/desktop-central/ | 16:17 |
| 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. | 16:19 |
| nemo | the problem with this script is it really is kinda sucky | 16:19 |
| nemo | it has no header information describing what it does | 16:19 |
| nemo | if you invoke it without params it does not give usage info | 16:19 |
| 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 | 16:19 |
| 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 | 16:20 |
| gnarface | well they should really be calling status in /etc/rc?.d/ is the thing | 16:20 |
| nemo | hm | 16:20 |
| nemo | that is a good point | 16:20 |
| 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 | 16:21 |
| nemo | thanks. that's a stronger point to make | 16:21 |
| 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? | 16:22 |
| gnarface | shouldn't be too hard for just that one change | 16:23 |
| gnarface | rcS is in sysv-rc which appears to be entirely plain text | 16:24 |
| gnarface | you'd just need to repackage | 16:24 |
| 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 | 16:26 |
| nemo | gnarface: I could, but they do have a lot of customers so it probably doesn't just impact me | 16:26 |
| gnarface | hopefully they'll see reason | 16:26 |
| nemo | yeah. fingers crossed. I'm writing it up now | 16:26 |
| gnarface | heh, hopefully your diplomacy skills are better than mine... | 16:26 |
| nemo | heh | 16:28 |
| 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 | 16:28 |
| nemo | they tend to start out well, then degrade after being bounced to the nth representative | 16:28 |
| nemo | I made a crude sample of checking | 16:28 |
| nemo | /bin/ls /etc/rc$(/sbin/runlevel | /usr/bin/awk '{print $NF}').d/S* | while read f;do "$f" status;done | 16:28 |
| gnarface | ah, you're a step ahead of me, clever | 16:29 |
| gnarface | i would think that approach should work on just about anything still using sysvinit | 16:30 |
| gnarface | not sure but you might want to do it with cut instead of awk though because cut is in coreutils | 16:32 |
| nemo | heh. I use what I'm familiar with 😉 | 16:33 |
| nemo | I don't know if their agent even uses scripts | 16:33 |
| nemo | it was more an example | 16:33 |
| gnarface | /sbin/runlevel |cut -d ' ' -f 2 | 16:34 |
| gnarface | to be honest i'm not sure which they'd actually prefer | 16:34 |
| nemo | yep. | 16:35 |
| nemo | well. we'll see what the agent says | 16:35 |
| nemo | my experience with 1st tier is they barely know how to follow the script | 16:35 |
| nemo | much less read scripts ☺ | 16:35 |
| nemo | s/the script/their script/ | 16:35 |
| gnarface | you could check and see if $RUNLEVEL is defined in that context | 16:41 |
| gnarface | the man page for runlevel mentions it but i'm not seeing it in the user's environment | 16:42 |
| gnarface | actually maybe cut is safer | 16:42 |
| gnarface | nevermind | 16:42 |
| gnarface | should work on older systems too | 16:42 |
| nemo | they seemed receptive. at least a ticket was filed | 16:46 |
| 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 | 16:46 |
| Nrml | Howdy everyone. Trying to upgrade a really oldie (still Devuan Jessie), getting this error on `apt-get update`: | 20:45 |
| 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. | 20:45 |
| Nrml | How do I work around it? | 20:45 |
| rrq | Nrml: "jessie" is moved to archive.devuan.org | 21:09 |
| rrq | change your sources.list to only: | 21:09 |
| rrq | deb http://archive.devuan.org/merged jessie main contrib non-free | 21:09 |
| rrq | (and same with "deb-src" if you need) | 21:10 |
| rrq | see https://www.devuan.org/os/packages | 21:10 |
| Nrml | thanks rrq! comprehensive answer as always! | 21:13 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!