<fps>
hm, for some reason the openssh service doesn't survive a reboot
pbb has quit [Ping timeout: 246 seconds]
nschoe has quit [Quit: No Ping reply in 180 seconds.]
pbb has joined #nixos-aarch64
nschoe has joined #nixos-aarch64
<fps>
oh ok. it's because the new system generation isn't activated on boot
<fps>
oh, that's gonna be fun to debug ;)
<samueldr>
is /boot mounted?
<samueldr>
I believe the default image doesn't
<samueldr>
so if you based yours on it it wouldn't
<samueldr>
it's because of mismatched expectations between a u-boot based boot on most other supported arm platform, and that special raspberry pi bootloader setup
<fps>
ah drats, now the image doesn't boot properly anymore
zupo has quit [Client Quit]
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-aarch64
pbb has quit [Ping timeout: 260 seconds]
pbb has joined #nixos-aarch64
zupo has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
alp has quit [Remote host closed the connection]
alp has joined #nixos-aarch64
<fps>
ok, got it figured out. :)
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 256 seconds]
alp has quit [Remote host closed the connection]
alp has joined #nixos-aarch64
<thefloweringash>
I’m half way through debugging the binutils upgrade. I’ve discovered that the bug is in a call to objdump failing in the glibc build.
<thefloweringash>
When autoconf looks for symbols “checking for lchmod”, it tries to avoid glibc stubs by looking for symbols like _stub_lchmod
<thefloweringash>
Preprocessor symbols, that is.
<thefloweringash>
The glibc build with upgraded binutils has an empty stubs file. So we get a “yes” when we should get a “no”
<thefloweringash>
The step that produces the stubs header is full of errors like that one in the gentoo wiki.
<thefloweringash>
The change that was linked to lchmod requiring /proc to be mounted doesn’t seem to be part of the glibc version we use, so is unrelated.
<srk>
thefloweringash++
<{^_^}>
thefloweringash's karma got increased to 12
<thefloweringash>
Hack that comes to mind: add binutils_new (>= 2.32), redefine the bootstrap tools to use new binutils; make a branch that simultaneously updates the bootstrap tools and replaces binutils with binutils_new, thus never mixing 2.31 and 2.32
<thefloweringash>
I don’t have a good handle on how bootstrapping works. Maybe it would be enough to tack on a glibc rebuild with new binutils.
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
alp has quit [Ping timeout: 246 seconds]
ky0ko has quit [Read error: Connection reset by peer]
ky0ko has joined #nixos-aarch64
alp has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Darkmatter66 has joined #nixos-aarch64
Darkmatter66_ has quit [Ping timeout: 246 seconds]
nschoe has quit [Quit: No Ping reply in 180 seconds.]
nschoe has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
orivej has joined #nixos-aarch64
nschoe has quit [Remote host closed the connection]
nschoe has joined #nixos-aarch64
zupo has joined #nixos-aarch64
lordcirth has joined #nixos-aarch64
alp has joined #nixos-aarch64
alp has quit [Ping timeout: 256 seconds]
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…]
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
nschoe has quit [Quit: No Ping reply in 180 seconds.]
nschoe has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
<samueldr>
danielrf[m]: might need a chat at some point in the future when convenient for you to see what can be done... as it looks like LineageOS is rubbing against your carefully orchestrated setup for controlling the output, signing and OTA stuff... it might warrant an abstraction level so we can get the sideloadable .zip ... but there's still the question of signing those builds I need to look into
<danielrf[m]>
samueldr: Yes, i'm open to some abstraction there if needed.
<samueldr>
I think it all hinges on whether robotnix aims to build all android-like systems, or aims to build the subset of closely AOSP-like systems like GrapheneOS in a secure and verifiable manner
<samueldr>
the latter can still happen if it wants to build all android-like systems, at the cost of abstractions, I guess
<danielrf[m]>
Well, I can only really commit to maintaining what I currently have, but I'm definitely open to abstraction if it makes sense and helps support other sources
<danielrf[m]>
it's already fairly abstract :)
<samueldr>
sure, understandable :)
<samueldr>
yes, I think the most I hit against right now is that it only dealt with AOSP-like so made assumptions
<danielrf[m]>
I mean, that is the hope for using the module system--that it would more easily support these changes
<samueldr>
I don't even think the assumptions are bad, but more that the outputs might need to configure them a bit more, so it's easier to grok
<samueldr>
though there is stilll some stuff I'm not entirely understanding in the (generic) android build
<samueldr>
I'm not sure my build should even work, but using the .zip created from whatever "-A img" output didn't boot...
<samueldr>
the dev cycle does take some time though :)
<danielrf[m]>
Hmm, well it's nice that it even completed the build with "-A img".
<samueldr>
but I just started yesterday evening getting this into robotnix, so I say it's great success
<samueldr>
yes, the .zip is wrong, as it doesn't have the right product name in it, but I'm 99% sure that with LineageOS we don't want those
<samueldr>
it's why I'm waiting on a new "bacon" build (whatever that target does) to have the sideloadable zip output
<samueldr>
(I *added* bacon as an output)
<danielrf[m]>
That seems reasonable
<danielrf[m]>
Just wondering if the build instructions on the lineageos site are all autogenerated
<samueldr>
99% sure they are
<samueldr>
they're not that useful
<samueldr>
they get you 80% there
<danielrf[m]>
Would be nice to see the differences between devices at least
<samueldr>
you have to know how their "roomservice" thingy does some magic to get the device trees at the right place
<samueldr>
I think it'll all make sense to you once I open that PR :)
<danielrf[m]>
haha ok, thanks :)
<danielrf[m]>
I see bacon is lineageos 16. Is that android 9?
<samueldr>
yes
<samueldr>
cyanogenmod was updating +1 every named release for Android
<samueldr>
so 4.1->4.2 they they went +1
<danielrf[m]>
Part of what most concerns me would be ongoing support for older android versions
<samueldr>
and LineageOS continued where cyanogenmod stopped
<samueldr>
undestandably
<danielrf[m]>
I've left some android 9 stuff in robotnix so far, but it's all untested
<samueldr>
I was thinking of only supporting what was supported by them
<danielrf[m]>
(or at least, it was last tested before android 10 was released)
<samueldr>
I still need to figure out a good scheme for getting a device into the tree
<danielrf[m]>
sorry what do you mean by "tree"? are you referring to the actual devicetrees? or the source tree?
<samueldr>
and anyway, I would prefer to make it trivial for the end-user to fetch the info themselves, rather than hardcode a totally untested list in robotnix
ashkitten has quit [Quit: WeeChat 2.8]
<danielrf[m]>
omg, matrix <-> bridge is so slow
<samueldr>
oh, lol
<danielrf[m]>
I was watching your messages get inserted above what I had typed.
<{^_^}>
danielfullmer/robotnix#8 (by samueldr, 11 seconds ago, open): [WIP] DO NOT MERGE — Add LineageOS ROM support
ashkitten has joined #nixos-aarch64
<danielrf[m]>
samueldr: Cool thanks. I'll see if I can get marlin builds working with this as well--maybe later tonight
<samueldr>
I should re-generate using 17.1, not even sure 17.0 ever was a thing that worked
<samueldr>
official builds went from 16.0 to 17.1
zupo has joined #nixos-aarch64
<samueldr>
though I'm glad to hear from our discussion that you're open to make it less of an opinionated thing to build your roms, and a bit more broad
<samueldr>
I'm willing to bet other users will end up interested in that with LineageOS coming
alp has joined #nixos-aarch64
<samueldr>
I still haven't had time to look into how it works, but I'm sure hoping the custom things like f-droid already can work :)
<danielrf[m]>
Well let's hope. I'd bet that has the best chance of working compared to the other modules... I'm more skeptical that e.g. webview would work on older versions of android
<danielrf[m]>
wonder if a generic build of lineageos would work with the emulator module too :)
ehmry has quit [Remote host closed the connection]
ehmry has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]