I'm working on it but there are lot of issues to tackle. 1.10 tests hang when building RPM so I will probably go directly to 1.11.

Does the "outdated" situation also explain the library links in Julia don't point correctly to the library so files in the parent /usr/lib64?  I get these broken links on Fedora 40 with Julia package julia-1.9.2-4.fc40.x86_64 and  suitesparse64_-7.6.0-1.fc40.x86_64 by running symlinks against the julia directory and grepping for dangling:

symlinks -rv /usr/lib64/julia/ | grep dangling

dangling: /usr/lib64/julia/libumfpack.so -> ../libumfpack64_.so.5
dangling: /usr/lib64/julia/libspqr.so -> ../libspqr64_.so.2
dangling: /usr/lib64/julia/libcamd.so -> ../libcamd64_.so.2
dangling: /usr/lib64/julia/libklu.so -> ../libklu64_.so.1
dangling: /usr/lib64/julia/libcolamd.so -> ../libcolamd64_.so.2
dangling: /usr/lib64/julia/libccolamd.so -> ../libccolamd64_.so.2
dangling: /usr/lib64/julia/libamd.so -> ../libamd64_.so.2
dangling: /usr/lib64/julia/libsuitesparseconfig.so -> ../libsuitesparseconfig64_.so.5
dangling: /usr/lib64/julia/librbio.so -> ../librbio64_.so.2
dangling: /usr/lib64/julia/libbtf.so -> ../libbtf64_.so.1
dangling: /usr/lib64/julia/libcholmod.so -> ../libcholmod64_.so.3
dangling: /usr/lib64/julia/libldl.so -> ../libldl64_.so.2

So the library versions in suitesparse64_-7.6.0-1.fc40.x86_64 are ahead of the so names in "julia-1.9.2-4.fc40.x86_64"

ls -l /usr/lib64/libumfpack* /usr/lib64/julia/libumfpack*
lrwxrwxrwx. 1 root root     21 Jan 19 19:00 /usr/lib64/julia/libumfpack.so -> ../libumfpack64_.so.5
lrwxrwxrwx. 1 root root     22 Jan 31 19:00 /usr/lib64/libumfpack64_.so.6 -> libumfpack64_.so.6.3.2
-rwxr-xr-x. 1 root root 767752 Jan 31 19:00 /usr/lib64/libumfpack64_.so.6.3.2

This is a general pattern for all those dangling links, in this case the "5" in julia is behind the "6" in /usr/lib64/

*** Bug 2276184 has been marked as a duplicate of this bug. ***

Yes, the package needs to be rebuilt but currently it fails and it's not trivial to fix.

*** Bug 2277771 has been marked as a duplicate of this bug. ***

FEDORA-2024-3f9b24f1ec (julia-1.11.0-0.beta1.fc40) has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-3f9b24f1ec

I've managed to build Julia 1.11.0-beta1, disabling some failing tests for now. Unfortunately I couldn't get 1.10 tests to work and 1.11 isn't released yet, but hopefully this beta stable enough already. Please test it!

FEDORA-2024-3f9b24f1ec has been pushed to the Fedora 40 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-3f9b24f1ec`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-3f9b24f1ec

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Thank you. However, I'm getting the same error that someone already reported on bodhi when trying to run julia:

ERROR: Unable to load dependent library /usr/bin/../lib64/julia/libjulia-codegen.so.1.11
Message:libLLVM-16jl.so: cannot open shared object file: No such file or directory

That is because one final library is mislinked

[root /usr/lib64/julia]# rpm -qa julia\*
julia-common-1.11.0-0.beta1.fc40.noarch
julia-1.11.0-0.beta1.fc40.x86_64

[root /usr/lib64/julia]# ls -l libLLVM-*so /usr/lib/libLLVM* /usr/lib64/libLLVM*
ls: cannot access '/usr/lib/libLLVM*': No such file or directory
lrwxrwxrwx. 1 root root        22 Apr 30 20:00  libLLVM-16jl.so -> ../lib/libLLVM-16jl.so
lrwxrwxrwx. 1 root root        15 Mar 10 20:00  /usr/lib64/libLLVM-18.so -> libLLVM.so.18.1
-rwxr-xr-x. 1 root root 118738216 Mar 10 20:00  /usr/lib64/libLLVM.so.18.1

the "../lib/libLLVM-16jl.so" need to be ../lib64/libLLVM-18.so"   where /usr/lib64/libLLVM-18.so is from package "llvm-libs"

rpm -qf /usr/lib64/libLLVM-18.so
llvm-libs-18.1.1-1.fc40.x86_64

FEDORA-2024-b87b0c2aa4 (julia-1.11.0-2.beta1.fc40) has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-b87b0c2aa4

Looking good now. Though I'm getting a lot of error messages regarding libcurl when using Julia's package manager. But that should probably be reported as a seperate issue (might be an upstream issue?)

Yeah, I saw that too. I thought I had fixed it before. I'll add libcurl as a dependency. But I also saw errors when trying to use SuiteSparse (e.g. SparseArrays), I need to sort this out.

swapping libcurl-minimal with the full libcurl package via dnf fixed the error messages for me. Will do some more testing of the package in the coming days.

FEDORA-2024-b87b0c2aa4 has been pushed to the Fedora 40 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-b87b0c2aa4`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-b87b0c2aa4

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2024-450662f67e (julia-1.11.0-5.beta1.fc40) has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-450662f67e

Should be fixed in the new build now (together with several other errors).

Thank you for your work! I guess we should leave this issue open until the package finally hits "Updates" to avoid more people reporting the Cholmod issue from 1.9.2?

FEDORA-2024-450662f67e has been pushed to the Fedora 40 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-450662f67e`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-450662f67e

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Yes, the issue will be closed automatically when the build moves from updates-testing to updates.

julia-1.11.0-5.beta1.fc40.x86_64  seems to fix the problem on Fedora 40

Is there any particular reason why the package is not even in updates-testing currently?

My last attempt created problems with LibCURL as Julia packages load the LTS version of OpenSSL while F40 uses a more recent version which conflicts with it (https://bodhi.fedoraproject.org/updates/FEDORA-2024-450662f67e#comment-3514471). Unfortunately to fix that I have to bundle libcurl, libssh2 and mbedTLS. I'm not too happy about that, especially given that these are security-sensitive libraries. At that point I'm not sure it still makes sense to build a Julia RPM (we also bundle GMP and a few smaller libraries at the moment). Maybe we'd better use the upstream binaries via a Flatpak package.

Orion: what do you think?

It will take me a bit to get up to speed on julia again.  How can I reproduce the curl/ssl issues with the rawhide version of julia (before the current curl fix attempt)?

With a project that's hostile to using system libraries, abandoning rpms and using a flatpack may be the only way to go.  Of course that doesn't really address security concerns, it just shifts the responsibility upstream for keeping components up to date.

(In reply to Orion Poplawski from comment #25)
> It will take me a bit to get up to speed on julia again.  How can I
> reproduce the curl/ssl issues with the rawhide version of julia (before the
> current curl fix attempt)?

You can reproduce the problem using the RPM from the last F40 build (julia-1.11.0-7.beta1.fc40). I have another commit locally which fixes it by also bundling mbedTLS (I can push it if you like).

> With a project that's hostile to using system libraries, abandoning rpms and
> using a flatpack may be the only way to go.  Of course that doesn't really
> address security concerns, it just shifts the responsibility upstream for
> keeping components up to date.

Yeah, using the Flatpak would mean bundling everything. Continuing to build a Fedora RPM means bundling fewer libraries, even if we bundle CURL, libssh2 and mbedTLS. But I'm not sure it's OK given the Fedora policy of bundling being exceptional.

Note that the problem with OpenSSL seems quite hard to fix even if Julia upstream was willing to put effort into that. That's because Julia packages need to be able to ship binary libraries so that they can rely on the same version on all platforms (in practice, it's almost impossible to support all versions that are shipped in existing distributions). The Julia package manager is a kind of distribution. This is fine for most libraries, but it fails for the few cases of libraries which are loaded indirectly by system libraries that Julia links to (like libopenssl which is loaded by libcurl in Fedora, but isn't used by Julia itself which uses it with mbedTLS).

would anyone be willing to report this issue upstream to see what they might be able to do about it in the future? I'm pretty sure nobody would want to see the Julia package being dropped from the official repos of one of the biggest Linux distributions.

I've been a contributor upstream for years and the general opinion among Julia developers is that distro packages are a negative rather than a positive point. So they may even be happy if we drop the Julia package as they tell users to download official binaries instead. :-)

The reason is that it's very hard to get Julia to work completely correctly using system libraries, and several distributions ship half-broken or outdated packages that generate a bad experience and/or bug reports from users.  This is visible here: if I build Julia using system CURL, libssh2 and mbedTLS, things seem to work, until somebody tries to install Plots.jl and it fails. And this is despite lots of efforts to get it to work (have a look at the .spec file...).

I've got many PRs merged upstream to fix issues when building the RPM, but the conditions are that 1) I (or somebody else interested) did the work, and 2) changes were more generally correct, without drawbacks for other use cases. Here I don't see what I could do to fix the problem.

Thank you for the clarification. That indeed doesn't sound very promising for the future. Personally I don't think programming languages, libraries and system utilities should be installed as flatpaks, but that's just my personal taste.

Until the fate of the Julia rpm package is finally decided, is there any chance to provide some sort of working package for the time being, even if it unnecessarily bundles certain libraries? The 1.11 beta package at least mostly works as opposed to 1.9.2 which is unusable on Fedora 40.

If it's deemed acceptable to bundle CURL, libssh2 and mbedTLS I can push a new update.

Who would be the one to greenlight this? Not that my word has any weight here, but I'd be in favor of bundling the libraries for the time being and maybe open a new, seperate issue to discuss the future of the Julia rpm package?

FEDORA-2024-8a00986001 (julia-1.11.0-8.beta1.fc40) has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-8a00986001

OK, I've pushed another update bundling mbedTLS.

FWIW, the Julia website now says in bold font (at https://julialang.org/downloads/):
> Please do not use the version of "Julia" shipped by unix package managers
> Many unix package managers ship broken and/or significantly out of date versions of Julia. Please use juliaup or download the official binaries instead.

FEDORA-2024-8a00986001 has been pushed to the Fedora 40 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-8a00986001`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-8a00986001

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

*** Bug 2291191 has been marked as a duplicate of this bug. ***

Try this patch

From 3d47f1f77811f41753c675c36348cb9c358b99bb Mon Sep 17 00:00:00 2001
From: Colin Walters <walters>
Date: Mon, 10 Jun 2024 16:24:22 -0400
Subject: [PATCH] Add a %define __provides_exclude_from

This more reliably filters out bundled libraries.
cc https://bugzilla.redhat.com/show_bug.cgi?id=2291191
---
 julia.spec | 1 +
 1 file changed, 1 insertion(+)

diff --git a/julia.spec b/julia.spec
index ebdb03a..d3975ae 100644
--- a/julia.spec
+++ b/julia.spec
@@ -27,6 +27,7 @@
 # OpenBLAS is excluded because we set a symlink to libopenblasp
 %global _privatelibs lib(openblas_|openblas64_|ccalltest|llvmcalltest|LLVM-.*|uv|blastrampoline|unwind)\\.so.*
 %global __provides_exclude ^(%{_privatelibs})$
+%global __provides_exclude_from ^%{_libdir}/%{name}/.*$
 %global __requires_exclude ^(%{_privatelibs})$
 
 # Some binaries confuse debuginfo check
-- 
2.44.0

> This is visible here: if I build Julia using system CURL, libssh2 and mbedTLS, things seem to work, until somebody tries to install Plots.jl and it fails

I don't have the full context for the problem here, but I suspect this is just flipping things the other way.  There can really only be one version of curl and openssl linked into the process, and if something else is pulling other external versions, then things are going to fail if some other library not in the bundled set here brings in a newer version of one of them.

Thanks for the patch Colin. I had already pushed another one which is a bit different but should give the same result. Unfortunately now the build hangs while running tests (this happens from time to time but now it happened twice in a row).

(In reply to Colin Walters from comment #37)
> I don't have the full context for the problem here, but I suspect this is
> just flipping things the other way.  There can really only be one version of
> curl and openssl linked into the process, and if something else is pulling
> other external versions, then things are going to fail if some other library
> not in the bundled set here brings in a newer version of one of them.

See my comment #26 above. OpenSSL is linked both by the system CURL and by Julia packages which don't expect it to be linked to Julia (which uses mbedTLS upstream).


This is really a nightmare and I'm more and more inclined to retire the package in favor of a Flatpak wrapping upstream binaries.

(Note that even once the Julia package is OK we'll have to fix bug 2279047 in Cantor.)

UPDATE: Now I see that you mean that bundling OpenSSL will create problems if another library links to the system OpenSSL. Yes, that's right. We can't win on both fronts. However, since Julia packages ship with their own libraries, it seems much more common to use versions expected by upstream than system (Fedora) versions. This kind of defeats the point of having a distro package for Julia though.

FEDORA-2024-b73636a9e6 (julia-1.11.0-9.beta1.fc40) has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-b73636a9e6

FEDORA-2024-b73636a9e6 has been pushed to the Fedora 40 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-b73636a9e6`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-b73636a9e6

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

I haven't received any feedback on the update, contrary to previous ones. Has anybody tested it?

(In reply to Milan Bouchet-Valat from comment #42)
> Has anybody tested it?

I added my +1

I just tested the "sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-b73636a9e6" change locally and that solves this issue for me on Fedora 40.  Thank you!

I've been using the package for a while now and have not had any major issues. I suppose it will say in testing until 1.11 is out of beta?

FEDORA-2024-b73636a9e6 (julia-1.11.0-9.beta1.fc40) has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.