[00:08] poolie, ping? [00:10] emmajane: hi [00:10] nice to see you [00:10] poolie, and you as well. :) [00:10] are you in the UK and up really late? [00:10] have you got a few minutse? [00:11] sure [00:11] Indeed. It's gone midnight here. [00:11] just give me 2m here first though.. biab [00:11] np [00:25] morning [00:41] I need a better progress info for bzr branch [00:41] Event if I need to develop a plugin or use the bzr API [00:41] bzr checkout -v is not enough, it's sens stalled for long time [00:42] Anyone knows if it's possible? [00:57] spiv, hi, i have a call with francis in a bit [00:57] KeBugCheckEx: is this as a user of the command line or from your own program (ie at the api level) [00:59] poolie: I'll do it at the api level [00:59] KeBugCheckEx: so there are two layers: events fired from the core code to the uifactory [00:59] you can hook into that if you're eg using bzrlib in a gui or daemon === zirpu2 is now known as zirpu [01:00] and then if the core code is not sending enough progress events, i guess file a ubg [01:00] try using the breaking debugger (Ctrl-\ or Ctrl-Break) to see where it's spending time and not repotring it [01:00] for curiousity, what is the app you're doing this from, and on what platform? [01:00] poolie: I downloaded Bzr Explorer for Windows, it shows the same progress the bzr command does [01:01] lots of time in "Fetching revisions:Inserting stream" [01:02] nice nick btw [01:02] I'm testing on Windows XP and Ubuntu Server, bzr 1.17 [01:02] this is over the network? [01:02] testing with bzr branch -v http://bazaar-vcs.org/bzr/bzr.dev bzr.dev [01:04] KeBugCheckEx: on the command line you should get a network progress indicator? [01:04] Maybe it's to early to ask questions since I didn't study the api enough, but I didn't find any tool with a decent progress report [01:04] it may be that bzr explorer doesn't expose that [01:04] It shows the progress, but looks like it doesn't know how much is left to be downloaded [01:05] like this: http://www.ubuntu-pics.de/bild/24166/screenshot_20090909_09_37_17_rjPOI4.png [01:05] blah [01:05] not that [01:05] this: [#########| ] 2KB 0KB/s | Fetching revisions:Inserting stream [01:05] showing the network rate [01:05] bzr and bzr-explorer just show the bytes dowloaded but not how much there's left [01:06] the tool I'll develop will need to show how much MBs is left [01:06] ok [01:06] what tool is that? [01:06] I'll create a tool for non technical people based on bzr [01:07] open source of course :0( [01:07] :-) [01:07] but the repositories will be big [01:07] maybe gigas [01:07] ok [01:07] it's very important to show the user how much time is left [01:08] our current setup is to have the server stream out data as it works through history [01:08] so it doesn't necessarily know up front how much data it will send [01:08] however, we could probably give at least some estimate [01:08] of how many more revisions need to be copied [01:08] if you look at eg 'bzr check' it does i think show how many objects will be checked [01:08] so you get proportional overall progress [01:09] let me try the checkout... [01:09] if you hook in at that level, when the core is updated, your ui will be told [01:12] bzr checkout -v --lightweight looks better [01:12] Build phase:Adding file contents 533/1105 [01:13] I'm assuming 1105 is the number of files to download [01:13] can I copy a branch from a machine to another? copy the files? [01:14] creating a branch in /tmp, zipping and then sending it via http is a viable alternative for me [01:31] KeBugCheckEx: yes, that will work [01:31] 1105 is the number of files in the working copy [01:31] you should get that output from any command that creates a tree [01:31] spiv, hello? [01:32] So, if I ensure nobody is changing the branch I can copy the branch files, right? [01:32] right [01:32] Event form Linux to Windows? [01:32] yes [01:32] *Even* [01:33] nice! [01:33] make sure it's a standalone branch, ie includes the repository data too [01:33] If someout changes the branch after this I only need to merge [01:34] someone [01:34] ok, I thing I can start something with this info. Thanks! [01:35] god, I better go sleep or take some typing lessons... [01:52] poolie: good morning. [02:04] hi spiv [02:04] spiv, did your patch land? [02:06] poolie: no, a surprising number of tests try to commit invalid revisions. [02:06] I just fixed a test in per_workingtree, for example, which I wasn't expecting to be affected. [02:08] Mainly it's been that a lot of tests that create revisions directly, without creating the texts in those revisions. [02:08] And all 2a revisions have a root. [02:09] Ok, looks like per_workingtree is now passing. [02:10] Also, we have lots of tests that do: "start_write_group(); try: ...; except: abort_write_group(); else: commit_write_group()" [02:10] :/ [02:10] But actually when commit_write_group fails we still need to do abort_write_group(), otherwise the inevitable unlock will raise an error from the cleanups and hide the real failure. [02:10] what's the problem with that one? [02:11] So more correct is to put the commit_write_group inside the try, I think. [02:11] But I wonder if commit_write_group shouldn't actually be "commit_or_else_abort_write_group". [02:12] spiv: commit can lead to suspend, no? [02:12] spiv: not that I'm here today. [02:12] * lifeless goes :) [02:13] Because I don't think we ever try to recover if commit_write_group fails, so the current API is a bit suboptimal. [02:13] lifeless: actually, no [02:13] lifeless: we detect that case before trying commit [02:14] But anyway by far the most common case is "I want to either commit, or fail", but the current API makes that tedious. [02:15] spiv: I'd favour a helper rather than a larger contract for commit [02:16] Sure, I agree it's useful to have the smaller operation available. [02:16] We're just not doing a good job of catering to the common case, atm. [02:17] yeah, copy & pasting this seems bad [02:17] on phone [04:02] * igc lunch [04:35] poolie: my patch landed. [04:56] mwhudson: I'm sort of around, though not for long [04:57] jam: no worries [04:57] jam: i commented on a bzr/launchpad-code bug, it would be nice if you replied at some point [05:02] mwhudson: response sent [05:08] spiv, woo, way to go [05:10] spiv, did you get another review? it sounded like there were nontrivial changes there [05:12] jam: thanks [05:29] spiv: the fix for https://bugs.edge.launchpad.net/launchpad-code/+bug/424136 should be on staging by now, want to test it? [05:29] Ubuntu bug 424136 in launchpad-code "Cannot upgrade stacked branches from 1.9 to 2a on Launchpad" [High,Fix committed] [05:54] mwhudson: hmm, it should be straightforward to test I guess. [05:54] make a 1.9 trunk branch; make a 1.9 branch stacked on trunk; upgrade trunk to 2a; upgrade stacked to 2a. [06:12] igc, it's sphinx 0.6 you need? [06:28] mwhudson: hmm [06:29] mwhudson: when I try to upgrade my test trunk on staging I get bzr: ERROR: bzrlib.errors.ErrorFromSmartServer: Error received from smart server: ('error', 'mismatched lock context and write group. None, ') [06:29] mwhudson: oh, actually, nevermind [06:29] ! [06:30] That's probably just because I'm trying to push from a 1.9 local branch to a 2a remote, but the server is too old to support that sanely. [06:30] Oh, hmm, 1.18rc1 [06:30] Oh, right, but it doesn't support the new insert_stream verb, and yeah. [06:31] Known issue, I think. [06:32] mwhudson: (p.s. please upgrade lp to 2.0rc2 ;) [06:36] tests fail currently [06:40] * spiv waits for https://code.staging.launchpad.net/~spiv/+junk/test-stacked to find out if 424136 is fixed. [06:42] mwhudson: looks good, thanks! [06:43] spiv: yay [06:46] poolie: yes [06:47] igc, that's only in karmic [06:47] that kind of worries me [06:47] dependencies are a pain in the butt [06:47] despite all the work that's gone into modularity [06:48] poolie: the best result comes from sphinx 0.6 [06:48] poolie: I suspect it still works on earlier versions but I'd need to test [06:48] oh ok [06:49] poolie: it shouldn't be hard for us to support earlier sphinx versions [06:49] poolie: but we won't get the blue theming for example pre 0.6 IIUIC [06:49] i'm just worried about adding it at all, given the kerfuffle with putting it on orcadas [06:50] poolie: well I felt our *default* docs ought to look the best they can - see http://sphinx.pocoo.org/theming.html [06:51] poolie: less pretty colours in the docs for a given distro concern me much less, of course [06:51] by default, I meant our online ones [06:52] essentially i'm not feeling this is a good risk/reward tradeoff to land at this time [06:53] :-( [06:53] what do you think? [06:53] well, I'm not objective it [06:53] to me the main thing is to field it on the public site, and we can do that without putting it in the 2.0 tarball [06:54] i don't want to frustrate you, but i also don't want packaging to be held up [06:54] so [06:54] I've put a lot of energy into getting good pdf and chm docs ready for the win and os x installers [06:54] hm [06:54] they are really popular [06:54] i guess if this doesn't go in, we won't get chm etc? [06:54] right [06:55] or we won't get it split out by language, so it looks broken? [06:55] or just not at all? [06:55] and searching in html will suck as well [06:56] without this patch, we have no chm at all and no/very-little pdf at all [06:56] poolie: so the blocker is dependency on sphinx 0.6 [06:57] if it built with sphinx 0.4 or 0.5, that would be ok? [06:57] how about if i try this branch on jaunty [06:57] that will give us some data [06:57] sounds good [06:57] so sphinx is reasonably straightforward to install on windows? [06:57] and os x? [06:57] I'm on jaunty as well but will sphinx installed via easy-install [06:58] poolie: easy to install on Windows - I did that to build the chm's [06:58] poolie: on Windows, install python, install east_install via an installer and then use easy_install to grab sphinx [07:00] spiv, tell me about https://code.edge.launchpad.net/~spiv/bzr/set-tags-bytes-bug-2.0/+merge/10778 [07:00] it seems like that should land to 2.0? [07:01] did it bounce? [07:01] poolie: hmm! [07:02] also, do you have an opinion about changing to sphinx for documentation generation for 2.0? [07:03] I'm also wary of making life harder for packagers just before 2.0 [07:03] But I don't really know how much of a problem sphinx would be for packagers. [07:06] hi all [07:06] * bialix waves at vila [07:07] poolie: I don't know any reason why that set-tags-bytes-bug-2.0 branch hasn't merged yet. [07:07] hmm, regarding docs, it sounds a lot like we want to split the docs *out* of the bzr package like we do for installers, [07:07] * vila waves back [07:07] I've just merged in latest lp:bzr/2.0 to make sure the NEWS entry is in the right spot. [07:07] Oh, perhaps that's why, the 2a transition. [07:08] * spiv pushes to a new lp branch to workaround 424136 [07:10] hmm, still regarding docs, without looking at the code, ISTM that there should a basic way to produce the html docs from the source package, then, any installer branch can add its own way of generating specially targeted docs, chm, pdf, shiny web site, etc [07:10] that way we don't add dependencies on the source package. [07:11] poolie: testing on jaunty is hardly relevant, try, say, OSX, Fedora and FreeBSD. *Then* you'll get a batter taste of the dependency issue :-D [07:11] poolie: lp:~spiv/bzr/set-tags-bytes-bug-2.0-again is up-to-date, and not broken by the 1.9->2a transition. [07:12] poolie: I'm happy to fire that at PQM unless you'd rather have PQM to yourself for making a release? [07:12] Did I say jaunty is hardy relevant ? I should have, that's the current LTS [07:17] spiv, yes please, send it [07:18] poolie: ok [07:26] vila, you don't need to convince me, i'm the one that has doubts about it [07:26] :) [07:27] * fullermd waits for vila to question how well the docs show up in Mosaic :p [07:31] vila, see pm [07:55] easy_install fail - error: Can't download http://launchpad.net/bzr/2.0/2.0rc1/+download/bzr-2.0rc1.tar.gz: 404 Not Found [07:59] rockstar: 2.0rc1 had critical bug inside and was withdrawn [08:19] poolie: call? [08:20] fullermd: the interesting question, IMHO, is: can we still setup, on today's hardware, an OS where we can install Mosaic ? :-D [08:21] *Still* discussing Mosaic? [08:22] Lo-lan-do: welcome to VCS channel where you can have branched discussions that last forever ! [08:22] :-) [08:24] igc, hi [08:24] sure, call [08:32] poolie: the _set_tags_bytes fix landed, btw. [08:32] yay [08:32] First time, unlike the last patch :) [08:33] bug #424136 [08:33] Launchpad bug 424136 in launchpad-code "Cannot upgrade stacked branches from 1.9 to 2a on Launchpad" [High,Fix committed] https://launchpad.net/bugs/424136 [08:36] hmm, spiv, can you tell me more about that bug ? I successfully upgraded a couple of branches by doing: 'bzr upgrade bzr+ssh://lpnet' ignore the error, 'bzr reconfigure --stacked-on bzr+ssh://lp,net' pesting because I couldn't use lp url in the later, but otherwise, I got usable branches... I didn't check the public ones though [08:40] vila: it's the public ones that are the problem [08:40] vila: also, look at the branch pages for the branches you've upgraded [08:41] vila: oh, and beware the confounding bug that if you don't change the tip revision, lp won't try update the mirror AFAICT, even if the format has changed. [08:42] right, I upgraded branch to push, so there ;) [08:43] vila: for an example of an affected branch, see https://code.edge.launchpad.net/~spiv/bzr/insert-stream-check-chk-root [08:43] vila: https://code.edge.launchpad.net/~vila/bzr/test-isolation appears to be a victim of the same bug, for instance [08:47] spiv: right, I think that's where the 'bzr reconfigure --stacked-on' workaround help [08:47] spiv: do you mind if I try there or do you want to keep that as evidence ? [08:47] vila: no, go ahead. [08:48] vila: I don't care much, as mwhudson has fixed the bug anyway (although it's only rolled out on staging so far) [08:48] spiv: ok, thanks for the feeback ! [08:51] What would I have to do to info.py in bzr-git to make it work with bzr 2.0-rc1? [09:23] poolie: still here? [09:24] hmmm, every new repo/branch format changed the way how locking works [09:25] every time we have to accommodate qbzr internals [09:25] does 2a format is radically different from 1.9 re locking? [09:26] bialix: I don't think the design changed, but the usage may raise lock errors at different places/times... [09:27] * igc dinner [09:27] ...if not used correctly (bzr itself had bugs there) [09:27] Bug 426688 [09:27] Launchpad bug 426688 in qbzr "ObjectNotLocked opening diff from annotate on 2a branch." [Critical,Confirmed] https://launchpad.net/bugs/426688 [09:27] vila: ^ [09:27] exactly [09:27] bialix: it's not very different with regard to locking [09:28] perhaps there should be some guidelines for bzrlib users [09:28] I don't understand why it worked fine before and now blow up [09:28] i wonder if this relates to john's fix to fix shelve or something similar [09:28] bialix: sometimes locks were taken abusively and are not anymore, that leads to bugs like above [09:29] shelev fix is lifeless work [09:29] my mistake [09:29] poolie, bialix: It may very well be related to lifeless fix [09:29] bzr 1.17 [09:29] vila, poolie: ^ [09:29] it's not related [09:29] to lifelees fix [09:30] ok, still, it certainly mean you need to take a read lock where it was taken by bzrlib before (for wrong reasons AIUI) [09:30] i wish people would put useful reprs on [09:31] does locking a wt implicitly lock the branch and repo? [09:32] my question is more generic [09:34] 'why it worked fine before and now blow up' ? [09:34] sorry, what's the question? [09:34] That's what bugs are about generally... [09:34] bugs that appear to make things work being the worse kind ! [09:37] vila :-) :-) nice mail [09:37] poolie: thanks :) [09:47] vila: no, why it blows up every time new format is appears [09:49] bialix: same answer: new format, new bugs, now, giving the backtrace, it starts with a call to id2path() which is an important change in 2a (inventories), bugs there are not that surprising [09:50] heh [09:51] * bialix not planned to switch to new format because of all this stuff [09:51] it's a bit surprising that it ends up in a groupcompress index though [09:51] mm [09:51] i'd say this is a latent bug in either qbzr or elsewhere though [09:51] * bialix thinks 1.18.1 is the right thing to have as latest stable pre-2a default format [09:51] that it was getting away with it before [09:51] bialix: that's still a bug in qbzr IMHO [09:51] vila: yes [09:53] I'm really hope 1.18 can be a long term supported pre-2a release as poolie want for post 2a development [09:53] there is too much dependencies between various tools [09:53] bialix: how about if we add an option to 2.0 to set the default format [09:53] and then support 2.0? [09:53] maybe other people can jump right into 2a -- I can't [09:53] bialix: even for new projects ? [09:54] so when jam wrote he don't think 1.18.1 make sense -- it hurts [09:54] that's probably the last thing i should do today [09:54] vila: I don't have completelly new projects at work [09:54] I don't follow your reasoning, 2a becomes the new default format, but previous formats are still supported... [09:54] 2a is default when you start working [09:55] nobody forces you to *upgrade* [09:55] bzr init-repo will create repo in 2a, right? [09:55] this will be implicit upgrade [09:55] and then I can't push to my central repo [09:55] yes, you do that frequently ? [09:55] because of incompatible rich-roots, pfffs! [09:55] yes, I'm do new local shared repos frequently [09:56] for each customer we support, when new features need to be implemented [09:56] you can swallow the incompatible rich-root by upgrading to 1.9-rich-root or 1.14-rich-root [09:56] 1.9-rich-root is slower than pack-0.92, you know? [09:57] but 1.14 should be faster no > [09:57] but 1.14 should be faster no ? [09:57] 1.14 is base don 1.9, no? [09:57] 1.14 is just new wt format? [09:57] AIUI it has the faster indexes [09:57] so [09:58] if we made it read /etc/bazaar.conf [09:58] and there had default_format = 1.9 [09:58] then you'd get the same behaviour but from the different code base [09:58] or rather the same codebase [09:58] if you will allow 0.92 as well -- then great [09:58] 0.92 *is* still supported [09:59] I mean allow in bazaar.conf [09:59] sure [09:59] it's called --pack-0.92, ha, right, [09:59] bialix: want to choose a name for this release? :) [10:00] Nein-Nein-Nein :) [10:00] lol [10:00] last from Mogikan? [10:02] that's the name? [10:02] it's a place? [10:02] wait a sec [10:03] The Last of the Mohicans [10:03] James Fenimore Cooper [10:03] because it's the last post 2.0? [10:04] something like that [10:04] i wonder if Disney will trouble us? [10:04] it makes sense for those who read/saw the movie [10:04] I feel the joke [10:04] never mind me, I'm thinking in Russian [10:05] it's famous quote in our culture [10:06] hm [10:07] i think there is a cultural difference [10:07] how about if i use the way you originally spelled it? [10:07] lol [10:08] poolie: I realy had to shut up [10:08] anyhow, i want to get it out tonight [10:08] vila's variant is funny [10:08] oh, it is too [10:08] I hope spiv landed that patch for tags [10:08] to 2.0 yes [10:08] I've backported it to 1.18.1 [10:09] oh, he was going to land your backport? [10:09] he seems to land it [10:09] but to wrong branch [10:10] https://code.launchpad.net/~bialix/bzr/bzr-1.18-set-tags-bytes-bug/+merge/10811 [10:10] poolie: my proposal will not be fun at all if you don't release today :) [10:10] vila: genau! [10:10] vila: oh [10:10] you mean 9-9-9 [10:11] bialix: yup, double meaning :-) [10:11] I've recall Hitler "nine" from recent movie [10:11] bialix: Infurious Bestards ? [10:11] yep [10:11] saw the trailer [10:12] poolie: is it possible to land https://code.launchpad.net/~bialix/bzr/bzr-1.18-set-tags-bytes-bug to 1.18.1? [10:12] Watch it undubbed (sp?), Brad Pitt accentS are hilarious ! [10:12] yes [10:12] spiv has not landed it [10:12] i'll merge it [10:12] vila: ok, will wait for dvd with English sound and subtitles [10:12] in fact i am merging it [10:12] vila: especially the italian one :) [10:13] luks: indeed ! [10:13] hi luks [10:13] hey [10:14] bialix: there is more german and french than english [10:17] well, in Ukraine I believe our brave translators cut out german and french and leave only ukrainian [10:17] heh [10:17] so original DVD sound is cool for listen [10:17] yep [10:19] bialix, was there a bug for that change? [10:19] i think there was [10:19] yes, it was [10:20] Bug 418931? [10:20] Launchpad bug 418931 in bzr "AssertionError: _remember_remote_is_before((1, 18)) called, but _remember_remote_is_before((1, 15)) was called previously" [High,Fix committed] https://launchpad.net/bugs/418931 [10:20] yes, that bug [10:21] poolie: ^ [10:23] lp is a bit down [10:25] poolie: slow, but not down [10:28] ok, i'm sending 1.18.1 to pqm [10:32] ok that's it for me [10:56] vila: do you want long answer in e-mail about setup.py? [10:56] I think you can look at qbzr's setup.py and its extras/ [10:56] to get some impression [10:58] oooh, so you meant, 'that' already what qbzr does' not 'we don't need that stuff' ? [10:59] I've lost in ' signs [10:59] sorry, reading /extras/* [11:00] bialix: what qbzr did is exactly what bzr needs to do there, and igc should really look at build_docs for example, it sounds like a far easier way to make sphynx a soft dependency that trying to do that from the Makefile [11:01] bialix: now, I don't really know hoe bzr setup.py and plugins setup.py can collaborate, but I'm sure we'll find :) [11:01] s/hoe/how/ [11:02] bialix: Do we agree ? [11:05] bialix: still there ? [11:14] vila: ping, I'm back [11:14] ha ok, so ^ [11:15] [13:00] bialix: what qbzr did is exactly what bzr needs to do there, and igc should really look at build_docs for example, it sounds like a far easier way to make sphynx a soft dependency that trying to do that from the Makefile [11:15] yes, I agree here [11:15] [13:01] bialix: now, I don't really know hoe bzr setup.py and plugins setup.py can collaborate, but I'm sure we'll find :) [11:15] ^ I think all setup.py should be importable [11:16] i.e. call to setup() function should be guarded with if __name__ == '__main__' stuff [11:19] ooooh, so we can use 'from bzrlib.plugin.qbzr import setup as qsetup' for example and collect anything we need ? [11:19] bialix: sounds like a very good plan [11:29] bialix: so may be you should point to qbzr/extras stuff in that mail discussion so that we converge [11:37] .ьу иид [11:37] * bialix bbl [12:27] vila: ping [12:27] [13:19] ooooh, so we can use 'from bzrlib.plugin.qbzr import setup as qsetup' for example and collect anything we need ? [12:27] ^ yes === mrevell is now known as mrevell-lunch [13:38] hello [13:38] I'm getting AttributeError: 'module' object has no attribute 'ProgressBarStack' when inspecting a file with loggerhead [13:39] loggerhead 1.10-1 from debian testing, bzr1.17 from the same [13:43] Hi Everyone [13:46] just upgraded to 1.18, problem persists === mrevell-lunch is now known as mrevell [13:54] sometimes i like to commit just to save a checkpoint even if i don't intend the commit to be permanent (i.e. a mess of files left over from some aborted experiment) [13:54] *e.g.! [13:54] is there a way i can re-organise such commits at a later date? [13:55] and what are the implications on the sequential revision numbers? i think git sidesteps the problem by using hashes [14:00] alex-weej: the revnos are just aliases (and are unique to any branch) [14:00]