<clever>
so a dedicated option exists for path, that knows how to merge
<clever>
the issue, is that systemd.nix adds some default things to PATH, so the normal Environment.PATH cant be set, since the whole Enrivonment key lacks merge rules
<clever>
yorick: fetchTarball requires it to be in the allowed-uris option in nix.conf
<clever>
yorick: ifd is allowed, but the inputs are still bound to the normal sandbox rules
<clever>
yorick: hydra is always in restricted mode
<clever>
Taneb: you can -e 'trace=!select' to hide that
<clever>
Taneb: thats normal, its waiting up to 1 second for events on fd 5
<clever>
and they are doing -qa, which nix-build doesnt support
<clever>
jomik: that is why restricted eval was on
<clever>
--option restrict-eval true
<clever>
just use plain nix-build
<clever>
that will ruin your disk usage
<clever>
jomik: and you shouldnt be using nix-env when doing testing or ci type things
<clever>
jomik: why is restricted mode enabled?
<clever>
jomik: -I cant take search paths like <foo>
<clever>
ah, i was thinking about how aws's hypervisor handles things, but packet is baremetal
<clever>
Taneb: find the pid's for nix-serve, and run `strace -p pid1 -p pid2 ...` and then see what happens when you curl it
<clever>
Taneb: what does `top` look like?
<clever>
yorick: what IP does that domain have?
<clever>
yorick: there may be seperate code to enforce your mac having the ip you should have
<clever>
rauno: source ip
<clever>
sphalerite: careful, it might umount everything, just to spite you!
<clever>
and either ack or nak depending on if you find it
<clever>
basically, you need to write the size of the firmware to a special /sys entry, then the blob itself, and do it in response to a hotplug event thing
<clever>
so i could get wifi in my custom initrd
<clever>
sphalerite: i once wrote bash scripts to deal with firmware loading
<clever>
> udev
<clever>
i would use udev, but systemd ate it :P
<clever>
sphalerite: devtmpfs is a special kernel fs to auto-create them
<clever>
sphalerite: run `bluetoothctl` and then `show`
<clever>
so if the hardware lacks the ability to be ab HFP client, then you can never use a bluetooth headset in HFP
<clever>
sphalerite: bluetooth is still a bit of a mystery to me, from what ive seen, the dongle in the computer needs to support every profile you want to use
<clever>
sphalerite: journal?
<clever>
sphalerite: weird, are you using pulse full?
<clever>
sphalerite: the laptop can connect, claiming to be a headset, and then it routes all audio into pulse!
<clever>
sphalerite: ive also noticed fun things a laptop can do to bluetooth on phones
<clever>
sphalerite: i ran blueman-manager, connected it as a hands free device, and it instantly appeared in pavucontrol, in the HSP/PFP profile, and is an input device
<clever>
sphalerite: let me fetch some of my BT devices and see what happens
<clever>
info*
<clever>
__monty__: more into in #haskell.nix
<clever>
__monty__: you would either need to somehow force the version of Cabal earlier in the overlay setup (causing ghc to rebuild), or use angerman's haskell.nix stuff to allow overriding anything that was builtin with the old system
<clever>
sphalerite: thats strange
<clever>
__monty__: any attempt to force it will lead to eratic failures, due to 2 Cabals being present
<clever>
__monty__: Cabal cant be overridden, because its one of the builtin packages
<clever>
sphalerite: nothing on the input devices tab for both modes?
<clever>
sphalerite: but the HSP/HFP should have a mic
<clever>
sphalerite: there are seperate profiles for music (stereo, but no mic) and phone usage (mono, both directions), the profile also changes the samplerates for the playback channel
<clever>
sphalerite: check the profiles on the configuration tab
<clever>
samrose: looks like i never put that eclipse plugin on github, its likely in one of my backups of backups of backups, lol
<clever>
__monty__: call .override on each thing you want to affect
<clever>
yeah, ive only used it for java based projects
<clever>
i even wrote my own custom eclipse plugin to fetch backtraces from my server, display them in the editor, and let me click on any stack frame to jump to that line in the code
<clever>
samrose: i found the android ui editor in eclipse to be good 90% of the time
<clever>
so: journalctl --root=/mnt/ -u nixos-upgrade
<clever>
Takes a directory path as an argument. If specified, journalctl will operate on journal directories and catalog file hierarchy underneath the specified directory instead of the root directory (e.g. --update-catalog will create
<clever>
--root=ROOT
<clever>
bsima1_: one second
<clever>
ah
<clever>
angerman: you will need at least the hash of the hackage index at that given time, and that hackage index would need to contain the hashes of the cabal files and source tars
<clever>
angerman: this will recursively fetch repos, parse the DEPS file in the root of each, and generate an attrset of fixed-output derivations, then generate a runCommand that copies them all into one dir
<clever>
nix-hash, without --flat, gives you the recursive hash
<clever>
outputHashMode = "recursive" means you are giving the hash of the nar archive of $out (it can be a file, dir, or symlink)
<clever>
outputHashMode = "flat" means that you are giving the raw hash for the $out file
<clever>
outputHashAlgo is usually sha256, but something like yarn2nix can just copy the hash&algo from yarn.lock, and not even fetch things when translating
<clever>
angerman: then it is a fixed-output derivation, and gains network access
<clever>
angerman: basically, if a derivation has the following attributes: outputHash, outputHashAlgo, outputHashMode
<clever>
you can also use a custom fetch function
<clever>
fetchzip will use recursive hashing, so $out can be a dir, and you can just rm the unpredictable bits
<clever>
although, fetchurl uses flat hashing, so $out must be a single file
<clever>
i have even seen a fixed output derivation that will abuse hash collisions, to get 2 different values from the same hash
<clever>
angerman: all nix cares about, is the hash at the end, so as long as you can reproduce that hash, the build will "pass"
<clever>
catern: i guess since the cross-compiled libs are always x86->arm cross-compile (changing that changes the $out hash), you could just put native x86 binaries into its bin/ folder
<clever>
catern: and then you have the mess of getting the x86 version of the binary to know where to even find the arm libs
<clever>
camsbury: nix-serve doesnt support upload, so all uploads would bypass it and use the ssh:// protocol
<clever>
QT for example, has both a qmake binary (acts like cmake), and the libs, and you need to mix arches, and teach qmake where to find the target libs
<clever>
i'm still not sure how cross-compiling is meant to work for things like that
2019-05-07
<clever>
tank/nix 98G 92G 6.3G 94% /nix
<clever>
Filesystem Size Used Avail Use% Mounted on
<clever>
[root@system76:~]# df -h /nix/
<clever>
OmnipotentEntity: yep
<clever>
OmnipotentEntity: out is a bash level variable, not a nix level variable
<clever>
looks like they used 1000 when calling it "500gig"
<clever>
Disk /dev/nvme0n1: 465.8 GiB, 500107862016 bytes, 976773168 sectors
<clever>
ottidmes: my main dev laptop has a `465.8G` nvme (as seen by lsblk) and it runs nixos, and has some vbox VM's for ubuntu and windows 7
<clever>
`foo = compiler: pkgs.${compiler}` is also lazy, but when you `foo "doesnotexist"` your eval'ing it, and see the failure
<clever>
i think the problem is that `foo = pkgs.does.not.exist` is lazy, and will fail when you try to eval foo later
<clever>
`foo "ghc844"` also works for me
<clever>
fresheyeball: can you double-check that?
<clever>
fresheyeball: yet the 1st form doesnt work for me
<clever>
error: attribute 'ghc843' missing, at (string):1:1
<clever>
gchristensen: you could bake the init= into the initrd itself, with a bit of unsafe discard context
<clever>
gchristensen: the current netboot image also generates an ipxe script that handles it for us, but .... hmmm
<clever>
,libraries eraserhd
<clever>
Ralith: there is also the xorg half of things, i'm not sure how to update it
<clever>
that driver came from within the linux source, so you would have to apply an override to linux itself to update it
<clever>
Ralith: now run realpath on that
<clever>
Ralith: what does modinfo say about it, where is the file located?
<clever>
Ralith: thats the only way to use a gpu
<clever>
Ralith: which kernel driver are you using?
<clever>
Ralith: not sure, try without and see what breaks?
<clever>
Ralith: hardware.openGL.package doesnt change the kernel side any
<clever>
yes
2019-05-05
<clever>
lopsided98: i belive the stdenv runs substituteAll over it
<clever>
lopsided98: the thing with setupHook = ./foo; will get @out@ replaced by $out's value, when its copied into $out/nix-support/
<clever>
ah, there it is
<clever>
> cmake.setupHook
<clever>
check the cmake source
<clever>
> cmake.meta.position
<clever>
and it will be copied to the right spot for you
<clever>
i think mkDerivation also accepts a setupHook = ./hook.sh;
<clever>
i think its a buildEnv of drivers and something else
<clever>
Ralith: if you only put your override into hardware.opengl.package, you can avoid the mass-rebuild it would otherwise cause
<clever>
Ralith: ive set that option before to use a variant of libGL with debug symbols
<clever>
its an internal thing, so the docs omit it
<clever>
ambro718: yeah, it will try to copy the libs into the initrd, and if it cant copy just the libs, it will just copy the entire closure
<clever>
mog: du -h --max=1 /nix/store/ | sort -h
<clever>
eeeh, without the e on pie, lol
<clever>
maurer: many years ago, i made a program that used shm to share some cache structures between many procs, and the pie structures where fun to work with
<clever>
but few apps actually use it properly
<clever>
then restore it later
<clever>
i also like how you can serialize the state of an app and terminate it
<clever>
MichaelRaskin: i liked that you need a special gid to use network, but modern android doesnt even bother asking for net perms when installing
<clever>
setuid binaries become an issue though
<clever>
and chroot can be done without root, by just pulling off a mitm attack on the fs channel
<clever>
then it returns handles to you
<clever>
and you ask it to open files over an rpc
<clever>
what if the filesystem was just an open handle you get passed as fd#4 ?
<clever>
something ive thought of, is that you can pass open file handles over a unix socket
<clever>
pie_: nix-store --optimize, will also hardlink all dups between things
<clever>
it would be best if you can build from a read-only $src, but a lot of things dont play nicely with that