Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1197678 > unrolled thread

Bug#1033839: Packaging docker 24.0.9

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1033839: Packaging docker 24.0.9 Reinhard Tartler <siretart@gmail.com> - 2024-05-17 02:40 +0200
    Bug#1033839: Packaging docker 24.0.9 Tianon Gravi <tianon@debian.org> - 2024-05-17 05:50 +0200
      Bug#1033839: Packaging docker 24.0.9 Shengjing Zhu <zhsj@debian.org> - 2024-05-17 09:40 +0200
        Bug#1033839: Packaging docker 24.0.9 Tianon Gravi <tianon@debian.org> - 2024-05-17 21:10 +0200
          Bug#1033839: Packaging docker 24.0.9 Reinhard Tartler <siretart@gmail.com> - 2024-05-18 00:30 +0200
            Bug#1033839: Packaging docker 24.0.9 Reinhard Tartler <siretart@gmail.com> - 2024-05-20 14:30 +0200
              Bug#1033839: Packaging docker 24.0.9 Arnaud Rebillout <arnaudr@debian.org> - 2024-05-20 16:10 +0200
          Bug#1033839: Packaging docker 24.0.9 Tianon Gravi <tianon@debian.org> - 2024-05-23 20:50 +0200
    Bug#1033839: Packaging docker 24.0.9 Arnaud Rebillout <arnaudr@debian.org> - 2024-05-17 09:40 +0200

#1197678 — Bug#1033839: Packaging docker 24.0.9

[Multipart message — attachments visible in raw view] — view raw

Hi,

copying everyone currently listed as co-maintainer of the docker.io package
in Debian.

I've decided to give this thing a stab. It seems Debian currently ships the
same minor upstream version of docker.io 20.10 as we had in unstable, and
more and more packages (such as podman) require significantly newer
versions  of docker. This is starting to do a serious disservice to our
users.

My current work in progress lives in
https://salsa.debian.org/go-team/packages/docker/-/tree/siretart/docker24?ref_type=heads.
So far, I've:

- identified that libnetwork got merged into gh:moby/moby, so I've removed
references from the packaging
- tried to follow README.source as much as possible
- identified vendored sources and updated the Files-Excluded fields and
debian/copyright as appropriate
- refreshed patches against the new upstream version
- identified circular dependencies and chose vendored versions to unbreak
them.

What I would appreciate help with:

- reviewing what I've done. This is a very complex package that is done in
a style that I'm not used to work with
- help getting it to build (it currently doesn't, I suspect because at
least some dependencies in debian are too old. I guess using vendored
copies is the most expedient way to go about this?
- update debian/copyright for new code additions
- identify and drop unnecessary dependencies from debian/control.

Thank you so much for your support and assistance!

-rt


-- 
regards,
    Reinhard

[toc] | [next] | [standalone]

#1197683

[Multipart message — attachments visible in raw view] — view raw

For the dependencies, I'd probably suggest attempting to parse
https://github.com/moby/moby/blob/v24.0.9/vendor.mod into a list of
versioned Depends: directly, since those aren't likely to be bumped
upstream "willy nilly" (and IMO that would make it easier to determine
which things need to be packaged and/or which packaged things might need to
be updated in Debian or used from vendor/).

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4


On Thu, 16 May 2024 at 17:33, Reinhard Tartler <siretart@gmail.com> wrote:

> Hi,
>
> copying everyone currently listed as co-maintainer of the docker.io
> package in Debian.
>
> I've decided to give this thing a stab. It seems Debian currently ships
> the same minor upstream version of docker.io 20.10 as we had in unstable,
> and more and more packages (such as podman) require significantly newer
> versions  of docker. This is starting to do a serious disservice to our
> users.
>
> My current work in progress lives in
> https://salsa.debian.org/go-team/packages/docker/-/tree/siretart/docker24?ref_type=heads.
> So far, I've:
>
> - identified that libnetwork got merged into gh:moby/moby, so I've removed
> references from the packaging
> - tried to follow README.source as much as possible
> - identified vendored sources and updated the Files-Excluded fields and
> debian/copyright as appropriate
> - refreshed patches against the new upstream version
> - identified circular dependencies and chose vendored versions to unbreak
> them.
>
> What I would appreciate help with:
>
> - reviewing what I've done. This is a very complex package that is done in
> a style that I'm not used to work with
> - help getting it to build (it currently doesn't, I suspect because at
> least some dependencies in debian are too old. I guess using vendored
> copies is the most expedient way to go about this?
> - update debian/copyright for new code additions
> - identify and drop unnecessary dependencies from debian/control.
>
> Thank you so much for your support and assistance!
>
> -rt
>
>
> --
> regards,
>     Reinhard
>

[toc] | [prev] | [next] | [standalone]

#1197696

Hi Tianon,

Actually I'm lost with the upstream version policy after they changed
the schema. Is there still something called "LTS"?

-- 
Shengjing Zhu

[toc] | [prev] | [next] | [standalone]

#1197767

[Multipart message — attachments visible in raw view] — view raw

That's a little bit of a separate concern from what I was talking about
(Moby own versions vs code dependencies).

In short, no, the upstream project does not currently have any "LTS"
branches (and never really had anything *super* long term outside of the
enterprise edition that wasn't open source -- the longest I recall on the
open source side was somewhere around four months).

The closest thing upstream to LTS right now is probably the 23.x
branch/release line where Mirantis is maintaining their currently supported
version with the support/assistance/blessing of the upstream community.

AFAIK, the 24.x branch is effectively already EOL.

(There's a task item on the project's list to document all this publicly
better, but it's definitely challenging, as I'm sure you can
imagine/understand.)

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4


On Fri, 17 May 2024 at 00:37, Shengjing Zhu <zhsj@debian.org> wrote:

> Hi Tianon,
>
> Actually I'm lost with the upstream version policy after they changed
> the schema. Is there still something called "LTS"?
>
> --
> Shengjing Zhu
>

[toc] | [prev] | [next] | [standalone]

#1197804

[Multipart message — attachments visible in raw view] — view raw

On Fri, May 17, 2024 at 3:06 PM Tianon Gravi <tianon@debian.org> wrote:

> That's a little bit of a separate concern from what I was talking about
> (Moby own versions vs code dependencies).
>
> In short, no, the upstream project does not currently have any "LTS"
> branches (and never really had anything *super* long term outside of the
> enterprise edition that wasn't open source -- the longest I recall on the
> open source side was somewhere around four months).
>
> The closest thing upstream to LTS right now is probably the 23.x
> branch/release line where Mirantis is maintaining their currently supported
> version with the support/assistance/blessing of the upstream community.
>
> AFAIK, the 24.x branch is effectively already EOL.
>
>
Just to clarify and for the avoidance of doubt, I picked 24.0.9 because I
understand this is the version that is supposed to work with the version of
containerd we currently have in unstable. Obviously packaging supported
versions of docker/containerd is preferable, but since this is already a
daunting task, I opted for this older version to not make the task
more complicated than it needs to be.


-- 
regards,
    Reinhard

[toc] | [prev] | [next] | [standalone]

#1198046

[Multipart message — attachments visible in raw view] — view raw

status update:

* Picked up the proposed changes Arnaud, I think using dh-golang is an
excellent idea
* seems our google-grpc version in sid is too old, but there is a newer one
in experimental, so let's use that for now
* tried to build against etcd server in sid, doesn't seem to work though
* updated containerd/typeurl and mitchellh/hashstructure in experimental. I
believe both should be good for sid, but I didn't check whether the changes
break existing packages. That needs to be done before uploading docker.io
24 to sid


Currently fails to build with:

src/github.com/docker/docker/cmd/dockerd/service_unsupported.go
cd _build && go install -trimpath -v -p 8 -tags "apparmor seccomp journald"
-buildmode=pie -ldflags "-w -X
github.com/docker/docker/dockerversion.Version=24.0.9+dfsg1 -X
github.com/docker/docker/dockerversion.GitCommit=fca702d -X
github.com/docker/docker/dockerversion.BuildTime=2024-05-11T18:30:26.000000000+00:00
-X github.com/docker/docker/dockerversion.PlatformName= -X
github.com/docker/docker/dockerversion.ProductName=docker -X
github.com/docker/docker/dockerversion.DefaultProductLicense="
github.com/docker/docker/cmd/dockerd
src/
github.com/docker/docker/vendor/github.com/moby/swarmkit/v2/api/raft.pb.go:12:2:
cannot find package "go.etcd.io/etcd/raft/v3/raftpb" in any of:
/<<PKGBUILDDIR>>/_build/src/
github.com/docker/docker/vendor/go.etcd.io/etcd/raft/v3/raftpb (vendor tree)
/usr/lib/go-1.22/src/go.etcd.io/etcd/raft/v3/raftpb (from $GOROOT)
/<<PKGBUILDDIR>>/_build/src/go.etcd.io/etcd/raft/v3/raftpb (from $GOPATH)
src/github.com/docker/docker/libcontainerd/shimopts/convert.go:4:2: cannot
find package "
github.com/Microsoft/hcsshim/cmd/containerd-shim-runhcs-v1/options" in any
of:
/<<PKGBUILDDIR>>/_build/src/
github.com/docker/docker/vendor/github.com/Microsoft/hcsshim/cmd/containerd-shim-runhcs-v1/options
(vendor tree)
/usr/lib/go-1.22/src/
github.com/Microsoft/hcsshim/cmd/containerd-shim-runhcs-v1/options (from
$GOROOT)
/<<PKGBUILDDIR>>/_build/src/
github.com/Microsoft/hcsshim/cmd/containerd-shim-runhcs-v1/options (from
$GOPATH)
src/
github.com/docker/docker/vendor/github.com/moby/swarmkit/v2/manager/state/raft/storage/storage.go:13:2:
cannot find package "go.etcd.io/etcd/client/pkg/v3/fileutil" in any of:
/<<PKGBUILDDIR>>/_build/src/
github.com/docker/docker/vendor/go.etcd.io/etcd/client/pkg/v3/fileutil
(vendor tree)
/usr/lib/go-1.22/src/go.etcd.io/etcd/client/pkg/v3/fileutil (from $GOROOT)
/<<PKGBUILDDIR>>/_build/src/go.etcd.io/etcd/client/pkg/v3/fileutil (from
$GOPATH)
src/
github.com/docker/docker/vendor/github.com/moby/swarmkit/v2/manager/state/raft/storage/snapwrap.go:12:2:
cannot find package "go.etcd.io/etcd/server/v3/etcdserver/api/snap" in any
of:
/<<PKGBUILDDIR>>/_build/src/
github.com/docker/docker/vendor/go.etcd.io/etcd/server/v3/etcdserver/api/snap
(vendor tree)
/usr/lib/go-1.22/src/go.etcd.io/etcd/server/v3/etcdserver/api/snap (from
$GOROOT)
/<<PKGBUILDDIR>>/_build/src/go.etcd.io/etcd/server/v3/etcdserver/api/snap
(from $GOPATH)
src/
github.com/docker/docker/vendor/github.com/moby/swarmkit/v2/manager/state/raft/storage/storage.go:16:2:
cannot find package "go.etcd.io/etcd/server/v3/wal" in any of:
/<<PKGBUILDDIR>>/_build/src/
github.com/docker/docker/vendor/go.etcd.io/etcd/server/v3/wal (vendor tree)
/usr/lib/go-1.22/src/go.etcd.io/etcd/server/v3/wal (from $GOROOT)
/<<PKGBUILDDIR>>/_build/src/go.etcd.io/etcd/server/v3/wal (from $GOPATH)
src/
github.com/docker/docker/vendor/github.com/moby/swarmkit/v2/manager/state/raft/storage/storage.go:17:2:
cannot find package "go.etcd.io/etcd/server/v3/wal/walpb" in any of:
/<<PKGBUILDDIR>>/_build/src/
github.com/docker/docker/vendor/go.etcd.io/etcd/server/v3/wal/walpb (vendor
tree)
/usr/lib/go-1.22/src/go.etcd.io/etcd/server/v3/wal/walpb (from $GOROOT)
/<<PKGBUILDDIR>>/_build/src/go.etcd.io/etcd/server/v3/wal/walpb (from
$GOPATH)
src/
github.com/docker/docker/vendor/github.com/moby/swarmkit/v2/manager/state/raft/transport/peer.go:16:2:
cannot find package "go.etcd.io/etcd/raft/v3" in any of:
/<<PKGBUILDDIR>>/_build/src/
github.com/docker/docker/vendor/go.etcd.io/etcd/raft/v3 (vendor tree)
/usr/lib/go-1.22/src/go.etcd.io/etcd/raft/v3 (from $GOROOT)
/<<PKGBUILDDIR>>/_build/src/go.etcd.io/etcd/raft/v3 (from $GOPATH)
src/
github.com/docker/docker/vendor/github.com/moby/swarmkit/v2/manager/state/raft/raft.go:32:2:
cannot find package "go.etcd.io/etcd/pkg/v3/idutil" in any of:
/<<PKGBUILDDIR>>/_build/src/
github.com/docker/docker/vendor/go.etcd.io/etcd/pkg/v3/idutil (vendor tree)
/usr/lib/go-1.22/src/go.etcd.io/etcd/pkg/v3/idutil (from $GOROOT)
/<<PKGBUILDDIR>>/_build/src/go.etcd.io/etcd/pkg/v3/idutil (from $GOPATH)
dh_auto_build: error: cd _build && go install -trimpath -v -p 8 -tags
"apparmor seccomp journald" -buildmode=pie -ldflags "-w -X
github.com/docker/docker/dockerversion.Version=24.0.9+dfsg1 -X
github.com/docker/docker/dockerversion.GitCommit=fca702d -X
github.com/docker/docker/dockerversion.BuildTime=2024-05-11T18:30:26.000000000+00:00
-X github.com/docker/docker/dockerversion.PlatformName= -X
github.com/docker/docker/dockerversion.ProductName=docker -X
github.com/docker/docker/dockerversion.DefaultProductLicense="
github.com/docker/docker/cmd/dockerd returned exit code 1
make[1]: *** [debian/rules:119: override_dh_auto_build] Error 25



-- 
regards,
    Reinhard

[toc] | [prev] | [next] | [standalone]

#1198058

[Multipart message — attachments visible in raw view] — view raw

On 20/05/2024 19:20, Reinhard Tartler wrote:
>
> src/github.com/docker/docker/libcontainerd/shimopts/convert.go:4:2 
> <http://github.com/docker/docker/libcontainerd/shimopts/convert.go:4:2>: 
> cannot find package 
> "github.com/Microsoft/hcsshim/cmd/containerd-shim-runhcs-v1/options 
> <http://github.com/Microsoft/hcsshim/cmd/containerd-shim-runhcs-v1/options>" 
> in any of:
> /<<PKGBUILDDIR>>/_build/src/github.com/docker/docker/vendor/github.com/Microsoft/hcsshim/cmd/containerd-shim-runhcs-v1/options 
> <http://github.com/docker/docker/vendor/github.com/Microsoft/hcsshim/cmd/containerd-shim-runhcs-v1/options> 
> (vendor tree)
> /usr/lib/go-1.22/src/github.com/Microsoft/hcsshim/cmd/containerd-shim-runhcs-v1/options 
> <http://github.com/Microsoft/hcsshim/cmd/containerd-shim-runhcs-v1/options> 
> (from $GOROOT)
> /<<PKGBUILDDIR>>/_build/src/github.com/Microsoft/hcsshim/cmd/containerd-shim-runhcs-v1/options 
> <http://github.com/Microsoft/hcsshim/cmd/containerd-shim-runhcs-v1/options> 
> (from $GOPATH)

 From what I remember, Microsoft/hcsshim is something specific to 
Windows. I could patch it out, and after a bug report upstream, they 
made some changes so that this module was not imported in Linux builds:

https://github.com/moby/moby/pull/40146/files

But it looks like it came back. Hopefully easy to patch out :)

Best,

Arnaud

[toc] | [prev] | [next] | [standalone]

#1198337

On Fri, 17 May 2024 at 12:05, Tianon Gravi <tianon@debian.org> wrote:
> (There's a task item on the project's list to document all this publicly better, but it's definitely challenging, as I'm sure you can imagine/understand.)

Aha, it's public at https://github.com/moby/moby/pull/46772 (a little
bit dated now, but describes the gist of the current state and is the
best place to contribute on this point).

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

[toc] | [prev] | [next] | [standalone]

#1197695

[Multipart message — attachments visible in raw view] — view raw

Hello,

I pushed a branch arnaudr/docker24/1. It still FTBFS of course, but the 
output looks a bit more sane. Hope that helps!

Arnaud

On 17/05/2024 07:28, Reinhard Tartler wrote:
> Hi,
>
> copying everyone currently listed as co-maintainer of the docker.io 
> <http://docker.io> package in Debian.
>
> I've decided to give this thing a stab. It seems Debian currently 
> ships the same minor upstream version of docker.io <http://docker.io> 
> 20.10 as we had in unstable, and more and more packages (such as 
> podman) require significantly newer versions  of docker. This is 
> starting to do a serious disservice to our users.
>
> My current work in progress lives in 
> https://salsa.debian.org/go-team/packages/docker/-/tree/siretart/docker24?ref_type=heads. 
> So far, I've:
>
> - identified that libnetwork got merged into gh:moby/moby, so I've 
> removed references from the packaging
> - tried to follow README.source as much as possible
> - identified vendored sources and updated the Files-Excluded fields 
> and debian/copyright as appropriate
> - refreshed patches against the new upstream version
> - identified circular dependencies and chose vendored versions to 
> unbreak them.
>
> What I would appreciate help with:
>
> - reviewing what I've done. This is a very complex package that is 
> done in a style that I'm not used to work with
> - help getting it to build (it currently doesn't, I suspect because at 
> least some dependencies in debian are too old. I guess using vendored 
> copies is the most expedient way to go about this?
> - update debian/copyright for new code additions
> - identify and drop unnecessary dependencies from debian/control.
>
> Thank you so much for your support and assistance!
>
> -rt
>
>
> -- 
> regards,
>     Reinhard

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web