(desperate) problem with bzr and launchpad

John Arbash Meinel john at arbash-meinel.com
Sun Sep 17 15:53:14 BST 2006

Hash: SHA1

Ramon Diaz-Uriarte wrote:
> Dear all,
> I am experiencing some problems when Launchpad tries to mirror some
> bzr branches. For example, I get (from
> https://launchpad.net/people/rdiaz02/+branch/rjacgh/main)
> Launchpad could not mirror this branch at 2006-09-16 19:20:17 CEST.
> The error was: No such file:
> 'http://asterias.bioinfo.cnio.es/bzr/RJaCGH/.bzr/repository/knits/c0/%2552%254aa%2543%2547%2548014.pdf-20060712140550-f8dccb44fc3fae8a.kndx':
> HTTP Error 404: Not Found
> (The exact same thing is happening with
> https://launchpad.net/people/rdiaz02/+branch/pomelo2/main)

Your Apache configuration is double unescaping the paths that we are
giving it. Are you behind a proxy? (We encountered this problem with
Apache 1.3 IIRC).

Basically, we are looking for a file that is literally named

To send it as a URL request, we escape all of the % characters and get:

But when I try to connect to your machine, it tells me:

The requested URL
was not found on this server.

So basically, your Apache has translated the path *twice*.

Some background:
  We are escaping capital letters in file ids, to be safe on file
  systems that are case insensitive (Mac, Windows). Otherwise a file-id
  like RJaCGH014-20060712140550... would conflict with a file-id like
  (This is unlikely, but it *is* possible).

  Newer versions of bzr understand this, and just always use lower case
  for all file-ids, and other invariants handle the fact that file-ids
  shouldn't collide.


We've seen this problem when using Apache 1.3 as a proxy, because it has
a bug where it passes the unescaped path to the caller, rather than
passing the requested url.


> Details (and unsuccesfull diagnoses and fix attempts)
> ------------------------------------------------------------------------------


> Best,
> P.D. I am using bzr 0.10 with Debian. The original repositories were
> created, I think, with bzr 0.8.2. But, again, that has been identical
> for both the problematic and the non-problematic branches.

Yes, the on-disk format hasn't changed from 0.8.2 -> 0.10. We did change
how we created file ids, to be friendlier in situations like this.
(Newly generated file ids should not need to be escaped).

If you want to make sure the file is really there, the file we are
looking for is:

(Also, the reason I can tell it is http that is causing the problem, is
because if I go here:

I get the exact same error message as the URL with the extra escaping.)

> P.D.2. I guess an extreme move would be to create a dummy branch
> without any previous history:
> checkout the stuff
> rm -r -f .bzr
> bzr init
> bzr add
> bzr commit --local
> and have the launchpad mirror this castrated branch.
> But this is not OK: people who download the stuff could not see all
> available history.

Version: GnuPG v1.4.5 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the bazaar mailing list