[02:39] <vorlon> sarnold: ^^ looks like a mariadb-10.6 security update that never got copied forward to lunar (and now mantic)
[02:39] <vorlon> sarnold: and this is from back in February; do we need to do an audit of package version numbers?
[02:39] <vorlon> amurray: ^^
[02:48] <amurray> nishit_: ^^^ :) - did you forget to publish the mariadb-10.6 update for kinetic? last I see in LP: #2006882 is you mentioned it was building fine but then I don't see it ever got published
[02:48] -ubottu:#ubuntu-devel- Launchpad bug 2006882 in mariadb-10.6 (Ubuntu) "MDEV-29988 affects MariaDB in Ubuntu" [Undecided, Fix Released] https://launchpad.net/bugs/2006882
[02:56] <amurray> as nishit_ just pointed out to me, I didn't read the publishing history - this did get published - see 1:10.6.12-0ubuntu0.22.10.1 listed directly under the jammy packages on the publishing history page
[02:57] <amurray> but we didn't publish anything to lunar as it was in devel... since otto supplies these updates, I think we have a gap in our process where we need to also publish devel updates here, which I am not sure we have been doing in the past
[03:01] <amurray> this does make me wonder if we may have similar problems with other sponsored security updates like this - and hence I agree that it would be worth doing an audit of package version numbers
[10:09] <dviererbe> Hello I have a question regarding git-ubuntu
[10:09] <dviererbe> I wanted to merge the new debian version of gdb yesterday and I noticed that pkg/import/13.1-2 and pkg/import/13.1-2ubuntu2 has a delta in the source files (outside the debian folder).
[10:09] <dviererbe> As far as I know ubuntu delta should only be in the debian folder. The commit message says that the patches are unapplied.
[10:09] <dviererbe> Is this a Bug or am I missing something?
[10:09] <dviererbe> Steps to reproduce:
[10:09] <dviererbe> git ubuntu clone gdb
[10:09] <dviererbe> cd gdb
[10:09] <dviererbe> git diff pkg/import/13.1-2 pkg/import/13.1-2ubuntu2 | diffstat
[10:10] <rbasak> It looks like gdb 13.1 has different orig tarballs between Debian and Ubuntu. We try to avoid this to avoid confusion, but it is permitted.
[10:11] <dviererbe> Thanks! Did not know that this is a thing
[10:11] <rbasak> git-ubuntu has to support all the things without breaking :-P
[10:16] <dviererbe> What is the best strategy for splitting the orig tarball diff into logical commits? Should I just take all the ubuntu orig diff in one commit?
[10:22] <rbasak> It's maybe worth looking into whether the difference in orig tarballs is functionally there for a reason or just some build artifact difference that doesn't matter.
[10:23] <rbasak> If the latter, then you could make a single commit to cover all orig tarball diff as your first logical commit, then "drop" that when you rebase
[10:24] <rbasak> Oh, I think that's what you suggested :)
[14:23] <nteodosio> Isn't this phased updates outdated, in that it not only applies to update manager but also to apt istelf as of recently?
[14:23] <nteodosio> https://wiki.ubuntu.com/PhasedUpdates
[14:24] <nteodosio> s/updates/updates article/
[18:08] <bdmurray> amurray, vorlon: who will do the audit of package version numbers?
[18:33] <vorlon> bdmurray: ideally the security team, and on an ongoing basis?
[18:46] <smoser> i'm looking to add an autopackage test for lvm2 that would run in a vm (isolation-machine).
[18:48] <smoser> in the official autopkgtest.ubuntu.com a.) do i have any control over the kernel that the vm runs (specifically -kvm is not enough, it needs access to dm-thin-pool and b.) can i get another disk attached to the system
[18:52] <vorlon> smoser: the kernel that the vm runs> you can install a kernel of your choice, mangle grub.cfg to your heart's content, and reboot; IIRC there are some helper utilities for handling of reboots within autopkgtests though I don't recall the details offhand.  I don't understand the comment about access to dm-thin-pool, though?
[18:52] <vorlon> smoser: as for another disk, no, sorry
[18:52] <smoser> wrt grub.cfg, i had hoped you would give me somethign else. :-(.
[18:53] <smoser> any thoughts on how to get another block device ? the two that come to me:
[18:53] <smoser> a.) nested virt / do it myself
[18:53] <smoser> b.) looback block device ... but i'd rather not as its just not a common or realistic lvm usage path.
[18:55] <vorlon> smoser: we do not guarantee that nested virt will work; so I was going to suggest b)
[18:57] <smoser> open-iscsi uses nested virt. (but wthout acceleration due to it not workign well)
[19:01] <vorlon> ah if you're doing it without acceleration, sure (I translated "nested virt" in my head to "nested KVM")
[19:08] <smoser> right. so y eah... it woudl likely work, but not great.
[19:09] <smoser> thanks, vorlon