<clever>
reilithion: you can also `nix-instantiate -A gcc` to get the drv directly, for further testing
<clever>
reilithion: run show-derivation on that drv, and youll see the exact params the nix evaluated to
<clever>
builder for '/nix/store/54kqrpnlsgq6jqpdnwif4v7yylv4rjlj-gcc-7.4.0.drv' failed with exit code 2
<clever>
reilithion: what was the gist with the full build error?
<clever>
reilithion: you can also run `nix show-derivation /nix/store/foo.drv` on the drv that fails to build, to get more details
<clever>
reilithion: if that gets removed, it will likely break things
<clever>
reilithion: what about line 254, involving "--with-native-system-header-dir=${getDev stdenv.cc.libc}/include" ++
<clever>
> if true then "a" else if false then "b" else "c"
<clever>
> if false then "a" else if false then "b" else "c"
<clever>
> if false then "a" else if true then "b" else "c"
<clever>
> if true then "a" else if true then "b" else "c"
<clever>
reilithion: i'm guessing that --without-headers made something lack vital headers, and then a later package (probably gcc) gets upset over those headers being missing
<clever>
dacuna: if you mount /boot and nixos-generate-config, it will fix itself
<clever>
nixpkgs rev 34aa254f9eb also lacks 864
<clever>
though in your case, both users are on the same version of the channel
<clever>
you would have to nix-channel --update, as both users, to fully update things
<clever>
locallycompact: you have channels on both users, so that can add to the complications
<clever>
locallycompact: what does nix-info print?
<clever>
x
<clever>
dacuna: if the install is already done, then boot has to be at /boot/ and you may need to re-run nixos-generate-config to fix hardware-configuration.ni
<clever>
dacuna: when installing, /boot must be at /mnt/boot/, after putting the rootfs at /mnt/
<clever>
but fully declarative profiles are better
<clever>
Denommus: would be simpler to just set nixops = self.nixopsUnstable; with an overlay
<clever>
it just finds a "random" derivation with a matching name?
<clever>
i dont think -u cares about version# at all
<clever>
Denommus: so it just guesses nixpkgs.nixops, incorrectly
<clever>
Denommus: nix-env -u doesnt know what attr a package came from
<clever>
Denommus: but, `nix-env -u` doesnt really "upgrade" it just guesses what attr a given package comes from, and installs whatever nixpkgs says it is on the new version
<clever>
it agrees that 2.2 < 2.2.1
<clever>
> builtins.compareVersions "2.2" "2.2.1"
<clever>
> builtins.compareVersions "1.2" "2.2"
<clever>
ardumont: and i think you can just blindly run nix-build on that file to test it
<clever>
reilithion: i believe nix-shell still works against cross-compile deriations
<clever>
DigitalKiwi: the relative speed of that machiiiiiiiiine, compared to others in the list
<clever>
thomashoneyman: the man page should give a definite answer
<clever>
thomashoneyman: yeah
<clever>
noonien: so an attacker cant get the keys out of the TPM
<clever>
noonien: the TPM has a measured boot mode, where the hash of your efi binary must remain unchanged
<clever>
noonien: the only point of secureboot, is to stop malware from replacing your bootloader, and then blocking things like AV early on
<clever>
noonien: also, M$ signed binaries allow executing unsigned code, so any bios trusting the M$ keys effectively has secureboot disabled
<clever>
noonien: of note, there is an EFI function to query if secureboot is enabled, but its just a bool, and its trivial to fake its response if secureboot is off
<clever>
noonien: i tend to use the hostname, duplicate pool names (recovering, and putting one hdd into another machine) cause issues
<clever>
mikky: but the other package is using qmake, and doesnt bother asking libxml where it lives
<clever>
mikky: libisds runs xml2-config, a binary that can print out the correct -I flags
<clever>
checking for xml2-config... /nix/store/5rnvl1aknc6myvmip48achjy79q3iccr-libxml2-2.9.9-dev/bin/xml2-config
<clever>
mikky: *looks*
<clever>
mikky: but libxml is being stupid, and needs -I/usr/include/libxml2
<clever>
mikky: the problem is that nixpkgs is basically making -I/usr/include work automatically after packages are moved
<clever>
ajs124: i think thats enough reason to get it into nixpkgs
<clever>
ajs124: i have sometimes wanted to run it, to see what my bios is up to
<clever>
mikky: pkgconfig is the usuall fix for this, bug datovka doesnt attempt to use it
<clever>
libxml is mostly to blame, for putting the file in a subdir of include, and requiring you to -I/usr/include/libxml2, which is how they avoided conflicts between versions (the entire point of nix!!)
<clever>
mikky: but! the file is at /nix/store/foo/include/libxml2/libxml/tree.h!!!
<clever>
mikky: and your package is doing #include <libxml/tree.h>
<clever>
mikky: nix did -I/nix/store/foo/include
<clever>
mikky: pkgconfig and libxml are to blame
<clever>
AtomVelvet: building from source is almost always prefered
<clever>
mikky: can you pastebin the nix expression that is failing?
<clever>
mikky: check `echo $NIX_CFLAGS_COMPILE`
<clever>
mikky: it is, but it wont be visible on the cmdline when make runs things
<clever>
mikky: thats what NIX_CFLAGS_COMPILE is for
<clever>
so it should just ignore that entry
<clever>
mikky: nixos lacks a /usr/include dir, but g++ should check all of the -I paths
<clever>
mikky: is this on nixos or another distro?
<clever>
betawaffle: only real difference i noticed, is that `watch` wasnt the normal linux `watch`!
<clever>
betawaffle: i was recently helping a person migrate from a 4 disk jbod pool, to a 3 disk raidz on freenas, and we just did everything over ssh with normal zpool commands
<clever>
then i switched to a tmpfs, and it finished in 3 minutes
<clever>
i recently had some sqlite stuff take an hour, even with sync=disabled
<clever>
all of my nixos recent machines are on zfs, including the nas
<clever>
noonien: nix-store --query --tree result
<clever>
noonien: nix-build the package first, nix-build '<nixpkgs>' -A hello
<clever>
noonien: the size of the entire closure, and all of its deps sorted by size