[gentoo-dev] [RFC] The right approach to python-r2 (-r3?)

2020-03-04 Thread Michał Górny
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 for removing deprecated API while
keeping the changes to the bare minimum possible without runtime
testing, or we go for changing some more and require runtime testing
when porting.  Let me expand on both concepts.


Approach A: minimal API changes
===
In this approach, I make only clearly cut API changes.  It will be
possible to migrate most of the ebuilds via a bunch of seds in a script,
and to detect cases needing manual update via some more greps.  This
will make the migration quick and mostly painless.

As an implication of that, I would keep support for all old EAPIs
and not make any of the runtime warnings more fatal than they are right
now (particularly DISTUTILS_USE_SETUPTOOLS remains a warning).

The migration plan would be roughly to:

1. Prepare a script converting ebuilds to new eclasses.

2. Run a test conversion and pass it over to Toralf for random testing.

3. Push the conversion.

4. Deprecate the old eclasses.

5. Convert remaining ebuilds manually (those that script can't convert).

6. Last rite the old eclasses.


Approach B: maximum cleanup
===
This approach involves making all current warnings fatal, and removing
support for old EAPIs.  While script would still help updating ebuilds,
it will be necessary to test every migrated ebuild.

The migration plan would be roughly to:

1. Prepare the script.

2. Convert some ebuilds on bumps.

3. Deprecate the old eclasses.

4. Wait forever for ::gentoo to be converted.

5. Last rite the old eclasses.

6. Wait again.

7. Remove the eclasses and hear people complaining that 6.5 years were
too short to migrate over.


Approach C: hybrid approach
===
Alternatively, I could combine both approaches: commit python-r2 suite
that follows approach A, and python-r3 suite that follows B.  For
practical reasons, the -r3 eclasses would probably boil down to:

  _PYTHON_R3_API=1
  inherit python...-r2

as they would merely enforce stricter warning rules.

The migration plan:

1. Prepare the script.

2. Run a test conversion to -r2, ask Toralf, push it.

3. In parallel, start manually switching to -r3 on bumps.

4. Deprecate -r1 and -r2.

5. Convert remaining ebuilds from -r1 to -r3.

6. Last rite -r1.

7. Wait forever.

8. Last rite -r2.


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 testing.

3. A & C makes it possible to get rid of -r1 shortly and reduce
maintenance effort.


What do you think?


-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [RFC] The right approach to python-r2 (-r3?)

2020-03-04 Thread Haelwenn (lanodan) Monnier
[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 testing.
> 
> 3. A & C makes it possible to get rid of -r1 shortly and reduce
> maintenance effort.
> 
> 
> What do you think?

It looks like you get everything nicely with option C, only drawback 
I can think of is more code but you put it with 3. as maintainance 
reducing so I guess it is the way to go.

But I'm wondering if there is some monster not shown by your email but
maybe it's because I might not have dug deep enough into python on 
gentoo (probably because it has been going nicely so thanks btw).



[gentoo-dev] [PATCH 0/9] python-r1 suite cleanup

2020-03-04 Thread Michał Górny
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_install_all is no longer mandatory.
   It it just a thin wrapper on einstalldocs, so it's fine to call
   einstalldocs instead.

4. /usr/lib/pypy*/share is now a fatal error.  It shouldn't be happening
   now that pypy* is patched.

Best regards,
Michał Górny

Michał Górny (9):
  python*-r1.eclass, distutils-r1.eclass: Link to Python Guide
  python-utils-r1.eclass: Mark _python_check_locale_sanity @INTERNAL
  python-utils-r1.eclass: Update docs to use python_setup
  python-r1.eclass: Report impl used by python_setup
  python-any-r1.eclass: Report impl used by python_setup
  python-single-r1.eclass: Report impl used by python_setup
  python-utils-r1.eclass: Remove leftover from virtual/pypy*
  distutils-r1.eclass: Do not require distutils-r1_python_install_all
  distutils-r1.eclass: Make /usr/lib/pypy/share warning fatal

 eclass/distutils-r1.eclass | 17 +++--
 eclass/python-any-r1.eclass| 10 +++---
 eclass/python-r1.eclass|  7 ---
 eclass/python-single-r1.eclass |  6 --
 eclass/python-utils-r1.eclass  | 31 +--
 5 files changed, 27 insertions(+), 44 deletions(-)

-- 
2.25.1




[gentoo-dev] [PATCH 1/9] python*-r1.eclass, distutils-r1.eclass: Link to Python Guide

2020-03-04 Thread Michał Górny
---
 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-r1.eclass b/eclass/distutils-r1.eclass
index 27ca236ccf5f..8b7745686d73 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -40,8 +40,8 @@
 # as well. Thus, all the variables defined and documented there are
 # relevant to the packages using distutils-r1.
 #
-# For more information, please see the wiki:
-# https://wiki.gentoo.org/wiki/Project:Python/distutils-r1
+# For more information, please see the Python Guide:
+# https://dev.gentoo.org/~mgorny/python-guide/
 
 case "${EAPI:-0}" in
0|1|2|3|4)
diff --git a/eclass/python-any-r1.eclass b/eclass/python-any-r1.eclass
index 878e337ff3c2..5d74c8acd3e4 100644
--- a/eclass/python-any-r1.eclass
+++ b/eclass/python-any-r1.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2019 Gentoo Authors
+# Copyright 1999-2020 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: python-any-r1.eclass
@@ -33,8 +33,8 @@
 # packages using python-any-r1, and there is no need ever to inherit
 # both.
 #
-# For more information, please see the wiki:
-# https://wiki.gentoo.org/wiki/Project:Python/python-any-r1
+# For more information, please see the Python Guide:
+# https://dev.gentoo.org/~mgorny/python-guide/
 
 case "${EAPI:-0}" in
[0-4]) die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}" ;;
diff --git a/eclass/python-r1.eclass b/eclass/python-r1.eclass
index dd350a436fa5..cd4c22aa0bd8 100644
--- a/eclass/python-r1.eclass
+++ b/eclass/python-r1.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2018 Gentoo Foundation
+# Copyright 1999-2020 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: python-r1.eclass
@@ -26,8 +26,8 @@
 # in the packages using python-r1, and there is no need ever to inherit
 # both.
 #
-# For more information, please see the wiki:
-# https://wiki.gentoo.org/wiki/Project:Python/python-r1
+# For more information, please see the Python Guide:
+# https://dev.gentoo.org/~mgorny/python-guide/
 
 case "${EAPI:-0}" in
0|1|2|3|4)
diff --git a/eclass/python-single-r1.eclass b/eclass/python-single-r1.eclass
index 739a394ddd18..87e1cb97deda 100644
--- a/eclass/python-single-r1.eclass
+++ b/eclass/python-single-r1.eclass
@@ -33,8 +33,8 @@
 # in the packages using python-single-r1, and there is no need ever
 # to inherit both.
 #
-# For more information, please see the wiki:
-# https://wiki.gentoo.org/wiki/Project:Python/python-single-r1
+# For more information, please see the Python Guide:
+# https://dev.gentoo.org/~mgorny/python-guide/
 
 case "${EAPI:-0}" in
0|1|2|3|4)
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index 91a32434dfaa..bb7f1a232688 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2019 Gentoo Authors
+# Copyright 1999-2020 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: python-utils-r1.eclass
@@ -16,8 +16,8 @@
 # This eclass does not set any metadata variables nor export any phase
 # functions. It can be inherited safely.
 #
-# For more information, please see the wiki:
-# https://wiki.gentoo.org/wiki/Project:Python/python-utils-r1
+# For more information, please see the Python Guide:
+# https://dev.gentoo.org/~mgorny/python-guide/
 
 case "${EAPI:-0}" in
[0-4]) die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}" ;;
-- 
2.25.1




[gentoo-dev] [PATCH 3/9] python-utils-r1.eclass: Update docs to use python_setup

2020-03-04 Thread Michał Górny
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-r1.eclass
@@ -198,7 +198,7 @@ _python_impl_matches() {
 # This variable is set automatically in the following contexts:
 #
 # python-r1: Set in functions called by python_foreach_impl() or after
-# calling python_export_best().
+# calling python_setup().
 #
 # python-single-r1: Set after calling python-single-r1_pkg_setup().
 #
@@ -217,7 +217,7 @@ _python_impl_matches() {
 # This variable is set automatically in the following contexts:
 #
 # python-r1: Set in functions called by python_foreach_impl() or after
-# calling python_export_best().
+# calling python_setup().
 #
 # python-single-r1: Set after calling python-single-r1_pkg_setup().
 #
-- 
2.25.1




[gentoo-dev] [PATCH 2/9] python-utils-r1.eclass: Mark _python_check_locale_sanity @INTERNAL

2020-03-04 Thread Michał Górny
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,6 +1261,7 @@ python_fix_shebang() {
 
 # @FUNCTION: _python_check_locale_sanity
 # @USAGE: 
+# @INTERNAL
 # @RETURN: 0 if sane, 1 otherwise
 # @DESCRIPTION:
 # Check whether the specified locale sanely maps between lowercase
-- 
2.25.1




[gentoo-dev] [PATCH 4/9] python-r1.eclass: Report impl used by python_setup

2020-03-04 Thread Michał Górny
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() {
fi
 
python_wrapper_setup
+   einfo "Using ${EPYTHON} in global scope"
 }
 
 # @FUNCTION: python_replicate_script
-- 
2.25.1




[gentoo-dev] [PATCH 6/9] python-single-r1.eclass: Report impl used by python_setup

2020-03-04 Thread Michał Górny
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
@@ -467,6 +467,7 @@ python_setup() {
 
python_export "${impls[0]}" EPYTHON PYTHON
python_wrapper_setup
+   einfo "Using ${EPYTHON} to build"
return
fi
 
@@ -484,6 +485,7 @@ python_setup() {
 
python_export "${impl}" EPYTHON PYTHON
python_wrapper_setup
+   einfo "Using ${EPYTHON} to build"
fi
done
 
-- 
2.25.1




[gentoo-dev] [PATCH 7/9] python-utils-r1.eclass: Remove leftover from virtual/pypy*

2020-03-04 Thread Michał Górny
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/eclass/python-utils-r1.eclass
@@ -1085,23 +1085,9 @@ python_is_installed() {
;;
esac
 
-   case "${impl}" in
-   pypy|pypy3)
-   local append=
-   if [[ ${PYTHON_REQ_USE} ]]; then
-   append=[${PYTHON_REQ_USE}]
-   fi
-
-   # be happy with just the interpeter, no need for the 
virtual
-   has_version "${hasv_args[@]}" 
"dev-python/${impl}${append}" \
-   || has_version "${hasv_args[@]}" 
"dev-python/${impl}-bin${append}"
-   ;;
-   *)
-   local PYTHON_PKG_DEP
-   python_export "${impl}" PYTHON_PKG_DEP
-   has_version "${hasv_args[@]}" "${PYTHON_PKG_DEP}"
-   ;;
-   esac
+   local PYTHON_PKG_DEP
+   python_export "${impl}" PYTHON_PKG_DEP
+   has_version "${hasv_args[@]}" "${PYTHON_PKG_DEP}"
 }
 
 # @FUNCTION: python_fix_shebang
-- 
2.25.1




[gentoo-dev] [PATCH 8/9] distutils-r1.eclass: Do not require distutils-r1_python_install_all

2020-03-04 Thread Michał Górny
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 --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 8b7745686d73..abb86996c5d6 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -922,8 +922,6 @@ distutils-r1_python_install_all() {
)
docompress -x "/usr/share/doc/${PF}/examples"
fi
-
-   _DISTUTILS_DEFAULT_CALLED=1
 }
 
 # @FUNCTION: distutils-r1_run_phase
@@ -1154,13 +1152,6 @@ distutils-r1_src_install() {
_distutils-r1_run_common_phase distutils-r1_python_install_all
fi
 
-   if [[ ! ${_DISTUTILS_DEFAULT_CALLED} ]]; then
-   local cmd=die
-   [[ ${EAPI} == [45] ]] && cmd=eqawarn
-
-   "${cmd}" "QA: python_install_all() didn't call 
distutils-r1_python_install_all"
-   fi
-
_distutils-r1_check_namespace_pth
 }
 
-- 
2.25.1




[gentoo-dev] [PATCH 5/9] python-any-r1.eclass: Report impl used by python_setup

2020-03-04 Thread Michał Górny
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,7 @@ python_setup() {
 
python_export "${impls[0]}" EPYTHON PYTHON
python_wrapper_setup
+   einfo "Using ${EPYTHON} to build"
return
fi
 
@@ -309,6 +310,7 @@ python_setup() {
if _python_EPYTHON_supported "${EPYTHON}"; then
python_export EPYTHON PYTHON
python_wrapper_setup
+   einfo "Using ${EPYTHON} to build"
return
fi
fi
@@ -324,6 +326,7 @@ python_setup() {
elif _python_EPYTHON_supported "${i}"; then
python_export "${i}" EPYTHON PYTHON
python_wrapper_setup
+   einfo "Using ${EPYTHON} to build"
return
fi
done
@@ -334,6 +337,7 @@ python_setup() {
python_export "${_PYTHON_SUPPORTED_IMPLS[i]}" EPYTHON PYTHON
if _python_EPYTHON_supported "${EPYTHON}"; then
python_wrapper_setup
+   einfo "Using ${EPYTHON} to build"
return
fi
done
-- 
2.25.1




[gentoo-dev] [PATCH 9/9] distutils-r1.eclass: Make /usr/lib/pypy/share warning fatal

2020-03-04 Thread Michał Górny
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/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index abb86996c5d6..0ee0dc27c345 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -894,9 +894,7 @@ distutils-r1_python_install() {
${shopt_save}
 
if [[ -n ${pypy_dirs} ]]; then
-   local cmd=die
-   [[ ${EAPI} == [45] ]] && cmd=eqawarn
-   "${cmd}" "Package installs 'share' in PyPy prefix, see bug 
#465546."
+   die "Package installs 'share' in PyPy prefix, see bug #465546."
fi
 
if [[ ! ${DISTUTILS_SINGLE_IMPL} ]]; then
-- 
2.25.1




[gentoo-dev] Last rites: dev-go/ed25519

2020-03-04 Thread Marek Szuba
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


[gentoo-dev] Last rites: www-apps/venus

2020-03-04 Thread Michał Górny
# 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
Description: This is a digitally signed message part


[gentoo-dev] News item: Removing ABI_X86_32 support from virtual/opencl

2020-03-04 Thread Marek Szuba
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 from virtual/opencl
Author: Marek Szuba 
Posted: 2020-03-09
Revision: 2
News-Item-Format: 2.0
Display-If-Installed: virtual/opencl

From April 2020 onwards virtual/opencl will no longer provide support
for the 32-bit ABI on either multilib amd64 or native x86 systems. The
reason for this is that most modern OpenCL providers currently available
from Gentoo only support the 64-bit ABI anyway. Therefore, we intend
to initially mask:
 - virtual/opencl in x86 profiles,
 - USE=abi_x86_32 for virtual/opencl in all profiles, and
 - USE=opencl in x86 profiles.
and follow up with removal of multilib support and x86 keywords from
virtual/opencl.

Note that this change will only affect the virtual package, i.e. OpenCL
providers which do support ABI_X86_32 will continue to advertise this
capability. Users of such providers who wish to retain 32-bit OpenCL
support are advised to add virtual/opencl to package.provided; see
portage(5) for details.

-- 
MS



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [PATCH] meson.eclass: Set needs_exe_wrapper in cross file

2020-03-04 Thread Matt Turner
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 machine can run the binaries directly.

This allows dev-libs/wayland to execute the wayland-scanner binary it
builds rather than relying on the system's.

Signed-off-by: Matt Turner 
---
 eclass/meson.eclass | 4 
 1 file changed, 4 insertions(+)

diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index 0588590b31e..16e17dd4a38 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -149,6 +149,9 @@ _meson_create_cross_file() {
# This may require adjustment based on CFLAGS
local cpu=${CHOST%%-*}
 
+   local needs_exe_wrapper=false
+   tc-is-cross-compiler && needs_exe_wrapper=true
+
cat > "${T}/meson.${CHOST}.${ABI}" <<-EOF
[binaries]
ar = $(_meson_env_array "$(tc-getAR)")
@@ -173,6 +176,7 @@ _meson_create_cross_file() {
objc_link_args = $(_meson_env_array "${OBJCFLAGS} ${LDFLAGS}")
objcpp_args = $(_meson_env_array "${OBJCXXFLAGS} ${CPPFLAGS}")
objcpp_link_args = $(_meson_env_array "${OBJCXXFLAGS} ${LDFLAGS}")
+   needs_exe_wrapper = ${needs_exe_wrapper}
 
[host_machine]
system = '${system}'
-- 
2.24.1




Re: [gentoo-dev] [PATCH 0/2] fix support for go modules

2020-03-04 Thread William Hubbs
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-module.eclass changes in the second patch.
> 
> The second patch adds EGO_SUM as a variable to the go-module.eclass.
> This also allows us to create a local goproxy for the modules we
> download.

This is in the tree with some documentation updates.

Now we need to start migrating go-module ebuilds from EGO_VENDOR to
EGO_SUM.

If no one objects I'll work on this over the next few days along with
anyone else who happens to see the ebuilds.

Let me know if there are any questions.

Thanks,

William



signature.asc
Description: Digital signature


Re: [gentoo-dev] [PATCH] meson.eclass: Set needs_exe_wrapper in cross file

2020-03-04 Thread James Le Cuirot
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, we want this set to false to communicate
> to meson that the build machine can run the binaries directly.
> 
> This allows dev-libs/wayland to execute the wayland-scanner binary it
> builds rather than relying on the system's.
> 
> Signed-off-by: Matt Turner 
> ---
>  eclass/meson.eclass | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/eclass/meson.eclass b/eclass/meson.eclass
> index 0588590b31e..16e17dd4a38 100644
> --- a/eclass/meson.eclass
> +++ b/eclass/meson.eclass
> @@ -149,6 +149,9 @@ _meson_create_cross_file() {
>   # This may require adjustment based on CFLAGS
>   local cpu=${CHOST%%-*}
>  
> + local needs_exe_wrapper=false
> + tc-is-cross-compiler && needs_exe_wrapper=true
> +
>   cat > "${T}/meson.${CHOST}.${ABI}" <<-EOF
>   [binaries]
>   ar = $(_meson_env_array "$(tc-getAR)")
> @@ -173,6 +176,7 @@ _meson_create_cross_file() {
>   objc_link_args = $(_meson_env_array "${OBJCFLAGS} ${LDFLAGS}")
>   objcpp_args = $(_meson_env_array "${OBJCXXFLAGS} ${CPPFLAGS}")
>   objcpp_link_args = $(_meson_env_array "${OBJCXXFLAGS} ${LDFLAGS}")
> + needs_exe_wrapper = ${needs_exe_wrapper}
>  
>   [host_machine]
>   system = '${system}'

LGTM!

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpYnYr8e6Y6F.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH v3 2/2] metadata/qa-policy.conf: Include deprecated eclasses

2020-03-04 Thread Michał Górny
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 is
> deprecated, and what you should be doing instead, might be useful

I'm all for it but I think that context should go into eclassdoc or
devmanual in general, and not into increasing CI report size.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part