Bug#816980: [Pkg-julia-devel] Bug#816980: julia: FTBFS in testing
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
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
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)
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)
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)
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 Vilawrote: > > 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