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#807701: [Pkg-julia-devel] Bug#807701: Bug#807701: julia: FTBFS on arm64

[Viral Shah]

We are not happy about the fork either. We had to add a few things to libuv
that have not been upstreamed for a variety of reasons.

Copying others too since this is an oft discussed topic.

-viral
On 12 Dec 2015 11:03 a.m., "Peter Colberg"  wrote:

> On Fri, Dec 11, 2015 at 06:36:09PM +, Edmund Grimley Evans wrote:
> > It failed to build on arm64:
> >
> > https://buildd.debian.org/status/package.php?p=julia=sid
> >
> > The error was:
> >
> > signal (6): Aborted
> > gsignal at /lib/aarch64-linux-gnu/libc.so.6 (unknown line)
> > Aborted
> >
> > The problem seems to be that there is no system call epoll_wait on
> > arm64, only epoll_pwait, so you need a patch like this:
>
> Edmund, thanks for pointing out the exact cause of the FTBFS.
>
> The issue has been fixed with libuv commit 1d8332f, which takes
> a slightly different approach by calling either uv__epoll_wait
> or uv__epoll_pwait, depending on availability [1].
>
> [1] https://github.com/libuv/libuv/pull/308
>
> This bug would have been avoided if Julia had not forked libuv
> without keeping it up to date :-(. I will forward the issue to
> the Julia maintainers and hopefully motivate them to switch to
> upstream libuv sooner than later.
>
> Regards,
> 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#803644: [Pkg-julia-devel] Bug#803644: src:julia: Please switch to llvm 3.6

[Viral Shah]

We are in the process of moving to 3.7.

-viral
On 1 Nov 2015 6:21 p.m., "Sylvestre Ledru"  wrote:

> Package: src:julia
> Severity: normal
>
> Hello,
>
> We would like to remove llvm-toolchain-3.5 from the archive.
>
> Please switch to llvm 3.6 (or, better, 3.7).
>
> Thanks,
> Sylvestre
>
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (900, 'testing'), (600, 'unstable'), (500,
> 'oldstable-updates'), (500, 'oldstable'), (300, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.1.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> ___
> 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#799036: [Pkg-julia-devel] Bug#799036: Bug#799036: Bug#799036: openspecfun: please build everywhere

[Viral Shah]

I would be ok with that too. The rem_pio2 is just thrown in there for 
convenience - it should be removed eventually.

-viral



> On 17-Sep-2015, at 10:06 pm, Graham Inggs  wrote:
> 
> On 17/09/2015 17:38, Sébastien Villemot wrote:
>> I don't understand why this would be better. It seems to me that it
>> would just eat buildd resources, with no clear benefit… Or am I missing
>> something?
> 
> In my opinion, restricting architectures is hiding the problem.
> 
> In the case of openspecfun, it builds in seconds (even on ARM) so wouldn't be 
> much of a burden on the buildds.
> 
> If the build logs show a failure, it may attract the attention of someone 
> with an interest in that architecture and the problem could get fixed.
> 
> ___
> 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#799099: [Pkg-julia-devel] Bug#799099: Bug#799099: julia: please drop build-depends on patchelf

[Viral Shah]

We should probably migrate this patch upstream (into the Julia project), to be 
default for those architectures.

-viral



> On 16-Sep-2015, at 2:48 am, Graham Inggs  wrote:
> 
> Hi Elliot
> 
> On 15 September 2015 at 23:12, Elliot Saba  wrote:
>> Graham, without setting `USE_SYSTEM_PATCHELF=1`, I believe the Makefiles
>> will still attempt to download and install `patchelf`.
> 
> That is correct.  I made this change in debian/rules, see 'no-patchelf.diff'.
> I split the patches up so that 'upstream-use-system-patchelf.patch'
> can be dropped when 0.4.0 is released.
> 
> Regards
> Graham
> 
> ___
> 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#799036: [Pkg-julia-devel] Bug#799036: Bug#799036: openspecfun: please build everywhere

[Viral Shah]

Yes, we should restrict. Arm should be possible shortly. We really should
move the rem_pio2 to Julia so that this restriction can be lifted.

-viral
On 17 Sep 2015 2:21 am, "Sébastien Villemot"  wrote:

> Le mardi 15 septembre 2015 à 08:50 +0200, Graham Inggs a écrit :
> > Source: openspecfun
> > Version: 0.4-1
>
> > Please do not restrict openspecfun to i386 and amd64.
> > It built on all architectures in Ubuntu [1].
>
> It builds, but I am not sure it works. There is some low level stuff in
> the rem_pio2/ directory. For example, in rem_pio2/fpmath.h, there is
> this comment: "Currently assumes Intel platform", followed by an
> alternative that seems to assume either amd64 or i386.
>
> Viral, Eliott, what's your take on this? Does it make sense to compile
> openspecfun on arches other than amd64 and i386?
>
> --
>  .''`.Sébastien Villemot
> : :' :Debian Developer
> `. `' http://sebastien.villemot.name
>   `-  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
>

Bug#776069: [Pkg-julia-devel] Bug#776069: Bug#776069: julia: 0.3.5 in experimental

[Viral Shah]

Given that Julia 0.3.x are largely bugfix releases - can't those make it
into Jessie?

I guess targeted bug fixes probably is much more restrictive.

-viral
On 24 Jan 2015 03:30, Sébastien Villemot sebast...@debian.org wrote:

 Le vendredi 23 janvier 2015 à 10:54 -0500, Viral Shah a écrit :
  I think it would be best to update to 0.3.5, or even 0.3.6 which will
  be released in a few weeks.
 
 
  Does the release policy allow us to update newer packages into
  experimental?

 Yes it's possible to upload 0.3.5 to experimental. But note that, by
 definition, packages in experimental never end up in a release of
 Debian. So Debian Jessie will ship with julia 0.3.2. Only targeted
 important bugfixes are allowed to get into Jessie by now, not new
 upstream releases.

 --
  .''`.Sébastien Villemot
 : :' :Debian Developer
 `. `' http://sebastien.villemot.name
   `-  GPG Key: 4096R/381A7594

Bug#776069: [Pkg-julia-devel] Bug#776069: julia: 0.3.5 in experimental

[Viral Shah]

I think it would be best to update to 0.3.5, or even 0.3.6 which will be
released in a few weeks.

Does the release policy allow us to update newer packages into experimental?

-viral

On Fri, Jan 23, 2015 at 10:20 AM, Peter Colberg pe...@colberg.org wrote:

 Package: julia
 Version: 0.3.2-1
 Severity: wishlist

 Dear Maintainer,

 When updating packages I receive the following warning:

   julia Pkg.update()
   INFO: Updating METADATA...
   INFO: Updating HDF5...
   INFO: Computing changes...
   WARNING: julia is fixed at 0.3.2 conflicting with requirement for HDF5:
 [0.3.4,∞)
   INFO: No packages to install, update or remove

 Since jessie is already frozen, what do think about uploading Julia 0.3.5
 to experimental to bridge the long time gap till the release of jessie?
 Let me know whether I could help with the preparation of the upload.

 Regards,
 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




-- 
-viral

Bug#758783: julia: does not start with -p option specified

[Viral Shah]

Do you still observe this behaviour with Julia 0.3?

-viral


On Thu, 21 Aug 2014 12:21:05 +0200 Frederik Beaujean beauj...@mpp.mpg.de 
wrote:
 Package: julia
 Version: 0.2.1+dfsg-3
 Severity: normal
 
 Dear Maintainer,
 
 I wanted to try the parallel capabilities of julia. Following the manual, I 
 tried to start it up as
 $ julia -p 2
 Master process (id 1) could not connect within 60.0 seconds.
 exiting.
 Master process (id 1) could not connect within 60.0 seconds.
 exiting.
 
 Master process (id 1) could not connect within 60.0 seconds.
 exiting.
 Master process (id 1) could not connect within 60.0 seconds.
 exiting.
 ^C
 
 The same happens even with one process
 $ julia -p 1
 Master process (id 1) could not connect within 60.0 seconds.
 exiting.
 Master process (id 1) could not connect within 60.0 seconds.
 exiting.
 Master process (id 1) could not connect within 60.0 seconds.
 exiting.
 ^C
 
 and I never get to do anything.
 
 To start julia at all, I had to use julia -f due to this outstanding bug 
 #755576
 
 bye
 
 Fred
 
 -- System Information:
 Debian Release: jessie/sid
   APT prefers testing-updates
   APT policy: (500, 'testing-updates'), (500, 'testing')
 Architecture: amd64 (x86_64)
 Foreign Architectures: i386
 
 Kernel: Linux 3.13-1-amd64 (SMP w/2 CPU cores)
 Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash
 
 Versions of packages julia depends on:
 ii  libamd2.3.11:4.2.1-3
 ii  libarpack2 3.1.5-3
 ii  libblas3 [libblas.so.3]1.2.20110419-7
 ii  libc6  2.19-7
 ii  libcamd2.3.1   1:4.2.1-3
 ii  libcholmod2.1.21:4.2.1-3
 ii  libcolamd2.8.0 1:4.2.1-3
 ii  libdouble-conversion1  2.0.1-1
 ii  libffi63.1-2
 ii  libfftw3-double3   3.3.4-1
 ii  libfftw3-single3   3.3.4-1


-viral


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

Bug#748573: Embedded code copy of libuv makes inconsistent use of _GNU_SOURCE

[Viral Shah]

With Julia 0.3 released, is this still an issue?

-viral

On Sun, 18 May 2014 16:28:24 +0100 Michael Tautschnig m...@debian.org wrote:
 Package: julia
 Version: 0.2.1+dfsg-3
 Usertags: goto-cc
 
 During a rebuild of all Debian packages in a clean sid chroot (using 
 cowbuilder
 and pbuilder) the build failed with the following error. Please note that we
 use our research compiler tool-chain (using tools from the cbmc package), 
 which
 permits extended reporting on type inconsistencies at link time.
 
 [...]
 libtool: link: gcc -shared  -fPIC -DPIC  src/.libs/libuv_la-fs-poll.o 
 src/.libs/libuv_la-inet.o src/.libs/libuv_la-uv-common.o 
 src/.libs/libuv_la-version.o src/unix/.libs/libuv_la-async.o 
 src/unix/.libs/libuv_la-core.o src/unix/.libs/libuv_la-dl.o 
 src/unix/.libs/libuv_la-fs.o src/unix/.libs/libuv_la-getaddrinfo.o 
 src/unix/.libs/libuv_la-loop-watcher.o src/unix/.libs/libuv_la-loop.o 
 src/unix/.libs/libuv_la-pipe.o src/unix/.libs/libuv_la-poll.o 
 src/unix/.libs/libuv_la-process.o src/unix/.libs/libuv_la-signal.o 
 src/unix/.libs/libuv_la-stream.o src/unix/.libs/libuv_la-tcp.o 
 src/unix/.libs/libuv_la-thread.o src/unix/.libs/libuv_la-threadpool.o 
 src/unix/.libs/libuv_la-timer.o src/unix/.libs/libuv_la-tty.o 
 src/unix/.libs/libuv_la-udp.o src/unix/.libs/libuv_la-linux-core.o 
 src/unix/.libs/libuv_la-linux-inotify.o 
 src/unix/.libs/libuv_la-linux-syscalls.o src/unix/.libs/libuv_la-proctitle.o  
  -lrt -lpthread -lnsl -ldl  -O2 -O2 -Wl,-z -Wl,relro   -Wl,-soname 
 -Wl,libuv.so.11 -o .libs/libuv.so.11.0.0
 file /usr/include/x86_64-linux-gnu/bits/socket2.h line 64: 
 
 error: conflicting function declarations recvfrom
 old definition in module fs-poll file 
 /usr/include/x86_64-linux-gnu/bits/socket2.h line 64
 signed long int (signed int __fd, void * restrict __buf, unsigned long int 
 __n, signed int __flags, struct sockaddr * restrict __addr, unsigned int * 
 restrict __addr_len)
 new definition in module linux-syscalls file 
 /usr/include/x86_64-linux-gnu/bits/socket2.h line 64
 signed long int (signed int __fd, void * restrict __buf, unsigned long int 
 __n, signed int __flags, union sockaddr __addr, unsigned int * restrict 
 __addr_len)
 Makefile:824: recipe for target 'libuv.la' failed
 make[6]: *** [libuv.la] Error 64
 make[6]: Leaving directory 
 '/srv/jenkins-slave/workspace/sid-goto-cc-julia/julia-0.2.1+dfsg/deps/libuv'
 Makefile:616: recipe for target 'all' failed
 
 This type conflict on parameter __addr is caused by an inconsistent use of
 #define _GNU_SOURCE, which is present in deps/libuv/src/unix/linux-syscalls.c,
 but not in deps/libuv/src/fs-poll.c.
 
 Obviously this is a problem of libuv rather than julia - hooray for embedded
 code copies. The packaged version in Debian does not suffer from the above
 problem.
 
 Best,
 Michael
 


-viral


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

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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#753971: [Pkg-julia-devel] Bug#753971: Bug#753971: julia: Please update the llvm dependency from 3.3 to 3.4 (or better, llvm-dev)

[Viral Shah]

Julia support for LLVM 3.4 is only experimental and we will probably go
directly to 3.5.

Is it an option to include 3.3 in the Julia package in that case?

-viral
On 6 Jul 2014 23:49, Sylvestre Ledru sylves...@debian.org wrote:

 On 07/07/2014 00:12, Sébastien Villemot wrote:
  Le dimanche 06 juillet 2014 à 23:55 +0200, Sébastien Villemot a écrit :
 
 
  Le dimanche 06 juillet 2014 à 19:39 +0200, Sylvestre Ledru a écrit :
  Source: julia
  Severity: important
  I would like to remove llvm-toolchain-3.3 from the archive ASAP.
  Could you switch to llvm-3.4-dev?
  Unfortunately upstream does not officially support LLVM 3.4 yet, not
  even for the latest development sources (it seems to compile, but there
  are issues, like https://github.com/JuliaLang/julia/issues/6369 ). For
  the current stable release (0.2) that is in sid, it is even worse, since
  julia FTBFS due to LLVM API changes.
 
  So at the very least I have to package a development snapshot. I need to
  get several new build dependencies through NEW, so it will take some
  time. Hopefully that will be done before the jessie freeze.
  Looking at https://github.com/JuliaLang/julia/issues/6757, it seems that
  even the next major release of Julia (0.3) will still require LLVM 3.3
  to be fully functional.
 
  Would that be acceptable for you to ship LLVM 3.3 in Jessie?
 
 Not really ... I am planning to ship with llvm 3.4  3.5.
 I don't want to third instance just for a single package.

 Sylvestre



 ___
 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#753971: [Pkg-julia-devel] Bug#753971: Bug#753971: Bug#753971: julia: Please update the llvm dependency from 3.3 to 3.4 (or better, llvm-dev)

[Viral Shah]

On 07-Jul-2014, at 1:02 am, Sylvestre Ledru sylves...@debian.org wrote:

 On 07/07/2014 09:10, Viral Shah wrote:
 Julia support for LLVM 3.4 is only experimental and we will probably go
 directly to 3.5.
 Do you have an eta on Julia-on-llvm-3.5 ? LLVM 3.5 branching is probably
 going to happen this week.

We are currently in our julia 0.3 release cycle, and just about to release 
0.3-rc1. We already have support llvm-3.5 svn, but the julia release that will 
use llvm 3.5 will be 0.4 is expected in December. LLVM 3.4 changed the APIs 
(MCJIT and such) and also had a bunch of bugs that made it difficult for us to 
use it. In fact we even have to apply patches to LLVM 3.3 (but can work around 
those bugs with slightly worse code generation in some cases, so that stock 
LLVM 3.3 can be used). Most of our patches are in 3.5, and we should be able to 
move to it for our next release.

 Is it an option to include 3.3 in the Julia package in that case?
 
 No. It had a maintenance burden on Debian that we don't want.

I really wish we can find a way.

-viral

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

Bug#730464: [Pkg-julia-devel] Bug#730464: julia: please build-depends on libunwind8-dev

[Viral Shah]

Even if julia builds on the other architectures - it is unlikely to work on 
those architectures unless LLVM supports them. In any case, we should certainly 
transition to libunwind8 if everything works out.

-viral



On 25-Nov-2013, at 3:50 pm, Aron Xu a...@debian.org wrote:

 Package: julia
 Version: 0.2.0+dfsg-4
 
 libunwind has an non-coordinated transition from libunwind7 to
 libunwind8, but julia builds fine when changing the build-depends from
 libunwind7-dev to libunwind8-dev, I suggest to make such a change.
 
 This also means allowing julia to be built on other architectures
 supported by libunwind:
 https://buildd.debian.org/status/package.php?p=julia
 https://buildd.debian.org/status/package.php?p=libunwind
 
 Thanks,
 Aron Xu
 
 ___
 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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#654845: closed by Sylvestre Ledru sylves...@debian.org (Re: Bug#654845: libarpack2: ARPACK should link against LAPACK 2.0, and not liblapack)

[Viral Shah]

For what it is worth, many of these patches are included here:

https://github.com/inducer/arpack

-viral



On Jan 11, 2012, at 9:18 PM, Debian Bug Tracking System wrote:

 This is an automatic notification regarding your Bug report
 which was filed against the libarpack2 package:
 
 #654845: libarpack2: ARPACK should link against LAPACK 2.0, and not liblapack
 
 It has been closed by Sylvestre Ledru sylves...@debian.org.
 
 Their explanation is attached below along with your original report.
 If this explanation is unsatisfactory and you have not received a
 better one in a separate message then please contact Sylvestre Ledru 
 sylves...@debian.org by
 replying to this email.
 
 
 -- 
 654845: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=654845
 Debian Bug Tracking System
 Contact ow...@bugs.debian.org with problems
 
 From: Sylvestre Ledru sylves...@debian.org
 Subject: Re: Bug#654845: libarpack2: ARPACK should link against LAPACK 2.0, 
 and not liblapack
 Date: January 11, 2012 9:15:22 PM GMT+05:30
 To: roucaries bastien roucaries.bastien+deb...@gmail.com
 Cc: 654845-d...@bugs.debian.org, Viral B. Shah vi...@mayin.org, 
 654...@bugs.debian.org, cont...@bugs.debian.org
 
 
 forcemerge 654845 315570
 thanks
 
 Le mercredi 11 janvier 2012 à 15:53 +0100, roucaries bastien a écrit :
 On Tue, Jan 10, 2012 at 10:18 PM, Sylvestre Ledru sylves...@debian.org 
 wrote:
 Le vendredi 06 janvier 2012 à 01:51 -0500, Viral B. Shah a écrit :
 Package: libarpack2
 Severity: important
 
 
 ARPACK needs to use LAPACK 2.0 for correctness. This will cause a
 conflict with liblapack upon which it depends. See this thread on the
 issue and a name mangling fix, so that LAPACK 2.0 routines can be used
 in ARPACK.
 I don't see the issue for now.
 Could you produce a sample which shows the issue ?
 
 Solved long time ago: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=315570
 
 Sylvain feel free to force-merge if I have understood correctly
 OK.
 
 Thanks for the information
 Sylvestre (and not Sylvain ;)
 
 
 
 
 
 
 
 From: Viral B. Shah vi...@mayin.org
 Subject: libarpack2: ARPACK should link against LAPACK 2.0, and not liblapack
 Date: January 6, 2012 12:21:27 PM GMT+05:30
 To: Debian Bug Tracking System sub...@bugs.debian.org
 
 
 Package: libarpack2
 Severity: important
 
 
 ARPACK needs to use LAPACK 2.0 for correctness. This will cause a
 conflict with liblapack upon which it depends. See this thread on the
 issue and a name mangling fix, so that LAPACK 2.0 routines can be used
 in ARPACK. The BLAS can be the standard one from the debian
 distribution.
 
 http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2011-July/215640.html
 
 -- System Information:
 Debian Release: 6.0.3
  APT prefers stable
  APT policy: (500, 'stable')
 Architecture: i386 (i686)
 
 Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores)
 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash
 
 Versions of packages libarpack2 depends on:
 ii  libatlas3gf-3dnow [liblapack. 3.6.0-22   Automatically Tuned Linear 
 Algebra
 ii  libblas3gf [libblas.so.3gf]   1.2-8  Basic Linear Algebra Reference 
 imp
 ii  libc6 2.11.2-10  Embedded GNU C Library: Shared 
 lib
 ii  libgfortran3  4.4.5-8Runtime library for GNU Fortran 
 ap
 ii  liblapack3gf [liblapack.so.3g 3.2.1-8library of linear algebra 
 routines
 pn  libopenmpi1.3 none (no description available)
 
 Versions of packages libarpack2 recommends:
 pn  atlas3-base   none (no description available)
 
 libarpack2 suggests no packages.
 
 
 
 




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

Bug#522482: RFP: pyamg -- Algebraic multigrid solvers

[Viral Shah]

Package: wnpp
Severity: RFP

The pyamg package provides a suite of multigrid solvers to be used in  
conjunction with scipy and numpy. Debian packages are available  
upstream. It would be nice to make this available in the repositories.


AMG is a multilevel technique for solving large-scale linear systems  
with optimal or near-optimal efficiency. Unlike geometric multigrid,  
AMG requires little or no geometric information about the underlying  
problem and develops a sequence of coarser grids directly from the  
input matrix. This feature is especially important for problems  
discretized on unstructured meshes and irregular grids.


http://code.google.com/p/pyamg/

-viral






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

Bug#522483: RFP: circuitscape -- Landscape ecology with circuit theory

[Viral Shah]

Package: circuitscape
Severity: RFP

Circuitscape is a tool written purely in python for landscape ecology.  
It uses algorithms from circuit theory to predict patterns of movement  
and gene flow. It depends on the following python packages: numpy,  
scipy, pyamg, wx, and PythonCard.


http://www.circuitscape.org

-viral








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