worldofpeace_ changed the topic of #nixos-dev to: #nixos-dev NixOS Development (#nixos for questions) | NixOS 20.03 BETA Announced https://discourse.nixos.org/t/nixos-20-03-beta/5935 | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | https://r13y.com | 19.09 RMs: disasm, sphalerite; 20.03: worldofpeace, disasm | https://logs.nix.samueldr.com/nixos-dev
orivej has quit [Ping timeout: 256 seconds]
lopsided98 has quit [Remote host closed the connection]
lopsided98 has joined #nixos-dev
<aanderse> one of the bots has started quoting urls
<cole-h> r-ryantm has, yeah.
Scriptkiddi has quit [Quit: killed]
ajs124 has quit [Quit: killed]
das_j has quit [Quit: killed]
ajs124 has joined #nixos-dev
Scriptkiddi has joined #nixos-dev
das_j has joined #nixos-dev
Scriptkiddi has quit [Quit: killed]
ajs124 has quit [Quit: killed]
das_j has quit [Quit: killed]
ajs124 has joined #nixos-dev
das_j has joined #nixos-dev
Scriptkiddi has joined #nixos-dev
alex_giusi_tiri has quit [Quit: Leaving.]
abathur has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 246 seconds]
bhipple has quit [Remote host closed the connection]
lovesegfault has quit [Quit: WeeChat 2.7.1]
orivej has joined #nixos-dev
lovesegfault has joined #nixos-dev
<lovesegfault> gchristensen: any chance you could re-enable experimental nix features on the community aarch64 box?
<lovesegfault> in particular to work around this: experimental Nix feature 'ca-references' is disabled
<lovesegfault> as well as being able to `nix run` again
phreedom_ has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
orivej has quit [Ping timeout: 256 seconds]
drakonis has quit [Quit: WeeChat 2.7.1]
abathur has joined #nixos-dev
abathur has quit [Ping timeout: 250 seconds]
cole-h has quit [Ping timeout: 246 seconds]
justanotheruser has quit [Ping timeout: 246 seconds]
FRidh has joined #nixos-dev
lovesegfault has quit [Quit: WeeChat 2.7.1]
justanotheruser has joined #nixos-dev
FRidh2 has joined #nixos-dev
FRidh has quit [Ping timeout: 256 seconds]
FRidh2 has quit [Client Quit]
FRidh2 has joined #nixos-dev
Jackneill has joined #nixos-dev
justanotheruser has quit [Ping timeout: 272 seconds]
lovesegfault has joined #nixos-dev
abathur has joined #nixos-dev
abathur has quit [Ping timeout: 246 seconds]
FRidh2 has quit [Ping timeout: 246 seconds]
FRidh2 has joined #nixos-dev
zarel has quit [Ping timeout: 250 seconds]
__monty__ has joined #nixos-dev
kraem has quit [Ping timeout: 246 seconds]
zarel has joined #nixos-dev
kraem has joined #nixos-dev
edwtjo has joined #nixos-dev
edwtjo has joined #nixos-dev
edwtjo has quit [Changing host]
abathur has joined #nixos-dev
abathur has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-dev
kraem has quit [Ping timeout: 256 seconds]
orivej has quit [Ping timeout: 250 seconds]
kraem has joined #nixos-dev
<tilpner> niksnut: In 64e5f4d53b2740bffb16641f703b9cf0df58b84e, you changed the type of nixosModules.notDetected (flake.nix) from a path to a function. I think this might cause collisions if multiple modules rely on a certain behaviour, and both import a module exported by a flake. Paths can be deduplicated, but not functions, AFAIK
<tilpner> Does flakes-nix do any special precautions that could prevent this collision?
<niksnut> tilpner: hm good point, haven't thought about that
FRidh2 has quit [Ping timeout: 246 seconds]
FRidh has joined #nixos-dev
<tilpner> I think modules should be paths whenever possible
<niksnut> I'm not sure we should even keep nixosModules.notDetected, since you can also do imports = [ (nixpkgs + "/nixos/modules/installer/scan/not-detected.nix") ];
<tilpner> There can already be hard-to-workaround collisions with nixpkgs, when generated modules are imported directly
<tilpner> E.g. with imports = [ (mkRemovedOptionModule ...) ];
<timokau[m]> Does anybody here know how ofBorg currently handles timeouts? I'm seeing failures that look like the build was killed due to timeout, but it registers as "Failed" not "Timed out"
<timokau[m]> The aarch64 and linux builds here in particular: https://github.com/NixOS/nixpkgs/pull/82766/checks?check_run_id=513330292
<tilpner> Careful, updating unstable just restarted my X session
<LnL> tilpner: it's a nix feature, check --option timeout in man nix.conf
<LnL> timokau[m]: ^
abathur has joined #nixos-dev
abathur has quit [Ping timeout: 264 seconds]
<Mic92> Nix update is now also in NUR: https://github.com/Mic92/nix-update/
phreedom has quit [Ping timeout: 240 seconds]
<timokau[m]> LnL: Yes, but normally ofBorg would report that as a timeout no? At least I think it did that in the past.
phreedom has joined #nixos-dev
<LnL> timokau[m]: "builder failed with exit code 1", what makes you think it's a timeout?
<timokau[m]> LnL: First indication is that the two builds failed on totally unrelated tests. Then if you look at the tests that failed (search for "Failed example") they look like they received some kill-signal mid-test. The linux one is:
<timokau[m]> TypeError: unable to make sense of Maxima expression '(kill(sage4)$o44)[[1.0,-2.0],[1.05,-2.149874965475482],[1.1,-2.298999939830521],[....
<timokau[m]> Aarch64: Doctesting 2 files using 1000000 threads.\n Killing test 99seconds.rst\n Killing test interrupt_diehard.rst
<LnL> looks more like the testuite
<timokau[m]> LnL: The testsuite does have a built-in timeout mechanism, but it should be disabled and it usually reports a timeout when it kicks in. Seems weird.
<LnL> nix outputs something like this: building of '/nix/store/r9gfiysi3bsfmj4v78msg5nc4ka0vphb-hello-2.10.drv' timed out after 1 seconds
FRidh has quit [Ping timeout: 250 seconds]
FRidh2 has joined #nixos-dev
<timokau[m]> LnL: Mh okay. Probably best to ignore it for now (given the tests pass locally, which I'm still checking) and see if it comes up again in the future with sage or other ofBorg builds.
arianvp_ is now known as arianvp
justanotheruser has joined #nixos-dev
orivej has joined #nixos-dev
<gchristensen> niksnut: I'd like to set a FORCE=1 with systemd, and re-run all the channel updaters, and then remove the FORCE setting, to make the git-revision data come back sooner. sound ok?
phreedom has quit [Ping timeout: 240 seconds]
<niksnut> gchristensen: sure
abathur has joined #nixos-dev
abathur has quit [Ping timeout: 250 seconds]
phreedom has joined #nixos-dev
<gchristensen> https://status.nixos.org/ is working again :)
<gchristensen> niksnut: thanks!
abathur has joined #nixos-dev
<garbas> niksnut++
<{^_^}> niksnut's karma got increased to 16
justanotheruser has quit [Ping timeout: 256 seconds]
drakonis has joined #nixos-dev
justanotheruser has joined #nixos-dev
cole-h has joined #nixos-dev
Dandellion has quit [Ping timeout: 245 seconds]
Dandellion has joined #nixos-dev
<Ericson2314> niksnut: the other thing to decide I forgot to mention is how to generealize hashDerivationModulo for multiple content-adddressed outputs
<Ericson2314> the current algorithm of replacing the drv input with `fixed:out....` only works when there is 1 output
<niksnut> right
<Ericson2314> niksnut: I am leaning towards making a fake derivation for every output, but I am not quite sure on the ramifications of that
<gchristensen> imo it would be nicer to have the idea of multi-output derivations known all the way down
<Ericson2314> gchristensen: Yes, but also for CA I just care about what my input are, not who made them
<Ericson2314> that would give us maximum sharing
<Ericson2314> there is input drvs and input sources, ideally they would be input sources so there wouldn't be any fake derivation whatsoever
<Ericson2314> but I wouldn't want to change the store path of existing derivations, nor leak whether a fixed ouput was built by a fixed output derivation or ca derivation
<Ericson2314> ....hmm but we already leak add-to-store store path vs fixed ouput derivation, right niksnut ?
Jackneill has quit [Remote host closed the connection]
<Ericson2314> (not in the store path itself, but in the store paths of downstream derivations via hashDerivationModulo)
<samueldr> something's weird here, no aarch64 channel listed https://channels.nixos.org/
* samueldr is confused
<samueldr> I thought we had an -aarch64 channel for stable releases already, but it looks like we didn't https://github.com/NixOS/nixos-org-configurations/commit/e7e22664ad88fde70647bc3ab2ebb31a1c81420a#diff-936856bc7e63058d6dfd2a00d80b87bf
<samueldr> (though we do have a separate jobset)
<lovesegfault> gchristensen: ping; did you see my late-night message about the aarch64 box
<gchristensen> no
<gchristensen> I don't do any administration on that thing, it builds from github.com/nix-community/aarch64-build-box and deploys every Monday
* lovesegfault goes investigate
<gchristensen> if Nix is broken, probably should get master fixed and update the version of nix in Nixpkgs
<lovesegfault> gchristensen: I don't think Nix is broken; I think it's just some Nix version diff. between 19.09 and 20.03
<lovesegfault> the effect ends up that building a 20.03 or unstable machine (nixos.system) in a 19.09 box no longer works
<lovesegfault> not sure whether that's working as intended, or a bug
<lovesegfault> and if it's bug where should it be reported
<gchristensen> Nix
* lovesegfault reports
<samueldr> it's basically the `nix` command being gated behind a flag, no?
<lovesegfault> samueldr: that's _part_ of it, there's another more annoying issue; let me dig it
<lovesegfault> samueldr: `experimental Nix feature 'ca-references' is disabled`
<gchristensen> also to clarify I'm open to PRs fixing it :)
<lovesegfault> gchristensen: I fully intend on sending one, I just need to first understand the issue :P
<gchristensen> woot :)
<lovesegfault> does anyone know where does /run/current-system/nix come from?
ris has quit [*.net *.split]
ris has joined #nixos-dev
<gchristensen> lovesegfault: I don't have /run/current-system/nix
<lovesegfault> gchristensen: it was me being silly; I had an overlay that referenced my `nix/` in my cfg repo; that then got copied over to /run/current-system/overlays, which in turn tried to point at /run/current-system/nix
<lovesegfault> and then it kaboom'd
<gchristensen> oh I see
<lovesegfault> (it import ../nix'd)
<gchristensen> =)
<lovesegfault> (of the ca-references issue)
<lovesegfault> now I need to learn how to enable nix features
<gchristensen> imo, no, this should continue working out of the box -- not be an exper9imental feature
<gchristensen> since I don't think it *is* an experimental feature
<lovesegfault> Well, I'll file an issue then :)
<gchristensen> I'm thinking it got experimental-ized by mistake
<clever> gchristensen: ca-references broke my ability to use the aarch64 box a few days ago
<gchristensen> yeah, that is what lovesegfault is looking at
<lovesegfault> clever: yep, mine too
<clever> also, the `nix` binary fails due to "experimental features" on a recent build from master
<lovesegfault> yes, that as well has been annoying the bejeezus out of me
<lovesegfault> I'm filing the issue rn
<lovesegfault> Also, is nixos-unstable back to normal? unstable-small is a bit wild for me
<lovesegfault> there's a release like every hour
<lovesegfault> gchristensen, clever: https://github.com/NixOS/nix/issues/3422
<{^_^}> nix#3422 (by lovesegfault, 48 seconds ago, open): ca-references should not be experimental
FRidh2 has quit [Quit: Konversation terminated!]
<niksnut> std::variant considered harmful
<Profpatsch> niksnut: having fun? :)
<niksnut> or rather, implicit coercions considered harmful
<niksnut> I have a std::variant<std::string, bool>
<niksnut> and if I assign a string literal to it, C++ will helpfully convert it to a bool rather than a string
<MichaelRaskin> Let me guess: even empty string literal is true, because it is a non-zero pointer?
<niksnut> yes
<niksnut> at least I assume so, I didn't check
<Profpatsch> Is this implemented as a C union?
<MichaelRaskin> Because of course it is char* and thus an integer-ish type which is closer to boolean than to std::string.
<Profpatsch> Because if you really want to tag you need an indirection afaik
<niksnut> it's a type-"safe" union
<niksnut> like a rust enum only less usable
<niksnut> because the variants don't have names (only indices) and there is no pattern matching
bhipple has joined #nixos-dev
<Ericson2314> niksnut: sorry to bug again, but is indeed correct that hash modulo drv will do something different a derivation that depends on a fixed ouput derivation vs a derivation that depends on a store path directly?
<Ericson2314> *hashDerivationModulo
ashkitten has quit [Quit: WeeChat 2.7.1]
ashkitten has joined #nixos-dev
ashkitte1 has joined #nixos-dev
ashkitten has quit [Ping timeout: 246 seconds]
justanotheruser has quit [Ping timeout: 246 seconds]
justanotheruser has joined #nixos-dev
__monty__ has quit [Quit: leaving]
ryantm has quit [Remote host closed the connection]