<clever>
dhess`: yeah, you would have to start by patchelfing the debian ghc, and using that as a one-time bootstrap
<clever>
nixpkgs also has a derivation to cross-compile that tar
<clever>
dhess`: so you can at any time, update the bootstrap tools to match the current versions in nixpkgs, then paste the url to that new tar into nixpkgs
<clever>
dhess`: i'm thinking of basing it on how nix handles the gcc bootstrap, there is a nix derivation that can make a new bootstrap-tools.tar
<clever>
dhess`: then the tarball of that nixified one can be entered as the bootstrap ghc for nixpkgs
<clever>
dhess`: in theory, i think you could use a patchelf'd ghc as a bootstrap, to build a proper nix-ified ghc
<clever>
katyucha: you probably want -I nixpkgs=$myNix/nixpkgs
<clever>
katyucha: so it checked for the existance of $myNix/nixpkgs/nixpkgs
<clever>
katyucha: you told it to look for nixpkgs inside $myNix/nixpkgs
<clever>
oh, and cd $sourceRoot
<clever>
ambro718: if the source was already unpacked
<clever>
ambro718: if its something cmake based, you can change the unpackPhase = "sourceRoot=$src";, and it might work
<clever>
jbo: are you able to pick an older nixos from grub?
<clever>
i generaly do that kind of thing in configuration.nix instead
<clever>
kiloreux: you can make a buildEnv derivation, that lists things, and then install that instead
<clever>
kiloreux: can you give an example?
<clever>
though id guess both tools would
<clever>
that might find ssh public keys though
<clever>
but it can also find new words being added to the repo
<clever>
gchristensen: the original idea i had, was to use it to find potential passwords in git history
<clever>
gchristensen: something that can go over the nix expressions, and generate stats for the number of times every 'word' is used, and if words are added
<clever>
gchristensen: oh, i was thinking about a tool for nix, that would help with the powerManagment issue above
<clever>
i always use the curl | sh installer
<clever>
ah, dont know about that then
<clever>
ij: how did you install nix?
<clever>
its only a month old, just skip the alias
<clever>
maurer: auto-generated from the options attrset
<clever>
maurer: yeah, one less e in the module
<clever>
nixos/modules/tasks/powertop.nix: options.powerManagment.powertop.enable = mkEnableOption "powertop auto tuning on startup";
<clever>
maurer: do you see powertop listed in 'man configuration.nix' ?
<clever>
maurer: yeah, i would expect that to just work
<clever>
maurer: can you gist your configuration.nix file?
<clever>
it will just be called channels when on root
<clever>
maurer: what does this say?
<clever>
ls ~/.nix-defexpr/channels_root/nixos/nixos/modules/tasks/powertop.nix -lh
<clever>
yeah, it should already be in that revision
<clever>
maurer: what does nixos-version say?
<clever>
maurer: the module was added to nixos about 1 month ago, which channel are you on?
<clever>
and the nix expression can only make use of those values and nothing else
<clever>
line 1 defines a function, that takes a certain set of arguments
<clever>
you need to add wrapProgram to the arguments on line 1
<clever>
that would also get rid of the purity that is the foundation of nix
<clever>
not currently
<clever>
and pkgs.wrapProgram has to be in buildInputs i believe
<clever>
rcschm: just wrapProgram should do
<clever>
the newer ones
<clever>
so the rpi2's are aarch64 without the wifi/bluetooth chip
<clever>
matthewbauer: but to save costs, they are now shipping rpi2's, with the rpi3 cpu
<clever>
matthewbauer: another oddity to keep in mind, the rpi3 has onboard wifi and the aarch64 capable cpu
<clever>
dash: probably pretty poor
<clever>
yeah, ive limited my own hydra to a small subset
<clever>
matthewbauer: they lack v6 and v7 backwards compat
<clever>
matthewbauer: another problem, is that the aarch64 build slaves for hydra, can only run aarch64
<clever>
matthewbauer: i dont think v6 is worth that much, but v7 may be
<clever>
matthewbauer: and rpi3 is armv6, armv7, and aarch64
<clever>
matthewbauer: the rpi2 can run v6 or v7
<clever>
matthewbauer: the rpi1 is armv6
<clever>
matthewbauer: thats only for the rpi3, wont work for the 1 or 2
<clever>
simpson: my build slave is raspbian with nix on the side
<clever>
no binary cache support
<clever>
building them
<clever>
simpson: i think it takes maybe a week for my hydra to get the bulk of the deps on a v7
<clever>
simpson: yeah, its pretty damn slow
<clever>
and it has no way to query features that only a subset of the partition table types can handle
<clever>
they made the api a bit too abstract
<clever>
matthewbauer: but one critical problem i ran into with libparted, is that it has no way to read the uuid of partitions, so i cant directly enter them into fileSystems. in configuration.nix
<clever>
matthewbauer: it uses libparted to partition the disk
<clever>
matthewbauer: this is from the pre-html gui, when it was all in QT
<clever>
i'm guessing nixpart could be configured to handle things for you
<clever>
matthewbauer: if you take the hex for the 'bios boot partition' type code, and treat it as ascii, you get "Hah!IdontNeedEFI"
<clever>
matthewbauer: and for extra fun, gpt uses 2 uuid's for every partition, a uuid that is globally unique to that partition, and a uuid type code
<clever>
now grub overwrites it with x86 code, and everything breaks
<clever>
and some users try to flag /boot as the bios boot partition
<clever>
and they all have different names for it
<clever>
the issue i see with most users here, is that almost no partitioning tool calls it the bios boot partition
<clever>
matthewbauer: all make sense?
<clever>
and now its correctly flagged as in-use
<clever>
so the partition just contains raw x86 opcodes
<clever>
and when you set boot.loader.grub.device = "/dev/sda";, grub will find the bios boot partiton, and put stage 1.5 in there
<clever>
you must make a special partition, of type 'bios boot partition', no filesystem, it never gets mounted, you dont need to format it
<clever>
so some new rules have been laid down to keep things orderly
<clever>
so that 'free space' region is no longer safe to just blindly use
<clever>
but, GPT partition tables use more then sector 0
<clever>
it can then load the rest from /boot/grub/i386-pc/ at runtime
<clever>
stage 1.5 is the grub kernel, hard-linked to a filesystem driver that supports whatever /boot is on
<clever>
and there is no way to know that the 'free' space isnt free
<clever>
if sda is MBR partitioned, it will put a stub into the MBR, then put stage 1.5 in the FREE SPACE between sector 0 and the 1st partition
<clever>
it will detect a filesystem on sda1 that doesnt support embeding, and fail to grub-install
<clever>
sda1 is the boot partition, that also means its the grub device, right? (nope!)
<clever>
and some users (including myself) have tried setting grub.device = "/dev/sda1"
<clever>
yeah, but nixos-generate-config doesnt know what the grub.device should be set to (nothing if efi!)
<clever>
but if there was a gui, that gave you a few different boot methods, legacy grub on mbr, efi grub, efi systemd-boot, legacy grub on gpt
<clever>
matthewbauer: ive seen users that are unable to set a simple flag on a partition to make it bootable, countless times
<clever>
matthewbauer: another reason ive been wanting to finish that installer, is that some people just cant seem to partition the disk right for booting
<clever>
and maybe 2 more for ( if things span multiple lines, but i try to break it up into seperate statements in the let block
<clever>
and also 2 spaces for ''
<clever>
i usualy do 2 spaces for each {
<clever>
so the file would become an unreadable mess, or get reformated, and will probably loose all comments
<clever>
i think hnix can mostly do it right now, but it looses whitespace
<clever>
without causing duplicates, and without breaking any fancy nix expressions the user may have
<clever>
matthewbauer: i want to have a command that can take an existing configuration.nix file, and set services.xserver.enable = true;
<clever>
matthewbauer: waiting for a project like hnix to progress more, so i can load configuration.nix, insert/overwrite a given attribute, and serialize it again
<clever>
matthewbauer: thats part of why the project is stalled, i need to get an AST of configuration.nix if i want to make further changes programaticaly
<clever>
matthewbauer: or you could boot it on a cd locally, and just http://localhost it, and install
<clever>
matthewbauer: so you could boot the iso on a remote box in a datacenter, then load this page up over the web, and install nixos
<clever>
matthewbauer: my original idea, was to allow doing the entire install over http
<clever>
goodnight :)
<clever>
and yesterday, i swapped the lcd panel out for one with a webcam, so i had to remove that mod
<clever>
never really worked right
<clever>
but it was a fractal chip antenna, and there is a crap-ton of rf shielding on the case
<clever>
and now it has internal xbee
<clever>
so i just unsoldered the mini-b, and soldered the ftdi to a jst cable
<clever>
thats what the 3 white and 1 black wire are
<clever>
gchristensen: there is a 4 pin JST connector on the motherboard, for a webcam, but its just usb
<clever>
gchristensen: in the old days, you could replace the cd drive with a second battery, then laptops ditched that feature, and now they are bringing it back, but as a giant wart you have to hang off a cable
<clever>
gchristensen: also, they appear to be reinventing the wheel
<clever>
gchristensen: that sounds like a fun bug in the bios
<clever>
Fare: i would patch it before the build, to use absolute paths
<clever>
nothing else that i can think of right now
<clever>
Fare: the fixup phase normally removes things from rpath, to optimize the size of the closure
<clever>
Fare: gcc sets the rpath up for you
<clever>
Fare: which normally runs after install, and does some misc cleanup of the output files
<clever>
Fare: dontFixup=true; will skip the fixupPhase
<clever>
bash is a bit weird, and you can have both a buildPhase function, and a $buildPhase variable
<clever>
Fare: yeah, you have a custon buildPhase, so you need to eval "$buildPhase"
<clever>
johnramsden: that left the machine unable to shutdown
<clever>
johnramsden: i have also managed to crash pid 1 on the host by pointing systemd-nspawn at a broken fuse filesystem
<clever>
Fare: it can only take a directory, and it will patch every file in that directory
<clever>
johnramsden: i think the entire containers. attrset is limited to nixos guests, you would need to manualy run systemd-nspawn to do others (lxc probably does that for you)