<clever>
joepie91: but all of that is inside the same JS engine, and can share values across the border safely
<clever>
joepie91: and the JS in a webpage is properly sandboxed
<clever>
joepie91: firefox has had that for ages, the JS managing extensions and the browser itself can just violate the cross-origin policy and read any file on your system
<clever>
i list deps that are in nixpkgs, and wrote the code to fit whatever version was already in nixpkgs
<clever>
then you can easily update it with a new gist later, or gist it up for others
<clever>
like macbook.nix, and then do imports = [ ./macbook.nix ];
<clever>
yegortimoshenko: it may also help to make a new file, just to keep things well laid out
<clever>
Enzime: all profiles exist within that, which includes stuff from nix-env, nix-channel, and nixos-rebuild
<clever>
because apple refuses to do "data recovery"
<clever>
Enzime: so the poor user had to take it to a 3rd party repair store, to have the drive removed, apple center to replace the motherboard, then back to the 3rd party store to put the hdd back in
<clever>
Enzime: ive also heard stories of the apple service center refusing to move the hdd when doing a "repair" (swap the entire motherboard), even though the hdd was confirmed working
<clever>
which leads to linux having better driver support then darwin
<clever>
yegortimoshenko: those i2c datalines also happen to be easily damaged by corrosion from water, and OSX will refuse to respond to the touchpad when its forced into usb only mode
<clever>
yegortimoshenko: and the OSX kernel lacks the usb drivers (or actively ignores the usb device)
<clever>
yegortimoshenko: when in the firmware/bios, it runs over usb, but once the OS boots, it switches to i2c
<clever>
yegortimoshenko: ive also heard, that the touchpad in the macbook has 2 entirely different interfaces, it can work over both usb and i2c
<clever>
so something else must have differed
<clever>
and you can see that in these 3 generations, i didnt update my nixcfg
<clever>
Enzime: now nixos is snapshoting its own config at every rebuild
<clever>
Enzime: it will appear in places like /run/current-system/nixcfg/
<clever>
Enzime: if you do this in configuration.nix, then every time you do nixos-rebuild, a copy of /etc/nixos/ gets embeded into the nixos build
<clever>
Enzime: but there is a trick you can add to help, system.extraSystemBuilderCmds = "ln -sv ${./.} $out/nixcfg";
<clever>
Enzime: not directly, thats part of why i keep zfs snapshots of everything
<clever>
yegortimoshenko: but, there is a problem with the above, any time nixos-rebuild updates things, it breaks that chain, and you have to go thru special recovery steps to update the TPM
<clever>
yegortimoshenko: then linux can access the key to decrypt / and it just works
<clever>
yegortimoshenko: as an example, the bios will report the hash(grub), before executing grub, then grub has to report the hash(linux) + hash(initrd) + hash(kernel cmdline), before running linux
<clever>
yegortimoshenko: and only if those hashes get replayed to the TPM in the same order, will it unlock the key in the TPM
<clever>
yegortimoshenko: a TPM in tracing mode is the only way to stop that, the bios, and every step of the boot process, must report the hash of the next binary its executing, before that binary gains control
<clever>
kaydee: and the url may be a different instance of curl, double-check "ps aux | grep curl"
<clever>
kaydee: the curl output from 4 different curls can be interleaved, ive seen the counter glitch between a number counting up from 4, and another counting up from 15 before
<clever>
kaydee: -j makes the output almost entirely unreadable
<clever>
kaydee: if its building things in parallel, it may hang on something else, and the url from something that ran quickly will be the last thing displayed
<clever>
yegortimoshenko: the attacker can just move up another step
<clever>
yegortimoshenko: and even if you encrypt /boot, there is a plaintext grub stage 1.5, that must be plaintext for the bios to load it
<clever>
grantwu: yeah, TPM and traced boot is the only way to stop this
<clever>
since /boot is in plaintext
<clever>
yegortimoshenko: but in either case (luks or crypted zfs), the attacker can just trojan your kernel or initrd, to do the same thing with the drive pass
<clever>
yegortimoshenko: nix has some protections against this (nix-store --verify --check-contents), which would detect any tampered files, but an attacker that is aware of nix can just update db.sqlite to account for that
<clever>
yegortimoshenko: and then return the laptop to where they found it
<clever>
yegortimoshenko: in theory, an attacker could just mount your rootfs, and trojan your gpg binary, so it reports the passphrase to a remote server when you unlock the key
<clever>
yegortimoshenko: so a single luks encrypts both
<clever>
yegortimoshenko: for my current laptop, i put swap and zfs into lvm, then i put the lvm into luks
<clever>
and it gets all of the deps via attributes in haskellPackages
<clever>
et4te: cabal2nix just generates a single derivation, that will be loaded via haskellPackages.callPackage ./. {};
<clever>
et4te: cabal2nix does that for you, as long as everything is in hackage
<clever>
et4te: what about just using cabal2nix directly on your project, and ignoring the stack.yaml ?
<clever>
it only has 3gig of ram, and just opening something like an appveyor log in the browser hangs it for 5 mins
<clever>
that should tell you how old it is, lol
<clever>
core2duo processor
<clever>
an old dell d650
<clever>
one is an in-progress kernel build that hung due to a make bug
<clever>
yegortimoshenko: heh, 4gig of my / is just in /tmp!
<clever>
yegortimoshenko: my laptop with a half-dead battery claims 40 minutes when i unplug it
<clever>
yegortimoshenko: on my main desktop, amd/root is only using 8gig
<clever>
yegortimoshenko: ah, yeah, if you have /etc/nixos on its own set, that can work
<clever>
yegortimoshenko: yeah, i have heard that apple has put a crap-ton of power optimization into things, and linux just kills the battery life
<clever>
kaydee: mkfs.vfat
<clever>
yegortimoshenko: my NAS was made before i started doing that, and now with constant churn in /nix from hydra, the snapshots keep a crap-ton of data
<clever>
yegortimoshenko: one thing ive been doing on all of my zfs installs, is a dedicated dataset for /nix/
<clever>
et4te: can you gist the exact error?
<clever>
yegortimoshenko: i believe apple added HFS+ to their firmware, so they could use a fs better then fat
<clever>
yegortimoshenko: its also heavily firmware based, different motherboards may implement different filesystem drivers, fat32/vfat is the only required one
<clever>
so you can use either fat32 or HFS+ for /boot, and EFI
<clever>
but also, macbooks support more then just fat32, they also allow HFS+ for /boot
<clever>
macbooks dont have a legacy boot option
<clever>
ahh
<clever>
why?
<clever>
then you dont need a dedicated /boot partition
<clever>
kaydee: and then set boot.loader.grub.device = "/dev/sda"; (the root of the drive containing that bios boot partition)
<clever>
kaydee: if you want legacy booting on GPT, you need to create a bios boot partition, 1mb in size, no fs, not mounted anywhere
<clever>
kaydee: if you dont want that, you need to boot via legacy, which means turning off the EFI options in configuration.nix
<clever>
kaydee: booting with EFI requires an ef00 partition that is fat32
<clever>
rodarmor: for finished programs, thats a good place to put them, but for development stuff, i try to keep it in a shell.nix, that i can load with nix-shell
<clever>
kaydee: you need to create a boot partition of type ef00, format it to fat32, and mount it to /mnt/boot/
<clever>
simpson: in an odd way, android does a lot of similar things, the entire OS is based around --prefix=/system/
<clever>
kaydee: what kind of problem are you having?
<clever>
rodarmor: you would build your program to reference a given python via an absolute path, so it just always works
<clever>
rodarmor: in general, you shouldnt have things like python installed system wide, ever
<clever>
try adding extra-libraries: gcc_s to your own cabal file
<clever>
ah
<clever>
et4te: *looks*
<clever>
et4te: what if you just manualy replace the entire bits-extras in the generated file, with the one from hackage-packages.nix in nixpkgs?
<clever>
et4te: i'm leaning towards it being a bug in stack2nix, because hackage2nix doesnt have the same problem
<clever>
normally, you cant reference other attributes defined at the same level
<clever>
so i could reference the toxvpn on line 11, by just saying toxvpn
<clever>
that allows you to reference attributes inside that set, within the set
<clever>
everything you nix-env -i goes into there
<clever>
.nix-profile is a symlink to the profile nix-env manages
<clever>
so when i want to install something new, i add it to the list, and nix-env -iA nixos.mystuff
<clever>
its all manual
<clever>
Enzime: that lets me declaratively manage what packages i keep installed
<clever>
i could make nixos myself
<clever>
in theory, if i can just run a command and spawn a given init process, with a given root dir
<clever>
same
<clever>
Enzime: how much do you know about WSL?, is it possible to spawn a new "container" with the root targeted at any given location?
<clever>
then i can have a nix managed build of something windowsy
<clever>
and give nix-build access to running .exe files on the host windows
<clever>
i have also been wondering about using WSL like wine, to run the linux nix-build, on windows
<clever>
what category did nixpkgs put it into!!
<clever>
what does wine stand for!! lol
<clever>
pkgs/misc/emulators/wine
<clever>
then wine-preloader will need to be patched
<clever>
ah
<clever>
slabity: thats just how wrapProgram works on nixos, we would need to confirm if wine is trying to dlopen wine64 directly, or if its just executing wine64 as a normal app
<clever>
pie_: looks normal at a glance, what error does it fail with?
<clever>
slabity: you may need to look into the wine docs or ask #winehq
<clever>
not sure, i didnt look into it that much, and i was only interested in testing 64bit cross-compiled things, not gaming on both arches at once
<clever>
slabity: i suspect that might be a 64bit only wine
<clever>
Enzime: i use them as a "plan to watch" list
<clever>
heh, was going to snap a photo of the phone+netbook tethered together
<clever>
gchristensen: sure
<clever>
i have internet
<clever>
gchristensen: and dhcp just went to town on it, lol
<clever>
gchristensen: upon flipping the switch, enp0s29f7u2 just magically appeared in "ip link"
<clever>
gchristensen: step 1, the phone wont even let me turn on usb tethering until i plug in a usb cable!
<clever>
gchristensen: let me grab my netbook and see...
<clever>
gchristensen: i havent tried usb tethering yet, just used the wifi tethering
<clever>
and then be able to fire slaves more jobs, as they finish things
<clever>
but once it gets a few slaves going, it will keep downloading things
<clever>
so it might wind up downloading things from a cache with 1 thread, and ignoring build slaves for 20 minutes
<clever>
catern: and only once that entire process is done, will it look back at the queue, and potentially start another build or step
<clever>
catern: in a single thread, it will load a given build, compute the dep graph and what is missing, optionally check the binary cache and download pre-built stuff, and then initiate a build of a step on a slave
<clever>
catern: the queue runner is single threaded, but will do things sorta in parallel
<clever>
gchristensen: and if you nix-collect-garbage -d, it ceases to boot!
<clever>
gchristensen: then grub.conf always points to an old generation, and all changes undo at every reboot
<clever>
gchristensen: another common issue ive seen, is where somebody forgot to define /boot in the nixos config, so nixos just never mounts /boot on startup
<clever>
the closest thing is that you can bump something to the top of the queue
<clever>
but also, the 'build product' links on hydra are now all broken
<clever>
so hydra never has io load, and never runs out of space
<clever>
and then streams the results from the slave (via ssh) to aws S3
<clever>
it streams the build inputs directly from cache.nixos.org to the slave (via ssh)
<clever>
catern: and in the case of hydra.nixos.org, the builds NEVER land in /nix/store
<clever>
and only hydra can accept a list of machines, and poll them for changes
<clever>
you can have a secondary /etc/nix/machines.ec2, that is auto-populated by ec2 machines you spin up&down constantly
<clever>
one reason, is because it accepts a list of config files
<clever>
catern: when the build is done, hydra will connect to nix-daemon over a unix socket, and import the build
<clever>
catern: hydra is also capable of accepting a list of those config files, in the variable
<clever>
catern: hydra will ignore the build hook entirely, and initiate its own ssh connections to the machines listed in /etc/nix/machines
<clever>
catern: but nix-daemon and hydra dont share usage stats of the slaves, so that will still double-up workload
<clever>
catern: i have also noticed, that if make a hydra machine a build slave, it can relay the build to one of its own slaves
<clever>
Enzime: this jobset is configured to checkout the latest version of toxvpn master, and the nixos-unstable-small branch of nixpkgs, and then build everything in release.nix from toxvpn
<clever>
Enzime: and nix-env -iA nixos.packagename
<clever>
Enzime: yeah, but you could also do it in ~/.config/nixpkgs/config.nix, then its just { packageOverrides = pkgs: { packagename = pkgs.callPackage ./packagename {}; }; }
<clever>
then you can do environment.systemPackages = [ pkgs.packagename ];
<clever>
Enzime: where packagename is a directory in the same dir as the file containing this string
<clever>
Infinisil: and if i somehow wind up with 2 identical installs from the same image, they will conflict
<clever>
Infinisil: then i have to change files in nixcfg (which is git managed) when the uuid of /boot changes
<clever>
gchristensen: ive also recently started breaking it up even further, i now have nas-hydra.nix, and mydomain.nix, which i can throw into imports to setup a certain hydra, but its self-contained enough that i could recreate that hydra faster elsewhere
<clever>
then configuration.nix only has the bare-minimal stuff to boot and get network, and imports = [ ./nixcfg/laptop.nix ];
<clever>
and each class does imports of another, even more generic class, until it all meets up at core.nix
<clever>
those leaves then list machine specific info, and imports a more generic class, like desktop or headless
<clever>
my general design, is a tree, where each leaf is a hostname, nixcfg/amd-nixos.nix, nixcfg/laptop.nix, nixcfg/nas.nix
<clever>
gchristensen: sure
<clever>
and now that i look, that makes no sense at all, lol, its just a mkDerivation that copies files
<clever>
and snmp
<clever>
cacti.nix causes mariadb to get loaded
<clever>
you can also infer a lot of the contents of those files, via what gets loaded after them
<clever>
gchristensen: ctrl+f the above gist for nixcfg, and youll see how i organized my systems
<clever>
Infinisil: but how was that derivation created?, i would want to reference a nix value that contains a recipe for creating it
<clever>
Infinisil: this is more about the config inputs, rather then the built outputs
<clever>
so not even config.nix can be safe
<clever>
factorio handles its download by putting a name&pw directly into the packageOverride
<clever>
and they can handle censorship
<clever>
gchristensen: the -v output, like 'nix-instantiate '<nixpkgs/nixos>' -A system -v' would at least list what files may be usefull, then you can ask the user to gist them
<clever>
gchristensen: it would also be great to gist things like config.nix and configuration.nix, BUT, those can have passwords in them, and with imports, large chunks can also be missing
<clever>
this helps confirm, which config.nix its obeying
<clever>
but its gone un-noticed, because it silently skips when missing
<clever>
gchristensen: and it has a far higher priority then the normal config.nix locations
<clever>
gchristensen: it turns out, that env variable points to that path, and has done so for years
<clever>
i think another user had manualy set NIXPKGS_CONFIG and then forgot he did it
<clever>
having a script that is aware of catches like that, and can gist the output of 'nix-instantiate -v '<nixpkgs>' -A hello' would help track down which config.nix its using
<clever>
gchristensen: and this lead to nix-env 100% ignoring config.nix
<clever>
gchristensen: and one weird thing that caught me off guard a week ago, somebody had created a /etc/nix/nixpkgs-config.nix file, without telling me (they also forgot they had even made it)
<clever>
gchristensen: and running the script would just automaticaly spit out a pastebin link with a crap-ton of details
<clever>
gchristensen: i cant find an example right now, but the ubuntu boot diag thing would read the MBR, confirm if grub is there, then read the stage 1.5 offset (a few bytes in the MBR), confirm that stage1.5 is stll there, and go down the entire chain the hardware follows while booting
<clever>
gchristensen: have you seen the boot diag script from ubuntu or the alsa diag scripts?
<clever>
joepie91: i think thats also part of the argument of either keeping the libs as an external .so (so end-user can update), or providing source when you staticly link (so user can rebuild and update)
<clever>
bennofs: yep, python36Packages.deluge.name evals but python36Packages.deluge.drvPath borks
<clever>
bennofs: ahh
<clever>
Drakonis[m]: everybody must install nix, nix is great, all hail nix, lol
<clever>
bennofs: then how did grantwu get the name "python3.6-deluge-1.3.13" out of nix-env -qa if it doesnt install? hmmmm
<clever>
bennofs: hmmm, but shouldnt nix-env -qa have hidden things that fail to eval?
<clever>
grantwu: -i also causes other problems
<clever>
grantwu: nix-env -i is almost always slower, its better to use attribute paths with -iA
<clever>
grantwu: the error says pygtk doesnt work on python 3.6, so you need to try a different python
<clever>
thats the default when installing nix on another distro
<clever>
the -small channels will only wait for testing, the non-small channels wait for everything to build
<clever>
nixpkgs- channels have darwin builds, but dont wait for nixos tests, so it may bork grub
<clever>
grantwu: and the nixos channels wont have darwin builds of things
<clever>
grantwu: the nixos channels wait for extra testing before they update
<clever>
gchristensen: and it would also auto-backup all data back to that central server
<clever>
gchristensen: so when nixops deploys the machine, its a fresh install, with a gui capable of restoring user-data into it
<clever>
gchristensen: when i was porting one of my things to nixos, i had considered making it connect into the backup framework, and having a gui to restore db snapshots
<clever>
bennofs: so you should never have to touch the ld.so path ever
<clever>
bennofs: normall, your supposed to just run gcc, and the gcc wrapper will handle everything for you
<clever>
maybe a bash if statement, if $NIX_CC is set, use it, then fall back to /lib/ld.so
<clever>
ah
<clever>
that variable is only set during a build that has gcc in the buildInputs
<clever>
ah, then you can probably use cat $NIX_CC/nix-support/dynamic-linker
<clever>
bennofs: what other platforms are you thinking of?
2017-07-29
<clever>
Infinisil: heh, that should work
<clever>
the nixos that nixos-install was being ran from
<clever>
the problem in my case, was with the install host, not the newly formatted fs
<clever>
dhess: i ran into an issue with the netboot stuff for x86 a few months ago, if the host /nix/store was read-only, nixos-install could fail
<clever>
Infinisil: so it will always have cache misses
<clever>
Infinisil: yeah, nixos-rebuild will always try to find the ENTIRE closure of your nixos on the cache, including the built version of stuff you customized
<clever>
the run that started the daemon, (stop it, then rebuild)
<clever>
can you gist the output of nixos-rebuild switch?
<clever>
so you want to fix the config, and run it once more, to fix the entire machine
<clever>
which can resume nix-daemon, AFTER the rebuild has finished
<clever>
when the rebuild finishes, it will restart any systemd units that need restarting
<clever>
did you clear the env variables after getting a root shell, and before you ran nix-build?
<clever>
Infinisil: yeah, this time it used the env of nix-build to setup the fetching
<clever>
as root, after confirming nix-daemon is dead?
<clever>
there is still a nix-daemon running, "sudo systemctl stop nix-daemon" and then re-run the nixos-rebuild
<clever>
now it knows that its reading stdin, and it wont try to seek
<clever>
ps -eH x | gist -p -
<clever>
so you need to tell it that its a pipe
<clever>
gist also wants to seek
<clever>
while the nixos-rebuild is hanging
<clever>
Infinisil: can you gist the output of "ps -eH x" ?
<clever>
yeah, i almost never use -d
<clever>
ah
<clever>
Infinisil: and why can you not do a rollback?
<clever>
which just turns off cache use entirely
<clever>
Infinisil: there is also nixos-rebuild switch --option binary-caches ""
<clever>
dang
<clever>
PR time then
<clever>
catern: setgid on a dir means the gid of things made in the dir will inherit differently
<clever>
the irc client may also ignore the proxy env variables
<clever>
only after you disconnect the irc client, and restart it in a new terminal, will it obey the proxy config