Stijn Tintel [2021-03-12 01:25:24]:
Hi,
> Having libcap in OpenWrt base allows us to enable libcap support in
> other packages in base.
there is same functionality available through procd already so essentialy
you're throwing away that effort, increasing flash space usage etc.
> In lldpd, this
On 12/03/2021 10:50, Petr Štetiar wrote:
Stijn Tintel [2021-03-12 01:25:24]:
Hi,
Having libcap in OpenWrt base allows us to enable libcap support in
other packages in base.
there is same functionality available through procd already so essentialy
you're throwing away that effort, increasing
On 11/03/2021 23:46, Eneas U de Queiroz wrote:
> The library is always compiled with $(FPIC) (-fPIC or -fpic), even for
> the static library.
>
> There are some assembly sources that decide whether or not to enable
> PIC code by checking if PIC is defined. It counts on libtool to define
> it, but
The Netgear R6850 has its EEPROM data sitting at 0x28000 for the 5 GHz radio
and at 0x2 for the 2,4 GHz radio. See forum topic for a hex dump [1].
[1]
https://forum.openwrt.org/t/netgear-r6850-very-low-transmit-power-on-5ghz/90984
Signed-off-by: Stijn Segers
Tested-by: Bernt Ø. Thorvaldsen
On 2021-03-12 11:34, Stijn Tintel wrote:
> On 11/03/2021 23:46, Eneas U de Queiroz wrote:
>> The library is always compiled with $(FPIC) (-fPIC or -fpic), even for
>> the static library.
>>
>> There are some assembly sources that decide whether or not to enable
>> PIC code by checking if PIC is d
OK I wiped the entire thing and pulled a fresh repo, same config for both
devices, same problems.
I revert the iproute2 update commit, b048a305a3d3cbb5375e32757e70aa129b4c7c4f,
builds just fine, I suspect there is some interplay between the default image
config in relation to iproute2 and libbp
Hi,
I would like to let you know, that we've prepared upgrade of the Buildbot
based infrastructure and there is a plan to make those changes alive.
We would like to bump master and workers in the upcoming days to the latest
and greatest Buildbot stable release 3.0.0 (current is 0.8.12) with Debi
On Fri, Mar 12, 2021 at 2:10 AM Stijn Tintel wrote:
>
> On 12/03/2021 10:50, Petr Štetiar wrote:
> > Stijn Tintel [2021-03-12 01:25:24]:
> >
> > Hi,
> >
> >> Having libcap in OpenWrt base allows us to enable libcap support in
> >> other packages in base.
> > there is same functionality available
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Bjørn Mork
> Sent: Dienstag, 9. März 2021 22:18
> To: openwrt-devel@lists.openwrt.org
> Cc: John Crispin ; Bjørn Mork
> Subject: [PATCH] rtl83xx-poe: add package
>
> From: John
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Birger Koblitz
> Sent: Mittwoch, 10. März 2021 20:18
> To: openwrt-devel@lists.openwrt.org
> Subject: Re: [PATCH 4/6] realtek: enable HWMON for SFP sensors
>
> Tested and is nece
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Birger Koblitz
> Sent: Mittwoch, 10. März 2021 20:16
> To: openwrt-devel@lists.openwrt.org
> Subject: Re: [PATCH 3/6] realtek: need to handle
> PHY_INTERFACE_MODE_NA for sfps
>
>
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Hauke Mehrtens
> Sent: Mittwoch, 10. März 2021 00:52
> To: openwrt-devel@lists.openwrt.org
> Cc: musashino.o...@gmail.com; Hauke Mehrtens
> Subject: [PATCH 5/5] mediatek: Add sup
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Stijn Segers
> Sent: Freitag, 12. März 2021 12:45
> To: openwrt-devel@lists.openwrt.org
> Cc: m...@david-bauer.net; Bernt Ø . Thorvaldsen
>
> Subject: [PATCH] ramips: mt7621: fix
Hi Adrian,
Op vrijdag 12 maart 2021 om 22u01 schreef Adrian Schmutzler
:
Hi,
-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
On Behalf Of Stijn Segers
Sent: Freitag, 12. März 2021 12:45
To: openwrt-devel@lists.openwrt.org
Cc: m...@david-ba
On Sat, Feb 27, 2021 at 7:41 AM Hauke Mehrtens wrote:
>
> On 2/27/21 5:17 AM, Rosen Penev wrote:
> > No package here depends on it. Furthermore, uClibc++ is a fairly buggy
> > C++ library and seems to be relatively inactive upstream.
> >
> > It also lacks proper support for modern C++11 features.
Hi,
Thanks for creating this patch. Got my X5000R today. Before flashing it
to OpenWRT, can you please tell me whether you (or anyone else) did
performance measurements with the original and the OpenWRT firmware?
I measured over 600mbit/s with WPA3 when on my desk, next to a notebook
with In
When one package "provides" another non-virtual package, prefer to use
the original package instead of the providing package.
Example:
Consider packages "foo" and "bar", where "foo" provides "bar".
The current code will sort all candidates by name and use the last entry
by default, so "foo" would
Hi!
On Sat, Mar 13, 2021 at 7:27 AM Bas Mevissen wrote:
>
> Hi,
>
> Thanks for creating this patch. Got my X5000R today. Before flashing it
> to OpenWRT, can you please tell me whether you (or anyone else) did
> performance measurements with the original and the OpenWRT firmware?
The wifi chip u
On Sat, Mar 13, 2021 at 02:00:40AM +0100, Matthias Schiffer wrote:
> When one package "provides" another non-virtual package, prefer to use
> the original package instead of the providing package.
>
> Example:
>
> Consider packages "foo" and "bar", where "foo" provides "bar".
> The current code w
On Fri, Mar 12, 2021 at 6:27 PM Chuanhong Guo wrote:
>
> Hi!
>
> On Sat, Mar 13, 2021 at 7:27 AM Bas Mevissen wrote:
> >
> > Hi,
> >
> > Thanks for creating this patch. Got my X5000R today. Before flashing it
> > to OpenWRT, can you please tell me whether you (or anyone else) did
> > performance
On 12/03/21 11:01, Stijn Tintel wrote:
On 12/03/2021 10:50, Petr Štetiar wrote:
Stijn Tintel [2021-03-12 01:25:24]:
Also, I don't agree that any optional package should be moved to the
packages feed. The packages feed is a mess, often PR's are accepted
without maintainer approval, sometim
With kernel 5.10, exfat is out of staging and in tree.
Added small hack to make it work with kernel 5.4 as well.
Signed-off-by: Rosen Penev
---
package/kernel/linux/modules/fs.mk | 20
1 file changed, 20 insertions(+)
diff --git a/package/kernel/linux/modules/fs.mk
b/pack
Now that kernel 5.10 is in tree, this can be removed.
Signed-off-by: Rosen Penev
---
package/kernel/exfat/Makefile | 46 ---
1 file changed, 46 deletions(-)
delete mode 100644 package/kernel/exfat/Makefile
diff --git a/package/kernel/exfat/Makefile b/package/ker
Petr Štetiar [2021-03-12 16:38:46]:
Hi,
> I would like to let you know, that we've prepared upgrade of the Buildbot
> based infrastructure and there is a plan to make those changes alive.
we've just finished the migration.
Cheers,
Petr
___
openwrt
On 13/03/2021 07:03, Petr Štetiar wrote:
Petr Štetiar [2021-03-12 16:38:46]:
Hi,
I would like to let you know, that we've prepared upgrade of the Buildbot
based infrastructure and there is a plan to make those changes alive.
we've just finished the migration.
Oh nice, didn't see that comi
25 matches
Mail list logo
