Kees Cook [2010-12-05 11:28 -0800]: > Hi, > I disagree here -- the ABI-tracking packages may include things outside the > kernel too. I'm significantly more comfortable with doing the builds where > they cannot possibly hit an -updates vs -security skew problem.
I see. I don't see much of a potential problem here, but I understand your concern and agree that it's technically cleaner to build them in a non-proposed environment. > I maybe do not understand what these tools are We have a tool "queuediff" which automates the review process as much as possible. See https://wiki.ubuntu.com/StableReleaseUpdates#Reviewing%20procedure%20and%20tools for the details. This would need to be changed to fetch the .changes and debdiff from the PPA. I just checked, and fortunately it seems that PPAs also generate debdiffs against the corresponding Ubuntu release, so it shouldn't be too hard. Is this going to be a public PPA? If not, then we need to rewrite queuediff from urllib to using launchpadlib (there seems to be a method packageDiffUrl() which we can use), and ~ubuntu-sru needs to be able to access the PPA. > , but I thought the kernel was reviewed from -proposed before being > promoted to -updates? No, an upload gets reviewed before it gets accepted into -proposed. The alternative approach would be to let the security team do the review and copying, and run sru-accept.py by themselves, as I outlined in https://wiki.ubuntu.com/ArchiveAdministration#Copying%20PPA%20kernels%20to%20proposed%20(DRAFT) I guess you already have your own methods/scripts to review package deltas, so exercising the steps 1 and 2 might actually be easier for you as well? Thanks, Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/technical-board
