Package Base Details: julia-git

Git Clone URL: https://aur.archlinux.org/julia-git.git (read-only)
Submitter: mihi
Maintainer: TrialnError
Last Packager: TrialnError
Votes: 52
Popularity: 0.093884
First Submitted: 2012-02-22 08:57
Last Updated: 2019-05-22 21:58

Packages (2)

Latest Comments

« First ‹ Previous ... 6 7 8 9 10 11 12 13 14 15 16 ... Next › Last »

maxbaroi commented on 2013-10-16 17:05

@gh02t

I was having a similar problem. I kept receiving a connection timed out error from github. My problem was the PKGBUILD was fetching from github over the git:// protocol and the firewall I was behind was blocking that port.

It worked fine when I fetched over the https protocol. I don't know how to mess around with the PKGBUILD file to correct this sort of problem. So instead I used a kludge by changing my git settings.

$ git config --global url."https://".insteadOf git://
will configure git to use the https protocol whenever asked to use the git protocol. I don't think it's particularly good solution, but it works and should solve similar problems for other packages.

gh02t commented on 2013-08-06 23:16

It seems to be something particular to my system. I've been talking with the devs on Github. Julia builds fine for me on a different system. I'll post back here if we ever figure out what's going on.

TrialnError commented on 2013-08-06 23:11

I had no problems yesterday to built the package.
Did you have the old src/ directory in place?

TrialnError commented on 2013-08-06 23:11

I had no problems yesterday to built the package.
Did you have the old src/ directory in place?

gh02t commented on 2013-07-31 21:17

Hmm... I'm seeing the exact same error as this guy http://comments.gmane.org/gmane.comp.lang.julia.devel/11000 . The poster mentions that the issue was fixed, but it doesn't seem that way to me.

TrialnError commented on 2013-07-04 19:08

I had previously an extra entry, which shouldn't be necessary. As on x686 systems it defaults to USE_BLAS64=0

What did I change?
eijnuhs suggested two ways to handle that. I will add a third one.

But as for this PKGBuild I think it's the easiest way to disable the use of the 64bit libs of blas. As this works with blas from [extra] too, I didn't change the dep. So it's not necessary to install openblas from AUR.

What are the other ways? If you really need the capabilities and benefits that come with 64bit.

Stick to point 2 made by eijnuhs:
"2) Edit openblas PKGBUILD from AUR to include 8byte integer support
With 2), under build(), just add INTERFACE64=1 to make to compile with 8byte integer support."

or use ABS and change the blas package to activate the 8byte support:
Get lapack from abs and add a prepare() function which changes the following: https://www.gnu.org/software/octave/doc/interpreter/Compiling-Octave-with-64_002dbit-Indexing.html (see point blas and lapack)
Maybe it's possible to add those as cmake-flags, but I don't know cmake that well.

TrialnError commented on 2013-07-04 18:36

Please disregard the previous comment. It seems I tend to overcomplicate things :D

TrialnError commented on 2013-07-04 18:10

I will go with the disabling of the 64bit libs for the time being
But I dunno if my construct works. Could someone test it, please?

http://pastie.org/8110519

snowball commented on 2013-07-04 06:06

TrialnError, I can confirm the issue fhs mentioned on x86_64 as well, using blas from extra.

Anonymous comment on 2013-07-03 18:40

Hi again, here's an update.
I force an reinstall of openblas with 64 bit integer support.
This remedies the problem.

So any user can either
1) Install openblas from AUR but set USE_BLAS64=0 in Julia
2) Edit openblas PKGBUILD from AUR to include 8byte integer support
With 2), under build(), just add INTERFACE64=1 to make to compile with 8byte integer support.