<ryantrinkle> samueldr: Ericson2314 mentioned to me today that there was some progress made on gobject-introspection cross by the yocto guys
<ryantrinkle> that's the gnarliest cross package i'm aware of for most of the things i'd like to run on my pinephone :P
<Ericson2314> samueldr: ryantrinkle I think I am very close to having something that works for us, based on the Yocto people's work
ornxka has quit [Quit: No Ping reply in 180 seconds.]
ornxka has joined #nixos-aarch64
<samueldr> nice, that would be really nice
<samueldr> and yes, it seems the main roadblock these days is g-i
<Ericson2314> samueldr: while you are here https://pastebin.com/eCR1qFT0 know what to make of that?
<samueldr> sorry, no real experience with meson
<samueldr> though it looks like it's somehow stripping dashes and keeping what's left to the first?
<Ericson2314> oh interesting
<Ericson2314> well that is already something for me to investigate :)
<Ericson2314> going to grab some food then look into that
<samueldr> I mean, that's my intuition from seeing that lone hash with a slash
<ryantrinkle> Ericson2314: awesome!
h0m1 has quit [Ping timeout: 260 seconds]
h0m1 has joined #nixos-aarch64
Darkmatter66 has joined #nixos-aarch64
Darkmatter66_ has quit [Ping timeout: 258 seconds]
edcragg has quit [Read error: Connection reset by peer]
edcragg has joined #nixos-aarch64
orivej has joined #nixos-aarch64
pat_h has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
pat_h has quit [Quit: Connection closed]
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
zupo has joined #nixos-aarch64
orivej has joined #nixos-aarch64
nschoe has joined #nixos-aarch64
wavirc22 has quit [Ping timeout: 272 seconds]
wavirc22_ has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
pbb has quit [Ping timeout: 272 seconds]
pbb has joined #nixos-aarch64
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-aarch64
orivej_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 272 seconds]
orivej_ has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
nschoe has quit [Ping timeout: 244 seconds]
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
zupo has quit [Ping timeout: 264 seconds]
zupo has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
orivej has quit [Ping timeout: 264 seconds]
orivej_ has joined #nixos-aarch64
alp has joined #nixos-aarch64
orivej_ has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
Darkmatter66_ has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 264 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<clever> 2020-05-19 09:41:20 < Tenkawa> Anyont tried out the mainline 5.7rc kernel yet? its great
<clever> 2020-05-19 09:45:54 < Tenkawa> clever: ok happier topic... cant believe mainline actually works un patched yay :)
<clever> samueldr: 5.7rc apparently works on an rpi4 now
<srk> nice!
orivej has quit [Ping timeout: 260 seconds]
orivej_ has joined #nixos-aarch64
<gchristensen> I don't suppose anyone has a recommended "build a stack of pi's" kits?
<hexa-> clever: hm, 5.7rc4 doesn't
<simpson> gchristensen: I found a cute little set of shelves that is perfect for holding Pis at Muji. I figure that some sort of Muji/IKEA plastic dish is going to work reasonably.
<simpson> I also recall great success with Lego, but I was not running things very hot; I don't know how well Lego stands up to heat.
<hexa-> lack of generations on the rpi4 is annoying
<clever> hexa-: i have been considering a custom arm bootloader to solve that
<clever> hexa-: probably something LK based
<clever> hexa-: though mobile-nixos also has a kexec based one
<hexa-> cool
<hexa-> contemplating on how to recover that pi
<hexa-> copying over the cmdline.txt didn't do the trick
<hexa-> probably too many changes in /boot
<gchristensen> simpson: hmm cool
<clever> hexa-: my current problem with handling generations on my open firmware, is the lack of long filename support
<hexa-> oh yeah, vfat limitations </3
<clever> hexa-: the filesystem supports them just fine, the fs drivers dont
<clever> hexa-: here is where i load the zImage, initrd, and cmdline.txt for linux
<hexa-> looking forward to this :)
<clever> hexa-: i could easily run read_file on something else, and then do some kind of parsing to deal with generations and such
<clever> but without fat32 write, i cant automate rollback on failure
<clever> and without long filenames, having multiple kernels with names that still make sense would be difficult
<hexa-> agreed
<clever> if i get fat32 write solved, i can change the default generation before i boot
<clever> and then after booting, change it back forwards again
<clever> and then if it fails, whack reset, and it goes backwards on its own
lordcirth has joined #nixos-aarch64
<simpson> gchristensen: I've got https://www.muji.us/store/4547315296286.html or so, and it fits three Pis or similar, although it's not perfect and I'm not sure if I'm actually happy with it.
<hexa-> acrylic for the heat dissipation of the rpi4 … hmm
<gchristensen> oh cool
<gchristensen> thanks!
<simpson> hexa-: Yeah, acrylic isn't a great material, but there's actually a lot of room in those bays, and Pis are designed to be passively cooled. Also I've never really spun everything up to see what happens on full tilt.
<gchristensen> are the prolific-based serial cables any good? I've been trained to only trust ftdi
<clever> gchristensen: ive also exclusively been using ftdi stuff
<hexa-> lately been using cp1202 and pretty happy with that as well
<hexa-> cp2102*
<gchristensen> cool
<simpson> hexa-: Huh, now I'm wondering about making little cloth mat-trays.
<hexa-> simpson: huh, for the rpi?
<simpson> Yeah. I've done this sort of thing before; when I used a Pi as a synthesizer for a keyboard, I needed a way to tape the Pi onto the keyboard, without scratching the keyboard's finish or damaging the Pi's exposed pins.
<simpson> My compromise was to use a piece of foam to mount the Pi while leaving it half-exposed to air, and to tape the mount to the keyboard. If I redid this today, maybe I'd use a piece of thick fabric instead.
<clever> simpson: most of my plastic cases have mounting keyholes in them
<simpson> clever: Right. These bays are completely open on one side, but I could imagine drilling holes in the other sides too.
<gchristensen> hmm it doesn't look like the rpi is actually compatible with the FTDI adapter, and requires some extra mucking about with cables
<hexa-> rpi4 rev 1.2 might give out serial over the usb-c port
<simpson> ISTR that IKEA had similar little bay-trays, maybe made out of wicker, but I can't find them in their online catalog.
<hexa-> with older revisions you'd have to go GND, TX, RX
<clever> hexa-: the rpi4 usb-c is wired to the legacy usb2.0 controller, and runs in gadget mode by default
<clever> hexa-: once linux has started, you could modprobe g_serial and turn it into a serial port
<clever> or g_ether, and do ethernet over usb
<hexa-> but gadget mode won't work before the rev 1.2 fixes, no?
<clever> hexa-: gadget mode should work on any mode, the fix is just for certain usb-c chargers to even turn on
<hexa-> oh, i thought that affected the usb-c smartness in general
<clever> hexa-: if you use a C->A adapter, all that smartness is ignored
<clever> and the C port is only 1.0 and 2.0, so you never had any 3.0 to loose
<clever> the bigger problem though, is that linux cant even boot, when powered over usb-c from my desktop
<clever> it doesnt get enough current
<hexa-> clever: uh, so. Should 5.7-rc6 work?
<hexa-> 5.7-rc4 didn't
<clever> hexa-: ive not tried 5.7 yet
Valodim has quit [Quit: ZNC 1.7.5 - https://znc.in]
Valodim has joined #nixos-aarch64
Valodim has quit [Quit: ZNC 1.8.0 - https://znc.in]
zupo has joined #nixos-aarch64
Valodim has joined #nixos-aarch64
<gchristensen> anyone mind taking a look at this order, to see if I'm missing anything obvious?
<gchristensen> https://gsc.io/snaps/70554a66-d087-407c-b762-55bf56d1a408.png + https://gsc.io/snaps/667767ff-709e-459b-a9f8-21ead0ea3c45.png and I already have: a USB hub for the serial, 4 ethernet cables, and a power strip.
<hexa-> uh, get samsung evo+ sd cards instead, paid 12 € for the 64GB version and it's good on 4k random writes
<hexa-> the usb ttl cable is not cheap
<gchristensen> nice
<Valodim> gchristensen: relatedly, I've recently laser-engraved an aluminium pi case: https://my.amazin.horse/picase.jpg
<Valodim> if you're interested, I'll make one for you :)
<gchristensen> I'm not sure I can swing 64g, but 32g samsung evo+ is definitely workable
<Valodim> just as a thanks for your work on nix.
<gchristensen> Valodim: I would _love_ that!
<gchristensen> :o it is beautiful
<Valodim> the picture doesn't even do it justice imo. laser-engraved metal just feels super nice :)
<Valodim> same offer to anyone else who's been involved in nix, particularly on pis. samueldr perhaps? ^
<clever> gchristensen: the rpi4 supports usb and network boot, so you could just omit the SD cards
<gchristensen> updated list: https://gsc.io/snaps/fa833564-e5fa-4884-b018-249a1b2e411c.png + https://gsc.io/snaps/fc9ce13a-fbf3-4bc0-a13b-4d9797253660.png hexa- wdyt? am I missing anything obscenely obvious that I'll be kicking myself for forgetting?
<clever> gchristensen: personally, ive also been using a heatsink case
<hexa-> gchristensen: network cables, duh :D
<Valodim> gchristensen: query me a shipping address?
<hexa-> same, I'm running mine in a flirc case
<clever> gchristensen: https://www.sparkfun.com/products/15773 this makes the pi extra durable
<gchristensen> oh nice, clever
<gchristensen> I don't think I have that much budget :(
<simpson> Guh, I wish I could buy new hardware.
<clever> gchristensen: you can probably find cheaper matching cases on other sites, sparkfun tends to be a bit more expensive i find
<simpson> I'm not allowing myself to buy new hardware until I've finished setting up a homelab with what I've got. But wow are those nice.
<gchristensen> (<3 sparkfun, though)
<clever> gchristensen: and the SD cards are optional, since you can netboot
<gchristensen> aye
<gchristensen> thanks, everyone :)
<gchristensen> I added network cables
<clever> gchristensen: what about the cost difference between a usb stick and a uSD?
<gchristensen> oh does that work nicely?
<clever> gchristensen: they just released the beta usb booting on the 15th
<hexa-> you'd need one sd card to update the eeprom
<clever> yeah
<gchristensen> ah cool
<Valodim> clever: same offer to you ^
<clever> Valodim: oooo, fancy!
<clever> Valodim: which models does it work on?
<Valodim> I'm using it for a pi4, would have to check for others
<adisbladis> clever: That heatsink case looks super nice
<clever> Valodim: my 4 has a good heatsink already, which isnt really able to be engraved, due to having fins on both sides
<clever> Valodim: though i have a naked rpi1 (with only 2 usb ports)
<clever> its old enough that they where still setting the revision with pullup resistors, lol
<adisbladis> clever: I've never had a Pi that didn't :P
<Valodim> eh. actually I might have to get back to you on that offer, the case seems to be sold out right now :(
<Valodim> it's this one, https://vilros.com/products/vilros-raspberry-pi-4-compatible-self-cooling-heavy-duty-aluminum-case but they're not shipping to europe and it's not in stock at amazon right now
<Valodim> drats
orivej_ has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-aarch64
<ashkitten> Valodim: wow, that pi4 case looks nice
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
<Valodim> it's pretty sweet yeah :)
<Valodim> sadly it seems I'll have to wait until for a restock to get more I can send to people
zupo has quit [Ping timeout: 256 seconds]
alp has quit [Remote host closed the connection]
alp has joined #nixos-aarch64
orivej_ has joined #nixos-aarch64
orivej has quit [Read error: Connection reset by peer]
orivej has joined #nixos-aarch64
orivej_ has quit [Read error: Connection reset by peer]
evils has quit [Quit: Lost terminal]
evils has joined #nixos-aarch64
spacekookie has joined #nixos-aarch64
<spacekookie> I'm trying to build an android app on nixos that has some native code and it's failing to find "aarch64-linux-android21-clang". I checked with {^_^} but it couldn't find any package that provided it. Is there some cross compling setup I'm missing to make this work?
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
<samueldr> clever: I'll need to take a look I guess
<clever> samueldr: Tenkawa also reports that MMIO via /dev/mem works just fine, which makes my problem even weirder, how can it work on mainline linux, but fail on the fork? lol
alp has quit [Remote host closed the connection]
alp has joined #nixos-aarch64
* clever heads off to bed
orivej_ has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-aarch64
alp has quit [Ping timeout: 256 seconds]
alp has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Ping timeout: 246 seconds]
pat_h has joined #nixos-aarch64
pat_h has quit [Client Quit]
zupo has joined #nixos-aarch64
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 272 seconds]
zupo has joined #nixos-aarch64
<ashkitten> hmmmmmm
alp has quit [Ping timeout: 272 seconds]
<ashkitten> google-marlin doesn't have an sd slot so i'm trying to see if somehow i can boot to mobile-nixos via usb otg... doesn't really seem to be booting, though the drive light is flashing a lot
<ashkitten> this is very silly because i have to quickly swap to the usb otg cable after `fastboot boot` before the nixos logo shows up
<samueldr> pretty sure usb otg should work
<samueldr> yeah, silly you're right... but it waits until the partition is available, so even if you were slow, it should be fine
<ashkitten> well the logo disappeared and soon after the drive stopped flashing
<ashkitten> oh, that's good
<ashkitten> hmm the screen's still black
<ashkitten> and it rebooted to the qcom charging screen
<samueldr> that should mean it kernel panic'd
<samueldr> you should figure out how to get the console ramoops using adb
<ashkitten> i need twrp for that
<ashkitten> what's the file path?
<samueldr> in theory the running android rom should also have those, but you might not be able to access them
<ashkitten> oh huh
<samueldr> it's somehwere like /sys/fs/pstore and from there on it should be obvious
<ashkitten> thanks
<ashkitten> uhhhh i have a file pmsg-ramoops-0, but it looks corrupted to all hell
<ashkitten> so that's not useful
<samueldr> yeah, I have trouble here in getting those consistently
<samueldr> but I don't know if I'm doing something wrong
<samueldr> and I don't know if booting into that battery charging bootimg can affect it
<samueldr> pro-tip: that's a "full" linux system that's used to show those images!
<samueldr> it's basically running the bootimg with a command line parameter
<ashkitten> i need a faster flash drive
<ashkitten> i don't know where my gf's usb 3 flash drive is
<samueldr> if it kernel panic'd, that means that something happened, as the boot process doesn't handle the partition never showing up and it would have instead been stuck on the boot logo
<ashkitten> nah i think it's actually booting, it's just incredibly slow because it's off a crappy 2.0 drive
<samueldr> it could also be that the linux kernel somehow resets the otg port on which it's reading files from!
<ashkitten> maybe
<ashkitten> i will try to find out if it does it again
<ashkitten> i see a mouse cursor 👀
<ashkitten> ayyyy
<samueldr> nice!
<ashkitten> tiny mouse cursor tiny gui
<samueldr> first confirmed OTG boot, never tried it beforehand, but assumed it should work
<ashkitten> hell yeah
<ashkitten> now i can test things for you if you want
<ashkitten> i probably won't do much in-depth stuff like i was trying before, but we'll see
<samueldr> at least now you know it's possible
<samueldr> or, more to the point, know *how*
<samueldr> theory and practice, in theory is the same, in practice...
<ashkitten> it'd be nice if i had an otg adapter that didnt need power
<samueldr> that didn't need power?
<samueldr> are you using a type-c usb hub, with type-c PD input?
<samueldr> in my experience they don't require power, but at least it's transmitted to the device when used
<samueldr> (well, they require power for the display out to work when they have display out)
<ashkitten> this 100% needs power
<samueldr> hm, not nice
<ashkitten> whether or not it should, is a different question
<ashkitten> i wish this phone had an sd card
<samueldr> I was wondering if it was rather that you were using one of those A-to-C adapters, which those can't allow charging at the same time
<samueldr> it gets annoying fast when you're racing with the battery power to debug :)
<ashkitten> no, this one has external power and apparently the phone can't provide power through it
<samueldr> type-c is fun
<ashkitten> lol, yep
<ashkitten> welp, back to android
<ashkitten> fun experiments
<ashkitten> samueldr: you haven't done anything with hybris or halium or anything right? i don't know when you said you were looking into that
<samueldr> it's coming up, but I'm stuck shaving a yak that regrew its hair
<ashkitten> uh oh
<samueldr> I wanted to reduce the amount of C I've written, by using libffi to interact with a library instead of C bindings
<samueldr> but just now I've realised one fatal flaw
<samueldr> pkgsStatic
<samueldr> and I'm not sure there's a good solution
<ashkitten> not sure i understand fully
<samueldr> still need to test things out here
<ashkitten> but that sounds rough
<samueldr> libffi will dlopen and use symbols from a .so file dynamically
<ashkitten> oh, i see
<ashkitten> so you can't statically link *and* use libffi
<samueldr> so you can say "this .so has a function foo with signature void foo(x, y, z)"
<samueldr> and then you can just use it
<samueldr> but yeah
<samueldr> I'm still looking in what's going on
<samueldr> though I have some hopes that it's as dumb as stripping
<samueldr> and use symbols in the current executable rather than dlopening
<samueldr> but I'm kinda flying by the seat of my pants for that right now
<samueldr> I really want to go through libffi instead as it reduces the risks of me doing more bad things
<ashkitten> samueldr: would you consider adding support for dual booting android with mobile nixos?
<samueldr> I have thought about it a bit, and I would like it for it to be possible, but I don't have a clue how to make that work nicely
<ashkitten> ah yeah
<ashkitten> maybe could replace the recovery image with mobile nixos bootloader?
<samueldr> "boot as recovery" is annoying here
<samueldr> newer devices, like pixel2 onward for google's own, there is no more recovery partition
<ashkitten> i'm not sure how to install just a recovery with that, yeah
<ashkitten> pixel1 even
<samueldr> oh
<ashkitten> i'm using google-marlin
<samueldr> I assumed
<samueldr> the way it works, the android bootimg holds the kernel, and the recovery initrd; it directly mounts system
<samueldr> on a normal boot it doesn't use the initrd
<ashkitten> twrp somehow patches the boot image for that, but i don't know what it does
<samueldr> flagrantly replaces the initrd :)
<ashkitten> can we do that?
<samueldr> possibly, but we'd be stuck with the android-platable kernel
<ashkitten> oh, but we can't use a normal android kernel, so we'd need to kexec
<ashkitten> right
<samueldr> so that one needs to *at least* allow kexec
<samueldr> it could be done
<samueldr> but then, *what* does it kexec?, userdata is encrypted!
<ashkitten> assuming we can't fit another kernel in the patched boot.img?
<samueldr> I'm sure there are solutions, it's simply not trivial :)
<samueldr> I think it could fit, but we need to fit a recovery initrd + a mobile nixos initrd in there I guess
<ashkitten> er, a stock initrd and mobile nixos initrd?
<ashkitten> we'd want to still boot android
<samueldr> stock (recovery) initrd and mobile nixos yeah
<samueldr> remember, normal boot skips recovery
<samueldr> oop
<samueldr> oops*
<samueldr> I see
<samueldr> no need for a recovery initrd I guess
<ashkitten> we want normal boot, recovery is mobile nixos
<ashkitten> right
<samueldr> (there is no stock initrd then, as normal boot skips initrd)
<ashkitten> okay, got it
<samueldr> might be possible, though I guess the last thing to fight with is userdata
<samueldr> can't touch system, can't touch any other partition
<samueldr> though I guess we could support that encryption scheme if we wanted to support dual booting
<ashkitten> i was assuming we would use an sdcard or otg device
<samueldr> oh
<samueldr> then it's less of an issue I guess
<ashkitten> yeah
<samueldr> the main things missing would be kexec in the android kernel into the mobile nixos one, with the same initrd, or something similar
<ashkitten> in theory we could probably support loopback mounting from a file on userdata if we wanted to mess with decryption, i guess
<samueldr> yeah, loopback is what I was thinking would be a solution if we wanted to mess with decryption
<ashkitten> many phones have sdcard slots though, so i assume the majority of people will use that scheme
<samueldr> I don't know what's the distribution of phones with sd card slots really
<samueldr> though yeah, for those that can, it would be usable that way
<ashkitten> also, if the android kernel doesn't support kexec maybe we should flip that around and kexec android from the mobile nixos kernel?
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<samueldr> that's another possibility
<ashkitten> then we could even present a boot selection gui or set a default boot option
<samueldr> yeah
<ashkitten> much more friendly than making the user select recovery whenever they want to use nixos
<samueldr> one issue, though, is applying OTAs AFAIK happens through recovery
<samueldr> not entirely sure for "pure aosp", but at least for LineageOS
<samueldr> so you're kinda stuck unable to update from Android unless we get into a convoluted scheme where recovery also sits within the image
<ashkitten> not on a/b, but boot does get overwritten
<ashkitten> i'm assuming we can do kexec entirely inside the boot partition even on non-boot-as-recovery devices, without touching recovery
<samueldr> I thought that on A/B too it ended up being installed through recovery, but I'm possibly off
<ashkitten> a/b it never boots to recovery, you install from inside the booted os and reboot to the new slot
<samueldr> the issue with kexec entirely inside the boot image with non-boot-as-recovery is that we need to fit the android kernel, its initrd, and our initrd contents :)
<ashkitten> yeah, and those partitions will be much smaller
<samueldr> yeah
<samueldr> motorola-addison has 16MiB to fit everything into
<samueldr> the kernel takes a bit over 8MiB since it's almost impossible to strip it down further
<samueldr> I think it's one of the worst case scenario
<samueldr> but still something to consider
<ashkitten> maybe we could offload the android kernel to somewhere else?
<ashkitten> or whichever kernel is booted second
<samueldr> that's what multirom manager did
<samueldr> but it was also using the fact userdata wasn't encrypted IIRC
<samueldr> (btw, it's probably a good starting point to see what are the issues)
<ashkitten> and we'd want android to be bootable without a nixos sdcard or otg storage, presumably, so we can't put it there
<samueldr> yeah
<ashkitten> very annoying problems, lol
<samueldr> just saying, I don't think I am going to implement it, it's not part of what's on schedule, but I am definitely open in getting a contribution that does this, and can help figure some things out even
<ashkitten> understandable
<samueldr> it would be really helpful for some
<ashkitten> for non boot-as-recovery devices it's as easy as replacing the recovery partition with mobile nixos, you just have to replace it with an android recovery in order to update that
<ashkitten> although, it might be possible to do something sneaky and figure out how to update android from mobile nixos to circumvent all of that
<ashkitten> or maybe we could kexec twrp from mobile-nixos
<ashkitten> lots of possibilities but i'm not sure i can actually implement it
THFKA4 has joined #nixos-aarch64
THFKA4 has quit [Changing host]
Acou_Bass has quit [Ping timeout: 265 seconds]
Acou_Bass has joined #nixos-aarch64