<clever>
depends on if you want something that can be added to PATH or something to just run
<clever>
ekleog: writeScript puts it in $out, and scriptbin puts it in $out/bin/$name
<clever>
ekleog: yeah, i also tried to avoid systemd
<clever>
thats why i avoid dbus :P
<clever>
yeah, but it just never got implemented
<clever>
ekleog: pretty sure the problem is that nixos-rebuild doesnt want to iterate over every single user
<clever>
there is a special reload that is needed to make it re-read service files
<clever>
ldlework: use writeScript to create your own script
<clever>
> writeScript "name" ''#!/bin/sh .... ''
<clever>
> writeScript "name" ''#!/bin/sh .... '
<clever>
ldlework: use writeScript to create your own script
<clever>
you can also just "echo $DISPLAY" in the script
<clever>
something in nixos modifies the logind env vars to set that up
<clever>
but i dont use them much
<clever>
i think so
<clever>
user services run per user, as the right user, wtih things like your DISPLAY set right
<clever>
system services run even if xorg isnt open, and your not logged in
<clever>
ldlework: you probably want a systemd user service, not a system service
<clever>
ldlework: $DISPLAY isnt set, so the service cant connect to xorg
<clever>
ldlework: is this a GUI app?
<clever>
ldlework: is gdb in PATH?
<clever>
ldlework: did you run `coredumpctl gdb <PID>` ?
<clever>
pastebin the output of bt
<clever>
yeah
<clever>
ldlework: you may need to add a `ulimit -c unlimited` to the script
<clever>
and bt
<clever>
then run coredumpctl gdb <pid>
<clever>
it should list the coredumps and pid's
<clever>
ldlework: now run coredumpctl as root
<clever>
Enzime: nope
<clever>
which is why we need a coredump
<clever>
ldlework: the if statement on 8 checks to see if enable is set, so you dont have to set it again
<clever>
ldlework: it sounds like the binary is crashing, try turning on systemd-coredump to get a coredump
<clever>
ldlework: line 16 only enables the service if the service is already enabled
2018-08-27
<clever>
gentoo was my main OS, prior to discovering nixos
<clever>
jonge: i have previously seen a bug in the livecd that broke binary caches, and sometimes a user just thinks a rebuild-the-world style gentoo install is normal, lol
2018-08-26
<clever>
dhess: but that can cause problems if you try to build it on a real aarch64, it will demand an x86-64 build slave
<clever>
dhess: and maybe also do something with config and overlays
<clever>
dhess: but you wont import <nixpkgs> but instead `import pkgs.path { system = builtins.currentSysstem; }`
<clever>
dhess: hydra would eval it on an x86-64, so currentSystem will be x86-64
<clever>
daveo_: iftop is just a much simpler form of the same thing, it uses pcap to gather the data
<clever>
that will always be for the current system, then you need to grab the dhall-nix from it
<clever>
dhess: import <nixpkgs> { system = builtins.currentSystem; }
<clever>
dhess: but then it introduces an impurity
<clever>
dhess: re-importing nixpkgs with builtins.currentSystem can get that effect
<clever>
daveo_: yep
<clever>
dhess: oops, ^^^
<clever>
daveo_: dhallToNix would need to be modified to accept 2 system params, then import nixpkgs twice, with those 2 values
<clever>
daveo_: though iftop can show more details, and tell you which domain is doing it all
<clever>
daveo_: ah, that also does the same job as vnstat
<clever>
the nix-env one doesnt really help any, and will stop nixos-rebuild from ever updating what is in $PATH
<clever>
bigvalen: probably, but its not a good idea to install postfix twice like that
<clever>
there is a bug in nix-env, that dead symlinks break nix-env -i
<clever>
bigvalen: oh!, nix-env -q
<clever>
bigvalen: yeah, all of that looks perfect, where did you get the /nix/store/r0z0z67cav0yffbpdpcz2f12b3vd9dwj-postfix-3.0.3/sbin path from?
<clever>
daveo: you can also check `iftop` to see what ip its going to
<clever>
daveo: run `vnstat -l -i enp3s0` and check if its doing any kind of upload
<clever>
bigvalen: can you post your configuration.nix to a gist?
<clever>
services.postfix is the nixos option
<clever>
bigvalen: do you have any packageOverrides or overlays?
<clever>
bigvalen: ls -l /root/.nix-defexpr/channels/nixos
<clever>
bigvalen: version 3.3.1 doesnt have this issue, so it may already be fixed, what does `nix-channel --list` report?
<clever>
bigvalen: you need to add an override to fix postfix
<clever>
bgamari: oops, yeah
<clever>
bgamari: you want to fix the postfix derivation and then nixos-rebuild again
<clever>
it must explicitely be listed in the inputs of tensorflow
<clever>
every package is built in its own sandbox, even if you install it before tensorflow, it wont be visible to tensorflow
<clever>
blankhart: editing that now
<clever>
blankhart: you only added protoc to project
<clever>
blankhart: tensorflow-proto is failing due to lack of protoc
<clever>
blankhart: can you pastebin the error?
<clever>
nix-shell shouldnt try building anything
<clever>
blankhart: what error does nix-shell give?
<clever>
blankhart: oh, the .env used by nix-shell omits the tools
<clever>
blankhart: did you re-launch the shell? what does `type protoc` return?
<clever>
pi3r_: i try to put it all in an overrides, because it makes it simpler to access the deps if you need them, and when the project grows, more things can depend on that package
<clever>
pi3r_: yeah, i think those are the same
<clever>
blankhart: with nix-build or nix-shell?
<clever>
pikajude: oops, wrong tab-complete
<clever>
pikajude: add protobuf to line 28 of the pastebin, to remap it the same way pkgconfig is remaped
<clever>
pikajude: due to how callPackage works, you are getting the hackage protobuf, not the c++ protobuf
<clever>
> haskellPackages.protobuf
<clever>
blankhart: can you pastebin your nix files?
<clever>
pikajude: and the main thing i want to use it on, is ~20 cabal projects depending on eachother
<clever>
pikajude: ive heard that snack doesnt support multiple cabal projects at once
<clever>
blankhart: does the haskell package contain a library?
<clever>
blankhart: pkgs.protobufc also contains a protoc symlink
<clever>
yep
<clever>
> pkgs.fetchFromGitHub
<clever>
> pkgs.fetchFromGithub
<clever>
ldlework: callPackage can send anything that is an attribute of pkgs
<clever>
that wont change the bootup default, so you can just reboot the VM to undo the change
<clever>
callipygous: also to speed up testing, use `nixos-rebuild test`
<clever>
try without enabling i3
<clever>
callipygous: try changing absolutely nothing, and onyl nixos-rebuild switch
<clever>
callipygous: what if you dont add unstable?
<clever>
then the update broke something, try nix-channel --rollback to undo the update
<clever>
the xserver sometimes crashes if you try to update things without rebooting
<clever>
that defers the update until you reboot
<clever>
try using `nixos-rebuild boot` instead, and then reboot
<clever>
callipygous: did you do nix-channel --update at any point?
<clever>
ldlework: so you must import (fetchFromGithub { ... })
<clever>
ldlework: but nothing is currently loading THAT file
<clever>
callipygous: try using grub to switch to the previous generation, then run `sudo journalctl -b -1` to read the logs from the previous boot
<clever>
it just fetches, from github
<clever>
correct
<clever>
it only happens when you run import or callPackage
<clever>
ldlework: you need to import the source to run its default.nix
<clever>
ldlework: 17 installs the SOURCE, not the result of running that nix
<clever>
ldlework: 6 fetches the source, and 17 installs the source
2018-08-25
<clever>
ixxie: then you have to run `nixops modify` to tell it where the file has moved
<clever>
ixxie: when you run `nixops deploy`, it will just eval every deployment file it was configured to use, and build the whole system based on them
<clever>
LnL: only with grub, configurationLimit
<clever>
thblt: but you can still run it with --install-bootloader
<clever>
thblt: to be safe, i would only delete the larger files, and keep the core parts of grub
<clever>
thblt: you need to manually delete some initrds, nix-collect-garbage never updates /boot, only nixos-rebuild does
<clever>
ldlework: yep
<clever>
ldlework: when hydra fetches release.nix, it also gets the source
<clever>
ldlework: if the release.nix is in the right dir, it can always do ./.
<clever>
endformationage: add .debug to the -A flag
<clever>
with import <nixpkgs> {}; callPackage ./foo.nix {}
<clever>
callipygous: correct, the live usb doesnt save anything
<clever>
callipygous: nix-env -iA nixos.irssi
<clever>
sphalerite: evtest can even detect headphones being (un)plugged
<clever>
sphalerite: run evtest as root
<clever>
sphalerite: there is something related, that can hijack any input device and receive inputs
<clever>
sphalerite: uinput, let me find the test thing
<clever>
its more likely that nixos-rebuild wont even work, if the types are broken
<clever>
jD91mZM2: after you dd it over, you can add another partition in the empty space
<clever>
techieAgnostic: i dont think cabal supports system libraries
<clever>
jD91mZM2: the ISO already has partitions on it, just dd it directly to the usb stick
<clever>
dukedave: the defaults are usually fine
<clever>
dukedave: if you pipe it into sh, then sh cant use stdin to ask things, if you save the script to a file and then run sh on it, it can ask you questions
<clever>
techieAgnostic: did you nix-shell into the .env attribute?
<clever>
Ashy: `man configuration.nix`
<clever>
Ashy: linuxPackages_latest
<clever>
Ashy: now just set boot.kernelPackages = pkgs.linuxPackages_4_17; and nixos-rebuild switch
<clever>
techieAgnostic: add it to the librarySystemDepends field of mkDerivation
<clever>
Ashy: run `nix repl '<nixpkgs>'` and then just try tab-completing linuxPackages
<clever>
Ashy: you can probably get a newer kernel while staying on 18.03
<clever>
mog: yep
<clever>
fresheyeball: ive not really used ghcjs, so i'm not sure what else to do
<clever>
mog: you could also do: with (import <nixpkgs> { crossSystem = (import <nixpkgs/lib>).systems.examples.riscv64; }); stdenv.mkDerivation { ... } in a foo.nix file, then use it with nix-build or nix-shell
<clever>
mog: this nix expression will build hello-world for riscv64
<clever>
jonreeve: what does `nix-channel --list` report for each user?
<clever>
and if you do understand whats wrong, you can just fix it
<clever>
jonreeve: if you dont understand what is wrong, your likely to just break it again after you reinstall
<clever>
jonreeve: that maps <nixpkgs> back to the nixos channel
<clever>
nbathum: what about `touch /root/foo` ?
<clever>
nbathum: nothing oviously wrong, nix-channel --update should just work
<clever>
slabity: ive seen it on a trelo
<clever>
nbathum: the db is in /nix/var/
<clever>
nbathum: thats normal, the db is not in store
<clever>
rfold: nothing obviously wrong there :(
<clever>
sphalerite: not sure, but i think that the php-fpm daemon is able to run multiple pools with unique configs on its own, and nixos just lacks the ability to start 2 of those daemons
<clever>
nbathum: can you pastebin the output of mount and df -h?
<clever>
rfold: can you pastebin configuration.nix?
<clever>
nbathum: dmesg | tail, does it mention anything about ro or read-only?
<clever>
but you probably want to update roots channels anyways
<clever>
each user has its own set of channels, not sure why its breaking for non-root
<clever>
nbathum: what does `type nix-store` report?
<clever>
nbathum: nixos or another distro? single or multiuser install?
<clever>
yeah, i forgot about the symlinkjoin
<clever>
nothing would refer to that image
<clever>
nope
<clever>
ah, that could be an issue
<clever>
sphalerit: nixos-rebuild should also work inside the netboot image, provided the configuration.nix is right