I'd been holding off on flashing a firmware selector generated sysupgrade myself, because though it reported a current snapshot before the build, after the build it reported something a few days earlier (pretty sure it was r27052 - positive the date was July 30).
I just flashed it anyway after reading your post and sure enough, it says it is actually the most current r27076-d604b2699b commit after all. Device is a Reyee RG E5, but doubt that matters.
I want to generate 2 (almost identical) images. Both for MT6000 and snapshot, only difference are some extra packages.
The first image is generated without any error.
Then the last 2 extra packages are removed and the image is generated again. Now it presents an error.
This seems not logical to me. It gets more confusing what causes the error.
Collected errors:
* opkg_download: Failed to download https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a53/luci/luci-app-attendedsysupgrade_24.205.37920~e55f9d9_all.ipk, wget returned 4.
* opkg_download: Check your network settings and connectivity.
* opkg_install_pkg: Failed to download luci-app-attendedsysupgrade. Perhaps you need to run 'opkg update'?
* opkg_install_cmd: Cannot install package luci-app-attendedsysupgrade.
I'm trying to do a custom build of the latest snapshot, but when I request the build it is giving me a build that I requested a few days ago of a previous snapshot. How can I force a new build rather than get a cached build?
I dont know if anybody reported the online outage but its not building my specific build for my linksys wrt3200acm. Probably wide-spreaded for the whole site. Tried two different devices and 3 different browsers and nothing was loaded.
I reported this to in another thread. Sysupgrade via luci isn't working..nor can I add packages to a "build request" online as it does nothing. Are these two separate issues?
Is there a ETA on this so I can prepare when to try and upgrade?
Why would a bug in the source affect the build service?
The build server uses the pre-made "quick build" toolkit where essentially everything for the specific target subset is already compiled, and just need to be re-packaged (meaning it rebuilds the file system based on packages, then creates the flashable images, which is why the process is so fast, compared to a full build that even on the OpenWrt build servers, takes 20-30 minutes per target).
Simply said, a bug in the source won't cause the build server to fail to respond. At most, if the build of the SDK fails, the new build won't be available on the server - in which case it falls back to the latest usable version.
FYI, the service seems to be back up and running as of ~3 hours ago. Thanks OpenWrt team for fixing it!
Could not reach API at "https://sysupgrade.openwrt.org/api/v1/revision/SNAPSHOT/ath79/generic?1725689569305". Please try again later.
Internal Server Error