> On Mar 5, 2019, at 7:50 PM, Arnaud Rebillout <arnaud.rebill...@collabora.com> 
> wrote:
> 
>   Dear Go team,
> 
> So let met sum up this bug now to avoid you reading the backlog:
> 
> In short, docker doesn't recognize the output of `runc --version`, and
> then it misbehaves and flood the log forever. To be more accurate,
> docker is not happy because it wants to know the git commit that was
> used to build runc. This information may or may not be part of the
> output of `runc --version`: it depends on how runc was built. Actually,
> there are two fields, `version` and `gitcommit`, that can be passed
> optionally to runc during the build (as ldflags). Therefore the output
> of `runc --version` varies accordingly.
> 
> So there's two ways out of that:
> 
> **Solution 1**
> 
> One is to patch docker, and fix their code so that it can handle various
> runc version outputs. This is the way chosen by buildroot for example:
> 
> https://github.com/buildroot/buildroot/blob/master/package/docker-engine/0001-Fix-faulty-runc-version-commit-scrape.patch
> 
> Note that this patch is not the definitive solution: it just allows
> docker to handle the output of runc *as built in buildroot*, and not in
> every case. If we go this way, we'll do something similar, supporting
> "debian's runc" output, and end up with a patch that has no chance to
> make it upstream.
> 
> Maybe the core of the issue is that the `runc --version` output is
> difficult to parse properly, and that's why docker upstream don't want
> to bother fixing their code...
> 
> 
> **Solution 2**
> 
> The other way is to modify the runc build so that we include the git
> commit. I've pushed such a change on a branch at:
> 
> https://salsa.debian.org/go-team/packages/runc/commit/033a60b549b0935861c92bf4e5118d03ef443a8f
> 
> It's actually not that bad, no patch involved, it's really just adding
> ldflags. The only downside I see is that there's an additional step when
> a maintainer wants to release a new upstream version: he has to look for
> the corresponding commit and add it to the file
> `debian/upstream-version-gitcommits`. I provided a helper script to do
> that, so it's really a small overhead.
> 
> 
> **What do you think?**
> 
> I'm in favor of solution 2, it seems the path of least trouble, and is
> also a correct thing to do IMHO. I'd like to have this fixed for buster,
> as this issue has been opened for a long while.
> 
> If you agree with solution 2 I'll need some DD to upload a new version
> of runc with this change (sorry to bother you...). Also this bug should
> be re-assigned to runc if we solve it in the runc package.
> 
> For more details you can also look at upstream discussion:
> https://github.com/moby/moby/issues/38709
> 
> 
> All the best,
> 
>   Arnaud

Based on the upstream bug linked it sounds like solution 2 is what they prefer, 
and also makes runc consistent with upstream releases.  If there’s consensus I 
am happy to sponsor an upload of runc for you.  Unfortunately, since we’re so 
close to the freeze it will not make it into buster unless there is an 
exception made.

Stephen

Reply via email to