[00:58] <tsimonq2> The aforementioned package that I'd like for Lubuntu has been uploaded to Kinetic source NEW, please ping with any questions.
[06:17] <cpaelzer> RAOF: hi, I've seen your SRU review reject on bug 1934997
[06:17] <ubottu> Bug 1934997 in sssd (Ubuntu Focal) "Authentication fails after upgrading sssd to 2.2.3-3ubuntu0.6" [High, In Progress] https://launchpad.net/bugs/1934997
[06:17] <cpaelzer> RAOF: since the uploader is on PTO I've taken a look and I think this isn't as unrelated as you thought
[06:17] <cpaelzer> RAOF: if you still ahve time, could you have a look at my explanation in that bug (last comment) and let me know if we should re-upload it or if there is something else I missed?
[06:19] <RAOF> cpaelzer: That's a reasonable explanation!
[06:20] <cpaelzer> I could re-upload it or can it be revived from the reject queue?
[06:20] <RAOF> I can actually fish it out of the rejected queue, I think.
[06:20] <cpaelzer> oh nice
[06:20] <RAOF> No need to re-upload.
[06:20] <cpaelzer> great, if that doesn't work out and you need me to get this back on track please ping me
[06:26] <RAOF> So, technically, the removal of `signal.c` *is* an unrelated change, but that's ok :)
[11:53] <tjaalton> did quebot die?
[11:53] <tjaalton> *queuebot
[13:14] <tjaalton> sil2100: uploaded libdrm & mesa-amber for focal, llvm-13 and mesa backport will follow later
[13:14] <tjaalton> also mesa point-release update for jammy
[16:36] <vorlon> ginggs: when packages show on https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20220617-kinetic-kinetic.html as 'ftbfs, no regression', what is the baseline being used for deciding if it's a regression?  I ask because sphde is built in kinetic
[16:40] <ginggs> vorlon: the reference series is jammy (shown near the top of the report)
[16:59] <ginggs> it shows that way only on amd64, ppc64el and s390x because the other architectures are still building
[17:34] <vorlon> ginggs: "Reference series: jammy" thanks for the clarification
[17:35] <vorlon> ginggs: I'm still confused though because sphde binaries are in jammy.  Is it using a baseline of some previous rebuild archive?
[17:38] <ginggs> vorlon: i have no idea.  we see the same in the 2nd impish test rebuild https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20210927-impish-impish.html
[17:40] <ginggs> if 1.4.0-3 had migrated, sphde would appear in the 'superseded' section of the report
[18:02] <Eickmeyer[m]> rbasak: I have an upload to supersede for quassel's SRU (bug 1980687), I missed one line in the patch to change. Literally the network name. Explained in the comment.
[18:02] <ubottu> Bug 1980687 in quassel (Ubuntu Kinetic) "[SRU] Quassel should not have #debian as default channel in Ubuntu" [High, Fix Committed] https://launchpad.net/bugs/1980687
[18:21] <rbasak> Eickmeyer[m]: yep OK, but could you please build with -v1:0.14.0-1ubuntu0.22.04.1? Otherwise the changes don't make sense on their own.
[18:23] <Eickmeyer[m]> rbasak: My upload was 1:0.14.0-1ubuntu0.22.04.3 in this case.
[18:24] <rbasak> Eickmeyer[m]: right, but the SRU change being landed includes both .2 and .3, so it'd be nice for the changes file to state that. Otherwise only the changelog associated for .3 would be seen in various reports.
[18:24] <rbasak> Hence the request for -v
[18:25] <Eickmeyer[m]> I see. I'll rebuild and reupload, go ahead and reject .3.
[18:30] <Eickmeyer[m]> rbasak: Done.
[18:32] <rbasak> Eickmeyer[m]: accepted. Thanks!
[18:32] <Eickmeyer[m]> rbasak: Thanks for your help!