[STABLE][PATCH v2] mingw-binutils: update to 2.19.1

[STABLE][PATCH v2] mingw-binutils: update to 2.19.1

[Esben Haabendal]

Signed-off-by: Esben Haabendal <eha@doredevelopment.dk>
---
 conf/checksums.ini                                 |    3 +++
 .../mingw-binutils-canadian-cross_2.19.1.bb        |   10 ++++++++++
 recipes/binutils/mingw-binutils_2.19.1.bb          |   12 ++++++++++++
 3 files changed, 25 insertions(+), 0 deletions(-)
 create mode 100644 recipes/binutils/mingw-binutils-canadian-cross_2.19.1.bb
 create mode 100644 recipes/binutils/mingw-binutils_2.19.1.bb

diff --git a/conf/checksums.ini b/conf/checksums.ini
index 2a119dd..20dc248 100644
--- a/conf/checksums.ini
+++ b/conf/checksums.ini
@@ -26886,3 +26886,6 @@
sha256=f57c4e33eb2cdd87a6c2f01bfa4794340fbe61ea1a1cfc7dac3b6671e1dd22af
 md5=5f7b88ebb2bcd7e8044328482d079661
 sha256=f57c4e33eb2cdd87a6c2f01bfa4794340fbe61ea1a1cfc7dac3b6671e1dd22af

+[http://downloads.sourceforge.net/mingw/binutils-2.19.1-src.tar.gz]
+md5=ad3f2b5fdcd599a772ad75fec2c384d8
+sha256=2df529b1ac0a621efb87b5b53dbc0167c566f8bebbd6a8ce19964b05845fd2e7
diff --git a/recipes/binutils/mingw-binutils-canadian-cross_2.19.1.bb
b/recipes/binutils/mingw-binutils-canadian-cross_2.19.1.bb
new file mode 100644
index 0000000..130dea5
--- /dev/null
+++ b/recipes/binutils/mingw-binutils-canadian-cross_2.19.1.bb
@@ -0,0 +1,10 @@
+require mingw-binutils_${PV}.bb
+require binutils-canadian-cross.inc
+
+DEFAULT_PREFERENCE_sdk-mingw32 = "1"
+
+require binutils-canadian-cross.inc
+
+SRC_URI = "${SOURCEFORGE_MIRROR}/mingw/binutils-${PV}-src.tar.gz"
+
+S = "${WORKDIR}/binutils-${PV}"
diff --git a/recipes/binutils/mingw-binutils_2.19.1.bb
b/recipes/binutils/mingw-binutils_2.19.1.bb
new file mode 100644
index 0000000..19d1077
--- /dev/null
+++ b/recipes/binutils/mingw-binutils_2.19.1.bb
@@ -0,0 +1,12 @@
+PR = "r1"
+
+require binutils.inc
+
+DESCRIPTION = "A GNU collection of binary utilities - MinGW port"
+HOMEPAGE = "http://www.mingw.org/"
+
+SRC_URI = "${SOURCEFORGE_MIRROR}/mingw/binutils-${PV}-src.tar.gz"
+
+S = "${WORKDIR}/binutils-${PV}"
+
+DEFAULT_PREFERENCE = "0"
-- 
1.6.2.2

Re: [STABLE][PATCH v2] mingw-binutils: update to 2.19.1

[Esben Haabendal]

I have now tested it with org.openembedded.dev branch, and this patch
should be applied there also.

/Esben

Re: [STABLE][PATCH v2] mingw-binutils: update to 2.19.1

[Tom Rini]

On Tue, Apr 07, 2009 at 09:16:28AM +0200, Esben Haabendal wrote:

[snip]
> +[http://downloads.sourceforge.net/mingw/binutils-2.19.1-src.tar.gz]
> +md5=ad3f2b5fdcd599a772ad75fec2c384d8
> +sha256=2df529b1ac0a621efb87b5b53dbc0167c566f8bebbd6a8ce19964b05845fd2e7

You need to run the 'contrib/source-checker/oe-checksums-sorter.py'
after adding a new checksum.  Roughly
/contrib/source-checker/oe-checksums-sorter.py conf/checksums.ini > t &&
mv t conf/checksums.ini.

> diff --git a/recipes/binutils/mingw-binutils-canadian-cross_2.19.1.bb
> b/recipes/binutils/mingw-binutils-canadian-cross_2.19.1.bb
> new file mode 100644
> index 0000000..130dea5
> --- /dev/null
> +++ b/recipes/binutils/mingw-binutils-canadian-cross_2.19.1.bb
> @@ -0,0 +1,10 @@
> +require mingw-binutils_${PV}.bb
> +require binutils-canadian-cross.inc
> +
> +DEFAULT_PREFERENCE_sdk-mingw32 = "1"

This should just be DEFAULT_PREFERENCE_mingw32 = "1".  Or just left out
as we aren't setting this to -1 for anything else.

> diff --git a/recipes/binutils/mingw-binutils_2.19.1.bb
> b/recipes/binutils/mingw-binutils_2.19.1.bb
> new file mode 100644
> index 0000000..19d1077
> --- /dev/null
> +++ b/recipes/binutils/mingw-binutils_2.19.1.bb
> @@ -0,0 +1,12 @@
> +PR = "r1"

First PR should be r0, and the PR line left out in this case.  This also
looks a whole lot like the older one, so perhaps the best thing to do
here would be to rename the old one to mingw-binutils.inc and just
include that in mingw-binutils_version.bb (which iirc does need to
exist).

> +DEFAULT_PREFERENCE = "0"

Then drop this, or set to -1.  I forget off the top of my head if
something will go wrong and try and use this for non-canadian stuff if
we don't have a -1 here..

Finally, the way Stable works, as I read it, is that the patch goes into
dev first then stable.  Not at the same time.

-- 
Tom Rini

Re: [STABLE][PATCH v2] mingw-binutils: update to 2.19.1

[Esben Haabendal]

On Tue, Apr 7, 2009 at 6:51 PM, Tom Rini <trini@kernel.crashing.org> wrote:
> On Tue, Apr 07, 2009 at 09:16:28AM +0200, Esben Haabendal wrote:
>
> [snip]
>> +[http://downloads.sourceforge.net/mingw/binutils-2.19.1-src.tar.gz]
>> +md5=ad3f2b5fdcd599a772ad75fec2c384d8
>> +sha256=2df529b1ac0a621efb87b5b53dbc0167c566f8bebbd6a8ce19964b05845fd2e7
>
> You need to run the 'contrib/source-checker/oe-checksums-sorter.py'
> after adding a new checksum.  Roughly
> /contrib/source-checker/oe-checksums-sorter.py conf/checksums.ini > t &&
> mv t conf/checksums.ini.

Ok.

>> diff --git a/recipes/binutils/mingw-binutils-canadian-cross_2.19.1.bb
>> b/recipes/binutils/mingw-binutils-canadian-cross_2.19.1.bb
>> new file mode 100644
>> index 0000000..130dea5
>> --- /dev/null
>> +++ b/recipes/binutils/mingw-binutils-canadian-cross_2.19.1.bb
>> @@ -0,0 +1,10 @@
>> +require mingw-binutils_${PV}.bb
>> +require binutils-canadian-cross.inc
>> +
>> +DEFAULT_PREFERENCE_sdk-mingw32 = "1"
>
> This should just be DEFAULT_PREFERENCE_mingw32 = "1".  Or just left out
> as we aren't setting this to -1 for anything else.

Well, as you suggest later on, I have now set DEFAULT_PREFERENCE to
-1, so I will be keeping in this, but of-course using _mingw32 instead
of the (now) defunct _sdk-mingw32

>> diff --git a/recipes/binutils/mingw-binutils_2.19.1.bb
>> b/recipes/binutils/mingw-binutils_2.19.1.bb
>> new file mode 100644
>> index 0000000..19d1077
>> --- /dev/null
>> +++ b/recipes/binutils/mingw-binutils_2.19.1.bb
>> @@ -0,0 +1,12 @@
>> +PR = "r1"
>
> First PR should be r0, and the PR line left out in this case.

Ok, I failed to find any information on this earlier.

So I just decided, based on what I think would make sense, that the first
version shoul dbe r1, and r0 being left as an indication that no PR
were set.

> This also
> looks a whole lot like the older one, so perhaps the best thing to do
> here would be to rename the old one to mingw-binutils.inc and just
> include that in mingw-binutils_version.bb (which iirc does need to
> exist).

Well, it looks a lot like, but is not identical.
But I've created a common mingw-binutils.inc, and require'd this by the two
mingw-binutils_version.bb files.

>> +DEFAULT_PREFERENCE = "0"
>
> Then drop this, or set to -1.  I forget off the top of my head if
> something will go wrong and try and use this for non-canadian stuff if
> we don't have a -1 here..

I will not guarantee that that it won't go wrong and use this for anything
else than MinGW canadian stuff, and as such, it seems really silly
to risk fucking up things just to save a few bytes in a recipe.

> Finally, the way Stable works, as I read it, is that the patch goes into
> dev first then stable.  Not at the same time.

Ok.

Then, please someone apply this to .dev.  But then how are we supposed
to remember which patches should also be moved to stable, and when?

Let's not make it to complicated to maintain stable, so that it will die
from us again :-(

Of-course, this approach will not work generally, as .dev will and must
diverge from stable, and more and more fixes will be specific to stable.

/Esben

Re: [STABLE][PATCH v2] mingw-binutils: update to 2.19.1

[Koen Kooi]

On 08-04-09 16:16, Esben Haabendal wrote:

> Then, please someone apply this to .dev.  But then how are we supposed
> to remember which patches should also be moved to stable, and when?

If you want something in stable, you send the patch to this mailinglist 
with [STABLE] in the subject. That way it will show up here:

http://patchwork.openembedded.org/project/openembedded/list/?state=*&q=oe%2CSTABLE

or for a complete historic view:

http://patchwork.openembedded.org/project/openembedded/list/?q=oe,STABLE&archive=both&state=*

> Let's not make it to complicated to maintain stable, so that it will die
> from us again :-(

Stuff needs to get into .dev first to receive wider testing. Putting 
stuff directly in stable negates the idea of the stable branch.

regards,

Koen

Re: [STABLE][PATCH v2] mingw-binutils: update to 2.19.1

[Esben Haabendal]

On Wed, Apr 8, 2009 at 4:26 PM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
> On 08-04-09 16:16, Esben Haabendal wrote:
>
>> Then, please someone apply this to .dev.  But then how are we supposed
>> to remember which patches should also be moved to stable, and when?
>
> If you want something in stable, you send the patch to this mailinglist with
> [STABLE] in the subject.

Which is exactly what I did.  Now 3 times even.

> That way it will show up here:
>
> http://patchwork.openembedded.org/project/openembedded/list/?state=*&q=oe%2CSTABLE
>
> or for a complete historic view:
>
> http://patchwork.openembedded.org/project/openembedded/list/?q=oe,STABLE&archive=both&state=*
>
>> Let's not make it to complicated to maintain stable, so that it will die
>> from us again :-(
>
> Stuff needs to get into .dev first to receive wider testing. Putting stuff
> directly in stable negates the idea of the stable branch.

Naturally, but (2 but's):

1. When .dev is sufficiently different from stable, some fixes needed
for stable will not make sense or work on .dev, so this rule will have
to be bent once in a while, and most likely, more often when
stable/2009 gets old.

2. There must be a some sensible elastic, as straight out simple fixes
IMHO, could just go in both at the same time.  But I guess, my opinion
on this matter does not really matter.

It is quite impressive how difficult it can be made to submit what is
mainly just a copy action of a file...

/Esben

Re: [STABLE][PATCH v2] mingw-binutils: update to 2.19.1

[Koen Kooi]

On 08-04-09 18:52, Esben Haabendal wrote:

> It is quite impressive how difficult it can be made to submit what is
> mainly just a copy action of a file...

That's misleading since we have lots of crappy files that should have a 
minefield around them to stop people from copying them :)

regards,

Koen

Re: [STABLE][PATCH v2] mingw-binutils: update to 2.19.1

[Philip Balister]

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

Esben Haabendal wrote:
> On Wed, Apr 8, 2009 at 4:26 PM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
>> On 08-04-09 16:16, Esben Haabendal wrote:
>>
>>> Then, please someone apply this to .dev.  But then how are we supposed
>>> to remember which patches should also be moved to stable, and when?
>> If you want something in stable, you send the patch to this mailinglist with
>> [STABLE] in the subject.
> 
> Which is exactly what I did.  Now 3 times even.

I suspect the problem is most of the people interested in stable do not 
know what this patch does. I admit to skimming over things that look 
like patches to pieces of OE that I know little about.

Still, we need a way to get this sort of thing into stable, even when it 
is outside the scope of most of the reviewers.

The good news is the queue of stuff to go into stable is not growing out 
of control, but we need to work out a solution to deal with "orphaned" 
patches.

Philip


> 
>> That way it will show up here:
>>
>> http://patchwork.openembedded.org/project/openembedded/list/?state=*&q=oe%2CSTABLE
>>
>> or for a complete historic view:
>>
>> http://patchwork.openembedded.org/project/openembedded/list/?q=oe,STABLE&archive=both&state=*
>>
>>> Let's not make it to complicated to maintain stable, so that it will die
>>> from us again :-(
>> Stuff needs to get into .dev first to receive wider testing. Putting stuff
>> directly in stable negates the idea of the stable branch.
> 
> Naturally, but (2 but's):
> 
> 1. When .dev is sufficiently different from stable, some fixes needed
> for stable will not make sense or work on .dev, so this rule will have
> to be bent once in a while, and most likely, more often when
> stable/2009 gets old.
> 
> 2. There must be a some sensible elastic, as straight out simple fixes
> IMHO, could just go in both at the same time.  But I guess, my opinion
> on this matter does not really matter.
> 
> It is quite impressive how difficult it can be made to submit what is
> mainly just a copy action of a file...
> 
> /Esben
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: [STABLE][PATCH v2] mingw-binutils: update to 2.19.1

[Tom Rini]

On Wed, Apr 08, 2009 at 01:38:39PM -0400, Philip Balister wrote:
> Esben Haabendal wrote:
>> On Wed, Apr 8, 2009 at 4:26 PM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
>>> On 08-04-09 16:16, Esben Haabendal wrote:
>>>
>>>> Then, please someone apply this to .dev.  But then how are we supposed
>>>> to remember which patches should also be moved to stable, and when?
>>> If you want something in stable, you send the patch to this mailinglist with
>>> [STABLE] in the subject.
>>
>> Which is exactly what I did.  Now 3 times even.
>
> I suspect the problem is most of the people interested in stable do not  
> know what this patch does. I admit to skimming over things that look  
> like patches to pieces of OE that I know little about.
>
> Still, we need a way to get this sort of thing into stable, even when it  
> is outside the scope of most of the reviewers.

Hang on.  I (the guy signed up to own this part of stable) have reviewed
it each time.  The problem is there's been both general little problems
and Esben has wanted the patch to go in both trees at once, which isn't
how I understand Stable to work.

My plan right now is to fixup the still minor problems in v3 and post
for stable momentarily.

-- 
Tom Rini

Re: [STABLE][PATCH v2] mingw-binutils: update to 2.19.1

[Esben Haabendal]

On Wed, Apr 8, 2009 at 7:50 PM, Tom Rini <trini@kernel.crashing.org> wrote:
> On Wed, Apr 08, 2009 at 01:38:39PM -0400, Philip Balister wrote:
>> Esben Haabendal wrote:
>>> On Wed, Apr 8, 2009 at 4:26 PM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
>>>> On 08-04-09 16:16, Esben Haabendal wrote:
>>>>
>>>>> Then, please someone apply this to .dev.  But then how are we supposed
>>>>> to remember which patches should also be moved to stable, and when?
>>>> If you want something in stable, you send the patch to this mailinglist with
>>>> [STABLE] in the subject.
>>>
>>> Which is exactly what I did.  Now 3 times even.
>>
>> I suspect the problem is most of the people interested in stable do not
>> know what this patch does. I admit to skimming over things that look
>> like patches to pieces of OE that I know little about.
>>
>> Still, we need a way to get this sort of thing into stable, even when it
>> is outside the scope of most of the reviewers.
>
> Hang on.  I (the guy signed up to own this part of stable) have reviewed
> it each time.  The problem is there's been both general little problems
> and Esben has wanted the patch to go in both trees at once, which isn't
> how I understand Stable to work.
>
> My plan right now is to fixup the still minor problems in v3 and post
> for stable momentarily.

That is fine.  And it is also good that we improve the quality of the
metadata when changing stuff.
But it is just surprising that when I copy an existing recipe file to
add a new version, it gives rise to so much need for improvement.
The existing file were committed by yourself, although it originates
from my canadian sdk work, but I maybe we could use time a bit more
efficient than nitpicking to much on selected commit(ter)s. That said,
it is always nice to have the best possible end result :-)

/Esben

Re: [STABLE][PATCH v2] mingw-binutils: update to 2.19.1

[Esben Haabendal]

On Wed, Apr 8, 2009 at 7:50 PM, Tom Rini <trini@kernel.crashing.org> wrote:
> Hang on.  I (the guy signed up to own this part of stable) have reviewed
> it each time.  The problem is there's been both general little problems
> and Esben has wanted the patch to go in both trees at once, which isn't
> how I understand Stable to work.

I don't seem to be able to find this policy described.  At least not on
http://wiki.openembedded.net/index.php/Stable

If this is an important rule for how to submit patches to stable, it would
really be nice to have it stated quite clearly.

Perhaps a small checklist to use before comitting to stable. Something
about remembering to test if it can build, have it tested in .dev
first, format the patch properly, use a proper subject string, and so
on.

/Esben
-- 
Esben Haabendal, Senior Software Consultant
DoréDevelopment ApS, Ved Stranden 1, 9560 Hadsund, DK-Denmark
Phone: +45 51 92 53 93, E-mail: eha@doredevelopment.dk
WWW: http://www.doredevelopment.dk

Re: [STABLE][PATCH v2] mingw-binutils: update to 2.19.1

[Tom Rini]

On Wed, Apr 08, 2009 at 08:02:59PM +0200, Esben Haabendal wrote:
[snip]
> That is fine.  And it is also good that we improve the quality of the
> metadata when changing stuff.
> But it is just surprising that when I copy an existing recipe file to
> add a new version, it gives rise to so much need for improvement.
> The existing file were committed by yourself, although it originates
> from my canadian sdk work, but I maybe we could use time a bit more
> efficient than nitpicking to much on selected commit(ter)s. That said,
> it is always nice to have the best possible end result :-)

Yes.  Just trying to stop minor mistakes from getting repeated (and
cleaned up instead).  This is now in .dev and I just posted what I
pushed for review in stable.

-- 
Tom Rini