On Tue, Feb 28, 2017 at 10:16 AM, Michael Tokarev <m...@tls.msk.ru> wrote:
> 17.02.2017 13:48, Christian Ehrhardt wrote: > > > - a) Ubuntu only fixes that can be hidden under the vendor based > > control-in -> control mechanism > > - b) Fixes applying to Debian as well (only for those there will be a > > debian/changelog entry needed) > > > > Since the ubuntu-zesty-2.8 is available for you as well now this should > come > > down to evaluating the following list of cherry-picks for acceptance into > > latest Debian. > > > > case sha1 summary > > a 84dc4d05d3 ubuntu acl fix dependencies changed > > a 0d52ac1285 Make qemu-system-common depend on qemu-block-extra > > a b24146b825 Make qemu-utils depend on qemu-block-extra > > I already commented on these 3. > > You can drop the last 2 of them completely, I guess. > Yeah, as we discussed before if we make it a recommends in general I should certainly be able to drop the hard depends. [...] > a fc0aef8d0c let qemu-utils recommend sharutils > > Why qemu-utils recommends sharutils, what for? > Searched through history on that one as well, but this clearly is one of those that I quoted as "Several changes were applied but missing in the changelog so far". Those were just pulled in by the merge commits without being mentioned for quite a while - I just "uncovered" them. I think it is an artifact from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820449 and can be ignored in the context of this bug (and dropped on my side) > > b 7a257a6a46 Enable seccomp for ppc64el > > This one isn't for stretch, delaying for now. > Why only ppc64el, why not other ppc variants? > Because ppc64el was the only one I could test/verify on. If you can check more we can enable more, but I had no way to do so. There actually is another fix needed along that which I intended to submit in the next set. But since it fits here, enabling seccomp for ppc64el needs a dependency bump - libseccomp-dev (>> 2.1.0) [linux-amd64 linux-i386 linux-ppc64el], + libseccomp-dev (>= 2.3.0) [linux-amd64 linux-i386 linux-ppc64el], You can merge that into the change, or wait for my next set of changes to hit since you wait on stretch+1 for that change anyway. [...] Thanks for all the picks already (I cut them out of my quote to streamline a bit). And it is clear and ok for those not for stretch to be picked later. > So we're left with sharutils and acl changes, and seccomp on ppc. > I outlined on ppc/sharutils what I think on inline above. On the acl change, while I agree the right fix is the bug you filed it is kind of unclear when this will happen. If not a maintenance burden for you I'd ask you to accept the minimal change which modifies the dependencies behind an :ubunu: label only for now (84dc4d05d3). Checking if my timing/approach works for you: - I thought I saw you preparing a new upload (many bugs merged / assigned, CVEs lining up in debian-unstable branch) - I expect (please correct me) that to be a 1:2.8+dfsg-3 upload - If the changes discussed here would be applied there that would be great and I wanted to remerge - not sure since they are no criticals for you, you might push the changes discussed here only for the next release - but even if the changes we discussed here are not in there I'd plan me to merge that for the CVEs - After some testing I'd get back to you with any additional Delta/Fixes I identified to be needed for 2.8. - preview: there is already one in my queue which is based on http://patchwork.ozlabs.org/patch/721974/ (I can't wait that to hit next stable)
