<clever>
you could look at how the nixos ones work, and maybe reuse them
<clever>
yeah
<clever>
so setuid just doesnt work outside of nixos
<clever>
but there is nothing setup to run something from nix, as root, when the machine boots
<clever>
all setuid stuff is handled by wrappers made in /run/wrappers/bin/ when nixos boots
<clever>
colemickens: nix doesnt allow setuid files in /nix/store/
<clever>
stepcut: but i already have unencrypted keys for build slaves
<clever>
stepcut: in my case, i'm using gpg-agent for my ssh agent, and its socket is at a predictable place, so its a bit simpler if i wanted to do that
<clever>
thomasjm: it should detect that some "invalid" storepaths are in the cache, and just ignore the cache
<clever>
thomasjm: so thats a different bug, but should still be filed to nix
<clever>
thomasjm: and nix then complains that those /nix/store/ paths dont exist
<clever>
thomasjm: you missed ~/.cache/nix/ which is pointing into /nix/store/
<clever>
ottidmes: i sometimes do, but it has been broken on nixos at times
<clever>
thomasjm: i think the cache is to blame here, different bug, what is the contents of ls -lh home/tom/.cache/nix/tarballs/071qfgdy82dkn58wqsv1ri3zlch4amvvfgn5vmwh9fvb4spcv18y-file
<clever>
thomasjm: oh wait, was nix previously used on this, without that change?
<clever>
thomasjm: definitely looks like nix-channel is broken when using non-standard storepaths, youll need to file a bug on nix itself
<clever>
,paste thomasjm
<clever>
ottidmes: your even using the same keysize and type as the comic! :D
<clever>
stepcut: you might get away with setting SSH_AUTH_SOCK correctly for the nix-daemon service
<clever>
fetchGitPrivate is the only thing that uses NIX_PATH like that
<clever>
stepcut: ssh-ng:// just runs ssh directly, and doesnt care about NIX_PATH
<clever>
stepcut: yep, now `strace -ff -o logfiles -p <pid>` with the pid of the current nix-daemon, and then run a single build, and ctrl+c the strace
<clever>
stepcut: strace needs -f to detect the ssh attempts
<clever>
stepcut: and then read the logfiles for where it makes the ssh session
<clever>
feep: and that must have channels within it
<clever>
feep: a subdir of it should symlink there
<clever>
feep: re-running nix-channel --update or sourcing nix.sh may fix it
<clever>
feep: ~/.nix-defexpr/ is to blame
<clever>
colemickens: correct, it has some sane defaults for nix.conf, and can function with /etc/nix entirely missing
2018-11-05
<clever>
thomasjm: you can also clone nixpkgs, and then nix-env -f ~/nixpkgs -i awscli
<clever>
thomasjm: it looks in ~/.nix-defexpr to find nixpkgs by default
<clever>
thomasjm: and ~/.nix-defexpr should be fixed the first time you run nix-channel
<clever>
thomasjm: ~/.nix-profile will remain broken until you first run `nix-env -i something`
<clever>
jabranham: and your still on aarch64?
<clever>
jabranham: which channel are you on?
<clever>
jabranham: it should, what is the storepath of the kernel its trying to build?
<clever>
ddellacosta: `nix-env -e home-manager-path` to uninstall it from .nix-profile
<clever>
ddellacosta: then it will be listed somewhere in `nix-env -q`
<clever>
ddellacosta: ls -lh ~/.bin
<clever>
fede_run: youll need to update the url in the nixpkgs source, and the sha256, then file a PR to nixpkgs
<clever>
fede_run: somebody deleted it from the server, so the nix code will need to be fixed
<clever>
as well
<clever>
,-A fede_run
<clever>
fede_run: you want -i, not -I
<clever>
lucky :P
<clever>
yeah
<clever>
maximiliantagher: in cardano's case, that template haskell was too deep into the dep stack, so it was recompiling 30+ minutes worth of code, when only the top layer has changed
<clever>
(nix also deletes .git, so the fallback wont work)
<clever>
that older one will read $GITREV, and if it fails, it runs `git rev-parse HEAD`
<clever>
maximiliantagher: there are simpler ways to do it, but they result in nix rebuilding the binary every time any commit happens, so you loose caching
<clever>
maximiliantagher: 5 pre-allocates a dummy space for a gitrev at compile time, 3/4 then modify the binary (after compiling) to inject a rev, which allows nix to cache the compile haskell code (for when no haskell changes occur), but still update the gitrev within it, so --version remains right
<clever>
exarkun2: which one you want, depends on what your trying to modify
<clever>
exarkun2: overrideCabal applies before generic-builder.nix
<clever>
exarkun2: it works, but it applies after generic-builder.nix and they cease to be "haskell packages"
<clever>
exarkun2: yes and no
<clever>
ghusbands: you can also use things like `nix copy` to create a binary cache with all of the build products, as either an s3 bucket, static http server, or just a tarball
<clever>
ghusbands: if you import a specific version of nixpkgs, an store all the expressions in git, you can reproduce the whole thing, as long as the src URL's arent deleted
<clever>
heh, hit the magic number!
<clever>
das_j: probably not
<clever>
das_j: that handled by setup hooks usually, which only get ran by nix-shell and nix-build
<clever>
eeva: whatever the problem is, you already fixed it, but nix-daemon had cached the bad base64
<clever>
eeva: what happens if you `sudo systemctl restart nix-daemon.service` then try `nix-store -r` again on a storepath?
<clever>
lukego: if it was booting via legacy, it would be more likely to have a proper menu
<clever>
lukego: systemd-boot is efi only
<clever>
lukego: i prefer using grub, and ive heard that systemd-boot lacks the rollback menu
<clever>
lukego: after you boot from something else, you can use `nixos-enter` to chroot into it (assuming you mounted everything right), and can then `nixos-rebuild boot`
<clever>
catern: i believe the product of builtins.toFile must have zero dependencies, you want pkgs.writeText or pkgs.writeTextFile
<clever>
symphorien: try patchShebangs instead, since it knows what a #! looks like
<clever>
symphorien: i then spent 2 hours helping them debug why the zip file was corrupt :P
<clever>
symphorien: i have seen somebody run a command like that before, which replaced paths inside a zip file
<clever>
and it sounds like the postInstall code in cabal2nix expects it to always be on
<clever>
yep
<clever>
thefloweringash: enableSeparateDataOutput = true; has to be set on the derivation, which cabal2nix should be doing
<clever>
thefloweringash: mostly nix
<clever>
thefloweringash: $data will only exist if a special bool is set when running mkDerivation
<clever>
nschoe: the version of state like db.sqlite
<clever>
ah, then it shouldnt have too much trouble with the CFG leaks in windows
<clever>
angerman: do you happen to know if the RTS generates any chunks of code at runtime, such as with thunks, requiring pages to be mapped executable?
<clever>
ah
<clever>
catern: and using those vars, you can see if a function is being called too much
<clever>
,profiling
<clever>
(with the same args)
<clever>
catern: but there is no cache for function calls, so you can wind up wasting a lot of cpu and ram by re-calling the same function repeatedly
<clever>
catern: there is an import cache that maps paths to values, so it should cache the result of importing
<clever>
not sure then
<clever>
ottidmes: is this on nixos?
<clever>
ottidmes: did you edit the file in the store?
<clever>
ottidmes: the fork from my example has had some improvements to fix various things, not sure if they got int nixpkgs or not
<clever>
ottidmes: are you using the fork of yarn2nix from the example i linked?
<clever>
that should also work i believe
<clever>
probably with `yarn install`
<clever>
ottidmes: you need to generate one outside of a nix sandbox, and commit it to your repo
2018-11-03
<clever>
joepie91: if you uninstall pkgconfig, then it will instead say pkgconfig not found, and you will then add it, and all is well
<clever>
joepie91: and to make things worse, when you do forget to add it to your nix-shell inputs, it claims freetype2 not found, when it exists
<clever>
if you wrongly install it with nix-env/systemPackages, then it just never finds buildInputs
<clever>
that only works under nix-shell and nix-build
<clever>
so it magically finds all inputs
<clever>
pkgconfig has a setuphook, that will scan all buildInputs, and add them to the pkgconfig search path
<clever>
joepie91: it doesnt work right, and only leads to more confusion when it half works due to not being in the nix-shell
<clever>
joepie91: also, if you ever installed pkgconfig in nix-env or systemPackages, remove it asap
<clever>
joepie91: and pkgconfig in the nativeBuildInputs?
<clever>
Zajcev_: investigate how to configure it to look elsewhere for pam modules, and then fix either the package or nixos module
<clever>
joepie91: cmake is in cmake
<clever>
joepie91: cmake!
<clever>
Zajcev_: its over in pam_pgsql, sounds like a bug in vsftpd's package
<clever>
,locate pam_pgsql.so
<clever>
joepie91: just add pkgconfig and alsaLib to your inputs, and it should work
<clever>
ddellacosta: the only other option is to mess with nix-copy and a usb stick, which is more complex
<clever>
ddellacosta: nixos-install is just a helper that runs nixos-rebuild under a chroot for you
<clever>
ddellacosta: boot the install media again, mount the existing fs to /mnt (and /mnt/boot if you have it), edit the config, and nixos-install
<clever>
ddellacosta: got an ethernet cord?
<clever>
while keeping the same API
<clever>
ottidmes: if you pass fetchSubmodules=true; then it will internally switch to pkgs.fetchgit for you
<clever>
stepcut: its a 2 lines, the example --shell makes is far more complex then it has to be
<clever>
skip --shell and just write a better file
<clever>
just load it with haskellPackages.callPackage
<clever>
you can ignore the default.nix cabal2nix generates, and only use the main file it produces
<clever>
just do the right thing from shell.nix to begin with, dont try to do magic things that guess what you want
<clever>
stepcut: i try to avoid using inNixShell, it just makes things behave in unpredictable ways
<clever>
yeah, it sounds like its just poorly written
<clever>
nschoe: if you found that inside a .img, then it is built, but not very well
<clever>
nschoe: you will need the right entries under boot.loader and fileSystems."/" and "/boot" to make sure it still boots, those will depend on how exactly the image is built
<clever>
WilliamHamilton[: if emacs is searching the right areas of ~/.nix-profile/, and the package had those files in its $out, yes
<clever>
nschoe: ah, then the default config is likely wrong
<clever>
nschoe: that will merge everything defined in that file with the other things you add to configuration.nix
<clever>
WilliamHamilton[: but you can do something like `nix-env -f default.nix -iA foobar` to install something into your profile, it will get merged into ~/.nix-profile/
<clever>
WilliamHamilton[: nix-build doesnt have -i or -p flags