2017-12-05

<clever> -r--r--r-- 1 root root 4.0K Dec 5 18:29 /sys/module/amdgpu/parameters/dpm
<clever> joepie91: correction, amdgpu_dpm
<clever> module_param_named(dpm, amdgpu_dpm, int, 0444);
<clever> joepie91: and its bound to c variable called dpm in this file
<clever> amdgpu_drv.c:MODULE_PARM_DESC(dpm, "DPM support (1 = enable, 0 = disable, -1 = auto)");
<clever> [clever@amd-nixos:~/apps/linux/drivers/gpu/drm/amd/amdgpu]$ grep -r --color dpm | grep MOD
<clever> joepie91: source located
<clever> [clever@amd-nixos:~/apps/linux]$ find -name amdgpu
<clever> ./drivers/gpu/drm/amd/amdgpu
<clever> joepie91: ok, the source is inside the linux package
<clever> /nix/store/q7jkkkgvdv936qqf8wygzglrxqlbmfjl-linux-4.9.57/lib/modules/4.9.57/kernel/drivers/gpu/drm/amd/amdgpu/amdgpu.ko.xz
<clever> [root@amd-nixos:~]# realpath /run/current-system/kernel-modules/lib/modules/4.9.57/kernel/drivers/gpu/drm/amd/amdgpu/amdgpu.ko.xz
<clever> [root@amd-nixos:~]# modinfo amdgpu
<clever> filename: /run/current-system/kernel-modules/lib/modules/4.9.57/kernel/drivers/gpu/drm/amd/amdgpu/amdgpu.ko.xz
<clever> joepie91: and now for some fun kernel + nix debugging, can amdgpu.dpm be turned off at runtime!
<clever> joepie91: also, the default driver from a few months ago, it would vsync after every character in xterm, leading to horid draw rates
<clever> [root@amd-nixos:~/nixcfg]# modinfo amdgpu | grep dp
<clever> parm: dpm:DPM support (1 = enable, 0 = disable, -1 = auto) (int)
<clever> joepie91: the "ati" driver mostly works, but hard-locks if i unplug a monitor before disabling it
<clever> joepie91: the closed-source driver hard-locks if i enable any extra monitors
<clever> joepie91: amd-gpu has the random corruption in one area of the screen after a few months of uptime, and the machine hard-locks if i unplug a monitor
<clever> tokudan[m]: nix-repl '<nixpkgs>'
<clever> joepie91: amd-gpu now
<clever> joepie91: ive seen heavy signs of the gpu rendering tooltips before the buffer is filled, causing it to render undefined data
<clever> joepie91: ive been seeing memory corruption in the framebuffer that runs deep enough that i can capture it in a screenshot
<clever> joepie91: that sounds a lot like some of my things
<clever> !ping
<clever> joepie91: what are the symptons of those PM problems? i happen to have amd all over my box
<clever> keep the path as a path as long as possible, and you will import as little as possible
<clever> vcunat: but "${src + "/foo.txt"}" will import just foo.txt
<clever> vcunat: another fun thing with paths in nix, "${src}/foo.txt" will import all of the src
<clever> amd writeText is just another derivation that properly depends on it
<clever> sphalerite: readFile doesnt trigger the building, but import from derivation does
<clever> sphalerite: i think its that readFile doesnt force the derivation to build
<clever> sphalerite: what about builtins.readFile "${foo}" ?
<clever> writeScript puts the script directly into /nix/store and makes it executable
<clever> adamt: the issue, is that ExecStart needs an absolute path to an executable, but writeScriptBin returns the path to a directory containing "bin/executable"
<clever> adamt: oh, writeScript is probably better then writeScriptBin
<clever> adamt: but at this point, its probably simpler to just serviceConfig.ExecStart = pkgs.writeScriptBin "foo-start" "#!{pkgs.ruby}/bin/ruby ... ";
<clever> adamt: so you need to remove the .script option
<clever> adamt: but if you use .script, it will writeScriptBin it for you, and put that into ExecStart
<clever> adamt: if you use serviceConfig.ExecStart, then the .service file points directly to the thing you gave it
<clever> tilpner: things like the state of the pulseaudio flag, and the arch
<clever> tilpner: can you gist all of the expressions involved?
<clever> tilpner: what do you have in nixpkgs.config?
<clever> tilpner: are you building it with nixos-rebuild, nix-env, or nix-build?
<clever> its pretty powerful
<clever> have you played with jq before?
<clever> nice
<clever> tilpner: ah, you mean for pre-fetching the tip of a branch and making it pure
<clever> tilpner: why did it need ls-remote at all?
<clever> cant think of anything else then
<clever> same or different error?
<clever> Havvy: what about "nix-shell '<nixpkgs>' -A rustc" ?
<clever> have you tried using cargo2nix?
<clever> are you using a stdenv.mkDerivation ?
<clever> not sure then
<clever> ah, are you inside a nix-shell?
<clever> Havvy: what commands did you run to start cmake?
<clever> yeah
<clever> Wizek: i think it translates to the cabal flag --enable-library-profiling
<clever> Wizek:
<clever> Wizek: generic-builder.nix
<clever> angerman: yeah, those are better ones, things like acid state and lenses
<clever> angerman: ive had projects fail to build because the TH cant find the git executable at compile time
<clever> joepie91: using the nix store to cache pure operations
<clever> joepie91: when i got into nix, i was considering a game engine as an extension of nix, lol
<clever> joepie91: at that point your basically just rewriting php, lol
<clever> the compiler just invisibly treats that special object syntax as an extra arg
<clever> behind the scenes, thats pretty much what c++ did to c
<clever> which roughly gives you partial function application
<clever> joepie91: and it can also prefix arguments into the function call
<clever> joepie91: i was thinking more along the lines of bar.bind(foo) causing 'this' to point to foo when the returned function is ran
<clever> joepie91: i always use .bind to deal with that, yet ive delt with libraries before, that always took 2 arguments for every callback, the func, and the 'this'
<clever> lol
<clever> Sonarpulse: apple can have multiple arches in the same binary, and the runtime linker picks the right one
<clever> Sonarpulse: which is reminding me of how apple handles binaries
<clever> at that point, its simpler to just build every module twice, and transparently pick the right variant
<clever> Sonarpulse: which means building all of the deps twice
<clever> Sonarpulse: you still need to have a host build of that module available
<clever> Sonarpulse: half the problem, is that TH can access modules you import, and what platform did ghc compile those modules for?
<clever> Sonarpulse: ghcjs uses the out of process th under nodejs to deal with this issue
<clever> dhess: and then you can do cross-compiled TH without binfmt-misc
<clever> dhess: in theory, qemu-user can be used as an interperter for the TH daemon, the same way nodejs handles ghcjs TH
<clever> gchristensen: nice
<clever> gchristensen: wow
<clever> are
<clever> gchristensen: the above will also show what the fat deps
<clever> maybe |sort -h at the end
<clever> gchristensen: du -hc $(nix-store -qR path)
<clever> sphalerite: ive said that about 7am a few times this week :P
<clever> and then specializing it to the cpu at runtime
<clever> this is about using llvm IR for all applications
<clever> 2017-11-29 12:27:08 * dtzWill is using allexe-built terminal/shell/ssh/etc. to chat presently, many of which are JIT'd just because I can xD
<clever> tobiasBora: oh, and swapping those libraries out will also break anything refering to them
<clever> tobiasBora: you would also need to swap in all the libraries the gcc would be linking against
<clever> tobiasBora: and the whole design of nix relies on paths having been made by the script that was hashed to make the path
<clever> tobiasBora: all paths in the store are immutable, and must never be modified once built
<clever> so /nix/store/hash1-gcc and /nix/store/hash2-gcc
<clever> the hash is in the storepath
<clever> tobiasBora: if you change the gcc from a native to a cross-compiler, that affects the hashes in strings, and changes the $out
<clever> tobiasBora: then to make $out, it runs $builder with $args
<clever> tobiasBora: nix will then hash that entire set of builders, and use it to compute $out's path
<clever> tobiasBora: basically, in nix, you have a set of environment variables, 2 of them being special, $builder and $args
<clever> so nix treats each compiler as a seperate task, producing different outputs
<clever> more that nix doesnt understand 2 different compilers being capable of producing the same output
<clever> yeah
<clever> resulting in x86 libraries in your arm initrd!
<clever> if you use a dynamicaly linked qemu-user, then the arm ldd will spit out x86 libraries
<clever> ive even caused such impurities with qemu-user
<clever> tobiasBora: and there are impurities that would leak in if you tried to force it
<clever> tobiasBora: nix doesnt understand that part though
<clever> petersjt014[m]: also, if you want to use legacy booting on GPT, you must create a bios boot partition, about 1mb in size, no fs, dont mount it
<clever> petersjt014[m]: fdisk can also make gpt tables
<clever> the raspberry pi can do v6, v7, and aarch64
<clever> gchristensen: depends on the chip
<clever> LnL: arm can be made without 32bit
<clever> LnL: oh, and also, when you do 32bit builds under nixpkgs, it runs a 32bit build of gcc, so the cpu needs 32bit support
<clever> LnL: so when you do "nix-env -iA nixpkgs.hello" it asks for the natively built glibc, and has to rebuild everything all over
<clever> LnL: yeah, but that would be cross-compiling
<clever> LnL: it might be aarch64 only
<clever> not sure how that interacts with rust
<clever> gchristensen: seperateDebugInfo = true; i think
<clever> petersjt014[m]: you will also need to umount the drive before you repartition it, and any data on it will be lost
<clever> tobiasBora: fairly normal
<clever> petersjt014[m]: you would create the partition tables with "fdisk /dev/sda" then format it with "mkfs.ext4 /dev/sda1"
<clever> petersjt014[m]: you need to wipe the disk, make a partition table, and put the ext4 at sda1
<clever> so it wont boot
<clever> you can, but grub wont install to it
<clever> you formated sda as ext4, so there are no partition tables
<clever> grub cant be installed on such a setup
<clever> petersjt014[m]: you dont have any partition tables!
<clever> petersjt014[m]: yep, theres your problem
<clever> petersjt014[m]: and also "mount | grep sda"
<clever> petersjt014[m]: what does "fdisk -l /dev/sda" say?
<clever> "blkid /dev/sda"
<clever> paritition table, not filesystem
<clever> petersjt014[m]: what partition scheme is on sda?
<clever> petersjt014[m]: https://nixos.org/nixos/options.html#boot.loader.grub.device
<clever> i suspect you can modify qemu-wrap.c to insert one of those flags at the start of the argv list
<clever> tobiasBora: this lists off what cpu's it can emulate
<clever> [root@amd-nixos:~]# ./qemu-3/bin/qemu-arm -cpu help
<clever> i think its more that support for it was compiled out of the x86 readelf
<clever> the x86 readelf cant see it
<clever> samueldr: also, only the arm readelf can find that arch tag
<clever> samueldr: you know where the existing wrapper is?
<clever> sphalerite: ah, the argv[0] thing could inspect every elf file, and pass the right args
<clever> petersjt014[m]: you can get some blocklist related errors if you set the device wrong
<clever> samueldr: binfmt-misc only works on a fixed offset mask and value
<clever> samueldr: its pretty deeply nested into the elf structure, a few pointers down
<clever> petersjt014[m]: what did you set the grub.rootDevice to?
<clever> samueldr: yeah, there is no way to tell them apart at binfmt-misc
<clever> sphalerite: its something like 200mb download to boot, and then nix has to push the whole closure over
<clever> sphalerite: you could use a modified form of my netboot config to boot them on a ramdisk, and just ignore the hdd, or use the hdd as swap only

2017-12-04

<clever> tobiasBora: just configure nix build slaves and bump up the -j count
<clever> tobiasBora: so you can just parallelize the job over every x86 machine, and every core
<clever> tobiasBora: more ram, and more cores, and you are likely to have many x86 machines
<clever> tobiasBora: also, after building qemu-user, you need to run ./qemu-user/bin/register
<clever> tobiasBora: and you need to use the patched nix from nix-build -A nix, then ./result/bin/nix-build
<clever> tobiasBora: you need the `build-extra-platforms = armv6l-linux` line in /etc/nix/nix.conf
<clever> tobiasBora: at some point, it should begin building, and thats when the real test starts
<clever> is it downloading or building?
<clever> yep
<clever> its just simpler to manage all the dependencies
<clever> tobiasBora: i always write nix expressions for every piece of software i make now
<clever> tobiasBora: nix-misc was just a dumping ground for many things
<clever> tobiasBora: the real magic is when you do: nix-build '<nixpkgs>' -A hello --argstr system armv6l-linux and it just works
<clever> tobiasBora: that will open the default.nix file, and build the qemu-user-arm target defined within
<clever> tobiasBora: nix-build -A qemu-user-arm -o qemu-user
<clever> samueldr: i think its runtime, but the wrapper for fixing argv[0] can insert them
<clever> tobiasBora: then nix-build the nix target in nix-misc, and use that nix to build things for arm, with the right config manualy placed in /etc/nix/nix.conf
<clever> tobiasBora: run nix-build on the qemu-user-arm target, and then run register as root
<clever> tobiasBora: it can be used on debian as well
<clever> tobiasBora: yeah, the BCM2835 is v6 only
<clever> tobiasBora: what about the revision and hardware
<clever> tobiasBora: what does /proc/cpuinfo say?
<clever> one minute
<clever> yeah
<clever> tobiasBora: also, are you sure you need v6, which model of the pi do you have?
<clever> but then you need to have a second x86 machine for v7 mode
<clever> qemu has some flags that can be used to entirely disable v7 support
<clever> then when you run it on a real v6, it crashes
<clever> openssl detects that the qemu is v7 capable, and makes v7 opcodes in the v6 build
<clever> tobiasBora: some things like openssl and the kernel have trouble building for v6, but a good deal does work
<clever> tobiasBora: so you can just add v6 to the list
<clever> tobiasBora: the extra-platforms option takes a space seperated list of platforms
<clever> yep
<clever> that puts the register script into the default PATH
<clever> sphalerite: ah, nice, yeah, you have to manualy run register on bootup
<clever> then use the nix attribute in that file as the nix.package in configuration.nix, and youll have a new option in nix.conf to convince nix-daemon it can actually run arm binaries
<clever> tobiasBora: then the ekrnel can just run any arm binary
<clever> tobiasBora:build the qemu-user-arm target, and then run the register script under bin, to register it with binfmt-misc
<clever> LnL: i sometimes use the irc gateway for slack
<clever> i'm guessing thats matrix renaming users again
<clever> blacklisting kvm will probably solve your problem, and also block qemu from ever having kvm extensions
<clever> the intel one may work differently
<clever> but i'm on the amd kvm module
<clever> it only blocks if /dev/kvm is in use
<clever> earldouglas: thats strange, because on my end i can have both loaded at once
<clever> earldouglas: try doing "rmmod kvm" and see what happens
<clever> MichaelRaskin: i recently found that hyper-v doesnt work inside virtualbox (the windows version of kvm)
<clever> earldouglas: do you have VM extensions enabled in the bios?
<clever> but you have to choose to connect to slack, so you expect that kind of thing, and they can just bend the rules of irc
<clever> the slack irc gateway handles long messages better, it just spams the channel, lol
<clever> there are some features qemu lacks, like clipboard sync
<clever> fearlessKim[m]: then you have no way to sign in until you set one with passwd
<clever> you just wont have ssh key pairs
<clever> fearlessKim[m]: it will accept the same name/pw as ssh
<clever> patchelf is in c
<clever> /nix/var/nix/profiles/system/init
<clever> fearlessKim[m]: it may be better to get it via /nix/var
<clever> fearlessKim[m]: oh, and that init path will only be valid after nixops has done the copy-closure
<clever> mightybyte: you need to use haskellPackages.callPackage
<clever> fearlessKim[m]: if you convert it to raw, it will be more easily readable, but that will also double your disk usage
<clever> fearlessKim[m]: ah, qcow cant be directly mounted on the host
<clever> fearlessKim[m]: and gist all 3
<clever> fearlessKim[m]: to start with, run file, blkid, and "fdisk -l" on it
<clever> fearlessKim[m]: the init script can handle the root being readonly
<clever> fearlessKim[m]: is /nix/store not on sda1 ?
<clever> fearlessKim[m]: that should let you know which toplevel your looking at
<clever> fearlessKim[m]: the path to toplevel includes the hostname, and those should be unique
<clever> fearlessKim[m]: that init will have to exist within the rootfs the initrd mounted
<clever> Ralith: pretty much every chip i have supports ondemand
<clever> no manual or userland option?
<clever> i used to use powernowd, which did on-demand in userland, via the userland govenor
<clever> it depends on the hardware

2017-12-03

<clever> mightybyte: did the build pass or fail?
<clever> magnetophon: src = ./.; is one common way
<clever> magnetophon: sounds right
<clever> magnetophon: and then set kernel.packages to the new thing?
<clever> magnetophon: and also line 160 of the file you linked, that makes a set of packages around the kernel
<clever> magnetophon: also, callPackage expects 2 arguments
<clever> magnetophon: ah, that may work then
<clever> magnetophon: so i dont think that override will have any effect
<clever> magnetophon: your override sets linux_4_14_rt, but musnix uses the linuxPackages_4_9_rt
<clever> magnetophon: then you will want to either override linuxPackages_4_9_rt, or set kernel.packages to a set of kernel packages built around your overriden kernel
<clever> magnetophon: line 99, it will decide between kernelpackages and linuxPackages_opt, depending on what kernel.realtime is set to
<clever> magnetophon: boot.kernelPackages has to be set correctly to make it use that version
<clever> magnetophon: is something actually using the overriden kernel?
<clever> so modprobe can never set those
<clever> the kernel args also let you set options to things that where linked in at compile time
<clever> benley: this is how i was setting various zfs flags
<clever> "spl.spl_taskq_thread_bind=1"
<clever> "zfs.zio_taskq_batch_pct=50"
<clever> kernelParams = [

2017-12-02

<clever> fikovnik: and the name will start with the hostname
<clever> fikovnik: the build-vm will drop it in the current directory
<clever> but if you delete the .qcow2 file, it will be a fresh boot
<clever> fikovnik: then the /etc/passwd is setup and it ceases to do anything
<clever> fikovnik: initialPassword only has an effect the first time it boots
<clever> fikovnik: try using initialPassword, and delete the temporary .qcow2 file it made
<clever> mbock: same thing, you have to set it in configuration.nix
<clever> you should be able to just logout and log back in
<clever> manu__: also, did you "nixos-rebuild switch" ?
<clever> manu__: nothing has to actually be installed, just setting the right enable flags will do everyhting for you
<clever> manu__: it also needs services.xserver.enable = true;
<clever> mbock: you need to configure an initial(hashed)password in configuration.nix, and delete the .qcow2 made when you ran the vm

2017-12-01

<clever> manu__: what have you tried so far?
<clever> rvolosatovs: it sounds more like you want to leverage the nixos options, if possible
<clever> where it spits out the last 30 lines of the failed job
<clever> nix needs to have a better -Q
<clever> gchristensen: the biggest reason i use it, is that if you get a failure with `-j 8`, your error is interleaved with other things, and restarting it may start more things, rather then fail right away
<clever> the entire build/install happens as root, so users shouldnt come into play
<clever> jvtbatman: you also dont really have to re-format, just mount everything again under /mnt and nixos-install
<clever> jvtbatman: that could break the boot partition
<clever> about the only real difference, is that you can use a graphical browser and graphical text editor while installing
<clever> jvtbatman: the graphical installer just boots with X11, but it produces the exact same thing when you nixos-install
<clever> earldouglas: the key from one level up when you do resources.ec2KeyPairs.KEY = options
<clever> earldouglas: it will default to using the key above it, causing it to become a unique "charon-uuid-unsharable-key-pair";
<clever> earldouglas: resources.ec2KeyPairs.unsharable-key-pair = { region = "..."; };
<clever> earldouglas: oh, i know, just delete the name= from that set
<clever> earldouglas: nixops normally inserts the deployment uuid into the name
<clever> earldouglas: ahh, that would be a problem then
<clever> earldouglas: and the keypair name includes the uuid?
<clever> jvtbatman: it defaults to /mnt/ which is where you must mount the hdd
<clever> earldouglas: and if you open the keypair list in the aws console, does it ruen into charon-uuid-dont overwrite me bro?
<clever> then it should be working
<clever> jvtbatman: did you just dd the iso directly to the root of the device?
<clever> jvtbatman: and how did you boot from that installer?
<clever> earldouglas: are you able to gist the nixops deployment.nix file?
<clever> jvtbatman: is there more to the error that you can paste?
<clever> yeah, you can either create a proper option, or you can do what i just linked, which gets passed to every module in the nixos
<clever> rvolosatovs: one min
<clever> that might explain some weirdness i saw recently
<clever> flyx: you need to figure out of its running python on a .py file and trying to import pygments, or just trying to run something like pygmentize
<clever> and the others get inserted at various points in the init scripts
<clever> extraUtilsCommands is ran when copying binaries into a temporarily directory the initrd will later use
<clever> LexLeoGryfon: using the options defined on lines 320, 344, 352, 361, 371, 388, and 399, you can manipulate what goes into the initrd
<clever> LexLeoGryfon: this is where nix generates the initrd
<clever> flyx: dang, cant remember what the magic incantation was for dtrace
<clever> LexLeoGryfon: what do you want to do with those hooks?
<clever> flyx: oh, darwin has something else
<clever> try adding strace to the buildInputs