daniels changed the topic of #freedesktop to: https://www.freedesktop.org infrastructure and online services || for questions about freedesktop.org projects, please see each project's contact || for discussions about specifications, please use https://gitlab.freedesktop.org/xdg or xdg@lists.freedesktop.org
karolherbst has quit [Remote host closed the connection]
karolherbst has joined #freedesktop
karolherbst has quit [Remote host closed the connection]
karolherbst has joined #freedesktop
karolherbst has quit [Remote host closed the connection]
<mripard>
I don't know if you've seen though, the i915 group wasn't public so i915/kernel isn't public anymore
<DragoonAethis>
Yes, waiting for Rodrigo to come back online
<DragoonAethis>
For the repos itself, I don't have permissions myself to do anything on the fd.o side - I can only poke the CI side :(
<mripard>
I can do it, do you only want to change the visibility?
<DragoonAethis>
Yes please!
<mripard>
done, it's public now
<DragoonAethis>
Looks like drm/i915/kernel is still private
<mripard>
indeed, it should be ok now
jkhsjdhjs has joined #freedesktop
<DragoonAethis>
Works, thank you!
<rodrigovivi>
mripard: thank you so much
<mripard>
rodrigovivi: yw
<rodrigovivi>
mripard: next is the repos, but I'm still trying to understand what are the 'templates' jani had mentioned and how to set them there in the main branch like you suggested... oh, and which branches we really want to move and keep...
<mripard>
my guess from a distance are that the issue templates in .gitlab/issue_templates in the main branch
<mripard>
so they are already there, and the main branch is already the default
<mripard>
what I was suggesting the other day was to just add your branches to that repo but *without* changing the default branch from main to -next like we did for the other repos
<mripard>
so I guess just figure out the branches you want to keep, push them to the gitlab repo, and you're done
<rodrigovivi>
ahh, cool, and then we update the manifests and let daniels to know when they are all there and he can setup the mirrors... anything else?
<mripard>
the most reliable would be to mark the cgit repos read only first
<mripard>
then you push the branches from cgit to gitlab, merge the rerere patches and finally setup the mirorring
<mripard>
but yeah, you'll need either daniels or bentiss around :)
scrumplex_ has joined #freedesktop
<daniels>
sure, what do you need?
<bentiss>
FWIW I'm around until Thu end of the day
<mripard>
rodrigovivi: all the steps are in that freedesktop issue really
<daniels>
I'm gone from 3-6pm UK (i.e. 1h from now) but generally around otherwise
<DragoonAethis>
mripard: AFAIK i915 is the last repo to move from cgit to gitlab?
<daniels>
yeah
<DragoonAethis>
okay
<DragoonAethis>
how about we do it now?
<daniels>
well, maybe ~agd5f/linux for amd is still left
<daniels>
DragoonAethis: yes very please
<bentiss>
daniels: I can handle it if you want (like I did the other ones)
<bentiss>
or we can play "who's the fastest?" :)
<bentiss>
ouch, that reminds me that we have a (low) security upgrade pending and a gitlab minor bump to do eventually
scrumplex has quit [Ping timeout: 480 seconds]
<daniels>
bentiss: super happy to leave it in your capable hands :)
<bentiss>
daniels: OK, works for me
<bentiss>
first time it was hard, but the second was easy
<bentiss>
hopefully the third will be easy as well
<bentiss>
DragoonAethis: so ping me whenever you need!
<DragoonAethis>
rodrigovivi: There are 14 branches on drm-intel, with 5 being untouched for 3+ years, so IMO you can pull/push these to GitLab and drop the rest: drm-intel-fixes drm-intel-gt-next drm-intel-next drm-intel-next-fixes for-linux-next for-linux-next-fixes for-linux-next-gt topic/core-for-CI topic/thunderbolt-next
vkareh has quit [Read error: Connection reset by peer]
<DragoonAethis>
The rest being: drm-intel-gt-next-backup drm-intel-next-queued drm-intel-testing topic/drm-intel-gem-next maintainer-tools
<DragoonAethis>
bentiss: I don't have permissions to do anything with the repos, just the CI side, but rodrigovivi is around and can do it
vkareh has joined #freedesktop
<DragoonAethis>
So please help me coerce him to do it now :)
<bentiss>
heh
<DragoonAethis>
If the mirrors get set up, then CI side just keeps humming along, nothing to see here for now
<bentiss>
I think we'd need the drm/i915/kernel repo to be slightly more populated before we enable mirroring, no?
<bentiss>
unless I'm looking at the wrong repo
<DragoonAethis>
You're looking at the correct repo, just need someone with perms to push it
<bentiss>
should I click "update fork"?
<bentiss>
(I guess it would be best to clone it locally first
<bentiss>
)
<mripard>
bentiss: the way I did it was to fetch each branch from cgit and push it to gitlab
<DragoonAethis>
bentiss: If you have a way to replace the contents with another repo, then go ahead
<DragoonAethis>
Or if you could grant me perms to do it, I'll do it
<mripard>
there might be a smarter way to do it though :)
<daniels>
bentiss: merci <3
<bentiss>
mripard: as I read it, the "update fork" should preserve the blobs from drm/kernel, so slightly more efficient. But it might overwrite the main brnach
<DragoonAethis>
I have it cloned so sure, go ahead
<bentiss>
same :)
<bentiss>
it's working...
<bentiss>
DragoonAethis: what's your gitlab username please?
<DragoonAethis>
bentiss: got it all cloned and and ready to push
<DragoonAethis>
DragoonAethis too
<DragoonAethis>
(username cons: long and annoying for most, pros: free and universal everywhere except my employer's LDAP :)
<bentiss>
ok, you are now owner, you can push all of the branches you wish
<DragoonAethis>
whee, I can now use the --force
<jani>
after everything is done, is there a way to remove the "Forked from drm / kernel" relationship in gitlab?
<rodrigovivi>
DragoonAethis: may the --force be with you
<DragoonAethis>
jani: there is, but the relationship makes it easier on the backend to keep multiple repo copies around
<bentiss>
jani: yes, there is a way, but why?
<bentiss>
jani: the whole point of having a fork graph is to keep git deduplication to a maximum, so breaking it is not so great
<jani>
idk feels kind of dumb because the fork relationships don't really reflect real world
<DragoonAethis>
They don't, but it makes GitLab keep it all under a single actual Git repo on the server side, and the repos are mostly logically separated on the web side
<DragoonAethis>
But while we're on this topic, drm/xe/kernel, drm/nouveau, drm/msm, drm/tegra could use a repush to restore the fork relationship too
<jani>
feels like in retrospect we should've added a "root" kernel project mirroring Linus' tree, and forking all the kernel trees from that
<DragoonAethis>
How many non-DRM kernels are hosted on fd.o anyways?
<daniels>
huge piles of those jobs are kernelci which run at the lowest priority
<DavidHeidelberg>
nope, we have problem 1/9 devices is available
vkareh has quit [Read error: Connection reset by peer]
<DragoonAethis>
bentiss: Looks like the fork worked but a push still tries to shove 10kk objects to the other side on the initial push
<DragoonAethis>
It'll work, but it's going to take... a while...
<bentiss>
DragoonAethis: well, just ping me when it's done :)
<DragoonAethis>
sure :)
<DavidHeidelberg>
daniels: hmm.. but something is running, anyway I think I have to reduce number of the jobs for now
<DragoonAethis>
Let's keep drm-intel read-write for now, to avoid breaking workflows - we can repush diffs, I'll just notify people not to rebase anything in the meantime
<DavidHeidelberg>
eric_engestrom: do u have some pipeline stuck at it?
<daniels>
DavidHeidelberg: 'available' means devices which aren't running anything and can take a job immediately
<daniels>
6 of the devices are running Mesa jobs which started very shortly ago
<daniels>
and I pinged about cbg-5 which is stuck in a weird state
<bentiss>
DragoonAethis: I haven't touched anything on cgit right now. The idea is that we flip the switch when things are roughly equivalent
<DragoonAethis>
bentiss: Yeah, that's good, I'll let you know when the initial push finishes from my side
<bentiss>
thanks
<daniels>
eric_engestrom: so no, no structural problem on limozeen, just that you're running a few pipelines on stable branches, hakzsam is running pipelines on a CTS-uprev branch, drm-msm people have been running pipelines on msm-next, etc
<DragoonAethis>
I'm currently enjoying pushing 2.5GB of Git objects at 461KiB/s and how's your day going
blatant has quit [Quit: WeeChat 4.2.2]
<bentiss>
DragoonAethis: are you limitted by your provider or by gitlab?
<bentiss>
it might be faster if I do it myself...
<DragoonAethis>
bentiss: provider, it might be faster if I switch to LTE lol
<bentiss>
DragoonAethis: ok, let me do it from my fiber connection
<bentiss>
noit sure I can pull directly from the gitaly pod itself, but I can try
<DragoonAethis>
Maybe not, but you can push from cgit
<DragoonAethis>
Okay, aborting the push on my side
<eric_engestrom>
daniels, DavidHeidelberg: ack, thanks for looking into it :)
<daniels>
np
<eric_engestrom>
and DavidHeidelberg no, nothing stuck on it, just working on the next mesa release and lava's "start running the job but don't actually run the job and wait until the device is available and then timeout before the job gets to actually run" is making me having to retry jobs *tons* of times :/
<eric_engestrom>
I'm only retrying a couple at a time now, but it's really not a good UX
<daniels>
well, we could make the timeout infinite?
<daniels>
or increase the priority for your jobs to something higher than others but lower than marge
<daniels>
but I'm not sure what the third option is
<eric_engestrom>
I shouldn't get priority
<eric_engestrom>
the third option is "don't start running the job until you're able to run the job" :P
<eric_engestrom>
but IIRC that's not possible with LAVA's design, right?
<eric_engestrom>
anyway, I was just annoyed and when I had a look the huge queue made me think something might be going wrong
<daniels>
it's possible if we use the rewritten gitlab-runner yeah
<eric_engestrom>
ack
<eric_engestrom>
well, I'm looking forward to when you get around to that, but I know you have tons of other things to do too :)
bmodem has quit [Ping timeout: 480 seconds]
<bentiss>
DragoonAethis: looks like it's done, but the weird part: Writing objects: 100% (4132/4132), 811.50 KiB | 12.11 MiB/s, done.
<DragoonAethis>
3 years old+ branches cleaned up, can you push the tags too?
<bentiss>
the git repack probably happened between your push and mine, and it was able to reuse the same packs
<bentiss>
DragoonAethis: once the gitlab remote cleanup is done, IIRC mripard changed the rerere branch first, so that dim was happy with the new location, and then we marked it as read-only on cgit for everyone but gitlab-mirror
<DragoonAethis>
bentiss: old branches are removed, but please push the tags too and we're all clear
<DragoonAethis>
bentiss: not sure if there's a list for rerere stuff as drm/tip is autogenerated on push from dim
<DragoonAethis>
rodrigovivi: Do you have push rights to drm/tip?
<DragoonAethis>
bentiss: pushed tags lgtm
<bentiss>
DragoonAethis: OK, so should I mark cgit as read only?
<DragoonAethis>
bentiss: if rerere etc can live without the correct repos in the meantime, sure
<bentiss>
I'm not 100% sure... daniels, mripard would the above ^^ be a problem?
<daniels>
I'm out atm but if DragoonAethis doesn't have push rights to drm-tip for some reason we can just give them to him
<DragoonAethis>
daniels: "some reason", namely me being the CI guy here, and not a developer ;p
<bentiss>
daniels: do I have to add him to a group on gitlab or directly to drm-tip?
<bentiss>
DragoonAethis: AFAICT, you are trusted enough to not push anything bad, and we can revert the permission once it's done if you want
<DragoonAethis>
bentiss: Alright, go ahead then, I'll update nightly.conf
<bentiss>
DragoonAethis: added you in the drm/i915 group, so you should have push right to drm-tip
<bentiss>
(and dropped you from being a direct member of drm/i915/kernel, so you only have one place to look at)
<DragoonAethis>
bentiss: can I push to the rerere-cache branch with the cookie or do I have to go through dim anyways?
<DragoonAethis>
(I don't want to rebuild the tip or anything, just push a single file)
DodoGTA has quit [Quit: DodoGTA]
<bentiss>
DragoonAethis: you have to go through dim IIRC. We have the same pre-receive hook than what is currently on cgit/drm-intel...
DodoGTA has joined #freedesktop
<DavidHeidelberg>
daniels: ...mornings, sorry bout that confusion :D
<bentiss>
DragoonAethis: FWIW I have a meeting for the next hour. In case it's too late after, we can postpone the migration to tomorrow
<DragoonAethis>
bentiss: I'm setting up the dim stuff for the first time so it might take an hour or so
<DragoonAethis>
orrr not?
<DragoonAethis>
okay, stand back, I'm gonna try pushing and seeing if the world breaks
<bentiss>
the worlsd always breaks :)
<DragoonAethis>
Okay, not sure how to proceed - I have the setup where src has the kernel, drm-rerere has a rerere-cache worktree checkout, and now I should just ./dim push-branch rerere-cache
<DragoonAethis>
That complains src is not on rerere-cache branch, but that is in a separate worktree and I can't just "unmount" that worktree because other things will break
<bentiss>
don't know, I'm not a dim user myself.... anyone???
* DragoonAethis
quietly pretends not to see the dim_fdo_cookie variable
scrumplex_ has quit [Quit: Quassel - Signing Off]
scrumplex has joined #freedesktop
mrpops2ko_ has quit []
scrumplex has quit [Quit: Quassel - Signing Off]
scrumplex has joined #freedesktop
<mripard>
DragoonAethis: this should all be reviewed, really
bbhtt has left #freedesktop [#freedesktop]
AbleBacon has joined #freedesktop
<DragoonAethis>
mripard: ack, patch to the Intel driver ML?
<mripard>
I guess, with dri-devel in Cc
<mripard>
also, a heads up would have been nice.
<bentiss>
mripard: so far nothing has been done, except for populating the gitlab mirror
<mripard>
We've been discussing it for months, it's frustrating to learn it was finally happening through a gitlab notification.
ximion has joined #freedesktop
<mripard>
so step 1 would be to send the MAINTAINERS, dim and rerere patches to the list so they can all be reviewed and everything is queued nicely
<DragoonAethis>
Okay, sorry for rushing on this - I'll send out the patches in a bit
<bentiss>
mripard: which gitlab otification are you talking about?
<mripard>
bentiss: I received an automatic mail that the i915 repo has moved, it's why I started the conversation here
<bentiss>
k
<daniels>
mripard: sorry you were surprised, should’ve said to ping you instead of just urging it to get done soon
navarre has joined #freedesktop
f_ has quit [Ping timeout: 480 seconds]
<jani>
I thought this was just prep work for getting everything in place before actually flipping the switch
mvlad has quit [Remote host closed the connection]
<rodrigovivi>
mripard: about the lack of notification to you, it is my bad... worst part is that I did write the response to your email that you pointed out that the issues url should be taken care by gitlab... but I ended up never sending it :( Sorry!
<rodrigovivi>
mripard: then on the repo thing I thought we were still uploading the branches and would send the rerere patch after we had everything in place... and synced with you and daniels but now I confess I'm also lost on where we are with the repo...
sima is now known as Guest2077
sima has joined #freedesktop
Haaninjo has quit [Quit: Ex-Chat]
sima has quit [Ping timeout: 480 seconds]
navarre has quit []
Guest2077 has quit [Ping timeout: 480 seconds]
vkareh has quit [Quit: WeeChat 4.2.2]
jvaclav6 has joined #freedesktop
jvaclav has quit [Ping timeout: 480 seconds]
jvaclav6 is now known as jvaclav
zxrom has quit []
AbleBacon has quit [Read error: Connection reset by peer]
m5zs7k has quit [Read error: Connection reset by peer]
m5zs7k has joined #freedesktop
mripard has quit [Remote host closed the connection]