[Buildroot] [PATCH 1/3] package/libva: Bump version to 1.4.0

[Buildroot] [PATCH 1/3] package/libva: Bump version to 1.4.0

[Bernd Kuhls]

Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
---
 package/libva/libva.mk |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/libva/libva.mk b/package/libva/libva.mk
index 857cb17..984222d 100644
--- a/package/libva/libva.mk
+++ b/package/libva/libva.mk
@@ -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
-- 
1.7.10.4

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

[Bernd Kuhls]

Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
---
 package/libva-intel-driver/libva-intel-driver.mk |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/libva-intel-driver/libva-intel-driver.mk b/package/libva-intel-driver/libva-intel-driver.mk
index b717e29..5aed95b 100644
--- a/package/libva-intel-driver/libva-intel-driver.mk
+++ b/package/libva-intel-driver/libva-intel-driver.mk
@@ -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
-- 
1.7.10.4

[Buildroot] [PATCH 3/3] package/ffmpeg: Bump version to 2.4.2

[Bernd Kuhls]

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

Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
---
 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

diff --git a/package/ffmpeg/ffmpeg-0002-arm4-arm5.patch b/package/ffmpeg/ffmpeg-0002-arm4-arm5.patch
deleted file mode 100644
index 5a0147f..0000000
--- a/package/ffmpeg/ffmpeg-0002-arm4-arm5.patch
+++ /dev/null
@@ -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 <bernd.kuhls@t-online.de>
-
-From fe0f39e7263cd95783ad4669f8c3672a8eab4c83 Mon Sep 17 00:00:00 2001
-From: Bernd Kuhls <bernd.kuhls@t-online.de>
-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 <bernd.kuhls@t-online.de>
----
- 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
-
diff --git a/package/ffmpeg/ffmpeg.mk b/package/ffmpeg/ffmpeg.mk
index 41b06a7..1af47a6 100644
--- a/package/ffmpeg/ffmpeg.mk
+++ b/package/ffmpeg/ffmpeg.mk
@@ -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
-- 
1.7.10.4

[Buildroot] [PATCH 1/3] package/libva: Bump version to 1.4.0

[Peter Korsgaard]

>>>>> "Bernd" == Bernd Kuhls <bernd.kuhls@t-online.de> writes:

 > Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>

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

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 1/3] package/libva: Bump version to 1.4.0

[Bernd Kuhls]

Peter Korsgaard <jacmet@uclibc.org> wrote in 
news:87ppe3fwnn.fsf at dell.be.48ers.dk:

> 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 ;)

[Buildroot] [PATCH 1/3] package/libva: Bump version to 1.4.0

[Yann E. MORIN]

Bernd, All,

On 2014-10-07 22:58 +0200, Bernd Kuhls spake thusly:
> Peter Korsgaard <jacmet@uclibc.org> wrote in 
> news:87ppe3fwnn.fsf at dell.be.48ers.dk:
> 
> > 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].

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

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

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

[Buildroot] [PATCH 1/3] package/libva: Bump version to 1.4.0

[Peter Korsgaard]

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

Hi,

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

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

-- 
Bye, Peter Korsgaard