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

[Alex J Lennon <ajlennon@dynamicdevices.co.uk>]

[-- Attachment #1: Type: text/plain, Size: 5983 bytes --]


On 27/02/2014 18:18, 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@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@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
>  

OK thanks for this, it's very useful.


>> 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.

OK so I can't download the source code to a distribution and built
identical, identically
versioned packages to theirs? With something like RPM wouldn't I expect
to be able to
download an RPM source package and build an identical, versioned RPM
from it?

As a minimum my package revision naming will be different from the
upstream distro
presumably?

Taking a slightly different tack, if I upgrade a recipe PV from 1.0.0 to
2.0.0 to correspond
to the upstream source versioning, and at that time I remove PR and
build some packages.

Then a month later I realise I need something extra added to the
configuration options,
which gives me a different output, what do I change to make sure the new
package is
versioned differently from the old package? (i.e. presumably if the
network service is
running it will handle it for me, but if it's not running then new
package will be versioned
identically to my old package?)

Thanks, Alex

>> 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.

Must look at that, yes.

>> 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".
>
> Cheers,
> Paul
>

-- 

Dynamic Devices Ltd <http://www.dynamicdevices.co.uk/>

Alex J Lennon / Director
1 Queensway, Liverpool L22 4RA

mobile: +44 (0)7956 668178

Linkedin <http://www.linkedin.com/in/alexjlennon> Skype
<skype:alexjlennon?add>

This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended
recipient(s). Any unauthorized disclosure, dissemination, distribution,
copying or the taking of any action in reliance on the information
herein is prohibited. E-mails are not secure and cannot be guaranteed to
be error free as they can be intercepted, amended, or contain viruses.
Anyone who communicates with us by e-mail is deemed to have accepted
these risks. Company Name is not responsible for errors or omissions in
this message and denies any responsibility for any damage arising from
the use of e-mail. Any opinion and other statement contained in this
message and any attachment are solely those of the author and do not
necessarily represent those of the company.


[-- Attachment #2.1: Type: text/html, Size: 10261 bytes --]

[-- Attachment #2.2: ddlogo-4.png --]
[-- Type: image/png, Size: 3997 bytes --]

[-- Attachment #2.3: linkedin.png --]
[-- Type: image/png, Size: 631 bytes --]

[-- Attachment #2.4: skype.png --]
[-- Type: image/png, Size: 800 bytes --]