<clever>
omnipotententity: both will have to be patchelf'd to fix it
<clever>
zacts: /usr/bin/env exists when using nix-shell, so thats not a valid test
<clever>
qyliss: ah!
<clever>
avn: or just modify fetchurl to map "" to that
<clever>
,tofy
<clever>
looks like its fine
<clever>
sure
<clever>
and clang will be provided automatically
<clever>
zacts: just change stdenv to clangStdenv
<clever>
so you can then use them in something, like buildInputs
<clever>
the function arguments are needed to get the variables into scope
<clever>
nope
<clever>
the function arguments
<clever>
that will get you clang and llvm automatically
<clever>
if you want clang, then you want the clangStdenv.mkDerivation
<clever>
thats not the buildInputs
<clever>
zacts: is ruby in the buildInputs?
<clever>
zacts: which file has #!/usr/bin/env?
<clever>
risson: mkOrder only works on nixos options
<clever>
'';
<clever>
./build.sh
<clever>
patchShebangs .
<clever>
buildPPhase = ''
<clever>
zacts: patchShebangs . first
<clever>
zacts: buildPhase = "./build.sh";
<clever>
,unstable siraben
<clever>
Thra11: likely just a bug, it gets copied from /nix/store/ on the first boot
<clever>
so every time you reboot, you have to re-configure qtcreator to find the right qmake
<clever>
and there was a qmake wrapper (to support the other things in buildInputs), in /tmp/randompath/, which qtcreator needed
<clever>
so you had to wipe those temp files every time you reopen the shell
<clever>
laalf: it was also creating things in the current dir, and failing if they already existed
<clever>
laalf: which makes nix-shell difficult to use without root
<clever>
laalf: it was something like the configure hooks creating $out/share or something and adding it to a search path
<clever>
laalf: last time i looked, you had to run one of the configure hools before starting qtcreator, and it was a pain to deal with
<clever>
ldlework: .overrideDerivation
<clever>
ah
<clever>
m1cr0man: just find whatever file defines main(), build that by itself, and then chase the link errors to find out what else you need
<clever>
m1cr0man: ive sometimes given up on using the upstream build framework, and just rewrote it in cmake, lol
<clever>
but a lot just assume /nix/store/
<clever>
in theory, proper nix derivations should use this to get the store path
<clever>
> builtins.storeDir
<clever>
__monty__: youll get zero support from the binary cache, so it will take a lot longer to doooo antyhing, and a lot of things will break
<clever>
__monty__: its always in the form of <hash>-${name}, and name typically has -1.2.3 at the end
<clever>
__monty__: it is a variable set by nix, based on the name attribute on your derivation
<clever>
i would expect the usb drivers to not work under wine
<clever>
yunratobe: and if you do change the source with an override, nix will automatically know it needs to be rebuilt
<clever>
yunratobe: most of the time, its not nessesary, since the builds are so pure
<clever>
yunratobe: why do you want to force it to use src?
<clever>
switchy: yep
<clever>
so -I /foo will make it look for <nixpkgs> at /foo/nixpkgs
<clever>
switchy: its mostly like gcc -I
<clever>
switchy: nix-shell -I nixpkgs=~/nixpkgs
<clever>
arcnmx: run import on the drv
<clever>
jonreeve[m]: you probably want to store the result of fetchzip in a variable in a let block `let foo = fetchzip {...}; in ..`, then create a systemd service to load the data, `script = ''do-something-with ${foo}'';`
<clever>
jonreeve[m]: what are you trying to do with the files after you unpack them?
<clever>
jonreeve[m]: and the poorly named fetchzip will both download and untar for you, you could replace that entire thing with just a fetchzip call
<clever>
jonreeve[m]: the default unpackPhase will untar it for you, so just src src= on something and you can then use it
<clever>
jonreeve[m]: 99% of the time, you dont want to change builder.sh, the default one works fine
<clever>
jonreeve[m]: or change it around, with import <nixpkgs> {}; stdenv.mkDerivation { ....
<clever>
jonreeve[m]: a seperate nix file, and no ; at the end
<clever>
jonreeve[m]: everything inside the quotes for -E can also just be put into a nix file
<clever>
,callPackage jonreeve[m]
<clever>
but nix also leaves those 2 paths in /nix/store/ (as invalid paths) so you can just grep -r both yourself
<clever>
so it doesnt know which file is to blame
<clever>
Ralith: nix is serializing the entire dir into a std::string containing a nar, and then basically doing a grep against that whole string
<clever>
Ralith: yes, because nix doesnt know
<clever>
Ralith: and a path cant exist until its deps exist, so its imposible for nix to download such a loop
<clever>
Ralith: .out depends on .dev, and .dev depends on .out
2019-07-06
<clever>
melling: usually, master, and maybe ask to have it backported to 1903 after its merged
<clever>
not sure what nix run will do when you give it a file containing things
<clever>
so $out/bin doesnt exist, $out is a file!
<clever>
oh, and line 59, the installPhase for that derivation, just prints 2 strings to $out
<clever>
___laika: nix run will simply grab out (line 62) and put only that into $PATH
<clever>
___laika: nix-shell will basically put buildInputs and nativeBuildInputs into $PATH, and everything else from the env section becomes an env var
<clever>
nix-shell is the only way to get such a development shell right now
<clever>
wont work*
<clever>
___laika: definitely looks like thats meant for use with nix-shell, and work work via nix run
<clever>
WilliamHamilton: everything that generic-builder.nix accepts
<clever>
___laika: there is #nix-tools on irc
<clever>
dang, he left
<clever>
collision between `/nix/store/qgalsdxj9d55s403vhlw0lkz8bcvy1qw-git-2.22.0/share/info/git.info' and `/nix/store/8p3nm8rjr0rhaa2mqfz0zmzayxk9cn39-git-2.22.0/share/info/git.info'
<clever>
iqubic: lspci
<clever>
ggpeti: youll want to set it in nix.conf
<clever>
ggpeti: there is an allowed-uris in `nix show-config` that acts as a whitelist of impurities
2019-07-05
<clever>
BoipiSigre: or just eval it within a `nix repl`
<clever>
gyroninja___: what storepath is it trying to download?
<clever>
and hash.narinfo contains the relative path of the .nar.xz
<clever>
gyroninja___: /nix/store/hash-name is at hash.narinfo
<clever>
gyroninja___: if you put both the .narinfo and the .nar.xz into a folder, you can `nix copy --from file:///path/to/dir /nix/store/hash-name` to "download" it from that dir
<clever>
iqubic: if its not shown in `zpool status -v`, yes
<clever>
iqubic: you must resize the sda2 partition to occupy the entire disk, and then do online -e again
<clever>
iqubic: thats what the online command did
2019-07-04
<clever>
gyroninja___: how long did the download take?
<clever>
iqubic: zfs uses the names from `ls -l /dev/disk/by-id/` when it boots
<clever>
iqubic: thats the serial# for your drive
<clever>
iqubic: so you want `zpool attach wwn-0x5001b444a630bdbc-part6 /dev/sda2`
<clever>
iqubic: wwn-0x5001b444a630bdbc-part6 is the name of the device
<clever>
iqubic: the order is right, but zfs is calling sda5 something else
<clever>
iqubic: but zfs may have named it differently, check `zpool status -v`
<clever>
iqubic: the man page says its that way around
<clever>
zpool attach [-f] [-o property=value] pool device new_device
<clever>
gyroninja___: you generally want to just look at the packets, you should see push packets from fastly, and ack packets going back for each one
<clever>
gyroninja___: you generally want to right click the packets for this stream, and hit follow tcp stream to filter it
<clever>
gyroninja___: which end last sent a packet, and where any retries present?
<clever>
gyroninja___: check with wireshark to see if its actualy sending data the whole time
<clever>
gyroninja___: the error 9 is because the stream to unxz ended in the middle of the file