Yocto Technical Team Minutes, Engineering Sync, for September 22, 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, Armin Kuster, Stephen Jolly, Martin Jansa (JaMa), Richard
Purdie, Joshua Watt (JPEW), Steve Sakoman (SS), Mark Morton, Michael
Halstead, David Reyna, Saul Wold, Paul Barker, Scott Murray, Jon Mason,
Randy MacLeod, Bruce Ashfield, Alejandro H, Tim Orling (Timo)

== notes ==
- m3-rc1 build and ran, qa found issues (beaglebone fails to boot) therefore
an -rc2 will be built
- 3.1.3 will be built soon
- sphinx transition has merged (docs.yoctoproject.org)
- one of the AB timeout issues identified and patch sent
- other AB issues to work on

== general ==
RP: beaglebone issues, ptest issues, please take a look

RP: believe we found why there are stalls on I/O (journal writing), tweaks
made, hope they help (thanks Michael)
RP: but there are still other AB issues (e.g. --x bit not set, caused by sudo
re-used inodes)
RP: this is blocking next build, not sure if they’re caused by master-next


RP: sphinx updates merged, it’s just the start, there are lots of URL issues
and lots of out-dated content that could use an update
Randy: is this documented somewhere (the workflow)?
RP: the README has been updated
RP: ignore the xml files, make changes to the rst files

RP: (to Michael) how close are we to getting auto-updates to the website
Michael: very close, just need an update to the new process
RP: would be great to not need manual intervention to update the docs
Michael: who would need to know of any failures other than me?
RP: the docs email list

PaulB: follow-up on last week’s rust discussion
PaulB: the license stuff looks good, what’s in meta-rust looks good, it
provides a fetcher (i.e. crates) that feeds that to bitbake. lots of stuff
that works (e.g. BB_NO_NETWORK).
PaulB: one limitation is that licenses of fetched dependencies are not fetched
PaulB: the crate-fetcher should be moved into bitbake itself, it just uses https as expected, so shouldn’t be too hard
RP: sounds good!
PaulB: after seeing npm nightmares, rust looks good!
PaulB: we need a story for handling licenses of dependencies
Randy: can we not just list all the licences for each one?
PaulB: the cargo-bitbake tool should be able to simply recurse through the
dependencies
PaulB: the cargo-bitbake tool is written in rust (as opposed to python3)

RP: on the licensing email list there was a question about licensing. there
are packages with sprawling dependencies and although the top-level
license is listed the licenses of the dependencies are not
PaulB: there is a tool (scancode-tk class in meta-spdxscanner) that can go
through a repository to look for license text (and itemize them). it’s a
very time-consuming process; core-image-minimal adds 23 hours to a 1 hour
build
RP: when we scan for debug symbols it tells us what’s included in the binary
PaulB: scancode-tk uses the fetching and patching to examine, examining only
the debug symbols would cut down the time
RP: in any case the question on the licensing mailing list needs a reply. do
we add to do_license?
PaulB: i don’t think it can ever be “complete”
RP: true, but maybe there are holes that can be easily filled
Armin: would ptest-check come into play too?
RP: those can be under a different license
Armin: what i mean is, sometimes enabling ptests causes other things to be
downloaded and used, would those be included? would those be considered
part of the package license compliance list
RP: since it’s downloaded but not shipped, i don’t think so, i think it
should be a runtime issue
(various): qt5, chromium, wayland, etc
RP: sounds like there’s work here to do and things to investigate

RP: are we going to get the rust fetcher into bitbake?
Randy: working on other stuff at the moment, but was going to get “hello
world” working, then focus on packaging, then later a “hello
crazy-world” (i.e. a larger rust program)
RP: makes sense to break it up into logical chunks. sounds like working on the
fetcher and having fetcher tests would be nice
Randy: PaulB does that sound good?
RP: I need to poke the meta-rust maintainers and see what they think/involve
them
Randy: they didn’t seem super interested in participating when i poked them
a while back
PaulB: but yes, working on the fetcher sounds like a good area to work on.
it’s fairly self-contained. needs test cases. should be able to pull it
in without the rest of meta-rust
Randy: does it make sense to do the toolchain alone then librsvg
PaulB: where is librsvg? (librsvg needs rust to build now)
Randy: oe-core
Armin: in meta-security there is a newer package that i haven’t brought in
because it needs rust, so it could be a good test case
PaulB: rust has really fast releases, how do we want to handle that amongst
the various branches?
PaulB: with python it makes sense to write a recipe for each and every
library/dependency that is used, but rust works differently, it doesn’t
work in the way of needing to build dependencies then building the main
app itself. in rust we just need a recipe for the app, and the rest gets
handled
Randy: (divides work up between himself and PaulB, going forward)

Stephen: there will be a new invite to this meeting and the bug triage meeting
on the mailing list, the new links will have an embedded password

RP: anything on stable front that we need to talk about
SS: not really. when we do the latest pull we’ll need to start a new build
RP: centos 7 perf?

RP: Bruce: x86 backtrace?
Bruce: had a quick look, no ideas yet, will look at it later today
RP: it’s a weird one and it worries me: a corrupt return pointer? maybe a
tool issue
Bruce: we can’t blame system load on this one
RP: it looks like corruption