remove systemd from DISTRO_FEATURES as well. DISTRO_FEATURES_remove = "sytemd"

Current Dev Position: YP 3.3 M4 (Feature Freeze) Next Deadline: 5th April 2021 YP 3.3 M4 build Next Team Meetings: Bug Triage meeting Thursday Apr. 15th at 7:30am PDT

Not sure what happened with the file deletion but I'll fix that. Cheers, Richard

Signed-off-by: Richard Purdie <richard.purdie@...> --- bsp-addition-example.patch | 54 -------------------------------------- config.py | 3 +++ 2 files changed, 3

Signed-off-by: Richard Purdie <richard.purdie@...> --- config.py | 1 + schedulers.py | 14 ++++++++++++-- 2 files changed, 13 insertions(+), 2 deletions(-) diff --git

I have created rootfs with Rocko yocto version. I need sysyvinit as system manager instead of Systemd. I have tried with following in local.conf DISTRO_FEATURES_append = "

Hello All, This is the full report for yocto-3.3.rc2: https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults ======= Summary ======== No high

I haven't been doing much with it lately and this got lost in my pile. Its merged to master.-- Jeremy Puhlman Montavista Software, LLC.

Is this layer alive? :) ../Randy -- # Randy MacLeod # Wind River Linux

All, YP M+ or high bugs which moved to a new milestone in WW15 are listed below: Priority Bug ID Short Description Changer Owner Was Became Medium+ 5389 bitbake/lib/bb/fetch2: filename too

All, The below were the owners of enhancements or bugs closed during the last week! Who Count randy.macleod@... 5 limon.anibal@... 2 mhalstead@... 1 steve@... 1 Grand Total 9 Thanks,

All, Below is the list as of top 37 bug owners as of the end of WW15 of who have open medium or higher bugs and enhancements against YP 3.3. There are 13 possible work days left until the final

All, The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on

Op 12-04-2021 om 10:13 schreef Robert Berger@...: Yeah, C++. But apearently it's during the LTO phase where it eat my memory. Yup. So then it would just fail the build? Nope.

Hi, Op 12-04-2021 om 04:25 schreef ChenQi: Yeah, so we would be having memwatch as a baby sitter. I would be nicer to have it built into bitbake, but this would work too.

Signed-off-by: Anton Antonov <Anton.Antonov@...> --- .../recipes-parsec/parsec-service/parsec-service_0.7.0.bb | 4 ++-- meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.3.0.bb | 3 +--

I'd suggest you place that tarball into some artefact storage, and have it listed in SRC_URI. Then the standard Yocto mechanism for fetching, checksumming, caching and unpacking tarballs kicks in, so

Hi Alex, OK, understood. If the "local download cache path" is well-known (this is not by any chance $DL_DIR?), then we could create a tar from the vendor directory (which is created when you call

Reproducibility means anyone can run a build at any point in the future even if the upstream repositories are gone, so all inputs must be stored in a local download cache, which is the other thing

Hi Robert, thanks for your thoughts. I see your point and the last thing I want is "NOT reproducable builds". But dependency management in go is not that arbitrary as it may seem. Dependencies and