[02:41] <idnar> -r ancestor::submit..
[02:41] <idnar> there's something visually fun about that
[02:43] <lifeless> :)
[02:43] <lifeless> almost perl in its elegance :P
[02:44] <idnar> although I think I actually just want bzr missing
[02:44] <fullermd> It really needs a pair of top-aligned dots at the beginning though.  Isn't that in Unicode somewhere?
[02:45] <idnar> haha
[02:46] <idnar> ¨::..
[02:46] <idnar> hmm, no
[02:46] <idnar> ··::..
[02:47] <idnar> someone else can write the patch to add it to the revisionspec syntax :P
[02:47] <fullermd> Alternate interpretation: "ancestor::submit.." would be a good title for a prog metal album.
[02:51] <bairui> hey, guys... on evaluating my repository layout needs for website development, a question arose regarding releases. We have a staging area (called XPT) from which successfully (accepted) builds become releases. What is a better strategy (repository-wise) with dealing with these releases? Should I have a single XPT branch from the trunk (created either way back when or at the first release) and as new
[02:51] <bairui> releases come, just merge them into XPT and tag the successful ones?   Or...   Create a new branch for each release?
[02:51] <mwhudson> fullermd: i like "Alternate interpretation: ancestor::submit.." actually
[02:54] <lifeless> bairui: both are fine
[02:54] <bairui> cool
[02:54] <fullermd> mwhudson: Could be a totally genre crossover.  Tracks include "Criss-cross merging the streams" and "-rdate:All Our Yesterdays".
[02:54] <bairui> tagging it is then, methinks
[02:54] <bairui> thanks, lifeless
[02:55] <mwhudson> fullermd: i like "Alternate interpretation: ancestor::submit.." actually
[02:55] <mwhudson> bah!
[02:55] <mwhudson> fullermd: :-p
[02:55] <fullermd> Maybe I should take that back.  It almost makes me look like some kinda nerd.
[05:15] <james_w> poolie, hi, did you change the crontab on jubany to send to canonical-bazaar?
[05:21] <james_w> poolie, if you did, it's bouncing
[05:21] <james_w> in fact, that's not conditional :-)
[05:21] <james_w> it is bouncing
[05:22] <james_w> "Relay access denied" from smtp.external
[06:07] <poolie> hi james_w; i did
[06:07] <poolie> shall i set it back to you?
[06:17] <poolie> i've donethat
[07:06] <vila> hi all !
[07:06] <vila> good evening poolie
[07:07] <vila> compiz: I don't what you're doing but t 2.5GB (3.7GB virtual), you're overdoing it
[07:07] <vila> I almost rebooted...
[07:09] <blackarchon> this wouldn't happen with KDE!
[07:10] <vila> :)
[07:10] <vila> famous last words ?
[07:11] <blackarchon> I call it the eternal truth!
[07:13] <AfC> KDE or GNOME3, works for me!
[07:13] <AfC> [I can't believe I just wrote that]
[07:15]  * gour stays with xfce
[07:16] <bairui> i just switched to xfce about a week or so ago
[07:16] <bairui> from awesome. I *liked* awesome... I just wanted to play with something shiny for a while.
[07:16] <jam> vila: unity --replace &;  Should fix it, I think.
[07:17] <jam> There are some memory leaks in compiz wrt app indicators
[07:17] <jam> bug #779717
[07:18] <gour> i'm just not sure i will be able to stay on freebsd seeing that DEs are becoming more & more linux-only
[07:18] <vila> jam: yeah, thanks, I've seen some earlier bugs and thought the issue was fixed...
[07:19] <vila> fullermd: ^ Imminent death of FreeBSD predicted ;)
[07:20] <vila> vila: stop it ! Enough noise already !
[07:20] <AfC> Replace Unity. Yes, that's an excellent idea.
[07:29] <zzz> Hi, is there any possibility to see the actual branches? Like git branch -a in git?
[07:30] <blackarchon> 'bzr branches' has just made it into trunk
[07:34] <vila> zzz: a bit more context may help answer your question
[07:34] <vila> zzz: branches map to directories by default
[07:36] <AfC> zzz: ie http://research.operationaldynamics.com/bzr/quill/ ; lots of Branches there; 'mainline' only one with a Working Tree in it.
[07:37] <gour> i like that hg doen't have 'main' line...but, well
[07:38] <gour> for me, greater problem is lp' lack of wiki & private repos (in comparison with bb)
[07:42] <vila> jelmer_: what's the status of bzr-svn with respect to bzr-2.4.0 ?
[07:42] <vila> jelmer_: no pressure intended et al, but, you know.. ;)
[07:50] <vila> jam: regarding bug #614713, you said 'reasonable to backport', how far should I target ? 2.0 ?
[08:27] <poolie> hi there vila, all
[08:28] <vila> jml: I've got a magic guesser but you won't be able to use it :) Good one ! (Joke aside, kudos for the neat pkgme-binary, that's the kind of magic I *love* !)
[08:28] <vila> hey poolie !
[08:30] <vila> poolie: I've run selftest -Econfig_stats | subunit-sum on bzr.dev.revnos[5982:6082] and your fdatasync raise interesting numbers
[08:30] <vila> s/sync/& stuff/
[08:30] <poolie> oh?
[08:31] <vila> since you cache the config we get a preview of what read/write once will achieve
[08:48] <vila> https://launchpad.net/bzr/+milestones
[08:48] <vila> list all the planned dates for the releases
[09:06] <jml> vila: thanks :)
[09:50] <poolie> jam, hi?
[09:50] <poolie> jml, hi
[09:52] <vila> Riddell: hey PP, can I ask for some reviews ? :D
[10:53] <vila> jam, jelmer, Riddell : ping
[10:53] <jelmer> vila!
[10:54] <vila> ha ! Someone ! :D
[10:54] <jelmer> uhoh, what did I volunteer for ? ;-)
[10:54] <vila> jelmer: how's going :)
[10:54] <vila> oh, nothing, just wanted to know are you were going on with bzr-svn and if you needed help there
[10:56] <jelmer> vila: alright so far, still working on tests
[10:56] <vila> \\o o// rock&roll !
[11:05] <jelmer> vila: :)
[11:07] <vila> If our beloved PP can shime in now... that would be so great ;)
[11:57] <vila> wow, almost felt into the 'pqm-is-broken' trap :) The progress does *not* work for 2.0 ...
[11:57] <vila> ohhh, and we run the test suite twice with [ascii] :)
[13:02] <vila> Riddell: Ping
[13:32] <briandealwis> jelmer: I have a local git repo.  With latest bzr.dev and bzr-git at tip, should I be able to use file:.../git-repo,branch=XXX to reference a particular git branch?
[13:32] <jelmer> briandealwis, yep
[13:33] <briandealwis> jelmer: I'm getting an error: "Not a branch: "/Users/bsd/Manumitting/Projects/e4/platform-ui-git": location is a repository.
[13:34] <briandealwis> jelmer: but branching without ",branch=XXX" works fine
[13:34] <jelmer> briandealwis, what does "BZR_DISABLE_PLUGINS=bzrtools bzr branches ../git-repo" say?
[13:36] <briandealwis> jelmer: no change
[13:37] <briandealwis> jelmer: sorry — I didn't fully read your message
[13:37] <briandealwis> jelmer: it just spits out 'master'
[13:38] <jelmer> briandealwis: does that match the output of "git branch" in that repo?
[13:38] <briandealwis> jelmer: yes — good catch.  Sorry for the confusion.
[13:39] <briandealwis> jelmer: do you think specifying 'origin/XXX' will work?  (There's a pile of origin/ branches listed with 'git branch -a'
[13:40] <jelmer> briandealwis, that should work, but you have to urlescape the / to prevent it from being interpreted as a path separator
[13:40] <jelmer> ,branch=origin%2Ffoo
[13:40] <jelmer> I realize that's not a very nice syntax, but it's a start
[13:40] <briandealwis> it makes complete sense
[13:41] <briandealwis> …though unfortunately origin%2Fxxx doesn't work — same location-is-a-repository
[13:42] <jelmer> actually, it needs to be
[13:42] <jelmer> ,ref=refs%2Fremotes%2Forigin%2Ffoo
[13:44] <briandealwis> nifty — but now I get a "ValueError: unable to map ref refs/remotes/origin/R4_development back to branch name".  Strangely there's only HEAD under .git/refs/remotes/origin/
[13:44] <briandealwis> I wodner where 'git branch -a' gets its info from then?
[13:45] <jelmer> briandealwis: ah, argh
[13:45] <jelmer> briandealwis: yeah, remotes are still problematic - can you file a bug?
[13:45] <briandealwis> ok
[13:46] <jelmer> briandealwis, git branch -a gets them from the packed refs file, which bzr-git will also be looking in
[13:47] <briandealwis> This is all great stuff, jelmer.
[13:47] <jelmer> briandealwis: now if only it actually worked.. :)
[13:53] <briandealwis> jelmer:  filed as bug 829481
[13:53] <jelmer> briandealwis, thanks!
[13:54] <briandealwis> jelmer: it's working great once I establish a local tracking branch
[14:03] <briandealwis> jelmer: the fix to bzr-git for avoiding rebuilding the git-map cache no longer triggers a rebuild.  thanks for that too!
[14:09] <vila> jelmer: thanks for the review !
[14:09] <vila> everybody: just thanks jelmer will you, it's just this time of day ;)
[14:12] <jelmer> briandealwis: great, thanks for confirming :)
[14:12] <jelmer> vila: hehe :)
[14:16] <vila> jelmer: any news from Riddell ?
[14:24] <jelmer> vila, haven't heard from him
[14:49] <vila> la la la, finally a trick to use pdb for blackbox tests \o/
[14:52] <jelmer> vila: ooh?
[14:52] <vila> http://paste.ubuntu.com/670131/
[14:53] <vila> I thought it was possible for... a long time, never tried. Stupid vila
[15:04] <vila> jelmer: and now https://code.launchpad.net/~vila/bzr/debug-blackbox-tests/+merge/72195
[15:07] <vila> great, merge proposals and bug numbers overlap... endless fun
[15:17] <jelmer> vila: it'd be great if BZR_TEST_PDB could support that too
[15:17] <fullermd> vila: Onoes!  BSD is dying again??   :(
[15:18] <vila> fullermd: hehe, wow, you've been away for long ;)
[15:19]  * vila just can't remember about BZR_TEST_PDB... time for some grepping
[15:19] <jelmer> fullermd, it's true, netcraft confirms it!
[15:20] <fullermd> Oh, I was worried for a second.  It's not REALLY official 'till it's on Wikipedia.
[15:21] <vila> jelmer: doesn't it work already ?
[15:21]  * vila tests
[15:22] <jelmer> vila: I'm not sure actually.. I just figured it wouldn't
[15:22] <vila> it seems to work but I'm not that familiar with post-mortem debug
[15:23] <vila> and before fullermd jumps his gun, yes, I prefer live debug ;)
[15:23] <fullermd> Ew.  Live bugs are creepy.
[15:24] <jelmer> fullermd: You have entomophobia and still manage to be a programmer?
[15:24] <vila> jelmer: right, looking at the implementation it's called far after stdin/stdout have been restored so N/A ?
[15:24] <fullermd> Well, it would be a problem if I were a _bad_ programmer.  Just gives me another reason to maintain my wonted perfection, see.
[15:25] <vila> fullermd: it's an acquired taste, I love bugs at breakfast
[15:25] <jelmer> heh, fair enough
[15:26] <jelmer> vila: that's a good point; so this means I should be using "from bzrlib import debug; debug.set_trace()" rather than importing from pdb?
[15:26] <vila> jelmer: yes
[15:26] <vila> well, at least with the proposed patch
[15:27] <vila> there may be a way to override the pdb.Pdb class directly, but I went with the simplest dirst
[15:27] <vila> first
[15:28] <jelmer> vila: this seems reasonable too
[15:29] <vila> thinking about it, may be I should just define set_trace in bzrlib including the pdb import... so we can just say bzrlib.debug()
[15:29] <vila> errr
[15:29] <vila> bzrlib.set_trace()
[15:30] <vila> jelmer: love/hate ?
[15:30] <jelmer> vila: in debug makes more sense to me
[15:30] <jelmer> and easier to find
[15:30] <jelmer> if we really care about not having to type that many characters, we should have ./bzr override pdb.Pdb
[15:31] <jelmer> IMO
[15:31] <vila> k
[15:32] <vila> on the other hand overiiding pdb.Pdb may be seen dev-hostile in same cases, bah, let's see what reviewers think, thanks for your feedback
[15:33] <lamalex> hi bzr, i'm trying to set up daily builds for the unity team. working on nux and when i run my recipe i get an error i dont understand, bzr: ERROR: No such tag: upstream-1.2.0t hooks - Stage 5/5
[15:33] <jelmer> lamalex, hi
[15:33] <vila> I like the existing ability to do self.debug() in tests (which triggered my typo above: bzrlib.debug())
[15:33] <lamalex> hello jelmer
[15:33] <jelmer> lamalex, it sounds like you're trying to build a non-native package but do not have a tag for the upstream tarball
[15:34] <jelmer> lamalex, since launchpad itself does not (yet) support non-native packages in recipes, I would recommend building with --allow-fallback-to-native
[15:34] <fullermd> Sounds like a double error actually, with it not clearing the line before giving the error.
[15:34] <lamalex> jelmer, what's a native vs non-native package? (i'm not a packager..)
[15:34] <lamalex> it's all C++ code..
[15:35] <jelmer> lamalex: http://wiki.debian.org/DebianMentorsFaq#What_is_the_difference_between_a_native_Debian_package_and_a_non-native_package.3F
[15:35] <lamalex> :)
[15:36] <jelmer> lamalex, in contrast to the answer on that FAQ, native packages often make more sense for daily builds
[15:36] <jelmer> lamalex: as upstream is going to change for each new upload, so there isn't much benefit in trying to reuse tarballs
[15:37] <lamalex> makes sense
[15:37]  * lamalex tries that flag
[19:03] <jml> mgz: I'm probably going to have some time for testtools hacking on the weekend. Am looking forward to seeing your stuff on assertThat.
[19:03] <jml> mgz: I don't want to nag. I very, very much appreciate your contributions. But I also want to release.
[19:04]  * jml goes
[19:05] <jelmer> maxb, btw, I did a subvertpy release
[19:05] <jelmer> jml: have a good weekend :)
[19:13] <etenil> Hi there
[19:14] <jelmer> hi
[19:15] <etenil> I'm working with the bzrlib, and I'm trying to make a formatter that turns a log into HTML, but the formatters seem to only be able to output to files (from the API anyway) and I'd need the output into a variable. Could someone help me?
[20:09] <mgz> blast, missed jml
[20:26] <Riddell> good evening
[20:27] <Riddell> sorry vila, I had a day off today
[20:27] <Riddell> are reviews still needed?
[20:28] <jelmer> 'evening Riddell
[20:28] <jelmer> I think there's still two open MPs
[20:35] <GRiD> hi Riddell  and/or jelmer, i'm waiting for proposal 70691. here if you want to talk about it.
[20:35] <Riddell> GRiD: got the full URL?
[20:36] <GRiD> https://code.launchpad.net/~weyrick/bzr/54624-warn-on-large-files/+merge/70691
[20:36] <GRiD> actually, i'm here as long as the approaching thunderstorm doesn't take out my power.
[20:36] <jelmer> g'evening GRiD
[20:37] <GRiD> howdy :)
[20:38] <GRiD> re: this proposal, i was thinking that if my final comment makes sense, i should probably make that functionality more explicit in the docs, and add a test for it
[20:39] <Riddell> GRiD: yes, I was just going to say that
[20:39] <GRiD> ok i'll add that, shouldn't take long.
[20:39] <Riddell> "add.maximum_file_size" why the dot in there?  bzr config options mostly don't use dots but some do and I'm not sure why
[20:41] <GRiD> if you look up in the comments a bit, that was one of the original suggestions from martin
[20:41] <GRiD> it seems that's a convention that's trying to be adopted
[20:44] <jelmer> yeah
[20:46] <jelmer> GRiD: I think this all looks ready to land
[20:47] <GRiD> awesome. let me just push these final doc changes and test
[20:48] <jelmer> GRiD, can you also add another newline above AddWithSkipLargeAction ?
[20:50] <GRiD> well now you're asking for a lot
[20:51] <jelmer> :D
[21:02] <GRiD> :) ok just pushed
[21:03] <jelmer> cool
[21:11] <Riddell> GRiD: lovely, approved, shall I sent it to PQM?
[21:12] <GRiD> very cool. uh, i don't know the next step, this is my first patch :)
[21:17] <Riddell> a good first patch :)
[21:17] <Riddell> next step is to ask the patch pilot (moi) to send it to PQM which is the programme that runs the test suite then merges it if it all works
[21:17] <Riddell> unfortunately pqm doesn't seem to want to work tonight "httplib2.ServerNotFoundError: Unable to find the server at api.launchpad.net"
[21:18] <Riddell> ah here we go
[21:19] <Riddell> GRiD: actually, could you add a release note too?
[21:19] <Riddell> needs an entry in doc/en/release-notes/bzr-2.5.txt
[21:19] <teratorn> hi, I'm trying to 'bzr merge', but bzr is failing to work because it complains about outstanding changes in the working directory. Which there are none, only the mistaken perception of changes; a bunch of files that have modes +x instead of -x presumably because this is on a Windows file system... how can I get unstuck?
[21:20] <Riddell> teratorn: does running bzr commit help ?
[21:20] <jelmer> teratorn: bzr revert should reset the entire tree, including the permission bits
[21:20] <Riddell> that's a better idea
[21:21] <teratorn> lets see
[21:21] <teratorn> I guess that works.... but how would it have gotten screwed up in the first place?
[21:22] <jelmer> teratorn: was there perhaps another branch you pulled in (and then reverted?) that touched the permissions bits?
[21:27] <teratorn> jelmer: I don't think so *shrug*
[21:28] <teratorn> btw, is there a fast-export/fast-import tool for bzr?
[21:30] <jelmer> teratorn, yep, there is a fastimport plugin
[21:31] <teratorn> yeah - I'm just checking it out now
[21:31] <jelmer> teratorn, I'm not sure what else could have caused the permission bits, I don't have a lot of experience using bzr on windows
[21:31] <GRiD> Riddell, ok thanks. I'll add the note
[21:45] <GRiD> Riddell, pushed, please take a look. tried to follow the existing format.
[21:54] <Riddell> GRiD: lovely, sent, it's in the queue at http://pqm.bazaar-vcs.org/
[21:54] <GRiD> great thanks :)
[21:55] <GRiD> i guess i should close the associated bug
[22:14] <GRiD> Riddell, shows a conflict in the release notes. do I have to do something?
[22:15] <Riddell> uh oh
[22:16] <Riddell> GRiD: merge in trunk and I'll send it again
[22:18] <elmo> does no one else find the bzr completions in zsh slow to the point of unusability ?
[22:19] <Riddell> they're slow to the point of unusability on bash too
[22:19] <elmo> Riddell: really?  bash works ok for me
[22:20] <elmo> I finally got annoyed enough to try bash
[22:20] <elmo> and was horrified to find it works there
[22:24] <mgz> elmo: have you seen contrib/zsh/README ?
[22:24] <mgz> my understanding is the new bash-completion plugin uses a more sensible method
[22:25] <mgz> it's certainly fast on my ancient laptop
[22:26] <GRiD> Riddell, ok i think i've merged ok
[22:26] <elmo> mgz: hmm, I hadn't thanks
[22:28] <mgz> GRiD: about your earlier question, unexpected merge conflicts are one reason I superstitiously wait for the pqm run to complete successfully before marking the bug fixed :)
[22:29] <mgz> so, elmo, I think `bzr shell-complete` is just slow, and zsh uses it while bash-completion doesn't.
[22:30] <GRiD> mgz, agreed, i actually did wait ... :)
[23:08] <bairui> elmo: did you find the problem? I think my bzr zsh setup is woeful too. :-(
[23:09] <elmo> bairui: I'm sure what mgz said is likely the problem - unfortunately I don't know enough zsh to be able to use the information to fix it
[23:10] <bairui> ok, but I don't even understand what he said - where is contrib/zsh/README ? whose contrib is that? bzr's? where is that? I did a locate and came up dry... :-?
[23:13] <bairui> oops... I didn't read his final word on the matter. :)
[23:15] <fullermd> Yes, it's right in the bzr tree.
[23:15] <bairui> you guys *have* a bzr tree :)
[23:16] <fullermd> We what?  Of course not.  What kind of nerds do you take us for?
[23:16] <bairui> heh - it's just that at this party... I'm a lesser nerd :-/
[23:16] <fullermd> In my youth, I tried that once.  It was an embarassing failure.
[23:16] <bairui> lol
[23:17] <fullermd> Now I just strive instead to be _massively_ more nerdy than anyone else.  That way, any references or jokes I make are so far out nobody even notices that I tried, so the end result is that I seem more normal.
[23:17] <fullermd> ...  that's my theory, anyway.
[23:19] <bairui> good blending strategy - at nerd parties
[23:21] <fullermd> There's...  some other kind?
[23:22] <bairui> heh - no. not fun ones, anyway.
[23:22] <bairui> so, without being able to read said README, what are my zsh bzr completion options? suck it up and wait? or is there a super-magic fix? or... use bash? :-(
[23:23] <fullermd> You can just read the README online y'know   ;p
[23:24] <fullermd> http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/view/head:/contrib/zsh/README
[23:24] <bairui> thanks, fullermd :D
[23:24] <fullermd> It's even more fun that way too, 'cuz it looks like loggerhead is trying to syntax highlight the README as if it were python...
[23:25] <bairui> yes... a bit unfortunate.
[23:25] <fullermd> Of course, the Right Answer is obviously to just use tcsh, like all smart attractive people do.
[23:25] <bairui> so, fullermd, you're on zsh too, eh?
[23:26]  * fullermd looks around for a stick.
[23:26] <bairui> heh :D
[23:26] <fullermd> I had a professor once who kept a 2x4 by his desk, with "Board Of Education" stenciled on it.
[23:26] <fullermd> He threatened to use it with some regularity.
[23:27] <bairui> the Clue Stick!
[23:27] <bairui> we had a senior at uni with a wiffle (sp?) bat that he'd wield in the labs. It was his Clue Stick
[23:58] <idnar> hmm
[23:58] <idnar> is there an easy way to reorder pipes?