The _python_impl_supported() function is not used anymore in its
original function. It is called only once, in order to die on incorrect
targets in PYTHON_COMPAT. Let's inline the corresponding logic
in _python_set_impls() and remove the function.
While at it, add an extra check for outdated
# Michał Górny (2021-01-01)
# RenPy requires Python 2.7 at runtime, and py3 port has not been
# released yet. Even if it were, the games would probably need porting
# anyway.
# Removal in 30 days. Bug #735358.
dev-python/numpy-python2
games-engines/renpy
games-misc/katawa-shoujo
# Alfredo Tupone (2020-08-16)
# Ported to py3.8 but not yet released
# Masked to allow py2.7 removal
# Michał Górny (2021-01-01)
# Masking for removal to prevent eclass from crashing on these packages.
# Removal in 30 days.
dev-ada/langkit
dev-ada/libadalang
dev-ada/libadalang-tools
dev-ada/gps
On Tue, 29 Dec 2020 23:34:36 +
Peter Stuge wrote:
> David Seifert wrote:
> > > Maybe because it is so well-known that monoculture is harmful per se,
> > > which is why the commitment to choice in Gentoo is very valuable.
> > >
> > > Further, LibreSSL comes out of the OpenBSD project, which
Alessandro Barbieri wrote:
> > Obviously this will only be useful for packages wanting to statically link
> > with libressl lib{crypto,ssl}
>
> There is an ongoing effort to remove static libraries from packages.
I know, and I couldn't disagree more with that effort.
> > but I think that's far
>
> Installing both openssl and libressl .a files in different directories
> seems both useful and straightforward. I don't object to openssl being
> favored for /usr/lib here, libressl gets a directory of its own, but
> libressl.pc goes into /usr/lib/pkgconfig so that it is found automatically.
>
TL;DR if you never used rsync:// access to download copies of data
from our VCS's you can stop paying attention. This has nothing to do
with "gentoo rsync mirrors" for ::gentoo, which is a separate service
that we are not terminating.
We previously offered rsync:// protocol access to gentoo VCS
On 12/31/20 11:47 AM, Matt Turner wrote:
> Since the KEYWORDS=... assignment is a single line, git struggles to
> handle conflicts. When rebasing a series of commits that modify the
> KEYWORDS=... it's usually easier to throw them away and reapply on the
> new tree than it is to manually handle
On Mon, Dec 28, 2020 at 8:09 PM Zac Medico wrote:
>
> On 12/28/20 3:15 PM, Matt Turner wrote:
> > +def apply_keyword_changes(ebuild: str, pathname: str,
> > + changes: List[Tuple[Optional[str],
> > + Optional[str]]]) -> int:
>
Since the KEYWORDS=... assignment is a single line, git struggles to
handle conflicts. When rebasing a series of commits that modify the
KEYWORDS=... it's usually easier to throw them away and reapply on the
new tree than it is to manually handle conflicts during the rebase.
git allows a 'merge
> On Thu, 31 Dec 2020, Francisco Blas Izquierdo Riera (klondike) wrote:
> El 26/12/20 a las 10:20, Ulrich Mueller escribió:
>> This would apply retroactively since 2018-10-21 (when GLEP 76 was marked
>> as Active). I am going to file a bug for authors to acknowledge that
>> their news items
Hi Jaco,
Jaco Kroon wrote:
> So a few points that I picked up during this discussion.
>
> 1. Nobody is AGAINST libressl per sé,
Michał gives me a distinctly different impression.
> 2. A number of people are AGAINTS the effort involved to make
> libressl work for various packages.
Yes, and
El 26/12/20 a las 10:20, Ulrich Mueller escribió:
This would apply retroactively since 2018-10-21 (when GLEP 76 was marked
as Active). I am going to file a bug for authors to acknowledge that
their news items can be distributed under CC-BY-SA-4.0.
For all matters the news item I wrote in 2017
Hi Peter,
I believe that as a maintainer I stated same in a previous email, and
based on what I've read it seems very few maintainers/developers would
object to it if someone was willing to do the work to enable things to
co-exist. So a few points that I picked up during this discussion.
1.
Mike Gilbert wrote:
> > It is important to me that you can choose dev-libs/libretls instead of
> > having any libretls code on your systems, but I reject you forcing that
> > choice of yours on everyone else.
>
> I'm having trouble making sense of this sentence. Did you mean to
> write "libressl"
Excerpt from MichaŠGórny and previous post:
> > Further, LibreSSL comes out of the OpenBSD project, which has a good
> > reputation on code quality.
> I could buy that if it actually said anything about LibreSSL code
> quality. So far you're guessing that it might or might not, especially
>
On Thu, 2020-12-31 at 02:50 +, Peter Stuge wrote:
> Michał Górny wrote:
> > > > I think the three main ways forward from here would be to either:
> > > >
> > > > 1. Keep LibreSSL for indefinite time (possibly masked)
> > > > 2. Eventually move LibreSSL to libressl overlay.
> > > > 3.
On Thu, 2020-12-31 at 02:50 +, Peter Stuge wrote:
> Michał Górny wrote:
> > > > I think the three main ways forward from here would be to
> > > > either:
> > > >
> > > > 1. Keep LibreSSL for indefinite time (possibly masked)
> > > > 2. Eventually move LibreSSL to libressl overlay.
> > > > 3.
18 matches
Mail list logo
