06:13Ford_Prefect: __tim: ack, I do think something is wrong, I'll try to make a reproducer (the delayed base time distribution to a bin with a sink and without no preroll elements in a live pipeline)
06:17Ford_Prefect: uff, wrong channel, sorry
07:39eric_engestrom: DavidHeidelberg[m]: "I plan to drop custom libdrm builds" -> I'm not sure that can work long term; sooner or later some driver will need an updated libdrm before debian has gotten around to update it, and devs of that driver will have to choose between not being able to merge their work, and revert your changes
09:39DavidHeidelberg[m]: eric_engestrom: I'm thinking aboit debian backports if needed OR small Debian repo with upreved stuff we need for CI
10:22eric_engestrom: DavidHeidelberg[m]: time will tell, but I kind of expect dropping the libdrm build would have to be reverted sooner or later, and it's unclear to me what is gained by it (other than a couple of seconds of container build time), so a priori I think it's best to keep it, but I may be missing something :]
10:24mupuf:would also think that depending on a distro to provide core dependencies is a bad idea
11:18DavidHeidelberg[m]: mupuf: first, it's core but kinda generic; second then we dont have to break packaging by force removing libdrm2 and supplying it externally
11:19DavidHeidelberg[m]: Also we use Debian as primary platform for testing, so having backport OR custom repo with packages we need makes a lot of sense to me
11:19pq: why not simply overwrite the distribution installed files? You're never going to install/upgrade any distropackages after that, right?
11:23pq: backport or custom package repo makes me think that a Mesa MR can never simply bump libdrm version, the version bump needs to be done separately somewhere else first and landed?
11:48mupuf: DavidHeidelberg[m]: What packages do we actually use from debian?
11:48mupuf: Don't we pretty-much build everything anyway?
11:49mupuf: not talking about the compiler toolchains, I mean what packages would transitevely depend on libdrm
11:53DavidHeidelberg[m]: mesa, since some other deps pull it in
11:53DavidHeidelberg[m]: At least in vk gl containers
11:54DavidHeidelberg[m]: and other mesa related libs
11:57mupuf:is a little confused... mesa is installed in the test containers?
12:04eric_engestrom: I expect that might be because the mesa package is often where the egl/gl/gles headers are provided, which is what a lot of packages actually need
12:05eric_engestrom:doesn't actually know if that's how debian does its packaging
12:05eric_engestrom: hmm, no I remember now, debian splits the headers into a `-dev` (or `-devel`?) sub-package
12:06eric_engestrom: oh wait no, that would be to build the packages, not to install them
12:06eric_engestrom: you can ignore everything I just said xD
12:08mupuf: yeah, I am also quite likely waaaaay out of touch here
12:09mupuf: Just looked at Arch's packaging, and I already spotted a circular dependency (libglvnd depends on mesa, and vice-versa)
12:57MrCooper: DavidHeidelberg[m]: pq's idea is worth a try I think, basically install the custom libdrm build to /usr instead of /usr/local
15:39DavidHeidelberg[m]: Not going to one way to hell override packages installed by dpkg; anyway the bumping packages should stay easy even with our repo
15:39DavidHeidelberg[m]: Just you could install it locally too
16:15DavidHeidelberg[m]: pq: about the workflow, it would be something like "mesa/ci-packaging" -> new issue "I need package" or MR for new "Changelog entry", the CI will build packages; then from the build you just reference the built version
16:16DavidHeidelberg[m]: the trick is, we know we build against Debian 12, the base isn't changing, we don't need rebuild (ok, we have ccache, so not that terrible) or link (more and more stuff use LTO, linking takes much longer) for 40 minutes per rootfs, we just install the right packages (which we have control over)
16:17DavidHeidelberg[m]: also packages builds has reproducibility tests, QA tests.. that's all for free. Now we just dump some binaries somewhere
17:42robclark: DavidHeidelberg[m]: what happens for someone working on a change that spans mesa and libdrm.. that sounds like a sort of chicken vs. egg problem.
17:43DavidHeidelberg[m]: robclark: can pull deb package from fork? :)
17:43mupuf: robclark: sounds like a flag day to me... Bad idea?
17:45robclark: mupuf: I mean, how are you going to test whatever new addition to libdrm that your mesa changes depend on
17:45robclark: I mean, I'm kinda anti-libdrm_$driver being anything that is outside of mesa.. but it is what it is
17:46mupuf: Are there libdrm tests depending on mesa? :o
17:46robclark: DavidHeidelberg[m]: well, I don't have skin in the game since we pulled stuff into mesa.git/src/freedreno/drm .. but I'd be rather annoyed if I had to figure out debian packaging in order to do anything that spans libdrm+mesa
17:47robclark: I don't think there are libdrm tests depending on libdrm_$driver
17:47anholt: libdrm seems like the least productive thing to move to prebuilt packaging to me, since it's small and fast to build but we uprev a lot. if we could package vk-gl-cts that would be huge for container rebuild times.\
17:47DavidHeidelberg[m]: robclark: if you want "bump" package, you just add new version into `debian/changelog` that's copy paste :) (you don't need to do development, comply with some strict rules or whatever for this purpose)
17:47mupuf: True that
17:47DavidHeidelberg[m]: the CI does all the heavy lifting, QA, checks and produce deb files
17:47mupuf: DavidHeidelberg[m]: Debian packaging is IMO a complete clusterfuck
17:48DavidHeidelberg[m]: but... you don't have to do it :)
17:48anholt: that's also been my experience with debian packaging.
17:49DavidHeidelberg[m]: you just paste snipper with +1 version or something into changelog and wait until CI does it's job
17:49anholt: giving debian a vk-gl-cts package would be lovely, but they would want to strip it apart to separately package the third party libs and break it in the process.
17:49DavidHeidelberg[m]: s/snipper/snippet/ :D
17:49DavidHeidelberg[m]: anholt: that I was thinking about. We could have these packages; we do them quick and dirty, and someone can come up, improve QA, upstream them into Debian
17:49mupuf: Not even sure why we use such an outdated distro as a base
17:50DavidHeidelberg[m]: mupuf: it's stable outdated base :D
17:50anholt: mupuf: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3123 unfortunately
17:51anholt: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3123#note_715416 specifically
17:52mupuf: Stability through dust-gathering, releasing a new stable version using outdated upstream versions (unsupported)... Not my definition of stable
17:52DavidHeidelberg[m]: anholt: https://gitlab.freedesktop.org/freedesktop/ci-templates/-/merge_requests/161 :( that ended as I got excited it'll solve all problems
17:52DavidHeidelberg[m]: we would have to maintain it for ourselfs..
17:53anholt: /o\ debian
17:53robclark: DavidHeidelberg[m]: I expect it is more work than that if you need to build libdrm from your gitlab fork with some things that haven't landed yet in a libdrm release.. as is going to be the case when you are developing the libdrm+mesa MRs
17:53mupuf: anholt: thanks for the links! I thought that was the downside of distros like arch... But it doesn't appear so :s
17:53anholt: robclark: that's not something we've done in the past for libdrm.
17:54DavidHeidelberg[m]: git merge _your_tag; vim debian/changelog :) not that painful (thou one step more with debian/changelog)
17:54mupuf: Why the fuck would one need to edit the changelog to build a new package? :o
17:55mupuf: Is the package version there?
17:55robclark: anholt: it would need to be in a libdrm release before the MR is ready to be merged in mesa.. but that doesn't mean that is the only time CI is involved..
17:55robclark: ie. it is useful to run CI pipelines on draft MRs
17:55anholt: robclark: is that something you've done? Because it's not something I've seen people do yet.
17:56DavidHeidelberg[m]: because CI wants to version it?
17:56DavidHeidelberg[m]: you don't build same package all over again and upload it same with our rootfs/container images, you always have to change version
17:56robclark: I do it
17:56robclark: frequently
17:56anholt: oh, interesting
17:56robclark: (but when marge is not busy)
17:56mupuf: DavidHeidelberg[m]: sure, but in arch it would be bumping the PKG version... Not editing its changelog
17:57robclark: anyways, like I said, I don't have to deal with libdrm so I don't have a stake in it.. but relying on deb packages for libdrm sounds like a really horrible idea
17:58anholt: mupuf: debian/changelog is debian's package versions plus commit messages because they don't have common source control for packaging.
17:58mupuf: Anyway. My point is: let's not make dealing with CI harder than it has to be. Learning gitlab ci and ci-templates is hard-enough, let's not add too much
17:58anholt: mupuf: yes, exactly.
17:58mupuf: anholt: lovely
17:58DavidHeidelberg[m]: robclark: right now it was better? deqp just time to time picking /usr libdrm, time to time /usr/local; or remove libdrm in build process and break other builds; or overwrite it and risk it gets mess up?
17:59robclark: build libdrm to install to /usr
17:59DavidHeidelberg[m]: see my later part of message :)
17:59mupuf: DavidHeidelberg[m]: you could reuse or build/upload the package as part of the CI-template build script
17:59DavidHeidelberg[m]: combining packages with custom stuff installed by hand is usually highway to hell. Also custom builds aren't aligned with what distro does, so it can introduce issues
18:00anholt: yes, it can introduce issues. life is hard. distro packaging is harder.
18:00mupuf: This way, we get caching between builds AND it is mostly transparent
18:00DavidHeidelberg[m]: mupuf: I'm listening :)
18:01mupuf: Doesn't have to be packages either, can be tarballs too
18:01mupuf: Sorry, gotta g
18:01mupuf: Just view it as a multilayer tag
18:03robclark: DavidHeidelberg[m]: not sure which "message" you refer to, tbh.. but it isn't like the container is ever going to `apt-get upgrade` so pretty sure all the reasons for not overwriting distro pkg files don't apply
18:04DavidHeidelberg[m]: robclark: my point is, it's hard keep track what is where. When you have distro with packaging and you don't plan to "rework" the distro from scratch, it's usually nicer do just adjustments, instead of doing stuff by hand
20:46dviola: hi, I just deleted my account at https://gitlab.freedesktop.org and created it again, I forgot I had this issue open: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4369 -- can I still take ownership of that issue?
21:11eric_engestrom: dviola: I don't think that's possible without the admins putting their hands inside the database and touching a bunch of things; the best thing to do is probably for you to post a comment explaining what you just said, so that people know who to tag to continue the conversation
21:18dviola: eric_engestrom: makes sense, ok I will do that, thanks