Description of problem: Upon running a bugtool or bugzuki query I get an xmlrpc error Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Download bugtool 2. Install 3. run bugtool from a terminal 4. Select one of the queries Actual results: xmlrpclib.Fault: <Fault 1: 'error decoding RPC.\n\nnot well-formed (invalid token) at line 1, column 8, byte 8 at /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/XML/Parser.pm line 185\n'> Expected results: Query runs (as I have been doing at least weekly) and returns Additional info:
Apologies wrong stack trace - I was running against a local bugzilla instance. I guess this is now closed down for external access: xmlrpclib.ProtocolError: <ProtocolError for bugzilla.redhat.com/bugzilla/xmlrpc.cgi: 403 Forbidden> Can you confirm this is the case.
OK, bugtool was set to go against http not https by default (will let jrb know). Tested with a clean install of bugtool s/http/https/ and ensured pointing at bugzilla.redhat.com back to original error: xmlrpclib.Fault: <Fault 1: 'error decoding RPC.\n\nnot well-formed (invalid token) at line 1, column 8, byte 8 at /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/XML/Parser.pm line 185\n' sorry for the line noise.
Retested today without changing anything this end is now working fine. Closing as WORKSFORME as can't really say anything else
There was an error in the way the CGI data was being parsed. Something was adding a POSTDATA= to the beginning of the POST body which was causing the XMLRPC libraries to freak out. Removal of the POSTDATA= from the beginning of the string using a regex allowed everything to work again. Still looking into why that was being added in the first place since the regex is considered a workaround and not a fix.