2020-01-15

<clever> :D
<clever> dminuoso_: ive been using minicom for years
<clever> Twey: the service may need to be updated to add those options
<clever> Twey: though it only has 2 options
<clever> dminuoso_: if its standard x86 hardware, then the wiki i linked before should be correct
<clever> Twey: `man configuration.nix`
<clever> dminuoso_: it could simply be ttyS1 thats going to the plug
<clever> dminuoso_: and try to just `echo anything > /dev/ttyS0` and see if it comes out
<clever> dminuoso_: ah yeah, cat /proc/cmdline
<clever> dminuoso_: legacy reasons, the serial driver just assumes you have 4 serial ports, often you may actually have them on the motherboard
<clever> dminuoso_: another thing you can try, just give console= 4 times
<clever> dminuoso_: slightly diff, not entirely sure how diff
<clever> dminuoso_: oh, weird, yeah, S0 is on a different driver from the others...
<clever> dminuoso_: plug&play, part of the hw auto-detection stuff
<clever> dminuoso_: looks like you want earlycon=uart8250,io,0x3f8,115200 ?
<clever> dminuoso_: linux starts at 0, dos/windows start at 1
<clever> dminuoso_: i think earlycon=uart8250,io,<addr>,115200 might work, once you lookup the IO port for COM1
<clever> dminuoso_: and i find similar docs near the 8250 driver
<clever> 622 * Only attempts to match console command lines of the form:
<clever> 624 * console=uart[8250],0x<addr>[,<options>]
<clever> 623 * console=uart[8250],io|mmio|mmio16|mmio32,<addr>[,<options>]
<clever> dminuoso_: and that is done via the struct console .match function...
<clever> dminuoso_: for arm devices, you can do this, and it would force the kernel to assume a pl011 device is at the given addr
<clever> drivers/tty/serial/amba-pl011.c: * "earlycon=pl011,<address>" on the kernel command line.
<clever> dminuoso_: one min
<clever> dminuoso_: yep, serial8250 is the driver, same as on a plain old desktop
<clever> dminuoso_: `ls -l /sys/class/tty/ttyS?` ?
<clever> dminuoso_: that would explain it then
<clever> dminuoso_: is it x86 or arm??
<clever> dminuoso_: sounds like classic x86 serial drivers, just assuming all 4 are present
<clever> dminuoso_: possibly, whats the serial port named under /dev/ ?
<clever> dminuoso_: and then try to enable early-printk for it in linux
<clever> dminuoso_: id say start by figuring out what uart you are using for the boot menu
<clever> and even an IR port
<clever> dminuoso_: it has hdmi, usb host, usb device, a bloody microphone right on the pcb, wifi, sata, lipo battery charging
<clever> dminuoso_: the banana pi also looks like somebody couldnt decide where to stop with features
<clever> dminuoso_: there is a spot on the bottom of the pcb for an eeprom, that stores the switch defaults, but the eeprom is missing, and the datasheets are nowhere to be found
<clever> dminuoso_: only after linux boots, can linux tell it, "stop that, your supposed to be a firewall!!"
<clever> dminuoso_: the critical problem with the banana pi, is that the "dumb" switch defaults to bridging every port, so your LAN and WAN are linked on bootup
<clever> dminuoso_: this is just a "dumb" switch ic, with the management interface wired to an allwinner a20 chip, along with 1 of the ethernet ports
<clever> Twey: yep
<clever> dminuoso_: basically, the switch IC out of most "dumb" switches, is capable of doing managed-switch tasks, but the cpu to drive the entire UI is missing
<clever> dminuoso_: sounds a lot like the banana pi series of boards
<clever> Twey: nixos generates a setuid wrapper, renames it to dumpcap in this case, and that wrapper then runs the real dumpcap, after gaining root
<clever> Twey: that allows wireshark's gui to run without root, but still capture packets
<clever> Twey: this configures dumpcap to be setuid root, and only executable by members of the wireshark group
<clever> Twey: you can use security.wrappers to make setuid things setuid-ish
<clever> Twey: ahh, yeah, thats where things get tricky
<clever> Twey: and you cant pre-create a tap device with configuration.nix?
<clever> dminuoso_: i also run nixos on my "router", but its just a server-grade motherboard with ecc ram and 2 gigabit NIC's
<clever> Twey: so qemu-bridge-helper is out of the picture, and nixos manages the interface for you
<clever> Twey: and this tells qemu to use tap0, and to not have any up/down scripts
<clever> Twey: https://github.com/NixOS/nixos-org-configurations/blob/master/macs/host/networking.nix#L27-L46 this creates a tap0 device, which is currently configured to NAT, but you could just as easily add it to a nixos managed br0, along side eth0
<clever> dminuoso_: ahh
<clever> dminuoso_: which switch is this? heh, a networking switch or a nintendo switch?
<clever> Twey: i do also have an example with bridging i can link, one min
<clever> Twey: `-net user` is the simplest network to setup, if you just want basic tcp/udp stuff
<clever> dminuoso_: the kernel config file, when you build the kernel
<clever> dminuoso_: i think with the right kernel config, earlyprintk causes the kernel to just blindly write bytes to a magic address, extremely early in the boot process, before drivers are even online
<clever> dminuoso_: this, plus configuring the earlycon in .config, so the kernel knows where to send it
<clever> 123 echo print-fatal-signals=1 console=ttyAMA0,115200 earlyprintk loglevel=7 root=/dev/mmcblk0p2 printk.devkmsg=on > cmdline.txt
<clever> dminuoso_: ive had similar problems with linux on the rpi, with custom firmware, early-con helps a lot
<clever> Ankhers: if you want to use clang to compile things
<clever> Ankhers: you want clangStdenv.mkDerivation

2020-01-14

<clever> medard: there are also pre-made virtualbox images, with nixos installed already
<clever> nDuff: maybe something else failed while booting, check the journal?
<clever> nDuff: nixos should create that, on bootup
<clever> Jarva[m]: updating the firmware could change hte order of devices
<clever> Jarva[m]: it might be a firmware problem with the motherboard, re-allocating bus's
<clever> ,locate
<clever> Jarva[m]: pciutils, and it would help to have an lspci from both wlp1s0 and wlp2s0
<clever> ,locate bin/lspci
<clever> so the 3, means its on pci bus #3, and the 0 means its device zero on that bus, 03:00
<clever> for me, wlp3s0 is 03:00.0 Network controller: Intel Corporation Wireless 8265 / 8275 (rev 78)
<clever> Jarva[m]: what does lspci say about that card?
<clever> das_j: that not really feasible, because the hash depends on which compiler you used
<clever> dalto5: for example, it took ~2 days to add a new cpu arch to nixpkgs, and then i was able to pull together 3 different cross-compilers (vc4, arm-embeded, arm-linux) trivially, and start building stuff for the rpi
<clever> dalto5: one of my most recent projects, is making heavy use of the cross-compile stuff in nixpkgs
<clever> the difference is just which tests they check for
<clever> dalto5: both nixos-unstable and nixpkgs-unstable point to whatever version of master has most recently passed a certain set of tests
<clever> dalto5: for the next 3 weeks, every nixpkgs-unstable user came out of the wood-work, asking why the machine stopped booting :P
<clever> dalto5: few years ago, grub began corrupting the grub config file, and nixos-unstable correctly stopped updating
<clever> dalto5: nixos-unstable goes thru extra testing, to make sure it wont brick a nixos machine

2020-01-13

<clever> samueldr: ive spent days before trying to figure out what to google to find it :P
<clever> sondr3: hydra-in-a-box has some examples
<clever> kalbasit: https://github.com/NixOS/nixops/issues/1189 could make it simpler, to make a much thinner ami, and then nixos-install afterwards
<clever> kalbasit: ive not heard of one yet
<clever> copy-only will build everything, and copy to every machine in parallel, but not activate anything
<clever> kalbasit: nixops deploy --build-only or --copy-only are options
<clever> kalbasit: https://github.com/cleverca22/nixos-configs/blob/master/deployments/raspberry_pi.nix is an example which does the same thing but for armv7l
<clever> kalbasit: set nixpkgs.system in the machine config
<clever> Rovanion: when ran as root, nix-env operates on roots profile, which is normally in $PATH for every user
<clever> jakobrs: by default, it will basically diff `ls` before and after unpacking, and guess where it should cd, based on what unpacking made
<clever> jakobrs: sourceRoot must be set to the name of what you should cd into
<clever> so i would prefer to just use a patch
<clever> __monty__: sed can silently do nothing, if the source changes
<clever> __monty__: builtins.replaceStrings can only work on strings that exist at the nix level, so it wont handle files within the source
<clever> __monty__: and i prefer .patch files, because those will fail if the thing your patching cant be found
<clever> __monty__: only the 1st is patching the source, the rest are wrapping the compiled binary to set vars at runtime
<clever> spelled it out too much, heh
<clever> ,runtimedeps __monty__
<clever> rajivr___: i tend to just stick them where it makes the most sense, programs.vim.fat is a custom option that controls if vim depends on clang at runtime
<clever> ,2
<clever> ,1
<clever> ,
<clever> ,runtimeDependencies __monty__

2020-01-12

<clever> evanjs: thats all of the arguments that nixpkgs can accept, as an example
<clever> > builtins.functionArgs (import <nixpkgs>)
<clever> nixnewbie: `nix-store -q --tree` shows build-time deps, if ran on a .drv file
<clever> stteevveen: nixos-option, a command-line util
<clever> that will download nixpkgs automatically
<clever> nixnewbie: nix-instantiate channel:nixos-unstable -A hello
<clever> nixnewbie: nix-instantiate and `nix show-derivation`
<clever> nixnewbie: you may need this, if your on nixos, though thats a bit overkill
<clever> 98 repeat = 2
<clever> 92 nix = {
<clever> 93 extraOptions = ''
<clever> nixnewbie: every input to the builtins.derivation function (stdenv.mkDerivation is a wrapper around it)
<clever> nixnewbie: `nix-build --repeat 1` will cause it to do every build twice, and fail if they didnt produce bit-identical results
<clever> nixnewbie: `nix-build --check` can be used to force a rebuild
<clever> nixnewbie: the only reason that wouldnt hold up, is if your using a random number generator at compile time
<clever> nixnewbie: nix will automatically rebuild anything if the inputs have changed, forcing a rebuild should produce the identical results
<clever> nixnewbie: why do you want to force a rebuild?
<clever> but the nixos test stuff doesnt respect that var currently
<clever> and the default buildPhase will pass that on, as `make -j`
<clever> --cores will set an env var at build time
<clever> viric: when stage-1 prompts, it saves the pw to a file on a tmpfs, and tries it on every device
<clever> viric: if you have 2 devices with the same passphrase, stage-1 will reuse it without asking a 2nd time
<clever> not sure it supports multiple stage2 luks devices
<clever> viric: just define each device manually in here
<clever> { name = "root"; device = "/dev/nvme0n1p2"; prLVM = true; }
<clever> boot.initrd.luks.devices = [
<clever> dont know
<clever> that both installs vim, and sets up all of the aliases and env vars
<clever> cap_sens1: nope, but you can use aliases to rig that up, one min
<clever> cap_sens1: what if you do `name = "vi";` instead?
<clever> aftet you install vim_configurable.customize
<clever> cap_sens1: i mean, if you `which vim` in a shell
<clever> cap_sens1: what about vim?
<clever> cap_sens1: try just `name = "vim";` ?
<clever> cap_sens1: try without a name?
<clever> cap_sens1: did you set a name inside customize?
<clever> jluttine: yeah, nixos sets the "log file" to null, and lets systemd log stdout/stderr fully
<clever> jluttine: journalctl -f -u display-manager

2020-01-11

<clever> ambro718: wpa_gui can control wpa_supplicant i believe
<clever> ambro718: i know how to use wpa_supplicant
<clever> ambro718: dont know, i just avoid network manager
<clever> networking.interfaces.wlp3s0.macAddress
<clever> ambro718: there is a nixos option for that
<clever> if you dont, then you risk nix garbage-collecting the ld.so on you
<clever> the_pumpkin_man[: its always simpler if you write a nix package for it, and then use nix-build to patch it
<clever> $ cat $NIX_CC/nix-support/dynamic-linker
<clever> /nix/store/aag9d1y4wcddzzrpfmfp9lcmc7skd7jk-glibc-2.27/lib/ld-linux-x86-64.so.2
<clever> $ nix-shell -p
<clever> Shouou: because it has to traverse all of the imports, to figure out what nixpkgs.config is set to, to figure out the value of pkgs
<clever> Shouou: imports can never depend on pkgs
<clever> mananamenos: ~/.ssh/authorized_keys still works
<clever> mananamenos: nixops uses nix-copy-closure behind the scenes, so it should work just fine
<clever> Thra11: you can probably just set TMP yourself in the shell.nix
<clever> Thra11: i believe its in the source of nix-shell, to set TMP and TMPDIR
<clever> stteevveen: dont put .override in there, thats breaking it
<clever> > virtualbox
<clever> mananamenos: if you deploy with nix-copy-closure, it should be perfectly fine
<clever> stteevveen: virtualisation.virtualbox.host.package = n1903.virtualbox;
<clever> mananamenos: you have to change whatever defined nixpkgs, which should be a few lines up
<clever> > ./. + "/foo/" + "/.." + "/" + "/" + "/"
<clever> > ./. + "/foo/" + "/.."
<clever> > ./. + "/foo/"
<clever> jtojnar: each time you append a string to a path, nix will remove redundant elements like a training / and ..
<clever> lovesegfault: `nix-build https://cachix.org/api/v1/install -A cachix && ./result/bin/cachix`
<clever> ,cache Guest84

2020-01-10

<clever> :D
<clever> kalbasit: lower numbers are prefered, the official cache is 40, and a hydra is 100
<clever> lol
<clever> grw: more that github may be the latest source, and your not running the latest, of both modules
<clever> grw: check against the actual version of the source your using
<clever> grw: videodev and v4l2_common may not be compatible with eachother, youll want to compare their sources and see if they disagree on v4l2_ctrl_query_fill
<clever> grw: next, you want to check the source for both v4l2_common and videodev, do they actually both export v4l2_ctrl_query_fill? perhaps the module isnt compatible with that kernel version?
<clever> grw: the problem, is that nixos itself, is using .extend to adjust the .kernel attribute some, which undoes whatever // did
<clever> grw: for example, linuxPackages_4_19 = super.linuxPackages_4_19.extend (kself: ksuper: { ... });
<clever> grw: .extend takes an overlay
<clever> grw: you must use the proper override function
<clever> grw: // on kernelPackages breaks
<clever> grw: which thing are you overriding?
<clever> and current-system?
<clever> grw: ls -l /run/{current,booted}-system/kernel
<clever> grw: and what does `uname -a` report?
<clever> grw: your mixing the 4.19 modules, with a not 4.19 kernel
<clever> grw: you must use config.boot.kernelPackages.tbs
<clever> grw: thats your problem
<clever> grw: can you paste your extraModulePackages line?
<clever> jackdk: the .bashrc stuff checks if you have any channels, when deciding if your channels should be in NIX_PATH
<clever> jackdk: you need to relog the first time you add a channel to non-root
<clever> thats only needed if the thing your importing returns a function
<clever> lovesegfault: lists with functions in them can do that
<clever> lovesegfault: check my vim.nix for a basic 1 option example
<clever> and nixos will merge things for you, and put the result into config.custom.confg
<clever> and then custom.config = mkMerge [ a b c ]
<clever> define some custom nixos options
<clever> then nixos encounters an object with an _type of "merge", it will merge them, but only within nixos options
<clever> > :p lib.mkMerge [ { a.a = [ 1 ]; } { a.a = 2; } ]
<clever> it takes a list
<clever> lovesegfault: mkMerge returns a specialy tagged object, which will only merge when assigned to a nixos option
<clever> lovesegfault: if you want it to properly merge with nixos option rules, you want to use lib.mkMerge instead
<clever> > :p lib.recursiveUpdate { a.a = [ 1 ]; } { a.a = 2; }
<clever> lovesegfault: but, that one just overwrites upon collision
<clever> > :p lib.recursiveUpdate { a.b = 1; } { a.c = 2; }
<clever> lovesegfault: lib.recursiveUpdate
<clever> lovesegfault: and its not recursive, so the entire a= got overwritten
<clever> > :p { a.b = 1; } // { a.c = 2; }
<clever> > { a.b = 1; } // { a.c = 2; }
<clever> > { a=1; b=42; } // { b="not 42"; }
<clever> > { a=1; } // { b=2; }
<clever> lovesegfault: //
<clever> my hydra is building that
<clever> also, check the release.nix in the same dir
<clever> and then just put secrets.nix into .gitignore so you cant screw up
<clever> yep, thats the one
<clever> that lets CI test things
<clever> the part omited from the paste, is default values, to make it built (but not really secure)
<clever> lovesegfault: you could just check if the file exists intead
<clever> $ cat ~/apps/nixos-configs/load-secrets.nix
<clever> if builtins.pathExists ./secrets.nix then import ./secrets.nix else {

2020-01-09

<clever> submodules dont work on builtins.fetchGit
<clever> tpham: only pkgs.fetchgit has a fetchSubmodules = true;
<clever> thomashoneyman: same
<clever> thomashoneyman: ssl and acme wont work without being publicly reachable for example
<clever> thomashoneyman: this is also reusing the hydra config that actually gets deployed with nixops, and it just has a few mkForce entries, to tweak it
<clever> thomashoneyman: basically, nix-build test-hydra-locally.nix && ./result, then browse http://localhost:8080/
<clever> thomashoneyman: have you seen my test-hydra-locally.nix?
<clever> thomashoneyman: bumping ram should also work, if you find the swap doesnt perform enough and are willing to up the machine size
<clever> inferencerules: one option is to do `pkgs2 = import <nixpkgs> {};` and then use `pkgs2.fetchFromGitHub
<clever> inferencerules: imports can never depend on pkgs
<clever> DigitalKiwi: recursive nix would let you make something that behaves like distcc+ccache
<clever> DigitalKiwi: distcc would violate the purity of the build sandbox
<clever> DigitalKiwi: if you callPackage with stdenv = gcc8Stdenv; then stdenv within that file, refers to gcc8Stdenv
<clever> via .override or just a 2nd callPackage
<clever> DigitalKiwi: looks like its mostly a style change, having it in all-packages.nix would make it simpler to build it on another version without having to edit the default.nix
<clever> DigitalKiwi: but those are more in terms of user error, rather then an os installer trying to wipe everything on its own
<clever> as long as you dont delete the wrong partition or mkfs the wrong device
<clever> smolck: should be completely safe
<clever> smolck: you will want to mount the root to /mnt before you mount home to /mnt/home
<clever> smolck: yep
<clever> smolck: probably better to use a 2nd /boot for nixos, efi allows multiple boot partitions
<clever> smolck: nixos has both systemd-boot and grub, and the install process will update the efi vars to point to whichever you enabled
<clever> smolck: yep
<clever> smolck: so when the directions tell you to partition the disk up and format everything, just mount your existing home to /mnt/home instead
<clever> smolck: nixos doesnt automate partitioning or formatting
<clever> thomashoneyman: swapDevices = [ { device = "/var/lib/swap2"; size = 1024; } ];
<clever> thomashoneyman: ah, the size was in mb, not gig, lol
<clever> mb*
<clever> thomashoneyman: `free -m`, how many mg of swap?
<clever> thomashoneyman: you can also just run `history` in your shell
<clever> yep
<clever> thomashoneyman: under the machine config, swapDevices is a sibling of services
<clever> thomashoneyman: docs should confirm the numbers/names
<clever> thomashoneyman: swapDevices = [ { device = "/var/lib/swap"; size = 10; } ]; i think, will auto-create a swap file
<clever> thomashoneyman: swap may help short-term
<clever> thomashoneyman: and how much ram does the machine have?
<clever> thomashoneyman: what is the nixos config for the hydra?
<clever> port:3000 ???
<clever> thomashoneyman: journalctl -f -u hydra-server
<clever> and check again
<clever> thomashoneyman: systemctl restart hydra-server
<clever> thomashoneyman: `netstat -anp | grep starman` ?
<clever> thomashoneyman: systemctl status hydra-server
<clever> thomashoneyman: nothing obvious, but we can still check the hydra port, netstat -anp | grep 3000
<clever> thomashoneyman: what about access.log in the same dir as error.log?
<clever> my cmd searched for 442, not 443 :P
<clever> thomashoneyman: probably just a typo then, oh, yeah, duh
<clever> thomashoneyman: `netstat -anp | grep nginx` ?
<clever> try just ssh'ing into it normally, and run in the shell
<clever> thomashoneyman: that would result in singlequotes inside singlequotes, which breaks it
<clever> thomashoneyman: the server ip is on line 1&3 of the paste
<clever> thomashoneyman: is that the netstat output from the server?
<clever> thomashoneyman: i dont see nginx listening on 443
<clever> thomashoneyman: `netstat -anp | grep LIST | egrep '80|442'` ?
<clever> thomashoneyman: [root@amd-nixos:~]# tail /var/spool/nginx/logs/error.log
<clever> thomashoneyman: what does error.log say on the server?
<clever> yeah, slap an https:// onto it
<clever> thomashoneyman: gist
<clever> thomashoneyman: if you run `curl -v hydra.mydomain.com`, what does it output?
<clever> thomashoneyman: what url are you trying to load?
<clever> thomashoneyman: connection refused means nothing is listening on that port, and the firewall already let you in
<clever> thomashoneyman: if its connection refused, its not the firewall or the virtualhosts
<clever> syzygyzer: one option is to use nixpkgs.overlays to create a pkgs.unstable

2020-01-08

<clever> veleiro: hardware.opengl.enable = true; handles most of it
<clever> kapil_: qtcreator has some trouble on nixos, qt is a lot more manageable in a shell
<clever> kapil_: what args did you start nix-shell with?
<clever> kapil_: are you using nix-shell?
<clever> kapil_: what is the network interface name from `ifconfig` ?
<clever> kapil_: that was an a/b question, not a yes/no question