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