2019-06-17

<clever> > :p lib.fix (self: { a=40; b = self.a + 2; })
<clever> li_matrix: next is lib.fix
<clever> li_matrix: and maybe use rec less, rec tends to cause problems with overrides
<clever> li_matrix: first thing i can think of, is that dependencies shouldbt be a set of strings, but just normal attr references
<clever> li_matrix: if you link a github with the generated nix, i could also maybe take a glance at it
<clever> ,profiling li_matrix

2019-06-16

<clever> ,
<clever> > qt511.qtbase.all
<clever> > qt511.qtbase.out
<clever> > qt511.qtbase.outputs
<clever> schmittlauch[m]: all outputs
<clever> thats basically `nix-shell '<nixpkgs>' -A hello` but also including gdb
<clever> schmittlauch[m]: let pkgs = import <nixpkgs> {}; in pkgs.hello.overrideAttrs (old: { buildInputs = old.buildInputs ++ [ pkgs.gdb ]; })
<clever> and reboot for every bisect
<clever> if you dont know how to ask systemd to just name a give card, you may have to just boot the new systemd
<clever> yeah, it depends on how you need to reproduce the issue
<clever> then you also know what changes happened to patches (if any)
<clever> but if you know a specific nixpkgs commit broke it, from going from rev1->rev2
<clever> and then bisect another level deeper
<clever> Miyu-saki: once you know which pkg, create an overlay that sets src = /home/clever/apps/systemd;
<clever> pbb: yeah, thats the main limitation, and i guess what systemd was trying to fix
<clever> Miyu-saki: it is fairly simply to just bisect nixpkgs with nixos-rebuild -I nixpkgs=
<clever> so eth0 is forever eth0
<clever> it would dynamicly generate udev rules, the first time a device is seen, and just bind the mac to whatever name the kernel gave it
<clever> in a way, the old hack was better in this reguard
<clever> but then, why did it not use that from the start?
<clever> thats what i was vaguely remembering as well
<clever> ens9 is the only odd one out
<clever> pbb: this gist has all of my NIC's and what the mapping is
<clever> ahh, i'm not used to a pci but having over 9 slots
<clever> pbb: that doesnt look like an enp0s25 to me...
<clever> but i dont know what makes something eno0
<clever> i know that enp2s0 is the 2nd pci bus, 0th slot
<clever> kraem: i think thats listing 19.03, and it was only added in unstable
<clever> kraem: i think the problem, is that nodejs_latest is an alias, and nix-env -qaP wont show duplicates
<clever> 4245 nodejs_latest = nodejs-12_x;
<clever> kraem: on nixos, <nixpkgs> and <nixos> should map to the same channel
<clever> kraem: most of nix operates on attr names, but nix-env -i will not use attrs, but instead search the .name of each package
<clever> ,-A kraem
<clever> Miyu-saki: i dont remember what the rules where either, but gchristensen probably does
<clever> Miyu-saki: oh, those, i got it from gchristensen
<clever> Miyu-saki: would probably want to map over config.users.extraUsers, check to see if isNormalUser is set, and then generate some nginx config to enable what you want
<clever> Gopal[m]: what about driver version? `modinfo nvidia`
<clever> dfordivam: `nix-store --verify --check-contents` should confirm that
<clever> dfordivam: i suspect you had an improper shutdown the last time you did something with nix-env, and the manifest.nix got corrupted
<clever> dfordivam: try nix-env --rollback
<clever> Gopal[m]: i prefer xfce, and havent had any issues
<clever> Gopal[m]: youve tasted the koolaid, and cant go back!
<clever> Gopal[m]: but i have used profiles in firefox, before switching to nixos
<clever> Gopal[m]: nope
<clever> marek: you can see that if you look at the definition of `fetchurl =` in all-packages.nix
<clever> 257 fetchurl = stdenv.fetchurlBoot;
<clever> marek: curl itself uses a different fetchurl to get around the issue
<clever> Gopal[m]: pretty much, once you confirm it worsk, you can file a PR back to nixpkgs, and then everybody gets the update
<clever> Gopal[m]: fork nixpkgs, and edit the version= and sha256= here, https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/video/plex-media-player/default.nix#L39-L47
<clever> linux_: your welcome
<clever> linux_: not sure what those are, to be paranoid, move instead of delete
<clever> or whatever bootloader is enabled in that generation
<clever> linux_: that will take whatever your last generation is, and tell it to just re-run grub-install
<clever> linux_: NIXOS_INSTALL_BOOTLOADER=1 /nix/var/nix/profiles/system/bin/switch-to-configuration boot
<clever> linux_: nixos-enter, and then ... one sec
<clever> can still try nixos-install
<clever> yeah, sounds like the router
<clever> linux_: does `ip route` show a default route?
<clever> linux_: what about `ping 8.8.8.8` ?
<clever> linux_: does /etc/resolv.conf have a dns server in it?
<clever> linux_: it should show something like this
<clever> inet 192.168.2.32 netmask 255.255.255.0 broadcast 192.168.2.255
<clever> linux_: and does `ifconfig` show it as having an IP?
<clever> linux_: does `iwconfig` show it as being connected?
<clever> linux_: wpa or wep?
<clever> linux_: `iwlist <wlan0> scan`, with the right interface name
<clever> linux_: then it does support it
<clever> linux_: does it appear in `iwconfig` or `ip link` ?
<clever> linux_: thats the only way to mount luks volumes
<clever> linux_: did you run cryptsetup luksOpen?
<clever> hyper_ch: cdrtools
<clever> hyper_ch: then install mkisofs
<clever> hyper_ch: dang, in the past, k3b was the only thing that could burn, for my old pata burner, lol
<clever> > k3b.meta.description
<clever> mac10688: yeah
<clever> mac10688: nix-env will manage ~/.nix-profile, which is also in the default search path
<clever> mac10688: but nix-shell can even do binaries and libraries, while a virtualenv is limited to python stuff
<clever> mac10688: a python virtualenv is more like nix-shell, they both mess with env variables to change the default search paths

2019-06-15

<clever> your welcome
<clever> zacts: your telling it to look for nixpkgs, in /home/zacts/git/nixpkgs, and /home/zacts/git/nixpkgs/nixpkgs doesnt exist
<clever> zacts: its nixpkgs=/path/to/nixpkgs
<clever> infinisil: nix-env -E doesnt work the way the manual thinks it does
<clever> chrisaw: yeah
<clever> zacts: what was the start of the output?
<clever> chrisaw: the date of the commit
<clever> dckc-ho: `nix why-depends /path/to/idrsi /path/to/gcc`
<clever> dckc-ho: wrap it in parans
<clever> and then everything fails
<clever> but if somebody is depending on your library, they wont think to wrap python and fix that
<clever> it will search the LD_LIBRARY_PATH and RPATH of the python binary
<clever> any time your loading a compiled library and not giving an absolute path
<clever> simpson: you sometimes need to patchelf/LD_LIBRARY_PATH, but you cant patchelf the python proc, and you dont even control the things depending on you to patch it right
<clever> simpson: a bigger problem in nix+python, is dynamic libraries
<clever> dckc-ho: vim
<clever> dckc-ho: yeah, i also prefer having it in the current dir, and to just never install dev time tools, nix-shell all the way
<clever> dckc-ho: its much simpler to make an override in config.nix, then just nix-env -iA nixpkgs.idris-things
<clever> dckc-ho: 4 months later, when you want to upgrade idris, youll need to figure this all out again
<clever> dckc-ho: also, i find using -E with nix-env to be a source of problesm for other reasons
<clever> dckc-ho: you want pkgs in the with block
<clever> dckc-ho: your using nixpkgs in the with block, that is of type path
<clever> dckc-ho: you want `pkgs = import nixpkgs {}`
<clever> dckc-ho: that imports the file at that path, and then calls the function with no args
<clever> dckc-ho: the `import nixos {}`
<clever> dckc-ho: thats why i imported it
<clever> dckc-ho: nixpkgs is the path to nixpkgs, not the package set
<clever> dckc-ho: yeah, that looks wrong, nix-env is weird and often doesnt work the same way as all the other nix tools
<clever> dckc-ho: that assumes your channel is called nixos, `nix-channel --list` to see all channels
<clever> dckc-ho: and this is a bit simpler, just replace the pkgs.hello
<clever> [clever@amd-nixos:~]$ nix-env --dry-run -iE '{ nixos, ... }: let pkgs = nixos {}; in pkgs.hello'
<clever> dckc-ho: this will load the channel called nixos, and then get hello from it
<clever> [clever@amd-nixos:~]$ nix-env --dry-run -iE '{ nixos, ... }: (nixos {}).hello'
<clever> dckc-ho: nix-env doesnt pass you pkgs, it passes you an attrset containing all channels
<clever> romildo: set platback to default, at the very bottom
<clever> romildo: set platback to default, at the very bottom
<clever> romildo: do you see default in /etc/asound.conf?
<clever> romildo: on my end, i see a default device
<clever> Guanin: i believe it must be a file that already exists, only nixops is able to extract strings
<clever> romildo: which platback device are you selecting within audacity?
<clever> romildo: testing it on this end...
<clever> Guanin: dont remember, but could just grep the entire nixpkgs for examples
<clever> Guanin: ah, nice
<clever> pbb: depends on if its just for luks, or a whole nfs root
<clever> pbb: that also works, if you can afford the network being down
<clever> romildo: it looks like audacity isnt using the pulse device within alsa
<clever> romildo: is hardware.pulseaudio.enabled = true; ?
<clever> pbb: networking.usePredictableInterfaceNames = false; will just not rename it
<clever> pbb: i'm not sure renaming works when using initrd networking
<clever> romildo: does it print anything to stdout?
<clever> romildo: does it appear in pavucontrol ?
<clever> pbb: there is an option already to just run dhcp in the initrd, so you dont need ip=dhcp
<clever> m1cr0man: oh, and this is basically doing exactly what i said to do an hour ago
<clever> m1cr0man: you may be interested in https://github.com/mcpkg/gradle2nix
<clever> thats better
<clever> [ERROR] Could not create local repository at /var/empty/.m2/repository -> [Help 1]
<clever> FRidh: but this was in the nix sandbox, running as nixbld1, with HOME explicitly set
<clever> m1cr0man: weird, how did it get that path
<clever> [ERROR] Could not create local repository at /home/clever/.m2/repository -> [Help 1]
<clever> m1cr0man: also, line 4 didnt do anything of use
<clever> that will add it to PATH for you
<clever> m1cr0man: also, line 10, you want buildInputs = [ git jdk ];
<clever> m1cr0man: you can do the same thing as fetchcargo, and just make your whole thing fixed-output
<clever> m1cr0man: if possible, download the files using pkgs.fetchurl, and then tell BuildTools.jar to use the pre-downloaded copies
<clever> eyJhb: the journal still
<clever> eyJhb: crank that up and see what the logs say
<clever> services.xserver.verbose
<clever> eyJhb: yeah, not much of use there
<clever> eyJhb: thats strange
<clever> journalctl -u display-manager.service
<clever> eyJhb: what does the xorg journal say?
<clever> and remove the other PageFlip you had added
<clever> i think
<clever> eyJhb: services.xserver.deviceSection = ''Option "PageFlip" "false"'';
<clever> eyJhb: you need to add it to the existing modesetting device, up a ways
<clever> eyJhb: there are no `Section "Screen"` that refer to the device called DisplayLink
<clever> the entire msg telling you what to do it missing
<clever> eyJhb: it looks like a very poorly written pkgs.requireFile
<clever> eyJhb: cat /nix/store/llxigm79n56rss7x4ka09a601im9zyk2-restrict-message
<clever> eyJhb: jq is in jq
<clever> eyJhb: nix show-derivation /nix/store/hv25mq89vxlk7cd1cy29h4szxysxm2kq-displaylink.zip.drv | jq
<clever> eyJhb: run `nix-store -r /nix/store/hv25mq89vxlk7cd1cy29h4szxysxm2kq-displaylink.zip.drv`
<clever> Izorkin: it accepts a string, so you could just set listen = "/run/phpfpm-something/something"; but automating it would require changing nixpkgs, or using disabledModules
<clever> eyJhb: :(
<clever> gentauro: you dont have to add docker to systemPackages
<clever> gentauro: what are you looking for?
<clever> gentauro: `man configuration.nix` and then `/docker`
<clever> ambro718: if you know the /nix/store/path, just run nix-store -r /nix/store/path
<clever> ambro718: pkgs.fetchurl
<clever> day|flip: linux_latest is an alias, and changing it wont change _51
<clever> day|flip: i checked the source, and linuxPackages_latest is referencing pkgs.linux_5_1
<clever> day|flip: i think the compatability thing is likely going to be in the source code
<clever> day|flip: yeah
<clever> day|flip: the gpu driver would have to be modified to do that correctly
<clever> day|flip: thats how the gpu drivers get gfx data to the gpu
<clever> day|flip: i'm guessing that the video driver has to know that SME enabled, and inform the kernel to not encrypt the dma buffers
<clever> 15507 linuxPackages_latest = linuxPackages_5_1;
<clever> then linux_latest should do it, confirming...
<clever> day|flip: it will depend on what your doing with boot.kernelPackages
<clever> day|flip: have you tried with just linux = pkgs.linux ....
<clever> yep
<clever> Guanin: and this is where the eeeeee's came from, https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/system/boot/stage-1.nix#L173
<clever> Guanin: you probably want to check if openvpn is just looking for `ip` in $PATH, or using an absolute path
<clever> Guanin: id say grub should be patched to support boot.initrd.secrets
<clever> but grub doesnt support that, and instead just takes a list of initrds, some of which arent in the store
<clever> systemd-boot's perl wrapper will run that on each entry, to inject all secrets from the current generation, into all generation's initrd's
<clever> this bash script will take an initrd file as an input, and then mutate it to include the secrets, and it can be ran when updating /boot/
<clever> if the bootloader doesnt support secrets, this will copy them into the nix store for you, so it just works
<clever> yeah
<clever> and if you use boot.initrd.secrets on grub, the secrets land in the store!
<clever> systemd-boot only supports boot.loader.supportsInitrdSecrets, which will dynamically regenerate the initrd to inject secrets, when your doing nixos-rebuild switch
<clever> grub only supports boot.loader.grub.extraInitrd, which will load 2 initrd's at boot time
<clever> (facepalm)
<clever> boot.initrd.secrets is seperate, and the security depends on what boot.loader.supportsInitrdSecrets is set to
<clever> Guanin: there are also ways to solve the secrets in the initrd problem already
<clever> Guanin: it does sound like it may be useful to have
<clever> day|flip: the config for the running kernel is in /proc/config.gz
<clever> but will also depend on what kernel your using
<clever> looks good at a glance
<clever> if its wrong, it will either do nothing, or give an error
<clever> youll know when you get the config right, since it will trigger a rebuild of the kernel
<clever> AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT may also be of interest, that makes it on by default, so you dont need memory_encrypt=on
<clever> the XXX's where to disable it, since i didnt need it anymore
<clever> yep
<clever> youll want to set AMD_MEM_ENCRYPT on the kernel your using
<clever> day|flip: https://gist.github.com/cleverca22/68d10d5d077bf531864394cc4b04e7fb a fragment of my configuration.nix, from when i was messing with kernel params
<clever> day|flip: its not enabled in my kernel
<clever> # CONFIG_AMD_MEM_ENCRYPT is not set
<clever> [clever@amd-nixos:~/Downloads]$ cat /proc/config.gz | gunzip | grep MEM_EN
<clever> ./arch/x86/Kconfig:config ARCH_HAS_MEM_ENCRYPT
<clever> ./arch/x86/Kconfig:config AMD_MEM_ENCRYPT
<clever> 53 obj-$(CONFIG_AMD_MEM_ENCRYPT)->>+= mem_encrypt.o
<clever> arch/x86/mm/mem_encrypt.c:int __init early_set_memory_encrypted(unsigned long vaddr, unsigned long size)
<clever> [clever@system76:~/apps/linux]$ grep -r --color memory_encrypt
<clever> day|flip: cat /proc/config.gz | gunzip | grep CONFIG_CRY
<clever> does it need a special compile-time flag in the kernel?
<clever> day|flip: cat /proc/cmdline
<clever> day|flip: that should do it
<clever> yeah
<clever> so the busybox process wont actually do any dns
<clever> Guanin: under normal nixos, it will use nscd to do the actual lookup
<clever> Guanin: what if you strace things?
<clever> at least, the normal ones, dlopen are special
<clever> Guanin: the dynamic libraries get copied automatically
<clever> and i think /usr/lib and /lib are baked into ld.so
<clever> on a normal distro, the compiler mostly relies on /etc/ld.so.conf and ldconfig
<clever> and then a fixup hook will run patchelf --shrink-rpath, to remove things that arent in the DT_NEEDED list
<clever> with gcc, the $out/lib of every single buildInput gets added to the rpath when linking the binary
<clever> and the binaries you make in nix-shell wont work on their own
<clever> so the rust stuff only patches stuff in $out/bin/ after installing
<clever> ah
<clever> lucus16: if you run `set`, do you see anything like a fixup or postinstall function?
<clever> yeah, that looks good at a glance
<clever> what does `type rustc` and `type cargo` return?
<clever> i would expect it to
<clever> lucus16: if you have the source available, just let nix build the whole thing

2019-06-14

<clever> just add that to your buildInputs, and then all other inputs magicaly enter XDG_DATA_DIRS
<clever> /home/clever/apps/nixpkgs/pkgs/top-level/all-packages.nix- wrapGAppsHook = makeSetupHook {
<clever> the line i just pasted, will cause a function to be ran for everything in buildInputs
<clever> Ralith: gnome apps i think
<clever> addEnvHooks "$targetOffset" find_gio_modules
<clever> Ralith: there it is
<clever> nixpkgs/pkgs/build-support/setup-hooks/wrap-gapps-hook.sh: gappsWrapperArgs+=(--prefix XDG_DATA_DIRS : "$XDG_ICON_DIRS")
<clever> Ralith: thats probably setup.sh
<clever> Ralith: same thing for systemPackages and /run/current-system/sw/share
<clever> Ralith: and nix-env will merge all derivations together and put them at ~/.nix-profile
<clever> Ralith: the default value on nixos includes ~/.nix-profile/share/
<clever> XDG_DATA_DIRS=/run/opengl-driver/share:/run/opengl-driver-32/share:/home/clever/.nix-profile/share:/nix/var/nix/profiles/default/share:/run/current-system/sw/share:/etc/profiles/per-user/clever/share
<clever> sindrip: read the cmakelists.txt and see if there is any references to glib-2.0
<clever> sindrip: its not in the normal include path, so you must use pkgconfig
<clever> glib.dev 3,335 x /nix/store/vc1ipmdkvnkx5p99vadzvlan6c6cyhbh-glib-2.50.3-dev/include/glib-2.0/glib.h
<clever> mla: i checked the source, you want dunst.override { dunstify = true; }
<clever> mla: what error does it fail with?
<clever> mla: you probably want .override
<clever> Guanin: yeah, thats basically it
<clever> amf: the name may not be what you think it is
<clever> amf: nix-env -q to list all packages, nix-env -e to remove a package
<clever> pie__: not sure
<clever> pie__: thats not the issue then
<clever> pie__: wb
<clever> pie__: follow the /proc/PID/exe symlink, and run file on that
<clever> pie__: is the rsession process 32bit or 64bit?
<clever> pie__: i dont think python will check the vars after startup, but there may be a python specific way to alter the search path from python code
<clever> pie__: you probably need a wrapper around rstudio then
<clever> pie__: os.getpid()
<clever> pie__: try to query the python pid from the python repl, then check ps aux
<clever> pie__: and is rstudio actually executing python, or loading a libpython.so ?
<clever> eyJhb: that should be easy to test without changes to nixpkgs, and probably should become a default until the real fix is done
<clever> eyJhb: double-check the generated xorg.conf and confirm its right
<clever> pie__: what is the wrapper wrappng?
<clever> eyJhb: looks like its just changes to the xorg config file to workaround the bug
<clever> pie__: back to what i always use then, strace!
<clever> pie__: cant think of what else to check
<clever> pie__: the above command lets you peek at the env vars for any pid
<clever> pie__: double-check the env vars of rstudio, see if the PYHONPATH is still set right
<clever> double-checking pkg_resources...
<clever> cat /proc/1/environ | xargs -0 -n1 echo
<clever> pie__: you probably want LD_LIBRARY_PATH
<clever> eyJhb: it either works or it doesnt, thats still debugging
<clever> eyJhb: could still bisect and see which commit broke it
<clever> eyJhb: ah
<clever> eyJhb: have you checked the diff of the source for xorg, to see what changed between those 2 versions?
<clever> eyJhb: is there a fix that doesnt involve downgrading?
<clever> eyJhb: i would just make the changes from the overlay be included within nixpkgs
<clever> 395 enableDebugging = pkg: pkg.override { stdenv = stdenvAdapters.keepDebugInfo pkg.stdenv; };
<clever> pmiddend: ^^
<clever> 394 # intended to be used like nix-build -E 'with import <nixpkgs> {}; enableDebugging fooPackage'
<clever> numerobis: did you spell services correctly?