ChanServ changed the topic of #robotnix to: Robotnix: || Channel logs:
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
<jack[m]> Clearing userdata -> factory reset, right?
<samueldr> yep
<jack[m]> I learned just now about the `factorImg` derivation, I was just building the `img` derivation.
<danielrf[m]> still working on documenting all this better. sorry for the delay on that :)
<samueldr> indeed -w should have wiped