package/libva: Bump version to 1.4.0

PATCH New Bernd Kuhls 3 participants 7 messages Oct 6, 2014 – Oct 7, 2014

lore

Share & tools

lore

Bernd Kuhls

author

2014-10-06 19:28 UTC #0 lore raw

PATCH 1/3 package/libva: Bump version to 1.4.0

Signed-off-by Bernd Kuhls <[email protected]>

---
 package/libva/libva.mk |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

package/libva/libva.mk +1 -1

index 857cb17..984222d 100644
@@ -4,7 +4,7 @@
 #
 ################################################################################
 
-LIBVA_VERSION = 1.3.1
+LIBVA_VERSION = 1.4.0
 LIBVA_SOURCE = libva-$(LIBVA_VERSION).tar.bz2
 LIBVA_SITE = http://www.freedesktop.org/software/vaapi/releases/libva
 LIBVA_LICENSE = MIT

Signature · 1 line

1.7.10.4

Bernd Kuhls

author

2014-10-06 19:28 UTC #1 lore raw

PATCH 2/3 package/libva-intel-driver: Bump version to 1.4.0

Signed-off-by Bernd Kuhls <[email protected]>

---
 package/libva-intel-driver/libva-intel-driver.mk |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

package/libva-intel-driver/libva-intel-driver.mk +1 -1

index b717e29..5aed95b 100644
@@ -4,7 +4,7 @@
 #
 ################################################################################
 
-LIBVA_INTEL_DRIVER_VERSION = 1.3.2
+LIBVA_INTEL_DRIVER_VERSION = 1.4.0
 LIBVA_INTEL_DRIVER_SOURCE = libva-intel-driver-$(LIBVA_INTEL_DRIVER_VERSION).tar.bz2
 LIBVA_INTEL_DRIVER_SITE = http://www.freedesktop.org/software/vaapi/releases/libva-intel-driver
 LIBVA_INTEL_DRIVER_LICENSE = MIT

Signature · 1 line

1.7.10.4

Bernd Kuhls

author

2014-10-06 19:28 UTC #2 lore raw

PATCH 3/3 package/ffmpeg: Bump version to 2.4.2

In reply to Bernd Kuhls

removed ffmpeg-0002-arm4-arm5.patch, applied upstream

Signed-off-by Bernd Kuhls <[email protected]>

---
 package/ffmpeg/ffmpeg-0002-arm4-arm5.patch |   85 ----------------------------
 package/ffmpeg/ffmpeg.mk                   |    2 +-
 2 files changed, 1 insertion(+), 86 deletions(-)
 delete mode 100644 package/ffmpeg/ffmpeg-0002-arm4-arm5.patch

package/ffmpeg/ffmpeg-0002-arm4-arm5.patch deleted +0 ~~-85~~

deleted file mode 100644
index 5a0147f..0000000
@@ -1,85 +0,0 @@
-Fix compile error on arm4/arm5 platform
-
-Patch merged upstream:
-http://git.videolan.org/?p=ffmpeg.git;a=commit;h=6b733be755529f2472472d9ed1b2eef3b6398828
-
-Signed-off-by: Bernd Kuhls <[email protected]>
-
-From fe0f39e7263cd95783ad4669f8c3672a8eab4c83 Mon Sep 17 00:00:00 2001
-From: Bernd Kuhls <[email protected]>
-Date: Tue, 23 Sep 2014 20:06:26 +0200
-Subject: [PATCH 1/1] Fix compile error on arm4/arm5 platform
-
-Since these commits
-http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=adf8227cf4e7b4fccb2ad88e1e09b6dc00dd00ed
-http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=db7f1c7c5a1d37e7f4da64a79a97bea1c4b6e9f8
-
-compilation on arm4/arm5 fails:
-
-libavcodec/libavcodec.so: undefined reference to
-`ff_startcode_find_candidate_armv6'
-
-Because libavcodec/arm/Makefile contains
-ARMV6-OBJS-$(CONFIG_STARTCODE)         += arm/startcode_armv6.o
-function ff_startcode_find_candidate_armv6 is not included for older ARM
-archs. The bug was found during automatic buildroot builds:
-
-http://autobuild.buildroot.net/results/ec7/ec71e4f16ee9106747dff5f15999cbd17903e76f//build-end.log
-Quote from configure summary:
-ARCH                      arm (armv4t)
-big-endian                no
-runtime cpu detection     yes
-ARMv5TE enabled           no
-ARMv6 enabled             no
-ARMv6T2 enabled           no
-
-http://autobuild.buildroot.net/results/be7/be72eb182eaccf0064a32c9dfc2ac1c0d6555506/build-end.log
-ARCH                      arm (armv5te)
-big-endian                no
-runtime cpu detection     yes
-ARMv5TE enabled           yes
-ARMv6 enabled             no
-ARMv6T2 enabled           no
-
-This patch provides the necessary #if clauses as discussed with Michael:
-https://ffmpeg.org/pipermail/ffmpeg-devel/2014-September/163329.html
-
-Signed-off-by: Bernd Kuhls <[email protected]>
----
- libavcodec/arm/h264dsp_init_arm.c |    2 ++
- libavcodec/arm/vc1dsp_init_arm.c  |    2 ++
- 2 files changed, 4 insertions(+)
-
-diff --git a/libavcodec/arm/h264dsp_init_arm.c b/libavcodec/arm/h264dsp_init_arm.c
-index f7aee1f..88dfd75 100644
---- a/libavcodec/arm/h264dsp_init_arm.c
-+++ b/libavcodec/arm/h264dsp_init_arm.c
-@@ -107,8 +107,10 @@ av_cold void ff_h264dsp_init_arm(H264DSPContext *c, const int bit_depth,
- {
-     int cpu_flags = av_get_cpu_flags();
- 
-+#if HAVE_ARMV6
-     if (have_setend(cpu_flags))
-         c->startcode_find_candidate = ff_startcode_find_candidate_armv6;
-+#endif
-     if (have_neon(cpu_flags))
-         h264dsp_init_neon(c, bit_depth, chroma_format_idc);
- }
-diff --git a/libavcodec/arm/vc1dsp_init_arm.c b/libavcodec/arm/vc1dsp_init_arm.c
-index 9dae22c..5f2c759 100644
---- a/libavcodec/arm/vc1dsp_init_arm.c
-+++ b/libavcodec/arm/vc1dsp_init_arm.c
-@@ -28,8 +28,10 @@ av_cold void ff_vc1dsp_init_arm(VC1DSPContext *dsp)
- {
-     int cpu_flags = av_get_cpu_flags();
- 
-+#if HAVE_ARMV6
-     if (have_setend(cpu_flags))
-         dsp->startcode_find_candidate = ff_startcode_find_candidate_armv6;
-+#endif
-     if (have_neon(cpu_flags))
-         ff_vc1dsp_init_neon(dsp);
- }
--- 
-1.7.10.4
-

package/ffmpeg/ffmpeg.mk +1 -1

index 41b06a7..1af47a6 100644
@@ -4,7 +4,7 @@
 #
 ################################################################################
 
-FFMPEG_VERSION = 2.4.1
+FFMPEG_VERSION = 2.4.2
 FFMPEG_SOURCE = ffmpeg-$(FFMPEG_VERSION).tar.bz2
 FFMPEG_SITE = http://ffmpeg.org/releases
 FFMPEG_INSTALL_STAGING = YES

Signature · 1 line

1.7.10.4

Peter Korsgaard

2014-10-07 20:32 UTC #3 lore raw

PATCH 1/3 package/libva: Bump version to 1.4.0

In reply to Bernd Kuhls

Quoted 3 lines

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Bernd" == Bernd Kuhls <[email protected]> writes:
Signed-off-by Bernd Kuhls <[email protected]>

Committed all 3, thanks. For future patches, it would be good if you would add the tarball hashes as the libva* release announcements had them (I've added them now).

Signature · 1 line

Bye, Peter Korsgaard

Bernd Kuhls

author

2014-10-07 20:58 UTC #4 lore raw

PATCH 1/3 package/libva: Bump version to 1.4.0

Peter Korsgaard <[email protected]> wrote in
news:87ppe3fwnn.fsf at dell.be.48ers.dk:

Quoted 3 lines

Committed all 3, thanks. For future patches, it would be good if you would add the tarball hashes as the libva* release announcements had them (I've added them now).

Hi,

ok, I will do so.

Until now I did not really bother for my non-security-related packages because I remembered the commit description
http://git.buildroot.net/buildroot/commit/support/download/check-hash?id=
9bd8b59526c4521879f0ae5f765cb1a748725c49 where Yann talked about "sensitive packages, related to security: openssl, dropbear, ca-certificates...", so I thought hashes are optional[1]. It seems I did not notice the change of policy regarding hashes.
In other words: Is there a reason _not_ to include a hash for a source tarball?

Regards, Bernd

[1] According to the doc
http://buildroot.uclibc.org/downloads/manual/manual.html#adding-packages-hash
they are still optional ;)

Yann E. MORIN

2014-10-07 21:06 UTC #5 lore raw

PATCH 1/3 package/libva: Bump version to 1.4.0

Bernd, All,

On 2014-10-07 22:58 +0200, Bernd Kuhls spake thusly:

Quoted 9 lines

Peter Korsgaard <[email protected]> wrote in
news:87ppe3fwnn.fsf at dell.be.48ers.dk:
Quoted 3 lines
Committed all 3, thanks. For future patches, it would be good if you would add the tarball hashes as the libva* release announcements had them (I've added them now).
Hi,

Quoted 8 lines

ok, I will do so.
Until now I did not really bother for my non-security-related packages because I remembered the commit description
http://git.buildroot.net/buildroot/commit/support/download/check-hash?id=
9bd8b59526c4521879f0ae5f765cb1a748725c49 where Yann talked about "sensitive packages, related to security: openssl, dropbear, ca-certificates...", so I thought hashes are optional[1].

Yes, that is the primary reason for adding hashes. And we do want hashes for those sensitive packages. However...

Quoted 4 lines

It seems I did not notice the change of
policy regarding hashes.
In other words: Is there a reason _not_ to include a hash for a source tarball?

... there are a few other good reasons we accept hashes:

- it ensures a broken download is detected, so the user quickly knows that the tarball is broken because of the download; sometimes, upstreams breaks their distributions (e.g. the recent sourceforge breakage...).

- non-compliant downloads are removed (rm -f) so they are not accidentally used in another context (e.g. I do share my BR2_DL_DIR with other stuff).

- consequently, it helps the autobuilders prune their failed downloads.

But in the end there is no clear policy, except:

- we *do* want hashes for security-related packages;
- hashes for other packages are a nice bonus.

Regards,
Yann E. MORIN.

Signature · 6 lines

.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

Peter Korsgaard

2014-10-07 21:12 UTC #6 lore raw

PATCH 1/3 package/libva: Bump version to 1.4.0

Quoted 1 line

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Yann" == Yann E MORIN <[email protected]> writes:

Hi,

Quoted 11 lines

... there are a few other good reasons we accept hashes:
- it ensures a broken download is detected, so the user quickly knows that the tarball is broken because of the download; sometimes, upstreams breaks their distributions (e.g. the recent sourceforge breakage...).
- non-compliant downloads are removed (rm -f) so they are not accidentally used in another context (e.g. I do share my BR2_DL_DIR with other stuff).

Quoted 7 lines

- consequently, it helps the autobuilders prune their failed downloads.
But in the end there is no clear policy, except:
- we *do* want hashes for security-related packages;
- hashes for other packages are a nice bonus.

Agreed. It is in no way required, but nice - Especially if upstream posts hashes.

Signature · 1 line

Bye, Peter Korsgaard