Hi, On Thu, Sep 14, 2023 at 8:06 AM Lucas Kanashiro <kanash...@ubuntu.com> wrote: > > Hi Andreas, > > On 13/09/2023 11:58, Andreas Hasenack wrote: > > Hi Lucas, > > > > On Fri, Sep 1, 2023 at 6:14 PM Lucas Kanashiro <kanash...@ubuntu.com> wrote: > >> Hi SRU team, > >> > >> I'd like to ask for an update of the Docker.io group SRU exception [1] > >> to also include the two new Docker CLI plugins that are now in the > >> archive (Mantic): > >> > >> - docker-buildx > >> - docker-compose-v2 > > Sorry for taking to long to get to this request. > > No problem. > > >> They are self contained (no reverse dependencies). They will also > >> considerably improve the experience of our Docker users across all > >> releases. Those 2 new packages are really tightened to the Docker > >> version we have and it would be great to keep it consistent everywhere. > >> > >> My idea is to not allow the backport of versions .0 of those packages as > >> we do with docker.io-app. > >> > >> [1] https://wiki.ubuntu.com/DockerUpdates > > Approved on the condition that we have a few new DEP8 tests. I think
But also please see my comment about docker-compose vs docker-compose-v2 at the end > > this is importand because, per SRU exception[1] for this group of > > packages, DEP8 tests are basically the only tests performed. > > Do you mean the current DEP-8 tests are not enough? There is no "docker build" in the current DEP-8 tests, much less with DOCKER_BUILDKIT=1 (I'm looking at mantic), and no test for docker compose, even to check its presence. You are asking to include two packages in an exception which relies on the DEP-8 tests, so yes, I think these two new packages should be tested. > > > I'm thinking: > > a) one for the build functionality with DOCKER_BUILDKIT=1, which is > > what will exercise the docker-buildx plugin at a minimum, and verify > > the recent regression[2]. A simple Dockerfile consisting only of "FROM > > ubuntu:latest" should suffice to begin with, as that would have caught > > the regression[1]. > > The DOCKER_BUILDKIT=1 option is not currently used in the test, so yes, > we could add it due to this regression. Could we move on with the > backports now and I add it in the next upload/backport? Please document it in the wiki, and for this first backport, it's ok as long as they are manually tested then. > > I'd like to mention that the basic features are already tested in the > smoke test we have. But not the new ones introduced by these new packages, right? > > > b) compose. We can start with a smoke test showing that the plugin is > > recognized, because right not it isn't (unless I'm doing something > > wrong. After I install bin:docker-compose, I don't see it in the > > output of "docker info", nor is the "docker compose" command > > recognized. Just "docker-compose" (in lunar). > > We do have a smoke test. The correct binary package is > docker-compose-v2, docker-compose is the old version. I just called it a smoke-test, I wasn't refering explicitly to d/t/basic-smoke, which does NOT check docker compose, unless I missed something. Noted on the binary package. So what will happen to the old bin:docker-compose? We have: $ rmadison docker-compose docker-compose | 1.5.2-1 | xenial/universe | source, all docker-compose | 1.8.0-2~16.04.1 | xenial-updates/universe | source, all docker-compose | 1.17.1-2 | bionic/universe | source, all docker-compose | 1.25.0-1 | focal/universe | source, all docker-compose | 1.29.2-1 | jammy/universe | source, all docker-compose | 1.29.2-3 | lunar/universe | source, all docker-compose | 1.29.2-6 | mantic/universe | source, all And: $ rmadison docker-compose-v2 docker-compose-v2 | 2.20.2+ds1-0ubuntu1 | mantic/universe | source, amd64, arm64, armhf, ppc64el, riscv64, s390x -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
