=== chris14_ is now known as chris14
=== shokohsc61 is now known as shokohsc6
[08:59] <Lope> Eickmeyer, can you please elaborate? I've looked at Debian 12 Bookworm, it has LXD...?
[09:24] <Lope> Eickmeyer, you can see here, LXD was *NOT* removed from Debian. It's there in Debian 12 Bookworm, and also in sid (unstable), which suggests that it's not going anywhere.
[09:24] <Lope> https://packages.debian.org/search?keywords=lxd
=== shokohsc66 is now known as shokohsc6
=== shokohsc68 is now known as shokohsc6
[15:46] <ahasenack_> it (lxd) has recent history in debian: https://tracker.debian.org/pkg/lxd
[15:47] <ahasenack_> indeed I also had a recollection of it not being available in debian before, just lxc
[16:12] <Odd_Bloke> Yeah, I saw that recently: I'm excited that I might actually be able to use lxd again :p
=== tomreyn_ is now known as tomreyn
[17:25] <effendy[m]> lxd can also be a virtual machine manager? I didn't know that.
[17:25] <ahasenack_> yes, it can also launch vms, just append --vm to the launch command
[17:25] <ahasenack_> everything else works the same, it's quite amazing
[17:25] <ahasenack_> network, storage, all the usual lxd/lxc commands
[18:34] <arraybolt3> Apparently you can even install Windows 11 inside LXC.
[18:35] <arraybolt3> I like LXC, but the syntax is... I mean, I don't particularly like when every argument is positional and things are supposed to read like a sentence. I like switches followed by settings - it's much more readable IMO, and more importantly, much easier to remember.
[18:36] <arraybolt3> I can rattle off "qemu-system-x86_64 -cdrom ./OS.iso -boot dc -hda ./hd.qcow2 -enable-kvm -m 2G -smp 4" entirely from memory and have a VM booted in no time.
[18:36] <arraybolt3> I look at LXC commands and start feeling like "how will I ever remember this?"
[18:36] <arraybolt3> But I'm going off-topic.
=== shokohsc68 is now known as shokohsc6
[19:07] <Teridon> regarding https://bugs.launchpad.net/cloud-init/+bug/1999164/comments/6 -- if I use "refresh-installer" from the stable channel -- will that get the latest cloud-init ?
[19:07] -ubottu:#ubuntu-server- Launchpad bug 1999164 in cloud-init "when multiple SSH host key certificates are defined, only one HostCertificate is referenced in sshd_config" [High, Fix Released]
[19:08] <Teridon> also:  thank you for fixing this! :) 
[19:41] <effendy[m]> arraybolt3: Some things you just don't remember :)
[19:41] <effendy[m]> You'll have to do with those which you do remember.
[19:41] <effendy[m]> stupid as it may sound :D
[19:42] <effendy[m]> And it's obviously more important to understand how it works than remembering syntax.
[19:51] <effendy[m]> Now I'm just struggling to get the values (labels, instances etc.) from the query into the contact points go template.
[19:51] <effendy[m]> Sorry, wrong channel.
[22:35] <bryceh> teward, rbasak I worked on the nginx merge a bit last week, and stuck the result in a PPA (https://launchpad.net/~bryce/+archive/ubuntu/nginx-merge-v1.22.1-7)
[22:35] <teward> bryceh: not easy is it with the chaos that -6 and -7 introduces huh :p
[22:35] <bryceh> teward nope!
[22:36] <bryceh> teward, rbasak the merge itself was ok (mainly dropping delta) but the trick as you know is the modules
[22:36] <bryceh> it looks to me like they've successfully been broken out as separate source packages in debian, but those packages never sync'd in to ubuntu?
[22:36] <teward> bryceh: welcome to the world of Hell :P  I"m expecting a significant delta drop though
[22:36] <teward> bryceh: that'd be a thing we have to stab -release on
[22:37] <teward> it MIGHT be stuck in proposed as component mismatch
[22:37] <teward> but that's something we need to fuix
[22:37] <teward> otherwise we are left with 'nonfunctioning stuff'
[22:37] <bryceh> there's launchpad records for the source packages, just no evidence of any publications
[22:37] <bryceh> teward, most certainly; we wouldn't want to ship this nginx without all the modules since that'd be a huge regression for folks
[22:38] <bryceh> however given we're past FF I'm wondering if it's going to be time-effective to get these sorted out, vs. leaving for next cycle.  What do you think?
[22:38] <teward> bryceh: it might be conflicting on other components because of binaries already produced by src:nginx, not sure if that's what happened but i'll let you handle the chaos/fallout
[22:38] <teward> bryceh: if this were an LTS cycle I"d say devote infinite resources to get nginx working
[22:38] <teward> but if we just discard the current merge and don't do it for Lunar i'm OK with that
[22:38] <teward> rbasak even suggested skipping this for Lunar cycle and take care of it in M-cycle
[22:39] <bryceh> alright, yeah that's kind of the decision I'm feeling led to as well
[22:39] <teward> so yeah focus on M-series to resolve the new src package stuff
[22:39] <teward> until then i'mma go prod arraybolt3 with a sharpened straw becuase they're irritating me on other things :P
[22:39] <bryceh> I'll keep that PPA up, the nginx build itself seems fine, just the autopkgtests fail due to the missing modules
[22:40] <bryceh> kewl, thanks teward