<disasm>
niksnut: would you be in favor of changing the hydra eval errors to be attached to the eval instead of job?
<clever>
disasm: i do also see value in creating an eval with 0 builds, if the eval hard-failed, it can be tricky to tell if the error blocked everything, or only some, and what rev last failed when it blocked everything
<samueldr>
+1
<clever>
there is also another change ive been thinking about lately...
<samueldr>
no eval output should be lost ever
<samueldr>
listing slowly changing projects could be an issue, but do as with project/jobset listing page, and allow filtering
<samueldr>
default to only showing evals with changes
<gchristensen>
disasm: my concern is the log is quite large
<samueldr>
gchristensen: what's the mechanism that allows keeping build logs? can it be co-opted?
<clever>
basically, i want hydra to measure how long this part of the code took to run, and include that in the job (the json just below)
<gchristensen>
samueldr: I'm, hrm, not sure
<clever>
then the hydra UI can report how long it took for the eval to produce that one expr
<clever>
that would be 1 more field in the json that hydra-eval-jobs returns, which the perl code must then copy into the db (and one more column in the db)
<clever>
then the starman server can report it in the UI
<samueldr>
I mean, it's fine if we shed some off at some point, if the weight of them all is too much, but keep some history around for figuring out issues
<samueldr>
and especially, which first eval broke
<gchristensen>
true, samueldr
<clever>
my general thinking, is that i want to see how expensive each attr is to eval, within the whole `release.nix`
<gchristensen>
wow
<clever>
and then i have somewhere to focus, when trying to optimize the eval
<samueldr>
it sure would be interesting
<clever>
and now i should get to bed!
<samueldr>
:|
<clever>
17 hour uptime!
<samueldr>
:) don't dreak too much about hydra
<aminechikhaoui>
samueldr I guess we could end up with many files (if you follow the build logs approach) or db records if a jobset is evaluated every X minutes and failing consistently
<aminechikhaoui>
build-logs are now a redirect for the nix build log to a file that has the derivation path without /nix/store pretty much, so you have a log file per derivation
<aminechikhaoui>
if you restart the derivation build it gets overwritten
<samueldr>
content-addressed logs
<aminechikhaoui>
bingo !
<samueldr>
no new eval if it's the same inputs
<aminechikhaoui>
not a bad idea :)
<samueldr>
maybe an additional "log" of non-evals?
<samueldr>
but there's no real need?
justanotheruser has quit [Ping timeout: 272 seconds]
<aminechikhaoui>
but I guess it's the same thing after all
<aminechikhaoui>
but inputs aren't always the jobset inputs
<aminechikhaoui>
once it resolves the inputs revisions, etc .. it keeps a record of the eval and whether it failed or not
<aminechikhaoui>
that would be useful
<samueldr>
right now there is no way to know when it started failing
<samueldr>
except guesstimating from the last good eval
<aminechikhaoui>
maybe we can have eval ids generated for each evaluation whether it fails or not, with a link to the log file if it failed
<samueldr>
[20:24:14] <clever> disasm: i do also see value in creating an eval with 0 builds, if the eval hard-failed, it can be tricky to tell if the error blocked everything, or only some, and what rev last failed when it blocked everything
<samueldr>
I think there's an agreement there :)
justanotheruser has joined #nixos-dev
ryantm has joined #nixos-dev
Guest30 has joined #nixos-dev
bhipple has quit [Ping timeout: 256 seconds]
Guest30 has quit [Remote host closed the connection]
Guest30 has joined #nixos-dev
orivej has quit [Ping timeout: 246 seconds]
Guest30 has quit [Ping timeout: 250 seconds]
cole-h has quit [Quit: WeeChat 2.7.1]
cole-h has joined #nixos-dev
justanotheruser has quit [Ping timeout: 250 seconds]
<garbas>
domenkozar[m]: on the announcement post the link to gihub account of bburdette is broken
<roberth>
added an issue about preserving the structure of the errors. Imagine having those improved error messages in your editor as you type :)
FRidh has joined #nixos-dev
<pie_[bnc]>
i didnt read the proposal but it looks very good, to bikeshed a bit, roberth: why non have some sort of channel for more properly typed errors instead of stringly typed ones
CRTified has joined #nixos-dev
alphawaffle has quit [Quit: Oh noes, my ZNC!]
betawaffle has joined #nixos-dev
<aminechikhaoui>
niksnut in https://github.com/NixOS/hydra/pull/668 you say plugins can be written in any language but not through hydra-notify script right ?
<{^_^}>
hydra#668 (by edolstra, 31 weeks ago, merged): Turn hydra-notify into a daemon
<aminechikhaoui>
it will need something else to listen and start plugins I guess
<niksnut>
yes
<niksnut>
hydra-notify is basically a compatibility wrapper for existing perl plugins
<niksnut>
but you can have other processes that listen to postgres notifications
<aminechikhaoui>
cool and using their own config etc .. as you don't necessarily need to parse the hydra.conf anymore
<domenkozar[m]>
garbas: thanks
<domenkozar[m]>
roberth: thanks!
<garbas>
domenkozar[m]: looking at the way you organized this it doesn't look much different the a rfc proposal. right now you asked for a discussion to happen
<garbas>
so the "proposal" is in discussion phase
<domenkozar[m]>
I don't think discussion equals an RFC
<garbas>
well, discussion is part of the rfc
<domenkozar[m]>
RFC is a specific process that also contains discussion, not the other way around
<domenkozar[m]>
then we could argue every PR could be an RFC
<garbas>
was there an overview of the proposed implementation from the nix core team? you are adding C code into the code base if i'm reading correctly
FRidh2 has joined #nixos-dev
FRidh has quit [Ping timeout: 264 seconds]
<garbas>
please understand me. i'd love this to happen. regardless if the process follows rfc or something else
<garbas>
but it doesn't fill me with confidence that this will be merged upstream.
<garbas>
i'm sure others might have similiar questions as i
<garbas>
maybe you want to clarify them in the announcement or in the proposal
<domenkozar[m]>
that's why we have PRs to discuss the code once it's written
<garbas>
but you are asking to donate before that. i just want to raise this to you attention if you didn't think of it already.
<garbas>
i'd love to donate, but only if this get into nix. otherwise i'd rather donate to other causes. i assume everybody has a donation budget which has a limit.
<garbas>
anyway. i think you understand what i'm trying to say. it is a chicked-egg problem. i think rfc might make this better. but at the end it is your call since you're organising it.
<domenkozar[m]>
not sure what you're implying
<domenkozar[m]>
that work wouldn't be merged because it's not an RFC?
* garbas
is maybe to as clear as he thinks :)
<garbas>
s/to/not/
<garbas>
there is always a chance that work doesn't get merged, right?
<domenkozar[m]>
do you think better error messages would be controversial enough not to be merged?
<garbas>
having a discussion with nix core team (via rfc) might make this more likely to happen.
<domenkozar[m]>
I can hardly see that happening, the implementation is always subject to change, and Eelco said "good stuff" so I'm sure we can come to solutions that would work
<domenkozar[m]>
there is no more nix core team :)
<garbas>
yes, if the implementation is not good. or doesn't follow the ideas in nix codebase.
<domenkozar[m]>
at least that I know of
<domenkozar[m]>
I think I'm around long enough to know how to make this happen :)
<garbas>
if Eelco said "good stuff" you should include this already in your pitch :)
<garbas>
well, then please go ahead. just tried to help.
<domenkozar[m]>
we got this, thanks
<domenkozar[m]>
I'm confident that a lot of developers and companies see the benefit in the goal and trust us to do the work, once the foundation and first results come out, others will be convinced too :)
<infinisil>
I think RFC are only useful when there's either something controversial about the chance, or if it's a big change
<danderson>
hmm, clearly my twitter shitposting about nixos needs to be in a blog, so I become famous
<yorick>
gchristensen: does the packet arm builder build any of the 32-bit arms? :P
phreedom has joined #nixos-dev
<gchristensen>
not sure how to answer that question :P, why do you ask?
<domenkozar[m]>
yorick: thanks!
<domenkozar[m]>
gchristensen: all good?
<drakonis>
danderson: clearly.
cole-h has joined #nixos-dev
<gchristensen>
cool
<yorick>
gchristensen: so our current arm32 build farm is 3 raspberry pi's ducktaped to underneath a desk :P
<gchristensen>
lol
<gchristensen>
the armv7l builder is a 32bit armv7l cross-compiled VM running on a Packet c2.large.arm
<drakonis>
its a step towards improvement
<LnL>
I just discovered boot.binfmt.emulatedSystems
<yorick>
yeah, there's a nixos module for qemuing that
<yorick>
I'm not sure if I can find it anywhere
<samueldr>
yorick: now all part of nixos
<samueldr>
at one point in the past there were issues stopping compilation in the qemu-user implementation
<LnL>
don't know if it has weird edgecases but it seems much better than trying to build anything significant on a rpi
<samueldr>
it has
<samueldr>
especially if you try armv6
<samueldr>
(IIRC)
<LnL>
anything specific you remember?
<yorick>
interact1ive
<yorick>
LnL: we build linux kernels overnight :D
{`-`} has joined #nixos-dev
<samueldr>
LnL: armv6l acted like armv6l on armv7l, bad detection in build systems that accidentally built armv7l stuff for armv6l
<samueldr>
otherwise, some random... I don't remember the name of the kind of exception, but segfaulty things due to bad implementation of the glue between the kernel and userland process
<samueldr>
not random
<samueldr>
but not constantly for all builds, only some things happened to trip it up
<LnL>
right, I can imagine v6 being even more tricky
<LnL>
gchristensen: where's the armv7 builder btw, I've not seen any builds for a while