Re: devel/mico failing due to failed assertion

[Karel Gardas]

Guys,

I've installed 5.8 chroot on 5.9-beta as of January 2016. I've removed
/etc/resolve.conf after installing few packages and give MICO build a
try. I've duplicated issue of assert in address.cc:555 since hostname
is not resolvable. I've been able to solve this assert by putting:

-ORBIIOPAddr inet:127.0.0.1:0 -ORBNoResolve

into some file and then:

export MICORC=

E.g.
$ echo "-ORBIIOPAddr inet:127.0.0.1:0 -ORBNoResolve" > /tmp/mico-build.rc
$ export MICORC=/tmp/mico-build.rc

this instructs MICO to load configuration options for its
initialization from the file, so basically -ORBIIOPAddr
inet:127.0.0.1:0 -ORBNoResolve are used for all IDL compiler
invocations. Those two options means: bind to 127.0.0.1, system
selected port and do not attempt to resolve name for this address to
get some meaningful name.

I think this should be enough even for Marc's builder but if you put
even more limits on your builders like for example can't create tcp
socket, then I should be able to instruct MICO to use unix pipes
instead -- hopefully those will be allowed at the end. :-)

Please let me know if this solves the issue for you. Thanks! Karel

On Fri, Mar 11, 2016 at 12:26 PM, Stuart Henderson  wrote:
> On 2016/03/11 11:22, Karel Gardas wrote:
>> On Thu, Mar 10, 2016 at 10:28 PM, Marc Espie  wrote:
>> >> Indeed, it is, but I guess this was done for a good reason in the past
>> >> and I would rather keep it this way. What I can certainly do for
>> >> 2.3.14 release is to add some clear error message pointing to the
>> >> incorrect network configuration.
>> >
>> > It's not an incorrect network configuration, actually.   It's just no 
>> > resolving
>> > some things on localhost.
>> >
>> > mico is the only port that wants this. Everything else works peachy.
>> >
>> > I've got a very paranoid setup on my build machines.
>> > I just have:
>> > block out quick proto {tcp,udp} from self user pbuild0
>> >
>> > oh, and the build is chroot'd to a place that only knows about localhost.
>> >
>> > No other port in the trees ever tries to resolve `hostname` during build.
>>
>> is it a big problem to set hostname to localhost  in such chroot and
>> have localhost resolvable to 127.0.0.1 and 127.0.0.1 back to
>> localhost?
>>
>> Just asking. The possibility is that -ORBNoResolve works in such case
>> and if so we may add it into IDL compiler main.cc as a parameter
>> specifically for OpenBSD. If this works well I may even relax this
>> condition for IDL compiler on all platforms or specifically test if
>> the issue is present and then switch NoResolve on...
>
> I think we could reasonably expect "localhost" to be resolvable
> forwards and backwards, but the hostname is system-wide and returned
> by a system call, you can't have a different one inside chroot.
>

Re: devel/mico failing due to failed assertion

[Stuart Henderson]

On 2016/03/11 11:22, Karel Gardas wrote:
> On Thu, Mar 10, 2016 at 10:28 PM, Marc Espie  wrote:
> >> Indeed, it is, but I guess this was done for a good reason in the past
> >> and I would rather keep it this way. What I can certainly do for
> >> 2.3.14 release is to add some clear error message pointing to the
> >> incorrect network configuration.
> >
> > It's not an incorrect network configuration, actually.   It's just no 
> > resolving
> > some things on localhost.
> >
> > mico is the only port that wants this. Everything else works peachy.
> >
> > I've got a very paranoid setup on my build machines.
> > I just have:
> > block out quick proto {tcp,udp} from self user pbuild0
> >
> > oh, and the build is chroot'd to a place that only knows about localhost.
> >
> > No other port in the trees ever tries to resolve `hostname` during build.
> 
> is it a big problem to set hostname to localhost  in such chroot and
> have localhost resolvable to 127.0.0.1 and 127.0.0.1 back to
> localhost?
> 
> Just asking. The possibility is that -ORBNoResolve works in such case
> and if so we may add it into IDL compiler main.cc as a parameter
> specifically for OpenBSD. If this works well I may even relax this
> condition for IDL compiler on all platforms or specifically test if
> the issue is present and then switch NoResolve on...

I think we could reasonably expect "localhost" to be resolvable
forwards and backwards, but the hostname is system-wide and returned
by a system call, you can't have a different one inside chroot.

Re: devel/mico failing due to failed assertion

[Karel Gardas]

On Thu, Mar 10, 2016 at 10:28 PM, Marc Espie  wrote:
>> Indeed, it is, but I guess this was done for a good reason in the past
>> and I would rather keep it this way. What I can certainly do for
>> 2.3.14 release is to add some clear error message pointing to the
>> incorrect network configuration.
>
> It's not an incorrect network configuration, actually.   It's just no 
> resolving
> some things on localhost.
>
> mico is the only port that wants this. Everything else works peachy.
>
> I've got a very paranoid setup on my build machines.
> I just have:
> block out quick proto {tcp,udp} from self user pbuild0
>
> oh, and the build is chroot'd to a place that only knows about localhost.
>
> No other port in the trees ever tries to resolve `hostname` during build.

is it a big problem to set hostname to localhost  in such chroot and
have localhost resolvable to 127.0.0.1 and 127.0.0.1 back to
localhost?

Just asking. The possibility is that -ORBNoResolve works in such case
and if so we may add it into IDL compiler main.cc as a parameter
specifically for OpenBSD. If this works well I may even relax this
condition for IDL compiler on all platforms or specifically test if
the issue is present and then switch NoResolve on...

Re: devel/mico failing due to failed assertion

[Karel Gardas]

On Thu, Mar 10, 2016 at 7:37 PM, Michael McConville  wrote:
> Karel Gardas wrote:
>> This is a sign of not so correct network configuration. MICO is really
>> picky about it so it should be able to resolve your host name/IP
>> address. What's failing precisely in the assert above is that it's not
>> able to get IP for your hostname. Can you confirm that this is the
>> case?
>
> Confirmed. I hadn't considered that my hostname could affect a package
> build.  :-)
>
> I don't know anything about Mico, so I'll stay out of the patching
> process.

The problem is simple: one part of build process is building
CORBA/MICO services. For this you need IDL compiler which translates
service interfaces (IDL) into target language (C++). The IDL compiler
itself is CORBA/MICO application (to be able to upload IDL files into
the interface repository which is also CORBA application). So IDL
compiler initializes CORBA/MICO and for this unfortunately (on MICO
side) you need to have correct hostname/ip setup.

Workaround for this may be to use -ORBNoResolve on IDL compiler
command-line. I have not tested this since all my hosts are OK from
this issue, but perhaps you can on your build host?

Re: devel/mico failing due to failed assertion

[Theo de Raadt]

> On Thu, Mar 10, 2016 at 05:58:05PM +0100, Karel Gardas wrote:
> > On Thu, Mar 10, 2016 at 3:13 PM, Marc Espie  wrote:
> > > On Thu, Mar 10, 2016 at 11:53:56AM +0100, Karel Gardas wrote:
> > >> This is a sign of not so correct network configuration. MICO is really
> > >> picky about it so it should be able to resolve your host name/IP
> > >> address. What's failing precisely in the assert above is that it's not
> > >> able to get IP for your hostname. Can you confirm that this is the
> > >> case?
> > >
> > > Nope. This is the only port in the tree that doesn't like it when you cut
> > > network access during build (which proper build machines have started 
> > > doing
> > > for a while now).
> > 
> > This would be strange since I commonly build MICO w/o any internet 
> > connection.
> 
> This is not what I'm talking about. I'm talking about explicitly blocking
> the build user from any kind of network activity thru pf.
> 
> > Indeed, it is, but I guess this was done for a good reason in the past
> > and I would rather keep it this way. What I can certainly do for
> > 2.3.14 release is to add some clear error message pointing to the
> > incorrect network configuration.
> 
> It's not an incorrect network configuration, actually.   It's just no 
> resolving
> some things on localhost.
> 
> mico is the only port that wants this. Everything else works peachy.
> 
> I've got a very paranoid setup on my build machines.
> I just have:
> block out quick proto {tcp,udp} from self user pbuild0
> 
> oh, and the build is chroot'd to a place that only knows about localhost.
> 
> No other port in the trees ever tries to resolve `hostname` during build.

but then how does it download the egg...

Re: devel/mico failing due to failed assertion

[Marc Espie]

On Thu, Mar 10, 2016 at 05:58:05PM +0100, Karel Gardas wrote:
> On Thu, Mar 10, 2016 at 3:13 PM, Marc Espie  wrote:
> > On Thu, Mar 10, 2016 at 11:53:56AM +0100, Karel Gardas wrote:
> >> This is a sign of not so correct network configuration. MICO is really
> >> picky about it so it should be able to resolve your host name/IP
> >> address. What's failing precisely in the assert above is that it's not
> >> able to get IP for your hostname. Can you confirm that this is the
> >> case?
> >
> > Nope. This is the only port in the tree that doesn't like it when you cut
> > network access during build (which proper build machines have started doing
> > for a while now).
> 
> This would be strange since I commonly build MICO w/o any internet connection.

This is not what I'm talking about. I'm talking about explicitly blocking
the build user from any kind of network activity thru pf.

> Indeed, it is, but I guess this was done for a good reason in the past
> and I would rather keep it this way. What I can certainly do for
> 2.3.14 release is to add some clear error message pointing to the
> incorrect network configuration.

It's not an incorrect network configuration, actually.   It's just no resolving
some things on localhost.

mico is the only port that wants this. Everything else works peachy.

I've got a very paranoid setup on my build machines.
I just have:
block out quick proto {tcp,udp} from self user pbuild0

oh, and the build is chroot'd to a place that only knows about localhost.

No other port in the trees ever tries to resolve `hostname` during build.

Re: devel/mico failing due to failed assertion

[Michael McConville]

Karel Gardas wrote:
> This is a sign of not so correct network configuration. MICO is really
> picky about it so it should be able to resolve your host name/IP
> address. What's failing precisely in the assert above is that it's not
> able to get IP for your hostname. Can you confirm that this is the
> case?

Confirmed. I hadn't considered that my hostname could affect a package
build.  :-)

I don't know anything about Mico, so I'll stay out of the patching
process.

Re: devel/mico failing due to failed assertion

[Karel Gardas]

On Thu, Mar 10, 2016 at 3:13 PM, Marc Espie  wrote:
> On Thu, Mar 10, 2016 at 11:53:56AM +0100, Karel Gardas wrote:
>> This is a sign of not so correct network configuration. MICO is really
>> picky about it so it should be able to resolve your host name/IP
>> address. What's failing precisely in the assert above is that it's not
>> able to get IP for your hostname. Can you confirm that this is the
>> case?
>
> Nope. This is the only port in the tree that doesn't like it when you cut
> network access during build (which proper build machines have started doing
> for a while now).

This would be strange since I commonly build MICO w/o any internet connection.

> I've looked a bit further, and that stupid test is so deep embedded within
> the mico code itself that it will be a pain to fix.

Indeed, it is, but I guess this was done for a good reason in the past
and I would rather keep it this way. What I can certainly do for
2.3.14 release is to add some clear error message pointing to the
incorrect network configuration.

Re: devel/mico failing due to failed assertion

[Stuart Henderson]

On 2016/03/10 15:13, Marc Espie wrote:
> On Thu, Mar 10, 2016 at 11:53:56AM +0100, Karel Gardas wrote:
> > This is a sign of not so correct network configuration. MICO is really
> > picky about it so it should be able to resolve your host name/IP
> > address. What's failing precisely in the assert above is that it's not
> > able to get IP for your hostname. Can you confirm that this is the
> > case?
> 
> Nope. This is the only port in the tree that doesn't like it when you cut
> network access during build (which proper build machines have started doing
> for a while now).
> 
> I've looked a bit further, and that stupid test is so deep embedded within
> the mico code itself that it will be a pain to fix.
> 

It's not even network access, it just needs the name in /etc/hosts.
mico builds fine for me and I do not permit _pbuild to make network
connections, but I do have an entry in /etc/hosts for the hostname
(i.e. getent `hostname` works).

Re: devel/mico failing due to failed assertion

[Marc Espie]

On Thu, Mar 10, 2016 at 11:53:56AM +0100, Karel Gardas wrote:
> This is a sign of not so correct network configuration. MICO is really
> picky about it so it should be able to resolve your host name/IP
> address. What's failing precisely in the assert above is that it's not
> able to get IP for your hostname. Can you confirm that this is the
> case?

Nope. This is the only port in the tree that doesn't like it when you cut
network access during build (which proper build machines have started doing
for a while now).

I've looked a bit further, and that stupid test is so deep embedded within
the mico code itself that it will be a pain to fix.

Re: devel/mico failing due to failed assertion

[Peter Hessler]

On 2016 Mar 10 (Thu) at 10:53:26 + (+), Stuart Henderson wrote:
:On 2016/03/10 02:05, Michael McConville wrote:
:> It's been failing reliably on my machine since I started bulk building a
:> couple months ago.
:
:If your local hostname doesn't resolve this triggers an assertion in
:mico.
:

would setting a fake hostname fix the assert?  can that be patched out?


-- 
In Boston, it is illegal to hold frog-jumping contests in nightclubs.

Re: devel/mico failing due to failed assertion

[Stuart Henderson]

On 2016/03/10 02:05, Michael McConville wrote:
> It's been failing reliably on my machine since I started bulk building a
> couple months ago.

If your local hostname doesn't resolve this triggers an assertion in
mico.

Re: devel/mico failing due to failed assertion

[Karel Gardas]

This is a sign of not so correct network configuration. MICO is really
picky about it so it should be able to resolve your host name/IP
address. What's failing precisely in the assert above is that it's not
able to get IP for your hostname. Can you confirm that this is the
case?

On Thu, Mar 10, 2016 at 11:05 AM, Michael McConville  wrote:
> It's been failing reliably on my machine since I started bulk building a
> couple months ago.
>
>
 Building on localhost under devel/mico
>  BDEPENDS = [devel/gmake]
>  DIST = [devel/mico:mico-2.3.13.tar.gz]
>  FULLPKGNAME = mico-2.3.13p0
> (Junk lock failure for localhost at 1455583281)
> Received IO
> (Junk lock obtained for localhost at 1455583287)
> Woken up devel/mico
> Woken up devel/mico
> Woken up devel/mico
> Short-cut: depends already handled by devel/avr/gcc
 Running show-prepare-results in devel/mico at 1455583287
> ===> devel/mico
> ===> mico-2.3.13p0 depends on: gmake-* -> gmake-4.1p0
> ===>  Verifying specs:  c m ncurses readline stdc++ crypto ssl ICE SM X11 Xt 
> pthread
> ===>  found c.84.2 m.9.0 ncurses.14.0 readline.4.0 stdc++.57.0 crypto.37.0 
> ssl.38.0 ICE.10.0 SM.9.0 X11.16.1 Xt.11.0 pthread.20.1
> gmake-4.1p0
> (Junk lock released for localhost at 1455583288)
> distfiles size=3269814
 Running patch in devel/mico at 1455583288
> ===> devel/mico
> ===>  Checking files for mico-2.3.13p0
> `/mnt/big/ports/distfiles/mico-2.3.13.tar.gz' is up to date.
> ===>  Extracting for mico-2.3.13p0
> ===>  Patching for mico-2.3.13p0
 Running configure in devel/mico at 1455583290
> ===> devel/mico
> ===>  Configuring for mico-2.3.13p0
> Using /home/dpb-wrk/mico-2.3.13/config.site (generated)
> loading site script /home/dpb-wrk/mico-2.3.13/config.site
> creating cache ./config.cache
> checking for extra include and lib directories...
> checking host system type... x86_64-unknown-openbsd5.9
> checking target system type... x86_64-unknown-openbsd5.9
> checking build system type... x86_64-unknown-openbsd5.9
> checking for gcc... cc
> checking whether the C compiler (cc -O2 -pipe ) works... yes
> checking whether the C compiler (cc -O2 -pipe ) is a cross-compiler... no
> checking whether we are using GNU C... (cached) yes
> checking whether cc accepts -g... (cached) yes
> checking how to run the C preprocessor... cc -E
> checking for c++... c++
> checking whether the C++ compiler (c++ -O2 -pipe ) works... yes
> checking whether the C++ compiler (c++ -O2 -pipe ) is a cross-compiler... no
> checking whether we are using GNU C++... yes
> checking whether c++ accepts -g... (cached) yes
> checking how to run the C++ preprocessor... c++ -E
> checking for POSIXized ISC... no
> checking OS Type... unix
> checking for open in -lpthread... yes
> checking for pthread.h... (cached) yes
> checking for sched.h... yes
> checking for semaphore.h... (cached) yes
> checking for bison... yacc
> checking for flex... (cached) flex
> checking for yywrap in -lfl... (cached) yes
> checking for ar... ar rc
> checking for ranlib... ranlib
> checking whether gmake sets ${MAKE}... yes
> checking for tclsh... tclsh
> checking for javac... no
> checking for JavaCUP... no
> configure: warning: you have not installed JDK 1.1 and JavaCUP. java parts 
> disabled.
> checking for esnacc/c++/asn-incl.h... no
> checking for open in -lc++asn1... no
> checking for esnacc... no
> checking for smp/AttributeCertificateDefinitions.h... no
> checking for open in -lcmlasn... no
> checking for open in -lm... (cached) yes
> checking for open in -lnsl... no
> checking for X... (cached) libraries /usr/X11R6/lib, headers 
> /usr/X11R6/include
> checking for dnet_ntoa in -ldnet... no
> checking for dnet_ntoa in -ldnet_stub... no
> checking for gethostbyname... (cached) yes
> checking for connect... (cached) yes
> checking for remove... (cached) yes
> checking for shmat... (cached) yes
> checking for IceConnectionNumber in -lICE... (cached) yes
> checking for open in -lsocket... no
> checking for open in -lbsd... no
> checking for open in -lelf... no
> checking for open in -ldl... no
> checking for open in -ldld... no
> checking for open in -lld... no
> checking for open in -lcrypto... yes
> checking for open in -lssl... yes
> checking for open in -lncurses... yes
> checking for readline in -lreadline... yes
> checking for ANSI C header files... (cached) yes
> checking for fcntl.h... (cached) yes
> checking for unistd.h... (cached) yes
> checking for sys/select.h... (cached) yes
> checking for strings.h... (cached) yes
> checking for float.h... (cached) yes
> checking for ieeefp.h... yes
> checking for sys/un.h... (cached) yes
> checking for netinet/in.h... (cached) yes
> checking for arpa/inet.h... (cached) yes
> checking for netdb.h... (cached) yes
> checking for dlfcn.h... (cached) yes
> checking for dl.h... no
> checking for netinet/tcp.h... (cached) yes
> checking for stdlib.h... (cached) yes
> checking for sys/time.h... (cached) yes
> checking for 

devel/mico failing due to failed assertion

[Michael McConville]

It's been failing reliably on my machine since I started bulk building a
couple months ago.


>>> Building on localhost under devel/mico
 BDEPENDS = [devel/gmake]
 DIST = [devel/mico:mico-2.3.13.tar.gz]
 FULLPKGNAME = mico-2.3.13p0
(Junk lock failure for localhost at 1455583281)
Received IO
(Junk lock obtained for localhost at 1455583287)
Woken up devel/mico
Woken up devel/mico
Woken up devel/mico
Short-cut: depends already handled by devel/avr/gcc
>>> Running show-prepare-results in devel/mico at 1455583287
===> devel/mico
===> mico-2.3.13p0 depends on: gmake-* -> gmake-4.1p0
===>  Verifying specs:  c m ncurses readline stdc++ crypto ssl ICE SM X11 Xt 
pthread
===>  found c.84.2 m.9.0 ncurses.14.0 readline.4.0 stdc++.57.0 crypto.37.0 
ssl.38.0 ICE.10.0 SM.9.0 X11.16.1 Xt.11.0 pthread.20.1
gmake-4.1p0
(Junk lock released for localhost at 1455583288)
distfiles size=3269814
>>> Running patch in devel/mico at 1455583288
===> devel/mico
===>  Checking files for mico-2.3.13p0
`/mnt/big/ports/distfiles/mico-2.3.13.tar.gz' is up to date.
===>  Extracting for mico-2.3.13p0
===>  Patching for mico-2.3.13p0
>>> Running configure in devel/mico at 1455583290
===> devel/mico
===>  Configuring for mico-2.3.13p0
Using /home/dpb-wrk/mico-2.3.13/config.site (generated)
loading site script /home/dpb-wrk/mico-2.3.13/config.site
creating cache ./config.cache
checking for extra include and lib directories...
checking host system type... x86_64-unknown-openbsd5.9
checking target system type... x86_64-unknown-openbsd5.9
checking build system type... x86_64-unknown-openbsd5.9
checking for gcc... cc
checking whether the C compiler (cc -O2 -pipe ) works... yes
checking whether the C compiler (cc -O2 -pipe ) is a cross-compiler... no
checking whether we are using GNU C... (cached) yes
checking whether cc accepts -g... (cached) yes
checking how to run the C preprocessor... cc -E
checking for c++... c++
checking whether the C++ compiler (c++ -O2 -pipe ) works... yes
checking whether the C++ compiler (c++ -O2 -pipe ) is a cross-compiler... no
checking whether we are using GNU C++... yes
checking whether c++ accepts -g... (cached) yes
checking how to run the C++ preprocessor... c++ -E
checking for POSIXized ISC... no
checking OS Type... unix
checking for open in -lpthread... yes
checking for pthread.h... (cached) yes
checking for sched.h... yes
checking for semaphore.h... (cached) yes
checking for bison... yacc
checking for flex... (cached) flex
checking for yywrap in -lfl... (cached) yes
checking for ar... ar rc
checking for ranlib... ranlib
checking whether gmake sets ${MAKE}... yes
checking for tclsh... tclsh
checking for javac... no
checking for JavaCUP... no
configure: warning: you have not installed JDK 1.1 and JavaCUP. java parts 
disabled.
checking for esnacc/c++/asn-incl.h... no
checking for open in -lc++asn1... no
checking for esnacc... no
checking for smp/AttributeCertificateDefinitions.h... no
checking for open in -lcmlasn... no
checking for open in -lm... (cached) yes
checking for open in -lnsl... no
checking for X... (cached) libraries /usr/X11R6/lib, headers /usr/X11R6/include
checking for dnet_ntoa in -ldnet... no
checking for dnet_ntoa in -ldnet_stub... no
checking for gethostbyname... (cached) yes
checking for connect... (cached) yes
checking for remove... (cached) yes
checking for shmat... (cached) yes
checking for IceConnectionNumber in -lICE... (cached) yes
checking for open in -lsocket... no
checking for open in -lbsd... no
checking for open in -lelf... no
checking for open in -ldl... no
checking for open in -ldld... no
checking for open in -lld... no
checking for open in -lcrypto... yes
checking for open in -lssl... yes
checking for open in -lncurses... yes
checking for readline in -lreadline... yes
checking for ANSI C header files... (cached) yes
checking for fcntl.h... (cached) yes
checking for unistd.h... (cached) yes
checking for sys/select.h... (cached) yes
checking for strings.h... (cached) yes
checking for float.h... (cached) yes
checking for ieeefp.h... yes
checking for sys/un.h... (cached) yes
checking for netinet/in.h... (cached) yes
checking for arpa/inet.h... (cached) yes
checking for netdb.h... (cached) yes
checking for dlfcn.h... (cached) yes
checking for dl.h... no
checking for netinet/tcp.h... (cached) yes
checking for stdlib.h... (cached) yes
checking for sys/time.h... (cached) yes
checking for sunmath.h... no
checking for sys/stat.h... (cached) yes
checking for poll.h... (cached) yes
checking for exception... yes
checking for exception.h... no
checking for terminate.h... no
checking for openssl/ssl.h... (cached) yes
checking for pgsql/libpq-fe.h... no
checking for qapplication.h... no
checking for qsocketnotifier.h... no
checking for qlineedit.h... no
checking for byteorder.h... no
checking for iostream... yes
checking for map... yes
checking for string... yes
checking for sstream... yes
checking for Ansi C++ headers... yes
checking for cxxabi.h... yes
checking for