| rrq | both echi and xhci would be (guest) kernel drivers and not something Devuan has forked or changed. | 00:31 |
|---|---|---|
| systemdlete | so kernel drivers are not forked by Devuan? | 00:32 |
| rrq | no. | 00:32 |
| systemdlete | I knew that ?hci would be guest-side drivers, but I wasn't sure about the extent of changes by Devuan. Thanks. | 00:33 |
| rrq | does vbox model any particular host controller? | 00:34 |
| systemdlete | it models ohci, ehci, and xhci | 00:34 |
| systemdlete | you can choose one of them for each individual VM | 00:34 |
| rrq | yes that's the type; but which specific chips do the emulate? | 00:35 |
| systemdlete | oh | 00:35 |
| systemdlete | lsusb reports "Linux Foundation 2.0 root hub" and "Linux Foundation 1.1 root hub" | 00:36 |
| systemdlete | on a VM that I've selected as USB 2.0 | 00:36 |
| systemdlete | Not sure that answers your question or not. | 00:37 |
| rrq | mmm for qemu I define both host and port device; | 00:38 |
| rrq | ehci would be the host device | 00:38 |
| rrq | and, say, scsi-cd may be the port device | 00:39 |
| systemdlete | Well, for vbox, I think selecting the type would be the host-side emulation mode. | 00:39 |
| rrq | or usb-storage perhaps | 00:39 |
| systemdlete | So the VM would see the usb bus as a ehci or xhci device | 00:40 |
| systemdlete | I'd think the interface would be about the same for any chipset, wouldn't it? | 00:40 |
| systemdlete | I don't believe that vbox will care what the guest does with it, aside from violating a protocol in the interface, of course--it would reply with an error of some kind for the guest to handle | 00:41 |
| onefang | Could be the "about" part that's your problem. Different enough to trip you up. Just a wild guess. | 00:42 |
| systemdlete | Sure. At this point, anything could be the cause. | 00:42 |
| systemdlete | Just the fact that it depends on the amount of memory alloc'd to the VM makes me hesitate to point in ANY direction. | 00:43 |
| systemdlete | Weirder still is the fact that as you INCREASE RAM, the problem appears. | 00:43 |
| rrq | so RAM size is related to USB stick size? | 00:44 |
| systemdlete | Eh... not sure what you mean | 00:44 |
| systemdlete | The ram stick doesn't change in size... | 00:44 |
| rrq | wasn't that what you said? | 00:44 |
| systemdlete | no | 00:44 |
| systemdlete | I meant as you increase RAM to the VM, not the size of the stick | 00:45 |
| rrq | "amount of memory" is not RAM size? | 00:45 |
| systemdlete | The stick is 256MB (yes MB, not GB). | 00:45 |
| rrq | and if you increas RAM the llimit on stick size changes? | 00:45 |
| systemdlete | what limit? | 00:45 |
| rrq | I must have misunderstood; I read it that you couldn't have more the 3Gb on the stick | 00:46 |
| systemdlete | > <systemdlete> So here is what I know about my USB thumb drive not being recognized. Chimaera host and guest. Using vbox ehci (usb 2.0) emulation, the VM is unable to enumerate the device when I give the VM, say, something over 3GB RAM. For example, the drive is recognized and works perfectly if I give the VM 3072M. But if I go maybe 3100M or so, it fails to enumerate the device. | 00:46 |
| systemdlete | rrq: I've tried this with a 16GB thumb drive also with the same behavior. Stick size doesn't matter. | 00:47 |
| rrq | ah. ok. how large is host RAM? | 00:47 |
| systemdlete | 32GB | 00:48 |
| systemdlete | htop on host shows only 19.4GB in use | 00:48 |
| systemdlete | and the stick is recognized on the host, and on 2 other hosts as well. Two of the hosts run chimaera, one daedalus. | 00:49 |
| systemdlete | haven't tried this in a VM under daedalus | 00:49 |
| rrq | ok, yes, that sounds really peculiar.. why the kernel would enumerate, or not, the USB depending on minor RAM size variation (with that much host RAM) | 00:50 |
| * systemdlete wonders why it is so hard to type "ae" for the release names... lol | 00:50 | |
| systemdlete | the #vbox support indicated that the kernel versions might be significant. | 00:51 |
| systemdlete | I will try this on my testbox which runs daedalus. I'll set up a similar VM with chimaera and 4G RAM, ohci+ehci | 00:52 |
| rrq | have you checked if it's really the kernel enumaration and not up at udev level; i.e. does modules exist but it's not present under /dev ? | 00:52 |
| systemdlete | I haven't poked around in /dev, no | 00:52 |
| systemdlete | I'm guessing you mean in the guest | 00:52 |
| systemdlete | since the host(s) have no problem with enumerating thumb drives | 00:53 |
| rrq | yes, you might see that difference by looking at the modules; | 00:54 |
| rrq | one case would have an echi and the other would not | 00:54 |
| rrq | mmm or maybe both would have the echi module but only one would enumerate and have a usb-storage module | 00:57 |
| systemdlete | well, here's another data point: It doesn't matter what the host is running. The behavior is the same on my testbox running daedalus on host | 00:59 |
| systemdlete | Nice to know, if nothing else. | 00:59 |
| systemdlete | what are the two cases? | 01:00 |
| systemdlete | lsmod lists ohci and ehci modules on a VM with this problem. | 01:00 |
| systemdlete | VM has 4GB Ram and 3 vCPUs | 01:01 |
| systemdlete | no usbstorage module though--I've noticed that before during my testing. | 01:01 |
| rrq | and if you unplug and plug in the stick it discovers it? | 01:02 |
| systemdlete | oh, I don't have it filtered. I manually attach it while the VM is running. | 01:03 |
| systemdlete | but it does the same thing as plugging it in physically | 01:03 |
| rrq | and you say the guest doesn't react to that? | 01:04 |
| rrq | eg with a line in /var/log/syslog | 01:04 |
| systemdlete | https://pastebin.com/CuXs7fCN (syslog on guest) | 01:04 |
| * systemdlete knew you were about to ask... :D | 01:05 | |
| rrq | :) ... error -110 typically means "not enough power" | 01:05 |
| systemdlete | in a VM? | 01:05 |
| systemdlete | Yeah, my web searches led me to that also. But I don't understand that. | 01:06 |
| rrq | must mean something else in the USB port emulation | 01:06 |
| rrq | or does this go to an actual USB stick? | 01:07 |
| systemdlete | it attempts power cycle | 01:07 |
| systemdlete | oh the stick is real, yes. It's a Sandisk Cruzer | 01:07 |
| systemdlete | not an emulated stick (I think vbox supports those now, but not sure) | 01:08 |
| systemdlete | btw, rrq: Thank you so much for your help. I can't thank the folks here enough. | 01:09 |
| rrq | one possibility is that the actual stick gets choked by the possibly larger USB bulk request, if that might relate to RAM size | 01:09 |
| systemdlete | keep in mind this happens with a 16GB stick also... | 01:09 |
| systemdlete | hmmm. | 01:10 |
| systemdlete | is there a way to set one of those kernel params (sysctl) for the bulk request size? | 01:10 |
| systemdlete | I could look for it, but maybe you already know | 01:11 |
| rrq | (nw.. stops me from loitering the streets) .. and the transfer chain involves the actual device handling too | 01:11 |
| rrq | I'd be interested in that yself because I have a similar use case with a newly bought sandisk, without VM | 01:11 |
| systemdlete | on the host, sure. I agree | 01:11 |
| rrq | though that's through xhci | 01:12 |
| systemdlete | this might be interesting also: https://pastebin.com/FfEM28y4 | 01:12 |
| rrq | that last suggests the stick is low-speed (?) | 01:13 |
| systemdlete | that's output from a vbox command line debug tool | 01:13 |
| systemdlete | right. It would be. | 01:13 |
| systemdlete | This stick is circa 2006 or so. Very small, only 256MB. | 01:14 |
| systemdlete | it still works though. | 01:14 |
| systemdlete | Not seeing errors from it. | 01:14 |
| systemdlete | an ex-gf gave it to me. | 01:14 |
| * systemdlete thinks back... about 4 gfs ago | 01:15 | |
| systemdlete | but I'm lucky at cards, at least. | 01:15 |
| systemdlete | well, not that lucky I guess. | 01:15 |
| rrq | low-speed would really be uhci I guess.. maybe echi code doesn't have transfer adaption in the same way as xhci | 01:16 |
| systemdlete | I mean, I can do this with a 16GB usb 2.x stick if you like. | 01:16 |
| systemdlete | slightly different syslog messages, but still no appearance of the drive in the guest | 01:18 |
| rrq | still error -110 ? | 01:18 |
| systemdlete | no, wait | 01:18 |
| systemdlete | https://pastebin.com/AZpi0b3Y | 01:19 |
| systemdlete | so different errors, but same conclusion: Can't enumberate | 01:20 |
| systemdlete | enumerate* | 01:20 |
| rrq | right .. this time the host drops to read/8 and gets -32 ... (like my stick) | 01:20 |
| systemdlete | oh so that slashy number is number of bytes requested? | 01:21 |
| rrq | I think so; number of "blocks" | 01:22 |
| systemdlete | ah, ok | 01:22 |
| systemdlete | makes sense | 01:22 |
| systemdlete | I have an 8GB sstick here. Try? | 01:23 |
| systemdlete | (last one was 16GB) | 01:23 |
| rrq | error -32 would be "Endpoint stalled" | 01:23 |
| systemdlete | lazy-assed endpoint... | 01:24 |
| rrq | some comments say "usually occurs when the USB port is drawing too much power" | 01:24 |
| systemdlete | Well... lessee here. | 01:24 |
| systemdlete | I've got a FX8350 on a Gigabyte mainboard with a 600W PS | 01:24 |
| systemdlete | Not seeing power draw or similar errors on host... don't recall any anyway | 01:25 |
| systemdlete | There's 32GB ram on the board and 2 hard drives | 01:25 |
| systemdlete | There's a video card for hdmi video. And about 5 or 6 fans | 01:26 |
| rrq | well USB x.0 includes a spec of power .. 2.0 said 0.5A ona port I think | 01:26 |
| systemdlete | I've got a lot of USB plugged in here. In fact, I had to use an old 1.1 usb hub to accommodate them all! | 01:27 |
| systemdlete | I've got a couple of 3.0 ports, but those don't work well with Linux | 01:27 |
| systemdlete | (maybe the new 6.x kernels will fare better, idk) | 01:27 |
| rrq | I'm not ure where power controls are; whether the kernel has a say in that.. and then whether associated code, if any, has changed | 01:28 |
| rrq | s | 01:28 |
| systemdlete | rrq: Just tried it with that 8GB thumb drive. Same results as last one. | 01:29 |
| systemdlete | tries /64 then power recycle, then /8 | 01:30 |
| systemdlete | then fails with can't enumerate | 01:30 |
| rrq | does the ramp-down happen with xhci as well ? | 01:31 |
| systemdlete | not sure | 01:31 |
| systemdlete | with xhci, it doesn't fail | 01:31 |
| systemdlete | let me look at my testbox VM's syslog | 01:32 |
| systemdlete | odd. When successfully enumerates, no such messages even appear in the syslog | 01:35 |
| systemdlete | it finds it immediately | 01:35 |
| systemdlete | but let me try some variations--that was with only 3GB ram in the VM | 01:35 |
| systemdlete | I tried it in a 4GB ram VM with ehci and all 3 drives (256MB, 8GB, 16GB) show the exact same pattern and then fail to enumerate | 01:40 |
| systemdlete | now, I'll try them with xhci | 01:40 |
| rrq | TL;DR; https://www.kernel.org/doc/html/v4.13/driver-api/usb/power-management.html | 01:45 |
| rrq | hmm 4.13 ..I guess there something newer in git | 01:45 |
| systemdlete | https://pastebin.com/G0wjrHMG -- this is on 4GB VM with xhci and 4GB and all three drives in succession. | 01:47 |
| rrq | .. last commit on that doc is June 2019 .. so some changes | 01:50 |
| rrq | hmm the commit at "Fri Apr 19 13:52:38 2019" has notes about "hub being auto-suspended at bad times" | 01:53 |
| systemdlete | what is that saying? Do they mean by design, or correcting a problem? | 01:53 |
| rrq | it appears to document a fix in usb core to resolve that issue .. let me clip out the text.. | 01:54 |
| systemdlete | btw, rrq: I DO see in the vbox log (on the host) that the device is being immediately suspended. So that matches | 01:54 |
| rrq | https://transfer.sh/4PoADxXVsK/commit2019.txt | 01:56 |
| rrq | I have to go.. but it seems ehci and xhci has significant code diff around usb power management; | 01:58 |
| systemdlete | Thanks. Do you know if this fix is "in" for 5.x or 6.x kernels? | 01:58 |
| al1r4d | Hi | 01:59 |
| systemdlete | IOW, if I were to try daedalus (6.x kernel?) in a VM, maybe this would be resolved even with a ehci emulation? | 02:00 |
| systemdlete | ah, or a backport kernel for chimaera | 02:00 |
| rrq | I don't know; being from 2019 it would probably be included now | 02:01 |
| systemdlete | in 5.x kernels? | 02:01 |
| systemdlete | so that problem is still present even with the fix? | 02:01 |
| systemdlete | s/that/my/ | 02:01 |
| rrq | maybe a larger value in /sys/module/usbcore/parameters/autosuspend would make a difference? that's seconds for auto-suspending apparently | 02:03 |
| systemdlete | rrq: is the fix for ehci and/or xhci, and is the fix for 5.x and/or 6.x kernels? | 02:04 |
| systemdlete | I'll try that parameter change | 02:04 |
| rrq | not sure .. the note is in the documentation .. and talks about usbcore I think | 02:05 |
| systemdlete | so it should be universal then | 02:06 |
| systemdlete | well, I don't want to keep you. You said you needed to go. | 02:06 |
| rrq | yes. cheers. | 02:06 |
| eyalroz | Hello devuaners, | 14:21 |
| eyalroz | I'm apt-get dist-upgrade'ing from daedalus to excalibur, and was wondering if there are particular gotchas you would advise I look out for | 14:22 |
| eyalroz | Here's one experience from the agdu'ing: apt-listchanges is informing me of how I'm installing "systemd (253~rc2-1) experimental; urgency=medium" :-( | 14:25 |
| fsmithred | eyalroz, if you're running excalibur then you can advise most of us. | 14:36 |
| fsmithred | do you know anything about changes in sudo? | 14:36 |
| eyalroz | fsmithred: Nope, I don't | 14:51 |
| nethead23 | Hello Gentleman, | 15:21 |
| nethead23 | i would like to ask if there is any instalable qcow2 / vm image of Devuan 4/5 i could use. | 15:21 |
| gnarface | nethead23: i'm not sure but it would be pretty easy to make one | 15:34 |
| gnarface | from a booted non-vm image | 15:35 |
| gnarface | even the live iso i would think | 15:35 |
| nethead23 | Well, i did make one, problem is that the vnc server is not working and the support is offline until monday. Without remote console i cant do the install... | 15:35 |
| nethead23 | I would need an image which is able to get an ip address handled by the vps manager | 15:37 |
| nethead23 | And sry, i am mostky new to vps stuff, i lost my HW servers about one month ago | 15:37 |
| gnarface | hmm, well i found these really old ones... those are the last official ones i can see here... https://files.devuan.org/devuan_ascii/virtual/ | 15:37 |
| gnarface | but if that one works maybe you can just update from it to current | 15:38 |
| nethead23 | Thanks, but i cant use a 2er version. What is this "ASCII" release? | 15:38 |
| gnarface | ascii was devuan 2 i believe | 15:39 |
| gnarface | it goes: jessie, ascii, beowulf, chimaera, daedalus, excalibur, ceres | 15:39 |
| nethead23 | Oh, thats the name, got it :) | 15:39 |
| gnarface | daedalus is current | 15:40 |
| gnarface | excalibur and ceres track debian testing and unstable, respectively | 15:40 |
| nethead23 | I need something stable, so i would like to install daedalus. Guess i wait for monday so i can get vnc console access. Thx anyway | 15:41 |
| gnarface | the only other thing i can think of is, if there's something like this already in the repos elsewhere just not listed here | 15:41 |
| nethead23 | BTW: Pretty cool project, i hate systemd | 15:41 |
| gnarface | feel free to stay connected and also join #devuan-offtopic | 15:43 |
| Guest15 | Hi, I'm m_dan9er@matrix.com | 15:53 |
| Guest15 | Apparently the bridge broke | 15:54 |
| golinux | We can count our blessings then . . . :) | 15:55 |
| Guest15 | bruh | 15:55 |
| Guest15 | Well uh I had upgraded my Pi400 to Daedalus 2 days ago | 15:56 |
| Guest15 | I was asking if I needed to do anything special for the upgrade | 15:57 |
| Guest15 | Cause of the Pi packages and stuff | 15:57 |
| Guest15 | Though my messages were lost to the void | 15:58 |
| golinux | I think there is also a #devuan-arm channel if no response here . . . | 16:04 |
| Guest15 | Yeah, but looking at chanlogs that looks pretty dead | 16:06 |
| golinux | Didn't know that . . . | 16:08 |
| Guest15 | Well I also have another more generic question | 16:10 |
| Guest15 | It looks like Chimaera is using unmerged /usr | 16:10 |
| Guest15 | However merger-usr-via-simlinks is now mandatory in Bookworm/Daedalus, saw that during my upgrade | 16:11 |
| Guest15 | s/merger/merged | 16:11 |
| Guest15 | Though it looks like dpkg is not ready for this, and the maintainers are very upset at tech-ctte | 16:14 |
| Guest15 | They have made a list of horribles here: https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Does_dpkg_support_merged-.2Fusr-via-aliased-dirs.3F | 16:15 |
| rrq | daedalus installer still defaults to --no-merged-usr and "expert install" asks you... | 16:16 |
| Guest15 | rrq: I upgraded my Pi400 and it did the usrmerge | 16:17 |
| Guest15 | So there's a dilema here, Bookworm mandates merged-usr, which breaks freaking dpkg | 16:19 |
| Guest15 | Why this was not a release critical bug, I have no idea | 16:20 |
| Guest15 | But I don't want to upgrade my more important machines until dpkg gets their shit together | 16:21 |
| Guest15 | Any thoughts? Am I being overly cautious? Is this situation different in Devuan? | 16:22 |
| rrq | no; Devuan inherits any usrmerge issues from Debian .. I'm keeping it unmerged until there's a real reason to not do so. | 16:24 |
| nethead23 | @Guest15, so you would recommend installing/staying with the 4 release? | 16:29 |
| djph | rrq: so, you'll be un-usrmerge'd forever. | 16:31 |
| rrq | probably :) | 16:31 |
| Guest15 | nethead23: I'm asking for other's opinions on this | 16:32 |
| fsmithred | Guest15, I'm un-merged here on system upgraded to daedalus. I'm wondering how it happened to you. I will remain un-merged by choice as long as I can. And I will add that I did have a merged system way back when I did a debootstrap install of ascii when ascii/stretch was still in Testing, and I did not notice it was merged until at least a year later. | 16:47 |
| fsmithred | And I did not notice it because of a problem, I just happened to look at it and think about usr-merge. | 16:49 |
| Guest15 | fsmithred: I just updated my sources and then did the upgrade in aptitude | 16:52 |
| Guest15 | Not sure how you passively avoided it | 16:53 |
| Guest15 | I would think you'll need to actively forbid the usrmerge package | 16:54 |
| Guest50 | great, got disconnected | 16:55 |
| Guest50 | Well, packages can't assume merged-usr until Trixie/Excalibur | 16:56 |
| Guest50 | I hope the solution there is to mandate that packages can't install stuff in /, only /usr, or dpkg will scoff (cause then having to `--force-*` it makes it obviously broken) | 17:00 |
| DelTomix | I've tried running merged usr on a few systems over the past year - haven't noticed issues. Though always as fresh installs. | 17:00 |
| rrq | I suppose a problem would only arise if unmerged and one program refers with full but wrong path to another program.. eg using say "/usr/bin/cat" or "/bin/less" | 17:04 |
| rrq | those paths are wrong in the sense of not being the installation paths for those programs | 17:06 |
| rrq | but if merged one might not noice, and refer to all programs X as /bin/X or as /usr/bin/X | 17:09 |
| eyalroz | So... some nuggets of experience from apt-get dist-upgrade'ing to excalibur. | 19:22 |
| buZz | oh , is Daedalus now stable, sweet | 19:23 |
| eyalroz | One problem is with /etc/mime.types . Users sometime need to add more mime types (e.g. this may have to do with libreoffice; but never mind the details) - and this conflicts with the Debian upstream changes. The conflict may be easily mergeable, but we're not in git here, so we get a prompt for the user. It's too bad we don't have a mime-types.extra or mime-types.d etc. | 19:23 |
| eyalroz | Still, not a big deal, one can re-integrate manually later. | 19:24 |
| eyalroz | At some point during package configuration I got this error message: | 19:25 |
| eyalroz | "update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults" | 19:25 |
| eyalroz | Don't know why "start" and "stop" are not supported | 19:26 |
| eyalroz | Plus, I shouldn't be getting this, anyway | 19:26 |
| eyalroz | Another warning I shouldn't be getting: | 19:26 |
| eyalroz | dpkg: warning: unable to delete old directory '/usr/share/fonts/truetype/liberation2': Directory not empty | 19:26 |
| eyalroz | Strangely enough, there's a .uuid file in that directory - not sure why. | 19:27 |
| eyalroz | But now for the serious issue: | 19:27 |
| eyalroz | dpkg: dependency problems prevent configuration of linux-headers-amd64: | 19:27 |
| eyalroz | linux-headers-amd64 depends on linux-headers-6.4.0-3-amd64 (= 6.4.11-1); however: | 19:27 |
| eyalroz | Package linux-headers-6.4.0-3-amd64 is not configured yet. | 19:27 |
| eyalroz | And a failure to build DKMS modules | 19:28 |
| eyalroz | ... which seems to be mostly/only a failure to build NVIDIA driver 525.60.11 | 19:28 |
| buZz | apt-get install -f ? | 19:30 |
| buZz | or dpkg-reconfigure linux-headers-6.4.0-3-amd64 | 19:31 |
| * buZz guesses | 19:31 | |
| eyalroz | dpkg-reconfigure linux-headers-6.4.0-3-amd64 <- tries to rebuild the DKMS kernel modules, and fails | 19:34 |
| eyalroz | buZz: Installed a newer NVIDIA driver, 535.104.05 (the latest production version from their website), then apt-get install'ed to complete the configuration, and this succeeded in building the DKMS modules | 19:42 |
| buZz | the dkms module of the nvidia.com driver? | 19:43 |
| buZz | or are you now mixing drivers between repo and website? | 19:43 |
| eyalroz | buZz: Yes | 19:45 |
| eyalroz | the DKMS module of the nvidia.com driver | 19:45 |
| buZz | ah, i never use that, i use devuan | 19:45 |
| eyalroz | nothing from any NVIDIA repo | 19:45 |
| buZz | i just enable non-free and apt install nvidia-driver | 19:45 |
| buZz | as is supported :) | 19:45 |
| eyalroz | buZz: kernel upgrades should still be somewhat accommodating of incompatibilities, even with non-free code. | 19:46 |
| buZz | https://wiki.debian.org/Nvidia | 19:46 |
| eyalroz | i.e. to the extent of warning you in some way | 19:46 |
| eyalroz | or offering to proceed without the non-free DKMS module | 19:47 |
| buZz | i just dont see the point of messing around like a windows user with manual downloads | 19:47 |
| buZz | instead of using apt install nvidia-driver | 19:47 |
| eyalroz | buZz: It can't be avoided, actually, if you're doing development work | 19:47 |
| buZz | i do development work | 19:47 |
| buZz | cuda is in repo too | 19:47 |
| eyalroz | NVIDIA drivers age extremely quickly, | 19:47 |
| eyalroz | and new(-architecture) GPUs are not supported with older drivers | 19:48 |
| buZz | right, there's backports repo for that | 19:48 |
| buZz | either way, i dont see any reason for anyone to do that | 19:48 |
| buZz | nobody needs 'cutting edge' software beside people that want to be the first ppl finding undocumented bugs :D | 19:48 |
| eyalroz | buZz: There's a non-free backports atp repository? | 19:48 |
| eyalroz | buZz: I actually was _not_ using the cutting-edge thing, I was just using the CUDA 12.2 driver | 19:49 |
| buZz | http://deb.devuan.org/merged/dists/daedalus-backports/non-free/ | 19:49 |
| buZz | 11.8.89 is in normal daedalus | 19:50 |
| eyalroz | buZz: http://deb.devuan.org/merged/dists/excalibur-backports/non-free/ doesn't exist yet, though | 19:50 |
| buZz | what would it be backporting from? :D there's no release beyond excalibur yet | 19:51 |
| eyalroz | buZz: debian sid? | 19:52 |
| buZz | thats literally not a release version | 19:52 |
| eyalroz | or rather, devuan ceres | 19:52 |
| buZz | daedalus-backports didnt exist, until excalibur started existing | 19:53 |
| eyalroz | Anyway, I'm not saying that Devuan should make an effort to support the newest versions of CUDA | 19:53 |
| eyalroz | but an option to skip one of the DKMS modules would be nice. Although that too is more of Debian responsibility than Devuan's | 19:53 |
| buZz | well, trixie/excaliber has 12.0.146 | 19:54 |
| buZz | debian has no mission that aligns to 'support the newest versions of $thing' | 19:55 |
| buZz | debian wants battletested, stuff that can work for years, not 'number goes up' stuff outside of security fixes | 19:55 |
| buZz | its a fixed ecosystem for a release | 19:55 |
| buZz | -not- a rolling distro | 19:56 |
| eyalroz | buZz: Which is why a reasonable thing to have is the ability to dynamically skip DKMS modules for some kernels - as an alternative to actually being aware of what they are and what to do with them | 20:10 |
| buZz | well, 'dkms remove nvidia -k 6.6.6/arm64' or something? :) | 20:12 |
| eyalroz | buZz: That would remove it from all kernels | 20:13 |
| eyalroz | i.e. all kernel versions | 20:13 |
| buZz | --all removes from all kernels | 20:13 |
| buZz | -k specifies a specific | 20:13 |
| eyalroz | Oh, I see | 20:13 |
| buZz | according to https://manpages.debian.org/unstable/dkms/dkms.8.en.html | 20:13 |
| eyalroz | Even when the kernel DEB has not yet been fully installed? | 20:14 |
| eyalroz | at any rate, that could be offered during installation for the user to choose. Like the user is offered to choose between different versions of a file etc. | 20:14 |
| Xenguy | In the end it tends to be a question of who will do said work? | 21:03 |
| Xenguy | Hopefully people who are interested in eating their own dogfood will step up | 21:04 |
| golinux | ^^^^ THIS! | 21:06 |
| eyalroz | @Xenguy: But I already have work maintaining FOSS projects which started with me eating my own dogfood | 21:26 |
| eyalroz | It turns out I'm maintaining a popular stand-alone printf-family library for arduino, for example (because I needed it for GPU work) | 21:27 |
| Xenguy | Glad to hear it, we do what we can do | 21:47 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!