Hi,
On Fri, Nov 29, 2019 at 9:29 PM Uwe Kleine-König wrote:
>
> On 11/29/19 8:50 PM, Hans Dedecker wrote:
> > On Wed, Nov 20, 2019 at 7:11 PM Uwe Kleine-König
> > wrote:
> >>
> >> When for example a /60 is assigned to a network the last 4 bits of the
> >> ip6hint are unused. Emit a warning if a
A const char * variable is being passed as a format string. Unfortunately,
this is not correct.
A constant expression needs to be passed so that GCC can determine the
types of the format properly.
Also fixed a different warning that needs a printf attribute.
Fixes:
error: format not a string li
On 3/12/2019 02:05, m...@adrianschmutzler.de wrote:
>> -Original Message-
>> From: Stijn Tintel [mailto:st...@linux-ipv6.be]
>> Sent: Dienstag, 3. Dezember 2019 00:58
>> To: m...@adrianschmutzler.de; openwrt-devel@lists.openwrt.org
>> Cc: pozega.tomis...@gmail.com
>> Subject: Re: [OpenWrt-D
> -Original Message-
> From: Stijn Tintel [mailto:st...@linux-ipv6.be]
> Sent: Dienstag, 3. Dezember 2019 00:58
> To: m...@adrianschmutzler.de; openwrt-devel@lists.openwrt.org
> Cc: pozega.tomis...@gmail.com
> Subject: Re: [OpenWrt-Devel] [PATCH] ath79: add support for Ubiquiti
> LiteBeam A
Hi,
The OpenWrt community is proud to announce the second release candidate
of the upcoming OpenWrt 19.07 stable version series. It incorporates 126
commits since the previous release candidate 19.07.0-rc1.
With this release, the OpenWrt project brings all supported targets back
to a single commo
On 3/12/2019 01:39, m...@adrianschmutzler.de wrote:
> Hi Stijn,
>
> does the device have a MAC address label or imprint on the box?
It does.
>
> [...]
>
>> +define Device/ubnt_litebeam-ac-gen2
>> + $(Device/ubnt-wa)
>> + DEVICE_TITLE := Ubiquiti LiteBeam AC Gen2
> DEVICE_TITLE has been replaced b
Hi Stijn,
does the device have a MAC address label or imprint on the box?
[...]
> +define Device/ubnt_litebeam-ac-gen2
> + $(Device/ubnt-wa)
> + DEVICE_TITLE := Ubiquiti LiteBeam AC Gen2
DEVICE_TITLE has been replaced by DEVICE_VENDOR, DEVICE_MODEL and
DEVICE_VARIANT. In your case, I'd choos
Hardware:
* SoC: Atheros AR9342-BL1A
* RAM: 64MB DDR2 (Winbond W9751G6KB-25)
* Flash: 16MB SPI NOR (Macronix MX25L12835FZ2I-10G)
* Ethernet: 1x 10/100/1000 Mbps (Atheros AR8035-A) with 24V PoE support
* Wifi 2.4GHz: Atheros AR9340 v2
* WiFi 5GHz: Ubiquiti U-AME-G1-BR4A (rebranded QCA988X v2)
* LEDs
On 11/29/19 3:40 AM, Joe Ayers wrote:
> Attempting to use the hAP ac lite model RB952Ui-5ac2nD with the 5GHz
> radio0 802.11ac seems to be unstable and consume available memory.
> This is only enabling radio0 with no other changes and bringing wifi
> up/down to reproduce. Am I doing something sil
Stijn Tintel [2019-12-02 16:45:11]:
> NAK!
ACK, I've Rejected the patch in the Patchwork and removed it from my staging
tree.
> Pushing commits that are known to result in systems no longer booting is
> simply not acceptable, imo.
This patch was for master, development branch so for me its alm
On 2/12/2019 16:12, Petr Štetiar wrote:
> I've added this patch into my staging tree[4] with some warning and
> will merge it unless someone NAK it in the next 14 days.
NAK!
Pushing commits that are known to result in systems no longer booting is
simply not acceptable, imo. Not everybody reads g
Henrique de Moraes Holschuh [2019-12-02 08:23:40]:
Hi,
> This one regresses some AMD processors in some (all?) motherboards. It has
> been reported to Ubuntu by several users.
for reference[1]:
amd64-microcode (3.20191021.1+really3.20180524.1~ubuntu0.16.04.2)
xenial-security; urgency=medium
This one regresses some AMD processors in some (all?) motherboards. It
has been reported to Ubuntu by several users.
It is fine for master, maybe, but I would not let it into a stable
OpenWRT release right now.
(spoken using my Debian Developer hat, as the Debian maintainer for
amd64-microc
13 matches
Mail list logo
