| CERAPIO | hello, Server-2: PipeWire v: 0.3.65 status: off | 00:35 |
|---|---|---|
| CERAPIO | server-1: is jack | 00:35 |
| HimeHaieto | so I just noticed that oldstable/chimaera's release file contains a couple errors setting the origin/label to "None" instead of "Devuan" and it's kinda messing with my pinning preferences...who might be in charge of managing that kind of stuff? | 00:43 |
| HimeHaieto | see here: http://deb.devuan.org/devuan/dists/oldstable-security/InRelease | 00:43 |
| plasma41 | bb|hcb: ^ | 00:45 |
| plasma41 | HimeHaieto: Ask LeePen in #devuan-dev as well | 00:46 |
| HimeHaieto | thanks, will do | 00:46 |
| CERAPIO | This is for debian, and for devuan what is it like? systemctl --user --now enable wireplumber.service | 01:07 |
| bb|hcb | plasma41: THanks for the ping, I have no idea if it is a good idea to change that... | 01:07 |
| HimeHaieto | bb|hcb: what, do you think some critical mass of people would have specifically looked at that, decided they should rely on an empty "None" designation, and also be unable to fix it or something? | 01:34 |
| HimeHaieto | seems like a pretty clear cut error to me in this case, and it's doubtful anyone would be harmed by actually setting it to its proper value | 01:35 |
| HimeHaieto | there actually seems to be some general inconsistency I'm finding, which I've posted more about in #devuan-dev | 01:36 |
| HimeHaieto | given that I legit have an apt policy over 1000 lines long, I was kinda relying on being able to properly distinguish different sources in a meaningful way | 01:37 |
| HimeHaieto | this stuff is a bit...problematic for me in that regard though | 01:38 |
| CERAPIO | Could it be that after an installation from scratch, with netinstall, system files were installed incorrectly? devuan daedalus | 01:38 |
| bb|hcb | HimeHaieto: Please do not misunderstand, I said that I have no idea | 02:06 |
| gnarface | if CERAPIO comes back, someone tell them to wait longer and be more specific about what's going wrong | 02:11 |
| HimeHaieto | bb|hcb: it's alright, going back and rereading my statements I think I may have come across a bit confrontational or even hostile, which I don't intend | 02:16 |
| HimeHaieto | I think maybe spending days constantly having to bang my head against dpkg/apt crap might be starting to really get to me | 02:17 |
| joerg | HimeHaieto: FWIW your reasoning looked flawless tome | 05:45 |
| joerg | NB: I also have no idea about the more arcane details in apt :-) | 05:52 |
| cousin_luigi | Does ifupdown always rely on bridge-utils? Couldn't I use the bridge tool from iproute2 instead? | 08:17 |
| cousin_luigi | (although I suspect I'll have to do everything by hand) | 08:17 |
| u-amarsh04 | cousin_luigi - I am running ifupdown 0.8.41 and it depends on adduser, iproute2 and libc6 | 08:56 |
| cousin_luigi | u-amarsh04: Do you create bridges or vlans in your interface definitions? | 08:56 |
| u-amarsh04 | no, haven't done that | 08:57 |
| u-amarsh04 | bridge-utils suggests ifupdown | 08:58 |
| cousin_luigi | u-amarsh04: Well, if bridge-utils is not installed, my interfaces won't go up. I suppose ifup invokes brctl and that I will have to replace those calls in pre-up/post-down with bridge if I want to avoid the hassle. | 09:03 |
| u-amarsh04 | fair enough | 09:09 |
| |cos| | gnarface: ah. that's your thinking. my machine has always been connected to the power grid, with at least on good fresh fully charged battery, when it has failed to boot. | 09:30 |
| rrq | cousin_luigi: afaict ifupdown does rely on bridge-utils for iface definitions including "bridge_ports ..." though I'm not sure how it's hooked in (doesn't use the if-*.d/ directories for that anymore (?)) | 09:51 |
| rrq | you may have seen "man bridge-utils-interfaces" already | 09:51 |
| rrq | ah; there are links like: /etc/network/if-pre-up.d/bridge -> /lib/bridge-utils/ifupdown.sh | 09:58 |
| rrq | (hmm now I see ugly infection of ifupdown in "/etc/network/if-*/resolved" [purged]) | 10:07 |
| |cos| | i've edited my /etc/init.d/eudev, adding log output on successful `udevadm settle` and an explicit timeout of the same value as the supposed default. hope that'll give some insight if/when my boot blocks again. | 10:12 |
| |cos| | the fact that https://packages.debian.org/eudev returns empty suggests that eudev is a devuan-specific package, right? | 10:13 |
| gnarface | |cos|: probably | 10:19 |
| rrq | (hmm and initscripts drops in a /etc/network/if-up.d/mountnfs ???) | 10:22 |
| cousin_luigi | rrq: /lib/bridge-utils/ifupdown.sh <- that ruined my last few days. I'm inclined to switch to manual invocations of /sbin/bridge | 13:15 |
| cousin_luigi | rrq: mountfs is another thing I can live without | 13:15 |
| * cousin_luigi keeps doing wrong things today. | 13:20 | |
| rrq | I don;t mind the "standard" bridge support, though my network isn't very complex; (just a vm subnet and a virtual lan subnet) | 13:20 |
| rrq | I tend to use "bridge_ports none" though, to control the port interfaces separately | 13:21 |
| rrq | (one quirk with a vlan through the virtual lan subnet to connect the vm subnet with a vm subnet on another host) | 13:24 |
| cousin_luigi | I'm not sure how to convert a vconfig-based setup to bridge | 13:40 |
| rrq | mmm I think I would have a tap interface on a bridge port, then set up vlan(s) on that tap, rather than on the bridge itself | 13:44 |
| rrq | packets to the vlan inferface (way "tap0.1") will become vlan tagged packets to the tap interface | 13:49 |
| rrq | way=say | 13:50 |
| rrq | then delivered on whatever net that tap is, coming out without tagging at any other "X.1" interface on that net | 13:52 |
| rrq | I suppose the a vlan interface could be on the bridges, but not also a ports of that bridge (as that would make a traffic loop) | 13:59 |
| data41201 | Mashing Enter to bypass full disk encryption with TPM, Clevis, dracut and systemd - https://pulsesecurity.co.nz/advisories/tpm-luks-bypass | 14:01 |
| fsmithred | If you're worried about someone mashing the enter key on your remote encrypted system, you should be more worried that they will just wait for you to boot up the machine and open it for them. | 14:37 |
| cousin_luigi | rrq: I'm confused. Right now I have e.g. enp1s0.123 part of br123: how would that translate to the newer model? | 16:25 |
| joigser | Will devuan drop i638 | 20:29 |
| joigser | *i686 | 20:30 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!