daniels changed the topic of #freedesktop to: GitLab is currently down for upgrade; will be a while before it's back || 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
lsd|2 has quit []
co1umbarius has joined #freedesktop
columbarius has quit [Ping timeout: 480 seconds]
DragoonAethis has quit [Quit: hej-hej!]
DragoonAethis has joined #freedesktop
dri-logger has joined #freedesktop
lkundrak has quit [Remote host closed the connection]
dri-logg1r has quit [Ping timeout: 480 seconds]
glisse has quit [Ping timeout: 480 seconds]
glisse has joined #freedesktop
lkundrak has joined #freedesktop
<mupuf>
related to not over-using our runners, maybe we could drop some build jobs in mesa? For example, why do we have debian-vulkan? How is that different from debian-testing?
<mupuf>
then we have debian-rusticl and debian-rusticl-testing. Why make a distinction here? What's different?
<mupuf>
then we have debian-testing-asan, debian-testing-msan, debian-testing, and debian-build-testing. Is that really necessary?
<airlied>
there are short jobs that do enough to kick off further tests run, and longer jobs that do complete build tests
<airlied>
else the hw runs have to wait and the artifacts for future runs are larger
<mupuf>
the issue is that the shared runners have capacity for X jobs running in parallel
<mupuf>
and gitlab does not prioritize jobs that others depend on
<mupuf>
(would be a good thing to add to the issue, koike ^)
<airlied>
well combining those jobs will end up with the jobs that run on hardware having less time to complete
<airlied>
and transferring larger artifacts
<mupuf>
yeah, we have to be careful about that
<mupuf>
but debian-rusticl vs debian-rusticl-testing?
<mupuf>
surely we don't need to make two builds for rusticl, do we?
<mupuf>
and if the plan is to make artifacts as small as possible, then maybe let's stop naming them "debian-XXXXX", but instead let's say who they are for
<airlied>
probably not, but those are probably not the biggest problems
<mupuf>
a lot of the situation we are in is due to "death by thousand cuts"
<mupuf>
nothing on its own is really bad
<mupuf>
but as a whole, it is
<airlied>
yeah it might be possible to combine those two, they seem to been a bit carried over
<airlied>
it's just hard to say what catches bugs when and what value there is
<airlied>
particularly around the asan/msan
<mupuf>
oh, don't get me wrong, I'm all for sanitizers, but we do agree that they need to be run in order to catch stuff, right?
<mupuf>
debian-arm32-asan is not used at all
AbleBacon has quit [Read error: Connection reset by peer]
<mupuf>
I could also question the value of building for 390x... like, seriously? Do we expect any user there?
<airlied>
yes we have plenty
<airlied>
it's not like we added the s390x job for the lulz
<mupuf>
really? :o
<mupuf>
I thought the whole thing was dead
<mupuf>
"According to IBM, by May 2006, over 1,700 customers were running Linux on their mainframes." according to wikipedia
<mupuf>
I was expecting numbers to have gone down, not up
<mupuf>
oh, I see they still release hardware
<airlied>
everytime mesa breaks on s390x someone complains when we rebase
<mupuf>
ack
<mupuf>
would be good to review the list of build jobs though, pretty sure there is room for optimization here
<airlied>
just not sure who could decide what is waste and what is wanted, since it kinda grown from everyone saying we should add CI for that
<airlied>
probably anholt_ might be most aware
<mupuf>
yeah, this will require archeology, then comparing the build flags of each job
<mupuf>
I wouldn't be surprised if some jobs would not be entirely redundant
<airlied>
I doubt there is pure redundancy, but there might be pointless optimisations
Haaninjo has joined #freedesktop
swatish2 has joined #freedesktop
sima has joined #freedesktop
bmodem has joined #freedesktop
i-garrison has quit []
i-garrison has joined #freedesktop
tzimmermann has joined #freedesktop
<bentiss>
good morning (or afternoon) everyone. So question of the day: how are the new runners behaving. Has anyone seen a timeout issue with them trying to access gitlab.fd.o or was there an issue with s3.fd.o?
<bentiss>
I personally think that they are behaving properly, but this was just while I was stress-testing them and just looking at the number of failed jobs
<airlied>
I don't think I've seen any traces fails today
<bentiss>
\o/
vjaquez has quit [Remote host closed the connection]
<eric_engestrom>
mupuf: "oh, don't get me wrong, I'm all for sanitizers, but we do agree that they need to be run in order to catch stuff, right?"
<eric_engestrom>
these jobs run `meson tests` which does catch stuff, eg. mesa#9516, mesa#9517, mesa!24610 that I ran into a few weeks ago when I tried adding nvk & panvk to the debian-vulkan job
<zmike>
topic does need updating
<zmike>
unless this is all a lie and gitlab really is down
<mupuf>
eric_engestrom: oh!
<mupuf>
well, that makes more sense indeed
blatant has quit [Ping timeout: 480 seconds]
karolherbst is now known as karolherbst_
karolherbst_ is now known as karolherbst
gert31 has joined #freedesktop
blatant has joined #freedesktop
lsd|2 has quit []
ximion has joined #freedesktop
vkareh has joined #freedesktop
blatant has quit [Quit: WeeChat 4.0.4]
ximion has quit [Quit: Detached from the Matrix]
AbleBacon has joined #freedesktop
bmodem has quit [Ping timeout: 480 seconds]
jarthur has quit [Read error: Connection reset by peer]
An0num0us has quit [Ping timeout: 480 seconds]
alatiera has joined #freedesktop
Ahuj has quit [Ping timeout: 480 seconds]
bmodem has joined #freedesktop
gert31 has quit [Quit: Leaving]
An0num0us has joined #freedesktop
vkareh has quit [Quit: WeeChat 4.0.4]
tzimmermann has quit [Quit: Leaving]
An0num0us has quit [Ping timeout: 480 seconds]
vkareh has joined #freedesktop
<anholt_>
mupuf: debian-vulkan exists to test "can you build just vulkan and not GL?"
<anholt_>
people wanted that because it kept breaking
<anholt_>
asan and msan are in fact critical types of testing if you're writing C code.
<mupuf>
Ack for debian-vulkan
<mupuf>
Could asan and msan be combined? AKA, both sanitizers enabled?
<mupuf>
Doesn't look like it
<mupuf>
I guess there are no alternatives: we need prioritization
An0num0us has joined #freedesktop
<daniels>
I wonder if we can combine some of the esoteric build configurations into a single job which can run longer than the test-blocking jobs
<mupuf>
+1 for that
ximion has joined #freedesktop
thaller has quit [Read error: Connection reset by peer]
thaller has joined #freedesktop
<elibrokeit>
do you run just asan/msan
alanc has quit [Remote host closed the connection]
alanc has joined #freedesktop
Haaninjo has joined #freedesktop
pkira has quit [Ping timeout: 480 seconds]
swatish2 has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
<daniels>
tintou: you’re wanted in #dri-devel :) cc Kayden
vkareh has quit [Quit: WeeChat 4.0.4]
alatiera has quit [Ping timeout: 480 seconds]
An0num0us has quit [Ping timeout: 480 seconds]
columbarius has joined #freedesktop
co1umbarius has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]