Re: [yocto] something about gtk+-2.24.8.tar.bz2 that requires constant downloading?
Khem Raj wrote on 2012-06-05:
> On Mon, Jun 4, 2012 at 10:04 PM, Wang, Shane
> wrote:
>> Yeah, Robert,
>>
>> You found a bug in bitbake. In the fetch code, local directory
>> /home/rpjday/dl/gtk+-2.24.8.tar.bz2 is decoded as
>> /home/rpjday/dl/gtk%2B-2.24.8.tar.bz2 by newuri = uri_replace(origud,
>> find, replace, ld), which is line 480 in lib/bb/fetch2/__init__.py. And
>> later on it is checked whether or not existed by if not
>> os.path.exists(newpath) and path.find("*") == -1:, which is line 61 in
>> lib/bb/fetch2/local.py.
>>
>> Actually the directory /home/rpjday/dl/gtk+-2.24.8.tar.bz2 is there, but
> /home/rpjday/dl/gtk%2B-2.24.8.tar.bz2 can't be found by bitbake code. That
> is the problem. Therefore, Gtk+ shouldn't be decoded as gtk%2B.
>>
>> I am not familiar with the whole fetch code and hope someone else can
> correct it, so can you please file a bug first?
>
> its probably due to use of urllib.unquote in decodeurl and not keeping
> the unquoted name for subsequent use
>>
>> --
>> Shane
Correct.
--
Shane
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Broken SDK
Hi,
Thanks for support. I successfully created SDK with this modification. I
installed the same SDK and tried compiling Qt application, but got error
mentioning
"Failure to read QMAKESPEC conf file
/opt/poky/1.0/sysroots/arm-poky-linux-gnueabi/usr/share/qtopia/mkspecs/linux-gnueabi-oe-g++/qmake.conf/qmake.conf.
Error processing project file: /home/Qt/hello/hello.pro"
I had exported path of QMAKESPEC to
/opt/poky/1.0/sysroots/arm-poky-linux-gnueabi/usr/share/qtopia/mkspecs/linux-gnueabi-oe-g++/qmake.conf
Any idea why I am ending up with this error ? Any reply is appreciable.
Thanks
Navani
On Wed, May 30, 2012 at 12:36 AM, Khem Raj wrote:
> On Tue, May 29, 2012 at 2:03 AM, Navani Srivastava
> wrote:
> >
> > "ln -s
> > /opt/poky/1.0/sysroots/arm-poky-linux-gnueabi/usr/share/qtopia/mkspecs
> > mkspecs
> > | ln: creating symbolic link `mkspecs': File exists"
> >
>
> as it says it seems file is there already. So make sure the preexisting
> file
> is correct if so then you can check first if file exists before creating
> symlink
> if the file is incorrect then just use ln -sf to create the symlink
>
> > On commenting out
> > "(cd ${SDK_OUTPUT}/${QT_TOOLS_PREFIX}/..; ln -s
> > ${SDKTARGETSYSROOT}/usr/share/qtopia/mkspecs mkspecs;)"
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] something about gtk+-2.24.8.tar.bz2 that requires constant downloading?
On Tue, 5 Jun 2012, Wang, Shane wrote:
>
> Khem Raj wrote on 2012-06-05:
>
> > On Mon, Jun 4, 2012 at 10:04 PM, Wang, Shane
> > wrote:
> >> Yeah, Robert,
> >>
> >> You found a bug in bitbake. In the fetch code, local directory
> >> /home/rpjday/dl/gtk+-2.24.8.tar.bz2 is decoded as
> >> /home/rpjday/dl/gtk%2B-2.24.8.tar.bz2 by newuri = uri_replace(origud,
> >> find, replace, ld), which is line 480 in lib/bb/fetch2/__init__.py. And
> >> later on it is checked whether or not existed by if not
> >> os.path.exists(newpath) and path.find("*") == -1:, which is line 61 in
> >> lib/bb/fetch2/local.py.
> >>
> >> Actually the directory /home/rpjday/dl/gtk+-2.24.8.tar.bz2 is there, but
> > /home/rpjday/dl/gtk%2B-2.24.8.tar.bz2 can't be found by bitbake code. That
> > is the problem. Therefore, Gtk+ shouldn't be decoded as gtk%2B.
> >>
> >> I am not familiar with the whole fetch code and hope someone else can
> > correct it, so can you please file a bug first?
> >
> > its probably due to use of urllib.unquote in decodeurl and not keeping
> > the unquoted name for subsequent use
> >>
> >> --
> >> Shane
>
> Correct.
at this point, has the problem been identified? or does this still
require a bugzilla submission? it would appear that the issue
involves any package with a "+" in the package name which, for now,
appears to be just that gtk+ package. would any other special
characters trigger this? that's the only package i've tripped over
that caused this behaviour.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] something about gtk+-2.24.8.tar.bz2 that requires constant downloading?
Robert P. J. Day wrote on 2012-06-05: > at this point, has the problem been identified? or does this still > require a bugzilla submission? it would appear that the issue > involves any package with a "+" in the package name which, for now, > appears to be just that gtk+ package. would any other special > characters trigger this? that's the only package i've tripped over > that caused this behaviour. > > rday > Yes, it has been identified. If you can't submit a bug, I can do. Yes, I believe other special characters will trigger that. Just because I am not familiar with all fetch code, I can fix it for gtk+ now but I am not sure whether that fix will bring any regression bugs. Give me more time. -- Shane ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] something about gtk+-2.24.8.tar.bz2 that requires constant downloading?
On Tue, 5 Jun 2012, Wang, Shane wrote: > Robert P. J. Day wrote on 2012-06-05: > > at this point, has the problem been identified? or does this still > > require a bugzilla submission? it would appear that the issue > > involves any package with a "+" in the package name which, for now, > > appears to be just that gtk+ package. would any other special > > characters trigger this? that's the only package i've tripped over > > that caused this behaviour. > > > > rday > > > > Yes, it has been identified. If you can't submit a bug, I can do. > Yes, I believe other special characters will trigger that. > > Just because I am not familiar with all fetch code, I can fix it for > gtk+ now but I am not sure whether that fix will bring any > regression bugs. Give me more time. ok, i'll leave it in your capable hands and go find something else to nitpick. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [RFC] Split and revamp distro_tracking_fields.inc
On 6/3/12 10:14 PM, Saul Wold wrote: Folks, As this project has progressed, we have found the distro_tracking_fields to become a bit cumbersome and dated, I want to therefore propose we get rid of it ;-), nah that would be too easy! I would like to propose the following, split it into smaller files with more specific meaning, and move some of the data contained in the original file into the recipes directly. Some of the fields will be deprecated, others renamed and finally others will be used for a burn down list of things to be checked or converted to be automagically generated. Currently the data contained in these fields is used to generate the database that the Package reporting system uses and will continue to use in it's new form. (https://packages.yoctoproject.org) We also use the data for tracking the recipe updating to ensure we keep the system as up to date as possible. The new split would make this data part of Poky in meta-yocto, and not in oe-core (other than the modifications to the recipes). The split would be as follows: maintainers.inc - RECIPE_MAINTAINER = "Full Name" - This is the name of the person currently watching the upstream and updating the recipe and/or fixing bugs filed against, this person should also help review incoming patches for that recipe. - NOTE to REVIEWERS: I still need to better define what the Roles and Responsibilities of a maintainer are for recipes! recipe_color.inc - RECIPE_COLOR = "green|yellow|red" - defaults to green - Burn down list of recipes that need to be checked for general issues - red means there are some issues that might be legacy or function need review - yellow means recipe needs review - once reviewed and issues resolved the recipe's entry can be removed upstream_tracking.inc - RECIPE_UPSTREAM_VERSION = "" - RECIPE_UPSTREAM_DATE = "Mmm, dd, " - Version info from the Upstream, mostly this can be generated, but in some cases we need to track it manually, this should just be the manually tracked info, it currently contains more than that, this will be corrected over time as we can generate it automatically - RECIPE_NO_UPDATE_REASON = "Free form text" - Used by the package and update tracking to explain why a recipe should not be updated. No real comments on the above.. I think that is all fine. Insert into recipe.bb or .inc files: My biggest concern with this is that any fields only get updated when the recipe itself is changed in some way... package uprev or modification. Arbitrary changes to the fields will cause checksums (file and otherwise) to invalidate causing reparsing and possibly even package rebuilds. Both of which take additional time - NOTES = - was RECIPE_COMMENTS - Information that would useful in the package reporting system, but not part of the DESCRIPTION, could be existing comments Right now anything tricky with an uprev or comments about why it was done a certain way are generally stored as comments in the recipe. Formalizing it would be nice. Only concern with this is the word "NOTES" seems awfully generic. - CHECK_DATE = "Mmm, dd, " - was RECIPE_MANUAL_CHECK_DATE - The date when the upstream was last checked, specifically for the Manual check process when a recipe's upstream could not be checked automagically, this should become fewer and fewer as we determine ways to check. This is a primary concern. If this is updated each time someone checks the recipes are still current and don't need modifications -- we're forcing a modification into the system. One alternative approach: Document the date when the recipe was upreved. Then in a separate file, document the check dates. Then the check dates and the uprev dates can be compared and it'll be easier to watch to see if things are being neglected or let go out of date. (Note, using git, it should be possible to also discover the data of the uprev as well) - DISTRO_PN_ALIAS = "Distro:package alias, Distro:package alias, ..." - This is a comma separated list of mainline distros, such as Fedora, Debian, OpenSuse which also ship a similar package, but with a different name possibly. - Used by package reporting system and is fairly static - Many Commercial users would like to know that a given package is already shipping with other distributions I've not seen this requirement from any of my customers. I can understand the uses of this -- how widely used is this? if it's not, then chances are there may be licensing or functional issues with the component... But I'm not sure if this is useful, or if the OE-core contributors would want the additional work involved. Any fields not mentioned above will be deprecated. The first three files are ready to merged, I need to finish updating the recipes for the last part. This will n
Re: [yocto] [PATCH] fix the build issue of ppp
On 04/06/12 20:32, b19...@freescale.com wrote:
From: Zhenhua Luo
this patch is for edison branch of poky
fix following build issue of ppp:
make[2]: Entering directory
`/local/home/b19537/workspace/sdk-devel/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/ppp-2.4.5-r2/ppp-2.4.5/pppd/plugins/rp-pppoe'
powerpc-fsl-linux-gcc -m32 -mhard-float -mcpu=e500mc -Wl,-O1
-Wl,--hash-style=gnu -Wl,--as-needed
--sysroot=/local/home/b19537/workspace/sdk-devel/build_p4080ds_release/tmp/sysroots/p4080ds
-O2 -g -I../../../include '-DRP_VERSION="3.8p"' -I../../.. -c -o plugin.o
-fPIC plugin.c
In file included from plugin.c:53:0:
/local/home/b19537/workspace/sdk-devel/build_p4080ds_release/tmp/sysroots/p4080ds/usr/include/linux/if_pppox.h:85:25:
error: field 'pppol2tp' has incomplete type
make[2]: *** [plugin.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: Leaving directory
`/local/home/b19537/workspace/sdk-devel/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/ppp-2.4.5-r2/ppp-2.4.5/pppd/plugins/rp-pppoe'
PPP builds fine here, can you share some more information such as what
causes the issue and where this patch has been tested?
Further, there's no header on the patch. Please see the guidelines at:
https://wiki.yoctoproject.org/wiki/Contribution_Guidelines
Cheers,
Joshua
Signed-off-by: Zhenhua Luo
---
.../ppp-fix-build-issue-of-rp-pppoe.so.patch | 23
meta/recipes-connectivity/ppp/ppp_2.4.5.bb |3 +-
2 files changed, 25 insertions(+), 1 deletions(-)
create mode 100644
meta/recipes-connectivity/ppp/ppp-2.4.5/ppp-fix-build-issue-of-rp-pppoe.so.patch
diff --git
a/meta/recipes-connectivity/ppp/ppp-2.4.5/ppp-fix-build-issue-of-rp-pppoe.so.patch
b/meta/recipes-connectivity/ppp/ppp-2.4.5/ppp-fix-build-issue-of-rp-pppoe.so.patch
new file mode 100644
index 000..ed2141a
--- /dev/null
+++
b/meta/recipes-connectivity/ppp/ppp-2.4.5/ppp-fix-build-issue-of-rp-pppoe.so.patch
@@ -0,0 +1,23 @@
+--- a/include/linux/if_pppol2tp.h 2012-06-04 04:22:37.966729643 -0500
b/include/linux/if_pppol2tp.h 2012-06-04 04:31:04.325905458 -0500
+@@ -32,6 +32,20 @@
+ __u16 d_tunnel, d_session; /* For sending outgoing packets */
+ };
+
++/* The L2TPv3 protocol changes tunnel and session ids from 16 to 32
++ * bits. So we need a different sockaddr structure.
++ */
++struct pppol2tpv3_addr {
++ pid_t pid;/* pid that owns the fd.
++* 0 => current */
++ int fd; /* FD of UDP or IP socket to use */
++
++ struct sockaddr_in addr;/* IP address and port to send to */
++
++ __u32 s_tunnel, s_session; /* For matching incoming packets */
++ __u32 d_tunnel, d_session; /* For sending outgoing packets */
++};
++
+ /* Socket options:
+ * DEBUG - bitmask of debug message categories
+ * SENDSEQ- 0 => don't send packets with sequence numbers
diff --git a/meta/recipes-connectivity/ppp/ppp_2.4.5.bb
b/meta/recipes-connectivity/ppp/ppp_2.4.5.bb
index 72464bf..6c4bd08 100644
--- a/meta/recipes-connectivity/ppp/ppp_2.4.5.bb
+++ b/meta/recipes-connectivity/ppp/ppp_2.4.5.bb
@@ -10,7 +10,7 @@ LIC_FILES_CHKSUM =
"file://pppd/ccp.c;beginline=1;endline=29;md5=e2c43fe6e81ff77
file://pppd/plugins/passprompt.c;beginline=1;endline=10;md5=3bcbcdbf0e369c9a3e0b8c8275b065d8
\
file://pppd/tdb.c;beginline=1;endline=27;md5=4ca3a9991b011038d085d6675ae7c4e6 \
file://chat/chat.c;beginline=1;endline=15;md5=0d374b8545ee5c62d7aff1acbd38add2"
-PR = "r2"
+PR = "r3"
SRC_URI = "http://ppp.samba.org/ftp/ppp/ppp-${PV}.tar.gz \
file://makefile.patch \
@@ -18,6 +18,7 @@ SRC_URI = "http://ppp.samba.org/ftp/ppp/ppp-${PV}.tar.gz \
file://pppd-resolv-varrun.patch \
file://enable-ipv6.patch \
file://makefile-remove-hard-usr-reference.patch \
+ file://ppp-fix-build-issue-of-rp-pppoe.so.patch \
file://pon \
file://poff \
file://init \
--
Joshua Lock
Yocto Project
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] fix the build issue of ppp
On Tue, Jun 5, 2012 at 11:59 AM, Joshua Lock wrote:
> On 04/06/12 20:32, b19...@freescale.com wrote:
>>
>> From: Zhenhua Luo
>>
>> this patch is for edison branch of poky
>>
>> fix following build issue of ppp:
>> make[2]: Entering directory
>> `/local/home/b19537/workspace/sdk-devel/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/ppp-2.4.5-r2/ppp-2.4.5/pppd/plugins/rp-pppoe'
>> powerpc-fsl-linux-gcc -m32 -mhard-float -mcpu=e500mc -Wl,-O1
>> -Wl,--hash-style=gnu -Wl,--as-needed
>> --sysroot=/local/home/b19537/workspace/sdk-devel/build_p4080ds_release/tmp/sysroots/p4080ds
>> -O2 -g -I../../../include '-DRP_VERSION="3.8p"' -I../../.. -c -o plugin.o
>> -fPIC plugin.c
>> In file included from plugin.c:53:0:
>>
>> /local/home/b19537/workspace/sdk-devel/build_p4080ds_release/tmp/sysroots/p4080ds/usr/include/linux/if_pppox.h:85:25:
>> error: field 'pppol2tp' has incomplete type
>> make[2]: *** [plugin.o] Error 1
>> make[2]: *** Waiting for unfinished jobs
>> make[2]: Leaving directory
>> `/local/home/b19537/workspace/sdk-devel/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/ppp-2.4.5-r2/ppp-2.4.5/pppd/plugins/rp-pppoe'
>
>
> PPP builds fine here, can you share some more information such as what
> causes the issue and where this patch has been tested?
>
Did you build it for ppc ?
ppc captures its own version of linux/if_pppol2tp.h and if this is not in sync
with kernel bad things can happen on different architectures. I think in case
of ppc here some reference is coming in and including this file instead of the
one from kernel-headers for ppc but not for may be x86. This patch is safe
but it would be better if whole capturing of this file can be avoided.
> Further, there's no header on the patch. Please see the guidelines at:
>
> https://wiki.yoctoproject.org/wiki/Contribution_Guidelines
>
yes thats needed for better patch management
> Cheers,
> Joshua
>
>
>>
>> Signed-off-by: Zhenhua Luo
>> ---
>> .../ppp-fix-build-issue-of-rp-pppoe.so.patch | 23
>>
>> meta/recipes-connectivity/ppp/ppp_2.4.5.bb | 3 +-
>> 2 files changed, 25 insertions(+), 1 deletions(-)
>> create mode 100644
>> meta/recipes-connectivity/ppp/ppp-2.4.5/ppp-fix-build-issue-of-rp-pppoe.so.patch
>>
>> diff --git
>> a/meta/recipes-connectivity/ppp/ppp-2.4.5/ppp-fix-build-issue-of-rp-pppoe.so.patch
>> b/meta/recipes-connectivity/ppp/ppp-2.4.5/ppp-fix-build-issue-of-rp-pppoe.so.patch
>> new file mode 100644
>> index 000..ed2141a
>> --- /dev/null
>> +++
>> b/meta/recipes-connectivity/ppp/ppp-2.4.5/ppp-fix-build-issue-of-rp-pppoe.so.patch
>> @@ -0,0 +1,23 @@
>> +--- a/include/linux/if_pppol2tp.h 2012-06-04 04:22:37.966729643
>> -0500
>> b/include/linux/if_pppol2tp.h 2012-06-04 04:31:04.325905458
>> -0500
>> +@@ -32,6 +32,20 @@
>> + __u16 d_tunnel, d_session; /* For sending outgoing packets */
>> + };
>> +
>> ++/* The L2TPv3 protocol changes tunnel and session ids from 16 to 32
>> ++ * bits. So we need a different sockaddr structure.
>> ++ */
>> ++struct pppol2tpv3_addr {
>> ++ pid_t pid; /* pid that owns the fd.
>> ++ * 0 => current */
>> ++ int fd; /* FD of UDP or IP socket to use
>> */
>> ++
>> ++ struct sockaddr_in addr; /* IP address and port to send to
>> */
>> ++
>> ++ __u32 s_tunnel, s_session; /* For matching incoming packets
>> */
>> ++ __u32 d_tunnel, d_session; /* For sending outgoing packets
>> */
>> ++};
>> ++
>> + /* Socket options:
>> + * DEBUG - bitmask of debug message categories
>> + * SENDSEQ - 0 => don't send packets with sequence numbers
>> diff --git a/meta/recipes-connectivity/ppp/ppp_2.4.5.bb
>> b/meta/recipes-connectivity/ppp/ppp_2.4.5.bb
>> index 72464bf..6c4bd08 100644
>> --- a/meta/recipes-connectivity/ppp/ppp_2.4.5.bb
>> +++ b/meta/recipes-connectivity/ppp/ppp_2.4.5.bb
>> @@ -10,7 +10,7 @@ LIC_FILES_CHKSUM =
>> "file://pppd/ccp.c;beginline=1;endline=29;md5=e2c43fe6e81ff77
>>
>> file://pppd/plugins/passprompt.c;beginline=1;endline=10;md5=3bcbcdbf0e369c9a3e0b8c8275b065d8
>> \
>>
>> file://pppd/tdb.c;beginline=1;endline=27;md5=4ca3a9991b011038d085d6675ae7c4e6
>> \
>>
>> file://chat/chat.c;beginline=1;endline=15;md5=0d374b8545ee5c62d7aff1acbd38add2"
>> -PR = "r2"
>> +PR = "r3"
>>
>> SRC_URI = "http://ppp.samba.org/ftp/ppp/ppp-${PV}.tar.gz \
>> file://makefile.patch \
>> @@ -18,6 +18,7 @@ SRC_URI = "http://ppp.samba.org/ftp/ppp/ppp-${PV}.tar.gz
>> \
>> file://pppd-resolv-varrun.patch \
>> file://enable-ipv6.patch \
>> file://makefile-remove-hard-usr-reference.patch \
>> + file://ppp-fix-build-issue-of-rp-pppoe.so.patch \
>> file://pon \
>> file://poff \
>> file://init \
>
>
> --
> Joshua Lock
> Yocto Project
> Intel Open Source Technology
Re: [yocto] [PATCH] fix the build issue of ppp
On 05/06/12 12:17, Khem Raj wrote:
On Tue, Jun 5, 2012 at 11:59 AM, Joshua Lock wrote:
On 04/06/12 20:32, b19...@freescale.com wrote:
From: Zhenhua Luo
this patch is for edison branch of poky
fix following build issue of ppp:
make[2]: Entering directory
`/local/home/b19537/workspace/sdk-devel/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/ppp-2.4.5-r2/ppp-2.4.5/pppd/plugins/rp-pppoe'
powerpc-fsl-linux-gcc -m32 -mhard-float -mcpu=e500mc -Wl,-O1
-Wl,--hash-style=gnu -Wl,--as-needed
--sysroot=/local/home/b19537/workspace/sdk-devel/build_p4080ds_release/tmp/sysroots/p4080ds
-O2 -g -I../../../include '-DRP_VERSION="3.8p"' -I../../.. -c -o plugin.o
-fPIC plugin.c
In file included from plugin.c:53:0:
/local/home/b19537/workspace/sdk-devel/build_p4080ds_release/tmp/sysroots/p4080ds/usr/include/linux/if_pppox.h:85:25:
error: field 'pppol2tp' has incomplete type
make[2]: *** [plugin.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: Leaving directory
`/local/home/b19537/workspace/sdk-devel/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/ppp-2.4.5-r2/ppp-2.4.5/pppd/plugins/rp-pppoe'
PPP builds fine here, can you share some more information such as what
causes the issue and where this patch has been tested?
Did you build it for ppc ?
I did, yes.
ppc captures its own version of linux/if_pppol2tp.h and if this is not in sync
with kernel bad things can happen on different architectures. I think in case
of ppc here some reference is coming in and including this file instead of the
one from kernel-headers for ppc but not for may be x86. This patch is safe
but it would be better if whole capturing of this file can be avoided.
That was my assumption but with very little information provided I'm
reluctant to take the patch.
For example if the kernel with which the issue was triggered is provided
by a separate layer it seems like this patch belongs in a bbappend in
the same layer, no?
If I can build for qemu machines without this patch will not the
application of the patch have a negative effect?
Sure, I can likely answer each of these questions myself if I spend some
CPU cycles running builds but
Further, there's no header on the patch. Please see the guidelines at:
https://wiki.yoctoproject.org/wiki/Contribution_Guidelines
yes thats needed for better patch management
Cheers,
Joshua
Signed-off-by: Zhenhua Luo
---
.../ppp-fix-build-issue-of-rp-pppoe.so.patch | 23
meta/recipes-connectivity/ppp/ppp_2.4.5.bb |3 +-
2 files changed, 25 insertions(+), 1 deletions(-)
create mode 100644
meta/recipes-connectivity/ppp/ppp-2.4.5/ppp-fix-build-issue-of-rp-pppoe.so.patch
diff --git
a/meta/recipes-connectivity/ppp/ppp-2.4.5/ppp-fix-build-issue-of-rp-pppoe.so.patch
b/meta/recipes-connectivity/ppp/ppp-2.4.5/ppp-fix-build-issue-of-rp-pppoe.so.patch
new file mode 100644
index 000..ed2141a
--- /dev/null
+++
b/meta/recipes-connectivity/ppp/ppp-2.4.5/ppp-fix-build-issue-of-rp-pppoe.so.patch
@@ -0,0 +1,23 @@
+--- a/include/linux/if_pppol2tp.h 2012-06-04 04:22:37.966729643
-0500
b/include/linux/if_pppol2tp.h 2012-06-04 04:31:04.325905458
-0500
+@@ -32,6 +32,20 @@
+ __u16 d_tunnel, d_session; /* For sending outgoing packets */
+ };
+
++/* The L2TPv3 protocol changes tunnel and session ids from 16 to 32
++ * bits. So we need a different sockaddr structure.
++ */
++struct pppol2tpv3_addr {
++ pid_t pid;/* pid that owns the fd.
++* 0 =>current */
++ int fd; /* FD of UDP or IP socket to use
*/
++
++ struct sockaddr_in addr;/* IP address and port to send to
*/
++
++ __u32 s_tunnel, s_session; /* For matching incoming packets
*/
++ __u32 d_tunnel, d_session; /* For sending outgoing packets
*/
++};
++
+ /* Socket options:
+ * DEBUG - bitmask of debug message categories
+ * SENDSEQ- 0 =>don't send packets with sequence numbers
diff --git a/meta/recipes-connectivity/ppp/ppp_2.4.5.bb
b/meta/recipes-connectivity/ppp/ppp_2.4.5.bb
index 72464bf..6c4bd08 100644
--- a/meta/recipes-connectivity/ppp/ppp_2.4.5.bb
+++ b/meta/recipes-connectivity/ppp/ppp_2.4.5.bb
@@ -10,7 +10,7 @@ LIC_FILES_CHKSUM =
"file://pppd/ccp.c;beginline=1;endline=29;md5=e2c43fe6e81ff77
file://pppd/plugins/passprompt.c;beginline=1;endline=10;md5=3bcbcdbf0e369c9a3e0b8c8275b065d8
\
file://pppd/tdb.c;beginline=1;endline=27;md5=4ca3a9991b011038d085d6675ae7c4e6
\
file://chat/chat.c;beginline=1;endline=15;md5=0d374b8545ee5c62d7aff1acbd38add2"
-PR = "r2"
+PR = "r3"
SRC_URI = "http://ppp.samba.org/ftp/ppp/ppp-${PV}.tar.gz \
file://makefile.patch \
@@ -18,6 +18,7 @@ SRC_URI = "http://ppp.samba.org/ftp/ppp/ppp-${PV}.tar.gz
\
file://pppd-resolv-varrun.patch \
file://enable-ipv6.patch \
Re: [yocto] Building poky-tiny for ARM fails in do_compile of elfutils
On Mon, 2012-06-04 at 14:55 -0700, Khem Raj wrote: > >> > | ../libdwfl/libdwfl_pic.a(linux-kernel-modules.os): In function > >> > `dwfl_linux_kernel_report_offline': > >> > | > >> > /home/rchatre/poky_build/tmp/work/armv5te-poky-linux-gnueabi/elfutils-0.148-r7/elfutils-0.148/libdwfl/linux-kernel-modules.c:310: > >> > undefined reference to `fts_open' > > you need libc-ftraverse added to > > >> > | ../libebl/libebl.a(eblwstrtab.o): In function `copystrings': > >> > | > >> > /home/rchatre/poky_build/tmp/work/armv5te-poky-linux-gnueabi/elfutils-0.148-r7/elfutils-0.148/libebl/eblwstrtab.c:329: > >> > undefined reference to `wmempcpy' > >> > | ../libebl/libebl.a(eblwstrtab.o): In function `ebl_wstrtabadd': > >> > | > >> > /home/rchatre/poky_build/tmp/work/armv5te-poky-linux-gnueabi/elfutils-0.148-r7/elfutils-0.148/libebl/eblwstrtab.c:249: > >> > undefined reference to `wcslen' > >> > | ../libebl/libebl.a(eblwstrtab.o): In function `searchstring': > >> > | > >> > /home/rchatre/poky_build/tmp/work/armv5te-poky-linux-gnueabi/elfutils-0.148-r7/elfutils-0.148/libebl/eblwstrtab.c:228: > >> > undefined reference to `wmemcmp' > > I think you need to enable libc-posix-clang-wchar in DISTRO_FEATURES > if you want this to work. > > you can add both libc-posix-clang-wchar and libc-ftraverse to > DISTRO_FEATURES_LIBC_DEFAULT > Thank you very much! I am able to build the poky-tiny image and boot it in qemu. Reinette ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH x32 Edison 0/2] Fixes for meta-x32 edison branch
The following patches are required to use the edison branch of meta-x32 with
the current edison branch of Poky.
The first change is required because the edison branch updated its openssl
version some time ago for security fixes.
The gmp change is required so that gmp-native can be used by ppl.
Regards,
Joshua
CC: Nitin Kamble
The following changes since commit 78a8f65718b7ad7c93103a82026575687271cf5d:
gmp: also built libgmpxx for gmp-native (2011-10-14 10:30:03 -0700)
are available in the git repository at:
git://github.com/incandescant/meta-x32.git josh/edison
https://github.com/incandescant/meta-x32
Joshua Lock (2):
openssl: update bbappend to match version in poky edison
gmp: Fix EXTRA_OECONF for native target
gmp/gmp_5.0.2.bbappend |2 +-
...ssl_0.9.8r.bbappend => openssl_0.9.8s.bbappend} |0
2 files changed, 1 insertions(+), 1 deletions(-)
rename openssl/{openssl_0.9.8r.bbappend => openssl_0.9.8s.bbappend} (100%)
--
1.7.7.6
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH x32 Edison 1/2] openssl: update bbappend to match version in poky edison
From: Joshua Lock
Signed-off-by: Joshua Lock
---
...ssl_0.9.8r.bbappend => openssl_0.9.8s.bbappend} |0
1 files changed, 0 insertions(+), 0 deletions(-)
rename openssl/{openssl_0.9.8r.bbappend => openssl_0.9.8s.bbappend} (100%)
diff --git a/openssl/openssl_0.9.8r.bbappend b/openssl/openssl_0.9.8s.bbappend
similarity index 100%
rename from openssl/openssl_0.9.8r.bbappend
rename to openssl/openssl_0.9.8s.bbappend
--
1.7.7.6
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH x32 Edison 2/2] gmp: Fix EXTRA_OECONF for native target
From: Joshua Lock Signed-off-by: Joshua Lock --- gmp/gmp_5.0.2.bbappend |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/gmp/gmp_5.0.2.bbappend b/gmp/gmp_5.0.2.bbappend index 4b33dbb..531bda8 100644 --- a/gmp/gmp_5.0.2.bbappend +++ b/gmp/gmp_5.0.2.bbappend @@ -1,3 +1,3 @@ PR .= ".x32" -EXTRA_OECONF_native += " --enable-cxx=yes" +EXTRA_OECONF_virtclass-native += " --enable-cxx=yes" -- 1.7.7.6 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Broken SDK
Finally this error is also resolving. I was exporting wrong path for
QMAKESPEC.
I need to export same path as defined in
environment-setup-armv6-poky-linux-gnueabi, so i executed-
"source /opt/poky/1.0/environment-setup-armv6-poky-linux-gnueabi "
then tried compiling Qt applications and got successful.
Thanks to Yocto community !!
On Tue, Jun 5, 2012 at 5:48 PM, Navani Srivastava <
navani.srivast...@gmail.com> wrote:
> Hi,
>
> Thanks for support. I successfully created SDK with this modification. I
> installed the same SDK and tried compiling Qt application, but got error
> mentioning
>
> "Failure to read QMAKESPEC conf file
> /opt/poky/1.0/sysroots/arm-poky-linux-gnueabi/usr/share/qtopia/mkspecs/linux-gnueabi-oe-g++/qmake.conf/qmake.conf.
> Error processing project file: /home/Qt/hello/hello.pro"
>
> I had exported path of QMAKESPEC to
> /opt/poky/1.0/sysroots/arm-poky-linux-gnueabi/usr/share/qtopia/mkspecs/linux-gnueabi-oe-g++/qmake.conf
>
>
> Any idea why I am ending up with this error ? Any reply is appreciable.
>
> Thanks
> Navani
>
>
> On Wed, May 30, 2012 at 12:36 AM, Khem Raj wrote:
>
>> On Tue, May 29, 2012 at 2:03 AM, Navani Srivastava
>> wrote:
>> >
>> > "ln -s
>> > /opt/poky/1.0/sysroots/arm-poky-linux-gnueabi/usr/share/qtopia/mkspecs
>> > mkspecs
>> > | ln: creating symbolic link `mkspecs': File exists"
>> >
>>
>> as it says it seems file is there already. So make sure the preexisting
>> file
>> is correct if so then you can check first if file exists before creating
>> symlink
>> if the file is incorrect then just use ln -sf to create the symlink
>>
>> > On commenting out
>> > "(cd ${SDK_OUTPUT}/${QT_TOOLS_PREFIX}/..; ln -s
>> > ${SDKTARGETSYSROOT}/usr/share/qtopia/mkspecs mkspecs;)"
>>
>
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
