Use Julia v1.12#12226
Conversation
|
As far as I know, building on 1.7 is not possible properly. #11683 (comment) I believe @benlorenz concluded that building for <1.9 can be dropped here #11683 (comment) |
|
The wrong libunwind version is being used for building v1.13, resulting in build failure for riscv64 (libunwind isn't available). It should be 1.8.2+1: Yggdrasil/L/libjulia/common.jl Line 486 in e5bd385 |
|
Uhm, is that because we're stuck with an old HistoricalStdlibVersions? https://github.com/JuliaPackaging/HistoricalStdlibVersions.jl/blob/9565c2f6c96c94555f516fdcee76fb6e458c89b9/src/version_map.jl#L11984-L11990? |
| push!(dependencies, Dependency(get_addable_spec("LLVMLibUnwind_jll", v"19.1.4+0"); platforms=filter(Sys.isapple, platforms))) | ||
| push!(dependencies, BuildDependency("SuiteSparse_jll")) | ||
| push!(dependencies, Dependency("LibUV_jll")) | ||
| push!(dependencies, Dependency("LibUnwind_jll"; platforms=filter(!Sys.isapple, platforms))) |
There was a problem hiding this comment.
@IanButterworth I removed all the get_addable_specs because it was like that in #11725, but the function should still work, right? At least that's still used for LLVM_full_jll everywhere. I presume that'd solve #12226 (comment)
There was a problem hiding this comment.
I guess it should still work. It seems counter to the simplicity of just using Pkg stuff where possible, so seems better to not use it, but I might be missing something.
|
Upgrading HSV breaks building for v1.13 entirely https://buildkite.com/julialang/yggdrasil/builds/23909#0199b73c-2e6a-4115-906b-add316099eb5/1091-1244: According to #11834 breakage happened in v2.0.3, this is the diff v2.0.2...v2.0.3: |
a4056e8 to
e0d695c
Compare
e0d695c to
1d763b3
Compare
|
Ok, this seems to be working using Julia v1.12.1 (but we have to exclude libjulia v1.7-1.8 because of #11683 (comment)), but we're hitting JuliaLang/Pkg.jl#4442 way too frequently, we have to fix that. |
|
Nice! Let's wait for PR #12378 then |
|
I think this PR also resolves #11834, as it relaxes the HSV compat again. But has anybody tested this PR with a dependent of libjulia_jll? The motivation for #11833 (which led to #11834 as a reminder) was just to fix the 1.13 build for dependents of libjulia_jll, the build of libjulia_jll itself was working fine. |
|
Needs treehashes re-signed (once the cloudflare outage is fixed) |
|
Note: we'll need v1.12.2 to hopefully resolve the curl issue |
lgoettgens
left a comment
There was a problem hiding this comment.
- I noticed that there are a bunch of issues similar to #11683 (comment), i.e. for any
PackageSpecthat provides a version as aVersionNumberthis has to be changed to a string. I would not put that into this PR to keep in readable, but there should be an automated change for this right after this PR here gets merged. - I tried to build
GAP_pkg_juliainterfacewith this PR with julia 1.12.1. The issues from #11833 don't happen anymore, so #11834 is resolved. - However, in the logs of the above, I see that
Artifactsgets downgraded from v1.11.0 to v1.3.0 (for a julia 1.13 build), which seems a bit weird
| @@ -1,10 +1,10 @@ | |||
| include("common.jl") | |||
|
|
|||
| if v"1.7" <= VERSION < v"1.8" | |||
There was a problem hiding this comment.
If the whole build setup is updated to julia 1.12, I think this if-branch can just go
44b45ba to
dfa0b09
Compare
|
Anything left (besides #12226 (comment))? |
|
What about 1 and 3 of #12226 (review)? |
You said that's for after this PR, no?
You didn't provide a direct link so I don't know what should I look at and don't have the bandwidth to scavenge the log myself, but also I don't particularly care, I'm more worried about the jlls version. |
Yeah, but IMO it should already be prepared so that it can be merged ASAP after, as otherwise many (most) recipes won't work.
The logs I was referring to were of me locally building a dependent of libjulia. |
|
First off, thank you to everyone who worked hard to make this PR possible!! @giordano from my POV this is fine, and the "draft" label could be removed. There is some cleanup one could perform here, e.g. remove the now-dead code in Regarding point 1 by @lgoettgens: I am not quite sure what needs to be done or prepared. But since you, Lars, seem to know quite well, would you be able and willing to prepare that? (I say this completely naively, without an inkling about how much work we are talking about, so don't hesitate to say "no" if this is an unreasonable ask; but realistically, I am then not sure if it will happen anytime soon, and we may just end up having to put up with some broken recipes in the meantime) Regarding point 3 / Artifacts, the log Lars linked to says: I note that |
I can try to ask AI to write me the necessary regexes tomorrow |
Co-authored-by: Lars Göttgens <lars.goettgens@gmail.com>
|
Re. Artifacts.. I assume Pkg is getting confused by the confusing state of Artifacts across julia versions. tbh so am I |
|
Re. Artifacts.. First guess at a fix (with a test) JuliaLang/Pkg.jl#4534 |
|
But that's not critical right? It's not like packages in those environments are used for anything. |
|
Yeah I don't think it's a blocker. Julia will use the stdlib version it comes with and ignore if the manifest has a different version. It's just a manifest correctness thing IIUC |
|
Agreed, not a blocker - still good that Lars noticed it and Ian is looking into it, but this PR need not wait for it. |
|
It failed to build on |
|
That was a timeout, riscv64 should be buildable on v1.13 (maybe also v1.12), yes. |
|
So ... all is green... merge? (I am not going to do that, though, as this is marked as draft, so perhaps there is a reason not to merge it after all?) |
|
Looks good to me but I think @giordano should do the honors |
See #12627. I think it would be good to merge that either right before or right after this PR here. So, no further objects from my side |
|
YOLO. |
Replaces #11725, there are too many conflicts to handle it nicely with a merge/rebase.
Closes #11834
CC @IanButterworth.