[05:24] <mirespace> good morning
[07:40] <utkarsh2102> \o
[07:52] <cpaelzer> hi utkarsh2102
[07:52] <cpaelzer> and everyone else o/
[12:01] <ahasenack> morning
[12:08] <ahasenack> rbasak: hi, morning/afternoon. I noticed a few PRs against ubuntu/devel (not debian/sid), of which https://code.launchpad.net/~bryce/ubuntu/+source/mysql-8.0/+git/mysql-8.0/+merge/415713 is an example, where the package migrated, but the PR is still in the "needs review" state. Is git-ubuntu not noticing it for some reason, or just falling behind?
[12:09] <ahasenack> I appreciate that this example I gave is old, and we might don't have the data anymore
[12:09] <ahasenack> I'm just going over the list at https://code.launchpad.net/~canonical-server/+activereviews which is quite large
[12:11] <ahasenack> mirespace: hi, could you please set the status of this MP to "merged"? This is one of those cases where git-ubuntu won't do it for us, because its target is debian/sid
[12:12] <rbasak> ahasenack: mysql has an empty directory in its source
[12:13] <rbasak> I wonder if that's the reason? Have you checked to see if the MR commit hash actually appeared in pkg/ubuntu/devel?
[12:13] <rbasak> It's not git-ubuntu that does the detection - it's LP.
[12:13] <rbasak> So I think it's just a match against the commit hash and that's it.
[12:14] <rbasak> Occasionally LP fails to "scan" the commits in the updated repo. Then there's an API call to make it rescan. That's the only case I know about where it doesn't happen if the hashes match.
[14:36] <mirespace> hi ahasenack! corosync merge changed to "Merged"
[14:43] <ahasenack> cheers!
[14:44] <ahasenack> I was just going over the list and thought "wait, there are way too many merge proposals still open" :)
[15:00] <mirespace> Sometimes is confusing for me when turned it to Merged, bu that one was very old , sorry
[15:34] <bryceh> good morning
[15:49] <mirespace> hi bryceh
[16:06] <andol> Should https://ubuntu.com/security/cves?q=CVE-2022-0847 really show zero results?
[17:02] <bryceh> forgot to mention at standup, also posted MP for https://code.launchpad.net/~bryce/+git/team-subscriptions/+merge/416422
[17:30] <rbasak> ^ reviewed
[17:47] <ahasenack> new dep8 test for backuppc up for review: https://code.launchpad.net/~ahasenack/ubuntu/+source/backuppc/+git/backuppc/+merge/416479
[18:39] <bryceh> @ahasenack, I can take a look at that one.  I also have nfs to review for you.  Will try to get to both this afternoon.
[18:39] <ahasenack> thank you!
[19:45] <orndorffgrant> Heads up (especially rbasak and paride) that ubuntu-advantage-tools is starting our release process for version 27.7. You can have a preview of whats coming at our github PR for it here: https://github.com/canonical/ubuntu-advantage-client/pull/1988/commits
[19:47] <ahasenack> orndorffgrant: do you have/need an FFe for it?
[19:48] <ahasenack> glancing at the changelog, looks like you need an FFe
[19:52] <orndorffgrant> That is a good question - the release is mostly features yes. I'm not sure we've needed an explicit feature freeze exception for ua for the past few releases because we always release all features to all series - so we're kind of in a special/weird process. blackboxsw have we needed a FFe in the past?
[19:53] <ahasenack> I found a few
[19:53] <ahasenack> big lp url
[19:53] <ahasenack> what's the url shortener we tend to use again?
[19:54] <ahasenack> orndorffgrant: this is the most recent one I think: https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/1915354
[19:55] <ahasenack> october last year, so that was... impish?
[19:55] <ahasenack> oh, sorry, february
[19:55] <ahasenack> hirsute then
[19:55] <ahasenack> don't mind me
[19:55] <ahasenack> something like that
[20:05] <orndorffgrant> Good find! Yep I thought we had released on impish between FF and Release but we didn't. We were planning on releasing 27.3 https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/1942929 but it took longer than planned and ended up being a 0-day SRU IIRC
[20:07] <orndorffgrant> So I guess we do need a FFe here. And I've never done that process before :) - do we have a wiki/discourse page on how to request it?
[20:07] <ahasenack> sure
[20:07] <ahasenack> orndorffgrant: https://wiki.ubuntu.com/FreezeExceptionProcess
[20:07] <bryceh> orndorffgrant, ffe's are pretty straightforward
[20:10] <orndorffgrant> +1 cool - thanks!
[20:11] <bryceh> orndorffgrant, mainly the most important part is to explain why you say it should be safe, so like mentioning that you already release all features to all series anyway is probably going to be a key point to make
[20:14] <orndorffgrant> yeah that makes sense, I'm wondering if UA should/could get a standing/ongoing FFe for that exact reason. In the same way that UA has a special SRU exception to release features https://wiki.ubuntu.com/UbuntuAdvantageToolsUpdates
[20:15] <bryceh> @orndorffgrant, it's likely you can craft a well-worked FFe and then just reuse that same text each cycle where it's needed
[20:15] <orndorffgrant> Excellent point
[20:16] <ahasenack> I don't think there can be a standing FFe "exception", like for SRUs
[20:16] <bryceh> part of the value of the FFe is tracking purposes for the release team, so they may prefer having separate bugs than one aggregated one with per-release bug tags.  Or maybe vice versa.  Worth asking them.
[20:16] <ahasenack> FFes should be an exception if possible
[20:18] <orndorffgrant> Got it, okay that makes sense
[20:18] <bryceh> ahasenack, I had kind of a FFe exception for the fglrx driver that ati always released just weeks ahead of our release, although the details of that are lost to the mists of time.  Anyway, I think there may be some precedent.
[20:18] <ahasenack> ok
[20:18] <bryceh> however I think it mostly boiled down to cut-and-paste the prior FFe
[20:22] <bryceh> https://wiki.ubuntu.com/X/DriverUpdates aludes to it
[20:25] <boblamont> hello. I have screwed up my formmail script somehow and it isn't working
[20:29] <blackboxsw> orndorffgrant, ahasenack and bryceh: I have a vague recollection after that FFe for ubuntu-advantage-tools that I was told it was unnecessary due to the fact that we are going through our SRU validation for UA's standing SRU exception process anyway.
[20:30] <blackboxsw> Since we are doing that full validation prior to the upload into a FF release it essentially was all basically treated as SRU process as long as we are running our validation scripts on all target series in this case.
[20:31] <blackboxsw> I'll see if I can find that conversation/log/blame on that
[20:32] <blackboxsw> in either case orndorffgrant, as mentioned it's as straightforward as filing the correct bug template related to the features included
[20:36] <orndorffgrant> Got it, if it is the case that ua shouldn't need a ffe every time for those reasons, then we should make that official somehow
[20:40] <blackboxsw> yeah orndorffgrant, I think it feels like a bit of overhead given the amount of testing and verification that is done for each release due to exception reqiurements https://wiki.ubuntu.com/UbuntuAdvantageToolsUpdates
[20:53] <athos> would anyone mind sync'ing dh-php 4.9 from debian? :) I already got the FFe here:
[20:53] <athos> https://bugs.launchpad.net/ubuntu/+source/dh-php/+bug/1963695
[20:53] <bryceh> athos, yep I can take that
[20:53] <athos> and bryceh is already aware of this sync request
[20:53] <athos> oh, thx bryceh :)
[20:54] <bryceh> athos, when you're back to work I have another straightforward php task / patch-on-plate
[20:55] <bryceh> dh-php sync requested for 4.9.  Should go through shortly
[20:57] <athos> bryceh: nice; thank you!
[21:41] <bryceh> athos, [ubuntu/jammy-proposed] dh-php 4.9 (Accepted)
[22:32] <giu--> hi