Summary
fbuild cannot provision the ARM toolchain on Windows: the download of arm-gnu-toolchain-15.2.rel1-mingw-w64-x86_64-arm-none-eabi.zip (282 MB) restarts from zero every time it reaches roughly 80–98 MB, and never completes.
Reproduced via bash compile samd21 --examples Blink in FastLED, which drives fbuild <dir> build -e samd21.
Observed
Parsed from the progress output of a single invocation:
samples: 145 | peak MB: 98
restarts: 5
reset 98MB -> 4MB
reset 80MB -> 6MB
reset 96MB -> 3MB
Roughly 450 MB transferred for zero net progress, and the run still had not produced a toolchain. Every attempt dies in the same 80–98 MB band, which reads like a timeout or a dropped connection rather than a random network fault.
Impact
Two distinct problems, and the second is the serious one:
- No resume. The partial file is discarded on failure.
Accept-Ranges: bytes is advertised by the ARM developer host, so a ranged retry would pick up where it left off. Instead each retry pays full price.
- No progress across retries, so it cannot converge. Because every attempt starts at 0 and dies around the same offset, more retries do not help. This is not slow — it is non-terminating. On a connection where a 282 MB single stream cannot survive ~90 MB,
fbuild can never provision this toolchain at all.
This blocked local verification of a SAMD fix (FastLED/FastLED#4015); I had to fall back to CI, where the toolchain is already provisioned.
Suggested handling
- Retry with
Range: from the byte count already on disk rather than restarting.
- Cap retries and fail loudly with the byte offset, instead of looping indefinitely at the same place.
- Verify the completed archive by digest, so a resumed download is still provably intact.
Segmented/parallel fetch would also help, but resume is the part that changes whether it finishes rather than how fast. Related: FastLED/FastLED#3968 and zackees/zccache#1469 make the same case for a content-addressed fetch with conditional GET, measured at 3.7x on a comparable payload; a shared implementation would cover both.
Environment
- Windows 10 Pro 19045
- FastLED master,
bash compile samd21 --examples Blink
- fbuild resolving
arm-gcc 15.2.Rel1
Summary
fbuildcannot provision the ARM toolchain on Windows: the download ofarm-gnu-toolchain-15.2.rel1-mingw-w64-x86_64-arm-none-eabi.zip(282 MB) restarts from zero every time it reaches roughly 80–98 MB, and never completes.Reproduced via
bash compile samd21 --examples Blinkin FastLED, which drivesfbuild <dir> build -e samd21.Observed
Parsed from the progress output of a single invocation:
Roughly 450 MB transferred for zero net progress, and the run still had not produced a toolchain. Every attempt dies in the same 80–98 MB band, which reads like a timeout or a dropped connection rather than a random network fault.
Impact
Two distinct problems, and the second is the serious one:
Accept-Ranges: bytesis advertised by the ARM developer host, so a ranged retry would pick up where it left off. Instead each retry pays full price.fbuildcan never provision this toolchain at all.This blocked local verification of a SAMD fix (FastLED/FastLED#4015); I had to fall back to CI, where the toolchain is already provisioned.
Suggested handling
Range:from the byte count already on disk rather than restarting.Segmented/parallel fetch would also help, but resume is the part that changes whether it finishes rather than how fast. Related: FastLED/FastLED#3968 and zackees/zccache#1469 make the same case for a content-addressed fetch with conditional GET, measured at 3.7x on a comparable payload; a shared implementation would cover both.
Environment
bash compile samd21 --examples Blinkarm-gcc 15.2.Rel1