https://bugs.launchpad.net/octavia/+bug/2024188 : I was about to upload, but checked in with the OpenStack team since there were mention of repositories other than the archive. It ended with @corey.bryant kindly offering to do the sponsoring.
started review of https://code.launchpad.net/~mitchdz/ubuntu/+source/multipath-tools/+git/multipath-tools/+merge/451301. One-liner but which can have big implications on how the service is used, which means I need to read up (again) on systemd. Small rant: systemd keywords almost all have āsimilar toā wording in their explanation. āFoo is similar to bar, butā. Itās hard to keep it all to memory.
Important Context
There are many NEW packages in the sponsorship queue, which could take more than one patch pilot shift to be analyzed correctly.
Same story for the first two of a series of patches all related to support of the NXP S32G board (LP: #2034640, LP: #2034641)
Of the remaining patches, reviewed the arm-trusted-firmware one and left comments on some of the improvements that would be required (starting with where the patches come from). Was going to remove ubuntu-sponsors and mark incomplete but Laider Lai managed to respond very quickly with the requested changes so the next pilot can continue reviewing this one.
Also reviewed the u-boot one and left comments on some improvements that would be required, and the potential for the up-streaming of the changes. Removed ubuntu-sponsors for now.
Important Context
Most (at time of writing all) of the [needs-packaging] bugs in the queue are related to NXP S32G support.
There were 15 requests in the sponsorship queue. Two were apparantely already handled by the kernel teamās process and needed closing. Seven were contributions from one person from Canonicalās hardware enablement team, and donāt look like they can be handled through patch piloting. I reviewed and sponsored one. Two are already being reviewed by Andreas. One was for flash-kernel (another hardware enablement) that Dave has partially reviewed - perhaps heās the best person to look again as itās quite involved. That leaves two I didnāt have time to look at.
A common theme seems to be really complex hardware enablements or new features. Iām not sure these can ever be expected to be handled by generalist patch pilots, rather than Ubuntu developers with specialised experience in those specific areas. Iām concerned that weāre doing a disservice by encouraging these types of contributions to use the sponsorship queue. A topic for further discussion, perhaps?
The kernel team say they do not accept MPs and contributors must follow their process instead. This is not ideal and the opposite of my previous request. But the kernel team process is so far removed from the rest of Ubuntu development process that itās probably not worth tackling that monster right now. For now, I closed the MPs since a kernel team member confirmed to me that these requests are being handled through their process.
The only reason these appear as git-ubuntu repositories in the first place is because we donāt have a good mechanism for me to detect kenrels and not import them. The list of kernel source packages is ever-growing and linux-firmware is for example not a kernel so a simple linux* match wonāt work.
These are all filed by someone from Canonicalās hardware enablement team. Steve already mentioned in the first bug that it canāt be handled by generalist patch pilots since it also requires kernel process. The submitter doesnāt appear to have ever been on IRC as far as I can tell, so I was unable to just ask them there. I sent them a private message asking what process led them to submitting these here, and if they have an alternative, to try and understand how I might be able to improve the overall process here.
Iām not sure if itās intentional that this other MP is no longer in the sponsorship queue due to [1], and/or if Andreas is expecting to look at it again himself or it should be reconsidered by a patch pilot. I pinged Andreas.
The status of the sponsoring queue is similar to that @rbasak described, with many very specific sponsorship requests mostly around kernel packages. I didnāt take action on those.
ivar LP: #2037769 / MR 452663 reviewed, triggered autopkgtests in PPA, and sponsored
makedumpfile LP: #1800562 crichton decided this week that lp1800562_eoan.debdiff seems to be a debdiff and subscribed ubuntu-sponsors@bdmurray . I removed the āpatchā flag from the attachment, removed the āpatchā tag from the bug, and unsubscribed ubuntu-sponsors. This should prevent future bot uprisings.
libfprint LP: #2034121 / LP: #2034481 I found conflicting patches for a Lunar SRU in each bug, marked both Incomplete and left a comment in each
openssl bug 2033422: Left a comment asking @adrien to improving the naming scheme he chose for the patches, add DEP-3 headers and improve the d/changelog entry.
firmware-sof MP: Thereās no diff to be reviewed, so I left a comment asking for clarification.
usbmuxd MP: Verified the fix and uploaded to Mantic.
Didnāt help much on LP: #2036873: big java sru, requesting new versions of java in stable releases, with lots of caveats (jtreg doesnāt work, what is it? What are the consequences? And so on). Iām not familiar with this ecosystem, and I think someone more familiar with it should review that change. And it will require an archive admin in any case, at least for jammy and focal. But I also asked questions about how this update follows the SRU policy on openjdk updates.
a lot of back and forth on the multipath-tools restart fix, fine tuning it. Sponsored for lunar and jammy (in another mp).
looking into why this nix ftbfs is not a problem in debian, or maybe it is, but that build killed my machine. It feels odd to build-depend on libssh-dev and libssh2-1-dev at the same time.
Added some follow-up questions to Andreasā on the big OpenJDK SRU (LP: #2036873). I think most were answered, but the issue remains that we seem to be (at the least) bending the OpenJDK SRU policy here.
Looked at the multipath merge, and fell down the debhelper systemd restart behaviour ā¦ again (aaargh!). But this time, the package is prior to dh compat level 10 (which was unfixed, so it still involves stop in prerm, not preinst), left a brief note to that effect, and ran away to hide in a dark corner.
Read through the OpenSSL SRUs in LP: #2033422 and LP: #2023545 but I donāt think I can add anything at this time (other than to wonder why two of the bugs in the over-arching bug, LP: #2033422, are marked for ubuntu-sponsors and the other two arenāt?
The patch for libvirtās default configuration in LP: #1960937 looks good, but probably worth waiting to hear if Debian want to accept it first to avoid bloating our delta if at all possible.
The fix for wifi on the StarFive VisionFive (LP: #2038546) looks reasonable, but leaving for the kernel team to action
Patch Pilot doc for handling git-ubuntu MPs that I worked on during my last patch pilot stint are now available on readthedocs. (This should probably be more prominently linked to from the main patch pilot docā¦)
The multipath-tools merge was uploaded by Andreas and is currently in the unapproved queue. It wonāt be set to Merged until it has been accepted by SRU, so may be lingering on the patch pilot list until then.
The openjdk-21 SRU is backporting a full release. Iāve dealt with openjdk and jtreg through a customer project so this all looks fine to me in principle, however this feels like it might be slightly outside the scope of patch pilot, particularly given that the test suite is being disabled and the bug report shows some failures, and may be more appropriately sponsored by someone on Foundations.
ubuntu-advantage-tools R30 I will take ownership of, but I suspect Ubuntu Pro reviews shouldnāt be included in the sponsorship list since theyāre not really in scope for patch pilot.