01:16 abhinav__: mlankhorst hi, for msm, we need some changes which went into drm-misc for a feature which we planned to land in 6.9 ... would it be possible to generate another tag so that we can pull in that into our tree and base our changes on that ...
01:18 abhinav__: these changes were merged after the last tag on 02-22
01:26 Hilligans: Hello
01:26 Hilligans: Ive come accross a very specific issue that I need help diagnosing
01:26 Hilligans: I'm working on my own engine currently thats using opengl as the backend that works fine on its own, but when I try to launch it via renderdoc I get a segfault in the driver.
01:27 Hilligans: I then compiled mesa on my system with debug symbols enabled and ran renderdoc via gdb to find the exact line causing the segfault, which is
01:27 Hilligans: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/auxiliary/util/u_threaded_context.c?ref_type=heads#L2163
01:27 Hilligans: I don't really know where to go from here and I dont really know where the issue lies or what piece of code is at fault for it so any tips or things I should do would be great.
01:31 kisak: failing everything else, you could ask the renderdoc dev(s) if it makes sense to thm or if they've seen similar
01:36 Hilligans: thats true ill do that
01:37 airlied: probably useful to get a proper backtrace
01:40 Hilligans: i do have a backtrace actually
01:43 Hilligans: #0 tc_set_vertex_buffers (buffers=0x7fff5e9ffa20, take_ownership=<optimized out>,
01:43 Hilligans: unbind_num_trailing_slots=0, count=3, _pipe=0x7fff0c76b2c0)
01:43 Hilligans: at ../mesa-24.0.1/src/gallium/auxiliary/util/u_threaded_context.c:2205
01:43 Hilligans: #1 tc_set_vertex_buffers (_pipe=0x7fff0c76b2c0, count=3, unbind_num_trailing_slots=0,
01:43 Hilligans: take_ownership=<optimized out>, buffers=0x7fff5e9ffa20)
01:43 Hilligans: at ../mesa-24.0.1/src/gallium/auxiliary/util/u_threaded_context.c:2179
01:43 Hilligans: #2 0x00007fffc09bac5b in cso_set_vertex_buffers_and_elements (cso=0x7fff0c7e8200,
01:43 Hilligans: velems=0x7fff5e9ff890, vb_count=3, unbind_trailing_vb_count=<optimized out>, take_ownership=true,
01:43 Hilligans: uses_user_vertex_buffers=<optimized out>, vbuffers=0x7fff5e9ffa20)
01:43 Hilligans: at ../mesa-24.0.1/src/gallium/auxiliary/cso_cache/cso_context.c:1376
01:43 Hilligans: #3 0x00007fffc07e4693 in st_update_array_templ<(util_popcnt)1, (st_update_flag)0> (
01:43 Hilligans: nonzero_divisor_attribs=<optimized out>, enabled_user_attribs=<optimized out>,
01:43 Hilligans: enabled_attribs=<optimized out>, st=<optimized out>)
01:43 Hilligans: at ../mesa-24.0.1/src/mesa/state_tracker/st_atom_array.cpp:348
01:43 Hilligans: #4 st_update_array_impl<(util_popcnt)1> (st=<optimized out>)
01:43 Hilligans: at ../mesa-24.0.1/src/mesa/state_tracker/st_atom_array.cpp:392
01:43 Hilligans: #5 st_update_array_with_popcnt (st=<optimized out>)
01:43 Hilligans: at ../mesa-24.0.1/src/mesa/state_tracker/st_atom_array.cpp:408
01:43 Hilligans: #6 0x00007fffc05774be in st_validate_state (pipeline_state_mask=<optimized out>, st=0x7fff0c7e67a0)
01:43 Hilligans: at ../mesa-24.0.1/src/util/bitscan.h:117
01:43 Hilligans: #7 st_prepare_draw (ctx=<optimized out>, state_mask=<optimized out>)
01:43 Hilligans: at ../mesa-24.0.1/src/mesa/state_tracker/st_draw.c:90
01:43 Hilligans: #8 0x00007fffc070cd90 in _mesa_draw_arrays (ctx=0x7fff0c79f700, mode=<optimized out>,
01:43 Hilligans: start=<optimized out>, count=<optimized out>, numInstances=<optimized out>,
01:43 Hilligans: baseInstance=<optimized out>) at ../mesa-24.0.1/src/mesa/main/draw.c:1202
01:43 Hilligans: #9 0x00007fffc0786861 in _mesa_unmarshal_DrawArrays(gl_context *, const marshal_cmd_DrawArrays * __restrict__) (ctx=<optimized out>, cmd=<optimized out>)
01:43 Hilligans: at ../mesa-24.0.1/src/mesa/main/glthread_draw.c:293
01:43 Hilligans: #10 0x00007fffc0522a72 in glthread_unmarshal_batch (job=job@entry=0x7fff0c7ab900,
01:43 Hilligans: gdata=gdata@entry=0x0, thread_index=thread_index@entry=0)
01:43 Hilligans: at ../mesa-24.0.1/src/mesa/main/glthread.c:139
01:43 Hilligans: #11 0x00007fffc050c61d in util_queue_thread_func (input=input@entry=0x7fff0c7ee180)
01:43 Hilligans: at ../mesa-24.0.1/src/util/u_queue.c:309
01:43 Hilligans: #12 0x00007fffc05208bc in impl_thrd_routine (p=<optimized out>)
01:43 Hilligans: at ../mesa-24.0.1/src/c11/impl/threads_posix.c:67
01:43 Hilligans: #13 0x00007ffff34a955a in start_thread (arg=<optimized out>) at pthread_create.c:447
01:43 Hilligans: #14 0x00007ffff3526a3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
01:45 airlied: maybe open a mesa gitlab issue
01:46 Hilligans: aight
07:41 marex: I was just pushing $ dim push-branch drm-misc-next and got this
07:41 marex: dim: No git remote for any of the URLs https://gitlab.freedesktop.org/drm/xe/kernel.git ssh://git@gitlab.freedesktop.org/drm/xe/kernel.git found in /git/drm-tip
07:41 marex: did I miss anything or screw anything up ?
07:41 marex: daniels: ^
08:29 tzimmermann: airlied, sima, i'd like to prepare drm-misc-next-fixes. could you please forward drm-next to -rc6
08:30 sima: tzimmermann, you mean like backmerge of -rc6 into -next?
08:30 tzimmermann: sima, yes
08:31 sima: tzimmermann, any specific commit or just general "pls keep the trees not too badly out of sync"?
08:32 tzimmermann: yeah, like that. it's still at -rc3 and before the final fixing begins, it makes sense to sync
08:32 sima: aye
08:32 tzimmermann: thanks a lot
08:32 sima: any specific pr I should do first?
08:32 sima:just recovered from vacations
08:32 sima: haven't caught up on mail yet
08:33 tzimmermann: sima, last week's drm-misc-next appears to be missing
08:33 tzimmermann: if you could merge that first
08:34 sima: hm strange airlied pulled the one from airlied, but not the others
08:34 sima: airlied, ^^ mail delivery lols?
08:34 sima: I had to switch to lore+lei here for ffwll.ch, gmail wouldn't take stuff anymore reliably
08:34 tzimmermann: sima, airlied, here's the PR mail https://lore.kernel.org/dri-devel/20240222135841.GA6677@localhost.localdomain/
08:35 sima: tzimmermann, yeah got it, there's also one from oded and a xe one from demarchi
08:35 tzimmermann: urgh, that's quite a number of patches
08:35 sima: ?
08:36 tzimmermann: i mean, would they miss the next merge window, or can we make an exception here?
08:37 sima: tzimmermann, we don't treat -rc6 as a hard cutoff
08:37 sima: or do you mean stuff that's now in -misc-next on top of that pr?
08:37 sima: it's just around -rc6 it should be all sorted and at least the pr out so there's enough time to merge and shake things out before the merge window opens
08:37 sima: since by then it should be all ready
08:38 sima: this also because iirc some subtrees aren't in linux-next
08:38 tzimmermann: i see. i thought that we have reached -rc6 and only fixes should go into drm-next.
08:38 sima: although we've tried to get that fixed
08:38 sima: tzimmermann, always some judgement calls
08:39 sima: imo the important one is that drm-misc-next is always open for patches, so that people don't feel like they have to rush in patches due to a 1 month long no-merge window
08:39 sima: which most other subsystems have, and that part imo sucks for contributors
08:39 tzimmermann: makes sense; got it
08:40 sima: anyway I'll go pr processing, I'll ping you when it's done including -rc6 backmerge
08:40 javierm: sima: also, some ocasional may not be tracking the release process that closely and even know whether wer are in the -rc cycle or the merge window
08:40 javierm: *ocarionsal contributors
08:40 tzimmermann: sima, BTW i've been doing quite a bit of fbdev work recently. i was wondering, should we merge the fbdev tree into drm-tip as well?
08:40 sima: javierm, yeah
08:41 sima: tzimmermann, so core fbdev is all officially in drm-misc, I've done the MAINTAINERS patch for that
08:41 sima:checks
08:41 tzimmermann: yes
08:41 javierm: sima: yeah, but is a good point tzimmermann to prevent conflicts or at least detect it earlier
08:42 sima: lol fb_defio.c is officially maintained by some random arc fbdev driver person :-)
08:42 sima: prooooobably outdated
08:42 sima: tzimmermann, for anything else I'd say drm-misc is also ok, especially if it's any kind of refactoring
08:42 sima: or one of the fw drivers we care about still
08:42 tzimmermann: quite a lot of driver patches go through helge's fbdev tree. i've been working on kernel graphics basics (such as sysfb) and htat naturally affects drm and fbdev. sometimes non-drm patchsets go into fbdev.git, even though they might affect drm as well
08:43 sima: if you want to be polite, maybe ask helge for an ack
08:43 sima: tzimmermann, yeah imo big refactorings just smash them all through drm-misc
08:43 sima: it's what the thing is there for
08:43 sima: I've pushed vt stuff through there too (but with gregkh's ack) in the past
08:43 tzimmermann: well, ok. i sometimes had to juggle some patches around until trees git sync'ed again.
08:44 sima: tzimmermann, tbf I give helge another 1-2 years before he gives up, that's usually how long fbdev volunteers stick around
08:44 tzimmermann: :D
08:44 sima: tzimmermann, yeah for anything cross-tree just ask for ack and land in drm-misc
08:45 sima: I made it pretty clear to helge that I don't see the point of a separate tree and invited him to drm-misc, and agreement is that he won't interfere
08:45 sima: so if the separate tree intereferes, just land it all through drm-misc
08:45 tzimmermann: helge mostly collects patches, it's mostly not much of a problem
08:45 tzimmermann: maybe i make a patch for the drm-tip repo and post it to the lists
08:51 sima: airlied, just noticed that tzimmermann -next pull is after the amdgpu one, just lore websearch lists them the other way round somehow
08:58 marex: sima: about that ^ xe error message , I hope I didn't break drm-misc-next ?
08:58 sima: marex, which xe error message?
08:58 marex: I was just pushing $ dim push-branch drm-misc-next and got this
08:58 marex: dim: No git remote for any of the URLs https://gitlab.freedesktop.org/drm/xe/kernel.git ssh://git@gitlab.freedesktop.org/drm/xe/kernel.git found in /git/drm-tip
08:58 marex: did I miss anything or screw anything up ?
08:59 marex: sima: ^ this
08:59 sima: hm I thought dim would ask you to auto-add in that case ...
08:59 sima: did it not?
08:59 marex: Enter a name to auto-add this remote, leave blank to abort: drm-xe
08:59 marex: ah ... I missed that one
09:00 marex: so, all is fine ?
09:00 sima: yeah so if you hit enter and it continued, it should be all fine
09:00 sima: otherwise you'll hit this again, and drm-tip won't be updated
09:00 marex: well, whew, that is good news, thanks
09:00 sima: marex, if you want to check, make sure your drm-tip was pushed
09:01 marex: it was
09:01 sima: then you're all good
09:01 marex: sima: I was concerned it might have been pushed somehow incorrectly, but it seems OK
09:01 marex: sima: thanks
09:19 airlied: sima: I only get PRs from patchwork mostly now, though I didn't get to process -next today like I should have
11:13 sima: airlied, tzimmermann backmerge pushed
11:14 sima: demarchi, hwentlan_ drm-tip rerere sorted out some trivial stuff in xe and amdgpu, maybe check
11:35 jmondi: I very seldom send patches for drm/kms, and when I have to do so I constantly fail to remember which tree/branch I am supposed to develop patches against
11:35 jmondi: this doesn't seem to be documented in https://docs.kernel.org/gpu/introduction.html
11:35 jmondi: am I looking in the wrong place ?
11:41 CounterPillow: Judging by "base-commit:" in some of the submitted patchsets to the dri-devel mailing list, you'll want drm-tip https://cgit.freedesktop.org/drm-tip/
11:42 CounterPillow: Though if you're submitting patchset for a specific large-ish driver like those of intel or amd, they might have their own driver specific -next repositories, but if they want you to rebase on those they'll tell you when you submit
11:43 jmondi: it's just about adding a new image format to the uAPI
11:43 mripard: jmondi: yeah, generally speaking we follow pretty much the same pattern: latest release unless being told otherwise?
11:44 jmondi: mripard: of drm-misc ? or just drm ?
11:44 mripard: of linux? drm-misc or drm doesn't do releases
11:44 jmondi: linux yes
11:45 jmondi: or linux-next ?
11:45 jmondi: is this documented somewhere and I have missed it ?
11:46 javierm: jmondi: yeah, I usually use linux-next for my kernel work when I don't know what is the correct tree / branch to target
11:47 CounterPillow: "Note, however, that you may not want to develop against the mainline tree directly. Most subsystem maintainers run their own trees and want to see patches prepared against those trees. See the T: entry for the subsystem in the MAINTAINERS file to find that tree, or simply ask the maintainer if the tree is not listed there."
11:47 CounterPillow: https://www.kernel.org/doc/html/latest/process/submitting-patches.html
11:48 tzimmermann: thanks sima
11:48 jmondi: CounterPillow: T: git git://anongit.freedesktop.org/drm/drm
11:49 CounterPillow: run ./scripts/get_maintainer.pl --scm fileyou'remodifyinghere
11:49 jmondi: for DRM DRIVERS in MAINTAINERS
11:49 mripard: jmondi: really, just use the latest linux release and start from there. Just like you would for v4l2 :)
11:49 CounterPillow: ./scripts/get_maintainer.pl --scm include/drm/drm_fourcc.h shows git git://anongit.freedesktop.org/drm/drm-misc as the first tree
11:49 javierm: jmondi: answering your question, for drm in particular I use drm-misc-next if is a new feature for the next release or drm-misc-fixes if is a fix for the currenty -rc cycle
11:49 javierm: jmondi: although I heard that some folks use https://gitlab.com/freedesktop-mirror/drm-tip
11:50 CounterPillow: as you can tell by the multitude of answers, it really doesn't matter as long as it is recent
11:51 CounterPillow: if you get it wrong according to the maintainer, a rebase is easy, and you get to tell the maintainer to update the T: in MAINTAINERS then
11:52 jmondi: mripard: for v4l2 I use the staging tree :) I thought it was documented in the maintainer-entry-profile file, but it's not
11:53 jmondi: will use -next, thank you all fro your answers
11:53 javierm: jmondi: for v4l2 I use -next btw :)
11:55 mripard: sima: we had a discussion with emersion last week and I couldn't remember (or find it in the doc), are drm-misc committers supposed to cherry-pick, or only maintainers should?
11:55 jmondi: javierm: I guess 'whatever works' is the right way of doing it ;)
11:56 emersion: sima: hope you got back from your trip with less trouble than last time :P
11:56 javierm: jmondi: yeah :)
11:56 emersion: re cherry-pick: the question is about what committers are supposed to do when they messed up
11:56 emersion: and pushed to the -next tree instead of the -fixes tree
11:58 sima: emersion, mripard the dim cherry-pick helper is in the section for maintainers https://drm.pages.freedesktop.org/maintainer-tools/dim.html#cherry-pick-commit-ish
11:58 sima: I think we also had some doc patch to clarify that in other parts
11:59 sima: hm I guess that never happened
12:00 sima: I thought we've added cherry-picks to the list of non-linear stuff that maintainers should do in the list here https://drm.pages.freedesktop.org/maintainer-tools/committer-drm-misc.html#merge-criteria
12:00 sima:shrugs
12:00 sima: maybe should get that fixed
12:00 javierm: sima: yeah, something like this after the COMMANDS FOR MAINTAINERS "NOTE:
12:00 sima: reason is that cherry-picks tend to cause conflicts, so usually need to make maintainers aware anyway
12:01 javierm: ups, press enter too son. "NOTE: the following commands are for drm-misc maintainers and should not be used by people with drm-misc commit rights"
12:01 emersion: i see
12:01 sima: javierm, well those are for maintainers in general, I'd just add something to the drm-misc committer docs specifically
12:01 emersion: so i should've asked for a maintainer to do the cherry-pick, is the answer
12:01 sima: general = drm-intel and xe and all those trees
12:02 emersion: indeed the cherry-picked caused a conflict which i had to resolve
12:02 emersion: pick*
12:02 mripard: sima: yeah, that was my recollection too but it wasn't in the doc so I got confused
12:02 sima: yeah, they do that :-)
12:02 mripard: I'll send a doc patch
12:02 emersion: ty!
12:02 sima: mripard, yeah I think the last time around we discussed this it got way too heated in private and everyone just wanted to settle it all for good :-/
12:03 javierm: mripard: that would be great. Thanks!
12:03 javierm: sima: now that you mention, is the first time I notice that the dim commands had sections for contributors and maintainers
12:15 sima: javierm, writing actually good docs that get the point across is hard ...
12:22 javierm: sima: agreed. Sorry if it sounded as if I was complaining, I just meant that is nice that mripard will clarify even more, to prevent us contributors to make mistakes
12:23 javierm: because in the past I did cherry-pick and pushed, thinking that it was something that contributors were supposed to handle
12:26 sima: javierm, yeah it's not one of the things which reliably results in pain, but it can, so we didn't yet get around to clarifying this properly
12:26 sima: but it also has lead to some serious pain in the past
12:26 sima: it's one of these "it's complicated" topics
12:26 javierm: sima: yeah
12:54 mripard: sima: also, ack for https://lore.kernel.org/all/20240221092636.691701-1-mripard@kernel.org/ ?
13:01 sima: mripard, a-b:me
13:01 sima: mripard, also the licensing issues for built-in fw is when you don't allow redistribution
13:01 sima: since we allow these as built-in already (but in other form) that shouldn't be an issue
13:02 sima: so it's not a general restriction for fw, it's just that most fw has proprietary licensing making it impossible to include in the gpl'ed kernel binary in any form
13:03 sima: which is why fw-in-C-file-constants got removed from the kernel, it doesn't matter in which form you include these binaries if licensing is incompatible
13:03 sima: s/redistribution/have open source source that's gpl compatible/
13:04 mripard: oh, right
13:45 mripard: sima: https://gitlab.freedesktop.org/drm/maintainer-tools/-/merge_requests/34
14:11 sima: mripard, lgtm but maybe get acks from tzimmermann or mlankhorst?
14:12 tzimmermann: mripard, ack
14:15 sima: mripard, -fixes stuck on -rc1 I just noticed ...
14:19 demarchi: sima: is git:// preferred for the pull request or could we just switch globally to https:// ?
14:20 sima: I thought https was less efficient than git ...
14:20 sima: or is that outdated info?
14:21 demarchi: sima: asking because we don't have a git:// one for xe. I ended up using ssh:// with a local change to get the pull request done, but after checking the email I see it was not really ideal
14:21 demarchi: sima: shouldn't matter these days and git:// is disabled now in several forges
14:21 mripard: sima: I'll update drm-misc-fixes
14:21 demarchi: I know github disabled it completely, need to check if gitlab disabled it too
14:21 mripard: sima: and also, I can't merge a branch in maintainer-tools :)
14:21 sima: mripard, pls ping me when you're done since I'm in the process of applying a patch
14:21 sima: mripard, uh
14:22 sima: demarchi, can you press the button for mripard? my ubikey is somewhere but not where it should be rn ...
14:22 sima: demarchi, ack for https by default then
14:22 demarchi: sima: yep
14:23 sima: thx
14:23 demarchi: this one? https://gitlab.freedesktop.org/drm/maintainer-tools/-/merge_requests/34
14:24 sima: yup
14:24 DemiMarie: demarchi: git:// is deprecated and hilariously insecure
14:24 demarchi: we are having a problem running pipelines from forked repos, so I can't merge neither
14:24 mripard: demarchi, sima: thanks!
14:24 demarchi: mripard: can you just push? the pipeline will just timeout and not run
14:25 mripard: I'm not sure I have the rights to, but I'll try
14:25 demarchi: mripard: I can push it if you don´t
14:26 sima: demarchi, I guess we need to move drm-misc and get everyone there added to the fdo-ci group so ci works?
14:26 demarchi: nonetheless we should fix the pipeline integration. Not sure if related, but we shouldn't really be using a container with fedora 28 for that
14:26 sima: oh lol
14:27 sima: it's been a while I've done the the dim ci :-)
14:27 sima: demarchi, xe committers should also get added to the fdo ci group, if they aren't yet
14:27 demarchi: sima: what do you mean by moving drm-misc?
14:28 sima: from legacy git to gitlab.fd.o
14:28 mripard: demarchi: yeah, I'm not allowed to push
14:28 demarchi: mripard: I will push that one for you
14:28 mripard: sima: I guess you didn't really watch your mails recently ? :)
14:28 mripard: sima: https://lore.kernel.org/dri-devel/gnthy5o42kiyj63d2bkkxsc5krzf3wrwt23chh2kthkmlyjwbg@ybynvjvqdka7/
14:29 sima: mripard, no :-)
14:29 demarchi: sima: in theory it uses fedora:latest, in practice it tries to pull fedora 28
14:29 sima: but thanks a lot for moving this forward, much, much, much appreciated
14:29 mripard: daniels helped a ton too
14:30 demarchi: mripard: sima one thing that I noticed... we'd still need to move drm-tip too, otherwise people would still need to create the ssh account
14:30 daniels: (perhaps a milli-ton at most)
14:30 sima: demarchi, yeah
14:31 sima: demarchi, I never checked, but does dim go through the repo lookup for drm-tip too?
14:31 sima: or would that be more bumpy?
14:32 sima: mripard, daniels so is drm.git also moving?
14:33 sima: I mean only like 2 people push there ...
14:33 mripard: demarchi: oooh, right...
14:33 mripard: sima: it wasn't planned, but I guess it would be easy to
14:33 demarchi: sima: it does. I think we'd mostly need to create the new remote and change nightly.conf
14:33 sima: demarchi, yeah I think then we can do that as soon as drm-misc shuffled over and things are settled
14:34 sima: since airlied&me have full rights to everything under drm/ anyway
14:36 daniels: sima: yeah
14:36 daniels: we can keep the old mirror ofc
14:36 demarchi: sima: now that drm-xe-next pull is merged, should I ff drm-xe-next-fixes to drm-next and start collecting the patches there?
14:37 sima: demarchi, yeah if you can ff that's preferred
14:37 sima: and for drm-next every merge commit should be good really
14:37 sima: otherwise picking a tag from linus is better
14:38 sima: demarchi, mripard I clicked the button for the dim mr, seems to have worked
14:38 demarchi: oh... that one didn't timeout
14:39 demarchi: not sure what's the difference between that one and e.g. https://gitlab.freedesktop.org/drm/maintainer-tools/-/merge_requests/31
14:41 sima: not sure, maybe should rebuild the images and move them over to fdo gitlab ci scripts
14:41 sima: mripard, for moving drm.git I guess just do it and then tell airlied&me
14:41 sima: as long as the mirror is there it shouldn't impact any in-flight pr to linus
14:42 daniels: yeah, that's because igt still isn't using the fd.o ci-templates, so it relies on either a) people running the container build themselves manually and pushing, or b) the person who submitted the MR to have rights to merge things to igt (since that causes the job to run in the project namespace rather than the user namespace)
14:42 daniels: sima: right, should be pretty straightforward
14:42 sima: daniels, this is dim, but yeah same
14:42 daniels: sima: tmtla
14:45 sima: daniels, is https://gitlab.freedesktop.org/drm/kernel autosyncing from somewhere or why is that fairly up-to-date with the legacy drm/drm.git?
14:45 sima: daniels, also is that the one that people should fork?
14:46 sima: mripard, ^^
14:52 daniels: sima: that's currently autosyncing from nowhere and up-to-date with nothing :)
14:52 daniels: but will eventually become the place you push and be mirrored out to anongit/drm/drm
14:52 sima: daniels, I'm just wondering why it's so up-to-date with last week :-)
14:53 sima: daniels, I guess if you have some time to disable write-access to the cgit drm.git somewhen I can then just shuffle it over
14:53 daniels: sima: oh yeah, because that's when we started creating all the stuff :P
14:53 sima: it's just a few pushes really
14:53 daniels: sima: sure, can do that tomorrow
14:54 sima: I ditched a few branches from the cgit one, I'll drop them from the gitlab one too
14:55 sima: also just updated the description to hopefully steer people away from it aside from using it as a fork source
14:55 sima: daniels, btw on the gitlab fork tree, did you reparent all the random forks we have to drm/kernel already?
14:55 sima: since I guess that's the plan, or different again?
14:56 sima: or maybe more a question for bentiss on #freedesktop
14:57 daniels: sima: yeah, so the only thing I'd done with drm/kernel was to create it and start reparenting the forks; I got as far as breaking quite a few kernel forks before ETIME, and trying to get back to that hopefully tonight
14:57 mripard: sima: drm-misc-fixes is up-to-date
14:58 sima: daniels, aye
14:58 sima: daniels, airlied I've disabled issues and made merge requests members only, to avoid confusing people too badly
14:59 sima: mripard, yeah just noticed, thx
15:00 mripard: sima: so, if we were to migrate drm.git, when would be the best time?
15:01 mripard: I'd assume that during the merge window like for drm-misc is probably not great?
15:01 sima: mripard, tomorrow, if daniels has time :-)
15:02 sima: mripard, it's just two people plus telling linus that "btw it moved, don't freak out"
15:02 sima: we sign the tags anyway
15:02 sima: only thing that matters is that legacy git gets disabled so sfr and airlied don't miss it
15:03 mripard: sima: uh, ok
15:03 mripard: that works for me
15:03 mripard: daniels: ^ ?
15:04 daniels: yeah no prob
15:04 daniels: legacy git disabled or mirroring?
15:05 sima: daniels, disabling writing is imo the important one, mirror is nice but not sure whether needed really
15:05 sima: mripard, oh I guess a really big MAINTAINERS patch is then also needed?
15:06 mripard: sima: our initial plan was to setup the cgit repo as a mirror, so it was needed but not urgent
15:06 mripard: but yeah, that's on the TODO list too
15:07 sima: mripard, yeah, simplest probably is if you base it on top of drm-next for all repo moves and then I just merge it directly
15:08 mripard: merge the MAINTAINERS patch you mean?
15:09 sima: yeah
15:09 mripard: ack
15:10 sima: demarchi, btw I guess you can delete drm/xe from the legacy git server?
15:11 sima: also not sure why the fw repo there is still in use when we have the new one
15:15 demarchi: sima: I'd remove the drm/xe from legacy git server if I knew how....
15:15 demarchi: sima: as for firmware... unfortunately it's still being used. I'm poking people updating that repo to stop and migrate to the new one
15:16 sima: demarchi, I think this needs server admin powers ... daniels?
15:16 sima: demarchi, also for fw repo you can just delete, that _will_ move the people :-)
15:16 daniels: demarchi: I can nuke it now if it helps
15:17 demarchi: sima: that's probably more effective than my method, although there will be drama and people yelling
15:17 sima: blame me, I'll take it :-)
15:17 sima: also, updating a git remote is a one-liner
15:18 demarchi: sima: there's also a process change
15:18 sima: demarchi, so if you ack, daniels can nuke drm-xe and drm-firmware from cgit
15:18 sima: demarchi, oh CI still looks at the old one?
15:18 demarchi: sima: yep
15:18 sima: ugh, then maybe mirroring is needed for drm-firmware :-/
15:19 demarchi: I´d just make it read-only
15:19 sima: demarchi, and force ci to update on the next fw push?
15:19 demarchi: then we don't lose the previous refs. But force people to migrate to the new one
15:19 sima: so delete drm-xe, make drm-firmware read-only?
15:20 demarchi: sima: yes.... we just merged the last firmwares we needed for the next release, so we probably have some time for people to adapt
15:20 demarchi: sima: ack
15:20 sima: mripard, ^^ maybe record that in your newly acquired 5yo issue :-)
15:20 sima: daniels, ^^
15:23 daniels: done
15:24 sima: thx a bunch!
15:26 mripard: daniels: for both the drm-xe deletion and the drm-firmware being set as read-only?
15:26 mripard: (it's also not clear to me what the different between cgit.fd.o/drm/drm-firmware and gitlab.fd.o/drm/firmware is)
15:28 danylo: scan_clusters.macro
15:28 daniels: mripard: yeah, both; I guess both repos are up-to-date now but there's no mirroring
15:33 mripard: sima: I guess you can ack the rerere, MAINTAINERS and https://gitlab.freedesktop.org/drm/maintainer-tools/-/merge_requests/35
15:33 mripard: and we should be all set
15:35 mripard: daniels, sima: so, do we want to keep the old repo around in r/o or do we want to set it up as a mirror?
15:36 sima: mripard, imo r/o should be good enough for drm.git
15:37 mripard: I'm asking because igt and libdrm are setup as mirrors
15:37 mripard: and we probably want to be consistent
15:37 sima: yeah, but there's a lot more people using that with contributors and all that
15:37 mripard: ok
15:37 sima: otoh mirroring probably better for smooth transition
15:37 sima: and then just delete it
15:38 sima: I think once linus, srf and rerere/nightly.conf are all updated, everyone who matters should have moved
15:38 sima: *sfr
15:58 warpme: guys: is current mesa (24.0.1) working out-of-box on rpi5 (v3d v7) with mainline 6.8-rc6?
16:00 abhinav__: tzimmermann mripard hi, for msm, we need some changes which went into drm-misc for a feature which we planned to land in 6.9 ... would it be possible to generate another tag so that we can pull in that into our tree and base our changes on that ... these changes were merged after the last tag on 02-22
17:30 bbrezillon: mripard, sima: How would you feel about merging panthor in drm-misc-next (the underlying question being, when is the drm-misc-next MR for 6.9 supposed to happen, and do you think it'd be preferable to wait for 6.9-rc1 to land before merging the driver)?
17:30 bbrezillon: dliviu: ^
17:31 bbrezillon: as a side note, this is a new driver for unsupported HW, so no risk of regression here
18:32 sima: bbrezillon, drm-misc-next is always open
18:32 sima: and yeah I think it'd fit into drm-misc, since usually after the initial drop activity tends to quiet down
18:33 sima: maybe get some acks from drm-misc maintainers
18:33 sima: wrt 6.9, the freeze already happened, so if you absolutely want to get it in, do a dedicated pull just for that, but with the MAINTAINERS entry pointing at the drm-misc git repo
18:34 sima: would still need to happen sooner than later, so that you can push bugfixes through drm-misc-next-fixes
18:34 sima: or drm-misc maintainers just ack that you drop the entire thing into drm-misc-next-fixes
18:35 sima: bbrezillon, for your actual question, the last drm-misc-next pr for 6.9 just happened last week, and I just merged it into drm-next today
18:35 sima: around -rc6 is the usual cutoff
18:49 bbrezillon: sima: I don't necessarily need it in 6.9
18:51 bbrezillon: just wanted to have it in linux-next for a few weeks, so that's perfect timing in the end
18:53 sima: bbrezillon, so drm-misc-next is not in linux-next during the feature freeze, so from roughly -rc6 to -rc1
18:53 sima: but you can still just land it
18:55 bbrezillon: that's fine, as long as it's in linux-next when -rc1 is out
18:56 bbrezillon: mripard_, mind giving me a ack on v5?
18:58 abhinav__: mripard_ hi, for msm, we need some changes which went into drm-misc for a feature which we planned to land in 6.9 ... would it be possible to generate another tag so that we can pull in that into our tree and base our changes on that ... these changes were merged after the last tag on 02-22 .... OR by any change will there be another PR from
18:58 abhinav__: drm-misc?
19:08 alyssa: bbrezillon: woohoo!
19:09 bbrezillon: hehe
19:09 bbrezillon: finally...
19:17 airlied: bbrezillon: are you aiming for 6.10?
19:19 bbrezillon: yes
19:24 airlied: ah cool
23:32 letsgofrom: karolherbst: you take steroids again i hear, we released a new product that you could consume after your dream in anal ways, cause you have not gone past the anal stage in your life, normally it happens after 3years old according to freud, but does not look you made it through, you are still a hero, some might consider you even a big gun, roll your german rrrrr's it's fair to say you are an idiot like 50 line java trace you used to read,
23:32 letsgofrom: puppet.
23:33 letsgofrom: next century you even might get to opencl 2.1
23:33 letsgofrom: at your current speed of solving things
23:35 kisak: wow, rude.