10:06 <pq> Why did I get a gitlab email about "Bugzilla Migration User created an issue: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/66" *yesterday* when the issue has not been touched in three years, was created and moved to its current place in gitlab 6 years ago?

10:14 <pq> That's not the only gitlab email sent and arrived yesterday telling me that a new gitlav issue has been opened, while it has been open for several years, and it's not only with bugzilla migrated issues either.

10:14 <pq> Did someone dig up a years old forgotten queue of gitlab notification events? :-)

10:16 <MrCooper> could be

10:16 <MrCooper> FWIW, our GitLab instance didn't exist 6 years ago, so presumably the creation date was faked to match the original bugzilla report

10:17 <MrCooper> looks like it has existed for over 3 years though, time flies!

10:21 <MrCooper> pq: looks like it's because these issues were moved from the wayland project

10:21 <MrCooper> to wayland-protocols

10:21 <pq> that happened many years ago

10:21 <pq> did it not?

10:22 <MrCooper> not according to https://gitlab.freedesktop.org/wayland/wayland/-/issues/20

10:22 <pq> huh!

10:23 <pq> but the note in #66 says " Simon Ser @emersion moved from wayland#20 (moved) 6 years ago"

10:23 <pq> so I thought it was just the migration script faking that date

10:23 <emersion> pq, i movedf it yesterday

10:23 <emersion> moved*

10:23 <pq> *bugzilla migration script

10:23 <emersion> by hand

10:24 <MrCooper> pq: huh, that sounds like a GitLab bug then

10:24 <MrCooper> also, would be nice if the notification e-mails made it clearer that the issue is moved, not newly created

10:24 <pq> emersion, by hand, as in, not via any Gitlab UI or API, but poking the database somehow?

10:25 <emersion> by hand, as in by clicking the button

10:25 <emersion> not by any API or automated way

10:25 <pq> oh, buggy gitlab then

10:25 <emersion> yea

10:25 <MrCooper> that's as literal as "by hand" gets :)

14:26 <__tim> Is this "newly-forked repositories are private by default" thing something that can be changed back to "are public by default" at the gitlab instance level?

14:26 <__tim> or was it something fdo admins changed on purpose?

14:27 <__tim> (I assume some default was introduced or flipped during some gitlab upgrade)

14:38 <MrCooper> FWIW, I just forked a repository on gitlab.gnome.org today, and none of the 3 choices were pre-selected IIRC

14:55 <daniels> I did actually look into the private-repo thing and I can't make heads or tails of why https://usercontent.irccloud-cdn.com/file/VYl0Lq9h/Screenshot%20from%202021-11-01%2014-55-30.png

17:03 <emersion> when i click "fork", the default is "public"

17:03 <emersion> but as soon as i select the namespace (my own personal one), it changes to "private"

17:24 <daniels> oh now that's interesting

18:59 <craftyguy> looks like most tags from here have been removed, are we expected to not use this registry anymore? https://gitlab.freedesktop.org/freedesktop/ci-templates/container_registry/

19:14 <daniels> craftyguy: er, most? I can still see loads ...

19:14 <daniels> e.g. there are 176 tags for F33

19:15 <craftyguy> daniels: hmm, yeah list view shows tags exist, but when I click on some, e.g. the one for arch linux, gitlab shows they were deleted

19:15 <craftyguy> after 'loading' for a while, this eventually shows there are no tags: https://gitlab.freedesktop.org/freedesktop/ci-templates/container_registry/7884

19:17 <craftyguy> http://0x0.st/-nx0.png

19:17 <bentiss> craftyguy: you are not supposed to use those images directly, outside of the 'buildah' or 'container-build*' images. the ones you can find here are ones we create for the CI of ci-templates, and are doomed to be removed

19:18 <daniels> craftyguy: they're still there, you just can't list them through the UI because performance is hard

19:18 <bentiss> they are created to ensure ci-templates is capable of using that specific distro

19:18 <craftyguy> ah. I'm basically just looking for a simple arch image to use for a linting CI stage. i can build one with ci-templates but that seems like overkill

19:18 <bentiss> so not for end user use

19:19 <craftyguy> to basically just replace something like `image: archlinux:latest`, without actually hitting docker hub

19:19 <bentiss> When I don't need to rebuild it often, I include ci-template, and mark the job as manual, so the job is never triggered unless I want to respin the image

19:21 <craftyguy> daniels: ah that solves the mystery of the missing tags that are really there :)

19:21 <bentiss> craftyguy: yeah, using skopeo to fetch for the image tags is usually faster and more accurate FWIW

19:22 <craftyguy> bentiss: is that used implicitly through ci-templates or are you suggesting I take another approach?

19:23 <bentiss> craftyguy: ci-templates is usually a good choice, yeah

19:23 <bentiss> should be just a few lines in your template

19:24 <bentiss> craftyguy: for instance: https://gitlab.freedesktop.org/freedesktop/helm-gitlab-omnibus/-/blob/master/.gitlab-ci.yml -> just turn the job 'container-prep' into manual and you can use just the lint one

19:25 <craftyguy> ya I got it working, it's just annoying having to now manage an image, and add a new stage to the pipeline to build it if it doesn't exist, when pulling some default image and installing a package in it would do the same thing without requiring space to store the new image, etc

19:25 <bentiss> craftyguy: well, complain to docker then :)

19:26 <craftyguy> I was secretly hoping some of those were proxied/cached at fdo :P

19:27 <bentiss> gitlab has a proxy cache integrated, but we haven't set it in place

19:28 <bentiss> FWIW https://docs.gitlab.com/ee/user/packages/dependency_proxy/ but I have no ideas if that has a GC or is just eating space for each and every project using it (it's per-project AFAICT)

19:28 <craftyguy> yeah I knew about the integrated proxy cache in gitlab, I should have started off here by asking about that

19:29 <craftyguy> got excited when I saw the /container_registry path in ci-templates project though, heh

19:29 <bentiss> "Blobs are kept forever on the GitLab server, and there is no hard limit on how much data can be stored.

19:29 <bentiss> that is... not very good for us :(

19:30 <craftyguy> ouch

19:30 <craftyguy> it's like gitlab was designed to eat cloud data storage

19:31 <bentiss> and the cleanup policy you can install is per-project, which means useless for us as we will have to go through every project

19:38 <anholt> getting some really low download perf from minio-packet https://gitlab.freedesktop.org/mesa/mesa/-/jobs/15328854

19:41 <daniels> anholt: sorry to hear that

19:41 <daniels> but I get 5.7MB/s on that file, limited only by TCP slow-start

19:42 <daniels> even annarchy gets ~6MB/sec, and that's the benchmark for broken networks ...

19:42 <daniels> being that slow screams packet loss to me tbh; is mtr enlightening?

19:42 <anholt> yeah, things work for me too. so does this runner have some issues?

19:46 <__tim> yeah, like 94% packet loss somewhere in the middle

19:49 <__tim> https://paste.gnome.org/picohbopi

19:49 <__tim> tcp is amazing

20:45 <daniels> anholt: oh, it's Hetzner - I just saw the filename and thought it was a fdno DUT

20:47 <anholt> tbf I feel like I've had some really rough downloads from packet on fdno, too.

20:47 <anholt> we've definitely got Something going on with traces.

22:29 <__tim> I don't think this is a one-off though, I've seen this before between hetzner and packet, it's beyond normal