trouble using a local kernel repo

trouble using a local kernel repo

[Hollis Blanchard]

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

Re: trouble using a local kernel repo

[McClintock Matthew-B29882]

On Thu, Feb 16, 2012 at 8:16 PM, Hollis Blanchard
<hollis_blanchard@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

Re: trouble using a local kernel repo

[Hollis Blanchard]

On 02/16/2012 01:22 PM, McClintock Matthew-B29882 wrote:
> On Thu, Feb 16, 2012 at 8:16 PM, Hollis Blanchard
> <hollis_blanchard@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.
Yeah, I've looked through there, but where should stdout (i.e. those 
echo commands) be appearing?

Hollis Blanchard
Mentor Graphics, Embedded Systems Division

Re: trouble using a local kernel repo

[McClintock Matthew-B29882]

On Thu, Feb 16, 2012 at 9:33 PM, Hollis Blanchard
<hollis_blanchard@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

Re: trouble using a local kernel repo

[Hollis Blanchard]

On 02/16/2012 01:43 PM, McClintock Matthew-B29882 wrote:
> On Thu, Feb 16, 2012 at 9:33 PM, Hollis Blanchard
> <hollis_blanchard@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

Re: trouble using a local kernel repo

[Bruce Ashfield]

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!
>

Re: trouble using a local kernel repo

[Bruce Ashfield]

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_blanchard@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

Re: trouble using a local kernel repo

[Hollis Blanchard]

[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]

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



[-- Attachment #2: Type: text/html, Size: 2135 bytes --]

Re: trouble using a local kernel repo

[Bruce Ashfield]

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
>
>

Re: trouble using a local kernel repo

[Hollis Blanchard]

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

Re: trouble using a local kernel repo

[Bruce Ashfield]

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
>

Re: trouble using a local kernel repo

[Hollis Blanchard]

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

Re: trouble using a local kernel repo

[Bruce Ashfield]

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
>

Re: trouble using a local kernel repo

[Hollis Blanchard]

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

Re: trouble using a local kernel repo

[Bruce Ashfield]

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
>
>