<domenkozar>
other wms say: you know haskell, should be enough
<gchristensen>
I would like to introduce a program to nixpkgs / backport to 17.09 which outputs some very minimal info: nix version, owner of /nix, and the release / channel / version they're on. ideally a one-liner. any thoughts?
<gchristensen>
it is frustrating to support "unstable" users, given there are two
<gchristensen>
and I want to answer that question more precisely
<MoreTea>
like a program that you can run to gather the stuff in the issue template?
<gchristensen>
no, a bit less, just knowing what channel it is would be an improvement
jtojnar has joined joined #nixos-dev
<LnL>
don't think there's a problem with adding a package to 17.09 if there's a good reason for it
MoreTea has quit [(Ping timeout: 240 seconds)]
MoreTea has joined joined #nixos-dev
<gchristensen>
we should probably give jtojnar merge permissions
<gchristensen>
... assuming they want it...
<gchristensen>
an alternative to the debug tool is killing nixpkgs-unstable and just doing nixos-* builds :)
<domenkozar>
I think that's a very good idea
<domenkozar>
nix-print-debug
<gchristensen>
oh, I thought you liked my killing nixpkgs-unstable :P
<gchristensen>
can nix-instantiate --eval -E 'builtins.toString <nixpkgs>' be made to not output the surrounding quotes?
<gchristensen>
oh, heh, remove the toString bit ;)
<LnL>
that works for paths
<LnL>
but I would love to have a flag for that
<copumpkin>
is there an easy way to install nixUnstable without installing Nix first?
<copumpkin>
like going from a machine without nix to a machine with a single-user nixunstable
<domenkozar>
copumpkin: in what way? I'd modify nixos.org/nix/install to use unstable builds
<copumpkin>
well I'm trying to automate the installation of nixunstable on a bunch of ubuntu machines :)
<copumpkin>
I guess I can just grab the tarball from hydra
<copumpkin>
but those tend to expire I think
<domenkozar>
you'll need to find the binary tarball
<gchristensen>
you can use a latest link
<domenkozar>
then nix-store -r it
<gchristensen>
$ ./nix-print-debub.sh
<copumpkin>
but my point is that I don't have nix :)
<domenkozar>
as hydra doesn't serve build products from s3
<copumpkin>
if I have nix I can just use nixUnstable
<copumpkin>
anyway, I might just go with the normal installer and then use that to get unstable
<copumpkin>
was just wondering if there was a more direct way
<gchristensen>
niksnut: what would you think about having a Hydra jobset to build & test LnL's nix-darwin project, and a nixos.org channel for it? :)
mguex has joined joined #nixos-dev
<zimbatm>
gchristensen: is it possible to output the owner of /nix/store or detect if the install is single or multi-user?
<gchristensen>
oh I totally meant to do that
<zimbatm>
thanks for doing that by the way
<gchristensen>
:) <3
<zimbatm>
then we can add it to .github/ISSUES.md as a pre-requisite for bug reporting
<gchristensen>
and the /topic for a thing to attach for problem questions
<zimbatm>
aye
<gchristensen>
hmm not sure about a cross-platform way to do that
JosW has joined joined #nixos-dev
taktoa has quit [(Remote host closed the connection)]
<copumpkin>
a simple heuristic might be to check if root/nixbld owns entries in the store
<zimbatm>
isn't NIX_REMOTE=daemon always set in the multi-user install?
jushur has joined joined #nixos-dev
<copumpkin>
oh, yeah, probably
<LnL>
if you want to use nix then yes :)
JosW has quit [(Quit: Konversation terminated!)]
goibhniu has quit [(Ping timeout: 240 seconds)]
peti has quit [(Ping timeout: 248 seconds)]
phreedom has quit [(Ping timeout: 260 seconds)]
MichaelRaskin has joined joined #nixos-dev
<jtojnar>
gchristensen: I would not mind merge access, especially so I could label the issues
<jtojnar>
also thanks for the geary merge
<grahamc>
Well ideally you’d also merge code too :)
taktoa has joined joined #nixos-dev
<copumpkin>
niksnut: is there a way to get nix-build to drop completed builds into s3 directly as it builds, so that even if something fails it's in the binary cache? some custom store URI or something?
<copumpkin>
I mean even if the final build fails, dependencies end up in the binary cahce