<khem>
RP:I have sent v3 of clang toolchain patch, note that its on top of master-next not master, so it does not have patches that you have already staged on master-next
aardo has quit [Ping timeout: 252 seconds]
ardo has joined #yocto
jmd has joined #yocto
_whitelogger has joined #yocto
<RP>
khem: cool, ok thanks
zeemate has joined #yocto
leon-anavi has joined #yocto
mckoan|away is now known as mckoan
jmd has quit [Remote host closed the connection]
Articulus has joined #yocto
alperak has joined #yocto
pbergin has joined #yocto
berton has joined #yocto
wooosaiiii has quit [Remote host closed the connection]
florian has joined #yocto
wooosaiiii has joined #yocto
wooosaiiii has quit [Remote host closed the connection]
wooosaiiii has joined #yocto
goliath has joined #yocto
wooosaiiii has quit [Remote host closed the connection]
wooosaiiii has joined #yocto
wooosaiiii has quit [Remote host closed the connection]
wooosaiiii has joined #yocto
OutOfService has joined #yocto
<OutOfService>
Hi. I'd like to create my own fiormware in order to be used in ameraki mr-18 AP. Do you think yocto is a right project to use with this hardware? I tried to use open-wrt, but it seems that it's not supported, so I thought that maybe poky could help. Any kind of help or advise will be helpfull. Thanks!
leon-anavi has quit [Read error: Connection reset by peer]
<rburton>
OutOfService: if you want to build everything from scratch then sure. if you don't want to have to write all the networking and router logic yourself then i'd port openwrt. the hard bit is figuring out how to get a non-vendor linux on the system and that won't change between openwrt and yocto.
<rburton>
like maybe openwrt isn't supported because that ap has secure boot so you can't just drop random firmware on it...
<rburton>
khem: so i had a poke at clang last night. really thinking we should split up the recipe - build lldb and libcbc at least in separate recipes. it looks like you can build clang against a separate llvm too. this would all help ensure that we build just the pieces needed and streamline the build
<rburton>
khem: data point: not building lldb and clc dropped over 100M and 2 minutes from clang-native on my altra
<OutOfService>
thanks a lot rburton. My point was just to try to usea something loke open-wrt. I wouldn't be able to build everuthong froms scratch by myself
Perflosopher0387 has quit [Quit: Ping timeout (120 seconds)]
<OutOfService>
I was thinking on trying to flash my own chip so as to allow my firmware to be flashed
Perflosopher0387 has joined #yocto
savolla has joined #yocto
florian_kc has joined #yocto
savolla has quit [Client Quit]
JerryM has joined #yocto
savolla has joined #yocto
<JerryM>
hey folks, anyone got some experience or pointers to share about using a host serving sstate using nfs and bitbake-hashserv and using multiple builders to populate it?
leon-anavi has joined #yocto
<paulg>
JerryM, yeah you'd not be wrong in saying our docs lack for that obvious use case.
<paulg>
But I've done it locally with downloads and sstate via NFS to a bunch of e-waste bots, and if you get it right, it will haul ass.
<paulg>
I had this poor old neglected Dell Optiplex 990. Couldn't even find the case lid for it. Slammed a couple old spinning rust disks in it as RAID0 and with avahi, it became my download/sstate server.
dgriego_ has joined #yocto
<paulg>
So here is what I added to the slave bots at the end of conf/local.conf
<paulg>
#BB_SIGNATURE_HANDLER = "OEBasicHash"
<paulg>
BB_SIGNATURE_HANDLER = "OEEquivHash"
<paulg>
BB_HASHSERVE = "o990.local:8687"
<paulg>
On the crappy old dell 990, I'd run the sstate server as follows:
<paulg>
...and then I'd symlink those NFS mounts into a new build for downloads and sstate.
<paulg>
There are variables for all this kind of stuff, but I can never remember, so I go right at it at a core/fs level.
<paulg>
I'm sure RP is horrified at my crimes about now, but he has respect for people who just get it done.
ablu has quit [Ping timeout: 248 seconds]
ablu has joined #yocto
jclsn has joined #yocto
<JerryM>
paulg, thx that sounds similar to what I expected
<JerryM>
but ye you are right documentation is minimal so I was wondering about reasons not to or things to take into account
<JerryM>
but at least it sounds like you had success with it so I'll give it a try too
<JerryM>
there is still the case of sstate management and hashserv I do believe it was possible to remove and clean items in both but I wasn't able to find any docs on that either, problems for later I suppose
<paulg>
JerryM, yeah - I just threw big arse disks at it and figured I'd revisit cache expiry another day (never happened).
goliath has quit [Quit: SIGSEGV]
wooosaiiii has quit [Remote host closed the connection]
wooosaiiii has joined #yocto
wooosaiiii has quit [Remote host closed the connection]
wooosaiiii has joined #yocto
wooosaiiii has quit [Remote host closed the connection]
wooosaiiii has joined #yocto
wooosaiiii has quit [Remote host closed the connection]
wooosaiiii has joined #yocto
wooosaiiii has quit [Remote host closed the connection]
wooosaiiii has joined #yocto
OutOfService has quit [Remote host closed the connection]
paulg has quit [Ping timeout: 260 seconds]
wooosaiiii has quit [Remote host closed the connection]
wooosaiiii has joined #yocto
Tyaku has quit [Ping timeout: 244 seconds]
Tyaku has joined #yocto
cyxae has joined #yocto
MarcWeDLM has joined #yocto
paulg has joined #yocto
* tgamblin
is testing numpy ptests on qemuriscv64, and it seems that he has run into the architecture's NaN handling quirks...
jmd has joined #yocto
<paulg>
tgamblin, do you actually have a genuine riscv64 board, or are they still unobtanium?
<tgamblin>
paulg: I have a VisionFive 2, which seems to be comparable to an rpi3 in performance
<tgamblin>
But right now I'm just trying to figure out which of my (maintainer) recipes are breaking on it
<paulg>
cool. I wish them the best. Someone needs to get in there and shake things up.
MarcWeDLM has quit [Quit: Client closed]
druppy has joined #yocto
druppy has quit [Ping timeout: 244 seconds]
JerryM has quit [Quit: Konversation terminated!]
<khem>
rburton: we can disable lldb in defaut PACKAGECONFIG
<rburton>
khem: i much prefer having separate recipes so its not a packageconfig thing to get the debugger
<rburton>
rebuilding _everything_ because you decided you wanted a debugger is a bad idea
<khem>
rburton: separate recipe will ask for more maintainance, while possible not many people do builds like that
<rburton>
this thread started because of libclc, which is also non-trivial and has to be enabled just in case the system is building mesa with opencl
<rburton>
how about lets not build libclc if its not needed
<khem>
yeah I think thats perhaps good to see that it becomes inert if opencl is not in build path
<khem>
paulg:i have more riscv64 boards lying around these days than other archirectures :)
<khem>
and I am not counting ESPs
druppy has joined #yocto
<khem>
rburton: add your observations to the bugzilla we have created for clang build improvements
<khem>
I will forget :)
<paulg>
khem, I'm just an old retired guy, so time basically stopped when I pulled the plug. The r-pi4 was what the cool kids were playing with back then.