2020-10-29

<clever> `echo $CC` returns nothing?
<clever> siraben: not sure where that comes from
<clever> siraben: so your compiler has to expose the same attrs, so nixpkgs knows how to use it
<clever> 239 passthru = {
<clever> 240 inherit langC langCC langObjC langObjCpp langFortran langGo version;
<clever> 241 isGNU = true;
<clever> siraben: i think its an attribute on the compiler itself
<clever> pkgs/development/compilers/gcc/8/default.nix: isGNU = true;
<clever> or `nix-shell -E 'with import ./. {}; pkgsCross.z80something.stdenv.mkDerivation { name = "name"; }'
<clever> or `nix-shell -E 'with import ./. {}; pkgsCross.z80something.stdenv.mkDerivation { name =
<clever> siraben: try to nix-shell -A pkgsCross.z80something.hello i think?
<clever> siraben: it then later runs it, and passes in that set
<clever> 8781 cc = gccFun {
<clever> 8770 gccCrossStageStatic = assert stdenv.targetPlatform != stdenv.hostPlatform; let
<clever> 8768 # The GCC used to build libc for the target platform. Normal gccs will be
<clever> siraben: the result of running callPackage on gcc, but leaving the final {} out
<clever> if not set, it defaults to only linux, and then hydra wont even try building to darwin
<clever> did you set meta.platforms?
<clever> then your makefile doesnt need to know what arch its working on
<clever> so you can just $CC foo.c -o foo.o
<clever> if its working, $CC should also point to the compiler
<clever> yeah
<clever> not sure, its non-gcc, so its not what i'm used to
<clever> siraben: try changing gccFun to use it, and see what happens?
<clever> siraben: Ericson2314 may know more, you can also look to see if llvm has z80 support, then use clang instead maybe?
<clever> siraben: hmmm, not sure how that would work, try just feeding it in as the gccFun fed into stdenv, look near where i modified gccFun in my pr
<clever> siraben: is it clang based?
<clever> siraben: probably simplest to use my pr as an example, and maybe dig up the #nixos-dev irc logs from around when i opened the PR
<clever> without lets you make the binary smaller, and gives you better control of things
<clever> siraben: i'm using pkgsCross.vc4 both with and without a libc
<clever> siraben: you can omit the libc if you want
<clever> possibly
<clever> when using --builders, it will randomly split the load between both local and remote systems
<clever> not sure
<clever> zopieux: are cpu arches being mixed around?
<clever> zopieux: what error did it give?

2020-10-28

<clever> wjjunyor[m]: it will probably work if you quote it
<clever> after that, it was just making sure the generations dont get mixed between arches, and it doesnt gc the other arch
<clever> each has a diff config file, so it tries to load a diff kernel and diff current-system
<clever> energizer: and i had 2 bootloaders in the same /boot, grub for x86, and rpi firmware for arm
<clever> energizer: ive done that before, you just have both closures in the same /nix/store

2020-10-27

<clever> omasanori[m]: or just that
<clever> /nix/store/hwqgr84ngnj4lyy0vl7bsk4lbc94n91i-nixos-system-amd-nixos-21.03pre243434.e0759a49733 11123534752
<clever> [root@amd-nixos:~]# nix path-info -S /run/current-system
<clever> energizer: use --to instead, and run on the other machine

2020-10-26

<clever> pinpox: yeah, the only way to avoid that, is to change the netrc-file option, and point it to something only you can read
<clever> pinpox: you dont have to push the /etc/nix/netrc file to the public repo, at some point, your going to have un-managed files with secrets in them
<clever> pinpox: but then it needs to be readable by any user on the machine
<clever> pinpox: you can also put it into the default netrc file, /etc/nix/netrc
<clever> pinpox: pass the --option to nix when you run nix on that expression
<clever> lrwxrwxrwx 1 root root 54 Dec 31 1969 hello -> /nix/store/xigwhh0hhw17bw3r86b8xy187bnk02qm-hello-2.10
<clever> total 1
<clever> [clever@amd-nixos:~/apps/rpi]$ ls /nix/store/lm0mls6s6lkmp2rbfvanbhwgw2isfp1m-things -l
<clever> spease: and done!
<clever> nix-repl> runCommand "things" {} (lib.concatStringsSep "\n" (["mkdir $out" "cd $out"] ++ (lib.attrValues (lib.mapAttrs (key: value: "ln -sv ${value} ${key}") { inherit hello; }))))
<clever> and now each attr in the set becomes a symlink
<clever> spease: then you can just runCommand "things" {} "mkdir $out; cd $out ${theabove}"
<clever> [ "ln -sv /nix/store/xigwhh0hhw17bw3r86b8xy187bnk02qm-hello-2.10 hello" ]
<clever> nix-repl> lib.attrValues (lib.mapAttrs (key: value: "ln -sv ${value} ${key}") { inherit hello; })
<clever> spease: but you can use things like pkgs.runCommand to make that one attribute depend on many others, in a structured way
<clever> spease: i usually consider that a mistake, and try to build just one attribute
<clever> spease: nix-build -A hello -o hello
<clever> vsiddharth: that work?
<clever> > :p builtins.listToAttrs (zipListsWith (name: value: { inherit name value; }) ["a" "b" "c"] [1 2 3])
<clever> > :p zipListsWith (name: value: { inherit name value; }) ["a" "b" "c"] [1 2 3]
<clever> 353 /* Merges two lists of the same size together. If the sizes aren't the same
<clever> 363 zipListsWith =
<clever> pinpox: and do you have a branch called main?
<clever> pinpox: if you want fetchurl to work on private repos, you need to put `machine github.com login <TOKEN>` into ~/.netrc and use `--option netrc-file ~/.netrc`
<clever> spease: not sure
<clever> pinpox: if its on github, that makes things much simpler, you can just use niv
<clever> pinpox: that could also be a branch name, or use niv
<clever> pinpox: and builtins.fetchurl caches better then fetchGit
<clever> pinpox: downloading a .tar.gz will make it a faster copy
<clever> pinpox: you can still do that build in nix
<clever> pinpox: https://github.com/ownner/repo/archive/GITREV.tar.gz, and it auto-generates one
<clever> pinpox: builtins.fetchurl on the tar.gz, would be compressed, and also cached, so it will fix it several ways
<clever> pinpox: pulling a tar file would be much better
<clever> pinpox: and thats what is causing your performance costs
<clever> pinpox: the problem, is that to always get the latest, it has to copy that latest into /nix/store each time you build
<clever> dhess: fairly old hydra
<clever> spease: either works, but using an overlay makes it simpler to cross-compile to many arches at once
<clever> spease: and now you can just pkgsCross.anything.program, and it will cross-compile to the right arch magically
<clever> spease: and then `pkgs = import <nixpkgs> { overlays = [ overlay ]; }
<clever> spease: you can also do overlay = self: super: { program = self.callPackage ./program.nix {}; }
<clever> spease: it will automatically give you the aarch64 cross compiler, and an x86 build of cmake, and you never have to touch crossSystem
<clever> spease: then do pkgs.pkgsCross.aarch64-multiplatform.callPackage ./program.nix {}
<clever> spease: create a program.nix file containing, { cmake, stdenv }: stdenv.mkDerivation { name = "program"; nativeBuildInputs = [ cmake ]; }
<clever> spease: if you use nativeBuildInputs and callPackage properly, you dont have to do that
<clever> pinpox: yep, thats over 256mb, the only way to make fetchGit faster, is to supply it with a rev= and sha256= i believe
<clever> pinpox: try just `nix-build blog.nix`
<clever> spease: .override cant change the system, but you could `import pkgs.path { system = "something"; }` to re-create the whole pkgs tree, from the same source, but it will ignore any past overlays
<clever> spease: or add { system ? builtins.currentSystem }: to the top for use with --argstr, then `inherit system;` to forward it on
<clever> spease: pkgs = (import <nixpkgs> { system = "i686-linux"; })
<clever> pinpox: change the buildPhase to `echo $src ; exit 1` and then check the size of that dir
<clever> but fetchGit shouldnt be counting the .git folder
<clever> pinpox: how big is the final dir that $src points to?
<clever> pinpox: what args did you run it with?
<clever> id try a relog then
<clever> hodapp: you likely have to restart the daemon, pactl exit i believe
<clever> spease: but -A llvm, isnt the function in llvm/default.nix, because callPackage ran that function, to give you the final derivation
<clever> spease: basically, when -A is loading a nix file, and following an attribute path, it will check if each thing in that path is a function, and then pass it the --arg's
<clever> hodapp: hardware.pulseaudio.package = pkgs.pulseaudioFull;
<clever> hodapp: ah, pulseaudioFull vs pulseaudio
<clever> hodapp: do other modules work, like module-loopback?
<clever> hodapp: you should first `hardware.pulseaudio.enable = true;` then it should be able to find things
<clever> ,libraries spease
<clever> spease: also, you shouldnt be installing things like llvm with nix-env
<clever> spease: yeah
<clever> spease: it has the identical effect to `nix-env -iA nixpkgs.llvm`
<clever> spease: nix-build -E 'with import ./. {}; somePackage.override { someArgument = someValue; }'
<clever> spease: if you want to change an arg for a package, you must use .override
<clever> spease: --arg only works if the root nix file accepts those args
<clever> evalexpr: you would need to use map and builtins.readDir
<clever> pickfire: nix-collect-garbage also wont delete anything your currently using, so that will never touch something that actually matters
<clever> pickfire: caches arent in the nix store, so that will never delete them

2020-10-25

<clever> supersandro2000: glancing at release-lib.nix, i think it defaults to just x86_64-linux
<clever> 148 or (supportedMatches (value.meta.platforms or [ "x86_64-linux" ]))
<clever> but you can open an older passing build, and just download it from there
<clever> energizer: its not done building on the latest rev
<clever> are you sure your on that channel?
<clever> i dont see that attribute in 20.03
<clever> not sure
<clever> raspbian can be used for that
<clever> energizer: you need to install nix on a pi4, with a 64bit kernel, and add it as a build machine
<clever> energizer: yeah
<clever> CyberManifest: ?
<clever> nix-build '<nixpkgs/nixos/release.nix>' -A sd_image_raspberrypi4.aarch64-linux
<clever> which model of pi?
<clever> nixos-install only works if the host and target are the same cpu
<clever> thats the problem
<clever> energizer: was that ran on an x86 or arm machine?
<clever> what command did you run to cause the error?
<clever> energizer: it sounds like your building the firmware for x86, which wouldnt work
<clever> energizer: there are already sd image files for raspi in nixpkgs

2020-10-23

<clever> though i dont see one for clang10...
<clever> laduke-132: such as clangStdenv.mkDerivation
<clever> laduke-132: you generally dont want to add compilers to the inputs, you want to instead change the stdenv
<clever> ahhh
<clever> dminuoso: and the pkgsCross part, makes it magically cross compile to arm instead
<clever> dminuoso: in my case, i didnt have a directory of sources, so i made a custom unpackPhase, and i lacked a makefile, so i just threw in a buildPhase too
<clever> laduke-132: then its probably something cmake is doing
<clever> buffet: use map to check if something is a directory, and run readDir again
<clever> laduke-132: what about $CXX instead of clang++
<clever> buffet: builtins.readDir
<clever> laduke-132: it works normally if i just compile it with $CXX directly, does that work for you?
<clever> [nix-shell:~/apps/test1]$ $CXX src/Hello.cpp
<clever> dmedinag: pkg-config relies on setup hooks, and your mkDerivation likely doesnt handle those properly
<clever> dmedinag: same for mkDerivation, just use stdenv.mkDerivation
<clever> dmedinag: you just want to use the existing callPackage in nixpkgs, rather then making your own
<clever> dmedinag: it looks like your re-writing half of the nixpkgs utils from scratch
<clever> laduke-132: c++ should just work out of the box
<clever> dmedinag: https://nixos.wiki/wiki/C
<clever> laduke-132: can you run `cat shell.nix hello.c ; cmake .` and then take a screenshot and upload it somewhere?
<clever> pumpy: nix turns them into absolute paths as it parses the file
<clever> pumpy: all relative paths are relative to the file the path is within
<clever> laduke-132: and what is the contents of shell.nix?
<clever> laduke-132: and how did you launch the nix-shell?
<clever> can you screenshot the terminal?
<clever> laduke-132: what commands have you run to try and compile it?
<clever> laduke-132: are you in nix-shell?
<clever> so you can just throw a `with lib;` at the top, and then it will find everything
<clever> lib also contains references to all builtins
<clever> builtin is more for things implemented in c++
<clever> pumpy: a lot of functions are implemented in nix, rather then c++
<clever> can always make a bash alias to it
<clever> then lib will be in scope
<clever> `nix repl '<nixpkgs>'` to load nixpkgs
<clever> pumpy: { pkgs, lib, config, ... }: on line 1
<clever> pumpy: lib.hasSuffix
<clever> est31: that one seems to have the gh-pages too
<clever> same
<clever> Guest8470: ^
<clever> ,locate
<clever> ,locate libatomic.so.1
<clever> yep
<clever> services.xserver.windowManager.xmonad.extraPackages = hsPkgs: [ hsPkgs.xmonad-contrib ];
<clever> c4droid``: xmonad wont see any library you install normally, you must use services.xserver.windowManager.xmonad.extraPackages
<clever> 2020-10-22 23:29:50 < clever> c4droid: you must install it with `services.xserver.windowManager.xmonad.enable = true;` to make it find ghc properly
<clever> c4droid: you must install it with `services.xserver.windowManager.xmonad.enable = true;` to make it find ghc properly
<clever> the binary will land in ~/.nix-profile/bin/
<clever> aquarial: and it will grab whatever { foo = ...; } has been set to, and install it
<clever> aquarial: you can just nix-env -f /path/to/default.nix -iA foo
<clever> forgot it in my example
<clever> yeah, that / needs to be there
<clever> because they dont use , and eat your function args
<clever> the outer () is only for lists
<clever> yeah
<clever> you want ++ to concat 2 lists together
<clever> pumpy: so that is [ ./hardware.nix [ ./cond.f/home-manager.nix ] ];
<clever> pumpy: map returns a list, you then put it inside imports, a list
<clever> now try :p builtins.attrNames (builtins.readDir /etc/nixos)
<clever> yeah, so its a set where the keys are filenames, and the values are the type
<clever> pumpy: pop open `nix repl` and then try to eval `:p builtins.readDir /etc/nixos`
<clever> pumpy: oh yeah, and builtins.readDir doesnt return a list of strings
<clever> imports = [ (map (x: /etc/nixos + "${x}") (builtins.readDir /etc/nixos)) ];
<clever> 3: the arg to readDir cant be quoted either
<clever> 2: that returns a list of strings, for just the names, not paths, you need to use map to append each to a path
<clever> 1: the () are in the wrong place, that list contains a function and a string
<clever> pumpy: that will fail in 2 ways
<clever> pumpy: builtins.readDir returns a list of files

2020-10-22

<clever> every unused generation*
<clever> there is also `nix-collect-garbage -d` to just delete every generation and every unused path
<clever> repeat until no more roots are remaining
<clever> Somelauw: `nix-env --delete-generations 2` to delete that generation
<clever> why do you want to delete it entirely?
<clever> `nix-env -e foo` is to uninstall it from a profile, while keeping it incase you change your mind
<clever> no, --delete is for completely removing it from /nix/store
<clever> Somelauw: if you try to force the delete, you will loose everything that is installed with nix-env
<clever> Somelauw: you installed it with nix-env -i as root, so you have to first uninstall it, and delete the generations
<clever> Somelauw: nix-store --query --roots /nix/store/9ycaql3dbmxhvb5n73z8znjbnjnxwgfn-qutebrowser-0.9.0

2020-10-21

<clever> pickfire: yep
<clever> pickfire: or add a call to builtins.trace to it
<clever> pickfire: the fact that the errors went un-noticed until now, prooves that it was never even trying to install the package
<clever> pickfire: nix is lazy, until you depend on config.boot.kernelPackages.rtl8822ce somewhere, it wont even bother reading rtl8822ce.nix
<clever> pickfire: extraModulePackages must be a derivation, as in the example i gave above
<clever> pickfire: but boot.extraModulePackages is needed to let it even be found
<clever> pickfire: boot.initrd.kernelModules just says to copy the module into the initrd, if it can be found
<clever> pickfire: you also need the extraModulePackages to actually include it in the OS
<clever> pickfire: that says to load the module, but not to install it from a given derivation
<clever> pickfire: can you paste the line you have now?
<clever> pickfire: you still need a boot.extraModulePackages = [ config.boot.kernelPackages.rtl8822ce ]; as before
<clever> pickfire: line 4-10 defines a single overlay, then line 32 makes a list containing that single overlay
<clever> thats where it can be handy to just read other peoples nixos config
<clever> yes, splitting things over 4 manuals is confusing
<clever> nixos manual for the option, nixpkgs manual for what an overlay is
<clever> nixpkgs.overlays is a nixos option, to accept a list of nixpkgs overlays
<clever> that would be in the nixos manual
<clever> pickfire: yep
<clever> ah yeah, the overlay is a way to avoid changing the repo, that explains the confusion
<clever> how did it work? what code did you use?
<clever> pickfire: so if the iso is booting, you likely already have this code working?
<clever> pickfire: also, this is the exact same way you need to add the driver to the iso
<clever> pickfire: inside a nixpkgs overlay, nixpkgs.overlays = [ (self: super: { .... }; }) ];
<clever> pickfire: linuxPackages = super.linuxPackages.extend (lself: lsuper: { rtl8822ce = lself.callPackage ./rtl8822ce.nix {}; });
<clever> 2020-10-21 13:40:16 < clever> pickfire: linuxPackages = super.linuxPackages.extend (lself: lsuper: { ... });
<clever> and its kernel based, so you must use the linuxPackages.callPackage
<clever> pickfire: thats a package, you must load it with callPackage
<clever> pickfire: what is line 1 of rtl8822ce.nix ?
<clever> pickfire: that will heavily depend on what is inside rtl8822ce.nix
<clever> yeah
<clever> the 2nd round, it needs to be in /mnt/etc/nixos, when you run nixos-install
<clever> the 1st round, is needed when building the iso, before you even boot
<clever> but on that 2nd round, the wifi is up, so scp will be up too
<clever> then a second time, when nixos-install builds the final install, youll put it in /mnt/etc/nixos then
<clever> once on the machine building the iso, which will let wifi work when you boot the iso
<clever> you need it twice
<clever> or manually copy it into the machine with git/scp after booting
<clever> pickfire: normally, the nix files are not copied into the build product, so you would have to add a `cp ${./foo.nix} somewhere/foo.nix` to some expression
<clever> pickfire: you can also inline it directly into configuration.nix, but having it as a seperate file is cleaner
<clever> pickfire: linuxPackages = super.linuxPackages.extend (lself: lsuper: { ... });
<clever> pickfire: you can also use an overlay to modify the linux packages
<clever> pickfire: add it to your main configuration.nix
<clever> yeah
<clever> iso_plasma5.x86_64-linux for graphical
<clever> pickfire: then edit configuration.nix to add the drivers, the same way you would have added them to a normal nixos
<clever> pickfire: nix-build '<nixpkgs/nixos/release.nix>' --arg configuration ./configuration.nix -A iso_minimal.x86_64-linux
<clever> and rollbacks didnt help, because it was the generation of the rollback menu that broke
<clever> jakobrs: what followed, was about 2 weeks of nixos users on nixpkgs-unstable,streaming into the channel because it wasnt booting anymore
<clever> jakobrs: i have seen an incident about 2 or 3 years back, when grub did break, nixos-unstable didnt change as it should have, nixpkgs-unstable did change
<clever> joebobjoe: only if your not building with nix
<clever> joebobjoe: i'm on an older branch of nix
<clever> jbal[m]: that only happens if either, a: you have overlays that make it never match the cache, b: your not on a full channel, c: it failed to build on hydra, and will fail for you as well
<clever> joebobjoe: you can read the release.nix to see how nix is doing it
<clever> release.nix: substitute ${./scripts/install.in} $out/install \
<clever> [clever@amd-nixos:~/apps/nix]$ git grep install.in
<clever> joebobjoe: they get substituteAll ran on them, to generate scripts used for various things
<clever> you can also `nix log ./result` i believe
<clever> /nix/var/log/nix/ is the nix build logs
<clever> /var/log is system logs, like systemd and other stuff
<clever> you can always delete the logs in that dir, nix doesnt really care about them
<clever> mine is at 1.9gig
<clever> thats nothing :P
<clever> so you can view the log for things you didnt even build
<clever> `nix log` can also fetch logs from the binary cache
<clever> pickfire: they are all saved in /nix/var/log/
<clever> pickfire: yeah, for every single path you build
<clever> pickfire: `nix-store -l /nix/store/foo` shows you the logs
<clever> both usr and sbin basically dont exist
<clever> Henson: same, lol
<clever> then they come here, and cant rollback, ebcause they GC'd
<clever> the biggest problem i see, is that new users think `nix-collect-garbage -d` and rebuild will fix their problem

2020-10-20

<clever> it should behave the same if the config and overlays are blank
<clever> viric: i think the flake will ignore them
<clever> viric: `nix build -A hello <nixpkgs>` will impurely read config.txt from $HOME, along with overlays
<clever> duairc: nix also accepts hashes in both base16 and base32
<clever> duairc: man nix-hash
<clever> duairc: recursiveUpdate wont properly deal with merging list type things
<clever> duairc: lib.mkMerge is better for nixos config
<clever> __red__: you likely also want boot.loader.grub.device = "/dev/sda";
<clever> __red__: then you forgot to do boot.loader.grub.enable = true;
<clever> __red__: --install-bootloader, ^
<clever> by default, it only reinstalls the bootloader if the bootloader version or low-level cfg has changed
<clever> __red__: nixos-rebuild switch --install-bootloader