Re: [gentoo-dev] Ada project needs your help!

[Christopher Head]

On Wed, 14 Dec 2016 16:47:41 +0100
Michał Górny  wrote:

> So the only real consumer is GHDL -- yet another case when someone
> thought it'd be fun to use a fringe language to implement something
> useful... However, it seems to be undermaintained in Gentoo as well,
> not bumped for a long time.
> 

Undermaintained perhaps, but it works. Not a lot of bugs filed. Would a
pull request be sufficient to stop this package I use from being
steamrollered into oblivion? I honestly wasn’t hoping to spend my
holidays learning how the GCC build system works, but if I’m left with
no other choice, then I possibly might look into it. I won’t bother
though if there’s some reason why it wouldn’t be accepted anyway,
because people don’t want Gnat or GHDL in the tree.
-- 
Christopher Head


pgpz_Xk5oibPC.pgp
Description: OpenPGP digital signature

[gentoo-dev] [PATCH 1/1] kernel-2.eclass: Remove kdbus support as it is, discontinued. First reported in bug #576614 by jon R-B

[Mike Pagano]

kdbus is discontinued and is being reworked upstream as a different
effort with a different name.
That said, remove unused kdbus support from the kernel eclass.

---
 eclass/kernel-2.eclass | 18 --
 1 file changed, 18 deletions(-)

diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index 2b4f21c..424aa03 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -156,13 +156,6 @@
 # in the long term directories on the upstream servers
 # as the location has been changed by upstream

-# @ECLASS-VARIABLE:  K_KDBUS_AVAILABLE 
-# @DEFAULT_UNSET
-# @DESCRIPTION:
-# If set, the ebuild contains the option of installing the
-# kdbus patch.  This patch is not installed without the 'kdbus'
-# and 'experimental' use flags.
-
 # @ECLASS-VARIABLE:  H_SUPPORTEDARCH   
 # @DEFAULT_UNSET
 # @DESCRIPTION:
@@ -610,10 +603,6 @@ if [[ ${ETYPE} == sources ]]; then
DESCRIPTION="Sources based on the Linux Kernel."
IUSE="symlink build"

-   if [[ -n ${K_KDBUS_AVAILABLE} ]]; then
-   IUSE="${IUSE} kdbus"
-   fi
-
# Bug #266157, deblob for libre support
if [[ -z ${K_PREDEBLOBBED} ]] ; then
# Bug #359865, force a call to detect_version if needed
@@ -1246,13 +1235,6 @@ unipatch() {
UNIPATCH_DROP+="
5000_enable-additional-cpu-optimizations-for-gcc.patch"
fi
fi
-
-   # if kdbus use flag is not set, drop the kdbus patch
-if [[ $UNIPATCH_DROP != *"5015_kdbus*.patch"* ]]; then
-   if ! has kdbus ${IUSE} ||  ! use kdbus; then
-   UNIPATCH_DROP="${UNIPATCH_DROP} 
5015_kdbus*.patch"
-   fi
-   fi
fi
done

-- 
2.10.2




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 1/1] kernel-2.eclass: Add required @USAGE documentation to functions.

[Mike Pagano]

On 12/12/2016 07:34 PM, Mike Pagano wrote:
> According to (not pms) devmanual, @USAGE is required for functions.
> This patch only touches comments and no code has been modified.


Committed. If the devmanual changes, I can easily remove the empty USAGE
statements.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Handling ebuild logging output in Portage (Was: gpg: signing failed: Inappropriate ioctl for device)

[M. J. Everitt]

At the risk of starting a flame war, two minor netiquette tips... ;)

1) Top or mid-posting is not recommended .. makes following the thread
harder [note my deliberate misuse here!]
2) PLEASE PLEASE sort out your clock .. I have emails from you (yeah I
know Thunderbird is ) from the future year 2026 which don't really
belong at the top of my mail folder.

Tyvm,ia,

Michael.
PS. Yes, I was aware of the elogv package, I think its mentioned in
whatever docs for PORTAGE_ELOG_*. If it needs updating for EAPI6 we'll
have to hunt down a maintainer

On 11/12/16 15:49, james wrote:
> On 12/14/2016 12:59 PM, Doug Freed wrote:
>> On Wed, Dec 14, 2016 at 10:45 AM, Rich Freeman  wrote:
>>> On Wed, Dec 14, 2016 at 10:27 AM, M. J. Everitt
>>>  wrote:

 I do, but only usually if its the last package of an emerge because
 otherwise its lost many many thousands of lines upwards. Thank
 goodness
 for portage's savelog feature. - Actually that reminds me .. someone
 mentioned a useful tweak to that, with an appropriate FEATURES switch,
 it would categorise the output of the logging system .. must look that
 one up again, or poke the wiki team ...
>
>
>
>
> Well pardon me, if I'm miss interpreting here, as there is only this
> fragmented thread in my inbox:: no prior postings. But perhaps folks
> should look at "app-portage/elogv"
>
> Already in place, easy to use, and should be updated with EAPI (5/6)
> based parsing features?
>
> hth,
> James
>
>

>>>
>>> IMO, emailing elogs to root should probably be the default.  By all
>>> means let people turn it off, but I bet a lot of people don't realize
>>> it is an option.
>>
>> Having just looked at portage's mail code, you can't use the mail
>> subsystem if you have no mailserver or sendmail binary.  Instead,
>> it'll just throw an error, so you couldn't have any default Portage
>> configuration to mail them somewhere.  The current default
>> configuration appends to ${PORT_LOGDIR}/elog/summary.log with qa, log,
>> warn, and error levels for every package that outputs any of these
>> classes.  If PORT_LOGDIR is unset, the target is
>> /var/log/portage/elog/summary.log.
>>
>>>
>>> This goes in all my make.conf files:
>>> PORTAGE_ELOG_CLASSES="warn error log"
>>> PORTAGE_ELOG_SYSTEM="save mail"
>>> PORTAGE_ELOG_MAILURI="a...@a.com smtp.server.address"
>>> PORTAGE_ELOG_MAILSUBJECT="package \${PACKAGE} merged on \${HOST}
>>> with notice"
>>>
>>> Yes, some packages are a bit spammy and this should be fixed, but in
>>> general it has prevented more headaches than it has caused.
>>
>> This can't really be fixed in a good way, and I'd really rather it
>> wasn't anyway.  A [ -z "$REPLACING_VERSIONS" ] test is only valid in
>> pkg_* phases (and by PMS, REPLACING_VERSIONS doesn't have to be
>> defined in pkg_pretend or pkg_setup), and in many cases, using
>> REPLACING_VERSIONS in any way can be difficult to do correctly.  Using
>> the readme.gentoo eclass wouldn't be an awful way to go if it really
>> bothers you, but you could also use mail_summary instead of mail to
>> reduce the mail spam to 1 email per emerge run.
>>
>> -Doug
>>
>>
>
>




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH] man: emaint typo fix, #575178

[Zac Medico]

On 12/14/2016 11:19 AM, Wim Muskee wrote:
> From 74d266404ec157bf97791f308a4858712028d607 Mon Sep 17 00:00:00 2001
> From: Wim Muskee >
> Date: Mon, 12 Dec 2016 19:59:08 +0100
> Subject: [PATCH] man: emaint typo fix, #575178
> 
> ---
>  man/emaint.1 | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/man/emaint.1 b/man/emaint.1
> index cfdadc8..24e4744 100644
> --- a/man/emaint.1
> +++ b/man/emaint.1
> @@ -1,6 +1,6 @@
>  .TH "EMAINT" "1" "May 2015" "Portage VERSION" "Portage"
>  .SH NAME
> -emaint \- performs package managment related system health checks and 
> maintenance
> +emaint \- performs package management related system health checks and 
> maintenance
>  .SH SYNOPSIS
>  .BR emaint
>  [\fIoptions\fR]
> 

Thanks, applied:

https://gitweb.gentoo.org/proj/portage.git/commit/?id=a29847f77d57f2c423c30b931fa40e65523795c4
-- 
Thanks,
Zac

Re: [gentoo-dev] [PATCH 2/3] multiprocessing.eclass: Introduce get_nproc() to get no of CPUs

[Andrew Savchenko]

On Wed, 14 Dec 2016 12:32:41 -0600 Nathan Zachary wrote:
> On 14/12/16 12:29, Fabian Groffen wrote:
> > On 14-12-2016 13:01:16 -0500, Doug Freed wrote:
> >> On Wed, Dec 14, 2016 at 12:48 PM, Nathan Zachary
> >>  wrote:
> >>> On 14/12/16 10:11, Doug Freed wrote:
> > I somehow doubt that would give me the expected number only, and I lack
> > a BSD install handy to test it.
>  $(sysctl -n hw.ncpu)
> 
> >>> I don't know that the sysctl command works universally:
> >>>
> >>> # sysctl -n hw.ncpu
> >>> sysctl: cannot stat /proc/sys/hw/ncpu: No such file or directory
> >>>
> >> It's BSD-specific (Darwin may have it too, but I'm not in OS X at the
> >> moment, so I can't check), which pretty much describes this branch in
> >> the codepath as well.  Linux users will have the nproc command from
> >> coreutils.
> > Yes, Darwin has it too, but the tool lives in /usr/sbin instead:
> >
> > https://gitweb.gentoo.org/repo/proj/prefix.git/tree/scripts/bootstrap-prefix.sh#n1987
> >
> > Fabian
> >
> >
> Ah, yes, I missed the part about it being BSD-specific.
> 
> This one-liner certainly isn't as graceful or elegant, but it works:
> 
> # cat /proc/cpuinfo | grep 'processor' | wc -l
 
Not all BSD systems have procfs enabled.

Best regards,
Andrew Savchenko


pgpPcS7wnPUVZ.pgp
Description: PGP signature

[gentoo-portage-dev] [PATCH] man: emaint typo fix, #575178

[Wim Muskee]

>From 74d266404ec157bf97791f308a4858712028d607 Mon Sep 17 00:00:00 2001
From: Wim Muskee 
Date: Mon, 12 Dec 2016 19:59:08 +0100
Subject: [PATCH] man: emaint typo fix, #575178

---
 man/emaint.1 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/man/emaint.1 b/man/emaint.1
index cfdadc8..24e4744 100644
--- a/man/emaint.1
+++ b/man/emaint.1
@@ -1,6 +1,6 @@
 .TH "EMAINT" "1" "May 2015" "Portage VERSION" "Portage"
 .SH NAME
-emaint \- performs package managment related system health checks and
maintenance
+emaint \- performs package management related system health checks
and maintenance
 .SH SYNOPSIS
 .BR emaint
 [\fIoptions\fR]

[gentoo-dev] [PATCH v2] multiprocessing.eclass: Support passing custom inf values for getters

[Michał Górny]

Support passing custom values for 'infinity' in makeopts_jobs()
and makeopts_loadavg(). This can be used e.g. when a build system does
not support --loadavg, and therefore '--jobs 999' would most likely
be a really bad idea. Combined with get_nproc(), this can be used to
provide a sane replacement instead.

// v2: tests included
---
 eclass/multiprocessing.eclass| 17 ++---
 eclass/tests/multiprocessing_makeopts_jobs.sh|  5 -
 eclass/tests/multiprocessing_makeopts_loadavg.sh |  5 -
 3 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/eclass/multiprocessing.eclass b/eclass/multiprocessing.eclass
index 3c5dfff2d11c..70ca475a8c72 100644
--- a/eclass/multiprocessing.eclass
+++ b/eclass/multiprocessing.eclass
@@ -86,26 +86,27 @@ get_nproc() {
 }
 
 # @FUNCTION: makeopts_jobs
-# @USAGE: [${MAKEOPTS}]
+# @USAGE: [${MAKEOPTS}] [${inf:-999}]
 # @DESCRIPTION:
 # Searches the arguments (defaults to ${MAKEOPTS}) and extracts the jobs number
 # specified therein.  Useful for running non-make tools in parallel too.
 # i.e. if the user has MAKEOPTS=-j9, this will echo "9" -- we can't return the
 # number as bash normalizes it to [0, 255].  If the flags haven't specified a
 # -j flag, then "1" is shown as that is the default `make` uses.  Since there's
-# no way to represent infinity, we return 999 if the user has -j without a 
number.
+# no way to represent infinity, we return ${inf} (defaults to 999) if the user
+# has -j without a number.
 makeopts_jobs() {
[[ $# -eq 0 ]] && set -- ${MAKEOPTS}
# This assumes the first .* will be more greedy than the second .*
# since POSIX doesn't specify a non-greedy match (i.e. ".*?").
local jobs=$(echo " $* " | sed -r -n \
-e 
's:.*[[:space:]](-[a-z]*j|--jobs[=[:space:]])[[:space:]]*([0-9]+).*:\2:p' \
-   -e 's:.*[[:space:]](-[a-z]*j|--jobs)[[:space:]].*:999:p')
+   -e "s:.*[[:space:]](-[a-z]*j|--jobs)[[:space:]].*:${2:-999}:p")
echo ${jobs:-1}
 }
 
 # @FUNCTION: makeopts_loadavg
-# @USAGE: [${MAKEOPTS}]
+# @USAGE: [${MAKEOPTS}] [${inf:-999}]
 # @DESCRIPTION:
 # Searches the arguments (defaults to ${MAKEOPTS}) and extracts the value set
 # for load-average. For make and ninja based builds this will mean new jobs are
@@ -113,15 +114,17 @@ makeopts_jobs() {
 # get excessive due to I/O and not just due to CPU load.
 # Be aware that the returned number might be a floating-point number. Test
 # whether your software supports that.
+# If no limit is specified or --load-average is used without a number, ${inf}
+# (defaults to 999) is returned.
 makeopts_loadavg() {
[[ $# -eq 0 ]] && set -- ${MAKEOPTS}
# This assumes the first .* will be more greedy than the second .*
# since POSIX doesn't specify a non-greedy match (i.e. ".*?").
local lavg=$(echo " $* " | sed -r -n \
-e 
's:.*[[:space:]](-[a-z]*l|--(load-average|max-load)[=[:space:]])[[:space:]]*([0-9]+|[0-9]+\.[0-9]+).*:\3:p'
 \
-   -e 
's:.*[[:space:]](-[a-z]*l|--(load-average|max-load))[[:space:]].*:999:p')
-   # Default to 999 since the default is to not use a load limit.
-   echo ${lavg:-999}
+   -e 
"s:.*[[:space:]](-[a-z]*l|--(load-average|max-load))[[:space:]].*:${2:-999}:p")
+   # Default to ${inf} since the default is to not use a load limit.
+   echo ${lavg:-${2:-999}}
 }
 
 # @FUNCTION: multijob_init
diff --git a/eclass/tests/multiprocessing_makeopts_jobs.sh 
b/eclass/tests/multiprocessing_makeopts_jobs.sh
index a1e43c8b91d7..ef477277ab3b 100755
--- a/eclass/tests/multiprocessing_makeopts_jobs.sh
+++ b/eclass/tests/multiprocessing_makeopts_jobs.sh
@@ -9,7 +9,7 @@ inherit multiprocessing
 
 test-makeopts_jobs() {
local exp=$1; shift
-   tbegin "makeopts_jobs($*) == ${exp}"
+   tbegin "makeopts_jobs($1${2+; inf=${2}}) == ${exp}"
local act=$(makeopts_jobs "$@")
[[ ${act} == "${exp}" ]]
tend $? "Got back: ${act}"
@@ -39,4 +39,7 @@ for (( i = 0; i < ${#tests[@]}; i += 2 )) ; do
test-makeopts_jobs "${tests[i]}" "${tests[i+1]}"
 done
 
+# test custom inf value
+test-makeopts_jobs 645 "-j" 645
+
 texit
diff --git a/eclass/tests/multiprocessing_makeopts_loadavg.sh 
b/eclass/tests/multiprocessing_makeopts_loadavg.sh
index 276b7e70d393..6b976beb1aef 100755
--- a/eclass/tests/multiprocessing_makeopts_loadavg.sh
+++ b/eclass/tests/multiprocessing_makeopts_loadavg.sh
@@ -9,7 +9,7 @@ inherit multiprocessing
 
 test-makeopts_loadavg() {
local exp=$1; shift
-   tbegin "makeopts_loadavg($*) == ${exp}"
+   tbegin "makeopts_loadavg($1${2+; inf=${2}}) == ${exp}"
local act=$(makeopts_loadavg "$@")
[[ ${act} == "${exp}" ]]
tend $? "Got back: ${act}"
@@ -36,4 +36,7 @@ for (( i = 0; i < ${#tests[@]}; i += 2 )) ; do
test-makeopts_loadavg "${tests[i]}" "${tests[i+1]}"
 done
 
+# test custom inf value
+test-makeopts_loadavg 645 "-l" 645
+
 

[gentoo-dev] [PATCH v2] multiprocessing.eclass: Introduce get_nproc() to get no of CPUs

[Michał Górny]

Introduce get_nproc(), a portable 'nproc' wrapper. It uses either
'nproc' or a fallback Python multiprocessing module call to attempt to
determine the number of available processing units.

This can be used e.g. to determine a safe number of jobs to run when
MAKEOPTS specifies unlimited --jobs and the build system in question
does not support --load-average.

// v2: added sysctl call for BSDs
---
 eclass/multiprocessing.eclass | 32 
 1 file changed, 32 insertions(+)

diff --git a/eclass/multiprocessing.eclass b/eclass/multiprocessing.eclass
index 5a5fe9acb56a..3c5dfff2d11c 100644
--- a/eclass/multiprocessing.eclass
+++ b/eclass/multiprocessing.eclass
@@ -53,6 +53,38 @@ bashpid() {
sh -c 'echo ${PPID}'
 }
 
+# @FUNCTION: get_nproc
+# @USAGE: [${fallback:-1}]
+# @DESCRIPTION:
+# Attempt to figure out the number of processing units available.
+# If the value can not be determined, prints the provided fallback
+# instead. If no fallback is provided, defaults to 1.
+get_nproc() {
+   local nproc
+
+   # GNU
+   if type -P nproc &>/dev/null; then
+   nproc=$(nproc)
+   fi
+
+   # BSD
+   if [[ -z ${nproc} ]] && type -P sysctl &>/dev/null; then
+   nproc=$(sysctl -n hw.ncpu 2>/dev/null)
+   fi
+
+   # fallback to python2.6+
+   # note: this may fail (raise NotImplementedError)
+   if [[ -z ${nproc} ]] && type -P python &>/dev/null; then
+   nproc=$(python -c 'import multiprocessing; 
print(multiprocessing.cpu_count());' 2>/dev/null)
+   fi
+
+   if [[ -n ${nproc} ]]; then
+   echo "${nproc}"
+   else
+   echo "${1:-1}"
+   fi
+}
+
 # @FUNCTION: makeopts_jobs
 # @USAGE: [${MAKEOPTS}]
 # @DESCRIPTION:
-- 
2.11.0

Re: [gentoo-dev] [PATCH 2/3] multiprocessing.eclass: Introduce get_nproc() to get no of CPUs

[Mike Gilbert]

On Wed, Dec 14, 2016 at 1:29 PM, Fabian Groffen  wrote:
> On 14-12-2016 13:01:16 -0500, Doug Freed wrote:
>> On Wed, Dec 14, 2016 at 12:48 PM, Nathan Zachary
>>  wrote:
>> > On 14/12/16 10:11, Doug Freed wrote:
>> >>> I somehow doubt that would give me the expected number only, and I lack
>> >>> a BSD install handy to test it.
>> >> $(sysctl -n hw.ncpu)
>> >>
>> > I don't know that the sysctl command works universally:
>> >
>> > # sysctl -n hw.ncpu
>> > sysctl: cannot stat /proc/sys/hw/ncpu: No such file or directory
>> >
>>
>> It's BSD-specific (Darwin may have it too, but I'm not in OS X at the
>> moment, so I can't check), which pretty much describes this branch in
>> the codepath as well.  Linux users will have the nproc command from
>> coreutils.
>
> Yes, Darwin has it too, but the tool lives in /usr/sbin instead:
>
> https://gitweb.gentoo.org/repo/proj/prefix.git/tree/scripts/bootstrap-prefix.sh#n1987
>

Seems like we could borrow that code for the eclass, with some minor
modifications. It should probably use ${CBUILD:-${CHOST}} to cover
cross-compiling.

Another alternative would be to check the userland_BSD and
userland_GNU use flags.

Re: [gentoo-dev] [PATCH 2/3] multiprocessing.eclass: Introduce get_nproc() to get no of CPUs

[Francesco Riosa]

2016-12-14 19:32 GMT+01:00 Nathan Zachary :

> On 14/12/16 12:29, Fabian Groffen wrote:
> > On 14-12-2016 13:01:16 -0500, Doug Freed wrote:
> >> On Wed, Dec 14, 2016 at 12:48 PM, Nathan Zachary
> >>  wrote:
> >>> On 14/12/16 10:11, Doug Freed wrote:
> > I somehow doubt that would give me the expected number only, and I
> lack
> > a BSD install handy to test it.
>  $(sysctl -n hw.ncpu)
> 
> >>> I don't know that the sysctl command works universally:
> >>>
> >>> # sysctl -n hw.ncpu
> >>> sysctl: cannot stat /proc/sys/hw/ncpu: No such file or directory
> >>>
> >> It's BSD-specific (Darwin may have it too, but I'm not in OS X at the
> >> moment, so I can't check), which pretty much describes this branch in
> >> the codepath as well.  Linux users will have the nproc command from
> >> coreutils.
> > Yes, Darwin has it too, but the tool lives in /usr/sbin instead:
> >
> > https://gitweb.gentoo.org/repo/proj/prefix.git/tree/
> scripts/bootstrap-prefix.sh#n1987
> >
> > Fabian
> >
> >
> Ah, yes, I missed the part about it being BSD-specific.
>
> This one-liner certainly isn't as graceful or elegant, but it works:
>
> # cat /proc/cpuinfo | grep 'processor' | wc -l
>

# grep -c processor /proc/cpuinfo

however Documentation/filesystems/proc.txt is very vague on it's content,
just stating it has info on the cpu, better leave this as a backup value
IMHO

Re: [gentoo-dev] Handling ebuild logging output in Portage (Was: gpg: signing failed: Inappropriate ioctl for device)

[james]

On 12/14/2016 12:59 PM, Doug Freed wrote:

On Wed, Dec 14, 2016 at 10:45 AM, Rich Freeman  wrote:

On Wed, Dec 14, 2016 at 10:27 AM, M. J. Everitt  wrote:


I do, but only usually if its the last package of an emerge because
otherwise its lost many many thousands of lines upwards. Thank goodness
for portage's savelog feature. - Actually that reminds me .. someone
mentioned a useful tweak to that, with an appropriate FEATURES switch,
it would categorise the output of the logging system .. must look that
one up again, or poke the wiki team ...





Well pardon me, if I'm miss interpreting here, as there is only this 
fragmented thread in my inbox:: no prior postings. But perhaps folks 
should look at "app-portage/elogv"


Already in place, easy to use, and should be updated with EAPI (5/6) 
based parsing features?


hth,
James






IMO, emailing elogs to root should probably be the default.  By all
means let people turn it off, but I bet a lot of people don't realize
it is an option.


Having just looked at portage's mail code, you can't use the mail
subsystem if you have no mailserver or sendmail binary.  Instead,
it'll just throw an error, so you couldn't have any default Portage
configuration to mail them somewhere.  The current default
configuration appends to ${PORT_LOGDIR}/elog/summary.log with qa, log,
warn, and error levels for every package that outputs any of these
classes.  If PORT_LOGDIR is unset, the target is
/var/log/portage/elog/summary.log.



This goes in all my make.conf files:
PORTAGE_ELOG_CLASSES="warn error log"
PORTAGE_ELOG_SYSTEM="save mail"
PORTAGE_ELOG_MAILURI="a...@a.com smtp.server.address"
PORTAGE_ELOG_MAILSUBJECT="package \${PACKAGE} merged on \${HOST} with notice"

Yes, some packages are a bit spammy and this should be fixed, but in
general it has prevented more headaches than it has caused.


This can't really be fixed in a good way, and I'd really rather it
wasn't anyway.  A [ -z "$REPLACING_VERSIONS" ] test is only valid in
pkg_* phases (and by PMS, REPLACING_VERSIONS doesn't have to be
defined in pkg_pretend or pkg_setup), and in many cases, using
REPLACING_VERSIONS in any way can be difficult to do correctly.  Using
the readme.gentoo eclass wouldn't be an awful way to go if it really
bothers you, but you could also use mail_summary instead of mail to
reduce the mail spam to 1 email per emerge run.

-Doug

Re: [gentoo-dev] [PATCH 2/3] multiprocessing.eclass: Introduce get_nproc() to get no of CPUs

[Nathan Zachary]

On 14/12/16 12:29, Fabian Groffen wrote:
> On 14-12-2016 13:01:16 -0500, Doug Freed wrote:
>> On Wed, Dec 14, 2016 at 12:48 PM, Nathan Zachary
>>  wrote:
>>> On 14/12/16 10:11, Doug Freed wrote:
> I somehow doubt that would give me the expected number only, and I lack
> a BSD install handy to test it.
 $(sysctl -n hw.ncpu)

>>> I don't know that the sysctl command works universally:
>>>
>>> # sysctl -n hw.ncpu
>>> sysctl: cannot stat /proc/sys/hw/ncpu: No such file or directory
>>>
>> It's BSD-specific (Darwin may have it too, but I'm not in OS X at the
>> moment, so I can't check), which pretty much describes this branch in
>> the codepath as well.  Linux users will have the nproc command from
>> coreutils.
> Yes, Darwin has it too, but the tool lives in /usr/sbin instead:
>
> https://gitweb.gentoo.org/repo/proj/prefix.git/tree/scripts/bootstrap-prefix.sh#n1987
>
> Fabian
>
>
Ah, yes, I missed the part about it being BSD-specific.

This one-liner certainly isn't as graceful or elegant, but it works:

# cat /proc/cpuinfo | grep 'processor' | wc -l



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 2/3] multiprocessing.eclass: Introduce get_nproc() to get no of CPUs

[Fabian Groffen]

On 14-12-2016 13:01:16 -0500, Doug Freed wrote:
> On Wed, Dec 14, 2016 at 12:48 PM, Nathan Zachary
>  wrote:
> > On 14/12/16 10:11, Doug Freed wrote:
> >>> I somehow doubt that would give me the expected number only, and I lack
> >>> a BSD install handy to test it.
> >> $(sysctl -n hw.ncpu)
> >>
> > I don't know that the sysctl command works universally:
> >
> > # sysctl -n hw.ncpu
> > sysctl: cannot stat /proc/sys/hw/ncpu: No such file or directory
> >
> 
> It's BSD-specific (Darwin may have it too, but I'm not in OS X at the
> moment, so I can't check), which pretty much describes this branch in
> the codepath as well.  Linux users will have the nproc command from
> coreutils.

Yes, Darwin has it too, but the tool lives in /usr/sbin instead:

https://gitweb.gentoo.org/repo/proj/prefix.git/tree/scripts/bootstrap-prefix.sh#n1987

Fabian


-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

Re: [gentoo-dev] gpg: signing failed: Inappropriate ioctl for device

[Doug Freed]

On Wed, Dec 14, 2016 at 10:52 AM, M. J. Everitt  wrote:
> I would tend to agree that in a sysadmin role this would be very helpful.
>
> At the risk of repeating myself, is there any einfo/elog displayed when
> portage is (first) updated, to alert users of this functionality? A link
> to the wiki page explaining the features [poke wiki team!] mentioned
> would probably be most useful.
>

The PORTAGE_ELOG_* variables are documented in
/usr/share/portage/config/make.conf.example, which is referenced by
the make.conf man page.

-Doug

Re: [gentoo-dev] [PATCH 2/3] multiprocessing.eclass: Introduce get_nproc() to get no of CPUs

[Doug Freed]

On Wed, Dec 14, 2016 at 12:48 PM, Nathan Zachary
 wrote:
> On 14/12/16 10:11, Doug Freed wrote:
>> On Wed, Dec 14, 2016 at 11:04 AM, Michał Górny  wrote:
>>> On Wed, 14 Dec 2016 15:27:25 +0300
>>> Andrew Savchenko  wrote:
>>>
 On Tue, 13 Dec 2016 10:36:15 +0100 Michał Górny wrote:
> +   nproc=$(python -c 'import multiprocessing; 
> print(multiprocessing.cpu_count());' 2>/dev/null)
 This is not portable. E.g. paludis users can have python-less
 system. Adding dev-lang/python to DEPEND will be also a bad idea,
 since this is quite heavy dependency.
>>> You can bikeshed potential circumstances where it wouldn't work for
>>> the next year. Which doesn't change that it would work quite reliably
>>> for the most of Gentoo users.
>>>
 Since on Linux boxes nproc is from coreutils, which is in @system,
 so looks like only *bsd setups are the problem. On FreeBSD
>>> ...and all other operating systems (see: Prefix).
>>>
   sysctl -a | egrep -i 'hw.ncpu'
>>> I somehow doubt that would give me the expected number only, and I lack
>>> a BSD install handy to test it.
>> $(sysctl -n hw.ncpu)
>>
> I don't know that the sysctl command works universally:
>
> # sysctl -n hw.ncpu
> sysctl: cannot stat /proc/sys/hw/ncpu: No such file or directory
>

It's BSD-specific (Darwin may have it too, but I'm not in OS X at the
moment, so I can't check), which pretty much describes this branch in
the codepath as well.  Linux users will have the nproc command from
coreutils.

-Doug

[gentoo-dev] Handling ebuild logging output in Portage (Was: gpg: signing failed: Inappropriate ioctl for device)

[Doug Freed]

On Wed, Dec 14, 2016 at 10:45 AM, Rich Freeman  wrote:
> On Wed, Dec 14, 2016 at 10:27 AM, M. J. Everitt  wrote:
>>
>> I do, but only usually if its the last package of an emerge because
>> otherwise its lost many many thousands of lines upwards. Thank goodness
>> for portage's savelog feature. - Actually that reminds me .. someone
>> mentioned a useful tweak to that, with an appropriate FEATURES switch,
>> it would categorise the output of the logging system .. must look that
>> one up again, or poke the wiki team ...
>>
>
> IMO, emailing elogs to root should probably be the default.  By all
> means let people turn it off, but I bet a lot of people don't realize
> it is an option.

Having just looked at portage's mail code, you can't use the mail
subsystem if you have no mailserver or sendmail binary.  Instead,
it'll just throw an error, so you couldn't have any default Portage
configuration to mail them somewhere.  The current default
configuration appends to ${PORT_LOGDIR}/elog/summary.log with qa, log,
warn, and error levels for every package that outputs any of these
classes.  If PORT_LOGDIR is unset, the target is
/var/log/portage/elog/summary.log.

>
> This goes in all my make.conf files:
> PORTAGE_ELOG_CLASSES="warn error log"
> PORTAGE_ELOG_SYSTEM="save mail"
> PORTAGE_ELOG_MAILURI="a...@a.com smtp.server.address"
> PORTAGE_ELOG_MAILSUBJECT="package \${PACKAGE} merged on \${HOST} with notice"
>
> Yes, some packages are a bit spammy and this should be fixed, but in
> general it has prevented more headaches than it has caused.

This can't really be fixed in a good way, and I'd really rather it
wasn't anyway.  A [ -z "$REPLACING_VERSIONS" ] test is only valid in
pkg_* phases (and by PMS, REPLACING_VERSIONS doesn't have to be
defined in pkg_pretend or pkg_setup), and in many cases, using
REPLACING_VERSIONS in any way can be difficult to do correctly.  Using
the readme.gentoo eclass wouldn't be an awful way to go if it really
bothers you, but you could also use mail_summary instead of mail to
reduce the mail spam to 1 email per emerge run.

-Doug

Re: [gentoo-dev] [PATCH 2/3] multiprocessing.eclass: Introduce get_nproc() to get no of CPUs

[Nathan Zachary]

On 14/12/16 10:11, Doug Freed wrote:
> On Wed, Dec 14, 2016 at 11:04 AM, Michał Górny  wrote:
>> On Wed, 14 Dec 2016 15:27:25 +0300
>> Andrew Savchenko  wrote:
>>
>>> On Tue, 13 Dec 2016 10:36:15 +0100 Michał Górny wrote:
 +   nproc=$(python -c 'import multiprocessing; 
 print(multiprocessing.cpu_count());' 2>/dev/null)
>>> This is not portable. E.g. paludis users can have python-less
>>> system. Adding dev-lang/python to DEPEND will be also a bad idea,
>>> since this is quite heavy dependency.
>> You can bikeshed potential circumstances where it wouldn't work for
>> the next year. Which doesn't change that it would work quite reliably
>> for the most of Gentoo users.
>>
>>> Since on Linux boxes nproc is from coreutils, which is in @system,
>>> so looks like only *bsd setups are the problem. On FreeBSD
>> ...and all other operating systems (see: Prefix).
>>
>>>   sysctl -a | egrep -i 'hw.ncpu'
>> I somehow doubt that would give me the expected number only, and I lack
>> a BSD install handy to test it.
> $(sysctl -n hw.ncpu)
>
I don't know that the sysctl command works universally:

# sysctl -n hw.ncpu
sysctl: cannot stat /proc/sys/hw/ncpu: No such file or directory



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Help wanted with www-client/chromium

[J. Roeleveld]

On December 14, 2016 2:40:45 PM GMT+01:00, Andrey Utkin 
 wrote:
>On Tue, Dec 13, 2016 at 06:00:25PM -0500, Mike Gilbert wrote:
>> Keeping up with the frequent Chromium releases is quite a chore.
>> Recently, phajdan.jr has been slacking on the masked dev channel
>> updates due a hardware problem, so I have been spending additional
>> time on them.
>> 
>> If there are any developers with relatively fast hardware that could
>> take on the stable and/or beta channel updates, that would be most
>> appreciated. This is also something that could be done by a trusted
>> user.
>> 
>> Help with the masked dev channel is also welcome -- especially
>testing
>> the various USE flags and unbundling libraries.
>
>Have reasonably powerful amd64 hardware, can try nightly runs.
>
>Not an affiliated gentoo developer.
>
>I guess it would be best to make up collectively a tiny git repo with
>scripts which do exactly what is needed?
>
>First of all it could be a set of chromium builds with different use
>flags (a set of such configurations needs to be defined), saved as
>binary packages, so that all the builds could be tested at once by
>unpacking every build, in turn. All build logs must be saved for
>review,
>and failures should be reported. Makes sense? Ideas? Comments?

I could run this automatically evey night.
Inside a set of different chroots which sync against the tree then try to 
install and package the latest ~amd64 version with a USE combination set per 
chroot.

The resulting build logs can be emailed automatically and binary packages 
uploaded to a specified location. I also have reasonably fast hardware 
available.

If similar activities would be useful for other packages. That should be 
possible as well.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-dev] [PATCH 2/3] multiprocessing.eclass: Introduce get_nproc() to get no of CPUs

[Doug Freed]

On Wed, Dec 14, 2016 at 11:04 AM, Michał Górny  wrote:
> On Wed, 14 Dec 2016 15:27:25 +0300
> Andrew Savchenko  wrote:
>
>> On Tue, 13 Dec 2016 10:36:15 +0100 Michał Górny wrote:
>> > +   nproc=$(python -c 'import multiprocessing; 
>> > print(multiprocessing.cpu_count());' 2>/dev/null)
>>
>> This is not portable. E.g. paludis users can have python-less
>> system. Adding dev-lang/python to DEPEND will be also a bad idea,
>> since this is quite heavy dependency.
>
> You can bikeshed potential circumstances where it wouldn't work for
> the next year. Which doesn't change that it would work quite reliably
> for the most of Gentoo users.
>
>> Since on Linux boxes nproc is from coreutils, which is in @system,
>> so looks like only *bsd setups are the problem. On FreeBSD
>
> ...and all other operating systems (see: Prefix).
>
>>   sysctl -a | egrep -i 'hw.ncpu'
>
> I somehow doubt that would give me the expected number only, and I lack
> a BSD install handy to test it.

$(sysctl -n hw.ncpu)

Re: [gentoo-dev] [PATCH 3/3] multiprocessing.eclass: Support passing custom inf values for getters

[Michał Górny]

On Wed, 14 Dec 2016 15:30:06 +0300
Andrew Savchenko  wrote:

> On Tue, 13 Dec 2016 10:36:16 +0100 Michał Górny wrote:
> > Support passing custom values for 'infinity' in makeopts_jobs()
> > and makeopts_loadavg(). This can be used e.g. when a build system does
> > not support --loadavg, and therefore '--jobs 999' would most likely
> > be a really bad idea. Combined with get_nproc(), this can be used to
> > provide a sane replacement instead.
> > ---
> >  eclass/multiprocessing.eclass | 17 ++---
> >  1 file changed, 10 insertions(+), 7 deletions(-)
> > 
> > diff --git a/eclass/multiprocessing.eclass b/eclass/multiprocessing.eclass
> > index 0d241cdc15b6..b7d5f435f888 100644
> > --- a/eclass/multiprocessing.eclass
> > +++ b/eclass/multiprocessing.eclass
> > @@ -79,26 +79,27 @@ get_nproc() {
> >  }
> >  
> >  # @FUNCTION: makeopts_jobs
> > -# @USAGE: [${MAKEOPTS}]
> > +# @USAGE: [${MAKEOPTS}] [${inf:-999}]
> >  # @DESCRIPTION:
> >  # Searches the arguments (defaults to ${MAKEOPTS}) and extracts the jobs 
> > number
> >  # specified therein.  Useful for running non-make tools in parallel too.
> >  # i.e. if the user has MAKEOPTS=-j9, this will echo "9" -- we can't return 
> > the
> >  # number as bash normalizes it to [0, 255].  If the flags haven't 
> > specified a
> >  # -j flag, then "1" is shown as that is the default `make` uses.  Since 
> > there's
> > -# no way to represent infinity, we return 999 if the user has -j without a 
> > number.
> > +# no way to represent infinity, we return ${inf} (defaults to 999) if the 
> > user
> > +# has -j without a number.
> >  makeopts_jobs() {
> > [[ $# -eq 0 ]] && set -- ${MAKEOPTS}
> > # This assumes the first .* will be more greedy than the second .*
> > # since POSIX doesn't specify a non-greedy match (i.e. ".*?").
> > local jobs=$(echo " $* " | sed -r -n \
> > -e 
> > 's:.*[[:space:]](-[a-z]*j|--jobs[=[:space:]])[[:space:]]*([0-9]+).*:\2:p' \
> > -   -e 's:.*[[:space:]](-[a-z]*j|--jobs)[[:space:]].*:999:p')
> > +   -e "s:.*[[:space:]](-[a-z]*j|--jobs)[[:space:]].*:${2:-999}:p")
> > echo ${jobs:-1}
> >  }
> >  
> >  # @FUNCTION: makeopts_loadavg
> > -# @USAGE: [${MAKEOPTS}]
> > +# @USAGE: [${MAKEOPTS}] [${inf:-999}]
> >  # @DESCRIPTION:
> >  # Searches the arguments (defaults to ${MAKEOPTS}) and extracts the value 
> > set
> >  # for load-average. For make and ninja based builds this will mean new 
> > jobs are
> > @@ -106,15 +107,17 @@ makeopts_jobs() {
> >  # get excessive due to I/O and not just due to CPU load.
> >  # Be aware that the returned number might be a floating-point number. Test
> >  # whether your software supports that.
> > +# If no limit is specified or --load-average is used without a number, 
> > ${inf}
> > +# (defaults to 999) is returned.  
> 
> Why not to feed default ${inf} from get_nproc() by default?
> This will make ebuild writing easier.

Maybe it would. However, I didn't want to change the existing behavior.

Most importantly, that would mean that for people with '-j -l XXX'
the eclass would suddenly changed from '-j 999 -l XXX' to
'-j 2 -l XXX', i.e. defeat the purpose of original --jobs.

As the commit message says, the main use for nproc is for stuff that
doesn't support --loadavg or follow regular rules. SCons, various
multiprocessing test suites...

-- 
Best regards,
Michał Górny



pgpBHNkM7RI9f.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 2/3] multiprocessing.eclass: Introduce get_nproc() to get no of CPUs

[Michał Górny]

On Wed, 14 Dec 2016 15:27:25 +0300
Andrew Savchenko  wrote:

> On Tue, 13 Dec 2016 10:36:15 +0100 Michał Górny wrote:
> > Introduce get_nproc(), a portable 'nproc' wrapper. It uses either
> > 'nproc' or a fallback Python multiprocessing module call to attempt to
> > determine the number of available processing units.
> > 
> > This can be used e.g. to determine a safe number of jobs to run when
> > MAKEOPTS specifies unlimited --jobs and the build system in question
> > does not support --load-average.
> > ---
> >  eclass/multiprocessing.eclass | 25 +
> >  1 file changed, 25 insertions(+)
> > 
> > diff --git a/eclass/multiprocessing.eclass b/eclass/multiprocessing.eclass
> > index 5a5fe9acb56a..0d241cdc15b6 100644
> > --- a/eclass/multiprocessing.eclass
> > +++ b/eclass/multiprocessing.eclass
> > @@ -53,6 +53,31 @@ bashpid() {
> > sh -c 'echo ${PPID}'
> >  }
> >  
> > +# @FUNCTION: get_nproc
> > +# @USAGE: [${fallback:-1}]
> > +# @DESCRIPTION:
> > +# Attempt to figure out the number of processing units available.
> > +# If the value can not be determined, prints the provided fallback
> > +# instead. If no fallback is provided, defaults to 1.
> > +get_nproc() {
> > +   local nproc
> > +
> > +   if type -P nproc &>/dev/null; then
> > +   # GNU
> > +   nproc=$(nproc)
> > +   elif type -P python &>/dev/null; then
> > +   # fallback to python2.6+
> > +   # note: this may fail (raise NotImplementedError)
> > +   nproc=$(python -c 'import multiprocessing; 
> > print(multiprocessing.cpu_count());' 2>/dev/null)  
> 
> This is not portable. E.g. paludis users can have python-less
> system. Adding dev-lang/python to DEPEND will be also a bad idea,
> since this is quite heavy dependency.

You can bikeshed potential circumstances where it wouldn't work for
the next year. Which doesn't change that it would work quite reliably
for the most of Gentoo users.

> Since on Linux boxes nproc is from coreutils, which is in @system,
> so looks like only *bsd setups are the problem. On FreeBSD

...and all other operating systems (see: Prefix).

>   sysctl -a | egrep -i 'hw.ncpu'

I somehow doubt that would give me the expected number only, and I lack
a BSD install handy to test it.

> > +   fi
> > +
> > +   if [[ -n ${nproc} ]]; then
> > +   echo "${nproc}"
> > +   else
> > +   echo "${1:-1}"
> > +   fi
> > +}
> > +
> >  # @FUNCTION: makeopts_jobs
> >  # @USAGE: [${MAKEOPTS}]
> >  # @DESCRIPTION:  

-- 
Best regards,
Michał Górny



pgpaSLTS2jNsx.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Ada project needs your help!

[M. J. Everitt]

On 14/12/16 15:47, Michał Górny wrote:
> On Wed, 14 Dec 2016 08:30:00 +
> "M. J. Everitt"  wrote:
>
>> On 14/12/16 08:26, Christopher Head wrote:
>>> On Sun, 11 Dec 2016 16:59:50 +0100
>>> Michał Górny  wrote:
>>>  
 Hello, everyone.

 The Ada project seriously needs help. For some time already, it has no
 active developers (George is retiring), and a lot of bugs needing
 attention.

 The packages maintained by aga@g.o are:

 app-eselect/eselect-gnat
 dev-ada/asis-gcc
 dev-ada/charles
 dev-lang/gnat-gcc
 virtual/ada
 virtual/gnat

 Since the Ada subsystem in Gentoo is practically unmaintained now
 and has only those two packages, the alternative is to lastrite it
 all.

 Is anyone interested in Ada? Any comments?
  
>>> I notice sci-electronics/ghdl is not in this list. Is it considered
>>> part of this? It depends on gnat-gcc. I guess it would also be lost if
>>> the above were given last rites?  
>> Following this theme, what does the dependency list look like Michał ?
> Well, to be honest I didn't really think it would come to that.
>
> But if you insist, there are two dependencies:
>
>   net-mail/topal
>   sci-electronics/ghdl
>
> The first one is dead and in process of being removed (waiting on
> stablereq of newer alpine). With it gone, we'd also get rid of some
> ugly hacks to net-libs/c-client (and with Alpine gone, we'd even get
> rid of more hacks!)
>
> So the only real consumer is GHDL -- yet another case when someone
> thought it'd be fun to use a fringe language to implement something
> useful... However, it seems to be undermaintained in Gentoo as well,
> not bumped for a long time.
>
Thanks for that, and I see you filed a PR on GH to get the CI tests done.

I guess we could bike-shed for a few weeks on here, and put to council
for a final vote in, say, February?!

Just my 3c ofc :]



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] gpg: signing failed: Inappropriate ioctl for device

[M. J. Everitt]

On 14/12/16 15:45, Rich Freeman wrote:
> On Wed, Dec 14, 2016 at 10:27 AM, M. J. Everitt  wrote:
>> I do, but only usually if its the last package of an emerge because
>> otherwise its lost many many thousands of lines upwards. Thank goodness
>> for portage's savelog feature. - Actually that reminds me .. someone
>> mentioned a useful tweak to that, with an appropriate FEATURES switch,
>> it would categorise the output of the logging system .. must look that
>> one up again, or poke the wiki team ...
>>
> IMO, emailing elogs to root should probably be the default.  By all
> means let people turn it off, but I bet a lot of people don't realize
> it is an option.
>
> This goes in all my make.conf files:
> PORTAGE_ELOG_CLASSES="warn error log"
> PORTAGE_ELOG_SYSTEM="save mail"
> PORTAGE_ELOG_MAILURI="a...@a.com smtp.server.address"
> PORTAGE_ELOG_MAILSUBJECT="package \${PACKAGE} merged on \${HOST} with notice"
>
> Yes, some packages are a bit spammy and this should be fixed, but in
> general it has prevented more headaches than it has caused.
>
I would tend to agree that in a sysadmin role this would be very helpful.

At the risk of repeating myself, is there any einfo/elog displayed when
portage is (first) updated, to alert users of this functionality? A link
to the wiki page explaining the features [poke wiki team!] mentioned
would probably be most useful.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Ada project needs your help!

[Michał Górny]

On Wed, 14 Dec 2016 08:30:00 +
"M. J. Everitt"  wrote:

> On 14/12/16 08:26, Christopher Head wrote:
> > On Sun, 11 Dec 2016 16:59:50 +0100
> > Michał Górny  wrote:
> >  
> >> Hello, everyone.
> >>
> >> The Ada project seriously needs help. For some time already, it has no
> >> active developers (George is retiring), and a lot of bugs needing
> >> attention.
> >>
> >> The packages maintained by aga@g.o are:
> >>
> >> app-eselect/eselect-gnat
> >> dev-ada/asis-gcc
> >> dev-ada/charles
> >> dev-lang/gnat-gcc
> >> virtual/ada
> >> virtual/gnat
> >>
> >> Since the Ada subsystem in Gentoo is practically unmaintained now
> >> and has only those two packages, the alternative is to lastrite it
> >> all.
> >>
> >> Is anyone interested in Ada? Any comments?
> >>  
> > I notice sci-electronics/ghdl is not in this list. Is it considered
> > part of this? It depends on gnat-gcc. I guess it would also be lost if
> > the above were given last rites?  
> Following this theme, what does the dependency list look like Michał ?

Well, to be honest I didn't really think it would come to that.

But if you insist, there are two dependencies:

  net-mail/topal
  sci-electronics/ghdl

The first one is dead and in process of being removed (waiting on
stablereq of newer alpine). With it gone, we'd also get rid of some
ugly hacks to net-libs/c-client (and with Alpine gone, we'd even get
rid of more hacks!)

So the only real consumer is GHDL -- yet another case when someone
thought it'd be fun to use a fringe language to implement something
useful... However, it seems to be undermaintained in Gentoo as well,
not bumped for a long time.

-- 
Best regards,
Michał Górny



pgpgR7Xpv_Gel.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] gpg: signing failed: Inappropriate ioctl for device

[Rich Freeman]

On Wed, Dec 14, 2016 at 10:27 AM, M. J. Everitt  wrote:
>
> I do, but only usually if its the last package of an emerge because
> otherwise its lost many many thousands of lines upwards. Thank goodness
> for portage's savelog feature. - Actually that reminds me .. someone
> mentioned a useful tweak to that, with an appropriate FEATURES switch,
> it would categorise the output of the logging system .. must look that
> one up again, or poke the wiki team ...
>

IMO, emailing elogs to root should probably be the default.  By all
means let people turn it off, but I bet a lot of people don't realize
it is an option.

This goes in all my make.conf files:
PORTAGE_ELOG_CLASSES="warn error log"
PORTAGE_ELOG_SYSTEM="save mail"
PORTAGE_ELOG_MAILURI="a...@a.com smtp.server.address"
PORTAGE_ELOG_MAILSUBJECT="package \${PACKAGE} merged on \${HOST} with notice"

Yes, some packages are a bit spammy and this should be fixed, but in
general it has prevented more headaches than it has caused.

-- 
Rich

Re: [gentoo-dev] gpg: signing failed: Inappropriate ioctl for device

[M. J. Everitt]

On 14/12/16 14:57, Mike Gilbert wrote:
> On Wed, Dec 14, 2016 at 9:07 AM, M. J. Everitt  wrote:
>> On 14/12/16 13:53, Mike Gilbert wrote:
>>> On Wed, Dec 14, 2016 at 7:56 AM, Mart Raudsepp  wrote:
 Ühel kenal päeval, K, 14.12.2016 kell 15:35, kirjutas Andrew Savchenko:
> This is not a workaround, but officially recommended practice, from
> man gpg-agent:
>
> You should always add the following lines to your .bashrc or
> whatever initialization file is used for all shell invocations:
>
> GPG_TTY=$(tty)
> export GPG_TTY
 Then the packages or eselect pinentry or whatever should be taking care
 of it, not have users have to mess with .bashrc to have stuff work.
>>> This is not practical.
>>>
>>> Adding it to the global /etc/bashrc is a bad idea. It would slow down
>>> every shell startup (fork/exec), even for users who do not actively
>>> use gpg (like root).
>>>
>>> Also, there is no way to know what shell each gpg user will be using.
>>>
>> Sounds to me like a perfect candidate for an elog/einfo, no??
> Who reads those? ;-)
>
> It's not a bad idea though.
>
I do, but only usually if its the last package of an emerge because
otherwise its lost many many thousands of lines upwards. Thank goodness
for portage's savelog feature. - Actually that reminds me .. someone
mentioned a useful tweak to that, with an appropriate FEATURES switch,
it would categorise the output of the logging system .. must look that
one up again, or poke the wiki team ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] gpg: signing failed: Inappropriate ioctl for device

[Mike Gilbert]

On Wed, Dec 14, 2016 at 9:07 AM, M. J. Everitt  wrote:
> On 14/12/16 13:53, Mike Gilbert wrote:
>> On Wed, Dec 14, 2016 at 7:56 AM, Mart Raudsepp  wrote:
>>> Ühel kenal päeval, K, 14.12.2016 kell 15:35, kirjutas Andrew Savchenko:
 This is not a workaround, but officially recommended practice, from
 man gpg-agent:

 You should always add the following lines to your .bashrc or
 whatever initialization file is used for all shell invocations:

 GPG_TTY=$(tty)
 export GPG_TTY
>>> Then the packages or eselect pinentry or whatever should be taking care
>>> of it, not have users have to mess with .bashrc to have stuff work.
>> This is not practical.
>>
>> Adding it to the global /etc/bashrc is a bad idea. It would slow down
>> every shell startup (fork/exec), even for users who do not actively
>> use gpg (like root).
>>
>> Also, there is no way to know what shell each gpg user will be using.
>>
> Sounds to me like a perfect candidate for an elog/einfo, no??

Who reads those? ;-)

It's not a bad idea though.

Re: [gentoo-dev] gpg: signing failed: Inappropriate ioctl for device

[M. J. Everitt]

On 14/12/16 13:53, Mike Gilbert wrote:
> On Wed, Dec 14, 2016 at 7:56 AM, Mart Raudsepp  wrote:
>> Ühel kenal päeval, K, 14.12.2016 kell 15:35, kirjutas Andrew Savchenko:
>>> This is not a workaround, but officially recommended practice, from
>>> man gpg-agent:
>>>
>>> You should always add the following lines to your .bashrc or
>>> whatever initialization file is used for all shell invocations:
>>>
>>> GPG_TTY=$(tty)
>>> export GPG_TTY
>> Then the packages or eselect pinentry or whatever should be taking care
>> of it, not have users have to mess with .bashrc to have stuff work.
> This is not practical.
>
> Adding it to the global /etc/bashrc is a bad idea. It would slow down
> every shell startup (fork/exec), even for users who do not actively
> use gpg (like root).
>
> Also, there is no way to know what shell each gpg user will be using.
>
Sounds to me like a perfect candidate for an elog/einfo, no??



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] gpg: signing failed: Inappropriate ioctl for device

[Mike Gilbert]

On Wed, Dec 14, 2016 at 7:56 AM, Mart Raudsepp  wrote:
> Ühel kenal päeval, K, 14.12.2016 kell 15:35, kirjutas Andrew Savchenko:
>> On Wed, 14 Dec 2016 11:16:58 +0200 Mart Raudsepp wrote:
>> >
>> > Ühel kenal päeval, K, 14.12.2016 kell 13:08, kirjutas Sam Jorna:
>> > >
>> > > On Mon, Dec 12, 2016 at 02:35:28PM +1100, Sam Jorna wrote:
>> > > >
>> > > >
>> > > > On Mon, Dec 12, 2016 at 09:34:21AM +0700, gro...@gentoo.org
>> > > > wrote:
>> > > > >
>> > > > >
>> > > > > On Sun, 11 Dec 2016, Kristian Fiskerstrand wrote:
>> > > > > >
>> > > > > >
>> > > > > > On 12/11/2016 03:13 PM, gro...@gentoo.org wrote:
>> > > > > > >
>> > > > > > >
>> > > > > > > gpg: signing failed: Inappropriate ioctl for device
>> > > > > > this might indicate a want for export GPG_TTY=$(tty)
>> > > > > I don't understand what has really happened. I removed my
>> > > > > last
>> > > > > commit, an
>> > > > > attempt to commit it again failed with gpg: signing failed.
>> > > > > Then
>> > > > > I logged
>> > > > > out of the box on which I have the git tree (I log in this
>> > > > > box
>> > > > > via ssh),
>> > > > > and logged in again. After that the commit succeeded.
>> > > >
>> > > > I was also getting some odd issues with commit signing, though
>> > > > it
>> > > > seemed
>> > > > to settle for me when I switched to pinentry-curses (since I
>> > > > use
>> > > > awesome), so I figured it was probably a local issue. Perhaps
>> > > > there's a
>> > > > wider problem here?
>> > >
>> > > If anyone else is getting this, it seems to be resolved by
>> > > exporting
>> > > GPG_TTY=$(tty) either immediately before attempting to sign or in
>> > > your
>> > > shell ~/.*rc file.
>> >
>> > I'd consider this a temporary workaround. The real issue would just
>> > be
>> > workarounded with this, which is nice to get something committed,
>> > but
>> > not so nice longterm.
>> > I had similar issues, but it turned out some pinentry issues for me
>> > iirc, so properly fixed by now and not needing such hackery
>> > anymore.
>>
>> This is not a workaround, but officially recommended practice, from
>> man gpg-agent:
>>
>> You should always add the following lines to your .bashrc or
>> whatever initialization file is used for all shell invocations:
>>
>> GPG_TTY=$(tty)
>> export GPG_TTY
>
> Then the packages or eselect pinentry or whatever should be taking care
> of it, not have users have to mess with .bashrc to have stuff work.

This is not practical.

Adding it to the global /etc/bashrc is a bad idea. It would slow down
every shell startup (fork/exec), even for users who do not actively
use gpg (like root).

Also, there is no way to know what shell each gpg user will be using.

Re: [gentoo-dev] Help wanted with www-client/chromium

[Andrey Utkin]

On Tue, Dec 13, 2016 at 06:00:25PM -0500, Mike Gilbert wrote:
> Keeping up with the frequent Chromium releases is quite a chore.
> Recently, phajdan.jr has been slacking on the masked dev channel
> updates due a hardware problem, so I have been spending additional
> time on them.
> 
> If there are any developers with relatively fast hardware that could
> take on the stable and/or beta channel updates, that would be most
> appreciated. This is also something that could be done by a trusted
> user.
> 
> Help with the masked dev channel is also welcome -- especially testing
> the various USE flags and unbundling libraries.

Have reasonably powerful amd64 hardware, can try nightly runs.

Not an affiliated gentoo developer.

I guess it would be best to make up collectively a tiny git repo with
scripts which do exactly what is needed?

First of all it could be a set of chromium builds with different use
flags (a set of such configurations needs to be defined), saved as
binary packages, so that all the builds could be tested at once by
unpacking every build, in turn. All build logs must be saved for review,
and failures should be reported. Makes sense? Ideas? Comments?

Re: [gentoo-dev] gpg: signing failed: Inappropriate ioctl for device

[Mart Raudsepp]

Ühel kenal päeval, K, 14.12.2016 kell 15:35, kirjutas Andrew Savchenko:
> On Wed, 14 Dec 2016 11:16:58 +0200 Mart Raudsepp wrote:
> > 
> > Ühel kenal päeval, K, 14.12.2016 kell 13:08, kirjutas Sam Jorna:
> > > 
> > > On Mon, Dec 12, 2016 at 02:35:28PM +1100, Sam Jorna wrote:
> > > > 
> > > > 
> > > > On Mon, Dec 12, 2016 at 09:34:21AM +0700, gro...@gentoo.org
> > > > wrote:
> > > > > 
> > > > > 
> > > > > On Sun, 11 Dec 2016, Kristian Fiskerstrand wrote:
> > > > > > 
> > > > > > 
> > > > > > On 12/11/2016 03:13 PM, gro...@gentoo.org wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > gpg: signing failed: Inappropriate ioctl for device
> > > > > > this might indicate a want for export GPG_TTY=$(tty)
> > > > > I don't understand what has really happened. I removed my
> > > > > last
> > > > > commit, an 
> > > > > attempt to commit it again failed with gpg: signing failed.
> > > > > Then
> > > > > I logged 
> > > > > out of the box on which I have the git tree (I log in this
> > > > > box
> > > > > via ssh), 
> > > > > and logged in again. After that the commit succeeded.
> > > > 
> > > > I was also getting some odd issues with commit signing, though
> > > > it
> > > > seemed 
> > > > to settle for me when I switched to pinentry-curses (since I
> > > > use 
> > > > awesome), so I figured it was probably a local issue. Perhaps
> > > > there's a 
> > > > wider problem here?
> > > 
> > > If anyone else is getting this, it seems to be resolved by
> > > exporting 
> > > GPG_TTY=$(tty) either immediately before attempting to sign or in
> > > your 
> > > shell ~/.*rc file.
> > 
> > I'd consider this a temporary workaround. The real issue would just
> > be
> > workarounded with this, which is nice to get something committed,
> > but
> > not so nice longterm.
> > I had similar issues, but it turned out some pinentry issues for me
> > iirc, so properly fixed by now and not needing such hackery
> > anymore.
> 
> This is not a workaround, but officially recommended practice, from
> man gpg-agent:
> 
> You should always add the following lines to your .bashrc or
> whatever initialization file is used for all shell invocations:
> 
> GPG_TTY=$(tty)
> export GPG_TTY

Then the packages or eselect pinentry or whatever should be taking care
of it, not have users have to mess with .bashrc to have stuff work.

I don't have GPG_TTY and it works fine, but I use a graphical password
asking agent.


Mart

Re: [gentoo-dev] gpg: signing failed: Inappropriate ioctl for device

[Andrew Savchenko]

On Wed, 14 Dec 2016 11:16:58 +0200 Mart Raudsepp wrote:
> Ühel kenal päeval, K, 14.12.2016 kell 13:08, kirjutas Sam Jorna:
> > On Mon, Dec 12, 2016 at 02:35:28PM +1100, Sam Jorna wrote:
> > > 
> > > On Mon, Dec 12, 2016 at 09:34:21AM +0700, gro...@gentoo.org wrote:
> > > > 
> > > > On Sun, 11 Dec 2016, Kristian Fiskerstrand wrote:
> > > > > 
> > > > > On 12/11/2016 03:13 PM, gro...@gentoo.org wrote:
> > > > > > 
> > > > > > gpg: signing failed: Inappropriate ioctl for device
> > > > > this might indicate a want for export GPG_TTY=$(tty)
> > > > I don't understand what has really happened. I removed my last
> > > > commit, an 
> > > > attempt to commit it again failed with gpg: signing failed. Then
> > > > I logged 
> > > > out of the box on which I have the git tree (I log in this box
> > > > via ssh), 
> > > > and logged in again. After that the commit succeeded.
> > > 
> > > I was also getting some odd issues with commit signing, though it
> > > seemed 
> > > to settle for me when I switched to pinentry-curses (since I use 
> > > awesome), so I figured it was probably a local issue. Perhaps
> > > there's a 
> > > wider problem here?
> > 
> > If anyone else is getting this, it seems to be resolved by exporting 
> > GPG_TTY=$(tty) either immediately before attempting to sign or in
> > your 
> > shell ~/.*rc file.
> 
> I'd consider this a temporary workaround. The real issue would just be
> workarounded with this, which is nice to get something committed, but
> not so nice longterm.
> I had similar issues, but it turned out some pinentry issues for me
> iirc, so properly fixed by now and not needing such hackery anymore.

This is not a workaround, but officially recommended practice, from
man gpg-agent:

You should always add the following lines to your .bashrc or
whatever initialization file is used for all shell invocations:

GPG_TTY=$(tty)
export GPG_TTY


Best regards,
Andrew Savchenko


pgpTi3IsP7WKU.pgp
Description: PGP signature

Re: [gentoo-dev] [PATCH 3/3] multiprocessing.eclass: Support passing custom inf values for getters

[Andrew Savchenko]

On Tue, 13 Dec 2016 10:36:16 +0100 Michał Górny wrote:
> Support passing custom values for 'infinity' in makeopts_jobs()
> and makeopts_loadavg(). This can be used e.g. when a build system does
> not support --loadavg, and therefore '--jobs 999' would most likely
> be a really bad idea. Combined with get_nproc(), this can be used to
> provide a sane replacement instead.
> ---
>  eclass/multiprocessing.eclass | 17 ++---
>  1 file changed, 10 insertions(+), 7 deletions(-)
> 
> diff --git a/eclass/multiprocessing.eclass b/eclass/multiprocessing.eclass
> index 0d241cdc15b6..b7d5f435f888 100644
> --- a/eclass/multiprocessing.eclass
> +++ b/eclass/multiprocessing.eclass
> @@ -79,26 +79,27 @@ get_nproc() {
>  }
>  
>  # @FUNCTION: makeopts_jobs
> -# @USAGE: [${MAKEOPTS}]
> +# @USAGE: [${MAKEOPTS}] [${inf:-999}]
>  # @DESCRIPTION:
>  # Searches the arguments (defaults to ${MAKEOPTS}) and extracts the jobs 
> number
>  # specified therein.  Useful for running non-make tools in parallel too.
>  # i.e. if the user has MAKEOPTS=-j9, this will echo "9" -- we can't return 
> the
>  # number as bash normalizes it to [0, 255].  If the flags haven't specified a
>  # -j flag, then "1" is shown as that is the default `make` uses.  Since 
> there's
> -# no way to represent infinity, we return 999 if the user has -j without a 
> number.
> +# no way to represent infinity, we return ${inf} (defaults to 999) if the 
> user
> +# has -j without a number.
>  makeopts_jobs() {
>   [[ $# -eq 0 ]] && set -- ${MAKEOPTS}
>   # This assumes the first .* will be more greedy than the second .*
>   # since POSIX doesn't specify a non-greedy match (i.e. ".*?").
>   local jobs=$(echo " $* " | sed -r -n \
>   -e 
> 's:.*[[:space:]](-[a-z]*j|--jobs[=[:space:]])[[:space:]]*([0-9]+).*:\2:p' \
> - -e 's:.*[[:space:]](-[a-z]*j|--jobs)[[:space:]].*:999:p')
> + -e "s:.*[[:space:]](-[a-z]*j|--jobs)[[:space:]].*:${2:-999}:p")
>   echo ${jobs:-1}
>  }
>  
>  # @FUNCTION: makeopts_loadavg
> -# @USAGE: [${MAKEOPTS}]
> +# @USAGE: [${MAKEOPTS}] [${inf:-999}]
>  # @DESCRIPTION:
>  # Searches the arguments (defaults to ${MAKEOPTS}) and extracts the value set
>  # for load-average. For make and ninja based builds this will mean new jobs 
> are
> @@ -106,15 +107,17 @@ makeopts_jobs() {
>  # get excessive due to I/O and not just due to CPU load.
>  # Be aware that the returned number might be a floating-point number. Test
>  # whether your software supports that.
> +# If no limit is specified or --load-average is used without a number, ${inf}
> +# (defaults to 999) is returned.

Why not to feed default ${inf} from get_nproc() by default?
This will make ebuild writing easier.

>  makeopts_loadavg() {
>   [[ $# -eq 0 ]] && set -- ${MAKEOPTS}
>   # This assumes the first .* will be more greedy than the second .*
>   # since POSIX doesn't specify a non-greedy match (i.e. ".*?").
>   local lavg=$(echo " $* " | sed -r -n \
>   -e 
> 's:.*[[:space:]](-[a-z]*l|--(load-average|max-load)[=[:space:]])[[:space:]]*([0-9]+|[0-9]+\.[0-9]+).*:\3:p'
>  \
> - -e 
> 's:.*[[:space:]](-[a-z]*l|--(load-average|max-load))[[:space:]].*:999:p')
> - # Default to 999 since the default is to not use a load limit.
> - echo ${lavg:-999}
> + -e 
> "s:.*[[:space:]](-[a-z]*l|--(load-average|max-load))[[:space:]].*:${2:-999}:p")
> + # Default to ${inf} since the default is to not use a load limit.
> + echo ${lavg:-${2:-999}}
>  }
>  
>  # @FUNCTION: multijob_init


Best regards,
Andrew Savchenko


pgp1LYXCsvhhG.pgp
Description: PGP signature

Re: [gentoo-dev] [PATCH 2/3] multiprocessing.eclass: Introduce get_nproc() to get no of CPUs

[Andrew Savchenko]

On Tue, 13 Dec 2016 10:36:15 +0100 Michał Górny wrote:
> Introduce get_nproc(), a portable 'nproc' wrapper. It uses either
> 'nproc' or a fallback Python multiprocessing module call to attempt to
> determine the number of available processing units.
> 
> This can be used e.g. to determine a safe number of jobs to run when
> MAKEOPTS specifies unlimited --jobs and the build system in question
> does not support --load-average.
> ---
>  eclass/multiprocessing.eclass | 25 +
>  1 file changed, 25 insertions(+)
> 
> diff --git a/eclass/multiprocessing.eclass b/eclass/multiprocessing.eclass
> index 5a5fe9acb56a..0d241cdc15b6 100644
> --- a/eclass/multiprocessing.eclass
> +++ b/eclass/multiprocessing.eclass
> @@ -53,6 +53,31 @@ bashpid() {
>   sh -c 'echo ${PPID}'
>  }
>  
> +# @FUNCTION: get_nproc
> +# @USAGE: [${fallback:-1}]
> +# @DESCRIPTION:
> +# Attempt to figure out the number of processing units available.
> +# If the value can not be determined, prints the provided fallback
> +# instead. If no fallback is provided, defaults to 1.
> +get_nproc() {
> + local nproc
> +
> + if type -P nproc &>/dev/null; then
> + # GNU
> + nproc=$(nproc)
> + elif type -P python &>/dev/null; then
> + # fallback to python2.6+
> + # note: this may fail (raise NotImplementedError)
> + nproc=$(python -c 'import multiprocessing; 
> print(multiprocessing.cpu_count());' 2>/dev/null)

This is not portable. E.g. paludis users can have python-less
system. Adding dev-lang/python to DEPEND will be also a bad idea,
since this is quite heavy dependency.

Since on Linux boxes nproc is from coreutils, which is in @system,
so looks like only *bsd setups are the problem. On FreeBSD
  sysctl -a | egrep -i 'hw.ncpu'
should be sufficient solution.

> + fi
> +
> + if [[ -n ${nproc} ]]; then
> + echo "${nproc}"
> + else
> + echo "${1:-1}"
> + fi
> +}
> +
>  # @FUNCTION: makeopts_jobs
>  # @USAGE: [${MAKEOPTS}]
>  # @DESCRIPTION:


Best regards,
Andrew Savchenko


pgp7joHj9RKQr.pgp
Description: PGP signature

Re: [gentoo-dev] gpg: signing failed: Inappropriate ioctl for device

[Fabian Groffen]

On 14-12-2016 11:16:58 +0200, Mart Raudsepp wrote:
> Ühel kenal päeval, K, 14.12.2016 kell 13:08, kirjutas Sam Jorna:
> > If anyone else is getting this, it seems to be resolved by exporting 
> > GPG_TTY=$(tty) either immediately before attempting to sign or in
> > your 
> > shell ~/.*rc file.
> 
> I'd consider this a temporary workaround. The real issue would just be
> workarounded with this, which is nice to get something committed, but
> not so nice longterm.
> I had similar issues, but it turned out some pinentry issues for me
> iirc, so properly fixed by now and not needing such hackery anymore.

https://www.gnupg.org/documentation/manuals/gnupg-devel/Common-Problems.html

gnupg is just weird like that...

Fabian

-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

Re: [gentoo-dev] gpg: signing failed: Inappropriate ioctl for device

[Mart Raudsepp]

Ühel kenal päeval, K, 14.12.2016 kell 13:08, kirjutas Sam Jorna:
> On Mon, Dec 12, 2016 at 02:35:28PM +1100, Sam Jorna wrote:
> > 
> > On Mon, Dec 12, 2016 at 09:34:21AM +0700, gro...@gentoo.org wrote:
> > > 
> > > On Sun, 11 Dec 2016, Kristian Fiskerstrand wrote:
> > > > 
> > > > On 12/11/2016 03:13 PM, gro...@gentoo.org wrote:
> > > > > 
> > > > > gpg: signing failed: Inappropriate ioctl for device
> > > > this might indicate a want for export GPG_TTY=$(tty)
> > > I don't understand what has really happened. I removed my last
> > > commit, an 
> > > attempt to commit it again failed with gpg: signing failed. Then
> > > I logged 
> > > out of the box on which I have the git tree (I log in this box
> > > via ssh), 
> > > and logged in again. After that the commit succeeded.
> > 
> > I was also getting some odd issues with commit signing, though it
> > seemed 
> > to settle for me when I switched to pinentry-curses (since I use 
> > awesome), so I figured it was probably a local issue. Perhaps
> > there's a 
> > wider problem here?
> 
> If anyone else is getting this, it seems to be resolved by exporting 
> GPG_TTY=$(tty) either immediately before attempting to sign or in
> your 
> shell ~/.*rc file.

I'd consider this a temporary workaround. The real issue would just be
workarounded with this, which is nice to get something committed, but
not so nice longterm.
I had similar issues, but it turned out some pinentry issues for me
iirc, so properly fixed by now and not needing such hackery anymore.


Mart

Re: [gentoo-dev] Ada project needs your help!

[M. J. Everitt]

On 14/12/16 08:26, Christopher Head wrote:
> On Sun, 11 Dec 2016 16:59:50 +0100
> Michał Górny  wrote:
>
>> Hello, everyone.
>>
>> The Ada project seriously needs help. For some time already, it has no
>> active developers (George is retiring), and a lot of bugs needing
>> attention.
>>
>> The packages maintained by aga@g.o are:
>>
>> app-eselect/eselect-gnat
>> dev-ada/asis-gcc
>> dev-ada/charles
>> dev-lang/gnat-gcc
>> virtual/ada
>> virtual/gnat
>>
>> Since the Ada subsystem in Gentoo is practically unmaintained now
>> and has only those two packages, the alternative is to lastrite it
>> all.
>>
>> Is anyone interested in Ada? Any comments?
>>
> I notice sci-electronics/ghdl is not in this list. Is it considered
> part of this? It depends on gnat-gcc. I guess it would also be lost if
> the above were given last rites?
Following this theme, what does the dependency list look like Michał ?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Ada project needs your help!

[Christopher Head]

On Sun, 11 Dec 2016 16:59:50 +0100
Michał Górny  wrote:

> Hello, everyone.
> 
> The Ada project seriously needs help. For some time already, it has no
> active developers (George is retiring), and a lot of bugs needing
> attention.
> 
> The packages maintained by aga@g.o are:
> 
> app-eselect/eselect-gnat
> dev-ada/asis-gcc
> dev-ada/charles
> dev-lang/gnat-gcc
> virtual/ada
> virtual/gnat
> 
> Since the Ada subsystem in Gentoo is practically unmaintained now
> and has only those two packages, the alternative is to lastrite it
> all.
> 
> Is anyone interested in Ada? Any comments?
> 

I notice sci-electronics/ghdl is not in this list. Is it considered
part of this? It depends on gnat-gcc. I guess it would also be lost if
the above were given last rites?
-- 
Christopher Head


pgpXcBNpo99EH.pgp
Description: OpenPGP digital signature