<clever>
bbarker: can you pastebin the entire nix file?
<clever>
attente[m]: ^^^
<clever>
> "${gcc.cc.lib}/lib"
<clever>
bbarker: what does it output if you just run `cat $NIX_CC/nix-support/dynamic-linker` in the installPhase?
<clever>
bbarker: and are you running that before or after the file gets copied to $out, and what is $exfi?
<clever>
bbarker: and you are not telling it what file to edit
<clever>
bbarker: you are telling it to set the interpreter to "exec $(cat $NIX_CC/nix-support/dynamic-linker) $exfi $@"
<clever>
bbarker: and the " is too far at the end
<clever>
bbarker: the exec shouldnt be in there
<clever>
so you pre-build the entire thing, and deploy it to the box
<clever>
kisik21: or just go ham, and control the box with nixops
<clever>
kisik21: you can also use nix-copy-closure to just copy something you already have to another machine
<clever>
kisik21: 3/1 split, 3gig to userland, 1gig to kernel
<clever>
kisik21: but its imposible to get >3gig of ram in a single process on 32bit
<clever>
kisik21: years ago, i found myself unable to build firefox on 32bit gentoo, because it needed >3gig of memory to link the main binary
<clever>
joko: i think hydra will get very upset, and not rebuild things it thinks are already built
<clever>
one of the fields was 2^64, but jq stores everything as floats
<clever>
dckc: i recently corrupted a yaml file, by doing yaml2json | jq | json2yaml
<clever>
dckc: :D
<clever>
dckc: you can also make default.nix do foo = callPackage ./foo.nix {};, and then foo.nix is the real package
<clever>
with import <nixpkgs> {}; is a way to cheat around having to load it with callPackage
<clever>
,callPackage dckc
<clever>
dckc: if you are making a simple trac module (like the snmpd.nix in the above gist) then youll know what it relies on the host to provide (users, dirs, and such)
<clever>
dckc: i dont see any existing modules for trac or rstudio
<clever>
then you just need to deal with getting the users and dirs to exist, since users.users wont do it
<clever>
this will just spit out systemd .service files, for any nixos service
<clever>
sicklorkin: youll want to make an overlay using something like callCabal2nix
<clever>
sicklorkin: what are you trying to build?
<clever>
oh, lol
<clever>
sicklorkin: ivolve?
<clever>
sicklorkin: the only way to get coverage from the cache, is to change the minimal subset you need, and to stay as close to nixpkgs as you can
<clever>
sicklorkin: when using stack2nix or nix-tools, your overriding the version of every single package, so hydra.nixos.org wont have things covered anymore
<clever>
sicklorkin: it needs versions built by nix, but stackage isnt building with nix
<clever>
not sure what could cause that, would need some strace or set -x
<clever>
ottidmes: npm will manage a combined node_modules/.bin for you
<clever>
ottidmes: if you add the .bin to PATH, then it should patch correctly
<clever>
infinee_: boot.loader.grub.efiSupport is the main thing you want to set for efi
<clever>
infinee_: efiSysMountPoint does not appear in either of those pages, and should not be used with /boot/ is the ESP partition
<clever>
infinee_: `systemctl start sshd` and `passwd`, then you can ssh into it from another machine with a working GUI
<clever>
infinee_: you should only set that if /boot/ itself is ext4, and /boot/efi is vfat
<clever>
infinee_: boot.loader.grub.efiSysMountPoint = "/boot/efi"; means that you mounted the ESP partition to /boot/efi/
<clever>
ottidmes: is gulp itself in PATH, when you ran patchShebangs?
<clever>
infinee_: can you pastebin the whole mount output?
<clever>
infinee_: there is a /etc/ missing in that string
<clever>
infinee_: what does `mount` output?
<clever>
infinee_: the installation should never remove /mnt/etc/nixos/
<clever>
ottidmes: ah, that should do it
<clever>
ottidmes: you might want to look at how yarn2nix is doing the download, i believe its entirely pkgs.fetchurl calls, so no scripts can run at that time
<clever>
if its running scripts at that phase, then its both a security problem, and a purity problem that can break the hash at any time
<clever>
s/bash//
<clever>
its running the bash script inside the fixed-output derivation?
<clever>
patchPhase? postUnpack? replace the tar with a patched tar before nix gets it?
<clever>
why is it not possible?
<clever>
so your only choice is to patchshebangs, before the script gets ran
<clever>
and i think /usr/bin/ is read-only from within the sandbox
<clever>
ottidmes: oh, yeah, hydra, and all end-users, would fail to build it, without that change
<clever>
in your case, you would want something like /usr/bin/env=${pkgs.coreutils}/bin/env
<clever>
ottidmes: using this option in nix.conf, you can impurely add things into the sandbox
<clever>
ottidmes: ah, yeah, yarn2nix involves IFD, but i have seen signs that it can work without IFD as well
<clever>
ottidmes: yarn2nix should be able to patch the things in node_modules before running the scripts
<clever>
ottidmes: have you looked into yarn2nix?
<clever>
ottidmes: that will replace every /usr/bin/env foo, with $(which foo)
<clever>
ottidmes: you have to run patchShebangs over the script (or the scripts dir)
<clever>
ivegotasthma: some services may run into problems, such as hard-coded /run/current-system, or assuming users.users actually made a user, but youll just need to find such things and fix them as they occur
<clever>
and that will allow running nixos services no non-nixos
<clever>
srhb: if you buildEnv several .service files together, you could then "install" them on any machine, and point systemd towards that dir
<clever>
pie_: what path is at the end of the list you truncated?
<clever>
pie_: so you can have a totally broken nix.nixPath, and it will work, once
<clever>
pie_: changes to nix.nixPath dont take effect until afetr the build has finished
<clever>
jonreeve: that will at least narrow down which one is broken, and needs more attention on it
<clever>
jonreeve: try commenting one out, and see if `nixos-rebuild build` passes or fails
<clever>
jonreeve: do you have anything python based in your systemPackages?
<clever>
jonreeve: you need to edit your configuration.nix, to not put 2 msgpack's into the python env
<clever>
jonreeve: it looks like you have 2 different variants of msgpack in that python env
<clever>
jonreeve: something you put into systemPackages
<clever>
jonreeve: you have conflicting files in a python thing your installing
<clever>
builder for '/nix/store/4y42l6irgbdszk6npn1a9mz5hr34l7jw-python3-3.7.2-env.drv' failed with exit code 25
<clever>
collision between `/nix/store/bfw27ldvy66v6mhwkzillzz1ddfz5lwf-python3.7-msgpack-0.5.6/lib/python3.7/site-packages/msgpack/__pycache__/exceptions.cpython-37.pyc' and `/nix/store/9dkp2r0hsr2jkd44qinw6m7fk8lsx2xy-python3.7-msgpack-python-0.5.6/lib/python3.7/site-packages/msgpack/__pycache__/exceptions.cpython-37.pyc'
<clever>
pie_: this is also a thing, but i suspect it needs the right things in buildInputs already
<clever>
lucus16: cross-compile package sets are auto-generated for nearly all platforms (maybe all?) and you can then use that to cross-compile almost any package
<clever>
> pkgsCross.mingwW64.hello
<clever>
no mouse needed either
<clever>
on bootup, plex just runs automatically, and i can play any media stored on any plex server i have permissions on
<clever>
that file contains everything you need to turn a nixos box into a media center
<clever>
Avaq: one critical thing when migrating from nixos to nixops, is to ensure you setup fileSystems. and boot. correctly, since it ignores configuration.nix and hardware-configuration.nix
<clever>
Avaq: yep
<clever>
Avaq: if you missed anything vital, it will behave the same as if you had simply removed that from configurationnix
<clever>
Avaq: and setup a new generation, as-if you had done a nixos-rebuild
<clever>
Avaq: when you do a `nixops deploy`, it will completely replace the old system, by just copying the new stuff into /nix/store and updating /run/current-system
<clever>
gchristensen: this is a nix-env profile, that roots every version i have deployed to my router/nas
<clever>
gchristensen: it does, when you turn on rollback
<clever>
mpickering: if you ssh in from another box, and run `ps -eH x`, is xmonad running, anything else near it?
<clever>
and nixos-rebuild tries to avoid restarting X, because it interupts everything, so you need to `systemctl restart display-manager.service` manually after these kinds of changes
<clever>
mpickering: it may also help to set desktopManager.xterm.enable = false;
<clever>
mpickering: window manager is a seperate option from desktop manager
<clever>
mpickering: the default desktop manager is xterm, you need to enable another one, and then either select it at the login screen, or disable xterm
<clever>
i'm not sure if that has an off switch
<clever>
Henson: if nix has root when doing a build, it assumes the nixbld group exists, and has build users within it
<clever>
alex_giusi_tiri: if the script is ran during the build, then patchPhase is a good place, if its at runtime, then any phase can work
<clever>
alex_giusi_tiri: you can also run it on a directory, and all files in the directory will be patched
<clever>
cransom: the same can be said about what nix has done to basically every package in the world
<clever>
yayforj: just import that file, and use its result, instead of haskellPackages
<clever>
dhess: thats what it looks like to me
<clever>
cransom: none, and aws, handle the nixops generated key in different ways
<clever>
cransom: it relies on the file that was created on the first boot
<clever>
cransom: and line 27 is to deal with the fact that the aws backend of nixops, DOES NOT bake its own key into the nixos config!
<clever>
cransom: we have also disabled the files in ~/.ssh/, so authorized keys cant be edited from the user itself
<clever>
cransom: only issue, is that it doesnt obey services.openssh.authorizedKeysFiles
<clever>
cransom: oh, that can work
<clever>
yayforj: yeah, stack2nix replaces the entire haskellPackages set, based on what the stack file said
<clever>
cransom: sudo requires a password, and cant accept a forwarded agent
<clever>
cransom: sudo
<clever>
dhess: so send-keys cant really change things
<clever>
dhess: nixops bakes its own public key into the nixos config it builds
<clever>
re-keying things
<clever>
tilpner: that is a bug that needs to be fixed in nixops
<clever>
tilpner: when you have 100 machines that you basically never ssh into, and dont want to re-deploy every time somebody quits and you have to cut them off
<clever>
tilpner: thats more about disabling the i686 support
<clever>
tilpner: my qemu.nix is currently the only thing that sets it
<clever>
tilpner: so that will need to be added back in manually
<clever>
tilpner: i suspect the new implementation of extra-platforms disables the automatic addition of i686-linux