<lovesegfault>
alright, time to clean up that rust code
<lovesegfault>
samueldr: Since you have experience with Nix + cross compiling. I want to write a module that returns `import nixpkgs { overlays = myOverlays; }` but allows those who import the module to set `system` or `crossSystem` or whatever
<lovesegfault>
is there a way to get an instantiated `nixpkgs` and then set the crossSystem?
<samueldr>
I don't know about that part :/
<samueldr>
I always end up using an attribute through pkgsCross instead
<lovesegfault>
I see
<samueldr>
so I guess the answer might be: whatever pkgsCross does is what you need?
<lovesegfault>
maybe... I'll fiddle with it more to see if I can get a working thing
<lovesegfault>
wish I could bake in my devtools into the same nix drv and have them only be available when I do nix-shell
<Jake[m]>
You might be able to use `override` to modify one of the arguments passed to `import nixpkgs`?
<lovesegfault>
what happens if I try to use pkgsCross and the host is the same as the target?
<samueldr>
it will cross-compile
<samueldr>
so the compiler configuration will be different
<lovesegfault>
I see
<lovesegfault>
hm
<lovesegfault>
I wonder how I can say "use pkgsCross.aarch64-multiplatofrm if the system is not aarch64"
<lovesegfault>
I'm trying to just use buildRustPackage
<lovesegfault>
oh
<lovesegfault>
just as I complained I think I got it
<clever>
rubber duck always solves it
<lovesegfault>
:D
<lovesegfault>
nice, I'm almost there
<lovesegfault>
will buildRust filter `target` by default?
<lovesegfault>
(filter from src that is)
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
<angerman>
LnL: do you know anyone else besides thefloweringash who works on nixpkgs on Big Sur, x86 and arm?
<LnL>
other than that some people have access to a dtk not really I think
<LnL>
but the tbd changes are the first required step so there's not all that much to do before that
<angerman>
well... I've got one. So just gauging.
<angerman>
LnL: btw, thefloweringash and I were able to produce the same binary on two machines.
<LnL>
unlike with x86 we don't have any older version to go back to to bootstrap the system libs
<LnL>
nice! yeah I very much suspect that the tbd definitions for frameworks will kill the last remaining impurities for reproducability :D
<angerman>
I guess I just need some help where to start to help out properly. My primary focus will be on making GHC work properly, but I'd be happy to help out with more nix stuff.
<LnL>
currently (unlike libSystem) we just symlink to the system dylib
<angerman>
but tbds have been there for a while no?
<angerman>
I think I've seen those at least two WWDCs ago already?
<Jake[m]>
[lovesegfault](https://matrix.to/#/@freenode_lovesegfault:matrix.org): I do think that if you're up for it, the flakes mechanism makes cross compilation easier in some ways.
<lovesegfault>
Jake[m]: how so?
<lovesegfault>
clever: I cannot wrap my brain around this, buildRustPackage works just fine, naersk tries to build llvm 10 and then rust
<clever>
lovesegfault: i havent had time to fully investigate what naersk is doing internally
<Jake[m]>
At a high level, if makes everything super pure. So you can't depend implicitly on the current system, so things depend explicitly on the system. So instead of `default.nix` examining the current system, you have a `package.<system>` for each system. Then `nix build` builds the one for the current system. So it is helpful in that you don't have to be the one to detect what the current system is.
<Jake[m]>
^^ sorry I said system too many times in that paragraph not sure if that made sense
<lovesegfault>
It did, yeah :D
<lovesegfault>
my main issue is with buildRustPackage requiring that maddening cargoSha
<lovesegfault>
which means you _need_ a tool to be able to not have to manually change that all the time
<LnL>
angerman: oh right one other big thing for arm is codesigning, we don't have codesign in nixpkgs because it's part of the libsecurity_* stuff which is not opensourced properly
<Jake[m]>
I think you're going to need to have multiple shas for each system
<angerman>
LnL: yea, that's why I said we were able to adhoc sign the stuff and get the same result.
<clever>
lovesegfault: full kms (the one that reports devices as enabled in DT, and manages with linux) apparently now partially works on the pi4, and can out-do the firmware in some modes
<clever>
6by9 has 2 hdmi + dpi working
<lovesegfault>
:O
<lovesegfault>
that rocks
<clever>
the firmware it limit to 2 screens max, but the hw (and now linux drivers) can do 3
<clever>
s/it/is/
<clever>
but it doesnt support pi4 DSI yet
<clever>
u-boot is also a lot more likely to break the full-kms route, but also, full-kms depends on the firmware a lot less
<clever>
so you might be able to do full-kms purely with nixos dt overlays and no config.txt
pinkieval has quit [Quit: We're here, we're queer, connection reset by peer.]
pinkieval has joined #nixos-aarch64
quinn has quit [Ping timeout: 258 seconds]
quinn has joined #nixos-aarch64
adisbladis has left #nixos-aarch64 ["ERC (IRC client for Emacs 28.0.50)"]
zupo has joined #nixos-aarch64
rajivr has quit [Quit: Connection closed for inactivity]
bennofs has joined #nixos-aarch64
orivej has joined #nixos-aarch64
bennofs_ has quit [Ping timeout: 240 seconds]
<leonardp>
hello. i am trying to boot a raspberrypi with an image i built myself. i swear it worked a while ago, but now, after uboot i get a lot of "mi-C"
<leonardp>
has anyone seen this before? i have no clue what it means!
aforemny has joined #nixos-aarch64
aforemny has quit [Ping timeout: 256 seconds]
aforemny has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<srk>
dead sd card? :)
aforemny has quit [Ping timeout: 256 seconds]
aforemny has joined #nixos-aarch64
bennofs has quit [Ping timeout: 258 seconds]
ninjin_ has quit [Remote host closed the connection]