On Thu, 2020-02-27 at 16:31 +1300, Kent Fredric wrote:
> On Wed, 26 Feb 2020 15:36:52 +0100
> Michał Górny wrote:
>
> > +fdo-mime = xdg-utils
> > +games = (none)
>
> Some of these need to have more context. For instance, a comment for
> the games one citing -ml discussions about why the eclass i
On Wed, 4 Mar 2020 11:55:30 -0800
Matt Turner wrote:
> needs_exe_wrapper tells meson whether the build machine is able to
> directly execute the binaries it produces or whether it needs an exe
> wrapper (like QEMU). For non-native ABI builds like building 32-bit
> libraries on an x86-64 system,
On Wed, Feb 26, 2020 at 09:24:35AM -0600, William Hubbs wrote:
> *** BLURB HERE ***
> This is another round of support for go modules.
> The first patch adds goproxy to the gentoo mirror system so that
> ebuilds can be written with "mirror://goproxy/foo/bar" in SRC_URI. This
> is used by the go-mod
needs_exe_wrapper tells meson whether the build machine is able to
directly execute the binaries it produces or whether it needs an exe
wrapper (like QEMU). For non-native ABI builds like building 32-bit
libraries on an x86-64 system, we want this set to false to communicate
to meson that the build
This will be shown as relevant to everyone who has installed
virtual/opencl, i.e. also to people on amd64 who have NOT enabled
abi_x86_32 for this package - but there is no way to filter news items
by use flags, is there? Anyway, comments are welcome!
* * *
Title: Removing ABI_X86_32 support fro
# Michał Górny (2020-03-04)
# Dead. Last commit in 2011. Python 2 only. Requires old version
# of Django. The Gentoo instance is being replaced by pluto
# (https://github.com/feedreader/pluto).
# Removal in 30 days. Bug #706362.
www-apps/venus
--
Best regards,
Michał Górny
signature.asc
Most of upstream code has got merged into x-crypto (dev-go/go-crypto),
and since go-1.13 subsequently into the Go standard library.
Original code is no longer maintained and contains known bugs.
Removal in 30 days. Bug #711520.
--
MS
signature.asc
Description: OpenPGP digital signature
All the share-related issues should have been fixed by the PyPy patch
by now, and since PyPy target is not stable, there is really no need
to be very graceful here.
Signed-off-by: Michał Górny
---
eclass/distutils-r1.eclass | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/e
Signed-off-by: Michał Górny
---
eclass/python-any-r1.eclass | 4
1 file changed, 4 insertions(+)
diff --git a/eclass/python-any-r1.eclass b/eclass/python-any-r1.eclass
index 5d74c8acd3e4..66c6965c04ea 100644
--- a/eclass/python-any-r1.eclass
+++ b/eclass/python-any-r1.eclass
@@ -301,6 +301,
Stop requiring ebuilds to call distutils-r1_python_install_all default
function. It just calls einstalldocs these days, and it is unlikely
that more magic will ever be added there.
Signed-off-by: Michał Górny
---
eclass/distutils-r1.eclass | 9 -
1 file changed, 9 deletions(-)
diff --g
Signed-off-by: Michał Górny
---
eclass/python-single-r1.eclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/eclass/python-single-r1.eclass b/eclass/python-single-r1.eclass
index 87e1cb97deda..f9e26e7c334f 100644
--- a/eclass/python-single-r1.eclass
+++ b/eclass/python-single-r1.eclass
@@
Signed-off-by: Michał Górny
---
eclass/python-utils-r1.eclass | 20 +++-
1 file changed, 3 insertions(+), 17 deletions(-)
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index 2791fae42112..325964e0e0e8 100644
--- a/eclass/python-utils-r1.eclass
+++ b/e
Signed-off-by: Michał Górny
---
eclass/python-r1.eclass | 1 +
1 file changed, 1 insertion(+)
diff --git a/eclass/python-r1.eclass b/eclass/python-r1.eclass
index cd4c22aa0bd8..960fed8c451a 100644
--- a/eclass/python-r1.eclass
+++ b/eclass/python-r1.eclass
@@ -785,6 +785,7 @@ python_setup() {
Signed-off-by: Michał Górny
---
eclass/python-utils-r1.eclass | 1 +
1 file changed, 1 insertion(+)
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index bb7f1a232688..37ab9c84eda6 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -1261,
Signed-off-by: Michał Górny
---
eclass/python-utils-r1.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index 37ab9c84eda6..2791fae42112 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils
---
eclass/distutils-r1.eclass | 4 ++--
eclass/python-any-r1.eclass| 6 +++---
eclass/python-r1.eclass| 6 +++---
eclass/python-single-r1.eclass | 4 ++--
eclass/python-utils-r1.eclass | 6 +++---
5 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/eclass/distutils-r
Hi,
Here's a short series addressing some issues I've noticed in the code.
This is mostly stale documentation, non-doc changes are:
1. python_setup() now verbosely reports the implementation selected.
2. leftover code to workaround virtual/pypy* is removed.
3. calling distutils-r1_python_instal
[2020-03-04 13:07:40+0100] Michał Górny:
> Summary
> ===
> So to summarize, of the three proposed approaches:
>
> 1. A & C provide for fast cleanup of old API with mostly-automated
> conversion.
>
> 2. B & C provide for gradual cleanup of warnings and old EAPIs, i.e.
> stuff requiring runtime
Hi, everyone.
After sending the recent proposal for python-r2 eclass suite, I've
realized that I have ended up somewhere in the middle of two possible
goals. Therefore, I'd like to take a step back and ask what kind of
python-r2 suite would be preferable.
I see two basic options: either we go fo
19 matches
Mail list logo
