On 01/06/2013 11:37 AM, Bruce Ashfield wrote:



On Sat, Jan 5, 2013 at 10:00 PM, Bruce Ashfield <bruce.ashfield@gmail.com> wrote:



On Sat, Jan 5, 2013 at 9:03 PM, Lei Yang <lei.yang@windriver.com> wrote:
On 01/06/2013 08:53 AM, Bruce Ashfield wrote:



On Sat, Jan 5, 2013 at 7:28 PM, Lei Yang <yanglei.fage@gmail.com> wrote:
Hi Bruce 

I checked the netcat with my phone in meta-networking ,It's not the bsd netcat,in libvirt or my vert-test,we need to use bsd netcat,they are different source.

That was understood, and what I meant by:

"If there are any specific meta-virt requirements for netcat, we should either use bbappends (and
depend on meta-networking, or use the combo-layer tools to pull the support directly) or better yet
get them merged into meta-networking."

The solution is not to carry a similar netcat in meta-virt, but to have a single netcat source, which
is meta-virtualization.


I don't know I catch you or not

solution 1:
=======


create a bbappend in meta-virt. there are two issue
a. they have different licence, one is GPLv2 aother is BSD-3-Clause, I don't know if we are allowed to overwritte the LICENSE
b. and they have different PV history, one is 0.71, another is 0.89, so this can't be append

soulution 2:
========


seems you want something like this in meta-networing
[lyang0@ala-lpggp2 netcat]$ ls
netcat_0.7.1.bb    netcat-openbsd_1.89.bb netcat.inc

netcat.inc is something like,below other part(DESCRIPTION HOMEPAGE license SRC_URI) ...will be in there bb file, seems what they can share is little.

inherit autotools update-alternatives gettext

do_install_append() {
        mv ${D}${bindir}/nc ${D}${bindir}/nc.${PN}
}

ALTERNATIVE_${PN} = "nc"
ALTERNATIVE_PRIORITY = "100"

It's solution #2 that would be preferable. Since meta-networking is the provider of the current
netcat in the set of yocto layers, it makes sense to not expend time and effort supporting an
alternative in meta-virt, but to move the variant that is required into meta-networking.

It would be even better to break the requirement completely (by changing the tools that have
the BSP specific requirement). I haven't dug into it yet, is it arguments/syntax, or purely a 
licensing issue that creates the requirement ? Given your patch, I think it's the former, but
as I said, I haven't gone to look yet.

.. but breaking the dependency is much easier to say, than to do :)

The combo layer tools could come into play after we've got the BSD netcat support in 
meta-networking, and for some reason we can't depend on meta-networking and only need
the one package. The combo tools can pull that support of our meta-networking and place
it in meta-virt .. in a maintainable way.

And in case you haven't found it yet:

https://wiki.yoctoproject.org/wiki/Combo-layer



Thanks to point this, I'm trying to learn it, I find if the meta-virtuallization is a repo it will init fail. or I miss something

lyang0@pek-lpgtest1:/buildarea1/lyang0/examples/meta-virtualization$ ~/combo-layer init -c conf/combo-layer.conf
[13:59:16] Repository already initialised, nothing to do.
lyang0@pek-lpgtest1:/buildarea1/lyang0/examples/meta-virtualization$ cat conf/combo-layer.conf
[meta-networking]
src_uri = git://github.com/openembedded/meta-oe.git
local_repo_dir = /buildarea1/lyang0/examples/meta-oe/meta-networking
dest_dir = /buildarea1/lyang0/examples/meta-virtualization
last_revision =
file_filter = recipes-support/netcat/netcat_0.7.1.bb

It seems the combo-layer is for user. if so, how user know this layer depend on another layer's bb?  or put a readme in this layer.

Lei


Cheers,

Bruce
 

Cheers,

Bruce



By the way I don't know what is combo-layer tools

Lei






There's no rush to merge this, there's no impending releases, so we should take our time and
unify the support, not create a very similar structure in meta-virt.

Cheers,

Bruce

 

Lei


On 2013-1-6, at 2:44, Bruce Ashfield <bruce.ashfield@gmail.com> wrote:




On Sat, Jan 5, 2013 at 9:46 AM, David Nyström <david.nystrom@enea.com> wrote:


On 01/05/2013 03:26 PM, lei yang wrote:
On Sat, Jan 5, 2013 at 5:55 AM, David Nyström <david.c.nystrom@gmail.com> wrote:
On 01/05/2013 02:43 PM, lei.yang@windriver.com wrote:

From: Lei Yang <lei.yang@windriver.com>

I know we have the patches in debian dir in the previous version,
but I meet lots of patch error.so I change it to debian.org version

The background I do this change is:
I'm a kvm tester,without patches it will meet error when I do the migrate
testing with  -incoming "exec:nc -l 5200" it meets error:
"nc: Protocol no available."

You can reproduce it simplely with "nc -l 5200" on your board

Lei

Signed-off-by: Lei Yang <lei.yang@windriver.com>
---


[snip]


+do_compile() {
+       cd ${S}
+        while read line; do patch -p1 <debian/patches/$line; done
<debian/patches/series


Is this line really needed ?
I cant seem to find any file called debian/patches/* in ${S}.


Yes it needed, http://ftp.debian.org/debian/pool/main/n/netcat-openbsd/netcat-openbsd_1.89-4.diff.gz
will be download, and gunzip by bitbake automaticlly, then it find
.diff (or patch) it will automatically apply(before I thought only
.patch will be applied, now I find .diff will be applied ) then you
will see the debian/patches dir  created by .dff

logs:
lyang0@pek-lpgtest1:/buildarea1/lyang0/kvm_rr$ ls
build/netcat-openbsd-1.89-r0/netcat-openbsd-1.89.orig/
atomicio.c      atomicio.o      Makefile        nc.1
netcat.c.orig   openbsd-compat/ .pc/            socks.o
atomicio.h      debian/         nc              netcat.c
netcat.o        patches/        socks.c



+       pkgrel=4
+       oe_runmake CFLAGS="$CFLAGS -DDEBIAN_VERSION=\"\\\"${pkgrel}\\\"\""


I assume this has been tested with package_rpm as well.



Yes, I'm a tester .welcome any testing work to let me do freely

lyang0@pek-lpgtest1:/buildarea1/lyang0/kvm_rr$ cat
build/netcat-openbsd-1.89-r0/deploy-rpms/x86_64/netcat-openbsd-
netcat-openbsd-1.89-r0.x86_64.rpm
netcat-openbsd-dbg-1.89-r0.x86_64.rpm
netcat-openbsd-dev-1.89-r0.x86_64.rpm


Thanks Lei,
I'll merge this as soon as I can, I seem to be unable to push at the moment. I'll try to resolv this asap.



I think we should hold on this merge completely. netcat is already covered by meta-networking, so
we should be consolidating patches and support there.

If there are any specific meta-virt requirements for netcat, we should either use bbappends (and
depend on meta-networking, or use the combo-layer tools to pull the support directly) or better yet
get them merged into meta-networking.

Cheers,

Bruce
 



+}
+
+do_install() {
+       install -d ${D}${bindir}
+       install -m 755 ${S}/nc ${D}${bindir}/nc.${BPN}
+}
+
+ALTERNATIVE_${PN} = "nc"
+ALTERNATIVE_PRIORITY = "101"
+
+BBCLASSEXTEND = "nativesdk"
diff --git a/recipes-networking/netcat/openbsd-netcat_1.6.bb
b/recipes-networking/netcat/openbsd-netcat_1.6.bb
deleted file mode 100644
index 1ae3f37..0000000
--- a/recipes-networking/netcat/openbsd-netcat_1.6.bb
+++ /dev/null
@@ -1,29 +0,0 @@
-DESCRIPTION = "OpenBSD Netcat"
-HOMEPAGE = "http://code.google.com/p/openbsd-netcat/"
-SECTION = "console/network"
-LICENSE = "BSD-3-Clause"
-PR = "r0"
-
-SRCREV = "5"
-
-SRC_URI =
"svn://openbsd-netcat.googlecode.com/svn;module=trunk;protocol=http"
-S = "${WORKDIR}/trunk"
-
-inherit update-alternatives gettext
-
-do_configure[noexec] = "1"
-
-do_compile() {
-       cd ${S}
-       oe_runmake
-}
-
-do_install() {
-       install -d ${D}${bindir}
-       install -m 755 ${S}/nc ${D}${bindir}/nc.${BPN}
-}
-
-ALTERNATIVE_${PN} = "nc"
-ALTERNATIVE_PRIORITY = "101"
-
-BBCLASSEXTEND = "nativesdk"


_______________________________________________
meta-virtualization mailing list
meta-virtualization@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-virtualization
_______________________________________________
meta-virtualization mailing list
meta-virtualization@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-virtualization

_______________________________________________
meta-virtualization mailing list
meta-virtualization@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-virtualization



--
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"



--
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" 


_______________________________________________
meta-virtualization mailing list
meta-virtualization@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-virtualization




--
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"



--
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"