> -----Original Message----- > From: Zanussi, Tom > Sent: Thursday, July 19, 2012 8:27 PM > To: Kamble, Nitin A > Cc: yocto@yoctoproject.org; bruce.ashfi...@windriver.com > Subject: RE: [PATCH 0/1] meta: update crownbay.scc for newer emgd driver > > On Thu, 2012-07-19 at 07:39 -0700, Kamble, Nitin A wrote: > > > > > -----Original Message----- > > > From: Zanussi, Tom > > > Sent: Thursday, July 19, 2012 8:57 AM > > > To: Kamble, Nitin A > > > Cc: yocto@yoctoproject.org; bruce.ashfi...@windriver.com > > > Subject: RE: [PATCH 0/1] meta: update crownbay.scc for newer emgd > > > driver > > > > > > On Wed, 2012-07-18 at 19:58 -0700, Kamble, Nitin A wrote: > > > > > > > > > -----Original Message----- > > > > > From: Zanussi, Tom > > > > > Sent: Wednesday, July 18, 2012 7:43 PM > > > > > To: Kamble, Nitin A > > > > > Cc: yocto@yoctoproject.org; bruce.ashfi...@windriver.com > > > > > Subject: Re: [PATCH 0/1] meta: update crownbay.scc for newer > > > > > emgd driver > > > > > > > > > > On Mon, 2012-07-16 at 22:57 -0700, nitin.a.kam...@intel.com wrote: > > > > > > From: Nitin A Kamble <nitin.a.kam...@intel.com> > > > > > > > > > > > > This commit changes emgd kernel driver for crownbay bsp to the > > > > > > emgd- > > > > > 1.14. > > > > > > > > > > > > > > > > Nitin, > > > > > > > > > > Doesn't switching this over in the kenrnel require emgd-1.14 > > > > > userspace recipe updates to work? Did I miss those? > > > > > > > > > > Tom > > > > > > > > > Tom, > > > > I am holding the emgd 1.14 userspace commits until the kernel > > > > repository > > > change goes upstream. The kernel recipe will need new SRCREV (with > > > emgd > > > 1.14 kernel parts) for the user level emgd 1.14 parts to work. And > > > that dependency will get satisfied once this commit is in. > > > > > > > > > > Yeah, I understand, the crownbay is typically the most complicated > > > update for all of those reasons - simultaneous new kernel > > > version/recipe, new emgd branch, and new emgd userspace recipe all at > the same time. > > > > > > In the past I've submitted them all at the same time for > > > simultaneous review and some coordination with Bruce - once the > > > kernel parts are in, the kernel recipe and the userspace parts can > > > then be pulled in along with a simple follow-on patch to update the > SRCREVs Bruce give us. > > > > > > The thing is that if Bruce pulls in the patch to switch to emgd-1.14 > > > and only at that point do you post the userspace recipe, and it ends > > > up needing some rework, in the meantime the graphics remain > > > non-functional (I know, they already are, thanks to the package > > > re-ordering patches breaking the current recipe, but hopefully the > > > 1.14 changes will be in and we don't have to worry about it any more.). > > > > > > Does that make sense, and can you just post the userspace and kernel > > > recipe parts before we give Bruce the go-ahead in making the kernel > > > changes? (I'd also like to try it out myself as well...). > > > > > Tom, > > Until the crownbay bsp's Linux-yocto kernel recipe's meta SRCREV is > updated, these kernel repo changes have no effect in the build process. > Right ? So as I see, this commit does not make anything worst (or better). > > I am sending the userland recipe commits anyway; So that you can also test > it out. > > > > Right, but what if we have to update the meta SRCREV for a different reason > in the meantime (like we did last week for instance). We're then forced to > take the emgd commit as well.
I see the issue now. And I don't see a perfect solution to the issue. Because of commits in two different repos there always going to be this kind of a sync issue. The best is pull the commits in both repositories at the same time. Thanks, Nitin > > In any case, it's your BSP so it's up to you how you want to manage it, I'm > just > trying to save you and the users some headaches. It always made sense to > me to do it all at the same time, all else being equal... > > Tom > > > > > Thanks, > > Nitin > > > > > > > _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto