[LEDE-DEV] Collecting issues on github

[Ted Hess]

Hi folks,

I would like to propose we close the issues tab on the github/openwrt/openwrt source repository as we did for the 
lede-project/source repo. We can continue to re-direct people to our bug-tracker for the mainline sources.


The packages repo remains as it is now.

/ted


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 2/2] download.mk: introduce a new variable SKIPHASH

[Ted Hess]

Ack from me for PKG_HASH=none. Much easier to use.

/ted

-Original Message- 
From: Jo-Philipp Wich 
Sent: Thursday, December 07, 2017 9:56 AM 
To: lede-dev@lists.infradead.org 
Subject: Re: [LEDE-DEV] [PATCH 2/2] download.mk: introduce a new variable SKIPHASH 


Hi Baptiste,

we've been discussing this patch again on IRC today and I came up with
an alternate suggestion that does not require a new variable.

-- 8< --
diff --git a/scripts/download.pl b/scripts/download.pl
index 775408934a..ad9c480c67 100755
--- a/scripts/download.pl
+++ b/scripts/download.pl
@@ -88,7 +88,7 @@ sub download_cmd($) {
}

my $hash_cmd = hash_cmd();
-$hash_cmd or die "Cannot find appropriate hash command, ensure the
provided hash is either a MD5 or SHA256 checksum.\n";
+$hash_cmd or ($file_hash eq "none") or die "Cannot find appropriate
hash command, ensure the provided hash is either a MD5 or SHA256
checksum.\n";

sub download
{
-- >8 --

Using the change above one can issue a

 "make package/mypackage/download PKG_HASH=none"

to download ignoring the Makefile checksum while preserving the error
semantics of unset PKG_HASH cases.

Ideally I'd like to push the "none" variant but wanted to share the idea
on the list first to see what others think about it.

Regards,
Jo

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] layerscape: rename firmware packages to avoid name collisions

[Ted Hess]

layerscape firmware package names collide with existing package contributions.
Ex: layerscape mc and midnight-commander(mc) are in conflict.

Firmware packages: mc, ppa, rcw and dpl are renamed to ls-mc, ls-ppa, ls-rcw
and ls-dpl respectively.

Signed-off-by: Ted Hess <th...@kitschensync.net>
---
 package/firmware/layerscape/dpl/Makefile   |  58 ---
 package/firmware/layerscape/ls-dpl/Makefile|  58 +++
 package/firmware/layerscape/ls-mc/Makefile |  57 ++
 package/firmware/layerscape/ls-ppa/Makefile| 111 
 package/firmware/layerscape/ls-rcw/Makefile| 116 +
 ...ile-generate-byte_swap-rcw-for-ls1046ardb.patch |  26 +
 package/firmware/layerscape/mc/Makefile|  57 --
 package/firmware/layerscape/ppa/Makefile   | 111 
 package/firmware/layerscape/rcw/Makefile   | 116 -
 ...ile-generate-byte_swap-rcw-for-ls1046ardb.patch |  26 -
 10 files changed, 368 insertions(+), 368 deletions(-)
 delete mode 100644 package/firmware/layerscape/dpl/Makefile
 create mode 100644 package/firmware/layerscape/ls-dpl/Makefile
 create mode 100644 package/firmware/layerscape/ls-mc/Makefile
 create mode 100644 package/firmware/layerscape/ls-ppa/Makefile
 create mode 100644 package/firmware/layerscape/ls-rcw/Makefile
 create mode 100644 
package/firmware/layerscape/ls-rcw/patches/0001-makefile-generate-byte_swap-rcw-for-ls1046ardb.patch
 delete mode 100644 package/firmware/layerscape/mc/Makefile
 delete mode 100644 package/firmware/layerscape/ppa/Makefile
 delete mode 100644 package/firmware/layerscape/rcw/Makefile
 delete mode 100644 
package/firmware/layerscape/rcw/patches/0001-makefile-generate-byte_swap-rcw-for-ls1046ardb.patch

diff --git a/package/firmware/layerscape/dpl/Makefile 
b/package/firmware/layerscape/dpl/Makefile
deleted file mode 100644
index 5d6cb60..000
--- a/package/firmware/layerscape/dpl/Makefile
+++ /dev/null
@@ -1,58 +0,0 @@
-#
-# Copyright 2017 NXP
-#
-# This is free software, licensed under the GNU General Public License v2.
-# See /LICENSE for more information.
-#
-
-include $(TOPDIR)/rules.mk
-
-PKG_NAME:=dpl
-PKG_VERSION:=2017.09
-PKG_RELEASE:=1
-
-PKG_SOURCE_PROTO:=git
-PKG_SOURCE_URL:=https://github.com/qoriq-open-source/dpl-examples.git
-PKG_SOURCE_VERSION:=a6c83759c0d9c02822eec89e86357a0998ef51d4
-PKG_MIRROR_HASH:=3c5fdaa18e24ce8d6d5569eefd110c4b9a7b504a676341e7225a361a17e4e447
-
-PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)-$(PKG_VERSION)-$(BUILD_VARIANT)/$(PKG_NAME)-$(PKG_VERSION)
-
-PKG_FLAGS:=nonshared
-
-include $(INCLUDE_DIR)/package.mk
-
-define Package/layerscape-dpl-ls1088ardb
-  SECTION:=firmware
-  CATEGORY:=Firmware
-  DEPENDS:=@TARGET_layerscape
-  TITLE:=NXP LS1088ARDB DPL firmware
-  VARIANT:=ls1088ardb
-  DPC_CONFIG:=ls1088a/RDB/dpc.0x1D-0x0D.dtb
-  DPL_CONFIG:=ls1088a/RDB/dpl-eth.0x1D_0x0D.dtb
-endef
-
-define Package/layerscape-dpl-ls2088ardb
-  SECTION:=firmware
-  CATEGORY:=Firmware
-  DEPENDS:=@TARGET_layerscape
-  TITLE:=NXP LS2088ARDB DPL firmware
-  VARIANT:=ls2088ardb
-  DPC_CONFIG:=ls2088a/RDB/dpc.0x2A_0x41.dtb
-  DPL_CONFIG:=ls2088a/RDB/dpl-eth.0x2A_0x41.dtb
-endef
-
-define Package/layerscape-dpl-ls1088ardb/install
-   $(INSTALL_DIR) $(STAGING_DIR_IMAGE)
-   $(CP) $(PKG_BUILD_DIR)/$(DPL_CONFIG) 
$(STAGING_DIR_IMAGE)/ls1088ardb-dpl.dtb
-   $(CP) $(PKG_BUILD_DIR)/$(DPC_CONFIG) 
$(STAGING_DIR_IMAGE)/ls1088ardb-dpc.dtb
-endef
-
-define Package/layerscape-dpl-ls2088ardb/install
-   $(INSTALL_DIR) $(STAGING_DIR_IMAGE)
-   $(CP) $(PKG_BUILD_DIR)/$(DPL_CONFIG) 
$(STAGING_DIR_IMAGE)/ls2088ardb-dpl.dtb
-   $(CP) $(PKG_BUILD_DIR)/$(DPC_CONFIG) 
$(STAGING_DIR_IMAGE)/ls2088ardb-dpc.dtb
-endef
-
-$(eval $(call BuildPackage,layerscape-dpl-ls1088ardb))
-$(eval $(call BuildPackage,layerscape-dpl-ls2088ardb))
diff --git a/package/firmware/layerscape/ls-dpl/Makefile 
b/package/firmware/layerscape/ls-dpl/Makefile
new file mode 100644
index 000..f305dfb
--- /dev/null
+++ b/package/firmware/layerscape/ls-dpl/Makefile
@@ -0,0 +1,58 @@
+#
+# Copyright 2017 NXP
+#
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+#
+
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=ls-dpl
+PKG_VERSION:=2017.09
+PKG_RELEASE:=1
+
+PKG_SOURCE_PROTO:=git
+PKG_SOURCE_URL:=https://github.com/qoriq-open-source/dpl-examples.git
+PKG_SOURCE_VERSION:=a6c83759c0d9c02822eec89e86357a0998ef51d4
+PKG_MIRROR_HASH:=3c5fdaa18e24ce8d6d5569eefd110c4b9a7b504a676341e7225a361a17e4e447
+
+PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)-$(PKG_VERSION)-$(BUILD_VARIANT)/$(PKG_NAME)-$(PKG_VERSION)
+
+PKG_FLAGS:=nonshared
+
+include $(INCLUDE_DIR)/package.mk
+
+define Package/layerscape-dpl-ls1088ardb
+  SECTION:=firmware
+  CATEGORY:=Firmware
+  DEPENDS:=@TARGET_layerscape
+  TITLE:=NXP LS1088ARDB DPL firmware
+  VARIANT:=ls1088ardb
+  DPC_CONFIG:=ls1088a/RDB/dpc.0x1D-0x

Re: [LEDE-DEV] kernel 4.9 migration for next release

[Ted Hess]

Hi all -

I have pushed an update to kernel 4.9 for ixp4xx to my staging repo at:

https://git.lede-project.org/lede/thess/staging.git ixp4xx-kernel-4.9

I have only tested it on an Actiontec MI424WR and an NSLU2.
Any feedback appreciated. I will merge it soon if no problems arise.

/ted


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] kernel 4.9 migration for next release

[Ted Hess]

-Original Message- 
From: Hauke Mehrtens 
Sent: Monday, October 02, 2017 3:18 PM 
To: lede-dev@lists.infradead.org 
Subject: [LEDE-DEV] kernel 4.9 migration for next release 


For the next major LEDE release after 17.01 all targets should be on
kernel 4.9, otherwise they will most likely not be included in the release.

[...]

The following targets are on kernel 4.4 and need a upgrade to kernel 4.9
to be included:
* ixp4xx


I did do a set of patches to 4.9 for the ixp4xx platform back in March.
However, I could not get the SPI-GPIO interface to the Micrel KS8995 switch
on my MI424WR router operational at all. The SPI device never showed up.
The device worked with the spi-gpio-old driver which has been removed. I
tried setting up the 4.9 kernel support for spi over gpio but nothing I tried
worked out - I could use some help with this. Everything else was working
OK on 4.9

/ted

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Fw: FYI: LEDE got bossie award

[Ted Hess]

Fwd to a wider distribution

/ted

-Original Message- 
From: juha-pekka.laesvu...@iteco.fi 
Sent: Monday, October 02, 2017 8:07 AM 
To: cont...@lede-project.org 
Subject: FYI: LEDE got bossie award 


Hi!

Just to let you know that LEDE got bossie award

https://www.infoworld.com/article/3227605/security/bossie-awards-2017-the-best-networking-and-security-software.html#slide16

Br,
Juha-Pekka

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Conditional dependencies in Makefiles

[Ted Hess]

Hi Felix -

You make a good point here about the way we constructed the ffmpeg-full dependencies. We do need to re-think its configuration and 
somehow NOT create a 4th permanent build. Currently we have an ffmpeg-custom package which is not normally built but can be used for 
a custom tailored config in a private build.


We should also figure out if we need to be including high resource (CPU) encoders (like shine, x264 and lame) in all default builds. 
They are currently in the default buildbot packages since the optional libs are selected by CONFIG_ALL.


Thanks for suggestion on intermediate config symbols (as we do with -custom) -- 
will give this a try.

Regards,
/ted

-Original Message- 
From: Felix Fietkau

Sent: Tuesday, August 29, 2017 3:04 PM
To: Ted Hess ; lede-dev
Subject: Re: [LEDE-DEV] Conditional dependencies in Makefiles

Please don't introduce dependencies that magically get added based on
whether a different package is selected or not.
Either always use shine, or add a separate option to configure whether
or not it should be used.
Also make sure that anything that affects the build gets proper
treatment in CONFIGURE_ARGS and PKG_CONFIG_DEPENDS.

Aside from that, there is an easy way to deal with conditional
dependencies that depend on multiple options: Just create an
intermediate config symbol via Package//config that is hidden and
depends on the relevant multiple config symbols.

- Felix

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev 



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Conditional dependencies in Makefiles

[Ted Hess]

I think I tried that variation too and it was as if CONFIG_SOFT_FLOAT wasn't defined when the dependencies are calculated. I usally 
check the .packageinfo file to see what the enabled dependency config is. Strangely,  I think the problem lies with 
CONFIG_SOFT_FLOAT itself and the order of config evaluation?


/ted
-Original Message- 
From: Alexandru Ardelean

Sent: Tuesday, August 29, 2017 2:50 PM
To: LEDE Development List ; Ted Hess
Subject: Re: [LEDE-DEV] Conditional dependencies in Makefiles

What if you do outside of the function def.

ifeq ($(CONFIG_SOFT_FLOAT),y)
 FLOAT_DEPENDS:= +PACKAGE_shine:shine
else
  FLOAT_DEPENDS+= +PACKAGE_lame-lib:lame-lib +PACKAGE_libx264:libx264
endif

and then

DEPENDS+=$(FLOAT_DEPENDS)

?



On Tue, Aug 29, 2017 at 9:34 PM, Sebastian Kemper <sebastian...@gmx.net> wrote:

On Tue, Aug 29, 2017 at 05:15:51PM +, Sebastian Kemper wrote:

Hi Ted,

Maybe a stupid idea, but is there a tab in front of the depends? Does
removing it help?


No, that doesn't help.

I remember trying to do something like this with PKG_BUILD_DEPENDS and
couldn't get it working either.

Maybe the best you can do is this:

define Package/libffmpeg-full
$(call Package/libffmpeg/Default)
 TITLE+= (full)
 DEPENDS+= @BUILD_PATENTED +alsa-lib +PACKAGE_libopus:libopus @!SOFT_FLOAT 
+PACKAGE_lame-lib:lame-lib +PACKAGE_libx264:libx264
 VARIANT:=full
endef

Downside would be no libffmpeg-full for SOFT_FLOAT setups, obviously :)

On another note, are you sure you want deps like these:

+PACKAGE_libopus:libopus?

According to https://wiki.openwrt.org/doc/devel/dependencies it means
that libopus will only get selected by libffmpeg-full if libopus is
enabled. I think

+PACKAGE_libffmpeg-full:libopus

is what you're after.

Regards,
Sebastian



Seb

Am 29. August 2017 19:08:11 MESZ schrieb Ted Hess
<th...@kitschensync.net>:
>Hi all -
>
>I have a package (ffmpeg) build problem which is trying to specify a
>different DEPENDS for soft-float systems and one for hard-float. The
>package definition is as follows:
>
>> define Package/libffmpeg-full $(call Package/libffmpeg/Default)
>>  TITLE+= (full)  DEPENDS+= @BUILD_PATENTED +alsa-lib
>> +PACKAGE_libopus:libopus  ifeq ($(CONFIG_SOFT_FLOAT),y)
>> DEPENDS+= +PACKAGE_shine:shine  else DEPENDS+=
>> +PACKAGE_lame-lib:lame-lib +PACKAGE_libx264:libx264  endif
>>  VARIANT:=full endef
>
>Thinking the 'ifeq', etc is not proper within a function definition,
>I have also tried:
>
>  DEPENDS+=$(if
>$(CONFIG_SOFT_FLOAT),+PACKAGE_shine:shine,+PACKAGE_lame- lib:lame-lib
>+PACKAGE_libx264:libx264)
>
>In both cases, the behavior is as if CONFIG_SOFT_FLOAT is not
>defined.
>
>Any help would be greatly appreciated.
>
>/ted
>
>
>___ Lede-dev mailing list
>Lede-dev@lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/lede-dev

___ Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev 



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Conditional dependencies in Makefiles

[Ted Hess]

Hi all -

I have a package (ffmpeg) build problem which is trying to specify a different
DEPENDS for soft-float systems and one for hard-float. The package definition is
as follows:

> define Package/libffmpeg-full
> $(call Package/libffmpeg/Default)
>  TITLE+= (full)
>  DEPENDS+= @BUILD_PATENTED +alsa-lib +PACKAGE_libopus:libopus
>  ifeq ($(CONFIG_SOFT_FLOAT),y)
> DEPENDS+= +PACKAGE_shine:shine
>  else
> DEPENDS+= +PACKAGE_lame-lib:lame-lib +PACKAGE_libx264:libx264
>  endif
>  VARIANT:=full
> endef

Thinking the 'ifeq', etc is not proper within a function definition, I have also
tried:

  DEPENDS+=$(if $(CONFIG_SOFT_FLOAT),+PACKAGE_shine:shine,+PACKAGE_lame-
lib:lame-lib +PACKAGE_libx264:libx264)

In both cases, the behavior is as if CONFIG_SOFT_FLOAT is not defined.

Any help would be greatly appreciated.

/ted


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] libmpdclient - meson/ninja ?

[Ted Hess]

Hi all -

The latest releases of libmpdclient, part of the Music Player Daemon (mpd), has
been revised to build with the Meson build system and Ninja. It no longer has
support for autotools & make. Since we do not have the availability of this
build environment / toolchain, the current version (2.11) will be frozen in the
packages library.

Any thoughts?

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] libubox: Fix calloc_a() to return mem aligned pointers

[Ted Hess]

-Original Message- 
From: Felix Fietkau 
Sent: Friday, February 24, 2017 3:39 AM 
To: Ted Hess ; Yousong Zhou ; lede-dev 
Subject: Re: [LEDE-DEV] [PATCH] libubox: Fix calloc_a() to return mem aligned pointers 


On 2017-02-24 03:37, Ted Hess wrote:

Yousong -

As a side note to your side note - If you examine the actual
mechanics of the allocation, the memory block is indeed size aligned to
(4*sizeof(size_t)), but the actual pointer returned is offset of
(2*sizeof(size_t)) within the block. As in CHUNK_TO_MEM...

I think that for calloc_a, using 2*sizeof(size_t) is probably overkill;
it would be 64 bit on 32 bit architectures and 128 bit on 64 bit
architectures.

Using sizeof(size_t) should be enough:


Agree - If no other objections, I'll push the fix directly.

/ted


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] libubox: Fix calloc_a() to return mem aligned pointers

[Ted Hess]

-Original Message- 
From: Yousong Zhou

Sent: Thursday, February 23, 2017 7:15 PM
To: Ted Hess
Cc: lede-dev
Subject: Re: [LEDE-DEV] [PATCH] libubox: Fix calloc_a() to return mem aligned 
pointers

On 24 February 2017 at 05:20, Ted Hess <th...@kitschensync.net> wrote:

The current implementation of calloc_a() returns packed pointers for the extra
arguments. These packed, unaligned, pointers are OK for a lot of architectures,
but not all. This patch will aligned the pointers returned in a manner congruent
with malloc(). I do not believe the extra padding overhead is all the burdensome
considering the overhead of separate malloc/calloc/free call to accomplish the
same thing.


Signed-off-by: Ted Hess <th...@kitschensync.net>
---
 utils.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/utils.c b/utils.c
index 5d9d5aa..314f716 100644
--- a/utils.c
+++ b/utils.c
@@ -27,6 +27,9 @@
_addr; \
_addr = va_arg(_arg, void **), _len = _addr ? va_arg(_arg,
size_t) : 0)

+#define C_PTR_ALIGN(2*sizeof(size_t))
+#define C_PTR_MASK (-C_PTR_ALIGN)
+


sizeof(long) should be used for C_PTR_ALIGN, though I cannot find the
quote at the moment...

   yousong

I picked the expression from malloc in the musl sources. No hard preferences, but it does do proper alignment for 64-bit systems and 
other sensitive data-types AFAICT.


/ted


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] libubox: Fix calloc_a() to return mem aligned pointers

[Ted Hess]

The current implementation of calloc_a() returns packed pointers for the extra
arguments. These packed, unaligned, pointers are OK for a lot of architectures,
but not all. This patch will aligned the pointers returned in a manner congruent
with malloc(). I do not believe the extra padding overhead is all the burdensome
considering the overhead of separate malloc/calloc/free call to accomplish the
same thing.


Signed-off-by: Ted Hess <th...@kitschensync.net>
---
 utils.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/utils.c b/utils.c
index 5d9d5aa..314f716 100644
--- a/utils.c
+++ b/utils.c
@@ -27,6 +27,9 @@
    _addr; \
    _addr = va_arg(_arg, void **), _len = _addr ? va_arg(_arg,
size_t) : 0)
 
+#define C_PTR_ALIGN(2*sizeof(size_t))
+#define C_PTR_MASK (-C_PTR_ALIGN)
+
 void *__calloc_a(size_t len, ...)
 {
    va_list ap, ap1;
@@ -40,7 +43,7 @@ void *__calloc_a(size_t len, ...)
 
    va_copy(ap1, ap);
    foreach_arg(ap1, cur_addr, cur_len, , len)
-   alloc_len += cur_len;
+   alloc_len += (cur_len + C_PTR_ALIGN - 1 ) & C_PTR_MASK;
    va_end(ap1);
 
    ptr = calloc(1, alloc_len);
@@ -49,7 +52,7 @@ void *__calloc_a(size_t len, ...)
    alloc_len = 0;
    foreach_arg(ap, cur_addr, cur_len, , len) {
    *cur_addr = [alloc_len];
-   alloc_len += cur_len;
+   alloc_len += (cur_len + C_PTR_ALIGN - 1) & C_PTR_MASK;
    }
    va_end(ap);
 
-- 
2.7.4


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Making staging tree appear on cgit?

[Ted Hess]

On Tue, 2017-01-17 at 11:10 -0800, Florian Fainelli wrote:
> Hi,
> 
> Are there specific instructions not currently documented at:
> https://lede-project.org/docs/guide-developer/the-source-code
> 
> that are needed in order to make one's staging tree appear on cgit?
> 
> Thanks!

There should be nothing special beyond what was already outlined in my easy-use
guide for private repos. There is a problem that just recently appeared where
private repos as disappearing from gitweb due to what I think is recent script
hook changes.

I can manually make your repo re-appear but it will disappear again on your next
push to it. Stay tuned...

/ted


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] forum limitations

[Ted Hess]

On Tue, 2017-01-17 at 09:32 -0800, David Lang wrote:
> currently new users (for some definition of 'new', I have 63 posts starting 
> within a day or two of when the forum was created) are limited to 3 replies in
> a 
> topic.
> 
> This limit is really easy to hit in a technical discussion and is going to
> drive 
> people to create extra topics to work around the limitation.
> 
> 
> example error message via e-mail:
> 
> We're sorry, but your email message to 
> ["forum+reply-83162f79a9a8b8efaf1a2e8dae533...@lede-project.org"] (titled Re: 
> [LEDE Project
> Forum] [Installing and Using LEDE] Wlan 2.4/5Ghz to slow fpr 1080p/60fps?) 
> didn't work.
> 
> Reason:
> 
> We're sorry, but new users are temporarily limited to 3 replies in the same 
> topic.
> 
> If you can correct the problem, please try again.
> 
> 
> 
> David Lang
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

Yes, we could increase that limit - However, do you need to add more than 3
replies in a row to a single topic before some else replies to it. You could
more easily just edit/append to one of your existing replies.

See discussion at: 

https://meta.discourse.org/t/why-is-there-a-topic-reply-limit-for-new-users/1151
3

/ted

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Branching LEDE 17.01

[Ted Hess]

On Tue, 2017-01-10 at 16:19 +0100, Jo-Philipp Wich wrote:
> Hi guys,
> 
> I'd like to branch off lede-17.01 on Friday, the 13th and would
> appreciate if you could merge your outstanding, release critical work
> until then.
> 
> If you think we should delay branching, then raise your objections now.
> 
> If no objections are brought up within the next 24 hours, I'll go
> forward asking the feed maintainers to create "lede-17.01" branches.
> 
> 
> Regards,
> Jo
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

Hi Jo -

Could you possibly hold off on this until after the weekend. I'm still working
on a few PolarSSL issues (and some other more minor) in the Packages repo. I
should have them done by then.

After that, I'll just cherry-pick other fixes until we freeze a release.

/ted


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Fading out PolarSSL

[Ted Hess]

On Tue, 2017-01-03 at 17:32 +0100, Steven Barth wrote:
> Hey everyone,
> 
> > 
> > Currently known remaining users of polarssl are:
> > 
> >  * bmx7
> >  * pianod
> >  * shadowsocks-libev-polarssl
> >  * shairport-sync-mini
> >  * shairport-sync-polarssl
> >  * transmission-cli-polarssl
> >  * transmission-daemon-polarssl
> >  * transmission-remote-polarssl
> >  * umurmur-polarssl
> > 
> > 
> > Please provide feedback on which approach you'd prefer and if you'd be
> > affected by the PolarSSL deprecation or not.
> I think for all but the first two from this list, there is a 
> non-polarssl version already packaged.
> Which would mainly leave bmx7 and pianod as main concerns. I think the 
> former used to work with cyassl
> at some point in time and the latter should work with gnutls. Both of 
> which we have, so it might just
> be a minor change to the packaging Makefiles.
> 
> So from my point of view dropping libpolarssl now (with a bit of upfront 
> notice to the maintainers)
> makes more sense than trying to drop a package later which is a bit of 
> unexpected and am not sure if
> it can be effectively announced in a service release and just delays the 
> inevitable.
> 
> 
> Cheers,
> 
> Steven
> 
> ___
> lede-adm mailing list
> lede-...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-adm

Drop it now.

Speaking for pianod and shairport-sync... I have already updated pianod (which I
still develop) to use mbed TLS and I am currently working with the shairport-
sync developer to replace PolarSSL with mbed TLS this weekend.

/ted

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [Forum] Certificate expired

[Ted Hess]

Nope, @jow - you won...

/ted

-Original Message- 
From: Jo-Philipp Wich

Sent: Thursday, December 08, 2016 5:09 PM
To: Thomas Endt
Cc: lede-dev@lists.infradead.org
Subject: Re: [LEDE-DEV] [Forum] Certificate expired

Thanks Thomas,

will check in approx. one or two hours  unless Ted beats me to it.

~ Jo


Am 08.12.2016 um 22:04 schrieb Thomas Endt :

It's currently not possible to visit the forum with Firefox + Chrome:

forum.lede-project.org verwendet ein ungültiges Sicherheitszertifikat.
Das Zertifikat ist am Donnerstag, 8. Dezember 2016 20:00 abgelaufen. Die
aktuelle Zeit ist Donnerstag, 8. Dezember 2016 22:01. Fehlercode:
SEC_ERROR_EXPIRED_CERTIFICATE

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev 



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] How do you develop (compile) LEDE efficiently?

[Ted Hess]

-Original Message- 
From: Weedy

Sent: Monday, November 07, 2016 3:03 PM
To: Rafał Miłecki
Cc: LEDE Development List
Subject: Re: [LEDE-DEV] How do you develop (compile) LEDE efficiently?

On Sun, Nov 6, 2016 at 3:24 PM, Rafał Miłecki  wrote:

I'm looking for a new notebook, but I can't find anything with i7 quad
core + AMD GPU. I may need to buy something with i7-6500U or i7-7500U
which may be too slow for compiling LEDE.



Dell Precisions they will compile for days and never overheat. You can
get AMD or Nvidia GPUs


+1 for Dell Precision laptops - My M4300 (retired) and more recently my M4800 are quite fast for doing full builds. M4800 
w/Quad-core i7 4910MQ @2.9GHz;3.9Ghz turbo + nVidia K1100M / Intel HD graphics w/ 16GB RAM and 2x500G SSD (Raid 1). I think the 
newest series is Precision 15.


/ted


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] LEDE Forum now open for business

[Ted Hess]

Hi all -

Here it is: https://forum.lede-project.org

You can now self-register without admin approval.

With a lot of help and comments from a bunch of the current users, I think we
now have a very usable site. We may still tweak the style, layouts and options
as we mature the site so don't be upset if the site changes.

So, visit the site, register and leave us a comment in the Site Feedback
category (https://forum.lede-project.org/c/site-feedback).

/ted


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Has a forum been selected?

[Ted Hess]

On Tue, 2016-11-01 at 18:50 +, grgw...@unseen.is wrote:
> Hey, guys. Looking forward to the start of a LEDE forum. Has a consensus been
> reached on where it will be hosted? When it is up and running, will there be
> any announcements other than on this mailing list? I'm wondering where I
> should keep an eye out for notice.
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

Announced here:
http://lists.infradead.org/pipermail/lede-dev/2016-October/003650.html

Available here:
https://forum.lede-project.org

/ted

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] LEDE Forum - Startup mode

[Ted Hess]

Hi all -

First off, thanks for all the feedback, suggestions and volunteers. For
starters, and perhaps to become permanent, we have set up a copy of Discourse
(http://discourse.org) for testing and evaluation. It is a very popular package
for new organizations and it has a pretty active community and support. 

Discourse puts a high demand on the user's client software capabilities and may
present some problems to users of screen readers. We would like to ask those
using screen readers to take a look at our site and give us your opinions with
respect the accessibility of our forum.

Before we can "go live" for everyone all accounts need to be admin approved.
This will be a quick and very liberal process. Admins currently are: Rich Brown
(richb-hanover), Thomas Endt (tmomas), myself, jow & blogic. If we get enough
interest and no one has good reasons not to proceed, and we have success setting
up the forum categories and site description (Welcome, ToS, FAQ, etc), we can go
live and allow open general self-registration. We will not be allowing anonymous
posting.

For those not wishing to use the forum site directly, once you have registered
you will be able reply to topics via e-mail. Additionally, we may enable the
ability to post new topics via e-mail to users with advanced trust levels to
certain categories.

During this initial startup period, we reserve the right to:
 * Take the site off-line for maintenance and reconfiguration.
 * Remove unwanted posts and uploaded content.
 * Revoke privileges and/or remove unwanted accounts.

So, visit the site, sign-up and post us a note. We will try to respond to all
requests. Try things out, send me or another admin any requests for site
configuration changes - or better yet, post a topic for those discussions.

And yes, Github logins are possible once you are registered.

/ted

Site location: https://forum.lede-project.org
Email: fo...@lede-project.org


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [packages for-15.05 PATCH 2/2] ffmpeg: backport AAC fix for multichannel mapping

[Ted Hess]

Thanks for these updates - I manually merged them to for-15.05.
https://github.com/openwrt/packages/commit/9de3069a949d303dcafd52c6df11baa7c673b
57f

(Tried to include your SoB, but branch wouldn't allow force-push after amend --
sorry)

/ted

On Fri, 2016-09-30 at 14:17 +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> It's a backport from 2.7 branch that fixes parsing some AAC formats.
> 
> What makes this quite important is that broken parsing was leading to
> many loop iterations, scanning taking a lot of time and allocating a lot
> of memory. Parsing 1.3 GB MPEG TS file could result in allocating
> 55+ MiB of memory causing OOM on some embedded platforms.
> 
> This is important change e.g. for minidlna users who were complaining
> about slowness and memory consumption of scanning process. This problem
> was forcing some users to building minidlna database on PCs and moving
> ready one to the target device.
> 
> Signed-off-by: Rafał Miłecki 
> ---
>  multimedia/ffmpeg/Makefile |  2 +-
>  ...ly-map-multichannel-ADTS-AAC-with-non-zer.patch | 68
> ++
>  2 files changed, 69 insertions(+), 1 deletion(-)
>  create mode 100644 multimedia/ffmpeg/patches/050-aac-Correctly-map-
> multichannel-ADTS-AAC-with-non-zer.patch
> 
> diff --git a/multimedia/ffmpeg/Makefile b/multimedia/ffmpeg/Makefile
> index 493f47a..4d9cf01 100644
> --- a/multimedia/ffmpeg/Makefile
> +++ b/multimedia/ffmpeg/Makefile
> @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
>  
>  PKG_NAME:=ffmpeg
>  PKG_VERSION:=2.6.9
> -PKG_RELEASE:=1
> +PKG_RELEASE:=2
>  
>  PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
>  PKG_SOURCE_URL:=http://ffmpeg.org/releases/
> diff --git a/multimedia/ffmpeg/patches/050-aac-Correctly-map-multichannel-
> ADTS-AAC-with-non-zer.patch b/multimedia/ffmpeg/patches/050-aac-Correctly-map-
> multichannel-ADTS-AAC-with-non-zer.patch
> new file mode 100644
> index 000..4ef1914
> --- /dev/null
> +++ b/multimedia/ffmpeg/patches/050-aac-Correctly-map-multichannel-ADTS-AAC-
> with-non-zer.patch
> @@ -0,0 +1,68 @@
> +From 0289f81241e720452b5a77713488d54d3ec252d7 Mon Sep 17 00:00:00 2001
> +From: nu774 
> +Date: Wed, 3 Jun 2015 14:01:32 +0900
> +Subject: [PATCH] aac: Correctly map multichannel ADTS AAC with non-zero
> + channel_config + PCE
> +
> +The decoder assigns channels using default channel configuration
> +for 5.1ch when it parses an ADTS frame header using consecutive
> +channel ids.
> +
> +When a PCE comes, it reassigns channels using PCE configuration
> +using directly the ids provided. They can be arbitrary.
> +
> +Always use consecutive channel ids to avoid decoding glitches due
> +spurious reconfigurations due the channel ids mismatch between the
> +two otherwise-identical channel maps.
> +
> +Signed-off-by: Luca Barbato 
> +---
> + libavcodec/aacdec.c | 13 ++---
> + 1 file changed, 10 insertions(+), 3 deletions(-)
> +
> +--- a/libavcodec/aacdec.c
>  b/libavcodec/aacdec.c
> +@@ -457,12 +457,18 @@ static int output_configure(AACContext *
> + AVCodecContext *avctx = ac->avctx;
> + int i, channels = 0, ret;
> + uint64_t layout = 0;
> ++uint8_t id_map[TYPE_END][MAX_ELEM_ID] = {{ 0 }};
> ++uint8_t type_counts[TYPE_END] = { 0 };
> + 
> + if (ac->oc[1].layout_map != layout_map) {
> + memcpy(ac->oc[1].layout_map, layout_map, tags *
> sizeof(layout_map[0]));
> + ac->oc[1].layout_map_tags = tags;
> + }
> +-
> ++for (i = 0; i < tags; i++) {
> ++int type = layout_map[i][0];
> ++int id =   layout_map[i][1];
> ++id_map[type][id] = type_counts[type]++;
> ++}
> + // Try to sniff a reasonable channel order, otherwise output the
> + // channels in the order the PCE declared them.
> + if (avctx->request_channel_layout != AV_CH_LAYOUT_NATIVE)
> +@@ -470,12 +476,14 @@ static int output_configure(AACContext *
> + for (i = 0; i < tags; i++) {
> + int type = layout_map[i][0];
> + int id =   layout_map[i][1];
> ++int iid =  id_map[type][id];
> + int position = layout_map[i][2];
> + // Allocate or free elements depending on if they are in the
> + // current program configuration.
> +-ret = che_configure(ac, position, type, id, );
> ++ret = che_configure(ac, position, type, iid, );
> + if (ret < 0)
> + return ret;
> ++ac->tag_che_map[type][id] = ac->che[type][iid];
> + }
> + if (ac->oc[1].m4ac.ps == 1 && channels == 2) {
> + if (layout == AV_CH_FRONT_CENTER) {
> +@@ -485,7 +493,6 @@ static int output_configure(AACContext *
> + }
> + }
> + 
> +-memcpy(ac->tag_che_map, ac->che, 4 * MAX_ELEM_ID * sizeof(ac-
> >che[0][0]));
> + if (layout) avctx->channel_layout = layout;
> + ac->oc[1].channel_layout = layout;
> + avctx->channels   = 

Re: [LEDE-DEV] A Wiki for LEDE Documentation

[Ted Hess]

On Sun, 2016-09-25 at 20:15 +0200, Thomas Endt wrote:
> What would be the official LEDE logo for the wiki?
> 
> This one?
> https://www.lede-project.org/logo/logo_small.png
> 
> If yes: Can I have this in a bigger size, please?
> 

The best place to start is here: https://github.com/lede-project/web/blob/master
/logo/logo.svg

Then create any size (png or jpg) you want :)

/ted

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] LEDE Wiki Teambuilding

[Ted Hess]

Hi all,

I can get you started with LEDE infrastructure and get Martin and Jan-Tarek
appropriate access to a Digital Ocean droplet for setup. Please contact me
directly if you want to go ahead with a LEDE droplet for the Wiki and we can go
from there. I will at least need your SSH RSA public keys to start. We already
have a droplet set aside for a forum which is staged but unused (currently
running a docker instance of Discourse). Adding some wiki package here would
probably make the most sense given expected usage. I'd even be willing to do the
initial install and access setup this week/end. Suggest a package...

I don't usually hang-out on IRC, so email is the best way to communicate.

/ted

CC to lede-adm where others can weigh in.


NameFunction
=
Ted Hess (th...@kitschensync.net),
Martin Tippmann  (m...@i3o.de),
Jan-Tarek Butt t...@ring0.de
Infrastructure / I could take
care of nginx, caching, let's encrypt, mysql,
php, memcache whatever.

Thomas Endt,            wiki admin / enabler / maintenance
ToH maintainer, Gardener, Editor

N.N.wiki admin / enabler / maintenance
ToH maintainer

Alberto Bursi   (alberto.bu...@outlook.it),   Editor, Gardener

Rich Brown   (richb.hano...@gmail.com),
Editor, Gardener, and maybe
maintenance

N.N.,   Optimizing, pluging inplementation, organisation



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Extraneous messages from issue tracker

[Ted Hess]

Hi all -

If you are receiving a message about a task change which was done by me and
don't know what changed - It's due to the work I am doing on issue "tags". I am
removing redundant information and cleaning up the actual tags in use to be
single word items. Tags may now be a list of single words separated by spaces,
commas or semi-colons. If you must use a phrase, separate the 'words' with "_"
or "-".

Sorry for any nuisance email.

/ted


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] lede forum

[Ted Hess]

On Sun, 2016-07-24 at 16:37 +0200, moeller0 wrote:
> > 
> > On Jul 24, 2016, at 15:41 , tapper  wrote:
> > 
> > Hi with the ssl sert being messed up on the openwrt forum we really need a
> > forum for lede. I don't know how to set one up but wen one is put up i wood
> > like to be a admin to help with noobs and getting rid of spam. I have bin a
> > admin on the Gargoyle forum now for a long time and like helping people out.
> > thanks  Tapper..
>   Oh, speaking of a forum, I believe, if LEDE wants to get its own forum
> (which) I would support it should come with more administration than the
> openwrt forums that, at times, are pretty far away from lede’s “be nice to
> each other” guidelines. I am not advocating to keep the ban-hammer swinging
> all times, but there should be some feed-back and potential consequences of
> prolonged and repeated lack of nice-ness…
>   I believe that tapper has shown exactly the kind of moderation a
> potential lede forum should have, so I support his “election” to forum
> administrator/moderator (for what it is worth)…

@tapper, @moeller0, & others

We had a brief discussion at our last mtg about what to do about a Wiki and
forum. One suggestion was to become a sub-forum in the OpenWrt forum if they'd
have us as a 'community build' - aka "The Dark Side" ;) That's sort of moot at
the moment since openwrt.org is in a certificate service valley.

We don't think we can handle our own wiki & forum without a whole lot of help
with content, moderation & management. We also have to find resources to host
the sites.

And... do you guys have any suggestions/recommendations for software (presumably
free) to deploy.

I'm here to help with the staging and systems work (installing and deploying the
base software) - I would like to see other volunteers to take on forum and/or
wiki admin, etc.

/ted


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] new bugs mailing list

[Ted Hess]

Daniel -

Subject to a few more folk's OKs and an up-coming adm meeting, I think we are going to go forward with Flyspray. There is no other 
proposed systems on deck for testing, so this is it unless someone proposes an alternative for further testing, etc.


If you need any help getting at the Flyspray data directly, I can help you out there. The backend is a MySQL DB and regular sync'd 
backups of it could be available on the mirror site. Otherwise, you can pull your data from the existing "export" feature and/or the 
lede-bugs mailing-list. I am working on implementing Flyspray backup so this would be a good time to discuss.


/ted

-Original Message- 
From: Daniel Curran-Dickinson

Sent: Wednesday, June 22, 2016 4:50 PM
To: John Crispin
Cc: LEDE Development List
Subject: Re: [LEDE-DEV] new bugs mailing list

Hi John,

On Wed, 2016-06-22 at 09:57 +0200, John Crispin wrote:

Hi,

the issue tracker now announces bug reports on this list



I missed the announcement of the issue tracker; has it been finalized or
still in testing?  If finalized I should take a look at working on the
automated info gathering I've promised (and actually even if not
finalized get started, based on previous discussions, on the info gather
part, even without the big tracker integration).

Regards,

Daniel


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev 



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Add info about git URLs in Lede Git Web

[Ted Hess]

Check it out now...

/ted

On Thu, 2016-06-02 at 13:41 +, Alexey Brodkin wrote:
> Hello,
> 
> I think it would be quite convenient to add info about URLs
> that could be used for accessing Lede repos via git.
> 
> In OpenWRT Git Web we had something like that:
> --->8---
> URL  http://git.openwrt.org/openwrt.git
>      https://git.openwrt.org/openwrt.git
>      git://git.openwrt.org/openwrt.git
> --->8---
> 
> In case of Lede we don't have this information for example here:
> https://git.lede-project.org/?p=source.git;a=summary
> 
> and every time one needs to figure out what is a correct URL that
> should be passed to git. And it's not only URL itself but what
> could be even more important what protocols could be used: git, http, https?
> 
> -Alexey
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] mac80211: change default SSID from Lede to LEDE

[Ted Hess]

From: Rafał Miłecki
Sent: Tuesday, May 24, 2016 3:37 AM
To: lede-dev@lists.infradead.org
Cc: Rafał Miłecki
Subject: [LEDE-DEV] [PATCH] mac80211: change default SSID from Lede to LEDE

LEDE project seems to be using "LEDE" as its acronym everywhere. To keep
things consistent adjust default wireless SSID.


Hi Rafał -

+1 from me - I like the idea of changing the default SSID of the freshly 
installed system.
It would really be cool if it could be something unique like LEDE where 
'' is the last
4-6digits of the MAC addr.

I'm just sayin'.

/ted


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Status of OpenWrt feeds in LEDE

[Ted Hess]

Mike -

The packages in the LEDE source repo are just the base-system packages as they were in the OpenWRT repo. The Github packages 
(openwrt/packages) will continue as they are and will be used by both distros. Hopefully, the packages will continue to be build in 
both environments.


/ted

-Original Message- 
From: W. Michael Petullo

Sent: Sunday, May 08, 2016 4:59 PM
To: lede-dev@lists.infradead.org
Subject: [LEDE-DEV] Status of OpenWrt feeds in LEDE

I am the maintainer of a number of OpenWrt packages, and I am watching
with interest the emargence of the LEDE project. Some time ago, OpenWrt
migrated to GitHub for some of its feeds, including the packages feed. At
that time, many of the packages were deprecated until the maintainter
manually migrated them to GitHub (e.g., gstreamer1). I just finished an
initial review of the LEDE Git repositories, and it seems a number of
packages are missing. Will we go through a period of manual migration
again? What is in store for all of these packages with respect to LEDE?

Thank you,

--
Mike

:wq

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev 



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev