Re: [RFC] Stop providing binary package updates for release builds?
Am Sun, Dec 12, 2021 at 08:42:52PM +0100 schrieb Jo-Philipp Wich:
>
> In my opinion, there is a fundamental decision to be made on whether we would
> like to pursue the goal of (also) being a binary distribution for
> routers/embedded appliances or if we simply concentrate on the build-from-
> source aspect and leave the binary package business to forks or other
> downstream distributions projects.
>
> Given that maintaining binary package distributions is hard and boring work we
> need to decide whether we want to fully and properly pursue this goal or
> rather not at all and focus on always porting master to the latest minor
> Kernel version and finding the optimal compilation flags for each SoC
> revision.
>
> I am interested in hearing you thoughts and comments on this matter.
Hi Jo,
I'm not exactly sure you mean to "only" stop uploading package updates
for release builds or if you'd at the same time also consider removing
the upgrade mechanism itself ("opkg") from the target images. The latter
would majorly increase the workload of testing new packages.
But I'm also opposed to just stopping to upload release package updates as
it is such a nice feature to have. Obviously it's really handy. Yes,
you can shoot yourself (and others) in the foot, but tell me one linux
distribution with strict gun control laws :).
Regarding "forks or other downstream distributions". Would be glad to
hear your personal choice of these, the ones you run on your own
routers. :)
If this notion made it into OpenWrt infra I can only _hope_ that a fork
gets made (again) :)
You can tell I write this half-jokingly, because I really don't think
anybody would seriously consider this.
Good night,
Seb
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC] Stop providing binary package updates for release builds?
On 12/12/21 20:42, Jo-Philipp Wich wrote: - The wiki actively discourages users from upgrading packages [1] - The overall sentiment in the forum is to instruct users to not/never upgrade packages [2] but to always upgrade to the next release, build from source [3] or use snapshots/IB To expand a bit on this, there have been plenty of instances where end users just go to Luci package upgrade page and do an "update all", and this breaks their system. This can fail for a couple main reasons: -sometimes the update of core packages breaks them, or breaks the dependent packages causing a softbrick (rarely, but has happened at least once per year to some) -space reasons, a lot of devices simply don't have the space to update anything, so offering "package updates" for these devices is just bad as that becomes a "shoot yourself in the foot" button. Yes, if the user is intimate with OpenWrt/Linux/embedded device development they can take informed decisions, but most end users simply can't do that and will do what everyone tells them to do in IT, "install security updates". In my experience, updating is not a problem if the end user is doing ONLY full firmware upgrades. I had pretty much no (upgrade-related) issues for years even on devices running on snapshot by just doing sysupgrade to new firwmare images. So I think the ability to just "update packages" on a running system should be inhibited by default and put behind some very strong warnings, while users should be pushed towards using full firmware upgrade images instead. This firmware upgrade can be either done through official releases, or through the "attended-sysupgrade" packages/infrastructure (it's a cloud server that runs an ImageBuilder and serves the device the assembled image, a project developed/maintained by aparcar) [1] Yes there are some specific devices (x86, raspberry and other SBCs) that can use a ext4 filesystem image, those can be an exception (maybe), but for all devices with onboard flash there isn't much choice imho. On 12/12/21 20:42, Jo-Philipp Wich wrote: > - Simplify release branch maintenance, build images every few months and in > case of security issues in vital components like openssl or dropbear we > could instruct users to wait for the next maintenance release or switch to > snapshots What's wrong with doing a "emergency maintenance release" (i.e. just an unsheduled "rebuild all" with the fixed packages) if there are core packages affected by important security fixes? From my (and others) experience above, as long as the end user is doing a full firmware upgrade it's all fine, so the end users can just be told to download the latest OpenWrt firmware image and do a sysupgrade, which is also how it works for most embedded devices anyway. Telling people to wait for months (until a next minor release) for security updates or switch to snapshot is a huge middle finger to many end users that have chosen OpenWrt for higher security/privacy than stock firmware (and its slow/nonexistant security updates). 1. https://github.com/aparcar/asu -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 21.02] mac80211: Update toversion 5.10.83
On 13.12.21 15:00, Hauke Mehrtens wrote: On 12/13/21 2:16 PM, Koen Vandeputte wrote: On 12.12.21 22:18, Hauke Mehrtens wrote: The following patches were backported from upstream before and are not needed any more: package/kernel/mac80211/patches/ath/980-ath10k-fix-max-antenna-gain-unit.patch package/kernel/mac80211/patches/subsys/307-mac80211-do-not-access-the-IV-when-it-was-stripped.patch Signed-off-by: Hauke Mehrtens --- package/kernel/mac80211/Makefile | 8 +-- .../patches/ath/542-ath9k_debugfs_diag.patch | 4 +- .../ath/551-ath9k_ubnt_uap_plus_hsr.patch | 4 +- .../ath/930-ath10k_add_tpt_led_trigger.patch | 4 +- ...rolling-support-for-various-chipsets.patch | 14 +++--- ...75-ath10k-use-tpt-trigger-by-default.patch | 2 +- ...980-ath10k-fix-max-antenna-gain-unit.patch | 49 --- ...-power-reduction-for-US-regulatory-d.patch | 8 +-- .../100-remove-cryptoapi-dependencies.patch | 10 ++-- ...ort-immediate-reconnect-request-hint.patch | 2 +- ...-the-fwd_skb-dev-for-mesh-forwarding.patch | 2 +- ...t-access-the-IV-when-it-was-stripped.patch | 26 -- ...-get_default_func-move-default-flow-.patch | 2 +- ...ot-maintain-a-backlog-sorted-list-of.patch | 2 +- ...add-rx-decapsulation-offload-support.patch | 18 +++ ...le-QoS-support-for-nl80211-ctrl-port.patch | 6 +-- ...pply-flow-control-on-management-fram.patch | 2 +- ...set-sk_pacing_shift-for-802.3-txpath.patch | 2 +- ...MPDU-session-check-from-minstrel_ht-.patch | 6 +-- ...eee80211_tx_h_rate_ctrl-when-dequeue.patch | 8 +-- ...te-control-support-for-encap-offload.patch | 2 +- ...rting-aggregation-sessions-on-mesh-i.patch | 2 +- ...introduce-aql_enable-node-in-debugfs.patch | 4 +- ...to-a-virtual-time-based-airtime-sche.patch | 6 +-- ...eck-per-vif-offload_flags-in-Tx-path.patch | 2 +- ...nl80211-add-support-for-BSS-coloring.patch | 2 +- ...211-add-support-for-BSS-color-change.patch | 6 +-- .../patches/subsys/400-allow-ibss-mixed.patch | 2 +- 28 files changed, 65 insertions(+), 140 deletions(-) delete mode 100644 package/kernel/mac80211/patches/ath/980-ath10k-fix-max-antenna-gain-unit.patch delete mode 100644 package/kernel/mac80211/patches/subsys/307-mac80211-do-not-access-the-IV-when-it-was-stripped.patch Hi Hauke, Something strange: - This complete patch was based on 5.10.83 and upstreamed patches were removed - it removes specifically this one: delete mode 100644 package/kernel/mac80211/patches/subsys/307-mac80211-do-not-access-the-IV-when-it-was-stripped.patch - But this fix was only added in 5.10.84 ? Hi Koen, Sorry I forgot to update the patch subject line. This is based on kernel 5.10.84, I only saw this some minutes after sending the mail. The patch for master is based on 5.15.7. The tar.xz files are named correctly. I anyway plan to release official backports tar.xz files and then use them in OpenWrt. Hauke No Worries :-) Thanks for clearing this up and your hard work here! Regards, Koen ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 21.02] mac80211: Update toversion 5.10.83
On 12/13/21 2:16 PM, Koen Vandeputte wrote: On 12.12.21 22:18, Hauke Mehrtens wrote: The following patches were backported from upstream before and are not needed any more: package/kernel/mac80211/patches/ath/980-ath10k-fix-max-antenna-gain-unit.patch package/kernel/mac80211/patches/subsys/307-mac80211-do-not-access-the-IV-when-it-was-stripped.patch Signed-off-by: Hauke Mehrtens --- package/kernel/mac80211/Makefile | 8 +-- .../patches/ath/542-ath9k_debugfs_diag.patch | 4 +- .../ath/551-ath9k_ubnt_uap_plus_hsr.patch | 4 +- .../ath/930-ath10k_add_tpt_led_trigger.patch | 4 +- ...rolling-support-for-various-chipsets.patch | 14 +++--- ...75-ath10k-use-tpt-trigger-by-default.patch | 2 +- ...980-ath10k-fix-max-antenna-gain-unit.patch | 49 --- ...-power-reduction-for-US-regulatory-d.patch | 8 +-- .../100-remove-cryptoapi-dependencies.patch | 10 ++-- ...ort-immediate-reconnect-request-hint.patch | 2 +- ...-the-fwd_skb-dev-for-mesh-forwarding.patch | 2 +- ...t-access-the-IV-when-it-was-stripped.patch | 26 -- ...-get_default_func-move-default-flow-.patch | 2 +- ...ot-maintain-a-backlog-sorted-list-of.patch | 2 +- ...add-rx-decapsulation-offload-support.patch | 18 +++ ...le-QoS-support-for-nl80211-ctrl-port.patch | 6 +-- ...pply-flow-control-on-management-fram.patch | 2 +- ...set-sk_pacing_shift-for-802.3-txpath.patch | 2 +- ...MPDU-session-check-from-minstrel_ht-.patch | 6 +-- ...eee80211_tx_h_rate_ctrl-when-dequeue.patch | 8 +-- ...te-control-support-for-encap-offload.patch | 2 +- ...rting-aggregation-sessions-on-mesh-i.patch | 2 +- ...introduce-aql_enable-node-in-debugfs.patch | 4 +- ...to-a-virtual-time-based-airtime-sche.patch | 6 +-- ...eck-per-vif-offload_flags-in-Tx-path.patch | 2 +- ...nl80211-add-support-for-BSS-coloring.patch | 2 +- ...211-add-support-for-BSS-color-change.patch | 6 +-- .../patches/subsys/400-allow-ibss-mixed.patch | 2 +- 28 files changed, 65 insertions(+), 140 deletions(-) delete mode 100644 package/kernel/mac80211/patches/ath/980-ath10k-fix-max-antenna-gain-unit.patch delete mode 100644 package/kernel/mac80211/patches/subsys/307-mac80211-do-not-access-the-IV-when-it-was-stripped.patch Hi Hauke, Something strange: - This complete patch was based on 5.10.83 and upstreamed patches were removed - it removes specifically this one: delete mode 100644 package/kernel/mac80211/patches/subsys/307-mac80211-do-not-access-the-IV-when-it-was-stripped.patch - But this fix was only added in 5.10.84 ? Hi Koen, Sorry I forgot to update the patch subject line. This is based on kernel 5.10.84, I only saw this some minutes after sending the mail. The patch for master is based on 5.15.7. The tar.xz files are named correctly. I anyway plan to release official backports tar.xz files and then use them in OpenWrt. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 21.02] mac80211: Update toversion 5.10.83
On 12.12.21 22:18, Hauke Mehrtens wrote: The following patches were backported from upstream before and are not needed any more: package/kernel/mac80211/patches/ath/980-ath10k-fix-max-antenna-gain-unit.patch package/kernel/mac80211/patches/subsys/307-mac80211-do-not-access-the-IV-when-it-was-stripped.patch Signed-off-by: Hauke Mehrtens --- package/kernel/mac80211/Makefile | 8 +-- .../patches/ath/542-ath9k_debugfs_diag.patch | 4 +- .../ath/551-ath9k_ubnt_uap_plus_hsr.patch | 4 +- .../ath/930-ath10k_add_tpt_led_trigger.patch | 4 +- ...rolling-support-for-various-chipsets.patch | 14 +++--- ...75-ath10k-use-tpt-trigger-by-default.patch | 2 +- ...980-ath10k-fix-max-antenna-gain-unit.patch | 49 --- ...-power-reduction-for-US-regulatory-d.patch | 8 +-- .../100-remove-cryptoapi-dependencies.patch | 10 ++-- ...ort-immediate-reconnect-request-hint.patch | 2 +- ...-the-fwd_skb-dev-for-mesh-forwarding.patch | 2 +- ...t-access-the-IV-when-it-was-stripped.patch | 26 -- ...-get_default_func-move-default-flow-.patch | 2 +- ...ot-maintain-a-backlog-sorted-list-of.patch | 2 +- ...add-rx-decapsulation-offload-support.patch | 18 +++ ...le-QoS-support-for-nl80211-ctrl-port.patch | 6 +-- ...pply-flow-control-on-management-fram.patch | 2 +- ...set-sk_pacing_shift-for-802.3-txpath.patch | 2 +- ...MPDU-session-check-from-minstrel_ht-.patch | 6 +-- ...eee80211_tx_h_rate_ctrl-when-dequeue.patch | 8 +-- ...te-control-support-for-encap-offload.patch | 2 +- ...rting-aggregation-sessions-on-mesh-i.patch | 2 +- ...introduce-aql_enable-node-in-debugfs.patch | 4 +- ...to-a-virtual-time-based-airtime-sche.patch | 6 +-- ...eck-per-vif-offload_flags-in-Tx-path.patch | 2 +- ...nl80211-add-support-for-BSS-coloring.patch | 2 +- ...211-add-support-for-BSS-color-change.patch | 6 +-- .../patches/subsys/400-allow-ibss-mixed.patch | 2 +- 28 files changed, 65 insertions(+), 140 deletions(-) delete mode 100644 package/kernel/mac80211/patches/ath/980-ath10k-fix-max-antenna-gain-unit.patch delete mode 100644 package/kernel/mac80211/patches/subsys/307-mac80211-do-not-access-the-IV-when-it-was-stripped.patch Hi Hauke, Something strange: - This complete patch was based on 5.10.83 and upstreamed patches were removed - it removes specifically this one: delete mode 100644 package/kernel/mac80211/patches/subsys/307-mac80211-do-not-access-the-IV-when-it-was-stripped.patch - But this fix was only added in 5.10.84 ? Regards, Koen ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC] Stop providing binary package updates for release builds?
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On 2021-12-12 20:42, Jo-Philipp Wich wrote: Hi, (...) Hi Jo-Philips, thanks for the detailed write-up. As an embedded software developer, I feel much and mostly agree with your reasoning. However, one of the reasons I like to use OpenWRT so much on my production router(s) is exactly that availability of quality pre-build images and release branch matching up-to-date (security, bugs) packages. For production use, I really love the "official" built and tested releases and install them to my devices, even while having my own builds available. Next to that, I install packages of what additional functionality I need. For the 20.02.1 release, it was also the way to get rid of a small bug, as advised in the release notes (in a matter of seconds): " The menu bar in LuCI is wrongly aligned If this is a real problem for you update the LuCI theme: opkg upgrade luci-theme-bootstrap " (source: https://openwrt.org/releases/21.02/notes-21.02.1) This is what, in my humble opinion, makes OpenWRT such a great piece of software for even not-so-technical users: you just pick the latest release for your router and if you need some other functionality, you can simply install a few packages from the web UI. And if there is a small security update or bugfix, it is solved in a few mouse clicks for everyone, independent of their technical skills. So apart from being convenient, I feel the packages feed for release branches also provides easy access to stability and security to all users. Given all the issues found in IOT and routers with mostly out-of-date propriety firmware, OpenWRT in its current form is such an asset! In summary, I would urge the OpenWRT devs to not too lightly drop the binary distribution of images and packages it has now. If, however, it is decided otherwise, I'm thinking of a possible solution: a docker or other container-like image that users can download with for example the host tools pre-build and an easy to use interface to update the OpenWRT sources, and configure and build them to their needs. Cheers, Bas. --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC] Stop providing binary package updates for release builds?
On Sun, Dec 12, 2021 at 08:42:52PM +0100, Jo-Philipp Wich wrote: > - Stop providing binary package updates; build release images and associated >repositories once only, archive the artifacts and redelegate build >resources back to master snapshots This! If people are interested in providing binary-updates (e.g. for their community) it's up to them. Bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
