[00:06] <mwhudson> ok unmkinitramfs is terrifying
[00:20] <Odd_Bloke> alias unmkinitramfs=sudo rm -f /boot/initrd*
[00:30] <xnox> mwhudson:  lets do a binwalk, then lets skip things, and do stuff.
[00:31] <mwhudson> xnox: i love parsing binary formats in shell
[00:31] <xnox> mwhudson:  note to self, when grub loads multiple initrds it inserts padding between them for alignment. also note that intel-ucode tries to insert weird cpio members too for alignment. note that we add amd64-ucode too. i'm pretty sure is that end result is _not_ aligned.
[00:32] <mwhudson> xnox: i have this side project to make customizing installer isos easier, one of the things i want to do is update .disk/info/casper-uuid-generic if you replace the initrd
[00:32] <mwhudson> but right now i just want a beer
[00:40] <xnox> mwhudson:  i'm not sure if there is a better way. in bios days one didn't know where one booted from; but in UEFI days we do.
[00:40] <xnox> mwhudson:  sdboot does store in efi variable the drive one booted from, hence one should look up squashfs from the same place.
[00:41] <xnox> mwhudson:  i wonder if we can make casper leverage that.
[00:42] <mwhudson> hm that would be nice
[00:50] <xnox> mwhudson:  i.e. not sure if we can inspect "BootCurrent" standard efi variable to figure out where abouts shim got loaded from this time around.
[00:50] <xnox> and decide that that's the badger
[00:52] <mwhudson> xnox: i suspect a distressing number of server installs are still bios too
[00:52] <mwhudson> although maybe that's changing finally
[00:54] <xnox> mwhudson:  new servers not only don't have bios, they crutially do not have bios or efi ipxe, meaning efi-httpboot as the only option
[00:55] <xnox> plus bmc which is the weird "virtual cdrom" option.
[00:55] <mwhudson> nice
[11:06] <DarkTrick> Does this mean, my actively used for debian unstable? https://imgur.com/a/SSK4YJi
[11:08] <JackFrost> ...No, it means you set the homepage URL to that.
[11:09] <DarkTrick> JackFrost, thank you. ... I wonder when I did that :D
[12:36] <TJ-> possible problem with the hirsute aarch64 ISO images; the GPT/EFI-SP is failing to be recognised from a Samsung Galaxy Book2 (Qualcomm Snapdragon 850) - manually writing a GPT + EFI-SP and copying grubaa64.efi to /EFI/BOOT/BOOTAA64.EFI works fine
[12:55] <JackFrost> ddstreet: Any idea why ubuntu-dev-tools prints keyring modules it can't load when firing up a lot of the commands?  It's rather annoying.
[12:56] <JackFrost> Eg, `syncpackage $anything` will print out a lot of 'Loading $foo' starting with kwallet and going down a line of a bunch of them.  Granted, redirecting stderr from all programs un ubuntu-dev-tools would "fix" the problem, but this is far from ideal.
[13:21] <rbasak> cjwatson: o/ just checking you still have my changes file proposal in your queue please?
[13:24] <cjwatson> rbasak: I do, sorry
[13:24] <cjwatson> It has been a Week
[13:28] <rbasak> np, thanks
[13:29] <rbasak> I don't have a particular deadline; I just wanted to make sure it wasn't lost.
[14:35] <Odd_Bloke> rbasak: We maintain cloud-init's packaging in our upstream repo; we don't want to change that, but I was wondering (idly, mostly) if there's a good way of us getting that history into git-ubuntu somehow?
[15:00] <ddstreet> JackFrost i don't see the prints you're talking about
[15:20] <rbasak> Odd_Bloke: there is a method that will work, but I'm not sure if it's a good idea. So I don't suggest doing it immediately, but we can ponder it. If you were to merge git-ubuntu's history into your packaging branch in your upstream repo, then git-ubuntu would be able to adopt subsequent commits that you make into its own history. But that might make a complete mess of the git history in a not-useful
[15:20] <rbasak> way, which is why I'm not sure it's a good idea.
[15:21] <rbasak> Apart from that, I'm not sure of what an integration might look like. Ideas welcome!
[16:38] <Laibsch> Can I interest someone in sponsoring bug 1916250?  I used Conflicts/Replaces even if only Replaces by itself might be enough.
[16:56] <rbasak> Laibsch: sure, although Conflicts is a little too strong perhaps, and are best avoided to give apt the most leeway to resolve things.
[16:56] <rbasak> Laibsch: can you pick from https://wiki.debian.org/PackageTransition please?
[16:58] <rbasak> Unversioned is also unusual; I'd expect versioned relationships in this case I think.
[17:22] <Laibsch> rbasak: Thank you for your comment.  Frankly, I lack some history of the package.  Looking through the changelog, it seems as if this package was neglected for a long time and recently a new Debian maintainer stepped in with frequent updates.
[17:23] <Laibsch> There's been an API change from upstream apparently.  Versions were also bumped from 1.x to 2.x upstream.
[17:24] <Laibsch> Versions 1 and 2 don't coexist in the same Debian pocket FWIW.
[17:24] <rbasak> Laibsch: sorry, I don't know anything about the package either. I appreciate your efforts in fixing bugs!
[17:25] <rbasak> But to fix it we need to understand what is necessary unfortunately
[17:37] <Laibsch> digging deeper, I find that hirsute provides both gir1.2-signon packages (which is most likely not desirable)
[17:39] <Laibsch> rbasak: Will it drop automatically from the archive, given that the source is now missing?
[17:39] <Laibsch> for hirsute
[17:40] <Laibsch> https://packages.ubuntu.com/hirsute/gir1.2-signon-2.0 and https://packages.ubuntu.com/hirsute/gir1.2-signon-1.0
[18:06] <rbasak> Laibsch: yes - it's in the NBS report, so the old source will be deleted when the archive admins clean up - usually only once per cycle I think.
[18:06] <rbasak> https://people.canonical.com/~ubuntu-archive/NBS/libsignon-glib1
[18:07] <rbasak> But I think that shouldn't make a difference to what's needed for the binary packages?
[18:07] <cjwatson> NBS clean up is quite a bit more than once a cycle
[18:07] <rbasak> Ah, OK
[18:07]  * cjwatson does that one now
[18:08] <cjwatson> Well, NBS doesn't involve removing *source*
[18:08] <cjwatson> but rather binaries
[18:10] <rbasak> Yes, sorry.
[18:10] <rbasak> Looks like they're both from the same source.
[18:40] <Laibsch> rbasak: After some looking into it, I believe that indeed the Conflicts line is too strict and not necessary.  https://bugs.launchpad.net/ubuntu/+source/libsignon-glib/+bug/1916250/comments/3
[18:44] <Laibsch> Concerning the link to the wiki page, I don't it is either of the options listed there with #5 being closest but I think that adding an empty transitional package would be overkill here.
[18:44] <Laibsch> I don't think it is either of the options ...
[23:15] <JawnSmith> Is any core dev available to restart the autopkgtest for iputils that was blocked by systemd? The new version of systemd should resolve the issue
[23:40] <JackFrost> ddstreet: Hmm, have kwallet installed?