worldofpeace changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | NixOS 20.09 Nightingale ✨ | | | 20.09 RMs: worldofpeace, jonringer |
Graypup_ has quit [Quit: ZNC 1.6.1 -]
Graypup_ has joined #nixos-dev
<red[evilred]> Thanks - I'll scream when I get to my wit's end
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-dev
<aszlig> infinisil: hm, what about making serviceConfig (or *Config for that matter) free-form and allowing ordering on certain or even all values?
<aszlig> infinisil: that way you could do lib.mkBefore "${pkgs.proxychains}/bin/proxychains4 "
<infinisil> aszlig: Problematic because systemd does its own merging and overriding
<aszlig> yeah
<infinisil> E.g. ExecStart = [ "foo" "" "bar" ] is the same as ExecStart = "bar"
<aszlig> especially since... yep, exactly
<gchristensen> samueldr: were you able to sort it with that machine?
<aszlig> but if we would merge down *all* ExecStart to be lists, it should work
<aszlig> okay, never mind, that would make it problematic to override the singleton case
<infinisil> Hmm, but also, lists mean "Execute these all"
<infinisil> So mkBefore [ "proxychains" ] would only run "proxychains" in addition to the other commands
<aszlig> yeah
<samueldr> gchristensen: yes
<samueldr> gchristensen: sorry, I forgot to tell you I was done
<gchristensen> no worries it is all automatic
<samueldr> I wasn't able to figure out _why_, but overnight it verified 43 times that the fix works
<aszlig> okay, alternatively: services.*.execute = ... types.str here ...;
<gchristensen> your cert expired and it was kept out of hydra until it was rebooted
<aszlig> which then boils down to defining the ExecStart in serviceConfig
<infinisil> aszlig: Oh I like that, but probably rather `listOf str`
<aszlig> well, listOf str would be hard to override again
<infinisil> There mkBefore should work
<aszlig> if you want the listOf case you could still use serviceConfig.ExecStart
<infinisil> .execute would be a list of command/arguments
<aszlig> infinisil: but only if you want to add another command to run before the current one, no?
<infinisil> In comparison to .ExecStart which would be multiple command/arguments
<infinisil> aszlig: Yea
<aszlig> this would also be madness if you have another service that defines .execute = mkBefore [ "foo" ];
<infinisil> Hm yeah
<infinisil> I do want to push for deprecating lists for option types in general
<infinisil> Because of stuff like this
<infinisil> Replacing them with a number of better alternatives
<infinisil> Though not sure what it would be in this case
<{^_^}> #97392 (by Infinisil, 16 weeks ago, open): Introduce `types.orderOf`
<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
<infinisil> Hehe
<aszlig> a while ago i did a small aggregate over vuizvui-evals (which is basically evaluating nixos tests):
<aszlig> s/aggregate/plot/
<aszlig> the range is between d3760d44ee12321d5ee249619695a0f469aaffab and a95bf523fcaeba58e93fdf27c3ee7dc5911beb8b
capisce has quit [Remote host closed the connection]
<aszlig> and time is in seconds
<andi-> aszlig: do you have times per commit without me having to do that manually?
<andi-> also were they all on the same (otherwise idle) box?
<aszlig> yes and yes
<andi-> the slope after around 466000 is scary
<samueldr> would it be interesting to see those evaluated by the default `nix` interpreter for *that* revision?
<samueldr> maybe not useful though?
<andi-> maybe, if that shows a difference
<andi-> the theory should be easy to test, no? Just run it on a few expressions across the range and compare the results
<samueldr> something like the edges where a nix version changes, and somewhere around the middle, maybe (to have more than one point)
<andi-> aszlig: is that all tests or just some nixos tests?
<aszlig> ah, yes, but the slop could also be due to the fact that there are other jobsets on that hydra
<aszlig> s/slop/&e/
<andi-> so we should probably re-run this on entirely idle hardware )
<aszlig> so to get more accurate statistics, it's probably better to re-evaluate everything on a non-loaded machine
<aszlig> yeah
<aszlig> and it's just some nixos tests...
<andi-> ok
<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
<infinisil> vw
<infinisil> (ignore that)
* andi- ignores it
<aszlig> > let lib = import ./lib; release = import nixos/release-combined.nix {}; in map (x: lib.getAttrFromPath (lib.filter lib.isString (builtins.split "\\." x)) release) release.tested.constituents
<{^_^}> access to path '/var/lib/nixbot/state/nixpkgs/nixos/release-combined.nix' is forbidden in restricted mode
<aszlig> something like that
<aszlig> but also results in a bunch of eval errors
<aszlig> alternatively you could also use the hydra evaluator
<aszlig> something like: hydra-eval-jobs --dry-run -I nixpkgs=. nixos/release-combined.nix
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-dev
<andi-> I just created a massive shell script using sed and rev-list.. vim is surprisingly slow with just 20k lines in the file..
supersandro2000 has quit [Quit: Ping timeout (120 seconds)]
supersandro2000 has joined #nixos-dev
<aszlig> andi-: yeah, especially if it comes to more complicated macros it's a matter of @x and then waiting (or doing something else) :-D
<andi-> I trimmed it down so it all fits into argv. Locked the screen and will let it run through hyperfine until the afternoon.
tilpner_ has joined #nixos-dev
tilpner has quit [Ping timeout: 256 seconds]
tilpner_ is now known as tilpner
supersandro2000 has quit [Quit: The Lounge -]
supersandro2000 has joined #nixos-dev
rajivr has joined #nixos-dev
justanotheruser has joined #nixos-dev
red[evilred] has quit [Quit: Idle timeout reached: 10800s]
LnL has quit [Quit: exit 1]
LnL has joined #nixos-dev
<supersandro2000> Why is /rebase-staging here not working? Anyone any idea?
<lukegb> supersandro2000: looks like it did, eventually?
<lukegb> yeah, the action run took a few mnutes
<supersandro2000> took like 3 minutes...
<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):
<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 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
<andi-> there is this
<andi-> I guess this is as good as it gets to the truth?
rajivr has quit [Quit: Connection closed for inactivity]
cole-h has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
peelz has joined #nixos-dev
peelz has quit [Remote host closed the connection]
mkaito has quit [Quit: WeeChat 3.0]
mkaito has joined #nixos-dev
supersandro2000 has quit [Quit: The Lounge -]
supersandro2000 has joined #nixos-dev
costrouc has quit [Quit: costrouc]
costrouc has joined #nixos-dev
mkaito has quit [Quit: WeeChat 3.0]
__monty__ has quit [Quit: leaving]
<supersandro2000> I am going to include more nativeBuildInputs verifcation in nixpkgs-review trough nixpkgs-hammering. So far I want to set for:
<supersandro2000> cmake, meson, ninja, pkg-config, autoreconfHook, bison, flex
<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 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