[yocto] [meta-mono] [PATCH 1/1] gtk-sharp: Updated to GTK# 2.12.21

[Paul Eggleton]

On Thursday 27 February 2014 18:18:29 Paul Eggleton wrote:
> On Thursday 27 February 2014 17:32:29 Alex J Lennon wrote:
> > On 27/02/2014 17:09, Paul Eggleton wrote:
> > > On Thursday 27 February 2014 08:30:10 Khem Raj wrote:
> > >> On Feb 27, 2014, at 7:59 AM, Alex J Lennon
> > >> <ajlennon at dynamicdevices.co.uk>
> > >> 
> > >> wrote:
> > >>> On 27/02/2014 15:50, Khem Raj wrote:
> > >>>       > On Feb 27, 2014, at 6:16 AM, Alex J Lennon
> > >>>       
> > >>>       <ajlennon at dynamicdevices.co.uk> wrote:
> > >>>       >> +PR = "r1"
> > >>>       >> 
> > >>>       >> +
> > >>>       > 
> > >>>       > get rid of that
> > >>> 
> > >>> Why is that Khem?
> > >> 
> > >> we have automatic PR server now a days, its enabled by default.
> > > 
> > > FWIW, I don't think it's enabled by default, at least not in
> > > OE-Core/Poky.
> > > The point still stands though, it's the way PR should be managed rather
> > > than manual bumping.
> > 
> > <googling/> Are we talking about the "network based PR service"?
> 
> Yes, see:
> 
>  http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#working
> -with-a-pr-service
> > Is this a single globally available nework service or a service that's
> > intended to be running local to a specific build farm?
> 
> Specific build farm; it may be made externally accessible if necessary
> however.
> 
> > My reading of the wiki page seems to imply it's intended to be local to
> > a build farm, or system, rather than globally unique?
> 
> PR values needn't match up between different distros. The point is they
> should get increased when a material change to the recipe's output happens;
> and this can happen for example when:
> 
> * A class that the recipe inherits is changed
> 
> * A dependency of the recipe that influences how the recipe is built gets
> changed
> 
> * Some global configuration changed that affects how the recipe is built
> e.g. DISTRO_FEATURES
> 
> * A bbappend is added or removed
> 
> In all of these cases the recipe itself does not get changed at all - prior
> to the PR server we had to remember to manually bump PR in the affected
> recipes, or (more often) we'd forget to handle it properly altogether. With
> the PR server, PR bumps happen automatically in response to signatures
> changing, which is about as accurate an indicator as we can get as far as
> determining whether the output has changed, and certainly much less prone
> to mistakes.
> > So if I'm releasing packages to production this now becomes a critical
> > part of my infrastructure as I'll lose all my package revisions if
> > something goes wrong with it?
> 
> Yes. Luckily it's not a particularly complicated piece of software; the only
> extra thing you need to preserve is the sqlite database that contains the
> hashes and corresponding PR values.
> 
> > And my packages will have different revisions from somebody elses's
> > packages when they are running their own network based PR service?
> 
> Yes. If bbappends were involved all bets were off prior to the PR service
> anyway since they were supposed to modify PR.
> 
> > I suppose the other question is, if I release a package of revision X,
> > then another which is up-rev'd' to Y as I made a change to the recipe
> > and so the NBPRS up-revs, then somebody comes back to me and tells me
> > they are having a problem with Xm then how do I link that rev X to the
> > specific commit that went to build it so I can audit ?
> 
> The PR server doesn't track this - however, all of this information does go
> into buildhistory if you enable that.
> 
> > I haven't enabled this here, so does that mean all my package revisions
> > will be r0 as I remove the PR variables from recipes ?
> 
> We're not talking about dropping all PR values in existing recipes, we're
> talking about dropping them on upgrade (i.e. when PV changes), where
> previously we'd have done that anyway or set them to "r0".

I should point out also in case it's not obvious - you only really need to 
care about this if you enable the packaging system on the target (i.e. 
"package-management" is in IMAGE_FEATURES).

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre