<
danielrf[m]>
henri: I had to try that out for myself too
<
danielrf[m]>
note: currently hard linking saves 2718804.31 MiB
<
danielrf[m]>
I'm assuming it's since so many of the android checkouts have identical files....
<
danielrf[m]>
e.g. clang/llvm prebuilts are pretty big and usually identical between tagged releases
ajs124 has quit [*.net *.split]
matthewcroughan has quit [*.net *.split]
lassulus has joined #robotnix
Miyu-saki has joined #robotnix
V has joined #robotnix
jack[m] has joined #robotnix
Ox4A6F has joined #robotnix
ajs124 has joined #robotnix
hexa- has joined #robotnix
hexa- has quit [Max SendQ exceeded]
danielrf[m] has joined #robotnix
Ox4A6F has quit [Ping timeout: 248 seconds]
jack[m] has quit [Ping timeout: 258 seconds]
danielrf[m] has quit [Ping timeout: 247 seconds]
mcint has joined #robotnix
hexa- has joined #robotnix
<
samueldr>
currently looking at adding TWRP to robotnix, mainly because it's impossible to just run the android build system in any remotely good ways
<
samueldr>
and ugh, forgot how annoying it is to deal with syncing repo
danielrf[m] has joined #robotnix
colemickens has joined #robotnix
Ox4A6F has joined #robotnix
jack[m] has joined #robotnix
<
samueldr>
interesting, the dev cycle for a build might not be that long
* samueldr
waits anxiously
<
samueldr>
and it failed as I wrote that
<
samueldr>
FAILED: /build/out/target/product/surfna/obj/STATIC_LIBRARIES/libguitwrp_intermediates/twrp
<
samueldr>
/bin/bash -c "([...])"
<
samueldr>
where the elided parts are those commands chained with ) && (
<
samueldr>
if it rings a bell
<
samueldr>
(I need to do other things if I want to eat tonight)
<
samueldr>
I assume it must be because of /bin/bash... but that's odd
matthewcroughan has joined #robotnix
<
danielrf[m]>
I would expect that /bin/bash should be fine in the FHS environment robotnix builds under
<
samueldr>
yeah, that's one thing I wasn't entirely sure
<
danielrf[m]>
Just checked, and yep /bin/bash should be fine
<
samueldr>
I was careless in reading the errors
<
samueldr>
I hadn't realized the following messages were relevant to the error
<
samueldr>
because there was interleaving from parallelism
<
samueldr>
ah, fonts coming from multiple `srcs` and not being writable
<
samueldr>
sounds plausible?
<
danielrf[m]>
yeah seems plausible
<
danielrf[m]>
if the origin of those files is from a dir under /nix/store then it won't have +w permission by default
<
samueldr>
that's what I was assuming
<
danielrf[m]>
Easiest way is usually to just patch in a chmod in the script
<
danielrf[m]>
*makefile
<
samueldr>
might not really be
<
samueldr>
since it's a single `cp` invocation that fails
<
samueldr>
hard to do it in-between
<
samueldr>
that would do it
<
danielrf[m]>
Is it the first or second one?
<
samueldr>
it's all in the first cp
<
samueldr>
multiple different sources being combined
<
samueldr>
(I assume)
<
danielrf[m]>
I'd suspect that cp would be smart enough to not remove write permission from a dir it later needs to write to halfway through copying
<
samueldr>
(turns out I didn't start some prep where I need to wait so I have a few minutes still)
<
danielrf[m]>
which is why I'd suspect the second copy would ultimately cause the problem
<
samueldr>
plausible
<
danielrf[m]>
but I might be wrong about cp's behaviour
<
samueldr>
anyway your fix is probably more right^W pragmatic
<
samueldr>
since it wouldn't surprise me that we'd see other similar issues
<
samueldr>
hm... but that's not using copyfile I guess
<
danielrf[m]>
well the fix I posted above has two: an added chmod, and a patch to setPermissions in libhost
<
danielrf[m]>
copyfile is only really used by go tools in android
<
samueldr>
I read it more carefully after adding it
<
samueldr>
past that error now
<
danielrf[m]>
nice!
<
samueldr>
and already 50% in of that build
<
samueldr>
(it's using a prebuilt kernel, since that's the assumption of the device tree generator)
<
danielrf[m]>
let me know how many other fixes like this you need for TWRP, i'm definitely curious
<
samueldr>
I am too :)
<
samueldr>
it might be very few
<
danielrf[m]>
fingers crossed
<
samueldr>
because TWRP skips a LOT of android
<
samueldr>
though I don't know if it would be possible to produce a list of devices like lineageOS uses
<
samueldr>
haven't checked yet
<
samueldr>
might also be hard because of the android target branches, unsure still
<
samueldr>
but right now the main thing is: this builds an android tree... while I can't otherwise
<
danielrf[m]>
Is your build based on the lineageos flavor? Or are you using a different manifest / repo json file?
<
danielrf[m]>
I don't know much about building TWRP currently
<
samueldr>
I used that exact manifest
<
samueldr>
but I'm building for a fresh device tree
<
danielrf[m]>
ah very cool
<
samueldr>
blah, blasted github and its inability to search in a fork
<
samueldr>
have to find from which repo a certain failure comes from
<
samueldr>
takes about 5 minutes to get to 99%
<
danielrf[m]>
Not bad!
<
samueldr>
still have similar `cp` issues, but obvious how to fix
<
samueldr>
just need to track them all down