> On 6 Jan 2017, at 1:37 PM, David Lang wrote:
>
> LEDE is already accepting pull requests via github
Oh I didn't realize that. Now I even see it on the lede webpage. I might have
missed that before :-/ Thanks for the heads-up!
/daniel
___
On Fri, 6 Jan 2017, Daniel (bovi) Bovensiepen wrote:
As part of this those I'm thinking that having a more
'commercial-quality' flavour and a more 'community' flavour branches
would be useful.
Could I make one remark concerning this: I fully understand from a review and
quality point of view
> As part of this those I'm thinking that having a more
> 'commercial-quality' flavour and a more 'community' flavour branches
> would be useful.
Could I make one remark concerning this: I fully understand from a review and
quality point of view the current way of providing patches to LEDE or Op
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 ---
Hi Hauke,
sorry for the late repl
On Wed, 21 Dec 2016 13:06:22 -0500
"Hauke Mehrtens" wrote:
> We had multiple meetings to find a solution to solve the problems
> between the OpenWrt and the LEDE project and to discuss a possible
> merge. Everyone with commit access to LEDE and all OpenWrt core
> developers were invited to these
Older OpenWRT releases won't get the new package (or the updates) anyway
so breaking compatibility is not an issue.
Although using a misleading name is still an issue. In LEDE core repo
that var was renamed into PKG_HASH and contains a SHA256sum.
The LEDE buildsystem works with both variables
h
Hello Hannu,
why should a variable be called MD5 if it holds an SHA256 hash? That
does not make any sense.
Could you, please, point me to the thread on the openwrt or lede list
that discussed this weird idea.
Abusing the MD5 variable with SHA256 hashes will break compatibility
with older openwrt
On 12/31/2016 04:13 PM, Florian Fainelli wrote:
> This patch series bumps a few packages in order to get updated CMakeList.txt
> and/or compiler warning fixed.
>
> Patch 4 mimics what other packages (e.g: uhttpd) do wrt. libcrypt since for
> some reason CMake is unable to find this library.
>
> P
I just want to chime in that I have felt no negatives and arguable
positives since deploying v1 of the airtime fairness patch.
I'm currently on git master from Dec 29th (so after the compat bump
and v2 fairness merge) and I want to say my Wi-Fi feels better then my
build from v1 timeframe. I got a
Hello,
The following patch (submitted by you) has been updated in patchwork:
* lede: [LEDE-DEV,v2] musl: update musl to 1.1.16+ and switch to download from
git
- http://patchwork.ozlabs.org/patch/710536/
- for: LEDE development
was: New
now: Accepted
This email is a notificat
On 2017-01-05 16:17, L. D. Pinney wrote:
> Hello Dave :
>
> Can you please stop cross posting?
>
> It's quite annoying to see this unrelated babble about UN-related ath10k
> when subject is ath9k
>
> Felix says it a no go on ath9k airtime fairness for the releaseAND
> that's all we really ne
On Thu, Jan 5, 2017 at 6:03 AM, Michal Kazior wrote:
> On 5 January 2017 at 14:23, Felix Fietkau wrote:
>> On 2017-01-05 14:22, Loganaden Velvindron wrote:
>>> On Thu, Jan 5, 2017 at 4:59 PM, Dave Taht wrote:
Felix:
Was there a bugreport? (don't see one)
Do you have a s
On Thu, Jan 5, 2017 at 5:23 AM, Felix Fietkau wrote:
> On 2017-01-05 14:22, Loganaden Velvindron wrote:
>> On Thu, Jan 5, 2017 at 4:59 PM, Dave Taht wrote:
>>> Felix:
>>>
>>> Was there a bugreport? (don't see one)
>>>
>>> Do you have a specific device or behavior triggering this revert?
>>>
>>>
On 5 January 2017 at 14:23, Felix Fietkau wrote:
> On 2017-01-05 14:22, Loganaden Velvindron wrote:
>> On Thu, Jan 5, 2017 at 4:59 PM, Dave Taht wrote:
>>> Felix:
>>>
>>> Was there a bugreport? (don't see one)
>>>
>>> Do you have a specific device or behavior triggering this revert?
>>>
>>>
>>>
On 2017-01-05 14:22, Loganaden Velvindron wrote:
> On Thu, Jan 5, 2017 at 4:59 PM, Dave Taht wrote:
>> Felix:
>>
>> Was there a bugreport? (don't see one)
>>
>> Do you have a specific device or behavior triggering this revert?
>>
>>
>> On Thu, Jan 5, 2017 at 4:42 AM, Dave Taht wrote:
>>> https:/
On Thu, Jan 5, 2017 at 4:59 PM, Dave Taht wrote:
> Felix:
>
> Was there a bugreport? (don't see one)
>
> Do you have a specific device or behavior triggering this revert?
>
>
> On Thu, Jan 5, 2017 at 4:42 AM, Dave Taht wrote:
>> https://github.com/lede-project/source/commit/c296ba834db4ce8c71e0a
On Thu, Jan 5, 2017 at 5:02 AM, Felix Fietkau wrote:
> On 2017-01-05 13:59, Dave Taht wrote:
>> Felix:
>>
>> Was there a bugreport? (don't see one)
>>
>> Do you have a specific device or behavior triggering this revert?
> Not yet. I'm still collecting information, but since we want to release
> s
On 2017-01-05 13:59, Dave Taht wrote:
> Felix:
>
> Was there a bugreport? (don't see one)
>
> Do you have a specific device or behavior triggering this revert?
Not yet. I'm still collecting information, but since we want to release
soon, and I trust at least some of the users that reported these
Felix:
Was there a bugreport? (don't see one)
Do you have a specific device or behavior triggering this revert?
On Thu, Jan 5, 2017 at 4:42 AM, Dave Taht wrote:
> https://github.com/lede-project/source/commit/c296ba834db4ce8c71e0ad7030aab188fe60b27b
--
Dave Täht
Let's go make home rout
Hi,
as far as I know, opkg S/MIME support provides no real advantage over
usign based package list signing (which is used by default).
What do you guys think about removing S/MIME support from the build
system, to clean it up some more?
- Felix
___
Led
Compile & run-tested on cns3xxx
Tested-by: Koen Vandeputte
On 2017-01-04 23:54, Magnus Kroken wrote:
Signed-off-by: Magnus Kroken
---
.../utils/busybox/patches/220-add_lock_util.patch | 54 ++
1 file changed, 15 insertions(+), 39 deletions(-)
diff --git a/package/util
Compile & run-tested on cns3xxx
Tested-by: Koen Vandeputte
On 2017-01-04 23:54, Magnus Kroken wrote:
The "new style" busybox applet approach moves all config
and build definitions related to an applet to its .c file.
Signed-off-by: Magnus Kroken
---
.../busybox/patches/210-add_netmsg_util
On Wed, Jan 4, 2017 at 10:12 PM, Stijn Tintel wrote:
> On 03-01-17 14:09, Jo-Philipp Wich wrote:
>> The odhcpd documentation currently implies that "option ignore 1" in a
>> section
>> of type "dhcp" will disable any services on the referenced interface while
>> the
>> code actually ignores the
23 matches
Mail list logo
