Package Details: julia-git 1.10.2.r55077.gbd47eca2c8a-1

Git Clone URL: https://aur.archlinux.org/julia-git.git (read-only, click to copy)
Package Base: julia-git
Description: High-level, high-performance, dynamic programming language
Upstream URL: https://julialang.org/
Licenses: MIT
Conflicts: julia
Provides: julia
Submitter: mihi
Maintainer: TrialnError (fusion809, mar)
Last Packager: TrialnError
Votes: 54
Popularity: 0.82
First Submitted: 2012-02-22 08:57 (UTC)
Last Updated: 2024-03-14 22:09 (UTC)

Required by (19)

Sources (7)

Latest Comments

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

mokasin commented on 2013-11-25 21:26 (UTC)

Is there any reason why librmath is exclusivly needed? Or would the r package also suffice? Because librmath conflicts with r.

TrialnError commented on 2013-10-31 01:20 (UTC)

I introduced a patch file with this update. It was in my opinion necessary. Although the SYSCONFDIR var was added I needed to write in package() SYSCONFDIR=$pkgdir/etc which resulted into following warning "WARNING: Package contains reference to $pkgdir" in the final package. So I decided to introduce DESTDIR so I could split it. And it looks more sane now. And static libs are added back to the package In the previous update I removed some of the makedeps as they're part of base and base-devel.

maxbaroi commented on 2013-10-16 17:05 (UTC)

@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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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.

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