Hi again :)
On 15/09/2023 16:39, Andreas Hasenack wrote:
Hi,
On Fri, Sep 15, 2023 at 4:24 PM Lucas Kanashiro <kanash...@ubuntu.com> wrote:
Hi,
On 14/09/2023 10:20, Andreas Hasenack wrote:
Hi,
On Thu, Sep 14, 2023 at 9:54 AM Lucas Kanashiro <kanash...@ubuntu.com> wrote:
Hi,
On 14/09/2023 09:33, Andreas Hasenack wrote:
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.
There is a call to "docker build" in line 24 of d/t/basic-smoke of
docker-buildx.
Ah, I was checking src:docker.io-app, sorry.
Looking at the correct package now, src:docker-buildx, it uses "docker
buildx" indeed. Ok then, we just need a normal build (not buildx) with
and without the env var, like what triggered the regression report.
Just be wary that this env var usage might disappear in the future I
suppose, as buildkit becomes default. Then the test would be moot and
could be removed. Something to keep an eye on.
+1.
The "docker compose" command is called multiple times in d/t/basic-smoke
of docker-compose-v2.
Same thing, sorry. I was looking at src:docker.io-app. ACK on
docker-compose-v2, no further tests needed.
AFAICS just the DOCKER_BUILDKIT=1 is not covered by the current tests.
Correct, with a normal "docker build" command.
Noted on the binary package. So what will happen to the old bin:docker-compose?
TBH I plan to do nothing, it is sync'ed from Debian and it is a totally
different package (even written in a different programming language).
Ok, that's something for an AA to sort out when the time comes.
Does this mean that the addition of those two packages to the exception
is accepted under the condition of adding DOCKER_BUILDKIT=1 to the
docker-buildx DEP-8 test in the next upload? Should I go ahead and
Yes, DEP8 in next upload, and a manual run on this one. And a normal
"docker build" (not buildx), unless I missed that one too and it's
already being done.
Right, I'll add the regular "docker build" as well.
Both changes in the next uploads of docker-buildx.
update the wiki page containing the exception? Do you want to do that
instead?
Please do it.
Just did it, let me know if there is any issue.
I'll be working on the backport of those packages to stable releases.
Thank you very much!
--
Lucas Kanashiro
--
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
