[PATCH 1/2] libical: update to 2.0.0

[PATCH 1/2] libical: update to 2.0.0

[Maxin B. John]

1.0.1 -> 2.0.0

1. New version is not Binary Compatible with Older Versions
2. Removed two backported patches
        a. Fix-x32-ABI-build.patch
        b. Depend-on-headers-to-fix-parallel-build.patch

3. New RSCALE support requires icu

Signed-off-by: Maxin B. John <maxin.john@intel.com>
---
 .../Depend-on-headers-to-fix-parallel-build.patch  | 46 ----------------------
 .../libical/libical/Fix-x32-ABI-build.patch        | 38 ------------------
 .../libical/{libical_1.0.1.bb => libical_2.0.0.bb} |  9 +++--
 3 files changed, 5 insertions(+), 88 deletions(-)
 delete mode 100644 meta/recipes-support/libical/libical/Depend-on-headers-to-fix-parallel-build.patch
 delete mode 100644 meta/recipes-support/libical/libical/Fix-x32-ABI-build.patch
 rename meta/recipes-support/libical/{libical_1.0.1.bb => libical_2.0.0.bb} (71%)

diff --git a/meta/recipes-support/libical/libical/Depend-on-headers-to-fix-parallel-build.patch b/meta/recipes-support/libical/libical/Depend-on-headers-to-fix-parallel-build.patch
deleted file mode 100644
index 4d65c81..0000000
--- a/meta/recipes-support/libical/libical/Depend-on-headers-to-fix-parallel-build.patch
+++ /dev/null
@@ -1,46 +0,0 @@
-From 56a10a14c0a544df99c97ce279801ddf40b0df52 Mon Sep 17 00:00:00 2001
-From: Jussi Kukkonen <jussi.kukkonen@intel.com>
-Date: Mon, 14 Sep 2015 13:35:42 +0300
-Subject: [PATCH] WIP: Depend on headers to fix parallel build
-
-Parallel builds occasionally fail because generated headers are only
-half built when they're being used.
-
-This fix is extracted
-from https://github.com/libical/libical/commit/dcc40c7ae2d337a0d83c077bf9d8f283499c6717
-
-Upstream-Status: Backport
-Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
-
----
- examples/CMakeLists.txt    | 1 +
- src/libical/CMakeLists.txt | 1 +
- 2 files changed, 2 insertions(+)
-
-diff --git a/examples/CMakeLists.txt b/examples/CMakeLists.txt
-index 3379ffd..514956b 100644
---- a/examples/CMakeLists.txt
-+++ b/examples/CMakeLists.txt
-@@ -16,6 +16,7 @@ set(doesnothing_SRCS
- )
- 
- add_executable(doesnothing ${doesnothing_SRCS})
-+add_dependencies(doesnothing ical icalss icalvcal)
- 
- target_link_libraries(doesnothing ical icalss icalvcal ical icalss icalvcal)
- 
-diff --git a/src/libical/CMakeLists.txt b/src/libical/CMakeLists.txt
-index 6774352..468a7d9 100644
---- a/src/libical/CMakeLists.txt
-+++ b/src/libical/CMakeLists.txt
-@@ -261,6 +261,7 @@ add_library(ical ${LIBRARY_TYPE} ${ical_LIB_SRCS})
- add_library(ical-static STATIC ${ical_LIB_SRCS})
- 
- add_dependencies(ical ical-header)
-+add_dependencies(ical-static ical-header)
- 
- target_link_libraries(ical ${CMAKE_THREAD_LIBS_INIT})
- 
--- 
-2.1.4
-
diff --git a/meta/recipes-support/libical/libical/Fix-x32-ABI-build.patch b/meta/recipes-support/libical/libical/Fix-x32-ABI-build.patch
deleted file mode 100644
index 12186e2..0000000
--- a/meta/recipes-support/libical/libical/Fix-x32-ABI-build.patch
+++ /dev/null
@@ -1,38 +0,0 @@
-Subject: [PATCH] Use GNUInstallDirs.
-
-x32 ABI build fails because of improper library path. Use
-GNUInstallDirs to fix it.
-
-Upstream-Status: Backport
-
-Signed-off-by: Maxin B. John <maxin.john@intel.com>
----
-diff -Naur libical-1.0.1-orig/CMakeLists.txt libical-1.0.1/CMakeLists.txt
---- libical-1.0.1-orig/CMakeLists.txt	2015-12-07 18:13:58.311503974 +0200
-+++ libical-1.0.1/CMakeLists.txt	2015-12-07 18:17:18.362002998 +0200
-@@ -92,6 +92,10 @@
- endif()
- 
- set(PERL_EXECUTABLE perl)
-+# Ensure finding 64bit libs when using 64-bit compilers
-+if(CMAKE_CL_64)
-+  set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS True)
-+endif()
- 
- # MSVC specific definitions
- if(WIN32)
-@@ -104,10 +108,10 @@
-   add_definitions(-DBIG_ENDIAN=0 -DLITTLE_ENDIAN=1 -DBYTE_ORDER=BIG_ENDIAN)
- endif()
- 
--set(LIB_SUFFIX "" CACHE STRING "Define suffix of directory name (32/64)")
--set(LIB_INSTALL_DIR "${CMAKE_INSTALL_PREFIX}/lib${LIB_SUFFIX}" CACHE STRING "Library directory name" FORCE)
--set(INCLUDE_INSTALL_DIR "${CMAKE_INSTALL_PREFIX}/include" CACHE STRING "Include directory name" FORCE)
--set(SHARE_INSTALL_DIR "${CMAKE_INSTALL_PREFIX}/share" CACHE STRING "Share directory name" FORCE)
-+include(GNUInstallDirs)
-+set(LIB_INSTALL_DIR ${CMAKE_INSTALL_LIBDIR} CACHE STRING "Library directory name" FORCE)
-+set(INCLUDE_INSTALL_DIR ${CMAKE_INSTALL_INCLUDEDIR} CACHE STRING "Include directory name" FORCE)
-+set(SHARE_INSTALL_DIR ${CMAKE_INSTALL_DATAROOTDIR} CACHE STRING "Share directory name")
- 
- # set the output paths
- set(EXECUTABLE_OUTPUT_PATH ${CMAKE_BINARY_DIR}/bin)
diff --git a/meta/recipes-support/libical/libical_1.0.1.bb b/meta/recipes-support/libical/libical_2.0.0.bb
similarity index 71%
rename from meta/recipes-support/libical/libical_1.0.1.bb
rename to meta/recipes-support/libical/libical_2.0.0.bb
index 838e788..1735cf5 100644
--- a/meta/recipes-support/libical/libical_1.0.1.bb
+++ b/meta/recipes-support/libical/libical_2.0.0.bb
@@ -8,11 +8,12 @@ SECTION = "libs"
 
 SRC_URI = "https://github.com/${BPN}/${BPN}/archive/v${PV}.tar.gz \
            file://Remove-cmake-check-for-Perl.patch \
-           file://Fix-x32-ABI-build.patch \
-           file://Depend-on-headers-to-fix-parallel-build.patch \
            "
-SRC_URI[md5sum] = "af91db06b22559f863869c5a382ad08a"
-SRC_URI[sha256sum] = "7d5f613454ec6c7d1bcfb441c919215be53292aa15cd1cb14249d1413d6c610c"
+DEPENDS = "icu"
+RDEPENDS_${PN} = "libicuuc libicui18n libicudata"
+
+SRC_URI[md5sum] = "ab743a66927284ccf42ee28847550144"
+SRC_URI[sha256sum] = "20f4a98475052e1200d2691ba50b27969e4bedc6e50bffd5e2fa81f4ac90de9a"
 UPSTREAM_CHECK_URI = "https://github.com/libical/libical/releases"
 
 inherit cmake
-- 
2.4.0

[PATCH 2/2] connman: fix crash with iptables 1.6

[Maxin B. John]

The struct of xtables_globals has been modified in iptables 1.6.
If connman runs with iptables 1.6, it can crash.

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
0xb7dea89c in xtables_find_target () from /usr/lib/libxtables.so.11
0xb7deac1c in ?? () from /usr/lib/libxtables.so.11
0xb7dea793 in xtables_find_target () from /usr/lib/libxtables.so.11

The the missing function item of xtables is added to xtables_globals.
It can fix the above issue.

Signed-off-by: Maxin B. John <maxin.john@intel.com>
---
 ...d-missing-function-item-of-xtables-to-mat.patch | 42 ++++++++++++++++++++++
 meta/recipes-connectivity/connman/connman_1.31.bb  |  1 +
 2 files changed, 43 insertions(+)
 create mode 100644 meta/recipes-connectivity/connman/connman/0001-iptables-Add-missing-function-item-of-xtables-to-mat.patch

diff --git a/meta/recipes-connectivity/connman/connman/0001-iptables-Add-missing-function-item-of-xtables-to-mat.patch b/meta/recipes-connectivity/connman/connman/0001-iptables-Add-missing-function-item-of-xtables-to-mat.patch
new file mode 100644
index 0000000..1b5a3e4
--- /dev/null
+++ b/meta/recipes-connectivity/connman/connman/0001-iptables-Add-missing-function-item-of-xtables-to-mat.patch
@@ -0,0 +1,42 @@
+From acea08a0e4234a4c1a87bedc087c73ff36de0c7b Mon Sep 17 00:00:00 2001
+From: Wu Zheng <wu.zheng@intel.com>
+Date: Thu, 28 Jan 2016 18:04:17 +0800
+Subject: [PATCH] iptables: Add missing function item of xtables to match
+ iptables 1.6
+
+The struct of xtables_globals has been modified in iptables 1.6.
+If connman runs with iptables 1.6, it can crash.
+
+Program received signal SIGSEGV, Segmentation fault.
+0x00000000 in ?? ()
+0xb7dea89c in xtables_find_target () from /usr/lib/libxtables.so.11
+0xb7deac1c in ?? () from /usr/lib/libxtables.so.11
+0xb7dea793 in xtables_find_target () from /usr/lib/libxtables.so.11
+
+The the missing function item of xtables is added to xtables_globals.
+
+Upstream-Status: Backport
+
+Signed-off-by: Maxin B. John <maxin.john@intel.com>
+Signed-off-by: Wu Zheng <wu.zheng@intel.com>
+---
+ src/iptables.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/src/iptables.c b/src/iptables.c
+index bc0c763..5ef757a 100644
+--- a/src/iptables.c
++++ b/src/iptables.c
+@@ -1566,6 +1566,9 @@ struct xtables_globals iptables_globals = {
+ 	.option_offset = 0,
+ 	.opts = iptables_opts,
+ 	.orig_opts = iptables_opts,
++#if XTABLES_VERSION_CODE > 10
++	.compat_rev = xtables_compatible_revision,
++#endif
+ };
+ 
+ static struct xtables_target *prepare_target(struct connman_iptables *table,
+-- 
+2.4.0
+
diff --git a/meta/recipes-connectivity/connman/connman_1.31.bb b/meta/recipes-connectivity/connman/connman_1.31.bb
index 7b6bcfb..e71d221 100644
--- a/meta/recipes-connectivity/connman/connman_1.31.bb
+++ b/meta/recipes-connectivity/connman/connman_1.31.bb
@@ -5,6 +5,7 @@ SRC_URI  = "${KERNELORG_MIRROR}/linux/network/${BPN}/${BP}.tar.xz \
             file://0001-Detect-backtrace-API-availability-before-using-it.patch \
             file://0002-resolve-musl-does-not-implement-res_ninit.patch \
             file://0003-Fix-header-inclusions-for-musl.patch \
+            file://0001-iptables-Add-missing-function-item-of-xtables-to-mat.patch \
             file://connman \
             "
 SRC_URI[md5sum] = "cb1c413fcc4f49430294bbd7a92f5f3c"
-- 
2.4.0

Re: [PATCH 1/2] libical: update to 2.0.0

[Burton, Ross]

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

On 28 January 2016 at 12:37, Maxin B. John <maxin.john@intel.com> wrote:

> +RDEPENDS_${PN} = "libicuuc libicui18n libicudata"
>

Do these not get detected automatically?

Ross

[-- Attachment #2: Type: text/html, Size: 602 bytes --]

Re: [PATCH 1/2] libical: update to 2.0.0

[Burton, Ross]

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

On 28 January 2016 at 13:13, Maxin B. John <maxin.john@intel.com> wrote:

> These library dependencies do get detected automatically. This line can be
> removed
> if we don't want to explicitly mention the dependencies.
>

We only need to mention library dependencies explicitly if they're opened
at runtime and the dependency magic can't see them.  Please send a v2 for
this patch.

Presumably although the ABI changed, the API is the same so bluez5 and so
on still builds against libical 2?

Ross

[-- Attachment #2: Type: text/html, Size: 992 bytes --]

Re: [PATCH 1/2] libical: update to 2.0.0

[Maxin B. John]

Hi Ross,

On Thu, Jan 28, 2016 at 01:00:49PM +0000, Burton, Ross wrote:
>On 28 January 2016 at 12:37, Maxin B. John <maxin.john@intel.com> wrote:
>
>   +RDEPENDS_${PN} = "libicuuc libicui18n libicudata">
>
>    Do these not get detected automatically?

These library dependencies do get detected automatically. This line can be removed
if we don't want to explicitly mention the dependencies.

>    Ross
Best Regards,
Maxin

Re: [PATCH 1/2] libical: update to 2.0.0

[Alexander Kanavin]

On 01/28/2016 03:13 PM, Burton, Ross wrote:

> Presumably although the ABI changed, the API is the same so bluez5 and
> so on still builds against libical 2?

Generally, when there is a scary-looking major version update like this, 
it's a good idea to 'bitbake world'.


Alex

Re: [PATCH 1/2] libical: update to 2.0.0

[Maxin B. John]

Hi,

On Thu, Jan 28, 2016 at 01:13:05PM +0000, Burton, Ross wrote:
>On 28 January 2016 at 13:13, Maxin B. John <maxin.john@intel.com> wrote:
>
>    These library dependencies do get detected automatically. This line can be removed
>        if we don't want to explicitly mention the dependencies.
>
>        We only need to mention library dependencies explicitly if they're opened at runtime and the dependency magic can't see them.  Please send a v2 for this patch.
>        Presumably although the ABI changed, the API is the same so bluez5 and so on still builds against libical 2?

Thanks for explaining that (bit carried away by the buildhistory-diff tool output). 
Sure, will send a v2 soon.

Yes, bluez5 build works fine with the libical 2.

> Ross

Best Regards,
Maxin

Re: [PATCH 1/2] libical: update to 2.0.0

[Maxin B. John]

Hi Alex,

On Thu, Jan 28, 2016 at 03:15:56PM +0200, Alexander Kanavin wrote:
> On 01/28/2016 03:13 PM, Burton, Ross wrote:
> 
> >Presumably although the ABI changed, the API is the same so bluez5 and
> >so on still builds against libical 2?
> 
> Generally, when there is a scary-looking major version update like this,
> it's a good idea to 'bitbake world'.

Good suggestion. Will do it for this update. 

Most of the times, it is hard to do a bitbake world for every upgrades. 
(regular build, x32, musl, uclibc and possibly one more architecture combinations)

> Alex

Best Regards,
Maxin

Re: [PATCH 1/2] libical: update to 2.0.0

[Alexander Kanavin]

On 01/28/2016 03:39 PM, Maxin B. John wrote:

> Good suggestion. Will do it for this update.
>
> Most of the times, it is hard to do a bitbake world for every upgrades.
> (regular build, x32, musl, uclibc and possibly one more architecture combinations)

Yes, of course. It's often a waste of time watching world builds, so 
it's a personal judgement call, but at least when there's a possibility 
of potential API breakage, that should be checked and the easiest way, 
if you have a bunch of updates and don't feel like disentangling their 
downstream dependencies, is to run 'world'.


Alex

Re: [PATCH 1/2] libical: update to 2.0.0

[Burton, Ross]

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

On 28 January 2016 at 13:40, Alexander Kanavin <
alexander.kanavin@linux.intel.com> wrote:

> Most of the times, it is hard to do a bitbake world for every upgrades.
>> (regular build, x32, musl, uclibc and possibly one more architecture
>> combinations)
>>
>
> Yes, of course. It's often a waste of time watching world builds, so it's
> a personal judgement call, but at least when there's a possibility of
> potential API breakage, that should be checked and the easiest way, if you
> have a bunch of updates and don't feel like disentangling their downstream
> dependencies, is to run 'world'.
>

If bluez5 works then the API can't have broken that much...  once it's in
mut the autobuilder can give it a stress test anyway.

Ross

[-- Attachment #2: Type: text/html, Size: 1271 bytes --]