2020-08-19

<clever> /nix/store/a759kbr0kgccsxl6lfx0xv5i3c9x9bw9-binutils-2.31.1/bin/ld: ../emu/libtilemcore.a(graycolor.o): undefined reference to symbol 'pow@@GLIBC_2.29'
<clever> srhb: yeah, they are pretty basic :P
<clever> [clever@system76:~]$ uptime 02:37:12 up 71 days, 17 min, 2 users, load average: 2.52, 2.71, 2.65
<clever> [clever@amd-nixos:~/apps/siraben/zkeme80]$ nix build -f . -L runit
<clever> yeah
<clever> oh, zkeme80, that was the calculator stuff, right?
<clever> it defaults to 1h
<clever> that makes the cache expire 1 minute after you downloaded it
<clever> --option tarball-ttl 60
<clever> note that nix caches the tar files it downloads
<clever> its working here
<clever> siraben: same error?
<clever> siraben: you may need a name= instead of pname, if your nixpkgs is too old
<clever> siraben: it should be something like this, { package = pkgs.rustPlatform.buildRustPackage { ... }; }
<clever> add a `{ package =` and `;}` to the file, and it should begin working
<clever> siraben: then that is your problem, the default.nix must return { package = ...; }
<clever> siraben: does it work with `nix-build -A package` ?
<clever> vika_nezrimaya: config and imports must be siblings, not parent/child
<clever> so you cant { pkgs, config, ... }:
<clever> c74d: the value put into config must be a set, not a function
<clever> drakonis: you need to find out what part of the module is reading config.json and fix it
<clever> try with --impure i think it was?
<clever> drakonis: might be a flake thing
<clever> drakonis: what cmd did you run?
<clever> drakonis: what error?
<clever> Ingor: but once you know the name, it can fetch without using as much
<clever> Ingor: nix-env -qa can be pretty memory hungry
<clever> Ingor: how much ram does the machine have?
<clever> Ingor: nixops is perfectly capable of that
<clever> so the merging problems dont exist, but its harder to remove
<clever> and it seems the default isnt using mkDefault or default= anymore
<clever> vika_nezrimaya: thats the example, not the default
<clever> 388 nix.binaryCachePublicKeys = [ "cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=" ];
<clever> and if you encourage mkForce, you need to mkForce in every file to make it keep appending
<clever> so setting it at normal priority clears all defaults
<clever> the problem is that the default value, is at the default priority
<clever> it is
<clever> its anoying that adding one key removes the default
<clever> vika_nezrimaya: `man configuration.nix`
<clever> vika_nezrimaya: you can find it in the docs for that nixos option, as the default value
<clever> jlv: https://gist.github.com/3fbf226d87a47e0d82771cdbd6970dfa doesnt infinitely recurse
<clever> jlv: the key, was that language-server was in the --show-trace
<clever> jlv: yep, pkgs.haskellPackages.haskell-language-server fixed it
<clever> jlv: but if you get hls from an un-overlaid haskellPackages...
<clever> jlv: the problem is triggered via this line: 47 ${ghc.haskell-language-server}/bin:\
<clever> leo60228: it may need a `sdImage.populateRootCommands = "touch files/dummy.txt";` in the nixos config
<clever> leo60228: read `nix show-derivation /nix/store/b4z6nq01vknblf0nq7d1sif2wv4nlra8-ext4-fs.img.zst.drv` and you may see where
<clever> leo60228: there is probably a "cp $foo/* $out" somewhere, and nullglob turned it into "cp $out" due to no matches
<clever> jlv: can you gist your current nix exprs?
<clever> jlv: you can also try using .override instead for just random, and see if it breaks or not
<clever> vika_nezrimaya: the UI randomly glitches out for me
<clever> vika_nezrimaya: anoyingly, the emoji in the /topic for this channel, has width problems on my terminal

2020-08-18

<clever> jlv: and smallcheck_1_2_0 got away with testing, by using the "wrong" version to test itself
<clever> jlv: it might be that smallcheck depends on smallcheck, and needs a haskell.lib.dontCheck applied to it
<clever> jlv: you need to look at the --show-trace and figure out where the cycle is
<clever> jlv: (haskellPackages.override { overrides = hsuper: hself: { OVERLAY HERE }; }).ghcWithPackages
<clever> jumper149: pinentry-curses is just an alias to pinentry.curses
<clever> 5769 pinentry-curses = (stdenv.lib.getOutput "curses" pinentry);
<clever> jumper149: yeah, an issue may help
<clever> colemickens: though, i also see a --no-root-passwd to nixos-install
<clever> colemickens: you also have to set mutableUsers = false;
<clever> jlv: if you just .override, then you wind up with 2 versions of the package in the closure, and things get ugly
<clever> jlv: and probably random too
<clever> jlv: you want an overlay that does splitmix = self.splitmix_0_1_0_1; and the same for smallcheck
<clever> jumper149: yeah, an overlay doing something = buildEnv { paths = [ pinentry-curses ]; }; might do it
<clever> jumper149: youll need to make a wrapper using buildEnv, or just shove it into environment.systemPackages
<clever> jumper149: yeah, nix-env has some trouble with split output stuff, its still installing .out, not .curses
<clever> jumper149: `ls -l ~/.nix-profile/bin/pinentry`, which storepath did it install?
<clever> maralorn: nix rarely gives you multiple versions of haskell packages, there is just one main version
<clever> > "${pinentry-curses.curses}/bin"
<clever> jumper149: its a split output package, it has 7 outputs!!
<clever> > pinentry-curses.outputs
<clever> maralorn: or tab-complete in `nix repl '<nixpkgs>'`
<clever> jlv: weird, when did it go from 2 version components to 3?
<clever> jumper149: nix-env -iA should give you both binaries then
<clever> > haskellPackages.splitmix
<clever> bqv: fsck -f -v /dev/bqv
<clever> jumper149: if you `nix-build '<nixpkgs>' -A pinentry-curses && ls -lh result/bin/` what does the package provide?
<clever> redmp: system.autoUpgrade.enable will never work with nixops, that will un-deploy everything
<clever> jlv: you may need to use doJailBreak to force it to ignore the versions of its deps
<clever> jlv: nix just manages giving it a version, not always the right version
<clever> or to set a reminder to check up on it latere
<clever> probably just needs a maintainer to look into the problems more, and fix them instead of just flagging it as broken
<clever> the difference between nix-build failing instantly, vs nix-build spending an hour compiling, then failing
<clever> energizer: the whole point of marking a package as broken, is so hydra (and end-users) dont waste time building a package that is known to fail at building
<clever> CMCDragonkai: maybe somebody fixed it by accident, so they didnt unmark it

2020-08-17

<clever> vika_nezrimaya: another neat trick is https://blog.filippo.io/ssh-whoami-filippo-io/
<clever> just thought you might want to know of it, and use it for stuff
<clever> vika_nezrimaya: yep
<clever> vika_nezrimaya: have you seen the command= stuff in authorized_keys ?
<clever> vika_nezrimaya: i did mess with that kind of thing over ssh and nfs in the past, but now that ive paid for my github, i have unlimited private repos, so i dont bother with it as much
<clever> wpcarro: when i was new to linux, i just dove head-first into /usr/share/man/ and read half the pages ......
<clever> wpcarro: i think its in a man page, but i forget which one
<clever> so they never get out of sync
<clever> i also try to -w any secret keys and their matching pub file
<clever> yeah
<clever> but private stuff may be o-rwx, to cut outsiders off
<clever> wpcarro: +x only, means you are blind, and must know the name to open a thing
<clever> wpcarro: +r on a dir lets you list the contents, +x lets you interact with the contents (cd, and do anything with a content)
<clever> ScottHDev: mkShell, because it confuses people when they need to siwtch to libsForQt5.mkDerivation
<clever> wpcarro: either other+x, group+x or owner+x
<clever> wpcarro: you need +x on a directory in order to do anything with the contents of a directory
<clever> ScottHDev: i try to avoid it, since it causes more confusion
<clever> ScottHDev: its just a function that calls stdenv.mkDerivation and sets a name for you
<clever> vika_nezrimaya: there may be other changes in nixpkgs, that make it unable to build versions too old/new
<clever> vika_nezrimaya: you want to base it on the same nixpkgs revision that built the good/bad wine (around the point where the version changed)
<clever> so nix takes care of the entire mess of building it
<clever> vika_nezrimaya: that will build wineStaging from the nixpkgs attr, but override the src to come from . so you can bisect wine
<clever> vika_nezrimaya: nix-build -E 'with import ~/apps/nixpkgs {}; wineStaging.overrideAttrs(old: { src = ./.; })'
<clever> vika_nezrimaya: and then you can go further, bisect wine to find out which commit broke it!!
<clever> wpcarro: if the key was created manually, then you also need to chown it manually
<clever> wpcarro: sounds like you just need to chown /etc/secrets/buildkite-agent-token to the right user
<clever> wpcarro: plus nixops?
<clever> wpcarro: are you using the systemd service for it?
<clever> vika_nezrimaya: boom!
<clever> "/nix/store/5gzkb53wvw9cll684fh60n0bc2dvv1l6-wine-5.12-staging"
<clever> [clever@amd-nixos:~/apps/nixpkgs-hasura]$ nix-instantiate --eval -A wineStaging.outPath
<clever> [clever@amd-nixos:~/apps/nixpkgs-hasura]$ git checkout 96069f7d890b90cbf4e8b4b53e15b036210ac146
<clever> and repeat...
<clever> so i'm going to tell bisect that 5.5 is good and 5.14 is bad
<clever> the rev i'm on, is too old, 5.5 vs 5.12
<clever> "/nix/store/zgvgxp0c11sdyw1a5s29bnixsvcs0rq8-wine-5.5-staging"
<clever> [clever@amd-nixos:~/apps/nixpkgs-hasura]$ nix-instantiate --eval -A wineStaging.outPath
<clever> and the revisions skip a lot
<clever> the timestamps are offset by hours or even days
<clever> and i think its the timestamp of when it entered the channel, not when the commit was made
<clever> so those that pass testing in hydra, and are covered by the cache
<clever> its only the revisions that make it into the channel
<clever> yep
<clever> this file, contains the nixpkgs revision of nixos-unstable over time
<clever> there is one other trick available
<clever> what store path are you using, what was the registrationTime time for it?
<clever> yeah, it should be in the hydra DB
<clever> and start at the most recent, then work backwards
<clever> you can narrow the search, by only bothering with revisions where wine is the same version
<clever> `nix-instantiate -A wineStaging` every revision of nixpkgs, until you get a match
<clever> and your only solution is brute-force
<clever> then you garbage-collected the .drv file
<clever> repeat until there is no diff
<clever> then decide if its newer or older (compare versions of deps) and bisect good/bad
<clever> and then nix-diff to compare the 2 drv files
<clever> then `nix-instantiate -A wineStaging` in a nixpkgs clone, to get a drv for the current checkout
<clever> first, `nix-store -q --deriver /nix/store/foo` to find the .drv for the given path
<clever> youll need to bisect nixpkgs and use nix-diff
<clever> ah, but if its not in a profile, you have problems
<clever> and the nixos derivation puts a nixpkgs rev into its name
<clever> vika_nezrimaya: not directly, but if you use what i just gave, you can find the nixos that contained that wine
<clever> vika_nezrimaya: that just lists every version of wine used for every past generation
<clever> vika_nezrimaya: ah, that sounds like a handy command, ive previously just used: ls -l /nix/var/nix/profiles/system*/sw/bin/wine
<clever> `_: path + "/${foo}" will remain as a path, and ../ can work, "${path}/${foo}" will copy path to /nix/store/hash-path and then ../ is /nix/store and it all breaks
<clever> `_: dont quote paths and variables using paths
<clever> yep
<clever> it was probably the video group that was absent from `id`
<clever> Akshay[m]: what does `ls -l /sys/class/backlight/intel_backlight/brightness` say?
<clever> it shows up like this on this end
<clever> 2020-08-17 01:23:31 * Akshay[m] uploaded an image: light.png (72KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/NJOYtdQctlZUwlSmLWnUzDkc/light.png >
<clever> ah, that image
<clever> matrix didnt pass it on to irc
<clever> Akshay[m]: what output does the light command give? thats missing
<clever> Akshay[m]: oh, misread the msg
<clever> Akshay[m]: how did you add yourself to the light group?
<clever> Akshay[m]: you need to relog for changes to your groups to take effect
<clever> Akshay[m]: if you run `id`, does it say your in the light group?
<clever> weird
<clever> energizer: if it wasnt setup to boot over usb, that could be the problem
<clever> energizer: not sure what else to check then
<clever> energizer: and if you plug the usb hdd into the same hub?
<clever> energizer: are you using a usb keyboard?
<clever> energizer: does blkid find things now?
<clever> energizer: ls -l /dev/disk/by-uuid/ ?
<clever> energizer: if you unplug and replug the usb drive, does dmesg gain more lines?
<clever> energizer: did dmesg in stage-1 show the usb stick connecting?
<clever> energizer: then run lsusb on another machine, with the same stick, do you see the same vid:pid pair?
<clever> energizer: the device id will be vendor-id and product-id pairs
<clever> energizer: check lsusb, does the usb device show up?
<clever> energizer: launch an interactive shell (i) and try to poke around, can you see the rootfs?
<clever> ah, try using the grub menu to rollback?
<clever> energizer: did you use unetbootin or dd?

2020-08-16

<clever> dsal: it should stop if you clear the userdata on the instance

2020-08-15

<clever> ah, simple
<clever> bogdb: can you share your expr? i also like trimming the fat, ycmd makes it a gig larger
<clever> bogdb: it just uses pkgs.ycmd

2020-08-14

<clever> bbarker: no, thats how cabal is used
<clever> bbarker: how did you launch the shell? is it against the .env attr?
<clever> bbarker: try `runhaskell Setup.hs configure` then `runhaskell Setup.hs build`
<clever> bbarker: the single-project mode, not the stack-like mode
<clever> bbarker: thats why i said old cabal
<clever> you need to cabal2nix your project into nix, and then run nix-shell on the .env of the project
<clever> one reason i avoid stack
<clever> the stack method isnt aware of any native deps for the packages
<clever> bbarker: but that just runs a shell.nix file, which must have zlib in the buildInputs\
<clever> bbarker: i find it MUCH simpler to ignore stack, and use plain cabal (old cabal)
<clever> bbarker: so you must re-create the list of buildInputs everything needs in your shell.nix file, this happens every time somebody tries using stack
<clever> bbarker: `stack build` cant use the deps info from each package, and it ignores what nix has already built
<clever> ,xy bbarker
<clever> bbarker: and cabal2nix/hackage2nix already did the right thing
<clever> 73550 }) {inherit (pkgs) zlib;};
<clever> 73547 librarySystemDepends = [ zlib ];
<clever> 73540 "digest" = callPackage
<clever> [clever@amd-nixos:~/apps/nixpkgs/pkgs/development/haskell-modules]$ vi hackage-packages.nix
<clever> you also need to be careful you dont depend on zlib.cabal
<clever> bbarker: also, i think the library is called libz.so, linked with -lz, so you would want `extra-libraries: z` and `pkgs.z`
<clever> bbarker: basically, you just want a extra-libraries: field in the cabal file
<clever> bbarker: if its properly defined in the cabal file, then cabal2nix should expect pkgs.zlib to exist, as an input
<clever> spease: did you try logging out and back in?
<clever> jlv: the install script will unpack a tar of a /nix/store that has nix and all of its deps
<clever> installing it with another package manager tends to break the sandbox stuff
<clever> nix should always be managed by nix
<clever> why did you uninstall it?
<clever> having a profile wont change the contents of $NIX_PATH
<clever> just install anything, and it creates a profile
<clever> spease: nix-env -iA nixos.hello
<clever> spease: nix-env will generate that automatically when you install something

2020-08-13

<clever> thats the nix way of doing things, ignore /etc/ entirely, and just use absolute paths for everything
<clever> that will generate a file in /nix/store/ and then point the config to it
<clever> steadmon: you could also do `services.postfix.mapFiles.generic = builtins.toFile "any-name" "body";`
<clever> jlv: you could pre-fetch things, compute the sha256, and then generate an extra lock file that lists the sha256's
<clever> jlv: and pkgs.fetchFromGitHub is faster, if its github
<clever> jlv: i find pkgs.fetchgit to be a lot more reliable
<clever> jlv: it gets cached in ~/.cache/nix/gitv2 so a GC wont delete it
<clever> makefu: bash only listens if you scream
<clever> jlv: unpackPhase = "cp -vi $src something";
<clever> $NIXPKGS_CONFIG also overrides the config.nix path
<clever> bqv: --arg doesnt play nicely with -p, and shell.nix eats all the other args
<clever> bqv: nix-shell -E 'with import <nixpkgs> { config.allowBroken = true; }; ....'
<clever> _user: the expr is evaled in its own isolated context, so pkg1&pkg2 dont exist yet
<clever> in my case, its a function that takes a pkgs tree, and returns a list of packages you chose
<clever> --arg can take any nix expr, just like -E, and then just passes it into the file
<clever> then { extraPkgs ? (pkgs: {}) }: and buildInputs = [ (extraPkgs pkgs) ];
<clever> _user: nix-shell --arg extraPkgs 'pkgs: with pkgs; [ foo bar ]'
<clever> yep
<clever> samueldr: nix-shell -E 'with import <nixpkgs> {}; stdenvClang.mkDerivation { name = "dummy"; buildInputs = [ cmake ]; }'
<clever> samueldr: yep
<clever> _user: gcc is always in nix-shell, you want to use clangStdenv instead of normal stdenv
<clever> bqv: gcc and make are in the nix-shell by default
<clever> jakob_rs: yeah, the runtime deps of each build-time dep is also included in the sandbox
<clever> jakob_rs: so it behaves like a derivation in nearly every way, including the sandboxing
<clever> jakob_rs: builtin:builenv stuff is technically a derivation, but instead of running a program in the sandbox, it runs a function in the nix library
<clever> jakob_rs: deps are either other derivations, or a raw path (the result of things like "${./foo}")
<clever> jakob_rs: correct
<clever> for runtime deps, nix will NAR up $out (similar to tar), and grep the entire NAR for the hash of each build-time dep
<clever> jakob_rs: when you pass those strings into a new derivation, they get collected together, and form the build-time dependencies
<clever> jakob_rs: all strings have some "context" invisibly attached to them, which says which derivations it depends on
<clever> jakob_rs: modern nix does count that as a dep on bash
<clever> drakonis: php-fpm is my prefered method
<clever> nature: with pkgs.vimPluguns; with pkgs.vimUtils;
<clever> probably both
<clever> i think dummy is something i did a while back while playing with it, and nixos isnt a program, but a full copy of nixpkgs
<clever> and like any nix-env profile, you can list the installed things
<clever> nixos-20.09pre237606.b50ef9afa11
<clever> dummy
<clever> [root@amd-nixos:~]# nix-env --profile /nix/var/nix/profiles/per-user/root/channels -q
<clever> when you `nix-channel --update nixos`, it will do something like `nix-env -i -E .... --profile /nix/var/nix/profiles/per-user/root/channels` to "install" a thing called "nixos" to the profile
<clever> because its a normal nix-env profile, and manifest.nix allows nix-env -i usage
<clever> the nixos-config bit is where it deviates from `gcc -I`, that maps <nixos-config> to /src/configuration.nix
<clever> veleiro: it behaves a lot like `gcc -I`, for any <foo>, check if /nix/var/nix/profiles/per-user/root/channels/foo exists
<clever> veleiro: line 12 points to a static path, so you dont have to keep relogging, and then line 16 sets up that path to point to a copy of nixpkgs
<clever> also, that value gets baked into the env of shells, and if you nixos-rebuild again, it wont update until you logout and log back in
<clever> while building the first time, it respects the current $NIX_PATH and -I flags
<clever> but, that will only take effect after it has built
<clever> veleiro: in your case, nix.nixPath = [ "nixpkgs= yeah that
<clever> veleiro: a list of things, the same `-I thing` you can do on the cli, or do `export NIX_PATH=thing:thing:thing`
<clever> _habnabit: hmmm, you could maybe use fileSystems."/".options = [ "ro" ];
<clever> moet: the issue i linked is how to install remotely, and make the very first generating be what nixops made, so you can skip that dummy generation
<clever> moet: yeah, it wont work right, because nixops expects the state in / to persist, and be the final system
<clever> _habnabit: /nix is part of /, so you have stuff outside the store, sudo ncdu -x /
<clever> _habnabit: can you pastebin the `du -h --max=1 /nix ; df -h /nix` output?
<clever> _habnabit: which filesystem?
<clever> yep
<clever> _habnabit: run --query --roots on both versions, how do the roots differ?
<clever> _habnabit: next up, find a random fat thing in /nix/store (ncdu -x /nix/store), and then run `nix-store --query --roots` on it, to find out why its rooted
<clever> _habnabit: something has changed since boot (but not nixpkgs), so you still have 2 profiles rooted, but they likely share a lot
<clever> what does `ls -l /run/{booted,current}-system` print?
<clever> if ran as root, that includes system
<clever> `nix-collect-garbage -d` can only affect profiles you have +w to
<clever> for nix-env, you can then use the normal --list-generations and --delete-generations flags
<clever> there is also the `nix-collect-garbage -d` flag
<clever> _habnabit: nix-env --profile /nix/var/nix/profiles/system
<clever> moet: you want to manually run steps 1/2/3/4 in https://github.com/NixOS/nixops/issues/1189
<clever> moet: one minute
<clever> moet: nixops expects it to copy to / not /mnt/ on the remote end, so it cant deploy to the livecd
<clever> moet: oh right

2020-08-12

<clever> and boom, your allowed in
<clever> so you can just paste in your own username, and > ~/.ssh/authorized_keys
<clever> moet: this returns every pubkey that github believes i own
<clever> [clever@amd-nixos:~]$ curl https://github.com/cleverca22.keys
<clever> there is another trick you can use
<clever> ah
<clever> that key will work, for the first deploy
<clever> or use your main ~/.ssh/id_rsa
<clever> once it successfully deploys once, it will think the key works, and try using it
<clever> 66 if res == 0:
<clever> 67 self._ssh_public_key_deployed = True
<clever> 64 def switch_to_configuration(self, method, sync, command=None):
<clever> moet: none.sshPublicKeyDeployed hasnt been set yet, so nixops believes the key is of zero use
<clever> 35 _ssh_public_key_deployed = attr_property("none.sshPublicKeyDeployed", False, bool)
<clever> 83 return super_state_flags + ["-o", "StrictHostKeyChecking=accept-new", "-i", self.get_ssh_private_key_file()]
<clever> 82 if self.vm_id and self.cur_toplevel and self._ssh_public_key_deployed: