<clever>
nh2: note that the eval of the nix expr alone requires several gig of ram, and the resulting jobs need linux, darwin, and aarch64 build slaves, and at least 80gig of disk space
<clever>
nh2: that would be release-combined.nix
<clever>
aveltras: so the packages can inter-link
<clever>
aveltras: oh, right, you need to use the set that this override applies to
<clever>
nixos/release.nix is all of the nixos tests
<clever>
nh2: pkgs/top-level/release.nix is just the pkgs tree, which is probably what you want
<clever>
nh2: just eval it with nix repl, nix-build, or hydra-eval-jobs, or setup a full hydra
<clever>
aveltras: try fetchzip in source-overrides then?, i think source-overrides handles the cabal2nix for you
<clever>
aveltras: youll need a 2nd callHackageDirect based override to introduce that to your package set
<clever>
185 in self.callCabal2nix pkg (pkgs.fetchzip {
<clever>
nh2: everything hydra.nixos.org does goes to cache.nixos.org
<clever>
nh2: either that, or have a dedicated jobset made for your branch
<clever>
nh2: i'm thinking you can contact gchristensen and see about getting it tested better
<clever>
nh2: and i think thats the main purpose of the staging branch, to pre-test such things before master gets broken
<clever>
nh2: id let a hydra just build the entire release.nix
<clever>
the hash
<clever>
,tofu
<clever>
aveltras: you give it the name of a package, the version, and the sha256 of its tarball from hackage, and then it can operate without being present in all-cabal-hashes
<clever>
mla: nix-locate or the ,locate command on the bot
<clever>
yeah, overrides tend to do that
<clever>
still building...
<clever>
can you add all of the nix files to the github repo and link the branch?
<clever>
ah, heh
<clever>
i believe shellFor uses that behind the scenes, you could try it also
<clever>
something like nix-shell '<nixpkgs>' -A haskellPackages.servant.env
<clever>
srid: are you also using .env ?
<clever>
probably
<clever>
with a relative path
<clever>
you must run cabal2nix from the same dir the default.nix will exist in
<clever>
srid: is the src= correct?
<clever>
srid: is that listed in the cabal file? does it exist?
<clever>
srid: i just write a default.nix, that loads each cabal file with callCabal2nix and shoves them all into an overlay
<clever>
slabity: if the url hasnt changed, it will take up to 1 hour for it to check for changes
<clever>
nix show-config | grep tarball-ttl
<clever>
felixfoertsch: its definitely not in kernel space
<clever>
contrun[m]: you can add a shell.nix file, and still have it build without nix
<clever>
contrun[m]: you probably need to use a shell.nix file, but ive not delt with stack much
<clever>
contrun[m]: add more -v's
<clever>
werner291: newScope creates a new instance of callPackage
<clever>
werner291: everything under idris-modules is likely loaded that way
<clever>
thats a list of most things the bot can do
<clever>
,
<clever>
,callPackage werner291
<clever>
dansvo: the teamspeak client is an example of how its used
<clever>
taktoa nerd-sniped me into fixing that bug, which got me into nixos :P
<clever>
yep
<clever>
and chrome hangs silently when you try to libredirect it
<clever>
in that case, teamspeak is wrapProgram's to libredirect, and chrome was inheriting the redirect preload
<clever>
gchristensen: libredirect is the first nix bug i ever delt with, before even intalling nixos, lol
<clever>
dansvo: have you looked at libredirect yet?
<clever>
no more json middle-man!
<clever>
jlv: and hnix will properly deal with escaping all strings as it serializes to nix
<clever>
jlv: this will use cabal to parse a .cabal file, then packageToExpr to turn it into a { src = ...; dependencies = ...; } based set, and print it to "output"
<clever>
werner291: what do you get if you eval `idrisPackages.with-packages (with idrisPackages; [ contrib pruviloj ])` under `nix repl '<nixpkgs>'` ?
2019-08-15
<clever>
werner291: does the error say which line the problem is on?
<clever>
werner291: you probably want to use just $src, not ${src}
<clever>
werner291: your not using a recursive set, so lines 20 and 24 are referencing this package, not line 14
<clever>
> pkgs.src
<clever>
then fromJSON + readFile it, and use // or recursiveUpdate (or modules and mkMerge) to apply changes
<clever>
yeah, you probably want to just convert the ini into json (either one-time, or use a derivation and IFD)
<clever>
ah
<clever>
do you want to actually modify the config from nix? or just use the .ini file as-is?
<clever>
and what is the main reason to do that?
<clever>
jlv: what exactly are you trying to do?
<clever>
__monty__: there is a 32bit cache, but i dont think firefox is configured to build on it
<clever>
but with zero friends, you have a bootstrap problem
<clever>
__monty__: that might be a bug, where it doesnt tell systemd it has "started" until it connects to a friend
<clever>
__monty__: do you have a friend added in toxvpn?
<clever>
__monty__: *waves*
<clever>
lol
<clever>
pie_: i use xfce
<clever>
pie_: try not-kde?
<clever>
virtualbox cant emulate it either
<clever>
and qemu cant emulate gpu accel
<clever>
pie_: maybe kde has 3d composition enabled by default?
<clever>
it is
<clever>
pie_: switch to the serial port
<clever>
is the qemu menu bar available?
<clever>
pie_: what about `top` within the guest?
<clever>
pie_: `iostat -x 30`, and look at util%
<clever>
pie_: try 2gig?
<clever>
configuration is typically just /etc/nixos/configuration.nix
<clever>
pie_: line 9 is a normal nixos-rebuild, line 15 is build-vm
<clever>
and because its an ad-hoc module in imports, it doesnt show up in docs
<clever>
then it builds your config again, to make nixos (which wont error)
<clever>
but nixos-rebuild first uses your config to try to build nix itself (causing that error)
<clever>
pie_: build-vm will dynamically jam another module into your imports list
<clever>
pie_: ignore that, its why the option doesnt show up in the docs
<clever>
pie_: build-vm will build the entire nixos, then build a shell script, that runs nixos, in qemu, with the configured amount of ram
<clever>
and that script obeys the cfg you put in configuration.nix
<clever>
pie_: build-vm will build a script in qemu-vm.nix
<clever>
pie_: you set that in your configuration.nix, and it will adjust the shell script used when launching qemu
<clever>
pie_: runtime env?
<clever>
tjg1: yeah, looks like boot.loader.grub.extraInitrd is the best option, generate an initrd that contains the secret key (cpio -H newc) and then give that the path
<clever>
that answers the grub vs systemd question, one min
<clever>
tjg1: ah, then you dont want extraUtilsCommands
<clever>
pie_: MOAR things that dont show up in the docs!, but for a different reason
<clever>
lucus16: ah, and yeah, you are creating something with deps, the shell script
<clever>
lucus16: nix-store -rvvv foo.drv, as root, reveals it has dependencies
<clever>
found reference to 'y844c6i3l5ayhyv0g1as69dv3pwzmg3v' at offset '26'
<clever>
scanning for references inside '/nix/store/pxlfgb5qf1628ydbsrj8yqbnw5b0izzl-minecraft-forge-server-1.12.2-14.23.5.2838'
<clever>
lucus16: fixed-output drvs shouldnt have any dependencies
<clever>
lucus16: oh
<clever>
lucus16: i can reproduce the failure
<clever>
lucus16: i would expect that to just work
<clever>
alienpirate5: is it giving an error?
<clever>
lucus16: and what command are you running to cause the failure?
<clever>
alienpirate5: stdenv.mkDerivation will force all of its arguments down to just a key/value set, with strings as values, lists turn into space seperated strings
<clever>
alienpirate5: both work
<clever>
alienpirate5: the default configurePhase will run ./configure with the configureFlags