2019-05-05

<clever> symlinks would be cheaper, but harder to create/manage
<clever> pie_: things like nix-copy-closure arent aware of hardlinks, and will still transfer dups around
<clever> it was busy copying source around for days
<clever> pie_: ive seen chromium cripple hydra before, because there was a seperate unpackPhase derivation, and the source unpacked to over 10gig
<clever> and it was nearly identical to mine
<clever> > stdenv.override { cc = gcc8; allowedRequisites = null; }
<clever> oh, and it already exists, lol
<clever> > gcc8Stdenv
<clever> bohan: this creates a gcc8 stdenv, then you can use that with -E or in a .nix file with -A
<clever> > stdenv.override { cc = gcc8; }

2019-05-04

<clever> ajs124: not sure
<clever> not really sure about them either
<clever> musl-ld: final link failed: nonrepresentable section on output
<clever> ajs124: 7.4.0/crtend.o: relocation R_X86_64_32 against `.ctors' can not be used when making a shared object; recompile with -fPIC
<clever> lambda-11235: did you programs.fish.enable = true; ?
<clever> lambda-11235: because sudo is in /run/wrappers/bin
<clever> pie_: and when thats done, https://www.youtube.com/watch?v=zJt8yzR2aoY
<clever> pie_: its only 1:20 am
<clever> > pkgs.path
<clever> nix show-derivation and nix-instantiate
<clever> also, peek at the .drv that is building the thing
<clever> if rpackages accepts a { pkgs }:, it wont care about .override { stdenv = ?; }
<clever> pie_: all enableDebugging does, is change the stdenv with .override
<clever> 389 enableDebugging = pkg: pkg.override { stdenv = stdenvAdapters.keepDebugInfo pkg.stdenv; };
<clever> rrr: indirect roots could become an issue if your sharing it like that
<clever> pie_: that will apply an override to the stdenv, to enable debug
<clever> > enableDebugging hello
<clever> the raw gcc wont understand buildInputs
<clever> depends a lot on what you want to do with it
<clever> that is the raw unwrapped gcc
<clever> > gcc.cc
<clever> when linux launches an ELF binary, it passes in the address of a struct from the ELF headers
<clever> AT_PHDR: 0x8048034
<clever> pie_: http://dbp-consulting.com/tutorials/debugging/linuxProgramStartup.html also, look at the stuff near LD_SHOW_AUXV
<clever> do it!
<clever> pie_: i think the handle is a pointer to the ELF header in ram
<clever> maurer: all children inherit the layout from the parent
<clever> maurer: linux only suffers from a form of that via fork() for worker children
<clever> maurer: *doh*
<clever> not 100% sure what windows does/needs
<clever> linux also requires you to build with PIE, so it can load at a different address and not need relocations
<clever> pie_: so it can just drop the .text in /dev/null when low on ram, and read it back on when its next needed
<clever> pie_: i think the kernel will even treat the ELF file sorta like a swap file for those pages
<clever> pie_: and if 2 procs try to mmap the same region of the same file, in readonly mode, the kernel will reuse the pages
<clever> pie_: the loader uses mmap to map the library into a process
<clever> i dont think dlopen obeys rpath
<clever> if you try to dlopen something already in scope, it just returns the existing handle
<clever> jtojnar: what if you LD_PRELOAD a libcairo.so?
<clever> yep
<clever> so he could debug it with gdb :P
<clever> this crazy guy took a windows driver, mutated it into an ELF library, and then dlopen'd it into his program
<clever> dtz: a 45 byte ELF executable
<clever> dtz: internals of ELF
<clever> dtz: and some signing systems dont check the part of ELF thats turring complete :P
<clever> pie_: i saw something a year ago, about somebody writting the spec for a URL, purely by data from fuzzing a URL parser, lol
<clever> google knows
<clever> LD_DEBUG i think
<clever> pie_: yep
<clever> and should only act once
<clever> pie_: it could be a generic load function, that is ran from many places
<clever> pie_: dlopen returns a special handle, and you must then pass that to dlsym to lookup symbols in the lib
<clever> void *dlsym(void *handle, const char *symbol);
<clever> void *dlopen(const char *filename, int flag);
<clever> rrr: run both `modinfo dm-raid` and `modinfo dm-mirror`, then read the descriptions
<clever> pie_: ive noticed before, that chromium will deadlock if libredirect is in place
<clever> rrr: the find command i gave above
<clever> rrr: then maybe you want dm-mirror ?
<clever> /run/booted-system/kernel-modules/lib/modules/4.14.104/kernel/drivers/md/dm-mirror.ko.xz
<clever> rrr: lvm will activate on its own, so you shouldnt need to lvchange -a y
<clever> rrr: you may want boot.initrd.availableKernelModules = [ "dm-raid" ];
<clever> /run/booted-system/kernel-modules/lib/modules/4.14.104/kernel/drivers/md/dm-raid.ko.xz
<clever> [root@amd-nixos:~]$ find -L /run/booted-system/kernel-modules | grep dm-raid
<clever> rrr: what is your configuration.nix and what is the error it has?
<clever> rrr: lvm is always available in the initrd
<clever> rrr: lvm?, mdadm?
<clever> pie_: :D
<clever> pie_: libredirect?

2019-05-03

<clever> but the new haskell.nix stuff is entirely seperate from the old haskellPackages stuff
<clever> blackriversoftwa: yeah, thats mostly done with overlays in the haskellPackages context
<clever> blackriversoftwa: there are ~3 ways that is delt with, a translation map in cabal2nix, passing the right name when you callPackage, adding an override in the haskell overlay
<clever> pie_: there are some functions in nixpkgs that do basically that
<clever> nh2: `env | grep -i --color prop`
<clever> exarkun: `avahi-browse -at` does something similar
<clever> ,locate mdns-scan
<clever> tilpner: nix-store --verify
<clever> so, while it keeps the known-good nixos, it wont let you boot it :P
<clever> so that booted version wont be put back into the bootloader
<clever> it wont GC the target of booted-system, but it can delete the generation link
<clever> infinisil: it booted x86-64 and armv6l on the same rootfs
<clever> have i ever mentioned the 1st frankentstein install?
<clever> and the desktop is the 2nd install i ever made
<clever> my desktop is up to 470
<clever> from maybe 6 nixpkgs revs
<clever> 18.09 and 19.03 are still present
<clever> 18.03 was on the disk, but is gone now
<clever> up to gen 154 now
<clever> it has been keeping every single build of nixos, from day 1
<clever> i recently discovered my laptop still had generation 1 of nixos, lol
<clever> youll still have 100 copies of glibc
<clever> infinisil: its also going to hella-waste disk space by giving you 100 copies of glibc!
<clever> infinisil: thats going to make the qt version mismatch stuff 100x worse :P
<clever> 2019-05-02 23:12:27 < infinisil> So you wouldn't install hello from nixpkgs version 1e6bf25, but instead say "I want hello" and the tool would search the latest nixpkgs version that has a successful build of hello

2019-05-02

<clever> emilsp: install nix-index, and run nix-locate
<clever> tbenst_: -I nixpkgs=/path/to/nixpkgs
<clever> dckc: nix-shell -p python27Packages.hg-git
<clever> dckc: nix-shell -p needs an attrpath
<clever> i flip my editor over to replace mode, and 0 out a few digits of the hash, to make sure its wrong
<clever> tbenst: if the hash is for something you already have, nix believes you, and uses that source directly

2019-05-01

<clever> camsbury: you likely want to just directly give mkDerivation the buildInputs list, and ignore buildEnv
<clever> camsbury: the stdenv doesnt know what to do with env = ...; so it just becomes an env variable
<clever> camsbury: do `echo $env` inside the shell?
<clever> use IFD to write it to a file, then pipe it thru jq, and readfile it back in, then trace that!!!
<clever> pie_: pipe it thru jq?
<clever> zen_monk: yes, but that wont run a tor node on its own
<clever> so when execve returns a new error code, it gives a sane msg
<clever> the libc in the parent process
<clever> gchristensen: and libc would also need to be extended to translate the error corectly
<clever> gchristensen: i think that would be a kernel level patch
<clever> try all of them!
<clever> iqubic: check the device profiles on the configuration tab
<clever> keep doing things!
<clever> m
<clever> iqubic: run alsamixer, select the non-pulse device with f6, and then play with the mute and volume levels on the capture page
<clever> iqubic: you can even `export TZ=America/Halifax` to affect only the programs in one shell
<clever> arcnmx: i think its because the nix deleting the path will exclude itself from the gcroots, but the sudo that started it isnt excluded
<clever> so i have 4 clocks on-screen, each showing a different timezone
<clever> roconnor: i can also reconfigure the xfce clock to show any 1 timezone, and i can put multiple clocks onto a single taskbar
<clever> so just dont sudo it
<clever> but you dont need sudo to delete paths
<clever> it also checks the argv
<clever> but, sudo nix-store --delete /nix/store/foo, will result in sudo "using" it, so it can never be deleted
<clever> arcnmx: nix-store --delete /nix/store/foo will not depend on foo, for obvious reasons
<clever> yeah

2019-04-30

<clever> yeah
<clever> arcnmx: part of it, is that if the build needs certain inputs, nix will try to push them over, and then the slave must trust those pre-built inputs
<clever> arcnmx: ah
<clever> arcnmx: ive used the community box as a build slave without issues
<clever> arcnmx: weird
<clever> arcnmx: then build slaves should also work, if you can turn off sig checking (or sign things)
<clever> arcnmx: try using `nix-copy-closure` to copy a given drv over
<clever> because you just save it as hash($bad), and it co-exists beside hash($good)
<clever> i cant give you $bad, and claim its $good
<clever> arcnmx: nope, because the .drv file is purely a hash(value)=value based DB
<clever> so you must trust that remote machine to give you what you asked for
<clever> the problem build slaves introduces, is that you are trusting a remote machine to just give you a tar, claiming its $out
<clever> nix-daemon enforces that $out is made by the directions, so if you ask for the original sudo, you get the original sudo
<clever> arcnmx: and $out is also based on that same hash
<clever> arcnmx: evaluation is done by the user, and is turned into .drv files, that are named after the hash of the build directions
<clever> JaakkoLuttinen[m: pkgs.substituteAll
<clever> you can also `nix-store --verify --check-contents` to make it just test the hash of everything
<clever> if they get out of sync, somebody has been naughty, and nix will claim the directory is corrupt
<clever> and the above is how to query the correct hash, and compute the current hash
<clever> camsbury: nix also tracks the hash of every directory in db.sqlite
<clever> [root@amd-nixos:~]$ nix-hash --base32 --type sha256 /nix/store/0j1sc30kjf9b3j7j0sp68jns2v34apr0-pcre-8.42
<clever> [root@amd-nixos:~]$ nix-store --query --hash /nix/store/0j1sc30kjf9b3j7j0sp68jns2v34apr0-pcre-8.42
<clever> yeah, the entire /nix needs to be one volume
<clever> and will want to download whatever is "missing"
<clever> if that is getting rolled back, then nix will believe the other files in /nix/store are also rolled back
<clever> its in /nix/var/nix/db/
<clever> this will either report the size, or claim the path is not valid
<clever> nix-store --query --size /nix/store/0j1sc30kjf9b3j7j0sp68jns2v34apr0-pcre-8.42
<clever> camsbury: but did db.sqlite claim its valid?
<clever> camsbury: i think the problem is more that docker doesnt understand that, and it makes a new layer for every command in your compose file
<clever> camsbury: you probably want to just generate a docker image directly from a nix expr
<clever> camsbury: docker compose will want to re-run the commands when you change things, similiar to how nix rebuilds when you change the expr
<clever> manveru: so the end result of the nix-build was just a single directory full of html&css, and it could then be hosted staticly
<clever> manveru: i saw a wordpress setup before, explained in some blog, where it would spin the entire thing up in a vm, then clone it with recursive wget
<clever> yeah
<clever> Twey: but cc-wrapper needs to manipulate those flags
<clever> Twey: i think gcc accepts @file in the args, and then you can put any gcc flag into the file, to get around argv length issues
<clever> kalbasit: bind mounts can be used to get around that
<clever> kalbasit: yeah
<clever> aha
<clever> hodapp: what channel are you on?
<clever> docs make no mention of that, did you set guiAddress?
<clever> hodapp: what does `journalctl -f -u syncthing.service` say?
<clever> green is what configuration.nix adds, red is what it removes
<clever> start2: that is every difference between generation 42, and the current configuration.nix
<clever> [root@system76:~]# nix-diff $(nix-store -q --deriver /nix/var/nix/profiles/system-42-link) $(nix-instantiate '<nixos/nixos>' -A system)
<clever> start2: if you have the old state in a rollback profile, you can use that too
<clever> [root@system76:~]# nix-diff $(nix-store -q --deriver /run/current-system) $(nix-instantiate '<nixos/nixos>' -A system)
<clever> then you can edit it to make it differ less
<clever> start2: you can use nix-diff to compare the current config against the currently running OS

2019-04-29

<clever> that file has the disk image
<clever> Orbstheorem: it creates a file in the directory you started it, ls -ltrh
<clever> > a:b
<clever> /foo + ("/" + "bar") -> /foo/bar
<clever> /foo + "/" + "bar" -> /foobar, again!
<clever> /foo + "bar" -> /foobar!!
<clever> path + string -> path
<clever> das_j2: dont call toString either, paths turn into strings on their own
<clever> das_j2: dont call toPath, its already a path
<clever> talqu: you may need to set allowed users as well
<clever> talqu: check the journal for nix-daemon.service
<clever> talqu: with sudo, it ignores the nix-daemon
<clever> das_j2: env vars at eval time or nix vars?
<clever> talqu: flip around who initates the transfer
<clever> talqu: you can also ssh into a normal user, sudo -i, and then nix-copy-closure --from otherend /nix/store/foo
<clever> das_j2: if you dont quote a path, nix will include it in the sandbox for you
<clever> talqu: check the journal for nix-daemon.service
<clever> talqu: if you run `nix-build '<nixpkgs>' -A hello` on the remote machine, wht does it say?
<clever> mwilsoncoding: the one that is calling buildPythonPackage i think
<clever> and then the source can be any user
<clever> talqu: but if you flip the initiator, you can just sudo -i on the remote machine, and do a --from instead
<clever> switch up who initiates it!
<clever> or: ssh root@remote, nix-copy-closure --from anybody@what-was-local /nix/store/foo/
<clever> or: nix copy --to root@remote --no-check-sigs /nix/store/foo
<clever> or: nix copy --to remote --no-check-sigs /nix/store/foo
<clever> talqu: nix-copy-closure --to root@remote /nix/store/foo
<clever> talqu: the receiver needs to be trusted, not the sender
<clever> you can also setup the sender to sign things, with a key the receiver trusts, if you plan to do it a lot and like the extra security
<clever> `nix copy --no-check-sigs` will disable checking, but again, you must be trusted to change that
<clever> (either run as root, or add yourself as a trusted user)
<clever> talqu: the receiver needs to be a trusted user in nix.conf
<clever> talqu: nix-env -f foo.nix -iA bar <- nix-build foo.nix -A bar
<clever> mightybyte: this will generate a bash script that partitions, formats, and installs, and supports legacy or efi, with optional luks
<clever> mightybyte: but on the flip side, gpt works in all situations, and it can still boot legacy
<clever> mightybyte: if the disk is under 2tb in size, then there is basically no reason against MBR

2019-04-28

<clever> updated the issue so it can fix your issue in the future
<clever> the above issue, is to fix it via --option builders or something else
<clever> but its broken by multi-user nix
<clever> there is code to detect if you are on a mac, and auto-configure build slaves, just for nixops, to use the target
<clever> sphalerite: ah, the mac logic may still work-ish, https://github.com/NixOS/nixops/issues/984
<clever> sphalerite: mac source machine?
<clever> then you just need to modify the import function to both recurse/spread-like-a-virus (when importing, it should use scopedImport moar!), and also to detect the filename in question, and import the "wrong" thing
<clever> yeah
<clever> you can then pass the function it returns to callPackage to provide it the args it originally wanted
<clever> that will replace what `import` does within the imported file
<clever> basically, scopedImport { import = myfunc; } ./path-to-file.nix
<clever> numinit: scopedImport is another way to do what you want
<clever> android also mounts even its internal /data with such options, despite only trusted things having root on it
<clever> to both of those :P
<clever> gchristensen: same, lol
<clever> auto-mouting with nodev,noexec blocks such attacks
<clever> then i can just auto-mount it on your PC, and write to it :P
<clever> and the whole point of nodev, is that i could create a 777 sda on my usb stick
<clever> you can then freely chown/chmod the copy, and it will keep the perms, independantly of the other copies
<clever> mknod (with root) can re-create that anywhere (as long as its not mounted with nodev)
<clever> the 10 and 232, are the major and minor numbers for the char device
<clever> crw-rw-rw- 1 root kvm 10, 232 Apr 12 08:32 /dev/kvm
<clever> gchristensen: oh, and nix-daemon could do the same, lol
<clever> gchristensen: docker has root though, so it can create a duplicate of /dev/ nodes, and chown/chgrp them from the containers namespace
<clever> jasom: thats likely also why nix doesnt use the kvm group on /dev/kvm, but rather, 777
<clever> tdeo: runCommand also works

2019-04-27

<clever> home-manager is just a more powerful/complex way of doing that
<clever> putting a buildEnv into your config.nix makes it trivial to update everything at once, so you cant cuase that issue
<clever> simply by not updating something you dont use anymore
<clever> yeah, nix-env makes it easy to break it by accident
<clever> boom, now your mixing nixpkgs :P
<clever> ambro718: systemPackages = [ (import <nixpkgs-16.09> {}).wireshark-qt ];
<clever> i think the original goal, was to let you install QT plugins with nix-env -i, and it would then search ~/.nix-profile/lib/qt-5.9/ at runtime to discover them
<clever> patching qt to use 5.9.0 instead of 5.9 would instantly fix this problem
<clever> so now, it crashes on login :P
<clever> ambro718: because an old QT was in nix-env, and had priority over the system QT, so the new QT apps from KDE (that manage the entire login session) borked
<clever> ambro718: i have seen the KDE desktop env totally bork, when doing nixos-rebuild --upgrade
<clever> why didnt it just put the libs into 1.2.1 and 1.2.2!?!?!
<clever> and anoyingly, QT puts the libs into a 1.2 dir, but then if you mix 1.2.1 and 1.2.2, it complains and refuses to start
<clever> if 2 different things both request QT via nix-support/propagated-user-env-packages, nix-env wont even tell you about the collisions
<clever> QT has a lot of problems in this area
<clever> well, it wont even be there for nix-env -i /nix/store/foo, only nix-env -iA nixos.foo
<clever> and it would forget about it
<clever> but the 2nd time around, when its only in manifest.nix, it wont be there (enless you save it to manifest.nix)
<clever> they may be available during the first pass with nix-env -i /nix/store/foo
<clever> yeah
<clever> -i and -e, will read ~/.nix-profile/manifest.nix, apply some mutations (adding/removing things), then build a new env based on that result, and bake the new manifest.nix into it
<clever> but thats different from --set
<clever> which will remove all other packages when installing home-manager-path
<clever> home manager might be using nix-env -ir
<clever> as far as nix-env is concerned, your just upgrading a "package" called "home-manager-path"
<clever> ambro718: thats what i prefer, and that behaves very similar to home-manager (from nix-env's viewpoint)
<clever> so if a noob does nix-env -i, it will the second layer of buildenv will merge things sanely
<clever> the perl buildenv merges everything, then the c++ buildenv merges that with /manifest.nix to create ~/.nix-profile/
<clever> then home manager is the only thing installed, but it is a sort of double buildenv
<clever> i dont have home manager, so i cant see what it does
<clever> ah
<clever> ambro718: ~/.nix-profile/manifest.nix is missing?
<clever> what does nix-env -q report on your end?
<clever> and that would use the perl version in your current nixpkgs
<clever> and then just name that bash script home-manager-rebuild
<clever> and like nixos-rebuild, you can just make a bash script that mutates the config, and then calls that for you
<clever> you would do something like, nix-env -f '<home-manager>' -A config.system.toplevel --set ~/.nix-profile
<clever> yeah
<clever> no storage is on the pi, so all changes can be undone remotely
<clever> and if i brick the pi, i can just --rollback to undo!
<clever> my tftp dir is then pointing at that, so it just boots
<clever> ambro718: this builds an netboot compatible image of notos (for the rpi), and puts it into a profile
<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> one sec...
<clever> you have to import a different nixpkgs