| rwp | avbox, I am curious if you made progress forward? I feel strongly that perl was probably broken by an inconsistent installation likely from non-repos perl parts. But not sure how to remove those parts without perl working for the system commands like apt-show-versions to work. | 00:40 |
|---|---|---|
| avbox | rwp: Yes and no, I could nearly all package put to daedalus, but debconf and libpam0g don't work. On the machine I want to upgrade I have a custom compiled kernel (mostly for Steamdeck). I even can reompile the kernel, but I can't install the created deb package. So I try it now on freshly installed system. I hope I find out what is really wrong on | 00:43 |
| avbox | my master machine. | 00:43 |
| rwp | Steamdeck? Could 3rd party packages installed from non-devuan repositories have brought in perl packages? Would you be able to purge those off, at least long enough to upgrade? You could re-install Steam again later. | 00:48 |
| avbox | rwp: I did not install 3rd party packages. Since kernel 6.1 there are also no patches needed to put everything together for steamdeck. And by the way, I have another image with kernel 5.x and dist-upgrade also fails there. But the image comes from devuan ascii, may be I have some really old perl stuff that results in the troubles. Will see. | 00:53 |
| rwp | If you have used "cpan" to install local packages then that is another possible source of problems. | 00:55 |
| avbox | rwp: Can be that I once or twice used cpan for packages (I don't remember everything I installed during years). I will check it. Needs too some time. Anyway, thank you for your help. | 00:57 |
| rwp | Good luck! | 00:58 |
| cousin_luigi | Does devuan use ifupdown by default? | 14:16 |
| buZz | not sure, i do have it installed on my desktop | 14:20 |
| buZz | i didnt install it myself | 14:20 |
| tr|ck | cousin_luigi: as long as the directive "source /etc/network/interfaces.d/* | 14:21 |
| tr|ck | cousin_luigi: shows up in /etc/network/interfaces, it does. | 14:21 |
| buZz | ah, mine does | 14:22 |
| fsmithred | cousin_luigi, it appears to be included in the default desktop install (it's in the desktop live) | 14:23 |
| cousin_luigi | I ask because I'm in a tangle with ifupdown-ng | 14:24 |
| cousin_luigi | But few appear to be using it | 14:24 |
| fsmithred | never heard of it | 14:26 |
| buZz | maybe rewritten in rust? :D | 14:28 |
| buZz | (no, just C) | 14:29 |
| spine-o-saurus | my system is broken again. ran apt update went through, but apt upgrade is reporting E:broken pacakges(libelogind-compat : Conflicts: libsystemd0 | 14:34 |
| tr|ck | cousin_luigi: ifupdown-ng is interesting because it extends the capablities of the former ifupdown: https://packages.debian.org/sid/ifupdown-ng | 14:34 |
| cousin_luigi | tr|ck: Yes, also it handles race conditions nicely. But I couldn't make it work with hotplug. | 14:35 |
| spine-o-saurus | also I'm getting an error building software it says lz4frame.h not found | 14:36 |
| spine-o-saurus | oh nm i just needed to install liblz4-dev | 14:38 |
| tr|ck | cousin_luigi: since 'Interfaces marked "allow-hotplug" are brought up when udev detects them' (from: man 5 interfaces) I would investigate on udev | 14:48 |
| cousin_luigi | tr|ck: My configuration works with ifupdown, the device is created. It's not configured though. | 14:49 |
| cousin_luigi | tr|ck: Furthermore, I couldn't find any occurrence of the "hotplug" keyword inside the ifupdown-ng source tree. | 14:49 |
| tr|ck | cousin_luigi: that's a point! | 14:50 |
| tr|ck | cousin_luigi: did you find the same occurency inside classic ifupdown? | 14:51 |
| cousin_luigi | tr|ck: There are references to it, yes. | 14:51 |
| cousin_luigi | https://lists.sr.ht/~sircmpwn/alpine-devel/%3C12372156.q0HFhEdf7Z%40localhost%3E <- "Future plans for ifupdown-ng include hotplug support" | 14:52 |
| cousin_luigi | Perhaps I should consider ifupdown2 | 14:53 |
| tr|ck | cousin_luigi: well... I'm not using ifupdown-ng, but from what you're telling it seems the new tool is not aware of the allow-hotplug feature. | 14:54 |
| cousin_luigi | tr|ck: Indeed. But it can handle race conditions better | 14:55 |
| cousin_luigi | with regular ifupdown I'd have to create an ugly script to make sure the proper interface is brought up before pppd attempts to use it. | 14:56 |
| tr|ck | cousin_luigi: exactly... Let me take a look into ifupdown-ng source code... | 14:56 |
| tr|ck | cousin_luigi: ifparse.c:if (iface->is_auto) | 14:58 |
| cousin_luigi | tr|ck: How does that help me? | 15:00 |
| tr|ck | cousin_luigi: it seems that it is aware of auto directive, but as you said, no occurence of hotplug. | 15:03 |
| cousin_luigi | tr|ck: Well, one would hope so. Without the auto directive, no device would go online on its own. | 15:04 |
| tr|ck | cousin_luigi: (: sure! | 15:04 |
| tr|ck | cousin_luigi: now I wonder how classic ifupdown source coude handles hotplug... Let me check | 15:05 |
| cousin_luigi | ifupdown2 seems to support both hotplug and dependencies. But I'm not sure leaving my network to the mercy of python scripts would be a good idea. | 15:07 |
| rrq | "allow-hotplug" is handled by /lib/udev/net.agent | 15:08 |
| rrq | cousin_luigi: isn't pre-up directive sufficient? | 15:10 |
| tr|ck | cousin_luigi: TARGET_IFACE=$(ifquery --allow hotplug -l "$INTERFACE" || true) | 15:11 |
| tr|ck | cousin_luigi: there's no hotplug in classic ifupdown either. The thing is managed by a shell script and ifquery. | 15:11 |
| cousin_luigi | rrq: But what is going to bring it up? | 15:11 |
| cousin_luigi | oh | 15:11 |
| * cousin_luigi is still somewhat confused | 15:12 | |
| rrq | I was imagining "pre-up" on "ppp" could bring up the carrier interface? | 15:13 |
| tr|ck | cousin_luigi: take a look at ifupdown source either from the github repo or by apt-get source ifupdown | 15:14 |
| cousin_luigi | tr|ck: Yes, I have it | 15:14 |
| cousin_luigi | rrq: However you slice it, you're going to need a trick for this or that | 15:14 |
| tr|ck | cousin_luigi: debian/ifupdown-hotplug is the script that manages hotplug | 15:15 |
| tr|ck | cousin_luigi: and as rrq correctly pointed out, is placed inside udev control (/lib/udev/ifupdown-hotplug) | 15:16 |
| cousin_luigi | tr|ck: What I mean is that each (ifupdown, ifupdown-ng, ifupdown2) has its own drawbacks | 15:16 |
| cousin_luigi | tr|ck: And can I invoke it from ifupdown-ng ? | 15:17 |
| tr|ck | cousin_luigi: for sure! (: That's why I've been sticking on classic ifupdown since it appeared on the scene... | 15:17 |
| tr|ck | cousin_luigi: you should give it a try | 15:18 |
| tr|ck | cousin_luigi: I would do it | 15:18 |
| tr|ck | cousin_luigi: I mean that I'd try to make it cope with ifupdwon-ng | 15:18 |
| tr|ck | cousin_luigi: the fact is that it's udev in charge of the process | 15:19 |
| tr|ck | cousin_luigi: we both took a look at the source code of both ifupdown and ifupdown-ng and we both arrived to the conclusion that they don't manage directly hotplug. This is actually correct because if there's something that is aware of new changes on the working state of a NIC this one is udev. | 15:21 |
| rrq | (mmm I'd also be weary about python) | 15:24 |
| cousin_luigi | tr|ck: I've tried classic ifupdown and couldn't make it work anymore even with the backup interface | 15:27 |
| cousin_luigi | (which explains my absence for the last few minutes) | 15:28 |
| rrq | one problem with hotplug driven networking setup is that the interfaces are raised and configured during pre-pivot boot, taking all config from the initrd filesystem | 15:28 |
| rrq | it's usually safer with "auto" setup | 15:29 |
| cousin_luigi | I'm confused | 15:29 |
| tr|ck | cousin_luigi, rrq: in this case a new initrd image should be created. | 15:29 |
| cousin_luigi | http://paste.debian.net/hidden/58df2860/ this is my (sanitised) current configuration | 15:30 |
| cousin_luigi | What should I add to initrd? | 15:30 |
| rrq | if there is ordering needs, then a single auto statement can name the interfaces in desired order | 15:30 |
| cousin_luigi | rrq: How do you mean? | 15:30 |
| rrq | "auto eth0 ppp" would bring up eth0 first, then ppp | 15:31 |
| cousin_luigi | ah | 15:31 |
| cousin_luigi | rrq: Does the numbering inside interface.d affect the running order? | 15:31 |
| rrq | possibly the order of auto statments is important | 15:32 |
| rrq | but certianl if mentioned in the same statement | 15:33 |
| cousin_luigi | ok, I suppose I'll have to merge those two | 15:34 |
| cousin_luigi | stay tuned:) | 15:34 |
| rrq | numbering of sourced files dfeines their inclusion ordering (alphabetical, really) and everything sourced is as if in place of the source statement. | 15:37 |
| cousin_luigi | Silly me, I was testing this on the systemd test pendrive ^_^ | 15:47 |
| cousin_luigi | (please don't summon the inquisition) | 15:48 |
| [-_-] | Hi | 20:12 |
| [-_-] | guys, I have imagemagick and graphicsmagick installed, but it seems like they don't contain binary | 20:13 |
| gnarface | they do, they just have super dumb names | 20:14 |
| gnarface | oh, i see what you mean | 20:16 |
| gnarface | the imagemagic package with the description "binaries" doesn't actually have the binaries, hilarious | 20:17 |
| rwp | All of them are using Debian Alternatives. | 20:17 |
| [-_-] | got em | 20:17 |
| gnarface | but they're there, they're in one of the dependency packges | 20:17 |
| gnarface | yea | 20:17 |
| [-_-] | graphicsmagick has gm | 20:17 |
| [-_-] | I got nothing for imagemagick though | 20:17 |
| gnarface | dpkg -l |grep imagemagick | 20:18 |
| gnarface | look in one of the others, like imagemagick-6.q16 | 20:18 |
| rwp | It's just super confusing because everything is an alternative. For example: update-alternatives --display convert | 20:18 |
| gnarface | yea they're all symlinked | 20:19 |
| rwp | ls -l /etc/alternatives/ | grep im6.q16 | 20:19 |
| rwp | But otherwise all of the normal commands are there. convert, mogrify, import, and so forth. If you don't look you would not know it was this way. | 20:20 |
| [-_-] | thanks rwp & gnarface | 20:30 |
| [-_-] | what is this alternatives about ? | 20:32 |
| DelTomix | [-_-]: In cases where you need multiple versions of things to be available - it lets you set defaults for which one to use. you manage it with the 'update-alternatives' command ... https://linuxconfig.org/how-to-set-default-programs-using-update-alternatives-on-debian-based-distributions | 20:37 |
| [-_-] | :o | 20:37 |
| rwp | Here is an old mailing list posting of mine where I go into the alternative system in some detail. Skip the first couple of paragraphs. https://lists.debian.org/debian-user/2002/08/msg02808.html | 20:56 |
| debdog | 2002, dang that is _old_ | 20:57 |
| rwp | I am feeling the years more and more every day! :-) | 20:58 |
| rwp | If I were to swap the names of packages around to be more current, get rid of elvis now for example, emacs stays the same though, then it would all apply identically now. | 20:59 |
| rwp | Just to be clear though I was "ranting" about emacs versus vi versus vim I was mostly having fun with it and wrote it with a smile on my face. | 21:03 |
| debdog | oh, el_vi_s | 21:05 |
| rwp | Before vim appeared there were several vi clones and elvis was quite popular back-in-the-days before vim really became popular. | 21:05 |
| debdog | I suppose it is pronounced el_whizzz | 21:07 |
| rwp | Before nvi was available actual vi was not free-software and so the clones were needed. There were several. | 21:07 |
| * [-_-] restarting xorg | 21:07 | |
| rwp | Then vi became free'd as nvi missing the encryption feature so that it could be exported. Before that encryption was a munition regulated by the ITAR the Internation Traffic and Arms Regulation (or something similar to that). | 21:08 |
| rwp | But clearly today vim has one the vi-side of the editor wars. Emacs is still popular. When I chat with random people mostly I only hear about vscode which is taking over. | 21:10 |
| rwp | s/one/won/ (gack, can't type) | 21:11 |
| clemens3 | and gnu emacs has one the emacs side, or at least i haven't heard about xemacs in a long time | 23:45 |
| clemens3 | one=won | 23:45 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!