2017-08-11

<clever> ah
<clever> are they in a single directory?
<clever> ah
<clever> catern: have you tried using requireFile?
<clever> catern: how often does it change?
<clever> catern: nix will automaticaly copy it into the store, and make it available in the sandbox
<clever> catern: just do ${./foo} in the string
<clever> jonjitsu: not that i know of
<clever> catern: what kind of access?
<clever> catern: and if you used sandboxing, that would break 100% of the time, and the problem would become much more obvious
<clever> just (import ifd)
<clever> catern: and dont quote it either
<clever> catern: that is breaking the dependency chain
<clever> catern: dont run builtins.toPath on it
<clever> catern: id recomend always doing development with sandboxing on
<clever> catern: which means nix doesnt know it has to be built first
<clever> catern: and with sandboxing off, you can access things that you "dont depend on"
<clever> catern: no, sandboxing has to be enabled in nix.conf or configuration.nix
<clever> catern: do you have sandboxing enabled?
<clever> jonjitsu: is grub enabled in configuration.nix?
<clever> catern: nix-store --verify --check-contents
<clever> hydra will root the entire build-time closure of things, so if thats the cause of the entire issue, it will hold on to the file
<clever> it prints an error telling you to dl it and nix-store --add-fixed the file
<clever> requireFile is a fixed-output derivation, that will never sucessfully build a path
<clever> every single nix eval requires hashing the entire bar
<clever> i have needed similar requirements as well, foo = ./bar; isnt nice when bar is 4gig in size
<clever> catern: requireFile is the closest thing i can think of
<clever> jonjitsu: i'm guessing fileSystems."/target" = { fsType = "bind"; device = "/source"; };

2017-08-10

<clever> rodarmor: its not well documented, but you can check how steam does it
<clever> rodarmor: what about just running dropbox unpatched under a fhs chroot, like steam, lol
<clever> Infinisil: nscd will let it bypass that
<clever> which installs to somewhere in ~/.dropbox
<clever> rodarmor: it runs a dynamic elf in /tmp, that acts as an update installer, i believe
<clever> rodarmor: it does the right thing, a randomly named folder in /tmp
<clever> Infinisil: so if dropbox can contact nscd, it will use nscd's view of the dns world
<clever> Infinisil: #2, nscd acts as a caching resolver, caching real dns and /etc/hosts lookups
<clever> Infinisil: for dns, there are 2 things i can think of, #1 glibc may read /etc/hosts directly
<clever> Infinisil: dns is entirely seperate
<clever> Infinisil: network namespaces only affect the listening ports and the ip layer
<clever> not sure then, i havent dealt with python stuff much
<clever> replace buildPythonPackage with pythonPackages.buildPythonPackage
<clever> pythonPackages.buildPythonPackage would get the function into scope
<clever> no idea
<clever> which is ~10 years before 1980, which zip's dont support
<clever> nix sets the timestamps to 1 second after jan 1st 1970
<clever> the indentation of it is also a mess
<clever> ah, that example is probably wrong
<clever> got a link to that doc?
<clever> which will pass in attrs from pythonPackages and pkgs
<clever> that example was meant to be loaded with pythonPackages.callPackage
<clever> its always been under pythonPackages
<clever> Enzime: Enzime pythonPackages.buildPythonPackage
<clever> nixpkgs-unstable skips that testing, because its not meant for use on nixos machines
<clever> nixos-unstable has proper testing to prevent such major breakage
<clever> rodarmor: but nixpkgs-unstable had a bug about a year ago, that hosed grub.conf
<clever> rodarmor: yeah
<clever> rodarmor: you would also need to alter $NIX_PATH, and then just pull on a regular basis until the system stops booting :P
<clever> rodarmor: i recently read the source of nix-env, and found that you can do things like this, now nix-env -iA foo.hello grabs from a checkout in that dir
<clever> import /home/clever/apps/nixpkgs
<clever> [clever@amd-nixos:~]$ cat .nix-defexpr/test/foo/default.nix
<clever> Lisanna: -I nixpkgs=https://github.com/NixOS/nixpkgs-channels/archive/nixos-unstable.tar.gz
<clever> same
<clever> nope
<clever> tilpner: just a bit slow to load
<clever> and yep, the exact channels you listed
<clever> tilpner: so, we hop over to the channels mirror
<clever> tilpner: it was probably this commit that fixed it
<clever> tilpner: there is a neat trick ive found on github, one sec
<clever> copumpkin: and you can always make another override with a higher priority to turn it back on
<clever> and that exact line, is why sshd is off, but installed, in iso images
<clever> copumpkin: that unsets the wantedBy, so multi-user.target no longer triggers the startup
<clever> you probably want an mkForce, on second
<clever> ah no, thats something else
<clever> copumpkin: enable
<clever> cocreature: ${name.lib}
<clever> yeah
<clever> id usualy try to avoid contents for anything you want to persist, since nix wont be aware of it and will GC it
<clever> etc would keep them rooted, so they cant be GC'd
<clever> that would litter a directory like / or /tmp with symlinks to storepaths, that lack GC roots
<clever> copumpkin: or just append to the contents argument of make-disk-image.nix
<clever> after that, its just throwing paths in random places like etc so they get hauled along for the ride
<clever> only one i can think of right now is isoImage.storeContents
<clever> ah
<clever> copumpkin: storeContents is directly passed to make-squashfs
<clever> images have a special option for that, one second
<clever> for a full nixos install or for installer images?
<clever> ah
<clever> copumpkin: restrict-eval
<clever> copumpkin: strict mode i think, let me find it
<clever> flyingleafe: testing a fix here...
<clever> flyingleafe: ah, no cabal file, i see why the normal tools dont work right
<clever> flyingleafe: let me see...
<clever> flyingleafe: ahh, that looks like a variant of runhaskell
<clever> flyingleafe: which project are you trying to build with stack?, i could have a look at its files and see if its doing anything strange
<clever> flyingleafe: it might be simpler to just run cabal2nix and nix-build, and skip the stack layer
<clever> dont know then
<clever> flyingleafe: have you looked at the documentation for stack --nix?
<clever> yegortimoshenko: nix-store --add-fixed sha256
<clever> ylwghst: that tells it to create a symlink called foo, pointing to the result
<clever> yes
<clever> Lisanna: nix-build '<nixpkgs>' -A foo -o foo
<clever> bennofs: looks like i later redid it to make it simpler
<clever> dual.x86.nix: imports = [ ./dual.common.nix ./snmpd.nix ];
<clever> bennofs: but my configuration.nix was littered with mkIf statements, and it was able to share the same configuration.nix between both arches
<clever> bennofs: no cross-compiles where involved, each system had to do a native build with nixos-rebuild
<clever> the more complex part, is making sure the raspberry pi doesnt delete the x86 stuff, because nothing says its currently needed
<clever> so they always refer to different files, and the names never conflict, so you can just merge them
<clever> they have different bootloader config, pointing to different builds of nixos, and different kernels
<clever> and because the raspberry pi and x86 use different bootloaders
<clever> but that root point is different for arm and x86 (and also different for every build with new config)
<clever> shapr: and when nixos is booting, everything starts at a root point, like /nix/store/<hash>-nixos-<hostname>-<version>
<clever> shapr: so arm and x86 binaries of things can co-exist within /nix/store
<clever> shapr: basically, the hashes in /nix/store/<hash>-foo include the arch they are built for
<clever> i have ran nixos on an armv6 raspberry pi before
<clever> shapr: the nixos-rebuild command will compile the entire system, based on the current nixos configuration.nix file
<clever> shapr: nixos is basically an entire linux distro, written as a single massive nix package
<clever> shapr: i have gotten steam to run before, but my GPU drivers dont play well on the desktop
<clever> shapr: i still have the old white c64 i had when i was a kid
<clever> ah, lol
<clever> shapr: what software where you porting to the C64's?
<clever> nixos-rebuild switch inside the container
<clever> sauyon: declarative or imperative container?
<clever> that sounds normal
<clever> ylwghst: what is the current output of efibootmgr -v?
<clever> nmayhew: ahhh yeah, forgot about that route
<clever> sauyon: add the module to the imports list for the container config
<clever> nmayhew: it wants to merge all modules together, so you cant refer to your own value
<clever> nmayhew: ah yeah, thats because of how nixos options work
<clever> nmayhew: config.services.locale....
<clever> i cant even help you diagnose the problem, because they say "no dirty canadians allowed" :P
<clever> ive found that any attempts at drm just drive piracy up
<clever> anelson-: also look in chrome://components/
<clever> when you run the new chromium, it contacts the old one and spawns a new window
<clever> anelson-: did you fully quit chromium then re-launch it?
<clever> move in the same direction, but initiate at the other end, still as root on the receiver
<clever> and if root ssh is blocked, sudo nix-copy-closure --from bar
<clever> root doesnt check signatures
<clever> Myrl-saki: --to root@foo
<clever> anelson-: depends on if your installing chromium in systemPackages or nix-env
<clever> anelson-: chromium.enablePepperFlash = true; inside the nixpkgs config is one option
<clever> anelson-: and your sure it needs flash?, the last person that i helped wanted it for netflix (which doesnt use flash)
<clever> anelson-: why do you need flash working?
<clever> joepie91_to_go_: you must have a /boot mounted to /mnt/boot/ when doing nixos-install with efi
<clever> grantwu: i think the above commit merged staging into master
<clever> grantwu: 2203908e5fa7529183f43b6a9e7e11559b1fcde6
<clever> staging must have been merged into master after it was deemed stable
<clever> grantwu: and it says it was merged into staging
<clever> grantwu: in either case, hydra wont let anything broken reach nixos-unstable, so the breakage only makes the channel lag behind
<clever> grantwu: anything that seems simple is put right into master
<clever> grantwu: i think staging is mostly used for large changes that people think will break a lot
<clever> then just nix-shell with no args loads it
<clever> you can also make a shell.nix file with that string
<clever> yep
<clever> nix-shell -E 'with import <nixpkgs> {}; callPackage ./default.nix {}'
<clever> Infinisil: oh, that sounds handy
<clever> brb
<clever> thats used when modifying or creating a new entry
<clever> using efibootmgr, you can remove systemd-boot from the config
<clever> Infinisil: and he also has 2 efi binaries in the second one (systemd-boot and grub)
<clever> Infinisil: yeah
<clever> (delete it using efibootmgr)
<clever> i'm thinking delete systemd, but if it doesnt fall thru to grub, it will cease booting, and you would need the install cd to fix it
<clever> i
<clever> oh, maybe we want to set current, not next
<clever> ylwghst: what if you hold the option button and pick nixos-boot?
<clever> uefi firmware
<clever> Infinisil: so if you delete the partition first, you basicaly ruin the firmware forever
<clever> Infinisil: i have also heard of some crappy firmwares, that refuse to let you delete an efi entry with efibootmgr, if the matching efi system partition is MIA
<clever> ylwghst: looks good, lets see what happens when you reboot
<clever> ylwghst: yeah, i think that will fix the problem
<clever> Set BootNext to XXXX (hex)
<clever> -n | --bootnext XXXX
<clever> Infinisil: yeah, that looks much better
<clever> ylwghst: what does efibootmgr -v say?
<clever> its great for when you only need something once or twice and dont want to leave garbage around for years
<clever> ylwghst: once you leave the shell, efibootmgr is effectively gone
<clever> ylwghst: that opens a shell and puts efibootmgr into $PATH
<clever> Infinisil: do you know more about efibootmgr?, i dont remember how to make it list more details
<clever> ylwghst: try "nix-shell -p efibootmgr" and then just "efibootmgr"
<clever> its the efi boot manager, just run that command to print its current settings
<clever> ylwghst: and is it listed in the output of "efibootmgr" ?
<clever> Infinisil: do you know how to make nixos-rebuild copy grub to /boot/EFI and re-configure efibootmgr?
<clever> ylwghst: checking the config...
<clever> ylwghst: and also do nixos-rebuild switch --install-bootloader
<clever> ylwghst: what if you set boot.loader.efi.canTouchEfiVariables = true; ?
<clever> ylwghst: that will likely cause more problems
<clever> disasm: it was removed several months ago
<clever> ylwghst: try nixos-rebuild switch --install-bootloader
<clever> ylwghst: you need to make sure the efi is updated to run grub now
<clever> ylwghst: its probably still using systemd-boot
<clever> but nixpkgs-unstable can potentialy break a nixos machine, because it isnt tested
<clever> nixpkgs-unstable ignores those tests, and updates more often
<clever> nixos-unstable only updates when the nixos tests pass
<clever> ylwghst: this will also show what your generations are
<clever> ls -ltrh /nix/var/nix/profiles
<clever> ylwghst: and you want to put the insmod down a line, to get the indents right
<clever> you may need to use boot.loader.grub.extraEntriesBeforeNixOS to get it inserted sooner
<clever> ylwghst: but is it in the right spot?
<clever> ylwghst: and also look at the grub.conf in /boot, and see what it has generated
<clever> ylwghst: it may need an insmod setpci in the grub extraConfig
<clever> all of the ones not ending in -small will have good binary cache coverage
<clever> the branches on here match the channels perfectly
<clever> bbl
<clever> grantwu: depends on if your goal is to match up with a given channel, or match what you already have in /nix/store/
<clever> nix-instantiate --eval -E 'with import <nixpkgs> {}; lib.nixpkgsVersion'
<clever> ah, one sec
<clever> so check that out, then make a branch from there
<clever> i'm on revision 01c3847b9c
<clever> $ nixos-version
<clever> 17.09pre110213.01c3847b9c (Hummingbird)
<clever> grantwu: nixos-version tells you what revision your currently on
<clever> nixos automatically copied it in now that grub is on
<clever> ylwghst: and you have setpci under /boot/grub/x86_64-efi
<clever> it installed both legacy and efi modules
<clever> ylwghst: now what is in /boot/grub/ ?
<clever> that option was invalid, and had zero effect on the system
<clever> systemd 100% ignores all grub options
<clever> ylwghst: now what is in /boot/grub/ ?
<clever> ylwghst: yes, grub.device is only for legacy booting, and macbooks dont support legacy
<clever> Infinisil: the last error is because grub was enabled, and the invalid .device = "/dev/sda3" is now being tried
<clever> ylwghst: and you need to do boot.loader.grub.efiSupport = true;
<clever> ylwghst: boot.loader.grub.device must be set to "nodev";
<clever> --argstr says its a string, and saves you the trouble
<clever> --arg system '"x86_64-linux"' for ex
<clever> --arg will try to parse the 2nd part as nix, so it would need double quotes, that are protected from bash eating them
<clever> adelbertc: that loads the default.nix in <nixpkgs>, which takes a system argument
<clever> adelbertc: another trick you can do: nix-build '<nixpkgs>' -A hello --argstr system x86_64-linux
<clever> adelbertc: ahhh, system is a sibling of config, so the 2nd one
<clever> ylwghst: the entries in boot.loader.grub only have an effect if you set boot.loader.grub.enable = true;
<clever> adelbertc: what file did you set system in, and what command are you running?
<clever> adelbertc: then that should come into play
<clever> adelbertc: ahh
<clever> adelbertc: although, what is the host?
<clever> distributed builds dont rely on any special value of system
<clever> adelbertc: what exactly are you trying to do?
<clever> adelbertc: and those are both nixos options
<clever> adelbertc: there is a config.system.build (where system is a set), and there is a config.nixpkgs.system (a string that sets the arch for the build)
<clever> you are currently using systemd-boot
<clever> only if grub is enabled
<clever> ylwghst: grub doesnt run on bootup, so all grub config is being ignored
<clever> ylwghst: you dont have grub enabled, so nothing grub related will have any effect
<clever> so nothing you do with grub will have any effect
<clever> ylwghst: you are using systemd-boot
<clever> ylwghst: what is currently in /boot/grub/ ?
<clever> and the nix-env copy wont update itself either
<clever> manualy copying them is fragile and will break horribly next time things upgrade
<clever> ylwghst: what is currently in /boot/grub/ ?
<clever> ylwghst: your not supposed to have grub files in that directory, why do you want to reach them?
<clever> yorick: yeah, meant to highlight the guy that DC'd right before then
<clever> Infinisil: meant to say efi only machine
<clever> yorick: ah, for pygrub, you would do boot.loader.grub.device = "nodev";
<clever> adelbertc: there are also 2 system attributes, one is a set, another is a string
<clever> adelbertc: its within config
<clever> Infinisil: it probably fails to rebuild, because he incorrectly setup legacy on a legacy-only machine
<clever> oh, wrong name, he DC'd
<clever> yorick: boot.loader.device is only for legacy booting
<clever> yeah, we just confirmed that
<clever> i have seen weird problems from people having 2 /boot's before
<clever> ylwghst: yeah, that is definitely apple only
<clever> mount -v /dev/sda1 /mnt ; ls -ltrhR /mnt; umount /mnt
<clever> please confirm
<clever> if you temporarily mount /dev/sda1 to /mnt, what is inside of it?
<clever> and that was not blkid on the second command
<clever> ylwghst: what is /dev/sda1 ?
<clever> what about "fdisk -l /dev/sda" and "blkid /dev/sda*" ?
<clever> yeah, thats mounted
<clever> can you gist the output of "df -h" ?
<clever> so df -h /boot/ shows the correct contents?
<clever> ylwghst: is it currently mounted?
<clever> ylwghst: do you have a /boot partition?
<clever> ylwghst: i would just ignore the vconsole error
<clever> adelbertc: (import master {}).dockerTools
<clever> ylwghst: cant, or it undoes it at reboot?

2017-08-09

<clever> customDockerTools = callPackage (master + "/pkgs/build-support/docker/docker.nix") {}
<clever> master = fetchFromGitHub { repo = "nixpkgs"; owner = "nixos"; rev = "??"; sha256 = "???"; }
<clever> is master checked out are you using using a fetchgit?
<clever> and uses the nixpkgs= entry
<clever> it does to $NIX_PATH
<clever> adelbertc: callPackage <nixpkgs/pkgs/build-support/docker/docker.nix> {};
<clever> yeah
<clever> ps aux | grep tty1
<clever> ylwghst_: are you doing anything strange in tty1?
<clever> ylwghst_: that just looks like systemd being weird, i usually ignore those
<clever> ylwghst_: and second, it will check /boot/grub/state, and if the content is "wrong", it will re-run grub-install to update the binaries in /boot with the latest version
<clever> ylwghst_: first, it will inspect the list on nixos generations, and auto-generate grub.conf, while obeying boot.loader.grub.extraConfig
<clever> ylwghst_: the grub on nixos will do 2 main things
<clever> ylwghst_: that error doesnt appear to have anything to do with grub