Re: why does devel/electron41 show as blacklisted on pkg.f.o

On 6/30/26 02:40, Mark Millard wrote:
> On 6/30/26 01:22, Dag-Erling Smørgrav wrote:
>> Mark Felder <[email protected]> writes:
>>> Yes, it will often be competing with multiple llvm, gcc, and the rust
>>> port. But it has never taken anywhere near as long as it does on the
>>> build cluster.
>>
>> Poudriere's scheduling is lousy (though it's mostly not its own fault).
>> You basically have a choice between occasional gridlock and chronic
>> underutilization, and it's actually easier to gridlock a beefier builder
>> than a skinnier one.  I desperately want to do something about it, but
>> it's more work than I can take on in my spare time, so it's not going to
>> happen any time soon unless someone is willing to sponsor it.
>>
>> DES
> 
> Given the context that exists, for poudriere-devel bulk runs that build
> the 34000+ port-packages, the best overall time minimization without
> having memory or disk resource failures that I've had has been based on:
> 
> 
> ) Generally high load averages so that there is mostly pending useful
> work ready to be worked on instead of even more time spent idle waiting
> for useful work to do.
> 
> ) A fair sized amount of RAM for the number of hardware threads.
>   [Example: 192 GiBytes of RAM for 32 hardware threads on the least time
> taking system.]
> 
> ) Lots of SWAP space that is PCIe Optane speed or the like.
>   [In general I avoid spinning rust.]
> 
> ) So, as an example: RAM+SWAP = 4.6*RAM, though I have access to an
> example that is closer to only 3.6*RAM --the earlier mentioned system.
> 
> ) Avoiding builders that would have large tmpfs usage for unconstrained
> USE_TMPFS=all from using much tmpfs. This is avoidance of resource
> failures. Such failures lead to a lot more overall time from the retries.
> 
> ) Also some mutual exclusions for what runs at the same time. More
> avoidance of resource failures.
> 
> ) Biasing that long running mostly-single threading builds have a higher
> tendency to run in parallel with other building port-packages, instead
> of by themselves.
> 
> ) Allowing slower processing hardware threads to still contribute to
> progress, rather than being idle.
> 
> 
> But the details would not scale well to hundreds or more of hardware
> threads: scaling RAM+SWAP would not be practical. For my context it
> would not even be practical to double the number of hardware threads.
> 
> It also makes looking at individual port-package build times not
> particularly useful. [The minimum overall time < the sum of the
> individual minimum times.]
> 

I forgot a major help that is in poudriere-devel (a poudriere.conf
setting): PKG_NO_VERSION_FOR_DEPS=yes

With that it can be common for a sizable fraction of builders get a
quick inspection and end up not rebuilding. But, last I knew,
PKG_NO_VERSION_FOR_DEPS=yes was little documented.


-- 
===
Mark Millard
marklmi at yahoo.com