Debian Bug report logs - #706060
ITP: lxc-docker -- the Linux container runtime

version graph

Package: wnpp; Maintainer for wnpp is wnpp@debian.org;

Reported by: Daniel Mizyrycki <daniel.mizyrycki@dotcloud.com>

Date: Wed, 24 Apr 2013 05:33:07 UTC

Owned by: Daniel Mizyrycki <daniel@dotcloud.com>

Severity: wishlist

Merged with 730569

Fixed in version docker.io/0.6.7+dfsg1-1

Done: Paul Tagliamonte <paultag@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org, wnpp@debian.org, Daniel Mizyrycki <daniel@dotcloud.com>:
Bug#706060; Package wnpp. (Wed, 24 Apr 2013 05:33:12 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Mizyrycki <daniel.mizyrycki@dotcloud.com>:
New Bug report received and forwarded. Copy sent to debian-devel@lists.debian.org, wnpp@debian.org, Daniel Mizyrycki <daniel@dotcloud.com>.

Your message had a Version: pseudo-header with an invalid package version:

N/A; reported 2013-04-23

please either use found or fixed to the control server with a correct version, or reply to this report indicating the correct version so the maintainer (or someone else) can correct it for you.

(Wed, 24 Apr 2013 05:33:12 GMT) Full text and rfc822 format available.


Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Daniel Mizyrycki <daniel.mizyrycki@dotcloud.com>
To: submit@bugs.debian.org
Subject: ITP: lxc-docker -- the Linux container runtime
Date: Tue, 23 Apr 2013 22:30:52 -0700
Package: wnpp
Version: N/A; reported 2013-04-23
Severity: wishlist
Owner: Daniel Mizyrycki <daniel@dotcloud.com>
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name : lxc-docker
Version : 0.1.8
Upstream Author : dotCloud Inc <opensource@dotcloud.com>
* URL : http://github.com/dotcloud/docker
* License : Apache-2.0
Description : Docker: the Linux container runtime

Docker complements LXC with a high-level API which operates at the
process level. It runs unix processes with strong guarantees of
isolation and repeatability across servers.
Docker is a great building block for automating distributed systems:
large-scale web deployments, database clusters, continuous deployment
systems, private PaaS, service-oriented architectures, etc.



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Daniel Mizyrycki <daniel@dotcloud.com>:
Bug#706060; Package wnpp. (Fri, 07 Jun 2013 02:12:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yaroslav Halchenko <debian@onerussian.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Daniel Mizyrycki <daniel@dotcloud.com>. (Fri, 07 Jun 2013 02:12:04 GMT) Full text and rfc822 format available.

Message #10 received at 706060@bugs.debian.org (full text, mbox):

From: Yaroslav Halchenko <debian@onerussian.com>
To: Daniel Mizyrycki <daniel.mizyrycki@dotcloud.com>, 706060@bugs.debian.org, dotCloud <ops@dotcloud.com>
Subject: so how is ITP going?
Date: Thu, 6 Jun 2013 22:09:57 -0400
Hi Daniel, Hi Ops,

I wonder if you are still interested to finalize packaging for the
upload to proper Debian?  

I see that PPA has some packages (check lintian *.dsc for minor
tweeks TODO; also probably there is no reason for duplicate
{,src/}github.com/docker; copyright seems to be missing info on
./src/github.com/gorilla/; may be more...) -- but is there anything
holding you up really? ;)

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        



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Daniel Mizyrycki <daniel@dotcloud.com>:
Bug#706060; Package wnpp. (Fri, 07 Jun 2013 15:33:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Mizyrycki <daniel.mizyrycki@dotcloud.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Daniel Mizyrycki <daniel@dotcloud.com>. (Fri, 07 Jun 2013 15:33:08 GMT) Full text and rfc822 format available.

Message #15 received at 706060@bugs.debian.org (full text, mbox):

From: Daniel Mizyrycki <daniel.mizyrycki@dotcloud.com>
To: Yaroslav Halchenko <debian@onerussian.com>, 706060@bugs.debian.org
Cc: Daniel Mizyrycki <daniel.mizyrycki@dotcloud.com>, dotCloud <ops@dotcloud.com>
Subject: Re: Bug#706060: so how is ITP going?
Date: Fri, 07 Jun 2013 08:28:03 -0700
Thank you for wondering!
As you might know, lxc-docker debian package is pretty much ready: 
http://mentors.debian.net/package/lxc-docker and I've been advocating 
for inclusion in unstable. Paul Tagliamonte, our awesome DD, and I have 
been closely working together. We need to rebump the way we generate the 
package to be more in line with Debian policies.

On 06/06/2013 07:09 PM, Yaroslav Halchenko wrote:
> Hi Daniel, Hi Ops,
>
> I wonder if you are still interested to finalize packaging for the
> upload to proper Debian?
You bet!

> I see that PPA has some packages (check lintian *.dsc for minor
> tweeks TODO; also probably there is no reason for duplicate
> {,src/}github.com/docker; copyright seems to be missing info on
> ./src/github.com/gorilla/; may be more...) -- but is there anything
> holding you up really? ;)
Yep, those are minor issues. The mayor one is to move the 
debian/Makefile to debian/rules with new logic, aligned with debian go 
packaging guidelines.
If are you interested in helping out, we will have the debian packaging 
faster :)

>
> Cheers,




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Daniel Mizyrycki <daniel@dotcloud.com>:
Bug#706060; Package wnpp. (Fri, 07 Jun 2013 15:39:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yaroslav Halchenko <debian@onerussian.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Daniel Mizyrycki <daniel@dotcloud.com>. (Fri, 07 Jun 2013 15:39:05 GMT) Full text and rfc822 format available.

Message #20 received at 706060@bugs.debian.org (full text, mbox):

From: Yaroslav Halchenko <debian@onerussian.com>
To: Daniel Mizyrycki <daniel.mizyrycki@dotcloud.com>
Cc: 706060@bugs.debian.org, dotCloud <ops@dotcloud.com>
Subject: Re: Bug#706060: so how is ITP going?
Date: Fri, 7 Jun 2013 11:34:34 -0400
> Thank you for wondering!
> As you might know, lxc-docker debian package is pretty much ready:
> http://mentors.debian.net/package/lxc-docker and I've been
> advocating for inclusion in unstable. Paul Tagliamonte, our awesome
> DD, and I have been closely working together. We need to rebump the
> way we generate the package to be more in line with Debian policies.

ha cool -- lazy me forgotten to check mentors (usually it is a good
practice to send such updates to the corresponding ITP bug so people
know where to look)


> >I see that PPA has some packages (check lintian *.dsc for minor
> >tweeks TODO; also probably there is no reason for duplicate
> >{,src/}github.com/docker; copyright seems to be missing info on
> >./src/github.com/gorilla/; may be more...) -- but is there anything
> >holding you up really? ;)
> Yep, those are minor issues. The mayor one is to move the
> debian/Makefile to debian/rules with new logic, aligned with debian
> go packaging guidelines.
> If are you interested in helping out, we will have the debian
> packaging faster :)

oki doki

looking at
http://mentors.debian.net/debian/pool/main/l/lxc-docker/lxc-docker_0.3.2-1.dsc
and trying to

$> git clone git://git.debian.org/git/collab-maint/lxc-docker.git
Cloning into 'lxc-docker'...
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

so where is the beast? ;)

in your stock repo on github I do not see any new 'debian' branch with
just 'debian/'... I see only "old" packaging/debian/ only

so where/how to look?  

-- 
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        



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Daniel Mizyrycki <daniel@dotcloud.com>:
Bug#706060; Package wnpp. (Fri, 07 Jun 2013 18:42:16 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Mizyrycki <daniel.mizyrycki@dotcloud.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Daniel Mizyrycki <daniel@dotcloud.com>. (Fri, 07 Jun 2013 18:42:16 GMT) Full text and rfc822 format available.

Message #25 received at 706060@bugs.debian.org (full text, mbox):

From: Daniel Mizyrycki <daniel.mizyrycki@dotcloud.com>
To: Yaroslav Halchenko <debian@onerussian.com>
Cc: Daniel Mizyrycki <daniel.mizyrycki@dotcloud.com>, 706060@bugs.debian.org, docker-club <docker-club+packaging@googlegroups.com>
Subject: [packaging] Re: Bug#706060: so how is ITP going?
Date: Fri, 07 Jun 2013 11:40:50 -0700
Sweet!

On 06/07/2013 08:34 AM, Yaroslav Halchenko wrote:
>> Thank you for wondering!
>> As you might know, lxc-docker debian package is pretty much ready:
>> http://mentors.debian.net/package/lxc-docker and I've been
>> advocating for inclusion in unstable. Paul Tagliamonte, our awesome
>> DD, and I have been closely working together. We need to rebump the
>> way we generate the package to be more in line with Debian policies.
>
> ha cool -- lazy me forgotten to check mentors (usually it is a good
> practice to send such updates to the corresponding ITP bug so people
> know where to look)
Good point. CC: is taking care of it now. :)  Thanks!

>>> I see that PPA has some packages (check lintian *.dsc for minor
>>> tweeks TODO; also probably there is no reason for duplicate
>>> {,src/}github.com/docker; copyright seems to be missing info on
>>> ./src/github.com/gorilla/; may be more...) -- but is there anything
>>> holding you up really? ;)
>> Yep, those are minor issues. The mayor one is to move the
>> debian/Makefile to debian/rules with new logic, aligned with debian
>> go packaging guidelines.
>> If are you interested in helping out, we will have the debian
>> packaging faster :)
>
> oki doki
>
> looking at
> http://mentors.debian.net/debian/pool/main/l/lxc-docker/lxc-docker_0.3.2-1.dsc
> and trying to
>
> $>  git clone git://git.debian.org/git/collab-maint/lxc-docker.git
> Cloning into 'lxc-docker'...
> fatal: Could not read from remote repository.
>
> Please make sure you have the correct access rights
> and the repository exists.
>
> so where is the beast? ;)
>
> in your stock repo on github I do not see any new 'debian' branch with
> just 'debian/'... I see only "old" packaging/debian/ only
>
> so where/how to look?
>
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 :)




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Daniel Mizyrycki <daniel@dotcloud.com>:
Bug#706060; Package wnpp. (Fri, 07 Jun 2013 19:15:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yaroslav Halchenko <yarikoptic@gmail.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Daniel Mizyrycki <daniel@dotcloud.com>. (Fri, 07 Jun 2013 19:15:04 GMT) Full text and rfc822 format available.

Message #30 received at 706060@bugs.debian.org (full text, mbox):

From: Yaroslav Halchenko <yarikoptic@gmail.com>
To: Daniel Mizyrycki <daniel.mizyrycki@dotcloud.com>
Cc: 706060@bugs.debian.org, docker-club <docker-club+packaging@googlegroups.com>
Subject: Re: [packaging] Re: Bug#706060: so how is ITP going?
Date: Fri, 7 Jun 2013 15:11:30 -0400
> >>...<

> 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
-- 
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        



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Daniel Mizyrycki <daniel@dotcloud.com>:
Bug#706060; Package wnpp. (Sat, 15 Jun 2013 03:42:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Mizyrycki <daniel.mizyrycki@dotcloud.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Daniel Mizyrycki <daniel@dotcloud.com>. (Sat, 15 Jun 2013 03:42:05 GMT) Full text and rfc822 format available.

Message #35 received at 706060@bugs.debian.org (full text, mbox):

From: Daniel Mizyrycki <daniel.mizyrycki@dotcloud.com>
To: Yaroslav Halchenko <yarikoptic@gmail.com>, 706060@bugs.debian.org
Cc: Daniel Mizyrycki <daniel.mizyrycki@dotcloud.com>, reply+i-12595695-18a5438565896eb9ee444effaa4bf2291790e300-68684@reply.github.com
Subject: Re: Bug#706060: [packaging] Re: Bug#706060: so how is ITP going?
Date: Fri, 14 Jun 2013 20:37:58 -0700
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?




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Daniel Mizyrycki <daniel@dotcloud.com>:
Bug#706060; Package wnpp. (Mon, 17 Jun 2013 18:48:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yaroslav Halchenko <yarikoptic@gmail.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Daniel Mizyrycki <daniel@dotcloud.com>. (Mon, 17 Jun 2013 18:48:09 GMT) Full text and rfc822 format available.

Message #40 received at 706060@bugs.debian.org (full text, mbox):

From: Yaroslav Halchenko <yarikoptic@gmail.com>
To: Daniel Mizyrycki <daniel.mizyrycki@dotcloud.com>
Cc: Yaroslav Halchenko <yarikoptic@gmail.com>, 706060@bugs.debian.org, reply+i-12595695-18a5438565896eb9ee444effaa4bf2291790e300-68684@reply.github.com
Subject: Re: Bug#706060: [packaging] Re: Bug#706060: so how is ITP going?
Date: Mon, 17 Jun 2013 14:45:02 -0400
> >>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        



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Daniel Mizyrycki <daniel@dotcloud.com>:
Bug#706060; Package wnpp. (Sun, 07 Jul 2013 12:48:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Vincent Bernat <bernat@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Daniel Mizyrycki <daniel@dotcloud.com>. (Sun, 07 Jul 2013 12:48:04 GMT) Full text and rfc822 format available.

Message #45 received at 706060@bugs.debian.org (full text, mbox):

From: Vincent Bernat <bernat@debian.org>
To: Daniel Mizyrycki <daniel.mizyrycki@dotcloud.com>
Cc: Yaroslav Halchenko <debian@onerussian.com>, 706060@bugs.debian.org, dotCloud <ops@dotcloud.com>
Subject: Re: Bug#706060: so how is ITP going?
Date: Sun, 07 Jul 2013 14:45:15 +0200
[Message part 1 (text/plain, inline)]
 ❦  7 juin 2013 17:28 CEST, Daniel Mizyrycki <daniel.mizyrycki@dotcloud.com> :

>> I see that PPA has some packages (check lintian *.dsc for minor
>> tweeks TODO; also probably there is no reason for duplicate
>> {,src/}github.com/docker; copyright seems to be missing info on
>> ./src/github.com/gorilla/; may be more...) -- but is there anything
>> holding you up really? ;)
> Yep, those are minor issues. The mayor one is to move the
> debian/Makefile to debian/rules with new logic, aligned with debian go
> packaging guidelines.
> If are you interested in helping out, we will have the debian
> packaging faster :)

I am a bit lost in the conversation. Those issues seem pretty easy to
fix. However, the Alioth repository is still not set so it is difficult
to help you. Would you like help to setup the repository on Alioth? Do
you have an account on Alioth?

Yaroslav's proposition seems complicated but is in fact pretty simple
(unless I have misunderstood his intentions). This is just using
git-buildpackage with default settings:
 - upstream tarballs are imported into upstream branch
 - debian modifications are done in master branch (and should only cover
   debian/ directory)
-- 
Test programs at their boundary values.
            - The Elements of Programming Style (Kernighan & Plauger)
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Daniel Mizyrycki <daniel@dotcloud.com>:
Bug#706060; Package wnpp. (Tue, 09 Jul 2013 23:48:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Mizyrycki <daniel.mizyrycki@dotcloud.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Daniel Mizyrycki <daniel@dotcloud.com>. (Tue, 09 Jul 2013 23:48:04 GMT) Full text and rfc822 format available.

Message #50 received at 706060@bugs.debian.org (full text, mbox):

From: Daniel Mizyrycki <daniel.mizyrycki@dotcloud.com>
To: Yaroslav Halchenko <yarikoptic@gmail.com>
Cc: Daniel Mizyrycki <daniel.mizyrycki@dotcloud.com>, 706060@bugs.debian.org, reply+i-12595695-18a5438565896eb9ee444effaa4bf2291790e300-68684@reply.github.com
Subject: Re: Bug#706060: [packaging] Re: Bug#706060: so how is ITP going?
Date: Tue, 09 Jul 2013 16:45:45 -0700
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.
>




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Daniel Mizyrycki <daniel@dotcloud.com>:
Bug#706060; Package wnpp. (Wed, 10 Jul 2013 00:06:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Mizyrycki <daniel.mizyrycki@dotcloud.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Daniel Mizyrycki <daniel@dotcloud.com>. (Wed, 10 Jul 2013 00:06:05 GMT) Full text and rfc822 format available.

Message #55 received at 706060@bugs.debian.org (full text, mbox):

From: Daniel Mizyrycki <daniel.mizyrycki@dotcloud.com>
To: Vincent Bernat <bernat@debian.org>
Cc: Daniel Mizyrycki <daniel.mizyrycki@dotcloud.com>, Yaroslav Halchenko <debian@onerussian.com>, 706060@bugs.debian.org, dotCloud <ops@dotcloud.com>
Subject: Re: Bug#706060: so how is ITP going?
Date: Tue, 09 Jul 2013 17:02:35 -0700
Thank you for offering help, Vicent! Yaroslav did in fact help a lot. 
Understanding the underlying logic of git-buildpackage is the real key.

On 07/07/2013 05:45 AM, Vincent Bernat wrote:
>   ❦  7 juin 2013 17:28 CEST, Daniel Mizyrycki<daniel.mizyrycki@dotcloud.com>  :
>
>>> I see that PPA has some packages (check lintian *.dsc for minor
>>> tweeks TODO; also probably there is no reason for duplicate
>>> {,src/}github.com/docker; copyright seems to be missing info on
>>> ./src/github.com/gorilla/; may be more...) -- but is there anything
>>> holding you up really? ;)
>> Yep, those are minor issues. The mayor one is to move the
>> debian/Makefile to debian/rules with new logic, aligned with debian go
>> packaging guidelines.
>> If are you interested in helping out, we will have the debian
>> packaging faster :)
>
> I am a bit lost in the conversation. Those issues seem pretty easy to
> fix. However, the Alioth repository is still not set so it is difficult
> to help you. Would you like help to setup the repository on Alioth? Do
> you have an account on Alioth?
Yes, that was the easy part :)

>
> Yaroslav's proposition seems complicated but is in fact pretty simple
> (unless I have misunderstood his intentions). This is just using
> git-buildpackage with default settings:
>   - upstream tarballs are imported into upstream branch
>   - debian modifications are done in master branch (and should only cover
>     debian/ directory)
Yes. We are playing with some of this and is super exciting. Thank you.



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Daniel Mizyrycki <daniel@dotcloud.com>:
Bug#706060; Package wnpp. (Wed, 10 Jul 2013 15:21:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yaroslav Halchenko <yarikoptic@gmail.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Daniel Mizyrycki <daniel@dotcloud.com>. (Wed, 10 Jul 2013 15:21:04 GMT) Full text and rfc822 format available.

Message #60 received at 706060@bugs.debian.org (full text, mbox):

From: Yaroslav Halchenko <yarikoptic@gmail.com>
To: Daniel Mizyrycki <daniel.mizyrycki@dotcloud.com>
Cc: Yaroslav Halchenko <yarikoptic@gmail.com>, 706060@bugs.debian.org, reply+i-12595695-18a5438565896eb9ee444effaa4bf2291790e300-68684@reply.github.com
Subject: Re: Bug#706060: [packaging] Re: Bug#706060: so how is ITP going?
Date: Wed, 10 Jul 2013 11:18:03 -0400
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        



Added tag(s) pending. Request was from Anibal Monsalve Salazar <anibal@debian.org> to control@bugs.debian.org. (Wed, 25 Sep 2013 08:06:04 GMT) Full text and rfc822 format available.

Owner changed from Daniel Mizyrycki <daniel@dotcloud.com> to 'Daniel Mizyrycki <daniel@dotcloud.com>'. Request was from Holger Levsen <holger@layer-acht.org> to control@bugs.debian.org. (Mon, 02 Dec 2013 12:48:04 GMT) Full text and rfc822 format available.

Merged 706060 730569 Request was from Holger Levsen <holger@layer-acht.org> to control@bugs.debian.org. (Mon, 02 Dec 2013 12:48:07 GMT) Full text and rfc822 format available.

Owner changed from 'Daniel Mizyrycki <daniel@dotcloud.com>' to Daniel Mizyrycki <daniel@dotcloud.com>. Request was from Holger Levsen <holger@layer-acht.org> to control@bugs.debian.org. (Mon, 02 Dec 2013 13:03:10 GMT) Full text and rfc822 format available.

Added blocking bug(s) of 706060: 733514 Request was from Thomas Koch <thomas@koch.ro> to submit@bugs.debian.org. (Sun, 29 Dec 2013 16:33:06 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Daniel Mizyrycki <daniel@dotcloud.com>:
Bug#706060; Package wnpp. (Sun, 29 Dec 2013 19:06:15 GMT) Full text and rfc822 format available.

Acknowledgement sent to Thomas Koch <thomas@koch.ro>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Daniel Mizyrycki <daniel@dotcloud.com>. (Sun, 29 Dec 2013 19:06:15 GMT) Full text and rfc822 format available.

Message #75 received at 706060@bugs.debian.org (full text, mbox):

From: Thomas Koch <thomas@koch.ro>
To: 706060@bugs.debian.org
Subject: Docker 0.6.6 debian packaging update
Date: Sun, 29 Dec 2013 20:05:22 +0100
Johan Euphrosine (proppy) posted a packaging update on nov 21. to docker.dev:
https://groups.google.com/forum/?fromgroups#!topic/docker-dev/7o-sXWFUyaU

The "bug with golang archive/tar" is already resolved in the the debian go 
package so there remains only a), c):

a/ missing gosqlite3 dependencies
c/ missing go.net/websocket dependencies (functionality disabled with a patch)

Thanks to everybody who brings Docker to Debian (and maybe to backports...)!

Regards, Thomas Koch



Reply sent to Paul Tagliamonte <paultag@debian.org>:
You have taken responsibility. (Wed, 08 Jan 2014 19:03:05 GMT) Full text and rfc822 format available.

Notification sent to Daniel Mizyrycki <daniel.mizyrycki@dotcloud.com>:
Bug acknowledged by developer. (Wed, 08 Jan 2014 19:03:05 GMT) Full text and rfc822 format available.

Message #80 received at 706060-close@bugs.debian.org (full text, mbox):

From: Paul Tagliamonte <paultag@debian.org>
To: 706060-close@bugs.debian.org
Subject: Bug#706060: fixed in docker.io 0.6.7+dfsg1-1
Date: Wed, 08 Jan 2014 19:00:06 +0000
Source: docker.io
Source-Version: 0.6.7+dfsg1-1

We believe that the bug you reported is fixed in the latest version of
docker.io, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 706060@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Paul Tagliamonte <paultag@debian.org> (supplier of updated docker.io package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Tue, 07 Jan 2014 21:06:10 -0500
Source: docker.io
Binary: docker.io
Architecture: source amd64
Version: 0.6.7+dfsg1-1
Distribution: unstable
Urgency: medium
Maintainer: Paul Tagliamonte <paultag@debian.org>
Changed-By: Paul Tagliamonte <paultag@debian.org>
Description: 
 docker.io  - Linux container runtime
Closes: 706060 730569
Changes: 
 docker.io (0.6.7+dfsg1-1) unstable; urgency=medium
 .
   * Initial release (Closes: #706060, #730569)
   * Document missing licenses in the source tree. Bad, paultag. Thanks
     alteholz.
Checksums-Sha1: 
 113b8642d1cc140ddc7097d5c8b781a5da453513 2160 docker.io_0.6.7+dfsg1-1.dsc
 d95dce01bdbe73e8965d57a58d09605a1a844e2c 246810 docker.io_0.6.7+dfsg1.orig.tar.gz
 0568811a69ffccd0fa549d120be48c7391413969 8292 docker.io_0.6.7+dfsg1-1.debian.tar.gz
 e4ec37c01597026eecedb055c4eabb6dadf576c3 2235302 docker.io_0.6.7+dfsg1-1_amd64.deb
Checksums-Sha256: 
 357cd8e27a31483683bba6ec811edd2f2aff478af0ff60c6762538bedffd38e3 2160 docker.io_0.6.7+dfsg1-1.dsc
 96b9c6dc0f5361712254647d7d1a955058934f23505f93d25f4faecb91fc54e9 246810 docker.io_0.6.7+dfsg1.orig.tar.gz
 d4cb506312297a17945937ed604716686f9eb759e66460fa6c3ccba8ff9fd8fe 8292 docker.io_0.6.7+dfsg1-1.debian.tar.gz
 87ff1e25682d4a4021095aa25eeeb7bc73ced99c051e3fedd3269cdb4d33af6d 2235302 docker.io_0.6.7+dfsg1-1_amd64.deb
Files: 
 ba76d6b1773bc9f430feee767694dcfb 2160 admin optional docker.io_0.6.7+dfsg1-1.dsc
 d23893a979a4ab4b7bfb77acda62a012 246810 admin optional docker.io_0.6.7+dfsg1.orig.tar.gz
 2d8505b13c99873a9e8e874522b6fa0b 8292 admin optional docker.io_0.6.7+dfsg1-1.debian.tar.gz
 9a5bb39a1f1f643288f039ffac158542 2235302 admin optional docker.io_0.6.7+dfsg1-1_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)

iQIcBAEBAgAGBQJSzWkNAAoJEHtYWzCAfCqHuyIQAJaG1zdHRCbVgJIjht5TJHM2
B05QBHkK9Ig8tsA/lMaIF7+QdSqNdYATRopa87Az7k7xVlzwpePo4ve7kRSSthvM
bTksJbvQ6UY+C0qlfODSS6hKkO7XhJqSbqf36TA2wSoqQqg+/1mhXIQe4O47AAXP
H0r8x23TR0jZWkG+Ow1L/TE0N3YbO0Aipyq+kDlvTI9f9LLxYsGowzhYI1Yg5rPU
LVxtVt78cwgp4R3eyorAV4pZQOyWf1NmbjxgLsCcvvHB+wHVVRd2qt7XW6pN3ZEV
OsKGhsR1eB3b0iyNcIULH63C2PE5Acb1yvWGVMvzzltrlRiUcH+aoxzYWAZa5tlS
UDDXWn6L0b1Z5Kb9dyePPmf7lX9AgjcR+g+A0GooIxdiRbF9qppjByr1qEjI+PQV
2i6xGynS0tRzTm2lVYBtXoZPiNidEUo6JVsoALbbOb9QhieQfffqgaI9hGXau5GY
tluIBLP7HCH8xi4LiV9SWUfw1TpIcLtaqAPgxpMTXElnoqCp7KeyN7h21ej6NvOZ
R5Kf6k5rBRUM6WkbnUfV5QcGOM34ZpKYmdGyQNws7vrLdjCTkLTQi0OGuWro3MyQ
Lxn1dNjsG9Pt2BSsBRZ52Pmqnp72XG3YPEhdKcZslLV9GMGbHr5D93vCMJmig19D
0GkNkT6cSSD4p2rkVVzB
=FKVJ
-----END PGP SIGNATURE-----




Reply sent to Paul Tagliamonte <paultag@debian.org>:
You have taken responsibility. (Wed, 08 Jan 2014 19:03:06 GMT) Full text and rfc822 format available.

Notification sent to Paul Tagliamonte <metatron@pault.ag>:
Bug acknowledged by developer. (Wed, 08 Jan 2014 19:03:06 GMT) Full text and rfc822 format available.

Message #85 received at 730569-close@bugs.debian.org (full text, mbox):

From: Paul Tagliamonte <paultag@debian.org>
To: 730569-close@bugs.debian.org
Subject: Bug#730569: fixed in docker.io 0.6.7+dfsg1-1
Date: Wed, 08 Jan 2014 19:00:06 +0000
Source: docker.io
Source-Version: 0.6.7+dfsg1-1

We believe that the bug you reported is fixed in the latest version of
docker.io, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 730569@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Paul Tagliamonte <paultag@debian.org> (supplier of updated docker.io package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Tue, 07 Jan 2014 21:06:10 -0500
Source: docker.io
Binary: docker.io
Architecture: source amd64
Version: 0.6.7+dfsg1-1
Distribution: unstable
Urgency: medium
Maintainer: Paul Tagliamonte <paultag@debian.org>
Changed-By: Paul Tagliamonte <paultag@debian.org>
Description: 
 docker.io  - Linux container runtime
Closes: 706060 730569
Changes: 
 docker.io (0.6.7+dfsg1-1) unstable; urgency=medium
 .
   * Initial release (Closes: #706060, #730569)
   * Document missing licenses in the source tree. Bad, paultag. Thanks
     alteholz.
Checksums-Sha1: 
 113b8642d1cc140ddc7097d5c8b781a5da453513 2160 docker.io_0.6.7+dfsg1-1.dsc
 d95dce01bdbe73e8965d57a58d09605a1a844e2c 246810 docker.io_0.6.7+dfsg1.orig.tar.gz
 0568811a69ffccd0fa549d120be48c7391413969 8292 docker.io_0.6.7+dfsg1-1.debian.tar.gz
 e4ec37c01597026eecedb055c4eabb6dadf576c3 2235302 docker.io_0.6.7+dfsg1-1_amd64.deb
Checksums-Sha256: 
 357cd8e27a31483683bba6ec811edd2f2aff478af0ff60c6762538bedffd38e3 2160 docker.io_0.6.7+dfsg1-1.dsc
 96b9c6dc0f5361712254647d7d1a955058934f23505f93d25f4faecb91fc54e9 246810 docker.io_0.6.7+dfsg1.orig.tar.gz
 d4cb506312297a17945937ed604716686f9eb759e66460fa6c3ccba8ff9fd8fe 8292 docker.io_0.6.7+dfsg1-1.debian.tar.gz
 87ff1e25682d4a4021095aa25eeeb7bc73ced99c051e3fedd3269cdb4d33af6d 2235302 docker.io_0.6.7+dfsg1-1_amd64.deb
Files: 
 ba76d6b1773bc9f430feee767694dcfb 2160 admin optional docker.io_0.6.7+dfsg1-1.dsc
 d23893a979a4ab4b7bfb77acda62a012 246810 admin optional docker.io_0.6.7+dfsg1.orig.tar.gz
 2d8505b13c99873a9e8e874522b6fa0b 8292 admin optional docker.io_0.6.7+dfsg1-1.debian.tar.gz
 9a5bb39a1f1f643288f039ffac158542 2235302 admin optional docker.io_0.6.7+dfsg1-1_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)

iQIcBAEBAgAGBQJSzWkNAAoJEHtYWzCAfCqHuyIQAJaG1zdHRCbVgJIjht5TJHM2
B05QBHkK9Ig8tsA/lMaIF7+QdSqNdYATRopa87Az7k7xVlzwpePo4ve7kRSSthvM
bTksJbvQ6UY+C0qlfODSS6hKkO7XhJqSbqf36TA2wSoqQqg+/1mhXIQe4O47AAXP
H0r8x23TR0jZWkG+Ow1L/TE0N3YbO0Aipyq+kDlvTI9f9LLxYsGowzhYI1Yg5rPU
LVxtVt78cwgp4R3eyorAV4pZQOyWf1NmbjxgLsCcvvHB+wHVVRd2qt7XW6pN3ZEV
OsKGhsR1eB3b0iyNcIULH63C2PE5Acb1yvWGVMvzzltrlRiUcH+aoxzYWAZa5tlS
UDDXWn6L0b1Z5Kb9dyePPmf7lX9AgjcR+g+A0GooIxdiRbF9qppjByr1qEjI+PQV
2i6xGynS0tRzTm2lVYBtXoZPiNidEUo6JVsoALbbOb9QhieQfffqgaI9hGXau5GY
tluIBLP7HCH8xi4LiV9SWUfw1TpIcLtaqAPgxpMTXElnoqCp7KeyN7h21ej6NvOZ
R5Kf6k5rBRUM6WkbnUfV5QcGOM34ZpKYmdGyQNws7vrLdjCTkLTQi0OGuWro3MyQ
Lxn1dNjsG9Pt2BSsBRZ52Pmqnp72XG3YPEhdKcZslLV9GMGbHr5D93vCMJmig19D
0GkNkT6cSSD4p2rkVVzB
=FKVJ
-----END PGP SIGNATURE-----




Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Thu, 06 Feb 2014 07:30:59 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Wed Apr 23 15:11:48 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.