justanotheruser has quit [Ping timeout: 244 seconds]
justanotheruser has joined #nixos-aarch64
heywoodlh has quit [Quit: WeeChat 2.9]
CyberManifest has quit [Quit: Leaving...]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
justanotheruser has quit [Ping timeout: 244 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
cole-h has quit [Quit: Goodbye]
juliosueiras has quit [Ping timeout: 244 seconds]
orivej has quit [Ping timeout: 256 seconds]
alp has joined #nixos-aarch64
juliosueiras has joined #nixos-aarch64
juliosueiras has quit [Ping timeout: 240 seconds]
zupo has joined #nixos-aarch64
CyberManifest has joined #nixos-aarch64
alp has quit [Ping timeout: 244 seconds]
CyberManifest has quit [Remote host closed the connection]
CyberManifest has joined #nixos-aarch64
alp has joined #nixos-aarch64
Acou_Bass has quit [Ping timeout: 260 seconds]
evax has quit [Ping timeout: 264 seconds]
Acou_Bass has joined #nixos-aarch64
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
evax has joined #nixos-aarch64
wavirc22 has joined #nixos-aarch64
Darkmatter66 has joined #nixos-aarch64
Darkmatter66_ has quit [Ping timeout: 260 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Ping timeout: 244 seconds]
zupo has joined #nixos-aarch64
CyberManifest has quit [Quit: Leaving...]
orivej has joined #nixos-aarch64
juliosueiras has joined #nixos-aarch64
patagonicus has quit [Read error: Connection reset by peer]
alp has quit [Ping timeout: 240 seconds]
LnL- has joined #nixos-aarch64
LnL- has joined #nixos-aarch64
davidtwco_ has joined #nixos-aarch64
alunduil_ has joined #nixos-aarch64
patagonicus1 has joined #nixos-aarch64
claudiii_ has joined #nixos-aarch64
claudiii has quit [Ping timeout: 272 seconds]
Adluc has quit [Ping timeout: 272 seconds]
davidtwco has quit [Ping timeout: 272 seconds]
alexarice[m] has quit [Ping timeout: 272 seconds]
alunduil has quit [Ping timeout: 272 seconds]
blackriversoftwa has quit [Ping timeout: 272 seconds]
simpson has quit [Ping timeout: 272 seconds]
samueldr has quit [Ping timeout: 272 seconds]
claudiii_ is now known as claudiii
gchristensen has quit [Ping timeout: 272 seconds]
blackriversoftwa has joined #nixos-aarch64
davidtwco_ is now known as davidtwco
gchristensen has joined #nixos-aarch64
alunduil_ is now known as alunduil
samueldr has joined #nixos-aarch64
simpson has joined #nixos-aarch64
Adluc has joined #nixos-aarch64
alexarice[m] has joined #nixos-aarch64
evax has quit [Ping timeout: 256 seconds]
evax has joined #nixos-aarch64
ninjin_ has quit [Ping timeout: 240 seconds]
ninjin_ has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
heywoodlh has joined #nixos-aarch64
heywoodlh1 has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
heywoodlh has quit [Ping timeout: 264 seconds]
<heywoodlh1>
samueldr: if you're online, I'm back at it again with razer-cheryl and attempting to build an image for it.
heywoodlh1 has quit [Quit: WeeChat 2.9]
heywoodlh has joined #nixos-aarch64
alp has joined #nixos-aarch64
juliosueiras has quit [Ping timeout: 244 seconds]
juliosueiras has joined #nixos-aarch64
juliosueiras has quit [Ping timeout: 246 seconds]
juliosueiras has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
bdju has quit [Read error: Connection reset by peer]
bdju has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
alp has quit [Ping timeout: 272 seconds]
zupo has joined #nixos-aarch64
<samueldr>
heywoodlh: what I'd do "next" would be to start by building my branch to verify it should build, then apply your configuration changes in chunks on top to see which is (or are) problematic
<samueldr>
assuming you are still where you were yesterday
<samueldr>
hopefully you can `fastboot boot twrp.img`
<samueldr>
>> Razer has disabled fastboot boot so there is no way to temporarily boot TWRP to perform an installation.
<samueldr>
bum
<samueldr>
what I'd do is to flash the WIP mobile nixos boot.img on one slot, and TWRP on the other
<samueldr>
and then you should be able to, in some way, get to the console ramoops
<samueldr>
/sys/fs/pstore/console-ramoops IIRC
<samueldr>
so, one thing I'm not entirely sure, is I don't know how long the console-ramoops survives
<samueldr>
so you might want to prep TWRP, flash mobile nixos, try to boot mobile NixOS and hope it bootloops into TWRP
orivej has joined #nixos-aarch64
<samueldr>
depending on the reason it bootloops for, you might or might not have a console-ramoops
<clever>
i have to wonder, could i use ramoops on the pi? the dram controller is reset, so it may begin to fade...
<samueldr>
no idea
<clever>
but i could always program the firmware to peek at the ramoops area
<samueldr>
clever: the actual driver is pstore
<samueldr>
there are multiple backends
<samueldr>
one of them is efi vars
<clever>
efi vars arent writeable on the pi
<samueldr>
I know
<clever>
since efi and linux would be fighting over /boot/
<samueldr>
so even if the actual one used for android devices doesn't work, there might be one that works for you
<clever>
but i guess i could just add my own backend, that ships the whole console to the firmware
<samueldr>
or you might be able to write one
<samueldr>
yeah
alp has joined #nixos-aarch64
<clever>
but firmware can only talk over serial, and the linux can already do serial console
<clever>
so why bother at this point
<samueldr>
debugging after the fact
<samueldr>
heywoodlh: there are three "big" failure modes with bootloops (if you don't see the mobile nixos logo)
<samueldr>
(1) the kernel doesn't even start
<samueldr>
that can happen if e.g. the device tree is not appended properly or other parameters like base address and stuff are not right in the device config
<samueldr>
it can also happen in some cases when built with the "wrong" compiler :/
<samueldr>
e.g. some kernel trees *need* to be built with an older gcc to boot, even if it builds successfully
<clever>
ive also had it happen when i build linux for SMP, but boot it on a non-SMP cpu
<samueldr>
one thing to check is which compiler was used to build the kernel
<samueldr>
>> %s version %s (ubuntu@ip-172-31-34-184) (gcc version 4.9.x 20150123 (prerelease) (GCC) ) %s
<samueldr>
this is done using `strings` on the uncompressed kernel image
<samueldr>
so it looks like they are using outright GCC 4.9, and not even LLVM
<samueldr>
recent android devices seem to build off of the android fork of LLVM
<samueldr>
heywoodlh: first thing to try `mobile-nixos.kernel-builder-gcc49`
<samueldr>
instead of the "naked" kernel-builder
<samueldr>
I see that in my not-exaclyt-working WIP branch for cheryl2 I was building with 49
<samueldr>
which might be a big clue
<samueldr>
(2) the kernel starts but fails before running init
<samueldr>
this in theory should write stuff to the console-ramoops
<samueldr>
since the kernel is running
<samueldr>
except if it's like reaaaally early and even fails to setup the pstore
<samueldr>
pretty much anything could cause that, without logs it's hard to diagnose
<samueldr>
(3) the kernel runs init, and init fails, killing the kernel
<samueldr>
this is sure to put stuff in console-ramoops
<samueldr>
though there is an open issue with writing to the kernel message log as init, it seems to cause issues
<samueldr>
so for the time being *that* needs a bit of helping to debug, but if you have the ramoops for it, it's 100% solvable
heywoodlh has quit [Ping timeout: 264 seconds]
<samueldr>
and just checked, using -gcc49 to build the kernel builds, so it's a plausible way to go
alp has quit [Ping timeout: 272 seconds]
AmandaC has quit [Remote host closed the connection]
AmandaC has joined #nixos-aarch64
heywoodlh has joined #nixos-aarch64
jumper149 has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Thra11 has quit [Ping timeout: 258 seconds]
zupo has joined #nixos-aarch64
<heywoodlh>
samueldr: sorry, just saw your messages now
<samueldr>
nah, no worries
<heywoodlh>
Just switched the compiler. Rebuilding now
<samueldr>
I think what I described can keep you occupied for a small while :)
<heywoodlh>
Well, okay, hopefully using the other compiler you suggested helps
<samueldr>
good thing to know: OEMs are often beasts of habits
<samueldr>
so often if it holds true for their previous device or their next device, it holds true for that one
<samueldr>
even if another OEM's device has different quirks
<heywoodlh>
Yeah, that makes sense. I don't have a Razer 2 but it would be great if we do get this working for the other Razer 2
<samueldr>
since cheryl2 seemingly needed it
<samueldr>
I'll probably end up checking this back again once I'm done with work for cheryl2
<heywoodlh>
Just curious (for purely selfish reasons) do you think you'll ever target the other Pixel models? I noticed LineageOS and GrapheneOS recently released ports for various Pixel 3's and 4's.
<samueldr>
heywoodlh: if I have the hardware for it :)
<samueldr>
(or if a contributor contributes the port)
<heywoodlh>
Nice. Well, if I get this working on the Razer and it works well for me I may just end up throwing it on my spare Pixel 4.
<heywoodlh>
(I have too many spare phones :)
<samueldr>
all ports I made (10/12) are hardware devices I have around
<heywoodlh>
Right now I'm running GrapheneOS on my Pixel 4 and I really like it.
<samueldr>
either bought for the project as good potential targets, or before I owned them already
<heywoodlh>
Sure, that makes sense.
<samueldr>
like cheryl2 was me previous day-to-day phone
<samueldr>
my*
<samueldr>
(its squaredness ended up annoying in my jeans pocket)
<heywoodlh>
Ah, that makes sense.
<heywoodlh>
My daily driver is an iPhone. But I have this excessive habit of keeping an Android that's been debloated with me as well.
<samueldr>
I haven't publicly stated it, but I can make ports happen if I'm provided with devices or the means to get a device... but without guarantees because we never know what a specific device can do :)
<samueldr>
x018d was kind of the first of those devices; with github sponsors money I bought what looked like a safe mediatek device
<heywoodlh>
Haha yeah, I can see how that would be the limiter.
<samueldr>
safe because (1) oem provides sources (2) can be unbricked trivially
<heywoodlh>
Sure
<samueldr>
and begonia was a phone a friend of mine was using, but didn't end up liking and was donated to the project
<heywoodlh>
Have you been able to get a NixOS phone working somewhat as a daily driver?
<samueldr>
not yet
<samueldr>
I have a couple milestones to get through for that
<heywoodlh>
I saw your NixCon talk but since it's been some time I'm guessing you've made some progress.
<samueldr>
(1) encrypted FS... which is not an issue... except there is no interface to input a passphrase!
<samueldr>
that's the main yak shave
<samueldr>
(2) making it useful
<samueldr>
which means telecom comms, so 3G/4G
<samueldr>
also means *some* kind of power management figured out
<heywoodlh>
I was curious about 3G/4G connectivity. Are there Linux packages that provide that kind of functionality? Or should using an OEM kernel provide that.
<samueldr>
literally haven't looked yet
<samueldr>
(haven't looked at power management yet*)
<samueldr>
for modem functionality, I have some ideas of the feasability, but still need to spend actual time investigating the situation
<samueldr>
for android-based devices
<heywoodlh>
The image finished building but now I've got to figure out how to get my Razer back into Fastboot.
<heywoodlh>
Since it bootloops it doesn't seem to like the volume down+power keys
<heywoodlh>
I got it
<samueldr>
good
<samueldr>
that was concerning for a hot minute
<heywoodlh>
Did the commands I sent you in the email look okay for flashing?
<samueldr>
looked okay yeah
<samueldr>
though some devices IIRC don't allow flashing to *_a and *_b separately and requires --slot=a and --slot=b
<samueldr>
but I guess yours allows it
<samueldr>
generally qualcomm devices don't need the power button to be held, only the volume key to be held when powered up
<heywoodlh>
Cool. It would probably be good to get the partitioning setup properly but I can do that once I figure out how to get it working.
superherointj has joined #nixos-aarch64
<heywoodlh>
That is what I figured out lol
<samueldr>
e.g. you could have it powered down, hold the correct volume key, and plug a usb cable
<heywoodlh>
Yeah, that's what I had to do
<samueldr>
if you're ever tempted to mess with the partition scheme of an android device
<samueldr>
DON'T
<samueldr>
it's highly likely you'll end up bricking it
<samueldr>
and most android devices can't be at all, or can't be trivially unbricked once bricked that way :)
<heywoodlh>
Good to know.
<heywoodlh>
With a device that's bootlooping is there a way to retrieve logs to figure out the issue?
<samueldr>
maybe
<samueldr>
if you had flashed TWRP to one of the slots
<heywoodlh>
Well, looks like I'm back in the boot loop.
<heywoodlh>
Let me grab TWRP
<heywoodlh>
So do each of the slots allow you to basically dual boot on the phone? I've never understood the purpose of multiple slots.
<samueldr>
not intended for dual booting
<samueldr>
the intention is to slap a new boot image and system image in there
<samueldr>
and if it fails to boot on update, you go back to the previous one
<samueldr>
also allows them to write to the partition while the system is running
<samueldr>
so imagine you're running on partition A, OTA is downloaded, applied to B, bootloader told to boot from B, you reboot, it then tries to boot from B
<samueldr>
if everything works, yay
<heywoodlh>
Ohhhh that makes sense
<samueldr>
the system tells the bootloader the boot is successful
<samueldr>
if the bootloader is booted back, and it sees this is unsuccessful, it'll fall back to A
<heywoodlh>
Apparently the Razer doesn't have a recovery partition
<samueldr>
yep
<heywoodlh>
Gotta find how I flashed LineageOS' recovery
<samueldr>
it's using "boot as recovery"
<heywoodlh>
Ah
<samueldr>
for TWRP AFAIUI you can just flash it on one of the boot slots
<samueldr>
then you need to set it active
<heywoodlh>
K. I'll do boot_b
<samueldr>
which I'm not sure off the top of my head how
<samueldr>
basically, the boot image doesn't hold an initramfs anymore
<heywoodlh>
K, booted into TWRP recovery
<samueldr>
so the initramfs is the recovery
<heywoodlh>
I see
<samueldr>
and by default it skips initramfs
<heywoodlh>
So with TWRP what's the best way to find logs?
<samueldr>
adb shell and the path I said earlier
<samueldr>
/sys/fs/pstore/console-ramoops
<samueldr>
it should be under /sys/fs/pstore
<heywoodlh>
Great. Looking there now
<samueldr>
*if* the kernel tried to boot
<heywoodlh>
Hmm. Nothing
<heywoodlh>
So the kernel didn't try to boot
<heywoodlh>
So I was looking at your previous messages at those 3 possible reasons you gave for the boot not working.
<heywoodlh>
If the kernel isn't even loading what can I do to fix that?
<samueldr>
that's the hardest to debug
<samueldr>
one thing is to try to make it boot something
<samueldr>
let me rephrase
<samueldr>
because what I said means nothing
<heywoodlh>
Haha
<samueldr>
one of the things I try is take e.g. TWRP, unpack it, replace only the kernel, repack it
<samueldr>
if TWRP boots, it means that the kernel is good and something else is wrong
<samueldr>
it could be the appended dtbs
<samueldr>
uh no, it probably isn't the appended dtbs
<samueldr>
that's something else to check
<samueldr>
and not something I was faced with often :/
<heywoodlh>
So I already flashed TWRP and have booted that. Does that satisfy what you were suggesting?
<samueldr>
a thing to do is to verify all settings are correct in the device options
<samueldr>
you'd have to unpack TWRP, replace its kernel with the kernel you just built, and repack it
<samueldr>
it's a bit involved
<heywoodlh>
Oh, I understand what you're saying.
<samueldr>
you can't exactly boot mobile nixos with TWRP's kernel, so even if you try it probably won't work for multiple reasons
<heywoodlh>
Would it help if I flashed the image I built into an emulator and see if I can get it working that way?
<heywoodlh>
I suppose that would only help me figure out if the image actually works.
<heywoodlh>
This is probably a stupid question but could I flash the image to an emulated device in Android Studio?
<samueldr>
the emulated device would need another kernel entirely
<samueldr>
generally on android devices kernels are per-device
<heywoodlh>
Got it.
<heywoodlh>
I'm looking at TWRP to see if I can figure out how to replace the kernel
<heywoodlh>
I just noticed that /sdcard on the device has a bunch of random files in it. Could that be at all related to this? I've normally only seen files/folders in /sdcard that were like userland stuff such as Download, Pictures, etc.
<samueldr>
I don't think it would be
<samueldr>
nothing tries to mount the sd card in the boot process, normally, and you're not even close to be running commands to mount stuff AFAIUI
<heywoodlh>
That makes sense. Hmm. Well, do you have any suggestions on where to go from here or should I just give up? Haha. I definitely appreciate all the help so far.
<samueldr>
to be fair, I'd be stuck thinking about possibilities as much as you are, only with a bit more experience under the belt
<samueldr>
having a view over serial would help
<samueldr>
though it doesn't seem to be documented at all if it has some way to access it
<samueldr>
and if it does, it's likely to necessitate soldering on the motherboard anyway
<heywoodlh>
Yeah, it's too bad that there aren't any fastboot logs
<heywoodlh>
It would be awesome to know why fastboot isn't loading the kernel
<samueldr>
>> Say Y here if you want to be able to pass default arguments to the kernel. This will be overridden by the bootloader, if you use one (such as SILO). This is most useful if you want to boot a kernel from TFTP, and want default options to be available with having them passed on the command line.
<samueldr>
>> On some architectures there is currently no way for the boot loader to pass arguments to the kernel. For these architectures, you should supply some command-line options at build time by entering them here.
<samueldr>
>> Provide a set of default command-line options at build time by entering them here. As a minimum, you should specify the the root device (e.g. root=/dev/nfs).
<samueldr>
ugh
<samueldr>
that's confusing as hell!
<samueldr>
depending on the platform (arch/*/) of the kernel it means different things!
<heywoodlh>
So it looks like based on arch/arm64/Kconfig CONFIG_CMDLINE means this
<heywoodlh>
>> Provide a set of default command-line options at build time by entering them here. As a minimum, you should specify the the root device (e.g. root=/dev/nfs)
<samueldr>
yeah
<samueldr>
but as I said, don't change it
<heywoodlh>
Okay, I won't
<samueldr>
that's what the OEM kernel configured it as
<heywoodlh>
I'll leave it alone then.
<heywoodlh>
Do you think changing that offset may fix the issue if I rebuild the image?
<samueldr>
that's what I'm hopeful for
<heywoodlh>
K, I'll rebuild and see what happens.
<samueldr>
because if any of those are wrong, it's expected not to work
<heywoodlh>
Okay sweet! Glad to know I had a major misconfiguration in there.
<heywoodlh>
It's a comforting feeling to find the thing(s) you've done wrong when something isn't working.
<heywoodlh>
Vs having no idea
<samueldr>
not saying that it will for sure work
<heywoodlh>
Does the boot_a spot correlate with system_a and vice versa?
<samueldr>
yes
<samueldr>
well
<samueldr>
we don't deal with system partitions really for misc reasons in that way
<samueldr>
and you can still get far without flashing a mobile nixos system img
<samueldr>
it will stay stuck on the mobile nixos logo or stuck "booting"
<samueldr>
which is a good sign if it stays stuck without rebooting
<samueldr>
that means the kernel is running!
<heywoodlh>
That makes sense. Hopefully I at least get to that point now with the offsets corrected
justanotheruser has quit [Ping timeout: 244 seconds]
<samueldr>
yes, once the kernel is running it's generally *possible* to debug issues
<samueldr>
while when it's not running it's pretty hard
<heywoodlh>
I don't see any thing referencing compiler-gcc6.h. I copied that over from the oneplus three folder. I don't need that, right?
<samueldr>
if you needed it it wouldn't compile
<samueldr>
that's for older kernel releases generally IIRC
<heywoodlh>
Cool
<heywoodlh>
Gonna remove that then
bennofs_ has joined #nixos-aarch64
<heywoodlh>
General question: how would I go about upgrading the kernel for this? (Assuming I ever get it working)
<heywoodlh>
Because I'm guessing that Razer won't be releasing new kernels for this.
<samueldr>
you can actually brick the phone enough to require a "xiaomi representative" to fix it
<samueldr>
trivially
<samueldr>
basically xiaomi-begonia, instead of treating an ARB fail as a condition where it allows you to reinstall through fastboot, it bricks the boot entirely
<clever>
samueldr: guessing you need special keys to sign the recovery processes?
<samueldr>
clever: exactly!
<samueldr>
and challenge-response
<clever>
per-device maybe?
<clever>
ah
<samueldr>
which is horribly anti-consumer!
<clever>
and likely why the rpi4 has the same key on every board
<clever>
so a single recovery.bin unlocks all locks, and nobody even noticed the keys
<heywoodlh>
I love my Razer Phone but yeah, I started toying with porting NixOS to it because there aren't really any other ROMs out there for it besides Lineage
<heywoodlh>
Image built now, gonna flash and see what happens
<heywoodlh>
Do you want to get Nix on mobile to the point where one could use it as a daily-driver?
alp has joined #nixos-aarch64
<samueldr>
definitely
<heywoodlh>
samueldr: flashed boot.img to boot_a, system.img to system_a and system_b and still nothing
<samueldr>
from TWRP you can apparently reboot to a specific slot
<heywoodlh>
Specified Slot A in TWRP just now
<heywoodlh>
I am pretty sure it rebooted and then went into TWRP but wasn't watching too closely
<samueldr>
rebooting into slot a from TWRP should help ensure
<heywoodlh>
Yeah, it has rebooted a couple times now
<samueldr>
and back into TWRP?
<samueldr>
it should eventually go back into TWRP AFAIUI
<samueldr>
and then verify for console-ramoops
<heywoodlh>
Not yet. It's just looping now
<samueldr>
but that sounds like it would be a negative for console-ramoops
<heywoodlh>
Hmm. I put TWRP in the boot_b slot but it doesn't seem to want to boot into that now when I go into recovery mode. Let me manually set the active slot.
<samueldr>
I'm not sure when/how the A/B switch triggers on fails
<heywoodlh>
Yeah, it never switched back to B for whatever reason. I set it to slot b and then got into TWRP recovery.
<heywoodlh>
Before, it would just switch back over to TWRP recovery.
<heywoodlh>
With the previous images
<heywoodlh>
Still nothing in logs. Dang it.
<samueldr>
try switching to LineageOS' kernel
<samueldr>
just maybe
<heywoodlh>
That's what I was about to do as the next step
<heywoodlh>
Will I need to grab the kernel config and then apply the PostMarketOS configs as well like before?
<samueldr>
you can try a first run with the same exact config.aarch64 you're using
<heywoodlh>
Or do you think that the kernel config I have now should be sufficient
<heywoodlh>
K, I'll start with that
<samueldr>
should be sufficient
<samueldr>
but maybe you'll want to extract the config.aarch64 from a LineageOS boot image and diff it
<samueldr>
a good ol' [n]vim -d to see the differences
<samueldr>
and try to guess at what could be important or not
<heywoodlh>
K, I'll do that later. First, I'll start with the config I have and see what happens.
<heywoodlh>
How do I grab the SHA 256 sum of a commit on Github?
<samueldr>
,tofy
<{^_^}>
samueldr: Did you mean tofu?
<{^_^}>
To get a sha256 hash of a new source, you can use the Trust On First Use model: use probably-wrong hash (for example: 0000000000000000000000000000000000000000000000000000), then replace it with the correct hash Nix expected. For inserting 52 0's in vim: <esc>52i0<esc>
<samueldr>
,yes, thanks {^_^}
<heywoodlh>
Cool.
<heywoodlh>
Thanks!
<heywoodlh>
Hmm
<heywoodlh>
sh: line 1: /bin/nconf: No such file or directory
<heywoodlh>
That's definitely not going to work
<heywoodlh>
Any suggested workarounds? Again, sorry for the NixOS-noobness
<heywoodlh>
That's from when I ran `./bin/kernel-normalize-config razer-cheryl`
<heywoodlh>
It was while the LineageOS kernel stuff was attempting to build I believe
alp has quit [Ping timeout: 272 seconds]
<heywoodlh>
I have no idea what nconf is
<samueldr>
just checking, did you comment out / remove setSourceRoot?
<samueldr>
nconf is the tool used for make menuconfig
<samueldr>
the build that actually failed, its log is stored by nix
<samueldr>
that'll open it in less (or $PAGER?)
<samueldr>
you can search error:
<samueldr>
the colon is quite important as otherwise you hit other output less likely
<heywoodlh>
Hmm. Nix log doesn't seem to have anything
<samueldr>
ooh, though this is one that doesn't hit on "error:"
<samueldr>
heywoodlh: just be sure you used *your* proper output hash
<samueldr>
/build/source/build/../drivers/input/touchscreen/synaptics_dsx/synaptics_dsx_i2c.c:515: multiple definition of `synaptics_rmi4_bus_init'; drivers/input/touchscreen/synaptics_3708/built-in.o:/build/source/build/../drivers/input/touchscreen/synaptics_3708/synaptics_dsx_i2c.c:708: first defined here
<samueldr>
/nix/store/2dwkvf4dyj9jp2yjs5infh4qvya3llqs-aarch64-unknown-linux-gnu-binutils-2.31.1/bin/aarch64-unknown-linux-gnu-ld: drivers/input/touchscreen/synaptics_dsx/built-in.o:/build/source/build/../drivers/input/touchscreen/synaptics_dsx/synaptics_dsx_i2c.c:526: multiple definition of `__ksymtab_synaptics_rmi4_bus_exit'; drivers/input/touchscreen/synaptics_3708/built-in.o:/build/source/build/..
<samueldr>
/drivers/input/touchscreen/synaptics_3708/synaptics_dsx_i2c.c:721: first defined here
<heywoodlh>
Yeah I tried it on the paths that existed on my system
<samueldr>
the path won't exist
<samueldr>
(since it won't have built successfully)
<samueldr>
but yeah, from your log I presume
<samueldr>
checking out their kernel repo to have a quick peek
<heywoodlh>
Okay
<samueldr>
this looks like a case of having "versioned" drivers in their kernel
<heywoodlh>
I'm guessing you haven't added the PostmarketOS tweaks, right?
<samueldr>
I worked on top of your last push
<samueldr>
so since I only normalized it should have kept them
<samueldr>
I didn't extract their defconfig
<samueldr>
uh, their kernel config from a boot.img
<heywoodlh>
Okay, cool
<samueldr>
I only read their defconfig to see which one they chose
<heywoodlh>
Let's see what happens
<samueldr>
I wouldn't bet much on any difference
<samueldr>
but you never know
<heywoodlh>
Yeah, it would be awesome if it works with the Lineage kernel. But yeah, I could see what you are saying if there isn't much of a difference.
<heywoodlh>
Does each major Android version just go to the next LTS?
bdju has quit [Read error: Connection reset by peer]
<heywoodlh>
(I've never really noticed much about the kernel that Android uses in each release)
bdju has joined #nixos-aarch64
<samueldr>
it's a bit complex, and they're trying to change that
<samueldr>
but basically you get locked in to whatever LTS was the "current" from Google when the SoC vendor forks the kernel for their SoC
<samueldr>
rarely they do an upgrade
<heywoodlh>
I can see why they don't upgrade now. Seems like it's a big big hassle.
<samueldr>
and then ODMs and OEMs have to work from that tree
<samueldr>
oh it's terrible
<samueldr>
because everyone in the chain makes it harder
<samueldr>
since you also have to clue in sometimes components vendor!
<samueldr>
let's imagine ABC Touchscreens of All Kinds, a fictitious manufacturer of touchscreens
<samueldr>
they will provide a driver _for that kernel_, most likely, which is current
<samueldr>
so neither the OEM nor the SoC vendor provided that driver
<samueldr>
so if the OEM wanted to upgrade, they might have to get the touchscreen vendor involved
<samueldr>
though it's not the whole picture, because sometimes it's not the vendor themselves, but another second-party that does a "base platform"
<samueldr>
basically, there's too many cooks
<heywoodlh>
Yeah, that's crazy
<heywoodlh>
At the same time, it's a bit disconcerting to not get any visibility into iOS.
<heywoodlh>
Definitely drawbacks in most cases
<samueldr>
you're not owner of the hardware when you can't run your own code
<samueldr>
now, that's a "ladder of abstraction"
<samueldr>
the higher up you are the least control and the least ownership
<samueldr>
my opinion is that for basic respect of ownership you should be able to run an operating system
<samueldr>
for better respect, you should be able to change the boot firmware
<samueldr>
note that I'm not saying that they should _support_ the change, but make it possible