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. One more workflow question: so to test my patch, I need to commit it to my real git repo, then push to the bare git repo, then rebuild Poky. When I find the inevitable problem, do I need to manually delete (git reset --hard) the changeset from both repositories? Is there a better way? 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-17 11:45 AM, 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. One more workflow question: so to test my patch, I need to commit it to my real git repo, then push to the bare git repo, then rebuild Poky. When I find the inevitable problem, do I need to manually delete (git reset --hard) the changeset from both repositories? Is there a better way? As with anything git based ... there's more than one way to do it, and everyone has their favourite way. Me, I'd just revert it and push it. Or hard reset it in the working repo and push -f to the bare one. But generally speaking, you've got the right way. Same as you'd have to pull it off a SRC_URI or remove a bbappend if it was tacked on the end via that method. 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 Thu, Feb 16, 2012 at 8:16 PM, Hollis Blanchard
hollis_blanch...@mentor.com 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 Thu, Feb 16, 2012 at 9:33 PM, Hollis Blanchard
hollis_blanch...@mentor.com 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
hollis_blanch...@mentor.com 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
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
hollis_blanch...@mentor.com 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 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
