<clever>
ldlework: 3 paths, all under 1mb, all made ~2 minutes ago
<clever>
sqlite> select path, narsize/1024/1024 as narmb, datetime(registrationTime,'unixepoch') from ValidPaths where path like "%BindingAttributes%" order by registrationTime;
<clever>
ldlework: add a where path like "%BindingAttributes%"
<clever>
ldlework: or just remove the limit entirely, or invert the direction
<clever>
ldlework: you want to go the other direction
<clever>
ldlework: you set the limit to 1gig
<clever>
manveru: yeah, not that hard
<clever>
manveru: would need to trace nix-daemon though
<clever>
ldlework: that would be a nice improvement you could PR
<clever>
DariusTheMede: configuration-common.nix
<clever>
DariusTheMede: there is an overrides file in the same directory, so you dont have to edit
<clever>
DariusTheMede: hackage2nix
<clever>
ldlework: the example i gave limits to >256mb
<clever>
ldlework: youll need to adjust the size limitation
<clever>
ldlework: i'm not sure if there is an api to sort all paths by registrationTime
<clever>
ldlework: part of it is just learning the internals of nix in depth
<clever>
ldlework: its a caching mechanism, its expecting that you will paste the new hash into the nix expr, and then it will reuse the product it previously made
<clever>
pbb: pkgsCross is the cross-compile framework, to cross-compile from current to something
<clever>
ldlework: this will list everything in /nix/store over 256mb, sorted by when it was created
<clever>
sqlite> select path, narsize/1024/1024 as narmb, datetime(registrationTime,'unixepoch') from ValidPaths where narsize > 256 * 1024 * 1024 order by registrationTime;
<clever>
ldlework: if you remove the |tail, are there non-lock files?
<clever>
Ariakenom: ahh, its the ntfs that ships with linux itself
<clever>
you*
<clever>
ldlework: yep, your broke ls
<clever>
ldlework: `type ls` ?
<clever>
ldlework: what did you do to your ls? lol
<clever>
Ariakenom: then its the ntfs kernel driver, rather then the fuse one, what about `lsmod | grep ntfs` ?
<clever>
ldlework: can you pastebin `ls -ltrh /nix/store/ | tail` ?
<clever>
ldlework: the failed output is the only thing that wont be 1969
<clever>
ldlework: simplest thing is to check mod-times, ls -ltrh /nix/store/
<clever>
ldlework: so, it got renamed, and you have a different hash in /nix/store/
<clever>
2019-08-27 05:40:58 < clever> ldlework: but if a fixed-output drv fails due to a hash mismatch, the $out is renamed to match the hash it actually has
<clever>
ldlework: yep
<clever>
ldlework: 2019-08-27 05:46:18 < clever> ldlework: still in /nix/store/
<clever>
Ariakenom: grep ntfs /proc/filesystems
<clever>
near the top
<clever>
ldlework: then look at the outputs it lists
<clever>
Ariakenom: what does `man mount.ntfs` do?
<clever>
ldlework: what was the .drv file it was building? from the error?
<clever>
2019-08-27 05:40:58 < clever> ldlework: but if a fixed-output drv fails due to a hash mismatch, the $out is renamed to match the hash it actually has
<clever>
2019-08-27 05:40:21 < clever> ldlework: any time a build fails, the $out is left at the expected path, but not flagged as valid
<clever>
ldlework: still in /nix/store/
<clever>
ldlework: every derivation, including fixed-output, has a $out
<clever>
ldlework: it increments the number at the end if one is in the way
<clever>
so if you fix the expr, it will compute the new name it gets renamed to
<clever>
ldlework: but if a fixed-output drv fails due to a hash mismatch, the $out is renamed to match the hash it actually has
<clever>
ldlework: any time a build fails, the $out is left at the expected path, but not flagged as valid
<clever>
Ariakenom: run `id`
<clever>
Ariakenom: you would have to check the manual for the ntfs driver your using
<clever>
Ariakenom: the option may be uid=1234, cant remember exactly
<clever>
Ariakenom: that must be set to your own id
<clever>
Ariakenom: the uid=0 is the problem
<clever>
Ariakenom: does it show the difference in `cat /proc/mounts` ?
<clever>
Ariakenom: should be enough to umount and then mount again
<clever>
Ariakenom: something like options = [ "user=clever" ];
<clever>
Ariakenom: the user option needs a user to actually give access to
<clever>
Ariakenom: you also have to add a user= to the mount options, standard ntfs stuff
<clever>
ldlework: yes
<clever>
ldlework: nix-locate or ,locate on the bot
<clever>
marler8997: grep doesnt follow symlinks, and it depends on what version of nix your using
<clever>
vvbb[m]: or nix-build -A output && ls -lh result/
<clever>
vvbb[m]: nix-build -A simple && ./result/bin/simple
<clever>
vvbb[m]: if nothing has change with the code, it wont re-run it, and if you perfectly undo something, it can reuse a previous result!
<clever>
vvbb[m]: gist updated, you can now `nix-build -A simple` to build the program, or `nix-build -A output` to both build, and run it, producing a result/hello.png
<clever>
vvbb[m]: this builds with both `make` under` nix-shell` and also `nix-build
<clever>
teto: howoldis will link to the subset that must pass
<clever>
teto: the channel updates when the tests pass, and hydra has tried to build everything, the non-test stuff doesnt have to pass
<clever>
evanjs: nixpkgs-unstable also waits for darwin builds, so that can hold it back
<clever>
evanjs: which is newer?
<clever>
,howoldis
<clever>
emptyflask: then run `diff -r /nix/store/a /nix/store/b` to diff them, what differs?
<clever>
emptyflask: try building the repo on 2 machines (linux and mac), fixing the hash to match what it claims, then use nix-copy-closure to copy the paths to a single machine
<clever>
wtv_nick: yep
<clever>
wtv_nick: doing that (and undoing when your done) is not trivial on any other distro
<clever>
wtv_nick: i once ran into an issue with minecraft segfaulting in opengl, and it was fairly simple to just build a special opengl with debug print statements everywhere, to confirm where it was failing
<clever>
infinisil: thats how i convinced him to convert to nixos
<clever>
like, reinstall levels of unusable
<clever>
and i know somebody else, that did an upgrade on fedora, and it basicalled killed all of xorg, and made the machine basically un-usable
<clever>
but it only took seconds to pick an older generation in grub, to undo the whole upgrade
<clever>
wtv_nick: i recently began having problems with the whole machine locking up due to changes in the graphics drivers
<clever>
both config files, and actual packages
<clever>
thats not simple to do in a bash script
<clever>
so any change to an input will properly update all things that depended on it
<clever>
wtv_nick: all config files are built in a sandbox, and only have access to what they defined as inputs, and the output path is a hash of all of the defined inputs
<clever>
which you use depends on if kernel changes are involved, and if you broke it so badly that you cant even boot
<clever>
wtv_nick: you can either pick an older state from grub, or use `nixos-rebuild rollback`
<clever>
wtv_nick: ive bricked a few machines with `apt-get dist-upgrade`, but nixos lets you undo even major changes
<clever>
wtv_nick: the other major benefit, is that you can undo changes very easily
<clever>
ldlework: this is the main change i had to do, to make it build
<clever>
which lets you discover what it just dumped
<clever>
infinisil: this will list every store path over 256mb, sorted by when it was added to the store
<clever>
sqlite> .mode column
<clever>
sqlite> select path, narsize/1024/1024 as narmb, datetime(registrationTime,'unixepoch') from ValidPaths where narsize > 256 * 1024 * 1024 order by registrationTime;
<clever>
infinisil: if <nixos-config> doesnt exist, or is the wrong config (nixops for ex) it will copy the wrong file
<clever>
ldlework: you didnt use the no-preserve flag i gave earlier
<clever>
/nix/store/z955xygfz1c365nasjfbh4jhf0dnzsvf-dotnet-sdk-2.2.103/sdk/2.2.103/Microsoft.Common.CurrentVersion.targets(1128,5): warning MSB3191: Unable to create directory "obj/Debug/netcoreapp2.2/". Access to the path '/build/disinfo/Disunity.Disinfo/obj/Debug/netcoreapp2.2/' is denied. [/build/disinfo/Disunity.Disinfo/Disunity.Disinfo.csproj]
<clever>
so its imposible to tell which one is which in the errors
<clever>
ldlework: next minor problem, both derivations have the identical name