[Buildroot] [PATCH] protobuf: bump to 2.6.1

[Buildroot] [PATCH] protobuf: bump to 2.6.1

[Steven Noonan]

Signed-off-by: Steven Noonan <steven@uplinklabs.net>
---
 package/protobuf/protobuf.hash | 2 ++
 package/protobuf/protobuf.mk   | 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)
 create mode 100644 package/protobuf/protobuf.hash

diff --git a/package/protobuf/protobuf.hash b/package/protobuf/protobuf.hash
new file mode 100644
index 0000000..78285b7
--- /dev/null
+++ b/package/protobuf/protobuf.hash
@@ -0,0 +1,2 @@
+# Locally calculated
+sha256 2667b7cda4a6bc8a09e5463adf3b5984e08d94e72338277affa8594d8b6e5cd1 protobuf-v2.6.1.tar.gz
diff --git a/package/protobuf/protobuf.mk b/package/protobuf/protobuf.mk
index 0426fce..144e5fb 100644
--- a/package/protobuf/protobuf.mk
+++ b/package/protobuf/protobuf.mk
@@ -4,7 +4,7 @@
 #
 ################################################################################
 
-PROTOBUF_VERSION = v2.5.0
+PROTOBUF_VERSION = v2.6.1
 PROTOBUF_SITE = $(call github,google,protobuf,$(PROTOBUF_VERSION))
 PROTOBUF_LICENSE = BSD-3c
 PROTOBUF_LICENSE_FILES = COPYING.txt
-- 
2.6.2

[Buildroot] [PATCH] protobuf: bump to 2.6.1

[Thomas Petazzoni]

Dear Steven Noonan,

On Wed,  4 Nov 2015 00:37:21 -0800, Steven Noonan wrote:
> Signed-off-by: Steven Noonan <steven@uplinklabs.net>
> ---
>  package/protobuf/protobuf.hash | 2 ++
>  package/protobuf/protobuf.mk   | 2 +-
>  2 files changed, 3 insertions(+), 1 deletion(-)
>  create mode 100644 package/protobuf/protobuf.hash

There have already been several attempts at bumping protobuf to 2.6.x,
but each time there were some issues.

Search for:

Subject: [Buildroot] [PATCH 1/1] protobuf: bump version to 2.6.1
Date: Mon, 22 Jun 2015 14:58:59 -0300

Subject: [Buildroot] [PATCH 1/1] protobuf/protobuf-c: bump versions
Date: Thu, 13 Aug 2015 21:41:21 -0400

Can you look into these threads and check that your bump takes into
account those problems ?

Most notably, make sure that protobuf-c builds fine, and
python-protobuf builds fine. But look at the threads for other
potential issues.

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] protobuf: bump to 2.6.1

[Steven Noonan]

On Wed, Nov 4, 2015 at 3:03 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Steven Noonan,
>
> On Wed,  4 Nov 2015 00:37:21 -0800, Steven Noonan wrote:
>> Signed-off-by: Steven Noonan <steven@uplinklabs.net>
>> ---
>>  package/protobuf/protobuf.hash | 2 ++
>>  package/protobuf/protobuf.mk   | 2 +-
>>  2 files changed, 3 insertions(+), 1 deletion(-)
>>  create mode 100644 package/protobuf/protobuf.hash
>
> There have already been several attempts at bumping protobuf to 2.6.x,
> but each time there were some issues.
>
> Search for:
>
> Subject: [Buildroot] [PATCH 1/1] protobuf: bump version to 2.6.1
> Date: Mon, 22 Jun 2015 14:58:59 -0300
>
> Subject: [Buildroot] [PATCH 1/1] protobuf/protobuf-c: bump versions
> Date: Thu, 13 Aug 2015 21:41:21 -0400
>
> Can you look into these threads and check that your bump takes into
> account those problems ?

Thanks for pointing those out. I'll take a look.

> Most notably, make sure that protobuf-c builds fine, and
> python-protobuf builds fine. But look at the threads for other
> potential issues.
>
> Thanks,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

[Buildroot] [PATCH] protobuf: bump to 2.6.1

[Steven Noonan]

On Wed, Nov 4, 2015 at 7:28 AM, Steven Noonan <steven@uplinklabs.net> wrote:
> On Wed, Nov 4, 2015 at 3:03 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>> Dear Steven Noonan,
>>
>> On Wed,  4 Nov 2015 00:37:21 -0800, Steven Noonan wrote:
>>> Signed-off-by: Steven Noonan <steven@uplinklabs.net>
>>> ---
>>>  package/protobuf/protobuf.hash | 2 ++
>>>  package/protobuf/protobuf.mk   | 2 +-
>>>  2 files changed, 3 insertions(+), 1 deletion(-)
>>>  create mode 100644 package/protobuf/protobuf.hash
>>
>> There have already been several attempts at bumping protobuf to 2.6.x,
>> but each time there were some issues.
>>
>> Search for:
>>
>> Subject: [Buildroot] [PATCH 1/1] protobuf: bump version to 2.6.1
>> Date: Mon, 22 Jun 2015 14:58:59 -0300
>>
>> Subject: [Buildroot] [PATCH 1/1] protobuf/protobuf-c: bump versions
>> Date: Thu, 13 Aug 2015 21:41:21 -0400
>>
>> Can you look into these threads and check that your bump takes into
>> account those problems ?
>
> Thanks for pointing those out. I'll take a look.

One of the threads I found is confusing. It bumped protobuf to 2.6.1
but also enabled building for PowerPC. But I see no indication in the
protobuf 2.6.1 sources that PowerPC is a supported architecture, so I
wouldn't have expected it to work -- and the patch was presumably not
applied for that reason. This issue should not affect my patch, as I
didn't touch the architecture requirements in
package/protobuf/Config.in (or in anything depending on protobuf).

I also saw threads talking about compile problems on pre-GCC 4.7
toolchains, but I successfully built on x86_64 with as old as GCC 4.4
(but didn't try older than that).

>> Most notably, make sure that protobuf-c builds fine, and
>> python-protobuf builds fine. But look at the threads for other
>> potential issues.

I'll submit a separate patch upgrading protobuf-c to v1.1.1.

With the protobuf 2.6.1 patch and my [unsubmitted] protobuf-c v1.1.1
patch, I successfully built with this defconfig (basically
qemu_x86_64_defconfig + protobuf and any packages using it):

BR2_x86_64=y
BR2_KERNEL_HEADERS_VERSION=y
BR2_DEFAULT_KERNEL_VERSION="4.2"
BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_2=y
BR2_TOOLCHAIN_BUILDROOT_WCHAR=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_TARGET_GENERIC_GETTY_PORT="tty1"
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.2"
BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/x86_64/linux-4.2.config"
BR2_PACKAGE_OLA=y
BR2_PACKAGE_PYTHON=y
BR2_PACKAGE_PYTHON_PROTOBUF=y
BR2_PACKAGE_PROTOBUF_C=y
BR2_PACKAGE_COLLECTD=y
BR2_PACKAGE_MOSH=y
BR2_TARGET_ROOTFS_EXT2=y
# BR2_TARGET_ROOTFS_TAR is not set


And to cover all my bases I also tried the same with a similarly
modified qemu_mipsel_malta_defconfig:

BR2_mipsel=y
BR2_mips_32r2=y
BR2_KERNEL_HEADERS_VERSION=y
BR2_DEFAULT_KERNEL_VERSION="4.2"
BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_2=y
BR2_TOOLCHAIN_BUILDROOT_WCHAR=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_TARGET_GENERIC_GETTY_PORT="ttyS0"
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.2"
BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/mipsel-malta/linux-4.2.config"
BR2_LINUX_KERNEL_VMLINUX=y
BR2_PACKAGE_OLA=y
BR2_PACKAGE_PYTHON=y
BR2_PACKAGE_PYTHON_PROTOBUF=y
BR2_PACKAGE_PROTOBUF_C=y
BR2_PACKAGE_COLLECTD=y
BR2_PACKAGE_MOSH=y
BR2_TARGET_ROOTFS_EXT2=y
# BR2_TARGET_ROOTFS_TAR is not set


Didn't run into any build problems with either one.

[Buildroot] [PATCH] protobuf: bump to 2.6.1

[DATACOM - henrique.marks]

Hello All

I was involved in one of those threads, so let me clarify.

There was an error in protobuf (upstream) that prevented it being built fot powerpc. In our project, we need protobuf 2.6.1 working with powerpc arch.

We have a local build of protobuf 2.6.1 that works with powerpc arch. We just didn't have time to submit it upstream (yet). So, i am going to attach our changes here, so that you can use it together with your work.

Tha Patch (0001) corrects the wrong protobuf behaviour, and it is already applied upstream (but not in this version).

The rest is the Config.in and protobuf.mk

What else must be done:

Some other packages, that depends on protobuf, have a dependency on !BR2_powerpc, so they are not built for powerpc just because of protobuf. Now that protobuf builds on powerpc, this restriction can be lifted up. This is what we don't have yet to submit upstream.

Thats it, thanks and sorry for the long email.

----- Mensagem original -----
> De: "Steven Noonan" <steven@uplinklabs.net>
> Para: "Thomas Petazzoni" <thomas.petazzoni@free-electrons.com>
> Cc: buildroot at buildroot.org
> Enviadas: Quarta-feira, 4 de novembro de 2015 14:58:16
> Assunto: Re: [Buildroot] [PATCH] protobuf: bump to 2.6.1

> On Wed, Nov 4, 2015 at 7:28 AM, Steven Noonan <steven@uplinklabs.net> wrote:
>> On Wed, Nov 4, 2015 at 3:03 AM, Thomas Petazzoni
>> <thomas.petazzoni@free-electrons.com> wrote:
>>> Dear Steven Noonan,
>>>
>>> On Wed,  4 Nov 2015 00:37:21 -0800, Steven Noonan wrote:
>>>> Signed-off-by: Steven Noonan <steven@uplinklabs.net>
>>>> ---
>>>>  package/protobuf/protobuf.hash | 2 ++
>>>>  package/protobuf/protobuf.mk   | 2 +-
>>>>  2 files changed, 3 insertions(+), 1 deletion(-)
>>>>  create mode 100644 package/protobuf/protobuf.hash
>>>
>>> There have already been several attempts at bumping protobuf to 2.6.x,
>>> but each time there were some issues.
>>>
>>> Search for:
>>>
>>> Subject: [Buildroot] [PATCH 1/1] protobuf: bump version to 2.6.1
>>> Date: Mon, 22 Jun 2015 14:58:59 -0300
>>>
>>> Subject: [Buildroot] [PATCH 1/1] protobuf/protobuf-c: bump versions
>>> Date: Thu, 13 Aug 2015 21:41:21 -0400
>>>
>>> Can you look into these threads and check that your bump takes into
>>> account those problems ?
>>
>> Thanks for pointing those out. I'll take a look.
> 
> One of the threads I found is confusing. It bumped protobuf to 2.6.1
> but also enabled building for PowerPC. But I see no indication in the
> protobuf 2.6.1 sources that PowerPC is a supported architecture, so I
> wouldn't have expected it to work -- and the patch was presumably not
> applied for that reason. This issue should not affect my patch, as I
> didn't touch the architecture requirements in
> package/protobuf/Config.in (or in anything depending on protobuf).
> 
> I also saw threads talking about compile problems on pre-GCC 4.7
> toolchains, but I successfully built on x86_64 with as old as GCC 4.4
> (but didn't try older than that).
> 
>>> Most notably, make sure that protobuf-c builds fine, and
>>> python-protobuf builds fine. But look at the threads for other
>>> potential issues.
> 
> I'll submit a separate patch upgrading protobuf-c to v1.1.1.
> 
> With the protobuf 2.6.1 patch and my [unsubmitted] protobuf-c v1.1.1
> patch, I successfully built with this defconfig (basically
> qemu_x86_64_defconfig + protobuf and any packages using it):
> 
> BR2_x86_64=y
> BR2_KERNEL_HEADERS_VERSION=y
> BR2_DEFAULT_KERNEL_VERSION="4.2"
> BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_2=y
> BR2_TOOLCHAIN_BUILDROOT_WCHAR=y
> BR2_TOOLCHAIN_BUILDROOT_CXX=y
> BR2_TARGET_GENERIC_GETTY_PORT="tty1"
> BR2_LINUX_KERNEL=y
> BR2_LINUX_KERNEL_CUSTOM_VERSION=y
> BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.2"
> BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
> BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/x86_64/linux-4.2.config"
> BR2_PACKAGE_OLA=y
> BR2_PACKAGE_PYTHON=y
> BR2_PACKAGE_PYTHON_PROTOBUF=y
> BR2_PACKAGE_PROTOBUF_C=y
> BR2_PACKAGE_COLLECTD=y
> BR2_PACKAGE_MOSH=y
> BR2_TARGET_ROOTFS_EXT2=y
> # BR2_TARGET_ROOTFS_TAR is not set
> 
> 
> And to cover all my bases I also tried the same with a similarly
> modified qemu_mipsel_malta_defconfig:
> 
> BR2_mipsel=y
> BR2_mips_32r2=y
> BR2_KERNEL_HEADERS_VERSION=y
> BR2_DEFAULT_KERNEL_VERSION="4.2"
> BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_2=y
> BR2_TOOLCHAIN_BUILDROOT_WCHAR=y
> BR2_TOOLCHAIN_BUILDROOT_CXX=y
> BR2_TARGET_GENERIC_GETTY_PORT="ttyS0"
> BR2_LINUX_KERNEL=y
> BR2_LINUX_KERNEL_CUSTOM_VERSION=y
> BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.2"
> BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
> BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/mipsel-malta/linux-4.2.config"
> BR2_LINUX_KERNEL_VMLINUX=y
> BR2_PACKAGE_OLA=y
> BR2_PACKAGE_PYTHON=y
> BR2_PACKAGE_PYTHON_PROTOBUF=y
> BR2_PACKAGE_PROTOBUF_C=y
> BR2_PACKAGE_COLLECTD=y
> BR2_PACKAGE_MOSH=y
> BR2_TARGET_ROOTFS_EXT2=y
> # BR2_TARGET_ROOTFS_TAR is not set
> 
> 
> Didn't run into any build problems with either one.
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
Dr. Henrique Marks
henrique.marks at datacom.ind.br
R. Am?rica, 1000 - Eldorado do Sul - RS
CEP: 92990-000 - Brasil
Fone: +55 51 3933 3000 - Ramal 3466
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-PowerPC-Support.patch
Type: text/x-patch
Size: 1808 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20151104/c73a2b4e/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Config.in
Type: application/octet-stream
Size: 884 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20151104/c73a2b4e/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: protobuf.mk
Type: text/x-makefile
Size: 702 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20151104/c73a2b4e/attachment-0001.bin>

[Buildroot] [PATCH] protobuf: bump to 2.6.1

[Steven Noonan]

On Wed, Nov 4, 2015 at 9:25 AM, DATACOM - henrique.marks
<henrique.marks@datacom.ind.br> wrote:
> Hello All
>
> I was involved in one of those threads, so let me clarify.
>
> There was an error in protobuf (upstream) that prevented it being built fot powerpc. In our project, we need protobuf 2.6.1 working with powerpc arch.
>
> We have a local build of protobuf 2.6.1 that works with powerpc arch. We just didn't have time to submit it upstream (yet). So, i am going to attach our changes here, so that you can use it together with your work.

What puzzles me is that protobuf 2.6.1 doesn't have any
PowerPC-related macros in src/google/protobuf/stubs/platform_macros.h,
and it doesn't look like your patch adds any.

> Tha Patch (0001) corrects the wrong protobuf behaviour, and it is already applied upstream (but not in this version).
>
> The rest is the Config.in and protobuf.mk
>
> What else must be done:
>
> Some other packages, that depends on protobuf, have a dependency on !BR2_powerpc, so they are not built for powerpc just because of protobuf. Now that protobuf builds on powerpc, this restriction can be lifted up. This is what we don't have yet to submit upstream.
>
> Thats it, thanks and sorry for the long email.
>
> ----- Mensagem original -----
>> De: "Steven Noonan" <steven@uplinklabs.net>
>> Para: "Thomas Petazzoni" <thomas.petazzoni@free-electrons.com>
>> Cc: buildroot at buildroot.org
>> Enviadas: Quarta-feira, 4 de novembro de 2015 14:58:16
>> Assunto: Re: [Buildroot] [PATCH] protobuf: bump to 2.6.1
>
>> On Wed, Nov 4, 2015 at 7:28 AM, Steven Noonan <steven@uplinklabs.net> wrote:
>>> On Wed, Nov 4, 2015 at 3:03 AM, Thomas Petazzoni
>>> <thomas.petazzoni@free-electrons.com> wrote:
>>>> Dear Steven Noonan,
>>>>
>>>> On Wed,  4 Nov 2015 00:37:21 -0800, Steven Noonan wrote:
>>>>> Signed-off-by: Steven Noonan <steven@uplinklabs.net>
>>>>> ---
>>>>>  package/protobuf/protobuf.hash | 2 ++
>>>>>  package/protobuf/protobuf.mk   | 2 +-
>>>>>  2 files changed, 3 insertions(+), 1 deletion(-)
>>>>>  create mode 100644 package/protobuf/protobuf.hash
>>>>
>>>> There have already been several attempts at bumping protobuf to 2.6.x,
>>>> but each time there were some issues.
>>>>
>>>> Search for:
>>>>
>>>> Subject: [Buildroot] [PATCH 1/1] protobuf: bump version to 2.6.1
>>>> Date: Mon, 22 Jun 2015 14:58:59 -0300
>>>>
>>>> Subject: [Buildroot] [PATCH 1/1] protobuf/protobuf-c: bump versions
>>>> Date: Thu, 13 Aug 2015 21:41:21 -0400
>>>>
>>>> Can you look into these threads and check that your bump takes into
>>>> account those problems ?
>>>
>>> Thanks for pointing those out. I'll take a look.
>>
>> One of the threads I found is confusing. It bumped protobuf to 2.6.1
>> but also enabled building for PowerPC. But I see no indication in the
>> protobuf 2.6.1 sources that PowerPC is a supported architecture, so I
>> wouldn't have expected it to work -- and the patch was presumably not
>> applied for that reason. This issue should not affect my patch, as I
>> didn't touch the architecture requirements in
>> package/protobuf/Config.in (or in anything depending on protobuf).
>>
>> I also saw threads talking about compile problems on pre-GCC 4.7
>> toolchains, but I successfully built on x86_64 with as old as GCC 4.4
>> (but didn't try older than that).
>>
>>>> Most notably, make sure that protobuf-c builds fine, and
>>>> python-protobuf builds fine. But look at the threads for other
>>>> potential issues.
>>
>> I'll submit a separate patch upgrading protobuf-c to v1.1.1.
>>
>> With the protobuf 2.6.1 patch and my [unsubmitted] protobuf-c v1.1.1
>> patch, I successfully built with this defconfig (basically
>> qemu_x86_64_defconfig + protobuf and any packages using it):
>>
>> BR2_x86_64=y
>> BR2_KERNEL_HEADERS_VERSION=y
>> BR2_DEFAULT_KERNEL_VERSION="4.2"
>> BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_2=y
>> BR2_TOOLCHAIN_BUILDROOT_WCHAR=y
>> BR2_TOOLCHAIN_BUILDROOT_CXX=y
>> BR2_TARGET_GENERIC_GETTY_PORT="tty1"
>> BR2_LINUX_KERNEL=y
>> BR2_LINUX_KERNEL_CUSTOM_VERSION=y
>> BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.2"
>> BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
>> BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/x86_64/linux-4.2.config"
>> BR2_PACKAGE_OLA=y
>> BR2_PACKAGE_PYTHON=y
>> BR2_PACKAGE_PYTHON_PROTOBUF=y
>> BR2_PACKAGE_PROTOBUF_C=y
>> BR2_PACKAGE_COLLECTD=y
>> BR2_PACKAGE_MOSH=y
>> BR2_TARGET_ROOTFS_EXT2=y
>> # BR2_TARGET_ROOTFS_TAR is not set
>>
>>
>> And to cover all my bases I also tried the same with a similarly
>> modified qemu_mipsel_malta_defconfig:
>>
>> BR2_mipsel=y
>> BR2_mips_32r2=y
>> BR2_KERNEL_HEADERS_VERSION=y
>> BR2_DEFAULT_KERNEL_VERSION="4.2"
>> BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_2=y
>> BR2_TOOLCHAIN_BUILDROOT_WCHAR=y
>> BR2_TOOLCHAIN_BUILDROOT_CXX=y
>> BR2_TARGET_GENERIC_GETTY_PORT="ttyS0"
>> BR2_LINUX_KERNEL=y
>> BR2_LINUX_KERNEL_CUSTOM_VERSION=y
>> BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.2"
>> BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
>> BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/mipsel-malta/linux-4.2.config"
>> BR2_LINUX_KERNEL_VMLINUX=y
>> BR2_PACKAGE_OLA=y
>> BR2_PACKAGE_PYTHON=y
>> BR2_PACKAGE_PYTHON_PROTOBUF=y
>> BR2_PACKAGE_PROTOBUF_C=y
>> BR2_PACKAGE_COLLECTD=y
>> BR2_PACKAGE_MOSH=y
>> BR2_TARGET_ROOTFS_EXT2=y
>> # BR2_TARGET_ROOTFS_TAR is not set
>>
>>
>> Didn't run into any build problems with either one.
>> _______________________________________________
>> buildroot mailing list
>> buildroot at busybox.net
>> http://lists.busybox.net/mailman/listinfo/buildroot
>
> --
> Dr. Henrique Marks
> henrique.marks at datacom.ind.br
> R. Am?rica, 1000 - Eldorado do Sul - RS
> CEP: 92990-000 - Brasil
> Fone: +55 51 3933 3000 - Ramal 3466

[Buildroot] [PATCH] protobuf: bump to 2.6.1

[Thomas Petazzoni]

Steven,

On Wed, 4 Nov 2015 08:58:16 -0800, Steven Noonan wrote:

> > Thanks for pointing those out. I'll take a look.
> 
> One of the threads I found is confusing. It bumped protobuf to 2.6.1
> but also enabled building for PowerPC. But I see no indication in the
> protobuf 2.6.1 sources that PowerPC is a supported architecture, so I
> wouldn't have expected it to work -- and the patch was presumably not
> applied for that reason. This issue should not affect my patch, as I
> didn't touch the architecture requirements in
> package/protobuf/Config.in (or in anything depending on protobuf).

Right.

> >> Most notably, make sure that protobuf-c builds fine, and
> >> python-protobuf builds fine. But look at the threads for other
> >> potential issues.
> 
> I'll submit a separate patch upgrading protobuf-c to v1.1.1.

Perfect.

> With the protobuf 2.6.1 patch and my [unsubmitted] protobuf-c v1.1.1
> patch, I successfully built with this defconfig (basically
> qemu_x86_64_defconfig + protobuf and any packages using it):

[...]

Excellent, thanks for your testing. I'll wait for your protobuf-c patch
then, and apply both the protobuf and protobuf-c patches.

If some people want to look at enabling PowerPC later, they can do it
as follow-up patches.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] protobuf: bump to 2.6.1

[Thomas Petazzoni]

Dear Steven Noonan,

On Wed,  4 Nov 2015 00:37:21 -0800, Steven Noonan wrote:
> Signed-off-by: Steven Noonan <steven@uplinklabs.net>
> ---
>  package/protobuf/protobuf.hash | 2 ++
>  package/protobuf/protobuf.mk   | 2 +-
>  2 files changed, 3 insertions(+), 1 deletion(-)
>  create mode 100644 package/protobuf/protobuf.hash

Applied, thanks. We'll see what the autobuilders have to say :-)

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] protobuf: bump to 2.6.1

[Thomas Petazzoni]

Dear Steven Noonan,

On Wed,  4 Nov 2015 00:37:21 -0800, Steven Noonan wrote:
> Signed-off-by: Steven Noonan <steven@uplinklabs.net>
> ---
>  package/protobuf/protobuf.hash | 2 ++
>  package/protobuf/protobuf.mk   | 2 +-
>  2 files changed, 3 insertions(+), 1 deletion(-)
>  create mode 100644 package/protobuf/protobuf.hash

This is breaking the build of python-protobuf:
http://autobuild.buildroot.net/results/16e/16e8c41f3b6627ecee96fcf5ab3b22f1b7513ba4/build-end.log.

The problem is that python-protobuf now has some additional
dependencies, which setuptools tries to download automatically. You
probably haven't seen this on your machine because it automatically
downloads the needed dependencies. It appears on the autobuilders
because https:// downloads fail.

This should be fixed by:

 1/ Ensuring that setuptools does not download dependencies
    automatically

 2/ Packaging the appropriate python-protobuf dependencies.

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] protobuf: bump to 2.6.1

[Steven Noonan]

On Sun, Nov 8, 2015 at 7:49 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Steven Noonan,

You can just call me "Steven"...

>
> On Wed,  4 Nov 2015 00:37:21 -0800, Steven Noonan wrote:
>> Signed-off-by: Steven Noonan <steven@uplinklabs.net>
>> ---
>>  package/protobuf/protobuf.hash | 2 ++
>>  package/protobuf/protobuf.mk   | 2 +-
>>  2 files changed, 3 insertions(+), 1 deletion(-)
>>  create mode 100644 package/protobuf/protobuf.hash
>
> This is breaking the build of python-protobuf:
> http://autobuild.buildroot.net/results/16e/16e8c41f3b6627ecee96fcf5ab3b22f1b7513ba4/build-end.log.
>
> The problem is that python-protobuf now has some additional
> dependencies, which setuptools tries to download automatically. You
> probably haven't seen this on your machine because it automatically
> downloads the needed dependencies. It appears on the autobuilders
> because https:// downloads fail.

I just looked at this. Nasty. These "dependencies" are only needed at
'setup.py build' time, and not runtime. I have trouble believing it
really needs these at all. Might be able to simply gut the build-time
dependencies.

> This should be fixed by:
>
>  1/ Ensuring that setuptools does not download dependencies
>     automatically
>
>  2/ Packaging the appropriate python-protobuf dependencies.
>
> Thanks,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

[Buildroot] [PATCH] protobuf: bump to 2.6.1

[Steven Noonan]

On Sun, Nov 8, 2015 at 8:57 AM, Steven Noonan <steven@uplinklabs.net> wrote:
> On Sun, Nov 8, 2015 at 7:49 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>> Dear Steven Noonan,
>
> You can just call me "Steven"...
>
>>
>> On Wed,  4 Nov 2015 00:37:21 -0800, Steven Noonan wrote:
>>> Signed-off-by: Steven Noonan <steven@uplinklabs.net>
>>> ---
>>>  package/protobuf/protobuf.hash | 2 ++
>>>  package/protobuf/protobuf.mk   | 2 +-
>>>  2 files changed, 3 insertions(+), 1 deletion(-)
>>>  create mode 100644 package/protobuf/protobuf.hash
>>
>> This is breaking the build of python-protobuf:
>> http://autobuild.buildroot.net/results/16e/16e8c41f3b6627ecee96fcf5ab3b22f1b7513ba4/build-end.log.
>>
>> The problem is that python-protobuf now has some additional
>> dependencies, which setuptools tries to download automatically. You
>> probably haven't seen this on your machine because it automatically
>> downloads the needed dependencies. It appears on the autobuilders
>> because https:// downloads fail.
>
> I just looked at this. Nasty. These "dependencies" are only needed at
> 'setup.py build' time, and not runtime. I have trouble believing it
> really needs these at all. Might be able to simply gut the build-time
> dependencies.

Pffbbbt.

It looks like it's probably as simple as:

diff --git a/python/setup.py b/python/setup.py
index 2450a77..6f6bffb 100755
--- a/python/setup.py
+++ b/python/setup.py
@@ -189,7 +189,6 @@ if __name__ == '__main__':
           'google.protobuf.text_format'],
         cmdclass = { 'clean': clean, 'build_py': build_py },
         install_requires = ['setuptools'],
-        setup_requires = ['google-apputils'],
         ext_modules = ext_module_list,
         url = 'https://developers.google.com/protocol-buffers/',
         maintainer = maintainer_email,


>> This should be fixed by:
>>
>>  1/ Ensuring that setuptools does not download dependencies
>>     automatically
>>
>>  2/ Packaging the appropriate python-protobuf dependencies.
>>
>> Thanks,
>>
>> Thomas
>> --
>> Thomas Petazzoni, CTO, Free Electrons
>> Embedded Linux, Kernel and Android engineering
>> http://free-electrons.com

[Buildroot] [PATCH] package/python-protobuf: eliminate unneeded build-time dependencies

[Steven Noonan]

This was causing unexpected HTTP requests by the setup.py script for
python-protobuf. These "dependencies" aren't actually required for a successful
build, and are not staged into the target install directory.

Signed-off-by: Steven Noonan <steven@uplinklabs.net>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 ...2.6.1-disable-unneeded-build-dependencies.patch | 37 ++++++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 package/python-protobuf/protobuf-2.6.1-disable-unneeded-build-dependencies.patch

diff --git a/package/python-protobuf/protobuf-2.6.1-disable-unneeded-build-dependencies.patch b/package/python-protobuf/protobuf-2.6.1-disable-unneeded-build-dependencies.patch
new file mode 100644
index 0000000..3f0eabd
--- /dev/null
+++ b/package/python-protobuf/protobuf-2.6.1-disable-unneeded-build-dependencies.patch
@@ -0,0 +1,37 @@
+From 7e7db7225e227905acabfa2149152ece21c93e70 Mon Sep 17 00:00:00 2001
+From: Steven Noonan <steven@uplinklabs.net>
+Date: Sun, 8 Nov 2015 09:03:00 -0800
+Subject: [PATCH] python-protobuf: don't require google-apputils
+
+This dependency is totally superfluous for successfully building/running
+python-protobuf. It's only "required" at build time and is not staged into the
+install directory, but it isn't even really required for a successful build.
+
+Signed-off-by: Steven Noonan <steven@uplinklabs.net>
+---
+ python/setup.py | 2 --
+ 1 file changed, 2 deletions(-)
+
+diff --git a/python/setup.py b/python/setup.py
+index 2450a77..db6f497 100755
+--- a/python/setup.py
++++ b/python/setup.py
+@@ -160,7 +160,6 @@ if __name__ == '__main__':
+         packages = [ 'google' ],
+         namespace_packages = [ 'google' ],
+         test_suite = 'setup.MakeTestSuite',
+-        google_test_dir = "google/protobuf/internal",
+         # Must list modules explicitly so that we don't install tests.
+         py_modules = [
+           'google.protobuf.internal.api_implementation',
+@@ -189,7 +188,6 @@ if __name__ == '__main__':
+           'google.protobuf.text_format'],
+         cmdclass = { 'clean': clean, 'build_py': build_py },
+         install_requires = ['setuptools'],
+-        setup_requires = ['google-apputils'],
+         ext_modules = ext_module_list,
+         url = 'https://developers.google.com/protocol-buffers/',
+         maintainer = maintainer_email,
+-- 
+2.6.2
+
-- 
2.6.2

[Buildroot] [PATCH] protobuf: bump to 2.6.1

[Thomas Petazzoni]

Hello,

On Sun, 8 Nov 2015 08:59:07 -0800, Steven Noonan wrote:

> It looks like it's probably as simple as:
> 
> diff --git a/python/setup.py b/python/setup.py
> index 2450a77..6f6bffb 100755
> --- a/python/setup.py
> +++ b/python/setup.py
> @@ -189,7 +189,6 @@ if __name__ == '__main__':
>            'google.protobuf.text_format'],
>          cmdclass = { 'clean': clean, 'build_py': build_py },
>          install_requires = ['setuptools'],
> -        setup_requires = ['google-apputils'],
>          ext_modules = ext_module_list,
>          url = 'https://developers.google.com/protocol-buffers/',
>          maintainer = maintainer_email,

Can you submit this as a proper patch ?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] protobuf: bump to 2.6.1

[Thomas Petazzoni]

Steven,

On Mon, 9 Nov 2015 21:34:20 +0100, Thomas Petazzoni wrote:

> Can you submit this as a proper patch ?

Sorry, you already did so. Sorry for the noise :-/

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] package/python-protobuf: eliminate unneeded build-time dependencies

[Thomas Petazzoni]

Steven,

On Sun,  8 Nov 2015 09:08:09 -0800, Steven Noonan wrote:
> This was causing unexpected HTTP requests by the setup.py script for
> python-protobuf. These "dependencies" aren't actually required for a successful
> build, and are not staged into the target install directory.

The reference to the autobuild is missing. It should contain:

Fixes:

	http://autobuild.buildroot.org/results/e44/e44694f30e39266491a1040e284e504d6d37ef9e/

> 
> Signed-off-by: Steven Noonan <steven@uplinklabs.net>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

(I have verified that your patch fixes the build problem in the minimal
chroot I use for Buildroot testing in my autobuilder instance)

> +++ b/package/python-protobuf/protobuf-2.6.1-disable-unneeded-build-dependencies.patch

This file name is not correct according to our patch naming policy. It
should be 0001-disable-unneeded-build-dependencies.patch.

Also, can you submit this change upstream ?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] package/python-protobuf: eliminate unneeded build-time dependencies

[Steven Noonan]

On Mon, Nov 9, 2015 at 1:08 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Steven,
>
> On Sun,  8 Nov 2015 09:08:09 -0800, Steven Noonan wrote:
>> This was causing unexpected HTTP requests by the setup.py script for
>> python-protobuf. These "dependencies" aren't actually required for a successful
>> build, and are not staged into the target install directory.
>
> The reference to the autobuild is missing. It should contain:
>
> Fixes:
>
>         http://autobuild.buildroot.org/results/e44/e44694f30e39266491a1040e284e504d6d37ef9e/

OK. I'll add that and rename the patch file later this evening.

>>
>> Signed-off-by: Steven Noonan <steven@uplinklabs.net>
>> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>
> Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>
> (I have verified that your patch fixes the build problem in the minimal
> chroot I use for Buildroot testing in my autobuilder instance)

Good to hear. :)

>> +++ b/package/python-protobuf/protobuf-2.6.1-disable-unneeded-build-dependencies.patch
>
> This file name is not correct according to our patch naming policy. It
> should be 0001-disable-unneeded-build-dependencies.patch.
>
> Also, can you submit this change upstream ?

Upstream would make use of the lines we're removing. It's intended for
running their unit tests, which we don't use when building it.

[Buildroot] [PATCH] package/python-protobuf: eliminate unneeded build-time dependencies

[Thomas Petazzoni]

Steven,

On Mon, 9 Nov 2015 14:07:36 -0800, Steven Noonan wrote:

> Upstream would make use of the lines we're removing. It's intended for
> running their unit tests, which we don't use when building it.

Can we find a way that is upstreamable, like some setup.py option or
environment variable to disable the build/installation of unit tests?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] package/python-protobuf: eliminate unneeded build-time dependencies

[Steven Noonan]

On Mon, Nov 9, 2015 at 2:10 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Steven,
>
> On Mon, 9 Nov 2015 14:07:36 -0800, Steven Noonan wrote:
>
>> Upstream would make use of the lines we're removing. It's intended for
>> running their unit tests, which we don't use when building it.
>
> Can we find a way that is upstreamable, like some setup.py option or
> environment variable to disable the build/installation of unit tests?
>

Maybe, I'll think about how it could be done.

[Buildroot] [PATCH] package/python-protobuf: eliminate unneeded build-time dependencies

[Steven Noonan]

On Mon, Nov 9, 2015 at 2:12 PM, Steven Noonan <steven@uplinklabs.net> wrote:
> On Mon, Nov 9, 2015 at 2:10 PM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>> Steven,
>>
>> On Mon, 9 Nov 2015 14:07:36 -0800, Steven Noonan wrote:
>>
>>> Upstream would make use of the lines we're removing. It's intended for
>>> running their unit tests, which we don't use when building it.
>>
>> Can we find a way that is upstreamable, like some setup.py option or
>> environment variable to disable the build/installation of unit tests?
>>
>
> Maybe, I'll think about how it could be done.

I investigated upstream's master branch state before doing too much
and found this:

https://github.com/google/protobuf/commit/9f42f5f4a423b923f7b07ae8c5e8db4943df49c6

(It doesn't apply to 2.6.1, but this does show that protobuf 3.x will
not have the unneeded dependency.)

So the upstream work has already been done.

[Buildroot] [PATCH] package/python-protobuf: eliminate unneeded build-time dependencies

[Thomas Petazzoni]

Hello,

On Mon, 9 Nov 2015 17:28:58 -0800, Steven Noonan wrote:

> > Maybe, I'll think about how it could be done.
> 
> I investigated upstream's master branch state before doing too much
> and found this:
> 
> https://github.com/google/protobuf/commit/9f42f5f4a423b923f7b07ae8c5e8db4943df49c6
> 
> (It doesn't apply to 2.6.1, but this does show that protobuf 3.x will
> not have the unneeded dependency.)
> 
> So the upstream work has already been done.

Alright, thanks for looking into this. I guess your patch is then
perfectly fine in the meantime.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com