[00:43]  * lifeless watches the dustweeds
[01:25] <lifeless> spiv: bug 457952
[01:27] <spiv> lifeless: what about it?  I guess the question is "what precisely should the 'check' target do?", and then just land that.
[01:28] <lifeless> spiv: I proposed an idiom earlier in the bug report
[01:28] <spiv> lifeless: feel like proposing an actual patch? :)
[01:28] <lifeless> I think something like tee test.log && subunit-stats < test.log
[01:29] <lifeless> spiv: or subunit-filter --no-skip < test.log | subunit2pyunit
[01:30] <spiv> lifeless: sure, the idea sounds fine.  But it seems to me that you're the best person to decide on the details.
[01:31] <lifeless> spiv: I'll add it to my queue
[01:31] <lifeless> spiv: possibly in the weekend
[01:32] <lifeless> spiv: I may be the best person; I don't think it needs the best person.
[01:34] <spiv> Well, partly I'm a bit hesistant because last time I turned on subunit things broke.  But that change was also simpler... and I haven't got all the various subunit-* utils paged in, so discovering the options for achieving this and evaluating them is not trivial effort.  If you propose a patch I can pilot it though ;)
[01:38] <lifeless> its not really on my radar workwise
[01:47] <lifeless> spiv: I guess what I'm thinking is that : it will help folk landing stuff; having at least one other person happy with the tool chain is important :)
[02:27] <stewart> hi! i'm having issues with a plugin I wrote. it's trying to commit.run with author= as a parameter, but i'm getting "author: s, t, e, w" etc instead of "author: stewart@"  any clues?
[02:27] <stewart> running bzr 2.0.2
[02:29] <stewart> (this used to work okay)
[02:32] <spiv> stewart: a commit can have multiple authors
[02:32] <spiv> stewart: so IIRC you need to pass a list of author strings, not just a single author string.
[02:32] <stewart> ahh...
[02:32] <stewart> let's try that
[02:33] <spiv> That feature was added in 1.13 according to the news file.
[02:34] <stewart> subtle API change :)
[02:34] <spiv> Yeah.  It would have been nicer I guess if the API had renamed that param.
[02:35] <spiv> And also calling it 'authors' would be clearer, really, but I think that's a limitation of our command-line processing infrastructure.
[02:35] <stewart> as i don't think i'm that important that each character in my email address should be listed :)
[02:36] <stewart> i should actually rip this plugin out of the internal mysql tree and just publish it.... was the original intention.
[02:37] <spiv> Probably ListOption should grow a feature where the name of the --option does not have to precisely match the param in the API, because the CLI will have a singular word (possibly repeated), but the API ideally would have a plural.
[02:38] <RenatoSilva> verterok: hi
[03:46]  * fullermd slaps lying 'merge' around.
[03:52] <fullermd> Is it actually expected that merge bleats about being unable to find a common ancestor when there are two of 'em?
[03:56] <lifeless> fullermd: thats a criss cross
[03:57] <lifeless> and it recurses deeper in that case
[03:57] <fullermd> Well, no, it just dies.
[03:57] <lifeless> fullermd: you may have a special case.
[03:57] <lifeless> bug filed?
[03:57] <fullermd> bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.
[03:58] <lifeless> theres no sign of two common ancestors there
[03:59] <fullermd> Well, I know.  But there are two.
[04:03] <fullermd> bug 483388
[04:13] <fullermd> (adding an explicit merge type doesn't change anything; I conjecture that it blows up before it gets to anything merge-type varies)
[04:26] <RenatoSilva> verterok: hope you read this later, I've got the new update site, but it works only if extracted. Some users like me get confused because update sites usually work as a zip. But anyway, I've extracted it and got bzr-eclipse installed without errors
[04:26] <RenatoSilva> verterok: however, when I try to get a lp branch as new project, it's not working if I put a non-ascii path :(
[04:27] <RenatoSilva> verterok: org.vcs.bazaar.client.xmlrpc.XmlRpcCommandException: <class 'xml.parsers.expat.ExpatError'>:not well-formed (invalid token): line 1, column 302
[04:28] <RenatoSilva> verterok: iirc that error is related to xmloutput
[05:28] <verterok> RenatoSilva: Hi
[05:28] <RenatoSilva> verterok: hi
[05:28] <verterok> RenatoSilva: yes, there is a bug with the bundled xmloutput in windows :/
[05:28] <verterok> RenatoSilva: I'm working on a fix ATM
[05:29] <RenatoSilva> verterok: ok let me know if I'm still here, so that I can test it
[05:29] <verterok> RenatoSilva: ok, probably I'll finish it by tomorrow, I need to sleep a few hours before go to work ;)
[05:30] <RenatoSilva> verterok: ah ok :)
[05:30] <RenatoSilva> verterok: just to note: I think there are remaining encoding problems in xmloutput
[05:30] <verterok> RenatoSilva: oh, that's bad :(
[05:31] <RenatoSilva> verterok: do you remember a bug when I said about 2 approaches about the XML Header? Always declare and  UTF-8 vs. detect system encoding?
[05:31] <verterok> RenatoSilva: yes
[05:33] <RenatoSilva> verterok: I've noted that your fixes to the encoding problems I've reported tend to go to detecting, but as I said, we must be careful about valid entries. For example, we can't get <?xml... encoding="cp850"?> because cp850 is an invalid entry for an XML document.
[05:34] <RenatoSilva> verterok: besides, I wonder if the fixes you've committed are adding more issues. In a nutshell: we need to take a better look at xmloutput. Feel free to ask me for testing :)
[05:34] <verterok> RenatoSilva: regarding, bzr-eclipse, in the preference page, try adding the path to the bzr plugins directory to the plugins path , e.g: in my winxp vm, it's: C:\Documents and Settings\guillermo\Datos de programa\bazaar\2.0\plugins
[05:34]  * RenatoSilva checks his xmloutput bugs
[05:35] <verterok> RenatoSilva: and click the Recheck button after setting it :)
[05:35] <RenatoSilva> verterok: but the bundled xmloutput is the same as trunk
[05:35] <RenatoSilva> verterok: or is it for something else?
[05:36] <verterok> RenatoSilva: yes, but there is a bug in bzr-eclipse, the code that builds the BZR_PLUGIN_PATH value is broken for windows paths
[05:36] <verterok> RenatoSilva: it's trunk
[05:36] <RenatoSilva> ok but why does it need to be aware of that path?
[05:37] <verterok> RenatoSilva: to override the path of the bundled xmloutput...I didn't testted :/
[05:41] <verterok> RenatoSilva: looks like adding the path to plugins dir works, at least in my spanish win xp :)
[05:42] <RenatoSilva> override the path?
[05:43] <verterok> RenatoSilva: in the bazaar preference page, there is an option to add plugins path
[05:44] <verterok> RenatoSilva: bzr-eclipse trunk, don't handle windows paths ok, and so the BZR_PLUGIN_PATH used contains a wrong path.
[05:44] <verterok> RenatoSilva: in order to use trunk build, you need to add the plugins path manually
[05:45] <RenatoSilva> verterok: ok but I mean, why does bzr-eclipse need to know that plugins path? to override the bundled's? but what's that?
[05:46] <verterok> RenatoSilva: bzr-eclipse trunk, bundle xmloutput so users don't have to install it...basically to simplify the install process
[05:46] <Peng> What's the right way to make push default to --no-strict? An alias?
[05:47] <verterok> RenatoSilva: but to do that, it need to set BZR_PLUGINS_PATH when it launchs the xmlrpc service
[05:48] <verterok> Peng: probably that's the way to go :)
[05:49]  * RenatoSilva installing bzr-eclipse again
[05:50] <verterok> RenatoSilva: or you can wait until tomorrow night, for the new build ;)
[05:51] <RenatoSilva> verterok: you said I could set the path manually, do you think it may be cause of the parse error I mentioned above?
[05:51] <Peng> verterok: Eh, ok
[05:51] <verterok> RenatoSilva: don't know :/
[05:52] <RenatoSilva> verterok: ok will test now
[05:52] <verterok> RenatoSilva: that error is the same we were getting in hudson a few days ago...
[05:52] <RenatoSilva> verterok: I remember that error as being something regarding encoding for sure
[05:54] <poolie1> spiv, how did the pilotage go?
[05:56] <RenatoSilva> verterok: there's no executable set, can't get how it was finding it...
[05:57] <verterok> RenatoSilva: it will look for it in PATH
[05:57] <RenatoSilva> ah ok, just added bzr's plugin path, will test
[06:00] <RenatoSilva> verterok: bah, same error, even setting the path manually :(
[06:00] <verterok> RenatoSilva: :(
[06:00] <RenatoSilva> verterok: org.vcs.bazaar.client.xmlrpc.XmlRpcCommandException: <class 'xml.parsers.expat.ExpatError'>:not well-formed (invalid token): line 1, column 302
[06:01] <RenatoSilva> verterok: would be easy to find out what's happening if I debug, but I'm afraing not getting the source code debug working
[06:01] <RenatoSilva> afraid
[06:01] <verterok> RenatoSilva: bzr-eclipse code?
[06:02] <verterok> RenatoSilva: it should bo ok now, I updated all deps in the pom(s).xml
[06:02] <RenatoSilva> verterok: yes, and we'd need bzr-java-lib too...
[06:02] <verterok> *be
[06:02] <spiv> poolie1: it's going pretty well, although it's a bit tedious figuring out who has signed the contributor agreement
[06:02] <poolie1> there's an lp team for it?
[06:03] <poolie1> i think?
[06:03] <RenatoSilva> verterok: but bzr-eclipse does not come configured to work with the source code of bzr-java-lib
[06:03] <spiv> There is, but a) I'm not confident it's up to date, and b) I don't see any way to go from a team page to a complete list of members.
[06:03] <verterok> RenatoSilva: yes, it will pull bzr-java-lib from the maven repository
[06:03] <spiv> Or rather, I see a way that *should* do that, but doesn't.
[06:03] <spiv> You can go backwards, from the lp user check their team memberships.
[06:04] <RenatoSilva> verterok: if the problem is not with xmloutput, it is with bzr-java-lib likely, so I will need the source of that too
[06:05] <verterok> RenatoSilva: oh, ok
[06:05] <RenatoSilva> verterok: I've got it working before, let me try again (feaaaar)
[06:05] <verterok> RenatoSilva: /me needs to get some sleep :)
[06:05] <RAOF> Hm.  How can I tell if a bzr-git dpush is actually going to finish or not (halting problem notwithstanding)?  This one seems to have pushed ~400MiB of data, which is substantially larger than the repository.
[06:05] <RenatoSilva> verterok: ok see you, thanks
[06:06] <verterok> RenatoSilva: np, thank you :-)
[06:06] <verterok> seey'a later!
[06:10] <RenatoSilva> Is there any issues related to running two bzr.exe instances at the same time?
[06:10] <RenatoSilva> I suspect I have one or more
[06:24] <poolie1> spiv: seriously? that seems like quite a gap
[06:24] <RAOF> Oooh.  2GB ram & 600MiB upload later it seems that dpus is almost done :)
[06:26] <poolie1> spiv, in theory one can write a bot that marks mp depending on whether the contributor is a member of the team or not
[06:26] <spiv> poolie1: yeah, just filing a bug on that now.  There's an "All members" link, but it leads to disappointment rather than the information I seek.
[06:26] <poolie1> https://edge.launchpad.net/~contributor-agreement-canonical/+members#active
[06:26] <poolie1> oh because it doesn't expand ubuntuone-hackers?
[06:26] <poolie1> it's safe to assume they're all staff
[06:27] <spiv> poolie1: that page says "54 people are members in total", then only lists 9 people
[06:27] <fullermd> "New bug filed: Plz delink disappointment"
[06:28] <spiv> Hmm, I'm not sure if that's a correct assumption.
[06:28] <spiv> Anyway, I think that means that page isn't complete, given that there are many more on the internal wiki page.
[06:36] <poolie1> i still think it's a bug
[06:36] <poolie1> that's true too
[06:36] <poolie1> we should pull them across
[06:37] <poolie1> can i suggest you mention this in a mail about the pilot project sometime
[06:37] <poolie1> hm
[06:37] <poolie1> actually it might just be flamebait
[06:38] <poolie1> we probably should reconcile that team with the other list/s though
[06:38] <spiv> Yes, a single canonical (hah!) list would be nice.
[06:38] <poolie1> if only there was a massive sql db guaranteed to have the precisely correct schema and data
[06:39] <fullermd> You can just use the web as one.  First, you become Google...
[06:39] <spiv> That's just begging for another joke about the word "canonical" :P
[06:44] <poolie1> we only give you $5 for lunch? that doesn't go far...
[06:45] <spiv> poolie1: for breakfast
[06:49] <lifeless> hmm, I need to do expenses too
[06:49] <lifeless> we did what, three group meals? mon, wed, friday
[06:50] <poolie1> and also thursday, without you
[06:51] <lifeless> yes :)
[09:26] <bialix> Hi GaryvdM
[11:33] <maxb> Where is the correct place to discuss a compatibility-breaking UI change? Namely, I would like to propose dropping the 'bzr rebase --always-rebase-merges' option and making its behaviour the default
[11:35] <balor> Is there a nice linux GUI tool for resolving conflicts?
[11:35] <bob2> meld
[11:35] <bob2> if you use emacs, smerge-ediff is very nice, too
[11:36] <bob2> (aside from the ridiculous colours)
[11:36] <balor> bob2, How does meld help? do I diff3 the BASE OTHER and THIS files?
[11:50] <gioele> balor: yes, also try kdiff3
[11:53] <balor> gioele, Thanks.  Meld worked brilliantly well.
[11:53] <balor> meld foo.c.BASE foo.c.OTHER foo.c.THIS, make them all agree then cp foo.c.BASE foo.c, bzr ci
[11:57] <gioele> balor: no "bzr resolve"?
[11:59] <Peng> "bzr resolved" is for telling bzr that the conflicts have been resolved, not for actively resolving them (unlike hg, which always bites me).
[12:00] <gioele> Peng: yes, but I thought that you needed "bzr resolve" before "bzr commit"
[12:09] <Peng> Oh oh, that's what you meant. Yes, you're correct.
[12:09] <Peng> Sorry I misunderstood.
[12:31] <gioele> spiv: (pilot) could you help me with <https://code.launchpad.net/~gioele/bzr/forgot-commit-message>? Is there something missing or wrong?
[12:50] <RenatoSilva> what is .bzr\checkout\lock\releasing.ed3xwzvx48mik4q2lqhl.tmp?
[12:50] <RenatoSilva> and .bzr\checkout\lock\held?
[12:50] <RenatoSilva> and how access denied errors are related to such files?
[13:12] <bialix> RenatoSilva: break-lock is your friend
[13:12] <RenatoSilva> sorry?
[13:13] <RenatoSilva> bialix: this is happening in unit tests, *randomly*
[13:13] <bialix> RenatoSilva: windows?
[13:14] <RenatoSilva> procmon is my friend and gives the this info about the error: Path "C:\Documents and Settings\Renato\Configura├º├Áes locais\Temp\bazaar_client_tests8941769694356864996\working_copies\localBranch\original\.bzr\checkout\lock\held"
[13:14] <RenatoSilva> Detail "ReplaceIfExists: False, FileName: C:\Documents and Settings\Renato\Configura├º├Áes locais\Temp\bazaar_client_tests8941769694356864996\working_copies\localBranch\original\.bzr\checkout\lock\releasing.rcgp0djgibyborcys2tx.tmp"
[13:14] <RenatoSilva> * gives me, and yes WinXP SP3 updated
[13:14] <bialix> I'd suggest to using shorter path for temp directory
[13:14] <RenatoSilva> I don't know what ReplaceIfExists and the related FileName means though
[13:14] <bialix> something like C:\TMP
[13:15] <RenatoSilva> Already tried
[13:15] <RenatoSilva> I probably tried anything that you can imagine :P
[13:15] <bialix> this is test for smart server? or dumb server perhaps
[13:15] <RenatoSilva> sorry?
[13:16] <bialix> I'd say this is race condition
[13:16] <bialix> RenatoSilva: bazaar_client_tests
[13:16] <bialix> the name of this tests suggest me that some sort of server is tested
[13:16] <bialix> perhaps some code runs in thread
[13:17] <RenatoSilva> what's that I'm sorry? The test errors are with bzr-java-lib project, only in my Windows XP
[13:17] <bialix> therefore race condtion
[13:17] <bialix> so what?
[13:17] <bialix> .bzr\checkout\lock is lock
[13:18] <bialix> if you have file with lock info still opened/read by one process you can't delete it by other
[13:18] <RenatoSilva> a dir right? and releasing.*.tmp?
[13:18] <bialix> RenatoSilva: there is file inside, named info
[13:18] <bialix> text file with info about lock
[13:18] <bialix> *.tmp is fancy_rename trick
[13:19] <bialix> see bzrlib/osutils.py fancy_rename
[13:20]  * RenatoSilva has no idea on what could be causing this problem, he's into this since days
[13:20] <Peng> Something that doesn't release locks, perhaps?
[13:20] <bialix> if you say it's random failures then I'd say it's either path length limit or race condition
[13:21] <bialix> or you have aggressive anti-virus
[13:21] <RenatoSilva> bzr-java-lib uses an XML-RPC server started with "bzr start-xmlrpc", then it sends commands to the server and reads the response. The tests work the same way
[13:22] <bialix> so you have 2 concurrent processes. race condition?
[13:23] <RenatoSilva> I'm currently running one specific test in Eclipse, and I'm catching the above error in procmon, it seems unreleased lock but has no sense (why? how? when? who? etc)
[13:23] <bialix> perhaps raised error
[13:24] <bialix> logs are you friends
[13:24] <RenatoSilva> bialix: I don't understand how my anti-virus would be causing this without notifying anything....
[13:25] <RenatoSilva> bialix: besides I tried disabling it...
[13:25] <bialix> anti-virus monitor can start reading/checking new files therefore effectively blocking file deletion
[13:25] <RenatoSilva> bialix: 2 processes? why? what processes?
[13:26] <bialix> XML-RPC server = 1st process, client = 2nd process, right&
[13:26] <bialix> XML-RPC server = 1st process, client = 2nd process, right?
[13:26] <RenatoSilva> bialix: but if I disabled the monitor for a while, it would stop monitoring and therefore stop blocking, however shutting down the anti-virus didn't work :(
[13:27] <bialix> that's bad if it won't help
[13:27] <RenatoSilva> bialix: client does not access the temp repo afaik, it only sends commands to xml-rpc server and handles response
[13:28] <bialix> do you have some pastebin to show?
[13:28] <RenatoSilva> I don't know if it serves as a clue, but during the test, procmon reports 3 executions of bzr.exe with different command lines, let me see
[13:29] <RenatoSilva> bialix: I can give you may pastebins, you just have to choose of what exactly :D
[13:29] <bialix> I have no idea about your code
[13:29] <bialix> why you need to run bzr.exe 3 times?
[13:30] <RenatoSilva> I'm just an user/contributor
[13:30]  * bialix is not user even
[13:31] <bialix> RenatoSilva: sometimes tests written in linux way, so it's hard to understand what's wrong
[13:32]  * bialix don't understand Java either
[13:32] <RenatoSilva> bialix: I don't --need-- 3 times, I've --found-- it
[13:33] <bialix> so maybe this is error?
[13:33] <bialix> sometimes one strange error masked actual error
[13:33] <RenatoSilva> I wonder if for any reason and somehow another bzr.exe tries to do something in the same branch
[13:34] <RenatoSilva> The question is why it was working perfectly a few days ago....
[13:34] <bialix> oh, my favorite question
[13:35] <RenatoSilva> anything that I've done of different I tried to revert back
[13:36] <RenatoSilva> I reverted windows back to a previous state, before insatlling AVG9 (over 8.5) and updating windows
[13:36] <RenatoSilva> I had problems with that, but after fixing them, I've got it wroking
[13:37] <RenatoSilva> then while I was here talking to verterok a thsi week, it stopped working again
[13:37] <RenatoSilva> the only thing I could figure out have done different was that I cancelled mvn test in cmd line, and that verterok pushed a new lib version to repo that was dowloaded
[13:38] <RenatoSilva> So I tried to change permisssions of mvn, c:/program files, ~, etc....
[13:38] <RenatoSilva> tried to reinstall bzr and mvn, tried many things...and nothing....
[13:39] <RenatoSilva> I even installed recent windows updates one by one, like one of them was causing this, but no
[13:40] <RenatoSilva> Therefore, I don't even know what action caused this starting to happen
[13:40] <bialix> sorry, it seems I can't help here
[13:40] <RenatoSilva> I'm looking for someone with mvn + winxp sp3 updated [+ avg9] to try at least reproduce the problem
[13:41] <RenatoSilva> is bzr.exe.Local a bzr stuff?
[13:47] <bialix> bzr.exe.Local? no
[13:55] <RenatoSilva> bialix: there are mainly 2 kind of errors that randomly happen, first one is access denied about the lock
[13:55] <RenatoSilva> bialix: not sure but seconde one seems to happen when first one passes
[13:55] <RenatoSilva> bialix: 2nd is  unknown command "C:\Arquivos de programas\Bazaar\bzr.exe"
[13:56] <RenatoSilva> which is absolutely non-sense, the file exists
[13:56] <bialix> do you have this file?
[13:56] <RenatoSilva> it's bzr!
[13:56] <bialix> yes, I see it's bzr
[13:57] <bialix> if this string process be something like shlex.split you'll have a problem
[13:57] <bialix> much better if there will be forward slashes using
[13:57] <RenatoSilva> I mean, it's the one that works all the time, and exists all the time, it can't say it's unkonw (and worse, tell that *sometimes*)
[13:58] <RenatoSilva> about the bzr.exe count, don't know the right order but they are "bzr xmlversion --short", "bzr xmlplugins", and "bzr start-xmlrpc"
[13:59] <RenatoSilva> verterok: ^^^ does this give you any clue?
[14:00] <RenatoSilva> god, fatal error in procmon itself o.O
[14:03] <verterok> RenatoSilva: hi
[14:04] <RenatoSilva> verterok: hi, good morning :)
[14:04] <verterok> RenatoSilva: bzr-java-lib need to check the if xmloutput is installed and the version, and after that it starts the xmlrpc service
[14:06] <RenatoSilva> verterok: I've sent you a few emails
[14:07] <verterok> RenatoSilva: yes, reading them ATM :)
[14:24] <verterok> RenatoSilva: I just finished a deploy of bzr-java-lib snapshot to the maven repository, the snapshot num. is: bzr-java-lib-0.5.3-20091116.142139-1
[14:26] <verterok> RenatoSilva: actually, the connection timedout..hang on :)
[14:27] <RenatoSilva> verterok: man, 0.5.3 is in sync with the code? I don't understand how can bzr-eclipse bundle not work, but when you get the source code, it does
[14:28] <RenatoSilva> verterok: I mentioned this file in email:  http://verterok.com.ar/maven-repo/org/vcs/bazaar/client/bzr-java-lib/0.5.3-SNAPSHOT/bzr-java-lib-0.5.3-SNAPSHOT-sources.jar,
[14:28] <verterok> RenatoSilva: probably because of how it's started when executed from inside eclipse
[14:28] <verterok> RenatoSilva: hmm, that file shouldn't exists in the repository...
[14:28] <RenatoSilva> verterok: that file is not the latest code, and its related binary is expected to not be either
[14:29] <verterok> RenatoSilva: I'll delete all -SNAPSHOTs files
[14:30] <RenatoSilva> verterok: so you mean these source jars are not generated by the same process than the one for the binary version?
[14:30] <verterok> RenatoSilva: maven deployed snapshots use a timestamp
[14:30] <verterok> RenatoSilva: yes, but I missed the source generation (an extra parameter to mvn :/)
[14:32] <verterok> RenatoSilva: remvoe all -SNAPSHOT from your local maven repo and run 'mvn compile' in bzr-eclipse again :)
[14:32] <RenatoSilva> verterok: about the xml enc detection, cat is not done through xmlrpc, right? but there's no detection involved right, because it's not xml...
[14:33] <verterok> RenatoSilva: right, there is no xml
[14:33] <RenatoSilva> verterok: source code is working, I don't use bzr-java-lib jars in it
[14:34] <RenatoSilva> verterok: ok so I think for cat we'll have no problem, need to check just if there's any xmloutput command that is not run with XMLRPCCommandRunner
[14:34] <verterok> RenatoSilva: xmlplugins & xmlversion for sure
[14:36] <RenatoSilva> hmmm ok...
[14:37] <verterok> RenatoSilva: is the xmloutput plugin installed in a path with non-ascii name?
[14:37] <verterok> RenatoSilva: or bzr itself?
[14:37] <RenatoSilva> no
[14:37] <RenatoSilva> just spaces
[14:38] <verterok> RenatoSilva: run xmlversion in a cmd.exe, probably the log file is in your user dir
[14:40] <verterok> RenatoSilva: is there any non-ascii path?
[14:40] <RenatoSilva> verterok: bzr log seems ok, no error
[14:40] <RenatoSilva> verterok: non-ascii path where? you're talking about which email specifically? :)
[14:40] <RenatoSilva> oh xmlversion? let me see
[14:41] <verterok> RenatoSilva: no email :) the output of xmlversion
[14:43] <RenatoSilva> humm no, it is ascii-only
[14:43] <verterok> RenatoSilva: and xmlplugins?
[14:44] <RenatoSilva> the output is bigger, not sure how to check it, looking....
[14:45] <RenatoSilva> seems ascii-only too
[15:36] <aguafuertes> Hi, is somebody here who has 5 minutes to explain some Bazaar concepts that I could not figure out by reading the documentation?
[15:36] <RenatoSilva> maybe
[15:37] <aguafuertes> :) great
[15:37] <RenatoSilva> I said maybe :)
[15:37] <aguafuertes> ;)
[15:37] <aguafuertes> I try to set up a branch that I want to work an with one colleguae
[15:37] <aguafuertes> we are a Windows environment, I'm the only Ubuntu user
[15:38] <aguafuertes> I installed an ssh server on my machine
[15:38] <aguafuertes> my colleague tries to branch my work, but always receives the error "bzr: ERROR: Not a branch:"
[15:39] <aguafuertes> interestingly, when branching directly in the file system, everything works fine
[15:39] <Peng> Your colleague has SSH access to your machine?
[15:39] <aguafuertes> yes, I set up an extra user for him
[15:40] <aguafuertes> interestingly, I can branch via the file system without problrm
[15:40] <Peng> Huh. Um. Note that bzr+ssh:// paths are relative to the root, not the user's home directory (though you can use ~ for that on recent versions. Probably.)
[15:40] <aguafuertes> mm, ok, that is a good hint
[15:40]  * Peng goes /away again
[15:40] <aguafuertes> I'll try that first
[15:43] <aguafuertes> Peng, thanks so much!
[15:43] <aguafuertes> that was it :)
[15:44] <Peng> Really? It was? I'm surprised. Well, I'm glad it's fixed. :)
[15:44] <aguafuertes> yes, I simply assumed that the it would be relative to the ssh user's login
[15:44] <aguafuertes> is that somewhere in the documentation?
[15:45] <aguafuertes> if not, maybe it can be added for people like me, coming from a web developer background
[15:45] <aguafuertes> were we deal more with document roots ;)
[15:46] <mgedmin> bzr 2.0.2 (karmic ppa) burns and crashes (TooManyConcurrentRequests) if I try to bzr pull over ssh from a server running bzr 1.13
[15:47] <Peng> TooManyConcurrentRequests: The most useless error message ever, aside from "Segmentation fault".
[15:48] <mgedmin> nah, segfault is very informative
[15:48] <mgedmin> TMCR is ... interesting
[15:54] <mgedmin> hm, maybe this is because I'm using a checkout
[15:54] <Peng> You're trying to "bzr pull" inside a checkout? Don't do that. Use "update".
[15:54] <Peng> Although it obviously shouldn't fail with such an error...
[15:54] <Peng> File a bug?
[15:55] <mgedmin> I don't want to update
[15:55] <mgedmin> I'm pulling from a different branch, not the one I'm bound to
[15:55] <mgedmin> bug filed here: https://bugs.launchpad.net/bzr/+bug/483661
[15:56] <mgedmin> "don't do that" sounds like something to suggest to people who say "I'm trying to use bazaar"
[15:56] <LarstiQ_> Peng: hmm, it's valid if you want to pull into the branch you're bound to
[15:56] <mgedmin> fwiw bzr pull over http worked fine
[15:56] <mgedmin> I wonder if pull over ssh would work if the two branches lived on different hosts
[15:57] <mgedmin> hm, bzr pull over ssh works now that there are no changes to pull
[15:57] <mgedmin> lemme update the bug
[16:01] <mgedmin> anyway, found a workaround (pull over http), got ideas for other workarounds (bzr unbind; bzr pull; bzr push; bzr bind), hope you get the bug fixed sooner or later
[16:01] <mgedmin> cheers!
[16:36] <jam> is there a losa about that can create a bzr-2.1 branch for me?
[16:36] <mthaddon> jam: sure
[16:36] <jam> basically, just "bzr branch lp:~bzr-pqm/bzr/bzr.dev lp:~bzr-pqm/bzr/2.1" should be sufficient.
[16:37] <jam> thanks mthaddon
[16:37] <mthaddon> jam: is there an RT for this, or could you give me a quick run down on why it's needed?
[16:37] <jam> and, of course, setting up pqm to allow access to that (if anything needs to be done there)
[16:37] <jam> mthaddon: No rt (yet), needed because I'll be releasing 2.1.0b3 ~ today
[16:38] <jam> I'm going to try to use a 2.1 branch rather than 2.1.0b3 so that we don't have to pester you every month
[16:45] <mthaddon> jam: ok, should be good to go
[16:50] <jam> mthaddon: thanks. I did end up sending an RT request
[16:51] <jam> #36509
[16:51] <jam> if you want to tick off that you already finished it
[16:51] <mthaddon> thx
[18:09] <maxb> Is there a shortcut way to deal with merge conflicts where both sides added the same file with the same text content independently?
[18:10] <jelmer_> maxb: not really, the two files will have different file ids
[18:10] <jelmer_> and there is no way to join file ids
[18:10] <maxb> ok.... I was hoping for a "bzr resolve --obvious" :-)
[18:12] <vila> maxb: bzr resolve <file> should do it
[18:13]  * Tak bzr resolve --duh
[18:15] <maxb> How do I ask bzr to show me the log of a file according to the merge-source branch?
[18:15] <dOxxx> maxb: have you tried using kdiff3 as an external merge tool?
[18:16]  * maxb tries installing
[18:16] <maxb> bzr log a-filename -r branch:../../the-merge-source  makes bzr crash :-/
[18:17] <dOxxx> maxb: make sure you have the extmerge plugin for bzr installed if you want to use kdiff3
[18:17] <dOxxx> maxb: try bzr log -n1 filename ?
[18:18] <maxb> bzr: ERROR: Path unknown at end or start of revision range: debian/patches/svn2cl-upstream
[18:18] <dOxxx> hmm that one's out of my league :)
[18:19] <dOxxx> maybe try bzr log filename --include-merges
[18:19] <maxb> Sorry, this is an uncommitted merge in progress
[18:20] <dOxxx> oh...
[18:21] <bialix> bzr qlog shows pending merges
[18:21] <dOxxx> I suspect there isn't really an easy way to do it other than constructing a URL to the file using the merge-source URL
[18:21] <dOxxx> I stand corrected.
[18:22]  * maxb tries that
[18:22] <maxb> also, what do I do when bzr erroneously decides a file is binary?
[18:30] <bialix> maxb: there is opposite problem
[18:38] <bialix> maxb: do you still compare bzr and hg?
[18:38] <maxb> Yes. We are currently doing "should we switch from svn and if so what?" at work
[18:41] <bialix> any results so far?
[18:41] <Meths> maxb: Is your choice between anything other than git, hg and bzr?
[18:42] <maxb> Well, I seem to be the only person with truly strong opinions, so I'm driving the whole thing
[18:42] <bialix> maxb: many people likes bzr-svn plugin to work directly with svn and to soften the transition
[18:44] <maxb> Meths: Not really - we acknowledge that other things exist, but we don't really have any knowledge of others in house, so it's tricky to evaluate anything else without a lot of effort
[18:44] <maxb> bialix: Sadly, bzr-svn gets really very slow when all your company's code resides in a single svn repository
[18:44] <maxb> Meths: Why, is there something else that we should keep on the table? :-)
[18:45] <bialix> understand
[18:47] <Meths> maxb: NAFAIK.  They seem to be the only sensible options going forward, similar command sets, private sector supporters, Internet project space...
[19:22] <jam> bialix, garyvdm: Hey guys, I'm getting ready to put together 2.1.0b3 and wanted to know what qbzr version to bundle
[19:28] <jam> mthaddon: I just tried to submit to 2.1.0 and it tells me I'm not authorized to commit to that branch
[19:28] <jam> it is http://bazaar.launchpad.net/~bzr-pqm/bzr/2.1.0 right?
[19:30] <dOxxx> looks like it's 2.1, not 2.1.0 ?
[19:33] <dOxxx> jam: bzr branch lp:bzr/2.1 works for me
[19:33] <jam> dOxxx: looks like you're right
[19:33] <jam> good enough I guess
[19:33] <jam> Probably the right thing anyway
[19:33] <jam> though I wish PQM's messages were better
[19:34] <jam> (not allowed to commit, versus branch doesn't exist)
[19:34] <dOxxx> I'm going by the Series 2.1 page on LP
[19:35] <dOxxx> it lists lp:bzr/2.1 as the branch
[19:35] <jam> dOxxx: yeah, and *I* just updated that :)
[19:35] <jam> just didn't notice the .0
[19:35] <jam> or lack thereof
[19:36] <jam> dOxxx: thanks for the pointer, it seems to be going now: http://pqm.bazaar-vcs.org/
[19:37] <dOxxx> cool :) I'm looking forward to being able to install 2.1.0b3 here so I can get the proxy fixes.
[19:45] <jam> dOxxx: well, those are also in 2.1.0b2 I believe
[19:45] <jam> and you only *need* 2.1.0b3 if you are running python2.4
[19:45] <dOxxx> jam: were there windows installers built for 2.1.0b2?
[19:45] <jam> yep
[19:46] <jam> not announced, but they are available
[19:46] <dOxxx> oh! I never saw them announced anywhere.
[19:46] <dOxxx> Where can I find them?
[19:46] <jam> I thought I would have 2.1.0b3 last Monday
[19:46] <jam> https://launchpad.net/bzr/2.1/2.1.0b2
[19:46] <jam> should have them
[19:46] <jam> though 2.1.0b3 will be out in the next day or two
[19:48] <dOxxx> I don't mind reinstalling ;)
[19:50] <KhaZ> Sorry if this is a basic question, but I just want confirmatino on what I'm about to do.  I've commited my 10th revision to a repository, but I'd like to temporarily bring my working tree back to revision 9.  Do I use bzr revert -R 9 to do this?
[19:51] <dOxxx> -r9
[19:51] <dOxxx> lowercase
[19:51] <KhaZ> OK, but revert doesn't actually force a commit, or revert in the repo or anything?
[19:53] <dOxxx> I believe so.
[19:53] <dOxxx> As I understand it, bazaar has a policy of not automatically committing changes.
[19:57] <KhaZ> Sweet.  The word 'revert' scares me.  :)  I'm used to Perforce lingo for syncing to a particular revision, so my first inclination was to bzr up, but that didn't seem to take a -r parameter.
[19:58] <dOxxx> yeah, that's update. I'm not actually sure when one would use update. checkouts?
[19:59] <KhaZ> I believe you use update when you want to pull chnages from the repo that someone has pushed
[20:01] <dOxxx> how does that differ from pull then?
[20:03] <Tak> update is for updating a working tree from the branch to which it's bound
[20:04] <Tak> pull is for pulling changes from one branch into another
[20:06] <dOxxx> bound is not the same as have a push branch set, right?
[20:07] <Tak> right
[20:07] <KhaZ> Stupid question, can I recursively revert somehow?
[20:08] <KhaZ> Oh, bzr revert * works for some reason, but I have to be down a level.  Weird.
[20:09] <Tak> doesn't `bzr revert` with no arguments do that?
[20:11] <KhaZ> I haven't the foggiest.  I'll try it out next time I need to do that. ;)
[20:11] <KhaZ> I wonder if that works with bzr add as well
[20:11] <KhaZ> I find bzr add * is nice to recursively add files, but it doesn't seem to respect files that are in bzr ignore
[20:12] <KhaZ> Maybe bzr add will respect that.. Hrmm.
[20:26] <jam> KhaZ: if you explicitly name a file with "*" then add will always add it
[20:26] <jam> bzr add .
[20:26] <jam> or bzr add
[20:26] <jam> will recurse from current dir down, or everything respectively
[20:26] <jam> respecting ignores
[20:26] <KhaZ> Ah, awesome.  SO bzr add or bzr add . will respect the ignore list?
[20:26] <jam> and yes "bzr revert" no args should revert the whole tree
[20:26] <jam> KhaZ: yes
[20:26] <KhaZ> Yeah, I figured bzr add * would not respect the ignore list, since technically I"m explicitly saying "add this!".
[20:26] <KhaZ> Awesome.  Good to hear.
[20:27] <dave_> I have a problem where I installed bzr on a windows comp and put some things under bzr, then the comp crashed. I can access the drive from linux, is there a way to get at those files?
[20:28] <jam> dave_: well, if you can get access to the drive, then generally you'll have access to the .bzr directory
[20:28] <jam> and you can "bzr branch /path/to/win32/"
[20:28] <jam> etc
[20:28] <dave_> and the .bzr directory isn't in the root directory, though, yes?
[20:30] <dave_> well, thanks
[20:32] <stuartpb> Uh, how am I supposed to install Bazaar on Slackware?
[20:33] <dOxxx> stuartpb: download the source distribution and 'python setup.py install' I think?
[20:34] <bialix> hi jam: please use qbzr 0.16 for 2.1.0b3
[20:34] <jam> bialix: sure
[20:34] <bialix> you're asked, me answered
[20:35] <bialix> gnight
[20:35] <dOxxx> I just got a very odd error when pushing to lp:
[20:36] <dOxxx> http://pastebin.com/m23fbb00c
[20:37] <dOxxx> when creating a local branch of bzrtools, I created it in a 2a shared repository
[20:37] <dOxxx> I guess bzrtools is not a 2a format branch and so stacking on it doesn't work?
[20:43] <jam> dOxxx: right, though if you do "bzr push -r -1" again it will push without stacking
[20:44] <jam> probably more accidentally than anything, but it should work
[20:44] <dOxxx> I'm trying to recreate my feature branch with the correct format
[20:45] <jam> I think bzrtools is in 1.9-rich-root, which means it should be able to merge any changes from a 2a format repo
[20:55] <dOxxx> yup, success :)
[20:56] <dOxxx> lp:~doxxx/bzrtools/shell-dir
[20:56] <fullermd> jam: Hey, I've got a Q or two...
[20:57] <jam> fullermd: QQ ?
[20:58] <fullermd> Nono, that's perl   8-}
[20:58] <jam> more pew-pew, less QQ fullermd
[20:58] <fullermd> Somewhat re that merge thing.  I was under the impression that when we merge3 on a criss-cross, it bleats at you and tells you to lca or weave.
[20:58] <jam> not exactly
[20:58] <jam> it still tries merge3
[20:58] <jam> it just bleats at you
[20:58] <jam> however, for the tree-shape info, etc
[20:59] <jam> we still use a common base
[20:59] <fullermd> But when I use -r0..-1 to force that merge to go through, it doesn't.  Is that because I explicitly -r'd, or because of the null LCA in that case, or something else?
[20:59] <jam> fullermd: you actually want "-r1..-1"
[20:59] <jam> but it doesn't bleat when you supply a base
[20:59] <jam> because it doesn't search for one
[20:59] <jam> yes
[21:00] <fullermd> Ah.  Should it?  In the real case, the criss-cross caused a lot of really ugly spurious conflicts.
[21:00] <fullermd> (using weave left it with 2 real ones)
[21:00] <jam> fullermd: so if you used "-r 1..-1" I would expect fewer conflicts
[21:00] <jam> though possibly you'd still end up with a bunch from side-2
[21:00] <fullermd> That wouldn't work in the real case, because r1 on both sides are totally unrelated.
[21:01] <jam> fullermd: sure, but supplying 0 is probably saying also look at all the changes from this side
[21:01] <jam> at least 1 skips that initial import
[21:01] <jam> anyway, only --weave and possibly --lca will work in this case
[21:01] <jam> since there is clearly no "clean" base
[21:02] <jam> fullermd: in case you didn't get my joke: http://www.urbandictionary.com/define.php?term=less%20qq%20more%20pew%20pew
[21:03] <fullermd> Anyway.  *I* know that, because I know (or would have known had I pondered it) that it was a criss-cross.
[21:03] <fullermd> It feels like bzr probably should have known to prompt me, though.
[21:03] <jam> well, it did warn you :)
[21:03] <jam> I've really wanted to get merge3 to use per-file merge bases
[21:03] <jam> which might get you out of this as well
[21:04] <jam> if the code bases were truly disjoint
[21:04] <fullermd> Not as such, it just dumped me a big pile of conflicts...
[21:04] <jam> ENOTUITS
[21:04] <fullermd> Actually, I thought the plan was just to make lca the default.  Did that just fall in the tuit hole, or are there reasons not to?
[21:04] <jam> well, if you specifically request -r0 we'll give you -r0
[21:04] <jam> at *this* point, *I* prefer --weave to --lca
[21:04] <jam> but I worked on --weave
[21:04] <jam> abentley worked on lca
[21:05] <jam> We've talked about changing
[21:05] <jam> but people also like getting .THIS .OTHER .BASE files
[21:05] <jam> which is why people like mysql use --merge3 most of the time
[21:05] <fullermd> Going back and retrying the real branches with 1..-1 instead of 0..-1 doesn't make any visible difference on the conflicts.
[21:06] <fullermd> 8 conflicts encountered.   one way and   20 conflicts encountered.  the other.
[21:07] <fullermd> (and actually, I think one of the real ones is spurious, but I s'pose it's possible bzr can't really tell.  1 of them is real.)
[21:07] <fullermd> Anyway.
[21:08] <fullermd> I also got an eye-twitch at that btree padding change.  Could that trip up pre-2.1 versions?
[21:08] <jam> fullermd: shouldn't
[21:08] <jam> we never read those bytes
[21:08] <fullermd> (I have no reason necessarily to believe it does, it just caught my eye as something that played in that court)
[21:09] <jam> we allow a single page to be <4096 bytes
[21:09] <jam> we reserve 120 bytes at the start
[21:09] <jam> but if it is less than that
[21:09] <jam> we write the info right away
[21:09] <jam> and pad at the end to make up the loss
[21:09] <jam> and generally we just throw away those bytes anyway
[21:10] <jam> so the change was to just not write the
[21:10] <jam> them
[21:12] <fullermd> Good 'nuff for me.
[21:12] <fullermd> Danke.
[21:13] <jam> fullermd: any more Q.Q ?
[21:13] <jam> or :,( :)
[21:13] <jam> :'( I mean
[21:14] <fullermd> Well, I'm massively piled up and way behind at work.  Does that count?
[21:14] <fullermd> But I'm hopeful that if I can get a good long day in today, I can take care of the stuff we need for the Oct 30 deadline and start looking at what we need for the Nov 16 one...
[21:14] <jam> fullermd: could you put that in the form of a QQ?
[21:15] <jam> fullermd: so only 2 weeks behind?
[21:15] <jam> I've certainly been far worse than that
[21:15] <fullermd> Well, so far...
[21:16] <fullermd> We've still got almost a month until the hard deadline when the whole thing has to be done.
[21:27] <lifeless> fullermd: what are you working on?
[21:32] <jam> morning li
[21:32] <jam> lifeless:
[21:32] <jam> ^^
[21:33] <fullermd> Oh, it's just $CURRENT_PROJECT.  The client has their big annual convention thingy in December, and we're supposed to have this all ready for them to show off then.
[21:33]  * fullermd is losing optimism.
[21:33] <vila> fullermd: yeah, next time I have to debug some ntp stuff, I'll be sure to not ask you (two weeks... and you were criticizing my VMs getting some *hour* skew... sheesh)
[21:34] <vila> :-p
[21:34]  * vila refocus on the session :)
[21:34] <fullermd> Hey, *I* know what time it is.  's not my fault my clients are getting ahead   :P
[21:34] <kfogel> is there any documentation on tags in bzr?  Google turns up pages about their existence, but http://doc.bazaar-vcs.org/latest/en/search.html?q=tags gives pretty thin results...
[21:38] <lifeless> kfogel: bzr help tag
[22:54] <spiv> Good morning.
[23:01] <igc> morning
[23:05] <lifeless> aloha
[23:10] <spiv> Hey wow, a bug report about TooManyConcurrentRequests that's actually due to bzr attempting to make concurrent requests on an HPSS connection.
[23:18] <Peng> ...Wow.
[23:19] <Peng> And I joked about that bug this morning. Whoops.
[23:31] <poolie1> biab
[23:31] <poolie1> hello jam, vila
[23:43]  * spiv boggles as a bug search for "hpss upgrade" fails to find a bug with tags of "hpss" and "upgrade"
[23:43] <fullermd> jam: (btw, looking back at it, merge -r1..-1 would have been a really bad idea, since it's a cherry pick)
[23:43] <spiv> Or any bugs, in fact.
[23:43] <fullermd> Hey, cool, that means the hpss upgrade is perfect!
[23:44] <spiv> fullermd: 107173 disagrees :P
[23:44] <fullermd> Pfft.  Who you wanna believe, 107173 or LP?
[23:49] <dOxxx> spiv: going through bzr merge proposals?
[23:54] <spiv> dOxxx: yup
[23:54] <dOxxx> must be a pile of work
[23:54] <spiv> Yeah, but we get bug fixes and other improvements out of it :)
[23:55] <spiv> Which is going to be work one way or another ;)
[23:55] <dOxxx> yep
[23:56] <poolie> hi spiv
[23:57] <poolie> spiv, it might be good to send a brief reply to the pilot thread just saying you're doing it and how it's going
[23:59] <spiv> Yeah, that's a good idea.  Although I did just send a similar mail in reply to a related thread.
[23:59] <poolie> i saw
[23:59] <poolie> but people don't read all mail
[23:59] <poolie> sending _more_ mail is a questionable fix :-) but i think worthwhile here
[23:59] <spiv> :)