* Correct procedure for rebuilding after a git pull
@ 2012-10-03 13:05 James Abernathy
2012-10-03 13:21 ` Burton, Ross
0 siblings, 1 reply; 7+ messages in thread
From: James Abernathy @ 2012-10-03 13:05 UTC (permalink / raw)
To: yocto
[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]
So I'm looking for the right way to do this. Here's the scenario. I do a
complete build of the image core-image-cdv-media for the cedartrail
machine. No changes from the basic BSP, except for the addition of my
meta-layer that include test audios and videos to help test the media
playback using gst-launch. I'm tracking the latest Denzil branch. So
everything works well to this point.
Now I see a bunch of patches pushed to Denzil branch and I want to test
them. My build directory is untouched since the successful build before.
What do I do to rebuild my project to include the latest patches. I've
tried things like "bitbake -c cleansstate core-image-cdv-media" before the
new "bitbake core-image-cdv-media" and I've tried just rebaking by itself.
Something always fails. I've learned that to really test I have to
completely delete my build directory saving only my local.conf and
bblayer.conf.
Am I missing something or is a complete rebuild the only way to get the new
patches in and a successful build??
Jim A
[-- Attachment #2: Type: text/html, Size: 1181 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Correct procedure for rebuilding after a git pull
2012-10-03 13:05 Correct procedure for rebuilding after a git pull James Abernathy
@ 2012-10-03 13:21 ` Burton, Ross
2012-10-03 13:27 ` James Abernathy
0 siblings, 1 reply; 7+ messages in thread
From: Burton, Ross @ 2012-10-03 13:21 UTC (permalink / raw)
To: James Abernathy; +Cc: yocto
On 3 October 2012 14:05, James Abernathy <jfabernathy@gmail.com> wrote:
> Now I see a bunch of patches pushed to Denzil branch and I want to test
> them. My build directory is untouched since the successful build before.
> What do I do to rebuild my project to include the latest patches. I've
> tried things like "bitbake -c cleansstate core-image-cdv-media" before the
> new "bitbake core-image-cdv-media" and I've tried just rebaking by itself.
> Something always fails. I've learned that to really test I have to
> completely delete my build directory saving only my local.conf and
> bblayer.conf.
Just git pull ; bitbake should work -- all of the packages that
changed will rebuild without any problems.
That's the theory, and everyone who works against oe-core/poky master
does this ever day (including me).
Can you give an example of something that fails?
Ross
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Correct procedure for rebuilding after a git pull
2012-10-03 13:21 ` Burton, Ross
@ 2012-10-03 13:27 ` James Abernathy
2012-10-03 13:37 ` Jack Mitchell
0 siblings, 1 reply; 7+ messages in thread
From: James Abernathy @ 2012-10-03 13:27 UTC (permalink / raw)
To: Burton, Ross; +Cc: yocto
[-- Attachment #1: Type: text/plain, Size: 1597 bytes --]
On Wed, Oct 3, 2012 at 9:21 AM, Burton, Ross <ross.burton@intel.com> wrote:
> On 3 October 2012 14:05, James Abernathy <jfabernathy@gmail.com> wrote:
> > Now I see a bunch of patches pushed to Denzil branch and I want to test
> > them. My build directory is untouched since the successful build before.
> > What do I do to rebuild my project to include the latest patches. I've
> > tried things like "bitbake -c cleansstate core-image-cdv-media" before
> the
> > new "bitbake core-image-cdv-media" and I've tried just rebaking by
> itself.
> > Something always fails. I've learned that to really test I have to
> > completely delete my build directory saving only my local.conf and
> > bblayer.conf.
>
> Just git pull ; bitbake should work -- all of the packages that
> changed will rebuild without any problems.
>
> That's the theory, and everyone who works against oe-core/poky master
> does this ever day (including me).
>
> Can you give an example of something that fails?
>
> The most recent patch update to Denzil included some Cedartrail BSP
> updates to the CDV PVR driver. I was traveling last week and I was out of
> date on my poky and meta-intel by at least that long. Monday was the
> pull. So when the rebuild happened, I got a cdv-pvr driver configuration
> error. I didn't look into why because of my experience of this taking
> longer than a complete rebuild. So I deleted the build directory and did
> the rebuild. And I didn't get the error on the rebuild. Everything still
> works fine for me on that BSP.
Jim A
> Ross
>
[-- Attachment #2: Type: text/html, Size: 2319 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Correct procedure for rebuilding after a git pull
2012-10-03 13:37 ` Jack Mitchell
@ 2012-10-03 13:37 ` Burton, Ross
2012-10-03 13:42 ` Jack Mitchell
0 siblings, 1 reply; 7+ messages in thread
From: Burton, Ross @ 2012-10-03 13:37 UTC (permalink / raw)
To: ml; +Cc: yocto
On 3 October 2012 14:37, Jack Mitchell <ml@communistcode.co.uk> wrote:
> I also use this work flow. If something goes wrong with a particular package
> then I will -c cleansstate failed-package and then start the build again.
> This usually fixes it.
Bringing the failure on on the list / bug would be appreciated,
everything *should* rebuild cleanly (especially with recent changes in
master).
Ross
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Correct procedure for rebuilding after a git pull
2012-10-03 13:27 ` James Abernathy
@ 2012-10-03 13:37 ` Jack Mitchell
2012-10-03 13:37 ` Burton, Ross
0 siblings, 1 reply; 7+ messages in thread
From: Jack Mitchell @ 2012-10-03 13:37 UTC (permalink / raw)
To: yocto
On 03/10/12 14:27, James Abernathy wrote:
>
>
> On Wed, Oct 3, 2012 at 9:21 AM, Burton, Ross <ross.burton@intel.com
> <mailto:ross.burton@intel.com>>wrote:
>
> On 3 October 2012 14:05, James Abernathy <jfabernathy@gmail.com
> <mailto:jfabernathy@gmail.com>> wrote:
> > Now I see a bunch of patches pushed to Denzil branch and I want
> to test
> > them. My build directory is untouched since the successful
> build before.
> > What do I do to rebuild my project to include the latest
> patches. I've
> > tried things like "bitbake -c cleansstate core-image-cdv-media"
> before the
> > new "bitbake core-image-cdv-media" and I've tried just rebaking
> by itself.
> > Something always fails. I've learned that to really test I have to
> > completely delete my build directory saving only my local.conf and
> > bblayer.conf.
>
> Just git pull ; bitbake should work -- all of the packages that
> changed will rebuild without any problems.
>
> That's the theory, and everyone who works against oe-core/poky master
> does this ever day (including me).
>
> Can you give an example of something that fails?
>
> The most recent patch update to Denzil included some Cedartrail
> BSP updates to the CDV PVR driver. I was traveling last week and
> I was out of date on my poky and meta-intel by at least that
> long. Monday was the pull. So when the rebuild happened, I got a
> cdv-pvr driver configuration error. I didn't look into why
> because of my experience of this taking longer than a complete
> rebuild. So I deleted the build directory and did the rebuild.
> And I didn't get the error on the rebuild. Everything still works
> fine for me on that BSP.
>
> Jim A
>
> Ross
>
>
I also use this work flow. If something goes wrong with a particular
package then I will -c cleansstate failed-package and then start the
build again. This usually fixes it.
Regards,
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
Jack Mitchell (jack@embed.me.uk)
Embedded Systems Engineer
http://www.embed.me.uk
--
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Correct procedure for rebuilding after a git pull
2012-10-03 13:37 ` Burton, Ross
@ 2012-10-03 13:42 ` Jack Mitchell
2012-10-03 14:11 ` Khem Raj
0 siblings, 1 reply; 7+ messages in thread
From: Jack Mitchell @ 2012-10-03 13:42 UTC (permalink / raw)
To: yocto@yoctoproject.org
On 03/10/12 14:37, Burton, Ross wrote:
> On 3 October 2012 14:37, Jack Mitchell <ml@communistcode.co.uk> wrote:
>> I also use this work flow. If something goes wrong with a particular package
>> then I will -c cleansstate failed-package and then start the build again.
>> This usually fixes it.
> Bringing the failure on on the list / bug would be appreciated,
> everything *should* rebuild cleanly (especially with recent changes in
> master).
>
> Ross
I'll bear that in mind.
I believe it was ext2fs that failed earlier today on my production build
machine. Again a -c cleansstate fixed it and I didn't investigate so I
can't add anything else!
Regards,
--
Jack Mitchell (jack@embed.me.uk)
Embedded Systems Engineer
http://www.embed.me.uk
--
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Correct procedure for rebuilding after a git pull
2012-10-03 13:42 ` Jack Mitchell
@ 2012-10-03 14:11 ` Khem Raj
0 siblings, 0 replies; 7+ messages in thread
From: Khem Raj @ 2012-10-03 14:11 UTC (permalink / raw)
To: ml; +Cc: yocto@yoctoproject.org
On Wed, Oct 3, 2012 at 6:42 AM, Jack Mitchell <ml@communistcode.co.uk> wrote:
>
> I'll bear that in mind.
>
that will help a lot in fixing sstate
> I believe it was ext2fs that failed earlier today on my production build
> machine. Again a -c cleansstate fixed it and I didn't investigate so I can't
> add anything else!
cleansstate was a stop gap but should be avoided as much as possible.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-10-03 14:11 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-10-03 13:05 Correct procedure for rebuilding after a git pull James Abernathy
2012-10-03 13:21 ` Burton, Ross
2012-10-03 13:27 ` James Abernathy
2012-10-03 13:37 ` Jack Mitchell
2012-10-03 13:37 ` Burton, Ross
2012-10-03 13:42 ` Jack Mitchell
2012-10-03 14:11 ` Khem Raj
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.