Yocto Technical Team Minutes, Engineering Sync, for September 29, 2020

Trevor Woerner

Yocto Technical Team Minutes, Engineering Sync, for September 29, 2020

== 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, Saul Wold, Armin Kuster, Richard Purdie,
Bruce Ashfield, Jon Mason, Michael Halstead, David Reyna, Jeremy Puhlman,
Jan-Simon Möller, Ross Burton, Paul Barker, Scott Murray, Tim Orling,
Steve Sakoman, Randy MacLeod, <phone-in>, Alejandro H

== notes ==
- M3-rc2 through QA, release for later this week
- 3.1.3 in QA, release Thur or Fri this week
- more AB issues resolved, but many remain
- --x corruption in pseudo, probably undetected in many cases

== general ==
RP: 2 of 5 bugs fixed against M3-rc1, so we’re ready to move on

RP: the pseudo issue explains strange bugs we’ve seen over the years
Randy: any solutions?
RP: seems worrying, Peter thinks it should abort. with the aborts it only gets
through 2-3 tasks before aborting
PaulB: can we do something when non-pseudo tries to touch these paths?
RP: pseudo assumes it has 100% access to the entire system, but there are
things we change outside pseudo (which are fine), so we need a patch to
tell pseudo to restrict what it can see, but the ignore-list isn’t
complete. e.g. pseudo and qemu don’t get along so we stop pseudo to run
qemu, qemu then touches files that pseudo controls, but we can’t tell
which files were touched

RP: despite all the changes we’ve made, we’re still seeing timeout issues
on the AB

ScottM: could we scan a set of directories
RP: we could do an integrity check, the problem is deciding when to do it.
there are a number of tasks that run in parallel, so the trick is figuring
out when to do the integrity check.
ScottM: how amenable is that to someone helping without deep knowledge of
RP: once it’s down to analysing individual changes, we should be fine
ScottM: do we need a failed build to work on?
RP: no, with the aborts in place the issues crop up quickly
J-SM: could the abort patch be made available conditionally so people can dig
RP: possibly. the build dies very quickly with the patch, so if we can get to
a certain point before failing then others can jump in
PaulB: other distros use fakeroot, is it worth looking elsewhere for ideas?
RP: we use pseudo because fakeroot had massive issues that didn’t map well
to what we’re doing (not sure if these have all been addressed) e.g. if
you open a shell and do the whole build sequentially in that one shell,
then fakeroot will work fine. but with us we use different tasks, in
parallel, etc which fakeroot doesn’t support
RP: these issues tend to only appear because of the heavy heavy load of the
build servers, these most likely won’t affect people doing “normal”
builds on mostly not-overloaded systems. i.e. the inodes are re-used very
quickly on our AB infrastructure

RP: i have some patches in master-next which i’ll push later this week. but
it raises the question about what to do regarding -stable
J-SM: i suggest doing the same, make the patch optionally available
RP: i’ll try to get it working somewhat so others can jump in more easily
Randy: things generally look good
RP: i think this bug’s been here a long time, but was exacerbated by
recipe-specific sysroots, these generate a *tonne* of database entries
RP: the only way people might have noticed this in the past is if someone did
a binary compare
Randy: right, but nobody’s complained about /bin/ls not having --x (for
Jeremy: i’m guessing the issue has been around since 2.4 (Rocko). we have
been seeing issues where random executables would be missing --x
PaulB: we have to make sure to not attribute this issue to too many bugs

PaulB: Randy and i emailed the maintainers of meta-rust to bring rust support
in during the next development cycle. looks good so far
Randy: i have a patch
PaulB: and the patch adds the fetcher into bitbake

TW: OE happy hour tomorrow

TW: there was a discussion re default values, any resolution?
RP: nobody liked any of the suggestions well enough, so it faded

PaulB: inclusive language: add to contribution guidelines? the contributing
guideline only appears in the wiki, should we have something at the
top-level of the repository?
RP: go for it, anything to help new users