pie__ has quit [Remote host closed the connection]
<yl[m]>
I received an email from Keybase saying the version I'm using has reach EOL, I'm on 18.09 channel. What do we do in these situations? Should I backport the version from unstable?
<gchristensen>
probably should
<yl[m]>
I'll open a PR, let me first test it on my system
<yl[m]>
LnL: is it possible to deploy nix-darwin via nixops instead of building on the machine itself?
<clever>
yl[m]: nixops expects to work via <nixpkgs/nixos> currently, so there is no real way to make it load nix-darwin
<yl[m]>
I see
<clever>
it would need to be heavily modified to support nix-darwin
srk has joined #nixos-dev
<yl[m]>
it would be awesome to have such support one day
srk has quit [Ping timeout: 245 seconds]
<clever>
yl[m]: there was also a talk of a nixops replacement at nixcon
<clever>
yl[m]: basically, instead of it being a python script that has to understand the target platform, it was pure nix, and nix-build would generate a bash script responsible for deploying
<clever>
you can then use normal nix overrides to add support for new targets
srk has joined #nixos-dev
<yl[m]>
oh I see
<yl[m]>
has there been any talk of using terraform as the backend?
<yl[m]>
it could prove quite useful if we leave the job of API to terraform
<yl[m]>
I saw some work done on nixops so it supports a configuration.nix through the cloud-config
<yl[m]>
and thought why not have that configuration generated and terraform used instead of nixops/boto
worldofpeace has quit [Ping timeout: 246 seconds]
aszlig has quit [Quit: Kerneling down for reboot NOW.]
aszlig has joined #nixos-dev
orivej has joined #nixos-dev
pie__ has joined #nixos-dev
pie___ has quit [Remote host closed the connection]
ckauhaus has quit [Quit: WeeChat 2.2]
ckauhaus has joined #nixos-dev
ckauhaus has quit [Client Quit]
ckauhaus has joined #nixos-dev
<niksnut>
yl[m]: yes
<colemickens>
would that mean replacing nix with hcl though?
<domenkozar>
yl[m]: I think we did a whole kamasutra between nix and terraform :)
<domenkozar>
the major issue is that terraform doesn't come with a schema
<niksnut>
hm, why does that matter?
<domenkozar>
because it would be easier to generate json and verify it's valid
<roberth>
nbp: I've been using self.callPackage just fine. What would be the reason to use super here?
<srhb>
Do we want to take the rebuild hit of the curl and valgrind patches on master soon? I don't think any of the staging branches look to be in an excellent state yet, and the channels won't advance until we get at least the curl fix in, and valgrind is very unlikely to succeed without the patch as well..
<srhb>
roberth: nbp: That's also confusing to me. self.callPackage seems the logical thing you'd usually want, but I've seen nbp dissuade from it before, and I don't understand the problem (I'm sure there's a good reason though!)
<roberth>
srhb: I'm pretty sure they are the same function, because it seems unlikely that anyone would override it. Maybe there's a situation I didn't think of where it might loop?
<srhb>
roberth: Why would it be the same function though? The scope of packages it can autoprovide should surely be different (consider one overlay that adds foo and bar where bar depends on foo)
<srhb>
roberth: Overriding it is quite common too, especially for haskellPackages (I think it's even in the user's guide) in order to make changes to all of the package set.
<roberth>
srhb: Right, in general they can be different, but in the case of the SO question they should be the same
<domenkozar>
roberth: you'll quite frequently want to override callPackage to be of local scope
<domenkozar>
ah srhb already said :)
<domenkozar>
well it's good to teach people good defaults :)
<roberth>
domenkozar: also in an overlay, for top-level packages?
<domenkozar>
I think that's where overlays get abuse, it really depends on the use case
<roberth>
domenkozar: not sure exactly what you mean with local scope. If you take it, 'modify it' but don't put it back in the overlay attrset, it's not overriding
<domenkozar>
most probably putting it in let..in makes more sense
<domenkozar>
either way, super.callPackage is a saner default
<srhb>
domenkozar: Why?
<domenkozar>
well if you chain overlays and callPackage has been overriden, it's kind of wrong?
<srhb>
Why? :P
<srhb>
This is the crux of my question
<domenkozar>
because you don't control the order of overlays
<domenkozar>
inside the overlay
<srhb>
Hm. Actually, I don't even understand how super.callPackage works (but it does) -- so that's probably my real issue.
<srhb>
It's a bit spooky-action-at-a-distance but it certainly clears up things.
<srhb>
I liked my wrong mental model better. :-P
hedning has quit [Quit: hedning]
<nbp>
roberth: srhb: The problem is the number of times we go through the fix-point resolution to find one package. using `self.` does one extra hop as opposed to doing `super.`
<nbp>
roberth: srhb: This does not matter today, but it would in the future for applying security patches.
<nbp>
roberth: srhb: Everything which uses the fix-point more than once will not received any security updates.
<nbp>
roberth: srhb: using self.callPackage uses the fix-point more than once. Once for getting callPackage, and the second one for the packages which are resolved from it.
<roberth>
nbp: So most of all-packages.nix is wrong. Interesting.
<nbp>
roberth: yes.
<roberth>
nbp: This seems like a rather fragile mechanism for security. Doesn't this eliminate a lot of overridability?
<nbp>
roberth: The other solution would be to make a breaking change to prevent everybody from using self.callPackage.
<nbp>
roberth: by making a last overlay do: self: super: { callPackage = builtins.trace "Warning: use of self.callPackage instead of super.callPackage" super.callPackage; }
<nbp>
roberth: but this would probably be way too verbose and useless for most users.
<roberth>
nbp: Seems appropriate if this security mechanism is going to materialize
<roberth>
nbp: Not sure what is worse
<nbp>
roberth: This would be a really controversial change is we ever do it :/
<roberth>
nbp: seems like
<nbp>
roberth: I guess we should probably make it an env-var to make it throw for a few version of Nixpkgs, asking people to fix them, and warn them a few version ahead of removing it.
<ekleog>
nbp: if this is done all nixpkgs would be fixed before the next hydra bump
<ekleog>
because tarball job checks for traces
<ekleog>
so I think it wouldn't be too verbose once it's done
<nbp>
ekleog: if this is done, everybody which is not using overlay will get these printed warnings.
<ekleog>
oh
<ekleog>
in this case it's a problem indeed
<ekleog>
but couldn't there be an implicit overlay that just does this?
<nbp>
ekleog: and they would rightfully get this warning as they will not benefit from security updates too.
<nbp>
we could make an overlay which is used in self computation, but not in the output of Nixpkgs, yes.
<nbp>
which would solve this issue.
<ekleog>
nbp: I think I don't get what exactly the security updates thing is
<nbp>
ekleog: this is still the old story that I made in a pull request but never got enough momentum around it.
<ekleog>
all I'm saying is that by default there could be no trace that passes through an hydra bump, because tarball job :)
<nbp>
ekleog: This is the automatic grafting proposal.
<nbp>
gchristensen: I don't think not caring is wise, not supporting with hydra is whoever fill the chache choices.
<nbp>
s/chache/cache/
<gchristensen>
by "not caring for" I mean not not liking them, because of this specific problem
<gchristensen>
s/not not/not/
<nbp>
gchristensen: I agree, overlays should not be supported by Nixpkgs, that the responsibility of the overlay author to make sure they are doing the right things with the latest Nixpkgs.
<nbp>
gchristensen: In the mean time overlay solve a problem, which is better solved with overlay than any other patching mechanism we had before.
<gchristensen>
I agree, I'm afraid I've not communicated what was intended very well
<gchristensen>
not a problem with overlays, but a easily avoided unintended consequence -- stuff like this would be cool to write about and publish "best practices" and what-not
<nbp>
overlays are currently lacking tools to manage them.
pie___ has joined #nixos-dev
<nbp>
and I am guessing this is the feeling that niksnut has, that updates of overlays are not integrated with other Nixpkgs updates.
<roberth>
gchristensen: your upgrade function would be a great addition to pkgs.lib imo
pie__ has quit [Remote host closed the connection]
<gchristensen>
I don't know, nbp. this overlay is private to the repository using it - the author isn't someone far away
<nbp>
gchristensen: I will also note, that sometimes it might be desirable to have overlays to downgrade packages.
<gchristensen>
sure
<gchristensen>
an unrelated note is I am scared to use overlays I haven't written, I feel they grant a lot of authority... but it comes with the territory :D
<nbp>
gchristensen: NixOS modules :cough:
<gchristensen>
definitely same of course
<nbp>
gchristensen: I honestly do not know how to keep the patchability of Overlays and NixOS modules while adding such restrictions.
<ekleog>
gchristensen: NUR FTW
<nbp>
gchristensen: the upgrade function is great, as it make some problem visible.
<gchristensen>
not sure. the times I have needed to load an overlay from someone else, I reimported nixpkgs in my personal overlay (this was the time I used NUR)
<nbp>
I never looked at NUR, I cannot tell anything about it.
<gchristensen>
it puts everybody in to a namespace, so you only trust NUR to not muck around
<nbp>
but then you cannot patch others packages or change a dependency without duplicating everything?
<gchristensen>
NUR isn't for patching, it is for distributing non-nixpkgs exprs
orivej has joined #nixos-dev
<gchristensen>
(maybe NUR folks would be better served by not-me answering NUR questions :P)
<ekleog>
(which is all I've needed up to now, but I haven't tested NUR yet either :D)
<ekleog>
then a solution would be to deliver the packages through NUR and let the user add these to an overlay, if there is a need for patching
<ekleog>
this way the user knows exactly what packages are overridden
<gchristensen>
the first Nix "flake" hack for a NixOS module is going to be a huge catastrophy
<asymmetric>
> If you are using Linux or macOS, the easiest way to install Nix is to run the following command [...] As of Nix 2.1.0, the Nix installer will always default to creating a single-user installation, however opting in to the multi-user installation is highly recommended.
<{^_^}>
error: syntax error, unexpected ',', expecting ')', at (string):209:32
<gchristensen>
we should stick to multi-user darwin on Travis
<domenkozar>
gchristensen: interesting, why?
<gchristensen>
why we should stick with it?
<domenkozar>
yeah :)
<gchristensen>
(1) it is now, and changing it, I think, is not so nice (2) it offers much more protection for the user, which is nice to have in CI (3) the installer defaulted back to single-user because of upgrade issues which exist only if you have Nix installed long-term, which Travis doesn't, so none of the reasons to have gone back to single-user apply
<domenkozar>
but it is very single user environment :)
<domenkozar>
those are good points though.
<gchristensen>
the main point of multi-user is not to support multiple end users and you know it :P
<domenkozar>
I think multi-user installer comes with quirks
<domenkozar>
like, most folks change nix.conf
<domenkozar>
and then nothing happens
<domenkozar>
so you have to come up with kill stuff to reload the daemon
<domenkozar>
quite a few loops to jump through
<gchristensen>
`pkill nix` ? :)
<domenkozar>
user is not trusted by default
<domenkozar>
which is another loop that is just, why :)
<asymmetric>
also, if we assume most people just use the default when installing nix, then the travis setup doesn't reflect how most user's setup
<domenkozar>
like most people now use cachix, the first thing they run into is that setting up binary cache won't work
<domenkozar>
then you need to trust the user
<domenkozar>
then you figure out that you need to restart the daemon
<domenkozar>
all of those go away with single user install
<domenkozar>
otherwise, people will just cargo cult that in
<gchristensen>
we could fix that stuff in the travis config -- make the user trusted by default
<domenkozar>
I think we now default to single-user on linux and multi-user on darwin?
<domenkozar>
ok so the plan is: fix multi-user support on travis
<domenkozar>
and upgrade nix
<domenkozar>
ideally, ship multi-user support on linux
<domenkozar>
to travis.
<gchristensen>
domenkozar: the Travis Nix YAML config could support arbitrary nix.conf directives and auto apply/restart the daemon
<gchristensen>
(in addition)
<domenkozar>
yeah I was thinking about that
<domenkozar>
probably just needs work :)
<gchristensen>
indeed :P and more complicated could be a `daemon` option
<domenkozar>
I'm using circleci with a custom docker image
<domenkozar>
works well :)
<domenkozar>
the problem with travis is, it's hard to find one size fits all
<gchristensen>
having the installer have a flag like --daemon-if-possible would be nice, whereas right now --daemon turns it on even if the host isn't supported
<gchristensen>
and hacking on the build script .rb file is no fun / hard to test
<domenkozar>
yeah
<asymmetric>
gchristensen: what's the main advantage of multi-user, if it's not support for multiple users?
<gchristensen>
the daemon brings most of the protections of Nix.
<gchristensen>
only writing to the out dir, preventingc access to the network, preventing arbitrarily reading from your hard drive, on and on
<gchristensen>
plus a single-user install means anything can write to /nix/store, so if you get python / pip from nix, pip can write stuff to /nix/store/ and corrupt it
ixxie has joined #nixos-dev
orivej has quit [Ping timeout: 245 seconds]
__Sander__ has quit [Quit: Konversation terminated!]
orivej has joined #nixos-dev
asymmetric has quit [Ping timeout: 268 seconds]
orivej has quit [Ping timeout: 245 seconds]
phreedom_ has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
worldofpeace has joined #nixos-dev
ixxie has quit [Ping timeout: 250 seconds]
<gchristensen>
it is extremely suspicious that hydra has almost 0 x86-64 linux builds -- any idea what is up, y'all?
<jtojnar>
gchristensen: nope, I just do not see any “Merge branch 'master' into staging” commits
<jtojnar>
recently
<jtojnar>
so I am not sure if we do it any more
pie__ has joined #nixos-dev
<gchristensen>
ah
pie___ has quit [Remote host closed the connection]
hedning has quit [Quit: hedning]
<yl[m]>
is there a particular reason why we can merge PRs even if changes were requested? http://i.imgur.com/j4BLIst.png
orivej has joined #nixos-dev
<Mic92>
yl[m]: do you mean technically or in this particular context?
<yl[m]>
I requested changes to this PR and I can still merge it. This can lead to accidental merges, so at work I required it for merging PRs. If you really meant to merge the PR, you can also dismiss the review
<clever>
i gathered every example in my irc logs, started documenting how they work, then got distracted, lol
<LnL>
yeah, "somebody" should document the uri stuff
<clever>
doit.sh will also do some fun things, it uses a normal /nix/store build, to create a /home/example/nix/store build, that initially lands in /home/clever/home/example/nix/store/
<clever>
then you can copy /home/clever/home/example/nix to a remote /home/example/nix and it just works
<LnL>
I just want a "new" regular store in this case, not a diverted one
<clever>
LnL: something that expects it to be at /nix/store/ ?
<LnL>
nope
<clever>
LnL: then you want one more like /home/clever/nix/store/ ?
<LnL>
a place to dump files probably only generated with builtins.toFile
<LnL>
a relocated store prints out the wrong paths which would be annoying
<gchristensen>
moving to the Checks API, I think ofborg would have to report a failed build as "Neutral" in order to not block the merging. does that seem reasonable?
<LnL>
probably, do you know how that looks?
asymmetric has joined #nixos-dev
<gchristensen>
I think they just show up gray
init_6 has joined #nixos-dev
hedning has joined #nixos-dev
orivej has quit [Ping timeout: 268 seconds]
jtojnar has quit [Quit: jtojnar]
Enzime has joined #nixos-dev
<Enzime>
any idea what's up with nixos-unstable?
<Enzime>
apparently it hasn't been updated for 13 days :\
sir_guy_carleton has joined #nixos-dev
asymmetric has quit [Ping timeout: 250 seconds]
<thoughtpolice>
Ugh, using NTP in the NixOS test suite is a bit annoying. :|