Ubuntu
protobuf package

protobuf 2.0.2-1 (universe) FTBFS on ia64 and sparc

Bug #308829 reported by Manny Vindiola
4
Affects Status Importance Assigned to Milestone
protobuf (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

merge of protobuf 2.0.2-1 (universe) from debian unstable FTBFS on ia64 and sparc architectures

ia64 build log:
http://launchpadlibrarian.net/20275404/buildlog_ubuntu-jaunty-ia64.protobuf_2.0.2-1ubuntu1_FAILEDTOBUILD.txt.gz

sparc build log:
http://launchpadlibrarian.net/20314713/buildlog_ubuntu-jaunty-sparc.protobuf_2.0.2-1ubuntu1_FAILEDTOBUILD.txt.gz

I have tracked down the problems from upstream and have patched the appropriate files. A description follows.

ia64:
gtest attempts to perform death tests using clone(2). clone(2) is not available on ia64 architectures and as a result build fails. gtest developers provide a fix that disables death tests if the system is an ia64 architecture. The patch is available here: http://codereview.appspot.com/8690/show . I had to adapt the patch a little bit because their source is a later revision than the one in the debian package.

sparc:

Fixed alignment issue that caused bus errors on platforms like sparc which
require all memory reads to be aligned. Specifically, it turns out that
sizeof(RepeatedField<bool>) is 20 on 64-bit sparc with GCC 3.4.6. This is
strange, since one of RepeatedField's members is a pointer, which I thought
meant that it had to be 64-bit aligned, which means its size should be a
multiple of 64 bits. But, 20 is not a multiple of 8. I don't understand why
this is the case, but if this is possible, then DynamicMessage's strategy of
sorting fields in descending order by size and then tightly packing doesn't
work. To fix this, I got rid of the sort step and instead added code that
aligns each field's offset appropriately based on the field's size.

Fix taken directly from upstream:
http://code.google.com/p/protobuf/source/detail?spec=svn72&r=72

I am running i386 architecture so I have not been able to test build these changes but the package continues to build correctly on i386.

Revision history for this message
Manny Vindiola (serialorder) wrote :

I have attached the debdiff between ubuntu1 and ubunt2.
builds correctly on i386
unable to test on sparc of ia64

Manny Vindiola (serialorder)
Changed in protobuf:
status: New → Confirmed
Revision history for this message
Daniel Holbach (dholbach) wrote :

Do you think it would make sense to update the version in Jaunty to 2.0.3 instead?

Revision history for this message
Manny Vindiola (serialorder) wrote :

I think that makes sense. In fact I was going to suggest that but I wasn't sure what the policy was on bringing in a package newer than the version in debian. Elliot what do you think of this? Do you want to take care of it or should I?

Revision history for this message
Elliot Murphy (statik) wrote : Re: [Bug 308829] Re: protobuf 2.0.2-1 (universe) FTBFS on ia64 and sparc

On 12/17/2008 02:37 PM, Manny Vindiola wrote:
> I think that makes sense. In fact I was going to suggest that but I
> wasn't sure what the policy was on bringing in a package newer than the
> version in debian. Elliot what do you think of this? Do you want to take
> care of it or should I?
>

Manny if you have time to do it that would be awesome! Just this morning
I was thinking that we should probably bring in 2.0.3, but haven't had
time to look at it.

--
Elliot Murphy | https://launchpad.net/~statik/

Revision history for this message
Manny Vindiola (serialorder) wrote :

Actually I have never actually packaged anything from scratch before. Mostly I have worked on merges and a few bug fixes. I have been eager to actually try my hand at packaging something. Would I do it like it was a new package or is there another method when the package is already in ubuntu?

Revision history for this message
Elliot Murphy (statik) wrote :

Daniel made a really cool YouTube video about how to update a package
to a new upstream version, it's about 10 minutes long. After watching
the video, feel free to ask in #ubuntu-motu if you have questions, and
you can let me know if you get completely stuck and I'll do my best to
help.

--
Elliot Murphy

On Dec 17, 2008, at 18:03, Manny Vindiola <email address hidden> wrote:

> Actually I have never actually packaged anything from scratch before.
> Mostly I have worked on merges and a few bug fixes. I have been
> eager to
> actually try my hand at packaging something. Would I do it like it
> was a
> new package or is there another method when the package is already in
> ubuntu?
>
> --
> protobuf 2.0.2-1 (universe) FTBFS on ia64 and sparc
> https://bugs.launchpad.net/bugs/308829
> You received this bug notification because you are subscribed to
> protobuf in ubuntu.
>

Revision history for this message
Michael Casadevall (mcasadevall) wrote :

I'm testing this now on sparc. If it builds there, I'll sponsor the upload.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package protobuf - 2.0.3-0ubuntu1

---------------
protobuf (2.0.3-0ubuntu1) jaunty; urgency=low

  * Merge from new upstream version (LP: #309237), remaining changes:
     * debian/control Moving python-support from Build-Depends-Indep
       to Build-Depends to fix build failures.
  * Fix FTBFS on ia64 architecture due to lack of clone(2)
     - src/gtest/internal/gtest-port.h (LP: #308829)
       disable death tests if architecture is IA64
       adapted from gtest upstream fix at:
       http://codereview.appspot.com/8690/show
  * Fix FTBFS on x64 architectures due to python 2.x int vs long issue
    test expects return type long but on x64 architecture return type
    unpacks to int
     -python/google/protobuf/internal/decoder_test.py
      explicitly type the result value as long
     taken from upstream discussion:
     http://groups.google.com/group/protobuf/browse_thread
         /thread/2357176cb1f50e10/

 -- Manny Vindiola <email address hidden> Thu, 18 Dec 2008 01:26:29 -0500

Changed in protobuf:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.