bzr bd in SVN checkout from DPMT repo fails with invalid URL

On Wed, 14 Jul 2010 19:56:18 -0000, Elliot Murphy <email address hidden> wrote:
> Public bug reported:
>
> I heard that there was this amazing new feature where I could go run bzr
> bd in the subversion checkout of my debian packages from debian python
> modules team (these all use svn-buildpackage). When I tried this, I got
> an error:
>
>
> emurphy@sunk:~/python-packaging/django-lean$ bzr bd
> Initialising Subversion metadata cache in /home/emurphy/.cache/bazaar/svn/771dd761-d7fa-0310-a302-f036d1c1ebb6.
> Building using working tree
> Running in merge mode
> bzr: ERROR: Invalid url supplied to transport: "svn+ssh://<email address hidden>/svn/python-modules/packages/django-lean/trunk": local urls must start with file:/// or file://localhost/

Hi Elliot,

Thanks for the bug.

So, it thinks that the branch that you passed is a local build, which it
is, because you didn't pass one.

In that case it assumes that the branch.base will be be local, but I'm
guessing that it is not forced to be in a checkout.

Thefore we need to be a bit smarter here and take the root of the tree
instead, if we have a tree.

We won't have one if you pass a remote branch to build, or if you are in
a treeless branch. If it is the latter then branch.base will be local
and all will work, if it is the former then it will be remote and the
existing code will cope with this.

I'm not quite sure how to untwist the logic around this right now, but
it shouldn't be hard to make the necessary tweaks in cmds.py if you want
to hack it and see how far you get after this error is removed.

Thanks,

James

When I run bzr bd in an svn checkout and get this error, I set BZR_PDB=1 and see that branch.base is 'svn+ssh://<email address hidden>/svn/python-modules/packages/django-lean/trunk'

And when commenting like this:

=== modified file 'cmds.py'
--- cmds.py 2010-07-02 22:15:05 +0000
+++ cmds.py 2010-07-16 03:58:13 +0000
@@ -267,9 +267,9 @@
                     supplied = if_not
             if supplied is not None:
                 if is_local:
- supplied = os.path.join(
- urlutils.local_path_from_url(branch.base),
- supplied)
+ #supplied = os.path.join(
+ # urlutils.local_path_from_url(branch.base),
+ # supplied)
                     supplied = os.path.realpath(supplied)
             return supplied

@@ -303,6 +303,7 @@
             export_upstream_revision, config, version):
         upstream_branch = None
         upstream_revision = None
+ import pdb;pdb.set_trace()
         if merge:
             if export_upstream is None:
                 export_upstream = config.export_upstream

I see failures triggered by _get_upstream_branch() returning None because config.export_upstream is None.
At this point I am pretty lost so I didn't try anything else.

On Fri, 16 Jul 2010 04:02:15 -0000, Elliot Murphy <email address hidden> wrote:
> I see failures triggered by _get_upstream_branch() returning None because config.export_upstream is None.
> At this point I am pretty lost so I didn't try anything else.

Ok, that suggests that the magic to detect the mergeUpstream property in
SVN isn't working.

    if tree is not None:
      try:
        # Imported here, since not everybody will have bzr-svn installed
        from bzrlib.plugins.svn.config import
      SubversionBuildPackageConfig, NoSubversionBuildPackageConfig
        try:
          self._tree_config =
      SvnBuildPackageMappedConfig(SubversionBuildPackageConfig(tree))
        except NoSubversionBuildPackageConfig:
          pass # Not a svn tree
      except ImportError:
        pass # No svn, apparently

I'm not sure which of the many things could be going wrong here, I would
have to try it to work that out.

Thanks,

James

Fixes have landed for two bugs that this is affected by:

bzr-builddeb no longer attempts to use the branch URL to determine the local path to store build results, tarballs, etc. (bug 676456) and it now has a sensible way of figuring out the build type so the information set in the svn branch properties actually gets picked up (bug 655277)

The upstream tarball also doesn't seem to be fetched at the moment, even though there is a debian/watch file. This seems related to bug 552893, which I'm working on that at the moment.

Building django-learn was affected by various bugs that have all been fixed now. I'm going to mark this bug as a dupe of the first relevant bug.