[03:16] <quarteradder> I'm confused about the SRU process. When creating a bug report on launchpad, does the bug submitter need to set the Ubuntu versions (e.g. focal, jammy, etc.) or is that supposed to be handled by the sponsor?
[03:29] <Eickmeyer[m]> quarteradder: Not part of the SRU team, but I've submitted enough SRUs to be familiar with the process. That needs to get set by the submitter. The latest development version (in this case, kinetic) must always, with few exception, be included and the fix must be there first before it is considered in prior versions. Then it needs to be set at the prior versions the fix should be applied toward.
[03:45] <quarteradder> Eickmeyer[m] Thanks! So if the bug was already fixed in kinetic, what would be the next step? For example, in this bug, is the next step to subscribe "ubuntu-sponsors" to it? https://bugs.launchpad.net/compiz/+bug/1986681
[03:47] <Eickmeyer[m]> quarteradder: Then you need to add Kinetic and mark it as "Fix Released" since it's fixed there.
[03:48] <Eickmeyer[m]> And no, you need to have a debdiff attached to the bug report first before you subscribe sponsors to it, but honestly, subscribing the sponsors team to the bug is likely to go nowhere. Asking for a sponsor is more likely to get it attention.
[03:49] <Eickmeyer[m]> However, subscribing the sponsors team to it would probably be a good idea anyhow since it's procedural in nature.
[03:50] <quarteradder> Ok thanks. This is also a stupid question, but how do I add Kinetic to it? I'm new to launchpad and can't seem to find the steps to do so.
[03:51] <quarteradder> The bug was fixed by a dev (with some help from me), so I assume they would probably sponsor it?
[03:51] <Eickmeyer[m]> Yeah, that would've been mitya57 . Great guy.
[03:52] <Eickmeyer[m]> Launchpad is being a bit stubborn for me at the moment.
[03:53] <Eickmeyer[m]> quarteradder: Go to this link, click "Target to series": https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1986681
[03:54] <Eickmeyer[m]> Same page, but this targets the Ubuntu package.
[03:54] <quarteradder> Yea, he and @muktupavels were super helpful. They seem to really know their stuff.
[03:55] <Eickmeyer[m]> So, looks like you're trying to get this backported to Focal?
[03:55] <Eickmeyer[m]> Or just Jammy?
[03:56] <quarteradder> Yes, Focal and possibly Jammy too.
[03:58] <Eickmeyer[m]> FYI, in Focal it's in the Universe repository. Most things in the Universe repo aren't supported beyond 3 years, which means it might lose support this upcoming April.
[03:58] <Eickmeyer[m]> With Jammy it's still got quite a bit of time left.
[03:59] <Eickmeyer[m]> Just keep that in mind.
[03:59] <quarteradder> Hmm, I don't see "Target to series".  I'm logged in, but can't find it still.
[03:59] <Eickmeyer[m]> I can do it for you.
[03:59] <quarteradder> Oh, thanks, that's good to know.  It's LTS, but time flies I guess.
[03:59] <Eickmeyer[m]> (I'm on the bug squad)
[04:00] <quarteradder> Oh, awesome, thanks!
[04:00] <Eickmeyer[m]> Yeah, LTS is 3 years for official flavors which use Universe. Anything in Main gets the full 5-10 years.
[04:01] <Eickmeyer[m]> Ok, so before you can get it sponsored, you'll have to come up with the .debdiff and attach it to the SRU bug.
[04:03] <Eickmeyer[m]> And since you're dealing with both Focal and Jammy, it looks like you're dealing with two different snapshots of Compiz, so keep that in mind.
[04:04] <Eickmeyer[m]> Also means potentially two different .debdiff's.
[04:12] <quarteradder> Ok. I might need to read up a bit on the debdiff process first. It sounds like this step requires compiling. I helped debug but ultimately it was @muktupavels who was kind enough to write up the patch, so I don't currently have an environment properly set up for this yet.
[04:15] <Eickmeyer[m]> No, it doesn't require compiling. It requires being able to generate a difference between sources. Basically, a patch.
[05:12] <quarteradder> Eickmeyer[m] Well I'll need to call it quits for today, but I think I understand the process a bit better now. I really appreciate your help! Thanks a ton!!
[06:28] <mitya57> quarteradder: Hi! I was going to upload compiz SRU today. So you are using focal? Will you be able to test jammy too?
[07:56] <luis220413> Can anyone sponsor for my bind9 update for Kinetic in bug 1986586, even though 2 dependencies are in the universe component.
[07:56] <luis220413> Can anyone sponsor for my bind9 update for Kinetic in bug 1986586, even though 2 dependencies are in the universe component?
[07:57] <luis220413> I mean: Can anyone sponsor my bind9 update for Kinetic in bug 1986586, even though 2 dependencies of the built binary packages in main are in universe?
[08:04] <vorlon> luis220413: not until and unless the MIR is approved
[08:10] <luis220413> vorlon: But there are binary packages in main that depend on binary packages in universe: https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[08:10] <luis220413> https://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[08:11] <vorlon> luis220413: no, there aren't.  The packages listed on https://people.canonical.com/~ubuntu-archive/component-mismatches.svg are false-positives
[08:11] <vorlon> and for -proposed, those packages are *stuck in* proposed until the mismatches are resolved
[08:15] <luis220413> But when a package is sponsored, it enters -proposed. Therefore, I believe this can be sponsored.
[08:15] <vorlon> no
[08:16] <vorlon> this is part of the Ubuntu delta deliberately because it is not in main; we should not revert that delta in -proposed so long as there is not a clear path to resolving that incompatibility
[08:17] <luis220413> There is: bug 1986591
[08:18] <vorlon> no, filing an MIR bug does not mean the MIR has been approved
[08:32] <luis220413_> vorlon: There is a clear path: MIR team ACK → security team ACK → sponsoring of my update → promotion of fstrm to main by AA
[08:33] <vorlon> luis220413_: you do not *have* that ack.  Nobody should be sponsoring this diff before it's actually been approved.
[08:40] <luis220413> vorlon: Related: Can you promote lerc to main now that libtiff5 in kinetic-proposed depends on it? This is bug 1977551.
[08:41] <luis220413> This MIR has been approved.
[08:41] <vorlon> luis220413: why does this not show up on https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.html ?
[08:42] <luis220413> vorlon: Search for "lerc: liblerc-dev liblerc3"
[08:42] <luis220413> vorlon: For me it shows up.
[08:42] <vorlon> luis220413: but it shows as in progress, not as fix committed
[08:43] <vorlon> luis220413: ok, you set it to fix committed; this should only be done by the MIR team, I'm reverting that state change
[08:43] <vorlon> the MIR team needs to confirm for us that it's ready for promotion
[08:44] <luis220413> vorlon: The MIR team already gave an ACK... Where is it written that this should only be done by the MIR team?
[08:45] <luis220413> I believe there is no such rule in the MIR policy (https://github.com/canonical/ubuntu-mir)
[08:46] <luis220413> Furthermore, today is a Saturday and I believe the MIR team will most likely not work on MIRs this weekend.
[08:47] <luis220413> I must leave now but I will see your replies in the logs.
[10:44] <ricotz> luis220413, vorlon, hi, lerc requires an i386 build in addition
[11:48] <quarteradder> Hi mitya57 ! Awesome, I really appreciate the help! Yes, I am currently using focal but I have reproduced the bug and am able to test the fix in both focal and jammy.
[11:53] <quarteradder> I'd be happy to test both and post a confirmation on the bug report after you upload the compiz SRU.
[14:03] <mitya57> quarteradder: jammy upload is now waiting for release team approval in the queue https://launchpad.net/ubuntu/jammy/+queue?queue_state=1, focal upload will follow in a couple of hours
[14:04] <mitya57> They will be probably approved next week.
[15:44] <mitya57> And focal is done too now: https://launchpad.net/ubuntu/focal/+queue?queue_state=1
[19:36] <Unit193> ahasenack: https://bugs.debian.org/1017767
[19:57] <Unit193> Crap, how do I usefully add an upstream bugtracker to a LP bug?  I see I can select another distro, but that doesn't help.
[19:58] <Unit193> https://gitlab.xiph.org/xiph/icecast-libigloo/-/issues/1 belongs to LP 1987177
[20:28] <vorlon> Unit193: you would have to do it using the 'also affects project' option, but I'm not sure if you can point to gitlab from launchpad
[20:30] <Unit193> vorlon: OK, thanks.  I likely didn't do something quite right there, but added it.
[20:31] <Unit193> (Upstream became aware of the failure a while ago though.)
[20:31]  * vorlon nods
[20:46] <Unit193> FWIW, yes it doesn't have any build-rdeps, but icecast and likely ices will.
[23:52] <quarteradder> mitya57: Thanks! Not sure if I'm dong it right, but I tried building a binary package with `debuild -i -us -uc -b` to test on focal, but it failed. I think it compiled fine, but 32 tests failed. Maybe it's just be an issue with my environment.