| 1 |
> On 5 Jan 2022, at 17:51, Alec Warner <antarus@g.o> wrote: |
| 2 |
> On Tue, Jan 4, 2022 at 3:03 PM Sam James <sam@g.o> wrote: |
| 3 |
>> |
| 4 |
>> On 4 Jan 2022, at 22:58, Sam James <sam@g.o> wrote: |
| 5 |
>> Crank down MAKEOPTS jobs if MAKEOPTS="-jN" is too high for the |
| 6 |
>> amount of RAM available (uses amount declared as needed |
| 7 |
>> in the ebuild). Typically should be ~2GB per job. |
| 8 |
>> [snip] |
| 9 |
> |
| 10 |
> I'm still not sure I grasp why we cannot make OOMs easier to discover |
| 11 |
> from portage. |
| 12 |
> |
| 13 |
> Most packages don't even use check-reqs, so your solution is very |
| 14 |
> narrow (and I get why, because you get a lot of bug reports from the |
| 15 |
> big packages that do use it.) |
| 16 |
> |
| 17 |
|
| 18 |
Yeah, you've got the thinking here :) |
| 19 |
|
| 20 |
> Can we write a build log analyzer? |
| 21 |
|
| 22 |
I think this is a good idea, even if it's just a few hand-gathered regexes, |
| 23 |
we can try improve the situation a bit, even for non-OOM (like |
| 24 |
some common Perl-related failures). |
| 25 |
|
| 26 |
> |
| 27 |
> -A |
| 28 |
> |
| 29 |
> PS: If this was a global change I'd downvote it. It's only for |
| 30 |
> check-reqs though and most packages don't use check-reqs; I don't |
| 31 |
> really care. I'd be concerned about adopting this kind of approach |
| 32 |
> wider; its very much a bandaid. |
| 33 |
> |
| 34 |
|
| 35 |
Yep, I don't deny that, and I can't really say I'd support this |
| 36 |
if it was global. The specific intent here is that check-reqs |
| 37 |
consumers are generally big beasts and hence it's a direct, |
| 38 |
targeted action to reduce bad bug reports and improve |
| 39 |
the user experience, especially for newcomers who |
| 40 |
end up hitting OOMs early on. |
| 41 |
|
| 42 |
Best, |
| 43 |
sam |
Archives