Please add a pointer to a specific Alpha Release criteria
when adding an alpha blocker.

Actually it's not abrt fault that xmlrpc-c can't provide automatic redirect (301 Moved Permanently). It should be fixed on xmlrpc-c or curl

(In reply to comment #1)
> Please add a pointer to a specific Alpha Release criteria
> when adding an alpha blocker.    

abrt not being able to talk to Fedora bugzilla falls under the "dramatically reduces test coverage" criterium, I think

http://fedoraproject.org/wiki/Fedora_13_Alpha_Release_Criteria#Alpha_Blocker_Bugs

Or
http://fedoraproject.org/wiki/Fedora_14_Alpha_Release_Criteria#Alpha_Blocker_Bugs

Thanks - it is working for me though.

Anyone else?  I don't think this is an ALpha blocker.

Damn, I remember this has come up before and we didn't codify a criterion to cover it.

I personally think we *need* abrt to work for Alpha, but in this case it works, there's a problem with submission, so I don't think this is quite a blocker. I'd definitely like to have it fixed, though.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

it's probably trivial by adding a patch which sets CURLOPT_FOLLOWLOCATION + CURLOPT_POSTREDIR.

Nevertheless, rfc 2616 says

   If the 301 status code is received in response to a request other
   than GET or HEAD, the user agent MUST NOT automatically redirect the
   request unless it can be confirmed by the user...

e.g. the correct way would be that xmlrpc-c reports the redirection to abrt, abrt asks the user whether to follow it and issues the new request.


There are security considerations too, e.g. when there would be a redirection to bugzilla.fedoraproject.org, the CURLOPT_UNRESTRICTED_AUTH must be set too.  But user entered password for bugzilla.redhat.com only and might not want that it is transferred to another server.


Why not use the correct URI in /etc/abrt/plugins/Bugzilla.conf?

(In reply to comment #8)
 
> Why not use the correct URI in /etc/abrt/plugins/Bugzilla.conf?    


/etc/abrt/plugins/Bugzilla.conf only rerefences the root bugzilla address, ie https://bugzilla.redhat.com

This is correct as it's probably the only thing the user knows

I have no idea why this results in a redirection

I updated rawhide and added a patch; but it fails to build atm

(In reply to comment #8)
> it's probably trivial by adding a patch which sets CURLOPT_FOLLOWLOCATION +
> CURLOPT_POSTREDIR.
> 
> Nevertheless, rfc 2616 says
> 
>    If the 301 status code is received in response to a request other
>    than GET or HEAD, the user agent MUST NOT automatically redirect the
>    request unless it can be confirmed by the user...
> 
> e.g. the correct way would be that xmlrpc-c reports the redirection to abrt,
> abrt asks the user whether to follow it and issues the new request.
> 

Yes, this will help a lot.

> 
> There are security considerations too, e.g. when there would be a redirection
> to bugzilla.fedoraproject.org, the CURLOPT_UNRESTRICTED_AUTH must be set too. 
> But user entered password for bugzilla.redhat.com only and might not want that
> it is transferred to another server.
> 
> 
> Why not use the correct URI in /etc/abrt/plugins/Bugzilla.conf?

    

> /etc/abrt/plugins/Bugzilla.conf only rerefences the root bugzilla address, ie
> https://bugzilla.redhat.com

Also look at gui settings. Gui stores URI into gnome-keyring

This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

As per my comment above and the criteria, this is not a blocker, and we don't think we should add a criterion to make it one (though we probably will for Beta or Final). We certainly would like to see it fixed before Alpha, though. It would be best to have it fixed by Tuesday to make sure that happens. Thanks!



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

(In reply to comment #11)

> > /etc/abrt/plugins/Bugzilla.conf only rerefences the root bugzilla address, ie
> > https://bugzilla.redhat.com
> 
> Also look at gui settings. Gui stores URI into gnome-keyring    

The GUI settings is the same (I started there)

feel free to request a build of the rawhide version. atm, the buildSRPMFromSCM phase fails with an obscure error (http://koji.stg.fedoraproject.org/koji/taskinfo?taskID=2239275) and I am not sure whether I have time to retry it at the weekend or debug the new build process further.

(In reply to comment #15)
> feel free to request a build of the rawhide version. atm, the buildSRPMFromSCM
> phase fails with an obscure error
> (http://koji.stg.fedoraproject.org/koji/taskinfo?taskID=2239275) and I am not
> sure whether I have time to retry it at the weekend or debug the new build
> process further.    

Err, dist-git problem or maybe you have an old fedpkg. Send me directly patch and I will make a build for a testing purpose.

Moving to F14Beta per comment#13.  There is discussion on test.org about appropriately prioritizing ABRT failures (see http://lists.fedoraproject.org/pipermail/test/2010-July/092322.html).

with
xmlrpc-c-1.23.01-1400.svn1958.fc14.x86_64
xmlrpc-c-c++-1.23.01-1400.svn1958.fc14.x86_64
xmlrpc-c-client++-1.23.01-1400.svn1958.fc14.x86_64
xmlrpc-c-client-1.23.01-1400.svn1958.fc14.x86_64

in non-ssl mode, abrt gui now fails with

abrt-gui:   settings:{'Bugzilla': {'SSLVerify': 'no', 'Enabled': 'yes', 'BugzillaURL': 'http://bugzilla.redhat.com/', 'Login': 'x', 'Password': 'y', 'RatingRequired': 'yes'}, 'KerneloopsReporter': {'InformAllUsers': 'yes', 'SysLogFile': '/var/log/messages', 'Enabled': 'yes', 'SubmitURL': 'http://submit.kerneloops.org/submitoops.php'}, 'Logger': {'Enabled': 'yes', 'AppendLogs': 'yes', 'LogPath': '/var/log/abrt.log'}}
abrt-gui: Report() returned
abrt-gui: Update:Connexion à bugzilla...
abrt-gui: Warning:Cannot login. Check Edit->Plugins->Bugzilla and /etc/abrt/plugins/Bugzilla.conf. Server said: libcurl failed to execute the HTTP POST transaction.  SSL connect error
abrt-gui: Update:Reporting via 'Bugzilla' was not successful: Cannot login. Check Edit->Plugins->Bugzilla and /etc/abrt/plugins/Bugzilla.conf. Server said: libcurl failed to execute the HTTP POST transaction.  SSL connect error

And in SSL mode, it fails with

abrt-gui:   settings:{'Bugzilla': {'SSLVerify': 'yes', 'Enabled': 'yes', 'BugzillaURL': 'https://bugzilla.redhat.com/', 'Login': 'x', 'Password': 'y', 'RatingRequired': 'yes'}, 'KerneloopsReporter': {'InformAllUsers': 'yes', 'SysLogFile': '/var/log/messages', 'Enabled': 'yes', 'SubmitURL': 'http://submit.kerneloops.org/submitoops.php'}, 'Logger': {'Enabled': 'yes', 'AppendLogs': 'yes', 'LogPath': '/var/log/abrt.log'}}
abrt-gui: Report() returned
abrt-gui: Update:Connexion à bugzilla...
abrt-gui: Warning:Cannot login. Check Edit->Plugins->Bugzilla and /etc/abrt/plugins/Bugzilla.conf. Server said: libcurl failed to execute the HTTP POST transaction.  SSL connect error
abrt-gui: Update:Reporting via 'Bugzilla' was not successful: Cannot login. Check Edit->Plugins->Bugzilla and /etc/abrt/plugins/Bugzilla.conf. Server said: libcurl failed to execute the HTTP POST transaction.  SSL connect error

can you please set $XMLRPC_TRACE_CURL env?

service abrtd stop
env XMLRPC_TRACE_CURL=1 abrtd -dv

Else, can you trace the network traffic in non-ssl mode and check where the 301 is redirecting to?

I have no idea what env XMLRPC_TRACE_CURL=1 abrtd -dv
 did, but I can not reproduce the bug anymore (I did restart the abrtd service yesterday after the xmlrpc-c update)

Do you mean that the bug is completely gone, or only when XMLRPC_TRACE_CURL is set?  In latter case, there is very likely a bug (vs. missing feature as reported initially) and problem should be analysed with valgrind or so.

(In reply to comment #19)
> abrt-gui: Warning:Cannot login. Check Edit->Plugins->Bugzilla and
> /etc/abrt/plugins/Bugzilla.conf. Server said: libcurl failed to execute the
> HTTP POST transaction.  SSL connect error

This is a problem staring at us right here: xmlrpc's error description is somewhat vague: "SSL error". What kind of SSL error?

Please improve it...

(In reply to comment #22)
> Do you mean that the bug is completely gone, or only when XMLRPC_TRACE_CURL is
> set?  In latter case, there is very likely a bug (vs. missing feature as
> reported initially) and problem should be analysed with valgrind or so.    

I mean I tried it with XMLRPC_TRACE_CURL and it succeeded

Then I started the abrtd service (wasted an hour crashing something and collecting enough debuginfos from koji for abrt to accept the new trace) and it succeeded too.

I still works now

I could not say if XMLRPC_TRACE_CURL unstuck something, if the redirect is gone server-side, of if one of the few other rpms I installed from koji in the meanwhile fixed the problem, but the problem is gone

> xmlrpc's error description is
> somewhat vague: "SSL error". What kind of SSL error?
>
> Please improve it...

that's a problem in curl's nss part; its Curl_nss_connect() function does not fill error information in some execution paths (e.g. when PR_NewTCPSocket() or the setup of various SSL options fails) and returns a generic CURLE_SSL_CONNECT_ERROR only. At a first glance, handling of SSL_ForceHandshakeWithTimeout() errors might return this error too in some cases

feel free to reassign this bug to the curl component or create a new report.

Discussed at today's blocker review meeting. We're tentatively accepting this while we decide whether to accept the proposed criterion that abrt must be able to report bugs at Beta stage.

Do we know exactly what's happening with this yet? Is this a general bug that affects everyone or something specific to Nicolas?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Discussed at today's blocker review meeting. I've filed several bugs via abrt over the last week, so this obviously isn't a complete showstopper. We could really do with knowing exactly what causes this problem and how likely people are to run into it, to decide if it's a blocker.

I just ran through several ABRT test cases on my F-14 system, and ABRT behaved as expected.  For a quick example ... http://fedoraproject.org/wiki/QA:Testcase_ABRT_CCPP_addon

(In reply to comment #26)
> Is this a general bug that
> affects everyone or something specific to Nicolas?

As I wrote in comment 14, I can not reproduce it any more with latest testing updates

(In reply to comment #29)
> (In reply to comment #26)
> > Is this a general bug that
> > affects everyone or something specific to Nicolas?
> 
> As I wrote in comment 14, I can not reproduce it any more with latest testing
> updates

Thanks for the feedback Nicolas!  I'm going to mark this issue as CLOSED CURRENTRELEASE.  Please re-open if the reported issue resurfaces.