Re: Bug#970460: qemu-user: trashes argv[0] breaking multi-call binaries
Michael Tokarev dixit:
> 17.09.2020 10:56, John Paul Adrian Glaubitz wrote:
>> On 9/17/20 9:49 AM, Michael Tokarev wrote:
>>>17.09.2020 10:08, John Paul Adrian Glaubitz wrote:
>>>> On 9/16/20 8:42 PM, Thorsten Glaser wrote:
>>>>> John Paul Adrian Glaubitz dixit:
>>>>>
>>>>>> That’s been fixed upstream and can be configured with the
>>>>>> qemu-binfmt.sh script and the option “preserved=yes”.
>>>>>
>>>>> $ locate qemu-binfmt.sh | wc
>>>>> 0 0 0
>>>
>>>It is scripts/qemu-binfmt-conf.sh script inside the qemu sources.
>>>It was a fork of debian's d/update-binfmts.sh, updated for other
>>>use cases.
Ah, okay.
>>>> Well, to be honest, you should never use the Debian QEMU package. It's almost
>>>> always very outdated and would lack important patches like these. It's easier
>>>> to use local builds from git.
Erm, excuse me?!?!?!
Of *course*, when developing for (or on, most of the time)
Debian, I use as many tools in the form packaged in Debian
as possible.
When developing *for* Debian (that is, things that eventually
get uploaded), I think it’s correct to even have the *expectation*
that only packaged things get used throughout the chain.
If your qemu buildds have errors, where else would we fix them?
Also, how else would maintainers reproduce them?
I reported this bug *because* your qemu buildds had errors
building mksh and because I was able to reproduce them.
I *really* _expect_ qemu buildds to use the packaged version
of qemu-user, ideally the one from sid.
>>>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.. :)
Thanks for the confirmation from the maintainer.
>> 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.
That asks for trying to work with the Debian maintainer of the
affected package (qemu in this case) to get the bugs not only
fixed but also available to Debian users. (Yes I know, but see
below.)
>>>(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).
But a buildd can run unstable anyway, and especially with
qemu-user-static this should be a given.
>> 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.
Absolutely not! That will break it on all my systems.
> 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).
Thanks.
>>>>> Also, why didnb t you fix that on the m68k and sh4 qemu buildds then? ;-)
>>>>
>>>>I did. But I'm updating the QEMU version on the buildds from time to time
>>>>by rebasing with git master and then I drop all the patches that have been
>>>>applied upstream.
Arrgh, no. Please use the packaged version. That avoids
many issues and ensures trust.
>> 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.
Thanks for being open to patching the version in Debian. Not all
maintainers are agreeable like that, unfortunately.
I know the burden of carrying local patches, but backports would
have been already accepted upstream, are scheduled to be removed
with a new upstream release, and are less likely to break things.
Patches that fix things for an architecture, whether guest or host,
should be considered IMHO, even if it’s not a release architecture,
at least during normal development, i.e. not just before a freeze
but all the other time.
>> There is also an important glibc patch necessary to unbreak qemu-user
>> that still hasn't been merged in glibc upstream or in Debian's glibc
>> package [1, 2].
>> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916276
>> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=23960
This is the first time I’m being made aware of that. (I had wondered
about the +qemu releases in unreleased.) This looks like another case
of prodding maintainers (and, perhaps, looking whether it can’t be
fixed in qemu as well).
But that’s what uploads to dpo unreleased are for, after all. And
if done with care and following normal Debian rules (and, incidentally,
being made using _only_ tools from Debian) I consider unreleased part
of Debian on that specific architecture (as it’s a ports-only thing
anyway).
bye,
//mirabilos
--
<ch> you introduced a merge commit │<mika> % g rebase -i HEAD^^
<mika> sorry, no idea and rebasing just fscked │<mika> Segmentation
<ch> should have cloned into a clean repo │ fault (core dumped)
<ch> if I rebase that now, it's really ugh │<mika:#grml> wuahhhhhh
Reply to: