[00:45]  * SamB gripes about bzr viz not being able to run from a repo ...
[00:50] <jelmer> lifeless: will iter_changes() yield unchanged parent directories of changed files
[00:59] <lifeless> jelmer: look for use_record_iter in commit.py
[01:03] <lifeless> james_w: ping
[01:03] <james_w> hey lifeless
[01:03] <lifeless> james_w: can I get you to debug the stacking bug you stuffered?
[01:03] <james_w> sure
[01:04] <lifeless> look at rev 4174
[01:04] <lifeless> it has the last change to this
[01:04] <lifeless> and a test
[01:04] <lifeless> pdb somewhere in its new code should help isolate whats going on
[01:04] <spiv> lifeless: you're welcome to come up here today.
[01:05] <lifeless> spiv: ok, I'll head up shortly then if thats ok; we've got a lot to get across :)
[01:05] <james_w> ah, that sort of debugging :-)
[01:06] <lifeless> james_w: yes :)
[01:06] <james_w> tomorrow then I feel
[01:06] <spiv> lifeless: sure.
[01:06] <lifeless> ok
[01:07] <lifeless> james_w: please attach bzr info -v of your source branch then
[01:07] <lifeless> james_w: as well as checking you did push with a bzr >> 4174
[01:16] <pygi> is there any docs for nested branches support?
[01:20] <jelmer> lifeless: well, I'm almost done implementing record_iter_changes
[01:21] <jelmer> lifeless: is iter_changes() O(delta) or O(tree) on bbc trees?
[01:24] <lifeless> jelmer: working tree is O(tree), revision trees are a function of delta size and log(tree)
[01:24] <lifeless> -> train to spivs, online again in ~40
[01:41] <thewrath> hello all
[01:59] <lifeless> jelmer: back
[02:53] <jelmer> lifeless: IIUC iter_changes does depth-first search based on the target tree?
[02:53] <jelmer> so if I see a directory is being processed and then see some sibling is being processed I can assume that directory is "done" ?
[03:34] <lifeless> jelmer: I wouldn't make that assumption
[03:34] <lifeless> jelmer: because it can jump around with renames and stuff
[03:34] <lifeless> it might start with one file in a dir, then subdirs, siblings, then find that the dir was reparented and include the parent
[06:30] <BasicOSX> lifeless:  just came here to report the stacking issue, but I see you are on it, I was just about to upload 1.14rc1, I can wait if bug 354036 fix is close
[06:36] <lifeless> BasicOSX: we're getting close, I'm landing the last bits of brisbane-core at the moment too
[06:38] <BasicOSX> we are all good then, was working vila  osx patches and Ian's filter registration patch, so I can hold off until that lands
[06:38] <lifeless> BasicOSX: cool
[06:50] <Peng_> BasicOSX: Are you planning to merge the RemoteBranchConfig stuff from r4251 of bzr.dev into 1.14?
[06:51] <BasicOSX> Peng:  no one specifically requested that
[06:51] <Peng_> Eh.
[06:52] <Peng_> lifeless: ^^ Did you want that for 1.14?
[06:54] <lifeless> BasicOSX: Oh, I thought I did
[06:54] <lifeless> BasicOSX: in my mail about it to the list, I noted that it fixes a regression vs 1.13
[06:57] <BasicOSX> hmm, only merge requests I see are the osx test failures and the simplify the content filter registration API
[06:57] <BasicOSX> well, and bug 354036
[06:58] <lifeless> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C49D53C9C.2070200%40mattnordhoff.com%3E
[06:58] <lifeless> actually thats not the one
[07:01] <lifeless> BasicOSX: its rev 4251 of bzr.dev
[07:01] <lifeless> I'll send a mail now
[07:01] <vila> hi all
[07:01] <Peng_> vila: Hello
[07:01] <BasicOSX> lifeless:  got that,   (robertc) Fix handling of fallback repositories some more, just cannot find request to cherry pick it (hello vila)
[07:02] <lifeless> BasicOSX: I've just sent one to the list
[07:03] <vila> BasicOSX: That was the purpose of lp:~vila/bzr/1.14
[07:03] <BasicOSX> I apologize if I missed the initial request... oh, wait
[07:04] <BasicOSX> info overload lately trying to weed through the 1.14 RC date thread :-(
[07:04] <lifeless> :P
[07:04] <vila> BasicOSX: np, that's what teams are for :)
[07:04] <lifeless> if I can ask a small favour
[07:04] <lifeless> please leave pqm clear for thie next cole of hours, I'm trying to land all of brisbane core
[07:04] <BasicOSX> np
[07:05] <lifeless> and finding gaps in e.g. python2.4 support for it
[07:05] <lifeless> which are trivialish but a round trip to fix
[07:05] <Peng_> lifeless: All of it? Like, "bzr merge ../brisbane-core"?
[07:05] <vila> lifeless: fwiw, full test suite passed for python2.[456] here
[07:06] <lifeless> Peng_: well no, I'm not planning on do that at all
[07:07] <lifeless> Peng_: but do the point there is nothing we want to land
[07:07] <lifeless> vila: check the _chk_map.pyx and _groupcompress.pyx files :)
[07:07] <lifeless> vila: _chk_map is in .dev, groupcompress in p.u.c/~robertc/baz2.0/integration
[07:10] <Peng_> lifeless: Oh. Well, congrats. :)
[07:10] <lifeless> groupcompress up to ascii :)
[07:10] <BasicOSX> lifeless:  sorry to pester, but did you find the initial request to merge fallback repositories stuff? I would like to know so I can attempt to fix the holes in my tracking of merge requests.
[07:12] <lifeless> BasicOSX: I haven't kept looking
[07:12] <BasicOSX> np
[07:12] <lifeless> BasicOSX: the fallback repositories stuff was fallout exposed by fixing the config stuff
[07:12] <lifeless> the branch was about configs
[07:12] <vila> BasicOSX: I'm not sure there was one, but as I was bitten by #354036, I merged it and prepare the branch for you to merge
[07:12] <vila> BasicOSX: I'm not sure there was one, but as I was bitten by #354036, I merged it *in bzr.dev* and prepare the branch for you to merge in 1.14
[07:13]  * BasicOSX groans 
[07:14] <lifeless> bug 354036
[07:14] <BasicOSX> Getting 354036 issue
[07:14] <lifeless> bug 354036
[07:14] <lifeless> vila: thats a different bug ;)
[07:14] <vila> grr
[07:15] <lifeless> vila: so have we fixed --parallel ?
[07:16] <BasicOSX> Peng:  thanks for the catch on the missed merge
[07:17] <vila> then #354075 fixed by matt, merged by lifeless in his 'Fix handling of fallback repositories some more' patch
[07:17] <BasicOSX> should the http transport for vila's 1.14 branch work (pass the smart server code)?
[07:17] <vila> lifeless: --parallel works great here
[07:18] <vila> lifeless: but you mentioned problems with ec2 ?
[07:19] <BasicOSX> http worked :-)
[07:19] <vila> BasicOSX: you mean for pqm submissions ?
[07:19] <lifeless> vila: yes
[07:19] <BasicOSX> no, to merge your code into my prepare-1.14rc1 (lifeless  requested I stay out of PQM for a couple hours)
[07:19] <lifeless> BasicOSX: http doesn't trigger the problem
[07:20] <lifeless> BasicOSX: oh, you can merge from lp all you want, just don't run bzr pqm-submit :)
[07:20] <lifeless> vila: give ec2test a spin, you'll see
[07:20] <lifeless> FAIL: test_merge.TestMergerEntriesLCA.test_one_lca_supersedes_path
[07:20] <lifeless>     RemoteException: Traceback (most recent call last):
[07:20] <lifeless>   File "/home/bzrtest/test_branch/bzrlib/tests/test_merge.py", line 1598, in test_one_lca_supersedes_path
[07:20] <lifeless>     self.assertEqual, [], list(merge_obj._entries_lca()))
[07:20] <lifeless>   File "/home/bzrtest/test_branch/bzrlib/tests/__init__.py", line 1055, in expectFailure
[07:20] <lifeless>     raise KnownFailure(reason)
[07:20] <lifeless> KnownFailure: We don't do an actual heads() check on lca values, or use the per-attribute graph
[07:20] <BasicOSX> lp = smart server
[07:20] <BasicOSX> ?
[07:20] <vila> lifeless, BasicOSX : Someone else than *me* triggers the lp/pqm bug ? Hurrah ! Not jinxed anymore !
[07:20] <lifeless> still
[07:21] <lifeless> BasicOSX: lp: urls reoslve to using bzr+ssh and thus a smart server
[07:21] <vila> lifeless: I can't do that, I don't have access to ec2, not even sure I can find boto module ?
[07:21] <BasicOSX> yep, and I'm getting bit but the smart server bug, so I just got vila's patch via http
[07:22] <lifeless> BasicOSX: oh right, I'm synced() now :)
[07:22] <lifeless> vila: sign up :)
[07:22] <lifeless> vila: see the company cloud computing policy in the all hands list archives
[07:24] <vila> lifeless: I'll look
[07:25] <vila> By the way, it seems that we have more "warnings.warn("%r was gc'd while locked" % self.repr)" these days nist of them (if not all, involving a LockableFiles(<bzrlib.transport.remote.RemoteTCPTransport url=bzr://127.0.0.1:33810 blah blah), does that ring someone's bell ¿
[07:25] <vila> gee how did I type that reverse ?
[07:26] <BasicOSX> heh
[07:53] <lifeless> -> home, groupcompress has landed, I'll be landing the remaining bits very soon.
[07:53] <lifeless> well, ->home shortly
[08:24] <lifeless> vila: the answer btw to InterCHKRevisionTree is s/development5/development/
[08:24] <lifeless> vila: found the ec2 doc stuff?
[08:25] <lifeless> -> home now
[08:42] <vila> lifeless: I need to find what login/pass I should use to access allhands archive first :-(
[08:49] <fullermd> Well, if it's allhands, I presume you need a fingerprint rather than a password   8-}
[08:51] <vila> time to upgrade ff then :)
[09:06] <lifeless> BasicOSX: around?
[09:11] <igc> lifeless: thanks for landing that stuff today
[09:12]  * igc dinner - bbl
[09:48] <vila> lifeless: still around ?
[09:50] <vila> I'd still prefer to run locally (for many reasons including ease of debugging). So my question is: do you feel that the problem you encounter is related to the tests protocols rather than any ec2 specific reason ?
[09:52] <vila> lifeless: by 'locally' I mean connecting via ssh in my LAN to get a close-enough approximation of course
[09:53] <vila> lifeless: and also because that's a setup I want to be able to use from my laptop to my "data center" :-)
[10:48] <lifeless> igc: nearly done
[10:48] <lifeless> vila: yes, I'm around
[10:49] <lifeless> vila: I would like it if you were familiar enough with bzr-ec2test to debug problems when it is used
[10:49] <lifeless> vila: thus, I plan to drag you kicking and screaming through it once :)
[10:51] <vila> lifeless: ha, I thought so but was unsure :-)
[10:53] <lifeless> vila: concretely it is failing to de-and-re serialise from ec2
[10:53] <lifeless> which I haven't had time to debug myself test.
[10:54] <vila> lifeless: so it's not directly related to my last patch (as in, it was failing before ?)
[10:54] <lifeless> I think so
[10:54] <lifeless> :)
[10:54] <vila> devil :)
[10:56] <lifeless> well
[10:56] <lifeless> I figure a little latitude is due, for doing the heavy lifting to get you your desired parallel suite :)
[10:57] <lifeless> vila: I have a separate favour for you to do though, and this is rather more important. I'm about to land --development6-rich-root
[10:57] <vila> huh ? We still separate rich-root ?
[10:58] <lifeless> its the only one
[10:58] <lifeless> no dev6
[10:58] <lifeless> and aaron has said subtrees need more stuff so leaving out for now
[10:58] <vila> ha, to underlined that it *is* rich root
[10:58] <lifeless> yes
[10:58] <vila> ok
[10:58] <lifeless> *do-not* want random upgrades and folk having deep troubles
[10:59]  * awilkins applauds the lack of not-rich-root
[10:59] <vila> Didn't we say we'll call it --dev6-rich-root-eat-your-dog ?
[11:00] <awilkins> --dev6-rich-root-cat-taxidermist  ?
[11:00] <vila> anyway, what favour ? (The more you wait to ask, the bigger is should be, the more I'm frighten :)
[11:00] <vila> awilkins: don't touch cats
[11:00] <awilkins> Toxoplasmosis?
[11:03] <lifeless> vila: merge all the components of brisbane-core from bzr.dev to a single branch and then that into 1.14/get BasicOSX to merge it into 1.14
[11:03] <lifeless> vila: *note* I *have not* and do *not intend* to merge the brisbane-core branch directly.
[11:03] <lifeless> vila: it has content we don't want to land in bzr.dev at this point.
[11:04] <vila> lifeless: right, so cherry pick from bzr.dev ok. Two things,
[11:04] <Peng_> The sucky thing about not having a non-rich-root format is that the Big Rich Root Transition will have to take place before I can use it locally on most projects. :\
[11:05] <vila> lifeless: Do you have some reference branch I can use for verification purposes (though one)
[11:05] <vila> lifeless: two: that means losing the annotations or did your (and Ian's) submissions somehow preserve them ?
[11:06] <vila> lifeless: if answer to two is yes, don't bother explaining, I can understand why, just want to be clear
[11:06] <awilkins> What exactly is the reason for things not being bi-directionally compatible with rich-root?
[11:06] <bob2> why aren't floats bidirectionally compatible with ints?
[11:07] <awilkins> That isn't "exactly"
[11:07] <bob2> rich-root has data non-rich-root can't represent
[11:07] <awilkins> Yes, but what is it?
[11:07] <vila> awilkins: root data :)
[11:07] <awilkins> Ginger? Valerian?
[11:07] <vila> awilkins: that data makes root rich
[11:07] <bob2> an id for the root directory of a branch
[11:09] <lifeless> vila: they are gone, we have used --author
[11:09] <lifeless> awilkins: and versioning of the root
[11:10] <lifeless> awilkins: which we use in a number of merge corner cases, and for nested trees.
[11:11] <awilkins> The band-aid needs to be ripped off!  .... of course, it doesn't matter much to me, the majority of branches I use are rich-root so I can keep my manager happy with svn commits
[11:13] <lifeless> vila: btw its 120 seconds for me to run the test suite with 2 ec2 instances
[11:14] <vila> lifeless: right so, from bzr.dev log that means revnos 4262 4261 4260 4259 4254 4248 4247 4246 4245? 4244 4243 and the one where you land the --dev6 format ?
[11:14] <vila> lifeless: 120... hmpf
[11:14] <vila> lifeless: that doesn't include bzr-loom of course :-)
[11:36] <lifeless> igc: ping
[11:53]  * lifeless tapdances on igc's toes
[12:11] <lifeless> vila: it passed tests in bzr.dev because many tests were not running for it
[12:12] <lifeless> vila: grab my integration branch if you want to see it blow up ;)
[12:12] <vila> lifeless: errr, context ? ec2 ? bbc ?
[12:13] <igc> lifeless: here to help - which branch should I grab?
[12:15] <lifeless> igc: my integration branch
[12:15] <lifeless> vila: bbc
[12:16] <lifeless> igc: if you run bzrlib.tests.workingtree_implementations.test_eol_conversion.TestEolConversion.test_eol_native_with_crlf_i
[12:16] <lifeless> for selftest
[12:16] <lifeless> it should fail with a clearly wrong line ending
[12:16] <lifeless> I see
[12:16] <lifeless> AssertionError: not equal:
[12:16] <lifeless> a = 'hello\r\nworld\r\n'
[12:16] <lifeless> b = 'hello\nworld\r\n'
[12:16] <lifeless> for instance
[12:17] <lifeless> give me a clear pointer at whats likely wrong and I'll happily fix. right now I'm fixing real issues with tests that were incorrectly not enabled in bbc that became clear as I did the integration
[12:17] <lifeless> s/real/other real/
[12:19] <igc> lifeless: grabing the branch now. The code on lp is up to 4248 and due for mirroring again in 2 hours so I can't just use loggerhead there
[12:23] <lifeless> igc: sorry yes :)
[12:23] <lifeless> igc: regardless loggerhead wouldn't help you I don't think
[12:23] <igc> np - it's down now
[12:23] <lifeless> so, found an issue with labels
[12:23] <lifeless> without labels in the pack
[12:25] <lifeless> two packs with different content can then collide, but the indices are no longer equivalnet
[12:25] <lifeless> [tests fail]
[12:26] <igc> lifeless: ./bzr selftest TestEolConversion --no-plugins -1 passes for me
[12:26] <igc> on 4249
[12:26] <igc> of your integration branch
[12:26] <igc> hmm
[12:26] <lifeless> set LANG=C
[12:26] <ronny> hmm
[12:27] <ronny> sadly bzr is the only vcs that has merge instead of pull if the remote diverged
[12:28] <bob2> 'has'?  you can merge in git in that situation (after fetching)
[12:29] <igc> ronny: try bzr merge --pull
[12:30] <ronny> hg and git allow me to pull first, merge later
[12:31] <bob2> you can bzr pull to your local mirror of that branch (and if it is in a repository with your branches, it is space efficient)
[12:31] <lifeless> ronny: bzr can do that too, via fetch
[12:31] <bob2> bzr's mass branch management is a bit lacking alas
[12:32] <ronny> lifeless: so fetch pulls a dangling head into the backing repo?
[12:32] <igc> lifeless: setting LANG=C doesn't break things for me
[12:32] <ronny> hmm
[12:32] <igc> I'll try a wider set of tests
[12:33] <ronny> i love how this shit differs - in hg/mtn pull is history sync, in bzr/git it has some merge potential (and bzr is the one that needs explicit merge)
[12:36] <ronny> lifeless: will the fetched remote data get any special marker other than showing up in the heads?
[12:36] <lifeless> igc: interesting
[12:36] <lifeless> ronny: no
[12:36] <igc> lifeless: so the filtered views tests are failing for me cause you deleted development-wt6 - trying them now with development-wt6-rich-rott
[12:37] <igc> roo
[12:37] <igc> root
[12:37] <lifeless> igc: yes,they are passing for me
[12:37] <lifeless> I have some uncommitted fixes fixing most of the tests
[12:37] <igc> it needs to go as well and be replaced with you new format
[12:41] <igc> lifeless: so filtered view tests pass on development6-rich-root, development-wt6-rich-root needs deletion if you haven't done it already
[12:42] <lifeless> igc: yes, done
[12:43] <igc> lifeless: did you try --no-plugins?
[12:43] <jelmer> hey lifeless, igc
[12:43] <igc> hi jelmer
[12:43] <jelmer> vila: ping
[12:44] <jelmer> vila: You mentioned using factory.stdin.getvalue() in your review
[12:44] <jelmer> vila: but the rest of the file also uses factory.stdin.readline() and the main point is checking the position of the stream
[12:47] <igc> lifeless: if you put the output from bzr diff in a pastebin, I'll apply that and run the tests again
[12:47] <vila> jelmer: I think the comment says: ensures stdin is empty no ? Oops, no, the previous test is with a non-empty stdin, sorry, forget that remark then
[12:49] <jelmer> vila: ok, just making sure I wasn't missing anything. Thanks again for reviewing, I've fixed the other issues.
[12:49] <lifeless> igc: sure, one sec
[13:00] <lifeless> http://paste.ubuntu.com/146177/
[13:00] <lifeless> sorry, phone call
[13:04] <lifeless> igc: ^
[13:04] <lifeless> igc: I'm going to recommit in a minute, as I had to back out some of the cleanup
[13:04] <lifeless> and try it again
[13:21] <lifeless> ok ec2testing
[13:21] <lifeless> igc: if it fails on the NoEol stuff, I'm going to shove it a pqm
[13:21] <lifeless> I think it might be me ;)
[13:22] <igc> lifeless: might be. bzr selftest eol filter --no-plugins -1 works fine for me with your patch ..
[13:23] <igc> and visually inspecting it, it looks fine
[13:23] <lifeless> igc: yea,  I can't see anything in this breaking it :(
[13:23] <igc> I got out of bed to help so I'll head back there now
[13:23] <lifeless> igc: I'm so sorry
[13:23] <lifeless> igc: where should I look if it still breaks
[13:23] <igc> lifeless: np. email me if there's still an issue and I'll look into it first thing
[13:24] <lifeless> I'm staying up till this is landed
[13:24] <lifeless> I don't need you to fix it, just to point me at the code areas that are potentially implicated
[13:24] <igc> well bzrlib/filters/eol.py is the starting point
[13:24] <igc> beyond that, it depends
[13:25] <igc> sorry - that's not much of an answer
[13:25] <lifeless> thats ok
[13:25] <lifeless> I will follow my nose as needed
[13:25] <lifeless> sleep well, and sorry again
[13:26] <igc> lifeless: good luck and I'll possibly be up early - hard to tell as the chemo makes me very both very sleepy and very awake depending on god knows what
[13:26] <igc> so please email any issues
[13:26] <igc> night all
[13:28] <lifeless> will do
[13:32] <lifeless> bombs away
[13:56] <vila> lifeless: your pending submission in pqm is the last I should backport to 1.14 right ? (It passes tests here)
[13:56] <lifeless> yes
[14:02] <jelmer> vila: I'm wondering what to do with smtp as the current implementation asks pre-emptively
[14:04] <jelmer> vila: ideally we wouldn't always be doing that but only in the cases where the server requires us to
[14:04] <jelmer> vila: but that seems impractical (impossible?) for smtp
[14:05] <vila> jelmer: smtp starts by using its own smtp_username and smtp_password config options, I'd say it should use authentication.conf instead
[14:06] <vila> jelmer: iow, out of scope for your fix IMHO
[14:06] <jelmer> vila: the problem is get_user() will now return getpass.getuser() rather than None if there's no user configured in authentication.conf
[14:06] <jelmer> vila: and previously it would skip authentication if None was returned
[14:06] <lifeless> jelmer: can I ask a favour?
[14:07] <jelmer> lifeless: you can always ask :-)
[14:07] <lifeless> jelmer: ... say yes to my next request
[14:07] <lifeless> jelmer: may I kill your pqm job, its 11PM, want to land development6 and sleep
[14:07] <jelmer> lifeless: sure, go ahead
[14:08] <lifeless> tanks
[14:13] <jelmer> lifeless: please let me know when yours is done so I can requeue mine
[14:14] <vila> jelmer: I'm pretty sure lifeless will be asleep when pqm lands its patch :) But nothing forbids you to queue now, I think that was the last missing patch
[14:14] <lifeless> vila: I will be awake till it lands
[14:14] <vila> lifeless: sorry no offense intended :)
[14:15] <lifeless> vila: only way to be sure
[14:15] <lifeless> non taken
[14:15] <vila> lifeless: good ! So you may have a look at lp:~vila/bzr/bcc-1.14 and tell me if everything looks fine so far
[14:15] <vila> :)
[14:16] <vila> lp:~vila/bzr/bbc-1.14 of course
[14:16] <lifeless> to your list above
[14:16] <lifeless> 4257
[14:16] <vila> indeed, just merged it
[14:17] <jelmer> vila: any idea about smtp?
[14:17] <vila> lifeless: errr, was about to merge it (not pushed)
[14:17] <lifeless> :)
[14:18] <jelmer> vila: I could add a "return_non_if_default" boolean parameter but that just seems plain wrong
[14:18] <vila> jelmer: consistency is good, I think smtp should align to either http or getpass.getuser()
[14:19] <jelmer> vila: but the new behaviour makes unauthenticated smtp impossible
[14:19] <jelmer> as get_user() will never return None
[14:21] <jelmer> lifeless: I just got a "success" message from PQM and my branch was merged
[14:21] <lifeless> jelmer: odd...
[14:21] <vila> jelmer: unauthenticated http is possible, do the same :-)
[14:22] <jelmer> vila: yes, but in the case of http we only ask after the remote host gives a "Permission denied"
[14:22] <vila> jelmer: sure, I was trying to get some time to think :)
[14:22] <awilkins> jelmer: That reminds me about svn+ prefixes
[14:23] <jelmer> vila: :-)
[14:23] <jelmer> awilkins: what about them?
[14:24] <awilkins> jelmer: I seem to think that if your web server refuses access to the locations that bzr probes to determine whether a web server is a repo, things just stop
[14:24] <awilkins> I should make a more coherent report
[14:26] <vila> jelmer: so smtp._authenticate() says: """If necessary authenticate yourself to the server.""", so there should be a way to find if auth is necessary
[14:26] <vila> In the worst case it means: try to send, catch auth error, authenticate, send
[14:26] <vila> there is smtplib.SMTPAuthenticationError ....
[14:27] <vila> ... whose doc string says " Most probably the server didn't accept the username/password"... I love the most probably part :-/
[14:28] <jelmer> vila: yeah, SMTP sucks
[14:28] <vila> jelmer: probably smtp servers requiring auth suck less :-)
[14:28] <jelmer> vila: The annoying thing here is that we probably won't know whether we need authentication until we've tried sent a full email
[14:29] <jelmer> s/sent/to send/
[14:31] <vila> jelmer: indeed, that's the way http achieve auth, try without and if it fails try with auth
[14:35] <vila> lifeless: ha, 4259, the fun stuff :-(
[14:37] <jelmer> vila: what about an optional default= argument to get_user() that defaults to getpass.getuser() ?
[14:37] <jelmer> vila: smtp could set that to None
[14:37] <jelmer> and keep behaving the way it does atm
[14:38] <vila> jelmer: if you add a FIXME in smtplib about converging and/or addressing the problem, that sounds perfect for your submission
[14:38] <jelmer> that would keep smtp in the current state but at least support prompting for http
[14:38] <jelmer> vila: cool, thanks
[14:39] <lifeless> yes :)
[14:39] <lifeless> vila: see the pyrex issues?
[14:39] <lifeless> also: http://pqm.bazaar-vcs.org/ - the eagle is landing
[14:40] <lifeless> jam: ^ :)
[14:40] <vila> lifeless: not yet (but I suspected that when you mentioned the problem), I'm in Resolve confclits in NEWS
[14:42] <jam> lifeless:  /cheer /train
[14:42] <jam> Though your post about duplicate content was a bit concerning
[14:43] <jam> I have some thoughts about exploiting duplicate content within a group, but having this across .pack files ...
[14:44] <lifeless> jam: yes; it is rather pathological, but worth resolving in some way for production version
[14:45] <jam> lifeless: so... we could go with some sort of labels as an easy fix, or push more for getting text content into a chk structure
[14:46] <jam> I'm concerned about the CHK index exploding even further...
[14:55] <lifeless> jam: indeed
[14:58] <vila> landed in bzr.dev
[15:04] <lifeless> vila: cool
[15:04] <lifeless> jelmer: go for it
[15:06] <jelmer> lifeless: thanks, it's already in though :-)
[15:06] <lifeless> vila: so are you good to get a passing testsuite version for 1.14?
[15:06] <vila> I run selftest at each commit, I'm at bzr.dev@4261 so 3 more commits to go
[15:07] <lifeless> cool, I'll hang about a bit then
[15:07] <vila> err 2 even
[15:07] <lifeless> as I know you have fast tests :)
[15:07] <vila> indeed, could not have afford to do that otherwise
[15:11] <vila> lifeless: yeah for the big fat NEWS entry  about bbc :)
[15:15] <vila> lifeless: ready to merge in 1.14 pushed at lp:~vila/bzr/bbc-1.14 care to have a look, jam too ?
[15:15] <vila> still running the tests, will do a 'make check' after that
[15:16] <lifeless> vila: I'm shattered; the mainline is done, I'm happy to hand off
[15:16] <vila> lifeless: ok
[15:16] <vila> lifeless: good job, sleep well, no test failure to report so far :-)
[15:16] <lifeless> vila: cool, thanks.
[15:17] <jam> vila: so is that cherry-picking brisbane-core into 1.14?
[15:17] <jam> lifeless: is this the bug you were looking at with spiv:
[15:17] <jam> ErrorFromSmartServer: Error received from smart server: ('error', "'AbsentContentFactory' object has
[15:17] <jam>  no attribute 'get_bytes_as'")
[15:17] <lifeless> jam: yes
[15:17] <jam> k
[15:17] <lifeless> jam: I mailed the list the bug number
[15:17] <jam> because I just failed to branch vila's code
[15:18] <lifeless> the fix is to upload more content
[15:18] <jam> bug 354036
[15:18] <lifeless> yes
[15:18] <vila> jam: yes, it should be: bzr-1.14 + (bzr.dev@4265 - everything not related to bbc)
[15:18] <lifeless> vila: apply the fix from bug 354036 to the bzr you use to push, remove the branch and push again
[15:19] <jam> well, for now I can just branch from "http://bazaar..."
[15:19] <lifeless> indeed
[15:20] <lifeless> well, I'm halting() or I'll be more than tired tomorrow
[15:20] <vila> lifeless: I use bzr.dev@4263 to push so the fix should already be included
[15:20] <lifeless> vila: we haven'tlanded the fix for that bug
[15:20] <vila> grrr
[15:21] <Peng_> lifeless: There's an error in the docs for development-rich-root: It says it's interchangeable with pack-0.92, not rich-root-pack.
[15:21] <vila> ubottu you didn't help here ! That's the second time I cross the bugs and that you can't display them >-/
[15:21] <vila> ubottu: that wasn't exactly what I was thinking :-)
[15:22] <lifeless> Peng_: thanks. vila/jam if you could fix that oversight that would be grand
[15:22]  * lifeless goes
[15:25] <vila> uuuurgh, can't pull ~spiv/bzr/stacking-inventory
[15:27] <vila> ok, pulled with bzr-1.13
[15:28] <vila> and pushed with ~spiv/bzr/stacking-inventory  at lp:~bzr/bzr/bbc-1.14
[15:29] <vila> jam: can you pull that one ?
[15:29] <jam> vila: I already fetched it with http://
[15:29] <jam> but I'll try again on another machine
[15:29] <vila> jam: rats, I missed that one
[15:31] <jam> vila: bzr.dev@4265 still fails to branch lp:~bzr/bzr/bbc-1.14
[15:31] <jam> maybe you need some actual data transferred so it doesn't no-op the push?
[15:32] <jam> vila: you could try 'commit --unchanged' and uncommit it later if it works
[15:32] <jam> (commit --unchanged, bzr push, bzr uncommit lp:...)
[15:32] <vila> jam: it's a new branch ! The former one was lp:~vila/bzr/bbc-1.14
[15:32] <jam> ah
[15:32] <jam> well, it failed
[15:33] <jam> so it seems the stacking fix isn't sufficient/complete yet
[15:33] <Peng_> So, um, anyone want to fix the doc issue I just mentioned, or should I send a trivial patch or something?
[15:33] <vila> Peng_: send a trivial patch so that it doesn't get lost
[15:34] <Peng_> vila: Okie dokie.
[15:34] <Peng_> Okey dokey? Whatever. Anyway.
[15:34] <Peng_> Wait, what should it be against? bzr.dev? bbc-1.14?
[15:35] <vila> bbc-1.14 will be merged in bzr.dev at some point so at least against it
[15:35] <Peng_> Whee, AbsentContentFactory traceback!
[15:36] <beuno> Peng_, downgrade to 1.13.1  :)
[15:36] <beuno> I had to do that yesterday
[15:36] <Peng_> \o/
[15:37] <Peng_> I don't have 1.13.1 anywhere.
[15:37] <beuno> it's stacked branches and bzr.dev not getting along AFAIK
[15:38]  * Peng_ kicks the "Target directory already exists" error.
[15:38] <vila> Peng_: bzr branch http://bazaar-vcs.org/bzr/bzr.1.13/
[15:38] <Peng_> vila: Well yeah.
[15:39] <Peng_> Tags would make it easier to figure out which revision is right, though.
[15:39] <Odd_Bloke> So I just ran "bzr push svn+ssh://odd_bloke-guest@svn.debian.org/svn/python-modules/packages/python-whoosh/trunk" and got "bzr: ERROR: Prefix missing for branches/python-whoosh; please create it before pushing.".  How can I tell bzr-svn to actually push to where I'm telling it?  Would it make a difference if .../trunk already existed?
[15:40] <Odd_Bloke> jelmer: ^ :)
[15:41] <awilkins> Odd_Bloke: python-whoosh needs to exist
[15:41] <awilkins> Odd_Bloke: Don't create trunk
[15:41] <Odd_Bloke> python-whoosh does exist.
[15:41] <Odd_Bloke> It's talking about an as-far-as-I-can-tell-unrelated '_branches_/python-whoosh'.
[15:42] <awilkins> Ah, maybe it's branches that needs to exist (or you need to make it think something else about branching scheme)
[15:45] <Peng_> Are format help strings hardcoded in the tests anywhere?
[15:46] <Peng_> In other words, is bzrdir.py the only place you have to make changes to them?
[15:46] <Odd_Bloke> awilkins: Using 'bzr svn-layout'?
[15:46] <awilkins> Odd_Bloke: I'm not entirely sure
[15:46] <awilkins> Odd_Bloke: I've just resorted to conforming to expectations :-)
[15:48] <vila> Peng_: running the tests should tell you :)
[15:48] <Peng_> vila: But you can tell me more quickly! ;-D
[15:49] <Peng_> Wait, so bbc is going to go in 1.14?
[15:49] <vila> Peng_: I don't know that one by hearth, so I'll have to run the tests :)
[15:49] <vila> Peng_: that was always the plan :)
[15:50] <jelmer> Odd_Bloke: hi
[15:50] <jelmer> Odd_Bloke: you need to use svn-push if you're running an older version of bzr
[15:51] <vila> BasicOSX: ping
[15:52] <Peng_> Well, it looks like the tests weren't updated last time they changed, so I'll go with that.
[15:52] <Peng_> So should I send the patch to the mailing list? [1.14]?
[15:52] <vila> Peng_: yup
[15:53] <Peng_> This process needs more magic. All I'd have to do is think "vila, fix this bug" and bang, it would be in bzr.dev 30 seconds later. :(
[15:54] <vila> Peng_: when in doubt, use more magic
[15:55] <Peng_> Shoot, I branched from bbc-1.14, meaning a diff against bzr.dev includes lots of other stuff. :(
[15:56] <Odd_Bloke> jelmer: Ah, cool, didn't realise how long it had been since I'd updated my bzr.dev/bzr-svn on this machine.
[15:56] <Odd_Bloke> jelmer: Thanks. :)
[15:59] <vila> Peng_: why are you diffing against bzr.dev ? Is your branch parent correct ? And the submit one ?
[16:01] <Peng_> vila: Well, when sending a bundle to the list, it's most convenient to have the parent be in bzr.dev. Which the tip of bbc-1.14 isn't. Or something.
[16:01] <Peng_> I don't want to expend more effort thinking about this! :(
[16:02] <Peng_> vila: So, you want the patch against bbc-1.14?
[16:02] <vila> Peng_: it's indeed the most convenient when sending bumdles against bzr.dev :-) But here you want submit_branch = http://bazaar-vcs.org/bzr/bzr.1.14/
[16:03] <vila> Peng_: whatever is easier for you, as I said, we don't want it to be lost, that doesn't mean you have to suffer :)
[16:04] <Peng_> So it looks like you and lifeless made the same changes (or at least the same commit messages) in different revisions, one for bbc-1.14 and one for bzr.dev.
[16:04] <Peng_> Hence my problems.
[16:04] <vila> Peng_: I indeed copy/pasted a lot to cherry-pick
[16:05] <Peng_> If only we were using darcs. :(
[16:10] <Peng_> On a different subject, ice cream! See you later. :)
[16:26] <Tak> ice cream is always on topic
[16:27] <Peng_> What about cake?
[16:30] <Tak> I suppose that's a matter for debate
[16:34] <vila> ice cream on top of cake ?
[16:35] <vila> passed under a chocolate fountain ?
[16:35] <Peng_> And deep-fried!
[16:35] <vila> ubottu don't like chocolate :)
[16:35] <Peng_> With M&Ms and powdered sugar on top.
[16:35] <Peng_> Heh.
[16:39] <vila> chocolate
[16:39] <vila> BasicOSX: ping
[16:40] <vila> BasicOSX: I have a fix for bug #355454
[16:40] <vila> come on ubottu, you should have that one in your cache, it's a hot one
[16:43] <Peng_> 1.14 is getting a *lot* of patches.
[16:45] <vila> Peng_: 1.14rc1 is not out yet, at least because of the above bug :)
[17:15] <tony> hello?
[17:26] <vila> jam: ping
[17:26] <tony> hi
[17:27] <jam> vila: pong
[17:28] <tony> heh
[17:28] <vila> jam: regarding fix for #355454, I think abspath is needed because we'll call stat, so my last remark is invalid
[17:30] <jam> I think I've tracked down the ambiguity, so we just need to decide on a fix
[17:30] <jam> specifically
[17:30] <jam> walkdirs()[4] ==> a path that you can pass to stat or open() to get the object
[17:30] <jam> which may be Unicode or may be an fs path
[17:30] <vila> yet, we may want to have both rel and abs available to avoid re-calculating rel from abs, I'm pretty sure we use the path that can be either utf8-encoded or unicode depending of what dir reader we use
[17:30] <vila> jam: exactly
[17:30] <jam> We use this so that internal to dirstate, we don't have do .decode('utf8') every file
[17:30] <jam> sorry
[17:30] <jam> every ptah
[17:30] <jam> path
[17:31] <jam> on UTF-8 filesystems, etc.
[17:31] <vila> yes, same page
[17:31] <jam> So it sounds like you're finding that the _content_filter stuff *requires* a Unicode string?
[17:31] <vila> so, do you agree that path is either unicode or utf8 encoded ?
[17:31] <vila> tree.relpath does
[17:31] <vila> AFAIK
[17:31] <jam> vila: I think for current implementations, we do
[17:32] <jam> I don't think the api requires that
[17:32] <jam> so I think the problem is how stat_and_sha1 is intermingling with the walkdirs stuff
[17:32] <jam> I think we already have a reasonable relpath available
[17:32] <jam> we just *also* need abspath to actually open the file from disk
[17:32] <vila> so pass both ?
[17:33] <jam> something like that
[17:33] <vila> with relpath=None as default ?
[17:33] <jam> Let me look at the code a bit
[17:34] <vila> jam: far more tests than actual code (and too much for me to fix it *today*, no problem if it can wait tomorrow)
[17:34] <jam> if we look at _walkdirs_utf8 we have a bunch of things that are "utf8_relpath" etc.
[17:34] <jam> vila: I just don't want "fixing" it on Mac to break it on Win32
[17:34] <vila> jam: I didn't fix it on mac, I fixed it on interpid
[17:35] <vila> and I think BasicOSX is also on Linux
[17:35] <jam> vila: how was it breaking there? (and why wouldn't it have been breaking on PQM)
[17:35] <vila> jam: ha ha pqm, still the same LANG=C joke ?
[17:35] <vila> it broke here with python -Werror
[17:36] <jam> well, supposedly lifeless fixed PQM's LANG issue
[17:36] <vila> lifeless filed a RT request, I don't know if it has been fixed yet
[17:37] <jam> he mentioned the likelyhood that things may start breaking accidentally
[17:37] <jam> so I thought it had happened
[17:38] <vila> python -Werror ./bzr selftest -s bzrlib.tests.tree_implementations.test_test_trees.TestTreeShapes.test_tree_with_merged_utf8
[17:38] <jam> so certainly WT.relpath() is comparing the path with self.basedir
[17:38] <vila> jam: can you try that ?
[17:38] <jam> which should be a unicode string
[17:38] <jam> vila: well, on Windows the tests pass
[17:39] <jam> because they use Unicode strings for that argument :)
[17:39] <vila> see ? That's the right fix ! :-)
[17:39] <vila> lol
[17:39] <jam> win32 walks in Unicode, because we get it directly from the FooW apis
[17:40] <vila> jam: doh ! It passes on OSX too !
[17:40] <jam> vila: interesting, I get d to convert both arguments to Unicode - interpreting them as being unequal
[17:40] <vila> ha wait, no extension built here
[17:41] <jam> vila: right, it will pass without extensions, because the global fallback path is to walk using Unicode
[17:41] <vila> did you use 'python -Werror' ?
[17:41] <vila> jam: sure
[17:41] <jam> vila: well with -Werror it fails, without it just warns
[17:41] <jam> anyway
[17:41] <jam> I would actually say the 'correct' fix is to do:
[17:42] <jam> if type(x) is not unicode:
[17:42] <jam>   x.decode(_fs_enc)
[17:42] <jam> however, at the moment
[17:42] <jam> the code paths
[17:42] <vila> jam: That's the bug ! That's why make check-dist-tarball fails
[17:42] <jam> state that the only time x isn't unicode
[17:42] <vila> because it uses python -Werror
[17:42] <jam> is when fs_enc == utf-8
[17:43] <jam> so.... we have a utf-8 relpath already
[17:43] <jam> it is part of the walkdirs api, and we could pass it into the stat function
[17:43] <jam> but for ease...
[17:46] <jam> vila: BB:tweak ... for now your fix is fine, as long as we update the documentation on SHA1Provider.stat_and_sha1() to declare that abspath
[17:46] <jam> may be a filesystem encoded absolute path
[17:47] <jam> since it is coming from walkdirs_utf8
[17:48] <vila> right, I'll then enhance the patch to provide relpath too and more importantly add some tests parametrization as discussed in brisbane
[17:48] <jam> vila: the one thing to be aware of... relpath *might* be from a subdir of a directory, I'm not 100% sure where the 'walkdirs' is starting from.
[17:49] <vila> jam: hmm
[17:49] <jam> I'm thinking it can be trusted
[17:49] <jam> I just need to poke around the code and make sure
[17:52] <jam> vila: it should be fine
[17:53] <jam> of course...
[17:53] <vila> jam: ok, I'll add tests for it :)
[17:53] <jam> this means that we'll have to decode every path again, but perhaps only if they miss the sha hash
[17:53] <jam> which would be ok
[17:54] <jam> sorry, the stat fingerprint hash cache
[17:55] <vila> jam: what worries me more is that g_content_filter_stack queries for filters which may in turn result in IO...
[18:04] <jam> vila: what IO, you mean having to read config files to figure out if there is a filter for the given file?
[18:04] <vila> jam: things like that, I didn't dig that far to be 100% sure, just a bad feeling
[18:05] <vila> since the SHA1Provider already cache the tree, I thought some more may need to be cached, but may be it's already the case and I should not worry
[18:09] <vila> jam: last thing before I quit, did you had a look or have comments about bbc-1.14 ? Can you make sure BasicOSX is aware of it ?
[18:09] <vila> s/did you had/did you have/ geee, why do I keep making that one...
[18:10] <vila> ...is it correct ENglish or *not* ?
[18:11] <jam> "did you have a look"
[18:11] <jam> though "did you look at" is easier
[18:21] <abentley> vila: Isn't it very similar to a French construction where the past tense is used?  "As-tu eu.."?
[18:22] <vila> abentley: that's where my error is coming most probably: As-tu jeté un coup d'oeil sur
[18:23] <vila> my fingers and my brains walking at different speeds in parallel in French and English just mess things up :)
[18:23] <vila> brain, mutli-core but still mon-brain :)
[18:23] <vila> mono argh, time to stop :)
[18:24] <vila> cooking time
[18:41] <alaa_> hey guys. So am getting a stack trace every time i run "bzr st". It is bzr 1.13. The error is TypeError: run() got an unexpected keyword argument "verbose"
[18:41] <alaa_> I'll file a bug a bit later, but is there anything i can do now?
[18:44] <james_w> alaa_: you need to upgrade your copy of the bzr-loom plugin
[18:44] <alaa_> james_w: ah yes. I was just looking at the trace, and i saw the loom reference. I'll try that and report back
[18:49] <alaa_> james_w: That worked. So this is a known problem then, right?
[18:51] <Peng_> alaa_: Yes. Hence it being fixed in newer versions of bzr-loom. :P
[18:51] <james_w> alaa_: yeah, I would guess that it is the most frequently reported bug in the history of bzr :-)
[18:54] <alaa_> Right. It's amazing how it got through since it is in the most used command in bzr :)
[18:54] <alaa_> james_w: thank you for your help
[18:54] <james_w> np
[18:57] <catojo> hello guys
[18:57] <Peng_> Hi
[18:58] <catojo> Hi Peng_
[18:58] <catojo> Can, do you know how much sites that supports the bazaar ?
[18:58] <Peng_> What?
[18:59] <catojo> So, I'm from brazil, thus, I do not speak english correctly.
[18:59] <catojo> But i want to know how many sites supports bazaar
[19:00] <catojo> I know launchpad only.
[19:00] <Peng_> catojo: Oh. SourceForge added support recently.
[19:00] <catojo> Cool.
[19:00] <catojo> I will see.
[19:00] <catojo> Thanks.
[19:01] <catojo> Peng_
[19:02] <catojo> A have a free software stored at sourceforge.
[19:02] <catojo> But I'm use SVN.
[19:02] <catojo> I will try to migrate to bazaar.
[19:02] <Toksyuryel> bzr rocks
[19:02] <Toksyuryel> :)
[19:03] <beuno> It sure does!
[19:03] <beuno> $
[19:03] <Peng_> catojo: You can use bzr-svn to convert. http://bazaar-vcs.org/BzrForeignBranches/Subversion
[19:03] <catojo> hmm
[19:03] <catojo> I will see.
[19:04] <catojo> Some people will go to FISL 10 ?
[19:04] <catojo> http://fisl.softwarelivre.org/10/www/
[19:06] <Peng_> beuno: So, which version of my Loggerhead YUI CDN thing do you like best?
[19:08] <Peng_> :D
[19:08] <catojo> Peng_ Yahoo library ?
[19:08] <catojo> javascript ?
[19:09] <catojo> YUI
[19:09] <Peng_> catojo: Yes.
[19:10] <catojo> Peng_ Javascript smells good.
[19:10] <beuno> Peng_, I have options?
[19:11] <beuno> did I not approve that branch?
[19:11] <Peng_> beuno: I made 3 different versions of my little patch.
[19:11] <Peng_> beuno: Sure, you did, and then I changed it again. :D
[19:11] <beuno> ah!  hehe
[19:11] <beuno> ok
[19:11] <beuno> so
[19:11] <beuno> URL?
[19:11] <beuno> and
[19:11] <beuno> what's your preferencec?
[19:13] <Peng_> beuno: http://bzr.mattnordhoff.com/loggerhead/loggerhead/yui-cdn/changes
[19:14] <Peng_> beuno: I think revision 322 is the prettiest, but revision 324/325 uses a single, combined JS file instead of half a dozen individual ones, so it should be faster.
[19:16] <beuno> Peng_, agreed
[19:16] <beuno> one comment
[19:16] <beuno> how about not using "yui" as a variable name?
[19:17] <beuno> ie, use cdn generically
[19:17] <beuno> other than that, I'd love for that to be merged in
[19:17] <beuno> don't forget to update NEWS
[19:19] <Peng_> beuno: Wait, so do you prefer 324/325 or 322?
[19:20] <beuno> Peng_, I think 322, even though the URL is hardcoded
[19:21] <beuno> and I know I complained about that
[19:21] <beuno> I'm actually ok either way I think
[19:21] <beuno> both are good, and both itch
[19:21] <Peng_> beuno: 324/325 just hardcodes it in the template, and in a more obfuscated way.
[19:21] <beuno> yeah, that's what itches me about that
[19:21] <Peng_> :D
[19:21] <beuno> so making the var names more generic, and landing 322 I think is a good compromise
[19:22] <Peng_> Which var names?
[19:23] <beuno> use_yui_cdn
[19:23] <beuno> and def yui_url
[19:23] <beuno> I'd use:  use_cdn, and cdn_url
[19:23] <beuno> we're using YUI, but we're not married yet  ;)
[19:24] <beuno> maybe even the --yui-cdn
[19:24] <beuno> to --use-cdn
[19:24] <Peng_> Hmm, I see your point.
[19:24] <beuno> so if we change js libraries, people don't have to update their start scripts   :)
[19:24] <Peng_> I kind of like the name "yui_url" for the function, though, since it *is* specific to YUI.
[19:25] <beuno> true
[19:25] <Peng_> Well, it's just as specific as the rest of the code. Still, I'd prefer to make the other changes, but stick with "yui_url".
[19:25] <beuno> I'm fine with that
[19:27] <Peng_> I guess it would have to be changed if the JS library is ever changed, but Loggerhead doesn't guarantee internal API stability anyway, does it?
[19:27] <beuno> not for now, no
[19:27] <beuno> I'm more concerned about changing things to the users
[19:29] <Peng_> Right. Users shouldn't care about the name of that method.
[19:29] <Peng_> (Which means *somebody* will, of course. :P )
[19:31] <beuno> heh, exactly
[19:34] <Peng_> Why are lines in NEWS only about 70 characters wide instead of 79?
[19:34] <beuno> no idea
[19:34] <beuno> crazyness
[19:34] <beuno> like a lot of the rest of the code  :)
[19:35] <Peng_> Heh.
[19:36] <Peng_> beuno: On a different subject, mind if I make LoggerheadConfig a new-style class? Can I do it directly in the trunk without getting reviewed? :D
[19:37] <beuno> Peng_, Go for it.
[19:37] <Peng_> Thanks.
[19:37] <beuno> this is why you got access to trunk!  lower barrier to JFDI stuff
[19:38] <Peng_> beuno: Yeah, but I'm still afraid to do it. How much am I allowed to JFD? Trivial things like that? Simple bug fixes?
[19:39] <beuno> Peng_, in general, it's small bits that don't change anything drastically
[19:39] <beuno> very small bug fixes, doc changes, etc
[19:40] <beuno> reviews are a fantastic safety net, and as we get more tests, we may even get a PQM
[19:40] <Peng_> Oh, neat.
[19:40] <beuno> so we can ensure tests pass as well
[19:41] <Peng_> Well, I just did it. Pushing to LP is slow!
[19:41] <Peng_> (The LoggerheadConfig thing, I mean.)
[19:42] <beuno> is it?
[19:42] <beuno> it seems amazingly fast for me with 1.13
[19:42] <beuno> I use a checkout to commit to trunk
[19:43] <beuno> merge in changes from the branch, and commit
[19:43] <Peng_> It was like 19 seconds vs. 4. Actually, I'm not sure why. They should both be new enough. Maybe it's just because LP is farther away from me.
[19:43] <beuno> maybe it autopacked?
[19:46] <abentley> jam: ping
[19:46] <beuno> Peng_, I've added 'debug_flags = hpss' to my bazaar.conf
[19:46] <Peng_> beuno: It didn't autopack. bazaar.lp seems just plain slow ATM.
[19:47] <beuno> so you can always look at the logs when these things happen
[19:47] <beuno> Peng_, could be. mwhudson was working on something with ssh auth
[19:48] <Peng_> beuno: Seems slow over HTTP too.
[19:48] <LarstiQ> Peng_: mail wrapping is usually 72 or 70 characters.
[19:48] <Peng_> LarstiQ: Ah, good point.
[19:48] <Peng_> beuno: Yeah, but it'll make .bzr.log *really* spammy.
[19:49] <beuno> Peng_, yes, also called useful  :)
[19:49] <Peng_> beuno: So, the diff for yui-cdn currently looks like this: http://paste.pocoo.org/show/111505/ bb:approve?
[19:49] <Peng_> beuno: But it won't be useful very often.
[19:49] <beuno> and it tells you how many hpss calls where made
[19:49] <Peng_> Hmm, I *do* like weird statistics.
[19:49] <LarstiQ> :)
[19:51] <beuno> Peng_, where is yui_url called from now?
[19:52] <Peng_> beuno: macros.pt.
[19:52] <beuno> aha
[19:52] <beuno> Peng_, bb:approve
[19:52] <beuno> or lp:approve (?)
[19:53] <abentley> beuno: " review approve"
[19:53] <Peng_> abentley: That's longer. :P And "Bundly Buggy" sounds cool.
[19:54] <Peng_> Makes me want to chew bubble gum.
[19:54] <Peng_> beuno: Can I land it?
[19:54] <abentley> Peng_: Thanks.  I like the name, though it makes less sense now that it's primarily tracking merge directives.
[19:55] <Peng_> abentley: True, but cool > sensible.
[19:57] <Peng_> beuno: wb?
[19:57] <beuno_> yeah, my ISP is sucking big time
[19:57] <Peng_> < Peng_> beuno: Can I land it?
[19:58] <beuno> Peng_, yes!
[19:58] <beuno> 15:52 < beuno> Peng_, bb:approve
[19:58] <beuno> 15:52 < beuno> or lp:approve (?)
[19:58] <beuno> but of course, that got eaten by the internets blackhole
[19:59] <Peng_> beuno: It came through, but I wasn't sure if we should wait on mwhudson or something. (Sorry for the highlight, mwhudson.)
[19:59] <beuno> Peng_, I think our policy is just 1 review
[20:00] <Peng_> Okay.
[20:01] <bpierre> hi
[20:02] <Peng_> beuno: Pushed to my server in 6.57 seconds and LP in 33.05.
[20:02] <Peng_> Isn't there some weird performance issue with certain versions of certain things?
[20:03] <beuno> Peng_, you've downgraded to 1.13, right?
[20:03] <Peng_> beuno: Nope.
[20:04] <Peng_> beuno: I used http to work around the AbsentContentFactory issue the one time I hit it.
[20:04] <beuno> ah
[20:04] <beuno> well, ~1.14 works amazingly well with 1.13
[20:04] <beuno> so maybe it's the ssh problem
[20:04] <beuno> rockstar, abentley, any ideas  ^?
[20:05] <bpierre> I'm trying to use the new code in bzr.dev for EOL handling, and so far nothing work: I've created a 1.14 format branch, added some files, then put '[name *]' 'eol = crlf' in ~/.bazaar/rules, so if I branch the initial branch I should get windows like EOL, right?
[20:06] <rockstar> beuno, mwhudson was saying something about a regression between 1.13 and older versions of bzr on the client.  That's all I know though.
[20:06] <abentley> beuno: Sorry, no.  Others are investigating slow username lookups, which may be related.
[20:07] <rockstar> abentley, ah, I forgot about that.
[20:08] <Peng_> abentley: Slow username looks? What does that impact? Regular old push to bzr+ssh://bazaar.lp.net?
[20:08] <Peng_> s/looks/lookups/
[20:08] <abentley> Peng: any sftp or ssh access to bazaar.lp.net
[20:09] <Peng_> abentley: Ah. That could do it, then, I guess.
[20:22] <Peng_> Thanks for the hand-holding. :)
[20:46] <fbond> Can I pull without updating the working tree?
[20:48] <james_w> not from the UI I don't think
[20:57] <rockstar> abentley, hey
[20:58] <abentley> rockstar: hey
[20:58] <rockstar> abentley, get_rev_id seems to be confused.
[20:58] <abentley> rockstar: how so?
[20:59] <rockstar> So I pass in the revno, and it throws a NoSuchRevision exception, even though I navigated from the history listing of the branch by clicking that revno.
[21:01] <rockstar> abentley, I'm sure it's because I'm confused, but the documentation looks pretty plain that I just pass in a revno.
[21:01] <abentley> rockstar: Is it an integer revno, or does it have dots?
[21:01] <bpierre> did you pass a string or a integer? I recently got a problem with buildbot because of that (after upgrading bzr)
[21:04] <rockstar> abentley, in this case, it's an integer revno.
[21:04] <rockstar> abentley, I can take it all the way back to revno 1, and it says it doesn't exist.
[21:06] <abentley> rockstar: It works for me.
[21:06] <rockstar> abentley, :(
[21:07] <abentley> rockstar: https://pastebin.canonical.com/16055/
[21:07] <rockstar> abentley, I think I figured it out.  The revno was actually '322'
[21:07] <jelmer> 'evening abentley, rockstar
[21:07] <abentley> jelmer: Hi.
[21:07] <rockstar> Hi jelmer
[21:07] <jelmer> abentley: Do you know what the expected behaviour of revno's is when there are ghosts in the lhs history?
[21:07] <rockstar> abentley, so it doesn't handle strings that can be converted to integers.
[21:07] <rockstar> abentley, does this mean I can't get the dotted revnos then?
[21:07] <bpierre> exactly my problem!
[21:08] <abentley> rockstar: No, it doesn't.
[21:08] <abentley> rockstar: That's UI-level functionality.
[21:08] <abentley> rockstar: Branch doesn't fold, spindle or mutilate its input.
[21:08] <jelmer> abentley: simply count the first known revid as revno 1?
[21:08] <rockstar> abentley, that's a good contract, I just needed to figure it out.
[21:09] <abentley> jelmer: No, it should work backwards from the current revid/revno
[21:09] <rockstar> abentley, so if I get a dotted revno, how would I get that revid?
[21:09] <abentley> jelmer: Due to ghosts, the revids for some revnos may not be known.
[21:10] <jelmer> abentley: ah, that makes sense
[21:10] <abentley> rockstar: Branch.get_revision_id_to_revno_map
[21:11] <abentley> rockstar: That operation is much more expensive, and makes sense to cache.
[21:11] <jelmer> abentley: so in the case that we don't have a reference revno when the revno is unknown, what is the expected behaviour? revno=-1, revno=None or is that simply not possible yet?
[21:12] <abentley> jelmer: I don't think that case is possible.  If we had to handle that case, I'd probably assign the ghost to revno 1.
[21:12] <jelmer> abentley: ok, that makes sense. thanks
[21:48] <Necoro> wow ... I just noticed that loggerhead now has syntax highlighting :)
[21:48] <Necoro> thanks to the author :)
[21:53] <lifeless> Necoro: :)
[21:53] <lifeless> mwhudson: was that you?
[22:06] <mwhudson> lifeless: it was originally a patch from peter bui iirc
[22:06] <mwhudson> Peng_ and i improved it a big
[22:11] <mwhudson> *bit
[22:13] <thumper> a big bit?
[22:14] <Bluehorn> Hrm, when branching, what does this error message tell me: KnitPackRepository('file://...') is not compatible  with
[22:14] <Bluehorn> KnitPackRepository(...) different rich root support
[22:14] <Bluehorn> I am branching bzr-builddeb from launchpad into a directory created using bzr init-repo.
[22:15] <Bluehorn> What worries me is that the message basically tells me, $foo is incompatible with $foo (same values for $foo ;-))
[22:16] <cody-somerville> Upgrade your repo
[22:17] <Peng_> Bluehorn: They're both KnitPackRepositories, but one has the "rich root" flag on and one doesn't. Yes, the message is rather unhelpful.
[22:18] <Peng_> Bluehorn: Do you have any other branches in your repo?
[22:18] <Peng_> Bluehorn: What format did you create it in? The default (pack-0.92)?
[22:20] <Bluehorn> Peng_: yep, default
[22:20] <Bluehorn> Peng_: just bzr init-repo bzr-builddeb
[22:20] <Bluehorn> Peng_: Just created a new repo, bzr init-repo --rich-root bzr-builddeb
[22:21] <jelmer> hmm
[22:21] <jelmer> 1.15 is going to be awesome
[22:21] <Bluehorn> Peng_: But I have to admit that the different formats (suggested by bzr help upgrade) are a djungle.
[22:21] <lifeless> Bluehorn: we are working to remove them all
[22:21] <Bluehorn> Peng_: I'll go and read bzr help formats
[22:21] <Bluehorn> lifeless: but you will need backwards compatibility, no?
[22:22] <lifeless> Bluehorn: yes, but that doesn't mean showing you everything under the sun
[22:22] <Bluehorn> lifeless: :)
[22:22] <beuno> lifeless, I see brisbane-core has landed?
[22:22] <Bluehorn> nice. bzr branch tells me that my repository is deprecated and I should run bzr upgrade. bzr upgrade tells me: bzr: ERROR: Cannot convert to format <RepositoryFormatKnitPack1>.  Does not support rich root data.
[22:23] <Bluehorn> so what is the latest and greatest format for rich root repositories?
[22:23] <james_w> --1.6-rich-root would be recent
[22:24] <james_w> --1.9-rich-root  is the shiniest
[22:24] <james_w> --development6-rich-root will eat your pets but will be very shiny indeed soon
[22:24] <lifeless> Bluehorn: --default-rich-root is what you should use if you need rich roots;
[22:25] <beuno> how's the performance between 1.6 and development6-rich-root?
[22:25] <lifeless> Bluehorn: note that rich roots are a *one-way* upgrade,so only use them if you know you need to, and don't branch other projects into the same repo
[22:25] <lifeless> Bluehorn: once we make rich roots the default this advice will go away :)
[22:26] <Bluehorn> james_w: just upgraded to 1.9-rr. thanks!
[22:26] <Peng_> Of course, one of the major reasons rich roots aren't the default yet is *because* they're a one-way upgrade. Yay chickens and eggs.
[22:27] <lifeless> mmmm omelete
[22:27] <Peng_> Or some other metaphor or whatever.
[22:28] <lifeless> jelmer: ah I remember why I pung
[22:29] <lifeless> I wanted to ask if its cool and accurate to say 'samba4 uses subunit'
[22:30] <jelmer> lifeless: yeah
[22:30] <jelmer> lifeless: so far it's mainly the subunit *protocol* though, not yet the subunit project
[22:31] <lifeless> jelmer: same thing IMO :)
[22:31] <jelmer> lifeless: I actually hope we can ship with a subunit parser that can do formatting for the buildfarm
[22:32] <lifeless> would be good
[22:32] <lifeless> you know I'm very happy to add a perl/ module to upstream
[22:32] <jelmer> lifeless: and allow developers to use the subunit projects' fancy tools if they have them on their system elsewhere
[22:33] <jelmer> lifeless: I might contribute back our perl parser at some point, but I need to make it a bit less hackish first
[22:33] <lifeless> jelmer: why? [less hackish] - I'm not qualified to critique perl code beyond simple readability
[22:36] <Peng_> jelmer: Is it a good idea for bzr.dev users to switch to bzr-svn 0.6 now? Will it be really unstable for a while or anything?
[22:39] <jelmer> lifeless: in particular the API should be hashed out, don't want to break it on people
[22:40] <jelmer> Peng_: yeah, that should be fine. the main thing atm is that you won't have dpush yet
[22:40] <lifeless> jelmer: you could put it up with a note saying clearly 'unstable api'
[22:40] <lifeless> better an unstable api than none
[22:40] <jelmer> lifeless: or I could just fix it and then contribute it rather than contributing it now, then fixing it, then sending updates :-)
[22:43] <lifeless> jelmer: up to you
[22:44] <lifeless> jelmer: just encouraging release early release often, where it seems possible without great risk
[22:47] <lifeless> jelmer: from my perspective you'd basically own a perl/ subdir; commit directly to it if you want
[22:56] <james_w> statik: ooh, thanks :-)
[22:56] <lifeless> james_w: ?
[22:57] <james_w> in response to a mail
[22:57] <lifeless> I'm naturally nosey
[23:15] <lifeless> Odd_Bloke: how does whoosh compare to bzr-search in terms of performance?
[23:18] <Odd_Bloke> lifeless: I've never used bzr-search, so I don't really know.
[23:18] <Odd_Bloke> For that matter, I haven't used Whoosh in any performance-critical manner.
[23:18] <lifeless> ok
[23:25] <vila> pqm announces: bbc landed in 1.14 :-)
[23:26] <lifeless> thanks vila
[23:26] <vila> lifeless: thanks BasicOSX (who manages to *avoid* that annoucement :-)
[23:26] <lifeless> did you incorporate peng's doc fix for it?
[23:27] <vila> I don't think so,
[23:27] <Peng_> \o/
[23:28] <vila> but I also think that the doc fix was making unclear that non rich root format can be imported
[23:30] <BasicOSX> when will the 1.13.2 stuff be ready :-)
[23:30] <vila> but the fix is available for all (especially those mastering English :) to comment
[23:30]  * vila goes to sleep now
[23:31] <lifeless> BasicOSX: jam and vila had issues with it yesterday, spiv and I will tackle it more today
[23:31] <Peng_> vila: Hmm, you have a point.
[23:31] <BasicOSX> woah... poolie ! :-)
[23:32] <poolie> hello!
[23:32] <BasicOSX> Anymore stuff to squeeze into 1.14rc1?
[23:32] <lifeless> BasicOSX: no, I think the 1.13.2 fix can go into whatever 1.14 we're up to when its ready - don't block on it
[23:32] <poolie> i literally just logged in to a computer for the first time in 12 days
[23:32] <poolie> so i presume you're not asking me :)
[23:33] <Peng_> poolie: Well, if you can think of anything... :D
[23:33] <BasicOSX> poolie:  not asking you ;-)
[23:33] <BasicOSX> Peng:  >8-(
[23:33] <poolie> oh typing feels weird :)
[23:33] <poolie> hello lifeless, peng
[23:34] <Peng_> Hi! :)
[23:34] <Peng_> BasicOSX: But if there weren't dozens of things being squeezed in at the last minute, wouldn't you feel underutilized? :)
[23:34] <lifeless> welcome back poolie
[23:35] <BasicOSX> Peng:  ironically, that would be the truth :-)
[23:36]  * BasicOSX cheers
[23:36] <BasicOSX> All test pass now
[23:43] <james_w> hey poolie
[23:45] <poolie> hello james_w
[23:47] <BasicOSX> should I just close the bugs listed as closed in the NEWS but are still listed as open by tools/check-newsbugs.py ?
[23:48] <poolie> BasicOSX: probably not just close them, but check whether they ought to be closed
[23:48] <poolie> it's possible some were eg reopened later, or not totally fixed
[23:48] <poolie> are there many of them?
[23:49] <BasicOSX> ok, I opened bug on it,  bug 354984
[23:50] <thumper> abentley: are you still waiting on a review for your big nested tree branch?