This failure blocks cassandra module building.

For the case the build.log is not kept, this is the error I see:
Buildfile: /builddir/build/BUILD/thrift-0.10.0/tutorial/java/build.xml
init:
    [mkdir] Created dir: /builddir/build/BUILD/thrift-0.10.0/tutorial/java/build
    [mkdir] Created dir: /builddir/build/BUILD/thrift-0.10.0/tutorial/java/build/log
generate:
compile:
    [javac] Compiling 7 source files to /builddir/build/BUILD/thrift-0.10.0/tutorial/java/build
    [javac] /builddir/build/BUILD/thrift-0.10.0/tutorial/java/gen-java/tutorial/Work.java:157: error: no suitable method found for copyBinary(Operation)
    [javac]       this.op = org.apache.thrift.TBaseHelper.copyBinary(other.op);
    [javac]                                              ^
    [javac]     method TBaseHelper.copyBinary(ByteBuffer) is not applicable
    [javac]       (argument mismatch; Operation cannot be converted to ByteBuffer)
    [javac]     method TBaseHelper.copyBinary(byte[]) is not applicable
    [javac]       (argument mismatch; Operation cannot be converted to byte[])
    [javac] 1 error

Created attachment 1348896 [details]
buildroot diff

Adding buildroot diff between the last successful thrift build (https://koji.fedoraproject.org/koji/taskinfo?taskID=21734894) and the failing one (https://koji.fedoraproject.org/koji/taskinfo?taskID=22799153)

I have no idea what's wrong on s390x arch. The generated code seems to be different there, but I'm not sure why. The line in x86_64 is simply:

  this.op = other.op;

The problem appears to be on line 4662 in:
./compiler/cpp/src/thrift/generate/t_java_generator.cc

I'm not certain, but I believe the cast to `(t_base_type*)` is not guarded by a check of `type->is_base_type()`, so it's somehow casting an enum type (Operation) to something where `is_binary()` is true only on s390x arch. Enums aren't binary types, so it should go to the else, but it's not.

I don't know if another `is_base_type()` check is appropriate, or a `&& !type->is_enum()`.

Should probably investigate this bug with upstream and patch accordingly.

I'm clearing the NEEDINFO flag, since no information was requested from any maintainer. However, I'm happy to help get the fix in place, if somebody can get upstream to take a look and confirm the bug and its fix.

It could be a larger issue on the s390x arch, if `is_binary()` is expected to return false for enums, but is incorrectly returning true. Could be a bug in a dependent library? Maybe boost? I don't do much C++ programming, so I'm close to my limit in my ability to debug. Really need upstream to take a look.

I filed an upstream bug at https://issues.apache.org/jira/browse/THRIFT-4380

Let me know if someone needs access to a Fedora s390x system for further debugging.

I still haven't heard anything from upstream. If anybody else can suggest a path forward, I would appreciate it.

Created attachment 1365446 [details]
Proposed patch

Hey, according to a scratch build the attached patch fixes the issue. I think this was more luck than anything else, since I don't really understand the code, but it looks like a copy&paste error. Anyway, please, take a look and possibly apply.

(In reply to Honza Horak from comment #8)
> Created attachment 1365446 [details]
> Proposed patch
> 
> Hey, according to a scratch build the attached patch fixes the issue. I
> think this was more luck than anything else, since I don't really understand
> the code, but it looks like a copy&paste error. Anyway, please, take a look
> and possibly apply.

Awesome. Thanks. Have you submitted (or do you mind if I do) the patch to upstream Thrift?

https://issues.apache.org/jira/browse/THRIFT-4380

(In reply to Christopher Tubbs from comment #9)
> Awesome. Thanks. Have you submitted (or do you mind if I do) the patch to
> upstream Thrift?
> 
> https://issues.apache.org/jira/browse/THRIFT-4380

I did not actually. Since I'm not really a Java developer, I'd prefer if someone else who understands Java more to submits it to upstream, for the case there are some more questions.. Is it possible that you could submit it?

I never got a response from upstream, but they seem to have patched it in the latest version. I'm testing a backport of the fix to 0.10.0, because I'm not quite ready to test the latest version, 0.11.0.

thrift-0.10.0-8.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-4184b7b2d7

thrift-0.10.0-8.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-037fb08938

thrift-0.10.0-8.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-037fb08938

thrift-0.10.0-8.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-4184b7b2d7

thrift-0.10.0-8.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.

thrift-0.10.0-8.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.