2017-04-24

<clever> i learned these kinds of things by installing linux-from-scratch
<clever> simp__: i have plans to make an installer gui, to prevent such mistakes in the future
<clever> dcz: this forces libfoo to always use the source in my home dir, so i can just edit it, re-run nix-shell, and it rebuilds libfoo
<clever> dcz: buildInputs = [ (libfoo.overrideDerivation (old: { src = /home/clever/libfoo; })) ];
<clever> dcz: you can also point things to a local source directory
<clever> avn: so just putting it into the $PATH roots it
<clever> avn: nix will scan /proc/*/env and a few others, and wont gc anything that can be in-use
<clever> so you could have one terminal with gcc4, and another with gcc5
<clever> and you could use a conflicting version of something in a different terminal by running nix-shell on a different default.nix
<clever> and since its only changing env variables, it wont persist after you exit the shell
<clever> dcz: things with a bin/ folder go into $PATH, and everything goes into the gcc search path
<clever> dcz: when you open a nix-shell, it will always put everything in /nix/store/, and it will modify some env variables so tools can find it
<clever> grub works on both
<clever> systemd-boot only works on gpt
<clever> simp__: yeah, boot.loader.grub.enable = true; and the one i gave before
<clever> dcz: how does this look? https://pastebin.com/vA3ryPMN
<clever> correct
<clever> and /boot can be mounted if you want to keep using it
<clever> re-run nixos-generate-config --root /mnt ; nixos-install
<clever> boot.loader.grub.device = "/dev/sda";
<clever> mbr doesnt need it and you can just continue with the previous directions
<clever> the bios_grub thing is a special work-around for how gpt works
<clever> this can be made to boot without efi
<clever> then youll want to make sure the usb boots via efi, and redo the disk with a gpt table
<clever> simp__: since its MBR, it doesnt need a bios_grub, so you can either continue, or start over with GPT
<clever> EFI needs a GPT style partition table
<clever> simp__: aha, thought so, this is an MBR style partition table, it will never work with efi
<clever> Disklabel type: dos
<clever> it can just go into a pastebin
<clever> simp__: what does "fdisk -l /dev/sda" say ?
<clever> dcz: and he used a custom builder script, so all overrides are imposible
<clever> dcz: yeah, this cimg is a mess, the plugins are in the doc folder!
<clever> nix-env -iA nixos.xfce.xfce4-screenshooter
<clever> simp__: i mainly use xfce4-screenshooter
<clever> simp__: what happens when you hit the printscreen key?
<clever> simp__: can you screenshot the page your looking at?
<clever> simp__: it should be called bios_grub
<clever> i had to disable efi entirely to make it stop
<clever> simp__: i did also have issues where the bios 100% ignored the boot order i set, and always booted the efi windows
<clever> simp__: simpler/faster to just unplug that hdd
<clever> dcz: yeah, this cimg package is a bit of a mess
<clever> simp__: i feel efi is optional, and i have never gotten it to work on any machine
<clever> dcz: ah, i see why i cant override cimg, the author didnt make the package very well
<clever> simp__: oh, and set boot.loader.grub.device = "/dev/sda"; (using the path for the hdd)
<clever> simp__: after you change the type, mount root to /mnt, /boot is no longer required, re-run nixos-generate-config --root /mnt ; nixos-install
<clever> simp__: it would be a bit of a waste of space, but you can change /boot into a bios boot partition (the bios_grub flag in gparted), and then switch to non-efi booting
<clever> simp__: what filesystem did you use for / and how big is /boot?
<clever> you also need to boot via efi to even see the efi config
<clever> ah
<clever> simp__: can you pastebin the output of "mount" ?
<clever> simp__: and you ran that as root?
<clever> simp__: efi is weird like that
<clever> simp__: you need to boot the usb via efi if you want to be able to install an efi os
<clever> id say its a bug with the cimg package then, one min
<clever> ah
<clever> i think you also need to use #include <cimg/CImg.h>
<clever> you must put a package with those headers into the buildInputs
<clever> dcz: the gcc in nix is modified to never look in /usr/include/
<clever> simp__: and then pastebin the output of running "efibootmgr"
<clever> simp__: can you boot from the usb again?
<clever> simp__: let me double-check this end
<clever> dcz: that will modify the stdenv to just use gcc5 by default
<clever> dcz: i think it needs to be done like this: https://gist.github.com/cleverca22/ff925d59fc4da36ee87fd1a43e9ddf48
<clever> simp__: yeah, i think its that simple
<clever> dcz: with a default.nix file?
<clever> dcz: are you using -p or -A?
<clever> simp__: i think this is the right flag: http://www.multibooters.com/articles/images/Screenshot-GParted.png
<clever> yeah
<clever> simp__: it should be possible to just change the type in gparted, and it will boot without anything else
<clever> simp__: i believe it must have the efi system partition type on it
<clever> dcz: you wrote import lessthan nixpkgs(undefined variable) greaterthan {}
<clever> dcz: <nixpkgs> i believe
<clever> simp__: ah, is the /boot fat32, and with the type code efi system partition?
<clever> simp__: what happened?
<clever> jophish: yeah, via db.sqlite
<clever> yeah
<clever> the whole reason for that, is so that it wont accidentaly use the system gcc, but the one you specified
<clever> it can only use the things you list in the nix expression
<clever> because nix is designed to never use libraries you have "installed"
<clever> so you can probably just let stdenv5 = stdenv.override { cc = gcc5; }; in stdenv5.mkDerivation
<clever> dcz_: this will give you a stdenv that uses gcc 5.4 by default
<clever> nix-repl> stdenv.override { cc = gcc5; }
<clever> gcc 5.4 is in nixpkgs, one min
<clever> dcz_: which gcc do you want to use?
<clever> simp__: mkdir first
<clever> thats a easy way to just list the current fw config
<clever> c0c0n3: and keep in mind there are 2 firewalls, try iptables-save both inside and outside the container
<clever> simp__: cant think of one
<clever> c0c0n3: ah yeah, and the container has its own firewall, you would have to allow port 80
<clever> c0c0n3: when i made a declarative container via configuration.nix, i had to set it up like this: https://gist.github.com/cleverca22/deaf56e929355841310e9509fa3ddedd#file-mc1-nix-L4-L19
<clever> simp__: that controls the video modes
<clever> simp__: ah
<clever> simp__: did you use dd or some other tool?
<clever> simp__: did you burn the iso to a cd or usb stick?
<clever> and you can use a proper browser to look things up
<clever> graphical is usualy better, gparted is just so much simpler then cli
<clever> more easily accessed if your on the non-graphical iso
<clever> there is also a nixos manual and a rogue game on alt+f8 and alt+f9
<clever> :D
<clever> simp__: spammers defacing everything
<clever> simp__: about 2 years, and i dont see myself ever using another distro
<clever> i have nixos on my laptop, desktop, router, nas, 2 netbooks, and 2 servers

2017-04-23

<clever> yep :)
<clever> its almost a dynamic dns layer running over ipfs
<clever> so if i have your pubkey, i can find your ip, at any time
<clever> you have a persistant keypair, and the (public key, public ip) is advertised on the dht
<clever> and there are some minor privacy issues in how ipfs handles its p2p stuff as well
<clever> ryantrinkle: so if somebody finds an exploit in /nix/store/foo, they can just ask IPFS, "who can give me a copy of foo?", and now they have a list of target IP's
<clever> ryantrinkle: a second issue though, is that you are broadcasting to the world that you have a given storepath in your hdd
<clever> ryantrinkle: so only cache.nixos.org-1 can be shared
<clever> ryantrinkle: yeah, you could also have a whitelist for keypairs you can share
<clever> hodapp: but things in foo's propagatedBuildInputs will propagate into bar's inputs
<clever> ryantrinkle: but if the signatures are kept, you could just configure it to never share unsigned things, so the locally built stuff remains private
<clever> for one, you would be able to download a complete copy of my nixos build, including its configs, just because i "leaked" the above path
<clever> lrwxrwxrwx 1 root root 92 Apr 21 00:21 /run/current-system -> /nix/store/5biaa9fmvi3dfyibwaba8i6xf5z4h7y0-nixos-system-amd-nixos-17.09pre105622.f0fac3b578
<clever> there are also some security issues i have heard about, if you start sharing the entire /nix/store over IPFS
<clever> or just go nuts and throw in a hardware signing token
<clever> and if your local builds where signed with a given pair, and you securely destroyed the secret, you can proove those are also unmodified
<clever> and massively cut down on what you need to audit
<clever> you could proove that 98% of the storepaths are unmodified originals from cache.nixos.org
<clever> and it would make nix-store --verify --check-contents crypographicaly secure
<clever> so even if an attacker gets root, and can mess with db.sqlite, he cant repair signatures on a year-old storepath
<clever> and if you throw in some keypair rotation, and put a timestamp into the signature, you could proove what month something was signed during
<clever> this also opens up the option of signing local builds when the build finishes, rather then when somebody asks for it
<clever> ryantrinkle: without that, non-primary hydras have to re-sign everything they share, even if it was originaly signed by the main hydra
<clever> ryantrinkle: oh, another thing ive been thinking of adding to nix, have it save the binary cache signatures to /nix/var/nix/db/db.sqlite
<clever> bennofs: and at that point, fusenar can index the file, and cache that
<clever> bennofs: and nix itself would need to be patched, so when you tell nix to substitute a .nar from the cache, it will save it to a dir and IPC fusenar, rather then unpacking
<clever> bennofs: i think if i was to improve it now, i would have it index the .nar when you register it into the framework, and cache that in a db
<clever> bennofs: haskell just turns half of the parsing job into a thunk, and can resume the parsing later
<clever> bennofs: yep, but the type of the root node (file, or directory) required parsing the nar, and making a lazy parser in c++ had a higher difficulty then just redoing it all in haskell
<clever> bennofs: i think it kept them as <hash>-<name>.nar i believe
<clever> ryantrinkle: nope
<clever> bennofs: 2, both have clever in the name, taktoa was just helping more with that project
<clever> ryantrinkle: i still think perf could be improved more by keeping a database with the results of parsing things
<clever> ryantrinkle: so, i rewrote the whole thing in haskell: https://github.com/taktoa/narfuse
<clever> ryantrinkle: and just doing "ls /nix/store" led to it having to fully parse every nar in the entire store
<clever> ryantrinkle: i had originaly written it in c++, but ran into performance issues because it had to parse the entire NAR (potentialy several gig) just to figure out if it was a file or a directory
<clever> MichaelRaskin: and maybe systemd wasnt coded to handle errors when the carpet gets pulled out from under its feet
<clever> MichaelRaskin: i think systemd glitched because the fuse app segfaulted, and the fs still existed
<clever> and thats the host pid1, that was supposed to be spawning a container
<clever> ryantrinkle: you are then unable to shutdown or reboot
<clever> ryantrinkle: i also quickly discovered, that if the fuse program crashes in a weird way, pid 1 will get stuck at 100% cpu and go unresponsive
<clever> just dont unpack the nar's!
<clever> ryantrinkle: why not use fuse to mount a pile of .nar files at /nix/store?
<clever> ryantrinkle: the idea with that project, is that ipfs needs a copy of the objects its sharing, and if you want to share your nix store over ipfs, you wind up with a copy in /nix/store, and a .nar file of equal size
<clever> ryantrinkle: this is how i was doing it for random tests: https://github.com/cleverca22/fusenar/blob/master/container.nix
<clever> ryantrinkle: when i was experimenting with containers to test some fuse stuff, i had to run systemd-nspawn as root, but i was able to just put the rootfs anywhere
<clever> usually better to just block the auto-update, and just update nixpkgs often
<clever> (though steam has special stuff to handle it)
<clever> in that case, the new version will fail to run
<clever> though some things like steam and dropbox try to save the updates to a dir under $HOME
<clever> GLn: the directory its installed to is read-only, so it will usualy fail to update
<clever> like it forced a fetchurl derivation to be cross-compiled with the arm curl
<clever> sounds more like a bug in the cross-compile framework now?
<clever> though network should be disabled everywhere but a few well-maintained derivations
<clever> bbl
<clever> m3tti: you just need to enter a known-wrong hash
<clever> m3tti: nix-build will tell you the correct hash when the hash fails
<clever> m3tti: it will basicaly nix-store --dump the $out path, and hash that
<clever> m3tti: nix needs the hash of the NAR (nix archive), not the hash of the .tar.bz2
<clever> 54% when visible, 40% when on another tab, no effect from minimizing
<clever> explains how it was using more then fullscreen video was
<clever> joepie91: that process is now at 0%
<clever> joepie91: ahh, it was an album full of animated things
<clever> oh, one of those imgur's is animated
<clever> joepie91: i cut that process down to 1 reddit thread and 2 imgur tabs, and its still using 44%
<clever> jophish: probably
<clever> steveeJ: yeah, but a lot of tabs that should be idle are listed as using cpu
<clever> nor twitter
<clever> its not the wiki
<clever> bennofs: most of those are sites that have extremely low background usage
<clever> a process with just a wiki, imgur, reddit, twitter, and youtube, is using more cpu then fullscreen video playback
<clever> Infinisil: another process, for totally idle tabs, is using a constant 42%!
<clever> Infinisil: the process in the chrome taskmanager for a video-ing tab is using between 23 and 36% cpu while doing fullscreen playback
<clever> Infinisil_: and there are 2 of you now
<clever> Infinisil_: aha, the installer lets you play rogue on F9, and the manual on F8
<clever> and a game on another
<clever> i think the install cd also has a manual on f8
<clever> i think i already fixed him yesterday, but a channel update may help
<clever> and f7 is the gui
<clever> all of them have login prompts
<clever> you can also use alt+f1 thru alt+f6
<clever> yay!
<clever> infinisil: you should be able to ctrl+alt+f1 and get a text console still
<clever> ++
<clever> the perl was just translated directly to c
<clever> nix-channel is still executing nix-env as a sub-process, exactly like it did before
<clever> bennofs: ah, its still doing the same as before: https://github.com/NixOS/nix/blob/master/src/nix-channel/nix-channel.cc#L134
<clever> a few months ago, the perl was purged
<clever> nix-env, nix-store, and nix-instantiate where all c++
<clever> and nix-build was a perl script that ran nix-store and nix-instantiate
<clever> Infinisil: nix-channel was a perl script that ran nix-build and nix-env
<clever> Infinisil: some of the utils where in perl
<clever> havent read this since the de-perl-ification of nix
<clever> every month or 2, i commit changes on every box, and merge them together
<clever> i try to avoid spamming git with commits
<clever> i have a snapshot of the known-good config in current-system
<clever> so if i ever need to rollback from grub, and cant remember what i changed to break things
<clever> bennofs: this puts a snapshot of all of my nixos config files into every build
<clever> ive also done something related, let me gist it
<clever> or that
<clever> and it will do a one-time fetch
<clever> and you could then use a url in -I when doing nixos-rebuild
<clever> it will never update, even if you rollback nixos from grub
<clever> i do see that being of use though
<clever> but the nixpkgs inside current-system is read-only, so you need to force things with -I to make any upgrades
<clever> but it can be confusing, so i always use <nixpkgs/nixos>
<clever> and <nixos/nixos> will refer to the nixos inside nixpkgs
<clever> yeah
<clever> bennofs: https://github.com/NixOS/nix/blob/master/corepkgs/unpack-channel.nix is involved in channel setup
<clever> while <nixpkgs>/pkgs/top-level/default.nix wont confirm the existance of the file, and may fail
<clever> but <nixpkgs/pkgs/top-level/default.nix> will only return a nixpkgs that contains that exact file
<clever> <nixpkgs> will return the first nixpkgs it can find, which might even be an empty directory
<clever> another thing about nix-path that i havent seen documented well
<clever> ah, that could work out well
<clever> lrwxrwxrwx 1 root root 1 Dec 31 1969 /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs -> .
<clever> thats a symlink to .
<clever> another old bit of legacy stuff, the nixpkgs at the end of "nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs"
<clever> other tools expect the channel to be called nixos on nixos machines
<clever> yeah, it already starts with nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs
<clever> thats close to what i would want also, but then <nixpkgs> wont work
<clever> root could also potentialy add a channel called nixos-config, and delete /etc/nixos/configuration.nix
<clever> but nothing can load from the users channels!
<clever> so <nixos> will load the nixpkgs of root's channel, by the name of nixos
<clever> and anything else that fails, will be looked in roots channels
<clever> <nixpkgs> will try the 'nixos' channel on root first, <nixos-config> will try /etc/nixos/configuration.nix first
<clever> ah, i see a minor bug as well
<clever> nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs:nixos-config=/etc/nixos/configuration.nix:/nix/var/nix/profiles/per-user/root/channels
<clever> each dir is managed identicaly by nix-channel
<clever> this is what nixos has
<clever> lrwxrwxrwx 1 clever users 44 Oct 11 2015 channels_root -> /nix/var/nix/profiles/per-user/root/channels
<clever> lrwxrwxrwx 1 clever users 46 Mar 7 2016 channels -> /nix/var/nix/profiles/per-user/clever/channels
<clever> but on non-nixos, there is no root setup
<clever> .nix-defexpr normaly contains both channels and channels_root
<clever> i dont even have a .profile on my gentoo
<clever> weird, even my gentoo box has that
<clever> nixpkgs=/home/clever/.nix-defexpr/channels/nixpkgs:nixpkgs=/home/clever/.nix-defexpr/channels/nixpkgs
<clever> and you have 3 identical entries?
<clever> yeah, its a bit more messy on other distros
<clever> ah
<clever> this entry is in NIX_PATH by default, and there is one dir per channel, named after the channel
<clever> /nix/var/nix/profiles/per-user/root/channels
<clever> we already have that
<clever> i would need to do a channel rollback
<clever> and while i can rollback the changes in the profile, i cant recreate things easily against an older nixpkgs
<clever> bennofs: what if i want to make 1 minor tweak to a package, and then nixpkgs decides i need to re-download all of the stdenv
<clever> bennofs: i'm more against just putting a url in $NIX_PATH, that can lead to things upgrading without warning
<clever> then you dont need to keep fliping between the 2 forms
<clever> nix-build -E 'with import <nixpkgs>{}; callPackage ./foo.nix {}'
<clever> though it would help massively if nix-build foo.nix would do it more like this by default
<clever> joepie91: learning how import, callPackage, and function definitions work, would explain that issue
<clever> joepie91: and how they where not compatible
<clever> joepie91: when i was new to nix, i was often confused by packages needing either { stdenv, dep1, dep2, dep3 }: or with import <nixpkgs> {};
<clever> and there is also the differences between pure nix, and nixpkgs
<clever> sphalerite: the ONLY time a virus has ever gotten into a linux machine i run, is when i ran an outdated copy of exim, with a known exploit right in the irc channel topic, lol
<clever> ToxicFrog: and the narinfo has the url to the .nar.xz (which may not be xz)
<clever> ToxicFrog: given /nix/store/hash-name-version/, the narinfo is at https://cache.nixos.org/hash.narinfo
<clever> yumbox: and yeah, the man page is confusing, it seems to start over repeatedly, the layout is not what i'm used to
<clever> nix-store {--realise | -r} paths... [--dry-run]
<clever> yumbox: its in the man page
<clever> so you can just run nix-build to patch any game
<clever> something that i think would be usefull for many, is to make a nix expression that takes a gog blob, and patches it
<clever> so you need to use #!/bin/sh, or patch everything
<clever> and on nixos, /bin/sh and /usr/bin/env are the only things in FHS locations
<clever> yeah
<clever> back when my primry system was a P2
<clever> many years ago it was
<clever> drp: ive done the same, i used #!/bin/bash for ages, then one day i discovered ubuntu replaced bash with dash because its "faster"
<clever> yeah
<clever> i think its more that startmojo isnt compatible with nixos, a common issue
<clever> are you able to link a copy of a smaller gog game using the same system?
<clever> startmojo.sh may need to be patched after the unpacking
<clever> and that line 55 makes more sense for the error you previously gave
<clever> so if --noexec was removed, it would have unpacked, and ran that
<clever> can you pastebin that one?
<clever> does it contain a startmojo.sh?
<clever> do you see the main elf for the game in there?
<clever> drp: it may also help to use --target <dir>
<clever> drp: i think the problem might be the ELF it unpacks, what happens if you just run it with --noexec --keep, and dont try to patch anything?
<clever> and 518
<clever> but have /bin/rm on line 467
<clever> strange, they use rm in most of the file
<clever> drp: can you pastebin the result of running head on the installer?
<clever> so it runs without an FHS env
<clever> it may also be possible to run the gog installer and point it to $out, then patchelf the products
<clever> which makes it imposible to patchelf things properly
<clever> because the anti-piracy stuff in a lot of games will un-patch them, and the auto-update also unpatches them
<clever> steam runs under a chroot that emulates the full FHS env
<clever> then it may work without patching