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

Alexander (whom you cc'ed here as well) wrote a long time ago on the mailing list[1] about this stuff. We have a couple of issues with those "modern" languages like go, which behave quite differently

Hello Konrad, thanks for your reply. It is interesting that you mention vendoring, because we tried this approach as well. We started to develop a "go-mod-vendor.bbclass", which retrieves

Met vriendelijke groet / kind regards, Mike Looijmans System Expert TOPIC Embedded Products B.V. Materiaalweg 4, 5681 RJ Best The Netherlands T: +31 (0) 499 33 69 69 E:

Hi, My comments are in-line. The RAM usage depends heavily on what you are building ;) - It could be some crazy C++ stuff ;) Is Linux your build host? Then you can use cgroups to limit resources

I think you write a script to do all the WATCH-STOP-CONTINUE stuff. e.g. memwatch bitbake core-image-minimal Options could be added. e.g. memwatch --interval 5

make already has -l option for limiting new instances if load average is too high, so it's only natural to add a RAM limiter too. -l [N], --load-average[=N], --max-load[=N]

Op 11-04-2021 om 17:55 schreef Alexander Kanavin: Bitbake does a lot of babysitting anyway :-) And is pretty good at it too. To me, fixing make et al. is more work and less effective then adding a