Here is some context of my thoughts so that they are visible to others even without a meeting at the ccc congress.

My ultimate goal is, as one would expect from a Nix/NixOS lover, to turn my mobile device into a nice reproducible nix environment. I want to use NixOS primarily on the go, but because the day‑to‑day requirements and the still‑unrefined mobile optimizations are unlikely to be practical in the near future, I believe it makes sense to invest my time in robotnix instead.

My first attempts with robotnix are already satisfying thanks to your work, though a few essential components are still missing, which makes it less usable at present. Please excuse any incorrect assumptions I may be making because I haven’t fully understand robotnix yet—feel free to correct me.

I’ve also noticed that the current Flake structure, while providing a clearer separation between library functions, modules, and packages, suffers from one major issue: everything is built in a single large derivation. This makes it difficult to leverage binary caches, which in turn keeps build times high.

I read the documentation at https://github.com/nix-community/robotnix/blob/master/docs/src/building.md#binary-cache, but quickly realized that the components required for that, listed in https://github.com/nix-community/robotnix/blob/master/release.nix#L53, appear to be missing.

I tried to trace the implementation in the repository (https://github.com/nix-community/robotnix/blob/master/modules/base.nix) based on your talks and took a closer look at Android’s Soong build architecture at https://source.android.com/docs/setup/build. Unfortunately, I couldn’t find the solutions you suggested in your talk in the repo, which makes me think there are reasons why they haven’t been pursued further.

My first idea was to abstract the components listed in https://github.com/nix-community/robotnix/blob/master/components.json into individual packages via a lib function for mkAndroid and mkAndroidComponent, so they could be made available as a binary cache. If this hasn’t been implemented yet only due to time or support constraints, it would be great to discuss it before I invest unnecessary effort and test my ideas—so I don’t fall into the same problems again.

If anyone here already has thoughts on these topics, feel free to share them. I’ll try to document and transfer them to a new docs page. During a ccc congress meetup we can then dive into the details together.

pentane (DECT CYPT/2978) matthewcroughan
Thanks for the feedback. What do you think, would it make sense to list the meeting as a Robotnix Meetup under Self-Organized Sessions in the wiki and find a date and timeframe for it? That might attract more interested parties and Android experts to the project. Then I would try to prepare a short description for the wiki. But it might be good if you could briefly share your ideas for the meeting.

Maybe something like:

• the status of the project
• the challenges of the past
• Useful or necessary extensions to the library and module system
• Missing parts of the documentation
• A roadmap with the challenges for dividing up the build derivation

I could imagine that if we tried to make this as concrete as possible, a few people might be interested in hacking together a few prototypes during the congress.

In reply to @cyclopentane:aidoskyneen.eu
i'm at the rzl assembly rn btw in case anyone wants to chat (cc matthewcroughancrstl)

In reply to @atemu12:matrix.org
Those who do have a preference: Which day would you prefer? React 1️⃣-4️⃣