-
-
Notifications
You must be signed in to change notification settings - Fork 34
Version 1.6.2 #119
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
Version 1.6.2 #119
Conversation
…nda-forge-pinning 2021.08.08.03.57.11
|
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
…a1949c2a5f0937a7e1da unverified HTTPS: don't set CURLOPT_SSL_VERIFYHOST=0
|
Downloads.jl, a part of the Julia standard library encountered three errors when we used the same configuration as Julia 1.6.1. Details of Downloads.jl errors.The errors are due to JuliaLang/Downloads.jl@818cd12 which is a backport of JuliaLang/Downloads.jl#114 Specifically, the test failures occur around lines 387, 395, and 405 of Downloads.jl 1.4.1 which tests a mechanism to override host verification. This is due to only modification of only By setting Subsequent commits upstream in Downloads.jl allow for user control of host verification. The significance of these test failures are not clear since upstream Julia "have yet to find an example where turning host verification off is necessary." Thus it is likely that b02be7b and 8fe4f7e will be reverted and perhaps the Downloads.jl tests will be dropped. |
recipe/build.sh
Outdated
| export EXTRA_MAKEFLAGS="USE_SYSTEM_LIBGIT2=0" | ||
| fi | ||
|
|
||
| # using system utf8proc can be enabled in 1.7.0. See https://github.com/JuliaLang/julia/commit/ba653ecb1c81f1465505c2cea38b4f8149dd20b3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should be able to use utf8proc in 1.6.2 since that patch was backported.
|
The reason the macOS math test are failing at line 296 is that the the tests are running on ivybridge: https://discourse.julialang.org/t/base-runtests-math-failures-on-chips-older-than-haswell/65954 |
|
@isuruf This is a decent working build of Julia 1.6.2. I've dropped the Downloads tests since upstream thinks the failures may be incorrect per JuliaLang/Downloads.jl#140. I've added all the tests for Julia proper except for the standard library tests. The one failing test in math is excluded for osx since the osx virtual machine uses an older ivybridge processor that lacks fused multiply add (FMA) instructions. I able to use conda-forge's Should one or both of us be listed as maintainers in meta.yaml? |
|
Note to self, set https://github.com/JuliaCI/julia-buildbot/blob/master/master/inventory.py#L128-L130 |
|
@mkitti, given your stellar work on the 1.6 packaging, I definitely support your addition to maintainers, but this is not my package. @conda-forge/julia, any objections? But I have a question: Is there a particular reason why you opened a new PR for this? Normally, you can work on the PR that was opened by the bot and push to the bot's repo. |
|
Thanks.
I was not aware I could push to the bot's branch. Perhaps I need to be a maintainer in order to do that? |
Ah yes, you are probably right. All the more reason to add you 😉 |
|
Do you need a member from core to merge this? Would be great to have you as a maintainer @mkitti ! |
…ell,-rdrnd,base(1)"
|
Hi! This is the friendly automated conda-forge-linting service. I wanted to let you know that I linted all conda-recipes in your PR ( Here's what I've got... For recipe:
|
|
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
|
Per #118 , we may need to pin some of the dependencies to particular versions. The versions used in the official builds are listed here: |
|
Hi @wolfv , thanks for the offer to merge. I just pushed a few commits addressing some lingering issues. @isuruf reviewed 1.6.1 so it may be useful for him to take a look in case I missed anything. I would be interested in merging some version of #87 as well, but perhaps we should save that for another build. Otherwise, I think this is good to merge to have Julia 1.6.2 available via conda-forge, pending passing CI checks. |
|
This should be ready to merge unless there are other blocking issues. After this, I would like work on another build along the lines of #87 . |
recipe/build.sh
Outdated
| export EXTRA_MAKEFLAGS="USE_SYSTEM_LIBGIT2=1" | ||
| fi | ||
| # Do this only for x86_64, target platform is not osx-arm64 | ||
| export JULIA_CPU_TARGET="generic;sandybridge,-xsaveopt,clone_all;haswell,-rdrnd,base(1)" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you explain what this does?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure. Here is a quote from https://docs.julialang.org/en/v1/devdocs/sysimg/#Specifying-multiple-system-image-targets
This creates a system image with three separate targets; one for a generic x86_64 processor, one with a sandybridge ISA (explicitly excluding xsaveopt) that explicitly clones all functions, and one targeting the haswell ISA, based off of the sandybridge sysimg version, and also excluding rdrnd. When a Julia implementation loads the generated sysimg, it will check the host processor for matching CPU capability flags, enabling the highest ISA level possible. Note that the base level (generic) requires the cx16 instruction, which is disabled in some virtualization software and must be enabled for the generic target to be loaded. Alternatively, a sysimg could be generated with the target generic,-cx16 for greater compatibility, however note that this may cause performance and stability problems in some code.
Without the above, Julia is built targeting whatever machine architecture the build system is using. However, we probably should target a broad number of x86_64 architectures rather than ones similar to the virtual machine environment. Here we target the exact same architectures that official Julia targets.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. Does that mean we should remove MARCH=core2 from the line below?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question. MARCH and JULIA_CPU_TARGET are actually distinct. JULIA_CPU_TARGET specifically targets the LLVM JIT component for building the system image.
https://github.com/JuliaLang/julia/blob/3aea11eea2111e91f33d91926d1fe2f9a71947cb/Make.inc#L774-L781
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the link. Looks like Julia is setting it based on the compiler, so it's better to remove MARCH part.
recipe/build.sh
Outdated
| fi | ||
| # Do this only for x86_64, target platform is not osx-arm64 | ||
| export JULIA_CPU_TARGET="generic;sandybridge,-xsaveopt,clone_all;haswell,-rdrnd,base(1)" | ||
| https://github.com/JuliaCI/julia-buildbot/blob/ba448c690935fe53d2b1fc5ce22bc60fd1e251a7/master/inventory.py |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the link supposed to be in a comment?
Co-authored-by: Isuru Fernando <isuruf@gmail.com>
|
Hi! This is the friendly conda-forge automerge bot! I considered the following status checks when analyzing this PR:
Thus the PR was passing and merged! Have a great day! |
|
Oh, I forgot to specify the version of suitesparse for run. |
This will update the Julia feedstock to the current stable version. The initial new commit is from the autotick bot.
The pull request is in draft form since additional commits are expected to take advantage of 1.6.2 build features.