apport fails to file bugreports

The problem seems to be either launchpad or py-lp-bugs. The .info() object returned by calling https://launchpad.net/+storeblob does not contain a 'X-Launchpad-Blob-Token' entry, so storeblob.upload() returns None, and this result in an AssertionError in apport.

result of print result.info() in storeblob.py line 75:
Date: Thu, 18 Dec 2008 11:37:11 GMT
Server: zope.server.http (HTTP)
X-Powered-By: Zope (www.zope.org), Python (www.python.org)
Content-Length: 6763
Content-Type: text/html;charset=utf-8
Via: 1.1 launchpad.net
Vary: Accept-Encoding
Connection: close

Markus

Fixed in lp:python-launchpad-bugs rev 169. The name of a field was changed in the recent lp update

- { 'FORM_SUBMIT': '1', 'field.blob': blob })
+ { 'field.actions.continue': '1', 'field.blob': blob })

Markus

Do old versions of apport exist, that depend of the field name being FORM_SUBMIT? We had a test to ensure that the field names wouldn't be changed, but a change to it slipped through anyway.

If you want, we could change it back (if older versions of apport need it).

Here's a debdiff for Hardy.

And one for Intrepid.

And one of Jaunty!

Yes, there are some stable releases out there that depend on the field name being FORM_SUBMIT. I've already done the work of creating the new package versions but some testing may need to be done for the stable releases. How long would it take to get Launchpad updated?

On Thu, Dec 18, 2008 at 10:15:58PM -0000, Brian Murray wrote:
> Yes, there are some stable releases out there that depend on the field
> name being FORM_SUBMIT. I've already done the work of creating the new
> package versions but some testing may need to be done for the stable
> releases. How long would it take to get Launchpad updated?

We would update Launchpad tomorrow. Should we go ahead and fix it in
Launchpad?

    affects malone
    status triaged
    importance high
    milestone 2.1.12

Yes, that would be the ideal solution. Thanks!

ok, cool, I'm fine with a solution on launchpad's side, we have to remember to revert my "fixes" in the py-lp-bugs branches

Fixed in RF 7475. This fix should be in production later today.

Thanks. so can you place it fix available by then?

Björn - you indicated that this slipped by a test. Has the test been changed to catch this? I'm curious because we are asking more and more reporters to use 'apport-cli' or 'ubuntu-bug' to report bug reports since a lot of information is gathered automatically.

On Fri, Dec 19, 2008 at 04:45:42PM -0000, Brian Murray wrote:
> Björn - you indicated that this slipped by a test. Has the test been
> changed to catch this? I'm curious because we are asking more and more
> reporters to use 'apport-cli' or 'ubuntu-bug' to report bug reports
> since a lot of information is gathered automatically.

Yes, I've change the test to make it more obvious that it shouldn't be
changed.

We do have a test for making sure that Apport works. What happened was
that someone modified the test when it started to fail, instead of
changing the code to make the original test pass. I've modified it so
that the same thing doesn't happen again.

The fix is now in production, and Apport should work again. I managed to get to the +filebug page through the "Report a Problem" option in Firefox.

When trying to report a bug via ubuntu-bug I will always get directed to "Lost something?" page. When trying the "Report a Problem" option in Firefox everything seems to be ok.

Aethralis: this is another bug in launchpad. As a workaround, wait a few seconds and refresh the page, you should see the "Report a bug"-page then.

I've reverted the change in revision 171, http://bazaar.launchpad.net/~bughelper-dev/python-launchpad-bugs/main/revision/171 , of python-launchpad-bugs and I'm marking this task as Invalid since the bug was resolved in Launchpad.