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

2021-04-23 Thread 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

2021-02-15 Thread 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

2020-03-13 Thread 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+

2020-03-13 Thread 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

2019-11-05 Thread 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

2019-09-09 Thread 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

2019-08-08 Thread 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

2019-07-31 Thread 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

2019-06-13 Thread 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

2019-06-13 Thread 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

2019-06-03 Thread 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

2019-05-29 Thread 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

2019-05-29 Thread 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

2019-03-25 Thread 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?

2018-10-17 Thread 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?

2018-10-15 Thread 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

2018-07-09 Thread 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

2018-06-22 Thread 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

2018-06-22 Thread 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

2018-06-22 Thread 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

2018-06-22 Thread 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

2018-06-22 Thread 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

2018-06-22 Thread 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 

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

2018-06-22 Thread 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

2018-06-22 Thread 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

2018-06-22 Thread 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

2018-06-21 Thread 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

2018-06-20 Thread 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

2018-06-20 Thread 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

2018-06-20 Thread 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

2018-06-20 Thread 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

2018-06-20 Thread 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

2018-06-20 Thread 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

2018-06-05 Thread 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

2018-06-04 Thread 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

2018-05-30 Thread 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-portage-dev] Re: [PATCH v2 3/3] _emerge.Ebuild*: delay creating DISTDIR shadow until src_unpack

2018-01-29 Thread Michael Haubenwallner
On 01/25/2018 10:11 AM, Michał Górny wrote:
> W dniu czw, 25.01.2018 o godzinie 10∶07 +0100, użytkownik Michael
> Haubenwallner napisał:
>> Hi,
>>
>> ${Subject} ringing a bell here:
>>
>> dev-db/oracle-instantclient is fetch restricted. As a binary package with
>> multiple USE options there's a bunch of files to download - even for
>> multiple archs when multilib is active.
>>
>> So in pkg_nofetch() I'm telling the user whether a file to download is
>> "already here" or "still absent", by testing if $A exists in $DISTDIR.
>>
>> With ${Subject}, I'm wondering if DISTDIR is created for pkg_nofetch too.
>>
>
> You're doing the wrong thing then. DISTDIR is not allowed
> in pkg_nofetch().

Is there a supported way to tell the user exactly which files are still missing?

> Furthermore, you're touching files whose hashes have
> not been verified which is twice wrong.

Well - does portage actually provide unverified files in the shadow DISTDIR?

Thanks!
/haubi/



[gentoo-portage-dev] Re: [PATCH v2 3/3] _emerge.Ebuild*: delay creating DISTDIR shadow until src_unpack

2018-01-25 Thread Michael Haubenwallner
Hi,

${Subject} ringing a bell here:

dev-db/oracle-instantclient is fetch restricted. As a binary package with
multiple USE options there's a bunch of files to download - even for
multiple archs when multilib is active.

So in pkg_nofetch() I'm telling the user whether a file to download is
"already here" or "still absent", by testing if $A exists in $DISTDIR.

With ${Subject}, I'm wondering if DISTDIR is created for pkg_nofetch too.

/haubi/

On 01/25/2018 09:50 AM, Michał Górny wrote:
> ---
>  pym/_emerge/EbuildExecuter.py | 4 
>  pym/_emerge/EbuildPhase.py| 6 --
>  2 files changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/pym/_emerge/EbuildExecuter.py b/pym/_emerge/EbuildExecuter.py
> index ab79ce901..d387b42be 100644
> --- a/pym/_emerge/EbuildExecuter.py
> +++ b/pym/_emerge/EbuildExecuter.py
> @@ -8,7 +8,6 @@ import portage
>  from portage import os
>  from portage.eapi import eapi_has_src_prepare_and_src_configure, \
>   eapi_exports_replace_vars
> -from portage.package.ebuild.prepare_build_dirs import _prepare_fake_distdir
>  
>  class EbuildExecuter(CompositeTask):
>  
> @@ -25,9 +24,6 @@ class EbuildExecuter(CompositeTask):
>   cleanup = 0
>   portage.prepare_build_dirs(pkg.root, settings, cleanup)
>  
> - alist = settings.configdict["pkg"].get("A", "").split()
> - _prepare_fake_distdir(settings, alist)
> -
>   if eapi_exports_replace_vars(settings['EAPI']):
>   vardb = pkg.root_config.trees['vartree'].dbapi
>   settings["REPLACING_VERSIONS"] = " ".join(
> diff --git a/pym/_emerge/EbuildPhase.py b/pym/_emerge/EbuildPhase.py
> index aa3a66831..d3fada622 100644
> --- a/pym/_emerge/EbuildPhase.py
> +++ b/pym/_emerge/EbuildPhase.py
> @@ -1,4 +1,4 @@
> -# Copyright 1999-2013 Gentoo Foundation
> +# Copyright 1999-2018 Gentoo Foundation
>  # Distributed under the terms of the GNU General Public License v2
>  
>  import gzip
> @@ -12,7 +12,7 @@ from _emerge.MiscFunctionsProcess import 
> MiscFunctionsProcess
>  from _emerge.EbuildProcess import EbuildProcess
>  from _emerge.CompositeTask import CompositeTask
>  from portage.package.ebuild.prepare_build_dirs import (_prepare_workdir,
> - _prepare_fake_filesdir)
> + _prepare_fake_distdir, _prepare_fake_filesdir)
>  from portage.util import writemsg
>  
>  try:
> @@ -171,6 +171,8 @@ class EbuildPhase(CompositeTask):
>   def _start_ebuild(self):
>  
>   if self.phase == "unpack":
> + alist = self.settings.configdict["pkg"].get("A", 
> "").split()
> + _prepare_fake_distdir(self.settings, alist)
>   _prepare_fake_filesdir(self.settings)
>  
>   fd_pipes = self.fd_pipes
> 




[gentoo-dev] Re: Open Build Service

2017-11-14 Thread 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

2017-09-29 Thread 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
>>>> <hanet...@startmail.com> 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

2017-09-29 Thread 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

2017-05-22 Thread 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

2017-03-02 Thread 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 <ha...@gentoo.org>
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 <ha...@gentoo.org>
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

2017-03-02 Thread 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

2017-01-26 Thread 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

2017-01-13 Thread 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 <michael.haubenwall...@ssi-schaefer.com>
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

2016-08-24 Thread 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

2016-04-21 Thread 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?

2015-10-27 Thread 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-portage-dev] [PATCH] unpack: avoid useless chmods to improve speed

2015-07-07 Thread Michael Haubenwallner
X-Gentoo-Bug: 554084
X-Gentoo-Bug-url: https://bugs.gentoo.org/show_bug.cgi?id=554084
---
 bin/phase-helpers.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bin/phase-helpers.sh b/bin/phase-helpers.sh
index efd2cfa..b446060 100644
--- a/bin/phase-helpers.sh
+++ b/bin/phase-helpers.sh
@@ -531,8 +531,8 @@ unpack() {
done
# Do not chmod '.' since it's probably ${WORKDIR} and 
PORTAGE_WORKDIR_MODE
# should be preserved.
-   find . -mindepth 1 -maxdepth 1 ! -type l -print0 | \
-   ${XARGS} -0 chmod -fR a+rX,u+w,g-w,o-w
+   find . -mindepth 1 '!' -type l '!' -perm /a+rX,u+w,g-w,o-w \
+   -exec chmod -f a+rX,u+w,g-w,o-w '{}' +
 }
 
 econf() {
-- 
2.0.5




[gentoo-portage-dev] [PATCH] unpack: avoid useless chmods to improve speed

2015-07-07 Thread Michael Haubenwallner
X-Gentoo-Bug: 554084
X-Gentoo-Bug-url: https://bugs.gentoo.org/show_bug.cgi?id=554084
---
 bin/phase-helpers.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bin/phase-helpers.sh b/bin/phase-helpers.sh
index efd2cfa..bf3ae1f 100644
--- a/bin/phase-helpers.sh
+++ b/bin/phase-helpers.sh
@@ -531,8 +531,8 @@ unpack() {
done
# Do not chmod '.' since it's probably ${WORKDIR} and 
PORTAGE_WORKDIR_MODE
# should be preserved.
-   find . -mindepth 1 -maxdepth 1 ! -type l -print0 | \
-   ${XARGS} -0 chmod -fR a+rX,u+w,g-w,o-w
+   find . -mindepth 1 '!' -type l '!' -perm /a+rX,u+w,g-w,o-w -print0 | \
+   ${XARGS} -0 chmod -f a+rX,u+w,g-w,o-w
 }
 
 econf() {
-- 
2.0.5




[gentoo-portage-dev] Re: [PATCH] Make the USE variable readonly (bug 325009)

2015-06-23 Thread Michael Haubenwallner
On 04/26/2015 11:14 PM, Zac Medico wrote:
 This requires the EBUILD_FORCE_TEST code from dyn_test to execute
 before USE is declared readonly.
 
 X-Gentoo-Bug: 325009
 X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=325009
 ---

 --- a/bin/ebuild.sh
 +++ b/bin/ebuild.sh
 @@ -1,5 +1,5 @@
 + declare -r USE

This breaks the 'ebuildshell' feature patch,
https://bugs.gentoo.org/show_bug.cgi?id=155161

Shouldn't USE show up in PORTAGE_READONLY_VARS as well?

/haubi/



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

2015-03-17 Thread 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: Naming of repositories: gento-x86 edition, bike shedding wanted

2015-03-17 Thread 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] Re: toolchain.eclass: need to revert fixincludes commit

2015-02-04 Thread 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.647r2=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

2014-07-31 Thread 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

2014-07-30 Thread 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-portage-dev] support multiple eclass variants (aka unstable eclasses)

2014-07-14 Thread Michael Haubenwallner

On 07/08/2014 07:11 PM, Sebastian Luther wrote:
 Am 08.07.2014 18:58, schrieb Michael Haubenwallner:
 Hello fellow Portage developers,

 attached portage patch draft aims to allow for easy distributing eclasses to 
 be tested by
 multiple tinderboxes on various architectures, without being active for 
 normal installs.
 
 What does the patch allow you to do, that you can't do right now? (i.e.
 put an eclass with the same name in an repository and use
 eclass-overrides to force its use in another repo?)

Is there an easy way to use the eclasses from the overriding tree, but not the 
(usually newer)
ebuilds from there - such as 'configure but disable repo (except for use in 
eclass-override)'?

Thanks!
/haubi/



[gentoo-portage-dev] support multiple eclass variants (aka unstable eclasses)

2014-07-08 Thread Michael Haubenwallner
Hello fellow Portage developers,

attached portage patch draft aims to allow for easy distributing eclasses to be 
tested by
multiple tinderboxes on various architectures, without being active for normal 
installs.

Usage is to have in make.conf (or profile): PORTAGE_ECLASS_VARIANTS=testing
and for the eclass: to live in tree-or-overlay/eclass/testing/

Thoughts? (even for var-naming, manpage yes/no/wording, ...)

Thank you!
/haubi/
From 2ddc1db0f1c15873e2476fbf5ba0352464c8725a Mon Sep 17 00:00:00 2001
From: Michael Haubenwallner ha...@gentoo.org
Date: Tue, 8 Jul 2014 17:48:54 +0200
Subject: [PATCH] support PORTAGE_ECLASS_VARIANTS

---
 bin/ebuild.sh | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/bin/ebuild.sh b/bin/ebuild.sh
index be044e0..366cab6 100755
--- a/bin/ebuild.sh
+++ b/bin/ebuild.sh
@@ -246,12 +246,14 @@ inherit() {
 		fi
 
 		for repo_location in ${PORTAGE_ECLASS_LOCATIONS[@]}; do
-			potential_location=${repo_location}/eclass/${1}.eclass
+		  for x in ${PORTAGE_ECLASS_VARIANTS:-} ''; do
+			potential_location=${repo_location}/eclass${x:+/}${x}/${1}.eclass
 			if [[ -f ${potential_location} ]]; then
 location=${potential_location}
 debug-print   eclass exists: ${location}
-break
+break 2
 			fi
+		  done
 		done
 		debug-print inherit: $1 - $location
 		[[ -z ${location} ]]  die ${1}.eclass could not be found by inherit()
-- 
1.8.3.2



Re: [gentoo-portage-dev] support multiple eclass variants (aka unstable eclasses)

2014-07-08 Thread Michael Haubenwallner

Am 2014-07-08 19:11, schrieb Sebastian Luther:
 Am 08.07.2014 18:58, schrieb Michael Haubenwallner:
 Hello fellow Portage developers,

 attached portage patch draft aims to allow for easy distributing eclasses to 
 be tested by
 multiple tinderboxes on various architectures, without being active for 
 normal installs.
 
 What does the patch allow you to do, that you can't do right now? (i.e.
 put an eclass with the same name in an repository and use
 eclass-overrides to force its use in another repo?)

Ohw, haven't been aware of that - will try first.

Thanks!
/haubi/



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

2014-07-03 Thread 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/



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

2013-11-22 Thread 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

2013-11-15 Thread 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
;;
-   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

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

2013-11-13 Thread 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
-   ELT_walk_patches 
${d}/../configure ${p}
- 

Re: [gentoo-dev] Automagic pax-mark

2013-04-08 Thread 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
 chith...@gentoo.org 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)

2013-01-24 Thread 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] news item for udev 197-r3 upgrade (yes, I know, it's late)

2013-01-24 Thread 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] Proposal to end-of-life tree-clean old profiles/updates/ files

2012-12-10 Thread 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-portage-dev] [RFC/PATCH] prepstrip/ecompressdir: parallelize operations

2012-05-14 Thread Michael Haubenwallner


On 05/11/2012 06:39 PM, Mike Frysinger wrote:
 +multijob_child_init() {
 + trap 'echo ${BASHPID} $? '${mj_control_fd} EXIT
 + trap 'exit 1' INT TERM
 +}

Just wondering why $! in parent isn't used anywhere, even not for some
integrity check if the child's BASHPID actually was forked by parent.

 +multijob_post_fork() {
 + : $(( ++mj_num_jobs ))
 + if [[ ${mj_num_jobs} -ge ${mj_max_jobs} ]] ; then
 + multijob_finish_one

Feels like ignoring this child's exitstatus isn't intentional here.

 + fi
 + return 0
 +}

/haubi/



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

2012-04-27 Thread 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

2012-04-16 Thread 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

2012-02-09 Thread 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

2011-11-03 Thread 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, ...?

opinion

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.

/opinion

/haubi/




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

2011-10-27 Thread 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

2011-10-14 Thread 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} $@
 
snip
 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] new helper: econf_build

2011-10-14 Thread 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} $@

 snip

 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] rfc: deprecation of baselayout-1.x

2011-07-01 Thread Michael Haubenwallner

On 07/01/11 07:56, Nirbheek Chauhan wrote:
 On Fri, Jul 1, 2011 at 11:03 AM, Dale rdalek1...@gmail.com 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



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

2011-05-25 Thread 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.1view=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: How do you perform patchset versioning?

2011-05-25 Thread 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



Re: [gentoo-portage-dev] EbuildProcess logs poll-error to already removed $T (on AIX)

2011-03-28 Thread Michael Haubenwallner


On 03/25/2011 05:23 PM, Zac Medico wrote:
  * EbuildProcess received strange poll event: 16384

 You can compare 16384 to the values of POLLERR and POLLNVAL in order to
 see what type of event it is. Apparently the values on AIX are different
 from those on Linux, because here's what I see on Linux:

On AIX 5.3 this is:

Python 2.7.1 (r271:86832, Feb 28 2011, 17:51:02) 
[GCC 4.2.4 (Gentoo 4.2.4-r01.2 p1.1)] on aix5
Type help, copyright, credits or license for more information.
 import select
 dir(select)
['PIPE_BUF', 'POLLERR', 'POLLHUP', 'POLLIN', 'POLLMSG', 'POLLNVAL', 'POLLOUT',
'POLLPRI', 'POLLRDBAND', 'POLLRDNORM', 'POLLWRBAND', 'POLLWRNORM', '__doc__',
'__file__', '__name__', '__package__', 'error', 'poll', 'select']
 select.POLLNVAL
32768
 select.POLLERR
16384

On AIX 6.1 it looks similar except for missing 'PIPE_BUF'.

 This will handle the IOError:
 http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=0a64f784003c11e151405b7f708d0de0ed57

Yes, that makes it work, thank you!

 It might be risky to skip logging of the POLLNVAL / POLLERR events, so
 hopefully we can determine their cause and handle them somehow. Do they
 seem to cause any problems? It might be something specific about pty
 devices on AIX.

There doesn't seem to go anything wrong so far.

I've no idea about programming with pty devices at all.
However, one relevant (IMHO) thing I can see is:
portage/util/_pty.py:_can_test_pty_eof() returns True for Linux only.

Anything I can try out?

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



[gentoo-portage-dev] EbuildProcess logs poll-error to already removed $T (on AIX)

2011-03-25 Thread Michael Haubenwallner
Hi Zac (et al),

while this problem occurs on AIX only (for now?), I doubt this problem is
introduced in prefix-portage.

With recent prefix-portage-2.2.01.18125 (Fabian, how do you calculate the
version numbers since moving to git?), the EbuildProcess spits this
every now and then during emerge mime-types fex:

 * EbuildProcess received strange poll event: 16384

While I don't understand (yet) why this is there on AIX at all, it does
trigger an IOError when trying to log this message to $T/build.log after
$WORKDIR has been cleaned up. When I avoid the logging of this message,
everything (seems to) work fine.

For the attached logfile, I've added these two lines to 
usr/lib/portage/bin/ebuild.sh:
@@ -1,3 +1,5 @@
 #!/big5tk/local/gprefix/bin/bash
 # Copyright 1999-2011 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
+echo ebuild.sh: $0 $@ 2
+echo ebuild.sh: WORKDIR: ${WORKDIR} 2
@@

Any idea?

Thank you!
/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level
WARNING: One or more repositories have missing repo_name entries:

/big5tk/local/prefix-overlay/profiles/repo_name
/big5tk/local/gentoo-x86/profiles/repo_name

NOTE: Each repo_name entry should be a plain text file containing a
unique name for the repository on the first line.



 * IMPORTANT: 1 news items need reading for repository 'gentoo_prefix'.
 * Use eselect news to read news items.

Calculating dependencies  ... done!

 Verifying ebuild manifests

 Emerging (1 of 1) app-misc/mime-types-8
ebuild.sh: /big5tk/local/gprefix/usr/lib/portage/bin/ebuild.sh clean
ebuild.sh: WORKDIR: /big5tk/tmp/gprefix/portage/app-misc/mime-types-8/work
 * EbuildProcess received strange poll event: 16384

 * mime-types-8.tar.bz2 RMD160 SHA1 SHA256 size ;-) ...  [ ok ]
 * Package:app-misc/mime-types-8
 * Repository: gentoo_prefix
 * Maintainer: d...@gentoo.org net-m...@gentoo.org
 * USE:elibc_AIX kernel_AIX ppc-aix prefix userland_GNU
 * FEATURES:   nostrip preserve-libs
ebuild.sh: /big5tk/local/gprefix/usr/lib/portage/bin/ebuild.sh setup
ebuild.sh: WORKDIR: /big5tk/tmp/gprefix/portage/app-misc/mime-types-8/work
 * EbuildProcess received strange poll event: 16384

ebuild.sh: /big5tk/local/gprefix/usr/lib/portage/bin/ebuild.sh unpack
ebuild.sh: WORKDIR: /big5tk/tmp/gprefix/portage/app-misc/mime-types-8/work
 Unpacking source...
 Unpacking mime-types-8.tar.bz2 to 
 /big5tk/tmp/gprefix/portage/app-misc/mime-types-8/work
 Source unpacked in /big5tk/tmp/gprefix/portage/app-misc/mime-types-8/work
 * EbuildProcess received strange poll event: 16384

ebuild.sh: /big5tk/local/gprefix/usr/lib/portage/bin/ebuild.sh compile
ebuild.sh: WORKDIR: /big5tk/tmp/gprefix/portage/app-misc/mime-types-8/work
 Compiling source in 
 /big5tk/tmp/gprefix/portage/app-misc/mime-types-8/work/mime-types-8 ...
 Source compiled.
 * EbuildProcess received strange poll event: 16384

ebuild.sh: /big5tk/local/gprefix/usr/lib/portage/bin/ebuild.sh test
ebuild.sh: WORKDIR: /big5tk/tmp/gprefix/portage/app-misc/mime-types-8/work
 Test phase [not enabled]: app-misc/mime-types-8
 * EbuildProcess received strange poll event: 16384

ebuild.sh: /big5tk/local/gprefix/usr/lib/portage/bin/ebuild.sh install
ebuild.sh: WORKDIR: /big5tk/tmp/gprefix/portage/app-misc/mime-types-8/work

 Install mime-types-8 into 
 /big5tk/tmp/gprefix/portage/app-misc/mime-types-8/image/big5tk/local/gprefix/
  category app-misc
 Completed installing mime-types-8 into 
 /big5tk/tmp/gprefix/portage/app-misc/mime-types-8/image/big5tk/local/gprefix/

 * EbuildProcess received strange poll event: 16384

ebuild.sh: /big5tk/local/gprefix/usr/lib/portage/bin/misc-functions.sh 
ebuild.sh: WORKDIR: /big5tk/tmp/gprefix/portage/app-misc/mime-types-8/work
 * MiscFunctionsProcess received strange poll event: 16384


 Installing (1 of 1) app-misc/mime-types-8
ebuild.sh: /big5tk/local/gprefix/usr/lib/portage/bin/ebuild.sh preinst
ebuild.sh: WORKDIR: /big5tk/tmp/gprefix/portage/app-misc/mime-types-8/work
 * EbuildProcess received strange poll event: 16384

ebuild.sh: /big5tk/local/gprefix/usr/lib/portage/bin/misc-functions.sh 
ebuild.sh: WORKDIR: /big5tk/tmp/gprefix/portage/app-misc/mime-types-8/work
 * MiscFunctionsProcess received strange poll event: 16384

ebuild.sh: /big5tk/local/gprefix/usr/lib/portage/bin/ebuild.sh prerm
ebuild.sh: WORKDIR: 
/big5tk/tmp/gprefix/portage/._unmerge_/app-misc/mime-types-8/work
 * EbuildProcess received strange poll event: 16384

ebuild.sh: /big5tk/local/gprefix/usr/lib/portage/bin/ebuild.sh postrm
ebuild.sh: WORKDIR: 
/big5tk/tmp/gprefix/portage/._unmerge_/app-misc/mime-types-8/work
 * EbuildProcess received strange poll event: 16384

ebuild.sh: /big5tk/local/gprefix/usr/lib/portage/bin/ebuild.sh clean
ebuild.sh: WORKDIR: 
/big5tk/tmp/gprefix/portage/._unmerge_/app-misc/mime-types-8/work
 * EbuildProcess received strange poll event: 16384


 * Messages for package app-misc/mime-types-8:
 * EbuildProcess received strange poll event

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

2011-02-16 Thread 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] Downgrading glibc?

2011-02-11 Thread 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] Re: Downgrading glibc?

2011-02-11 Thread 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] libpng-1.5 smooth upgrade

2011-02-11 Thread 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-portage-dev] portage's lafilefixer has problems with readonly la files

2010-12-22 Thread Michael Haubenwallner


On 12/20/10 14:52, Zac Medico wrote:
 On 12/20/2010 04:21 AM, Michael Haubenwallner wrote:
 Thing is that portage rewrites fixed content to potentially readonly lafiles.
 
 Hopefully this will fix it:
 
 http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=f991bb526d50c363dd0743955cb463f7ecb135cb

Yep, seems to work, thanks!
/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level



[gentoo-portage-dev] portage's lafilefixer has problems with readonly la files

2010-12-20 Thread Michael Haubenwallner
Hi,

looking at portage.git master this doesn't look like a prefix only problem:

After upgrading to prefix-portage-2.2.01.17380 in prefix-launcher I'm
encountering this backtrace, due to some lib.la being readonly here on
hppa-hpux with older libtool. This basically is a problem with either
libtool and/or the build-system, but it shouldn't break portage IMO.

Thing is that portage rewrites fixed content to potentially readonly lafiles.

/haubi/

Traceback (most recent call last):
  File /prefix-launcher/inst/bin/emerge, line 44, in module
retval = emerge_main()
  File /prefix-launcher/inst/lib/portage/pym/_emerge/main.py, line 1701, in 
emerge_main
myopts, myaction, myfiles, spinner)
  File /prefix-launcher/inst/lib/portage/pym/_emerge/actions.py, line 443, in 
action_build
retval = mergetask.merge()
  File /prefix-launcher/inst/lib/portage/pym/_emerge/Scheduler.py, line 1160, 
in merge
rval = self._merge()
  File /prefix-launcher/inst/lib/portage/pym/_emerge/Scheduler.py, line 1478, 
in _merge
self._main_loop()
  File /prefix-launcher/inst/lib/portage/pym/_emerge/Scheduler.py, line 1620, 
in _main_loop
self._poll_loop()
  File /prefix-launcher/inst/lib/portage/pym/_emerge/PollScheduler.py, line 
138, in _poll_loop
handler(f, event)
  File /prefix-launcher/inst/lib/portage/pym/_emerge/EbuildIpcDaemon.py, line 
82, in _input_handler
reply_hook()
  File 
/prefix-launcher/inst/lib/portage/pym/_emerge/AbstractEbuildProcess.py, line 
149, in _exit_command_callback
self.scheduler.schedule(self._reg_id, timeout=self._exit_timeout)
  File /prefix-launcher/inst/lib/portage/pym/_emerge/PollScheduler.py, line 
232, in _schedule_wait
handler(f, event)
  File /prefix-launcher/inst/lib/portage/pym/_emerge/SpawnProcess.py, line 
201, in _output_handler
self.wait()
  File /prefix-launcher/inst/lib/portage/pym/_emerge/AsynchronousTask.py, 
line 41, in wait
self._wait_hook()
  File /prefix-launcher/inst/lib/portage/pym/_emerge/AsynchronousTask.py, 
line 114, in _wait_hook
self._exit_listener_stack.pop()(self)
  File /prefix-launcher/inst/lib/portage/pym/_emerge/EbuildPhase.py, line 
153, in _ebuild_exit
_post_src_install_uid_fix(settings, out)
  File 
/prefix-launcher/inst/lib/portage/pym/portage/package/ebuild/doebuild.py, 
line 1501, in _post_src_install_uid_fix
mode='wb')
IOError: [Errno 13] Permission denied: 
'/toolsbase-2010.0/usr/lib/libncurses++.la'

-- 
Michael Haubenwallner
Gentoo on a different level



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

2010-10-04 Thread 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

2010-09-17 Thread 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

2010-03-01 Thread 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

2010-02-22 Thread 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] [RFC] New eclass for x11 packages

2010-02-22 Thread 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] Re: [rfc] layman storage location (again)

2010-01-18 Thread 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.
snip 
 /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

2009-10-27 Thread 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

2009-10-21 Thread 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

2009-10-20 Thread 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 libsobjects 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

2009-10-05 Thread 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

2009-07-27 Thread 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

2009-07-24 Thread 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] Re: Progress on Universal Select Tool

2009-07-16 Thread 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




  1   2   >