Looked over patches for r-cran-flextable, dipy, and pyfai. They all look fine to me. I don’t have upload permissions for any of them though so they’re still available for the next patch pilot.
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.
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.