Tonis Tiigi
81f2f2c3d5
With docker-17.06.0 some images pulled do not extract properly. Some files don't appear in correct directories. This may or may not cause the pull to fail. These images can't be pushed or saved. 17.06 is the first version of Docker built with go1.8. Cause There are multiple updates to the tar package in go1.8. https://go-review.googlesource.com/c/32234/ disables using "prefix" field when new tar archives are being written. Prefix field was previously set when a record in the archive used a path longer than 100 bytes. Another change https://go-review.googlesource.com/c/31444/ makes the reader ignore the "prefix" field value if the record is in GNU format. GNU format defines that same area should be used for access and modified times. If the "prefix" field is not read, a file will only be extracted by the basename. The problem is that with a previous version of the golang archive package headers could be written, that use the prefix field while at the same time setting the header format to GNU. This happens when numeric fields are big enough that they can not be written as octal strings and need to be written in binary. Usually, this shouldn't happen: uid, gid, devmajor, devminor can use up to 7 bytes, size and timestamp can use 11. If one of the records does overflow it switches the whole writer to GNU mode and all next files will be saved in GNU format. Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>(cherry picked from commit 4a3cfda45e37b81211fbfbf0c45dbe64860a3ad0) Signed-off-by: Andrew Hsu <andrewhsu@docker.com>
Docker CE
This repository hosts open source components of Docker Community Edition
(CE) products. The master branch serves to unify the upstream components
on a regular basis. Long-lived release branches host the code that goes
into a product version for the lifetime of the product.
This repository is solely maintained by Docker, Inc.
Unifying upstream sources
The master branch is a combination of components adapted from
different upstream git repos into a unified directory structure using the
moby-components
tool.
You can view the upstream git repos in the components.conf file. Each component is isolated into its own directory under the components directory.
The tool will import each component git history within the appropriate path.
For example, this shows a commit
is imported into the component engine from
moby/moby@a27b4b8
into the components/engine directory.
commit 5c70746915d4589a692cbe50a43cf619ed0b7152
Author: Andrea Luzzardi <aluzzardi@gmail.com>
Date: Sat Jan 19 00:13:39 2013
Initial commit
Upstream-commit: a27b4b8cb8e838d03a99b6d2b30f76bdaf2f9e5d
Component: engine
components/engine/container.go | 203 ++++++++++++++++++++++++++++...
components/engine/container_test.go | 186 ++++++++++++++++++++++++++++...
components/engine/docker.go | 112 ++++++++++++++++++++++++++++...
components/engine/docker_test.go | 175 ++++++++++++++++++++++++++++...
components/engine/filesystem.go | 52 ++++++++++++++++++++++++++++...
components/engine/filesystem_test.go | 35 +++++++++++++++++++++++++++
components/engine/lxc_template.go | 94 ++++++++++++++++++++++++++++...
components/engine/state.go | 48 ++++++++++++++++++++++++++++...
components/engine/utils.go | 115 ++++++++++++++++++++++++++++...
components/engine/utils_test.go | 126 ++++++++++++++++++++++++++++...
10 files changed, 1146 insertions(+)
Updates to master branch
Main development of new features should be directed towards the upstream
git repos. The master branch of this repo will periodically pull in new
changes from upstream to provide a point for integration.
Branching for release
When a release is started for Docker CE, a new branch will be created
from master. Branch names will be YY.MM to represent the time-based
release version of the product, e.g. 17.06.
Adding fixes to release branch
Note: every commit of a fix should affect files only within one component directory.
Fix available upstream
A PR cherry-picking the necessary commits should be created against the release branch. If the the cherry-pick cannot be applied cleanly, the logic of the fix should be ported manually.
No fix yet
First create the PR with the fix for the release branch. Once the fix has been merged, be sure to port the fix to the respective upstream git repo.
Release tags
There will be a git tag for each release candidate (RC) and general availablilty (GA) release. The tag will only point to commits on release branches.