we've completed the bookworm upgrade in %Debian 12 bookworm upgrade, at least as far as physical machines are concerned.
but we're still building bullseye images here!
figure out a way to stop doing that and retire those images. i think that implies doing a survey of the consumers of that image across gitlab and pinging those people, or perhaps just sending an announcement with a timeline?
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Everything else in there seems to be forks or at least personal repos.
I think tpo/core/tor#41029 (closed) is going to take care of a lot of those. I'll file an issue with anti-censorship and onion-services, and take care of our stuff (TPA and web).
update: the above is all images, including upstream dockerhub. we should probably worry only about our images, here's a new set:
root@gitlab-02:/# sudo -u git find /var/opt/gitlab/git-data/repositories/@hashed -type d -a -name '*.git' -exec sh -c 'git -C {} grep -q 'containers.torproject.org.*:bullseye' HEAD -- Dockerfile Containerfile .gitlab-ci.yml 2>/dev/null && echo {}' \; | tee /root/projects-our-registry.list/var/opt/gitlab/git-data/repositories/@hashed/14/4d/144dc53d5dff011b70e273ff282f86c2976c8268811315f548ae013705941ba8.git/var/opt/gitlab/git-data/repositories/@hashed/a0/7e/a07eccc182c743a46ab8e902635a7ba4ad53cb780b6b9ef0bec926c34e7b22aa.git/var/opt/gitlab/git-data/repositories/@hashed/4d/a3/4da317481dcf5fbe44d38ef3bfcddef1080705af9f486c0a354851849a4ac242.git/var/opt/gitlab/git-data/repositories/@hashed/5c/7a/5c7a722d8d8f97d6d923396f673c15bab9722658cbe5ab24438a3ddadde5403f.git/var/opt/gitlab/git-data/repositories/@hashed/9b/e3/9be3da431e0a833d2b07781de97ebbd0b14c274d16c0597820d9982a5f547cb3.git/var/opt/gitlab/git-data/repositories/@hashed/3a/89/3a892eea646c4e4fc44df3a264545ce2e51f4bdc752cbd996dae588e5c839602.git/var/opt/gitlab/git-data/repositories/@hashed/49/98/49982c8e082e073b414ede8160c20679bf7432eab323bc981d96cf9205b9cf53.git/var/opt/gitlab/git-data/repositories/@hashed/da/56/da567b5f09f055a646df0e74c6014785930a8d207b22964868153f872b9bf9cf.git/var/opt/gitlab/git-data/repositories/@hashed/8e/69/8e690b5f73876692494576ad7fe9842af66e5d2ad2809ae42d1db67c3b2299de.git/var/opt/gitlab/git-data/repositories/@hashed/42/f2/42f25adecf47629878e89e31b2073d1af009c9c76f4140a06313af5e5950eabc.git/var/opt/gitlab/git-data/repositories/@hashed/ef/58/ef5839d610a3567ed8e2b6df29dce544e3fb9ffbaf45f507b3a69fbc5e81f507.git/var/opt/gitlab/git-data/repositories/@hashed/c7/d8/c7d86cb26af8d4344b7d1fc85fe37600940312901528d0977702f129cddf49ff.git/var/opt/gitlab/git-data/repositories/@hashed/62/c4/62c488bbaded8ff5903a5b55b345a49d74385768c7e5601aa5d0b6126dd694b5.git
figure out a way to stop doing that and retire those images. i think that implies doing a survey of the consumers of that image across gitlab and pinging those people, or perhaps just sending an announcement with a timeline?
i did such a review, only core tor and onionspray use our stuff, so it seems simpler to just do it, once people have switched over.
Not in this repository, rather, tpo/core/debian/tor builds backports for bullseye and this requires a bullseye image. If we remove the image, this means these backports will stop, and support will thus officially be droppped. I mean, I'm not too worried at this point, but we can't say its completely out of support currently.
but i thought that tor/core/tor#41029 was the one supposed to take care of tor.
That took care of the tor test suite, essentially. The package building CI is in tpo/core/debian/tor, as you know.
I guess this begs the question, what's our policy here for old Debian and Ubuntu releases, given that these images are also being used to build and ship software to downstream users?
I guess this begs the question, what's our policy here for old Debian and Ubuntu releases, given that these images are also being used to build and ship software to downstream users?
I was assuming we would retire the oldstable images alongside completing
the upgrade to stable/testing, but it's true it might merit more
leniency. Perhaps we remove release N when we finish the upgrade to N+2?
In this case, we'd restore bullseye and remove it when we complete the
trixie upgrade?
I mean in the trixie upgrade proposal, i explicitly proposed removing
the bookworm images at the end of the trixie upgrade (somewhere in
2026), so bullseye is far gone, in that context.
Now that I think of it, I think I'd prefer if we aligned the image builds here with the upstream lifecycle of the releases themselves.
I guess I don't really see why the build roster should follow TPA's own upgrade schedule. Am I missing something?
In addition, if we say we align with the upstream lifecycle of Debian and Ubuntu releases, that would give much better predictability for other teams (in terms of what build/testing environments we support) and for downstream users (in terms of what platforms are supported).
That being said, I think this policy would apply to the "bootstrap" images, and we could afford ourselves more flexibility for the other images (eg. podman, python et al)
Now that I think of it, I think I'd prefer if we aligned the image builds here with the upstream lifecycle of the releases themselves.
But what does that mean, concretely? Debian's bullseye has ended at
debian.org already, last August. It's supported by the Debian LTS, but
that's not "official" upstream. There's also ELTS.
In Ubuntu land, it's even worse: their "ELTS" is non-free... Should we
support that as well? :)
I guess I don't really see why the build roster should follow TPA's own upgrade schedule. Am I missing something?
I thought it was just being coherent.
In addition, if we say we align with the upstream lifecycle of Debian and Ubuntu releases, that would give much better predictability for other teams (in terms of what build/testing environments we support) and for downstream users (in terms of what platforms are supported).
Well, we've just started providing container images, so I'm not sure
people had any expectations or anything, we're really just making this
up as we go.
That being said, I think this policy would apply to the "bootstrap" images, and we could afford ourselves more flexibility for the other images (eg. podman, python et al)
Okay, so if I can rephrase your proposal, i think what you're proposing
is:
assume stable is N, old stable is N-1 and testing or "the next stable
after" is N+1
base-images, in general, should follow TPA's support schedule, which
is that we retire old stable (N-1) when we finish upgrading to stable
(N) and we start upgrading to stable during the freeze
"bootstrap" images (which I guess is the debian images?) should
support oldstable (N-1) longer, until we finish upgrading to the
next stable (N+1)
in any case, i took note of that issue in team#41990 (comment 3181336) and the next step here is likely to restore bullseye images for debian images here until we complete the trixie upgrade.
talked about this with @lavamind and a few points came up:
for bootstrap images (debian/ubuntu), he suggests we should support upstream OS as long as they do, and by that he means "LTS", essentially, for both Ubuntu and Debian (and not LTS, and not "just stable" for Debian)
for other images, we could just use the same policy, he doesn't feel the need to reduce the number of jobs or optimize the pipelines
keeping more images will reduce friction with other teams
he feels the policies between our base OS upgrades and the containers should be decoupled
we observed that the bullseye retirement went smoothly
anarcat likes the idea of keeping container images in lockstep with main OS upgrades as it provides an escape hatch for people
let's make a policy specifically for container images and remove that part from the trixie upgrade policy for now.