=== wgrant_ is now known as wgrant
[02:43] <mwhudson> huh libgit2 1.0.0
=== guiverc2 is now known as guiverc
[10:57] <rbalint> xnox, thanks this is TIL :-)
[11:12] <juliank> chrisccoulson: do you want to submit the grub patch for bug 1878541 upstream? I think we can discuss it there?
[11:12] <ubottu> bug 1878541 in grub2 (Ubuntu Groovy) "Grub fails to load kernel from squashfs if mem < 1500mb" [High,Confirmed] https://launchpad.net/bugs/1878541
[11:12] <juliank> grub-devel@gnu.org
[11:12] <juliank> chrisccoulson: certainly sounds like the correct approach to me
[11:12]  * juliank can push it upstream too
[11:33] <irreleph4nt> Hi. Quick question: Does Ubuntu support dbus-broker as a replacement for dbus-daemon? Google yields no useful results for that query. Thank you.
[11:35] <xnox> irreleph4nt:  at the moment, dbus-broker is still experimental and lacks feature parity. For example, whilst basic functionality is available. LSM mitigation are not. Thus using dbus-broker is less secure, than regular dbus.
[11:36] <xnox> and we do use dbus apparmor mitigations by default, to secure leaking information over dbus from host to confined snaps. And vice versa.
[11:36] <irreleph4nt> xnox, thank you. So it sounds like using broker instead of daemon currently is anything between discouraged and impossible. Noted. :)
[11:37] <xnox> irreleph4nt:  but otherwise one can experiment/install dbus-broker if one wants to. But you will get to keep both pieces or like help to improve integrating it.
[11:37] <xnox> irreleph4nt:  i wish it was easier to use, but it currently is not.
=== irreleph4nt is now known as Guest7554
[11:41] <irreleph4nt> xnox, what you've said gives off the impression though that work is being done to get broker into Ubuntu. Is that right? I found a github issue against dbus which mentions AppArmor. It was raised in 2018 and is open to this day
[11:46] <xnox> irreleph4nt: no, i didn't say anything remotely to that effect.
[11:46] <xnox> irreleph4nt:  i'm not aware of anybody currently working on LSM mitigations in broker.
[11:47] <xnox> check with upstream if that has changed. But that's what the status of this was since the inception of the project.
[11:47] <irreleph4nt> Okay, noted. Thanks again :)
=== helio|afk is now known as heliocastro
[13:16] <rbasak> ahasenack: o/ I pinged you in https://github.com/certbot/certbot/issues/7954 but not sure if that means you see it.
[13:16] <ahasenack> just replied
[13:16] <rbasak> Oh
[13:16] <rbasak> Thanks :)
[13:16] <ahasenack> I saw it
[13:36] <seb128> wgrant, hey, any chance you could investigate what's wrong with pulseaudio on riscv? dunno what changed but a test is failing in focal and groovy now, which is annoying because it means the recent SRU with important fixes is getting blocked now :/
[13:37] <seb128> though the security update got published with the arch failure it seems
[13:41] <jalt> Hi, where can I find documentation for subiquity (or ubiquity) unattended installations of 20.04 (#ubuntu-installer points to here)?
[14:03] <coreycb> cpaelzer: hi, do you think we could get python3-ironicclient into main as of focal? it's py2 counterpart used to be in main.
[14:04] <coreycb> bug 1376238
[14:04] <ubottu> bug 1376238 in python-ironicclient (Ubuntu) "[MIR] python-ironicclient" [High,Fix released] https://launchpad.net/bugs/1376238
[14:07] <jdstrand> riscv64 is considered a 'bonus' architecture for security updates. note, 1:13.99.1-1ubuntu3.1 also ftbfs on riscv64. the security updates was built on top of 1:13.99.1-1ubuntu3 which did build
[14:08] <jdstrand> I don't know if it was a toolchain chain. ubuntu3 built, ubuntu3.1 didn't (had part of the sru patch but not security), ubuntu3.2 ftbfs (had the security patch but not the sru patch)
[14:08] <jdstrand> toolchain change*
[14:09] <jdstrand> ubuntu3.3 and ubuntu5 have both the sru and the security patch
[14:28] <jdstrand> fyi seb128 ^
[14:28] <jdstrand> (and wgrant ^)
[14:29] <jdstrand> ('bonus' for focal at this point; presumably some day it will be offical)
[14:43] <seb128> jdstrand, thanks