On Tuesday, December 13, 2016 06:00:25 PM Mike Gilbert wrote:
> Keeping up with the frequent Chromium releases is quite a chore.
> Recently, phajdan.jr has been slacking on the masked dev channel
> updates due a hardware problem, so I have been spending additional
> time on them.
>
> If there are
On 12/13/2016 10:47 AM, Christopher Head wrote:
> On December 9, 2016 10:12:54 PM PST, "A. Wilcox"
> wrote:
>> I think James has perhaps spoken ambiguously, or at least I hope that
>> you have misunderstood his proposal. (If you haven't, then he's
>> misunderstood mine.)
>>
>> The point of makin
On Mon, Dec 12, 2016 at 02:35:28PM +1100, Sam Jorna wrote:
> On Mon, Dec 12, 2016 at 09:34:21AM +0700, gro...@gentoo.org wrote:
> > On Sun, 11 Dec 2016, Kristian Fiskerstrand wrote:
> > > On 12/11/2016 03:13 PM, gro...@gentoo.org wrote:
> > >> gpg: signing failed: Inappropriate ioctl for device
> >
Keeping up with the frequent Chromium releases is quite a chore.
Recently, phajdan.jr has been slacking on the masked dev channel
updates due a hardware problem, so I have been spending additional
time on them.
If there are any developers with relatively fast hardware that could
take on the stable
Our bug queue has 94 bugs!
If you have some spare time, please help assign/sort a few bugs.
To view the bug queue, click here: http://bit.ly/m8PQS5
Thanks!
On December 9, 2016 10:12:54 PM PST, "A. Wilcox"
wrote:
>I think James has perhaps spoken ambiguously, or at least I hope that
>you have misunderstood his proposal. (If you haven't, then he's
>misunderstood mine.)
>
>The point of making it easier to fork is not only for the benefit of
>developer
On Tue, Dec 13, 2016 at 8:59 AM, Michael Orlitzky wrote:
> On 12/13/2016 06:11 AM, Mike Pagano wrote:
>>
>> You're absolutely right, Mike. It was the devmanual.
>>
>> I'm not a fan of having an empty usage. As the devmanual is written
>> today, it is not optional.
>>
>
> The devmanual is once agai
On 12/13/2016 06:11 AM, Mike Pagano wrote:
>
> You're absolutely right, Mike. It was the devmanual.
>
> I'm not a fan of having an empty usage. As the devmanual is written
> today, it is not optional.
>
The devmanual is once again based on the awk script, which vaguely
implies that USAGE is req
On 12/12/2016 09:49 PM, Mike Gilbert wrote:
> On Mon, Dec 12, 2016 at 9:44 PM, Mike Gilbert wrote:
>> On Mon, Dec 12, 2016 at 7:34 PM, Mike Pagano wrote:
>>> According to PMS, @USAGE is required for functions.
>>> This patch only touches comments and no code has been modified.
>>
>> PMS says no
Introduce get_nproc(), a portable 'nproc' wrapper. It uses either
'nproc' or a fallback Python multiprocessing module call to attempt to
determine the number of available processing units.
This can be used e.g. to determine a safe number of jobs to run when
MAKEOPTS specifies unlimited --jobs and
Support passing custom values for 'infinity' in makeopts_jobs()
and makeopts_loadavg(). This can be used e.g. when a build system does
not support --loadavg, and therefore '--jobs 999' would most likely
be a really bad idea. Combined with get_nproc(), this can be used to
provide a sane replacement
Hello,
Here's a short batch of improvements to multiprocessing.eclass.
Patch 1 fixes handling multiple short args, e.g. '-kj'.
Patch 2 adds get_nproc() (copied from scons-utils.eclass) that tries
to portably determine the number of available CPUs.
Patch 3 adds the option to explicitly specify t
Improve the regular expressions to handle parameters consisting of
multiple short options (such as -kj). It should be noted that the code
is not perfect but should handle all common (valid) cases; it could e.g.
incorrectly process a short option followed by string arg such as
'-Wfoo.j' although hav
13 matches
Mail list logo
