Preconditions/Environment ------------------------- A PREMIRROR that doesn't support https Triggering Action/Cause ----------------------- bitbake a recipe that uses https protocol and fetches from github. Expectation ----------- Try to redirect to http and download the archive? Skip the PREMIRROR and download from upstream... Actual Result ------------- wget fails when trying to fetch from the premirror because https is reserved for a login page. wget gets redirected to the login page, download the HTML, tries to untar the html page, then obviously fails to untar it. I was trying to build tools inside meta-clang layer. URL transformed to HTTPS due to an HSTS policy is a warning given by wget. Reproducibility --------------- 5/5
A real-life example of the problem http://errors.yoctoproject.org/Errors/Details/220286/
I'm not sure this is a bitbake problem but a misconfigured server. The logs show a fetch of http://bitbucket.org/eigen/eigen/get/3.3.7.tar.bz2 which redirected to https://bitbucket.org/eigen/eigen/get/3.3.7.tar.bz2. The fact that this redirected url is invalid is an issue with the hosting of those files. I tried this locally and it worked so perhaps you could retest please? Perhaps the server issue was fixed?
The redirect URL isn't invalid, you can see that the file was downloaded without problem: 2019-01-30 00:25:44 (3.51 MB/s) - ‘TOPDIR/../downloads/libeigen-3.3.7.tar.bz2’ saved [1665168/1665168] But then for some reason, the fetcher can't find it? How can that happen?! " The fetch command returned success for url http://bitbucket.org/eigen/eigen/get/3.3.7.tar.bz2 but TOPDIR/../downloads/libeigen-3.3.7.tar.bz2 doesn't exist?! " I was not able to reproduce the error ever on local. It only did it on the remote build machine that yocto is using. When I sent the patch I made sure that it worked on local first. The only error I was able to create was when I trying to build a recipe from the meta-clang layer that had the protocol set to https. But my company PREMIRROR that had the cache tarball doesn't support HTTPS. But you can download the tarball in HTTP no problem. HTTPS on the PREMIRROR is reserved for a login page. That's probably another issue though.
To get around the redirection of HTTP -> HTTPS, I had to modify the FETCHCMD_wget with FETCHCMD_wget = "/usr/bin/env wget -t 2 -T 30 --passive-ftp --no-check-certificate --no-hsts" I added the "--no-hsts" part.
Richard, It appears that Maxime has answered your question. I am moving it to Accepted unless you have other questions.
It appears that his was a problem with the local network configuration. If it is not, please open a new more clear bug describing the issue.