<samueldr>
danielrf[m]: a bit off-topic for the issues; my end-goal at some point is hopefully to use robotnix to build for a custom rom for a non-google device, maybe even LineageOS if possible
<samueldr>
it's why I'm looking at this
<danielrf[m]>
very cool. I think it could definitely be extended to do that
<danielrf[m]>
feel free to ask any questions you might have along the way
<samueldr>
it may be surprising, but my knowledge of the actual android toolchain bits is severly lacking, so I may at some point ask questions
<samueldr>
sure :)
<danielrf[m]>
yeah, i've spent waay too much time fighting with the android build system
<samueldr>
that tooling that looks like the biggest rube goldberg machine scared/revolted me so much that I never dug into it
<danielrf[m]>
seriously
<samueldr>
the one time I looked seriously into it, to build a GSI for my new phone, it just didn't work as documented
<danielrf[m]>
a lot of documentation is outdated. but the GSI stuff is pretty new so it's unfortunately that didn't work
<danielrf[m]>
*unfortunate
<samueldr>
that was documentation on that GSI project aimed at making fresh GSIs of AOSP from phhusson
<samueldr>
with their specially built docker images!
<samueldr>
well, the next section, but still, it didn't work out of the box
<samueldr>
this only helped cement the gut feeling I had from that
<danielrf[m]>
Yeah, there's a few projects using docker or scripts to make AOSP builds. I think nix is a good alternative with all the benefits of reproducibility and purity we get for free
<samueldr>
I'm sure nix is a good alternative for that
<danielrf[m]>
lots of these scripts do random network access to download stuff
<danielrf[m]>
In fact, the new Android 10 build system uses "nsjail" to disallow network access while building
<danielrf[m]>
so hopefully things will get better there
<samueldr>
hopefully I won't have to deal with that ever again in the future :)
<samueldr>
(by not even using android :))
<danielrf[m]>
haha, I'd love to as well! hopefully mobile-nixos can be a daily driver at some point :)
<danielrf[m]>
it's been on my TODO list to look at if we could use AVB in mobile-nixos btw
<danielrf[m]>
I think google's actually done a really good job at boot security with their recent devices
<danielrf[m]>
and they even let you use your own keys!
<samueldr>
I don't know if other devices allow usage of one's own keys
<samueldr>
information is scarce
<samueldr>
we may want to rely on AVB up to boot.img, and from boot.img rely on something more generic that also works on other distros/x86_64-linux for verified boot setups
<samueldr>
if it even makes sense
<samueldr>
I assume AVB with custom keys verifies boot.img first, and then at that point it's a kernel implementation of system implementation of AVB, or something
<danielrf[m]>
https://calyxos.org/ and https://grapheneos.org/ are both projects that build ROMs which let you use AVB.. I think calyxos at least is looking into other devices as well
<danielrf[m]>
yep, I agree.
<samueldr>
yeah, I learned the most about AVB on grapheneOS' docs
<danielrf[m]>
the verified boot relies on having a read-only "system.img"--which isn't really something we do in mobile-nixos
<danielrf[m]>
so verifying boot.img and using something else for the rest of the system seems the right approach for us
<danielrf[m]>
sorry, I should be more precise--they use dm-verity to verify that read-only partitions haven't been modified
<samueldr>
nice, calyxos has a neat nugget about that
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
asbachb has joined #nixos-aarch64
<asbachb>
Just to be sure: When config this: https://nixos.wiki/wiki/Distributed_build I should be able to build my rasbperry pi stuff on an non arm system like a x86_64 server?
<clever>
asbachb: under normal conditions, the remote builders must have the same cpu type
<samueldr>
while vendor does work, it seems something is broken with the vanilla build of android with robotnix for google-walleye
<samueldr>
android spews so much garbage to the console it's hard to know what's important and what's not :(
<danielrf[m]>
any chance you could post the logs somewhere?
<danielrf[m]>
adb logcat "*:E" will show just the errors
<danielrf[m]>
but even on my device it's still a lot of stuff :)
<samueldr>
sorry, I was looking in the build system a bit
<samueldr>
danielrf[m]: I assume "vanilla" is supposed to boot completely, right?
<samueldr>
it looks like zygote fails to start early, but I'm unsure
<danielrf[m]>
yep
<samueldr>
let me get a serial log
<danielrf[m]>
oh, so you can't even get to settings to enable adb then?
<samueldr>
should the "pixel" flavour be expected to work for walleye? it doesn't eval
<samueldr>
nope, stuck at "android"
<samueldr>
and it goes to rescue party
<danielrf[m]>
only "vanilla" and "grapheneos" are valid flavors atm
<danielrf[m]>
I should probably move pixel out of the flavors subdir
<samueldr>
it was unclear to me what it was supposed to be :)
<samueldr>
another thing, I'll probably open an issue, I thinkg having buildNumber/source.buildNumber default to "12345" is dangerous, it hides real issues
<samueldr>
especially since it looks like it's expected that flavors should set them up
<danielrf[m]>
i agree--I'll add a TODO
<danielrf[m]>
having the flavors set them was a relatively new addition
<samueldr>
that's kinda what I assumed
<samueldr>
just ran strings on vendor.img and it does look like a walleye image (peeking just in case)
<danielrf[m]>
I'll start a vanilla marlin build again just to see if I can reproduce this
<samueldr>
blah, the log has control codes making it hard to gist :/
<danielrf[m]>
samueldr: yep. I can reproduce this. I think I know what the issue is. It's a hack I applied for grapheneos
<danielrf[m]>
I guess I shouldn't expect anything different for not properly understanding the hack :D
<danielrf[m]>
wait---no I can' reproduce this...
<danielrf[m]>
haha it booted up finally
<samueldr>
I'll queue a build of grapheneos once I'm done with what I'm doing, to see if that works
<samueldr>
nix and nixpkgs is so nice, I can go backwards in time in the Mobile NixOS repo and in Nixpkgs, and I *know* I'm actually testing the build like it was in the past
<danielrf[m]>
another thing to potentially try is to add variant="eng" which makes debugging a little easier since adb starts automatically and you get root
<samueldr>
trying to see if asus-flo ever worked properly or not
vika_nezrimaya has quit [Ping timeout: 250 seconds]