2017-04-02

<clever> calvertvl: one option is to just turn sub-modules off entirely, then manualy copy things in like https://github.com/nixos/nixpkgs/blob/master/pkgs/games/multimc/default.nix#L23-L25
<clever> hmmm, partition table looks a little strange, but if its already the one in the iso, its probably good
<clever> yep, looks just fine, try booting that now
<clever> and fdisk?
<clever> once the dd is done, double-check it with fdisk -l /dev/sdc
<clever> yeah, that is a disk
<clever> oh, and also, what does "ls -l /dev/sdc" say?
<clever> and try running sync
<clever> that might be the write cache cheating, check the activity light
<clever> what exactly did it output when ran?
<clever> fresheyeball: are you sure its the right sdX?
<clever> fresheyeball: no, that generaly means that no card is in the card reader
<clever> sure
<clever> and the ticket says that the label on the disk image must be set to NIXOS_ISO, which the iso already has
<clever> the iso is already a valid usb disk image, it doesnt need any special tools
<clever> try using just dd
<clever> fresheyeball: how did you make the usb stick?, you should be able to just dd the iso to sdf

2017-04-01

<clever> Svarog: i dont think it records it anywhere, but for a given nix expression, it will always give the same result
<clever> Svarog: for systemPackages, i think its whichever came first, for nix-env, its a fatal error and you must set a priority
<clever> Svarog: you would need to run it on the derivation that /run/current-system/sw points to, to get the collisions for the current environment.systemPackages
<clever> Svarog: that will show the build log for foo, and if it was something like system-path, the collisions within
<clever> Svarog: run nix-store -l /nix/store/foo
<clever> ndowens08: yeah
<clever> ndowens08: nix-shell -p nixUnstable
<clever> try running file on it, and check uname -a
<clever> cant think of anything else to check right now
<clever> neeasade: so this directory exists?
<clever> [clever@amd-nixos:~]$ ls /run/opengl-driver-32
<clever> alphor: and preStart just automaticaly gets written to a bash script, whose path is put into ExecStartPre
<clever> alphor: i believe ExecStartPre must start with an absolute path, and can only contain a single command
<clever> Drakonis: and for that, clangStdenv.mkDerivation

2017-03-31

<clever> exarkun: as long as the db.sqlite can downgrade cleanly
<clever> exarkun: you could just change the channel afterwards and nix-env -iA nixpkgs.nix to install the older nix
<clever> pmahoney: simply adding cmake to the buildInputs causes this script to get sourced, which will mutate how the stdenv behaves, causing it to run cmake instead of ./configure
<clever> pmahoney: have a look at how things like cmake work in nix: https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/tools/build-managers/cmake/setup-hook.sh
<clever> pmahoney: about the only way to improve it, is to modify librsvg to store the path in a variable within $out/nix-support/setup-hook.sh, which will get sourced by anything with librsvg in buildInputs
<clever> pmahoney: and thats relatively expensive, and forces thing to build in a weird order
<clever> pmahoney: i suspect thats also doing import from derivation, so it has to download (or build) librsvg before it can finish the nix eval

2017-03-30

<clever> kuznero: here is how i solved a git submodule a few months ago: https://github.com/NixOS/nixpkgs/blob/master/pkgs/games/multimc/default.nix#L23-L24
<clever> spinus: yeah, an override or overlay will stick long term and have little maintaince cost
<clever> spinus: thats usualy the easyer way, but it gives you more work in the long-term, to maintain the change
<clever> spinus: so now the debug info in gdb is targeting only the area of the backtrace that has a segfault
<clever> spinus: this rebuilds gtk and libnl with debug symbols, then builds a non-debug wireshark against the debug gtk+libnl
<clever> spinus: one neat override ive done before, wireshark = pkgs.wireshark.override { gtk = pkgs.enableDebugging pkgs.gtk; libnl = pkgs.enableDebugging pkgs.libnl; };
<clever> lol
<clever> demax: everything is being moved to documentation on the site, which is stored witnin the git repos
<clever> kuznero: that will probably change when 17.03 becomes official
<clever> ls sorts by name by default, so its hard to notice (ls -U disables all sorting)
<clever> which can vary from filesystem to filesystem, and the order they where made in
<clever> i think tar just leaves them in the same order they where in on-disk
<clever> and it cant store uid or timestamps
<clever> yep
<clever> nix-channel --add https://nixos.org/channels/nixos-17.03 nixos
<clever> kuznero: the channel name must be nixos, and the channel url doesnt end in .tar.gz
<clever> kuznero: and it is the channel that is responsible for loading configuration.nix, so its too late to change things by the time its parsing
<clever> kuznero: it can only be changed by running nix-channel, no config in configuration.nix can control what channel it uses
<clever> kuznero: nix-channel should be ran as root
<clever> kuznero: add the new channel with "nix-channel --add URL nixos" and then nixos-rebuild boot and reboot
<clever> shlevy: :O
<clever> yumbox: nix always builds things as a non-root user, that cant modify things it shouldnt modify
<clever> yumbox: it wont help
<clever> yumbox: it may also need qt5.qmakeHook in the buildInputs
<clever> { stdenv, fetchgit, cmake, qt5 }:
<clever> yumbox: what is currently on line 1 of the file?
<clever> yumbox: you need to also put qt5 into the arguments on line 1
<clever> did you put qt5.qtbase into the buildInputs?
<clever> it also has to go into the buildInputs
<clever> did you put cmake into the buildInputs ?
<clever> correct
<clever> nix-build -E 'with import <nixpkgs> {}; callPackage ./yourthing.nix {}'
<clever> fetchgit
<clever> yumbox: src = fetchFromGitHub { owner = "foo"; repo = "bar"; rev = "abcd"; sha256 = "...."; };
<clever> yumbox: just put cmake into the buildInputs, and it handles CMakeLists.txt for you
<clever> yumbox: which gtk.nix did you edit?
<clever> yumbox: almost
<clever> yumbox: its usualy very easy to just write a nix package for it
<clever> it depends on glibc, ld.so and a few others
<clever> then nix cant track the dependencies correctly, and will delete things you depend on
<clever> nix doesnt allow manualy built things to be installed
<clever> it must be compiled with nix-build if you want to install it
<clever> yumbox: so headers and link flags are lost if you just install it normally
<clever> yumbox: because nix is designed to skip build-time things when you try to install stuff
<clever> yumbox: nix-shell -p gcc qt5.qtbase ...
<clever> yumbox: you should always use nix-shell when you want to build things with nix
<clever> yumbox: are you using nix-shell?

2017-03-29

<clever> and now you have a services. in the top level, which isnt allowed
<clever> but as soon as you add a single config. entry, you now have config.foo ....; services...; in the same file
<clever> so it just works
<clever> the issue, is that if config is missing, it automaticaly wraps your entire module in config = { ... };
<clever> removing the config. should fix the problem
<clever> This is caused by assignments to the top-level attributes `config' or `options'."
<clever> alphor: remove the word config.
<clever> can you throw it in a gist along with the error?
<clever> can you gist the module that is causing the fault?
<clever> all modules must have one of those attributes, and nothing else
<clever> i think in the context of the linked line, that is just part of the api of modules
<clever> dtzWill: then you can repartition it
<clever> dtzWill: you need to "vgchange -a n" to close all LVM devices
<clever> ericnoan: that allows unpatched games to run
<clever> ericnoan: steam uses a FHS chroot to simulate a system with /usr/lib
<clever> pi3r: in other setups, where S3 isnt enabled, that UI does work
<clever> pi3r: all data is now stored on the binary cache
<clever> dtzWill: ah :)
<clever> Dezgeg: but part of the goal of kexec is to be able to umount /
<clever> Dezgeg: most pid1's already have the ability to re-execute /bin/init or similiar, for upgrading
<clever> dtzWill: i have also been considering making the above a nixos option, so you can basicaly boot the installer from grub if you ever break the system
<clever> dtzWill: then just reboot and pick it from grub
<clever> dtzWill: you can also copy the kernel+initrd to /boot and add a grub.conf entry for it
<clever> dtzWill: i recently helped somebody else in a very similiar situation, and the only issue was that kexec doesnt work within a xen dom0
<clever> disasm: ah yeah, all of the service@foo things in systemd lack auto-restart
<clever> dtzWill: so it will restore control to the previous os
<clever> dtzWill: correct, and the auto-reboot timer will cause it to self-reboot at the end of the hour
<clever> dtzWill: just remember to put an ssh key in the right spot and to stop the autoreboot timer in systemd
<clever> disasm: i am able to ssh into the guest from the host
<clever> disasm: yeah
<clever> dtzWill: i believe that is how nixops handles all of the pre-generated stuff on cloud machines
<clever> dtzWill: using LABEL=root for things can simplify that last part
<clever> dtzWill: and keep in mind, you need to correctly specify all of the fileSystem. stuff on the central box, so the builds it pushes out are still able to boot
<clever> dtzWill: i have seen somebody recently run nixos-rebuild by mistake, and it reverted the entire machine back to a fresh install
<clever> dtzWill: and one tip i would give is to delete the configuration.nix once nixops takes over
<clever> dtzWill: oops, wrong d name
<clever> disasm: should be, ive heard that if you set the targetEnv = "none"; it will just nix-copy-closure and activate it
<clever> disasm: nat and port forwarding
<clever> 7am
<clever> yeah
<clever> -I nixpkgs=/home/clever/nixpkgs
<clever> amosbird: -p always uses <nixpkgs> so you need to use -I
<clever> amosbird: simplest option, add it to the overrides in ~/.nixpkgs/config.nix
<clever> or ldflags, yeah
<clever> readline*
<clever> it might not be specifying -lreadlink when linking
<clever> find the .so and run patchelf --set-rpath on it in the build
<clever> yeah, you would need to provide your own python that has been wrapped, or fix the rpath on the python modules
<clever> it will need to wrap the python script
<clever> pie__: i would just add ${readline}/lib to LD_LIBRARY_PATH using makeWrapper
<clever> pie__: where is the source for rpy2?
<clever> are you linking rpy2 with -lreadlink?
<clever> it doesnt cover things at runtime
<clever> the buildInputs only covers libraries at build/link time
<clever> ah
<clever> no need to put the stdenv in buildInputs
<clever> and the error
<clever> pie__: can you gist the nix expression?
<clever> pie__: if the libs are in the lib subdir of another package, just put it into buildInputs

2017-03-28

<clever> jimmy_DM: specificly, https://nixos.org/nix/manual/#ss-functions
<clever> ashkitten: exactly the same syntax
<clever> ashkitten: you can put this into configuration.nix as well
<clever> jimmy_DM: that is a function, accepting certain arguments, and returning an attribute set
<clever> ashkitten: thats better done in the prestart of the proper systemd unit
<clever> ashkitten: nixos should automaticaly restart services when they are modified
<clever> eacameron: ah wait, php-fpm has to specify the php.ini differently
<clever> eacameron: does look usefull, but it will also need a php-fpm wrapper
<clever> eacameron: neat
<clever> erictapen: activation scripts are ran any time a nixos build is activated (on boot, and after rebuild switch), and they are also responsible for creating users
<clever> erictapen: system.activationScripts = ''mkdir and chmod it'';
<clever> erictapen: you will need an activation script that changes that
<clever> erictapen: its hard-coded to 700
<clever> probably one of the lesser documented ones
<clever> gchristensen: this lets me inject <ssh-config-file> into the search path, for only private.nix
<clever> gchristensen: i have also used scopedImport to modify nixPath once
<clever> gchristensen: <nixpkgs> will get translated to this while parsing
<clever> /home/clever/.nix-defexpr/channels/nixpkgs
<clever> nix-repl> builtins.findFile builtins.nixPath "nixpkgs"
<clever> octe: it needs to be in a let block near the top
<clever> unstable-pkgs.foopackage
<clever> eacameron: then every time you nixos-rebuild switch, with zero changes, the ancestor is different, and it will forever rebuild
<clever> eacameron: so it has to be handled at runtime by the perl script
<clever> eacameron: the issue is that the store and nix expressions are all pure, and wont be aware of the previous allocations
<clever> eacameron: so the code in this region would have to be modified, to save name+uid pairs somewhere, and look them up when recreating things: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/config/update-users-groups.pl#L147-L177
<clever> eacameron: the entire users option tree goes into a json file that goes at ${spec}, and the perl script manages mutating /etc/passwd correctly
<clever> eacameron: this line of bash will get ran on bootup, and after a nixos-rebuild switch (and when nixops does a deploy)
<clever> eacameron: the 2nd option would probably be better for users, no visible change in how things work, and the problem goes away
<clever> eacameron: my own fix has just been to always set a uid, but modifying the code to have more state (a history of name+uid pairs) would also solve things without forcing users to pick a uid
<clever> just serving https is trivial with nginx and acme
<clever> eacameron: in my case, i'm doing ssl requests within the php login code, to query other remote servers
<clever> eacameron: i think i had to add this to php.ini to get ssl to work
<clever> openssl.cafile=/etc/ssl/certs/ca-bundle.crt
<clever> eacameron: but as far as i know, the module paths have to be configured in php.ini, and i have to customize php.ini for other things to work, and now nix needs a way to merge those customizations
<clever> then you can swap the entire phpPackages out, and it wont mix up the versions
<clever> eacameron: it should probably be a lambda within phpPackages, the same way haskell handles things
<clever> same
<clever> eacameron: though php uses composableDerivation.composableDerivation, so it might configure the same way vim does
<clever> eacameron: the phpPackages attrset is built on a given php, php70 in my case, so i dont think an override on php70 would be right
<clever> had to stare at it for a minute to see it
<clever> oh, there
<clever> pie_: sudo nix-channel --list
<clever> pie_: which nix channel are you on?
<clever> eacameron: i do see a phpPackages.xdebug, but no clear way yet on how to put it into the search scope
<clever> mojjo: ah
<clever> you can also just echo things in there and see them in the build log
<clever> yeah
<clever> mojjo: can you show more of the output from the nix build?
<clever> mojjo: line 39, you cd $src, that source tree will be read-only
<clever> mojjo: it may need a #!/bin/sh
<clever> mojjo: i think you mean ${
<clever> its also $stdenv/setup that handles buildCommand, so sourcing it the buildCommand will cause recursion
<clever> so just buildCommand = ./builder.sh;
<clever> mojjo: buildCommand can be a path as well
<clever> mojjo: no, buildCommand handles the stdenv for you
<clever> mojjo: when buildCommand is used, the build will fail if any command returns non-zero, but you loose that feature if you use builder
<clever> mojjo: try switching it from builder to buildCommand and see if it does something different
<clever> mojjo: you also need to copy or symlink html files into the $out directory
<clever> unlmtd[m]: nix-env -iA nixos.my_nvim
<clever> unlmtd[m]: you want -iA
<clever> mojjo: is this on nixos or another distro?
<clever> mojjo: i think the problem is that its pointing to a different <nixpkgs> so some defaults changed
<clever> mojjo: you probably just want to switch it to pkgs.runCommand "my" { jars = ... ... } ''bash script here''
<clever> mojjo: also, the version on line 16 does absolutely nothing
<clever> mojjo: you should almost always use buildCommand, rather then just builder
<clever> filyforasec: nix-env -e program
<clever> mojjo: can you gist my.nix?
<clever> mojjo: sounds like the script inside my.nix didnt mkdir $out, so you need to look further up in the log
<clever> mojjo: and what error does it fail with?
<clever> mojjo: can you gist the file your putting that into?
<clever> LnL: and nixos also mounts /nix/store read-only, so it cant even be written to by root!

2017-03-27

<clever> disasm: and of course, the rootfs for the container must be mounted to the right spot
<clever> RequiresMountsFor=/var/lib/containers/%i
<clever> disasm: ahh, and systemd is told to use the .conf to initialize env variables, before it runs any (pre)start/stop scripts
<clever> EnvironmentFile=-/etc/containers/%i.conf
<clever> the script in ExecStart just runs systemd-nspawn with a bunch of special arguments
<clever> disasm: if /nix is mounted correctly, it might work to just symlink the configs and .service file, but that would need experimentation to confirm
<clever> disasm: this bash script(and a few other in its .service) then deal with starting/stopping the container as a systemd unit
<clever> ExecStart=/nix/store/aqs2is200gy81qapw79d8dr3d8qniqg7-unit-script/bin/container@-start
<clever> cat /etc/systemd/system/container\@.service
<clever> it will contain a storepath like this
<clever> SYSTEM_PATH=/nix/store/4iph3lm61vv7b60qrv005n9sx602xpji-nixos-system-mc1.earthtools.ca-17.03pre98383.7ee897a
<clever> disasm: if you look in /etc/containers you should see a config for each nixos container
<clever> tsmeets: sure
<clever> arch*
<clever> tsmeets: most things are only tested with native builds via build slaves of the correct arc
<clever> tsmeets: not a lot of things are well tested under cross-compiles
<clever> tsmeets: cant see anything obviously wrong
<clever> tsmeets: and thats in the root dir of nixpkgs?
<clever> ceah, that is setting cross system
<clever> tsmeets: can you gist cross-aarch64.nix?
<clever> tsmeets: you need to pass crossSystem to nixpkgs to setup cross-building
<clever> brb
<clever> that path is hard-coded into it
<clever> command-not-found uses the programs.sqlite db found in the channel called nixos on root
<clever> yeah
<clever> and why?
<clever> ertes: depends on what tool you want to affect and why
<clever> ertes: and also, the root channels point to the same place as the default $NIX_PATH
<clever> lrwxrwxrwx 1 clever users 44 Oct 11 2015 /home/clever/.nix-defexpr/channels_root -> /nix/var/nix/profiles/per-user/root/channels
<clever> nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs:nixos-config...
<clever> echo $NIX_PATH
<clever> ertes: nix-env will use .nix-defexpr
<clever> ertes: most tools search for <nixpkgs>, nix-env is the only odd one out
<clever> ertes: with either -I or $NIX_PATH
<clever> hlavaty: overrideDerivation has been replaced by overrideAttrs

2017-03-26

<clever> Unode: harder to check dmesg if its entirely unresponsive
<clever> YellowOnion: could be that it just ran out of swap&ram
<clever> YellowOnion: a lot of routers dont like it when you idle in putty
<clever> YellowOnion: did it not respond after trying to reconnect?
<clever> YellowOnion: maybe, you can also echo that control string to /dev/console and /dev/tty1
<clever> but some context is lost if you copy/paste a line from the middle
<clever> services = { mingetty.helpLine = "..."; }; reduces the duplication, no need to say services. 20 times in a file
<clever> or prefix it with services.
<clever> oh right, it has to go within services = { ... };
<clever> YellowOnion: not sure, but you could download the raw version of the above gist,then cut&paste between files
<clever> YellowOnion: but waking the console from sleep doesnt work if its locked up
<clever> YellowOnion: the reason for this, is that linux will often print helpfull errors to the console
<clever> YellowOnion: note, those are real escape codes, tricky to type right
<clever> mingetty.helpLine = "ESC[9;0]ESC[14;0]";
<clever> YellowOnion: one thought is to disable the dpms in the tty, that can cause trouble debuging
<clever> YellowOnion: that channel should be stable
<clever> YellowOnion: as root,run nix-channel --list
<clever> YellowOnion: what channel are your running?
<clever> ah
<clever> YellowOnion: any swap?
<clever> YellowOnion: what type of VPS?
<clever> YellowOnion: what FS?
<clever> YellowOnion: sounds like it froze and was unable to log things
<clever> YellowOnion: how much of a gap is there in the journal, between the last message and it booting back up?
<clever> YellowOnion: how about forcibly restarting it?
<clever> rmrfroot: you can also -b -1 to view the previous boot only
<clever> that limits the log to the current boot
<clever> yeah, -b 0 can speed it up a lot
<clever> switched the hdd from gentoo to nixos