2019-03-11

<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> reilithion: what did you change?
<clever> noonien: go ahead :)
<clever> (and nixops has to set that, to make nix-copy-closure work)
<clever> ah, i was thinking of NIX_SSHOPTS, but only nix-copy-closure obeys it, nixops doesnt
<clever> noonien: but there should be another fix that just involves env vars...
<clever> noonien: the proper fix, would be to add PubkeyAuthentication=yes at https://github.com/NixOS/nixops/blob/28231a177d751e800af3223a8763ea75b0ef9dd9/nixops/ssh_util.py#L48-L50
<clever> noonien: let me check something...
<clever> slap a -r on the end, and jq prints it without escaping the \n's
<clever> noonien: this exposes the private key to ssh into my router
<clever> nixops export -d house | jq '."ca55b021-87f5-11e8-b6f5-024225fad90e".resources.router."none.sshPrivateKey"'
<clever> noonien: you can also see them with nixops export
<clever> noonien: in the sqlite db
<clever> and youve disabled it!
<clever> noonien: nixops specifies a privkey with -i, and uses that to get into everything
<clever> noonien: oh, that will definitely break it
<clever> noonien: not much
<clever> reilithion: what about just `nix-build -A gcc` ?
<clever> max-jobs, and build-cores
<clever> both can also have defaults set in nix.conf
<clever> and the remote builders can have a different build-cores in their local nix.conf files
<clever> noonien: do you want nixops to get a linux build slave, or to use nixops for testing things?
<clever> noonien: it may just be that the guest hasnt finished booting yet
<clever> linarcx: run nix-build on this file, https://gist.github.com/cleverca22/d69a156a99848029f2225419bf63e7cd
<clever> linarcx: or you can: nix-build '<nixpkgs>' -A i3blocks -o i3blocks ; ls -lh i3blocks/libexec/i3blocks/disk
<clever> linarcx: that has to be in a nix script, that generates the bash
<clever> > "${i3blocks}/libexec/i3blocks/disk"
<clever> charukiewicz: https://nixos.org/nixops/manual/#opt-deployment.ec2.ebsInitialRootDiskSize
<clever> charukiewicz: one min
<clever> noonien: nixops itself works great, but ive heard that the virtualbox backend has a lot of trouble
<clever> noonien: try the nixops deploy again?
<clever> noonien: what happens if you just `ssh -v root@192.168.56.104` ?
<clever> noonien: yeah, every file you padd to `nixops create` gets merged
<clever> it doesnt have to exist to start editing
<clever> reallymemorable: just run any text editor on the file
<clever> reallymemorable: just create it
<clever> slabity: what about `machinectl show myc -p Leader` ?
<clever> slabity: it will use machinectl to find the leader of the container
<clever> 220 my $s = `machinectl show "$containerName" -p Leader`;
<clever> but it first needs to find the pid of the leader, via getLeader
<clever> 264 exec($nsenter, "-t", $leader, "-m", "-u", "-i", "-n", "-p", "--", @args);
<clever> 344 elsif ($action eq "root-login") {
<clever> 345 runInContainer("/nix/store/c4w7l847prnan6zzhx718c788bdkrg02-shadow-4.6-su/bin/su", "root", "-l");
<clever> noonien: hydra will use nix to build everything in a given release.nix file when changes occur
<clever> noonien: this daemon will monitor the hydra load, and dynamically create/destroy machines using nixops
<clever> and its late now, i should get off to bed
<clever> pretty much :P
<clever> pie_: that shows all the changes needed to switch it to stdenv
<clever> pie_: i was greeted with that one day, when i tried to .overrideDerivation, and it didnt work right
<clever> pie_: that is what nixpkgs used, before stdenv.mkDerivation
<clever> pie_: have you seen builder defs?

2019-03-10

<clever> if your using a custom builder on A, then propagatedBuildInputs wont work
<clever> noonien: and propagatedBuildInputs only works if A runs the fixup phase
<clever> noonien: yeah, B will also have python available, if your using the stdenv builder
<clever> that can also work, just dont source the stdenv from it
<clever> noonien: you can still put it into the buildPhase
<clever> noonien: use buildPhase = '' ...''; in the derivation
<clever> noonien: 90% of the time, you dont want to set builder, it just makes things harder for you
<clever> noonien: you must patch and run the copy in .
<clever> noonien: the unpackPhase copies it from $src to . for you
<clever> ggpeti: if done properly, maintainer wont have any impact on the stdenv
<clever> ggpeti: and the local machine will download from https://cache.nixos.org/
<clever> ggpeti: that means build slaves will have a copy of things pushed over from the current machine
<clever> ggpeti: nix show-config | grep sub
<clever> ggpeti: is the binary cache enabled?
<clever> and then ls its result symlink
<clever> build the thing your expecting the header to be in
<clever> Guest44936: pkgconfig can deal with that, so try adding pkgconfig to the nativeBuildInputs
<clever> Guest44936: the problem is that its it needs -I${SDL2_image}/include/SDL2 because SDL2 is being dumb
<clever> SDL_image.h
<clever> [root@router:~]# ls result/include/SDL2/
<clever> [root@router:~]# nix-build '<nixpkgs>' -A SDL2_image.dev
<clever> rprije: ah, cant think of one for that
<clever> rprije: nix show-derivation
<clever> slack1256: not much if both actions happen on the same machine
<clever> which adds a .override to every attr
<clever> the correct solution, is to switch nixpkgs to callpackages
<clever> thats what you will need to do
<clever> > (libav_all.override {}).libav_11
<clever> simpson: callPackages was not correctly used, so .override only exists on libav_all
<clever> 10642 libav_all = callPackage ../development/libraries/libav { };
<clever> 10643 inherit (libav_all) libav_0_8 libav_11 libav_12;
<clever> 10641 libav = libav_11; # branch 11 is API-compatible with branch 10
<clever> thats usually enough to make nix-shell also work without a shell.nix
<clever> laas: write the file such that `nix-build` or `nix-build -A foo` is enough to build the project
<clever> laas: and for some projects, default.nix also functions as a usable shell file
<clever> laas: i would also ensure the default.nix is doing callPackage
<clever> laas: create a shell.nix that uses callPackage

2019-03-09

<clever> infinisil: one or 2
<clever> and obviously, have the same fallback as generic-builder.nix
<clever> runhaskell is in the same output as ghc
<clever> infinisil: ive also been considering weather i should just compile Setup.hs, or always runhaskell it
<clever> it would have to be a bash script
<clever> but an alias wont cover `ghcid -c "cabal repl"`
<clever> infinisil: so it becomes invisible to the user
<clever> infinisil: ive been wanting to put a bash alias, to map cabal to `runhaskell Setup.hs`
<clever> and nix-serve can just serve /nix/store/
<clever> and nix-push/nix copy, can create a dumb directory, that you can then host on anything you want
<clever> mog: instead of importing <nixpkgs> import (builtins.fetchTarball URL)
<clever> Orbstheorem: same reason i use zfs, so i can `zfs send` my non-mirrored machines (pure nvme) to the nas
<clever> and linux just waits for it to finish, forever
<clever> the entire SSD will just randomly hang in the middle of a write operation sometimes
<clever> Orbstheorem: but those problems persisted even after switching to zfs, and where eventually tracked down to SSD firmware bugs!
<clever> Orbstheorem: ive used it before, but ran into problems
<clever> Orbstheorem: zfs, and yeah
<clever> Orbstheorem: my laptop and desktop run purely from nvme, the NAS though has several tb of storage, so the nvme is cache
<clever> and deleting the result link nix-builds, makes them broken
<clever> nix's GC will clean up the broken links
<clever> noonien: any that have finished building will be in /nix/store and wont be rebuilt
<clever> noonien: yeah
<clever> pie___: i usually start with -vvvv
<clever> which is just a small text file
<clever> it has to generate B.drv
<clever> stdenv.mkDerivation is a function that generates a .drv
<clever> yeah
<clever> alone*
<clever> noonien: the hash of A is based on the .drv files along
<clever> and the hash of some of that data, is what $out is computed from
<clever> yep
<clever> noonien: `nix show-derivation /nix/store/foo.drv`
<clever> noonien: if A is already in the binary cache, it can skip downloading B
<clever> ekleog: add more -v's
<clever> noonien: and its not legal for a cache to have A but not B
<clever> noonien: it will try to fetch B from the cache first
<clever> noonien: its basically all strings at that point
<clever> noonien: yep
<clever> including the buildInputs=value;
<clever> every key=value in the derivation arguments
<clever> noonien: its a hash of the serialized .drv file, which includes the paths to its inputs, and the build instructions
<clever> Shouou: its easy to miss, i didnt even see it when you pasted the error
<clever> Shouou: the review commend says fetchFromGitHub, not fetchFromGithub
<clever> Shouou: can you pastebin your files?
<clever> Shouou: you want `nix-build -E "with import <nixpkgs>{}; callPackage ./default.nix {}'`
<clever> ,callpackage Shouou
<clever> dacunap: grub or systemd?
<clever> dacuna: those are supposed to be there, a new one is added every time you nixos-rebuild
<clever> dacuna: so nixos never knows about /boot/
<clever> dacuna: this problem happens if you nixos-generate-config before you mount /mnt/boot when installing
<clever> dacuna: it will persist, so you only need to do that kind of thing if you later add more FS's you want mounted on boot
<clever> dacuna: yep
<clever> dacuna: yeah
<clever> locallycompact: http://howoldis.herokuapp.com/ nixos-unstable is 4 days old
<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> mog: https://github.com/cleverca22/nix-tests/tree/master/module-example is an example of how to use the module system yourself
<clever> mog: line 27 will fail to find moreInputs
<clever> jpaus: this configures a virtualhost, sets up an http->https redirect, and configures certbot+nginx to use lets encrypt
<clever> jpaus: nixos automates the nginx and certbox config with a single flag
<clever> thats 2 attrsets, being merged with the // operator
<clever> mog: imports is only for modules, but stdenv.mkDerivation doesnt involve modules
<clever> mog: personalFile = ./personal.nix; could also be in the main let block, no real need to nest them
<clever> mog: you put personal= into elixir's arguments, not the let block
<clever> mog: line 6-13 is a single attribute set
<clever> mog: and what error does that file give?
<clever> mog: can you update the gist with that version of the file, and include the error?
<clever> and 13 looks useless right now
<clever> mog: line 20 will cause similar problems, move it up into the let block on line 2
<clever> mog: you can use builtins.pathExists directly
<clever> "cannot coerce a built-in function to a string"
<clever> and stdenv.mkDerivation then tries to convert everything to a string
<clever> mog: you are passing builtins.pathExists to stdenv.mkDerivation
<clever> mog: line 19 is your problem
<clever> mog: can you add all the files to a gist?
<clever> its parsing as: ([ foo ] ++ import) personal pkgs;
<clever> ] ++ (import personal pkgs);
<clever> mog: you need more ()
<clever> mog: what error does it give?

2019-03-08

<clever> > builtins.unsafeGetAttrPos "linuxPackages_latest" pkgs
<clever> ,tofu
<clever> yl: ah, those env vars are better
<clever> yl: examples are in nixpkgs
<clever> yl: look into libredirect
<clever> nix repl shows more info when given functions
<clever> «lambda @ /nix/store/4rq3vfnl8pyvy7xg2z29862s7badfcv1-nixos-19.03pre158246.6141939d6e0/nixos/pkgs/build-support/fetchurl/default.nix:38:1»
<clever> nix-repl> fetchurl
<clever> > fetchurl
<clever> yl[m]: have a look at the source for fetchurl
<clever> ardumont: nice
<clever> catern: that will be at cache.nixos.org/5blzqmi4735d90rdrw26byjnn2bdzm4b.narinfo
<clever> > "${pkgs.hello}"
<clever> hmmm, not sure what the exact rules are now...
<clever> > builtins.compareVersions "1.6.1a1_2" "1.6.1"
<clever> > builtins.compareVersions "1.6.1a1" "1.6.1"
<clever> > builtins.compareVersions "1.6.1p" "1.6.1"
<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> ardumont: https://github.com/NixOS/nixpkgs/blob/master/nixos/tests/bittorrent.nix is a good example i used to see how tests work
<clever> jasongrossman: if /boot/ is mounted when you run nixos-generate-config, it will include /boot automatically

2019-03-07

<clever> ,cache charukiewicz
<clever> charukiewicz: is your internet working on the remote and local machine?
<clever> reilithion: you should be able to call gcc with params like free-standing to make it ignore the linux-y defaults
<clever> reilithion: youll need to just grab the bare gcc from it, at which point, the 32bit one from before should do
<clever> reilithion: i think the stdenv needs a libc to function, so a full cross-compile env wont work until your OS has a libc
<clever> reilithion: i prefer using gist
<clever> reilithion: it works exactly like pkgs, but its all 32bit packages
<clever> reilithion: if you are just targeting 32bit x86, you can use pkgsi686Linux.stdenv
<clever> reilithion: just use pkgsi686Linux
<clever> reilithion: also, if you just want a 32bit compiler, you dont need any of the cross-compile logic
<clever> reilithion: and if you tab-complete i3<tab> what does it find?
<clever> reilithion: how does it fail?
<clever> noonien: nativeBuildInputs picks the native version automatically
<clever> noonien: it also depends on if your just shoving it into the build inputs, or using it inside a string
<clever> noonien: if i need a tool like pkg-config, i want the x86 version, not the avr version
<clever> noonien: more to let me access non-cross things when i need them
<clever> reilithion: https://github.com/cleverca22/thermostat_firmware/blob/master/default.nix#L4 so you just start with something nix-build can cross-compile
<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> ddellacosta: heh
<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
<clever> du -h --max=0 -c $(nix-store -qR result) | sort -h
<clever> noonien: the size of a single package
<clever> nix-store --query --size ./result
<clever> 26801448
<clever> ,libraries seqizz
<clever> srhb: is it a multi-device pool?
<clever> srhb: read /init and see what nixos is using
<clever> srhb: or your calling zpool with the "wrong" args
<clever> Taneb: nix-shell -p 'callPackage ./foo.nix {}'
<clever> 195 jobs remain in the queue
<clever> click the eval# in the build page you just linked
<clever> pbb: hydra must also finish every single job in the eval (pass or fail)
<clever> pbb: http://howoldis.herokuapp.com/ has links to those pages
<clever> hyper_ch2: i think its cached by nscd, when that is active
<clever> srhb: boot.debug1devices will force an artificial failure after all dev nodes are up
<clever> srhb: boot.shell_on_fail will allow a shell, after it fails normally
<clever> that fixes it
<clever> srhb: boot.zfs.devNodes = "/dev/";