Upgrading a repository fails with 'Inter1and2Helper' object has no attribute 'source_repo'

my bzr.log

This looks like bug 513432 but that was supposed to be fixed in 2.2.

Duplicates bug 633915 and bug 635874 are also current rather than old bzr versions and may have additional info that will help diagnose this.

With this much info, why not Triage?

http://doc.bazaar.canonical.com/bzr.2.2/developers/bug-handling.html

See under 'Bug status'.

Thanks lifeless, I thought bzr uses the same system of bug statuses as Ubuntu.

This appears to be shallow. It's in a code path not currently covered by our test suite, so I think a refactoring probably broke it. I'll fix and also try to make sure it has some test coverage.

I'm proposing my fix for merging now.

In the meantime, affected people may be able to workaround this bug by adding -DIDS_never to your command line (or debug_flags = IDS_never to your ~/.bazaar/bazaar.conf).

The fix has landed on the 2.2 branch and will be part of 2.2.1.

I've added launchpad-code to this bug report; Launchpad is running bzr 2.2.0 and so is affected by this until they upgrade to the latest lp:bzr/2.2 version. (Some of the duplicates show this error occuring server-side in Launchpad, and presumably it breaks Launchpad's upgrade button for upgrades that cross the rich-root watershed.)

I think we should try to do this as an SRU of bzr 2.2.1 into Maverick after the release of Maverick (or even now, if that's possible). I don't know if this will get over the bar to actually get into the maverick release at this point.

Dear ~ubuntu-sru, we'd like to get this into maverick-updates, preferably now or otherwise after the release. Per <https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions>, we have an exception to take all of 2.2.1, conditional on running the tests during the package build and on running the tests in 2.2.1. Some of those will fail in 2.2.1, but they should be fixed in 2.2.2. For now I propose we build the package, then check there are only the expected isolation-related failures in the installed package.

We still have time until the Maverick release, so any reason why we should't fix this in maverick now? Is 2.2.1 already released? If so, let's upload that.

On 24 September 2010 18:35, Martin Pitt <email address hidden> wrote:
> We still have time until the Maverick release, so any reason why we
> should't fix this in maverick now? Is 2.2.1 already released? If so,
> let's upload that.

That would be excellent! I had the misapprehension it was now totally
frozen. 2.2.1 does not yet have the fixes to make the test suite
clean from the installed version, but we could check the only ones are
those known and mentioned in the bugs here: bug 632387, bug 644855.

--
Martin

2.2.1 is now officially released, I don't know who can upload and what should be uploaded though.

bug #632387, bug #644855 and bug #646133 have landed so we should be able to run the test suite during builds for the next releases (2.2.2 and 2.3b2).

There's now a package in https://launchpad.net/~bzr/+archive/ppa similar to what should be put into the maverick release. The upstream diff from 2.2.0 to 2.2.1 is attached here. I've read through it and can certify everything in it is a real bug fix suitable for a stable update.

pitti said, on irc, that someone (maxb?jelmer?) should upload it; it won't be in 10.10 final but it will be in an SRU shortly afterwards.

Branch linked: lp:~maxb/ubuntu/maverick/bzr/2.2.1-0ubuntu1 containing my proposed package. NB that it differs only in debian/changelog from what we built in https://launchpad.net/~bzr/+archive/ppa as bzr 2.2.1-0~bazaar1~maverick1.

I require sponsorship for the upload:
* original source: http://launchpad.net/bzr/2.2/2.2.1/+download/bzr-2.2.1.tar.gz
* bzr_2.2.1-0ubuntu1.debian.tar.gz - attached
* bzr_2.2.1-0ubuntu1.dsc - will attach next, for completeness sake

Currently the upload is targetted at maverick rather than maverick-updates, as the last contact I had with an ubuntu-release member indicated that a post-RC release pocket upload was still an option.

There are no changes in the debian/ directory between the current maverick package and my sponsorship request, other than non-functional artifacts (of version number and ordering of files in a diff) produced by the construction of a source package from the packaging branch, and the single extra debian/changelog entry.

Dear ~ubuntu-release,

In some bug comments and IRC conversations, it has been suggested that this update might be a candidate for a post-RC release pocket approval. Now that there is a proposed package, may we have a formal decision on this matter? If it is deemed too late, we shall instead pursue this as a SRU.

Dear ~ubuntu-sponsors,

There is a pending question to the release team on whether this package should target maverick or maverick-proposed - that aside, however, would someone be willing to review my proposed package such that it can be sponsored quickly once that release team verdict is rendered?

Thanks.

Before I would consider uploading this, I'd like to see a report of the results of the tests that would be required if this were a post release update.

@scottk I've run the tests from the installed package, as was required in the technical-board thread. There are some failures about "test isolation" which are bug 650001. This was discovered in the course of the t-b thread and it will be fixed in 2.2.1 but because of the timing of the 2.2.1 release vs the SRU policy it's not fixed here.

There's also the failure described in bug 651706, which I haven't seen before, but looks like it may also be something about the test environment rather than an inherent problem in the package.

I'd be uncomfortable with this until Bug #651706 is understood and positively been determined not to be an actual issue in bzr.

I can reproduce the problem with 2.2.0 on maverick:

  bzr selftest --no-plugins -s bt.per_transport

So things won't be worse with 2.2.1.

I'm currently investigating bug #651706 nevertheless, my gut feeling being that it's a test-only issue.

Given vila's comment #26, I think we shouldn't block putting 2.2.1 into maverick.

See bug #651706 for details, this is a test-only issue and doesn't affect bzr use.

< pitti> poolie: as I said, it can be uploaded to maverick-proposed
 -- #ubuntu-devel, ~45 minutes ago

OK, I'm treating this as an official verdict and we're retargeting this as a SRU again.

Changelog update targeting maverick-proposed to branch and to attached package for sponsorship will follow shortly.

Dear ~ubuntu-sponsors,

Please sponsor my package into maverick-proposed:

Packaging branch: lp:~maxb/ubuntu/maverick/bzr/2.2.1-0ubuntu1
(this does not share history with the UDD branches, because bzr has had packaging branches since long before UDD existed. If you prefer UDD-based sponsorship, let me know and I will recommit this on top of the UDD branch)

NB: that it differs only in debian/changelog from what we built in https://launchpad.net/~bzr/+archive/ppa as bzr 2.2.1-0~bazaar1~maverick1.

* original source: http://launchpad.net/bzr/2.2/2.2.1/+download/bzr-2.2.1.tar.gz
* bzr_2.2.1-0ubuntu1.debian.tar.gz - attached
* bzr_2.2.1-0ubuntu1.dsc - will attach next, for completeness sake

Thanks.

The fix for bug #651706 has landed and will be available in bzr 2.2.2.
I confirm that it's a test-only issue that should not block putting 2.2.1 into maverick.

Dear ~ubuntu-sponsors,

as discussed with maxb, I compared the test failures between 2.2.0 and 2.2.1 (attached), they are exactly the same in both cases.

As for 2.2.2, not yet released, we have fixed this failures except for:

- a test failing when the test suite is run as root (see bug #646133, this test was added since 2.1 and I'm fixing it right now),

- a single remaining failure related to a bug in paramiko (https://bugs.edge.launchpad.net/bzr/+bug/579530). Note that if paramiko is not installed in the chroot running the build, the test will be skipped instead.

I'm uncomfortable with the tests not being run during build, but I understand from the history of this bug that that's essentially due to the 2.2.1 release happening before we set this SRU policy, so I'm sponsoring this on the understanding that it will be sorted out in 2.2.2 and that we run the tests on the installed package (as discussed above). This will still need approval from another SRU team member.

Accepted bzr into maverick-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Hi Pitti,

I've installed bzr 2.2.1 from maverick-proposed and used it for the last few days without hitting any regressions.

I've manually tested the upgrade from 1.14 to 2a described by this bug.

I'm running the sefltests and the only failures are the already-known problems to do with tests not liking being run from an installed copy. (And also as discussed above, these are fixed in trunk and will be fixed in 2.2.2.)

I don't see any new bugs in <https://bugs.edge.launchpad.net/ubuntu/+source/bzr/?field.searchtext=&orderby=-datecreated&search=Search&field.status:list=NEW&field.status:list=INCOMPLETE_WITH_RESPONSE&field.status:list=INCOMPLETE_WITHOUT_RESPONSE&field.status:list=CONFIRMED&field.status:list=TRIAGED&field.status:list=INPROGRESS&field.status:list=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=> that would indicate that other people running maverick-proposed had any trouble.

According to <https://wiki.ubuntu.com/QATeam/PerformingSRUVerification#Updating%20the%20bug%20report>we need one more positive verification...

Just installed bzr 2.2.1-0ubuntu1 from maverick-proposed on my Maverick system and then branched lp:~ubuntu-desktop/empathy/ubuntu into a 2a shared repo (which forced an upgrade first). Worked perfectly. The same thing didn't work earlier for me, which I described in dup bug #633915 .

Marking as verification-done.

Sorry, I didn't notice the fact that the desktop devs have upgraded that repo to 2a :( Setting back to verification-needed.

Hi Pitti,

I've installed bzr 2.2.1 from maverick-proposed and ran the self-tests and I confirm the only failures are the already-known problems.

Hi Pitti,

I've installed bzr 2.2.1 from maverick-proposed and used it for running the self-tests.

The only failures are the already-known problems mentioned above and fixed in trunk and the upcoming bzr-2.2.2.

meh, firefox didn't refresh the page correctly so I thought launchpad lost my comment, sorry for the noise.

This bug was fixed in the package bzr - 2.2.1-0ubuntu1

---------------
bzr (2.2.1-0ubuntu1) maverick-proposed; urgency=low

  * New upstream release.
   + Fix regression with upgrading poor-root to rich-root formats. LP: #636930
   + Files in ~/.bazaar are now locked whilst being updated automatically.
     LP: #525571
 -- Max Bowsher <email address hidden> Thu, 30 Sep 2010 09:57:15 +0100

Natty has 2.3.0 beta 2, assuming that it's fixed there.

I upgraded to bzr - 2.2.1-0ubuntu1 and all is well.

Thanks everyone. :)

Todd

I'm running 10.10 w/ bzr 2.2.1 installed and I'm encountering this problem when attempting to checkout / branch a private repository. Based on an IRC conversation with spiv, the fix is an update of bzr server-side? Here is my traceback:

https://pastebin.canonical.com/39250/

As an aside, prefixing the repository with 'nosmart+' when checking it out does seem to work around the problem in the interim as suggested by spiv.

OK. This issue has been resolved for me. I'm going to assume that someone updated bzr server-side? Thanks

This should be fixed on the lp side, which will fix more cases, when they upgrade to 2.2.1. Because of lp being in testfix mode, that hasn't happened yet. ~wallyworld is working on it.

<poolie> spiv does bug 636930 require upgrading the client, or also the server?
<spiv> poolie: whichever side is actually performing the conversion; in the case of fetching from a smart server, that's the server side.
<spiv> poolie: so there's a couple of things in that bug:
<spiv> poolie: the original reported traceback is client side
<spiv> poolie: but Launchpad performs upgrades on behalf of users when they click the link on Launchpad, so that's Launchpad-side
<spiv> And cross-format fetches that aren't upgrades are also affected.
<spiv> So to cover all cases server and client need to be upgraded.

Fixed in stable r12005 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/12005>.