Bug#834788: singularity-container: FTBFS: most platforms unsupported

2016-08-19 Thread Gregory M. Kurtzer
On Fri, Aug 19, 2016 at 7:18 AM, Yaroslav Halchenko <deb...@onerussian.com>
wrote:

>
> On Fri, 19 Aug 2016, Gregory M. Kurtzer wrote:
> >  I thought that the idea generally is to not restrict by default and
> >  possibly to let interested in porting to look at it. Policy 5.6.8
> >  states "Specifying a list of architectures or architecture wildcards
> >  other than any is for the minority of cases where a program is not
> >  portable or is not useful on some architectures".
>
> >  Theoretically I think singularity could be ported for other
> >  architectures (CCing upstream for clarification), not that me or
> >  upstream is going to embark on such a voyage ATM ;)
>
> >  If there is somewhere policy/recommendation that I should better
> drop
> >  from any to a restricted list of architectures, please let me know,
> and
> >  I will do so for the next release.
>
> >That is a good point regarding non-Linux builds. At present I am not
> >checking for the clone() or unshare() system calls, as they have been
> on
> >Linux for quite some time so I didn't think of them not being
> available,
> >but they are Linux specific system calls (as are the CLONE_* flags
> which I
> >am checking for). So it sounds like I need to add some checks for
> clone()
> >and unshare() and bomb out early with a reasonable error message
> about an
> >unsupported platform before checking for the flags.
> >As far as architecture support, Singularity *should* build on non-x86
> >architectures just fine, but my ability to port and test are limited
> to
> >x86. I am aware that IBM has successfully ported and used Singularity
> on
> >Power, but I've never gotten any patches so I assumed it just worked.
> Are
> >the failed build logs for non-x86 available?
>
> This is the page you could always go to
> https://buildd.debian.org/status/package.php?p=
> singularity-container=unstable
> to get the logs (click on Build-Attempted)
>

It doesn't actually show the configure output, or did it die at the first
line?


configure: exit 1
dh_auto_configure: ./configure --build=aarch64-linux-gnu --prefix=/usr
--includedir=${prefix}/include --mandir=${prefix}/share/man
--infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var
--disable-silent-rules --libdir=${prefix}/lib/aarch64-linux-gnu
--libexecdir=${prefix}/lib/aarch64-linux-gnu --disable-maintainer-mode
--disable-dependency-tracking returned exit code 1
debian/rules:9: recipe for target 'build-arch' failed
make: *** [build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2



>
> I can provide you access to mipsel, and possible sparc (when I bring it
> back online, that poor elderly beast with failing fan), and soon
> powerpc.
>
>
 You are awesome, thank you!

Greg

-- 
Gregory M. Kurtzer
High Performance Computing Services (HPCS)
University of California
Lawrence Berkeley National Laboratory
One Cyclotron Road, Berkeley, CA 94720


Bug#834788: singularity-container: FTBFS: most platforms unsupported

2016-08-19 Thread Gregory M. Kurtzer
On Thu, Aug 18, 2016 at 10:02 PM, Yaroslav Halchenko <deb...@onerussian.com>
wrote:

>
> On Thu, 18 Aug 2016, Aaron M. Ucko wrote:
>
> > Source: singularity-container
> > Version: 2.1.2-1
> > Severity: important
> > Justification: fails to build from source
>
> > Builds of singularity-container for architectures other than x86 Linux
> > have been failing at the configuration stage.  The non-Linux builds
> > complain that various CLONE_* flags, most crucially CLONE_NEWNS, are
> > unavailable; I presume these platforms are a lost cause.  As for Linux
> > on non-x86, the build system complains that the architecture "is not
> > supported"; I haven't checked whether that's simply a case of
> > excessive conservatism.
>
> > Could you please take a look and restrict the package's official
> > Architecture accordingly?
>
> I thought that the idea generally is to not restrict by default and
> possibly to let interested in porting to look at it. Policy 5.6.8
> states "Specifying a list of architectures or architecture wildcards
> other than any is for the minority of cases where a program is not
> portable or is not useful on some architectures".
>
> Theoretically I think singularity could be ported for other
> architectures (CCing upstream for clarification), not that me or
> upstream is going to embark on such a voyage ATM ;)
>
> If there is somewhere policy/recommendation that I should better drop
> from any to a restricted list of architectures, please let me know, and
> I will do so for the next release.
>

That is a good point regarding non-Linux builds. At present I am not
checking for the clone() or unshare() system calls, as they have been on
Linux for quite some time so I didn't think of them not being available,
but they are Linux specific system calls (as are the CLONE_* flags which I
am checking for). So it sounds like I need to add some checks for clone()
and unshare() and bomb out early with a reasonable error message about an
unsupported platform before checking for the flags.

As far as architecture support, Singularity *should* build on non-x86
architectures just fine, but my ability to port and test are limited to
x86. I am aware that IBM has successfully ported and used Singularity on
Power, but I've never gotten any patches so I assumed it just worked. Are
the failed build logs for non-x86 available?

 Thank you!


-- 
Gregory M. Kurtzer
High Performance Computing Services (HPCS)
University of California
Lawrence Berkeley National Laboratory
One Cyclotron Road, Berkeley, CA 94720