Fix base-files not being able to download because packages.debian.org is down #6763
Conversation
ColorfulRhino
force-pushed
the
base-files-fix
branch
from
8d6ab2e
to
5a29f91
Compare
|
|
I've been avoiding everything
This method is only used if the original website can't be reached. I think it's definitely better than not being able to build at all :) And at least on my machine this was somehow cached, meaning on the second build it went through this step almost instantly. |
I guess then it would be an unsupported build host anyways. As for me I never had an issue with missing xz-utils on any host I did building. |
Thanks for sharing your experience! I have changed it to xz since both of you are in favor of it 👍 |
|
Hi @ColorfulRhino - a suggestion from top of my head: should you make it dependant on a global config variable (let's call it Whether to have it as an alternative backup method for downloading base-files seems reasonable from an end-user perspective, can't speak about CI builds. |
packages.debian.org has been down a lot lately, so builds could not finish since the build system wants to find out the package name and version for `base-files`. Use `Packages.gz` from the mirrors as an alternative method to search for this information.
| display_alert "Could not find package filename for '${sought_package_name}' in '${package_info_download_urls[*]}'" "Trying alternative method to get ${sought_package_name}" "warn" | ||
| # Try alternative method since packages.debian.org is down often | ||
| # Use -N with wget so it always downloads the latest file, overwriting the local one if it exists | ||
| run_host_command_logged wget --no-verbose -N https://${mirror_with_slash}/dists/${RELEASE}/main/binary-${ARCH}/Packages.xz |
There was a problem hiding this comment.
Yeah I'm pretty certain this will break under multiple simultaneous executions, as it writes to the "current directory", and that might be the same directory when run in the prepare json matrix pipeline job. Ideally this should be done without touching the disk, by using a series of pipes. Those parallel jobs are run with CONFIG_DEFS_ONLY and other wide-affecting flags too, so beware.
There was a problem hiding this comment.
Ah, the intricacies of the build scripts 😅
Maybe it would work if it's saved to the cache directory?
A solution in the line of what @alexl83 said would be possible as well, but would on the other hand add yet another build flag that probably not many people would even know of and use 😅
Also I think finding a solution that CI can use as well would be nice since build errors in CI triggered by Debian/Ubuntu website being down is bad, it distracts from the real errors.
There was a problem hiding this comment.
The "real" solution to this is to move it out of band; implement the gathering of information (incl base-files version and references, but also other info about the RELEASE+ARCH) to a scheduled, frequent, GitHub Actions job. We'd get all the info required, massage and process it into a format for easy armbian/build consumption, and publish it in a git repo. Then armbian/build would only fetch from that repo -- a mechanism we already do for many of the packages.
There was a problem hiding this comment.
@rpardini Is the "real" solution something being planned / worked on at the moment ?
PS: As a image build user, I can't build anything when ubuntu / debian official sites act up and it has been a lot lately :-( and it is not armbian fault of course :-)
Description
packages.debian.org has been down a lot lately, so builds could not finish since the build system wants to find out the package name and version for
base-files.Use
Packages.xzfrom the mirrors as an alternative method to search for this information.How Has This Been Tested?
Checklist: