2017-06-08

<clever> Filystyn: can you gist your configuration.nix file?
<clever> we would need somebody that has admin access to cloudfront to look into it
<clever> one of the servers in the cluster may have cached a 404, when others cached a 500
<clever> bennofs: cache.nixos.org is likely a load balancer, sending you to different cloudfront servers, each with its own cache
<clever> bennofs: the host in the via field is also changing in each
<clever> seconds
<clever> the age appears to be counting up, so the 404 is a cached reply
<clever> Via: 1.1 2db316290386960b489a2a16c0a63643.cloudfront.net (CloudFront)
<clever> X-Amz-Cf-Id: zJibv2ktw1P8U6H9VF-yesR9kRGvkUnQPxBgowTruwbk7MS49QoVKg==
<clever> Age: 1033
<clever> bennofs: if you add "-D -" you can see internal headers
<clever> 404 on the 2nd
<clever> bennofs: 404 on the first
<clever> also 404
<clever> chpatrick: there is a recent change that will inject packages into a 2nd profile, seperate from nix-env
<clever> samae: so if you start on 1, update+rollback, then update+rollback again, you land on generation 2, not 1
<clever> samae: ive also noticed, if you update and rollback several times, the rollback goes back to a previous failure, not the last working one
<clever> ToxicFrog: what error does it give?
<clever> ah, that sounds equaly good
<clever> having no dns in /etc/resolv.conf will probably fail faster then having an invalid dns
<clever> samae: ah, the target may try to fetch things from the binary cache, since thats faster then your upload pipe, in most cases
<clever> shlevy: in this case, i was booting nixos, with the store running on a custom fuse layer
<clever> shlevy: i have manualy ran systemd-nspawn to create some custom containers
<clever> sphalerite: i think you would need to at least disable this line: https://github.com/NixOS/nixpkgs/blob/release-17.03/nixos/modules/config/timezone.nix#L43
<clever> garbas_: there is a darling-dmg package in nixpkgs, that can be used to unpack dmg files
<clever> aloiscochard: you need to fetch every source with nix, then put them in the right spot so cmake doesnt try to
<clever> you must fetch source with one of the fetch functions
<clever> all network access is disabled at build time
<clever> ah
<clever> aloiscochard: which fetch function are you using?
<clever> aloiscochard: NIX_CURL_FLAGS is likely one you want to play with
<clever> aloiscochard: these variables are allowed to "leak" into fixed-output builds: https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/fetchurl/default.nix#L23-L34
<clever> its very rare that it comes up at the start of a sentence
<clever> lol
<clever> so that spam bot did noting to my client
<clever> hyper_ch: mine only does that if the mention is at the very start, like i did you for
<clever> and he gave up
<clever> eddyb: neat
<clever> morning
<clever> well, at least he is getting the admins attention for us, lol

2017-06-07

<clever> jgedarovich: you can sometimes edit /etc/nixos/configuration.nix right from the installer, and "nixos-rebuild test" the installer env
<clever> and that nix will then be used to do a proper nix build of everything (gcc, glibc, nix)
<clever> jefdaj: i think the copy of nix in ~/nix-boot/ will be linked against the host libs
<clever> jefdaj: you may need -L/lib64/
<clever> to find a subset, the runtime deps
<clever> nix knows the storepaths of the build-time inputs, and will then grep the output for those paths
<clever> that happens afterwards
<clever> unsafeDiscardStringContext just discards all of that, turning it into a plain string
<clever> and the context carries over after any string manipulation
<clever> danharaj: and if those strings are used in the creation of a new derivation, it will magically know what the build-time dependencies are
<clever> danharaj: internally, every string in nix has context invisible attached to it, a list of derivations that string depends on
<clever> danharaj: the derivation on line 110-116 contains the storepath of the system.build.toplevel derivation, but doesnt depend on it at build-time (or runtime), and it wont be made available inside the build sandbox
<clever> danharaj: an example of its use: https://github.com/cleverca22/not-os/blob/master/base.nix#L115
<clever> danharaj: for small scale things, there is builtins.unsafeDiscardStringContext, but i cant see how that would be used against an entire disk image
<clever> so it would have normally ignored yours, or overwritten the erlang ones, but they modified it to play nicely
<clever> gleber_: ah, lines 57 and 63 are inserting the prepatch/postpatch you pass to erland, into its own pre/post hooks
<clever> gleber_: depends on what context they are being set in, can you gist an example?
<clever> gleber_: there is an autoreconfHook, just add it to your buildInputs, and it will do everything for you
<clever> sphalerite: my brain works in weird ways, ive memorized a large chunk of the nixpkgs source, yet i cant remember when i last ate
<clever> sphalerite: you will need to populate installer.cloneConfigIncludes with a list of nixos modules, all of them land in the imports section of the generated configuration.nix
<clever> sphalerite: yeah, one min
<clever> danharaj: yeah, ive noticed the same problem with all disk images, the only solution ive seen is to run some compression over it so the paths are not readable by nix
<clever> you cant, only option i can see is to compress the image
<clever> Sonarpulse: ive used it for a few things before
<clever> internally, nixos-rebuild just calls that for you, on the result of nix-build
<clever> you could have also done ./result/bin/switch-to-configuration boot
<clever> you can also "--argstr system x86_64-linux" to force 64bit without having to set it inside the configuration.nix file
<clever> i knew i was forgetting something
<clever> oops, config.system.build.toplevel
<clever> sphalerite: yep
<clever> [0x4A6F]: how about this command? /nix/store/py2rbw8840758zmpvniniq4h1i27d06i-nix-1.11.9/bin/nix-build '<nixpkgs/nixos>' -A config.system.toplevel
<clever> [0x4A6F]: did you add the new nix's bin folder to the start of $PATH and run nixos-rebuild with _NIXOS_REBUILD_REEXEC=1?
<clever> sphalerite: check my qemu args in the insane.nix for an example
<clever> since it will be in the cache
<clever> oh, you might also be able to do that directly on your end
<clever> so my patches are absent from that hash
<clever> [0x4A6F]: this forces my nix to build a 64bit version of nix, and ignore everything in config.nix
<clever> /nix/store/py2rbw8840758zmpvniniq4h1i27d06i-nix-1.11.9
<clever> [clever@amd-nixos:~]$ nix-build '<nixpkgs>' -A nix --arg config '{}' --argstr system x86_64-linux
<clever> [0x4A6F]: oh, that might be a patched version i have
<clever> so it might cause infinite recusion if you try to reference its value
<clever> though that is also the attribute path for the final bash script for launching things
<clever> (config.system.build ? vm) will return a boolean
<clever> stanibanani: checking for the precenses of the .vm attribute might be the simplest way
<clever> sphalerite: vm's have this module added to the list
<clever> but shell/build/env can all share the same file
<clever> nixops needs a very different layout for the file
<clever> ixxie: nix-shell just sets an env var before eval'ing the nix expression, and you can test for that and behave differently
<clever> /home/clever/apps/nixpkgs/lib/trivial.nix: inNixShell = builtins.getEnv "IN_NIX_SHELL" != "";
<clever> you can do a lot of that logic within default.nix using lib.isInNixShell
<clever> shell.nix isnt really needed very often
<clever> ixxie: one thing i often see people doing, is running nix-build or nix-shell on a default.nix that needs callPackage
<clever> sphalerite: only rebuilds that change the grub version
<clever> rather then overwriting the 1st sata drive!
<clever> i would lean towards vda, so it will fail at runtime later on
<clever> it has to be something like /dev/sda or vda during the install
<clever> the usb stick may boot the rootfs on the hdd
<clever> yeah, if it collides with a real nixos install, bad things will happen
<clever> sphalerite: line 11 of the gist i linked
<clever> sphalerite: ah
<clever> nixos will also default to the arch that nix was built for, so the nixpkgs.system probably isnt required
<clever> and run _NIXOS_REBUILD_REEXEC=1 nixos-rebuild boot
<clever> then add it's /bin to the start of $PATH
<clever> that will download it from the binary cache
<clever> like /nix/store/sgvy8zr5zx8qp0j22ws5szykki4aw6yv-nix-1.11.9
<clever> [0x4A6F]: you will need to run "nix-store -r" on the storepath for a recent 64bit build of nix
<clever> [0x4A6F]: is the kernel 64bit capable?, what does uname -a say?
<clever> sphalerite: what expression did you use?, i could build it and have a look
<clever> though nix isnt aware of sparse files, and will still serialize it as a crap-ton of nulls
<clever> sphalerite: there is also the truncate command, which will just set the size, potentialy making it sparse
<clever> sphalerite: you can then dd that to a usb stick and it will boot like a normal nixos install, with full generations and nixos-rebuild support
<clever> sphalerite: make-disk-image will do what it says on the tin, it has a wide range of options, and it basicaly does nixos-install into a .img file
<clever> sphalerite: though another better option, is to skip the read-only squashfs entirely, let me find that expression
<clever> sphalerite: then it would always consume the entire usb stick, rather then having a fixed size that has to be extended
<clever> sphalerite: i just had a thought, what if, instead of creating an extra partition in the disk image at buildtime, what if you created it at boot time, from stage-1?
<clever> so i mutated it into 32bit nixos (oops, didnt notice the arch!), then mutated it again into 64bit nixos
<clever> but the gentoo still booted, and had a /nix/store that "worked"
<clever> i was in the middle of moving it to a backup server when i had to leave, and that left it without a /usr/bin and stuff
<clever> i had to go thru the 32->64bit conversion because i was on xmas vacation with half a gentoo install
<clever> heh
<clever> Mic92: ah, nice
<clever> danbst: ive also made a kexec trick that can potentialy be used on any cloud provider with >1gig of ram and MBR booting
<clever> danbst: and the 32bit nix still thinks the kernel is 32bit only
<clever> danbst: yeah, but when you change nixpkgs.system, your using a 32bit nix to build a 64bit nixos
<clever> and you cant run the 64bit stuff on a 32bit kernel
<clever> and until you manualy force nix to be 64bit, it wont let you do 64bit builds
<clever> danbst: the example in your gist only upgrades the kernel
<clever> but if you nix-store -r a 64bit nix, you can add that to $PATH temporarily to unlock 64bit builds
<clever> danbst: the 32bit build of nix believes the host to be 32bits, and will refuse to run a 64bit gcc
<clever> danbst: hmmm, yeah, that just might work, but nix will need a bit more convicing afterwards
<clever> gleber_: the build-chroot-dirs is the only part that may need more explaining, it contains the path that gets symlinked to /bin/sh, and the closure of /bin/sh, the one of the few impuritys that nix inject into the sandbox
<clever> gleber_: i just manualy copy how i see it setup on nixos, look at the nix.conf file and setup build-chroot-dirs, build-users-group, build-use-chroot, and also create some build users in the nixbld group, and run nix-daemon as root
<clever> preferably on the local network
<clever> [0x4A6F]: it can be any linux 64bit machine with nix installed
<clever> drakonis_: what does "ls -l /dev/vboxnetctl" say exactly?
<clever> [0x4A6F]: i then had to read the result/bin/switch-to-configuration script, find the install-grub script, which is #!'d to the 64bit perl, and manualy run the 32bit perl against it
<clever> [0x4A6F]: that will create a 64bit instance of nixos
<clever> [0x4A6F]: if you add a 64bit build slave, you can do this: nix-build '<nixpkgs/nixos>' -A config.system.toplevel --argstr system "linux-x86_64", i believe
<clever> drakonis_: does the "id" command say your in the right user?
<clever> yeah, if you just run nixos-install without formating, it will reuse the current config
<clever> [0x4A6F]: to start with, you need a 64bit build slave configured in configuration.nix, so it can do a 64bit build of the os
<clever> [0x4A6F]: ive done it once before
<clever> music mode also turned off the mic
<clever> and the music mode had support for stereo, and resent lost packets
<clever> i'm not sure, but i think the phone quality mode sounded worse, but allowed packet loss?
<clever> and its "tethering" was ppp over bluetooth serial
<clever> oh, that phone didnt even have wifi
<clever> it was back from the era when a "smartphone" ran palmos
<clever> part of my problem might have been from me using the oldest bluetooth headset possible, lol
<clever> and the description says you can just set package to pulseaudioFull
<clever> and also, the description, you probably dont even need an override
<clever> sphalerite: which attribute did you override?
<clever> but pulse wasnt aware of all of that
<clever> the hardware is capable of doing 3 output streams at once, optical output, headphone on front, headphone on back
<clever> i was using that to try and get more grunt out of the sound card on my motherboard
<clever> sphalerite: hardware.pulseaudio.package
<clever> i saw an issue a few weeks back about nixos loading the overlays (it would fail if the overlay had a syntax error), but ignoring them entirely
<clever> most of its features just work out of the box of nixos, but you cant reprogram the buttons, and the low battery warning is gone
<clever> sphalerite: logitech g930
<clever> sphalerite: i have since switched to a wireless headset with a proprietary RF protocol (the dongle claims to be a usb sound card + usb HID)
<clever> sphalerite: the range was horid, it had constant dropouts, and it buffered any lost packets, causing the latency to get worse every time it had a dropout
<clever> sphalerite: i dont remember the exact config i used, but i believe i had it working in nixos a year or 2 ago
<clever> yeah, just jobs = import ./jobs.nix { usesStableNixpkgs = true; } in nix-repl and then you can tab-complete on jobs.
<clever> joko: you can either pass that machine list directly in via an argument, or throw in an if statement to change the file
<clever> joko: ah, line 18, your currently reading a machines file
<clever> joko: like the supportedSystems argument here: http://hydra.earthtools.ca/jobset/arm/nixpkgs-arm-unstable#tabs-configuration
<clever> joko: you can add arguments to the jobs.nix file like any other file, so { usesStableNixpkgs ? false }:, and then in hydra, you can set that as a nix expression
<clever> joko: if you want to run the exact same command hydra does, i have that in an issue somewhere
<clever> joko: it can help greatly in debugging
<clever> you can check off #3, #4, and #5 in that comment
<clever> kojiro: if you try to just install it, the error tells you exactly that you need to put in a file, and where the file is
<clever> [clever@amd-nixos:~]$ nix-env -iA nixos.slack
<clever> aloiscochard: mesa should contain the opengl headsers/libs
<clever> and if you run the same query commands on the result that nix-build makes, you can see the runtime closure
<clever> ij: that will show the entire build-time closure
<clever> ij: run nix-instantiate on the nix file, then nix-store --query --tree or nix-store -qR
<clever> nix uses lazy evaluation, and will only eval the parts of pkgs that you reference, and only the derivations you reference directly become part of your closure
<clever> only the things listed inside the derivation become a dependency
<clever> you just brought the pkgs variable into scope
<clever> ij: inherit (nixpkgs) pkgs;, this gives you access to the pkgs attribute
<clever> ij: ooohh, yeah, 'git' inside a with haskellPackages; gives you the haskell package called git
<clever> goibhniu: yep, that was part of the plan, you can either use it for servers, or localhost it for new users
<clever> it will then serialize out to a configuration.nix file
<clever> this shows the full tree of options, with descriptions, and you can paste them into a tree of config
<clever> tanonym: i started something similiar that would allow full config of nixos
<clever> lol
<clever> sphalerite: :D
<clever> so i could walk up to that car, guess the wpa password in ~200 tries, then dbus root your radio
<clever> the wifi is also always on, and gives you access to the dbus
<clever> so the seed is the uptime
<clever> before ntp has had a chance to do its thing
<clever> oh, and the wpa passphrase on the wifi hotspot is seeded with the unix timestamp at bootup
<clever> the captive portal just wont let you thru until you pay
<clever> even if your not paying for it
<clever> the issue in that car, is that the 3d is always on
<clever> and then just turn off the safetys they had put in the CAN bridge
<clever> so you can remotely reflash the entire radio
<clever> however, they ran a shell script from writable media, while in flashing mode
<clever> and you had to reboot the radio into flashing mode to reprogram that second processor
<clever> so you couldnt directly fiddle with the ECU
<clever> there was also a dedicated cpu acting as a bridge between the main OS cpu, and the CAN bus
<clever> which means, malware in one car is free to spread to all other cars, but the big bad internet cant get in :P
<clever> in that case, the port was firewalled off at the teleco, so it could only be accessed by other cellular users on the same telco
<clever> avn: i have also seen horribly done dbus services, there was a car entertainment center that had dbus running over bare tcp, on the internet, and it had a method to run a command as root
<clever> aloiscochard: ah, its cmakeConfigurePhase
<clever> aloiscochard: you can also get that by manualy running cmakePhase i believe, in nix-shell
<clever> aloiscochard: just adding cmake to the buildInputs will make it automaticaly run cmake with the right flags in the configurePhase
<clever> aloiscochard: possibly, nix also has support to handle cmake for you, what happens if you run nix-build on the file instead?
<clever> lol
<clever> avn: the only thing i was able to get over the normal dbus api was the path to that socket
<clever> sphalerite: and the main dbus api only gives you the path to the non-standard socket, that no library will accept
<clever> sphalerite: pulseaudio for example, seems to reimplement their own dbus server, on a non-standard socket
<clever> sphalerite: yeah, almost every dbus based thing ive tried to query has been imposible
<clever> aloiscochard: that should work, do you know how the package is calling gcc?
<clever> sphalerite: toxvpn is currently controlled with text commands over a unix socket, but i was thinking about adding dbus to it
<clever> aloiscochard: are you doing the build under nix-shell
<clever> ij: also keep in mind, nix will usualy delete the .git folder for sources
<clever> [clever@amd-nixos:~]$ nix-shell -p '(python27Packages.python.withPackages (p: [ p.gst-python ]))'
<clever> myguidingstar: oops, wrong m name above
<clever> makefu: i think this might have something to do with it
<clever> [nix-shell:~]$ ls /nix/store/0zx8799kbvlybwy43vs0bf8r9n56d7gy-python-2.7.13-env/lib/python2.7/site-packages/gi
<clever> just put everything into installPhase
<clever> the default fixupPhase is what patches everything, but youve overridden that
<clever> boomshroom: can you gist your expression?
<clever> but only because i'm using a crap-ton of memory and swap isnt doing its job
<clever> a midnight cronjob always borks zfs
<clever> lol, like that
<clever> it works great on most systems, only has trouble under high memory loads
<clever> i run zfs on all of my nixos machines
<clever> might be tricky to find an fs both support, that also has uid and +x
<clever> heh
<clever> ext3?
<clever> does mac support ext4?
<clever> then you can just mount the /nix/ partition of nixos to the mac, and it will probably work
<clever> then just cp -r the per-user/${macuser}/ folder into the nixos version of /nix/var/nix/profiles/
<clever> then boot into nixos on the mac, and nix-copy-closure it back
<clever> in theory, you could use nix-copy-closure to copy the closure of your mac ~/.nix-profile/ to any machine with nix
<clever> boomshroom: do you have a 2nd system with nix?
<clever> it might even be enough to entirely eliminate the problem
<clever> that might help
<clever> that should allow multiple arches to share the store and keep all profiles seperate
<clever> and then i think i had to symlink each profile folder under /nix/var/nix/gcroots/
<clever> then the profiles for each OS remain seperate
<clever> half of the solution, is to have 2 different instances of the /nix/var/nix/profiles/ folder, and to bindmount the right one on bootup
<clever> i had x86-64 nixos, and arm nixos on the same rootfs
<clever> then its similiar to one of my early nixos installs
<clever> ah
<clever> is the laptop running both mac and linux?
<clever> simpler to just allow copying between the systems
<clever> its tricky to get right
<clever> and the gcroots have to be aware of the profiles from the other os
<clever> but the db.sqlite must be linked to /nix/store, or it can gc things another os is using
<clever> boomshroom: might be better to just document the need for imagemagick then?
<clever> sounds more like a problem in the feh package then, it doesnt correctly depend on imagemagick
<clever> ah
<clever> is feh causing any problems?
<clever> so feh just cant be removed without reworking that code
<clever> boomshroom: feh is also required because the 'none' display manager doesnt support backgrounds automaticly
<clever> or open the site in a browser, accept the license, and download it manually
<clever> yeah, ive not seen any other package do that kind of thing
<clever> bhipple: either use requireFile like java does, or require the user to fill some info in like factorio does
<clever> yeah
<clever> boomshroom: if your copying it to $out/bin/ then you can just chmod it at the same time
<clever> boomshroom: do you have an example expression your starting with?
<clever> if you want to use that with different channels, then you can just make 2 buildEnv's
<clever> i can then nix-env -iA nixos.mystuff to atomicly apply that
<clever> boomshroom: line 12 onward creates a custom package called mystuff, that contains a large list of things
<clever> writing a buildEnv based package
<clever> yep, but that shows names, not attribute paths, and it doesnt know which channel things came from
<clever> install*
<clever> then nix-env -iA unstable.stuff2, to unstall a second chunk from the unstable channel
<clever> if you use a buildEnv in config.nix, you can do nix-env -iA nixos.stuff1 to install a chunk from the nixos channel
<clever> and if you try to install something you already have, it will be updated to the version you referenced
<clever> nixos is still a valid channel, --list wont show root's channels
<clever> so you can just name any channel you have
<clever> boomshroom: when you do nix-env -iA nixos.firefox, the 'nixos' tells it which channel to use

2017-06-06

<clever> then call the channel on your user nixpkgs or unstable
<clever> so you now have 2 nixos channels
<clever> or rather, you added it to both your user, and root