[00:18] <igc> hi all
[00:18] <igc> hi poolie, spiv
[00:33] <poolie> hi igc
[00:45] <mkanat> mwhudson: Hey hey. Sooo.... :-)
[00:45] <mwhudson> mkanat: no news is good news!
[00:45] <mkanat> mwhudson: Sigh. Not for me! :-)
[00:45] <mwhudson> although bugs that just evaporate are always a bit diconcerting
[00:46] <mkanat> mwhudson: Well, from the trace that you gave me, if that trace was in fact taken at the hang time, it looked like an OS-level problem.
[00:46] <mwhudson> mkanat: the admins are all in one timezone this week, so it's possible that outages are being fixed in more of a hurry than usual and not reported
[01:14] <gregcoit> anu idea on how to fix a "bzr: ERROR: exceptions.AssertionError: Unknown kind 'absent' " issue?
[01:15] <gregcoit> google indicates it happens on revert, but I haven't done a revert on this b..ranch
[01:15] <gregcoit> er, branch...
[01:15] <spiv> gregcoit: pastebin the full traceback?
[01:15] <gregcoit> spiv: sure
[01:16] <spiv> gregcoit: (also, please file a bug report, but hopefully we can find an easy workaround for you in the meantime)
[01:16] <gregcoit> spiv: http://pastebin.com/FGEhnVA2
[01:16] <gregcoit> spiv: np
[01:18] <spiv> gregcoit: pastebin the output of "bzr st" ?
[01:19] <gregcoit> http://pastebin.com/tEin1iJc - aha
[01:19] <gregcoit> I think I see the problem
[01:19] <gregcoit> OTHER and THIS
[01:20] <gregcoit> it's not that way on launchpad, but my guess is this confilct has to be fixed before merge will work...
[01:22] <spiv> gregcoit: the presence of conflicts shouldn't matter
[01:22] <jblue> Hello,  I've run into a problem with loggerhead 1.17, but I'm not sure if it's a bug or a configuration issue.  Looking for some assistance. Here are the errors I'm seeing:  http://pastebin.com/fj24CxgB
[01:23] <spiv> gregcoit: (although it is a bit weird to use 'bzr merge --force', are you sure you want to merge multiple branches in a single commit?)
[01:23] <spiv> jblue: looks like it's expecting a different version of the 'simplejson' modue
[01:23] <spiv> module, rather
[01:24] <gregcoit> spiv: you're right - that didn't fix it...
[01:24] <jblue> @spiv - it's odd, I'm using the one it came with
[01:24] <spiv> jblue: ok, then I have no idea :)
[01:24] <gregcoit> spiv: what I'm trying to do is download updates from launchpad without loosing changes i've made locally...
[01:24] <spiv> gregcoit: it does to me look like a bug related to trying to apply a merge to a tree that already has some changes, though.
[01:25] <spiv> So it's possible that if you commit the changes you already have (and you do need to resolve conflicts before you can do that) that then this merge will succeed
[01:25] <gregcoit> spiv: did we just say the same thing?  My understanding of bzr terminology is weak
[01:25] <gregcoit> spiv: oh, commit locally!
[01:25] <gregcoit> right?
[01:26] <spiv> Right.
[01:26] <gregcoit> so i'm not changing the stuff on launchpad...
[01:26] <gregcoit> brilliant!
[01:26] <spiv> Right.
[01:27] <jblue> @spiv, just curious, whats making you think it's a version issue with simplejson?
[01:28] <gregcoit> spiv: that worked - thanks!!!
[01:28] <spiv> Typically, the way you keep your own set of changes to a project while tracking updates from the official version is that you make a branch (e.g. 'bzr branch lp:foo'), then in that branch you can make and commit your changes, and you can merge and commit updates using "bzr merge" (and then bzr commit, resolving conflicts first if any)
[01:29] <gregcoit> spiv: kk
[01:29] <spiv> You usually want to avoid mixing your own edits with merges, so that it's easy to tell them apart later, which is why 'bzr merge' will require the --force option in that situation.
[01:29] <spiv> (So you don't accidentally mix unrelated changes)
[01:29] <spiv> gregcoit: glad I could help :)
[01:29] <spiv> jblue: just that it's reporting that the 'dumps' attribute is missing from that module
[01:30] <jblue> so dumps attrib is related to versioning?  (my python is weak)
[01:30] <spiv> jblue: if it's the right version, then you've probably got something more confusing like a circular import or something going on
[01:31] <spiv> jblue: no, I just mean that the program expected to find something in that module, and it wasn't there.  A likely cause for that sort of thing is that the module isn't the module it expected.
[01:32] <jblue> ah ok, gotcha. I think I'll backup the existing loggerhead directory, and re-install, then do a diff between the two installations to see if I can identify the problem (assuming the newer install works)
[01:34] <Peng> jblue: There's something wrong with your simplejson install, not Loggerhead, unless you created a file called simplejson.py in Loggerhead's directory or something.
[01:35] <Peng> jblue: Older versions of Loggerhead did not use simplejson; that's why you didn't experience this problem before.
[01:37] <Peng> jblue: By the way, the dumps function existed in the oldest version of simplejson I can find, before it was even called simplejson, so ISTM your installation is broken, not out-of-date.
[01:39] <jblue> yeah it's likely that the install is broken.
[01:40] <Peng> jblue: Just curious, what version of Python are you using?
[01:41] <jblue> umm lemme check
[01:42] <jblue> python 2.5.2ubuntu0
[01:42] <jblue> er.. ubuntu1
[01:42] <Peng> Ah.
[01:42] <jblue> basically 2.5.2
[01:42] <Peng> Well, you can do "python -c 'import simplejson; print simplejson.__file__'" to see where the install is.
[01:43] <Peng> Also, Ubuntu has a package for it, python-simplejsonm.
[01:43] <gregcoit> strange question - is there a way to bzr ci changes without providing a description of changes?  ie: put bzr ci in a script?
[01:43] <Peng> Err, without the m
[01:43] <Peng> gregcoit: Why not just pass -m ""?
[01:43] <gregcoit> or does it know to now ask for a description if there is no controlling termimnal
[01:43] <gregcoit> -m  I'll look at that - thanks!
[01:43] <Peng> Or, preferably, a somewhat less useless message.
[01:43] <gregcoit> Peng: ahh, gotcha - yeah, that works
[01:44] <jblue> looks like it's installed.  So does simplejson have to be symlinked into the loggerhead directory or something?
[01:44] <Peng> jblue: No.
[01:44] <Peng> jblue: It just has to be not completely broken.
[01:44] <jblue> hrm..
[01:45] <Peng> jblue: Just out of curiosity, try this: python -c "from simplejson import dumps"
[01:45] <jblue> yay!
[01:45] <Peng> Yay?
[01:46] <jblue> okay, you were right, it was looking for simplejson, which I didn't have installed
[01:46] <jblue> I had to restart serve-branches before it would work
[01:46] <Peng> If you didn't have simplejson installed, the error message should be different.
[01:46] <Peng> It would just die with an ImportError. It found some module called "simplejson".
[01:47] <jblue> odd
[01:47] <Peng> Indeed.
[01:48] <Peng> What exactly did you do to fix it? apt-get install python-simplejson?
[01:48] <jblue> I don't play with python enough to have simplejson installed without it coming from a .deb package
[01:48] <jblue> yep that exactly
[01:49] <Peng> Did you do "python -c 'import simplejson; print simplejson.__file__'" before installing it?
[01:49] <jblue> the rest of loggerhead was working
[01:50] <jblue> no I didn't, I apt-get installed just before you told me to do that
[01:50] <Peng> Oh, darn.
[01:50] <jblue> I can apt-get remove, and run that command, just for curiosity
[01:50] <Peng> Well, I suspect you have some broken copy of simplejson sitting somewhere in your PYTHONPATH. That'd make it easier to finmd.
[01:50] <Peng> find*
[01:51] <jblue> well that box has been upgraded, so it's possible an older copy of python had that file sitting around somewhere
[01:53] <jblue> in any case, thanks for your help
[01:53] <Peng> :)
[01:54] <Peng> If you do have a broken copy of simplejson somewhere, it shouldn't cause problems, but it'd still be good to take care of.
[01:54] <Peng> If only for cleanliness.
[01:54] <jblue> yeah, I'm run 'find' on  /usr/, see if it comes up with anything
[01:55] <jblue> Aha!
[01:55] <jblue> root@pse-tools-vcs:/usr# find . -name simplejson
[01:55] <jblue> ./share/python-support/python-simplejson/simplejson
[01:55] <jblue> ./share/doc/python-simplejson/docs/simplejson
[01:55] <jblue> ./lib/python-support/python-simplejson/python2.5/simplejson
[01:55] <jblue> ./lib/python-support/python-simplejson/python2.4/simplejson
[01:55] <jblue> whoops.. should've pastbin'd that
[01:57] <jblue> looks like I have python2.4 still on that system.. with simplejson, wonder if that was what it was referencing
[01:57] <Peng> It shouldn't have, unless your PYTHONPATH is weird or Loggerhead was running with Python 2.4.
[01:58] <Peng> (Does Loggerhead even support Python 2.4?)
[01:58] <jblue> No idea
[01:59] <Peng> I mean, it's probably intended to be compatible with 2.4, but I doubt it's tested regularly...
[01:59] <mwhudson> i expect loggerhead still works with 2.4
[01:59] <mwhudson> but yeah, haven't tried for a few months
[02:01] <jblue> I dunno, weird stuff.. most likely because of the layered upgrades this system has gone through
=== jblue is now known as jblue_away
[02:13] <mkanat> Yes, it works with 2.4.
[02:16] <Peng> You run it with 2.4?
[02:22] <mkanat> Peng: Yeah, that's what's on RHEL5.
[02:24] <Peng> Ah.
[02:42] <herbtea> hello all
[02:43] <herbtea> Is there a means of setting a default path to my local project repository
[02:43]  * igc lunch
[02:44] <herbtea> It is on a different drive than where the bzr.exe runs
[02:44] <herbtea> and I'm tired of having to type the full path to the project directory
[02:51] <herbtea> any help on whether I can set a default path to my local repository would be greatly appreciated :)
[02:55] <herbtea> bye
[04:00] <Peng> Uh-oh, Loggerhead wants something that got removed. Fun.
[04:01] <Peng> (get_revision_inventory)
[05:47]  * igc bbl
=== Adys is now known as packman
=== packman is now known as Adys
[06:55] <vila> hi all !
[07:06] <poolie> hello vila!
[07:06] <vila> hey poolie
[07:29] <tasslehoff> I'm trying to get started with bzr and its eclipse plugin at the same time. After setup I tried a team->status, and it says "Executing xmlstatus C:\src\bazaar\work" forever.
=== radoe_ is now known as radoe
[08:21] <tasslehoff> another Q: I used bzr-svn to check out a trunk, and create a branch called work. After doing some commits in work, what is the preferred way of getting them back into svn? In trunk I did a pull of new commits from work, and all of a sudden they were commited upstream. Surprised me a bit :)
[08:21] <Anteru> Hi
[08:21] <Anteru> I just tried Bazaar 2.1.0 on Windows 7/x64, and I got a very weird issue: Running bzr takes literally minutes to execute, no matter what I do. Even bzr help stalls for 3-4 minutes
[08:21] <Anteru> Task manager says bazaar is reading ~10 kib/s ...
[08:22] <Anteru> 2.0.4 works flawlessly
[08:22] <Anteru> Machine speed shouldn't be limiting here _at all_
[08:22] <Anteru> Any idea where to start troubleshooting?
[08:26] <Anteru> Bah, seems to be Sophos AV
[08:45] <poolie> tasslehoff, i think normally people commit in a bzr checkout of their bzr branch
[08:45] <poolie> nice nick btw
[08:48] <tasslehoff> poolie: thanks :)
[09:04] <tasslehoff> poolie: hm. I didn't understand your reply. I followed the Simple Example from http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/svn_plugin.html, but when I do multiple commits in my workbranch, I want them to appear as multiple commits in trunk/svn as well. pulling from work->trunk seems to solve this, but it automatically pushes to svn as well. not a problem really, but I need to understand this :)
[09:05] <poolie> tasslehoff, so, bzr's normal model is that you'll just make one commit to trunk rolling up all the changes for that feature
[09:05] <poolie> you can later look inside that commit to see the individual parts
[09:05] <poolie> i think this is also true once it's gone into svn
[09:05] <poolie> if you want them to look like individual commits _on trunk_ then yes you need to pull
[09:08] <tasslehoff> poolie: ok. if I have multiple commits in work that will be one commit in trunk, is there a way to automatically get a trunk commit message with all the work commit messages?
[09:10] <poolie> tasslehoff, i'm not sure about in svn
[09:10] <poolie> i think bzr-email or bzr-hookless-email can be configured to do that
[09:11] <tasslehoff> poolie: not in svn yet. I meant if I do a local merge commit from work->trunk
[09:12] <poolie> yes, bzr-email should support that
[09:13] <tasslehoff> poolie: thanks
[09:34] <Kamping_Kaiser> pointless question, but i want to be really sure on this: bzr tracks changes per *commit*, so cherry picking individual commits preserves the details of the change, wheres pulling an individual file *won't* track details?
[09:34] <jelmer> Kamping_Kaiser: what do you mean by details of the change, exactly?
[09:35] <Kamping_Kaiser> jelmer: committer/diff/commit message largely. i'm trying to decide if i should rebase a branch and pull out individual changes into a diff or try cherry picking out individual commits from the branch
[09:36] <Kamping_Kaiser> yes, i acknowledge that i've failed to use the tool correctly if i'm in this possition :/
[09:37] <jelmer> Kamping_Kaiser: cherry picking of revisions won't preserve the commit message etc
[09:37] <jelmer> Kamping_Kaiser: the replay command does
[09:37] <Kamping_Kaiser> jelmer: I'll check its help, thanks.
=== gerard_1 is now known as gerard_
[10:45] <MvG> I've got a usr-committed branch containing a fix, committed against current trunk. I want to turn that fix into a Daggy Fix, i.e. move it somewhere just after the error occurred, and more importantly, before a branching point between series. How would I do this and maintain as much metadata as possible? Cherry-Picking feels like I'd have to migrate one commit at a time, and deal with author and commit messages manually.
[10:45] <MvG> jelmer, is your rebase plugin up to this task? I think I used it to do just that in the past, but somehow can't figure out the proper invocation just now.
[10:48] <bialix> MvG: hi, there is replay command in rebase(rewrite) plugin
[10:50] <bialix> MvG: also, you may just use branch point as base revision for DaggyFix
[10:51] <MvG> bialix: thx, replay sounds good.
[10:51] <bialix> the fix for diff in trac sounds very promising, btw!
[10:52] <MvG> That's the one I want to replay. :-)
[10:54] <bialix> :-) I've thought the same
[11:12] <MvG> trac-bzr 0.3.2 released. :-)
[11:17] <bialix> \o/
[11:25] <bialix> MvG: many thanks!
[11:27] <MvG> bialix: np. The thanks should really go to James Teh for identifying and fixing the problem. I'll benefit a lot from that myself as well.
[11:28] <bialix> of course. but you maintain trac-bzr and do releases, and build/upload eggs
[11:28] <bialix> so I can easily update my installation now
[12:36] <igc> hi bialix
[12:36] <igc> bialix: thanks for the rc2 release btw
[12:47] <bialix> hi igc
[12:47] <igc> bialix: hi
[12:47] <bialix> igc: you've asked me -- so I've helped you
[12:48] <igc> bialix: really, really appreciated
[12:48] <bialix> np
[12:49] <bialix> I'm planning to release qbzr 0.18.3 tomorrow
[12:50] <bialix> igc: do we need to pack rc3
[12:50] <bialix> ?
[12:51] <igc> bialix: I'm not planning an rc3 at this stage
[12:51] <bialix> well, ok
[12:51] <bialix> it's just easier for me to do releases in row
[12:52] <igc> bialix: but I'm certainly hoping some of the treewidget bugs can be sorted out soon -gary's doing a good job working through them it seems
[12:52] <bialix> igc: I've updated POT on LP, btw, but it seems some strings are not marked for translations. Have no time to investigate right now
[12:53] <igc> bialix: bug 395175 is my biggest worry right now
[12:53] <ubottu> Launchpad bug 395175 in bzr-explorer "Refresh action can cause segmentation fault or freeze" [High,Confirmed] https://launchpad.net/bugs/395175
[12:53] <igc> that and Windows packaging
[12:54] <bialix> igc: I think running it via valgrind is good idea
[12:55] <bialix> I might help with Windows packaging, but on;y on the next weekend, sorry
[12:55] <bialix> I think today is better solution -- is to use our own rc2 installer
[12:56] <bialix> igc: at least as workaround for packaging issue
[13:01] <parthm> hello. I am trying to understand bzrlib sources. I am somewhat unclear on the terms. whats a basis_tree?
[13:02] <bialix> parthm: it's a revision tree of latest committed revision of current working tree, usually
[13:03] <parthm> ok. thanks. if i get revisionspec from a user and i need to look at its content i do a rev.as_tree(context_branch) first right?
[13:03] <parthm> i am wondering what i pass for context_branch?
[13:05] <parthm> basically i am working on bzr-grep and trying to figure out what the best way to cat files of the tree based on revspec given by the user.
[13:14] <bialix> look at the implementation of cmd_cat in bzr maybe
[13:15] <bialix> AFAIK you are need to use something like repo.revision_tree(revid)
[13:18] <parthm> ok. thanks bialix.
[13:18]  * parthm goes digging into bzrlib code.
=== bigjools is now known as bigjools-lunch
=== bigjools-lunch is now known as bigjools
[15:08] <smoser> is there a way to see '--fixes' after the fact ? i can't see it anywhere in log
[15:08] <smoser> ie: bzr commit --fixes "lp:1" -m "mission accomplished"
[15:08] <smoser> but then, how can i later see what fixed lp:1 ?
[15:10] <luks> I think it's in bzr log in recent version of bzr
[15:10] <luks> and it's been in bzr qlog since it was introduced
[15:11] <luks> in bzr qlog you can even search by bug numbers
[15:20] <smoser> hm.. i've 2.0.4 (lucid)
[15:20] <smoser> rm -Rf foo && bzr init foo && ( cd foo && echo "bar" > wark && bzr add wark && bzr commit --fixes lp:1 -m "foo world" && bzr log )
[15:20] <smoser> doesn't show anything
[15:20] <smoser> related to lp:1
[15:26] <smoser> ok. next question, how can i figure out what format a branch is in ?
[15:27] <smoser> never mind. found that.
=== pickscrape_ is now known as pickscrape
[16:03] <maxb> smoser: On lucid, you should have 2.1.0, which would show you the fixes info
[16:04] <smoser> hm..
[16:05] <smoser> hm... i wonder how i didn't have that version. now i do.
=== beuno is now known as beuno-lunch
=== salgado is now known as salgado-lunch
=== beuno-lunch is now known as beuno
[16:49] <parthm> In bzrlib, if I have a Tree or RevisionSpec object, how can I get the revno?
[16:54] <bialix> parthm: from Tree -- most likely there is no way
[16:54] <bialix> RevisionSpec has special method
[16:56] <bialix> mmm, you can get revid from RevisionSpec, but to obtain revno you have to have branch
[16:56] <parthm> bialix: I see as_revision_id but nothing for the revno. RevisionInfo seems to have an attribute revno, but I don't know how to get RevisionInfo.
[16:57] <bialix> parthm: revno makes sense only in the context of a branch
[16:58] <bialix> RevisionInfo.from_revision_id(branch, revid)
[16:58] <parthm> hmm. I am basically getting bzr-grep to work with history and have a tree and revspec. http://pastebin.com/QprGpETR
[16:58] <parthm> Oh. ok. I think wt.branch should be usable.
[16:59] <bialix> yep
[17:00] <bialix> parthm: look at plugin file-revno
[17:00] <bialix> id_to_revno = branch.get_revision_id_to_revno_map()
[17:01] <bialix> and resulting revno string is ".".join([str(n) for n in id_to_revno[rev_id]])
[17:01] <bialix> partm: &
[17:01] <bialix> partm: ^
[17:01] <bialix> because revno can be dotted you have to join it to get string
=== mordred_ is now known as mtaylor
[17:03] <parthm> Oh. ok. so I get get it directly from the branch. will try.
[17:04] <bialix> beware: branch.get_revision_id_to_revno_map() this is very expensive operation
[17:15] <maxb> Wouldn't it make a lot of sense for bzr to cache that map on disk?
[17:15] <maxb> Surely inspecting it must happen a lot more often than commit / pull happens
=== salgado-lunch is now known as salgado
[17:22] <bialix> maxb: igc wrote plugin to cache this info IIRC
[17:22] <maxb> Has it been considered whether it would be sensible for bzr core to cache it?
[17:22] <bialix> but it's not in the core. for some reason core devs don't do caches in first place
[17:23]  * bialix not quite understand maxb's question
[17:24] <maxb> OK - Why is it not done in core?
[17:25] <parthm> bialix: that worked nicely. thanks. now with the rspec given I can grep history for a particular rev and print revno in the result.
[17:25] <bialix> IIRC someone (lifeless?) said that caches makes the performance problems less visible for them
[17:26] <bialix> so core devs trying to increase the speed in firts place
[17:26] <bialix> and then suddenly nobody has the time and inspiration to write caching solution
[17:26] <bialix> partm: nice
[17:26] <bialix> maxb: so I think situation is far from ideal
[17:28] <maxb> Hmm. I agree with "caches makes the performance problems less visible" in general. However, it seems to me that assigning revnos is an intrinsically complex operation that could be done once at tip-change and would not consume much space on disk to store
[17:28] <bialix> yes, I agree
[17:29] <bialix> maybe if igc has polished his plugin more it would find the path to the core
[17:29] <bialix> unfortunately igc is busy with some other serious problems
[17:29] <bialix> and nobody else working on this
[17:30] <bialix> stalemat
[17:31] <parthm> got to go. bye. thanks for your help bialix.
[17:31]  * bialix waves
=== deryck is now known as deryck[lunch]
[17:40]  * bialix waves bye
=== deryck[lunch] is now known as deryck
=== mrjazzcat is now known as mrjazzcat-afk
=== mathrick is now known as _mathrick
=== _mathrick is now known as mathrick
=== mrjazzcat-afk is now known as mrjazzcat
[20:48] <lifeless> maxb: a revnocache is actually fairly large; pulling down 10MB of data while talking to a remote server hurts performance a lot.
[20:48] <lifeless> maxb: our early file formats were essentially using a revno cache
[20:48] <lifeless> maxb: add to that that partial rewrites over the network are really complex
[20:49] <lifeless> maxb: and that this is a per branch overhead, so you pay a lot of duplication costs.
[20:49] <lifeless> maxb: we'd /love/ a robust revno oracle; but its not actually all that simple
[20:51] <maxb> What if it was only ever used locally - never transmitted over dumb transports?
[20:51] <maxb> You could have the time saved for local and smart access, without incurring any additional bandwidth
[20:52] <lifeless> maxb: I believe thats what the current revnocache does
[20:52] <lifeless> is it sufficient is an interesting question
[20:53] <lifeless> I don't have a good answer
[20:53] <maxb> What's the current thinking, if any, on doing that in bzr core?
[20:54] <lifeless> I can give you my thinking
[20:54] <lifeless> which is that john has done amazing work working around python being silly and slow, with his frozen graph stuff
[20:55] <lifeless> so we really should be able to do revno calculation pretty speedily now
[20:55] <lifeless> and someone should look at that
[22:32] <nDuff> What's the state of bzrp4? It appears to refer to adapt_modules, which looks like it was removed some time ago...
[23:01] <barry> hi folks, is there a bzr-pipeline that works with bzr 2.1 yet?
[23:02] <barry> oh, there's bug 527775
[23:02] <ubottu> Launchpad bug 527775 in bzr-pipeline "bzr-pipeline does not work with bzr 2.1 API" [Undecided,New] https://launchpad.net/bugs/527775
[23:15] <lifeless> nDuff: probably stale
[23:16] <lifeless> james_w: how's your  offline bugs db going?
[23:16] <lifeless> james_w: will it offer local-edit-and-queuing?
[23:17] <james_w> I sort of have a cache working
[23:17] <james_w> that's what I want to do, but I haven't started that bit yet
[23:18] <lifeless> cool, I look forward to it
[23:22] <james_w> I'm kind of surprised that I couldn't find an existing twisted HTTP caching client
[23:48] <kirkland> where's the best place to get a more recent bzr version for hardy?
[23:48] <kirkland> is there an official ppa or somethign?
[23:48] <lifeless> yes
[23:48] <lifeless> its on the downloads  page in the website
[23:50]  * kirkland found it, thanks.