igchi all00:18
igchi poolie, spiv00:18
pooliehi igc00:33
mkanatmwhudson: Hey hey. Sooo.... :-)00:45
mwhudsonmkanat: no news is good news!00:45
mkanatmwhudson: Sigh. Not for me! :-)00:45
mwhudsonalthough bugs that just evaporate are always a bit diconcerting00:45
mkanatmwhudson: 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
mwhudsonmkanat: 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 reported00:46
gregcoitanu idea on how to fix a "bzr: ERROR: exceptions.AssertionError: Unknown kind 'absent' " issue?01:14
gregcoitgoogle indicates it happens on revert, but I haven't done a revert on this b..ranch01:15
gregcoiter, branch...01:15
spivgregcoit: pastebin the full traceback?01:15
gregcoitspiv: sure01:15
spivgregcoit: (also, please file a bug report, but hopefully we can find an easy workaround for you in the meantime)01:16
gregcoitspiv: http://pastebin.com/FGEhnVA201:16
gregcoitspiv: np01:16
spivgregcoit: pastebin the output of "bzr st" ?01:18
gregcoithttp://pastebin.com/tEin1iJc - aha01:19
gregcoitI think I see the problem01:19
gregcoitOTHER and THIS01:19
gregcoitit's not that way on launchpad, but my guess is this confilct has to be fixed before merge will work...01:20
spivgregcoit: the presence of conflicts shouldn't matter01:22
jblueHello,  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/fj24CxgB01:22
spivgregcoit: (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
spivjblue: looks like it's expecting a different version of the 'simplejson' modue01:23
spivmodule, rather01:23
gregcoitspiv: you're right - that didn't fix it...01:24
jblue@spiv - it's odd, I'm using the one it came with01:24
spivjblue: ok, then I have no idea :)01:24
gregcoitspiv: what I'm trying to do is download updates from launchpad without loosing changes i've made locally...01:24
spivgregcoit: 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:24
spivSo 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 succeed01:25
gregcoitspiv: did we just say the same thing?  My understanding of bzr terminology is weak01:25
gregcoitspiv: oh, commit locally!01:25
gregcoitso i'm not changing the stuff on launchpad...01:26
jblue@spiv, just curious, whats making you think it's a version issue with simplejson?01:27
gregcoitspiv: that worked - thanks!!!01:28
spivTypically, 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:28
gregcoitspiv: kk01:29
spivYou 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
spivgregcoit: glad I could help :)01:29
spivjblue: just that it's reporting that the 'dumps' attribute is missing from that module01:29
jblueso dumps attrib is related to versioning?  (my python is weak)01:30
spivjblue: if it's the right version, then you've probably got something more confusing like a circular import or something going on01:30
spivjblue: 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:31
jblueah 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:32
Pengjblue: 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:34
Pengjblue: Older versions of Loggerhead did not use simplejson; that's why you didn't experience this problem before.01:35
Pengjblue: 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:37
jblueyeah it's likely that the install is broken.01:39
Pengjblue: Just curious, what version of Python are you using?01:40
jblueumm lemme check01:41
jbluepython 2.5.2ubuntu001:42
jblueer.. ubuntu101:42
jbluebasically 2.5.201:42
PengWell, you can do "python -c 'import simplejson; print simplejson.__file__'" to see where the install is.01:42
PengAlso, Ubuntu has a package for it, python-simplejsonm.01:43
gregcoitstrange question - is there a way to bzr ci changes without providing a description of changes?  ie: put bzr ci in a script?01:43
PengErr, without the m01:43
Penggregcoit: Why not just pass -m ""?01:43
gregcoitor does it know to now ask for a description if there is no controlling termimnal01:43
gregcoit-m  I'll look at that - thanks!01:43
PengOr, preferably, a somewhat less useless message.01:43
gregcoitPeng: ahh, gotcha - yeah, that works01:43
jbluelooks like it's installed.  So does simplejson have to be symlinked into the loggerhead directory or something?01:44
Pengjblue: No.01:44
Pengjblue: It just has to be not completely broken.01:44
Pengjblue: Just out of curiosity, try this: python -c "from simplejson import dumps"01:45
jblueokay, you were right, it was looking for simplejson, which I didn't have installed01:46
jblueI had to restart serve-branches before it would work01:46
PengIf you didn't have simplejson installed, the error message should be different.01:46
PengIt would just die with an ImportError. It found some module called "simplejson".01:46
PengWhat exactly did you do to fix it? apt-get install python-simplejson?01:48
jblueI don't play with python enough to have simplejson installed without it coming from a .deb package01:48
jblueyep that exactly01:48
PengDid you do "python -c 'import simplejson; print simplejson.__file__'" before installing it?01:49
jbluethe rest of loggerhead was working01:49
jblueno I didn't, I apt-get installed just before you told me to do that01:50
PengOh, darn.01:50
jblueI can apt-get remove, and run that command, just for curiosity01:50
PengWell, I suspect you have some broken copy of simplejson sitting somewhere in your PYTHONPATH. That'd make it easier to finmd.01:50
jbluewell that box has been upgraded, so it's possible an older copy of python had that file sitting around somewhere01:51
jbluein any case, thanks for your help01:53
PengIf 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
PengIf only for cleanliness.01:54
jblueyeah, I'm run 'find' on  /usr/, see if it comes up with anything01:54
jblueroot@pse-tools-vcs:/usr# find . -name simplejson01:55
jbluewhoops.. should've pastbin'd that01:55
jbluelooks like I have python2.4 still on that system.. with simplejson, wonder if that was what it was referencing01:57
PengIt shouldn't have, unless your PYTHONPATH is weird or Loggerhead was running with Python 2.4.01:57
Peng(Does Loggerhead even support Python 2.4?)01:58
jblueNo idea01:58
PengI mean, it's probably intended to be compatible with 2.4, but I doubt it's tested regularly...01:59
mwhudsoni expect loggerhead still works with 2.401:59
mwhudsonbut yeah, haven't tried for a few months01:59
jblueI dunno, weird stuff.. most likely because of the layered upgrades this system has gone through02:01
=== jblue is now known as jblue_away
mkanatYes, it works with 2.4.02:13
PengYou run it with 2.4?02:16
mkanatPeng: Yeah, that's what's on RHEL5.02:22
herbteahello all02:42
herbteaIs there a means of setting a default path to my local project repository02:43
* igc lunch02:43
herbteaIt is on a different drive than where the bzr.exe runs02:44
herbteaand I'm tired of having to type the full path to the project directory02:44
herbteaany help on whether I can set a default path to my local repository would be greatly appreciated :)02:51
PengUh-oh, Loggerhead wants something that got removed. Fun.04:00
* igc bbl05:47
=== Adys is now known as packman
=== packman is now known as Adys
vilahi all !06:55
pooliehello vila!07:06
vilahey poolie07:06
tasslehoffI'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.07:29
=== radoe_ is now known as radoe
tasslehoffanother 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
AnteruI 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 minutes08:21
AnteruTask manager says bazaar is reading ~10 kib/s ...08:21
Anteru2.0.4 works flawlessly08:22
AnteruMachine speed shouldn't be limiting here _at all_08:22
AnteruAny idea where to start troubleshooting?08:22
AnteruBah, seems to be Sophos AV08:26
poolietasslehoff, i think normally people commit in a bzr checkout of their bzr branch08:45
poolienice nick btw08:45
tasslehoffpoolie: thanks :)08:48
tasslehoffpoolie: 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:04
poolietasslehoff, so, bzr's normal model is that you'll just make one commit to trunk rolling up all the changes for that feature09:05
poolieyou can later look inside that commit to see the individual parts09:05
pooliei think this is also true once it's gone into svn09:05
poolieif you want them to look like individual commits _on trunk_ then yes you need to pull09:05
tasslehoffpoolie: 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:08
poolietasslehoff, i'm not sure about in svn09:10
pooliei think bzr-email or bzr-hookless-email can be configured to do that09:10
tasslehoffpoolie: not in svn yet. I meant if I do a local merge commit from work->trunk09:11
poolieyes, bzr-email should support that09:12
tasslehoffpoolie: thanks09:13
Kamping_Kaiserpointless 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
jelmerKamping_Kaiser: what do you mean by details of the change, exactly?09:34
Kamping_Kaiserjelmer: 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 branch09:35
Kamping_Kaiseryes, i acknowledge that i've failed to use the tool correctly if i'm in this possition :/09:36
jelmerKamping_Kaiser: cherry picking of revisions won't preserve the commit message etc09:37
jelmerKamping_Kaiser: the replay command does09:37
Kamping_Kaiserjelmer: I'll check its help, thanks.09:37
=== gerard_1 is now known as gerard_
MvGI'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
MvGjelmer, 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:45
bialixMvG: hi, there is replay command in rebase(rewrite) plugin10:48
bialixMvG: also, you may just use branch point as base revision for DaggyFix10:50
MvGbialix: thx, replay sounds good.10:51
bialixthe fix for diff in trac sounds very promising, btw!10:51
MvGThat's the one I want to replay. :-)10:52
bialix:-) I've thought the same10:54
MvGtrac-bzr 0.3.2 released. :-)11:12
bialixMvG: many thanks!11:25
MvGbialix: 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:27
bialixof course. but you maintain trac-bzr and do releases, and build/upload eggs11:28
bialixso I can easily update my installation now11:28
igchi bialix12:36
igcbialix: thanks for the rc2 release btw12:36
bialixhi igc12:47
igcbialix: hi12:47
bialixigc: you've asked me -- so I've helped you12:47
igcbialix: really, really appreciated12:48
bialixI'm planning to release qbzr 0.18.3 tomorrow12:49
bialixigc: do we need to pack rc312:50
igcbialix: I'm not planning an rc3 at this stage12:51
bialixwell, ok12:51
bialixit's just easier for me to do releases in row12:51
igcbialix: 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 seems12:52
bialixigc: I've updated POT on LP, btw, but it seems some strings are not marked for translations. Have no time to investigate right now12:52
igcbialix: bug 395175 is my biggest worry right now12:53
ubottuLaunchpad bug 395175 in bzr-explorer "Refresh action can cause segmentation fault or freeze" [High,Confirmed] https://launchpad.net/bugs/39517512:53
igcthat and Windows packaging12:53
bialixigc: I think running it via valgrind is good idea12:54
bialixI might help with Windows packaging, but on;y on the next weekend, sorry12:55
bialixI think today is better solution -- is to use our own rc2 installer12:55
bialixigc: at least as workaround for packaging issue12:56
parthmhello. I am trying to understand bzrlib sources. I am somewhat unclear on the terms. whats a basis_tree?13:01
bialixparthm: it's a revision tree of latest committed revision of current working tree, usually13:02
parthmok. 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
parthmi am wondering what i pass for context_branch?13:03
parthmbasically 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:05
bialixlook at the implementation of cmd_cat in bzr maybe13:14
bialixAFAIK you are need to use something like repo.revision_tree(revid)13:15
parthmok. thanks bialix.13:18
* parthm goes digging into bzrlib code.13:18
=== bigjools is now known as bigjools-lunch
=== bigjools-lunch is now known as bigjools
smoseris there a way to see '--fixes' after the fact ? i can't see it anywhere in log15:08
smoserie: bzr commit --fixes "lp:1" -m "mission accomplished"15:08
smoserbut then, how can i later see what fixed lp:1 ?15:08
luksI think it's in bzr log in recent version of bzr15:10
luksand it's been in bzr qlog since it was introduced15:10
luksin bzr qlog you can even search by bug numbers15:11
smoserhm.. i've 2.0.4 (lucid)15:20
smoserrm -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
smoserdoesn't show anything15:20
smoserrelated to lp:115:20
smoserok. next question, how can i figure out what format a branch is in ?15:26
smosernever mind. found that.15:27
=== pickscrape_ is now known as pickscrape
maxbsmoser: On lucid, you should have 2.1.0, which would show you the fixes info16:03
smoserhm... i wonder how i didn't have that version. now i do.16:05
=== beuno is now known as beuno-lunch
=== salgado is now known as salgado-lunch
=== beuno-lunch is now known as beuno
parthmIn bzrlib, if I have a Tree or RevisionSpec object, how can I get the revno?16:49
bialixparthm: from Tree -- most likely there is no way16:54
bialixRevisionSpec has special method16:54
bialixmmm, you can get revid from RevisionSpec, but to obtain revno you have to have branch16:56
parthmbialix: 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:56
bialixparthm: revno makes sense only in the context of a branch16:57
bialixRevisionInfo.from_revision_id(branch, revid)16:58
parthmhmm. I am basically getting bzr-grep to work with history and have a tree and revspec. http://pastebin.com/QprGpETR16:58
parthmOh. ok. I think wt.branch should be usable.16:58
bialixparthm: look at plugin file-revno17:00
bialixid_to_revno = branch.get_revision_id_to_revno_map()17:00
bialixand resulting revno string is ".".join([str(n) for n in id_to_revno[rev_id]])17:01
bialixpartm: &17:01
bialixpartm: ^17:01
bialixbecause revno can be dotted you have to join it to get string17:01
=== mordred_ is now known as mtaylor
parthmOh. ok. so I get get it directly from the branch. will try.17:03
bialixbeware: branch.get_revision_id_to_revno_map() this is very expensive operation17:04
maxbWouldn't it make a lot of sense for bzr to cache that map on disk?17:15
maxbSurely inspecting it must happen a lot more often than commit / pull happens17:15
=== salgado-lunch is now known as salgado
bialixmaxb: igc wrote plugin to cache this info IIRC17:22
maxbHas it been considered whether it would be sensible for bzr core to cache it?17:22
bialixbut it's not in the core. for some reason core devs don't do caches in first place17:22
* bialix not quite understand maxb's question17:23
maxbOK - Why is it not done in core?17:24
parthmbialix: 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
bialixIIRC someone (lifeless?) said that caches makes the performance problems less visible for them17:25
bialixso core devs trying to increase the speed in firts place17:26
bialixand then suddenly nobody has the time and inspiration to write caching solution17:26
bialixpartm: nice17:26
bialixmaxb: so I think situation is far from ideal17:26
maxbHmm. 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 store17:28
bialixyes, I agree17:28
bialixmaybe if igc has polished his plugin more it would find the path to the core17:29
bialixunfortunately igc is busy with some other serious problems17:29
bialixand nobody else working on this17:29
parthmgot to go. bye. thanks for your help bialix.17:31
* bialix waves17:31
=== deryck is now known as deryck[lunch]
* bialix waves bye17:40
=== 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
lifelessmaxb: a revnocache is actually fairly large; pulling down 10MB of data while talking to a remote server hurts performance a lot.20:48
lifelessmaxb: our early file formats were essentially using a revno cache20:48
lifelessmaxb: add to that that partial rewrites over the network are really complex20:48
lifelessmaxb: and that this is a per branch overhead, so you pay a lot of duplication costs.20:49
lifelessmaxb: we'd /love/ a robust revno oracle; but its not actually all that simple20:49
maxbWhat if it was only ever used locally - never transmitted over dumb transports?20:51
maxbYou could have the time saved for local and smart access, without incurring any additional bandwidth20:51
lifelessmaxb: I believe thats what the current revnocache does20:52
lifelessis it sufficient is an interesting question20:52
lifelessI don't have a good answer20:53
maxbWhat's the current thinking, if any, on doing that in bzr core?20:53
lifelessI can give you my thinking20:54
lifelesswhich is that john has done amazing work working around python being silly and slow, with his frozen graph stuff20:54
lifelessso we really should be able to do revno calculation pretty speedily now20:55
lifelessand someone should look at that20:55
nDuffWhat's the state of bzrp4? It appears to refer to adapt_modules, which looks like it was removed some time ago...22:32
barryhi folks, is there a bzr-pipeline that works with bzr 2.1 yet?23:01
barryoh, there's bug 52777523:02
ubottuLaunchpad bug 527775 in bzr-pipeline "bzr-pipeline does not work with bzr 2.1 API" [Undecided,New] https://launchpad.net/bugs/52777523:02
lifelessnDuff: probably stale23:15
lifelessjames_w: how's your  offline bugs db going?23:16
lifelessjames_w: will it offer local-edit-and-queuing?23:16
james_wI sort of have a cache working23:17
james_wthat's what I want to do, but I haven't started that bit yet23:17
lifelesscool, I look forward to it23:18
james_wI'm kind of surprised that I couldn't find an existing twisted HTTP caching client23:22
kirklandwhere's the best place to get a more recent bzr version for hardy?23:48
kirklandis there an official ppa or somethign?23:48
lifelessits on the downloads  page in the website23:48
* kirkland found it, thanks.23:50

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!