Backporting big complex pieces of code like wireless stack is a bad idea from very beginning. Especially if resources are limited. But, I suppose, widening hardware compatibility list is a project's priority.
2 Likes
sometimes we change our eyes for our tails that s linux
Maybe not enough people with platforms that would be affected tested the release candidates?
It's all very well going on to suggest that there should be X, Y and Z testers with A, B and C platforms - but nobody's getting paid here, so an absence of feedback (as with all open source efforts) is usually seen as a tacit "Ok".
These things happen. They suck. But if you're not stepping forward with an actual answer or getting involved, they might happen again.
1 Like
I think you've made a sensible suggestion to execute a benchmark test suite to detect regressions before a stable release is "released" fully. Only the developers know if their time is worth managing such a thing, but the suggestion is not a bad one.
I don't see a connection between the merits of the suggestion and placing external blame on the source of the bug. A noticeable performance bug got through; it was identified, squashed and fixed essentially immediately after release; and a benchmark suite executed once only (just before release) would have very likely caught it.
My sense is main snapshot sees enough real time testing from users wanting to run bleeding edge that bugs get noticed and squashed fairly quickly in main snapshot. Whereas, I suspect stable snapshots see far less real time testing, but that could just be because I never use stable snapshots.
If I want stable, I install a stable point release after it has been "benchmark tested" in its release announcement thread 
, not an in-progress stable snapshot that has not. In any event, the present issue provides evidence these stable release announcement threads do a good job of benchmark testing the releases. "These things happen" isn't a bad approach in this sense for a resource limited project.
5 Likes
Hello & Thanks to developers for 23.05.4
Im wondering, that I cant install under X86/64 running in Proxmox, neither QOSIFY package neither SQM ...thats sad, hope a solution comes soon, I rolled back, without Problems to my Proxmox VM with 23.05.3, where QOSIFY etc works.... see picture, when I try to install QOSIFY under 23.05.4, missing dependency ...... ->
Thank you. I thought after enabling advanced settings i would see SNAPSHOT builds listed as a firmware option under "Attended Sysupgrade" as an option. What am i missing? I might download the snapshot build and flash that way, but if i can do it via the attended sysupgrade route, i'd prefer to figure that out. Any ideas? Screenshot doesn't show it in the drop down, but the only option in the drop down of "select firmware version" is the one that is [installed].
Adding screenshot as a sanity check to make sure there really isn't another option. Especially since at the top it says "new firmware available".
I decided to try something else. I tried
auc -c -b 23.05 -B 23.05-SNAPSHOT
from terminal, then i it starts to do stuff, then eventually errors out with
Error: Received incorrect version r24016-f791ec1f6d (requested r24014-76a0c2932c)
Bad message (77)
which my research hints could be an error with the caching of the build server? Anyways, i'll just wait it out for tonight and try again later. I posted all the above in case it helps someone.
I'm editing my post, as i think i found the information i was looking for regarding using auc or other means to upgrade to 23.05-SNAPSHOT from current 23.05.4
https://forum.openwrt.org/t/attended-system-upgrade-broken/205454
Would you like to test this on 23.05-SNAPSHOT before a new release is made? Then please do it and share your results. The community will be thankful for your quality assurance testing.
No need to transfer files manually. 23.05-SNAPSHOT sysupgrade files are being built daily. Download the files whenever you like. You can test the current snapshot each day.
Will you look at my previous post and see what i'm doing wrong to move to snapshot. I don't mind testing and reporting. I'm hoping if i just use luci-attended-sysupgrace or auc from command line, i can keep luci and settings going without having to continually flash, load luci, configure settings and such. I could start a new thread, but i thought if simple, maybe those following and wondering how they can contribute testing might just see it here.
luci is included in stable branch snapshots. You could keep all settings if your source installation is from 23.05 stable series, too. Just need to reinstall additional packages, as always after classic sysupgrade.
If you use auc or luci attended sysupgrade the process might be different.
1 Like
@PhilArmstrong
You are right. I stand corrected.
The dependency is obscure, as it is not directly coming from the luci-theme-openwrt Makefile, but instead from the global luci.mk, which has dependency logic for packages that are still based on lua. That confused me when looking just from the source repo. I have now looked it at my build system, and the dependency is more visible.
The ancient luci-theme-openwrt is the only theme still having lua as base, while all other supported themes (default bootstrap, openwrt-2020 and material) are already javascript/ucode based. That causes an implicit dependency on luci-lua-runtime.
@jow converted all other themes to ucode in Oct 2022, but seems to have left the header & footer in the old luci-theme-openwrt unconverted. Not sure if that was intentional (and still necessary) or just an oversight.
That dependency is clearly visible when looking from build system menuconfig:
│ Symbol: PACKAGE_luci-theme-bootstrap [=y] │
│ Type : tristate │
│ Defined at tmp/.config-package.in:60823 │
│ Prompt: luci-theme-bootstrap........................... Bootstrap Theme (default) │
│ Location: │
│ -> LuCI │
│ (1) -> 4. Themes │
│ Selects: PACKAGE_luci-base [=y] && PACKAGE_libc [=y] │
...
│ Symbol: PACKAGE_luci-theme-material [=n] │
│ Type : tristate │
│ Defined at tmp/.config-package.in:60834 │
│ Prompt: luci-theme-material....................................... Material Theme │
│ Location: │
│ -> LuCI │
│ (2) -> 4. Themes │
│ Selects: PACKAGE_luci-base [=y] && PACKAGE_libc [=y] │
│ │
│ │
│ Symbol: PACKAGE_luci-theme-openwrt [=n] │
│ Type : tristate │
│ Defined at tmp/.config-package.in:60845 │
│ Prompt: luci-theme-openwrt................................ LuCI OpenWrt.org theme │
│ Location: │
│ -> LuCI │
│ (3) -> 4. Themes │
│ Selects: PACKAGE_luci-lua-runtime [=y] && PACKAGE_luci-base [=y] && PACKAGE_libc [=y] │
│ │
│ │
│ Symbol: PACKAGE_luci-theme-openwrt-2020 [=y] │ Type : tristate │
│ Defined at tmp/.config-package.in:60857 │
│ Prompt: luci-theme-openwrt-2020........................ LuCI modern OpenWrt theme │
│ Location: │
│ -> LuCI │
│ (4) -> 4. Themes │
│ Selects: PACKAGE_libc [=y] && PACKAGE_luci-base [=y] │
3 Likes
Hello, @hnyman and @efahl, I read your posts about “luci-compat” and “*lua*” packages, I was curious and apparently I also have them installed and the package that installed them is “luci-app-unbound”, this package was never updated to JavaScript and is still based on “lua“, if it is not too much trouble, I was wondering if you (@EricLuehrsen or @jow) can update this package to JavaScript, because I think you are the maintainers of this package. Thanks!
Asus RT-AC88U HW:A6
Not sure if it is the snapshots, or something I did, but now I can only have one enabled device per radio a time. If I enable a second device wither all will be disabled, or the new enabled is enabled and the old will be disabled. More detail later.
Should I file a bug? As no one is helping me.
I also ran into this, running x86 EXT4 EFI on an nvme drive. Reboot loop but could enter failsafe and remove scripts uci-defaults, it was ok, but root partition was not. No matter what I tried I ran into issues (primarily read only root partition) so I decided to rebuild from scratch, when I used the automated method to expand root, and ran 70-rootpt-resize I would get a reboot loop.
Even manually performing the steps resulted in errors when I added enough packages to get past the initial root size which resulted it in being mounted read only, is there is an issue with the root fs resize steps? I do not see any errors when I run them and reported size appears ok.
The only way I got it back up and running was to boot another os and perform the parted and resize2fs from the other os and everything was ok.
Jow has now pushed the conversion from lua to ucode for luci-theme-openwrt both main/master and 23.05, so now all the themes in repo are without lua, = no need for luci-lua-runtime for them.
3 Likes
Is it possible to get software flow offload working on Asus Rt-ac51u somehow? Its working on wndr3700v4 but not 51u..
Should the bugs that were discovered be posted in the known issues?
1 Like
Please propose a text for critical showstopper bugs.
The mac80211 issue for example cuts the bandwidth to only one stream on wide spread dual stream devices and on 2.4 GHz. Some devices are affected, others are not. Linksys E8450 MT7622B with 23.05.4, dual stream station on 2.4 GHz:
144.4 Mbit/s, 20 MHz, MCS 15, Short GI
144.4 Mbit/s, 20 MHz, MCS 15, Short GI
Not affected from what I see.
Bug reports should from my perspective be show stoppers and the report should be specific, which targets are affected and which are not.
SQM doesn't work on ingress anymore with NAT Offloading. I've made a post:
SQM doesn't work with NAT Offloading anymore (v23.05.4) - Installing and Using OpenWrt - OpenWrt Forum
Also, packet steering doesn't work either.
In theory anyway, main snapshot is where the bleeding edge commits, random regressions and bugs are expected to be found. In practice, I've found issues are fixed so quickly in main snapshot that it is as stable as the stable releases. Perhaps more so considering that on a time weighted basis, issues in stable linger for quite some time waiting for the next point release.
It is all a matter of opinion of course, but a 50% decrease in 2.4 GHz wireless throughput in a a material population of devices is a major issue that merits a very timely point release to rectify in my opinion. We are after all talking about something called a "stable release" that is intended to be less bleeding edge, less prone to regressions, less prone to bugs.
There are different philosophies. When I last used it more than a few years ago, dd-wrt was maintained similar to main snapshot. Releases designated "beta" rolled out near continuously and anything like "stable" was a decade old and clearly no longer maintained. The beta releases were it, and they were more hit or miss than grabbing OpenWrt main snapshot on any given day. One had to read the forum lore carefully to identify the "good" betas. No thanks.
I like OpenWrt's philosophy of actually maintaining a stable branch better, but I do think the threshold and/or frequency for stable point releases is a bit too high. There can be a LOT of commits between stable point releases - clearly that compounds the risk of issues in something intended to be stable. If stable is not stable and the fix is in...why not issue a point release to make stable, well, actually stable?
If storage is an issue, there are many old stable point releases that could be trimmed down to their last point release. For example retaining 18.06.8 may suffice for posterity and let the 18 rc's and .0 through .7 go. I don't see much point in retaining release candidates for any major release. A little house cleaning might be a good thing.
2 Likes