orivej has joined #nixos-aarch64
ris has quit [Ping timeout: 258 seconds]
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-aarch64
<craige> I've packed my spare Pixel 3 samueldr and one of my goals for Brno is to find time to boot mobile-nixos on it.
* craige flies out in about 6 hours
<clever> nice
<samueldr> craige: do you have a hack day ticket?
<clever> makes me want to mess with my kindle fire, but its pretty old
<craige> I like to thisnk I do, samueldr :-)
<craige> I'm pretty sure it's a "yes".
<samueldr> clever: depending on which, it might require opening up to hack
<insep[m]> clever: your kindle fire is too old to run systemd?
<clever> samueldr: hd 7" i believe
<samueldr> which hd 7 :)
<clever> i do have su on it already
<samueldr> I think they're up to the fourth hd 7 :D
<samueldr> right, so likely the 2015 one
<clever> i think its the first
<samueldr> I'm *pretty sure* that we'll have at least a small group at hackday for mobile-nixos shenanigans
<samueldr> and hopefully more than one device to get porting to :)
<samueldr> the 2017 version (iirc), codename austin, can be hacked to run stuff, though it needs to be started in a special mtk mode
* samueldr digs for repo
<craige> I can bring 3 Motorola Defy's samueldr :-)
<clever> model x43z60
<samueldr> sadly, armv7, so we won't be able to go to stage-2
<samueldr> there are some forks of amonet for other devices IIRC
<clever> so its basically an rpi2 with touchscreen and battery, lol
<samueldr> though, I'm pretty sure amazon does the OSS release
<clever> what exactly does amonet involve?
<samueldr> if it wasn't for the fact they don't allow unlocking the bootloader, it would be nice
<samueldr> clever: depends on the exact device
<samueldr> on mine it would involve opening its back, and booting it while shorting some test pads
<samueldr> yours, I think you could use it without
<samueldr> it looks like you have a 2015 one
<clever> ive already obtained root (both su or adb su)
<samueldr> yeah, thus why "it looks like" :)
<clever> i was able to `adb su` via an `adb restore` exploit
<samueldr> >> (Only 5th gen) Downgrade to 5.0.1 firmware via adb sideload in Amazon recovery, then proceed to use the left volume button to enter boot-rom.
<clever> ive never gotten into the bootloader stuff
<samueldr> yours would be miles more trivial to do than mine :)
<samueldr> I put mine aside to try, though
<samueldr> it's relatively low risk
<clever> the restore exploit, is to restore an app and directory, that contains 100's of files
<samueldr> AFAIUI the worst (fixable) thing that could happen can be fixed by just doing it again
<clever> and the permissions on the directory being restored are 777
<samueldr> then, the actual worst is something like accidentally shorting the wrong thing and releasing some of the magic smoke
<clever> then you setup a race condition, to replace the final file, with a symlink
<clever> (from a normal adb shell)
<clever> then the restore process opens the symlink, and blindly overwrites whatever it pointed to
<clever> typically, a config file claiming that android is running in a VM
<samueldr> craige: you're flying out awfully early... well... not that early when I think about it... only feels like it since it's still sunday here :)
<clever> which disables all security (and hw accel)
<clever> main thing i worry about, is bricking the fire, either soft or hard, as i replace the os
<samueldr> hm?
<samueldr> I gather you're still using it then
<samueldr> probably not a good thing to toy with in that case
<clever> not really, its been retired for a few years
<samueldr> ah
<clever> but id rather not brick it still
<samueldr> then it should be relatively safe, in your case, at any point you can put it in "boot rom" mode, where amonet can run any code on it
<clever> ah
<samueldr> amonet runs tethered from your computer
<clever> so the bootloader for recovery usage has been cracked wide open
<samueldr> not entirely sure of the details, but I think it's that that special mediatek mode has a flaw
<samueldr> so it's not even using the special mode, but using it to inject a payload
<samueldr> I had a look at the repo, it's generally straightforward how the big picture looks
* clever rips the back cover off
<samueldr> you don't even need to!
<clever> i see some special contacts for usbboot, reset, and power
<samueldr> yours has a bootloader that is signed by amazon that will enter in that special mode already
<clever> oh, and theres rx/tx!
<clever> ive had the cover off before
<samueldr> ah
<samueldr> carry on then :D
<gchristensen> craige: where do you travel from?
<clever> many many years ago, i tripped on the stairs, and rammed the corner of the tablet into a tile
<clever> the screen survived (thanks to having giant edges), but the covered had popped half off
<craige> .au, gchristensen
<clever> modern edgeless phones are at risk of damage :P
<samueldr> I'm thinking about setting up a tac switch through the back of my kindle fire if this is something fiddly I want to be able to re-use to repair bricks
<gchristensen> good long trip :)
<craige> "normal" :-)
<gchristensen> aye
<clever> samueldr: ive also heard rumors of shorting something in the usb port to trigger usb boot too
<samueldr> not rumours :D
<clever> samueldr: and it could be done with a special cable
<craige> There's a system, you just do it. Should be fresh when I get there gchristensen :-)
<samueldr> qcom and mtk (most of the time) all have a special way to do it via a cable
<samueldr> I acquired such a cable
<samueldr> though some devices can access the mode without a cable, just press the right sequence at boot
<clever> ah
<clever> but the amazon bootloader has an unsigned function to enter mtk mode?
<samueldr> and there, with qcom, during boot, it looks like it's bricked!
<samueldr> an amazon-signed bootloader has the function accessible through a key combo, which is likely an oversight
<samueldr> hmmm
* samueldr is wondering
<samueldr> would the mtk cable I ordered do the trick with the fire?
<clever> what was the combo to test things out?
<samueldr> >> (Only 5th gen) Downgrade to 5.0.1 firmware via adb sideload in Amazon recovery, then proceed to use the left volume button to enter boot-rom.
<samueldr> if you downgrade the bootloader, the tablet won't boot a more recent system
<samueldr> thus the note
<samueldr> >> NOTE: Using option two will brick your device until you have successfully finished the process.
<clever> left volume button?
<samueldr> here they're using the term "brick" when they should be using the term" unbootable-but-fixable-via-software
<clever> all of my buttons are on the same side, pow vol- vol+
<samueldr> heh, I figure the one that is to the left when in a specific orientation
<samueldr> so... either of those, if it doesn't, the other :D
<samueldr> though you'll need the 5.0.1 firmware
<clever> let me boot it up and see...
<clever> immediately on power-up, the bootloader shows the logo in portrait mode, with the buttons on the top
<clever> left volume is vol-
<clever> system version 7.5.1!
<clever> connectbot says i havent opened a local shell for 4 years
<samueldr> hah
<clever> `su` instantly works, i now have a root shell
<samueldr> hmmm
<samueldr> I figure you maybe can apply the same bootloader exploits from within the OS, though that's unlikely to be "ready to use"
<clever> heh, the static ip is still there!
<clever> [clever@amd-nixos:~]$ adb connect 192.168.2.23
<clever> and i'm in, from nixos
<samueldr> as expected
<samueldr> this is what the exploit ends up doing
<samueldr> AH
<samueldr> right
<samueldr> THIS is the one you may want to check https://github.com/chaosmaster/amonet
<clever> they both start by loading a payload
<samueldr> I'm not sure you would be able to write to the rpmb from within the OS
<clever> print(" * * * Remove the short and press Enter * * * ")
<samueldr> so it might require to be installed via tethered mode
<clever> i would expect it to have some ability to flash itself, for normal upgrades
<samueldr> it may happen before the OS is started, within the bootloader
<samueldr> like not even the recovery OS, but the bootloader itself
<clever> yeah, it could write a special file to a special partition
<clever> and the bootloader then does the flashing
<samueldr> while this exploit seemingly can write to the rpmb
<clever> reading the source, it looks like load_payload will exploit a bug, and execute a blob on the kindle
<clever> and everything after that point is talking to that blob
<samueldr> yes
<samueldr> and it's IMO generally safe
<samueldr> # Clear preloader so, we get into bootrom without shorting, should the script stall (we flash preloader as last step)
<samueldr> looks like you could alternatively clear the EMMC_BOOT partition
<samueldr> or at least enough of its header
<clever> brw------- root root 179, 8 2019-10-21 00:28 mmcblk0boot0
<clever> brw------- root root 179, 16 2019-10-21 00:28 mmcblk0boot1
<samueldr> likely not those
<samueldr> those AFAIUI are the rpmb thing
<samueldr> maybe not
<samueldr> hmm
<samueldr> anyway, those hardware partitions with emmc still elude me
<samueldr> ooh, new stuff since the last time I checked
<samueldr> there is a branch for the fire hd 8 (2018) which is aarch64
<clever> [clever@amd-nixos:~/apps/kindle]$ adb shell su -c "cat /dev/block/mmcblk0" > mmcblk0
<clever> [clever@amd-nixos:~/apps/kindle]$ blkid mmcblk0
<clever> mmcblk0: PTTYPE="PMBR"
<clever> fdisk says its an mbr table, with a single entry of type gpt, but it wont read the gpt part because its truncated
<samueldr> yeah, android devices generally are GPT with a protective mbr (PMBR)
<clever> [clever@amd-nixos:~/apps/kindle]$ adb shell su -c "cat /dev/block/mmcblk0" | pv > mmcblk0
<clever> 28.5MiB 0:00:10 [1.08MiB/s] [ <=> ]
<clever> now it can show progress and speed
<clever> a direct usb link is also way faster then wifi
<clever> one confusing thing, how is mmcblk0boot0 getting created?
<clever> what tells the kernel to boot more then a number into the partition field?
<samueldr> those are hardware partitions on the emmc
<samueldr> the kernel just shows them
<samueldr> they are a different area on the emmc
<samueldr> some devices will have those, while not using them
<samueldr> my chuwi tablet has those, and they are (apparently) not used, they are not even readable or anything iirc
<samueldr> oh hey
<samueldr> I saw mediatek preloader in lususb wizz by with that cable
<clever> one question, is the cable active or passive?
<samueldr> passive
<samueldr> resistors of a specific value IIRC
<clever> a good way to confirm that, boot the device with the cable, then once its in the right mode, switch to a normal cable
<clever> does the lsusb output persist?
<samueldr> aw, wrong boot mode
<samueldr> so it's an *additional* mode it looks like
<clever> so, if i'm reading this right, amonet should just unlock fastboot, and leave android in place?
<samueldr> "just"
<clever> and then fastboot lets you reflash any partition, without limits?
<samueldr> yeah
<samueldr> something along the lines
<clever> i have put clockworkmod onto a galaxy S3 before in the past
<clever> biggest nasty surprise, is that the stock bootloader can look similar, and doesnt strongly confirm before unpacking a zip file (and pre-wiping the device)
<clever> so if you try to re-apply su.zip, and dont notice the bootloader "fixed" itself, it will factory reset itself!
<samueldr> sucks that bootrom mode is not the same as that preloader mode
<samueldr> it would have been too easy :)
orivej has quit [Ping timeout: 240 seconds]
<clever> from what ive seen of android before, there are 2-ish bootloader menus (one is a menu to select things, the other is a boot rom to unbrick or factory flash it)
<clever> and then there is the recovery image, which is basically just dual-booting between "recovery" and android
<samueldr> yeah, recovery is a pared down linux os
<samueldr> not sure about your 2-ish bootloader menus
<clever> there is an extremely low-level one, that i think might be in a rom on the cpu itself
<samueldr> though those can differ depending on the OEM and/or SoC
<samueldr> ah, the qualcomm firehose mode
<clever> and then there is a slightly higher level one, that is on the mmc, and can actually bring the display online
<samueldr> well, qualcomm mode which can accept firehose programs
<clever> the rpi also has such a low-level boot rom
<samueldr> edl
<clever> if all other boot modes fail, the rpi can boot as a usb device
<clever> and you shove vc4 binaries over usb
<samueldr> the bootrom one from mtk is similar to the qualcomm edl
<samueldr> qualcomm edl requires signed programs to be uploaded to it
<samueldr> luckily a bunch of them have leaked or are genuinely distributed by OEMs
<clever> ive theorized that the rpi boot rom can also require signatures, if you burn a pubkey into the OTP bits
<samueldr> but at the same time, they allow complete control on the device
<clever> but the boards shipped to users dont have that key set, so they allow unsigned code
<clever> a legacy feature, from the cpu's says as a locked down telephony device
<clever> s/says/days/
<samueldr> set-top box
<clever> similarly, there is an extra mmu between arm "physical" and "true physical"
<clever> so you can prevent the arm cores from accessing certain regions of ram
<clever> which could be used to protect the vc4 firmware from a malicious (or hacked) linux kernel, after the user gains root
<clever> that could also prevent linux from being able to access mmio, so it cant reflash the bootloader
<clever> or read hdmi keys
orivej has joined #nixos-aarch64
FRidh has joined #nixos-aarch64
t184256 has left #nixos-aarch64 ["Disconnected: Replaced by new connection"]
t184256 has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sb0 has joined #nixos-aarch64
<sb0> hi. can I run 32-bit ARM binaries on Nixos AArch64?
<sb0> also, has anyone made the Raspberry PoE hat fan work with NixOS?
<sb0> I tried various things but it's having none of it
<sphalerite> sb0: depends on the CPU, but generally yes.
<sb0> sphalerite: raspberry pi 3b+
<sphalerite> yeah raspberry pis definitely can
<sb0> how do I do it? ld-linux-aarch64.so.1 fails with "wrong ELF class: ELFCLASS32"
<sphalerite> oh, these are foreign-distro binaries?
<sb0> is there a libc32 package that I can install?
<sb0> it's vcdbg, which is a proprietary raspberry pi binary
<sb0> trying to debug the fan issue
<sphalerite> not really, no
<sphalerite> easiest way would probably be a 32-bit alpine-or-similar chroot
<sb0> chroot works but then
<sb0> # ldd vcdbg
<sb0> Error loading shared library libdebug_sym.so: No such file or directory (needed by vcdbg)
<sb0> # apk
<sb0> Illegal instruction (core dumped)
<sb0> maybe I should just take the soldering iron and override the software fan control
<sb0> ffs
<sb0> okay the arm7 (instead of armhf) fs doesn't have the second problem
<DigitalKiwi> i feel like there's a joke in there "we'll patch it in software!" for a hardware problem
<DigitalKiwi> you're the anti-boeing
<sb0> and now this: Error relocating /firmware-master/opt/vc/lib/libelftoolchain.so: __strdup: symbol not found
sb0 has quit [Quit: Leaving]
ryantrinkle has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 264 seconds]
ryantrinkle has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 265 seconds]
zupo has joined #nixos-aarch64
ryantrinkle has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 268 seconds]
qyliss has quit [Quit: bye]
qyliss has joined #nixos-aarch64
qyliss has quit [Remote host closed the connection]
qyliss has joined #nixos-aarch64
ryantrinkle has joined #nixos-aarch64
orivej has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ris has joined #nixos-aarch64
FRidh has quit [Quit: Konversation terminated!]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
<samueldr> oops, M0 :)
<samueldr> still awfully neat
<gchristensen> yeah
<gchristensen> also this was 2yr ago
<samueldr> oh, right
<samueldr> and let's not forget most of the "cpus" in use are SoCs
<gchristensen> yeah
<samueldr> I don't know if M0 generally are SoCs or just the cpu
<gchristensen> true
<samueldr> lately I've been seeing stuff, it looks like memory chips are going to be the waaaaay bigger components in most mid-range systems
<samueldr> like those new chips for the new surface devices, be it the ryzen or the qualcomm ones
ryantrinkle has quit [Ping timeout: 240 seconds]
ryantrinkle has joined #nixos-aarch64
<t184256> opened a submission request for Nix-on-Droid to F-Droid, despite it violating the inclusion guidelines; wish me luck
<clever> t184256++
<{^_^}> t184256's karma got increased to 1
<samueldr> inclusion guidelines t184256?
<samueldr> ah, "some/all guidelines" and not "guidelines about inclusions", is that it?
<samueldr> anyway t184256++ for fun sillyness
<{^_^}> t184256's karma got increased to 2
<samueldr> at the very worst you could figure out a way to host the repo yourself
<t184256> software should not download binaries and/or include autoupdate mechanisms
<samueldr> ah, right
<samueldr> termux though
<t184256> oh, that's infinitely easier than submission to their repo
<clever> t184256: thats kind of the entire point of nix
<clever> t184256: and means fdroid shouldnt be a valid app in fdroid, lol!
<t184256> termux, anlinux, everybody and their uncle
<t184256> Oh shit
<samueldr> there's only termux that I *know* is on f-droid though :)
* samueldr thinks
<samueldr> someone without an aarch64 machine could bootstrap themselves with nix on droid for mobile nixos, lol
<samueldr> that's actually amazingly useful
<t184256> I doubt that
<samueldr> well, in theory
<clever> samueldr: someone in #nixos recently said they where able to cross-compile all of nixos to arm
<samueldr> how come?
<samueldr> all of nixos? I doubt it :)
<t184256> Compiling anything on my tablet is terribly slow
<samueldr> though enough to have the iso image and/or sd image going, I do think so
<samueldr> t184256: I was thinking about building with cache.nixos.org backing it
<samueldr> there's not that much to build for stage-2, most of it is taken wholesale from cache.nixos.org
<t184256> and until somebody shows me how to cross-compile, I'm stuck with what's already in binary cache
<samueldr> so it wouldn't be a quick experience, but would still be better than nothing
<samueldr> I'll have to try it out
<t184256> Well, building without compiling anything remotely big is feasible
<samueldr> it is one of my concern, I don't want to distribute images, but without it, it would become cumbersome for most users
<samueldr> and stupidly enough, stage-2 is trivially easy to build
<samueldr> it's stage-1 that has the most cost to build, but that can be cross-compiled
<t184256> But even tiny native libraries/binaries start from 10 minutes. I wonder how much is due to CPU performance and how much is due to proot overhead =/
<samueldr> oh, it's backed by proot?
<samueldr> now I see
<t184256> samueldr: why not distribute images?
<clever> t184256: ahh, proot based, *looks*
<samueldr> because it would mean having to build n images, where n is the amount of devices in mobile-nixos
<t184256> yeah, because otherwise I'll have to recompile everything *just* to change the /nix/store path
<samueldr> n could be cut back some, but not entirely
<samueldr> I guess SELinux on Android is what makes it impossible to run using a chroot with root privs?
<samueldr> (as an additional mode of operation)
<t184256> n doesn't sound bad if there are only k architectures and most derivations can be reused
<samueldr> still, I don't want to *have* to :)
<t184256> Um, if you have root, you can disable SELinux
<samueldr> the least amount of work I have to do, the better it is :D
<t184256> anhod mount something over /nix/store
<t184256> *and
<clever> t184256: ive looked at https://f-droid.org/en/packages/tech.ula/ before, but the ui seems klunky and kind of docker-y
<t184256> but playing by the rules is way more interesting
<t184256> anything special about this one or it it also proot-based?
<clever> its also proot based, but has buttons to auto-download a distro
<samueldr> btw, just making sure, I'm not being dismissive in saying "it's backed by proot?"
<samueldr> just as you said, playing by the (expected) rules is more interesting :)
<clever> i'm curious if user namespacing still works
<t184256> "the least amount of work I have to do, the better it is :D" - said the person behind mobile-nixos? wow
<samueldr> it's still true!
<samueldr> I'm a developer because I'm lazy
<t184256> clever: I wouldn't use 'still' for something that is not wide available yet
<samueldr> and android is getting in the way of my lazyness
<t184256> cannot compute
<clever> t184256: it works on any modern linux kernel, if debian hasnt patched it out
<clever> t184256: and modern android definitely uses root namespacing, to isolate apps further
<t184256> Last time I've checked, my shiny new 2016 tablet didn't have it.
<samueldr> heh, "shiny new 2016"
<samueldr> likely running a 2014 era kernel :3
<clever> Linux version 3.0.8-02825-g9e39b8c (ubuntu@ip-10-166-55-151) (gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #1 SMP PREEMPT Sat Aug 3 23:03:37 PDT 2013
<clever> from /proc/version
<samueldr> though I was highly surprised, the new redmi note 8 pro (IIRC) from xiaomi are mtk-based AND have a 4.14 (yes, fourteen) kernel
<clever> shell@android:/ # cat /proc/modules
<clever> bcmdhd 437056 0 - Live 0xbf00b000
<clever> atmel_mxt_ts 25085 0 - Live 0xbf000000
<clever> surprised to see modules on android
<t184256> Mine's 3.10
<t184256> samueldr: we seem to have absolutely polar opinions on what constitutes 'the least amount off work' =)
<t184256> One of the reasons I admire your work is how outlandishly hardcore your goals are
<samueldr> haha, though it's surprisingly straightforward up to now
* samueldr knocks on all wood-like surfaces
<t184256> it's like pmos is crossing an ocean on a small boat with 20 people, purism is crossing the ocean with a boat, two guys and a bag of money, and you are crossing the boat with a log all alone on a paddleboard with the absolute best high-tech paddle ever invented
<samueldr> you're missing the big picture, I'm hoping (and trying) to get all of us tied together
<samueldr> still not sure how to, but I hope to achieve a better dialogue between all projects, you have to add ubports, maemo leste, lune os, and halium, at the very least :)
<samueldr> there's a biiiiig chunk of commonalities that we need to figure out a way to build upon
<samueldr> like how I am working on a phone that's not available on other platforms
<samueldr> I want it to work easily on other platforms too
<samueldr> and vice versa
<t184256> that's a separate grandiose goal in itself
<samueldr> I wouldn't feel that my work in complete without a better dialogue/cooperation within those projects that do share a basic big chunk
<t184256> you're doing God's job, no doubt, but it sounds insanely big
<samueldr> and it's likely not going to be "my work" only to achieve this, but I hope, if it isn't already under way implicitly, or explicitly, that things can be nudged towards something good :D
<samueldr> I don't know if I will have coordinated my thoughts on the matter enough for the talk
<samueldr> hopefully yes
<samueldr> but there is an appeal to OEMs I want to do
<samueldr> to make sure they give the means to run whatever you want
<t184256> Call me pessimistic, but in my eyes, a goal of a Linux phone, let alone a big Linux phone ecosystem, needs resources thrown at it, and if someone asked me to estimate those efforts, I'd estimate them in Nokias
<samueldr> it will help success with resources thrown, but I think that is not something that a single company can do, since they provably seemingly can't :D
<samueldr> nokia with maemo being my "probably seemingly"
<samueldr> though there it may be that they have been poisoned by elop
<t184256> Note the 's' in 'Nokias' =)
<samueldr> I have a belief that it needs to come from "outisde" the companies
<samueldr> with the end-users in mind
<samueldr> not the end-product im mind
<t184256> Companies tend to cling to what they wrote
<samueldr> exactly, and they want to shrink wrap it for their needs
<samueldr> see tizen
<samueldr> while it's much more gnu/linux like, it's still entirely foreign, and unusable
<t184256> Maemo was marvelous for the first iteration
<samueldr> that it sure was
<samueldr> I had the N800 when it was new
<samueldr> even got a couple friends around me interested in it, not all of them being total geeks
<samueldr> at that point in time, an "internet tablet" was still an amazing new thing
<t184256> Yeah. Had a N800 and an N900, they were quite different beasts
<t184256> My point is, is Maemo sparked a couple of similarly sized efforts that also reused the traditional stack instead of piling up new alien stuff like crazy, that'd be freaking ideal
<t184256> *if
<samueldr> couldn't get n900 here, and if I would have, it wouldn't have worked well due to bands issues :(
<t184256> But, since it didn't happen, the pessimist in me is afraid of the 'Linux desktop'-style scenario
<samueldr> what I hope makes the difference here is that I want, as a goal, to make ports as cheap as possible
<samueldr> I'm willing to compromise on the ideal of mainline free libre oss everything
<samueldr> I rather have an install base of OEM kernels with some blobs to create a mass of users
<t184256> As in, more DEs than one can even follow, all of them doing something different, all of them unpopular
<samueldr> and *then* when the mass has enough inertia, working on the ideals
<samueldr> (thanks, talking about it I think I finally put into words my approach)
<t184256> Finally, someone who doesn't try to capitalize on 'libre everything' while sacrificing usability
<samueldr> what good is a libre system that no one will/can use?
<samueldr> I could have spent a godawful amount of time forward porting my zenfone 2 laser to mainline linux
<samueldr> and likely lose support for some of the useful features
<t184256> Gathering investments before going out in a puff of smoke, obvs
<samueldr> and have no one to help
<samueldr> meanwhile I have spent the least amount of time I could on the kernel port, it works with a chunk of evidence everything can be made to work well
<samueldr> and I replicated the approach on 4 different android-based devices with success, in less time than estimated
<samueldr> the oneplus-oneplus3 port was mind-blowingly trivial and quick
<samueldr> (due to experience mainly I think)
<t184256> makes sense, if you want stuff to work. does not, if you're, for example, pmos
<samueldr> hm?
<samueldr> I believe they're halfway torn in between, though they do have mostly OEM kernels going on
<adisbladis> samueldr: Tbh the gemini porting experience was also pretty good
<t184256> if your primary goal is long-term support, you want stuff mainlined
<adisbladis> Except the obvious glaring omissions once you got into userspace :3
<samueldr> adisbladis: glaring omissions? what do you mean?
<samueldr> if you mean docs and porting guide: definitely!
<samueldr> this is scheduled as the next big bit of work
<adisbladis> samueldr: I mean like hybris not working
<samueldr> ah, then that's something else :D
<adisbladis> Yeah :D
<samueldr> you're at the same place than I am
<samueldr> and also, nice, I have not been able to work with MTK devices, I didn't know if there would be different stuff that wouldn't map
<t184256> everyone wants different things and everyone does it differently. wish you luck bringing us all together
<adisbladis> samueldr: Anyway, I'm hopeful to get hybris up and running once I get some more time to invest
<adisbladis> I _know_ that our hybris stuff is working since it worked on Gemian with nix-built applications
<samueldr> and one thing is clear: I don't spit on mainline. In fact I desire for mainline, but see that pragmatically we need a critical mass before working on that
<adisbladis> (I even checked which libs were loaded at runtime to make sure we didn't get gemian impurities)
<adisbladis> So I'm _very_ hopeful it's just a matter of getting that android container stuff running
<adisbladis> Also my strace results would imply that it's the missing piece
<samueldr> yeah, I have a big question mark about those things
<samueldr> wondering how we'll end up implementing that
<samueldr> though also have time set aside exactly for that
<adisbladis> samueldr: Imho we should do the same as Halium
<samueldr> yeah, that was my first option
<samueldr> and likely the solution