[00:01] <beuno> mwhudson, ta
[00:01] <mwhudson> beuno: i'm a pushover :)
[00:03] <beuno> very effective pushover ;)
[00:34] <spiv> Good morning.
[00:34] <lifeless> hai
[00:39] <Kissaki> hi
[00:40] <Kissaki> morning... haha
[01:11] <garyvdm> igc: how important do you think it is to finish Bug 328598?
[01:12] <igc> garyvdm: pretty important ...
[01:12] <igc> at a minimum, we want a placeholder class so ...
[01:13] <igc> that all GUIs get nicer revision selection as the widget changes/improves
[01:13] <igc> garyvdm: the first implementation doesn't need to be too clever - it just needs to exist :-)
[01:13] <garyvdm> It's current status is that it works, but some time one 1 cell gets selected, rather than the whole row.
[01:14] <garyvdm> and you can't select multiple rows - which would be nice for things like merge - to do cherry picks
[01:14] <lifeless> http://www.xaprb.com/blog/2009/06/07/the-cache-oblivious-algorithms-inside-tokuteks-tokudb/
[01:15] <igc> garyvdm: where can I see it in action now?
[01:15] <Gnx-> can I specify a file to always be overwritten in new revisions?
[01:15] <garyvdm> igc: lp:~qbzr-dev/qbzr/revision-selector
[01:16] <garyvdm> then bzr pull
[01:16] <garyvdm> err bzr qpull
[01:16]  * igc grabs it
[01:17] <igc> damn - AbsentContentFactory exception :-(
[01:18] <garyvdm> igc: unfortunately to fix the problems with it, I need to rewrite some of the qt combo box code so I can modify it's behaviour
[01:18] <garyvdm> Gnx-: can you explain in a bit more detail
[01:19] <garyvdm> Do you want the file to be overwritten when you pull a new revision?
[01:19] <Gnx-> garyvdm: well I'd like to include a sqlite database, and it does not like merging
[01:19] <Gnx-> but I'd want it to always be the version from the lats commit
[01:19] <Gnx-> last
[01:20] <garyvdm> Gnx-: with you now - but I don't know the answer
[01:20] <garyvdm> sorry
[01:20] <Gnx-> so basically I'd like to have the overwrite option for just one file
[01:21] <Gnx-> I know I can have it for push/pull in their entirety
[01:21] <garyvdm> Gnx- does bzr detect that it is a binary file, or does it think it's a text file and try merge it?
[01:22] <Gnx-> garyvdm: it thinks its a text file
[01:22] <Gnx-> and throws content conflict
[01:22] <garyvdm> Gnx- Hmm - that seems like a bug :-(
[01:23] <garyvdm> Gnx- Bug 218128
[01:23] <Gnx-> garyvdm: so it should detect binary files?
[01:24] <Seablade> Hmm before I make a complete fool of myself, is there an IRC channel for TortoiseBZR?
[01:24] <lifeless> this is i
[01:24] <Seablade> Haven't found anything via google yet
[01:24] <lifeless> it
[01:24] <garyvdm> Seablade - no - you can ask here
[01:24] <Seablade> Ahh ok, now to make a fool of myself then:)
[01:25] <Seablade> Is there a way using tortoisebzr to checkout from an SVN server with credentials?  I can't seem to find a place to enter them, and the checkout process seems to be hanging so I assume it is looking for them
[01:26] <garyvdm> Seablade - I think you have to put the password in the url.
[01:26] <Seablade> TortoiseBZR installed as part of the Bzr for windows installer for the record
[01:26] <Seablade> garyvdm: Hmm didn't try that, now I gotta remember the syntax for doing that, thanks
[01:26] <Seablade> garyvdm: I will let you know if it works
[01:27] <garyvdm> I know jelmer added ui code that asks for a username and password. Qbzr only implements the just password version. (TortoiseBZR - uses qbzr btw)
[01:28] <lifeless> jam: pyrex for heads I think
[01:28] <lifeless> jam: when you're into inner function removal for optimisation...
[01:29] <garyvdm> Sorry igc: that AbsentContentFactory exception - was that using the revision selector?
[01:29] <Seablade> garyvdm: Yes I knew that much of TortoiseBZR and QBzr were the same, just wasn't sure how much.  Hmm looks like the username and password in the URL seems to be crashing it, gotta do a sanity check but I think I got everything correct
[01:31] <Seablade> garyvdm: Hmm there should be no need for quotes when supplying username and password through the URL is there?
[01:31] <lifeless> igc: use nosmart+ should avoid the error
[01:31] <lifeless> garyvdm: you need to run the branch repairer
[01:31] <igc> yep - plain http worked as well
[01:32] <lifeless> poolie: I had no further changes to make to the advisory I drafted; abentley suggested including more of the immediate actions in it, which I could work in if you like, or we could send it out
[01:32] <lifeless> mwhudson: where are you guys at in runing the repairer over all stacked branches?
[01:32] <mwhudson> lifeless: somewhat stalled, i guess
[01:32] <garyvdm> Seablade: You should only need to specify a username - it will then ask you for the password.
[01:33] <Seablade> garyvdm: Hmm let me try that, the protocol should just be https if it is checking out over svn+https correct?
[01:33] <idnar> Lightweight checkout (format: dirstate or dirstate-tags or pack-0.92 or rich-root or rich-root-pack)
[01:33] <idnar> what exactly does "or" mean there?
[01:33] <garyvdm> Seablade - I don't know that - have not use bzr-svn much.
[01:34] <Seablade> garyvdm: Looks like it, it is checking out now, or at least seems to be, thanks
[01:34] <lifeless> idnar: inclusive
[01:34] <idnar> well, I mean, why can't it tell me which one it actually is?
[01:35] <lifeless> idnar: because the ui is trying to be too smart
[01:35] <lifeless> idnar: what it means is 'this is the style of checkout you get with any of the above formats'
[01:35] <Gnx-> garyvdm: do you think if I slipped some non-text in the beginning of the file it would behave correctly in bzr?
[01:35] <idnar> ah, okay
[01:35] <lifeless> idnar: because they all share the same 'working tree' code
[01:36] <idnar> so I guess I'd want to run bzr info against the repository I checked out
[01:37] <Seablade> garyvdm: Ok I can reproduce that crash at least, it seems to happen when in tortoiseBzr I tell it to checkout to a location(destination) that does not end in the svn repository name
[01:37] <Seablade> garyvdm: So for isntance if I checkout https://blah/els to C:\Projects it dies, but doesn't if I do it to C:\Projects\els
[01:39] <garyvdm> sorry Gnx-, Seablade - I'm a bit busy atm.
[01:40] <Seablade> garyvdm: np, just tossing it out there if anyone needs the info, I have the checkout working at least, which was the main goal.  If I have to deal with a slittle screwy directory structure I certainly can;)
[01:48] <lifeless> idnar: depends on what you want to find out, but yes
[01:48] <mwhudson> is it possible the bzr 1.14 release branch never got merged back to bzr.dev?
[01:48] <mwhudson> (or that it did, but after the 1.15 branch was cut?)_
[01:48] <mwhudson> i guess i can find these things out for myself
[01:56] <lifeless> I sure hope so
[02:01] <idnar> are bzr+ssh URLs relative to $HOME?
[02:02] <SamB> idnar: I think you need a /~/ if you want that
[02:03] <idnar> hmm, /~/ doesn't work but specifying the full absolute path does
[02:03] <lifeless> idnar: no, they are abspath to the virtual root (which depends on server config as normal)
[02:04] <lifeless> idnar: host/~/ is used with sftp to mean '.' in the SFTP protocol, as it has no good mapping in std66 and the I-D for sftp
[02:04] <lifeless> :// was bong
[02:04] <lifeless> spiv has a patch (not landed I think) to let /~/ be used with bzr+ssh too
[02:06] <SamB> ":// was bong" ?
[02:09] <lifeless> SamB: sftp:// was bong
[02:10] <SamB>   bong
[02:10] <SamB>        v : ring loudly and deeply; "the big bell bonged"
[02:17] <thumper> lifeless: just confirmation before I delete them, but the content of obsolete_packs is ok to delete if no bzr commands are in progress right?
[02:17] <thumper> lifeless: when do obsolete_packs get cleaned out?
[02:20] <lifeless> thumper: when bzr does a pack
[02:20] <lifeless> thumper: which is every 10 commits on average
[02:20] <thumper> lifeless: I don't believe that
[02:20] <lifeless> thumper: check the code if you like
[02:21] <thumper> lifeless: because I just pulled stuff in that seemed to do a pack
[02:21] <thumper> and I hve stuff there from over a month ago
[02:21] <lifeless> thumper: file a bug then
[02:21] <lifeless> thumper: The pack algorithm is as follows:
[02:21] <lifeless> a) make new pack
[02:21] <thumper> I have 2.3 gig of obsolete_packs in my LP repo
[02:21] <lifeless> b) delete obsolete_packs contents
[02:21] <lifeless> c) activate new pack
[02:22] <lifeless> d) move obsoleted packs and indices to obsolete_paks
[02:29]  * igc off for lunch and medical stuff
[02:45] <garyvdm> How come bzr pull . -rsubmit: --overwrite only pulls the lca of . and :submit? I thought it would pull the tip of :submit like bzr pull :submit --overwrite
[02:48] <spiv> garyvdm: because ". -rsubmit:" resolves to that particular revision
[02:49]  * garyvdm re reads bzr help revisionspec
[02:50] <lifeless> submit: is the lastmerged rev of the submit branch
[02:54] <garyvdm> Ok - I thought that -rsumbit: gave you the tip of :submit.
[02:54] <garyvdm> I thought wrong...
[02:56] <poolie> lifeless: hi
[02:58] <garyvdm> Hmm - so -r ancestor::submit == -r submit:
[02:58] <poolie> lifeless: which advisory?
[03:03] <lifeless> poolie: about stacked repositories
[03:03] <lifeless> garyvdm: yes
[03:06] <jam> lifeless: certainly I agree about pyrex if I was fully fine tuning. Mostly I'm algorithm exploring, and wanted to make sure it was comparable to our existing code
[03:43] <poolie> jam, lifeless, i'd like to do 1.16rc1 a bit early, like this week, to help with brisbane-core testing
[03:43] <poolie> and to let it be rolled into launcphad
[03:43] <jam> poolie: sure
[03:43] <poolie> do you see any problems, or any bugs that'd block it?
[03:46] <poolie> lifeless: spiv does have a patch for ~ but he agreed it was bad to do it at the ssh level so he's going to rethink it
[03:46] <poolie> ie it's still in his queue
[03:50] <poolie> lifeless, jam, also, what do you think about changing both the on-disk marker and the ui name for this format to say '2a'
[03:50] <jam> poolie: I think we should make it 2 or 2-something
[03:50] <jam> vincent agreed this morning
[03:51] <poolie> until i was writing that mail i was going to say just '2' or '2.0' but the thing is
[03:51] <poolie> at least in the general case if not here
[03:51] <poolie> we can't rule out changing it before code 2.0 comes out
[03:51] <poolie> and having obviously different but related names seems to be useful
[03:53] <spiv> '2a' seems like a reasonable compromise given the constraints (such as lack of time machine).
[03:54] <poolie> ok
[03:54] <poolie> i'll put up a patch
[04:01] <lifeless> poolie: well its a dev format already
[04:02] <lifeless> and currently we promise not to break them
[04:02] <lifeless> poolie: I'm fine with the next change to it being e.g. 2.0beta
[04:13] <lifeless> (I mean, I agree that we should put 2.0 in the disk format asap)
[04:23] <spiv> poolie: https://code.edge.launchpad.net/~jspashett/bzr/76616_ignored_on_add_confusing/+merge/4864 has a comment from you saying "looks good, I'll merge", but lp doesn't think it is merged?
[04:25] <mwhudson> jelmer: awake still?
[04:27]  * mwhudson sends mail instead
[04:30] <poolie> spiv: i think i rebased his patch
[04:30] <poolie> he also said that i might have merged the wrong thing
[04:30] <lifeless> chalk up another way rebase interferes ;)
[04:30] <poolie> i'll come back to it sometime
[04:31] <poolie> lifeless: i can't work out whether you're agreeing about format names or not
[04:31] <KhaZ> I'm trying to debug an ssh error; how do I set BZR_SSH again?
[04:31] <KhaZ> (For debugging purposes, I mean.)
[04:32] <lifeless> poolie: I think we should have the next production format be called 2.0 on disk in some way; If we have no further planned changes then I think changing the format label would break early adopters and we should instead add another format with only a disk label change
[04:32] <spiv> poolie: ok.  When the current PQM queue clears that will be the only proposal left on https://code.edge.launchpad.net/bzr/+approvedmerges, if that's extra incentive :)
[04:32] <lifeless> poolie: It wasn't clear to me what you were proposing to do
[04:33] <lifeless> KhaZ: I'm not sure, it might be one of openssh/paramiko/...
[04:33] <KhaZ> Ah; got it!  Looks like I got owned by hosts.deny.  Whoops. ;)
[04:34]  * spiv -> lunch
[04:44] <Peng_> Cool, my Loggerhead repo fails a check. :D
[04:46] <lifeless> Peng_: which one?
[04:47] <Peng_> lifeless: Which repo or which check?
[04:47] <lifeless> whih check
[04:47] <Peng_> if (self.text_sha1 != tree._repository.texts.get_sha1s([key])[key]): KeyError: ('wsgitest.py-20080612051902-5y0zpdi6fhxgun6z-1', 'jelmer@samba.org-20090529150418-05on2fgizfqs77fj')
[04:48] <lifeless> hax!
[04:48] <lifeless> (thats actually fairly serious)
[04:48] <lifeless> we need tools to repair this
[04:48] <lifeless> please file a bug
[04:48] <Peng_> Crap, real
[04:48] <Peng_> The copy on my server passes, so even in the worst case I've lost little to no data.
[04:49] <Peng_> Err, really?*
[04:50] <Peng_> lifeless: Any chance of ruining a remote repo if I push to it?
[04:50] <lifeless> well it means there is an inventory claiming that  ('wsgitest.py-20080612051902-5y0zpdi6fhxgun6z-1', 'jelmer@samba.org-20090529150418-05on2fgizfqs77fj') exists, and yet its missing.
[04:50] <lifeless> so that revision can't be reconstructed
[04:51] <lifeless> I don't think you'll make it worse pushing to it
[04:51] <Peng_> What if I push a revision in this repo to a remote one, though?
[04:51] <Peng_> Argh, this is a pain.
[04:52] <lifeless> backup the target repo first
[04:52] <Peng_> Indeed.
[04:59] <Peng_> lifeless: If another repo passes check, it's safe to say it isn't broken in this way?
[04:59] <lifeless> probably :)
[05:00] <Peng_> lifeless: Any idea how this could've happened?
[05:01] <Peng_> Sigh, I want a faster CPU. Check is slow. :P
[05:01] <lifeless> Peng_: bzr-svn possibly
[05:01] <lifeless> Peng_: or a bug
[05:02] <Peng_> lifeless: This isn't a bzr-svn repo, though.
[05:03] <Peng_> Anyway, I'll file a bug once I'm done working around this.
[05:06] <Peng_> Well, the good news is it looks like this hasn't affected my serfer or lp:loggerhead.
[05:06] <lifeless> Peng_: it could be a fetch ailure, or a knit related ordering bug back some time ago
[05:07] <lifeless> if that key exists in your other repo, try fetching a stream directly in python to fill it
[05:07] <Peng_> lifeless: How should I test if it exists?
[05:08] <lifeless> Peng_: _repository.texts.get_sha1s([key])[key])
[05:08] <lifeless> with key = ('wsgitest.py-20080612051902-5y0zpdi6fhxgun6z-1', 'jelmer@samba.org-20090529150418-05on2fgizfqs77fj') and so on
[05:08] <Peng_> And the key is that tuple?
[05:08] <Peng_> :)
[05:09] <jml> poolie: available for a call?
[05:12] <lifeless> jml: do you want to get together for the europython talk and do some notes/whatever
[05:12] <jml> lifeless: yes, sounds like a great idea
[05:12] <lifeless> jml: if so I'd be delighted, but I'll let you drive it (as I'm not going)
[05:12] <lifeless> cool
[05:13] <jml> lifeless: how's thursday evening?
[05:14] <lifeless> this week is kinda full - but next week anytime should be fine
[05:15] <jml> lifeless: ok cool.
[05:18] <Peng_> lifeless: My other repo does not have that key.
[05:21] <lifeless> Peng_: then you have a local rev (perhaps jelmer@samba.org-20090529150418-05on2fgizfqs77fj) which is either a ghost in other repos, or part of a dead branch, that is faulty.
[05:24] <Peng_> lifeless: Ohhhhhhh! I just remembered!
[05:24]  * Peng_ suddenly pings out, never to be seen again.
[05:25] <idnar> haha
[05:25] <poolie> jml: hi
[05:25] <jml> poolie: I'm just out of batteries, may I call you on your mobile?
[05:25] <poolie> jml: am a bit starving at the moment, would about 3pm be ok?
[05:25] <jml> poolie: 3pm is perfec.n
[05:25] <poolie> k
[05:25]  * jml off.
[05:25] <poolie> off to post ian's swag and get lunch
[05:26] <Peng_> lifeless: Anyway. There was a branch, lp:~jelmer/loggerhead/smart-server (since deleted) that was, like, broken. I tried to branch it into this repo. Maybe that introduced the bad revision.
[05:27] <lifeless> Peng_: likely
[05:28] <Peng_> lifeless: Yeah, I just checked .bzr/branch/last-revision on my copy of the branch, and it is indeed that revision.
[05:28] <Peng_> lifeless: Still think I should file a bug?
[05:28] <lifeless> Peng_: how long ago was that
[05:29] <lifeless> Peng_: and do you have knits locally?
[05:29] <Peng_> lifeless: Note the date in the revid, 2009-05-29. My repo was (and still is) 1.9-rich-root. The remote repo presumably was too, since I don't remember a knit warning when branching it.
[05:29] <lifeless> Peng_: actually yes. File a bug - we should neither have permitted the damage, nor your repo to be damaged, and we should allow it to be fixed.
[05:32] <Peng_> .bzr.log++
[05:40] <Peng_> lifeless: Filed https://bugs.edge.launchpad.net/bzr/+bug/385054
[05:41] <lifeless> jelmer: do you have that original source branch?
[05:42] <Peng_> lifeless: Do you think the repo is safe to use as long as I don't interact with that revision?
[05:42] <Peng_> jelmer: That is, the original, broken lp:~jelmer/loggerhead/smart-server
[05:43] <lifeless> Peng_: yes
[05:44] <Peng_> lifeless: So I can keep using it? You sure? :D
[05:44] <Peng_> Why am I suddenly paranoid?
[05:45] <lifeless> I don't know. Are they after you ?
[05:45] <Peng_> lifeless: The Illuminati corrupted jelmer's branch to interfere with my work! or something!
[05:45] <idnar> Peng_: don't answer that, he's one of them!
[05:45] <Peng_> Oh crap!
[05:46] <idnar> now you've done it, the Admiral will be here any second
[05:47] <Peng_> Quick favor: Could someone link bug #241133 with the 1.13 milestone?
[05:48] <spiv> Peng_: I can't; the 1.13 milestone is no longer an option in the dropdown.  1.14rc2 is as far back as it goes.
[05:49] <Peng_> spiv: OK. Thanks.
[05:49] <lifeless> Peng_: don't stress.
[05:59]  * jml is back
[06:05] <Peng_> lifeless: You're just saying that because adrenalin makes it harder to read my mind!
[06:06] <jml> poolie: whenever you're ready
[06:08] <Peng_> bzr check seems to fail over bzr+ssh. "revno does not match len(mainline) 366 != 0".
[06:08] <Peng_> Oh, actually, it had already checked the repo. That was just the branch.
[06:23] <poolie> jml, hi!
[06:24] <jml> poolie: skype?
[06:24] <poolie> if you like
[06:30] <spiv> lifeless: hmm, pqm is still silently swallowing my merge requests for lp: URLs :(
[06:34] <lifeless> spm: ^
[07:12] <poolie> jml: i'm going to change 1.16 to that date -- https://edge.launchpad.net/bzr/1.16
[07:13] <Peng_> "bzr check" sure is dreadfully inefficient over the smart server. :)
[07:13] <lifeless> Peng_: yes
[07:13] <jml> poolie: thanks
[07:13] <lifeless> Peng_: feel free to add a verb for it
[07:14]  * Peng_ runs away.
[07:22] <vila> hi all
[07:23] <poolie> hello vila
[07:24] <vila> poolie: I've started a buildbot. Only jaunty and OSX 10.5 to start with.
[07:24] <vila> poolie: selftest is failing right now :-)
[07:25] <poolie> even on jaunty?
[07:25] <vila> poolie: at least one failure is related to pb noise, I was wondering if you had pending changes in that area ?
[07:25] <poolie> are the results public?
[07:25] <vila> the only test failing on jaunty is one testing 'bzr --version' stderr and finding some pb artifacts there, really not a big problem
[07:26] <poolie> it's a bit surprising
[07:26] <poolie> i do have some changes pending
[07:26] <fullermd> Y'know, I had some weird test failures the other day I mentioned here...
[07:26]  * fullermd digs.
[07:27] <fullermd> test_two_files_different_versions_no_inconsistencies_bug_165071 fails for me on RepositoryFormat's 5, 6, and 7.
[07:27] <vila> poolie: the buildbot is not public so far, but is under bzr and I keep notes
[07:35] <poolie> spiv, hi?
[07:36] <poolie> can you tell me more about bug 380314?
[07:36] <spiv> poolie: hello
[07:37] <poolie> i guess specifically
[07:37] <poolie> are you working on it, and is it needed for 1.16? (it seems so)
[07:37] <spiv> To be honest, I'd forgotten about it, but I targetted it to 1.16 for a reason :)
[07:41] <spiv> I'll start on that basically right now.
[07:41] <Peng_> Huh, I can't get "bzr check --branch bzr+ssh://..." to fail again.
[07:41] <Peng_> Maybe it only does if I check the whole repo too.
[07:41] <poolie> ok
[07:42] <poolie> what were you doing before i disrupted you? :)
[07:42] <spiv> It shouldn't be a lot of work, I ought to have it done in time for the probable rc on Thursday.
[07:42] <spiv> :)
[07:42] <spiv> Today I've been closing off various small things, e.g. approved branches, a little bit of administrivia.
[07:42] <vila> fullermd: and only that test ?
[07:43] <spiv> Specifically, right when you pinged me on IRC I had just finished making a coffee :)
[07:43] <poolie> :)
[07:51] <vila> poolie: sorry, get distracted, does your pending changes includes setting the ui from an env var ?
[07:53] <poolie> not yet
[07:53] <poolie> i know it needs to be done
[07:53] <poolie> at the moment i'm trying to make sure it gets cleaned off when there's other output
[07:53] <poolie> i will come back to that
[07:57] <poolie> lifeless: it's a good document
[07:57] <poolie> you could put it in devnotes
[08:03] <lifeless> poolie: Sure. Is devnotes a branch of bzr itself?
[08:05] <poolie> no
[08:06] <fullermd> vila: Well, I didn't run the whole test suite.  I just noticed that by accident since it got run when I was checking something else.
[08:07] <vila> fullermd: ok, may be worth filing a bug for it so that it doesn't get lost :-/
[08:07] <lifeless> poolie: can I ask why it isn't ?
[08:08] <lifeless> I thought the developer docs subdir was working well
[08:08] <fullermd> I've got a new workstation in pieces across my office.  Was planning to try a full testsuite run after I got it live, just to see what it's like when it takes less'n an hour to run...
[08:08] <vila> fullermd: yeah !
[08:09] <vila> fullermd: what processor/memory ?
[08:09] <fullermd> Phenom II 955, 8 gig DDR2-800
[08:10] <lifeless> fullermd: thats amd yead?
[08:10] <fullermd> Yah.
[08:10] <fullermd> Intel's still made it impossible for me to buy their chips, the bastiches.
[08:11] <fullermd> I'd'a considered the i7 if the memory controller weren't b0rked  :|
[08:11] <vila> fullermd: I'm curious to know about 'bzr selftest --parallel=fork' timings on it :-)
[08:12] <vila> as soon as all tests pass there of course :)
[08:12] <fullermd> I'm just dreaming of what it'll be like when firefox is merely really annoyingly slow.
[08:15] <lifeless> fullermd: impossible?
[08:15] <fullermd> Let me have my dreams.
[08:15] <lifeless> fullermd: I'm sure they will take your money
[08:16] <fullermd> They always have before.  Consistency is a virtue.
[08:18] <vila> fullermd: why are the memory controller borked ?
[08:18] <fullermd> Oh.  Because they integrated a memory controller, and then didn't let it support ECC.
[08:19] <fullermd> AMD did.  So I can grab any AMD chip and put decent memory in.  With Intel, you always either had to be VERY careful and picky about motherboards, or buy Xeon.
[08:19] <fullermd> And now that they've integrated the memory controller, you can't even be picky about motherboards anymore.
[08:20] <vila> But don't you want the fastest DDR3 memory anyway ?
[08:20] <fullermd> I don't care HOW fast I can get the wrong answer   :p
[08:21] <fullermd> I care about my data; I don't consider ECC to be optional.
[08:21] <vila> You have to educate me here I'm affraid because I may not understand what ECC is about then :-/
[08:21] <fullermd> Detecting and correcting bit errors.
[08:23] <fullermd> Same reason the new system is running ZFS with SHA256 block checksums.
[08:23] <vila> And DDR3 don't do that ?
[08:23] <fullermd> (I'm not paranoid.  I've been around long enough to know my hardware really _is_ out to get me!)
[08:24] <fullermd> Oh, it can.  But DDR3 is still twice the price of DDR2, and the speed difference isn't near big enough to justify that.
[08:24] <fullermd> Maybe in a couple years, I'll replace the board and load up on DDR3 when the price is down and 4GB DIMM's are at a good price point.  The processor will handle either.
[08:25] <vila> Oh I see, the *other* strategy :-)
[08:25] <fullermd> (it's a lie of course, I'll probably sit on the system unchanged for 6 or 8 or 10 years, like I always do.  But it's a nice dream  :P)
[08:26] <vila> fullermd: I suggest you do yourself a favor and buy an SSD, you won't believe the impact on raw performances...
[08:27] <fullermd> Oh, with my EXTRA money?   :p
[08:27]  * fullermd doesn't have a couple grand to spend on storage...
[08:27] <vila> you can find some for 150$ these days, worth the price for ~64GB to play with
[08:27] <poolie> lifeless: because it's not a branch of bzr
[08:28] <poolie> they're not really in sync with each other, like the user documentation is meant to be
[08:28] <fullermd> The cheap ones all have abysmal random write performance.  You gotta get up into the $600 or so ones before they don't fall apart there.
[08:28] <fullermd> Then double the price to get 2 of 'em to mirror...
[08:28] <poolie> if we're landing something that is in sync, like documentation of code that's actually come in, that does belong in there
[08:29] <igc> back
[08:29] <fullermd> vila: I've got the new series Velociraptors.  They're plenty fast.
[08:29] <fullermd> vila: (anyway, the hard drives could be pretty slow and still be a nice improvement over my current ~12 year old ones  :P)
[08:29] <vila> haaa, Monsieur is using mirrored velociraptors and is talking about PRICE ? :-)
[08:29] <poolie> hello igc
[08:30] <fullermd> Hey, the raptors WERE the cheap option.  I'm a SCSI nazi.
[08:30] <vila> pfew, I gave up with SCSI years ago :-/
[08:30] <jml> if I do 'bzr init foo' inside a brisbane-core repo, the branch is format6 -- is this expected?
[08:30] <poolie> igc, a large bag of UDS shwag is in the mail :)
[08:30] <poolie> spiv, want a quick call?
[08:30] <lifeless> jml: yes its a defence of repositories as currently defined
[08:31] <lifeless> defect
[08:31] <jml> lifeless: ok thanks.
[08:31] <lifeless> poolie: have we moved all the extant theory documents out then ?
[08:31] <spiv> poolie: sure
[08:31] <lifeless> poolie: I'd rather not have two places to go looking for such things
[08:32] <jml> how would I upgrade those branches to branch7 format?
[08:32] <lifeless> jml: upgrade --<format>
[08:32] <jml> lifeless: what goes into <format>
[08:33] <poolie> ay
[08:33] <lifeless> whatever you used to make your repo
[08:34] <poolie> no, i haven't cleaned up all existing documents
[08:34] <poolie> this is mostly an alternative to putting them on the wiki, which
[08:34] <poolie> is annoying to edit especially when you're flying or on a super flakey network
[08:34] <lifeless> oh
[08:35] <lifeless> well, with this sort of think I would normally get some feedback and land it in bzr.dev.
[08:35] <lifeless> Do you want this to change?
[08:35] <lifeless> s/think/thing/ (Sorry about typos, am really EOD'd already)
[08:35] <poolie> or an alternative to having it just on the list
[08:36] <poolie> oh of course the other difference with this branch is that, like the wiki, unlike dev, it's clearly not pre-review
[08:36] <lifeless> ah, [that wasn't clear]
[08:37] <poolie> i did send a mail
[08:37] <poolie> which may have been unclear :)
[08:37] <lifeless> its likely in my backlog, I was a little distracted
[08:37] <poolie> so, it's ok to land it in bzr.dev
[08:37] <poolie> i do have some qualms about having speculative or thinking-out-loud documentation there
[08:38] <poolie> i kind of feel if it's in a release it ought to all relate to that release
[08:38] <poolie> also, possibly having somewhere it's shared and mutually editable without going through review is good
[08:38] <poolie> though we could of course do that with just a devnotes branch of bzr
[08:38] <lifeless> or a loom even :P
[08:39] <jml> I didn't make this repo :(
[08:39] <lifeless> jml: well, --development-rich-root should do it, but I haven't checked
[08:40] <igc> thanks poolie
[08:40] <jml> ahh right, was running in wrong directory
[08:41] <jml> thanks.
[08:42] <lifeless> poolie: I agree that there is a tension between the timelines of documents
[08:43] <lifeless> poolie: this shows up a lot in translations
[08:44] <lifeless> poolie: yeah, your email about that was pretty much sent right before the weekend between allhands and UDS; as you know monday morning had me emulating a chicken
[08:45] <lifeless> poolie: I encourage you to put some thought into devnotes-as-an-experiment
[08:46] <lifeless> so for instance, how do you get the same degree of review and consideration of whats in it as bzr.dev gets from the reviews on the list
[08:47] <lifeless> I will look at it tomorrow and make sure I've read whats in it
[08:49] <lifeless> but I really have to EoD now
[09:01] <poolie> lifeless:
[09:01] <poolie> > Perhaps weakrefs?
[09:01] <poolie> [ ] metaprogramming
[09:01] <poolie> [ ] code generation
[09:01] <poolie> [ ] C extensions
[09:01] <poolie> [ ] kernel module
[09:01] <poolie> [ ] flub
[09:01] <lifeless> weakrefs on the progress bars in the thing that maintains the stack
[09:02] <poolie> maybe
[09:02] <lifeless> then it can cleanly discard the most recent addition if a generator is existed early
[09:02] <lifeless> FSVO clean
[09:02] <poolie> the thing is
[09:02] <poolie> even conceptually, getting away from the details of python implementation
[09:02] <poolie> if the UI model is that there is a stack of nested activities
[09:03] <poolie> and if activities can trail off with no clear ending
[09:03] <poolie> there seems to be a problem...
[09:03] <poolie> so you can handle this by generalizing the model, to say there can be an arbitrary DAG of progress tasks going on
[09:03] <poolie> some of which hang around for a bit and terminate during gc
[09:03] <lifeless> meep!
[09:04] <poolie> and then you work out how to draw that on a single line of text :)
[09:04] <poolie> or, as i'm doing now, you rethink whether generators should really be doing this
[09:04] <lifeless> so
[09:04] <lifeless> the concern I have is not whether generators should be doing this, but whether any code used by generators can...
[09:05] <lifeless> [I mentally voted against generators doing progress bar creation/finalisation some time ago]
[09:05] <lifeless> OTOH I may not be thinking all that clearly right now.
[09:06] <poolie> code used by them in the sense of regular functions called by generators?
[09:07] <lifeless> yah
[09:07] <poolie> that shouldn't be a problem
[09:07] <poolie> i'm moving away from passing pb arguments down the stack
[09:07] <lifeless> right
[09:07] <poolie> so they can just create one, use it, and clean it up when they're done
[09:08] <lifeless> so the idiom I have is:
[09:08] <lifeless> for generators, do progress by inserting a filter from a non-generator function
[09:08] <lifeless> and the non generator has to be one that doesn't return the generator
[09:11] <poolie> i'm not sure i understand
[09:11] <poolie> but, i'm also not working on it atm and i have to stop soon
[09:12] <lifeless> sure
[09:12] <lifeless> just chewing the fat
[09:12] <poolie> do you mean you have a plain function wrapping the generator?
[09:12] <poolie> or vice versa?
[09:13] <jml> pushing up a new bbc branch to local launchpad:
[09:13] <jml> HPSS calls: 22 (10 vfs) SmartSSHClientMedium(connected=False, username=None, host='bazaar.launchpad.dev', port=None)
[09:13] <jml> surprised to see so many vfs calls.
[09:13] <lifeless> jml: pastebin the calls made please
[09:14] <lifeless> poolie: the former sometimes; or the former and the latter simultaneously sometimes.
[09:14] <spiv> jml: local launchpad is running bzr.dev?
[09:15] <spiv> There is a weakness with the HPSS call count ratchets in our test suite atm where they tend to hardcode the format to 1.9.
[09:16] <spiv> So a regression in number of vfs calls vs. 1.9 formats is certainly possible :/
[09:17] <jml> spiv: yeah.
[09:17] <lifeless> plain(generator(wrapped_helper))
[09:17] <lifeless> spiv: I'm hesistant to multiply them
[09:17] <lifeless> spiv: but perhaps we should bulk move them to chk
[09:17] <lifeless> spiv: also, network deltas - is that now top of your stack and do you need any help on it
[09:17] <lifeless> jml: pastebinned?
[09:18] <spiv> lifeless: top of my stack is https://bugs.edge.launchpad.net/bzr/+bug/380314
[09:18] <lifeless> oh right.
[09:18] <lifeless> uhm, it should?
[09:19] <jml> lifeless, spiv: http://paste.ubuntu.com/191488/
[09:19] <spiv> lifeless: well, a better bug title perhaps is "bzr pull -r 123 fails on a stacked branch via HPSS"
[09:19] <jml> client & server logging interleaved, unfortunately
[09:19] <lifeless> spiv: my immediate reaction is to stop calling revision_history
[09:20] <lifeless> jml: bzr-search
[09:21] <jml> dammit.
[09:21] <lifeless> jml: so there are two causes
[09:21] <lifeless> bzr-search
[09:22] <spiv> lifeless: yeah, the way that revisionspec does the revspec->revid mapping could probably be better, I think there's some nice logic somewhere that can work backwards from the branch last-revision info.
[09:22] <lifeless> and tags being written via VFS
[09:22] <jml> I don't know where bzr-search lives right now -- it's not in .bazaar/plugins
[09:22] <lifeless> jml: push --no-plugins is the easiest 'temp removal' test
[09:23] <spiv> jml: I 2nd lifeless' diagnosis FWIW.
[09:23] <jml> as long as the server side isn't using it
[09:23] <jml> although I don't think it will here
[09:23] <lifeless> jml: we need to implement set_tags_bytes to remove 9 of those 10
[09:25] <poolie> OK
[09:25] <poolie> movie sign!
[09:26] <lifeless> poolie: I am meeting a prospective DD in the city tomorrow @6 to sign his key
[09:26] <jml> lifeless, spiv: thanks.
[09:26] <lifeless> poolie: if you wanted to get together this week, tomorrow avo would thus work well for me.
[09:26] <poolie> k
[09:26] <lifeless> poolie: [just saying]
[09:26] <poolie> will ask s
[09:27] <vila> Will 1.16 be usable to switch bzr and launchpad to 2.0 format ?
[09:27] <poolie> vila, yes!
[09:27] <poolie> We Can Do It
[09:27] <asabil> hi all
[09:27] <lifeless> check and reconcile are still multi day operations for that format
[09:27] <lifeless> I worry about the logicistics
[09:28] <lifeless> I'm not sure we've finished fixing the bugs from the bzrtools upgrade experiment either
[09:30] <poolie> vila, probably better for now if you shelve the buildfarm and test or debug this...
[09:30] <lifeless> I'd like to see bzr switch safely and effectively to the 2.0 format before lp does, because bzr has a smaller codebase
[09:30] <vila> poolie: I already stopped working on the buildfarm :)
[09:31] <lifeless> the mails I've been sending about conversion experiments would be a good place to start
[09:34] <lamalex> Is anyone using bzr-git successfully?
[09:36] <spiv> lamalex: Launchpad is, at least...
[09:38] <lamalex> hm, anyone around who knows anything about it?
[09:39] <lamalex> i cant talk to my companies git repo with it, keep gettng bounced with sh: bzr: not found
[09:39] <lamalex> bzr: ERROR: Connection closed: please check connectivity and permissions
[09:40] <lifeless> lamalex: what url are you giving bzr?
[09:41] <lamalex> bzr+ssh://user@git.mycompany.org/~/git/mycompany/system/product.git
[09:41] <lamalex> i just got it by cloning that repo locally, and branching from there
[09:43] <spiv> lamalex: if bzr isn't installed on the remote end, then bzr+ssh can't work.  But I think bzr-git makes git:// URLs work?
[09:44] <lifeless> lamalex: thats a bzr url - you're telling bzr to use bzr on that url.
[09:44] <lifeless> lamalex: you want git+ssh://....
[09:47] <lamalex> ah, makes sense
[09:50] <jml> pushing up a brisbane-core branch while running the puller over another almost destroyed my system...
[09:50] <jml> that said, I hadn't tried that with a branch as big as those two before with any other format.
[09:56] <asabil> I tried checking out an svn repository using bzr-svn (the bzr.dev branch) to a development6-rich-root repository
[09:57] <asabil> it took some hours, but the resulting repository was about 11GB
[09:57] <asabil> after running a bzr pack on the repository, it went down to 700M
[09:58] <asabil> also, it seems like the branch wasn't in development6-rich-root format by default (bzr info was showing format: unknown)
[09:58] <asabil> are these known issues ?
[09:58] <asabil> the svn code is WebKit trunk
[09:58] <lifeless> asabil: the branch or tree will be different - info -v will show you
[09:59] <lifeless> the size is surprising, I thought bzr-svn did many transactions
[09:59] <asabil> I already upgraded to the branch to development6-rich-root
[09:59] <lifeless> might ask jelmer if its disabling pak or something 'clever'
[09:59] <asabil> oh and the 11GB is contained in 2 .pack files
[10:00] <asabil> each one is about 5.5GB
[10:01] <asabil> having such large files made the process of branching extremely slow over time (as the pack files grew bigger)
[10:01] <lifeless> I'm not sure that the size is what made it slow
[10:02] <lifeless> anyhow, if you had more revisions bzr would have autopacked itself earlier
[10:02] <lifeless> I agree its bad, perhaps file a bug for jelmer.
[10:09] <jml> hmm.
[10:12] <jml> bummer.
[10:13] <jml> spiv: just got this error wish local testing: http://paste.ubuntu.com/191520/
[10:13] <jml> spiv: I'm guessing it's a direct consequence of bazaar 1.15 hpss improvements.
[10:14] <spiv> jml: possibly, what's the -Dhpss trace?
[10:15] <spiv> jml: potentially it's a direct consequence of a stacking-logic issue being exposed by hpss...
[10:15] <spiv> jml: (not that there's much practical difference for you)
[10:16] <jml> spiv: http://paste.ubuntu.com/191522/
[10:25] <lifeless> jml: could be the far end trying to open it
[10:26] <jml> lifeless: could be, but the far end has that url protocol registered
[10:26] <spiv> The response to the BzrDirFormat.initialize_ex call has the lp-NNN... URL as the final_stack_pwd.
[10:28] <spiv> I'm not sure what the best way to fix that is, but I think the pressure to fix the bug that server-internal URLs are returned to the client is growing...
[10:29] <jml> spiv: heh
[10:29] <jml> spiv: well, this is of course a 1.15 rollout blocker for us.
[10:29] <lifeless> jml: make sure there is a bug
[10:29] <spiv> please file a bug and target it to 1.16 I guess
[10:29] <lifeless> I wrote init_ex; tomorrow I can chat with you
[10:30] <jml> will do.
[11:30] <bialix> igc: around?
[11:34] <bialix> nope
[12:05] <bialix> igc: ?
[12:06] <bialix> igc: about your qversion/qsysinfo patch
[12:07] <igc> hi bialix
[12:07] <bialix> can you provide screenshot or ascii-drawings of how it looks for you?
[12:07] <igc> bialix: shall do
[12:07] <bialix> I could try to recreate the form for this dialog
[12:07] <bialix> so it will be usable with older PyQT
[12:07] <igc> bialix: what's the minimum PyQT we support?
[12:08] <bialix> I'm not sure how to deal with different PyQt versions whoes thouygh
[12:08] <bialix> igc: I guess 4.3
[12:08] <bialix> although in the README claims it should be 4.2
[12:08] <igc> bialix: cool, I was hoping it was at least that
[12:09] <bialix> we need to update this info
[12:09] <bialix> at least I can test and guarantee it works pretty well for 4.3.1
[12:10] <bialix> don't have 4.2.x installer and even don't have desire to go so far back
[12:11] <bialix> btw Ian, I think bzr explorer should invoke q-dialogs with --ui-mode flag
[12:11] <bialix> so user will see the result
[12:12] <bialix> although in this case user should explicitly close dialogs when operation successfully finished
[12:12] <igc> bialix - see bug 381161
[12:12] <igc> bialix: what exactluy is that flag?
[12:12] <igc> exactly
[12:12] <bialix> igc: this is private bug, I can't see it
[12:12] <igc> I've seen it around but haven't looked into it
[12:13] <bialix> igc: this flag was introduced for TortoiseBzr
[12:13] <igc> bialix: bug 385161 sorry
[12:13] <bialix> this flag force Close button for dialogs when operation finished successfully
[12:14] <igc> bialix: UUIIC, it ought to translate (layout wise) ok to OS X
[12:14] <bialix> without this flag q-dialogs close itself when operation finished
[12:14] <igc> bialix: do all qcommands support it?
[12:15] <bialix> we desperately needs mode dev docs for qbzr
[12:15] <bialix> no, unfortunate;y
[12:15] <bialix> no, unfortunately
[12:15] <igc> bialix: yes please
[12:15] <bialix> ask questions, and I'll try to write the docs
[12:15] <igc> bialix: no problem, I can use it for the ones that do at least
[12:16] <AfC> poolie: still up?
[12:17] <bialix> igc: can you make additional screenshot from Qt-Designer>
[12:17] <bialix> ?
[12:17] <bialix> I've got the idea
[12:17] <bialix> just want to see some more (internal) info
[12:18] <bialix> igc: what do you think about adding i18n for explorer?
[12:18] <bialix> I'd suggest to use qbzr approach. I think it's very close to ideal
[12:18] <igc> bialix: I really want it to see that happen
[12:19] <igc> bialix: I'm said to use LP for translations ...
[12:19] <bialix> so, just cherrypick qbzr/lib/i18n.py would be good start
[12:19] <igc> but I'm not sure what to do to seed the process to happen
[12:19] <igc> ok - I'll take a look
[12:19] <bialix> I manage current qbzr translations
[12:20] <bialix> I'll try to provide you the patch to compile pot
[12:20] <bialix> we have all this in qbzr
[12:20] <bialix> and it pretty reusable, IMO
[12:20] <bialix> also, what about adding 'explore' as alias to 'explorer' command?
[12:24] <igc> bialix: sure. Also bug 385161 now has Windows preview snapshot
[12:25] <igc> bialix: so if bzr 1.16rc ships late this week, what timeframe makes sense for a qbzr release?
[12:25] <bialix> thx
[12:26] <bialix> igc: I've released 0.10 recently
[12:26] <bialix> usually we release each months or so. from this period there is enough bugfixes and improvements
[12:27] <vila> and what improvements !
[12:27] <bialix> so, I'm doubt we need 0.11 next week.
[12:27] <bialix> only if there is something really Critical
[12:27] <igc> bialix: sure
[12:27] <bialix> you can bribe be of course ;-)
[12:27] <bialix> s/be/me/
[12:27] <igc> bialix: :-)
[12:28] <bialix> as vila said: hate when typo breaks good joke
[12:28] <vila> :-D
[12:28] <bialix> bonjour monsieur
[12:28] <vila> hi Alexander
[12:29] <bialix> igc: re qversion: do you prefer GroupBox, or just bold headings and indented bodies?
[12:30] <igc> bialix: group box. I'm thinking that the way OS X displays them will be nicer there and it doesn't matter a lot on other platforms
[12:30] <bialix> vila: does my greetings breaks french etiquette? I've read recently 'monsieur' is intended when somebody talks to person he is not very familiar
[12:31] <vila> bialix: That's right, 'Monsieur' is a bit formal
[12:32] <bialix> excuse moi s'il vous plait
[12:32] <vila> bialix: on the other hand, when speaking to friends or relatives, 'Monsieur' acquire an other meaning which is a bit aggressive :-)
[12:33] <bialix> aggressive?
[12:33] <vila> bialix: I'm perfectly aware that this is not your intent here :)
[12:33] <bialix> I'll be more careful
[12:33] <bialix> it's just sounds funny (a bit)
[12:34] <vila> yeah, like, when you argue with a friend and tone begins to warm, you may end up saying things like: "I know what I'm talking about, *me*, Monsieur" :-)
[12:34] <bialix> in the 18-19 centuries in Russian noble people used french instead of native Russian to talk each with other
[12:35] <lifeless> IIRC in england they used french
[12:35] <lifeless> as well
[12:35] <bialix> interesting
[12:35] <lifeless> again in the nobility for a relatively short time
[12:35] <vila> Yeah, you mean the ones that are known in France as "Les Russes Blancs" (White Russians)
[12:36] <vila> IIRC French was the international diplomatic  language at one point hence the *latin* expression lingua franca :-)
[12:36] <bialix> vila: I'm not sure
[12:36] <bialix> not sure about Russes Blanc
[12:37] <vila> bialix: You think it has another meaning ? For me it refers to noble expatriated Russian, I thought it matched
[12:37] <lifeless> vila: http://www.wikihow.com/Make-a-White-Russian
[12:37] <vila> lifeless: :-) Same name, yes
[12:37] <bialix> vila: no, I'm just never heard this nicks before
[12:38] <vila> bialix: ho, it may well be french-only :)
[12:38] <bialix> vila: I can think about people who ran away from Russia when there was Revolution (1917)
[12:39] <vila> yup, these ones
[12:39] <bialix> they called "white russains"
[12:39] <bialix> well, that's it
[12:39] <mwhudson> they were called white during the civil war too, right?
[12:39] <bialix> yes
[12:39] <bialix> bielogvardeitzy
[12:39] <bialix> this is how they in Russian
[12:40] <bialix> white guardians
[12:40] <vila> na gavariu pasrusky
[12:40] <bialix> correction: parusky
[12:41] <bialix> :-D
[12:41] <vila> rats ! That was a typo ! You mean the spelling is right ? That's the only russian sentence Valentine taught me :)
[12:41] <vila> Talk about typo ruining jokes :)
[12:41] <bialix> spelling is almost right
[12:42] <bialix> just thinking about I don't heard you
[12:43] <bialix> anyway I understand you
[12:43] <bialix> je ne parle pas in Francais
[12:43] <vila> I wrote it phonetically, with some google help it should be: na gavaru pa ruski, right ?
[12:43] <vila> je ne parle pas Fran,cais
[12:44] <bialix> well, 'na' -> 'ne' or 'neh'
[12:44] <bialix> gavaru -> gavaryu
[12:44] <bialix> pa -> po
[12:44] <bialix> otherwise it's very close :-D
[12:45] <vila> :-D Yeah, thanks google :)
[12:45] <vila> It should be written in cyrillic anyway
[12:46] <bialix> many people have to use latin keyboard
[12:46] <bialix> and thus we have latinica form for russian
[12:47] <bialix> so, people will understand this
[12:47] <vila> bialix: more seriously, I got another occurrence of pyQT4 not installed: in a setup where qbzr is installed but not PyQT4, 'bzr merge' was failing (instead of just refusing to load the plugin)
[12:47] <bialix> because qbzr override merge command with --qpreview flag
[12:47] <bialix> file a bug!
[12:48] <vila> k
[12:48] <bialix> it's critical enough
[12:49] <AfC> My understanding is that 1.15.1 has not been published. That correct?
[12:55] <AfC> I'll file these bugs on that assumption.
[13:03] <vila> BasicOSX: Do you plan to release 1.15.1 ?
[13:04] <vila> AfC: come back, the answer is not known yet ! :-/
[13:19] <vila> bialix: since you're there ! Can you subscribe me to the qbzr google group ? AFAICS invitations is the only way to come in :-/
[13:19] <vila> bialix: if possible use my '+lp' email
[13:22] <lifeless> bialix: if you want people to be able to apply, make it moderated not restricted
[13:27] <bialix> lifeless: we have 3 admins in qbzr@google
[13:28] <bialix> luks, garyvdm and me
[13:28] <vila> lifeless: Did you have some specifics in mind when you said "I'm not sure we've finished fixing the bugs from the bzrtools upgrade experiment either"
[13:28] <bialix> something has changed recently and it seems I'm not aware
[13:28] <bialix> vila: about PyQt dependency
[13:29] <bialix> vila: I'm not sure probing PyQt on every bzr ionvocation is right thing to do
[13:29] <bialix> it takes some time to import this library
[13:29] <vila> that's not what I suggested
[13:29] <vila> ha err, wait
[13:29] <bialix> so I'd rather fix the bug with merge, and not to change existing lazy load
[13:30] <lifeless> bialix: oh I"m talking about people being able to 'join' rather than 'be invited', not about who the admins are
[13:31] <bialix> lifeless: I'm sure qbzr group should not be SO restricted
[13:31] <vila> bialix: oook, I didn't realize the intent there... so yes if you lazy load, we'll have to continue the whack-a-mole game :)
[13:31] <bialix> whack-a-mole, gha!
[13:32] <vila> bialix: I never subscribe to a google group so far, so I may have misunderstood the process
[13:32] <bialix> vila: I've just subscribe my gmail account without any problems
[13:32] <vila> from where ?
[13:33] <bialix> http://groups.google.com/group/qbzr/subscribe?hl=en
[13:33] <bialix> do you have google account?
[13:33] <bialix> not necessary gmail
[13:34] <vila> ghaa, what did I try  last time to miss that 8-/ Ohhh, I wasn't connected (I connect only when *required*)
[13:34] <bialix> I can add you directly, but it's better to understand first what's going wrong
[13:34] <vila> bialix: my brain
[13:35] <bialix> no, I don't believe!
[13:35] <vila> bialix: and my will to use a non-gmail address
[13:35] <bialix> this is not problem
[13:35] <bialix> I've subscribed from my usual ukr.net mail
[13:36] <bialix> lifeless: we just using pre-moderation of emails from new members to deny the spam
[13:36] <bialix> otherwise the group is open to everyone'
[13:37] <lifeless> kk
[13:37] <vila> bialix: if I subscribe from my gmail account, I can't change the email to be used :-/
[13:37] <bialix> so don;t
[13:37] <bialix> subscribe from you free.fr mail
[13:38] <bialix> you need to create free google account for this mail. that's it
[13:38] <vila> bialix: I prefer to use a single mail (with the +lp suffix) for the all the bzr related communications
[13:39] <vila> otherwise yes, I would have created a dedicated qbzr address
[13:39] <bialix> I'm not sure I understand +lp
[13:41] <bialix> lifeless: who I should to poke to ensure russian translation will have a chance to be merged to 1.16?
[13:41] <asabil> jelmer: ping ?
[13:47] <vila> bialix: my email includes a '+lp' just before the '@' it's a suffix that is not part of the "real" mail but most smtp servers know about that and route the mails accordingly
[13:47] <bialix> vila: so you can filter the mail easily?
[13:47] <bialix> nice trick
[13:47] <vila> bialix: exactly and track who use which suffix without to create new emails
[13:48] <bialix> ok, I understand
[13:48] <vila> bialix: it works well for mailing lists, less so for web-based subscriptions because so many web devs know better and forbid '+' in emails :-/.
[13:48] <bialix> do you want me to try add you directly?
[13:48] <vila> bialix: yes please
[13:49] <bialix> Email subscription options  	
[13:49] <bialix> 	No email - Web-only participation
[13:49] <bialix> 	Send email for each message and update
[13:49] <bialix> 	One summary email a day
[13:49] <bialix> 	One email with all activity in it
[13:50] <bialix> what do you prefer?
[13:50] <vila> email for each message
[13:50] <spiv> vila: that's why I use - rather than + :)
[13:50] <spiv> bialix: to make sure it's in 1.16 the best thing to do it make sure the RM (jml) is aware of it, and you've already done that by replying to his 1.16 email
[13:51] <spiv> bialix: I'm sure jml won't mind if you ping him regularly to make sure, though :)
[13:51] <bialix> jml: :-)
[13:51] <bialix> vila: check mail
[13:51] <vila> spiv: huh ? And it works ? I thought smtp servers had to recognize it explicitely and every conf file I've seen for sendmail or postfix always use '+' and '+' only 8-)
[13:52] <vila> spiv: Or do you administer your own domain ?
[13:52] <spiv> bialix: the other thing you could do is file a bug and target it to the 1.16 milestone; perhaps jml will recommend that.
[13:52] <spiv> vila: I do (well, my wife does)
[13:52] <vila> spiv: lucky man ! His wife does....
[13:52]  * vila already administer too many family stuff :)
[13:53] <spiv> vila: I frankly don't know the first thing about postfix conf files, but happily I don't need to :)
[13:53] <vila> spiv: postfix is a breeze, sendmail on the other hand... :-)
[13:54]  * awilkins has learned something viz : the '+' thing
[13:55] <vila> awilkins: it also seems that spam harvesters don't like such emails ;)
[13:55] <awilkins> Or they just trim the suffix :-)
[13:56] <bialix> lifeless: still around?
[13:56] <vila> awilkins: surprisingly that seems too hard for them... I guess they have enough and don't need to dig more
[13:59]  * awilkins resolves to use "plussies" from now on
[14:00] <bialix> vila: do you receive welcome message?
[14:00] <spiv> Yeah, that's the problem with having lots of me-* aliases... I often get the same spam to every single alias.
[14:01] <lifeless> bialix: vaguely
[14:01] <vila> awilkins: what I mean is that I *never* receive spam on a '+' address and I don't receive a lot on the main one either (far less than the spam trap I created to get a reference point for example).
[14:02] <bialix> I have test script for bzr-search and it seems found the bug in bzrlib/btree_index.py as well
[14:02] <spiv> The usual spam filtering measures cut out the vast majority of them of course, it's just annoying for the ones that get through...
[14:02] <lifeless> bialix: is this you ? http://www.facebook.com/profile.php?id=1041185773
[14:03] <bialix> no, this is another man. I'm Belchenko, it's Boychenko
[14:05] <bialix> vila: it seems something wrong with google brilliant minds: http://groups.google.com/group/qbzr/search?q=author:v.ladeuil+lp@free.fr&hl=en
[14:05] <vila> bialix: %40 ftw
[14:06] <bialix> excuse moi?
[14:06] <awilkins> Escape the + char or it's a query operator
[14:06] <awilkins> ?
[14:07] <vila> bialix: oops, I meant %2B oof course :) http://www.google.fr/search?q=v.ladeuil%2Blp%40free.fr
[14:07] <bialix> I did not create the query by hands, as you understand
[14:07] <vila> bialix: aaah :)
[14:08] <bialix> so, I can try to subscribe you with %2b if you still did not receive welcome mail
[14:09] <lifeless> bialix: are you passing str or unicode to btree ?
[14:09] <lifeless> bialix: anyhow, hand the script to me and I'll play tomorrow
[14:09] <vila> bialix: welcome message just arrived, thanks !
[14:09] <lifeless> bialix: (facebook) - I thought it might be a transliteration thing.
[14:10] <bialix> lifeless: attached to bug report
[14:10] <bialix> but I can't reproduce it now
[14:11] <bialix> no, it's reproducible
[14:12] <vila> quantum bug for you, it's both reproducible and not reproducible :)
[14:12] <bialix> :-P
[14:13] <bialix> you need to pass both unicode and non-unicode strings in one list to trigger
[14:13] <guilhembi> Latest bzr.dev and latest bzr-gtk (dev branch) don't play together, in "bzr gannotate":
[14:13] <guilhembi> bzr: ERROR: exceptions.AttributeError: 'module' object has no attribute 'ProgressBarStack'
[14:13] <guilhembi> and a traceback...
[14:14] <vila> guilhembi: see bug #385191
[14:14] <vila> :-/
[14:14] <guilhembi> vila: thanks
[14:14] <bialix> lifeless: https://bugs.launchpad.net/bzr-search/+bug/383102 two bugs for you by money of one!
[14:16]  * awilkins particularly enjoys bugs that vanish when you aim a debugger at them
[14:16] <vila> awilkins: that's schrodinger bugs :)
[14:16] <lifeless> bialix: so u'foo' should be just 'foo'
[14:16] <awilkins> I thought it was Heisenbugs
[14:16] <lifeless> bialix: If we are going to be passing just str in
[14:17] <awilkins> A Schroedinger bug would be a bug which is in an indeterminate state until you exmaine it
[14:17] <bialix> well, we should do
[14:17] <bialix> you can ignore UnicodeDecodeError if you wish
[14:18] <vila> awilkins: you're both right and wrong: http://catb.org/jargon/html/S/schroedinbug.html
[14:19] <awilkins> Right about the debugger though http://catb.org/jargon/html/H/heisenbug.html
[14:19] <vila> awilkins: yup
[14:19] <lifeless> bialix: I'm assuming the CLI commands are broken, but won't fix until we have the API directly working for you in qbzr
[14:20] <bialix> lifeless: with my testing script I see that internal search engine unable to find russian text
[14:20] <bialix> I've also provided the patch for CLI
[14:20] <lifeless> yup, thanks
[14:20] <lifeless> just playing with the test branch now
[14:21] <bialix> I think you have to force check that query_list contains only plain strings
[14:21] <bialix> in your API
[14:21] <bialix> to avoid any unicode errors
[14:21] <lifeless> assuming thats the final outcome for sure
[14:29] <Mez>   Conflict: media.new is not a directory, but has files in it.  Created directory.
[14:29] <Mez>   Conflict: media.new is not a directory, but has files in it.  Created directory.
[14:30] <Mez> grr./..
[14:30] <Mez> what does that mean?
[14:30] <Mez> I'm pretty sure if it has files in it, it's a directory
[14:31] <awilkins> Are you on ReiserFS?
[14:31] <Mez> not that I know of
[14:32] <Mez> nope, ext3
[14:34] <awilkins> Maybe the other tree has a FILE called media.new
[14:34] <awilkins> And youi have a directory
[14:34] <awilkins> Or vice versa
[14:34] <awilkins> But I'm just guessing
[14:40] <lifeless> bialix: night
[14:40] <bialix> night
[14:40] <lifeless> bialix: I know its a index problem now
[14:41] <bialix> ok
[14:52] <jam> morning vila
[14:53] <jam> hey bialix, lifeless
[14:53] <jam> lifeless: what are you still doing up?
[14:53] <vila> jam: hey !
[14:53] <bialix> jam: !!!
[14:55] <guilhembi> vila: there are probably other problems: bzrlib.util.bencode moved to bzrlib.bencode in the latest bzr.dev,
[14:55] <guilhembi> so bzr-gtk code which does "from bzrlib.util import bencode" will fail, this impacts revisionview.py and commit.py.
[14:55] <guilhembi> vila: should I make a bug report?
[14:56] <vila> guilhembi: sure
[14:56] <guilhembi> Meanwhile I'm fixing our MySQL-internal plugin which uses bzrlib.util.bencode and broke too.
[14:56] <guilhembi> ok, filing
[14:59] <igc> bialix: any thoughts on bug 384988?
[15:02] <bialix> igc: I have no idea. I'd say PyQt/Qt should use native windows dialogs if possible, but I can't be 100% sure
[15:02] <bialix> so it's more PyQT bug
[15:04] <bialix> from PyQT help:
[15:05] <bialix> The easiest way to create a QFileDialog is to use the static functions. On Windows, these static functions will call the native Windows file dialog, and on Mac OS X these static function will call the native Mac OS X file dialog.
[15:05] <bialix> so, it seems like PyQt tries to call native dialog
[15:05] <bialix> at least it claims so
[15:06] <bialix> wait
[15:06] <bialix> from the PyQt help:
[15:07] <bialix>  QString dir = QFileDialog.getExistingDirectory(this, tr("Open Directory"),
[15:07] <bialix>                                                  "/home",
[15:07] <bialix>                                                  QFileDialog.ShowDirsOnly
[15:07] <bialix>                                                  | QFileDialog.DontResolveSymlinks);
[15:07] <bialix> look at the last argument
[15:07] <sidnei> hey vila, jam
[15:07] <jam> hi sidnei
[15:08] <bialix> igc: by default PyQt uses native dialog and symlinks should be resolved
[15:08] <sidnei> jam: i am planning to setup kerguelen as a buildbot slave, would that be ok?
[15:08] <jam> sidnei: seems fine to me, though getting Martin's ec2 instance might be better
[15:09] <jam> at a minimum, kerguelen has DNS issues
[15:09] <jam> (it doesn't resolve anything that I haven't put into 'hosts')
[15:09] <sidnei> jam: we punted on ec2, waiting for elmo to setup something in the dc
[15:09] <sidnei> (yes, i noticed the hosts thing :)
[15:10] <sidnei> jam: i thought the stuff in hosts was some attempt at preventing unwanted outbound connections, didn't know it was a real issue.
[15:11] <jam> sidnei: The hosts say "we have to completely rebuild the machine" to fix it
[15:11] <jam> so we said "screw it, will manage hosts"
[15:11] <jam> rather than re-install everything
[15:11] <igc> thanks bialix!
[15:11] <jam> sidnei: the other problem is that we are only allowed 2 "logins" to kerguelen
[15:12] <jam> I assume that a build bot needs to be running as a user
[15:12] <jam> so we would be down to 1 login
[15:12] <jam> which is probably enough, at least until someone forgets to log out
[15:12] <bialix> igc: I've re-read help one more time, and I'm sure it should works as any native application
[15:12] <sidnei> jam: it does, but it doesn't consume a login. it runs as a service user.
[15:12] <jam> k
[15:13] <jam> given that it is the machine where we currently build bzr, it certainly seems fine to make it a buildbot slave :)
[15:13] <sidnei> perfecto. now in search for a master. :)
[15:14] <sidnei> i think i will wait for the lp buildbot master to be moved in the dc too, hopefully that will make it easier. this is happening soon.
[15:18] <sidnei> jam: fyi, i have a buildout-based setup which can do a 'from scratch' build, downloading all of the svn, db4, libintl, tortoiseoverlays and unpacking them in the right location. just waiting on a bugfix to be merged to one of the recipes to put this through review.
[15:20] <jam> sidnei: interesting, especially given I have that in 'build_release.py' :)
[15:20] <jam> I didn't think we used db4
[15:20] <jam> do you mean bdb ?
[15:20] <sidnei> jam: yes, bdb. and yes, i saw build_release.py, and i think you will enjoy the new thing. it's less... convoluted. :)
[15:22] <jam> sidnei: perhaps. Some of the "convolution" is because of real-world issues I ran into.
[15:22] <jam> But hey, if you can get win32 to autobuild for me
[15:22] <jam> I certainly have no qualms with it :)
[15:23] <sidnei> jam: i've kept most if not all of the things from build-release, like getting trunk then branching from the tag, doing a build in the separate 'release' dir that gets blown away, etc.
[15:26] <vila> sidnei: I setup a buildbot master yesterday here, but 1) that's my first buildbot install ever, 2) It is accesible from my LAN only :-/
[15:26] <sidnei> vila: eh, thanks anyway ;)
[15:28] <vila> sidnei: I'm interested in your slave setup anyway :-) Especially if you handled installing twisted/buildbot on win32 (I used easy_install on OSX though)
[15:30] <sidnei> vila: there's some documentation over here: http://lists2.idyll.org/pipermail/pybots/2006-September/000098.html
[15:31] <visik7> under windows
[15:31] <visik7> .bazaar/plugins where is ?
[15:31] <vila> sidnei: why oh why such setups always end up being nightmarish :-)
[15:32] <sidnei> vila: it's not that hard actually, that was my first try. it is much simpler now. also, i was trying to build lxml which had many dependencies
[15:33] <vila> sidnei: yeah, kidding, only the second item in the list is relevant, in fact I think once the dev env is up, buildbot install shouldn't be a problem
[15:33] <sidnei> vila: correct.
[15:37] <bialix> visik7: see output of `bzr version`, line started with 'Bazaar conbfiguration'. This is the path to .bazaar on Windows
[15:38] <bialix> also you can use BZR_PLUGIN_PATH to override the default path
[15:38] <bialix> and there is C:\Program Files\Bazaar\plugins is you have installed bzr.exe in default location
[15:44] <vila> guilhembi: by the way, since bzr-gtk is currently broken, update qbzr and try qlog again, you should see that improvement in performance :)
[15:44] <vila> s/that/some/
[16:00] <guilhembi> vila: on a MySQL 6.0 branch, qlog took 12 secs to display the graph, now takes 10. It took 3 secs to expand a merge revision in the graph, now  takes 1. Good!
[16:00] <vila> guilhembi: and it consumes far less space too when you begin to open merge nodes
[16:01] <guilhembi> vila: what space? screen space?
[16:02] <vila> guilhembi: yes, it uses far less "columns" to display the graph
[16:06] <guilhembi> bbl
[16:27] <vila> huh, pushing to a local branch with a WT updates the WT *including* uncommitted changes ? Is it really the desired behaviour or a bug ?
[16:39] <awilkins> vila: Does it update the WT including the uncommitted changes that were already there? Or the changes from the source branch?
[16:39]  * awilkins tests
[16:45] <Kissaki> I checked out, and now I want to commit, for which I should require a username and password. On commit it does ask me for password, twice, but fails... (not for username
[16:45] <Kissaki> where/how can I specify login name?
[16:45] <awilkins> Kissaki: In authentication.conf
[16:45] <Kissaki> (using bzr with svn server)
[16:45] <awilkins> Kissaki: Ah
[16:46] <Kissaki> I managed to do it before, but don't remember how I did it...
[16:46] <awilkins> Kissaki: Might also help to do something requiring auth with the SVN client (like taking a lock and then releasing it)
[16:46] <awilkins> svn lock --username <url>
[16:47] <awilkins> svn lock --username <username> <url>
[16:47] <awilkins> Duh
[16:47] <awilkins> I'll forget my own head next
[16:47] <Kissaki> I don't have svn here
[16:47] <Kissaki> jut bzr :)
[16:52] <Kissaki> hm, it seems it could also be a problem with authserver...
[16:52] <awilkins> Kissaki: The other thing is that Bazaar doesn't cope with refusal well. Try prefixing your urls with svn+
[16:53] <awilkins> (Is it svn over http)?
[16:54] <Kissaki> yes
[16:55] <awilkins> Try the svn+ prefix
[16:55] <awilkins> Kissaki: Bazaar is probably asking for .bzr/smart URLS which the SVN WebDAV server will probably refuse to be nice about
[16:56] <awilkins> Anyway, time to go home
[16:56] <Kissaki> didn't use svn+ on the other one though
[17:16] <BasicOSX> morning (from the US) at least
[17:17] <BasicOSX> Any bzr-core people online? Any one going to address http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/58794 or just take it as someone venting?
[17:17] <bialix> jam: ping
[17:17] <bialix> not here
[17:18] <james_w> hey Bob
[17:18] <james_w> do you know why the files were missed from 1.15?
[17:20] <BasicOSX> james_w:  no, I cannot duplicate it either. Same pbuilder, same machine, same build procedure
[17:20] <james_w> odd
[17:21] <BasicOSX> james_w:  I will admit I stopped checking for them, since it was my understanding (wrongfully so) that a build would fail of the pyrex-ified files weren't created and that the .c files where going to be revisioned
[17:23] <vila> BasicOSX: hi Bob, did you planned to release a 1.15.1 ?
[17:23] <BasicOSX> RM is in an odd position. I can make releases every day, but there needs to be coordination between RM and dev, so I was going to push 1.15.1, but it was pointed out that bug 380314 should be rolled into 1.15.1, then I got busy at work.
[17:24] <vila> BasicOSX: yup, RM is an odd position :-)
[17:24] <BasicOSX> vila:  I hate being ask if I plan to do a release, much rather the position be bzr-core telling RM do a release
[17:25] <BasicOSX> as I said above, I can do releases everyday, but that's wasted work without bzr-core stating there's something new to release
[17:26] <BasicOSX> RM is ultimately grunt work, happy to do it, but when to do it is more of a bzr-core thing (imho)
[17:26] <james_w> I'm not so sure
[17:26] <vila> BasicOSX: That's just that *I* didn't closely follow what planned, I thought some bugfixes was targeted as 1.15.1 and then I understood at least one of them couldn't make it, and... then I thought I should check with you :)
[17:27] <james_w> in my experience an RM that pushes for releases with certain things is important for good quality
[17:27] <vila> BasicOSX: Also, being RM also implies you're the one to say *NO* to devs, who will always want to delay just to get that one last fix in
[17:27] <james_w> otherwise the developers will just tend to focus on the shiny
[17:28] <vila> BasicOSX: I had trouble with my mail client last week and lost track of some mails, but I thought spiv prepared a branch for meging in 1.15, cn't find the mail back though :-(
[17:29] <BasicOSX> hmm, in my professional career, that focus on release date is project manager (PM) roll. RM is rolling up the code for release.
[17:29] <BasicOSX> but point taken
[17:30] <BasicOSX> AS a developer in real life, I hate PM :-) because they are always taking away my shiny new play things :-P
[17:31] <vila> BasicOSX: yeah I know, things are a bit different here, PM is more the tie-breaker when devs can't agree, in professional carrer, PM is also responsible for the planning and distributing work, that can't work with a community
[17:32] <vila> so we end up in making the RM the human  gatekeeper for what goes into a release and the one that should respect the planning of time-based releases
[17:32] <Peng_> jelmer or beuno: ping
[17:33] <BasicOSX> There's a slice of volunteer time vs real world time in the RM roll too.  Andrew's comments on ML make it seem like RM is that is not volunteer. But I'm taking the comments personally as I'm RM right now.
[17:33] <vila> Of course that's an ideal definition and then we can still fight and drag the RM into discussions about how important this feature or that bugfix is sooo important that *he* should delay the release
[17:34] <vila> BasicOSX: Don't take it for you. Andrew is firing at the project not at the RM
[17:36] <vila> I think his main point is that we are making other packagers life harder. We still have work to do in that area to streamline the process.
[17:36] <BasicOSX> I know, been in the  FOSS world long enough to understand the personalities, still irritating to read a vent like that but not offering any constructive solution. Easy to vent. Hard to propose a solution.
[17:37] <vila> BasicOSX: And you helped a lot in that area by documenting all glitches you found, so focus on that: you did a great job, it's not finished nor perfect, so what ? :-)
[17:37] <beuno> Peng_, hi!
[17:39] <bialix> vila: re PyQt and merge bug. It's not clear how to separate PyQt from basic code. I have a fix for your problem, but we still will play whack-a-mole game with you. At least I'm trying to fix the bugs you found as fast as I can.
[17:40] <Peng_> beuno: Ah, hi. Um. The patch to __init__.py to only add loggerhead to sys.path if necessary broke "bzr serve --http" for me. Oddly, it successfully imports loggerhead.apps.transport, but that can't import loggerhead.apps.branch.
[17:40] <Peng_> beuno: (Well, I assume that's the patch that broke it.)
[17:40] <vila> bialix: I understand that, no problem, I'll keep thinking about it but unless we find a better implementation, let's continue that way, who knows, that may have been the last mole :)
[17:40] <beuno> Peng_, ah
[17:40] <Peng_> I guess I should file a bug. I dunno, it confused me enough that I wanted to discuss it.
[17:40] <beuno> Peng_, I don't quite know why
[17:41] <beuno> jelmer may know
[17:41] <beuno> I'd file a bug and assign it him
[17:41] <beuno> and run  :)
[17:41] <bialix> vila: this mole was born as result of massive refactoring made by Gary. So it's the last mole until we did next big refactoring ;-)
[17:41] <Peng_> beuno: I'll run and hide behind you. :P
[17:41] <vila> bialix: I hopefully inoculate him the test virus, so next refactoring may go better :-)
[17:42] <Peng_> beuno: Maybe I'll just CC him instead.
[17:42] <bialix> i.e. I don't expect it *the last one ever*
[17:42] <bialix> heh
[17:42]  * beuno runs off to lunch
[17:43] <vila> bialix: I know my setups are quite unusual anyway, qbzr but no PyQt and I appreciate your efforts to support it :)
[17:44] <bialix> well, usually your setup helps find easy bugs
[17:44] <bialix> so I'm fixing them for fun
[17:44] <vila> bialix: I'm slowing getting away from such plugin sharing between setups but I wish bzr-core has better support for activating/desactivating one plugin at a time
[17:44] <vila> bialix: hehe, always happy to help people have fun :)
[17:45] <bialix> between setups?
[17:45] <bialix> wdym?
[17:46] <bialix> do you know about BZR_PLUGIN_PATH env variable?
[17:46] <vila> depending on the machine I work on some ~/.bazaar directories are mounted via NFS so the plugins are installed once for say Ubuntu and OSX, and no PYQT on OSX for me so far :)
[17:47] <vila> Yeah I know about BZR_PLUGIN_PATH :)
[17:47] <vila> But most of the time I run into problems when trying to run the whole test suite *without* using --no-plugins (since that also desactivate the lp plugin for example)
[17:48] <vila> so I cd ~/.bazaar/plugins ; mv bogus DISABLED
[17:48] <vila> and I do mv DISABLED/bogus . when I need the plugin again :-/
[17:49] <bialix> but why you keep qbzr plugin without PyQt4 anyway?
[17:49] <vila> because I use it from the Ubuntu side where PyQT4 *is* installed
[17:50] <bialix> so, why not put qbzr in the ~/.bazaar/plugins/ubuntu-only and add this location to BZR_PLUGIN_PATH?
[17:51] <vila> bialix: Because I'm lazy ? :-) I'm going away from such sharing anyway
[17:51] <BasicOSX> boo on me for -not- listening to my latop when it said it was a reserve power!
[17:52] <vila> BasicOSX: :-D
[17:52] <vila> bialix: lib/subprocess.py use DOS line endings ?
[17:53] <bialix> vila: I'm not surprised about this
[17:53] <bialix> Gary used Windows a lot in the past
[17:53] <vila> bialix: ok, just wanted to make sure it wasn't some filtering leakage
[17:53] <bialix> don't blame me
[17:54] <vila> I don't blame anybody, my editor handle that fine :-)
[17:54] <bialix> you can try to find CRLF in some log*.py modules, I guess
[17:56] <bialix> vila: https://code.launchpad.net/~qbzr-dev/qbzr/bug-385177
[18:01] <vila> bialix: it works ! Thanks
[18:02] <bialix> np
[18:26] <BasicOSX> vila:  Ping? unusual problem, got time to look at it? http://pastebin.com/m788e3e2
[18:27] <BasicOSX> bzr push says "No new revisions" bzr submit to PQM says public branch is out of date
[18:29] <vila> BasicOSX: just wait a bit, it a mirroring delay, shouldn't exceed 10 minutes though
[18:29] <BasicOSX> hmm, never seen that when push to lp:
[18:29] <BasicOSX> I'll note it in doc
[18:30] <vila> BasicOSX: I almost *always* see it when issuing pqm-submit just after the commit
[18:30] <BasicOSX> I've seen it when http but not lp
[18:30] <vila> the mirroring occurs generally in less than 2/3 minutes
[18:34] <BasicOSX> push happened 12:26pm CDT, it's now 12:34pm, still getting error.
[18:36] <johnskulski> Hey, trying to get into bzr by checking out a svn project we have at work. I did a $ bzr branch file://var/svn/project and made my changes, i committed them but they do not show up in the svn repository (thought the commit is in the bzr log)
[18:37] <beuno> johnskulski, since you used "branch" instead of "checkout", you probably need to push your changes with "bzr push /var/svn/project"
[18:38] <vila> BasicOSX: you nearly got me there ! 1.15.1 not 1.15 check your public_branch setting :-)
[18:38] <johnskulski> beuno, yeah just pushed it. is 'checkout' provided by bzr-svn
[18:38] <beuno> johnskulski, nope, bzr
[18:38] <beuno> a checkout is bound to it's parent branch
[18:38] <beuno> and a branch is independant
[18:38]  * BasicOSX groans
[18:39] <beuno> johnskulski, so you can commit to a branch and push whenever you like
[18:40] <vila> BasicOSX: sorry about the misleading comment about mirroring delay :-/
[18:40] <johnskulski> beuno, i see. is this the command they talk about when saying bzr can support a centeralized workflow as well?
[18:40] <beuno> johnskulski, exactly
[18:40] <BasicOSX> totally my fault vila, cut-n-paste error
[18:41] <BasicOSX> I think I should change the release doc to force RM To put info into command line view locations.conf
[18:42] <johnskulski> beuno, and one more. the workflow for branched is 'commit' are 'saves for user' and then you push to some other branch, where as with centeralized checkouts, you commit --local to 'save for user' and then commit (no local) to commit for realz
[18:42] <beuno> johnskulski, you nailed it
[18:43] <johnskulski> great! thanks for the clarification beuno
[18:43] <beuno> johnskulski, happy to help. Let us knwo if you have any more questions
[18:44] <johnskulski> sure I willl, we're going ot be doing an svn to bzr migration at work later this year :-X
[18:44] <beuno> johnskulski, yay
[18:44] <beuno> johnskulski, be sure to add yourself to: http://bazaar-vcs.org/WhoUsesBzr
[18:45] <beuno> (if you're allowed to)
[18:45] <johnskulski> beuno, noted, thanks!
[19:17] <BasicOSX> Something wrong with PQM? Submitted, it played, no email response, pass or fail.
[19:32] <vila> BasicOSX: try replacing your lp: url by the http:  equivalent
[19:33] <vila> I heard spiv had some troubles with lp urls too recently
[19:36] <BasicOSX> :-(
[20:14] <bialix> vila: ping
[20:28] <stianse__> using the module filecmp from within a plugin works ok on linux but not on windows.
[20:28] <stianse__>  does python for windows come with its own python installation without the filecmp module?
[20:37] <bialix> are you using bzr.exe?
[20:38] <stianse__> yes
[20:39] <bialix> then it's possible this module is missed
[20:39] <bialix> which one plugin used this module?
[20:39] <sidnei> bialix is correct, since we use py2exe not all of the standard library is included
[20:40] <stianse__> bialix: a plugin i'm writing right now :)
[20:40] <bialix> so you have 2 choices:
[20:40] <stianse__> soon finished, just wanted to check if it worked on windows. it didn't.
[20:40] <bialix> 1) provide a copy of this module with your plugin (like qbzr does)
[20:41] <bialix> 2) copy this module to C:/Program Files/Bazaar/lib/library.zip
[20:42] <stianse__> bialix: I guess 1) is better since others probably will run into the same problem
[20:42] <bialix> you have 3rd option: file a bug and force bzr devs to include this module into bzr.exe for you
[20:42] <sidnei> i guess we could force py2exe into including more things into stdlib. not all things make sense though, like BaseHttpServer. or maybe it does *wink*
[20:43] <bialix> the patch is simple: lok at setup.py
[20:43] <sidnei> s/into/from
[20:43] <stianse__> bialix, sidnei: thanks, i think I will do both 1) and 3)
[20:43] <bialix> sidnei: yes, one can force py2exe to include more stuff than auto-detecting
[20:44] <sidnei> bialix: i know, just trying to think about how to draw the line
[20:44] <bialix> draw the line?
[20:44] <sidnei> one could argue that every module from stdlib should be included, if we are supporting plugins
[20:45] <sidnei> though some clearly do not make sense, at least right now
[20:45] <bialix> well, I'd prefer to improve this area on case-by-case approach
[20:45] <sidnei> sure, that works too :)
[20:46] <kenichi> hello, has anyone seen a problem where a commit to a branch (with >1k revisions in it) somehow sets the revno to 0?
[20:47] <bialix> at least for "default plugins" that shipped with td installer we force additional libs based on ModuleFinder
[20:47] <bialix> kenichi: no
[20:47] <LarstiQ> kenichi: yes, possibly
[20:47] <bialix> does log still works?
[20:47] <kenichi> a bzr log -l 10 shows logs for revnos 2, 1, 0, -1, -2 ... , -8.  googling "negative revno" returns nothing...
[20:48] <bialix> bzr reconcile
[20:48] <LarstiQ> kenichi: did you perform a merge prior to the commit?
[20:48] <bialix> may be it helps
[20:48] <kenichi> i'm still tracking down what exactly happened.  the committer is in hanoi, so ...
[20:49] <LarstiQ> kenichi: it sounds like : bzr init; bzr merge previous-work; bzr commit
[20:50] <LarstiQ> kenichi: so one question you could ask is how they started a local copy
[20:51] <LarstiQ> kenichi: if the answer is `bzr init` instead of `bzr branch` (or checkout/get/etc), you're on to something
[20:51] <kenichi> LarstiQ: yeah, that's the one way we came up with for this to happen.  but... i would think that the older 1000+ revs would be "sub-revisions" of the merge-in commit in that case, no?
[20:52] <LarstiQ> kenichi: indeed. I haven't seen this specific effect of negative revnos for a whole lot of releases.
[20:52] <LarstiQ> kenichi: which bzr versions are in play here?
[20:53] <kenichi> LarstiQ: the server on which this happened runs 1.10 (/me is not happy with that but is gated..), i'm waiting to hear version of the client.
[20:53]  * kenichi guesses ~1.13
[20:56] <LarstiQ> kenichi: hmm, I thought it didn't occur anymore at that time
[20:56] <LarstiQ> kenichi: is the project public? If so, could you make a tarball of it for analysis?
[20:57] <kenichi> LarstiQ: sorry, it is not.  Though if, in my investigations, i can replicate the results with a "test" repo, i glady would.
[20:57] <LarstiQ> kenichi: that's good too :)
[20:57] <LarstiQ> kenichi: anyway, to get out of it
[20:58] <LarstiQ> kenichi: given a messed up branch, I'd `bzr pull --overwrite -r revid:lastgoodbranchtip`
[20:58] <LarstiQ> well, depends on how much work was done on top of that
[20:58] <bialix_> LarstiQ: IIRC there was attempt to teach bzr reconcile fix incorrect revno
[20:59] <bialix_> kenichi: can you make a copy of your broken branch and run reconcile there?
[20:59] <LarstiQ> bialix_: ah
[20:59] <kenichi> LarstiQ: thanks, that is similar to what we did: pulled each rev-id to another local work branch, then push --overwrite to the mainline.
[20:59] <LarstiQ> kenichi: I forgot a . in that
[20:59] <LarstiQ> kenichi: right
[21:00] <LarstiQ> kenichi: `bzr pull . --overwrite -r revid:lastgoodbranchtip`
[21:00] <kenichi> bialix_: i have a tarball of the whole repos.  i'll give it a go.
[21:00] <kenichi> (in it's fubared state)
[21:00] <kenichi> s/it's/its/
[21:01] <LarstiQ> kenichi: good
[21:01]  * LarstiQ looks up which tram to take home
[21:01] <kenichi> "Fixing last revision info 2 => 1127" looks promising :)
[21:03] <bialix_> :-)\
[21:05]  * LarstiQ detaches and goes home
[21:05] <LarstiQ> kenichi: cool :)
[21:12] <kenichi> bialix_: it is taking quite a while, "Calculating text parents 26850/39745"...  sound normal?  a co-worker is running 'bzr check -v' on his own copy of the fubared repos; said it's been going for hours.
[21:12] <bialix_> perhaps
[21:13] <bialix_> bzr check is known to be very slooooooooooooooooooooooow
[21:20] <kenichi> LarstiQ: can you elaborate on when you *did see* the negative revno effect before?
[21:21] <bialix_> kenichi: he's going home
[21:33]  * bialix_ summons vila
[21:40] <mwhudson> jelmer: hi
[21:46] <sevenseeker> I have a remote machine I would like to push a branch to, can I do that (it is running 'bzr serve')
[21:48] <Gnx-> so anybody have any thoughts on how I could force a file to be always overwritten when pushing/pulling?
[21:48] <Peng_> sevenseeker: You should use bzr+ssh. If the server has bzr installed, and you have SSH access, it should work automagically.
[21:48] <Peng_> sevenseeker: It's possible to enable pushing to bzr://, but it doesn't support auth, so anyone could do whatever they wanted.
[21:51] <sevenseeker> Peng_: We use keys for entry via ssh (ssh -i foo) how can I utilize this with bzr+ssh?
[21:55] <Peng_> sevenseeker: It'll work automagically.
[21:55] <Peng_> sevenseeker: Unless you actually have to pass arguments to ssh, but that's dumb.
[21:56]  * Peng_ /away!
[21:59] <sevenseeker> Peng: thanks, are you saying that I can pass '-i' to bzr I am not sure I understand what 'automagically' means in this context.  e.g. ssh -i pubkey foo@foo.com --> bzr push -i pubkey bzr+ssh://foo@foo.com/spambranch
[22:00] <beuno> sevenseeker, it should search for your pubkey automatically
[22:01] <sevenseeker> beuno: thanks, search by name or just try until it succeeds?
[22:01] <sevenseeker> sorry for silly questions
[22:02] <beuno> sevenseeker, I suppose it does whatever ssh does
[22:02] <beuno> don't know the details to be honest
[22:02] <beuno> vila may, but he's probably not around
[22:02] <sevenseeker> ok, I only grok enough to be dangerous about ssh :)
[22:03] <beuno> same here  :)
[23:07] <BasicOSX> Got reverse-bitten by sync bug now too. lp:/bzr/bzr.1.15 doesn't have my changes
[23:19] <jml> james_w: new nightlies! wooooo!
[23:19] <james_w> at last! :-)
[23:23] <BasicOSX> Someone do me fav and QA the bzr-1.15.1 tar and zip at ftp://ftp.real-timecom/pub/bzr ? Just want second set of eyes looking at them for pyrex-ifed files before going public. Thanks.
[23:32] <jml> mwhudson, lifeless: I'll be back a bit later, then we can talk about the hpss stacking issue maybe?
[23:33] <mwhudson> jml: sure
[23:33] <jml> BasicOSX: ... and if no one else has done so, I can QA those when I get back too.
[23:38] <mwhudson> lifeless: can you tell me what "cache oblivious" means in a short sentence?
[23:38] <mwhudson> oh nm, wikipedia has an article
[23:50] <poolie> hello all
[23:51] <poolie> hi beuno
[23:59] <lifeless> mwhudson: maximising cache performance in algorithm design without cache size parameters
[23:59] <mwhudson> right