01:22tarceri: imirkin: can I add your r-b to https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5766/diffs?commit_id=b7b622aa04abc2e427444ce40d6d576d4acfa9df ?
01:29imirkin: tarceri: r-b me for the nouveau commit. haven't looked at the others.
01:30tarceri: all the others have review now
06:08danvet: pinchartl, cover letter plus first 3 patches
06:09danvet: not sure you want all that in your commit message ...
06:36danvet: pinchartl, oh and patch 16, somehow I misordered that to the end
07:20MrCooper: anholt__ tomeu: FWIW that looks rather like kernel+rootfs_arm* have "needs: arm_build", but the latter doesn't exist; probably the former need rules consistent with those of other jobs
07:58MrCooper: tarceri: what does https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5799 have to do with ARM builds? :)
08:54tarceri: MrCooper: I meant to say arm drivers
09:50ElBarto: anything I can do to help having https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1598 merged ?
10:11emersion: it would be nice to have freebsd ci, unfortunately freebsd upstream doesn't make this easy :S
10:14ElBarto: I need to learn more about gitlab-runner but it should be ~easy once I know how it really work
10:15ElBarto: this is on my todo list but not near the top of it :)
10:16emersion: the main issue is that freebsd doesn't provide an image that we can provision without human interaction from linux
10:16emersion: if we boot the upstream image with qemu, sshd won't be enabled, so we can't gfet in
10:16emersion: get in*
10:16ElBarto: yeah, I was more thinking of providing some "official" gitlab-runner maintained by us
10:17emersion: that would be very nice
10:17ElBarto: as long as everything is documented on how to re-install it from scratch that should be ok I guess
10:17emersion: (even nicer if it's not tied to gitlab so that other CI providers can benefit from it)
10:17ElBarto: for travis and cirrus-ci there is just scripts to wrote
10:17ElBarto: they already support FreeBSD
10:18emersion: ah, how do they provision freebsd images?
10:18ElBarto: cirrus-ci used the gcp images
10:18emersion: do you have a link?
10:19emersion: ah, interesting
10:19ElBarto: I've just learned two days ago about travis
10:19ElBarto: and haven't looked yet
10:19emersion: (for context, i'm maintaining the freebsd sr.ht images)
10:19ElBarto: they apparenly also talking about making some FreeBSD/arm64 support (travis)
10:20ElBarto: sr.ht ?
10:20ElBarto: ah ok
10:20ElBarto: also making a new qemu-compatible image with everything enabled for CI shouldn't be hard tbh
10:21ElBarto: what would you need ?
10:21emersion: … which is a little easier than gitlab, because we're generating freebsd images from our freebsd CI
10:21emersion: (not from linux)
10:21ElBarto: sshd with default password ? some kind of cloud-init mechnanism ?
10:21emersion: for sr.ht, we have a script which ~mnostly works https://git.sr.ht/~sircmpwn/builds.sr.ht/tree/master/images/freebsd/genimg
10:23emersion: we mainly have issues with files disappearing from the ftp
10:23ElBarto: a lot of thing could be simplified using mkimg(1)
10:23ElBarto: how so ??
10:25emersion: when a new version N is released, some files for version N-1 are removed from the ftp immediately, before files for version N are uploaded
10:25emersion: ah, i should look into mkimg
10:25ElBarto: for the stable/current release you mean ?
10:25ElBarto: I though we kept at least 3
10:25ElBarto: but I don't know how stuff is synced
10:25emersion: for STABLE yes
10:26ElBarto: I'm trying currently to join the team that handle that because there is a lot to do ...
10:26emersion: yes :)
10:26emersion: it's files in snapshots/ iirc
10:26emersion: maybe we should fallback to files in releases/…
10:27ElBarto: those should be always present
10:27emersion: so, when 11.4 was released a few weeks ago, the 11.3 dir was removed before 11.4 was added
10:27emersion: which broke our CI
10:28emersion: it's not that of a big deal because we just keep using old images on failure
10:29ElBarto: anyway, I can look at making a qemu-ci friendly image if you want
10:29ElBarto: an official one I mean
10:29emersion: yeah, please do! i think for gitlab, just something which has sshd enabled by default would be enough
10:29ElBarto: yeah sshd+emptypasswords should be enough
10:30ElBarto: some scripts can bootstrap pkg and install what it needs then
10:30ElBarto: https://git.sr.ht/~sircmpwn/builds.sr.ht/tree/master/images/freebsd/genimg#L91 is that needed ?
10:30emersion: maybe growfs too, so that people can just resize the disk, boot it and get extra space
10:31emersion: hmm, is the group added by default?
10:31ElBarto: yeah grosfs and some ifconfig_DEFAULT=DHCP
10:31emersion: this would be something i'd like to use in the wayland and weston CI too
10:31emersion: to finally upstream freebsd patches
10:32ElBarto: email@example.com will be happy :)
10:32emersion: ahah :P
10:41ElBarto: emersion: btw weston was removed for our ports tree, don't remember the reason though ...
10:46FireBurn: cwabbott: I've bisected to one of your commits
10:55FreeFull: I'm wondering if it's the fault of that commit, or if that commit just happened to expose a pre-existing bug
10:58cwabbott: it almost certainly is
10:58cwabbott: that commit shouldn't affect anything at all
11:10emersion: ElBarto: oh really? i'd be interested to know why. maybe not enough interested from maintainers?
11:11ElBarto: emersion: yeah I think that jbeich@ didn't used it and no one stepped up to maintain it
11:11emersion: makes sense
11:12emersion: completely understandable, weston doesn't have many desktop users (and doesn't try to)
11:17tzimmermann: danvet, mripard, mlankhorst, what's the policy for merging upstream kernels back into drm-misc-fixes? i wonder if i should merge the recent v5.8-rc4
11:26mlankhorst: tzimmermann: I mostly fast-forward to drm/drm-fixes if possible
11:26mlankhorst: usually it takes on the latest rc
11:28tzimmermann: i see. is there a dim command to fast-forward, or should i use dim backmerge?
11:28mlankhorst: git merge --ff-only
11:28mlankhorst: if you really need a specific fix in the latest rc, you can backmerge if you require
11:30tzimmermann: got it, thanks
11:30mlankhorst: I try to do it on monday morning, least chance something is committed. :)
12:20hakzsam: CI failure: https://gitlab.freedesktop.org/hakzsam/mesa/-/jobs/3505066
13:15MrCooper: hakzsam: VK-GL-CTS pulling stuff from sourceforge.net FTL
13:15hakzsam: yeah, just reporting in case someone is interested :)
13:16MrCooper: anyway, since you're not making any changes to that image, retry and it should just get copied from the main project registry
13:18hakzsam: yes, that MR has been merged since
18:52jekstrand: What is this kernel+rootfs_arm64 job? It's failing
19:15anholt__: jekstrand: scroll up a bit, there's a missing "needs"
19:16anholt__: gitlab ci unforunately doesn't just automatically handle transitive dependencies
19:17jekstrand: anholt__: Is there a fix incoming?
19:18anholt__: nobody's put one up yet, I've been trying to take a break from CI to write some actual code.
19:18anholt__: you just need to put a needs on the missing job in the job that's looking for it
19:19anholt__: (note how other jobs with transitive deps on container jobs list them)
19:23jekstrand: anholt__: It looks to me like a download from SF is failing
19:23anholt__: oh, that's different, that was also mentioned in scrollback, theoretically when the job eventually completes on master then everyone will get the updated image from master
19:23anholt__: but maybe someone needs to click retry on master
19:23anholt__: VK-GL-CTS depending on things from SF FTL
19:24anholt__: hmm, looks like pipelines have passed on master
19:25jekstrand: fetching with wget, it looks like it redirects a few times
19:25jekstrand: Maybe python doesn't like that?
19:26jekstrand: Works locally
19:26jekstrand:clicks the "retry" button
19:27jekstrand: Why is this even re-running on my push?
19:27jekstrand: Can we not cache CTS builds?
19:27anholt__: they are cached, that's the whole ci-templates infrastructure
19:28jekstrand: I clicked retry and it succeeded immediately
19:28jekstrand: And now panfrost jobs are running
19:28jekstrand: I have no idea what's going on
19:28anholt__: you touched nir so everything is getting tested?
19:29jekstrand: Made nir_validate suck a little less
19:29anholt__:not sure where you're confused
19:31jekstrand: I'm not confused
19:32jekstrand: I'm just annoyed every time the GitLab CI breaks for reasons that are completely opaque to me and have nothing to do with my MR.
19:35anholt__: reporting these intermittent issues to irc is probably not the best forum, I guess we could try to create a culture of reporting to the mailing list?
19:36jekstrand: Should we file bugs with a ci tag?
19:36anholt__: but I've been putting my points of intermittent handling into tracking down and filing issues
19:36anholt__: that's what I do.
19:59pinchartl: danvet: I'd like to get the Xilinx DPSUB driver merged for the next merge window, but it depends on dmaengine patches that target the same. I've thought about providing a branch based on v5.8-rc1 to be merged in both the dmaengine and drm trees, but there's a conflict on the dmaengine side. would you consider merging dmaengine/next into drm/next to avoid a one release delay ?
19:59danvet: pinchartl, do we need that conflict resolved for drm side?
20:00danvet: if it's just dmaengine internal, could resolve that when it's pulled into the dmaengine branches
20:00pinchartl: it's a new DMA engine API
20:00pinchartl: to be precise, a new flag in the DMA engine API
20:00danvet: well what I mean is we have 3 trees, dmaengin, your dmaegnine topic branch, drm-next
20:00pinchartl: and someone else has added another new flag, so there's a conflict there
20:01danvet: if the conflict is only between the first two, then resolving it only in that merge is ok
20:01danvet: yeah sounds like that case
20:01pinchartl: that's fine with me, but I don't know vif Vinod would accept that
20:01pinchartl: I'll try
20:01danvet: kick a thread off
20:02danvet: but yeah if it's just a flag, topic branch on -rc1, smash into both trees
20:02danvet: since the conflict is only with dmaengine, within dmaengine
20:02pinchartl: that's my preference too
20:02pinchartl: I'll provide a merge of topic + dmaengine-next with the conflict resolution for Vinod to merge
20:02pinchartl: and DRM would just get the topic branch
20:02danvet: once vinod has acked the topic branch, pull it into drm (with vinod's ack)
20:03danvet: I'm assuming you send it directly for drm.git?
20:03danvet: for that maybe best to have 2 pulls, first for the dmaengine baseline, then the driver
20:03danvet: or can we stuff xilinx into drm-misc
20:04pinchartl: correct, I'll wait for the branch to be pulled by Vinod before sending a pull request for drm.git
20:04pinchartl: or drm-misc, doesn't matter too much
20:04pinchartl: but in any case the dmaengine part needs to be pulled first