2019-08-06

<clever> Mateon1: gcc wont work when used outside of nix-shell
<clever> that includes compilers as well
<clever> ,libraries Mateon1

2019-08-05

<clever> might be the only way to undo it
<clever> and it will continue to persist, even after you forget, and it overrides NIX_PATH!
<clever> 2019-08-05 15:47:10 < clever> asymmetric: but nixops modify -I ... foo.nix, will persist in the state file
<clever> 2019-08-05 15:47:00 < clever> asymmetric: deploy -I ... only affects that one deploy
<clever> Miyu-chan: yep
<clever> and i dont think there is any way to remove an entry once set
<clever> the only way to change it is with another `nixops modify -I nixpkgs=...`
<clever> and that is overriding NIX_PATH
<clever> asymmetric: aha, so you did a `nixops modify` in the past, like i said to do earlier
<clever> asymmetric: check `nixops info`
<clever> asymmetric: does it show a `Nix path:` ?
<clever> asymmetric: what does `nixops info` say?
<clever> asymmetric: are you on nixos or another distro?
<clever> ah
<clever> gchristensen: what is pkgs.packet?
<clever> asymmetric: can you pastebin your shell.nix?
<clever> the comment also keeps track of what rev i should be using
<clever> and i just leave a comment to remind myself if i ever forget
<clever> in my case, i'm the only one modifying the repo, and there is only one deployment of it, so i know when thats needed
<clever> only problem is that you have to re-run modify when changing things, so it cant update on `git pull`
<clever> asymmetric: i prefer nixops modify, since it persists for you
<clever> asymmetric: but nixops modify -I ... foo.nix, will persist in the state file
<clever> asymmetric: deploy -I ... only affects that one deploy
<clever> ,tofu
<clever> colemickens: the number is just an index into a list, and doesnt mean much
<clever> colemickens: a currently running process refers to that path
<clever> thoughtpolice: and they just didnt want to deal with auditing it for problems, so they just disable it
<clever> thoughtpolice: from what i heard, its more about adding a large chunk of un-audited code to the kernel
<clever> but now you rely on both fuse support (which itself has some security problems) and user namespacing (which debian claims has security problems)
<clever> because a true mounted FS would open the kernel up to buffer overflow exploits in the FS driver, along with things like setuid binaries
<clever> your only allowed to `mount --bind`
<clever> i think they are forced to use fuse, because you cant mount actual filesystems when using user namespacing
<clever> and they added a /proc flag to re-enable it
<clever> it will likely have the same problems on debian, where a custom kernel patch disables namespacing for non-root users
<clever> FRidh: i see mention of namespaces, the same stuff nix-user-chroot uses
<clever> link?
<clever> FRidh: yeah, that kind of stuff needs a chroot
<clever> FRidh: or the nix bootstrap tools
<clever> FRidh: perhaps they patchelf'd things to behave more like nixos's initrd?
<clever> FRidh: is any chroot or namespace magic going on?
<clever> simpson: https://github.com/cleverca22/gl/blob/master/core.c#L559-L568 i dont think this is the proper way to implent a driver in opengl :P
<clever> simpson: then i went to the userland side, with zero idea how mesa and opengl where "supposed" to work, and just implemented every function the opengl app was using, lol
<clever> simpson: i started with kernel code that delt with allocating chunks of memory, letting you mmap them into userland, letting you issue a render action, and waiting for an irq
<clever> simpson: ive had the fun of writing gpu drivers for the rpi before
<clever> thoughtpolice: nix-bundle is also fully nix based, i can just `nix-build -A something` and it spits out the arx bundle
<clever> main problem i have with nix-user-chroot is that debian made the silly choice to disable namespacing without root
<clever> and the chroot has a fully working nix, so nix profiles can be used
<clever> so its entirely transparent, and ceases to be nix-bundle once installed
<clever> and that installer copies a nix closure to ~/.daedalus/nix/store, and sets up scripts to run nix-user-chroot for you
<clever> my solution to the speed problem (and to support updating dynamically), is to use nix-bundle to package an "installer"
<clever> and next time you run it, it uses the partially unpacked directory, causing various problems
<clever> if arx fails to unpack a thing, it wont clear the cache
<clever> thoughtpolice: arx did recently add a cache thing, so it will reuse the previously unpacked stuff, but that introduces its own bugs
<clever> thoughtpolice: main issue with nix-bundle, that squashfs would solve (but that needs root-ish), is the long startup time
<clever> thoughtpolice: who needs a fancy optional daemon running on the host?? :D
<clever> nix-user-chroot then simply runs /bin/sh -c "xdg-open <url>", outside the sandbox, done!
<clever> a bash script inside the sandbox, called xdg-open, that simply echos "xdg-open <url>" into /escape-hatch
<clever> thoughtpolice: ive done something similar with nix-bundle, i called it the escape hatch
<clever> Lukas4452: what is the output from it?
<clever> Lukas4452: ls -l /run/{booted,current}-system ?
<clever> Lukas4452: the defaults for it may differ
<clever> Lukas4452: sounds related to the video drivers
<clever> DariusTheMede: what does gdb say the backtrace is?
<clever> lucus216: ah, can you screenshot where it hangs?
<clever> lucus216: there should be pre-made virtualbox images, with nixos already installed
<clever> the answers are already in the code you gave!
<clever> DariusTheMede: i think this would already solve that
<clever> DariusTheMede: but if you use callCabal2nix, it will re-make the entire drv, based on the cabal file, and ignore the previous version
<clever> DariusTheMede: so it is being set to a non-default value, on the version of nixpkgs your using
<clever> 122905 editedCabalFile = "01cxsjdxy5brdnw966928bcdivc8ab7kq91vdqkg2q801jf5jj9g";
<clever> 122904 revision = "1";
<clever> 122891 "inline-r" = callPackage
<clever> DariusTheMede: if i check nixpkgs rev 2a051165d53585630a602e831496f7157c519885 i can see:
<clever> DariusTheMede: you might also be able to use callHackage and callHackageDirect, depending on if the target is in hackage or not
<clever> DariusTheMede: the entire problem may even vanish if you just use callCabal2nix on everything
<clever> DariusTheMede: same for Naperian
<clever> DariusTheMede: move the entire codeblock on 14-24, down to line 44, and use the hspkgs from 43
<clever> DariusTheMede: doing it outside like that breaks the whole idea of overlays and composing overlays together
<clever> DariusTheMede: also, line 14 should really be refering to hspkgs.inline-r
<clever> DariusTheMede: what is line 3 refering to?, it may not be obeying the -I nixpkgs= at all
<clever> DariusTheMede: can you pastebin the shell.nix file?
<clever> DariusTheMede: do you have a shell.nix in the mix?
<clever> DariusTheMede: thats on version 0.10.1, which doesnt agree with the output you pasted above
<clever> DariusTheMede: *looks*
<clever> DariusTheMede: which rev of nixpkgs are you on?
<clever> DariusTheMede: check this to see what they do
<clever> DariusTheMede: the params revision and editedCabalFile should be set to null in your override
<clever> DariusTheMede: cabal revisions, one min
<clever> not sure, you would need to test each part in `nix repl` to see what is failing
<clever> > pkgs.pkgs.pkgs.pkgs.pkgs.hello
<clever> pkgs is an element in pkgs
<clever> no need to import nixpkgs 4 times
<clever> pingiun: what about just `pkgs = import <nixpkgs> {}; and lib = pkgs.lib; ?
<clever> pingiun: thats a strange error to be getting
<clever> 177 optional (stdenv ? cc && stdenv.cc.libc != null) stdenv.cc.libc ++
<clever> pingiun: `let pkgs = import <nixpkgs> {}; lib = pkgs.lib;`
<clever> clang.cc also has cmake files in its lib
<clever> there is also pkgs.clang.cc, which has some clang libraries, but no libclang.so
<clever> provides clang by default, and makes sure clang actually works
<clever> Athas: instead of stdenv.mkDerivation, use clangStdenv.mkDerivation
<clever> Athas: are you using clangStdenv.mkDerivation?

2019-08-04

<clever> yep
<clever> fendor_: and are any weird nix related env vars still set?
<clever> fendor_: did you bind mount to /nix or /nix/store ?
<clever> if you lack write access to /nix (or it doesnt exist), the script will use sudo to correct that, then do the rest without root (if doing a single-user install)
<clever> fendor_: the install.sh script just cares that you own /nix/, it doesnt care how its mounted
<clever> fendor_: `mount --bind /home/clever/nix /nix`
<clever> fendor_: just bind-mount something to /nix, that will be far better
<clever> fendor_: but that new build of nix, still lives in /nix/store/ on the host system
<clever> fendor_: this one uses the host nix, to build a nix binary, that acts on a non-standard location by default
<clever> fendor_: something else you could maybe play with
<clever> 2019-07-29 04:35:59<@clever_> nix-build -E 'with import <nixpkgs> {}; nix.override { storeDir = "/home/clever/.nix/store"; stateDir = "/home/clever/.nix/var"; confDir = "/home/clever/.nix/etc/"; }' -o ~/home-nix/
<clever> srid: i think i heard 80tb, but gchristensen probably knows the full number
<clever> srid: yep
<clever> srid: so if you pick a rev, and know it has cache coverage, you know it will forever have coverage into the future
<clever> srid: the cache is never garbage collected
<clever> fendor_: the ones you probably want are NIX_CONF_DIR, NIX_LOG_DIR, NIX_STORE, and NIX_STATE_DIR
<clever> fendor_: this does a dozen things at once, some of them you want
<clever> fendor_: and i dont think --store deals with making things work outside of /nix/store, it expects you to chroot into that "root"
<clever> fendor_: --store takes a path to the "root" directory, not the /nix/store subdir
<clever> srid: so it will randomly change versions without warning
<clever> srid: a branch will cause it to update every time you eval (if its been an hour since the update)
<clever> and use that to get the rev for a channel
<clever> ,howoldis
<clever> pkgs = import (builtins.fetchTarball "https://github.com/nixos/nixpkgs/archive/GITREV.tar.gz") {}
<clever> 2019-08-04 12:23:42 < clever> instead of using <nixpkgs>, just directly give it the path to a nixpkgs
<clever> srid: but that wont work on my machine
<clever> instead of using <nixpkgs>, just directly give it the path to a nixpkgs
<clever> srid: or tell your nix expr to use nixpkgs-unstable directly, and ignore what the host system has
<clever> srid: echo $NIX_PATH
<clever> srid: a nixos machine gets the nixpkgs from the nixos channel
<clever> fendor_: you may need to clear the ~/.cache/nix/tarballs dir
<clever> and a reboot is all you need to apply the systemd update
<clever> and init-interface-version is a safety, to stop it from breaking the entire system
<clever> but, for certain version changes, they arent compatible
<clever> from what ive seen, systemd usually can serialize its state to disk, and then pid 1 will re-execute the new systemd, which will deserialize and restore the state
<clever> chris__: the git rev is in the storepath, near the end
<clever> iqubic: yes
<clever> sphalerit: *doh*, it was in the pocket on the scope the whole time
<clever> evanjs: my system is setup to copy all of /etc/nixos to /run/current-system/nixcfg/
<clever> evanjs: not really
<clever> reminds me of xkcd, "standards"
<clever> heh
<clever> lol
<clever> ive got a cachecache, that can cache a binary cache, but it currently lacks the ability to query a local nix-daemon
<clever> or haskell
<clever> thoughtpolice: just rewrite it in c++ :P
<clever> which lets you act as an untrusted cache
<clever> so you can repeat upstream sigs, and proove that you didnt do anything nasty to the files
<clever> thoughtpolice: and `nix copy-sigs` can download the cache.nixos.org signatures, and save them locally
<clever> thoughtpolice: does eris support nix2.0 signatures in db.sqlite?
<clever> ivan: strace + curl to see what its doing when frozen
<clever> ivan: sounds like the client didnt read the reply?
<clever> ivan: id start with strace and curl, to see what its doing
<clever> ivan: set restart=always on the unit? find out why its crashing?
<clever> lambda-11235: are there any qt packages in nix-env ?
<clever> lambda-11235: you can find out what nixpkgs a generate was made from easily

2019-08-03

<clever> sphalerite: where did i leave my scope probes...
<clever> iqubic: first, you need to figure out if those options are controlled via a config file, or if they can be changed by a command after you login
<clever> kreisys: maybe :D
<clever> kreisys: but worktrees yeah
<clever> kreisys: `git archive` gives you a subset that you want
<clever> kreisys: cloning from the bare repo i think copies the entire .git dir, and then it deletes it
<clever> then deleting the .git folder
<clever> kreisys: its cloning/fetching to a bare repo, then clone again to a non-bare one
<clever> kreisys: the problem, is that `git archive` doesnt support submodules
<clever> kreisys: line 94, it init's a bare git repo, 131 it fetches things, 171 it generates an archive at a given rev
<clever> kreisys: thats fairly complicated, let me link it
<clever> kreisys: give it a try!
<clever> kreisys: the nix-prefetch-git script is bash
<clever> iqubic: should be
<clever> kreisys: you may need to patch hydra to turn it back off
<clever> iqubic: it expands it to $HOME
<clever> kreisys: the release.nix would have to fetch the submodules that ./submodules.json defines, then merge ./. with the submodules
<clever> (or directory)
<clever> iqubic: .source is usually a path to a file
<clever> kreisys: my idea, was to make a json file in the repo, that describes the submodules, and then use runCommand to merge things together, using multiple fetchFromGithub (deepfire/serge has implemented it)
<clever> kreisys: i think it mainly impacts the name
<clever> so something as simple as an unrelated branch getting pushed, can result in a different .git
<clever> the version of git, and the state of unrelated branches, will impact what git puts in .git
<clever> kreisys: and .git is often a source of impurities
<clever> kreisys: deep clone is the reverse of shallow clone, its to do with history, not submodules
<clever> kreisys: i believe only iohk's fork of hydra will fetch submodules
<clever> kreisys: ah, fetchgit uses a name based on the url, but fetchFromGitHub uses "source"
<clever> kreisys: on which version of nixpkgs?
<clever> kreisys: fetchgit or fetchGit?
<clever> kreisys: and then fetchFromGitHub and friends had to be changed to "source" to match hydra
<clever> kreisys: the problem is more that hydra doesnt know what the name should be, so it has to fetch it as "source"
<clever> kreisys: yeah, a bit of messy
<clever> kreisys: oops, ^^
<clever> hyper_ch: you want to set name="source"; on the nix function doing the fetch
<clever> kreisys: the name is part of what gets hashed
<clever> kreisys: are the names identical?
<clever> gchristensen: zfs!, zfs!
<clever> gchristensen: ^^
<clever> 2nd, /bin is empty!, youll want to export PATH=/nix/var/nix/profiles/system/sw/bin/
<clever> 1st, stage-1 will claim /bin/sh doesnt exist (its an absolute symlink, and its testing relative to the wrong root), tell it to continue anyways
<clever> nixos just has some extra requirements
<clever> the disk is already mounted to / when it runs "init"
<clever> no need to
<clever> then you have root, without systemd, and can do whatever you want
<clever> (this works in any linux distro, even nixos)
<clever> if you change the kernel cmdline in grub to `init=/bin/sh` you can force a single-user shell
<clever> and he had also GC'd older generations, because it was running fine for years
<clever> then after years of not rebooting, he rebooted, and it failed on bootup
<clever> he was doing network in his activation script, and hadnt rebooted in years, so it always worked
<clever> and thats the exact same problem the 1st guy with activation problems had
<clever> yeah, nixos-rebuild will re-run activation scripts, to apply changes
<clever> zaninime: cups isnt even running when activation scripts happen, so its more likely to fail 100% of the time
<clever> zaninime: what is the script doing?
<clever> zaninime: yeah
<clever> ever since i helped debug that first guy that lacked systemd, ive been saying, just use a systemd script
<clever> zaninime: so || exit 0 will make it worse
<clever> zaninime: i think nixos unstable also wraps every script for you, to prevent problems
<clever> you want || true
<clever> oh, yeah, that will do it, lol
<clever> zaninime: when the activation script fails, it bails out early, before putting systemd in PATH
<clever> zaninime: it will be at a path like this, check the system symlink to see what the latest is, then look backwards a bit
<clever> -r-xr-xr-x 1 root root 18346 Dec 31 1969 /nix/var/nix/profiles/system-500-link/activate
<clever> zaninime: and maybe read the finished activate script in the nix store
<clever> zaninime: youll need to add `set -x` before it, and see what exactly is failing
<clever> zaninime: are you still able to boot an older generation? or try removing it
<clever> zaninime: did you have any custom ones?
<clever> zaninime: activation scripts can cause that problem if they have an error
<clever> ahh
<clever> ToxicFrog: ahh, yeah
<clever> if its done with env vars, then a setup hook can probably also do it
<clever> probably
<clever> Miyu-chan: i think if you have perl int he buildInputs, and use #!/path/to/perl, the fixup phase will fix it for you
<clever> *looks*
<clever> pie_: there was a talk at the last nixcon about redoing the networking stuff in nixos
<clever> ldlework: since you pretty much never use unpackPhase when nix-shell'ing in, since the source is already at .
<clever> ldlework: your shell.nix may want to just set src = null;
<clever> ldlework: nix-shell -v, are you doing src = ./. with a large . ?
<clever> all the power!
<clever> it does light up, but i didnt have an SD card, so the boot obviously fails
<clever> also, just for fun, i took my wireless qi charging adapter (it puts out 5v on micro-usb) and plugged it into the pi :P
<clever> aha, my main phone charger is 1.55a
<clever> just a bare naked pi with only ethernet plugged in, lol
<clever> need to experiment with them more to find out which one is best
<clever> but the power supply has trouble even booting, and it randomly locks up mid way thru bootup
<clever> if i ever brick the rpi, i can do a nix-env rollback, at the router, and the rpi is un-bricked
<clever> and symlinks in the tftp config then boot that profile
<clever> this builds not-os, for netboot rpi, then updates the rpi3-netboot profile to point to the result
<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> thats also where i'm using nix-env in interesting ways
<clever> but the power supply has trouble booting now
<clever> and that was my arm build slave at one time
<clever> sphalerite: actually, i have netbooted the rpi to it, lol
<clever> sphalerite: wait wait, forgot, lol
<clever> sphalerite: correct, ive compiled it to arm before, but never actually ran it on arm (neither vm nor rpi)
<clever> joebobjoe: haskell-init has only been compiled/tested on x86, but arm shouldnt be that hard
<clever> joebobjoe: not-os has been compiled for ARM first, but only tested on x86
<clever> joebobjoe: rewrite every single util you ever plan to use, in haskell, and forkIO them, rather then createProcess!
<clever> joebobjoe: have a look at the haskell-init above, and say goodbye to posix compat, because you can now live in forkIO children! :P
<clever> rawtaz: its also small, but not single-binary small
<clever> rawtaz: the 2nd is more of an embeded os, that doesnt contain systemd
<clever> rawtaz: it was more of a toy, just to say i can do it :P
<clever> rawtaz: the 1st, is a single haskell binary, in the initrd, and thats it
<clever> rawtaz: ive made 2 more distros, using nix as a base, lol
<clever> petercommand: nix-shell -E 'with import <nixpkgs> {}; gcc9Stdenv.mkDerivation { name = "foo"; }'
<clever> petercommand: you want to use gcc9Stdenv
<clever> petercommand: one min
<clever> due to teamspeak being closed-source, CI cant test it, so nobody noticed when updaitng libquazip
<clever> for example, libquazip got updated recently, but it broke teamspeak
<clever> it instead just has the version set for every package, and it only updates if its confirmed to not break other open-source things
<clever> but it doesnt compute the right version based on constraints
<clever> /run/current-system/etc, /run/current-system/sw/bin, /run/current-system/sw/share
<clever> but its mainly rooted under /run/current-system/
<clever> joebobjoe: buildFHSEnv basically does that, thats how steam works on nixos
<clever> joebobjoe: which one gets to win the /bin/node path?
<clever> joebobjoe: there are 2 node binaries, one is nodejs, the other is a ham radio program
<clever> joebobjoe: combined, as in, they both have the same problems
<clever> joebobjoe: conflicting packages in /lib and /bin
<clever> the nix store just automatically prevents it from ever happening
<clever> joebobjoe: but the problem is finding those bugs, and fixing them, endlessly
<clever> joebobjoe: it could be solved by adding more --disable-x flags, to every single package in the system
<clever> joebobjoe: yeah
<clever> joebobjoe: on linux, /bin/sh can differ between builds
<clever> joebobjoe: it means darwin cant remap paths, only block access
<clever> joebobjoe: on darwin, the sandbox is implemented with ACL's, that cause error codes if you look at something you shouldnt