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 .. 10 11 12 13 14 15 16 17 18 19 20 21 Next › Last »

TrialnError commented on 2013-03-29 19:23 (UTC)

Right.. Didn't thought about -Qo But I'm still somewhat in doubt. Julia links specially to it's own version (openlibm) Project summary: A high quality independent libm implementation when one is not sure of the system libm. And until now I don't know if they provide the same, or if there are differences, that can break everything. Do you know more about it? Building went fine though. And Extras are compiled into libopenlibm-extras.so. No issues with simple testcases Hrm.. I will change it.

Archetyp commented on 2013-03-29 14:30 (UTC)

You are right about the libuv, I just had the impression that the sentence "If you already have one or more of these packages installed on your system, it is possible to pass USE_SYSTEM_...=1 to make to prevent Julia from compiling duplicates of these libraries." includes also libuv as it is in the list. But apparently not :D About the libm: $ pacman -Qo /lib/libm.so /lib/libm.so is owned by glibc 2.17-3 So this should be fine :)

TrialnError commented on 2013-03-28 01:45 (UTC)

Looked at libuv. The biggest argument against adding it, is the fact, that the package installs a specific version. As long as julia pulls from master and not a specific tag/version it could be better, that libuv is also pulled from master Edit: And if there would exist an USE_SYSTEM_LIBUV Flag

TrialnError commented on 2013-03-28 01:16 (UTC)

Duh, right *cough* I tend to forget adding or removing deps, thanks Last time I checked, libuv didn't exist in AUR.. Nice But I'll wait. Julia forked it, so it's necessary to look if the commits are somewhat the same. So long, I won't add it As for libm. It was recently added to julia as a dep and they point to one of their repos (openlibm) pacman -Ss libm cower -s libm didn't provide me a package named libm, so I assumed it's not in the repos or on AUR. I would appreciate it, if you can point me to a package ;)

Archetyp commented on 2013-03-26 13:38 (UTC)

Probably suitesparse should now be removed from the deps array. And, for consistency, would not be better to add libuv to deps as we have that package in AUR already?:D Also, why the change of USE_SYSTEM_LIBM so we don't use the system one anymore?:D About the provides, I would not add them as they all sit in /usr/lib/julia so they won't conflict if you install those packages normally :D

TrialnError commented on 2013-03-25 17:58 (UTC)

Little update. Removed some USE_System lines (nginx and lighthttp were dropped) and changed suitesparse to 0, so Julia will create it's own version. Concerning suitesparse this mail says enough: https://mailman.archlinux.org/pipermail/arch-dev-public/2013-March/024561.html Not sure if I should add a few things to provide (suitesparse, libm, libuv) If someone is testing Pacman 4.1rc1 and need a PKGBuild. You will find one there: https://github.com/Narrat/aur-julia-lang/blob/master/PKGBUILD

TrialnError commented on 2013-03-20 13:02 (UTC)

No, I stumbled on it too. (Although it worked before) But one correction. The script didn't search them locally. If you invoked the pkgbuild via makepkg and you had changed the the 1 to 0, the build process itself made again those .so files. So it's just necessary to change the 1 to 0 :) And still right, that it is easily fixed. But I have a problem with that. I have suitesparse installed via octave and now I've got this package and julia provides suitesparse too. Not clean. Until I get an answer the 1 will remain. And as it is easily fixed everyone can do it (at least if they read our comments), therefore I'll wait at the moment

« First ‹ Previous 1 .. 10 11 12 13 14 15 16 17 18 19 20 21 Next › Last »