Bug 1012409

http://lsm5.fedorapeople.org/rpmbuild/RPMS/x86_64/docker-io-0.6.2-14.devicemapper.fc21.x86_64.rpm

Let me know.

Ignore Comment 1.

Here's the right link: http://lsm5.fedorapeople.org/rpmbuild/RPMS/x86_64/docker-io-0.6.3-1.devicemapper.fc21.x86_64.rpm

Thanks for quick fix, unfortunately this hasn't fixed the issue:

$ docker version
Go version (client): go1.1.2
Go version (server): go1.1.2
Last stable version: 0.6.3

$ docker push goldmann/f20
The push refers to a repository [goldmann/f20] (len: 1)
Sending image list
Pushing repository goldmann/f20 (1 tags)
Pushing 5c47c08926951ad84aa164b300f13dc3ebfbb72b626163806415bbe7b3e30d2c

2013/09/27 09:16:07 Failed to upload layer: Put https://registry-1.docker.io/v1/images/5c47c08926951ad84aa164b300f13dc3ebfbb72b626163806415bbe7b3e30d2c/layer: archive/tar: header field too long

I've tried the upstream binary which can be downloaded from here: http://docs.docker.io/en/latest/installation/binaries/ and it worked:

$ ./docker version 
Client version: 0.6.3
Go version (client): go1.1.2
Git commit (client): b0a49a3
2013/09/27 09:40:03 GET /v1.5/version
Server version: 0.6.3
Git commit (server): b0a49a3
Go version (server): go1.1.2
Last stable version: 0.6.3

$ ./docker push goldmann/f20
2013/09/27 09:40:46 POST /v1.5/images/goldmann/f20/push
The push refers to a repository [goldmann/f20] (len: 1)
Sending image list
Pushing repository goldmann/f20 (1 tags)
Pushing 5c47c08926951ad84aa164b300f13dc3ebfbb72b626163806415bbe7b3e30d2c


Pushing tags for rev [5c47c08926951ad84aa164b300f13dc3ebfbb72b626163806415bbe7b3e30d2c] on {https://registry-1.docker.io/v1/repositories/goldmann/f20/tags/latest}

It seems that the problem is that we use the system-wide tar which has some issues :( The dotcloud tar (which is removed by the docker-%{version}-remove-dotcloud-tar.patch) has the fix incorporated already. It seems that we need to package https://github.com/dotcloud/tar/ (maybe as golang-github-dotcloud-tar) and use it for docker.

Docker folks told us dotcloud/tar was a temporary fork, and it would be discarded once the patches were merged upstream, so would it still be preferred that we package it separately? I'm cool doing it either way.

Our version of golang includes those patches. Or, it should -- see #1010271. One issue here is that the golang package has differing release numbers across Fedora (and EPEL) releases -- 1.1.2-5 on rawhide, 1.1.2-3 on f20, 1.1.2-4 on f19 and el6. That means we'd need something complicated in our specfile rather than just "BuildRequires: golang >= 1.1.2-5". Maybe we can get Adam to bump them all to 6. :)

Packaging something that's going to be discarded soon will cause a lot of extra work for a lot of people, so I'd rather not do that.

Marek, can you make sure your package was built against the newest golang? The patches applied are the ones the Docker people told us are in their fork, but it's possible something is wrong with that

Oh, that's very unfortunate that the version in each golang branch (f19, f20, rawhide) are different (no matter what the reason is) - now we have no idea which version to use, since same patches are applied to different versions. This needs to be fixed.

I'm pretty sure I've compiled against golang-1.1.2-3.fc20. Unfortunately I cannot test this now, since I've encountered another bug, see bug 1013539.

I don't see this issue anymore with docker-io-0.7-0.13.dm.fc20.