<clever>
i tried building a hello-world with the nixpkgs cross-compilers, but it didnt boot under qemu
<clever>
yep, just a matter of how to interface with them from userland, and what to ask
<clever>
and give bypass options, like using a sata disk to bootstrap
<clever>
i'm interested in how, so nixos could tell you its not going to work
<clever>
edef: i also dont know how, but the windows installer can detect if the bios has nvme support, and will refuse to even install to an nvme disk
<clever>
but for my laptop, it boots directly from nvme
<clever>
for my desktop, my entire /boot must be non-nvme, i cant chainload from a stage1.5->nvme/boot
<clever>
it relies on the efi firmware to provide nvme support
<clever>
related, grub does NOT have nvme drivers!!
<clever>
while grub is basically an entire os, and can supply its own drivers
<clever>
edef: my understanding, is that systemd-boot is more limited, and must use the FS drivers the firmware provides
<clever>
edef: i'm not sure what systemd-boot will do if /boot isnt the ESP
<clever>
nh2: and that just adds one more partition&fs into the mix
<clever>
nh2: yeah, you can shove the ESP at /boot/ESP, but grub still doesnt support the zfs crypto, so /boot must be non-zfs
<clever>
but most only do vfat
<clever>
yeah, its up to the firmware vendor to add other FS's
<clever>
and efi requires /boot to be vfat
<clever>
nh2: also, i dont think grub supports zfs crypto, so the kernel+initrd must be on a non-zfs /boot/
<clever>
dminuoso: and your less likely to run into a 500 mile email problem, due to the distro downgrading components on you
<clever>
jollyjester: last week, slim was finally removed (its been unmaintained since ~2014)
<clever>
jollyjester: do you know functional programming?
<clever>
that way of finding things, also applies to other distros sometimes
<clever>
jollyjester: for example, instead of assuming the config is in /etc/nginx/nginx.conf, you `ps aux | grep nginx` and look at whatever `--config` is telling it to look at
<clever>
jollyjester: one trick, is to just forget everything you know about where files normally are, and learn how to find where a tool is told to look
<clever>
thats more in the FHS scope
<clever>
and then having to manually tell each package where to find all of its deps
<clever>
you could think of it like just building every package with its own custom --prefix=
<clever>
yeah, that adds a bit of a learning curve
<clever>
jollyjester: my brain is just wonky, ive memorized a decent chunk of the source for nix, nixops, and nixpkgs
<clever>
,callPackage jollyjester
<clever>
jollyjester: are you using callPackage?
<clever>
(or channel)
<clever>
jollyjester: which nixpkgs rev are you on?
<clever>
jollyjester: that will generate a package, that copies something.sh, and replaces @firefox@ with self.firefox
<clever>
jollyjester: you would write a package overlay, that does something = self.substituteAll { src = ./something.sh; firefox = self.firefox; }; i believe
<clever>
jollyjester: grep the nixpkgs source for substituteAll, youll find an example near nixos-install and nixos-rebuild
<clever>
jollyjester: thats a function that pkgs.substituteAll uses
<clever>
jollyjester: and then nix-env -iA nixos.something
<clever>
jollyjester: you would write a package overlay, that does something = self.substituteAll { src = ./something.sh; firefox = self.firefox; }; i believe
<clever>
jollyjester: check nixpkgs for examples of how substituteAll is used
<clever>
jollyjester: you usually want to build that bash script with nix, so you would use something like pkgs.substituteAll to replace @firefox@ with pkgs.firefox
<clever>
evils: you can use callPackage in all-packages.nix to load the file and pop it into pkgs
<clever>
jollyjester: then its not a string in a nix file
<clever>
jollyjester: if your bash is a string in a nix file, ${pkgs.firefox}/bin/firefox
<clever>
evils: you can either do `symbols = something;` right in the kicad derivation (but kicad will depend on, and force symbols to build first), or you can do `passthru.symbols = something;` then kicad wont depend on the symbols
<clever>
yeah, simpler to use a fetchgit then
<clever>
might get away with just `kicad-libraries = fetchgit`
<clever>
yorick: ah, in that case, it would be better to just make 2 seperate derivations
<clever>
evils: the kicad package would `mkdir $libraries` and copy things to there, while doing its normal build
<clever>
evils: you could add `outputs = [ "out" "libraries" ];` to the derivation, then reference `${kicad.libraries}` to get the files that got installed to $libraries
<clever>
ij: thats what the default NIX_PATH should look like
<clever>
viric: so whatever is receiving the string, must depend on hello
<clever>
viric: if you pass "${hello}" to another derivation, it uses that context to know that the string depends on hello
<clever>
viric: every string has some context attached to it, saying which derivations the string depends on
<clever>
jjakob: nix is using split outputs, to let you install one part or the other
<clever>
jjakob: the dnsutils are in the bind source, and compiled when building bind
<clever>
jjakob: dnsutils is part of the bind package
<clever>
14050 dnsutils = bind.dnsutils;
<clever>
thats why it didnt sound right!
<clever>
viric: that doesnt sound right
<clever>
viric: run `nix-store -qR` on the drv, to confirm your looking at the right patch path
<clever>
viric: oh, nix-instantiate must always copy the patch file
<clever>
viric: remove the root to the thing depending on the patch, and nix-store --delete it
<clever>
viric: they should both say unknown-deriver i believe
<clever>
what does `nix-store --query --deriver` say on each?
<clever>
and something like md5sum agrees they are identical?
<clever>
and the other storepath with ./foo?
<clever>
not sure then
<clever>
viric: is the name the same?
<clever>
yeah
<clever>
so it will work fine in this case
<clever>
but only works for files with pure text content
<clever>
`builtins.toFile (builtins.readFile ..)` could force it to never be executable
<clever>
label it as user error when the wrong tool is chosen
<clever>
just make sure its always cloned with the right tool
<clever>
i dont think theres much you can do about that
<clever>
ah
<clever>
why does the file sometimes have the execute bit?
<clever>
viric: it will get whatever the execute state is for the original my.patch
<clever>
laas: lib.recursiveUpdate
<clever>
but you usually also loose all disk contents on reboot when in such a setup
<clever>
kaliumxyz: most FS's will also keep a read cache, so recently used files stay in ram, but you could force that if you use something like the installer media, where it unionfs's a read-only store with a tmpfs
<clever>
kaliumxyz: thats basically what you get if you enable fstrim on an ssd, it will pre-erase blocks, so it writes faster
<clever>
notgne2: changing /nix/store also means you cant use nixops to deploy linux
<clever>
notgne2: and recompiling to put /nix/store elsewhere means recompiling EVERYTHING
<clever>
notgne2: local?store=/mnt/ only works if you can chroot, and darwin doesnt have chroot support
<clever>
,libraries Nazral
2019-11-21
<clever>
possibly
<clever>
yeah
<clever>
and nix always gives base32 in its messages
<clever>
you can tell from the length and letters
<clever>
i have had confusion before, where it treated X and Y as valid hashes, yet X != Y, because X was base16, and Y was base32 of the same hash
<clever>
once both are base32, i can confirm, it still is a different hash
<clever>
asheshambasta: i'm using videoDrivers = [ "amdgpu" ];
<clever>
ubuntu has serious trouble changing gpu drivers back and forth that easily
<clever>
thats one nice thing with nixos, if you remember to clean that option out, all traces of that gpu driver are gone
<clever>
asheshambasta: the even more modern gpu drivers (kms, kernel mode switching) are suppose to resolve that issue, but your driver has to support it
<clever>
asheshambasta: linux has a kernel panic instead of a bsod, but modern gui layers prevent the panic from being visible
<clever>
asheshambasta: so i just retired the SSD, and moved my zfs pool purely to nvme
<clever>
asheshambasta: the windows only (ugh) utility to update the firmware just fails with "unknown error" (double ugh)
<clever>
asheshambasta: i had similar, it turned out to be a firmware bug in my ssd
<clever>
asheshambasta: anything obvious in dmesg?
<clever>
asheshambasta: thats weird, what exactly is crashing if you use the default kernel?
<clever>
asheshambasta: try `hardware.parallels.package = pkgs.hello;` then
<clever>
chloekek: if you give fetchTarball the hash it wants, then it will be in the nix store, and then you can diff to figure things out
<clever>
chloekek: pkgs.fetchzip unpacks for you
<clever>
asheshambasta: try `hardware.parallels.package = pkgs.hello;` to make it shut up?
<clever>
asheshambasta: and there is no trace of hardware.parallels in hardware-configuration.nix?
<clever>
chloekek: run `diff -r` on the 2 store paths
<clever>
asheshambasta: can you pastebin your whole configuration.nix file?
<clever>
162 description = "Parallels Tools for Linux guests";
<clever>
asheshambasta: are you using prl-tools somewhere?