Yocto Technical Team Minutes/Engineering Sync for Mar 2, 2021

Trevor Woerner

Yocto Technical Team Minutes, Engineering Sync, for Mar 2, 2021
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, Stephen Jolly, Joshua Watt, Peter Kjellerstedt (saur),
Armin Kuster, Scott Murray, Richard Purdie, Michael Halstead, Steve
Sakoman, Paul Eggleton, Jan-Simon Möller, Saul Wold, Steve Sakoman,
Alejandro H, Bruce Ashfied, Tim Orling, Randy MacLeod, Jon Mason, Ross
Burton, Alexandre Belloni

== notes ==
- 3.2.2 and 3.1.6 released last week
- 3.3-m3 due to be built soon
- now in 3.3 feature freeze
- reproducibility improved, exclusion list significantly reduced
- various infrastructure issues (e.g. diffoscope)
- lots of old, stale patches

== general ==
RP: reproducibility: down to about 5 recipes (outside of Go) perf and ovmf
are holdouts (ovmf has a hard-coded path in it), ruby and meson have
intermittent issues (depending on build host). ruby is in ruby-docs. there
are bugzilla entries for these. about 20 of the remaining issues in the
exclusion list are related to Go. there are some sync issues
Ross: meaning?
RP: there are explicit “sync” calls in the test framework, but there are
too many, and this adds enormous I/O load which can affect issues when the
test itself does I/O work
JPEW: running diffoscope on all the output was really slow, if we can
pre-check the directories and prune them out before, it can speed it up
Ross: i tried diffoscope a while back and gave up after 5 hours
JPEW: what version?
Ross: really old
JPEW: lots of improvements, lots and lots, so just pip install the latest and
it should help
RP: found performance issues and upstream happily accepted them
JPEW: if there are 1000’s of files that are different it will just give up
after a while
RP: i was able to get diffocope to give some good results before it gave up
and that was helpful. sometimes it is able to complete, but then the
resulting HTML is huge. it takes a _long_ time for my browser to load :-/
RP: the good news is the AB is producing output in a timely manner

RP: we’re in feature freeze for 3.3, lots of stuff in master-next that i
don’t know what to do with
RP: rust isn’t in yet
Randy: still working on the bugs (a dnf issue)
Scott: if it doesn’t get in, does it block us on python3-cryptography?
Randy: yes
RP: i don’t feel like it’s ready yet. things have been rushed in in the
past with not-so-great results, i think we’ll step back on this one and
wait for it to be more stable, more tested. it should definitely get in
for the next cycle but i’m leaning towards not doing it for this release
(various): agreement on waiting
Randy: there’s an issue with the SDK related to dynamic linking, and
automating the rust compiler test cases

RP: are there any other things that need to go into 3.3? ross: debugd?
Ross: i think the debugd stuff is in master-next
RP: i think there’s some stuff related to docs that needs to be done but we
can hold off on that and fix it up later
Scott: i think PaulB has some stuff he’s trying to get in (read-only hash
equiv, read-only pr)
RP: i think i’ll wait for -m4 for that one. he started with really bad code,
so i expect it’ll take a lot of work/testing before it’s ready
RP: i’m working on making do-install become an sstate task, but getting
weird issues
RP: i did some testing on libuuid, but it blew up
PaulE: okay, i’ll poke Luka today to see what’s the status
RP: i think there’s a lurking sstate management issue, but haven’t proved
or disproved yet
PaulE: we’re not absolutely desperate for it, we can wait a release, don’t
want to cause pain
RP: sstate manifests not behaving, it’s supposed to get cleaned out, but
if there’s an overlap it seems to complain. at that point things get
cleaned up and the next build will succeed (which is probably worse)

PeterK: recipe parsing times seems to have increased significantly compared to
gatesgarth and dunfell
Randy: numbers?
PeterK: with all our layers included in the build:
45s dunfell
48s gatesgarth
1:38 master
RP: (looks at the AB at some metrics graphs (performance worker) to see if
he can see the issue) hmm.. there is definitely a noticeable jump in the
stats. hopefully easy to bisect (gives commit numbers between which the
issue jumped).
Randy: how do we translate between the data on the X-axis?
RP: that’s commits in the poky repository

Randy: any plans for the next release?
RP: just want to get through this one first
RP: i think focusing on the I/O sync issue would be great. like to see that
one sorted out

Bruce: just want to make sure that anyone doing Go stuff outside of the tree,
make sure to do world builds because some fundamental things changed that
you’ll need to fix. i think a lot of them are fetching things in the
RP: Go is quite nasty in the sense that it wants to be built in a specific
path and once that path is chosen that’s the place it has to be built
PeterK: i think there’s a way to set the build-id to 0 which is causing the
RP: side-effects?
PeterK: we’ll have to see. bug number?
RP: 14270

Join yocto@lists.yoctoproject.org to automatically receive all group messages.