@synack had a good debianization in a branch (better than the one in deb/ subdir)

#161 was implemented to support his effort

That'd be a Debian package as in compatible with Debian (stable?), or a Debian package for Ubuntu? 😅

Since the package includes an upstart configuration file (and the quick start also suggests to create on), I'd say it's Ubuntu specific.

@mdaniel could you clarify if this issue is for generic .deb creation, or
specifically for inclusion in the Debian distro? Thanks.

On Saturday, March 30, 2013, Mikhail Sobolev wrote:

Since the package includes an upstart configuration file (and the quick
start also suggests to create on), I'd say it's Ubuntu specific.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/251#issuecomment-15684958
.

Sorry meant @mzdaniel

On Saturday, March 30, 2013, Solomon Hykes wrote:

@mdaniel could you clarify if this issue is for generic .deb creation, or
specifically for inclusion in the Debian distro? Thanks.

On Saturday, March 30, 2013, Mikhail Sobolev wrote:

Since the package includes an upstart configuration file (and the quick
start also suggests to create on), I'd say it's Ubuntu specific.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/251#issuecomment-15684958
.

@shykes, gh issues have an edit feature :)

the keyword in the question was "compatible", how I took it: if the package is installed, can it be used right away on a Debian system. The answer is: no, you'd have to enable daemon start somehow.

@shykes: We are talking about Debian. We are currently looking for landing docker in the Unstable distro.

@oz: That'd be a Debian package compatible with Debian Wheezy (currently Testing distro)

@sa2ajj: Thank you so much, Mikhail, for implementing the Makefile! It is super useful for all developers and neatly done.

Changed title to clarify that issue #251 is for Debian, and issue #30 is for Ubuntu.

cc @paultag @mzdaniel what is missing to make this an official Debian package? Let us know if there's any way we can help.

Issue #396 has been solved in branch 396-disabling_memory_limit-feature. Thank you Guillaume!

As explained in issue #396, Wheesy Debian stock kernel does support limiting memory, only that needs a couple of kernel boot parameters as by default they are disabled. The parameter settings for properly enable kernel suport are:

cgroup_enable=memory swapaccount=1

Debian users can fully enjoy docker passing all its tests with standard Wheesy kernel adding the following parameters into their /boot/grub/grub.cfg:

linux /boot/vmlinuz-3.2.0-4-amd64 [other parameters] cgroup_enable=memory swapaccount=1

This implies that with good documentation, Debian Wheesy with no special packages fully support Docker

Debian package has been uploaded to https://mentors.debian.net/package/lxc-docker

The debian lxc-docker package had been uploaded to http://mentors.debian.net/package/lxc-docker using what it is on docker mainline /packaging/debian . There are a few loose ends at this point, including the need to rewrite /packaging/debian/Makefile logic into /packaging/debian/rules, aligned with debian go packaging guidelines. If you are interested in helping out we will have this package faster and all debian and downstream distros will benefit :)

On 06/07/2013 12:11 PM, Yaroslav Halchenko wrote:

...<

All fair questions! We are following the practice we use for
publishing PPA packages, which after installing building
dependencies (git debhelper build-essential autotools-dev devscripts
golang), boils down to:

git clone git://github.com/dotcloud/docker; cd
docker/packaging/debian; make debian

That will take care of generating all packaging files. For the PPA,
that's enough. Launchpad builders will take it from there. As you
point out, this is not quite the process debian uses. We have
already access rights and the next step is creating the proper repo.
Upstream is meant to have /packaging/debian as we highly prefer to
keep the root level clean and organized ( having /debian will
suggest we could have /ubuntu
/redhat /arch. It's much cleaner to have /packaging for packaging stuff :)

I hear you! I do...

but there are few "problems" with such an approach which would
keep such package at least "non-conventional" in Debian land:

• ideally Debian source package should not contain "generated"
  files but rather sources ... including the content of debian/ directory.

  the reason is simple -- maintenance of debian/ content.

  if someone introduces fixes and uploads via
  non-maintainer uploads, most probably those changes would be under
  debian/ and if debian/ itself is "derived" from some other location --
  it might get messy quickly

• people who 'debcheckout' (via Vcs- header fields in debian/control)
  expect getting some repository (possibly a branch) where debian/
  directory is already there so they could quickly tune it up and build
  package right away, e.g. via

  dpkg-buildpackage

  which is the standard way to build a debian package out of extracted
  sources (the actual standard is to e.g. call debian/rules binary
  -- to generate binary packages)

with original debian packaging residing somewhere under packaging/ --
things would get... non-standard to say the least. It should not
preclude upload to Debian proper, since Debian policy doesn't mandate
original VCS structure, but the fact would be that contribution by
debian community could be hindered...

FWIW -- just to share alternative ways -- it is common to go with
branches, i.e. I keep debian branch which adds debian/ directory with
packaging on top of "master"/releases content. That has pros and cons too

• pros: anyone could debcheckout (branch could be specified in vcs-git)
  and adjust packaging, build package right away

  it becomes clearer what was the released into Debian-land state of
  things (by last merge from master)

• cons: if releases come from release branches (and not from a single
  branch like master, or "releases") then merging into 'debian' branch
  could be tricky and requires some trickery (I usually create
  "releases" branch which "merge theirs" releases to be packaged)...

alternative resolution here could also be to have 'debian' branch as an
overlay -- containing just debian/ directory, and then use
git-buildpackage with overlay option (and specify that in
debian/gbp.conf). That one would happily overlay it on top of any
given branch/tarball and everyone would be happy... cons -- working with
such detached branch might be trickier too

just my .1c whatever they are worth

Thank you Yaroslav for sharing! I am curious to explore these
alternatives. Could you point us to a few projects to see these in action?

All fair questions! We are following the practice we use for
publishing PPA packages, which after installing building
dependencies (git debhelper build-essential autotools-dev devscripts
golang), boils down to:

git clone git://github.com/dotcloud/docker; cd
docker/packaging/debian; make debian

That will take care of generating all packaging files. For the PPA,
that's enough. Launchpad builders will take it from there. As you
point out, this is not quite the process debian uses. We have
already access rights and the next step is creating the proper repo.
Upstream is meant to have /packaging/debian as we highly prefer to
keep the root level clean and organized ( having /debian will
suggest we could have /ubuntu
/redhat /arch. It's much cleaner to have /packaging for packaging stuff :)

I hear you! I do...

but there are few "problems" with such an approach which would
keep such package at least "non-conventional" in Debian land:

• ideally Debian source package should not contain "generated"
  files but rather sources ... including the content of debian/ directory.

  the reason is simple -- maintenance of debian/ content.

  if someone introduces fixes and uploads via
  non-maintainer uploads, most probably those changes would be under
  debian/ and if debian/ itself is "derived" from some other location --
  it might get messy quickly

• people who 'debcheckout' (via Vcs- header fields in debian/control)
  expect getting some repository (possibly a branch) where debian/
  directory is already there so they could quickly tune it up and build
  package right away, e.g. via

  dpkg-buildpackage

  which is the standard way to build a debian package out of extracted
  sources (the actual standard is to e.g. call debian/rules binary
  -- to generate binary packages)

with original debian packaging residing somewhere under packaging/ --
things would get... non-standard to say the least. It should not
preclude upload to Debian proper, since Debian policy doesn't mandate
original VCS structure, but the fact would be that contribution by
debian community could be hindered...

FWIW -- just to share alternative ways -- it is common to go with
branches, i.e. I keep debian branch which adds debian/ directory with
packaging on top of "master"/releases content. That has pros and cons too

• pros: anyone could debcheckout (branch could be specified in vcs-git)
  and adjust packaging, build package right away

  it becomes clearer what was the released into Debian-land state of
  things (by last merge from master)

• cons: if releases come from release branches (and not from a single
  branch like master, or "releases") then merging into 'debian' branch
  could be tricky and requires some trickery (I usually create
  "releases" branch which "merge theirs" releases to be packaged)...

alternative resolution here could also be to have 'debian' branch as an
overlay -- containing just debian/ directory, and then use
git-buildpackage with overlay option (and specify that in
debian/gbp.conf). That one would happily overlay it on top of any
given branch/tarball and everyone would be happy... cons -- working with
such detached branch might be trickier too

just my .1c whatever they are worth

Thank you Yaroslav for sharing! I am curious to explore these
alternatives. Could you point us to a few projects to see these in
action?

btw - 1 more point why eventually you would need to branch anyways.
E.g. if some version in Debian stable would need to be fixed -- so you
would need to get back to that point and branch off

1. debian (or alike) branch with merges of the main code branch

   a. where all releases come from 'master' branch so merging into
   debian branch becomes easy -- examples are numerous, but let me point
   to our own project:

   https://github.com/PyMVPA/PyMVPA/tree/dist/debian/proper/sid

   so here we named branch not simply "debian" but rather
   "dist/debian/proper/sid", since we might also need to upload bug fix
   package releases to debian stable, and then it would become
   "dist/debian/proper/wheezy".

   'proper' was there because we thought we might need a special branch
   for neurodebian repository backports (http://neuro.debian.net/) but
   that never got to be the case (we ship patches for backporting within
   the same dist/debian/proper/sid under debian/patches)

   b. if releases come from "release branches", so merging into "debian"
   branch becomes tricky, I created 'releases' branch for sklearn

   http://github.com/yarikoptic/scikit-learn

   for merges into "releases" branch I use following git alias

   To overcome absence of "ours" strategy in git merge

   mtheirs = !sh -c 'git merge -s ours --no-commit $1 && git read-tree -m -u "$1"' -

   so I do smth like

   git checkout releases
   git mtheirs RELEASE-TAG
   git checkout debian
   git merge releases

   note that you can always got from a. to more complicated b.

2. debian branch carries only debian/ directory

   well -- there is a lot of "debian packaging" projects which use this strategy,
   and usually they are still under SVN... here might be an example on how it would look

   http://anonscm.debian.org/gitweb/?p=pkg-exppsy/python-traits4.git

   but probably it is not the convenient one for your case.

Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Senior Research Associate, Psychological and Brain Sciences Dept.
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik

Just a quick note, the correct way to add the kernel params "cgroup_enable=memory swapaccount=1" would be to edit the /etc/default/grub:

GRUB_CMDLINE_LINUX="cgroup_enable=memory swapaccount=1"

This way it get's added to all the kernels when the grub.cfg file is regenerated. It's not a good practice to edit grub.cfg file directly seeing as it's a generated file.

Thank you for the note @denibertovic. I am not convinced this is a good idea. Modifying system files is a big deal and we might be even breaking packaging guidelines in doing so. FWIW, our documentation already addresses the issue: http://docs.docker.io/en/latest/installation/kernel.

@mzdaniel I was merely referring to the comment in this pull request that suggested modifying the grub.cfg file directly. I did not mean to imply that this should be done in the packaging.

Thanks for the link to the docs as i was not aware that the correct way to modify kernel parameters was already outlined there.

Thank you for sharing all this wealth of information, Yaroslav. I've got
to admit I was a little confused about so many different ways to go
about packaging, until you mention git-buildpackage and I saw you are
using it on https://github.com/PyMVPA/PyMVPA . Thank you so much for
pointing that out!
The other side of packaging docker has been understanding how to do
proper packaging of go libraries. Michael Stapelberg has done an amazing
job in this area and together we currently reviewing the first docker
library dependency for an unstable release:
http://mentors.debian.net/package/golang-mux-dev
http://anonscm.debian.org/gitweb/?p=collab-maint/golang-mux-dev.git;a=summary
So, it looks that now we are on firm track to release docker in a no
distant moment.

On 06/17/2013 11:45 AM, Yaroslav Halchenko wrote:

FWIW -- just to share alternative ways -- it is common to go with
branches, i.e. I keep debian branch which adds debian/ directory with
packaging on top of "master"/releases content. That has pros and cons too

• pros: anyone could debcheckout (branch could be specified in vcs-git)
  and adjust packaging, build package right away

  it becomes clearer what was the released into Debian-land state of
  things (by last merge from master)

• cons: if releases come from release branches (and not from a single
  branch like master, or "releases") then merging into 'debian' branch
  could be tricky and requires some trickery (I usually create
  "releases" branch which "merge theirs" releases to be packaged)...

alternative resolution here could also be to have 'debian' branch as an
overlay -- containing just debian/ directory, and then use
git-buildpackage with overlay option (and specify that in
debian/gbp.conf). That one would happily overlay it on top of any
given branch/tarball and everyone would be happy... cons -- working with
such detached branch might be trickier too

just my .1c whatever they are worth

Thank you Yaroslav for sharing! I am curious to explore these
alternatives. Could you point us to a few projects to see these in
action?

btw - 1 more point why eventually you would need to branch anyways.
E.g. if some version in Debian stable would need to be fixed -- so you
would need to get back to that point and branch off

1. debian (or alike) branch with merges of the main code branch

   a. where all releases come from 'master' branch so merging into
   debian branch becomes easy -- examples are numerous, but let me point
   to our own project:

   https://github.com/PyMVPA/PyMVPA/tree/dist/debian/proper/sid

   so here we named branch not simply "debian" but rather
   "dist/debian/proper/sid", since we might also need to upload bug fix
   package releases to debian stable, and then it would become
   "dist/debian/proper/wheezy".

   'proper' was there because we thought we might need a special branch
   for neurodebian repository backports (http://neuro.debian.net/) but
   that never got to be the case (we ship patches for backporting within
   the same dist/debian/proper/sid under debian/patches)

   b. if releases come from "release branches", so merging into "debian"
   branch becomes tricky, I created 'releases' branch for sklearn

   http://github.com/yarikoptic/scikit-learn

   for merges into "releases" branch I use following git alias

   To overcome absence of "ours" strategy in git merge

   mtheirs = !sh -c 'git merge -s ours --no-commit $1&& git read-tree -m -u "$1"' -

   so I do smth like

   git checkout releases
   git mtheirs RELEASE-TAG
   git checkout debian
   git merge releases

   note that you can always got from a. to more complicated b.

2. debian branch carries only debian/ directory

   well -- there is a lot of "debian packaging" projects which use this strategy,
   and usually they are still under SVN... here might be an example on how it would look

   http://anonscm.debian.org/gitweb/?p=pkg-exppsy/python-traits4.git

   but probably it is not the convenient one for your case.

On Tue, 09 Jul 2013, Daniel Mizyrycki wrote:

Thank you for sharing all this wealth of information, Yaroslav. I've
got to admit I was a little confused about so many different ways to
go about packaging, until you mention git-buildpackage and I saw you
are using it on https://github.com/PyMVPA/PyMVPA .

Sorry for being confusing -- but that is the realm of things in Debian: Debian
policy clearly specifies only the state of binary and source packages, but
internal "housekeeping" is up for the developers/teams to decide. And having
thousands of people working on Debian, and coming from different fields,
use-cases and work patterns, different people/teams have different approaches
on how to organize their package maintenance. Tools such as git-build-package
help to standardize flows while allowing for so demanded flexibility (e.g. I
use overlay setups for some projects but not the others etc)

Thank you so much
for pointing that out!
The other side of packaging docker has been understanding how to do
proper packaging of go libraries. Michael Stapelberg has done an
amazing job in this area and together we currently reviewing the
first docker library dependency for an unstable release:
http://mentors.debian.net/package/golang-mux-dev
http://anonscm.debian.org/gitweb/?p=collab-maint/golang-mux-dev.git;a=summary
So, it looks that now we are on firm track to release docker in a no
distant moment.

That all sounds great, thank you Daniel for the follow up! I am glad I
could have been of help, and yes -- I do use git-buildpackage quite
extensively. While we are at it I might recommend also some
generic customizations I use

$> cat ~/.gbp.conf
[git-buildpackage]
sign-tags = True

use this for more svn-buildpackage like bahaviour:

export-dir = ../build-area/
tarball-dir = ../tarballs/

so -- git-buildpackage always builds for me in a clean checkout under export-dir.
and signing the tags is also quite neat

Cheers!

Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Senior Research Associate, Psychological and Brain Sciences Dept.
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik

More progress towards debian lxc-docker package:

Promoted to debian new queue:
http://ftp-master.debian.org/new/golang-pty-dev_0.0~git20130701-1.html
http://ftp-master.debian.org/new/golang-mux-dev_0.0~git20130701-1.html

In current review by our debian sponsors:
http://anonscm.debian.org/gitweb/?p=collab-maint/golang-context-dev.git
http://anonscm.debian.org/gitweb/?p=collab-maint/lxc-docker.git

Great news Daniel! Don't forget to move the debian stuff to github.com/dotcloud/docker-debian so we can refactor upstream.
​
Thanks 

—
@solomonstre
@getdocker

On Sat, Jul 27, 2013 at 9:02 PM, Daniel Mizyrycki
[email protected] wrote:

More progress towards debian lxc-docker package:
Promoted to debian new queue:
http://ftp-master.debian.org/new/golang-pty-dev_0.0~git20130701-1.html
http://ftp-master.debian.org/new/golang-mux-dev_0.0~git20130701-1.html
In current review by our debian sponsors:
http://anonscm.debian.org/gitweb/?p=collab-maint/golang-context-dev.git

http://anonscm.debian.org/gitweb/?p=collab-maint/lxc-docker.git

Reply to this email directly or view it on GitHub:
#251 (comment)

Most pieces are in place now. github.com/dotcloud/docker-debian has been created, and golang-mux-dev and golang-pty-dev are now official part of the Debian repository on sid.
Here is a rough list of commands to build lxc-docker package assuming a sid system with the dependencies listed in debian/control plus git-buildpackage.

git clone https://github.com/dotcloud/docker-debian.git -b draft-master
( cd docker-debian; git-buildpackage --git-arch=all --git-pristine-tar-commit --git-ignore-branch )

As update: the last dependency, golang-context-dev is now in the Debian repo. http://packages.debian.org/search?keywords=golang-context-dev
The Docker Debian package has been updated to 0.5.3 on both http://anonscm.debian.org/gitweb/?p=collab-maint/lxc-docker.git and https://github.com/dotcloud/docker-debian

The last piece of the puzzle is to add the ability to compile docker go code in the Debian builders without needing root. This might require changes in the Debian golang package.

@mzdaniel in case it's related to having write access to GOROOT (/usr/lib/go) for the go test / go install, Gentoo has a similar issue and I'm solving it with a temporary copy of GOROOT and then changing the GOROOT environment variable to the temporary copy during compile so we can make sure our docker binary is completely static, in case a similar approach might work here (currently being discussed on #1847).

If it's not really related, my apologies.

What's the status of this issue now? git-buildpackage from https://github.com/dotcloud/docker-debian.git (master branch) failed for me with the error "fatal: Not a valid object name upstream/0.5.3+ds1" - is anonscm now the canonical place to build this deb from?

If there's a mirror on non-Debian services, there should be code to keep it
in sync with the Debian services.

Be aware there's a DFSG repack, so please use uscan to download the tarball

On Fri, Nov 1, 2013 at 11:38 AM, Tim Pierce [email protected]:

What's the status of this issue now? git-buildpackage from
https://github.com/dotcloud/docker-debian.git (master branch) failed for
me with the error "fatal: Not a valid object name upstream/0.5.3+ds1" - is
anonscm now the canonical place to build this deb from?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/251#issuecomment-27574518
.

:wq

ping @mzdaniel Don't we have a deb package now?

I'm working on an official one today.
On Nov 29, 2013 4:43 PM, "Michael Crosby" [email protected] wrote:

ping @mzdaniel https://github.com/mzdaniel Don't we have a deb package
now?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/251#issuecomment-29538662
.

Our get.docker.io repo/package works on Debian, we just need to update the documentation to reflect that.

And as Paul mentioned, we are almost downstream properly too. :)

You also need a Debian icon on the front of https://www.docker.io/gettingstarted/ ;)

What's the status on this one? Do you need help in any way (writing up the docs or something like that?)

For reference, the ITP is being tracked at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706060 and it looks like it is currently waiting for golang-sqlite3-dev.

The latest status update for official Debian packaging is that we're finally in NEW: https://ftp-master.debian.org/new/docker.io_0.6.7+dfsg1-1.html

🍰

awesome work everyone! 👍

👍