<colemickens>
should I trust autoport's "mobile.usb.mode = gadgetfs" ?
<colemickens>
also, when grabbing the android-linux-stable sources to use, should I match the exact kernel config version from autoboot?
<colemickens>
or can I grab 4.9.237 instead of 4.9.223 like the config is for
tilpner_ has joined #nixos-aarch64
tilpner has quit [Ping timeout: 240 seconds]
tilpner_ is now known as tilpner
lafa has quit [Quit: Leaving]
rajivr has joined #nixos-aarch64
h0m1 has quit [Ping timeout: 272 seconds]
tilpner has quit [Ping timeout: 260 seconds]
justanotheruser has joined #nixos-aarch64
justan0theruser has quit [Ping timeout: 240 seconds]
iwq has quit [Ping timeout: 260 seconds]
LnL has quit [Quit: exit 1]
LnL has joined #nixos-aarch64
LnL has joined #nixos-aarch64
cole-h has quit [Quit: Goodbye]
justanotheruser has quit [Ping timeout: 240 seconds]
cole-h has joined #nixos-aarch64
knerten1 has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
iwq has joined #nixos-aarch64
knerten has quit [Ping timeout: 272 seconds]
orivej has quit [Remote host closed the connection]
h0m1 has joined #nixos-aarch64
orivej has joined #nixos-aarch64
<colemickens>
I've tried with three kernel builders and I always just get: arch/arm64/Makefile:67: *** CROSS_COMPILE_ARM32 not defined or empty, the compat vDSO will not be built. Stop.
knerten has joined #nixos-aarch64
knerten has quit [Remote host closed the connection]
<samueldr>
colemickens: yes for mobile.usb.mode
<samueldr>
colemickens: it's either android_usb, for older devices, or gadgetfs, for newer devices
<samueldr>
and it's entirely detectable from the kernel config file
<samueldr>
so it's pretty reliable
<colemickens>
Ok
<samueldr>
you don't need to match the kernel version exactly
<samueldr>
I even noted that in the example PR, that there may be difficulties when doing so, if e.g. in my case lineageos modified something
<samueldr>
but I guess that ALS should be quite close to the OEM's config
<samueldr>
right, compat vdso is a known issue
* samueldr
looks
<colemickens>
I tried disabling it in the config, but then I got stuck being told to normalize it even when the script wasn't changing the config...
<samueldr>
oh that's odd
<samueldr>
can you copy the config, kernel derivation and the message to an issue?
<samueldr>
that's a new thing, being forced to normalize, and in theory shouldn't have issues
<samueldr>
but yeah, in theory
<samueldr>
:| I really don't remember what was the issue with compat vdso
<samueldr>
other than disabling it
<samueldr>
colemickens: when you were disabling the kernel option, how were you doing it?
<samueldr>
because setting it to =n is not the way to go
<samueldr>
it has to be `# CONFIG_XXX is not set`
<samueldr>
because that totally makes sense
<samueldr>
which is different than leaving the config out!
<samueldr>
looks like all config.aarch64 files in mobile nixos have it disabled
<samueldr>
so it might have been just about disabling it?
<samueldr>
oh, you already had filed an issue I see
<colemickens>
okay, thanks for the tips so far, trying with this suggestion.
<samueldr>
I really want to know about =n
<colemickens>
Sorry, yes, you assumed right
<colemickens>
I was doing =n
<samueldr>
because if it's a common mistake, I'll make it an error
<colemickens>
I've updated it to be the # CONFIG_XXX is not set style.
<colemickens>
I'll let you know if I get pass the normalization error and/or if I get past the vDSO error with it "is not set".
<samueldr>
great
<samueldr>
btw, the rndis gadget too is detectable
<samueldr>
the value for blue* pixels are 99.9% sure good
<samueldr>
out of my five known data points, it was definitively something that could be detected
<samueldr>
ugh, I should get to fixing the documentation regression
<samueldr>
because the site is not updating :)
<colemickens>
I used the clang builder, if not I get an error that implies I must use clang
<colemickens>
when I use `mobile-nixos.kernel-builder-clang_9`, I get: `Cannot use CONFIG_LTO: -flto -fvisibility=hidden not supported by compiler`
<samueldr>
google used clang 11
<samueldr>
look in misc.json, there's the kernel version string from the OEM :)
<samueldr>
hmmm... I should have named it something like autoport.misc.json instead
<colemickens>
and another build kicked off. probably time for an errand, this one will take a while
<colemickens>
thank you, as always, for the interactive help and detailed answers. I'll poke around for more hints in those files
<samueldr>
you're welcome
<samueldr>
it's quite a bit because I want other contributors to work with :)
alp has joined #nixos-aarch64
<colemickens>
I did the obvious thing to get clang11 and still get the same error
<samueldr>
though there's the added difficulty of using ALS, which could bring some discrepancies
<samueldr>
try unsetting CONFIG_LTO
* samueldr
looks for what it does
<samueldr>
looks like it's not part of mainline
<colemickens>
oh I'm not building mainline right now
<samueldr>
I know
<samueldr>
but I wanted to know what CONFIG_LTO did
<samueldr>
yours is more likely to be closer to that
<colemickens>
killed it, restarted it, ran much faster, kconfig can't explain that. looks like it's building now
<colemickens>
okay, I'll keep that bookmarked
<colemickens>
random question: would it be any harder than normal to pull a stage-2 over the network?
<samueldr>
what do you mean?
<colemickens>
with regular nixos, if stage-1 can get internet, it can more or less pull a squashfs to use for stage-2, right
<samueldr>
yeah
<samueldr>
nah
<samueldr>
shouldn't be much of an issue in theory
<samueldr>
if you can get internet, first problem :)
<samueldr>
(assuming recent android-based device)
<colemickens>
next question - does this "stuff" work with newer Android bootloaders? I had seen a comment regarding the mainline/blueline work that made it seem like booting with newer android platforms was harder?
<{^_^}>
mobile-nixos#42 (by kirelagin, 48 weeks ago, open): stage-1: Add support for rootfs on loop device
<samueldr>
I'd have to read about the "newer Android bootloaders" issues
<samueldr>
I have no idea
<samueldr>
I haven't seen anything that tells me it would be
<colemickens>
hm, it seems like if you don't mind Google Pay breaking you could get to the point where you could non-destructively test on a device that otherwise has a normal functional Android install on it
<samueldr>
even without squashfs or overlayfs
<samueldr>
you could have a type-c usb thumbdrive!
<colemickens>
ah
<colemickens>
right
<colemickens>
nice
<samueldr>
in fact I should make this a party trick for my main phone and keep a type-c drive ready
<samueldr>
haha, changing the CONFIG_LTO stuff also led to 100% cpu use
<colemickens>
cool, I got a boot img at least I think!
<colemickens>
had to borrow the "Image.gz" addition to get it to generate, seems.
<colemickens>
from the razer-cheryl2 example you linked
<samueldr>
yep
<samueldr>
sorry, I should have stated
<samueldr>
that bit was most likely needed
<samueldr>
IIRC there's another kernel that needed it
<samueldr>
something seems off to require specifically asking for Image.gz
<samueldr>
not sure if you don't have a stage-2 what will happen
justanotheruser has quit [Ping timeout: 246 seconds]
<colemickens>
I have to decide if I want to re-setup this phone since unlocking wipes data :(
<colemickens>
I understand why locking does but less so for unlocking.
<samueldr>
ah!
<samueldr>
I see
<samueldr>
it wipes as a last ditch effort to ensure you don't get bamboozled
<samueldr>
if you were to follow some kind of "microsoft scam call" and following their steps
<samueldr>
and to prevent "drive-by" unlocks
<samueldr>
if e.g. you didn't have a pin
<samueldr>
or if somehow someone got it from you while unlocked
<samueldr>
well, it won't stop drive-by unlocks, but will prevent an attacker from replacing the system without your knowledge and you using your data
<colemickens>
Yeah, makes sense.
<colemickens>
So is DRM expected to be hard? Will you be in new territory that pmos hasn't been in yet then?
<samueldr>
it's a question with no hard answer
<samueldr>
for the bits Mobile NixOS has created, DRM shouldn't really be hard
<samueldr>
maybe two weeks of work top for the LVGUI (fork of LVGL) stuff
<samueldr>
maybe less
<samueldr>
the issue is more about *everything else*
<samueldr>
AFAIUI, and I'm not sure I understand it all, the "software stack" of whatever PE (phone environment) you want to use is going to be aware of DRM
<samueldr>
I *think* xorg might be
<samueldr>
but at first glance things were not working (and segfaulting)
<samueldr>
I need to research a bit more about that
<samueldr>
though, if I understand things correctly, this might mean DRM-based rendering is either "more" hardware accelerated or easier to get accelerated
veleiro has joined #nixos-aarch64
alp has quit [Remote host closed the connection]
alp has joined #nixos-aarch64
flokli has quit [Ping timeout: 260 seconds]
flokli has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
cole-h has quit [Quit: Goodbye]
aforemny has joined #nixos-aarch64
alp has joined #nixos-aarch64
aforemny has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-aarch64
kahiru has quit [Ping timeout: 265 seconds]
kahiru has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
aforemny has joined #nixos-aarch64
tilpner has joined #nixos-aarch64
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64
tilpner has quit [Remote host closed the connection]
<betaboon>
are the aarch64 images not build on hydra for nixpkgs-20.09 ?
veleiro has quit [Remote host closed the connection]
<thefloweringash>
which was actually just a distraction from my main task: trying to debug why some callPackage-provided arguments are unspliced, but the rest are properly spliced.
<thefloweringash>
is there something weird about using (or misusing) newScope that can prevent splicing among sibling packages?
pbb has quit [Ping timeout: 246 seconds]
pbb has joined #nixos-aarch64
<betaboon>
thefloweringash: if i recall correctly there are some caveats for splicing when using overlays
evils has quit [Quit: Lost terminal]
aforemny has quit [Ping timeout: 256 seconds]
alp has quit [Ping timeout: 272 seconds]
Darkmatter66_ has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 240 seconds]
ninjin_ has quit [Remote host closed the connection]
<Ke>
a -> b means b || (a && b)
<Ke>
nix manual has language description with operators section
ninjin_ has joined #nixos-aarch64
knerten2 has joined #nixos-aarch64
knerten1 has quit [Ping timeout: 260 seconds]
<julm>
Ke: hmm, I read e1 -> e2 equivalent to !e1 || e2
alp has joined #nixos-aarch64
julm has quit [Quit: leaving]
julm has joined #nixos-aarch64
knerten1 has joined #nixos-aarch64
knerten2 has quit [Ping timeout: 246 seconds]
tilpner has quit [Quit: tilpner]
tilpner has joined #nixos-aarch64
<Ke>
oh right
cole-h has joined #nixos-aarch64
lafka has joined #nixos-aarch64
lafa has quit [Read error: Connection reset by peer]
knerten2 has joined #nixos-aarch64
lafathethird has joined #nixos-aarch64
knerten1 has quit [Ping timeout: 240 seconds]
lafka has quit [Ping timeout: 264 seconds]
alp has quit [Remote host closed the connection]
alp has joined #nixos-aarch64
Mirrexagon has quit [Ping timeout: 272 seconds]
alp has quit [Ping timeout: 272 seconds]
TheNumb has quit [Ping timeout: 240 seconds]
chessai has quit [Ping timeout: 260 seconds]
cstrahan has quit [Ping timeout: 260 seconds]
feepo has quit [Ping timeout: 260 seconds]
c00w has quit [Ping timeout: 272 seconds]
prusnak has quit [Ping timeout: 240 seconds]
angerman has quit [Ping timeout: 256 seconds]
claudiii has quit [Ping timeout: 240 seconds]
rajivr has quit [Ping timeout: 246 seconds]
elvishjerricco has quit [Ping timeout: 272 seconds]
alunduil has quit [Ping timeout: 260 seconds]
pkral has quit [Ping timeout: 272 seconds]
blackriversoftwa has quit [Ping timeout: 240 seconds]
dsal has quit [Ping timeout: 272 seconds]
davidtwco has quit [Ping timeout: 260 seconds]
Mirrexagon has joined #nixos-aarch64
NekomimiScience has quit [Ping timeout: 272 seconds]
NekomimiScience has joined #nixos-aarch64
dsal has joined #nixos-aarch64
prusnak has joined #nixos-aarch64
blackriversoftwa has joined #nixos-aarch64
TheNumb has joined #nixos-aarch64
claudiii has joined #nixos-aarch64
rajivr has joined #nixos-aarch64
chessai has joined #nixos-aarch64
angerman has joined #nixos-aarch64
pkral has joined #nixos-aarch64
feepo has joined #nixos-aarch64
c00w has joined #nixos-aarch64
alunduil has joined #nixos-aarch64
davidtwco has joined #nixos-aarch64
cstrahan has joined #nixos-aarch64
alp has joined #nixos-aarch64
knerten1 has joined #nixos-aarch64
elvishjerricco has joined #nixos-aarch64
knerten2 has quit [Ping timeout: 258 seconds]
knerten2 has joined #nixos-aarch64
knerten1 has quit [Ping timeout: 256 seconds]
rajivr has quit [Quit: Connection closed for inactivity]
noonien has joined #nixos-aarch64
Mirrexagon has quit [Ping timeout: 256 seconds]
Mirrexagon has joined #nixos-aarch64
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-aarch64
pkral has quit [Quit: Connection closed for inactivity]
aforemny has joined #nixos-aarch64
knerten1 has joined #nixos-aarch64
aforemny has quit [Ping timeout: 260 seconds]
knerten2 has quit [Ping timeout: 258 seconds]
aforemny has joined #nixos-aarch64
aforemny has quit [Ping timeout: 260 seconds]
lafathethird has quit [Quit: Leaving]
knerten has joined #nixos-aarch64
knerten1 has quit [Ping timeout: 260 seconds]
noonien has quit [Ping timeout: 240 seconds]
blackriversoftwa has quit [Ping timeout: 240 seconds]
cstrahan has quit [Ping timeout: 244 seconds]
alunduil has quit [Ping timeout: 244 seconds]
dsal has quit [Ping timeout: 260 seconds]
jackdk has quit [Ping timeout: 240 seconds]
prusnak has quit [Ping timeout: 272 seconds]
blackriversoftwa has joined #nixos-aarch64
feepo has quit [Ping timeout: 260 seconds]
davidtwco has quit [Ping timeout: 260 seconds]
NekomimiScience has quit [Ping timeout: 260 seconds]