<clever>
nix-build '<nixpkgs/nixos>' -I nixos-config=./configuration.nix -A config.system.build.toplevel
<clever>
and you can pre-build the images and embed them into the host as well
<clever>
if the host has something, it just copies it over, if not, it tries the binary cache, and just compiles whatever is missing
<clever>
Zvieratko: then it just runs nix-build under the chroot
<clever>
Zvieratko: it will basicaly rsync a copy of nix (and its dependencies) into the root, and register them as valid in nix.db, then configure it so it can leech from /nix/store of the host (like a 2nd binary cache)
<clever>
Zvieratko: you can run nixos-install from a script, and there are utils in nixpkgs to build an image that has a script built into it
<clever>
Zvieratko: the main way i can think of right now, is to setup something that will install a base image (with ssh and some credentials to login), and then use nixops with the targetenv of "none" to deploy
<clever>
ixxie: only gentoo does that, heh
<clever>
ah, i didnt notice that typo in the original paste
<clever>
qknight: the left version will call fetchurl on an attrset, the right version returns an attrset with fetchurl set to another attrset
<clever>
ixxie: its what creates the main pkgs attribute set
<clever>
ixxie: that contains nearly every package in nixpkgs
<clever>
echo-area: and then if something uses findfile to find it, nix would automaticaly download the given revision of nixpkgs
<clever>
echo-area: http://pastebin.com/w4WZyy0Z is something i was experimenting with yesterday, and i could put pkgs2 into the nix search path as-is
<clever>
echo-area: but in some weird cases, the path list given to findFile may contain a derivation
<clever>
echo-area: <nixpkgs>/default.nix doesnt actualy contain a derivation, it returns an attribute set full of derivations
<clever>
but normaly, those contexts get routed back to another derivation, and become its build-time dependencies
<clever>
and in this case, findFile will try to compile everything the string depends on, at line 811
<clever>
what you cant see, is that it also references /nix/store/ay9q989f0qwvrjjnn6pq5skc69rlmkmc-hello-2.10.drv
<clever>
so if i make a string like "${pkgs.hello}", that has context that depends on a specific build of hello, but when cast to a string, it looks like "/nix/store/cjdj0d229a4d8cr872di5yvyrm65qg83-hello-2.10"
<clever>
basicaly, every string in nix has context attached to it, which references which derivations the string may depend on
<clever>
PathSet context; is another weird thing in nix that can be non-obvious
<clever>
in this case, findFile requires that every entry is an attrset
<clever>
but yeah, it is valid for a list to have a mix of types, [ 5 "10" { a=true; } ] is a list of 3 items
<clever>
its forcing it from a lazy thunk to an attribute set, which can throw an exception if it isnt an attrset
<clever>
state.forceAttrs(v2, pos);
<clever>
echo-area: state is an internal part of the evaluator, its not one of the variables passed to findFile
<clever>
5 + "10" is invalid, so we dont have another javascript on our hands
<clever>
numbers wont just magicaly turn into strings, but argument types dont have a defined type either
<clever>
nh2_: sounds like you need a "make clean" rule to delete the state
<clever>
gchristensen: yeah, like the snmp case
<clever>
so, it compiles itself to open "unknown" at runtime
<clever>
nh2_: the nix sandboxes lack all variants
<clever>
nh2_: it tries to detect the name of /etc/mtab at compile time, (it varies from distro to distro)
<clever>
nh2_: though i have run across an impurity in snmpd, that was tricky to track down
<clever>
nh2_: i generaly feel that sandboxes can be used to force impure stuff to break, as an alarm, but once you have make the expression pure, it will build the same with or without
<clever>
nh2_: i have heard that chrome uses the same path to lock its threads down, but i didnt think it could do that much without root
<clever>
nh2_: even without root?
<clever>
nh2_: you can see the expected output in the txt file by the same name
<clever>
2016-11-28 11:53:01 < clever> JonReed: which will search $PATH at build time (put python2 into buildInputs)
<clever>
it will patch everything in that dir
<clever>
JonReed: one minor detail, patchShebangs needs a directory, not a file
<clever>
JonReed: make a nix package for it that will download and patch it
<clever>
JonReed: which will search $PATH at build time (put python2 into buildInputs)
<clever>
JonReed: if it already has #!/usr/bin/python, you can use patchShebangs
<clever>
JonReed: use #!${pkgs.python2}/bin/python
<clever>
kbwt: and they will always get the version the ask for
<clever>
kbwt: and unlike other distros, you can depend on a&b, without a&b being "installed" globaly, so nothing else will be able to use a&b, enless they also depend on it directly
<clever>
kbwt: all dependencies are resolved by evaluating the nix expressions, which is much faster on nix then on gentoo
<clever>
and different versions with different build config also get unique prefixes
<clever>
kbwt: nix solves most issues, by not really installing things in the traditional way, every version of every package gets a unique --prefix
<clever>
taktoa: this one is just the ansii color code escape, but it probably allows all of unicode
<clever>
vdemeester: i prefer using a buildEnv, for package management
<clever>
i tend to just delete the file and manage that manualy in configuration.nix, so i know exactly what is changing
<clever>
normaly, you can re-run nixos-generate-config on a running machine, and it will update hardware-configuration.nix to match whatever you currently have mounted
<clever>
its more of a user config problem then a bug in nixos
<clever>
one person garbage-collected that generation, and then it lost the ability to boot :P
<clever>
and from then on, it always rolls back to the last config that made it into /boot, on every restart
<clever>
this happens every now and then with nixos users, /boot gets removed from configuration.nix by mistake
<clever>
you have been updating the entries file on the rootfs, not the one the bootloader used
<clever>
yeah, so you need to mount sda2 to /boot
<clever>
can you mount sda2 to /mnt and run "find /mnt" and pastebin that output?
<clever>
what is sda1, sda2, and sda3?
<clever>
do you have a dedicated boot partition?
<clever>
i dont see anything mounted to /boot
<clever>
joncfoo: can you pastebin the output of "mount" and "lsblk" ?
<clever>
ah, not grub then, but same conditions still apply
<clever>
you picked exactly 44?, or just "latest"?
<clever>
is /boot mounted correctly?
<clever>
either you selected 42 from grub when booting, or something has glitched out
<clever>
you are currently running from generation 42, and there are 2 new ones, 43&44
<clever>
joncfoo: can you pastebin the output of this?
<clever>
ls -l /run/current-system /nix/var/nix/profiles/system*
<clever>
joncfoo: one sec
<clever>
joncfoo: is virtio in that file?
<clever>
joncfoo: and its configured via /etc/modules-load.d/nixos.conf which nixos should generate
<clever>
joncfoo: i think a systemd unit called systemd-modules-load handles loading boot.kernelModules
<clever>
Dezgeg: i think i found my boot problems, ARM_APPENDED_DTB is enabled when it shouldnt be
<clever>
Biappi: modify the nix file to add that to buildInputs
<clever>
Biappi: -p and passing files in dont work together
2016-11-27
<clever>
nix-shell -p patchelf
<clever>
lf
<clever>
and you usualy dont want to install things like patche
<clever>
the kernel injects linux-vdso.so into every process, so the userland can get the best performance without having to care about what the cpu is
<clever>
and you need to use the right one for syscalls, to get the best performance
<clever>
basicaly, every cpu has a different trick to switch to kernel mode
<clever>
its a weird hack to make syscalls perform better
<clever>
nope, linux-vdso.so is part of the kernel itself
<clever>
yeah
<clever>
not what i was thinking of then
<clever>
ToxicFrog: nixos or another distro?
<clever>
based on buildInputs
<clever>
LD_LIBRARY_PATH is only setup like that inside nix-shell
<clever>
so it breaks for everybody, rather then just those who forgot to install X
<clever>
and also why nix is designed to avoid looking in global paths
<clever>
yeah, i'm not sure on that part either
<clever>
yep
<clever>
iMatejC: just following along with what your saying
<clever>
so you will want a second variable made via mkLibraryPath for those, and then use wrapProgram
<clever>
ToxicFrog: i think dlopen can only be solved via LD_LIBRARY_PATH
<clever>
iMatejC: ah
<clever>
you must use libPath in --set-rpath
<clever>
all that does is set a variable called libPath
<clever>
not sure how its finding the others, but xorg.libX11 is the package for libX11
<clever>
you must point it to the path of everything
<clever>
it will never find "installed" libraries
<clever>
for closed-source stuff, buildInputs is only usefull to get things in $PATH at build time
<clever>
when compiling stuff from source, the rpath is just set correctly by the compiler (via buildInputs)
<clever>
ToxicFrog: you need to --set-rpath with a list of the runtime deps
<clever>
but if you get it into nixpkgs, i can add it to my jobsets and pre-build it
<clever>
ahh, then you will need a more customized kernel
<clever>
yep, that build is following the nixos-unstable-small channel
<clever>
i should have the rpi fork of the kernel in there, but when i tested it recently i couldnt get it to boot
<clever>
iMatejC: its following nixos-unstable-small if you want to match your nix-channel up
<clever>
iMatejC: with this, you can leech things ive built on my hydra
<clever>
iMatejC: i also have some arm stuff on my hydra
<clever>
simpson: but it might be simpler to just use a proper config+option pair like everything else, if your only going to have a single cool.nix loaded
<clever>
simpson: and then inside that, { foo }: { pkgs, config, ... }: { normal junk }
<clever>
simpson: i suspect you can do imports = [ (import ./cool.nix { foo = "bar": }) ];
<clever>
glines: gcc.cc.lib
<clever>
glines: best case, it has a CLI mode, worst case, it needs a full x server to unpack the rest
<clever>
glines: i see xorg functions in the new binary
<clever>
XftFontOpenPattern
<clever>
eek
<clever>
so you needed to patchelf the binary in ram
<clever>
without using the execve syscall
<clever>
what i believe UPX does, is it unpacks the 246mb copy to ram, then internaly re-executes that version
<clever>
yeah, now you can patchelf that version
<clever>
glines: running upx -d on it turns it into a 246mb elf dynamic elf file
<clever>
glines: yep, its a valid UPX self-extracting-archive
<clever>
glines: you might be able to get something out of it using binwalk
<clever>
glines: i'm guessing its either some form of weird DRM, or something similar
<clever>
glines: i have a feeling they cheated, and made a "static" executable, that opens the dynamic linker anywahs
<clever>
glines: that sounds very strange, is there an execve anywhere in the strace?
<clever>
glines: what does "file" say when ran on the program?
<clever>
and at build-time, it creates those symlinks
<clever>
you could then package the launcher, and have it depend on doomrl
<clever>
ah
<clever>
and if you use $out/bin, then it will be in /run/current-system/sw/bin, which is part of $PATH
<clever>
if you put the package into environment.systemPackages, it will wind up in /run/current-system/sw/opt/doomrl
<clever>
i would make a proper package for it, and add it to the configuration.nix
<clever>
ah
<clever>
and by extension, it wont break the ELF file nix isnt aware of
<clever>
so nix will never garbage collect zlib
<clever>
and as an added benefit, nix believes that the shell script depends on zlib
<clever>
without making a proper package
<clever>
so i could then use the above gist to re-patch the ELF every time steam updates it
<clever>
one case where i can see the above being usefull on its own, one of the games ive played in steam, downloads .exe and ELF files, when running under wine
<clever>
this allows you to quickly test things out, either just to make it work, or as a step leading up to making a package
<clever>
and if you run that shell script on an ELF file, it will fix the dynamic linker, and make zlib available at runtime
<clever>
ToxicFrog: if you run nix-build on that nix file, it will generate a shell script
<clever>
ToxicFrog: this is a util i wrote that helps speed up some steps