[00:24] Has anyone used 'bzr qlog', right-click, "Tag revision...." recently? [00:25] It throws a medium has reached concurrent request limit error for me [00:26] filed bug 979484 [00:26] Launchpad bug 979484 in qbzr (Ubuntu) "bzr crashed with TooManyConcurrentRequests in __init__(): The medium 'SmartSSHClientMedium(bzr+ssh:///)' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request." [Undecided,New] https://launchpad.net/bugs/979484 [02:36] anyone here ? [02:38] nobody here but us chickens [02:39] darn. [02:43] having bugs with bzr-git and no such revision [07:50] morning all [07:50] o/ jam [07:50] hi poolie [08:07] morning [08:19] poolie: another todo for your handoff list [08:19] poolie: gnu maintainer status [08:29] 'bzr testament' doesn't have any option to generate a v3 testament [08:30] 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] imple is good [08:31] simple != easy [08:32] Hmm [08:33] So I'd have to create testament format registry to do this right, I suppose [08:33] Does that sound worth doing? [08:35] I guess it does, if we have things as simple as bzrlib.log.author_list_registry [08:35] I wonder if this makes it a sufficiently large change to disqualify targeting not-trunk [08:36] probably, but so does adding a --strict switch [08:54] 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] I like that. [08:54] so, if anyone needs additional info, prod me. [08:54] (LP#979690) [09:01] mira|AO: hardy, yum. looks like a bzr-svn issue, not seeing an existing bug at quick look. [09:01] yeah, “yum” ☹ [09:01] can you attach the output of `bzr tags` on the repo you're trying to push? [09:01] bzr tags in the bzr repo or the svn repo? [09:02] yeah, I’m awaiting the day I can switch to debian testing… [09:02] I presume the bzr one, but try both. [09:02] ok [09:02] oh. there are tags. apparently imported from upstream svn… [09:03] potentially deleting a odd (non-ascii maybe?) tag will do as a work around. [09:05] I never worked with tags though… [09:05] doesn’t look any tags are non-ASCII [09:07] whoops, path not tag. [09:07] hm? [09:08] bzr: ERROR: unknown command "path" [09:10] (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] I'd missed that the failing assertion was on a path, despite being in tag related code [09:10] ah [09:10] looking at the context now [09:11] so, the return of: [09:11] self.branch.layout.get_tag_path(tag_name, self.branch.project) [09:11] is not str... [09:11] 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] ah. maybe this is because the pushed-to repo doesn't have any tags? [09:12] (not even toplevel dir) [09:12] hm let me see if another bzr push will also crash (despite nothing to push) [09:12] yes it does [09:12] ok, I'll mkdir a tags dir [09:12] 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] could well just be None if the dir is missing [09:13] nope, will still crash [09:13] ok [09:13] do I need to install something for that debugger? [09:14] nope, it's part of python. [09:14] ok [09:14] path is None, yes [09:16] okay, do `l`, and then print the arguments to the function listed above that assert [09:16] (Pdb) p tag_name [09:16] u'debian_version_4_5_14-2' [09:16] (Pdb) p tag_target [09:16] 'svn-v4:9d84d37e-dcb1-4aad-b103-6f3d92f53bf6:tags/debian_version_4_5_14-2:5614' [09:16] 166 def set_tag(self, tag_name, tag_target): [09:17] ace. [09:17] what's the layout object, also on the line above? [09:17] *** NameError: NameError("name 'layout' is not defined",) [09:17] oh sorry [09:17] (Pdb) p self.branch.layout [09:17] WildcardLayout(['branches/*', 'trunk/gforge_base/evolvisforge', 'trunk/gforge_base/evolvisforge-5.1', 'vendor/testlink', 'trunk/testlink', 'trunk/mediawiki'],['tags']) [09:19] und _space ? [09:19] oops [09:20] 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] hm wait a sec… [09:21] # FIXME [09:21] return None [09:21] okay, that's the problem :) [09:21] just realised tags should be 'tags/*' not 'tags' [09:21] doesn't change anything though [09:21] ah ok :) [09:21] fixed in later versions, then? [09:21] yes. just checking which now [09:22] you may be able to manually update just bzr-svn without breaking any of your other packages [09:22] hmmmmmmm [09:22] “may” ;) [09:22] (on the other hand, I do want a newer bzr anyway, I occasionally run into minor trouble) [09:23] okay, it's implemented in bzr-svn 1.1.0 [09:23] oh well. I'll try that, and try to push my boss to allow me to switch to debian sooner [09:23] thanks [09:23] you should be able to just remove the bzr-svn package [09:23] and install from source to your user plugins dir? [09:24] * mira|AO shudders [09:25] 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] unpacking into to ~/.bazaar/plugins/bzr-svn will tell you [09:27] heh. actually I can't uninstall it, as our dependency metapackage depends on it… [09:28] anyway, thanks for all the help so far [09:28] your user plugins dir should be checked first so should override even without uninstalling [09:28] ah ok [09:28] I’ll try that [09:28] there may also be another workaround, it's not clear to me why you only started hitting this today [09:28] argh. the download link doesn't work… [09:29] I did several bzr-svn related things in the meantime [09:29] hm, just did for me [09:29] so my subversion.conf was changed [09:29] new repos, etc. [09:29] https://launchpad.net/bzr-svn/1.1/1.1.2/+download/bzr-svn-1.1.2.tar.gz [09:30] oh this is great [09:30] it works with lynx [09:30] not with bloatzilla… [09:30] heh. [09:30] * mgz is using lynx [09:31] Unable to load plugin 'svn'. It requested API version (2, 4, 0) of module but the minimum exported version is (2, 1, 0), and the maximum is (2, 1, 0) [09:31] mh, I don't normally use it with launchpad [09:31] maybe I should ;) [09:32] ah, blast, bzr-svn 1.1 isn't compatible with bzr 2.1 it seems. [09:32] mh. [09:32] I'll write up the details on the bug and see if jelmer has any better ideas. [09:33] mgz: is this for bug 979690 ? [09:33] Launchpad bug 979690 in Bazaar Subversion Plugin "AssertionError in set_tag on push to svn" [Medium,Incomplete] https://launchpad.net/bugs/979690 [09:33] ok [09:33] I mean, if it's fixed in a later version, there's nothing I require from you ;) [09:34] besides, the push works, it just crashes afterwards [09:34] jelmer: yup, short version WildcardLayout.get_tag_path returns None tripping that assertion, fixed in bzr-svn 1.1.0 [09:37] 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] mgz, maybe the fact that the pushed-to SVN repo is a fsck'd up PITA that needs WildcardLayout? [09:39] unsetting the tags = value altogether, if that's an option? [09:39] that's an option, yes [09:41] ah. that's what I had before, actually [09:41] so the "cause" are the changes to subversion.conf [09:41] now all I get is: [09:41] 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] and no crash [09:41] ok, that'll suffice for now [09:42] and I'll try to get a permit to drop hardy earlier… === deryck is now known as deryck[lunch] === deryck[lunch] is now known as deryck [18:59] Can I use 'remerge' to pull in new revisions from merged branch committed since I began the merge? [19:13] nope, it's only for redoing the current merge [19:14] merge --force can pull in the newer changes, but is a little riskier for your current state [19:15] may have done what you want previously with commit/merge/uncommit but don't recall if I also needed some extra cleanup [19:17] 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] 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] how do i remove any new files (non-added, non-commited) in a branch directory? [20:06] bzr rm --keep or something [20:06] oh, they arnt added [20:06] you should be able to get a list of unknowns [20:06] this is on windows by the way, so i really don't have any of those fancy xargs applications [20:11] see `bzr help clean-tree` [20:16] cheers === jelmer_ is now known as jelmer [22:31] 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] Any ideas what I'm doing wrong? [22:48] hmm, it seems like my locations.conf breaks things when I use pipelines. === yofel_ is now known as yofel