update canutils to current version

update canutils to current version

[Vitus Jensen]

The following patches will update canutils to the current version
4.0.6 and remove older 4.0.x versions.  Also only the latest
version of libsocketcan will be kept.

[PATCH 1/3] canutils: remove old version 4.0.4

[Vitus Jensen]

Signed-off-by: Vitus Jensen <vjensen@gmx.de>
---
 recipes/socketcan/canutils_4.0.4.bb |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)
 delete mode 100644 recipes/socketcan/canutils_4.0.4.bb

diff --git a/recipes/socketcan/canutils_4.0.4.bb b/recipes/socketcan/canutils_4.0.4.bb
deleted file mode 100644
index 9ddb697..0000000
--- a/recipes/socketcan/canutils_4.0.4.bb
+++ /dev/null
@@ -1,4 +0,0 @@
-TAG = "canutils-${PV}"
-require canutils.inc
-
-PR = "${INC_PR}.0"
-- 
1.7.1

[PATCH 2/3] libsocketcan: remove old version 0.0.7

[Vitus Jensen]

Signed-off-by: Vitus Jensen <vjensen@gmx.de>
---
 recipes/socketcan/libsocketcan_0.0.7.bb |    7 -------
 1 files changed, 0 insertions(+), 7 deletions(-)
 delete mode 100644 recipes/socketcan/libsocketcan_0.0.7.bb

diff --git a/recipes/socketcan/libsocketcan_0.0.7.bb b/recipes/socketcan/libsocketcan_0.0.7.bb
deleted file mode 100644
index 18f607e..0000000
--- a/recipes/socketcan/libsocketcan_0.0.7.bb
+++ /dev/null
@@ -1,7 +0,0 @@
-TAG = "v${PV}"
-require libsocketcan.inc
-
-PR = "${INC_PR}.0"
-
-SRC_URI += "file://install-can_netlink.h.patch;apply=yes \
-	"
-- 
1.7.1

[PATCH 3/3] canutils: update to version 4.0.6

[Vitus Jensen]

Signed-off-by: Vitus Jensen <vjensen@gmx.de>
---
 recipes/socketcan/canutils_4.0.5.bb |    4 ----
 recipes/socketcan/canutils_4.0.6.bb |    4 ++++
 2 files changed, 4 insertions(+), 4 deletions(-)
 delete mode 100644 recipes/socketcan/canutils_4.0.5.bb
 create mode 100644 recipes/socketcan/canutils_4.0.6.bb

diff --git a/recipes/socketcan/canutils_4.0.5.bb b/recipes/socketcan/canutils_4.0.5.bb
deleted file mode 100644
index c084bcd..0000000
--- a/recipes/socketcan/canutils_4.0.5.bb
+++ /dev/null
@@ -1,4 +0,0 @@
-TAG = "v${PV}"
-require canutils.inc
-
-PR = "${INC_PR}.0"
diff --git a/recipes/socketcan/canutils_4.0.6.bb b/recipes/socketcan/canutils_4.0.6.bb
new file mode 100644
index 0000000..9ddb697
--- /dev/null
+++ b/recipes/socketcan/canutils_4.0.6.bb
@@ -0,0 +1,4 @@
+TAG = "canutils-${PV}"
+require canutils.inc
+
+PR = "${INC_PR}.0"
-- 
1.7.1

Re: [PATCH 1/3] canutils: remove old version 4.0.4

[Frans Meulenbroeks]

2010/8/13 Vitus Jensen <vjensen@gmx.de>:
>
> Signed-off-by: Vitus Jensen <vjensen@gmx.de>
> ---
>  recipes/socketcan/canutils_4.0.4.bb |    4 ----
>  1 files changed, 0 insertions(+), 4 deletions(-)
>  delete mode 100644 recipes/socketcan/canutils_4.0.4.bb
>
> diff --git a/recipes/socketcan/canutils_4.0.4.bb b/recipes/socketcan/canutils_4.0.4.bb
> deleted file mode 100644
> index 9ddb697..0000000
> --- a/recipes/socketcan/canutils_4.0.4.bb
> +++ /dev/null
> @@ -1,4 +0,0 @@
> -TAG = "canutils-${PV}"
> -require canutils.inc
> -
> -PR = "${INC_PR}.0"
> --
> 1.7.1
>
Acked-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>

Re: [PATCH 2/3] libsocketcan: remove old version 0.0.7

[Frans Meulenbroeks]

2010/8/13 Vitus Jensen <vjensen@gmx.de>:
>
> Signed-off-by: Vitus Jensen <vjensen@gmx.de>
> ---
>  recipes/socketcan/libsocketcan_0.0.7.bb |    7 -------
>  1 files changed, 0 insertions(+), 7 deletions(-)
>  delete mode 100644 recipes/socketcan/libsocketcan_0.0.7.bb
>
> diff --git a/recipes/socketcan/libsocketcan_0.0.7.bb b/recipes/socketcan/libsocketcan_0.0.7.bb
> deleted file mode 100644
> index 18f607e..0000000
> --- a/recipes/socketcan/libsocketcan_0.0.7.bb
> +++ /dev/null
> @@ -1,7 +0,0 @@
> -TAG = "v${PV}"
> -require libsocketcan.inc
> -
> -PR = "${INC_PR}.0"
> -
> -SRC_URI += "file://install-can_netlink.h.patch;apply=yes \
> -       "
> --
Acked-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>

Re: [PATCH 3/3] canutils: update to version 4.0.6

[Frans Meulenbroeks]

2010/8/13 Vitus Jensen <vjensen@gmx.de>:
>
> Signed-off-by: Vitus Jensen <vjensen@gmx.de>
> ---
>  recipes/socketcan/canutils_4.0.5.bb |    4 ----
>  recipes/socketcan/canutils_4.0.6.bb |    4 ++++
>  2 files changed, 4 insertions(+), 4 deletions(-)
>  delete mode 100644 recipes/socketcan/canutils_4.0.5.bb
>  create mode 100644 recipes/socketcan/canutils_4.0.6.bb
>
> diff --git a/recipes/socketcan/canutils_4.0.5.bb b/recipes/socketcan/canutils_4.0.5.bb
> deleted file mode 100644
> index c084bcd..0000000
> --- a/recipes/socketcan/canutils_4.0.5.bb
> +++ /dev/null
> @@ -1,4 +0,0 @@
> -TAG = "v${PV}"
> -require canutils.inc
> -
> -PR = "${INC_PR}.0"
> diff --git a/recipes/socketcan/canutils_4.0.6.bb b/recipes/socketcan/canutils_4.0.6.bb
> new file mode 100644
> index 0000000..9ddb697
> --- /dev/null
> +++ b/recipes/socketcan/canutils_4.0.6.bb
> @@ -0,0 +1,4 @@
> +TAG = "canutils-${PV}"
> +require canutils.inc
> +
> +PR = "${INC_PR}.0"
> --
Acked-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>

Re: update canutils to current version

[Vitus Jensen]

On Fri, 13 Aug 2010, Vitus Jensen wrote:

> The following patches will update canutils to the current version
> 4.0.6 and remove older 4.0.x versions.  Also only the latest
> version of libsocketcan will be kept.

Frans, thank you for the ACKs.  Could you please apply the patches, too? 
I have no right to do so.

Vitus

-- 
Vitus Jensen, Hannover, Germany, Universe (current)
pgp public key available from keyservers

Re: update canutils to current version

[Frans Meulenbroeks]

2010/8/13 Vitus Jensen <vjensen@gmx.de>:
> On Fri, 13 Aug 2010, Vitus Jensen wrote:
>
>> The following patches will update canutils to the current version
>> 4.0.6 and remove older 4.0.x versions.  Also only the latest
>> version of libsocketcan will be kept.
>
> Frans, thank you for the ACKs.  Could you please apply the patches, too? I
> have no right to do so.


Applied. Thanks for the contribution

System guru's: Vitus's patches did not show up in patchwork

Frans

Re: update canutils to current version

[Vitus Jensen]

On Fri, 13 Aug 2010, Frans Meulenbroeks wrote:

> 2010/8/13 Vitus Jensen <vjensen@gmx.de>:
>> On Fri, 13 Aug 2010, Vitus Jensen wrote:
>>
>>> The following patches will update canutils to the current version
>>> 4.0.6 and remove older 4.0.x versions.  Also only the latest
>>> version of libsocketcan will be kept.
>>
>> Frans, thank you for the ACKs.  Could you please apply the patches, too? I
>> have no right to do so.
>
> Applied. Thanks for the contribution
>
> System guru's: Vitus's patches did not show up in patchwork

They did.  But after you posted you ACKs I changed their state to 
"Accepted" and then they are usually filtered by "Action Required".  I'm 
not really sure I did the right thing but I don't believe they shouldn't 
remain in "New".

http://wiki.openembedded.net/index.php/Patchwork doesn't describe states, 
only that you should change them :(

Vitus

-- 
Vitus Jensen, Hannover, Germany, Universe (current)
pgp public key available from keyservers

Re: update canutils to current version

[Frans Meulenbroeks]

2010/8/13 Vitus Jensen <vjensen@gmx.de>:
> On Fri, 13 Aug 2010, Frans Meulenbroeks wrote:
>
>> 2010/8/13 Vitus Jensen <vjensen@gmx.de>:
>>>
>>> On Fri, 13 Aug 2010, Vitus Jensen wrote:
>>>
>>>> The following patches will update canutils to the current version
>>>> 4.0.6 and remove older 4.0.x versions.  Also only the latest
>>>> version of libsocketcan will be kept.
>>>
>>> Frans, thank you for the ACKs.  Could you please apply the patches, too?
>>> I
>>> have no right to do so.
>>
>> Applied. Thanks for the contribution
>>
>> System guru's: Vitus's patches did not show up in patchwork
>
> They did.  But after you posted you ACKs I changed their state to "Accepted"
> and then they are usually filtered by "Action Required".  I'm not really
> sure I did the right thing but I don't believe they shouldn't remain in
> "New".
>
> http://wiki.openembedded.net/index.php/Patchwork doesn't describe states,
> only that you should change them :(
>
> Vitus
>
Ah ok. Actually I only peeked at the new ones.
Most people tend not to change the patchwork values so I didn't think
of looking at the other states
and I use patchwork to download the patches, much simpler than getting
them from gmail.

Wrt the states: that is indeed not too clear. I always have doubts
what I should to with the archived checkbox.

Anyway, your changes are in, so please change the state in patchwork
from Accepted to Applied.

Frans

Re: update canutils to current version

[Khem Raj]

On Fri, Aug 13, 2010 at 2:59 AM, Vitus Jensen <vjensen@gmx.de> wrote:
> On Fri, 13 Aug 2010, Frans Meulenbroeks wrote:
>
>> 2010/8/13 Vitus Jensen <vjensen@gmx.de>:
>>>
>>> On Fri, 13 Aug 2010, Vitus Jensen wrote:
>>>
>>>> The following patches will update canutils to the current version
>>>> 4.0.6 and remove older 4.0.x versions.  Also only the latest
>>>> version of libsocketcan will be kept.
>>>
>>> Frans, thank you for the ACKs.  Could you please apply the patches, too?
>>> I
>>> have no right to do so.
>>
>> Applied. Thanks for the contribution
>>
>> System guru's: Vitus's patches did not show up in patchwork
>
> They did.  But after you posted you ACKs I changed their state to "Accepted"
> and then they are usually filtered by "Action Required".  I'm not really
> sure I did the right thing but I don't believe they shouldn't remain in
> "New".

If they got applied change the state to 'applied'
>
> http://wiki.openembedded.net/index.php/Patchwork doesn't describe states,
> only that you should change them :(
>
> Vitus
>
> --
> Vitus Jensen, Hannover, Germany, Universe (current)
> pgp public key available from keyservers
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: update canutils to current version

[Vitus Jensen]

On Fri, 13 Aug 2010, Khem Raj wrote:

> On Fri, Aug 13, 2010 at 2:59 AM, Vitus Jensen <vjensen@gmx.de> wrote:
>> On Fri, 13 Aug 2010, Frans Meulenbroeks wrote:
>>> 2010/8/13 Vitus Jensen <vjensen@gmx.de>:
>>>> On Fri, 13 Aug 2010, Vitus Jensen wrote:
>>>>
>>>>> The following patches will update canutils to the current version
>>>>> 4.0.6 and remove older 4.0.x versions.  Also only the latest
>>>>> version of libsocketcan will be kept.
>>>>
>>>> Frans, thank you for the ACKs.  Could you please apply the patches, 
>>>> too? I have no right to do so.
>>>
>>> Applied. Thanks for the contribution
>>>
>>> System guru's: Vitus's patches did not show up in patchwork
>>
>> They did.  But after you posted you ACKs I changed their state to "Accepted"
>> and then they are usually filtered by "Action Required".  I'm not really
>> sure I did the right thing but I don't believe they shouldn't remain in
>> "New".
>
> If they got applied change the state to 'applied'

Sure, already did!  Do I set the 'archive' bit, too?


Frans got hit by the fact, that 'accepted' patches don't show up in the 
list by default.

Vitus posts patches
Frans acks patches
Vitus changes state to 'accepted'
Vitus asks Frans to apply
Frans: where are those patches in patchwork???
Frans forces his googlemail to produce usable mail and applies
Vitus changes state to 'applied'

Probably I should update the wiki to document the above procedure, right?

Vitus

-- 
Vitus Jensen, Hannover, Germany, Universe (current)
pgp public key available from keyservers

patch queue/patchwork: How should states be used? (was: update canutils to current version)

[Paul Menzel]

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

Am Freitag, den 13.08.2010, 23:01 +0200 schrieb Vitus Jensen:
> On Fri, 13 Aug 2010, Khem Raj wrote:
> > On Fri, Aug 13, 2010 at 2:59 AM, Vitus Jensen <vjensen@gmx.de> wrote:

[…]

> >> They did.  But after you posted you ACKs I changed their state to "Accepted"
> >> and then they are usually filtered by "Action Required".  I'm not really
> >> sure I did the right thing but I don't believe they shouldn't remain in
> >> "New".
> >
> > If they got applied change the state to 'applied'
> 
> Sure, already did!  Do I set the 'archive' bit, too?

I think so. Yes.

> Frans got hit by the fact, that 'accepted' patches don't show up in the 
> list by default.
> 
> Vitus posts patches
> Frans acks patches
> Vitus changes state to 'accepted'
> Vitus asks Frans to apply
> Frans: where are those patches in patchwork???
> Frans forces his googlemail to produce usable mail and applies
> Vitus changes state to 'applied'

I would also advise to set the commit ID when setting the state to
applied. Actually this can be done automatically [2], but the
administrators have not yet had time to address this.

We have the following 11 states.

        $ pwclient state
        ID    Name
        --    ----
        1     New
        2     Under Review
        3     Accepted
        4     Rejected
        5     RFC
        6     Not Applicable
        7     Changes Requested
        8     Awaiting Upstream
        9     Superseded
        10    Deferred
        11    Applied

What is the difference between 3 (Accepted) and 8 (Awaiting Upstream)?

> Probably I should update the wiki [1] to document the above procedure, right?

That would be great. But before there should be reached a little
consensus to save you some unnecessary work.

I guess the accepted state is too much work and could be skipped?

+ Normally people reviewing and acknowledging patches have commit access
and will do this shortly afterward.
- People with commit access not searching the list and just looking at
the patch queue would see that those patches have been reviewed and
acknowledged and could commit these patches.

I do not know if we already have some people taking care of the patch
queue. If there are such folks, they should voice their opinion what
they prefer.


Thanks,

Paul


[1] http://wiki.openembedded.net/index.php/Patchwork
[2] http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-August/022588.html

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: update canutils to current version

[Frans Meulenbroeks]

2010/8/13 Vitus Jensen <vjensen@gmx.de>:
> On Fri, 13 Aug 2010, Khem Raj wrote:
>
>> On Fri, Aug 13, 2010 at 2:59 AM, Vitus Jensen <vjensen@gmx.de> wrote:
>>>
>>> On Fri, 13 Aug 2010, Frans Meulenbroeks wrote:
>>>>
>>>> 2010/8/13 Vitus Jensen <vjensen@gmx.de>:
>>>>>
>>>>> On Fri, 13 Aug 2010, Vitus Jensen wrote:
>>>>>
>>>>>> The following patches will update canutils to the current version
>>>>>> 4.0.6 and remove older 4.0.x versions.  Also only the latest
>>>>>> version of libsocketcan will be kept.
>>>>>
>>>>> Frans, thank you for the ACKs.  Could you please apply the patches,
>>>>> too? I have no right to do so.
>>>>
>>>> Applied. Thanks for the contribution
>>>>
>>>> System guru's: Vitus's patches did not show up in patchwork
>>>
>>> They did.  But after you posted you ACKs I changed their state to
>>> "Accepted"
>>> and then they are usually filtered by "Action Required".  I'm not really
>>> sure I did the right thing but I don't believe they shouldn't remain in
>>> "New".
>>
>> If they got applied change the state to 'applied'
>
> Sure, already did!  Do I set the 'archive' bit, too?
>
>
> Frans got hit by the fact, that 'accepted' patches don't show up in the list
> by default.
>
> Vitus posts patches
> Frans acks patches
> Vitus changes state to 'accepted'
> Vitus asks Frans to apply
> Frans: where are those patches in patchwork???
> Frans forces his googlemail to produce usable mail and applies
> Vitus changes state to 'applied'
>
> Probably I should update the wiki to document the above procedure, right?
>

I saw a different thread from Paul on patchwork.
Let's discuss this  in that thread.


Frans

Re: patch queue/patchwork: How should states be used? (was: update canutils to current version)

[Frans Meulenbroeks]

2010/8/13 Paul Menzel <paulepanter@users.sourceforge.net>:
> Am Freitag, den 13.08.2010, 23:01 +0200 schrieb Vitus Jensen:
>> On Fri, 13 Aug 2010, Khem Raj wrote:
>> > On Fri, Aug 13, 2010 at 2:59 AM, Vitus Jensen <vjensen@gmx.de> wrote:
>
> […]
>
>> >> They did.  But after you posted you ACKs I changed their state to "Accepted"
>> >> and then they are usually filtered by "Action Required".  I'm not really
>> >> sure I did the right thing but I don't believe they shouldn't remain in
>> >> "New".
>> >
>> > If they got applied change the state to 'applied'
>>
>> Sure, already did!  Do I set the 'archive' bit, too?
>
> I think so. Yes.
>
>> Frans got hit by the fact, that 'accepted' patches don't show up in the
>> list by default.
>>
>> Vitus posts patches
>> Frans acks patches
>> Vitus changes state to 'accepted'
>> Vitus asks Frans to apply
>> Frans: where are those patches in patchwork???
>> Frans forces his googlemail to produce usable mail and applies
>> Vitus changes state to 'applied'
>
> I would also advise to set the commit ID when setting the state to
> applied. Actually this can be done automatically [2], but the
> administrators have not yet had time to address this.
>
> We have the following 11 states.
>
>        $ pwclient state
>        ID    Name
>        --    ----
>        1     New
>        2     Under Review
>        3     Accepted
>        4     Rejected
>        5     RFC
>        6     Not Applicable
>        7     Changes Requested
>        8     Awaiting Upstream
>        9     Superseded
>        10    Deferred
>        11    Applied
>
> What is the difference between 3 (Accepted) and 8 (Awaiting Upstream)?

I'd say awaiting upstream would be a situation where the patch has
been submitted upstream (e.g. for gcc to the gcc devs) and we're
waiting for their reaction.
But that is just my guess.
>
>> Probably I should update the wiki [1] to document the above procedure, right?
>
> That would be great. But before there should be reached a little
> consensus to save you some unnecessary work.
>
> I guess the accepted state is too much work and could be skipped?
>
> + Normally people reviewing and acknowledging patches have commit access
> and will do this shortly afterward.
> - People with commit access not searching the list and just looking at
> the patch queue would see that those patches have been reviewed and
> acknowledged and could commit these patches.

Typically if I see something pass by that is straightforward (like the
patches from Vitus) and I have the time and my tree is in a state that
I can easily apply it, I take the patch and push it (after reviewing).
The rule I apply on myself is: if it is something that I woud push
myself without further review (e.g. a single recipe like the canbus
ones), I take it and push it and update patchwork. That is after
testing that the recipe builds.
so the workflow here is:

if it is a patch in an area I do not understand I'll skip it.
otherwise:

review patch. if ok and it is a simple patch
download patch from patchwork in mbox fmt
git am patch
bitbake recipe
if ok, git push.

if the patch is not ok, I inform the poster. I hardly ever repair things myself.
I'd rather educate people to do things the proper way.

And if the patch is complicated (e.g. affects the toolchain) I also
review and if possibly try then ack (or nak).

But sometimes I am not in a position to push (e..g because my system
or me is too busy with something else, or because my tree has too much
changes on it or is not up to date and cannot be updated)
In that case I tend to ack (and I might pick it up later) This is what
happened with vitus'  recipe.

>
> I do not know if we already have some people taking care of the patch
> queue. If there are such folks, they should voice their opinion what
> they prefer.

I feel taking in and handling patches is partly an orphaned process.
If a patch is submitted by someone with commit access for reveiw,
typically that person will follow up on it.
If it is e.g. a new recipe or in an area that is not really taken care
of by someone, it is sheer luck if someone picks it up.
I feel recipe maintainers could be useful here.

(btw recipe maintainers could also be useful when it comes to handling
bug reports in bugzilla).


Frans

Re: patch queue/patchwork: How should states be used? (was: update canutils to current version)

[Martin Jansa]

On Sat, Aug 14, 2010 at 09:59:59AM +0200, Frans Meulenbroeks wrote:
> review patch. if ok and it is a simple patch
> download patch from patchwork in mbox fmt
> git am patch
> bitbake recipe
> if ok, git push.

check contrib/patchwork/pw-am.sh to simplify steps 2 and 3.

Regards,
-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

Re: patch queue/patchwork: How should states be used?

[Vitus Jensen]

On Fri, 13 Aug 2010, Paul Menzel wrote:
> Am Freitag, den 13.08.2010, 23:01 +0200 schrieb Vitus Jensen:
>> On Fri, 13 Aug 2010, Khem Raj wrote:
>>> On Fri, Aug 13, 2010 at 2:59 AM, Vitus Jensen <vjensen@gmx.de> wrote:
>
>
> I would also advise to set the commit ID when setting the state to
> applied. Actually this can be done automatically [2], but the
> administrators have not yet had time to address this.

This requires the pwclient script which people without commit access 
probably don't use.  Well, I don't use it.


> We have the following 11 states.
>
>        $ pwclient state
>        ID    Name
>        --    ----
>        1     New
>        2     Under Review
>        3     Accepted
>        4     Rejected
>        5     RFC
>        6     Not Applicable
>        7     Changes Requested
>        8     Awaiting Upstream
>        9     Superseded
>        10    Deferred
>        11    Applied
>
> What is the difference between 3 (Accepted) and 8 (Awaiting Upstream)?

In which state should the "Archived" flag be set?  What is the effect of 
that flag?  And do we really need all those states?  Rejected, Not 
Applicable, Changes Requested, Deferred?  IMHO that's Rejected, refer to 
the mail archive for details.

BTW: who removes patches from patchwork?  I do have some patches in 
"Superseded" state which I no longer care about.

Vitus

-- 
Vitus Jensen, Hannover, Germany, Universe (current)
pgp public key available from keyservers

Re: patch queue/patchwork: How should states be used?

[Frans Meulenbroeks]

2010/9/7 Vitus Jensen <vjensen@gmx.de>:

>
> BTW: who removes patches from patchwork?  I do have some patches in
> "Superseded" state which I no longer care about.

You can do that yourself. If I recall correctly it requires that you
create an account on patchwork with the same email address as the
patches come from.

Frans