[00:35] I have a branch stored on my webserver, and I did a checkout on it. but I can't commit. I get bzr: ERROR: Cannot commit to branch BzrBranch6('file://local-path'). It is bound to BzrBranch6(sftp.....') which is bound to sftp:same-path. [00:36] so BzrBranch6(sftp-path) is bound to sftp-path sounds circular... but I have no idea.... [00:37] izm99: that sounds as if the branch on your server is a checkout. [00:37] LarstiQ: so how can I commit to it? [00:37] izm99: what does `bzr info` return for sftp:remote-path? [00:38] checkout root: . [00:38] oh sorry.. of remote path.. one sec [00:39] branch root: http://stevenbrown.ca/src/AttrDict/ [00:39] bound to branch: sftp://blah@blah/src/AttrDict/ [00:40] related branches: push branch: sftp://blah@blah/src/AttrDict/ [00:40] and the bound branch is the same as that branch itself? [00:40] 'bound to branch' [00:40] i kinda fudged when I put it up there.... ¬_¬ [00:41] izm99: if so, that's rather silly. Issue a `bzr unbind` on the remote branch. [00:41] izm99: after that, you should be able to commit in the local one. [00:41] oooh.. ok, i'll try [00:42] wait, do i have to ssh into the remote host to do that? [00:42] izm99: yeah, fraid so. [00:42] dang [00:42] bzr isn't actually installed on that. [00:43] if you're not afraid to touch .bzr we can do it without bzr installed. [00:43] i'm in [00:44] :D [00:44] (i have a local copy anyways, this is a learning exercise) [00:44] ok [00:45] izm99: see .bzr/branch/branch.conf [00:46] izm99: it should have a bound_location and a boolean 'bound' option. [00:46] izm99: toggle the latter to false, and you should be good to go. [00:49] hmm.... it let me commit [00:50] izm99: so your problem is fixed now? [00:50] not really... it didn't actually change the files [00:52] * LarstiQ needs a bit more context [00:52] where did you commit, and where didn't files change? [00:52] yeah, sorry, I'm trying to poke around... [00:52] Committing to: sftp://stiibu@stevenbrown.ca/home/stiibu/stevenbrown.ca/src/AttrDict/ [00:52] added COPYING [00:52] modified attrdict.py [00:52] modified test_attrdict.py [00:52] Committed revision 2. [00:52] (woops username.. oh well) [00:53] that looks like it worked to me. === bac is now known as bac|away [00:53] ya.. [00:53] izm99: I'm guessing you're expecting the checkout on stevenbrown.ca to also have updated? [00:53] bzr status http://stevenbrown.ca/src/AttrDict -> bzr: ERROR: Path(s) do not exist: http:/stevenbrown.ca/src/AttrDict [00:53] yes i am [00:53] that doesn't actually happen. [00:53] oh. [00:53] i have to push? [00:54] izm99: no no, the .bzr file got updated fine. [00:54] (unless I'm bound)? [00:54] izm99: so the question is, what are you trying to accomplish? [00:54] i wanted to update the remote branch with my commit [00:54] izm99: if you just want to publish your branch, you don't have to do anything extra, since all bzr cares about is .bzr, and that's updated. [00:55] izm99: is your use case something like website deployment? [00:55] izm99: or do you want to be able browse the content of the branch? [00:55] yeah, i want the source to browsable, as well [00:55] izm99: ok, for the latter I'd probably recommend running loggerhead to do that. [00:56] * izm99 googles [00:56] izm99: That's an actual webfrontend akin to things like viewcvs if you are familiar with that. [00:56] yes, I'm familiar [00:57] so the changes have been committed, but the actual files are not updated? The changes are stored in the .bzr somewhere? [00:59] izm99: The changes have been commited, yes. The files outside of .bzr are not touched, I wouldn't call them 'actual files' though :) [00:59] izm99: so, if you wanted to updated the files there, you could do 'bzr update' [00:59] ooooh.... [01:00] izm99: there is a plugin to ssh into the remote machine and run update after a push if you want something like that. [01:00] so I should pretty much at least install bzr on the remote machine... [01:00] I was trying to avoid any server stuff... [01:01] izm99: if you want to do code browsing there, yes. [01:01] izm99: the alternative is having to transfer all the files in the working tree every time, that's rather expensive though. [01:02] izm99: at this point I would step back and consider if browsing on the server is really what I want to do then. [01:03] hah.. ok, I believe you.. i just tried another checkout. :P [01:03] * izm99 checks local bzr version [01:04] so, there's likely incompatibilities between bzr versions, right? [01:04] my local is : bzr 1.3.1, python 2.5.2;; remote is : python 2.3 [01:04] izm99: depending on versions, yes. But you're not combining 0.11 with 1.5 are you? [01:04] izm99: ah see, we kinda depend on python2.4 or higher. [01:05] i'm just curious ... ya, that was my next question. [01:05] i figured the python would be too old. [01:05] >.< [01:06] is it a bzr option to transfer the working tree? [01:06] izm99: check out bzr-upload plugin [01:06] izm99: yes [01:12] hmm.. ok, should i take the debian or trunk branch of bzr-upload? [01:14] izm99: the debian branch is specifically for Debian packaging, it doesn't bring you other benefits. [01:14] oh ok. [01:15] izm99: it might mean that you can just apt-get install bzr-upload depending on what suite of Debian you are running. But bzr 1.3.1 looks older than what is in sid. [01:15] and I doubt it's in anything else at this point. [01:15] i'm using hardy [01:15] just searched, not there [01:16] i'll follow the directions to branch into .bazaar/plugins/ directory. [01:16] right [01:24] i'm guessing a lot of plugins have a hypen in the name... it'd be nice if bzr had some install_plugin command that renamed the plugin branch appropriately when grabbing it. [01:25] yes [01:25] whoo! it worked. Thanks for all the help! [01:26] izm99: so, _now_ everything you want to do works? :) [01:27] yes! LarstiQ: Thank you very much. :D [01:27] good, good. [01:27] * LarstiQ continues poking at python-nautilus. [01:27] ^.^ [01:28] for some reason the nautilus-bzr stuff doesn't work when I think it should. [01:29] But phatch has a nautilus extension that does work, so it _is_ possible. [01:29] it's so amazingly funny [01:29] you know Novell folks also work/will work on nautilus-bzr, right? xD [01:29] what happened with the collaboration I though exists in FOSS world? :-/ [01:30] oh well [01:30] pygi: huh what? [01:31] how should I know this? [01:31] at least I think that's correct, If I understood right [01:31] I'll have to investigate [01:31] LarstiQ, no idea, I'm just talking in general xD [01:32] pygi: the problem was that nautilus doesn't pick the script up from ~/.nautilus/python/, but it does look at /usr/lib/nautilus/extensions-1.0/python/ [01:32] * LarstiQ insers an extensions-1.0 in his home dir variant [01:33] pygi: I'd like to know more about that. Have you been at GUADEC this year? [01:33] LarstiQ, I haven't, no ... [01:34] LarstiQ, I'll investigate that more for you in the coming days, to see if I got it right [01:34] but I think I have, and there'll also be nautilus-hg, nautilus-git and similar [01:34] strace ftw, .nautilus/python-extensions [01:35] pygi: riight. [01:35] * pygi has to make them collaborate with you then =) [01:35] pygi: I admit to not having followed bzr lately. [01:36] but I'm sleeping now, it's 2:35AM, and I gotta get up in 3 hours and 25 minutes :P [01:36] pygi: so Mark Hammond and I discussed TortoiseBazaar today, and our idea was to use the same code at one side of the pipe, and/but write a small nautilus thingy that does the equivalent of windows shell. [01:36] enjoy folks :) [01:36] pygi: have fun [01:36] LarstiQ, we'll talk about that tomorrow, ok? [01:36] pygi: yes/no [01:36] pygi: please do talk to me [01:37] pygi: but I'll be away untill Sunday/Monday [01:37] LarstiQ, ah, ok, then Monday it is :) [01:37] pygi: you can paste links at me and I'll read my backlog when I get back. [01:37] sure, that works too perhaps :) [01:37] * pygi is officially in sleep-mode [01:39] sigh, I'm reminded of why I didn't use nautilus in the first place. [01:39] LarstiQ: why not? [01:40] izm99: I recall there being some option to turn it off, but the main thing that is annoying me right now is it's autospawning. [01:41] LarstiQ: oooh... yeah, that bothers me sometimes too, actually. never bothered looking for how to turn it off. [01:42] LarstiQ: but i'm interested to try the new tab interface... :) [01:42] also, I don't appreciate it chaning my root window. === bac|away is now known as bac [01:44] ah, -n is helpful === bac is now known as bac|away [02:03] emilis_info: Just installed taglist (finally!), quick test looks great! [02:03] emilis_info: so thanks :) [02:03] hmm, branch lp:,mysql-server going since yesterday arvo... still going... [02:22] poolie: i have some user doc on stacked branches in progress. Will put a patch up later today. [02:22] explaining 'policies' is the main thing left to do [02:25] igc, hi [02:26] does bazaar support encrypted repositories? i searched and found only one plugin that released no code and has not been touched in a year. anyone know of anything else? [02:27] i think there's just that [02:27] so no, they're not supported [02:28] ok, thanks. i sent an email to the author asking about it. === sm is now known as sm1 [02:45] I was going to ask, why... you can have it on an encrypted fs anyway [02:46] arjenAU: well it would be kind of nice to host it on an untrusted server [02:46] it's distributed, allover the place, bzr needs to know the pwd anyway... and so on. messy. and slow [02:46] it is a bit of an edge case [02:46] poolie: well that's true I suppose. but would you really... that's tricky for other reasons [02:56] imo it's more of a cool feature than a useful one [02:57] poolie: yup. nice for later. right now, aim for speed. the mysql-server branching is upsetting me a bit, fortunately its a one off but it's heading towards a 24hr thing [03:02] could you be maybe pulling into or from a knit repository? === bac|away is now known as bac === Linnk is now known as Tank|Away [03:39] jml, i think i have a fix now [03:39] happy to say [03:39] poolie: sweet [03:39] poolie: I am happy to hear it. [03:41] I was wondering what the default merge algorithm was. in the user reference it shows 4 options, diff3, lca, merge3 and weave but doesn't show what the default it. [03:41] is* [03:44] libwilliam: merge3 [03:44] mwhudson, thanks [03:56] * igc lunch === sm1 is now known as sm [04:55] arjenAU: so i can branch mysql-6.0 from launchpad in about 20 minutes [04:56] and my adsl link is busy with other stuff [04:56] it should be roughly comparable for you? [04:56] poolie: i' grabbing mysql-server (that is all branches) [04:56] but if you put them in a repo most of the data should be shared? [04:56] and I have ADSL2+.. it's not eating the bandwidth. it's just slow as. no idea what it's doing [04:57] check using bzr info they have the same format [04:57] hmm [04:58] remote? on lp? [05:02] poolie: perhaps i'm confused somewhere. on my box I just do bzr init-repo mysql, cd mysql, bzr branch lp:mysql-server [05:02] flawed logic that that should be ok? [05:03] I think the repo-init was done with an old bzr, I've just restarted the whole thing and we'll see.... [05:03] that might've been the issue. [05:04] poolie: would be godo to have bzr complain about version stuff between repo and the branch you're trying to get. also, perhaps have lp refuse ancient bzr clients to protect them against what I had the other day, namely bzr pulling about 20G of data and putting it nowhere. ate my iiNet allowance ;-) [05:05] poolie: it'd be great if you could bug the launchpad ppl to have init-repo there, takes 7+hrs to push a mysql branch :( [05:08] stewart: stacked branches coming soon! [05:08] mwhudson: yay :) [05:09] in a couple of weeks i guess [05:10] How big is the repo for one branch of mysql-server? [05:11] stewart: FWIW, I push things to shared repos on my own server, and have Launchpad mirror from there. It still uses lots of my server's bandwidth, but pushing is quick. [05:12] Peng: 500mb or so i think.... [05:12] $ du -sh ~/mysql/.bzr [05:12] 619M /home/stewart/mysql/.bzr [05:12] that's shared repo... but i'm pushing 6.0 branches, which is latest, so includes about all history. [05:13] Nice. I tried to branch it once on a VPS with very little memory and it almost died. :D [05:15] Peng: yeah... branching into shared repo is quite quick (2minutes for a new mysql branch being pulled from europe over bzr+ssh over ADSL1). wish it was that quick for pushing to lp [05:16] i guess it [05:17] 's not worth it with stacked branches looming, but otherwise i'd suggest getting a machine in the uk you could host a shared repo on and have lp mirror those branches, like Peng said [05:17] Yeah, exactly. [05:17] mwhudson, Peng: there's machines and stuff within Sun that i could do that with, although it involves going through people, not as direct as "bzr push lp:...." [05:18] stewart: you can probably make it pretty easy actually (have you seen register-branch?) but well yeah [05:18] stewart: hence why stacked branches are priority 1 [05:19] stewart: If you have to go through people, they probably won't appreciate you using that much disk space and bandwidth.. :P [05:30] arjenAU: yes, those commands are correct; yes, we should make it give a warning when doing a transfer or conversion that will be slow [05:30] or possibly on any access to a really old format [05:30] and as mwhudson says stacking should fix this on lp soon [05:31] poolie: I think the latter was the prob. and there's no indication for it so blocking it would be fine [05:31] I mean the old format foo [05:31] itt's doing better now on the progress bar. sanity is prevaling [05:33] yay [05:34] little things like a warning would make a big difference [05:34] i'll try to add one soon [05:37] yep. tnx. [05:38] poolie: I'd say just block old stuff. say to upgrade. [05:38] jml, i think i'm on the home stretch now [05:39] or at least another stretch :) [05:42] poolie: yay [05:49] poolie: yay [05:50] i have an change i should separate out that puts you into the debugger when a test fails [05:50] it's super useful [05:50] can't believe i haven't done it before [05:50] Wait, yay what? [05:50] yay stacking is nearly landed [05:50] Oh, yay. :) [05:50] i have a suggestion, it'd be cool to have "bzr conflicts" print out a list of files directly, so you could: emacs `bzr conflicts` [05:51] oh... --text does that [05:51] poolie: mysql-server 50 minutes. all done [05:51] stewart: yes, but it kind of annoys me it's not the default [05:51] also it would be nice if we could run the editor for you [05:51] How exactly does stacking work? Does it cache X revisions locally? Does it cache all revisions starting at X? [05:51] though emacs users might not prefer it [05:52] Peng: basically the second [05:52] it's not really a cache though [05:53] Yeah, I know. [05:54] Can you (automatically) remove older revisions from the local repo? [05:54] Should we always use stacked branches, or only when it's necessary? [05:54] stewart: $ grep -c 'vim $(bzr conflicts --text)' /home/mwh/.bash_long_history [05:54] 23 [05:54] :) [06:03] peng, if you're familiar with a union filesystem mount it's kinda like that [06:47] jml, mwhudson, i have only 3 more failures, all repetitions of the same test and i think i know why [06:48] \o/ [06:48] \o/ [06:48] poolie: what exactly is in this branch btw? [06:48] integration of stacking into trunk [06:48] poolie: branch7 etc but not the stacking policy? [06:49] not the policy patch but that's pretyt small [06:49] i know it does need to be merged too [06:49] cool [06:49] if it lands, i'll run a launchpad make check tonight against bzr.dev [06:52] jelmer: known issue about apr-config and rst2html binaries being arbitrarily used by "make" in bzr-svn? (i have apr-1-config and rst2html.py here...) [06:53] chandlerc: what do you mean by 'arbitrarily'? [06:57] it doesn't seem to do any detection of the path, or variable substitution [06:57] but i haven't looked directly at the makefile -- could be dead wrong [06:59] poolie: ahh, it seems RST2HTML is a variable, apr-config comes out of setup.py, but it actually keeps testing till it finds (correctly) apr-1-config, so the "error message" is just not swallowed [07:00] poolie: setting RST2HTML=rst2html.py fixed it right up, although it didn't fail fatally before, just didn't bulid the HTML docs, which is fine [07:20] Random: bzrlib/tests/ is 106k lines of code, including whitespace and everything. [07:21] All of bzrlib is 211k. [07:53] Moin. [07:54] Hmm, I have an appointment in 6.5 hours. I should sleep or something. [08:02] Jc2k: pong [08:02] poolie: hi, can't skype from here, can use phone [08:02] hi lifeless [08:02] that could be good [08:02] i can call you if you want [08:03] just starting a talk now, is 55 minutes ok for you? I'll ring - cheaper [08:06] ok [08:08] Do we have any test coverage figures for bzr? [08:08] no [08:08] there may be some support for making it, i'm not sure [08:11] poolie, Odd_Bloke: I'm not aware of any figures, spiv may (he implemented the --coverage global option and used it at least for parts of bzr). I'm interested in such figures too. [08:12] and hi all :) [08:14] hello vila [08:14] i should mail you [08:29] is there a particular reason the gtk plugin doesn't offer a 'glog' command? Is it considered that gannotate is all you really need? [08:30] (I'm hoping to directly reuse almost all of the 'g' commands for tbzr) [08:33] I think 'viz' usually fills that role in -gtk... [08:33] markh: `bzr viz` fills that role [08:33] ahh, thanks. I missed that as it doesn't start with 'g' :) [08:34] Maybe someone should add an alias? [08:34] Peng: if you do `bzr help commands` everything says where it comes from. You can always just ` | grep gtk` [08:35] Peng: but perhaps an alias would be good - unless someone is planning on writing a glog that does something else. [08:35] but you do get "tricked" into thinking that gtk adds a new version of most common commands, but with a 'g' prefix [08:35] Which unfortunately fails when descriptions go to more than one line :| [08:35] * fullermd wishes for "bzr plugin-commands $FOO" [08:35] but I admit it was there for me to find :) [08:36] fullermd: aren't the descriptions single lines? If not, "oh" [08:36] Not all. [08:36] fullermd: Maybe "bzr help plugins/foo" should list them. [08:36] cvsps-upgrade-conversion Convert the old layout of branches to the new one. [08:36] [cvsps] [08:36] fetch-ghosts Attempt to retrieve ghosts from another branch. [08:36] [bzrtools] [08:36] [etc] [08:37] You'd think a project which refuses to feed its output to $PAGER would refuse to wrap its lines. [08:37] I guess the gtk ones are all shor... no, there's test-gtk, running onto a second line for the [gtk] [08:38] But as to markh's query, all that we are discussing only applies if you've conceived of the problem as "there GUI commands I am looking for are in a plugin called '[bzr-]gtk' and so I should search down from that" [08:44] bug 220331 (in reference to a mailing list post, not what's going on here) [08:44] Launchpad bug 220331 in bzr "editor paths containing spaces are not parsed correctly" [Medium,In progress] https://launchpad.net/bugs/220331 [08:44] Thank you, ubottu. [08:44] bug 109115 (same) [08:44] Launchpad bug 109115 in bzr "nicer error when unable to commit large files" [Medium,Confirmed] https://launchpad.net/bugs/109115 [08:49] poolie: is your phone on ? [08:52] lifeless: yes, i was on teh phone to amanda [08:52] lifeless: try again? [09:01] Jc2k: http://bzr-playground.gnome.org/gnome/.mirror-log/changes <- the log [09:05] lifeless: how goes guadec? [09:09] it seems 'bzr viz' always shows a visualization of the entire branch - which is different than 'log' [09:20] Well, I didn't say it was the same :) [09:28] * Odd_Bloke --> breakfast [09:36] With bzr, is there any way I can pull a specific commit from another branch, kind of like git cherry-pick? [09:37] git has cherry picking? [09:37] gour: it records a single revid [09:37] steltho: yes you can, bzr merge -r x..y BRANCH [09:38] lifeless: but that's still not like darcs' ? [09:38] gour: not at all [09:38] (due to different design) [09:40] fullermd: you think there is scope to add a 'glog' command which is just a graphical version of 'log'? Or maybe it is considered unnecessary? [09:40] (I'm not asking anyone to do it - just if it makes sense!) [09:41] markh: I think it does [09:41] markh: though for full log it should look like viz :) [09:42] lifeless: by "full log", you mean "log of entire branch"? [09:42] I'm not sure what a log of multiple files should do. Maybe it makes more sense for 'vis' to accept a filename? [09:42] s/a filename/list of filenames/ [09:46] markh: sure; st [09:50] hello markh [10:01] jml, stacking passes all tests [10:02] poolie: rock the cazbah === Tank|Away is now known as Linnk [10:09] and patch is sent [10:09] poolie: woo! [10:09] lifeless: if you could read it that would be great [10:09] there is some more that can be done but at least it passes [10:09] it's in the 'stacking status update' thread [10:09] have a good weekend [10:11] now i should really log off [10:11] night [10:13] anyone know of any good introduction videos for bzr, im trying to sell the development team/management on the idea, videos seems to get watched from start to finish, were as text gets skimmed or not read at all :) [10:16] If there isn't, perhaps we should get a good one produced. That would be fun to be a part of, actually. [10:26] poolie: hi. I'm at the bzr sprint at europython, which is quite cool! [10:26] I wish I could work out how to get a group of talented people to work like dogs for free for a few days ;) [10:32] \leave [10:35] a_c_m: would you be after screencasts, or more presentational videos? [10:35] neobug: Hey, just replied to your email. [10:36] ok, thanks [10:36] neobug: How did you send your changes to the mailing list previously? [10:37] Odd_Bloke: LarstiQ helped me [10:37] I just sent a mail with Mutt [10:37] and attached a bundle [10:38] neobug: OK, you should be able to do exactly the same again, having committed your changes to the same branch. [10:38] markh: hey there [10:38] markh: who is sprinting? [10:40] Wouter was here yesterday, but there are a few new people who have never used or seen bzr too - which is quite amazing really [10:40] A couple of [RFC] mails to the list are from such people [10:40] most excellent [10:41] markh: save'em all ;) [10:41] james_w: dont mind... just something text light, ideally with moving bits and sound ;) [10:42] james_w: i just sent out one of the pdf presentations as a stop gap... but i doubt they would make it past all 50 odd pages [10:42] markh: On a side note, if you could encourage them to use '[MERGE/RFC]' rather than just '[RFC]', that makes not losing them much easier. [10:42] a_c_m: I've been working on some instructional screencasts. We haven't set up hosting for them yet, and there are only a few, but once I've got my current deadline out the way I hope to make some more. [10:44] james_w: sounds good to me, ones on the different workflow situations and how to set them up / use them would be what my guys would be most interested in [10:44] a_c_m: I hadn't got that far yet, but that's the sort of thing that I would like to do. Unfortunately they are not quick to produce. [10:47] Odd_Bloke: that is a convention that is news to me. Wouter was actually mentoring those guys yesterday, but I'll try and make that happen for today. [10:48] I think that none of the patches was really considered ready for merging though (IIRC, one of the new error messages suggested buying more RAM ;) [10:49] markh: which Wouter? [10:49] I suggested adding "you idiot" to the end of the message ;) [10:49] V? [10:49] vH [10:49] umm - not sure :) The dutch one [10:49] you're highlighting me :) [10:49] markh: i'm "the other dutch wouter" [10:49] oh :) [10:49] but I'm at guadec, so it's not me ;) [10:49] um - the one with the Q at the end of his IRC nick [10:49] thogh we do have a bunch of bzr people around here as well [10:49] larstiq that is [10:50] james_w: cool, are you on identi.ca ? [10:50] yeah! [10:50] a_c_m: nope [10:50] james_w: shame [10:50] heh :-) [10:54] uws: larstiq [11:02] beuno: [11:02] Traceback (most recent call last): [11:02] File "/srv/gnome-loggerhead/loggerhead/controllers/changelog_ui.py", line 45, in get_values [11:02] revid, start_revid, filter_file_id, query) [11:02] File "/srv/gnome-loggerhead/loggerhead/util.py", line 407, in locked [11:02] return unbound(self, *args, **kw) [11:02] File "/srv/gnome-loggerhead/loggerhead/history.py", line 458, in get_view [11:02] revid_list = self.get_file_view(start_revid, file_id) [11:02] File "/srv/gnome-loggerhead/loggerhead/util.py", line 407, in locked [11:02] return unbound(self, *args, **kw) [11:03] File "/srv/gnome-loggerhead/loggerhead/history.py", line 423, in get_file_view [11:03] revlist = list(self.get_short_revision_history_by_fileid(file_id)) [11:03] File "/srv/gnome-loggerhead/loggerhead/util.py", line 407, in locked [11:03] return unbound(self, *args, **kw) [11:03] File "/srv/gnome-loggerhead/loggerhead/history.py", line 330, in get_short_revision_history_by_fileid [11:03] w = self._branch.repository.weave_store.get_weave(file_id, self._branch.repository.get_transaction()) [11:03] breaks http://bzr-playground.gnome.org/robsta/gtk-css-engine/changes?start_revid=20&filter_file_id=gtk2.0-20080708104047-cvt44z7pck8smu4n-3 [11:05] ew [11:07] hm [11:07] lifeless, that's using the latest lh-search? [11:07] beuno: I hope so :) - but its in history.py in loggerhead :) [11:08] beuno: its using the latest loggerhead-gnome-theme [11:08] beuno: http://bazaar.launchpad.net/%7Ebeuno/loggerhead/gnome_theme/ [11:09] that file is empty [11:10] I wonder if that's what triggers the traceback [11:10] beuno: using weave_store triggers it [11:10] beuno: its running 1.6b3 bzr [11:11] lifeless, where can I get a branch for that repo? [11:11] http://bzr-playground.gnome.org/robsta/gtk-css-engine [11:12] bbs [11:15] lifeless, it doesn't blow up in trunk [11:15] looking at what may have caused it [11:17] lifeless, pushed a revision that fixes it [11:20]