Yeah, the first point is why I've been following the 24.10-SNAPSHOT vs. a tagged RC on the 24.10 branch... it means I can get granular updates when I have a few minutes to update the router, and makes it easy to keep up with new features / bug fixes (or help ID new bugs) as things change.
But my comment about being able to upgrade to 24.10-SNAPSHOT was only to point out that it seems there's something specific in the RC5 builds/agents vs. it being a generic trait of the 24.10 source tree / state.
Currently on 24.10.0-rc5 built using Dynalink DL-WRX36 sysupgrade image + manually adding all packages (due to issues with firmware-selector site displaying init when trying the same there).
Successfully built an image using: owut download -V 24.10-snapshot
Now tried: owut download -V 24.10.0-rc5 or owut download -V 24.10.0-rc5 --force and getting errors...?
Traceback (most recent call last):
File "/usr/local/lib/python3.12/site-packages/rq/worker.py", line 1633, in perform_job
return_value = job.perform()
^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/rq/job.py", line 1331, in perform
self._result = self._execute()
^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/rq/job.py", line 1365, in _execute
result = self.func(*self.args, **self.kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/app/asu/build.py", line 155, in build
container = podman.containers.create(
^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/podman/domain/containers_create.py", line 354, in create
response.raise_for_status(not_found=ImageNotFound)
File "/usr/local/lib/python3.12/site-packages/podman/api/client.py", line 74, in raise_for_status
raise not_found(cause, response=self._response, explanation=message)
podman.errors.exceptions.ImageNotFound: 404 Client Error: Not Found (no such image: ghcr.io/openwrt/imagebuilder:qualcommax-ipq807x-v24.10.0-rc5: image not known)
ERROR: Build failed with status 500```
It looks like we hit the wall with the master snapshots - one of the ABI-versioned packages was updated. Has there been any progress with fixing the underlying packaging tools?
Yeah, this first one is pretty easy to deal with, just remove the package:
$ owut download --remove libubus20241020
This works because libubus is not a top-level package (it's only there because something depends on it), and since nothing in the new package list depends on the 20241020-named version, owut thinks "fine, it's no longer needed, so carry on". When you go to build, all the packages that actually depend on libubus will pull in the new version libubus20250102 as a new package, so everything falls into place.
Since there's no way to automate this into owut, we'll have to do a manual intervention until the ABI data appears in the package/index files, bringing us to...
Oh, and since I'm speaking of --remove, I just added a new feature yesterday: both it and the --add option will now accept an argument delimited by whitespace, in addition to commas. I did this because I had wanted to test removing a bunch of packages that were listed in a file and didn't want to jump through hoops editing the file's contents.
I'm not sure if it's intended?
Adding init-script, then adding --force, 2x errors occur if the image on the server contains an identical init-script...
Request:
Version 24.10-SNAPSHOT r28308-c06d4df974 (kernel 6.6.69)
Included init script '/tmp/99-asu-defaults' (1938 bytes) in build request
Request hash:
23481b46d8c71ee25c6082320f79f19afb2f8e58054de79827fb7971458b4fca
--
Status: queued - 0 ahead of you
Progress: 0s total = 0s in queue + 0s in build
--
Status: init
Progress: 3s total = 0s in queue + 3s in build
Build failed in 3s total = 0s in queue + 3s to build:
ASU server error =
Traceback (most recent call last):
File "/usr/local/lib/python3.12/site-packages/rq/worker.py", line 1633, in perform_job
return_value = job.perform()
^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/rq/job.py", line 1331, in perform
self._result = self._execute()
^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/rq/job.py", line 1365, in _execute
result = self.func(*self.args, **self.kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/app/asu/build.py", line 142, in build
defaults_file.parent.mkdir(parents=True)
File "/usr/local/lib/python3.12/pathlib.py", line 1311, in mkdir
os.mkdir(self, mode)
FileExistsError: [Errno 17] File exists: '/home/openwrt/public/store/23481b46d8c71ee25c6082320f79f19afb2f8e58054de79827fb7971458b4fca/files/etc/uci-defaults'
ERROR: Build failed with status 500
The above errors are often due to the upgrade server lagging behind the
build server, first suggestion is to wait a while and try again.
It could me my interpretation of how I issued the command line with init-script?
Nope, you are doing everything correctly, that's a bug in the ASU server. I'm embarrassed to say that I found that 3-4 months ago, but forgot to submit the fix. Will do so right now...
Anyone here have an OpenWrt One? If so, could you post the output of the following? I'm curious about the block devices when you have both nand and nor storage on the same device (relates to some work I'm doing on --rootfs-size).
I'm writing a script that'll convert the default owut generated firmware.* files to an openwrt-24*.firwmare.* format, to archive builds by the generated name found in the firmware-manifest.json.
I noticed a difference between the: development snapshot & release candidate snapshot names, and I'm guessing there'll be a different format for the release versions?
Where <version> on the release branches is something like 23.05.5, 24.10-SNAPSHOT or 22.03.0-rc4. (Note that unlike most web addresses, the version names are case sensitive, so 24.10-snapshot will not work, you'll get a 404.)
For the image names themselves, the naming convention is consistent across releases and between the release and snapshots:
Right, from the firmware selector, but you don't know what that hash in the middle is until you know the full package selection and run it through https://github.com/openwrt/asu/blob/main/asu/util.py#L147 (which is what gives each ASU image its unique name). If you go to downloads, it's the same but minus the -8a...22.
The various ASU clients don't even bother constructing the name, they look into the manifest.json at the images array (your json snippet a couple posts up) and search for the entry with the applicable filesystem and type, then grab the name entry directly.
the opkg manager name has changed and the image is not built if there are old language packs related to the old manager name.
However, the manager is automatically changed during the build, but the language packs are not.
Even after deleting the old language packs and running the build, it is built, although without errors, but without new language packs.
Is the problem in dependencies?
Since with other packages that have language packs for LUCI, they are pulled in automatically.
Not getting this error anymore!
