<clever>
pistache: but you can also make a smaller module, that only turns on the hardening, and then make a completely seperate "machine" for build-vm, which wont try to mount disks that wont exist
<clever>
pistache: yep
<clever>
pistache: as an example, my nas starts from nas.nix, and you recursively follow everything listed in imports, to see the full config
<clever>
pistache: what if you only use the kernelPackages change, and not the kernelPatches half?
<clever>
Jonathan44: now just reference that expresion in the buildInputs of the next thing, maybe using `rec {` or a let block, and nix-build the next thing in line
<clever>
pistache: can you pastebin your configuration.nix file?
<clever>
atemu12[m]: lib.filter
<clever>
Jonathan44: start by getting the dependencies to build with nix-build, not nix-shell
<clever>
Jonathan44: the "proper" way to do it, is to build the dependencies with nix, and add them to the buildInputs
<clever>
zeta_0: yeah
<clever>
zeta_0: every single package in haskellPackages has a .env on it
<clever>
zeta_0: once your in the nix-shell, you can mostly use cabal as normal
<clever>
lovesegfault: you can also use `--option substituters ssh://10.0.5.155` to make nix treat the remote machine as a binary cache
<clever>
Also copy the outputs of store derivations included in the closure.
<clever>
zeta_0: it must go inside the attribute set that goes from line 1 to 7
<clever>
hpfr[m]: and behind the scenes, nixos-rebuild is just using nix-env to manage the system profile, so you can use this to list/delete generations
<clever>
hpfr[m]: nixos-rebuild will create generations in the system profile
<clever>
hpfr[m]: nix-env -i will create generations in your user profile
<clever>
Ilya_G: also, the docs and error, say it should be a list, not a set, systemd.automounts = [ {...} {...} ]; for ex
<clever>
Ilya_G: its probably simpler to just add it to fstab via the normal fileSystems."/foo" stuff
<clever>
nextloop: not sure why its building then
<clever>
nextloop: do you have any overrides to vlc? which channel are you on?
<clever>
jonreeve[m]: you must add a `name = "...";` that matches the name of the cabal file
<clever>
nextloop: that looks unrelated to vlc, is it something youve installed seperately?
<clever>
nextloop: vlc should be available in source form, which jar did you see being downloaded?
<clever>
jonreeve[m]: add `name = "annotate-color";` to the args of developPackage
<clever>
jonreeve[m]: developPackage runs callCabal2nix for you
<clever>
jonreeve[m]: add name = "annotate-color"; to the default.nix file
<clever>
jonreeve[m]: you called it annotate-color.cabal, so that fails
<clever>
jonreeve[m]: so its looking for color-word-analyzer.cabal
<clever>
jonreeve[m]: the problem, is that the default name is color-word-analyzer
<clever>
231 developPackage =
<clever>
233 , name ? builtins.baseNameOf root
<clever>
232 { root
<clever>
jonreeve[m]: the problem is likely the name of things
<clever>
jonreeve[m]: what args did yo run developPackage with?
<clever>
jonreeve[m]: what args did yo run callCabal2nix with?
<clever>
jonreeve[m]: its not a caching problem, its a problem with your nix code
<clever>
jonreeve[m]: what args did yo run callCabal2nix with?
<clever>
jonreeve[m]: thats your problem then, what args did yo run callCabal2nix with?
<clever>
jonreeve[m]: thats your problem then, what args did yo run callCabal2nix with?
<clever>
jonreeve[m]: and that matches the one you find in /nix/store/fvka3nd7slnqgjvfkjg649v77y10lc89-color-word-analyzer ?
<clever>
jonreeve[m]: github does have nix highlighting, but the contents you pasted are json, so its showing red all over the place
<clever>
das_j: that appears to be a bug in `nix build`, it did build it, but pointed result to the wrong thing
<clever>
das_j: what exactly did you run with `nix build`, the full arg list and output
<clever>
das_j: is the last-mod on the result symlink changing?
<clever>
das_j: you can run `nix build` on either a storepath or a drv file
<clever>
terlar: what overlays do you have?
<clever>
jonreeve[m]: what does the cabal file in /nix/store/fvka3nd7slnqgjvfkjg649v77y10lc89-color-word-analyzer look like? can you add that file to the gist?
<clever>
jonreeve[m]: its a json output, so if you rename the file in the gist, the syntax highlighting will be a lot more pretty
<clever>
terlar: thats reporting only 0.175 sec, which is pretty speedy, weird
<clever>
jonreeve[m]: can you pastebin `nix show-derivation /nix/store/02szzrd1w7wqmnkh9is5qlx64m7r6f1z-cabal2nix-color-word-analyzer.drv` ?
<clever>
jonreeve[m]: cabal2nix is trying to write to /nix/var while inside a nix sandbox, so there is a problem with the build process
<clever>
terlar: yeah, it should return a drv file
<clever>
jonreeve[m]: is it nixos or another distro?
<clever>
zeta_0: for cabal-install, use .overrideAttrs to add cabal-install to the buildInputs
<clever>
zeta_0: if you want to force 865, use haskell.packages.ghc865.dars.env
<clever>
zeta_0: it will come with whatever ghc is default for haskellPackages
<clever>
organixpear: allowed-users in nix.conf can be used to restrict it
<clever>
zeta_0: ignore default.nix entirely
<clever>
zeta_0: then just run nix-shell
<clever>
zeta_0: create a shell.nix that has only: with import <nixpkgs> {}; haskellPackages.darcs.env
<clever>
zeta_0: you could change only the shell.nix file
<clever>
zeta_0: you may be able to just ditch compiler.developPackage entirely, and use darcs.env.overrideAttrs by itself
<clever>
zeta_0: but you can do darcs.env.overrideAttrs (old: { ... }) to extend the buildInputs further
<clever>
zeta_0: you need to point nix-shell directly to darcs.env, not add it to the buildInputs of something else
<clever>
zeta_0: no
<clever>
colemickens: boot.debug1 and other debug ones (read the script) will also force a false failure at various points, letting you get a shell early
<clever>
colemickens: add boot.shell_on_fail to the cmdline, and then a shell will be added to the menu
<clever>
151 boot.shell_on_fail)
<clever>
colemickens: it can already do that, but you have to authorize it with a kernel cmdline flag
<clever>
colemickens: try getting a shell in the initrd, and then do `ip link`
<clever>
colemickens: ive also looked into the hw of it some, and the genet doesnt have any firmware
<clever>
colemickens: no need to do anything special then, it should just work in the initrd
<clever>
colemickens: so the genet module is present, but if modinfo cant find it, it must be compiled into the kernel
<clever>
colemickens: and what about ls /sys/module/genet/ ?
<clever>
colemickens: what about `modinfo genet` ?
<clever>
colemickens: do you see genet in lsmod?
<clever>
yeah
<clever>
srid: and what does rib do when you give it the wrong root?
<clever>
srid: so root is getting replaced with this
<clever>
> pkgs.root
<clever>
srid: maybe just `import ./foo {}` then?
<clever>
srid: when you use pkgs.callPackage, it will search for each of those args, in pkgs
<clever>
zeta_0: thats what nixpkgs is using to compile darcs
<clever>
zeta_0: it probably includes everything you need
<clever>
srid: the defaults are for when they cant be found under pkgs
<clever>
ottidmes: no middle ground where you see half a change
<clever>
ottidmes: i'm thinking more in terms of the change either didnt happen, or fully happened
<clever>
ottidmes: it will have a different inode and last-mod timestamp
<clever>
zeta_0: yes
<clever>
ottidmes: you may read the json file in the middle of the json being written, and only get half the json data
<clever>
ottidmes: and use writes to a tmp file + rename() to atomicly update the json file
<clever>
ottidmes: and re-configure itself dynamically
<clever>
ottidmes: and then a thread in haskell (maybe using inotify) that will watch the json for changes
<clever>
ottidmes: for that, i would do something close to what hydra does, have a json file that details all machines
<clever>
ottidmes: ah, run nix-serve on each machine, then dynamically point cachecache to all of them
<clever>
ottidmes: then you just need some means of causing it to update, either errors and timeouts, or a servant+rest api
<clever>
ottidmes: but you could change it to be a TVar over a list, and then you can modify it or just read
<clever>
ottidmes: and 268 is a hard-coded list of caches
<clever>
ottidmes: 344 will try each one in turn, until one of them gives a narinfo, and 358 will try each in turn until one gives a nar.xz
<clever>
ottidmes: narinfo files are cached to ram, for faster lookup
<clever>
ottidmes: nar.xz files are cached to a dir, and it can query multiple upstream sites to find one
<clever>
ottidmes: currently, cachecache is close to just a dumb http cache, with a little bit of inteligence around the http/narinfo protocol
<clever>
ottidmes: nix-serve would convert a normal /nix/store into an http cache
<clever>
ottidmes: currently, cachecache only supports the http protocol
<clever>
ottidmes: you can add ssh://user@host as a substitutors
<clever>
Ilya_G: you can see containers.nix using %i everywhere
<clever>
Ilya_G: systemd will replace %i with bar within the .service files
<clever>
ottidmes: cachecache could be modified to dynamically change the list of upstream caches
<clever>
zeta_0: what happens if you simply `nix-shell '<nixpkgs>' -A haskellPackages.darcs.env` and try to `cabal configure` ?
<clever>
Ilya_G: basically, systemd.services."foo@" = ...; to define the template, and systemd.services."foo@bar".wantedBy to spawn an instance, i think