Re: [yocto] RDEPENDS fails to find an existing package
> Hello,
>
> On Thu, 2012-02-16 at 10:26 +0530, Joshua Immanuel wrote:
>> Can you please explain little bit more on what INSANE_SKIP_${PN} =
>> "dev-so" does. I don't find any documentation on it.
>
> I guess, it suppresses the warnings stating that an non-dev package
> contains symlink. This is the warning I got, when I packaged protobuf
> for yocto
In the e-mail I mentioned that if you are using M2 1.2 (means the
milestone 2 of version 1.2). 1,2 final will be released sometime in
the next few weeks/months.
Sometime between 1.1 and 1.2 M2 - the behavior has been changed where
the warning you described below has been changed to an error - thereby
- the said .so files are not actually included.
This does not apply if you are using 1.0 or 1.1 (not sure about 1.1
myself - I jumped from 1.0 to 1.2 M2)
Eventually - if/when you will be using a newer release of yocto - your
recipe will fail to work as expected - unless you have that insane
skip.
>
>> WARNING: QA Issue: non -dev/-dbg/-nativesdk package contains symlink .so:
>> protobuf path
>> '/work/core2-poky-linux/protobuf-2.4.1-r1/packages-split/protobuf/usr/lib/libprotobuf.so'
>> WARNING: QA Issue: protobuf:
>> /work/core2-poky-linux/protobuf-2.4.1-r1/packages-split/protobuf/usr/lib/libprotobuf.so
>> contains probably-redundant RPATH /usr/lib
>
> Adding the line INSANE_SKIP_${PN} = "dev-so" suppressed the above
> warnings.
This is correct.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RDEPENDS fails to find an existing package
On Thursday, February 16, 2012, Autif Khan wrote:
>> Hello,
>>
>> On Thu, 2012-02-16 at 10:26 +0530, Joshua Immanuel wrote:
>>> Can you please explain little bit more on what INSANE_SKIP_${PN} =
>>> "dev-so" does. I don't find any documentation on it.
>>
>> I guess, it suppresses the warnings stating that an non-dev package
>> contains symlink. This is the warning I got, when I packaged protobuf
>> for yocto
>
> In the e-mail I mentioned that if you are using M2 1.2 (means the
> milestone 2 of version 1.2). 1,2 final will be released sometime in
> the next few weeks/months.
>
> Sometime between 1.1 and 1.2 M2 - the behavior has been changed where
> the warning you described below has been changed to an error - thereby
> - the said .so files are not actually included.
>
> This does not apply if you are using 1.0 or 1.1 (not sure about 1.1
> myself - I jumped from 1.0 to 1.2 M2)
>
> Eventually - if/when you will be using a newer release of yocto - your
> recipe will fail to work as expected - unless you have that insane
> skip.
>
Did you even try to understand what his original problem was ?
If not go back to first post and reread it
>
>>
>>> WARNING: QA Issue: non -dev/-dbg/-nativesdk package contains symlink
.so:
>>> protobuf path
'/work/core2-poky-linux/protobuf-2.4.1-r1/packages-split/protobuf/usr/lib/libprotobuf.so'
>>> WARNING: QA Issue: protobuf:
/work/core2-poky-linux/protobuf-2.4.1-r1/packages-split/protobuf/usr/lib/libprotobuf.so
>>> contains probably-redundant RPATH /usr/lib
>>
>> Adding the line INSANE_SKIP_${PN} = "dev-so" suppressed the above
>> warnings.
>
> This is correct.
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] trouble using a local kernel repo
I'm trying to figure out how to use a cloned/modified copy of the
linux-yocto-3.0 git repository. Here's what I did:
* cloned linux-yocto-3.0.git and committed to the meta branch
* specified my new repo:
--- a/meta/recipes-kernel/linux/linux-yocto_3.0.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.0.bb
@@ -18,12 +18,12 @@ SRCREV_machine_qemuppc ?=
"15fd748017f0849138ff4b47d73f6866fa26cfe8"
SRCREV_machine_qemux86 ?= "8f74a4339b3dc029fafff0ba7d88d6dc950d4b31"
SRCREV_machine_qemux86-64 ?= "610c5a62daeda033755b0b7bfcb3e2cad5c76f3f"
SRCREV_machine ?= "5df0b4c2538399aed543133b3855f809adf08ab8"
-SRCREV_meta ?= "b78a519841bd8b477cad599af8d38df6760445c1"
+SRCREV_meta ?= "7af8d6f8769335b79c1b76c8bded256b8f909c74"
PR = "r3"
PV = "${LINUX_VERSION}+git${SRCPV}"
-SRC_URI =
"git://git.yoctoproject.org/linux-yocto-3.0;protocol=git;nocheckout=1;branch=${KBRANCH},meta
+SRC_URI =
"git:///mnt/linux-yocto-3.0.git;protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machi
COMPATIBLE_MACHINE = "(qemuarm|qemux86|qemuppc|qemumips|qemux86-64)"
* bitbake -c clean virtual/kernel&& bitbake virtual/kernel
What I get is this:
ERROR: Function failed: do_validate_branches (see
/mnt/poky.git/build/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-3.0.18+git2+7af8d6f8769335b79c1b76c8bded256b8f909c74_1+368e38c673ffac8b37fc2a2d4c1e4a1e6f8abf19-r3/temp/log.do_validate_branches.5342
for further information)
There is no more information in that file. It contains only the exact
message I already got on the console ("ERROR: Function failed ...").
What am I missing?
http://www.yoctoproject.org/docs/current/kernel-manual/kernel-manual.html was
not helpful.
Thanks!
--
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] trouble using a local kernel repo
On Thu, Feb 16, 2012 at 8:16 PM, Hollis Blanchard
wrote:
> I'm trying to figure out how to use a cloned/modified copy of the
> linux-yocto-3.0 git repository. Here's what I did:
>
> * cloned linux-yocto-3.0.git and committed to the meta branch
> * specified my new repo:
>
> --- a/meta/recipes-kernel/linux/linux-yocto_3.0.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto_3.0.bb
> @@ -18,12 +18,12 @@ SRCREV_machine_qemuppc ?=
> "15fd748017f0849138ff4b47d73f6866fa26cfe8"
> SRCREV_machine_qemux86 ?= "8f74a4339b3dc029fafff0ba7d88d6dc950d4b31"
> SRCREV_machine_qemux86-64 ?= "610c5a62daeda033755b0b7bfcb3e2cad5c76f3f"
> SRCREV_machine ?= "5df0b4c2538399aed543133b3855f809adf08ab8"
> -SRCREV_meta ?= "b78a519841bd8b477cad599af8d38df6760445c1"
> +SRCREV_meta ?= "7af8d6f8769335b79c1b76c8bded256b8f909c74"
>
> PR = "r3"
> PV = "${LINUX_VERSION}+git${SRCPV}"
>
> -SRC_URI =
> "git://git.yoctoproject.org/linux-yocto-3.0;protocol=git;nocheckout=1;branch=${KBRANCH},meta
> +SRC_URI =
> "git:///mnt/linux-yocto-3.0.git;protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machi
>
> COMPATIBLE_MACHINE = "(qemuarm|qemux86|qemuppc|qemumips|qemux86-64)"
>
> * bitbake -c clean virtual/kernel&& bitbake virtual/kernel
>
>
> What I get is this:
> ERROR: Function failed: do_validate_branches (see
> /mnt/poky.git/build/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-3.0.18+git2+7af8d6f8769335b79c1b76c8bded256b8f909c74_1+368e38c673ffac8b37fc2a2d4c1e4a1e6f8abf19-r3/temp/log.do_validate_branches.5342
> for further information)
>
> There is no more information in that file. It contains only the exact
> message I already got on the console ("ERROR: Function failed ...").
>
> What am I missing?
> http://www.yoctoproject.org/docs/current/kernel-manual/kernel-manual.html
> was not helpful.
Not much help but you can look in:
meta/classes/kernel-yocto.bbclass:do_validate_branches() {
And try to figure out which step could return an error code to the shell.
-M
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] trouble using a local kernel repo
On 02/16/2012 01:22 PM, McClintock Matthew-B29882 wrote:
On Thu, Feb 16, 2012 at 8:16 PM, Hollis Blanchard
wrote:
I'm trying to figure out how to use a cloned/modified copy of the
linux-yocto-3.0 git repository. Here's what I did:
* cloned linux-yocto-3.0.git and committed to the meta branch
* specified my new repo:
--- a/meta/recipes-kernel/linux/linux-yocto_3.0.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.0.bb
@@ -18,12 +18,12 @@ SRCREV_machine_qemuppc ?=
"15fd748017f0849138ff4b47d73f6866fa26cfe8"
SRCREV_machine_qemux86 ?= "8f74a4339b3dc029fafff0ba7d88d6dc950d4b31"
SRCREV_machine_qemux86-64 ?= "610c5a62daeda033755b0b7bfcb3e2cad5c76f3f"
SRCREV_machine ?= "5df0b4c2538399aed543133b3855f809adf08ab8"
-SRCREV_meta ?= "b78a519841bd8b477cad599af8d38df6760445c1"
+SRCREV_meta ?= "7af8d6f8769335b79c1b76c8bded256b8f909c74"
PR = "r3"
PV = "${LINUX_VERSION}+git${SRCPV}"
-SRC_URI =
"git://git.yoctoproject.org/linux-yocto-3.0;protocol=git;nocheckout=1;branch=${KBRANCH},meta
+SRC_URI =
"git:///mnt/linux-yocto-3.0.git;protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machi
COMPATIBLE_MACHINE = "(qemuarm|qemux86|qemuppc|qemumips|qemux86-64)"
* bitbake -c clean virtual/kernel&&bitbake virtual/kernel
What I get is this:
ERROR: Function failed: do_validate_branches (see
/mnt/poky.git/build/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-3.0.18+git2+7af8d6f8769335b79c1b76c8bded256b8f909c74_1+368e38c673ffac8b37fc2a2d4c1e4a1e6f8abf19-r3/temp/log.do_validate_branches.5342
for further information)
There is no more information in that file. It contains only the exact
message I already got on the console ("ERROR: Function failed ...").
What am I missing?
http://www.yoctoproject.org/docs/current/kernel-manual/kernel-manual.html
was not helpful.
Not much help but you can look in:
meta/classes/kernel-yocto.bbclass:do_validate_branches() {
And try to figure out which step could return an error code to the shell.
Yeah, I've looked through there, but where should stdout (i.e. those
echo commands) be appearing?
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] trouble using a local kernel repo
On Thu, Feb 16, 2012 at 9:33 PM, Hollis Blanchard
wrote:
> Yeah, I've looked through there, but where should stdout (i.e. those echo
> commands) be appearing?
I'd guess it's failing before that... you can add your own echo's.
Also, this should be in that log file:
tmp/work/${ARCH}/linux-yocto-vZ-rX/temp/log.do_validate.${PID}
-M
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] trouble using a local kernel repo
On 02/16/2012 01:43 PM, McClintock Matthew-B29882 wrote:
On Thu, Feb 16, 2012 at 9:33 PM, Hollis Blanchard
wrote:
Yeah, I've looked through there, but where should stdout (i.e. those echo
commands) be appearing?
I'd guess it's failing before that... you can add your own echo's.
Also, this should be in that log file:
tmp/work/${ARCH}/linux-yocto-vZ-rX/temp/log.do_validate.${PID}
Ah ha, it *was* failing before that.
'git show-ref -s --heads yocto/standard/beagleboard' fails without an
error message (prints nothing; $? is 1).
On the other hand, 'git show-ref -s --head yocto/standard/beagleboard'
seems to work (heads vs head). This is git 1.6.0.5.
Of course, this was working fine with the remote git tree -- it's only
when I switched to my local clone that I ran into problems. I guess that
means I'm missing "refs/heads", whatever that means... did I somehow
clone my git tree incorrectly? I did a git clone; git checkout -t
origin/meta -b meta; git commit.
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] MEL Kit - qemu targets
Last week, we announced the MEL Kit support for both the BeagleBoard and the PandaBoard. This week, we are announcing the availability of MEL Kits for emulated target environments. This should be handy for those that want to check out CodeBench Lite or MEL Lite, but you lack hardware. These MEL Kits for QEMU are absolutely free and available to anyone that would like to tinker with a prebuilt, Yocto-based image set for the following emulation environments: QEMU for ARM QEMU for MIPS QEMU for Freescale Power QEMU for Intel x86 Each kit contains a Sourcery CodeBench Lite (integrated cross toolchain), a set of libraries/headers for applications development, and a quick start guide that should get you started right out of the box. http://www.mentor.com/embedded-software/downloads/linux-kits/ The entire Mentor Embedded Linux engineering team is hanging out on mel-discuss (http://sourcerytools.com/cgi-bin/mailman/listinfo/mel-discuss/). If you have any questions about MEL Kit or Mentor Embedded Linux, use mel-discuss to go to the source (so to speak). Regards, John Cherry Mentor Embedded ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] trouble using a local kernel repo
On 12-02-16 03:16 PM, Hollis Blanchard wrote:
I'm trying to figure out how to use a cloned/modified copy of the
linux-yocto-3.0 git repository. Here's what I did:
* cloned linux-yocto-3.0.git and committed to the meta branch
* specified my new repo:
Very strange. Is this from the yocto master branch ?
--- a/meta/recipes-kernel/linux/linux-yocto_3.0.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.0.bb
@@ -18,12 +18,12 @@ SRCREV_machine_qemuppc ?=
"15fd748017f0849138ff4b47d73f6866fa26cfe8"
SRCREV_machine_qemux86 ?= "8f74a4339b3dc029fafff0ba7d88d6dc950d4b31"
SRCREV_machine_qemux86-64 ?= "610c5a62daeda033755b0b7bfcb3e2cad5c76f3f"
SRCREV_machine ?= "5df0b4c2538399aed543133b3855f809adf08ab8"
-SRCREV_meta ?= "b78a519841bd8b477cad599af8d38df6760445c1"
+SRCREV_meta ?= "7af8d6f8769335b79c1b76c8bded256b8f909c74"
PR = "r3"
PV = "${LINUX_VERSION}+git${SRCPV}"
-SRC_URI =
"git://git.yoctoproject.org/linux-yocto-3.0;protocol=git;nocheckout=1;branch=${KBRANCH},meta
+SRC_URI =
"git:///mnt/linux-yocto-3.0.git;protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machi
COMPATIBLE_MACHINE = "(qemuarm|qemux86|qemuppc|qemumips|qemux86-64)"
* bitbake -c clean virtual/kernel&& bitbake virtual/kernel
What I get is this:
ERROR: Function failed: do_validate_branches (see
/mnt/poky.git/build/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-3.0.18+git2+7af8d6f8769335b79c1b76c8bded256b8f909c74_1+368e38c673ffac8b37fc2a2d4c1e4a1e6f8abf19-r3/temp/log.do_validate_branches.5342
for further information)
There is no more information in that file. It contains only the exact
message I already got on the console ("ERROR: Function failed ...").
validate branches will always dump out an error message if it finds
a mismatch in the SRCREV and branch(s).
I've seen this myself in the past. It triggers when the kernel tree that
is being used is for some reason missing the branches in question and
the default bitbake behaviour that if any command returns non zero, the
entire function fails.
I have two commits that attempt to detect this, and do a proper warning,
I just haven't sent them out yet due to travel.
That being said. If you go into your src tree. Do you see the meta and
board branch ? Are they local branches ? Is your SRC_URI pointing at a
bare clone, and not a non-bare one ?
Cheers,
Bruce
What am I missing?
http://www.yoctoproject.org/docs/current/kernel-manual/kernel-manual.html was
not helpful.
Thanks!
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] trouble using a local kernel repo
On 12-02-16 05:06 PM, Hollis Blanchard wrote:
On 02/16/2012 01:43 PM, McClintock Matthew-B29882 wrote:
On Thu, Feb 16, 2012 at 9:33 PM, Hollis Blanchard
wrote:
Yeah, I've looked through there, but where should stdout (i.e. those
echo
commands) be appearing?
I'd guess it's failing before that... you can add your own echo's.
Also, this should be in that log file:
tmp/work/${ARCH}/linux-yocto-vZ-rX/temp/log.do_validate.${PID}
Ah ha, it *was* failing before that.
'git show-ref -s --heads yocto/standard/beagleboard' fails without an
error message (prints nothing; $? is 1).
On the other hand, 'git show-ref -s --head yocto/standard/beagleboard'
seems to work (heads vs head). This is git 1.6.0.5.
Of course, this was working fine with the remote git tree -- it's only
when I switched to my local clone that I ran into problems. I guess that
means I'm missing "refs/heads", whatever that means... did I somehow
clone my git tree incorrectly? I did a git clone; git checkout -t
origin/meta -b meta; git commit.
I just sent a reply with this. We crossed on the 'net. I have changes
to detect and report this, but yes, it would be the clone tripping us
up. I've never seen the heads vs head change, but all my machines are
1.7.x git installs. I'll go have a look at a 1.6 git and see if that
is in fact something to detect and handle.
But since it only happens on your local clone, it really shouldn't be
a git issue .. and is more likely just with the clone.
Bruce
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] trouble using a local kernel repo
On 02/16/2012 02:11 PM, Bruce Ashfield wrote: On 12-02-16 03:16 PM, Hollis Blanchard wrote: I'm trying to figure out how to use a cloned/modified copy of the linux-yocto-3.0 git repository. Here's what I did: * cloned linux-yocto-3.0.git and committed to the meta branch * specified my new repo: Very strange. Is this from the yocto master branch ? I ran this: git clone git://git.yoctoproject.org/linux-yocto-3.0 git checkout -t origin/meta -b meta vim git commit [snip] That being said. If you go into your src tree. Do you see the meta and board branch ? Are they local branches ? Is your SRC_URI pointing at a bare clone, and not a non-bare one ? As you can tell from my clone command above, it is a non-bare clone (though I have no idea what that actually means). I have lots of branches, but aside from master only my new "meta" branch is local: -bash-3.2$ git branch -a master * meta origin/HEAD origin/master origin/meta origin/yocto/base origin/yocto/eg20t origin/yocto/emgd origin/yocto/emgd-1.10 origin/yocto/gma500 origin/yocto/standard/arm-versatile-926ejs origin/yocto/standard/base origin/yocto/standard/beagleboard [...] Hollis Blanchard Mentor Graphics, Embedded Systems Division ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] trouble using a local kernel repo
On 12-02-16 05:50 PM, Hollis Blanchard wrote: On 02/16/2012 02:11 PM, Bruce Ashfield wrote: On 12-02-16 03:16 PM, Hollis Blanchard wrote: I'm trying to figure out how to use a cloned/modified copy of the linux-yocto-3.0 git repository. Here's what I did: * cloned linux-yocto-3.0.git and committed to the meta branch * specified my new repo: Very strange. Is this from the yocto master branch ? I ran this: git clone git://git.yoctoproject.org/linux-yocto-3.0 git checkout -t origin/meta -b meta vim git commit [snip] That being said. If you go into your src tree. Do you see the meta and board branch ? Are they local branches ? Is your SRC_URI pointing at a bare clone, and not a non-bare one ? As you can tell from my clone command above, it is a non-bare clone (though I have no idea what that actually means). I have lots of branches, but aside from master only my new "meta" branch is local: That's the problem. I have a patch that detects this and abort is a non bare upstream is used. I just need to send them .. which I'll do when I get back to my desk next week. There are two reason for this bare clone requirement: - technical: this scales to several hundred branches. cloning, and iterating remote branches to create local tracking branches is noisy and time consuming. So there's a trick that has been in use for years that you can clone a bare upstream, and mass convert the branches to local in a single operation. - social: you want to do your development in a different tree from the one that is being cloned and used. That way the tree is clean, and you are building what you expect. This was supposed to be added to the new documentation (in the smaller, lightened versions) .. but I don't think that is out yet. Cheers, Bruce -bash-3.2$ git branch -a master * meta origin/HEAD origin/master origin/meta origin/yocto/base origin/yocto/eg20t origin/yocto/emgd origin/yocto/emgd-1.10 origin/yocto/gma500 origin/yocto/standard/arm-versatile-926ejs origin/yocto/standard/base origin/yocto/standard/beagleboard [...] Hollis Blanchard Mentor Graphics, Embedded Systems Division ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] trouble using a local kernel repo
On 02/16/2012 03:02 PM, Bruce Ashfield wrote: That's the problem. I have a patch that detects this and abort is a non bare upstream is used. I just need to send them .. which I'll do when I get back to my desk next week. There are two reason for this bare clone requirement: - technical: this scales to several hundred branches. cloning, and iterating remote branches to create local tracking branches is noisy and time consuming. So there's a trick that has been in use for years that you can clone a bare upstream, and mass convert the branches to local in a single operation. - social: you want to do your development in a different tree from the one that is being cloned and used. That way the tree is clean, and you are building what you expect. Do I want to do my development in a different tree? Are you sure? ;) I don't need to scale to hundreds of branches -- I just have one small patch I wanted to test. I already have it in a "clean" tree -- it's a committed changeset, with a commit message and everything, even though I haven't even been able to *test* it yet! I'm just trying to test a small kernel/meta patch, and the poorly documented list of setup requirements is growing longer and longer. All this stuff may be good practice for a more complicated scenario, but so far it seems like enormous overkill for my use case... Hollis Blanchard Mentor Graphics, Embedded Systems Division ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] trouble using a local kernel repo
On 12-02-16 06:18 PM, Hollis Blanchard wrote: On 02/16/2012 03:02 PM, Bruce Ashfield wrote: That's the problem. I have a patch that detects this and abort is a non bare upstream is used. I just need to send them .. which I'll do when I get back to my desk next week. There are two reason for this bare clone requirement: - technical: this scales to several hundred branches. cloning, and iterating remote branches to create local tracking branches is noisy and time consuming. So there's a trick that has been in use for years that you can clone a bare upstream, and mass convert the branches to local in a single operation. - social: you want to do your development in a different tree from the one that is being cloned and used. That way the tree is clean, and you are building what you expect. Do I want to do my development in a different tree? Are you sure? ;) The point is that the tree is local to your machine, but it doesn't have to be. You may only have push, not direct commit access. It's really not asking for anything that isn't already common practice. I don't need to scale to hundreds of branches -- I just have one small patch I wanted to test. I already have it in a "clean" tree -- it's a committed changeset, with a commit message and everything, even though I haven't even been able to *test* it yet! Right. I didn't imply that .. just to explain why it is like it is. I'm just trying to test a small kernel/meta patch, and the poorly documented list of setup requirements is growing longer and longer. All this stuff may be good practice for a more complicated scenario, but so far it seems like enormous overkill for my use case... So why are you trying to use the technique ? Maybe the answer is that the docs made it sound like this was the best/right way .. and that's a problem in itself. If you do have a single patch, toss it on the end of the SRC_URI and everything just works like any other package. The local repo instructions are largely for BSP developers or teams that are working with the kernel on a more intensive basis. So there are some setup requirements. If you want to explore the git flow, and maintain out of tree branches, repositories based on linux-yocto, etc. Then that's the time to kick away on the git workflow and steps, but as the first plunge, it may not be the right choice. Cheers, Bruce Hollis Blanchard Mentor Graphics, Embedded Systems Division ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] trouble using a local kernel repo
On 02/16/2012 03:25 PM, Bruce Ashfield wrote: The point is that the tree is local to your machine, but it doesn't have to be. You may only have push, not direct commit access. It's really not asking for anything that isn't already common practice. Hmm, I'm not at all a git expert, but I thought common practice was to clone the upstream git tree, then create local branches that track the upstream ones. I've never seen any directions say "first create a bare clone, then clone that again, then create local branches." I'm just trying to test a small kernel/meta patch, and the poorly documented list of setup requirements is growing longer and longer. All this stuff may be good practice for a more complicated scenario, but so far it seems like enormous overkill for my use case... So why are you trying to use the technique ? Maybe the answer is that the docs made it sound like this was the best/right way .. and that's a problem in itself. The docs don't cover "how do I add a kernel patch?" at all, AFAICS. ... oh wow, now I see http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html. This actually does talk about bare clones. http://www.yoctoproject.org/docs/current/kernel-manual/kernel-manual.html, which is what I had been reading, does not. If you do have a single patch, toss it on the end of the SRC_URI and everything just works like any other package. The reason I'm even bothering is to try to be a good person. I could have stuck this in a private collection 2 days ago... but I figured this is going to bite plenty of other people, so I should try to submit a patch that would fix it for everybody. I could tell the kernel configuration system is complicated, but I really didn't expect this many barriers. Hollis Blanchard Mentor Graphics, Embedded Systems Division ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] trouble using a local kernel repo
On 12-02-16 06:52 PM, Hollis Blanchard wrote: On 02/16/2012 03:25 PM, Bruce Ashfield wrote: The point is that the tree is local to your machine, but it doesn't have to be. You may only have push, not direct commit access. It's really not asking for anything that isn't already common practice. Hmm, I'm not at all a git expert, but I thought common practice was to clone the upstream git tree, then create local branches that track the upstream ones. I've never seen any directions say "first create a bare clone, then clone that again, then create local branches." It's a build system thing, what can I say ? When you are working with the raw tree, and your own cross compiler, that's absolutely the workflow. It's the same as having to write recipes versus Makefiles and python versus shell. I had to switch to recipes and bitbake constructs when that didn't match anything I had previously had or used as best practices. I'm just trying to test a small kernel/meta patch, and the poorly documented list of setup requirements is growing longer and longer. All this stuff may be good practice for a more complicated scenario, but so far it seems like enormous overkill for my use case... So why are you trying to use the technique ? Maybe the answer is that the docs made it sound like this was the best/right way .. and that's a problem in itself. The docs don't cover "how do I add a kernel patch?" at all, AFAICS. ... oh wow, now I see http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html. This actually does talk about bare clones. http://www.yoctoproject.org/docs/current/kernel-manual/kernel-manual.html, which is what I had been reading, does not. Argh. We are working a brand new organization for this, with the important information clearly and concisely stated as the first thing you see. I feel your pain on this. If you do have a single patch, toss it on the end of the SRC_URI and everything just works like any other package The reason I'm even bothering is to try to be a good person. I could have stuck this in a private collection 2 days ago... but I figured this is going to bite plenty of other people, so I should try to submit a patch that would fix it for everybody. I could tell the kernel configuration system is complicated, but I really didn't expect this many barriers. Absolutely. I'm glad to hear this. The first contact information let us down a bit. There IS complexity in the system, but for the easy straight forward, first patch sort of use case, it is supposed to be completely hidden and just work like any other package. I hate hearing about anyone have trouble, or things not working, and I've been knocking off things that break for over a year now. For example, someone else hit the bare clone (first time in over two years!), and I wrote a patch to fix that case .. but I failed to get it out in time to save you the same trouble :( Cheers, Bruce Hollis Blanchard Mentor Graphics, Embedded Systems Division ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [eclipse-plugin]: ADT version too old
I'm using the ecipse-plugin: http://autobuilder.yoctoproject.org/pub/nightly/20120216-2/eclipse-plugin/indigo/org.yocto.sdk-rc1-201202161547-archive.zip my build tree is following the latest yocto git tree: git://git.yoctoproject.org/poky.git and when assign the build tree as toolchain directory in eclipse, it said that: "Yocto Preferences Configuration Error! OECORE related items are not found in envrionement setup files. The ADT version you're using is too old. Please upgrade to our latest ADT Version!" I have checked the env setup file: /tmp/tmp/environment-setup-ppc603e-insigma-linux. It has OECORE items no doubt. export OECORE_DISTRO_VERSION="1.1+snapshot-20120217" export OECORE_SDK_VERSION="1.1+snapshot" and I googled, found: https://lists.yoctoproject.org/pipermail/yocto/2011-October/005379.html the author said that: "Could you check your file of meta-yocto/conf/distro/poky.conf for the variable DISTRO_VERSION, it should be "1.1'. " but I checked the git tree, the poky.conf always has 'snapshot' in 'DISTRO_VERSION'. I lost. Any idea? THANKS! -- Yi Qingliang niqingli...@insigma.com.cn https://niqingliang2003.wordpress.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [eclipse-plugin]: ADT version too old
and there is no use to change DISTRO_VERSION in /tmp/tmp/environment-setup-ppc603e-insigma-linux. On Fri, 2012-02-17 at 10:42 +0800, 倪庆亮 wrote: > I'm using the ecipse-plugin: > http://autobuilder.yoctoproject.org/pub/nightly/20120216-2/eclipse-plugin/indigo/org.yocto.sdk-rc1-201202161547-archive.zip > > my build tree is following the latest yocto git tree: > git://git.yoctoproject.org/poky.git > > and when assign the build tree as toolchain directory in eclipse, it > said that: > "Yocto Preferences Configuration Error! > OECORE related items are not found in envrionement setup files. > The ADT version you're using is too old. > Please upgrade to our latest ADT Version!" > > I have checked the env setup file: > /tmp/tmp/environment-setup-ppc603e-insigma-linux. > It has OECORE items no doubt. > export OECORE_DISTRO_VERSION="1.1+snapshot-20120217" > export OECORE_SDK_VERSION="1.1+snapshot" > > and I googled, found: > https://lists.yoctoproject.org/pipermail/yocto/2011-October/005379.html > > the author said that: "Could you check your file of > meta-yocto/conf/distro/poky.conf for the variable DISTRO_VERSION, it > should be "1.1'. " > > but I checked the git tree, the poky.conf always has 'snapshot' in > 'DISTRO_VERSION'. > > I lost. > > Any idea? THANKS! > > -- > Yi Qingliang > niqingli...@insigma.com.cn > https://niqingliang2003.wordpress.com > -- Yi Qingliang niqingli...@insigma.com.cn https://niqingliang2003.wordpress.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [eclipse-plugin]: ADT version too old
Ni Qingliang wrote on 2012-02-17: > and there is no use to change DISTRO_VERSION in > /tmp/tmp/environment-setup-ppc603e-insigma-linux. Looks like you're using the 1.1 eclipse plugin against the 1.1+snapshot poky. You may manually change the OECORE_SDK_VERSION in the environment file as a workaround. -Lianhao > On Fri, 2012-02-17 at 10:42 +0800, 倪庆亮 wrote: >> I'm using the ecipse-plugin: >> http://autobuilder.yoctoproject.org/pub/nightly/20120216-2/eclipse-plugin/indigo/org.yocto.sdk-rc1-201202161547-archive.zip >> >> my build tree is following the latest yocto git tree: >> git://git.yoctoproject.org/poky.git >> >> and when assign the build tree as toolchain directory in eclipse, it >> said that: >> "Yocto Preferences Configuration Error! >> OECORE related items are not found in envrionement setup files. >> The ADT version you're using is too old. >> Please upgrade to our latest ADT Version!" >> I have checked the env setup file: >> /tmp/tmp/environment-setup-ppc603e-insigma-linux. >> It has OECORE items no doubt. >> export OECORE_DISTRO_VERSION="1.1+snapshot-20120217" >> export OECORE_SDK_VERSION="1.1+snapshot" >> >> and I googled, found: >> https://lists.yoctoproject.org/pipermail/yocto/2011-October/005379.html >> >> the author said that: "Could you check your file of >> meta-yocto/conf/distro/poky.conf for the variable DISTRO_VERSION, it >> should be "1.1'. " >> >> but I checked the git tree, the poky.conf always has 'snapshot' in >> 'DISTRO_VERSION'. >> >> I lost. >> >> Any idea? THANKS! >> >> -- >> Yi Qingliang >> niqingli...@insigma.com.cn >> https://niqingliang2003.wordpress.com >> > ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [eclipse-plugin]: ADT version too old
thanks, I found the problem, I have setup one new meta layer, and use a new distro (new name and new version), but the eclipse-plugin is only for native poky distro, and will check if the version is same as poky distro's version. On Fri, 2012-02-17 at 12:10 +0800, Lu, Lianhao wrote: > > Looks like you're using the 1.1 eclipse plugin against the 1.1 > +snapshot poky. You may manually change the OECORE_SDK_VERSION in the > environment file as a workaround. > > -- Yi Qingliang niqingli...@insigma.com.cn https://niqingliang2003.wordpress.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] The sysroot location in eclipse plugin?
the environment-setup file in build tree had defined CFLAGS and CXXFLAGS which include the sysroot argument(/tmp/sysroots/). Do we must specify the sysroot location in the eclipse plugin? after specify it, I found the CFLAGS CXXFLAGS in project property follow it, and dropped the sysroot defined in environment-setup file. and I have another sysroot running on target (qemu) unzipped from the image. If I specify the target sysroot in eclipse-plugin, I can't compile my code, because there is no any header file in /usr/include. If I specify the /tmp/sysroots/, I can't running the qemu machine in eclipse, because there is no 'init'. what is the problem? THANKS! -- Yi Qingliang niqingli...@insigma.com.cn https://niqingliang2003.wordpress.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] The sysroot location in eclipse plugin?
Ni Qingliang wrote on 2012-02-17: > the environment-setup file in build tree had defined CFLAGS and CXXFLAGS > which include the sysroot argument(/tmp/sysroots/). > > Do we must specify the sysroot location in the eclipse plugin? > > after specify it, I found the CFLAGS CXXFLAGS in project property follow > it, and dropped the sysroot defined in environment-setup file. > > and I have another sysroot running on target (qemu) unzipped from the > image. > > If I specify the target sysroot in eclipse-plugin, I can't compile my > code, because there is no any header file in /usr/include. > If I specify the /tmp/sysroots/, I can't running > the qemu machine in eclipse, because there is no 'init'. > The eclipse-plugin by default assumes the user using the same target sysroot for both cross compiling and qemu launching. So this requires the target sysroot having the libraries and header files. You might have 2 options here: 1. build a new image with the "dev-pkgs" image feature(you can set that in conf/local.conf in variable EXTRA_IMAGE_FEATURES) and use that image as target sysroot in eclipse. 2. launch the qemu in console terminal, out of eclipse, using a different target sysroot. Best Regards, Lianhao ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
