| rwp | I have become fond of the full manual debootstrap installation for myself. But that requires being very comfortable with doing everything yourself. | 01:10 |
|---|---|---|
| systemdlete | E: Release file for http://deb.devuan.org/merged/dists/chimaera/InRelease is expired (invalid since 1d 2h 43min 48s). Updates for this repository will not be applied. | 05:03 |
| systemdlete | I am only seeing this on one system, a laptop. But not anywhere else. | 05:03 |
| systemdlete | I am pretty sure the apt configs are identical. | 05:04 |
| systemdlete | I ran "apt upgrade" on laptop and my host system, which use the same apt config. But the host system does not have this error while the laptop does. | 05:08 |
| systemdlete | (I also checked the system times on both, thinking maybe a problem with security due to time differences. But the date/time is the same) | 05:09 |
| systemdlete | The error has disappeared now, but still... what caused that? Anyone? | 05:27 |
| onefang | systemdlete: do you know the IP addresses apt was using at the time for deb.devuan.org on those systems? | 09:42 |
| systemdlete | hmmm. Unless it is still in my scrollback, I probably won't. But let me look... | 09:43 |
| systemdlete | when I pinged devuan.org, it was 54.36.142.179, but maybe the repo is at a different addr | 09:44 |
| systemdlete | (I should have checked deb.devuan.org) | 09:44 |
| systemdlete | but my laptop is on my local wireless, and the wireless goes out via the same router and modem. Why would the addresses be OK for all but the laptop? | 09:45 |
| systemdlete | I mean, why would the laptop be getting a different repo address than the rest of my devuan systems at the same time? | 09:46 |
| lts | That's round robin for you | 09:46 |
| systemdlete | ?lts? | 09:46 |
| onefang | Coz it's a DNS Round Robin, I'm not sure exactly how apt gets it's IPs from that. | 09:46 |
| systemdlete | so are you telling me that apt gets an address and it is stuck with it for a while? I didn't think that would be the case. | 09:47 |
| systemdlete | I figured it was more dynamic than that. | 09:47 |
| lts | I confirm 54.36.142.179 gives that error. | 09:48 |
| lts | Let me check the rest while at it | 09:48 |
| onefang | Well it should stick with that IP for one run, but who knows how your DNS caching works at your end. | 09:48 |
| systemdlete | My entire network uses one dnsmasq server | 09:48 |
| systemdlete | and, afaik, the laptop does not have a dnsmasq server (or bind, etc) | 09:49 |
| lts | 160.16.137.156 same error | 09:49 |
| systemdlete | lts: It was only for a few minutes, maybe 15-20 | 09:49 |
| systemdlete | eventually, the problem cleared itself. | 09:49 |
| lts | Yes, that's round robin for you. You need to enforce the resolution to a specific ip e.g. with /etc/hosts to be really able to test it | 09:50 |
| onefang | 160.16.137.156 is very slow to update. I should remove it from the DNS-RR and send them an email. | 09:50 |
| onefang | 54.36.142.179 isn't part of the DNS-RR for deb.devuan.org. | 09:51 |
| lts | The rest of the RR IPs work fine for me | 09:52 |
| systemdlete | Like I said, I ping'd the wrong address when the problem was occuring. Next time, I will try to remember to ping the deb.devuan.org address | 09:52 |
| systemdlete | onefang: Does linux cache DNS addresses, even with a DNS server? I thought you had to run something like dnsmasq or bind, or else point to a DNS server. | 09:53 |
| onefang | This is why I wrote apt-panopticon, so it can probe package mirrors in many ways on a regular basis. | 09:53 |
| systemdlete | even withOUT a DNS server, sorry | 09:54 |
| onefang | Dunno for sure. I recently switched to unbound and it seems to be caching less. lol | 09:54 |
| lts | systemdlete: check out what "TTL" means in DNS context. Use the "dig" command to see what's happening | 09:54 |
| systemdlete | nslookup OK? | 09:54 |
| systemdlete | I have both dig and nslookup | 09:55 |
| lts | I believe you need dig for this | 09:55 |
| systemdlete | ok, thanks | 09:55 |
| systemdlete | But I'll have to wait until I see this again. | 09:55 |
| onefang | apt-panopticon uses dig for digging around DNS. | 09:55 |
| systemdlete | things seem to be working ok now | 09:55 |
| lts | Specifically, use "dig deb.devuan.org" a few times and observe how the result changes, and the TTL cache time counts down each second | 09:56 |
| systemdlete | I wonder if low battery on the laptop might play a role here... the battery was low at the time, was recharging less than 20% | 09:57 |
| lts | No | 09:57 |
| systemdlete | lts, what if the wireless went out for a moment when apt was trying to connect (apt runs via a remote operation) | 09:58 |
| systemdlete | on a low battery, maybe wireless gets flakey | 09:58 |
| lts | No, this is about how round robin works. To spread the load between several servers, each client randomly chooses the result from the round robin pool. When you query for the A record of deb.devuan.org, it first returns an alias (CNAME) of deb.rr.devuan.org, and then returns a dozen or so IP addresses. Your client randomly chooses one each time | 10:00 |
| onefang | 160.16.137.156's weekly stats are way down on apt-panopticon, so I'm removing it from the DNS-RR. Though I think I JUST missed the update window for that. lol | 10:00 |
| systemdlete | client, is that the local dnsmasq server? | 10:04 |
| systemdlete | I only have one dns server on my entire network. It servers all my hosts, VMs, laptop, etc. | 10:05 |
| systemdlete | it serves, not servers... (sorry for all these typos) | 10:06 |
| lts | Your local dnsmasq server resolves your query and then caches it for the TTL period. It is a client for its upstream server, and a server for the client in your laptop. Likely the dnsmasq's upstream server is also a caching server, acting as a client for its upstream, until an authoritative DNS server is found | 10:13 |
| lts | The result always contains the full dozen or so IPs, it's your endpoint which chooses from them | 10:14 |
| lts | Because your endpoint keeps choosing different IP addresses (as it is supposed to), you saw the problem go away. Most of the IPs worked fine | 10:15 |
| systemdlete | lts: Thanks for that explanation. So a local linux box, say my laptop, does not really cache anything (maybe certain programs do though) | 10:15 |
| gnarface | i know firefox does cache dns results until restarted | 10:16 |
| lts | Some programs indeed do | 10:16 |
| systemdlete | exactly. ok. | 10:16 |
| lts | Practically all of them obey the TTL though, and fetch a new result after TTL has expired | 10:17 |
| gnarface | normally you should not see caching, however i have also had issues in the past when i used to use dnsmasq with it also caching stuff for too long, but i think i actually had set it to do that and simply forgotten | 10:17 |
| systemdlete | so if my dnsmasq dns server was holding various values for deb.devuan.org at moment X when this error was occurring ONLY on the laptop... | 10:17 |
| lts | Your other endpoints probably randomly picked an IP which worked. Your laptop was unlucky | 10:18 |
| systemdlete | So the endpoint obtained a new list and randomly picked a bad one, while my other boxes and VMs did not share that fate. | 10:19 |
| systemdlete | ah, ^ | 10:19 |
| gnarface | i'm noticing a lot more of these mirrors are resolving as ipv6 addresses than before, that might enter into the problem | 10:20 |
| onefang | All but three of them on the DNS-RR have IPv6. | 10:20 |
| systemdlete | hmmm. I know for a fact I don't do any ipv6 here. | 10:21 |
| onefang | Should not be a problem if you don't have IPv6, apt wont use that. | 10:21 |
| systemdlete | eventually perhaps. but for now, I'm happy with ipv4 | 10:21 |
| onefang | I don't have IPv6 at home. I used to, before I moved. I want it back. lol | 10:22 |
| onefang | I may need to send one of my servers IPv6's down my VPN. | 10:22 |
| onefang | Coz otherwise that's installing FTTC into my bedroom, and with the cost of living going up, my pension can't afford that. Had FTTP into my old bedroom. | 10:23 |
| onefang | Yeah I did miss the window for DNS-RR updates. So gotta wait half an hour for that change to get through the system. | 10:26 |
| systemdlete | onefang: Thank you for looking at this and taking action on it. | 10:28 |
| onefang | You are welcome. That's my only job here, package mirror herder. | 10:28 |
| systemdlete | I'll try not to get as hyper next time this happens. Apparently, this is a little fallout from an otherwise normal situation. I couldn't possibly do anything about it myself anyway | 10:28 |
| systemdlete | I just found it a little peculiar. But now, after you and tls responded, it is making more sense to me. I can see how it happens... intermittently :headslap: | 10:29 |
| onefang | Yeah it's always possible you hit a mirror while it was updating, but they should not be a day out of sync. I'm trying to get them all to sync every 30 minutes. | 10:30 |
| * onefang wanders off to do other stuff. | 10:31 | |
| systemdlete | It looks like dnsmasq is giving me 15 addresses. How do I find out which one apt is actually using? | 10:32 |
| gnarface | run jnettop or tcpdump? | 10:32 |
| systemdlete | You said it was random. But in order to determine who is being the bad guy, I'd need to know that, right? | 10:32 |
| systemdlete | oh | 10:33 |
| systemdlete | tcpdump, my old friend | 10:33 |
| gnarface | i'm not sure there's no way to get apt to actually cough up the ip address in the console output... maybe check the man page for options related to verbosity | 10:33 |
| gnarface | but yea i'd probably just cheat and sniff the network traffic | 10:34 |
| gnarface | jnettop is a little friendlier than tcpdump | 10:34 |
| gnarface | not as light-weight | 10:35 |
| systemdlete | apt debug option | 10:35 |
| systemdlete | never heard of jnettop. ntop, tcpdump, wireshark, etc. | 10:36 |
| lts | If you need to enforce a dns result, you can use /etc/hosts (on the endpoint) for it. It is ~always checked before any DNS query is sent | 10:37 |
| lts | s/dns result/dns result for A or AAAA/ | 10:38 |
| systemdlete | right. But if I am trying to figure out which one is the bad guy, I'd have to do some digging | 10:39 |
| onefang | apt usually does cough up the IP in the console when there is issues. | 10:39 |
| onefang | Or just pick a mirror. | 10:40 |
| lts | Unfortunately this error message was one where it does not | 10:41 |
| systemdlete | yeah, it doesn't here. | 10:42 |
| systemdlete | but I think I understand how to deal with it, should it re-occur | 10:42 |
| systemdlete | wish apt would handle this more elegantly. Like, transparently, maybe? | 10:43 |
| lts | You basically just retry and your client will choose another IP, which has 93.3% probability to be a different from a set of 15 | 10:43 |
| systemdlete | lts, I actually tried multiple times, on the laptop and some of the other systems here. | 10:44 |
| onefang | apt-panopticon has a "URL sanity" test, which is there coz of an old apt bug. More elegance would be good. lol | 10:46 |
| lts | Interesting. That does sound like some sort of caching of a single IP. I hit the same error myself yesterday on a host and a simple retry right afterwards worked | 10:46 |
| systemdlete | lts, as you suggest, I figured retrying would help. but this was going on for a good 15-20 minutes. | 10:47 |
| systemdlete | I did try. | 10:47 |
| lts | Sounds like something in your setup does not handle round robin results appropriately, if they only cache a single IP from a result of 15 IPs | 10:48 |
| systemdlete | what does the cacheing on my laptop? It is not running dnsmasq or bind or another dns server. Is this done in, say, libc? Or is this a kernel thing? | 10:48 |
| systemdlete | I mean, specifically, the local (laptop) caching? | 10:49 |
| lts | apt should not cache it, and should always query the server in your /etc/resolv.conf* file(s) | 10:49 |
| systemdlete | so apt should initiate a call to my dnsmasq server every time it runs. Which means apt is not caching it then. | 10:50 |
| systemdlete | and my resolv.conf file was not modified before, during, or after this incident. | 10:51 |
| systemdlete | on the laptop I mean | 10:51 |
| lts | run "dig deb.devuan.org" and you can see what server is used | 10:51 |
| systemdlete | it sounds like you are saying a problem with dnsmasq | 10:51 |
| systemdlete | Oh, I know which server is used. | 10:51 |
| systemdlete | the laptop's /etc/resolv.conf is pointed at my LAN dns server (dnsmasq) | 10:52 |
| systemdlete | so I don't need to dig for that. | 10:52 |
| lts | In your scenario I would look at dnsmasq caching first, yes | 10:52 |
| systemdlete | but if it were a problem in dnsmasq, then I would expect similar issues more frequently, and on a variety of hosts | 10:53 |
| lts | Should be easy to test with "dig deb.devuan.org" | 10:53 |
| systemdlete | I mean, I guess it could have been a momentary glitch | 10:53 |
| systemdlete | lts: YOu mean run dig on the dnsmasq host? | 10:54 |
| systemdlete | not on the laptop | 10:54 |
| systemdlete | because, on the laptop, it will show the dnsmasq server address (and it does) | 10:54 |
| lts | Both ways give you separate pieces of information | 10:54 |
| systemdlete | At any rate, I'll do more investigation next time if it happens | 10:55 |
| systemdlete | thank you both for the info | 10:55 |
| systemdlete | well, everyone that is. There's been more than just lts and onefang helping here | 10:55 |
| lts | Enjoy, DNS is a great source of fun and interesting things | 10:56 |
| furrymcgee | ther are options to log dns queries in dnsmasq | 10:56 |
| systemdlete | is it ever... | 10:56 |
| systemdlete | ah, good idea, furrymcgee. Thanks! | 10:57 |
| systemdlete | YOu know what. I even tried restarting dnsmasq while this was going on. Sorry I forgot that tidbit. | 10:57 |
| systemdlete | several times in fact. | 10:57 |
| systemdlete | I thought maybe there was a an issue with dnsmasq (and it does seem like that could have been the case) | 10:58 |
| furrymcgee | you can also strace -f apt update |& grep inet_addr | 10:58 |
| lts | It could be the source of the issue (only returning the faulty IP) is even higher upstream than your dnsmasq server | 10:58 |
| onefang | Sooo, on the subject of DNS servers... As I mentioned I have recently switched to unbound, coz it supports all these new ways of DNS lookups. | 11:40 |
| onefang | But it often fails. My various things that regularly lookup DNS to do something (fetchmail, web page refreshes, icinga) will several times a day fail to find them. | 11:41 |
| lts | Sounds like there is an issue with its forwarding servers | 11:42 |
| onefang | Most of them are my own server, or servers I look after. | 11:42 |
| lts | My unbounds are rock solid using 1.1.1.1 as upstream/forwarding. I did have similar issues you describe with my ISPs servers, though. | 11:43 |
| onefang | I'm using the stock config of Chimaera's unbound. What do I tweak? | 11:43 |
| onefang | I usually avoid my ISPs servers, no matter who they are. lol | 11:43 |
| lts | Ooh, there is plenty for you to configure then. Unbound has lots of nifty features not enabled by default | 11:44 |
| lts | https://wiki.archlinux.org/title/unbound#Forwarding_using_DNS_over_TLS is the config to set your upstream servers to 1.1.1.1 using DoT | 11:44 |
| onefang | Ah good old Arch docs. | 11:44 |
| lts | Plenty of unbound configs on the internet, muscle memory often leads to arch wiki though :-) | 11:45 |
| onefang | I did already have that page open, but was hoping someone had a quick Devuan fix. | 11:45 |
| onefang | Anhd that first option Arch mentions tls-system-cert doesn't seem to exist in Chimaera's version. lol | 11:51 |
| onefang | Ah "tls-cert-bundle or use tls-win-cert" sayeth the manual. | 11:52 |
| lts | The one in debian/devuan stable is indeed very old, but unfortunately backporting is not deemed necessary either. I've compiled from unstable deb-src the latest one | 11:53 |
| lts | Main reason for that was the ability to drop AAAA queries completely in an ipv4 network, which came in 1.15.1 IIRC | 11:54 |
| onefang | Well stable has "do-ip6", and I'd much prefer to stick with stable for most things. | 11:56 |
| lts | That is a separate thing - do-ip6 only controls does the server respond or issue using ipv6. Happy eyeballs causes clients to typically send both AAAA and A queries despite ipv4-only environment, and sometimes that AAAA query takes a long time | 11:59 |
| lts | But yeah, it's not a showstopper. Should be available in daedalus when released | 12:00 |
| furrymcgee | does devuan.org have a public dns server? | 12:01 |
| onefang | There's also prefer-ip4. | 12:01 |
| lts | It will happily send that AAAA query over ipv4 :-) | 12:02 |
| onefang | tls-cert-bundle: "/etc/ssl/certs/ca-certificates.crt" | 12:03 |
| onefang | instead of the unsupported tls-system-cert: yes | 12:04 |
| onefang | And it works at least. Now to wait a day and see if it stops not finding my own servers. | 12:04 |
| lts | Ah, found it. The setting I'm referring to is "aaaa-filter: yes" | 12:04 |
| onefang | Well since I WANT IPv6, and should eventually get around to adding IPv6 to my desktop some day, plus once I have unbound working fine on my desktop I'll put it on my servers, which have IPv6 .... that option doesn't interest me at all. B-) | 12:07 |
| onefang | Seems to have fixed reverse lookups to. Which was the next thing I was gonna bitch about. lol | 12:09 |
| onefang | furrymcgee: If you mean a DNS server you can point your resolver at, not that I know of. | 12:21 |
| onefang | Obviously there's our DNS zone server for providing things like deb.devuan.org to the world. | 12:22 |
| furrymcgee | would it be possible to use round robin to select the nameserver itself? | 12:31 |
| lts | That is what the optional "rotate" setting in resolv.conf is for | 12:33 |
| oscareczek | hi, I have 2 problems after migrating from Debian Stable on my X230 with Plasma | 16:07 |
| oscareczek | 1. micmute button doesn't work, on systemd acpi_listen outputs `button/f20 F20 00000080 00000000 K`, on sysv it's `button/micmute MICMUTE 00000080 00000000 K`, latter isn't detected in Plasma settings at all; similarly, ThinkVantage was `button/prog1 PROG1 00000080 00000000 K` and is `button/vendor VNDR 00000080 00000000 K` | 16:09 |
| gnarface | just guessing but try installing acpid if it's not, then check for some configurable setting for the button in plasma if it is | 16:10 |
| oscareczek | 2. I can't get wireguard to start at boot - manually starting this https://www.procustodibus.com/blog/2021/06/wireguard-sysv-init-script/ with $local-fs to $local_fs works, update-rc.d created rc[0-6]/*wg0 | 16:10 |
| oscareczek | acpid is already started, configurable settings in Plasma don't detect buttons | 16:11 |
| gnarface | the second one is probably something simple if it works when run manually | 16:12 |
| oscareczek | yeah, I feel like I'm missing something trivial | 16:12 |
| gnarface | the script file in /etc/init.d has to be executable, and has to end in .sh if you don't have proper LSB headers | 16:13 |
| oscareczek | it is +x, I have lsb-{base, release} installed | 16:13 |
| gnarface | make sure it isn't checking for a flag in a file in /etc/default/ | 16:13 |
| oscareczek | I don't see any mention of /etc/default and there's nothing there connected to wireguard | 16:14 |
| gnarface | (by LSB headers i mean the text block in the top of the script containing $local_fs, etc... double check that against a working script) | 16:14 |
| oscareczek | oh, lol | 16:15 |
| oscareczek | they look fine | 16:16 |
| gnarface | wireguard needs root permissions? | 16:16 |
| oscareczek | iirc yes | 16:16 |
| gnarface | is it getting them from that script? | 16:16 |
| gnarface | if it's being run as another user, that user might not have the proper permission but systemd wouldn't care | 16:17 |
| oscareczek | well, it should be launched from /etc/rc2.d/S02wg0 automatically and I don't su anywhere, so I guess it has root permissions…? | 16:18 |
| gnarface | is the file in /etc/init.d called wg0? | 16:18 |
| oscareczek | yes | 16:18 |
| lts | Race condition with ethernet not yet up / not yet having an IP? | 16:19 |
| lts | *ethernet or wifi | 16:19 |
| gnarface | yea maybe that... make sure the LSB headers contain $network | 16:19 |
| oscareczek | they do contain RequiredStart: $network | 16:19 |
| oscareczek | with hyphen | 16:19 |
| gnarface | and there's evidence of it trying to start in the output of dmesg at all? | 16:20 |
| gnarface | *no evidence? | 16:21 |
| oscareczek | it is loading, but earlier than my WLAN driver | 16:21 |
| lts | I'm not fully trusting $network really means the device has connectivity yet. I remember using a "ping until success or timeout" loop for some services | 16:21 |
| oscareczek | so it looks indeed like it's a race | 16:21 |
| gnarface | there's some other things you can throw into Required-Start that should reliably come up later i think | 16:22 |
| gnarface | or you could just run it from /etc/rc.local which should run absolutely last | 16:22 |
| oscareczek | hmm, let's try that | 16:23 |
| lts | Required-Start: $all is also a possibility | 16:23 |
| oscareczek | is just adding `/etc/init.d/wg0 start` at the end enough? | 16:24 |
| gnarface | from the init.d maybe you could try something like $syslog $time $remote_fs | 16:24 |
| gnarface | or $all yea | 16:24 |
| gnarface | uh, you'd add that to the /etc/rc.d before the "exit 0" on the last line | 16:24 |
| gnarface | er, i mean the /etc/rc.local | 16:25 |
| gnarface | but yea it should run as root implicitly | 16:25 |
| gnarface | worth a try anyway | 16:25 |
| gnarface | only other thing i can think of is if the program you're trying to run insists on being started from an interactive shell | 16:25 |
| gnarface | maybe also increase "02" in the "S02" to a higher number but it might not matter anymore | 16:27 |
| oscareczek | I tried Required-Start: $all, didn't help | 16:35 |
| oscareczek | I don't have exit 0 anywher in rc.local | 16:36 |
| gnarface | hmm, pretty weird | 16:36 |
| gnarface | i wonder if you're missing a package | 16:36 |
| gnarface | do you have the "initscripts" package installed? | 16:36 |
| oscareczek | it's in initscripts, I reinstalled it, didn't changed | 16:36 |
| gnarface | you have "sysv-rc" installed too? | 16:37 |
| oscareczek | I do automatically | 16:37 |
| gnarface | suspicious, but just add "exit 0" to the end of the rc.local file | 16:37 |
| oscareczek | okay then | 16:37 |
| gnarface | the only other thing in the stock one is some comments | 16:38 |
| oscareczek | I also have `run-parts /etc/boot.d` if this file is present | 16:38 |
| gnarface | i'm not sure what boot.d is from, i don't have that here | 16:39 |
| gnarface | you migrated from debian stable to devuan stable? chimaera? | 16:40 |
| oscareczek | yes | 16:40 |
| oscareczek | adding the service at the end of rc.local also didn't help | 16:40 |
| linux_n | When i run this command: sudo add-apt-repository ppa:linuxuprising/apps i get this error ---> Error: could not find a distribution template for Devuan/chimaera | 16:40 |
| linux_n | Anyone know how to fix? | 16:40 |
| gnarface | oscareczek: you did "apt-get update && apt-get dist-upgrade" right? | 16:41 |
| oscareczek | I followed the migration tutorial from A to Z | 16:41 |
| gnarface | linux_n: ubuntu repos won't work | 16:41 |
| gnarface | oscareczek: something is fishy for sure here. not sure what we're missing but you should be able to get something to run from /etc/rc.local even if it's just an echo... the rc.local file is set to executable right? | 16:42 |
| oscareczek | it is | 16:43 |
| gnarface | ok, couple other sanity checks | 16:44 |
| oscareczek | I mean, it is progress since wireguard started slightly later | 16:44 |
| gnarface | make sure /bin/sh is a link to bash not dash | 16:44 |
| oscareczek | just still not late enough | 16:44 |
| fifiopenbsd | yoo | 16:44 |
| linux_n | Can tlpui be installed on devuan or not possible on devuan? | 16:44 |
| gnarface | make sure "ENV_SUPATH" in /etc/login.defs contains: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin | 16:44 |
| oscareczek | it is | 16:45 |
| gnarface | linux_n: never heard of it | 16:45 |
| oscareczek | hmm, the link was actually wrong, but again, my problem isn't that the service doesn't start, but that it starts too soon | 16:46 |
| gnarface | linux_n: it's not in the list of banned packages so maybe try building it | 16:46 |
| oscareczek | it parses the file | 16:46 |
| gnarface | oscareczek: oh, you're sure it gets run | 16:46 |
| gnarface | oscareczek: i thought that was still in question | 16:46 |
| gnarface | i wonder if it's hanging waiting for wifi then timing out or something | 16:46 |
| gnarface | any way to get wifi out of the loop as a test? | 16:47 |
| oscareczek | from what I remember on another machine, I think it immediately fails because it can't find domain | 16:47 |
| gnarface | it really should have worked from /etc/rc.local though unless it needs wifi to be actually up... | 16:47 |
| linux_n | gnarface: Ok | 16:48 |
| oscareczek | I don't have a cable to connect to the router and I believe it really needs to be able to access DNS server before anything | 16:48 |
| gnarface | oscareczek: well the thing is depending on your install i think wifi might not actually connect until you login to a GUI | 16:48 |
| oscareczek | how do I make it as soon as possible with NetworkManager? | 16:49 |
| gnarface | i'm the wrong person to ask about that, i would have just put the config into /etc/network/interfaces by hand already | 16:49 |
| oscareczek | well, that still requires wpa_supplicant | 16:50 |
| oscareczek | so same question, but with that | 16:50 |
| gnarface | i'm not saying networkmanager can't do it, i'm just saying i don't know much about networkmanager | 16:50 |
| gnarface | yea, it'd still need wpa_supplicant but if the config was in /etc/network/interfaces directly, it would start wpa_supplicant on demand | 16:50 |
| oscareczek | also, that isn't really an option, it needs to be really idiot-proof, it's my mother's laptop | 16:51 |
| gnarface | hmm, i wonder if we're going about this the wrong way now that i think of it... maybe the right way to do this with networkmanager is to have networkmanager start wireguard | 16:51 |
| oscareczek | so I can't really hardcode IP because well, I don't know where she'll connect | 16:51 |
| oscareczek | hmm, maybe? | 16:51 |
| gnarface | note that /etc/network/interfaces can use dhcp though, no IP hardcoding necessary | 16:52 |
| gnarface | finding a place to put the password for people who can't use textfiles would be a problem though | 16:52 |
| gnarface | yea see if the networkmanager gui has a field for post-up commands or something | 16:53 |
| gnarface | there might be an extra package for it or something | 16:55 |
| gnarface | wireguard-tools? dunno | 16:55 |
| fifiopenbsd | wow gnarface, you're still alive, wow! | 16:56 |
| rrq | oscareczek: I'm not sure with networkmanager but dhclient might have "enter/exit hooks" for scripts | 16:57 |
| rrq | that'd be a good place for virtul cabling to spring to life | 16:58 |
| rrq | for it's "man dhclient-script" | 16:58 |
| rrq | for me it's "man dhclient-script" | 17:00 |
| gnarface | oh, dhclient hooks are a good call too, because then you know the wifi has handed you a dhcp configuration which would happen last | 17:00 |
| gnarface | system might detect wifi "up" as soon as there's a link, well before the response from the dhcp server | 17:00 |
| gnarface | and if your wifi is slow to finish the handshake that can cause significant problems | 17:01 |
| oscareczek | okay, yeah, I completely forgot I can configure wg with networkmanager, that works, thanks | 17:01 |
| gnarface | whew ok one problem down then | 17:02 |
| gnarface | i'm afraid i don't know how to remap buttons in kde though | 17:02 |
| gnarface | still can't even figure out how to call a shell script from a desktop icon there (i prefer enlightenment, which is less stable but much more obedient) | 17:03 |
| gnarface | someone around here has gotta know about kde though | 17:04 |
| oscareczek | I don't really think it's KDE's problem, rather systemd doing everything except being a good init | 17:04 |
| oscareczek | because *something* clearly renames these buttons | 17:04 |
| gnarface | hmm | 17:04 |
| gnarface | i thought that was the kernel or Xorg or something though | 17:05 |
| gnarface | it is weird that they're even different | 17:05 |
| gnarface | they shouldn't be different, and neither should either of those packages | 17:05 |
| gnarface | xorg and the kernel are not forked | 17:05 |
| gnarface | but i doubt kde is either... | 17:06 |
| gnarface | doesn't seem like there's anywhere else to point the blame but acpid | 17:07 |
| gnarface | also not forked though | 17:07 |
| gnarface | oscareczek: can you check the button signals with xev? | 17:07 |
| gnarface | just as a sanity check, make sure they're reporting the same thing | 17:12 |
| oscareczek | afk for now, I guess I'll try in an hour | 17:21 |
| oscareczek | or nvm, I managed to find a moment | 17:25 |
| oscareczek | xev is silent | 17:25 |
| oscareczek | for these keys, that is, it reports everything else | 17:25 |
| gnarface | now that's weird | 17:26 |
| gnarface | when it was on debian had you used anything from backports? | 17:27 |
| oscareczek | no | 17:27 |
| gnarface | just grasping at straws here but theoretically something from backports might have not been properly replaced during the upgrade from debian to devuan | 17:27 |
| gnarface | theoretically this could be some bug in libinput or something like that i think, but it'd likely have to be somehow a different version from the one you were using, or the wrong version for debian | 17:28 |
| gnarface | er, devuan | 17:28 |
| gnarface | did you have a special keymap set? | 17:29 |
| oscareczek | pl2, which is just us with different stuff behind RAlt | 17:29 |
| gnarface | something other than the default for "dpkg-reconfigure keyboard-configuration" ? | 17:29 |
| oscareczek | I never touched keyboard-configuration since debian installer | 17:30 |
| gnarface | you might want to double check it's still set right | 17:30 |
| oscareczek | keyboard is pc105 currently and likely since the beginning | 17:30 |
| hightower2 | hey is there a devuan image for qubes? | 21:02 |
| gnarface | is that some sort of arm system? | 21:05 |
| gnarface | or a virtual server? | 21:06 |
| lts | https://www.qubes-os.org/ I presume (which I also use) | 21:06 |
| lts | And no, I haven't heard of one | 21:06 |
| lts | Basically a hypervisor + desktop, segmenting your use. Debian and Fedora come as standard. | 21:08 |
| hightower2 | yes, qubes-os | 21:14 |
| gnarface | can you just upgrade a debian image to devuan? would it work? | 21:16 |
| hightower2 | I guess it'd work only if all the system commands qubes executes remain exactly the same | 21:16 |
| gnarface | well does it rely on systemd stuff? | 21:17 |
| hightower2 | it's defined in the template | 21:17 |
| hightower2 | (trying to find a doc documenting template creation so we can see) | 21:17 |
| lts | Definitely worth a try. I can't right away think of a reason what would be a showstopper | 21:17 |
| lts | I've mentally resigned from the idea of purging systemd from the qubes machine. The main hypervisor will always run fedora anyway | 21:18 |
| gnarface | well, worth a try but have a backup first | 21:18 |
| lts | Fortunately backups are very easy, as qubes is all about everything being a virtual machine | 21:19 |
| lts | hightower2: test and tell us, please? | 21:19 |
| hightower2 | trying to find a debian template def | 21:20 |
| hightower2 | I guess this would be relevant in case of in-place ugprades: https://www.qubes-os.org/doc/templates/debian/in-place-upgrade/ | 21:21 |
| lts | It is | 21:21 |
| kolofon | hi, i'm an apparent spammer at dev1 | 21:58 |
| kolofon | i wrote a few days back about it here and nothing's changed | 21:58 |
| kolofon | would someone like to help me? | 21:59 |
| gnarface | key kolofon someone saw your message, but you were already gone | 21:59 |
| gnarface | golinux: kolofon is back | 21:59 |
| kolofon | i was told i wouldn't need to do a thing, so i went | 22:00 |
| kolofon | should i wait now? | 22:01 |
| gnarface | yea, wait. i dunno what else is needed from you, sorry | 22:01 |
| kolofon | ok, i'll be around for a while. thanks. | 22:02 |
| kolofon | btw, i recently installed devuan and i like it | 22:03 |
| gnarface | you're welcome to stay connected even if you're not still there. it might improve your ability to get a response... | 22:03 |
| kolofon | how would i stay connected? | 22:03 |
| kolofon | ok, i think i understand | 22:04 |
| gnarface | you won't be kicked from this end for being idle | 22:04 |
| kolofon | yes, clear | 22:04 |
| kolofon | that would be weird though | 22:04 |
| gnarface | most the other people here do it, it's less weird than you think | 22:04 |
| kolofon | do you mean i should shut up? | 22:04 |
| kolofon | i don't use irc much | 22:05 |
| gnarface | no, i just mean that if you're still connected and someone has to ask you a question or give you instructions, then the reply will be in your scrollback history | 22:05 |
| kolofon | next to never in fact | 22:05 |
| gnarface | if you disconnect then nobody can reply to you | 22:05 |
| kolofon | yes, that's a pity | 22:05 |
| golinux | I am here kolofon! | 22:06 |
| kolofon | is it not recorded some public place? | 22:06 |
| gnarface | oh it is logged actually too | 22:06 |
| gnarface | somewhere... | 22:06 |
| brocashelm | big brother is watching ;) | 22:07 |
| eyalroz | brocashelm: Does that comment have anything to do with the fact that your nickname begins with "bro"? | 22:08 |
| eyalroz | So, fsmithred, golinux, other channel denizens - I've installed daedalus. Would you guys like another 3-4 forum posts with complaints/peeves following the installation? | 22:10 |
| eyalroz | Like my series of posts last year? | 22:10 |
| brocashelm | eyalroz: no, my nick is taken from a heavy metal band named brocas helm | 22:36 |
| golinux | eyalroz: You are certainly predictable . . . LOL! | 22:38 |
| eyalroz | golinux: Ok... but, is that a yes or a no? | 22:39 |
| golinux | You do not need anyone's permission to post on the forum. | 22:42 |
| kolofon | ok, done. thanks for help, gnarface. | 23:15 |
| eyalroz | On another note... what is the "right way" to keep a standalone, self-updating version of firefox (or thunderbird), rather than the distro-provided one? I've been using the alternatives mechanism to link to /opt/firefox/firefox , but this has some glitches, with apps occasionally trying to start the other copy of firefox, | 23:59 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!