<clever>
but if you hack the hdd firmware, you can probably bypass that
<clever>
jsgrant_om: sata drives might have the old ata lock command, that can be accessed via hdparm i think, and some bios may prompt for it before starting the boot
<clever>
jsgrant_om: biggest problem, is that the rpi boot rom must load bootcode.bin from the sd card, so it cant boot until a pw has been entered
<clever>
jsgrant_om: its not clear, but it may not even encrypt the data, it would be possible to implement it by just turning reads off until a password has been given
<clever>
rcschm: "sudo -i" will run a shell as root
<clever>
sphalerite: what does nixos-version say?
<clever>
rcschm: so you would need to run nix-shell, use the bash functions, then manualy run zsh
<clever>
rcschm: part of the issue is that nix-shell pre-loads a large number of bash functions into the shell you get, and those likely wont work right with zsh
<clever>
sphalerite: yeah, looks like different config on your end
<clever>
nh2: what version does "which nix-build" show?
<clever>
qknight_: hmm, what does this say: journalctl -f -u hydra-evaluator
<clever>
qknight_: is the hydra gui public?
<clever>
hyper_ch: what does "ip -6 addr" and "ip -6 route" say?
<clever>
orbekk: yeah, manual git pull/push to sync the machines up and nixos-rebuild
<clever>
hyper_ch: that paste was from a nixos 16.03 netboot
<clever>
orbekk: so desktop.nix does stuff for my desktop, laptop.nix does my laptop, router.nix does the router, and core.nix covers common things to all of them
<clever>
nh2: jan 1st 1970, minus your timezone offset
<clever>
orbekk: currently, i have a /etc/nixos/nixcfg in git, configuration.nix just does imports = [ ./nixcfg/laptop.nix ]; and then laptop.nix imports ./core.nix and so on
<clever>
dash: might want to look into that warning also
<clever>
Making all in protocol
<clever>
/tmp/nix-build-glusterfs-3.10.1.drv-0/glusterfs-3.10.1-runner-log/xlators/storage/posix/src/posix.c:351: warning: lchmod is not implemented and will always fail
<clever>
heh
<clever>
nope
<clever>
and 2, including argv[0], when it isnt, just <dirpath>
<clever>
it wants 3, including argv[0], when stdin IS a tty
<clever>
oh, that not in the if
<clever>
double-checking things
<clever>
it asks for 3 arguments when stdin isnt a tty
<clever>
testing something on this end
<clever>
but if stdin isnt a tty, it wants a <dirpath>, 2 other things it doesnt appear to use, and then takes filepaths on stdin
<clever>
if stdin is a tty, it wants a <dirpath> and a <filepath>
<clever>
oh no
<clever>
and if stdin isnt a tty, it also needs a dir that it will chdir into
<clever>
oops, with a space between touch and b
<clever>
this returns 0
<clever>
mkdir a;touchb;gfid_to_path.py a b
<clever>
nh2: harder to use the diff's on a gist when you keep renaming the files
<clever>
its not using sed to apply pattern changes
<clever>
substituteInPlace is written purely in bash
<clever>
i'm using nix-build so i dont spam grub up with 200 revisions of testing
<clever>
ah, because it wants a python library from $out/lib, not from its inputs
<clever>
hmmm, glusterfind currently fails with no args, cant import glusterfind.main, checking...
<clever>
need a simple way to test them all
<clever>
do most of the programs try to load deps even with --help or --version?
<clever>
if thats still needed
<clever>
so that has to go after the withPackages
<clever>
nh2: oh, i think python2 was providing toPythonPath
<clever>
Guest89871: both of them will produce the exact same thing when installed to the system, given the same configuration.nix file
<clever>
Guest89871: the minimal iso had no xorg, while the graphical iso has kde on startup
<clever>
that pythonhome should also entirely eliminate the need to set pythonpath
<clever>
removing the duplicate python2 from buildInputs should also fix it
<clever>
nh2: and nativeBuildInputs is scanned before buildInputs, thats why it had a higher priority and fixed things
<clever>
nh2: and it takes the first python it can find to patch into the #!
<clever>
nh2: you have python2 AND python2.withPackages in the buildInputs
<clever>
nh2: yep, there it is
<clever>
nh2: oh, i think i see the problem
<clever>
nh2: and what about the first line of .eventsdash.py-wrapped?
2017-05-09
<clever>
ok, i see how its currently working, let me see what i can debug with it
<clever>
can you gist the relevant nix expressions and maybe i can look at it?
<clever>
when your not doing a crosscompile, the buildInputs will just be silently renamed (and appended to) the nativeBuildInputs
<clever>
but if you have a 2nd package that depends on X and other python stuff, it may need to make a new python2.withPackages over [ X other python stuff];
<clever>
what i said before will embed the result of $(which python) into the #!, so that gets the wrapper
<clever>
you need to embed the paths of things into the final output
<clever>
nh2: it helps to keep in mind, buildInputs and propagatedBuildInputs will not just be available in the search path at runtime
<clever>
nh2: i dont think it would be able to merge the 2 python wrappers correctly, so it might be better to put python2Packages.flask into the propagatedBuildInputs, in addition to withPackages in the buildInputs
<clever>
which you probably dont want/need
<clever>
if you put the withPackages into propagatedBuildInputs, then that python will leak into every derivation your package is in the buildInputs of
<clever>
which should be the python2.withPackages python
<clever>
nh2: this will basicaly replace /usr/bin/env python with the output of $(which python)
<clever>
not entirely sure, windows 64bit is a bit weird
<clever>
philipp[m]: and the nixos option hardware.opengl.driSupport32Bit gives you 32bit opengl libs, which you may still need for 32bit exe's under wine
<clever>
philipp[m]: wine.override { wineBuild = "wineWow"; }; will create a 64bit capable wine build
<clever>
same
<clever>
strange, it appears that rec has a higher priority then with
<clever>
you may also want to update the system to the next stable release channel, 16.09 is a bit old now
<clever>
you can delete the nixos channel on the non-root account, and it should still be able to use the nixos on root
<clever>
while the nix-env command you gave, uses the nixpkgs-unstable version of google-chrome
<clever>
so the nixos-rebuild command as root, use roots version of the 16.09 channel
<clever>
tywkeene: and you have a nixpkgs channel on your user, that follows nixpkgs-unstable
<clever>
tywkeene: you have 2 copies of the nixos channel (with and without root), that follow nixos-16.09, but on different versions (each user has to nix-channel --update)
<clever>
tywkeene: then you have 3 different channels on your system
<clever>
tywkeene: what does "nix-channel --list" say?
<clever>
that at least needs a valid github account, which will cut down on some of the spam
<clever>
it had spam problems, and after going read-only, it suffered from being more wrong as time went on
<clever>
the wiki was just put out of its misery today
<clever>
tywkeene: testing the 16.09 version of google-chrome now
<clever>
the nixos-unstable channel is the latest you can safely use
<clever>
yeah
<clever>
what does "sudo nix-channel --list" say?
<clever>
which channel are you on?
<clever>
but i got .133, while you where getting .110