| rrq | I guess "ip -d l" does include haystacks about bridge setup | 00:05 |
|---|---|---|
| rwp | So one of the bits of information I want to know is what devices are connected to the bridge. "brctl show" lists those immediately. | 00:07 |
| rrq | so passing that to a semi-clever awk script could probably reinvent brctl | 00:07 |
| rwp | The "ip -d l" command you just provided is good. I am noting it down. But using it I have to dig out the information from the mass of noise around it. | 00:07 |
| rwp | "ip link show | grep --color br0" (my bridge name is br0) shows thins a little bit better. | 00:09 |
| rrq | good. so `ip l | grep master | sed 's/[0-9]*: \([^:@]*\).*master \([^ ]*\).*/\2 \1/' | sort` is almost `brctl show` | 00:16 |
| rrq | or even `ip l | sed '/master/!d;s/[0-9]*: \([^:@]*\).*master \([^ ]*\).*/\2 \1/' | sort` is almost `brctl show` | 00:18 |
| bb|hcb | FWIW brctl is considered obsolete for configuring the bridges (to be more exact, ip is preferred). But for displaying there is no problem just to use brctl (obviously ip is lacking there) | 00:31 |
| rrq | do you know why it's obsolete.. doesn't it do its thing anymore? | 00:31 |
| rrq | or things needing done that it doesn't do? | 00:33 |
| bb|hcb | It does and is doing well. But there is like 15+ y.o. effort to manage linux network by ip/tc/etc that solely use netlink instead of ioctl | 00:34 |
| rrq | hmm so "obsolete" means "we don't like it"? | 00:36 |
| rrq | afaik ifupdown config for bridge setup still uses brctl | 00:38 |
| bb|hcb | Yes, brctl is ioctl based... | 00:47 |
| rrq | yeah, is that something one should worry about? | 00:48 |
| bb|hcb | If the kernel drops the ioctl api, then yes | 00:59 |
| rrq | sure. does it? is that "the plan"? | 01:00 |
| bb|hcb | Live and see, I think that will not happen soon | 01:01 |
| cousin_luigi | I did it! I have a read-only devuan system at last! | 15:21 |
| Besnik_b | gnarface, I don’t hear the artifacts anymore! It might have been a misconfigured jack… an hour playing and no xruns. | 18:28 |
| mrnhmath | anyone in for a classic flavored MATE? ;-) | 19:04 |
| blockhead | you mean you forked mate into a new program? | 19:07 |
| mrnhmath | perhaps | 19:10 |
| gnarface | Besnik_b: nice! well, too bad you don't know exactly what changed, but at least it's working now. | 19:49 |
| Besnik_b | I do somehow. I changed settings in qjackctl | 19:54 |
| Besnik_b | No realtime; Sample rate: 44100; Frames: 4096; Periods 3 (since it’s a USB external audio interface); | 19:55 |
| gnarface | hmm, interesting | 19:58 |
| Besnik_b | Latency went up, 279ms, but I don’t mind | 19:58 |
| Besnik_b | I’m not recording or broadcasting… | 19:58 |
| gnarface | as a USB device, if it's not very very old it should be able to handle 48000 too, i would think. | 19:59 |
| Besnik_b | It’s a Rubix 22 | 19:59 |
| Besnik_b | qjacktl advertises up to 192000 | 19:59 |
| gnarface | if it says that it can probably do it, as long as you have the right period/buffer settings | 20:00 |
| gnarface | is Rubix the manufacturer brand? i don't see it on the wiki | 20:01 |
| Besnik_b | Roland is the manufacturer. | 20:01 |
| gnarface | oh, it's Roland? well they're on the wiki but that device isn't listed | 20:01 |
| gnarface | you might be the first person to get this working | 20:01 |
| gnarface | or at least the first to try | 20:01 |
| Besnik_b | It worked from the first boot a year ago under Siduction. | 20:02 |
| gnarface | huh, but nobody put it on the wiki. a shame... | 20:02 |
| Besnik_b | If you need any probing from my side to add it, feel free to ask. | 20:03 |
| gnarface | heh, well you have exactly as much authority over the alsa project wiki as i do... | 20:04 |
| gnarface | as far as i can tell you'd put it here: https://www.alsa-project.org/wiki/Matrix:Vendor-Roland_Edirol | 20:05 |
| Besnik_b | I’m pretty sure that I bought it after reading confirmations that it worked in Gnu/Linux | 20:05 |
| gnarface | sometimes it's a driver regression and it just fails to auto-detect the correct buffer/period timings | 20:05 |
| gnarface | then setting them fixes it | 20:05 |
| Besnik_b | Let my take note of the task. I might find time to add it. | 20:06 |
| gnarface | the ideal information to add just along with "it works" would be to know the hard minimums on period_time, period_size, buffer_size, etc | 20:07 |
| eyalroz | Hello Devuaners; I want to read about the mechanism which generates /etc/resolv.conf these days | 23:09 |
| eyalroz | man resolv.conf tells me about the final result, not the generation; and /etc/resolveconf/ is almost empty | 23:09 |
| rrq | many get /etc/resolv.conf written by their dhcp client, which takes whatever the dhcp server serves and writes it into that file. | 23:13 |
| eyalroz | rrq: Ok, so, where does dhclient keep rules for how to populate resolv.conf ? | 23:18 |
| eyalroz | i.e. other than copy-paste what the DHCP server said? | 23:18 |
| eyalroz | /etc/dhcp/dhclient-exit-hooks.d/ doesn't seem to hold that | 23:18 |
| eyalroz | and neither does /etc/dhcp/dhclient.conf | 23:19 |
| rwp | eyalroz, The first problem is that there is no such thing as ONE thing that is "the mechanism" generating that file. It might be generated by hand, by program, by several programs. | 23:27 |
| rwp | That was the reason resolvconf was created. So that it could be THE ONE that wrote that file. And so if you use resolvconf then resolvconf is the one thing that writes that file. | 23:28 |
| rwp | But some people don't like resolvconf so they created openresolve as a competitor to resolvconf. It's a different program trying to THE ONE. | 23:28 |
| eyalroz | rwp: Well, I run a pretty plain-vanilla Devuan install, I haven't tried to interfere with that myself. | 23:29 |
| rwp | And this is only needed for dynamic mobile clients using DHCP. A very many clients are statically assigned. Those don't need a dynamic resolv.conf file. | 23:29 |
| eyalroz | How do I check what's used on my system? Do I have to look at... I dunno, /etc/init.d/rcS or something? | 23:29 |
| rwp | And NetworkMangler also writes to be THE ONE too. Look in the file and usually the program that wrote it will say who they are. | 23:30 |
| eyalroz | rwp: Ah, well, I do use NetworkManager. Too bad that it tries to be "The One" rather than just be on a level above "The One". | 23:31 |
| rwp | There was also a disagreement between the resolvconf maintainer and the bind9 maintainer with the result being that neither of them supply a file (resolvconf-update-bind) that both thought the other should provide. Making resolvconf much less useful and incomplete without it. | 23:31 |
| eyalroz | rwp: How very useful. It seems that the domain of name resolution is filled with tall mountains of ego. | 23:32 |
| rwp | For me I write the file on all of my static IP systems and I use resolvconf on my mobile laptops which use DHCP, and I remove NM from all of them. | 23:32 |
| rwp | Yes! Now you have the landscape understood. | 23:32 |
| * rwp gotta run off | 23:33 | |
| blockhead | lol at "networkmangler" :) | 23:41 |
| brocashelm | i hate network-manager, but it's the one with the "least problems" for me of the gui network applets i've tried (connman fucks up the resolv symlink, and i have to relink them if i remove connman) | 23:49 |
| brocashelm | you would think there would be a simple on/off switch for ethernet and a menu of wireless profiles powered by ifconfig | 23:50 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!