[gentoo-dev] Packages up for grabs: oracle-instantclient and others

[Michael Haubenwallner]

Hello!

It turns out that I don't have enough time to maintain these packages any more:

Has reverse dependencies:
* dev-db/oracle-instantclient (no fetch restriction any more)

Obsolete, updating revdeps not initiated yet:
* dev-db/oracle-instantclient-basic
* dev-db/oracle-instantclient-jdbc
* dev-db/oracle-instantclient-odbc
* dev-db/oracle-instantclient-sqlplus

No reverse dependencies:
* dev-db/tora(has one proxy maintainer left)
* mail-mta/nullmailer(has one maintainer left)
* net-libs/openmq-cclient
* net-misc/mico

For Windows based Prefix, as there is no more Prefix developer
having access to Windows machines:

For Cygwin only - which may drop in favor of WSL:
* app-admin/cygwin-rebase
* sys-libs/cygwin-crypt

For native Windows using MSVC, needs either Cygwin or WSL:
* dev-libs/pthreads4w
* sys-devel/parity   (a live build dep has dropped already)

Thanks!
/haubi/

[gentoo-dev] Re: New project: binhost

[Michael Haubenwallner]

On 2/10/21 6:57 PM, Andreas K. Hüttel wrote:
> Hi all, 
> 
> I'm announcing a new project here - "binhost"
> 
> "The Gentoo Binhost project aims to provide readily installable, precompiled 
> packages for a subset of configurations, via central binary package hosting. 
> Currently we are still in the conceptual planning stage. "
> 
> https://wiki.gentoo.org/wiki/Project:Binhost
> 
> If you're interested in helping out, feel free to add yourself on the wiki 
> page.
> 
> Note that I see actually *building* the packages not as the central point of 
> the project (that could be e.g. a side effect of a tinderbox). I'm more 
> concerned about
> * what configurations should we use
> * what portage features are still needed or need improvements (e.g. binpkg 
> signing and verification)
> * how should hosting look like
> * and how we can test this on a limited scale before it goes "into production"
> * ...
> 
> Comments, ideas, flamebaits? :D

To me, rather than build time, the time consuming challenge is to review the
content of make.conf to get the most out of my (usually quite powerful) 
hardware,
when there are updates to Gentoo or even the hardware.

For GSoC 2018 I have drawn the idea of some 'Social Linux Distribution Network',
as in sharing Gentoo config like in some social network, with backing by some
binhost infrastructure to be an optional second step:
https://wiki.gentoo.org/wiki/Google_Summer_of_Code/2018/Ideas#Social_Linux_Distribution_Network

While I unlikely will have enough time to really help out here, I'm a potential 
user
of binhost with a personal focus on most flexible connectivity while using Xfce.

My 2 ct,
/haubi/

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

[Michael Haubenwallner]

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

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

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

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

/haubi/

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

[Michael Haubenwallner]

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

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

Otherwise, the order is irrelevant.

Thanks!
/haubi/

[gentoo-dev] Re: [RFC] Removing obsolete thick Manifest compatibility from MetaManifests

[Michael Haubenwallner]

Hi,

On 10/24/19 2:37 PM, Michał Górny wrote:
> Hello,
> 
> TL;DR: I'd like to disable thick Manifest support in Portage, in order
> to disable some of the compatibility quirks from MetaManifest format. 
> All files would still be verified by gemato.

> 
> WDYT?
> 

I'm using Gentoo Prefix as a Meta Distribution, where I can not use the
Gentoo infrastructure, but have to provide the master services on my own.

While I've been able to set up rsync & distfiles master ~10 years ago,
where I haven't discovered any docs for so far, I feel lost when I think
of setting up additional master services for gemato without some docs.

Facing the removal of thick Manifest support (which I don't want to block
in any way), I've started to search for some docs how to set up these
additional master services to support gemato, but failed.

What I've found is the Infrastructure wiki project, providing a list of
servers maintained by infra, but nothing about how to set them up.

Did I miss something?

Thanks!
/haubi/

[gentoo-dev] Re: [PATCH] prefix.eclass: minor @USAGE fix

[Michael Haubenwallner]

LGTM

On 9/6/19 9:06 PM, Ben Kohler wrote:
> Signed-off-by: Ben Kohler 
> ---
>  eclass/prefix.eclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/eclass/prefix.eclass b/eclass/prefix.eclass
> index 8ae3e3a531d..435e99fdf92 100644
> --- a/eclass/prefix.eclass
> +++ b/eclass/prefix.eclass
> @@ -111,7 +111,7 @@ hprefixify() {
>  }
>  
>  # @FUNCTION: prefixify_ro
> -# @USAGE: prefixify_ro .
> +# @USAGE: 
>  # @DESCRIPTION:
>  # prefixify a read-only file.
>  # copies the files to ${T}, prefixies it, echos the new file.
> 

[gentoo-dev] [PATCH] toolchain.eclass (do_gcc_CYGWINPORTS_patches): avoid bash-4.4ism

[Michael Haubenwallner]

Closes: https://bugs.gentoo.org/690686
---
 eclass/toolchain.eclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index 6bc04b4cbfe..40d46ed0707 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -687,9 +687,9 @@ do_gcc_CYGWINPORTS_patches() {
[[ -n ${CYGWINPORTS_GITREV} ]] || return 0
use elibc_Cygwin || return 0
 
-   local -a patches
local p d="${WORKDIR}/gcc-${CYGWINPORTS_GITREV}"
-   readarray -t patches < <(sed -e '1,/PATCH_URI="/d;/"/,$d' < 
"${d}"/gcc.cygport)
+   # readarray -t is available since bash-4.4 only, #690686
+   local patches=( $(sed -e '1,/PATCH_URI="/d;/"/,$d' < 
"${d}"/gcc.cygport) )
for p in ${patches[*]}; do
epatch "${d}/${p}"
done
-- 
2.21.0

[gentoo-dev] Re: [PATCH] eclass/cmake-utils.eclass: restrict rpath hack to Prefix/rpath

[Michael Haubenwallner]

On 7/15/19 2:45 PM, Michael Palimaka wrote:
> On 7/12/19 3:14 AM, hero...@gentoo.org wrote:
>> From: Benda Xu 
>>
>>    Prefix/standalone does not need it.
>> ---
>>   eclass/cmake-utils.eclass | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
>> index ea1858e9735f..109b584afb39 100644
>> --- a/eclass/cmake-utils.eclass
>> +++ b/eclass/cmake-utils.eclass
>> @@ -612,7 +612,7 @@ cmake-utils_src_configure() {
>>   fi
>>   fi
>>   -    if [[ ${EPREFIX} ]]; then
>> +    if use prefix-guest; then
>>   cat >> "${build_rules}" <<- _EOF_ || die
>>   # in Prefix we need rpath and must ensure cmake gets our 
>> default linker path
>>   # right ... except for Darwin hosts
>>
> 
> This seems to break non-prefix builds, as the prefix-guest USE flag will not 
> exist.
> 

Note that IUSE_IMPLICIT="prefix prefix-guest prefix-stack" is set in the base 
profile
of Gentoo mainline.  So the flag really should "exist" in non-prefix builds as 
well.

/haubi/

[gentoo-dev] Re: [PATCH] xorg-3.eclass: EAUTORECONF_DEPENDS belong to BDEPEND

[Michael Haubenwallner]

On 6/13/19 2:45 PM, James Le Cuirot wrote:
> On Thu, 13 Jun 2019 13:08:15 +0200
> Michael Haubenwallner  wrote:
> 
>> EAUTORECONF_DEPENDS is non-empty for ppc-aix and x86-winnt only.
>> Also, unset variable 'arch' after use.
>> ---
>>  eclass/xorg-3.eclass | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/eclass/xorg-3.eclass b/eclass/xorg-3.eclass
>> index 6ac90a64d59..f135058fba6 100644
>> --- a/eclass/xorg-3.eclass
>> +++ b/eclass/xorg-3.eclass
>> @@ -116,7 +116,8 @@ WANT_AUTOMAKE="latest"
>>  for arch in ${XORG_EAUTORECONF_ARCHES}; do
>>  EAUTORECONF_DEPENDS+=" ${arch}? ( ${EAUTORECONF_DEPEND} )"
>>  done
>> -DEPEND+=" ${EAUTORECONF_DEPENDS}"
>> +unset arch
>> +BDEPEND+=" ${EAUTORECONF_DEPENDS}"
>>  [[ ${XORG_EAUTORECONF} != no ]] && BDEPEND+=" ${EAUTORECONF_DEPEND}"
>>  unset EAUTORECONF_DEPENDS
>>  unset EAUTORECONF_DEPEND
> 
> Apart from the unset, the comment doesn't seem to relate to the actual
> change?

Agreed: The relation should become clear with 15 lines of context.
Or do you mean something else?

Thanks!
/haubi/
From 1eb3709d84b04c4fbbed342de8f5721233e35e2f Mon Sep 17 00:00:00 2001
From: Michael Haubenwallner 
Date: Thu, 13 Jun 2019 12:58:04 +0200
Subject: [PATCH] xorg-3.eclass: EAUTORECONF_DEPENDS belong to BDEPEND

EAUTORECONF_DEPENDS is non-empty for ppc-aix and x86-winnt only.
Also, unset variable 'arch' after use.
---
 eclass/xorg-3.eclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/eclass/xorg-3.eclass b/eclass/xorg-3.eclass
index 6ac90a64d59..f135058fba6 100644
--- a/eclass/xorg-3.eclass
+++ b/eclass/xorg-3.eclass
@@ -104,31 +104,32 @@ fi
 
 # Set up autotools shared dependencies
 # Remember that all versions here MUST be stable
 XORG_EAUTORECONF_ARCHES="ppc-aix x86-winnt"
 EAUTORECONF_DEPEND+="
 	>=sys-devel/libtool-2.2.6a
 	sys-devel/m4"
 if [[ ${PN} != util-macros ]] ; then
 	EAUTORECONF_DEPEND+=" >=x11-misc/util-macros-1.18 >=media-fonts/font-util-1.2.0"
 fi
 WANT_AUTOCONF="latest"
 WANT_AUTOMAKE="latest"
 for arch in ${XORG_EAUTORECONF_ARCHES}; do
 	EAUTORECONF_DEPENDS+=" ${arch}? ( ${EAUTORECONF_DEPEND} )"
 done
-DEPEND+=" ${EAUTORECONF_DEPENDS}"
+unset arch
+BDEPEND+=" ${EAUTORECONF_DEPENDS}"
 [[ ${XORG_EAUTORECONF} != no ]] && BDEPEND+=" ${EAUTORECONF_DEPEND}"
 unset EAUTORECONF_DEPENDS
 unset EAUTORECONF_DEPEND
 
 # @ECLASS-VARIABLE: XORG_STATIC
 # @DESCRIPTION:
 # Enables static-libs useflag. Set to no, if your package gets:
 #
 # QA: configure: WARNING: unrecognized options: --disable-static
 : ${XORG_STATIC:="yes"}
 
 # Add static-libs useflag where useful.
 if [[ ${XORG_STATIC} == yes \
 		&& ${CATEGORY} != app-doc \
 		&& ${CATEGORY} != x11-apps \
-- 
2.19.2



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [PATCH] xorg-3.eclass: EAUTORECONF_DEPENDS belong to BDEPEND

[Michael Haubenwallner]

EAUTORECONF_DEPENDS is non-empty for ppc-aix and x86-winnt only.
Also, unset variable 'arch' after use.
---
 eclass/xorg-3.eclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/eclass/xorg-3.eclass b/eclass/xorg-3.eclass
index 6ac90a64d59..f135058fba6 100644
--- a/eclass/xorg-3.eclass
+++ b/eclass/xorg-3.eclass
@@ -116,7 +116,8 @@ WANT_AUTOMAKE="latest"
 for arch in ${XORG_EAUTORECONF_ARCHES}; do
EAUTORECONF_DEPENDS+=" ${arch}? ( ${EAUTORECONF_DEPEND} )"
 done
-DEPEND+=" ${EAUTORECONF_DEPENDS}"
+unset arch
+BDEPEND+=" ${EAUTORECONF_DEPENDS}"
 [[ ${XORG_EAUTORECONF} != no ]] && BDEPEND+=" ${EAUTORECONF_DEPEND}"
 unset EAUTORECONF_DEPENDS
 unset EAUTORECONF_DEPEND
-- 
2.19.2

[gentoo-dev] Re: [PATCH-r1] darcs.eclass: use BDEPEND with EAPI >= 7

[Michael Haubenwallner]

pushed, thanks!
/haubi/

On 5/29/19 8:51 PM, Sergei Trofimovich wrote:
> On Wed, 29 May 2019 12:01:20 +0200
> Michael Haubenwallner  wrote:
> 
>> ---
>>  eclass/darcs.eclass | 12 ++--
>>  1 file changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/eclass/darcs.eclass b/eclass/darcs.eclass
>> index 489008a87f1..09b71882367 100644
>> --- a/eclass/darcs.eclass
>> +++ b/eclass/darcs.eclass
>> @@ -85,8 +85,16 @@ SRC_URI=""
>>  
>>  # --- end ebuild-configurable settings ---
>>  
>> -DEPEND="dev-vcs/darcs
>> -net-misc/rsync"
>> +case ${EAPI:-0} in
>> +[0-6]) # no need to care about 5-HDEPEND and similar
>> +DEPEND="dev-vcs/darcs
>> +net-misc/rsync"
>> +;;
>> +*)
>> +BDEPEND="dev-vcs/darcs
>> +net-misc/rsync"
>> +;;
>> +esac
>>  
>>  # @FUNCTION: darcs_patchcount
>>  # @DESCRIPTION:
>> -- 
>> 2.19.2
>>
> 
> Looks good!
> 

[gentoo-dev] [PATCH-r1] darcs.eclass: use BDEPEND with EAPI >= 7

[Michael Haubenwallner]

---
 eclass/darcs.eclass | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/eclass/darcs.eclass b/eclass/darcs.eclass
index 489008a87f1..09b71882367 100644
--- a/eclass/darcs.eclass
+++ b/eclass/darcs.eclass
@@ -85,8 +85,16 @@ SRC_URI=""
 
 # --- end ebuild-configurable settings ---
 
-DEPEND="dev-vcs/darcs
-   net-misc/rsync"
+case ${EAPI:-0} in
+   [0-6]) # no need to care about 5-HDEPEND and similar
+   DEPEND="dev-vcs/darcs
+   net-misc/rsync"
+   ;;
+   *)
+   BDEPEND="dev-vcs/darcs
+   net-misc/rsync"
+   ;;
+esac
 
 # @FUNCTION: darcs_patchcount
 # @DESCRIPTION:
-- 
2.19.2

[gentoo-dev] [PATCH] darcs.eclass: use BDEPEND with EAPI >= 7

[Michael Haubenwallner]

---
 eclass/darcs.eclass | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/eclass/darcs.eclass b/eclass/darcs.eclass
index 489008a87f1..81003651680 100644
--- a/eclass/darcs.eclass
+++ b/eclass/darcs.eclass
@@ -85,8 +85,16 @@ SRC_URI=""
 
 # --- end ebuild-configurable settings ---
 
-DEPEND="dev-vcs/darcs
-   net-misc/rsync"
+case ${EAPI:-0} in
+   [0-6]*)
+   DEPEND="dev-vcs/darcs
+   net-misc/rsync"
+   ;;
+   *)
+   BDEPEND="dev-vcs/darcs
+   net-misc/rsync"
+   ;;
+esac
 
 # @FUNCTION: darcs_patchcount
 # @DESCRIPTION:
-- 
2.19.2

[gentoo-dev] Last rites: app-portage/prefix-chain-setup, sys-apps/prefix-chain-utils

[Michael Haubenwallner]

# Michael Haubenwallner  (25 Mar 2019)
# Obsolete, in favor of app-portage/prefix-toolkit.
# Removal in 30 days.  Bug #658572
app-portage/prefix-chain-setup
sys-apps/prefix-chain-utils

[gentoo-dev] Re: Can pkg_nofetch determine if a file is already downloaded?

[Michael Haubenwallner]

On 10/15/2018 08:05 PM, Michał Górny wrote:
> On Mon, 2018-10-15 at 13:34 +0200, Michael Haubenwallner wrote:
>> Hi,
>>
>> in pkg_nofetch, beyond to "direct the user to download relevant source 
>> files",
>> I've found it useful to tell the user which filesystem directory to put the
>> files into once downloaded.
>>
>> Beyond that, I've also found it useful to tell the user whether a relevant
>> source file is 'already there' or 'still missing'.
>>
>> Since the EAPI 6 related update to pkg_* phases to not have access to DISTDIR
>> (even in earlier EAPI) any more, I'm wondering if both informations are still
>> available to pkg_nofetch in one or another way.
>>
>> Any idea?
>>
>> Or is my only option to reduce the information to "all these files need to be
>> put in your DISTDIR", requiring the user to find out both the right DISTDIR
>> and which of the listed files are still missing herself?
>>
> 
> How would you know whether the file in DISTDIR is correct and complete?
> 
Well, pkg_nofetch is called only if some files are still missing,
so portage really should have checked them before, and eventually
renamed invalid files to "checksum_failure", no?

/haubi/

[gentoo-dev] Can pkg_nofetch determine if a file is already downloaded?

[Michael Haubenwallner]

Hi,

in pkg_nofetch, beyond to "direct the user to download relevant source files",
I've found it useful to tell the user which filesystem directory to put the
files into once downloaded.

Beyond that, I've also found it useful to tell the user whether a relevant
source file is 'already there' or 'still missing'.

Since the EAPI 6 related update to pkg_* phases to not have access to DISTDIR
(even in earlier EAPI) any more, I'm wondering if both informations are still
available to pkg_nofetch in one or another way.

Any idea?

Or is my only option to reduce the information to "all these files need to be
put in your DISTDIR", requiring the user to find out both the right DISTDIR
and which of the listed files are still missing herself?

Thanks,
/haubi/

[gentoo-dev] Re: [PATCH 0/5]-r1 toolchain.eclass: Prefix patches, Cygwin related

[Michael Haubenwallner]

On 06/22/2018 03:10 PM, Michael Haubenwallner wrote:
> Hi,
> 
> now reordered for EAPI 7 first.
> 
> Also, the downloaded cygwindist patches file now is renamed to
> gcc-cygwindist-.tar.gz rather than just .tar.gz.
> 
> Thanks for the reviews,

pushed now, thanks!

/haubi/

[gentoo-dev] Re: [PATCH 5/5] toolchain.eclass: support gcc patches from cygwinports

[Michael Haubenwallner]

On 06/22/2018 03:10 PM, Michael Haubenwallner wrote:
> Download and apply patches found in Cygwin's gcc.cygport, maintained at
> github/cygwinports/gcc, for a compiler running on cygwin.  The ebuild
> can define the cygwinports' git commit id as CYGWINPORTS_GITREV.
> ---
>  eclass/toolchain.eclass | 28 
>  1 file changed, 28 insertions(+)
> 
> diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
> index aa62010be6e..22936175125 100644
> --- a/eclass/toolchain.eclass
> +++ b/eclass/toolchain.eclass
> @@ -309,6 +309,14 @@ gentoo_urls() {
>  #ten Brugge's bounds-checking patches. If you want to 
> use a patch
>  #for an older gcc version with a new gcc, make sure you 
> set
>  #HTB_GCC_VER to that version of gcc.
> +#
> +#CYGWINPORTS_GITREV
> +#If set, this variable signals that we should apply 
> additional patches
> +#maintained by upstream Cygwin developers at 
> github/cygwinports/gcc,
> +#using the specified git commit id there.  The list of 
> patches to
> +#apply is extracted from gcc.cygport, maintained there 
> as well.
> +#This is done for compilers running on Cygwin, not for 
> cross compilers
> +#with a Cygwin target.
>  get_gcc_src_uri() {
>   export PATCH_GCC_VER=${PATCH_GCC_VER:-${GCC_RELEASE_VER}}
>   export UCLIBC_GCC_VER=${UCLIBC_GCC_VER:-${PATCH_GCC_VER}}
> @@ -375,6 +383,11 @@ get_gcc_src_uri() {
>   fi
>   fi
>  
> + # Cygwin patches from https://github.com/cygwinports/gcc
> + [[ -n ${CYGWINPORTS_GITREV} ]] && \
> + GCC_SRC_URI+=" elibc_Cygwin? ( 
> https://github.com/cygwinports/gcc/archive/${CYGWINPORTS_GITREV}.tar.gz
> + -> gcc-cygwinports-${CYGWINPORTS_GITREV}.tar.gz )"
> +
>   echo "${GCC_SRC_URI}"
>  }
>  
> @@ -481,6 +494,8 @@ gcc_quick_unpack() {
>  
>   use_if_iuse boundschecking && unpack 
> "bounds-checking-gcc-${HTB_GCC_VER}-${HTB_VER}.patch.bz2"
>  
> + [[ -n ${CYGWINPORTS_GITREV} ]] && use elibc_Cygwin && unpack 
> "${CYGWINPORTS_GITREV}.tar.gz"

Of course this should read

+   [[ -n ${CYGWINPORTS_GITREV} ]] && use elibc_Cygwin && unpack 
"gcc-cygwinports-${CYGWINPORTS_GITREV}.tar.gz"


> +
>   popd > /dev/null
>  }
>  
> @@ -505,6 +520,7 @@ toolchain_src_prepare() {
>   fi
>   do_gcc_HTB_patches
>   do_gcc_PIE_patches
> + do_gcc_CYGWINPORTS_patches
>   epatch_user
>  
>   if ( tc_version_is_at_least 4.8.2 || use_if_iuse hardened ) && ! use 
> vanilla ; then
> @@ -645,6 +661,18 @@ do_gcc_PIE_patches() {
>   BRANDING_GCC_PKGVERSION="${BRANDING_GCC_PKGVERSION}, pie-${PIE_VER}"
>  }
>  
> +do_gcc_CYGWINPORTS_patches() {
> + [[ -n ${CYGWINPORTS_GITREV} ]] || return 0
> + use elibc_Cygwin || return 0
> +
> + local -a patches
> + local p d="${WORKDIR}/gcc-${CYGWINPORTS_GITREV}"
> + readarray -t patches < <(sed -e '1,/PATCH_URI="/d;/"/,$d' < 
> "${d}"/gcc.cygport)
> + for p in ${patches[*]}; do
> + epatch "${d}/${p}"
> + done
> +}
> +
>  # configure to build with the hardened GCC specs as the default
>  make_gcc_hard() {
>  
> 

[gentoo-dev] [PATCH 5/5] toolchain.eclass: support gcc patches from cygwinports

[Michael Haubenwallner]

Download and apply patches found in Cygwin's gcc.cygport, maintained at
github/cygwinports/gcc, for a compiler running on cygwin.  The ebuild
can define the cygwinports' git commit id as CYGWINPORTS_GITREV.
---
 eclass/toolchain.eclass | 28 
 1 file changed, 28 insertions(+)

diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index aa62010be6e..22936175125 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -309,6 +309,14 @@ gentoo_urls() {
 #  ten Brugge's bounds-checking patches. If you want to 
use a patch
 #  for an older gcc version with a new gcc, make sure you 
set
 #  HTB_GCC_VER to that version of gcc.
+#
+#  CYGWINPORTS_GITREV
+#  If set, this variable signals that we should apply 
additional patches
+#  maintained by upstream Cygwin developers at 
github/cygwinports/gcc,
+#  using the specified git commit id there.  The list of 
patches to
+#  apply is extracted from gcc.cygport, maintained there 
as well.
+#  This is done for compilers running on Cygwin, not for 
cross compilers
+#  with a Cygwin target.
 get_gcc_src_uri() {
export PATCH_GCC_VER=${PATCH_GCC_VER:-${GCC_RELEASE_VER}}
export UCLIBC_GCC_VER=${UCLIBC_GCC_VER:-${PATCH_GCC_VER}}
@@ -375,6 +383,11 @@ get_gcc_src_uri() {
fi
fi
 
+   # Cygwin patches from https://github.com/cygwinports/gcc
+   [[ -n ${CYGWINPORTS_GITREV} ]] && \
+   GCC_SRC_URI+=" elibc_Cygwin? ( 
https://github.com/cygwinports/gcc/archive/${CYGWINPORTS_GITREV}.tar.gz
+   -> gcc-cygwinports-${CYGWINPORTS_GITREV}.tar.gz )"
+
echo "${GCC_SRC_URI}"
 }
 
@@ -481,6 +494,8 @@ gcc_quick_unpack() {
 
use_if_iuse boundschecking && unpack 
"bounds-checking-gcc-${HTB_GCC_VER}-${HTB_VER}.patch.bz2"
 
+   [[ -n ${CYGWINPORTS_GITREV} ]] && use elibc_Cygwin && unpack 
"${CYGWINPORTS_GITREV}.tar.gz"
+
popd > /dev/null
 }
 
@@ -505,6 +520,7 @@ toolchain_src_prepare() {
fi
do_gcc_HTB_patches
do_gcc_PIE_patches
+   do_gcc_CYGWINPORTS_patches
epatch_user
 
if ( tc_version_is_at_least 4.8.2 || use_if_iuse hardened ) && ! use 
vanilla ; then
@@ -645,6 +661,18 @@ do_gcc_PIE_patches() {
BRANDING_GCC_PKGVERSION="${BRANDING_GCC_PKGVERSION}, pie-${PIE_VER}"
 }
 
+do_gcc_CYGWINPORTS_patches() {
+   [[ -n ${CYGWINPORTS_GITREV} ]] || return 0
+   use elibc_Cygwin || return 0
+
+   local -a patches
+   local p d="${WORKDIR}/gcc-${CYGWINPORTS_GITREV}"
+   readarray -t patches < <(sed -e '1,/PATCH_URI="/d;/"/,$d' < 
"${d}"/gcc.cygport)
+   for p in ${patches[*]}; do
+   epatch "${d}/${p}"
+   done
+}
+
 # configure to build with the hardened GCC specs as the default
 make_gcc_hard() {
 
-- 
2.16.1

[gentoo-dev] [PATCH 4/5] toolchain.eclass: Cygwin provides posix threads

[Michael Haubenwallner]

Upstream Cygwin does build their gcc with posix threads for ages,
at least since gcc4-4.5.1-1.cygport (committed on Oct 3, 2010).
---
 eclass/toolchain.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index 4b94f78bfa9..aa62010be6e 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -1034,7 +1034,7 @@ toolchain_src_configure() {
confgcc+=( --enable-shared )
fi
case ${CHOST} in
-   mingw*|*-mingw*|*-cygwin)
+   mingw*|*-mingw*)
confgcc+=( --enable-threads=win32 ) ;;
*)
confgcc+=( --enable-threads=posix ) ;;
-- 
2.16.1

[gentoo-dev] [PATCH 3/5] toolchain.eclass: D->ED for where to start cleanups

[Michael Haubenwallner]

---
 eclass/toolchain.eclass | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index 36c9f8e78fc..4b94f78bfa9 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -1720,9 +1720,9 @@ toolchain_src_install() {
S="${WORKDIR}"/build emake -j1 DESTDIR="${D}" install || die
 
# Punt some tools which are really only useful while building gcc
-   find "${D}" -name install-tools -prune -type d -exec rm -rf "{}" \;
+   find "${ED}" -name install-tools -prune -type d -exec rm -rf "{}" \;
# This one comes with binutils
-   find "${D}" -name libiberty.a -delete
+   find "${ED}" -name libiberty.a -delete
 
# Move the libraries to the proper location
gcc_movelibs
@@ -1731,7 +1731,7 @@ toolchain_src_install() {
if ! is_crosscompile ; then
local EXEEXT
eval $(grep ^EXEEXT= "${WORKDIR}"/build/gcc/config.log)
-   [[ -r ${D}${BINPATH}/gcc${EXEEXT} ]] || die "gcc not found in 
${D}"
+   [[ -r ${D}${BINPATH}/gcc${EXEEXT} ]] || die "gcc not found in 
${ED}"
fi
 
dodir /etc/env.d/gcc
@@ -1810,7 +1810,7 @@ toolchain_src_install() {
|| prepman "${DATAPATH#${EPREFIX}}"
fi
# prune empty dirs left behind
-   find "${D}" -depth -type d -delete 2>/dev/null
+   find "${ED}" -depth -type d -delete 2>/dev/null
 
# install testsuite results
if use regression-test; then
@@ -1966,7 +1966,7 @@ gcc_movelibs() {
for FROMDIR in ${removedirs} ; do
rmdir "${D}"${FROMDIR} >& /dev/null
done
-   find -depth "${D}" -type d -exec rmdir {} + >& /dev/null
+   find -depth "${ED}" -type d -exec rmdir {} + >& /dev/null
 }
 
 # make sure the libtool archives have libdir set to where they actually
-- 
2.16.1

[gentoo-dev] [PATCH 2/5] toolchain.eclass: ROOT->EROOT at looking for gcc specs file

[Michael Haubenwallner]

---
 eclass/toolchain.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index 3916555cb21..36c9f8e78fc 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -2207,7 +2207,7 @@ do_gcc_config() {
[[ -n ${current_specs} ]] && use_specs=-${current_specs}
 
if [[ -n ${use_specs} ]] && \
-  [[ ! -e 
${ROOT%/}/etc/env.d/gcc/${CTARGET}-${GCC_CONFIG_VER}${use_specs} ]]
+  [[ ! -e 
${EROOT%/}/etc/env.d/gcc/${CTARGET}-${GCC_CONFIG_VER}${use_specs} ]]
then
ewarn "The currently selected specs-specific gcc 
config,"
ewarn "${current_specs}, doesn't exist anymore. This is 
usually"
-- 
2.16.1

[gentoo-dev] [PATCH 1/5] toolchain.eclass: EAPI 7 aware for D,ED,ROOT,EROOT

[Michael Haubenwallner]

These variables may or may not have the trailing slash. Additionally,
avoid leading double slash (a network location for Cygwin) with ROOT and
EROOT because they may be empty, while D and ED never should be empty
and there is no reason so far to avoid double slashes in between.
On the other hand, eclass variables like DATAPATH and LIBPATH do contain
the leading slash, so an extra slash reduces readability for no reason.
---
 eclass/toolchain.eclass | 36 ++--
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index 68e4ce15b37..3916555cb21 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -1793,13 +1793,13 @@ toolchain_src_install() {
 
cd "${S}"
if is_crosscompile; then
-   rm -rf "${ED}"usr/share/{man,info}
+   rm -rf "${ED}"/usr/share/{man,info}
rm -rf "${D}"${DATAPATH}/{man,info}
else
if tc_version_is_at_least 3.0 ; then
local cxx_mandir=$(find 
"${WORKDIR}/build/${CTARGET}/libstdc++-v3" -name man)
if [[ -d ${cxx_mandir} ]] ; then
-   cp -r "${cxx_mandir}"/man? 
"${D}/${DATAPATH}"/man/
+   cp -r "${cxx_mandir}"/man? 
"${D}${DATAPATH}"/man/
fi
fi
has noinfo ${FEATURES} \
@@ -1850,7 +1850,7 @@ toolchain_src_install() {
# libvtv.la: gcc itself handles linkage correctly.
# lib*san.la: Sanitizer linkage is handled internally by gcc, and they
# do not support static linking. #487550 #546700
-   find "${D}/${LIBPATH}" \
+   find "${D}${LIBPATH}" \
'(' \
-name libstdc++.la -o \
-name libstdc++fs.la -o \
@@ -1916,7 +1916,7 @@ gcc_movelibs() {
# code to run on the target.
if tc_version_is_at_least 5 && is_crosscompile ; then
dodir "${HOSTLIBPATH#${EPREFIX}}"
-   mv "${ED}"usr/$(get_libdir)/libcc1* "${D}${HOSTLIBPATH}" || die
+   mv "${ED}"/usr/$(get_libdir)/libcc1* "${D}${HOSTLIBPATH}" || die
fi
 
# For all the libs that are built for CTARGET, move them into the
@@ -2113,7 +2113,7 @@ gcc_slot_java() {
 
 toolchain_pkg_postinst() {
do_gcc_config
-   if [[ ${ROOT} == / && -f 
${EPREFIX}/usr/share/eselect/modules/compiler-shadow.eselect ]] ; then
+   if [[ ! ${ROOT%/} && -f 
${EPREFIX}/usr/share/eselect/modules/compiler-shadow.eselect ]] ; then
eselect compiler-shadow update all
fi
 
@@ -2128,17 +2128,17 @@ toolchain_pkg_postinst() {
echo
 
# Clean up old paths
-   rm -f "${EROOT}"*/rcscripts/awk/fixlafiles.awk 
"${EROOT}"sbin/fix_libtool_files.sh
-   rmdir "${EROOT}"*/rcscripts{/awk,} 2>/dev/null
+   rm -f "${EROOT%/}"/*/rcscripts/awk/fixlafiles.awk 
"${EROOT%/}"/sbin/fix_libtool_files.sh
+   rmdir "${EROOT%/}"/*/rcscripts{/awk,} 2>/dev/null
 
-   mkdir -p "${EROOT}"usr/{share/gcc-data,sbin,bin}
+   mkdir -p "${EROOT%/}"/usr/{share/gcc-data,sbin,bin}
# DATAPATH has EPREFIX already, use ROOT with it
-   cp "${ROOT}${DATAPATH}"/fixlafiles.awk 
"${EROOT}"usr/share/gcc-data/ || die
-   cp "${ROOT}${DATAPATH}"/fix_libtool_files.sh 
"${EROOT}"usr/sbin/ || die
+   cp "${ROOT%/}${DATAPATH}"/fixlafiles.awk 
"${EROOT%/}"/usr/share/gcc-data/ || die
+   cp "${ROOT%/}${DATAPATH}"/fix_libtool_files.sh 
"${EROOT%/}"/usr/sbin/ || die
 
# Since these aren't critical files and portage sucks with
# handling of binpkgs, don't require these to be found
-   cp "${ROOT}${DATAPATH}"/c{89,99} "${EROOT}"usr/bin/ 2>/dev/null
+   cp "${ROOT%/}${DATAPATH}"/c{89,99} "${EROOT%/}"/usr/bin/ 
2>/dev/null
fi
 
if use regression-test ; then
@@ -2154,7 +2154,7 @@ toolchain_pkg_postinst() {
 }
 
 toolchain_pkg_postrm() {
-   if [[ ${ROOT} == / && -f 
${EPREFIX}/usr/share/eselect/modules/compiler-shadow.eselect ]] ; then
+   if [[ ! ${ROOT%/} && -f 
${EPREFIX}/usr/share/eselect/modules/compiler-shadow.eselect ]] ; then
eselect compiler-shadow clean all
fi
 
@@ -2165,16 +2165,16 @@ toolchain_pkg_postrm() {
 
# clean up the cruft left behind by cross-compilers
if is_crosscompile ; then
-   if [[ -z $(ls "${EROOT}"etc/env.d/gcc/${CTARGET}* 2>/dev/null) 
]] ; then
-   rm -f "${EROOT}"etc/env.d/gcc/config-${CTARGET}
-   rm -f "${EROOT}"etc/env.d/??gcc-${CTARGET}
-   rm -f "${EROOT}"usr/bin/${CTARGET}-{gcc,{g,c}++}{,32,64}
+   if [[ -z $(ls "${EROOT%/}"/etc/env.d/gcc/${CTARGET}* 
2>/dev/null) ]] ; then
+   rm -f "${EROOT%

[gentoo-dev] [PATCH 0/5]-r1 toolchain.eclass: Prefix patches, Cygwin related

[Michael Haubenwallner]

Hi,

now reordered for EAPI 7 first.

Also, the downloaded cygwindist patches file now is renamed to
gcc-cygwindist-.tar.gz rather than just .tar.gz.

Thanks for the reviews,
/haubi/

[gentoo-dev] Re: [PATCH 0/5] toolchain.eclass: Prefix patches, Cygwin related

[Michael Haubenwallner]

On 06/20/2018 07:49 PM, Michael Haubenwallner wrote:
> Hi,
> 
> please review these patches we have in prefix-overlay,
> where patches 3-5 are for Gentoo Prefix on Cygwin.

Thanks for the reviews, will reorder to account for EAPI 7 paths first.

One minor thing still unclear to me, beyond no _leading_ double slash:
Do we try hard to avoid redundant slashes _in between_ too?

Thoughts behind this question:
Beyond the eventual trailing slash, the {,E,SYS,ESYS,B}ROOT variables
may be empty, so Cygwin really requires the ${%/} modifier for them
to not end up with a network location by accident (in EAPI before 7).

But D,ED are not expected to be empty, and the ${%/} modifier will avoid
an extra slash _in between_ only, not a leading one.

So with D,ED the ${%/} modifier feels needless, reducing readability only.

Just wondering if we have some guidance here,
/haubi/

[gentoo-dev] Re: [PATCH 5/5] toolchain.eclass: support gcc patches from cygwinports

[Michael Haubenwallner]

On 06/20/2018 09:56 PM, Michał Górny wrote:
> W dniu śro, 20.06.2018 o godzinie 19∶49 +0200, użytkownik Michael
> Haubenwallner napisał:
>> Download and apply patches found in Cygwin's gcc.cygport, maintained
>> at
>> github/cygwinports/gcc, for a compiler running on cygwin.  The ebuild
>> can define the cygwinports' git commit id as CYGWINPORTS_GITREV.
>> ---
>>  eclass/toolchain.eclass | 28 
>>  1 file changed, 28 insertions(+)
>>
>> diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
>> index faf96d2a41f..a16bfadc301 100644
>> --- a/eclass/toolchain.eclass
>> +++ b/eclass/toolchain.eclass
>> @@ -309,6 +309,14 @@ gentoo_urls() {
>>  #   ten Brugge's bounds-checking patches. If
>> you want to use a patch
>>  #   for an older gcc version with a new gcc,
>> make sure you set
>>  #   HTB_GCC_VER to that version of gcc.
>> +#
>> +#   CYGWINPORTS_GITREV
>> +#   If set, this variable signals that we
>> should apply additional patches
>> +#   maintained by upstream Cygwin developers at
>> github/cygwinports/gcc,
>> +#   using the specified git commit id
>> there.  The list of patches to
>> +#   apply is extracted from gcc.cygport,
>> maintained there as well.
>> +#   This is done for compilers running on
>> Cygwin, not for cross compilers
>> +#   with a Cygwin target.
>>  get_gcc_src_uri() {
>>  export PATCH_GCC_VER=${PATCH_GCC_VER:-${GCC_RELEASE_VER}}
>>  export UCLIBC_GCC_VER=${UCLIBC_GCC_VER:-${PATCH_GCC_VER}}
>> @@ -375,6 +383,10 @@ get_gcc_src_uri() {
>>  fi
>>  fi
>>  
>> +# Cygwin patches from https://github.com/cygwinports/gcc
>> +[[ -n ${CYGWINPORTS_GITREV} ]] && \
>> +GCC_SRC_URI+=" elibc_Cygwin? (
>> https://github.com/cygwinports/gcc/archive/${CYGWINPORTS_GITREV}.zip
>> )"
> 
> Why not .tar.gz?

Didn't know .tar.gz works - the webpage provides [Download ZIP] only, thanks!

> 
>> +
>>  echo "${GCC_SRC_URI}"
>>  }
>>  
>> @@ -481,6 +493,8 @@ gcc_quick_unpack() {
>>  
>>  use_if_iuse boundschecking && unpack "bounds-checking-gcc-
>> ${HTB_GCC_VER}-${HTB_VER}.patch.bz2"
>>  
>> +[[ -n ${CYGWINPORTS_GITREV} ]] && use elibc_Cygwin && unpack
>> "${CYGWINPORTS_GITREV}.zip"
>> +
>>  popd > /dev/null
>>  }
>>  
>> @@ -505,6 +519,7 @@ toolchain_src_prepare() {
>>  fi
>>  do_gcc_HTB_patches
>>  do_gcc_PIE_patches
>> +do_gcc_CYGWINPORTS_patches
>>  epatch_user
>>  
>>  if ( tc_version_is_at_least 4.8.2 || use_if_iuse hardened )
>> && ! use vanilla ; then
>> @@ -645,6 +660,19 @@ do_gcc_PIE_patches() {
>>  BRANDING_GCC_PKGVERSION="${BRANDING_GCC_PKGVERSION}, pie-
>> ${PIE_VER}"
>>  }
>>  
>> +do_gcc_CYGWINPORTS_patches() {
>> +[[ -n ${CYGWINPORTS_GITREV} ]] || return 0
>> +use elibc_Cygwin || return 0
>> +
>> +local p d="${WORKDIR}/gcc-${CYGWINPORTS_GITREV}"
>> +for p in $(
>> +eval "$(sed -ne '/PATCH_URI="/,/"/p' <
>> "${d}"/gcc.cygport)"
> 
> The eval here is completely unnecessary, and can easily wreak havoc. 
> Don't do that.

Erm - multiline commands from $() seem to fail without eval:

# sed -ne '/PATCH_URI="/,/"/p' < ./gcc.cygport
PATCH_URI="
0001-share-mingw-fset-stack-executable-with-cygwin.patch
...
"

# $(sed -ne '/PATCH_URI="/,/"/p' < ./gcc.cygport)
-bash: PATCH_URI=": command not found

# eval "$(sed -ne '/PATCH_URI="/,/"/p' < ./gcc.cygport)"

# declare -p PATCH_URI
declare -- PATCH_URI="
0001-share-mingw-fset-stack-executable-with-cygwin.patch
...
"

/haubi/

[gentoo-dev] Re: [PATCH 3/5] toolchain.eclass: avoid leading double slash

[Michael Haubenwallner]

On 06/21/2018 12:40 AM, Ulrich Mueller wrote:
>>>>>> On Wed, 20 Jun 2018, Michael Haubenwallner wrote:
> 
>> Path starting with "//" is a Network path for Cygwin:
>> As DATAPATH starts with EPREFIX, we have to use it with ${ROOT%/}.
>> ---
>>  eclass/toolchain.eclass | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
>> diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
>> index a51d8e84f5e..bc3a80e0e8a 100644
>> --- a/eclass/toolchain.eclass
>> +++ b/eclass/toolchain.eclass
>> @@ -2133,12 +2133,12 @@ toolchain_pkg_postinst() {
>  
>>  mkdir -p "${EROOT}"usr/{share/gcc-data,sbin,bin}
>>  # DATAPATH has EPREFIX already, use ROOT with it
>> -cp "${ROOT}${DATAPATH}"/fixlafiles.awk 
>> "${EROOT}"usr/share/gcc-data/ || die
>> -cp "${ROOT}${DATAPATH}"/fix_libtool_files.sh 
>> "${EROOT}"usr/sbin/ || die
>> +cp "${ROOT%/}${DATAPATH}"/fixlafiles.awk 
>> "${EROOT}"usr/share/gcc-data/ || die
>> +cp "${ROOT%/}${DATAPATH}"/fix_libtool_files.sh 
>> "${EROOT}"usr/sbin/ || die
> 
> Looks a bit short-sighted for the destinations, since EROOT lost its
> trailing slash in EAPI 7. So better use "${EROOT%/}/" there too.

Well, DATAPATH already has the leading slash, and I have to avoid double slash 
here.

/haubi/

[gentoo-dev] [PATCH 5/5] toolchain.eclass: support gcc patches from cygwinports

[Michael Haubenwallner]

Download and apply patches found in Cygwin's gcc.cygport, maintained at
github/cygwinports/gcc, for a compiler running on cygwin.  The ebuild
can define the cygwinports' git commit id as CYGWINPORTS_GITREV.
---
 eclass/toolchain.eclass | 28 
 1 file changed, 28 insertions(+)

diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index faf96d2a41f..a16bfadc301 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -309,6 +309,14 @@ gentoo_urls() {
 #  ten Brugge's bounds-checking patches. If you want to 
use a patch
 #  for an older gcc version with a new gcc, make sure you 
set
 #  HTB_GCC_VER to that version of gcc.
+#
+#  CYGWINPORTS_GITREV
+#  If set, this variable signals that we should apply 
additional patches
+#  maintained by upstream Cygwin developers at 
github/cygwinports/gcc,
+#  using the specified git commit id there.  The list of 
patches to
+#  apply is extracted from gcc.cygport, maintained there 
as well.
+#  This is done for compilers running on Cygwin, not for 
cross compilers
+#  with a Cygwin target.
 get_gcc_src_uri() {
export PATCH_GCC_VER=${PATCH_GCC_VER:-${GCC_RELEASE_VER}}
export UCLIBC_GCC_VER=${UCLIBC_GCC_VER:-${PATCH_GCC_VER}}
@@ -375,6 +383,10 @@ get_gcc_src_uri() {
fi
fi
 
+   # Cygwin patches from https://github.com/cygwinports/gcc
+   [[ -n ${CYGWINPORTS_GITREV} ]] && \
+   GCC_SRC_URI+=" elibc_Cygwin? ( 
https://github.com/cygwinports/gcc/archive/${CYGWINPORTS_GITREV}.zip )"
+
echo "${GCC_SRC_URI}"
 }
 
@@ -481,6 +493,8 @@ gcc_quick_unpack() {
 
use_if_iuse boundschecking && unpack 
"bounds-checking-gcc-${HTB_GCC_VER}-${HTB_VER}.patch.bz2"
 
+   [[ -n ${CYGWINPORTS_GITREV} ]] && use elibc_Cygwin && unpack 
"${CYGWINPORTS_GITREV}.zip"
+
popd > /dev/null
 }
 
@@ -505,6 +519,7 @@ toolchain_src_prepare() {
fi
do_gcc_HTB_patches
do_gcc_PIE_patches
+   do_gcc_CYGWINPORTS_patches
epatch_user
 
if ( tc_version_is_at_least 4.8.2 || use_if_iuse hardened ) && ! use 
vanilla ; then
@@ -645,6 +660,19 @@ do_gcc_PIE_patches() {
BRANDING_GCC_PKGVERSION="${BRANDING_GCC_PKGVERSION}, pie-${PIE_VER}"
 }
 
+do_gcc_CYGWINPORTS_patches() {
+   [[ -n ${CYGWINPORTS_GITREV} ]] || return 0
+   use elibc_Cygwin || return 0
+
+   local p d="${WORKDIR}/gcc-${CYGWINPORTS_GITREV}"
+   for p in $(
+   eval "$(sed -ne '/PATCH_URI="/,/"/p' < "${d}"/gcc.cygport)"
+   echo ${PATCH_URI}
+   ); do
+   epatch "${d}/${p}"
+   done
+}
+
 # configure to build with the hardened GCC specs as the default
 make_gcc_hard() {
 
-- 
2.16.1

[gentoo-dev] [PATCH 4/5] toolchain.eclass: Cygwin provides posix threads

[Michael Haubenwallner]

Upstream Cygwin does build their gcc with posix threads for ages,
at least since gcc4-4.5.1-1.cygport (committed on Oct 3, 2010).
---
 eclass/toolchain.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index bc3a80e0e8a..faf96d2a41f 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -1034,7 +1034,7 @@ toolchain_src_configure() {
confgcc+=( --enable-shared )
fi
case ${CHOST} in
-   mingw*|*-mingw*|*-cygwin)
+   mingw*|*-mingw*)
confgcc+=( --enable-threads=win32 ) ;;
*)
confgcc+=( --enable-threads=posix ) ;;
-- 
2.16.1

[gentoo-dev] [PATCH 3/5] toolchain.eclass: avoid leading double slash

[Michael Haubenwallner]

Path starting with "//" is a Network path for Cygwin:
As DATAPATH starts with EPREFIX, we have to use it with ${ROOT%/}.
---
 eclass/toolchain.eclass | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index a51d8e84f5e..bc3a80e0e8a 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -2133,12 +2133,12 @@ toolchain_pkg_postinst() {
 
mkdir -p "${EROOT}"usr/{share/gcc-data,sbin,bin}
# DATAPATH has EPREFIX already, use ROOT with it
-   cp "${ROOT}${DATAPATH}"/fixlafiles.awk 
"${EROOT}"usr/share/gcc-data/ || die
-   cp "${ROOT}${DATAPATH}"/fix_libtool_files.sh 
"${EROOT}"usr/sbin/ || die
+   cp "${ROOT%/}${DATAPATH}"/fixlafiles.awk 
"${EROOT}"usr/share/gcc-data/ || die
+   cp "${ROOT%/}${DATAPATH}"/fix_libtool_files.sh 
"${EROOT}"usr/sbin/ || die
 
# Since these aren't critical files and portage sucks with
# handling of binpkgs, don't require these to be found
-   cp "${ROOT}${DATAPATH}"/c{89,99} "${EROOT}"usr/bin/ 2>/dev/null
+   cp "${ROOT%/}${DATAPATH}"/c{89,99} "${EROOT}"usr/bin/ 
2>/dev/null
fi
 
if use regression-test ; then
-- 
2.16.1

[gentoo-dev] [PATCH 1/5] toolchain.eclass: ROOT->EROOT at looking for gcc specs file

[Michael Haubenwallner]

---
 eclass/toolchain.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index 68e4ce15b37..fe41a80db28 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -2207,7 +2207,7 @@ do_gcc_config() {
[[ -n ${current_specs} ]] && use_specs=-${current_specs}
 
if [[ -n ${use_specs} ]] && \
-  [[ ! -e 
${ROOT}/etc/env.d/gcc/${CTARGET}-${GCC_CONFIG_VER}${use_specs} ]]
+  [[ ! -e 
${EROOT}etc/env.d/gcc/${CTARGET}-${GCC_CONFIG_VER}${use_specs} ]]
then
ewarn "The currently selected specs-specific gcc 
config,"
ewarn "${current_specs}, doesn't exist anymore. This is 
usually"
-- 
2.16.1

[gentoo-dev] [PATCH 0/5] toolchain.eclass: Prefix patches, Cygwin related

[Michael Haubenwallner]

Hi,

please review these patches we have in prefix-overlay,
where patches 3-5 are for Gentoo Prefix on Cygwin.

Thanks!
/haubi/

[gentoo-dev] [PATCH 2/5] toolchain.eclass: D->ED for where to start cleanups

[Michael Haubenwallner]

---
 eclass/toolchain.eclass | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index fe41a80db28..a51d8e84f5e 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -1720,9 +1720,9 @@ toolchain_src_install() {
S="${WORKDIR}"/build emake -j1 DESTDIR="${D}" install || die
 
# Punt some tools which are really only useful while building gcc
-   find "${D}" -name install-tools -prune -type d -exec rm -rf "{}" \;
+   find "${ED}" -name install-tools -prune -type d -exec rm -rf "{}" \;
# This one comes with binutils
-   find "${D}" -name libiberty.a -delete
+   find "${ED}" -name libiberty.a -delete
 
# Move the libraries to the proper location
gcc_movelibs
@@ -1731,7 +1731,7 @@ toolchain_src_install() {
if ! is_crosscompile ; then
local EXEEXT
eval $(grep ^EXEEXT= "${WORKDIR}"/build/gcc/config.log)
-   [[ -r ${D}${BINPATH}/gcc${EXEEXT} ]] || die "gcc not found in 
${D}"
+   [[ -r ${D}${BINPATH}/gcc${EXEEXT} ]] || die "gcc not found in 
${ED}"
fi
 
dodir /etc/env.d/gcc
@@ -1810,7 +1810,7 @@ toolchain_src_install() {
|| prepman "${DATAPATH#${EPREFIX}}"
fi
# prune empty dirs left behind
-   find "${D}" -depth -type d -delete 2>/dev/null
+   find "${ED}" -depth -type d -delete 2>/dev/null
 
# install testsuite results
if use regression-test; then
@@ -1966,7 +1966,7 @@ gcc_movelibs() {
for FROMDIR in ${removedirs} ; do
rmdir "${D}"${FROMDIR} >& /dev/null
done
-   find -depth "${D}" -type d -exec rmdir {} + >& /dev/null
+   find -depth "${ED}" -type d -exec rmdir {} + >& /dev/null
 }
 
 # make sure the libtool archives have libdir set to where they actually
-- 
2.16.1

[gentoo-dev] Re: EAPI 7, BDEPEND and pkg_*inst

[Michael Haubenwallner]

On 06/04/2018 01:40 PM, Michał Górny wrote:
> W dniu śro, 30.05.2018 o godzinie 13∶49 +0200, użytkownik Michael
> Haubenwallner napisał:
>> Hi,
>>
>> HOORAY, seems like EAPI 7 might be able to obsolete the "prefix-chaining"
>> portage patch I've carried in prefix-overlay all the time, thank you for 
>> that!
> 
> I'm sorry for not replying earlier.  I meant to, but I failed to mark
> the mail and I've forgot about it.

This is what a (long) weekend is for: forget about it - at least for some time 
;)

>>
>> However, a first thing being unclear already came up when bumping EAPI 6 to 
>> 7:
>>
>> For example, the current app-misc/ca-certificates ebuild (EAPI 6) contains:
>>
>>  # c_rehash: we run `c_rehash`
>>  # debianutils: we run `run-parts`
>>  RDEPEND="${DEPEND}
>>  app-misc/c_rehash
>>  sys-apps/debianutils"
>>
>>  pkg_postinst() {
>> if [ -d "${EROOT}/usr/local/share/ca-certificates" ] ; then
>> # if the user has local certs, we need to rebuild again
>> # to include their stuff in the db.
>> # However it's too overzealous when the user has custom certs in 
>> place.
>> # --fresh is to clean up dangling symlinks
>> "${EROOT}"/usr/sbin/update-ca-certificates --root "${ROOT}"
>> fi
>>  }
>>
>> Thing is, these RDEPENDs are not really required to "run" ca-certificates, 
>> but to
>> administrate it - which eventually is done on the CBUILD machine (from 
>> within the
>> ebuild, like in pkg_postinst currently), not necessarily on the CHOST 
>> machine.
>>
>> So I do not necessarily want these RDEPENDs to be installed on the CHOST 
>> machine,
>> given that they may not be executed from within the CBUILD machine at all.
>>
>> So the first idea is to move both RDEPENDs into BDEPEND.  But then, they are
>> not guaranteed to be available during pkg_postinst - like for a binary 
>> package.
>>
>> Question now is: Is this wrong behaviour in the ebuild,
>> or is this something where EAPI 7 is still insufficient for?
> 
> It's a known deficiency discovered just a while too late to address it. 
> It comes from the fact that we never really had proper dependencies for
> pkg_*inst phases.  So far we've ignored the problem because our work-
> arounds were sufficient for our use cases but cross definitely needs
> something better.
> 
>> When this is wrong (probably independent of EAPI 7 already) in the ebuild:
>> How can the ebuild get such a use case right, especially with EAPI 7?
> 
> I think the 'closest' thing to right would be to use BDEPEND+RDEPEND. 
> It won't cover cross+binpkg but I guess it's as good as you can get.
> 

Having BDEPEND in RDEPEND will fix binpkg, but break cross again - which
BDEPEND aims to help firsthand (as far as I understood).

To get both binpkg and cross working, although not combined together,
what about something like this workaround:

EAPI=7
IUSE="+bindist"
BDEPEND="some-cbuild/tool"
RDEPEND="bindist? ( ${BDEPEND} )"

It should be easy for cross profiles to use.mask "bindist".

For cross (without binpkg), BDEPEND should still be around during pkg_*inst,
even if not specified per PMS.

-- 
/haubi/

Re: [gentoo-dev] EAPI 7, BDEPEND and pkg_*inst

[Michael Haubenwallner]

On 05/31/2018 12:58 AM, Zac Medico wrote:
> On 05/30/2018 04:49 AM, Michael Haubenwallner wrote:
>> Hi,
>>
>> HOORAY, seems like EAPI 7 might be able to obsolete the "prefix-chaining"
>> portage patch I've carried in prefix-overlay all the time, thank you for 
>> that!
>>
>> However, a first thing being unclear already came up when bumping EAPI 6 to 
>> 7:
>>
>> For example, the current app-misc/ca-certificates ebuild (EAPI 6) contains:
>>
>>  # c_rehash: we run `c_rehash`
>>  # debianutils: we run `run-parts`
>>  RDEPEND="${DEPEND}
>>  app-misc/c_rehash
>>  sys-apps/debianutils"
>>
>>  pkg_postinst() {
>> if [ -d "${EROOT}/usr/local/share/ca-certificates" ] ; then
>> # if the user has local certs, we need to rebuild again
>> # to include their stuff in the db.
>> # However it's too overzealous when the user has custom certs in 
>> place.
>> # --fresh is to clean up dangling symlinks
>> "${EROOT}"/usr/sbin/update-ca-certificates --root "${ROOT}"
>> fi
>>  }
>>
>> Thing is, these RDEPENDs are not really required to "run" ca-certificates, 
>> but to
>> administrate it - which eventually is done on the CBUILD machine (from 
>> within the
>> ebuild, like in pkg_postinst currently), not necessarily on the CHOST 
>> machine.
>>
>> So I do not necessarily want these RDEPENDs to be installed on the CHOST 
>> machine,
>> given that they may not be executed from within the CBUILD machine at all.
>>
>> So the first idea is to move both RDEPENDs into BDEPEND.  But then, they are
>> not guaranteed to be available during pkg_postinst - like for a binary 
>> package.
> 
> Right, so it really belongs in RDEPEND *and* BDEPEND.

RDEPEND doesn't feel correct - see below.

> 
>> Question now is: Is this wrong behaviour in the ebuild,
>> or is this something where EAPI 7 is still insufficient for?
> 
> If we want to tune the dependencies more finely, we'll need new EAPI.

Probably - with explicit "dependencies for merge and configuration phases"?
For consistency with DEPEND+RDEPEND, I can imagine BDEPEND+*BRDEPEND*.

> 
>> When this is wrong (probably independent of EAPI 7 already) in the ebuild:
>> How can the ebuild get such a use case right, especially with EAPI 7?
> 
> What's wrong with putting it in both?

In RDEPEND, they are provided as CHOST binaries (in EROOT), but they are
executed on the CBUILD machine during merge and configuration phases.

In BDEPEND, they are not guaranteed to be available with binary packages.

For a workaround (in another prefix-chaining portage patch), it might work to
guarantee BDEPEND be available even for merge and configuration phases, no?

-- 
Thanks!
/haubi/



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] EAPI 7, BDEPEND and pkg_*inst

[Michael Haubenwallner]

Hi,

HOORAY, seems like EAPI 7 might be able to obsolete the "prefix-chaining"
portage patch I've carried in prefix-overlay all the time, thank you for that!

However, a first thing being unclear already came up when bumping EAPI 6 to 7:

For example, the current app-misc/ca-certificates ebuild (EAPI 6) contains:

 # c_rehash: we run `c_rehash`
 # debianutils: we run `run-parts`
 RDEPEND="${DEPEND}
 app-misc/c_rehash
 sys-apps/debianutils"

 pkg_postinst() {
if [ -d "${EROOT}/usr/local/share/ca-certificates" ] ; then
# if the user has local certs, we need to rebuild again
# to include their stuff in the db.
# However it's too overzealous when the user has custom certs in place.
# --fresh is to clean up dangling symlinks
"${EROOT}"/usr/sbin/update-ca-certificates --root "${ROOT}"
fi
 }

Thing is, these RDEPENDs are not really required to "run" ca-certificates, but 
to
administrate it - which eventually is done on the CBUILD machine (from within 
the
ebuild, like in pkg_postinst currently), not necessarily on the CHOST machine.

So I do not necessarily want these RDEPENDs to be installed on the CHOST 
machine,
given that they may not be executed from within the CBUILD machine at all.

So the first idea is to move both RDEPENDs into BDEPEND.  But then, they are
not guaranteed to be available during pkg_postinst - like for a binary package.

Question now is: Is this wrong behaviour in the ebuild,
or is this something where EAPI 7 is still insufficient for?

When this is wrong (probably independent of EAPI 7 already) in the ebuild:
How can the ebuild get such a use case right, especially with EAPI 7?

Thanks!
/haubi/

[gentoo-dev] Re: Open Build Service

[Michael Haubenwallner]

Hi,

another two cents:

On 11/10/2017 12:03 AM, Samuel Bernardo wrote:
> Hi,
> 
> I send this email to know the devs opinion about Gentoo integration with
> Open Build Service[1].
> 
> When creating specialized images and using an automated process for
> testing before deployment, I think that Open Build Service would be
> useful. It already support all major binary based distros and I think
> that Gentoo could be in there also.

Well, Gentoo is a Meta Distribution, and it's binary instantiation usually
does emerge on the users machine(s). So users actually do have their private
binary distribution - either with or without caching the binary packages.
(In my opinion, a binary distribution is little more than a cache for binary
packages, to avoid the need for compilation resources on the target machine.)

Of course there is chance that users do have identical profile setups (USE 
flags,
optimization flags, etc.), which is where OBS (or similar) indeed feels useful.

Rather than sharing binary packages, an idea is to share Gentoo user's profile
setups - with the cache for binary packages to be optional (yet powered by some
open build service). Note that some USE flags disallow binary packaging at all.

Wouldn't we gain something like a "Social Linux Distribution Network" then?

/haubi/

[gentoo-dev] Re: sys-libs/ncurses: erronious deletion of *.dll.a files; possibly other packages affected

[Michael Haubenwallner]

On 09/29/2017 10:33 AM, Marty E. Plummer wrote:
> On Fri, Sep 29, 2017 at 08:29:07AM +0000, Michael Haubenwallner wrote:
>> On 09/29/2017 03:36 AM, Marty E. Plummer wrote:
>>> On Thu, Sep 28, 2017 at 07:35:20PM +, Mike Gilbert wrote:
>>>> On Wed, Sep 20, 2017 at 10:01 PM, Marty E. Plummer
>>>>  wrote:
>>>>> arfrever suggests I send a mail here, as there are other packages which
>>>>> may be affected by this issue and perhaps a more generalized fix is
>>>>> required instead of an explicit fix in sys-libs/ncurses and other ebuilds
>>>>> that may require it.
>>>>
>>>> I think the solution here is to remove those overly broad "find
>>>> -delete" statements and replace them with something safer.
>>>>
>>>> Ideally the build system(s) would be patched to not compile static
>>>> libs in the first place.
>>>>
>>>> If that's not possible, perhaps an eclass function could be created to
>>>> safely remove static libs.
>>>>
>>> Honestly I already have a pr up that fixes this particular package's
>>> issue, fairly simple fix https://github.com/gentoo/gentoo/pull/5734
>>>
>>> --- a/sys-libs/ncurses/ncurses-6.0-r1.ebuild
>>> +++ b/sys-libs/ncurses/ncurses-6.0-r1.ebuild
>>> @@ -241,7 +241,8 @@ multilib_src_install() {
>>> # Provide a link for -lcurses.
>>> ln -sf libncurses$(get_libname) 
>>> "${ED}"/usr/$(get_libdir)/libcurses$(get_libname) || die
>>> fi
>>> -   use static-libs || find "${ED}"/usr/ -name '*.a' -delete
>>> +   # don't delete '*.dll.a', needed for linking #631468
>>> +   use static-libs || find "${ED}"/usr/ -name '*.a' ! -name '*.dll.a' 
>>> -delete
>>
>> In prefix overlay we have this version:
>>
>>   use static-libs || find "${ED}"/usr/ -name '*.a' -not -name 
>> "*$(get_libname)" -delete
>>
> Won't work here, as $(get_libname) returns .dll in this case, which is
> why the symlinking is busted

Indeed! Although I do believe get_libname should return the (dynamically) 
linkable file
name rather than the dynamically loadable one, because a build system's target 
often is
the dynamically linkable file, creating the loadable as side effect. Note that 
only COFF
based systems (AIX, Windows) may distinguish (dynamically) linkable and 
loadable files.

Additionally (although unused in Prefix), AIX allows for one single file libN.a 
containing
Shared Objects, which can be statically linked too!

And for winnt I've yet to decide the value for $(get_libname) as the Import 
Library:
Candidates are ".so", ".dll.a", ".dll.lib" - as I do support all of them in the 
msvc
wrapper ("parity") to reduce the need of patching various build systems for 
now...

So probably the real safe one here is (in case get_libname may return ".a"):

  use static-libs || find "${ED}"/usr/ -name '*.a' -not -name '*.dll.a' -not 
-name "*$(get_libname)" -delete

OR: Really have some function prune_static_libs to remove library files serving 
as
Static Library only - neither as Import Library nor Shared Library: Implemented
for some platforms to ignore the file name but inspect the content instead.

Remember: This is (related but) different from prune_libtool_libs,
which suggests the find "${D}" -name '*.la' -delete alternative only.

/haubi/

[gentoo-dev] Re: sys-libs/ncurses: erronious deletion of *.dll.a files; possibly other packages affected

[Michael Haubenwallner]

On 09/29/2017 03:36 AM, Marty E. Plummer wrote:
> On Thu, Sep 28, 2017 at 07:35:20PM +, Mike Gilbert wrote:
>> On Wed, Sep 20, 2017 at 10:01 PM, Marty E. Plummer
>>  wrote:
>>> arfrever suggests I send a mail here, as there are other packages which
>>> may be affected by this issue and perhaps a more generalized fix is
>>> required instead of an explicit fix in sys-libs/ncurses and other ebuilds
>>> that may require it.
>>
>> I think the solution here is to remove those overly broad "find
>> -delete" statements and replace them with something safer.
>>
>> Ideally the build system(s) would be patched to not compile static
>> libs in the first place.
>>
>> If that's not possible, perhaps an eclass function could be created to
>> safely remove static libs.
>>
> Honestly I already have a pr up that fixes this particular package's
> issue, fairly simple fix https://github.com/gentoo/gentoo/pull/5734
> 
> --- a/sys-libs/ncurses/ncurses-6.0-r1.ebuild
> +++ b/sys-libs/ncurses/ncurses-6.0-r1.ebuild
> @@ -241,7 +241,8 @@ multilib_src_install() {
>   # Provide a link for -lcurses.
>   ln -sf libncurses$(get_libname) 
> "${ED}"/usr/$(get_libdir)/libcurses$(get_libname) || die
>   fi
> - use static-libs || find "${ED}"/usr/ -name '*.a' -delete
> + # don't delete '*.dll.a', needed for linking #631468
> + use static-libs || find "${ED}"/usr/ -name '*.a' ! -name '*.dll.a' 
> -delete

In prefix overlay we have this version:

  use static-libs || find "${ED}"/usr/ -name '*.a' -not -name "*$(get_libname)" 
-delete

/haubi/

[gentoo-dev] Re: Integrating Ada into toolchain.eclass, again

[Michael Haubenwallner]

Hi Luke,

On 05/19/2017 09:08 PM, Luke A. Guest wrote:
> Hi,
> 
> I posted a bug back in August,
> https://bugs.gentoo.org/show_bug.cgi?id=592060, to discuss adding Ada
> support into Gentoo's toolchain.eclass.

> Thoughts?

Did you have a look at https://bugs.gentoo.org/show_bug.cgi?id=592060 ?

I had been almost there, but then I stopped because George seemed to return
(turned out as retirement), and my only need for Ada is to bootstrap gcc-trunk
sometimes (not since then). Beyond that: I'm lacking basic Ada knowledge to
correctly finalize the missing bits, but I'm wondering why my patch still is
larger than yours.

HTH,
/haubi/

[gentoo-dev] profiles/arch/amd64/no-multilib cleanup WAS: [PATCH 1/8] profiles/hardened: Include base amd64-multilib profile in subprofile

[Michael Haubenwallner]

On 01/21/2017 11:59 PM, Michał Górny wrote:
> Include arch/amd64/no-multilib in the hardened no-multilib amd64
> variant. Confirmed with profile-dumper that it does not currently change
> anything.
> ---
>  profiles/hardened/linux/amd64/no-multilib/parent | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/profiles/hardened/linux/amd64/no-multilib/parent 
> b/profiles/hardened/linux/amd64/no-multilib/parent
> index 8305c3556463..0defac31415d 100644
> --- a/profiles/hardened/linux/amd64/no-multilib/parent
> +++ b/profiles/hardened/linux/amd64/no-multilib/parent
> @@ -1,2 +1,3 @@
> +../../../../arch/amd64/no-multilib
>  ..
> 

As hardened/linux/amd64 does inherit arch/amd64, this way arch/amd64
always overrides arch/amd64/no-multilib, rendering the latter useless.

Instead, profiles/hardened/linux/amd64/no-multilib/parent should read:
 ..
 ../../../../arch/amd64/no-multilib

Beyond that:
While arch/amd64/no-multilib of course _is_ an override to arch/amd64,
question is whether it also should _perform_ the override by itself.

Currently it does perform the override, causing lots of subsequent profiles
to end up with arch/amd64 inherited multiple times - most prominent is the
default/linux/amd64/13.0/no-multilib profile.

So removing arch/amd64/no-multilib/parent would simplify things here.

Thoughts?
/haubi/
From 9457fd8eb330a94a15bb91decec522fe1c027986 Mon Sep 17 00:00:00 2001
From: Michael Haubenwallner 
Date: Thu, 2 Mar 2017 13:52:58 +0100
Subject: [PATCH] profiles/hardened/linux/amd64/no-multilib: inherit
 arch/amd64/no-multilib late

Whether  arch/amd64/no-multilib  does _inherit_  arch/amd64
or not,  arch/amd64/no-multilib  does _extend_   arch/amd64 anyway.

So inheriting  arch/amd64/no-multilib  before  arch/amd64  always will
reset the  arch/amd64/no-multilib  to the  arch/amd64  values.
---
 profiles/hardened/linux/amd64/no-multilib/parent | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/profiles/hardened/linux/amd64/no-multilib/parent 
b/profiles/hardened/linux/amd64/no-multilib/parent
index 2909df6..9bf59c5 100644
--- a/profiles/hardened/linux/amd64/no-multilib/parent
+++ b/profiles/hardened/linux/amd64/no-multilib/parent
@@ -1,2 +1,2 @@
-../../../../arch/amd64/no-multilib
 ..
+../../../../arch/amd64/no-multilib
-- 
2.10.2

From 3f8eb7869937d6da2f79b0a6eeb448f6eedea7b3 Mon Sep 17 00:00:00 2001
From: Michael Haubenwallner 
Date: Thu, 2 Mar 2017 14:45:16 +0100
Subject: [PATCH] profiles/arch/amd64/no-multilib: do not inherit arch/amd64

While arch/amd64/no-multilib of course _is_ an override to arch/amd64,
is should not _perform_ the override by itself, as that causes lots of
subsequent profiles to end up with arch/amd64 inherited multiple times,
most prominent is the default/linux/amd64/13.0/no-multilib profile.
---
 profiles/arch/amd64/no-multilib/parent | 1 -
 1 file changed, 1 deletion(-)
 delete mode 100644 profiles/arch/amd64/no-multilib/parent

diff --git a/profiles/arch/amd64/no-multilib/parent 
b/profiles/arch/amd64/no-multilib/parent
deleted file mode 100644
index f3229c5..
--- a/profiles/arch/amd64/no-multilib/parent
+++ /dev/null
@@ -1 +0,0 @@
-..
-- 
2.10.2

[gentoo-dev] Re: [PATCH 1/4] profiles/prefix: Add arch/base to parent

[Michael Haubenwallner]

On 02/13/2017 03:40 PM, Michał Górny wrote:
> ---
>  profiles/prefix/parent | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/profiles/prefix/parent b/profiles/prefix/parent
> index 8f0e9fd7471d..3eaf2c441360 100644
> --- a/profiles/prefix/parent
> +++ b/profiles/prefix/parent
> @@ -1 +1,2 @@
> +../arch/base
>  ../features/prefix/rpath
> 

This causes duplicate inheritance of arch/base for prefix/linux/* profiles,
as they get arch/base via default/linux/* anyway.

Fixed in
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3bf75385caac73e1ffb7035b37add91ef57583fe

/haubi/

[gentoo-dev] Re: Unused profiles

[Michael Haubenwallner]

On 01/22/2017 07:56 PM, Fabian Groffen wrote:
> On 19-01-2017 20:47:46 +0100, Michał Górny wrote:

>> prefix/aix/7.1.0.0/ppc

This one I've added to profiles.desc,

>> prefix/hpux/B.11.11/hppa2.0

while just dropping this one, silently.

I've completely given up on HP-UX here already, and one would
hardly find anything working in current tree at all. Unless we
see some interest in HP-UX by someone within some time, all hpux
profiles (and keywords) may eventually go.

> Please don't remove these.  Most seem missing profile.desc ptrs to me,
> but some are odd, which needs investigation.
> 
> Thanks,
> Fabian


Thanks for notifying!
/haubi/

[gentoo-dev] [PATCH] multiprocessing.eclass: work around Cygwin FIFO shortcoming

[Michael Haubenwallner]

Hi,

same patch is about to be applied to portage:
https://github.com/gentoo/portage/pull/86

Thanks for comments!
/haubi/

>From dc80b87a87f407cece9abad81a5369e2ec5ae2a5 Mon Sep 17 00:00:00 2001
From: Michael Haubenwallner 
Date: Wed, 27 Apr 2016 15:21:52 +
Subject: [PATCH] multiprocessing.eclass: work around Cygwin FIFO shortcoming

Cygwin does not support multiple read-handles for one FIFO (yet).
As we really need just one readonly- and one writeonly-handle, we can
reorder to open one single readwrite- and one writeonly-handle.

X-Gentoo-Bug: 583962
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=583962
---
 eclass/multiprocessing.eclass | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/eclass/multiprocessing.eclass b/eclass/multiprocessing.eclass
index 70ca475..67f7e2d 100644
--- a/eclass/multiprocessing.eclass
+++ b/eclass/multiprocessing.eclass
@@ -139,11 +139,16 @@ multijob_init() {
 
 	# Setup a pipe for children to write their pids to when they finish.
 	# We have to allocate two fd's because POSIX has undefined behavior
-	# when you open a FIFO for simultaneous read/write. #487056
+	# when using one single fd for both read and write. #487056
+	# However, opening an fd for read or write only will block until the
+	# opposite end is opened as well. Thus we open the first fd for both
+	# read and write to not block ourselve, but use it for reading only.
+	# The second fd really is opened for write only, as Cygwin supports
+	# just one single read fd per FIFO. #583962
 	local pipe="${T}/multijob.pipe"
 	mkfifo -m 600 "${pipe}"
-	redirect_alloc_fd mj_write_fd "${pipe}"
 	redirect_alloc_fd mj_read_fd "${pipe}"
+	redirect_alloc_fd mj_write_fd "${pipe}" '>'
 	rm -f "${pipe}"
 
 	# See how many children we can fork based on the user's settings.
-- 
2.7.3

[gentoo-dev] Re: Empty project: ADA

[Michael Haubenwallner]

On 08/22/2016 05:58 PM, Pacho Ramos wrote:
> Now https://wiki.gentoo.org/wiki/Project:Ada is empty

While not using any Ada thing myself, occasionally I'm in need to fully
bootstrap upstream gcc, which requires C,C++,Ada compilers these days.

There's some basically accepted patches in [1] already: I've expected George
to be back and catch up here eventually - but stranded. I may not update and
commit them before I need to hack upstream gcc-trunk again...

[1] https://bugs.gentoo.org/547358

/haubi/

[gentoo-dev] Re: RFC: new USE="win32" flag for mingw and prefix/windows support

[Michael Haubenwallner]

On 04/20/2016 09:01 PM, Anthony G. Basile wrote:
> On 4/20/16 2:17 PM, Mike Frysinger wrote:
>> On 20 Apr 2016 21:01, Alon Bar-Lev wrote:
>>> On 20 April 2016 at 18:52, Ian Stakenvicius wrote:

 Comments?
>>>
>>> You should be able to achieve similar behavior by looking at libc
>>> and/or CHOST without introducing new USE flag, just like we do for
>>> aix/solaris/freebsd etc...
>>
>> agreed ... we have kernel_Winnt & elibc_Winnt already.  i think
>> those represent a mingw environment (vs a cygwin env).

Nope: We have used kernel_Winnt and elibc_Winnt for the native MS
Visual Studio compiler, wrapped with Parity[1] to provide a gcc-like
commandline interface for the toolchain.  Independent of Parity I've
seen traces of native cl.exe/lib.exe support within libtool as well.

[1] https://github.com/haubi/parity

> The way I think of it is
> 
> the operating system (ie kernel) = kernel_Winnt
> the system libraries (=~libc)= elibc_Winnt
> the executable binary format = win32

Right now, for kernel_Winnt, in the prefix/windows profiles we have:

  + elibc_Interix
. runtime environment: Interix libc, CHOST=i586-pc-interixN.N
. python+bash+portage: yes
. accessible API (UI): POSIX (X11 client)
. executable format  : PE32 executable for MS Windows (POSIX) Intel 80386 
32-bit
. compiler: GNU gcc
. used as : build environment for elibc_Winnt: 
CBUILD=CHOST=i586-pc-winntN.N (non-cross)
. state   : dead, but in production here

  + elibc_Winnt (32bit only for now)
. runtime environment: MSVCRT, CHOST=i586-pc-winntN.N
. python+bash+portage: no
. accessible API (UI): Win32 (Win32)
. executable format  : PE32 executable for MS Windows ({console,GUI}) Intel 
80386 32-bit
. compiler: MSVC cl.exe (wrapped by Parity)
. used as : runtime environment for my company's application
. state   : old, in production here, to be updated

  + elibc_Cygwin
. runtime environment: newlib (Cygwin), CHOST={i686,x86_64}-pc-cygwin
. python+bash+portage: yes
. accessible API (UI): POSIX (X11 client), Win32 (Win32)
. executable format  : PE32 executable ({console,GUI}) Intel 80386, for MS 
Windows
   PE32+ executable ({console,GUI}) x86_64, for MS 
Windows
. compiler: GNU gcc
. used as : build environment for elibc_Winnt: CBUILD=CHOST=i586-pc-winnt 
(non-cross)
build environment for elibc_Mingw: 
CBUILD=CHOST={i686,x86_64}-w64-mingw32 (non-cross)
. state   : under construction, cygwin fork patch necessary (upstream 
review pending)


For MinGW, IMHO it feels more straightforward to add something like:

  + elibc_Mingw (mingw-w64.org I guess, not mingw.org)
. runtime environment: MinGW-W64, CHOST={i686,x86_64}-w64-mingw32
. python+bash+portage: no
. accessible API (UI): Win32 (Win32)
. executable format  : PE32 executable ({console,GUI}) Intel 80386, for MS 
Windows
   PE32+ executable ({console,GUI}) x86_64, for MS 
Windows
. compiler: GNU gcc
. used as : runtime environment for various applications
. state   : proposal

> I don't know that we need an executable binary format flag, but we might
> because they're working on windows 10 so it can natively run ELF.

Well, nope:
Although Windows Desktop (only, not Windows Server) can run ELF somewhat 
"natively",
it is not possible to start Windows executables from within a Linux executable.
This makes me assume there is no access to the Win32 API from within Linux 
either.
Also, they explicitly focus on the commandline only, not the GUI.

So WSL (Windows Subsystem for Linux) does not seem to be useable as replacement 
for
any of these currently possible non-crosscompiling setups:
  * Interix/Cygwin building Winnt (.exe runs natively)
  * Interix/Cygwin building Mingw (.exe runs natively)
  * Linux building Mingw (.exe runs in Wine)

For the USE flag:
As Cygwin allows for both X11 and Win32 UI, I do see fit for an additional 
"win32ui"
or similar (win32gui, w32ui, w32gui, winui, wingui, wntui, wntgui) USE flag.

And what about the new "win8ui" (formerly called Metro):
Do/will GTK+, Qt and others support that too eventually?

Probably we may end up with something like: IUSE="X aqua win32ui win8ui"

My 2*2 cents,
/haubi/

[gentoo-dev] Re: gnatbuild.eclass refactoring: new/transitory eclass?

[Michael Haubenwallner]

Hi George,

On 09/03/2015 04:00 PM, George Shapovalov wrote:
> I am about to start a long-overdue refactoring of the gnat (Ada compilers) 
> build system, governed by the gnatbuild.eclass. Given that nature of the 
> packages concerned and, for quite some time, I was the only person brave 
> enough to even touch this beast this probably does not concern too many 
> people. However, since I am likely to produce some observable effects, such 
> as 
> introduction of a (possibly transitory) new eclass, I am giving a requisite 
> heads-up here.
> 
> First a short but necessary introduction:
> gnatbuild.eclass is a complex and ancient beast controlling the build of the 
> two Ada compilers we have in the tree - gnat-gcc (by FSF) and gnat-gpl (by 
> AdaCore). It has been created some 10 years ago, following the 
> toolchain.eclas 
> of then, long before even functions like src_prepare were envisioned and the 
> term pms existed only in medical terminology. Correspondingly, it is composed 
> of big blocks of code, not very modular and can benefit greatly of new 
> practices.
> 
> The catch is that all the gnat-xxx ebuilds depend on it and replacing the 
> eclass would require modifying all of the ebuilds at the same time. Given the 
> typical adjustmentsto address gcc backend gets bumps and the differences 
> between two implementations, doing a big, all-in-one change like that is a 
> perfect recipe for disaster that would likely lead to total breakage of gnat 
> build system and the project that is never complete at the same time. 
> Therefore I am thinking to do it in a more usual and gradual manner: 

Just wondering whether you are aware of https://bugs.gentoo.org/547358 already:

Although I'm not an Ada dev, as gcc upstream committer I've need to bootstrap
the Ada parts within gcc as well, but faced that neither AdaCore nor gnat-xxx
ebuilds provide a C,C++,Ada compiler. Given that AdaCore seems to not provide
anything up-to-date at all any more, my idea was to provide the recent FSF Ada
compiler via toolchain.eclass only.

Thanks!
/haubi/

[gentoo-dev] Re: Naming of repositories: gento-x86 edition, bike shedding wanted

[Michael Haubenwallner]

On 03/14/2015 11:25 PM, Robin H. Johnson wrote:
> It will be the single tree that contains what you find today in the

In my FOSDEM talk[1][2] I had to refer to things like gx86 as well, and tried 
hard
to avoid using "gentoo-x86". Actually I've ended up with the term "tree" too.

In particular, I've used these names for various instances of an "ebuild-tree":

 (ship as) (built from)
gentoo-tree = gentoo-tree
prefix-tree = gentoo-tree + prefix-overlay
   lts-tree = clone(prefix-tree)
  wlts-tree = lts-tree+ wamas-overlay

Additionally, for Gentoo/Prefix the goal is to empty out the prefix-overlay,
so both Gentoo/Linux and Gentoo/Prefix should be feed by the "gentoo-tree" then.

However, as long as the name does fit such metadistro-derivation use-cases,
I don't care too much - for example I'd be fine with something like these:
  for gentoo-tree: gentoo{,-core,-base,-main}-tree
or with namespace: gentoo/{core,base,main}-tree
  for prefix-tree: gentoo-prefix-tree, gentoo/prefix-tree
and when derived by someone else (vendor=ssi):
  forlts-tree: ssi{-lts,-core,-base,-main,-gentoo}-tree, 
ssi-lts/{core,base,main,gentoo}-tree
  for   wlts-tree: ssi-wlts-tree, ssi/wlts-tree, ssi-lts/wamas-tree

Anyway, my favourite is "gentoo-tree".

> Questions:
> 0. What names for the tree/repository.
> 1. We have some namespaces in Git: proj, dev, priv, data, sites, exp; should
>the tree be in one of those namespaces, a new namespace, or be without
>a namespace? git://anongit.gentoo.org/NEW-NAME.git.

git://anongit.gentoo.org/gentoo{,-core,-base,-main}-tree.git
git://anongit.gentoo.org/data/gentoo{,-core,-base,-main}-tree.git
git://anongit.gentoo.org/gentoo/{core,base,main}-tree.git
git://anongit.gentoo.org/tree/gentoo{,-core,-base,-main}{,-tree}.git

[1] 
http://video.fosdem.org/2015/devroom-distributions/providing_an_lts_distro_with_gentoo_prefix.mp4
[2] http://thread.gmane.org/gmane.linux.gentoo.devel/95226

my 2+2 ct,
/haubi/

[gentoo-dev] [heads-up] Use-case for the meta-distro (FOSDEM-talk)

[Michael Haubenwallner]

Hi,

now as the video recording is available:
A probably noteworthy use-case using Gentoo/Prefix in production:

*) Providing a Long-Term Support distribution with Gentoo Prefix
   
http://video.fosdem.org/2015/devroom-distributions/providing_an_lts_distro_with_gentoo_prefix.mp4

/haubi/

[gentoo-dev] Re: toolchain.eclass: need to revert fixincludes commit

[Michael Haubenwallner]

On 02/03/2015 08:55 PM, Anthony G. Basile wrote:
> On 02/02/15 19:06, viv...@gmail.com wrote:
>> Il 02/02/2015 23:30, Pacho Ramos ha scritto:
>>> El sáb, 31-01-2015 a las 16:48 -0500, Anthony G. Basile escribió:
 Hi everyone,

 We need to revert the following change to toolchain.eclass:

 http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/toolchain.eclass?r1=1.647&r2=1.648


>>> Please remember to add a comment to the eclass with the reference to not
>>> forget in the future why fixincludes stuff is needed ;)
>>>
>> fixincludes only on prefix and bsd is doable/acceptable?
> 
> @pacho.  absolutely.   part of the process is me learning the layers of 
> history there.
> its not like the code is hard to read, its just "why was this done?".
> 
> @vivo75. the fixedincludes are removed after compiling, so they don't make it 
> to $ROOT
> during qmerge either for linux or bsd/prefix.
> Its just that are needed during compiling for fbsd/prefix.

To complete this info: At least in prefix they have to be installed as well,
as subsequent packages may still use host's (libc at least) headers, and gcc
requires them to be "fixed".

> So a straight revert is fine.

Fine for now, it's forked in prefix-overlay still.

> We need to explain this in a comment in case some "clever" future dev doesn't 
> comes to the
> same erroneous conclusion, that its okay to just disable their build.

Thanks!
/haubi/

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

[Michael Haubenwallner]

Am 2014-07-30 19:33, schrieb Samuli Suominen:
> 
> On 30/07/14 20:29, Michael Haubenwallner wrote:
>> Am 2014-07-30 14:33, schrieb Samuli Suominen:
>>> There is no need to package.mask if proper if -logic is used, like, for
>>> example,
>>>
>>> if [[ ${PV} == * ]]; then
>>> inherit git-r3
>>> KEYWORDS=""
>>> else
>>> KEYWORDS="~amd64 ~arm ~arm64 ~x86"
>>> fi
>>>
>>> Then you can just `cp foo-.ebuild foo-1.2.3.ebuild` and it'll have
>>> the KEYWORDS
>>> ready, and 1.2.3 and  ebuilds can be identical
>> Which instance of the KEYWORDS line is touched by the ekeyword tool these 
>> days?
>>
>> To have ekeyword touch the else-part in the release ebuild, what about this:
>>
>> if [[ ${PV} == * ]]; then
>>   inherit vcs...
>>   :; KEYWORDS=""
>> else
>>   KEYWORDS="..."
>> fi
>>
>> /haubi/
>>
> 
> You are propably looking for this,
> http://bugs.gentoo.org/show_bug.cgi?id=321475
> 

Indeed, thanks!

/haubi/

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

[Michael Haubenwallner]

Am 2014-07-30 14:33, schrieb Samuli Suominen:
> 
> There is no need to package.mask if proper if -logic is used, like, for
> example,
> 
> if [[ ${PV} == * ]]; then
> inherit git-r3
> KEYWORDS=""
> else
> KEYWORDS="~amd64 ~arm ~arm64 ~x86"
> fi
> 
> Then you can just `cp foo-.ebuild foo-1.2.3.ebuild` and it'll have
> the KEYWORDS
> ready, and 1.2.3 and  ebuilds can be identical

Which instance of the KEYWORDS line is touched by the ekeyword tool these days?

To have ekeyword touch the else-part in the release ebuild, what about this:

if [[ ${PV} == * ]]; then
  inherit vcs...
  :; KEYWORDS=""
else
  KEYWORDS="..."
fi

/haubi/

Re: [gentoo-dev] new profile layout with flavors and mix-ins

[Michael Haubenwallner]

On 07/03/2014 08:18 AM, Joshua Kinard wrote:
> On 07/02/2014 13:54, Michał Górny wrote:
>> Dnia 2014-07-02, o godz. 10:44:16
> [snip]
>>
>> I don't feel like we ought to vote on something like this without
>> understanding most of the current profiles. And I'm afraid there are
>> only few people who have any idea about the current profile
>> structure...
>>
> 
> I am going to throw this out there and see what people think.  Maybe it's
> insane, maybe it's not, maybe it's a mix of insane and not-insane.
> 
> Years ago, before we had the current stacking profile design (we were
> discussing the current design, actually), I kinda conjured up this "building
> blocks" like approach for a profile design.

> The idea being that, in /etc/make.conf (or wherever that file is now), you'd
> define $PROFILE like this:
> 
> linux-mips o32 uclibc server:
> PROFILE="base:kernel/linux:arch/mips:subarch/mips-o32:libc/uclibc:roles/server:releases/13.0"

What about making /etc/portage/make.profile a directory rather than a symlink,
having /etc/portage/make.profile/parent to reference all the flavours?

Tools that need to respect the /current/ profile should work without any 
change, and
tools that need to respect the /available/ profiles (repoman) already do have a 
list
of profiles to respect (profiles/profiles.desc).

So the only missing thing would be the eselect profile module to manage entries 
of
/etc/portage/make.profile/parent, maybe using 
/usr/portage/profiles/profiles.desc
as the source for available flavours.

my 2 cents
/haubi/

Re: [gentoo-dev] mbox -- looks sort of interesting

[Michael Haubenwallner]

On 02/11/14 01:36, Jason A. Donenfeld wrote:
> Hey folks,
> 
> Late night clicking-while-drooling, I came across something a few
> minutes ago that mildly piqued my interest -- mbox
> . It's a sandbox that uses a
> combination of ptrace and seccomp bpf; neither ours nor exherbo's uses
> both of these together. The killer feature, for us, that's motivating
> me to write to this list, is that it creates a "shadow file system",
> and then has the option to commit the changes of that file system to
> the real file system, piece by piece, when the process is done. It
> made me think of some discussions we had at FOSDEM about Portage
> evolution and whatnot. I haven't looked at this tool past an initial
> glance, but it does look like interesting food for thought.

Sounds interesting, especially the "without special privileges" bit...

/haubi/

[gentoo-dev] Re: [PATCH] libtool.eclass: Have elibtoolize explicitly apply configure patches

[Michael Haubenwallner]

On 11/15/2013 11:02 AM, Michael Haubenwallner wrote:
>> as you might or might not be aware of, elibtoolize() originally was for 
>> applying
>> patches to ltmain.sh, but now also applies patches to configure scripts.

>> Attached patch drops that wild guesses, explicitly applying 
>> configure-patches to
>> configure scripts, while still explicitly applying ltconf.sh-patches to 
>> ltconf.sh.

> One update to this patch, to run elibtoolize once per directory again,
> even if both filenames are in that same directory:

> Without objections, I plan to commit this patch by the end of next week.

committed.

/haubi/

[gentoo-dev] Re: [PATCH] libtool.eclass: Have elibtoolize explicitly apply configure patches

[Michael Haubenwallner]

On 11/13/2013 10:14 AM, Michael Haubenwallner wrote:
> Hi all,
> 
> as you might or might not be aware of, elibtoolize() originally was for 
> applying
> patches to ltmain.sh, but now also applies patches to configure scripts.

> Attached patch drops that wild guesses, explicitly applying configure-patches 
> to
> configure scripts, while still explicitly applying ltconf.sh-patches to 
> ltconf.sh.

One update to this patch, to run elibtoolize once per directory again,
even if both filenames are in that same directory:

-   set -- $(find "${S}" '(' -name ltmain.sh -o -name configure ')' 
-printf '%h ')
+   set -- $(find "${S}" '(' -name ltmain.sh -o -name configure ')' 
-printf '%h\n' | sort -u)

> WDYT?

Without objections, I plan to commit this patch by the end of next week.

Thank you!
/haubi/
Index: libtool.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/libtool.eclass,v
retrieving revision 1.106
diff -u -r1.106 libtool.eclass
--- libtool.eclass  11 May 2013 11:17:58 -  1.106
+++ libtool.eclass  15 Nov 2013 09:57:08 -
@@ -204,9 +204,9 @@
# Reuse "$@" for dirs to patch
set --
if [[ ${do_shallow} == "yes" ]] ; then
-   [[ -f ${S}/ltmain.sh ]] && set -- "${S}"
+   [[ -f ${S}/ltmain.sh || -f ${S}/configure ]] && set -- "${S}"
else
-   set -- $(find "${S}" -name ltmain.sh -printf '%h ')
+   set -- $(find "${S}" '(' -name ltmain.sh -o -name configure ')' 
-printf '%h\n' | sort -u)
fi
 
local d p
@@ -225,8 +225,12 @@
ewarn "  avoid this if possible (perhaps by filing a 
bug)"
fi
 
+   local ret
+
+   # patching ltmain.sh
+   [[ -f ${d}/ltmain.sh ]] &&
for p in ${elt_patches} ; do
-   local ret=0
+   ret=0
 
case ${p} in
portage)
@@ -258,17 +262,6 @@
ELT_walk_patches "${d}/ltmain.sh" "${p}"
ret=$?
;;
-   uclibc-conf)
-   if grep -qs 'Transform linux' 
"${d}/configure" ; then
-   ELT_walk_patches 
"${d}/configure" "${p}"
-   ret=$?
-   # ltmain.sh and co might be in a 
subdirectory ...
-   elif [[ ! -e ${d}/configure ]] && \
-grep -qs 'Transform linux' 
"${d}/../configure" ; then
-   ELT_walk_patches 
"${d}/../configure" "${p}"
-   ret=$?
-   fi
-   ;;
uclibc-ltconf)
# Newer libtoolize clears ltconfig, as 
not used anymore
if [[ -s ${d}/ltconfig ]] ; then
@@ -276,34 +269,12 @@
ret=$?
fi
;;
-   fbsd-conf)
-   if grep -qs 'version_type=freebsd-' 
"${d}/configure" ; then
-   ELT_walk_patches 
"${d}/configure" "${p}"
-   ret=$?
-   # ltmain.sh and co might be in a 
subdirectory ...
-   elif [[ ! -e ${d}/configure ]] && \
-grep -qs 
'version_type=freebsd-' "${d}/../configure" ; then
-   ELT_walk_patches 
"${d}/../configure" "${p}"
-   ret=$?
-   fi
-   ;;
fbsd-ltconf)
if [[ -s ${d}/ltconfig ]] ; then
ELT_walk_patches 
"${d}/ltconfig" "${p}"
ret=$?
fi
   

[gentoo-dev] [PATCH] libtool.eclass: Have elibtoolize explicitly apply configure patches

[Michael Haubenwallner]

Hi all,

as you might or might not be aware of, elibtoolize() originally was for applying
patches to ltmain.sh, but now also applies patches to configure scripts.

The problem is that finding configure scripts to be patched is based on where
ltmain.sh is found in ${S}, wild guessing that ltmain.sh may reside in 
subdirectories,
trying ./configure, ../configure and ../../configure inconsistently.

But especially with gettext, this wild guess does not identify each configure 
script.

Attached patch drops that wild guesses, explicitly applying configure-patches to
configure scripts, while still explicitly applying ltconf.sh-patches to 
ltconf.sh.

WDYT?

Thank you!
/haubi/

Index: libtool.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/libtool.eclass,v
retrieving revision 1.106
diff -u -r1.106 libtool.eclass
--- libtool.eclass  11 May 2013 11:17:58 -  1.106
+++ libtool.eclass  12 Nov 2013 10:10:46 -
@@ -204,9 +204,9 @@
# Reuse "$@" for dirs to patch
set --
if [[ ${do_shallow} == "yes" ]] ; then
-   [[ -f ${S}/ltmain.sh ]] && set -- "${S}"
+   [[ -f ${S}/ltmain.sh || -f ${S}/configure ]] && set -- "${S}"
else
-   set -- $(find "${S}" -name ltmain.sh -printf '%h ')
+   set -- $(find "${S}" '(' -name ltmain.sh -o -name configure ')' 
-printf '%h ')
fi
 
local d p
@@ -225,8 +225,12 @@
ewarn "  avoid this if possible (perhaps by filing a 
bug)"
fi
 
+   local ret
+
+   # patching ltmain.sh
+   [[ -f ${d}/ltmain.sh ]] &&
for p in ${elt_patches} ; do
-   local ret=0
+   ret=0
 
case ${p} in
portage)
@@ -258,17 +262,6 @@
ELT_walk_patches "${d}/ltmain.sh" "${p}"
ret=$?
;;
-   uclibc-conf)
-   if grep -qs 'Transform linux' 
"${d}/configure" ; then
-   ELT_walk_patches 
"${d}/configure" "${p}"
-   ret=$?
-   # ltmain.sh and co might be in a 
subdirectory ...
-   elif [[ ! -e ${d}/configure ]] && \
-grep -qs 'Transform linux' 
"${d}/../configure" ; then
-   ELT_walk_patches 
"${d}/../configure" "${p}"
-   ret=$?
-   fi
-   ;;
uclibc-ltconf)
# Newer libtoolize clears ltconfig, as 
not used anymore
if [[ -s ${d}/ltconfig ]] ; then
@@ -276,34 +269,12 @@
ret=$?
fi
;;
-   fbsd-conf)
-   if grep -qs 'version_type=freebsd-' 
"${d}/configure" ; then
-   ELT_walk_patches 
"${d}/configure" "${p}"
-   ret=$?
-   # ltmain.sh and co might be in a 
subdirectory ...
-   elif [[ ! -e ${d}/configure ]] && \
-grep -qs 
'version_type=freebsd-' "${d}/../configure" ; then
-   ELT_walk_patches 
"${d}/../configure" "${p}"
-   ret=$?
-   fi
-   ;;
fbsd-ltconf)
if [[ -s ${d}/ltconfig ]] ; then
ELT_walk_patches 
"${d}/ltconfig" "${p}"
ret=$?
fi
;;
-   darwin-conf)
-   if grep -qs '&& echo \.so ||' 
"${d}/configure" ; then
-   ELT_walk_patches 
"${d}/configure" "${p}"
-   ret=$?
-   # ltmain.sh and co might be in a 
subdirectory ...
-   elif [[ ! -e ${d}/configure ]] && \
-grep -qs '&& echo \.so ||' 
"${d}/../configure" ; then
-

Re: [gentoo-dev] Automagic pax-mark

[Michael Haubenwallner]

On 04/08/2013 12:08 AM, Anthony G. Basile wrote:
> On 04/07/2013 05:20 PM, Mike Gilbert wrote:
>> On Sun, Apr 7, 2013 at 5:11 PM, Chí-Thanh Christopher Nguyễn
>>  wrote:
>>> Hello All,
>>>
>>> After recent changes in dev-lang/v8 and related ebuilds, the pax-mark call 
>>> no
>>> longer has a || die. This means that the resulting binaries may have PT_PAX,
>>> XATTR_PAX, both or neither markings depending on kernel configuration,
>>> filesystem and mount options.

Although not used to PaX in general, I've fixed a bug report[1] where "pax-mark 
-c" was
sufficient to get some prebuilt thirt-party binary to run on user's hardened 
machine.

>> In the mean time, maybe we could disable XATTR_PAX markings by default
>> for people not using the hardened profile.
>>
> You can disable either or both type of pax markings by setting PAX_MARKINGS.
> We can change the default in the eclass.  Its currently set to "PT XT".
> Setting it to "PT" would revert to only doing PT_PAX markings.
> Then users will have to manually set XT in their make.conf.

While fixing that bug I've discovered the default value of PAX_MARKINGS="PT"
(has changed to "PT XT" since), but no profile actually setting 
PAX_MARKINGS="none".

Actually I've wondered if it would make more sense to default to 
PAX_MARKINGS="none",
and have the hardened profiles (or the user in make.conf) set a different value.

But thinking again now, I'm wondering if pax-mark should be done in pkg_preinst 
rather
than src_install - for the sake of binary merges when the build machine has 
different
PAX_MARKINGS than the target machine (no idea if that ever would happen).

[1] https://bugs.gentoo.org/show_bug.cgi?id=456694

my 2 cents
/haubi/

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Michael Haubenwallner]

On 01/24/13 16:49, Michael Orlitzky wrote:
> On 01/24/13 05:02, Michael Haubenwallner wrote:
>>
>> I've recently upgraded some server from kernel-2.6.28 to kernel-3.5.7 and
>> encountered that the root-device was renamed from /dev/cciss/c0d0p1 to
>> /dev/sda1 due to some kernel driver change (took me a while to find out).
>> I'm not using genkernel or any initramfs, nor do I have separate /usr.
>>
>> The only way I've found to keep the system bootable with both kernels
>> (for the upgrade process until the new kernel config was good enough)
>> was to replace /dev/cciss/c0d0p1 by /dev/root in /etc/fstab.
>>
>> How would this be done when there is no /dev/root any more?
> 
> These are the Compaq SmartArray controllers (usually found in HP
> Proliants). They used to have their own block driver, but these days
> they're just grouped with the rest of the SCSI drives.

Yep, this is a HP DL380 G6, and lspci says:
04:00.0 RAID bus controller: Hewlett-Packard Company Smart Array G6 controllers 
(rev 01)

> The old driver:
> 
>   Block Devices -> BLK_CPQ_CISS_DA
> 
> The new one is under,
> 
>   SCSI device support -> SCSI low-level drivers -> SCSI_HPSA
 
> The HPSA driver does *not* work on older Proliants, so I can only assume
> that HPSA is receiving active maintenance while the old block driver is
> not. Nevertheless, if the block driver worked for you in an old kernel,
> you could simply disable HPSA on the new one.

Well, I'm pretty sure to have started with BLK_CPQ_CISS_DA=y in the new kernel
config, but this driver doesn't seem to feel responsible for that controller
any more - or what else could have make me wonder where /dev/cciss/* has gone?
Finally I went along [1] to identify SCSI_HPSA as the correct driver.
[1] 
http://www.linuxtopia.org/online_books/linux_kernel/kernel_configuration/ch08s02.html

> When the time comes that you need to boot two newish kernels, you can
> re-enable HPSA and update fstab to use the new name.

So this didn't work out IIRC - but I won't retest that now. For the curious:
  $ cat /sys/bus/pci/devices/\:04\:00.0/vendor 
  0x103c
  $ cat /sys/bus/pci/devices/\:04\:00.0/device 
  0x323a

/haubi/

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Michael Haubenwallner]

On 01/23/13 19:29, Felix Kuperjans wrote:
> Samuli Suominen wrote:
>> please review this news item, seems we need one after all
> 
> /dev/root is no longer available in this udev version, so people who put
> this in their /etc/fstab might end up with an unbootable system.
> 
> I suggest including in the news item, that /dev/root must be replaced
> with the actual root device or LABEL=..., UUID=... and the like in
> /etc/fstab.

I've recently upgraded some server from kernel-2.6.28 to kernel-3.5.7 and
encountered that the root-device was renamed from /dev/cciss/c0d0p1 to
/dev/sda1 due to some kernel driver change (took me a while to find out).
I'm not using genkernel or any initramfs, nor do I have separate /usr.

The only way I've found to keep the system bootable with both kernels
(for the upgrade process until the new kernel config was good enough)
was to replace /dev/cciss/c0d0p1 by /dev/root in /etc/fstab.

How would this be done when there is no /dev/root any more?

So yes, please include the /dev/root drop (at least) in the news item.

/haubi/

Re: [gentoo-dev] Proposal to end-of-life tree-clean old profiles/updates/ files

[Michael Haubenwallner]

On 12/10/2012 12:10 AM, "Paweł Hajdan, Jr." wrote:
>> I propose that we say, once a year, schedule a tree-cleaning of old
>> updates files.  These updates files could be added to a tarball made
>> available for download.  That way if they are needed to update a system
>> older than what the main tree has been tree-cleaned to. They can then be
>> manually downloaded, extracted to the normal location and then run the
>> "fixpackages" command.
> 
> I think that complicates the process. :-/ But maybe the advantages
> outweigh that.
> 
>> The main question here is what is a reasonable length of time to keep
>> the updates actively in-tree?
>>
>>  -- From my experience in the forums, I think any updates older than 
>> 4 years should be subject to tree-cleaning.  
> 
> Yeah, 4 years is ancient and would probably be non-trivial to update anyway.
> 
>>  -- Most old systems that have been updated tend to be less than that,
>> probably about 2 years.
> 
> 2 years seem reasonable.

For the records:
We do have some Gentoo box serving as VirtualBox host here, installed in early 
2010,
not updated since then, with an uptime of 836 days right now. It is subject to 
upgrade,
but there may come another year until that to happen ("never change a running 
system").
Although I do not expect the update to be trivial, keeping things like pkgmove 
for at
least 4 years sounds reasonable.

/haubi/

Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force

[Michael Haubenwallner]

On 04/27/12 00:03, Andreas K. Huettel wrote:

 as soon as possible (which likely means in the next EAPI?):

* two new files in profile directories supported, package.use.stable.mask and
package.use.stable.force
* syntax is identical to package.use.mask and package.use.force
* meaning is identical to package.use.mask and package.use.force, except that
the resulting rules are ONLY applied iff a stable keyword is in use


Wouldn't it be more obvious/simple to have an extra profile subdirectory
containing package.use.mask and package.use.force?

Maybe in combination with 'eselect profile' to be able to select multiple
profiles [1], selecting both what /etc/make.profile pointed to as symlink
as well as some /usr/portage/profile/unstable/$arch - to avoid the need
for having an extra unstable/ subdir within each (selectable) profile dir.

Actually, I do have an extra unstable/ subdir for each selectable profile
here, besides an extra buildbot/ subdir too...

As a side effect, this wouldn't affect EAPI in any way.

[1] 
http://archives.gentoo.org/gentoo-dev/msg_a69bee8bfa00146ee05e49adf722e791.xml

my .02
/haubi/
--
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Packages maintained by mduft need a co-maintainer

[Michael Haubenwallner]

On 04/14/2012 01:30 PM, Pacho Ramos wrote:
> Due long devaway, his packages need a co-maintainer, feel free to add to
> metadata if you want. Thanks:
> app-portage/prefix-chain-setup
> sys-apps/prefix-chain-utils

Even if prefix-chaining most likely is broken ATM in prefix-portage,
(IMO) they still belong to prefix herd. Why have they shown up at all?

> sys-libs/suacomp
> sys-devel/parity
> sys-libs/itx-bind

Added myself, target Interix/Windows only.
Not sure if we can/want/should take them to prefix herd.

> net-proxy/cntlm

Still open.

/haubi/

Re: [gentoo-dev] Packages up for grabs due dertobi123 retirement

[Michael Haubenwallner]

On 02/09/2012 11:49 AM, Pacho Ramos wrote:
> Due dertobi123 retirement the following packages need a new maintainer:

> dev-db/oracle-instantclient-basic
> dev-db/oracle-instantclient-sqlplus

mine, I do use them in Gentoo Linux, and plan to use them in Gentoo Prefix too.

> dev-db/oracle-instantclient-jdbc
> dev-db/oracle-instantclient-odbc

Might take them along with the above, even without real use-case here.

> dev-db/tora

Ohw, a Qt application - something new to me.
However, I do see need for that in Prefix here too.

/haubi/

Re: [gentoo-dev] Rotating oversized ChangeLog files

[Michael Haubenwallner]

On 11/03/2011 01:33 AM, Andreas K. Huettel wrote:
> In a week's time I personally, manually, will "rotate" all ChangeLog files 
> larger than 100k in the tree, by splitting them at 31/12/2010-1/1/2011.

> Opinions, flames, ...?



Again for 'emerge --changelog':

As we do have the "$delay before breaking old" period, usually with $delay="1 
year":
Should we also apply this $delay to the output of above command?

If yes, what I can think of ATM is:
* Do that first splitting in January 2012 (in less than 2 months).
* Have PM search in the old ChangeLogs if necessary.

The latter would also allow for completely emptying current ChangeLog each 
January
by moving that to ChangeLog-$lastyear.



/haubi/

Re: [gentoo-dev] [Council] ChangeLog generation within Gentoo

[Michael Haubenwallner]

On 10/26/11 19:33, Bruno wrote:
> In order to not bloat the tree I would like to see old entries purged
> when there are more than 25-50 of them, especially if they refer to
> ebuilds gone since more than 3-6 months.

One thing to remember:

Even if old ebuilds are gone in the tree already, they still may be
installed on users systems. As a result, 'emerge --changelog' searches
for their addition-entries in ChangeLog.

So when purging ChangeLog's really becomes necessary, we might need to
keep the addition-entries back to until a once-been-stable ebuild was
superseded by another stable ebuild more than 1 year ago - or sth. similar.

my 0.02 [€$?]

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] new helper: econf_build

[Michael Haubenwallner]

On 10/14/11 17:45, Mike Frysinger wrote:
> On Friday 14 October 2011 03:08:14 Michael Haubenwallner wrote:
>> On 10/14/11 01:48, Mike Frysinger wrote:
>>> i've found myself a few times having to implement logic like so:
>>> CFLAGS=${BUILD_CFLAGS:--O1 -pipe} \
>>> CXXFLAGS=${BUILD_CXXFLAGS:--O1 -pipe} \
>>> CPPFLAGS=${BUILD_CPPFLAGS} \
>>> LDFLAGS=${BUILD_LDFLAGS} \
>>> CC=$(tc-getBUILD_CC) \
>>> LD=$(tc-getBUILD_LD) \
>>> econf --host=${CBUILD} "$@"
>>
>> 

> i'll probably implement as an @INTERNAL:
> tc-env_build() { ... }
> 
> then define econf_build on top of that as an exported API.  then let's see 
> what 
> grows organically beyond.

Fine with me.

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] new helper: econf_build

[Michael Haubenwallner]

On 10/14/11 01:48, Mike Frysinger wrote:
> i've found myself a few times having to implement logic like so:
>   CFLAGS=${BUILD_CFLAGS:--O1 -pipe} \
>   CXXFLAGS=${BUILD_CXXFLAGS:--O1 -pipe} \
>   CPPFLAGS=${BUILD_CPPFLAGS} \
>   LDFLAGS=${BUILD_LDFLAGS} \
>   CC=$(tc-getBUILD_CC) \
>   LD=$(tc-getBUILD_LD) \
>   econf --host=${CBUILD} "$@"
> 

> so rather than continuing to copy & paste this logic everywhere, i'm going to 
> add it to toolchain-funcs.eclass as "econf_build".  any feedback before i do ?

Eventually not to stick to 'econf', but provide a more generic one,
so it is useable like this (in lack of a better name):

run_with_build_env econf --host=${CBUILD} ...

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] rfc: deprecation of baselayout-1.x

[Michael Haubenwallner]

On 07/01/11 07:56, Nirbheek Chauhan wrote:
> On Fri, Jul 1, 2011 at 11:03 AM, Dale  wrote:
>> William Hubbs wrote:
>> As a user, if a person hasn't upgraded in about 6 months, they may as well
>> reinstall anyway.  That is usually the advice given on -user.  After a year
>> without updating, it is certainly easier and most likely faster to
>> reinstall.
> 
> Except for the fact that while you upgrade, you still have a usable
> system. Reinstallation means a massive time-sink during which your
> machine is completely unusable. This is not an option for a lot of
> people.

I'd call myself an "affected user" in this context:
As (lazy) administrator of some servers (hardened) and desktops (stable),
both virtualbox servers and guests, as well as an x86 binhost vm for the
laptop, and the only requirement of keep-it-working, I'm doing the upgrades
somewhat seldom: up to 1.5 years, especially for the hardened servers.

As I don't care for compilation time (the servers are up 24/7), my thought
to still allow for a somewhat stable upgrade path: Regularly (twice a year?)
take a tree snapshot to keep around (infra? releng?), and provide some mechanism
(eselect?) to pick such an old snapshot instead of the current (rsync) one.
Then, run each (half-year) update within a couple of days...

Maybe the tree snapshots are there already within the live-cds: Do we aim
to provide an upgrade path from one live-cd snapshot to the next one?

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Re: How do you perform patchset versioning?

[Michael Haubenwallner]

On 05/25/2011 03:40 PM, Diego Elio Pettenò wrote:
> Il giorno mer, 25/05/2011 alle 15.34 +0200, Michael Haubenwallner ha
> scritto:
>>
>> My idea was to set a CVS-Tag on [3] for what is in each patchset
>> version, but
>> as I don't see /any/ (according to ViewVC) CVS-Tag on [1], I'm
>> unsure... 
> 
> Tags are usually applied per-directory rather than on the whole
> repository, you can find tags for instance on
> 
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/src/patchsets/xine-lib/1.1.3_pre20060831/

So I indeed just failed to find the tags - ok then.

> For git-based projects (and I don't know if mico is),

It is darcs based...

> I have a
> preference to store a git tag with the patches applied over it, as I
> described on my blog:
> 
> http://blog.flameeyes.eu/2010/09/07/maintaining-backports-with-git

Thank you!
-- 
Michael Haubenwallner
Gentoo on a different level

[gentoo-dev] How do you perform patchset versioning?

[Michael Haubenwallner]

Hello fellow developers,

I'm wondering what is Best Practice to "tag" a bunch of patches stored in some
VCS like [1], which are bundled into one single version of a patchset-tarball.

My current usecase is:
mico-2.3.13-r4[2] uses version 0.1 for the set of patches[3].

While I have to add a new patch into [3] (and bump to patchset-0.2),
I still want to be able to recreate the patchset-0.1 content from VCS
if necessary.

My idea was to set a CVS-Tag on [3] for what is in each patchset version, but
as I don't see /any/ (according to ViewVC) CVS-Tag on [1], I'm unsure...

So what are your workflows here?

Thank you!

[1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/src/patchsets/
[2] 
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-misc/mico/mico-2.3.13-r4.ebuild?revision=1.1&view=markup
[3] 
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/src/patchsets/mico/2.3.13/

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Re: Re: Downgrading glibc?

[Michael Haubenwallner]

On 02/11/11 16:24, Diego Elio Pettenò wrote:
> Il giorno ven, 11/02/2011 alle 14.23 +0100, Michael Haubenwallner ha
> scritto:
>>
>> But both that document as well as uncountable lines of source code are
>> rather old.
>> While the source code isn't that large a problem for Gentoo, existing
>> binaries
>> without source code still are.
> 
> Beside flash what else is involved for now? We can decide that once
> that's defined.

I've heard a colleague of mine debugged for 50(!) hours after moving some
quite old application to some recent Linux before he replaced a memcpy by
memmove, so this did ring some bells.

However, now he said this was on Ubuntu 10.04.1 LTS, having glibc-2.11,
so this might have been unrelated indeed.

Anyway, running old applications on recent Linux is quite common in
"enterprise" world (where Gentoo might not be such a big player).

So I'm fine with Gentoo shipping vanilla memcpy, I'm just curious
if next RHEL will do.

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] libpng-1.5 smooth upgrade

[Michael Haubenwallner]

On 02/11/2011 05:38 PM, "Paweł Hajdan, Jr." wrote:
> To ensure good upgrade experience for our users, and learning some
> lessons from previous, um... "disruptive" upgrade (1.2 -> 1.4), I'd have
> some questions:

FWIW: For that upgrade I've not used lafile-fixer or anything like that
on my stable x86 binhost.
Instead, alternating 'emerge -uDN world' with 'revdep-rebuild' a couple
of times until there was nothing more to do did work as well.

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Re: Downgrading glibc?

[Michael Haubenwallner]

On 02/11/2011 11:12 AM, Diego Elio Pettenò wrote:
> Il giorno ven, 11/02/2011 alle 10.55 +0100, Michael Haubenwallner ha
> scritto:
>>
>> what do you think of working around the memcpy troubles with
>> glibc-2.13 by
>> simply redirecting memcpy to memmove within glibc, either
>> unconditionally or
>> optional/temporary (via USE-flag?) until everyone uses memmove where
>> necessary?
> 
> That unless things start crashing down nobody will fix the issues at
> all.
> 
> We're not talking a last minute change! memcpy() *always* documented not
> to use overlapping memory areas.

Yes, *documented*, I'm aware of that.

But both that document as well as uncountable lines of source code are rather 
old.
While the source code isn't that large a problem for Gentoo, existing binaries
without source code still are.

The questions simply are:
*) Does anyone really need memcpy when there is memmove?
*) Is it worth the effort to bug everyone to replace memcpy by memmove in their
   existing applications, with or without investigating that memcpy doesn't 
suffice?

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Downgrading glibc?

[Michael Haubenwallner]

On 02/11/2011 01:20 PM, "Paweł Hajdan, Jr." wrote:
> On 2/11/11 10:55 AM, Michael Haubenwallner wrote:
>> what do you think of working around the memcpy troubles with glibc-2.13 by
>> simply redirecting memcpy to memmove within glibc, either unconditionally or
>> optional/temporary (via USE-flag?) until everyone uses memmove where 
>> necessary?
> 
> I'm not a maintainer of base-system, but it seems to me that such a
> change in behavior would only add to the confusion. glibc behaving
> differently on Gentoo than other distros... no, that doesn't sound good.

While Fedora 14 has shipped with glibc-2.13 and vanilla memcpy it seems, I'm 
really
curious if a next Red Hat Enterprise Linux or any distribution designed for 
enterprise
environments would do so, risking commercial applications to break.

So I'm not convinced yet that they can perpetuate this new memcpy 
implementation.

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Downgrading glibc?

[Michael Haubenwallner]

On 02/11/2011 09:50 AM, Sebastian Pipping wrote:
> In relation to bug 354395 [1] I would like to downgrade my glibc back to
> 2.12.2.  Portage doesn't allow me to do that:
> 
>  * Sanity check to keep you from breaking your system:
>  *  Downgrading glibc is not supported and a sure way to destruction
>  * ERROR: sys-libs/glibc-2.12.2 failed (setup phase):
>  *   aborting to save your system
> 
> Can anyone guide me or point me to a guide how to savely do that manually?

While it actually would be interesting to see some downgrade path even for 
glibc,

> [1] https://bugs.gentoo.org/show_bug.cgi?id=354395

what do you think of working around the memcpy troubles with glibc-2.13 by
simply redirecting memcpy to memmove within glibc, either unconditionally or
optional/temporary (via USE-flag?) until everyone uses memmove where necessary?

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] libstdc++ compatibility and -bin packages

[Michael Haubenwallner]

On 10/11/2010 04:40 PM, "Paweł Hajdan, Jr." wrote:
> Today I got http://bugs.gentoo.org/340517 filed against chromium-bin.
> The machine that compiled the package had only gcc-4.4.3 installed.
> 
> It'd probably be difficult to solve the problem using dependencies (the
> bug reporter had gcc-4.4.3 installed, but active version was 4.3.4).
> 
> I was thinking about using a lower version of gcc on the builder, like
> 4.1.2 or 4.3.4.
> 
> However, I'm not sure how likely this is to cause C++ ABI mismatch
> issues. I remember some problems with half of KDE compiler with one GCC
> version and half with a more recent version.
> 
> What do you think?

Iff the bug reporter would have selected gcc-4.4.3 being the active version
using 'gcc-config', his chrome should have been working IMO.

But I don't think this is an acceptable fix:

Instead, gcc-config should sort available gcc's libdirs into /etc/ld.so.conf
by /descending gcc-version independent of which one is currently selected/, as
gcc libraries are backwards compatible AFAICS when they have the same SONAME.

For linking, the selected compiler's libs are used anyway.

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Reminder: please use the latest Portage/repoman version to commit to tree

[Michael Haubenwallner]

On 09/30/2010 09:36 AM, Andreas K. Huettel wrote:
> as I've only recently "graduated to developer", I've got a question about 
> this. Diego, your request makes perfect sense to me. But, so far I always 
> thought "Python, portage, and gcc are the things that I really need to rely 
> on, so whatever I do, I'll keep those stable."
> 
> (My development machine(s) are also my real-life work machines.)

As I do second these concerns, another thought:

While /portage/ is vital to our distro (not only) for end users (including
devs doing their workwork on Gentoo systems), /repoman/ isn't.

So - would it make sense to split repoman into its own ebuild?

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] RFC: fox.eclass update

[Michael Haubenwallner]

Must admit that I have no idea of what "fox" is at all, but:

On 09/16/2010 08:32 PM, Peter Volkov wrote:
> В Чтв, 16/09/2010 в 16:24 +0200, Matti Bickel пишет:
>> -   elibtoolize
>> +   eautoreconf
> 
> Hm, is this change necessary?

The obvious reason for eautoreconf here is:
fox_src_prepare() updates configure.{ac,in} and Makefile.am's just before.

The non-obvious reason is:
Ebuilds may have to patch these files too for random (usually prefix) platforms.

Iff not eautoreconf but elibtoolize were done here, the ebuild would have to do 
the
eautoreconf itself, which doesn't work right now[1] when elibtoolize was called 
before.

[1] http://bugs.gentoo.org/show_bug.cgi?id=232820

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] [RFC] New eclass for x11 packages

[Michael Haubenwallner]

Tomáš Chvátal wrote:
> and renamed snapshot variable into saner XORG_EAUTORECONF.

> Does it fit your needs?

Sane enough for me ;), thank you!

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] [RFC] New eclass for x11 packages

[Michael Haubenwallner]

Tomáš Chvátal wrote:
> Dne 22.2.2010 11:50, Michael Haubenwallner napsal(a):
>> PS: Just a suggestion what an ebuild could do in this case:
>>  src_prepare() {
>>  xorg-2_src_prepare --force-eautoreconf
>>  }
> SNAPSHOT="yes" xorg-2_src_prepare
> 
> ^ this does not fit your needs? It does exactly what you want :]

Uhh, this doesn't look like the "clean" way and depends on 
exakt knowledge how xorg-2_src_prepare works - shouldn't
eclasses provide something like an "intuitive API" to some
degree, especially if they are "new"?

However - I'll continue looking into the eclass impl details...

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] [RFC] New eclass for x11 packages

[Michael Haubenwallner]

Tomáš Chvátal wrote:
> Hi,
> we prepared new eclass for x11 packages that should be used as
> replacement for x-modular.eclass.

> Prefix support done.

There's one thing I don't find addressed yet:

When some patch[1] necessary for some (prefix-) platform has to touch
configure.ac or Makefile.am, rendering eautoreconf mandatory on
*each* platform, there's no way to tell xorg-2_reconf_source() to
do the eautoreconf instead of elibtoolize *unconditionally*.

We had to have libXaw.ebuild do the eautoreconf unconditionally[2] after
x-modular_src_unpack() - which just did elibtoolize on some platforms,
causing elibtoolize to get run twice, resulting in bug#232820 [3].

Even if libXaw doesn't need those patches any more it seems,
there's no reason such patches won't become necessary again.

[1] 
http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/x11-libs/libXaw/files/libXaw-1.0.5-darwin.patch?rev=37037
[2] 
http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/x11-libs/libXaw/libXaw-1.0.6.ebuild?rev=49677#L43
[3] http://bugs.gentoo.org/show_bug.cgi?id=232820

/haubi/

PS: Just a suggestion what an ebuild could do in this case:
 src_prepare() {
 xorg-2_src_prepare --force-eautoreconf
 }
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Re: [rfc] layman storage location (again)

[Michael Haubenwallner]

Alex Alexander wrote:
> On Mon, Jan 18, 2010 at 09:05:58AM +0100, Peter Hjalmarsson wrote:
>> I sometimes think the main problem is the tree itself. Portage really
>> should had a directory of its own, but maybe with anoher structure,
>> like /var/portage, /var/portage/tree (the current
>> PORTDIR), /var/portage/distfiles (i.e. split out distfiles from the tree
>> itself), /var/portage/overlays/layman or /var/portage/layman.
>> I of course realize that change the structure of the whole portdir would
>> had inresting complications, so take this comment just as serious as you
>> like.
 
> /var/portage/
> /var/portage/tree
> /var/portage/layman
> /var/portage/overlays (non-layman managed, layman could also be in here)
> /var/portage/distfiles
> /var/portage/packages

Not that I really care, but are these "portage-only" and we might need
/var/{paludis,pkgcore,...}/*? So what about /var/gentoo/*?

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] RFC: multilib and the compatibility to singlelib

[Michael Haubenwallner]

Mike Frysinger wrote:
> On Wednesday 21 October 2009 07:34:18 Michael Haubenwallner wrote:
>> Mike Frysinger wrote:
>>> On Tuesday 20 October 2009 09:06:29 Michael Haubenwallner wrote:
>>>> As I'm building the toolchain myself too, I configure it with the
>>>> 32bit host triplet on each platform, usually disabling multilib.
>>> this doesnt make any sense to me
>> What exactly doesn't make sense to you:
> 
> it doesnt make sense to build your own toolchain when the default native one 
> Gentoo provides includes all multilib support already.
> 
> but i guess when you're commercially developing a binary-only package, people 
> tend to not have such freedoms as the binary-only mentality infects all 
> layers.

Even if it's commercially, it isn't binary-only here. But it is bound
to a specific set of (likely older) toolchain versions usually not
available on the target system.
I just don't want to make an exception for Gentoo Linux hosts when it
does work on both RedHat and SuSE Linux as well as *nix.

>>>> Isn't the intention of multilib to have a new (64bit) system
>>>> be compatible with the corresponding old (32bit) system?
>>> your description of "compatible" is pretty vague.  ignoring /lib ->
>>> /lib64 symlink (which shouldnt matter to any binaries), i'm not aware of
>>> any differences off the top of my head.
>> Well, "compatible" here means to me that when I do
>> $ configure --{build,host}=i686-pc-linux-gnu
> 
> assuming you simply forgot the forcing of -m32 here, or you have a fully 
> named 
> i686-pc-linux-gnu-... toolchain

I do (like to) have a fully qualified i686-pc-linux-gnu-* toolchain.
Adding -m32 would require to create the i686-pc-linux-gnu-gcc wrapper,
resulting in some kind of a fully qualified i686 toolchain again.

>> It turns out that it is the "/lib resolving to 64bit" thing only that
>> causes me headaches here, which actually is distro-specific.
> 
> i'm not against changing things to fall in line with what other distros have 
> settled on (guess that's the risk you take when you're one of the first 
> distros to do multilib), i just want this kind of decision to be fully 
> informed / thought out before making it.  it's not something i'd label 
> "trivial".

Fully agreed. But as I don't have time to carry on this symlink change,
I'm going to live with the patches for now (in Prefix).
OTOH, Debian uses /lib->/lib64 symlink too IIRC...

Thank you!
/haubi/

Re: [gentoo-dev] RFC: multilib and the compatibility to singlelib

[Michael Haubenwallner]

Mike Frysinger wrote:
> On Tuesday 20 October 2009 09:06:29 Michael Haubenwallner wrote:
>> As I'm building the toolchain myself too, I configure it with the
>> 32bit host triplet on each platform, usually disabling multilib.
> 
> this doesnt make any sense to me

What exactly doesn't make sense to you:
* building the toolchain in general:
   The application is quality assured to one specific gcc version, and
   I cannot expect that exactly this one version is available on the
   target machine, especially when some specific patches are required,
   or there is no gcc available at all, or the installation is just broken.
   And sometimes I do have multiple application releases on the same
   machine, requiring different gcc versions...
* using the 32bit host triplet:
   see below
* or disabling multilib:
   whenever possible I'd like to avoid messing with multilib.

>> But Linux "is not Unix":
> 
> you're right, so i'm not terribly concerned with compatibility with non-Linux 
> systems.  comparing the native Gentoo/Linux multilib setup to another Linux 
> multilib setup is the only useful comparison.

Agreed. Although it is uncommon that Linux causes more headaches than Unix,
especially when it is about GNU packages.

>> Configuring both binutils and gcc needs to be done with:
>>   $ CC="gcc -m32" /path/to/configure --{build,host}=i686-pc-linux-gnu ...
>> This works on 64bit RHEL as well as on 64bit SLES (both have 32bit in /lib,
>> 64bit in /lib64, no /lib32), but breaks on amd64+multilib Gentoo Linux.

> i dont get it.  why does the i686-pc-linux-gnu toolchain target matter on an 
> amd64 multilib system ?  the native x86_64-pc-linux-gnu toolchain should 
> already do the right thing when given -m32.

It is more an administrative thing: On Unix as well as x86-linux I simply
get 32bits from gcc. But for x86_64-linux I'm in need of an exception to
build/use some x86_64-gcc and wrap it with -m32, because I don't want to
force the application-maintainers to add this exception to add CFLAGS=-m32,
which can be interpreted as "require some change to keep it unchanged".
And it is ways easier to use --{build,host} than to create wrappers.

>> Isn't the intention of multilib to have a new (64bit) system
>> be compatible with the corresponding old (32bit) system?
> 
> your description of "compatible" is pretty vague.  ignoring /lib -> /lib64 
> symlink (which shouldnt matter to any binaries), i'm not aware of any 
> differences off the top of my head.

Well, "compatible" here means to me that when I do
$ configure --{build,host}=i686-pc-linux-gnu
on x86-linux, I'd like to expect this working on x86_64-linux too, as the
"_64" can be seen as an "extension"[1] to x86 I just do not want to use.

It turns out that it is the "/lib resolving to 64bit" thing only that
causes me headaches here, which actually is distro-specific.

[1] http://en.wikipedia.org/wiki/X86-64

/haubi/

[gentoo-dev] RFC: multilib and the compatibility to singlelib

[Michael Haubenwallner]

Hi devs,

while there is the appreciated multiple ABI portage support going on,
a thought on the intentions of the multilib profiles.

Some background:
I do have to support building an older, but still maintained large
application software, that simply does not work when built as 64bit.
As it does not have the need itself for >32bit pointers, and all
the 64bit target platforms do support 32bit binaries too, the plan
to fix the code for 64bits has been cancelled.

I'm using gcc to build the application on all the target unices,
as well as autotools for build management.

As I'm building the toolchain myself too, I configure it with the
32bit host triplet on each platform, usually disabling multilib.

This simply works for ppc-aix, hppa-hpux, ia64-hpux, sparc-solaris,
x86-solaris, even if the underlying OS/kernel is 64bit.
It isn't even necessary to explicitly use --{build,host} at all,
as config.guess tells the 32bit triplet on these platforms.
Additionally, even their default compiler output is 32bit.

But Linux "is not Unix":
Configuring both binutils and gcc needs to be done with:
  $ CC="gcc -m32" /path/to/configure --{build,host}=i686-pc-linux-gnu ...
This works on 64bit RHEL as well as on 64bit SLES (both have 32bit in /lib,
64bit in /lib64, no /lib32), but breaks on amd64+multilib Gentoo Linux.

Problem is that, as x86-linux isn't a multilib target, both ld and gcc
search for 32bit libs&objects in /usr/lib:/lib, as they don't know about
/usr/lib32:/lib32. The error when bootstrapping gcc is:
  /usr/lib/crti.o: file not recognized: File format not recognized

While it is possible to patch binutils[1] and gcc[2] to search in
/usr/lib32:/lib32 even with this otherways non-multilib target,
it doesn't feel like the "right thing" to enable multilib for
just one multilib option.

Isn't the intention of multilib to have a new (64bit) system
be compatible with the corresponding old (32bit) system?

Please comment, thank you!
/haubi/

[1] http://overlays.gentoo.org/proj/alt/changeset/51324
[2] http://overlays.gentoo.org/proj/alt/changeset/51325

Re: [gentoo-dev] python-wrapper breaks init scripts

[Michael Haubenwallner]

Arfrever Frehtes Taifersar Arahesis wrote:
> 2009-10-04 20:32:17 Hanno Böck napisał(a):
>> I just stepped over a problem with the new python-wrapper. If I interpreted 
>> the changelogs correctly, since eselect-python-20090801 /usr/bin/python is 
>> no 
>> longer a symlink, but a wrapper.
> 
> Since eselect-python-20090804 /usr/bin/python is a symlink to a wrapper.
>  
>> I find this a questionable idea simply for the overhead it causes, but it 
>> seems that this breaks all init-scripts using start-stop-daemon for python 
>> scripts.
>>
>> Example:
>> http://bugs.gentoo.org/show_bug.cgi?id=286191
>>
>> (same issue happens with some self-written python daemons we're using on our 
>> servers)
>>
>> I don't know what the reasons were for the change from symlinks to a wrapper
> 
> Ebuilds (usually through python.eclass) need to be able to set requested 
> version
> of Python without changing /usr/bin/python symlink. This is performed by 
> setting
> EPYTHON environment variable ("E" in the name of this variable is related to 
> words
> "ebuild" and "eclass"). If this variable isn't set, then Python wrapper uses
> version of Python configured using `eselect python`. Otherwise it uses 
> version of
> Python referenced by this variable.

The problem here IMO is that this wrapper executes python2.6 with argv0 set
to python2.6, while it should be the argv0 from how the wrapper was executed.
At least this is what init.d scripts expect (seen with ntlmaps too).

/haubi/

Re: [gentoo-dev] Re: [gentoo-soc] Re: Progress on Universal Select Tool

[Michael Haubenwallner]

Sérgio Almeida wrote:
> On Fri, 2009-07-24 at 10:22 +0200, Michael Haubenwallner wrote: 

>>> if cmd = 'chdir':
>>>   uprofile

>> ..., the automatism for the 'cd' command feels like more
>> confusing than useful...

> Atm, cd just changes dir as it is supposed to. Robert alerted us to the
> fact that we can trigger a PRE_CMD on most shells when a CHANGEDIR
> occurs. 
 
>> Instead, provide a command to update the environment for the current
>> directory, which does search for an .uprofile/ in all the parent
>> directories when there is no local one.
>> Additionally, (let the user) define a *new* command that does both
>> changing directory and updating the environment.
>>
> 
> This is the question... Call uprofile manually or detect the profile
> automatically? Both capabilities? Mmm...

I'd say leave it to the user to either use the CHANGEDIR event,
or define some alias like 'ucd', or call 'uprofile' manually only.
Eh - provide an uselect-module to select the variant...

>> Another point: the per-directory profile solution feels like there is no
>> need to distinguish between user- and directory-profile any more - as
>> the user-profile would not be anything different than ~/.uprofile/, no?
> 
> Yes and no. ~/.uselect/ contains a bin/ environment (prepended to your
> PATH by /etc/profile or something) a env.d/ and most probabily
> something else that gets executed uppon login.
> 
> This does not invalidate you having a ~/.uprofile/. uprofile will
> configure your ~/.uselect/ and your environment variables. Your user
> profile will not be interpreted by python, uprofile turns profile files
> (from python) into bin/ and env.d/ environment on your ~/.uselect.

Ohw, there is .uselect/{bin,env.d}/ ...

What about a per-directory .uselect/{bin,env.d}/ too?
I'd like to set up the complete environment/profile for a development project,
to completely take precedence over the users' environment/profile who are
working on that project, to have something like this order:
PATH=/my/project/.uselect/bin:/home/user/.uselect/bin:/etc/.uselect/bin:/usr/bin:/bin

Maybe this already is how it works?

> 
> This may seem confusing, but that's the best way I can explain. Later
> this weekend will send a call for ideas/call for modules to the dev
> list to get everyone known with the uselect environment. I'm just
> finishing cleaning up the code to start commiting and using git
> branches.

Whenever I come to test uselect/uprofile, I'll do this in Gentoo Prefix
on several platforms, not on my stable Gentoo Desktop...

Thank you!

/haubi/

Re: [gentoo-dev] Re: [gentoo-soc] Re: Progress on Universal Select Tool

[Michael Haubenwallner]

Sérgio Almeida wrote:
> On Thu, 2009-07-23 at 17:28 +0200, Robert Buchholz wrote:
>> On Thursday 23 July 2009, Sérgio Almeida wrote:
>>> You changedir, you call uprofile, and
>>> voila, new profile. You login again, default profile.

..., change back to your home dir, call uprofile, and you have your
default (=login) environment.

> if cmd = 'chdir':
>   uprofile

> What do you guys think?

While the per-directory profile sounds interesting and useful (a really
good idea!), as it might solve the requirement for per-project
environment here, the automatism for the 'cd' command feels like more
confusing than useful: "WTF does 'cd' more than change directory?"

Instead, provide a command to update the environment for the current
directory, which does search for an .uprofile/ in all the parent
directories when there is no local one.
Additionally, (let the user) define a *new* command that does both
changing directory and updating the environment.

Another point: the per-directory profile solution feels like there is no
need to distinguish between user- and directory-profile any more - as
the user-profile would not be anything different than ~/.uprofile/, no?

Thank you!

/haubi/

Re: [gentoo-dev] stacking profile.bashrc?

[Michael Haubenwallner]

On Wed, 2009-07-15 at 11:39 -0700, Zac Medico wrote:
> Michael Haubenwallner wrote:
 
> > We do have post_src_install() hook in profiles/prefix/profile.bashrc ...
> > In profiles/prefix/aix/profiles.bashrc, there is another
> > post_src_install() hook ...
> > The problem now is that the latter post_src_install() overrides the
> > former, ...

> The pre/post phase hooks are not designed for this, they are only
> intended for users to put in /etc/portage/bashrc. For what you are
> trying to do, it seems like a registration interface would be more
> appropriate (something like register_die_hook).

Should this registration api be provided by portage, or by
base/profile.bashrc?
Hmm, will have to be portage, because /etc/portage/bashrc would override
base/profile.bashrc too. base/profile.bashrc just might jump in when not
provided by installed portage yet.

>  Maybe the usage
> could go something like this:
> 
>   register_phase_hook install post my_post_src_install

For readability, I'd more like to have 'post' in front of 'install'.

Or eventually something like:

register_phase_hook \
  --before-src_install my_pre_src_install_1 my_pre_src_install_2 \
  --after-src_install my_post_src_install_1 my_post_src_install_2 \
  --before-  

Or with phase-names instead of phase-function-names:

register_phase_hook \
  --before-{setup,nofetch,unpack,prepare,configure,compile,...}  
\
  --after-{...,test,install,preinst,postinst,prerm,postrm} 

Suggesting "before&after" here as I'm always confused with
pre_pkg_preinst, post_pkg_preinst, pre_pkg_postinst, post_pkg_postinst,
pre_pkg_prerm, post_pkg_prerm, pre_pkg_postrm, post_pkg_prerm.

Anyway: besides implementation, what else does it need to get this done?

Thank you!

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Re: Progress on Universal Select Tool

[Michael Haubenwallner]

On Wed, 2009-07-15 at 16:43 +0100, Sérgio Almeida wrote:
> On Tue, 2009-07-14 at 17:07 +0200, Michael Haubenwallner wrote:
 
> > So it should be fine as long as 'symlink' can potentially be implemented
> > as 'copy' for specific platforms.

> ... can be easily replaced for copy. What should be the default?
> Should uselect be able to supply both options like "uselect --copy bla
> bla" overrides os.symlink to copy function?

Ideally it is transparent to the uselect-user (either end-user or
developer) if the implementation actually does the symlink or emulates
it via copy.
It might be enough to select the implementation based on the
"host-system" (CHOST), which may be different to the
"build-system" (CBUILD).
Eventually, uselect won't need to detect the CHOST itself, but get it
from some external resource (cmdline, env-var, config-file, ...).

> Thanks for the hint!

nP.

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

[gentoo-dev] stacking profile.bashrc?

[Michael Haubenwallner]

(seems the first mail was dropped somewhere, sorry when doubled)

Hi,

I'm facing this problem in Prefix on AIX, although it is a generic
problem IMO:

We do have post_src_install() hook in profiles/prefix/profile.bashrc to
drop charset.alias for packages != libiconv, required for non-glibc
platforms.

In profiles/prefix/aix/profiles.bashrc, there is another
post_src_install() hook with some aix specific hacks, required for
portage to allow for merging shared libraries there.

The problem now is that the latter post_src_install() overrides the
former, and I get collisions on charset.alias as the former is not
executed.

Is this a portage bug (each of them should be executed)?
Or is there some defined way to handle this I just was unable to find?

Thank you!
/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Re: Progress on Universal Select Tool

[Michael Haubenwallner]

On Mon, 2009-07-13 at 16:36 +0100, Sérgio Almeida wrote:
> Hello,
> 
> Missed a weekly report, busy week. Will try to post 2 reports this week
> as I am also working twice as much time.
> 
> Progress since last report:

> * symlinking dependencies (ex: ruby and ruby-gems)

Sorry, I've lost track on what's really going on here:
Does 'symlink' mean symlinks on the filesystem like 'ln -s' does?
Or, more important, does uselect create those symlinks itself?
If yes, please don't forget that OS without symlinks...

Thank you!
/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

[gentoo-dev] stacking profile.bashrc?

[Michael Haubenwallner]

Hi,

I'm facing this problem in Prefix on AIX, although it is a generic
problem IMO:

We do have post_src_install() hook in profiles/prefix/profile.bashrc to
drop charset.alias for packages != libiconv, required for non-glibc
platforms.

In profiles/prefix/aix/profiles.bashrc, there is another
post_src_install() hook with some aix specific hacks, required for
portage to allow for merging shared libraries there.

The problem now is that the latter post_src_install() overrides the
former, and I get collisions on charset.alias as the former is not
executed.

Is this a portage bug (each of them should be executed)?
Or is there some defined way to handle this I just was unable to find?

Thank you!
/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] GLEP 55 Version 2

[Michael Haubenwallner]

On Sat, 2009-06-06 at 23:31 +0100, Roy Bamford wrote:

> I've spent some time reading all of this years emails on GLEP55 and 
> added a few lines to version 1.5 which is the last offical version.

Is there a specific reason not to include the "inherit eapi"[1][2]
thing?

IMHO this would fit best in "Abstract Solution (Part 1)" somehow like:

-There are two potential solutions to this part of the problem,
+There are three potential solutions to this part of the
problem,

* wait for old package managers to fall into disuse
* 'blind' old package managers to ebuilds using later
constructs
+   * use "inherit" to have old package managers almost silently
+ ignore unsupported ebuilds

[1] 
http://archives.gentoo.org/gentoo-dev/msg_b2656aca1d124658b3df73d3d6804b7e.xml
[2] 
http://archives.gentoo.org/gentoo-dev/msg_348f84690f03e597fb14d6602337c45f.xml

Thanks!

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] A new glep: Ebuild format and metadata handling

[Michael Haubenwallner]

On Sun, 2009-05-31 at 15:56 +0200, Patrick Lauer wrote:

Thank you for collecting this up!

> parsers: The current practise of putting the eapi definition near the top of
> the ebuild, combined with the need to state it for all non-EAPI0 ebuilds,
> suggests that it can be parsed without having to source the ebuild.

Would it improve parsers' performance to explicitly define EAPI="0" in
EAPI0 ebuilds too, so it always can find an EAPI value?

> "haubi"
> He proposes to use an eapi.eclass and define eapi as a function.

Erm, unlike earlier I did not propose eapi as a function this time.

Instead, my proposal is identical to the "parsers" one, but with a
backwards compatible syntax for defining the EAPI value that allows to
have non-parsing PMs (nearly) silently ignore the ebuild, so we do not
have to wait another extended period (=year) to put "parsed" EAPI values
in the tree after a "parsing" PM became stable.

This backwards compatibility syntax is done with the eapi.eclass, which
does nothing but early exit when inherit'ed by an old (=non-parsing) PM.

It is up to the "parsing" PM (the PMS) if 'eapi.eclass' actually gets
read in, as the implementation of 'inherit' is part of the PM and has to
detect "eapi" as special argument anyway, otherways it would fail to
find "4.eclass" when used this way:
>inherit eapi 4

But I can also think of this syntax:
  EAPI="4"# parsers read this line only
  inherit eapi# compat for non-parsing PM only

Here the 'inherit eapi' line can be dropped as soon as we do not need to
support non-parsing PMs any more. However, parsing PMs either need to
ignore "eapi" as argument to 'inherit', or need to inform eapi.eclass
somehow that the EAPI was parsed already.
There might be a better name than 'eapi.eclass' here. With
'eapicompat.eclass' fex this would read:
   EAPI="4"
   inherit eapicompat

Thanks!

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Re: GLEP 55: another approach: display pretty messages with old PMs

[Michael Haubenwallner]

On Fri, 2009-05-29 at 10:42 +, Duncan wrote:
> Michael Haubenwallner  posted on  Fri, 29
> May 2009 10:14:46 +0200:
> 
> > Ohw, the latter would be necessary here, or '4.ebuild' would not be
> > found.
> 
> s/4.ebuild/4.eclass/ I assume.

Indeed.

> Except...  since an ebuild must presently be sourced to (properly) 
> determine EAPI, it still doesn't work for changes that break sourcing or 
> other pre-EAPI processing (like parsing PN and PVR out of the filename), 
> so the changes allowed with a simple EAPI change are still rather limited.

As long as the *whole* ebuild content (including the filename) needs to
be successfully interpreted just for EAPI detection, we will have to
change the extension or wait the extended period for each incompatible
EAPI change. So this full interpretation for EAPI detection doesn't feel
like a good way to go at all.

> That's why the change to GLEP55 or alternative, whether in-filename or
> in-file-itself, will again require either an extended wait after 
> introduction (the old way) or at minimum, a one-time change to extension 
> such that old PM versions don't even see the currently EAPI incompatible 
> changes.

Wouldn't it be possible to avoid both the extension change and another
extended wait period for new incompatible(*) EAPIs, when we do this
early and silent exit hack for unsupported ebuilds with old PMs that
still do full interpretation for EAPI detection?

And after another extended wait period(**), we can start dropping the
silent exit hack, so we finally have switched to EAPI detection without
full interpretation, but still have the .ebuild extension.

(*) The incompatibility of EAPIs must not begin (meaning the bytewise
ebuild content) before the end of both the ebuild's EAPI value
definition and the silent exit hack.
But this IMO is an acceptable compromise.

(**) After this wait period, the incompatibility of EAPIs can start
after the end of the ebuild's EAPI value definition.

Thanks!

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

[gentoo-dev] Re: GLEP 55: another approach: display pretty messages with old PMs

[Michael Haubenwallner]

On Thu, 2009-05-28 at 19:17 +0200, Michael Haubenwallner wrote:

> inherit eapi 4
> 
> Now when the PM is capable of pre-source EAPI detection, it will set
> EAPI before sourcing, eapi.eclass can see EAPI already being set and not
> do the 'exit' in global scope. Or even the PM's inherit-implementation
> expects to be first called with arguments "eapi 4", and not reading the
> eapi.eclass at all, so the 'eapi.eclass' does not need to check for
> anything, just needs to 'exit' when inherited.

Ohw, the latter would be necessary here, or '4.ebuild' would not be
found.

eapi.eclass could also be renamed to sth. like eapisupport.eclass or
eapivalidation.eclass, to write this way:
EAPI="4"
inherit eapisupport
But then the eclass has to detect which EAPI's are supported by the
running PM to 'exit' upon an unsupported one.

Btw.: What do non-EAPI-aware PMs do with ebuilds using EAPI 1 and 2 -
how become they masked _now_? What did I miss here?

Thanks!

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

[gentoo-dev] GLEP 55: another approach: display pretty messages with old PMs

[Michael Haubenwallner]

loads: 0 kB

This is: one additional nice line for each unsupported ebuild, except
for the version format change, which shows 'Invalid ebuild name'.

But how many such new version formats will exist while there are no
other ebuilds with unsupported eapi but compatible version format, and
how long do we really plan to support PMs not pre-source reading the
eapi?

When there is no supported ebuild available, this would look like:

$ ACCEPT_KEYWORDS='~x86' emerge -1pv '>net-misc/mico-2.3.13'

These are the packages that would be merged, in order:

Calculating dependencies |
Invalid ebuild name: /usr/portage/net-misc/mico/mico-2.3.13_live.ebuild
 * Need >=sys-apps/portage-2.3 to support net-misc/mico-2.3.13-r3.
 * Need >=sys-apps/portage-2.3 to support net-misc/mico-2.3.13-r2.
 * Need >=sys-apps/portage-2.3 to support net-misc/mico-2.3.13-r1.  

... 
done!

!!! All ebuilds that could satisfy ">net-misc/mico-2.3.13" have been 
masked.
!!! One of the following masked packages is required to complete your 
request:
- net-misc/mico-2.3.13-r3 (masked by: corruption)
- net-misc/mico-2.3.13-r2 (masked by: corruption)
    - net-misc/mico-2.3.13-r1 (masked by: corruption)

For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.

my 2ct...

Thanks!

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level
# Copyright 1999-2009 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

#
# Original Author: Michael Haubenwallner 
# Purpose: Inform the user that another version of the PM is required to
# support this ebuild.
#

if [[ ${EAPI+set} != 'set' ]]; then
if [[ ${PR:-r0} == 'r0' ]]; then
ewarn "Need >=sys-apps/portage-2.3 to support ${CATEGORY}/${P}."
else
ewarn "Need >=sys-apps/portage-2.3 to support 
${CATEGORY}/${P}-${PR}."
fi
exit 0
fi

Re: [gentoo-dev] Google SoC @ Gentoo - Universal Select Tool

[Michael Haubenwallner]

On Wed, 2009-05-13 at 16:40 +0100, Sérgio Almeida wrote:

> > This .uselect 
> > should not contain symlinks, but plain (text?) files only.

> Do we really need more than one file? 

No, at least not to define the _values_ of a profile.

> Checklist:
> * Hostname
> * Uname
> * {$chost}
> 
> Mmm... Maybe we can simplify this with a parameter like:
> 
> # eval something
> eval "hostname" "superhost"
> what
> to
> do
> # end something
> 
> Then if command "hostname" outputs "superhost" we know "what-to-do". 

Eventually, we should pass something like "-Dhostname=superhost" as
cmdline parameter to uselect...

> 
> This way it would get ultra versatile.
> 
> > What if there is some hierarchy in .uselect/ much like the profiles in
> > gentoo-x86 tree, using some kind of 'parent' files to inherit/override
> > settings for this one project, where 'parent' can contain something like
> > $(CHOST), $(UNAME), $(HOSTNAME), $(USERNAME)?
> > 
> 
> Would this really be necessary? We can define hierarchy into a
> single .uselect file. Even the use of folders (folder .uselect/) isn't
> necessary. I think a single file can handle all this... 

Eventually yes.

> Lets see an
> example:
> 
> # profile something

I don't like to have anything interpreted after the usual and well-known
comment-marker, this just feels hackish.

> 
> do this 3 <- override the overridden =)

> The actions to be done like "do this 3" are a simple call to uselect
> using module "do" and action "this" with "3" as parameters.

fine.

I do have something like this content-syntax in mind for .uselect (or
eventually some .uprofile) file:

8<8<8<
version "0.1"

include "path/to/another/uselect/file"

profile "generic solaris" {
  module A actionAX "valueAX1" "valueAX2"
  module B actionBX "valueBX1" "valueBX2
}

profile "generic host" {
  module C actionCX "valueCX1"
}

profile "superhost" {
  inherit profile "generic solaris"
  inherit profile "generic host"
  module C actionCX "newvalueCX1"
  module A actionAX "newvalueAX1" "newvalueAX2"
  module D actionDY "valueBY1" "valueBY2"
}

profile "generic user" {
  module E actionEX "valueEX1"
}

profile "user haubi" {
  inherit profile "generic user"
  module F actionFX "valueFX1"
}

profile "any user on superhost" {
  module G actionGX "valueGX1"
}

profile "fallback host" {
  inherit profile "generic host"
  module A actionAX "valueAX1" "valueAX2"
}

activation "superhost activation" {
  in category "host"
  on fallback level 0
  when $hostname matches string "superhost"
  activate profile "superhost"
}

activation "haubi on superhost" {
  in category "user"
  on fallback level 0
  when $username matches string "haubi"
  when $hostname matches string "superhost"
  activate profile "any user on superhost"
  activate profile "user haubi"
}

activation "haubi" {
  in category "user"
  on fallback level 1
  when $username matches string "haubi"
  activate profile "user haubi"
}

activation "gentoo host" {
  in category "host"
  on fallback level 1
  when $hostname matches regex ".*\.gentoo\.org"
  activate profile "fallback host"
}
>8>8>8

I'm not sure to have an ascending "fallback level" or descending
"priority" value, but both should allow for negative integer values.

The selection of one or more profiles is controlled by "activation"
entries, independent for each "category". The order and selection of
categories is done via a commandline argument, fex "--categories".

Profiles are selected when all of the "when" entries (besides "category"
and "fallback level") in "activation {}" do match.
Selected are *all* of the matching profiles in the *lowest* "fallback
level" *only*, which does have at least one matching profile.

And I'm thinking of something like this commandline:
$ uselect \
  --categories host,user \
  --define hostname=`hostname` \
  --define username=`whoami`

> 
> Remember that profile creation/storing/managing should be automatic and
> nothing would need to be written by hand.

Yes, would be fine. When using something like above configuration file
syntax, some GUIding tool would be useful, at least to see which
profiles are selected for specific cmdline args.

>  By other words, create a basic
> profile automatically using your currently running settings and then
> alter the profile with the util to add constrains to it.

Sounds interesting...

> Remember that
> all the machines that this profile is read would need to have the same
> uselect modules into it's /usr/share/uselect/modules or similar.

Indeed, yes.

> > Ha! This kind of inheritance tree could be a solution for my long
> > standing bug here to simplify our way too complex environment script...
> > 
> 
> This is a basic idea from softenv so it has has it's place into uselect.

Don't know softenv. Found http://www.teragrid.org/userinfo/softenv/
Do you mean this one?

> The question now is, bloat it all into uselect or create a uprofile
> util? I like the idea of having to use only uselect for basic profiling
> and using uprofile for