[00:24] <maxb> Has anyone used 'bzr qlog', right-click, "Tag revision...." recently?
[00:25] <maxb> It throws a medium has reached concurrent request limit error for me
[00:26] <maxb> filed bug 979484
[02:36] <mgrandi> anyone here ?
[02:38] <lifeless> nobody here but us chickens
[02:39] <mgrandi> darn.
[02:43] <mgrandi> having bugs with bzr-git and no such revision
[07:50] <jam> morning all
[07:50] <poolie> o/ jam
[07:50] <jam> hi poolie
[08:07] <mgz> morning
[08:19] <lifeless> poolie: another todo for your handoff list
[08:19] <lifeless> poolie: gnu maintainer status
[08:29] <maxb> 'bzr testament' doesn't have any option to generate a v3 testament
[08:30] <maxb> I wonder if I should do the simple thing of just adding another switch like --strict, or do the more complex thing of attempting to handle testament types like repository format options
[08:30] <lifeless> imple is good
[08:31] <vila> simple != easy
[08:32] <maxb> Hmm
[08:33] <maxb> So I'd have to create testament format registry to do this right, I suppose
[08:33] <maxb> Does that sound worth doing?
[08:35] <maxb> I guess it does, if we have things as simple as bzrlib.log.author_list_registry
[08:35] <maxb> I wonder if this makes it a sufficiently large change to disqualify targeting not-trunk
[08:36] <vila> probably, but so does adding a --strict switch
[08:54] <mira|AO> heh, nice message “Thanks for submitting this bug report. We should be in touch soon. If you want to talk to somebody now, try #bzr on the freenode irc network.”
[08:54] <mira|AO> I like that.
[08:54] <mira|AO> so, if anyone needs additional info, prod me.
[08:54] <mira|AO> (LP#979690)
[09:01] <mgz> mira|AO: hardy, yum. looks like a bzr-svn issue, not seeing an existing bug at quick look.
[09:01] <mira|AO> yeah, “yum” ☹
[09:01] <mgz> can you attach the output of `bzr tags` on the repo you're trying to push?
[09:01] <mira|AO> bzr tags in the bzr repo or the svn repo?
[09:02] <mira|AO> yeah, I’m awaiting the day I can switch to debian testing…
[09:02] <mgz> I presume the bzr one, but try both.
[09:02] <mira|AO> ok
[09:02] <mira|AO> oh. there are tags. apparently imported from upstream svn…
[09:03] <mgz> potentially deleting a odd (non-ascii maybe?) tag will do as a work around.
[09:05] <mira|AO> I never worked with tags though…
[09:05] <mira|AO> doesn’t look any tags are non-ASCII
[09:07] <mgz> whoops, path not tag.
[09:07] <mira|AO> hm?
[09:08] <mira|AO> bzr: ERROR: unknown command "path"
[09:10] <mira|AO> (still, independent of this problem, _if_ someone has got current bzr debs for hardy, or source debs for something else of the lenny era which I could probably build on hardy, tell me ;)
[09:10] <mgz> I'd missed that the failing assertion was on a path, despite being in tag related code
[09:10] <mira|AO> ah
[09:10] <mgz> looking at the context now
[09:11] <mgz> so, the return of:
[09:11] <mgz> self.branch.layout.get_tag_path(tag_name, self.branch.project)
[09:11] <mgz> is not str...
[09:11] <mira|AO> if you need the two svn repositories, I can point you to that. I _think_ I probably can also put my entire shared-repo up somewhere, but that's huge
[09:11] <mira|AO> ah. maybe this is because the pushed-to repo doesn't have any tags?
[09:12] <mira|AO> (not even toplevel dir)
[09:12] <mira|AO> hm let me see if another bzr push will also crash (despite nothing to push)
[09:12] <mira|AO> yes it does
[09:12] <mira|AO> ok, I'll mkdir a tags dir
[09:12] <mgz> running that push with BZR_PDB=1 set, you should land in the python debugger and be able to do `p path` to answer the question of what it is
[09:12] <mgz> could well just be None if the dir is missing
[09:13] <mira|AO> nope, will still crash
[09:13] <mira|AO> ok
[09:13] <mira|AO> do I need to install something for that debugger?
[09:14] <mgz> nope, it's part of python.
[09:14] <mira|AO> ok
[09:14] <mira|AO> path is None, yes
[09:16] <mgz> okay, do `l`, and then print the arguments to the function listed above that assert
[09:16] <mira|AO> (Pdb) p tag_name
[09:16] <mira|AO> u'debian_version_4_5_14-2'
[09:16] <mira|AO> (Pdb) p tag_target
[09:16] <mira|AO> 'svn-v4:9d84d37e-dcb1-4aad-b103-6f3d92f53bf6:tags/debian_version_4_5_14-2:5614'
[09:16] <mira|AO> 166         def set_tag(self, tag_name, tag_target):
[09:17] <mgz> ace.
[09:17] <mgz> what's the layout object, also on the line above?
[09:17] <mira|AO> *** NameError: NameError("name 'layout' is not defined",)
[09:17] <mira|AO> oh sorry
[09:17] <mira|AO> (Pdb) p self.branch.layout
[09:17] <mira|AO> WildcardLayout(['branches/*', 'trunk/gforge_base/evolvisforge', 'trunk/gforge_base/evolvisforge-5.1', 'vendor/testlink', 'trunk/testlink', 'trunk/mediawiki'],['tags'])
[09:19] <mira|AO> und _space ?
[09:19] <mira|AO> oops
[09:20] <mgz> okay, that should be enough, now either want jelmer, or I'll go back and look at WildcardLayout.get_tag_path in bzr-svn 1.0 because the current version seems fine
[09:20] <mira|AO> hm wait a sec…
[09:21] <mgz>         # FIXME
[09:21] <mgz>         return None
[09:21] <mgz> okay, that's the problem :)
[09:21] <mira|AO> just realised tags should be 'tags/*' not 'tags'
[09:21] <mira|AO> doesn't change anything though
[09:21] <mira|AO> ah ok :)
[09:21] <mira|AO> fixed in later versions, then?
[09:21] <mgz> yes. just checking which now
[09:22] <mgz> you may be able to manually update just bzr-svn without breaking any of your other packages
[09:22] <mira|AO> hmmmmmmm
[09:22] <mira|AO> “may” ;)
[09:22] <mira|AO> (on the other hand, I do want a newer bzr anyway, I occasionally run into minor trouble)
[09:23] <mgz> okay, it's implemented in bzr-svn 1.1.0
[09:23] <mira|AO> oh well. I'll try that, and try to push my boss to allow me to switch to debian sooner
[09:23] <mira|AO> thanks
[09:23] <mgz> you should be able to just remove the bzr-svn package
[09:23] <mgz> and install from source to your user plugins dir?
[09:24]  * mira|AO shudders
[09:25] <mgz> I think https://launchpad.net/bzr-svn/1.1/1.1.2 should be bzr 2.1.0 compatible, and it's an easy check
[09:26] <mgz> unpacking into to ~/.bazaar/plugins/bzr-svn will tell you
[09:27] <mira|AO> heh. actually I can't uninstall it, as our dependency metapackage depends on it…
[09:28] <mira|AO> anyway, thanks for all the help so far
[09:28] <mgz> your user plugins dir should be checked first so should override even without uninstalling
[09:28] <mira|AO> ah ok
[09:28] <mira|AO> I’ll try that
[09:28] <mgz> there may also be another workaround, it's not clear to me why you only started hitting this today
[09:28] <mira|AO> argh. the download link doesn't work…
[09:29] <mira|AO> I did several bzr-svn related things in the meantime
[09:29] <mgz> hm, just did for me
[09:29] <mira|AO> so my subversion.conf was changed
[09:29] <mira|AO> new repos, etc.
[09:29] <mgz> https://launchpad.net/bzr-svn/1.1/1.1.2/+download/bzr-svn-1.1.2.tar.gz
[09:30] <mira|AO> oh this is great
[09:30] <mira|AO> it works with lynx
[09:30] <mira|AO> not with bloatzilla…
[09:30] <mgz> heh.
[09:30]  * mgz is using lynx
[09:31] <mira|AO> Unable to load plugin 'svn'. It requested API version (2, 4, 0) of module <module 'bzrlib' from '/usr/lib/python2.5/site-packages/bzrlib/__init__.pyc'> but the minimum exported version is (2, 1, 0), and the maximum is (2, 1, 0)
[09:31] <mira|AO> mh, I don't normally use it with launchpad
[09:31] <mira|AO> maybe I should ;)
[09:32] <mgz> ah, blast, bzr-svn 1.1 isn't compatible with bzr 2.1 it seems.
[09:32] <mira|AO> mh.
[09:32] <mgz> I'll write up the details on the bug and see if jelmer has any better ideas.
[09:33] <jelmer> mgz: is this for bug 979690 ?
[09:33] <mira|AO> ok
[09:33] <mira|AO> I mean, if it's fixed in a later version, there's nothing I require from you ;)
[09:34] <mira|AO> besides, the push works, it just crashes afterwards
[09:34] <mgz> jelmer: yup, short version WildcardLayout.get_tag_path returns None tripping that assertion, fixed in bzr-svn 1.1.0
[09:37] <mgz> any work arounds you can think of, given updating bzr on hardy is a pain? what gets WildcardLayout used rather than one of the others?
[09:39] <mira|AO> mgz, maybe the fact that the pushed-to SVN repo is a fsck'd up PITA that needs WildcardLayout?
[09:39] <jelmer> unsetting the tags = value altogether, if that's an option?
[09:39] <mira|AO> that's an option, yes
[09:41] <mira|AO> ah. that's what I had before, actually
[09:41] <mira|AO> so the "cause" are the changes to subversion.conf
[09:41] <mira|AO> now all I get is:
[09:41] <mira|AO> bzr: ERROR: Tags not supported by SvnBranch('svn+ssh://mirabilos@svn.evolvis.org/svnroot/evolvis/trunk/gforge_base/evolvisforge-5.1'); you may be able to use bzr upgrade.
[09:41] <mira|AO> and no crash
[09:41] <mira|AO> ok, that'll suffice for now
[09:42] <mira|AO> and I'll try to get a permit to drop hardy earlier…
[18:59] <cody-somerville> Can I use 'remerge' to pull in new revisions from merged branch committed since I began the merge?
[19:13] <wgz> nope, it's only for redoing the current merge
[19:14] <wgz> merge --force can pull in the newer changes, but is a little riskier for your current state
[19:15] <wgz> may have done what you want previously with commit/merge/uncommit but don't recall if I also needed some extra cleanup
[19:17] <wgz> so if you've got lots of half resolved conflicts, you probably just want to pick between resolving fully then doing the new ones, or starting again with the newer rev
[20:00] <mgrandi_> so , i gm getting a bzr: ERROR: bzrlib.errors.MalformedTransform: Tree transform is malformed [('overwrite', 'new-65', u'test')] error when i try to revert one of my branches
[20:05] <damd> how do i remove any new files (non-added, non-commited) in a branch directory?
[20:06] <mgrandi_> bzr rm --keep or something
[20:06] <mgrandi_> oh, they arnt added
[20:06] <mgrandi_> you should be able to get a list of unknowns
[20:06] <damd> this is on windows by the way, so i really don't have any of those fancy xargs applications
[20:11] <wgz> see `bzr help clean-tree`
[20:16] <damd> cheers
[22:31] <thomi> Hi, I'm trying to figure out pipelines. I'm having an issue where when I do 'bzr lp-propose' while in the second pipe of two, it sets the source branch to be the first pipe in the series, rather than the current one.
[22:31] <thomi> Any ideas what I'm doing wrong?
[22:48] <thomi> hmm, it seems like my locations.conf breaks things when I use pipelines.