| xisop | is it still possible to turn debian into devuan? | 03:08 |
|---|---|---|
| Xenguy | xisop, Yes, there are migration how-to's on the Devuan web site | 03:09 |
| xisop | Xenguy: ah okay. i wasn't sure if that was still a thing | 03:10 |
| Xenguy | Well now that you mention it, I'm asking myself, where does usrmerge fit in, if at all? | 03:10 |
| Xenguy | Might be best to do such a migration at or before Daedalus/stable, since after that, I'm not sure if complications could possibly occur | 03:11 |
| Xenguy | That's all that's documented now anyhow, so all good | 03:11 |
| golinux | Daedalus is the last release that will work without it IIUC | 03:11 |
| Xenguy | Yes | 03:12 |
| golinux | It will also work WITH it | 03:12 |
| Xenguy | So, last release that works with or without usrmerge : -) | 03:12 |
| Xenguy | Perhaps we should tweak that statement | 03:13 |
| Xenguy | the web page makes | 03:13 |
| golinux | https://www.devuan.org/os/announce/excalibur-usrmerge-announce-2024-02-20.html | 03:13 |
| Xenguy | That page looks extremely unfamiliar = ) | 03:13 |
| golinux | Daedalus/stable is the final Devuan release that will function without merged usr. | 03:14 |
| Xenguy | Hallelujah | 03:14 |
| Xenguy | Being a trailing edge guy, I'm not even close, of course | 03:15 |
| golinux | Me too | 03:15 |
| golinux | I may cross that bridge in a year or two . . . | 03:16 |
| Xenguy | "All in good time" | 03:22 |
| hightower3 | I'm happy to report that I'm running Devuan (just upgrading to daedalus) on an old WeTab (https://1.bp.blogspot.com/-WXJeKFlql5o/TgLPRpDCcwI/AAAAAAAACBk/hKBz5OuVSNk/s1600/side2.png). It's a modest system with just 2-core Intel Atom N460 @ 1.66 Ghz and 1 GB RAM, but it's 64 bit and it works. | 16:30 |
| Joril | hightower3: good job! | 16:41 |
| ecxod | I think that postgresql does not like devuan | 20:29 |
| ecxod | > Trigger für postgresql-common (248) werden verarbeitet ... | 20:29 |
| ecxod | > supported-versions: WARNING! Unknown distribution ID in /etc/os-release: devuan | 20:29 |
| ecxod | > debian found in ID_LIKE, treating as Debian | 20:29 |
| free_help | I'm having a hard time resizing a LUKS-encrypted LVM ext4 partition. I've done it on-the-fly in the past but now can't seem to find a guide that doesn't ask for the system to be unmounted | 21:30 |
| Guest80 | Heya | 21:50 |
| Guest80 | I updated and upgraded apt yesterday, and today the x server won't start, something with nvidia, so I uninstalled the drivers, and when reinstalling it says it can't build kernel modules. Uname -a -> 6.1.10-amd64 / Debian 6.1.76-1. | 21:50 |
| Guest80 | fixed it, turns out the new kernel breaks nvidia cards https://dev1galaxy.org/viewtopic.php?id=6418 | 22:17 |
| gnarface | they still haven't pushed a fix for that into the repos? what a bunch of jokers... | 22:33 |
| commodore256 | I need a new version of GlibC to build imagemagik that I need for a shellscript. I figure the easiest way would be adding a new version of GCC and maybe it would package a new version of GlibC, but I see a debian way of updating it, but that involves using a first party LTSB and I worry about conflicts with Devuan and apt might say "wait a minute, you need SystemD" | 22:59 |
| gnarface | commodore256: what devuan release are you currently on? | 23:01 |
| commodore256 | latest | 23:02 |
| gnarface | as in latest stable, or sid? | 23:02 |
| gnarface | er, ceres | 23:02 |
| commodore256 | 5.0 I think, I updated via apt | 23:02 |
| gnarface | that's daedalus, current stable | 23:02 |
| commodore256 | latest stable | 23:02 |
| gnarface | there should be newer glibc and gcc in testing (excalibur) and even newer than that in unstable (ceres) | 23:03 |
| gnarface | i recommend you just install excalibur or ceres into a chroot under your main distro (to avoid polluting your stable package tree with this mess) and then see if your imagemagic build works in there better | 23:03 |
| commodore256 | how do I install that version downstream? | 23:03 |
| commodore256 | This is my main distro | 23:04 |
| gnarface | for that matter, maybe the imagemagick version you need is already there in testing or unstable... which would save you build trauma | 23:04 |
| gnarface | and for that matter... it may already be in daedalus-backports, someone may have already done all this work for you | 23:04 |
| gnarface | do you need some weird custom imagemagick build, or just a newer version? | 23:04 |
| gnarface | to be clear, you do not want to go installing testing or unstable packages into your nice stable install, the chroot would protect you from that (you'd use debootstrap) | 23:05 |
| commodore256 | all I want is the unified version that just uses the magik command | 23:05 |
| gnarface | do you know which version number that is? | 23:06 |
| commodore256 | it says I have ImageMagick 6.9.11-60 and I think I need 7.?? | 23:07 |
| commodore256 | or 7.* | 23:07 |
| gnarface | hmm, looks like that's newer than even what's in unstable currently: https://pkginfo.devuan.org/cgi-bin/policy-query.html?c=package&q=%5Eimagemagick%24&x=submit | 23:07 |
| gnarface | totally bleeding edge | 23:07 |
| commodore256 | Yeah, but all of the documentation I'm looking into is focused on this, there was a FFT halftone reversal tutorial I saw that used magik | 23:08 |
| gnarface | alright, yea i think for the record this is way too much effort for a minor indignity of having to remember 2 or 3 admittedly obnoxiously generic separate command names, but you should be able to just debootstrap ceres into a local directory then chroot in and attempt a build of imagemagick 7 | 23:08 |
| gnarface | and that or using some other containerization (like a qemu virtual machine or the like) is the only way i'd recommend attempting this, as any other approach would risk making a real unrecoverable mess of your current stable install | 23:09 |
| commodore256 | containerization is too much of a pain, I need it for a scanning image processing pipeline | 23:10 |
| gnarface | and for the record, usually if there's something you want that's even too new for ceres, there's a good reason, and you should just wait | 23:10 |
| gnarface | but, if you try to build it yourself, you'll definitely find out for sure | 23:11 |
| commodore256 | I'm sick of opening xsane, cropping the scan, opening gimp, running noise reduction, then opening sharpening, it's a pain navigating the menus | 23:12 |
| commodore256 | I figure even if I have to compile three things, it saves me from my scanning torture | 23:13 |
| gnarface | alright, well, it may turn out to be much messier than that | 23:13 |
| gnarface | fair warning | 23:13 |
| gnarface | i don't know for sure in this case though, i suggest start with the debootstrap + chroot of ceres, since that'll be closest to the baseline of what imagemagick7 is probably requiring | 23:14 |
| commodore256 | just as long it's mess I only have to clean up once and not repete over a thousand times | 23:14 |
| commodore256 | Literally, that's what I have to do | 23:14 |
| commodore256 | Scanning CD Album art is such a pain | 23:14 |
| gnarface | you don't have to justify anything to me, i'm just trying to make sure you know what you're getting into | 23:17 |
| commodore256 | Maybe I'll switch to testing because it stays in testing for about a year or so, so I won't have to switch distros for an extra year or so beyond the stable support cycle | 23:19 |
| gnarface | i would really recommend not doing that for this | 23:19 |
| commodore256 | but during that first year or so, it's like using arch | 23:19 |
| gnarface | at least not to your main install | 23:19 |
| commodore256 | I've used arch before | 23:20 |
| gnarface | your best bet is to debootstrap a separate install of testing or unstable into a side directory you can chroot into | 23:20 |
| gnarface | that way whatever happens it won't make a mess of your main install | 23:20 |
| gnarface | the chance of you having to delete that chroot and start over a couple times are fairly high | 23:21 |
| gnarface | chances* | 23:21 |
| gnarface | there's a reason they keep all this stuff separate from the stable release | 23:21 |
| commodore256 | so chroot ~/testing How would I install Debian in a chroot? | 23:21 |
| gnarface | with debootstrap | 23:21 |
| commodore256 | I've messed with chroot when trying gentoo | 23:22 |
| gnarface | technically you do not install into a chroot, you install into an empty directory with debootstrap, then chroot into it afterwards | 23:22 |
| gnarface | nothing special makes it a chroot other than the fact you chroot into it afterwards | 23:22 |
| commodore256 | Oh, yeah, technically | 23:22 |
| gnarface | should work like this: debootstrap ceres ./some_directory http://deb.devuan.org/merged/ | 23:24 |
| commodore256 | and with chroot, you don't use SystemD | 23:25 |
| gnarface | yea, systemd is allergic to chroot in some way, i'm not clear on it, but systemd has its own answer to that | 23:26 |
| gnarface | none of that should matter for you on devuan | 23:26 |
| commodore256 | Yeah, because the host system works without it | 23:26 |
| commodore256 | will chroot still access usb devices? | 23:28 |
| gnarface | yes, if you bind mount dev | 23:32 |
| gnarface | mount -o bind /dev ./some_directory/dev | 23:33 |
| gnarface | it uses the host machine's kernel, which isn't the same version as ceres, but probably will be close enough for this task | 23:33 |
| gnarface | but it will only have access to /proc, /sys, /dev and such if you actually manually bind mount them like this before chrooting in | 23:34 |
| fsmithred | arch-install-scripts package is in the repo | 23:35 |
| gnarface | i usually do /proc, /sys, /dev, and /dev/pts all as a general practice when doing such things, though /dev/pts i've only usually needed for a few very badly behaved programs (various Steam dedicated game servers) | 23:35 |
| commodore256 | can you use chroot for alternative ABIs? like if I ran a system that was mostly x32 (not to be confused with IA32) and have a chroot for amd64 | 23:41 |
| gnarface | yes on devuan and other debian derivatives, though i think the host kernel might have to be the amd64 one for it to work | 23:43 |
| gnarface | for other distros that don't support multi-arch, i don't know for sure it'll work | 23:43 |
| gnarface | for those you might have to resort to a real VM | 23:44 |
| gnarface | but yea, debian calls this feature "multi-arch" and it should work fine | 23:44 |
| gnarface | i've successfully compiled and ran 32-bit and 64-bit x86 as well as ARM code in chroots under a amd64 kernel on devuan | 23:45 |
| gnarface | might even work with the i386 kernel, just not sure | 23:46 |
| gnarface | in fact it would probably work for IA32 too, but i think devuan has recently pulled support | 23:47 |
| gnarface | er, debian rather has pulled support, devuan just follows them | 23:47 |
| gnarface | (there's a bunch of caveats in the setup, it wasn't easy to figure out, but there should be documentation online somewhere...) | 23:49 |
| commodore256 | Yeah, everything is switching to docker and I find that to be annoying | 23:51 |
| commodore256 | Short term convenience eroding long term stability | 23:51 |
| gnarface | docker support does seem fraught. i use qemu despite that it's harder to figure out, because it works right | 23:52 |
| gnarface | i don't use that libvirt frontend crap with it though, because it's low quality | 23:53 |
| gnarface | for this task, you shouldn't need any virtualization though. a regular chroot should be sufficient | 23:55 |
| gnarface | i don't know that for sure, but it would be really weird | 23:55 |
| n4dir | i'd argue it is the usual way to backport a package, but i am not sure if i fully understand the "problem" | 23:59 |
| gnarface | with docker? | 23:59 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
