ChanServ changed the topic of #freedesktop to: https://www.freedesktop.org infrastructure and online services || for questions about freedesktop.org projects, please see each project's contact || for discussions about specifications, please use https://gitlab.freedesktop.org/xdg or xdg@lists.freedesktop.org
alanc has quit [Remote host closed the connection]
<Ford_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)
<Ford_Prefect>
uff, wrong channel, sorry
alpernebbi_ has quit []
alpernebbi has joined #freedesktop
todi has quit [Remote host closed the connection]
<eric_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
<DavidHeidelberg[m]>
eric_engestrom: I'm thinking aboit debian backports if needed OR small Debian repo with upreved stuff we need for CI
<eric_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 :]
* mupuf
would also think that depending on a distro to provide core dependencies is a bad idea
blatant has quit [Quit: WeeChat 3.8]
AbleBacon has quit [Read error: Connection reset by peer]
<DavidHeidelberg[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
phryk has quit [Ping timeout: 480 seconds]
<DavidHeidelberg[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
<pq>
why not simply overwrite the distribution installed files? You're never going to install/upgrade any distropackages after that, right?
<pq>
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?
phryk has joined #freedesktop
<mupuf>
DavidHeidelberg[m]: What packages do we actually use from debian?
<mupuf>
Don't we pretty-much build everything anyway?
<mupuf>
not talking about the compiler toolchains, I mean what packages would transitevely depend on libdrm
<DavidHeidelberg[m]>
mesa, since some other deps pull it in
<DavidHeidelberg[m]>
At least in vk gl containers
<DavidHeidelberg[m]>
and other mesa related libs
vkareh has joined #freedesktop
* mupuf
is a little confused... mesa is installed in the test containers?
<eric_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
* eric_engestrom
doesn't actually know if that's how debian does its packaging
<eric_engestrom>
hmm, no I remember now, debian splits the headers into a `-dev` (or `-devel`?) sub-package
<eric_engestrom>
oh wait no, that would be to build the packages, not to install them
<eric_engestrom>
you can ignore everything I just said xD
<mupuf>
yeah, I am also quite likely waaaaay out of touch here
<mupuf>
Just looked at Arch's packaging, and I already spotted a circular dependency (libglvnd depends on mesa, and vice-versa)
chipxxx has quit [Ping timeout: 480 seconds]
<MrCooper>
DavidHeidelberg[m]: pq's idea is worth a try I think, basically install the custom libdrm build to /usr instead of /usr/local
pendingchaos_ is now known as pendingchaos
Haaninjo has joined #freedesktop
damian has quit []
damian has joined #freedesktop
i509vcb has quit [Quit: Connection closed for inactivity]
<DavidHeidelberg[m]>
Not going to one way to hell override packages installed by dpkg; anyway the bumping packages should stay easy even with our repo
<DavidHeidelberg[m]>
Just you could install it locally too
jarthur has joined #freedesktop
<DavidHeidelberg[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
<DavidHeidelberg[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)
<DavidHeidelberg[m]>
also packages builds has reproducibility tests, QA tests.. that's all for free. Now we just dump some binaries somewhere
ximion has joined #freedesktop
___nick___ has joined #freedesktop
___nick___ has quit []
___nick___ has joined #freedesktop
i509vcb has joined #freedesktop
eroux has joined #freedesktop
agd5f_ has quit []
agd5f has joined #freedesktop
<robclark>
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.
<DavidHeidelberg[m]>
robclark: can pull deb package from fork? :)
<mupuf>
robclark: sounds like a flag day to me... Bad idea?
<robclark>
mupuf: I mean, how are you going to test whatever new addition to libdrm that your mesa changes depend on
<robclark>
I mean, I'm kinda anti-libdrm_$driver being anything that is outside of mesa.. but it is what it is
<mupuf>
Are there libdrm tests depending on mesa? :o
<robclark>
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
<robclark>
I don't think there are libdrm tests depending on libdrm_$driver
<anholt>
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.\
<DavidHeidelberg[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)
<mupuf>
True that
<DavidHeidelberg[m]>
the CI does all the heavy lifting, QA, checks and produce deb files
<mupuf>
DavidHeidelberg[m]: Debian packaging is IMO a complete clusterfuck
<DavidHeidelberg[m]>
but... you don't have to do it :)
<anholt>
that's also been my experience with debian packaging.
<DavidHeidelberg[m]>
you just paste snipper with +1 version or something into changelog and wait until CI does it's job
<anholt>
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.
<DavidHeidelberg[m]>
s/snipper/snippet/ :D
<DavidHeidelberg[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
<mupuf>
Not even sure why we use such an outdated distro as a base
<DavidHeidelberg[m]>
mupuf: it's stable outdated base :D
<DavidHeidelberg[m]>
we would have to maintain it for ourselfs..
<anholt>
/o\ debian
<robclark>
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
<mupuf>
anholt: thanks for the links! I thought that was the downside of distros like arch... But it doesn't appear so :s
<anholt>
robclark: that's not something we've done in the past for libdrm.
<DavidHeidelberg[m]>
git merge _your_tag; vim debian/changelog :) not that painful (thou one step more with debian/changelog)
<mupuf>
Why the fuck would one need to edit the changelog to build a new package? :o
<mupuf>
Is the package version there?
<robclark>
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..
<robclark>
ie. it is useful to run CI pipelines on draft MRs
<anholt>
robclark: is that something you've done? Because it's not something I've seen people do yet.
<DavidHeidelberg[m]>
because CI wants to version it?
<DavidHeidelberg[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
<robclark>
I do it
<robclark>
frequently
<anholt>
oh, interesting
<robclark>
(but when marge is not busy)
<mupuf>
DavidHeidelberg[m]: sure, but in arch it would be bumping the PKG version... Not editing its changelog
<robclark>
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
<anholt>
mupuf: debian/changelog is debian's package versions plus commit messages because they don't have common source control for packaging.
<mupuf>
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
<anholt>
mupuf: yes, exactly.
<mupuf>
anholt: lovely
<DavidHeidelberg[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?
<robclark>
build libdrm to install to /usr
<DavidHeidelberg[m]>
see my later part of message :)
<mupuf>
DavidHeidelberg[m]: you could reuse or build/upload the package as part of the CI-template build script
<DavidHeidelberg[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
<anholt>
yes, it can introduce issues. life is hard. distro packaging is harder.
<mupuf>
This way, we get caching between builds AND it is mostly transparent
<DavidHeidelberg[m]>
mupuf: I'm listening :)
<mupuf>
Doesn't have to be packages either, can be tarballs too
<mupuf>
Sorry, gotta g
<mupuf>
Just view it as a multilayer tag
<robclark>
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
<DavidHeidelberg[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
Kayden has quit [Quit: to office]
ninja21859 has joined #freedesktop
alatiera has quit [Ping timeout: 480 seconds]
alatiera has joined #freedesktop
mvlad has quit [Remote host closed the connection]
___nick___ has quit [Ping timeout: 480 seconds]
AbleBacon has joined #freedesktop
garrison has quit [Read error: Connection reset by peer]
<eric_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
<dviola>
eric_engestrom: makes sense, ok I will do that, thanks
sauce has quit []
woodwose has quit [Quit: syl]
woodwose has joined #freedesktop
xybre has left #freedesktop [Konversation terminated!]