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

[Alex J Lennon]

On 27/02/2014 18:48, Paul Eggleton wrote:
> On Thursday 27 February 2014 18:29:59 Alex J Lennon wrote:
>> On 27/02/2014 18:18, Paul Eggleton wrote:
>>> 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?
> They'll always be "identical" as far as the material content goes, that's not
> in question here - we're just talking about the PR values. For the PR values
> it depends - which distro are we talking about? IIRC for example, SHR and
> Angstrom both make their PR servers available so that people's PR values
> will match up if they build it from source themselves.
>
> However, I think we're starting to head into territory where you have to
> ask who is maintaining this distro you are referring to. If you're making
> changes to how things get built, arguably it's now a derivative distro
> and you ought to be maintaining it yourself; at which point you shouldn't
> expect the PR values to match up. How else would you signify that you'd
> made the configuration change (or added your own patch, or ...) if it's
> someone else's distro that doesn't contain that change "upstream"?
>
>> 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?)
> Yes. If you care about PR values (i.e. you're using packaging on the
> target) then you need to enable and use the PR server. If you do that,
> you don't need to make any additional change other than the
> configure option change you've already made - EXTRA_OECONF
> would presumably have been changed -> do_configure signature
> changes -> dependent task signatures change -> the PR value
> changes automatically.

OK thanks. I best get it switched on then :)

>>>> 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.
> For reference:
>
> http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#maintaining-build-output-quality

Thanks

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20140227/bdf3375c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ddlogo-4.png
Type: image/png
Size: 3997 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20140227/bdf3375c/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linkedin.png
Type: image/png
Size: 631 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20140227/bdf3375c/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: skype.png
Type: image/png
Size: 800 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20140227/bdf3375c/attachment-0002.png>