2019-09-18

<clever> but that might leak into swap, depending on system conditions
<clever> Ariakenom: only in ram, in the scrollback history of your terminal emulator, which is usually gone once you close the terminal
<clever> (if nothing else happens to also be needing it)
<clever> and once `meacs.root` is deleted, you can GC emacs
<clever> `nix-build '<nixpkgs>' -A emacs -o emacs.root` will create an `emacs.root` symlink
<clever> use nix-build instead, to just build things
<clever> if you dont want something rooted jsut yet, dont give it to nix-env
<clever> and nix is keeping things around incase you choose that action
<clever> ctp: because you may choose to roll forwards instead, to redo those actions
<clever> but your better off just doing your install in an atomic manner, so it either happens, or doesnt
<clever> `nix-collect-garbage -d` is the nuclear option, to just get rid of all ability to undo actions
<clever> and you still have the option to rollback to that generation
<clever> that path cant be deleted, because an older generation refers to it
<clever> ctp: and nix is holding on to the old emacs, incase you choose to `nix-env --rollback` to undo the last action
<clever> ctp: that is exactly what generations and rollbacks are for
<clever> ctp: why do you want to entirely delete the package? it shouldnt be harming anything
<clever> lrwxrwxrwx 1 clever users 16 Aug 6 19:57 /nix/var/nix/profiles/per-user/clever/profile -> profile-453-link
<clever> thats the whole point of this room
<clever> Guest66: mkForce can do that, but then you loose a lot of the merging logic between your own files
<clever> Guest66: it already does that out of the box, just set it without trying to merge

2019-09-17

<clever> tyrion-mx: you can use the above 2 things as examples of dealing with the few native deps you run into
<clever> flow-bin ships a pre-compiled ELF that has to be patchelf'd
<clever> notgne2: node-sass compiles some c++ against nodejs
<clever> notgne2: i have an example of yarn2nix, which involves some c++ code
<clever> tyrion-mx: nix creates a tmpdir for you, and your already cd'd into it when your buildCommand starts
<clever> tyrion-mx: the current dir
<clever> tyrion-mx: whatever the nodejs stuff is in
<clever> tyrion-mx: yarn2nix also accepts a yarnLock argument, so you can pass that without having to fork the repo
<clever> then use that one
<clever> tyrion-mx: you can probably just run `yarn install` to generate a `yarn.lock` file
<clever> tyrion-mx: yarn2nix uses yarn.lock instead
<clever> turtlerabbit: libredirect is an LD_PRELOAD library, that can remap all filesystem access, without a chroot or container
<clever> turtlerabbit: then you want libredirect, look at the teamcpeak client
<clever> lrwxrwxrwx 1 clever users 60 Aug 6 19:57 /nix/var/nix/profiles/per-user/clever/profile-453-link -> /nix/store/69khyarmij2n9xwwsq00apghnpwfsyvx-user-environment
<clever> v0|d: yeah
<clever> turtlerabbit: thats in a few packages, like skype i think
<clever> turtlerabbit: that would also work
<clever> v0|d: nix copy --from local?root=/mnt /nix/store/hash-name
<clever> v0|d: ah, if its only mounted, nix copy is better
<clever> turtlerabbit: you can also use pkgsi686Linux.crossover maybe
<clever> turtlerabbit: you need to add `--argstr system i686-linux` to tell nixpkgs to be 32bit
<clever> v0|d: you likely want to read what .nix-profile is pointing to, then use nix-copy-closure to copy that storepath over, then nix-env --set /nix/store/foo to set your profile to point to that
<clever> turtlerabbit: how did you drop into the nix-shell?
<clever> v0|d: are you moving it to another machine?
<clever> turtlerabbit: how exactly is it not working?
<clever> > "${pkgs.pkgsi686Linux.hello}"
<clever> tyrion-mx: you may also want to look into yarn2nix
<clever> tyrion-mx: if pkgconfig is in the buildInputs, it will fix PKG_CONFIG_PATH and add -L flags for you
<clever> v0|d: this symlink in the home dir is part of it
<clever> [clever@amd-nixos:~]$ ls -l .nix-profile
<clever> lrwxrwxrwx 1 clever users 45 Oct 11 2015 .nix-profile -> /nix/var/nix/profiles/per-user/clever/profile
<clever> laerling: i use `dig` to resolve things
<clever> boogiewoogie: what does `file` say about that path? how big is the file?
<clever> sb0: ive also had a different problem, where my router has lately just been refusing to route v6 packets, even with all the right flags set
<clever> sb0: i'll need to try that out later
<clever> so you can use the expr in nixpkgs, but the local src
<clever> that will load nixpkgs, grab the hello attr, then change the src to the current dir
<clever> with import <nixpkgs> {}; hello.overrideAttrs (old: { src = ./.; })
<clever> you could also do
<clever> then use `with import <nixpkgs> {};` and `src = ./.;`
<clever> why not?
<clever> which will use the callPackage in pkgs/top-level/all-packages.nix
<clever> you want to run `nix-build -A foo` in the root of the checkout
<clever> thats why the example i gave started as `with import <nixpkgs> {};` instead, so it doesnt need callPackage
<clever> ,callPackage iqubic
<clever> iqubic: yes
<clever> iqubic: the buildInputs are present for every phase
<clever> iqubic: installPhase or postInstall
<clever> eclipse itself is written in java, so there must be a makeWrapper call handling that
<clever> if configure doesnt exist, add nativeBuildInputs = [ autoreconfHook ];
<clever> if configure exists, then you dont need ac
<clever> gcc is always provided
<clever> 2019-09-17 02:16:45 < clever> iqubic: you just want `buildPhase = "./Make.sh";` and the default configurePhase will deal with configure
<clever> iqubic: only the default configurePhase does --prefix for you, if you manually ./configure, that wont happen
<clever> notgne2: probably
<clever> if https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/testing/service-runner.nix was rewritten in c++, that would fix both issues
<clever> and yeah.... its perl
<clever> it doesnt escape " right, so any " in the ExecStart breaks things
<clever> that is meant for testing systemd things
<clever> the main issue (oh perl), is that i'm using the systemd.services.whatever.runner attr, which is a dynamically generated perl script
<clever> that (mostly) seamlessly lets existing nixos modules work in docker
<clever> notgne2: i could also add a thing to map over users.users, and auto-gen users
<clever> notgne2: the gist i linked above, is a docker-specific case, where i translate all systemd.services entries, over to runit services, then tell docker to run runit
<clever> notgne2: de-perl'ing and de-systemd'ing is what i started not-os for
<clever> notgne2: you could eval system.activationScripts.users, but that is the very thing that depends on perl
<clever> notgne2: what parts of the setup are you relying in?
<clever> if you want to run systemd
<clever> notgne2: init is responsible for running systemd, so it needs to be present at all times
<clever> notgne2: also, read https://github.com/NixOS/nixpkgs/pull/64594
<clever> notgne2: what are you generating in runAsRoot?
<clever> also, read Make.sh, and see what its doing, it may be something you want to bypass
<clever> iqubic: you just want `buildPhase = "./Make.sh";` and the default configurePhase will deal with configure
<clever> iqubic: that is the *default* prefix, --prefix=$out will fix that, which nixpkgs does automatically
<clever> notgne2: but i believe nix is generating a new layer when doing that qemu stuff, so GC wont help
<clever> notgne2: i dont think chroot can be used in the nix sandbox, runAsRoot gets around that by booting qemu with the docker image mounted
<clever> 4 if you count nixops
<clever> anything involving pkgs, lib, or the stdenv, is part of nixpkgs
<clever> nix is just builtins.whatever, the basic syntax, and the shell commands
<clever> iqubic: makeWrapper and phases are part of nixpkgs, so they will be in the nixpkgs manual, not the nix manual
<clever> iqubic: are you sure you checked the manual?
<clever> notgne2: runAsRoot also generates a new layer, so anything you delete wont be deleted, as it will persist in previously layers
<clever> notgne2: runAsRoot is typically costly, and will harm performance, its best to not use it
<clever> notgne2: so nothing will be garbage
<clever> notgne2: and a GC wouldnt help, nix only copies the things you depend on into the image
<clever> notgne2: https://gist.github.com/cleverca22/f3e54a2e0ade7e5f38a6ee4b20d83e14 this generates a docker image, without systemd, that runs a list of nixos services, ive confirmed that nginx and postgresql work
<clever> iqubic: that should all be in the nixpkgs manual
<clever> notgne2: let me check my gists...
<clever> and maybe add src = ./.;
<clever> iqubic: i usually start with: with import <nixpkgs> {}; stdenv.mkDerivation { name = "name"; buildInputs = [ openjdk ]; }
<clever> iqubic: services.xserver.displayManager.sessionCommands = "export _JAVA_AWT_WM_NONREPARENTING=1";
<clever> `true` behaves a bit oddly in nix
<clever> _JAVA_AWT_WM_NONREPARENTING = true; in the nix should do that
<clever> id say thats a bug in the syntax highlighter then
<clever> i dont think they are
<clever> iqubic: _foo = "bar";
<clever> iqubic: every attribute you pass to mkDerivation becomes an env var
<clever> gyroninja: yeah, not really clear whats missing
<clever> gyroninja: does it say which jdk tools its looking for?
<clever> though thats identical to just plain `nix-shell -p openjdk`
<clever> iqubic: with import <nixpkgs> {}; stdenv.mkDerivation { name = "name"; buildInputs = [ openjdk ]; }
<clever> iqubic: buildInputs = [ openjdk ];

2019-09-16

<clever> tv: unicode might like to speak with you
<clever> dansho: with the current partition layout, you cant EFI boot, and must do legacy boot, which the configuration.nix is already setup for, you just need to make sure the firwmare is going to legacy boot, not efi boot
<clever> freeman42x: the iso is already a bootable usb image, just dd it directly to the root device of the usb stick
<clever> freeman42x: yes
<clever> freeman42x: that breaks everything, use plain dd
<clever> freeman42x: how did you write the iso to the usb stick?
<clever> so /boot is optional, and sda4 is an extended partition, you cant mount sda4
<clever> dos partition types cant UEFI boot
<clever> dansho: disk label type, not partition type
<clever> dansho: when you do `fdisk -l /dev/sda`, what is the disk label type?
<clever> dansho: what exact args did you use with mount?
<clever> dansho: if you mount sda4 to the nixos boot folder (/boot if your still inside enter, /mnt/boot if your outside), what files are inside that dir?
<clever> dansho: can you pastebin the output of `fdisk -l /dev/sda` ?
<clever> dansho: the uefi /boot will be fat32, so run `blkid /dev/sda*` and look for a fat32 fs
<clever> dansho: for uefi, you definitely have to mount /boot/
<clever> dansho: if you have a /boot partition, you must also mount that, at /mnt/boot/
<clever> dansho: did you mount /boot correctly before doing nixos-enter?
<clever> dansho: and is sda still your root device?
<clever> dansho: what was boot.loader.grub.device set to in configuration.nix?
<clever> dansho: try /nix/var/nix/profiles/system/bin/switch-to-configuration boot --install-bootloader
<clever> yes
<clever> dansho: are you sure you used boot?
<clever> notgne2: can you pastebin the nix expr?
<clever> notgne2: that would imply its not adding anything new, which you have claimed it was
<clever> notgne2: if you build the toplevel twice, with and without that overlay, how do the paths differ?
<clever> notgne2: if you build the top-level drv, with nix-build, can you then compare the size of 2 of them with nix-store -qR ?

2019-09-15

<clever> Henson: buildFHSUserEnv
<clever> it should know the rev
<clever> nix-prefetch would have to be modified, to use the same name
<clever> then it will work with current nix
<clever> alexarice[m]: i would just put those things into the name of the drv
<clever> if it exists, then it makes no attempt to build it
<clever> then check if that already exists in /nix/store/
<clever> it will compute what $out should be, based on name and sha256
<clever> alexarice[m]: a fixed-output drv ignores all attrs other then name and sha256
<clever> infinisil: it should be able to generate the same name attr
<clever> but somebody changed the name to "source"
<clever> infinisil: the $out is based on the name and sha256, so changing the rev changes the name, and the $out, causing it to properly re-check
<clever> infinisil: originally, fetchFromGitHub would put the rev into the name
<clever> alexarice[m]: so nix doesnt rebuild the world when the version of git or curl changes
<clever> alexarice[m]: thats the point of a fixed-output drv
<clever> rotaerk: LD_LIBRARY_PATH needs to point into /run/opengl-driver/lib/ for opengl stuff to work
<clever> notgne2: and then why-depends on that path, outside of docker
<clever> notgne2: use nix-build outside of docker, against the toplevel expr you pass to buildImage
<clever> notgne2: why-depends can also help with perl
<clever> notgne2: use nix why-depends to track those down
<clever> notgne2: how big is your image, that 25mb is worth the trouble?
<clever> notgne2: if you use an overlay to modify glibc, then nix must rebuild EVERYTHING
<clever> notgne2: why do you want to use static linking in the docker image? it feels like it would increase the size
<clever> yep
<clever> emily: look this up in the nixos options
<clever> systemd.services.<name>.environment
<clever> emily: yeah
<clever> and update the symlink on login
<clever> you could also have a static symlink, that points to the dynamic path
<clever> emily: i think if you set SSH_AUTH_SOCK before you run gpg-agent, it will obey that
<clever> then root can still use the yubikey
<clever> you could set the SSH_AUTH_SOCK env var, for nix-daemon, to point to your gpg-agent
<clever> why not just fix root to be able to use the build slave?
<clever> if it has +w to something in /nix, it wont contact the daemon, when in auto mode
<clever> if you run nix-build as root, it will behave in a single-user type mode
<clever> ah, ive not looked into how its being done
<clever> the rules still exist
<clever> and a udev thing is ran in stage-1
<clever> tilpner: i think its still "udev" (which got eaten by systemd)
<clever> tilpner: systemd is only ran late in stage 2
<clever> eyJhb: mkdir $out ; cd $out ; ln -sv ${hello} hello
<clever> eyJhb: the script in the ''string'' is responsible for creating $out, and whatever path is in $out will wind up in something
<clever> yeah
<clever> ah, its ignore-liveness
<clever> nix-store --delete [--ignore-liveness] paths...
<clever> j-em: if `--query --roots` only shows lsof, then try `--delete --force`
<clever> j-em: nix-env --delete-generations 9 11 ; nix-store --delete /nix/store/ihz9qxg66s0wpx9dlq9p4s54xi8bnq9y-vscode-1.38.0
<clever> j-em: nix-env -e 'vscode.*' then repeat the last 2 commands
<clever> j-em: ls -l /nix/var/nix/profiles/per-user/jeremyallard/profile
<clever> j-em: what about `nix-store --query --roots /nix/store/ihz9qxg66s0wpx9dlq9p4s54xi8bnq9y-vscode-1.38.0` ?
<clever> j-em: then you need to fix the ownership on /nix, so you own every file (sudo chown -R USER /nix/), and then re-do repair-path without root
<clever> j-em: single-user or multi-user? is nix-daemon running?
<clever> j-em: is this on nixos or another os?
<clever> j-em: sounds like your ssl ca files arent visible to nix for some reason
<clever> j-em: what does `date` return?
<clever> j-em: try running it as root?
<clever> j-em: yeah
<clever> dansho: yeah
<clever> dansho: and configure mint to not touch the MBR
<clever> dansho: you need to chroot into nixos, and run `nixos-rebuild boot --install-bootloader` to fix the bootloader back to grub
<clever> j-em: nix-store --repair /nix/store/ihz9qxg66s0wpx9dlq9p4s54xi8bnq9y-vscode-1.38.0
<clever> oops
<clever> j-em: nix-store --repair https://pastebin.com/aLUsQAa4
<clever> j-em: what does --verify report?
<clever> but dont use --force if it fails

2019-09-14

<clever> cant think of what else to check then
<clever> incognito9999: what do you see if you run pavucontrol?
<clever> incognito9999: is pulseaudio enabled?
<clever> and just reuses the old result
<clever> your telling it the hash of the result, and if you claim the hash hasnt changed, then it assumes the result hasnt changed
<clever> Melkor333: yes
<clever> maralorn: nice
<clever> maralorn: its generated in the same set of conditions that copy the headers
<clever> not sure, those might be able to use pkgconfig, if luv generated one
<clever> switching over would let you drop the submodules
<clever> which is why you needed fetchSubmodules
<clever> if you dont set that, it will build its own copy of libuv, making the build slower
<clever> maralorn: it will only do that if you -DWITH_SHARED_LIBUV
<clever> maralorn: this tells cmake to use pkgconfig to file a library
<clever> find_package(Libuv REQUIRED)
<clever> maralorn: i think you want something like: cmakeFlags = [ "-DLUA=Off" "-DBUILD_MODULE=Off" ];
<clever> maralorn: it will only install headers if both lua and build_module are false
<clever> maralorn: build_module defaults to on, lua will be printed early in the build
<clever> option(BUILD_MODULE "Build as module" ON)
<clever> MESSAGE(STATUS "LUA: " ${LUA})
<clever> maralorn: do you know what the lua and build_module flags are set to?
<clever> maralorn: can you link or pastebin the cmake file?
<clever> maralorn: you may just need to edit the cmake file then to do that
<clever> maralorn: is the cmake file setup to actually copy headers?
<clever> it works like this
<clever> 87 #extraModulePackages = [ config.boot.kernelPackages.v4l2loopback ];
<clever> 89 #kernelPackages = pkgs.linuxPackages_latest;
<clever> kernelPackages is a set of all packages, not a list
<clever> oh wait, backwards
<clever> rndd: you need to give it a single package, not a set of all linux packages
<clever> 2019-09-14 19:09:22 < rndd> kernelPackages = [pkgs.linuxPackages_latest pkgs.rtlwifi_new];
<clever> li_matrix: sounds like your from #osdev
<clever> li_matrix: i think it would be much simpler if you just use nix copy, then to re-invent the signatures
<clever> li_matrix: and users can choose to either fetch the URL: field, or the ipfs field
<clever> li_matrix: then you host a modified copy of the .narinfo, on a central http server
<clever> li_matrix: my idea on what needs to be done for ipfs, is to just add one more field, the ipfs hash of the nar.xz
<clever> just a series of "key: value" pairs
<clever> fairly simple
<clever> li_matrix: a custom format
<clever> i think
<clever> the signature is over the string: "1;/nix/store/n9z80xrc7bidx5hcap2wvb5l9r2vk6y0-hello-2.10;1b80qjckhfhpfmjd8gr8zrkicvika8523hpids707fpj8wf4rw3c;205720;n9z80xrc7bidx5hcap2wvb5l9r2vk6y0-hello-2.10 xqs95fqkjb1kd102yjv5h5q57gcsafb3-glibc-2.27"
<clever> li_matrix: run this
<clever> li_matrix: have you looked at a narinfo file yet?
<clever> Batzy: sounds like the package is broken, and youll need to wait for somebody to fix it, maybe file an issue on nixpkgs
<clever> li_matrix: and the signing happens in c++, using libsodium
<clever> this will return a string in the form of "1;/nix/store/hash-foo;<narhash>;<narsize>;<dependencylist>"
<clever> thats how nix-serve is generating the signatures
<clever> $res .= "Sig: $sig\n";
<clever> my $sig = signString($secretKey, $fingerprint);
<clever> my $fingerprint = fingerprintPath($storePath, $narHash, $narSize, $refs);
<clever> you need to have the full nar file to generate either hash
<clever> the hash cant really be converted
<clever> and needing a lookup table, between store-path hash, and ipfs hash
<clever> there is still minor issues, like how ipfs uses a merkle hash, and nix uses a single hash
<clever> and its then just the hash over that whole thing
<clever> li_matrix: the nar is basically a tar, containing every file in the directory
<clever> li_matrix: what part of that isnt secure?
<clever> yes
<clever> discord in the config, but then run Discord to actually start it
<clever> you may already have it installed, and have just been running the wrong command
<clever> they like to make the guessing games hard
<clever> Batzy: also, the binary is called Discord
<clever> and then nixos-rebuild switch to apply it
<clever> if discord is in configuration.nix, then you want nixpkgs.config.allowUnfree = true;
<clever> Batzy: if you use sudo, then it uses the config.nix in /root/ instead
<clever> Batzy: what about nix-env -iA nixos.discord?
<clever> Batzy: what does `nix eval nixpkgs.config` return?
<clever> Batzy: what path is config.nix at?
<clever> li_matrix: which is just the hash of `nix-store --dump /nix/store/foo`
<clever> li_matrix: the signature is over the narhash
<clever> yeah
<clever> so you need some kind of index, to map the hashes
<clever> oh right, bot is down
<clever> > "${hello}"
<clever> but the nix binary cache isnt using the hash of the product, its using the hash of the build directions
<clever> ipfs needs to know the hash of the product
<clever> that has other problems
<clever> li_matrix: or re-write it in a better language
<clever> the other option is to fix nix-serve, to have support for the new signature stuff