<clever>
athan: and have you done a nixos install before on other hardware?
<clever>
athan: to start with, do you have nix on the rpi yet?
<clever>
its more about having to delete the partitions, and you cant do that when they are mounted
<clever>
then you are free to partition it correctly
<clever>
athan: if you have a 2nd uSD card in a usb reader on the pi, it would go much smoother
<clever>
athan: but it had some minor boot issues that i solved with rm -rf /etc, which is harder to do without grub
<clever>
athan: i have used nix-build to convert 2 of my gentoo machines directly to nixos, without any repartitioning or formating
<clever>
rardiol: if 2 build inputs both provide foo in /bin, then the order will start to matter
<clever>
rardiol: so it basicaly turns into "foo bar" vs "bar foo" and nix doesnt know they are similar (and the order can still affect the build)
<clever>
rardiol: it doesnt apply any sorting to the buildInputs, and it casts the list down to a string
<clever>
and more major stuff
<clever>
rardiol: or changing the order of elements in a list
<clever>
rardiol: nope, only spaces inside strings cause a rebuild
<clever>
Dezgeg: bingo, i checked out the next branch of firmware, and now i have even more entries for program_ being found within "strings start.elf"
<clever>
Dezgeg: but i dont see the usb stuff the docs mentioned, and they do say to switch to the next branch
<clever>
Dezgeg: i just found a rather scary option in start.elf, program_bootrom
<clever>
stepcut: could be power saving, can you plug in a keyboard and hit the any key?
<clever>
and i do have a 3 i can mess with
<clever>
they should clearly document when that was added
<clever>
Dezgeg: if i'm reading this right, the boot rom in the die can dhcp and fetch bootcode.bin, without any sd card.....
<clever>
sphalerite: and the end-user builds a buildEnv to bundle all the plugins into 1 dir
<clever>
sphalerite: in that case, the browser is built without plugins by hydra, then the end-user builds a shell script, that sets an env variable saying where to find plugins
<clever>
sphalerite: plugins in browsers are that sort of thing
<clever>
and if runtime detection is on, it can fallback sanely
<clever>
sphalerite: it also has c implementations, which will probably perform slower
<clever>
sphalerite: so it has to select the correct codepath, for the current processor
<clever>
sphalerite: in mplayer, there are large chunks of hand-optimized assembly
<clever>
the runtime detection results in the best performance, and compatibility
<clever>
MichaelRaskin: by default, mplayer builds everything into it, and auto-detects stuff at runtime, but this results in a bigger binary
<clever>
MichaelRaskin: thats an option gentoo had enabled, because they are ricers :P
<clever>
and if you now run it on an older processor, it will just hard fail
<clever>
and compile those into the binary
<clever>
one random example, by default, mplayer builds on gentoo will auto-detect what cpu features you have
<clever>
you have to trust that the hydra build slave didnt bend the purity rules and inject malware into every single result
<clever>
mostly compatibility
<clever>
and hydra does 90% of what you will ever want
<clever>
primarily source based, but because of the purity, it is safe to reuse builds other people have made
<clever>
so forcing it on, and forcing it off, always causes a large number of recompiles
<clever>
ah yeah, and options like pulseaudio have different defaults for every package
<clever>
jeaye: oh, the tests are are doing dont handle the nixpkgs.config overrides from configuration.nix
<clever>
the cache is there, i cant think of anything else
<clever>
jeaye: can you pastebin /etc/nix/nix.conf?
<clever>
and i also confirmed that the drv path in one of your pastes is in the cache
<clever>
jeaye: the 2 nix-instantiates i gave at first confirmed that its not an override
<clever>
and it is present in the cache
<clever>
git checkout ee52e98 ; nix-instantiate -A openjdk perfectly recreates the .drv hash from the pastebin
<clever>
yeah
<clever>
kmicu: the hash in that pastebin was the drv hash, not the output hash, so it will differ some because of fetchurl's
<clever>
32bit or 64bit?, and what kmicu said
<clever>
then its not an override
<clever>
jeaye: can you compare the output of these 2 commands, "nix-instantiate '<nixpkgs>' -A openjdk" and "nix-instantiate '<nixpkgs>' -A openjdk --arg config '{}'"
<clever>
sphalerite: put either gnome or gnome3 into the list of arguments on line 1, then put either gnome.gtksourceview or gnome3.gtksourceview into the buildInputs
<clever>
but nothing actualy gets an image out of any
<clever>
it seems i can turn the signal on/off, if i --off an output, the monitor goes into power saving mode
<clever>
and $DISPLAY is already in the env
<clever>
--output DVI-1 --off also has no effect
<clever>
no effect from xrandr --auto
<clever>
but it doesnt give a tty
<clever>
running "chvt 1" over ssh causes the monitors to loose signal and re-obtain it
<clever>
amd, and i have no easy way to control it when blind
<clever>
i unplugged the 3rd monitor to shuffle the wires around, and the other 2 monitors went dead
<clever>
and now ive lost video on the main system
<clever>
that would also be possible
<clever>
steveeJ: yeah, to cover the missing features, you would almost need to do that, it would become a thin wrapper between the host init system, and the service, that translates kill -int to ExecStop
<clever>
steveeJ: and then just have other init systems run the wrapper, when unsupported features are detected
<clever>
steveeJ: in theory, that could be rewritten in c++, then have mount and user namespaces added to it, to cover all of the other systemd features
<clever>
i think its meant for testing the service on nixos, but it can also be abused to run the service on another distro
<clever>
though it probably doesnt cover the special cases i initialy mentioned
<clever>
steveeJ: if you run nix-build on this, you get an executable that starts postgresql, and obeys all of the service config setup in nixos, including the pre/post start/stop
<clever>
steveeJ: also, have you seen the perl script thats used for testing?
<clever>
steveeJ: not all init systems have those, and the security of some services depends on them, so now you need to re-implement sections of systemd, and use custom wrappers to launch things
<clever>
steveeJ: part of the problem, what do you do with options like ReadWriteDirectories or PrivateTmp and PrivateNetwork
<clever>
arjen-jonathan: looks like you make a "worker@foo" that only has things like wants on it, then another "worker@" service, that has the start scripts
<clever>
arjen-jonathan: and the area starting at line 464
<clever>
lonokhov: yeah, thats pretty tiny compared to what i currently have
<clever>
lonokhov: the only fix i can see here, is to split lib, doc, and share into multiple outputs on js-jquery, and patch the share path it returns to the runtime
<clever>
lonokhov: and the lib folder (which is never referenced by chat-shaker) references ghc itself, so thats another 1gig of overhead
<clever>
so thats 161mb of overhead right there
<clever>
and the js-jquery docs depend on the ghc docs
<clever>
the only reference to js-jquery in chat-shaker is the path to a 85kb file, but the docs are in the same output
<clever>
not sure how that effects the above issue, are your fixed on master yet?
<clever>
what does ekg do?
<clever>
so it only needs a single <500kb js file, but depends on the entirety of ghc
<clever>
lonokhov: that jquery.js path, is in the same output as the .so files(which depend on ghc), but the .so files got staticly linked and arent needed
<clever>
lonokhov: for example, the jquery package (a haskell library that just returns the path to jquery.js on-disk)
<clever>
lonokhov: one area i ran into, which may not be fixed yet, is with multiple outputs
<clever>
loskutov: there is also a NIX_DEBUG=true; you can add to a derivation, which will tell you when stuff like overflow protection is being enabled
<clever>
reactormonk: i heard that it was missing a key syscall
<clever>
been a while since ive done it
<clever>
i think i also had to run qtcreator under that nix-shell
<clever>
and it will auto-detect the paths for everything
<clever>
yep, and within qtcreator you should be able to add a new version of qt, and give it the path to that qmake
<clever>
thats what generates the qmake
<clever>
qt56.qmakeHook has to also be in the -p flag
<clever>
so the setup hooks have to generate a modified qmake, based on what you put into buildInputs
<clever>
but with nix, that would lead to qmake depending on every single module you can possibly enable, and now you cant cut out un-needed things
<clever>
normally, qmake has the paths of all of the libs built into it, and qtcreator will just query qmake to find them all
<clever>
so you have to reconfigure qtcreator every time you reboot
<clever>
goibhniu: but the problem, is that the tmp folder gets wiped after a shutdown, and that qmake is generated by the setup hooks when you enter nix-shell
<clever>
goibhniu: last time i messed with qtcreator, i had to run "type qmake" to find a qmake binary in a tmp folder, then added that to qtcreator as a qt kit
<clever>
it will now eval this chunk of bash script, before it runs ./configure, so $out is a normal env variable at this stage
<clever>
tmobile: once the version of nix is bumped, you can use builtins.placeholder for that, until then, you need to append to it at the bash level
<clever>
asymmetric: i think i would just put it under pythonPacakges to give people a choice if they want to use a different python for whatever reason
<clever>
asymmetric: youtube-dl isnt a library, but it is under pythonPackages
<clever>
klros: cant really name one source, ive sort of read every page of the docs, and a decent chunk of the source in nixpkgs
<clever>
klros: just download that file to kubernetes.nix and make an override that does kubernetes = pkgs.callPackage ./kubernetes.nix {};
<clever>
depends on what you alter and if you break it or not
<clever>
klros: yeah, if you change how its built, it will automaticaly fetch the source, and build it acording to the new directions
<clever>
nix-env -u will only sync it to what is currently in nixpkgs, you need to also update nixpkgs first, which is nix-channel's job
<clever>
just latency and packet loss to deal with
<clever>
entire thing stays within my house, but my download speed is fast enough that it could potentialy keep up
<clever>
to the NAS in the other room
<clever>
so when grub tries to use the legacy bios API's, it winds up going over the LAN
<clever>
ipxe is configured to hijack bios device #0, and re-route it to an iscsi server
<clever>
rly: my laptop is doing that, lol
<clever>
rly: also keep in mind, it affects disk usage in /boot, most of the people ive given that to had to turn it down because /boot was full
<clever>
rly: boot.loader.grub.configurationLimit
<clever>
rly: yeah, one sec
<clever>
rly: there is a "powertop" util ive used to track that down on laptops
<clever>
earldouglas: part of your problem, is that fetchgit doesnt keep the .git dir, so your previous hash was likely including that
<clever>
earldouglas: nix-prefetch-git
<clever>
and --rollback just undoes whatever the last operation was
<clever>
if you -i something you already have, it will upgrade
<clever>
no need to --upgrade, and --rollback doesnt take -A
<clever>
or remove it if it wasnt present in the last version
<clever>
simendsjo: the entire mystuff package is one atomic unit, so a rollback will downgrade the whole thing at once
<clever>
simendsjo: manage that in git, and you have less to remember when you want to upgrade or reinstall
<clever>
simendsjo: so i can just nix-env -iA nixos.mystuff, and everything from line 15-38 gets installed
<clever>
simendsjo: yeah, thats one option, i'm a bit torn between configuration.nix being enough to rebuild the entire thing, and being able to select what rebuilds each time
<clever>
simendsjo: if you put chromium only in nix-env, and put enableWideVine into ~/.nixpkgs/config.nix, then it will only have to build chromium when you tell nix-env to update
<clever>
simendsjo: yep
<clever>
griff__: or its going to try to download ~80gig of packages, every single thing under the sun
<clever>
griff__: you generaly want to make a derivation and tell it what you want to build from nixpkgs
<clever>
it was doing that on my end recently
<clever>
simendsjo: i think enableWideVine causes a rebuild of chromium
<clever>
simendsjo: nothing chromium related?
<clever>
it updates once a day, at 2:15 am
<clever>
and nixpkgs.config is an entry in configuration.nix
<clever>
updatedb cant be ran manualy, it needs a service setup in configuration.nix
<clever>
also, nix-env stuff isnt updated by nixos-rebuild, so it will just not update, which might be what you want
<clever>
then one in nix-env will use ~/.nixpkgs/config.nix
<clever>
the one in systemPackages will use nixpkgs.config
<clever>
simendsjo: depends, is chromium in nix-env -q or systemPackages?
<clever>
simendsjo: what do you have in nixpkgs.config ?
<clever>
its because nix has no real way to figure out the old state, the purity of the system stops it
<clever>
simendsjo: are you on 32bit or 64bit?
<clever>
simendsjo: nix has no way of doing that, it either updates everything, or it updates nothing
<clever>
and why i try to always use absolute paths in things i build on nix
<clever>
thats why i avoid having certain tools installed globally
<clever>
but then it should be fixed
<clever>
and it will eventualy break when somebody doesnt have it
<clever>
yeah, if something happens to already be in $PATH on the devs system, they may not notice it depends on that
<clever>
you can only find something you have been explicitely given thru the expression
<clever>
and because everything is in nearly random paths under /nix/store, you cant find something your not supposed to be using
<clever>
nix solves that by just clearing $PATH at the start of a build
<clever>
yoou can create that symlink inside the chroot
<clever>
cd /media/sda4 ; chroot . ./nix/var/nix/profiles/system/sw/bin/bash
<clever>
it also helps sometimes to use relative paths with chroot
<clever>
Havvy: and double-check the symlinks youve made to ensure they will remain valid inside the chroot (they must lack /media/sda4)
<clever>
Havvy: you may need to symlink /nix on the host to /media/sda4/nix
<clever>
Havvy: yep
<clever>
Havvy: it should be at /media/sda4/boot/ before you chroot
<clever>
Havvy: and if you have a boot partition, mount that as well
<clever>
Havvy: and make sure to only use "nixos-rebuild boot", switch wont like the chroot
<clever>
Havvy: then i think you can chroot /media/sda4 /media/sda4//nix/var/nix/profiles/system/sw/bin/bash and export PATH=/run/current-system/sw/bin
<clever>
Havvy: that should get the bulk of the mounts, then you want to symlink /media/sda4/run/current-system to /nix/var/nix/profiles/system (the symlink will only be valid after the chroot)
<clever>
Havvy: mount --bind /dev /media/sda4/dev ; mount --bind /proc /media/sda4/proc ; mount --bind /sys /media/sda4/sys ; mount -t tmpfs tmpfs /media/sda4/run
<clever>
Havvy: have you used chroot before to do this to another distro?
<clever>
Havvy: is the host also nixos?
<clever>
signal4: and i think it only happens if you are building the same version of glibc that you are currently running
<clever>
signal4: the /bin/sh impurity would have to be fixed first
<clever>
-Q and -j 8 can speed things up, some
<clever>
normally, the binary cache fills the gap in, so nobody ever notices
<clever>
and then sh isnt valid, so the rebuild fails
<clever>
and when rebuilding it, that key part of sh gets omited from the sandbox
<clever>
there is a key part of the sh closure, that can be deleted by garbage collection, but is needed to do the rebuild
<clever>
there is also a weird problem if you ever garbage collect