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