[07:07] Good morning [11:50] Is there a way to get multipass to see other multipass hosts via dns? I keep getting a lookup failure. I know there's libnss-libvirt, but that doesn't seem to affect multipass [11:53] kstenerud: other hosts or other guests? [11:53] other guests. So multipass launch a, launch b, b: ping a [11:54] kstenerud: using libvirt or the default multipass backend? [11:54] using default, but if possible I'd rather use libvirt since I've already redirected lxd to it [11:54] multipass's libvirt is a different one... [11:55] kstenerud: as andreas said, it is its own one [11:55] ok. Then whatever works. I don't absolutely need it to talk to other techs [11:55] kstenerud: with the default backend you ahve not much - I think they spawn a dnsmasq as well, setting that as DNS server maybe? [11:56] ask saviq in #multipass [11:56] he might know [12:38] rbasak: how does debian put tarballs in their git in salsa? pristine-tar? [12:42] ahasenack: it's entirely up to individual maintainers. Some may not at all, others use gbp (which uses pristine-tar), etc. [12:42] rbasak: trying to figure out how I would propose a version upgrade to a package in salsa. I should check their previous upgrades then [12:45] ahasenack: for "3.0 (quilt)" an MR for just the debian/ directory might be sufficient. Maintainers generally use uscan or other automated methods so it shouldn't be difficult for them to handle the upstream part. That's what I'd do, at least. Then you don't have to learn/screw up the maintainer's individual method. [12:45] I see [12:46] I would explain that it's debian/ only in the MR of course. [12:46] it would be a MR that doesn't built [12:46] it would mention a version in d/changelog that is not there, etc [12:46] True. [12:46] s/built/build/ [12:46] But the maintainer could pull in the new upstream, and then merge that MR, etc. [12:46] ok [12:46] I guess CI would fail if that's in use. [12:46] I can always ask [12:47] just wanted to get a feeling how it's usually done [12:47] Last time I asked this kind of thing in #debian-alioth (OFTC) nobody had a good answer. [12:47] That was on salsa issues vs. BTS. [12:47] I think it's too new for Debian to have any sense of "usually" yet. [12:50] rbasak: sorry about misunderstanding your MP comment yesterday in sssd [12:50] rbasak: you wrote it correctly, I just focused too much on the branch name I thought it was about that [12:50] No worries. I could have been clearer. [12:51] I don't think you could :) [12:51] Just wait until you see my next review :-P [12:51] hehe === Pici` is now known as Pici === kallesbar_ is now known as kallesbar === led_dark_2 is now known as led_dark_1 [18:53] hi. i understand that loading of processor microcode updates from within a virtual guest is ignored/rejected by the hypervisor - but is there a scenario where a guest might be able to load microcode in the context of its "view" of the processor? [18:54] or is that just a fundamentally invalid premise from the start? [18:58] i'm equally curious about the linux-firmware package, and all of its firmware files. are those applicable to a virtual guest? [18:59] I don't think you should need that package in a VM [19:00] that's the sense i had too. i was hoping to formulate the why not part so i could understand it well [19:57] Is it normal for the server to get updated packages and even kernel updates? I thought there were no package update [19:58] can you rephrase your question? [19:59] I thought the only updates that you will get on the server are security updates [20:01] that's up to you -- if you have the -updates pocket configured in your apt sources, you'll get non-security updates in addition to the security updates when you use apt-get upgrade / dist-upgrade / apt upgrade [20:01] unattended-upgrades I believe can also be configured to install from -updates, but should do -security as the default [20:26] Deihmos: kernel updates almost invariably include security updates. [20:27] it does not seem like Deihmos is still close to their web browser.