sphalerite changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | NixOS 19.09 now in beta! https://discourse.nixos.org/t/nixos-19-09-feature-freeze/3707 | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | https://r13y.com | 19.09 RMs: disasm, sphalerite | https://logs.nix.samueldr.com/nixos-dev
ris has quit [Ping timeout: 268 seconds]
orivej has quit [Ping timeout: 276 seconds]
drakonis has quit [Ping timeout: 245 seconds]
tilpner_ has joined #nixos-dev
tilpner has quit [Ping timeout: 265 seconds]
jonringer has joined #nixos-dev
<ryantm> jtojnar: Okay, I stopped the run until we get that change worked out.
<ryantm> worldofpeace: jtojnar: okay, I did and started it https://github.com/ryantm/nixpkgs-update/commit/f7defb53995186e56dd69cc7629b61b23687c330
<samueldr> ryantm++
<{^_^}> ryantm's karma got increased to 7
<worldofpeace> ryantm: Thanks so much ✨
<worldofpeace> ryantm++
<{^_^}> ryantm's karma got increased to 8
cdepillabout has joined #nixos-dev
rajivr___ has joined #nixos-dev
cdepillabout has quit [Ping timeout: 245 seconds]
cdepillabout has joined #nixos-dev
cdepillabout has quit [Ping timeout: 245 seconds]
orivej has joined #nixos-dev
cdepillabout has joined #nixos-dev
janneke_ is now known as janneke
aristid has quit [Ping timeout: 250 seconds]
phreedom has quit [Quit: No Ping reply in 180 seconds.]
phreedom has joined #nixos-dev
johanot has joined #nixos-dev
Jackneill has joined #nixos-dev
cdepillabout has quit [Ping timeout: 245 seconds]
jonringer has quit [Remote host closed the connection]
johanot has quit [Ping timeout: 245 seconds]
johanot has joined #nixos-dev
cdepillabout has joined #nixos-dev
<Taneb> It looks like a lot of builds were aborted (manually?) on https://hydra.nixos.org/eval/1545005
<Taneb> There was another eval an hour later, so I guess something was wrong with this one that was thought to be fixed?
<Taneb> But in that case the aborted builds in https://hydra.nixos.org/eval/1545017 (the subsequent eval) ought to be restarted, I feel
cdepillabout has quit [Quit: Leaving]
johanot has quit [Ping timeout: 265 seconds]
psyanticy has joined #nixos-dev
phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
__monty__ has joined #nixos-dev
johanot has joined #nixos-dev
tilpner_ is now known as tilpner
johanot has quit [Quit: WeeChat 2.4]
tilpner has quit [Quit: WeeChat 2.6]
tilpner has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
init_6 has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
pie_ has quit [Ping timeout: 265 seconds]
xwvvvvwx has quit [Quit: ZNC 1.7.4 - https://znc.in]
xwvvvvwx has joined #nixos-dev
justanotheruser has quit [Ping timeout: 265 seconds]
averell has quit [Quit: .]
justanotheruser has joined #nixos-dev
averell has joined #nixos-dev
ixxie has joined #nixos-dev
Cale has quit [Ping timeout: 264 seconds]
Cale has joined #nixos-dev
pie_ has joined #nixos-dev
orivej has joined #nixos-dev
<gchristensen> https://status.nixos.org/grafana/d/hkRCcV0mk/instance-metrics?orgId=1&refresh=30s now has some updated graphs thanks to andi- and flokli, and also has all of the spot market machines from Packet being scraped too
<Taneb> gchristensen: nice!
init_6 has quit []
<infinisil> Hm in #69660 the author adds their own package with probably nobody but themselves using it. It also includes a NixOS module, more of which will slow down rebuilds for everybody (#57477)
<{^_^}> https://github.com/NixOS/nixpkgs/pull/69660 (by Evils-Devils, 1 hour ago, open): Clarissa: init at v0.6
<{^_^}> https://github.com/NixOS/nixpkgs/issues/57477 (by Infinisil, 28 weeks ago, open): `nixos-rebuild --switch` too slow, tracking issue
<infinisil> Do we want to allow this in nixpkgs? There was discussion on this on discourse recently too: https://discourse.nixos.org/t/we-need-more-defined-guidelines-for-package-inclusion/3592
<gchristensen> I'd punt to NUR
<infinisil> Maybe we could have some kind of voting system, that all PRs that add a new package need at least one "I want to use this too"-style comment or a +1 to be eligible for merging
<gchristensen> guidelines would be better
<infinisil> guidelines are hard to judge/enforce
drakonis has joined #nixos-dev
<infinisil> I think knowing that at least 2 people are interested in a package would be a decent and simple indicator
<infinisil> for it at least having somewhat of a userbase
<samueldr> guidelines could somewhat codify that through asking for "notable" or "popular" packages, where popular is more about the concept, even a small number could be "popular" for nixpkgs
<infinisil> I worry that there could easily be disagreement, the author of course would think it's popular enough but the potential merger doesn't feel the same
<simpson> infinisil: In English we have the phrase "chicken and egg" for this sort of situation. It's unreasonable to expect demand to materialize without supply; it's already miraculous enough that people write Nix expressions given the current non-guarantee of merge.
<infinisil> Hm yes that's a good point
<infinisil> People might try `nix-env -iA nixos.florp` and give up immediately if it's not found
<danderson> fwiw, I quite like the Arch linux model for this. There's core Arch, which has a build system and promises re: breaking things; and AUR, where anyone can upload stuff, with a lightweight way to claim abandoned packages, but fewer promises that it'll work
<infinisil> I've heard this is a pretty big security problem because so many things aren't available in core
<samueldr> it's a bit more involved, there's core, extra and community, https://wiki.archlinux.org/index.php/Official_repositories#Stable_repositories
<simpson> danderson: The dynamics are different there because of who builds the binaries.
<samueldr> though tbf, core and extra could realistically be merged and things would keep working the same
<samueldr> though the layering of community between AUR and core/extra is notable
<danderson> simpson: presumably nixos could similarly decline to build cached versions of an aur-alike?
<danderson> sorry, nix, not nixos. You know what I mean.
<simpson> danderson: Sure, and that's already what we've got at the edges of nixpkgs, let alone NUR.
marek has quit [Changing host]
marek has joined #nixos-dev
<hyperfekt> Ugh, I'm trying to decide whether I want to parse nix-instantiate --eval output, use hnix, or extend nix-the-tool and I'm not sure how to. I guess it depends on how easy hooking into the nix eval code is and how closely hnix follows upstream Nix, and what the chances of getting the tool I'm building accepted into the Nix codebase are.
<gchristensen> what do you want out of the output?
<hyperfekt> gchristensen: An attribute set of .drvs from an attribute set of derivations. The plan is to merge the results of calling each into an existing attribute set and print that.
<hyperfekt> The whole thing is to become a dependency management tool, which can create new / updated entries in a 'lockfile' (which is in Nix for easy consumption) from a set of update instructions.
drakonis has quit [Ping timeout: 240 seconds]
ris has joined #nixos-dev
Jackneill has quit [Remote host closed the connection]
<__monty__> hyperfekt: Sounds a bit flakey.
<__monty__> : )
<hyperfekt> __monty__: The general concept? As long as you want to avoid one file per dependency it'll be hard to get around doing some parsing...
<clever> > hello.drvPath
<{^_^}> "/nix/store/hnvzgj1b83hy84nq382krlgn3f07jc2g-hello-2.10.drv"
pie_ has quit [Ping timeout: 240 seconds]
<__monty__> hyperfekt: It was a joking reference to the flakes RFC and its lockfile.
<hyperfekt> clever: Yeah, using .drvPath on all the derivations and parsing the resulting attrset with rnix was my plan for the nix-instantiate variant.
<clever> hyperfekt: nix-instantiate can output json too
<clever> hyperfekt: either with builtins.toJSON or --json
<clever> hyperfekt: there is also --xml, which supports more types then --json
<hyperfekt> __monty__: Yeah, that's true, they're not dissimilar. Flake lockfiles only work for other flakes though, instead of arbitrary dependencies, otherwise I wouldn't do this.
cjpbirkbeck has joined #nixos-dev
pie_ has joined #nixos-dev
ixxie has quit [Ping timeout: 240 seconds]
psyanticy has quit [Quit: Connection closed for inactivity]
<samueldr> hm, we get X stuff leaking into the minimal image again I think
* samueldr digs
justanotheruser has quit [Ping timeout: 240 seconds]
justanotheruser has joined #nixos-dev
pie_ has quit [Ping timeout: 245 seconds]
<samueldr> can't exactly pinpoint when, and bisecting may take a while, though it's something about rngd-tools, requiring opensc, which has some X11 deps
<samueldr> right, ignore the "X stuff leaking" bit, it's not new; though it was causing issues with cross-compilation, traced it to https://github.com/NixOS/nixpkgs/pull/68072 that upgrade once reverted fixes cross-compilation; looking into it now
<{^_^}> #68072 (by dtzWill, 3 weeks ago, merged): libX11: 1.6.7 -> 1.6.8
<samueldr> luckily upstream fixed the issue in the next commit
drakonis has joined #nixos-dev
drakonis has quit [Read error: Connection reset by peer]
<infinisil> globin: Regarding making mkRemovedOptionModule fail evaluation, there's a problem with that, namely that if you get an error, you have no idea where it's coming from!
<infinisil> Just now I'm updating a bunch of stuff, and I get `trace: Obsolete option `system.nixosLabel' is used. It was renamed to `system.nixos.label'.` and I have no idea where nixosLabel is used
<infinisil> It's certainly not in my config
<infinisil> (this is for mkRenamedOptionModule now, but it's the same problem for mkRemovedOptionModule)
<infinisil> I guess this is a disadvantage to IFD, because if I'd have all the nix code checked out in my config, I could just ripgrep for nixosLabel to find it, but I can't because I use IFD
<infinisil> Oh actually, that was just me being a bit stupid, I evaluated `nix-instantiate '<nixpkgs/nixos>' -A config.system`
<infinisil> But it should be `nix-instantiate '<nixpkgs/nixos>' -A system`
<infinisil> Or `nix-instantiate '<nixpkgs/nixos>' -A config.system.build.toplevel`
<infinisil> Duh
cjpbirkbeck has quit [Quit: Quitting now.]
__monty__ has quit [Quit: leaving]
<infinisil> But still, in Nix we have this problem that we have no idea where warnings come from
<infinisil> This can almost be added to the list of fundamental existing problems with Nix