checkwatches on non-debian debbugs instances do not work

This could be a result of our copy of the debbugs database being out of date (at least that's what the OOPS seems to suggest). I'll do some testing with a sysadmin to confirm this.

Ping? This is still happening.

And for the record, the bug tracker was moved to debbugs.gnu.org some months ago, but the Launchpad information about the bug tracker has been updated to point to the right place. The links still work but the audit trail shows a bunch of OOPSes.

E.g. https://bugs.launchpad.net/bugs/243156/+watch/52216 and generally I think all the open watches (i.e. other than Status = done) listed at https://bugs.launchpad.net/bugs/bugtrackers/auto-debbugs.gnu.org

On 30 August 2010 16:35, era <email address hidden> wrote:
> And for the record, the bug tracker was moved to debbugs.gnu.org some
> months ago, but the Launchpad information about the bug tracker has been
> updated to point to the right place.  The links still work but the audit
> trail shows a bunch of OOPSes.
>

So, the problem here is that we aren't currently updating the debbugs
database due to diskspace issues on the server that hosts it (we sync
the entire debbugs DB to that host). We're working on increasing the
diskspace available; hopefully this should be resolved soon.

--
Graham Binns | PGP Key: EC66FA7D
http://launchpad.net/~gmb

Ping? Define "soon"?

@Graham, this is a different debbugs db :)

@era we haven't updated our code to deal with multiple debbugs instances yet.

See also bug #704297

Also for the record the tracker has been renamed and is now at https://bugs.launchpad.net/bugs/bugtrackers/gnu-debbugs

So, we'd love to support this. Its probably fairly straight forward to do, but it will need some code patches. Would you like us to mentor you on doing that?

Supporting this isn't currently in our roadmap, though, so I'm going to mark this as Low.

I am open to mentoring but unable to commit to working on Launchpad code.

If you can explain why adding a remote watch says "There are some problems" when you add a valid URL, that would be a useful starting point both for myself and anybody else who runs into this problem.

(For what it's worth, the latest instance happened to me in LP#1466139)

debbugs bug syncing isn't handled by simple HTTP fetches; it works by rsyncing the bug database and parsing it directly, so it's much more involved than just providing a valid URL. At the moment the code in lib/lp/bugs/externalbugtracker/debbugs.py is hardcoded to deal with just one such rsynced database; any work on fixing this bug would need to start by adding support for an rsynced database per tracker.

Alternatively, it might be worth exploring whether the SOAP interface that IIRC debbugs has these days could be used instead of the rsynced mirror. I don't know whether the instance on gnu.org supports this, though.

Personally, I would already be happier if it was possible to add an upstream bug link for human consumption, but my repeated bug reports have all been closed and abandoned. I see bugs against Emacs which have correct uplink bug watches, even though the actual watching functionality seems to be hosed, so it's apparently possible to add them somehow, but my attempts always fail with a completely unconspicuous error message. Should I report that as a separate bug (again?) or try to revive one of the bug reports I submitted before?