[03:02] <arraybolt3> LocutusOfBorg: So I see there's a new thing out there tha finally lets VBox and KVM VMs run at the same time: https://cyberus-technology.de/articles/vbox-kvm-public-release Basically just using KVM as the underlying hypervisor for VBox rather than using VBox's built-in one. I'm sorely tempted to package this myself and use it since I have a use case for it right now, but I know you're the
[03:02] <arraybolt3> defacto all-things-VirtualBox person (and VBox maintainer), so I thought maybe I should mention it to you first to see if you wanted to package it, or if you had pointers for if I was to package it.
[03:04] <sarnold> that might be easier than my suggestion "buy two computers" :)
[03:04] <arraybolt3> hah
[03:04] <arraybolt3> I actually have two computers on this desk
[03:05] <arraybolt3> but until I can somehow make them boot off the same drive and simultaneously access the same files at the same time WITHOUT making a total wreak of the filesystem, that's a bit impractical for me.
[06:48] <vorlon> sarnold: you are Theo de Raadt and I claim my five pounds
[07:22] <LocutusOfBorg> arraybolt3, feel free to package it and put under pkg-virtualbox hat if you want! I'm amazed to try it!
[07:23] <LocutusOfBorg> so this is a forked-virtualbox?
[07:23] <LocutusOfBorg> why can't have something like "choose your backend at startup" and upstream their work?
[07:28] <LocutusOfBorg> let me ask upstream
[07:35] <tjaalton> what broke my noble schroot.. "unknown system group 'postdrop' in statoverride file; the system group got removed"
[07:37] <LocutusOfBorg> https://pastebin.ubuntu.com/p/pF3PGSgJvD/
[07:38] <LocutusOfBorg> 2024-02-16 08:09:22 CET 	Pending 	Noble 	release 	main 	admin 	4.0.0~alpha4-0ubuntu1
[07:38] <LocutusOfBorg>     Created 28 minutes ago by Ubuntu Archive Auto-Sync
[07:38] <LocutusOfBorg> tjaalton, ^^ maybe?
[07:38] <LocutusOfBorg> apparmor?
[07:38] <tjaalton> hmm
[07:39] <vorlon> that shouldn't cause groups to disappear from /etc/groups?
[07:40] <vorlon> fwiw postdrop is only created by the postfix package (both the statoverrides and the /etc/group entry)
[07:40] <vorlon> do you have a schroot setup that syncs /etc/group from the host, and you persistently installed postfix in your schroot, and on initializing a new session the re-sync of /etc/group clobbered the addition of postdrop group within the schroot?
[07:41] <tjaalton> probably
[07:42] <tjaalton> yeah group is in all the /etc/schroot/*/nssdatabases
[07:43] <tjaalton> dunno why postfix is in the chroot
[07:44] <tjaalton> it got installed on the latest update for some reason
[07:46] <tjaalton> gpg-wks-server
[07:46] <tjaalton> pulled it in
[07:48] <vorlon> juliank: ^^ :P
[07:48] <juliank> Hmm
[07:48] <juliank> Did you install gpg 2.4 from proposed?
[07:49] <tjaalton> I think proposed is enabled by default, yes
[07:49] <juliank> Hmm
[07:50] <juliank> Well that means Digging into depends I guess
[07:50] <juliank> Hooray
[07:58] <cpaelzer> @pilot in
[07:58] <cpaelzer> I've got a few community requests from Debian folks that want to help noble to be good in regard to things they maintain
[07:59] <cpaelzer> Among too many things that distract me I'll try to at least resolve those community requests
[07:59] <cpaelzer> but I wanted to make myself known for the rare, but important "available for pings" here
[08:49] <sudip> ginggs: you were right, opening the bug report did the trick :)
[09:04] <juliank> Ah yes gnupg2.4 adds default-mta | mail-transport-agent as a Depends to it
[09:05] <juliank> that is clearly unacceptable, but why do we install a web key server in the first place
[09:05] <juliank> Because we seed the full suite of gnupg rather than just gpg
[09:07] <juliank> We should probably seed gpg, dirmngr (where private keys are needed) and keyboxd instead, and gpg-agent on server
[09:08] <juliank> (desktop already has GNOME's gpg agent, doesn't need the gpg-agent)
[09:23] <juliank> tjaalton: The depends are a mess in gnupg, libvolume-key1 Depends gnupg which seems ridiculous, why would it need all gnupg tools and the web key server and all, probably should Depends gpg
[09:23] <juliank> But also gpgconf Recommends gnupg and should Recommends gpg instead
[09:23] <juliank> And then also gotta trim down the seeds from gnupg to gpg
[09:23] <juliank> And then the wks server should become autoremovable
[09:24] <juliank> But lots more reverse dependencies sadly
[09:25] <juliank> Back in the day, gpg was not split out
[09:26] <juliank> So I think I'm inclined to do the seeds changes and the libvolume-key one, but also demote gpg-wks-server to Suggests in gnupg and deal with cleaning up gnupg reverse dependencies next cycle
[09:31] <juliank> Or I edit 40 packages now
[09:31] <juliank> maybe 80
[09:32] <tjaalton> yeah I just removed gnupg from the chroot as a quick fix :)
[09:50] <cpaelzer> xypron: do you happen to know any troubles with bpftool in noble on riscv64?
[09:51] <cpaelzer> xypron: background is that on xdp-tools we exchange a debian dependency bpftool with linux-tools-generic
[09:51] <cpaelzer> xnox: that used to work in the past e.g. https://launchpadlibrarian.net/652981344/buildlog_ubuntu-lunar-riscv64.xdp-tools_1.3.0-2ubuntu2_BUILDING.txt.gz https://launchpadlibrarian.net/652975016/buildlog_ubuntu-lunar-amd64.xdp-tools_1.3.0-2ubuntu2_BUILDING.txt.gz
[09:51] <cpaelzer> xnox: both found it - configure shows like "using /usr/lib/linux-tools/5.19.0-1006-generic/bpftool v7.0.0"
[09:52] <cpaelzer> but in a new build of a recent version that works on all but risc where I got "bpftool not found or doesn't support skeleton generation; not building all tools"
[09:54] <cpaelzer> xypron: and if you do not know but probably have a risc test env around, configure does this "$BPFTOOL gen help 2>&1 | grep 'gen skeleton.*name'" - maybe you could tell me how this looks atm in noble?
[09:56] <cpaelzer> qucik grocery run and lost in debugging, out'ing but still being here later
[09:56] <cpaelzer> @pilot out
[10:08] <juliank> tjaalton: should be fixed with https://git.launchpad.net/~juliank/ubuntu/+source/gnupg2/commit/?h=ubuntu/devel&id=e03dfd60321dade291a05960403e3f4456f7d359
[10:08] -ubottu:#ubuntu-devel- Commit e03dfd6 in ~juliank/ubuntu/+source/gnupg2 "gnupg: Demote gpg-wks-server to Suggests"
[10:08] <juliank> I went for the meta package demotion route fwiw
[10:08] <juliank> there's more changes in the branch: https://git.launchpad.net/~juliank/ubuntu/+source/gnupg2/log/?h=ubuntu%2Fdevel
[10:12] <tjaalton> okay, cool
[10:25] <juliank> Fixed in https://launchpad.net/ubuntu/+source/gnupg2/2.4.4-2ubuntu3
[10:29] <juliank> rbasak: Does it seem sensible to demote the gnupg seed to gpg in server, do we want a fully usable gnupg suite seeded by default with like X.509 cert support, S/MIME and everything, or just the standard gpg to manipulate keys (and maybe dirmngr to receive keys)
[10:30] <juliank> The worst offender in gnupg was a server for wks which I just demoted to Suggests so it won't be installed by default, but I'm still questioning the usefulness of seeding the metapackage
[10:30] <juliank> But we can change the seeds in 24.10 :)
[10:32] <juliank> Well yes, server already seeds dirmngr explicitly
[10:32] <juliank> while also seeding the gnupg metapackage that pulls it in via Depends anyhow
[10:42] <xypron> cpaelzer: I have never worked with bpftool. If you have a test case I can run it on RISC-V systems.
[10:43] <cpaelzer> xypron: hi, I've shown above what it runs in the configure
[10:43] <cpaelzer> xypron: knowing what that does would already be helpful - and if it is available with linux-tools-generic installed
[10:53] <rbasak> juliank: I think it's probably OK to swap to gpg in the server seed. But I'm not sure. Would --recv-key still work?
[10:53] <juliank> rbasak: Yes because it also seeds dirmngr
[10:53] <rbasak> juliank: maybe email the ubuntu-server@ ML?
[10:53] <juliank> I'm also thinking I should make gpg Recommends: dirmngr directly because that seems very closely related
[10:54] <rbasak> I can't think of a use case that I'm bothered about breaking.
[10:54] <juliank> Stuff like gpgsplit from gpg-utils would disappear by default too
[10:54] <rbasak> But it's probably wise to ask more widely to see if others can think of any
[10:55] <juliank> Yeah for now I just changed gnupg and demoted the wks server to suggests and l10n to recommend
[10:56] <juliank> I'm talking to Debian maintainers and gathering opinions and should have proposals for seed changes in 24.10
[11:06] <xypron> cpaelzer: bpftool gen help 2>&1 | grep 'gen skeleton.*name': bpftool gen skeleton FILE [name OBJECT_NAME]
[11:08] <cpaelzer> xypron: odd, that looks like it should work
[11:08] <cpaelzer> xypron: that is noble right?
[11:08] <xypron> 24.04
[11:08] <cpaelzer> xypron: hmm, thanks. I'm not much smarter now but really I appreciated it
[11:08] <cpaelzer> xypron: maybe I should just give back and re-run the build before spending hours to debug this one ...
[11:09] <xypron> cpaelzer: do you have a file for which we can really create a skeleton?
[11:09] <cpaelzer> xypron: no, this is just what configure does to check if it is there
[11:09] <cpaelzer> xypron: and the build already fails there
[11:10] <xypron> cpaelzer: these are my versions: kernel 6.5.0-9-generic: bpftool v7.3.0, using libbpf v1.3, features:
[11:10] <cpaelzer> xypron: oh, build would be noble-proposed
[11:10] <cpaelzer> xypron: can you see if it is the same there?
[11:12] <cpaelzer> xypron: but 6.5.0-9 is what my failing build log had as well
[11:15] <cpaelzer> I've restarted the build on infra and at the same time set up my local rsicv64 emulation system, but generating initramfs takes ages there ...
[11:17] <cpaelzer> xypron: the dependency seems insufficient
[11:17] <cpaelzer> xypron: I installed linux-tools-generic but it does not bring in bpftool
[11:18] <cpaelzer> xypron: I still get the usual diversion of the kernel helpers like perf with the "not found for kernel ... You may need to install the following packages for this specific kernel"
[11:23] <cpaelzer> xypron: oh that might be because on the builder it does not have the one for the kernel
[11:23] <cpaelzer> xypron: all those are redirected via uname -r
[11:24] <xypron> cpaelzer: linux-tools-generic is needed
[11:25] <LocutusOfBorg> arraybolt3, LocutusOfBorg: I reached out already to Cyberus expressing our interest in integration. they said they'll need a bit of time to prepare the official contribution (as aeichner said, we can only accept it under UPL or MIT license or with an Oracle Contributor Agreement). The integration will not happen into 7.0.x (they published a changed 7.0.14) but into trunk which will become 7.1 eventually.
[11:25] <LocutusOfBorg> this happened in #vbox-dev
[11:25] <cpaelzer> xypron: this is from the actual build on the infrastructure "Kernel version: Linux bos03-riscv64-017 5.19.0-1021-generic #23~22.04.1-Ubuntu SMP Thu Jun 22 12:49:35 UTC 2023 riscv64"
[11:25] <cpaelzer> xypron: so to ever work it would need /usr/lib/linux-tools/$(uname -r)/bpftool
[11:26] <cpaelzer> xypron: and in noble it will never find /usr/lib/linux-tools/5.19.0-1021-generic/...
[11:27] <cpaelzer> I think I need to bring back a change we had, that was working well without everywhere ...
[11:27] <cpaelzer> give me a minute ..
[11:27] <xypron> cpaelzer: the kernels used in Launchpad are not from any distro archive.
[11:27] <cpaelzer> xypron: yeah I know, that is why I said "it will never find"
[11:29] <xypron> cpaelzer: Is this different on other architectures?
[11:30] <cpaelzer> xypron: yeah - on allother arches it would find the ...(uname -r)... and hence it works
[11:30] <cpaelzer> xypron: I have the code that should fix it, it is already in d/rules
[11:30] <cpaelzer> xypron: now it is no more a riddle but work
[11:31] <cpaelzer> Debian took our delta with slight modifications and it seems to not work anymore, that is what I need to fix for this
[11:31] <LocutusOfBorg> dbungert, sorry i just read it
[11:31] <LocutusOfBorg> I also failed to understand and craft the patch, it took me a while to get why the variable was empty for armhf, and had to setup and open a chroot to check
[11:33] <LocutusOfBorg> arraybolt3, can you please explain me why this is a real case scenario you need to solve?
[15:41] <arraybolt3> LocutusOfBorg: I have a long-running VM that uses libvirt+QEMU+KVM to provide an application that can be accessed via SSH + X forwarding. This application is used by a family member over the network so they can run this somewhat resource-intensive application even though their hardware is too weak to support it. At the same time however, I sometimes need to use VirtualBox for testing Ubuntu
[15:41] <arraybolt3> flavors in a multi-monitor scenario (among other use cases), and currently I have to ensure the network-shared application is closed so I can shut down the libvirt VM and be able to run a VBox one.
[15:41] <LocutusOfBorg> why not use vbox for both?
[15:42] <arraybolt3> because in my experience, VBox is generally more unstable than KVM and so I don't use it for anything but testing purposes most of the time.
[15:42] <arraybolt3> I run my Ubuntu packaging environment under a KVM virtual machine for the same reason, which makes things difficult when testing in a VBox VM.
[15:43] <arraybolt3> since then I have to power down one VM to power up the other
[15:43] <arraybolt3> If KVM integrated just a bit better with the host system, I could and would use it solely (and it would need working multi-monitor support too, I have yet to figure out how to do that), but currently KVM is better for intensive use and VBox is better as far as UX and has some features I use.
[15:43] <arraybolt3> So I'm stuck running both.
[15:45] <LocutusOfBorg> anyway for vbox 7.1 it should become upstream
[15:45] <LocutusOfBorg> this is what they said and they are working on
[15:46] <LocutusOfBorg> #vbox-dev on OFTC
[15:46] <arraybolt3> oh wow
[15:47] <arraybolt3> then I'll just wait, that's awesome news
[15:47] <arraybolt3> or maybe I'll fiddle with it to see if there's any packaging "gotchas"
[20:21] <sarnold> vorlon: lol <3