gchristensen changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | 18.09 release managers: vcunat and samueldr | https://logs.nix.samueldr.com/nixos-dev
<infinisil> Alright
<infinisil> samueldr: Where did you find that?
<samueldr> in my 18.09 release announcement
<infinisil> ahh
<infinisil> samueldr: UMmm, where do I got to that from the homepage? https://nixos.org/
<infinisil> The "NixOS 18.09 released" entry doesn't contain any link to what you quoted
<samueldr> hmm, that's on the discourse
drakonis_ has joined #nixos-dev
<samueldr> just as previously mailing list posts weren't linked, the discourse post wasn't
<infinisil> Ohh
<infinisil> It's really hard to find stuff tbh..
<samueldr> (most of the release was templated on the one from before, which was templated from the one before...)
<infinisil> github (nixpgks/nix/rfcs), discord, mailing list, website, manuals (nixpkgs/nix/nixos)
<infinisil> Information all over the place
<samueldr> might be a good idea to link to the announcement
<infinisil> Asked for #49833
<{^_^}> https://github.com/NixOS/nixpkgs/pull/49833 (by 1000101, 4 days ago, closed): [18.03] backport trezord: 2.0.19 -> 2.0.24
drakonis2 has joined #nixos-dev
drakonis1 has quit [Ping timeout: 272 seconds]
drakonis_ has quit [Ping timeout: 264 seconds]
genesis has quit [Remote host closed the connection]
genesis has joined #nixos-dev
init_6 has joined #nixos-dev
orivej has joined #nixos-dev
sir_guy_carleton has joined #nixos-dev
lassulus_ has joined #nixos-dev
lassulus has quit [Ping timeout: 252 seconds]
lassulus_ is now known as lassulus
pie_ has quit [Ping timeout: 272 seconds]
drakonis2 has quit [Ping timeout: 252 seconds]
drakonis2 has joined #nixos-dev
drakonis has quit [Quit: WeeChat 2.3]
drakonis2 is now known as drakonis
sir_guy_carleton has quit [Quit: WeeChat 2.2]
pie_ has joined #nixos-dev
pie_ has quit [Excess Flood]
pie_ has joined #nixos-dev
Taneb has quit [Quit: I seem to have stopped.]
Taneb has joined #nixos-dev
aborsu has joined #nixos-dev
init_6 has quit []
init_6 has joined #nixos-dev
FRidh has joined #nixos-dev
aborsu has quit [Quit: aborsu]
aborsu has joined #nixos-dev
JosW has joined #nixos-dev
JosW has quit [Client Quit]
orivej has quit [Ping timeout: 244 seconds]
orivej has joined #nixos-dev
phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
<gchristensen> ekleog: kind of funny, but yeah
<ekleog> any idea why "x86_64-linux" and not even builtins.currentSystem?
<gchristensen> hmm not sure builtins.currentSystem works in hydra?
<gchristensen> "In pure mode, the Nix evaluator forbids access to anything that could cause different evaluations of the same command line arguments to produce a different result."
<ekleog> oh
<ekleog> so it's basically “well anything really”
<gchristensen> what do you mean?
<ekleog> but at the same time it's used to generate symlinks… so it needs to be the right arch to be able to build the `ln` & co tools, doesn't it?
<gchristensen> Nix will ensure those build jobs are run on a system which supports x86_64-linux
<gchristensen> are you having a problem based on this?
<ekleog> no, I'm just refactoring the region of code around (to make the tests attrset reusable), and wondered what that meant
<gchristensen> cool
<ekleog> thank you :)
<ekleog> (now, the fun stuff: `nix-instantiate --eval --strict nixos/release.nix -A tests` doesn't evaluate :D)
<arianvp> ugh
<arianvp> scripted networking sure is a headache
<arianvp> when are we swithcing to networkd?
<arianvp> found another bug
orivej has quit [Ping timeout: 252 seconds]
drakonis has quit [Ping timeout: 272 seconds]
<gchristensen> depending on how complicated your network is, you can switch now
drakonis has joined #nixos-dev
<gchristensen> (networking.useNetworkd = true)
<arianvp> alright nice
<arianvp> but basically, I just want to use "systemd.network.<blah>" directives
<arianvp> and not deal with the "networking" dsl at all
<arianvp> when using networking.useNetworkd = true is used, I guess all the "networking" stuff is translated to "systemd.network" statements?
<gchristensen> Mic92 has a config somewhere using systemd.network.blah directives
orivej has joined #nixos-dev
init_6 has quit []
orivej has quit [Ping timeout: 272 seconds]
<gchristensen> ekleog: by referencing nixos tests from nixpkgs, is the nixos configuration evaluated for each evaluation of nixpkgs?
<gchristensen> for each test referenced by each package *
<ekleog> gchristensen: it's the point Sonarpulse mentioned, I'm currently working on the test refactor to avoid re-importing nixpkgs every time :)
<ekleog> (then, meta attributes aren't evaluated by default, so there's always this)
<gchristensen> I'm worried more about memory and cpu for nix users
<ekleog> it's not really often that `meta` attributes are all evaluated, is it?
<ekleog> I mean, apart from the case of JSON-exporting
<gchristensen> and when attributes are type-checked or using nix search
* ekleog doesn't know about nix search
<ekleog> isn't it just checking the package name and description?
<gchristensen> might be, not sure
<ekleog> then it'd need benchmarking I guess, no one thought of this issue :°
<ekleog> (well, no one raised it until now, at least)
<gchristensen> it is hard to remember until you're on a t2.micro and can't run `nix-env` because nixpkgs is too big to fit in ram :P
<ekleog> :D
FRidh has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-dev
drakonis1 has joined #nixos-dev
drakonis has quit [Ping timeout: 244 seconds]
drakonis_ has quit [Ping timeout: 252 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 252 seconds]
zarel has joined #nixos-dev
drakonis1 has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 260 seconds]
aszlig has quit [Quit: Kerneling down for reboot NOW.]
aszlig has joined #nixos-dev
drakonis has joined #nixos-dev
orivej has joined #nixos-dev
pie_ has quit [Ping timeout: 244 seconds]
pxc has joined #nixos-dev
pxc has quit [Client Quit]
aborsu has quit [Quit: aborsu]
pie_ has joined #nixos-dev
JosW has joined #nixos-dev
drakonis_ has quit [Ping timeout: 250 seconds]
JosW has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
drakonis_ has joined #nixos-dev
aborsu has joined #nixos-dev
aborsu has quit [Client Quit]
zarel has quit [Quit: Leaving]
orivej has quit [Ping timeout: 252 seconds]
<samueldr> infinisil: in case you want a local noisy failure for issues like in #44076, you can use `env -i NIXPKGS_ALLOW_UNFREE=1 nix-build ...` (where NIXPKGS_ALLOW_UNFREE isn't necessary, but useful in those cases)
<{^_^}> https://github.com/NixOS/nixpkgs/pull/44076 (by hlolli, 15 weeks ago, merged): lumo: init at 1.9.0-alpha
<samueldr> I have a thin wrapper around nix-build, `nix-verify` which does that (also ensures none of your overlay peeks through)
<infinisil> samueldr: I think it would be much more helpful to add this to ofborg
<gchristensen> what is that?
<samueldr> sure, but in that case, it would mean evaluating the arguments, no?
<samueldr> I'm not 100% sure, but wasn't this introduced in a commit after the latest ofborg build?
<infinisil> samueldr: I think the `import <nixpkgs> {}` was there all along
<samueldr> yeah, queued a build to verify
<gchristensen> what did I miss? :)
<samueldr> oh, and I wasn't witch hunting, I was checking another PR from the author and saw the issue :)
<samueldr> s/witch/bug/g
* samueldr is confused
<infinisil> Yeah, ofborg doesn't catch it
<samueldr> wasn'T hydra not building it?
<infinisil> ofborg != hydra though
<samueldr> it used the cache!
<samueldr> >> copying path '/nix/store/3gs08y9ja2vyaabhh94acjzqaz0bzlas-lumo-1.9.0' from 'https://cache.nixos.org'...
<infinisil> Ohhh huh
<infinisil> Ahh, only the tarball build failed apparently
<gchristensen> it is definitely wrong to import <nixpkgs> inside nixpkgs though
<gchristensen> how do we fix that ... :)
<infinisil> gchristensen: Can't you just not set nixpkgs in NIX_PATH?
<gchristensen> mmmmaybe!
<samueldr> or gchristensen, `env -i` every commands?
<gchristensen> it runs a restricted evaluation, so it must have the checkout in the NIX_PATH
<samueldr> ah, it already is from `env_clear` I guess
<gchristensen> but it doesn't need to be set at NIX_PATH=nixpkgs=... maybe
<samueldr> restricted evals can't work from pwd?
<gchristensen> don't think so!
* samueldr loads up the nix manual
<samueldr> confirmed, it won't
<samueldr> though -I . seems workable
<LnL> yes, only things that are part of NIX_PATH are allowed
<gchristensen> has to be absolute, too, iirc ;)
<LnL> yeah, eg. symlinks don't work
<samueldr> env -i nix repl --option restrict-eval true -I oops=. # seems alright
<LnL> it might work for the entries themselves now, but nothing else AFAIK
<gchristensen> samueldr: import <oops> ?
<samueldr> would break, but you'd have to have a crazy clown having import <oops> in their PR ;)
<samueldr> oooh boy
<samueldr> $ env -i nix-build --option restrict-eval true -I " "=. -A hello
<samueldr> (inside a valid checkout)
<gchristensen> (do I want to know?)
<samueldr> using `nix repl` I'm pretty sure < > won't work ever
<samueldr> seems to whitelist the path, while making the path unreachable for use with the angled brackets
<samueldr> (and is probably undocumented behaviour)
<samueldr> (and probably can be bypassed through some API I don't know of yet)
<gchristensen> haha
<samueldr> is there a builtin for `find-file`?
<gchristensen> I think so
<samueldr> findFile isn't in the manual :/
<gchristensen> builtins.findFile
<LnL> not sure if it's a good idea to depend on something weird like this tho
<gchristensen> don't need it anyway
<gchristensen> NIX_PATH=/path/to/checkout
<samueldr> >> Find a file in the Nix search path. Used to implement <x> paths, which are desugared to 'findFile __nixPath "x"'.
<samueldr> hm, hadn't realised (but knew) that -I acted differently in that case
<LnL> gchristensen: then you can import <nixos>, etc. :p
<gchristensen> eh.
<samueldr> or <.>
<samueldr> (assuming pwd I guess)
<LnL> I'd just use a uuid, ofborg could even check if it's in the diff then
<samueldr> hm no, <.> is not pwd, but seems to be the NIX_PATH?
<infinisil> > <.>
<{^_^}> file '.' was not found in the Nix search path (add it using $NIX_PATH or -I), at (string):206:1
<gchristensen> oh, cute idea, lnl
<gchristensen> I can see the error message now: "evaluation failed because the code probably referred to the build directory"
<samueldr> >> { path = "/Users/samuel/tmp/nixpkgs/nixpkgs"; prefix = ""; } # NIX_PATH="/Users/samuel/tmp/nixpkgs/nixpkgs"
<LnL> gchristensen: we could also provide a <nixpkgs> that aborts with a more detailed message
<samueldr> and any <nixpkgs/other/files> would fail since only default.nix would exist I presume
<LnL> hmm yeah, it would only help for a toplevel jmport
<samueldr> well no, it would also help for e.g. <nixpkgs/nixos> by failing (though not with a nice message)
<LnL> sure but not having a nixpkgs entry would also fix that
<samueldr> yeah
<samueldr> (and I confirmed that using
<samueldr> `NIXPKGS=" =..." adds a __nixPath entry with the prefix " ", so it's a hack, but since <> has a stricter definition, one would need to find the entry in __nixPath to import it)
<samueldr> (and I do understand not wanting to use it! just shared the findings)