| analbleeding | ubuntu | 01:26 |
|---|---|---|
| hyrcanus | echo "export DBUS_FATAL_WARNINGS=0" >> ~/.bashrc | 04:35 |
| hyrcanus | f-u dbus | 04:35 |
| CAPTCHA_REQUIRED | everybody hates dbusy but nobody's written a replacement | 04:40 |
| hyrcanus | :) | 04:40 |
| hyrcanus | b0rk b0rk b0rk | 04:40 |
| golinux | I don't think that dbus cares | 04:40 |
| golinux | Take the rant to OT please | 04:41 |
| hyrcanus | the envvar above fixed a n0-w0rk for me, so mabe it halpes someone | 04:41 |
| CAPTCHA_REQUIRED | thankyou | 04:44 |
| tinyweasel | Is it me or is deb.devuan.org not resolving? | 09:25 |
| tinyweasel | tried a different DNS resolver, etc | 09:25 |
| tinyweasel | yeah, actually | 09:26 |
| tinyweasel | I think devuan's sites are blocking mullvad servers | 09:26 |
| tinyweasel | lovely, then... :( | 09:26 |
| DPA | Isn't working for me either. SERVFAIL | 09:26 |
| tinyweasel | yikes | 09:26 |
| DPA | pkgmaster.devuan.org still works | 09:27 |
| tinyweasel | well, that's good, I suppose | 09:27 |
| DPA | Not sure who needs to deal with this. I'll just ping a few people. | 09:34 |
| DPA | parazyd, rrq: deb.devuan.org is broken | 09:34 |
| tinyweasel | also, can they remove their IP rule blacklists, it seems? It's broken mullvad for me | 09:34 |
| tinyweasel | *for me, with devuan sites | 09:34 |
| tinyweasel | though, I'd like to know if mullvad is doing it, ideally | 09:34 |
| DPA | It seams pkgmaster.devuan.org is resolvable, but I can't load it. Same with devuan.org. So I guess it doesn't work anymore after all. | 09:37 |
| tinyweasel | yeah, that sucks | 09:37 |
| tinyweasel | I already mirror the debian repos (VMs, etc), but erh, I really was considering mirroring the devuan repos | 09:37 |
| tinyweasel | but if I could find out what tools they were using to "merge" the repos, that'd be amazing | 09:37 |
| tinyweasel | like, do it on the fly per package if requested | 09:38 |
| tinyweasel | then purge from the cache when not needed | 09:38 |
| DPA | I think it was amprolla. There used to be some instructions to just mirror devuan packages on pkgmaster.devuan.org. | 09:39 |
| tinyweasel | >mnt-by: OVH-MNT | 09:39 |
| tinyweasel | yeah, there's netsplits, it seems | 09:39 |
| tinyweasel | caused by OVH problems | 09:39 |
| tinyweasel | but yeah, that's interesting | 09:39 |
| DPA | I mirror a few releases / archs with apt-mirror locally, but it's not all of it: https://mirror.dpa.li/linux/repository/apt/ | 09:40 |
| tinyweasel | yeah, I use ftpsync | 09:40 |
| benben159 | is anyone know why deb.devuan.org is connection timed out several minutes ago? | 10:06 |
| tinyweasel | benben159: OVH is having issues right now, it seems | 10:07 |
| DPA | Looks like it's back. | 10:49 |
| benni_dito | DPA yes | 11:14 |
| * jla uh... just tried to install GNU Jami on a fresh Chimaera install ... 'E: Unable to correct problems, you have held broken packages. ' | 13:00 | |
| hyrcanus | there may be temporary problems with your repository today | 13:01 |
| jla | ah...yess, you mentioned it, a while ago, thX | 13:02 |
| blackSurge | Hola!~ | 13:32 |
| luser978 | smaller fire than last time? or bgp drop... @ovh | 13:33 |
| * jla yeah... Fuckerberg knows about BGP drops ... :-P | 13:39 | |
| hyrcanus | statement from OVH https://corporate.ovhcloud.com/en/newsroom/news/network-incident/ | 15:15 |
| hyrcanus | "particularly intense over the course of recent weeks" | 15:15 |
| hyrcanus | interesting that someone announced this would happen... K.S. | 15:15 |
| onefang | Naturally this problem with deb.devuan.org happens while I sleep, but seems to be OK now. | 17:01 |
| hyrcanus | :) | 17:03 |
| hyrcanus | 7 | 17:03 |
| onefang | If it has problems in the future, please don't use pkgmaster, coz that's the master server the other mirrors sync from, and we don't want to bog it down. Pick something else from https://pkgmaster.devuan.org/mirror_list.txt | 17:03 |
| onefang | deb.devuan.org is a round robin DNS, that points to our package mirrors. It's entirely possible this so,rt of problem might happen to the particular mirror you happen to get resolved to, not the entire set of them. | 17:05 |
| hyrcanus | could pkgmaster be configured to only accept connections from a whitelist of mirrors, or would that be too restrictive | 17:05 |
| gnarface | left accessible to us specifically for debugging; don't abuse it | 17:05 |
| onefang | I have a TODO to make things a bit more dynamic based on my apt-panoptican testing. | 17:06 |
| onefang | Er apt-panopticon. | 17:06 |
| hyrcanus | is it better for me to select a mirror in my country, or will deb.devuan.org round-robin them? | 17:07 |
| hyrcanus | redirect, whatever | 17:07 |
| hyrcanus | hm i see it should redirect ok | 17:08 |
| gnarface | ymmv | 17:10 |
| gnarface | some people have problems with certain repos | 17:10 |
| hyrcanus | works great for me | 17:10 |
| gnarface | the round-robin should work for most people | 17:10 |
| onefang | It's up to you. Once I pull my finger out and get that TODO done, deb.devuan.org should be the most reliable. Any given specific mirror might go down for some random reason at some random time. | 17:11 |
| hyrcanus | devuan works really well for me. | 17:11 |
| onefang | The TODO is to test them all every ten minutes, have deb.devuan.org resolve to the ones that passed the tests this time. So should be more reliable. | 17:11 |
| user____ | Is there something new in kernel 'Linux beowulf 4.19.0-17-amd64 #1 SMP Debian 4.19.194-3 (2021-07-18)' which prevents guest qemu sessions from seeing the internet no matter what I do with qemu -nic -net etc options? Even if using options known to work from 2-3 kernels ago? | 20:47 |
| gnarface | not that i know of but there could be | 20:48 |
| gnarface | before though, had you tried it on actual Debian with systemd? systemd might behave differently with regards to tun/tap setups | 20:49 |
| gnarface | so maybe that's all that changed with regards to this is now you have to set some modules and permissions up manually | 20:49 |
| gnarface | i think the group you need to be in for that is plugdev or netdev | 20:50 |
| gnarface | or maybe dialout? | 20:50 |
| onefang | It's working in kernel 5.10 from beowulf backports at least. | 20:50 |
| gnarface | something like that | 20:50 |
| gnarface | you probably also want to be in the kvm group if you're using kvm accel | 20:50 |
| gnarface | and, there might be a better way to do this but what i did was just load the tap and bridge stuff up manually ahead of starting qemu | 20:51 |
| user____ | No debian was molested here. It worked with a different image (nothing else changed) a few weeks ago. I only upgraded the kernel. | 21:00 |
| user____ | Afaik -net nic should simply work, the guest should see the internet the host is connected to. Correct? That's how it worked before. | 21:01 |
| user____ | And am not using kvm, running qemu as user or root makes no difference for this issue. | 21:01 |
| user____ | Been googling, I think I am missing something important. | 21:01 |
| gnarface | hmm. well when i tried it that way, my research indicated the ethernet card would have to be dedicated to the qemu guest; as in the host and guest couldn't both use it at once | 21:02 |
| user____ | I MAY have updated qemu too, did not look. | 21:02 |
| user____ | gnarface: that sounds like you want a bridge. | 21:02 |
| gnarface | but what i was able to do was add the host physical device in a bridge with a tap device before qemu starts | 21:02 |
| gnarface | yea, that is what i went with | 21:02 |
| user____ | Yes, but it worked w/o manual tinkering with bridges before. | 21:03 |
| gnarface | if the bridge is set up and populated with both the tap and eth0 devices ahead of time, qemu can be just given the tap device and is able to use it without having to bother configuring it | 21:03 |
| gnarface | and, importantly, nothing breaks after qemu is shut down either | 21:03 |
| gnarface | hmm, even as far back as wheezy i think i had only ever tried this with dedicated physical ethernet devices for the guests | 21:04 |
| gnarface | i agree it should work i just am not claiming i ever knew how | 21:04 |
| user____ | Weird. Okay, I'll give it another go tomorrow, 10pm now, my head is buzzing. | 21:05 |
| gnarface | hmm, the man page does also indicate that the "user" backend should be able to do this | 21:06 |
| gnarface | qemu-system-x86_64 -netdev user,id=n1,ipv6=off -device e1000,netdev=n1,mac=52:54:98:76:54:32 | 21:06 |
| user____ | yes. But there is some advance in security and also some bit-rot involved. | 21:06 |
| gnarface | qemu-system-x86_64 -nic user,ipv6=off,model=e1000,mac=52:54:98:76:54:32 | 21:06 |
| gnarface | any of that look familiar? | 21:06 |
| user____ | I used various stanzas, the simplest: -net tap -net nic | 21:06 |
| gnarface | yea i dunno if it's a change in kernel permissions or qemu defaults or what | 21:06 |
| user____ | Which should do it but no | 21:06 |
| gnarface | most my virtualization experience is actually with linux-vservers | 21:07 |
| user____ | Also -net user -net nic | 21:07 |
| user____ | -net is deprecated but still works | 21:07 |
| user____ | Ok, I'll look at it harder tomorrow. | 21:07 |
| systemdlete | any way to get rid of that long delay due to mandb update during package installs? Various web pages have suggestions, but they don't address the problem. One suggests simply getting rid of mandb altogether; some packages depend on mandb, so that is not a solution. Another suggests completely disabling ipv6, which may have been OK when the guy wrote that "solution" but in 2021 that is both silly | 21:25 |
| systemdlete | and ignorant. | 21:25 |
| systemdlete | (and the latter was an article on Tech Republic) | 21:26 |
| systemdlete | Actually, if there really is a way to get rid of mandb, I'd be OK with that. I find myself searching for "man blah" on the web these days (and avoiding hits from die.net!) | 21:27 |
| gnarface | systemdlete: change to max cpu speed before doing updates maybe? | 21:34 |
| gnarface | it'll help a little | 21:34 |
| gnarface | the load of triggering stuff like package unpacks and db builds from packages is almost never enough to engage the cpu scaling governors, but if you force it to max speed ahead of time, conspicuous bottlenecks still are alleviated | 21:35 |
| systemdlete | I've never had to do anything like that in the past. This problem has only started appearing recently, maybe over the past 3-6 months. It may have happened previously, but the delays now have become ridiculously long. | 21:37 |
| gnarface | i assume that's just probably because they switched from gz to xz | 21:37 |
| gnarface | maybe you can switch it back, not sure | 21:37 |
| systemdlete | newer kernels maybe prioritizing multitasking differently now? | 21:37 |
| systemdlete | aha! | 21:37 |
| gnarface | xz is a lot slower | 21:38 |
| gnarface | i'd check on that first | 21:38 |
| systemdlete | yes, THAT could be an explanation | 21:38 |
| systemdlete | so you are telling me that mandb pages are being compressed with xz rather than gz now? | 21:38 |
| systemdlete | or is that for everything? | 21:38 |
| systemdlete | (and do man pages really, really need to be compressed ffs?) | 21:39 |
| gnarface | well not exactly. what i'm telling you is i've noticed that xz has replaced the compression mechanism for a lot of other conspicuous stuff, like the initrd.img, and it has caused notable bottlenecks for me too | 21:39 |
| rwp | Also look at the fsync() problems. There is a ticket with information from like ten years ago still open. | 21:39 |
| gnarface | so at this point the mandb thing is merely a hypothesis | 21:39 |
| gnarface | but it definitely fits the pattern of everything else switching to xz | 21:40 |
| systemdlete | rwp: I attached strace during these episodes and saw that apt was in a tight wait loop, making zillions of system calls | 21:41 |
| rwp | Could you tell what category of system calls? | 21:41 |
| systemdlete | ie, even though it was supposed to be waiting, it was timing out and resetting the wait over and over again | 21:41 |
| systemdlete | rwp: I've forgotten. It is one particular one... hold on | 21:41 |
| systemdlete | select() | 21:42 |
| rwp | In any case... This was the ticket I referred to: https://bugs.debian.org/700633 | 21:42 |
| systemdlete | (I think) | 21:42 |
| rwp | Even though that ticket I referenced is on debootstrap really the root cause is dpkg. | 21:42 |
| systemdlete | You filed that in 2013? Someone in 2019 uttered that they were appalled this had not been addressed by 2019 when he posted to that list. | 21:48 |
| systemdlete | istm that either that system call is not working as intended (unlikely) or the program is setting too short a timeout -- aside from having to wait on a sub task to complete, the waiting routine should not be issuing the same calls in rapid fire succession like that. Of course, I have not studied the guts of dpkg either... | 21:50 |
| luser978 | run strace -ff $bin - select is waiting on a fd for data, likely a child process | 21:58 |
| rwp | Phillip Susi posted that ticket. I commented upon it. Both in 2013. In this year 2021 Holger Levsen commented that the blockers for the bug being fixed had been fixed. | 22:07 |
| rwp | Discussing why I believe overuse of fsync() is trouble is best left for -offtopic and another time. Since -offtopic is at this moment consumed by a different flamefest. | 22:08 |
| systemdlete | luser978: thanks for looking at this. Do you see rapid-fire calls to select() as I did? | 22:10 |
| systemdlete | I wonder, is this convo more suitable for -dev? | 22:11 |
| systemdlete | (irdk) | 22:11 |
| systemdlete | it IS a kind of support issue, otoh. But it can really only be addressed by devs I think | 22:11 |
| rwp | Certainly discussing how to work with and around the current environment is on topic here. So I recommend eatmydata to speed up dpkg to tolerable levels. | 22:13 |
| systemdlete | so this is something I need to install? | 22:14 |
| systemdlete | patch? | 22:14 |
| rwp | I link eatmydata to /usr/local/bin/ apt-get and dpkg so that I always get it automatically. (I am sure that some people here reading this will be aghast!) | 22:14 |
| rwp | Top of my head: apt-get install eatmydata ; ln -s /usr/bin/eatmydata /usr/local/bin/dpkg ; ln -s /usr/bin/eatmydata /usr/local/bin/apt-get | 22:15 |
| systemdlete | this approach seems sort of kludgy. I'd prefer a real bug fix. | 22:15 |
| rwp | It is sort of kludgy. I also would prefer a real fix. | 22:15 |
| systemdlete | :) | 22:15 |
| systemdlete | (good to hear that, rwp. Good to hear that) | 22:15 |
| systemdlete | I can live with the long delays... there's always something to watch on youtube, even if it's really stupid or trite. It's not like I have to prepare for my Ted talk or something. | 22:16 |
| rwp | I have been trying to craft a sentence or two that would summarize the situation. Failing miserably. I can't do it concisely. It's has several subtle facets that need longer description. | 22:20 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!