2017-05-15

<clever> bennofs: it looks for that path in the db
<clever> bennofs: it looks for /nix/store/<hash>-<name>
<clever> bennofs: i believe nix puts the rev into the name of the derivation, to prevent that
<clever> ambro718: not sure then
<clever> ambro718: do you have keepDotGit set?
<clever> "fun"
<clever> katyucha: and then the string ends on line 85 with another ''
<clever> katyucha: line 81 is the problem, you start a string with ''
<clever> katyucha: can you pastebin the entire file?
<clever> is that inside a string or not?, its not clear what listen does
<clever> oh wait
<clever> katyucha: you can just remove the ${ and } on those lines
<clever> ah, then you need to give it a ghcWithPackages that has them already?
<clever> eacameron: ive heard that it will use nix-shell to get the right ghc version, but otherwise ignore all of haskellPackages
<clever> ah
<clever> somebody in here has done related work recently, cant remember who
<clever> the 3 minimal attributes are just utils it will need, build does 90% of the work, and dist tar's it up
<clever> looks like -A armv7l.dist is the main attribute you want
<clever> dhess`: i dont think make-bootstrap-tools-cross will be able to make a ghc cross-compiler, since thats a more complex beast
<clever> so you can reference any attr within it
<clever> dhess`: https://pastebin.com/fU8Yv0QG nix-repl says armv7l is an attrset
<clever> i think he missed a few instances
<clever> git log says it was removed on april 25th
<clever> same
<clever> so nix-build pkgs/stdenv/linux/make-bootstrap-tools-cross.nix -A armv7l
<clever> dhess`: line 1, the entire nix file appears to be stand-alone
<clever> dhess`: and line 302
<clever> dhess`: line 90
<clever> this one is for making a native bootstrap tools
<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> (imagemagick.overrideAttrs (old: { src = fetchurl { .... }; })
<clever> you would need an override
<clever> imagemagick
<clever> you must use attribute paths, not names
<clever> it also needs -i
<clever> ah
<clever> as does yours
<clever> Infinisil: my irc client has an /exec -o command
<clever> and nix doesnt really install dependencies, it just downloads them to the /nix/store and things work without having to install them
<clever> nix-env -f default.nix
<clever> thats just a random trick for making a .desktop file for jvisualvm
<clever> nope
<clever> kiloreux: if its going into a default.nix, it will look a little different
<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> then you probably want __noChroot
<clever> FRidh: and if nix.conf allows it, there is a __noChroot=true; option for derivations (it needs build-use-sandbox=relaxed i think)
<clever> FRidh: any fixed-output derivation has network access automatically
<clever> not sure then
<clever> ericnoan: did you configure a static ip in configuration.nix?
<clever> sdll: for -p, you need to set -I nixpkgs=/path/to/nixpkgs
<clever> sdll: depends on if you are using nix-shell -p or nix-shell -A
<clever> but -iA just gives it the attribute path
<clever> which means evaling every single package in nixpkgs
<clever> -i will try to find a package who's .name attribute matches
<clever> sdll: and also try to use -iA instead, its a lot faster
<clever> sdll: remove the /pkgs at the end of the nix-env command
<clever> rcschm: heading off to bed now, goodnight
<clever> so you want to make sure its already in bin before you wrap
<clever> which may break the wrappers
<clever> the fixupPhase will move everything in sbin to bin
<clever> rcschm: this should fix it
<clever> '';
<clever> wrapProgram $out/bin/arangod --add-flags "~/testdata --server.authentication false"
<clever> mv $out/sbin/arangod $out/bin/arangod
<clever> postInstall = ''
<clever> another ls should confirm that
<clever> its probably in sbin
<clever> you need to move it from sbin to bin before you wrapProgram it
<clever> ah
<clever> rcschm: ls -lh /nix/store/w00iivkr5awnvi7zg13h5qkhvb66fz90-arangodb-3.2/bin
<clever> and then you can use those bash functions in any phase
<clever> rcschm: when you add makeWrapper to the buildInputs, nixpkgs will source this script
<clever> yeah
<clever> no need to list them
<clever> and since you have 'with import <nixpkgs> {};', every single derivation is in scope
<clever> so buildInputs = [ makeWrapper ];
<clever> makeWrapper is the name of the derivation
<clever> i named it wrong
<clever> oh
<clever> rcschm: { stdenv, wrapProgram, other, stuff }:
<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> yeah
<clever> matthewbauer: https://pastebin.com/SsUyHVXE
<clever> it could preset everything and just work
<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: like https://www.sparkfun.com/products/12568
<clever> gchristensen: an xbee radio
<clever> gchristensen: this is a custom mod i made to my eeepc 701 netbook a while ago
<clever> github link is in the description
<clever> matthewbauer: been working on one of those on&off
<clever> and now you can find the config for the service on any distro
<clever> check the cli first for a -f or -c flag, then check /etc/foo/
<clever> and that can carry over to other distros
<clever> i find that nixos forces you to learn more internals, like how to figure out what config file service xyz is using
<clever> :D
<clever> i also have a c64, vic20, snes
<clever> packrat, lol
<clever> oh, the one in that image has the 3g modem!
<clever> gchristensen: here is how it looks without the keyboard or lcd, https://i.ytimg.com/vi/5A1UQRDIyTc/maxresdefault.jpg
<clever> gchristensen: 1 is smartcard (never got it to work in linux), 2 is the pcmcia, and right under 2 is the sata hdd
<clever> :D
<clever> gchristensen: its in a different place on my model, lets see what the image search has
<clever> its just barely visible
<clever> there is a smartcard reader right under the pcmcia slot
<clever> and most of the time, they are poppulated with a wifi card, a dialup modem, and an empty port for the 3g
<clever> that model has a total of 3 mini-pcie bays
<clever> gchristensen: so if you put the proper 3g modem into the mini-pcie slot inside, you will have an internal cellular modem
<clever> gchristensen: and under the battery, is a sim card slot: https://d3nevzfk7ii3be.cloudfront.net/igi/gOwRUU6PDKxyg6G6
<clever> gchristensen: there is also a smaller battery, that just doesnt have the black handrest
<clever> gchristensen: see the battery on the left side, with the large black handrest?
<clever> not even a pci bus
<clever> no cd drive, no sound card
<clever> this laptop is grey scale lcd, ~20mb of ram, and a 486 cpu
<clever> 120vac in, 18vdc out, directly plugged into the motherboard
<clever> thats the power brick
<clever> gchristensen: see the bulge between the lcd panel hinges?
<clever> gchristensen: oh yeah, another neat thing ive seen change over the years
<clever> gchristensen: but they where clever, and they made the bulge into a wrist rest
<clever> gchristensen: this laptop can take an extra-large battery, that doesnt fit in the battery bay
<clever> gchristensen: see the wrist rest at the bottom of the image?
<clever> gchristensen: but the side bay is a different shape, so you need a special battery for the side bay
<clever> gchristensen: the next dell up that i have used, it takes 1 battery in the bottom, and a cd/floppy/battery on the side
<clever> thats how old it is
<clever> gchristensen: the cpu maxes out at 1ghz i think, and it had no wifi built in :P
<clever> gchristensen: and both bays accept the same type of battery, so you can freely put either battery in either bay
<clever> gchristensen: with this laptop, you have 2 bays, one can take only batteries, the other can take a cd/floppy/battery
<clever> gchristensen: http://i.dell.com/das/dih.ashx/500x500/das/xa_____/global-site-design%20WEB/521fe103-c9e2-9b87-6525-4c2b4f87efb2/1/OriginalPng?id=Dell/Product_Images/eSupport/notebooks/latitude_notebooks/laptop-latitude-c600-overhead-esupport-149.jpg
<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> Fare: can you gist the nix file?
<clever> oh, do you have a custom buildPhase?
<clever> Fare: that will omit /run/current-system
<clever> Fare: run nix-shell with --pure
<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)
<clever> johnramsden: https://nixos.org/nixos/options.html#containers.<name>.hostbri
<clever> Fare: did you run unpackPhase first, and cd into the source dir it made?
<clever> johnramsden: this will register the nixos containers to a bridge when they start
<clever> johnramsden: ah, found it, containers.<name>.hostBridge
<clever> Fare: it has to be ran on a directory
<clever> Fare: there is also a patchShebangs function, that will fix all #!'s for you, including #!/usr/bin/env
<clever> rcschm: so you need to clear the postPatch, not patchPhase
<clever> rcschm: the substituteInPlace stuff is in the postPatch hook
<clever> Fare: /bin/sh is available always, glibc requires it
<clever> Fare: only if sandboxes are disabled
<clever> johnramsden: but things like lxc are free to mutate the network stack imperatively
<clever> johnramsden: bridges.<name>.interfaces is a list of things nixos will enslave to <name> on bootup
<clever> rcschm: what command did you run to cause that error?
<clever> johnramsden: it can probably be done, i just havent tried it with nixos containers
<clever> johnramsden: in my case, the nixos containers arent tied to a bridge, so i need to perform NAT to make the network work
<clever> 6: ve-mc1@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
<clever> johnramsden: yeah, eno1 has to be slaved to br0, and then you tell systemd-nspawn to link the guests into br0
<clever> Fare: nix-shell is better suited to that task, nix-shell '<nixpkgs>' -A foo, then run unpackPhase; cd $sourceRoot; configurePhase; buildPhase
<clever> Fare: that should skip the 20minute rebuilds
<clever> Fare: you can try copying the defective binary to your home directory, and then try different ways of patching it
<clever> johnramsden: and both eth0 and vif8.0 are slaved to br0, so packets can cross between them
<clever> johnramsden: in this case, vif8.0 is linked to dom8 in xen
<clever> 16: vif8.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP qlen 1
<clever> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP qlen 1000
<clever> root@klingon:~# ip link