[oe] [PATCH 2/2] relayd: Move to meta-openwrt repo

[cshored]

From: "Daniel F. Dickinson" 

Because this package is primarily useful in the context
of other opewnrt packages such as netifd, and not widely
deployed outside openwrt, move to the meta-openwrt layer's
repo.

Signed-off-by: Daniel F. Dickinson 
---
 .../0001-rtnl_flush-Error-on-failed-write.patch| 34 --
 .../recipes-connectivity/relayd/relayd_git.bb  | 17 ---
 2 files changed, 51 deletions(-)
 delete mode 100644 
meta-networking/recipes-connectivity/relayd/relayd/0001-rtnl_flush-Error-on-failed-write.patch
 delete mode 100644 meta-networking/recipes-connectivity/relayd/relayd_git.bb

diff --git 
a/meta-networking/recipes-connectivity/relayd/relayd/0001-rtnl_flush-Error-on-failed-write.patch
 
b/meta-networking/recipes-connectivity/relayd/relayd/0001-rtnl_flush-Error-on-failed-write.patch
deleted file mode 100644
index eaaf30460..0
--- 
a/meta-networking/recipes-connectivity/relayd/relayd/0001-rtnl_flush-Error-on-failed-write.patch
+++ /dev/null
@@ -1,34 +0,0 @@
-From 2fa326b26dc479942367dc4283e2f87372403988 Mon Sep 17 00:00:00 2001
-From: Khem Raj 
-Date: Sat, 17 Jun 2017 09:32:04 -0700
-Subject: [PATCH] rtnl_flush: Error on failed write()
-
-Fixes
-route.c:45:2: error: ignoring return value of 'write', declared with attribute 
warn_unused_result [-Werror=unused-result]
-|   write(fd, "-1", 2);
-|   ^~
-
-Signed-off-by: Khem Raj 

-Upstream-Status: Submitted
-
- route.c | 3 ++-
- 1 file changed, 2 insertions(+), 1 deletion(-)
-
-diff --git a/route.c b/route.c
-index c552d1f..fc5c31e 100644
 a/route.c
-+++ b/route.c
-@@ -42,7 +42,8 @@ static void rtnl_flush(void)
-   if (fd < 0)
-   return;
- 
--  write(fd, "-1", 2);
-+  if (write(fd, "-1", 2) < 0 )
-+  perror("write");
-   close(fd);
- }
- 
--- 
-2.13.1
-
diff --git a/meta-networking/recipes-connectivity/relayd/relayd_git.bb 
b/meta-networking/recipes-connectivity/relayd/relayd_git.bb
deleted file mode 100644
index 98dc41a09..0
--- a/meta-networking/recipes-connectivity/relayd/relayd_git.bb
+++ /dev/null
@@ -1,17 +0,0 @@
-DESCRIPTION = "Layer 3 relay daemon"
-SECTION = "console/network"
-LICENSE = "GPLv2"
-LIC_FILES_CHKSUM = 
"file://main.c;endline=17;md5=86aad799085683e0a2e1c2684a20bab2"
-
-DEPENDS = "libubox"
-
-SRC_URI = "git://git.openwrt.org/project/relayd.git \
-   file://0001-rtnl_flush-Error-on-failed-write.patch \
-"
-
-SRCREV = "ad0b25ad74345d367c62311e14b279f5ccb8ef13"
-PV = "0.0.1+git${SRCPV}"
-
-S = "${WORKDIR}/git"
-
-inherit cmake
-- 
2.11.0

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [networking] [PATCH 0/2] Move openwrt-upstream packages to meta-openwrt

[cshored]

 ...01-rtnl_flush-Error-on-failed-write.patch | 34 ---
 .../relayd/relayd_git.bb | 17 
 .../libubox/0001-version-libraries.patch | 28 
 .../libubox/libubox/fix-libdir.patch | 40 --
 .../recipes-devtools/libubox/libubox_git.bb  | 30 -
 5 files changed, 149 deletions(-)

libubox is probably uncontroversial and in fact was suggested by
Khem Raj here: 
http://lists.openembedded.org/pipermail/openembedded-devel/2018-January/116565.html

relayd I'm not as sure about as it's in meta-networking and there is
the off chance it's actually in use.  I'm open to opinions.

In any event I'm updating meta-openwrt with the good things done in
meta-openembedded, as well as other work to meake meta-openwrt
more generally useful (for use as a hybrid with regular OE, 
as a more openwrt-built-with-OE distro, and as a pick the bits
that make sense to you repo).

Regards,

Daniel
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [PATCH 1/2] libubox: Move to meta-openwrt repo

[cshored]

From: "Daniel F. Dickinson" 

libubox is primarily useful in the context of openwrt packages
and per Khem Raj does not belong in meta-oe (see
http://lists.openembedded.org/pipermail/openembedded-devel/2018-January/116565.html)

Signed-off-by: Daniel F. Dickinson 
---
 .../libubox/libubox/0001-version-libraries.patch   | 28 ---
 .../libubox/libubox/fix-libdir.patch   | 40 --
 meta-oe/recipes-devtools/libubox/libubox_git.bb| 30 
 3 files changed, 98 deletions(-)
 delete mode 100644 
meta-oe/recipes-devtools/libubox/libubox/0001-version-libraries.patch
 delete mode 100644 meta-oe/recipes-devtools/libubox/libubox/fix-libdir.patch
 delete mode 100644 meta-oe/recipes-devtools/libubox/libubox_git.bb

diff --git 
a/meta-oe/recipes-devtools/libubox/libubox/0001-version-libraries.patch 
b/meta-oe/recipes-devtools/libubox/libubox/0001-version-libraries.patch
deleted file mode 100644
index 02117fa8d..0
--- a/meta-oe/recipes-devtools/libubox/libubox/0001-version-libraries.patch
+++ /dev/null
@@ -1,28 +0,0 @@
-diff --git a/CMakeLists.txt b/CMakeLists.txt
-index 57804cf..1aa7f27 100644
 a/CMakeLists.txt
-+++ b/CMakeLists.txt
-@@ -18,6 +18,7 @@ ENDIF()
- SET(SOURCES avl.c avl-cmp.c blob.c blobmsg.c uloop.c usock.c ustream.c 
ustream-fd.c vlist.c utils.c safe_list.c runqueue.c md5.c kvlist.c ulog.c 
base64.c)
- 
- ADD_LIBRARY(ubox SHARED ${SOURCES})
-+SET_TARGET_PROPERTIES(ubox PROPERTIES VERSION 1.0.1 SOVERSION 1)
- ADD_LIBRARY(ubox-static STATIC ${SOURCES})
- SET_TARGET_PROPERTIES(ubox-static PROPERTIES OUTPUT_NAME ubox)
- 
-@@ -46,6 +47,7 @@ find_library(json NAMES json-c)
- IF(EXISTS ${json})
-   ADD_LIBRARY(blobmsg_json SHARED blobmsg_json.c)
-   TARGET_LINK_LIBRARIES(blobmsg_json ubox ${json})
-+  SET_TARGET_PROPERTIES(blobmsg_json PROPERTIES VERSION 1.0.1 SOVERSION 1)
- 
-   ADD_LIBRARY(blobmsg_json-static STATIC blobmsg_json.c)
-   SET_TARGET_PROPERTIES(blobmsg_json-static
-@@ -55,6 +57,7 @@ IF(EXISTS ${json})
-   TARGET_LINK_LIBRARIES(jshn blobmsg_json ${json})
- 
-   ADD_LIBRARY(json_script SHARED json_script.c)
-+  SET_TARGET_PROPERTIES(json_script PROPERTIES VERSION 1.0.1 SOVERSION 1)
-   TARGET_LINK_LIBRARIES(json_script ubox)
- 
-   INSTALL(TARGETS blobmsg_json blobmsg_json-static jshn json_script
diff --git a/meta-oe/recipes-devtools/libubox/libubox/fix-libdir.patch 
b/meta-oe/recipes-devtools/libubox/libubox/fix-libdir.patch
deleted file mode 100644
index 6f09c8b29..0
--- a/meta-oe/recipes-devtools/libubox/libubox/fix-libdir.patch
+++ /dev/null
@@ -1,40 +0,0 @@
-[PATCH] fix the CMAKE_INSTALL_LIBDIR
-
-Upstream-Status: Pending
-
-libdir maybe /usr/lib64 for 64bit machine
-
-Signed-off-by: Roy Li 

- CMakeLists.txt | 8 
- 1 file changed, 4 insertions(+), 4 deletions(-)
-
-diff --git a/CMakeLists.txt b/CMakeLists.txt
-index 57804cf..2c7bdc1 100644
 a/CMakeLists.txt
-+++ b/CMakeLists.txt
-@@ -35,8 +35,8 @@ INSTALL(FILES ${headers}
-   DESTINATION include/libubox
- )
- INSTALL(TARGETS ubox ubox-static
--  ARCHIVE DESTINATION lib
--  LIBRARY DESTINATION lib
-+  ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
-+  LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
- )
- 
- ADD_SUBDIRECTORY(lua)
-@@ -58,8 +58,8 @@ IF(EXISTS ${json})
-   TARGET_LINK_LIBRARIES(json_script ubox)
- 
-   INSTALL(TARGETS blobmsg_json blobmsg_json-static jshn json_script
--  ARCHIVE DESTINATION lib
--  LIBRARY DESTINATION lib
-+  ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
-+  LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
-   RUNTIME DESTINATION bin
-   )
- 
--- 
-1.9.1
-
diff --git a/meta-oe/recipes-devtools/libubox/libubox_git.bb 
b/meta-oe/recipes-devtools/libubox/libubox_git.bb
deleted file mode 100644
index f9f4e08b7..0
--- a/meta-oe/recipes-devtools/libubox/libubox_git.bb
+++ /dev/null
@@ -1,30 +0,0 @@
-DESCRIPTION = "C utility functions for OpenWrt"
-SECTION = "libs"
-LICENSE = "GPLv2"
-LIC_FILES_CHKSUM = "\
-file://avl.c;endline=39;md5=00810155fed3d604816ec5814523d60a \
-file://avl-cmp.c;endline=15;md5=1603e6094b432a5f3f320877a06f41b5 \
-file://base64.c;endline=61;md5=51fdff010d45b0086ac0a6e035693dc0 \
-file://blobmsg.c;endline=15;md5=7ed64c1570e8c9b46c4fc6fbd16c489e \
-file://list.h;endline=28;md5=2d5f5475fbd0f08741354c5a99c2e983 \
-file://md5.h;endline=39;md5=048bf9f68963c207a0c2b3a94c9d2aaa \
-file://md5.c;endline=51;md5=0a448eea0bcbc89e3c7e6608f2d119a0 \
-file://usock.h;endline=18;md5=f0dfdc8de858e66d66d74036611bba14 \
-"
-
-SRC_URI = "\
-git://git.openwrt.org/project/libubox.git \
-file://0001-version-libraries.patch \
-file://fix-libdir.patch \
-"
-
-SRCREV = "155bf39896f126b1ba121b816922a88dc34c31e3"
-PV = "1.0.1+git${SRCPV}"
-
-S = "${WORKDIR}/git"
-
-inherit cmake
-
-DEPENDS = 

[oe] Some experimental layers and conclusions

[cshored]

-Original Message-
From: Daniel Dickinson [mailto:csh...@thecshore.com] 
Sent: May 5, 2017 3:52 AM
To: 'openembedded-de...@lists.openembeeded.org' 

Subject: [oe] Some experimental layers and conclusions

Apologies if you get this twice; I got a bounce due to sending with wrong email 
address.

> -Original Message-
> From: Trevor Woerner [mailto:twoer...@gmail.com]
> Sent: April 27, 2017 9:06 AM
> To: csho...@cshore.thecshore.com
> Cc: Openembedded-devel@lists.openembedded.org
> Subject: Re: [oe] Some experimental layers and conclusions
>
> Hi Daniel,
>
> Very interesting report, thanks for the info!
>
> On Thu 2017-04-27 @ 02:46:24 AM, csho...@cshore.thecshore.com wrote:
> > * OE doesn't have good *router* networking support (i.e. nothing 
> > like OpenWrt/LEDE's netifd and friends for a headless system, that 
> > one can configure by editing a text file, or by using a WebUI for 
> > handling multiple interfaces and VLANs and bridged (or not) wireless 
> > and wired networks, with easy firewall configuration).
>
> I wonder Khem's if meta-openwrt could have helped here? It looks like 
> it has a recipe for netifd and friends:

I hadn't actually gotten to the point of needing to worry about the networking 
yet. I was trying to avoid procd because of too many hard-coded openwrtisms 
(assumptions about how the system should loo) in a niche C project, and systemd 
for being too large.  From what I saw in the changelog the meta-openwrt is not 
working yet, and my guess it has to do with a lot assumptions about how the 
system is set up that are not well documented, and are openwrt-specific (I have 
some knowledge of how this setup works, so I can make it work, but I'm not sure 
it's worth it).

The real showstoppers where the lack of kernel (especially wireless support) 
without getting into e.g. wireless development which I don't have facilities to 
do legally and hence is off the table.

>
>   https://layers.openembedded.org/layerindex/branch/master/layer/
> meta-openwrt/
>
> Out of curiosity, did you try using musl? You don't mention which C 
> library you're using. I'd be curious to know if musl can help with 
> size reduction.

Yes, using musl, that's part of how I managed to get the size down as far as I 
did without getting into major patches for debloating.

>
> Is toybox mature enough to be used in these situations?
>
>   http://layers.openembedded.org/layerindex/recipe/28902/
>

Last I checked (about three months ago) it is not (I've peeked at it from time 
to time, but there are some important things like POSIX shell and working dhcpc 
that would have to come from busybox or a larger traditional sources.

I'm not sure how much size difference toybox will make over busybox, although I 
am interested for other reasons.

The biggest size challenge compared to openwrt is that openwrt has a lot of 
custom stuf to cut things down, mostly by excluding not needed functionality, 
or as with netifd, odhcd, uhttpd, etc, by writing minimalist versions of things 
that are needed.

Regards,

Daniel

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] Some experimental layers and conclusions

[cshored]

Hi all,

I've done some prototyping of some ideas I was working on with OpenEmbedded,
what I learned from the efforts (which I'm posting here for the benefit of
someone who might be interested in this or similar concepts).

I was initially interested in OE as a possible replacement for OpenWrt/LEDE
on my router.  I quickly discovered there are some issue with that, however:

* OE doesn't have good *router* networking support (i.e. nothing like
OpenWrt/LEDE's netifd and friends for a headless system, that one can
configure by editing a text file, or by using a WebUI for handling multiple
interfaces and VLANs and bridged (or not) wireless and wired networks, with
easy firewall configuration).
* The routers (ar71xx) I was interested in have a lot of OpenWrt/LEDE
technical debt and have drivers and BSP that has never been upstreamed.
* OE's default build can quickly exceed 16MB flash, which is the larger of
the flash sizes on the devices I was interested in.

I started on the latter by creating a poky-tiny inspired distro which called
CShore Embedded Device -- CShorED (cshore is a nick I've been using for a
while).  That layer can be viewed at
https://layers.openembedded.org/layerindex/branch/master/layer/meta-cshored/
.  In the process I created meta-runit-init
https://layers.openembedded.org/layerindex/branch/master/layer/meta-runit-in
it/ (which uses busybox's runit/daemontools-style applets a the main init
system, because systemd was clearly too large for my use case and I wanted
something more resilient to daemon failure than sysvinit or busybox-init)
and meta-earlyinit
(https://layers.openembedded.org/layerindex/branch/master/layer/meta-earlyin
it/) which allows initramfs like pre-init setup when not using an initramfs
and also adds what I think is a lot better support for read-only-rootfs that
doesn't require special handling after earlyinit.

Oh and cshored uses squashfs-xz read-only-rootfs with the objective of
having an easy 'factory-reset' capbability, however it doesn't take the
overlay approach to the entire filesystem, but only overlays a subset of
files, and uses a lot of symlinks for data that is either volatile (not kept
across boots) or which is persistent (and with earlyinit has handling of
auto-setup of persistent storage).

I was successful with cshored in getting build sizes into potentially useful
range (~8 MB which my smaller devices have for flash) while still having
useful commands/capabilities, but it compared to OpenWrt/LEDE OE is always
going to be bigger.  The lack of device support got me looking at x86/Pi
etc, but I discovered that when going that route there are already a
significant number of good players who take advantage of the power and
usually available storage on x86 to create high-grade
routers/firewalls/gateways/VPN gateways/switches/etc, so not much point in
being a latecomer to that party (as a new entry).

runit-init was an interesting experiment but the ultimately systemd is much
better on systems that are large enough (which is even most embedded devices
these days), or procd for smaller devices (from OpenWrt/LEDE).  The problem
with run-it is that it doesn't have meaningful dependency support one ends
up with a lot attempting to start, fail and restart during the boot process
and a lot of delay while trying to figure out of the dependency was actually
up or just hasn't reported down yet.

Earlyinit seems to me to be the most useful of these, but I've heard systemd
is wanting to take over the boot process too, so I'm not sure that earlyinit
is a useful road to go down for further development.

If anyone has comments on the layers, or wishes to see further work on any
of them, please ping me, otherwise at this point I consider it feasibility
research that led to no-go conclusion.

Regards,

Daniel





-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] OpenEmbedded Layer Index autobuild errors

[cshored]

> -Original Message-
> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
> Sent: March 20, 2017 9:28 PM
> To: openembedded-devel@lists.openembedded.org
> Cc: Max Krummenacher ; Gary Thomas
> ; Daniel Dickinson 
> Subject: Re: [oe] OpenEmbedded Layer Index autobuild errors
> 
> On Monday, 20 March 2017 11:46:06 AM NZDT Paul Eggleton wrote:
> > On Monday, 20 March 2017 11:33:16 AM NZDT Paul Eggleton wrote:
> > > On Monday, 20 March 2017 10:51:46 AM NZDT Max Krummenacher
> wrote:
> > > > Am Sonntag, den 19.03.2017, 12:04 -0400 schrieb Daniel Dickinson:
> > > > > On Sun, 19 Mar 2017 15:39:38 +0100
> > > > >
> > > > > Gary Thomas  wrote:
> > > > > > > With that change all tools which must be installed on the
> > > > > > > host need to be present, even if in your use case some of
> > > > > > > them might not be used. Did you install the prerequisites?
> > > > > > > http://www.yoctoproject.org/docs/2.2.1/ref-manual/ref-manual
> > > > > > > .html#
> > > > > > > re
> > > > > > > qu
> > > > > > > ired-packages-for-the-ho st-dev elopment-system
> > > > > >
> > > > > > The real point is that it's not his host - it's the [remote]
> > > > > > autobuilder tool for OpenEmbedded (IIRC)
> > > > >
> > > > > Yes, thank you.  I'm not sure it's a full autobuilder or just
> > > > > parses recipes for generating the web pages, but either way it's
> > > > > not my host, it's an openembedded.org host.  Apparently I'm not
> > > > > good at explaining that...
> > > >
> > > > My bad, sorry.
> > > >
> > > > And it looks like the host fails to update any of the layers, e.g.
> > > > also
> > > > openembedded-core:
> > > > https://layers.openembedded.org/layerindex/layerupdate/323749/
> > > > Adding Paul, as he maybe knows how to get those tools onto the
> server.
> > >
> > > Ah yes - I think I may just take the cheap way out and clear
> > > HOSTTOOLS when parsing in the index - we're not doing any actual
> > > building, after all, so we're not going to be calling any of these
> > > tools).
> >
> > Well, perhaps I spoke too soon. We call gcc to check its version just
> > when parsing, I suspect there may be others, so maybe the safest thing
> > is to just install these tools. Things are rarely as simple as they
first appear...
> 
> FYI I have merged a patch for this, just waiting for it to be applied in
the OE
> infrastructure now.

Thank you; it's  been working since about March 28.  Now to prepare an
announcement / RFC message.

Regards,

Daniel

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel