Re: [gentoo-dev] [PATCH v2 3/3] gnuconfig.eclass: use BDEPEND, BROOT where available (drop support for EAPI <4)

2021-04-09 Thread Sam James


> On 10 Apr 2021, at 01:13, Michael Orlitzky  wrote:
> 
> On Sat, 2021-04-10 at 00:32 +0100, Sam James wrote:
>> 
>> 
>> Yes, this is the part I find difficult too. The important
>> distinction here was *bootstrapping* (which I missed)
>> but I think at least we should make a list of packages generally considered
>> critical for bootstrap.
>> 
> 
> What is a bootstrap package?
> 
> There is some chicken-and-egg problem to be solved, but I don't think
> that we should be assuming that e.g. GNU grep is always present just
> because, during the base case of some recursive process, POSIX grep
> must be available temporarily.
> 
> Anyway, https://bugs.gentoo.org/485356 awaits reopening if you make any
> progress on this.
> 

Oh, I agree completely. CCed myself on the bug and added to the list
to think about/work on.

I’m pleased a bug existed in the past! I don’t agree with it being closed 
though:
documentation issues can exist without a patch existing to fix them yet, right?


signature.asc
Description: Message signed with OpenPGP


Re: [gentoo-dev] [PATCH v2 3/3] gnuconfig.eclass: use BDEPEND, BROOT where available (drop support for EAPI <4)

2021-04-09 Thread Sam James


> On 7 Apr 2021, at 12:18, Michael Orlitzky  wrote:
> 
> On Tue, 2021-04-06 at 20:32 +0100, Sam James wrote:
>> 
>>> 
>>> We usually don't add basic tools like grep to dependencies.
>> 
>> Few points:
>> 
>> ...
> 
> 5) There are no clear rules about what @system packages can be left out
> of *DEPEND and when, so their presence is wildly inconsistent.

Yes, this is the part I find difficult too. The important
distinction here was *bootstrapping* (which I missed)
but I think at least we should make a list of packages generally considered
critical for bootstrap.

The Prefix documentation and scripts as well as Catalyst
will help here.


signature.asc
Description: Message signed with OpenPGP


Re: [gentoo-dev] [PATCH v2 3/3] gnuconfig.eclass: use BDEPEND, BROOT where available (drop support for EAPI <4)

2021-04-09 Thread Sam James


> On 7 Apr 2021, at 12:06, Ulrich Mueller  wrote:
> 
>>>>>> On Tue, 06 Apr 2021, Sam James wrote:
> 
>> 1) @system varies between profiles anyway which makes it hard to fully
>> rely on;
> 
> That's exactly the reason why you _don't_* add GNU grep as a dependency,
> because e.g. on Prefix grep may be provided by another package.
> 
> grep is a POSIX tool and a bootstrap package, so we can be certain that
> will be available everywhere. (And the single grep instance in the
> eclass doesn't use any GNUisms.)
> 

Yeah, bootstrap package was the key distinction I was missing.

>> 2) As a few of us have discussed in #gentoo-portage in the past,
>> continuing this trend of not explicitly stating dependencies makes
>> parallelism in Portage difficult. You can try this with
>> —implicit-system-deps=n, but we really need to be stating what we use
>> explicitly.
> 
> This would mean that we'd end up with lots of system dependencies in
> every ebuild. The current policy is in place for good reasons.
> 

Yes, although as I’ll say below, I’m not sure it’s as clear as it could be.

> You may have a point for adding library dependencies explicitly, but
> certainly not for common build tools (aka bootstrap packages). They will
> be available from the very beginning of the bootstrap process.

Indeed.

>> The benefit is enhanced parallelism and the downside is being
>> _slightly_ more verbose in some ebuilds;
> 
> s/slightly/much/;s/some/all/
> 
> We'd end up having a significant subset of profiles/base/packages in
> _every_ ebuild. Or even worse, a bunch of any-of-many dependencies or
> virtuals, in order to account for different systems. Personally, I
> wouldn't be willing to maintain such dependencies for my ebuilds.
> 

I’m not sure this would be a significant subset, but I agree, this
approach is really only applicable to non-bootstrap dependencies.

What we do need likely need is to document this specific part better.

> More importantly, if you want such a policy change, then you should
> discuss it first and have it approved. Until then, the current policy
> [1] applies.

Sure. It should probably be in the QA policy document though, given
the devmanual is not always explicitly policy, as we’ve
discussed.

TL;DR: Agreed, I’ll drop this part from the changes, and we
may revisit the issue through e.g. documentation.

> 
>> 3) Implicit dependencies make it hard for us to ever actually swap
>> implementations;
> 
>> 4) This helps when creating minimal systems without Portage in it.
> 
> [1] 
> https://devmanual.gentoo.org/general-concepts/dependencies/index.html#implicit-system-dependency



signature.asc
Description: Message signed with OpenPGP


Re: [gentoo-dev] vdr-plugin-2.eclass QA fix, please review, bug 778815

2021-04-09 Thread Sam James


> On 9 Apr 2021, at 22:10, Joerg Bornkessel  wrote:
> 
> https://bugs.gentoo.org/show_bug.cgi?id=778815
> 
> pkgcheck, gives an error like this
> VariableScope: vdr-plugin-2: variable 'WORKDIR' used in 
> 'vdr-plugin-2_pkg_setup', line 371
> 

Hi, thanks for looking into this!

> inserted patch will fix this issues

Could you make the change in a git checkout and then use ‘git format-patch’ and 
then
git send-email to send it here?

> 
> 
> --- vdr-plugin-2.eclass 2020-02-23 17:39:40.0 +0100
> +++ vdr-plugin-2_QA-fixed.eclass2021-04-06 23:27:37.358477036 +0200
> @@ -368,7 +368,7 @@
>VDR_INCLUDE_DIR="/usr/include/vdr"
>DVB_INCLUDE_DIR="/usr/include"
> 
> -   TMP_LOCALE_DIR="${WORKDIR}/tmp-locale"
> +   TMP_LOCALE_DIR="${T}/tmp-locale"
> 
>LOCDIR=$(pkg-config --variable=locdir vdr)
> 
> 

This looks fine as-is, although you may want to take the opportunity
to do some other clean ups, like replacing pkg-config with
$(tc-getPKG_CONFIG) to respect the ${PKG_CONFIG} variable
for e.g. cross-compilation.

We should add pkg-config to BDEPEND in EAPI 7 if it’s needed too.

It looks like there are some missing || dies on e.g. sed and other
external commands too which we could fix.

> i did several tests on my setup, it works like expected.
> please review, thanks...
> 
> --
> Joerg Bornkessel 
> GnuPG Key: 0x93EB5F4DAA5832A1
> Fingerprint: 0E0A A1EE 1DF4 41D7 A3F5 21C2 93EB 5F4D AA58 32A1
> 



signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] base.eclass: last-rites

2021-04-09 Thread Sam James
base.eclass: last-rite eclass (mark as @DEAD)

Removal on 2021-05-09. Please port to general eclass functions/helpers.

See https://bugs.gentoo.org/497022 for information.


signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] games.eclass: last-rite eclass

2021-04-09 Thread Sam James
games.eclass: mark as @DEAD (last-rite eclass)

Removal on 2021-05-09. Please port to general eclass functions/helpers.

No specific eclass is needed for general games installation.


signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] s390 has been dropped to ~s390 (testing/unstable) (resent)

2021-04-06 Thread Sam James
Hi,

Given I received no comments on the mailing list [0] post from 16th Feb and 
affirmative comments via IRC, I’ve
dropped all s390 keywords to ~s390 (testing/unstable). We’ll keep the s390 arch 
in addition to s390x as a subprofile
for now as this reduces the hassle of maintaining s390.

This is actually a net improvement to any users of s390 if they’re out there, 
as stable s390 was completely unusable
in terms of consistency given it was marked ‘exp'.

The aim is to restore s390 and s390x to being a ‘dev’ profile rather than ‘exp’ 
when possible, i.e. consistency
within ~s390 keywords - which does not yet exist.

I’ve started looking at what work would be needed here: 
https://github.com/gentoo/gentoo/pull/20270. I intend
to work on it every so often rather than it being a priority. Help welcome to 
file keywording bugs as indicated
by CI results in that PR!

I’ve updated all stabilisation bugs with s390@ CCed. I (ab)used NATTkA to do 
this so that the nuance of arch bugs
was respected (e.g. not closing bugs when s390@ wasn’t the last arch), hence 
the ’s390 done’ comments, which may
be slightly misleading.

TL;DR: s390 is now pure ~arch but this should be an improvement as we aim for 
consistency in the keywords in future. Help is
welcome. All existing stable bugs for s390 should have been updated - let me 
know if you find one which hasn’t been.

[0] 
https://archives.gentoo.org/gentoo-dev/message/69834962ec55a31908544793eb2dea05

[Originally forgot reply-to].


signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] s390 has been dropped to ~s390 (testing/unstable)

2021-04-06 Thread Sam James
Hi,

Given I received no comments on the mailing list [0] post from 16th Feb and 
affirmative comments via IRC, I’ve
dropped all s390 keywords to ~s390 (testing/unstable). We’ll keep the s390 arch 
in addition to s390x as a subprofile
for now as this reduces the hassle of maintaining s390.

This is actually a net improvement to any users of s390 if they’re out there, 
as stable s390 was completely unusable
in terms of consistency given it was marked ‘exp'.

The aim is to restore s390 and s390x to being a ‘dev’ profile rather than ‘exp’ 
when possible, i.e. consistency
within ~s390 keywords - which does not yet exist.

I’ve started looking at what work would be needed here: 
https://github.com/gentoo/gentoo/pull/20270. I intend
to work on it every so often rather than it being a priority. Help welcome to 
file keywording bugs as indicated
by CI results in that PR!

I’ve updated all stabilisation bugs with s390@ CCed. I (ab)used NATTkA to do 
this so that the nuance of arch bugs
was respected (e.g. not closing bugs when s390@ wasn’t the last arch), hence 
the ’s390 done’ comments, which may
be slightly misleading.

TL;DR: s390 is now pure ~arch but this should be an improvement as we aim for 
consistency in the keywords in future. Help is
welcome. All existing stable bugs for s390 should have been updated - let me 
know if you find one which hasn’t been.

[0] 
https://archives.gentoo.org/gentoo-dev/message/69834962ec55a31908544793eb2dea05


signature.asc
Description: Message signed with OpenPGP


Re: [gentoo-dev] Packages up for grabs: app-emulation/img, app-forensics/aide, app-text/cherrytree, media-gfx/zbar, net-p2p/go-ethereum

2021-04-06 Thread Sam James


> On 6 Apr 2021, at 22:16, Sam James  wrote:
> 
> Packages up for grabs due to retirement of a proxied maintainer (and somebody 
> giving up a package):
> app-emulation/img
> app-forensics/aide
> app-text/cherrytree
> media-gfx/zbar
> net-p2p/go-ethereum
> 
> Most have no open bugs and are in a reasonable state.

(But need a bump).


signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] Packages up for grabs: app-emulation/img, app-forensics/aide, app-text/cherrytree, media-gfx/zbar, net-p2p/go-ethereum

2021-04-06 Thread Sam James
Packages up for grabs due to retirement of a proxied maintainer (and somebody 
giving up a package):
app-emulation/img
app-forensics/aide
app-text/cherrytree
media-gfx/zbar
net-p2p/go-ethereum

Most have no open bugs and are in a reasonable state.


signature.asc
Description: Message signed with OpenPGP


Re: [gentoo-dev] [PATCH v2 3/3] gnuconfig.eclass: use BDEPEND, BROOT where available (drop support for EAPI <4)

2021-04-06 Thread Sam James


> On 5 Apr 2021, at 17:24, Ulrich Mueller  wrote:
> 
>>>>>> On Mon, 05 Apr 2021, Sam James wrote:
> 
>> +4|5|6)
>> +DEPEND="
>> +sys-apps/grep
>> +sys-devel/gnuconfig
>> +"
>> +;;
>> +7)
>> +BDEPEND="
>> +sys-apps/grep
> 
> We usually don't add basic tools like grep to dependencies.

Few points:

1) @system varies between profiles anyway which makes it hard to fully
rely on;

2) As a few of us have discussed in #gentoo-portage in the past, continuing
this trend of not explicitly stating dependencies makes parallelism in Portage
difficult. You can try this with —implicit-system-deps=n, but we really need
to be stating what we use explicitly.

The benefit is enhanced parallelism and the downside is being _slightly_ more
verbose in some ebuilds;

3) Implicit dependencies make it hard for us to ever actually swap 
implementations;

4) This helps when creating minimal systems without Portage in it.


signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] [PATCH v2 3/3] gnuconfig.eclass: use BDEPEND, BROOT where available (drop support for EAPI <4)

2021-04-05 Thread Sam James
EPREFIX is only available in > EAPI 2 but let's take the opportuinty
to clean up in general. We don't want to keep worrying about
*very* old EAPI cases, especially given other eclasses
either barely - or don't - support it.

Signed-off-by: Sam James 
---
 eclass/gnuconfig.eclass | 41 +++--
 1 file changed, 35 insertions(+), 6 deletions(-)

diff --git a/eclass/gnuconfig.eclass b/eclass/gnuconfig.eclass
index f679441445f..865bc9fcb70 100644
--- a/eclass/gnuconfig.eclass
+++ b/eclass/gnuconfig.eclass
@@ -15,7 +15,23 @@
 # other files that come with automake, e.g. depcomp, mkinstalldirs, etc.
 #
 
-DEPEND="sys-devel/gnuconfig"
+case ${EAPI:-0} in
+   4|5|6)
+   DEPEND="
+   sys-apps/grep
+   sys-devel/gnuconfig
+   "
+   ;;
+   7)
+   BDEPEND="
+   sys-apps/grep
+   sys-devel/gnuconfig
+   "
+   ;;
+   *)
+   die "EAPI ${EAPI} is unsupported!"
+   ;;
+esac
 
 # @FUNCTION: gnuconfig_update
 # @USAGE: [file1 file2 ...]
@@ -91,12 +107,25 @@ gnuconfig_do_update() {
 # This searches the standard locations for the newest config.{sub|guess}, and
 # returns the directory where they can be found.
 gnuconfig_findnewest() {
-   local locations=(
-   "${EPREFIX}"/usr/share/misc/config.sub
-   "${EPREFIX}"/usr/share/gnuconfig/config.sub
-   "${EPREFIX}"/usr/share/automake*/config.sub
-   "${EPREFIX}"/usr/share/libtool/config.sub
+   local locations=()
+   local prefix
+
+   case ${EAPI:-0} in
+   4|5|6)
+   prefix="${EPREFIX}"
+   ;;
+   *)
+   prefix="${BROOT}"
+   ;;
+   esac
+
+   locations+=(
+   "${prefix}"/usr/share/misc/config.sub
+   "${prefix}"/usr/share/gnuconfig/config.sub
+   "${prefix}"/usr/share/automake*/config.sub
+   "${prefix}"/usr/share/libtool/config.sub
)
+
grep -s '^timestamp' "${locations[@]}" | \
sort -r -n -t\' -k2 | \
sed -n '1{s,/config.sub:.*$,,;p;q}'
-- 
2.31.1




[gentoo-dev] [PATCH v2 2/3] gnuconfig.eclass: provide basic @ECLASS block, docs

2021-04-05 Thread Sam James
Signed-off-by: Sam James 
---
 eclass/gnuconfig.eclass | 33 +++--
 1 file changed, 23 insertions(+), 10 deletions(-)

diff --git a/eclass/gnuconfig.eclass b/eclass/gnuconfig.eclass
index 3433837787c..f679441445f 100644
--- a/eclass/gnuconfig.eclass
+++ b/eclass/gnuconfig.eclass
@@ -1,25 +1,32 @@
-# Copyright 1999-2020 Gentoo Authors
+# Copyright 1999-2021 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
-#
-# Author: Will Woods 
-#
+
+# @ECLASS: gnuconfig.eclass
+# @MAINTAINER:
+# maintainer-nee...@gentoo.org
+# @AUTHOR:
+# Will Woods 
+# @BLURB: Eclass to make PCF font generator from BDF uniform and optimal
+# @DESCRIPTION:
 # This eclass is used to automatically update files that typically come with
 # automake to the newest version available on the system. The most common use
 # of this is to update config.guess and config.sub when configure dies from
 # misguessing your canonical system name (CHOST). It can also be used to update
 # other files that come with automake, e.g. depcomp, mkinstalldirs, etc.
 #
-# usage: gnuconfig_update [file1 file2 ...]
+
+DEPEND="sys-devel/gnuconfig"
+
+# @FUNCTION: gnuconfig_update
+# @USAGE: [file1 file2 ...]
+# @DESCRIPTION:
 # if called without arguments, config.guess and config.sub will be updated.
 # All files in the source tree ($S) with the given name(s) will be replaced
 # with the newest available versions chosen from the list of locations in
 # gnuconfig_findnewest(), below.
 #
 # gnuconfig_update should generally be called from src_unpack()
-
-
-DEPEND="sys-devel/gnuconfig"
-
+#
 # Wrapper function for gnuconfig_do_update. If no arguments are given, update
 # config.sub and config.guess (old default behavior), otherwise update the
 # named files.
@@ -42,6 +49,9 @@ gnuconfig_update() {
return $?
 }
 
+# @FUNCTION: gnuconfig_do_update
+# @INTERNAL
+# @DESCRIPTION:
 # Copy the newest available version of specified files over any old ones in the
 # source dir. This function shouldn't be called directly - use gnuconfig_update
 #
@@ -75,7 +85,10 @@ gnuconfig_do_update() {
return 0
 }
 
-# this searches the standard locations for the newest config.{sub|guess}, and
+# @FUNCTION: gnuconfig_findnewest
+# @INTERNAL
+# @DESCRIPTION:
+# This searches the standard locations for the newest config.{sub|guess}, and
 # returns the directory where they can be found.
 gnuconfig_findnewest() {
local locations=(
-- 
2.31.1




[gentoo-dev] [PATCH v2 1/3] autotools.eclass: eclassdoc, cosmetic changes, drop old EAPIs, configure.ac rename

2021-04-05 Thread Sam James
(Relatively) significant changes:
* inherit eutils for < EAPI 7 for eqawarn
* rename configure.in -> configure.ac in >= EAPI 8 (to avoid retroactive 
breakage)
* convert phase test to EBUILD_PHASE_FUNC
* use gnuconfig.eclass for finding gnuconfig logic for consistency and
avoiding duplication
* add explicit GNU awk BDEPEND as we use it in the eclass
* drop support for < EAPI 5 officially
[Needed for the EBUILD_PHASE_FUNC change.
< EAPI 5 is no longer in ::gentoo (since December).

Note that we were using ${EPREFIX} which isn't defined
< EAPI 3 so we were wrong about which EAPIs we supported
anyway.]

eclassdoc fixes:
* explicitly blank and mark variables as @DEFAULT_UNSET
* add @DESCRIPTION for _at_uses_pkg
* document AUTOTOOLS_DEPEND

Cosmetic changes:
* minor cosmetic changes to various elogs
* fix whitespace/phrasing in comment
* convert ewarn to eqawarn
* consistent 'case' style
* consistent variable references
* consistent references to bugs in comments
* consistent use of ${ECLASS}, not "autotools.eclass"
* use same ${WANT_AUTOCONF} comparison test throughout

Bug: https://bugs.gentoo.org/426262
Closes: https://bugs.gentoo.org/584254
Signed-off-by: Sam James 
---
 eclass/autotools.eclass | 118 ++--
 1 file changed, 65 insertions(+), 53 deletions(-)

diff --git a/eclass/autotools.eclass b/eclass/autotools.eclass
index 3e6906cb469..455fe38f466 100644
--- a/eclass/autotools.eclass
+++ b/eclass/autotools.eclass
@@ -4,7 +4,7 @@
 # @ECLASS: autotools.eclass
 # @MAINTAINER:
 # base-sys...@gentoo.org
-# @SUPPORTED_EAPIS: 0 1 2 3 4 5 6 7
+# @SUPPORTED_EAPIS: 5 6 7
 # @BLURB: Regenerates auto* build scripts
 # @DESCRIPTION:
 # This eclass is for safely handling autotooled software packages that need to
@@ -19,19 +19,23 @@ if [[ ${__AUTOTOOLS_AUTO_DEPEND+set} == "set" ]] ; then
# eclass at that point, but that adds overhead, and it's trivial
# to re-order inherit in eclasses/ebuilds instead.  #409611
if [[ ${__AUTOTOOLS_AUTO_DEPEND} != ${AUTOTOOLS_AUTO_DEPEND} ]] ; then
-   die "AUTOTOOLS_AUTO_DEPEND changed value between inherits; 
please inherit autotools.eclass first! ${__AUTOTOOLS_AUTO_DEPEND} -> 
${AUTOTOOLS_AUTO_DEPEND}"
+   die "AUTOTOOLS_AUTO_DEPEND changed value between inherits; 
please inherit ${ECLASS} first! ${__AUTOTOOLS_AUTO_DEPEND} -> 
${AUTOTOOLS_AUTO_DEPEND}"
fi
 fi
 
-if [[ -z ${_AUTOTOOLS_ECLASS} ]]; then
+if [[ -z ${_AUTOTOOLS_ECLASS} ]] ; then
 _AUTOTOOLS_ECLASS=1
 
 case ${EAPI:-0} in
-   0|1|2|3|4|5|6|7) ;;
+   5|6)
+   # Needed for eqawarn
+   inherit eutils
+   ;;
+   7) ;;
*) die "${ECLASS}: EAPI ${EAPI} not supported" ;;
 esac
 
-inherit libtool
+inherit gnuconfig libtool
 
 # @ECLASS-VARIABLE: WANT_AUTOCONF
 # @PRE_INHERIT
@@ -74,21 +78,14 @@ _LATEST_AUTOMAKE=( 1.16.2-r1:1.16 )
 
 _automake_atom="sys-devel/automake"
 _autoconf_atom="sys-devel/autoconf"
-if [[ -n ${WANT_AUTOMAKE} ]]; then
+if [[ -n ${WANT_AUTOMAKE} ]] ; then
case ${WANT_AUTOMAKE} in
# Even if the package doesn't use automake, we still need to 
depend
# on it because we run aclocal to process m4 macros.  This 
matches
# the autoreconf tool, so this requirement is correct, bug 
#401605.
none) ;;
-   latest)
-   # Use SLOT deps if we can.  For EAPI=0, we get pretty 
close.
-   if [[ ${EAPI:-0} != 0 ]] ; then
-   _automake_atom="|| ( `printf 
'>=sys-devel/automake-%s:%s ' ${_LATEST_AUTOMAKE[@]/:/ }` )"
-   else
-   _automake_atom="|| ( `printf 
'>=sys-devel/automake-%s ' ${_LATEST_AUTOMAKE[@]/%:*}` )"
-   fi
-   ;;
-   *)  _automake_atom="=sys-devel/automake-${WANT_AUTOMAKE}*" 
;;
+   latest) _automake_atom="|| ( `printf 
'>=sys-devel/automake-%s:%s ' ${_LATEST_AUTOMAKE[@]/:/ }` )" ;;
+   *) _automake_atom="=sys-devel/automake-${WANT_AUTOMAKE}*" ;;
esac
export WANT_AUTOMAKE
 fi
@@ -114,9 +111,16 @@ if [[ -n ${WANT_LIBTOOL} ]] ; then
export WANT_LIBTOOL
 fi
 
+# @ECLASS-VARIABLE: AUTOTOOLS_DEPEND
+# @INTERNAL
+# @DESCRIPTION:
+# Contains the combination of requested automake/autoconf/libtool
+# versions in *DEPEND format.
 AUTOTOOLS_DEPEND="${_automake_atom}
${_autoconf_atom}
-   ${_libtool_atom}"
+   ${_libtool_atom}
+   sys-apps/gawk
+"
 RDEPEND=""
 
 # @ECLASS-VARIABLE: AUTOTOOLS_AUTO_DEPEND
@@ -128,7 +132,7 @@ RDEPEND=""
 : ${AUTOTOOLS_AUTO_DEPEND:=yes}
 if [[ ${AUTOTOOLS_AUTO_DEPEND} != "no" ]] ; then
case ${EAPI:-0} in
-   0|1|2|3|4

Re: [gentoo-dev] [PATCH] flag-o-matic.eclass: get rid of eutils in

2021-04-01 Thread Sam James


> On 31 Mar 2021, at 10:09, Ulrich Mueller  wrote:
> 
>> On Wed, 31 Mar 2021, Andreas Sturmlechner wrote:
> 
>> setup-allowed-flags() {
>> +[[ ${EAPI} == [0-7] ]] ||
>> +die "Internal function ${FUNCNAME} is not available in 
>> >=EAPI-8."
>> +_setup-allowed-flags
>> +}
> 
> Strictly speaking, EAPIs are strings, so numeric comparison is not
> meaningful. Suggestion: "... is not available in EAPI ${EAPI}."

That’s a reason to not do arithmetic comparison in e.g. Bash, but >= refers
to age/chronological order here, which isn’t a problem.

> 
>> test-flag-PROG() {
>> +[[ ${EAPI} == [0-7] ]] ||
>> +die "Internal function ${FUNCNAME} is not available in 
>> >=EAPI-8."
>> +_test-flag-PROG
>> +}
> 
>> test-flags-PROG() {
>> +[[ ${EAPI} == [0-7] ]] ||
>> +die "Internal function ${FUNCNAME} is not available in 
>> >=EAPI-8."
>> +_test-flags-PROG
>> +}
> 
> Same for these.
> 
> Ulrich



signature.asc
Description: Message signed with OpenPGP


Re: [gentoo-dev] [PATCH] flag-o-matic.eclass: get rid of eutils in

2021-03-31 Thread Sam James


> On 31 Mar 2021, at 07:39, Andreas Sturmlechner  wrote:
> 
> qa-reports showing >7300 ebuilds with EAPI-7 using eutils.eclass, that can't 
> be right.
> 
> - Restrict inherit eutils to  - Drop bogus multilib.eclass (inherited by toolchain-funcs.eclass anyway)
> - Several functions look like they should be internal
> - Fix eclassdoc issues, add missing docu
> 
> See also:
> https://qa-reports.gentoo.org/output/eapi-per-eclass/eutils.eclass/
> https://github.com/gentoo/gentoo/pull/20207

Looks good and similar to what I had previously (as a draft). Good work and a 
nice
opportunity to kill off some internal functions too.



signature.asc
Description: Message signed with OpenPGP


Re: [gentoo-dev] [PATCH] autotools.eclass: eclassdoc, cosmetic changes, drop old EAPIs

2021-03-30 Thread Sam James

> On 27 Mar 2021, at 22:21, Sam James  wrote:
> 

Given how uncontroversial most of it is, the positive reviews, and the fact 
that I pushed a load
of other eclassdoc changes (for other eclasses) but CI is still down, it makes
sense to throw in as much as we can to not waste the big cache regeneration 
that’s going to occur
anyway.

I’ve therefore pushed the uninteresting parts of this (all cosmetic for 
eclassdocs or whitespace,
nothing functional involving EAPIs or anything like that).

I’ll send out a v2 either later today or tomorrow with the parts I’ve 
cherry-picked removed.

v2 will look roughly like:
> (Relatively) significant changes:
> * inherit eutils for < EAPI 7 for eqawarn
> * drop support for < EAPI 5
> 
> [Needed for the EBUILD_PHASE_FUNC change.
> < EAPI 5 is no longer in ::gentoo (since December).]
> 
> eclassdoc fixes:
> * explicitly blank and mark variables as @DEFAULT_UNSET
> * add @DESCRIPTION for _at_uses_pkg
> * document AUTOTOOLS_DEPEND
> 
> Cosmetic changes:
> * convert ewarn to eqawarn
> * consistent 'case' style
> * consistent variable references
> * consistent use of ${ECLASS}, not "autotools.eclass"
> * use same ${WANT_AUTOCONF} comparison test throughout

If we’re sticking with the dropping of EAPIs earlier than 5, I think there’s 
some more cruft I can clear out too.

So, as you can see, not much interesting actually got cherry-picked. For 
transparency - although
you could read git yourself, I cherry-picked the following:

$ git shortlog 3f1cd0c161eeec3a5b0173da31f8949fa5eb38b5..HEAD
Sam James (6):
  autotools.eclass: mark AT_M4DIR as @DEFAULT_UNSET
  autotools.eclass: mark WANT_AUTO*, AUTOTOOLS_AUTO_DEPEND as @PRE_INHERIT
  autotools.eclass: mark AT_SYS_M4DIR variable as @DEFAULT_UNSET
  autotools.eclass: consistent references to bugs in comments
  autotools.eclass: fix whitespace/phrasing in comment
  autotools.eclass: minor cosmetic changes to various elogs



signature.asc
Description: Message signed with OpenPGP


Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?

2021-03-29 Thread James Le Cuirot
On Sun, 28 Mar 2021 19:46:32 -0400
Joshua Kinard  wrote:

> I've kinda come to this conclusion myself.  I could probably host an
> extracted, micro-initramfs on my NFS server that would be loaded by the
> kernel to jump to $REAL_ROOT.  Not *too* much of an issue on the Octane,
> because I can store the kernel command line args in a PROM variable so that
> all I have to do is type "$foo" at the PROM prompt to load something.  But,
> SGI did their best to be inconsistent, and IP27 systems cannot permanently
> save variables to NVRAM.  Once you power cycle, all user-defined PROM vars
> are lost.  And Linux's NFS Root command args are somewhat complicated from
> what I remember.  Upshot is I boot the IP27 over serial console, so I can
> just save bootp() args in a text file on my desktop and paste it into the
> console for those instances.

Have you seen CONFIG_CMDLINE? It lets you bake command line args into
the kernel image itself.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpjPj3Fv0z6w.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] autotools.eclass: eclassdoc, cosmetic changes, drop old EAPIs

2021-03-28 Thread Sam James


> On 28 Mar 2021, at 13:46, Ulrich Mueller  wrote:
> 
> 
>>> On Sun, 28 Mar 2021, David Seifert wrote:
>> This is just bringing it in line with the rest of the eclass. You know,
>> consistency.
> 
> If that's the goal then the patch should update all occurences, though.

Well, that was definitely the aim. To avoid any doubt, I don’t feel 
particularly passionate about which style we use so it was not the main point 
of this patch. Just copying existing style for consistency.

> Especially those where usage is inconsistent within the same line.

I’m mobile right now but maybe you could show me what you’re referring to? 
Thank you!

We have review for a reason - to improve - but being vague doesn’t help me do 
that ;)


Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?

2021-03-28 Thread James Le Cuirot
On Sat, 27 Mar 2021 18:40:52 -0400
Joshua Kinard  wrote:

> On 3/27/2021 18:16, James Le Cuirot wrote:
> > On Sat, 27 Mar 2021 17:43:34 -0400
> > Joshua Kinard  wrote:
> >   
> >> I kinda wish the Linux kernel had an ability to partially boot, init the
> >> networking subsystem, then fetch an initramfs image over TFTP like it can 
> >> do
> >> with NFS Root.  That would solve the problem on my MIPS system(s) (and make
> >> install netboots better).  I've dug around, but this does not seem to be a
> >> capability currently in the kernel, unless I have over looked something.
> >>
> >> Otherwise in the future, I may just have to setup an initramfs into an NFS
> >> Root and teach the SGI's to somehow deal with it.  Which all still seems
> >> unnecessarily complicated because some other distro thinks it knows what's
> >> best for everyone else (but I digress...).  
> > 
> > NBD may be a slightly simpler alternative and a bit more like an
> > initramfs. nbdkit can do all sorts of weird things. I thought it might
> > have a plugin for cpio archives, allowing you to use a regular
> > initramfs generated by Dracut or similar directly. It doesn't appear to
> > but plugins are quite easy to write. Alternatively you could just
> > extract the initramfs and use nbdkit-linuxdisk-plugin.  
> 
> Can NBD be used like I described?  Never played with it before.  The MIPS
> machine has functioning local disk drives, and currently, it boots fine by
> just pulling a kernel off my TFTP server and booting from the local drive,
> no initramfs needed because I compiled everything into it.  If we ever force
> sep-usr to end, then I'll need a way to teach it to mount /usr before
> dropping into /bin/init (and nothing else).

Apologies, I went to experiment with this idea but I'd forgotten that
booting over NBD is not a built-in kernel feature and requires... an
initramfs. NFS looks like the only option with this general approach.

Rich is right though, the initramfs can be tiny. Dracut images are
heavy because they are very flexible and pack a lot of features but
none of that is required.

The kexec idea would be a nice bonus for you, if it works. Limiting
what kernel features you can enable must be frustrating.

It's also worth bearing in mind that you could just generate an image
with Dracut and extract it to a disk partition. That may seem a little
pointless if you're not using something like LVM or encryption but I
don't see the point in separate /usr either. ;) I'm guessing you don't
want to change your partition layout at this point though.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpAb6gauIo0N.pgp
Description: OpenPGP digital signature


[gentoo-dev] Last-rites: autotools-utils.eclass

2021-03-27 Thread Sam James
autotools-utils.eclass: mark as @DEAD (last-rite eclass)

Removal on 2021-04-28. Please port to autotools.eclass
or out-of-source.eclass.


signature.asc
Description: Message signed with OpenPGP


Re: [gentoo-dev] [PATCH] xorg-2.eclass: Mark @DEAD for removal

2021-03-27 Thread Sam James


> On 27 Mar 2021, at 19:25, Matt Turner  wrote:
> 
> Per Sam's suggestion, I'll also add
> 
> # @DEPRECATED: Use xorg-3.eclass
> 

I made the same mistake with oasis, do just ‘xorg-3.class’ because the
pkgcheck text says ‘replacement: ${text}’.


signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] [PATCH] autotools.eclass: eclassdoc, cosmetic changes, drop old EAPIs

2021-03-27 Thread Sam James
(Relatively) significant changes:
* inherit eutils for < EAPI 7 for eqawarn
* mark WANT_AUTO*, AUTOTOOLS_AUTO_DEPEND as @PRE_INHERIT
* convert phase test to EBUILD_PHASE_FUNC
* drop support for < EAPI 5

[Needed for the EBUILD_PHASE_FUNC change.
< EAPI 5 is no longer in ::gentoo (since December).]

eclassdoc fixes:
* explicitly blank and mark variables as @DEFAULT_UNSET
* add @DESCRIPTION for _at_uses_pkg
* mark AT_M4DIR as @DEFAULT_UNSET
* document AUTOTOOLS_DEPEND

Cosmetic changes:
* minor cosmetic changes to various elogs
* fix whitespace/phrasing in comment
* convert ewarn to eqawarn
* consistent 'case' style
* consistent variable references
* consistent references to bugs in comments
* consistent use of ${ECLASS}, not "autotools.eclass"
* use same ${WANT_AUTOCONF} comparison test throughout

Signed-off-by: Sam James 
---
 eclass/autotools.eclass | 101 
 1 file changed, 61 insertions(+), 40 deletions(-)

diff --git a/eclass/autotools.eclass b/eclass/autotools.eclass
index 4ae360aa24d..1c687d7cb5e 100644
--- a/eclass/autotools.eclass
+++ b/eclass/autotools.eclass
@@ -19,31 +19,38 @@ if [[ ${__AUTOTOOLS_AUTO_DEPEND+set} == "set" ]] ; then
# eclass at that point, but that adds overhead, and it's trivial
# to re-order inherit in eclasses/ebuilds instead.  #409611
if [[ ${__AUTOTOOLS_AUTO_DEPEND} != ${AUTOTOOLS_AUTO_DEPEND} ]] ; then
-   die "AUTOTOOLS_AUTO_DEPEND changed value between inherits; 
please inherit autotools.eclass first! ${__AUTOTOOLS_AUTO_DEPEND} -> 
${AUTOTOOLS_AUTO_DEPEND}"
+   die "AUTOTOOLS_AUTO_DEPEND changed value between inherits; 
please inherit ${ECLASS} first! ${__AUTOTOOLS_AUTO_DEPEND} -> 
${AUTOTOOLS_AUTO_DEPEND}"
fi
 fi
 
-if [[ -z ${_AUTOTOOLS_ECLASS} ]]; then
+if [[ -z ${_AUTOTOOLS_ECLASS} ]] ; then
 _AUTOTOOLS_ECLASS=1
 
 case ${EAPI:-0} in
-   0|1|2|3|4|5|6|7) ;;
+   5|6)
+   # Needed for eqawarn
+   inherit eutils
+   ;;
+   7) ;;
*) die "${ECLASS}: EAPI ${EAPI} not supported" ;;
 esac
 
 inherit libtool
 
 # @ECLASS-VARIABLE: WANT_AUTOCONF
+# @PRE_INHERIT
 # @DESCRIPTION:
 # The major version of autoconf your package needs
 : ${WANT_AUTOCONF:=latest}
 
 # @ECLASS-VARIABLE: WANT_AUTOMAKE
+# @PRE_INHERIT
 # @DESCRIPTION:
 # The major version of automake your package needs
 : ${WANT_AUTOMAKE:=latest}
 
 # @ECLASS-VARIABLE: WANT_LIBTOOL
+# @PRE_INHERIT
 # @DESCRIPTION:
 # Do you want libtool?  Valid values here are "latest" and "none".
 : ${WANT_LIBTOOL:=latest}
@@ -61,9 +68,9 @@ inherit libtool
 # version.
 # If a newer slot is stable on any arch, and is NOT reflected in this list,
 # then circular dependencies may arise during emerge @system bootstraps.
-# 
-# See bug 312315 and 465732 for further information and context.
-# 
+#
+# See bug #312315 and bug #465732 for further information and context.
+#
 # Do NOT change this variable in your ebuilds!
 # If you want to force a newer minor version, you can specify the correct
 # WANT value by using a colon:  :
@@ -71,11 +78,11 @@ _LATEST_AUTOMAKE=( 1.16.2-r1:1.16 )
 
 _automake_atom="sys-devel/automake"
 _autoconf_atom="sys-devel/autoconf"
-if [[ -n ${WANT_AUTOMAKE} ]]; then
+if [[ -n ${WANT_AUTOMAKE} ]] ; then
case ${WANT_AUTOMAKE} in
# Even if the package doesn't use automake, we still need to 
depend
# on it because we run aclocal to process m4 macros.  This 
matches
-   # the autoreconf tool, so this requirement is correct.  #401605
+   # the autoreconf tool, so this requirement is correct, bug 
#401605.
none) ;;
latest)
# Use SLOT deps if we can.  For EAPI=0, we get pretty 
close.
@@ -111,12 +118,18 @@ if [[ -n ${WANT_LIBTOOL} ]] ; then
export WANT_LIBTOOL
 fi
 
+# @ECLASS-VARIABLE: AUTOTOOLS_DEPEND
+# @INTERNAL
+# @DESCRIPTION:
+# Contains the combination of requested automake/autoconf/libtool
+# versions in *DEPEND format.
 AUTOTOOLS_DEPEND="${_automake_atom}
${_autoconf_atom}
${_libtool_atom}"
 RDEPEND=""
 
 # @ECLASS-VARIABLE: AUTOTOOLS_AUTO_DEPEND
+# @PRE_INHERIT
 # @DESCRIPTION:
 # Set to 'no' to disable automatically adding to DEPEND.  This lets
 # ebuilds form conditional depends by using ${AUTOTOOLS_DEPEND} in
@@ -137,12 +150,14 @@ unset _automake_atom _autoconf_atom
 # @DESCRIPTION:
 # Additional options to pass to automake during
 # eautoreconf call.
+: ${AM_OPTS:=}
 
 # @ECLASS-VARIABLE: AT_NOEAUTOHEADER
 # @DEFAULT_UNSET
 # @DESCRIPTION:
 # Don't run eautoheader command if set to 'yes'; only used to work around
 # packages that don't want their headers being modified.
+: ${AT_NOEAUTOHEADER:=}
 
 # @ECLASS-VARIABLE: AT_NOEAUTOMAKE
 # @DEFAULT_UNSET
@@ -150,6 +165,7 @@ unset _automake_atom _au

Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?

2021-03-27 Thread James Le Cuirot
On Sat, 27 Mar 2021 17:43:34 -0400
Joshua Kinard  wrote:

> I kinda wish the Linux kernel had an ability to partially boot, init the
> networking subsystem, then fetch an initramfs image over TFTP like it can do
> with NFS Root.  That would solve the problem on my MIPS system(s) (and make
> install netboots better).  I've dug around, but this does not seem to be a
> capability currently in the kernel, unless I have over looked something.
> 
> Otherwise in the future, I may just have to setup an initramfs into an NFS
> Root and teach the SGI's to somehow deal with it.  Which all still seems
> unnecessarily complicated because some other distro thinks it knows what's
> best for everyone else (but I digress...).

NBD may be a slightly simpler alternative and a bit more like an
initramfs. nbdkit can do all sorts of weird things. I thought it might
have a plugin for cpio archives, allowing you to use a regular
initramfs generated by Dracut or similar directly. It doesn't appear to
but plugins are quite easy to write. Alternatively you could just
extract the initramfs and use nbdkit-linuxdisk-plugin.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpGX8oMTiAmr.pgp
Description: OpenPGP digital signature


[gentoo-dev] Last-rites: oasis.eclass

2021-03-22 Thread Sam James
oasis.eclass: mark as @DEAD (last-rite eclass)

Removal on 2021-04-05 when the rest of the Oasis packages, including
Oasis (dev-ml/oasis) is removed.

There's no point in keeping the eclass when Oasis itself is gone and nothing
should be able to use this right now anyway due to the large number of packages
which have been removed and conflicts with e.g. jbuilder and Dune.

(Even if something IS using this, they *really* shouldn't be by now, and the 
vast
majority - if not all - of their packages would have been from outside ::gentoo,
as Oasis and friends have not been usable in the tree for at least a year.)

Please port to newer opam or dune.

Bug: https://bugs.gentoo.org/775785
Bug: https://bugs.gentoo.org/497044
Bug: https://bugs.gentoo.org/637826


signature.asc
Description: Message signed with OpenPGP


Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?

2021-03-21 Thread James Le Cuirot
On Sun, 21 Mar 2021 05:18:52 +0100
Ulrich Mueller  wrote:

> >>>>> On Sat, 20 Mar 2021, William Hubbs wrote:  
> 
> > /etc/localtime should definitely be a symlink to the proper file in
> > /usr/share/zoneinfo.  
> 
> > This works fine if /usr is on a separate partition *and* you are using
> > an initramfs. The only time it doesn't work is if /usr is separate
> > without using an initramfs.  
> 
> > Council decided years ago that we don't support separate /usr without
> > an initramfs, but we haven't completed that transition yet.  
> 
> Which doesn't imply that we deliberately break things.

How about making emerge --config dynamic, copying if it's on a
different partition and symlinking if it's not? You can't accurately
determine the use of an initramfs but at least this is closer to what
we want.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgppd9SmOxjcX.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] gstreamer-meson.eclass: New eclass required for gstreamer-1.18.0+

2021-03-16 Thread Sam James


> On 17 Mar 2021, at 01:49, Haelwenn (lanodan) Monnier  
> wrote:
> 
> Gstreamer switched to meson in 1.16.0 and removed autotools support in 1.18.0,
> this eclass is an update of gstreamer.eclass.
> 
> [snip]

Thanks for working on this!

> +#
> +# GStreamer consuming applications should depend on the specific plugins
> +# they need as defined in their source code. Usually you can find that
> +# out by grepping the source tree for 'factory_make'. If it uses playbin
> +# plugin, consider adding media-plugins/gst-plugins-meta dependency, but
> +# also list any packages that provide explicitly requested plugins.
> +
> +inherit eutils multilib meson multilib-minimal toolchain-funcs versionator 
> xdg-utils

Do we need eutils here?

> +
> +case "${EAPI:-0}" in
> + 5|6)
> + ;;
> + 0|1|2|3|4)
> + die "EAPI=\"${EAPI:-0}\" is not supported anymore"
> + ;;
> + *)
> + die "EAPI=\"${EAPI}\" is not supported yet"
> + ;;
> +esac

EAPI 7?

> [snip]

> +
> +# Even though xz-utils are in @system, they must still be added to DEPEND; 
> see
> +# 
> https://archives.gentoo.org/gentoo-dev/msg_a0d4833eb314d1be5d5802a3b710e0a4.xml
> +if [[ ${GST_TARBALL_SUFFIX} == "xz" ]]; then
> + DEPEND="${DEPEND} app-arch/xz-utils"
> +fi
> +

BDEPEND in EAPI 7.

> [snip]

> +DEPEND="
> + >=sys-apps/sed-4
> + >=virtual/pkgconfig-0-r1[${MULTILIB_USEDEP}]
> +"
> +

BDEPEND in EAPI 7.

> [snip]
> +else
> + IUSE="nls"
> + DEPEND="${DEPEND} nls? ( >=sys-devel/gettext-0.17 )"

BDEPEND in EAPI 7 unless we’re really building against gettext.
> 
> +
> +read -d '' __MESON_EXTRACT_TARGET_FILENAME <<"EOF"
> +import json
> +import sys
> +
> +with open("meson-info/intro-targets.json", "r") as targets_file:
> + data = json.load(targets_file)
> +
> +for i in range(len(data)):
> + target = data[i]
> + if target['installed']:
> + if sys.argv[1] in target['filename'][0]:
> + print(target['filename'][0] + ':' + 
> target['install_filename'][0])
> +EOF
> +

It seems kind of odd to me to do this in global scope.

> +# @FUNCTION: _gstreamer_get_target_filename
> +# @INTERNAL
> +# @DESCRIPTION:
> +# Extracts build and target filenames from meson-data for given submatch
> +_gstreamer_get_target_filename() {
> + python -c "${__MESON_EXTRACT_TARGET_FILENAME}" "$@"
> +}

|| die on external commands. We probably want ${EPYTHON} and to use
a Python eclass here.

> +
> +# @FUNCTION: gstreamer_multilib_src_compile
> +# @DESCRIPTION:
> +# Compiles requested gstreamer plugin.
> +gstreamer_multilib_src_compile() {
> + local plugin_dir plugin
> +
> + for plugin_dir in ${GST_PLUGINS_BUILD_DIR} ; do

“${GST_PLUGINS_BUILD_DIR}"

> + plugin=$(_gstreamer_get_target_filename 
> $(gstreamer_get_plugin_dir ${plugin_dir}))
> + plugin_path="${plugin%%:*}"
> + eninja "${plugin_path/"${BUILD_DIR}/"}"

No need for double quoting?

> +# @FUNCTION: gstreamer_multilib_src_install_all
> +# @DESCRIPTION:
> +# Installs documentation for requested gstreamer plugin, and removes .la
> +# files.
> +gstreamer_multilib_src_install_all() {
> + local plugin_dir
> +
> + for plugin_dir in ${GST_PLUGINS_BUILD_DIR} ; do
> + local dir=$(gstreamer_get_plugin_dir ${plugin_dir})
> + [[ -e ${dir}/README ]] && dodoc "${dir}"/README
> + done
> +
> + prune_libtool_files --modules

Deprecated in newer EAPIs, let’s do it manually.

> +}
> --
> 2.26.2
> 
> 



signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] Last rites: various old dev-ml/* packages stuck on oasis.eclass

2021-03-14 Thread Sam James
# Sam James  (2021-03-13)
# Stuck on oasis.eclass, out of date
# No reverse dependencies
# bug #775785
# Removal in 14 days. Nothing should really
# be able to use any of these right now anyway.
dev-ml/qcheck
dev-ml/macaque
dev-ml/pgocaml
dev-ml/csv
dev-ml/gen
dev-ml/tyxml
dev-ml/stringext
dev-ml/deriving
dev-ml/type-conv
dev-ml/optcomp
dev-ml/lwt_react
dev-ml/batteries
dev-ml/ocaml-magic-mime
dev-ml/iTeML
# Stuck on old oasis.eclass
# bug #749696, #711414
dev-ml/ocaml-re
# Dependencies of Oasis itself
dev-ml/ocamlify
dev-ml/ocamlmod
dev-ml/ocaml-expect
dev-ml/oasis
# Please port your applications to dev-ml/ounit2
# Should be a case of just a sed in most cases
dev-ml/ounit


signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] Begging notice: please mark your packages as ALLARCHES

2021-03-11 Thread Sam James
Hi,

Please mark your package as ALLARCHES if at all possible.

The  metadata.xml tag indicates to arch teams
that the package is architecture independent and therefore testing on one
architecture is sufficient.

You can read more in the devmanual:
https://devmanual.gentoo.org/keywording/#simultaneous-stabilization-on-all-architectures.

We should do this even if your package is pure ~arch to simplify
matters if it becomes a dependency or included in a stable request in future.

It only takes a few minutes to check if your package is compiling anything
or installing e.g. ELF files but can save arch teams a lot of time.

Proactively doing this is a huge help and I’d be really grateful if maintainers
could take the time to do this.

Generally, unless the package seems somehow special, I wouldn’t
restrict yourself to marking only your own packages ALLARCHES either.

Tips:
1) If you don’t know, ask somebody! Email me or ask in e.g. #gentoo-dev on IRC.

2) Python packages are generally ALLARCHES, see the wiki:
https://wiki.gentoo.org/wiki/Project:Python#ALLARCHES

3) Perl packages don’t count. Technically, some COULD, but due to
prominent usage of e.g. unpack() throughout the ecosystem, it’s best
not to risk it for now. We may find a better way to check for problematic
functions in future.

4) graaff has advised that Ruby is in a similar situation. Far too often
both Perl and Ruby end up exposing system internals.

Thanks!
Sam



signature.asc
Description: Message signed with OpenPGP


Re: [gentoo-dev] Urgent reminder to port your packages to Python 3.8 and Python 3.9

2021-03-11 Thread Sam James


> On 3 Mar 2021, at 22:55, Sam James  wrote:
> 
> Hi,
> 
> We still have ~31 packages still not declaring support for newer Python 3 
> targets than Python 3.7,
> we have ~1085 packages still not declaring support for newer Python 3 targets 
> than Python 3.8 (i.e.
> Python 3.9).

Thanks to everyone who ported in response!

> Please review this list to see if your packages are stuck on Python 3.7:
> http://qa-reports.gentoo.org/output/gpyutils/37-to-38.txt

We’re now on ~27.

> 
> Please review this list to see if your packages are stuck on Python 3.8:
> http://qa-reports.gentoo.org/output/gpyutils/38-to-39.txt

We’re now on ~1012.

> 
> This list contains maintainer names, so it’s easy to tell if you need to act.
> 
> The default Python target in profiles was switched from Python 3.7 to Python 
> 3.8
> at the beginning of December. A news item still needs to be created [0].
> 
> Your package not supporting the latest targets makes it harder for other 
> packages
> to do so. In particular, packages not supporting even the default target (now 
> Python 3.8)
> means that users have a difficult time installing it.
> 
> Previous warnings have been sent about this including in November [1]. mgorny 
> sent
> this [2] RFC regarding an impeding switch of the default to Python 3.9 too.
> 
> TL;DR:
> * Please port your packages to Python 3.8 (already default) and Python 3.9 
> ASAP.
> * Packages supporting Python 3 but not newer versions may be last-rited.
> 
> [0] https://bugs.gentoo.org/771165
> [1] 
> https://archives.gentoo.org/gentoo-dev/message/f1e452d0a54d5347d9f867478b2604c4
> [2] 
> https://archives.gentoo.org/gentoo-dev/message/ba2fc4854ed6bb49813819ae6f5e9552



signature.asc
Description: Message signed with OpenPGP


Re: [gentoo-dev] [News item review] V2 Chromium access to Google services

2021-03-08 Thread Sam James



> On 8 Mar 2021, at 19:01, Stephan Hartmann  wrote:
> 
> Hi,

Hi!

Review from mobile so please excuse non-ideal formatting.


> 
> updated based on previous suggestions.
> 
> ```
> Title: Chromium access to Google services
> Author: Stephan Hartmann 
> Content-Type: text/plain
> Posted: 2021-03-09
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: www-client/chromium
> 
> Starting March 15th, 2021 Google Chrome Team will restrict access to

From March 15th 2021, Google’s Chrome team will be restricting access to...

> Google APIs and services that are reserved for Google use only. This
> means that users are no longer able to login into

users of?

> their Google Accounts
> which disables access to for example Chrome Sync.
> 

Access to e.g Chrome Sync and ... will be affected.

> As a consequence we have to remove Client ID and secret from all
> www-client/chromium ebuilds.

As a consequence, we must remove both the Client ID and secret(s) from the 
www-client/chromium ebuilds in Gentoo.

> This change has already been done for
> =www-client/chromium-89.0.4389.82.

This change has already been made for...

> Other versions will be updated
> shortly.
> 
> If you need one of the Google use only APIs, then you either have to

If you need to use one of these Google-only APIs. then you either have to...

1) ...

> switch to www-client/google-chrome{-beta,-unstable}

Or

2)
> setup your own
> keys [1]. However, the latter is only intended for development.
> Documentation on how to generate and use own keys can be found in [2].
> 
> [1] 
> https://groups.google.com/a/chromium.org/g/chromium-dev/c/jgy5pcJ7np8/m/p3j_4b6vBQAJ
> [2] https://www.chromium.org/developers/how-tos/api-keys
> ```
> 
> Best regards,
> 
> Stephan
> 



[gentoo-dev] Packages up for grabs: app-emulation/fuse app-emulation/fuse-utils app-emulation/libspectrum

2021-03-05 Thread Sam James
Hi,

Following the retirement of a proxy maintainer, as their request, we have the 
following packages up for grabs:
app-emulation/fuse
app-emulation/fuse-utils
app-emulation/libspectrum

Thanks!


signature.asc
Description: Message signed with OpenPGP


Re: [gentoo-dev] [RFC] Dropping PyPy(3) back to ~arch

2021-03-03 Thread Sam James

> On 2 Mar 2021, at 15:05, Michał Górny  wrote:
> 
> Hi,
> 
> I think I've made a mistake by stabilizing PyPy(3), and I would like to
> drop it back to ~arch (and stable-mask the relevant flags).
> 
> Roughly, there are 4 problems with it:
> 
> [snip]

> Honestly, I've tried to improve PyPy in the past but I don't really have
> time or motivation to do this continuously.  PyPy is an interesting
> project, and it has its isolated uses.  However, I don't think it's
> ready as a general-purpose Python interpreter for production
> environments.
> 
> I don't really want to remove it entirely or revert all the work we've
> put into testing packages with it -- but I think we should move it to
> ~arch at the very least.

It’s unfortunate but no objections. News item may be worthwhile
to explain to users why & how for posterity, but not necessary.



signature.asc
Description: Message signed with OpenPGP


Re: [gentoo-dev] Urgent reminder to port your packages to Python 3.8 and Python 3.9

2021-03-03 Thread Sam James

> On 3 Mar 2021, at 22:55, Sam James  wrote:
> 
> Hi,
> 
> We still have ~31 packages still not declaring support for newer Python 3 
> targets than Python 3.7,
> we have ~1085 packages still not declaring support for newer Python 3 targets 
> than Python 3.8 (i.e.
> Python 3.9).

Further to this, if you know you aren’t interested anymore in one of your 
packages on these lists, please last-rite
it rather than waiting for somebody to.

> 
> Please review this list to see if your packages are stuck on Python 3.7:
> http://qa-reports.gentoo.org/output/gpyutils/37-to-38.txt
> 
> Please review this list to see if your packages are stuck on Python 3.8:
> http://qa-reports.gentoo.org/output/gpyutils/38-to-39.txt

> [snip]


signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] Last rites: app-office/moneyguru

2021-03-03 Thread Sam James
# Sam James  (2021-03-03)
# Declared abandoned upstream and stuck
# on Python 3.7.
# Removal in 30 days.
app-office/moneyguru



signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] Urgent reminder to port your packages to Python 3.8 and Python 3.9

2021-03-03 Thread Sam James
Hi,

We still have ~31 packages still not declaring support for newer Python 3 
targets than Python 3.7,
we have ~1085 packages still not declaring support for newer Python 3 targets 
than Python 3.8 (i.e.
Python 3.9).

Please review this list to see if your packages are stuck on Python 3.7:
http://qa-reports.gentoo.org/output/gpyutils/37-to-38.txt

Please review this list to see if your packages are stuck on Python 3.8:
http://qa-reports.gentoo.org/output/gpyutils/38-to-39.txt

This list contains maintainer names, so it’s easy to tell if you need to act.

The default Python target in profiles was switched from Python 3.7 to Python 3.8
at the beginning of December. A news item still needs to be created [0].

Your package not supporting the latest targets makes it harder for other 
packages
to do so. In particular, packages not supporting even the default target (now 
Python 3.8)
means that users have a difficult time installing it.

Previous warnings have been sent about this including in November [1]. mgorny 
sent
this [2] RFC regarding an impeding switch of the default to Python 3.9 too.

TL;DR:
* Please port your packages to Python 3.8 (already default) and Python 3.9 ASAP.
* Packages supporting Python 3 but not newer versions may be last-rited.

[0] https://bugs.gentoo.org/771165
[1] 
https://archives.gentoo.org/gentoo-dev/message/f1e452d0a54d5347d9f867478b2604c4
[2] 
https://archives.gentoo.org/gentoo-dev/message/ba2fc4854ed6bb49813819ae6f5e9552


signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] Begging notice: always CC all arches which are currently stable on your package

2021-03-03 Thread Sam James
Hi,

This is a friendly reminder that you should CC arch teams *for all arches which 
currently have a stable keyword for your package*. NATTkA
handles this for you (see my other email [0]), but if you decide to not use it, 
please be sure you do CC all arches for which the previous
stable version had stable keywords.

The point of arch teams is to test on their platform. Of course, if you become 
aware that upstream have made serious changes to support for
a certain arch, you may want to speak to a member of the arch team and drop the 
keyword *and request rekeywording* or similar.

You do not need to be a e.g. HPPA fan or user in order to continue 
stabilisation on that platform. Let the arch team do their job.

[Of course, exceptions apply if we’ve decided to discontinue support (like the 
package can’t work on e.g. SPARC after a certain release for sure),
but in such a case, please check with somebody to ensure it looks like the 
right thing to do, if you’re not sure.]

[0] 
https://archives.gentoo.org/gentoo-dev/message/cd62f6be924f6a0f76b68a07d33b256a

Thanks,
sam


signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] Begging notice: please use NATTkA / CC-ARCHES for keywording/stabilisation bugs

2021-03-03 Thread Sam James
Hi,

This is a begging notice to ideally use NATTkA if possible for your keywording 
or stabilisation bugs!

[If you don’t know what to do, I hereby give you permission to nag me and ask 
me to check each one
of your bugs to let you know if it’s working okay and if it’s all gone alright. 
New tools are sometimes
hard to get used to, and I’ll help! CC me on your bugs or ping me on IRC.]

HOWTO:
1) Populate the ‘Package List’ field on Bugzilla, using the * (‘copy previous 
stable keywords’) and ^ (copy above line keywords) as appropriate.
2) Add ‘CC-ARCHES’ to the keywords field on Bugzilla to automatically CC the 
appropriate arch teams.

ADVANTAGES:
1) NATTkA will automatically CC the *correct* arch teams if you populate the 
package list with an asterisk, like so:
```
app-misc/foo *
```

This will copy the last set of stable keywords for app-misc/foo and apply them 
here. It then CCs the appropriate arch teams.

This helps a lot with avoiding accidental dropping of arches, if you’ve copied 
and pasted the list. It only has to happen a few times a month for it to become
a pain later on when it comes to cleaning up old versions.

[If you manually CC arches and used ‘CC-ARCHES’, be aware that NATTkA **WILL 
NOT** override your wishes, and will take
what you said as gospel. So, please avoid doing this unless you’re 100% sure 
you got it right. Or just don’t bother and use
CC-ARCHES so we can be sure.]

2) By using the CC-ARCHES keyword, arch teams aliases are not spammed with bugs 
which aren’t yet ready (passing the sanity check).

It’s a waste of time for us to try test bugs which cannot be committed yet 
because of breakages in the depgraph.

—
NATTkA is not mandatory in the sense that you can manually construct a package 
list but using it (by filling out the package list)
is mostly unavoidable given the sanity-check field should be set by a bot. 
Manually tampering with this is harmful.

You can read more at:
* the main documentation - 
https://dev.gentoo.org/~mgorny/doc/nattka/intro.html#primary-features
* GitHub - https://github.com/mgorny/nattka
* Original announcements by mgorny:
1) 
https://archives.gentoo.org/gentoo-dev/message/b71fc507d5e017569d7ba385e257afe4
2) 
https://archives.gentoo.org/gentoo-dev/message/e7eb47e3395c18bd98f25e90aabfc816


signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] Re: [gentoo-dev-announce] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

2021-03-03 Thread Sam James

> On 2 Mar 2021, at 03:54, Matt Turner  wrote:
> 
> tl;dr: In app-portage/gentoolkit-0.5.1 there's a new tool I wrote,
> called merge-driver-ekeyword that can automatically resolve git merge
> conflicts involving the KEYWORDS=... line in ebuilds.
> 

Thanks a lot for your work here, Matt! It’s something that’s
proven genuinely helpful in day-to-day work and solves
an actual problem during arch testing.

This is a great improvement on the status quo and obviously this isn’t
the place to bikeshed over the ebuild format.

> [snip]

Best,
Sam


signature.asc
Description: Message signed with OpenPGP


Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

2021-03-01 Thread Sam James

> On 2 Mar 2021, at 05:10, Michael Orlitzky  wrote:
> 
> On Mon, 2021-03-01 at 22:54 -0500, Matt Turner wrote:
>> tl;dr: In app-portage/gentoolkit-0.5.1 there's a new tool I wrote,
>> called merge-driver-ekeyword that can automatically resolve git merge
>> conflicts involving the KEYWORDS=... line in ebuilds.
>> 
>> Since the KEYWORDS=... assignment is a single line,
> 
> Is that enforced? If not, will the merge driver handle other formats
> correctly? And if it is... why don't we just enforce putting each
> keyword on a separate line instead, so that we don't have this problem
> in the first place?

Yeah, it’s policy: 
https://projects.gentoo.org/qa/policy-guide/ebuild-format.html#pg0105.

I also removed all of the trivial infringers not long ago: 
https://github.com/gentoo/gentoo/pull/19467. There
aren’t many left.

Anyway, yes, the format is still a pain because diff doesn’t handle it well. 
But I don’t really want
to see ebuilds become longer...

sam



signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] Last rites: games-strategy/0ad-data

2021-03-01 Thread Sam James
# Sam James  (2021-02-28)
# games-strategy/0ad-data has been merged
# into games-strategy/0ad for simplicity.
# Note that in most cases, the latter uses
# upstream pre-built assets anyway.
# Nothing should really be using this.
# bug #735352, bug #768930
# Removal in 14 days.
games-strategy/0ad-data



signature.asc
Description: Message signed with OpenPGP


Re: [gentoo-dev] Non-maintainer commits and CI

2021-03-01 Thread Sam James

> On 7 Jan 2021, at 14:28, Agostino Sarubbo  wrote:
> 
> Hello,
> 
> it happens frequently that CI discovers failure(s) in non-maintainer commits.
> 
> The most striking examples are maintainer-needed, proxy-maint and general pull
> request where who made the change has no visibility on the new bug.
> 
> Do you think that is a good idea to CC everyone involved in the commit?
> 

Hi all,

Following up on this, ago has implemented this after I brought it up to him - 
thank you ago!

The committer will be CCed on bugs and upon requests this can be disabled where 
maintainer is a member
of a project alias (to avoid receive mail from both herd and CC).

If needed, we could revisit this and turn it into a whitelist or something, but 
for now,
the aim is to just blacklist “alive” projects where people read the alias.

Best,
Sam


signature.asc
Description: Message signed with OpenPGP


Re: [gentoo-dev] pkgdev: an alternative to `repoman commit`

2021-02-27 Thread Sam James


> On 27 Feb 2021, at 14:50, Tim Harder  wrote:
> 
> Hi all,
> 
> Finally responding to all the requests, I've hacked up an initial
> alternative to repoman's commit functionality in the form of pkgdev [1]
> that uses pkgcheck's API behind the scenes. The project is meant to grow
> into a collection of tools for Gentoo development and maintenance, but
> initially supports `pkgdev commit` and `pkgdev push` that should work
> for a basic git workflow on ebuild repos.

Thank you! Already using it.

> [snip]
> 
> Feel free to respond with questions, ideas, or flames. If you want to
> give it a shot, I believe a live ebuild for it has already been added to
> the tree at dev-util/pkgdev. Also, please open issues on the upstream
> project if you run into bugs or have feature requests.

Yes, please let me know if there’s any issues with the ebuild too.

I’ll add a tagged release once it’s made, obviously.

> 
> Thanks,
> Tim
> 
> [1]: https://github.com/pkgcore/pkgdev
> 



signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] Last rites: media-gfx/openexr_viewers

2021-02-27 Thread Sam James
# Bernd Waibel  (2021-02-27)
# No longer actively supported upstream.
# Removal needed to clean-up {ilmbase,openexr}-2.3.0
# Masked for removal in 30 days.
media-gfx/openexr_viewers


signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] Last rites: sci-mathematics/ggnfs

2021-02-26 Thread Sam James
# Sam James  (2021-02-27)
# Fails to build with GCC 10 (or otherwise!)
# bug #708508, bug #728026, bug #542280
# Removal in 30 days
sci-mathematics/ggnfs



signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] Last rites: dev-lang/ats

2021-02-26 Thread Sam James
# Sam James  (2021-02-27)
# Fails to build with GCC 10, out of date.
# bug #723192, bug #737058
# Removal in 30 days
dev-lang/ats


signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] Last rites: dev-scheme/greg

2021-02-26 Thread Sam James
# Sam James  (2021-02-27)
# Broken with newer(?) dev-scheme/guile, dead upstream
# bug #642736, bug #773196
dev-scheme/greg


signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] Re: [gentoo-dev-announce] Packages up for grabs: innoextract, emech, tigervnc, urxvtconfig

2021-02-21 Thread James Le Cuirot
On Sun, 21 Feb 2021 15:54:39 +0200
Joonas Niilola  wrote:

> Hey,
> 
> here are some packages up-for-grabs due to retirement of their maintainers.
> b = bugs open, v = version bump available.
> 
> app-arch/innoextract

I'll take this.

> net-irc/emech (b)
> net-misc/tigervnc (b)
> x11-misc/urxvtconfig (b)

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpCz9mh0ZV9G.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] verifying profiles/package.mask comment format

2021-02-20 Thread Sam James

> On 21 Feb 2021, at 04:30, Tim Harder  wrote:
> 
> Hi all,
> 
> Is there interest in enforcing some basic QA for the semi-formatted
> comments in profiles/package.mask (and possibly other profiles file
> types)? I have code implementing the basic functionality done for
> pkgcheck, but wondered if the format should be standardized and
> documented more than it may be already before support is merged.
> 

I definitely have interest in this. Every so often, I find a class of mistakes
like incorrectly-ordered masks, wrong email format, and so on, and fix
them in the area I’m touching as it’s cheap to fix whatever file I’m on -
not necessarily so to fix every single one in profiles/.

This also gives us scope to make requirements like e.g. a bug reference,
clear date for removal if last-rites, and generally be a bit more verbose
by making clear what the expectations are for message content.

(There is a clear benefit for last-rites having at least one bug — it gives
users a chance to object or mention alternatives.)

Anyway, not trying to bikeshed re last-rites process, I just mean there’s
definitely a collection of uses here. Thanks for working on it.

Note that this was brought up last month too by jstein, so there is definitely 
other
interest: 
https://archives.gentoo.org/gentoo-dev/message/0600146362529770aa88225b29de46ae.

> Also, I'm unsure it's been noticed but `pkgcheck scan --commits` now
> verifies any profile changes done in git commits so this support would
> automatically get run for package.mask changes (and other enabled files)
> when using pkgcheck locally in that fashion.
> 
> Thanks,
> Tim
> 



signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] [RFC] Dropping s390 (but not s390x) entirely and s390, s390x to ~arch.

2021-02-16 Thread Sam James
Hi all,

I have two linked proposals:
1) I propose we remove support for Gentoo on s390 and support only s390x 
instead;
2) We drop the s390 arch (covering both s390 and s390x) keywords to ~s390 
(unstable).

Right now, we support both s390 and s390x with the same keyword (’s390’) but 
s390x has a subprofile.
No separate keyword exists.

In reality, this means all packages should be tested on s390 (lowest common 
denominator).

This has some limitations:
* upstreams aren’t particularly interested in the 31/32 bit platform that is 
the original s390;

* Following on from That Cryptography Debacle, upstream Python and others may 
be looking
  to drop s390 support anyway;

* s390 is not supported by e.g. libpcre for JIT. Ditto LaTeX which means we 
have to
  mask a lot of documentation. It’s not a huge deal but it shows how little 
attention folks pay to it,

I’d like to make clear that this isn’t a knee-jerk response to recent events 
with the Python ecosystem;
we have a limited amount of time and volunteers and I don’t recall seeing a bug 
report from an s390 user
any time recently. Further, nobody other distros seem to be carrying s390 (only 
s390x).

(On the recent dev-python/cryptography bug upstream, it was claimed s390 isn't 
supported by the kernel,
but I can't find any evidence for this, so let's not base any decisions on that 
unless
some evidence arises.)

I tried to review old bugs and most were from Gentoo developers testing the 
platform, but I accept
it may have had more relevance in the past. We’ve not even built stages for it 
in a year and nobody
seems to have noticed.

Motivation:
* I'm the only person actively doing keywording and stabilisation for s390 and 
find it hard to keep up -
reducing the workload would be helpful for me but also motivate me in terms of 
reporting issues when
there's actually likelihood of it being fixed vs for a (thought to be) dead 
platform.

* I’d prefer it if we only declared support for things we can support *well*. 
I’d say s390 isn’t currently
in this category and at least having s390x as the target is a bit more 
realistic.

* We’re not really consistent with what is/isn’t stable for s390 at present 
anyway, hence the profiles
are dev/exp.

* We’re going to have a headache with certain things like Rust and it’s an 
opportunity to assess
what we’re supporting/not and ideally limiting our efforts to realistic & 
worthwhile targets.

In any case, I’m not trying to kill off platforms people are using, so:
1) If anybody is using this, please tell us!

2) I’m quite happy (as well as others I’ve spoken with) to keep s390x which is 
more well-accepted as a platform and is
still in circulation.

Thanks,
Sam


signature.asc
Description: Message signed with OpenPGP


Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390

2021-02-08 Thread Sam James

> On 8 Feb 2021, at 11:19, Michał Górny  wrote:
> 
> Hi,
> 
> FYI the developers of dev-python/cryptography decided that Rust is going
> to be mandatory for 1.5+ versions.  It's unlikely that they're going to
> provide LTS support or security fixes for the old versions.
> 
> Since cryptography is a very important package in the Python ecosystem,
> and it is an indirect dependency of Portage, this means that we will
> probably have to entirely drop support for architectures that are not
> supported by Rust.
> 

It seems that there was no mention of this in release notes or the changelog -
neither to warn packagers or consult with them for their views on this, which 
would’ve
been the best place to do so.

> [snip]
> 
> Furthermore, the Gentoo Rust packages are missing support
> for the following platforms, apparently supported upstream:
> - mips (exp)
> - ppc (32) (stable)
> - sparc (stable)
> - s390x (exp)
> - riscv (stable)

We also need to add support for armv4/armv5.

> 
> Apparently it's non-trivial to bootstrap Rust on these platforms,
> so it's unclear when Gentoo is going to start providing Rust on them.
> 
> [snip]

Filed a Gentoo bug too: https://bugs.gentoo.org/769482.

> [1] https://doc.rust-lang.org/nightly/rustc/platform-support.html
> [2] https://github.com/pyca/cryptography/issues/5771
> 
> --
> Best regards,
> Michał Górny
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP


Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390

2021-02-08 Thread James Le Cuirot
On Mon, 08 Feb 2021 12:19:13 +0100
Michał Górny  wrote:

> Hi,
> 
> FYI the developers of dev-python/cryptography decided that Rust is going
> to be mandatory for 1.5+ versions.  It's unlikely that they're going to
> provide LTS support or security fixes for the old versions.
> 
> 
>
> Honestly, I don't think it likely that Rust will gain support for these
> platforms.  This involves a lot of work, starting with writing a new
> LLVM backend and getting it accepted (getting new code into LLVM is very
> hard unless you're doing that on behalf one of the big companies).  You
> can imagine how much effort that involves compared to rewriting the new
> code from Cryptography into C.

I do know that there is ongoing work to get Rust going on m68k but it's
very slow and I'm not entirely confident they'll get there. At least I
don't have this package on my m68k system!

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpEXub3MDL7c.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] GTK:2 EOL and incoming migration to GTK:3

2021-02-08 Thread Sam James

> On 8 Feb 2021, at 00:52, Aisha Tammy  wrote:
> 
> Hi all,
> [snip]
> This transition is expected to take a long time so there shouldn't be a worry 
> about sudden
> changes in packages. We are going to keep some of the more important old 
> GTK:2 ebuilds,
> such as the CJK ebuilds, around as long as we have GTK:2 in the tree. Newer 
> packages are
> encouraged to be GTK:3 only.
> The starting point of the transition are packages which have GTK:3 support 
> and optional GTK:2
> support. Most of the bugs of this kind have already been filed[1] and is the 
> safest
> place to start killing off GTK:2.

This is completely fair, but I’d just like to add that dropping GTK 2 should 
ideally be done in revbumps
and given time before stabilisation & cleanup to ease the pain for users.

Yes, it’s been a long time coming, and this is only the first step, but some 
people have a sentimental
attachment to it, so we should give them time to get used to the new interfaces 
rather than yanking
it entirely from all versions in the tree where it’s possible.

TL;DR: Great, let’s just not rush to cleanup old so people can revert if issues 
arise with new designs
or whatever in the GUI.

> 
> Best,
> Aisha
> 
> [1] https://blog.gtk.org/2020/12/16/gtk-4-0/
> [2] https://bugs.gentoo.org/768993
> 
> 



signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] Package up for grabs: media-gfx/frogr

2021-02-01 Thread Sam James
Hello,

Packages up for grabs due to the retirement of sobhan@:
media-gfx/frogr

It has 1 open bug and a version bump pending according to Repology.

Thanks!
Sam


signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] Package up for grabs: x11-misc/i3blocks

2021-02-01 Thread Sam James
Hello,

Packages up for grabs due to the retirement of mudler@:
x11-misc/i3blocks

No open bugs and no version bump pending.

Thanks!
Sam


signature.asc
Description: Message signed with OpenPGP


Re: [gentoo-dev] Packages up for grabs

2021-01-17 Thread Sam James


> On 17 Jan 2021, at 09:26, Michał Górny  wrote:
> 
> Hello,
> 
> The following packages are in need of a new maintainer due to their
> current maintainer being MIA:
> 
> […]
> [  ] app-admin/stow

Adopted the wonderful stow, but I’ll leave xstow for others.

> [Bv] app-admin/xstow

Thanks,
Sam



signature.asc
Description: Message signed with OpenPGP


Re: [gentoo-dev] [PATCH] eclass/lua-utils.eclass: remove EPREFIX from exported module paths

2021-01-13 Thread James Le Cuirot
On Mon, 11 Jan 2021 11:01:33 -0600
William Hubbs  wrote:

> Bug: https://bugs.gentoo.org/762769
> Signed-off-by: William Hubbs 
> ---
>  eclass/lua-utils.eclass | 23 ++-
>  1 file changed, 18 insertions(+), 5 deletions(-)
> 
> diff --git a/eclass/lua-utils.eclass b/eclass/lua-utils.eclass
> index 100be14cb08..9fe4d22e93f 100644
> --- a/eclass/lua-utils.eclass
> +++ b/eclass/lua-utils.eclass
> @@ -212,8 +212,9 @@ _lua_get_library_file() {
>   die "Invalid implementation: ${impl}"
>   ;;
>   esac
> - libdir=$($(tc-getPKG_CONFIG) --variable libdir ${impl}) || die
>  
> + libdir=$($(tc-getPKG_CONFIG) --variable libdir ${impl}) || die
> + 
>   debug-print "${FUNCNAME}: libdir = ${libdir}, libname = ${libname}"
>   echo "${libdir}/${libname}"
>  }
> @@ -274,6 +275,7 @@ _lua_export() {
>   local val
>  
>   val=$($(tc-getPKG_CONFIG) --variable 
> INSTALL_CMOD ${impl}) || die
> + val="${val#${ESYSROOT#${SYSROOT}}}"
>  
>   export LUA_CMOD_DIR=${val}
>   debug-print "${FUNCNAME}: LUA_CMOD_DIR = 
> ${LUA_CMOD_DIR}"
> @@ -282,6 +284,7 @@ _lua_export() {
>   local val
>  
>   val=$($(tc-getPKG_CONFIG) --variable includedir 
> ${impl}) || die
> + val="${val#${ESYSROOT#${SYSROOT}}}"
>  
>   export LUA_INCLUDE_DIR=${val}
>   debug-print "${FUNCNAME}: LUA_INCLUDE_DIR = 
> ${LUA_INCLUDE_DIR}"
> @@ -298,6 +301,7 @@ _lua_export() {
>   local val
>  
>   val=$($(tc-getPKG_CONFIG) --variable 
> INSTALL_LMOD ${impl}) || die
> + val="${val#${ESYSROOT#${SYSROOT}}}"
>  
>   export LUA_LMOD_DIR=${val}
>   debug-print "${FUNCNAME}: LUA_LMOD_DIR = 
> ${LUA_LMOD_DIR}"
> @@ -364,11 +368,14 @@ lua_get_CFLAGS() {
>  # @USAGE: []
>  # @DESCRIPTION:
>  # Obtain and print the name of the directory into which compiled Lua
> -# modules are installed, for the given implementation. If no implementation
> +# modules are installed for the given implementation. If no implementation
>  # is provided, ${ELUA} will be used.
>  #
> -# Please note that this function requires Lua and pkg-config installed,
> -# and therefore proper build-time dependencies need be added to the ebuild.
> +# Please note that this function requires Lua and pkg-config to be installed,
> +# and therefore proper build-time dependencies need to be added to the 
> ebuild.
> +#
> +# For prefix installations, this function does not include the offset in
> +# the path.
>  lua_get_cmod_dir() {
>   debug-print-function ${FUNCNAME} "${@}"
>  
> @@ -385,6 +392,9 @@ lua_get_cmod_dir() {
>  #
>  # Please note that this function requires Lua and pkg-config installed,
>  # and therefore proper build-time dependencies need be added to the ebuild.
> +#
> +# For prefix installations, this function does not include the offset in
> +# the path.
>  lua_get_include_dir() {
>   debug-print-function ${FUNCNAME} "${@}"
>  
> @@ -412,11 +422,14 @@ lua_get_LIBS() {
>  # @USAGE: []
>  # @DESCRIPTION:
>  # Obtain and print the name of the directory into which native-Lua
> -# modules are installed, for the given implementation. If no implementation
> +# modules are installed for the given implementation. If no implementation
>  # is provided, ${ELUA} will be used.
>  #
>  # Please note that this function requires Lua and pkg-config installed,
>  # and therefore proper build-time dependencies need be added to the ebuild.
> +#
> +# For prefix installations, this function does not include the offset in
> +# the path.
>  lua_get_lmod_dir() {
>   debug-print-function ${FUNCNAME} "${@}"
>  

That's better, thanks. I would go a step further though and add a note
to lua_get_shared_lib() to say that this *does* include the SYSROOT and
prefix. It is slightly odd that this differs from lua_get_include_dir()
but I cannot find any examples where lua_get_shared_lib() is used in an
install phase.

Can you confirm that following this, you will go around and correct all
the ebuilds that use lua_get_include_dir() ? I count around 21 of them.
As I said, ${ESYSROOT} should be prepended when it is used in a build
phase. luaexpat is a good example of it being used in both a build and
an install phase.

Note that all of this is still slightly broken by the difference
between dev-util/pkgconfig and dev-util/pkgconf but I'll resolve that
as soon as I can. Most users, including most prefix users, won't notice.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpMZXQy_kycK.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] ml project created

2021-01-13 Thread Sam James

> On 12 Jan 2021, at 19:24, Alfredo Tupone  wrote:
> 
> As I have interest on lot of ebuild on dev-ml, and most of them are not
> managed by any project, I have created a project to handle them.
> 

Thanks Alfredo, I’m in and I joined #gentoo-ml too.

> I have build https://wiki.gentoo.org/wiki/Project:Ml tring to revive
> an old ml project.
> 
> Any comments?

All we need now is a .NET / Mono revival ;)

> 
> Alfredo
> 



signature.asc
Description: Message signed with OpenPGP


Re: [gentoo-dev] Suggestion: Trying to locate and remove unused dev- & media-libs?

2021-01-08 Thread James Le Cuirot
On Fri, 8 Jan 2021 14:26:32 +0200
Joonas Niilola  wrote:

> dev-libs/libgcrypt-compat
> dev-libs/libpcre-debian

These are maintained by me and I'd like to keep them. They can be
pulled in by running the esteam tool in steam-overlay for games that
need them. They could potentially be used for other old or
Debian-oriented binary packages too.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgp25epsm8vEo.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] eclass/lua.eclass: remove EPREFIX from exported paths

2021-01-07 Thread James Le Cuirot
On Thu,  7 Jan 2021 17:13:09 -0600
William Hubbs  wrote:

> Bug: https://bugs.gentoo.org/762769
> Signed-off-by: William Hubbs 
> ---
>  eclass/lua-utils.eclass | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/eclass/lua-utils.eclass b/eclass/lua-utils.eclass
> index 100be14cb08..1e552da0848 100644
> --- a/eclass/lua-utils.eclass
> +++ b/eclass/lua-utils.eclass
> @@ -212,8 +212,10 @@ _lua_get_library_file() {
>   die "Invalid implementation: ${impl}"
>   ;;
>   esac
> - libdir=$($(tc-getPKG_CONFIG) --variable libdir ${impl}) || die
>  
> + libdir=$($(tc-getPKG_CONFIG) --variable libdir ${impl}) || die
> + libdir="${libdir#${ESYSROOT#${SYSROOT}}}"
> + 
>   debug-print "${FUNCNAME}: libdir = ${libdir}, libname = ${libname}"
>   echo "${libdir}/${libname}"
>  }
> @@ -274,6 +276,7 @@ _lua_export() {
>   local val
>  
>   val=$($(tc-getPKG_CONFIG) --variable 
> INSTALL_CMOD ${impl}) || die
> + val="${val#${ESYSROOT#${SYSROOT}}}"
>  
>   export LUA_CMOD_DIR=${val}
>   debug-print "${FUNCNAME}: LUA_CMOD_DIR = 
> ${LUA_CMOD_DIR}"
> @@ -282,6 +285,7 @@ _lua_export() {
>   local val
>  
>   val=$($(tc-getPKG_CONFIG) --variable includedir 
> ${impl}) || die
> + val="${val#${ESYSROOT#${SYSROOT}}}"
>  
>   export LUA_INCLUDE_DIR=${val}
>   debug-print "${FUNCNAME}: LUA_INCLUDE_DIR = 
> ${LUA_INCLUDE_DIR}"
> @@ -298,6 +302,7 @@ _lua_export() {
>   local val
>  
>   val=$($(tc-getPKG_CONFIG) --variable 
> INSTALL_LMOD ${impl}) || die
> + val="${val#${ESYSROOT#${SYSROOT}}}"
>  
>   export LUA_LMOD_DIR=${val}
>   debug-print "${FUNCNAME}: LUA_LMOD_DIR = 
> ${LUA_LMOD_DIR}"

NACK.

The _lua_get_library_file() result is used for lua_get_shared_lib() and
this appears to be always used when building, not when installing. In
that case, you want it to return the prefixed (and sysrooted) path or
callers should always prepend ${ESYSROOT}.

Similarly, lua_get_include_dir() is often used for building but is
sometimes used for installing too. luaexpat uses it for both! If this
is returned unprefixed then luaexpat and similar should prepend
${ESYSROOT} when building and ${ED} when installing. 

I did suggest that you explicitly whether the paths are prefixed or not
in the function descriptions so please do that.

As discussed, I'll get back to you on the other sysroot issue.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgp2lt1tHBLfK.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Non-maintainer commits and CI

2021-01-07 Thread Sam James

> On 7 Jan 2021, at 14:28, Agostino Sarubbo  wrote:
> 
> Hello,
> 
> it happens frequently that CI discovers failure(s) in non-maintainer commits.
> 
> The most striking examples are maintainer-needed, proxy-maint and general pull
> request where who made the change has no visibility on the new bug.
> 
> Do you think that is a good idea to CC everyone involved in the commit?
> 

Yes please, that’d be extremely helpful and I don’t see any reason not to from 
my POV.

I keep an eye on recently changed/new bugs out of habit, but this is a great
way to help avoid things being lost.


> 
> Agostino
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP


Re: [gentoo-dev] [PATCH] systemd.eclass: remove SYSROOT from pkg-config output

2021-01-06 Thread James Le Cuirot
On Mon, 4 Jan 2021 19:28:37 -0500
Mike Gilbert  wrote:

> On Mon, Jan 4, 2021 at 6:45 PM Mike Gilbert  wrote:
> >
> > On Mon, Jan 4, 2021 at 6:18 PM James Le Cuirot  wrote:  
> > > $ PKG_CONFIG_SYSROOT_DIR=/foo pkg-config --variable=udevdir udev
> > > /lib/udev
> > >
> > > The udevdir variable is not affected by PKG_CONFIG_SYSROOT_DIR at all.
> > > And why would it be? The man page says that this variable is only
> > > applied to -I and -L flags. I don't know for sure but I suspect that
> > > pkg-config just sees this as some arbitrary variable with no special
> > > path handling at all. I wonder what led you to think that this fix was
> > > necessary?  
> >
> > Interesting!
> >
> > pkg-config behaves differently on my system:
> >
> > % PKG_CONFIG_SYSROOT_DIR=/foo pkg-config --variable=udevdir udev
> > /foo/lib/udev
> >
> > This appears to be a difference in behavior between dev-util/pkgconfig
> > and dev-util/pkgconf. I am using pkgconf, and I would guess you are
> > using pkgconfig.
> >
> > I guess I will ask pkgconf upstream for help on this; it seems like
> > this is probably an unintended behavior.  
> 
> It seems that the pkgconf behavior is intentional.
> 
> https://github.com/pkgconf/pkgconf/issues/69
> 
> I opened an issue to see if we can get some kind of opt-out.
> 
> https://github.com/pkgconf/pkgconf/issues/205

Hmmm. At this point, I'm thinking maybe we should just address this in
cross-pkg-config. It seems unfair to ask upstream to accommodate this
when the tool is just doing what we asked it to. Perhaps it could
respect PKG_CONFIG_SYSROOT_DIR if it is already set, even when empty.
It wouldn't allow to you set this differently for the build host but
you shouldn't ever have to. I think I'd prefer this over adding yet
another confusing variable. The same could be applied to
PKG_CONFIG_LIBDIR and PKG_CONFIG_SYSTEM_LIBRARY_PATH for consistency.
What do you think?

On a side note, I think that what cross-pkg-config does should be part
of Portage or something rather than part of crossdev because there's
nothing really cross-compile-specific about it. You can set SYSROOT
when building natively, although that tends to run into even more
issues than you get with cross.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpNBAoelSf5e.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] systemd.eclass: remove SYSROOT from pkg-config output

2021-01-04 Thread James Le Cuirot
On Sun, 3 Jan 2021 10:16:49 -0500
Mike Gilbert  wrote:

> On Sun, Jan 3, 2021 at 7:52 AM James Le Cuirot  wrote:
> >
> > On Sat,  2 Jan 2021 20:09:04 -0500
> > Mike Gilbert  wrote:
> >  
> > > When cross-compiling, users will typically have
> > > PKG_CONFIG_SYSROOT=${SYSROOT} defined via pkg-config wrapper.
> > >
> > > When PKG_CONFIG_SYSROOT is set, all paths included in pkg-config
> > > output get prefixed with this value.
> > >
> > > Signed-off-by: Mike Gilbert 
> > > ---
> > >
> > > This patch has already been pushed, but I figured I would send it for
> > > review in case someone else can think of a failure case, or has a better
> > > solution.
> > >
> > >  eclass/systemd.eclass | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/eclass/systemd.eclass b/eclass/systemd.eclass
> > > index 81065a0af79a..f6d1fa2d92d6 100644
> > > --- a/eclass/systemd.eclass
> > > +++ b/eclass/systemd.eclass
> > > @@ -50,6 +50,7 @@ _systemd_get_dir() {
> > >
> > >   if $(tc-getPKG_CONFIG) --exists systemd; then
> > >   d=$($(tc-getPKG_CONFIG) --variable="${variable}" systemd) 
> > > || die
> > > + d=${d#${SYSROOT}}
> > >   d=${d#${EPREFIX}}
> > >   else
> > >   d=${fallback}  
> 
> > The EPREFIX line is (sometimes) wrong in EAPI 7 though and the same goes
> > for udev.eclass. It took a while to get this agreed and corrected in
> > PMS but if SYSROOT points to / then the effective prefix is BROOT, not
> > EPREFIX; they may not be the same.  
> 
> Ugh, that "corrected" logic in PMS head is nasty.

I wish it could be simpler but that's just the nature of the beast. I
could give an example of why it matters, even in this context, but I
think you already know. There's some good news though...

> > If you just strip ESYSROOT then
> > it will always do the right thing but you'll need this fall back for
> > older EAPIs. I'm not sure why you didn't do it in one line?  
> 
> I was trying to accommodate older EAPIs that do not define ESYSROOT.
> This seemed like the simplest approach. It also allows for the case
> where someone is not using cross-pkg-config, and
> PKG_CONFIG_SYSROOT_DIR is unset. Since SYSROOT and EPREFIX are removed
> separately, if one of them is already missing, it will just be
> skipped.

I saw your new patch. I noticed that it sets the "d" variable but
doesn't make use of it. That aside, I thought perhaps I could come up
with something cleaner. That's when I made an amusing discovery.

$ PKG_CONFIG_SYSROOT_DIR=/foo pkg-config --variable=udevdir udev  
/lib/udev

The udevdir variable is not affected by PKG_CONFIG_SYSROOT_DIR at all.
And why would it be? The man page says that this variable is only
applied to -I and -L flags. I don't know for sure but I suspect that
pkg-config just sees this as some arbitrary variable with no special
path handling at all. I wonder what led you to think that this fix was
necessary?

That said, you'll still need special handling for EAPI 7. Unfortunately
there's no separate variable for the prefix alone but at least it's
simpler now. Something like this?

diff --git a/eclass/udev.eclass b/eclass/udev.eclass
index 2873ae9a92c3..f10ea0de01a2 100644
--- a/eclass/udev.eclass
+++ b/eclass/udev.eclass
@@ -50,12 +50,19 @@ fi
 # @DESCRIPTION:
 # Get unprefixed udevdir.
 _udev_get_udevdir() {
-   if $($(tc-getPKG_CONFIG) --exists udev); then
-   local udevdir="$($(tc-getPKG_CONFIG) --variable=udevdir udev)"
-   echo "${udevdir#${EPREFIX%/}}"
-   else
-   echo /lib/udev
+   local udevdir="/lib/udev"
+
+   if $(tc-getPKG_CONFIG) --exists udev; then
+   udevdir="$($(tc-getPKG_CONFIG) --variable=udevdir udev)" || die
+
+   if [[ ${EAPI:-0} == [0123456] ]]; then
+   udevdir=${udevdir#${EPREFIX}}
+   else
+   udevdir=${udevdir#${ESYSROOT#${SYSROOT}}}
+   fi
fi
+
+   echo "${udevdir}"
 }

One last question. Why is this dynamic at all? Shouldn't it just be
hardcoded to /lib/udev? Sure, a user could patch udev to make it
something different if they really wanted but there are plenty of other
paths we just assume. What makes this one special?

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpSPRcvfw2Md.pgp
Description: OpenPGP digital signature


[gentoo-dev] Last rites: dev-libs/ilbc-rfc3951

2021-01-04 Thread Sam James
# Jaco Kroon  (2021-01-04)
# media-libs/libilbc is (for every package I manage) a drop-in for
# dev-libs/ilbc-rfc3951. The latter had net-misc/asterisk,
# net-libs/pjproject and net-voip/yate as dependencies.
# (All of which has been bumped to no longer have this dependency.)
# Removal in 30 days, bug #70
dev-libs/ilbc-rfc3951


signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] Re: [PATCH] acct-user.eclass: don't modify existing user by default

2021-01-04 Thread James Cloos
>>>>> "RHJ" == Robin H Johnson  writes:

RHJ> The best I can come up with at the moment, is that any packaging should
RHJ> detect if there are user modifications, and provide control to users
RHJ> based on that fact.

Exactly.  Akin to etc-update.

-JimC
-- 
James Cloos  OpenPGP: 0x997A9F17ED7DAEA6




Re: [gentoo-dev] [PATCH] systemd.eclass: remove SYSROOT from pkg-config output

2021-01-03 Thread James Le Cuirot
On Sun, 3 Jan 2021 12:52:08 +
James Le Cuirot  wrote:

> On Sat,  2 Jan 2021 20:09:04 -0500
> Mike Gilbert  wrote:
> 
> > When cross-compiling, users will typically have
> > PKG_CONFIG_SYSROOT=${SYSROOT} defined via pkg-config wrapper.
> > 
> > When PKG_CONFIG_SYSROOT is set, all paths included in pkg-config
> > output get prefixed with this value.
> > 
> > Signed-off-by: Mike Gilbert 
> > ---
> > 
> > This patch has already been pushed, but I figured I would send it for
> > review in case someone else can think of a failure case, or has a better
> > solution.
> > 
> >  eclass/systemd.eclass | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/eclass/systemd.eclass b/eclass/systemd.eclass
> > index 81065a0af79a..f6d1fa2d92d6 100644
> > --- a/eclass/systemd.eclass
> > +++ b/eclass/systemd.eclass
> > @@ -50,6 +50,7 @@ _systemd_get_dir() {
> >  
> > if $(tc-getPKG_CONFIG) --exists systemd; then
> > d=$($(tc-getPKG_CONFIG) --variable="${variable}" systemd) || die
> > +   d=${d#${SYSROOT}}
> > d=${d#${EPREFIX}}
> > else
> > d=${fallback}  
> 
> I was going to say this is not the best approach as it would be better
> to tell pkg-config to not add the SYSROOT in the first place. I now
> realise we have shot ourselves in the foot with cross-pkg-config as it
> uses SYSROOT to set both PKG_CONFIG_SYSROOT_DIR to control the output
> and PKG_CONFIG_LIBDIR to find the .pc files in the first place. I have
> had prefix-related fixes for cross-pkg-config lined up for over a year
> but unfortunately they do not address this. Trying to accommodate this
> use case would probably just make it more confusing though so maybe
> your approach is best after all.
> 
> The EPREFIX line is (sometimes) wrong in EAPI 7 though and the same goes
> for udev.eclass. It took a while to get this agreed and corrected in
> PMS but if SYSROOT points to / then the effective prefix is BROOT, not
> EPREFIX; they may not be the same. If you just strip ESYSROOT then
> it will always do the right thing but you'll need this fall back for
> older EAPIs. I'm not sure why you didn't do it in one line? I forget if
> EPREFIX is normalised to be / rather thank blank.
> 
> d=${d#${SYSROOT%/}/${EPREFIX#/}}

Had another minute to think. EPREFIX always strips the trailing slash
so it would be blank.

d=${d#${SYSROOT%/}${EPREFIX}}

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgp0JKYoJYsgE.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] systemd.eclass: remove SYSROOT from pkg-config output

2021-01-03 Thread James Le Cuirot
On Sat,  2 Jan 2021 20:09:04 -0500
Mike Gilbert  wrote:

> When cross-compiling, users will typically have
> PKG_CONFIG_SYSROOT=${SYSROOT} defined via pkg-config wrapper.
> 
> When PKG_CONFIG_SYSROOT is set, all paths included in pkg-config
> output get prefixed with this value.
> 
> Signed-off-by: Mike Gilbert 
> ---
> 
> This patch has already been pushed, but I figured I would send it for
> review in case someone else can think of a failure case, or has a better
> solution.
> 
>  eclass/systemd.eclass | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/eclass/systemd.eclass b/eclass/systemd.eclass
> index 81065a0af79a..f6d1fa2d92d6 100644
> --- a/eclass/systemd.eclass
> +++ b/eclass/systemd.eclass
> @@ -50,6 +50,7 @@ _systemd_get_dir() {
>  
>   if $(tc-getPKG_CONFIG) --exists systemd; then
>   d=$($(tc-getPKG_CONFIG) --variable="${variable}" systemd) || die
> + d=${d#${SYSROOT}}
>   d=${d#${EPREFIX}}
>   else
>   d=${fallback}

I was going to say this is not the best approach as it would be better
to tell pkg-config to not add the SYSROOT in the first place. I now
realise we have shot ourselves in the foot with cross-pkg-config as it
uses SYSROOT to set both PKG_CONFIG_SYSROOT_DIR to control the output
and PKG_CONFIG_LIBDIR to find the .pc files in the first place. I have
had prefix-related fixes for cross-pkg-config lined up for over a year
but unfortunately they do not address this. Trying to accommodate this
use case would probably just make it more confusing though so maybe
your approach is best after all.

The EPREFIX line is (sometimes) wrong in EAPI 7 though and the same goes
for udev.eclass. It took a while to get this agreed and corrected in
PMS but if SYSROOT points to / then the effective prefix is BROOT, not
EPREFIX; they may not be the same. If you just strip ESYSROOT then
it will always do the right thing but you'll need this fall back for
older EAPIs. I'm not sure why you didn't do it in one line? I forget if
EPREFIX is normalised to be / rather thank blank.

d=${d#${SYSROOT%/}/${EPREFIX#/}}

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpTmn9Lvd_4Y.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Getting rid of USE=unicode

2020-12-30 Thread James Cloos
there are not too many packages to look at:

:; git grep -P IUSE.+unicode.*\"|awk -F/ '{print $1 "/" $2}'|sort -u|wc -l
82

so it should ot take too uch effort.

and it definitely would be worth it!

-JimC
-- 
James Cloos  OpenPGP: 0x997A9F17ED7DAEA6



Re: [gentoo-dev] Last rites: media-libs/jpeg

2020-12-30 Thread James Le Cuirot
On Wed, 30 Dec 2020 12:54:59 +0100
Michał Górny  wrote:

> # Michał Górny  (2020-12-30)
> # Unmaintained.  Entirely replaced by media-libs/libjpeg-turbo,
> # to the point that reverse dependencies no longer build with
> # media-libs/jpeg.  The two libraries are binary-incompatible,
> # and the current method of switching between them is incorrect.
> # Removal in 30 days.  Bug #762634.
> media-libs/jpeg

It's worth noting that libjpeg-turbo is now an official reference
implementation. https://jpeg.org/items/20190204_press.html

Also of interest is the fact that libjpeg-turbo can be built to be
ABI-compatible with jpeg-7 and jpeg-8, though not the current jpeg-9. I
added a turbo-based media-libs/jpeg-compat for version 8 to
steam-overlay.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpAmU8tbJTZQ.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-29 Thread Sam James


> On 28 Dec 2020, at 10:02, Hanno Böck  wrote:
> 
> If it has any weight:
> I think I was the first person to build Gentoo with LibreSSL. I support
> this.
> 

I’m pleased to have yours and blueness’ input. Really, I think going
is probably best. Just make it clear it can come back with some
new backing, if that ever happens.

Thinking about it some more, we recently had QtNetwork users without
security patches for a few weeks because (and this is not his fault) there’s
only a bus factor of 1 for updating compatibility on every point release of Qt.

I’m also unconvinced that if we suddenly lost LibreSSL compatibility in some
@system or otherwise popular package we could restore functionality in any
reasonable timeframe.

Bit sad to be here, but here we are.

> I believe pretty much everything that LibreSSL originally was
> (consistent codingstyle, cleanup of obsolete/dead code etc.) has
> happened in OpenSSL these days. It's more that there's some myth around
> LibreSSL from these early days (where the people behind it raised
> back then valid criticism about OpenSSL) than any real value.

This is exactly my experience.

> 
> --
> Hanno Böck
> https://hboeck.de/
> 



signature.asc
Description: Message signed with OpenPGP


Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-29 Thread Sam James

> On 29 Dec 2020, at 09:13, Marcel Schilling  
> wrote:
> 
> 
> I just want to comment that I switched to LibreSSL on several Gentoo
> systems years ago and never had any major issues.
> I run both desktop and server systems with LibreSSL, based on X and
> Wayland. The only issues I ran into is a slight lag of the overlay
> behind the main tree so once in a while I had to mask a new version of
> some package for a week or so.

It is largely one person who is under a lot of stress to provide updated
patches ASAP. Some upstreams have made clear they will never
accept LibreSSL patches and life becomes harder as they adopt
new APIs not yet supported in the Libre variant.

TL;DR: I’d be fine with keeping LibreSSL if we had (an influx of) people
coming up with patches that are sustainable, upstreamed, and not just
crippling functionality.

> So from a pure user perspective, thing change would mean a risky update
> to systems running stable for years with no gain whatsoever.

This isn’t quite right. Users cannot upgrade to new versions of software,
possibly with security fixes, until a new patch is created and applied.

This recently happened with mupdf.

One of our developers runs several high-bandwidth Tor relays which
were broken with LibreSSL and still haven’t been fixed. But I accept
that you’ve had a pain-free experience.

> So even if LibreSSL does not provide any advantage over OpenSSL
> (anymore), dropping support would do harm.
> That said, I do understand maintainer burden and I will probably be fine
> with such a change. But I have to say that over the last ten years,
> Gentoo does feel a lot less focussed on choice than it used to and I am
> counting the days until is deemed 'unpractical' to support legacy boot,
> non-systemd init or 'exotic' arches. ;-)
> 

I don’t think this is true. We support equality of openrc vs systemd and
if you think there’s deficits there, please let us know - although of course
help is welcome (and needed for OpenRC).

And on arches, I spend a lot of my time testing packages on various
exotic architectures, so it’d be good to have some concrete examples
of what’s bothering you.

I don’t think being realistic about what we can support is wrong,
but I’m also not sure we’ve been particularly aggressive or wrong
with any of those decisions...

> Best,
> Marcel

—
My position is that I’d prefer to just mask it and make clear it’s
unsupported rather than remove at all.

There’s little to be gained from fully removing - we can just treat it like
musl/prefix/whatever else, i.e. a niche thing which we support with best-effort
(and it might be a bit patchy).

Thanks,
Sam



signature.asc
Description: Message signed with OpenPGP


Re: [gentoo-dev] [PATCH 1/3] dev-util/meson: install meson-array script

2020-12-17 Thread James Le Cuirot
On Thu, 17 Dec 2020 14:38:43 -0600
William Hubbs  wrote:

> On Sat, Dec 12, 2020 at 09:22:06PM -0500, Mike Gilbert wrote:

> > I don't really understand what you mean by this. I am converting one
> > internal bash function into an external script so that its python
> > dependencies can be better defined and managed.  
> 
> What I mean is, ebuilds should not be calling _meson_env_array at all
> since it is defined and documented as an eclass internal function.
> 
> I would like to know more about what the gallium-nine-standalone ebuild
> is doing and why it needs to call a meson.eclass internal function.
> 
> On the other hand, if _meson_env_array is meant to be called by ebuilds,
> we need to rename it and improve the documentation for it in the eclass.

I knew I spoke to someone about this on IRC and turns out it was you 2
years ago. :P The ebuild needs to render flags as a Meson array and
this eclass function is the best way to do it. You did not know why it
was private and said to go ahead anyway but file a bug so that this
situation could be improved. I admittedly didn't get around to filing a
bug but I was totally prepared to deal with the fall out if it broke.
Now floppym is improving the situation anyway and fixing the ebuild
too. I give my thanks to him. Job done?

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpPbvZE71UX_.pgp
Description: OpenPGP digital signature


[gentoo-dev] Re: [PATCH 2/3] meson.eclass: use meson-array script

2020-12-11 Thread James Le Cuirot
On Fri, 11 Dec 2020 18:17:43 -0500
Mike Gilbert  wrote:

> This allows python-exec to pick a suitable interpreter when
> /usr/bin/python is missing.
> 
> Closes: https://bugs.gentoo.org/759433
> Signed-off-by: Mike Gilbert 
> ---
>  eclass/meson.eclass | 100 +---
>  1 file changed, 39 insertions(+), 61 deletions(-)

That's cool. You forgot to remove the __MESON_ARRAY_PARSER definition
though.


pgpY5ngFuvHKB.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider

2020-11-26 Thread Sam James

> On 26 Nov 2020, at 22:37, Peter Stuge  wrote:
> Michael Orlitzky wrote:
>> Corollary: the tmpfiles.d specification can only be implemented (safely)
>> on Linux after all.
> 
> So should virtual/tmpfiles differentiate based on system?
> 

It won’t be keyworded where it’s not available so Portage will skip over it. 
systemd only supports certain platforms.

> 
> //Peter
> 



signature.asc
Description: Message signed with OpenPGP


Re: [gentoo-dev] Pushing to distfiles?

2020-11-14 Thread James Le Cuirot
On Sun, 15 Nov 2020 11:03:29 +1300
Kent Fredric  wrote:

> On Wed, 11 Nov 2020 19:38:35 -0500
> Rich Freeman  wrote:
> 
> > I just host stuff like that on my dev webspace, or better yet on
> > github or something else that will auto-tarball stuff.  
> 
> Oh, yeah, and don't rely on github auto-tarball stuff.
> 
> History has demonstrated github sometimes "forgets" their cached copies
> of those tarballs, and then later when requested, it will regenerate
> them fresh ... but with different SHAsums.
> 
> If you're gonna use github for tarballs, roll that tarball yourself,
> and attach it to a "release", manually and explicitly, and then use the
> URL to the release asset.
> 
> Only then can you be sure: 
> 
> a) Of what the tarball actually contains
> b) Of what the tarballs SHAsum will be

I'm not claiming this has never actually happened but I use these
GitHub tarballs *a lot* and I don't recall ever seeing it. Does anyone
know for sure that it's happened in, say, the last 3 years?  It's a lot
of extra work for a problem that may no longer exist or is so rare that
it's just not worth the effort.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpUsAXfBuNwo.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Packages & projects up for grabs due to jer's retirement

2020-11-03 Thread Sam James


> On 3 Nov 2020, at 21:53, James Le Cuirot  wrote:
> 
> On Tue, 03 Nov 2020 22:32:11 +0100
> Michał Górny  wrote:
> 
>> Additionally, the following packages are looking for a new maintainer:
>> 
>> net-misc/chrony
> 
> I may take this if no one else really wants it. I run a simple client
> and server setup on Gentoo at home but I have no interest in the fancy
> features.

I have some familiarity with Chrony so could we co-maintain?

> 
>> www-client/vivaldi
>> www-client/vivaldi-snapshot
> 
> I'll take these but it may take me some time to get some kind of
> automation going for the frequent bumps involved. I know that Opera is
> a similar package but I really don't want it.

BTW: Speak with the Chromium team as I think they’re looking at automating
these all if possible (not guaranteed, ofc).

> 
> --
> James Le Cuirot (chewi)
> Gentoo Linux Developer



signature.asc
Description: Message signed with OpenPGP


Re: [gentoo-dev] Packages & projects up for grabs due to jer's retirement

2020-11-03 Thread James Le Cuirot
On Tue, 03 Nov 2020 22:32:11 +0100
Michał Górny  wrote:

> Additionally, the following packages are looking for a new maintainer:
> 
> net-misc/chrony

I may take this if no one else really wants it. I run a simple client
and server setup on Gentoo at home but I have no interest in the fancy
features.

> www-client/vivaldi
> www-client/vivaldi-snapshot

I'll take these but it may take me some time to get some kind of
automation going for the frequent bumps involved. I know that Opera is
a similar package but I really don't want it.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpBo6kggM2u6.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] sys-apps/firejail and sys-apps-firejail lts are up for grabs

2020-10-14 Thread Sam James

> On 14 Oct 2020, at 18:40, Hank Leininger  wrote:
> 
> On 2020-10-11, Dennis Lamm wrote:
>> the following packages are up for grabs:
>> 
>> - sys-apps/firejail
>> - sys-apps/firejail-lts
> 
> I will proxy maintain both of these. Preparing a PR shortly...
> 

I think ajak is also working on this (spending time on getting tests working), 
so coordinate with him if possible?

Thanks,
Sam

> Thanks,
> 
> --
> 
> Hank Leininger 
> 9606 3BF9 B593 4CBC E31A  A384 6200 F6E3 781E 3DD7



signature.asc
Description: Message signed with OpenPGP


Re: [gentoo-dev] OSL 1.11.8.0 ebuild

2020-10-09 Thread Sam James
Hi,

Can you submit this on Bugzilla and/or via a GitHub pullrequest?

Thanks!

> On 9 Oct 2020, at 19:31, Luke A. Guest  wrote:
> 
> Hi,
> 
> I copied and updated the osl ebuild. There's a bit of a hack in there to find 
> the LLVM_ROOT. But it builds.
> 
> 



signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] Last rites: games-board/spider

2020-10-03 Thread James Le Cuirot
# Alexey Sokolov  (2020-10-03)
# Package with no available HOMEPAGE, SRC_URI and multiple compilation issues.
# Bug #741468, removal in 30 days.
games-board/spider

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpzcRSFp1vbJ.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC: GID assignment for gamemode

2020-09-20 Thread Sam James

> On 20 Sep 2020, at 18:40, Kai Krakow  wrote:
> 
> Supersedes: 
> https://archives.gentoo.org/gentoo-dev/message/06a2f464c836a0f8d9dd1d48963aefb1
>  
> 
> 
> I would like to reserve GID 37 for games-util/gamemode.
> 

Hi,

For proxy-maintainers, see the wiki page [0]. The gist is that we pick one for 
you at time of merge.

If you need to ping us for a PR where CI is green and comments have been 
addressed, please come
ask in #gentoo-proxy-maint on Freenode.

[0] 
https://wiki.gentoo.org/wiki/Proxied_Maintainer_FAQ#Adding_acct-.7Bgroup.2Cuser.7D.2Fpackages_as_a_proxied_maintainer
 


Thanks!
Sam



signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] Last rites: app-admin/recursos

2020-09-16 Thread Sam James
# Sam James  (2020-09-16)
# Stuck on EAPI 4, only source is mirror://gentoo,
# unmaintained, HOMEPAGE gone.
app-admin/recursos


signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] Last rites: sys-fs/ufsutils

2020-09-15 Thread Sam James
# Sam James  (2020-09-15)
# No longer exists upstream, stuck on long-obsolete EAPI 4,
# and fails to build with glibc-2.32.
# Vestige of Gentoo/FreeBSD.
# bug #715506, #737892, #740916, #547244.
sys-fs/ufsutils


signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] Last rites: app-arch/unarj

2020-09-13 Thread James Le Cuirot
# James Le Cuirot  (2020-09-13)
# License issues. app-arch/arj is a better alternative. Removal in 30
# days. See bug #694746.
app-arch/unarj

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpz225rDDqkd.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Packages up for grabs

2020-09-13 Thread James Le Cuirot
On Sun, 30 Aug 2020 11:19:51 +0300
Joonas Niilola  wrote:

> here's a list of few packages dropped to maintainer-needed due to
> retirement of inactive    maintainers.
> 
> b = bugs open,
> v = new version available.
> 
> app-arch/lha

Taken. Amiga forever! ;)

> app-arch/unarj b

This is going to be last-rited. See https://bugs.gentoo.org/694746.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpa_05luHXpS.pgp
Description: OpenPGP digital signature


[gentoo-dev] Last rites: net-dialup/tkvoice

2020-09-12 Thread Sam James
# Sam James  (2020-09-13)
# Dead upstream, EAPI 4, no maintainer
# Removal in 30 days
net-dialup/tkvoice


signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] Last rites: dev-lang/cll1h

2020-09-12 Thread Sam James
# Sam James  (2020-09-13)
# Dead upstream, EAPI 4, no maintainer
# Removal in 30 days
# bug #740954
dev-lang/cll1h


signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] Last rites: dev-tex/chktex

2020-09-12 Thread Sam James
# Sam James  (2020-09-12)
# Merged into app-text/texlive-core
# Removal in 30 days
dev-tex/chktex


signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] Last rites: dev-tex/biblatex-apa

2020-09-12 Thread Sam James
# Sam James  (2020-09-12)
# Merged into dev-texlive/texlive-bibtexextra
# Removal in 30 days
dev-tex/biblatex-apa


signature.asc
Description: Message signed with OpenPGP


Re: [gentoo-dev] Please port your packages to Python 3.8

2020-09-02 Thread Sam James

> On 1 Sep 2020, at 12:02, Michał Górny  wrote:
> 
> Hello,
> 
> [snip]

> Python 3.8 is planned to become the default on 2020-12-01.
> 

Note that this means we need to keep in mind stabilisation of Python 3.8+ 
supporting-packages going forward.

Please request stabilisation of your Python 3.8+ changes at the 30 days point, 
or earlier if it’s a trivial revbump
(as new Python targets are equivalent to new USE flags, there is no real need 
for a revbump unless doing other tidying
whilst there).

Stabling Python 3.8 packages also makes things a bit easier for people who do 
testing of their packages on a stable system -
mostly thinking of proxy-maintainers or casual user contributions here.

I’m sure you’ve all already seen my annoying bugs to keep track of needed 
stabilisations; it will however be worth
it to ensure a smooth transition when the default changes.

The danger of insufficient stabled changes is users having to understand 
possibly complex Portage conflicts and add
large numbers of package.use exceptions on a temporary basis which is 
unnecessary confusion.

Again a reminder to add Python 3.9 whenever you can too.

> Thank you all for your hard work!
> --
> Best regards,
> Michał Górny
> 

Thanks,
Sam



signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] Last rites: net-irc/nebula

2020-08-30 Thread Sam James
This one is stuck on EAPI 4 and we’re the only ones packaging it. Dead upstream.

# Sam James  (2020-08-30)
# Collection of quite dead net-irc/* pkgs
# Please speak up if you use any of these
# and a modern alternative doesn't work for you.
# None of these have alive upstreams, and we're
# the only distro packaging them in many cases.
# Unmaintained. Removal in 30 days.
[…]
net-irc/nebula



signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] Last rites: net-irc/xaric

2020-08-29 Thread Sam James
# Sam James  (2020-08-30)
# Collection of quite dead net-irc/* pkgs
# Please speak up if you use any of these
# and a modern alternative doesn't work for you.
# None of these have alive upstreams, and we're
# the only distro packaging them in many cases.
# Unmaintained. Removal in 30 days.
# […]
# bug 706898, bug 731188
[…]
net-irc/xaric


signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] Last rites: dev-db/sqliteodbc

2020-08-29 Thread Sam James
# Sam James  (2020-08-30)
# Serious security bug, unmaintained.
# Stuck on long-obsolete EAPI 4.
# Several open bugs.
# bug 720732, bug 729714, bug 722644,
# bug 724184.
dev-db/sqliteodbc



signature.asc
Description: Message signed with OpenPGP


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

2020-08-29 Thread Sam James
# Sam James  (2020-08-30)
# Serious security vulns, outdated.
# bug 699834. Removal in 30 days.
www-apps/ampache


signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] Last rites: net-irc/irc-server

2020-08-29 Thread Sam James
# Sam James  (2020-08-30)
# Collection of quite dead net-irc/* pkgs
# Please speak up if you use any of these
# and a modern alternative doesn't work for you.
# None of these have alive upstreams, and we're
# the only distro packaging them in many cases.
# Unmaintained. Removal in 30 days.
# bug 724940, bug 708408, bug 716264, bug 633346
[…]
net-irc/irc-server



signature.asc
Description: Message signed with OpenPGP


[gentoo-dev] Last rites: net-irc/ptlink-ircd, net-irc/ptlink-opm

2020-08-29 Thread Sam James
# Sam James  (2020-08-30)
# Collection of quite dead net-irc/* pkgs
# Please speak up if you use any of these
# and a modern alternative doesn't work for you.
# None of these have alive upstreams, and we're
# the only distro packaging them in many cases.
# Unmaintained. Removal in 30 days.
# bug 724940
net-irc/ptlink-ircd
net-irc/ptlink-opm


signature.asc
Description: Message signed with OpenPGP


Re: [gentoo-dev] How to set CXX compiler?

2020-07-03 Thread James Le Cuirot
On Fri, 03 Jul 2020 22:35:30 +
Xianwen Chen (陈贤文)  wrote:

> In the Makefile, it is written that 
> 
> cc = g++ 
> 
> I would like to use sed to patch it so that it ebuild knows which g++ to
> use. For example, depending on whether ccache is set, ebuild shall know
> whether to use ccache. 

Rather than patch it, start the build with:

emake cc="$(tc-getCXX)"

You'll probably need to do more to respect CXXFLAGS and such though.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpUk0gHCJfvA.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Last rites: */* More Py2 only items

2020-06-29 Thread Sam James

> On 29 Jun 2020, at 01:35, Aaron Bauman  wrote:
> 
> # Aaron Bauman  (2020-06-28)
> # More Py2 only stuff. Plz see -dev ML for discussions
> # Remove bindings, port to Py3, etc
> 
> net-irc/irker
> 

Upstream seem to be about to release 2.19 which includes
several patches for Python 3 compatibility.

(There wasn’t much activity 24 hours ago.. maybe you inspired
something, bman!)

I’ll make a PR with these (either with the patches or release) if
they work fine.

> --
> Cheers,
> Aaron



signature.asc
Description: Message signed with OpenPGP


Re: [gentoo-dev] glsa-check: missing CVE-2020-6509 for current stable chromium version

2020-06-23 Thread Sam James

> On 23 Jun 2020, at 21:57, Samuel Bernardo  
> wrote:
> 
> Hi,
> 
> Sorry if I miss any detail about glsa-check context, but I think that it
> misses the CVE[1] id review I left in subject.
> 

A GLSA (see https://security.gentoo.org/glsa 
) has not yet been filed
for this issue. Once the fixed version (83.0.4103.116) is stabilised,
we will release one ASAP.

> About chromium stability, what would you advice me, install latest
> keyword masked version or wait for next stable version?

The new one should be stabled shortly. It’s up to you if you want to
install it ahead of time or not.

> 
> The current chromium stable version have also runtime errors using
> ffmeg-4.3. [2][3]

The new version was added in [1] and you can track the progress
of the security bug (search Bugzilla for the CVE(s)) in [2].

There is also a bug [3] for the ffmpeg issue, and the commit [1]
adds a dep on an older ffmpeg for now.

[1] 
https://gitweb.gentoo.org/repo/gentoo.git/commit/www-client/chromium?id=a21f83685eda6f895c0a6819172172f63395a157
 

[2] https://bugs.gentoo.org/729310 
[3] https://bugs.gentoo.org/728624


Hope this helps.

If you ever have any queries about security matters in Gentoo, please
feel free to ask this list (or gentoo-security, but it’s less active), or
on IRC in the #gentoo-security channel.

TL;DR: We’re aware of it, the bug is in progress, will be stabled on amd64
shortly, and a GLSA will follow. No need to worry. :)

> 
> Thanks for your enlightenment



signature.asc
Description: Message signed with OpenPGP


Re: [gentoo-dev] */*: Mask Py2 only packages

2020-06-20 Thread James Le Cuirot
On Sat, 20 Jun 2020 14:58:22 +0300
Azamat Hackimov  wrote:

> > games-emulation/openmsx  
> 
> git version migrated to meson and python3

Yeah, don't worry, this has been on my TODO for a while and I'll step
it up the list. I was hoping they'd do a release but no such luck.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpuDKd84KFJF.pgp
Description: OpenPGP digital signature


  1   2   3   4   5   6   7   8   >