17.09.2020 10:56, John Paul Adrian Glaubitz wrote: > On 9/17/20 9:49 AM, Michael Tokarev wrote: >> You should not use upstream git of qemu, since it too lacks >> important patches like this, - please don't suggest people >> to use outdated sources.. :) > > I think I'm one of the heaviest users of QEMU inside Debian and if > I had stuck with the Debian version of QEMU, the m68k and sh4 ports > would not be able to keep up due to QEMU issues. Laurent will confirm > the number of bugs I reported and that got fixed.
You were referring to particular example of a patch which is NOT merged upstream, - not your other heavy usages. And this is exactly what my joke about - if lack of this patch makes source outdated, it should not be used, hence upstream git is also outdated, nothing more nothing less. I wont deny other issues being addressed upstream all the time, and I definitely wont fight against Debian stable policy. >> (just as a matter of fact, debian usually has new version of >> qemu the next day it is released, and I usually keep it up >> to date in backports. With debian stable and current qemu 5. >> we have a bit of delay since there are a few other things to >> backport, but we have 5.0 there). > > Well, the first thing would be to switch QEMU in Debian to finally > use systemd-binfmt instead of the old binfmt-support package, > something that has happened in other distributions long ago. This is debatable. First of all I didn't know binfmt-support is "old", just checked its pages and description, - nowhere they mention it is deprecated or something. And to me, I think "switching to" should happen *in* that package, ie, when binfmt-support and systemd cooperates, say, binfmt-support prepares stuff for systemd and does nothing when booted under systemd. This will make other packages using binfmt-support to work with the systemd binfmt registration instantly, and things will continue to work if systemd is not in use (for those who prefer sysvinit or other init mechanisms, fwiw). It's trivial to "switch" to systemd binfmt support on qemu part. But I don't want to do it without a good reason, and I don't actually see binfmt-support being "bad" in some way, - what's the problem with it exactly? > If you are willing to cooperate though, I'm happy to point you to > all the patches necessary to address all issues that we observed. I'm definitely interested in things being fixed in the end, tho it isn't obvious how much backporting should be done to _testing_ version in Debian. /mjt