Bug#834788: singularity-container: FTBFS: most platforms unsupported
Yaroslav Halchenko writes: > Upstream has intent to look into compatibility with other > architectures, next builds will remove some arch checks etc. So we > will just stay inline with current policy for arch any, and possibly > later restrict to a subset... Great, thanks! FTR, I don't favor a priori or otherwise gratuitous architecture restrictions, just honest indications of the architectures on which automatic builds have a reasonable prospect of succeeding now or at least in the near future. (I see no point in bothering to start automatic builds on architectures for which a package would need a major overhaul unless such an overhaul is actually forthcoming.) -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#834788: singularity-container: FTBFS: most platforms unsupported
Look above that summary line
On August 19, 2016 10:24:33 AM EDT, "Gregory M. Kurtzer"
wrote:
>On Fri, Aug 19, 2016 at 7:18 AM, Yaroslav Halchenko
>
>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&suite=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
On Fri, Aug 19, 2016 at 7:18 AM, Yaroslav Halchenko
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&suite=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
On Thu, Aug 18, 2016 at 10:02 PM, Yaroslav Halchenko 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
Bug#834788: singularity-container: FTBFS: most platforms unsupported
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&suite=unstable to get the logs (click on Build-Attempted) 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. -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Bug#834788: singularity-container: FTBFS: most platforms unsupported
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. Cheers, -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Bug#834788: singularity-container: FTBFS: most platforms unsupported
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? Thanks!
