<clever>
then it will fail, and tell me the correct hash
<clever>
i typically put my editor into replace mode, and overwrite a few digits with 0's
<clever>
yeah
<clever>
so youve told nix that the source is identical to before
<clever>
you appear to have not changed the sha256 field
<clever>
is that the correct hash for it?
<clever>
what command did you use to install it afterwards?
<clever>
clementd: and you dont need the rec on line 4 either
<clever>
clementd: there is rarely any point in overriding the version
<clever>
yeah
<clever>
try removing that
<clever>
do you have virtualbox in your systemPackages?
<clever>
its more likely that your config is to blame them, what is colliding?
<clever>
nix-env, nix-channel and nixos-rebuild all have rollback options to undo things
<clever>
you can use `nix-channel --rollback` to undo the last update
<clever>
so the problem is that the scripts setting up $NIX_PATH dont eval $HOME correctly when ran via sudo
<clever>
using this, i can see a bare $HOME inside $NIX_PATH
<clever>
drakonis: sudo sh -c 'echo $NIX_PATH'
<clever>
drakonis: echo $NIX_PATH ?
<clever>
and what about just `sudo -i` followed by `nixos-rebuild boot` ?
<clever>
drakonis: which shell are you using and what command causes the warning?
<clever>
and do those also exist?, ls -lh /nix/var/nix/profiles/per-user/drakonis/channels/ /nix/var/nix/profiles/per-user/root/channels/
<clever>
can you paste both?
<clever>
what do they point to?
<clever>
what does this print?
<clever>
drakonis: ls -lh /home/drakonis/.nix-defexpr/
<clever>
drakonis: what is your normal user?
<clever>
even if you have zero channels on the user
<clever>
hence, running nix-channel --update
<clever>
drakonis: the warning is less about what your channels are called, and more that your non-root user has never ran nix-channel, so it lacks a channels directory
<clever>
worldofpeace: ive not tried changing the port, but you could abuse ~/.ssh/config to change the default port of that hostname
<clever>
worldofpeace: i would keep your own key as an extra backdoor, either set via configuration.nix extraUsers.root.authroized keys, or directly in /root/.ssh/authorized
<clever>
worldofpeace: and line 83 sets up the ssh -i flag to load the private
<clever>
if you decide to abandon nix1, you can just use fetchTarball directly
<clever>
elvishjerricco: fetchNixpkgs.nix is just an if statement to deal with nix 1.0 stuff
<clever>
worldofpeace: yeah
<clever>
elvishjerricco: which is why i unset NIX_PATH to audit the source for such mistakes
<clever>
angerman: fetchNixpkgs.nix, when working right, allows you to just `unset NIX_PATH`, then it has to be pure
<clever>
and not care about NIX_PATH at all
<clever>
elvishjerricco: i would prefer using -E or a shell.nix with nix-shell, then i can just import a fixed version directly
<clever>
worldofpeace: ive only ever used it on port 22
<clever>
and then eval it
<clever>
angerman: it will basically just jam together "with import <nixpkgs> { }; (pkgs.runCommandCC or pkgs.runCommand) \"shell\" { buildInputs = [ ", the args of -p (wrapped in parens) and then a }; }
<clever>
p_l: you want to use nixpkgs.config.packageOverrides to overwrite the package
<clever>
p_l: old contains the old attributes, so you can do old.postInstall
<clever>
p_l: when you do .overrideAttrs (old: { ...
<clever>
hyper_ch: same thing that was wrong yesterday
<clever>
a few months ago, i was building the opengl in /run/opengl-drivers from a custom checkout, and adding print statements to track down a segfault :P
<clever>
but nobody thought of that, and i was the only one to debug it far enough to figure that out
<clever>
the act of installing curl is what fixed it :P
<clever>
curl and wget gave identical binaries
<clever>
and forum posts showed people installing curl, re-running the script, and being confused as to why curl gives a different binary then wget
<clever>
i lacked curl, so i used wget, and then it broke :P
<clever>
and funnily enough, the "install script" just ran curl to download a naked .so file, and copied it to the right dir
<clever>
but, flash doesnt check for null pointers, and just segfaults all of chrome when it fails :P
<clever>
and the flash plugin in firefox opens curl with dlopen
<clever>
due to its flexibility, i was able to have a system without curl installed at all (though nix is better, because curl can be installed yet not exist)
<clever>
gentoo has also helped me learn similar things due to bugs years ago
<clever>
oh, patchelf also lets you inject things into DT_NEEDED
<clever>
but its not aware of dlopen
<clever>
which looks over everything in the DT_NEEDED field, and strips rpath entries you dont need
<clever>
the default fixupPhase will run patchelf --shrink-rpath
<clever>
it accepts a list and will give you a : seperated string
<clever>
> lib.makeLibraryPath [ curl ]
<clever>
instantepiphany: you need to generate paths yourself, and either re-add them to RPATH in postFixup, or wrapProgram with LD_LIBRARY_PATH
<clever>
if you load things at runtime with dlopen, then you need to do custom stuff
<clever>
the buildInputs stuff only handles compile-time linkage
<clever>
instantepiphany: $NIX_LDFLAGS also sets gcc flags to configure the rpath for binaries it produces
<clever>
$NIX_CFLAGS_COMPILE is used to inject -I flags
<clever>
and yeah, $buildInputs will be all inputs
<clever>
the gcc wrapper uses $NIX_LDFLAGS to inject -L flags
<clever>
your DE may have its own reload option
<clever>
the issue, is that it doesnt notice changes to old paths
<clever>
zgrep: for xfce, there is `xfce4-panel --restart` which will restart the panels, which then re-scan the original $XDG_DATA_DIRS
2018-07-29
<clever>
worldofpeace: when using the none backend, nixops will add its own keys to the config, so you just need an ssh agent or pw for the first deploy
<clever>
juhe: ls -lhd ~/.nix-profile/lib/qt*
<clever>
__monty__: now that that has been identified, i would hope that they can solve it, and make the benchmarks more pure
<clever>
Dezgeg: yep
<clever>
infinisil: and that adjusted the alignment of the stack, and basically all benchmarking and tuning for the last decade is wrong :P
<clever>
infinisil: some of the ghc benchmarks that have been running for years, have been discovered to have major error, because the stack is offset by the size of the env vars, and those where not cleared prior to testing
<clever>
infinisil: i have also heard that env vars have a measurable impact on performance
<clever>
> builtins.parseDrvName hello.name
<clever>
samueldr: i prefer to put version into a let block, using rec misleads people into thinking overrideAttrs can change the version
<clever>
michas_: if you define the bridge and its static ip in the nixos config, then i believe dhcpcd will ignore it
<clever>
michas_: ah
<clever>
michas_: what do you plan to do with the bridge?
<clever>
michas_: watch `journalctl -f -u dhcpcd` while creating the bridge
<clever>
michas_: dhcpcd will auto-detect any new interface, query it automatically, and when it fails to get a reply, assign a 169 addr
<clever>
samueldr: /proc will give you both cpu used per process and uptime, and with a bit of math, you can find %
<clever>
you read from hsSuper and return a set of changes
<clever>
i tend to name them hsSuper and hsSelf so it doesnt shadow the others
<clever>
line 5's super and self are the super and self of haskellPackages
<clever>
kalbasit: so you need to remove a .haskellPackages from lines 6 and 11
<clever>
kalbasit: line 6 is refering to the super on 5, not 1
<clever>
not sure, but at a glance, its using libalsa to adjust volumes, and the pulseaudio "driver" within alsa reroutes things
<clever>
i glanced at it nix expression and it currently does not depend on pulse
<clever>
smolboye: yes
2018-07-28
<clever>
prior to discovering that, i just forced shutdown and corrupted things :P
<clever>
jasongrossman: if you `grep Dirty /proc/meminfo` you can see how much remains
<clever>
jasongrossman: so things can "finish" rather fast, and then a sync call or umount will hang for 20mins
<clever>
jasongrossman: ive also had problems where linux tends to allow a massive write buffer for usb drivers
<clever>
jasongrossman: but yeah, if the usb drive re-orders writes, i could see that corrupting things
<clever>
jasongrossman: as long as the usb drive doesnt re-order writes, the immutable and ring based natures of zfs would just cause it to revert to an older state
<clever>
and zfs doesnt really timeout, so then zfs hangs
<clever>
sometimes my sata drive just doesnt respond to a read command, and the io call blocks
<clever>
the only real problem ive had, is mostly hardware to blame
<clever>
at least with zfs, it has checksums on all blocks, so such things are harder to go un-noticed
<clever>
jasongrossman: yeah, theres no way to know
<clever>
when did they get a flipped bit?
<clever>
but those files had passed thru at least 4 or 5 computers, ntfs, fat32, ext4, xfs, nfs, samba
<clever>
jasongrossman: they had 1 or 2, sometimes 3 flipped bits
<clever>
jasongrossman: so i hexdump'd both 300mb files (creating files in the gigs range) and ran diff -u on them, lol
<clever>
jasongrossman: many years ago, i discovered some duplicate files, that didnt have matching hashes
<clever>
Drakonis: ive found that swap on a zvol is unstable, but the rest seems fine
<clever>
jasongrossman: ive used virtualbox images on zfs to do a rollback of any os
<clever>
joepie91: :D
<clever>
coconnor: ive seen somebody try to do network in the activation script, that results in nixos failing to find systemd at bootup, lol
<clever>
so i just changed the channel, and nixos-rebuild
<clever>
i had GC'd my rollback options
<clever>
when confirming if something had been broken recently in the channel
<clever>
coconnor: i trivially downgraded from nixos-unstable to nixos-17.09 last week, and then went back to unstable
<clever>
?
<clever>
lunik1: and then mount.fuse handles the binary path and doing non-standard things
<clever>
lunik1: i think the key is that the fstype is fuse, so mount just runs mount.fuse
<clever>
lunik1: i found that in google a few months ago
<clever>
yep
<clever>
ejpcmac: no idea
<clever>
lunik1: absolute path to the mergefs binary
<clever>
ejpcmac: and when you do nix-env -iA nixos.foo, it looks for a channel called nixos, so you can just use a different name
<clever>
ejpcmac: the channels must have unique names
<clever>
lunik1: you probably need to use an absolute path in the fs config, check the link above
<clever>
lunik1: it may need to be added to systemPackages
<clever>
but it doesnt understand luks, so you still need to tell configuration.nix how to open the luks device
<clever>
daveo: nixos-generate-config would put the uuid's into hardware-configuration.nix automatically
<clever>
srid: an example of both
<clever>
> "${./.} ${builtins.toString ./.}"
<clever>
srid: if you call builtins.toString, then it will just return the absolute path without copying
<clever>
srid: if you use the path normall, it will copy the whole thing into the store, and return that storepath
<clever>
srid: nix will turn all paths into absolute automatically
<clever>
srid: ./. or ../.
<clever>
but then you also have to start dealing with all of the unsolved issues with running it without orot
<clever>
i would add a new option, that generates a startx helper script and auto-adds it to systemPackages
<clever>
ajs124: so you wont get any config if you disable all display managers
<clever>
ajs124: nixos puts the path to the xorg.conf file into the systemd unit for starting the displaymanager
<clever>
smolboye: i just fix the settings in xfce after i login, and dont care about the login page
<clever>
joepie91: nix is the answer :P
<clever>
tertle||eltret: yeah
<clever>
sir_guy_carleton: this will format the disk with GPT, for either legacy or uefi booting, with or without luks+lvm, and then format the rootfs with zfs, and install nixos
<clever>
if you use buildInputs, then only the first will work
<clever>
and you have to use absolute paths if you want to force 2 into the same env
<clever>
but each runhaskell is tailored to the deps of a single derivation
<clever>
not sure how to get the path to that from nix
<clever>
the derivation `callCabal2nix "name" ./path {}).env` will have a runhaskell in its $PATH
<clever>
actually, its not that exact path
<clever>
vaibhavsagar: if you use the runhaskell from "${(callCabal2nix "name" ./path {}).env}/bin/runhaskell" then it will have the deps path/name.cabal wanted
<clever>
vaibhavsagar: why do you want to merge several of those?