[00:00] <igc> morning
[00:39] <jelmer> hmm, 43 % of all bzr-svn bugs will be fixed in 0.4.11. I wonder if we'll be able to make that 50...
[00:39] <spiv> Heh.
[00:43] <spiv> jelmer: hmm, current 'stable' branch is extremely slow for me when pulling my twisted import
[00:44] <jelmer> spiv: What step is slow?
[00:44] <spiv> jelmer: the progress bar keeps jumping back.  http://rafb.net/p/SPzipu87.html
[00:46] <jelmer> looks like it's finding tags
[00:46] <jelmer> does twisted have an awful lot of them perhaps?
[00:47] <spiv> I guess it might.
[00:47] <spiv> $ svn ls svn+ssh://cvs.twistedmatrix.com/svn/Twisted/tags | wc -l
[00:47] <spiv> 152
[00:48] <spiv> Approximately one for each release (including rc and alpha releases) until Twisted 2.2 or so, when the release process changed, I think.
[00:49] <spiv> I suspect Twisted isn't going to be unusual in doing that :)
[00:53] <ChristopheT> jam: Are you sure chmod is to set g+w?  I tried without setting the proper umask on the server and g+w was not set.
[00:54] <ChristopheT> Anyway, I have a small patch available.  Do I send it to the ML or do you want to see it first?
[02:16] <Odd_Bloke> Moin.
[02:16] <jelmer> hi Odd_Bloke
[02:21] <jelmer> Odd_Bloke: You're not in the UK?
[02:27] <Odd_Bloke> jelmer: Yeah, but have weird sleeping patterns. :D
[02:29] <jelmer> ah :-)
[02:30] <spiv> jelmer: I filed a bzr-svn bug for you, I got an error when I left that bzr pull run to completion.
[02:31] <jelmer> spiv: Thanks
[02:37]  * Odd_Bloke --> breakfast
[02:37] <jelmer> ok, that's even more weird than my sleeping patterns
[02:55]  * igc lunch
[03:04] <libwilliam> I've got a question/comment. I was wondering why bzr modified isn't in the user reference list. Also it seems like bzr ls should have a --modified option.
[03:04] <Odd_Bloke> jelmer: :D
[03:04] <libwilliam> Also is there a way to get a list of removed files. That would be another option I think bzr ls should have.
[03:05] <libwilliam> i know i can get them with status, but I meant the removed files alone
[03:05] <Odd_Bloke> I decided to be on Australian time for a while, and am now adjusting back for something I'm doing this weekend.
[03:05] <Odd_Bloke> Also, I work best at night.
[03:07] <bob2> bzr status -S | awk '/^R/ {print $2}' or something
[03:11] <libwilliam> bob2: ill mess around with that, thanks, didnt think about that
[03:20] <Odd_Bloke> poolie: When you're free, a chat would be good. :)
[03:27] <meteoroid> poolie rawks :-P
[03:31] <meteoroid> i'd like to expose my bzr branches over http and i'm unclear from the documentation on how to do so
[03:31] <meteoroid> any help would be much appreciated :)
[03:31] <Peng> meteoroid: You can just put them in some location served by Apache or whatever. You don't need to do anything else.
[03:32] <meteoroid> i have heard that, but had trouble with it in the past
[03:32] <Peng> You *can* set up an HTTP smart server if you want to, but it's not necessary.
[03:32] <meteoroid> are there any docs?
[03:32] <meteoroid> i'd like to set up for http commit
[03:32] <Peng> meteoroid: Well, you shouldn't have.
[03:32] <Peng> ??
[03:32] <meteoroid> so people don't need ssh
[03:32] <meteoroid> i know i shouldn't have, that's why i ask about docs..
[03:32] <Peng> Oh.
[03:32] <meteoroid> i must have missed something..
[03:32] <Peng> Err, I'm not sure you can.
[03:32] <meteoroid> and yeh, a lot of my collaborators are ubuntu users, so getting bzr is no big.
[03:32] <Peng> Writing over HTTP requires WebDAV, right?
[03:32] <meteoroid> not sure i can what?
[03:32] <Odd_Bloke> meteoroid: vila has recently published the webdav plugin.
[03:32] <meteoroid> Odd_Bloke: url?
[03:33]  * meteoroid would welcome half-working experimental code
[03:33] <Odd_Bloke> meteoroid: https://code.launchpad.net/~bzr/bzr.webdav/webdav
[03:33] <meteoroid> is it in pypi?
[03:33] <Odd_Bloke> It's marked as only working for bzr 1.6, but will probably work before that, it just hasn't been tested.
[03:34] <meteoroid> hm, i seem to have 1.3.1
[03:34] <meteoroid> i should be compiling from source..
[03:34] <meteoroid> but, yeh, i'd like this setup to work with what ubuntu is shipping..
[03:35] <bob2> sftp or bzr+ssh will be less hassle
[03:35] <poolie> Odd_Bloke: oh hi
[03:38] <Odd_Bloke> poolie: Hey.
[03:38] <poolie> hello
[03:38] <poolie> did you want to talk here, on private irc, or on the phone
[03:39] <Odd_Bloke> poolie: PM?
[04:08] <Odd_Bloke> I have two different Test classes, both of which have a setUp method.  I also have one test which requires the setUps of both Test class.  How should I go about combining them?  Is there something better than copy-paste?
[04:20] <bob2> C inherits from both of them, it's setUp consists of A.setUp(self);B.setUp(self)
[04:22] <Odd_Bloke> I tried that, I think C then ends up with all of the tests from A and B being run twice.
[04:22] <Odd_Bloke> I'll double-check though.
[04:30] <Odd_Bloke> It does run all the tests from A and B twice.
[04:31] <Odd_Bloke> However, it has also allowed me to debug the test which shares the setUps, so it's not a total loss.
[04:32] <Odd_Bloke> Perhaps extract the setUp for A and B to A' and B'.  A and B then each subclass A' and B' and C subclasses both A' and B'?
[04:33] <spiv> Odd_Bloke: yeah, separating the setUps from the classes with the test methods sounds like a good start
[04:33] <spiv> Depending on what those setUps do, you might even be able to extract them into a non-TestCase object entirely.
[04:35] <spiv> Like how some bzrlib tests do things like "smart_server = bzrlib.smart.server.SmartTCPServer_for_testing(); smart_server.setUp(backing_transport=blah); self.addCleanup(smart_server.tearDown); ..." in test bodies.
[04:35] <spiv> But your arrangement with A' and B' sounds ok too.
[04:45] <Odd_Bloke> Soo, bzr-email and the PQM test suite shouldn't be mixed. >.<
[04:47] <Odd_Bloke> If I want to exclude a specific directory under a more general directory (in this case ~/devel/pqm/work/_trial_temp underneath ~/devel/pqm) from using bzr-email, do I do it in ~/.bazaar/locations.conf?
[04:50] <spiv> Odd_Bloke: If the PQM test suite used bzrlib.tests.TestCase, it ought to be insulated from your ~/.bazaar configuration.
[04:51] <Odd_Bloke> Hmm, thumper has a patch for exactly this.
[06:19] <Odd_Bloke> PQM merge-directives patch just sent to the ML.
[06:38] <lifeless> pygi: quite well recieved, but a self selected audience
[06:38] <lifeless> pygi: 20 or so people, all but 4 already love bzr :)
[06:38] <lifeless> jam: I will check when I get to the uni
[07:29] <poolie> lifeless: it looks like branch --stacked still copies all the data from the source repository
[07:30] <poolie> this is in the top of your baz2.0/shallow-branch
[07:30] <poolie> am i just using out of date code, or do i need to fix this?
[07:37] <Odd_Bloke> jml: What was the name of the todo-list website you were looking at?
[07:37] <mwhudson> rememberthemild
[07:37] <mwhudson> rememberthemilk
[07:37] <mwhudson> remember the mild sounds like a good idea of a different sort...
[07:38] <Odd_Bloke> mwhudson: Thanks. :)
[07:38] <Peng> mwhudson: Can I bother you about Loggerhead?
[07:39] <mwhudson> Peng: not really, it's end of day time here
[07:39] <mwhudson> Peng: but if you're quick...
[07:39] <Peng> mwhudson: Oh. Yeah, not very quick..
[07:39] <mwhudson> Peng: bugs and or email then please
[07:40] <Peng> mwhudson: Email to? Bazaar-list?
[07:40] <mwhudson> Peng: yeah, sounds good
[07:46] <liw> "And man, major WTF at using Bazaar. :)" (in the comment section, fairly close to the end, of http://community.livejournal.com/evan_tech/248736.html)
[07:47] <liw> I know bzr isn't as popular as git, but... "major WTF" for using it? tsk.
[07:51] <lifeless> poolie: I was fairly sure there were tests to catch this;  its possible there are not though
[07:52] <tim__> nick thumper
[07:52] <tim__> damnit
[07:52] <lifeless> :)
[07:53] <lifeless> poolie: abentley's policy work may help too
[08:11] <poolie> lifeless: what branch would those tests be in?
[08:12] <poolie> can you check you've pushed all your work on it?
[08:12] <poolie> afaics aaron's work doesn't change it
[08:12] <poolie> it might though
[08:12] <poolie> maybe i should try the merge anyhow
[08:12] <poolie> at least in a separate workspace
[08:13] <lifeless> poolie: I have
[08:13] <lifeless> poolie: got a machine to setup sorry
[08:14] <poolie> lifeless: i don't mind fixing it, i just want to avoid rewriting code that exists on your laptop or something
[08:14] <poolie> "I have" -- checked you've pushed it?
[08:14] <poolie> ok, thanks
[08:26] <poolie> i tried the stacking-policy branch; it still copies the contetn
[08:28] <lifeless> poolie: urgh. I suspect a race condition in clone()/sprout()
[08:29] <poolie> i should have tried this a few days ago
[08:29] <poolie> i've been chasing the wrong geese
[08:31] <lifeless> poolie: group compress is looking nice btw - I can compress bzr.dev's texts down to 16MB
[08:32] <bob2> wow
[08:37] <thumper> lifeless: what is it normally?
[08:37] <thumper> poolie: hi
[08:37] <poolie> hi thumper
[08:39] <lifeless> du -sh test-repos/bzr.dev.-100/.bzr/repository/packs/
[08:39] <lifeless> 74M     test-repos/bzr.dev.-100/.bzr/repository/packs/
[08:39] <lifeless> thumper: which includes inventories and revisions too though
[08:43] <thumper> lifeless: that is very impressive
[08:44] <bob2> btree indices save more than 50%, too
[08:51] <lifeless> ok, strict bzr.dev gets down to 12M
[08:52] <bob2> is groupcompress hooked up the ui at all?
[08:52] <lifeless> its a VF object at the moment
[08:54] <lifeless> thumper: ping
[08:54] <lifeless> thumper: the local playground is up at 10.2.13.75
[08:55] <lifeless> thumper: I need you to find olav, and send him my way on IRC or real-world
[08:59] <beuno> lifeless, hey there. I've been hearing great things about you in Guadec!  Having fun?
[09:02] <lifeless> beuno: yes indeed
[09:02] <lifeless> being eaten alive by mosquitos
[09:02] <Odd_Bloke> (NOM NOM NOM)
[09:08] <beuno> ok, off to work, bbiab
[09:11] <lifeless> poolie: ping
[09:17] <poolie> lifeless: pong
[09:17] <lifeless> whats the mailman padmindb password these days
[09:18] <lifeless> jamesh: ping, can you come over
[09:24] <lifeless> thumper: jamesh: pikng
[09:25] <thumper> lifeless: here
[09:25] <thumper> lifeless: I don't have popups with irssi
[09:25] <lifeless> can you and jamesh pop over, I can't really come to you
[09:32] <Odd_Bloke> thumper: lifeless: poolie: Is it OK if I go ahead and create the pqm-dev team?
[09:34] <jamesh> lifeless: sorry.  was away.  Where are you?
[09:34] <lifeless> student computer lab
[09:35] <lifeless> Odd_Bloke: I've created it
[09:36] <Odd_Bloke> lifeless: Cool, thanks.  I've just applied.
[09:37] <lifeless> Odd_Bloke: I'm a bit confused about what the team is meant to imlpy though
[09:38] <lifeless> if its commit access to trunnk, which I labeled it as, then clearly its just me today.
[09:38] <lifeless> if its not commit access to trunk, then what is it
[09:38] <Odd_Bloke> lifeless: I think it's probably for people who are expected to have commit access at some point.
[09:38] <Odd_Bloke> At the very least, it'd be good to have a team that can manage the bugs.
[09:39] <lifeless> do you not have the needed permissions todayt?
[09:39] <Odd_Bloke> I can't change Importance of bugs.
[09:40] <lifeless> ok, lets fix that
[09:40] <beuno> mwhudson, merged trunk into loggerhead-searched and pushed revo 273
[09:41] <beuno> lifeless, thanks for pushing the merge  :)
[09:44] <lifeless> beuno: my pleasure
[10:09] <lifeless> beuno: ping
[10:10] <lifeless> beuno: does the loggerhead gnome theme branch have bzr-search merged?
[10:11] <beuno> lifeless, yeap
[10:11] <Peng> Does Loggerhead trunk or bzr-search_integration work with bzr.dev?
[10:11] <beuno> Peng, both do
[10:11] <Peng> Heck, I'll switch to bzr-search_integration, then.
[10:11] <beuno> 1.5+ AFAIK
[10:12] <beuno> :)
[10:12] <beuno> hopefully trunk will become lh-search soon
[10:12] <Peng> Yeah, I was expecting that to happen faster..
[10:13] <Odd_Bloke> lifeless: I'm a little confused by what pqm.ui.twistd.QueueResource.render is doing (http://tinyurl.com/5jptpr for reference).  Should both of the "len(request.postpath) > n" be "len(request.postpath) >= n"?
[10:13] <lifeless> Odd_Bloke: no :)
[10:14] <lifeless> Odd_Bloke: have a look at what the data is, it may help
[10:14] <Peng> beuno: Like, how soon? Do you have a specific plan? If I switch now, will you suddenly merge it into trunk tomorrow?
[10:14] <lifeless> poolie: deends on mwhudson
[10:14] <lifeless> Peng: ^
[10:15] <lifeless> poolie: soorry\
[10:15] <Peng> Well.
[10:15] <beuno> Peng, "in the next few days"
[10:15] <Peng> Oh, nice.
[10:15] <Peng> beuno: Is the search branch considered reasonably stable?
[10:15] <beuno> Peng, gnome has been using it, and I haven't heard any complaints
[10:16] <beuno> I think it's stable enough to be used in most enviroments, yes
[10:16] <Peng> Will search indexes be created automatically?
[10:16] <beuno> no, that's one of the remaining issues
[10:16] <beuno> they do get updated automatically, but that's due to bzr-search's magic, not LH
[10:17] <Odd_Bloke> lifeless: I would expect "localhost:8000/project" to go to project's page.  ATM, however, it would go to the main page.
[10:17] <lifeless> Odd_Bloke: it doesn't seem to is what I'm saying
[10:18] <Peng> beuno: So, if there is no index, what happens? it's eternally slow?
[10:18] <lifeless> Odd_Bloke: as in, projects are in use at the moment, and it works last I heard
[10:18] <beuno> Peng, nope, it ignores everything, and search doesn't return any results
[10:19] <Peng> Haha.
[10:19] <Peng> Since I don't want to bother to index anything, I guess I won't do it, then.
[10:19] <lifeless> Peng: 'bzr index' once on the things you want to index
[10:20] <Peng> lifeless: Yeah, but I don't know what should be indexed. I'm not an upstream developer; I don't have any trunk branches.
[10:20] <lifeless> Peng: well, you're running loggerhead on some branches you want to look at
[10:23] <Peng> So apparently knit repos can't be indexed?
[10:24] <Peng> Actually, no, even a pack repo tracebacks about weave_store.
[10:25] <Peng> Ooh.
[10:25] <Odd_Bloke> lifeless: Ah, I was being confused by a lack of a '/' at the end of the URL.
[10:26] <Peng> I'm sorry, false alarm. One copy of bzr-search was out-of-date.
[10:33] <lifeless> Peng: :)
[10:34] <Peng> Also, when "bzr index" uses 220 MB of RAM, and my VPS has 360 MB of RAM, that becomes a bit of a problem..
[10:34] <Peng> Also also, I still got a weave_store traceback.
[10:37] <Peng> Screw this. I'm reverting.
[10:46] <lifeless> Peng: your loggerhead?
[10:47] <lifeless> Peng: or the index creation ?
[10:47] <lifeless> Peng: uhm, ratchet down the group size in index.py will reduce memory use
[10:47] <LarstiQ> hatchet it down? :)
[10:47] <Peng> lifeless: The original weave_store tracebacks were from index, but upgrading bzr-search fixed them. The new ones were from Loggerhead.
[10:48] <lifeless> Peng: sounds like an old loggerhead too then
[10:48] <Peng> lifeless: I had just merged bzr-search_integration, which just merged the trunk.
[10:48] <lifeless> bue^
[10:48] <lifeless> beuno: ^
[10:49] <beuno> hm
[10:49] <beuno> yes, lh-search has the latest and greatest
[10:50] <beuno> Peng, LH is using the memory, or creating the search indexes?
[10:50] <Peng> beuno: Sorry, index was using the memory.
[10:51] <Peng> Um, actually, that traceback was from a branch that either had no index or a broken one.
[10:51] <Peng> lifeless: What all does index creation modify? Just .bzr/bzr-search. Or in other words, what do I delete to make it go away? :)
[10:51]  * beuno throws the ball back to lifeless 
[10:51] <Peng> Haha.
[10:52] <lifeless> Peng: .bzr/bzr-search
[10:52] <Peng> lifeless: Thanks.
[10:52] <lifeless> beuno: I was saying LH was erroring, bzr-search is using the memory
[10:52] <lifeless> Peng: like I say though, edit index.py, look for group_size
[10:52] <lifeless> set that to 1 for minimal memory use
[10:53] <beuno> Peng, can you paste the traceback?
[10:53] <Peng> beuno: http://paste.pocoo.org/show/78956/ (it's the same traceback all 4 times)
[10:53] <Peng> lifeless: Thanks, but I'll just live without those branches being indexed for the moment.
[10:54] <Peng> lifeless: Does searching suck much RAM?
[10:54] <beuno> Peng, are you running bzr.dev with the latest bzr-search?
[10:54] <Peng> beuno: I should've been.
[10:54] <lifeless> Peng: searching should not suck much
[10:54] <lifeless> beuno: can you advise on something
[10:54] <Peng> lifeless: That's good. Thanks.
[10:55] <lifeless> beuno: if you go to http://bzr-playground.gnome.org/gnome/CWordHelper/trunk/changes, and do a search
[10:55] <lifeless> beuno: a) why does it end up on bzr-gnome.canonoical.com
[10:55] <Peng> beuno: I had just switched Loggerhead from using the system bzr 1.5 to my copy of bzr.dev with bzr-search, and I never confirmed it actually worked.
[10:55] <lifeless> beuno: and
[10:55] <beuno> Peng, that seems like a bzr-search <> bzr problem with lifeless's VersionedFiles thingie
[10:56] <lifeless> b) why doesn't the search box popup show
[10:56] <beuno> lifeless, hm, that's odd
[10:56] <Peng> Canonical host's Gnome's Bazaar?
[10:56] <Peng> Err, hosts*
[10:56] <lifeless> Peng: we host svn.gnome.org I think too :)
[10:57] <Peng> lifeless: You're right. That's nice.
[10:57] <beuno> lifeless, it seems LH is finding the *.canonical URL instead of the *.gnome one, and setting that
[10:57] <beuno> find as you type should work though
[10:57] <lifeless> beuno: where does it look though?
[10:58] <beuno> it probably doesn't due to cross-site-scripting protection
[11:00] <lool> Hey folks
[11:01] <lool> When bzr branching casper under hardy and Debian sid I get:
[11:01] <lool> KnitCorrupt: Knit 9e/x_%254datt_%255aimmerman_%253cmatt.zimmerman%40canonical.com%253e_%2553un_%254dar_13_00%253a51%253a19_2005_1366.38 corrupt: line-delta from stream for version mdz@mizar-20051205230117-c327e75be767f237 references missing parent Arch-1:matt.zimmerman@canonical.com--2004%casper--main--0--patch-21
[11:01] <beuno> lifeless, it seems paste is resolving to that host
[11:01] <lool> I'm suggested to run bzr check or reconcile, but is there any risk for the lp repo?
[11:01] <lool> I wouldn't want to break the casper bzr repo on lp
[11:02] <lifeless> lool: I suspect you have a bug in your bzr that we fixed
[11:02] <lifeless> lool: what version do you have?
[11:02] <lool> lifeless: hardy's and sid's versions
[11:02] <lool> That'd be 1.5-1 and 1.3.1-1
[11:03] <lool> Well the opposite
[11:03] <lifeless> lool: please try 1.6b2
[11:03] <lool> Is this in some ppa?
[11:03] <lool> I don't see it in intrepid
[11:03] <lifeless> lool: but its possible that there is some problem
[11:03] <lifeless> lool: yes
[11:03] <lifeless> 'bzzr' ppa
[11:04] <lool> That guy exists but doesn't have a ppa :)
[11:04] <Peng> lifeless: ~bzr's ppa only has 1.5.
[11:04] <lifeless> oh, the bzr-beta one then
[11:05] <lool> I see no bzr-beta ppa
[11:05] <lool> And indeed ~bzr only has 1.5
[11:05] <mattions> hey guys
[11:06] <mattions> hello
[11:06] <lool> ~bzr-beta-ppa
[11:06] <lifeless> https://launchpad.net/~bzr-beta-ppa/+archive
[11:06] <lifeless> hi matt
[11:06] <lifeless> ions
[11:07] <Peng> Bye matt ions.
[11:07] <lifeless> beuno: I see no search requests in th eloggerhead logs
[11:07] <lifeless> beuno: could the jscript not be loading in the client?
[11:08] <beuno> lifeless, it probably isn't, yes, because it's on a different host, and browsers have cross-site-scripting protection
[11:08] <mattions> hi lifeless, sorry xchat wuit
[11:09] <lifeless> beuno: so, why is it detecting this other host, how do I fix that
[11:09] <Peng> Why does LH insert the full URL into links so often?
[11:09] <beuno> that means, to some extent, the browser is also confused on what the hosts are
[11:09] <mattions> can anybody have a quick look to this stacktrace http://paste.ubuntu.com/26174/ ?
[11:09] <lool> lifeless: It isn't fixed in 1.6
[11:09] <lifeless> lool: ok; can you chat to colin watson?
[11:09] <lool> 1.6~beta2-1~bazaar1 is the hardy version I tried
[11:09] <lool> lifeless: Colin suggested me to come here :)
[11:09] <lifeless> oh
[11:09] <beuno> lifeless, I'm trying to find where paste generates that, and why it would be detecting something else
[11:09] <lool> lifeless: As he has been experiencing the same
[11:10] <lifeless> uhm, try grabbing the current source, then pulling the old source into your branch with pull --overwrite
[11:10] <lool> The current source?  you mean the source package?
[11:11] <lifeless> lool: the current bzr tree
[11:11] <lool> Or only check out the latest revision?
[11:12] <beuno> lifeless, did you kill LH?
[11:12] <lool> I'm doing bzr checkout --lightweight lp:~ubuntu-core-dev/casper/trunk
[11:12] <lool> Interestingly, when I bzr pull --overwrite it says: Using saved location: http://people.ubuntu.com/~tfheen/bzr/casper/trunk/
[11:12] <lool> it shouldn't use this saved location
[11:13] <Peng> lool: "bzr pull --remember lp:~ubuntu-core-dev/casper/trunk" to change it.
[11:13] <lool> Peng: Thanks
[11:13] <Peng> (You can pass --overwrite too if you want to.)
[11:14] <lifeless> beuno: back
[11:14] <lool> All pulls returned "No revisions to pull" and bzr vis complained that my branch didn't support tags
[11:14] <lifeless> lool: with --overwrite ?
[11:14] <beuno> lifeless, not for me  :)
[11:15] <lool> lifeless: With overwrite
[11:15] <lool> Let me try again starting from the lightweight checkout and using unbind first
[11:15] <lool> bzr: ERROR: To use this feature you must upgrade your branch at bzr+ssh://lool@bazaar.launchpad.net/%7Eubuntu-core-dev/casper/trunk/.
[11:15] <lool> So I'll skip unbind
[11:15] <lifeless> lool: just bzr branch the current trunk of casper, then pull --overwrite the old version you want
[11:16] <lool> I checked it out because I didn't know I could lightweight branch, but I'll try that
[11:16] <lool> lifeless: I don't see how I can branch the current trunk
[11:17] <lool> Hmm perhaps with revision
[11:17] <lool> No doesn't work
[11:18] <lool> bzr branch --revision 516 or bzr branch alone fails with the KnitCorrupt error
[11:18] <lool> KnitCorrupt: Knit 9e/x_%254datt_%255aimmerman_%253cmatt.zimmerman%40canonical.com%253e_%2553un_%254dar_13_00%253a51%253a19_2005_1366.38 corrupt: line-delta from stream for version mdz@mizar-20051205230117-c327e75be767f237 references missing parent Arch-1:matt.zimmerman@canonical.com--2004%casper--main--0--patch-21
[11:18] <lool> I can't unbind without upgrading
[11:18] <lool> I could try to upgrade locally, unbind and pull --overwrite
[11:20]  * lool lightweight checkout + upgrade => stuck: \ [[11:20]  * Peng leaves.
[11:20] <lool> No progress anymore
[11:21] <beuno> lifeless, are you running serve-branches or start-loggerhead?   can you try running the other one on a random branch?
[11:21] <beuno> I suspect it's the way serve-branches sets the URL
[11:22] <lifeless> beuno: server-foo
[11:23] <lifeless> lool: sorry, I can't devote as much time to you as I'd like, my cycles are overcommitted
[11:23] <lool> lifeless: I understand; how do we go forward with the problem?
[11:23] <lool> Should I file it against bzr?
[11:23] <lool> It's effectively preventing Colin and I to work on the casper bzr tree which is used for the casper package
[11:23] <lifeless> beuno: it was the ServerName in apache
[11:24] <beuno> lifeless, self._url_base = environ['SCRIPT_NAME']
[11:24] <beuno> yeah
[11:24] <beuno> found it  :)
[11:24] <lifeless> lool: its proably user data that has had something bong done to it; perhaps sftp interaction bug or something in the past
[11:24] <lool> lifeless: Interestingly, I could branch from an older bzr version
[11:24] <lool> alioth's
[11:25] <lifeless> lool: so now pull --overwrite the newer one into there
[11:25] <lool> I have nothing to pull in particular
[11:25] <Dany> Hi! I'm developer on a project opened on "http://forge.ocamlcore.org/". I have generated a key with "PuTTYgen" and I put it in my profil on ocamlforge. With this, I can connect me to the shell with the command "putty shell.forge.ocamlcore.org". I use bzr to make a branch of the project, it works fine. But the command "bzr push sftp://bzr.ocamlcore.org//bzrroot/pa-do/pa-do/trunk" gives an error.
[11:26] <Dany> The error is : bzr: ERROR: Unable to connect to SSH host bzr.ocamlcore.org; EOF during negotiation
[11:26] <lifeless> lool: grab the alioth branch; cd to it; pull the launchpad branch
[11:26] <Dany> any suggestion?
[11:26] <lool> lifeless: Ah I think I wasn't clear
[11:26] <lool> lifeless: I could bzr branch the lp branch /from/ alioth
[11:27] <lool> Using alioth's bzr
[11:27] <lool> There's no branch hosted on alioth
[11:27] <lool> It's just bzr 1.3-1~bpo40+1
[11:27] <lifeless> Dany: no idea sorry
[11:27] <lifeless> lool: can you run rsync that somewhere and then run check on it
[11:30] <lool>    112 inconsistent parents
[11:30] <lool>      5 revisions missing parents in ancestry
[11:31] <lool> I ran bzr reconcile and bzr checked again; I still have      5 revisions missing parents in ancestry
[11:31] <lool> and 5 ghost revisions in all cases
[11:32] <lifeless> try cloning that with modern bzr?
[11:32] <lool> -- I did the checks and reconciles with modern bzr btw
[11:32] <lool> bzr: ERROR: Revision {Arch-1:matt.zimmerman@canonical.com--2004%casper--main--0--patch-9} not present in "KnitVersionedFile(file:///home/lool/b/trunk2/.bzr/repository/knits/9c/x_%254datt_%255aimmerman_%253cmatt.zimmerman%40canonical.com%253e_%2553un_%254dar_13_00%253a51%253a19_2005_1366.36)".
[11:32] <lool> NB: The error is this only line now
[11:33] <lool> (this is the error from branching the reconciled branch with modern bzr)
[11:33] <lifeless> same thing
[11:33] <lifeless> file a bug please
[11:33] <lifeless> don't alter the lp branch
[11:34] <lool> I'll attach this IRC log
[11:38]  * lool thanks and waves
[11:39] <mtaylor> lifeless: if I have two revisions, is there a "good" way to just get the list of revisions between them? (like a magic method to call somewhere?)
[11:40] <lifeless> mtaylor: graph.difference os some wuch
[11:40] <mtaylor> ah...
[11:40] <lool> Sorry, forgot to say I filed #246880
[11:40] <lifeless> mtaylor: g = repository.get_graph();
[11:40] <lifeless> lool: thanks
[11:40] <lool> lifeless: thank /you/
[11:41]  * lool goes for some lunch soonish now &
[11:58] <lifeless> ok. we're syncing again
[12:00] <davidf1> Hi all, I have a question to which I can't find an answer (but maybe I'm not looking good enough...). It is this: someone has started a project and committed lots of files to our repository. Most of it isn't used anymore, but some of it is. I started new projects with a clean structure. Is it possible to lift just a few files out of the old project with version history included? So, something like a merge, but without pulling in all unused stuff, revisions
[12:01] <davidf1> Sorry for the long read...
[12:02] <Peng> davidf1: That ended with "but without pulling in all unused stuff, revision" and one more byte.
[12:02] <davidf1> Ai...
[12:02] <davidf1> So, something like a merge, but without pulling in all unused stuff, revisions and histories. I can merge the entire project and then delete all unused stuff, but that pulls in lots of history I don't use. Can I just merge a few files?
[12:03] <davidf1> Peng: thank you
[12:03] <Peng> Sprry, but I don't have an answer. Hopefully someone else knows.
[12:03] <davidf1> Peng: thank you for pointing out the missing text.
[12:03] <Peng> :)
[12:03] <davidf1> I'll wait for someone else to answer this (hopefully...)
[12:04] <Peng> Also, I was just about to go to bed. Good night (or, morning, or whatever).
[12:05] <davidf1> Peng: good night for you, then. Here, it's just after lunch, ;-)
[12:05] <Peng> Here it's 07:05, but I have no sleep schedule. :D
[12:05] <Peng> Bye.
[12:05] <davidf1> Peng: you stayed up all night???
[12:11] <luks> the problem is mainly in getting positions of the text line
[12:11] <luks> sorry, wrong channel
[12:12] <lifeless> davidf1: the history for the files you want is mingled with the history you don't want; its possible to write ode to generate new history with matching dates etc for only the file syou want, but it won't be mergable after that; and we haven't got a canned solution too this
[12:16] <davidf1> lifeless: ok, thanks. I'll merge the whole project then and remove all unnecessary parts. A bzr log <file> should still only give the relevant history, right?
[12:16] <lifeless> davidf1: yes
[12:16] <davidf1> lifeless: thanks!
[12:30] <Odd_Bloke> lifeless: I've just checked and I still can't edit PQM bugs.  I think you need to set PQM's bug supervisor to the pqm-dev team...
[12:31] <lifeless> Odd_Bloke: ok
[12:47] <lifeless> Odd_Bloke: done
[12:48] <jelmer> hi lifeless, Odd_Bloke
[12:48] <thumper> lifeless: I've just applied to join the pqm-dev team too
[12:49] <lifeless> k
[12:58] <Odd_Bloke> All the cool kids are doing it.
[13:17] <jelmer> Odd_Bloke, you appear to've spammed the commits list :-)
[13:17] <Odd_Bloke> jelmer: Was this with multiple 'Revision 1' messages, or more recently?
[13:18] <jelmer> yeah, multiple rev 1
[13:18] <jelmer> the others appear to be fine
[13:19] <Odd_Bloke> Yeah, that's because PQM's test suite uses your standard bzr settings, which I'd forgotten about.  So every commit in a test got emailed out.
[13:21] <jelmer> ahh :-)
[13:24] <mwhudson> bzrlib.tests.TestCase ftw
[14:01] <lifeless> thumper: try that groups thing now
[14:05] <jam> lifeless: I'd like to chat a bit about how 'bzr pull' has to grab 100% or it throws out everything.
[14:06] <jam> It's being a real problem with mirroring 200 branches from my home repository
[14:06] <jam> => launchpad
[14:38] <lifeless> jam: ok; well it doesn't really have to, what it has to do is ensure that the ones it grabs are topologically oldest
[14:39] <jam> lifeless: so I was looking at the fetch code.
[14:39] <jam> And for "old" formats
[14:39] <jam> you could simply grab the sorted list of revision ids
[14:39] <jam> and then say grab 1000 at a time
[14:39] <jam> the problem with the new code
[14:39] <jam> is that you use "get_stream_from_search"
[14:39] <jam> which is nice and efficient
[14:39] <jam> from a "bytes transmitted on the wire" perspective
[14:39] <jam> but means there isn't a way to say "give me only some of these"
[14:40] <jam> I mentioned to Andrew that it would be nice to have a "sync" node in the data stream
[14:40] <jam> so that the server could give you revisions in a given group, and then let the client know that it has a "complete" set
[14:40] <jam> thus it can be committed to the repo
[14:40] <jam> and start a new write group.
[14:40] <lifeless> jam: sure, or you could just drive it from the client, by taking some subset of the search
[14:41] <jam> well, the client has to do a lot more querying of the server to find out the subset from the search
[14:41] <jam> since all it has are the graph edges
[14:41] <lifeless> jam: not really
[14:41] <lifeless> jam: its traversed the intermediate nodes, you can just pick one, and use the existing graph edges
[14:41] <jam> maybe I misunderstand what the 'for search' does
[14:42] <jam> lifeless: my specific example is 'first pull', how should it need to traverse anything but the branch tip?
[14:42] <lifeless> jam: ah that case is fair enough
[14:44] <jam> I would *like* to have it driven by the client, but the whole point was to avoid having the client have to determine the whole graph
[14:45] <jam> being driven client side makes it easier to support
[14:45] <lifeless> jam: ack; anyhow I agreew it the the need
[14:48] <jam> ok, I know you and I have full plates, so I'll see about pushing spiv to do it :)
[15:45] <kinkie> Hi all... I have a problem with pushing some changes to launchpad. I have a private copy of squid-trunk off which I branched. I pulled from trunk, merged into my copy and then tried to push my copy to launchpad. But the push complains that "These branches have diverged.  Try using "merge" and then "push".". Tried to, but all actions show that trees are actually in sync. Hints on how to solve?
[15:45] <kinkie> Thanks in advance
[15:48] <lifeless> kinkie: hi
[15:48] <kinkie> hi lifeless :)
[15:48] <lifeless> kinkie: are you pushing to your own branch in launchpad?
[15:48] <kinkie> yes
[15:48] <lifeless> kinkie: what url is that ?
[15:48] <lifeless> (and what url does bzr think you are pushing to)
[15:49] <kinkie> after lp: expansion, it's bzr+ssh://kinkie@bazaar.launchpad.net/~kinkie/squid/cachemgr-refactor/
[15:49] <lifeless> can you paste the bzr output?
[15:50] <kinkie> kinkie@longhorn:~/src/cachemgr-refactor$bzr push
[15:50] <kinkie> Using saved location: bzr+ssh://kinkie@bazaar.launchpad.net/~kinkie/squid/cachemgr-refactor/
[15:50] <kinkie> bzr: ERROR: These branches have diverged.  Try using "merge" and then "push".
[15:51] <lifeless> kinkie: what does 'bzr info' show?
[15:51] <kinkie> kinkie@longhorn:~/src/cachemgr-refactor$bzr info
[15:51] <kinkie> Lightweight checkout (format: dirstate or dirstate-tags or pack-0.92 or rich-root or rich-root-pack)
[15:51] <kinkie> Location:
[15:51] <kinkie>   light checkout root: .
[15:51] <kinkie>    checkout of branch: /home/kinkie/src/repo/squid-cachemgr-refactor
[15:51] <kinkie>     shared repository: /home/kinkie/src/repo
[15:51] <kinkie> Related branches:
[15:51] <kinkie>     push branch: bzr+ssh://kinkie@bazaar.launchpad.net/%7Ekinkie/squid/cachemgr-refactor/
[15:51] <kinkie>   parent branch: /home/kinkie/src/repo/squid-trunk
[15:51] <kinkie>   submit branch: ../repo/squid-trunk
[15:51] <lifeless> ok
[15:52] <lifeless> what does bzr missing bzr+ssh://kinkie@bazaar.launchpad.net/%7Ekinkie/squid/cachemgr-refactor/ show ?
[15:53] <kinkie> You have 6 extra revision(s): XXX omitted XXX
[15:53] <kinkie> You are missing 1 revision(s): XXX omitted XXX
[15:53] <lifeless> right, clearly you are diverged :)
[15:53] <kinkie> (hm.. is omitted even english?)
[15:53] <kinkie> Oookay. the 6 extra revisions are what I am trying to push.
[15:53] <lifeless> kinkie: you have either uncommitted, or pushed a different branch to that url at some point
[15:54] <lifeless> if you have whaqt you want, you can just push ---overwrite
[15:54] <kinkie> I have what I want, what I'm missing is a merge from trunk which I performed anyways
[15:54] <lifeless> so, push --overwrite
[15:55] <kinkie> should I find myself in the same situation, what could be a resolution path? merge from the offending branch then push?
[15:57] <lifeless> kinkie: look at whats missing, decide if you want to sync - merge & push, or replaace - push --overwrite
[15:57] <kinkie> ok.
[15:57] <kinkie> Thanks!
[15:57]  * kinkie has to go now.
[15:57] <kinkie> See you later / tomorrow!
[15:57] <lifeless> kinkie: for a release branch, like trunk, you'd normally check that branch out, cd to it, merge your branch and push
[15:57] <lifeless> ciao
[15:57] <kinkie> ok
[15:57] <kinkie> thank you very much.
[16:16] <lifeless> beuno: ping
[16:16] <beuno> lifeless, pong
[16:16] <lifeless> hey
[16:16] <lifeless> so thumper and I have some mino trouble
[16:16] <lifeless> with rewrites
[16:19] <beuno> hm?
[16:20] <lifeless> so, we have a server with /gnome/project/trunk and /user/project/trunk
[16:20] <lifeless> we want to present this as /project/trunk and /~user/project/trunk,
[16:21] <beuno> hrm, the way we use URLs is far from ideal...
[16:21] <beuno> you're using an htaccess?
[16:21] <lifeless> rouhgly, yes
[16:22] <lifeless> so we tried adding the gnome in a rewrite rulle, which works
[16:22] <lifeless> and stripping the ~, which doesn't work
[16:23] <lifeless> because loggerhead sees /user/ and does a 301 to /user/ causing epic fail
[16:24] <beuno> hmm...
[16:25] <beuno> I need to finish something, and I'll try and see how we can work around that
[16:25] <lifeless> so I'd like the paste magic to say  '/gnome/' -> '/gnome/' and '/other' -> '/~other'
[16:39] <MvG> Hi! I'm again trying to get a bzr branch for inkscape, and again I encounter errors. This time I'm using the branch at launchpad as a source.
[16:39] <MvG> First I tried a simple "bzr branch lp:inkscape", then a "bzr branch http://bazaar.launchpad.net/~vcs-imports/inkscape/main". Both take ages and seem to freeze at some point.
[16:40] <MvG> wireshark lists an awful lot of partial requests from the branch repository, which seems to be quite inefficient.
[16:41] <MvG> To solve that aspect, I used wget to download the pranch with repository in a dumb but fast way. The fact that this is several times faster than a bzr branch should cause some worries, I think.
[16:41] <MvG> So with that I had a local copy of the inkscape main branch on launchpad. I tried to branch from that, and again it froze at the same point the other access methods did. So it's not a server issue, and now I can reproduce it quite fast.
[16:42] <lifeless> MvG: ok, can you file a bug then ?
[16:42] <lifeless> MvG: it may not be a bug, and I'll be delighted to dig into it in detail, but I'm a little fenetic right now
[16:42] <MvG> lifeless: I guess I could, but I'm not sure how much of this depends on current state of the branch, so debugging as much as possible today might be helpful.
[16:43] <MvG> So what would you suggest in order to get more info for this. Is there some -D switch liekly to help?
[16:43] <lifeless> well, if you hit ctrl-\ at the hung bzr,
[16:43] <lifeless> you can get a debugger
[16:43] <lifeless> and hit bt to get a back trace
[16:44] <MvG> That's just what I wanted, thanks! I'll try locate the loop, and tell you my findings.
[17:14] <lifeless> beuno: so, do you know how to ook into the url -> disk mapping layer easily?
[17:14] <radix> hey guys, is there a prerelease with stacked branches yet?
[17:14] <beuno> lifeless, not off the top of my head, sorry
[17:15] <beuno> I may be able to poke at it in a few hours, but I'm in a tight schedule right now
[17:18] <lifeless> beuno: I understand
[17:21] <james_w> hey radix, I don't think so.
[17:22] <james_w> radix: should be an rc1 with them in the next day or two I believe.
[17:22] <radix> oh, nice
[17:32] <rivo> hi
[17:32] <rivo> I converted a part of a subversion repository to bazaar using bzr branch <svn repo url>
[17:32] <jam> lifeless, abentley: If you want to see why the ha_ndbcluster.cc merge is tricky, here is its file revision graph (note, you want to wget it and view it locally, not in a browser):
[17:32] <jam> http://bzr.arbash-meinel.com/mesh.png
[17:32] <jam> The brown node is the unique lca
[17:32] <rivo> is there any downsides to that, compared to properly doing  bzr svn-import ...?
[17:33] <jam> the green nodes are the intermediate lcas
[17:33] <jam> the red nodes are the revisions being merged
[17:33] <jam> and all revisions that are ancestors of the unique lca have been pruned
[17:33] <jam> rivo: Just that svn-import will do multiple branches for you at once
[17:33] <jam> The results should be the same
[17:34] <rivo> jam: ok, that's great
[17:34] <rivo> jam: I couldn't get svn-import working, maybe because of the weird layout of my repo, but then it doesn't matter
[17:47] <MvG> OK, I have some more information from my slow branch of the main inkscape branch from launchpad.
[17:48] <MvG> It seems not to be an infinite loop, but rather incredibly slow processing.
[17:48] <lifeless> MvG: puttting the backtrace in a bug will be useful
[17:48] <lifeless> MvG: most incredibly slow processing cases are due to data-conversion paths
[17:49] <MvG> It's busy in fetch.py in Inter1and2Helper._find_root_ids, iterating over some 4000+ id's, with each batch of 100 taking several minutes.
[17:50] <MvG> And it only has this kind of problem when I branch into a pre-initialized rich-root-pack repo. A branch without shared repo workes fast enough to wait for it, although I still wouldn't call it "fast".
[17:52] <james_w> MvG: what does "bzr info" on the branch you are pulling from report as it's repository type?
[17:52] <MvG> james_w: pack-0.92
[17:53] <james_w> so this is slowness from not-rich-root->rich-root
[17:55] <lifeless> MvG: you're pulling into a rich root format from a non-rich root; I'm guessing the lp branch yyou're pulling is not the bzr-svn import
[17:55] <MvG> What would you like to do about it? Have a bug report? Wishlist item? Some kind of benchmarking testcase? Or declare it as somebody elses problem?
[17:56] <lifeless> MvG: its our problem; what we really want is to have everyone using rich-root, but there is a bug remaining to do the conversion
[17:56] <MvG> lifeless: No, I don't think it is either.
[17:57] <MvG> lifeless: I had tried to branch drictly from svn yesterday, but that failed due to a bug in bzr-svn, and I have seen no commit from jelmer since which would addressing that.
[17:57] <lifeless> MvG: is it https://code.edge.launchpad.net/~ted-gould/inkscape/trunk that you are pulling ?
[17:58] <MvG> lifeless: No, it's http://bazaar.launchpad.net/~vcs-imports/inkscape/main
[17:58] <lifeless> MvG: please grab http://bazaar.launchpad.net/%7Eted-gould/inkscape/trunk/ it should be nce and fast
[17:58] <lifeless> I'll tell ted to update the series
[17:59] <MvG> lifeless: Thanks, I'll do that to work on inkscape. Classified "workaround", as the slowness issue still remains, though.
[18:00] <jam> Odd_Bloke: I'm getting a bunch of test commits from you
[18:00] <jam> Odd_Bloke: Rev 1: start branch. in	http://bzr.daniel-watkins.co.uk/pqm/work/_trial_temp/bzrbranch
[18:00] <MvG> I've got a breakpoint in l347 of fetch.py, so I would get notified every 100 revisions. Last time I hit that is more than 10 minutes ago, so throiughput is less than 10 revisions per minute.
[18:02] <MvG> As the inkscape branch has 6052, that would mean about 10h to convert everything.
[18:06] <lifeless> MvG: the branch I have pointed you at will not do this conversion
[18:06] <MvG> lifeless: I know, I just wanted to illustrate the scope of the slowness for situations where no workaround is feasible.
[18:11] <jam> MvG: I believe if you branched locally into a non rich-root repository, and *then* branched into the rich root repository, it would likely be faster
[18:13] <MvG> jam: Why would it be faster? I was working from a downloaded (wget) copy of the branch, so network traffic didn't play a role any more. Over the net, it was slower still, I think.
[18:13] <jam> MvG: ok, I didn't realize you were using the local copy
[18:14] <MvG> I guess that was way up there in the backlog, when I first told about this and lifeless introduced me to the breakin debugger.
[18:14] <lifeless> MvG: so there is always a workaround - don't cross-grade the data
[18:16] <MvG> As long as I don't need any of the features provided by rich root packs. As I couldn't name any such feature right now, I think it usually should work.
[18:27] <Odd_Bloke> SimpleTAL makes my eyes hurt. :(
[18:27]  * beuno hands eye drops to Odd_Bloke 
[18:28] <beuno> :)
[18:28]  * Odd_Bloke hands Mako to beuno.
[18:28] <Odd_Bloke> ;)
[18:28] <beuno> haha
[18:28] <beuno> well, we looked into it
[18:29] <beuno> it's faster, just not structured like we want it to
[18:29] <beuno> *be
[18:30] <Odd_Bloke> Structure within templates, or higher-level structure than that?
[18:30] <beuno> within templates
[18:31] <Odd_Bloke> I just don't like templating engines that put their structure inside the HTML elements.  It means I'll have to write a comment saying, essentially, what I could just write as code in one that uses a Mako/Django style.
[18:33] <Odd_Bloke> Hmm, BB is down.
[18:33] <Odd_Bloke> Ominously soon after I submitted the first patch testing the new functionality.
[18:33] <Odd_Bloke> s/testing/utilising/
[18:34] <radix> Odd_Bloke: there's a bzr buildbot?
[18:36] <Odd_Bloke> radix: BB is BundleBuggy in bzr parlance.
[18:36] <radix> oh, woops
[18:36] <Odd_Bloke> :D
[18:37] <MvG> Anyone here familiar with the gentoo overlay managed by malept? It caused bzr 1.5 to break here: http://rafb.net/p/xyIkQ870.html
[18:40] <Verterok> MvG: I was getting the same error, then I changed to this branch of the overlay lp:~mocksoul/bzr-gentoo-overlay/bzr-gentoo-overlay
[18:42] <MvG> jelmer: Starting from the bzr-svn branch of inkscape from http://bazaar.launchpad.net/%7Eted-gould/inkscape/trunk/ as mentioned above, I tried to pull the remaining revisions using bzr-svn directly from the svn repository. bzr-svn then crashed on me in find_tags: http://rafb.net/p/LdJtdP94.html
[18:42] <MvG> Verterok: Thanks, I'll try that.
[18:47] <emilis_info> I have heard there will be a bzr development sprint in EuroPython conference in Vilnius tomorrow
[18:47] <MvG> The issue with the http://bzr.malept.com/bazaar-overlay/ branch can be reproduced on the command line with bzr 1.5, but current bzr.dev works fine. Do you intend bug-fixing maintainance backports to the 1.5 branch? SHould I report this somewhere?
[18:47] <emilis_info> Couldn't find the guy who anounced it though
[18:47] <emilis_info> anyone know anything about this?
[18:49] <Verterok> beuno: hi
[18:49] <beuno> howdy Verterok
[18:50] <Verterok> beuno: still around Europe?
[18:51] <beuno> Verterok, yeap, still working too.  I should be back on sunday
[18:52] <beuno> how's your holiday?
[18:54] <Verterok> beuno: quite nice, it's good to wake up late. also working, but in bzr-java-lib and xmlrpc service ;-)
[18:57] <beuno> Verterok, I've been getting up at 7am, please don't tell me about waking up late  :)
[18:58] <Verterok> beuno: ouch, I fully understands your suffering
[18:58] <jam> beuno: bah, my son is waking me up at ~5:45 the last two days
[18:59] <jam> kids seem to really sleep by the sun, which seems to be forgotten in our general society
[18:59] <beuno> jam, well, I suppose you can nap when he does, babies sleep a lot
[18:59] <jam> or at least, our son did, it is kind of hard to push them to stay awake or go to sleep earlier
[18:59] <beuno> I don't think it'll look good if I fall asleep at a desk in Canonical
[18:59] <jam> beuno: except he naps during work hours :)
[19:00] <beuno> heh, right
[19:00] <beuno> smart guy
[19:00] <jam> the real trick is to not work until 1am
[19:00] <jam> that helps a lot
[19:00] <beuno> that is, if you can still manage the deadlines without doing so
[19:00] <jam> I didn't know you were working at Canonical HQ.
[19:00] <Odd_Bloke> I find that getting up to start work at 1am increases my productivity a great deal.
[19:01] <jam> beuno: well, if you are having deadline problems, either they are unrealistic, or you have poor time management skills :)
[19:01] <beuno> jam, been here last week, and will be here til the end of this one.  My trip was a bit... unexpected  :)
[19:01] <beuno> jam, or both!
[19:01] <jam> beuno: yeah, poolie mentioned your work rotation might get a bit interesting
[19:02] <beuno> jam, hopefuly it will. I'll know the details in the next few weeks
[19:02] <jam> beuno: I should also mention that he woke up about 4 times last night... at least it was always for a short time
[19:02] <jam> sometimes he'll wake up at 3, and then not sleep for ~1 hr
[19:02] <jam> silly babies
[19:03] <emilis_info> jam, how old is he?
[19:03] <emilis_info> :)
[19:03] <beuno> jam, sounds fun
[19:03] <jam> 10 months
[19:03] <emilis_info> mine is 5 months today
[19:03] <jam> grats emilis_info
[19:03] <Odd_Bloke> I suppose one advantage of working for Canonical is that there'll almost always be someone up to work with.
[19:03] <emilis_info> thanks :)
[19:04] <jam> Odd_Bloke: except bzr is mostly US & AU, we need to get more Europe people hired
[19:04] <Odd_Bloke> *COUGH*
[19:04] <jam> Odd_Bloke: then what are you doing working if you started at 1am :)
[19:04] <jam> by my count, it is ~7pm there
[19:05] <Odd_Bloke> It was about 4am this morning.
[19:05] <jam> ah, ok, keep working then
[19:05] <jam> I wouldn't want you to slack off
[19:05] <Odd_Bloke> I'm having to adjust from Australian to British time by Friday.
[19:06] <jam> Odd_Bloke: what were you doing in AU?
[19:06] <Odd_Bloke> I wasn't, I was just keeping AU time.
[19:06] <Odd_Bloke> Until the last couple of days I haven't really been sure of what I was doing PQM-wise.
[19:07] <radix> we try to keep consistent schedules in canonical, at least :)
[19:07] <Odd_Bloke> And being on British time tends to mean I dump stuff at the end of the day and wake up to reviews being there.
[19:07] <Odd_Bloke> Which isn't particularly helpful if I need to chat to someone about what I'm doing.
[19:08] <beuno> Odd_Bloke, do what I did. Just sleep australia time.
[19:08] <Odd_Bloke> beuno: Yeah, I was. :)
[19:09] <beuno> and leave reviews for jam   :p
[19:09] <jam> radix: 4-10 on mondays, 8-6 on tuesday-thurs, 8-4am on fridays ?
[19:09] <jam> Odd_Bloke: well, I've been used to dumping stuff at the end of the day, and then *maybe* waking up to reviews for a while now :)
[19:09] <jam> AU time starts when I get done
[19:10] <jam> which has the small benefit that I *can* drop by in the evening and see poolie/lifeless
[19:10] <jam> And I probably do that far too often :)
[19:10] <Odd_Bloke> Heh.
[19:10] <Odd_Bloke> I had noticed. :p
[19:11] <jam> Anyone here know zsh very well?
[19:11] <jam> I'm trying to configure my prompt by inserting the output of a script
[19:11] <jam> and it doesn't seem to want to run ti
[19:11] <jam> it
[19:12] <jam> In bash, I just put $(command) into the PS1
[19:18] <jam> Doing that in zsh just runs the command right away, and not each time
[19:18] <jam> using \$(command) ends up only printing the string $(command)
[19:18] <james_w> emilis_info: LarstiQ is at EuroPython I believe
[19:20] <emilis_info> james_w, hmm... thanks. I'll need to find him tomorrow :)
[20:17] <statik> anyone got a good example of how to use bzr-builddeb?
[20:18] <james_w> hey statik
[20:19] <james_w> if you are in a branch with ./debian/ then "bzr-builddeb" should build it
[20:19] <james_w> are you trying to build something, or are you setting up a package in a branch?
[20:19] <james_w> http://jameswestby.net/bzr/builddeb/user_manual/
[20:20] <statik> hi james_w! i'm looking to create a new package, and i want to keep in in bzr
[20:20] <statik> it's a really simple metapackage, which i'm adapting from another package, but the package I am copying from doesn't use version control
[20:20] <james_w> cool, so is it a native package?
[20:20] <statik> yes
[20:21] <statik> this doc you pointed me to is good, I had not found that yet
[20:21] <james_w> ok, native packages are easy :-)
[20:22] <statik> james_w: that doc says I need to create the branch with --dirstate-trees, is that still true?
[20:22] <james_w> the important bit is:
[20:22] <james_w> $ mkdir .bzr-builddeb/
[20:22] <james_w> $ echo -e '[BUILDDEB]\nnative = True' > .bzr-builddeb/default.conf
[20:22] <james_w> $ bzr add .bzr-builddeb/default.conf
[20:22] <james_w> statik: it's both wrong and false and outdated and stupid
[20:22] <statik> heh, ok :)
[20:23] <james_w> I need to push the updated docs there sometime.
[20:38] <awilkins> jelmer: ?
[20:41] <awilkins> Hmmph, these test reports need better instance-comparability
[22:22] <GaryvdM> Hi - In qbzr you can run "bzr qlog FILENAME" to see the history of that file.
[22:23] <GaryvdM> When you do that, unfortunately the ui locks up.
[22:23] <GaryvdM> This happen during the call to branch.repository.texts.get_parent_map
[22:24] <GaryvdM> see http://bazaar.launchpad.net/~qbzr-dev/qbzr/trunk/annotate/279?file_id=liblogmodel.py-20080624153442-csesbwmxg0s8db2x-1#L121
[22:25] <GaryvdM> Is there a way to do the incrementally?
[22:25] <james_w> an --lsprof output might be helpful to know what's eating the time
[22:25] <james_w> I'm not familiar with the .texts interface to know if it is likely to be slow
[22:26] <james_w> I know that "bzr log filename" is very slow, but I think that is implemented in a different way.
[22:26] <GaryvdM> I've been reading the code. If I could get to branch.repository.texts._index._graph_index.iter_entries - that is incremental
[22:27] <GaryvdM> It's similar to "bzr log filename"
[22:28] <GaryvdM> I'm not so worried about the speed. I would just like to be able to update our ui while it is happening.
[22:28] <james_w> ah, I've looked above now, maybe not using a list comprehension for text_keys would allow you to make it incremental
[22:29] <james_w> so, loop over self.merge_sorted_revisions calling get_parent_map each time
[22:29] <GaryvdM> Oh - ok - let me try that.
[22:30] <james_w> there shouldn't be too much of a performance hit
[22:30] <james_w> if that works then you could experiment with batching
[22:30] <james_w> the show_log code batches some of its operations, which makes a big difference.
[22:32] <awilkins> Offtopic : who's good with XSLT?
[22:33] <awilkins> CAn you pass a {$variable} as part of your input document and have the XSLT expand it?
[22:43] <GaryvdM> Thanks james_w - That worked.
[22:43] <james_w> really?
[22:44] <GaryvdM> Yip - now it need to try get it to load on screen incrementaly
[22:44] <GaryvdM> *now I need
[22:46] <james_w> well, even a stopped clock is right twice a day :-)
[22:46] <pygi> hi ho
[22:46] <GaryvdM> lol
[22:47] <james_w> hey pygi
[22:47] <james_w> you get around :-)
[23:05] <GaryvdM> Huh
[23:05] <GaryvdM> bzr qlog bzrlib\tree.py
[23:05] <GaryvdM> is now about 4x faster (wall clock time)
[23:05] <GaryvdM> than bzr log bzrlib\tree.py >/dev/null
[23:07] <james_w> GaryvdM: nice work
[23:08] <james_w> have you looked to see if log itself could be sped up here?
[23:08] <GaryvdM> Thats what I'm thinking.
[23:20] <GaryvdM> james_w: Making the same change to bzr log makes it much faster.... :-)
[23:20] <GaryvdM> Patch on the way.
[23:20] <james_w> GaryvdM: great!
[23:21] <mwhudson> is it log <FILE> specific?
[23:21] <GaryvdM> Yes
[23:23] <mwhudson> ah well
[23:23] <mwhudson> :)
[23:26] <james_w> I found that the limiting factor in plain log was revision extraction.
[23:30] <jam> mwhudson, GaryvdM: I also will guess it will break our test suite
[23:30] <jam> It is slow not because we can't get the graph of just the changes to a file
[23:30] <jam> but because we want to see the revisions which merged those changes
[23:30] <jam> So in:
[23:31] <jam> A
[23:31] <jam> |\
[23:31] <jam> | C
[23:31] <jam> |/
[23:31] <jam> B
[23:31] <jam> We want to see both 'C' and 'B'
[23:31] <jam> even though the file was only changed in C
[23:31] <jam> (This was back when we discussed per-file merge logic.)
[23:31] <jam> GaryvdM: I would be happy to be proven wrong, though. :)
[23:31] <mwhudson> jam: but if you  have the merge sorted revision graph (which log does) finding B from C really isn't so hard
[23:31] <GaryvdM> jam: how do I check?
[23:32] <mwhudson> GaryvdM: 'bzr selftest log' i would imagine
[23:32] <GaryvdM> ok
[23:32] <jam> mwhudson: I would guess you are right (though *getting* that merge sorted graph is also quite slow)
[23:33] <jam> There are also issues with doubly nested merges, etc.
[23:33] <mwhudson> jam: oh sure
[23:33] <mwhudson> jam: but you need to do that anyway to be able to number the revisions (today, anyway)
[23:39] <GaryvdM> Hmm - does break test :-(
[23:40] <jam> GaryvdM: so if you have the per file graph, and you have the merge_sorted graph
[23:40] <jam> I *think* you can start iterating over the merge sorted graph
[23:40] <jam> when you find a revision that is in the per-file graph
[23:40] <jam> you just need to include all merge sorted revisions with a depth < the current depth
[23:40] <jam> until you reach mainline
[23:40] <GaryvdM> ok
[23:41] <jam> I can't promise that, but I think it would work
[23:45] <mwhudson> there is code in loggerhead to do this :)
[23:47] <mwhudson> http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/annotate/head:/loggerhead/history.py#220
[23:47] <mwhudson> that's perhaps not quite what you want
[23:47] <mwhudson> but it has the flavour
[23:50] <tolstoy> Hi Folks, I'm getting an error: ValueError: failed to deserialize tag dictionary ....
[23:50] <tolstoy> Is there anything I can do about that?
[23:50] <tolstoy> I can't "branch" the branch because of it.
[23:50] <james_w> tolstoy: that sounds like file corruption to me
[23:50] <james_w> of .bzr/branch/tags
[23:51] <tolstoy> Hm. Just erase it and maybe to a pull or something from another branch?
[23:51] <tolstoy> I think it has later tags, though.
[23:51] <james_w> can you see what state it is in before doing anything?
[23:51] <james_w> is there obvious corruption
[23:52] <james_w> I'm not even sure that it's not a binary file though
[23:52] <tolstoy> It's just a long string, but I don't know the format in order to tell what's corrupted.
[23:53] <james_w> I think it might be rio, but I'm not familiar with it either
[23:54] <tolstoy> The difference between it and the "HEAD" that it was branched from is a weird \n appended to it.
[23:54] <james_w> I assume you haven't edited it at any point
[23:55] <tolstoy> Nope.
[23:55] <james_w> there was a problem recently where someone's dirstate had a \n appended as well, I don't think they share a codepath though
[23:55] <james_w> it would be odd for disk corruption to just append \n to a file
[23:56] <tolstoy> Very odd.
[23:57] <tolstoy> Ah, okay. The "corrupt" one has a line feed, not the characters "\n" on the end of it, which I thought it did at first.
[23:59] <james_w> so it ended \r\n?