[01:51] <poolie> hi spiv
[01:52] <lifeless> ok, losa ping - again, sorry for the noisiness of this; there is something odd/wrong
[01:53] <spiv> Morning poolie.
[01:54] <poolie> thanks for the stacking fix
[01:55] <poolie> there are some more similar ones if you're keen
[01:55] <poolie> probably currently untargeted but i would not object to fixing them
[01:56] <spiv> Any specific ones in mind?  There are quite a few with the 'stacking' tag!
[01:57] <poolie> nothing specific sorry
[01:57] <poolie> what did you have in mind to chase next?
[02:07] <lifeless> poolie: shout when you have a minute (loom-diff topic)
[02:15] <spiv> poolie: submitting my bzr and bzr-builder branches to support the 'take just debian/ dir from a parallel import' case.  I have complete patches for both, but based on discussion on the list I think I'll leave out any CLI for it in the initial bzr patch.
[02:22] <spiv> poolie: that said, one of the other High stacking bugs looks fairly straightforward, so I'll queue that up to tackle too
[02:22] <spiv> (https://bugs.edge.launchpad.net/bzr/+bug/551525)
[03:13] <poolie> spiv that would be nice, you could target that
[04:34] <bendj> I'm building 2.2b3.  On x86m builds & installs just fine.  On a similarly configured x86_64 box, however, it reports an "internal error": http://pastebin.com/8UK28NnA
[04:35] <bendj> Before I report a bug -- does that, in fact, look like a bazaar issue, or likely something in my env?
[04:35] <bendj> I ask cuz of the different behavior on different arch ...
[04:35] <lifeless> its a bit hard to tell
[04:37] <lifeless> that means that trace._bzr_log_filename is None
[04:38] <lifeless> do you have logging disabled or something, perhaps ?
[04:39] <bendj> lifeless: Nope.  Was working ... at least before this build attempt.
[04:39] <bendj> nothing _should_ be significantly different abt this x86_64 box :-/
[04:41] <bendj> lifeless: aha.  well, sort of ... if I manually "rm /usr/local/bin/bzr" the previously installed bzr, then re- "python setup.py install", no more error.
[04:41] <bendj> shouldn't an install overwrite a preexisting bin?
[04:42] <lifeless> bendj: only if its installing to the same place
[04:42] <bendj> lifeless: it is ...
[04:42] <bendj> interesting tried it on 3 x86_64 boxes, same behavior.  on x86 boxes, no req't to PRE-delete the nimady
[04:42] <lifeless> e
[04:42] <bendj> aghh! binary
[04:43] <bendj> (nimady? jeesh ...)
[04:43] <lifeless> nomstu surely ?
[04:44] <bendj> heh ... smart___ ;-)
[04:45] <bendj> easy enuf -- added to my notes.  thx!
[05:17] <AfC> If I want to get the branch of an Ubuntu package [presumably from Launchpad] (as opposed to an upstream hosted on Launchpad), is there a special command or URL to use?
[05:22] <spiv> IIRC, lp:ubuntu/src-package-name (or e.g. lp:ubuntu/maverick/src-package-name to explicitly get the maverick version)
[05:28]  * AfC tries that
[05:30] <AfC> spiv: yes,
[05:30] <AfC> $ bzr branch lp:ubuntu/bc
[05:30] <AfC> spiv: worked.
[05:31] <AfC> Kind of a shame that all the revisions show as being made by Bazaar Package Importer <james.westby@ubuntu.com> instead of whomever the original committer in Debian or Ubuntu was.
[05:32] <poolie> hi afc
[05:32] <AfC> poolie: hello Martin, nice to see you
[05:32] <poolie> you too
[05:50] <lifeless> AfC: I think it sets author now
[05:50] <lifeless> AfC: so log can show it
[05:50] <AfC> oh.
[05:51] <AfC> so does that mean those branches will be superseded with new ones?
[05:51] <AfC> lifeless: ^
[05:51] <lifeless> maybe someday
[05:51] <lifeless> magic 8 ball says 'drink some beer'
[05:51] <AfC> lifeless: cool!
[05:52] <AfC> No, that was "cool that the bzr branches will be fixed", not "cool that you're drinking and we
[05:52] <AfC> are not" :)
[05:56] <lifeless> AfC: actually I'm working @ poolies today
[06:13] <AfC> lifeless: still, though, all in all the "go drink beer" meme is a good one. I think we might take your advice.
[06:14] <lifeless> AfC: be my guest :)
 I'm building 2.2b3.  On x86m builds & installs just fine.  On a similarly configured x86_64 box, however, it reports an "internal error": http://pastebin.com/8UK28NnA
[06:17] <mgz> ^I actually get some test failures like that in my setup, because I don't init logging
[06:18] <mgz> really that line shouldn't assume that trace._bzr_log_filename is a string
[06:19] <poolie> spiv, lifeless, did one of you mention an updated network delay simulator?
[06:22] <parthm> looks like an interesting ssl bug got fixed upstream in python http://bugs.python.org/issue9075 ... was posted on reddit.
[06:25] <spiv> poolie: I don't think that would have been me.
[06:30] <lifeless> mgz: I'm in that area now, I'll do something to it (stabby stabby)
[06:31] <poolie> i'm trying to reproduce bug 590638 between here and chinstrap
[06:31] <poolie> as another machine on a similar network
[06:31] <poolie> unfortunately it's only sending fairly large stream parts
[06:31] <poolie> so the effect is not very obvious
[06:35] <mgz> lifeless: cool
[06:35] <mgz> now I need to stop playing and pack my things
[06:39] <spiv> poolie: IIRC, igc saw a variety of large and small stream parts when fetching lp:launchpad, perhaps try using that as the data?
[06:56] <vila> poolie: There is SocketDelay in stub_sftp..
[06:56]  * vila not fully here yet
[06:57] <vila> poolie: but a vm sounds like an easier way to truly simulate that (ymmv, etc)
[07:20] <poolie> spiv, i think when i branched from lp to chinstrap it probably got repacked into something less fragmented?
[07:23] <lifeless> yes
[07:23] <lifeless> it will be optimus prime now
[07:24] <vila> hi all
[07:27] <spiv> poolie: hmm, I guess you could grab the files via sftp.
[08:05] <sebi_`> I accidently added .git/ to my branch with "bzr add .", but after "bzr remove .git", bzr actually erased the *physical* location.. what's the deal with that?
[08:06] <sebi_`> er, bzr rm .git
[08:06] <spiv> 'bzr revert .git; bzr rm --keep .git'
[08:07] <sebi_`> I just wanted to remove it from my branch ):
[08:07] <sebi_`> bzr revert .git brought at least .git back, thanks
[08:07] <spiv> 'bzr rm FOO' will automatically delete FOO if it is safe to do so, i.e. if the file(s) to delete were committed and unchanged, because when people 'rm' things they usually want them removed completely :)
[08:08] <spiv> If you'd never committed the .git directory, then 'bzr rm' would have defaulted to 'bzr rm --keep'
[08:08] <sebi_`> true, but git rmtree $path only removes the data from the branch, if it has been accidently pushed
[08:08] <sebi_`> I didn't commit yet
[08:09] <sebi_`> okay, well, time to study the docs again, I guess :P
[08:09] <sebi_`> also, are comments allowed in the .bzrignore?
[08:09] <spiv> 'bzr revert' reverts to the last committed state... so if 'bzr revert' brought it back, you must have committed it.
[08:09] <sebi_`> errr yeah. commited, but not pushed
[08:10] <spiv> Leading #, I think.
[08:10] <sebi_`> okay
[08:11] <spiv> Depending on how recently you accidentally committed that directory, you might find 'bzr uncommit' helpful.
[08:14] <sebi_`> it looks like no sensitive data has been added, so I guess it's fine
[08:37] <poolie> hi there vila
[08:38] <vila> hey poolie
[08:39] <poolie> hi spiv, vila
[08:39] <poolie> for reasons i'm about to post to bug 582157, i couldn't prove that flushing the hpss stream more often makes things faster
[08:39] <poolie> but i'm still pretty sure it will help in some cases
[08:39] <vila> :)
[08:40] <poolie> so i think i'll send it up anyhow
[08:40] <vila> when have no scientific proof, trust the experts :)
[08:40] <vila> s/have/you have/, typos....
[08:41] <poolie> :)
[08:41] <spiv> poolie: My suspicion is it will help a small amount.  I certainly don't expect it to hurt, at least not for the uses we currently use body streams for.
[08:41] <spiv> poolie: so, your inconclusive results match my expectations :)
[08:41] <poolie> me too
[08:42] <poolie> i had to adjust or cut a couple of tests about how many flushes there were
[08:42] <poolie> i hit https://bugs.edge.launchpad.net/tribunal/+bug/598348
[08:42] <poolie> when they fail they print the whole 1.5MB stream :)
[08:42] <spiv> Heh.
[08:42] <poolie> though it is nice the test is there
[08:58] <GaryvdM> Hi all
[09:02] <vila> hey GaryvdM !
[09:02] <GaryvdM> Hi vila
[09:19] <GaryvdM> Does use of ctypes reduce portability?
[09:35] <poolie> GaryvdM: it depends what you do with it :)
[09:36] <poolie> not necessarily
[09:36] <GaryvdM> Hi poolie!
[09:36] <GaryvdM> poolie: http://code.activestate.com/recipes/496960-thread2-killable-threads/
[09:37] <poolie> wow
[09:39] <poolie> ok, good night all
[09:39] <lifeless> gnight
[09:39] <lifeless> btw
[09:39] <lifeless> paste
[09:39] <lifeless> loggerheads web engine
[09:39] <lifeless> has that code already
[09:39] <GaryvdM> night poolie
[09:39] <poolie> lifeless: which bit? thread killing?
[09:40] <lifeless> yes
[09:41] <GaryvdM> Ok - I feel better about using it then.
[09:41] <poolie> in qbzr?
[09:41] <GaryvdM> Yes
[09:50] <C-Keen> Hi! I am comming from darcs and hg/git and I was wondering if I am expecting the wrong thing here: if I do a merge from a remote branch to my own, should I see the other branche's commits in history?
[09:55] <poolie> C-Keen: yes, use 'log -n0'
[09:57] <C-Keen> poolie: that's cool! thanks!
[09:57] <C-Keen> I like how bazaar handles history!
[09:59] <C-Keen> poolie: another question. Can I tell bzr to commit merges if my tip does not diverge?
[10:06] <jelmer> C-Keen: you would probably want to use 'bzr pull' in that case rather than merge
[10:07] <C-Keen> ah ok
[10:38] <GaryvdM> C-Keen:  bzr merge --pull . That will pull if the branches have not merged, and will merge if they have.
[10:38] <GaryvdM> *have not diverged
[10:39] <C-Keen> ah!
[10:46] <GaryvdM> Offtopic question, but it is for qbzr dev:
[10:47] <GaryvdM> Is there a way to tell grep to use single line mode.
[10:47] <GaryvdM> i.e. "." should include \n
[10:47] <GaryvdM> I've read man grep about 3 times and I can't see anything.
[10:48] <Kinnison> grep explicitly operates on lines
[10:48] <GaryvdM> I want to find:  lazy_import.*'''.*bzrlib\.plugins\.qbzr\.lib\.trace.*'''
[10:48] <Kinnison> you can tell by the "...for lines containing a match..." in the first paragraph of the description.
[10:50] <GaryvdM> Is there maybe an alternative to grep that can do that?
[10:53]  * GaryvdM looks if he can use ack...
[10:55] <spiv> Kinnison: I think by "single line" GaryvdM means "as if entire file were a single line", perhaps, so he can search for patterns that span \n.  I'd probably call that "multi-line matching" myself.
[10:56] <spiv> GaryvdM: i.e. you're looking for the equivalent of re.DOTALL in Python's re module?
[10:57] <Kinnison> spiv: yeah, grep doesn't do that
[10:58] <GaryvdM> spiv: yes - re.DOTALL is what I need
[10:59] <GaryvdM> spiv: and that is the same as re.S which in refered to as single line mode in some places.
[10:59] <GaryvdM> http://blog.stevenlevithan.com/archives/singleline-multiline-confusing
[10:59] <GaryvdM> So confusing...
[13:00] <vila> jelmer: ping
[13:41] <vila> jelmer: Ping
[13:46] <jelmer> vila: pong
[15:04] <vila> losa: regarding bug #525571, do you still have some corrupted subversion.conf file around ?
[15:05] <mthaddon> vila: not that I'm aware of
[15:05] <exarkun> doesn't the ticket description describe how to produce one?
[15:05] <exarkun> (and also include one?)
[15:06] <vila> exarkun: there is one mentioned in the bug description but I wonder if it is complete...
[15:07] <exarkun> vila: I'm the reporter.  It is.
[15:07] <vila> exarkun: good to know !
[15:08] <vila> that's very weird that configobj created an *empty* section with the name of an existing one...
[15:09] <vila> I can't imagine  scenario (even with two processes writing to the same file) that could give such a result,
[15:09] <exarkun> Hm yea, that's interesting.
[15:10] <vila> the whole section duplicated, I can, with some efforts :), imagine that both were trying to create the same content, but an empty one...
[18:56] <evanton> is there a tool that would allow me to import revisions from a bzr repo into a subdirectory of another bzr repo? My final goal is to join a lot of small bzr repos into one, where each small repo will be a directory in the big repo
[18:57] <evanton> basically I want to give as arguments small repo location, new big repo location, directory name and let the tool pull revisions one by one and add them to the custom directory in the big repo
[19:09] <beuno> evanton, so, the opposite of that would be to use "bzr split", which I think is in bzrtools
[19:10] <beuno> I'd expect there to be an equivalent
[19:11] <fullermd> It's in base, not bzrtools.
[19:11] <fullermd> And the command is 'join'.
[19:11] <fullermd> It's essential the equivalent of merge + move the root of the merged tree.
[19:23] <beuno> I am so outdated...
[20:05] <jmlxx> Hi All!
[20:06] <jmlxx> anybody have any info/insight as to why Bazaar Explorer wont launch on Win7 x86 platform?
[20:06] <jmlxx> using the default settings during install, i get an error when trying to launch the program "Unable to execute file: BZR - Create Process failed; code 2, The system cannot find the specified file"
[20:09] <jmlxx> anyone??
[20:51] <VSpike> heya. bzr just threw and exception on me during a push by sftp.  The last line (more or less) was SSHException: Server connection dropped:
[20:52] <VSpike> It asks me to file a bug report, but it seems to me that this is probably normal?
[20:53] <VSpike> ALso, what's the best way to recover? Just bzr break-lock and repeat the push?
[20:56] <lifeless> VSpike: yes
[20:57] <lifeless> VSpike: uhm sounds like an error case we aren't explicitly handling yet - could you please file that bug, we'll make it prettier when it happens.
[20:57] <VSpike> okie doke
[20:57] <VSpike> does that answer still apply if I mention I'm running the cygwin version? ;)
[20:57] <lifeless> yes
[21:01] <VSpike> Looks like Bug #386036 to me
[21:03] <lifeless> wah yes
[21:03] <lifeless> you could me-too it
[21:04] <VSpike> Done :)
[21:50] <VSpike> http://pastebin.com/Zm9D0Umg
[21:50] <VSpike> Any ideas what to do about this error?
[22:34] <VSpike> Hmm keep getting same error (apart from file names) when I repeat the attempt
[22:40] <maxb> VSpike: about the only thing I can think to check is file permissions on the repository
[22:45] <VSpike> maxb: the permissions look ok.  I can see the files in /.bzr/repository/upload that are still there.  Interestingly, the destination file that it wants to rename to in ../packs/ already exists
[22:45] <VSpike> perhaps that's why it cant rename the file?
[22:48] <maxb> sounds entirely plausible
[23:25] <VSpike> Aha. Bug 516179