So this version is available. For example, TP-Link TL-WR1043N / ND v1 (ath79 / generic) 19.07.9 was assembled several months ago, now it is no longer supported. If not supported, what is the reason for making the choice?
Just because it can?
Perhaps your observation may prompt an update to the menu soon if this issue has simply escaped notice. Until then, the servers will just have to keep telling us the kitchen has run out of ingredients to make an old dish.
Then again, everyone working in this restaurant volunteers their time for free to do so after they finish their day jobs. It may simply come down to prioritizing their limited resources.
No problems. I understand perfectly well that this is all enthusiasm and no one owes anything to anyone. If old versions are not even supported as updates, then nothing prevents you from building the versions selected on this site from ready-made packages. This is much more convenient than collecting on your computer before downloading gigabytes of files. All these files are ready-made on the project servers, and for example, TP-Link TL-WR1043N / ND v1 (ath79 / generic) on versions above 19 is very slow...
the listed sysupgrade image's SHA256 checksum seems to be incorrect.
The page says it should be: 1419e575635082a5435ce8f55069120b1786bc3d062eab56a64b5492b2d5757d
but the actual image I download has a different SHA256 checksum:
I've tried downloading the image several times, and the checksum has remained the same, but different from what the page says it should be.
Would you please help?
Hopefully a site sysadmin or someone with insight can reply about the checksum on the software selector page.
Here is my take:
I tried it and got the exact same results. I then went to the download page https://downloads.openwrt.org/snapshots/targets/mvebu/cortexa9/
and it shows the sha256sum as 768ea82074a5ea23349765c61f907b6eabc8f0a0b9e4dffc742f76c9b2e67f1f
for file linksys_wrt3200acm-squashfs-sysupgrade.bin
If the device is unbrickable or there is sure way to recover from a bad image that I'm comfortable with, I would go ahead and use it. You can make that judgement for yourself. You can wait a day and see what the next build shows.
UPDATE: I just refreshed page https://firmware-selector.openwrt.org/?version=SNAPSHOT&target=mvebu%2Fcortexa9&id=linksys_wrt3200acm
and it now shows the correct sha256sum. Hopefully you are all set.
I noticed that the date in the "About this build" section near the top was in the future compared to my local time so I wonder if things were just not complete yet when we both were looking at it the first time. It may be a good idea to wait to download until it is a couple hours past that date as GMT time. I don't know where the build servers are but so far I've see dates as much as 6 hours ahead of my local (USA) time.
It looks like the only part that was out of sync was the presentation of the shasum data on the firmware selector web page. The sum agreed with the data on the download page that is linked to by the button.
Im not a web developer but looking at the data used for the web page for the firmware selector, it looks like there is a file that provides the shasum data and the timestamp on that .json file looks to be after we first downloaded the image and did our sha256sum check. I had done a browser refresh and got the same info so I don't think it was browser cache. I don't think I visited that page recently or ever as I don't own that device.
If any packages are updated in a release (for example, 22.03.3) and I try to build an assembly with my packages with which I already built the same assembly, then at the output I get my previous assembly from the site cache and I have to remove or add which -something item, or wait indefinitely to compile with updates...
It would be correct if I did it just because there was nothing to do, but .... As I wrote, some packages were updated in the stable version of the firmware, for example - 5 packages. Can't have the same hash and package size? That's what I think. It would be correct if nothing had changed and I would have collected exactly the same image from nothing to do, but this is not so))
It would be correct to delete images after 1 hour, for example, and not after 7 days, or even better, keep track of the compilation date of the selected packages and if it has changed, collect the image without even waiting for this 1 hour.