2021-03-21

<clever> ,libraries nly

2021-03-20

<clever> but there are options to restore the expected function
<clever> jumper[m]: i think chrome and firefox ignore the host ca list by default, they ship internal lists
<clever> cant find the old omx docs
<clever> *looks*
<clever> viric: in omx, you could cross-link components, like mjpeg decode, and h264 encode, and the library would magically figure out when things can stay within the gpu
<clever> viric: on the whole VC4 line, the "gpu mem" isnt special, and is basically just a partition
<clever> viric: the old omx api was crazy good at linking components (like gstreamer) and sharing buffers automagically
<clever> viric: i would have expected the api to allow writing results into the other devices buffer
<clever> specifically, the dot graph
<clever> viric: the h264 stuff has moved over to the v4l api
<clever> viric: ive also been working on some open-source drivers for the rpi, and can get composite video up with minimal help from the firmware: https://cdn.discordapp.com/attachments/820789807655157800/822286957382991923/20210318_225757.jpg
<clever> yeah
<clever> ah
<clever> viric: but for that hack to work, the libs must load to the same addr each time, which means avoiding the OS doing automatic relocation, so every dyn lib in cygwin must have its addr assigned, and managed centrally
<clever> viric: for complex reasons (which may have since been fixed?), cygwin cant use fork(), so it emulates fork, by spawning a new proc, then copying all data over! lol
<clever> viric: the a.out has a similar limitation to cygwin

2021-03-19

<clever> viric: in this case, i was using LD_PRELOAD to overwrite a symbol, and wanted to then query the original
<clever> viric: ive had to use something related over at https://github.com/cleverca22/tox_decoder/blob/master/src/logkeys.c#L38

2021-03-18

<clever> redmp_: --include can save some of that time
<clever> redmp_: flake-compat wont have any of the flake eval caching
<clever> but nixops may not be capable of that yet
<clever> if the flake stuff is working fully, it should cache the eval
<clever> redmp_: the nixos eval itself is pretty heavy
<clever> redmp_: have you seen the defaults key in nixops?
<clever> redmp_: line 9
<clever> redmp_: check the file i linked above
<clever> redmp_: putting it in NIX_PATH only effects the runtime of the given machine, but not how the machine itself is built
<clever> viric: not sure
<clever> redmp_: you have to also add them to nixpkgs.overlays for each machine in the nixops network
<clever> this tells nixos to put it at a predictable path, and points NIX_PATH to that dir
<clever> redmp_: a secondary problem with those ideas above, is that the NIX_PATH will change on every rebuild, but only take effect after shells are re-launched
<clever> viric: dlopen, and using dlsym on that handle, might work
<clever> matthewcroughan_: all of the fetch functions put it into /nix/store, named after the hash of the contents, and the function returns that path
<clever> viric: the runtime linker is going to only load one copy of it
<clever> matthewcroughan_: those offsets are something internal to setup.sh in the stdenv, ive not figured them out either
<clever> host platform (what the binary was made for) is the derivations build platform (where the drv will be built)
<clever> "host platform is the new derivation's build platform"
<clever> matthewcroughan_: cmake, pkgconfig, and so on
<clever> matthewcroughan_: anything your running at build time, which must be for the host cpu
<clever> when in recursive mode, its the hash of `nix-store --dump $out`, which serializes it as a NAR
<clever> when in flat mode, it is just the raw hash of the file, thats how things like yarn2nix translate a yarn.lock into a drv
<clever> matthewcroughan_: outputHashMode=flat means that $out must be a single file, outputHashMode=recursive means $out can be anything (file, directory, symlink)
<clever> matthewcroughan_: if a derivation has the above 3 attrs, it is fixed-output, and it will get network access
<clever> matthewcroughan_: or the user changed his keys
<clever> > "${hello.src.outputHash} ${hello.src.outputHashAlgo} ${hello.src.outputHashMode}"
<clever> matthewcroughan_: you must know the hash of the keys, if you want it to be pure
<clever> one sec
<clever> matthewcroughan_: curl https://github.com/cleverca22.keys
<clever> matthewcroughan_: if you make it a fixed output drv (declare the hash of $out), then nix will unlock networking, and fail the build if you dont match that hash
<clever> matthewcroughan_: you either need to use builtins.fetchurl (impure) or make it a fixed-output drv

2021-03-17

<clever> adding the iohk hydra to your nix will also speed up the build, directions are in the readme
<clever> and then it wont be able to update itself, so you need to use `niv update` and rebuild the whole system
<clever> you can just do something like `daedalus = import sources.daedalus { cluster = "mainnet"; };` in an overlay, and toss it into systemPackages
<clever> [clever@amd-nixos:~/iohk/daedalus-master]$ nix-build -A daedalus --argstr cluster mainnet
<clever> and then it will just magically update itself when updates are needed
<clever> colemickens: after that bin has finished, you will have a binary in ~/.local/bin and its also in the xfce apps menu
<clever> colemickens: the main point of the sandbox, is to let things work the nix way, even if you lack write perms to /nix, and on a nixos system, if you are not a trusted user in nix.conf
<clever> ive made sure the sandbox stuff works on both nixos and normal linux
<clever> colemickens: if you want the sandboxing and auto-update, just install it the same way as any other linux user
<clever> release.nix is more aimed at running default.nix multiple times, once for every os and cluster combination
<clever> colemickens: the above cmd uses default.nix
<clever> that builds a variant without sandboxing, that just runs directly from the host /nix/store, it lacks auto-update capabilities
<clever> colemickens: `nix-build -A daedalus --argstr cluster mainnet` i think was the incantation
<clever> matthewcroughan_: this file has all of the default phases
<clever> [clever@amd-nixos:~]$ find $(nix-instantiate --find-file nixpkgs)/ -name setup.sh
<clever> /nix/var/nix/profiles/per-user/root/channels/nixos/pkgs/stdenv/generic/setup.sh
<clever> but it doesnt crash
<clever> and yes, it does slow down when editing such large files
<clever> heh
<clever> and ive opened 3mb files in vim
<clever> ive not seen it crash vim
<clever> so you dont wind up with a single line that is 1000 chars long
<clever> matthewcroughan_: just to make the generated shell script more human readable
<clever> bash script
<clever> a multi-line \
<clever> it becomes \
<clever> then you can turn it into a space seperated list
<clever> > :p concatStringsSep " " (mapAttrsToList (key: value: "-D${key}=${value}") { a="1"; b="2"; })
<clever> and an empty set, into an empty list!
<clever> > :p mapAttrsToList (key: value: "-D${key}=${value}") { }
<clever> matthewcroughan_: this turns a set into a list
<clever> > :p mapAttrsToList (key: value: "-D${key}=${value}") { a="1"; b="2"; }
<clever> map attrs
<clever> so the type should be attrs
<clever> then you want nixos to error out when duplicates are given
<clever> does it use both, or just one?
<clever> do you want to silently allow duplicates?
<clever> matthewcroughan_: because [ "foo=bar"] and [ "foo=baz" ] dont conflict, and you wind up with [ "foo=bar" "foo=baz" ]
<clever> matthewcroughan_: the other package, was using an attrset, so you could do { foo = "bar"; }, rather then [ "foo=bar" ];
<clever> > :p map ({key, value}: "-D${key}=${value}") [ {key="a"; value="1";} {key="b";value="2"; } ]
<clever> > map ({key, value}: "-D${key}=${value}") [ {key="a"; value="1";} {key="b";value="2"; } ]
<clever> Yaniel: yep, exactly
<clever> - nativeBuildInputs = [ autoreconfHook pkg-config ];
<clever> + nativeBuildInputs = [ pkg-config ];
<clever> $ git -C ~/apps/nixpkgs log --patch origin/master pkgs/development/tools/misc/openocd/default.nix
<clever> Yaniel: thats triggered by a hook in the inputs
<clever> apply just lets you do one final transformation after all merging is done
<clever> if you set a given option with mkForce twice, it will merge them, according to the usual rules
<clever> this also causes other fun things
<clever> so now the default= has entirely vanished, and cant participate in the merge rules
<clever> it will gather every value at 100, throw the rest out, and merge just the 100's
<clever> so if you use both mkOptionDefault and nothing, you then have values at priority 1500, and priority 100
<clever> it will then run the type-specific merge function on everything at that priority
<clever> if you assign a given option multiple times, nixos will first first out what the strongest (lowest number) priority is
<clever> and foo = mkForce "baz"; is a priority of 50
<clever> foo = "bar"; is a priority of 100
<clever> if you do config = { foo = mkDefault "foo"; } then it gets a priority of 1000
<clever> matthewcroughan_: when you use default= inside a mkOption, it goes via mkOptionDefault, giving it a priority of 1500
<clever> yeah
<clever> matthewcroughan_: if you assign package to pkgs.yabar, it will print that warning
<clever> probably
<clever> while default is just a default if you never set anything
<clever> apply is ALWAYS ran
<clever> matthewcroughan_: the option accepts text, but this apply turns it into a file containing the text
<clever> matthewcroughan_: so line 126 is reading the result of the apply function, at all times
<clever> matthewcroughan_: the result of apply, is what you see at config.services.activemq.javaProperties
<clever> matthewcroughan_: after nixos has finished merging every value assigned to that option (or picking the default), it will run apply on the merged result
<clever> getting the auto-generated docs to explain these edge cases isnt easy
<clever> you could pass that same set to default, but anybody knowing the rules would still be confused more
<clever> yeah
<clever> matthewcroughan_: the default of this option dynamically changes, based on other options
<clever> a lot of options do that
<clever> its a different way of providing defaults at a higher priority
<clever> its acting like a default, by different rules
<clever> yeah, it is very funky
<clever> if you never set javaProperties, then the attrs on line 71 is the default of {}
<clever> apply always gets ran, when you read javaProperties
<clever> it isnt ignored
<clever> then that is at the non-default priority, and so ALL of the default ones (a/b) vanish
<clever> if you ever do javaProperties = { c=3; }
<clever> then a/b are at the default priority level
<clever> the problem is that if you set default = { a=1; b=2; };
<clever> so if you ever set activemq.base, your version has priority
<clever> matthewcroughan_: apply is putting those values on the left side of //, so they have a lower priority
<clever> but they also cant conflict with your own things
<clever> but they have higher priority, and wont magically vanish if you add anything
<clever> they are acting like defaults, because they are on the left of a //
<clever> so then you loose the foo=
<clever> matthewcroughan_: default = { foo = 1; }; would entirely be replaced by javaProperties = { bar = 2; };
<clever> matthewcroughan_: after the final merge is done, nixos will run the apply function, and the result of apply is what you read with services.activemq.javaProperties
<clever> ,tell hasik --remove wants the name on the left, not the right
<clever> ajs124: ah, nice!
<clever> bigvalen: and the server end, but its a bit buggy: https://github.com/cleverca22/nixos-configs/blob/master/tgt_service.nix
<clever> hasik: what does it say?
<clever> bigvalen: i originally wrote this to netboot my rpi's, because of nfs trouble
<clever> hasik: https://nixos.org/channels/nixpkgs-20.09-darwin looks valid when i check it in a browser
<clever> hasik: https://status.nixos.org/ has the names of each channel
<clever> bigvalen: ive got both iscsid and tgtd working on nixos

2021-03-15

<clever> but i dont think the normal container api allows it
<clever> gchristensen: ive done it when manually invoking systemd-nspawn: https://github.com/cleverca22/fusenar/blob/master/container.nix#L6-L13
<clever> yaymukun1: its a module so you have to add <nixpkgs-unstable/nixos/modules/programs/neovim.nix> to the imports section in your configuration.nix
<clever> yaymukund: prior to discovering that line of meminfo, i often forcibly unplugged things, because umount was hanging for hours
<clever> simpson: `dd oflags=direct` will force every write to be synced, so the speed will be more true
<clever> simpson: i believe both pv and dd will hang at the end, and you can `grep Dirty /proc/meminfo` to see how much is pending
<clever> so the speed will be blazing fast, until your write cache fills up, then the speed will entirely tank, because the sync hangs
<clever> dd will force a sync at the end
<clever> yaymukund: dd, cp, and `cat foo.iso > /dev/sdX` all basically do the same thing

2021-03-14

<clever> colemickens: this also does a lot more then appimage, in order to cache the unpacked closure, and speed up starting the app
<clever> colemickens: the bundle stuff was originally designed to be flexible, and support any app
<clever> daedalus ships its own everything (nix ftw), so i can just ship a patched udev to the end-user
<clever> depends on if the appimage is shipping its own udev, or relying on the fhs-env to provide one
<clever> and the nix-user-chroot is behaving similar to fhs-env
<clever> colemickens: daedalus is creating something similar to appimage, but more custom (based on nix-user-chroot and nix-bundle), which allows it to ship a nix closure to a non-nix machine
<clever> subscribed to the issue
<clever> you can also reproduce the problem simply by running `udevadm monitor` inside a fhs-env
<clever> colemickens: i'm also curious how systemd containers dont break things...
<clever> colemickens: running it without the fhs-env would likely also work
<clever> colemickens: client side fix, only the libudev inside the fhs-env needs it
<clever> running it outside of a fhs-env would also work
<clever> the above patch, disables that bit of security in libudev
<clever> likely unrelated
<clever> and libudev actively rejects such messages
<clever> colemickens: but, a non-root namespace (like the fhs-env) cant map root to a uid, for security reasons, so the uid of the sender becomes nobody
<clever> colemickens: when the kernel does that, it will try to preserve the uid of the sender
<clever> colemickens: hotplug events from udevd, are fired into the kernel, which then re-broadcasts them over a special socket, to every libudev client listening for hotplug
<clever> daedalus had the exact same issue
<clever> colemickens: fhs-env, i see the problem!
<clever> colemickens: aha, hotplug issues, i re-launched the electron mess, with it plugged in, and it worked
<clever> colemickens: yeah, it cant detect my ledger anymore...
<clever> possibly
<clever> so you have to repeat the whole series of checks when in an app
<clever> and it will re-enumerate on the usb bus when you do that, potentially breaking the permissions
<clever> the app in ledger-live cant do anything until you launch the matching app in the ledger itself
<clever> thats caused by either uaccess or udev-acl, not sure
<clever> SUBSYSTEMS=="usb", ATTRS{idVendor}=="2581", ATTRS{idProduct}=="1b7c|2b7c|3b7c|4b7c", TAG+="uaccess", TAG+="udev-acl"
<clever> then you should also have permission to open the node and do things to it
<clever> so i have r/w, despite not being in the normal owner/group
<clever> colemickens: this says that the user clever has special permissions, beyond what normal unix rules would have given me
<clever> user:clever:rw-
<clever> [root@amd-nixos:~]# getfacl /dev/hidraw11
<clever> colemickens: the + here, says an ACL was added to the device
<clever> crw-rw----+ 1 root root 249, 11 Mar 14 19:39 /dev/hidraw11
<clever> [root@amd-nixos:~]# ls -l /dev/hidraw11
<clever> [192630.096973] hid-generic 0003:2C97:0004.000E: hiddev101,hidraw11: USB HID v1.11 Device [Ledger Nano X] on usb-0000:04:00.0-1/input0
<clever> [192630.082650] usb 3-1: New USB device found, idVendor=2c97, idProduct=0004, bcdDevice= 2.00
<clever> [root@amd-nixos:~]# [192629.779393] usb 3-1: new full-speed USB device number 4 using xhci_hcd
<clever> ledger*
<clever> colemickens: when i first insert the ledget, absolutely nothing happens on the usb bus, as confirmed by `dmesg -w`
<clever> *looks*
<clever> i didnt have to reboot, just re-plugging the device was enough
<clever> colemickens: services.udev.packages = [ pkgs.ledger-udev-rules pkgs.trezor-udev-rules ];
<clever> stteevveen: as the same user you did --list as?
<clever> stteevveen: did you --update after adding it?
<clever> stteevveen: that dir gets added automatically, if your user has ran nix-channel --update
<clever> that drv allows cross-compiling a kernel, with working `make menuconfig`
<clever> gchristensen: in this case, ncurses doesnt properly add to the cross shell, so i have to add it myself, and then just echo 2 things as a reminder
<clever> usually, shellHook should only setup env vars and echo things
<clever> mkShell isnt special, its just a helper to run mkDerivation for you
<clever> it works on any derivation
<clever> the normal phases dont run when you enter nix-shell
<clever> fzakaria: shellHook basically acts like a new phase, that gets ran upon entering nix-shell
<clever> fzakaria: shellHook is just an env var that nix-shell will eval, it works on any derivation
<clever> gchristensen: iohk has some tricks where doing `nix-shell -A foo` will use the shellHook to run a script and mutate the source in some defined way, using buildInputs to manage getting the right tools
<clever> fzakaria: i think its just re-doing the eval every time you enter the dir, and nix caches the build normally
<clever> gchristensen: i would consider that a bug :P
<clever> fzakaria: i think the only "feature" it gives, is that the eval/build happens in the background, so you wind up using the old shell for 10mins, pulling your hair out trying to figure out why the shell.nix isnt taking effect
<clever> stteevveen: not sure it matters, try it and see what happens
<clever> stteevveen: both generate and install act on /mnt/etc/nixos
<clever> stteevveen: depends, is this config for the target machine or the current machine?
<clever> if you comment out the fileSystems, does the error still happen? does it give any context?
<clever> just one file
<clever> stteevveen: can you pastebin the full configuration.nix file?
<clever> are you setting it in any other files listed under imports?
<clever> fileSystems = { "/" = { ... }; };
<clever> it must contain at least one attribute
<clever> stteevveen: and what did you set it to?
<clever> stteevveen: what does the error say?
<clever> ah!
<clever> turbo_MaCk: that version is in the package
<clever> /nix/store/6hcqnys5sii21xi821f8yg7mvj7cx5dl-util-linux-2.36.1/lib/libuuid.so.1
<clever> [clever@amd-nixos:~]$ ls $(nix-build '<nixpkgs>' -A libuuid.out --no-out-link)/lib/libuuid.so.1
<clever> infinisil: uhhh?
<clever> libuuid.out 23,448 x /nix/store/aswq968ln90nrykgi7902lg80vmibygf-util-linux-2.29.2/lib/libuuid.so.1.3.0
<clever> [clever@amd-nixos:~]$ nix-locate libuuid.so
<clever> ,locate lib libuuid.so.1
<clever> aha
<clever> kenran_: i ran nix repl against the same nixpkgs src i was reading, and cant find it either
<clever> kenran_: yeah, i'm not sure where it is....
<clever> 63 // melpaPackages // { inherit melpaPackages; }
<clever> pkgs/top-level/emacs-packages.nix: melpaGeneric = { pkgs, lib }: import ../applications/editors/emacs-modes/melpa-packages.nix {
<clever> kenran_: what does that line say?
<clever> then the package likely doesnt exist in nixpkgs
<clever> kenran: what if you run `nix repl '<nixpkgs>'` then try to tab-complete `epkgs.evil` ?

2021-03-11

<clever> Miyu-saki: fixed-output derivations arent allowed to have any deps
<clever> but ive not seen linux->darwin cross working before
<clever> nixnewbie: using something like pkgsCross.aarch64-multiplatform.stdenv should give you an env where $CC and $LD target aarch64 for example

2021-03-10

<clever> not recently
<clever> it may also make it fatter, due to code duplication
<clever> Mic92: i'm guessing you could swap pkgsStatic in somewhere, but ive not tried it lately
<clever> lol, matrix ddos'd itself!
<clever> 2021-03-10 06:36:41 -!- juansucks[m] [juansucksm@gateway/shell/matrix.org/x-yuuecyxaqbrbrgex] has quit [Max SendQ exceeded]
<clever> so somebody has already fixed this
<clever> if you run `nix-store -r` on the above path, you can fetch it from a binar ycache
<clever> aforemny: but the above storepath is a different version, which doesnt
<clever> jauco: make $out/etc/ofono/phonesim.conf a symlink to /etc/ofono/phonesim.conf ?

2021-03-09

<clever> elux: try running memtest86?
<clever> ,unstable AWizzArd
<clever> rnhmjoj-M: the only people i do know, dont use nixos, and are using screen-readers because braille display's are rather expensive

2021-03-08

<clever> so you must give it a derivation, that contains whatever is triggering the restart
<clever> exarkun: but if that storepath changes, the .service file changes, and that change is what triggers the restart
<clever> exarkun: i think the only thing it can do, is inject a storepath into the .service file, which basically does nothing
<clever> shla: not really possible to do that
<clever> shla: `nix repl '<nixpkgs/nixos>'` and then you can eval any attr of config
<clever> or you could replace it with u-boot
<clever> in theory, you could customize it to make it more nixos friendly, with rollbacks and a menu
<clever> thats the current bootloader
<clever> Ke: biggest problem right now, is that rpi-open-firmware lacks any form of video output
<clever> Ke: in theory, the pi4 could be fully uefi capable, with a slightly larger spi flash chip
<clever> pi4 has changed too much, and needs a major re-work
<clever> pi1 has armv6 problems, still needs work
<clever> its able to boot nixos on pi2 and pi3
<clever> yeah
<clever> Ke: i have been working on rpi-open-firmware, but ive not focused on uefi yet
<clever> shla: mainline linux and the rpi fork, both work, on all models
<clever> shla: but arm32 has unrelated problems doing a native build on recent nixpkgs revs
<clever> shla: i believe it works on all models
<clever> ixxie: yeah
<clever> so it includes /boot/old
<clever> ixxie: the "firmware partition" is now at /boot
<clever> the default assumes your using u-boot, and never touching it again
<clever> ixxie: youll need to rebuild the image, with a larger firmwareSize flag, so the new /boot has room
<clever> ixxie: the firmware mode, ignores that, dang!
<clever> Default: 20
<clever> boot.loader.raspberryPi.uboot.configurationLimit