[00:03] <poolie> james_w: guess you're not around?
[00:03] <poolie> spiv, hi?
[00:03] <dOxxx> hey poolie
[00:05] <spiv> poolie: hey
[00:06] <spiv> poolie: I was thinking about the latest ObjectNotLocked bug (this time in cmd_annotate)
[00:06] <poolie> we should have a chat - now if you like, but i might get some coffee first
[00:08] <spiv> poolie: now or post-coffee are both fine
[00:09] <spiv> I already have one ;)
[00:09] <fullermd> I find the phrase "post-coffee" so misleading.  It implies that there's such a thing as "pre-coffee".
[00:09] <fullermd> That's like "what happened before time began?"
[00:15] <spm> fullermd: +11111
[00:20] <dOxxx> What version of pycrypto should we be using for bzr 2.0.3 and 2.1.0b4?
[00:20] <dOxxx> Or rather, what should I be packaging in the Mac installers?
[00:20] <poolie> k
[00:21] <james_w> hi poolie
[00:21] <james_w> I am now
[00:21] <poolie> hi
[00:21] <poolie> do you want to talk now, or some other time?
[00:23] <james_w> let's do it now
[00:23] <james_w> save us missing each other again
[00:27] <poolie> k
[00:32] <jelmer> poolie, hi
[00:33] <jelmer> poolie: you just changed the product of bug 496827 back to bzr, was that intentional?
[00:33] <poolie> it was accidental
[00:34] <poolie> now it won't let me change it back
[00:34] <jelmer> ah, probably because you're not in the bug maintainers group for bzr-svn?
[00:34] <jelmer> I've changed it back
[00:57] <poolie> james_w: http://bazaar-vcs.org/Roadmap
[01:23] <Jordan_U> bzr branch with bzr+ssh is currently using 270m of ram on the server side, is this normal?
[01:24] <spiv> For large enough branches, yes, unfortunately.
[01:24] <spiv> 2.1.0b4 should be a little bit better than 2.0.x on memory consumption, but we still use more than we'd like.
[01:25] <spiv> Oh, and doing cross-format fetches tends to consume more memory too (as well as being slower), so upgrade everything to 2a if you haven't already ;)
[01:25] <Jordan_U> That is unfortunate, it's already triggered the OOM killer twice and is making my computer ( "server" and desktop are the same machine ) unusable
[01:26] <Jordan_U> irssi is about the only usable application right now :)
[01:26] <spiv> You can do "bzr branch -r 1000 bzr+ssh://.... foo; cd foo; bzr pull -r 2000; bzr pull -r 3000; ..." etc if necessary.
[01:26] <spiv> Or maybe even smaller increments.
[01:27] <Jordan_U> I assume that also means that subsiquent pulls should reasonable wrt memory usage?
[01:28] <Jordan_U> *should be
[01:29] <spiv> Right, the memory usage is roughly proportional to how much (revisions, file deltas, etc) is being transferred.
[01:29] <Jordan_U> spiv: Thanks
[01:29] <spiv> So incremental pulls of the last few revisions new this week will need much less memory than branching the whole thing.
[01:33] <poolie> spiv: finished on phone, writing up a mail
[02:32] <spiv> poolie: I'm going to grab lunch now; how about I ping you after?
[02:59] <maxb> Is it possible to invoke a command from bzrlib.builtins directly from a python script?
[03:05] <maxb> ..and still get a progress bar?
[03:12] <poolie> maxb: yes
[03:12] <poolie> maxb: to get a progress bar you just need to set up a uifactory
[03:12] <poolie> there is a function to help you do it
[03:14] <maxb> make_ui_for_terminal ?
[03:15] <poolie> right
[03:15] <maxb> thanks :-)
[03:15] <poolie> spiv, sorry, back now
[03:32] <poolie> bzr still seems to use pycurl for me
[03:32] <poolie> i thought we were going to change to urllib2?
[03:40] <jml> is there a doc / guide on how to maintain a friendly fork with Bazaar
[03:42] <gutworth> is there demand for that?
[03:47] <spiv> poolie: ok
[03:48] <spiv> poolie: shall I call?
[03:51] <poolie> spiv, yes, thanks
[04:07] <mwhudson> jml: gtg again?
[04:07] <jml> mwhudson, maaybe.
[04:07] <jml> gutworth, well, I guess I count as demand.
[04:07] <jml> I'm thinking that looms would be a good fit, actually.
[04:14] <dOxxx1> uploading mac installer for bzr 2.1.0b4 :)
[04:20]  * fullermd is so happy to have DWIM revspecs...
[04:23] <jfroy|work> jelmer: just hit an assertion in bzr-svn's mergeinfo parser, reported in https://bugs.launchpad.net/bzr-svn/+bug/497280; hope it's not going to be too severe to fix :/
[04:25] <poolie> omg
[04:26] <poolie> is random sniping really _that_ much more fun than writing code?
[04:26] <poolie> ...
[04:26] <jfroy|work> poolie: was that directed at me?
[04:26] <poolie> not at all
[04:27] <poolie> someone else (guess)
[04:27] <poolie> not in this channel
[04:27]  * poolie muffles himself
[04:27] <jfroy|work> I'm confused
[04:27] <jfroy|work> :/
[04:27] <lifeless> poolie: I think you're turning japanese?
[04:27] <poolie> seriously, no offense intended
[04:27] <poolie> just offtopic venting
[04:27] <jfroy|work> none taken, I would write a patch if I had time!
[04:28] <jfroy|work> I se
[04:28] <fullermd> If it's not in this channel, it doesn't really exist, does it?   :p
[04:28] <jfroy|work> *see
[04:28] <poolie> hello lifeless
[04:28] <jfroy|work> fullermd: bzrgotism?
[04:29] <mwhudson> poolie: for some people, it certainly seems that it is
[04:29] <cellofellow> is there an easy way to access a SourceForge CVS project with bzr?
[04:29] <dOxxx1> lifeless/poolie: I'm running bzr selftest --subunit from lifeless' subunit branch on Vista at the moment.
[04:30] <lifeless> cellofellow: not really
[04:30] <fullermd> jfroy|work: If you can get it declared a religion, it's tax-deductible.
[04:30] <lifeless> dOxxx: thank you for that
[04:31] <cellofellow> bzr-cvsps-import or bzr-fastimport seem close. I don't have commit access to the repo and it isn't very active.
[04:31] <dOxxx> lifeless: you're welcome. seems to be working okay so far. I find subunit output rather hard to read though. I must see if I can get the filters working.
[04:31] <lifeless> dOxxx: the patch doesn't require subunit output :) - just run as normal.
[04:31] <mwhudson> cellofellow: if you can download the cvs repo, you can use fastimport
[04:31] <dOxxx> lifeless: so I didn't need to run with --subunit?
[04:32] <lifeless> dOxxx: if you put the filters on your path (set PATH=%PATH%c:\src\subunit\filters) then you should be able to use them.
[04:32] <mwhudson> cellofellow: otherwise you can request an import on launchpad
[04:32] <lifeless> dOxxx: indeed :)
[04:32] <lifeless> dOxxx: for most people subunit streams will be an implementation detail they rarely need to look at.
[04:32] <dOxxx> lifeless: Okay. So I guess I should try --parallel next.
[04:33] <cellofellow> ok
[04:33] <lifeless> dOxxx: you need --parallel=subprocess on win32
[04:33] <dOxxx> yeah
[04:36] <lifeless> hi poolie
[04:36] <dOxxx> lifeless: with --parallel=subprocess, it looks like I'm getting mixed CRLF and LF in the stdout
[04:36] <lifeless> dOxxx: what command line did you use?
[04:37] <dOxxx> lifeless: bzr selftest --parallel=subprocess > tests.out 2> tests.err
[04:37] <lifeless> I wouldn't redirect it
[04:37] <lifeless> as it will be doing the fancy bzr progress bar
[04:37] <dOxxx> lifeless: ah yes, you're right
[04:38] <dOxxx> lifeless: actually, no... I'm getting a lot of spewage
[04:38] <dOxxx> lifeless: looks like multiple threads writing to stdout concurrently
[04:39] <dOxxx> lifeless: no progress bar that I can see
[04:39] <dOxxx> lifeless: in fact I see output very similar to --subunit
[04:39] <dOxxx> lifeless: albeit garbled
[04:39] <lifeless> ok, thats not the goal :)
[04:39] <lifeless> someone recently had a patch to make --parallel=subprocess work at all on win32; but it should be merged.
[04:41] <dOxxx> lifeless: should I try merging trunk into this branch?
[04:42] <spiv> poolie: btw, the 405 is apparently from .bzr/branch-format, not .bzr/smart, even so treating it more like a 404 does seem more useful in practice.
[04:43] <poolie> i know
[04:43] <lifeless> dOxxx: I've merged trunk already
[04:43] <poolie> hello lifeless!
[04:43] <poolie> spiv, i was going to try TransportNotPossible
[04:43] <lifeless> hello poolie!
[04:43] <poolie> it's just possible it'll come up in other places
[04:44] <dOxxx> in other news, I really need to improve the mac build process so that it checks for missing tarballs *first*
[04:44] <dOxxx> waiting 20 minutes while it builds only to discover that I typo'd a tarball name in the config really sucks
[04:45] <dOxxx> doing this three times in a row..... priceless.
[04:46] <lifeless> dOxxx: I'm running --parallel-fork, I am getting the normal progress bar:
[04:46] <lifeless> [407 in 1m18s] per_repository.test_repository.TestRepository.test_item_keys_introduced_by(Reposit
[04:46] <lifeless> trying subprocess now
[04:48] <lifeless> dOxxx: subprocess working for me
[04:48] <lifeless> dOxxx: I'll speculate that stdout in the child processes isn't wired up correctly.
[04:51] <lifeless> poolie: which PPA, if any, would you like me to upload python-testtools into, and which versions of ubuntu for?
[04:51] <poolie> good idea doxxx
[04:52] <poolie> i'd like it to be possible to run selftest on the packaged bzrs
[04:52] <poolie> therefore, for it to be in at least ~bzr for ubuntu versions that don't ship it
[04:52] <poolie> well, i guess ~bzr-beta-ppa
[04:52] <poolie> though the betas may not be in there yet
[04:52] <poolie> there are also ppa dependencies, but i think that's only for building?
[04:52] <lifeless> so, hardy, jaunty, karmic ?
[04:53] <poolie> ppas have been sufficiently successful to create new problems :/
[04:53] <poolie> yes
[04:53] <lifeless> lucid will have the right versions once various archive syncs catch up
[04:54] <dOxxx> lifeless: silly question, but are you actually running on a multi-CPU machine?
[04:55] <dOxxx> lifeless: now I'm not getting the problem...
[04:56] <lifeless> dOxxx: yes, 2 cpu
[04:56] <dOxxx> lifeless: I mean the garbled output problem. it seems coherent now, but still subunit-like spam.
[04:56] <dOxxx> and no progress bar
[04:57] <dOxxx> lifeless: I'm not running it through any subunit filter. Should I be?
[04:57] <lifeless> no
[04:57] <lifeless> it wires one up internally
[04:57] <lifeless> there are two possibilities
[04:58] <lifeless> either stdout on the child is attached to the terminal, not a pipe to the parent
[04:58] <lifeless> or something is introducing noise into the pipe and confusing the parser
[04:58] <dOxxx> could it be my method for installing subunit? I just copied the python modules into my site-packages dir since I couldn't use the makefile
[04:59] <lifeless> dOxxx: that should have worked fine
[04:59] <lifeless> at the moment there isn't any C code needed
[05:00] <dOxxx> it looks like I only get the garbled output when I press Ctrl-C to stop
[05:00] <lifeless> ah
[05:00] <dOxxx> I suspect that stderr and stdout are mixing
[05:00] <lifeless> perhaps the chilren are not being killed appropriately or something
[05:02] <dOxxx> if I recall correctly, ctrl-c is sent to all subprocess associated with the terminal, in win32
[05:02]  * lifeless shrus
[05:02] <lifeless> if, when you don't hit ctrl-C,
[05:02] <lifeless> you get a process count and test name showing
[05:02] <lifeless> then robert is happy
[05:03] <dOxxx> this is what I'm getting, and lots of it: http://pastebin.com/d7623943b
[05:05] <poolie> i was hoping someone would say "how about you help?" - go nmb
[05:06] <jml> what does "IllegalUseOfScopeReplacer" mean? http://paste.ubuntu.com/342421/
[05:06] <jml> I'm trying to follow a review suggestion to use lazy import
[05:07] <dOxxx> poolie: I'm still trying to refine the process of building mac packages. :P
[05:07] <jml> ffs
[05:09] <poolie> jml it means
[05:10] <poolie> oh, blah
[05:10] <poolie> it means fiddle with the way you're using it
[05:10] <poolie> make it a global
[05:10] <poolie> i've read the review but i don't recall the details
[05:10] <poolie> essentially i think you should have your __init__ only lazy_register_command()s
[05:11] <poolie> and then the command module can load its heavy dependencies
[05:12] <dOxxx> uploading bzr 2.0.3 package for mac :)
[05:12] <jml> poolie, lazy_register_command might be the ticket, thanks.
[05:12] <lifeless> jml: it means that something outside the module accessed the lazy import
[05:14] <lifeless> dOxxx: that pastebin is raw subunit
[05:14] <jml> lifeless, so what should I do about that?
[05:14] <lifeless> jml: don't do that :). its likely one of your other modules. They should import (lazily if possible) it themselves.
[05:14] <jml> poolie, lazy_register_command doesn't seem to be a thing
[05:14] <lifeless> rather than doing foo.bar.baz
[05:15] <jml> lifeless, hmm. why isn't this a problem if a plugin fails to lazily import trace, say
[05:16] <lifeless> jml: I'm leaving the house, you can ring me and I will help you happily, if you give me 3 minutes before ringing.
[05:17] <jml> lifeless, ok, thanks.
[05:17] <dOxxx> lifeless: so I guess that means that the filter is failing
[05:18] <lifeless> poolie: on the subunit branch for bzr, I hope I'm not coming across as pushy, I'm just trying to execute on somethings you've been saying for a bit.
[05:18] <poolie> yeah
[05:18] <poolie> i think you're being appropriately pushy
[05:19] <poolie> i just wanted to make my comment more clear
[05:19] <poolie> i'd rather merge it now than after the last beta
[05:19] <poolie> jml if you push or pastebin or gobby your code i will look
[05:19] <jml> poolie, thanks.
[05:22] <jml> poolie, this diff: http://paste.ubuntu.com/342430/ from https://code.edge.launchpad.net/~jml/bzr/lp-login-oauth-2/+merge/15897 -- branch lp:~jml/bzr/lp-login-oauth-2 is up-to-date
[05:25] <poolie> oh you're trying to lazy import a submodule of the current module?
[05:25] <jml> poolie, I guess I am.
[05:25] <poolie> or whatever the right word is
[05:25] <poolie> this is from
 Also, it seems like it might be nicer to lazily import lp_registration.
[05:25] <poolie> ?
[05:26] <poolie> s/from/motivated by
[05:26] <jml> poolie, that's right.
[05:26] <poolie> quick call?
[05:26] <jml> poolie, sure. +61362643170
[05:41] <dOxxx> mac installers are build and uploaded so I'm going to bed. good night!
[05:58] <poolie> jml http://en.wikipedia.org/wiki/List_of_Ubuntu_releases#Release_history
[05:59] <poolie> so quite a few are still supported: dapper (server only), hardy, intrepid, jaunty, karmic
[05:59] <poolie> and in a sense lucid
[05:59] <jml> poolie, citation needed!
[05:59] <poolie> :)
[05:59] <poolie> "moving violation"
[06:00] <jml> poolie, where are they getting our support policy from?
[06:01] <spiv> jml: if you do "from from bzrlib.plugins.launchpad import lp_registration as _lazy_lp_registration" in the __init__.py, does that fix it?
[06:01] <jml> spiv, maybe.
[06:01] <poolie> i don't know
[06:01] <poolie> it's consistent with my memory of it
[06:01] <poolie> spiv i think we solved it
[06:01] <jml> spiv, I've abandoned the lazy registration angle, I'm afraid.
[06:02] <spiv> (and s/lp_registration/_lazy_lp_registration/, obviously)
[06:02] <spiv> jml: :)
[06:37] <jml> hi
[06:37] <jml> http://paste.ubuntu.com/342486/ -- from win32utils
[06:37] <jml> is the second import as unnecessary as it looks?
[06:38] <jml> also, is "WindowsError" a builtin on win32?
[06:48]  * spm must fight temptation to suggest it's a ground state of being....
[06:51] <spiv> jml: file:///usr/share/doc/python2.6/html/library/exceptions.html#exceptions.WindowsError implies yes
[06:51] <jml> spiv, thanks.
[06:51] <jml> spiv, that's probably a bug in pyflakes then
[06:52] <spiv> jml: yes, that second import looks redundant (and weird)
[06:52] <jml> spiv, I actually deleted the first one
[06:52] <spiv> Well, arguably it's the first import -- right.
[06:57] <jml> hmm.
[06:57] <jml> actually, it's probably not a bug.
[06:57] <jml> it's just annoying.
[07:02] <poolie> hm
[07:02] <poolie> google code is either flaky or intermittently banning me
[07:02] <poolie> or both
[07:23] <poolie> could someone test https://spyderlib.googlecode.com/.bzr/branch-format for me?
[07:23] <poolie> actually nm
[07:24] <poolie> really just down
[07:27] <vila> hi all
[07:42] <jml> vila, hello
[07:42] <vila> hi jml ! You're up early !
[07:42] <vila> :D
[07:43] <jml> vila, well, the sun is shining
[07:43] <vila> jml: Lucky you
[07:43] <jml> and it's well over 20 degrees celsius
[07:43] <jml> I thought
[07:43] <jml> why not be awake
[07:43] <jml> https://code.edge.launchpad.net/~jml/bzr/lp-login-oauth-2/+merge/15897 -- I've replied to John's review
[07:43] <jml> it's ready for another round.
[07:44] <vila> Oh yeah, 3 minutes ago :)
[07:45] <jml> vila, why wait even that long!
[07:45] <poolie> hello vila
[07:45] <poolie> jml, i'm pretty much ok with it but
[07:45] <poolie> i greedily want to finish my own patch first
[07:45] <jml> vila, it's very common for Launchpad branches to be landed within a day after submission for review.
[07:45] <poolie> and to talk to vila!
[07:46]  * jml is off to eat food.
[07:46] <vila> It looks like you don't need piloting, you're doing well and already have one core reviewer :) jam sounded ok so I don't see why he would not approve.
[07:46] <vila> Your branch is on my radar anyway, I've just not come to it yet
[07:47] <vila> jml: Do you need two votes here ? You have pqm access right ?
[07:47] <jml> vila, I have PQM access.
[07:47] <jml> vila, I only need one vote
[07:47]  * poolie will look, it's paged in
[07:47] <vila> poolie: ok
[07:48] <jml> I'd really love to rewrite the Launchpad plugin from scratch.
[07:48] <jml> except that's always a terrible idea
[07:48] <vila> jml: pilot work done :-) I will ensure you enjoy your flight anyway :)
[07:48]  * jml off to eat food, for real
[07:48] <jml> vila, :D
[07:49] <poolie> jml did you ever work out how to test lplib?
[07:50] <vila> what ? no tests from jml ? Surely he forgot to push the right thread ? :D
[07:51] <vila> jml: before you raise some ill-founded objections, I'll be ok with a soft dependency on a locally installed launchpad :D
[07:54] <Peng> Woah, an lp-mirror command. Awesome!
[08:00] <poolie> vila: there was a thread a while ago about 'how on earth do you test lplib?'
[08:00] <vila> hmm, before the Mooloolaba sprint ?
[08:01] <vila> re-phrasing: before jml tought me how to installl lauchpad ?
[08:01] <poolie> i should go soon...
[08:01] <poolie> probably yes
[08:02] <jml> vila, the way to test it is to use a mocked launchpadlib, basically
[08:02] <jml> vila, launchpadlib has support for this, but this support is not available in karmic.
[08:02] <jml> vila, nor in any released version of launchpadlib.
[08:03] <vila> jml: that's one way, the one I was hinting above is more like the local_test_server plugin approach were you require a true server locally running and inject it in the bzr test suite
[08:03] <vila> jml: whatever works !
[08:04] <vila> minimizing entropy, etc
[08:09] <jml> poolie, I've just pushed up a change to the NEWS file.
[08:11] <poolie> k
[08:12] <poolie> jml, this is the point where we poke the 'diffs get out of date' bug?
[08:12] <poolie> actually are you really sure you pushed?
[08:12] <poolie> it doesn't even show the revisions
[08:14] <jml> poolie, ahh.
[08:14] <jml> poolie, bzr: ERROR: These branches have diverged.  See "bzr help diverged-branches" for more information.
[08:14] <jml> poolie, injudicious use of uncommit, plus errors all looking the same in text
[08:14] <poolie> mm
[08:15] <jml> poolie, I just successfully pushed.
[08:24] <poolie> good for you :)
[08:24] <poolie> me too
[08:24] <poolie> https://code.edge.launchpad.net/~mbp/bzr/497274-http-405/+merge/16229 may unblock bzr-git imports from google code if we're lucky
[08:25] <MvG> Good morning, or whatever time of day might be appropriate to you!
[08:26] <MvG> Would I be correct to assume that methods decorated with needs_read_lock will ALWAYS unlock their object once they are done?
[08:26] <poolie> they will decrement its lock counter
[08:26] <poolie> if it goes to zero they will unlock it
[08:27] <MvG> poolie: Ah. Didn't see any lock counter in the Branch implementation...
[08:27] <MvG> But otoh, branch is mostly forwarding to its control files, it seems.
[08:28] <MvG> OK, so it might be I forgot to lock things...
[08:50] <Zapelius> I have a driver-foo.c -file, now there is a modified new hw revision and I would need a slightly modified driver for that. how do I copy that driver-foo.c file with history to driver-foo-a.c ?
[08:51] <spiv> Zapelius: bzr doesn't track file copies, unfortunately
[08:52] <spiv> https://bugs.edge.launchpad.net/bzr/+bug/269095
[08:52] <spiv> (currently the top bug on https://bugs.edge.launchpad.net/bzr/+bugs?orderby=-users_affected_count !)
[08:53] <Zapelius> yep, found that too. there's no work-around-hack?
[08:54] <spiv> Not that I can think of, but what behaviour are you after?
[08:54] <spiv> Just that 'bzr log FILE' and 'bzr annotate FILE' would reflect the history from before the copy?
[08:55] <spiv> Or do you expect something special to happen on 'bzr merge' when the file is changed?
[09:03] <Zapelius> I have a branch that I'm working on, and I just wanted to have the entire history for the new file too, as it's up to a few lines identical to the old one
[09:04]  * spiv nods
[09:04] <spiv> It's a reasonable enough request, just we haven't implemented it yet.
[09:05] <Zapelius> k
[09:06] <Zapelius> I have an option to make the driver itself dynamic, selecting the hw rev with an option
[09:18] <CaMason> Hi guys. I'm at r30, and I've got a changeset at r24 that I want to 'revert'. Would revert be the correct command?
[09:24] <spiv> CaMason: probably you want "bzr merge -r 24..23
[09:24] <spiv> CaMason: probably you want "bzr merge -r 24..23 ."
[09:24] <CaMason> spiv, ah, thanks :)
[09:25] <spiv> (I think "bzr help revert" mentions this case :)
[10:01] <CaMason> hm not working as intended :/
[10:02] <CaMason> if I use `bzr diff -r 26..27` I see the changes I made. Those are the changes I want to get back. However, `bzr marge 26..27 .` I don' get them
[10:02] <CaMason> bzr merge* even
[10:02] <bob2> -r
[10:03] <CaMason> yes, sorry was using that
[10:03] <CaMason> aha.. gotta use the revisions the other way around
[10:04] <CaMason> worked perfectly :D
[10:09] <spiv> CaMason: great :)
[10:09] <CaMason> thanks
[10:32] <bialix> hi all
[10:47] <johnf> lifeless, jelmer: Thoughts on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558460
[11:02] <A4Tech> hi all!
[11:03] <A4Tech> How can I synchronize a local code so that updated my partner on launchpad?
[11:04] <lifeless> johnf: according to policy, suggests is right
[11:04] <lifeless> its optional, so its not requires
[11:04] <lifeless> and in fact we find urllib to be more reliable
[11:04] <bialix> A4Tech: use pull and push commands
[11:04] <A4Tech> lifeless: you can help me? :)
[11:04] <A4Tech> using pull  i'm get error
[11:05] <bialix> pastebin
[11:05] <A4Tech> ok
[11:06] <A4Tech> bialix: wait  a second:)
[11:07]  * bialix twiddles the thumbs
[11:08] <A4Tech> bialix: in general, I get an error saying that I have not selected a working branch.
[11:08] <bialix> bzr pull URL
[11:08] <bialix> ensure you're invoking this command from your local branch
[11:09] <A4Tech> It was after this command and received this error. Now make a new commit, I will show an error, but then I got involved in the latest version of code
[11:13] <bialix> pastebin?
[11:54] <johnf> lifeless: we have Recommends for ca-certificates though
[11:54] <johnf> so sureley recomends for pycurl makes sense. Other wise the certs are fairly useless right?
[11:55] <lifeless> ask vila
[12:01] <A4Tech> What should I do if I wrote "branches have diverged" as bzr merge says "Nothing to do"
[12:01] <beuno> A4Tech, when do you get the diverged message?
[12:02] <beuno> it may be trying to merge from a different location?
[12:03] <A4Tech> Just now I made the changes and then commit, and my friend also made a change, and now he wrote it.
[12:05] <beuno> so he is getting the message?
[12:06] <A4Tech> no my fiend
[12:07] <beuno> ok, so he has to merge from you
[12:09] <vila> jonhf: Hmm, it's a bit messy...
[12:10] <johnf> vila: how so?
[12:10]  * beuno waves at vila and lifeless 
[12:10] <vila> Today, only pycurl do certificate validation, urllib don't
[12:10] <vila> \o
[12:10] <vila> Today, only pycurl does certificate validation, urllib doesn't
[12:10] <A4Tech> beuno: and how?
[12:10] <vila> If you don't have ca-certificates, I'm pretty sure pycurl will whine loudly
[12:11] <beuno> A4Tech, bzr merge URL
[12:11] <beuno> A4Tech, are you using launchpad?
[12:11] <A4Tech> yes
[12:11] <A4Tech> but
[12:11] <vila> Now, if you don't have pycurl, then all is "well":  certificates are just ignored
[12:11] <A4Tech> my friend use ArchLinux :)
[12:12] <beuno> A4Tech, so "bzr merge URL_ON_LAUNCHPAD
[12:12] <johnf> vila: Right. So currently ca-certificates is a Recomends, while pycurl is a Suggests. So either we should make ca-certificates a Suggests or pycurl a recommends. I'm leaning towards the latter
[12:13] <A4Tech> beuno: start from 122 line http://pastebin.com/d155c3873
[12:14] <vila> johnf: Well, we plan de deprecate pycurl once we support certificate validation in urllib, so the current rules are not that far away from what we want...
[12:14] <vila> s/de/to/
[12:14] <johnf> vila:  ok. Well I've uploaded 2.0.3 anyway so it can wait till next time :)
[12:14] <vila> johnf: all of that being said, yes, both should be in the same group until then
[12:15] <vila> whether that group is Recommends or Suggests is a bit more subjective :-) If you care about certificates or not I think :)
[12:16] <vila> johnf: While I have the dependencies ouder the eyes... celementree still needed for python-2.5 ? Really ?
[12:16] <vila> s/ouder/under/
[12:16]  * vila shouts at his new keyboard
[12:17]  * vila looks defiantly at beuno waiting for comments
[12:17]  * beuno giggles
[12:17] <johnf> vila: funny you should ask
[12:17] <johnf> here are two more  bugs
[12:17] <johnf> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555336
[12:17] <johnf> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555343
[12:18] <vila> I'm pretty sure we have some minor changes from configobj but I don't remember which
[12:19] <vila> for the later... what ? We have that ? Where ?
[12:25] <vila> johnf: right, so for the later, the copy is there for python-2.4 support, so youcould mark that bug as invalid or whatever the idiom is there, I don't think debian policy requires you to do the kind of brain surgery required to get rid of it
[12:27] <johnf> vila: ok thanks
[12:28] <lifeless> vila: actually, debian is pretty aggressive about duplicated libraries
[12:29] <vila> lifeless: I can understand that and why, but here... 2.5 being supported and upstream supporting another version, how do they address that kind of problem in other contexts ?
[12:31] <lifeless> vila: file a bug, talk, talk some more. And if you're lucky, talk some more.
[12:32] <vila> lol, you mean: until upstream stop trying to the packaging itself ? :D
[12:33] <lifeless> death by discussion
[12:33] <lifeless> seriously though, they would patch it out in debian
[12:33] <lifeless> and file a bug upstream
[12:33] <vila> AFAICS, in that particular case, we may get rid of the python library in util/. The only one that will need it is RedHat were there should be a way to add celementtree in the packaging.
[12:34] <lifeless> vila: yeah. still, E-On-Leave :P
[12:35] <vila> lifeless: thought so :)
[12:35] <vila> lifeless: enjoy !
[12:35] <lifeless> vila: you might like my subunit branch of bzr :)
[12:35] <lifeless> vila: if you could give it, with subunit 0.0.3 & testtools 0.9.2 a spin on babune that might be good to catch anything up with it.
[12:36] <vila> lifeless: I have my eye on it since the begining but gave priority to non-core while pp'ing and then.... time flew :-/
[12:36] <vila> But yes, that was my plan
[12:36] <vila> and sorry for delaying that kind of check so long :-/
[12:37] <lifeless> hey nothing to apologise for
[12:37] <lifeless> testtools was only released this morning
[12:37] <vila> well, I was waiting for some release of test ... exactly, so the delay is ... today :)
[12:37] <vila> lifeless: so that includes you protocol branch right ?
[12:38] <vila> s/you/your/
[12:38] <lifeless> 0.0.3 does, yes
[12:38] <lifeless> if you want to see how it looks, break a test, run selftest --parallel, and look - you should get the log passed across nicely.
[12:39] <vila> I think my big question about your bzr branch was how it fall backs if neither subunit nor testtools is available and how it behaves when wrong versions are available
[12:40] <lifeless> so, it doesn't alter the subunit aspect at all
[12:40] <vila> other than that, if you get rid of the horrors of get_log in bzr, I'd love it :-D
[12:40] <lifeless> older subunit will degrade cleanly - you get the log, but as a 'mega backtrace'
[12:40] <lifeless> older testtools, and bzr selftest will die horribly while loading the tests.
[12:47]  * vila reading lifeless/bzr/subunit
[12:47] <vila> BZRTransformingResult death ? \o/
[12:54] <vila> lifeless: I'm pretty sure you didn't fix the XXX in _get_log(), if further content has been added returning the cached content is still too aggressive
[12:55] <vila> lifeless: E_OUT_OF_SCOPE accepted as long as you restore the comment :)
[12:58] <lifeless> vila: the xxx was wrong
[12:59] <vila> you mean self._log_contents can contain the content flushed ? How ?
[12:59] <lifeless> it gets cached when the log is deleted
[12:59] <vila> yeah, and what happens to writes that occur *after* that ?
[13:00] <lifeless> mutter will fail ?
[13:00] <vila> I'm pretty sure it didn't when I added that XXX
[13:00] <lifeless> the statement was that unflushed stuff wouldn't be seen
[13:01] <lifeless> once the log is closed, there cannot be unflushed stuf
[13:01] <vila> the method is called _get_log() not close_log()
[13:01] <lifeless> if you mean 'mutter can be called after the log is closed and stuff goes nowhere', thats fine - but it belongs totally in a different place.
[13:01] <lifeless> vila: it is, but it serves multiple masters.
[13:02] <vila> including tests that just want to peek at intermediate point
[13:02] <lifeless> vila: not anymore
[13:02] <lifeless> vila: and if they do, it *does not cache the result*
[13:02] <vila> nor provide a way to reset the cache :-/
[13:03] <lifeless> vila: no point once the log is gone.
[13:03] <lifeless> vila: the file is deleted from disk and all
[13:03] <lifeless> vila: I am asserting that the XXX did not describe a bug in this function, when I saw the function - in trunk.
[13:03] <vila> I know, that's the problem ! While I don't like tests that look inside the log, I had to write one yesterday
[13:04] <lifeless> vila: my replacement API doesn't have this issue
[13:05] <lifeless> vila: but even in trunk, the XXX was complaining about a non issue.
[13:05] <lifeless> if you don't believe me, audit the code.
[13:06] <lifeless> the cache was only set when the log was deleted
[13:08] <vila> !
[13:09] <lifeless> I believe you saw an issue, but I think you misdiagnosed
[13:09] <lifeless> and an XXX that is wrong is not helpful to fixing issues.
[13:11] <rubbs> good morning
[13:14] <vila> lifeless: ok, get it, and addDetail use keep_log_file=True. I may have misunderstood the keep_log_file semantic at the time and never re-read the code carefully enough as I missed the cache created only if file deleted part
[13:15] <vila> on the other hand, I think the relationship between bzrlib.trace._trace_file and self._log_file_name wasn't and is still not that obvious :-/
[13:15] <lifeless> vila: yes, that would fit my observation ... that and having to mention it 3 times here n now :P
[13:15] <lifeless> vila: I have 0 objections to you cleaning it up :P
[13:15] <vila> hehe
[13:15] <lifeless> just let me land my patch first so we're not treading on each other.
[13:15] <vila> HAHA
[13:17] <vila> apart from the get_log needed to avoid duplication as other said, the last bit is that deleted addCLeanup
[13:17] <lifeless> hmm ?
[13:17] <vila> in test_trace_nesting, I'm pretty there was a file leak there
[13:17] <lifeless> how so?
[13:18] <vila> because I found a file with the related content
[13:20] <vila> lifeless: hmm, may be you fixed the problem, I should have asked first: why did you delete that addCleanup ?
[13:20] <lifeless> because it was wrong :)
[13:21] <vila> before or after ?
[13:21] <vila> or both ?
[13:21] <lifeless> it was deleting a log file from a test that had been finalised
[13:22] <lifeless> so I moved it into the teset itself
[13:22] <lifeless> see the hunk above where I add it.
[13:22] <lifeless> so I haven't deleted it so much as moved it to be closer to the thing it deletes.
[13:23] <vila> yeah, I just realized that
[13:23] <lifeless> have you had your coffee?
[13:24] <vila> I'm going from the diff to the code, that move wasn't obvious :)
[13:24] <lifeless> I'm -> sleep. Let me distract you : http://build.robertcollins.net - see e.g. http://build.robertcollins.net/job/testtools-2.4/
[13:24] <vila> Of course now that I re-read the diff, it *is* obvious ;)
[13:25]  * vila cries
[13:26] <lifeless> vila: ?
[13:26] <vila> lifeless: by the way, do you version any of that stuff (i.e. have you sorted out which files need to be versioned and which are not interesting)
[13:26] <vila> lifeless: I have hudson very on my plate except I can't find the time to get back to *that* plate :-D
[13:27] <lifeless> vila: which stuff?
[13:27] <vila> using hudson
[13:27] <vila> err
[13:27] <lifeless> no, I don't version the config
[13:27] <vila> which files contains the job description or any part you modify in your hudsonsetup
[13:27] <vila> ok
[13:27] <lifeless> I keep the config lean
[13:28] <lifeless> and if its complex make a shell/python/whateve file to source - and that I version
[13:28] <vila> Famous last words :-D
[13:28] <lifeless> is babune ubuntu ?
[13:28] <vila> yup
[13:28] <vila> well, not only by definition, depends on what you call babune, but the host supporting most of the slaves is karmic
[13:29] <lifeless> vila: on the master, deb http://hudson-ci.org/debian binary/
[13:29] <vila> already installed
[13:29] <lifeless> shove that in sources.list or a .list file in sources.list.d
[13:29] <lifeless> well then, you're all done :P
[13:29] <vila> hehe, no, I want to run a specific instance in a dedicated user and version the relevant bits :)
[13:29] <lifeless> the deb creates a dedicated user
[13:30] <lifeless> /var/lib/hudson if you want to version stuff, but honestly, why?
[13:30] <vila> ENOTNOW !!!
[13:30] <lifeless> vila: 5 minutes, I'll bootstrap you.
[13:30] <vila> Why ??? Oh my, if only to rollback when I break stuff !
[13:31] <lifeless> exclude jobs
[13:32] <lifeless> actually
[13:32] <lifeless> include jobs
[13:32] <vila> lifeless: I have an instance running on locahost:8080 (11 days ago it says even :)
[13:32] <lifeless> exclude 'workspace' inside each job
[13:32] <lifeless> have you setup security?
[13:32] <vila> Apart from the port not being visible on internet, no
[13:33] <lifeless> go to /configure
[13:33] <lifeless> for security realm, select 'hudsons own user db', and 'allow people to sign up'
[13:33] <lifeless> select 'logged in users can do anything'
[13:33] <lifeless> save the config (button at the bottom)
[13:34] <lifeless> click on sign up in the top right
[13:34] <lifeless> give yourself a username(e.g. vila) and passsword etc.
[13:34] <lifeless> now go back to /configure
[13:34] <lifeless> and click on 'matrix based security'
[13:35] <lifeless> it will probably have just anonymous there
[13:35] <lifeless> if so, give anonymous both read permissions (second and middlish positions)
[13:35] <lifeless> add your username
[13:35] <lifeless> and click every tick box in that row
[13:35] <lifeless> add 'authenticated' as a user, and give it both read permissions
[13:35] <lifeless> click save
[13:36] <lifeless> that should take you back to the main screen
[13:36] <lifeless> and still give you a 'manage' link
[13:36] <lifeless> you can add more admins such as john or me via that form.
[13:37] <vila> done
[13:37] <vila> err, except the last :)
[13:37] <lifeless> install the bazaar plugin from http://build.robertcollins.net/pluginManager/
[13:37] <lifeless> we'll need to add our own accounts first, no rush,
[13:37] <lifeless> sorry, /pluginManager
[13:38] <lifeless> once its installed, click the restart button, or use invoke-rc.d hudson restart
[13:38] <lifeless> then visit /view/All/newJob
[13:39] <lifeless> job name 'bzr.dev', type 'build a free software project', OK
[13:39] <lifeless> source code management -> bazaar, repository url 'lp:bzr'
[13:40] <lifeless> 'poll scm', @hourly
[13:40] <lifeless> add build step 'execute shell', put in
[13:40] <vila> willl trigger only if changes appear there right >
[13:43] <lifeless> ./bzr selftest --parallel=fork --subunit | subunit2junitxml -o tests.xml
[13:43] <lifeless> click 'publish junit test result report'
[13:43] <lifeless> put in *.xml as the field
[13:43] <lifeless> click on save
[13:44] <vila> done
[13:44] <vila> Well, I added a 'make' build step first
[13:44] <lifeless> ok
[13:44] <lifeless> so, assuming you have subunit and python-junitxml installed, this will just work.
[13:44] <vila> they are installed only for my user :)
[13:45] <lifeless> ok, so ideally you'd install them
[13:45] <vila> so I guess it will just breaks ?
[13:45] <lifeless> however
[13:52] <lifeless> anyhow - make the build shell be what I pasted above
[13:52] <lifeless> and it will grab our deps from lp
[13:52] <lifeless> save the config
[13:52] <lifeless> click on build now
[13:52] <vila> it complains about -f
[13:52] <vila> ./bzr selftest --parallel=fork --subunit | ./subunit/filters/subunit2junitxml -o tests.xml -f | ./subunit/filters/subunit2pyunit
[13:53] <lifeless> really ?
[13:53] <lifeless> oh bugger
[13:53] <lifeless> optparse faaail
[13:54] <lifeless> subunit 0.0.4 will be coming to a doorway near you tomorrow
[13:54] <lifeless> add 1
[13:54] <lifeless> -f 1
[13:55] <jelmer> hah, boolean option?
[13:55] <lifeless> yeah
[13:55] <lifeless> well, meant to be :P
[13:56] <vila> running
[13:57] <vila> instant feedback via console output, good
[13:57] <vila> progress bar as barbershop, less good
[13:57] <vila> :D
[13:59] <lifeless> vila: should be nearly done ;)
[13:59] <lifeless> on your beefy machine
[14:00]  * vila tracking the python processed by use hudson
[14:01] <vila> urgh, zombies ? 3 of them, bad
[14:01] <vila> some other processes are still running though, so let see
[14:01] <vila> no more feedback in the uhdson console :-/
[14:01] <lifeless> does hudson think its still running?
[14:02] <vila> still the spinning wheel but no more *test* names
[14:02] <lifeless> possibly the setup test
[14:02] <lifeless> :P
[14:03]  * vila kills the build
[14:03] <vila> no more zombies, good
[14:03] <lifeless> thats a little harsh :P
[14:03] <lifeless> ok, put test_plugin or something on the selftest line
[14:03] <vila> far too long
[14:03] <lifeless> so I can go to bed ;)
[14:04] <lifeless> see, the US is getting up. Now I know its late.
[14:04] <vila> hehe
[14:04] <vila> Ran 0 tests in 0.172s
[14:04] <vila> OK
[14:05] <rubbs> lifeless: haha
[14:05] <lifeless> vila: thats perhaps a little too fine a test selection
[14:05] <vila> dichotomy :)
[14:05] <vila> Ran 208 tests in 1.496s
[14:05] <vila> OK
[14:05] <vila> Recording test results
[14:05] <vila> Finished: SUCCESS
[14:06] <vila> lifeless: sleep well :)
[14:06] <lifeless> vila: right, now on the project page
[14:06] <lifeless> there should be a test graph
[14:06] <lifeless> and a 'last test result'
[14:06] <vila> graph, yes, latest, yes
[14:06] <lifeless> click, click enjoy.
[14:06] <vila> rhaaaaaa lovely :)
[14:07] <lifeless> what else do you need to know?
[14:07] <vila> activating remote slaves, I read somewhere you should do that early
[14:07] <lifeless> ok
[14:08] <lifeless> are you using vmware? kvm? ec2?
[14:08] <vila> virtualbox, real boxes so far, ec2 very soon for desolation
[14:08] <lifeless> #hudson btw, good folk there if you need a hand.
[14:08] <vila> good
[14:08] <lifeless> so, virtualbox oesn't have a plugin yet
[14:08] <lifeless> do you start the slaves and leave them running?
[14:09] <vila> for vbox, yes,
[14:09] <lifeless> ok
[14:09] <lifeless> go to /computer/new
[14:09] <vila> except lately were I need to reboot them far too often, but that's most probably a vbox bug
[14:09] <lifeless> select 'dumb' slave
[14:09] <lifeless> (vs automatic provision like ec2 does)
[14:10] <lifeless> executors is concurrency on the slave
[14:10] <lifeless> fs root - e.g /home/babune/hudson
[14:11] <lifeless> change launch method to ssh
[14:11] <lifeless> oh
[14:11] <lifeless> you probably want the platform labeller plugin
[14:11] <lifeless> for tying jobs to os's
[14:12] <lifeless> but it won't really matter at this point
[14:12] <vila> oh I would certainly like that
[14:12] <lifeless> you can tie by the node name too
[14:12] <lifeless> so if your node is called 'freebsd' you'll probably be ok for now :)
[14:12] <lifeless> but install platform labeller, its mine ;)
[14:13] <vila> ok, noted
[14:14] <vila> private key path, damn, needs to run as babune again :)
[14:16] <lifeless> ln :P
[14:16] <lifeless> or cp probably better
[14:17] <lifeless> K, crashing.
[14:17] <lifeless> all you need now is java installed on the slave
[14:17] <vila> sure, thanks a lot, that helped !
[14:17] <lifeless> and you can either add a new copy, as a copy of this one
[14:17] <lifeless> and 'tie to a node' in both jobs
[14:17] <lifeless> *or8
[14:17] <lifeless> you can play with matrix builds
[14:17] <lifeless> I suggest the former, for now. Its easier to grok.
[14:17] <lifeless> if a tad more manual.
[14:18] <vila> yeah a bit too much clicks for me :-) Another reason to version the stuff, hopefully the xml bearable...
[14:19] <vila> is
[14:19] <lifeless> this process - /usr/bin/python /var/lib/hudson/jobs/bzr.dev/workspace/bzr --no-plugins serve --port localhost:0 - is stuck for me
[14:19] <vila> oh my, it's installing the jdk :-)
[14:19] <lifeless> I suspect its what you had too ?
[14:19] <vila> yup,
[14:20] <vila> I didn't mention it earlier but it appeared early in the game
[14:21] <lifeless> test_breakin
[14:21] <lifeless> test_breakin_harder
[14:21] <lifeless> they were the problem
[14:21] <vila> hehe, back they are :0)
[14:22] <vila> Good,looks like it's mainly config.xml fileS under /var/lib/hudson for the main, the jobs and the hosts
[14:22] <lifeless> this is what test failures look like: http://build.robertcollins.net/job/bzr.dev/lastCompletedBuild/testReport/
[14:23] <lifeless> (with my patch they will have the log)
[14:27] <vila> gee, /systeminfo, refreshing transparency....
[14:29] <vila> Disk space is too low. Only 1.012GB left. Come on hudson....
[14:36] <lifeless> vila: /computer/configure
[14:36] <lifeless> turn off things to your hearts content
[14:37] <lifeless> and thats my final note; consider yourself unblocked:)
[14:37] <lifeless> infuture, remember I'm happy to share knowledge!
[14:37] <lifeless> ciao
[14:39] <vila> I'm there, I'd like to tune instead, but thanks a ton for all the hints, highly appreciated !
[14:39] <vila> you saved me hours
[15:48] <eric_f> I'm curious if there's a way I can register nickname for branches more globally? I can use bzr nick trunk, bzr nick eric to allow me to easily switch between my "trunk" and "eric" branches, but when I'm bound to "eric" and want to merge in "trunk" I have to always use bzr+ssh://username@host:port/repos/project/trunk, I just want to simply type in "bzr merge trunk"
[15:49] <eric_f> Note that both branches are remote ones on a central server
[15:55] <rubbs> I'm not sure if this is what your looking for, but I'm sending it just in case
[15:55] <rubbs> http://doc.bazaar.canonical.com/bzr.2.0/en/user-reference/index.html?highlight=intent
[16:06] <jam> lifeless: we get ^M output on the stream until we run a test that ends up setting sys.stdout to binary
[16:06] <jam> \o/ for test suite isolation
[16:06] <jam> (That is CRLF until a expect binary output is run, and then we get LF only on the output)
[16:06] <jam> I think the test is "test_send" but any time you run_bzr with something that has output_encoding=exact it potentially causes it
[16:08] <jam> oh, and you can't run the filters via "C:\Path\to\subunit2pyunit" you have to use "C:\Python26\python C:\Path\to\subunit2pyunit"
[16:08] <jam> I alias them locally
[16:09] <ad-530> hiho
[16:09] <ad-530> need help with bzr builder/dailydeb
[16:09] <intellectronica> james_w: can you maybe help ad-530 with some bzr builder problems he's having?
[16:12] <james_w> hi ad-530
[16:12] <ad-530> hi james
[16:12] <ad-530> can i start?
[16:13] <james_w> ad-530: of course :-)
[16:13] <ad-530> ok ^^
[16:14] <ad-530> i want to setup daily builds with bzr dailydeb from a sf.net svn repos and publish them in a ppa
[16:15] <ad-530> i've made a local branch of the svn repos and keep it up to date with bzr pull
[16:15] <ad-530> the svn working copy resides in /home/ad-530/prog/dangerdeep/trunk/
[16:15] <ad-530> the local bzr branch in /home/ad-530/prog/dangerdeep/bzr/
[16:16] <ad-530> my recipe resides in /home/ad-530/prog/dangerdeep/trunk/dangerdeep/packaging/ubuntu/daily/recipes
[16:17] <ad-530> the debian folder for packaging is located here /home/ad-530/prog/dangerdeep/trunk/dangerdeep/packaging/ubuntu/daily/karmic/debian
[16:17] <ad-530> the recipe content is:
[16:17] <ad-530> # bzr-builder format 0.2 deb-version 0~dangerdeep{revno}+0.0ubuntu~9.10
[16:17] <ad-530> /home/ad-530/prog/dangerdeep/bzr/dangerdeep/trunk/dangerdeep
[16:18] <ad-530> nest packaging /home/ad-530/prog/dangerdeep/trunk/dangerdeep/packaging/ubuntu/daily/karmic .
[16:18] <ad-530> now i've two problems
[16:18] <ad-530> fuck
[16:27] <ad-530> james_w, what was the last you'd recieved ?
 ok ^^
[16:27] <ad-530> lol
[16:27] <james_w> not good :-(
[16:28] <james_w> could you repeat what you said?
[16:28] <ad-530> are the script kiddies attacking freenode excelusively or just their sponsors and the splits are a side effect?
[16:28] <ad-530> sure
 i want to setup daily builds with bzr dailydeb from a sf.net svn repos and publish them in a ppa
 i've made a local branch of the svn repos and keep it up to date with bzr pull
 the svn working copy resides in /home/ad-530/prog/dangerdeep/trunk/
 the local bzr branch in /home/ad-530/prog/dangerdeep/bzr/
 my recipe resides in /home/ad-530/prog/dangerdeep/trunk/dangerdeep/packaging/ubuntu/daily/recipes
 the debian folder for packaging is located here /home/ad-530/prog/dangerdeep/trunk/dangerdeep/packaging/ubuntu/daily/karmic/debian
 the recipe content is:
 # bzr-builder format 0.2 deb-version 0~dangerdeep{revno}+0.0ubuntu~9.10
[16:29] <james_w> ad-530: I'm not sure, I would suspect freenode itself
 /home/ad-530/prog/dangerdeep/bzr/dangerdeep/trunk/dangerdeep
 nest packaging /home/ad-530/prog/dangerdeep/trunk/dangerdeep/packaging/ubuntu/daily/karmic .
[16:29] <ad-530> now i've two problems
[16:29] <ad-530> first is the nest line
[16:29] <ad-530> is "." right?
[16:30] <ad-530> or is the "nest" itself right?
[16:30] <ad-530> most howtos are using merge but that gives an error
[16:30] <ad-530> not the same ancestor
[16:31] <ad-530> 2nd problem is when running bzr dailydeb with that recipes it gives the following error msg:
[16:31] <james_w> you can't nest to ".", not
[16:31] <james_w> err, "no"
[16:32] <james_w> you can nest to "debian"
[16:32] <james_w> so the line would be
[16:32] <james_w>  nest packaging /home/ad-530/prog/dangerdeep/trunk/dangerdeep/packaging/ubuntu/daily/karmic debian
[16:32] <james_w> however, it depends on what is in that branch as to whether that will do the right thing
[16:33] <ad-530> well, in all the howtos the guys are merging a "packaging" branch into
[16:34] <ad-530> thought it's a good idea to have several packaging files for several distributions
[16:34] <ad-530> but merging gives an error about the two branches don't have the same ancestor
[16:34] <james_w> you can do that
[16:36] <ad-530> with the new nest line there's no lock error furthermore
[16:38] <ad-530> but that produces /home/ad-530/blubb/karmic-0~dangerdeep1+0.0ubuntu~9.10/debian/debian
[16:39] <ad-530> guess i need to change the line to: nest packaging /home/ad-530/prog/dangerdeep/trunk/dangerdeep/packaging/ubuntu/daily/karmic/debian debian
[16:41] <ad-530> ah yes
[16:41] <ad-530> works
[16:41] <ad-530> thank you very much
[16:45] <ad-530> what is the manifest file used for?
[17:16] <nekohayo> hey folks, what's the status of the bzr nautilus integration?
[17:21] <jelmer> nekohayo, there's something basic, but no developmens in the last little whle
[17:22] <nekohayo> and it seems like there's a new kid on the block, bzr explorer?
[17:22] <nekohayo> is it out to replace olive?
[17:27] <maxb> The bazaar website move has broken the bzr-eclipse releases update site, is it available anywhere else?
[17:28] <jam> nekohayo: bzr explorer >> olive (at the moment)
[17:28] <nekohayo> >> ?
[17:28] <jam> much much better
[17:28] <nekohayo> oh
[17:29] <nekohayo> what becomes of olive?
[17:30] <rubbs> it's till around, but it's mostly suggested that people switch to explorer.
[17:32] <ad-530> is it possible to specify ignores in builder/dailydeb ?
[17:49] <james_w> ad-530: not currently, what do you want to ignore?
[17:57] <ad-530> a folder
[17:58] <ad-530> that contains a lot of data files that should better be in an own package
[18:00] <ad-530> the trunk has a data/ and a src/ folder
[18:01] <ad-530> and a makefile of course
[18:06] <ad-530> best thing would be to have the local repos and inside one branch for the trunk/src/, one for the trunk/data/ and one for the makefile(s) inside trunk/
[18:06] <ad-530> that's not possible, right?
[18:11] <james_w> ad-530: not currently, no
[18:25] <rellis> Is there a way to get bzr to convert windows newline character to unix?
[18:25] <rellis> When any random person commits..
[18:30] <rellis> I guess I'm looking for a pre-commit bit to turn CRLF -> LF.
[18:31] <rellis> nm found it
[20:37] <lifeless> vila: thats the idea; you should learn and tune, but basic setup a quickstart is a good idea
[20:37] <lifeless> hi jam, so there is a problem on win32?
[20:37] <jam> lifeless: there is a problem on all platforms
[20:38] <jam> GCCHKPacker isn't passing the reload func to the vfs
[20:38] <jam> so they are aborting
[20:38] <jam> raising the wrong exception
[20:38] <jam> the fix is one-line
[20:38] <jam> lifeless: I'd love to chat about how to test it
[20:38] <lifeless> jam: I mean about subunut :P
[20:38] <jam> ah, different patch :0
[20:38] <lifeless> jam: but the autopack one. sure
[20:38] <lifeless> uhm
[20:38] <jam> here is a start comment
[20:38] <jam> So, IMO, to have a stable test, you'd ideally like a high-level per-repository test that a concurrent 'Repo.autopack()' doesn't fail with an error. Creating this situation across all repository formats seems difficult to do. You could create threads, but then you introduce timing race conditions. Monkeypatching to inject the race seems brittle against the repository format.
[20:40] <lifeless> so
[20:40] <lifeless> whats the clearest statement we can make about the race
[20:40] <lifeless> heres my stab
[20:41] <lifeless> 'when one pack completes other pack operations may be reading from a file it tries to obsolete' ?
[20:42] <jam> So we have a test like:     def test_concurrent_pack_triggers_reload(self):
[20:42] <jam> But it passes, because the Repo.texts etc all have reload func set appropriately.
[20:42] <jam> It is only the GCCHKPacker code that suffers from this
[20:42] <jam> So it has to be 2 concurrent pack operations
[20:42] <jam> and not just pack + some other op
[20:43] <jam> maybe just r1.pack(), r2.pack()?
[20:43] <jam> lifeless: I think your summary is reasonable
[20:43] <lifeless> do they have to be partial packs, or will an autopack do ?
[20:43] <lifeless> anyway
[20:43] <jam> well, autopack is triggering it today :)
[20:43] <lifeless> here is a way to trigger it
[20:44] <lifeless> firstly we should parameterise to just pack based repos, like there are just chk based tests. test_pack_repo.py already exists and we can use that I guess.
[20:44] <jam> yeah
[20:44] <lifeless> so, if we use a VFS
[20:44] <jam> per_pack_repository now
[20:45] <lifeless> we can make io block, call other operations and whatnot
[20:45] <lifeless> here is a simplish way to make a non-threaded race
[20:45] <lifeless> all we need is a way to figure out the name of one of the packs
[20:46] <lifeless>  write a transport decorator which can trigger a callable on a specified trigger.
[20:46] <lifeless> e.g. t = decorate(self.get_transport())
[20:46] <lifeless> setup a repo, two commits and then two repo objects
[20:46] <lifeless> then do
[20:47] <lifeless> t.set_trigger('readv', one_pack_name, repo2.pack)
[20:47] <lifeless> repo1.pack()
[20:48] <lifeless> this will cause repo2 to repack under repo1's attempt to pack
[20:48] <lifeless> nice and synchronously
[20:49] <jam> interesting point, this code:
[20:49] <jam> http://paste.ubuntu.com/342979/
[20:49] <jam> In that order, all formats pass
[20:49] <jam> reversing those two lines
[20:49] <jam> all formats fail
[20:49] <jam> well, 7 failures at least
[20:51] <lifeless> thats odd
[20:51] <lifeless> that test is also pretty good, but it assumes that once the pack name index is read it isn't re-read till later
[20:51] <jam> yeah
[20:51] <lifeless> which the callback style trick I suggest above won't assume.
[20:52] <lifeless> as AIUI we now know matters
[20:52] <lifeless> or we've done something such that the existing test isn't strong enough
[20:52] <jam> sure, though I think I've also exposed another bug, since all the formats fail
[20:52] <jam> the existing tests mix packing with record streaming
[20:52] <jam> and the bug in the current format is about mixing packing with packing
[20:53] <jam> well, and reading indices
[20:53] <jam> it mixes a get_parent_map() call in one test and a get_record_stream().next() in the other
[20:55] <lifeless> so
[20:55] <lifeless> if you use the trace decorator
[20:55] <lifeless> and copy tree
[20:55] <lifeless> you can find all the i/o with some granularity that pack does
[20:55] <lifeless> and then do it again N times
[20:56] <lifeless> with each time a different IO hooked
[20:56] <lifeless> jam: do you know the name of an xfail test offhand ?
[20:57] <jam> I believe there is one in test_merge
[20:57] <jam>     def test_modify_conflicts_with_delete(self):
[20:59] <lifeless> thanks
[21:00] <lifeless> thanks
[21:00] <jam> lifeless: just to clarify, the trigger code would be a new class, right?
[21:00] <lifeless> yeah
[21:00] <lifeless> a new transport decorator
[21:00] <lifeless> that with no triggers, does nothing unusal
[21:00] <jam> that's what I thought, I just know that 'trace+' already exists
[21:00] <lifeless> but with a trigger, fires a callback
[21:01] <lifeless> and (to follow a regular convention) can have the trigger kept if what you return evaluates True
[21:04] <jam> lifeless: you don't seem to have a "subunit.__version__" string. Is that intentional?
[21:04] <jam> (I often use something like that to figure out versions I have installed.)
[21:04] <lifeless> I haven't been doing that, I've started adding them to projects as I notice the lack.
[21:05] <jam> consider this an observation of the lack :)
[21:07] <lifeless> jam: heh
[21:07] <justdave> is there any way to make bzr pass specific SSL certificate handling options to libcurl when it communicates with an https repository?
[21:08] <lifeless> justdave: not at the moment, i think its why we want to drop libcurl
[21:08] <lifeless> you can make it not use libcurl
[21:08] <justdave> that's probably work.
[21:08] <justdave> got a repo with a local-CA-signed certificate, and it's been working fine for months...
[21:09] <justdave> updated the OS on the webserver, and it picked up a new version of libcurl and now I can't bzr up anymore :)
[21:09] <lifeless> you could add that to your certificate store
[21:09] <lifeless> the upgrade probably discarded it
[21:10] <justdave> I figured out how to specify the root ca cert to check it against via an environment variable, which was a good temporary solution
[21:10] <justdave> but it's also got a hostname mismatch actually.
[21:10] <lifeless> rotfl
[21:10] <lifeless> ok
[21:10] <lifeless> so, I think its urllib+http://...
[21:10] <lifeless> its in bzr help urlspec, I think.
[21:10] <justdave> makes it a little harder problem :)
[21:11] <justdave> in a few weeks this problem will go away when the repo moves to a dedicated server
[21:11] <justdave> in the meantime I need to convince it to work :)
[21:12] <Peng> The recent progress bar changes have lead to some suckiness for me: " M  NEWSKB     0KB/s | Pull phase:Merge phase:Resolution pass 1/10 0/1263sion paths 0/1"
[21:13] <Peng> Ah, only happens when piped to less.
[21:14] <justdave> don't see anything mentioning urllib in bzr help urlspec, and tells me "Unsupported protocol" when I try it anyway
[21:14] <justdave> probably an old version of bzr or something
[21:14] <lifeless> no
[21:14] <jam> lifeless: so it turns out the reason why the '.pack() + .pack()' fails, is because .pack *doesn't* handle retry, only autopack does...
[21:14] <justdave> looks like it's 2.0.1
[21:14] <lifeless> jam: woo :P
[21:14] <lifeless> jam: do you remember justdaves thing
[21:15] <jam> justdave: http+urllib:// iirc
[21:15] <jam> not urlib+http
[21:15] <jam> yep: register_transport_proto('http+urllib://',
[21:15] <justdave> that works.
[21:16] <justdave> All changes applied successfully.
[21:16] <justdave> woot
[21:16] <justdave> thanks
[21:16] <justdave> it's funny...
[21:16] <justdave> [root@mradm02 bugzilla.mozilla.org]# bzr pull --overwrite https+urllib://dm-bugstage01.mozilla.org/bmo/3.4/
[21:16] <justdave> https://dm-bugstage01.mozilla.org/bmo/3.4 is permanently redirected to https://dm-bugstage01.mozilla.org/bmo/3.4/
[21:16] <justdave> didn't I specify it with a / on the end?
[21:16] <justdave> :)
[21:17] <lifeless> it gets normalised
[21:18] <DanC> how do I check out a copy of the python branch of lp:zim? i.e. https://launchpad.net/zim/pyzim
[21:18] <DanC> oh. duh.
[21:19] <justdave> ok, so how do I re-parent my local branch to that urlspec?
[21:19] <justdave> (so I don't have to specify it every time)
[21:19] <justdave> bzr switch says I can only do that to a checkout
[21:19] <DanC> $ bzr branch https://launchpad.net/zim/pyzim
[21:19] <bialix> pull --remember
[21:19] <DanC> that worked; I'm kinda curious how that works. but I'm happy
[21:19] <justdave> --remember does the trick.  thanks!
[21:20]  * bialix mutters: gary gary where are you
[21:20] <jam> bialix: hiding from you.
[21:20] <jam>  /wave
[21:20] <jam> by the way
[21:20] <bialix> ?
[21:20] <jam> bialix: I'm saying hi, and teasing you that gary is hiding from you
[21:21] <bialix> ah
[21:21] <jam> sorry if it didn't translate well
[21:21] <bialix> hi jam!
[21:21] <bialix> sometimes I think I did something not good
[21:21] <lifeless> DanC: launchpad puts a bzr style symlink at series paths
[21:21] <DanC> "symlink"?
[21:21] <lifeless> yeah, with scare quotes ;)
[21:22] <bialix> jam: thanks for new instalers, waiting for announce now :-D
[21:22] <DanC> I know how filesystem symlinks work
[21:22] <lifeless> technically a branch reference object
[21:22] <lifeless> has a .bzr/branch which is a branch reference, same as lightweight checkouts use.
[21:22] <DanC> what does it look like on the wire?
[21:22] <DanC> ah.
[21:22]  * bialix sighs: this new colored chatzilla is full of colors, so strange
[21:29] <bialix> luks: ping
[21:36] <maxb> I've been looking at bzr-svn trying to understand why there are trunk0, trunk1, trunk2, etc. layouts. I can't see any reason why there couldn't just be a single trunk* layout. Am I missing anything?
[21:37] <lifeless> users are insane
[21:37] <maxb> users?
[21:37] <lifeless> of svn
[21:41] <maxb> Sorry, I'm not questioning why flexible layout handling needs to exist. I'm questioning why the trunk layout needs parameterization with a fixed integer
[21:41] <maxb> Especially since I have a repository with projects at varying depths.
[21:41] <lifeless> I don't recall why sorry
[21:41] <lifeless> jelmer: ^
[21:42] <jelmer> maxb: hi
[21:42] <lifeless> it may be part of the older styles no longer recommended
[21:42] <maxb> hello
[21:42] <jelmer> maxb: what if you have a file named trunk in a directory named trunk ?
[21:42] <maxb> But no one would be silly enough to do that, right? :-)
[21:43] <lifeless> maxb: see under insane
[21:43] <jelmer> similarly, not all directories in a repository usually follow the trunk, branches, tags scheme
[21:43] <maxb> Well, I guess I'll have a go at writing a trunk* layout, since I need it, and it seems mostly plausible
[21:44] <jelmer> so some people have a directory "releases" and having a flexible scheme would require us to descend into that directory to see if there happens to be a idirectory there somewhere named "trunk"
[21:44] <maxb> *Ah*
[21:44] <maxb> That's the thing I was missing
[21:45] <jelmer> so, to summarize: a flexible schema would cause confusing behaviour and potential performance issues.
[21:46] <jelmer> argh
[21:47] <jelmer> maxb, did you see my last lines?
 so, to summarize: a flexible schema would cause confusing behaviour and potential performance issues.
[21:47] <maxb> OK, I now understand why a flexi-depth layout isn't a good all-purpose solution
[21:48] <maxb> I think I can still make it work for me, however
[21:48] <lifeless> maxb: note that if you do that, only you can use that svn repo with bzr, until you get the patch in other folks plugin
[21:49] <maxb> True, but it beats having to edit .bazaar/subversion.conf depending on which project I'm currently working on in that repository
[21:49] <jelmer> lifeless, that's not true anymore
[21:50] <lifeless> jelmer: oh, cool
[21:51] <jelmer> maxb: you can set a list of wildcard expressions
[21:52] <maxb> I could, but it just seems so messy
[21:53] <maxb> Also, the wildcard layout does not push non-lefthand ancestry
[22:05] <maxb> Is there any flag to make bzr log show bugs-fixed info?
[22:07] <bob2> don't think so
[22:07] <bob2> qlog does iirc
[22:10] <lifeless> maxb: it would be nice to have that
[22:10] <Peng> I think there's a bug open about it.
[22:18] <bialix> maxb: qlog
[22:19] <maxb> bialix: Yup.. except when I'm working over ssh :-)
[22:19] <bialix> qlog REMOTE_URL?
[22:22] <maxb> hmm... that's... a wonderful idea :-)
[22:22] <bialix> :-)
[22:23]  * maxb fights trying to get qbzr-eclipse installed.
[22:23] <maxb> (for an unrelated matter)
[22:24] <bialix> maxb: there was some issues with redirection from qbzr-eclipse@b-v.o to real location
[22:25] <bialix> maxb: http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/64783
[22:25] <bialix> maybe this related to your fight?
[22:25] <maxb> I think I've hopelessly confused my eclipse by trying to install both qbzr-eclipse and bzr-eclipse
[22:25] <bialix> last time I've tried do this it succeed
[22:26] <bialix> this summer
[22:28] <maxb> Oh. No, it has worked, but I was confused because qbzr-eclipse doesn't seem to be a proper "Team" plugin
[22:28] <maxb> It puts all its menus and options elsewhere
[22:29] <bialix> it puts its menu to main menu line
[22:29] <maxb> Indeed. Disconcertingly bizarre to someone used to how standard Eclipse VCS integration plugins
[22:29] <maxb> work
[22:30] <bialix> sighs
[22:31] <poolie> hello maxb, bialix
[22:31] <maxb> hello
[22:31] <poolie> is there a problem with the list?
[22:31] <bialix> morning poolie
[22:32] <bialix> the list?
[22:32] <bialix> the?
[22:32] <maxb> Mailing list? I have an email from half an hour ago
[22:32] <bialix> confirm
[22:33] <bialix> freenode has some problems though
[22:44] <poolie> oh i was asking about
[22:44] <poolie> > bialix: maxb: there was some issues with redirection from qbzr-eclipse@b-v.o to real location
[22:45] <bialix> poolie: http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/64783
[22:45] <bialix> jam sent the answer
[22:46] <phoenixz> fullermd: Hi there, dunno if you remember me, I switched from SVK/SVN to BZR a couple of weeks ago..
[22:46] <phoenixz> fullermd: Im having 2 problems with BZR, dunno if you might be able to help out?
[22:46] <bialix> phoenixz: just ask, there many people around
[22:48] <phoenixz> Sure
[22:50] <phoenixz> problem 1) I have my branch, and I have a branch (without WT) on a central server that acts as trunk. Communication is over bzr+ssh:// Now, the second developer joined the group, we try to push and pull but the second person gets access denied all the time, even though I made group permissions of the entire server brach "development" and we are both member of that group..  I chgrp development .bzr -R again, the second person has access, but as soon as I do
[22:50] <phoenixz>  an update, we have the very same problem again.. How can I fix this problem?
[22:50] <phoenixz> Dunno if I put that clear...
[22:51] <fullermd> Use a group with the two of you.
[22:51] <phoenixz> Its a permission problem when 2 persons try to push over bzr+ssh:// to a central repository ..
[22:51] <fullermd> If should preserve the.
[22:51] <fullermd> s/the/that/.
[22:51] <phoenixz> fullermd: eh, sorry, don't understand what you are saying..
[22:51] <fullermd> Though you may need g+s on a filesystem with SysV semantics; do you have that?
[22:52] <jam> phoenixz: did you setgid ?
[22:52] <jam> chmod 2775 -R .bzr
[22:52] <fullermd> (also, I presume you made it group writable, as well as chgrp'ing)
[22:52] <phoenixz> jam: setgid?
[22:52] <phoenixz> fullermd: correct, I added group write permissions
[22:52] <jam> phoenixz: If the bit is set, it sets the group for newly created flies
[22:52] <jam> to inherit from the directory
[22:52] <fullermd> Well, I wouldn't do it that bluntly, just on GP.  A find | xargs of just the dirs rather.
[22:52] <phoenixz> jam: ah, that sounds interresting...
[22:53] <jam> find .bzr -type d -print0 | xargs -0 chmod 2775
[22:53] <jam> find .bzr -type f -print0 | xargs -0 chmod 664
[22:53] <jam> phoenixz: what is prob 2, btw
[22:53] <phoenixz> jam: well, Id like all this only to be available for development users.. could I also do 2770 and 660?
[22:54] <phoenixz> jam: eh... problem 2... crap.. I forgot, heheheh...
[22:54] <jam> phoenixz: sure
[22:55] <phoenixz> There were 2 things, but I just cant get what the 2nd thing was..well, not too important then.. :)
[22:55] <jam> you *might* need to look into setting the umask for the bzr process, but I think the chmod + chgrp should be enough
[22:57] <phoenixz> jam: fullermd: Going to try this.. thanks!
[22:59] <phoenixz> jam: ah, got the other problem!
[23:00] <phoenixz> one time I did bzr tag 0.3.0... then I made modifications and I needed to tag THAT one as 0.3.0, so, according to documentation I did bzr tag -f 0.3.0 to force retagging..
[23:00] <phoenixz> ever since, I get Conflicting tags:
[23:00] <phoenixz> 0.3.0
[23:01] <phoenixz> how can I fix this?
[23:02] <fullermd> You'll have to move (or eliminate) it on the branch it's set at the old rev on.
[23:02] <bialix> does it only for me? bzr: ERROR: Unable to connect to SSH host bazaar.launchpad.net; (10061, 'Connection refused')
[23:03] <phoenixz> bialix: denyhosts?
[23:03] <spiv> bialix: it's down for maintenance
[23:03] <bialix> thanks spiv
[23:03] <spiv> bialix: topic in #launchpad says it should be back by 23:59 UTC
[23:04] <bialix> hmm, there is nothing on twitter channel
[23:09] <jam> spiv: so another... 2 hours or so?
[23:10] <jam> anyway, thanks to everyone who made 2.1.0b4 and 2.0.3 happen. I'm out for tonight.
[23:11] <jam> I should mention, the turnaround on binaries was pretty darn good this time. Thanks!
[23:12] <sproaty> is the web browisng interface part of bzr itself?
[23:22] <spiv> jam: less than 40 minutes left, 'date -u' will show you the time in UTC
[23:27] <lifeless> spiv: assuming estimates are accurate predictors :P
[23:27] <spiv> lifeless: :P
[23:55] <Tak> ssh: connect to host bazaar.launchpad.net port 22: Connection refused
[23:56] <Tak> oh, damn - if there hadn't been so many splits, I would've seen that in the scrollback