Re: [gentoo-dev] [RFC] Personall Gentoo Installer project pre-beta release

2018-04-13 Thread Christopher Díaz Riveros
El vie, 13-04-2018 a las 23:00 +, Robin H. Johnson escribió:
> On Fri, Apr 13, 2018 at 10:20:23AM -0500, Christopher Díaz Riveros wrote:
> > Still on the TODO list:
> > 
> >  -next step will be to create an ebuild for installer, I may need some help
> > there but it should be pretty simple.
> > 
> >  -still some validations: installer error messages are quite hard to
> > understand
> > if you are installing Gentoo for the first time (my fault), so I'll be
> > working
> > on better error messages.
> > 
> >  -Ask if there is a way to add installer in the liveUSB so that people don't
> > need to install it manually in order to begin a Gentoo installation.
> 
> Once it's a little further from the above (esp having a package), releng
> can potentially include it in the release media (*cd-stage1).
> 
> Hopefully you have a very minimal set of dependencies for it, because
> the installcd is quite slim (by gentoo media standards).
> 

Yes, that was the first requirement for the project, it must keep as minimal as
possible.

I ended up having these runtime dependencies:

GNU tar (runtime)
Iputils (runtime)
GNU coreutils (runtime)
Bash (runtime)
Util-linux (runtime)
GNU grep (runtime)
Ncurses (runtime)

And it is written in Python with support for 3.4 onwards.

I think all those are already present in a cd-stage1 or stage3 :)

I'll polish some rough edges before packaging it, then I'll let you know when I
have a functional package in my overlay so that it can be reviewed too.
 
Regards and thanks,
-- 
Christopher Díaz Riveros
Gentoo Linux Developer
GPG Fingerprint: E517 5ECB 8152 98E4 FEBC  2BAA 4DBB D10F 0FDD 2547

signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [RFC] Personall Gentoo Installer project pre-beta release

2018-04-13 Thread Robin H. Johnson
On Fri, Apr 13, 2018 at 10:20:23AM -0500, Christopher Díaz Riveros wrote:
> Still on the TODO list:
> 
>  -next step will be to create an ebuild for installer, I may need some help
> there but it should be pretty simple.
> 
>  -still some validations: installer error messages are quite hard to 
> understand
> if you are installing Gentoo for the first time (my fault), so I'll be working
> on better error messages.
> 
>  -Ask if there is a way to add installer in the liveUSB so that people don't
> need to install it manually in order to begin a Gentoo installation.
Once it's a little further from the above (esp having a package), releng
can potentially include it in the release media (*cd-stage1).

Hopefully you have a very minimal set of dependencies for it, because
the installcd is quite slim (by gentoo media standards).

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



[gentoo-dev] Re: [PATCH] flag-o-matic.eclass: treat "--param x" as a unit when testing flags

2018-04-13 Thread Sergei Trofimovich
On Fri, 13 Apr 2018 12:21:47 -0400
Mike Gilbert  wrote:

> For clang and gcc, --param consumes the next argument. Testing --param
> and its value separately is nonsensical.
> ---
>  eclass/flag-o-matic.eclass   | 33 +++--
>  eclass/tests/flag-o-matic.sh |  4 ++--
>  2 files changed, 25 insertions(+), 12 deletions(-)
> 
> diff --git a/eclass/flag-o-matic.eclass b/eclass/flag-o-matic.eclass
> index 14b84fbdbebe..5ab14b08d6ec 100644
> --- a/eclass/flag-o-matic.eclass
> +++ b/eclass/flag-o-matic.eclass
> @@ -421,9 +421,9 @@ strip-flags() {
>  test-flag-PROG() {
>   local comp=$1
>   local lang=$2
> - local flag=$3
> + shift 2
>  
> - [[ -z ${comp} || -z ${flag} ]] && return 1
> + [[ -z ${comp} || -z $1 ]] && return 1
>  
>   local cmdline=(
>   $(tc-get${comp})
> @@ -434,11 +434,11 @@ test-flag-PROG() {
>   -c -o /dev/null
>   )
>   if "${cmdline[@]}" -x${lang} - /dev/null ; then
> - cmdline+=( "${flag}" -x${lang} - )
> + cmdline+=( "$@" -x${lang} - )
>   else
>   # XXX: what's the purpose of this? does it even work with
>   # any compiler?
> - cmdline+=( "${flag}" -c -o /dev/null /dev/null )
> + cmdline+=( "$@" -c -o /dev/null /dev/null )
>   fi
>  
>   if ! "${cmdline[@]}" /dev/null; then
> @@ -455,25 +455,25 @@ test-flag-PROG() {
>  # @USAGE: 
>  # @DESCRIPTION:
>  # Returns shell true if  is supported by the C compiler, else returns 
> shell false.
> -test-flag-CC() { test-flag-PROG "CC" c "$1"; }
> +test-flag-CC() { test-flag-PROG "CC" c "$@"; }
>  
>  # @FUNCTION: test-flag-CXX
>  # @USAGE: 
>  # @DESCRIPTION:
>  # Returns shell true if  is supported by the C++ compiler, else 
> returns shell false.
> -test-flag-CXX() { test-flag-PROG "CXX" c++ "$1"; }
> +test-flag-CXX() { test-flag-PROG "CXX" c++ "$@"; }
>  
>  # @FUNCTION: test-flag-F77
>  # @USAGE: 
>  # @DESCRIPTION:
>  # Returns shell true if  is supported by the Fortran 77 compiler, else 
> returns shell false.
> -test-flag-F77() { test-flag-PROG "F77" f77 "$1"; }
> +test-flag-F77() { test-flag-PROG "F77" f77 "$@"; }
>  
>  # @FUNCTION: test-flag-FC
>  # @USAGE: 
>  # @DESCRIPTION:
>  # Returns shell true if  is supported by the Fortran 90 compiler, else 
> returns shell false.
> -test-flag-FC() { test-flag-PROG "FC" f95 "$1"; }
> +test-flag-FC() { test-flag-PROG "FC" f95 "$@"; }
>  
>  test-flags-PROG() {
>   local comp=$1
> @@ -484,8 +484,21 @@ test-flags-PROG() {
>  
>   [[ -z ${comp} ]] && return 1
>  
> - for x ; do
> - test-flag-${comp} "${x}" && flags+=( "${x}" )
> + while (( $# )); do
> + case "$1" in
> + --param)
> + if test-flag-${comp} "$1" "$2"; then
> + flags+=( "$1" "$2" )
> + fi
> + shift 2
> + ;;
> + *)
> + if test-flag-${comp} "$1"; then
> + flags+=( "$1" )
> + fi
> + shift 1
> + ;;
> + esac
>   done
>  
>   echo "${flags[*]}"
> diff --git a/eclass/tests/flag-o-matic.sh b/eclass/tests/flag-o-matic.sh
> index 53af9f862c41..97cd71d710a2 100755
> --- a/eclass/tests/flag-o-matic.sh
> +++ b/eclass/tests/flag-o-matic.sh
> @@ -6,7 +6,7 @@ source tests-common.sh
>  
>  inherit flag-o-matic
>  
> -CFLAGS="-a -b -c=1"
> +CFLAGS="-a -b -c=1 --param l1-cache-size=32"
>  CXXFLAGS="-x -y -z=2"
>  LDFLAGS="-l -m -n=3"
>  ftend() {
> @@ -55,7 +55,7 @@ done <<<"
>  
>  tbegin "strip-unsupported-flags"
>  strip-unsupported-flags
> -[[ ${CFLAGS} == "" ]] && [[ ${CXXFLAGS} == "-z=2" ]] && [[ ${LDFLAGS} == "" 
> ]]
> +[[ ${CFLAGS} == "--param l1-cache-size=32" ]] && [[ ${CXXFLAGS} == "-z=2" ]] 
> && [[ ${LDFLAGS} == "" ]]
>  ftend
>  
>  for var in $(all-flag-vars) ; do
> -- 
> 2.17.0.rc2
> 

Looks good. I personally use '--param=l1-cache-line-size=64' form :)

-- 

  Sergei



[gentoo-portage-dev] [PATCH] rsync: default to sync-rsync-verify-jobs = 1 (bug 650696)

2018-04-13 Thread Zac Medico
Some users have reported that using all processors to verify
manifests results in overloading, therefore default to using
a single processor. On modern hardware, verification of the
gentoo repository completes in less than 20 seconds, so using
multiple processors is not really necessary. Also, gemato-13.0
disables parallel verification due to the unresolved deadlock
issue reported in bug 647964, so this brings the default
portage configuration into alignment with current gemato
behavior.

Bug: https://bugs.gentoo.org/650696
Bug: https://bugs.gentoo.org/647964
---
 cnf/repos.conf  | 1 +
 man/portage.5   | 8 +---
 pym/portage/sync/modules/rsync/rsync.py | 7 ++-
 3 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/cnf/repos.conf b/cnf/repos.conf
index 5759b8b43..987be6462 100644
--- a/cnf/repos.conf
+++ b/cnf/repos.conf
@@ -6,6 +6,7 @@ location = /usr/portage
 sync-type = rsync
 sync-uri = rsync://rsync.gentoo.org/gentoo-portage
 auto-sync = yes
+sync-rsync-verify-jobs = 1
 sync-rsync-verify-metamanifest = yes
 sync-rsync-verify-max-age = 24
 sync-openpgp-key-path = 
/var/lib/gentoo/gkeys/keyrings/gentoo/release/pubring.gpg
diff --git a/man/portage.5 b/man/portage.5
index 2c3a75ccd..6e4089ae5 100644
--- a/man/portage.5
+++ b/man/portage.5
@@ -1105,9 +1105,11 @@ Ignore vcs directories that may be present in the 
repository. It is the
 user's responsibility to set sync-rsync-extra-opts to protect vcs
 directories if appropriate.
 .TP
-.B sync\-rsync\-verify\-jobs
-Number of parallel jobs to use when verifying nested Manifests. Defaults
-to the apparent number of processors.
+.B sync\-rsync\-verify\-jobs = 1
+Number of parallel jobs to use when verifying nested Manifests. When
+set to 0, this will use the apparent number of processors if parallel
+verification is supported by the installed version of app-portage/gemato.
+Defaults to 1.
 .TP
 .B sync\-rsync\-verify\-max\-age
 Warn if repository is older than the specified number of days. Disabled
diff --git a/pym/portage/sync/modules/rsync/rsync.py 
b/pym/portage/sync/modules/rsync/rsync.py
index 763f41699..de8327a55 100644
--- a/pym/portage/sync/modules/rsync/rsync.py
+++ b/pym/portage/sync/modules/rsync/rsync.py
@@ -107,12 +107,17 @@ class RsyncSync(NewBase):
if self.verify_jobs is not None:
try:
self.verify_jobs = int(self.verify_jobs)
-   if self.verify_jobs <= 0:
+   if self.verify_jobs < 0:
raise ValueError(self.verify_jobs)
except ValueError:
writemsg_level("!!! sync-rsync-verify-jobs not 
a positive integer: %s\n" % (self.verify_jobs,),
level=logging.WARNING, noiselevel=-1)
self.verify_jobs = None
+   else:
+   if self.verify_jobs == 0:
+   # Use the apparent number of processors 
if gemato
+   # supports it.
+   self.verify_jobs = None
# Support overriding max age.
self.max_age = self.repo.module_specific_options.get(
'sync-rsync-verify-max-age', '')
-- 
2.13.6




[gentoo-dev] [PATCH] flag-o-matic.eclass: treat "--param x" as a unit when testing flags

2018-04-13 Thread Mike Gilbert
For clang and gcc, --param consumes the next argument. Testing --param
and its value separately is nonsensical.
---
 eclass/flag-o-matic.eclass   | 33 +++--
 eclass/tests/flag-o-matic.sh |  4 ++--
 2 files changed, 25 insertions(+), 12 deletions(-)

diff --git a/eclass/flag-o-matic.eclass b/eclass/flag-o-matic.eclass
index 14b84fbdbebe..5ab14b08d6ec 100644
--- a/eclass/flag-o-matic.eclass
+++ b/eclass/flag-o-matic.eclass
@@ -421,9 +421,9 @@ strip-flags() {
 test-flag-PROG() {
local comp=$1
local lang=$2
-   local flag=$3
+   shift 2
 
-   [[ -z ${comp} || -z ${flag} ]] && return 1
+   [[ -z ${comp} || -z $1 ]] && return 1
 
local cmdline=(
$(tc-get${comp})
@@ -434,11 +434,11 @@ test-flag-PROG() {
-c -o /dev/null
)
if "${cmdline[@]}" -x${lang} - /dev/null ; then
-   cmdline+=( "${flag}" -x${lang} - )
+   cmdline+=( "$@" -x${lang} - )
else
# XXX: what's the purpose of this? does it even work with
# any compiler?
-   cmdline+=( "${flag}" -c -o /dev/null /dev/null )
+   cmdline+=( "$@" -c -o /dev/null /dev/null )
fi
 
if ! "${cmdline[@]}" /dev/null; then
@@ -455,25 +455,25 @@ test-flag-PROG() {
 # @USAGE: 
 # @DESCRIPTION:
 # Returns shell true if  is supported by the C compiler, else returns 
shell false.
-test-flag-CC() { test-flag-PROG "CC" c "$1"; }
+test-flag-CC() { test-flag-PROG "CC" c "$@"; }
 
 # @FUNCTION: test-flag-CXX
 # @USAGE: 
 # @DESCRIPTION:
 # Returns shell true if  is supported by the C++ compiler, else returns 
shell false.
-test-flag-CXX() { test-flag-PROG "CXX" c++ "$1"; }
+test-flag-CXX() { test-flag-PROG "CXX" c++ "$@"; }
 
 # @FUNCTION: test-flag-F77
 # @USAGE: 
 # @DESCRIPTION:
 # Returns shell true if  is supported by the Fortran 77 compiler, else 
returns shell false.
-test-flag-F77() { test-flag-PROG "F77" f77 "$1"; }
+test-flag-F77() { test-flag-PROG "F77" f77 "$@"; }
 
 # @FUNCTION: test-flag-FC
 # @USAGE: 
 # @DESCRIPTION:
 # Returns shell true if  is supported by the Fortran 90 compiler, else 
returns shell false.
-test-flag-FC() { test-flag-PROG "FC" f95 "$1"; }
+test-flag-FC() { test-flag-PROG "FC" f95 "$@"; }
 
 test-flags-PROG() {
local comp=$1
@@ -484,8 +484,21 @@ test-flags-PROG() {
 
[[ -z ${comp} ]] && return 1
 
-   for x ; do
-   test-flag-${comp} "${x}" && flags+=( "${x}" )
+   while (( $# )); do
+   case "$1" in
+   --param)
+   if test-flag-${comp} "$1" "$2"; then
+   flags+=( "$1" "$2" )
+   fi
+   shift 2
+   ;;
+   *)
+   if test-flag-${comp} "$1"; then
+   flags+=( "$1" )
+   fi
+   shift 1
+   ;;
+   esac
done
 
echo "${flags[*]}"
diff --git a/eclass/tests/flag-o-matic.sh b/eclass/tests/flag-o-matic.sh
index 53af9f862c41..97cd71d710a2 100755
--- a/eclass/tests/flag-o-matic.sh
+++ b/eclass/tests/flag-o-matic.sh
@@ -6,7 +6,7 @@ source tests-common.sh
 
 inherit flag-o-matic
 
-CFLAGS="-a -b -c=1"
+CFLAGS="-a -b -c=1 --param l1-cache-size=32"
 CXXFLAGS="-x -y -z=2"
 LDFLAGS="-l -m -n=3"
 ftend() {
@@ -55,7 +55,7 @@ done <<<"
 
 tbegin "strip-unsupported-flags"
 strip-unsupported-flags
-[[ ${CFLAGS} == "" ]] && [[ ${CXXFLAGS} == "-z=2" ]] && [[ ${LDFLAGS} == "" ]]
+[[ ${CFLAGS} == "--param l1-cache-size=32" ]] && [[ ${CXXFLAGS} == "-z=2" ]] 
&& [[ ${LDFLAGS} == "" ]]
 ftend
 
 for var in $(all-flag-vars) ; do
-- 
2.17.0.rc2




Re: [gentoo-dev] [RFC] Personall Gentoo Installer project pre-beta release

2018-04-13 Thread Christopher Díaz Riveros
El vie, 13-04-2018 a las 16:32 +0100, Andrey Utkin escribió:
> Hi,
> 
> First, my appreciation for your work!
> 
> I am not going to check it out myself, but I'd enjoy watching a
> screencast, or at last a series of screenshots, of how it looks and
> works.

That's a good idea Andrey :) Once I consider it stable and pretty enough to
release the official 0.1 version I'll attach a blog entry showing how to use it
on my gentoo blog ;)

Thanks,
-- 
Christopher Díaz Riveros
Gentoo Linux Developer
GPG Fingerprint: E517 5ECB 8152 98E4 FEBC  2BAA 4DBB D10F 0FDD 2547

signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [RFC] Personall Gentoo Installer project pre-beta release

2018-04-13 Thread Andrey Utkin
Hi,

First, my appreciation for your work!

I am not going to check it out myself, but I'd enjoy watching a
screencast, or at last a series of screenshots, of how it looks and
works.


signature.asc
Description: Digital signature


[gentoo-dev] [RFC] Personall Gentoo Installer project pre-beta release

2018-04-13 Thread Christopher Díaz Riveros
Good day devs and users:

A couple of months ago I shared with you a similar email about my personal
project. I'm very glad to say that I'm about to release the 'beta' in a couple
of weeks.

This beta version adds new stuff like:

 -experimental TUI interface: Right now it's only designed to enable a user to
launch the installer from any specific point from installation (selecting a step
from 11 different options). But it is easily scalable to add new windows and
steps into the TUI.

 -internationalization support: Right now installer works on English and
Spanish, it would be awesome if any dev with experience in German (Mein Deutsch
ist sehr verschlechtert und ich brauche viel Übung), or any other language that
you consider would be good to have in the installer.

 -installer now installs itself inside the new Gentoo system to avoid manual
installation inside the new Gentoo system. (Thanks to NP_Hardass for the idea)

Still on the TODO list:

 -next step will be to create an ebuild for installer, I may need some help
there but it should be pretty simple.

 -still some validations: installer error messages are quite hard to understand
if you are installing Gentoo for the first time (my fault), so I'll be working
on better error messages.

 -Ask if there is a way to add installer in the liveUSB so that people don't
need to install it manually in order to begin a Gentoo installation.

As last time, you can see the repo here:

https://github.com/ChrisADR/installer

Hope you have a great weekend,
-- 
Christopher Díaz Riveros
Gentoo Linux Developer
GPG Fingerprint: E517 5ECB 8152 98E4 FEBC  2BAA 4DBB D10F 0FDD 2547

signature.asc
Description: This is a digitally signed message part