<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>
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>
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: 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>
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