<infinisil>
Alright sounds good, I'll forward it to that PR
<worldofpeace>
infinisil: yeah, essentially a major version update like that in the stable distribution isn't permissible, we want the smallest change surface for the fix
<infinisil>
+1
<infinisil>
git merge-base is awesome. Super smooth base branch changing with it
lopsided98 has quit [Remote host closed the connection]
lopsided98 has joined #nixos-dev
cole-h has quit [Quit: WeeChat 2.7]
das_j has quit [Remote host closed the connection]
Scriptkiddi has quit [Remote host closed the connection]
ajs124 has quit [Remote host closed the connection]
ajs124 has joined #nixos-dev
Scriptkiddi has joined #nixos-dev
das_j has joined #nixos-dev
cole-h has joined #nixos-dev
Scriptkiddi has quit [Quit: killed]
das_j has quit [Quit: killed]
ajs124 has quit [Quit: killed]
ajs124 has joined #nixos-dev
Scriptkiddi has joined #nixos-dev
das_j has joined #nixos-dev
drakonis1 is now known as drakonis
<disasm>
manveru: can you weigh in on the above discussion about crystal being upgraded to 0.33 in 20.03? I feel less worried about merging breaking changes into a beta if they have little impact to the NixOS ecosystem (which it looks like they do).
Jackneill has joined #nixos-dev
drakonis has quit [Ping timeout: 240 seconds]
Jackneill has quit [Remote host closed the connection]
cole-h has quit [Ping timeout: 240 seconds]
justan0theruser has quit [Ping timeout: 246 seconds]
lovesegfault has quit [Quit: WeeChat 2.7]
betawaffle has quit [Remote host closed the connection]
betawaffle has joined #nixos-dev
bhipple has quit [Remote host closed the connection]
ris has quit [Ping timeout: 268 seconds]
<manveru>
disasm: i think adding the version without making it the default wouldn't hurt
claudiii has joined #nixos-dev
rnhmjoj has joined #nixos-dev
rnhmjoj has quit [Changing host]
rnhmjoj has joined #nixos-dev
rnhmjoj has quit [Changing host]
__monty__ has joined #nixos-dev
johnny101m has quit [Ping timeout: 268 seconds]
tomberek has quit [Ping timeout: 272 seconds]
orivej has quit [Ping timeout: 272 seconds]
Guest17523 has quit [Quit: WeeChat 2.3]
garbas has joined #nixos-dev
zarel_ has joined #nixos-dev
zarel has quit [Read error: Connection reset by peer]
claudiii has quit [Quit: Connection closed for inactivity]
<manveru>
anyone know how to debug a `error: stack overflow (possible infinite recursion)`?
<manveru>
i tried with gdb, but it's just thousands of lines in the backtrace without any function arguments or clue what went recursive...
<gchristensen>
manveru: --show-trace might help? and I don't know why it would be different, but maybe --trace-function-calls would help
<manveru>
that is with `--show-trace` already :)
<manveru>
the other doesn't do anything...
<gchristensen>
maybe it isn't part of your nix version yet :/
<manveru>
i'm on 2.3.2
<gchristensen>
then it should definitely do something :P
<gchristensen>
nix-instantiate --trace-function-calls -E '(import <nixpkgs> {}).hello' gives me major spew
<manveru>
ah, just not with `nix eval`
<gchristensen>
annoying
cole-h has joined #nixos-dev
claudiii has joined #nixos-dev
<andi->
niksnut: Is there a way to verify those new-style consituents are correct without running a hydra locally? Previously it would at least fail if there was a typo somewhere. Now it just accepts everything.
<LnL>
yeah, the strings are a bit unfortunate but evaluating _everyting_ at once doesn't really scale
<andi->
I am not arguing against it just want to verify what I am proposing isn't entirely wrong and only fails hours after it was merged..
<gchristensen>
I agree that it is a problem we'll need to solve
<LnL>
I think having the hydra-eval-jobs functionality in nix would be useful for a number of reasons
<LnL>
reproducing the logic for recursing the same way while allowing errors is pretty hard to do with expressions
<andi->
So it is error tolerant? e.g. jobs that just don't exist (e.g. a type) do not cause the whole thing to abort?
<andi->
s/type/typo/
<LnL>
it continues evaluating attributes even if something throws with asserts or platform checks
<niksnut>
andi-: there is the 'nix eval-hydra-jobs' command (which is what hydra now uses, hydra-eval-jobs is gone)
<LnL>
oh! :D
<niksnut>
however it only checks constituents if you don't pass --dry-run
<arianvp>
domenkozar[m]: I have a reliable reproducer for nix-repl segfaults :)
<disasm>
it essentially just queries the hydra api for eval errors instead of running the eval in a buildkite job.
<disasm>
I'll have to check it out! :)
<disasm>
ah, so I'm assuming that isn't in 20.03 and will be part of 20.09?
psyanticy has quit [Quit: Connection closed for inactivity]
<drakonis>
ah, nice.
ixxie has quit [Ping timeout: 240 seconds]
ixxie has joined #nixos-dev
ixxie has quit [Ping timeout: 260 seconds]
<genesis>
i play a bit with patchelf on an still used tunneling unfree xlinkkai
<genesis>
if i only --set-interpreter ${pkgsi686Linux.glibc}/lib/ld-linux.so.2
<genesis>
it complains about :
<genesis>
$ kaiengine
<genesis>
kaiengine: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
<genesis>
but i still have rabin2 -l /nix/store/4mwfsqlp6ky8h0l23l4a2jgn8wga3zhg-xlinkkai-7.4.34-rev789/bin/kaiengine gives me 7 Linked libraries
<genesis>
if i fixed with --set-rpath ${lib.makeLibraryPath [ pkgsi686Linux.stdenv.cc.cc.lib ]}
<genesis>
$ kaiengine
<genesis>
kaiengine: kaiengine: no version information available (required by kaiengine)
<genesis>
but interesting here is that rabin2 -l gives no linked library.
<gchristensen>
fyi worldofpeace, disasm: I just increased th amount of scheduling shares 20.03 gets to make it a bit zippier. probably should go and review all the shares all the jobsets have. the shares number is deflationary unfortunately
<gchristensen>
("too slow? x10!")
<bennofs>
woo, nix eval-hydra-jobs sounds like something nix-index could use...
<gchristensen>
might should rename it from eval-hydra-jobs to something more generic sounding
<samueldr>
what's the actual output, a json with a list of attr paths?
<andi->
May I ask why we are rushing flakes in instead of just stabilizing the status quo and await the results of the flakes RFC before we take it further? It seems a bit random right now...
<emily>
I personally think that getting rid of non-flakes Nix files is... premature?
<samueldr>
I see there is no CLI mention in the flakes RFC, so I'm not even sure if it's because I'm lacking the flake feature in nix or for other reason
<emily>
samueldr: (that's just for nixosModules but the knot-tying when invoking it is the hard part)
ris has joined #nixos-dev
<worldofpeace>
??? "May I ask why we are rushing flakes in instead of just stabilizing the status quo and await the results of the flakes RFC before we take it further? It seems a bit random right now..." andi- This isn't related to the flakes PR being merged into nixpkgs right?
<gchristensen>
I think it is useful to have working code next to the RFC to make sure things actually work as described
<samueldr>
I like the dogfooding, but maybe we need the instructions on the food packaging?
<niksnut>
samueldr: yeah, I got rid of all CLI aspects in the RFC, it's just about the file format now
<samueldr>
right, though how one would use a flake?
<samueldr>
emily: thanks for the input, I got further in evaluating, though I'm thinking there could be something that's not forward-compatible in nix's flake.nix
<samueldr>
(almost definitely me misusing something)
<samueldr>
right, though no "forward compatibility", if your nix doesn't have flakes%
<samueldr>
?*
<niksnut>
yes
<samueldr>
I'm not sure I'm comfortable about this small issue, with a non-flake-enabled nix, not being able to use or contribute to a flake-using project... especially nix
<niksnut>
that seems impossible to avoid though
<gchristensen>
could a shell.nix bridge the gap for users?
<niksnut>
and it's the same issue as "how to hack on a nix-based project if you don't have nix yet?"
__monty__ has quit [Quit: leaving]
<samueldr>
speaking of shell.nix, is it supposed to work or is it an oversight that it's still in the nix repo?
<samueldr>
(flakes branch)
<niksnut>
oh, good catch
<niksnut>
no it's not supposed to be there
<gchristensen>
maybe it should be there, and working :)
<samueldr>
I'm thinking I'm probably flawed in not importing `flake.nix` from the inputs
<samueldr>
I wonder what other flaws there could be
<samueldr>
though it does evaluate and (currently fetching deps) seems to build nix's flake
<samueldr>
this is the kind of forward compatible shim I'd expect to see in some of the core examples, as they maybe also help in understanding the flow of flakes
<drakonis>
niksnut: "warning: the syntax 'nixpkgs.<attr>' is deprecated; use 'nixpkgs:<attr>'" should be nixpkgs#<attr>
<samueldr>
though, it's hella weird that it fails when you can obviously visit it
<samueldr>
(can _you_?)
<worldofpeace>
yes I can, I also noticed in your competitors script, hydra-eval-failures, spits out a lot of errors like `error: attribute 'i686-linux' in selection path 'containerTarball.i686-linux.meta' not found` for i686-linux failures
<samueldr>
here it seems to want to work, same eval
<samueldr>
gosh, I hate when stuff doesn't fail
<worldofpeace>
I've actually tried to do it with different evals yesterday with the same issue. This is indeed weird, it's for sure there.
<samueldr>
did you try evicting your cache, just in case?
<samueldr>
(rm eval_* build_* in $PWD where you ran the script)