Zyxel EX5601-T0 ubootmod
OpenWrt 25.12.3 r32912-6639b15f62 / LuCI openwrt-25.12 branch 26.124.02521~c1d16b5
As far as I'm concerned it's official when it appears on owut check lol.
2 Likes
TBH, owut notifications should be gated until a new release is officially announced (maybe a new feature for a future release?)
Right now, owut is offering updates for a new release even when not all targets have been built yet. Issues with specific targets may require the build to be restarted, and there is a chance that the new build (even if it is the same version) might end up being different from the one initially offered by owut.
So for now, even if owut is notifying that a new version is available, it is recommended to wait for the official announcement of a new version before upgrading (basically ensuring that the build is successfully completed for all supported targets).
Anyway, nothing will prevent anyone from installing a new update that is available (but not officially announced) via owut or even manually, at their own risk (I did this many times! 
).
1 Like
owut is only relaying what upstream is telling it, as are Firmware Selector and LuCI ASU app. These clients have no idea what's going on with the buildbots, container builds or ASU server.
No announcement doesn't mean it's not available yet.
It's available for download on the official place by more than 24h ago.
Availability and announcement are two different things (basic school-level logic). If they don't coincide that means someone (or something) isn't doing good job.
You just prove that your previous statement was false 
Agreed. I have to wait even though I could compile my own now if I want to, but generally I would just wait to be safe and didn’t encounter any error during compile.
... and I just install it. Just for others to be safe and sure, that no broken image was released (happened before).
okay ive been struggling with version 25.12.2 and also 25.12.3
NONE of this is a critisim to the awesome work of the Openwrt Devs and its very supportive community, im just trying to do my part!
i tried to put up a post for each issue but i only managed to put up a few and also pin on to existing topics. In my posts i spoke about a few issues i ran into during my transition from Version 24.10.5 to 25.12.2 (as well as some breakage for the new 25.12.3)
- acme-acmesh not included as dependency
acmeinstalls withoutacme-acmesh, no init.d script created, silent failure with no useful error. - acme debug mode breaks DuckDNS validation when
debug=1, the_duckdns_restfunction requires both "UPDATED" AND "OK" in the API response, but DuckDNS only returns "OK" for new TXT records, causing silent failure. - LuCI ACME credentials field adds double quotes around token value the credentials field wraps values in double quotes which get passed literally to the DNS API script, corrupting the token.
- AdGuard blocks acme.sh DoH verification to cloudflare-dns.com acme.sh uses Cloudflare DoH for DNS propagation checking, If AdGuard blocks it theres no warning, causing acme to loop indefinitely with no useful error.
- WireGuard listen_port not persisting via LuCI port saves in UI but doesn't write correctly to
/etc/config/network, interface comes up on port 0. (EDIT: This may have been caused by a malformed peer, and it can be found with logs but it seems like a a Silent fail from Gui, see next bullet below) - WireGuard peer endpoint DNS failure brings down entire interface single unresolvable peer prevents whole interface from starting.
- force_link and MTU not set to sensible WireGuard defaults causes carrier absent and MTU fragmentation with no guidance.
- Attended Sysupgrade 25.12.2→25.12.3 failed ubus-random-seed version conflict caused corrupt files requiring full reinstall.
- Upgrade documentation overstates transparency of 24 to 25 migration acme restructuring, DHCP/DNS tab separation, for apk replacing opkg seem undocumented changes.
- ClamAV daemon looks for config at
/usr/etc/clamd.confdespite LuCI correctly pointing to/etc/clamav/clamd.conf— hardcoded path mismatch between the binary and the package config location.
I do love some of the new features for 25 (tab separation is great; love the acme log tab seriously! and i like the assisted upgrade though at the moment its best used for known routers and not "custom" builds).
I hope this helps in some small way! and i will try to contribute where i can!
2 Likes
acme-acmesh not included as dependency
acmeinstalls withoutacme-acmesh, no init.d script created, silent failure with no useful error.
sorry I break that, I made alt backend that use luci-app-acme from uacme (because it can run with mbedtls), and tried to make acme metapackage to depend either acme.sh or uacme, but I only tested with menuconfig, looks like apk itself doesn't get either A or B depend config and removed it entirely
3 Likes
If you understood in this way, you need to read it again.
I said:
No announcement doesn't mean it's not available yet.
There is no new release announcement and a new release is available. It proves exactly what I said.
A new version was released. It's available by almost 48h.
If someone forgot to announce it, or don't have time to do so, or they are delaying the announcement just to avoid everyone downlaoding at the same time, this is another thing to take into consideration.
The time between tagging a new version and announcing it is used for: building ALL targets (2-3 days if no errors occur) and testing.
So chances are good you are lucky and your target got fished early. Chances are also that some random package didn't finish in this time and you got a image with some funky bits hidden, waiting to blow some weird errors when you don't expect.
Edit: besides if you want to test early, cool. But if you are in a hurry, there is also 25.12-SNAPSHOT for the newest bits.
3 Likes
When it's available on the stable channel. It's not a building for testing.
25.12.3 is already avaiable on Firmware-Selector, ASU and owut
If an annoucement is needed to consider an stable release as stable, so the proccess should be:
- building all targets --> announcement --> release
And not:
- building all targets --> release --> announcement
2 Likes
- So, you want the developers to hide the targets while they build?
- In your opinion, what does the "release" step entail?
I know you've only been on the forum 2 years, but there used to be issues with that approach as well.
1 Like
No. Just make an intermediate release to test the build.
- Freeze
- Build
- Passed?
3.1 Yes --> Make it available at the offical places.
3.2 No --> Fix the issue and go back to step 1
If there is an issue, it should not be available at the stable channels.
Stable is not "testing", or "rc" or "snapshot"...
- So you want 2 builds because of the time it takes to release 1?
- How will that improve the situation?
I don't follow your statements here. Perhaps you misunderstand what's occurring. What issue?
Pass what?
Stable channels?
- Snapshot- development built daily
- Previous versions...
- 25.12.x - frozen again
- rc
- .0
- .1, etc.
There's a Wiki explaining each development branch and the lineage of the codebase.
Also a summary of the actual various steps involved with doing so.
If you mean test every device, that's not possible with the community, and even then users may dispose of previous device, not have the skills, resources or time (i.e., needing to recover the device), etc.
1 Like
The issue - as noted upthread - is that currently ASU shows the new version as soon as a particular target is built.
2 Likes
Yes, hiding was a [decent] suggestion? 
Those systems previously had an issue where a new release wouldn't display a new release after an announcement had taken place. It was just fixed recently. There were also reports of that. Just FYI [if giving consideration] regarding the developers time.
1 Like
Yeah, that would be preferable – but in its absence people are going to assume something is released, and well criticising them seems counter productive.