<Guest30066>
I'm trying to run NixOS on a Raspberry Pi 4 using the instructions at https://nixos.wiki/wiki/NixOS_on_ARM/Raspberry_Pi_4 It works with the "without GPU" instructions. With the "With GPU" instructions I get the error "Error at 'compatible': FDT_ERR_NOTFOUND" on the device-tree-overlays build. What am I doing wrong?
v0|d has joined #nixos-aarch64
tilpner has quit [Remote host closed the connection]
<Ericson2314>
flokli: btw upstream got a bit closuer to merging things
<Ericson2314>
probably need to ping again after holidya
<flokli>
I'm closely following the issues :-)
<Ericson2314>
:)
<flokli>
I'd personally prefer to have a path to a cross-compiled nixos in hydra, so we spot regressions
<flokli>
We can slowly work towards feature parity
<samueldr>
yes, that would be great
<samueldr>
even if "useless in the end", having armv7l cross-compiled images would be good to allow trustable bootstrapping
<flokli>
I mean, I don't have capable non-x86_64 build hardware
<flokli>
and building on a raspi or pine64 simply doesn't work for me
<flokli>
so I'm basically cross-compiling everything from the workstation to this
<flokli>
https://github.com/NixOS/nixpkgs/pull/108174 is a similar candidate. We can get a pulseaudio without gsettings support, and the alsa-plugins configured there don't support libjack2, but that's probably better than no pulseaudio support at all
<samueldr>
users will end up wanting to nixos-rebuild on an armv7l cross-compiled image
<samueldr>
and live through a world rebuild :)
<samueldr>
thus "useless in the end" (in many cases)
<samueldr>
and even useless in your case
<flokli>
why?
<samueldr>
you won't be downloading the hydra image, dding it, then deploy
<samueldr>
you'll just build it outright
<flokli>
I build a new system on the workstation, and nix-copy-closure it with morph
<flokli>
I do the nix-env system profile dance, and run the activation script.
<flokli>
It's a lot better than dd-ing raspian and running puppet, or building everything on the box itself ;-)
<samueldr>
yeah
<samueldr>
well, native builds would be better **considering** how nixos works currently
<flokli>
ideally native and non-native would converge. But we probably need the intensional store for this
<samueldr>
it'd help
<flokli>
yeah
<flokli>
I just mean, for me, it's better to have a cross-compilation path to a slightly more limited version in a package than no cross-build at all. Often these things are dependencies of something else, and we can't even test cross-compilation without the dependency package
<flokli>
and for some usecases, a cross-compiled image, and not running nix-shell on the machine is totally fine.
<samueldr>
it would be nice if it was all doable through a built-in overlay to Nixpkgs
<samueldr>
to clearly show where things are incomplete
<samueldr>
where work is yet to be done
<flokli>
I don't think it's super feasible. There's a lot of conditionals deep in various package derivations
<samueldr>
yeah
<samueldr>
"it would be nice"
<flokli>
:)
cole-h has quit [Quit: Goodbye]
cole-h has joined #nixos-aarch64
cole-h has quit [Client Quit]
<Ericson2314>
overlay to remove things taht don't work for cross?
<Ericson2314>
Thankfully intentional store is on the way :)
<Ericson2314>
and hopefully after we can get into strictDeps everywhere