Bug#816980: [Pkg-julia-devel] Bug#816980: julia: FTBFS in testing

2016-04-26 Thread Santiago Vila
On Tue, Apr 26, 2016 at 05:05:07PM +0200, Graham Inggs wrote:

> I attach the complete build log for the 1 CPU and 1GB build.
> The others logs look very similar.

I found this difference. First file is mine, second file is yours:

@@ -983,8 +228,8 @@
 checking for ranlib... ranlib
 checking command to parse /usr/bin/nm -B output from gcc -march=x86-64 -m64  
object... ok
 checking for sysroot... no
-checking for mt... no
-checking if : is a manifest tool... no
+checking for mt... mt
+checking if mt is a manifest tool... no
 checking how to run the C preprocessor... gcc -march=x86-64 -m64  -E
 checking for ANSI C header files... yes
 checking for sys/types.h... yes


* Please use a chroot with only build-essential packages and the julia 
build-dependencies.
* Please use sbuild (which is how it fails for me).

Thanks.



Bug#816980: [Pkg-julia-devel] Bug#816980: julia: FTBFS in testing

2016-04-26 Thread Graham Inggs

Hi Santiago

I set up a Debian Testing amd64 VM in VirtualBox, initially with 2 CPUs 
and 4GB which I later reduced.


I successfully built julia 0.4.5-3 with 2 CPUS and 4GB, 2 CPUS and 2GB, 
1 CPU and 4GB, 1 CPU and 2GB and finally 1 CPU and 1GB.


I attach the complete build log for the 1 CPU and 1GB build.
The others logs look very similar.

Regards
Graham



julia_0.4.5-3_amd64_1cpu_1gb.build.gz
Description: application/gzip


Bug#816980: [Pkg-julia-devel] Bug#816980: julia: FTBFS in testing

2016-04-25 Thread Peter Colberg
Hi Santiago,

On Mon, Apr 25, 2016 at 09:24:51PM +0200, Santiago Vila wrote:
> Question: Why should this package be the only one which does not work
> with eatmydata? Are there good reasons for the build system to be
> incompatible with eatmydata? Could julia be made compatible with
> eatmydaya again? I'm building a lot of packages and this is a real
> time saver.

I had the same issue with eatmydata causing segmentation faults:

https://github.com/JuliaLang/julia/issues/14033

You can still use eatmydata by diverting dpkg inside the sbuild chroot

dpkg-divert --rename /usr/bin/dpkg

and putting the following script in its place:

#!/bin/sh
exec /usr/bin/eatmydata /usr/bin/dpkg.distrib "$@"

Regards,
Peter



Bug#816980: [Pkg-julia-devel] Bug#816980: julia: FTBFS in testing (signal (11): Segmentation fault)

2016-04-25 Thread Santiago Vila
On Mon, Apr 25, 2016 at 09:15:35AM -0700, Tony Kelman wrote:
> Probably because the Debian build isn't using the stable, tested,
> recommended and supported version of LLVM for that branch of Julia. LLVM
> makes significant breaking changes to all of their API's between minor
> versions, so removing old versions from Debian means downstream users of
> LLVM end up broken or with serious performance and memory regressions.

Well, this is Debian testing and unstable what we are talking about.

If the Debian maintainers of Julia decided to use the latest LLVM compiler,
not the stable version that you recommend, I guess it's because they are
willing to help Debian as a whole to discover and fix any remaining LLVM
bugs (for example, this one if it were a LLVM bug) before the current
Debian testing becomes the next Debian stable.

In principle, this should be good for Debian and also good for Julia,
because it is this way that you will be able to recommend, say, LLVM 3.8,
when all of the bugs have been fixed and it's as stable as the older
LLVM versions.

Also, please note that I'm not speaking as an "end user" here. I'm just
a Debian maintainer with some interest on QA issues.

Thanks.



Bug#816980: [Pkg-julia-devel] Bug#816980: julia: FTBFS in testing (signal (11): Segmentation fault)

2016-04-25 Thread Tony Kelman
Probably because the Debian build isn't using the stable, tested,
recommended and supported version of LLVM for that branch of Julia. LLVM
makes significant breaking changes to all of their API's between minor
versions, so removing old versions from Debian means downstream users of
LLVM end up broken or with serious performance and memory regressions.
On Apr 25, 2016 9:10 AM, "Viral Shah"  wrote:

> I routinely build Julia on my 8GB Macbook Pro, and it comfortably builds
> with a bunch of other stuff running.
>
> Tony, Elliot - either of you have any ideas?
>
> -viral
>
>
>
> > On 25-Apr-2016, at 8:17 PM, Santiago Vila  wrote:
> >
> > severity 816980 serious
> > thanks
> >
> > I rented a virtual machine with 16 GB RAM and 16 GB swap.
> > It failed again. The build log is attached.
> >
> > While it was working, "top" showed this:
> >
> >  PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+
> COMMAND
> > 8453 sanvila   20   0 9209844 504260  66120 R  99.7  6.2   2:42.93 julia
> > 8677 sanvila   20   0 9002012 272516  62216 R 100.3  3.3   0:54.40 julia
> > 7954 sanvila   20   0 9105584 163172  56504 S   0.0  2.0   0:09.03 julia
> >
> > Do I need 27 GB of RAM to build this now?
> >
> > If not: How much swap do I need, why does julia overcommit so much,
> > and why this didn't happen in version 0.3.11 or 0.3.12?
> >
> >
> Thanks.___
> > Pkg-julia-devel mailing list
> > pkg-julia-de...@lists.alioth.debian.org
> > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-julia-devel
>
>


Bug#816980: [Pkg-julia-devel] Bug#816980: julia: FTBFS in testing (signal (11): Segmentation fault)

2016-04-25 Thread Viral Shah
I routinely build Julia on my 8GB Macbook Pro, and it comfortably builds with a 
bunch of other stuff running. 

Tony, Elliot - either of you have any ideas?

-viral



> On 25-Apr-2016, at 8:17 PM, Santiago Vila  wrote:
> 
> severity 816980 serious
> thanks
> 
> I rented a virtual machine with 16 GB RAM and 16 GB swap.
> It failed again. The build log is attached.
> 
> While it was working, "top" showed this:
> 
>  PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
> 8453 sanvila   20   0 9209844 504260  66120 R  99.7  6.2   2:42.93 julia
> 8677 sanvila   20   0 9002012 272516  62216 R 100.3  3.3   0:54.40 julia
> 7954 sanvila   20   0 9105584 163172  56504 S   0.0  2.0   0:09.03 julia
> 
> Do I need 27 GB of RAM to build this now?
> 
> If not: How much swap do I need, why does julia overcommit so much,
> and why this didn't happen in version 0.3.11 or 0.3.12?
> 
> Thanks.___
> Pkg-julia-devel mailing list
> pkg-julia-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-julia-devel