Hi Luka,
in rpcd there already is the ability to store arbitrarily nested
key-value data in the session namespace which is even persistent over
daemon reloads. Is this not sufficient? And if not, what is missing?
~ Jo
___
Lede-dev mailing list
Lede-dev
On 11/08/2016 05:13 PM, Antonio Paunovic wrote:
> Hello everyone,
>
> recently there was a change in default UCI behaviour which you can
> see here:
>
>
http://git.openwrt.org/?p=project/uci.git;a=commit;h=df72af474075159ab79ed190d2109eb2d86709bf
>
> While change in implementation is minor, this m
Hi Jo,
can you define the session namespace and how this existing feature can be used?
Thanks,
Luka
On Thu, Nov 10, 2016 at 9:37 AM, Jo-Philipp Wich wrote:
> Hi Luka,
>
> in rpcd there already is the ability to store arbitrarily nested
> key-value data in the session namespace which is even per
Hi Felix,
On Tue, 2016-11-08 at 16:08 +0100, Felix Fietkau wrote:
> On 2016-11-08 15:46, Alexey Brodkin wrote:
> >
> > TI wl18xx and wl12xx are Wi-Fi/Bluetooth combo modules
> > that could be found on different existing boards.
> >
> > But it is possible to get those modules as a separate
> > co
libuv was recently udpated too:
https://github.com/openwrt/packages/commit/d8d457e52c2560bab4cf49182762bb4a8fe6019c
from 1.4.2 to 1.9.1, though fortunately that at least seems to be
ABI compatible:
https://abi-laboratory.pro/tracker/timeline/libuv/
I'm concerned that given the lack of release fr
Hi Jason,
Thanks for the patch. Wireguard is not part of the core OpenWRT/LEDE
systems, it is managed on https://github.com/openwrt/packages , so you
should have sent a pull request there.
Nevertheless, I will try to test and apply your patch within a few days.
Baptiste
On Thu, Nov 10, 2016 at
Karl Palsson wrote:
[snip]
I'm concerned that given the lack of release from both LEDE and
OpenWrt, people are starting to treat the for-15.05 branch like a
free for all "mainline" branch again.
[snip]
All,
15.05 should definitely not be treated as a "mainline" branch, neither
in core nor
TI wl18xx and wl12xx are Wi-Fi/Bluetooth combo modules
that could be found on different existing boards.
But it is possible to get those modules as a separate
component and use with existing boards as well as
new boards equipped with either module may appear so we
remove dependency on OMAP instead
From: Marek Lindner
A firmware compiled with BUSYBOX_CONFIG_ARP should also use by default the
arp binary from busybox. Otherwise the extra functionality the user
requested can only be used when running arp with the path to the binary.
Signed-off-by: Marek Lindner
---
package/base-files/files/
Hi,
pushed with http://git.lede-project.org/9978a3e and added the missing
">" to the first S-o-b.
Thanks,
Jo
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Hi,
how should non-actively used LEDs be handled in regards of entries in uci
system.*. I saw some entries in target/linux/ar71xx/base-files/etc/board.d/
01_leds with calls to ucidef_set_led_default with the default parameter set to
0. But not all LEDs have an entry in either 01_leds or diag.sh
Hi Sven,
imho it is preferable to have usable, but inactive LEDs available by
default in the system configuration.
~ Jo
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Given that the current leds init script only looks for some
explicit values, I've done the following to have a led _listed_
in the UCI file, and available to leds.sh, but not actually
touched by the init script...
> ucidef_set_led_default "etactica" "etactica" "eg200:red:etactica" "ignored"
It
Hi Karl,
I think there is not much speaking against making the led init script
run earlier. I think it would make sense to have it START=11, right
after /etc/init.d/boot.
~ Jo
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradea
2016-11-10 16:41 GMT+01:00 Jo-Philipp Wich :
> Hi Karl,
>
> I think there is not much speaking against making the led init script
> run earlier. I think it would make sense to have it START=11, right
> after /etc/init.d/boot.
I've a TDW-8980 here, where the ath9k driver acts as GPIO controller
for
Mathias Kresin wrote:
> 2016-11-10 16:41 GMT+01:00 Jo-Philipp Wich :
> > Hi Karl,
> >
> > I think there is not much speaking against making the led init script
> > run earlier. I think it would make sense to have it START=11, right
> > after /etc/init.d/boot.
>
> I've a TDW-8980 here, where the
Today asterisk disappeared from feeds
Does the build_bot are out of sync of their .config?
As you can see lede-halifax-rwth-aachen uploaded asterisk:
http://phase2.builds.lede-project.org/builders/mips_24kc/builds/309/steps/packageupload/logs/stdio
bowl-builder deleted it:
http://phase2.builds.l
On 11/10/2016 04:28 AM, Alexey Brodkin wrote:
> TI wl18xx and wl12xx are Wi-Fi/Bluetooth combo modules
> that could be found on different existing boards.
>
> But it is possible to get those modules as a separate
> component and use with existing boards as well as
> new boards equipped with either
18 matches
Mail list logo
