<aszlig>
ah, similar to the strings-with-deps stuff?
<infinisil>
Yea
<aszlig>
that would indeed be an option to get rid of a few headaches in some lists
<infinisil>
Originally the PR was even more like `orderOf = elemType: attrsOf (submodule { value = mkOption { type = elemType; }; before = ...; after = ...; })
<infinisil>
But that was changed in favor of a more generic `before` function
<infinisil>
Yeah so this orderOf thing would only be useful for some listOf cases. Another alternative for listOf will be like a setOf, where keys are ordered and deduplicated
<infinisil>
Which will be able to replace many listOf's
scott has quit [Quit: Ping timeout (120 seconds)]
scott has joined #nixos-dev
<aszlig>
hmhm... not sure how i like the attrsOf bool
<infinisil>
aszlig: attrsOf bool?
<aszlig>
ah, wait, that was in the test
<infinisil>
the implementation of setOf would probably be about like `coercedTo (listOf str) (genAttrs (n: true)) (attrsOf bool)`
<infinisil>
So that underneath it's an `attrsOf bool`, representing whether an element is part of the set
<infinisil>
But you could also use the shorthand `[ "foo" "bar" ]` to set `{ foo = true; bar = true; }`
<infinisil>
(Ah but yeah I guess you weren't having that in mind)
<aszlig>
ah, i do actually, i mean coercing that list to attrsOf bool would make sense in these cases, since it makes it less verbose to define but still easy to override
v0|d has joined #nixos-dev
* infinisil
nods
<aszlig>
however, i fear that if things like these get more widespread use we'll need to increase the eval timeout on hydra X-D
<andi->
so if it is some regression that is more likely to be in the test runner stuff and not in some test
<aszlig>
those tests are per machine config, so not *all* the nixos tests
<aszlig>
but after removing tests to see what probably contributes the most i've found that the installer tests in particular were pretty slow to evaluate (but i don't have exact timings here, it's been a while)
<andi->
I guess the installer tests suffer from having to eval multiple nixos generations each
<aszlig>
hm, not sure... the test runner didn't have a lot of changes when it comes to the nix expressions
<andi->
ok, is there some nice tooling I could write a hacky script around to run this on an idle machine during the night?
<aszlig>
you could probably evaluate the "tested" job
<andi->
nah, that doesn't do the trick anymore..
<andi->
it is just a bunch of JSON
<aszlig>
yah
<aszlig>
not json probably but a list of jobset names
<supersandro2000>
I wouldn't mind if we could give some feedback earlier...
<lukegb>
yeah, I mean, it could probably reacji on the comment that triggered it or something
<supersandro2000>
but now I know it takes a while so I guess it is fine for now
orivej has joined #nixos-dev
pmy_ has quit [Quit: WeeChat 3.0]
pmy has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
kalbasit has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
kalbasit has joined #nixos-dev
tilpner_ has joined #nixos-dev
tilpner has quit [Ping timeout: 256 seconds]
tilpner_ is now known as tilpner
peelz has quit [Ping timeout: 240 seconds]
bpye4 has joined #nixos-dev
bpye has quit [Ping timeout: 260 seconds]
bpye4 is now known as bpye
cole-h has quit [Ping timeout: 240 seconds]
__monty__ has joined #nixos-dev
cole-h has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
cole-h has quit [Ping timeout: 256 seconds]
jonringer has quit [Ping timeout: 260 seconds]
<Profpatsch>
Do we have fish completions for nix command?
orivej has joined #nixos-dev
justanotheruser has quit [Ping timeout: 264 seconds]
<siraben>
How often is staging merged into master?
<siraben>
I have a merged PR that causes 1000+ hydra rebuilds
<andi->
aszlig: I just did a quick run against every 100th commit in the range for the simple nixos test and at least that doesn't look like it regressed (it is a bit noisy): https://s.rammhold.de/eval.png
<andi->
(left is old commit, right is newest)
<supersandro2000>
siraben: from time to time but it needs to go through staging-next first to stablilize
<hexa->
staging-next is the one that has a hydra job
<siraben>
Ah I see
jonringer has joined #nixos-dev
v0|d has quit [Read error: Connection reset by peer]
lassulus has quit [Ping timeout: 246 seconds]
lassulus has joined #nixos-dev
andi- has quit [Remote host closed the connection]
lassulus has quit [Ping timeout: 264 seconds]
andi- has joined #nixos-dev
lassulus has joined #nixos-dev
lassulus has quit [Quit: WeeChat 2.9]
lassulus has joined #nixos-dev
justanotheruser has joined #nixos-dev
mkaito has joined #nixos-dev
mkaito has joined #nixos-dev
<andi->
Do we have a machine readable source for the currently supported nixos release branches? (currently unstable & 20.09)
<lukegb>
andi-: it's in the status.nixos.org prometheus somewhere
<lukegb>
Dunno where that comes from
<andi->
lukegb: any hint what metric it might be?
<andi->
It would be kinda odd as source of truth
<lukegb>
It's at least on the hydra_job_failed metric
<supersandro2000>
*test for. Anyone has any additions which are 99% clear or any comment one the ones I have listed?
<symphorien[m]>
most setup hooks
<symphorien[m]>
that is, any variable ending in Hook
<supersandro2000>
good catch
<supersandro2000>
I am also planning out how we could use nixpkgs-hammering as a GitHub action to give people quicker feedback about such little mistakes
<supersandro2000>
I don't want to write a comment but the things at the line so I need a machine readable export
<symphorien[m]>
then it would need to have 0% false positive, don't you think ?
<supersandro2000>
yeah or near 99%
<supersandro2000>
right now I am more and more integrating it into my nixpkgs-review
<supersandro2000>
to know which things we deactivate and how to filter some false positives etc
<symphorien[m]>
or a way to override the "red cross" diagnostic
<supersandro2000>
yellow warning?
<symphorien[m]>
I was thinking about "@inputBot disable" or something like that, but demoting to a warning also works
cole-h has quit [Quit: Goodbye]
cole-h has joined #nixos-dev
cole-h has quit [Client Quit]
tom39291 has quit [Ping timeout: 272 seconds]
tom39291 has joined #nixos-dev
<elvishjerricco>
Yay, I did it. Booted NixOS with my custom initrd
<samueldr>
nice!
cole-h has joined #nixos-dev
<samueldr>
was it mainly about systemd, or are there other custom bits?
<elvishjerricco>
samueldr: Mainly about systemd.
<elvishjerricco>
Now I need to get activation occuring in stage 1 via nixos-enter or something, so that stage2/init can just be systemd
<elvishjerricco>
Is that going to be possible?
<samueldr>
good question
<elvishjerricco>
I don't know how much of stage-2.sh is actually necessary
<samueldr>
can you / will you share your work, even if not through a PR outright, to help with the current effort with systemd in stage-1?
<elvishjerricco>
samueldr: I'll post it somewhere. It's a million miles away from being applicable to upstream nixos right now