[00:46] <poolie1> jml, interesting: i just did bzr push --remember -Dhpss --stacked bzr+ssh://bazaar.launchpad.net/~bzr/bzr/brisbane-core
[00:46] <poolie1> and it made it stacked on the public location of the parent branch, not on lp:bzr as i expected
[00:48] <jml> poolie1: right. so what I normally do, as advertised on the Launchpad blog, is just bzr push lp:~bzr/bzr/brisbane-core
[00:48] <jml> poolie1: bazaar's default stacking policy feature takes care of the rest
[00:49] <jml> poolie1: use --stacked essentially overrides our stacking policy
[00:49] <jml> s/use/using/
[00:53] <poolie1> interesting
[00:53] <poolie1> and bzr now defaults to stacked
[00:55] <jml> poolie1: only if there's a stacking policy on the other end.
[00:55] <jml> poolie1: which there is in this case
[00:56] <poolie1> that may not be so great til bug 288751 is ixed
[01:00] <jml> poolie1: then bug 288751 needs to be fixed.
[01:01] <poolie1> indeed
[01:01] <poolie1> aaron sent what seemed like a reasonable plan
[01:13] <abentley> poolie: I'm not actually sure how to tackle 288751.  I'm somewhat against disabling the current behaviour, because I suspect there are hundreds or thousands of afflicted branches.
[01:15] <rusty> Hi all!  Anyone interested in 'bzr upgrade' failures?
[01:16] <abentley> poolie: I'd rather bless the current behavior.  A subsequent format could be stricter.
[01:16] <poolie> rusty, yes
[01:16] <abentley> poolie: A groupcompress format would be stricter anyhow.
[01:16] <rusty> bzr: ERROR: Revision {[('_info.30342-20080814081531-zlq95k6nqflx7n8y-1', 'dinesh@dinesh-laptop-20080814081712-cckpecc9m4vao31v')]} not present in "<bzrlib.knit.KnitVersionedFiles object at 0xa3f474c>".
[01:17] <rusty> poolie: 1.6.1 from my upgrade yesterday to 8.10.
[01:17] <rusty> poolie: what do you need?
[01:17] <poolie> rusty: i suspect this is bug 288751 we're just talking about
[01:18] <poolie> it'd be useful if you add the 'bzr info' results on that to that bug
[01:18] <rusty> Domo aragato, ubottu.
[01:19] <poolie> abentley: do you want to talk here or on mail?
[01:19] <poolie> so the main question is just what server-side autopack should do
[01:19] <abentley> poolie: No, it's larger.
[01:20] <abentley> poolie: The main question is "should we permit text deltas across stacked repositories"?
[01:20] <poolie> so i basically agree with robert that we should not be generating them
[01:20] <poolie> s/basically//
[01:20] <rusty> poolie: bzr info?  After failure or before?  Output not interesting.
[01:20] <abentley> poolie: There's no server-side autopack involved here.
[01:21] <poolie> does it say it's stacked on something?
[01:21] <rusty> poolie: no...
[01:22] <abentley> poolie: Fine, but we've already generated many stacked branches.  They are probably afflicted.  How should we deal with them?
[01:24] <abentley> AFAICT, robert wants bzr to fail if it encounters them.  I am more inclined to keep existing branches working.
[01:26] <rusty> poolie: It's a very vanilla tree I think.  And just not that complicated.
[01:26] <poolie> rusty: i would suggest that you make a backup, run bzr reconcile, bzr check, bzr upgrade
[01:27] <poolie> if that does not fix the problem, file a bug, and if the code is public attach a tarball of it
[01:27] <rusty> poolie: OK, I'll try that now.
[01:27] <rusty> poolie: yes, good news is this is all public.
[01:27] <poolie> insert before those instructions, move backup.bzr back in place
[01:28] <rusty> poolie: woot!  I blew up reconcile!  Do I get a prize??
[01:28] <poolie> yes :/
[01:29] <poolie> abentley: so perhaps we could do a query on lp for branches that are stacked, and then look at if they have text deltas across repositories
[01:29] <rusty> I will report a bug and attach the 4MB tarball of the whole repo.
[01:29] <poolie> thanks
[01:29] <poolie> for reporting it, and sorry for the incovenience
[01:29] <rusty> poolie: heh, I've filed 6 KDE4 bugs in the last 12 hours... this is nothing :)
[01:30] <jml> poolie: how would that influence the decision?
[01:30] <poolie> heh
[01:31] <jml> also, we don't record all instances of stacked branches, only branches stacked on other branches also in/mirrored on Launchpad.
[01:32] <abentley> jml: because of the bzr+ssh bug, no one would want to stack their launchpad branches on something else.
[01:32] <jml> abentley: that's comforting.
[01:32] <ryanakca> why do I get this with any bzr command? http://paste.ubuntu.com/70759/
[01:32] <poolie> so if it's only happened on the particular branches were lp recommends stacking, then it's more reasonable to do a one-off fix
[01:33] <poolie> ryanakca: because the gtk plugin (or something related) is assuming you have a desktop running
[01:33] <poolie> but i would guess you're running it from a text or ssh session or similar
[01:33] <poolie> i think this was fixed in a later release
[01:34] <poolie> https://bugs.edge.launchpad.net/bzr-dbus/+bug/199513
[01:35] <ryanakca> poolie: could it be qctBzrPlugin? Its the only one without a description... the rest: http://paste.ubuntu.com/70761/
[01:36] <jml> poolie: so, I don't see the # of affected branches as being a factor.
[01:37] <jml> poolie: either you break them and provide a script (or whatever) to fix them, or you accommodate them and fix the underlying issue in a new format.
[01:38] <rusty> poolie: OK, filed bug 297024.  That should keep you off the streets for a bit longer :)
[01:38] <ryanakca> poolie: nevermind, thats what it is...
[01:41] <poolie> jml, that's basically true - if it turned out to be just one or two it would be more reasonable to say 'just remirror them'
[01:41] <ryanakca> poolie: or what I thought it was. Still there. What can I do? If I go --no-plugins, it disables the svn plugin as well... but I need the svn plugin to checkout / svn->bzr...
[01:42] <poolie> ryanakca: can you upgrade?
[01:42] <poolie> or otherwise remove the gtk or qt plugin
[01:43] <jml> poolie: I seriously doubt it's 1 or 2
[01:44] <ryanakca> poolie: I can't see any of them installed... I removed qct, which is a qt one... but, I still get it... all of my plugins are in the above paste.
[01:44] <jml> poolie: when spm gets back, he can tell us which branches are stacked. I'll need more bzr expertise to get a test for the other bit.
[01:44] <poolie> ryanakca: reckon the 'dbus' one might have anything to do with it? ;-)
[02:08] <abentley> jml: You should be able to repurpose Packer._check_references to do that.
[02:09] <lifeless> abentley: or james-w's script
[02:13] <abentley> lifeless: I didn't see that one.
[02:20] <lifeless> abentley: its attached to one of the bugs
[02:26] <jml> abentley: everything about that except the pronoun sounded great :)
[02:27] <abentley> jml: Y'all should be able to repurpose Packer._check_references to do that?
[02:27] <jml> abentley: "one should be able to..."
[02:28] <jml> poolie: fwiw, we're looking at 300+ stacked branches on LP
[02:57] <jml> well, the list of branch ids is at https://pastebin.canonical.com/11067/. Let me know if you need a hand writing the script :)
[03:02] <awmcclain> Why aren't new branches I push group writable? Am I missing some umask for bzr?
[03:03] <abentley> awmcclain: are you using sftp?
[03:04] <awmcclain> bzr+ssh
[03:05] <abentley> awmcclain: There's no bzr-specific umask.  What does "ssh $HOSTNAME umask" report?
[03:07] <awmcclain> 0022
[03:07] <abentley> awmcclain: So your remote host umask is set to disable group write.
[03:08] <awmcclain> Ah. I figured it was a system configuration. I'll go look up ssh and umask.
[03:38] <adeel> what's the easiest way to create a central branch and commit data to it? the user-guide isn't very clear on it
[04:09] <Peng_> Wait...can anyone log into pastebin.canonical.com?
[04:11] <lifeless> Peng_: anyone can authenticate
[04:11] <Peng_> Oh.
[04:11] <lifeless> adeel: once you have your code locallly; bzr push CENTRAL BRANCH
[04:12] <lifeless> adeel: then 'bzr bind CENTRAL_BRANCH' to make that into a checkout, and other people can do 'bzr checkout CENTRAL_BRANCH'
[04:12] <adeel> lifeless, so does that work if the central repo is local to my system? that is, i want the repo to be stored at /foo, but right now, the contents of the files are at /bar
[04:13] <Peng_> You're right, I can /authenticate/. I just don't have permission to access anything. ;P
[04:15] <poolie> for some reason bzr builddeb is not following its .bzr-builddeb/local.conf
[04:15] <lifeless> adeel: yes
[04:16] <adeel> lifeless, interesting...thanks for the info...and btw, if you know who maintains the user's guide on the bzr website, they might need to update/clarify it
[04:17] <lifeless> adeel: file a bug with whats unclear please
[04:19] <adeel> lifeless, sure
[04:20] <adeel> also, what transports are enabled by default for bzr? sftp? http? ssh? etc
[04:20] <lifeless> everything that the libraries for are on your system
[04:20] <adeel> there a way to find out which ones are?
[04:20] <lifeless> the deb packages depend on enough to have ftp/http(but not webdav)/ssh/bzr/filesystem/sftp work
[04:21] <lifeless> adeel: bzr help urlspec
[04:21] <adeel> ah, i'm on gentoo, so the deb packages don't help =cp
[04:21] <adeel> thanks for the tip
[04:57] <poolie> lifeless: what i'm saying is
[04:57] <poolie> if you push to lp/bzr, you may also hit the stacking issue
[04:57] <lifeless> oh sure
[04:57] <lifeless> but I have ways and means for that "{
[04:57] <lifeless> :P
[05:01] <lifeless> poolie: can you do me a favour
[05:01] <lifeless> poolie: push to lp:~bzr/bzr/brisbane-core, the branch you have?
[05:01] <lifeless> it won't stack
[05:06] <poolie> it's runnig
[05:21] <lifeless> http://paste.ubuntu.com/70801/
[06:14] <lifeless> igc: /srv/conversions/manganese on tungsten
[06:14] <lifeless> igc: 136Gb, knock yourself out
[06:14] <fullermd> You can't mix manganese and tungsten!
[06:15] <lifeless> fullermd: not mixing. layering
[06:15] <fullermd> Stacking?   ;)
[07:09] <abentley> lifeless: Do you know why pqm would treat bzr+ssh://bazaar.launchpad.net/%7Eabentley/bzr/1.9-launchpad/ as a Baz1 branch?
[07:11] <poolie> abentley: it tends to treat anything it doesn't understand as a Baz1 branch
[07:12] <poolie> i would guess that you've hit 288751 and therefore lp is not republishing it over bzr+ssh
[07:12] <poolie> oh
[07:12] <poolie> in fact, that's the simpler answer, it probably just can't ssh to launchpad
[07:12] <poolie> you need an http url
[07:12] <abentley> poolie: I merged something via SSH yesterday evening.
[07:13] <abentley> poolie: We use PQM with the launchpad codebase and that's confidential, so we use SSH for it.
[07:13] <poolie> ok
[07:13] <poolie> nevermind that then, though i thought it used to fail
[07:15] <spiv> abentley: because it's not a branch? https://code.edge.launchpad.net/~abentley/bzr/1.9-launchpad/
[07:15] <poolie> i can't access it over ssh eithre
[07:16] <spiv> Random guess: you uploaded in 1.9 format, but Launchpad doesn't understand 1.9 yet.
[07:17] <abentley> spiv: bzr info reports "Standalone branch (format: 1.6)"
[07:19] <poolie> abentley: so then i'd come back to my statement that it's affected by 288751
[07:19] <spiv> Random and wrong guess :)
[07:20] <lifeless> poolie:
[07:20] <lifeless>             # Performance with commit was profiled extensively, and it found that
[07:20] <poolie> i pasted a reproduction sample to that bug btw
[07:20] <lifeless>             # using the keys of the Inventory._byid was faster at the time. We
[07:20] <lifeless>             # want to move away from doing this, but until careful profiling
[07:20] <lifeless>             # is done, we're preserving the old behaviour.
[07:20] <lifeless>             # <lifeless, poolie>
[07:20] <lifeless> abentley: if it can't access the branch it will fall back to considering it a baz branch, which is not as probable
[07:21] <poolie> i'd say "using the keys ... (rather than eg building a set from the key iterator)"
[07:21] <poolie> i think you need to be a bit specific
[07:21] <poolie> otherwise it's like the billboards in qld saying "motorcyclists beware"
[07:21] <poolie> beware what, bats?
[07:22] <poolie> i was also thinking that it might have been better to do a getattr() rather than isinstance
[07:22] <poolie> it's more to the point of what we're trying to switch on
[07:22] <abentley> poolie: That only happens on autopack, but perhaps the mirroring process is autopacking.  That would be #280595 actually.
[07:23] <poolie> i posted a reproduction example
[07:23] <poolie> it may be on the wrong bug strictly speaking
[07:23] <abentley> lifeless: So it looks like the failure is because of a problem mirroring it.
[07:23]  * abentley sells all his computers and buys a spaghetti farm.
[07:29]  * fullermd will show his support by buying bulk spaghetti.
[07:41] <igc> night all
[08:20] <poolie> abentley: i have some ideas on 288751, nothing really conclusive yet
[08:20] <poolie> there is a check Packer._check_references that's meant to stop this but does not
[08:21] <lifeless> (Pdb) self.source.get_inventory('sp1r-monty@donna.mysql.com-20000829163832-06287')['sp1f-bk.txt-20000829134525-trpy4oecjn4oeshxkcg357zy4b2sisz4']
[08:21] <lifeless> InventoryFile('sp1f-bk.txt-20000829134525-trpy4oecjn4oeshxkcg357zy4b2sisz4', 'bk.txt', parent_id='sp1d-docs-ncsbsqrhxzflos6d2mrwgql4b7a7gacv', sha1='b5a47ca433f25aac932844515415ef43209ae017', len=3087, revision=sp1r-monty@donna.mysql.com-20000829163832-06287)
[08:21] <lifeless> (Pdb) self.target.get_inventory('sp1r-monty@donna.mysql.com-20000829163832-06287')['sp1f-bk.txt-20000829134525-trpy4oecjn4oeshxkcg357zy4b2sisz4']
[08:21] <lifeless> *** KeyError: 'sp1f-bk.txt-20000829134525-trpy4oecjn4oeshxkcg357zy4b2sisz4'
[09:47] <lifeless> seems to be scaling well:
[09:47] <lifeless> Commits: 1665
[09:47] <lifeless>                       Raw    %    Compressed    %  Objects
[09:47] <lifeless> Revisions:       6202 KiB   0%      1921 KiB   5%     1665
[09:47] <lifeless> Inventories:    27210 KiB   1%     14446 KiB  43%    29953
[09:47] <lifeless> Texts:        1520391 KiB  97%     16477 KiB  50%    11401
[09:48] <lifeless> Signatures:         0 KiB   0%         0 KiB   0%        0
[09:48] <lifeless> Total:        1553804 KiB 100%     32844 KiB 100%    43019
[09:53] <jelmer> looks promising
[09:53] <lifeless> the compressed size inventories are still just 'gzip' rather than deltas
[09:54] <lifeless> which is why it is ~50% smaller and thats all ;)
[09:55] <fullermd> Do you have a feel for how much difference there is to be made there?  'nother factor or 2, or 10?
[09:55] <lifeless> well
[09:55] <lifeless> we write ~20 nodes per commit
[09:56] <lifeless> of those, I guess its one leaf per changed inventory entry at worst
[09:56] <lifeless> and a leaf is quite compressible - its 4K of line orientated binary
[09:56] <lifeless> foo\x00bar\nquux\x00gam\n
[09:58] <lifeless> so, if we change say 200 bytes per 4K page, thats say 300 bytes with headers as a delta, or 150/200 as a gzip delta
[09:58] <lifeless> down from 2K
[09:58] <lifeless> so yeah, 5% of repo size compressed would be worth aiming for
[09:59] <fullermd> Awesome.
[09:59] <fullermd> (seeing the inventories compress to just barely smaller than the texts offended my intuition of what relative magnitudes should be.  Made me wonder if my intuition was completely cracked.)
[10:03] <lifeless> seeing it at 96% offended me
[10:04] <fullermd> Well, inventories are important; why shouldn't they get plenty of bytes!
[10:05] <asabil> hi all
[10:05] <jelmer> hey asabil
[10:07] <asabil> did anyone write a plugin to submit merge requests directly to bundle buggy ?
[10:11] <jelmer> asabil: how do you mean? Afaik bundle buggy only accepts merge requests via the mailing list
[10:12] <asabil> I would like to make my team mate use bundlebuggy
[10:12] <fullermd> Well, one could setup BB with a direct mail address, and just make send default to that address.
[10:12] <asabil> but getting them to use a mailing list, and setting their mails would be a big hassle
[10:12] <fullermd> I don't remember if there's already support for setting a default send address or not; that make take a little plugin-fu.
[10:13] <jelmer> yeah, you can set a default send address
[10:13] <jelmer> child_submit_to =
[10:13] <LarstiQ> asabil: they can use `bzr send`
[10:13] <asabil> I am thinking about exposing some rpc over http, and add a bzr command to directly submit a merge request
[10:14] <asabil> yes, but they need to setup a mail program I guess ?
[10:14] <fullermd> I thought send could just spawn off an editor and `sendmail`-submit it itself.
[10:15] <fullermd> (of course, that assumes the rest of the system is properly setup for mailing, which I always assume but may not be valid in your neighborhood)
[10:15] <asabil> I don't think that's the case unfortunately
[10:15] <LarstiQ> it can also use smtplib iirc, useful for hosts without an mta
[10:17] <asabil> so basically I would just setup bundle buggy, and create an email address for it
[10:17] <asabil> and then configure bzr send to use smtplib ?
[10:17] <fullermd> Yah.  [AFAIK] it just gets email; seems to usually be done by subscribing it to a ML, but could just as easily be mail sent right at it.
[10:19] <lifeless> asabil: yah
[10:19] <lifeless> asabil: I'm sure more can be done, but thats the current state-of-play
[10:19] <asabil> okidoki, thanks a lot
[10:20] <asabil> one last question, how do I configure bzr send to use smtplib ?
[10:22] <jszakmeister> jelmer: Thanks for taking care of that corruption bug.
[10:23] <jszakmeister> Looks like there's one more with the branch nick stuff... but it sounded like 1.9.1 was going to have a fix for that.
[10:23] <jelmer> jszakmeister: yep
[10:24] <lifeless> asabil: its in the configuration help
[10:25] <asabil> bzr help send | grep smtp gives nothing
[10:25] <strk> ERROR: Your shelved patch no longer applies cleanly to the working tree!
[10:25] <strk> now what ?
[10:25] <strk> I shelved changes in a brach because I selectively patched trunk with some of the changed
[10:25] <strk> then merged the updated trunk into the branch again
[10:25] <strk> and now was willing to unshelv, expecting the already-found patches to become non-changes
[10:25] <strk> but I get that error above...
[10:26] <lifeless> strk: that version of shelf works with simple patch(1) behavour
[10:26] <lifeless> strk: just supply --force
[10:27] <lifeless> bzr's next release has a better shelve that should do what you were expecting
[10:28] <strk> ok, --force did it, produced some .rej but I'm fine with them, seem to be the patches I didn't want to apply anymore cause already applied in trunk
[10:28] <strk> how to clean the shelf now ?
[10:28] <lifeless> bzr shelf list
[10:28] <lifeless> bzr shelf delete (thing to delete)
[10:28] <strk> great, thanks
[10:31] <luks> asabil: bzr help configuration
[10:34] <asabil> thanks
[13:11] <rocky> any here use cmd-line bzr with emacs? trying to get sensible status info to show up but it seems to be killing emacs
[13:42] <abentley> asabil: In terms of receiving patches, bundle buggy just scans a directory containing messages.  Whether it's personal mail or from a mailing list shouldn't matter.
[13:44] <abentley> asabil: bzr help send describes the "editor" mail client, which uses smtplib.
[13:47] <asabil> okidoki, thanks for the input abentley
[14:06] <strk> how can I compare two branches ?
[14:07] <strk> the ideal outpu for me would be the same you'd get with 'status' (a summary of diffs) and the possibility to know more about something
[14:11] <Odd_Bloke> strk: Try using "-r branch:<PATH>".
[14:11] <strk> to status ?
[14:12] <strk> bzr: ERROR: bzrlib.errors.ReadOnlyError: A write attempt was made in a read only transaction on KnitPackRepository('file:///home/src/gnash/avm2/.bzr/repository/')
[14:12] <strk> write ?! it was bzr status -r branch:../bzr/trunk/
[14:13] <Odd_Bloke> strk: That sounds wrong.  What's in ~/.bzr.log?
[14:13] <luks> that should be fixed in recent bzr
[14:13] <fullermd> That's a long-standing bug.
[14:14] <Odd_Bloke> Ah, OK, I'd never seen it before.
[14:14] <luks> 1.8 probably
[14:15] <strk> this is Bazaar (bzr) 1.3.1
[14:15] <fullermd> https://bugs.launchpad.net/bzr/+bug/144421
[14:30] <strk> uhm... diff branchA/file1 branchB/file1 # no diffs
[14:30] <strk> branchA$ merge ../branchB # nothing to do
[14:31] <strk> branchB$ merge ../branchA # conflicts in file1
[14:31] <strk> any idea ?
[14:31] <strk> seem the real difference in the conflict marker is just the amount of spaces used for indentation
[14:32] <strk> questions are: 1) why 'diff' doesn't care ? 2) why merge in the two directions is different in catching that ?
[14:33] <strk> uhm, on a closer look, there's really NO difference in the two files, so diff(1) is right
[14:33] <strk> why does merge gets that conflict then ?
[14:37] <Odd_Bloke> Hmm, I seem to have accidentally Planet Bazaar.
[14:37] <Odd_Bloke> The whole planet.
[14:37] <fullermd> "This sentence no verb"
[14:38] <Odd_Bloke> (http://img165.imageshack.us/img165/189/1218062796760xd1.jpg)
[14:40] <dobey> uhm
[14:40] <dobey> riiiiiight
[14:41] <strk> lol
[14:42] <strk> Odd_Bloke: I'm laughing as a kid
[14:42] <strk> silly stuff
[15:01] <Ursinha> Odd_Bloke, LOL
[15:14] <rocky> jelmer: hey... when i do a push of a revision back to a svn branch to a repo with 75k revs it does the "determining revisions" dance like 3 times ... each time it takes about 4sec or so
[15:19] <_tsatbic_> Hi there ...
[15:20] <_tsatbic_> I've got a type in a commit's message, is it possible to rename the message even after several other commits have been made?
[15:20] <beuno> _tsatbic_, no, commits are immutabl
[15:21] <_tsatbic_> thanks
[16:18] <gary_poster> Hello.  Does anyone happen to have a buildbot hook for bzr (i.e., one that pings a buildbot master when a change is commited) that they would be willing to share?  Neither Google nor buildbot.net seem to show such a beast.
[16:19] <jelmer> gary_poster: Hi
[16:19] <gary_poster> hi jelmer
[16:20] <jelmer> Afaik there isn't anything like that yet
[16:20] <gary_poster> jelmer: ok thanks.  here I go then, I guess ;-)
[19:08] <eyda|mon> is there anyway to get bzr to show me the relative paths of files when doing bzr st instead of the full path?
[19:09] <eyda|mon> (a la git)
[19:20] <rockstar> abentley, is a revid usually just <email-address>-<timestamp>-<randomness> ?
[19:21] <beuno> rockstar, I think there's a sha1 hash in there somehow
[19:21] <beuno> something related to the actual contents of the revid
[19:21] <abentley> rockstar: Yes, the revids bzr itself generates are that.
[19:21] <beuno> but that may be somewhere else
[19:21] <abentley> beuno: There is nothing related to the actual contents of the committed tree in the revid.
[19:21] <abentley> beuno: You may be thinking of revision testaments, which are used with GPG signing.
[19:22] <rockstar> abentley, great.  That makes my job so much easier.
[19:22] <beuno> abentley, I'm actually thinking of a hash that makes sure that the revision hasn't been changed
[19:22]  * rockstar prefers that Old Testaments.  No GPG sig, but lots of funny stories.
[19:23] <abentley> rockstar: importers like bzr-svn often do not follow bzr's practice.  The only requirement is that they be random.
[19:23] <abentley> beuno: That's what testaments are for.  There's also a SHA hash in the revision XML.
[19:23] <abentley> but it's a bad idea, and not reliable.
[19:24] <beuno> abentley, the sha is what I was thinking of
[19:24] <beuno> why is it not reliable?
[19:24] <beuno> because of upgrades and such?
[19:25] <abentley> Yes, format upgrades will update the inventory XML without necessarily updating the SHA1.
[19:25] <beuno> gotcha, thanks for the explanation\
[19:26] <abentley> beuno: Or at least that was the case.  It should be fixed in recent bzrs, but old revisions won't be fixed.
[19:32] <abentley> lifeless: ping
[19:51] <lifeless> abentley: just waking up
[19:51] <lifeless> abentley: what can I do for you?
[19:52] <abentley> lifeless: What causes PQM to die on "not enough arguments for format string"?
[19:52] <lifeless> I think thats a new one
[19:55] <abentley> lifeless: I'm not sure if you're aware, but bzr 1.9 has API changes that are incompatible with loom trunk.  Launchpad wants to use bzr 1.9.  So I'm trying to land lp:~abentley/bzr-loom/stuff on bzr+ssh://bazaar.launchpad.net/~Elaunchpad-pqm/bzr-loom/trunk
[19:56] <abentley> lifeless: But it died with the aforementioned error.
[19:56] <abentley> lifeless: A silent failure, not an email failure.
[19:57] <rockstar> How do I get the config of a branch, if I have a setting for a branch in my bazaar.conf
[19:58] <jelmer> rockstar: you mean something like Branch.open(url).get_config() ?
[19:58] <rockstar> jelmer, does that return a bzrlib.config.Config object?
[19:59] <jelmer> It returns a BranchConfig object, but that's based on a Config object IIUC
[19:59] <rockstar> I thought I wanted BzrDirConfig, but BranchConfig looks better.
[19:59] <jelmer> BranchConfig reads from .bzr/branch/branch.conf, locations.conf and bazaar.conf (not sure in what order)
[20:01] <lifeless>   File "/home/pqm/pqm/pqm/__init__.py", line 534, in do_merge
[20:01] <lifeless>     self.log_with_status(logger, merge_line)
[20:01] <lifeless>   File "/home/pqm/pqm/pqm/__init__.py", line 428, in log_with_status
[20:01] <lifeless>     self.branch_spec_handler.status.line(message % args)
[20:01] <lifeless> TypeError: not enough arguments for format string
[20:01] <lifeless> abentley: its a bug; let me have brekkie and I'll try to track it down
[20:04] <abentley> lifeless: thank you.
[20:33] <jfroy|work> :sigh: loggerhead has almost no documentation :|
[20:33] <evarlast> it has source!
[20:33] <evarlast> python is very readable, that is how I got lh running :)
[20:33] <jfroy|work> I know, I know.
[20:33] <jfroy|work> But I always look for the easy way out.
[20:34] <jfroy|work> *easy way out first :p
[20:34] <jfroy|work> Seems odd that they are pushing to move to serve-branches
[20:34] <NfNit|oop> Hmm, is there not an option to create a branch w/o a working copy?
[20:34] <jfroy|work> It seems a lot less flexible than the config file.
[20:34] <dobey> NfNit|oop: bzr branch lp:foo bar
[20:34] <dobey> or you mean create a branch on the server?
[20:35] <NfNit|oop> a branch without a checkout.
[20:35] <NfNit|oop> it's ok, I'll just branch then remove-tree
[20:42] <verterok> NfNit|oop: if you have repository created with --no-trees, the branch is created without tree
[20:43] <jfroy|work> bah, I can't make heads or tails of how to use --user-dirs with an Apache proxy
[20:44] <NfNit|oop> verterok: right, I'm in a shared repo, but I've got trees for some branches, and wanted to create a branch as a sortof temporary tag to compare against some other revision.   Didn't really need to create a working tree for it.
[20:45] <verterok> NfNit|oop: I don't think they can be mixed :/
[20:45] <luks> NfNit|oop: you can compare against remote branches
[20:46] <NfNit|oop> verterok: Well, I just did `bzr remove-tree`... so I hope they can be mixed. :p
[20:46] <NfNit|oop> luks: Yeah, but that's slower than doing it locally. :p
[20:46] <verterok> NfNit|oop: sure, but you must do a remove-tree :)
[20:47] <NfNit|oop> verterok: mkay, that's fine. :)   I was just surprised at its absence.
[20:47] <verterok> NfNit|oop: indeed
[20:54] <abentley> NfNit|oop: If you really want to, you can create the branch over bzr+ssh (or sftp, ftp whatever your workstation has running).  Branches created over remote protocols don't get working trees.
[21:05] <lifeless> jfroy|work: its less flexible in some ways, but its a lot easier for most folk to deploy
[21:05] <lifeless> jfroy|work: the user-dirs thing is instead of using apaches' userdir mapping facility-> if you want host/~foo to be served by loggerhead
[21:06] <lifeless> verterok: they should be mxable
[21:06] <BrentH> Hi, I'm having problems with the initial brnach setup of Bazaar. Any bored volunteers? <g>
[21:06] <BrentH> er branch
[21:06] <lifeless> BrentH: sure, whats up
[21:06] <BrentH> well, I'll give you the mini-background.
[21:07] <BrentH> I've setup a project on Launchpad, and put ateam on the project...the problem is getting the initial code onto Launchpad
[21:08] <lifeless> BrentH: what vcs is it in at the moment?
[21:08] <BrentH> I'm an IT person, but Bazaar and Launchpad have made me feel really dumb. lol
[21:08] <BrentH> it's not - brand new.
[21:08] <lifeless> assume that its at /src/foo
[21:08] <lifeless> cd /src/foo
[21:08] <lifeless> bzr init
[21:08] <lifeless> bzr add
[21:08] <lifeless> bzr commit
[21:09] <lifeless> bzr push lp:~$TEAM/$PROJECT/trunk
[21:09] <BrentH> I should clarify - it didn't exist before...right now the initial code is only two files. The code is on a Win installation of Bazaar.
[21:09] <BrentH> when I push it, I'm getting "error not a branch"
[21:09] <lifeless> BrentH: have you run the commands I listed above?
[21:09] <BrentH> yes. all were successful until the push
[21:10] <lifeless> are you running push from within the directory?
[21:10] <verterok> lifeless: yes, it's just I expressed it wrong (choosed poorly my words), what I meant was that a share repo can't create branches without tree if it's not a --no-trees repo.
[21:10] <lifeless> abentley: I see the issue with pqm I think; the branch has % in it
[21:11] <BrentH> ok, 1st problem solved...maybe
[21:11] <BrentH> here's the thing...
[21:12] <BrentH> I desire a directory under foo called new.   So foo/new...
[21:12] <abentley> lifeless: Heh.
[21:12] <lifeless>  File "/home/pqm/pqm/pqm/__init__.py", line 787, in run
[21:12] <lifeless>     line='merge %s %s' % (self.from_branch, self.to_branch))
[21:12] <lifeless>   File "/home/pqm/pqm/pqm/__init__.py", line 534, in do_merge
[21:12] <lifeless>     self.log_with_status(logger, merge_line)
[21:12] <lifeless>   File "/home/pqm/pqm/pqm/__init__.py", line 428, in log_with_status
[21:12] <lifeless>     self.branch_spec_handler.status.line(message % args)
[21:12] <BrentH> does it make a difference where I eventually deploy it? (I want to deploy to a virtual website dir)
[21:13] <lifeless> BrentH: 'mkdir new'
[21:13] <lifeless> BrentH: 'bzr add'
[21:13] <lifeless> BrentH: 'bzr commit'
[21:13] <abentley> lifeless: Looks like some pretty intentional string interpolation to me ;-)
[21:13] <BrentH> I just now realized I had to commit from within "new"
[21:13] <BrentH> duh
[21:13] <lifeless> abentley: I'm only guessing at this point, but it seems plausible
[21:14] <BrentH> but it gave me an auth error
[21:14] <BrentH> ...on the password error
[21:14] <BrentH> is it the same password as the private key?
[21:15] <lifeless> BrentH: on push?
[21:15] <BrentH> lifeless:yes
[21:15] <lifeless> yes, it's your private key passphrase
[21:16] <BrentH> lemme try again...
[21:17] <BrentH> bad auth type again
[21:18] <lifeless> can you show the exact error please
[21:18] <lifeless> if its more than a couple of lines paste it on http://paste.ubuntu.com/
[21:18] <BrentH> why do I sometimes need to use my screen name, and other times my full name?
[21:18] <lifeless> for launchpad urls, its always the display name
[21:19] <abentley> lifeless: I would interpret "display name" as "Aaron Bentley"
[21:19] <abentley> lifeless: I've re-submitted without the %.
[21:20] <lifeless> oh
[21:20] <lifeless> BrentH: the short-name-with-no-spaces
[21:20] <BrentH> first-last
[21:20] <lifeless> abentley: thanks, I'll file a bug on pqm re this
[21:20] <BrentH> 1sec
[21:22] <BrentH> when I do the commit, it tries to use first-last instead of BrentH (scrn name)
[21:22] <BrentH> don't know if that is the issue or not...
[21:23] <BrentH> I'm using it to teach a class project, and thought this might be a cool way to do it
[21:23] <lifeless> BrentH: the commits record email addresses as a globally unique committer identifier
[21:23] <lifeless> the BrentH for url's on launchpad is just what launchpad has chosen to use as account names.
[21:24] <BrentH> I set my email addy in cmd pmt
[21:25] <BrentH> BrentH was the screen name I chose on launchpad
[21:26] <BrentH> guess that doesn't matter
[21:27] <BrentH> question: will this be too cpmplex for community college students to use for a one-off 1 month project?
[21:27] <BrentH> yeesh...sorry about that
[21:27] <lifeless> BrentH: not your fault ;)
[21:27] <lifeless> BrentH: it should be fine IMO, there are only a few steps to basic usage
[21:28] <BrentH> ok. should I email you acct un/pw to take a look?
[21:29] <lifeless> BrentH: why? (I'm not sure what you're asking)
[21:29] <BrentH> wasn't sure what be the easiest to troubleshoot
[21:29] <BrentH> er what would be...
[21:30] <BrentH> drat....brb
[21:33] <lifeless> BrentH: is there still something wrong though?
[21:42] <lifeless> bug 279381 is the one got you abentley
[21:42] <abentley> Oh, did ubotu go away?
[21:43] <lifeless> netsplit
[21:43] <lifeless> 10K users gone :P
[21:44] <abentley> lifeless: readdir?  Colour me confused.
[21:51] <lifeless> abentley: https://bugs.edge.launchpad.net/pqm/+bug/297381
[21:51] <lifeless> transient dyslexic chaos reigned
[22:12] <BrentHat> lifeless: hi
[22:14] <NfNit|oop> BrentHat: hi
[22:14] <BrentHat> ok, the distractions are gone. :)
[22:15] <lifeless> BrentHat: hi
[22:15] <BrentHat> I should have a block of time now if you can help
[22:15] <lifeless> BrentHat: are you still having some problem?
[22:15] <BrentHat> lifeless: yes, at the auth, even though I think it is the correct pw
[22:16] <lifeless> BrentHat: can you paste the exact thing you see please
[22:17] <BrentHat> C:\Documents and Settings\Brent\My Documents\windsortoastmasters.org\new>bzr pus
[22:17] <BrentHat> h lp:~windsortoastmasters/windsortoastmasters/website
[22:17] <BrentHat> Connected (version 2.0, client Twisted)
[22:17] <BrentHat> SSH brent-hathaway@bazaar.launchpad.net password:
[22:17] <BrentHat> Authentication type (password) not permitted.
[22:17] <BrentHat> bzr: ERROR: Connection error: Unable to authenticate to SSH host as brent-hathaw
[22:17] <BrentHat> ay@bazaar.launchpad.net Bad authentication type (allowed_types=['publickey'])
[22:17] <lifeless> BrentHat: bzr doesn't know/have access to your private key
[22:17] <lifeless> BrentHat: have you setup a private key and uploaded it to launchpad?
[22:18] <lifeless> jml: also, why don't we support the users passphrase on b.l.n ?
[22:18] <BrentHat> ok, makes sense. I uploaded a key to launchpad
[22:18] <jml> lifeless: historical reasons.
[22:19] <jml> lifeless: spiv may have a better notion of the history.
[22:19] <BrentHat> lifeless: so does that mean each user has to work at a dedicated location, because of the key?
[22:19] <lifeless> jml: I was there :) I don't think we ever had a good reason, just that we were not going to use the system db.
[22:19] <lifeless> BrentHat: no, they can carry the key around with them
[22:20] <lifeless> BrentHat: what you upload to launchpad was half the key
[22:20] <jml> lifeless: then why ask me.
[22:20] <BrentHat> lifeless: ok.
[22:20] <lifeless> jml: because its your baby *now* :)
[22:20] <lifeless> jml: and if you think its reasonable, I'll file a bug
[22:20] <lifeless> BrentHat: its like a lock+key; the 'public key' is the lock, the 'private key' is the bit you carry around yourself and never give to someone else.
[22:21] <NfNitLoop> BrentHat: Or, they can work wherever, then pull & push when they get to wherever their key is.
[22:21] <BrentHat> I see my public key has been added at https://launchpad.net/~brent-hathaway/+editsshkeys
[22:21] <BrentHat> so how do I assoc. the private key with bazaar?
[22:22] <lifeless> BrentHat: I don't know windows well enough; sorry
[22:22] <lifeless> one of the folk that use windows should be around in about 40 minutes
[22:22] <lifeless> or it might be documented in the user guide
[22:22] <BrentHat> there also aren't any .config files either tat I could find
[22:22] <jml> lifeless: it's semi-reasonable, it won't get done any time soon
[22:23]  * jml on a call that's demanding concentration.
[22:23] <BrentHat> I'll try rtfm again then, lol.
[22:24] <BrentHat> ok, since I have a bunch of "wrong" branches made at launchpad, is there a way to delete them at the site list?
[22:25] <eyda|mon> is there anyway to get bzr to show me the relative paths of files when doing bzr st instead of the full path?
[22:26] <lifeless> eyda|mon: not yet
[22:26] <lifeless> BrentHat: go to the branch web page; there is a delete button there
[22:28] <BrentHat> lifeless: it says the branch hasn't been imported yet. I don't see any button, but no biggie.
[22:34] <BrentHat> lifeless: yay, found the conf files
[22:35] <BrentHat> lifeless: there is a file called: ssh_host_keys   do I replace that file with my private key, and rename it to that?
[22:35] <lifeless> BrentHat: no
[22:36] <lifeless> BrentHat: you should put your private key in that directory
[22:36] <BrentHat> lifeless: public, too?
[22:36] <lifeless> doesn't matter
[22:38] <BrentHat> grrr, no dice - same error
[22:39] <lifeless> what file name does your private key have?
[22:39] <BrentHat> privatekey.ppk
[22:40] <poolie> hello lifeless, all
[22:40] <BrentHat> hi poolie
[22:41] <BrentHat> lifeless - should I recreate another set of keys?
[22:41] <lifeless> BrentHat: no
[22:41] <lifeless> BrentHat: try renaming the file to 'id_dsa'
[22:42] <lifeless> hi poolie
[22:42] <BrentHat> k
[22:42] <lifeless> poolie: BrentHat here has some issues with lp auth on windows; is jam there ?
[22:43] <BrentHat> lifeless: same
[22:43] <BrentHat> thanks for the help, btw
[22:43] <eydaimon> lifeless: plans for it though?
[22:44] <eydaimon> lifeless: I end up doing bzr st; bzr diff ... then the path is all wrong :/
[22:44] <eydaimon> lifeless: and I do that a lot
[22:44] <lifeless> eydaimon: yes, plans for it
[22:44] <eydaimon> good :)
[22:44] <lifeless> eydaimon: 'bzr root' may help
[22:44] <eydaimon> hmm, maybe. I'll keep that in mind. thanks
[22:49] <BrentHat> authentication.conf:
[22:49] <BrentHat> [Launchpad]
[22:49] <BrentHat> host = .launchpad.net
[22:49] <BrentHat> scheme = ssh
[22:49] <BrentHat> user = brent-hathaway
[22:56] <jfroy|work> is there a way to show a branch's public_url in Loggerhead?
[22:57] <jfroy|work> There's no indication, as far as I can tell, to let people know from a loggerhead page how to branch the branch.
[22:57] <jfroy|work> how to branch -> what URL to use to branch or checkout the branch
[22:57] <beuno> jfroy|work, no, but if you file a bug, that can happen
[22:57] <beuno> patches are also welcome!
[22:58] <jfroy|work> Sounds good
[22:59] <poolie> abentley: are you still around?
[22:59] <poolie> want to talk about bug 288751
[23:00] <ja1> BrentHat: do you have Pageant running?
[23:00] <lifeless> BrentHat: rename the id_dsa file back to what you had it called before
[23:00] <BrentHat> no, running only Tortoise Bazaar....
[23:01] <jam> BrentHat: ok, you generated your .ppk file using putty, though right?
[23:01] <jam> well, "puttygen"
[23:01] <BrentHat> ok, renamed
[23:01] <BrentHat> yes, thru putty
[23:01] <jam> I'll give the quick rundown
[23:01] <jam> if you load your .ppk file into puttygen
[23:02] <jam> in the top box it has: "Public key for pasting into OpenSSH authorized_keys file"
[23:02] <jam> which has some text
[23:02] <jam> starting with "ssh-rsa"
[23:02] <poolie> lifeless: anyhow let's talk here
[23:02] <jam> you want to select that string, and copy and paste that into launchpad
[23:02] <poolie> was just going to say i had some progress towards 288751, i wondered if aaron would come back to it but i guess not
[23:02] <jam> BrentHat:  http://launchpad.net/+me/+editsshkeys
[23:03] <poolie> i think you read my incremental patches?
[23:03] <jam> https://edge.launchpad.net/people/+me/+editsshkeys
[23:03] <jam> sorry
[23:03] <BrentHat> jam: yup
[23:03] <jam> ok, then once you have that uploaded
[23:03] <jam> you need to either run Pageant and load the key manually
[23:03] <jam> Start/Programs/Putty/Pageant
[23:04] <jam> to start it
[23:04] <jam> and then right-click and say "add key"
[23:04] <jam> browse for the .ppk
[23:04] <jam> add it
[23:04] <BrentHat> i did that b4 - uploaded the public
[23:04] <jam> Unfortunately, putty & pageant require you to add the keys manually on each boot
[23:04] <jam> You'll probably also want to set Pageant up to start automatically
[23:04] <jam> (I just copy the shortcut to Start/Programs/Startup)
[23:05] <jam> BrentHat: feel free to ask me to clarify any of the steps
[23:05] <BrentHat> ah, cool, 1 sec
[23:06] <jam> BrentHat: I think there is another way that you can do it, so that bzr & paramiko can find the key without you running pageant
[23:06] <jam> let me poke around for a sec
[23:06] <BrentHat> ok, in the meantime, I'll try the commit again.
[23:07] <jam> ok, if you load your key back into PuttyGen
[23:07] <BrentHat> er: I'll try the push again
[23:07] <poolie> [merge] NewPack constructor takes a PackCollection rather than a bunch of it's attributes <http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20081112091450.GA7227%40sourcefrog.net%3E>
[23:08] <BrentHat> Woo-hoo!!!! Auth successful!
[23:08] <jam> Under "Conversions/Export OpenSSH key"
[23:08] <jam> you can use that to create the "id_rsa" file
[23:08] <jam> and put it in $HOME
[23:08] <jam> which is typically
[23:08] <jam> Documents and Settings/<username>
[23:09] <jam> or Users/<username> (on Vista)
[23:09] <BrentHat> not seeing conversions/export
[23:09] <jam> BrentHat: In "PuTTYGen" ?
[23:09] <BrentHat> ohhhh lol
[23:09] <jam> In the menu, I have "File, Key, Conversions"
[23:10] <BrentHat> got it! <g>
[23:10] <BrentHat> I saved it in the 2.0 dir - with the other key - correct?
[23:11] <jam> Not in the 2.0 dir
[23:11] <jam> in "C:\Documents and Settings\<username>\id_rsa"
[23:11] <jam> as the full path to the file
[23:11] <BrentHat> k
[23:12] <BrentHat> ok, done - should I test, and if so....how? lol
[23:12] <BrentHat> yay, much happier now.
[23:15] <BrentHat> ah geez, I just noticed there's till an error:
[23:15] <arjenAU> poolie: morning - so you're in my town today?
[23:16] <BrentHat> C:\Documents and Settings\Brent\My Documents\windsortoastmasters.org\new>bzr pus
[23:16] <BrentHat> h lp:~windsortoastmasters/windsortoastmasters/website --use-existing-dir
[23:16] <BrentHat> Connected (version 2.0, client Twisted)
[23:16] <BrentHat> Authentication (publickey) successful!
[23:16] <BrentHat> Secsh channel 1 opened.
[23:16] <BrentHat> Using default stacking branch /~windsortoastmasters/windsortoastmasters/main at
[23:16] <BrentHat> bzr+ssh://bazaar.launchpad.net/%7Ewindsortoastmasters/windsortoastmasters/
[23:16] <BrentHat> Connected (version 2.0, client Twisted)
[23:16] <BrentHat> Authentication (publickey) successful!
[23:16] <BrentHat> Secsh channel 1 opened.
[23:16] <BrentHat> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~windsortoastmasters/w
[23:16] <BrentHat> indsortoastmasters/main/".
[23:17] <BrentHat> further proof I am *newbie clueless*
[23:20] <BrentHat> ok, so there is one bazaar branch listed as lp:~vcs-imports/windsortoastmasters/main and another listed as lp:~windsortoastmasters/windsortoastmasters/website
[23:21] <BrentHat> and a third with a series of lp:windsortoastmasters series: trunk
[23:21] <BrentHat> I'd like to do whatever is going to be the easiest, and I don't know which to delete from the site (although I do not see a delete button as lifeless had mentioned...drat)
[23:25] <BrentHat> thanks jam for the help so far!
[23:27] <jam> BrentHat: just a sec
[23:31] <arjenAU> poolie: blip
[23:39] <poolie> hello arjenAU
[23:40] <arjenAU> poolie: so, in my town today was that right?
[23:44] <poolie> yes, we are
[23:44] <poolie> we're in the city
[23:44] <poolie> would you like to meet, maybe for lunch?
[23:45] <arjenAU> poolie: pm
[23:49] <BrentHat> which timezone is everyone in?
[23:51] <arjenAU> GMT+10
[23:53] <BrentHat> I'm GMT -5
[23:55] <BrentHat> It's cool that people from this project hang out IRL