Debian package repositories broken: Unknown date format Bad header data #1399
Comments
|
Running into this as well - am not very familiar with the Debian formats, but a quick look through the specs seems to indicate it's the 'Date' field in the 'Release' file: |
|
Yep, the File downloaded from: https://adoptopenjdk.jfrog.io/adoptopenjdk/deb/dists/jessie/ |
|
For reference, this happens when then running an |
|
Debian's own Release also contains a UTC Date, so that is probably fine...
|
|
We're running into this issue has well and also noticed that the Date field seems to comply with Date format specifications https://wiki.debian.org/DebianRepository/Format#Date.2C_Valid-Until I cannot tell what is going wrong. |
|
@mkey-cdx Following header seems to be the cause: Last-Modified: Wed, 17 Jun 2020 08:56:25 EDTbasically, the Last-Modified header. |
|
@aahlenst - Sorry to be a bother buddy, just wondering if there was any update from JFrog's side in terms of the resolution to this issue? |
|
No, no answer yet. I'll update as soon as we hear anything. Unfortunately, we neither have control over the machine nor the domain, so we cannot provide an interim fix. |
|
@aahlenst - No worries. Thanks very much for the response and keeping us posted. As a temporary workaround in the meantime, if someone would like to setup AdoptOpenJDK using the tar files ... you can do something like the following ## Using wget to download AdoptOpenJDK 11 tar file
sudo wget https://github.com/AdoptOpenJDK/openjdk11-binaries/releases/download/jdk-11.0.7%2B10/OpenJDK11U-jdk_x64_linux_hotspot_11.0.7_10.tar.gz -O jdk.tar.gz
## Extract jdk.tar.gz
sudo tar -xzf jdk.tar.gz
## Create a storage path and move it there:
sudo mv jdk-11.0.7+10 /usr/lib/jvm/jdk
## Add a file to set JAVA_HOME environment variable and /usr/lib/jvm/jdk/bin to PATH globally:
sudo bash -c 'cat <<EOF >/etc/profile.d/java.sh
export JAVA_HOME=/usr/lib/jvm/jdk
export PATH=$PATH:/usr/lib/jvm/jdk/bin
EOF'
## Source it:
sudo bash -c 'source /etc/profile.d/java.sh'
## Try:
java -versionFYI - only tested it on Ubuntu 16.04 LTS & Ubuntu 18.04 LTS .. Shouldn't be any different for a debian family OS. |
|
Yesterday evening I was able to add the repo and install an adoptopenjdk package, but running update this morning results in the above mentioned error. Maybe that helps narrowing down where things went wrong? |
|
Related to this release - 7.5.8? Perhaps some of y'all could start tweeting up a storm about this, it's been persisting longer than I would have expected. |
|
Is there a dependent issue with JFrog? Is the best way to reach them really on Twitter? |
|
@keefertaylor As I wrote in the first message, we have an open support request with JFrog. |
|
Is there another repository than the one from jfrog? |
|
What's going on here? We can't rollout our infrastructure due to this error. Is someone working on this? |
|
(Disclaimer: we only use this package on our CI for running tests) For those of you using Debian Buster and need OpenJDK 8, you can switch to Debian's Stretch package it only installs a few dependencies being the headless variant, and for us it did the trick. |
|
The packages can be manually pulled from https://adoptopenjdk.jfrog.io/adoptopenjdk/deb/pool/main/a/. Because no further dependencies have to be downloaded from our server, you can work around the problem with wget+apt: There's currently no other server to download the packages from via apt. I do not want to rush the introduction of a replacement, as inconvenient as the current situation is. We're still waiting on a response from JFrog. |
Summary: This is a workaround for the adoptopenjdk8 issue: adoptium/infrastructure#1399 It should help keeping the CI running until this is fixed upstream. The real solution would be to update to latest Teamcity, which will cut the dependency to the old Java 8 version. Test Plan: Run any CI build. Reviewers: #bitcoin_abc, jasonbcox Reviewed By: #bitcoin_abc, jasonbcox Differential Revision: https://reviews.bitcoinabc.org/D6635
|
Facing the same issue: |
|
Still geting the same problem Ign:17 https://adoptopenjdk.jfrog.io/adoptopenjdk/deb bionic InRelease |
|
@abhijeetnarvekar , @duckulaj - As per @aahlenst, the issue has been raised with JFrog and team is likely waiting on a response from them.
As you may notice, @aahlenst also shared alternative method to install the debian package for the time being, if you are interested. |
|
Looks like it is related to this issue, caused by a bug in the underlying Tomcat engine. https://www.jfrog.com/jira/browse/RTFACT-21640 |
|
Their support is on the case |
|
Hopefully it sticks, but it just worked for me: |
|
Yup, seems like it has been fixed... Last-Modified header TZ is GMT now. $ curl -IL https://adoptopenjdk.jfrog.io/adoptopenjdk/deb/dists/xenial/Release
HTTP/1.1 200 OK
Date: Thu, 18 Jun 2020 18:46:17 GMT
Content-Type: application/octet-stream
Content-Length: 5285
Connection: keep-alive
X-Artifactory-Id: adoptopenjdk-artifactory-primary-0-adoptopenjdk
X-Artifactory-Node-Id: adoptopenjdk-primary
Last-Modified: Wed, 17 Jun 2020 12:56:25 GMT
ETag: 3b1e63e4fdf360bc8e04f5b688adf9184ceab02d
X-Checksum-Sha1: 3b1e63e4fdf360bc8e04f5b688adf9184ceab02d
X-Checksum-Sha256: a34410d12fff57b039269433835a674f3fb94b4dee624d9cf63f294255a2bd93
X-Checksum-Md5: 21cce52419c5920a0d39786e17bc32dd
Accept-Ranges: bytes
X-Artifactory-Filename: Release
Content-Disposition: attachment; filename="Release"; filename*=UTF-8''Release
Cache-Control: no-store
Strict-Transport-Security: max-age=15724800; includeSubDomains
X-Request-ID: 3b9188cc78466f83dcbccab40e9959baTested installation of debian packages from the repo.. Looks all good 👍 |
|
Hi, it seems JFrog fixed the issue. I have an automation script and it works again, no manual steps as suggested above. |
|
This issue seems to have been solved.
Can you confirm action taken? |
|
Our Jenkins Jobs were finished successfully today. I can confirm, that this problem is solved for us. Thank you everyone. |
|
This problem should be fixed. If anyone experiences any problems, please get in touch. I'm very sorry for the extended outage of our Debian package repositories and that it took more than a day to sort it out. This is not an acceptable level of service for any AdoptOpenJDK offering. To the best of my knowledge, this is what happened (all times in UTC): On Wed, June 17, around noon, our hosted Artifactory instance has been upgraded to v6.18.1. This included a version of Apache Tomcat that could return HTTP date headers in other time zones than GMT which is forbidden by the relevant RFCs. Apt, the package management tool of all Debian flavours, relies on those headers and as a consequence stopped working. We investigated the issue, but quickly discovered that we cannot fix it on our end. At 13:48, we contacted JFrog support by email and asked for a rollback to the previous version or an upgrade to a patched version. JFrog support got back to us on Thu, Jun 18, 16:45, and acknowledged the problem and promised an upgrade to an unaffected version of Artifactory. At 22:59, we were informed that Artifactory has been upgraded to v6.20.0 and that the problem should be resolved. This incident highlighted multiple issues with our current setup and arrangements with our suppliers. We'll carefully review everything and institute the necessary changes. |
|
Works again! Great! Thank you everyone! |
|
Thanks for the detailed information @aahlenst |
|
Works again! |
This reverts commit d5ae1b6. adoptium/infrastructure#1399 has been fixed now.
|
E: The repository 'https://adoptopenjdk.jfrog.io/adoptopenjdk/deb jammy Release' does not have a Release file. Jan/8/2023 |
|
Tried to manually get the termurin-8-jdk but when trying to execute it, it displays: "Error: Dependency not satisfiable: adoptium-ca-certificates" i do have ca-certificates-java installed though. |
and others
Since Wed, June 17, around noon (UTC):
Problem seems to be the HTTP headers:
Problem seems to be this line:
Last-Modified: Wed, 17 Jun 2020 14:56:24 CEST. This should beUTCorGMT, notCEST.This seems to be a known problem in Artifactory: https://www.jfrog.com/jira/browse/RTFACT-21640. But it should already have been fixed, so I have no idea why it pops up now.
Regenerating the package index hasn't helped.
I'm going to raise this with JFrog.
The text was updated successfully, but these errors were encountered: