NoFinalPath import failures (gnome-orca, paramiko, gwibber, udev, etc)

[Vincent Ladeuil]

Hey,

Nothing better than cracking a nutty bug before leaving for vacations ;)

I just realized that 2.3.4 (recently deployed on jubany (reverted from
2.4b4)) included the fix for the NoFinalPath import failures (31
packages including gnome-orca, paramiko, gwibber, udev, ktorrent, some
xserver stuff (4 packages), some xfce4 (2), etc). So I didn't have to
wait for 2.4b5 to reach jubany through the cat archive and so on.

We now have 22 more successful imports. \o/

And one less cause of blocked imports.

The remaining 9 mutated into:

- 7 AppendRevisionsOnlyViolation failures (make the corresponding bug
  even more juicy ;)

-  1 UnicodeDecodeError

- 1 HTTP 404 (wait, really ? Must be a joke... No it isn't ;)

All the involved packages had a pending broken lock (almost all of them
in their updates/.../oneiric branch) which I broke[1] before requeuing
them. 

Note that there are two kinds of AppendRevisionsOnlyViolation errors:

*   37 packages failed with key bzrlib.errors.AppendRevisionsOnlyViolation:<module>:main:import_package:import_package:_do_import_package:pull_version_from_branch:pull_write_locked:pull:pull:pull_write_locked:pull:_pull:update_revisions:update_revisions_write_locked:update_revisions:set_last_revision_info_write_locked:set_last_revision_info:_check_history_violation

    anjuta-extras bobcat csound drapes enigmail garmin-forerunner-tools goffice gpsd gvfs icinga ikvm json-glib kde4libs kdebindings kdenetwork kdepimlibs konq-plugins ktorrent libcap-ng libevent libffi libmailtools-perl libverilog-perl libxcursor libxrandr mistelix ocaml-dtools open-cobol pacpl pino pyfribidi pygobject python2.7 qjackctl schroot sexplib310 telepathy-mission-control-5 

*   5 packages failed with key bzrlib.errors.AppendRevisionsOnlyViolation:<module>:main:import_package:import_package:_import_native_package:pull_version_from_branch:pull_write_locked:pull:pull:pull_write_locked:pull:_pull:update_revisions:update_revisions_write_locked:update_revisions:set_last_revision_info_write_locked:set_last_revision_info:_check_history_violation

    apt dwww git-buildpackage x11-utils xfonts-utils 

The 7 failures are all in the first instance, it may help debug it to
have 7 additional cases to write the corresponding test ;)

With a bit of luck, writing the test for the second instance, will
demonstrate that a single fix is needed for both instances.

Happy hacking !

     Vincent

[1]: It would be nice if the import process was split into parts around
which we could handle the errors better. In this NoFinalPath case, we
can either fix bzr to not leave a broken lock, or more defensively, add
a check that an import never leave a broken lock, whatever the bug is
(or both, that's the same code after all). Note that the NoFinalPath was
happening during the logs/merges/ (or is it www/merges now ?) file
generation which is not yet used in production, so we shouldn't block an
import for that.