2018-02-12

<clever> genesis: derivations will never use packages you have installed manually
<clever> freeman42x[NixOS: something that just halts the virtual cpu, without saving the state anywhere, with the option to resume it shortly after
<clever> freeman42x[NixOS: it would have to be a suspend to ram within the vm software, not the guest
<clever> but it would obviously have to suspend to the host ram, and it wont survive a reboot of the host
<clever> freeman42x[NixOS: and in cases like that, the best you can hope for is to suspend the guest, while retrying the writes, until enough space is freed up
<clever> freeman42x[NixOS: and due to ext4 writing the metadata before the data, the data itself was lost
<clever> freeman42x[NixOS: ahh, and any writes that where pending at that moment where just thrown out
<clever> freeman42x[NixOS: this, for the most part
<clever> nix/store/dhmqrk1mj2kmkq81i67qjpwjd4jdaxp2-findutils-4.6.0/bin/xargs: cannot execute binary file: Exec format error
<clever> freeman42x[NixOS: plus the host OS for the VM may not obey the same rules about flushing data to disk, and could loose writes
<clever> freeman42x[NixOS: ext4 only keeps the metadata in a journal by default, so an improper shutdown can null out half of a file
<clever> freeman42x[NixOS: that can be done with `nix-store --verify --check-contents --repair` i believe
<clever> freeman42x[NixOS: you can fix them with `nix-store --repair-path /nix/store/foo`
<clever> freeman42x[NixOS: those are paths that got corrupted on-disk, probably due to not being fully written before the shutdown
<clever> freeman42x[NixOS: what does this command say?
<clever> freeman42x[NixOS: nix-store --verify --check-contents
<clever> freeman42x[NixOS: has the vm been improperly shutdown recently?
<clever> freeman42x[NixOS: anything interesting in dmesg?
<clever> ij: they didnt even implement that "only windows" thing properly, especially when we already have secure boot for just that kind of thing
<clever> ij: (facepalm)
<clever> ij: try changing the boot order in the bios itself, or use a key like f12 to pick a certain item
<clever> ij: what does efibootmgr show when ran?

2018-02-11

<clever> literally all it does, is what i did, plus disable the safety that caused the error :P
<clever> lol
<clever> 11 overrideCC = stdenv: cc: stdenv.override { allowedRequisites = null; cc = cc; };
<clever> this one works
<clever> nix-shell -E 'with import <nixpkgs> {}; let env2 = overrideCC stdenv gcc7; in env2.mkDerivation { name = "shell"; buildInputs = [ which ]; }' --pure
<clever> vcunat: there must be a subtle difference, because your variant was actually a hit in the binary cache
<clever> vcunat: and it fails to build the stdenv
<clever> output ‘/nix/store/qs71y5nvcwxqpzs6y3rw4xc6szib4qp0-stdenv’ is not allowed to refer to path ‘/nix/store/49pgxxi59f65xsffpfjlvdsl49ihq9hv-gcc-7.2.0-lib’
<clever> nix-shell -E 'with import <nixpkgs> {}; let env2 = stdenv.override { cc = gcc7; }; in env2.mkDerivation { name = "shell"; buildInputs = [ which ]; }'
<clever> vcunat: but youll need to use -E, not -p, since -p uses the original stdenv
<clever> vcunat: in theory, you can also do stdenv.override { cc = gcc7; } to create a variant that has gcc7
<clever> vcunat: this creates a variant of stdenv, that has no cc
<clever> stdenvNoCC = stdenv.override { cc = null; };
<clever> vcunat: one min
<clever> catern: id just generate a #!/bin/sh script that runs it on the main py file then
<clever> catern: double-check that that python actually solves the problem
<clever> catern: that nix-shell sets up PYTHONPATH automatically i believe
<clever> troydm: for a simple thing, you can probably just use "nix-shell -p stdenv" and then use gcc inside that
<clever> troydm: if you try to install gcc, it will just fail with errors like the one you gave
<clever> troydm: the compiler only works inside nix-shell and nix-build
<clever> troydm: are you building it inside nix-shell or nix-build?
<clever> hyper_ch: bit busy right now
<clever> as long as the namespace is configured to deal with that properly
<clever> and then mount it
<clever> or simply make a disk image with setuid root bash
<clever> you could potentially use a malformed disk image to buffer-overflow the kernel
<clever> aminechikhaoui: which doesnt allow you to mount things
<clever> aminechikhaoui: that just lies about what uid your running as
<clever> aminechikhaoui: so you have to run the whole thing in a linux vm, which gives you a fake root
<clever> aminechikhaoui: you cant mount a disk image via loopback, because the nix build lacks root
<clever> so adding a single config.something to the file disables the helper, causing the rest of the file to suddenly become invalid
<clever> if its missing all 3, nixos will automatically wrap it in config = { ... }; for you
<clever> all module modules must contain the following 3 keys, imports, options, config
<clever> that breaks the entire configuration.nix file, due to other weirdness
<clever> bkchr: nixpkgs.config.clementine.ipod = true;
<clever> TonyTheLion: and wrap it with another ( and ) because of how lists and functions interact
<clever> TonyTheLion: id add that to the buildInputs then
<clever> ottidmes: i think the foo variable gets passed in as $fooPath, which is a path to its contents
<clever> ottidmes: id still do that with <<EOF
<clever> ottidmes: just just stick to <<EOF then
<clever> ottidmes: depends, do you need to substitute any variables within it?
<clever> mkmk: also, genericBuild does unpack for you, so if your using that, thats the ONLY thing you run
<clever> mkmk: after unpackPhase, you must cd into the directory it produced, before you run patchPhase
<clever> mkmk: ah, sounds like you already got the patch working, is cmake in the buildInputs?
<clever> mkmk: id just copy the file in with a postPatch phase

2018-02-10

<clever> yep
<clever> nico202: there is no real difference between putting it all in a file, and using -E
<clever> nico202: you can just put the string inside the 'single quotes' into a default.nix and nix-build will use it
<clever> nico202: that will build the hello-world package, but fetch the source from .
<clever> nico202: nix-build -E 'with import <nixpkgs> {}; hello.overrideDerivation (drv: { src = ./.; })'
<clever> yeah, it can be ran without root and without sudo
<clever> dhess: it doesnt really care what user its ran as
<clever> dhess: yeah, mostly for impure things like stack2nix, or dealing with secrets
<clever> dhess: yep
<clever> dhess: yeah
<clever> dhess: it works well so far, and the queue times are far shorter then travis
<clever> dhess: that implies that you havent setup build slaves
<clever> dhess: what error did you get?
<clever> dhess: i would expect the error to be obvious
<clever> dhess: that option defaults to the same arch as the nix binary that is being used to eval the expressions
<clever> delta_: i dont think its documented anywhere
<clever> thats normal, side-effects of how build-vm works
<clever> it will error, then build normally
<clever> and it wont be in the auto-generated docs due to how build-vm works
<clever> delta_: its only valid in configuration.nix when using build-vm
<clever> delta_: its just a normal nixos option you set in the configuration.nix
<clever> dhess: if you hit blame, that has been there for 3 years
<clever> dhess: all it does is run nix-prefetch-git as the hydra user, no sandboxing involved
<clever> error: Package ‘hydra-2017-09-14’ in /nix/store/1ja644zdbff4n0zxpa7p3w40vqj8lxh7-nixpkgs-18.03pre118668.0e4be9e5f0/nixpkgs/pkgs/build-support/release/nix-build.nix:151 is not supported on ‘x86_64-darwin’, refusing to evaluate.
<clever> it may
<clever> so you can start spraying builtins.trace and lib.traceShowVal all over your code
<clever> dhess: this does a hydra eval, without installing hydra
<clever> dhess: let me grab one other handy thing
<clever> but its a different rev then what the nix refers to
<clever> nixops is being passed in via the hydra inputs
<clever> iqubic: run ls on both paths, which one doesnt exist?

2018-02-09

<clever> so "sudo nix-store --delete" will never work
<clever> sudo also causes false positives, because sudo is "using" the path, while waiting for nix-store to delete it
<clever> typetetris: its either running directly, in an open file handle, or in an environment variable
<clever> typetetris: then its in-use by a running program
<clever> typetetris: what does nix-store --delete say about that path?
<clever> typetetris: nix-store --query --roots
<clever> ij: 2017-03-20 12:45:56< niksnut> if you urgently need a log, you can find them at URIs like: https://cache.nixos.org/log/l9qmwi2q0dk4ji8pcycc188gank0q5pb-pointedalternative-0.1.0.0.drv
<clever> ij: one min
<clever> ij: youll want to view the build log for that derivation
<clever> ij: the configure script may have chosen to not enable it
<clever> lexooohhh: by default, it uses the version of nixpkgs you currently have
<clever> lexooohhh: if you specify the nixpkgs revision, and block access to config.nix, it will be a lot more reproducible
<clever> if you used nix-env instead of nix-build, it would be added to the profile
<clever> and yeah, file a PR to make the fix go public
<clever> ldlework: and result is a symlink to that path
<clever> ldlework: you can run "nix-env -i /nix/store/hash-foo" on a storepath to add it to your profile
<clever> ldlework: look in the result/bin/ directory to see the binary, and confirm it works
<clever> ldlework: nix-build doesnt install things, it only builds
<clever> and try to just build it
<clever> ldlework: if you add a second --arg config like this, it will just ignore the platform list
<clever> [clever@amd-nixos:~]$ nix-build '<nixpkgs>' -A oraclejdk --argstr system x86_64-darwin --arg config '{ allowBroken = true; allowUnfree = true; }'
<clever> on the mac machine
<clever> ldlework: if you have a fork of nixpkgs already, just edit the platforms array for the package, and then run nix-build -A foo in the root of the nixpkgs clone
<clever> ldlework: ah, one sec
<clever> hyper_ch2: and if you mess up the dhcp config, it reboots itself and restores control to the original OS
<clever> hyper_ch2: mainly, you want to stop it over ssh, to confirm you have control of the machine
<clever> ldlework: this downloads the darwin build of coreutils from the binary cache
<clever> ldlework: nix-build '<nixpkgs>' -A coreutils --argstr system x86_64-darwin
<clever> hyper_ch2: that would stop it fully
<clever> hyper_ch2: systemctl stop autoreboot.timer
<clever> hyper_ch2: 2 minutes ago, it would have given a warning to every open tty, and you could run `shutdown -c` to abort, and 5 minutes after that warning, it reboots
<clever> hyper_ch2: 5 minutes after the end of the hour
<clever> hyper_ch2: ah, then it wont fire
<clever> hyper_ch2: but if your starting from a decade old debian
<clever> hyper_ch2: its more predictable, when you can boot the same systemd and look at the names
<clever> without it, you get something starting with enp, that refers to its exact bus position
<clever> with that set, you get eth0 and eth1
<clever> that changes how systemd renames things
<clever> hyper_ch2: also, beware of the auto-reboot, its due in 50 seconds
<clever> :D
<clever> wb
<clever> fearlessKim[m]: but if your using something like network manager, it probably wont be
<clever> fearlessKim[m]: its already in PATH if you are using dhcpcd
<clever> fearlessKim[m]: manually run dhcpcd on the interface
<clever> and its only really of use in weird situations where nix isnt aware of how you are making it valid later
<clever> yeah
<clever> Lisanna: i need the path it unpacks to
<clever> Lisanna: yeah
<clever> klntsky: yeah
<clever> nice
<clever> Lisanna: nix doesnt understand compression
<clever> Lisanna: line 112, that squashfs is a compressed copy of toplevel
<clever> ah
<clever> hyper_ch: it copies it from the host, just before it kexec's
<clever> hyper_ch: have you seen /ssh_pubkey?
<clever> nice
<clever> so if sandboxing is correctly enabled, it will never see the files
<clever> those paths wont be added to the nix sandbox
<clever> it may also break build-time
<clever> if those scripts didnt exist, it would fail at runtime, because the path doesnt exist
<clever> and i have scripts that mount it to /nix at bootup
<clever> i'm already embeding my own copy, in the form of a squashfs containing the entire thing
<clever> so when you copy the product around, its copying the OS around twice
<clever> Lisanna: it would also become a runtime dependency
<clever> Lisanna: and that contains the path to the toplevel package
<clever> boot.kernelParams = [ "systemConfig=${config.system.build.toplevel}" ];
<clever> without the discard, nix will include a second (uncompressed) copy of the entire os
<clever> Lisanna: and that build is going to be supplied elsewhere
<clever> Lisanna: the kernel params in here, must refer to the final build of nixos, that becomes /run/current-system
<clever> Lisanna: one min
<clever> Lisanna: and when that string it placed into another derivation, nix combines the context from every string, to form the build-time deps of the new derivation
<clever> Lisanna: yep
<clever> Lisanna: yes
<clever> Lisanna: every string in nix has some context attached to it, that says what derivations it depends on
<clever> Lisanna: it discards the string context
<clever> nixos: haskell.packages.ghc802.ghc-mod
<clever> Lisanna: probably
<clever> yet the code is in nixpkgs
<clever> its in the nixos manual
<clever> Lisanna: i think so
<clever> Lisanna: it uses a function inside of nixpkgs to do the work
<clever> Lisanna: there are already tools in nixos to do exactly this
<clever> Lisanna: why are you trying to copy paths like that?
<clever> Wizek: instead, try doing "${fetchFromGitHub { ... }/foobar" to make a path to the subdir, then pass that to cabal2nix
<clever> Wizek: cabal2nix may not even find the cabal file at that point
<clever> Lisanna: a variant of sed may work
<clever> ldlework: add something to the url, like ?1
<clever> Wizek: as a parameter to the derivation that is using the source
<clever> Wizek: you need to append to sourceRoot, postUnpack = "sourceRoot+=/cborg; echo source root reset to $sourceRoot";
<clever> there is also the nix-hash command, and its man page
<clever> yeah, bit i dont have that table memorized
<clever> i forget
<clever> base32 or base64
<clever> depends on how its encoded
<clever> this one also includes an example hash
<clever> !tofu
<clever> !tufo
<clever> Lisanna: have you verified that?
<clever> Lisanna: i think LD_LIBRARY_PATH has priority
<clever> Lisanna: i think the -L search path automatically gets added during linking

2018-02-08

<clever> all but the last one
<clever> rardiol1: -d deletes all generations from the profiles it has access to, so root can matter
<clever> rardiol1: "nix-collect-garbage" and "sudo nix-collect-garbage" are identical
<clever> Ralith: in the case of lacking a rescue netboot, kexec is the only way to umount the drives and repartition the machine remotely
<clever> so you could boot into the provided "recovery" system, then kexec your own better recovery
<clever> lewo: nixos-install isnt garanteed to work from debian, but kexec should
<clever> hydra_: i think it depends on the version of hydra
<clever> hydra_: try it with a non-local build slave
<clever> hydra_: it gets a local lock file, then tries to build it over ssh to itself, which waits on that lock file
<clever> hydra_: localhost has some deadlock issues
<clever> hydra_: other then localhost?
<clever> hydra_: and you have build slaves configured?
<clever> hydra_: do any of your jobs need the kvm feature? or others
<clever> yep
<clever> now the size is all that remains
<clever> and just to double-check, see what print says about the start after formating things
<clever> 403134464 sectors from the start
<clever> ndrei2: fdisk should accept a start in mb
<clever> hydra_: the supportedFeatures entry under buildMachines
<clever> ndrei2: so that luks header is at 196843 MB
<clever> exactly 192gig and 235mb
<clever> so the 192 i gave before should have found it
<clever> and puts it near 192.22
<clever> which aligns with the previous ~37.22
<clever> thats now ~2.22 gig after the start
<clever> ndrei2: what dd command was used, and what offset did it find?
<clever> hydra_: what features have you enabled on your build slaves?
<clever> has it been found again with a different offset?
<clever> ndrei2: dd may use 1000 based units for 1G, rather then 1024 based
<clever> mostly just confirming things havent been typoed somewhere
<clever> ndrei2: what about a skip of 190 or 180?
<clever> and what device path are you using?
<clever> `dd if=<device> bs=1G skip=192 | hexdump -C | grep LUKS` and wait some, it should be within half a gig
<clever> ndrei2: what about the 192 i gave above?
<clever> ndrei2: http://tomb.dyne.org/Luks_on_disk_format.pdf page 6, this describes what that header contains
<clever> ndrei2: yeah, i believe thats right
<clever> ndrei2: the 192 i gave above will get you within 1 gig
<clever> ndrei2: you could, but it helps to double-check things by narrowing it in with dd first
<clever> ndrei2: keep narrowing in, and also try to switch to bs=512 when you get close (youll need to bump skip up by a factor of *2097152
<clever> ndrei2: you should get a much smaller number
<clever> ndrei2: as an example, try dd if=<device> bs=1G skip=192 | hexdump -C | grep LUKS
<clever> ndrei2: then the data is 150gig + 0x94eb00000
<clever> ndrei2: and that spit out 94eb00000 ?
<clever> ndrei2: does it show at an offset of 0 when you use the skip on dd?
<clever> ndrei2: you have to divide by 512 decimal, which is 0x200 hex
<clever> pkill9: its set globally if xorg is enabled in nixos
<clever> pkill9: so programs compile against a generic mesa library, then the right one is swapped in at runtime
<clever> pkill9: nixos handles that by putting /run/opengl-driver/lib into LD_LIBRARY_PATH
<clever> nix-store -qR /nix/store/8234spbxwzj9ndlnrydq4z2v0s9q1zzl-toxvpn-git.drv) | xargs du --max=0 -h | sort -h
<clever> because the sort at the end will fix it up anyways
<clever> xargs should work
<clever> surprisingly, those build and work on darwin
<clever> pikajude: try the du from nix-shell -p coreutils
<clever> pikajude: and then run this command on that .drv file
<clever> [clever@amd-nixos:~/toxvpn]$ du --max=0 -h $(nix-store -qR /nix/store/8234spbxwzj9ndlnrydq4z2v0s9q1zzl-toxvpn-git.drv) | sort -h
<clever> pikajude: what is the root .drv after it does all the evals?
<clever> pikajude: what does "du -h" say?
<clever> pikajude: do you have any src = ./. in your expression?

2018-02-07

<clever> need context, add -C10 to the grep command
<clever> ndrei: its only valid if its at the start of a 512 byte block, so thats a false hit
<clever> the LUKS should be at the start of a 16 byte wide block
<clever> that doesnt sound like it
<clever> ndrei: take that hex number, divide it by 512, then create a partition at that sector
<clever> ndrei: which command found it, and what exactly did it output?
<clever> ndrei: nix-env -iA nixos.testdisk && man testdisk
<clever> ndrei: id just leave the grep running longer
<clever> some filesystems will unsparsify when copying between them
<clever> i think the nixos config doesnt force a redirect for the .well-known directory?
<clever> ndrei2__: is there still a partition at the offset for the ntfs fs?
<clever> ndrei2__: and alt+f1 lets you watch the grep again
<clever> you have to read fdinfo to get the info
<clever> watch -d cat /proc/1417/fdinfo/3
<clever> this will let you see the progress
<clever> ndrei2__: ls -l /proc/1417/fd/, which symlink is pointing to the nvme drive?
<clever> ndrei2__: what PID is the grep process?
<clever> ndrei2__: alt+f2 to change to tty2
<clever> ndrei2__: what PID is the grep process?
<clever> ndrei2__: one sec
<clever> ndrei2__: ah, that complicates things then
<clever> ndrei2__: do you know how big that filesystem was?
<clever> ndrei2__: what was using the 0 to 40% range?
<clever> and how big it is
<clever> ndrei2__: depends on what position you put the luks partition at
<clever> Ndrei2: divide by 512 i believe
<clever> i can confirm that my luks starts with that header
<clever> [root@system76:~]# hexdump -C /dev/nvme0n1p2 | head
<clever> 00000000 4c 55 4b 53 ba be 00 01 61 65 73 00 00 00 00 00 |LUKS....aes.....|
<clever> Ndrei2: allowing the partition editor to use the same alignment it previously used
<clever> Ndrei2: you can also try creating the 1st /boot one overly large, then use mount -o ro to find its real size, remake it at that, then make another after it, overly large, repeat