<clever>
duairc: but, then it wont work via nix-build && ./result/bin/foo
<clever>
duairc: propagatedUserEnvPkgs is an ugly hack, that will force nix-env&friends to force-install the thing along side your thing
<clever>
duairc: propagatedBuildInputs only gets added to the PATH of other derivations, during build time, and wont show up at runtime
<clever>
duairc: most of the wrapProgram based things are problematic, because you have to force any program linking into your lib, to wrapProgram properly
<clever>
duairc: that would be the best option i find
<clever>
wormwood: it looks more like you just installed it with nix-env, without sudo
<clever>
nix-env wont update when you nixos-rebuild
<clever>
the nixos module installs the same version of both, to the system profile
<clever>
the version of the drivers and client app must match
<clever>
wormwood: remove it from nix-env, on all users
<clever>
wormwood: thats the problem, you have 2 copies of vbox installed, and they are conflicting
<clever>
wormwood: what happens if you run `type VirtualBox`?
<clever>
evils: yeah, the problem is that debian config files break it
<clever>
evils: on nixos or debian?
<clever>
rossabaker: pam stuff usually also needs to be setuid root, most of the time, and nix cant easily do that on its own
<clever>
rossabaker: or patch nixpkgs, to obey the debian pam configs
<clever>
rossabaker: it reads everything in /etc/pam.d
<clever>
rossabaker: blame debian for running a fork of pam that isnt compatible
<clever>
rossabaker: so all pam based programs in nixpkgs will fail
<clever>
rossabaker: nixos pam doesnt support @include, only debian based pam does
<clever>
then `nix-channel --update` to apply the removal
<clever>
gwen: you added a nixos channel to both your user and root, remove the duplicate with `nix-channel --remove nixos` (without sudo)
<clever>
,stateVersion
<clever>
tokudan: is this on baremetal or a vm?
<clever>
> builtins.attrNames builtins
<clever>
tetdim: builtins.attrNames builtins
<clever>
tetdim: what does your repl say 5-4 is?
<clever>
tetdim: it shouldnt
<clever>
> pkgs.fetchGit
<clever>
tetdim: pkgs only exists if you `nix repl '<nixpkgs>'`
<clever>
> pkgs.fetchgit
<clever>
> builtins.fetchGit
<clever>
tetdim: case sensitive
<clever>
tetdim: Git vs git
<clever>
tetdim: builtins.fetchGit vs pkgs.fetchgit
<clever>
tetdim: fetchgit is from pkgs
<clever>
tetdim: fetchGit is the builtin
<clever>
tetdim: given what youve got built, the error may surprise you
<clever>
tetdim: what is 5-4, in `nix repl`
<clever>
tetdim: id say start with `nix repl` and see if the basics even exist then
<clever>
tetdim: ?
<clever>
tetdim: ninja is a tool to run the compiler, not a compiler, not a linker
<clever>
tetdim: ldd isnt a linker
<clever>
tetdim: is it being passed to the linker? which linker? what flags?
<clever>
literon: b: change ci to use a predictable name
<clever>
literon: a: move that directory to a subdir of your repo, so the name is stable
<clever>
AmandaC: ^^^
<clever>
If this option is disabled, then no GPU devices will be added from the udev backend. Enabled by default. (May need to be disabled to setup Xinerama).
<clever>
Option "AutoAddGPU" "boolean"
<clever>
literon: use builtins.filterSource instead
<clever>
AmandaC: you have no way to move a window between monitors, and little way to run an app on 2 monitors at once!
<clever>
AmandaC: and you must mess with $DISPLAY to change which window an app opens on
<clever>
AmandaC: with xinerama off, you have :0.0, :0.1, :0.2 and so on
<clever>
AmandaC: i heavily suspect chromium is built without xinerama, because it cant share 1 monitor, it likely doesnt know where a monitor starts&ends
<clever>
AmandaC: a window manager typically needs xinerama, to maximize to a single window
<clever>
AmandaC: second, an application must use xinerama api's, to learn where the monitors are within :0.0
<clever>
AmandaC: first, xorg treats all monitors as a single x11 display (just :0.0, no :0.1)
<clever>
AmandaC: there are 2 parts to xinerama
<clever>
AmandaC: xinerama is what lets you drag a window between 2 different monitors
<clever>
back when xinerama was still new and not the default!
<clever>
wucke13: ..... i memorized the xorg.conf options, before wayland was even an idea, lol
<clever>
AmandaC: and i dont expect cmdline args on the 10th and 15th pages
<clever>
AmandaC: what confused me though, is the nix man pages, it looks like several man pages just got mushed together, and so i skim the first page for cmd line args
<clever>
wucke13: yeah, it would be nice to be able to toggle those options
<clever>
wucke13: nixos has an option to toggle this, but hard-codes AllowMouseOpenFail to on
<clever>
sequences have no special meaning and are passed to clients. Default: off.
<clever>
This disallows the use of the Ctrl+Alt+Keypad-Plus and Ctrl+Alt+Keypad-Minus sequences. These sequences allows you to switch between video modes. When this option is enabled, those key
<clever>
Option "DontZap" "boolean"
<clever>
wucke13: unlike iqubic, i devour man pages for breakfast, and even a decade later, little options i never use (like AllowMouseOpenFail), stick around, lol
<clever>
wucke13: i think this is the main option that would prevent such failures
<clever>
This tells the mousedrv(4) and vmmouse(4) drivers to not report failure if the mouse device can't be opened/initialised. It has no effect on the evdev(4) or other drivers. Default: false.
<clever>
iqubic: things tend to break if you dont enable xserver, but do enable a desktop manager
<clever>
iqubic: try it!
<clever>
iqubic: you mus still set services.xserver.desktopManager.gnome3.enable=true; to install all of gnome3
<clever>
iqubic: try what wucke13 gave you first
<clever>
wucke13: then it will just hard fail, rather then leaving you in a trap
<clever>
wucke13: usually, xorg will suicide if it cant find any input devices
<clever>
wucke13: the nixos config you gave iqubic
<clever>
iqubic: did you try it?
<clever>
2019-10-11 20:36:37 <@clever_> 2019-10-11 20:35:15 < AmandaC> clever: ... I may have stumbled upon how to make your qemu stuff work again. I did the wrong flag when I did the `-D...` change -- it wants `-Ddefault_library` instead of `-Ddefault-library` -- it seems to
<clever>
gchristensen: nice
<clever>
nakkle: if things are signed by a key the remote end trusts, then you dont need to be a trusted user, but signing can be more tricky to configure
<clever>
gchristensen: nice, can clearly see how long it took to build, shutdown, and boot up again
<clever>
nakkle: remote builders typically also need hydra to push inputs the remote end lacks, and pushing those inputs needs trust or signing
<clever>
nakkle: by default, all users can build things
<clever>
then its not PATH issues
<clever>
nakkle: what happens if you manually run `ssh user@build-slave nix-store --version` ?
<clever>
nakkle: any other errors nearby?
<clever>
nakkle: are you reading the jorunal for hydra-queue-runner?
<clever>
which means my `top` like app no loner works, it cant see other processes!
<clever>
modern android uses containers and namespacing
<clever>
each app in its own uid
<clever>
old android did it purely with unix permissions
<clever>
jophish: thats basically what android does
<clever>
mwelt: which is usually managed by nix-channel
<clever>
mwelt: $NIX_PATH
<clever>
mwelt: in <nixpkgs>
2019-10-14
<clever>
inkbottle: that will also expose nesting sudo, sh, and bash
<clever>
inkbottle: both nix-shell and nix run increment $SHLVL, so you could use an alternate PS1 that reveals $SHLVL
<clever>
and a whitelist shouldnt allow -1, so no issue there
<clever>
a lot of users are near-root power, and a blacklist is just a plain bad idea
<clever>
that just seems like a dumb way to set it up
<clever>
__red__: ahhh, its for when you allow somebody to run x as anybody-but-root
<clever>
for me, it asks for the normal pw before running the thing as root
<clever>
selfsymmetric-pa: automake now
<clever>
,locate bin aclocal
<clever>
selfsymmetric-pa: ~/.stack/config.yaml can make nix the default
<clever>
stack only obeys that if you use `stack --nix`