I am testing deploy-rs on my build x86_64-linux system with other remote machine, one of them is raspberry pi 4.
I followed this guide to set this in config:
When I deploy the raspberry pi remote machine, an error message popped up: “apparmor broken”.
It turns out I am using hardened profile and security.apparmor.enable = true; is set.
And I dig in the source code and I found this lines:
Exactly what kind of error? An eval error? An explicit eval throw? Where does come from?
Please always paste the full error message.
What you’re looking at here is code that disables optional(?) features when cross. Given someone went out of their way to add these gates, it should build fine when cross or at least it did at some point.
This is a bit of an oldschool way of doing it which suggests to me that the package hasn’t been touched in a while w.r.t. cross. It might be that cross just works but it’s more likely that these features are still broken in some non-trivial way.
Using the regular override functions. Though at this point you’re doing development on the packages and might as well touch the Nixpkgs source directly.
I wouldn’t think so? I’d see if upstream docs say anything about that.
First I’d research what the current upstream state of support for cross builds is because some build systems do stuff that is fundamentally incompatible with cross. That’s the necessary condition for a Nix cross build to work.
Then look into why the derivation is broken with cross. It’s usually because the build system attempts to run some software it built for the hostPlatform during the build (which isn’t typically possible in a cross scenario of course) or because it cannot discover the cross-systemd-prefixed compilers and supporting tools.
There are various other ways the build can go wrong though. You have to use the scientific method to figure it out: Research what others have found before you, use logic to establish a hypotheses as to what could be going on and test them. There isn’t a manual you could write on this sort of thing.
Thanks for your suggestion!
The “apparmor broken message”: error: Package ‘apparmor-utils-3.1.7’ in /nix/store/hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh-source/pkgs/os-specific/linux/apparmor/default.nix:29 is marked as broken, refusing to evaluate.
Sorry I haven’t research enough before opening this thread.
Later I found a gitlab apparmor issue URL in the file. Basically it tells everything about why both perl and python perform a buildPlatform check: