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

[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

Bug#820220: [Pkg-julia-devel] Bug#820220: Bug#820220: Bug#820220: Bug#820220: Bug#820220: Bug#820220: julia: FTBFS on armel/armhf

[Viral Shah]

LLVM 3.7.1 should have decent performance as we upstreamed various performance 
patches from the Julia project. However, we still have patches on top of llvm 
3.7.1 for getting acceptable performance. However, this is all on the julia 
master, and not julia 0.4.

-viral



> On 08-Apr-2016, at 9:31 PM, Peter Colberg  wrote:
> 
> On Fri, Apr 08, 2016 at 09:55:02PM +0200, Graham Inggs wrote:
>> On 8 April 2016 at 21:16, Emilio Pozuelo Monfort  wrote:
>>> Why did you switch to 3.8? The default in unstable is 3.6 and in 
>>> experimental is
>>> 3.7.
>> 
>> I understood there were severe performance regressions with Julia on
>> LLVM > 3.3 that were only fixed in 3.8.
> 
> The reason for switching to LLVM 3.8 was the abysmal performance
> of LLVM 3.7 on i386, and complete failure of LLVM 3.6 or earlier.
> 
> https://github.com/JuliaLang/julia/issues/14191
> 
> Peter
> 
> ___
> 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#755576: [Pkg-julia-devel] Bug#755576: Bug#755576: cannot open /etc/julia/juliarc.jl on startup (bug in abspath)

[Viral Shah]

Good point. pcre 8.31 is a hard requirement as of now. We should probably file 
the issue upstream, so that we can use a newer version of pcre.

-viral



On 22-Jul-2014, at 3:14 pm, Sébastien Villemot sebast...@debian.org wrote:

 Control: tags -1 + confirmed
 Control: severity -1 grave
 
 Hi Eric,
 
 Le mardi 22 juillet 2014 à 09:11 +0200, Eric Marsden a écrit :
 Package: julia
 Version: 0.2.1+dfsg-3
 Severity: serious
 
 When invoking julia, it prints the error message below and exits.
 
   ERROR: could not open file /tmp//tmp//etc/julia/juliarc.jl
 in include at boot.jl:238
 
 julia -f starts up OK.
 
 Experimenting a little, it seems that the bug is in the abspath
 function, which is called from load_juliarc in client.jl.
 
julia abspath(/foo)
/tmp//foo
 
 where /tmp is the CWD.
 
 Thanks for reporting this. I can confirm the bug. It is triggered by the
 upgrade of libpcre3, from version 1:8.31-5 to 1:8.35-2. Downgrading to
 libpcre3 1:8.31-5 solves the issue.
 
 At this stage, I don't know if this is an ABI break in libpcre3 (#755439
 looks like a possible candidate), or if it is related to the way Julia
 internally stores regular expressions in its LLVM bytecode image
 (sys.ji).
 
 -- 
 .''`.Sébastien Villemot
 : :' :Debian Developer
 `. `' http://www.dynare.org/sebastien
  `-  GPG Key: 4096R/381A7594
 
 ___
 Pkg-julia-devel mailing list
 pkg-julia-de...@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-julia-devel


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org