Bazaar

AttributeError: 'Inter1and2Helper' object has no attribute 'source_repo'

Bug #513432 reported by Monty Taylor
106
This bug affects 18 people
Affects Status Importance Assigned to Milestone
Bazaar
Fix Released
Critical
Martin Pool
Bazaar 2.1.0 "Strasbourg"
2.0
Invalid
Critical
Unassigned
2.1
Fix Released
Critical
Martin Pool
Bazaar 2.1.0 "Strasbourg"
Launchpad itself
Fix Released
Critical
Michael Hudson-Doyle
Launchpad itself 10.02
bzr (Ubuntu)
Fix Released
Undecided
Unassigned
Ubuntu maverick-updates

Bug Description

When I try to grab the libsndfile-dev branch:

bzr branch http://www.mega-nerd.com/Bzr/libsndfile-dev

I get:

bzr: ERROR: exceptions.AttributeError: 'Inter1and2Helper' object has no attribute 'source_repo'

This happens very consistently.

The tail of the log file:

   File "/usr/lib/python2.6/dist-packages/bzrlib/repository.py", line 4482, in _generate_root_texts
     self.from_repository).generate_root_texts(revs)
   File "/usr/lib/python2.6/dist-packages/bzrlib/fetch.py", line 257, in generate_root_texts
     graph = _get_rich_root_heads_graph(self.source_repo, revs)
 AttributeError: 'Inter1and2Helper' object has no attribute 'source_repo'

This bug was present in trunk and 2.1 rc releases. It is fixed now in both branches.

Launchpad currently has this bug in its deployed server code, with the result that branching from LP can fail.

See original description
Tags: lp-code sru fetch

Related branches

lp:~mbp/bzr/513432-fetch
Merged into lp:bzr
John A Meinel: Approve
Diff: 28 lines (+6/-1)
2 files modified
NEWS (+3/-0)
bzrlib/fetch.py (+3/-1)
lp:~mbp/bzr/prepare-2.1
John A Meinel: Approve
Diff: 271 lines (+160/-10)
9 files modified
NEWS (+11/-0)
bzrlib/builtins.py (+1/-1)
bzrlib/mutabletree.py (+4/-0)
bzrlib/tests/__init__.py (+1/-0)
bzrlib/tests/per_workingtree/__init__.py (+2/-1)
bzrlib/tests/per_workingtree/test_symlinks.py (+98/-0)
bzrlib/tests/test_treeshape.py (+41/-0)
bzrlib/tests/test_upgrade.py (+0/-6)
bzrlib/tests/treeshape.py (+2/-2)
lp:~mwhudson/launchpad/apply-fix-for-bug-513432
Francis J. Lacoste (community): Approve (release-critical)
Tim Penhey (community): Approve
Björn Tillenius: Pending requested
Diff: 13 lines (+2/-1)
1 file modified
versions.cfg (+2/-1)
Martin Pool (mbp)
Changed in bzr:
status: New → Confirmed
importance: Undecided → High
tags: added: fetch
Martin Pool (mbp)
Changed in bzr:
importance: High → Critical
Revision history for this message
Martin Pool (mbp) wrote :

http://www.mega-nerd.com/Bzr/libsndfile-dev is a pack-0.92 branch.

I think as a workaround you should run 'bzr info' to check what format of repository you're trying to bring it into. Perhaps create or upgrade a specific libsndfile repository in --0.92 format.

Revision history for this message
Martin Pool (mbp) wrote :

Also reported as a problem in lp tests https://lpbuildbot.canonical.com/builders/db_lp/builds/463/steps/shell_4/logs/stdio

Revision history for this message
Martin Pool (mbp) wrote :

I can reproduce it going from an old format to 2a

Martin Pool (mbp)
Changed in bzr:
assignee: nobody → Martin Pool (mbp)
status: Confirmed → In Progress
Revision history for this message
Martin Pool (mbp) wrote :

This is now fixed in trunk. 2.1 has already branched off so this also needs to be landed there. The bug is not present in the 2.0 branch.

Changed in bzr:
milestone: none → 2.1.0
status: In Progress → Fix Released
Revision history for this message
Martin Pool (mbp) wrote :

This probably also needs to be rolled out on Launchpad, because by branching from a remote old branch into a 2a repo you can get

bzr: ERROR: bzrlib.errors.ErrorFromSmartServer: Error received from smart server: ('error', "'Inter1and2Helper' object has no attribute 'source_repo'")

Changed in launchpad-code:
importance: Undecided → High
Revision history for this message
Robert Collins (lifeless) wrote :

Jorge Castro appeared to encounter this error using bzr 2.0.3. but in actual fact it was coming from launchpad. Seeing about escalating/doing a fix there.

Robert Collins (lifeless)
description: updated
Robert Collins (lifeless)
Changed in launchpad-code:
status: New → Confirmed
Robert Collins (lifeless)
Changed in launchpad-code:
importance: High → Critical
assignee: nobody → Michael Hudson (mwhudson)
Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

Fix rolled out to launchpad production.

Changed in launchpad-code:
status: Confirmed → Fix Released
Tim Penhey (thumper)
Changed in launchpad-code:
milestone: none → 10.02
Revision history for this message
Martin Pool (mbp) wrote :

Actually Lucid now has 2.1.0-1 so this is fixreleased there.

Changed in bzr (Ubuntu):
status: New → Fix Released
Revision history for this message
Alan Bell (alanbell) wrote :

getting the error above on bzr branch lp:ubiquity on a Maverick box.
Doing on-the-fly conversion from RemoteRepositoryFormat(_network_name='Bazaar pack repository format 1 (needs bzr 0.92)\n') to RepositoryFormat2a().

Revision history for this message
Andrew Bennetts (spiv) wrote :

Alan: Which version of bzr? This bug has been fixed since 2.1.0. Maverick has 2.2.0, and using that version I can branch from lp:ubiquity into a local 2a repository just fine. So the most likely explanation seems to be that for some reason you are still using an old version of bzr.

Revision history for this message
Andrew Bennetts (spiv) wrote :

Oh, I spoke too soon: this bug does occur in 2.2.0. Sorry for the noise!

It is fixed in 2.2.1, though. So it is a problem in the current Maverick package; we should probably get an SRU going for 2.2.1 in Maverick.

Changed in bzr (Ubuntu):
milestone: none → maverick-updates
status: Fix Released → Confirmed
Revision history for this message
Martin Pool (mbp) wrote :

An sru has alread been requested for bug 636930, which is quite similar (but I guess not a dupe?)

tags: added: sru
Revision history for this message
Andrew Bennetts (spiv) wrote :

It's essentially the same bug. The faulty line of code was different in lp:bzr/2.2 vs. lp:bzr/2.1 due to a refactoring (and so apparently caused the fix in 2.1 to be lost when 2.1 was merged into 2.2), but the actual fault was the same, and the nature of the fix was the same. So probably we could/should mark this bug as a dupe of 636930, although ideally we wouldn't want to lose the bug metadata on this bug about when it was fixed in e.g. 2.1... :/

Vincent Ladeuil (vila)
Changed in bzr (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.