<clever>
srid: depends on exactly how they differ, can you paste a single line of the conflict?
<clever>
srid: you might have 2 copies of git in your systemPackages
<clever>
wpcarro: ive just been ignoring those
<clever>
wpcarro: yeah
<clever>
wpcarro: remove that, it will cause a large number of problems
<clever>
wpcarro: do you have busybox in your systemPackages?
<clever>
wpcarro: what is one of the things colliding?
<clever>
wpcarro: depends on what is colliding
<clever>
__monty__: but toxvpn only routes the IP's peers have, and it wont break the whole range
<clever>
__monty__: in the case of hamachi, it routed the entire 5.x.y.z to the vpn, and broke the whole IP block
<clever>
about 4 years ago, it ceased being reserved, random sites got IP's in that block, and they just never loaded for me
<clever>
so the IP's where technically public, but unused
<clever>
__monty__: the hamachi VPN was originally using the 5.x.y.z range, because that was under some special reserved (do not use) area on the internet
<clever>
yeah
<clever>
and you also have the entire 10.x.y.z space
<clever>
so its not likely to cause issues
<clever>
and usually, your only needing the router, which is generally x.y.z.1
<clever>
it will force .123.64 to use the VPN variant of that ip, and ignore whatever the cafe had there
<clever>
if you ever wind up in an internet cafe that is using 192.168.123, then the vpn will only cause problems when refering to 192.168.123.64, and the rest of the cafe machines will work as-normal
<clever>
.123 is high enough up there that it has a low chance of conflicting
<clever>
192.168.0 .1 and .2 are commonly used for home routers
<clever>
192.168.0.0/16, 10.0.0.0/8 and 172.16.0.0/12 are the 3 official "private" networks, that will never be used on the web
<clever>
thats a tricky part
<clever>
other then that, you can choose whatever you want
<clever>
and its best to be on a different subnet from any LAN you will be in
<clever>
it must not match the LAN ip
<clever>
yeah, you still need dyndns for that
<clever>
yeah, you can just ignore dyndns
<clever>
yeah
<clever>
thats just how ipv4 and NAT works
<clever>
srid: and that will allow traffic back into the thinkpad, on the router ip
<clever>
srid: when the thinkpad connects out on udp, the router dynamicaly sets up a reverse route for the udp replies
<clever>
it will use the intermediary nodes to discover the ip of the house, then connect directly to it
<clever>
srid: it will auto-discover the public ip of the other machine, and connect to it, even if you dont forward ports
<clever>
srid: it uses some bootstrap nodes to connect to a DHT, where it will then discover the other node's public ip, and then uses udp hole punching to form a connection
<clever>
srid: toxvpn would also be an option, then you have a fixed ip for both situations
<clever>
srid: if you try to connect to 22 of the public ip, from within the network, some routers (including nixos NAT) wont forward it back into the lan
<clever>
srid: ah, another thing to be aware of, port forwarding often doesnt work when your inside the same network
<clever>
srid: ah, my home IP is stable enough that i just port-forward once and just setup a fairly static dns
<clever>
srid: are the client and server on the same network?
<clever>
srid: nixos also allows 22 thru the firewall automatically
<clever>
srid: run tcpdump against the given interface, filtered to port 22, then try to ssh into it
<clever>
srid: dmesg and journalctl
<clever>
does it still fail with the new file in the above gist?
<clever>
this is my final expression, and it builds even faster when you enable parallism
<clever>
aleph-: definitely sounds like you need a systemd service
<clever>
you may need a nixos module, and a systemd service
<clever>
and note, that it will only have +w to $out, and wont have any access to DB's
<clever>
aleph-: then just run it after you chmod +x it
<clever>
aleph-: does it need to be executed at build-time or runtime?
<clever>
so it hides such mistakes when in a console
<clever>
bash also cheats, and will run itself on anything that looks like a shell script but technically isnt working
<clever>
aleph-: /bin/bash doesnt exist on nixos, you want #!${stdenv.shell}
<clever>
aleph-: src = ./.; is doing the exact same thing
<clever>
aleph-: if you do ${./db.sh}, then nix will dynamically copy those into /nix/store/ and insert the new storepath
<clever>
aleph-: also, you want to indent that entire heredoc, to match the nearby lines
<clever>
aleph-: the spaces around the = make it a command, not a variable assignment
<clever>
aleph-: the 2 args being '=' and the expansion of '$out/bin/install.sh'
<clever>
aleph-: you also dont have to set the system attribute, thats likely to cause issues down the road
<clever>
aleph-: you are running the command binary, with 2 args
<clever>
binary = $out/bin/install.sh
<clever>
aleph-: what if its "binary" that is not found?
<clever>
dev*
<clever>
hyper_ch: there is a def i know, that only ever uses `git add --all`, i have seen him commit lock files to the repo, luckily, the code uses flock and doesnt care
<clever>
holy crap
<clever>
1.2G /nix/var/log/nix/
<clever>
Unode: not planning on that
<clever>
dhess: i'm on my way to nixcon next week
<clever>
jtojnar: you could use gcc.cc, rather then gcc, as your compiler
<clever>
bpye: a lot like deploying nixops from a mac machine
<clever>
bpye: it will need build slaves of the right arch to perform those steps
<clever>
bpye: you just need to set the right nixpkgs.system.localSystem param for each machine
<clever>
bpye: yes
<clever>
jtojnar: i believe cc-wrapper sets some rpath flags when calling the real gcc
<clever>
that is the bare minimum grub needs to mount the real /boot
<clever>
hyper_ch: in your exact case, it would contain the grub kernel, the zfs drivers for grub, and maybe the luks drivers
<clever>
it has no fs, cant be mounted, cant be formatted, and just holds raw x86 assembly code
<clever>
so you now need a dedicated partition for that, called the bios boot partition
<clever>
and they decided to ban using "unused" space :P
<clever>
GPT uses more then 1 sector for its partition table, so that same range is now unsafe to use
<clever>
when booting on MBR, grub will shove stage 1.5 between sector 1 and partition 1, in the "unused" space
<clever>
hyper_ch: it serves the same purpose as the ESP
<clever>
hyper_ch: bios boot only needs <1mb
<clever>
hyper_ch: it can also be used as a bios boot partition for legacy booting
<clever>
ahh
<clever>
and that causes zfs to mess with performance controls of the entire sda
<clever>
also of note, if you let zfs paritition the disk like that, it sets a magic "whole disk" flag that cant normally be set
<clever>
i'm not entirely sure what zfs intends for that reserved partition, but if it works, it works, lol
<clever>
lol
<clever>
hyper_ch: and fdisk -l /dev/sda ?
<clever>
:O
<clever>
and the remote console only works under 7
<clever>
the remote cdrom part only works under xp
<clever>
yes
<clever>
dhess: it could be worse, ive had to install both windows xp and 7, just to get a mess of activex applets to work
<clever>
dhess: ah, that would imply that the entire machine is locking up upon kexec
<clever>
dhess: thats why ive got the autoreboot flag, so you can retry without needing any special console
<clever>
ah
<clever>
hyper_ch: then boot.initrd.availableKernelModules and it will auto-load if the card is still present
<clever>
hyper_ch: after booting with kexec, check `lspci -vvv` it will tell you which driver owns each device
<clever>
dhess: yep
<clever>
Unode: services.nixosManual.enable
<clever>
somebody that runs one has to tell you about its url and public key
<clever>
i dont think so
<clever>
its an opt-in thing
<clever>
drakonis1: you build your packages on something like travis, using normal nix-build, and then push it to cachix, and then you (and others) can use that as a binary cache
<clever>
emily: depends mostly on what hydra has and hasnt built
<clever>
if you switch to the nixos-unstable-small channel, you can get it early, at the cost of having to compile a few more things
<clever>
hydra is waiting for all of nixpkgs to build before updating nixos-unstable
<clever>
only nixos-unstable-small has 3.6.0
<clever>
and nixpkgs-unstable too
<clever>
drakonis1: the same is true for the latest commit of nixos-unstable!
<clever>
home-manager shouldnt have any impact on nix-build
<clever>
now what does `nix-build '<nixpkgs>' -A gzdoom` and `nix-instantiate --find-file nixpkgs` report?
<clever>
but --update wont run if you have zero channels to update
<clever>
i think the bug is that you need to --update to make it notice the removable of any channel
<clever>
that also works
<clever>
if you `rm /nix/var/nix/profiles/per-user/drakonis/channels*` then the problem will go away, as will any ability to do rollbacks for the non-root channels
<clever>
drakonis1: what does `ls -lh /home/drakonis/.nix-defexpr/channels` report?
<clever>
drakonis1: it sounds like you previously added a channel to your user, then deleted it, and nix-channel is glitching a bit and wont let you remove it
<clever>
at start,up, it will run /etc/runit/1, 3 is for shutdown, i think 2 was for when it finishes booting?, and then the run's under /etc/service/name/run are services it keeps running
<clever>
Ericson2314: this for examples defines some submodule options within fileSystems, then it just maps over a the result of running filter on all fileSystems
<clever>
Ericson2314: i think what you do is mapAttr or attrsOf over the entire config, outside of the submodule, when assigning other config (like systemd services)
<clever>
nkaretnikov: the .env attribute is rather basic
<clever>
catern: basic dns and /etc/hosts still work without nscd, you just loose advanced things like avahi
<clever>
you will want to do `lib.overrideDerivation drv.env (old: { buildInputs = old.buildInputs ++ [ portaudio ]; })` in the area between `then` and `else`
<clever>
nkaretnikov: the .env at the very end accesses the env for building haskell packages, which ignores most things you pass to mkDerivation
<clever>
nkaretnikov: yeah, that would help
<clever>
nkaretnikov: what else is in that file?
<clever>
and what are the contents of shell.nix?
<clever>
nkaretnikov: what nix-shell command are you running?
<clever>
nkaretnikov: every attribute on the derivation is automatically made into an env var
<clever>
an old a somebody else made
<clever>
> a
<clever>
> { a = 5; b = a; }
<clever>
> rec { a = 5; b = a; }
<clever>
nkaretnikov: you want rec there
<clever>
electrocat: the bigger question, is how many evals back you want to cache things, and how you garbage collect
<clever>
electrocat: ive heard that a single full build of nixpkgs is about 80gig
<clever>
if you do `nixops deploy --build-only` and have never created, then it will just not set things like publicIPv4, and they will default to null
<clever>
and then does a nix-build to build the machines
<clever>
then it creates all of those resources, and generates a nix file with the state
<clever>
python then parses that xml, to find the names and cloud-hosters of every vm, and what resources must exist
<clever>
it does a first nix-instantiate pass over things, with --to-xml
<clever>
behind the scenes, nixops generates an extra deployment file with that kind of state, and adds it to the nix eval
<clever>
arianvp: this will generate nixos config, based on python variables
<clever>
maxJobs is at the `nix-build -j5` layer, and will run up to 5 packages in parallel
<clever>
o1lo01ol1o: it will run `make -j72` inside each build, and it will depend on the deptree within a given package, and if the package even has enableParallelBuilding = true;
<clever>
if the vm hasnt been created, the param will be null
<clever>
when deploying, it will create the vm, query its state, then build the nixos with that ip as a param
<clever>
arianvp: nixops will get the IP from the vm system, before it builds the modules
<clever>
arianvp: yeah, i think it was networking.publicipv4 or something like that
<clever>
electrocat: only aarch64 has binary cache coverage
<clever>
nope
<clever>
Lisanna: declare what the output hash is and it will do that
<clever>
everything is stored in a single amazon S3 bucket, several terrabytes
<clever>
the old version was removed from nixpkgs, so you will need to either choose an older version of nixpkgs, or use an override
<clever>
the problem might be that -i is picking the wrong package, but its also very likely that hydra is not pre-building 32bit as well
<clever>
which version does it start building?
<clever>
try nix-env -iA nixpkgs.pandoc
<clever>
fiatjaf: how exactly did the build fail?
<clever>
fiatjaf: yeah, you can just run nix-env -i on that path if you want to
<clever>
fiatjaf: it looks like it was removed from the release.nix, so hydra isnt building it anymore
<clever>
This job is not a member of the latest evaluation of its jobset. This means it was removed or had an evaluation error.
<clever>
oldandwise: oh yeah, every contributor will have his own fork, where he makes some changes, and then files a PR
<clever>
oldandwise: no need to fork nixpkgs, if you properly use the nix expressions (rather then using the nix-env cmd fiatjaf gave), it will detect what arch its being ran on, and build for that arch (or download a prebuilt one)
<clever>
oldandwise: so it will just blindly download the exact build you gave it (a 64bit build) which will then fail to start
<clever>
oldandwise: the hash in that path is a hash over the build instructions, which includes the arch
<clever>
oldandwise: yep, downloading things from the cache
<clever>
without flags, it will only collect the unused things
<clever>
fiatjaf: you can regain some of the space it doesnt really need by running nix-collect-garbage
<clever>
fiatjaf: then youll want to use the above gist to create a mostly matching profile, that is 32bit (it will default to the same arch as the host nix-env was compiled for)
<clever>
creating the derivation itself from nix is a bit more tricky
<clever>
you could also use nix-copy-closure to copy the current profile to another machine, and then run `nix-env --set -i /nix/store/thatpath` to overwrite your current profile with the copy
<clever>
tbenst: ls -lh ~/.config/nixpkgs/overlays/tb.nix
<clever>
tbenst: what is the exact command you ran?
<clever>
tbenst: does the error give a line number?
<clever>
yeah, we could update it
<clever>
the faq also lacks a script that saves you from having to remember the magic incantation of `nix-env -iA userPackages -f '<nixpkgs>'`
<clever>
colemickens: the faq is using buildEnv to merge things into a single package, and then `nix-env -q` only shows "user-packages"
<clever>
colemickens: in the case of that gist, you are telling nix-env to install an attrset, so it will just install every attr of the set, and all will appear in `nix-env -q`