[meta-ti] [PATCH] libdrm: Add GLSDK specific staging tree for omap-a15

Denys Dmytriyenko denys at ti.com
Sun Jun 30 21:51:46 PDT 2013

On Fri, Jun 28, 2013 at 07:25:04AM -0400, Maupin, Chase wrote:
> >> Well, if every time you update SRCREV you also increment the
> >first letter, it
> >> will work as expected - so the comment is kind of correct... :)
> >>
> >
> >Right, I just followed the existing kernel recipes for convention.
> >Would
> >the convention change between a kernel recipe (like
> >recipes-kernel/linux/linux-ti-staging_3.8.bb) where we have both
> >and the first letter, compared to userspace recipes which point to
> >git
> >trees for versions?
> The kernel ones were to append the MACHINE_KERNEL_PR that was set with the 
> letter.  The SRCPV use was also nice to make it easier to know which 
> commitid was being used during the kernel build.
> >>> That being said if you were going to overlay this recipe the PR
> >should be
> >>> something like
> >>>
> >>> PR = "${INC_PR}.0"
> >>>
> >>> Right now you are appending to the default since PR is not
> >defined.  With a
> >>> bbappend you should append a -arago flag.
> >>>
> >>> So this comes back to why no bbappend?  Is it because the base
> >version in
> >>> oe-core is 2.4.39 and not 2.4.41?  Can you not append the _git
> >version of
> >>> the recipe and update the PV appropriately?
> >>>
> >
> >That's also possible but the question I have is what's the
> >preferred
> >convention?
> >
> >All the GLSDK trees are on git. The choice really is between
> >having a
> >since .bbappend for each of the trees with an explicit PV and bump
> >the
> >PV everytime we update to latest on upstream *OR* have a recipe
> >for the
> >version and submit a new recipe when we update to latest.
> >
> >I can submit a v2 once I understand the expected convention to be
> >followed.
> I get your point on clarity so I'm OK with a version specific addition.  You 
> may have answered this before but what is the difference between your libdrm 
> and the libdrm upstream?  Are your patches going upstream to the main libdrm 
> so that going forward you can drop this recipe for a new version?
> Denys, refresh my memory if we are doing a version but we are also changing 
> things in our trees don't we normally do this as something like ti-libdrm 
> and set the PROVIDES, etc for libdrm?  This was to distinguish between 
> libdrv 2.4.41 for example and what TI is calling 2.4.41 right?  Or do you 
> just want to do 2.4.41+?  What is your preferrence?

>From my past discussions with Nicolas, TI's libdrm is quite close to the 
upstream and the patches are meant to be upstreamed eventually. So, 
technically it's not a complete fork and having a full replacement like 
ti-libdrm is not really necessary here. I'm fine with providing own 
libdrm-2.4.41 recipe for now.


More information about the meta-ti mailing list