thefloweringash has quit [Ping timeout: 250 seconds]
bennofs[m] has quit [Ping timeout: 250 seconds]
philipp[m] has quit [Ping timeout: 240 seconds]
Ericson2314 has quit [Ping timeout: 252 seconds]
vaibhavsagar has quit [Ping timeout: 265 seconds]
rycee has quit [Ping timeout: 252 seconds]
worldofpeace has quit [Ping timeout: 250 seconds]
Moredread[m] has quit [Ping timeout: 250 seconds]
matthewbauer has quit [Ping timeout: 250 seconds]
sphalerit has quit [Ping timeout: 252 seconds]
<ekleog>
globin: right, I've been waiting to have a better view on my schedule before answering
nocent has quit [Ping timeout: 268 seconds]
yegortimoshenko has quit [Ping timeout: 268 seconds]
timokau[m] has quit [Ping timeout: 268 seconds]
<aszlig>
globin: unfortunately no... the last time i was using selinux was ~9 years ago and i'm also a bit time-constrained at the moment :-/
<ekleog>
I think in the following weeks I won't be able to shepherd
roberth has quit [Ping timeout: 264 seconds]
<ekleog>
(plus my only knowledge of selinux is theoretical, I never actually tried to use it)
<ekleog>
I wonder if we shouldn't nominate between e-user and etbe the one who's a selinux dev (or maybe fishilico?), if they're agreeing to it -- they aren't necessarily nixos contributors but would provide valuable insight I think -- or at least invite them to the meeting
drakonis has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-dev
<globin>
sphalerite just tagged 19.03 \o/
<makefu>
partey!
<gchristensen>
niksnut: could Nix exit a different code if a fixed output build failed due to hash mismatch?
<niksnut>
yes
<niksnut>
even better though would be if we had a `nix build --json` that outputted a structured build result
<gchristensen>
that would be darling
<niksnut>
basically the BuildResult data structure
<gchristensen>
I could try my hand at writing a patch to exit a different code if it is approachable -- could you send me in the right direction?
<niksnut>
see Worker::exitStatus in build.cc, where it returns a different exit status for temporary or permanent failures
<gchristensen>
neat, thanks!
<gchristensen>
aszlig: I'm on it!
<aszlig>
gchristensen: no need to hurry :-)
<gchristensen>
good, b/c I have many meetings between now and then :P
<aszlig>
gchristensen: it's just that i regularily build a large subset of nixpkgs master and thus get breaking builds usually before they hit hydra.nixos.org
<gchristensen>
also samueldr relevant stats in there that I think you'll like ^
<gchristensen>
hrm, maybe not. heap went up :o
<samueldr>
are executions of nix deterministic?
<samueldr>
or uh, evals
<gchristensen>
I think so, let's find out
<infinisil>
gchristensen: The non-deterministic stats at least should be done multiple times to get a standard deviation. Such statistics otherwise are more misleading than useful
<samueldr>
because I wouldn't think so considering how the too many heap sections issue seems to not be deterministic in hydra evals
<gchristensen>
hydra's evaluator is fancier
<samueldr>
yeah, but I think it should be deterministic if nix evals are :/
<samueldr>
going from memory, but hydra's evals while fancier are simple, it restarts under some conditions only, and those conditions I assume from memory should be deterministic
<gchristensen>
no, it isn't deterministic
<samueldr>
"it" being "only hydra's evaluator" or "all nix evals"?
<gchristensen>
knowing this, would it be helpful or confusing to have this table on each eval?
<samueldr>
without determinism it might not be as useful :/ though maybe there's a ballpark estimate that can be made from those (with possibly multiple evals)?
<sphalerite>
mumble mumble confidence intervals I can't do statistics
<samueldr>
I won't pretend I know how to, I'll just pretend I understand them :)
<gchristensen>
I certainly don't understand
<sphalerite>
but I do know enough about statistics to know that there are tools that can help us work out how useful the numbers are
<sphalerite>
just not how to do it :D
<infinisil>
Yeah confidence intervals are important
<infinisil>
I do know some statistics
<gchristensen>
great!
<gchristensen>
yeah pretty sure these numbers are not actually very useful :|
<gchristensen>
just kidding, I re-ran the stats export for the same branch instead of switching to another branch I wanted to test with :)
<gchristensen>
okay, so I think the delta-percent is pretty reasonably useful
<gchristensen>
I'm inclined to put it in a Check result.
<gchristensen>
a change of +/- a small percent is not going to raise any eyebrows, but for future big changes? probably a good idea to expose this info
<gchristensen>
a less cute explanation is the check-meta function is pretty complicated, and it defined in an environment which included each package's parameters
<gchristensen>
despite not using any of the package's parameters
<gchristensen>
nix caches thunks, but doesn't automatically lift thunks out of environments when the thunk doesn't depend on the environment (maybe that is really hard? I don't know)
* gchristensen
is on the edge of his specific knowledge