else think of this idea? What seems like a reasonable date?
And who would be willing to take on the task of splitting the branch
at said date to make sure we'll be actually moving forward with the
plan at said date?
Yours sincerely,
Jaap Buurman
On Wed, May 2, 2018 at 4:41 AM, Eric Luehrsen
think?
Yours sincerely,
Jaap Buurman
On Tue, May 1, 2018 at 2:53 PM, Rich Brown wrote:
> Hi folks,
>
> It has been exactly a month since Hauke sent his note recommending a release
> process for the next OpenWrt stable.
> http://lists.infradead.org/pipermail/lede-dev/2018-April/011
Dear Sven,
I wasn't aware of signature checking and hence I agree with yours and
Jo-Philipp's sentiment that this would be a bad idea. Please disregard
my suggestion. Thank you very much for teaching me about the signature
verification system.
Yours sincerely,
Jaap Buurman
On Tue, Ap
Dear Alberto Bursi,
I did not know about signature verification. I agree that there are no
secrets to hide and hence signature verification should be sufficient
to avoid tampering. Thank you very much for your reassurance.
Yours sincerely,
Jaap Buurman
On Tue, Apr 17, 2018 at 10:13 AM, Alberto
ownloading over
https via opkg default by changing the distfeed file and including the
required packages. We might even decide to only do this on targets
that are not starved for flash storage. Any opinions regarding this
matter?
Yours sincerely,
Ja
arget on kernel
4.9 for now?
Yours sincerely,
Jaap Buurman
On Mon, Apr 2, 2018 at 2:11 PM, Hauke Mehrtens wrote:
> On 04/02/2018 10:54 AM, Jaap Buurman wrote:
>> Dear Hauke,
>>
>> Quick question from my side: I was wondering why Ramips will probably
>> stay with
:)
Yours sincerely,
Jaap Buurman
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
!
Kind regards,
Jaap
On Sat, Jul 1, 2017 at 11:29 AM, Jaap Buurman wrote:
> Dear John,
>
> I haven't had time to test it yet myself, but in the previously
> mentioned topic by Bart van Zoest there have already been two reports
> of crashing devices with SQM cake enabled unfortuna
mized-build-for-the-d-link-dir-860l/948
> for the people wanting to test it.
> Hopefully, there will be testers and feedback soon!
>
> Regards,
> Bart
>
> On Thu, Jun 29, 2017 at 8:56 PM, John Crispin wrote:
>>
>>
>> On 29/06/17 20:14, Jaap Buurman wrote:
>&g
Dear John,
This patch sounds very very promising! I will compile and test this
first come this weekend. Thank you so very much for having a look at
this issue :)
Yours sincerely,
Jaap
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists
results in the following Lede forum topic:
https://forum.lede-project.org/t/build-for-the-d-link-dir-860l/948/62
On Sun, Apr 23, 2017 at 2:42 PM, Jaap Buurman wrote:
> The mediatek folder is not there by default. It gets generated in the
> during the "make" command when compiling
source package
> downloaded so it must come from LEDE patches.
>
> So go in main source folder and write "git checkout lede-17.01" then it
> should work.
>
> -Alberto
>
>
> On 04/23/2017 12:52 PM, Jaap Buurman wrote:
>> Thank you all for the suggesti
ch file you created from the
> quilt kernel patch folder (platform/) to the patch folder as said above.
>
> There might be better ways, but that's what I did when I had to add new
> kernel patches.
>
> -Alberto
>
>
> On 04/22/2017 01:53 PM, Jaap Buurman wrote:
>
> I h
c and gsw_mt7620.o files just fine in the
aforementioned path, but not the .h file it is trying to patch. To
which branch does the patch apply cleanly? I am currently trying to
patch the master branch. Should I try the 17.01 branch instead?
On Wed, Apr 19, 2017 at 10:32 AM, Jaap Buurman wrote:
>
since I would like to raise the limit up to
> 9KB if possible. Please, let me know if this works for you.
>
> On Wed, Apr 19, 2017 at 10:18 AM, Jaap Buurman wrote:
>> Wow, this is perfect. Thank you very much. I will try to use this
>> patch and compile my own image with up to 2kb
gt; index 1609a3e..f95c354 100644
> --- a/drivers/net/ethernet/mediatek/soc_mt7621.c
> +++ b/drivers/net/ethernet/mediatek/soc_mt7621.c
> @@ -140,7 +140,7 @@ static void mt7621_init_data(struct fe_soc_data *data,
>
> priv->flags = FE_FLAG_PADDING_64B | FE_FLAG_RX_2B_OFFSET |
&g
=mushoz
If so, I will be able to apply the patch myself and test it. I could
then send a PR if the tests are successful.
Yours sincerely,
Jaap Buurman
On Mon, Apr 10, 2017 at 9:16 AM, Milan Kočvara wrote:
> Hello all,
> if someone do a testing patch for jumboFrames, I can lend a helping
>
Hello all,
I found the message below in a conversation from back in August, 2016
in this mailinglist. I did not find a reply to this question. Has
there ever been one? Or does anyone else happen to know the answer to
this question? Thank you very much in advance.
Yours sincerely,
Jaap Buurman
One more question if you don't mind :) With the "mac80211 debloated
intermediate queues" do you also mean fq_codel (phase 2), or just
phase 1?
Also, has cake ever been tried instead of fq_codel to try and debloat wifi?
On Sun, Jan 29, 2017 at 2:46 PM, Toke Høiland-Jørgensen wrote:
:46 PM, Toke Høiland-Jørgensen wrote:
> Jaap Buurman writes:
>
>> Thank you very much for the clarification. That makes a lot of sense.
>> Do you happen to know where the mt76 driver stands with respect to
>> these different phases? I am in the market for a new router, and d
y the dir-860l rev b1.
On Sun, Jan 29, 2017 at 6:33 AM, Weedy wrote:
> On 28 January 2017 at 15:56, Rich Brown wrote:
>> Hi Jaap,
>>
>>> On Jan 28, 2017, at 6:36 AM, Jaap Buurman wrote:
>>> Also about the following: "Improvements to the WiFi stack eliminatin
Great job on the release notes! One minor thing that I think looks
nicer would be the removal of "nothing specific" after "improved
performance", since it adds no additional information. But that's just
me.
Also about the following: "Improvements to the WiFi stack eliminating
bufferbloat on ath9k
Hi all,
According to Dave Täht the following code disables Airtime Fairness:
for i in /sys/kernel/debug/ieee80211/phy*/*/airtime_flags
do
echo 0 > $i
done
Wouldn't it be a good idea to ship Lede with ATF baked in, but
disabled at default? That would allow end-users to easily enable ATF.
Since
23 matches
Mail list logo
