[gentoo-dev] [PATCH] dev-python/booleanOperations: add proper dependency

2020-03-13 Thread Jason A. Donenfeld
Otherwise we incur breakage.

Closes: https://bugs.gentoo.org/712212
Package-Manager: Portage-2.3.93, Repoman-2.3.20
Signed-off-by: Jason A. Donenfeld 
---
Not my package, so emailing to you/the list to apply it. Python people
are usually kind of touchy about non-maintainers twiddling around.

 dev-python/booleanOperations/booleanOperations-0.9.0.ebuild | 1 +
 1 file changed, 1 insertion(+)

diff --git a/dev-python/booleanOperations/booleanOperations-0.9.0.ebuild 
b/dev-python/booleanOperations/booleanOperations-0.9.0.ebuild
index 0468e6dc92f..8d822fcc410 100644
--- a/dev-python/booleanOperations/booleanOperations-0.9.0.ebuild
+++ b/dev-python/booleanOperations/booleanOperations-0.9.0.ebuild
@@ -20,6 +20,7 @@ BDEPEND=""
 RDEPEND="${DEPEND}
>=dev-python/fonttools-4.0.2[${PYTHON_USEDEP}]
>=dev-python/pyclipper-1.1.0[${PYTHON_USEDEP}]
+   dev-python/wheel[${PYTHON_USEDEP}]
 "
 
 src_prepare() {
-- 
2.25.1




Re: [gentoo-dev] [PATCH] autotools.eclass: reorder sysroot M4 include dir option

2020-03-13 Thread James Le Cuirot
On Fri, 13 Mar 2020 14:23:48 -0400
David Michael  wrote:

> The old autoconf-2.13 version requires options to be specified
> before the file name argument, so packages with WANT_AUTOCONF="2.1"
> would fail to build in a sysroot with the -l option at the end.
> 
> Closes: https://bugs.gentoo.org/710792
> Signed-off-by: David Michael 
> ---
>  eclass/autotools.eclass | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/eclass/autotools.eclass b/eclass/autotools.eclass
> index 9df0e1b9366..625abd0e9d1 100644
> --- a/eclass/autotools.eclass
> +++ b/eclass/autotools.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: autotools.eclass
> @@ -512,7 +512,7 @@ autotools_run_tool() {
>   fi
>  
>   if ${m4flags} ; then
> - set -- "${1}" $(autotools_m4dir_include) "${@:2}" 
> $(autotools_m4sysdir_include)
> + set -- "${1}" $(autotools_m4dir_include) 
> $(autotools_m4sysdir_include) "${@:2}"
>   fi
>  
>   # If the caller wants to probe something, then let them do it directly.

NACK. Please see https://bugs.gentoo.org/710792#c4.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpTx6ZOTI21P.pgp
Description: OpenPGP digital signature


[gentoo-dev] [PATCH v2] fcaps.eclass: use BDEPEND for EAPI 7

2020-03-13 Thread David Michael
The eclass installs libcap to execute the setcap program, so it
must be installed in /.  Optional libcap linking is handled by the
USE=caps flag, which is unrelated to this eclass, so the DEPEND
declaration is not needed on EAPI 7.

Closes: https://bugs.gentoo.org/700018
Signed-off-by: David Michael 
---

Changes since v1:
  * Inverted patterns so EAPI 7+ is the default.

 eclass/fcaps.eclass | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/eclass/fcaps.eclass b/eclass/fcaps.eclass
index 467f955f5e9..2b6e5be4683 100644
--- a/eclass/fcaps.eclass
+++ b/eclass/fcaps.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2015 Gentoo Foundation
+# Copyright 1999-2020 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: fcaps.eclass
@@ -34,7 +34,10 @@ _FCAPS_ECLASS=1
 IUSE="+filecaps"
 
 # We can't use libcap-ng atm due to #471414.
-DEPEND="filecaps? ( sys-libs/libcap )"
+case "${EAPI:-0}" in
+   [0-6]) DEPEND="filecaps? ( sys-libs/libcap )" ;;
+   *) BDEPEND="filecaps? ( sys-libs/libcap )" ;;
+esac
 
 # @ECLASS-VARIABLE: FILECAPS
 # @DEFAULT_UNSET
-- 
2.21.1




Re: [gentoo-dev] [PATCH] fcaps.eclass: use BDEPEND for EAPI 7

2020-03-13 Thread Mike Gilbert
On Fri, Mar 13, 2020 at 2:23 PM David Michael  wrote:
>
> The eclass installs libcap to execute the setcap program, so it
> must be installed in /.  Optional libcap linking is handled by the
> USE=caps flag, which is unrelated to this eclass, so the DEPEND
> declaration is not needed on EAPI 7.
>
> Closes: https://bugs.gentoo.org/700018
> Signed-off-by: David Michael 
> ---
>  eclass/fcaps.eclass | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/eclass/fcaps.eclass b/eclass/fcaps.eclass
> index 467f955f5e9..b0479f32456 100644
> --- a/eclass/fcaps.eclass
> +++ b/eclass/fcaps.eclass
> @@ -1,4 +1,4 @@
> -# Copyright 1999-2015 Gentoo Foundation
> +# Copyright 1999-2020 Gentoo Authors
>  # Distributed under the terms of the GNU General Public License v2
>
>  # @ECLASS: fcaps.eclass
> @@ -34,7 +34,10 @@ _FCAPS_ECLASS=1
>  IUSE="+filecaps"
>
>  # We can't use libcap-ng atm due to #471414.
> -DEPEND="filecaps? ( sys-libs/libcap )"
> +case "${EAPI:-0}" in
> +   7) BDEPEND="filecaps? ( sys-libs/libcap )" ;;
> +   *) DEPEND="filecaps? ( sys-libs/libcap )" ;;
> +esac

Please reverse the logic: if EAPI is in 0-6, set DEPEND, otherwise set
BDEPEND. Assuming future EAPIs support BDEPEND, this will future-proof
the eclass somewhat.



Re: [gentoo-dev] rfc: reply-to munging

2020-03-13 Thread Robin H. Johnson
On Fri, Mar 13, 2020 at 08:53:39AM -0500, William Hubbs wrote:
> On Thu, Mar 12, 2020 at 09:09:39PM +0100, Andreas K. Huettel wrote:
> > Am Donnerstag, 12. März 2020, 20:23:56 CET schrieb Michał Górny:
> > > I suppose that a part of the problem is the default Reply-To in these
> > > mails.
>  
> Yes, I agree that this is a problem.
> 
> > Which was deliberately added...
> 
> Why was this added? I have asked before and never gotten an answer.

TL;DR specifically because gentoo-commits can only be emailed by the
bots, and not everybody is on the other list anyway.

infra/cfengine.git:
commit 2d1156486f8f09ed4747a61d194928b05fdc974f
Date:   Fri Feb 4 01:51:31 2011 +

It sets the Reply-To to be gentoo-dev@lists.g.o AND the change
committer, on the basis that:
- developers are NOT required to subscribe to gentoo-dev@ (that's why
  gentoo-dev-announce@ exists, which is mandatory).
- Not every committer is a developer: the script is used for many repos,
  not just repo/gentoo.git

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136


signature.asc
Description: PGP signature


[gentoo-dev] [PATCH] autotools.eclass: reorder sysroot M4 include dir option

2020-03-13 Thread David Michael
The old autoconf-2.13 version requires options to be specified
before the file name argument, so packages with WANT_AUTOCONF="2.1"
would fail to build in a sysroot with the -l option at the end.

Closes: https://bugs.gentoo.org/710792
Signed-off-by: David Michael 
---
 eclass/autotools.eclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/eclass/autotools.eclass b/eclass/autotools.eclass
index 9df0e1b9366..625abd0e9d1 100644
--- a/eclass/autotools.eclass
+++ b/eclass/autotools.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: autotools.eclass
@@ -512,7 +512,7 @@ autotools_run_tool() {
fi
 
if ${m4flags} ; then
-   set -- "${1}" $(autotools_m4dir_include) "${@:2}" 
$(autotools_m4sysdir_include)
+   set -- "${1}" $(autotools_m4dir_include) 
$(autotools_m4sysdir_include) "${@:2}"
fi
 
# If the caller wants to probe something, then let them do it directly.
-- 
2.21.1




[gentoo-dev] [PATCH] fcaps.eclass: use BDEPEND for EAPI 7

2020-03-13 Thread David Michael
The eclass installs libcap to execute the setcap program, so it
must be installed in /.  Optional libcap linking is handled by the
USE=caps flag, which is unrelated to this eclass, so the DEPEND
declaration is not needed on EAPI 7.

Closes: https://bugs.gentoo.org/700018
Signed-off-by: David Michael 
---
 eclass/fcaps.eclass | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/eclass/fcaps.eclass b/eclass/fcaps.eclass
index 467f955f5e9..b0479f32456 100644
--- a/eclass/fcaps.eclass
+++ b/eclass/fcaps.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2015 Gentoo Foundation
+# Copyright 1999-2020 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: fcaps.eclass
@@ -34,7 +34,10 @@ _FCAPS_ECLASS=1
 IUSE="+filecaps"
 
 # We can't use libcap-ng atm due to #471414.
-DEPEND="filecaps? ( sys-libs/libcap )"
+case "${EAPI:-0}" in
+   7) BDEPEND="filecaps? ( sys-libs/libcap )" ;;
+   *) DEPEND="filecaps? ( sys-libs/libcap )" ;;
+esac
 
 # @ECLASS-VARIABLE: FILECAPS
 # @DEFAULT_UNSET
-- 
2.21.1




[gentoo-dev] Last rites: dev-python/cliff-tablib

2020-03-13 Thread Matthew Thode
# Matthew Thode  (2020-03-13)
# masked for removal in 14 days. Bug #712310
dev-python/cliff-tablib

https://bugs.gentoo.org/712310

-- 
Matthew Thode (prometheanfire)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Fwd: [gentoo-commits] repo/gentoo:master commit in: app-office/calcurse/

2020-03-13 Thread Rich Freeman
On Fri, Mar 13, 2020 at 1:29 AM Chí-Thanh Christopher Nguyễn
 wrote:
>
> Alec Warner schrieb:
> > On Thu, Mar 12, 2020 at 9:54 AM Andreas K. Huettel  > > wrote:
> >
> > Someone needs to grow up here.
> >
> >
> > Meh, to me (someone who can't commit to ::gentoo) I have a few concerns 
> > here.
> > First, I don't see a lot of QA reverts on the gentoo-dev list. Is it common
> > practice to post reverts publicly? Second, I'm not aware that we would 
> > revert
> > for things like this. Most of the items you mention look fairly minor (maybe
> > the python comment looks impactful?) Why can't we fix these items in a 
> > future
> > commit, rather than revert? What did Patrice's commit break?
>
> If the issues are so serious that we have to prevent any breakage/regressions
> from reaching users, I guess an alternative response would have been to
> p.mask the offending new ebuild. Unless the commit caused some tree-wide
> breakage which I can't see here however.

Don't really want to comment on where the line should have been drawn
on this particular case, but the idea of reverting commits doesn't
seem particularly abhorrent, and certainly commits that don't create a
new ebuild couldn't be addressed with masking unless we want to impact
end users.

It seems like the drama here is mostly about how this ended up on the
lists vs just being a discussion between QA and the committer/etc.
Reading between the lines I'm not sure if it was ever intended to be
on the list at least initially.

If this was intended for public consumption it probably wouldn't hurt
to note why (hey, we're singling out this commit because it has this
error we've been seeing a lot of lately and you can see how this sort
of thing could sneak in...).  Otherwise it just seems like it causes
drama without actually achieving the desired impact.

-- 
Rich



[gentoo-dev] rfc: reply-to munging

2020-03-13 Thread William Hubbs
On Thu, Mar 12, 2020 at 09:09:39PM +0100, Andreas K. Huettel wrote:
> Am Donnerstag, 12. März 2020, 20:23:56 CET schrieb Michał Górny:
> > I suppose that a part of the problem is the default Reply-To in these
> > mails.
 
Yes, I agree that this is a problem.

> Which was deliberately added...

Why was this added? I have asked before and never gotten an answer.

Thanks,

William


signature.asc
Description: Digital signature


[gentoo-dev] Re: [PATCH 0/4] elt-patches: support wrapped Win32 MSVC toolchain

2020-03-13 Thread Michael Haubenwallner
On 3/12/20 11:23 AM, Alexis Ballier wrote:
> On Thu, 2020-03-12 at 09:06 +0100, ha...@gentoo.org wrote:
>> As this native Win32 support is considered highly experimental still,
>> I
>> would like to apply the libtool patches for parity via elibtoolize
>> only,
>> without applying them in sys-devel/libtool itself yet.
>>
> 
> IIRC you need to do it this way, experimental or not: elibtoolize is
> needed for packages whose autotools have been generated with an old
> libtool (ie all of them for now). eautoreconf should call elibtoolize,
> so, after having this in elt-patches, better focus on upstreaming this
> in libtool itself so that the need for elibtoolize fades away with
> time.

Actually, sys-devel/libtool should only apply libtool patches that are
committed upstream already, to not confuse other distros and/or package
managers when package maintainers use libtoolize ('make dist') on Gentoo.

> 
> You will probably run into the same issues as in the old days with BSD:
> not all packages run elibtoolize and you do not have a sane way to
> force this besides editing ebuilds.

Yeah, we do face this issue in Prefix as well.

/haubi/



[gentoo-dev] Re: [PATCH 4/4] winnt: die if libtool version is not 2.4.6+

2020-03-13 Thread Michael Haubenwallner
On 3/12/20 9:48 PM, James Le Cuirot wrote:
> On Thu, 12 Mar 2020 09:06:26 +0100
> ha...@gentoo.org wrote:
> 
>> From: Michael Haubenwallner 
>>
>> Signed-off-by: Michael Haubenwallner 
>> ---
>>  eltpatch.in | 14 +-
>>  1 file changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/eltpatch.in b/eltpatch.in
>> index 6b69216..e12f754 100644
>> --- a/eltpatch.in
>> +++ b/eltpatch.in
>> @@ -179,7 +179,7 @@ elibtoolize() {
>>  *-hpux*)elt_patches+=" hpux-conf deplibs hc-flag-ld 
>> hardcode hardcode-relink relink-prog no-lc" ;;
>>  *-irix*)elt_patches+=" irix-ltmain" ;;
>>  *-mint*)elt_patches+=" mint-conf" ;;
>> -*-winnt*)   elt_patches+=" winnt-conf winnt-ltmain" ;;
>> +*-winnt*)   elt_patches+=" winnt-ltmain winnt-conf" ;;
>>  esac
>>  
>>  if ${LD} --version 2>&1 | grep -qs 'GNU gold'; then
> 
> This change reorders something you added in the first patch.
> 

This is to perform the version check earlier rather than later.

Otherwise, the order is irrelevant.

Thanks!
/haubi/



Re: [gentoo-dev] [PATCH 0/4] elt-patches: support wrapped Win32 MSVC toolchain

2020-03-13 Thread Alexis Ballier
On Thu, 2020-03-12 at 20:59 +, James Le Cuirot wrote:
> On Thu, 12 Mar 2020 11:23:04 +0100
> Alexis Ballier  wrote:
> 
> > On Thu, 2020-03-12 at 09:06 +0100, ha...@gentoo.org wrote:
> > > As this native Win32 support is considered highly experimental
> > > still,
> > > I
> > > would like to apply the libtool patches for parity via
> > > elibtoolize
> > > only,
> > > without applying them in sys-devel/libtool itself yet.
> > >   
> > 
> > IIRC you need to do it this way, experimental or not: elibtoolize
> > is
> > needed for packages whose autotools have been generated with an old
> > libtool (ie all of them for now). eautoreconf should call
> > elibtoolize,
> > so, after having this in elt-patches, better focus on upstreaming
> > this
> > in libtool itself so that the need for elibtoolize fades away with
> > time.
> > 
> > You will probably run into the same issues as in the old days with
> > BSD:
> > not all packages run elibtoolize and you do not have a sane way to
> > force this besides editing ebuilds.
> 
> I've long wanted to automatically apply elibtoolize to fix other
> cross-compile issues. I did come up with a rough prototype and it did
> work though I imagine it might break some packages. Maybe it should
> be
> opt-out rather than opt-in?

If a patch in elibtoolize might break something then it should not be
there in the first place: the function is called by a lot of packages.
However, we can assume that such packages have been tested whereas by
magically calling elibtoolize they have not. A good solution to avoid
this could be to modify the default src_prepare in EAPI8 to call it.

I think some hacks were implemented for fbsd via profile.bashrc because
the pain caused by *not* calling elibtoolize (soname changes) was worse
than having untested packages that might break under a red moon.


Alexis.