Closed alkisg closed 2 weeks ago
@alkisg
Let me do a quick investigation as to why that line was changed. I do not recall and think it was just in this repo for testing.
@alkisg
I have merged a fix to return the "one-liner" to its previous state. I couldn't revert it as the other two fixes in that patch were valid and needed fixes. Thanks for bringing this to my attention.
FYI: I would not have caught this because I no longer test with kernel 4.9. What I do is stop testing kernels once they are no longer supported. Right now the oldest LTS kernel that is still supported is 5.4 and it drops off in 2 months. I do some consulting so I am very familiar with some organizations and companies that try to use very old kernels in product development. This is usually a BAD idea. The desire comes about because some sbc makers do a poor job of keeping their support current. My advice is for those organizations to carefully choose the hardware they use and make sure a modern, supported kernel is part of their support.
Thank you Nick. I've tested it from Jessie to Bookworm and from Xenial to Oracular and found no compilation issues.
Re: LTS kernels, the distributions have their own kernel maintainers and do not follow the upstream LTS kernel concept. And since users mostly use the distribution kernels and not the upstream kernels, I'm inclined to support specific distributions, not specific upstream kernels. In general oldoldstable for Debian, and LTS-2 for Ubuntu, but if things happen to work for even older versions, even better.
Thanks again, closing this ticket.
Copy all.
Re: LTS kernels, the distributions have their own kernel maintainers and do not follow the upstream LTS kernel concept.
Some do follow the upstream LTS support concept. Debian would be one example. Raspberry Pi is another example. Those that don't, such as Ubuntu, will have a modern kernel update available on older releases.
I'm inclined to support specific distributions...
I understand this. We are not headed toward the same goal. My goal is to support as many distros as is possible. You can't do that or it would be a full time job. Our skills do complement each other and I do appreciate your help.
I will continue doing what I am doing and since you know what that is, you will know if I am testing specific kernels but looking at the mainline support schedule and if something important comes up on an old unsupported kernel, do what you did with this report and we'll figure something out.
Have a good weekend.
@morrownr
Checklist
uname
Linux jessie-mate 4.9.0-0.bpo.12-686-pae #1 SMP Debian 4.9.210-1+deb9u1~deb8u1 (2020-06-09) i686 GNU/Linux
lsusb
Bus 001 Device 034: ID 0bda:8812 Realtek Semiconductor Corp. RTL8812AU 802.11a/b/g/n/ac 2T2R DB WLAN Adapter
What happened?
The driver fails to compile on stock Debian Jessie 8, with its 4.9 kernel. Yeah that's an old one, not worth spending a lot of time on it. But the previous 8812au-20210629 tree worked there, and the fix is a oneliner. In the Makefile, just revert:
EXTRA_CFLAGS += -O2 -std=gnu11 -Wno-declaration-after-statement
To what it was before commit c25246be, i.e.:EXTRA_CFLAGS += -O1
Nick of course if you prefer to support newer distributions only, gnu11 and up, feel free to close this issue. I just test on my newest and older VMs and this is the only one of the 8812au, 88x2bu, 8821cu and 8852bu drivers that now fails to compile there. The others work fine.