ajs124 has quit [Quit: Bridge terminating on SIGTERM]
ajs124 has joined #robotnix
<jack[m]>
tested and working on redfin.
<danielrf[m]>
jack: Thanks for testing. Was that with the vanilla or grapheneos flavor?
<jack[m]>
grapheneos!
<danielrf[m]>
Nice. Happy to hear
<jack[m]>
A few things that I noticed in the 20 minutes I spent with it:
<jack[m]>
- there was a glitch in the f-droid permissions where I had to regrant f-droid the permission to install apps.
<jack[m]>
- I have some puzzlement about seedvault (you get one chance to restore a backup during setup, but that's before you have a chance to transfer the backup onto the phone?)
<danielrf[m]>
jack: I haven't tried the seedvault restore functionality personally. My understanding is that it should work with an sdcard, but that it doesn't work well with nextcloud for the reason you said
<danielrf[m]>
Although there should be an adb command to force the restore to happen after having already gone through setupwizard
<danielrf[m]>
I'm hoping to write a NixOS-style test for this functionality in the future
<danielrf[m]>
I'll see if I can reproduce the f-droid thing in the emulator
<danielrf[m]>
I remember having that issue a long time ago but I thought it was resolved
<jack[m]>
I can understand the desire to limit the use cases to a set that can be easily tested; the use cases were jut not what I had in mind.
<jack[m]>
Huh. I guess I could have packaged the .seedValutAndroidBackup with the image I built. That seems like a bit more of a declarative way of doing it.
<jack[m]>
> I remember having that issue a long time ago but I thought it was resolved
<jack[m]>
* > I remember having that issue a long time ago but I thought it was resolved
<jack[m]>
Sorry I don't have a better report; I was kinda of playing around with stuff. ☹️
<jack[m]>
... and not really doing more rigourous testing.
<danielrf[m]>
No worries. The NixOS-style testing thing would be really nice to have. Even with the (relatively) small set of customization options I provide in robotnix, I hate having to worry that updates/refactors could cause regressions
<danielrf[m]>
Plus doing end-to-end tests (with, for example, seedvault + nextcloud) would be awesome
<jack[m]>
Mmm. That's where the NixOS testing framework really shines.
<samueldr>
sd card and/or usb thumb drive to the usb port
<samueldr>
(for seedvault)
<samueldr>
probably will need an adapter :)
<samueldr>
since... you know... pixel phones not having an sd slot
<ajs124>
my pixel 4a came with a charger that has usb-c on it. so the cable that came with it has usb-c on both ends. but for reasons they also included a usb-c (male) to usb-a (female) adapter.
<ajs124>
I guess so you can use the charger with usb-a -> usb-c cables?
<ajs124>
anyways, that's what I used to restore a seedvault backup
<samueldr>
ajs124: I believe the A female to C male *is* for data transfer from iPhone and other phones
<samueldr>
[citation sorely needed]
<ajs124>
hah, then I actually used it for its intended purpose, sort of
<samueldr>
I remember this as a factoid, but I don't know where I heard it from
<danielrf[m]>
jack: I couldn't reproduce the f-droid issue in the emulator. If you had flashed a version of grapheneos including fdroid on top of one without fdroid then maybe you'd encounter that issue
<jack[m]>
Hrm. I flashed the bootloader and radio fw from grapheneos, but never system image..
<samueldr>
the important part here I assume would be the userdata
<samueldr>
e.g. if it wasn't cleared
<danielrf[m]>
^ that's what I meant
<samueldr>
in custom ROMs land, "dirty flash" is flashing a *different* ROM without resetting the userdata
<samueldr>
and here if you were going from the google android distribution, to grapheneOS without resetting userdata, it'd amount to dirty flashing
<samueldr>
kind of similarly too in differently configured builds I suppose
<jack[m]>
TIL; dirty flashing.
<samueldr>
e.g. one with and without F-Droid
<danielrf[m]>
technically, every change to the robotnix configuration is a "different ROM"
<danielrf[m]>
enabling/disabling modules like seedvault / fdroid might behave differently with a wiped userdata vs. one with existing data
<samueldr>
yes, many changes could be benign, but some changes to the ROM have knock-on effects in userdata
<jack[m]>
I went directly from stock google fw to robotnix without clearing userdata.
<danielrf[m]>
typically I wouldn't expect it to be major issues for smaller robotnix modules like that
<danielrf[m]>
Oh yeah, I'd definitely recommend clearing userdata when moving from factory google to robotnix builds. Or between different flavors of robotnix
<samueldr>
I assume that's the reason the flashing .sh scripts in the OTA zips forcibly wipe