Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Backports for 1.0.4 #30954

Merged
merged 41 commits into from
May 9, 2019
Merged

Backports for 1.0.4 #30954

merged 41 commits into from
May 9, 2019

Conversation

KristofferC
Copy link
Member

@KristofferC KristofferC commented Feb 4, 2019

Backported PRs:

Non-merged PRs with backport label:

@cdluminate
Copy link
Contributor

May I ask when Julia 1.0.4 will be released? According to Debian's release scheme, I'd better upload 1.0.4 to Debian before March 2nd.

@KristofferC KristofferC force-pushed the backport-1.0.4 branch 3 times, most recently from a6392c5 to 42fe9fc Compare February 11, 2019 11:59
@KristofferC
Copy link
Member Author

Bisecting suggests #30470 as the cause of the test failures. Dropping that PR and rerunning CI.

@StefanKarpinski
Copy link
Member

May I ask when Julia 1.0.4 will be released?

Seems likely to be out by then but it's not a guarantee.

@fredrikekre
Copy link
Member

Looks pretty good, lets push this over the finish line and get 1.0.4 out!

  • From tester_win64:

    Error in testset FileWatching:
    Test Failed at C:\cygwin\home\Administrator\buildbot\worker-tabularasa\tester_win64\build\share\julia\stdlib\v1.0\FileWatching\test\runtests.jl:388
      Expression: #= C:\cygwin\home\Administrator\buildbot\worker-tabularasa\tester_win64\build\share\julia\stdlib\v1.0\FileWatching\test\runtests.jl:388 =# @elapsed(c = watch_folder(dir, timeout)) < 0.5
       Evaluated: 1.265155767 < 0.5
    
  • package_freebsd64 looks like it failed building gmp, if I am reading the logs correctly:

    gmake[1]: *** [/usr/home/julia/buildbot/worker/package_freebsd64/build/deps/gmp.mk:26: scratch/gmp-6.1.2/build-configured] Error 1
    

I restarted both 🤞

@fredrikekre fredrikekre mentioned this pull request Apr 16, 2019
39 tasks
@KristofferC
Copy link
Member Author

@nanosoldier runbenchmarks(ALL, vs = ":release-1.0")

@KristofferC
Copy link
Member Author

How did AV start passing... Oh well, I'll take it.

@fredrikekre
Copy link
Member

Looks like tester_win64 passed the restart, package_freebsd still fails with the same error though, @staticfloat , @ararslan any ideas about that?

@vchuravy
Copy link
Member

The error in FreeBSD is a configure error:

configure: error: could not find a working compiler, see config.log for details
....
gmake[1]: *** [/usr/home/julia/buildbot/worker/package_freebsd64/build/deps/gmp.mk:26: scratch/gmp-6.1.2/build-configured] Error 1
gmake[1]: *** Waiting for unfinished jobs....

@vchuravy
Copy link
Member

FreeBSD failure is likely fixed by #31586

@ararslan ararslan added the needs pkgeval Tests for all registered packages should be run with this change label Apr 16, 2019
@nanosoldier
Copy link
Collaborator

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @ararslan

@KristofferC
Copy link
Member Author

Freebsd and macOS buildbots fail at some built step.

@staticfloat
Copy link
Member

FreeBSD bot needs #31586 backported. MacOS bot is a race condition in OpenBLAS 0.3.2 buildsystem; I think we can ignore that because there's no trivial fix other than upgrading OpenBLAS to 0.3.5. (It only occurs when you build OpenBLAS 0.3.2 on a multicore system with a hot ccache)

@KristofferC
Copy link
Member Author

FreeBSD bot needs #31586 backported

I already backported that. Did it not get picked up?

@staticfloat
Copy link
Member

Oh, so you did. Ah, yes. This is one of those patches that applies itself into $(SRCDIR) so it muddles our persistent cache and doesn't get applied cleanly sometimes. I'll try nuking that builder and running this again.

@staticfloat
Copy link
Member

Frustratingly, logging in and manually running the same make command, it configures correctly. The error it ran into was that a configure test segfaulted, which I don't quite understand. One worrying thing is that it looks like our $$ORIGIN escaping isn't working properly, in the configure log I see things like -Wl,3563ORIGIN, which is potentially not harmless fun.

@ararslan
Copy link
Member

PkgEval says the only regressions are CategoricalArrays and StaticNumbers. Logs: https://gist.github.com/ararslan/b47e8f93e19e46cfc8a7980fe53ef727. CategoricalArrays looks like it might be okay (@nalimilan, thoughts?), no idea about StaticNumbers. Looks weird, man.

@fredrikekre fredrikekre added the release Release management and versioning. label Apr 19, 2019
stevengj and others added 6 commits April 20, 2019 11:40
(cherry picked from commit c36e70b)
* minor fixes in multiplication with Diagonals

* correct rmul!(A,D), revert changes in AdjTrans(x)*D

* [r/l]mul!: replace conj by adjoint, add transpose

* add tests

* fix typo

* relax some tests, added more tests

* simplify tests, strict equality

(cherry picked from commit a93185f)
@KristofferC
Copy link
Member Author

I reverted the commit that broke StaticNumbers. Need #30880 manually backported, another PkgEval run, then this is good to go.

@staticfloat
Copy link
Member

The inference fix seems to have done something naughty:

Error in testset compiler/compiler:
Test Failed at /buildworker/worker/tester_linux64/build/share/julia/test/compiler/compiler.jl:1343
  Expression: typeof_tfunc(Union{<:T, <:Real} where T <: Complex) == Union{Type{Complex{T}} where T <: Real, Type{<:Real}}
   Evaluated: Union{Type{#s55} where #s55<:Complex{T} where T<:Real, Type{#s55} where #s55<:Real} == Union{Type{Complex{T}} where T<:Real, Type{#s607} where #s607<:Real}
Error in testset compiler/compiler:
Test Failed at /buildworker/worker/tester_linux64/build/share/julia/test/compiler/compiler.jl:1346
  Expression: Base.return_types(f_typeof_tfunc, (Union{<:T, Int} where T <: Complex,)) == Any[Union{Type{Int}, Type{Complex{T}} where T <: Real}]
   Evaluated: Any[Union{Type{Int64}, Type{#s55} where #s55<:Complex{T} where T<:Real}] == Any[Union{Type{Int64}, Type{Complex{T}} where T<:Real}]

@KristofferC
Copy link
Member Author

I'll just drop it then.

@ararslan
Copy link
Member

Still need to figure out the macOS and FreeBSD buildbot stuff. @staticfloat, any ideas?

@ararslan
Copy link
Member

I can't reproduce the FreeBSD buildbot failure on FreeBSD 11.2 (which is what I think the buildbot is running) with or without USE_BINARYBUILDER=0.

@ViralBShah
Copy link
Member

Do we know if this will produce working arm binaries?

@ararslan
Copy link
Member

ararslan commented May 6, 2019

@ararslan
Copy link
Member

ararslan commented May 7, 2019

Looks like we have some actual test problems on macOS and FreeBSD.

@KristofferC
Copy link
Member Author

Looks like we have some actual test problems on macOS and FreeBSD.

Hmm, macOS passes on Travis. Tests that fails have to do with LibGit2 which should not be touched by this PR. Not sure what to do.,

@ararslan
Copy link
Member

ararslan commented May 7, 2019

If macOS passes on Travis, we're probably fine there. I'll run the FreeBSD build and tests locally and report back.

@ararslan
Copy link
Member

ararslan commented May 7, 2019

No LibGit2 failures locally on FreeBSD on this branch for me. errorshow fails, which is odd, as it does not seem to happen on the buildbot.

@ararslan ararslan removed the needs pkgeval Tests for all registered packages should be run with this change label May 9, 2019
@ararslan
Copy link
Member

ararslan commented May 9, 2019

PkgEval results are in: No regressions. The only difference is CategoricalArrays, which is testing incorrect behavior, as stated previously.

Regarding the buildbot failures, I'm inclined to say we're okay there. I can't reproduce the failure on FreeBSD, and macOS passed on Travis. The issue is with the tests, which aren't run as part of the packaging build, so it won't pose a problem for making release binaries.

EDIT: Apparently a rerun of the FreeBSD tests passed anyway.

@KristofferC
Copy link
Member Author

I agree.

@ararslan
Copy link
Member

ararslan commented May 9, 2019

Also, the Nanosoldier regressions look like noise to me.

@ararslan ararslan removed the DO NOT MERGE Do not merge this PR! label May 9, 2019
@ararslan ararslan merged commit 51496aa into release-1.0 May 9, 2019
@ararslan ararslan deleted the backport-1.0.4 branch May 9, 2019 22:17
@vtjnash vtjnash mentioned this pull request Jan 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release Release management and versioning.
Projects
None yet
Development

Successfully merging this pull request may close these issues.