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
drakonis has joined #nixos-dev
Synthetica has quit [Quit: Connection closed for inactivity]
<infinisil> Can version updates still go in 20.03?
<infinisil> Probably not right/
<infinisil> By default at least
<infinisil> E.g. with crystal 0.33 I wouldn't have to add a patch, but this means updating from 0.32.1 to 0.33 on the 20.03 branch: https://github.com/NixOS/nixpkgs/pull/80389#issuecomment-587212361
<infinisil> I guess in this case it's probably not a problem because there's only a couple derivations that use crystal for building
<infinisil> worldofpeace: Got an opinion? ^
drakonis has quit [Ping timeout: 240 seconds]
<worldofpeace> infinisil: Ideally version updates that are minor, how does crystal's versioning work?
<infinisil> Looks like there are breaking changes: https://github.com/crystal-lang/crystal/releases
<worldofpeace> So I'd say we shouldn't
<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
<{^_^}> firing: BuildsStuckOverTwoDays: https://status.nixos.org/prometheus/alerts
<{^_^}> resolved: BuildsStuckOverTwoDays: https://status.nixos.org/prometheus/alerts
drakonis1 has joined #nixos-dev
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]
psyanticy has joined #nixos-dev
johnny101m2 has joined #nixos-dev
zarel_ has quit [Ping timeout: 265 seconds]
zarel has joined #nixos-dev
orivej has joined #nixos-dev
Mic92 has quit [Quit: WeeChat 2.7]
Mic92 has joined #nixos-dev
justanotheruser has joined #nixos-dev
drakonis has joined #nixos-dev
tomberek has joined #nixos-dev
evanjs has quit [Quit: ZNC 1.7.5 - https://znc.in]
evanjs has joined #nixos-dev
drakonis has quit [Ping timeout: 246 seconds]
<andi-> Eval of 19.09 is failing with an EOF error. Is that still related to the eval issue we had a few days ago?
<gchristensen> interesting, will look andi-
<niksnut> this almost certainly means OOM
<niksnut> probably 19.09 needs a backport of the 'tested' job changes
<andi-> we didn't have any massive additions (or any?) to that jobset, why does it suddenly run OOM? Also the previous attempt showed the same errors.
<niksnut> hydra used to set GC_INITIAL_HEAP_SIZE to get around OOM issues
<gchristensen> I think the memory allocation of the evaluators changed fairly significantly in favor of the new model which works for 20.03
* gchristensen will let it come right from the horse's mouth
<andi-> ok, that makes sense then
<niksnut> Feb 18 16:09:41 ceres kernel: Out of memory: Kill process 20358 (nix) score 425 or sacrifice child
<niksnut> Feb 18 16:09:41 ceres kernel: Killed process 20358 (nix) total-vm:28172236kB, anon-rss:27980736kB, file-rss:0kB, shmem-rss:0kB
<niksnut> actually it's more likely because of the new parallelism
<niksnut> so in addition to one nix process evaluating the 'tested' job (taking 27 GB), you have 7 others taking 4 GB
<niksnut> GC_INITIAL_HEAP_SIZE probably doesn't matter anymore now that boehm gc is compiled with --enable-large-config
<garbas> does somebody know if the release process of nix is documented somewhere? especially all the manual parts of the release process. something similar as it is done for nixos https://nixos-homepage.netlify.com/nixos/manual/index.html#release-process
<niksnut> yes
<garbas> also hello everyone after some hibernation on my end :)
<gchristensen> garbas! :)
<niksnut> at least I thought so...
<garbas> niksnut: i'm mostly looking how things end up in nixos.org/releases/ folder
<garbas> niksnut: :) no worries, if we dont have it you can tell me and i'll add it to the nix/manual
<niksnut> I think there used to be a text file somewhere, but now the code is the documentation, see maintainers/upload-release.pl in the nix repo
<niksnut> that script only works on my laptop though :-)
<garbas> :) hehe i can go through it and decrypt it thx
<niksnut> so basically I wait for an eval in https://hydra.nixos.org/jobset/nix/maintenance-2.3 to finish, then I run upload-release.pl <eval-id>
<garbas> i was thinking if we should upload also the nix release artifacts to releases.nixos.org S3 bucket
<garbas> niksnut: ^
<niksnut> s/also//
<niksnut> just move it all to S3
<niksnut> the only downside is the lack of browseability
<garbas> i find this completly fine :) http://releases.nixos.org/
<garbas> niksnut: maybe a if we add a little of html+js that would be enough -> https://github.com/rufuspollock/s3-bucket-listing
<niksnut> +1
<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 :)
<arianvp> (one you reported quite a while ago)
ixxie has joined #nixos-dev
drakonis has joined #nixos-dev
evanjs has quit [Quit: ZNC 1.7.5 - https://znc.in]
evanjs has joined #nixos-dev
andi- has quit [Ping timeout: 260 seconds]
andi- has joined #nixos-dev
evanjs has quit [Quit: ZNC 1.7.5 - https://znc.in]
andi- has quit [Read error: Connection reset by peer]
andi- has joined #nixos-dev
evanjs has joined #nixos-dev
tomberek has quit [Remote host closed the connection]
andi- has quit [Ping timeout: 246 seconds]
andi- has joined #nixos-dev
<gchristensen> andi-, lnl: we'll need to switch ofborg to use that and catch them at PR time
<LnL> good point, but now that it's part of nix instead that shouldn't bee too hard
<gchristensen> yeah
<gchristensen> and if switching to nix eval-hydra-jobs will make it faster, heck yes :)
<disasm> I wrote https://github.com/input-output-hk/iohk-nix/blob/master/ci/hydra-eval-errors/bin/hydra-eval-errors.py to work around the platform issues with running hydra-eval-jobs... Looks like I should have tried nix eval-hydra-jobs first.
<gchristensen> it is brand new as of ~yesterday
<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?
* samueldr could check
<niksnut> samueldr: like this: https://pastebin.com/pBMCDiM6
<samueldr> thanks (was building nix to check)
<gchristensen> it reminds me of nix-env's json output
<worldofpeace> gchristensen: thanks ❤️
<samueldr> eval-for-builder ?
<gchristensen> samueldr: evaluate-buildables maybe? dunno hehehe, this is the hardpart isn't it
<samueldr> yes
<samueldr> :/ shell.nix in the flakes branch of nix is missing a file, and release.nix has vanished
<samueldr> (and that command is part of the flakes branch)
* samueldr searches for info about building with flakes
drakonis has quit [Ping timeout: 272 seconds]
<emily> samueldr: if you just want to hack around it, then perhaps see https://github.com/edolstra/dwarffs/issues/8
<{^_^}> edolstra/dwarffs#8 (by thoughtpolice, 10 weeks ago, open): Please re-add module.nix
<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)
drakonis has joined #nixos-dev
<niksnut> samueldr: there are some examples in https://nixos.org/~eelco/talks/nixcon-oct-2019.pdf
<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> starting from emily's module thing, I tried this: https://gist.github.com/0aca915cab477639e322c50ca1b8eed7
<samueldr> I'm facing an issue where nixpkgs should both be a string and a set
<gchristensen> { outPath = ... }
<gchristensen> iirc
<samueldr> error: cannot coerce a set to a string or error: value is a path while a set was expected
<samueldr> I'm using -A defaultPackage
<niksnut> looks like it got accidentally revived in a merge commit
<samueldr> oh, gchristensen, I think I see *tries*
<emily> it would be nice if there was just a non-flakes thing upstream so people didn't have to do these hacks ._.
<samueldr> hm, not sure, it seems to both want to use `import nixpkgs` and `nixpkgs.lib` on the same value
<niksnut> if you mean nix eval-hydra-jobs, it's on the flakes branch because that's what hydra.nixos.org is running
claudiii has quit [Quit: Connection closed for inactivity]
<niksnut> samueldr: you could use builtins.fromJSON (builtins.readFile ./flake.lock) to get the nixpkgs revision to use
<samueldr> oh, makes sense!
<drakonis> flake fetchers need a bit of documentation right now, i had to drop into the source code to find out how to use a local github for flakes
<drakonis> a local git repo
drakonis has quit [Quit: WeeChat 2.7]
<gchristensen> yorick, flokli: looking at this new buildkite-agents stuff... :)
drakonis has joined #nixos-dev
orivej has quit [Ping timeout: 265 seconds]
<gchristensen> looking nice, I have great big hacks to have 10 builders on a system
<samueldr> this is the current state
<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>
<gchristensen> yorick: can you take a look at this when you're around? https://github.com/NixOS/nixpkgs/pull/78373#issuecomment-587948762
<niksnut> drakonis: thanks, fixed
<niksnut> samueldr: probably you don't want to use builtins.currentTime...
<niksnut> better to feed some fake constant value
<samueldr> I almost put that solely to make you cringe, my initial was "0"
<niksnut> :-)
<samueldr> AFAICT this would mean the derivation always gets rebuilt here since it's using lastModified as an input, right?
<emily> can we not have #s in command line syntax? :(
<emily> it might not parse as a comment but it's certainly confusing (and it'll definitely mess up poor syntax highlighters)
<yorick> gchristensen: hmm. do you have config?
<yorick> hooks.environment works here
<yorick> thanks, I'll check tomorrow
<gchristensen> thank you, yorick!
johnny101m has joined #nixos-dev
johnny101m2 has quit [Ping timeout: 240 seconds]
<samueldr> :|
<samueldr> tar: .git/logs/refs/remotes/origin/mojave-/homeless-shelter: Cannot stat: No such file or directory
<samueldr> ls -l .git/logs/refs/remotes/origin/mojave-\$HOME
<samueldr> worldofpeace: I pushed a quick fix to the script, I think it is failing to download
<samueldr> the "fix" is to explain it failed to download, with curl's exit status
<samueldr> I should probably instead invest in actually downloading in the script to get better knowledge about fetch failures
<worldofpeace> samueldr: that would definitely be an improvement, it seems to fail on i686-linux stuff https://hydra.nixos.org/build/113082252
<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)