09:24 <mkorpershoek> narmstrong: the linux-meson.com website sources have been relocated to https://gitlab.baylibre.com/baylibre/amlogic/linux-meson.com . I don't know if you still use this but prefered to give a head's up anyways

09:26 <narmstrong> mkorpershoek: thx yes I still use it, thx for the notification

09:26 <mkorpershoek> ok. you should still have access to the one on gitlab.com but that will drop very soon. please update your remotes on your end

09:27 <narmstrong> mkorpershoek: I moved the website on gitlab.com so any people could push some changes via MRs, but now on the private baylibre instance it's not more possible :-/

09:28 <mkorpershoek> Everything that used to be public on gitlab.com will be public again on gitlab.baylibre.com. We had some migration problems with permissions. It's the same for the ATV tree. it should be public again later today

09:29 <narmstrong> mkorpershoek: ok for public access, but public submission is no more possible without an account on gitlab.baylibre.com

09:30 <mkorpershoek> indeed :'( and creating an account on gitlab.baylibre.com for a (maybe) one-off contribution seems to big of a hassle

09:34 <mkorpershoek> On another note: i've not forgotten about migrating the usb stack to DM on u-boot. I've started something but it's not completely working as I want. especially around controller disconnections. It's a little low on my todo for now but I'll try to give some more details in the coming weeks

09:34 <narmstrong> anyway thx for ther notice, I'll update the source url on the website

09:35 <narmstrong> mkorpershoek: ok no prob, ping me if you need any help

09:38 <mkorpershoek> will do, whenever I spend some real time on it and actually will be stuck

09:41 <narmstrong> mkorpershoek: CI is stuck on https://gitlab.baylibre.com/baylibre/amlogic/linux-meson.com/-/pipelines it seems the shared runner doesn't take the job

09:42 <mkorpershoek> weird. It should take it. I'm having a look

09:45 <mkorpershoek> narmstrong: should be good now. I asume that the shared runner was not configured before the MR started. We only have a single runner for default jobs (such as doc) so it might be a little slower than the gitlab.com instance.

09:46 <narmstrong> mkorpershoek: indeed now it's ok, thx ! no prob for the slowness