On Wed, Dec 05, 2012 at 03:19:53PM +0000, Richard Purdie wrote: > On Wed, 2012-12-05 at 15:45 +0100, Martin Jansa wrote: > > On Wed, Dec 05, 2012 at 02:13:59PM +0000, Richard Purdie wrote: > > > I've made it clear we want and need to switch to the PR service for > > > handling PR bumps. I'd now like to put a deadline in place for doing > > > this, namely that I'm going to stop requiring PR bumps in patches as of > > > 1 week's time. The TSC did discuss this and our conclusion was that we > > > need to switch early in this release cycle to give time for any issues > > > to get resolved. Now is a good time to do this as I think we're ready. > > > > > > There were a number of open bugs related to the PR service[1]. We've > > > looked through them and they are now resolved with the exception of one > > > related to the incremental git PV issue for which we have a plan in > > > place and patches ready. > > > > > > We've taken on board feedback about documentation and the following wiki > > > page has been setup which details the current situation: > > > > > > https://wiki.yoctoproject.org/wiki/PR_Service > > > > > > I appreciate this is going to be a disruptive change for some but I > > > believe it is in the best interests of the project longer term and that > > > we will have a better system as an end result of this. If people do run > > > into problems, please send email or file bugs. I'm trying to ensure > > > there are some people with time available to look into these issues as a > > > priority so we can make a smooth transition. > > > > After reading this wiki page I have few questions (I admit I haven't > > tried it yet). > > > > 1) How do you limit access to shared prserv instance? > > Can you define some group as RO, some RW? > > For RO access it would be great to export state from remote PRSERV > > on first connection and then continue to increment locally (with > > PRSERV running on localhost) > > This isn't implemented as things stand. As you point out, a true RO > connection causes problems... > > > 2) If you have slightly different builder (e.g. someone with extra BSP > > or different host distro), then he will have different checksums, so > > different AUTOPR values and you cannot share binary feed with such > > builder, right? I know this wasn't possible (or at least safe) to use > > before too. But it should be more clear from documentation. > > If the extra BSP uses its own package_arch it would probably be ok, > otherwise not. The host distro only affects native/cross packages and > not the checksum itself so again, that should also be ok? > > > 3) Is it possible to use OEBasic together with PRSERV or should bitbake > > show fatal error when PRSERV is used toghether with OEBasic? > > > Added to the page: "The service works with both OEBasic and OEBasicHash > generators, with the understanding that PR bumps happen when the > checksum changes and the different generator mechanisms change > signatures under different circumstances." > > > 4) Is there plan to import current PR values from recipes, so that > > bitbake can parse all enabled layers, gather checksum-PR values and > > export it for bitbake-prserv-tool to import it as inital state? > > 5) Is there plan to remove PR from all recipes or are they ignored with > > PRSERV in use and can stay in for some time? If there is functionality > > for 4) then we should tag all layers just before PR/PRINC are removed, > > so someone can create own initial export from last known PR state. > > Added to the page: "As implemented, values from the PR service are > included into the PR field as an addition of the form ".X" so r0 becomes > r0.1, r0.2 and so on. This allows existing PR values to be used for > whatever reasons allowing manual PR bumps should it be necessary." > > (should cover both questions) > > As for removing PR, as recipes are upgraded, I'm expecting we will > remove PR values so we should get a smooth transition. We can still have > PR values, it will just become an exception rather than the rule.
So default "hidden" r0 is still used in such cases and PRSERV adds again just .X. Thanks for answers. -- Martin 'JaMa' Jansa jabber: [email protected]
signature.asc
Description: Digital signature
_______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
