2017-04-15

<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> gattler: then you can use just .override
<clever> gattler: just make an override that sets patches = [ ./foo.patch ];
<clever> you may need to delete some data first to make it work, try a nix-collect-garbage without sudo
<clever> that usualy fixes it
<clever> try the rebalance command first
<clever> Jookia2: https://btrfs.wiki.kernel.org/index.php/Problem_FAQ#I_get_.22No_space_left_on_device.22_errors.2C_but_df_says_I.27ve_got_lots_of_space
<clever> can you gist the output of mount;df -h;df -i
<clever> Jookia: what does df -i say?
<clever> for the 2nd derivation, that is using the new simgrid
<clever> in the default.nix for the thing your building with nix-shell
<clever> you can do this outside of nixpkgs
<clever> then you can run nix-shell without -I
<clever> sophiag: that lets you load the new simgrid default.nix, outside of the nixpkgs its contained within
<clever> sophiag: you can also do let simgrid = pkgs.callPackage /path/to/simgrid/default.nix {}; in stdenv.mkDerivation .... simgrid
<clever> try changing that to off and see what happens
<clever> see on line 33 of simgrid/default.nix, it has enable_ns3=on
<clever> not sure what the next step would be for that
<clever> looks to be python based
<clever> so we can either disable ns3 support in simgrid, or package ns3 first
<clever> doesnt appear to be packaged on nixpkgs
<clever> message(STATUS "Warning: To use NS-3 Please install ns3 at least version 3.10 (http://www.nsnam.org/releases/)")
<clever> doesnt look like its perl
<clever> not sure which package ns3 is in
<clever> change the lua5_1 to lua5_3
<clever> sophiag: you must add python3 to the list of buildInputs in the simgrid/default.nix
<clever> that would taint things
<clever> nix will never look at what you have "installed" when doing nix builds
<clever> can you gist the output of "git diff"
<clever> with what error?
<clever> the new hash it prints should be totally different
<clever> just increment or decrement any digit
<clever> yah
<clever> nix has a bit of a problem if you change the url but keep the same name at the end
<clever> i do mean that hash
<clever> yes
<clever> so it knows to re-fetch things
<clever> you need to change a single digit in the hash
<clever> Error: Lua version 5.3 is required, but version . found instead.
<clever> my attempts at changing the version# are having python and lua problems
<clever> so you built a copy of 3.11, but just called it 3.15
<clever> and it gave you a copy of 3.11
<clever> i suspect the 33686 is related to the version
<clever> what url did you use?
<clever> sophiag: did you have to do anything with python when updating the simgrid version?
<clever> sophiag: one min
<clever> sophiag: is the app your trying to build available as a url somewhere?
<clever> sophiag: what does 'which smpicc' say when ran in the nix-shell?
<clever> yeah, thats the only thing a gc can fix
<clever> a gc will never fix a problem
<clever> and nix will get exactly that version
<clever> you must tell nix which version you want
<clever> the different versions can co-exist without ever conflicting
<clever> the entire design of nix is such that you never have to get rid of old things
<clever> no you dont
<clever> sophiag: you need to nix-shell -I nixpkgs=/home/clever/nixpkgs to force it to use the modified version
<clever> sophiag: and nix-shell will always use the one you reference, which defaults to the un-modified one in nix-channel
<clever> sophiag: due to how nix works, you can have dozens of different simgrid's "installed" at once
<clever> ran in the root dir of a nixpkgs checkout
<clever> nix-build -A simgrid
<clever> run nix-build without fixing the hash, and nix will tell you the correct value
<clever> and fix anything else that may break
<clever> bump up the version# and fix the hash when nix complains
<clever> yeah
<clever> and the 3.11 branch doesnt
<clever> at least in the version 3.11.1 i have
<clever> simgrid has no msg.h in simgrid/
<clever> its in <msg/msg.h>
<clever> what #include path are you using?
<clever> or you can give a path to the default.nix to nix-shell
<clever> no, but you can freely use cd after nix-shell
<clever> yep
<clever> then create one
<clever> you must still use nix-shell to get the headers into scope
<clever> sophiag: put this into default.nix in the root of your project, then run nix-shell and you will get a shell with gcc and simgrid
<clever> sophiag: then you want the mkDerivation in its own file
<clever> sophiag: you can then use the file i just linked as an example for building your own
<clever> nixos literaly has a package for hello world
<clever> one sec
<clever> or use the url if its already tar'd up
<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> fixed
<clever> oops, minor typo, fixing
<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> hyphon81: yeah, the R1 seems simpler for powering the drive: http://www.banana-pi.org/images/bpi-images/R1/r5.jpg
<clever> hyphon81: the R1 has a full data+power connector like a laptop, and you just slot the whole drive in
<clever> hyphon81: yeah, the R2 lacks the sata power connector, so you need an external supply that powers both the hdd and the R2
<clever> i need to force a single step to be done without any contention, and parallel the rest of the build
<clever> and it fights 3 other gcc's over it, and swaps for hours
<clever> and in the case of my rpi, if i make -j4 with a max of 1 job, and it hits glibc, a single task within that build needs ~3gig of ram
<clever> if you make -j96, and you hit a derivation that lacks enableParallelBuild = true;, it will waste time on 1 core
<clever> ive also found ram and other things to complicate the problem
<clever> nalice: http://www.banana-pi.org/m2u.html real sata and ethernet on this board
<clever> gchristensen: the R2 also have mini-pcie!
<clever> just a standard office powerbar with a switch on it
<clever> and one day, he stepped on a power bar and cut power to half the rack
<clever> and they did have a homebrew watercooled server mounted OVER the petabyte storage array
<clever> i think they have internal battery backup
<clever> i am seeing a lipo connector on a lot of these
<clever> yeah, depends on if your wanting a router or a nas
<clever> gchristensen: http://www.banana-pi.org/m2u.html another model, without the 5 ethernet ports
<clever> i had it shipped to a friend in america, and then we had shipping complications and i wound up picking it up when i flew down to bayhac
<clever> cant remember how much it was, too forever to get it into canada
<clever> it just needs a partition table, kernel, initrd, and rootfs, and it should be good to go
<clever> gchristensen: and i have nixpkgs u-boot running on it: https://gist.github.com/cleverca22/8ff5bd6a322c45f5a3bf7e6109e03e7a
<clever> gchristensen: dual core 912mhz, proper sata, proper gigabit ethernet
<clever> gchristensen: have you seen this board i'm looking into? http://www.banana-pi.org/r1.html
<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> lol
<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> joko_: init=/nix/var/nix/profiles/system/sw/bin/bash
<clever> are you able to take a screenshot of the error?
<clever> hyphon81: and the docs say that the zfs_force=1 should only be done once
<clever> and boot.supportedFilesystems = [ "zfs" ]; isnt required because nixos just figures that out via fileSystems."/" on its own
<clever> boot.loader.grub.zfsSupport isnt required, because your /boot is ext4
<clever> hyphon81: at a glance it should work, but i suspect the extra / in rpool/root/nixos may confuse some scripts
<clever> hyphon81: can you gist the configuration.nix and hardware-configuration.nix and also the output of "zpool history"
<clever> got the names mixed up
<clever> ah
<clever> calvertvl: and also the output of "zpool history"
<clever> calvertvl: can you gist the configuration.nix and hardware-configuration.nix ?
<clever> calvertvl: do you know if the import error is coming from nixos or from grub?
<clever> not yet
<clever> but it had an error last time i tried, havent debugged it fully yet
<clever> i'm using the same key to cover both swap and root, so in theory, it should be able to hibernate
<clever> thats a problem when the swap has a new key every time it boots
<clever> so i used lvm to split the luks between zfs and swap
<clever> but i know swap on zfs is a problem
<clever> i wanted swap on the luks
<clever> as long as the luks is also configured correctly
<clever> the above even works if the zfs is on lvm, and the lvm is on luks
<clever> this is enough for nixos to include zfs in the initrd, and find the pool on bootup
<clever> "/" = { device = "amd/root"; fsType = "zfs"; };
<clever> fileSystems = {
<clever> calvertvl: nixos will juat automaticaly include zfs in the initrd if you set a filesystem type to zfs
<clever> hyphon81: ive only ever done zfs booting with an ext4 /boot partition, and it just works for me
<clever> a month ago it wasnt, havent heard any update yet
<clever> matthewbauer: they are on the binary cache now, and hydra isnt aware of that
<clever> 2017-03-20 12:45:56 < niksnut> if you urgently need a log, you can find them at URIs like: https://cache.nixos.org/log/l9qmwi2q0dk4ji8pcycc188gank0q5pb-pointedalternative-0.1.0.0.drv
<clever> yeah
<clever> . .. passwords.txt
<clever> sophiag: and glibc is already in the buildInputs
<clever> sophiag: its in glibc, sys/msg.h
<clever> sophiag: by default, locate will ignore /nix/store, so that would never have worked the way you wanted
<clever> sophiag: what package is msg.h usualy in?

2017-04-13

<clever> sophiag: it may still be updating, check top
<clever> sophiag: that would be updatedb scanning everything in the system
<clever> sophiag: journalctl -f -u update-locatedb.service
<clever> sophiag: systemctl start update-locatedb
<clever> sophiag: you need to start the updatedb.service in systemd, not run updatedb directly
<clever> copumpkin: sounds like the db.sqlite import faked all the hashes
<clever> and turns the linux kernel into a linux app
<clever> it basicaly takes qemu out of the loop
<clever> usermode linux
<clever> MichaelRaskin: i think i recently did one with just ARCM=um make menuconfig, id have to check again
<clever> MichaelRaskin: i have built and used uml before, but the nixos build framework complicates that
<clever> bitonic: this runs a service every hour on the hour: https://github.com/cleverca22/nix-tests/blob/master/kexec/configuration.nix#L53-L57
<clever> gchristensen: did you see the above link?
<clever> gchristensen: *ping*
<clever> copumpkin: head out now
<clever> so it has to pass a spec file to gcc, and the musl-gcc script handles that
<clever> musl both replaces the libc.so, and the interperter
<clever> nope, dont see anything in adapters.nix
<clever> copumpkin: forgot to check those, *looks*
<clever> copumpkin: yeah and there is currently no way to change it
<clever> copumpkin: and we did find a PR you made, https://github.com/NixOS/nixpkgs/issues/6221
<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
<clever> copumpkin: http://linux-sunxi.org/BROM
<clever> thats why the ubootBananaPi package is broken
<clever> copumpkin: it appears to be using the x86 gcc with -march=armv5
<clever> i could also potentialy patch u-boot to cut things off much sooner in the bootup
<clever> so its less likely to cause an issue
<clever> in the case of my isp, the dhcp is locked to a given mac, and nothing else can get an ip until that expires