Nothing to report from IRC
The request for the gdb SRU came from irc. There was another request just after I ended my shift for an openssl SRU, but it needs more than just a quick look.
MP #455564 and MP #455517: apache2 MPs for @mdzurick. Left comments asking for improvements.
Bug #1991909: the user addressed the comments made by @paride, so I uploaded the package and staged the SRU as per @ahasenack’s instructions.
MP #455006: curl merge from @danilogondolfo. Left minor comments asking for improvements. He addressed them, and I uploaded the package.
MP #454972: netcat-openbsd merge from @danilogondolfo. Left a question. Also explained more about how dpkg-buildpackage scans changelog entries to automatically close bugs.
Bug #2008594: getmail6 fix. Uploaded after doing a small adjustment to the provided debdiff.
Bug #2038834: fix for mesa. The Noble upload was done, but there’s no debdiff for Mantic. I left a comment asking for it.
~ubuntu-sponsors from bugs whose debdiffs/packages have been uploaded. If there are any subsequent problems with the upload, the reporter can always flag us again. I had a brief conversation with @tsimonq2 and @ahasenack on IRC about it.I’ve been casually taking care of one or two a day. I haven’t been posting here because I don’t want to fill up the thread with my one or two each time, but feel free to mention me. 
Today I did these two:
I think, intuitively I take the LIFO approach to the queue, but in reality it should be FIFO. Would be nice to see some of those older items gone.
ubuntu-sponsors until this is addressednemos-dev-key, optee-os-s32, u-boot-s32, and arm-trusted-firmware-s32
nemos-dev-key now sponsored thanks to @tsimonq2 (LP: #2043448), optee-os-s32 was ready to go (LP: #2034648) so I sponsored that with minor changesu-boot-s32 (LP: #2034650) but I need to compare it to a fresh build of u-boot under noble and I’m now getting yet-another FTBFS due to cross-build compiler flags on that. I’ll dig into it again tomorrow, but ultimately I’m aiming to deal with this and the remaining -s32 packages.I did more than my usual “one or two” packages today, so here’s a post.
According to the KPI metrics, the sponsorship queue was at 33, 24 hours ago. Right now, it sits at 24. Here are the uploads I personally did today:
kernelshark was accepted. Thanks for your help, @tjaalton!Other extremely important notes:
.-""-.
/ .--. \
/ / \ \
| | | |
| |.-""-.|
///`.::::.`\
||| ::/ \:: ;
||; ::\__/:: ;
\\\ '::::' /
`=':-..-'`
Remember, community members can patch pilot too. If you’re in ~ubuntu-dev, take a seat in the cockpit! 
I’d also like to highlight @bdrung’s starter work on an ubuntu-sponsoring package, with some additional refinements to the code. I think the original package looks promising, but if anyone (~ubuntu-dev or not) is looking for some low-hanging fruit, I’m sure he’d appreciate the help with test cases, splitting data collection and rendering, etc.
Thanks.
I will say my singing was on-point.
LP: #2007702: asked the reporter to fix the version numbers for the SRU candidates and pointed to the SRU policy.
LP: #2041171: removed ubuntu-sponsors, patch already uploaded.
LP: #2042902: asked the reporter to fix the version number for the mantic SRU candidates, pointed to the SRU policy, and asked them to adjust the trackers for each series.
Ping about zlib sponsoring: I didn’t have time to do all of it, but at least was able to spot and suggest some organizational details in the changelog that should help to not be in the way when the next sponsor comes by
I had the opportunity to do a little piloting today. Here are a few notes…
-k, just set DEBSIGN_KEYID=<YOUR_KEYID_HERE> in ~/.devscripts - this will pick up your key every time./etc/quilt.quiltrc has the default quiltrc, which enables the header and differences in the config. We should consider whether changing the defaults, or noting in the packaging guide, might be a good idea. Less diff lines are Usually better.@canonical.com email address, it creates a ghost Launchpad account. That karma belongs to you! Here’s an example that I discussed with @adrien today.
The sponsor queue report that the Patch Pilot team uses is the general report that excludes security and kernel uploads.
Makes sense, I didn’t notice that. Thanks.
That being said, KPI shows all items, and IMO the point still stands: red items should get appropriate attention.
Well, we can fix the KPI to track the thing we’re actually trying to drive to zero!
The other items should get attention, yes. But kernel patches in particular are not really an Ubuntu community thing.
Let’s do it!
A quick point of clarification: there’s a difference, in this case, between kernel packages and kernel-adjacent packages. The former, yeah, not touching with a 10-foot pole, let Canonical Kernel take care of that. The latter gets more fuzzy, because that covers e.g. DKMS-related packages that I’d rather not touch, but don’t fall into the direct “jurisdiction” of Canonical Kernel.
Those packages will still show up, and are still on the general report, but are not something most sponsors feel comfortable touching. We should think about either asking someone from Canonical Kernel to rotate and take care of these, and/or ask skilled/willing individuals from Foundations/another team to do the same.
My shift today was affected by multiple conflicting meetings and interruptions. So I couldn’t get lots of stuff done.
zlib merge, at least:
Excited to be able to help a bit more with patch pilot now that I’m a core dev 
In between meetings, I did some archaeology for the zeitgeist merge, and looked at the libgcrypt20 SRU.
Since the current queue is mostly made out of Canonical contributions, I’d like future shifts to prioritize the zeitgeist merge if possible as it is a pure community contribution.
This shift was my first patch pilot shift were I got pinged on #ubuntu-devel. It look like the patch pilot program takes off!