[00:34] <arraybolt3[m]> ginggs: Scratch all of that, I can't read it turns out. The Debian version was 0.11.0-2, not 0.12.0-2. 🤦
[06:40] <cpaelzer> lvoytek: FYI the small fixes for libvirt in lunar got entangled by the migration of the new wireshark
[06:41] <cpaelzer> lvoytek: soeone already did a reference test on arm64 which confirmed that it was regressed elswhere, but on armhf it worked
[06:44] <cpaelzer> lvoytek: I've restarted it once just wireshark (no other new PKGs which formerly were bundled in the test) and a migration-reference run (as the last one is 2.5 weeks old)
[06:45] <cpaelzer> lvoytek: remind me that we recheck the results later so that indirectly our libvirt can be unblocked
[07:24] <cpaelzer> utkarsh2102: hiho, you asked for the verification of bug 1982703
[07:24] -ubottu:#ubuntu-devel- Bug 1982703 in ruby3.0 (Ubuntu Jammy) "Segfaults in ruby 3.0.2" [High, Fix Committed] https://launchpad.net/bugs/1982703
[07:24] <utkarsh2102> \o, yes
[07:24] <cpaelzer> utkarsh2102: the steps are not perfect (but I can fix them) and then it works to reproduce the issue
[07:24] <cpaelzer> utkarsh2102: but the reason it doesn't fix it is because the fix FTBFS
[07:25] <cpaelzer> I wondered why enabling proposed didn't give me 3.0.2-7ubuntu2.2 and the answer is here https://launchpad.net/ubuntu/+source/ruby3.0/3.0.2-7ubuntu2.2
[07:25] <cpaelzer> utkarsh2102: you might have way much more context on this than I do
[07:25] <cpaelzer> utkarsh2102: I thought you asked for a second person to test the verification - or are you asking about that FTBFS?
[07:25] <utkarsh2102> oh no!
[07:26] <utkarsh2102> the test verification only!
[07:26] <utkarsh2102> re-triggered the builds, it should be build now, apologies
[07:26] <utkarsh2102> however, can you test the PPA where I landed the fix in?
[07:27] <utkarsh2102> cf: ppa:utkarsh/temporary-stuff
[07:27] <utkarsh2102> it built on amd64 (ignore the arm FTBFS)
[07:28] <cpaelzer> utkarsh2102: fixed a few broken test steps now
[07:28] <cpaelzer> utkarsh2102: trying from your PPA ...
[07:28] <utkarsh2102> looking
[07:30] <cpaelzer> utkarsh2102: -1 karma for a "temporary stuff" PPA :-P
[07:30] <utkarsh2102> heh, fair :)
[07:31] <cpaelzer> utkarsh2102: for me the PPA works
[07:31] <cpaelzer> utkarsh2102: the former "Invalid read of size 8" are gone
[07:32] <cpaelzer> utkarsh2102: there is a similar set of "Use of uninitialised value of size 8" but that has been there before
[07:33] <utkarsh2102> danke schön
[07:33] <utkarsh2102> yes, I got mixed up b/w the two, thanks!
[07:34] <cpaelzer> ok, glad I could help
[07:51] <cpaelzer> lvoytek: the termshark really did regress independent to wireshark - that should be unblocked on the next run of proposed migration
[08:35] <sandy> HI How to build a custom ubuntu-base rootfs? https://wiki.ubuntu.com/Base
[08:36] <sandy> Is there any scripts ?
[08:59] <mwhudson> it's mostly just "debootstrap" i think
[09:26] <sandy> @mwhudson think you, I'll try and diff.
[12:12] <arraybolt3> Being intentionally vague, those who know what I'm talking about will know. When dealing with a security-related bug that I have knowledge about, is it acceptable for me to patch the vuln and have that uploaded into Ubuntu "early", since the details are already semi-public upstream? Or do we need to wait for upstream to accept it and then we can patch it?
[12:13] <arraybolt3> Also is there any recommended procedure here for non-Security Team members who want to help patch it? Do I just treat it like any other bug and add patches to the bug report in Launchpad?
[13:21] <rbasak> Is there a quick say to see if autopkgtests for a particular package and arch are already queued?
[13:22] <rbasak> I'm aware that https://autopkgtest.ubuntu.com/running shows the queue, but its size makes it impractical to identify which arch a queue entry is for right now :-/
[13:23] <rbasak> arraybolt3: I'm not aware of any requirement for Ubuntu to "wait" to fix any seurity issue except in the case where the information has been provided to us under an embargo and it isn't otherwise public.
[13:23] <rbasak> But best to ask in #ubuntu-security.
[13:23] <rbasak> arraybolt3: for security sponsorship there's a separate process and queue: https://wiki.ubuntu.com/SecurityTeam/SponsorsQueue
[13:27] <arraybolt3> rbasak: Thanks!
[15:54] <ahasenack> rbasak: lp-test-isrunning from the ubuntu-helpers git repo
[15:54] <ahasenack> run it like lp-test-isrunning | grep package
[15:54] <rbasak> Ah, perfect. I did dig around in ubuntu-helpers but didn't find that
[15:54] <ahasenack> further filtering will become clear once you see its output
[15:54] <ahasenack> like the first letter of each line being R or Q
[15:54] <rbasak> It's not mentioned in README.md :-(
[15:58] <rbasak> Now fixed. Thanks!
[16:02] <ahasenack> rbasak: standup?
[16:19] <sergiodj> vorlon: bdmurray: hi there, in case you've missed it I filed https://code.launchpad.net/~sergiodj/ubuntu/+source/dpkg/+git/dpkg/+merge/433545 last week as a followup from our discussions regarding debuginfod & source code indexing.  would appreciate your review when possible.  thanks
[19:01] <utkarsh2102> !dmb-ping
[19:01] <utkarsh2102> !dmb ping-all?
[19:01] <utkarsh2102> I have no idea what's the right way
[19:01] <utkarsh2102> !dmb ping
[19:01] <utkarsh2102> man :P
[19:02] <utkarsh2102> I'll just do it myself. rbasak, teward, seb128, sil2100, bdmurray, kanashiro - meeting time
[19:04] <rbasak> What's wrong with what the bot just did?
[19:04] <utkarsh2102> it workeddddddddddddd!
[19:36] <teward[m]> rbasak delayed as heck by 2 minutes :P
[20:42] <vorlon> sergiodj: yes, I saw that MP come in; I was out all last week for Thanksgiving, I probably won't get to reviewing this until next week
[20:43] <sergiodj> vorlon: ACK, thanks for the heads up.  I'll ping again next week if I don't hear back from you, thanks
[21:13] <teward[m]> krytarik check your DMs from my matrix account when you get a minute (my IRCCloud account went fubar so i'm slowly moving over to my Matrix for my primary IRC)
[21:14] <krytarik> I did and replied.. >_>
[23:37] <bluesabre> > Unit193> ...The never ending drums In the xubuntu seed/meta, why is (wireplumber) needed twice in order to actually pick up?  I had to do https://dpaste.com/7SG34HBNX in order for ./update to actually add it to the recommends (sans the pipewire dep → rec change.)
[23:37] <bluesabre> Expanding on what Unit193 mentioned earlier, I've created a bug report on LP for germinate/xubuntu-meta: https://bugs.launchpad.net/ubuntu/+source/xubuntu-meta/+bug/1998149
[23:37] <Unit193> Hellos yes this is fish.
[23:37] -ubottu:#ubuntu-devel- Launchpad bug 1998149 in xubuntu-meta (Ubuntu) "Recommended package ignored on Xubuntu core seed" [Undecided, New]
[23:38] <bluesabre> lol
[23:38] <bluesabre> Anybody here able to help? Xubuntu doesn't want to be left out of the pipewire fun!
[23:39] <Unit193> Well, given the issue I ran into, sure we don't? ;)