[00:09] <igc> morning all
[00:09] <igc> moening lifless, mwhudson
[00:10] <igc> let's try that again ...
[00:10] <mwhudson> hi igc
[00:10] <igc> morning lifeless, mwhudson
[00:10] <mwhudson> :)
[00:21] <jml> lifeless: why doesn't aws-status read my access key from the same file as ec2test?
[00:22] <jml> i.e. ~/.ec2/aws_id
[00:23] <lifeless> it uses the same variables as bzr ec2test
[00:23] <lifeless> and if it doesn't find it it will look in gnome-keyring too
[00:24] <lifeless> you could file a bug to have it look at a file as well; AFAIK the amazon toolchain just looks for environment variables, which is why I copied that
[00:24] <jml> lifeless: ok.
[00:24] <jml> lifeless: the real answer might be "Why does Launchpad's ec2test use a non-standard file"
[00:24]  * jml makes a note
[00:26] <lifeless> of course, if the amazon toolchain does read a file, a bug on txaws is definitely in order
[00:27] <jml> lifeless: yeah. I'll chase it up later.
[00:28] <lifeless> thanks
[00:36] <AfC1> lifeless: Robert, you're signing emails with a key that's not on the public keyservers. You might want to upload it somewhere.
[00:37] <lifeless> AfC: odd, I have. it just hasn't propogated ><
[00:37] <AfC> lifeless: It's not on subkeys.pgp.net or pgp.mit.edu
[00:38] <AfC> lifeless: I would have thought you would have uploaded to them directly, seeing as how they're the main ones
[00:40]  * igc working on branch-specific rules today
[00:41] <lifeless> igc: you were going to mail about the issue; have I missed that ?
[00:41] <igc> lifeless: nope - sending it today
[00:54] <poolie> good morning
[00:57] <thumper> how worried should I be about 2485 revisions missing parents in ancestry and 3547 inconsistent parents?
[00:57] <lifeless> thumper: it will be affecting the output of annotate
[00:58] <lifeless> the 2485 are the unimported arch revisions
[00:58] <thumper> 2645 ghost revisions
[00:58] <lifeless> oh hmm
[00:58] <igc> morning poolie
[00:58] <lifeless> then its filled in ghosts
[00:58] <bob2> would it be sensible to have 'bzr bind' with no args pick one of the configured urls (maybe in order: parent, push, merge)?
[00:58] <lifeless> you should reconcile anyhow
[00:58] <poolie> helol igc
[00:58] <lifeless> bob2: confusing
[00:58] <poolie> will comment on your docs soon
[00:59] <lifeless> bob2: as it already has a saved bound location
[00:59] <thumper> lifeless: what will reconcile do?
[00:59] <poolie> bob2: if it guaranteed to rebind just where it was last bound
[00:59] <poolie> what he said
[00:59] <lifeless> it will rewrite the parents
[00:59] <thumper> to what?
[00:59] <lifeless> to the correct value based on the data available in the repository
[01:00] <bob2> lifeless: hm, I meant, only if it didn't have a previously saved one
[01:00] <lifeless> bob2: still confusing, no
[01:00] <bob2> ok
[01:00] <lifeless> bob2: as in
[01:00] <lifeless> bind (grabs parent)
[01:00] <lifeless> pull x (sets parent in master and local)
[01:00] <lifeless> unbind
[01:00] <lifeless> bind
[01:00] <lifeless> (does not grab parent)
[01:14] <bignose> with Loggerhead, browsing a file gives me the “annotate” view
[01:14] <thumper> what's the status of bzr-hg?
[01:14] <bignose> how can I just view the content of the file from head, without annotation?
[01:15] <bignose> i.e. the URL formed has …/trunk/annotate/head%3A/README
[01:15] <bignose> what URL should I use instead to just display the raw content of that revision of the file?
[01:16] <lifeless> mwhudson: ^
[01:16] <mwhudson> bignose: there is no view to display the raw content
[01:16] <bignose> :-(
[01:17] <mwhudson> bignose: because we're worried about xss attacks
[01:17] <mwhudson> bignose: there is a branch which adds it somewhere, but we need a way to turn it off
[01:18] <mwhudson> bignose: https://code.edge.launchpad.net/~intellectronica/loggerhead/view-file is one
[01:19] <bignose> mwhudson: thanks for the response.
[01:19] <lifeless> mwhudson: 'if hacked(): disable_it_now()' ?
[01:19] <mwhudson> bignose: np
[01:19] <mwhudson> lifeless: yeah
[01:20] <lifeless> it would be nice to be able to get at plain text versions
[01:20] <lifeless> its a pity that browser authors are insane
[01:20] <bignose> mwhudson: actually on second thought: what XSS vulnerability?
[01:20] <lifeless> [content sniffing]
[01:20] <lifeless> bignose: I could upload arbitrary html to my branch
[01:20] <bignose> shouldn't it be just a matter of serving the file as ‘Content-Type: text/plain’?
[01:21] <mwhudson> ha, ha, yes, it should
[01:21] <lifeless> bignose: many browsers sniff content and ignore content-type
[01:21] <lifeless> bignose: and there is now a 'standard' under discussion for controlling when the do this. Its insane
[01:21] <bob2> haha
[01:21] <bob2> is it enabled via a meta tag?
[01:22] <bignose> lifeless: those broswers deserve to get pwned then :-)
[01:22] <bignose> hmm, though I guess in that case it's the site getting pwned.
[01:22] <lifeless> its batshit insane
[01:22] <lifeless> and es
[01:22] <lifeless> *yes*
[01:22] <lifeless> http://www.nabble.com/NEW-ISSUE:-content-sniffing-td22795699.html
[01:23] <lifeless> I should raise this on the wg
[01:23] <bignose> yes, please. that's intentional brokenness
[01:23] <bignose> it's like Reply-To field munging, except with hideous security vulnerability
[01:23] <lifeless> http://tools.ietf.org/html/draft-abarth-mime-sniff-00 is the spec
[01:26] <lifeless> mwhudson: in theory if you avoid all the holes in that, it would be safe to present it as application/octet-stream. Note that I haven't read the algorithm in sufficient detail to comment.
[01:26] <lifeless> I just followed the surface discussions
[01:26] <mwhudson> lifeless: that would be nice
[01:26] <bignose> eugh. ‘text/plain’ would be better
[01:27] <lifeless> bignose: what would be? (no quotes please)
[01:27] <bignose> content which can't display well as ‘text/plain’ should be downloaded anyway IMAO
[01:27] <mwhudson> but the fact remains that it's going to require a lot more effort to get right than it should
[01:27] <bignose> lifeless: fix yer UTF-8 man :-)
[01:27] <bignose> lifeless: text/plain
[01:27] <lifeless> bignose: I want to; its somewhere down in xlib
[01:28] <lifeless> bignose: we don't know what the type is as bzr doesn't encode mime types in its store
[01:28] <bignose> (specifically in the context of showing content of a file under VCS)
[01:28] <lifeless> bignose: so text/plain would be a guess, and work badly with showing a jpg, for instance
[01:28] <bignose> lifeless: yes, that's why I'm saying the common denominator should be text/plain
[01:28] <lifeless> its also likely that text/plain is one of the ones browsers sniff-up to html
[01:29] <bignose> right, and application/octet-stream would be *just as bad* for non-text content
[01:29] <bignose> lifeless: this was in direct response to you saying if-the-sniffing-problems-are-resolved
[01:30] <lifeless> bignose: oh; so they won't be. Browsers are out there (including FF as far as I know)
[01:30] <lifeless> the only way to resolve it is to implement http/2.0 and have a very large blacklist hammer for any nonconformant browsers that appear
[01:31]  * bignose deprecates stupid people.
[01:31] <lifeless> pragmatically thats not happening, so we have to a) convince authors not to be idiots from here on out, and b) work within the limits of whats out there
[01:31] <lifeless> 'resist the temptation to guess' isn't something that ie or mozilla had heard, I guess.
[01:38] <mwhudson> lifeless: i think the correct response to the issue in http://tools.ietf.org/html/draft-abarth-mime-sniff-00 involves a time machine and a very large bat
[01:39] <eferraiuolo> I was wondering if it's built in or if you need the bzr-git plugin to run: bzr branch git:// commands?
[01:40] <mwhudson> eferraiuolo: you need the git plugin
[01:41] <eferraiuolo> mwhudson: cool, well I'm about to branch it then :-)
[02:17] <Peng_> eferraiuolo: bzr-git depends on dulwich as well.
[02:32] <lifeless> poolie: I think a script is better than trying to get all devs to change their bug filing behaviour :)
[02:33] <poolie> it seems to me the importance needs to come from a human
[02:33] <poolie> i don't see how a script can generate it
[02:33] <poolie> it could make them all default to wishlist i guess
[02:33] <poolie> that might force people to dtrt
[02:33] <lifeless> medium seems fine to me
[02:34] <lifeless> anyhow, my previous comment was 'when I've thought about I do', which seems valid to me
[02:35]  * igc lunch
[02:39] <poolie> BB seems to be down..
[02:39] <lifeless> mondayitis
[02:40] <poolie> not a good day for servers apparaently
[03:03] <jelmer_> mwhudson: main improvement is that dpush to remote git repositories works now
[03:04] <jelmer_> mwhudson: and pull from remote git repositories only does one smart protocol command now
[03:20] <mwhudson> jelmer_: so nothing very interesting from a launchpad pov
[03:21] <jelmer_> mwhudson: no, not really
[03:21] <mwhudson> cool, less work for me :)
[03:23] <mwhudson> jelmer_: i set up a samba import on staging :)
[03:27] <jelmer_> mwhudson: :-)
[03:27] <jelmer_> mwhudson: are there other git branches there yet that I can look at?
[03:27] <mwhudson> well, some on staging
[03:28] <jelmer_> which ones?
[03:28] <mwhudson> but staging has just gone *bang*
[03:28] <mwhudson> jelmer_: etckeeper, gedit, banshee
[03:55] <jelmer_> re
[03:56] <jelmer_> thumper: it can view history but that's it, no fetch
[03:56] <lifeless> jelmer_: are you going to do some stuff to it?
[03:57] <jelmer_> lifeless: Don't have anything planned atm, would be interested in doing so
[03:58] <thumper> jelmer: what?
[03:58] <jelmer_> thumper: bzr-hg
[03:58] <thumper> jelmer: ah
[03:59] <thumper> jelmer: how big a repo can bzr-git handle right now?
[03:59] <jelmer_> thumper: I've imported samba on my desktop machine
[03:59] <thumper> jelmer_: how big is that?
[04:00] <thumper> in the big picture of things
[04:00] <thumper> say compared to the kernel
[04:00] <thumper> or evolution
[04:01] <jelmer_> thumper: IIRC it's ~70k revisions, about ~3k files in the tree on average
[04:01] <jelmer_> I'm not sure what the numbers are for the kernel
[04:01] <jelmer_> evolution is smaller than samba, at least
[04:02] <lifeless> less commits more files for the kernel, IIRC
[04:02] <jelmer_> thumper: the #1 bottleneck is the inventory handling in bzr
[04:03] <lifeless> jelmer_: in dev6 still?
[04:03] <wgrant> Does CHK fix that?
[04:04] <jelmer_> lifeless: dev6 is significantly better, but afaik the lp imports are still using 1.9
[04:04] <jelmer_> lifeless: with dev6 inventory handling accounts for 20% of the CPU time during git imports
[04:04] <lifeless> jelmer_: thats good; should be lower though
[05:26] <jml> where is the mainline commit message policy for bzr documented?
[05:33] <jml> I didn't realize that NEWS conflicts can never auto-resolve.
[05:46] <igc> lifeless, poolie, jam: status update & proposed direction for branch-specific rules sent to the list now
[05:50] <igc> jelmer_: ^^^
[05:52] <poolie> hi igc
[05:53] <poolie> igc re bug 345693 being closed
[05:53] <poolie> does that mean we should cross "Check performance of full inventory extraction" off the brisbane-core list?
[06:05]  * igc looks
[06:06] <poolie> ok so i see that means we now have a usertest for it
[06:06] <poolie> and iirc it didn't turn out to be too slow?
[06:06] <igc> poolie: I think it was slower but it's not a major deal for ls
[06:07] <poolie> ok
[06:07] <igc> it may be for other commands though
[06:07] <poolie> so, not too many of them should be using it
[06:07] <poolie> i'll cross it off for now
[06:07] <igc> poolie: ok. I'll rerun the benchmark soon as well to see where it's at
[06:08] <igc> poolie: on another topic, abentley has appointed you as the reviewer for his compositetree patch
[06:08] <igc> poolie: that makes you the bottleneck :-)
[06:08] <igc> poolie: he wants you to say wwhether the design doc is now sufficient or not to proceed
[06:08] <poolie> :)
[06:08] <poolie> ok
[06:10] <lifeless> popping up to the chemist, back soon
[06:56] <lifeless> jelmer_: oh, I know why it was slow for you to push cross-format
[06:56] <lifeless> jelmer_: it's john's changes to IDS
[07:01] <lifeless> poolie: 374726 for vila
[07:02] <lifeless> poolie: I suspect thats more than a day to have a good answer on
[07:02] <lifeless> poolie: so I'll look for other things tomorrow
[07:16] <poolie> bug 374726
[07:16] <vila> hi all
[07:16] <poolie> hello vila
[07:17] <vila> hmm thanks for the gift lifeless :)
[07:18] <lifeless> vila: anytime
[07:19] <lifeless> vila: I know you've looked at annotate recently :)
[07:19] <vila> lifeless: yup
[07:20] <vila> and from what I recall before paging in I can't see why it could become slower... I'll see
[07:21] <lifeless> well, if you bench a few juicy files from bzr and emacs and its fine, then we'll know :)
[07:21] <vila> ...and mysql :)
[07:22] <lifeless> indeed
[07:22] <lifeless> I built drizzle on the weekend
[07:22] <lifeless> ... and found [and fixed some] bugs :)
[07:23] <vila> sheesh, wrong button
[07:23] <lifeless> haha
[07:24] <lifeless> poolie: I've done as much wiki gardening as I think is useful for a few days
[07:24] <lifeless> back to check for a bit then signoff
[07:25]  * vila teach himself: heron is the background means no menu bar at the top of the screen
[07:34] <igc> hi vila
[07:34] <vila> hi Ian
[07:39] <vila> BB is down
[08:14]  * lifeless halt()s
[08:14] <Peng_> lifeless: Good night. :)
[08:19] <poolie> vila: can you try using lp reviews for some things?
[08:19] <poolie> you may get less outages
[08:20] <vila> poolie: sure, old habits... but in that case it's a bzr-gtk critical bug that got affected to bzr instead
[08:22] <poolie> oh ok
[08:22] <poolie> i just meant in general
[08:31] <vila> poolie: sure, my last submission(s?) to BB were followed by a 'damn it, use lp reviews ! You already pushed your branch ! You just have to use lp-open instead of bzr send !!!' :)
[08:33] <vila> spiv: I noticed that you have added some 'if token is not None: xxx.leave_lock_in_place()' at the *end* of one (may be two so far) tests,
[08:33] <vila> spiv: Am I right thinking that you forgot to delete them after having written more focused tests ?
[08:41] <spiv> vila: hmm, which tests?
[08:42] <vila> spiv: bzrlib/tests/per_repository/test_write_group.py test_abort_write_group_does_not_raise_when_suppressed
[08:43] <vila> spiv: bzrlib/tests/test_pack_repository.py test_abort_write_group_does_not_raise_when_suppressed and test_abort_write_group_does_raise_when_not_suppressed
[08:45] <spiv> vila: those two lines are there to suppress "object was locked when gc'd" warnings when possible
[08:46] <vila> spiv: haaa, so if I get rid of the warning you din't mind me deleting them then ?
[08:46] <spiv> vila: I suppose we could also achieve that by renaming foo back to repo and doing an unlock.
[08:46] <vila> yup: self.addCleanup(t.rename, 'foo', 'repo')
[08:46] <spiv> I don't mind you deleting them, but how are you going to get rid of the warning?
[08:46] <spiv> Ok.
[09:15]  * igc dinner
[09:54] <vila> lifeless: I know you're aware of the problem but I thought I'll share the fun anyway: Ran 1 test in 0.027s
[09:54] <vila> FAILED (errors=2)
[09:55] <vila> observed with an error in a cleanup hook :)
[09:56] <lifeless> yes, its by design ugly though it is
[10:34] <lifeless> vila: feel free to fix; though I think its low priority - its cosmetic not functional
[10:35] <vila> lifeless: naah, just surprising, I think the fix could be a bit hard to get rigth though and not worth the effort right now (test errors should be fixed anyway)
[10:35] <vila> and it's true that there was 2 errors...
[12:01] <jelmer_> mwhudson: what does lp run, dapper or hardy?
[12:11] <jelmer_> vila, lifeless: do you know perhaps?
[12:12] <vila> jelmer: I'd say dapper but since I'm not sure, you'd better check with a LOSA
[12:12] <elmo> jelmer_: hardy
[12:13] <vila> elmo: do you when it was upgraded ?
[12:13] <vila> yeah, know is missing of course :)
[12:15] <elmo> vila: not offhand; over 6 months ago?  I can find out exactly, if you really need to know
[12:15] <jelmer_> elmo: thanks
[12:15] <vila> elmo: thanks, that's precise enough :)
[13:04] <vila> abentley: BB is down
[13:04] <vila> abentley: but hi first, sorry :)
[13:05] <abentley> vila: Restarted.
[13:05] <abentley> vila: hi :-)
[13:09] <vila> abentley: how strange... For http://bundlebuggy.aaronbentley.com/project/bzr-gtk/request/<m2tz3x6rw6.fsf%40free.fr>, I got an ack email  to bazaar@list.canonical.com, which was wrong since it's for bzr-gtk, yet, on BB, it's correctly affected to bzr-gtk...
[13:10] <abentley> vila: Any reviewer can reassign a merge request to the correct project.
[13:10] <vila> but as soon as I got the ack email I tried to do that, BB has been down since
[13:11] <vila> and http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Cm2tz3x6rw6.fsf%40free.fr%3E is also valid 8-)
[13:11] <vila> BB is too magick :)
[13:45] <vila> jelmer: any change you can review the abvove ?
[14:10] <jelmer_> vila: sure, one sec
[16:18] <cornucopic> vila, Hello
[16:21] <vila> cornucopic: hi, how is your patch for #372800 going ?
[16:22] <cornucopic> vila, Just resumed looking at it. To make sure, that I am in sync with you on the bug, can you please take a look the bug report?
[16:23] <cornucopic> vila, the description: https://bugs.launchpad.net/bzr/+bug/372800
[16:23] <vila> cornucopic: I,m pretty we are sync, how about you submit a patch so we can discuss on concrete code :)
[16:23] <vila> s/pretty/pretty sure/
[16:24] <cornucopic> vila, Hmm..Okay :) As you suggest.. !
[16:28] <rbriggsatuiowa> I tried to shelve a delete and the unshelve failed miserably
[16:29] <rbriggsatuiowa> the ticket here https://bugs.launchpad.net/bzr/+bug/319790 seems to indicate this is fixed in later versions - what version will work (ie: is this in a release or dev version?)
[16:32] <vila> rbriggsatuiowa: 1.13 should include it AFAICS
[16:35] <vila_> rbriggsatuiowa: 1.13 should include it AFAICS (just got a crash here, don't know if you got that)
[16:35] <rbriggsatuiowa> I'm building 1.14 right now and can't find a --prefix option for setup.py ...
[16:35] <rbriggsatuiowa> I was running 1.10
[16:36] <vila_> rbriggsatuiowa: you know you can run from source right ?
[16:37] <rbriggsatuiowa> ahh - thanks
[16:40] <cornucopic> vila, I can safely use a string function to extract the port number from smtp_server ?
[16:41] <vila> cornucopic: yes, use split()
[16:41] <SamB> you mean .split(':'), yes ?
[16:42] <cornucopic> SamB, vila, yes
[16:42]  * SamB meant that question for vila ;-)
[16:42] <rbriggsatuiowa> vila: 1.14 worked for me - thanks
[16:43] <vila> rbriggsatuiowa: always happy to help (TM)
[16:43] <SamB> rbriggsatuiowa: you maybe want --home ~
[16:43] <SamB> that's what I use
[16:43] <rbriggsatuiowa> yeah - that's what I found once I read the FAQ (:))
[16:44] <SamB> It was used in some example in the Python documentation
[16:44] <rbriggsatuiowa> I'm too used to the --prefix configure option
[16:46] <SamB> hehe
[16:47] <SamB> I was pleased to see that git's build system defaults to installing in $HOME
[16:48] <rbriggsatuiowa> weird - I've always been a big fan of installing into /opt/app and fixing PATH when I do source installs
[16:48] <rbriggsatuiowa> makes it easy to hose old versions without hurting other apps - but a pain to maintain (have to set pythonpath as well)
[16:54] <vila> rbriggsatuiowa: old SunOS user maybe ? :-)
[16:54] <vila> rbriggsatuiowa: what os/version are you using right now ?
[17:02] <rbriggsatuiowa> gentoo
[17:02] <rbriggsatuiowa> the bzr version is way out of date
[17:03] <rbriggsatuiowa> 1.9
[17:04] <rbriggsatuiowa> I started using /opt when running rocks clustering stuff at work
[17:05] <vila> rbriggsatuiowa: rocks clustering, I see :)
[17:05] <rbriggsatuiowa> yeah - it's supposed to simplify clustering stuff - I found it a little binding
[17:06] <rbriggsatuiowa> I haven't used it in four years though, so it might be better
[17:12] <amit> vila, can you please take a look at http://pastebin.com/m6a72d8ad? Is this on the correct road?
[17:13] <Guest98791> vila, amit here..
[17:14] <vila> Guest98791: please, send a proper submission to the list or do a merge proposal from launchpad, it's far easier and efficient to review code in context than in pastebin/IRC, thanks in advance :)
[17:16] <Guest98791> vila, Ok. cool. Thanks.
[17:36] <cornucopic> the bzr-email plugin replaces the bzr installation's 'smtp_connection.py' ?
[17:42] <cornucopic> apparently, it uses its own copy of smtp_connection
[17:43] <cornucopic> and not the globally installed one
[18:22] <jelmer_> jam: hi
[18:22] <jelmer_> jam: when you talk about chk stacking you mean chk stacked on chk right?
[18:22] <jam> jelmer_: yes
[18:23] <jam> I think I have it all working
[18:23] <jam> I'm just doing testing
[18:23] <jelmer_> nice
[18:23] <jam> and uncovering stuff like: bug #375019
[18:26] <jam> hey vila... you know, we really should start chatting more often
[18:27] <jam> I got out of the habit with multiple conferences, and getting sick, but I'd like to catch up sometime
[18:30] <jelmer_> jam: whoops
[18:31] <jelmer_> jam: what about chk stacking on 1.9 and vice versa?
[18:31] <jelmer_> jam: 1.9-rr on chk I mean
[18:31] <jam> jelmer_: ATM we can't stack across serialization formats
[18:32] <jam> so no stacking 1.9-rr <=> dev6
[18:32] <jam> or svn <=> bzr anything
[18:32] <jam> etc
[18:32] <jelmer_> ah, ok
[18:32] <jelmer_> jam: svn <=> bzr has worked for quite a while :-)
[18:32] <jam> jelmer_: how did you manage that?
[18:32] <jelmer_> jam: bzr-svn provides fake VersionedFiles implementations
[18:33] <jam> Given that I get:
[18:33] <jam> bzr: ERROR: CHKInventoryRepository('file:///C:/Users/jameinel/dev/%2Ctmp/d6rr/.bzr/repository/')
[18:33] <jam> is not compatible with
[18:33] <jam> KnitPackRepository('file:///C:/Users/jameinel/dev/%2Ctmp/d6rr-b-stacked/.bzr/repository/')
[18:33] <jam> different serializers
[18:33] <jelmer_> that call Repository.get_revision() under the hood
[18:33] <jelmer_> and serialize again using the serialization format that 1.9-rich-root uses
[18:33] <jam> jelmer_: so it would fail for dev6, because you are explicitly casting to 1.9-rr ?
[18:34] <jelmer_> jam: yeah
[18:34] <jam> (also, you can stack 0.92 => 1.9 because the serializer didn't change)
[18:39] <jelmer_> jam: ok, so I guess we'll need something more generic at some point anyway
[19:01] <vila> jam: definitely, I was hoping to call you today but... so many things to do :)
[19:03] <jam> vila: not a big deal. I just saw your email, and realized we haven't talked in a while. Maybe tomorrow.
[19:04] <vila> jam: sure
[19:10] <Peng_> Space Shuttle! :D
[19:17] <Tak> couldn't see very well from here
[19:21] <Peng_> I couldn't see it at all. It was cloudy, and the trajectory may have interfered.
[20:09] <beuno> jam, w0000000t!
[20:09]  * beuno dances
[20:10] <LarstiQ> beuno: you received some lettuce in the mail? :)
[20:10] <beuno> jam, EVEN BETTER!
[20:10] <beuno> a patch for stacking on brisbane-core
[20:11] <Kissaki> yo, can you with bzr commit -m "" how can I add newlines?
[20:12] <Kissaki> aka line breaks
[20:12] <beuno> Kissaki, I think you need to drop the -m, and jump into an editor
[20:13] <LarstiQ> it can be done with -m
[20:13] <Kissaki> hm, ok
[20:13] <Kissaki> thx
[20:13] <Kissaki> can=can't ? ^^
[20:13] <LarstiQ> Kissaki: what I do is bzr ci -m 'Added foo.<hit enter>Added bar.'
[20:13] <LarstiQ> Kissaki: ie, let my shell handle the newlines
[20:14] <LarstiQ> Kissaki: can
[20:14] <Kissaki> tried \n, but that didn't work :/
[20:14] <LarstiQ> Kissaki: have you tried an actual literal enter?
[20:14] <Kissaki> hm?
[20:14] <LarstiQ> Kissaki: use the enter key.
[20:15] <Kissaki> pressing it will exec the cmd ofc
[20:15] <Peng_> Kissaki: Depending on your shell, if you're inside quote marks, it won't.
[20:15] <Kissaki> using windows cmd right now
[20:15] <LarstiQ> ah. windows cmd
[20:16] <LarstiQ> Kissaki: I don't know if the windows shell has support for multiline editing
[20:17] <LarstiQ> Kissaki: I'd leave off -m and spawn a commit editor then.
[20:17] <Kissaki> well, I'll try copy paste for comment next time
[20:17] <Kissaki> commit editor? is that something special?
[20:17] <LarstiQ> I doubt tricks like bzr ci -m `cat` will work on windows?
[20:17] <Kissaki> yeah
[20:18] <LarstiQ> Kissaki: it looks at $VISUAL or $EDITOR, and will spawn notepad on windows if it can't find anything else
[20:18] <LarstiQ> Kissaki: also, you configure what editor to use for commit messages, see `bzr help configuration`
[20:18] <sidnei> is there an argument for reading the commit message from a file? in svn you can do svn ci -F <filename> or something
[20:18] <LarstiQ> which might come in handy on windows
[20:18] <LarstiQ> sidnei: oooh, good one!
[20:18] <LarstiQ> that was even my first patch for bzr, shame I don't remember :/
[20:18] <LarstiQ> Kissaki: as sidnei said, you can use -F
[20:19] <luks> Kissaki: have you tried bzr qci
[20:19] <Kissaki> no
[20:19] <luks> it might not be what you want, but just in case
[20:19] <sidnei> qci is cool too
[20:19] <Kissaki> don't even know what ci is
[20:19] <luks> commit
[20:19] <Kissaki> ah
[20:19] <luks> (and qcommit)
[20:20] <Kissaki> what's the difference?
[20:20] <luks> it opens a dialog window
[20:20] <GaryvdM> nothing - qcli is an alias
[20:20] <luks> where you can type the commit messages, select files, see diffs, etc.
[20:20] <GaryvdM> qcli is an alias for qcommit
[20:20] <luks> *message
[20:20] <LarstiQ> GaryvdM: qcli or qci?
[20:21] <GaryvdM> err qci
[20:22] <Kissaki> oh, nice
[20:22] <Peng_> jam: You left a "bork" in bzrlib/repofmt/groupcompress_repo.py in the dev6 stacking patch. :P
[20:22] <Kissaki> qcommit indeed does open a commit window/dialog/editor thingy
[20:22] <Kissaki> thx
[20:35] <jam> Peng nice catch :)
[20:35] <jam> though that would hint that the code isn't exercised (as I thought it wasn't)
[20:37] <Peng_> :D
[20:38] <LeoNerd> Uhh... Where'd 'bzr revert' move my file to?
[20:38] <LeoNerd> It always used to keep a backup
[20:39] <beuno> LeoNerd, ~filename~
[20:40] <LeoNerd> I don't see one
[20:40] <beuno> LeoNerd, ls -la?
[20:40] <LeoNerd> In the directory it used to live, or in the treeroot?
[20:40] <LeoNerd> Well. it's absent either way
[20:40] <LarstiQ> LeoNerd: it doesn't leave backups if it can be constructed otherwise, afaik.
[20:41] <LeoNerd> Hrm...
[20:41] <LeoNerd> it was locally modified
[22:04] <eka> hi all
[22:05] <eka> is there any way to work using bzr with a git repo?
[22:05] <mwhudson> eka: yes, 'bzr-git'
[22:07] <eka> mwhudson: it's stable?
[22:08] <mwhudson> eka: it's moving quite quickly, but mostly in a positive direction :)
[22:08] <mwhudson> eka: it works pretty well, in my testing
[22:09] <eka> mwhudson: thanks for the tip
[22:09] <mwhudson> (launchpad will be using it to import git repositories into bzr soon)
[22:10] <jam> lifeless: ping
[22:24] <jelmer> mwhudson: so, bzr-git now supports using tdb to store its cache data
[22:24] <jelmer> mwhudson: which is significantly faster than sqlite
[22:28] <adamfast> I've got a question - a while back I upgraded via the installer to 1.13.2 (and then today to 1.14.1) but I keep getting a "bzr: WARNING: bzrlib version doesn't match the bzr program." the bzrlib version is 1, 14, 1, 'final' and bzr --version tells me it's 1.14.1. Has anyone seen this before?
[22:28] <adamfast> (I should mention I'm using a Mac with the Leopard Python 2.5)
[22:29] <thumper> adamfast: my guess is that the bzr executable isn't the one you installed
[22:30] <adamfast> any idea what the/a possible fix could be? Try to delete all the files and run the installer again?
[22:30] <mwhudson> jelmer: tdb?
[22:31] <mwhudson> jelmer: is it packaged for hardy?
[22:31] <jelmer> mwhudson: yep
[22:31] <thumper> jelmer: is it chosen automagically?
[22:31] <mwhudson> jelmer: hmm, where is the cache stored between runs?
[22:31] <jelmer> thumper: yep, we also still support sqlite
[22:32] <jelmer> thumper: and if tdb is not there sqlite is used like it was before, it'll just be slower
[22:32] <jelmer> thumper: (slower than tdb, not slower than it is with sqlite now obviously)
[22:32] <jelmer> mwhudson: it's in .bzr/repository/git.[t]db
[22:33] <mwhudson> jelmer: does push preserve it?
[22:33] <Peng_> Can you upgrade a repo from sqlite to tdb?
[22:33] <jelmer> mwhudson: no, but if it's not there bzr-git will regenerate it
[22:34] <mwhudson> jelmer: how bad is that, relatively speaking?
[22:34] <mwhudson> (because it seems with the system we have in place we'll regenerate it each time)
[22:34] <jelmer> mwhudson: one sec, I'll try on a bzr.dev repo
[22:35] <thumper> lifeless: you up yet?
[22:37] <jelmer> mwhudson: I guess it would be nice if push could preserve it I guess but we'd need better hooks for that
[22:37] <jelmer> mwhudson: also, if you don't keep this database around you'll hit problems when there are revisions that contain characters that can't be represented in XML
[22:38] <mwhudson> jelmer: well, it would be easy enough to preserve it by hand, esp if bzr-git can tell me where it should go for a branch
[22:38] <thumper> jelmer, mwhudson: well that is a handy thing to know
[22:38] <mwhudson> thumper: indeed
[22:40] <Peng_> Why's lp:dulwich a remote branch?
[22:40] <jelmer> mwhudson: regenerating the sha map takes 16 seconds for 1000 revisions (bzr-git)
[22:41] <jelmer> mwhudson: try 'bzr git-object' in any bzr branch to generate a full map
[22:41] <mwhudson> jelmer: will it need to do that for a pull where the remote tip hasn't changed?
[22:42] <jelmer> mwhudson: I'm not entirely sure
[22:42] <jelmer> mwhudson: it shouldn't need to, but I don't know what it does atm
[22:42] <jelmer> mwhudson: only one way to find out :-)
[22:43] <mwhudson> jelmer: :)
[22:43] <lifeless> thumper: yes
[22:43] <lifeless> thumper: but I'm doing bio stuff
[22:44] <thumper> lifeless: I've just done mine :)
[22:48] <thumper> lifeless: why does pack take so long with bbc?
[22:48] <thumper> packing launchpad with packs took under 3m
[22:48] <thumper> packing launchpad in bbc took over 3 hours
[22:49] <thumper> although packing packs went from 1.1G to 1.1G (not much change :)
[22:49] <thumper> packing bbc went from 248M to 137M
[22:50] <thumper> for the pack dir at least
[22:50] <lifeless> for xml based formats all pack does is reduce latency
[22:50] <lifeless> for the chk formats, we recompress
[22:50] <thumper> lifeless: is this going to happen automatically when combining packs?
[22:50] <thumper> lifeless: because if it does, it will make for very slow pushes :)
[22:51] <lifeless> thumper: 'bzr pack' recombines all history. of course its slow
[22:51] <mwhudson> jelmer: it seems maybe not
[22:51] <thumper> lifeless: but what about the autopack?
[22:51] <lifeless> autopack doesn't do a full pack
[22:52] <thumper> so it will still be fast?
[22:52] <lifeless> yes
[22:52] <lifeless> kindof an obvious question :)
[22:52] <thumper> cool
[22:52] <jelmer> lifeless: is it right that running 'bzr pack' in a dev6 repo multiple times gives "Pack already exists ..." after the first time ?
[22:53] <thumper> just making sure :)
[22:53] <lifeless> jelmer: file a bug please
[22:53] <lifeless> jelmer: its because we don't short-circuit pack and avoid doing it in dev6
[22:53] <jelmer> lifeless:  I guess that's a "no"
[22:54] <lifeless> jelmer: its not the desired behaviour :)
[22:55] <lifeless> thumper: autopack has a exponential backoff on frequency for a given text
[22:55] <lifeless> thumper: 10 autopacks of 10 revs in the first 99 commits, then one of 100 revs, and so on
[22:56] <lifeless> if you've got 100K commits, it will be a very long time before autopack decides to rewrite the 100K pack when you push a single revision
[22:56] <thumper> lifeless: just saying "yes it'll be fast" is good enough for me
[22:57] <lifeless> thumper: sure, but you may as well understand it too ;)
[22:57] <beuno> lifeless, https://pastebin.canonical.com/17459/    bug?
[22:57] <thumper> lifeless: however your explination doesn't help me understand because I'm missing too much context :)
[22:58] <lifeless> thumper: ok. In short - autopack may do a full pack, but its very rare, and becomes more rare thelarger the repo
[22:58] <lifeless> thumper: theres a heuristic, which seems to work well.
[22:59] <lifeless> beuno: bug
[22:59] <beuno> lifeless, danke. What does --default-rich-root default to in bzr.dev?   0.92 still?
[23:00] <lifeless> I'm not sure. that was on branch anyhow
[23:00] <jelmer> beuno: rich-root-pack
[23:00] <beuno> ah, lh is 1.9
[23:01] <beuno> so I guess it's trying to do 1.9 -> rich-root-pack
[23:01] <beuno> so failing
[23:01] <lifeless> beuno: its the branch object thats failing
[23:01] <lifeless> nothing to do with roots
[23:01] <beuno> oh
[23:03] <beuno> k, bug files
[23:03] <beuno> and filed
[23:04] <jelmer> heh, dpush from svn into git works (-:
[23:05] <jelmer> secretly bzr is just tailor Done Right [tm] ;-)
[23:06] <lifeless> jelmer: lol; scary, and 'No'
[23:11] <beuno> nice. Loggerhead in bbc is ~40% smaller, and "bzr log -v" takes less than half the time
[23:12] <beuno> (compared to 1.9)
[23:14] <luks> beuno: out of curiosity, how long is that? :)
[23:14] <luks> I'd expect that to still be unusable
[23:15] <beuno> luks, 3.7sec to 1.6sec
[23:15] <lifeless> beuno: be sure to bzr check ;; bzr reconcile before migrating
[23:15] <beuno> pretty usable
[23:15] <luks> what? log -v does still all the deltas?
[23:15] <lifeless> beuno: I encourage you to migrate to rich roots soon; see the thread on bzrtools which has migrated to rich roots already
[23:15] <beuno> lifeless, I will, although I'm just fooling around now, to try and hash out any obvious problems
[23:16] <beuno> lifeless, I'm more than happy to, if we can get mwhudson and Peng_ on board
[23:16] <jam> lifeless: I have to go now, but if I get some time, I'd like to chat after a few hours
[23:16] <lifeless> beuno: thats part of the process; read my mails ;)
[23:16] <lifeless> jam: sure
[23:16] <lifeless> jam: ping me
[23:16] <lifeless> jam: I'm going to be poking at check, then presentations
[23:17] <mwhudson> beuno: sure, no problems at all with going to rich root
[23:17] <beuno> lifeless, both check and reconcile?
[23:17] <lifeless> beuno: yes, or just reconcile
[23:17] <beuno> mwhudson, what happens with the existing stacked branches?
[23:17] <Peng_> beuno: My position on rich-roots hasn't changed. I'm on board, pending that email from a few weeks ago about changing how converting worked.
[23:17] <beuno> they all break?
[23:17] <lifeless> beuno: with a check afterwards
[23:17] <mwhudson> beuno: well that's the fun part :)
[23:17] <Peng_> Or whatever it was about.
[23:17] <mwhudson> beuno: i'm sure lifeless talks about that too in his mails
[23:18] <lifeless> beuno: 1) read my mails about this; 2) reply with anything unclear so we can capture it and improve - please
[23:18] <beuno> Peng_, mwhudson, ok, I may attempt to upgrade trunk later today then
[23:18] <beuno> check and reconcile looked ok on lh bbc
[23:19] <lifeless> beuno: read the mail first; doing it today would pretty much break all the rules
[23:19] <beuno> even when going from plain 1.9 -> bbc
[23:19] <beuno> ok, *today* I may read lifeless's email more carefully
[23:19] <beuno> and see where that takes me
[23:19] <lifeless> Peng_: noone has altering the conversion process in their queue that I know of
[23:22] <beuno> lifeless, any hint on how to find that email?
[23:23] <lifeless> Subject: 	[DRAFT][RFC] Migrating to rich roots
[23:23] <beuno> loggerhead is very spify on bbc: http://bazaar.launchpad.net/~beuno/%2Bjunk/loggerhead-bbc/changes
[23:23] <lifeless> spify?
[23:24] <lifeless> do you mean fast or pretty?
[23:24] <beuno> fast
[23:24] <lifeless> 3 seconds to toggle a >
[23:24] <lifeless> :<
[23:25] <beuno> not sure what that means
[23:25] <lifeless> in the changes pge
[23:25] <lifeless> there are > beside each rev
[23:25] <lifeless> if I click one, its about 3 seconds, sometimes up to 5, before the expanded content is complete
[23:25] <beuno> I clicked on expand all
[23:26] <beuno> and it took ~2-3 seconds to bring all of them in
[23:27] <Peng_> lifeless: I dunno. There was some email about somehting or other. I still don't know what it was about. :P
[23:28] <lifeless> beuno: 10 seconds to do that for me
[23:28] <lifeless> beuno: where are you at the moment
[23:28] <lifeless> Peng_: I do
[23:28] <beuno> lifeless, argentina
[23:28] <lifeless> strange :-)
[23:28] <beuno> lifeless, so upgrading to rich-roots breaks stacked branches. Can they be upgraded as well, or are they just discarded?
[23:28] <Peng_> Whoever did it first had to wait for the cache to be generated.
[23:28] <lifeless> Peng_: I did it second
[23:29] <lifeless> beuno: clean your eyes
[23:29] <lifeless> 3) Users migrate their own branches before this time, including lp
[23:29] <lifeless> hosted branches and particularly stacked branches.
[23:29] <beuno> lifeless, I don't follow
[23:29] <lifeless> Peng_: its possible its slower now its cached
[23:30] <beuno> current branches stacked can be upgraded to rich-root, even though the stacked-on branch isn't rich-root?
[23:30] <Peng_> Stupid question that I can figure out on my own: is it possible to push to a lightweight checkout on a remote server, where the branch is stored on the same server?
[23:30] <Peng_> s/can/should/
[23:30] <lifeless> beuno: yes, they will break after the upgrade; then when the stacked on is a matching format again, they will work again
[23:30] <beuno> lifeless, gotcha
[23:31] <lifeless> Peng_: it should be yes, unless the the server is chrooted so as to divide them
[23:31] <lifeless> Peng_: but it may not work dependign on the path in iuse in the checkout
[23:31] <Peng_> lifeless: In this case, no chroot, but they're totally different paths.
[23:32] <Peng_> Maybe I should use a stacked branch instead.
[23:32] <lifeless> Peng_: there's always a chroot
[23:32] <lifeless> Peng_: ChrootTransportDecorator
[23:32] <Peng_> Eh.
[23:32] <beuno> it pretty much sucks that all branches tied to merge proposals will break, unless we hunt down each and upgrade (which takes ages remotely)
[23:32] <lifeless> Peng_: and the jail
[23:32] <awilcox> okay it has been a few days so I think I will reask my question.  Is there any way to utilise Bazaar in XCode?
[23:32] <Peng_> Yeah, I love the jail.
[23:32] <lifeless> Peng_: the jail works with the chroot decorator
[23:33] <lifeless> awilcox: no idea sorry; have you checked the IDE page?
[23:33] <awilcox> lifeless: I have and it said that CVS, SVN, and Perforce are supported natively, but others can use a plug-in interface
[23:33] <lifeless> awilcox: I mean our one
[23:33] <lifeless> on bazaar-vcs.org
[23:33] <awilcox> I googled, and some people mentioned projects for a plug-in, but I haven't found the actual code.
[23:33] <Peng_> The situation is, I have branches of one project in 3 different locations, with a checkout in 1 of them, and want to get rid of one of the duplicate repositories. (The other can stay, I guess. Although I could convert it to a stacked branch too, hmm.)
[23:33] <awilcox> ohhhh sorry.
[23:39] <awilcox> http://bazaar-vcs.org/IDEIntegration doesn't even have XCode listed.
[23:39] <lifeless> :(
[23:39] <lifeless> care to add it?
[23:42] <awilcox> I don't see a way to edit the page
[23:43] <lifeless> bottom of the page is an edit link
[23:43] <lifeless> if you're logged in
[23:43] <awilcox> ah.  I don't have an account.
[23:43] <lifeless> if you don't have an account you can just create one, or I can add xcode to it for you (but I don't know anything about xcode which is why I asked you to add it :))
[23:45]  * beuno -> off for a while
[23:56] <Raim> hi
[23:56] <Peng_> Hello
[23:57] <Raim> I am trying to branch using bzr 1.9 as client from a server with bzr 1.5 using the bzr+ssh:// protocol
[23:58] <Raim> are these versions known to be incompatible?
[23:58] <mwhudson> Raim: no
[23:59] <Raim> so I am seeing these messages and it fails: http://pbot.rmdir.de/0347a921ae170e1ba6dfb075de29c6d0