<worldofpeace>
Jan Tojnar: I'm not sure. The patch I ended up with was what worked perfectly 7 months ago
<jtojnar>
worldofpeace yeah, looking at your patch, commenting that line is equivalent
<jtojnar>
though removing the property altogether is probably safer in case they add another falsification
<jtojnar>
why si linux timing out on aarch64-linux so often?
<cole-h>
Big build on not-big devices, maybe?
<jtojnar>
would that happen?
<samueldr>
we don't have not-big aarch64 devices on Hydra, cole-h
<cole-h>
Oh :)
<samueldr>
my theory, without the ability to check, is ressource exhaustion
<samueldr>
most likely I/O
<samueldr>
I don't remember how the machines are configured, but if the kernel build is sent to a server that runs multiple jobs in parallel, I/O takes a hit
<samueldr>
and looking at /machines, it looks like most aarch64-linux machines do run multiple tasks in parallel
<samueldr>
if my assumption is right, this is something that could be solved via alternative scheduling methods
<samueldr>
I'm assuming a lot, but I'm thinking most "big builds" like webkits, chromes, firefoxes, linux, all end-up in resource exhaustion tarpits
<gchristensen>
we could make 1 arm box big-parallel with few jobs at a time
<samueldr>
if we can try it out, 1 or 2 jobs
<gchristensen>
I can't try it tonight I don't think
<samueldr>
that's alright, whenever :)
<gchristensen>
I mean I could, but it'd still get -j2 or whatever :P
<samueldr>
ah
<gchristensen>
(kind of wish the cores param could be sent over the remote build protocol)
<samueldr>
let's imagine that firefox never builds after 10 hours, that's one failed job, that during those 10 hours stopped up to 14 other jobs from being able to finish in less than 10 hours
<samueldr>
even if firefox takes 2 hours to build (it shouldn't), it's a win, we would win 5 firefox over none
<gchristensen>
+1
<samueldr>
and the queue could end up beint treated more slowly, but with better results (and even then I'm not positive it would be slower)
<gchristensen>
+1
<gchristensen>
yeah I've thought this'd be a good thing to try for a bit, but was persuaded by people worried it'd be wasteful
<samueldr>
I'm sure the tarpit makes trivialer jobs take much longer, too
<gchristensen>
:)
Scriptkiddi has quit [Quit: killed]
ajs124 has quit [Quit: killed]
das_j has quit [Quit: killed]
ajs124 has joined #nixos-dev
Scriptkiddi has joined #nixos-dev
das_j has joined #nixos-dev
teto has quit [Ping timeout: 272 seconds]
LnL has quit [Ping timeout: 256 seconds]
LnL has joined #nixos-dev
LnL has joined #nixos-dev
LnL has quit [Changing host]
justan0theruser is now known as justanotheruser
drakonis has quit [Read error: Connection reset by peer]
<etu>
jtojnar: Does it still fail or did you look into it?
<jtojnar>
etu should be fixed now
<etu>
jtojnar: Ok, just found your commit, thanks :)
<kcalvinalvin>
Are there any tips to debug a package that takes really long to build? I'm currently trying to fix a broken package but the build doesn't error out until 25 minutes in
<kcalvinalvin>
Wondering if there are some tricks to help with this
<lovesegfault>
jtojnar: reproing the build failure for you
<lovesegfault>
one moment
<jtojnar>
Emantor yeah, I do not like it for the reasons stated, I visit the website on every PR review and not having the URL is an extra step
<jtojnar>
kcalvinalvin one possibility is trying to build it in nix-shell, then you can at least reuse the built artefacts, but it will not help with sandboxing issues
<Emantor>
I'm 50/50 on it. But typing github repo URLs comes naturally to me, so thats just me. I often prefer not reaching for the mouse and typing things.
<kcalvinalvin>
jtojnar hmmm ok. Thanks for the suggestion
<jtojnar>
lovesegfault "No package 'gio-unix-2.0' found" is a packaging issue, it needs to depend on glib
cole-h has quit [Quit: Goodbye]
CRTified has quit [Ping timeout: 240 seconds]
LnL has joined #nixos-dev
LnL has joined #nixos-dev
LnL has quit [Changing host]
LnL has quit [Remote host closed the connection]
LnL has joined #nixos-dev
LnL has joined #nixos-dev
LnL has quit [Changing host]
LnL has joined #nixos-dev
LnL has joined #nixos-dev
LnL has quit [Changing host]
CRTified has joined #nixos-dev
FRidh2 has joined #nixos-dev
FRidh has quit [Ping timeout: 265 seconds]
__monty__ has joined #nixos-dev
erictapen has joined #nixos-dev
v0|d has quit [Remote host closed the connection]
v0|d has joined #nixos-dev
rsa_ has quit [Ping timeout: 265 seconds]
rsa_ has joined #nixos-dev
orivej has quit [Ping timeout: 264 seconds]
<gchristensen>
,tell cole-h a simple one wouldbe collapsing the "adding" "removed" "already" log messages in to one line
<{^_^}>
gchristensen: I'll pass that on to cole-h
<gchristensen>
I think I caught the biggest source of ofborg-internal-error labels
<gchristensen>
it used to be that errors adding a commit status were ignored and the job was restarted. this caused a problem where if there was a error in ofborg, it would write a thousand statuses to a single commit in a retry loop. I changed that recently to propogate the error and ... consider it an error, and apply the ofborg-internal-error label in this case. one of the biggest sources of these errors
<gchristensen>
for a bit was GitHub making some fields nullable, and our github API Client considering them required. the next biggest (just fixed) was trying to add a status to a PR after the PR had been force pushed, and the commit not being part of that PR anymore.
teto has joined #nixos-dev
teto has quit [Ping timeout: 260 seconds]
teto has joined #nixos-dev
erictapen has quit [Ping timeout: 256 seconds]
erictapen has joined #nixos-dev
erictapen has quit [Ping timeout: 265 seconds]
erictapen has joined #nixos-dev
rsa has joined #nixos-dev
<globin>
teto: i have a fix for all targetPrefix stuff that I'm testing currently
<globin>
please don't waste time on qt etc
rsa_ has quit [Ping timeout: 265 seconds]
<teto>
globin: anything you would like me to take a look at then ?
<globin>
teto: also I'd prefer if you'd create PRs to the branch as long as I'm actively working on it :)
<globin>
teto: python2 scandir is still a problem I haven't looked at yet
<teto>
globin: sure that's why I asked, then I saw other committing :) feel free to forcepush then
<globin>
sphalerite and Ericson2314 at least were in contact with me before pushing
<gchristensen>
,tell cole-h (I already got it actually)
<{^_^}>
gchristensen: I'll pass that on to cole-h
erictapen has quit [Ping timeout: 265 seconds]
<teto>
btw, when running a --strict --eval, many issues appear in fetchers, it makes harder to see the issues in structured-attrs. Any interest in addressing this ? the issue exists on unstable too
<globin>
teto: i currently just diff the current structured-attrs eval to the current trunk eval and look at removed drvs while searching for x86_64-linux to see the drvs that can't eval
rsa_ has joined #nixos-dev
justanotheruser has quit [Ping timeout: 272 seconds]
<{^_^}>
cole-h: 8 hours, 21 minutes ago <gchristensen> (I already got it actually)
<{^_^}>
garbas's karma got increased to 12
<{^_^}>
cole-h: 11 hours, 32 minutes ago <gchristensen> a simple one wouldbe collapsing the "adding" "removed" "already" log messages in to one line
<cole-h>
lol
v0|d has quit [Ping timeout: 256 seconds]
lovesegfault has quit [Quit: WeeChat 2.7.1]
<gchristensen>
samueldr: let's see :)
<gchristensen>
when I rebuilt my home server, I didn't restore the old way I was building the aarch64 images -- thinking it'd be nice to set it up in a way where the SSH key used for testing the image was short lived. but in this case I should probably just start makig it work :)
* emily
advertises #84522 to anyone interested in hardened NixOS