<clever>
gluonix: installing things like gcc and make with nix-env isnt supposed to work, and will only cause problems
<clever>
,libraries gluonix
<clever>
gluonix: are you building in nix-shell? or nix-build?
<clever>
and rebuild the whole system from configuration.nix
<clever>
dumbuser: but if you did wipe /mnt/nix, it would re-download it all from the cache, and you would only loose the `nix-env -q` list and rollbacks
<clever>
dumbuser: most of the data comes from /mnt/nix/store
<clever>
dumbuser: because nixos-install is just a shell script to run nixos-rebuild inside a chroot
<clever>
and only gcc
<clever>
but i have seen gcc segfault before, when the battery in one of my laptops got really low
<clever>
not sure how it could cause that though
<clever>
and i'm not into abusing hardware like that :P
<clever>
which makes it rather hard to find out which socket it is, you would have to kick/drop the pc a few times for it to come loose again
<clever>
dumbuser: but just pushing the ram back into the socket all the way would fix it
<clever>
dumbuser: the ram socket was bad, and the ram would sometimes come a bit loose
<clever>
dumbuser: then it would be fine for years, until it receives a decent amount of vibration
<clever>
dumbuser: ive gotten PC's from walmart before that would bluescreen constantly until you reseat the ram
<clever>
dumbuser: have you ran a memtest recently?
<clever>
pumpy: yeah, its case sensitive
<clever>
dumbuser: yeah, you have to give it a device and name, like `cryptsetup open --type luks /dev/sda1 rootfs`
<clever>
pumpy: did you mount a filesystem to /mnt/boot/ ?
<clever>
dumbuser: cryptsetup open --type luks
<clever>
pumpy: try doing `sudo -i` first
<clever>
pumpy: thats just how bash and sudo work
<clever>
pumpy: sudo doesnt affect >
<clever>
dumbuser: if you mount your disk to /mnt, that will be your orignal config files
<clever>
dumbuser: nope, nixos-install will use whatever is in /mnt/etc/nixos/
<clever>
dumbuser: luksopen the device, mount it back to /mnt, and then nixos-install will rebuild it for you
<clever>
dumbuser: nixos-install is just a script to run nixos-rebuild in a chroot for you
<clever>
dumbuser: nope, just dont run any format commands
<clever>
dumbuser: luksopen, same as when you first installed it
<clever>
dumbuser: since you GC'd, there may be no simple way to undo things, the next simplest option is to just boot the installer again, mount your filesystems under /mnt like when installing, and re-run nixos-install, to rebuild it from a working system
<clever>
dumbuser: it also needs --check-contents
<clever>
dumbuser: try doing a `nix-store --verify --check-contents`
<clever>
dumbuser: thats weird for even bash to be segfaulting
<clever>
dumbuser: what does `coredumpctl | tail` say?
<clever>
dumbuser: what error does nixos-rebuild give?
<clever>
gluonix: not easily, since its basically just a hash of the input
<clever>
dumbuser: you can also just pick an older version from the grub menu
<clever>
dumbuser: nixos-rebuild --rollback will undo whatever you did last
<clever>
dumbuser: just change the nix-channel back to 20.03, same way you changed it to 20.09
2020-10-13
<clever>
nicolas[m]: the datadog package fails because the tests want apikeys, callHackage will re-create a duplicate of the package that is non-broken, then dontCheck fixes it
<clever>
siraben: you can give it a derivation too
<clever>
siraben: then nix will auto-generate a new derivation from scratch, based on what the .cabal file wants
<clever>
siraben: it can sometimes be simpler to just do `haskell-language-server = self.callCabal2nix "haskell-language-server" /path/to/src {};`
<clever>
yeah
<clever>
haskellPackages.mkDerivation is just a wrapper around stdenv.mkDerivation, that does some extra stuff to help haskell out
<clever>
siraben: while overrideAttrs mutates the args going into stdenv.mkDerivation, after haskellPackages.mkDerivation has done some mutations
<clever>
siraben: basically, overrideCabal lets you mutate the args that are going into the haskellPackages.mkDerivation function
<clever>
siraben: lib.haskell.overrideCabal
<clever>
to make it load that library, without a rebuild
<clever>
you can use LD_LIBRARY_PATH to force the other stuff to look in a certain directory first
<clever>
then you can just do the standard edit, make, ./run cycle
<clever>
chpatrick: if you want to debug things, you want to instead build it interactively under nix-shell
<clever>
chpatrick: nix strips all debug info by default
<clever>
chpatrick: why do you need ccache in that package?
<clever>
chpatrick: ccache cant function at all when using the sandbox
2020-10-12
<clever>
it started when the default ghc updated a few months back
<clever>
__monty__: does pandoc still function for you on master? i recently found problems where it blows the haskell heap, no matter how big you make it
<clever>
noonien: symlinks kind of mess with the ./foo logic in nix, it can wind up being relative to the wrong dir
<clever>
noonien: you can also create a dummy configuration.nix with just `{ imports = [ /path/to/real/configuration.nix ]; }`
<clever>
noonien: or use `nixos-rebuild switch -I nixos-config=/anywhere/you/want.nix` to just force it
<clever>
noonien: so you can use nix.nixPath to point it anywhere you want
<clever>
noonien: which defaults to /etc/nixos/configuration.nix
<clever>
noonien: oh, if your on nix, you dont want to create the tarball
<clever>
noonien: possibly
<clever>
rnhmjoj: thats more for building things on a remote machine, rather then just checking if it already has a built copy
<clever>
zanc: the nix-daemon on that machine, is what did `ssh user@hostname` as root
<clever>
zanc: on the machine where you ran `nix-env -i --substituters ssh://user@hostname`
<clever>
zanc: put a private key in /root/.ssh/id_rsa, that lacks a password, and can get into user@hostname
<clever>
zanc: nix-copy-closure ssh's from the current user, but `--substituters` will try to ssh from root, via the nix-daemon, which lacks your $SSH_AUTH_SOCK
<clever>
yeah
<clever>
eyJhb: if you go to the inputs tab on the build i linked, youll find a nixpkgs rev
<clever>
eyJhb: did you test on the same rev of nixpkgs as hydra did?
<clever>
eyJhb: nix-build '<nixpkgs/nixos/relese.nix>' -A nixos.manual.x86_64-linux
<clever>
eyJhb: the `nixos.manual.x86_64-linux` in the job name, is the attribute path, within nixos/release.nix
<clever>
fresheyeball: nix show-derivation on the .drv file
<clever>
addcn: you want `nix-shell -p libusb1` to use it
<clever>
addcn: `nix-shell '<nixpkgs>' -A libusb1` gives you a shell suitable for building libusb, not using libusb
<clever>
v0|d: which package did you get lsusb from?
<clever>
v0|d: lsusb for usb devices
2020-10-09
<clever>
astk: add an `echo` to it temporarily, and confirm if the echo runs
<clever>
exactly
<clever>
astk: is it before or after any if statements?
<clever>
yeah
<clever>
astk: yeah, near the top
<clever>
astk: you need the nix.sh line i pasted above
<clever>
try editing the .bashrc on the remote machine, to set $PATH correctly
<clever>
then your .bashrc needs more work
<clever>
astk: you can test it with `ssh user@host nix --version`
<clever>
astk: the installer tends to add it to the "wrong" file, and its only available for interactive shells
<clever>
if [ -e /home/clever/.nix-profile/etc/profile.d/nix.sh ]; then . /home/clever/.nix-profile/etc/profile.d/nix.sh; fi # added by Nix installer
<clever>
clever@c2d ~ $ cat .bashrc
<clever>
asheshambasta: that says that you should have 2 caches in your nix.conf, one of them being there twice
<clever>
asheshambasta: can you pastebin `nixos-option nix.binaryCaches ; nixos-option nix.extraOptions`?
<clever>
Fuuzetsu: but you can `export NIX_REMOTE=daemon` to force it
<clever>
Fuuzetsu: less overhead, it can just fork out the child workers directly, and modify /nix/store without using the RPC
2020-10-06
<clever>
eyJhb: you may be able to put just /etc/NIXOS_LUSTRATE into the file, instead of a whole dir
<clever>
if /etc itself was in NIXOS_LUSTRATE, then it wouldnt wipe /etc/NIXOS_LUSTRATE
2020-10-04
<clever>
sphalerite: yeah, that looks like the example got encoded into json
<clever>
sphalerite: on my end, the example value is proper nix
<clever>
Example: [ { x = 1600; y = 1200; } { x = 1024; y = 786; } ]
<clever>
dave8: sets must be key = value; pairs, not key : value,
<clever>
wave goodbye to any data you might have had on there!
<clever>
pjt_tmp: justdoit.nix itself, is a nixos module you would add to the ISO, then you simply boot, and run `justdoit` in a shell, and bam, /dev/sda has been wiped and installed
<clever>
pjt_tmp: this script will run nixos-generate-config, then overwrite configuration.nix, and it assumes a generated.nix and hardware-configuration.nix are nearby
<clever>
nicolas[m]1: that one only works within a nix file
<clever>
dsal: or use '<nixpkgs/nixos/release.nix>' to use the one in $NIX_PATH
2020-10-01
<clever>
pikajude: what does the setup hook do? read its source
<clever>
pikajude: manually `source ${foo}/nix-support/setup-hook` in some phase, but dont put it into buildInputs?
<clever>
mysql does that for example
<clever>
nh2[m]: so entrypoint can be a shell script to handle activation scripts, then run "$@" (what the user requested)
<clever>
nh2[m]: entrypoint and cmd, basically, the command that gets ran when you start it, will be "${entrypoint} ${cmd}", and by default, the cmd you specify elsewhere replaces cmd
<clever>
nh2[m]: i think it was entrypoint vs start? one of those lets you do these things
<clever>
numkem: i skimmed the git log a bit, and couldnt find it there either
<clever>
numkem: weird, i cant see how nixos is doing it...
<clever>
numkem: one sec
<clever>
gchristensen: MBR only having 8 bits for type codes made it rather difficult, when more then 256 filesystems came into existance, you cant give a unique id to each one anymore!
<clever>
its just describing the type of the contents, not how unique it is
<clever>
gchristensen: thats the same as how MBR has linux as type 0x83
<clever>
gchristensen: if you try to do a legacy (non-efi) grub install onto gpt, you need a "bios boot partition"
<clever>
gchristensen: part1 is "bios boot partition", part2 is "linux filesystem data" and part3 is "luks partition"
<clever>
then you dont have to update the hash constantly
<clever>
maurer: this would create a non-fixed derivation, that clones the original, then deletes things
<clever>
a different way: firmwareLinuxNonfree = super.runCommand "${super.firmwareLinuxNonfree.name}-patched" "cp -r ${super.firmwareLinuxNonfree} $out ; rm ... ";
<clever>
if you flip it back, it will use the old build
<clever>
maurer: you must supply a new outputHash in your override, or override it a different way
<clever>
maurer: its a fixed output derivation, so if nix already has a result for the given name&hash, it will never rebuild it, even when the build directions change
<clever>
maurer: run `nix edit -f '<nixpkgs>' firmwareLinuxNonfree` line 20