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

custom JULIAUP_SERVER for normal http server #917

Open
johnnychen94 opened this issue May 3, 2024 · 3 comments
Open

custom JULIAUP_SERVER for normal http server #917

johnnychen94 opened this issue May 3, 2024 · 3 comments

Comments

@johnnychen94
Copy link
Sponsor Member

johnnychen94 commented May 3, 2024

The current download implementation seems to require the etag header, which usually doesn't exist for regular HTTP servers. I think juliaup should not assume this header exists (but it seems that this etag header is kept track in the channel db)

This leads to the following crash:

JULIAUP_LOG=debug JULIAUP_SERVER=https://mirrors.tuna.tsinghua.edu.cn/julia-releases juliaup add 1.9
[2024-05-03T17:51:06Z INFO  juliaup] Parsing command line arguments.
[2024-05-03T17:51:06Z DEBUG reqwest::connect] starting new connection: https://mirrors.tuna.tsinghua.edu.cn/
[2024-05-03T17:51:06Z DEBUG hyper_util::client::legacy::connect::dns] resolving host="mirrors.tuna.tsinghua.edu.cn"
[2024-05-03T17:51:06Z DEBUG hyper_util::client::legacy::connect::http] connecting to 101.6.15.130:443
[2024-05-03T17:51:06Z DEBUG hyper_util::client::legacy::connect::http] connected to 101.6.15.130:443
[2024-05-03T17:51:06Z DEBUG hyper_util::client::legacy::pool] pooling idle connection for ("https", mirrors.tuna.tsinghua.edu.cn)
Installing Julia 1.9.4+0.aarch64.apple.darwin14
[2024-05-03T17:51:06Z DEBUG juliaup::operations] Downloading from url `https://mirrors.tuna.tsinghua.edu.cn/julia-releases/bin/mac/aarch64/1.9/julia-1.9.4-macaarch64.tar.gz`.
[2024-05-03T17:51:06Z DEBUG reqwest::connect] starting new connection: https://mirrors.tuna.tsinghua.edu.cn/
[2024-05-03T17:51:06Z DEBUG hyper_util::client::legacy::connect::dns] resolving host="mirrors.tuna.tsinghua.edu.cn"
[2024-05-03T17:51:06Z DEBUG hyper_util::client::legacy::connect::http] connecting to 101.6.15.130:443
[2024-05-03T17:51:06Z DEBUG hyper_util::client::legacy::connect::http] connected to 101.6.15.130:443
⠁                                                                                                                                                                               Well, this is embarrassing.

Juliaup had a problem and crashed. To help us diagnose the problem you can send us a crash report.

We have generated a report file at "/var/folders/zd/5x9t7qz92sx6c38q9yl7qbm00000gp/T/report-e6878051-147c-40b3-9265-5e677ae61cfb.toml". Submit an issue or email with the subject of "Juliaup Crash Report" and include the report as an attachment.


To submit the crash report:

https://github.com/JuliaLang/juliaup

We take privacy seriously, and do not perform any automated error collection. In order to improve the software, we rely on people to submit reports.

Thank you kindly!
[2024-05-03T17:51:06Z DEBUG hyper_util::client::legacy::pool] pooling idle connection for ("https", mirrors.tuna.tsinghua.edu.cn)

The crash report:

"name" = "Juliaup"
"operating_system" = "Mac OS 13.2.1 [64-bit]"
"crate_version" = "1.14.8"
"explanation" = """
Panic occurred in file 'src/operations.rs' at line 81
"""
"cause" = "called `Option::unwrap()` on a `None` value"
"method" = "Panic"
"backtrace" = """

   0: 0x100f89578 - core::panicking::panic::hcdbd360f66af7955
   1: 0x100f89714 - core::option::unwrap_failed::h7f61ccc9834696cb
   2: 0x100dfd720 - juliaup::operations::download_extract_sans_parent::hc477128cc7186939
   3: 0x100df7188 - juliaup::operations::install_version::hde6db4a2b39cd26d
   4: 0x100df106c - juliaup::command_add::run_command_add::h077c95f3e216b4d0
   5: 0x100d1802c - juliaup::main::hae29d18c2d32cdf1
   6: 0x100d130a4 - std::sys_common::backtrace::__rust_begin_short_backtrace::hd6f133e2356630ee
   7: 0x100d20ce8 - _main"""
@davidanthoff
Copy link
Collaborator

We use that etag to figure out whether there is a new nightly build available... The official servers we use support this, so is the problem here that some alternative non-official server doesn't? I'm not sure how else we could implement the same functionality...

@StefanKarpinski
Copy link
Sponsor Member

Would it be possible to assume there are no nightlies if the etag header isn't returned?

@davidanthoff
Copy link
Collaborator

One thing we should definitely do is make things not crash if someone doesn't even have the nightly channel installed and is using a server that doesn't support etags. And then maybe if someone is on that we just lose the ability to notify the user about new nightly builds.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants