<clever>
gchristensen: any vu meters moving in pavucontrol?
<clever>
gchristensen: oh, and often, there is a mute in alsamixer that has to be switched off after a fresh install, i think f7 to bypass pulse and control the card directly
<clever>
gchristensen: so you may need to replug the headphones while its running
<clever>
gchristensen: ive found that pulseaudio can detect changes in the headphone state, but not the current state
<clever>
gattler: nix-store -r /nix/store/foo will download things from the binary cache
<clever>
or use absolute paths
<clever>
yeah
<clever>
gattler: if you do ./upgrade.patch, it will look for it in the same directory as the nix file containing that
<clever>
and then it will build the source in that directory
<clever>
then src = /home/sophiag/yourthing;
<clever>
ah
<clever>
what is the url to that?
<clever>
are you trying to compile something that uses simgrid?
<clever>
what exactly do you need simgrid for?
<clever>
depends a lot on what you want done
<clever>
probably
<clever>
yeah
<clever>
but if you want to build something that uses simgrid headers, you must build that something inside a derivation, that has simgrid in its buildInputs
<clever>
since its already packages, you just want to put simgrid directly into the systemPackages
<clever>
there is no src attribute in the derivation you defined
<clever>
variable $src or $srcs should point to the source
<clever>
building path(s) ‘/nix/store/6rjljxaaia6ks6vx6fsbl9vgw9vp6i7f-simgrid’
<clever>
with the errors
<clever>
can you gist the entire output?
<clever>
could remove it and see what happens
<clever>
sophiag: that just means something you put into systemPackages failed, likely the simgrid2
<clever>
sophiag: keep scrolling up more
<clever>
read the lines above to find out why
<clever>
but you could just wrap the whole thing in (...) and insert it directly into systemPackages for maximum unreadability
<clever>
that calls pkgs.stdenv.mkDerivation on an attribute set, and stores the result in a local value called simgrid2, which then gets inserted into systemPackages
<clever>
it can also be done in one file, but not like that
<clever>
that belongs in its own file, not configuration.nix
<clever>
oh wait, line 134 is totally wrong
<clever>
sophiag: its possible your nix channel is too old, what does nix-channel --list say?
<clever>
the file your editing that references simgrid
<clever>
sophiag: can you gist the default.nix file?
2017-04-14
<clever>
you should never have to put dependencies into systemPackages or nix-env -i
<clever>
yeah
<clever>
if you add simgrid to the buildInputs and run nix-build, it will just find the headers
<clever>
systemPackages will also ignore header files
<clever>
the headers will only be available inside nix-build and nix-shell
<clever>
thats how nix works
<clever>
when you install anything with nix-env -i, it will ignore the headers
<clever>
sophiag: what package is missing what files?
<clever>
make a default.nix with something like this: with import <nixpkgs> {}; stdenv.mkDerivation { name="foo"; buildInputs = [ boost ]; src = ./.; }
<clever>
yeah
<clever>
sophiag: just add boost to buildInputs and it should work
<clever>
sophiag: boost-test is inside the main boost package
<clever>
boxofrox: should be as simple as just setting the shell to "/run/current-system/sw/bin/false" i believe
<clever>
ixxie: yeah, i'm still learning haskell as well, had some help from dmj` and taktoa when writting that part of it
<clever>
ixxie: a different minimal os i threw together in one night
<clever>
ixxie: so the haskell prog gets ran as pid 1 at bootup, and that does everything
<clever>
ixxie: the gist i linked replaces the entire OS with a single haskell binary
<clever>
i have had many problems with NBD before, but not much with iSCSI
<clever>
gchristensen: his april fools video involved using hairspray to blast a flame thrower out of the data closet air vent and faking a server "room" fire, lol
<clever>
nalice: i have recently been considering using an NVME drive as an L2ARC in my NAS
<clever>
ToxicFrog: lists in nix are picky
<clever>
ToxicFrog: needs another ( and ) around the whole function call
<clever>
MichaelRaskin: yeah, the power of nixos also makes many things harder
<clever>
pie_: those binaries would have to be secured to never reveal the key
<clever>
benley: so if all of the binaries are un-modified, the same series of hashes gets written to the tpm, and you can unlock the key for decrypting the hdd
<clever>
benley: and when grub loads linux, it writes hash(linux) to the tpm
<clever>
benley: as a crude example, when the bios runs grub, the hash(grub) gets written to the tpm
<clever>
benley: i believe it works by having each stage of the bootloader writing the hash of the next stage to the TPM, as it boots
<clever>
benley: one thought is TPM measured boot
<clever>
attempting to revoke that key would brick every install cd out there
<clever>
benley: they forgot to remove a debug feature, and now the core secureboot key for M$ is useless :P
<clever>
benley: and given how easily you can rebuild kernel modules in nix, good luck signing those
<clever>
benley: for this reason, MS demands that all signed code will only ever execute code that has also been signed
<clever>
benley: and that custom module could then re-boot the entire OS under a hypervisor, and claim secureboot is working, but spy on everything
<clever>
benley: and as an example, if you have a signed grub, signed linux kernel, but dont have signed kernel modules, an attacker could insmod a custom module, that now has ring0 and hijacks the machine
<clever>
benley: but if somebody can yank out the hdd and run it in a vm, or modify the bios config, your hosed
<clever>
benley: everything relies on the bios not being reconfigured to disable secureboot
<clever>
benley: its just a function in the EFI that returns boolean and has no security checks on it
<clever>
benley: another thing to keep in mind, if somebody does bypass secureboot, they can trivialy lie to your OS and say secureboot is still enabled
<clever>
pie_: plus powernowd, that monitors cpu usage and writes orders into /sys
<clever>
pie_: when i first saw cpufreq, there was no kernel governers, only a userland governer
<clever>
gchristensen: 48 cores isnt a normal machine, lol
<clever>
pie_: i think that depends more on the hardware
<clever>
plumps: not sure why it would be doing that
<clever>
ToxicFrog: you will loose some of the perl man pages, but not the std-man-pages
<clever>
ToxicFrog: perl may have added that manpage recently
<clever>
nalice: if /boot is on a different filesystem, it should automaticaly copy
<clever>
ToxicFrog: oh, thats because both perl and std-man-pages provide the same man page
<clever>
ToxicFrog: but that wont cover doc and devdoc, i dont see those in defaults
<clever>
plumps: and your running nix-channel as the plumps user?
<clever>
plumps: and double-check nix-channel --list
<clever>
plumps: did you nix-channel --update after deleting it?
<clever>
ToxicFrog: if programs.man is enabled, man will already be in that config
<clever>
i think i have zfs on 5 systems right now
<clever>
hyphon81: your welcome :)
<clever>
and you can rerun nixos-install without any data loss (makes it much much faster), just mount everything back to the right spot under /mnt, edit the config, nixos-install
<clever>
it may also be possible to force it to boot if you dont have the cd anymore
<clever>
try setting boot.zfs.devNodes = "/dev"; in configuration.nix and then re-run nixos-install
<clever>
yeah, thats probably it then
<clever>
now check inside /dev/disk/by-id with ls
<clever>
hyphon81: the nixos scripts assume your zfs devices will be within /dev/disk/by-id, but they might not be
<clever>
hyphon81: i suspect the problem is boot.zfs.devNodes
<clever>
hyphon81: can you use e to edit the kernel params at grub, and add "boot.shell_on_fail" to the end, then boot the modified config with f10?
<clever>
though i have gotten photos of monitors back from "professional" datacenters...
<clever>
just the fact that its not a camera reveals that
<clever>
hyphon81: imgur.com is one place you can upload images
<clever>
try that first and see what happens
<clever>
i think init=/bin/sh is the fastest way
<clever>
but /bin/bash doesnt exist on nixos
<clever>
joko_: stage1 should obey init=
<clever>
joko_: init=/bin/sh would also work, since the symlink probably still exists
<clever>
copumpkin: dmj and i have also been looking into stdenv.override { glibc = pkgs.musl; }
<clever>
ah
<clever>
what was the subject?
<clever>
loadng up the mailing list
<clever>
copumpkin: so i now have a u-boot that should be compatible witht he banana pi
<clever>
copumpkin: oops, wrong c name
<clever>
cpennington: yep, the uboot does appear to build, it has the right header at the start
<clever>
copumpkin: used nix-instantiate --argstr system armv7l-linux to get an arm .drv, then nix-copy-closure to get it into an arm, and nix-store -r to begin building it
<clever>
or with crossSystem fully configured
<clever>
copumpkin: i think the issue is that it doesnt force a cross-compile by default, and it only supports being built on a native arm box
<clever>
copumpkin: the u-boot derivation should contain the result of concating the SPL and u-boot