> On 5 Jan 2022, at 17:51, Alec Warner <anta...@gentoo.org> wrote: > On Tue, Jan 4, 2022 at 3:03 PM Sam James <s...@gentoo.org> wrote: >> >> On 4 Jan 2022, at 22:58, Sam James <s...@gentoo.org> wrote: >> Crank down MAKEOPTS jobs if MAKEOPTS="-jN" is too high for the >> amount of RAM available (uses amount declared as needed >> in the ebuild). Typically should be ~2GB per job. >> [snip] > > I'm still not sure I grasp why we cannot make OOMs easier to discover > from portage. > > Most packages don't even use check-reqs, so your solution is very > narrow (and I get why, because you get a lot of bug reports from the > big packages that do use it.) >
Yeah, you've got the thinking here :) > Can we write a build log analyzer? I think this is a good idea, even if it's just a few hand-gathered regexes, we can try improve the situation a bit, even for non-OOM (like some common Perl-related failures). > > -A > > PS: If this was a global change I'd downvote it. It's only for > check-reqs though and most packages don't use check-reqs; I don't > really care. I'd be concerned about adopting this kind of approach > wider; its very much a bandaid. > Yep, I don't deny that, and I can't really say I'd support this if it was global. The specific intent here is that check-reqs consumers are generally big beasts and hence it's a direct, targeted action to reduce bad bug reports and improve the user experience, especially for newcomers who end up hitting OOMs early on. Best, sam
signature.asc
Description: Message signed with OpenPGP
