^1.6.0-0 (the last separator is a -, not a .) will work. There are several slightly different ways in the action readme
2 Likes
UPDATE: deleting “_.julia\registries\general” fixed things
(although I have not tried to regenerate the Norton alert)
Norton does not like it. First msg (no valid signature), next msg (Norton Alert Severity High: Data Protector blocked a suspicious action by julia.exe) [later, I cleared the block, and had Norton ignore it, that made no difference] which resulted in this:
(@v1.6) pkg> up
Updating registry at `C:\Users\jas\.julia\registries\General`
ERROR: IOError: unlink("C:\\Users\\jas\\.julia\\registries\\General\\D\\Desktop\\Compat.toml"): permission denied (EACCES)
then
upon restarting Julia, a number of packages (on pkg> up) report e.g. (here Cairo, same msg with DataFramesMeta and others)
ERROR: Unsatisfiable requirements detected for package Cairo [159f3aea]:
Cairo [159f3aea] log:
├─Cairo [159f3aea] has no known versions!
└─restricted to versions * by an explicit requirement — no versions left
Windows 64bit
Thanks. I will try to read better next time. My Morse code skills are poor and sometimes I can’t tell my dots from my dashes.
1 Like
I think you should consider the history of bugs that only appear with Debian packages before you wish for that too strongly 
. You should always install from a binary or build from source.
5 Likes
I would like to thank a lot all the Julia Team for this very, very good release of Julia because
-
it is much faster the previous ones for the Time to First plot issue, and also faster generally speaking,
-
it does full Project-precompiling when updating, and for this is uses multicore/multithreads ability, so much faster for update of package,
-
it re-introduces old AMD (Phenom, Turion) as standandard x86_64 operation ready (which was lost since 1.4, so, getting them again much better for future(?) LTS status,
-
it (re?)-introduces Powerpc (ppc64LE) platform, so same comment for LTS status (however, it did not completely worked for me, see next post).
Just a comment, there are some glitches for interoperation from Julia-1.5.3, as there is this new jll library scheme. In most cases you can just run julia-1.6 on an 1.5 project, but in some cases it fails with a totally unrelated message (see below). But in that case the fix is easy : just Up-date the project under julia-1.6.0, and then it works, but you loose compatibility with julia-1.5.3 (the new Manifest from julia-1.6 cant be used by julia-1.5.3 because of the jll switches. I think, imho, that it could warrant a comment in the NEWS section ?
for the record, MWE of the case
mkdir /tmp/pb_http15; cd /tmp/pb_http15
julia-1.5.3 --project=.
] add HTTP
] precompile
then
davidj@vivojdw /tmp/pb_http15$ julia -q --project=.
julia> using HTTP
[ Info: Precompiling HTTP [cd3eb016-35fb-5094-929b-558a96fad6f3]
julia> url="https://query1.finance.yahoo.com/v7/finance/chart/FP.PA?&interval=1d&period1=1577880000&period2=1609329600"
"https://query1.finance.yahoo.com/v7/finance/chart/FP.PA?&interval=1d&period1=1577880000&period2=1609329600"
julia> response = HTTP.get(url, cookies = true)
HTTP.Messages.Response:
"""
HTTP/1.1 200 OK
... (all is OK)
davidj@vivojdw /tmp/pb_http15$ julia16 -q --project=.
julia> using HTTP
[ Info: Precompiling HTTP [cd3eb016-35fb-5094-929b-558a96fad6f3]
julia> url="https://query1.finance.yahoo.com/v7/finance/chart/FP.PA?&interval=1d&period1=1577880000&period2=1609329600"
"https://query1.finance.yahoo.com/v7/finance/chart/FP.PA?&interval=1d&period1=1577880000&period2=1609329600"
julia> response = HTTP.get(url, cookies = true)
ERROR: IOError(MbedTLS error code 13: CCM - Bad input parameters to the function during request(https://query1.finance.yahoo.com
/v7/finance/chart/FP.PA?&interval=1d&period1=1577880000&period2=1609329600))
Stacktrace:
[1] mbed_err(ret::Int32)
@ MbedTLS ~\.julia\packages\MbedTLS\4YY6E\src\error.jl:17
[2] crt_parse!
@ ~\.julia\packages\MbedTLS\4YY6E\src\x509_crt.jl:30 [inlined]
[3] crt_parse(buf::String)
@ MbedTLS ~\.julia\packages\MbedTLS\4YY6E\src\x509_crt.jl:40
[4] ca_chain!
@ ~\.julia\packages\MbedTLS\4YY6E\src\ssl.jl:497 [inlined]
[5] MbedTLS.SSLConfig(verify::Bool; log_secrets::Nothing)
@ MbedTLS ~\.julia\packages\MbedTLS\4YY6E\src\MbedTLS.jl:128
[6] SSLConfig
@ ~\.julia\packages\MbedTLS\4YY6E\src\MbedTLS.jl:111 [inlined]
[7] global_sslconfig(require_ssl_verification::Bool)
@ HTTP.ConnectionPool ~\.julia\packages\HTTP\hbs7O\src\ConnectionPool.jl:692
[8] sslconnection(tcp::Sockets.TCPSocket, host::SubString{String}; require_ssl_verification::Bool, sslconfig::MbedTLS.SSLConfi
g
....
4 Likes
And now, the glitch for the ppc64le version
[jdavid00@login02 ~]$ julia-1.6.0-beta1-org
ERROR: Unable to load dependent library /m100/home/userexternal/jdavid00/local/julia-b84990e1ac-org/bin/../lib/julia/libjulia-internal.so.1
Message:/lib64/ld64.so.2: version `GLIBC_2.22' not found (required by /m100/home/userexternal/jdavid00/local/julia-b84990e1ac-org/bin/../lib/julia/libjulia-internal.so.1)
[jdavid00@login02 ~]$
It works seamlessly when I recompile julia from the source (full with dependencies, very simple since no Make.user to define).
A check shows me that
[jdavid00@login02 ~]$ uname -a
Linux login02 4.14.0-115.14.1.el7a.ppc64le #1 SMP Thu Oct 3 05:32:24 EDT 2019 ppc64le ppc64le ppc64le GNU/Linux
[jdavid00@login02 j160b1]$ cat /etc/os-release
NAME="Red Hat Enterprise Linux Server"
VERSION="7.6 (Maipo)"
...
[jdavid00@login02 ~]$ rpm -qi glibc
Name : glibc
Version : 2.17
Release : 260.el7
Architecture: ppc64le
Install Date: Fri 17 Apr 2020 06:22:24 PM CEST
Group : System Environment/Libraries
Size : 28627824
License : LGPLv2+ and LGPLv2+ with exceptions and GPLv2+
Signature : RSA/SHA256, Thu 28 Jun 2018 01:06:15 PM CEST, Key ID 199e2f91fd431d51
Source RPM : glibc-2.17-260.el7.src.rpm
Build Date : Thu 28 Jun 2018 06:57:29 AM CEST
Build Host : ppc-044.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor : Red Hat, Inc.
URL : http://www.gnu.org/software/glibc/
Summary : The GNU libc libraries
Description :
The glibc package contains standard libraries which are used by
...
so the problem is that the system has an older glibc-2.17 version …
but manageable as not a real problem for me (13.36mn for compilation overall, so quite fast).
1 Like
2 Likes
Done!
(thanks to you support/suggestion)
1 Like
Which of the Linux are for Debian (I’m new to Linux)?
1 Like
It depends on your machine, we can’t tell you. If you don’t know what architecture is your machine (x86, aarch64 or PowerPC), chances are good that it’s a x86, likely 64-bit. For x86_64 Linux there are the binaries for both glibc and musl C libraries, which one again depends on your system. If you don’t know, chances are good that it’s based on glibc
4 Likes
Ok that makes sense, I’m sure it’s 64, and pretty sure it’s x86. It’s an Intel® Xeon(R) CPU E5-1630 v3 @ 3.70GHz × 8.
I don’t like that syntax either but I’ve not found a way to make 1.6 etc work without introducing a number of potential edge cases, hence it falls back to “standard” semver range parsing. The -0 forces it to include all prereleases.
3 Likes
That chip is x86-64 for sure. If you run uname from the shell you should see x86-64 tags on your machine architecture
gibson@sophist$ uname -m
x86_64
gibson@sophist$ uname -a
Linux sophist.ad.unh.edu 5.3.18-lp152.57-default #1 SMP Fri Dec 4 07:27:58 UTC 2020 (7be5551) x86_64 x86_64 x86_64 GNU/Linux
1 Like
I’ve gotten it running on the Raspberry Pi 4! Running on the 64bit beta of Raspbian. Thanks Julia devs! I was having issues building and this came at the perfect time!
4 Likes
Nice. How’s the new pkg precompile process on the PI? Does it lock up the system while it’s going on at all? i.e. can you move the terminal window around while it’s taking place?
Hmm, so far I haven’t experienced the system locking up, although at the moment I’m only using the pi remotely over ssh and haven’t used a graphical environment. I’ll report back if I experience quirks though.
1 Like
Unfortunately, this is not correct, at least on GitHub Actions, where using “1.6” does not work; apparently ^1.6.0-0 works (though I did not try it). @ararslan could you perhaps edit your post, as it is a bit misleading and people need to rediscover this again and again? (Of course even better would be if 1.6 just worked, bit since it still doesn’t after several days, it seems to be a non-trivial issue).
*** Thank you, Alex, for your great service! ***
Kind regards from Northern Germany,
Harald Gegenfurtner
There are 8 open issues in the 1.6 blockers milestone. Does that mean Julia 1.6 will not be released until all these issues are resolved?
Yes. (at least in theory. In practice, there is a possibility that some of them could get dropped from 1.6)
3 Likes