Comment 21 for bug 2059303

Hi @seth-arnold,
I am not in-depth familiar with security related updates (since they happen rarely for me, and if private-security are handled by the security team anyway).

"
My assumption is that these package updates should be published first to -updates for autopkgtest testing, and once they have passed testing and phased to users, then we should republish these updates to -security so that they are available to all users. Does this sound correct?
"
There are no autopkgtests (for historical reasons and since lot's of functions in that package req. the hw to be configured in a certain way, which cannot guaranteed by the build systems), but the packages get (and already got) already manually tested upfront, with focus on the changes (according to test plan in SRU justification).

"
This is much easier to execute if the updates have been built in a PPA with only -security enabled, and not -updates. (The -security pocket is built with only packages from -release and -security, not -updates.) Do packages built in such a PPA exist?
"
I've now kicked off build in a -security only PPA here:
https://launchpad.net/~fheimes/+archive/ubuntu/lp2059303-sec
(so yes, they build there, but it'll take a while until published)

"
The SRU workflow asks for packages to be either uploaded with dput to the queue or debdiffs provided. I see some debdiffs here, but some additional work was performed after most of the debdiffs were uploaded.
"
The changes are some broken URL references in some quilt patch headers, I've fixed those.

"
Are the posted debdiffs something that the SRU team should work with? The Ubuntu Sponsors team was added around three weeks ago, before much of the work was done, it's entirely possible that this has fallen off their radar as a result. (And, the general hustle of responding to the xz-utils issue, release time goals, etc.)
"
I think the debdiffs should be taken (as usual).
It's difficult to get SRUs processed around release times.

One concern I have is that copying the packages might not work, since there is a bootloader component that is signed, and the signing key is based on the location where the package is build.
Hence a package build in PPA will be signed with the PPA key and not with the official ('production') key
and so copying it over from PPA to archive will probably mess up things.

So I believe the debdiffs need to be the base for an upload (by a sponsor), then build for the archives (that will ensure signing with the proper key), then published on -proposed, verified there and then eventually released.

(I'm attaching the debdiffs again, with fixed urls)