From: "Trevor Woerner" <twoerner@gmail.com>
To: yocto@yoctoproject.org
Subject: minutes for Yocto Project Technical Team Meeting / Engineering Sync - June 2 2020
Date: Tue, 9 Jun 2020 17:08:21 -0400 [thread overview]
Message-ID: <20200609210821.GA33481@linux-uys3> (raw)
Yocto Technical Team Minutes, Engineering Sync, for June 2 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, Stephen Jolly, Joshua Watt, Mark Morton, Richard Purdie, Steve
Sakoman, Randy MacLeod, Trevor Gamblin, Bruce Ashfield, Jan-Simon Möller,
Jeremy Puhlmann, Jon Mason, Mark Van de Vyver, Michael Halstead, Paul Barker,
Ross Burton, Scott Murray, Tim Orling, Armin Kuster, Peter Kjellerstedt, David
Reyna, Denys Dmytriyenko
== notes ==
- YP 3.0.3 has been released
- YP 2.7.4 is awaiting final approval and likely to be released today
- YP 3.1.1 later this week or early next
- AB up on Fedora 32 and Ubuntu 20.04
== general ==
Randy: how do we feel about the build quality
RP: better, but it looks like there’s new races (e.g. icu-data) especially
when multiple builds are run in parallel, not “panic” yet, but
“concerned”
TrevorG: haven’t had success with logrotate yet
RP: on a good day there’s a 50% chance of a build failing
Randy: that’s not good, we see ~1% internally at WR
RP: Steve: we need to look at the ltp-release issue
Steve: okay
RP: upstream recommends removing some of the tests and using at least 1GB of
RAM
RP: Joshua sent invasive bitbake patches, something we probably should have
done a while back, but taking them makes LTS diverge significantly from
master, should we put it in LTS?
JPEW: maybe put it in master for a while, but ideally it would be in LTS
eventually
RP: python module issue for dunfell (LTS): upgrading to LTS
requires meta-openembedded because of meta-arm see:
https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg136914.html
(various): conflicted on whether this is good or not
Steve: including meta-oe is pretty much standard, hard to believe a production
system can build without it
RP+Timo: we see people who would rather cherry pick from meta-oe (and forking)
than importing meta-oe entirely
Paul: how does this cause breakage?
RP: versions and layer priorities
JPEW: happens when people already have meta-python and upgrade one but not
another
Scott: doesn’t the build fail?
JPEW: yes, it could, or they get the wrong versions
RP: if they upgrade oe-core but not meta-oe then it fails
JPEW: if we move them, do we also upgrade them?
RP: given the security issues, we should. i suggest punting to TSC
Timo: do we do the upgrade also on meta-oe dunfell branch?
RP: yes, but it needs to be clear that this is an exceptional circumstance,
this isn’t something we’ll do regularly
Steve: do we do it now, or 3.1.1?
RP: 3.1.1.
Ross: lots of overlap between OE and Yocto TSC, but I think this is mostly an
OE TSC issue
Timo: if this had happened a few months ago, this wouldn’t be an issue, so i
think it should go in
RP: agreed. JPEW and Bruce: thoughts?
JPEW + Bruce: sounds good
Paul: to clarify if oe-core is updated but meta-oe isn’t the wrong recipe is
used
RP: an older version of a recipe is used, so it succeeds but has the wrong
version
Paul: maybe we should add sanity checks
RP: don’t think we should
Scott: will dunfell be updated
Steve: have to dig into the issue to understand it
Timo: crops broken, worked on getting it working over the weekend, now works
from morty to zeus, but fails on dunfell and master, not sure why
RP: can we run the tests on AB?
Timo: probably just a “pip install”
RP: we do something similar with mingw
Timo: perl dependency, look at all the split packages, run all the files
through perl-req, in order to generate
RP: thanks for update
Scott: noticed <secret> is a platinum member
RP: yes, not quite ready to blog about it, the website updated, but still
finishing the deal, an official announcement is coming. we don’t know
who from their side will be interacting with the community, we’ll have
to see
Scott: is devday sign-up going to be posted?
David: just signed things recently, team has been distracted
Scott: how is it going to work this year?
David: zoom meeting, 500 participants, 3 hands-on, hoping for helpers (as
usual), separate rooms
RP: lots of changes behind the scenes, advocacy Tracy again, Andrew Wafaa on
board
RP: Mark how are things going with docs?
Mark: out last week. Nico has a wiki page setup for the conversion, working on
testing manual
RP: looking forward to first draft of testing manual! (then others can pitch
in)
reply other threads:[~2020-06-09 21:08 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200609210821.GA33481@linux-uys3 \
--to=twoerner@gmail.com \
--cc=yocto@yoctoproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.