bzr bd --native is ignored if merge=True is set in config file

[Serge Hallyn]

I have a new package in a tree at lp:~serge-hallyn/user-mounts/devel. If debian/source/format is not set, then I get

serge@sergelap:~/src/private_mounts$ bzr bd --native
Building using working tree
Running in merge mode
Purging the build dir: /home/serge/src/build-area/user-mounts-1.1
Looking for a way to retrieve the upstream tarball
Upstream tarball already exists in build directory, using that
bzr: ERROR: [Errno 2] No such file or directory: '/home/serge/src/private_mounts/debian/source/format'

If debian/source/format is set to
3.0 (native)

then it works.

[Jelmer Vernooij (jelmer)]

This is because that file existed previously. You have to remove it from bzr explicitly by using "bzr rm debian/source/format".

I guess we could handle this a bit nicer and automatically update the dirstate before exporting.

[Serge Hallyn (serge-hallyn)]

Quoting Jelmer Vernooij (<email address hidden>):
> This is because that file existed previously. You have to remove it from
> bzr explicitly by using "bzr rm debian/source/format".

I guess I failed in my attempts to reproduce the original error message.
But I'm telling you that 'bzr bd' also fails if debian/source never
existed. I just didn't want to create a new tree just to get the
original error message.

> I guess we could handle this a bit nicer and automatically update the
> dirstate before exporting.

No, that isn't worth fixing. That wasn't what I was trying to report.

[Serge Hallyn (serge-hallyn)]

Ok, I went ahead and did 'bzr remove debian/source' as well as removed the cached
tarballs and build-area. A subsequent 'bzr bd -S' gave me:

serge@sergelap:~/src/x$ bzr bd -S
Building using working tree
Running in merge mode
Looking for a way to retrieve the upstream tarball
Using apt to look for the upstream tarball.
apt could not find the needed tarball.
Trying to use get-orig-source to retrieve needed tarball.
make: *** No rule to make target `get-orig-source'. Stop.
Trying to run get-orig-source rule failed
No watch file to use to retrieve upstream tarball.
bzr: ERROR: Unable to find the needed upstream tarball: user-mounts_1.1.orig.tar.gz.

With debian/source/format set to
    3.0 (native)

it works

[James Westby (james-w)]

> serge@sergelap:~/src/private_mounts$ bzr bd --native
> Building using working tree
> Running in merge mode

That's the problem. It's ignoring your --native for some reason.

> If debian/source/format is set to
> 3.0 (native)

> then it works.

I don't understand that. bug 586617 requests the feature to auto-detect
native pased on debian/source/format, and I certainly haven't coded it,
so I suspect that it is in fact some other change that means this works for
you.

>> I guess we could handle this a bit nicer and automatically update the
>> dirstate before exporting.

> No, that isn't worth fixing. That wasn't what I was trying to report.

It is worth fixing, and I believe that is the bug that Clint was seeing
when I asked you to report this one.

So, /this/ bug is about --native not working, and it using merge mode
instead for some reason, possibly related to the presence of the
debian/source/format file, there is an existing bug for debian/source/format
to imply --native, and there is another bug which I will file about
removed files causing an error.

Thanks,

James

[James Westby (james-w)]

Ok, this bug is the result of using several bools, rather than an enum.

We should change the code to an enum, and possibly error on conflicting
options.

We should also have mode = merge|native|etc. in the config file, but that's
a harder change.

Thanks,

James

[Serge Hallyn (serge-hallyn)]

Quoting James Westby (<email address hidden>):
> > serge@sergelap:~/src/private_mounts$ bzr bd --native
> > Building using working tree
> > Running in merge mode
>
> That's the problem. It's ignoring your --native for some reason.
>
> > If debian/source/format is set to
> > 3.0 (native)
>
> > then it works.
>
> I don't understand that. bug 586617 requests the feature to auto-detect
> native pased on debian/source/format, and I certainly haven't coded it,
> so I suspect that it is in fact some other change that means this works for
> you.

Sorry, I again mis-interpreted. What happens is that it works when my
.bzr-builddeb/default.conf has

export-upstream = lp:~serge-hallyn/user-mounts/devel

Then, if I remove that line, it continues to work, but that's because
the .orig.tar.gz has already been saved in the parent directory. If I
erase the .orig.tar.gz, the build-area, and don't have the above line,
then actually it doesn't work.

> >> I guess we could handle this a bit nicer and automatically update the
> >> dirstate before exporting.
>
> > No, that isn't worth fixing. That wasn't what I was trying to report.
>
> It is worth fixing, and I believe that is the bug that Clint was seeing
> when I asked you to report this one.
>
> So, /this/ bug is about --native not working, and it using merge mode
> instead for some reason, possibly related to the presence of the

Ah, then it is NOT a bug, but end-user bug. I still had
 Merge = True
in my default.conf (as had been suggested I do on irc)

[James Westby (james-w)]

> Sorry, I again mis-interpreted. What happens is that it works when my
> .bzr-builddeb/default.conf has
>
> export-upstream = lp:~serge-hallyn/user-mounts/devel
>
> Then, if I remove that line, it continues to work, but that's because
> the .orig.tar.gz has already been saved in the parent directory. If I
> erase the .orig.tar.gz, the build-area, and don't have the above line,
> then actually it doesn't work.

Right. That "works", but it's not building a native package as you are
requesting with --native.

> Ah, then it is NOT a bug, but end-user bug. I still had
> Merge = True
> in my default.conf (as had been suggested I do on irc)

Right, an inconsistent configuration has been specified. We should
either recognise this and complain, have a priority scheme to disambiguate,
or change the configuration so that only valid states can be specifed (or all
three).

I appreciate that you are keen to work out how to use the tool, but that
doesn't detract from the fact that you had these problems is a deficiency
in the tool that I want to fix. This isn't a place where confusion arising from
poor code, UI or documentation is your fault :-)

Thanks,

James

[Jelmer Vernooij (jelmer)]

There now is a proper priority scheme in place, and this works as expected.