01:51 <robclark> random q: is there a way to have public gitlab issue but private attachments (ie. for attaching trace of closed src game)?

03:42 <robclark> tomeu, daniels: Maybe something not entirely happy at collabora farm.. maybe a flake? https://gitlab.freedesktop.org/mesa/mesa/-/jobs/34668569

03:43 <robclark> of maybe on gitlab side, idk.. I re-ran some similar fails and they passed the next time..

03:50 <gallo[m]> From the logs, it is an error 500 during artifacts uploading to the Gitlab server, so it should be an internal problem/bug in Gitlab.

05:42 <robclark> gallo[m]: new run after fixing some `UnexpectedPass` (since my earlier esting overlooked somehow the a618 runners) resolved the issue, so I guess it was some transient hickup ?

08:45 <daniels> robclark: yeah, a 500 from gitlab.fd.o means the GL server is unhappy for some reason; it’s slmost always temporary

10:03 <bentiss> daniels: FWIW, starting to enable the registry db now: the db is now created, as following https://docs.gitlab.com/charts/charts/registry/#creating-the-database

10:25 <bentiss> daniels: and registry db backend is enabled for new repos

10:33 <daniels> oooh!

10:33 <bentiss> well: FATA[0004] copying system image from manifest list: writing blob: initiating layer upload to /v2/bentiss/test-minio/alpine/blobs/uploads/ in registry.freedesktop.org: errors:

10:33 <bentiss> denied: requested access to the resource is denied

10:33 <bentiss> unauthorized: authentication required

10:33 <bentiss> this should be only for new repos

10:39 <bentiss> right, so uploads are borked

10:57 <bentiss> *maybe* it is my local credentials that are borked, because a ci-templates run seems perfectly fine

10:58 <bentiss> "read_registry", that was the name of my token :)

11:02 <bentiss> daniels: alright, flase alert as mentioned above: the registry db works fine, so do uploads

11:02 <bentiss> false

11:11 <bentiss> daniels: as a test, I created a new alpine image with a "curl" layer. Pushed it to a new repo (registry.freedesktop.org/bentiss/test-minio/alpine:curl) and deleted the tag. Normally, tomorrow at noon the blob fdo-gitlab-registry/gitlab/docker/registry/v2/blobs/sha256/d7/d760d33c8c1cf959ce19130f9cc1f9635bc0e6d1216ebec6a186f9d9425bb2a4 should be removed if online gc kicked in

11:11 <bentiss> properly

11:14 <daniels> woooosh

11:14 <daniels> super exciting!

11:36 <bentiss> daniels: so using the registry database import tool fails at copying the blobs. It expects a different gcs bucket when the migration tool expects the same bucket but a different root directory

11:37 <bentiss> I need to try the import through ruby