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
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
Hi,
On 10.11.2016 12:49, Karl Palsson wrote:
>
> Again, we're getting major version package updates in the stable
> for-15.05 branch. haproxy has just been updated from 1.5.x to
> 1.6.x, with no pull request, no mailing list discussion and by a
> committer without a proper name.
Iam sorry for pu
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
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
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.
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 Sven,
imho it is preferable to have usable, but inactive LEDs available by
default in the system configuration.
~ Jo
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
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,
pushed with http://git.lede-project.org/9978a3e and added the missing
">" to the first S-o-b.
Thanks,
Jo
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
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/
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
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
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
Again, we're getting major version package updates in the stable
for-15.05 branch. haproxy has just been updated from 1.5.x to
1.6.x, with no pull request, no mailing list discussion and by a
committer without a proper name.
Again, if packages in the stable release aren't enough for you,
_use you
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
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
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 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
___
openwrt-devel mailing list
open
18 matches
Mail list logo
