<clever>
pkgs/development/misc/avr-gcc-with-avr-libc/default.nix: description = "AVR development environment including binutils, avr-gcc and avr-libc";
<clever>
arcetera: heh, i was just thinking about getting back into some avr programming
<clever>
obadz: services.cron.enable will probably work
<clever>
obadz: ive just been using systemd timers in configuration.nix, but that would need root
<clever>
ah
<clever>
and the above code cant append /Imaging/ to those -I paths
<clever>
but also keep in mind, nixpkgs uses a non-standard cflags (NIX_CFLAGS_COMPILE) to inject -I's without allowing dumb makefiles the chance to overwrite it
<clever>
SplitFire: it says that if the outputs are newer then the inputs
<clever>
SplitFire: then run "nix-shell -p hello" and you should get patchShebangs
<clever>
it must be done by a nix expression, not by hand
<clever>
SplitFire: that script it sourced by setup.sh in the stdenv, so you can just "patchShebangs ." to patch every script in the current dir
<clever>
SplitFire: and the fixupPhase automaticaly finds all "#!/usr/bin/env bash" in $out/bin and patches it to "#!/nix/store/hash-bash/bin/bash" for you
<clever>
SplitFire: patchShebangs must be ran on a directory, and it will get every file in it for you
<clever>
MichaelRaskin: i dont think the nix build sandbox has /usr/bin/env
<clever>
you can just use the command in your derivation
<clever>
its already in the stdenv
<clever>
apostolis: yay
<clever>
what shell did you try to tabcomplete in?
<clever>
i belive its already in the stdenv, so you can just use it
<clever>
SplitFire: and you cant just make libc depend on bash, because bash depends on libc, because libc depends on bash, because bash depends on libc, because libc depends on bash, because bash depends on libc, because libc depends on bash ....
<clever>
SplitFire: the system() function in libc requires a /bin/sh
<clever>
SplitFire: and the entire design of nix is to avoid things breaking like that
<clever>
SplitFire: /bin is an impurity, it might contain a different binary tomorrow, and cause your perfectly working script to not work because somebody updated something else
<clever>
it will add a number at the end of each line
<clever>
apostolis: what about lspci -nn?
<clever>
can you gist the entire dmesg output?
<clever>
apostolis: anything interesting in dmesg?
<clever>
apostolis: what about "ip link"
<clever>
i usualy just delete it, and embed the contents into configuration.nix
<clever>
it depends on if you plan to use nixos-generate-config to rebuild it or not
<clever>
apostolis: boot.kernelModules is basicaly just a list of things that get modprobe'd at bootup, so you should be able to test if "modprobe ath9k" fixes things first
<clever>
i was more going for a way to alter how private.nix behaves without having to edit it directly
<clever>
MichaelRaskin: when the tryEval fails, it just spits out a better error, but id need to modify private.nix directly if i wanted to add support to take the config in as a string
<clever>
MichaelRaskin: to eliminate a step the user has to perform before nix-build
<clever>
MichaelRaskin: i wanted to generate the <ssh-config-file> with pkgs.writeText
<clever>
gchristensen: and scopedImport would get any <nixpkgs> the user may add down the road
<clever>
gchristensen: but if the users deployment file later re-imports <nixpkgs> it wont be
<clever>
gchristensen: i believe the patch in that PR changes it from using <nixpkgs> to using nixpkgs + "/nixos/eval-config.nix", so the initial pkgs it loads for nixos will be affected
<clever>
MichaelRaskin: scopedImport isnt even used in nixpkgs, and the nixops case is fairly special, wanting to import many different files, each with their own view of <nixpkgs>
<clever>
MichaelRaskin: not sure, would need to experiment and see
<clever>
gchristensen: and scopedImport lets you inject things into the global scope of a given import
<clever>
gchristensen: basicaly, every <nixpkgs> gets translated to __findFile calls on __nixPath and "nixpkgs"
<clever>
BlessJah: serviceConfig must be an attributeset
<clever>
AndreasO: and the nix-env one will have a higher priority
<clever>
AndreasO: ah, it wont detect that collision, because they are in different profiles
<clever>
pie__: it sounds like the root problem is a lack of $XAUTHORITY, so when $HOME changes, it can break
<clever>
which is also a default, so it being unset still works, if $HOME is set right
<clever>
on my end, its set to /home/clever/.Xauthority
<clever>
try copying its value over
<clever>
pie__: what does this show under a root shell?
<clever>
pie__: echo $XAUTHORITY $DISPLAY
<clever>
pie__: i do "sudo -i" all the time, and run xorg apps under that
<clever>
pie__: root should be able to read your xauth file out of the old $HOME
<clever>
AndreasO: and only one of those programs will be usable
<clever>
AndreasO: if you try to install 2 different things that provide the same binary, nixos will build, and print a warning as it does so
<clever>
AndreasO: systemPackages is set to ignore collisions, it will print a warning at build time, and i think it will use whichever package provided a given file first
<clever>
AndreasO: there is a n missing, environment.systemPackages
<clever>
AndreasO: what error is it giving?
<clever>
and if the nixos module just ran buildEnv over a list of hooks, and then stuck the resulting path into the systemd unit, it would be able to do that
<clever>
then patch it to obey the env var
<clever>
if you have a systemd unit already
<clever>
id make it an option within nixos, that sets up env vars when the systemd unit gets ran
<clever>
heading out for a bit
<clever>
ah, must still be in master then
<clever>
should be testable under nix-shell, and the nix-daemon doesnt have to match
<clever>
try nixUnstable
<clever>
Baughn: reading the source, its just builtins.exec { program="stat"; arguments = [ "-L" "-c" "%s" file ]; }