<clever>
lfish: the entire /etc/systemd dir is read-only, all changes must be defined in coniguration.nix
<clever>
that also works, depends on what your doing
<clever>
mpickering: let foo = "s"; in d.${foo}
<clever>
as would b=a; in a==b
<clever>
yeah
<clever>
depending on if they are identical or identical :P
<clever>
but some compares can suceed, and others throw
<clever>
you can compare unevaled thunks
<clever>
and lazy!
<clever>
yep
<clever>
it could cheat a bit, by comparing the Value* rather, then the value within
<clever>
and one of the keys is designed to fail
<clever>
i suspect its strictly evaling everything top-level, and trying to compare each key
<clever>
> pkgs.pkgs.pkgs.pkgs == pkgs
<clever>
but if you directly put ${glib} (the nix var) in prePatch, you dont need the bash var
<clever>
and then you can refer to $glib (the bash var) in the shell
<clever>
that is assigning an env var called glib
<clever>
i think i also have a dolphin expr somewhere...
<clever>
ah
<clever>
boogiewoogie: you should be able to run nix-shell on the same default.nix you build with
<clever>
boogiewoogie: and on line 29, you could just run sed on ${glib} itself, (a nix var) rather then \${glib} (a bash var), then you can just delete line 8
<clever>
the version= on line 6 is also not doing anything
<clever>
you usually dont need rec in most cases
<clever>
boogiewoogie: that causes glib = glib; to refer to itself
<clever>
boogiewoogie: oh, the rec on line 3
<clever>
not sure why that 2nd example failed to parse
<clever>
> pkgs == pkgs.pkgs.pkgs.pkgs
<clever>
> pkgs.glib == glib
<clever>
boogiewoogie: pkgs.glib and glib should be identical
<clever>
jackjennings: yep
<clever>
you have to add the datadog user to the keys group, to be able to even look inside /run/keys/
<clever>
yeah, theres the proboem
<clever>
ls -lhd /run/keys/
<clever>
jackjennings: and `grep User /etc/systemd/system/datadog-agent.service` ?
<clever>
jackjennings: what does `ls -lh` report for that path?
<clever>
so any changes you do via // get undone
<clever>
tilpner: also of note, nixos will do a boot.kernelPackages.extend somewhere
<clever>
tilpner: the package providing the module has to be in boot.kernelPackages i believe
<clever>
so the host will always be garbage collecting stuff you need
<clever>
and indirect roots inside the dokcer container are likely to never work right
<clever>
if you miss something like profiles/gcroots, one party may delete everything the other party needs
<clever>
if you share the entire /nix/ then you get the socket and the state stuff
<clever>
you can also put the above into a new file called default.nix, and rename the old one to pkg.nix
<clever>
yeah, that is also a solutiopn
<clever>
boogiewoogie: you want to remove the function on line 7 of the pastebin
<clever>
,locate query-kvm
<clever>
vasarmilan: try downloading a different iso?
<clever>
vasarmilan: try a bs=1024?
<clever>
vasarmilan: my only guess is that using bs=4mb, you cut the image short
<clever>
i would expect that to work
<clever>
vasarmilan: and it was written to the root of the device?
<clever>
vasarmilan: how did you image the iso onto the usb?
<clever>
Taneb: and if 2 clients are connected, which client answers?
<clever>
Taneb: but if no clients are connedted, it has to answer with something
<clever>
and gchristensen responds with weechat when ctcp version'd
<clever>
infinisil: but when it connects to a given network (like freenode), it has to have some kind of reply to ctcp version
<clever>
infinisil: it looks like just weechat
<clever>
and then when he finally did reboot, it didnt come up
<clever>
and he then went without rebooting for months, so it worked at nixos-rebuild time
<clever>
a few months ago, somebody tried doing network in an activation script
<clever>
bbarker: that can result in systemd not being found
<clever>
bbarker: just be carefull that you dont crash in an activation script
<clever>
kai_w: add it to either the rpath or the LD_LIBRARY_PATH
<clever>
bbl*
<clever>
bl
<clever>
slack1256: no real way to know what something was built from, but you can try running nix-build -I nixpkgs=/foo -A bar on each channel generation, to see which one makes the version you want
<clever>
bash is part of the stdenv
<clever>
the stdenv sets a lot of special flags like exiting if any command returns a non-zero status
<clever>
also, all exported vars are inherited, even without source
<clever>
ottidmes: it does
<clever>
ottidmes: add a set -x to the script
<clever>
ottidmes: how does it fail?
<clever>
and channel generation 8 happens to point to a dae9c...
<clever>
exarkun22: target, in the deployment files
<clever>
exarkun22: you need to set nixpkgs.localSystem and something related, in the nixos config level
<clever>
yay
<clever>
Mufga1: i prefer using the config file
<clever>
Mufga1: /boot can then either be part of / (depending on the FS) or a dedicated /boot partition
<clever>
Mufga1: if you set `boot.loader.efi.efiSysMountPoint = "/boot/EFI";`, mount ESP to `/boot/EFI`, then the fat kernels/initrds will be in /boot, not the ESP
<clever>
samueldr: my nas has a 64mb boot partition....
<clever>
Mufga1: what FS is your rootfs?
<clever>
kingemp: ive got an old gentoo box as my escape hatch, lol
<clever>
i use xfce and it seems to run fine
<clever>
Mufga1: i have nixos on my laptops, desktop, router, and nas
<clever>
{ config, options, pkgs, ... }: at the top of the file
<clever>
witchof0x20: the config var has all config for the eval
2018-11-16
<clever>
then it can build anything you have manually copied over
<clever>
and then use all of the above nix copy stuff, to get things into that machine
<clever>
run something like nix-serve on an internal box, that acts as your cache
<clever>
oh, another option
<clever>
it still has internet, but it doesnt use any binary caches
<clever>
the installer i made is more about pre-building a closure, and deploying it to a machine i wont have real-time access to, in an automated way
<clever>
but i have used stuff similar to the above, to produce an installer (similar to an airgap)
<clever>
basically every action in nix needs access to the binary cache, so its not a very common use-case
<clever>
and now the entire package-set is defined in profile1.nix, and you can recreate it
<clever>
then you can nix copy that to a usb, and deploy it
<clever>
and -r will remove anything the profile previously had, so it only has what the current things defined
<clever>
this will install the things attr in profile1.nix, to the example profile (which is ignored by all tools)
<clever>
nix-env -f profile1.nix -iA things -r -p /nix/var/nix/profiles/per-user/clever/example
<clever>
alex-v: you can also manage your own profiles, for example
<clever>
and will omit build-time deps
<clever>
alex-v: you can also look at your profiles, and only copy what yo need, that will be faster then --all
<clever>
alex-v: the main benefit of `nix copy` is that its incremental, it knows what has already been copied, and can update things faster
<clever>
alex-v: if you know what storepaths should be where, you can `nix-env -p /nix/var/nix/profiles/per-user/clever/profile --set /nix/store/foo` to update the profile, after copying things
<clever>
alex-v: yeah, but note, that the profiles themselves wont be copied, so the links in /nix/var/nix/profiles/ wont be copied, just the things they point to
<clever>
djahandarie: check the next thing down in the call count then
<clever>
djahandarie: would need to know more about what the nix code your using is doing
<clever>
if possible, try to reduce the usage of zip attrs?
<clever>
ah, so that part is ran on every attr that its zipping
<clever>
djahandarie: what funciton is at that line?
<clever>
5056579 anonymous function at /nix/store/rfz3yh9r9skayd6rwq1ms4cibmb8bs4g-nixos-unstable-19.03pre158246.6141939d6e0/nixos-unstable/lib/attrsets.nix:333:23
<clever>
then other overlays can be inserted, and mutate self before you get a reference
<clever>
if you want to refer to something else, use self
<clever>
yep
<clever>
if you have rec, then the overlays wont work right
<clever>
no rec should be involved when using overlays
<clever>
super refers to the version from 1 overlay prior, and breaks the recursion
<clever>
like saying `let foo = foo`
<clever>
and if you do uuid = foo self.uuid; then its infinite recursion
<clever>
self.uuid is the result of applying all overrides, including the current one
<clever>
and skip the entire override
<clever>
let mypkgs = pkgs.haskell.packages.ghc862.override { ... };
<clever>
Peaker: if you only ever want to use that package set directly, just dont bother putting it back into the right place
<clever>
Peaker: you could, but that would require rebuilding every single dep
<clever>
oh, your deps, yeah, you would have to override those deps to doCheck = false; them
<clever>
Peaker: is doCheck = true; set on your derivation?
<clever>
Peaker: lib.cleanSource is an example, but it doesnt clean dist
<clever>
Peaker: you need to use builtins.filterSource to exclude the dist dir and some other things
<clever>
and with any luck, libc will be the only occurance of /dev/log, in the closure of your binary, so its the only way it could have gotten that string
<clever>
ottidmes: i'm guessing youll find the libc that your program depends on, and then a quick grep of the libc source would have led you to the syslog() function
<clever>
leotaku: you would need to find an eval on hydra, that has a high amount of jobs finished
<clever>
leotaku: --dry-run will tell you that
<clever>
(until you re-run modify with a new one, or use `nixops deploy -I nixpkgs=...`)
<clever>
leotaku: then <nixpkgs> will only ever resolve to that exact git rev, and it will never update
<clever>
leotaku: use `nixops modify -d something foo.nix -I nixpkgs=https://github.com/nixos/nixpkgs/archive/GITREV.tar.gz`
<clever>
leotaku: it will generally be NIX_PATH to blame here, you did a nix-channel --update on the host
<clever>
for NIX_PATH, it generally doesnt change, but what it points to may change (nix-channel for ex), but nix-channel also has generations and keeps the old ones
<clever>
leotaku: for the /nix/var/nix/profiles/system symlinks, it keeps all of the old ones, so you can just ls that dir to see the history
<clever>
and in both, there will be /nix/var/nix/profiles/system symlinks to track the last build
<clever>
leotaku: for nixos-rebuild, its mainly just NIX_PATH
<clever>
leotaku: for nixops, it will keep state in ~/.nixops/deployments.nixops, and it will also obey NIX_PATH (but you can nixops modify -I nixpkgs=... to save overrides)
<clever>
kingemp: yeah, its tricky to find the right balance, i just set both to the core count
<clever>
kingemp: ah, then it will do 12 different derivations in paralle, with make -j1 in each
2018-11-14
<clever>
kingemp: nixos-generate-config should fill that in, check what your generated config has
<clever>
kingemp: nix.buildCores = 10; in configuration.nix
<clever>
kingemp: nixos or other?
<clever>
kingemp: nix show-config | grep core
<clever>
kingemp: enableParallelBuilding = true;
<clever>
Church-: videoDrivers = [ "intel" ]; works, but [ "nvidia" ]; fails, bumblebee also fails
<clever>
Church-: both of these appear in PolarIntersect's lspci
<clever>
PolarIntersect: see if you can figure out how its installed/configured on other distros, then we could try to reproduce it on nixos
<clever>
PolarIntersect: ah, that indeed may need special drivers then
<clever>
not entirely sure
<clever>
Ralith: there is also cmakeFlags = [ "-D" "CFLAGS=whatever" ];
<clever>
PolarIntersect: also, reboot things between each test
<clever>
PolarIntersect: try the other driver, hardware.bumblebee = { enable = true; driver = "nouveau"; };
<clever>
PolarIntersect: have you checked the nixos-hardware repo on github?
<clever>
PolarIntersect: if you dont care about 3d accel, you can just go back to pure intel
<clever>
if i turned hw accel off, 2d was fast, and it lacked 3d entirely
<clever>
but 3d was fine
<clever>
as in, `ls -l /nix/store` took 5 minutes slow
<clever>
that reminds me, one of the bugs i had on my amd card (since fixed), is that 2d rendering was horid slow
<clever>
the reason for that design, is that the nvidia card can just be 100% disabled, and then you have a very low-power 2d-only card, and better battery life
<clever>
while keeping videoDrivers = [ "intel" ]; i think
<clever>
PolarIntersect: hardware.bumblebee = { enable = true; driver = "nvidia"; }; i think this is how you enable that stuff
<clever>
and the nvidia is 3d only, and renders directly into the 2d buffer of the intel card
<clever>
from what ive heard, the intel card controls the display and handles all 2d actions