[gentoo-dev] Last-rites: app-misc/zygrib

[Marc Schiffbauer]

# Marc Schiffbauer  (2022-07-30)
# No update since 2016, compilation and build system
# errors
# Bugs #637150, #686078, #733066, #733068, #828986, #854744
# removal in 30 days (2022-08-29)
app-misc/zygrib


signature.asc
Description: PGP signature

Re: [gentoo-dev] USE=ninja to compile by ninja, otherwise by make

[Fabulous Zhang Zheng]

Sorry for bothering.

Fabulous Zhang Zheng  于2022年7月30日周六 01:31写道：

> Thanks for your reply
>
>  于2022年7月30日周六 01:09写道：
>
>> On Sat, 30 Jul 2022 00:38:54 +0800
>> Fabulous Zhang Zheng  wrote:
>>
>> > Dear everyone,
>> >
>> >
>> > While gentoo-devhelp is a better place for questions, it's been inactive
>> > for years so I sent an email here. Apologies if this is solely for
>> gentoo
>> > developers.
>>
>> There's #gentoo-dev-help
>>
>> >
>> > After trying to read cmake.eclass source code, I think separately
>> denoting
>> > ninja/make in src_compile and src_install might be possible. But
>> > cmake_build still automatically detects the build type so I am confused.
>> >
>>
>> Take a look at CMAKE_MAKEFILE_GENERATOR variable used in cmake.eclass.
>> You want to change this from the default to emake if you want to use
>> make instead of ninja.
>>
>>
>> I noticed this variable before but it must be set before inherit.
> If I try something like:
>
>  if ! use ninja; then
> CMAKE_MAKEFILE_GENERATOR=emake
> fi
> inherit cmake xdg ninja-utils
>
> pkgcheck will say report error:
> external commands disallowed during metadata regen: 'use ninja'
>
> Best regards
>

I asked this question in #gentoo-dev-help.

According to @iamben and @floppy, using the default ninja is best supported,
emake would only be preferred if the package fails with ninja.

And apologies again, for bothering with this list,
I was not aware of the IRC.

Best regards

Re: [gentoo-dev] USE=ninja to compile by ninja, otherwise by make

[Fabulous Zhang Zheng]

Thanks for your reply

 于2022年7月30日周六 01:09写道：

> On Sat, 30 Jul 2022 00:38:54 +0800
> Fabulous Zhang Zheng  wrote:
>
> > Dear everyone,
> >
> >
> > While gentoo-devhelp is a better place for questions, it's been inactive
> > for years so I sent an email here. Apologies if this is solely for gentoo
> > developers.
>
> There's #gentoo-dev-help
>
> >
> > After trying to read cmake.eclass source code, I think separately
> denoting
> > ninja/make in src_compile and src_install might be possible. But
> > cmake_build still automatically detects the build type so I am confused.
> >
>
> Take a look at CMAKE_MAKEFILE_GENERATOR variable used in cmake.eclass.
> You want to change this from the default to emake if you want to use
> make instead of ninja.
>
>
> I noticed this variable before but it must be set before inherit.
If I try something like:

 if ! use ninja; then
CMAKE_MAKEFILE_GENERATOR=emake
fi
inherit cmake xdg ninja-utils

pkgcheck will say report error:
external commands disallowed during metadata regen: 'use ninja'

Best regards

Re: [gentoo-dev] USE=ninja to compile by ninja, otherwise by make

[waebbl-gentoo]

On Sat, 30 Jul 2022 00:38:54 +0800
Fabulous Zhang Zheng  wrote:

> Dear everyone,
> 
> 
> While gentoo-devhelp is a better place for questions, it's been inactive
> for years so I sent an email here. Apologies if this is solely for gentoo
> developers.

There's #gentoo-dev-help

> 
> After trying to read cmake.eclass source code, I think separately denoting
> ninja/make in src_compile and src_install might be possible. But
> cmake_build still automatically detects the build type so I am confused.
> 

Take a look at CMAKE_MAKEFILE_GENERATOR variable used in cmake.eclass.
You want to change this from the default to emake if you want to use
make instead of ninja.

[gentoo-dev] USE=ninja to compile by ninja, otherwise by make

[Fabulous Zhang Zheng]

Dear everyone,


While gentoo-devhelp is a better place for questions, it's been inactive
for years so I sent an email here. Apologies if this is solely for gentoo
developers.

I'm writing an ebuild of ddnet,  a cmake
argument of which is "-GNinja" controlling the build system to be ninja or
make.  Naturally I decided to add a USE flag "ninja"

Part of my src_configure function is as below:

local mycmakeargs=(
..
-DVULKAN=$(usex vulkan ON OFF)
)
use ninja && mycmakeargs+=( -GNinja )
cmake_src_configure

What confuses me is that portage seems to always use ninja to build, for
htop always indicates user portage is running ( ninja -v -j5 ), whenever
USE=ninja is enabled or disabled.

After trying to read cmake.eclass source code, I think separately denoting
ninja/make in src_compile and src_install might be possible. But
cmake_build still automatically detects the build type so I am confused.

My drafted ebuild file is attached below. It will be much appreciated if
anyone could help  :)


Best regards.


ddnet-16.2.2.ebuild
Description: Binary data

Re: [gentoo-dev] [PATCH 09/11] net-wireless/blueman: Invoke eautomake to fix py-compile script

[Ulrich Mueller]

> On Fri, 29 Jul 2022, Michał Górny wrote:

> --- a/net-wireless/blueman/blueman-2.3.1.ebuild
> +++ b/net-wireless/blueman/blueman-2.3.1.ebuild
> @@ -97,7 +97,7 @@ pkg_setup() {
>  }
>  
>  src_prepare() {
> - [[ ${PV} ==  ]] && eautoreconf
> + [[ ${PV} ==  ]] && eautoreconf || eautomake

So if eautoreconf returns with nonzero status, eautomake will be called?
Or does eautoreconf always return zero (I believe it does)?

However, I don't want to think about that when reading the code, so
could you make it an if-then-else statement instead?

Same for the live ebuild.

Ulrich


signature.asc
Description: PGP signature

Re: [gentoo-dev] Up for grabs: dev-python/pyside2

[waebbl-gentoo]

On Fri, 29 Jul 2022 07:06:06 -0400
Ionen Wolkens  wrote:

> On Fri, Jul 29, 2022 at 10:30:20AM +, waebbl-gen...@posteo.net wrote:
> > On Sun, 17 Jul 2022 23:11:08 +0100
> > Sam James  wrote:
> >   
> > > Up for grabs because of inactivity.
> > > 
> > > dev-python/pyside2 has several open bugs and a version bump pending.
> > > 
> > > Needs some real love to tidy it up.
> > > 
> > > Best,
> > > sam  
> > 
> > Wouldn't it be applicable to put these packages under the umbrella of
> > the Gentoo Qt project?  
> 
> It still need someone to maintain it either way, qt@ is rather small
> and Qt6 is likely to use up people's time already. Being m-n at least
> make its current state clear (up to qt@ though).
> 

I can think of co-maintaining the packages, but it exceeds my resources
to being primary maintainer.

> > They're developed, published and hosted by the The Qt Company (in
> > contrast for example to PyQt5 or QtPy) and are only python
> > bindings for the Qt framework, although they're currently distributed
> > in a separate tarball and not with the Qt tarball.  
> 
> On a side-note I'll be adding PyQt6 to the tree once I can[1], but I
> don't use pyside for anything and probably won't be looking at pyside6.
> 

I'm slowly working towards shiboken6 / pyside6. Pyside is needed for
the Qt6 move of FreeCAD, at it's current state at least.
There are discussion on completely moving to pybind11 instead of
pyside, but that's not yet decided. So I will probably need pyside6 for
the sake of FreeCAD.


> [1] https://github.com/gentoo/gentoo/pull/26504



pgpAfI8Ibfe_d.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Up for grabs: dev-python/pyside2

[Ionen Wolkens]

On Fri, Jul 29, 2022 at 10:30:20AM +, waebbl-gen...@posteo.net wrote:
> On Sun, 17 Jul 2022 23:11:08 +0100
> Sam James  wrote:
> 
> > Up for grabs because of inactivity.
> > 
> > dev-python/pyside2 has several open bugs and a version bump pending.
> > 
> > Needs some real love to tidy it up.
> > 
> > Best,
> > sam
> 
> Wouldn't it be applicable to put these packages under the umbrella of
> the Gentoo Qt project?

It still need someone to maintain it either way, qt@ is rather small
and Qt6 is likely to use up people's time already. Being m-n at least
make its current state clear (up to qt@ though).

> They're developed, published and hosted by the The Qt Company (in
> contrast for example to PyQt5 or QtPy) and are only python
> bindings for the Qt framework, although they're currently distributed
> in a separate tarball and not with the Qt tarball.

On a side-note I'll be adding PyQt6 to the tree once I can[1], but I
don't use pyside for anything and probably won't be looking at pyside6.

[1] https://github.com/gentoo/gentoo/pull/26504
-- 
ionen


signature.asc
Description: PGP signature

[gentoo-dev] [PATCH 11/11] python-utils-r1.eclass: Sterilize pytest-sugar plugin

[Michał Górny]

Signed-off-by: Michał Górny 
---
 eclass/python-utils-r1.eclass | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index b793a1f13e0f..89013591c31b 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -1331,6 +1331,9 @@ epytest() {
# sterilize pytest-markdown as it runs code snippets from all
# *.md files found without any warning
-p no:markdown
+   # pytest-sugar undoes everything that's good about pytest output
+   # and makes it hard to read logs
+   -p no:sugar
)
local x
for x in "${EPYTEST_DESELECT[@]}"; do
-- 
2.35.1

[gentoo-dev] [PATCH 10/11] dev-python/pygobject: Call python_optimize explicitly

[Michał Górny]

Signed-off-by: Michał Górny 
---
 dev-python/pygobject/pygobject-3.42.2.ebuild | 1 +
 1 file changed, 1 insertion(+)

diff --git a/dev-python/pygobject/pygobject-3.42.2.ebuild 
b/dev-python/pygobject/pygobject-3.42.2.ebuild
index 217ae21f2c4a..d411290d7520 100644
--- a/dev-python/pygobject/pygobject-3.42.2.ebuild
+++ b/dev-python/pygobject/pygobject-3.42.2.ebuild
@@ -65,6 +65,7 @@ python_test() {
 
 python_install() {
meson_src_install
+   python_optimize
 }
 
 python_install_all() {
-- 
2.35.1

[gentoo-dev] [PATCH 09/11] net-wireless/blueman: Invoke eautomake to fix py-compile script

[Michał Górny]

Signed-off-by: Michał Górny 
---
 net-wireless/blueman/blueman-2.3.1.ebuild | 2 +-
 net-wireless/blueman/blueman-.ebuild  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/net-wireless/blueman/blueman-2.3.1.ebuild 
b/net-wireless/blueman/blueman-2.3.1.ebuild
index dbedcfc7eae6..997963609ec2 100644
--- a/net-wireless/blueman/blueman-2.3.1.ebuild
+++ b/net-wireless/blueman/blueman-2.3.1.ebuild
@@ -97,7 +97,7 @@ pkg_setup() {
 }
 
 src_prepare() {
-   [[ ${PV} ==  ]] && eautoreconf
+   [[ ${PV} ==  ]] && eautoreconf || eautomake
distutils-r1_src_prepare
 }
 
diff --git a/net-wireless/blueman/blueman-.ebuild 
b/net-wireless/blueman/blueman-.ebuild
index dbedcfc7eae6..997963609ec2 100644
--- a/net-wireless/blueman/blueman-.ebuild
+++ b/net-wireless/blueman/blueman-.ebuild
@@ -97,7 +97,7 @@ pkg_setup() {
 }
 
 src_prepare() {
-   [[ ${PV} ==  ]] && eautoreconf
+   [[ ${PV} ==  ]] && eautoreconf || eautomake
distutils-r1_src_prepare
 }
 
-- 
2.35.1

[gentoo-dev] [PATCH 08/11] dev-python/tomli: Call python_optimize explicitly

[Michał Górny]

Signed-off-by: Michał Górny 
---
 dev-python/tomli/tomli-2.0.1-r1.ebuild | 5 +
 1 file changed, 5 insertions(+)

diff --git a/dev-python/tomli/tomli-2.0.1-r1.ebuild 
b/dev-python/tomli/tomli-2.0.1-r1.ebuild
index f24193c0c9fe..4a4c0bc1ea17 100644
--- a/dev-python/tomli/tomli-2.0.1-r1.ebuild
+++ b/dev-python/tomli/tomli-2.0.1-r1.ebuild
@@ -34,3 +34,8 @@ distutils_enable_tests unittest
 python_compile() {
python_domodule src/tomli "${WORKDIR}"/*.dist-info
 }
+
+python_install() {
+   distutils-r1_python_install
+   python_optimize
+}
-- 
2.35.1

[gentoo-dev] [PATCH 07/11] dev-python/installer: Call python_optimize explicitly

[Michał Górny]

Signed-off-by: Michał Górny 
---
 dev-python/installer/installer-0.5.1-r1.ebuild | 5 +
 1 file changed, 5 insertions(+)

diff --git a/dev-python/installer/installer-0.5.1-r1.ebuild 
b/dev-python/installer/installer-0.5.1-r1.ebuild
index a29b236242ca..39b7336c9b89 100644
--- a/dev-python/installer/installer-0.5.1-r1.ebuild
+++ b/dev-python/installer/installer-0.5.1-r1.ebuild
@@ -35,3 +35,8 @@ distutils_enable_tests pytest
 python_compile() {
python_domodule src/installer "${WORKDIR}"/*.dist-info
 }
+
+python_install() {
+   distutils-r1_python_install
+   python_optimize
+}
-- 
2.35.1

[gentoo-dev] [PATCH 06/11] distutils-r1.eclass: Let gpep517 compile bytecode when 9+ is used

[Michał Górny]

Use the new --optimize option of gpep517 >= 9 when it is installed,
and remove the python_optimize call then.  This conditional logic is
meant to give some additional testing while gpep517-9 is still in ~arch.

Note that this also removes python_optimize call for "no" mode.
However, this mode is used only by a handful of ebuilds, so if any of
them needs an explicit python_optimize call, we can quickly fix them.

Signed-off-by: Michał Górny 
---
 eclass/distutils-r1.eclass | 36 ++--
 1 file changed, 26 insertions(+), 10 deletions(-)

diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 495eead1d5fd..60f81473c0a6 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -1270,13 +1270,25 @@ distutils_wheel_install() {
local wheel=${2}
 
einfo "  Installing ${wheel##*/} to ${root}"
-   local cmd=(
-   gpep517 install-wheel
-   --destdir="${root}"
-   --interpreter="${PYTHON}"
-   --prefix="${EPREFIX}/usr"
-   "${wheel}"
-   )
+   if has_version -b ">=dev-python/gpep517-9"; then
+   # TODO: inline when we dep on >=9
+   local cmd=(
+   gpep517 install-wheel
+   --destdir="${root}"
+   --interpreter="${PYTHON}"
+   --prefix="${EPREFIX}/usr"
+   --optimize=all
+   "${wheel}"
+   )
+   else
+   local cmd=(
+   gpep517 install-wheel
+   --destdir="${root}"
+   --interpreter="${PYTHON}"
+   --prefix="${EPREFIX}/usr"
+   "${wheel}"
+   )
+   fi
printf '%s\n' "${cmd[*]}"
"${cmd[@]}" || die "Wheel install failed"
 
@@ -1994,9 +2006,13 @@ _distutils-r1_post_python_install() {
done
 
if [[ ${DISTUTILS_USE_PEP517} ]]; then
-   # we need to recompile everything here in order to embed
-   # the correct paths
-   python_optimize "${sitedir}"
+   if ! has_version -b ">=dev-python/gpep517-9"
+   then
+   # TODO: remove when we dep on >=9
+   # we need to recompile everything here in order 
to embed
+   # the correct paths
+   python_optimize "${sitedir}"
+   fi
fi
fi
 }
-- 
2.35.1

[gentoo-dev] [PATCH 05/11] distutils-r1.eclass: Pass EPREFIX to addpredict

[Michał Górny]

Pointed out by Arfrever.

Signed-off-by: Michał Górny 
---
 eclass/distutils-r1.eclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index e4ef1919bc7d..495eead1d5fd 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -1647,8 +1647,8 @@ distutils-r1_python_install() {
# python likes to compile any module it sees, which triggers 
sandbox
# failures if some packages haven't compiled their modules yet.
addpredict "${EPREFIX}/usr/lib/${EPYTHON}"
-   addpredict /usr/lib/pypy3.9
-   addpredict /usr/local # bug 498232
+   addpredict "${EPREFIX}/usr/lib/pypy3.9"
+   addpredict "${EPREFIX}/usr/local" # bug 498232
 
if [[ ! ${DISTUTILS_SINGLE_IMPL} ]]; then
merge_root=1
-- 
2.35.1

[gentoo-dev] [PATCH 04/11] distutils-r1.eclass: Bump dev-python/sip dependency

[Michał Górny]

Bug: https://bugs.gentoo.org/851840
Signed-off-by: Michał Górny 
---
 eclass/distutils-r1.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 85a5c8496d49..e4ef1919bc7d 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -265,7 +265,7 @@ _distutils_set_globals() {
;;
sip)
bdep+='
-   >=dev-python/sip-6.6.1[${PYTHON_USEDEP}]
+   >=dev-python/sip-6.6.2[${PYTHON_USEDEP}]
'
;;
standalone)
-- 
2.35.1

[gentoo-dev] [PATCH 03/11] install-qa-check.d: Rewrite 60python-pyc to use gpep517

[Michał Górny]

Signed-off-by: Michał Górny 
---
 metadata/install-qa-check.d/60python-pyc | 168 +--
 1 file changed, 96 insertions(+), 72 deletions(-)

diff --git a/metadata/install-qa-check.d/60python-pyc 
b/metadata/install-qa-check.d/60python-pyc
index 47e9a3eea908..fd9434994f2f 100644
--- a/metadata/install-qa-check.d/60python-pyc
+++ b/metadata/install-qa-check.d/60python-pyc
@@ -4,86 +4,110 @@
 # QA check: ensure that Python modules are compiled after installing
 # Maintainer: Python project 
 
-# EAPI guard to prevent errors from trying to import python-utils-r1
-# in unsupported EAPIs.  Please keep the list in sync with the eclass!
-if [[ ${EAPI} == [6-8] ]]; then
-   inherit python-utils-r1
+python_pyc_check() {
+   local save=$(shopt -p nullglob)
+   shopt -s nullglob
+   local progs=( "${EPREFIX}"/usr/lib/python-exec/*/gpep517 )
+   ${save}
 
-   python_pyc_check() {
-   local impl missing=() outdated=()
-   for impl in "${_PYTHON_SUPPORTED_IMPLS[@]}"; do
-   _python_export "${impl}" EPYTHON PYTHON
-   [[ -x ${PYTHON} ]] || continue
-   local sitedir=$(python_get_sitedir "${impl}")
+   local invalid=()
+   local mismatched_timestamp=()
+   local mismatched_data=()
+   local missing=()
+   local stray=()
 
-   if [[ -d ${D}${sitedir} ]]; then
-   local suffixes=() subdir=
-   case ${EPYTHON} in
-   python2*)
-   suffixes=( .py{c,o} )
-   ;;
-   pypy)
-   suffixes=( .pyc )
-   ;;
-   python3*|pypy3*)
-   local tag=$("${PYTHON}" -c 
'import sys; print(sys.implementation.cache_tag)')
-   suffixes=( 
".${tag}"{,.opt-{1,2}}.pyc )
-   subdir=__pycache__/
-   ;;
-   *)
-   # skip testing unknown impl
-   continue
-   ;;
-   esac
+   for prog in "${progs[@]}"; do
+   local impl=${prog%/*}
+   impl=${impl##*/}
+   einfo "Verifying compiled files for ${impl}"
+   local kind pyc py
+   while IFS=: read -r kind pyc py extra; do
+   case ${kind} in
+   invalid)
+   invalid+=( "${pyc}" )
+   ;;
+   mismatched)
+   case ${extra} in
+   timestamp)
+   mismatched_timestamp+=( 
"${pyc}" )
+   ;;
+   *)
+   mismatched_data+=( 
"${pyc}" )
+   ;;
+   esac
+   ;;
+   missing)
+   missing+=( "${pyc}" )
+   ;;
+   older)
+   # older warnings were produced by 
earlier version
+   # of gpep517 but the check was 
incorrect, so we just
+   # ignore them
+   ;;
+   stray)
+   stray+=( "${pyc}" )
+   ;;
+   esac
+   done < <("${prog}" verify-pyc --destdir "${D}" --prefix 
"${EPREFIX}"/usr)
+   done
 
-   einfo "Verifying compiled files in ${sitedir}"
-   local f s
-   while read -d $'\0' -r f; do
-   local dir=${f%/*}
-   local basename=${f##*/}
-   basename=${basename%.py}
+   local found=
+   if [[ ${missing[@]} ]]; then
+   eqawarn
+   eqawarn "QA Notice: This package installs one or more Python 
modules that are"
+   eqawarn "not byte-compiled."
+   eqawarn "The following files are missing:"
+   eqawarn
+  

[gentoo-dev] [PATCH 02/11] distutils-r1.eclass: Require gpep517 >= 8

[Michał Górny]

Signed-off-by: Michał Górny 
---
 eclass/distutils-r1.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 9909ba70178c..85a5c8496d49 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -205,7 +205,7 @@ _distutils_set_globals() {
fi
 
bdep='
-   >=dev-python/gpep517-6[${PYTHON_USEDEP}]
+   >=dev-python/gpep517-8[${PYTHON_USEDEP}]
'
case ${DISTUTILS_USE_PEP517} in
flit)
-- 
2.35.1

[gentoo-dev] [PATCH 01/11] distutils-r1.eclass: Update pyproject.toml advice for PEP517 mode

[Michał Górny]

Signed-off-by: Michał Górny 
---
 eclass/distutils-r1.eclass | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index e64eedec5fd3..9909ba70178c 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -884,10 +884,10 @@ _distutils-r1_handle_pyproject_toml() {
 
if [[ ! -f setup.py && -f pyproject.toml ]]; then
if [[ ${DISTUTILS_USE_SETUPTOOLS} != pyproject.toml ]]; then
-   eerror "No setup.py found but pyproject.toml is 
present.  In order to enable"
-   eerror "pyproject.toml support in distutils-r1, set:"
-   eerror "  DISTUTILS_USE_SETUPTOOLS=pyproject.toml"
-   die "No setup.py found and 
DISTUTILS_USE_SETUPTOOLS!=pyproject.toml"
+   eerror "No setup.py found but pyproject.toml is 
present.  Please migrate"
+   eerror "the package to use DISTUTILS_USE_PEP517. See:"
+   eerror "  
https://projects.gentoo.org/python/guide/distutils.html;
+   die "No setup.py found and PEP517 mode not enabled"
fi
fi
 }
-- 
2.35.1

[gentoo-dev] [PATCH 00/11] distutils-r1.eclass: Support for gpep517-9+ --optimize + minor changes

[Michał Górny]

Hi,

Here's another medium-sized patchset for Python eclasses.  The primary
feature is support for the new gpep517 9+ option to byte-compile
installed .pyc files.  As a result, rather than delaying until
python_install(), we get optimized .pyc already in python_compile()
and the test phase should be faster.

This implies a minor change to DISTUTILS_USE_PEP517=no behavior -- we're
no longer calling python_optimize implicitly, so if the ebuild does not
compile bytecode, it needs to call python_optimize explicitly now.
This mode is used only by a few ebuilds right now, so I'm including
updates to them as well.  On the plus side, it now avoids compiling .py
files twice in the remaining ebuilds.

The other major change included is rewriting the .pyc install-qa-check.d
to use the new "gpep517 verify-pyc" command rather than implementing
the checks in bash.  Since gpep517 is a dep of all ebuilds inheriting
distutils-r1, this should be a relatively safe place to put
the functionality, and so the check should work reliably in most
of the environments.  This also includes more correct checking of
whether .pyc files are up-to-date that couldn't be done in bash because
it impacted performance *a lot*.

The other changes include a fix for obsolete pyproject.toml
recommendation, the usual build system minimal version updates,
disabling pytest-sugar plugin in epytest (that makes test output awful)
and fixing EPREFIX in addpredict invocations.


Michał Górny (11):
  distutils-r1.eclass: Update pyproject.toml advice for PEP517 mode
  distutils-r1.eclass: Require gpep517 >= 8
  install-qa-check.d: Rewrite 60python-pyc to use gpep517
  distutils-r1.eclass: Bump dev-python/sip dependency
  distutils-r1.eclass: Pass EPREFIX to addpredict
  distutils-r1.eclass: Let gpep517 compile bytecode when 9+ is used
  dev-python/installer: Call python_optimize explicitly
  dev-python/tomli: Call python_optimize explicitly
  net-wireless/blueman: Invoke eautomake to fix py-compile script
  dev-python/pygobject: Call python_optimize explicitly
  python-utils-r1.eclass: Sterilize pytest-sugar plugin

 .../installer/installer-0.5.1-r1.ebuild   |   5 +
 dev-python/pygobject/pygobject-3.42.2.ebuild  |   1 +
 dev-python/tomli/tomli-2.0.1-r1.ebuild|   5 +
 eclass/distutils-r1.eclass|  52 --
 eclass/python-utils-r1.eclass |   3 +
 metadata/install-qa-check.d/60python-pyc  | 168 ++
 net-wireless/blueman/blueman-2.3.1.ebuild |   2 +-
 net-wireless/blueman/blueman-.ebuild  |   2 +-
 8 files changed, 146 insertions(+), 92 deletions(-)

-- 
2.35.1

Re: [gentoo-dev] Up for grabs: dev-python/pyside2

[waebbl-gentoo]

On Sun, 17 Jul 2022 23:11:08 +0100
Sam James  wrote:

> Up for grabs because of inactivity.
> 
> dev-python/pyside2 has several open bugs and a version bump pending.
> 
> Needs some real love to tidy it up.
> 
> Best,
> sam

Wouldn't it be applicable to put these packages under the umbrella of
the Gentoo Qt project?
They're developed, published and hosted by the The Qt Company (in
contrast for example to PyQt5 or QtPy) and are only python
bindings for the Qt framework, although they're currently distributed
in a separate tarball and not with the Qt tarball.

Resending due to wrong sender being used.


Regards,
Bernd


pgpN6407DJvvo.pgp
Description: OpenPGP digital signature

[gentoo-dev] [PATCH] java-pkg-simple.eclass: do not java-pkg_gen-cp if USE=binary

[Volkmar W. Pogatzki]

Closes: https://bugs.gentoo.org/861026
Signed-off-by: Volkmar W. Pogatzki 
---
 eclass/java-pkg-simple.eclass | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/eclass/java-pkg-simple.eclass b/eclass/java-pkg-simple.eclass
index 09062d9ede6..6f7324240e3 100644
--- a/eclass/java-pkg-simple.eclass
+++ b/eclass/java-pkg-simple.eclass
@@ -344,9 +344,6 @@ java-pkg-simple_prepend_resources() {
 java-pkg-simple_src_compile() {
local sources=sources.lst classes=target/classes apidoc=target/api 
moduleinfo
 
-   # auto generate classpath
-   java-pkg_gen-cp JAVA_GENTOO_CLASSPATH
-
# do not compile if we decide to install binary jar
if has binary ${JAVA_PKG_IUSE} && use binary; then
# register the runtime dependencies
@@ -357,6 +354,9 @@ java-pkg-simple_src_compile() {
cp "${DISTDIR}"/${JAVA_BINJAR_FILENAME} ${JAVA_JAR_FILENAME}\
|| die "Could not copy the binary jar file to ${S}"
return 0
+   else
+   # auto generate classpath
+   java-pkg_gen-cp JAVA_GENTOO_CLASSPATH
fi
 
# gather sources
-- 
2.35.1