2020-04-29

<clever> NIXOS_LUSTRATE is already in nixpkgs, it was written based on how i manually repaired a machine i had converted from gentoo :P
<clever> so you basically just `nix-build '<nixpkgs/nixos>' -A system -I nixos-config=/etc/nixos/configuration.nix && touch /etc/NIXOS /etc/NIXOS_LUSTRATE && ./result/bin/switch-to-configuration boot`
<clever> but basically, if /etc/NIXOS_LUSTRATE exists on bootup nixos will move EVERYTHING in / to /old-root/
<clever> energizer: ive since made some kexec tools that would work more reliably
<clever> the only time you can `rm -rf /lib /usr /bin` and the machine runs better after its done!
<clever> and you simply have to purge all traces of the old distro, lol
<clever> then upon reboot, its nixos
<clever> energizer: basically, install single-user nix, use nix-build to build nixos, then tell nixos, "its a nixos machine, trust me, just fix the bootloader"
<clever> energizer: i have also devised ways to install nixos on any linux machine, without any install media
<clever> nix has now spread to everything i own
<clever> prior to catching the nix virus, i used gentoo :P
<clever> Raito_Bezarius: curl doent follow redirects by default
<clever> Raito_Bezarius: thats the hash of an empty string
<clever> $ echo -n | sha256sum
<clever> e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 -
<clever> Raito_Bezarius: and then you have to deal with that mess, when you want to put all of the tar's in one dir...
<clever> Raito_Bezarius: npm does the same thing, there is foo, and @types/foo, both have a foo-1.2.3.tar.gz, with different contents
<clever> Raito_Bezarius: and fetchurl can use that hash directly
<clever> mwx: so it directly uses that version of bash, and doesnt care what you have "installed" elsewhere
<clever> mwx: pkgs.bash evaluates to that string
<clever> > "${pkgs.bash}"
<clever> yeah
<clever> mwx: it takes derivations, like pkgs.bash
<clever> or python
<clever> mwx: the absolute path to bash
<clever> mwx: i would run patchShebangs over that script, that will change the #! to a proper absolute path
<clever> jumper149: neat idea!
<clever> weird
<clever> Lumpio-: ahh, yeah, that sounds like a bug
<clever> Lumpio-: if you run `pwd` inside postInstall, what dirs is it ran from?
<clever> Lumpio-: :D
<clever> elvishjerricco: i believe it will default to /tmp as well
<clever> but if your using single-user nix on a systemd based machine, $TMPDIR might be a tmpfs in /run/user/1000/
<clever> elvishjerricco: which is normally /tmp
<clever> elvishjerricco: oops, ^
<clever> emily: its in $TMPDIR
<clever> emily: but then things got more fishy, when other systems, with cpu's from a totally different era, had the same problem, at the same offset in ram
<clever> emily: and thats when the jokes about a bios malware began to come up (was talking to somebody else as i debugged it)
<clever> emily: and it still failed the ram test...
<clever> emily: but after juggling between all the ram sticks, i couldnt confirm which was bad, so i did a whole motherboard swap
<clever> emily: a few years ago, i got a random segfault out of nowhere, and knowing nix hadnt changed any binaries, i suspected bad ram, and memtest confirmed a problem ~256mb into the ram
<clever> jumper149: it was `nix-repl`, but got renamed during the nix 2.0 changes
<clever> Ilya_G: probably
<clever> jumper149: you can also eval that in `nix repl`
<clever> jumper149: nix-instantiate --eval -E 'builtins.attrNames (import <nixpkgs> {})'
<clever> Ilya_G: you need to include systemd in the buildInputs
<clever> Raito_Bezarius: a fixed-output derivation must declare upfront what the hash of the result is, and if it fails to meet that claim, the build fails
<clever> jumper149: builtins.attrNames
<clever> Lumpio-: you need this to fix gyp
<clever> Lumpio-: one min
<clever> Lumpio-: yeah, nix always disables network during build
<clever> Ilya_G: so you have no way to patch it
<clever> Ilya_G: it looks like pypi2nix is skipping some steps and not generating any nix, its just going right to building stuff
<clever> Ilya_G: all .nix files you have in the project
<clever> Ilya_G: can you pastebin the nix file that your building?
<clever> Ilya_G: its just plain systemd in nixpkgs
<clever> > pkgs.systemd.lib
<clever> Ilya_G: nix will never find libraries installed by other package managers
<clever> Lumpio-: not sure what thats doing
<clever> Lumpio-: so it may be different for canvas
<clever> Lumpio-: `yarn run build` says to lookup the build action in the package.json file
<clever> Ilya_G: and libsystemd.so is in systemd.lib, so it should just work when in buildInputs
<clever> result-lib/lib/libsystemd.so
<clever> $ ls result-lib/lib/libsystemd.so
<clever> /nix/store/6838l6w2nkcnyrf8ygs4m5d0kjqxz655-systemd-243-lib
<clever> $ nix-build '<nixpkgs>' -A systemd.lib
<clever> Lumpio-: you need to add a pkgConfig for canvas, similar to this one, which will tell yarn to actually compile canvas
<clever> emily: that one is ldd based, not getting the full graph
<clever> Lumpio-: ahh, one min
<clever> emily: you would need to use export reference graph and auto-generate a profile, that includes the closure of a binary, to let it access its own libs
<clever> Lumpio-: what is in the canvas sub-dir?
<clever> Lumpio-: yeah, look in there for some binary files
<clever> Lumpio-: but what about the node_modules it showed while the build was running?
<clever> Ilya_G: did you try adding systemd to the buildInputs ?
<clever> Ilya_G: what is the error msg?
<clever> Lumpio-: what do you ee if you actually build it?
<clever> Lumpio-: but its often simpler to test if you just nix-build, and then ls result/ and confirm if the contents are right
<clever> Lumpio-: in this case, `nix-shell -p '(import ./.)'` would be enough to do that
<clever> Lumpio-: you must point nix-shell to another derivation, that has nixcanvas in the buildInputs
<clever> Lumpio-: `nix-shell default.nix` would give you a shell suitable for building nixcanvas, not for running nixcanvas
<clever> Lumpio-: does the file actualy not exist? check the nod_modules dir
<clever> Lumpio-: some packages try to make the install faster, by just shipping pre-compiled binaries to you
<clever> Henson: systemd itself does have some isolation options, that can basically just dockerize each service
<clever> wedens[m]: both the 104 and the 56 say network problems
<clever> 56 Failure in receiving network data.
<clever> wedens[m]: it looks like its just a network error?
<clever> OS error code 104: Connection reset by peer
<clever> wedens[m]: does it fail if you retry?
<clever> wedens[m]: looks fine at a glance
<clever> wedens[m]: what url is nix trying to fetch?
<clever> mcwitt: you would need to override the buildCommand and append to it
<clever> mcwitt: runCommand uses buildCommand, so it just doesnt run any phase
<clever> Setzer22__2: the stdenv is part of the stdenv
<clever> yep, in the nixos manual
<clever> Avaq: because its part of lib, not builtins
<clever> Avaq: its part of the module framework, which is most used by nixos
<clever> Avaq: it should be in the nixos manual
<clever> pingiun: like, each job is turned into a list of steps, and then it sends N steps to each machine
<clever> pingiun: steps are also split up
<clever> pingiun: yep
<clever> pingiun: yeah
<clever> if i break things, and it stops booting, i can just do a rollback of the profile
<clever> jakobrs: so when the rpi tries to netboot, it follows that symlink, and loads whatever is in the custom profile
<clever> lrwxrwxrwx 1 root root 48 Apr 7 2019 /tftproot/55a4377c -> /nix/var/nix/profiles/per-user/root/rpi3-netboot
<clever> jakobrs: in my rpi3-netboot case, its just a symlink in my tftp root dir
<clever> jakobrs: only if you want things like xfce to detect the .desktop files and its $PATH stuff i think
<clever> Alexey56: yeah
<clever> and you have to modify everything again!!
<clever> and then somebody decides to add a 3rd place
<clever> and then you have to modify xfce to search in both
<clever> jakobrs: because things like your .desktop files, are now split between /run/current-system/sw/ and ~/.nix-profile/
<clever> jakobrs: i think thats a hint to shell scripts, so they can search each profile for stuff
<clever> you can always make a shell script to shorten it
<clever> lrwxrwxrwx 1 clever users 15 Nov 24 05:40 /nix/var/nix/profiles/per-user/clever/profile -> profile-15-link
<clever> lrwxrwxrwx 1 clever users 45 Jan 21 2016 /home/clever/.nix-profile -> /nix/var/nix/profiles/per-user/clever/profile
<clever> thats what ~/.nix-profile is doing
<clever> jakobrs: yeah, but is simpler to just put the profile in the profiles dir (as above), then symlink to the profile from elsewhere
<clever> you could also use -i instead, then it will behave more like normal nix-env, and merge with whatever you also installed
<clever> when in --set mode, whatever it builds will replace the entire profile (like nixos)
<clever> and you still have all of the standard rollback options as well
<clever> jakobrs: this will create a custom profile called rpi3-netboot, build rpi_image of release.nix, and set the profile to the last build
<clever> nix-env -p /nix/var/nix/profiles/per-user/root/rpi3-netboot -f not-os/release.nix -A rpi_image -I nixpkgs=./nixpkgs/ --set
<clever> jakobrs: nix-env can do that
<clever> if you need to cross-compile, your only real option is haskell.nix
<clever> if you only want native builds, id say stick to pkgs.haskellPackages

2020-04-28

<clever> energizer: run `nix-shell` directly on the .drv that failed, then just `echo $PATH`
<clever> nschoe: id double-check things with a scope
<clever> drozdziak1[m]: what does `nix-env -q` list?
<clever> nschoe: your likely generating the same string as what normal $AR contains
<clever> then at build time, nix will take that drv, and begin building things
<clever> at eval time, nix is just evaluating the pure nix expression, and creating .drv files, that contain build directions
<clever> nschoe: the $AR we want, only exists at build-time, after the shell hooks for the cross stdenv have mutated env vars
<clever> nschoe: makeFlags is eval-time, ${AR} would be a nix variable, not an env var
<clever> use nix or go away :P
<clever> the example i linked from open-firmware, just assumes $AR (the env var) is already set, and fails otherwise
<clever> the problem is that the makefile is force-setting AR, not providing a default and fallback
<clever> nschoe: that forces make to set AR (the make var) to $AR (the bash env var)
<clever> nschoe: preConfigure = ''makeFlags="$makeFlags AR=$AR"''; is enough to fix it as well
<clever> nschoe: the stdenv already set $AR the env var
<clever> nschoe: looks like automake detected the wrong ar
<clever> 131 AR = ar
<clever> 133 AM_V_AR = $(am__v_AR_$(V))
<clever> 544 $(AM_V_AR)$(libbcm2835_a_AR) libbcm2835.a $(libbcm2835_a_OBJECTS) $(libbcm2835_a_LIBADD)
<clever> 542 libbcm2835.a: $(libbcm2835_a_OBJECTS) $(libbcm2835_a_DEPENDENCIES) $(EXTRA_libbcm2835_a_DEPENDENCIES)
<clever> nschoe: if you let it fail, and build with --keep-failed, then you can view the generated Makefile in /tmp ...
<clever> nschoe: can you gist your nix exprs?
<clever> nschoe: ah yeah, *looks*
<clever> nschoe: which package is it? it should be as simple as just https://github.com/librerpi/rpi-open-firmware/blob/master/common/Makefile#L19
<clever> then why are you editing cmakeFlags?
<clever> AR=... in cmakeFlags, is diff from AR being an env var
<clever> nschoe: you need to tell cmake to use $AR, and not set AR, i believe
<clever> nschoe: the stdenv already sets a $AR for you
<clever> zeta_0: it means env vars wont leak in from the shell above nix-shell
<clever> id say its due to mixing nixpkgs revs, and it wouldnt happen if sway and nixos came from the same rev
<clever> simpson: so it spreads like a virus, and all of GL's deps could be the "wrong" version for sway
<clever> simpson: but libGL may be pulling in an old libdrm via RPATH, which isnt in sync with the libdrm that sway was built against
<clever> opengl is the only place where nix impurely mixes things up like that
<clever> because 2 nixpkgs versions got mixed up
<clever> simpson: the GL.h it was compiled from is out of sync with the libGL in /run/opengl-driver/
<clever> Jonathan21: you must get sway from the same version of nixpkgs as nixos, or things break
<clever> Jonathan21: opengl behaves weirdly on nixos, and ignores the previous rules
<clever> Jonathan21: can you link the issue?
<clever> Jonathan21: anything in /nix/store must follow that rule
<clever> zeta_0: then you need to figure out which file is setting compton
<clever> zeta_0: edit configuration.nix to rename the option
<clever> energizer: buildEnv only depends on the things in paths at runtime
<clever> energizer: does it actually depend on the things?, nix-store -q --roots
<clever> that would depend on a/b/c then
<clever> energizer: you could just nix-build an expr that does writeText "name" (toString [ a b c])
<clever> that will parse NIX_PATH and any -I flags it might receive, and tell you where <nixpkgs> is
<clever> butterthebuddha: nix-instantiate --find-file nixpkgs

2020-04-27

<clever> ornxka: that also works!
<clever> ornxka: and it was merged 8 hours ago, so you just need to wait for the channel to update once more
<clever> ornxka: it began failing 2 days ago, but fails within 2mins
<clever> ornxka: parallel building makes it a lot more muddy
<clever> ornxka: dqlite is what hung, and thats probably something in your systemPackages?
<clever> ornxka: ah, so its not actually the initrd thats hanging, but rather, the initrd is the last thing to print
<clever> ornxka: cat /proc/8212/environ | xargs -0 -n1 echo | grep out=
<clever> mpickering: ah
<clever> ornxka: sure
<clever> mpickering: have you tried middle click?
<clever> ornxka: can you pastebin the output of `ps -eH x` ?
<clever> ornxka: is anything using a lot of cpu?
<clever> ornxka: what does `top` say its doing?
<clever> and then do what you said
<clever> though, i could make a custom nixos module, to manage secrets.token1 as a normal nixos option
<clever> and then i have complex state that i have to manage without git
<clever> and that would make the secrets.nix contain a lot more config
<clever> noonien: also, some of the secrets are used multiple times
<clever> noonien: same for the snmp stuff
<clever> noonien: some things like the github tokens for hydra arent proper options, they are mixed in with the extraConfig
<clever> so the config can still build if the secrets happen to be missing, it just wont do anything secret
<clever> noonien: the real secrets.nix is in .gitignore
<clever> noonien: all of my config imports load-secrets.nix, which provides defaults for CI and other users to use as examples
<clever> mpickering: pkgs.fetchgit would avoid that issue
<clever> djanatyn: nice
<clever> djanatyn: use a 32bit stdenv
<clever> freeman42x[m]: pkgs.mpv
<clever> djanatyn: if you do `nix-shell -p` youll get a $NIX_CC var
<clever> djanatyn: yes

2020-04-26

<clever> $ nix-build channel:nixos-unstable -A hello
<clever> evils: the fishy part, is when every single nixos box claimed to have bad ram at the same offset
<clever> evils: not recently, but i did run into a quirk where it claimed some ram was bad at offset ~256mb, due to gcc hardening flags
<clever> freeman42x[m]: it usually solves itself after the build is done
<clever> freeman42x[m]: that can happen when mixing nix versions with your nix.conf version
<clever> Wulfsta: yeah
<clever> Wulfsta: wantedby makes your thing start before something else
<clever> Wulfsta: after just controls the order of starting things, and forces something else to start first
<clever> Wulfsta: after and wantedby are seperate things
<clever> Wulfsta: you want enabled = true; and then change wantedBy to control if it auto-starts or not
<clever> qy[m]: then nix didnt remove it, you never created it to begin with
<clever> within the same derivation
<clever> qy[m]: immediately after you build, run ls on the dir where you put the .o file, is it there?
<clever> qy[m]: what was the full output when building?
<clever> qy[m]: did you copy it to $out ?
<clever> qy[m]: can you pastebin the nix expr you have? and the result of building it?
<clever> ,xy qy[m]
<clever> qy[m]: what exactly are you trying to do?
<clever> qy[m]: runCommandCC doesnt run the fixupphase
<clever> qy[m]: add a `set -x` to one of your build phases, and then look at the logs to see which phase/hook is doing it, then change the settings so it doesnt
<clever> qy[m]: a static library is basically just a tar of .o files
<clever> qy[m]: you probably want to generate a static library with ar
<clever> qy[m]: why do you need them?
<clever> Wulfsta: it should be in the nixos manual
<clever> if your doing userland stuff, you probably want to stick to the one glibc provides
<clever> nh2: you need to shell int the wrong thing initially, and use some env vars
<clever> nh2: there is a guide on building kernel modules in the nixpkgs manual

2020-04-25

<clever> xfix: ive been trying midori for low-ram stuff
<clever> i have no idea!
<clever> vika_nezrimaya: i have 32gig of ram, and 28 gig of swap used, with 1800 tabs open.....
<clever> jakobrs: you want to look at trunk-combined, not nixos-test-expensive-eval
<clever> so its a problem with 5.4 somehow, not r8168
<clever> vika_nezrimaya: and it does still build on 4.19 unstable
<clever> vika_nezrimaya: it last build on jan 31st
<clever> vika_nezrimaya: also, i gave the directions while waiting for the search results, lol
<clever> vika_nezrimaya: clipboard!
<clever> vika_nezrimaya: if you go to hydra.nixos.org and run a search for that driver...
<clever> Nazral: you must first remove one of them with nix-env -e
<clever> Nazral: you installed 2 conflicting packages, that both provide tex related files
<clever> Nazral: what was the actual build error?
<clever> mchasard: yes
<clever> then your on the stable channel
<clever> sudo nix-channel --list
<clever> though the chown and chmod half of `install` are a bit useless on nix
<clever> bqv: i just use cp instead
<clever> rotaerk: run `nix-build '<nixpkgs>' -A godot && ls -l result/bin` to build a package and look at it
<clever> rotaerk: follow the symlink
<clever> rotaerk: find its binary in ~/.nix-profile/bin/ and then just run ls the dir
<clever> Nazral: nix-env -iA nixos.texlive.combined.scheme-full
<clever> > builtins.currentTime
<clever> jonathan84: for fetchurl, you can just use the standard sha256sum prog, nix accepts the hash in both base16 and base32
<clever> is the simplest nix way
<clever> ,tofu

2020-04-24

<clever> which will cast it to a string
<clever> nschoe: then you want background = "${/home/nschoe/wallpaper.png}";
<clever> either works
<clever> and you then wind up with the path to the copy instead
<clever> nschoe: when you try to cast a path to a string, nix will copy it to the store
<clever> nschoe: paths can be cast to a string automatically
<clever> yeah
<clever> nschoe: the process doing `nixos-rebuild` must have permission to read the file though
<clever> nschoe: correct
<clever> just background = ./background.jpg; and your done
<clever> nschoe: and if its unquoted, it can be outside the store, nix will copy it for you
<clever> nschoe: if you quote the path, nix wont know its a path, and none of the GC stuff will work
<clever> nschoe: what is the exact line you put into configuration.nix?
<clever> nschoe: then you quoted it when you shouldnt have
<clever> typetetris: cache.nixos.org has darwin as well
<clever> nschoe: the path must not be quoted
<clever> nschoe: then nix will add it to the store for you automatically, and copy it any time its missing
<clever> nschoe: instead do something.wallpaper = /path/to/lightdm-wallpaper.png; directly in configuration.nix
<clever> typetetris: add pkgconfig and opencv to buildInputs
<clever> typetetris: then create it
<clever> typetetris: still /etc/nix/
<clever> typetetris: /etc/nix/ just like linux
<clever> contrun[m]: the ram doesnt even work until the firmware has ran
<clever> contrun[m]: the reverse, the firmware is what loads the initrd into memory
<clever> i dont know why yet, but the kernel nix builds wont boot
<clever> contrun[m]: ive been doing similar when running nixos on an rpi with a custom set of firmware
<clever> contrun[m]: figure out which modules matter, and bake those into the kernel
<clever> nix-build '<nixpkgs/nixos>' -A vm -I nixos-config=./configuration.nix
<clever> then when you try to run nixos thru its vm system, it uses your kernel instead
<clever> contrun[m]: so you can use something like this, to just `rm $out/kernel ; cp ${./bzImage} $out/kernel`
<clever> and extraSystemBuilderCmds is the very last thing to be ran in toplevel
<clever> contrun[m]: when you use nixos-rebuild build-vm, and the -A vm attr, it expects a file called kernel in top-level