On Fri, May 25, 2018 at 1:18 AM, Daniel Golle wrote:
> Hi!
>
> On Thu, May 24, 2018 at 10:38:45PM +0300, Alexandru Ardelean wrote:
>> On Thu, May 24, 2018 at 7:34 PM, Daniel Golle wrote:
>> > Use download from github archive corresponding to v3.14.4 tag because
>> > the project's website apparent
Currently when installing the firmware, a bunch of files and directories
that the ath10k driver does not look for are created.
The package now installs firmware for both hw 2.1 and 3.0 devices.
2.1 is abandonware but may be useful to keep.
3.0 firmware was tested on a Killer 1535 to be relatively
This is a port of an old commit from mkresin's tree:
09260cdf3e9332978c2a474a58e93a6f2b55f4a8
This has the potential to break sysupgrade but it should be fine as
there is no stable release of LEDE or OpenWrt that support these devices.
Signed-off-by: Rosen Penev
---
target/linux/ramips/base-fi
I was carrying a local commit that added the sdhci stuff and missed it
as a result.
Also fix the rgmii3 thing in the PC2 DTS file as that's bogus and causes
a dmesg warning that it's bogus.
Signed-off-by: Rosen Penev
---
target/linux/ramips/dts/GB-PC1.dts | 3 +++
target/linux/ramips/dts/GB-PC2
On 25 May 2018 at 03:40, Martin Tippmann wrote:
> On Thu, May 24, 2018 at 9:06 PM, Hauke Mehrtens wrote:
>> Please do not hesitate to re report some request that something should
>> be backported from master or some regression compared to lede-17.01, if
>> it looks like they got ignored and didn'
On 24.05.2018 22:40, Martin Tippmann wrote:
On Thu, May 24, 2018 at 9:06 PM, Hauke Mehrtens wrote:
Please do not hesitate to re report some request that something should
be backported from master or some regression compared to lede-17.01, if
it looks like they got ignored and didn't got a respo
Hi!
On Thu, May 24, 2018 at 10:38:45PM +0300, Alexandru Ardelean wrote:
> On Thu, May 24, 2018 at 7:34 PM, Daniel Golle wrote:
> > Use download from github archive corresponding to v3.14.4 tag because
> > the project's website apparently only offers 3.14.0-stable release
> > downloads.
> > Drop l
On Thu, May 24, 2018 at 9:06 PM, Hauke Mehrtens wrote:
> Please do not hesitate to re report some request that something should
> be backported from master or some regression compared to lede-17.01, if
> it looks like they got ignored and didn't got a response.
Hi, would be great if the recent wi
On Thu, May 24, 2018 at 7:34 PM, Daniel Golle wrote:
> Use download from github archive corresponding to v3.14.4 tag because
> the project's website apparently only offers 3.14.0-stable release
> downloads.
> Drop local patch for CVE-2017-13099 as it was merged upstream.
>
Looks good.
On a relate
We would like to create a lede 17.01.5 release soon, the last release,
lede 17.01.4, was done on 18. October 2017 which was a long time ago.
We are planning to do the build by end of next week, around 2. June 2018.
This release would be build form the lede-17.01 stable branch and
contain all the f
On 05/06/2018 07:17 PM, Paul Oranje wrote:
>
>
>> Op 30 apr. 2018, om 08:39 heeft John Crispin het volgende
>> geschreven:
>>
>> On 30/03/18 17:34, Hauke Mehrtens wrote:
>>> If the package doe not contain a PKG_HASH just skip the check instead of
>>> making the download fail. The scripts/down
Hi,
On Tue, May 22, 2018 at 10:33 PM, Rosen Penev wrote:
> Looks like it's this commit:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/staging/mt7621-mmc?h=next-20180517&id=b734735fcaca60e8f07b040cd8a700f6fabe5b39
>
> Please try reverting. Unfortunately I don
John Crispin kirjoitti 24.5.2018 klo 18:44:
On 24/05/18 17:42, Hannu Nyman wrote:
John Crispin kirjoitti 24.5.2018 klo 18:36:
On 24/05/18 17:29, Hannu Nyman wrote:
...
The big question is if the sysupgrade break for regular users will be
* in the 17.01/18.06 change (enabling easy master/18.0
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 ---
Hello Jaap,
On Thu, May 24, 2018
On 05/22/2018 10:09 AM, Rosysong wrote:
> Hi Hauke,
> Do you mean my nftables commands (limit rate xxx) can work on
> your lantiq (4.14 kernel) target ?
> I also choose kmod-nf-flow and kmod-nft-offload modules, but it
> can not restrict the traffic flow on specific ip
Use download from github archive corresponding to v3.14.4 tag because
the project's website apparently only offers 3.14.0-stable release
downloads.
Drop local patch for CVE-2017-13099 as it was merged upstream.
Signed-off-by: Daniel Golle
---
package/libs/wolfssl/Makefile | 9 +
On 24/05/18 17:42, Hannu Nyman wrote:
John Crispin kirjoitti 24.5.2018 klo 18:36:
On 24/05/18 17:29, Hannu Nyman wrote:
Increasing the reserved kernel space in master from 2MB to 4MB due
to kernel 4.14 for many ipq806x devices like R7800 has broken the
sysupgrade possibility from 17.01, 18
John Crispin kirjoitti 24.5.2018 klo 18:36:
On 24/05/18 17:29, Hannu Nyman wrote:
Increasing the reserved kernel space in master from 2MB to 4MB due to
kernel 4.14 for many ipq806x devices like R7800 has broken the sysupgrade
possibility from 17.01, 18.06 or an earlier master snapshot build t
On 24/05/18 17:29, Hannu Nyman wrote:
Increasing the reserved kernel space in master from 2MB to 4MB due to
kernel 4.14 for many ipq806x devices like R7800 has broken the
sysupgrade possibility from 17.01, 18.06 or an earlier master snapshot
build to the current master build. Same goes for th
Increasing the reserved kernel space in master from 2MB to 4MB due to kernel
4.14 for many ipq806x devices like R7800 has broken the sysupgrade
possibility from 17.01, 18.06 or an earlier master snapshot build to the
current master build. Same goes for the downgrade to stable branches.
The cur
On Thu, May 24, 2018 at 4:16 PM e9hack wrote:
> Am 24.05.2018 um 09:16 schrieb Hans Dedecker:
> >> possible and must not load hostfiles from other instances. The entry in
> >> dnsmasq.init must be:
> >
> >> xappend "--addn-hosts=$HOSTFILE"
> > Making such a change will break the host entries lear
Am 24.05.2018 um 09:16 schrieb Hans Dedecker:
>> possible and must not load hostfiles from other instances. The entry in
>> dnsmasq.init must be:
>
>> xappend "--addn-hosts=$HOSTFILE"
> Making such a change will break the host entries learned via odhcpd as the
> entires are put into the odhcpd fil
Mounting using the zlib compression and mounting with
full access accounting are now available in the
menuconfig.
Signed-off-by: Pierre Lebleu
---
v2: change the option names
package/system/fstools/Makefile | 16
1 file changed, 16 insertions(+)
diff --git a/package/system/fsto
Dear all,
I found some additional information in the system log: Thu May 24
11:38:39 2018 kern.err kernel: [83864.729458] eth0: Invalid MTU 1508
requested, hw max 1500
Digging deeper, this seems like a message that is spawned by a
function in /net/core.dev.c of the linux kernel:
if (dev->max_mtu
Refreshed all patches
Added new ARM64 symbol: ARM64_ERRATUM_1024718
Compile-tested on: ar71xx
Runtime-tested on: ar71xx
Signed-off-by: Koen Vandeputte
---
include/kernel-version.mk | 4 +-
.../ar7/patches-4.9/300-add-ac49x-platform.patch | 4 +-
.../403-mtd_fix_c
On Wed, May 23, 2018 at 11:43 PM e9hack wrote:
> Hi,
> this commit and the way, who the init script handles hostfiles seams to
be completely wrong. The init script generates
> one independent hostfile per dnsmasq instance and writes it to a common
directory. Multiple dnsmasq instances are
> poss
26 matches
Mail list logo
