[00:00] <jml> igc: I think it's very much worth fixing, because it regularly trips up bzr users, no matter how experienced they are.
[00:01] <igc> jml: do we have logs showing how often users are pushing pack-0.92 branches vs 0.9 branches?
[00:01] <jml> hahaha
[00:01] <jml> no.
[00:01] <igc> jml: do you think it's related to trying to stack on the far end?
[00:02] <jml> igc: I don't know. What I do know is that stacking isn't behaving as I'm told it should.
[00:02] <igc> jml: if this is the performance users are seeing out-of-the-box, it's scary.
[00:02] <jml> igc: if they use old formats, that's what they see when pushing to LP.
[00:02] <jml> igc: incidentally, do you have -Dhpss enabled?
[00:02] <igc> jml: just added 'debug_flags=hpss' to bazaar.conf now
[00:03] <jml> igc: cool. it's worth having for situations like this.
[00:03] <igc> poolie: were you planning to make 1.9 the default early in the 1.14 release cycle?
[00:03] <poolie> i'd ilke to
[00:03] <igc> poolie: or did jelmer still have issues we need to sort first?
[00:04] <poolie> it may be getting a bit close to 2.0 but we should still do it
[00:04] <poolie> that branch still doesn't pass
[00:04] <poolie> i think i understand what to do but i haven't done it yet
[00:04] <jml> igc: I'd very much appreciate if you could take the time to file a good bug about this.
[00:06] <jml> hmm. or I can "upgrade" to pack-0.92 and do it myself.
[00:06] <lifeless> igc: it hasn't stacked. I was sure we had this fixed - what bzr are you using
[00:08] <igc> lifeless: bzr.dev r4163
[00:09] <lifeless> ok
[00:09] <lifeless> buggering a file
[00:09] <lifeless> igc: whats your local branch format
[00:13] <lifeless> igc: can you do bzr info -v on the branch you pushed from please
[00:13] <lifeless> igc: I want the branch format line
[00:14] <jml> lifeless: I *think* I'm reproducing the bug w/ bzr.dev r4164, pack-0.92 repo, branch7 format. getting lots of hpss calls like http://paste.ubuntu.com/133325/
[00:14] <lifeless> jml: lp will do lots of hpss calls full stop
[00:14] <jml> lifeless: bzr info -v output http://paste.ubuntu.com/133326/
[00:15] <jml> lifeless: it doesn't normally take five minutes to push up a stacked branch that is identical to the stacked-on branch.
[00:15] <lifeless> so my guess is
[00:15] <jml> lifeless: but I can wait an hour or so and see if this is really the same behaviour
[00:15] <lifeless> a stackable source branch
[00:15] <lifeless> shortcutting the check for can-stack
[00:16] <lifeless> when actually it can't
[00:16] <lifeless> and thus we don't upgrade-on-the-fly
[00:16] <jml> sounds plausible.
[00:16] <lifeless> no jml, thats enough to go on I think
[00:17] <jml> lifeless: if I file a bug, what should I put in it? (or do you want to file it instead?)
[00:17] <lifeless> I've filed
[00:18] <jml> lifeless: thanks. I'll look out for it.
[00:20] <lifeless> spiv: how did you go assessing alternatives for 'I'm in a gaol'
[00:23] <spiv> lifeless: I'm pretty happy with adding an ignore_fallbacks param to open_branch et al.  But we have a problem with the cloning_metadir RPC, which currently *depends* on following a branch reference to determine the repo format, and the client depends on server to tell it the repo format.
[00:24] <lifeless> spiv: oh, ugh.
[00:24] <lifeless> I think branch references on servers are fugly
[00:25] <lifeless> so I propose that on a server we do something different; e.g. return the current default
[00:25] <spiv> So there's no way to have the gaol and preserve the behaviour of the cloning_metadir RPC.  I think probably we should add a new RPC, and make the old one just guess at the default format for branch refs.  1.13 clients might be confused sometimes, everyone else should be ok.
[00:25] <spiv> Hmm, we don't even need a new RPC, really.
[00:25] <lifeless> no, we don't :)
[00:26] <spiv> We can just make the 1.14 client ask the referenced branch for the source format and ignore whatever the first server reckoned.
[00:26] <lifeless> spiv: I was proposing that we just behave differently
[00:27] <mwhudson> oh btw
[00:27] <spiv> It sounds like we're agreeing?
[00:28] <mwhudson> if you want to change the ignore_fallback parameter to some kind of callback
[00:28] <mwhudson> i will buy you alcohol
[00:28] <spiv> mwhudson: oh?
[00:28] <lifeless> spiv: broadly; I think you're saying the client can get the old behaviour by working differently, I'm saying the old behaviour is simply undesirable with servers in the loop
[00:28] <mwhudson> it would let me stop using the transform_fallback_location hook, which is basically a bad idea
[00:28] <lifeless> spiv: and we should just change it
[00:29] <lifeless> mwhudson: you use it to get a properly loaded branch, yes?
[00:29] <mwhudson> lifeless: yes
[00:29] <lifeless> mwhudson: AFAICT you'll still need it
[00:29] <lifeless> mwhudson: not in the server process, but in the scanner etc
[00:29] <mwhudson> well, if this ignore_fallback parameter became a callback that allowed me to open a different branch instead (or no branch, your use case)
[00:29] <mwhudson> then i wouldn't
[00:30] <mwhudson> we'd just say open('...', fallback_hook=)
[00:30] <mwhudson> lifeless: it's only the puller that really really needs it
[00:30] <lifeless> mwhudson: how is that better for you that the transform hook
[00:30] <lifeless> *than*
[00:30] <mwhudson> lifeless: i don't have to worry about uninstalling it
[00:31] <lifeless> mwhudson: why would you worry about that?
[00:31]  * mwhudson pages in furiously
[00:31] <lifeless> mwhudson: last I heard you uninstall it in your test suite which isn't needed as TestCase in bzrlib does that
[00:33] <mwhudson> lifeless: one of the awkwardnesses is that the 'hook' wants to have state per my invocation of branch.open
[00:33] <mwhudson> lifeless: i can make the hook work
[00:33] <mwhudson> lifeless: but it's not natural
[00:33] <lifeless> mwhudson: perhaps it should be given the branch url too?
[00:33] <mwhudson> well it is, in effect
[00:34] <mwhudson> (it gets the passed half-open branch)
[00:34] <lifeless> mwhudson: the thing is, Branch.open is Branch.open_containing which is bzrdir.open_branch which is WorkingTree.open_containing which is ...
[00:34] <mwhudson> lifeless: i know
[00:35] <lifeless> I'm not happy about adding a parameter to it as it is (this is what spiv and I disagreed on yesterday)
[00:35] <mwhudson> i'll let you fight it out then :)
[00:35] <lifeless> I'd really rather not have to scatter lambda:None around to use it
[00:37] <mwhudson> yeah, i can see that
[00:37] <lifeless> also I think there is a difference between
[00:38] <lifeless> 'globally, I'm running in a funky space', and 'right here I do not want to open it'
[00:38] <lifeless> specifically,
[00:38] <lifeless> the first case is servers, the puller, etc
[00:38] <lifeless> the second is reading data from an unupgraded stacked branch
[00:38] <lifeless> which requires a heck of a lot of other work done anyhow
[00:42] <igc> lifeless: branch: Branch format 6
[00:44] <lifeless> thanks
[00:53] <SamB> jelmer: yeah?
[00:58] <glyph> Did bzr and bzrtools make it to the ppa without bzr-svn, or is something wrong with my package configuration?
[00:59]  * SamB wishes the PPAs could do Debian packages too ...
[01:10] <johnf> glyph: I didn't get a chance let me sort that out now. I though jelmer might do it as he has done in the past
[01:21] <glyph> johnf: Thanks.  Just wanted to know if it was everybody's system or just mine :)
[01:29] <jelmer> SamB: never mind, I misread 345067
[01:29] <jelmer> SamB: bug 345067 I mean
[01:30] <SamB> jelmer: I still haven't figured out what the REAL problem is
[01:30] <jelmer> SamB: well, did you actually build subvertpy?
[01:32] <SamB> yeah
[01:32] <SamB> the .so is there
[01:37] <SamB> can't seem to find libneon
[01:38] <jelmer> SamB: please try the latest subvertpy
[01:38] <jelmer> SamB: it should give a clearer error message
[01:39] <SamB> oh
[01:39] <SamB> huh
[01:39] <SamB> I just tried running SVN ...
[01:39] <SamB> guess what!
[01:39] <SamB> it can't find libneon on this box either ...
[01:39] <lifeless> fail?
[01:40] <jelmer> one day I'll find time to implement WebDAV+DeltaV in Python
[01:41] <SamB> (actually, I typed "svn pull" by mistake when I was trying to pull subvertpy ;-)
[01:41] <SamB> damn you, slackware, and your lack of dependencies!
[01:48] <lifeless> jml: bug 345169
[01:49] <jml> lifeless: thanks.
[01:55] <pohutukawa> jelmer: Hi jelmer, thumper has just directed me to you with a request
[01:55] <pohutukawa> jelmer: just filed this: https://bugs.launchpad.net/bzr/+bug/345198
[01:56] <thumper> pohutukawa: jelmer was active 15 min ago but is in europe
[01:56] <jelmer> pohutukawa: hi
[01:56] <pohutukawa> thumper: thx.  It's the one in Intrepid ... and it used to work until yesterday or the day before that ...
[01:59] <jml> mwhudson: I'd like an interface similar to rgrep
[01:59] <jml> I guess it's not that hard to knock up in elisp
[02:00] <pohutukawa> jelmer: what's the preferred way to upgrade it in this case?
[02:00] <mwhudson> jml: M-x customize-variable grep-find-template
[02:00] <mwhudson> (!)
[02:00] <pohutukawa> always have a bit of a bad feeling when circumventing the package management ...
[02:02] <jelmer> pohutukawa: You'd have to upgrade bzr itself as well when upgrading bzr-svn
[02:02] <jelmer> pohutukawa: the bzr PPA has the latest bzr-svn built for intrepid fwiw
[02:02] <pohutukawa> :-/
[02:02] <jelmer> pohutukawa: anyway, the problem seems to be in the tags, did you change any recently/
[02:02] <pohutukawa> ah, if there's a PPA, that sounds a lot more promising towards succeeding without a domino effect of upgrade dependencies
[02:02] <jelmer> ?
[02:03] <pohutukawa> jelmer: what tags?
[02:03] <pohutukawa> I didn't add tags recently, neither in bzr, nor in svn
[02:04] <pohutukawa> but maybe someone else did. let's see
[02:04] <jelmer> pohutukawa: for upgrading, see the UPGRADING file included with bzr-svn
[02:04] <jelmer> you may also find the "bzr svn-upgrade" command useful
[02:06] <pohutukawa> jelmer: bzr: ERROR: Unable to import bzr-rebase (required for svn-upgrade support): Version (0, 3, 0, 'final', 0) present, at least (0, 4) required
[02:06] <jelmer> pohutukawa: yeah, you need at least 0.4.4
[02:06] <jelmer> it might not be in the PPA
[02:06] <pohutukawa> looking at it, I haven't even checked out tags from SVN to the bzr branch
[02:07] <pohutukawa> just the trunk
[02:07] <pohutukawa> so it can't be SVN tags
[02:07] <pohutukawa> and I haven't (knowingly) added bzr tags
[02:07] <jelmer> pohutukawa: try running "bzr tags" in your bzr branch
[02:07] <jelmer> it will import tags from svn
[02:08] <pohutukawa> got 8 lines with names followed by a column of "?"
[02:09] <pohutukawa> most of these lines correspond with directories within the repo, but one is a tag from "way back" when I used SVN directly, and not through bzr
[02:10] <jelmer> pohutukawa: so one of the workarounds you can try is removing all tags in your local bzr branch
[02:10] <jelmer> and then pulling from the remote branch again
[02:10] <jelmer> and then pushing
[02:12] <pohutukawa> OK, first of all getting new bzr stuff from PPA for intrepid
[02:12] <pohutukawa> incl. bzr-svn 0.5.3
[02:14] <pohutukawa> jelmer: OK, with the new bzr the push worked, but ...
[02:14] <pohutukawa> ... it tells me about "Conflicting tags"
[02:14] <pohutukawa> which is a first good step. Now "cleanup" some tag mess
[02:19]  * jelmer gets some sleep
[02:19] <pohutukawa> jelmer: thanx for the help! everything seems clean now
[02:19] <jelmer> pohutukawa: push works again?
[02:19] <pohutukawa> don't even know where those tags came from, to be hones
[02:19] <pohutukawa> yes
[02:19] <jelmer> great
[02:20] <jelmer> pohutukawa: they should match the directories in tags/
[02:20] <pohutukawa> jelmer: thx, and have a good night. Bedankt!!!
[02:20] <jelmer> in the svn repo
[02:20] <pohutukawa> hmmm, OK
[02:20] <pohutukawa> how would I get those down now?
[02:20] <jelmer> pohutukawa: why is it that all newzealanders seem to speak a few words of Dutch? :-)
[02:20] <pohutukawa> 'Cause I'm German ;-)
[02:20] <jelmer> pohutukawa: bzr pull from the svn branch should import them
[02:20] <pohutukawa> and been to the netherlands quite often for playing Honkball and SCUBA diving
[02:21] <jelmer> ahh
[02:21] <pohutukawa> did a bzr pull, and they're back. Hpe they're consistent now
[02:21] <pohutukawa> jelmer: good night, then.
[02:22] <jelmer> gnight
[03:01] <lifeless> spiv: I don't think Remote*Format should have a network_name, but I can't remember if I added them or you did :P
[03:04] <Peng_> Kobaz: pong?
[03:18] <SamB> jelmer: you also aren't propagating import error messages from the import of sqlite3 ... assuming that you try to import it
[03:19] <poolie> igc, hi
[03:20] <poolie> what on earth is that push doing that it's taking so long?
[03:20] <lifeless> poolie: its not stacking
[03:20] <lifeless> bug 345169
[03:21] <poolie> oh ok
[03:22] <lifeless> I have a fix, running the full test suite now
[03:27] <igc> poolie: it's still going btw - up to 73M at a leisurely 1-2 kB/s
[03:27] <igc> lifeless: well done and thank-you
[03:30]  * SamB notes down the software he's noticed missing so far so he can tell the sysadmin about it ...
[04:04] <poolie> lifeless: are the development2 formats now obsoleted by 1.9?
[04:10] <lifeless> poolie: we don't have a development format thats newer than 1.9 in trunk at the moment, but I figured it was better to keep them and the alias live until we do have a newer one.
[04:14] <lifeless> lol its so easy to trigger the lp bug on notifications
[04:14] <poolie> of the connection staying open
[04:16] <lifeless> http://people.ubuntu.com/~robertc/LP%20Notification%20bug-Bazaar.png
[04:16] <lifeless> I can see ajax making this worse :P
[04:16] <lifeless> or better
[04:16] <lifeless> depending
[04:17] <lifeless> spiv: hola, we should coordinate
[04:29] <jamesh> lifeless: there used to be a real solution for that, but people complained about the URLs being ugly
[04:41] <poolie> possibly having ugly urls is better than looking like you don't know what's happening
[04:41] <poolie> esp if there's a 'close' button that strips off the notification bits
[05:01] <BasicOSX> Bug#345232 help?
[05:01] <BasicOSX> #345232
[05:02] <BasicOSX> uncharted territory for me I don't know where to start, when PQM fails to merge
[05:06] <lifeless> jamesh: I know
[05:06] <poolie> bug 345232
[05:06] <poolie> BasicOSX: i answered it
[05:06] <lifeless> jamesh: I was there :P
[05:06] <poolie> it's an easy fix
[05:06] <BasicOSX> ok
[05:07] <poolie> hth
[05:07] <poolie> ping me if it doesn't
[05:07] <poolie> but i'm going out to the shops for a bit first
[05:10] <BasicOSX> I guess I need to update the releasing doc? I do not see anything about changing _script_version in bzr
[05:11] <poolie> i think it's in there but if it's unclear please fix it
[05:12] <lifeless> BasicOSX: _script_version only needs the major version
[05:13] <lifeless> BasicOSX: oh, I'm wrong
[05:13] <lifeless> uhm
[05:13] <lifeless> BasicOSX: it does need changing :(
[05:13] <BasicOSX> np, I stumble you catch me, it's ok :-)
[05:16] <lifeless> BasicOSX: thank you for doing this
[05:16] <lifeless> rm is non trivial
[05:16] <BasicOSX> heh, I was going to thank you guys for being patient and helpful
[05:35] <thumper> lifeless: is there a bug about the notifications with examples on reproducability?
[05:39] <poolie> lifeless: re bug 330494, i propose to just remove the options
[05:39] <poolie> and tell people to use --format 1.9
[05:39] <poolie> and then, for the --format parameter, say see `help formats'
[05:57] <lifeless> thumper: notifications?
[05:58] <lifeless> poolie: well, I'm not against that per se, but as I commented in the bug, the list will be undiscoverable if we do that
[05:59] <poolie> even if we say 'see also'?
[05:59] <lifeless> poolie: help formats doesn't list all the formats
[05:59] <poolie> iiuc all of them are listed in other help topics?
[05:59] <lifeless> its now static text
[05:59] <lifeless> because help formats used to be the full list from the options and it was too long :P - same issue
[05:59] <poolie> ok
[06:00] <poolie> so i thought they were all included in either current-formats or other-formats
[06:00] <lifeless> I'd rather, TBH, have the option list short and detailless - hand crafted, and help formats be the full dynamic list it used to be
[06:00] <poolie> and that those were dynamic
[06:00] <poolie> just including the common ones?
[06:01] <lifeless> well, the filtered logic we have - hide hidden etc already exists
[06:02] <lifeless> hmm
[06:02] <lifeless> current-formats is sane, and other-formats has rest
[06:02] <lifeless> perhaps thats enough
[06:02] <lifeless> ok
[06:03] <lifeless> its a little long winded though
[06:12] <poolie> i agree
[06:12] <poolie> nm for now
[06:13] <poolie> the annoying thing about trying to fix one of these bugs is how it makes you notice more
[06:28] <jml> :)
[06:31] <poolie> igc, are you still here?
[06:35] <BasicOSX> What quick check can I do on the .tar.gz to confirm the pyrex-ifed files are in there?
[06:39] <lifeless> tar tzf | grep \\.c
[06:40] <lifeless> there should be about 4-5 files
[06:41] <lifeless> poolie, there is a fix up for bug 345169 if you want to do a review
[06:41] <BasicOSX> lifeless:  http://www.nopaste.org/p/apmIZgncK
[06:42] <poolie> k
[06:42] <lifeless> BasicOSX: looks fine to me
[06:42] <BasicOSX> k, "ignore" my post to the ML :-)
[06:45] <BasicOSX> 1:45am, sleepy, watching check-dist-tarball scroll makes my eyes heavy! will push and announce things in the morning.
[06:47]  * lifeless is gone
[06:49] <igc> poolie: yes
[06:58] <vila> hi all
[07:00] <poolie> hi vila
[07:01] <vila> lifeless: ping. working on parallel selftest. KnownFailure and UnavailableFeature deserialized, with 8 procs, selftest for ~17500 tests is down to 2/3 minutes
[07:01] <lifeless> vila: cool
[07:01] <lifeless> vila: I'm working on ec2parallel now
[07:01] <lifeless> vila: most of that code should not land in bzr itself, I only committed it there to get it to you
[07:02] <vila> lifeless: right, so where do you plan to land it ?
[07:02] <vila> lifeless: should I make bzr pluggable and go for plugin instead ?
[07:02] <lifeless> subunit [done], testtools [part of it is up for review already]
[07:02] <vila> lifeless: or do you target testtools/subunit ?
[07:02] <lifeless> and a small strategy bit in bzr itself
[07:03] <vila> subunit landed ? I saw a merge request for it yersterday but didn't check today
[07:04] <igc> poolie: see http://bazaar-vcs.org/SummerOfCode2009
[07:04] <lifeless> vila: done not landed
[07:04] <poolie> vila i'm reviewing your ftp server thing
[07:04] <vila> I modified ThreadsafeForwardingResult to add  wnFailure and UnavailableFeature deserialization, should I subclass instead ?
[07:04] <vila> poolie: thanks !
[07:04] <vila> poolie: I think I forgot to add a NEWS entry
[07:05] <lifeless> well, there aren't unittest standards for those aspects yet
[07:06] <vila> lifeless: but
[07:06] <vila> lol
[07:06] <lifeless> no but
[07:06] <lifeless> look in the subunit and testtools log
[07:07] <lifeless> you'll see addSkip
[07:07] <vila> lifeless: but TAP2SubUnit handles xfail it seems, but not TestProtocolServer
[07:07] <lifeless> we need to do something similar for all the custom things in bzr
[07:07] <vila> lifeless: I saw that, but couldn't decide if *some*things should stay bzr specific or not
[07:07] <lifeless> vila: on indeed, where te subunit wire protocol decides that X is already handledand subunit can't deserialise thats a plain ol bug
[07:08] <lifeless> so definitely -> fixes to subunit for that
[07:08] <lifeless> it would be clearer if I described my goals I think
[07:08] <lifeless> I want:
[07:08] <lifeless>  - a couple of small functions in bzr that specify how to turn a bzr test suite into an externally run suite
[07:10] <lifeless> vila: like http://paste.ubuntu.com/133468/
[07:10] <lifeless> vila: thats bzr specific
[07:10] <lifeless> vila: that, option parsing to enable this, is all that should be in bzr itself for this, IMO
[07:11] <lifeless> vila: and even that should be a helper bzr chooses to use rather than inaccessible in bzrlib
[07:13] <vila> lifeless: sounds reasonable, when asked to parallelize (-j n ?) do we want a warning and fallback to serialized selftest or just abort ? The idea is that selftest should still return coherent return codes
[07:14] <lifeless> vila: expand on that, I suspect you are missing an assumption
[07:15] <vila> if I run 'selftest -j n' and miss the dependencies, I want selftest to either abort (sorry, couldn't verify your tests ran) or just fallback to normal behavior (I couldn't parallelize, but I ran the tests anyway)
[07:16] <lifeless> either is fine; I'd abort myself
[07:16] <lifeless> vila: for now, just schlep plain diffs to me
[07:16] <vila> I slightly prefer that too, deal.
[07:16] <lifeless> I have a bunch of untangling of my sketch to do :P
[07:17] <lifeless> jml: which reminds me - could you please review my subunit merge request, its trivial
[07:17] <jml> lifeless: your _subunit_ one?
[07:17]  * jml looks
[07:17]  * vila mumbles: bundle when I send diffs and now diffs when I want bounded branches :)
[07:17] <vila> rats bound branches
[07:19] <jml> lifeless: one question: do you want to stop reading when there's a blank line?
[07:19] <vila> lifeless: oh, any idea why a 'bzr serve --port localhost:0' is coming from ? It stays alive and blocks the whole thing with zombies
[07:19] <vila> s/why/where/
[07:19] <lifeless> jml: end of file
[07:19] <jml> hmm. maybe readline() includes the terminating line char
[07:19]  * jml experiments
[07:19] <lifeless> mwhudson: so the answer is
[07:20] <lifeless> mwhudson: readlines buffers regardless of the buffer size
[07:20] <lifeless> mwhudson: readline doesn't
[07:20] <mwhudson> lifeless: ah, ok
[07:20] <vila> lifeless: once killed, everything terminate gracefully
[07:20] <jml> >>> news.readline()
[07:20] <jml> '--------------------\n'
[07:20] <lifeless> vila: not specifically, no
[07:20] <mwhudson> jml: yes, it does
[07:20] <mwhudson> it returns '' for end of file
[07:21] <jml> so bool(line) <=> EOF
[07:21] <jml> yay.
[07:21] <mwhudson> and '\n' for intermediate empty lines
[07:21] <mwhudson> right
[07:21] <vila> vila: well gracefully with still failures=1, errors=9, which I intend to address first
[07:21] <lifeless> the subunit fix is what gives us graceful concurrentp progress
[07:21] <jml> lifeless: approved.
[07:21] <mwhudson> for i in file: [07:22] <lifeless> jml: thanks
[07:22] <jml> iter takes a second parameter?!
[07:22] <mwhudson> or something like that
[07:22]  * jml keeps learning Pythno
[07:22] <lifeless> mwhudson: meep
[07:22] <mwhudson> yep
[07:22] <lifeless> mwhudson: also, for i in file: == for i in file.readlines() :( -- buffers 1K or so suckage
[07:22] <mwhudson> well
[07:22] <mwhudson> different implementations i think
[07:23] <lifeless> mwhudson: so I argue ~=
[07:23] <mwhudson> yes, ok
[07:23] <lifeless> mwhudson: no, I started with for i in file
[07:23] <lifeless> mm, may need to checkt he C code
[07:23] <lifeless> regardless, it suckaged
[07:24] <mwhudson> lifeless: i'm not disagreeing with your observations, just your deductions
[07:25] <mwhudson> the code implementing readlines and iteration for files is entirely disjoint
[07:25] <mwhudson> i can believe both buffer though
[07:25] <mwhudson> and yes, looks like readline() is yet another case
[07:25]  * mwhudson reads code, gets confused
[07:26] <mwhudson> too late in the day to be thinking anyway
[07:26] <vila> lifeless: also, from a high level, splitting by concurrency only once doesn't give the best results here with 8 procs, some processes finish far quicker than others. IMO, once things stabilize enough, we should look at making each process handles *several* test slices instead of just one
[07:28] <vila> lifeless: roughly, the actual 200 seconds can go down to 120 or something I think
[07:28] <lifeless> mwhudson: :P
[07:28] <lifeless> vila: well
[07:28] <lifeless> vila: I appreciate that
[07:29] <lifeless> vila: ideally it streams (say) 30 seconds worth at a time
[07:29] <lifeless> or we annotate each test with a cost and make the partitions have equal cost
[07:32] <vila> Could be, I don't strive for perfection there though, if I can just feed the processes a bit more, I'd be happy (and end up with a simpler code I think). Evaluating test cost upfront or based on previous execution sounds a bit fragile/hard
[07:32] <vila> but as I said, not something I want to decide on without a first version running smoothly
[07:33] <vila> lifeless: by the way, any idea when you could have a look a loom tests, I still have failures and no enough understanding to fix them :-/
[07:36] <poolie> yay activity bars
[07:36] <AfC> And yet *another* person burned by Ubuntu only shipping bzr version 1.3!
[07:37]  * AfC scratches another chalk mark on the wall...
[07:38] <poolie> it should be fixed soon
[07:38] <poolie> at least in backports
[07:47] <poolie> lifeless: i'm reading your patch then i'm going to go
[07:47] <lifeless> AfC: btw, with 1.13 shipped you should be seeing better network behaviour already
[07:48] <AfC> lifeless: I'll keep an eye out - the bzr package on my distro is upgraded already, but I haven't done anything demanding software wise this week so I haven't had a chance to form a subjective view yet.
[07:58] <vila> lifeless: no more zombies no 'bzr serve' hanging processes, WNOHANG is *not* your friend :)
[07:59] <lifeless> vila: its not the parallel suite causing it
[07:59] <lifeless> vila: it happens on pqm too
[07:59] <vila> lifeless: you mean the 'bzr serve' one ?
[07:59] <lifeless> yes
[08:00] <vila> well, at least I got read of the zombies... or not, I'll keep an eye on it but WNOHANG and calling waitpid *before* joining the thread didn't sound right
[08:03] <vila> lifeless: right, its' back, but indeed, far less zombies as expected
[08:03]  * vila acquires target
[08:10] <lifeless> so
[08:10] <lifeless> I have BZR_PARALLEL=subprocess working
[08:10] <lifeless> but fugly batched output again
[08:11] <vila> lifeless: send diffs :-)
[08:12] <lifeless> yes dear
[08:12] <vila> :-)
[08:14] <lifeless> http://paste.ubuntu.com/133493/
[08:16] <vila> lifeless: thanks
[08:16] <AfC> lifeless: first impression: I have no idea whether it's faster or not, but you're giving more (and cleaner) feedback in progress & bytes transfered etc so it *seems* more responsive. Well done
[08:17] <AfC> although I wish there was a way to kill off the silly progress bar and thereby have more room to report the actual information
[08:19] <poolie> afc: are you talking about testing or in general?
[08:20] <AfC> poolie: Robert wanted to know if I subjectively experienced 1.13 as faster since we're one of the few communities who publicly uses the bzr: protocol (have adopted it WAY to early)
[08:21] <poolie> ok
[08:21] <AfC> poolie: and, of course, I push over bzr+ssh like everyone else but do a fair bit of it (none of this firing an email off to bug buddy nonsense)
[08:21] <poolie> just wasn't sure which irc thread you were on
[08:21] <jamesh> the new progress reporting rocks, irrespective of actual speed improvements
[08:22] <poolie> jamesh: thanks; i thought it might
[08:22] <poolie> also it makes silly slow or wasteful bits obivous
[08:22] <jamesh> actual speed improvements welcomed too
[08:22] <poolie> which is good
[08:22] <Guest7068> amen
[08:22] <poolie> 1.14 should have both
[08:22] <AfC> Like I said, just need to kill of the [###      ] from appearing half way into an operation.
[08:22] <poolie> hm
[08:22] <vila> poolie: regarding pb/ui, we definitely need a way to override them unconditionally with ENV variables (until we get a *perfect* auto-detection, which could take some time :-)
[08:22] <AfC> [That's half :) and half :( ]
[08:22] <poolie> so you just want the text progress not the [######] bit?
[08:22] <poolie> and not the activity?
[08:23] <AfC> poolie: I think so
[08:23] <poolie> vila: i agree, it's high on my list
[08:23] <vila> poolie: great !
[08:23] <poolie> by activity i mean not the network speed?
[08:23] <AfC> A single cell / - \ | / - spinner would be fine, whereas all the numbers and status and such is great.
[08:24] <AfC> It's a bit weird that there are two status fields (and in 80 chars, both are truncated to the point where you can't read anything) but at least it gives the impression that its doing something.
[08:24] <AfC> Which is what Git has done all along, so people thought it was "fast" whereas Bazaar was 0/5 forever.
[08:24] <jamesh> if bzr said "1/5" they'd probably think it was faster
[08:24] <AfC> poolie: (to be clear, bzr's idea of network speed is great)
[08:25] <AfC> jamesh: perhaps, but the problem is it being camped out on 0/5 or 1/5 for 30 minutes. That wasn't so cool.
[08:25] <jamesh> true.
[08:25] <AfC> "hung"
[08:25] <poolie> exactly
[08:25] <poolie> that's why i did it
[08:25] <poolie> so, um
[08:26] <poolie> opinions seem to vary about the progress bar bit
[08:26] <poolie> robert wants it to be bigger
[08:26] <poolie> i guess so he can see it in peripheral vision
[08:26] <poolie> personally i think a spinner to say "something's happening" and then a numeric count may be better...
[08:26] <poolie> i was going to try making them fractions of your terminal width
[08:27] <poolie> this stuff is hard to judge until people see it
[08:27] <poolie> for interest, what is your terminal? 80 cols? and a real xterm, or something inside an ide?
[08:27] <poolie> (by which i include emacs :)
[08:27] <jamesh> I like the smaller progress bar
[08:27] <jamesh> it is large enough to get an idea of overall progress, while leaving enough room for the other info
[08:28] <poolie> also we should cut out some of the less useful text bits
[08:28] <poolie> which will make the right side less crampde
[08:28] <poolie> cramped*
[08:32] <vila> I'd love to see more "semantic" info in the pb, yet, the network speed is a must, the  [######] didn't carry understandable info  so far, I prefer the xx/nn part myself, all of this being *totally* subjective of course
[08:33] <poolie> agree
[08:33] <poolie> it requires some kind of audit of code that's generating pb events
[08:33] <poolie> which i've started
[08:33] <vila> and obeying SIGWINCH is of course a must so that I can resize my window when I want more info :)
[08:33] <poolie> :)
[08:33] <poolie> soon, that too
[08:33] <vila> woohoo
[08:33] <AfC> poolie: 80 chars, in a gnome-terminal
[08:33] <poolie> that search got a bit hung up on what to do about generators
[08:33] <poolie> afc ok thanks
[08:37] <vila> poolie: 80 chars should be the default when deciding how to split the info in the pb IMHO
[08:37] <poolie> yes
[08:37]  * vila uses a 24" display so that 3 emacs windows can be shown
[08:39] <vila> each of which are 80 chars wide of course
[08:43] <lifeless> poolie: I want it bigger, and doing stuff :P
[08:43] <poolie> you sound like a spam mail :)
[08:43] <poolie> anyhow it will be
[08:43] <poolie> but good night
[08:52]  * igc dinner
[10:07] <mwhudson> this doesn't make a great deal of sense to me: http://pastebin.ubuntu.com/133536/
[10:08] <lifeless> hmm, yes, patch needed
[10:12] <mwhudson> it's even documented
[10:21] <lifeless> mwhudson: well,it can be changed
[11:36] <AfC> Well, surprise. After being told the GNOME vcs survey wouldn't be used as evidence, it was used to drive the migration to Git after all. Another cause lost.
[11:39] <AfC> and that's going to make me even more unpopular in that crowd. {sigh} what else is new
[11:40]  * AfC is tired of fighting
[11:40] <lifeless> AfC: :(
[11:41] <AfC> I guess I should blog pointing out all the issues I raised in January, but that wouldn't really help anything.
[12:40] <Stavros> hello
[12:40] <Stavros> how can i check out a repository but not include the .bzr dir?
[12:40] <LeoNerd> You mean like   bzr export   ?
[12:40] <Stavros> i want to have a production static site but i don't want people to be able to check out the history
[12:40] <Stavros> hmm
[12:40] <Stavros> probably, let me look
[12:40] <lifeless> or get the bzr-upload plugin
[12:40] <Stavros> oh, bzr export looks like it
[12:41] <Stavros> let me check to see what bzr-upload does
[12:41] <Stavros> is that automatic?
[12:44] <Stavros> hmm, i ran setup.py for bzr-upload but don't see it in the list of available plugins...
[12:48] <Peng_> Stavros: Just put it in ~/.bazaar/plugins or bzrlib/plugins.
[12:48] <Peng_> Stavros: (But name it "upload" instead of "bzr-upload" or "trunk" or whatever.)
[12:48] <SamB> the other option would be to just disallow fetching of the .bzr dir ;-)
[12:49] <Peng_> SamB: Yeah, I do that, but it's less safe, in case you screw up the web server config or permissions or whatever.
[12:50] <Stavros> agreed
[12:50] <Stavros> let me check it out again
[12:51] <Stavros> ah great, it works now, thanks
[12:52] <Stavros> this is brilliant
[12:53] <Stavros> hmm, it breaks
[12:53] <Stavros> http://dpaste.com/16433/
[12:58] <Stavros> how is "contact.html" an invalid relative url for the transport?
[13:00] <Stavros> any idea what relpath should be, for put_bytes?
[13:06] <Stavros> wow, it doesn't support utf8
[13:38] <jelmer> SamB: sqlite3 is included with Python >= 2.5
[13:40] <SamB> jelmer: I know! it must have gotten deleted or something?
[13:41] <SamB> in fact, it's the _sqlite3 module that seems to be missing ...
[13:46] <SamB> jelmer: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=2599#a2599
[13:53] <Peng_> SamB: Maybe you didn't have sqlite's headers installed when compiling Python?
[13:53] <SamB> it wasn't me!
[13:53] <SamB> I'm not the sysadmin
[13:53] <Peng_> Well, still.
[13:54]  * Peng_ goes /away again
[13:54] <SamB> does it still install the .py files for sqlite3 even when it can't build the extension?
[13:55] <Peng_> Hmm, I would be surprised if it did, but it's possible.
[13:55]  * Peng_ really goes away again
[14:22] <Stavros> i did a bzr add * and it added ignored files, how can i undo that?
[14:36] <SamB> hmm. this issue is documented on http://www.linuxquestions.org/questions/slackware-14/python-bug-in-current-633384/
[14:38] <SamB> jelmer: apparantly slackware doesn't build the _sqlite3 module :-(
[14:38] <jelmer> SamB: it's included with python..
[14:38] <SamB> ... because it doesn't include sqlite
[14:38] <jelmer> SamB: python includes sqlite afiak
[14:39] <SamB> the whole library ?
[14:39] <SamB> mine, at least, is dynamicly linked
[14:40] <jelmer> SamB: yes, it includes the sqlite library itself as well IIRC
[14:40] <jelmer> SamB: it can probably use the system sqlite as well
[14:42]  * SamB prints a copy of http://trac.edgewall.org/wiki/TracOnSlackware12 to show to his sysadmin
[14:45]  * SamB wishes it was easier to kill an ssh session whose connection has been dropped by a router ...
[15:02] <jam> SamB: <enter> ~ .
[15:03] <jam> One of the magic commands for ssh
 ~
[15:03] <jam> is the give meta-commands
[15:03] <jam> like ^[ for telnet
[15:03] <jam> and "."  Quick call (but beware it's *really* nisy here :)
[15:04] <vila> s/nisy/noisy/
[15:05] <jam> sure
[15:05] <jam> we'll make it quick
[16:49] <mcasadevall> Does bzr-svn limit the formats a bazaar repo can be?
[16:49] <beuno> mcasadevall, AIUI, it has to be rich-root
[16:49] <beuno> but jelmer is the expert
[16:49] <mcasadevall> Well, I'm having stacking issues which makes things annoying :-/
[17:24] <pygi> folks
[17:24] <pygi> download page links to wrong release for windows platform
[17:24] <pygi> (1.12, outdated)
[17:25] <sidnei> pygi: i can fix that
[17:25] <pygi> sidnei, thanks :)
[17:25] <sidnei> in fact, anyone can, its a wiki
[17:25] <pygi> well ... that's true xD
[17:25] <pygi> sidnei, but I feel lazy atm, so would you? :)
[17:25] <pygi> please? :)
[17:25] <sidnei> if i remember my password :)
[17:29] <sidnei> pygi: done, thanks for noticing!
[17:29] <pygi> haha, np, thank yuo sidnei :)
[17:29] <jelmer> mcasadevall: hi
[17:29] <jelmer> mcasadevall: it has to be some rich root format
[17:29] <mcasadevall> :-/
[17:29] <jelmer> mcasadevall: but stacking shouldn't be a problem
[17:29] <mcasadevall> can you convert an existing repo to rich root format?
[17:30] <jelmer> mcasadevall: what's not working exasctly, and what format are you using?
[17:30] <mcasadevall> I have a KnitPack
[17:30]  * mcasadevall is not a bazaar gurur
[17:30] <jelmer> mcasadevall: KnitPack isn't really a format. What does "bzr info" report?
[17:30] <mcasadevall> Standalone tree (format: unnamed)
[17:30] <mcasadevall> Nothing useful.
[17:33] <mcasadevall> jelmer, what do I type to convert it?
[17:33] <jelmer> mcasadevall: what format did you upgrade to ?
[17:33] <mcasadevall> I didn't upgrade anything
[17:33] <jelmer> mcasadevall: "bzr upgade --1.9-rich-root"
[17:33] <mcasadevall> I just did a bzr pull
[17:33] <jelmer> mcasadevall: in both the branch and the shared repository
[17:34] <mcasadevall> seems to be working :-)
[17:35] <mcasadevall> I don't have commit rights to where I pulled.
[17:35] <mcasadevall> jelmer, this is what I pulled https://code.edge.launchpad.net/~ubuntu-core-dev/debian-installer/ubuntu
[17:36] <jelmer> mcasadevall: what are you trying to do exactly?
[17:36] <mcasadevall> push to Launchpad without spending two days waiting for it to push
[17:37] <jelmer> mcasadevall: but where is bzr-svn involved?
[17:37] <mcasadevall> jelmer, the repo I pulled with was made with it
[17:37] <jelmer> https://code.edge.launchpad.net/~ubuntu-core-dev/debian-installer/ubuntu
[17:37] <jelmer> you mean?
[17:38] <mcasadevall> yeah
[17:38] <jelmer> mcasadevall: that seems to already support stacking though
[17:38] <jelmer> mcasadevall: from the lp page: Packs 5 rich-root (adds stacking support, requires bzr 1.6.1)
[17:38] <mcasadevall> No, I know
[17:39] <mcasadevall> but try pulling, then pushing to launchpad
[17:39] <mcasadevall> it won't work.
[17:39] <jelmer> mcasadevall: so I'm not quite sure what's not working
[17:39] <jelmer> mcasadevall: so pushing a new branch to launchpad based on that branch doesn't stack? or it doesn't work at all?
[17:40] <mcasadevall> Doesn't stack at all
[17:40] <jelmer> mcasadevall: it would try to stack on lp:~cjwatson/debian-installer/main, which has no shared history
[17:41] <jelmer> mcasadevall: as that is the development focus
[17:41] <mcasadevall> argh
[17:41] <mcasadevall> so what do I do ?
[17:42] <jelmer> mcasadevall: ask the debian-installer team to change the development focus, or alternatively you can ask for support for stacking on arbitrary branches in launchpad
[17:42] <mcasadevall> ..............
[17:42] <zooko> Anybody going to PyCon?
[17:44] <jelmer> mcasadevall: Bazaar supports stacking on arbitrary branches just fine, this is (as I understand it) an issue specific to launchpad
[17:44] <mcasadevall> ...................................................................
[17:44] <mcasadevall> ARGH
[17:46] <eferraiuolo> Looking for some help on setting up the bzr-email plugin
[17:47] <eferraiuolo> Where do I set the configuration? and can I set it globally for all users?
[18:04] <jelmer> mcasadevall: so you might want to ask in #launchpad instead
[18:05] <jelmer> mcasadevall: hmm
[18:05] <jelmer> mcasadevall: maybe "bzr push --stacked-on" works, have you tried that yet?
[18:05] <jelmer> eferraiuolo: in .bzr/branch/branch.conf or ~/.bazaar/locations.conf
[18:05] <jelmer> eferraiuolo: global configuration in ~/.bazaar/bazaar.conf
[18:06] <eferraiuolo> the global then is per user
[18:07] <eferraiuolo> which I think that's what I want, since I have a smart server setup with a dedicated bzr shh user...
[18:18] <mcasadevall> jelmer, nope
[18:19] <mcasadevall> (doesn't work that is)
[18:24] <eferraiuolo> I'm getting (when pushing to a remote smart-server): bzr: ERROR: Server sent an unexpected error: ('error', "cannot concatenate 'str' and 'NoneType' objects")
[18:24] <eferraiuolo> on 1.13 both the server and my local machine
[18:28] <NfNitLoop> eferraiuolo: sounds like a bug.  Does ~/bzr.log have any more detail?
[18:33] <eferraiuolo> NfNitLoop: I'll check now on both my machine and the server
[18:37] <eferraiuolo> NfNitLoop: I have stacks on both my server and local machine
[18:37] <mwhudson> beuno: um yes, loggerhead's test suite, mumble
[18:39] <beuno> mwhudson, :)
[18:39] <beuno> you can ignore that safely
[18:39] <beuno> I had no comments on the code, so I threw that in!
[18:43] <mwhudson> hrumpf!
[18:43]  * mwhudson uncommits from launchpad trunk :/
[18:44] <beuno> ew
[18:48] <mwhudson> beuno: did you see the other branch?
[18:48] <beuno> mwhudson, I don't think so, no
[18:49] <mwhudson> beuno: https://code.edge.launchpad.net/~mwhudson/loggerhead/sorry-rob/+merge/4648
[19:00] <beuno> mwhudson, freenode and my ISP hate eachother
[19:00] <beuno> last I said was that I hadn't seen any other branch
[19:00] <mwhudson> beuno: https://code.edge.launchpad.net/~mwhudson/loggerhead/sorry-rob/+merge/4648
[19:00] <mwhudson> (that's the only message you missed)
[19:01] <beuno> sorry-rob?  :)
[19:01] <beuno> it's odd that there aren't any requested reviews on that branch
[19:02] <beuno> mwhudson, in line 74 of the diff
[19:02] <beuno> why are you importing errors?
[19:03] <mwhudson> it's called sorry-rob because it does things to the bzrlib api lifeless probably won't be super pleased to see
[19:04] <mwhudson> beuno: ah, because it was needed at one point :)
[19:07] <alevine> i'm trying to use the latest bzr-svn and I get "unable to load plugin 'svn'" . In .bzr.log I am getting ImportError: No module named foreign
[19:07] <alevine> anyone have an idea?
[19:07] <jelmer> alevine, you need a newer version of bzr
[19:09] <alevine> jelmer, ok thanks. any recommendations on the best way to do this on ubuntu? at the moment I have just compiled subvertpy myself, should I do the same with bzr?
[19:09] <jelmer> alevine, you can retrieve all packages from the PPA
[19:10] <alevine> jelmer, the bzr ppa?
[19:10] <jelmer> alevine, yep
[19:11] <alevine> thanks
[19:15] <LarstiQ> though bzr-svn still needs uploading for !intrepid
[19:16] <LarstiQ> jelmer: is the svn credential store supposed to work set from authentication.conf? I got StopIteration on creds.next(), and python -c 'from subvertpy import ra; ra.Auth(ra.get_simple_provider())' segfaults
[19:17] <alevine> I'm ok with manually installing bzr-svn, but I can't seem to get subvertpy to install properly
[19:17] <alevine> I get  subprocess post-installation script returned error exit status 1
[19:17] <jelmer> alevine, you might have to remove the files that got installed when you built subvertpy yourself
[19:17] <jelmer> LarstiQ, latest subvertpy?
[19:19] <LarstiQ> jelmer: I think so, I'll recheck after I clean the fridge
[19:19] <LarstiQ> alevine: yeah, apt-get remove subvertpy; rm -rf /usr/lib/python2.5/site-packages/subvertpy; apt-get install bzr-svn; did the job for me
[19:20] <alevine> ahh, thanks, that seemed to work
[19:23] <mwhudson> beuno: hello again
[19:23] <mwhudson> beuno: i talked to jml the other day about the annotate page
[19:24] <mwhudson> beuno: and we came up with the idea that the default view of a file should be just a view
[19:24] <beuno> no annotation?
[19:24] <mwhudson> and that the annotate information should be on a separate page/loaded with ajaz
[19:24] <mwhudson> ajax
[19:24] <beuno> hm
[19:24] <beuno> or
[19:25] <beuno> the annotation information could be fetched through ajax on that same page
[19:25] <beuno> I'm thinking if we loose a lot or not really
[19:27] <beuno> mwhudson, if you request a review for: https://code.edge.launchpad.net/~mwhudson/loggerhead/sorry-rob/+merge/4648
[19:27] <beuno> I'll review it  :)
[19:27] <beuno> can't otherwise
[19:27] <beuno> as for annotate view..
[19:27] <beuno> is it that much slower?
[19:27] <mwhudson> for, say, sql_select.cc, yes
[19:28] <mwhudson> beuno: requested :)
[19:29] <beuno> mwhudson, ok, so, we could not provide it by default, and bring in that information via ajax on request
[19:29] <beuno> how does that sound?
[19:29] <mwhudson> yes
[19:29] <beuno> instead of havinf 2 different pages
[19:29] <mwhudson> i was only going to keep the separate page for the noscripters
[19:30] <beuno> ah
[19:30] <beuno> I guess that sounds good then
[19:33] <mwhudson> beuno: thanks for the reviews :)
[19:33] <mwhudson> i've actually been trying quite (pointlessly?) hard to cater to the noscript case for lh
[19:36] <beuno_> I hate irc
[19:38] <beuno_> well, my ISP at least
[19:39] <beuno> mwhudson, did the canonical IRC die for you as well?
[19:40] <mwhudson> beuno: nope, but i see you ping-timeouting
[19:40] <beuno> ok
[19:41] <beuno> so it's argentina
[19:41] <beuno> no access to *canonical.com
[19:41] <beuno> fun
[19:41] <jam> igc: ping
[19:43] <igc> hi jam
[19:44] <jam> hi igc, I was wondering where you got to with the iteritems() code?
[19:44] <jam> If my last message helped point you towards what I was thinking
[19:45] <spiffytech> How can I create a branch of my program? All I can find on Google is branching from random online repos.
[19:45] <igc> jam: I spent nearly all of yesterday on GSoC stuff so no progress since my email, sorry
[19:46] <igc> jam: your reply looked really helpful but I'm yet to apply it
[19:47] <igc> jam: I have some other things still ahead of that in my queue: tweaking the add-view patch & landing content filtering
[19:47] <jam> igc: k. I ended up finding 2 or 3 other things to work on today...
[19:47] <igc> jam: I did push through those minor tweaks to Node __repr__ though
[19:47] <jam> got a bit sidetracked seeing that btree overhead was very high for large repos
[19:48] <jam> and still have some gc.make_delta() tweaks I want to look at
[19:48] <jam> igc: so if you could leave me a message before you stop tonight with where you get to. as I'm likely to poke at it if you can't finish it by tomorrow
[19:49] <igc> jam: yeah, I was seeing additional overhead in the btree layer profiling send on bzr.dev vs brisbane core
[19:49] <jam> igc: that is something different, and is probably just because we have 5x more items to read now
[19:49] <igc> I couldn't explain it though and the profiler wasn't helping with weird count #s for some iterators
[19:49] <jam> in the past, at most we had 200 deltas for an inventory, now we have 255 chk pages + root + inv node
[19:50] <jam> not to mention the chk index is much larger than the old .iix
[19:52] <jam> oh, and looking closer, the fact that .cix don't have a size entry in pack-names is probably hurting a lot
[19:52] <jam> as we call "transport.get_bytes()" in that case
[19:52] <jam> which means we page in the *whole thing*
[19:52] <jam> which probably destroys the existing page-cache, etc.
[19:52] <jam> :(
[19:53] <igc> jam: I'm back up the hospital today after lunch for chemo so I'm not confident I'll get the iteritems stuff completed before then
[19:53] <jam> np
[19:53] <igc> jam: on the bright side, you latest patch sounds sweet
[19:53] <igc> s/you/your/
[19:54] <jam> The one I'm working on now for btree code, seems to drop "bzr pack lp" another minute or so (~12 -> ~10.5)
[19:54] <igc> I gather that will help branch (out of a shared repo) time?
[19:55] <jam> hmm... maybe I'm wrong, as it seems to have a size now
[19:56] <jam> igc: it shouldn't help branch anymore
[19:56] <jam> as the streaming code changed it
[19:56] <jam> so that 'bzr branch in out' doesn't do a full repack anymore
[19:56] <jam> but it *does* have implications for "time to insert" "autopack" and the infrequent "bzr pack" times
[19:56] <jam> Oh, and it might help bzr branch
[19:56] <jam> as the btrees end up writing 400k entries
[19:56] <jam> which is what i'm fixing up
[20:08] <thumper> morning
[20:23]  * igc breakfast
[20:48] <mwhudson> beuno_: so you know the way i removed all the "get multiple file changes at once" code from LH?
[20:49] <mwhudson> i probably should put it back :)
[20:49] <mwhudson> at least i can do it more sanely this time
[20:49] <beuno_> mwhudson, what's the use case for it?
[20:50] <mwhudson> beuno_: when you click expand all on the changelog page
[20:50] <mwhudson> and maybe something similar for the revision page
[20:50] <mwhudson> not so sure about that
[20:52] <beuno> ah, right
[20:54] <beuno> so you would make two different tyoe of calls depending on if the user expanded all or just one?
[20:54] <beuno> some rad optimizing you're doing
[20:54] <mwhudson> yeah
[20:54] <mwhudson> maybe i won't care for now
[20:55] <beuno> YUI has some nice chaining methods
[20:55] <beuno> you could chain the requests
[21:01] <mwhudson> oh, interesting
[21:09] <LarstiQ> does anyway here have a hardy system around?
[21:09] <LarstiQ> s/way/one/
[21:09] <beuno> LarstiQ, I do
[21:10] <LarstiQ> beuno: ok, I'm merging the bzr-svn 0.5.3 unstable packaging into the hardy-ppa packaging, but I'm not certain of all of it
[21:10] <LarstiQ> beuno: could you give the package a testspin before I upload to the ppa?
[21:10] <beuno> LarstiQ, sure
[21:10] <LarstiQ> sweet :)
[21:11] <beuno> regular bzr ppa?
[21:14] <shikibu> I'm a new user of bzr, and I just renamed a symbolic link whose content was under version control. (cp -pr the content of src@ to src2/, then rm src@, then mv src2 src). Now bzr figures all my source code is gone. How can I recover?
[21:16] <shikibu> verterok: perhaps you'll give me a hint?
[21:16] <LarstiQ> beuno: yes
[21:16] <LarstiQ> beuno: I'll ping you when I've got the source/dsc built
[21:17] <beuno> LarstiQ, cool
[21:17] <verterok> shikibu: you should do: rm src@; bzr mv <src-symlink-dest> src
[21:18] <verterok> shikibu: if that was the only change, do a bzr revert, and start over :)
[21:18] <shikibu> ah, i see. but perhaps I must do this for each element that was beneath src@?
[21:19] <shikibu> i think it's the only change, but I wanted bzr to help me feel confident of that before live deploy!
[21:19] <LarstiQ> shikibu: could you pastebin `bzr status` output?
[21:20] <shikibu> sure
[21:20] <verterok> shikibu: do you want to  remove the symlink, and replace it with a real dir?
[21:20] <shikibu> yes, that's what I want.
[21:20] <shikibu> It was a symlink because I was working partly in eclipse workspace
[21:20] <verterok> shikibu: what's the target of the symlink?
[21:21] <shikibu> https://pastebin.canonical.com/15214/
[21:22] <shikibu> Oh, I see; src@ links to eclipse-workspace/src. so yes, I need to do what you said first "bzr mv eclipse-workspace/src src"
[21:23] <shikibu> i think part of what I wanted was to get bzr to tell me exactly what it now thought was missing
[21:24] <mwhudson> beuno, rockstar: another loggerhead branch up for review :)
[21:24] <rockstar> mwhudson, does this fix all the problems?
[21:25] <shikibu> bzr: ERROR: Not a branch: "/...../workspace-eclipse/3874 CD Distributor form/src/".
[21:25] <verterok> shikibu: seems like the symlink target isn't under the same branch
[21:26] <shikibu> can I get bzr to give me an inventory of what is in the branch?
[21:26] <mwhudson> rockstar: no, not really
[21:26] <rockstar> mwhudson, :)
[21:26] <verterok> shikibu: bzr ls
[21:26] <verterok> shikibu: if that's the case, you need to cp/mv and then bzr add
[21:26] <LarstiQ> shikibu: it doesn't like my identiy url or something
[21:26] <shikibu> got it. thanks for your help (again)
[21:27] <verterok> shikibu: np :)
[21:27] <shikibu> LarstiQ: hmm. that's funny. and it's my group that would like you to post a bug about it ; )
[21:27] <shikibu> can you tell me LarstiQ what it looks like?
[21:29] <shikibu> hay LarstiQ nevermind; I just realized that i used the wrong pastebin.
[21:29] <shikibu> I think i'm good now tho, thanks for offering to look.
[21:40]  * LarstiQ frowns at the ppa builder
[21:42] <LarstiQ> aha
[21:45] <LarstiQ> mbp, jam: could one of you approve me for bzr-beta-ppa team so I can upload the bzr-svn hardy package there before uploading it to bzr-ppa?
[21:48]  * LarstiQ falls asleep
[21:48] <LarstiQ> beuno: I'll check back with you tomorrow
[21:49] <beuno> LarstiQ, whenever you like. The server isn't going anywhere
[21:49] <LarstiQ> I hope so :)
[21:51] <jam> LarstiQ: approved
[21:51] <beuno> hey hey poolie
[21:54] <poolie> hi beuno
[21:55] <beuno> poolie, how are you?
[21:56] <poolie> good thanks
[22:01] <lifeless> moin
[22:01] <poolie> lifeless: want to join us?
[22:01] <poolie> even if not you're welcome to come today
[22:06] <lifeless> poolie: :P yes, was honouring natrures callw when you rang
[22:08] <lifeless> can you hear me
[22:08] <mwhudson> lifeless: no
[22:30] <BasicOSX> Generating doc/developers/performance.png
[22:30] <BasicOSX> Dot not installed; skipping generation of doc/developers/performance.png
[22:31] <BasicOSX> I assume that is dot2tex?
[22:31] <thumper> abentley: ping
[22:32] <lifeless> BasicOSX: graphviz is the package
[22:33] <BasicOSX> ty
[22:48] <glyph> is the hardy ppa still missing bzr-gtk?  When I asked yesterday johnf said he'd fix it.