Julia
http://julialang.org/
Julia is a high-level, high-performance dynamic programming language for technical computing, with syntax that is familiar to users of other technical computing environments. It provides a sophisticated compiler, distributed parallel execution, numerical accuracy, and an extensive mathematical function library. The library, largely written in Julia itself, also integrates mature, best-of-breed C and Fortran libraries for linear algebra, random number generation, signal processing, and string processing.
- Devel package for openSUSE:Factory
-
4
derived packages
- Links to openSUSE:Factory / julia
- Has a link diff
- Download package
-
Checkout Package
osc -A https://api.opensuse.org checkout science/julia && cd $_ - Create Badge
Refresh
Refresh
Source Files (show unmerged sources)
| Filename | Size | Changed |
|---|---|---|
| UnicodeData.txt | 0001851767 1.77 MB | |
| _constraints | 0000000804 804 Bytes | |
| _multibuild | 0000000055 55 Bytes | |
| disable-doc-gen-in-makefile.patch | 0000000907 907 Bytes | |
| disable-download-of-unicode-for-doc-gen.patch | 0000000509 509 Bytes | |
| fix-dependencies-checksums.patch | 0000001822 1.78 KB | |
| julia-1.10.2-full.tar.gz | 0318584736 304 MB | |
| julia-1.10.2-full.tar.gz.asc | 0000000866 866 Bytes | |
| julia-env-script-interpreter.patch | 0000000370 370 Bytes | |
| julia-hardcoded-libs.patch | 0000003373 3.29 KB | |
| julia-libunwind-1.9.patch | 0000000750 750 Bytes | |
| julia-remove-libcholmod_cuda.patch | 0000001642 1.6 KB | |
| julia-rpmlintrc | 0000000635 635 Bytes | |
| julia.changes | 0000045289 44.2 KB | |
| julia.keyring | 0000003094 3.02 KB | |
| julia.spec | 0000023321 22.8 KB | |
|
libLLVM.v15.0.7.x86_64-linux-gnu-cxx11-llvm_versio |
0085634590 81.7 MB | |
| llvm-link-shared.patch | 0000001325 1.29 KB | |
| llvm-set-of-custom-patches.patch | 0000016202 15.8 KB | |
| new-pass-manager.patch | 0000013006 12.7 KB | |
| openlibm.patch | 0000000507 507 Bytes | |
|
support-float16-depending-on-llvm-and-platform.pat |
0000008279 8.08 KB | |
| use-newpm-asan.patch | 0000003838 3.75 KB |
Latest Revision
Soc Virnyl Estela (uncomfyhalomacro)
accepted
request 1170084
from
Soc Virnyl Estela (uncomfyhalomacro)
(revision 174)
- Update to version 1.10.2:
* JuliaSyntax.jl is now used as the default parser, providing better diagnostics and faster
parsing. Set environment variable `JULIA_USE_FLISP_PARSER` to `1` to switch back to the old
parser if necessary (and if you find this necessary, please file an issue).
* `⥺` (U+297A, `\leftarrowsubset`) and `⥷` (U+2977, `\leftarrowless`) may now be used as
binary operators with arrow precedence.
* When a task forks a child, the parent task's task-local RNG (random number
generator) is no longer affected. The seeding of child based on the parent
task also takes a more disciplined approach to collision resistance, using
a design based on the SplitMix and DotMix splittable RNG schemes.
* A new more-specific rule for methods resolves ambiguities containing Union{} in favor of
the method defined explicitly to handle the Union{} argument. This makes it possible to
define methods to explicitly handle Union{} without the ambiguities that commonly would
result previously. This also lets the runtime optimize certain method lookups in a way
that significantly improves load and inference times for heavily overloaded methods that
dispatch on Types (such as traits and constructors).
* The "h bar" `ℏ` (`\hslash` U+210F) character is now treated as equivalent to `ħ` (`\hbar` U+0127).
* The `@simd` macro now has more limited and clearer semantics: it only enables reordering and contraction
of floating-point operations, instead of turning on all "fastmath" optimizations.
If you observe performance regressions due to this change, you can
recover previous behavior with `@fastmath @simd`, if you are OK with
all the optimizations enabled by the `@fastmath` macro.
* When a method with keyword arguments is displayed in the stack trace view, the textual
representation of the keyword arguments' type is simplified using the new
`@Kwargs{key1::Type1, ...}` macro syntax.
* The mark phase of the garbage collector is now multi-threaded.
* [JITLink](https://llvm.org/docs/JITLink.html) is enabled by default on
Linux aarch64 when Julia is linked to LLVM 15 or later versions.
This should resolve many segmentation faults previously observed on this
platform.
* The precompilation process now uses pidfile locks and orchestrates
multiple julia processes to only have one process
spend effort precompiling while the others wait. Previously all would
do the work and race to overwrite the cache files.
* New option `--gcthreads` to set how many threads will be used by the
garbage collector.
The default is `N/2` where `N` is the number of worker threads
(`--threads`) used by Julia.
* SparseArrays and SuiteSparse are no longer included in the default system
image, so the core language no longer contains GPL libraries. However,
these libraries are still included alongside the language in the standard
binary distribution.
* `tanpi` is now defined. It computes tan(π*x) more accurately than
`tan(pi*x)`.
* `fourthroot(x)` is now defined in `Base.Math` and can be used to compute
the fourth root of `x`. It can also be accessed using the unicode
character `∜`, which can be typed by `\fourthroot<tab>`.
* `Libc.memmove`, `Libc.memset`, and `Libc.memcpy` are now defined, whose
functionality matches that of their respective C calls.
* `Base.isprecompiled(pkg::PkgId)` has been added, to identify whether a
package has already been precompiled.
* `binomial(x, k)` now supports non-integer `x`.
* A `CartesianIndex` is now treated as a "scalar" for broadcasting.
* `printstyled` now supports italic output.
* `parent` and `parentindices` support `SubString`s.
* `replace(string, pattern...)` now supports an optional `IO` argument to
write the output to a stream rather than returning a string.
* `startswith` now supports seekable `IO` streams.
* The `initialized=true` keyword assignment for `sortperm!` and
`partialsortperm!` is now a no-op. It previously exposed unsafe behavior.
* Printing integral `Rational`s will skip the denominator in `Rational`-typed
IO context (e.g. in arrays).
* `Pkg.precompile` now accepts `timing` as a keyword argument
which displays per package timing information for precompilation
(e.g. `Pkg.precompile(timing=true)`).
* `AbstractQ` no longer subtypes `AbstractMatrix`. Moreover,
`adjoint(Q::AbstractQ)` no longer wraps `Q` in an `Adjoint` type,
but instead in an `AdjointQ`, that itself subtypes `AbstractQ`. This
change accounts for the fact that typically `AbstractQ` instances
behave like function-based, matrix-backed linear operators, and
hence don't allow for efficient indexing. Also, many `AbstractQ`
types can act on vectors/matrices of different size, acting like a
matrix with context-dependent size. With this change, `AbstractQ`
has a well-defined API that is described in detail in the [Julia
documentation](https://docs.julialang.org/en/v1/stdlib/LinearAlgebra/#man-linalg-abstractq).
* Adjoints and transposes of `Factorization` objects are no longer wrapped
in `Adjoint` and `Transpose` wrappers, respectively. Instead, they are
wrapped in `AdjointFactorization` and `TranposeFactorization` types,
which themselves subtype `Factorization`.
* New functions `hermitianpart` and `hermitianpart!` for extracting the
Hermitian (real symmetric) part of a matrix.
* The `norm` of the adjoint or transpose of an `AbstractMatrix` now returns
the norm of the parent matrix by default, matching the current behaviour
for `AbstractVector`s.
* `eigen(A, B)` and `eigvals(A, B)`, where one of `A` or `B` is symmetric
or Hermitian, are now fully supported.
* `eigvals/eigen(A, cholesky(B))` now computes the generalized eigenvalues
(`eigen`: and eigenvectors) of `A` and `B` via Cholesky decomposition
for positive definite `B`. Note: The second argument is the output of
`cholesky`.
* Format specifiers now support dynamic width and precision, e.g. `%*s`
and `%*.*g`.
* When stack traces are printed, the printed depth of types in function
signatures will be limited
to avoid overly verbose output.
* The `@test_broken` macro (or `@test` with `broken=true`) now complains
if the test expression returns a non-boolean value in the same way as
a non-broken test.
* When a call to `@test` fails or errors inside a function, a larger
stacktrace is now printed such that the location of the test within a
`@testset` can be retrieved.
* `code_native` and `@code_native` now default to intel syntax instead
of AT&T.
* `@time_imports` now shows the timing of any module `__init__()`s that
are run.
* The `@pure` macro is now deprecated. Use `Base.@assume_effects :foldable` instead ([#48682]).
- Set Cmake version requirement to be at least 3.22
- Accommodate renaming dependencies in specfile.
- Disable jldownload by just running true
- Add fix-dependencies-checksums.patch
* Fix checksum checks for suitesparse aarch64. Sources are fetched from the same source.
* Fix checksum checks for libLLVM_jll
* It's checking for the checksums and it is also trying to fetch them from the internet
and idk what's the point of having the full julia tarball.
- Fix build
* use bundled suitesparse. comment out system suitesparse build requirement
* comment out openblas development dependencies. use bundled openblas.
* comment out lapack development dependencies. use bundled lapack.
* move openblas build away from the actual make build.
this ensures that it's installed properly because doing otherwise will
skip the install of the dependencies. weird but it works.
- Update specfile for bundled LLVM
- Add missing build requirements for bundled llvm 15
- Fix aarch64 build. it needs to download a source that can just be copied which is
SuiteSparse.v7.2.1+1.aarch64-linux-gnu.tar.gz
Comments 51
I think the project has to prefer libnghttp2-14 as the dependency?
This package is totally broken ATM. It bundles tons of system libraries (e.g. libgcc_1.so, libnghttp2) and breaks the complete science repository.
I have disabled the build for now, and purged all binaries.
Hi @StefanBruens,
Julia needs those libraries. It uses a JIT compiler that is tightly integrated with the system. Long time ago I tried to separate but it became impossible to manage old LLVM versions, for example, in openSUSE. If you use different, unsupported versions, you can have problems and very bad bugs. Julia must be shipped with those versions, it has been like this for ages here in openSUSE and in other distros as well. Thus, I have no idea why this is "breaking" science repo just now.
This problem has been introduced when updating to 1.6.0.
This package breaks the whole science repository (as I already told you), and would break Factory when submitted.
The package bundles libgcc_s (which is a system library), it bundles libnghttp2 (which is part of the curl) package, and these provides end up in the RPM packages. You make it impossible for the resolver to do its job, both on the OBS and at runtime.
If you don't believe me, check the "Details" section of the built packages. Or ask yourself why after building julia the whole science repo ends up with the "Have choice ..." dependency problem.
But it has always been like this... you can check, we always bundled LLVM for at least 4 years.
No, it has not - this has been introduced by the update to 1.6.0, probably by upstream changes.
libLLVM is actually ok here, as it is not named libLLVM, but libLLVM-9jl.so (note the "jl" suffix).
See https://build.opensuse.org/package/binary/openSUSE:Factory/julia/standard/x86_64/julia-1.5.2-1.5.x86_64.rpm for package Provides.
libgit2 is wrong, though not critical - system soversion is 1.1 (libgit2.so.1.1), while julia has libgit2.so.28, so currently there is no problem.
libopenlibm is a problem already with version 1.5.2, as julia provides libopenlibm.so.3(), which should only provided by the system package.
So you are saying that, for some reason, we cannot bundle any system library in a openSUSE package now?
I only see a problem with the libnghttp2.so.14 library until now, which was introduced in Julia 1.6.0. We just need to fix this and use the system version, since it seems to match the upstream version. It does not mean that the package is "totally broken".
Check again. Julia 1.6.0 provides libnghtttp2.so.14, libopenlibm.so.3, libgcc_1.so.
nghttp2 dependency was indeed introduced by 1.6.0. libopenlibm.so.3 was already provided in 1.5.2 and nobody pointed out any problem. libgcc_1.so I need to wait for the build to analyze.
Hence, since we already had libopenlibm.so.3 inside Julia without problem and now you are telling me that this is a problem, can we conclude that you are telling me that now we cannot have bundled system libraries in openSUSE packages?
Just because nobody has mentioned it does not mean it is no problem - it is.
Please build it julia in a branched repository and fix it there. There obviously is a problem with the package, and breaking the complete science repository is not acceptable.
I am building to figure out, but in my local repository it worked. I think I just need to tell RPM to do not provide those libraries. I haven't found any problem or guideline prohibiting to bundle libraries in openSUSE packages.
I will just ask, please, to inform me first instead of disabling everything without given the maintainer proper time to check the logs next time.
The build worked, but apparently you did not check the results.
I am repeating this for the 3rd time, you broke the whole science repository. This was the case for 3 days (as can be seen by the very first comment here). You have not acted, and now you have reenabled it without checking the results first. Your actions will cause another breakage as soon as the package has been built. Deleting the binary julia packages is the only way to unbreak the repository.
But how am I suppose to know what happen if, when you disabled the builds and deleted the files, the logs were also deleted? You just said "It bundles tons of system libraries (e.g. libgcc_1.so, libnghttp2) and breaks the complete science repository." I needed to reenable to see the problem and fix it.
Again, your actions were not friendly. A simple: "@Ronis_BR we have a problem, it seems that Julia 1.6.0 is interfering with the entire repo. Can you check out please?" I would verify the conflict and would disabled the builds until a fix is found.
It is very different from: "this package is completely broken, I will disable everything".
You got a "we have a problem" three days ago.
There was no need to reenable the repository, rebuilding it in a branch suffices.
No, I had a comment "I think the project has to prefer libnghttp2-14 as the dependency?". This is a work I do for free in my spare time. If I do not receive a message saying "Hey! Look, a big problem", then I will just look when I have time, which can take more than 3 days.
One more time, you were not friendly. In this package, please, next time just ping me telling that we have a problem. If you are not happy with this, you are my guest to take over the maintenance of Julia.
You broke the repository for everyone, users and all other maintainers here - so a lot of other persons who also do the work for free.
You could have checked the results from the pending SR, to verify the problems. Instead you kept repeating "this package is fine", apparently without checking any of the raised concerns.
And how long should I have waited for any actions on your side? The broken repository state blocked all work in this repository, hindering everyone else here.
I did not keep repeating "This package is fine", meaning that no problem was occurring, but "I have been bundling LLVM and many system libraries since forever". YOU, on the other hand, said that this package is "completely broken".
I even wrote: "Thus, I have no idea why this is "breaking" science repo just now." I did not deny that a problem exist, just that the package as it is (with a lot of libraries bundled) has been like this for a long time.
Again, you told me that the package was broken because it is bundling system libraries, which is not true. It is a specific new bundled system library that is causing the problem, which I would have identified 10,000x faster if you had let me just analyze the logs.
Again, and for the last time: in this package, next time, tell me that something is wrong and I will fix it. If, for any specific reason, I do not respond fast (which I did today), then you can take actions. If you do not accept this, then ask for the maintenance role.
I have re-enabled the builds until anyone really point me out a problem. Again, Julia package has been like this for ages, and it must be like this. It is a computing language and we must use only supported libraries versions with the upstream patched when applicable.
And, by the way, if the openSUSE policy has changed (last time I checked I could bundle libraries if I want to), then you can completely delete this package and remove Julia from openSUSE. It is virtually impossible to maintain Julia without using those supported versions. It will lead to a ton of bugs, as we have verified in the past.
Hi @StefanBruens,
I think we are safe now. If you look at the binary created in my repo:
https://build.opensuse.org/package/binary/home:Ronis_BR/julia/openSUSE_Tumbleweed/x86_64/julia-1.6.0-112.1.x86_64.rpm
then you will see that even with a lot of bundled system libraries, RPM is not considering them as provided by Julia package. This should solve all the problems. Locally, Julia is working fine also, so no drawbacks up to now. If everything went wrong with those dependencies, let me know please.
I created a small bash script to download julia from release-1.6 branch and the libraries strictly needed by it (they check also sha1 or md5 of the files besides the repository revision, what complicate things a bit). Overall, the size of the package is greatly reduced as is also the time to build it (unluckily, had no success to build it against a standard system llvm).
May you be interested, let me know.
Regards, André
is there any plan to update this software to latest stable?
Yes! I am just waiting for 1.8.0 be released. 1.7 cannot build agains the current openSUSE tools... Sorry about that!
Hi,
Julia 1.8.1 is released by Sept. 6, could you update this repository for openSUSE TW?
Sincerely,
Hi!
I am really trying, but for some reason I am having build failures when using OBS (locally). I can build julia inside my machine using TW but not in OBS. I have no clue what is going on.
Maybe we can retire this package now that juliaup exists. My other reason would be that it is hard to maintain this package as well. Also, in the julia community, we really do not recommend using built binaries since the ones built upstream contains patches for LLVM and other dependencies for Julia to work properly. Not sure if that's what you want but this package has not been updated for a while due to weird build failures as you mentioned.
Sorry, but juliaup is no replacement for a julia built using the libraries available for the respective system. It works in a lot of cases, but no always. As an example try to run the GR surface plot example using the julia version installed using juliaup. At least on my system, it crashes because of unsatisfied references whereas it works using my locally compiled version. I'm using TW.
I didn't try to compile julia in OBS, because I don't know enough about rpm and OBS, but I think it would be good, if Ronis_BR could make his failed attempts somehow public, so people more experienced than me can have a look.
I will take a look next week to see what i can do for this. since there are two packages that provide julia, i will probably check if it is possible to add the
update-alternativeson the spec for both of these packages.@Ronis_BR I will branch this and check if I can build this package.
@GNE as long as you built julia with the necessary patchsets to LLVM, you should be fine, we don't really recommend it though if it's just vanilla LLVM. I have seen some issues with it in ArchLinux and the solution was to use Julia's binary from their download's page since that contain patchsets for Julia to work properly.
Hi! Sorry for the delay!
Please, go ahead. Any help is appreciated! I will add you as a maintainer of this package.
I tried a lot, but the build process always failed in OBS during the sysimg creation. My attempts were based on using more bundled libraries instead of linking them to the ones in openSUSE.
Since we are using Julia for sensitive applications, I could not use the repository version anymore because I have never been able to make all tests pass. Hence, I needed to download the binary version from julialang.org.
Currently, I have time to perform some minor maintenance, but I no longer have time to solve those significant issues.
Thanks for the help!
By the way, we have not been using the openSUSE LLVM for a long time. I think somewhere between Julia 0.4 or 0.7, I needed to bundled LLVM due to significant version mismatch between the supported version and Tumbleweed.
I really suggest keeping the LLVM bundled because it will break when Tumbleweed upgrade to a newer version that is not supported by Julia. This scenario happened many times in the past. Since it is not easy to install two versions of LLVM, it is easier and safer to bundle it, IMHO.
Seems to me that it really is hard to package Julia. I have a feeling I should start from scratch and take it from there. Anyone can still use
juliaupfor the time being for convenience or download from the website. Personal life has caught up to me so updating julia won't happen anytime soon-ish unless someone helps.I have been trying to build julia-1.8.5 under leap-15.4. There are a couple of block points I've struck: - It is not possible to build julia against system llvm13, as it needs libLLVMDemangle and nothing provides it on SUSE; - It, for some reason, can't find some libraries that reside under /lib, as a workaround, I did place links to them inside the libraries build directory; - In my experience, some libraries that julia regular building process patches, are better left outside of USE_SYSTEM*; - It needs -DSUN64, so that functions that use huge indexes can coexist with others that use 32 bit ones (see https://github.com/Reference-LAPACK/lapack/issues/666). It means that many libraries must be build with this flag (at least openBLAS and suitesparse, but probably others will need to be build with it too); - No matter how much I tried, downloads happen under building process, what is quite annoying.
On coming days I will clone the current version, make the changes and submit a request. There are, still, some tests that didn't complete but, maybe, the effort can be properly shared.
I am checking out how Fedora does it. but for now I don't have time to do it because I have other things to do in school 😅
OK, had success building julia-1.8.5.
Now, the problem is, as I said on previous post, SUSE has to have openBLAS built with INTERFACE64=1 and a special version of SuiteSparse linked against it. This means to have a proper library name convention on place.
I inserted a definition i64 for that in openblas.spec: %if "%{?index64:defined}" == "" %global i64 %nil %else %global i64 64 %endif
and, on many places, modified the packages names to be:
lib%{name}%{?so_v}%{?i64:_%{i64}}
or
lib%{name}%{i64}-devel
So, this is what is missing, define what package names (and libraries and include directories) will be.
Regards, André
@StefanBruens what do you think of this approach? I remembered that bundling system libraries broke the science repository last time
The only sane approach is to build OpenBLAS with
INTERFACE64=1andSYMBOLSUFFIX=64_, and provide this as an additional variant.Otherwise, you end up with a BLAS library with potentially different calling convention for the same symbols, which breaks miserably when two dependent libraries refer to these symbols, one using 32bit indexes, the other 64bit indexes.
Yes, but we still have to have a name that follow SUSE conventions, this is the input I would like to get.
On a proto package I generated, I renamed openblas.pc to openblas64.pc and openBLASconfig.cmake had its path adjusted.
Same considerations should be done about libopenblas.so and libopenblas_openmp.so. Would the resulting names be libopenblas_64.so and libopenblas_openmp_64.so?
Some of the libraries were a bit more laborious to adjust, and I had to patch their building process, but seems to be fine now. Also, needed to fix the rpm .spec files.
Now, as a last decision, would be nice to establish what will be used for library suffix and include files (mainly).
My suggestion is to put them under "%{_libdir}/ilp64" and "%{_includedir}/ilp64". Even though this simple steps seem to fix most of the problems, I had an error while building SuiteSparse and it's mongoose library picking the installed regular Suitesparse suitesparseconfig, so, I suggest really adding _ilp64 to libraries to prevent this kind of error, or others that could arise from using just the regular names and risk ld picking the wrong library.
Suggestions?
have you asked some help in julia slack or in julia zulip?
also thanks for giving your time to improve the spec for julia and find ways to fix the build issues. i was too busy with personal stuff and maintain other packages on some devel projects at OBS, thus, i really can't help much here.
Did all of the adjustments on my computer. Will check the above projects to see if they have some suggestions. It would be wise to talk with Fedora maintainers also, just to have some common basic location settings to easy the testing done by upstream developers.
yes i think it's a good idea to ask for advice/help from fedora. it seems they have packaged julia like this https://src.fedoraproject.org/rpms/julia/blob/rawhide/f/julia.spec
I will check if I am able to.
This is my third attempt of updating julia to 1.9.4 https://build.opensuse.org/package/show/home:uncomfyhalomacro:branches:science/julia
however, it seems it's a lot difficult and may even be worthless effort in the end as noted in the arch wiki https://wiki.archlinux.org/title/Julia.
I will give time and probably request for deletion. The only other alternative of this is for users to use juliaup.
Unless someone steps up, I will request for its deletion within a week.
Afaik @Ronis_BR has abandoned the maintenance of this package and understandably so. Hopefully, even after its deletion, juliaup will satisfy the users.
Well it's successful :) so no deletion but imma put a warning
Hi @uncomfyhalomacro!
Thanks for your contribution! It would be nice to have Julia again in openSUSE repos. I had to abandon because it was taking a lot of time to make things works at each new release. Some people in openSUSE did not like the idea to bundle everything (like Fedora does, AFAIK), which was my only idea to make things work at that time.
Well it will be the same. In a separate branch, I will be using bundled library of LLVM. So if merged, there will only be two bundled libraries: LLVM and libuv.
LLVM and libuv are important since these are the only two that seem to affect numerical correctness whereas the former is the most important of them all since using system LLVM can affect Julia packages such as Sundials.jl
@Ronis_BR juliaup and julia are now enabled as
update-alternatives. Going to experiment tomorrow if it still works.still broken. need to know why libLLVM-14jl.so is missing
just need to add INTERFACE_64=1 to openblas in opensuse hmm
EDIT: not needed. lolz
I guess the only way for this package to work correctly is to bundle suitesparse as well.