Re: [gentoo-dev] Re: [PMS] [PATCH] Correct the definition of ESYSROOT as EPREFIX isn't always applicable

2019-07-31 Thread Benda Xu
Hi James,

James Le Cuirot  writes:

>> > What if we want to bootstrap a brand new prefixed system using the
>> > crossdev system as SYSROOT? This is the distinct SYSROOT case. The
>> > problem is that there is no distinct variable for SYSROOT's prefix
>> > and, as already stated, ESYSROOT is always ${SYSROOT}${EPREFIX}. We
>> > therefore cannot do it! If the crossdev prefix is blank then ROOT's
>> > must be blank too.  
>> 
>> My question: is there a case when both SYSROOT and ESYSROOT are needed?
>> As far as I can see, SYSROOT is strictly build-time. Therefore setting
>> SYSROOT= would be enough for all.
>> 
>> Why did ESYSROOT exist in the first place?  Was it only for the sake of
>> symmetry, or did I miss something?
>
> Remember that we now install packages to SYSROOT too. Portage needs to
> know the prefix so that it can set EPREFIX when building these
> packages. You'll already know that you can't fake EPREFIX by setting
> ROOT. We could potentially work out EPREFIX by comparing SYSROOT with
> BROOT and EROOT (instead of / and ROOT) but that's not the whole story.
>
> When using crossdev, pkg-config files are sourced from SYSROOT. These
> may return paths like -L/myprefix/usr/lib. If SYSROOT!=/ then
> pkg-config will need to translate this to -L/myroot/myprefix/usr/lib.
> However, it's bad to explicitly add lib and include paths that the
> toolchain would look at anyway as it can change the search order. Under
> a regular setup, pkg-config would omit -L/usr/lib -I/usr/include but for
> this to work in the above setup, we need to know that /myprefix is a
> prefix. As stated, we don't have an explicit variable for SYSROOT's
> prefix but we can work it out using ${ESYSROOT#${SYSROOT}}. This is
> what I have done in my pending cross-pkg-config fixes.
>
> None of that magic happens when not using crossdev. I have debated
> whether it should but native builds with SYSROOT!=/ tend to be a
> disaster for various other reasons so perhaps it's not worth worrying
> about.
>
> There are probably more reasons when we need to know the prefix but I
> can't remember what they are now. :)

I could only remotely understand your argument.  But I feel you know
what you are doing.  So go ahead.

And please excuse me if I raise this again in the future.

>> In conclusion, IMHO, if SYSROOT can be overridden without restriction
>> ("distinct" in your email), we could cover all the use cases.
>
> It's still a little bit restricted but less than it was and the only
> cases we don't handle are obscure ones that we wouldn't want to support
> anyway.
>
> When dealing with this stuff, it's worth remembering that practically no
> one has used crossdev with prefix until recently. I know this because
> I had to fix the glibc ebuild, Portage, and crossdev itself to make it
> work following a bug report this month. ;)

That is an heroic effort.

I have tried to bring together crossdev and Prefix together in the past
but found too many obstacles to achieve it.

Thank you a million times!

Yours,
Benda


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: [PMS] [PATCH] Correct the definition of ESYSROOT as EPREFIX isn't always applicable

2019-07-31 Thread James Le Cuirot
On Tue, 30 Jul 2019 23:50:21 +0800
Benda Xu  wrote:

> > A check was added to Portage to ensure this held. Myself, the
> > ChromiumOS team, and others have since been caught out by this check
> > when trying to bootstrap brand new systems from scratch. You cannot
> > bootstrap with no headers at all! The check will therefore be adjusted
> > to merely ensure that SYSROOT is / when ROOT is /.  
> 
> It is very encouraging to see contributions from the ChromiumOS team to
> Gentoo!

Don't read too much into that. ;) I can't recall how I became aware of
it but I saw a patch that ChromiumOS had made against Portage to remove
the check I had added. No doubt it had caught them out in the same way.

> > What if we want to bootstrap a brand new prefixed system using the
> > crossdev system as SYSROOT? This is the distinct SYSROOT case. The
> > problem is that there is no distinct variable for SYSROOT's prefix
> > and, as already stated, ESYSROOT is always ${SYSROOT}${EPREFIX}. We
> > therefore cannot do it! If the crossdev prefix is blank then ROOT's
> > must be blank too.  
> 
> My question: is there a case when both SYSROOT and ESYSROOT are needed?
> As far as I can see, SYSROOT is strictly build-time. Therefore setting
> SYSROOT= would be enough for all.
> 
> Why did ESYSROOT exist in the first place?  Was it only for the sake of
> symmetry, or did I miss something?

Remember that we now install packages to SYSROOT too. Portage needs to
know the prefix so that it can set EPREFIX when building these
packages. You'll already know that you can't fake EPREFIX by setting
ROOT. We could potentially work out EPREFIX by comparing SYSROOT with
BROOT and EROOT (instead of / and ROOT) but that's not the whole story.

When using crossdev, pkg-config files are sourced from SYSROOT. These
may return paths like -L/myprefix/usr/lib. If SYSROOT!=/ then
pkg-config will need to translate this to -L/myroot/myprefix/usr/lib.
However, it's bad to explicitly add lib and include paths that the
toolchain would look at anyway as it can change the search order. Under
a regular setup, pkg-config would omit -L/usr/lib -I/usr/include but for
this to work in the above setup, we need to know that /myprefix is a
prefix. As stated, we don't have an explicit variable for SYSROOT's
prefix but we can work it out using ${ESYSROOT#${SYSROOT}}. This is
what I have done in my pending cross-pkg-config fixes.

None of that magic happens when not using crossdev. I have debated
whether it should but native builds with SYSROOT!=/ tend to be a
disaster for various other reasons so perhaps it's not worth worrying
about.

There are probably more reasons when we need to know the prefix but I
can't remember what they are now. :)

> In conclusion, IMHO, if SYSROOT can be overridden without restriction
> ("distinct" in your email), we could cover all the use cases.

It's still a little bit restricted but less than it was and the only
cases we don't handle are obscure ones that we wouldn't want to support
anyway.

When dealing with this stuff, it's worth remembering that practically no
one has used crossdev with prefix until recently. I know this because
I had to fix the glibc ebuild, Portage, and crossdev itself to make it
work following a bug report this month. ;)

Regards,
-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpLWWBo9OyxR.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PMS] [PATCH] Correct the definition of ESYSROOT as EPREFIX isn't always applicable

2019-07-31 Thread James Le Cuirot
On Wed, 31 Jul 2019 21:40:19 +0100
James Le Cuirot  wrote:

> So why does ROOT affect it? Normally you install the packages for
> BDEPEND, DEPEND, and RDEPEND to the same location. If BDEPEND and
> RDEPEND are installed to different locations (ROOT!=/) then DEPEND will
> almost always be installed to one of the other two. If either of those
> two locations is prefixed then we need the prefix for DEPEND's location
> to match, otherwise it wouldn't actually be the same location. Using
> ROOT allows us to figure this out automatically in a way that covers
> all sensible use cases and avoids accidentally falling into an
> unsupported case.

Just to clarify this in the binpkg case, here you would normally
install BDEPEND, DEPEND, and usually RDEPEND to / on your build
machine. On your other machines, you usually only care about RDEPEND.
If you care about BDEPEND and DEPEND too then you'll need to use the
same prefix everywhere but that's nothing new. You'd be pretty crazy to
use different prefixes in this kind of environment anyway.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpwVGu6zJELp.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PMS] [PATCH] Correct the definition of ESYSROOT as EPREFIX isn't always applicable

2019-07-31 Thread James Le Cuirot
On Wed, 31 Jul 2019 15:51:58 +0200
Alexis Ballier  wrote:

> On Tue, 30 Jul 2019 23:26:27 +0100
> James Le Cuirot  wrote:
> 
> > > Admittedly without a full understanding of the problem, but this
> > > looks wrong to me: SYSROOT, EPREFIX and BROOT are only relevant in
> > > build phases (src_*); (EPREFIX is a little special here but mostly
> > > for convenience). ROOT is only relevant in pkg_* phases. I don't
> > > see how this can work. Say I build a binpkg with ROOT=/ then use
> > > that binpkg with ROOT=/somewhere, you can't go back and change
> > > SYSROOT.  
> > 
> > ROOT is used to determine ESYSROOT, not the other way around. As you
> > say, (E)SYSROOT is only relevant in src phases so it doesn't matter if
> > ROOT has changed when installing a binpkg.  
> 
> I am missing something here: You are making ESYSROOT depend on the
> value of ROOT, so how can it not matter ?

What I am trying to say (somewhat unsuccessfully!) is that the value of
(E)SYSROOT only changes how the package is built, not what the
resulting package looks like. It's where all the headers and libraries
are sourced from at build time, which is irrelevant at runtime.

So why does ROOT affect it? Normally you install the packages for
BDEPEND, DEPEND, and RDEPEND to the same location. If BDEPEND and
RDEPEND are installed to different locations (ROOT!=/) then DEPEND will
almost always be installed to one of the other two. If either of those
two locations is prefixed then we need the prefix for DEPEND's location
to match, otherwise it wouldn't actually be the same location. Using
ROOT allows us to figure this out automatically in a way that covers
all sensible use cases and avoids accidentally falling into an
unsupported case.

I hope that's clearer.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgp7vt5Id1Dzh.pgp
Description: OpenPGP digital signature


Re: [gentoo-portage-dev] [PATCH] Configure additional addresses on the lo interface for network-sandbox

2019-07-31 Thread Zac Medico
On 7/31/19 12:59 PM, Mike Gilbert wrote:
> This works around some strange behavior in glibc's getaddrinfo()
> implementation when the AI_ADDRCONFIG flag is set.
> 
> For example:
> 
>   struct addrinfo *res, hints = { .ai_family = AF_INET, .ai_flags = 
> AI_ADDRCONFIG };
>   getaddrinfo("localhost", NULL, , );
> 
> This returns no results if there are no non-loopback addresses configured.
> 
> Bug: https://bugs.gentoo.org/690758
> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12377#c13
> Signed-off-by: Mike Gilbert 
> ---
>  lib/portage/process.py | 43 +++---
>  1 file changed, 28 insertions(+), 15 deletions(-)
> 
> diff --git a/lib/portage/process.py b/lib/portage/process.py
> index dfbda75de..4a5a35df2 100644
> --- a/lib/portage/process.py
> +++ b/lib/portage/process.py
> @@ -9,8 +9,6 @@ import fcntl
>  import multiprocessing
>  import platform
>  import signal
> -import socket
> -import struct
>  import subprocess
>  import sys
>  import traceback
> @@ -446,6 +444,33 @@ def spawn(mycommand, env=None, opt_name=None, 
> fd_pipes=None, returnpid=False,
>   # Everything succeeded
>   return 0
>  
> +def _configure_loopback_interface():
> + """
> + Configure the loopback interface.
> + """
> +
> + # We add some additional addresses to work around odd behavior in 
> glibc's
> + # getaddrinfo() implementation when the AI_ADDRCONFIG flag is set.
> + #
> + # For example:
> + #
> + #   struct addrinfo *res, hints = { .ai_family = AF_INET, .ai_flags = 
> AI_ADDRCONFIG };
> + #   getaddrinfo("localhost", NULL, , );
> + #
> + # This returns no results if there are no non-loopback addresses
> + # configured for a given address family.
> + #
> + # Bug: https://bugs.gentoo.org/690758
> + # Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12377#c13
> +
> + try:
> + subprocess.check_call(['ip', 'link', 'set', 'lo', 'up'])
> + subprocess.check_call(['ip', 'address', 'add', '10.0.0.1/8', 
> 'dev', 'lo'])
> + # Try IPv6, but don't fail if the kernel support is missing.
> + subprocess.call(['ip', 'address', 'add', 'fd00::1/8', 'dev', 
> 'lo'])
> + except subprocess.CalledProcessError:
> + writemsg("Unable to configure loopback interface\n")
> +
>  def _exec(binary, mycommand, opt_name, fd_pipes,
>   env, gid, groups, uid, umask, cwd,
>   pre_exec, close_fds, unshare_net, unshare_ipc, unshare_mount, 
> unshare_pid,
> @@ -624,19 +649,7 @@ def _exec(binary, mycommand, opt_name, fd_pipes,
>   
> noiselevel=-1)
>   os._exit(1)
>   if unshare_net:
> - # 'up' the loopback
> - IFF_UP = 0x1
> - ifreq = 
> struct.pack('16sh', b'lo', IFF_UP)
> - SIOCSIFFLAGS = 0x8914
> -
> - sock = 
> socket.socket(socket.AF_INET, socket.SOCK_DGRAM, 0)
> - try:
> - 
> fcntl.ioctl(sock, SIOCSIFFLAGS, ifreq)
> - except IOError as e:
> - 
> writemsg("Unable to enable loopback interface: %s\n" % (
> - 
> errno.errorcode.get(e.errno, '?')),
> - 
> noiselevel=-1)
> - sock.close()
> + 
> _configure_loopback_interface()
>   except AttributeError:
>   # unshare() not supported by libc
>   pass
> 

I'd prefer if we could use the ioctl method if possible, since it's not
much code and it will work even if the `ip` command is missing for any
reason (note that subprocess.check_call will raise an ENOENT
EnvironmentError if it's missing).
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature


[gentoo-portage-dev] [PATCH] Configure additional addresses on the lo interface for network-sandbox

2019-07-31 Thread Mike Gilbert
This works around some strange behavior in glibc's getaddrinfo()
implementation when the AI_ADDRCONFIG flag is set.

For example:

  struct addrinfo *res, hints = { .ai_family = AF_INET, .ai_flags = 
AI_ADDRCONFIG };
  getaddrinfo("localhost", NULL, , );

This returns no results if there are no non-loopback addresses configured.

Bug: https://bugs.gentoo.org/690758
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12377#c13
Signed-off-by: Mike Gilbert 
---
 lib/portage/process.py | 43 +++---
 1 file changed, 28 insertions(+), 15 deletions(-)

diff --git a/lib/portage/process.py b/lib/portage/process.py
index dfbda75de..4a5a35df2 100644
--- a/lib/portage/process.py
+++ b/lib/portage/process.py
@@ -9,8 +9,6 @@ import fcntl
 import multiprocessing
 import platform
 import signal
-import socket
-import struct
 import subprocess
 import sys
 import traceback
@@ -446,6 +444,33 @@ def spawn(mycommand, env=None, opt_name=None, 
fd_pipes=None, returnpid=False,
# Everything succeeded
return 0
 
+def _configure_loopback_interface():
+   """
+   Configure the loopback interface.
+   """
+
+   # We add some additional addresses to work around odd behavior in 
glibc's
+   # getaddrinfo() implementation when the AI_ADDRCONFIG flag is set.
+   #
+   # For example:
+   #
+   #   struct addrinfo *res, hints = { .ai_family = AF_INET, .ai_flags = 
AI_ADDRCONFIG };
+   #   getaddrinfo("localhost", NULL, , );
+   #
+   # This returns no results if there are no non-loopback addresses
+   # configured for a given address family.
+   #
+   # Bug: https://bugs.gentoo.org/690758
+   # Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12377#c13
+
+   try:
+   subprocess.check_call(['ip', 'link', 'set', 'lo', 'up'])
+   subprocess.check_call(['ip', 'address', 'add', '10.0.0.1/8', 
'dev', 'lo'])
+   # Try IPv6, but don't fail if the kernel support is missing.
+   subprocess.call(['ip', 'address', 'add', 'fd00::1/8', 'dev', 
'lo'])
+   except subprocess.CalledProcessError:
+   writemsg("Unable to configure loopback interface\n")
+
 def _exec(binary, mycommand, opt_name, fd_pipes,
env, gid, groups, uid, umask, cwd,
pre_exec, close_fds, unshare_net, unshare_ipc, unshare_mount, 
unshare_pid,
@@ -624,19 +649,7 @@ def _exec(binary, mycommand, opt_name, fd_pipes,

noiselevel=-1)
os._exit(1)
if unshare_net:
-   # 'up' the loopback
-   IFF_UP = 0x1
-   ifreq = 
struct.pack('16sh', b'lo', IFF_UP)
-   SIOCSIFFLAGS = 0x8914
-
-   sock = 
socket.socket(socket.AF_INET, socket.SOCK_DGRAM, 0)
-   try:
-   
fcntl.ioctl(sock, SIOCSIFFLAGS, ifreq)
-   except IOError as e:
-   
writemsg("Unable to enable loopback interface: %s\n" % (
-   
errno.errorcode.get(e.errno, '?')),
-   
noiselevel=-1)
-   sock.close()
+   
_configure_loopback_interface()
except AttributeError:
# unshare() not supported by libc
pass
-- 
2.22.0




Re: [gentoo-portage-dev] [PATCH] Configure a dummy network interface for network-sandbox

2019-07-31 Thread Mike Gilbert
On Wed, Jul 31, 2019 at 2:00 PM Zac Medico  wrote:
>
> On 7/31/19 9:06 AM, Mike Gilbert wrote:
> > This works around some strange behavior in glibc's getaddrinfo()
> > implementation when the AI_ADDRCONFIG flag is set.
> >
> > For example:
> >
> >   struct addrinfo *res, hints = { .ai_family = AF_INET, .ai_flags = 
> > AI_ADDRCONFIG };
> >   getaddrinfo("localhost", NULL, , );
> >
> > This returns no results if there is no non-loopback interface configured 
> > with an
> > IPv4 address.
> >
> > Bug: https://bugs.gentoo.org/690758
> > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12377#c13
> > Signed-off-by: Mike Gilbert 
> > ---
> >  lib/portage/process.py | 24 
> >  1 file changed, 24 insertions(+)
> >
> > diff --git a/lib/portage/process.py b/lib/portage/process.py
> > index dfbda75de..c284c04f3 100644
> > --- a/lib/portage/process.py
> > +++ b/lib/portage/process.py
> > @@ -446,6 +446,29 @@ def spawn(mycommand, env=None, opt_name=None, 
> > fd_pipes=None, returnpid=False,
> >   # Everything succeeded
> >   return 0
> >
> > +def _configure_dummy_interface():
> > + """
> > + Configure a dummy interface to work around odd behavior in glibc's
> > + getaddrinfo() implementation when the AI_ADDRCONFIG flag is set.
> > +
> > + For example:
> > +
> > +   struct addrinfo *res, hints = { .ai_family = AF_INET, .ai_flags = 
> > AI_ADDRCONFIG };
> > +   getaddrinfo("localhost", NULL, , );
> > +
> > + This returns no results if there is no non-loopback interface 
> > configured with an
> > + IPv4 address.
> > +
> > + Bug: https://bugs.gentoo.org/690758
> > + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12377#c13
> > + """
> > + try:
> > + 
> > subprocess.check_call(['ip','link','add','dummy','type','dummy'])
> > + subprocess.check_call(['ip','link','set','dummy','up'])
> > + 
> > subprocess.check_call(['ip','address','add','10.0.0.1/8','dev','dummy'])
> > + except subprocess.CalledProcessError:
> > + writemsg("Unable to configure dummy network interface\n")
> > +
> >  def _exec(binary, mycommand, opt_name, fd_pipes,
> >   env, gid, groups, uid, umask, cwd,
> >   pre_exec, close_fds, unshare_net, unshare_ipc, unshare_mount, 
> > unshare_pid,
> > @@ -637,6 +660,7 @@ def _exec(binary, mycommand, opt_name, fd_pipes,
> >   
> > errno.errorcode.get(e.errno, '?')),
> >   
> > noiselevel=-1)
> >   sock.close()
> > + 
> > _configure_dummy_interface()
> >   except AttributeError:
> >   # unshare() not supported by libc
> >   pass
> >
>
> Maybe it will suffice to add the address to the loopback interface?

I wasn't expecting that to work, but it actually does! That makes this
a bit simpler indeed. I'll send a new patch in a bit.



Re: [gentoo-portage-dev] [PATCH] Configure a dummy network interface for network-sandbox

2019-07-31 Thread Zac Medico
On 7/31/19 9:06 AM, Mike Gilbert wrote:
> This works around some strange behavior in glibc's getaddrinfo()
> implementation when the AI_ADDRCONFIG flag is set.
> 
> For example:
> 
>   struct addrinfo *res, hints = { .ai_family = AF_INET, .ai_flags = 
> AI_ADDRCONFIG };
>   getaddrinfo("localhost", NULL, , );
> 
> This returns no results if there is no non-loopback interface configured with 
> an
> IPv4 address.
> 
> Bug: https://bugs.gentoo.org/690758
> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12377#c13
> Signed-off-by: Mike Gilbert 
> ---
>  lib/portage/process.py | 24 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/lib/portage/process.py b/lib/portage/process.py
> index dfbda75de..c284c04f3 100644
> --- a/lib/portage/process.py
> +++ b/lib/portage/process.py
> @@ -446,6 +446,29 @@ def spawn(mycommand, env=None, opt_name=None, 
> fd_pipes=None, returnpid=False,
>   # Everything succeeded
>   return 0
>  
> +def _configure_dummy_interface():
> + """
> + Configure a dummy interface to work around odd behavior in glibc's
> + getaddrinfo() implementation when the AI_ADDRCONFIG flag is set.
> +
> + For example:
> +
> +   struct addrinfo *res, hints = { .ai_family = AF_INET, .ai_flags = 
> AI_ADDRCONFIG };
> +   getaddrinfo("localhost", NULL, , );
> +
> + This returns no results if there is no non-loopback interface 
> configured with an
> + IPv4 address.
> +
> + Bug: https://bugs.gentoo.org/690758
> + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12377#c13
> + """
> + try:
> + 
> subprocess.check_call(['ip','link','add','dummy','type','dummy'])
> + subprocess.check_call(['ip','link','set','dummy','up'])
> + 
> subprocess.check_call(['ip','address','add','10.0.0.1/8','dev','dummy'])
> + except subprocess.CalledProcessError:
> + writemsg("Unable to configure dummy network interface\n")
> +
>  def _exec(binary, mycommand, opt_name, fd_pipes,
>   env, gid, groups, uid, umask, cwd,
>   pre_exec, close_fds, unshare_net, unshare_ipc, unshare_mount, 
> unshare_pid,
> @@ -637,6 +660,7 @@ def _exec(binary, mycommand, opt_name, fd_pipes,
>   
> errno.errorcode.get(e.errno, '?')),
>   
> noiselevel=-1)
>   sock.close()
> + 
> _configure_dummy_interface()
>   except AttributeError:
>   # unshare() not supported by libc
>   pass
> 

Maybe it will suffice to add the address to the loopback interface?
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature


[gentoo-portage-dev] [PATCH] Configure a dummy network interface for network-sandbox

2019-07-31 Thread Mike Gilbert
This works around some strange behavior in glibc's getaddrinfo()
implementation when the AI_ADDRCONFIG flag is set.

For example:

  struct addrinfo *res, hints = { .ai_family = AF_INET, .ai_flags = 
AI_ADDRCONFIG };
  getaddrinfo("localhost", NULL, , );

This returns no results if there is no non-loopback interface configured with an
IPv4 address.

Bug: https://bugs.gentoo.org/690758
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12377#c13
Signed-off-by: Mike Gilbert 
---
 lib/portage/process.py | 24 
 1 file changed, 24 insertions(+)

diff --git a/lib/portage/process.py b/lib/portage/process.py
index dfbda75de..c284c04f3 100644
--- a/lib/portage/process.py
+++ b/lib/portage/process.py
@@ -446,6 +446,29 @@ def spawn(mycommand, env=None, opt_name=None, 
fd_pipes=None, returnpid=False,
# Everything succeeded
return 0
 
+def _configure_dummy_interface():
+   """
+   Configure a dummy interface to work around odd behavior in glibc's
+   getaddrinfo() implementation when the AI_ADDRCONFIG flag is set.
+
+   For example:
+
+ struct addrinfo *res, hints = { .ai_family = AF_INET, .ai_flags = 
AI_ADDRCONFIG };
+ getaddrinfo("localhost", NULL, , );
+
+   This returns no results if there is no non-loopback interface 
configured with an
+   IPv4 address.
+
+   Bug: https://bugs.gentoo.org/690758
+   Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12377#c13
+   """
+   try:
+   
subprocess.check_call(['ip','link','add','dummy','type','dummy'])
+   subprocess.check_call(['ip','link','set','dummy','up'])
+   
subprocess.check_call(['ip','address','add','10.0.0.1/8','dev','dummy'])
+   except subprocess.CalledProcessError:
+   writemsg("Unable to configure dummy network interface\n")
+
 def _exec(binary, mycommand, opt_name, fd_pipes,
env, gid, groups, uid, umask, cwd,
pre_exec, close_fds, unshare_net, unshare_ipc, unshare_mount, 
unshare_pid,
@@ -637,6 +660,7 @@ def _exec(binary, mycommand, opt_name, fd_pipes,

errno.errorcode.get(e.errno, '?')),

noiselevel=-1)
sock.close()
+   
_configure_dummy_interface()
except AttributeError:
# unshare() not supported by libc
pass
-- 
2.22.0




Re: [gentoo-dev] [PMS] [PATCH] Correct the definition of ESYSROOT as EPREFIX isn't always applicable

2019-07-31 Thread Alexis Ballier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, 30 Jul 2019 23:26:27 +0100
James Le Cuirot  wrote:

> > Admittedly without a full understanding of the problem, but this
> > looks wrong to me: SYSROOT, EPREFIX and BROOT are only relevant in
> > build phases (src_*); (EPREFIX is a little special here but mostly
> > for convenience). ROOT is only relevant in pkg_* phases. I don't
> > see how this can work. Say I build a binpkg with ROOT=/ then use
> > that binpkg with ROOT=/somewhere, you can't go back and change
> > SYSROOT.
> 
> ROOT is used to determine ESYSROOT, not the other way around. As you
> say, (E)SYSROOT is only relevant in src phases so it doesn't matter if
> ROOT has changed when installing a binpkg.

I am missing something here: You are making ESYSROOT depend on the
value of ROOT, so how can it not matter ?

> I take your point that setting a src phase variable based on a pkg
> phase variable seems odd but we're only using ROOT to determine the
> applicable prefix. We're not taking the actual value of ROOT. When
> Portage works all this out, it has access to all the necessary
> variables. It only filters the variables based on the phase function
> later on.

The value does not really matter, the dependency of a variable used in
src_* from a variable that can change when installing a binpkg is what
worries me here.


Alexis.
-BEGIN PGP SIGNATURE-

iHUEAREIAB0WIQSpOxaxaZikKNVNlsYOJUi7xgflrgUCXUGc/gAKCRAOJUi7xgfl
rrlNAP9AEX0enc5Tzh++N6I+P4ZKp0hBdljlYBteYTuEipZLEAD/a3fT/pgOR3HJ
LyGvu98wHn6sCldtBMjoV/RgrxfaKO8=
=L9Hp
-END PGP SIGNATURE-


[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/