On Tue, Feb 21, 2017 at 9:46 AM, Michael Tokarev <m...@tls.msk.ru> wrote:
> Hello Christian! > > Thank you for doing this. > > 17.02.2017 13:48, Christian Ehrhardt wrote: > > > case sha1 summary > > a 84dc4d05d3 ubuntu acl fix dependencies changed > > This really should be fixed in acl package, not in qemu. I > filed a bugreport about this quite some time ago, and actually > forgot about it. > I agree that a correct long term solution would be better. Yet this change is only modifying the current "workaround" to be slightly more modern. And it all is behind an :ubuntu: mask anyway. So if you could consider to pick it still that would be very kind. If not I think that is fine as well - as this really isn't the most complex delta :-) Do you happen to know/find the bug number you filed on acl? > > a 0d52ac1285 Make qemu-system-common depend on qemu-block-extra > > a b24146b825 Make qemu-utils depend on qemu-block-extra > > This is something I really don't want to do. This completely > defeats the purpose of qemu-block-extra package. > > The idea was to be able to ship less commonly used backends > in a separate package to avoid too much dependencies. > When you make these a strong dependency, you end up always > installing this package. > To start with the right mindset, I know the concept from many other packages and understand your position on this. > I objected when this has been done in Ubuntu, and asked for > a reason for this, but never seen a reply. Maybe you can > re-evaluate the reasons why this has been made in Ubuntu, > and revert this change. > IIRC it was that some of the drivers where considered not so "extra" but more core for us. Let me look if I can unearth some history on this. > I can _guess_ this was because some people complained that > after introducing this new qemu-block-extra package, their > block devices stopped working (because they've been moved > to -extra out of main). We can't really deal with this by > introducing new packages and making transitional packages, > we can, however, _recommend_ the new package, and we can > mention this in the NEWS file (both of which I did). > I think a recommend would be just as fine for us bug I need to know the history to really decide. *digging* Imagine a spinning progress bad | / - \ ... Ah I found it https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1495895 Reading that I think we would be fine with a recommends as well. On installing by default recommended packages would be co-installed. But one "could" install without them via the man apt ways of not installing recommends. What do you think now knowing the history of this? Should we just together go with a recommends in the git for now. And on the next merge I'll check in Detail if it really does not open an error window for us and would come back. > > a 5dea4321d9 qemu-efi is in universe > > a 4018ada7da no more skip enable libiscsi (now in main) > > a fc0aef8d0c let qemu-utils recommend sharutils > > b a06832a485 avoid people editing d/control > > b 7a257a6a46 Enable seccomp for ppc64el > > a 5c4d2d0849 Disable glusterfs (Universe dependency) > > b 78aaa8e6b0 char: fix ctrl-a b not working > > b 4aa3e058c2 bump libseccomp-dev dependency > > The rest is good small fixes. 78aaa8e6b0 is from upstream and > should be in next their stable, hopefully. These are good small changes I'll definitely pick. > > At any rate, all this, unfortunately, is post-stretch material, > as I can't change anything in the main branch at this time, > unfortunately. Maybe it's time to create debian-stretch > branch anyway. > It is totally fine that this is post-stretch, but yeah now that you have released it might be worth to spin of an extra branch for it. > Thank you very much! > > /mjt > -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd
