06:59 <slomo> hi! does someone know what's wrong with the failing jobs at https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/pipelines/410491 ? after retrying many times they usually pass but that doesn't seem like a solution :)

06:59 <__tim> registry needs to be kicked again it seems

07:00 <bentiss> slomo: yep, just kicked the registry once again

07:00 <bentiss> should be good now

07:03 <slomo> let's try again then, thanks

07:09 <slomo> seems better :)

07:18 <bentiss> \o/

07:46 <MrCooper> bentiss: it wasn't this bad when we started using the cache, was it? Any idea what changed to make it worse?

08:09 <bentiss> MrCooper: see the backlog -> https://github.com/distribution/distribution/issues/2367 -> basically, whenever a tag expires, it also deletes the attached blobs, and if an other image reuses it, it doesn't have the file anymore

08:10 <MrCooper> Mesa tags don't expire though

08:10 <MrCooper> or you mean when the cache entry expires?

08:12 <MrCooper> hmm, or I guess it could be due to other images sharing a distro image blob

08:13 <bentiss> well, the expiration policy is different on the cache proxy: if a tag is not pulled for 7 days, it will expire and the cleanup will clear the data

08:14 <bentiss> so if you pull from MrCooper/mesa/debian-foo:bar, which is a plain copy of mesa/mesa/debian-foo:bar, after 7 days, if you do not pull it once again, it will clear the related blobs and will clear the ones for mesa too

08:15 <bentiss> AFAUI, it's done at the tag level, not at the blob, which is the proble her

08:15 <bentiss> e

08:16 <MrCooper> not sure how that can matter though, if the cache needs to be kicked every (other) day? :)

08:17 <bentiss> MrCooper: right now it's more like every 12h :(

08:18 <bentiss> MrCooper: yesterday I decided with myself that I would write a job to prune the cache every Sunday

08:18 <bentiss> this should give a compromise between how much we spend pulling images and not having failed jobs

08:19 <MrCooper> makes sense

14:04 <daniels> emersion: hey, re sway ... hmm.

14:05 <daniels> as for Weston, it's legendarily not a desktop, and in fact what we're trying to do is to prune it down to the equivalent of tinywl + kiosk-shell in-tree, and strip even more of desktop-shell so it's a super bare-bones example and doesn't even try to do stuff like exposay - and have that hosted somewhere else externally

14:05 <daniels> so that would point to a parallel of wlroots on fd.o + sway elsewhere

14:06 <emersion> ah, interesting

14:06 <emersion> maybe it would make sense to have a weston org as well at some point…

14:06 <emersion> or yeah, dunno

14:07 <daniels> I'd be happy to move it out, and have separating the websites on my list as well

14:07 <daniels> just been waiting for sufficient boredom :P

14:07 <emersion> ahah :P

14:08 <emersion> where would you be hosting weston-desktop if you had to move today?

14:08 <emersion> collabora gitlab?

14:08 <daniels> anyway, fd.o was set up to be ultra scrupulously neutral between desktop envs, so hosting desktop envs was always an anti-goal, because there was this perception for a while that anything fd.o did was 'blessed' and that hosting a desktop env would destroy the ability for desktop envs to collabora

14:08 <daniels> te

14:08 <emersion> ah i see

14:08 <daniels> emersion: good question. maybe gitlab.com? I don't think gitlab.c.c lets you register

14:09 <daniels> and if there's one thing we need it's probably not less community :P

14:09 <emersion> ahah

14:09 <emersion> alright, makes sense to me!

14:09 <emersion> thanks for the feedback

14:09 <emersion> i'll look into other options

14:09 <daniels> anyway, that's where things are - I'm pretty neutral on potentially changing that, would be one for x.org people I guess

14:09 <daniels> (I really don't want to move off gitlab.fd.o tbh, if only because setting up CI yet again == pain)

14:10 <emersion> would ci-templates work on gitlab.com?

14:10 <emersion> hmm… something something custom kernel?

14:11 <daniels> custom kernel?

14:11 <daniels> ci-templates would work if we had the freedesktop org secured (can't remember if we do or not) but you'd have to BYO runners

14:11 <emersion> custom kernel for vkms and such

14:12 <emersion> hmmm

14:12 <emersion> much pain

14:13 <emersion> maybe i'll write a proposal to allow desktops on gitlab.fd.o again

14:14 <emersion> if it's open for everybody, it's not like one project would be "blessed" and not others

14:14 <daniels> oh, the kernel on the runner itself doesn't matter

14:15 <emersion> ah right, VMs

14:15 <daniels> since we start in qemu

14:15 <daniels> yeah

14:15 <emersion> GNOME and KDE have their own gitlabs, but for other desktops setting up a gitlab is a lot of effort

14:15 <emersion> also… argably monado is a desktop

14:24 <daniels> Monado?

14:24 <daniels> it's just an implementation of a Khronos standard

14:25 <daniels> xrdesktop is definitely much closer to that line, but then rather than building up its own world, it just plugs into all the other various desktops

14:26 <daniels> I was going to say that I recused myself from the decision to host xrdesktop since it's Collabora-backed, but then I looked at https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/177 and apparently I didn't :\

14:50 <ajax> we did have an enlightenment download mirror for a while though

14:50 <ajax> just downloads though, not mailing lists or bzs

14:50 <emersion> ah right xrdesktop

14:54 <ajax> daniels: to the larger point about hosting DEs, i'm... undecided. part of me thinks that part of the mission focus is maybe misguided now.

14:55 <ajax> i don't know how much authority i have to determine fdo direction, certainly i'm not pulling my admin weight, but.

15:02 <emersion> ajax: would be useful to have a definition of a DE

15:04 <daniels> emersion: oh god

15:05 <emersion> :P

15:06 <ajax> hah. sort of my point, yeah. it's not like these are sharp lines.

15:07 <ajax> i can certainly see the argument for fdo staying far clear of any such discussion for the sake of remaining switzerland

15:07 <daniels> anyway, yeah, I'm at this point leaning towards the mission + environment + community having changed a lot, and with the infrastructure load having changed from per-project to infra-global (i.e. previously running the servers was p trivial but managing all the projects was hard; now adding projects is basically free and all our problems are ceph) we don't need to be quite so picky about the hosting

15:07 <daniels> ajax: I sort of see that, but otoh xdg@ is dead anyway and no-one cares enough to even pretend to maintain it

15:09 <ajax> freedesktop platform release 2.0

15:10 <emersion> my main point is that gitlab.fd.o could provide a lot of value for DEs which aren't able to maintain their own infra

15:10 <emersion> and allow them to leave github if so they wish

15:11 <daniels> ajax: you are seriously undermining a lot of time in therapy

15:11 <emersion> btw… sway/wlroots won't be using the shared FDO runners

15:11 <daniels> emersion: yeah, totally agree

15:11 <ajax> hahahahaha

15:11 <daniels> heh, I did see the sourcehut runner

15:11 <emersion> so overhead should really be zero

15:11 <emersion> ah :P

15:12 <emersion> let me know if the runner is making too many requests or something btw

15:12 <emersion> apparently just hammering requests is the official way to poll for new jobs

15:12 <emersion> (gitlab-runner polls every 3s, sourcehut runner every 10s)

15:13 <bentiss> gitlab-runners are a tiny drop in the amount of requests we have, so fine by me

15:13 <daniels> ^

15:14 <daniels> if you manage to be anything but extreme line noise, I'll be too impressed to be annoyed

15:14 <emersion> okay!

19:28 <daniels> emersion: btw, to take this further, could you please email board@f.x.o?

19:29 <emersion> will do!

19:30 <daniels> emersion: merci! empty-lease review coming tomorrow btw, and leandrohrb is working on dmabuf-hints revision

19:30 <emersion> oh sweet!

19:31 <emersion> i'll do the final s/hints/feedback/ soon

19:31 <daniels> if that's our biggest problem, I'll be very pleased

19:32 <emersion> naming is always the biggest problem

19:32 <daniels> so what you're saying is if we just decide the name for liballocator then we're all good?

19:37 <airlied> daniels: isn't it called libgbm :-P

19:38 <daniels> airlied: congrats, you own it

19:38 <daniels> look forward to the results

19:55 <emersion> ship it!

20:51 <dcbaker> Nvidia just needs a Mesa driver, and the whole problem is solved :D