[00:44] <poolie> spiv, igc, lifeless, do you think https://code.edge.launchpad.net/~mbp/bzr/456077-cross-format-fetch/+merge/17354 is worth merging to 2.0?
[00:44] <poolie> it is a bug, and a mysql bug, but
[00:44] <poolie> there's some risk of regressions
[00:45] <poolie> and i think not a high-impact bug
[00:45] <poolie> so i have doubts
[01:43] <lifeless> poolie: no strong opinion
[01:45] <thumper> lifeless: a fix for your most annoying code bug is playing in ec2
[01:54] <lifeless> thumper: \o/
[01:54] <lifeless> thank you
[01:57] <jkprg> hi. how could I list all branches of centralized repository?
[02:13] <CardinalFang> jkakar, there's a plugin that will download all tips.
[02:13] <jkakar> CardinalFang: Tips for what? :)
[02:14] <poolie> jkprg: 'bzr branches' (may be in bzrtools)
[02:17] <jkprg> poolie: thx. I have some problem with this command. it generates error of pycrypto (http://nopaste.info/b5e646b452.html)
[02:19] <poolie> it's not an error, it's a bug in another python library
[02:19] <poolie> i think recent bzrs suppress it?
[02:20] <jkprg> poolie: may be i'm too fresh. i have bzr 2.1.0b4
[02:22] <poolie> can you file a bug please?
[02:22] <poolie> https://bugs.edge.launchpad.net/bzr/+bugs
[02:22] <poolie> i thought there was one but this may be a different issue
[02:23] <jkprg> poolie: sure
[04:00] <jml> poolie, sorry, you asked earlier about where to talk about testtools.
[04:01] <jml> poolie, I'm sorry but I don't have a clear answer -- hip-deep in sprint, and not satisfied by the current channels for communication.
[04:01] <poolie> np, not at all urgent
[04:01] <poolie> i shall blather on subunit-dev i think
[04:39] <poolie> hi spiv, still around?
[04:50] <spiv> poolie: yeah
[06:58] <DaffyDuck_`> Let's say I want to ignore everything under src/, except src/sys/dev/cgd.c and src/sys/kern/kern_main.c. Is there a way to accomplish this using .bzrignore?
[06:59] <lifeless> bzr ignore ./src
[06:59] <lifeless> bzr add src/sys/dev/cgd.c src/sys/kern/kern_main.c
[06:59] <lifeless> (adds take precedence over ignores)
[06:59] <DaffyDuck_`> Oh, I thought "ignore"
[06:59] <DaffyDuck_`> ... ah. :)
[06:59] <DaffyDuck_`> Many thanks.
[06:59] <DaffyDuck_`> Makes sense, now that I think about it.
[07:04] <lifeless> np
[07:09] <vila> hi all
[07:11]  * fullermd waves at vila.
[07:12] <lifeless> hi vila
[07:14]  * vila feels welcome :)
[07:21] <DaffyDuck_`> lifeless: There's an interesting side effect when adding ./src to .bzrignore, and adding explicit files. Once I added the explicit files, it adds the paths up until the files, which means it finds lots of "unknowns". I guess I could set an explicit "ignore everything under ./src" rule? But how?
[07:22] <lifeless> DaffyDuck_`: hmm, let me check
[07:22] <DaffyDuck_`> I tried something like RE:./src/.*
[07:24] <DaffyDuck_`> Aha. "RE:src/.*" seems to have done it.
[07:25] <lifeless> bzr ignore './src/**/*'
[07:25] <lifeless> if you want to use an re thats fine - but be sure to anchor it to root
[07:25] <DaffyDuck_`> Even better. Thanks again.
[07:25] <lifeless> as you don't want to ignore *any* dir called src, only ones at the top.
[07:25] <DaffyDuck_`> Yeah, that's what I was worried about.
[07:26] <lifeless> contrast with (for instance) 'bzr ignore Makefile.in' where any Makefile.in should be ignored.
[07:38] <lifeless> poolie: ping
[07:38] <poolie> hi
[07:39] <lifeless> something is calling stopTest without calling any outcome, for a number of tests
[07:39] <poolie> ... to cause that behaviour i complained about?
[07:39] <lifeless> to cause the stderr output
[07:40] <lifeless> its because the test before the first one shown hasn't 'finished' in the stream.
[07:40] <poolie> something in bzr?
[07:40] <lifeless> yeah - bzr/testtools
[07:40] <lifeless> if you run subunit-stats < subunit.out | head
[07:40] <poolie> :{
[07:40] <lifeless> you'll see the start of a subunit stream
[07:41] <lifeless> look in subunit.out with vim, find the test: line that was at the top of head
[07:41] <lifeless> and look up
[07:41] <poolie> mm
[07:41] <lifeless> you'll see a test that is misbehaving
[07:41] <lifeless> its probably my fault :)
[07:42] <poolie> mm
[07:42] <poolie> test_info_locking
[07:42] <poolie> there is a test line but no other mention of it
[07:42] <lifeless> right
[07:42] <poolie> are you allowed to have multiple tests in flight at once?
[07:42] <lifeless> that means that startTest was called, but not addSuccess/addSkip/addExpectedFailure/addError/addFailure/addUnexpectedSuccess
[07:43] <lifeless> poolie: in a single stream, no. the parser will emit an error for that test after the stream ends at the moment.
[07:44] <poolie> i kind of want a --strict that will flag these
[07:44] <poolie> or a subunit-lint
[07:45] <lifeless> poolie: It may be a good idea to warn on any token seen out of state; I don't at the moment to be as transparent as possible.
[07:46] <lifeless> if you do subunit2pyunit < subunit.out
[07:46] <lifeless> you get
[07:46] <lifeless> ERROR: bzrlib.tests.per_tree.test_path_content_summary.TestPathContentSummary.test_file_content_summary_not_versioned(PreviewTree)
[07:46] <lifeless> ----------------------------------------------------------------------
[07:46] <lifeless> _StringException: lost connection during test 'bzrlib.tests.per_tree.test_path_content_summary.TestPathContentSummary.test_file_content_summary_not_versioned(PreviewTree)'
[07:47] <poolie> mm
[07:47] <poolie> it may be better but it's not exactly clear
[07:47] <lifeless> I agree.
[07:47] <poolie> sorry if that sounds grumpy
[07:47] <lifeless> We can definitely have a specific linter
[07:47] <lifeless> I'm hesitant to make the main parser more aggressive though.
[07:48] <poolie> yes that makes sense not to
[07:48] <lifeless> you don't sound grumpy
[07:48] <lifeless> this is with bzr.dev yes?
[07:48] <poolie> i think i'd like it to try to catch up and keep going
[07:48] <poolie> approximately
[07:48] <poolie> so
[07:48] <poolie> i'm going to stop for today
[07:49] <lifeless> what combination of bzr branch + testtools version did you use to generate the subunit.out ?
[07:52] <lifeless> poolie: ^
[07:56] <lifeless> vila: ping
[07:57] <vila> lifeless: pong
[07:57] <lifeless> bug 507804 - is it possible that you have the same sort of damage to the subunit stream you're testing subunit2gtk with ?
[08:01] <poolie> lifeless: it's within a few revs of bzr head
[08:02] <poolie> well, ~mbp/bzr/progress if you want to be specific
[08:02] <poolie> and
[08:02] <poolie> >>> testtools.__version__
[08:02] <poolie> (0, 9, 2, 'final', 0)
[08:02] <lifeless> poolie: could you try running just ./bzr selftest --subunit bzrlib.tests.blackbox.test_info.TestInfo.test_info_locking | subunit-stats before you sign off
[08:02] <vila> lifeless: I don't think so but I notice that:
[08:03] <poolie> Total tests:       2
[08:03] <poolie> Passed tests:      2
[08:03] <poolie> Failed tests:      0
[08:03] <poolie> Skipped tests:     0
[08:03] <vila> ./bzr selftest -s bt.test_log --subunit | ~/src/subunit/trunk/filters/subunit2gtk is broken
[08:03] <lifeless> poolie: ok, so whatever damaged the stream either needs a full test run, or was post-output from bzr
[08:03] <vila> while redirect the output and then using the file works (selftest > file ; filter < file)
[08:04] <poolie> the whole module works
[08:04] <lifeless> vila: just tried it - it worked for me
[08:04] <vila> lifeless: so not bug #507804, but something specific to subunit2gtk
[08:04] <lifeless> vila: thanks
[08:04] <poolie> but now i have to go
[08:04] <lifeless> poolie: thanks
[08:04] <poolie> dinner and extremely strange movies at the Chauvel
[08:04] <lifeless> enjoy!
[08:05] <lifeless> Did you do any post processing of the stream?
[08:05] <vila> lifeless: what worked ? selftest | filter ?
[08:05] <lifeless> vila: ./bzr selftest -s bt.test_log --subunit | ~/source/unittest/subunit/working/filters/subunit2gtk
[08:05] <lifeless> 67 ok, 0 not ok.
[08:06] <vila> lifeless: try subunit-stats as the filter
[08:08] <vila> oh damn, my version says 67 ok when stats says 70, whereas trunk says 67 ok 1 nok when stats says 70 >-/
[08:11] <vila> lifeless: right, got that fixed too, hup is trigger-happy so we should process all pending reads first
[08:13] <lifeless> visik7: welcome back
[08:13] <vila> lifeless: right, got that fixed too, hup is trigger-happy so we should process all pending reads first
[08:13] <lifeless> vila: I don't like the approach
[08:13] <vila> lifeless: pushed to lp~vila/subunit/gtk-filter-fixes
[08:14] <vila> lifeless: fine with me, as long as you fix the bugs :)
[08:14] <lifeless> vila: busy reading in 'idle' is not nice
[08:15] <lifeless> vila: in particular, running two or three of these in the same process is going to end badly  (think multiple ec2 machines)
[08:15] <vila> installing/uninstalling io watch have race conditions, you can miss events
[08:16] <lifeless> vila: ! its not level triggered ?
[08:16] <vila> I didn't change *when* we read, you said the UI is starving, fine, let's process the events
[08:16] <vila> level triggered means ?
[08:16] <lifeless> edge vs level
[08:17] <vila> ECANTPARSE
[08:17] <lifeless> http://en.wikipedia.org/wiki/Interrupt#Level-triggered
[08:17] <lifeless> If there is data to read, adding a watch should trigger a read
[08:18] <lifeless> otherwisee a trivial 'cat foo' program that supplies 'test: foo\nsuccessful: foo\n' would not cause anything to be seen
[08:18] <mneptok> mmmmm .... cat food.
[08:19] <vila> right, but how is that relevant to the fact that the hup signal is handled while in signals are pending ?
[08:19] <lifeless> vila: your branch has conflicts btw
[08:20] <lifeless> currently the merge is nonsensical
[08:22] <vila> lifeless: weird
[08:24] <vila> Oh, right, got it, the conflict is genuine, I deleted the lostConnection call
[08:24] <lifeless> vila: I've done something similar
[08:24] <lifeless> see if that fixes it for you
[08:26] <vila> lifeless: yup, fixed
[08:29] <lifeless> thank you for catching this issue
[08:35] <vila> lifeless: hmm, but now the UI is starving again when fed with a bug file...
[08:35] <vila> s/bug/big/
[08:36] <lifeless> vila: via cat ?
[08:36] <vila> lifeless: filter <big_file
[08:39] <lifeless> bah
[08:39] <lifeless> I meant to write all=False
[08:39] <fullermd> all=False == none=True?
[08:39] <lifeless> idnar: pshed
[08:39] <lifeless> bah
[08:39] <lifeless> idnar: sorry
[08:39] <lifeless> vila: PSHed
[08:39] <vila> which is expected since all defaults to True
[08:39] <vila> perhaps you meant it to default to False instead
[08:39] <vila> yup seems to do the trick
[08:39] <vila> Now you can compare both versions and see decide which behaviour you prefer
[08:40] <lifeless> Scheduling a read later is better for now IMO
[08:40] <lifeless> reentering into the event loop is nasty
[08:40] <lifeless> imagine you had three streams
[08:41] <vila> io_watch events are not the same as othe events (IIRC) I did it that way in a gtk app with admiteddly a single data source, but never encounter problems in years
[08:49] <vila> lifeless: in fact, since the  loop is while event: process_event and the script can exit this loop *while there are still pending reads* I'm pretty sure it's safe :0D
[08:50] <lifeless> vila: if you're playing with subunit
[08:50] <lifeless> be sure to checkout testrepository
[08:52] <vila> lifeless: sure, I came to subunit filters when toying with testrepository as you pinged me about it yesterday or the day before :)
[11:29] <grettke> Hi. I had done a bzr unbind to work disconnected, and bound back to the remote branch. I want to blow away those changes now. Would you say, unbind and revert them, or, is there a simpler way?
[11:30] <LeoNerd> pull --overwrite  ?
[11:32] <grettke> I'll try it... just realizing that I ought to study up a bit more on the nature of doing the SVN model with BZR ;).
[11:33] <lifeless> grettke: if you want to blow them away
[11:33] <lifeless> grettke: then do 'bzr update; bzr revert'
[11:33] <lifeless> grettke: when you're using a checkout, it works like a checkout :)
[11:33] <grettke> lifeless: doh! :), pull in the changes and then blow them away, I see
[11:33] <lifeless> grettke: updating makes your local offline work into a pending merge and sets the master as your tip
[11:33] <lifeless> grettke: then revert discards the pending merge
[11:36] <grettke> lifeless: thank you
[13:02] <vila> lifeless: how do I get a subunit stream *out* of testr ?
[13:07] <bialix> heya bzr
[13:07] <vila> hi bialix
[13:07] <bialix> hi vila!
[13:27] <ruk> i am geting this error: http://pastebin.com/m4b2e273
[13:29] <vila> ruk: what is en_IN ?
[13:29] <vila> ruk: python doesn't know about it, that's the problem, try en_US.UTF-8 instead
[13:30] <ruk> vila: how can i change it?
[13:30] <vila> as in export LANG=en_US.UTF-8
[13:31] <vila> ruk:  but it's strange you ended up with such a $LANG, any idea how you ended with that ?
[13:31] <ruk> vila: no. i am using ssh login for first time and then i did $bzr
[13:32] <vila> ok, so ask the remote admin about it
[13:32] <ruk> btw i m stiil getting same error: http://pastebin.com/m790fa6e5
[13:32] <ruk> vila: ok
[13:32] <vila> ruk: oooh, that's english(India) does that ring a bell ?
[13:33] <ruk> vila: yeah
[13:33] <vila> ruk:  so you may try en_IN.UTF-8 instead, no need to force US on India :)
[13:37] <ruk> vila: same error only lang is changin!
[13:38] <vila> does it work with en_US.UTF-8 ?
[13:42] <ruk> vila: i think i can ignore it!
[13:43] <ruk> vila: but while trying to get branch i get "Permission denied (publickey). bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist. "
[13:43] <vila> ruk: it's hard to tell if you don't tell me what works and what doesn't work
[13:44] <vila> the later error is probably because you didn't 1) log to launchpad 2) didn't install your private ssh key on the host you're running bzr from
[13:45] <ruk> ok
[13:45] <ruk> vila: so i have to login separtely for launchpad from ssh also ?
[13:47] <vila> ruk: that's the way ssh works, each host is seen as different unless you share keys, launchpad allows you to register which keys you will use, ssh allows you to specify which key you use when connecting to a given host
[13:47] <vila> finally launchpad *requires*  ssh keys
[13:47] <vila> so if you don't have keys you can't connect to launchpad
[13:54] <ruk> vila: do i have to save on remote machin (ssh) the ssh key file?
[13:54] <vila> ruk: that or create a new key pair and upload the public one on lp
[13:55] <ruk> vila: i did ssh-keygen on ssh but i think it generated a new rsa key and overwrote on my preevious key.
[13:56] <vila> what do you call shh ? The remote host ?
[13:57] <ruk> vila: :)
[13:59] <ruk> vila: ssh for connecting tto remote host.
[13:59] <ruk> securely
[14:00] <vila> ruk: I can't parse "i did ssh-keygen on ssh" where did you run that ?
[14:01] <ruk> vila: i logged in using sssh . after loggin i did ssh-keygen
[14:02] <vila> so you ran it on the remote host, then you didn't overwrote your local key, have a look into $HOME/.ssh on both your local and remote host to check
[14:04] <ruk> vila: i see only three file. rsa, rsa_pub and known hosts
[14:05] <vila> locally and remotely ? Same sizes ? Same dates ? Same content ?
[14:05] <ruk> vila: how do i check remotley?
[14:05] <vila> ruk: you know how to use ssh right ?
[14:06] <ruk> vila: i m a total n00b with both ssh and bzr! :(
[14:06] <vila> ruk: What are you trying to do exactly ?
[14:06] <ruk> somehow i managed to keep my branch updated! ;)
[14:09] <ruk> vila: i have been assigned a web adres for uploading my app. i was given an ssh acess too! i have my branch on Launchpad which i would like to push on the web adress assigned.
[14:11] <vila> so assuming that web address is an url starting with either sftp: or bzr+ssh: and that your rsa_pub is part of their authorized_keys then just do bzr push URL
[14:12] <vila> if that's not the case, you need to contact the admin for that URL and set things up with him
[14:12] <ruk> ok
[15:40] <ruk> is thr a GUI way of uploading branch on launchpad?
[15:40] <ruk> :)
[15:46] <beuno> ruk, maybe using bzr-gtk?
[15:52] <bialix> ruk: bzr-explorer
[16:28] <davidstrauss> Is it possible to "revert" the contents of the working tree to the tree contents of a revision on a remote branch?
[16:33] <bialix> revert -r xxx ?
[16:42] <jam> davidstrauss: bzr revert -r -1:$REMOTE_BRANCH
[16:43] <davidstrauss> ah
[16:43] <jam> or bzr revert -r branch:$REMOTE_BRANCH
[16:43] <davidstrauss> jam: thanks
[16:43] <davidstrauss> jam: I kept trying -r revno:-1@$REMOTE_BRANCH
[16:43] <jam> @ => : would have worked
[16:46] <bialix> nice
[16:46] <bialix> never know it's possible
[16:46] <bialix> hello jam
[16:47] <jam> hi bialix
[16:48] <bialix> does it works only for revno?
[16:52] <maxb> Whether a revision specifier accepts a branch parameter is part of the revision specifier
[17:04] <ruk> i am getting internal server error when i open some folder in my branch .however i can open files!
[17:08] <Peng> ruk: Go on. Is this using Loggerhead or something? What does the server's error log say? Use index files or something?
[17:09] <ruk> Peng: i am checking it through my web browser on launchpad
[17:40] <lifeless> vila: testr failing --subunit
[17:46] <vila> lifeless: hmm, testr help failing looks promising :-) What I had in mind I asked was the ability get a stream for any run though, which I since realized is just there in the .tesr dir
[17:46] <vila> s.mind.mind when/
[17:58] <lifeless> vila: Feel free to add a command to show an arbitrary run, with a --subunit option to it ;)
[17:58] <lifeless> vila: I'd like access to the files in .testrepository to be arbitrated
[18:01] <Peng> Great, ruk's gone... :|
[18:01] <Peng> Well, if it comes to it, someone could check LP's logs./
[18:01] <lifeless> 'codebounce down'. ;P
[18:01] <lifeless> -> plan
[18:01] <lifeless> -> plane
[18:02]  * vila nods @ lifeless (about arbitrated access)
[18:02] <beuno> oooh...  and that's with the new patch I think
[18:02] <beuno> lifeless, you've been a lot on planes lately
[18:08] <vila> wow, now that's a nasty trap: read a test, think , right, so that's how we implement it.... hours pass.... realize that the test is against a deprecated function :-( Worse, the deprecation is only a comment in the function >-(
[18:08]  * vila search for a chicken to eviscerate just because
[18:18] <Flare183> When I use bzr register-branch it gives me this error: bzr: ERROR: xmlrpc protocol error connecting to https://xmlrpc.edge.launchpad.net/bazaar/: 401 Unauthorized
[18:18] <Flare183> How can I fix it?
[18:18] <Flare183> Or what should I do?
[18:19] <znik> when i do bzr merge lp:/... Is the online branch merged or the local one?
[18:20] <maxb> lp: is an alias for bzr+ssh://bazaar.launchpad.net/ or http://bazaar.launchpad.net depending on whether you've registered your launchpad login - either way, it's remote
[18:20] <Flare183> ok
[20:05] <lifeless> beuno: not really
[20:06] <lifeless> vila: what code?
[20:06] <lifeless> maxb: flare probably needed to log in
[20:08] <vila> lifeless: log.calculate_view_revisions
[22:34] <Adys> is there a way to completely delete files from a repo? I got like 50mb of static content I branched off that's being downloaded every time I branch my website repo
[22:41] <maxb> Adys: Unfortunately no, or at least, not without rebuilding a new branch which bzr will not consider to be related to the old one (so no merging between them)
[22:41] <maxb> If this is potentially acceptable to you, install bzr-fastimport and read bzr help fast-import-filter
[22:41] <Adys> mmh ill stay lazy
[22:42] <Peng> Adys: Yes, but not easily.
[22:42] <Peng> Adys: Um, mostly people use bzr-fastimport for it.
[22:42] <Peng> Eeek.
[22:43] <Peng> What was that?
[22:54] <mneptok> Peng: netsplit
[22:54] <quotemstr> Clearly, the network should go on one humongous server.
[22:54] <Peng> mneptok: Well yes, but this one was combined with some nice lag. That's unusual.
[22:54] <Peng> "[Lag: 14.13]" :D
[22:55] <Peng> "[Lag: 70.63]" -- even better! (Sorry, I'll stop now.)
[22:55] <Peng> Aww, 5.06 now. *Now* I'll stop. :P
[22:57] <Peng> What about a mainframe? :D
[22:58] <mneptok> a netbook with multiple OC-192s is better for IRC than a mainframe with a single 300kbps modem :)
[23:00] <Peng> mneptok: You just have to get a bunch of keyboards and monitors and make the users sit right there.