ChanServ changed the topic of #robotnix to: Robotnix: || Channel logs:
<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> hm
<samueldr> yeah, that's one thing I wasn't entirely sure
<samueldr> oh
<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> oh
<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]> yeah
<danielrf[m]> copyfile is only really used by go tools in android
<samueldr> yeah
<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'm seeing this as well:
<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