<clever>
/nix/store/a759kbr0kgccsxl6lfx0xv5i3c9x9bw9-binutils-2.31.1/bin/ld: ../emu/libtilemcore.a(graycolor.o): undefined reference to symbol 'pow@@GLIBC_2.29'
<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
<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>
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>
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>
_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>
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