Yocto Technical Team Minutes, Engineering Sync, for December 7, 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 Jolley, Jasper Orschulko, Trevor Gamblin,
Steve Sakoman, Philip Balister, Richard Purdie, Randy MacLeod, Peter
Kjellerstedt, Jan-Simon Möller, Scott Murray, Alexandre Belloni, Tim
Orling, Jon Mason, Bruce Ashfield, Ross Burton, Joshua Watt, Michael
Opdenacker
== project status ==
- 3.5-m1 (kirkstone) to be built this week
- 3.4.1 (honister) out of QA and to be released
- changes to check-layer script leads to improvements to layer README files
- thanks to all for YPS last week
- continue to remove local patches by sending upstream
- rising intermittent issues with AB
- SWAT faltering, large backlog of un-triaged issues
== discussion ==
RP: Ross created graphs related to the changing number of patches and their
state (from 2015 to now) http://www.burtonini.com/yoctometrics/ The patch
status is clearly improving over time both in number and that they are
generally moving upstream. 5 years ago we peaked at 1900 patches, today
we’re at 1270-ish. It’s nice to note how much progress we can make
when we put our resources towards it. Sometimes looking at a patch shows
us that it is no longer required. Upstream is usually receptive, sometimes
it’s just a matter of poking again.
JPEW: i was working on meta-phosh and noticed that libsoup is all messed
up now. there are 2 versions (v2 and v3) and you’re not supposed to
mix-and-match. libsoup2 and 3 were both updated so that if they noticed
the other one, they both hard fail (they call abort() on the process to
kill it). previously things wouldn’t function correctly, now things
won’t run at all. biggest offender is webkitgtk was upgraded to use
libsoup3 but nothing else has been upgraded so anything links in webkitgtk
crashes on startup. there are a surprising number of things in gnome that
crash e.g. settings panel.
Ross: probably easiest to add a packageconfig on webkit so distro maintainers
get to pick
JPEW: it looks like most things will probably switch to libsoup3 when they
update to gtk4 (and won’t switch before then), but for now pretty much
everything in meta-gnome is completely broken. currently libsoup3 is not
used by anything other than webkitgtk
Ross: probably should make libsoup2 the default for now to regress the
breakage
RP: sounds reasonable to me
JPEW: at OEDVM we were talking about open-source projects getting Yocto
compliance. i was working on meta-phosh but not sure what to do next.
maybe next thing is to talk to the board?
RP: not the board, talk to Nico. Nico is the gatekeeper for the compatibility
process, and it goes to the TSC if required after. there are forms on the
website, but the website is iffy, so if you fill in the forms and nothing
happens, then reach out to Nico directly. it’s probably best to just
reach out to Nico directly.
RP: something that may be landing in the next few days, Ross is recommending
that we remove libtool prefix. libtool is prefixed with an architecture
prefix. this is something that OE and buildroot did early on and we’ve
been carrying this for decades. there was a time when it looked like
autoconf was going to mandate that build tools had the cross-compiler
triplet prepended, but autotools looks dead now-a-days. ironically libtool
rejected the patches
Ross: everything it was trying to solve is now solved with recipe-specific
sysroots, and host tools, etc. so everything should just work. any recipe
that has to hand-code libtool work-arounds can all be removed now. i
expect the fallout to be substantial, but the fixes will be to just remove
stuff from recipes. does buildroot still do this?
RP: not sure
Ross: i don’t see any patches for libtool at all (in buildroot)
RP: the cross-compile support in upstream libtool is broken; well, not broken
but inefficient. but, as Ross says, it is obsolete now.
Ross: lots of diffstat lines removed, but it will make the AB explode
AlexB: buildroot has patches for libtool, even multiple versions (see
support/libtool, not package/libtool)
Ross: ah, i was looking in the wrong place
RP: is supporting multiple versions of libtool not a path to madness?
supporting one version is bad enough…
Ross: it looks like it’s doing the same as our patches (i.e. fixing the
relink thing)
RP: yes, buildroot is patching for the the relink thing (which is something we
do as well) but the prefix patch isn’t in buildroot
Ross: i’ll clean this up and post it as an RFC at least
RP: sounds good
Ross: going back to the chart thing, there was talk a while ago about the LF
having a centralized git monitoring/metrics thing?
RP: LFX
Ross: ah yes! is it still going? can we add our stuff into it? it would be
nice to inject out patch data stuff there
RP: they are still doing it, and there are developers actively working on it,
but the people working on it have more pressing things to work on. so the
answer is yes, but not now. there are lots of stuff i’d like to do this
with, e.g. CVE metrics is another. it would be nice to find someone who
would be interested in generating dashboard data for the project from what
we’re producing. we have the ability to inject this stuff, we just need
to generate it
TimO: we need a data scientist
Jon: i sent out an email about inclusive language, please read and respond
RP: where?
Jon: main yocto, oe-devel, oe-core. trying to get the ball rolling to see if
it can land this release
MO: i’m interested, it ties in with documentation
RP: me too
RP: Quentin sent a patch to rename… core-image-master (?) to golden instead.
this is part of the QA test framework and was from a time when we had
ideas about test controllers etc. i checked with the QA team and they
aren’t using it. i did a double-take on that name, it’s not something
i’ve used recently and there haven’t been any patches for it in ages.
i had completely forgotten about its existence, despite being listed as
the maintainer! is anyone using this code?
JPEW: core-image-test-master
ScottM: i had never heard of it before
Ross: i almost ripped it out a few weeks back when i was doing a cleanup
of the QA code. there is someone who is either using that code, or a
derivative of it. i’ll copy them in on that thread so they can have an
opinion. but if it’s not being used then it can probably be deleted.
RP: rather than rename, i’m very tempted to just delete it. it’s not used
and likely broken. even if someone is using it, there are probably better
things they should be doing
RP: there’s another breaking change to one of the tunes that we should
probably fix before M1…
Jon: A72?
RP: yes, thanks. the crypto extension is enabled by default in the tune, but
there’s now an rpi4 that has an SoC that doesn’t enable it. there
are 2 ways to fix this: 1) leave the current tune as-is and create a
-nocrypto variant 2) change the current tune to remove the crypto, then
add a -crypto variant. not sure what path to take; i’m leaning towards
the latter since that fits in better with the rest of the framework even
if it is more disruptive. tune stuff is already complicated, i’d rather
we keep the framework consistent. i also would prefer a better commit
comment
Jon: should i respin their patch with the updated wording? or comment on it to
have them updated it?
RP: either way; preferred to have it before -m1
Jon: just to be clear, this won’t break anything, it’ll just make it
slightly less performant
RP: right, and i think that’s reasonable
ScottM: only meta-raspberrypi is affected by this?
Jon: meta-raspberrypi is broken by this
ScottM: oh right, after this change everyone else will have this off
Jon: right. meta-raspberrypi, meta-rockchip, and possibly a freescale layer
will be affected
JPEW: so just manually re-enable it?
Jon+RP: exactly
Jon: yes, change to cortex-a72 + crypto
RP: anyone using SH4? or anyone know of someone using it?
Randy: nobody we know of (WindRiver)
ScottM: nobody that I know of (AGL)
MO: it’s an SoC for settop boxes (?)
ScottM: maybe Khem would know
RP: Khem is the one who patched it in the past, but not sure if he’s doing
it because he’s using it (or knows someone using it) or if he’s just
doing it because he’s aware of the patches
RP: I came across this as part of the patch clean up exercise; there are some
SH4 patches we’re carrying for glibc. we need to decide if we’re going
to support this going forward. i’m under the impression that if someone
wanted to get SH4 working, they would need more than these glibc patches.
it would probably be better as an external architecture port/layer rather
than odd, random hacks in oe-core
ScottM: if Khem signs off on it then it sounds reasonable to me
RP: i’ll talk to Khem
Peter: i’ve noticed a problem with debug packages with honister. in june
there was a change to remove the attempt-only for complimentary packages,
so they are no longer called with skip-broken complimentary packages. this
hid issues in our packaging. in our case we use gstreamer plugins (bad
maybe) for srtp. the thing is we also have our own plugin for srtp. so
we build the gstreamer plugin for srtp both as part of the gstreamer-bad
package and from our own package. this works fine for the product images
(since each plugin is put in its own package) but the debug symbols are
all put in one package. meaning there is a clash for installing the debug
symbols for both gstreamer and our package. is there any support for
splitting the debug packages (similiar to how the main package is split),
or are debug packages expected to all be all in one package?
JPEW: are you asking if you can split? currently there is one debug package
per recipe
Peter: exactly. but because we are mixing plugins between 2 packages, the
debug symbols clash. i would like the debug packages split just like the
plugin packages are split. and i don’t know how the complimentary stuff
works; and how it knows, for each plugin, that it should pick up the
common debug package rather than the debug package that has the same name
as the plugin package
RP: it’s a good question. i’ve wondered about this in the past. yours
isn’t the only scenario where you can hit this problem. the downside
is the extra impact on the build. generating all these extra packages,
and putting these extra packages into the package feed, etc.. will have
an impact on the overall build and i’m not sure it will make anything
more usable. it would fix some things, but cause other things. i also
wouldn’t underestimate the amount of work involved to get this to work.
RP: the easier fix is to make the files non-overlapping (by renaming)
Peter: the problem is that our srtp is a drop-in replacement, so the plugins
(files) are called exactly the same (they have to be) so you get the same
file in both packages
RP: you could make it a symlink (the debug symbols will be based on the
original file, not the symlink), if you rename the file but made a symlink
that might get around the issue
Peter: interesting idea…
RP: we’ve moving the goal-posts, but i think the symlink path would be
easier
TrevorW: honister-specific?
Peter: yes, there was a change (june 28) in the package manager. previously,
the complimentary packages were built attempt-only=true so dnf was called
with the skip-broken option which ended up hiding the issue. it would
ignore installing one of the packages at random. so previously there was
a chance that symbols wouldn’t be there, and nobody would notice unless
they were specifically needing those symbols. the honister change is an
improvement since it makes it obvious when an issue comes up.
ScottM: it would be nice to have the debug packages setup the same way other
distros do, but if it blows up the build times, then that would probably
not be worth it. it would be nice if someone had the cycles to prototype
it so we’d have the data
RP: it’s probably optimizable to some extent. we have some crazy build times
for things like packaging ltp. for ltp it probably doesn’t matter, but
for perl-modules it probably does. if you add more packages the build time
scales badly. one of the implications would be separate debug symbols for
each kernel module, which would at least double the number of packages in
a kernel build
Peter: for us we’d just do it for gstreamer, since that’s the only one
causing us issues. in an ideal world everything would be handled the same
RP: you can do that and the system will let you do that, but that’s not
a change i’d take into core. currently the policy is to have 1 debug
package per recipe, and that’s not something we’re about to change.
separate debug packages will work, but will affect build times
Peter: i could just remove the debug symbols for one of the packages, and hope
nobody ever needs to debug it
RP: separate debug packages will work, but we’re not going to change the
policy
Peter: i also have a similar problem with hardknott (which still has the
keep-broken option enabled) so i can’t figure that out. similar, but not
the same
TrevorW: there was discussion around having more of a presentation +
discussion style meeting each month at the OE happy hour
Jon: possible, we have done it in the past, we’re open to it, but it’s
hard to get people to do it (and having them do the prep). but having
a YPS gives people something to shoot for. lots of work to do a
presentation, OEHH is more informal. it would need someone or something
to drive it and make it more formal. Paul Barker has done a couple
show-and-tells informally at some OEHHs
TimO: i like the spontaneous show-and-tell
Jon: most people are trained to think in terms of conferences and doing
presentations there. trying to do it informally might make it less likely
to happen. we can take it to the board
RP: i’ve been chatting with Khem and he says the SH4 patches are there
because i wanted them in, so i guess i’ll remove them
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#55591): https://lists.yoctoproject.org/g/yocto/message/55591
Mute This Topic: https://lists.yoctoproject.org/mt/87734783/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
