[00:02] whoops, making a hash of bug editing, sorry for the spam nmb [00:06] mkanat: mkanat probably [00:07] lifeless: Okay. Does it need any information from the processes it's proxying, like information on which ones are busy/free? [00:07] mkanat: we tell it a policy about how deep to queue. [00:07] if we're going to deploy with single threaded instances, its easy - we set that to 1 ;) [00:07] lifeless: Okay, that's easy enough. [00:08] filing an RT for it now [00:08] lifeless: Okay. However, loggerhead isn't completely ready for single-threaded instances. [00:08] I'm not sure why, but it's very very slow in single-threaded mode. I think there's some cache that it's regenerating for each request or something. [00:09] do you mean [00:09] 'if you configure it with one thread and then run it locally its slow' [00:09] or [00:10] 'if you configure a cluster of lh's with 10 threads each but a 1-request-at-a-time cluster policy it is slow' ? [00:10] lifeless: The first one. [00:10] ok, so lets not do that [00:10] we can just use haproxy to limit it to one concurrent request [00:10] lifeless: That sounds like it could work, yeah. [00:11] lifeless: I also haven't yet tested to see if there are any concurrency problems with multiple processes. [00:11] lifeless: But if we can set up a sort of edge loggerhead behind haxproxy, that would probably work. [00:11] For testing purposes, that is. [00:13] that would be staging [00:14] edge is a production system :) [00:14] http://blog.launchpad.net/general/continuous-deployment-in-launchpad [00:14] lifeless: Okay. [00:15] * mwhudson would expect strictly fewer concurrency issues running multiple processes compared to multiple threads [00:15] mwhudson: I would too, but there's the log and the sql caches. [00:15] mwhudson: rt 41762 if you'd like to review what I've asked for. [00:15] ok, stacking wood. [00:16] And launchpad-loggerhead specifically has code to disable locking the log, although that probably wouldn't matter anyway since I think the locks are mutexes. [00:16] I think that it all being a single fwrite will probably be enough. [00:17] mkanat: i don't think sqlite cares at all whether the multiple accesses come from different processes or different threads [00:17] similar for locking really, i hope... [00:17] mwhudson: I think that you're right, and jam's post to the bzr list pretty much confirms it. [00:17] yeah, one line per fwrite [00:17] * mwhudson needs lunch [00:23] lifeless: The current production loggerhead isn't using bzr-history-db yet, though, also, BTW. [00:24] lifeless: So putting that into one-request mode would be, basically, a miserable experience. [00:45] hm, istr that sqlite requires you to lock yourself if you're going to use the same object from multiple threads [00:45] this might be handled in the python layer though [00:45] poolie: its not [00:45] we already have something to do isolation of the sqlite dbs, I think? [00:46] hello lifeless [00:47] mwhudson, could you find some time to review https://code.edge.launchpad.net/~jameinel/launchpad/lp-service/+merge/37531 ? [00:48] Hmm, I don't suppose one of you feels like running requeue_package.py deja-dup coreutils freeimage on pkg_import@jubany ? [00:52] mkanat: [00:52] ./requeue_package.py deja-dup coreutils freeimage [00:52] deja-dup has not failed [00:52] coreutils has not failed [00:52] freeimage has not failed [00:52] ba [00:52] maxb: ^ [00:52] maxb: I think we clearly need to legally change our names, or something. :-) [00:53] huh [00:53] well why does the web ui say they have :-( [00:53] noidea [00:53] poolie: i'll take a look [01:00] lifeless: Could you try that again with --force ? Because those branches are definitely lagging reality [01:02] ./requeue_package.py --force deja-dup coreutils freeimage [01:02] Usage: requeue_package.py [options] [01:02] requeue_package.py: error: no such option: --force [01:02] $pwd? [01:02] pkg_import@jubany:/srv/package-import.canonical.com/scripts [01:03] * mwhudson stabs his launchpad development environment repeatedly with a rusty blade [01:03] cd ../new/scripts [01:04] james_w: to be followed by ../../newer/scripts ? [01:04] eww [01:04] pkg_import@jubany:/srv/package-import.canonical.com/new/scripts$ ./requeue_package.py deja-dup coreutils freeimage [01:04] Traceback (most recent call last): [01:04] File "./requeue_package.py", line 8, in [01:04] import icommon [01:04] File "/srv/package-import.canonical.com/new/scripts/icommon.py", line 21, in [01:04] from debian_bundle import changelog [01:04] ImportError: No module named debian_bundle [01:05] james_w: ^ [01:05] !delegate james_w :-) [01:05] Error: I am only a bot, please don't think I'm intelligent :) [01:05] ubot5: hush [01:05] ../newest.REALLY [01:05] lifeless: pythonpath=python-debian [01:06] james_w: this needs a profile or some such [01:07] Go ahead [01:07] maxb: requeued [01:07] james_w: I have 3.5 m³ to finish stacking [01:07] thanks mwhudson [01:08] lifeless: I have a hard disk to repair :) [01:08] thanks [01:08] james_w: ouch [01:08] james_w: that sounds ... delicate [01:09] mkanat, hi? [01:09] Howdy poolie. === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [03:47] is it possible to change what a branch is stacked on? [04:50] chx: Yes, see bzr reconfigure [04:53] jbowtie: thanks! === bialix_ is now known as bialix [07:13] hi vila, bialix, gary [07:14] hi poolie! [07:14] i'm going to turn back on expiry of old incomplete bugs, unless/until someone complains [07:14] I was about to ask you about kicking update of explorer site, but it's updated this morning. thanks anyway [07:15] it was failing to update because of a minor permissions problem [07:15] i fixed it [07:15] thanks anyhow [07:24] hi all ! [07:24] poolie: +1 for expiring bugs [07:29] \o_ _o/ [07:29] bialix: :) [07:38] hi there [07:43] grr, update requires reboot, bbiab [07:59] weird... what is the meaning of 't' in 'drwxrwxr-t' in the chmod bits on '/' ? [07:59] that's on OSX if that matters [08:02] nm, sticky bit for directory [08:06] os.listdir('/home') raises OSError: [Errno 5] Input/output error .... wth ? (I know OSX uses /Users, but the directory exists here, is empty and chmod bits are 'dr-x-rxr-x root wheel') [08:07] at that point on linux i'd look in the kernel log for an actual io error [08:08] I have a parent_location set to a path inherited from branching from another host and bzr expects Errno 2 (ENOENT) and fails in this case [08:08] i would say generally we should not swallow eio [08:08] it often does indicate a real hardware error [08:09] that's what we do, but it occurs during a format probe so we fail to raise NotBranchError [08:09] I think we don't have to care about *this* exotic case, but I'd like to understand what is really happening here [08:11] hehe, trying to scare me this early in my morning ? No, not hardware related ;) I can 'cd' there and issue ls -al [08:15] nothing in log, I think I will just delete this '/home' directory [08:16] ha ha ! sudo rmdir /home: Resource busy [08:22] still busy after a reboot... [08:24] haaaa, automount... [08:25] morning all [08:26] and can't be reproduced on 10.6, ok, exotic, Wontfix :) [08:27] mgz: _o/ [09:26] hi vila [09:26] argh, lp read-only, bug report lost ! [09:26] did you see my messages, or were you rebooting? [09:26] tell me there is some log somewhere I can get it back :( [09:26] poolie: nope didn't see them [09:51] hi... does anyone know if there is an easy awy to generate a reasonable-sized repository? [09:53] nm... i just used my bzr checkout :D [09:58] he guys, i'm getting Error received from smart server: ('error', 'bytes must be a string') when trying to access a certain branch [09:58] any idea's what I should be looking at to diagnose properly? [10:00] http://pastebin.com/bp8twuQm =/ [10:01] mm [10:01] thas cool! [10:01] i have no clues sorry (but i dont know much :)) [10:02] are there foreign languages in ur branch at all? [10:03] it's a very basic rails app, which includes some binary files [10:06] Glenjamin: it seems your bytes are actually unicode string, but bzr expects them to be plain string [10:06] check the input [10:07] my input is bzr push repo-url [10:07] i'm not really sure what to look at beyond that [10:07] I can push the same branch over ssh, but then I can't pull it back down over bzr+http [10:08] is it with CLI bzr? or with your own tool? [10:08] CLI bzr [10:08] that's bug then, can't say more [10:14] peitschie: your patch landed, thank you [10:15] bialix: a pleasure :). Thanks for the feedback and guidance... it's quite exciting to get my first commit to bzr & friends accepted :) [10:15] :-) [10:25] hi, does anyone around knows how to use tarmac? [10:36] Can you give me some google keywoards for this kinda of problem: Branch b1 is 3 commits ahead of b2, I want now to apply all the commits to b2 but instead of 3 commits i want to use only 1 [10:37] txdv: I think what you want is to do a "merge" from b1 to b2 [10:37] see: bzr help merge [10:38] txdv: do you mean you want the 3 commits to appear as one commit in b2? [10:38] or that you want all three commits to appear in b2 with only one command? [10:39] yes [10:39] 1 commit [10:39] i want those 3 commits to appear as 1 commit [10:39] txdv: definitely merge then :) [10:40] http://doc.bazaar.canonical.com/latest/en/user-reference/merge-help.html [10:40] Oo [10:41] quite different then from git's merge [10:41] yeah [10:41] there's no direct equivalent of git's fast-forward merge in bazaar [10:41] git's ff merge is just "pull" in bzr isn't it? [10:42] that does sound like pull or push to me definitely [10:42] not quite [10:42] pull makes your branch a copy of the other branch (same history ordering) [10:42] git pull gets the revisions you're missing [10:42] ahh [10:46] should bzr be buildable without pyrex? [10:47] well no [10:47] but it should be usable without compilation [10:47] actually, not pyrex, cython [10:48] ah right, i think i misread that as cpython in the install guide [10:48] my smart server is failing on a type check inside some pyrex code, so i'm trying to do a quick fix by building without pyrex stuff [10:49] you probably have a larger problem [10:49] i do, but I need something to work by 1pm [10:49] and what if i WANT those commit messages to be existent in the other branch? [10:49] txdv: they will be, just nested [10:49] ddaa: http://pastebin.com/bp8twuQm [10:49] I won't be able to help you, but if you have red blinking lights on your dashboard, cutting the wires to the lights is usually not the right way to proceed [10:50] haha [10:51] Glenjamin: that look like the sort of thing that very much should not happen, as in "no such bug should exist, because the test suite would catch them" [10:51] Glenjamin: bzr log won't show them [10:51] Glenjamin: so I'm inclined to think your build/package is somehow wrong [10:51] txdv: --include-merges or -n, see bzr help log [10:51] Glenjamin: what does bzr selftest tell you? [10:53] running now... the error only appears over http, not ssh [10:54] Glenjamin: does it save the subcommits or does it just save the log text with merge? [10:54] txdv: it saves the nested history afaik [10:55] so only the text [10:55] txdv: merge + commit adds the whole data of the merged revisions [10:55] no, all the revisions are stored in the repo [10:56] but bzr has a hierarchical history, and by default "bzr log" only shows the mainline [10:56] mainline = revision committed or pulled in this branch, but not revisions merged [10:56] contrast that with the default of git and hg, which show every revision [10:56] i understand [10:57] so maybe you know how I *compact*merge 3 revisions into 1? [10:57] if you really, really do want to discard the history of merged revisions [10:57] (but you probably do not really want) [10:58] then you can use "bzr revert --forget-merges" between merge and commit. [10:58] No no, lets say i have a topic branch, i do minor one-line changes in it for example 4, but it solves my problem [10:59] now 4 line changes for 4 entire commit entries is a little bit overkill, so i want it to summarize into one revision [10:59] well, no, it's not overkill in any meaningful sense [11:00] but anyway, you can "revert --forget-merges" to do what you want [11:01] or you can "bzr uncommit -r-4" then "bzr commit" on the feature branch before merging [11:01] but, and I can't stress that enough, this needless and potentially troublesome tweaking. [11:02] hm ok [11:02] What about a counterpart of git --amend [11:02] no idea what git --amend does [11:03] it uses the current revision to add stuff instead of creating x+1 [11:03] that would be "bzr uncommit" then "bzr commit" [11:06] awesome [11:06] that will do it [11:06] ddaa: thanks [11:06] * ddaa shrugs [11:25] ddaa: I managed to turn off one pyrex module, and the python fallback doesn't produce the error [11:26] running the testsuite gave me 5 fails and 36 errors - seems to be mostly pycurl [11:26] mh... maybe try disabling pycurl [11:26] AIUI bzr has a rather byzantine set of http transport layers [11:27] httplib might be less troublesome [11:27] yeah, i've done some stuff to switch the order about [11:27] but pycurl can't be turned off on ubuntu [11:27] and i'm pretty confident that the WSGI smart server app doesn't touch pycurl === samgee_ is now known as samgee [11:52] ok i have retought it [11:52] hi [11:52] why bzr uncommit && bzr commit inferior to gits commit --amend is [11:52] it doesn't save the commit history, i have to type it again in [11:52] which bzr tool allows me to select single hunks for commits? kind of 'git gui' does [11:58] hrw: bzr shelve --all might do what you want [11:58] Is there a good reason bzr is consuming all available CPU and memory when running "bzr branch http://bzr.savannah.gnu.org/r/emacs/trunk emacs" ? [11:59] Glenjamin: shelf? [11:59] or shelve? [11:59] shelve [11:59] USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND [11:59] twb 21634 64.3 49.9 579588 507536 pts/3 R+ 21:34 15:56 /usr/bin/python /usr/bin/bzr branch http://bzr.savannah.gnu.org/r/emacs/trunk emacs [11:59] Glenjamin: I do not want "git stash" replacement [11:59] dunno to who he is talking [12:00] Glenjamin: I want something which save me from reverting hunks in file in editor and do commit, revert edit, commit, revert edit, commit way [12:01] i'm not entirely sure what your workflow is here, but there's no interactive commit [12:01] looks like 'bzr commit -i' is closest which I can get [12:02] or maybe there is [12:02] you both seem to be trying to apply git-specific workflows to bazaar here [12:02] Glenjamin: I use git for few years and bzr for just few months. [12:03] Glenjamin: before used monotone, bitkeeper, subversion, cvs, rcs and my workflow was similar [12:03] i'm just intruiged as to why you'd only commit part of a file often [12:04] Glenjamin: because I did lot of changes unrelated to each other and now I want to commit them [12:04] i guess that makes sense, but why not commit between fixes? [12:15] hello! I am unsure to understand the difference between doing a pull and doing a checkout, could someone enlighten me? [12:16] Glenjamin: because lot of work is done in environments where all I have it editor [12:16] Glenjamin: and so far I did not found good replacement for 'git rebase' in bzr [12:18] so my workflow is: hack until it builds, then commit all changes in set of commits (where one commit may consume few hunks and leave few others for other commits) [12:21] yann2: A pull pulls new changes into an existing branch. A checkout creates a new checkout (which is another term for a bound branch) and pulls all history into it. [12:22] Never mind, the kernel OOM-killed it. [12:24] hrw: there's a bzr rebase plugin [12:26] bzr-rewrite [12:28] twb: Savannah hasn't deployed a smart (bzr-aware) server, so Bazaar is using its dumb transport support (plain http against the repository files). The dumb transport method was never intended as a good way to host huge projects. [12:28] Ah, I did wonder about that. [12:28] So what should I, a poor end user, do? Look for a lp mirror of emacs? [12:28] Basically, it wasa a really bad idea to migrate emacs to bzr without first ensuring there was a decent hosting platform available [12:29] and yes, use a lp mirror [12:30] Is it just lp:emacs? [12:30] Appears to be, per https://code.launchpad.net/~vcs-imports/emacs/trunk [12:32] maxb: I think it was probably also a bad idea to base a technical decision (which vcs?) on political metrics (bzr has "GNU" in its name) [12:33] I'd like to think Bazaar could work well for Emacs if it was deployed the way it's supposed to be, but yes, that's a poor rationale for the choiec [12:34] Does lp penalize me for not logging in? bzr is actually reporting a slower I/O rate from lp:emacs [12:38] Ah [12:38] Yes, LP only supports the smart server over ssh [12:38] Sigh [12:39] You'd think the emacs people would have written this down somewhere [12:39] or the sv people [12:41] * twb grumbles about having to provide an identity to a private corporation in order to clone Emacs in reasonable time [12:42] Aaaand apparently my launchpad login has expired because I haven't used it for four years [12:42] Fuck this, I'll just keep using the git mirror. [12:45] lp: needs to offer smart server for non-logged-in people [13:02] maxb > is there a command with which I can deploy a specific version, without any bzr files? [13:02] like from bzr server to prod? [13:05] yann2, bzr-upload plugin, or just the bzr export command [13:06] export sounds good :) I ll give it a try === oubiwann-away is now known as oubiwann [13:39] maxb: by chatting with #launchpad I managed to find a version of a tty browser that launchpad supports, and log in, and find out my launchpad username was actually "twb" not "trentbuck@gmail.com". Armed with this knowledge, "bzr lp-login twb" and "bzr branch lp:emacs" Just Work. [13:42] And I wrote down the results, so hopefully I won't have this problem again in another three years === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [14:53] is it possible to undo a specific revision? [14:53] the tutorial talks only about *last commit, last revision, last multiple revisions* [14:54] you can make a new commit that undoes the change of a previous one. [14:54] txdv, What you can do is reverse-cherrypick that revision and commit that as a new revision [14:55] dash: what if i changed 100lines? [14:55] txdv: OK! [14:55] awilkins: your solution was aproved, thank you very much, needed just a keywaord ;) [14:56] txdv: 'bzr merge -r Y..X' [14:56] where Y is the revision you want to undo, and X is the one before it [14:57] thanks [15:09] hi [15:10] sorry for stupid questions but how to cherry-pick changeset (changes+commit)? "bzr merge -r130..131" picked changes but not commited them [15:11] 'bzr commit' like normal :) [15:11] sure, and have to dig for commit message too? [15:11] "dig"? [15:12] dash: do "bzr log PROPERBRANCH" and copy paste commit message [15:12] oh [15:13] well if that's what you want, sure [15:13] thx [15:13] * hrw arghs again [15:14] and "bzr merge -r128..130" will squash all changes into one and leave me to commit? [15:15] yep [15:15] so how to merge 128..130 as set of revisions? [15:16] with their commit logs etc [15:18] * hrw -> food [15:24] OK, now I *really* give up. [15:24] After a couple of hours, "bzr branch lp:emacs" finally caused the kernel to OOM-kill its child process (ssh), and then hang the entire machine. [15:24] morning all [15:25] twb: what version of bzr? [15:25] Prior to the OOM it (bzr) was consuming a good 58% of the 1GiB of RAM. [15:25] jam: 2.2.0-1, Debian Squeeze [15:26] Oh, and I have carefully nice'd and ionice -c3'd it. [15:27] The git clone of the emacs git mirror, incidentally, completed successfully in around half an hour. [15:27] killing ssh because of OOM is very strange [15:27] jam: it was a child of bzr [15:28] The oom killer tries to kill children of hogs before the hogs themselves. [15:28] What's strange is that after killing SSH it didn't then kill bzr and restore my system to working order. [15:28] (Which is what has happened in the past when the OOM killer killed off things like firefox and polipo.) [15:31] I also did a "bzr branch http://bzr.sv.gnu.org/emacs/trunk" or so on another host, which had 4GiB of RAM and a quad-core 3GHz CPU, and that eventually finished. So we can probably say that bzr branch on the emacs repo requires more than 512MB and less than 4GiB of memory at peak consumption. [15:32] twb: I'm sure it requires less than 2GB, I think it is less than 1GB, but it could be 800MB or so. [15:32] also note that branching over http:// will have a different memory profile to branching via bzr+ssh:// [15:32] Right. [15:32] (I would think the latter would use less memory, but I won't guarantee it) [15:32] I tried http first and ran into problems, so I spent a couple of hours getting lp:emacs to work over ssh [15:34] According to free -m, in my fresh boot, I'm using 193M (after ignoring swap/cache). [15:34] So if it is 800MiB or so, it could have OOMed for that reason [15:35] twb: you could run with -Dmemory or "echo debug_flags = memory >> ~/.bazaar/bazaar.conf" and it will show you memory consumption on process exit (peak memory, etc) [15:35] not that it helps you a lot here, but if you are interested [15:35] Well, I'm not going to run it again right now :P [15:35] someone's accidentally pushed a branch to the repo root, is there any way I can undo this? [15:35] Glenjamin: rm .bzr/branch -rf [15:36] of course, ty! [15:36] touch .bzr/branch (if you want to prevent it for sure in the future, though the failure messages won't be perfectly clear) [15:36] will that confuse loggerhead? [15:36] jam: I was assuming that 800MB was unexpected, so I was dutifully reporting it (read: bitching) [15:36] Glenjamin: shouldn't. Loggerhead might try to open it, but it should fail as it would with any other directory [15:37] that was the problem i had so far, it didn't list the branches because the parent was a branch [15:37] Glenjamin: right, touch .bzr/branch doesn't make it a branch, .bzr/branch/format does [15:37] by creating a *file* there you prevent a directory from being created there [15:39] i start not to like bzr [15:39] bzr push just wont work :( [15:41] the solution is very inuitive [15:41] edit the file in .bzr/branch/branch.conf and change http to bzr+ssh [15:41] bzr could do better, i mean even git is more verbose about failures and it's written in C [15:43] txdv: what server were you trying to push to ? [15:45] vila: launchpad [15:46] txdv: didn't you get a warning about http not allowing write operations when you initially branch ? [15:48] jam, twb: branching emacs from lp completed in ~11 minutes here: http://paste.ubuntu.com/507301/ [15:49] the peak seemed to occur very late [15:49] vila: vmpeak = 665 [15:49] probably building the working tree? [15:49] I would guess the slowness was swapping [15:49] that, and vila has a very big pipe [15:50] jam: and it looks like we are better at saturating it these days [15:50] In case it isn't obvious from the talk of OOM killing, I run without wap [15:50] *swap [15:50] jam: but not during the whole transfer though [15:51] twb: 1GB without swap ? Unusual, why so ? (Just curious, I realize there are valid reasons to do that) [15:51] It's a netbook with a small SSD [15:51] indeed [15:52] twb: I'm pretty sure there have been related fixed in 2.2.1 but may be only in trunk... [15:52] And more to the point, my experience on 2.6 is that, when you have swap, during memory consumption your system becomes unresponsive to the point of being unable to fix it, whereas the OOM killer has maybe a one in two or three chance of recovering [15:52] linux-2.6, that is [15:53] twb: yeah, nightmarish [15:53] twb: may be even more with 12GB RAM 24GB swap system :-/ [15:54] or rather a mis-configured 12GB *without* its 24GB swap [15:58] jam, twb : wasn't there a recent merge proposal calling meliae for this king of trouble ? [15:58] vila: yes, I don't think it has landed yet, though, and you have to supply "-Ddump_memory" [15:59] vila: I dunno, man, I don't track the kernel [15:59] twb: not in the kernel, in bzr [15:59] https://code.edge.launchpad.net/~kbielefe/bzr/551391-log-memory-usage/+merge/37086 [16:00] I don't track bzr either :-) [16:00] twb: I realize you may not be able to use it though :-/ (Requires more deps and running from source) [16:00] twb: hence the url above :) [16:01] The only bzr users I know (apart from Emacs) either migrated from arch and got stuck, or are canonical employees. [16:07] So you came here to extend your horizon ? [16:08] I came here to bitch about the OOMing :P [16:09] bug reports and new people are always welcomed :) [16:09] Yeah, well. I've gotta jump through hoops to use lp [16:11] you shouldn't have to, especially if you register an ssh key to launchpad [16:11] I mean malone, not bzr lp:foo [16:11] You *do* use lp/malone for your BTS? === BasicPRO is now known as BasicOSX [16:12] we use lp yes (I'm not sure a lot of people remember the bug part was named malone ;) [16:13] as for people using bzr: https://code.edge.launchpad.net/ubuntu says there are ~200.000 active branches just for ubuntu [16:13] Is that counting all the mirrors of upstream projects? ;-) [16:15] certainly, but I think it's only a small fraction [16:18] All of a sudden my bzr pull from a SVN repo isnt working anymore. This is the error: http://pastebin.com/2vuM2Qk4 [16:18] BZR version: Bazaar (bzr) 2.1.1 on Ubuntu 10.04 [16:19] sender: sounds like a known bug in bzr-svn, what does 'bzr plugins' says for it ? [16:19] sender: -Derror would include a traceback, or you can get it from ~/.bzr.log [16:19] It looks to me like a mismatched revno-for-last-revision stuff, but I'm not positive [16:20] villa, jam: thanks. bzr plugins: svn 1.0.2 [16:21] sender: could be bug #480102 [16:21] Launchpad bug 480102 in Launchpad Bazaar Integration "assert len(tview) == tview_len (affected: 15, heat: 96)" [High,Fix released] https://launchpad.net/bugs/480102 [16:22] sender: said to be fixed in bzr-svn 1.0.4 [16:22] vila: great, i was looking for the fixed version info... going to try this. [16:24] vila: hmm ubuntu did not update its packages yet. Will see how I can override the version. [16:25] sender: you can use the bzr ppa which always carry the stable versions of bzr and some plugins (including bzr-vsn) [16:26] sender: https://edge.launchpad.net/~bzr/+archive/ppa [16:26] vila: that sounds excellent [16:26] sender: which OS vesion ? [16:26] rhaaa, which Ubuntu release I meant [16:28]