From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 6974EE00709 for ; Sat, 5 Jan 2013 22:09:58 -0800 (PST) Received: from ALA-HCA.corp.ad.wrs.com (ala-hca.corp.ad.wrs.com [147.11.189.40]) by mail.windriver.com (8.14.5/8.14.3) with ESMTP id r0669vfq024429 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 5 Jan 2013 22:09:57 -0800 (PST) Received: from [128.224.158.164] (128.224.158.164) by ALA-HCA.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sat, 5 Jan 2013 22:09:56 -0800 Message-ID: <50E9154E.1040806@windriver.com> Date: Sun, 6 Jan 2013 14:10:22 +0800 From: Lei Yang User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Bruce Ashfield References: <1357393406-11707-1-git-send-email-lei.yang@windriver.com> <50E830EF.6030102@gmail.com> <50E83CC7.60608@enea.com> <0BF1DE0F-6CAD-4128-811E-EB9C6BBD1566@gmail.com> <50E8DB6D.6010806@windriver.com> In-Reply-To: X-Originating-IP: [128.224.158.164] X-Mailman-Approved-At: Sun, 06 Jan 2013 03:28:19 -0800 Cc: "meta-virtualization@yoctoproject.org" Subject: Re: [PATCH] Update the netcat with debian patches to fix some error X-BeenThere: meta-virtualization@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: lei.yang@windriver.com List-Id: "Discussion of layer enabling hypervisor, virtualization tool stack, and cloud support" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 06:09:58 -0000 Content-Type: multipart/alternative; boundary="------------070404050108080406070508" --------------070404050108080406070508 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit On 01/06/2013 11:37 AM, Bruce Ashfield wrote: > > > > On Sat, Jan 5, 2013 at 10:00 PM, Bruce Ashfield > > wrote: > > > > > On Sat, Jan 5, 2013 at 9:03 PM, Lei Yang > wrote: > > On 01/06/2013 08:53 AM, Bruce Ashfield wrote: >> >> >> >> On Sat, Jan 5, 2013 at 7:28 PM, Lei Yang >> > 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 >> >> Sent from my iPhone >> >> On 2013-1-6, at 2:44, Bruce Ashfield >> > > wrote: >> >>> >>> >>> >>> On Sat, Jan 5, 2013 at 9:46 AM, David Nyström >>> > >>> wrote: >>> >>> >>> >>> On 01/05/2013 03:26 PM, lei yang wrote: >>> >>> On Sat, Jan 5, 2013 at 5:55 AM, David Nyström >>> >> > wrote: >>> >>> On 01/05/2013 02:43 PM, >>> lei.yang@windriver.com >>> wrote: >>> >>> >>> From: Lei Yang >> > >>> >>> 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 >>> >> > >>> --- >>> >>> >>> >>> [snip] >>> >>> >>> +do_compile() { >>> + cd ${S} >>> + while read line; do patch -p1 >>> >> >> >>> >>> >>> 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" --------------070404050108080406070508 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit 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:




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"

--------------070404050108080406070508--