Binary installation was broken after the
hack/dockerfile/install-binaries script was removed.
This remedies that.
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Upstream-commit: 59164bedeab571029805a107e8e5a32fc9cd56b3
Component: packaging
Zesty is EOL and doesn't even have a subdirectory in the `deb` directory of this repo. There's no need to have it as a default.
Signed-off-by: Corbin <corbin.coleman@docker.com>
Upstream-commit: 9b3e8f85f039dfe7391512de6143ef213574973a
Component: packaging
This fixes a vulnerability in `go get` (CVE-2018-6574, http://golang.org/issue/23672),
but shouldn't really affect our code, but it's good to keep in sync.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 6263b1254b179af81ff4ef97563fe2e1a053993a
Component: packaging
Dev builds for debian packages previously had system time inserted into
their packaging names while both static and rpm builds instead had the
git commit time.
This commit remedies that by pushing the generation of the debian
package version into a separate script to mirror what is being done in
static and rpm builds.
To give you an idea of what it looks like take the following examples:
```
❯ ./gen-deb-ver ~/work/docker-ce/components/engine/ $(cat ~/work/docker-ce/VERSION)
18.03.0~ce~dev~git20180202.170651.0.e232737
```
```
❯ ./gen-rpm-ver ~/work/docker-ce/components/engine $(cat ~/work/docker-ce/VERSION)
18.03.0.ce 0.0.dev.git20180202.170651.0.e232737 e232737
```
```
❯ ./gen-static-ver ~/work/docker-ce/components/engine/ $(cat ~/work/docker-ce/VERSION)
18.03.0-ce-dev-20180202.170651-e232737
```
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Upstream-commit: 23e3e42df6cb4e5cafd8648344ad37de25002971
Component: packaging
Adds git date plus git commit sha to static builds if the version being
built for is a development version
Output is similar to: `docker-18.02.0-ce-dev-20180120.170357-fa4fb35.tgz`
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Upstream-commit: 8a86c3a6a54760b19cd67854bf68e408bd2a17fb
Component: packaging
Since systemd version 228, a new setting, `TasksMax`, has appeared,
which limits the number of tasks used by a service (via pids cgroup
controller). Unfortunately, a default for this setting, `DefaultTaskMax`,
is set to 512. In systemd version 231 it is changed to 15% which
practically is 4195, as the value from /proc/sys/kernel/pid_max is
treated like 100%).
Either 512 or 4195 is severily limited value for Docker Engine,
as it can run thousands of containers with thousands of tasks in each,
and the number of tasks limit should be set on a per-container basis
by the Docker user. So, the most reasonable setting for `TasksMax`
is `unlimited`.
Unfortunately, older versions of systemd warn about unknown `TasksMax`
parameter in `docker.service` file, and the warning is rather annoying,
therefore this setting is commented out by default, and is supposed
to be uncommented by the user.
The problem with that is, once the limit is hit, all sorts of bad things
happen and it's not really clear even to an advanced user that this
setting is the source of issues.
Now, `rules` file already contain a hack to check for the systemd
version (during build time) and in case the version is greater than 227,
uncomment the `TasksMax=unlimited` line. Alas, it does not work
during normal builds, the reason being systemd is not installed
into build environments.
An obvious fix would be to add systemd to the list of installed
packages in all Dockerfiles used to build debs. Fortunately,
there is a simpler way, as libsystemd-dev is installed, and
it's a subpackage of systemd built from the same source and
carrying the same version, so it can also be checked.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Upstream-commit: d80738e4b4459816c64757a2a63e5d8058d0ccf4
Component: packaging
Since systemd version 228, a new setting, `TasksMax`, has appeared, which
limits the number of tasks used by a service (via pids cgroup
controller). Unfortunately, a default for this setting, `DefaultTaskMax`,
is set to 512. In systemd version 231 it is changed to 15% which
practically is 4195, as the value from /proc/sys/kernel/pid_max is
treated like 100%).
Either 512 or 4195 is severily limited value for Docker Engine, as it
can run thousands of containers with thousands of tasks in each, and
the number of tasks limit should be set on a per-container basis by the
Docker user. So, the most reasonable setting for `TasksMax` is `unlimited`.
Unfortunately, older versions of systemd warn about unknown `TasksMax`
parameter in `docker.service` file, and the warning is rather annoying,
therefore this setting is commented out by default, and is supposed to
be uncommented by the user.
The problem with that is, once the limit is hit, all sorts of bad things
happen and it's not really clear even to an advanced user that this
setting is the source of issues.
As Fedora 25 ships systemd 231, it (and later Fedora releases) support
TasksMax, so it makes total sense to uncomment the setting, this is what
this commit does.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Upstream-commit: 9055832bb0725f05d518c3ebc9b7cc93a69420c7
Component: packaging
-dev was being removed, per legacy code, but we'd like to add it back
into the naming so that deb / rpm packages will look mostly the same
when compiled with a `-dev` version.
RPMS end up looking like:
docker-ce-18.02.0.ce-0.0.dev.git20180120.170357.0.fa4fb35.el7.centos.x86_64.rpm
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Upstream-commit: 65e2c3cf9ff8c3130e628a455e3d02921876cdfc
Component: packaging
This change is in response to https://github.com/moby/moby/pull/35697
It adds pigz to the recommended binaries that should be installed with
docker-ce.
Signed-off-by: Sargun Dhillon <sargun@sargun.me>
Upstream-commit: 1ca014b9440a92b46e2e03d879c03ddc5c51d4c0
Component: packaging
Was getting annoying to have to write it into one spot so moved them to
above the targets that they specify.
Signed-off-by: Eli Uriegas <seemethere101@gmail.com>
Upstream-commit: a8e527df5d6579cc53372c26ef86fdcf449aa9ae
Component: packaging
VERSION file does not exist anymore for moby/moby so we need to
compensate
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Upstream-commit: c411321b8870101c227b03e64930260984c862fd
Component: packaging
Relates to an upgrade in `rpm` to `14.4.0`, where missing build-ids now
cause builds to self-terminate. May be needed in other distros if/when
the `rpm` package is updated in those repos.
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Upstream-commit: dcd681da54f2c2b2286cc09d053dd6cb865d3f98
Component: packaging
When building we should default to a dummy version unless otherwise
specified so we don't get ourselves confused over what is official and
what is not.
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Upstream-commit: ffcd040b5c3bd4f81e1d1f11c32f9bb81e235ed1
Component: packaging
Failed out otherwise:
```
---> Making bundle: dynbinary (in bundles/dynbinary)
Building: bundles/dynbinary-daemon/dockerd-17.09.0-dev
Package libudev was not found in the pkg-config search path.
```
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Upstream-commit: 4d8e8855d1008f4705ea6db17e5cd5bc90bd2d81
Component: packaging
Seems `docker-edge` was removed as label on jenkins.dockerproject.org.
This removes that label and just puts the x86_64 label
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Upstream-commit: 6765382587e31a93b1e65d2d169b00a42d183ee2
Component: packaging
* add aarch64 support
* use go 1.9 for arm64 support
* fixtypo
* add backports on jessie
* fix path
* delet yakkety
* rm golang-go
* use arm64v8/ images
* fix error made in merge
* remove double architecture
* use arm64v8/
* use go 1.8.5
* Update aarch64 builds to 1.9.2
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Upstream-commit: 03eac425534002445e666ce0352f1c666151dc89
Component: packaging
Setting to something that will not be confused with a version number
that will ever be released. Also, this is required for the deb packages
to build properly
Signed-off-by: Andrew Hsu <andrewhsu@docker.com>
Upstream-commit: 0de78bd1251958a9d8916c3944b8f51d0ffb49b7
Component: packaging
