[00:05] spiv: hi! [00:05] spiv: you back? [00:10] lifeless: yeah, I hope so :) [00:11] With the help of cold & flu tablets. [00:11] ok cool [00:11] I was going to pickup the 'detect ghost inventories' patch [00:12] if you're back, and it was next on your todo, perhaps you'd like to just follow through on it ? [00:21] mwhudson: moin [00:21] mwhudson: any more luck with bzr-git now? [00:22] jelmer: haven't tried with the latest versions yet [00:24] lifeless: sure [00:27] So, um, what's the right branch of Dulwich to use? [00:27] jelmer: judging by the first two minutes, it seems much saner in terms of memory usage === dereine is now known as dereine[OFF] [00:30] morning all [00:30] lifeless: pong [00:31] igc: hi [00:32] igc: you mentioned that filter config has hit a wall; where should I read to read up on that [00:32] lifeless: thanks for your email btw [00:32] anytime [00:33] lifeless: I'll email the list soon with an update [00:33] literally apparently, it was what, 11? :P [00:33] lifeless: see Alexander's latest email for the brief problem [00:34] i.e. using an arbitrary file doesn't allow storage of that file in the tree [00:34] because of various ordering issues w.r.t. tree building and filter application [00:35] e: [MERGE] [BUG 363837] Catch _win32_delete_readonly failure to remove file or directory and try to recove ? [00:35] Launchpad bug 363837 in bzr "diff --using does not give Windows enough time to remove temp files" [Medium,In progress] https://launchpad.net/bugs/363837 [00:37] jelmer: sorry if the mail I just sent about your patch is confusing, but I'm tired and going to bed now [00:52] spiv: still sick today? [00:53] oh i see [00:53] poolie: no (well, not enough to stop me working) [00:54] hi spiv. welcome back [00:54] I wouldn't recommend getting too close to me, though :) [00:54] Between this cold and the vaccinations last week my immune system should be very well exercised for Barcelona... [01:20] jelmer: is there any way of telling how a bzr-git pull is doing by looking at the .bzr directory? [01:20] spiv: could you please eyeball my updated descriptions on https://bugs.edge.launchpad.net/launchpad-code/+bug/354036 and https://bugs.edge.launchpad.net/bzr/+bug/360791 [01:20] Ubuntu bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Undecided,Confirmed] [01:21] spiv: I've tried to make them very approachable for users [01:21] How can I get a list of all revids? [01:22] cat /dev/urandom ? [01:23] more seriously, a little context is needed - do you mean the revisions in a branch, or the contents of a repository, or some concordance of what people have used anywhere.... [01:23] luke-jr: in a branch's mainline history? in a branch's full ancestry? in a repository? [01:23] also do you want it in python, or shell scripting [01:23] spiv: a future revision [01:24] I did a bunch of bzr uncommit ;) [01:24] lifeless: the descriptions look very good, thanks! [01:24] luke-jr: you mean you want to know the revids of the uncommitted revs? [01:24] bzr heads --dead [01:25] will list all the heads [01:25] uhm, log -r revid:ADEADHEAD --show-ids will let you get at the ancestors of the dead head [01:26] * fullermd still wishes log -r..revid:FOO would give a log as if FOO were the head of a branch... [01:26] fullermd: make it happen! [01:26] fullermd: [is there a bug too] [01:26] And "bzr uncommit" in recent releases will display the revid of the revision you are uncommitting [01:26] lifeless: 'bzr heads' doesn't exist..? [01:26] I tried, but my magic wand just sorta looks at me and says 'blert'... [01:26] spiv: it did, long off my scroll history [01:27] Not sure. I don't remember filing one. [01:27] fullermd: you need to pay it more attention [01:27] bzr 1.14rc1 has no 'heads' cmd [01:27] luke-jr: It's in bzrtools [01:29] luke-jr: the revids may be in your bzr.log too [01:30] ty [01:40] jml: when you do a web review, its annoying that you can't see what you are reviewing [01:40] e.g. https://code.edge.launchpad.net/%7Embp/bzr/340352-rename-lock/+merge/4334/+review [01:41] the bug style inline forms are _much_ more convenient [01:41] lifeless: yeah, poolie filed a bug about this. [01:41] ok cool [01:43] I can't see it [01:44] mmm [01:44] * mwhudson still finds the distribution of concerns in progress reporting a little odd [01:44] mmm [01:44] maybe it's not bad actually [01:44] https://bugs.edge.launchpad.net/launchpad-code/+bug/372059 [01:44] Ubuntu bug 372059 in launchpad-code "show the merge diff when proposing a merge" [Undecided,New] [01:45] I haven't had the chance to triage it yet. [01:46] mwhudson: it's not fully baked yet i agree [01:46] jml: thats when proposing a merge [01:46] jml: I'm talking when doing a review [01:46] lifeless: oh ok. [01:46] jml: https://code.edge.launchpad.net/%7Embp/bzr/340352-rename-lock/+merge/4334/+review is an example url [01:46] poolie: concretely right now i wish TextProgressView._format_task was somewhere else :) [01:47] patches welcome :) [01:48] jml: let me know, bug or feature:P [01:48] lifeless: what do you think? [01:48] i guess i need to figure out what i want here [01:49] poolie: i'm just going to blabber requirements for a while, feel free to either ignore or read as you like [01:49] jml: I think it would be better if it was like the bug discussion pages [01:49] this is for git code imports [01:49] we have a monitor process that considers a process stuck if it produces no output for an hour [01:49] lifeless: me too. [01:50] so i'd like to have a progress reporter that prints some kind of progress indication [01:50] i think printing a line on every progress report would get a bit spammy [01:51] so i was thinking of printing a progress report on _progress_updated if nothing had been printed for, say 10 minutes [01:52] i guess i'll subclass clifactory [01:53] mwhudson: don't you have this already [01:53] mwhudson: I *sounds* like code you wrote in the past. [01:54] lifeless: it sounds a bit like something ddaa wrote [01:54] i think [01:56] mwhudson: I'm pretty sure you already have a UI factory in your code base that does this [01:56] lifeless: i'm pretty sure we do not, any more [01:56] oh, ok. [01:56] 'bzr revert -r wheredidthatcodego' [01:58] bug 373038 [01:58] Launchpad bug 373038 in launchpad-code "inline editing for reviews please" [Undecided,New] https://launchpad.net/bugs/373038 [01:59] thanks. [02:00] lifeless: yes, I know [02:00] thumper: ? [02:00] lifeless: I've been planning to work on it with beuno but both of us have long lists :( [02:00] lifeless: bug 373038 [02:00] Launchpad bug 373038 in launchpad-code "inline editing for reviews please" [Undecided,New] https://launchpad.net/bugs/373038 [02:00] thumper: thats a new bug I just filed as the result of the discussion with jml [02:00] lifeless: yes, but we've known about it for ages :) [02:00] just bugless [02:01] thumper: I'm honouring a promise I made to jml to be active about documenting my experiences with code [02:01] that's good [02:01] thanks [02:01] I do appreciate it [02:01] I just want you to know that we know about it and have been thinking about it [02:01] ok, cool. [02:07] lifeless: btw that pqm-config fix for the LANG (/home/pqm/bin/dchroot-run LANG=en_GB.utf8 make check) worked nicely for vila last night. Shall we roll to all the bzr config entries, or revert? [02:07] spm: bzr.dev and new releases only [02:08] spm: e.g. 'no' [02:08] lifeless: new releases being 1.14+ ? [02:08] the state of existing branches is unknown [02:08] spm: 1.15 [02:08] oh yes of course. will do. [02:08] thanks [02:09] spiv: how goes it? [02:10] spiv: I ask because AIUI you had a patch, but I don't recall seeing it up for review; I'm keen to put these bugs behind us and want to help :) [02:10] lifeless: just caught up on the worst of my mail and administrivia backlog [02:12] lifeless: the work-in-progress is lp:~spiv/bzr/all-referenced-texts-check [02:12] lifeless: I'm currently working on adding more test coverage [02:12] ok [02:12] the conceptual approach makes sense, and I browsed the patch yeseterday [02:13] lifeless: cool, that's good to know :) [02:13] mwhudson: not really [02:14] The code feels overly complex, but I think that's hard to avoid. [02:14] jelmer: ok [02:14] We don't have particularly convenient APIs for working with the dependencies that are implicit in our graphs. [02:15] mwhudson: it should give you a progress bar though [02:15] jelmer: yeah, if you install a ui factory at all :) [03:03] where does the ui_factory get set when you run bzr from the command line? [03:04] oh, main() [03:05] mwhudson: with the small exception of cmd_serve which unconditionally uses SilentUIFactory [03:06] spiv: ta [03:08] oh wow, i can actually pull bzr.dev over http now [03:09] i wonder if my isp has fixed their proxy at last... [03:11] jam/igc: any ETA on bbc stacking? [03:14] thumper: no idea sorry - I'm not working on that [03:15] igc: hmm, lifeless just said it was with you and jam [03:17] thumper: igc and jam are working on the bbc format and related things, spiv and I are working on networking - thats the split across the two major goals set for the bazaar team [03:19] ok [03:20] thumper: it doesn't mean that everything we do is strictly in those buckets, nor that everything that needs to be done to move bbc from beta to release is actively being coded right now :) [03:26] mwhudson: so you're running bzr in a subprocess with a pipe on stderr/stdout? [03:26] and you just want it to mumble stuff, not draw a progress bar as such? [03:26] poolie: yes [03:26] right [03:32] hmm [03:32] can i use a plugin to override the default ui factory? [03:33] mwhudson: yes [03:33] mwhudson: it may be a little esoteric; I will put one together for you after I finish a little roadmap cleanup [03:34] lifeless: don't worry about it, i'll just hack for now [03:34] poolie: http://bazaar-vcs.org/Roadmap/BrisbaneCore seems to completely miss that bbc can't stack right now [03:35] thumper: I'm editing it at the moment [03:40] thumper: done [03:41] mwhudson: ok [03:42] mwhudson: hook into Command.hooks 'extend_command' [03:42] mwhudson: bzr help hooks has the docs for this [03:42] mwhudson: that will get called before any command is executed, and after the ui factory is set [03:43] lifeless: ta [03:43] its a little hacky, and you may be invoked multiple times etc [03:43] but it will work [03:47] lifeless: so will editing main() which is what i'm doing now >:) [03:48] mwhudson: well you asked about a plugin to do it [03:48] yeah, sorry [03:48] its about 4 lines in a plugin, including imports [03:48] and how many lines to install ? [03:48] SamB: thats the lot [03:49] I meant, how many lines do you need to type in the shell ;-P [03:49] SamB: oh heh [03:55] * spiv -> lunch [03:58] spiv: I maintain that you people are CRAZY! [04:01] * igc lunch [04:01] igc: yes, you too! [04:01] SamB: :-) [04:01] * SamB <- dessert [04:01] * fullermd isn't edible. [04:02] (the dessert goes into me ;-) === lamont` is now known as lamont [04:40] igc, i'm trying to merge the doctools patch you mentioned yesterday [04:40] it has small failures on python2.4 [04:41] poolie: did jam suggest some workarounds in the review thread? It's a while ago now but I recall something like that [04:41] he had a small fix but i think not for that [04:44] its the win32 installer it fixes I think === samurai is now known as samiam [04:54] spiv: http://bazaar-vcs.org/Roadmap/SmartServer I've tweaked; let me know if I used too big a cleaver [04:57] thanks for all the roadmap updates! [04:58] poolie: as we were discussing, there is a balance here [05:00] poolie: this is the ui factory i've come up with so far, if you're curious: http://pastebin.ubuntu.com/165831/ [05:02] mwhudson: seems more complex than desirable [05:02] mwhudson: but if it works great [05:03] lifeless: it's not _just_ for progress monitoring, it's also visible in the ui [05:03] so i put a bit of effort into making it useful too [05:03] mwhudson: sure; by complex I mean its a shame you can't use existing code more [05:03] lifeless: ah right\ [05:03] yes [05:04] I mean, ideally you'd just override the render call and instead of doing [======] do 'status change, x->y', and also change the clamp threshold from 1/10th of a second to 30 seconds [05:04] or wahtever [05:06] actually thats a good, serious question [05:06] why didn't you do that? [05:12] hmm, i guess that would have been somewhat easier [05:12] would need to copy-paste-change some methods (and presumably submit changes to bazaar that would make that less relevant) [05:16] naturally [05:16] otoh it would be more obvious and likely easier to maintain [05:23] mwhudson: i like the time_source thing [05:23] poolie: deterministic tests ftw [05:24] i'd like to merge something like this into bzr [05:24] if you need to provide the stack stuff here that's a bug [05:28] poolie: i think as lifeless said, i'm somewhat operating at the wrong level [05:28] poolie: but operating at the right level nicely requires a bzr patch [05:28] poolie: i'll try to write that patch later [05:29] ok [05:29] i also want to keep improving this [06:23] Are there instructions anywhere for actually creating the repository layouts mentioned in http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#advanced-shared-repository-layouts [06:29] eelik: there's no special commands needed beyond the "bzr init-repo" to create the shared repository [06:30] but how about "container directories"? Are they versioned somehow? [06:31] eelik: no, just create an ordinary directory on your filesystem. [06:31] then I'm out of luck, because sourceforge doesn't make it possible [06:32] basically, it allows only using bzr command [06:33] eelik: you can just use bzr commands [06:33] eelik: bzr init-repo URL [06:33] yes, that's the easy one [06:33] it has to be done in a special ssh shell environment [06:33] eelik: and then bzr push URL/foo to push a branch up [06:34] poolie: http://pastebin.ubuntu.com/165869/ <- version that uses more from bzrlib [06:34] poolie: it's a bit ugly, but a bzrlib patch will sort that out [06:34] that I can do also, but what if I want to create a branch in a nonversioned subdirectory or subsubdirectory [06:35] does bzr create them automatically [06:35] eelik: bzr push URL/foo/bar --create-prefix [06:35] (well, I'm new to bzr as you can see) [06:35] ok, I have to try that [06:36] But I managed already to create a nonversioned directory into the sf server and it can't be removed [06:37] eelik: bzr push --use-existing-dir URL if you want it to be a branch [06:37] their system may be unmature [06:37] eelik: or if you wanted it to be a repository, bzr init-repo URL [06:38] ok, I have been reading the docs for couple of days but it's just too much :) [06:38] eelik: could be :) [06:38] sf have only recently added sf support, its true [06:39] and they don't offer any site specific documentation except for the very scarce intro [06:40] but thanks, I keep learning === dereine[OFF] is now known as dereine === dereine is now known as dereine[OFF] [07:19] I have a security question. [07:20] I notice that bzr has an ssh key [07:21] if someone gets a hold of my ssh id_rsa.pub key from launchpad does that mean they can ssh into my computer? [07:21] no [07:21] Ok. [07:21] ssh keys work in two parts [07:21] the public part is like the lock [07:21] hi all [07:21] the private part, the bit you keep on your computer, is the actual key [07:21] I realized the error of my question...after I asked it. [07:22] the public key can be used to give you permission to login to machines, thats all [07:22] hi vila [07:25] I guess it didn't hurt to ask. I'm pretty paranoid about letting people have access to my machine. [07:28] thats healthy [07:30] jelmer: ping [07:49] lifeless: +1 to your updates and thanks for writing it [07:49] updates to the advice [07:57] the-erm: I used to have an 'anonymous' account on mine, without a password [07:57] curiously, the botnets never noticed it [07:58] poolie: I've finished for the day; feel free to let the announcement go free if you want :) [07:58] poolie: otherwise I'll do it tomorrow [07:58] lifeless: announcement? ☺ [07:58] luke-jr: see the list, 'draft announcement..' [08:05] lifeless: let it go from teh moderation queue? [08:05] poolie: I haven't mailed it anywhere [08:05] ok let it go by sending it? [08:05] sure [08:14] * jml really really wants an SQL-like frontend to Bazaar [08:14] (except not enough to actually design and build one) [08:18] jml: select from revision where author like ... ? [08:18] yeah [08:18] or, a thing I wanted to refute a particular accusation [08:19] select from revision where message.startswith('release-critical') and author in (...) [08:19] except because of PQM you need the author of the second-to-left parent of the mainline revision. [08:19] which is a pita [08:20] also counts and averages and better time awareness [08:21] jml: bzr log -m '\brelease\b' :P [08:21] also bzr-search aims at this space, I'd be delighted to have a readline interface to it [08:21] lifeless: that log command is obviously not good enough [08:21] lifeless: because it doesn't restrict the set of authors. [08:21] jml: yes, thats true [08:22] igc and I and others want a query language we can make standard and reuse [08:22] ETIME [08:22] right [08:26] jml: are there ppa package branches? [08:26] [I have a piece of software; I'm going to upload it to a ppa; it would be nice if the branch I upload was clearly packaging] [08:28] lifeless: there aren't ppa package branches, per se. [08:28] lifeless: you can push to ~lifeless/ubuntu/karmic/software/branch though [08:29] or jaunty presumably? [08:29] or jaunty [08:29] or lenny [08:29] now, if the package hasn't been in ubuntu yet, will that fail? [08:29] (or whatever they call it) [08:29] lifeless: very good question. my guess is "yes" [08:29] lifeless: but I haven't tried. [08:30] let me know if I'm wrong :) [08:34] software is 'package' ? [08:37] jml: apparently subunit has been uploaded before, or the answer is 'no' [09:03] Hmm, bzr just isn't good at whacking-great-enormous files. === serg_ is now known as serg [09:15] Is there any way that bzr support for large sized files could improve? I know it's not the core use case, but a lot of people check large files into e.g. SVN, which copes well with them, and this can make interoperating with those repositories with bzr something of a trial. [09:16] awilkins: it will improve when jam lands a patch he has, but only by a factor of 3 or so; files that are large fractions of your memory require more radical changes [09:16] What kind of fraction? [09:17] My problem here is I think this repo has a single revision with about 600MB of data in it. [09:17] It's sitting at around 2.1GB in top and swapping around every so often.. :-) [09:18] to merge a file wit 600MB of content we need 1.8GB in memory, minimum. [09:18] (three copies) [09:19] Dammit, the server just dropped [09:19] * awilkins bites the edge of his shield [09:19] I think it's split into several 150MB files [09:20] I'll check it out the traditional way and see [09:21] Would it be a valid approach to write a class that merges using disk as an intermediary, and "mutate" the memory based operation into a disk based operation if it was consuming a lot of memory? [09:22] or just give up and conflict out [09:22] each 150MB file should be getting processed separately [09:22] 600MB files probably aren't text [09:23] awilkins: yes, that is a valid approach [with costs, but yadayadayada]. [09:23] Ah, ok, even better(ish) it's more like 25-40MB files [09:23] They are text files, they are just big ones [09:23] They're CSV tables [09:23] awilkins: ok, if *that* is giving headaches its not the 'big file' bug [09:23] awilkins: what bzr version? [09:23] This is bzr 1.14.1 plus whatever bzr-svn it ships with [09:25] ok [09:25] please file a bug [09:25] with plenty of data about reproducing if possible [09:25] It's probably bzr-svn [09:25] it could be bzr-svn [09:25] if you can simulate (e.g. fast-export fast-import, reproduce) it without bzr svn that would be good; if you can't it probably is bzr-svn :P [09:25] I suspect that most of this data was committed in a single revision in the source SVN repo [09:27] night all [09:34] Looks like 7 folder containing 150MB apiece of text files (60/60/25 MB) were committed in the same revision [09:34] Which is the revision it was choking on [09:37] awilkins: were you doing a pull from svn? [09:45] lifeless: Yes [09:45] lifeless: I just added a comment to the bzr-svn "Memory problems" bug [09:46] I suspect it's trying to process an entire revision in memory in one step [09:47] * igc dinner [09:47] awilkins: that makes sense to me [09:49] I don't think svn even breaks a sweat - it doesn't even consume enough memory to hold one of the files as far as I can see [09:49] But it doesn't have to do any "transcoding" or however you want to term it [09:52] bzr itself won't either [09:52] its likely a interface mismatch [10:05] is there a way to change the parent and push information for a branch without actually pushing/pulling? [10:05] I changed servers, and would like to point the projects at the right place in a one-off batch job [10:05] hack .bzr/branch/branch.conf [10:06] that sounds like it's inviting breakage [10:06] how so? [10:06] it's just an ini file [10:08] so no breakage? [10:09] a little bit of sed should be fine [10:09] or you could use the python API to set them [10:11] sed sounds easier for a one-off project like this. :) [10:11] * Solarion is leery of poking around in .bzr [10:14] thanks! === jelmer_ is now known as Guest40441 === Guest40441 is now known as jelmer__ [13:35] Any work on when bzr-gtk will be updated in the ppa? [13:35] *word === dahoste|away is now known as dahoste [14:03] vadi2: what's broken about it? [14:04] if I upgrade my bzr to ppa version, bzr-gtk stops working - I was told it needs an update in the ppa. [14:04] what bzr version does the ppa have? [14:04] I think 14 something and bzr-gtk is 13 [14:05] 1.14.1 for bzr in the ppa [14:05] vadi2: that should be sufficient, bzr 1.14.1 didn't change the API since bzr 1.13 [14:05] "0.95.0+bzr629-1ubuntu1" for my bzr-gtk package... but it complains when I install the bzr ppa [14:06] well, I tried it before, let me try again [14:09] magic! works now :) [14:09] here's what I had before for some reason: [14:09] (08:36:26 AM) vadi2: Hi. I upgraded my bzr from the ubuntu ppa, and all of the g* commands broke - it says gtk+ wants an api version of 1, 13, 0 while only 1, 14, 0 is available. But there are no upgrades available. [14:09] vadi2: you had bzr 1.14.0 which incorrectly claimed it broke compatibility with bzr 1.13 [14:10] ohh [14:36] jelmer: I'm a check committer now :P === dereine[OFF] is now known as dereine [15:28] I'm getting a run() got an unexpected keyword argument 'location' when I type in bzr.exe xmllog --limit=200 build.xml. I'm using xmloutput 0.8.3 and Bazaar (bzr) 1.14. Does anyone know what the cause is & how to fix it? [15:31] verterok, ^ [15:32] Jemsquash: do you have the traceback? [15:32] beuno: hi, thanks! [15:32] verterok, hi :) [15:33] 0.233 Traceback (most recent call last): [15:33] File "C:/tools/bazaar/plugins\xmloutput\xml_errors.py", line 61, in xml_error_handling [15:33] File "C:/tools/bazaar/plugins\xmloutput\__init__.py", line 356, in run [15:33] File "bzrlib\commands.pyo", line 937, in ignore_pipe [15:33] TypeError: run() got an unexpected keyword argument 'location' [15:35] Jemsquash: it shouldl be fixed in trunk (vila's magic patches :) [15:35] *should [15:35] I'll do a new point release tonight [15:36] Ok Thanks. Do I pick it up from http://verterok.com.ar/bzr-eclipse/update-site/ ? [15:36] Jemsquash: sorry, in bzr-xmloutput trunk :) [15:37] ah ok. [15:37] thanks [15:37] Jemsquash: also there is a new build of bzr-eclipse with the new and shiny send dialog (courtesy of Javier) [15:38] Jemsquash: btw, I'm working on bundling xmloutput in bzr-eclipse builds, so the only external dependecy is bzr itself ;) [15:38] hopefully I'll have it ready in a few days [15:42] send looks good. First time I tried it was from the context of a file & it told me 'send is not enabled in this context'. I was a bit confused at first until I thought about what it was about. It worked from the project level. [15:44] great! [15:45] Jemsquash: yeah, that is a generic context handling error, it might be good that some commands override the default message [15:46] yeah. Could it be disabled for that context? [15:48] Am I misunderstanding something? I see that the project menu has a lot more enabled than the file context menu. Is there a reason the send menu item is here? [15:49] Jemsquash: sure, check the performance preference page, there is a checkbox: action availability [15:49] ah ok. [15:50] Jemsquash: but you'r right, it shouldn't be in the file/folder menu, and that's just a config issue in the plugin xml [15:50] Jemsquash: could you file a bug about it? [15:50] Can do if you want. What's the performance penalty? [15:52] I'm assuming there is a performance penalty since the preference is in the performance preference panel. [15:55] Jemsquash: the filtering by file/folder/project is "free", the performance issue is related to bzr specific checks, like: only enable Switch in a checkou, or unbind in a boudn branch, etc [15:58] Does that mean you want me to raise a bug that the default for that value should be on? Or change the message so that it mentions the preference or just the fact that menus should be disabled based on context? [15:58]