Please consider adding gitlab to sync blacklist

[Jeremy Bícha]

I spent some time looking over gitlab's website and I couldn't find a clear mention of how long releases are supported for or there are any LTS series. gitlab makes new releases every month.

Unless someone commits to supporting gitlab in Ubuntu stable releases, it feels like it's a disservice to users to have a package like this in our stable releases.

It might be ok to have it in -proposed only (or otherwise removed from Ubuntu before stable releases are made), but at that point, it feels like it might be better to just not have it in Ubuntu at all since we don't want to encourage people to run -proposed during the development cycle.

[Simon Quigley (tsimonq2)]

I agree with this.

From a security standpoint, it's a bit of a nightmare. Nobody who cares about their security would actually use the package in production...

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Jeremy Bícha (jbicha)]

Ok, I found a policy [1]. My understanding is that there is no LTS branch. You need to update monthly to be under support. This is similar to how web browsers and webkitgtk are managed except that no one has stepped up to handle these releases for Ubuntu and get the Release Exception.

Unlike something like WordPress, I expect that at least the new major releases (not done as often as monthly releases) to require updated dependencies. But I haven't investigated whether that's true.

(Although WordPress doesn't advertise it, they do provide security releases for old versions so WordPress is supportable if someone just does the work to prepare and verify the updates.)

[1] https://docs.gitlab.com/ee/policy/maintenance.html

[Steve Langasek (vorlon)]

Agreed, added to blacklist.

[Shengjing Zhu (zhsj)]

I find several gitlab components are still in archive, shouldn't they be blocked together? (not useful without gitlab package)

[Jeremy Bícha (jbicha)]

gitlab-shell can be used to access remote Gitlab servers. It is not required to have Gitlab installed on the same machine as gitlab-shell.

[Shengjing Zhu (zhsj)]

@jbicha, hmm how can gitlab-shell be used to access remote Gitlab servers? AFAIK, gitlab-shell is used as a login shell on gitlab server when doing git operation through ssh protocol.

https://docs.gitlab.com/ee/development/gitlab_shell/

[Jeremy Bícha (jbicha)]

Ok, sorry I misunderstood what gitlab-shell was.

[Chris Halse Rogers (raof)]

Someone seems to have cared enough about gitlab-shell recently to request a sync from Debian: https://bugs.launchpad.net/ubuntu/+source/gitlab-shell/+bug/2024202. I'm not sure if that indicates that there are sensible uses for it, though. I've requested further information.

[Steve Langasek (vorlon)]

y'all can make a recommendation as to whether gitlab-shell or shouldn't be removed, but this bug should NOT be tagged block-proposed, as this prevents the new version of gitlab-shell from being released from mantic-proposed and the old version build-depends on golang-gitaly-proto-dev which has been removed in Debian.

[Jeremy Bícha (jbicha)]

gitaly is currently in noble and noble-proposed so a removal would need to remove it from both places

[Sebastien Bacher (seb128)]

Removing packages from noble:
 gitaly 16.0.8+ds1-1 in noble
  gitaly 16.0.8+ds1-1 in noble amd64
  gitaly 16.0.8+ds1-1 in noble arm64
  gitaly 16.0.8+ds1-1 in noble armhf
  gitaly 16.0.8+ds1-1 in noble ppc64el
  gitaly 16.0.8+ds1-1 in noble riscv64
  gitaly 16.0.8+ds1-1 in noble s390x
  gitlab-common 16.0.8+ds1-1 in noble amd64
  gitlab-common 16.0.8+ds1-1 in noble arm64
  gitlab-common 16.0.8+ds1-1 in noble armhf
  gitlab-common 16.0.8+ds1-1 in noble i386
  gitlab-common 16.0.8+ds1-1 in noble ppc64el
  gitlab-common 16.0.8+ds1-1 in noble riscv64
  gitlab-common 16.0.8+ds1-1 in noble s390x
  golang-gitlab-gitlab-org-gitaly-dev 16.0.8+ds1-1 in noble amd64
  golang-gitlab-gitlab-org-gitaly-dev 16.0.8+ds1-1 in noble arm64
  golang-gitlab-gitlab-org-gitaly-dev 16.0.8+ds1-1 in noble armhf
  golang-gitlab-gitlab-org-gitaly-dev 16.0.8+ds1-1 in noble i386
  golang-gitlab-gitlab-org-gitaly-dev 16.0.8+ds1-1 in noble ppc64el
  golang-gitlab-gitlab-org-gitaly-dev 16.0.8+ds1-1 in noble riscv64
  golang-gitlab-gitlab-org-gitaly-dev 16.0.8+ds1-1 in noble s390x
  ruby-gitaly 16.0.8+ds1-1 in noble amd64
  ruby-gitaly 16.0.8+ds1-1 in noble arm64
  ruby-gitaly 16.0.8+ds1-1 in noble armhf
  ruby-gitaly 16.0.8+ds1-1 in noble i386
  ruby-gitaly 16.0.8+ds1-1 in noble ppc64el
  ruby-gitaly 16.0.8+ds1-1 in noble riscv64
  ruby-gitaly 16.0.8+ds1-1 in noble s390x
Comment: not compatible with the new libgit2, remove from debian testing, lp #2046034
Remove [y|N]? y
1 package successfully removed.

[Sebastien Bacher (seb128)]

Removing packages from noble:
 gitlab-shell 14.20.0+ds1-2build1 in noble
  gitlab-shell 14.20.0+ds1-2build1 in noble amd64
  gitlab-shell 14.20.0+ds1-2build1 in noble arm64
  gitlab-shell 14.20.0+ds1-2build1 in noble armhf
  gitlab-shell 14.20.0+ds1-2build1 in noble ppc64el
  gitlab-shell 14.20.0+ds1-2build1 in noble riscv64
  gitlab-shell 14.20.0+ds1-2build1 in noble s390x
  golang-gitlab-gitlab-org-gitlab-shell-v14-dev 14.20.0+ds1-2build1 in noble amd64
  golang-gitlab-gitlab-org-gitlab-shell-v14-dev 14.20.0+ds1-2build1 in noble arm64
  golang-gitlab-gitlab-org-gitlab-shell-v14-dev 14.20.0+ds1-2build1 in noble armhf
  golang-gitlab-gitlab-org-gitlab-shell-v14-dev 14.20.0+ds1-2build1 in noble i386
  golang-gitlab-gitlab-org-gitlab-shell-v14-dev 14.20.0+ds1-2build1 in noble ppc64el
  golang-gitlab-gitlab-org-gitlab-shell-v14-dev 14.20.0+ds1-2build1 in noble riscv64
  golang-gitlab-gitlab-org-gitlab-shell-v14-dev 14.20.0+ds1-2build1 in noble s390x
Comment: gitlab is not supported in Ubuntu, lp #1758702
Remove [y|N]? y
1 package successfully removed.

[Paul Mars (upils)]

It looks like a new version of gitaly was re-uploaded in December. seb128 can you remove it?

Is there a way to automatically prevent future uploads on packages we do not want in the archive anymore?