Yocto Technical Team Minutes, Engineering Sync, for September 15, 2020
Trevor Woerner
Yocto Technical Team Minutes, Engineering Sync, for September 15, 2020
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit == disclaimer == Best efforts are made to ensure the below is accurate and valid. However, errors sometimes happen. If any errors or omissions are found, please feel free to reply to this email with any corrections. == attendees == Trevor Woerner, David Reyna, Saul Wold, Richard Purdie, Tim Orling, Randy MacLeod, Joshua Watt, Jan-Simon Möller, Michael Halstead, Paul Barker, Mark Morton, Steve Sakoman, Bruce Ashfield, Trevor Gamblin, Mark Asselstine, Stacy Gaikovaia == notes == - closed m3, hasn’t built yet (in freeze) waiting for docs - good progress on the docs, past point-of-no-return - there appear to be 3 AB issues: - qemu-mips issue - limited to 256MB of memory, systemd needs more - Armin tried raising it, but caused other issues (will revert) - weird networking dropout issue when qemu testing - was it caused by something in the image? - or caused by qemu, kernel, etc? - need to detect this issue and report on if anything else is dead - seen on x86, arm and mips - intermittent - occasional bitbake timeout - bitbake says it can’t connect to the server - due to sync thread in bitbake, 90 second+ disk stalls (apparently) while writing logs, there’s a 60[s] timeout limit - devtool doesn’t do re-nice’ing, might be related - parsing issue seems to be solved (thanks for help from jpew) == general == Randy: bitbake timeout is to add nice to devtool or to not block? RP: thread is there to allow cache to be written out while allowing bitbake to do other things, we could just increase timeout on UI, or have bitbake write the cache directly JPEW: it’s during client shutdown? RP: yes, when a given client is done using bitbake, the sync should already be happening at that time, we need to make sure the sync is done, if not it will wait on sync completion RP: it’s a high bug for m3, but will probably push to m4, won’t hold up m3 RP: lots of unassigned bugs in 3.2 if anyone has time Randy: you listed off a bunch of AB issues, have we seen any improvements RP: yes, there have been cleanups in various areas that help expose these issues Randy: is it an issue of overloading? RP: i think this is a consequence of heavy automated testing. sure we could half the number of workers or increase timeouts. or maybe we have bitbake act differently on the AB than the way it would normally. we could implement some pinging infrastructure so the UI can know that bitbake hasn’t died Timo: is this an NFS issue, or just a general I/O issue RP: don’t have enough data to say, but feels like an I/O issue Timo: how will devtool do io-nice? RP: tinfoil execution RP: appears to happen when bitbake is extracting kernel source, devtool is probably using external source, so we’ll probably need to wrap the extraction of the source code with io-nice JPEW: i’m still working on multiprocessing things (still multiprocessing, but not using the python multiprocessing module), maybe not for m4, but do we still want to keep looking at? RP: i’d like to look at the code before deciding JPEW: i’ll clean it up some more Randy: rust, people looking to get it into 3.3, i need to push the patches somewhere, would be happy to have help. RP: i think AlexK is interested. keep him in the loop (he has a great track record with gnarly problems) PaulB: doing research for my talk next week at Linaro Connect for license compliance. wrt rust, whether it can use build offline etc. will be looking at dunfell and master and try to find answers in the next week or so Randy: sounds good, there’s currently no major differences between what i’m working on and what’s in meta-rust PaulB: we need to be able to generate source tarballs, handle being behind corporate firewalls, offline builds. i want to investigate this wrt rust, golang, and nodejs RP: it’d be great if this were done as a set of automated tests that could be added to the project PaulB: don’t know that all the test code is available, some of the builds would be big, but can look into it PaulB: also want to mention outreachy that Paul has worked on and mention it in my talk RP: wrt people interested in rust. maybe try Yann or Leon David: call for papers for YP Summit is open Randy: 6 days until deadline? David: yes Randy: next Monday Timo: Christopher Clarke and I will be doing virtualization (rehashed and expanded) Randy: i’d like to introduce Stacy, working at WR as a co-op for this term RP: and there’s already a patch in Stacy: and hopefully another and another! (various): welcome! ☺
|
|