Patchwork [v2,04/15] file: replace obsolete automake macros with working ones

login
register
mail settings
Submitter Marko Lindqvist
Date Jan. 6, 2013, 11:49 p.m.
Message ID <1357516181-5358-5-git-send-email-cazfi74@gmail.com>
Download mbox | patch
Permalink /patch/42115/
State New
Headers show

Comments

Marko Lindqvist - Jan. 6, 2013, 11:49 p.m.
Add obsolete-automake-macros.patch that replaces automake macros
no longer supported by automake-1.13 with modern constructs.

Signed-off-by: Marko Lindqvist <cazfi74@gmail.com>
---
 .../file/file/obsolete_automake_macros.patch            |   15 +++++++++++++++
 meta/recipes-devtools/file/file_5.11.bb                 |    3 ++-
 2 files changed, 17 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-devtools/file/file/obsolete_automake_macros.patch
Richard Purdie - Jan. 7, 2013, 11:59 a.m.
On Mon, 2013-01-07 at 01:49 +0200, Marko Lindqvist wrote:
> Add obsolete-automake-macros.patch that replaces automake macros
> no longer supported by automake-1.13 with modern constructs.
> 
> Signed-off-by: Marko Lindqvist <cazfi74@gmail.com>
> ---
>  .../file/file/obsolete_automake_macros.patch            |   15 +++++++++++++++
>  meta/recipes-devtools/file/file_5.11.bb                 |    3 ++-
>  2 files changed, 17 insertions(+), 1 deletion(-)
>  create mode 100644 meta/recipes-devtools/file/file/obsolete_automake_macros.patch
> 
> diff --git a/meta/recipes-devtools/file/file/obsolete_automake_macros.patch b/meta/recipes-devtools/file/file/obsolete_automake_macros.patch
> new file mode 100644
> index 0000000..8b0d34c
> --- /dev/null
> +++ b/meta/recipes-devtools/file/file/obsolete_automake_macros.patch
> @@ -0,0 +1,15 @@
> +Upstream-Status: Fixed in file-5.12

Can we use a standard syntax for this, something like:

Upstream-Status: Backport (fixed in file-5.12)

(as mentioned in
https://wiki.yoctoproject.org/wiki/Contribution_Guidelines#Patch_Header_Recommendations)

for the same reasons as I just mentioned to Marcin - so we can tell from
scripts what status patches have and it helps reviewers in future know
this can be dropped. The aim is to push patches upstream and standard
syntax means we can get real numbers for how many patches we're
carrying.

I appreciate you can read and tell from the above what it means but I
really want to try and use a consistent syntax.

Cheers,

Richard
Marko Lindqvist - Jan. 7, 2013, 12:11 p.m.
On 7 January 2013 13:59, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Mon, 2013-01-07 at 01:49 +0200, Marko Lindqvist wrote:
>> Add obsolete-automake-macros.patch that replaces automake macros
>> no longer supported by automake-1.13 with modern constructs.
>>
>> Signed-off-by: Marko Lindqvist <cazfi74@gmail.com>
>> ---
>>  .../file/file/obsolete_automake_macros.patch            |   15 +++++++++++++++
>>  meta/recipes-devtools/file/file_5.11.bb                 |    3 ++-
>>  2 files changed, 17 insertions(+), 1 deletion(-)
>>  create mode 100644 meta/recipes-devtools/file/file/obsolete_automake_macros.patch
>>
>> diff --git a/meta/recipes-devtools/file/file/obsolete_automake_macros.patch b/meta/recipes-devtools/file/file/obsolete_automake_macros.patch
>> new file mode 100644
>> index 0000000..8b0d34c
>> --- /dev/null
>> +++ b/meta/recipes-devtools/file/file/obsolete_automake_macros.patch
>> @@ -0,0 +1,15 @@
>> +Upstream-Status: Fixed in file-5.12
>
> Can we use a standard syntax for this, something like:
>
> Upstream-Status: Backport (fixed in file-5.12)
>
> (as mentioned in
> https://wiki.yoctoproject.org/wiki/Contribution_Guidelines#Patch_Header_Recommendations)

  What's the correct status for fixes that are not really backports,
but have happened independently in oe and upstream?
 - If practically identical, still mark as "Backport"?
 - If different solution, "Inappropriate [not needed]"?


 - ML
Ross Burton - Jan. 7, 2013, 12:16 p.m.
On 7 January 2013 12:11, Marko Lindqvist <cazfi74@gmail.com> wrote:
> What's the correct status for fixes that are not really backports,
> but have happened independently in oe and upstream?
>  - If practically identical, still mark as "Backport"?
>  - If different solution, "Inappropriate [not needed]"?

If you did it and then later discovered it's happened upstream
independently, it's essentially a backport.

Ross
Otavio Salvador - Jan. 7, 2013, 12:18 p.m.
On Mon, Jan 7, 2013 at 10:16 AM, Burton, Ross <ross.burton@intel.com> wrote:
> On 7 January 2013 12:11, Marko Lindqvist <cazfi74@gmail.com> wrote:
>> What's the correct status for fixes that are not really backports,
>> but have happened independently in oe and upstream?
>>  - If practically identical, still mark as "Backport"?
>>  - If different solution, "Inappropriate [not needed]"?
>
> If you did it and then later discovered it's happened upstream
> independently, it's essentially a backport.

Maybe it'd be better to not patch at all and update to the newer recipe version?

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
Richard Purdie - Jan. 7, 2013, 1:46 p.m.
On Mon, 2013-01-07 at 10:18 -0200, Otavio Salvador wrote:
> On Mon, Jan 7, 2013 at 10:16 AM, Burton, Ross <ross.burton@intel.com> wrote:
> > On 7 January 2013 12:11, Marko Lindqvist <cazfi74@gmail.com> wrote:
> >> What's the correct status for fixes that are not really backports,
> >> but have happened independently in oe and upstream?
> >>  - If practically identical, still mark as "Backport"?
> >>  - If different solution, "Inappropriate [not needed]"?
> >
> > If you did it and then later discovered it's happened upstream
> > independently, it's essentially a backport.

The best thing is to consider how we use the information. I'd happily
accept "Backport" in this case as meaning "the upstream latest version
has equivalent functionality". You can note the status after the word to
give specifics if needed.

> Maybe it'd be better to not patch at all and update to the newer 
> recipe version?

I don't think that is a reasonable policy in all cases. I'm not going to
block automake on all upstreams making new releases for example.

Cheers,

Richard
Otavio Salvador - Jan. 7, 2013, 3:58 p.m.
On Mon, Jan 7, 2013 at 11:46 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Mon, 2013-01-07 at 10:18 -0200, Otavio Salvador wrote:
>> On Mon, Jan 7, 2013 at 10:16 AM, Burton, Ross <ross.burton@intel.com> wrote:
>> > On 7 January 2013 12:11, Marko Lindqvist <cazfi74@gmail.com> wrote:
>> >> What's the correct status for fixes that are not really backports,
>> >> but have happened independently in oe and upstream?
>> >>  - If practically identical, still mark as "Backport"?
>> >>  - If different solution, "Inappropriate [not needed]"?
>> >
>> > If you did it and then later discovered it's happened upstream
>> > independently, it's essentially a backport.
>
> The best thing is to consider how we use the information. I'd happily
> accept "Backport" in this case as meaning "the upstream latest version
> has equivalent functionality". You can note the status after the word to
> give specifics if needed.
>
>> Maybe it'd be better to not patch at all and update to the newer
>> recipe version?
>
> I don't think that is a reasonable policy in all cases. I'm not going to
> block automake on all upstreams making new releases for example.

Sure but if there're a new release with the fix it is better to
upgrade than backport the fix (with exceptions, of course).

My point is: it is good to verify if there're a new release and use it
if possible. Otherwise backport the fix.

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
Marko Lindqvist - Jan. 7, 2013, 4:26 p.m.
On 7 January 2013 17:58, Otavio Salvador <otavio@ossystems.com.br> wrote:
> On Mon, Jan 7, 2013 at 11:46 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>> On Mon, 2013-01-07 at 10:18 -0200, Otavio Salvador wrote:
>>> On Mon, Jan 7, 2013 at 10:16 AM, Burton, Ross <ross.burton@intel.com> wrote:
>>> > On 7 January 2013 12:11, Marko Lindqvist <cazfi74@gmail.com> wrote:
>>> >> What's the correct status for fixes that are not really backports,
>>> >> but have happened independently in oe and upstream?
>>> >>  - If practically identical, still mark as "Backport"?
>>> >>  - If different solution, "Inappropriate [not needed]"?
>>> >
>>> > If you did it and then later discovered it's happened upstream
>>> > independently, it's essentially a backport.
>>
>> The best thing is to consider how we use the information. I'd happily
>> accept "Backport" in this case as meaning "the upstream latest version
>> has equivalent functionality". You can note the status after the word to
>> give specifics if needed.
>>
>>> Maybe it'd be better to not patch at all and update to the newer
>>> recipe version?
>>
>> I don't think that is a reasonable policy in all cases. I'm not going to
>> block automake on all upstreams making new releases for example.
>
> Sure but if there're a new release with the fix it is better to
> upgrade than backport the fix (with exceptions, of course).
>
> My point is: it is good to verify if there're a new release and use it
> if possible. Otherwise backport the fix.

 That's what I'm being doing. Even if new upstream release doesn't
have fix for the particular problem, I try to update to it first.
Rationale being that if update is going to happen at some point
anyway, it's less work to do it without need to update the bugfix to
apply to new version. That is: total work of "update + fix" vs "fix +
update + port the fix".


 - ML

Patch

diff --git a/meta/recipes-devtools/file/file/obsolete_automake_macros.patch b/meta/recipes-devtools/file/file/obsolete_automake_macros.patch
new file mode 100644
index 0000000..8b0d34c
--- /dev/null
+++ b/meta/recipes-devtools/file/file/obsolete_automake_macros.patch
@@ -0,0 +1,15 @@ 
+Upstream-Status: Fixed in file-5.12
+
+Signed-off-by: Marko Lindqvist <cazfi74@gmail.com>
+diff -Nurd file-5.11/configure.ac file-5.11/configure.ac
+--- file-5.11/configure.ac	2012-02-21 21:16:29.000000000 +0200
++++ file-5.11/configure.ac	2013-01-02 07:18:23.004856505 +0200
+@@ -3,7 +3,7 @@
+ AM_INIT_AUTOMAKE()
+ m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])])
+
+-AM_CONFIG_HEADER(config.h)
++AC_CONFIG_HEADERS(config.h)
+ AC_CONFIG_MACRO_DIR([m4])
+
+ AC_MSG_CHECKING(for builtin ELF support)
diff --git a/meta/recipes-devtools/file/file_5.11.bb b/meta/recipes-devtools/file/file_5.11.bb
index be6a863..52ae460 100644
--- a/meta/recipes-devtools/file/file_5.11.bb
+++ b/meta/recipes-devtools/file/file_5.11.bb
@@ -10,10 +10,11 @@  LIC_FILES_CHKSUM = "file://COPYING;beginline=2;md5=6a7382872edb68d33e1a9398b6e03
 
 DEPENDS = "zlib file-native"
 DEPENDS_class-native = "zlib-native"
-PR = "r0"
+PR = "r1"
 
 SRC_URI = "ftp://ftp.astron.com/pub/file/file-${PV}.tar.gz \
            file://fix_version_check.patch \
+           file://obsolete_automake_macros.patch \
            file://dump \
            file://filesystems"