Daniel Bailey [2020-05-29 18:32:55]:
Hi,
BTW I'm not going to apply this, see my reasoning in the other thread[1], just
reviewing this from the patch content perspective:
1. http://lists.infradead.org/pipermail/openwrt-devel/2020-May/023393.html
> + if (in->watchdog.mode != INSTANCE_WATCHDOG_M
R. Diez via openwrt-devel [2020-06-04
14:55:30]:
Hi,
> I do not know what you did not like in the patch, so I am hoping it is just
> the formatting of the subject line and perhaps that some extra explanation
> is needed. Please find enclosed the new patch version.
https://openwrt.org/submittin
Jun 6, 2020 03:41:30 Alexander Couzens :
Hi,
> To prevent "wrong" musl packages which have a new version number
> but the package still contains an old version, because
> PKG_SOURCE_VERSION was unchanged.
>
> Ref: musl ml https://www.openwall.com/lists/musl/2020/05/22/4
>
> Signed-off-by: Alexand
To prevent "wrong" musl packages which have a new version number
but the package still contains an old version, because
PKG_SOURCE_VERSION was unchanged.
Ref: musl ml https://www.openwall.com/lists/musl/2020/05/22/4
Signed-off-by: Alexander Couzens
---
toolchain/musl/common.mk | 9 +++--
1
Removes the standalone implementation of stack smashing protection
in gcc's libssp in favour of the native implementation in musl,
glibc and uClibc and introduces a uniform configuration interface.
This also makes kernel-level stack smashing protection available
for builds using non-musl libc (sub
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Henrique de Moraes Holschuh
> Sent: Freitag, 5. Juni 2020 15:50
> To: openwrt-devel@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [RFC PATCH] sysupgrade: introduce
> compatibil
On 5 June 2020 14:27:24 CEST, "Bjørn Mork" wrote:
>I haven't even bother to try to write any code to see if this is
>feasible, but anyway...
>
>I wonder if there might be more flexible and user-friendly ways to
>handle upgrade incompatibilities if we are allowed to use code/metadata
I see the a
Adrian Schmutzler [2020-06-05 16:50:48]:
Hi,
> as far as I'm concerned, this was/is desired. There has been an older
> discussion on the list
yeah, I barely remember something, but can't find it right now, but IIRC it
was David who explained to you, that removing the WAN port is not that good
On Mon, May 25, 2020 at 7:20 PM Ian Cooper wrote:
>
> Removes the standalone implementation of stack smashing protection
> in gcc's libssp in favour of the native implementation in musl,
> glibc and uClibc and introduces a uniform configuration interface.
>
> This also makes kernel-level stack sma
On 5 June 2020 16:37:48 CEST, "Petr Štetiar" wrote:
>Commit 5acd1ed0be0d ("ramips: mt7621: fix Ubiquiti ER-X ports names and
>MAC addresses") didn't only changed naming, but also removed WAN
>functionality from eth0 port, which is not desired, so lets add it
>back.
Hi Petr,
as far as I'm conc
Hello Petr,
I have already created a PR to do just this, for both the ER-X and
ER-X-SFP. https://github.com/openwrt/openwrt/pull/2961
Perhaps the PR could be merged instead since it handles both devices.
Greets,
Perry
On 6/5/20 4:37 PM, Petr Štetiar wrote:
> Commit 5acd1ed0be0d ("ramips: mt762
Commit 5acd1ed0be0d ("ramips: mt7621: fix Ubiquiti ER-X ports names and
MAC addresses") didn't only changed naming, but also removed WAN
functionality from eth0 port, which is not desired, so lets add it back.
Cc: Chuanhong Guo
Cc: Adrian Schmutzler
Cc: DENG Qingfang
Fixes: 5acd1ed0be0d ("ramip
On 05/06/2020 09:27, Bjørn Mork wrote:
I wonder if there might be more flexible and user-friendly ways to
handle upgrade incompatibilities if we are allowed to use code/metadata
from the new image in the sysupgrade process? Instead of just providing
a version number with some simple semantics li
I haven't even bother to try to write any code to see if this is
feasible, but anyway...
I wonder if there might be more flexible and user-friendly ways to
handle upgrade incompatibilities if we are allowed to use code/metadata
from the new image in the sysupgrade process? Instead of just providi
We regularly encounter the situation that devices are subject to
changes that will make them incompatible to previous versions.
Removing SUPPORTED_DEVICES will not really be helpful in most of these
cases, as this only helps after a rename.
To solve this situation, this patch introduces a compatib
15 matches
Mail list logo
