2018-11-03

<clever> nschoe: import or imports? and what path is it importing?
<clever> thats done in config.txt with one of the dtb overlays
<clever> nschoe: you may need to disable bluetooth to make the serial work right
<clever> only haskell does it, as far as ive seen
<clever> same, i tracked it down a few months ago when somebody else made the same mistake, and i wanted to know how it didnt fail
<clever> yep
<clever> it winds up excluding functions as well, causing it to not fail
<clever> WilliamHamilton[: there is another function, that filters all haskell dependencies, to exclude non-haskell things
<clever> lists in nix are greedy and need () to force the order correctly
<clever> not the result of applying the function to the derivation
<clever> WilliamHamilton[: that is a list containing the function and a derivation
<clever> o1lo01ol1o: pkgs.runCommand "name" { buildInputs = [ foo ]; } "build script" is also of use
<clever> yep
<clever> o1lo01ol1o: it would probably be easyer if you gist all of your nix files ane give a better example of what you want done
<clever> or you rename things to be more sane
<clever> then you use ${shell.foo}/bin/foobar and ${shell.bar}/bin/foobar in the buildCommand
<clever> every derivation is isolated and can only access its own buildInputs
<clever> builder is a lot more limited
<clever> o1lo01ol1o: you generally want to use buildPhase and installPhase, rather then builder
<clever> o1lo01ol1o: or make a new derivation, that has that list on its buildInputs
<clever> o1lo01ol1o: you need to add src to every item in the list then
<clever> o1lo01ol1o: you need to modify the derivation to add src = ./.; or similar
<clever> o1lo01ol1o: usualy, -A provides a shell suitable for building foo, not for using foo
<clever> o1lo01ol1o: does nix-build work on those derivations yet?
<clever> ivegotasthma: ive seen traces of bsd in nixpkgs, and i think darwin is bsd-ish, but ive not heard much about them actually being used
<clever> ivegotasthma: the darwin kernel and windows kernel are also supported, though windows has some issues still
<clever> singlequotes on the outside is the simplest solution
<clever> WilliamHamilton[: so the command turned into this
<clever> nix-shell -p with import <nixpkgs> {}; haskellPackages.callCabal2nix Agda (fetchFromGitHub {owner= agda; repo= agda; rev= ac38171335f3cdd4be92326c1b3aace484320803; sha256= 0000000000000000000000000000000000000000000000000000; } ) {}
<clever> WilliamHamilton[: you have doublequotes inside doublequotes
<clever> WilliamHamilton[: callCabal2nix handles the callPackage for you
<clever> you can either use it in a normal shell, or just use the wrong hash in a nix repl
<clever> ,tofu WilliamHamilton[
<clever> WilliamHamilton[: builtins.fromJSON
<clever> = not :
<clever> WilliamHamilton[: you gave it json, not nix
<clever> nh2++
<clever> so i would expect 2.1.3 and master to be broken
<clever> the first good commit is on 2.1.3, as is the first bad commit
<clever> and it could also be a smaller file for faster repro, it just needs to be a url ending in .xz
<clever> i already have a `nix-build` command in the issue, but you could just put that attr into a -E flag
<clever> nh2: but dtz's host isnt to blame, its working perfectly
<clever> and because my nix was newer, and i lacked the binary cache, i ran into the issue
<clever> nh2: i think it was when we where trying to solve gold issues with musl on ghc?
<clever> nh2: sure
<clever> nh2: i narrowed the bisect down to a certain region of commits, then entirely forgot about it! lol
<clever> ah
<clever> but if its modifying linux internals, it becomes harder to maintain it as an external module
<clever> and any additional files would be in the same dir
<clever> hyperfekt: you would need a makefile and kconfig like in here, to begin with: https://github.com/cleverca22/v3d2
<clever> hyperfekt: if the source was kept as an external module, it could be built on any kernel version
<clever> infinisil: neat
<clever> hyperfekt: yeah, i see it now, its using a fork of the linux kernel, with the BCACHEFS_FS flag enabled
<clever> hyperfekt: thats changing out the entire kernel package set, and the kernel version
<clever> hyperfekt: oh wait, no, misread that nvm
<clever> everything else looks great
<clever> hyperfekt: its best to use a kernel package from config.boot.kernelPackages, which has to be added to the right region of all-packages.nix, or it will wind up being of the wrong kernel version
<clever> hyperfekt: this line will likely cause problems
<clever> hyperfekt: boot.kernelPackages = pkgs.linuxPackages_testing_bcachefs;
<clever> hyperfekt: i prefer zfs, but always nice to see more choices available in nixos
<clever> > let foo = ({ a ? 42 }: a); in foo
<clever> > ({ a ? 42 }: a)
<clever> because it dis-agrees with the source
<clever> i think {^_^} also auto-called pkgs.nixos with {} before printing it
<clever> roberth: yeah
<clever> though that ignores overrides+overlays
<clever> roberth: i just use import (pkgs.path + "/nixos") { configuration = ...; }
<clever> gchristensen: also try alsamixer, use f6 i think to change cards
<clever> so you refered to this function, i'm surprised to even see that in the pkgs tree
<clever> > nixos
<clever> gchristensen: nix-env takes channel names (nixos.) but nix-shell doesnt
<clever> gchristensen: try flipping each of the mute flags in pavucontrol?
<clever> systemd can be configured to not restart things when they fail due to an error, rather then exiting with 0
<clever> nh2: might it be related to the rsync failing due to an error?
<clever> nh2: i usually see a OnCalendar= in the timer files, so this one likely behaves differently then what i'm used to
<clever> nh2: can you pastebin the output of `systemctl list-timers` ?
<clever> WilliamHamilton[: callPackage and callCabal2nix will then import that with the right args
<clever> WilliamHamilton[: cabal2nix will return a nix file containing mkDerivation
<clever> WilliamHamilton[: either run cabal2nix on that repo (either url or ./.) and then haskellPackages.callPackage it, or use `haskellPackages.callCabal2nix "name" (pkgs.fetchFromGithub { ... }) {}`
<clever> lukego: that option is a list type, so it will merge with all other values automatically
<clever> WilliamHamilton[: basement = self.callHackage "basement" "0.0.8" {};
<clever> WilliamHamilton[: you can first try callHackage, if the version happens to be in the db
<clever> __red__: there arent really any good cross-compile options for targeting darwin right now
<clever> samueldr: it is able to supress a keyword at least
<clever> time is a shell keyword
<clever> time (GNU Time) 1.9
<clever> $ command time --version
<clever> but [ seems to have very special parsing, lol
<clever> samueldr: `command` usually forces bash to search PATH and ignore internals
<clever> samueldr: or not, ack!
<clever> samueldr: you can also `command [ --version`
<clever> __red__: i cant see any obvious source for that INSTALL=, so i would just `installPhase = "make install";` and your done
<clever> i just found 2 open tabs, both to installPhase, lol
<clever> also, i read setup.sh far too often
<clever> and now its not mixed in with other packages, so you can tar it up and make a package
<clever> then it will install to /dummy/usr/ but expect files to be in /usr/ at runtime
<clever> basically, you set both INSTALL (to a dummy root dir) and PREFIX (to /usr/ for ex)
<clever> that var is usually used to make debian packages for ex
<clever> heh
<clever> that will set the ${INSTALL} var inside the makefile
<clever> line 1085 will print those extra flags before running `make install`
<clever> __red__: the default installPhase calls `make install` witl a lot more params
<clever> samueldr: heh, need to switch over to something like environment.interactiveShellInit!
<clever> samueldr: lol :D
<clever> environment.extraInit winds up in a special set-environment file, that is sourced by /etc/profile and a few other things
<clever> environment.interactiveShellInit winds up in /etc/bashrc
<clever> environment.shellInit, programs.bash.shellInit, environment.loginShellInit all wind up naked in /etc/profile
<clever> all of the nixos options involving shell init, and what file each winds up in
<clever> one moment, grabbing something else of use
<clever> the nixos module already lets you change the db path
<clever> programs.command-not-found.dbPath
<clever> oh!
<clever> then you dont have to force priority
<clever> and perhaps programs.command-not-found.enable = false; to make the old one get out of the way
<clever> youll just need to re-define that bash function again
<clever> ottidmes: it refers to a variable in a let block, so there is no way to override it
<clever> /home/clever/nixpkgs/nixos/modules/programs/command-not-found/command-not-found.nix: command_not_found_handle() {
<clever> ottidmes: the real thing doing the job, is the bash function command_not_found_handle, which has a full storepath baked into it
<clever> ottidmes: aha, `type command_not_found_handle`, run that
<clever> ottidmes: and if you manually run nix-locate /bin/hello, it finds something?
<clever> ottidmes: the #! appears to be missing
<clever> __red__: yep
<clever> ottidmes: and if you just cat it?
<clever> ottidmes: what is the contents of the current /run/current-system/sw/bin/command-not-found ?
<clever> 1-3 of the existing nix.conf
<clever> __red__: line 1-3 should also explain that
<clever> __red__: https://nixos.org/nixos/options.html#nix.buildcores
<clever> ottidmes: i think hiPrio only works on nix-env, and has no impact on systemPackages
<clever> ottidmes: double-check what is in /run/current-system/sw/bin/command-not-found, and try lib.mkBefore, rather then hiPrio
<clever> ottidmes: is that in nix-env or systemPackages?
<clever> just call nix-locate bin/$1
<clever> ottidmes: yeah, thats always an option
<clever> and it generates the programs.sqlite db
<clever> this script is responsible for generating the tars that nix-channel downloads
<clever> ottidmes: i had heard that this was improved to use nix-index, but the source says otherwise
<clever> still is
<clever> 11 my $dbPath = "/nix/var/nix/profiles/per-user/root/channels/nixos/programs.sqlite";
<clever> last i looked, command-not-found has that path hard-coded
<clever> ottidmes: you can also use nix-index and nix-locate directly to update your own db
<clever> ottidmes: you need a channel called nixos, on the root user, that came from nixos.org
<clever> -r--r--r-- 1 root root 3.3M Dec 31 1969 /nix/var/nix/profiles/per-user/root/channels/nixos/programs.sqlite
<clever> ah, the new one is also using programs.sqlite
<clever> ottidmes: programs.sqlite is the older command-not-found system
<clever> hyperfekt: command-not-found uses a database in the channel
<clever> hyperfekt: are you using nix-channel and one of the proper channels?
<clever> azazel: syncplay tends to catch the exception though, and then resume things, so that may not work
<clever> and upon reconnecting, it tries to list the same dir, and fails again
<clever> in my case, the exception isnt caught, and it unravels the stack hard enough to break my connection to the server
<clever> so you must then spend hours looking over strace output to find out why, lol
<clever> and if any filename fails, it throws an exception, and doesnt tell you what file caused the problem
<clever> aleph-: i have a different python program, which runs a function to recursively list a directory, and it tries to parse every single filename as utf8
<clever> aleph-: and it uses pythonPackages as an arg, so you can mopidy = super.mopidy.override { pythonPackages = super.python3Packages; };
<clever> 17909 mopidy = callPackage ../applications/audio/mopidy { };
<clever> aleph-: so you need to make an overlay that overwrites mopidy
<clever> aleph-: which is a wrapper around pkgs.mopidy that mutates PYTHONPATH
<clever> aleph-: in that case, it just runs the "binary" inside mopidyEnv
<clever> Drakonis: not sure, but i do remember that line from somewhere
<clever> Drakonis: i'm a dude :P
<clever> andi-: i was using spot instances for all testing, and its currently hard-coded to only do spot, i plan to make it a nix option in the deployment file
<clever> andi-: and i need to redo that entire nixos config layer, to fetch what is pre-generated on the machine
<clever> andi-: probably, i havent tested deploy yet

2018-11-02

<clever> :D
<clever> possibly
<clever> azazel: and you need to use uwsgi.service, not uwsgi
<clever> Mic92: https://github.com/input-output-hk/nixops/commit/696687280078ce120f0cd390d2c4d060e130af82 and i can now create a packet.net machine via nixops
<clever> azazel: you probably also want to set after
<clever> hyperfekt: you want -I nixos-config=/mnt/etc/nixos/configuration.nix
<clever> hyperfekt: what args did you run it with?
<clever> Mic92: :O
<clever> now i need to loop and check the state until it gains an ip
<clever> Mic92: so i can now create and destroy sshkeys, and machines, but the machine doesnt have an ip immediate after creating, causing nixops to break
<clever> "string", lol
<clever> the docs also dont tell you what it expects in any fields
<clever> with zero type checking
<clever> and the library is just a thin wrapper around the REST api
<clever> Mic92: that string is directly from the json that the REST api spit out
<clever> my first idea, was that i lacked permission to create devices
<clever> Mic92: how would you parse this error?
<clever> Error 422: users: "7e24caef-6317-4b2b-8830-d5e9b77f27d2" are not collaborators on this project
<clever> that didnt help with the api giving vague errors
<clever> Mic92: i already patched the python library to print all request and response bodies
<clever> Mic92: so what looked like a permission error, was actually a 404 for the ssh keys listing! lol
<clever> i assumed it was my userid, but no, it was the unique id i put in to the ssh keys list
<clever> it then gave an error, saying .... is not a colaborator
<clever> i assumed that the ssh keys your authorizing, are a list of unique id's for the ssh keys, from the api to create them
<clever> half of my problem is just a lack of documentation with this cloud provider
<clever> Mic92: heh, i'm currently adding a new backend to nixops
<clever> ottidmes: its a somewhat recent addition, ive also been messing with service names in the copy to make them not conflict, prior to discovering that
<clever> ah yeah, i did see it
<clever> xourt: one of the /proc/*/maps files refers to that path, check them all with a grep
<clever> and to make nixos ignore its own version of a module, so you can imports a customized version: https://nixos.org/nixos/manual/#sec-replace-modules
<clever> `-I nixos-config=./configuration.nix` on most nix commands, to make them use a different configuration.nix
<clever> imports = [ ./foo.nix ]; to load a custom module in your configuration.nix
<clever> hyperfekt: `nix repl '<nixpkgs/nixos>'` and then eval `config` and `options` to inspect the current state of all modules in your current config
<clever> hakujin: if recursive == false, then the path is a file, and does not support directories (fetchurl for ex)
<clever> oh, but i think the filename is included either way
<clever> hakujin: depends on if its recursive or flat hashing
<clever> moredhel: netstat -anp | grep 53, as root, should tell you what program is to blame
<clever> locallycompact: just override src= to use fetchgit or fetchFromGitHub
<clever> locallycompact: a really simple way of pinning nixpkgs: https://github.com/input-output-hk/cardano-chain/blob/devops-1118/pkgs.nix#L2
<clever> you can still do that without forking nixpkgs
<clever> that builds a patched version of nix, my vpn, and some dummy things
<clever> locallycompact: you also dont have to fork nixpkgs if you just want to build one thing
<clever> locallycompact: running your own hydra is about the only way to build a reasonable chunk of nixpkgs
<clever> jonge: but ive noticed that traversing the massive /nix/store/.links/ dir does get worse over time, and then even adding a new link becomes a cost
<clever> jonge: its limited to just the storepath thats being built/downloaded, so it can optimize faster
<clever> auto-optimise-store = false
<clever> jonge: there is also a nix.conf flag to do it after every build/download
<clever> i just read the nix files, all the time
<clever> locallycompact: i consume source code for breakfast, lol
<clever> )
<clever> locallycompact: when you import <nixpkgs/nixos>, also pass it `system = "i686-linux";` as an argument (near the `configuration=`
<clever> cinimod: installing libraries with nix wont make them findable by any compiler, and only the compilers within nix have been modified to be able to find them correctly
<clever> ,library
<clever> and the /stuff isnt needed anymore
<clever> locallycompact: and depending on what you want, also get rid of the autologinUser
<clever> locallycompact: you can get rid of everything under virtualisation, kernelParams, systemd
<clever> that will allow it to use up to 8g of ram, and the build should pass
<clever> locallycompact: mount /tmp -o remount,size=8g
<clever> locallycompact: tmpfs?
<clever> locallycompact: df -h $TMP
<clever> locallycompact: nixos or other?
<clever> locallycompact: what about the host drive?
<clever> locallycompact: your drive is full
<clever> cinimod: use haskell.ghcWithPackages i believe
<clever> locallycompact: that seems to have been removed in july of 2018, as it didnt actually do anything by then
<clever> > sundials.outputs
<clever> so you can just get rid of partitioned = true;
<clever> it now takes a string with a type, and the default works fine
<clever> in dec of 2017, partitioned was renamed to partitionTableType
<clever> the example is from march of 2017
<clever> and the ; on 45 doesnt belong
<clever> locallycompact: it needs a `let` near the start, and a `in` between lines 44 and 45
<clever> and then you can freely edit the config on lines 5-34
<clever> locallycompact: youll need to cut lines 2-45 into its own file, and then refer to the rootDisk attr
<clever> locallycompact: line 43 sets the size of the disk image, 41 makes it have a partition table, 42 makes it bootable, and 35 loads a configuration.nix value (held in dom0_config this time)
<clever> Priority: 40
<clever> eeva: there is a nix-cache-info in the root of the cache, which has its priority
<clever> make-disk-image.nix then
<clever> zduch4c: the ; at the end shouldnt be
<clever> but that dir doesnt exist, so nothing was building them?
<clever> --mandir=/nix/store/6j6slxdhbbzxvhkn6yf7afm62r8n9fmf-ghc-8.4.3/share/man was also present on one line
<clever> and i do see html docs in ghc.doc
<clever> but nothing obvious about missing man related tools
<clever> i see libffi is installing its man pages to a subdir of /build/
<clever> this command will show the build log for that derivation
<clever> nix log /nix/store/6j6slxdhbbzxvhkn6yf7afm62r8n9fmf-ghc-8.4.3
<clever> and due to nix being pure, it cant find those tools, and silently disables building man pages
<clever> Unode: i'm guessing that the impurity of emerge leads to it finding the tools for manpage building, and just generating them at build time
<clever> i see no mention of man pages in its ebuild, but it is inheriting from a number of things
<clever> heh, and i even have that ebuild on my old gentoo box
<clever> -rw-r--r-- 1 root root 22K Jul 26 2016 ghc-7.10.3.ebuild
<clever> Unode: and `equery b` reports it as being part of the ghc package?
<clever> what package is it in on those systems?
<clever> then installing neither will get you man pages
<clever> Unode: run `nix-build '<nixpkgs>' -A ghc -A ghc.doc`, then look in result/share and result-doc/share, which one has man pages?
<clever> > ghc.outputs
<clever> Unode: how are you installing them?
<clever> o1lo01ol1o: just treat its result as a string somewhere else, its just a normal derivation
<clever> aanderse: yep, ive got 3 of them

2018-11-01

<clever> often helps to have a second set of eyes, that arent making the same assumptions
<clever> then why is sda2 on /mnt/boot/ ?
<clever> /dev/sda2 on /mnt/boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
<clever> your trying to use the usb stick as /boot i think
<clever> ddellacosta: `mount` shows that sda is the install ISO you booted from
<clever> ddellacosta: thats claiming its not a gpt disk, and what is the type code on sda1 ??
<clever> ddellacosta: and `fdisk -l /dev/sda` ?
<clever> ddellacosta: can you pastebin the output of `mount` ?
<clever> teser: if /dev/kvm doesnt exist, it will silently not use kvm
<clever> teser: build-vm can work without kvm, but will be a lot slower without it
<clever> romildo: with import ./. {}; instead
<clever> romildo: nix-build -E 'with import <nixpkgs> {}; vivaldi.override { proprietaryCodecs = true; }'
<clever> romildo: you want vivaldi.override, via -E
<clever> so non-root users can do some root-like actions
<clever> i believe polkit is responsible for letting xfce shutdown without a sudo prompt
<clever> jophish: who wants to rewrite polkit for V8? lol
<clever> schopp0r: it should have a flag for it in ./configure
<clever> ah
<clever> schopp0r: why not just use https://nixos.org/nix/install ?
<clever> schopp0r: nix has an s3:// url it supports
<clever> schmittlauch[m]: executables you patch into PATH for use at runtime would also be in the buildInputs i believe
<clever> schmittlauch[m]: buildInputs is stuff you link against, and later use at runtime (the target when cross-compiling)
<clever> schmittlauch[m]: nativeBuildInputs is stuff that has to run at compile time, on the host (when cross-compiling)
<clever> thats printed on the sticker for some of my newer drives
<clever> turion: this one for example, uses the serial# from a sata disk