Edit Package julia

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.

Refresh
Refresh
Source Files (show merged sources derived from linked package)
Filename Size Changed
_constraints 0000000277 277 Bytes over 1 year
_multibuild 0000000055 55 Bytes over 1 year
julia-1.6.2-full.tar.gz 0153647142 147 MB about 2 months
julia-env-script-interpreter.patch 0000000329 329 Bytes almost 2 years
julia-fix-mbedtls-build-failure-gcc-11.patch 0000015032 14.7 KB about 2 months
julia-fix_doc_build.patch 0000000854 854 Bytes 5 months
julia-rpmlintrc 0000000119 119 Bytes 6 months
julia.changes 0000022566 22 KB about 2 months
julia.spec 0000011577 11.3 KB about 2 months
juliabuildopts 0000000891 891 Bytes 5 months
Comments for julia 23

kh Lai's avatar

dlshcbmuipmam wrote 6 months ago

I think the project has to prefer libnghttp2-14 as the dependency?


Stefan Brüns's avatar

StefanBruens wrote 5 months ago

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.


Ronan Chagas's avatar

Ronis_BR wrote 5 months ago

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.


Stefan Brüns's avatar

StefanBruens wrote 5 months ago

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.


Ronan Chagas's avatar

Ronis_BR wrote 5 months ago

But it has always been like this... you can check, we always bundled LLVM for at least 4 years.


Stefan Brüns's avatar

StefanBruens wrote 5 months ago

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.


Ronan Chagas's avatar

Ronis_BR wrote 5 months ago

So you are saying that, for some reason, we cannot bundle any system library in a openSUSE package now?


Ronan Chagas's avatar

Ronis_BR wrote 5 months ago

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".


Stefan Brüns's avatar

StefanBruens wrote 5 months ago

Check again. Julia 1.6.0 provides libnghtttp2.so.14, libopenlibm.so.3, libgcc_1.so.


Ronan Chagas's avatar

Ronis_BR wrote 5 months ago

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.


Ronan Chagas's avatar

Ronis_BR wrote 5 months ago

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?


Stefan Brüns's avatar

StefanBruens wrote 5 months ago

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.


Ronan Chagas's avatar

Ronis_BR wrote 5 months ago

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.


Stefan Brüns's avatar

StefanBruens wrote 5 months ago

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.


Ronan Chagas's avatar

Ronis_BR wrote 5 months ago

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".


Stefan Brüns's avatar

StefanBruens wrote 5 months ago

You got a "we have a problem" three days ago.

There was no need to reenable the repository, rebuilding it in a branch suffices.


Ronan Chagas's avatar

Ronis_BR wrote 5 months ago

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.


Stefan Brüns's avatar

StefanBruens wrote 5 months ago

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.


Ronan Chagas's avatar

Ronis_BR wrote 5 months ago

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.


Ronan Chagas's avatar

Ronis_BR wrote 5 months ago

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.


Ronan Chagas's avatar

Ronis_BR wrote 5 months ago

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.


Ronan Chagas's avatar

Ronis_BR wrote 5 months ago

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.


Andre Barros's avatar

acobar wrote 5 months ago

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é

openSUSE Build Service is sponsored by