ChanServ changed the topic of #freedesktop to: infrastructure and online services || for questions about projects, please see each project's contact || for discussions about specifications, please use or
<pendingchaos> this channel is mostly for freedesktop infrastructure and online services, rather than hosted projects
<pendingchaos> I don't know what would be a good channel for d-bus
<daniels> Harzilein: yeah, the dbus@ mailing list is the best forum for it
ybogdano has quit [Ping timeout: 480 seconds]
damian has quit [Read error: Connection reset by peer]
damian has joined #freedesktop
anholt has quit [Ping timeout: 480 seconds]
ofourdan has quit [Ping timeout: 480 seconds]
anholt has joined #freedesktop
jarthur has quit [Quit: Textual IRC Client:]
systwi_ has joined #freedesktop
agd5f_ has joined #freedesktop
systwi has quit [Ping timeout: 480 seconds]
agd5f has quit [Ping timeout: 480 seconds]
danvet has joined #freedesktop
aswar002 has quit [Quit: - Chat comfortably. Anywhere.]
aswar002 has joined #freedesktop
agd5f has joined #freedesktop
agd5f_ has quit [Ping timeout: 480 seconds]
itoral has joined #freedesktop
alanc has quit [Remote host closed the connection]
alanc has joined #freedesktop
SirNeo has left #freedesktop [#freedesktop]
agd5f_ has joined #freedesktop
agd5f has quit [Ping timeout: 480 seconds]
mvlad has joined #freedesktop
phasta has joined #freedesktop
<MrCooper> bentiss: the -12 runner seems to have similar issues as the -11 one before:
<bentiss> MrCooper:all the runners are now using podman
<MrCooper> meson tests are timing out for no apparent reason
<bentiss> MrCooper: the "glamor" part makes me think it needs to have access to the host
<bentiss> and that's bad anyway
<bentiss> so I would ask to use boot2container to start the tests in a VM
<MrCooper> not sure what you mean
<MrCooper> the glamor tests use llvmpipe
<MrCooper> I saw similar issues yesterday (in Mesa IIRC) with the -11 runner before you took it out
<bentiss> MrCooper: previously, we had full access to the host with docker as the containers are privileged. IOn the short future I want to switch to rootless podman, so we better fix our CI instead.
<bentiss> This way we could securely do releases through CI
<MrCooper> I get that, but I don't see how this issue is related
<MrCooper> it doesn't have anything to do with docker or host access
<bentiss> SocketCreateListener() failed -> probably a permission issue?
___nick___ has joined #freedesktop
<bentiss> MrCooper: can you point at failing mesa jobs?
<MrCooper> some of the same tests passed fine in
<MrCooper> bentiss: I don't remember I'm afraid, it was likely one mentioned here or on #dri-devel
<bentiss> MrCooper: so far, all of the mesa failing ones I have seen have been fixed by using a more recent podman version
<bentiss> so it's weird to me that only xserver is having such issues
<bentiss> gstreamer, mesa, networkmanager all are fine with podman
<MrCooper> so is xserver, in some jobs, just not always
ofourdan has joined #freedesktop
<bentiss> testing locally on rootless podman, on fedora
<bentiss> seems perfectly fine on local container...
<bentiss> but I am not running 10 containers with the same test suite at the same time
<MrCooper> it seems to be "meson dist" which fails (not always though, even on the same runner), wonder if that does something special
<bentiss> it might be interesting to test on an alpine base image, instead of debian stable. maybe we have less tuning to do there
<bentiss> cause we don't have the ability to freshly install a debian 12 system
<bentiss> and all of the other images and quite old too (beside ubuntu 22.04 but I'd rather not go there
<MrCooper> nope, not specific to meson dist:
<MrCooper> looks like it's hitting some limit on the number of threads maybe
<bentiss> does the test suite in xserver handles FDO_CI_CONCURRENT?
<MrCooper> actually one issue in xserver's CI is that it uses ninja test, which ends up spawning the maximum number of test threads regardless of -j
<MrCooper> would need to use meson test directly instead
<MrCooper> still seems like the limit is too low though, if a few xserver jobs hit it
<bentiss> MrCooper: if you point at the setting, I would happily change it
<MrCooper> I would if I knew it offhand :)
<bentiss> damn, fpaste is not responding
<bentiss> -> doesn't look so bad
pixelcluster has quit [Quit: Goodbye!]
<MrCooper> all I can say is it was never an issue before, and now it suddenly is
pixelcluster has joined #freedesktop
a-l-e has joined #freedesktop
<MrCooper> this might affect other projects as well though
<bentiss> MrCooper: testing tright now the current pipeline on a runner that has no load whatsoever, and it's already failing :)
<daniels> MrCooper: setting LP_NUM_THREADS=1 is probably also a good idea
<MrCooper> hmm yeah, maybe it's the <number of test processes> * <number of llvmpipe threads> explosion?
<MrCooper> still not clear why it's suddenly an issue now, not before
<MrCooper> actually only (some of) the X server processes should spawn llvmpipe threads, not every test process
<bentiss> that's weird. On that runner, with htop I don ´t even see the CPU getting used when everything explodes
<bentiss> (without your patch)
<MrCooper> it feels like some kind of artificial limit
<bentiss> yeah, I just don't know where it comes from, and why it wasn't an issue before
<bentiss> and OTOH, if it forces people to have a fair usage of CI, that's not so bad :)
<MrCooper> true, but I'm worried that we can hit the limit even with reasonable utilization
<bentiss> TBH, I am starting to wonder if we should keep debian testing as a base for those runners. Something like CoreOS or Silverblue (even flatcar linux if it weren't using docker) would be easier to maintain IMO
hikiko has joined #freedesktop
vbenes1 has joined #freedesktop
vbenes has quit [Read error: Connection reset by peer]
AbleBacon has quit [Read error: Connection reset by peer]
vbenes2 has joined #freedesktop
vbenes1 has quit [Read error: Connection reset by peer]
a-l-e has quit [Quit: Leaving]
hikiko has quit []
vbenes2 has quit []
vbenes has joined #freedesktop
phasta has quit [Ping timeout: 480 seconds]
phasta has joined #freedesktop
vladh has joined #freedesktop
<vladh> I signed up for an account two hours ago but it's still "blocked", any tips?
<bentiss> vladh: you should have received a verification email
<bentiss> vladh:if not I can manually allow you in
<vladh> bentiss: I haven't :( my email is
<bentiss> vladh: done
<vladh> bentiss: thank you very much :)
<bentiss> you're welcome (and sorry if it doesn't work quite well, it's an attempt at fighting bots)
pjakobsson has joined #freedesktop
<kbingham> Aha... so signup is limited at the moment? My colleague djrscally also just tried to signup and hasn't been able to yet.
djrscally has joined #freedesktop
<bentiss> kbingham: it's not. it's supposed to be working, with a delay. But it seems people who are using non standrad domains are having issues
<bentiss> kbingham: if you need I can also unlock the situation for that person
<kbingham> Ah. What's 'non-standard domain'? I expect he signed up with
<kbingham> bentiss, Yes please!
<bentiss> kbingham: approved
<kbingham> bentiss, Thankyou
<bentiss> kbingham: honestly no idea what would be non standard
vladh has left #freedesktop [Igloo IRC:]
<kbingham> :-)
<bentiss> maybe it's time for me to check if that manual registration is still working
itoral has quit [Remote host closed the connection]
<kbingham> Is there anyway with gitlab to 'add' tags to a commit message? (I'm guessing not, so I'm wondering what equivalent options there are)
<kbingham> Trying things out djrscally sent me a merge request. Previously I would have added Reviewed-by: tags....
<kbingham> But now - it's just 'punch the merge button' ...
<bentiss> kbingham: projects like mesa and gstreamers are using bots for that
<ofourdan> for the xserver, this is still a manual process
<bentiss> the bot rewrite the commits, force pushes the branch, and wait for the CI before merging the code
<kbingham> are the bots gitlab side?
<kbingham> sounds like what I'd be after.
<bentiss> kbingham: they are hosted by us, but not part of gitlab (same infra but not pure gitlab)
<__tim> in GStreamer we just add Part-of: <merge-request-url> to the commit message, we don't add reviewed-by / approved-by etc.
<__tim> (that info is in gitlab)
<ofourdan> yeah, gnome does the same
<kbingham> Thanks - lots to experiment with then.
<DavidHeidelberg[m]> Anyone could review it's for making s3cp more reliable, and also resistant against 50x errors
<DavidHeidelberg[m]> Need to merge it ASAP for Mesa3D; but not risking that without review from someone with deeper knowledge of ci-fairy + Python :)
<bentiss> DavidHeidelberg[m]: dumb question, have you tried it with a large data to send?
<DavidHeidelberg[m]> nah, but I can do in 20 minutes
<bentiss> I am a little bit worry about the "So if you’re making several requests to the same host, the underlying TCP connection will be reused"
<bentiss> I am not sure how this is seen on the host side
<bentiss> server
<DavidHeidelberg[m]> yes, if the connection works? anyway, let me run whole mesa against it
<bentiss> that would be nice
<bentiss> I can monitor the logs on the server side
<bentiss> you need to also overwrite the ci-fairy image
<bentiss> DavidHeidelberg[m]: let me find an example for you
ds` has quit [Quit: ...]
ds` has joined #freedesktop
<DavidHeidelberg[m]> bentiss: oh you saved me! thanks
<bentiss> make it in your case
<DavidHeidelberg[m]> right, the harbor usage :) thx!
<bentiss> well, you don't need to directly use harbor actually, the runners will pick it up
<bentiss> so just as taken from your container registry
<bentiss> mupuf: I have a selfish request: would you mind getting out a release of boot2container? I have added vm2c in the kernel for hid and now it fetches the latest released initramfs which is not compatible with the new options
<bentiss> great :)
<mupuf> you may use these binaries already, if you need
<bentiss> that was also a way to tell you that I put vm2c in the kernel :)
<mupuf> gotta go
<mupuf> oh, right, wonderful!
<bentiss> k, no worries
Haaninjo has joined #freedesktop
<mupuf> congrats, and thanks!
<bentiss> next step would be to put it directly in the Makefile of selftest
<bentiss> :)
<bentiss> DavidHeidelberg[m]: looks like the server is happy with your requests, both single upload and multi
<DavidHeidelberg[m]> nice
<bentiss> well, I'm still witing for the POST at the end of the /artifacts/mesa/mesa/787944/mesa-arm64-asan.tar.zst upload
<DavidHeidelberg[m]> bentiss: that's not going to happen :(
<bentiss> \the uploaded file is still 151 MB, so why is it not complete
<bentiss> huh, the file seems fine.
<DavidHeidelberg[m]>, headers=headers, params={"uploadId": key}, data=complete) # this didn't worked, right?
<bentiss> oh, wait it might be my filter on the logs
<bentiss> that was it. the POST log in the server doesn't give me s3.fd.o and I was filtering on it
<bentiss> all good
<DavidHeidelberg[m]> uffff
<DavidHeidelberg[m]> I wonder, is any chance that session will decrease load on the servers? (there isn't new connection, but if it reuses existing, it could save a bit work).. just curious if it's relevant at this scale
<bentiss> not sure I'll be able to measure that
<bentiss> the thing is we have *a lot* of connections and they should use all 3 control planes, so hard to see a difference
<bentiss> it would matter only at he nginx level too, I am not sure it keeps the same connection between nginx and ceph
<bentiss> plus when you upload the file to ceph, it internally gets replicated over 3 nodes, so it might have some benefits, but I wouldn't bet anything on a reduce load of the cluster
<bentiss> DavidHeidelberg[m]: also just stating the obvious: you have to wait for to finish before you can include the ci-templates sha in mesa
<bentiss> (the publish to quay happens when the pipeline is correct, at the very end)
<DavidHeidelberg[m]> oh, thanks for merging :)
<MrCooper> bentiss daniels: I wonder how many other projects use "ninja -j<...> test" in CI and expect it to limit the number of test processes spawned in parallel :/
<bentiss> MrCooper: actually I should try to see if podman is capable of limitting how many cpus are exposed to the container
<bentiss> I know it didn't work with docker
<MrCooper> would be nice if it was possible
<bentiss> IIRC there is gitlab-runner option that wasn't properly handled
<bentiss> well, we can limit the cpu usage, not how many are exposed
<MrCooper> taskset affects the nproc command, sadly not meson though
<bentiss> given that it's not using cpu, but just spawning too many tests, it doesn't work to induce that quota
<bentiss> (and the machine was loaded between 30 to 60 as some virglrenderer tests were also running)
<daniels> last time I looked at that, we'd need to make podman use a runtime like Kata which would spawn a VM that we could limit the number of CPUs on
MrCooper has quit [Quit: Leaving]
MrCooper has joined #freedesktop
MrCooper has quit [Quit: Leaving]
MrCooper has joined #freedesktop
bl4ckb0ne has quit [Remote host closed the connection]
emersion has quit [Remote host closed the connection]
bl4ckb0ne has joined #freedesktop
emersion has joined #freedesktop
ybogdano has joined #freedesktop
<MrCooper> daniels: BTW, LP_NUM_THREADS=1 still spawns one worker thread; LP_NUM_THREADS=0 was measurably lighter, so I went for that in
* bentiss is rather confused... since the stats for the containers usage are definitely not working :(
<bentiss> so we were clearing all images all the time (expect those that are in the keep-list)
djrscally has quit [Ping timeout: 480 seconds]
djrscally has joined #freedesktop
eroux has quit [Ping timeout: 480 seconds]
djrscally has quit [Ping timeout: 480 seconds]
sbraz has quit [Quit: ZNC -]
sbraz has joined #freedesktop
eroux has joined #freedesktop
phasta has quit [Quit: Leaving]
miracolix has joined #freedesktop
jarthur has joined #freedesktop
___nick___ has quit []
___nick___ has joined #freedesktop
___nick___ has quit []
___nick___ has joined #freedesktop
Leopold has quit [Remote host closed the connection]
Leopold_ has joined #freedesktop
ybogdano has quit [Ping timeout: 480 seconds]
<eric_engestrom> any objection to me merging a bunch of timestamps in the ci to have them next time an issue happens?
ybogdano has joined #freedesktop
<DavidHeidelberg[m]> eric_engestrom: I object, your honor.
<DavidHeidelberg[m]> What about using timestamps in the sections?
<anholt> then you have to keep breaking down smaller and smaller sections to debug, when if you just had timestamps you could take your failing log and figure out where things stalled.
<eric_engestrom> DavidHeidelberg[m]: too coarse
<anholt> gitlab also managed to snatch failure from the jaws of victory by concluding that requests for timestamps were actually just requests for section timings.
<eric_engestrom> (also, please don't use the phrase "make X great again")
<DavidHeidelberg[m]> the quote is catchy, can't help it ;-) (for political reasons, I declare I don't care about politics)
<eric_engestrom> oh, I was about to marge it (thanks for the acks!), but I just realized I need to bump container tags; just KERNEL_ROOTFS_TAG, right?
<anholt> nothing in that MR affects containers
<anholt> the CI *.{sh,txt,yml,toml} files go through artifacts
<eric_engestrom> ah right
<eric_engestrom> thanks :)
<eric_engestrom> ok, marg'ing then
ybogdano has quit [Ping timeout: 480 seconds]
agd5f_ has quit []
agd5f has joined #freedesktop
Leopold___ has joined #freedesktop
Leopold_ has quit [Remote host closed the connection]
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #freedesktop
Kayden has quit [Quit: to lunch and office for a bit]
ybogdano has joined #freedesktop
ybogdano has quit []
ybogdano has joined #freedesktop
___nick___ has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
ybogdano has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
AbleBacon has joined #freedesktop
djrscally has joined #freedesktop
ybogdano has joined #freedesktop
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #freedesktop
Haaninjo has quit [Quit: Ex-Chat]