> On Wed, 23 Jun 2021, Michał Górny wrote:
>> It's just not available for everyone for free/without registration
>> anymore. But it is still a thing in Gentoo.
> Your comment makes it sounds like 'just registering' is an option.
> The website seems to disagree with that, pretty clearly sayin
# Miroslav Šulc (2021-06-23)
# obsolete, no consumers
# see bug: https://bugs.gentoo.org/797739
dev-java/xml-commons
# Volkmar W. Pogatzki (2021-06-21)
# libraries without consumers, removal in 30 days
dev-java/bytelist
dev-java/jcodings
dev-java/joni
dev-java/jvyamlb
Python 3.9 includes a new feature for compileall to automatically hardlink
different optimization level cache files if they are identical. Make use of it
for python_optimize for some space savings.
This however does not cover distutils use cases and python itself.
---
eclass/python-utils-r1.eclass
Python 3.5 added support for compileall to run parallel workers for
performing bytecode compilation. Make use of it to the extent
possible without refactoring the code too much to get different
paths into the same call for best possible parallelization.
---
eclass/python-utils-r1.eclass | 16 +
On mercoledì 23 giugno 2021 11:36:33 CEST Mart Raudsepp wrote:
> + jobs=$(( nproc + 1 ))
I don't know who historically started the nproc+1 story (it looks to be in the
handbook too), but it has been demonstrated that nproc+1 is slower than nproc.
Agostino
On 2021-06-22 19:01, Sergei Trofimovich wrote:
One of the steps forward for libffi would be to add extra USE=pax-kernel
with REQUIRED_USE="pax_kernel? ( pax-kernel )" or 'die' equivalent.
Sounds like a good idea to me, that way people who don't pay attention
to news items will notice.
--
Ma
Ühel kenal päeval, K, 23.06.2021 kell 11:43, kirjutas Agostino Sarubbo:
> On mercoledì 23 giugno 2021 11:36:33 CEST Mart Raudsepp wrote:
> > + jobs=$(( nproc + 1 ))
>
> I don't know who historically started the nproc+1 story (it looks to
> be in the
> handbook too), but it has been
On Wed, 2021-06-23 at 12:36 +0300, Mart Raudsepp wrote:
> Python 3.9 includes a new feature for compileall to automatically hardlink
> different optimization level cache files if they are identical. Make use of it
> for python_optimize for some space savings.
> This however does not cover distutils
On Wed, 2021-06-23 at 11:43 +0200, Agostino Sarubbo wrote:
> On mercoledì 23 giugno 2021 11:36:33 CEST Mart Raudsepp wrote:
> > + jobs=$(( nproc + 1 ))
>
> I don't know who historically started the nproc+1 story (it looks to be in
> the
> handbook too), but it has been demonstrated
Ühel kenal päeval, K, 23.06.2021 kell 11:56, kirjutas Michał Górny:
> > - python*|pypy3)
> > + python3.[5678]|pypy3)
>
> We don't really support < 3.8 anymore but I can update that while
> merging, I guess.
Yeah, this is originating from the previous bl
> On Mon, 21 Jun 2021, Sam James wrote:
> I'm happy with the whole series. Thanks for working on this.
Merged.
signature.asc
Description: PGP signature
On Wed, 2021-06-23 at 13:19 +0300, Mart Raudsepp wrote:
> Ühel kenal päeval, K, 23.06.2021 kell 11:56, kirjutas Michał Górny:
> > > - python*|pypy3)
> > > + python3.[5678]|pypy3)
> >
> > We don't really support < 3.8 anymore but I can update that while
>
https://qa-reports.gentoo.org/output/eapi-per-eclass/darcs.eclass/
says that there are no consumers left.
So, could the eclass be removed?
signature.asc
Description: PGP signature
hi guys,
here is a patch that should provide initial support for module-info.java
in java packages. more info can be found here:
https://bugs.gentoo.org/796875
i'd mainly appreciate comments on the style of the patch whether it's ok
or what should be improved, though any questions or suggest
On Wed, 23 Jun 2021 20:49:47 +0200
Ulrich Mueller wrote:
> https://qa-reports.gentoo.org/output/eapi-per-eclass/darcs.eclass/
> says that there are no consumers left.
There are two references worth cleaning up to avoid possible future confusion:
$ git grep darcs | fgrep inherit
net-misc
16 matches
Mail list logo
