Publicizing certain repositories

Infrastructure
1

There are few gnome gitlab repositories that were used as a link for dependencies like NixOS registry. For example: vte

However, after gitlab got private and forces users to log in before they access to repositories, now packages are failing at build and are broken. I believe, there are many packages that are getting flagged broken for not being able to access repositories within build farms.

Is there any chance we can publicize number of repositories in gitlab and make them available (open) for anyone?

2

If the answer is no, can we consider mirroring repositories to GitHub?

3
  1. Is something broken on your site? Plain HTTPS should just work, but I will let myself have corrected by the infrastructure team on this
  2. It already is mirrored to github, but see 1
1 Like
4

What? Who got private? GNOME / vte · GitLab is publicly available

All GNOME software repos are publicly available, except for some security related things.

git clone https://gitlab.gnome.org/GNOME/vte.git

works fine for me.

1 Like
5

GNOME GItLab is intentionally configured to rate limit non-login requests, which would cause some requests to fail. Refer this post.

@orzklv: Did you mean the rate limited failures as pointed above, or 100% failure ?

1 Like
6

Why not use a release tarball from download.gnome.org? download.gnome.org is mirrored and not subject to rate limiting, and is where we publish release artifacts ready for packaging.

1 Like
7

According to the Readme file there:

Vte is not released with tarballs anymore. To get the source for a release version, use the corresponding git tag, or download a tarball at https://gitlab.gnome.org/GNOME/vte/-/archive/TAG/vte-TAG.tar.bz2 replacing TAG with the desired tag’s name. Older releases are still available here.

Though, @orzklv, I don’t know how the fetchFromGitlab on nixpkgs is working currently on fetching the source, but a Git tag should be the most efficient solution then, right?

2 Likes
8

Oh, apologies, I didn’t realise that vte opts to not use download.gnome.org. That’s a departure from what other GNOME modules do, so I didn’t check the readme.

2 Likes
9

I’m not sure about the benefits of using gitlab package registry over download.gnome.org, but I guess we should stick with one. Else, it’s going to be a source of confusion for packagers.

2 Likes
10

Hello everyone, I apologize for late response.

After playing around more and digging more into the codebase (which wasn’t written by myself initially), I managed get vte4 compiled successfully and I found out that it was the rate limit blocking my build machine. I read all suggestions regarding to download.gnome.org and I’m planning to attempt to rewrite packages using archives provided in downloads. Thanks to everyone for mentioning it, it was really my first time when I’ve heard about it.

Also, amongst the packages of the project I was working on, there were links to user repositories like: https://gitlab.gnome.org/vlinkz/vte4-rs which also was one of many causes why I was failing at building from sources. Later, I found vte4 in crates.io and many more. Currently, I’m porting all dependency links from gitlab to crates.io.

Thank you all very much for your attention and sharing, I really appreciate it. <3

1 Like