#357 a workaround for 64bits long int xmlrpc processing
Closed by julian8628. Opened by julian8628.
julian8628/koji 64bits-xmlrpc  into  master

Download 357.patch

the issue is from #koji irc channel

[22:26:12] aboccia_: greetings koji community, I recently built texlive which is a massive pkg into my private koji instance. When i query it in the system I seem to be hitting an int limit with the xmlrpc call.
[22:26:13] aboccia_: xmlrpclib.Fault: : long int exceeds XML-RPC limits">
[22:26:38] aboccia_: any way this can be changed without poking at code, I am also on a much older version of koji 1.9, planning on doing an upgrade.
[22:26:55] aboccia_: Curious if anyone has any info off the bat regarding possible fixes/workarounds.

But no xml data provided.
I'm not sure all long integers are transformed outside kojixmlrpc, so put this workaround here

It is unclear how broadly this xmlrpc extension is supported.

i8 is not the only part of the Apache xmlrpc extensions. There are several more:
https://ws.apache.org/xmlrpc/types.html

Python's xmlrpc unmarshaller appears to understand i8 at least, though it has not always. The python 2.4 version on RHEL5 does not for example. And not all Koji clients are written in Python.

This is actually a rather significant API change.

What we have done in the past with large values like this is convert them to strings. See the encode_int() function. That is not a terribly satisfactory answer either, but at least it is valid xmlrpc.

1.9 is three years old

I'm not sure which value is overflowing in this user's case, but I suspect it is the rpm file size. In which case, there is already a fix in place (using encode_int).

I found the commit to supply encode_int for rpm size is 37c6eed562dc5937a25095f8f88e5e85d577752d
It's after when 1.9 released.

That makes sense for the reason of the supporting to various xmlrpc clients and python versions.

Cancel this PR.

Pull-Request has been closed by julian8628

Metadata