00:12 daniels: eric_engestrom: please give me the morning to sort out the YAML updates :\
07:24 eric_engestrom: daniels: sure :)
08:15 eric_engestrom: daniels: you have reassign !29649 to marge but you haven't pushed anything; did you forget to `git push`? (or did you run it but gitlab had an error and didn't receive it?)
10:03 daniels: oops, thanks!
10:09 eric_engestrom: daniels: I think you accidentally just undid jenatali's changes :(
10:10 daniels: f
10:12 daniels: eric_engestrom: do you have the commit in your repo from when jenatali pushed?
10:13 eric_engestrom: yeah
10:13 eric_engestrom: `git fetch fdo ea81bff8aa26217c8d4643f1448287ce5464f482` will get you all the commits in your cache
10:14 eric_engestrom: then you can do an interactive rebase and replace db2ce8bfbb1e8ea573a7 with a50ec799c2d13d7a0fa4
10:14 daniels: oh huh, I didn't think we could fetch dangling refs
10:14 eric_engestrom: as far as I can tell that's all that's needed
10:14 eric_engestrom: yeah it's pretty neat :)
10:14 daniels: well, you can't fetch arbitrary dangling refs, they do have to be reachable from somewhere useful
10:15 daniels: anyway, I'd manually recreated jenatali's zlib commit, and diff shows nothing meaningfully different apart from my nil build fix, so fingers crossed this one is it ...
10:15 eric_engestrom: yes and no: in practice gitlab never runs gc because there could always be a link somewhere on the internet that points to a commit
10:16 eric_engestrom: typo in the author name :P
10:16 eric_engestrom: -Author: Jesse Natalie <jenatali@microsoft.com>
10:16 eric_engestrom: +Author: Jesse Natali <jenatali@microsoft.com>
10:16 daniels: oh ffs
10:17 eric_engestrom: hehe
10:17 daniels: and right, it never runs gc, but gitaly does have a check to make sure that any commit you explicitly try to fetch is reachable from a visible ref
10:17 eric_engestrom: everything else is good though
10:17 daniels: anyway, marge is actually working on it now, so I'm not keen to interrupt her
10:17 daniels: sorry jenatali(e)
10:17 eric_engestrom: ack
10:17 eric_engestrom: and ack for gitaly, I didn't know
10:18 eric_engestrom: but that's a bit surprising though, I'm sure I've fetched stuff that was long dead
10:18 eric_engestrom: I guess it's all down to what counts as "visible ref"
10:19 eric_engestrom: it was definitely not in a git branch/tag anymore, but maybe a link in the webui "activity" history counts
10:19 daniels: yeah, it does count previous revisions of MRs as visible given that it keeps hidden refs to those
10:19 eric_engestrom: ack
10:19 daniels: but you can't e.g. fetch commits from other peoples' forks just because they happen to share storage
10:23 eric_engestrom: right, but you can `git fetch https://gitlab.freedesktop.org/$THEIR_USERNAME/mesa $sha` for anyone
10:24 ukleinek: That must be some gitlab extension then, doesn't work with plain git.
10:28 daniels: it does, if the server lets you fetch it
10:31 ukleinek: might be, then still s/plain git/plain git on the server side/
10:34 eric_engestrom: oh wait daniels, you didn't address the missing dep in mesa/main: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/61237178
10:35 eric_engestrom: yep, latest pipeline has also hit it: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/61257239
10:40 daniels: yeah, I'm on it
10:42 zmike: eric_engestrom: looks like pepp spotted our mystery spam source
10:42 daniels: strangely the libmesa target does already have idep_mesautil in its deps ...
10:42 eric_engestrom: zmike: yep!
10:43 zmike: hero
10:43 rgallaispou: Hi,
10:43 rgallaispou: I have merged three patches regarding stm drivers, and pushing onto drm-misc-next showed conflicts with v3d drivers. I have resolved and rebuilt drm-tip as the dim doc said fyi
10:44 rgallaispou: mripard: could you double check the changes ?
11:00 eric_engestrom: haha daniels, casting a wide idep_mesautil net I see ^^
11:00 eric_engestrom: there's probably some overkill in there but I think that's good and we can remove unnecessary ones later
11:01 daniels: heh yeah, some of them were definitely required - at this point pretty much everything pulls it in one way or another, so might as well be explicit about it
11:02 eric_engestrom: (just saw your comment)
11:02 eric_engestrom: and yeah I agree with you
11:02 eric_engestrom: I think meson could use a dependency tree viewer
11:03 eric_engestrom: not just in the `dependencies` sense, but anything that links one object to another, with the transitive stuff listed but marked as such
11:03 eric_engestrom: dcbaker: is there something like this?
11:05 eric_engestrom: daniels: I think in 3h I'll make the branchpoint, and if your MR didn't make it I'll backport it for -rc2
11:05 eric_engestrom: does that sound ok?
11:06 eric_engestrom:is ill and doesn't want to work late on friday evening
11:21 daniels: eric_engestrom: yep, that's totally fine, thanks so much for your help & understanding so far
11:22 daniels: I'm doing some marge improvements as penance
11:29 daniels: eric_engestrom: ci18-rpi4 seems unhealthy https://gitlab.freedesktop.org/mesa/mesa/-/jobs/61261137
11:44 eric_engestrom: re- rpi, it looks random to me which ones fail to boot, so I think it's either a problem with the master or the pdu, but it happens on both of these two as well; we can't seem to figure out anything, and the baremetal farm is set to be retired hopefully Soon™ so we decided focus on migrating away from it instead of debugging it
11:46 daniels: rpi is going ci-tron?
11:56 daniels: eric_engestrom: penance https://gitlab.com/marge-org/marge-bot/-/merge_requests/445
12:42 eric_engestrom: daniels: nice, thanks! r-b for the first two commits, and I'll read the last one when I have time to dive into it but it looks reasonable
12:44 eric_engestrom: and yes, we have a ci-tron farm with a rpi dut and we're ironing out the kinks (it works now but it's not pretty), and hopefully we'll migrate all the duts there soon
13:38 sima: mripard, for the drm-misc commit rights imo just ping drm-misc maintainers, this isn't something where airlied or me need to get involved I think
14:16 eric_engestrom: daniels: all the build jobs are green, I think this time's the one! 💪
14:16 eric_engestrom: I'll post the branchpoint MR in a few minutes
14:17 daniels: eric_engestrom: thanks, I owe you and jenatali both
14:17 daniels: I have nfi how alpine-build-testing hit every failure so aggressively when the others (and local) were mostly fine ...
14:28 eric_engestrom: race conditions are always fun :]
14:29 eric_engestrom: but yeah, no idea why they show up in that build so much more often
14:30 daniels: \o/
16:08 jenatali: IMO meson/ninja needs a deterministic mode for CIs, where targets are built in an order where generated files that can be consumed implicitly (like headers) are sorted last, and only built when no targets can make progress without them
16:12 Company: jenatali: ninja -j 1 should give you "deterministic" at least
16:13 Company: and keeping the list of remaining targets sorted by extension or something doesn't sound too hard
16:14 Company: I remember arguing the opposite - sorting the list so that the linking process of large libraries starts asap, and compiling testcases and whatnot happens after that
16:15 Company: well, not "opposite" - "different" is a better term
16:18 eric_engestrom: the problem with making the ci build deterministic like this is that it will hide all for us devs the build problems that the users/packagers will hit if they don't also do that
16:20 Company: I was thinking jenatali wanted a debug tool to helps find missing deps after refactorings
16:20 jenatali: Yeah, that
16:20 jenatali: So CI can't pass if you're trying to merge a change that happens to work without explicit annotated dependencies for things that you're implicitly consuming
16:22 Company: I wonder if what you really want is for meson to move away all files you don't explicitly depend on
16:22 Company: before running the command
16:23 Company: then order wouldn't matter
16:23 jenatali: That breaks parallelism though
16:23 Company: but you'd need a custom directory structure for each command
16:23 Company: technically you could give each command its own directory tree
16:24 Company: not sure how slow it gets when you start virualizing the file system for each command though
16:25 eric_engestrom: I see, yeah that sounds like a good debugging tool
16:25 jenatali: Probably very slow :)
16:26 Company: it sounds very powerful though
16:26 Company: because it should reliably find *every* missing dep
16:26 jenatali: I've contemplated adding a similar mode to our software D3D driver, so it explicitly executes commands in reverse submission order whenever allowed by spec, to help catch similar missing dependency bugs
16:29 Company: the validation layers recently told me I can't wait on that semaphore, because nobody is gonna signal it
16:30 Company: it was right (I had forgotten to add it elsewhere), but I wondered how it knew
19:06 pixelcluster: Company: that case is pretty simple - you can wrap VkSemaphore objects with some metadata in the validation layers that tracks if some submission signaled this semaphore (and you reset it when something waits on the semaphore)
19:07 pixelcluster: if something waits on the semaphore and there was no previous submission signaling this semaphore, you throw an error
19:07 Company: pixelcluster: but the semaphore could be submitted later/in a different thread to a different queue, no?
19:07 pixelcluster: since wait-before-signal is forbidden for semaphores this works always
19:08 Company: or are semaphores queue-local?
19:08 Company: maybe there's a flag you need to set to make them cross-queue
19:09 jenatali: What's the point of a queue-local semaphore?
19:09 Company: pipeline stages
19:09 pixelcluster: semaphores are not queue-local
19:09 pixelcluster: but again, wait-before-signal is forbidden
19:10 pixelcluster: https://registry.khronos.org/vulkan/specs/1.3-extensions/html/chap6.html#VUID-vkQueueSubmit-pWaitSemaphores-03238
19:11 Company: I did not know that
19:11 Company: good thing I don't do multithreading yet
19:11 jenatali: Right, forgot that queue submission isn't a sequence point in Vk like it is in D3D
19:12 pixelcluster: if wait-before-signal is allowed there is no way to validate correct signaling I'm pretty sure
19:12 jenatali: Correct
19:13 Company: yeah, that's why I was surprised
19:13 Company: oh, it's only for binary semaphores
19:13 jenatali: Yeah, timeline semaphores can do wait-before-signal, right?
19:14 Company: considering you can import them and then wait on them, that seems like a requirement
19:15 Company: or can you import binary semaphores, too?
19:16 Company: you can
19:16 Company: I suppose they count as signaled if you import them
19:17 Company: *as queued for signaling
19:18 Company: I clearly need to learn more about that topic
19:28 dcbaker: jenatali: there’s some improvements to ninja that should make that better. One of the meson devs who’s also a gentoo dev has a script they’re using in portage to look for missing dependencies via dep file, which can at least find missing header dependencies
19:28 jenatali: Oh awesome
19:31 dcbaker: There’s been some work to try to make ninja build ordering more deterministic as well, and I think samu has a more deterministic build order
19:37 jenatali: Very cool