| 30 Jun 2022 |
 Alyssa Ross | it could probably use some love | 08:49:59 |
 matthewcroughan - nix.how | Those layered imports seem wrong to me, is there a better way to do it? | 08:50:14 |
| matthewcroughan - nix.how | the chain of imports = [ ../../foo ] and then ../../foo does imports = [ ./foo/foo ] and then ./foo/foo imports ../foo | 08:50:47 |
| matthewcroughan - nix.how | * the chain of imports = [ ../../foo ] and then ../../foo does imports = [ ./foo/foo ] and then ./foo/foo imports = ../foo | 08:50:58 |
| matthewcroughan - nix.how | * the chain of imports = [ ../../foo ] and then ../../foo does imports = [ ./foo/foo ] and then ./foo/foo imports = [ ../foo ] | 08:51:03 |
| matthewcroughan - nix.how | I mean, I do that in my own configs. But my own configs are not as complex as what is in nixos-hardware | 08:51:31 |
| Alyssa Ross | https://github.com/NixOS/nixpkgs/pull/179686 | 08:51:46 |
| matthewcroughan - nix.how | In reply to @qyliss:fairydust.space
https://github.com/NixOS/nixpkgs/pull/179686 Awesome that there's already an example in nixos-hardware which you've linked to. | 08:52:33 |
| Alyssa Ross | :) | 08:53:04 |
| matthewcroughan - nix.how | nixos-hardware is comparable to a "bsp" in Yocto terminology. A "board support package" if anyone has ever used or dabbled with it. | 08:53:56 |
| matthewcroughan - nix.how | Basically they give you a bunch of "bitbake" code, like nix code, which you import. Then it gets rid of all the quirks, and patches software, etc. Much like an overlay in nix. | 08:54:27 |
| matthewcroughan - nix.how | An example of what a bsp would do, is patch ffmpeg to have support for the Pi's OMX gpu. | 08:54:58 |
| matthewcroughan - nix.how | what we do with configureFlags = [ --enable-omx ] | 08:55:09 |
| matthewcroughan - nix.how | * what we do with configureFlags = [ "--enable-omx" ] | 08:55:20 |
 dramforever | In reply to @dramforever:matrix.org
I guess I should clarify that the thing I worry about most is not just linux_visionfive but all the other things in the PR IMHO We're not even sure how long the VisionFive will last, and what other things StarFive will do, and what the other Linux-capable RISC-V computers in the future will be like. We already know StarFive is working on a JH7110, an even better 8-core thing (I think these two are not the same?).
Will we be updating linux_visionfive or will we need linux_visionfive_v2? Are we prepared to deal with upstream issues in github:starfive-tech/*? Will StarFive keep upstreaming their drivers or not? | 08:55:39 |
| matthewcroughan - nix.how | https://github.com/agherzan/meta-raspberrypi | 08:55:49 |
| matthewcroughan - nix.how | here's what their "BSP" looks like | 08:55:54 |
| matthewcroughan - nix.how | So in order to patch mesa, they cannot just mesa.override since their language is simply terrifying and doesn't work like that, they do this https://github.com/agherzan/meta-raspberrypi/tree/master/recipes-graphics/mesa | 08:56:45 |
| matthewcroughan - nix.how | Line 6 of mesa-gl_%.bbappend is basically what we could do with foo.overrideAttrs (_: { postFixup = "rm -rf someFile"'; }) | 08:57:58 |
| dramforever | In reply to @dramforever:matrix.org
IMHO We're not even sure how long the VisionFive will last, and what other things StarFive will do, and what the other Linux-capable RISC-V computers in the future will be like. We already know StarFive is working on a JH7110, an even better 8-core thing (I think these two are not the same?).
Will we be updating linux_visionfive or will we need linux_visionfive_v2? Are we prepared to deal with upstream issues in github:starfive-tech/*? Will StarFive keep upstreaming their drivers or not? A question I've been thinking of throughout this discussion is... Why doesn't the Unmatched need all this, honestly, crap? | 08:59:51 |
| matthewcroughan - nix.how | Has it not just been around for longer and therefore upstreamed more stuff? | 09:00:25 |
| matthewcroughan - nix.how | And perhaps SiFive are just faster, better, at upstreaming? | 09:00:35 |
| matthewcroughan - nix.how | It's all down to upstreaming, etiquette, putting the work in, on behalf of the vendor isn't it? | 09:00:53 |
| dramforever | Upstreaming in this case means putting things into linux not linux_unmatched, right? | 09:01:21 |
| matthewcroughan - nix.how | It takes work and time to do the extra step of upstreaming the code, and ultimately the vendor needs to do that work | 09:01:24 |
| matthewcroughan - nix.how | In reply to @dramforever:matrix.org
Upstreaming in this case means putting things into linux not linux_unmatched, right? yes | 09:01:29 |
| matthewcroughan - nix.how | technically anyone can do the work of upstreaming the code to Linux, but it's a lot easier for people working for the vendor to do it | 09:01:49 |
| matthewcroughan - nix.how | And if it's simply not in the culture to do that, fast, and readily, then it just chugs along at a snails pace | 09:02:12 |
| matthewcroughan - nix.how | All of this will eventually settle, since all of the work is being done in the open | 09:03:02 |
| matthewcroughan - nix.how | With android phones there are genuine proprietary bits which make this a permanent problem though | 09:03:30 |
