Re: [gentoo-dev] Help wanted with www-client/chromium
On Tuesday, December 13, 2016 06:00:25 PM 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. I don't use chromium often, but if it's simply bumping the ebuild and testing if it builds and runs, then that is something I can help with. If there also is a quick method to check if the browser actually renders pages correctly (a few test-sites) then that can be added to the test-cycle. Please contact me off-list if this is sufficient. -- Joost
Re: [gentoo-dev] Re: Cross Post due to technical component - Thanks for all the fish
On 12/13/2016 10:47 AM, Christopher Head wrote: > On December 9, 2016 10:12:54 PM PST, "A. Wilcox" > wrote: >> I think James has perhaps spoken ambiguously, or at least I hope that >> you have misunderstood his proposal. (If you haven't, then he's >> misunderstood mine.) >> >> The point of making it easier to fork is not only for the benefit of >> developers. As James says: >> >>> And then folks running gentoo-proper now can pick and choose which >>> innovations they want to include in the master tree. >> >> The idea being the people who "run" Gentoo, that being the developers >> of Gentoo, can pick what they want from the forks and derivatives, and >> include those improvements in the master tree. Then all Gentoo users, >> and all derivatives of Gentoo, can benefit from those improvements. > > You’re right, I took the word “run” in the sense of “execute” (the OS), not > in the sense of “manage” (the organization). If forks are a way to develop > work destined for upstream, they’re great. It’s when they become a tool for > fragmenting the community (of both users and developers) without any hope of > work being recombined that they become a problem. > Sometimes people don't get along or play politics to fight within an organization. At that point, one is forced to route around the social damage and branch off. It's at the "host"'s discretion whether they want to pull from the fork, and I don't think pressuring or forcing either of those groups to work together would be a good idea. I'm applying this in a general sense, to clarify. It's true that it can create a maintenance burden and sometimes even confusion, but what else can you do about volunteers that can't agree on a way forward for a given project? -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] gpg: signing failed: Inappropriate ioctl for device
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. -- Sam Jorna (wraeth) GnuPG Key: D6180C26 signature.asc Description: Digital signature
[gentoo-dev] Help wanted with www-client/chromium
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.
[gentoo-dev] [warning] the bug queue has 94 bugs
Our bug queue has 94 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
Re: [gentoo-dev] Re: Cross Post due to technical component - Thanks for all the fish
On December 9, 2016 10:12:54 PM PST, "A. Wilcox" wrote: >I think James has perhaps spoken ambiguously, or at least I hope that >you have misunderstood his proposal. (If you haven't, then he's >misunderstood mine.) > >The point of making it easier to fork is not only for the benefit of >developers. As James says: > >> And then folks running gentoo-proper now can pick and choose which >> innovations they want to include in the master tree. > >The idea being the people who "run" Gentoo, that being the developers >of Gentoo, can pick what they want from the forks and derivatives, and >include those improvements in the master tree. Then all Gentoo users, >and all derivatives of Gentoo, can benefit from those improvements. You’re right, I took the word “run” in the sense of “execute” (the OS), not in the sense of “manage” (the organization). If forks are a way to develop work destined for upstream, they’re great. It’s when they become a tool for fragmenting the community (of both users and developers) without any hope of work being recombined that they become a problem. -- Christopher Head
Re: [gentoo-dev] [PATCH 1/1] kernel-2.eclass: Add required @USAGE documentation to functions.
On Tue, Dec 13, 2016 at 8:59 AM, Michael Orlitzky wrote: > On 12/13/2016 06:11 AM, Mike Pagano wrote: >> >> You're absolutely right, Mike. It was the devmanual. >> >> I'm not a fan of having an empty usage. As the devmanual is written >> today, it is not optional. >> > > The devmanual is once again based on the awk script, which vaguely > implies that USAGE is required. For example, some other tags are optional: > > # @EXAMPLE: > # > > but the @USAGE does not say that it is: > > # The format of functions: > # @FUNCTION: foo > # @USAGE: [optional arguments to foo] > # @RETURN: > ... > > From now on, it would make more sense if the awk script conformed to the > devmanual rather than the other way around. I don't see any problem with > amending the devmanual, and then pestering the script maintainers to > play along. The awk script does not generate an error for missing @USAGE, so it isn't even consistent with its own documentation.
Re: [gentoo-dev] [PATCH 1/1] kernel-2.eclass: Add required @USAGE documentation to functions.
On 12/13/2016 06:11 AM, Mike Pagano wrote: > > You're absolutely right, Mike. It was the devmanual. > > I'm not a fan of having an empty usage. As the devmanual is written > today, it is not optional. > The devmanual is once again based on the awk script, which vaguely implies that USAGE is required. For example, some other tags are optional: # @EXAMPLE: # but the @USAGE does not say that it is: # The format of functions: # @FUNCTION: foo # @USAGE: [optional arguments to foo] # @RETURN: ... >From now on, it would make more sense if the awk script conformed to the devmanual rather than the other way around. I don't see any problem with amending the devmanual, and then pestering the script maintainers to play along.
Re: [gentoo-dev] [PATCH 1/1] kernel-2.eclass: Add required @USAGE documentation to functions.
On 12/12/2016 09:49 PM, Mike Gilbert wrote: > On Mon, Dec 12, 2016 at 9:44 PM, Mike Gilbert wrote: >> On Mon, Dec 12, 2016 at 7:34 PM, Mike Pagano wrote: >>> According to PMS, @USAGE is required for functions. >>> This patch only touches comments and no code has been modified. >> >> PMS says nothing on the topic of eclass documentation syntax. >> >> Any requirements are imposed by the eclass-manpages awk script. > > Maybe you were referring to the devmanual (not PMS)? > > https://devmanual.gentoo.org/eclass-writing/index.html > > Personally, I don't think it makes sense to add an empty @USAGE entry > for functions that take no arguments. > You're absolutely right, Mike. It was the devmanual. I'm not a fan of having an empty usage. As the devmanual is written today, it is not optional. I'll leave them in for now, and if the devmanual gets updated, I'll remove them. -- Mike Pagano Gentoo Developer - Kernel Project Gentoo Sources - Lead E-Mail : mpag...@gentoo.org GnuPG FP : 52CC A0B0 F631 0B17 0142 F83F 92A6 DBEC 81F2 B137 Public Key : http://http://pgp.mit.edu/pks/lookup?search=0x92A6DBEC81F2B137&op=index signature.asc Description: OpenPGP digital signature
[gentoo-dev] [PATCH 2/3] multiprocessing.eclass: Introduce get_nproc() to get no of CPUs
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)
+ fi
+
+ if [[ -n ${nproc} ]]; then
+ echo "${nproc}"
+ else
+ echo "${1:-1}"
+ fi
+}
+
# @FUNCTION: makeopts_jobs
# @USAGE: [${MAKEOPTS}]
# @DESCRIPTION:
--
2.11.0
[gentoo-dev] [PATCH 3/3] multiprocessing.eclass: Support passing custom inf values for getters
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.
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
--
2.11.0
[gentoo-dev] [PATCH] multiprocessing.eclass: Improvements for wider use
Hello, Here's a short batch of improvements to multiprocessing.eclass. Patch 1 fixes handling multiple short args, e.g. '-kj'. Patch 2 adds get_nproc() (copied from scons-utils.eclass) that tries to portably determine the number of available CPUs. Patch 3 adds the option to explicitly specify the replacement for unlimited jobs/loadvg in makeopts_*() functions. 2+3 combined makes it possible to provide a safe replacement for unlimited '--jobs' for build systems that do not support limiting '--loadavg'. -- Best regards, Michał Górny
[gentoo-dev] [PATCH 1/3] multiprocessing.eclass: Fix handling multiple short options (e.g. -kj)
Improve the regular expressions to handle parameters consisting of
multiple short options (such as -kj). It should be noted that the code
is not perfect but should handle all common (valid) cases; it could e.g.
incorrectly process a short option followed by string arg such as
'-Wfoo.j' although having this in MAKEOPTS is extremely unlikely.
---
eclass/multiprocessing.eclass| 8
eclass/tests/multiprocessing_makeopts_jobs.sh| 3 +++
eclass/tests/multiprocessing_makeopts_loadavg.sh | 3 +++
3 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/eclass/multiprocessing.eclass b/eclass/multiprocessing.eclass
index 06e004aa1669..5a5fe9acb56a 100644
--- a/eclass/multiprocessing.eclass
+++ b/eclass/multiprocessing.eclass
@@ -67,8 +67,8 @@ makeopts_jobs() {
# 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:]](-j|--jobs[=[:space:]])[[:space:]]*([0-9]+).*:\2:p' \
- -e 's:.*[[:space:]](-j|--jobs)[[:space:]].*:999:p')
+ -e
's:.*[[:space:]](-[a-z]*j|--jobs[=[:space:]])[[:space:]]*([0-9]+).*:\2:p' \
+ -e 's:.*[[:space:]](-[a-z]*j|--jobs)[[:space:]].*:999:p')
echo ${jobs:-1}
}
@@ -86,8 +86,8 @@ makeopts_loadavg() {
# 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:]](-l|--(load-average|max-load)[=[:space:]])[[:space:]]*([0-9]+|[0-9]+\.[0-9]+).*:\3:p'
\
- -e
's:.*[[:space:]](-l|--(load-average|max-load))[[:space:]].*:999:p')
+ -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}
}
diff --git a/eclass/tests/multiprocessing_makeopts_jobs.sh
b/eclass/tests/multiprocessing_makeopts_jobs.sh
index 017d491156a0..a1e43c8b91d7 100755
--- a/eclass/tests/multiprocessing_makeopts_jobs.sh
+++ b/eclass/tests/multiprocessing_makeopts_jobs.sh
@@ -31,6 +31,9 @@ tests=(
7 "-l3 --jobs 7 -w"
4 "-j1 -j 2 --jobs 3 --jobs=4"
8 " -j 8 "
+ 999 "-kj"
+ 4 "-kj4"
+ 5 "-kj 5"
)
for (( i = 0; i < ${#tests[@]}; i += 2 )) ; do
test-makeopts_jobs "${tests[i]}" "${tests[i+1]}"
diff --git a/eclass/tests/multiprocessing_makeopts_loadavg.sh
b/eclass/tests/multiprocessing_makeopts_loadavg.sh
index 12f9d01f9fcd..276b7e70d393 100755
--- a/eclass/tests/multiprocessing_makeopts_loadavg.sh
+++ b/eclass/tests/multiprocessing_makeopts_loadavg.sh
@@ -28,6 +28,9 @@ tests=(
4 "-j1 -j 2 --load-average 3 --load-average=4"
3 " --max-load=3 -x"
8 " -l 8 "
+ 999 "-kl"
+ 4 "-kl4"
+ 5 "-kl 5"
)
for (( i = 0; i < ${#tests[@]}; i += 2 )) ; do
test-makeopts_loadavg "${tests[i]}" "${tests[i+1]}"
--
2.11.0
