[00:21] <jelmer> 'morning poolie, wgz
[00:21] <jelmer> I'm sure a pangolin is safer than riding an ocelot.. :-)
[00:21] <poolie> hi there
[00:59] <wgz> Noldorin: bug 906109
[00:59] <wgz> I think I put most of the relevent things in there
[00:59] <wgz> making lockdir error reporting a little less lame would probably be generally helpful
[01:02] <Noldorin> wgz, cheers
[07:22] <poolie> vila, hi?
[07:33] <vila> hi all !
[07:33] <vila> poolie: hey !
[07:33] <poolie> hi there
[09:03] <mgz> morning all!
[09:05] <poolie> hi mgz
[09:13] <poolie> ok good night
[09:14] <mgz> night poolie :)
[09:54] <jml> hi
[09:54] <jml> I just answered my own question
[09:55] <jml> apparently I have to update my bzr plugin.
[09:55] <jml> shame on you all!
[10:01] <vila> mgz: hi !
[10:01] <vila> jml: ECONTEXT ??
[10:01] <jml> cannot import name get_trees_and_branches_to_diff
[10:01] <jml> have to update lp:difftodo to call the right API
[10:01] <vila> no deprecation warnings ?
[10:02] <jml> vila: I didn't get any visible ones when running oneiric, no.
[10:03] <jml> vila: might have been in the log though
[10:03] <vila> :-/
[10:08] <mgz> ~_~
[10:09] <jml> anyway, it's been fixed. small enough change.
[10:17] <mgz> odd, lp just told me "bzr+ssh://bazaar.launchpad.net/~gz/bzr/" was not a branch
[10:17] <mgz> when I was actually trying to operate on a (non-existant) child of that
[11:16] <mgz> meh, the locale module is a mess
[11:17] <mgz> the osx not being like posix bug is fixed in 2.7 at least
[11:58] <jelmer> garr, how do I fix the path used for relative paths when using imp.load_module() ?
[12:01] <mgz> why are you using imp.load_module?
[12:01] <jelmer> mgz: loading plugins
[12:02] <mgz> ah.
[12:02] <jelmer> mgz: and because I'm an imp.
[12:03] <jelmer> mgz: we actually discover the kind of a plugin when we scan the plugin directories, and then discard that and actually use "exec 'import ...'" at the moment
[12:04] <jelmer> which then scans all plugin directories again, statting for .so, module.so, .py and .pyc everywhere
[12:04] <mgz> yeah, that's what I thought we did (exec)
[12:05] <mgz> fiddle with sys.path then use __import__?
[12:05]  * mgz throws out more bad ideas for bzrlib.plugin
[12:07] <jelmer> mgz: getting it to work is actually pretty easy - just passing path and description to _load_plugin_module, and calling imp.load_module there
[12:07] <jelmer> mgz: the trouble is that that for some reason breaks relative imports
[12:09] <mgz> you have a pathname that's relative, and it fails?
[12:09] <mgz> (as in, the third argument to load_module)
[12:10] <Sarkle> Hello
[12:11] <jelmer> mgz: I don't have a relative path name actually
[12:11] <jelmer> should it be relative?
[12:12] <mgz> I was wondering what the difference between cases that work and cases that don't is.
[12:13] <jelmer> I haven't seen cases where it does work yet, but it's an interesting point.
[12:30] <jelmer> found it, we were returning the info for the init file rather than the package
[12:31] <mgz> cool.
[12:31] <jelmer> mgz: thanks for the teddybearing :)
[12:35] <mgz> hm, I wonder how many more things changing the setlocale behaviour will break
[12:35] <mgz> I guess that pretty much all bzrlib users other than the bzr script don't call it
[12:46] <mgz> bug 570495
[12:56] <jelmer> mgz: changing the setlocale behaviour in bzrlib?
[13:04] <mgz> jelmer: well, changing some assumptions at least
[13:05] <mgz> bah, using DEPRECATED_PARAMETER seems more likely to break things than help
[13:23] <roryy> argh. i'm trying to add a test for bug 185211, but if i use UTF-8 encoded strings an unrelated problem happens with building the dirstate, and with unicode strings the bug isn't triggered
[13:24] <roryy> it's not always hugely clear when strings should be unicode and when not
[13:24] <jelmer> roryy: I think we're reasonably consistent, but it's probably not very well documented
[13:25]  * mgz giggles a little
[13:26] <mgz> rorry, try just a blackbox test to start with?
[13:26] <mgz> that should give you a way into fixing the bug, it's hard to write a good unit test for an issue when it's not clear what level the problem is at
[13:27] <roryy> i have the fix
[13:27] <mgz> oo, diff? :)
[13:27] <mgz> then I can probably help you with the test
[13:27] <roryy> sure;  it's not very complicated
[13:28] <mgz> in fact, just post an mp with the blackbox test and the change, and we can go from there
[13:28] <mgz> I think I'm even pilot this week
[13:30] <mgz> look at the current tests in bzrlib/tests/blackbox/test_mv.py for the basics
[13:30] <mgz> the ones at the bottom are nearly what you want already
[13:30] <roryy> http://pastebin.com/qsUsgm2E
[13:30] <roryy> ok, it should be easy to make a test based off of the error reproduction script
[13:31] <mgz> roryy: ahahha
[13:31] <roryy> it just looked like the dirstate tests have an *ideal* place for it, if it weren't for this utf-8 weirdness
[13:32] <mgz> yeah, we probably want both anyway, so starting with blackbox is not bad.
[13:35] <vila> mgz: can you update bug #839461 now that 0.9.8 have been deployed on pqm ?
[13:38] <lalatenduM> Hi, I want to fix bugs in https://code.launchpad.net/ubuntu/+source/guake
[13:39] <mgz> vila: sure, will put in my results from the other day as well
[13:39] <lalatenduM> but dont know how to import code from launchpad using bazzaar
[13:39] <lalatenduM> bazaar*
[13:40] <vila> mgz: thanks, my understanding is that it's not critical anymore and I suspect that's the main point of poolie's question
[13:40] <jelmer> hi lalatenduM
[13:40] <lalatenduM> so need  your help
[13:40] <lalatenduM> hi jelmer
[13:41] <jelmer> lalatenduM: are you trying to check out the packaging branch?
[13:42] <lalatenduM> yes, but i am not sure which branch i should chekout if i want to do bug fixing
[13:42] <jelmer> lalatenduM: presumably ubuntu:guake
[13:42] <jelmer> lalatenduM: e.g. "bzr branch ubuntu:guake guake"
[13:45] <lalatenduM> thanks
[13:45] <lalatenduM> let me try this..
[13:52] <lalatenduM> yes..
[13:52] <lalatenduM> it works
[13:56] <lalatenduM> thanks jelmer
[13:56] <jelmer> you're welcome
[14:09] <mgz> good, I think I'm in net code deleted still for the morning
[14:09] <mgz> wonder what else can be got rid of after lunch...
[14:10] <mgz> and... jelmer has already fixed my docstring complaint on his future import branch
[14:11] <mgz> ...which I seem to have not actually posted?
[14:11] <jelmer> mgz: you didn't, but I noticed it myself too
[14:12] <jelmer> mgz: with regard to your branch no_locale_hacks_570495
[14:12] <jelmer> I will say that the code looks prettier, but I'm not sure about what it actually does
[14:47] <mgz> jelmer: I shall try and explain a little more in the mp :)
[14:54] <lalatenduM> jelmer, can you please point me to the code branch of "bzr branch ubuntu:guake guake" in launchpad
[14:54] <lalatenduM> i can't find it lp
[14:54] <lalatenduM> *in lp
[14:56] <jelmer> lalatenduM: http://code.launchpad.net/ubuntu/+source/guake should have all branches relevant for the guake package
[14:57] <lalatenduM> according to http://doc.bazaar.canonical.com/beta/en/tutorials/using_bazaar_with_launchpad.html, "bzr branch lp:project-name/series" should be the syntax
[14:58] <lalatenduM> but i did something else
[14:58] <lalatenduM> i.e. bzr branch ubuntu:guake guake
[14:59] <lalatenduM> i am not able to co relate both sysntax'
[14:59] <lalatenduM> syntax*
[15:05] <vila> jelmer: regarding the error message, the initial issue is that "skipping {file} (larger than {add.maximim} of {20MB} bytes) " is bogus, (of what ?). How about "skipping {file}, larger than {add.maximim} ( {20MB} bytes)"  ?
[15:06] <jelmer> lalatenduM: that's for upstream projects; ubuntu:pkg is a shorthand for lp:ubuntu/pkg
[15:06] <jelmer> vila: Is that message really bogus? it seems valid English to me
[15:07] <jelmer> let's ask a native speaker :)
[15:07] <jelmer> mgz: ^
[15:07] <vila> hehe, yeah :)
[15:07] <hrw> hi
[15:07] <hrw> jelmer: did you tried to use git bzr to merge bzr branches?
[15:07] <jelmer> hi hrw, what's up?
[15:08] <hrw> jelmer: I have criss-cross merge and bzr gaves me 8 conflicting files never mind that those conflicts are fixed in branch which I merge in
[15:08] <jelmer> hrw: what do you mean with git bzr?
[15:08] <hrw> jelmer: bzr::lp: one
[15:09] <jelmer> git after git-remote-bzr?
[15:09] <hrw> yes
[15:09] <jelmer> hrw: if you're merging in bzr, where does git come into the picture?
[15:10] <hrw> I have lp:~hrw/ubuntu/precise/gcc-4.6/gcc-linaro-ci-native branch which base on lp:ubuntu/gcc-4.6 + lot of changes. recently I merged lp:ubuntu/gcc-4.6 into it, fixed conflicts and pushed.
[15:10] <lalatenduM> jelmer: that explains it ubuntu:pkg is a shorthand for lp:ubuntu/pkg
[15:10] <hrw> now I want to merge lp:~hrw/ubuntu/precise/gcc-4.6/gcc-linaro-ci-native into lp:~hrw/ubuntu/precise/gcc-4.6/gcc-linaro-ci-cross
[15:10] <lalatenduM> thanks
[15:10] <hrw> ci-cross one and ci-native one have same base but some differences
[15:11] <hrw> jelmer: and I am thinking about doing git tree with both branches as separate ones + merge them in git
[15:13] <hrw> jelmer: but git/bzr fails on 'git remote update': http://pastebin.com/WpeT1RGD
[15:13] <hrw> jelmer: same for ci-native
[15:14] <jelmer> hrw: going through git means losing all bzr metadata
[15:14] <jelmer> hrw: so I wouldn't recommend doing this until git-remote-bzr supports roundtripping bzr metadata
[15:15] <hrw> k
[15:17] <hrw> is bzr and merges between few branches asking for problems?
[15:17] <hrw> I have branch-upstream + branch-c/branch-n. both -c and -n branched from upstream and merge them and each other
[15:21] <mgz> vila, jelmer: not having the parens at all would be good, and maybe statng what add.max actually is (the name of a config option), but the current does make sense
[15:22] <jelmer> hrw: that should be fine - you're getting conflicts in that case?
[15:22] <jelmer> hrw: if you're doing criss-cross merges, you may want "bzr merge --lca"
[15:22] <hrw> jelmer: --weave and --lca == same
[15:23] <jml> you guys are running pkgimport with bzr as a branch dependency, right?
[15:25] <vila> mgz: ok, so either I'll leave it as is or you can give me your proposed phrasing and I'll take that
[15:25] <vila> jml: by setting PYTHONPATH yes
[15:26] <vila> jml: by the way, I've tested udd trunk with your changes locally and will deploy it next time I can
[15:26] <jml> vila: hurrah.
[15:27] <jelmer> hrw: same results you mean? They're definitely different merge algorithms.
[15:28] <hrw> jelmer: same as '8 files conflicted'
[15:28] <hrw> jelmer: now I am merging file after file and see same merges which I did in ci-native (which I merge into)
[15:30] <jelmer> hrw: right, that's often an issue with criss-cross merges
[15:30] <jelmer> hrw: you might want to post to the list about this, I'm not really an expert on merge algorithms
[15:31] <hrw> jelmer: can you give me email to ml?
[15:31] <jelmer> hrw: bazaar@lists.canonical.com
[15:31] <lalatenduM> jelmer: after I imported code from lp. I have created a personal branch at https://code.launchpad.net/~then4way/+junk/guake
[15:31] <jelmer> hrw: or, if you have a short script of reproducing it for a merge that you think we should be handling better, please file a bug
[15:31] <lalatenduM> and pushed the code to it
[15:32] <lalatenduM> bzr push --use-existing lp:~then4way/+junk/guake
[15:33] <hrw> will report bug
[15:33] <lalatenduM> For maintaining a version system, i think i have to do "bzr init;bzr add; bzr commit -m "Initial Import"". Right?
[15:34] <lalatenduM> I have used wincvs, perforce but new to bzr
[15:37] <jelmer> lalatenduM: yep
[15:37] <lalatenduM> thanks
[15:40] <hrw> bug 906370
[15:41] <hrw> I do not have better idea for title at the moment
[15:45] <jelmer> mgz: I'm going to approve your locale branch
[15:45] <jelmer> mgz: be aware though, that we'll assign all encoding-related bugs to you for the next couple of months :P
[15:48] <mgz> ehehe
[15:56] <mgz> anyone want to review my "oops, I completely broke windows" branch?
[15:57] <mgz> jelmer: I'm also interested in if you have debugging ideas for tracking actual socket connections
[15:58] <mgz> as I still need to work out if the gap between transport tracking old and new is real or bogus connections
[16:10] <jelmer> mgz: hmm
[16:12] <jelmer> mgz: it doesn't seem particularly tricky to me - we just have to call out to a new hook when we create a socket or ask somebody else (curl, paramiko, ...) to create one for us
[16:12] <jelmer> mgz:  your last sentence doesn't parse for me
[16:13] <mgz> hm, okay
[16:13] <mgz> basically, I did some testing on... Friday? that got me a list of transports seen by both the old get_transport hack and the new hook
[16:14] <jelmer> ah
[16:14] <jelmer> mgz: ... and you saw a difference?
[16:14] <mgz> I want to work out which of the differences are due to bugs fixed (a transport that wasn't connected now not tracked),
[16:15] <mgz> and which are due to bugs created (a transport that is connected now not tracked)
[16:15] <jelmer> mgz: I guess as long as you're just interested in seeing what the difference is
[16:16] <jelmer> mgz: you could move the body of get_transport_from_url() into a new method, and have that method's return value indicate whether it reused an existing transport
[16:16] <jelmer> ... and then use that method in bzrlib.tests as well, and discard anything that reused an existing transport
[16:18] <mgz> I think I cover that already by using set()
[16:19] <mgz> but perhaps not.
[16:19] <mgz> hm, no, _reuse_for does get a new instance
[16:25] <mgz> so, eg, currently bb.test_branch.TestRemoteBranch.test_branch_local_remote sees 4 _SharedConnection objects
[16:27] <mgz> and with the hook the same test has 3 _SharedConnection objects
[16:30] <jelmer> hmm
[16:31] <jelmer> can you tell what the classes of those connections are?
[16:32] <mgz> yup, paramiko.SFTPClient in this case.
[16:33] <mgz> and using that as the key gives different results again
[16:35] <vila> mgz: forget about SFTPClient, they use a dedicated thread that you cannot track, they are the cause of the last known  leak IIRC
[16:36] <mgz> but we can see if the connection actually happens I trust?
[16:36] <vila> the hook should be more precise in this case though
[16:36] <vila> hmm, I think so, the shared connection is not the socket itself but rather the paramiko transport object right ?
[16:37] <mgz> yup.
[16:37] <vila> so I think you get one only after the connection really occurs
[16:37] <mgz> and if we have one do we known the underlying sock... cool
[16:37] <vila> 90% sure
[16:38] <vila> do we have a disconnect() implemented there ?
[16:39] <vila> bah, certainly, so you may not precisely track the underlying socket, but it's good enough as paramiko will close it later (in theory)
[16:40] <mgz> yup, the hook looks good here
[16:41] <mgz> the difference is on the following transport:
[16:41] <vila> mgz: sry, my memory is failing me again, did you end up fixing the news_merge config on pqm ?
[16:41] <mgz> ('sftp://foo@127.0.0.1:39740/tmp/testbzr-PK83Bv.tmp/bzrlib.tests.blackbox.test_branch.TestRemoteBranch.test_branch_local_remote/work/', None, None)
[16:41] <mgz> vila: nope, we need to know where the real locations.conf is
[16:42] <vila> ha, right, mthaddon should know
[16:42] <mgz> ^that's (transport.base, transport._shared_connection.connection, transport._shared_connection.base)
[16:42] <mgz> so, it's a transport that gets created but never connects
[16:44] <mgz> next, the http case...
[16:44] <vila> transport._shared_connection.base ??? What's that used for ?
[16:45] <mgz> no idea, I thought I'd print it to see
[16:45] <mgz> 's always None in this case
[16:48] <vila> weird, both 'connection' and 'credentials'  is used as an opaque container are supposed to be opaque and transport specific but still related to the connection, having a 'base' there.... sounds bogus
[16:48] <vila> nm, unrelated to your work anyway
[16:50] <mgz> ...looks like it's just used by the smart server?
[16:51] <vila> it should probably be part of either connection or credentials
[16:54] <hrw> help? I created small recipe to test something. It uses lp:ubuntu/gcc-4.6 as base branch and then merges my lp:~hrw/+junk/ci-gcc-cross-armel branch into it. my branch contains one commit which adds debian/target file. But on 'bzr dailydeb' run I am getting merge conflicts... on directory ;(
[16:55] <hrw> http://pastebin.com/mLEmqPpr is output and recipe
[17:07] <jelmer> hrw: looking...
[17:08] <hrw> jelmer: thanks
[17:08] <jelmer> hrw: is lp:~hrw/+junk/ci-gcc-cross-armel actually derived from lp:ubuntu/gcc-4.6 ?
[17:08] <hrw> jelmer: not at all
[17:08] <jelmer> hrw: it doesn't appear to be, so the identity of the debian/ directory is different.
[17:09] <hrw> jelmer: so I should base on gcc-4.6 and remove all files in one commit to get same result but mergeable?
[17:09] <jelmer> hrw: I'd recommend creating lp:~hrw/+junk/ci-gcc-cross-armel as a branch that derives from lp:ubuntu/gcc-4.6 and actually adds the the file that way
[17:09] <hrw> jelmer: I want to not do any changes in my branch - just to have one file there so launchpad will do all work for me
[17:10] <jelmer> hrw: right, my suggestion should do that
[17:10] <hrw> ok
[17:10] <jelmer> hrw: just create lp:~hrw/+junk/ci-gcc-cross-armel as a clone of lp:ubuntu/gcc-4.6 with one additional commit that adds debian/target.
[17:11] <hrw> jelmer: this way I would have to update my branch each time when lp:ubuntu/gcc-4.6 is updated.
[17:11] <hrw> jelmer: will try my idea
[17:11] <jelmer> hrw: no
[17:11] <jelmer> hrw: launchpad will happily merge, as long as nobody creates a target file in lp:ubuntu/gcc-4.6
[17:12] <jelmer> if somebody creates a target file in lp:ubuntu/gcc-4.6 then it will (correctly) conflict
[17:13] <hrw> jelmer: ah. now I see - had to think a moment
[17:22] <achiang> hello, should 'bzr launchpad-login' be expected to work in a console environment? (remote server)
[17:22] <jelmer> achiang: hi
[17:22] <jelmer> achiang: yes
[17:23] <achiang> jelmer: hm, perhaps i'm just hitting an issue in precise?
[17:23] <achiang> ubuntu@server-3424:~/Projects$ bzr launchpad-login achiang
[17:23] <achiang> WARNING: gnome-keyring:: no socket to connect to
[17:23] <jelmer> achiang: what are you seeing?
[17:23] <jelmer> achiang: are there any plugins installed on the remote server ("bzr plugins") ?
[17:24] <hrw> jelmer: it works - thanks
[17:24] <achiang> jelmer: http://pastebin.ubuntu.com/775503/
[17:28] <mgz> vila: okay, I think I'm caught up with your thinking on the post_connect hook
[17:30] <jelmer> achiang: hmm, I don't think any of those use gnome-keyring
[17:31] <achiang> jelmer: trying to recreate with an older version of ubuntu now
[17:31] <jelmer> achiang: my guess is that we're loading launchpadlib and that's using gnome-keyring
[17:31] <jelmer> lp-login shouldn't actually be using launchpadlib though
[17:33]  * achiang patiently waits for another openstack instance to start up
[17:43] <achiang> jelmer: ok, as a test, i tried natty, and bzr launchpad-login works fine in headless mode
[17:44] <hrw> bye
[17:44] <achiang> jelmer: shall i file a bug?
[17:48] <jelmer> achiang: please do
[17:48] <achiang> jelmer: ok, will do
[17:48] <jelmer> achiang: can you perhaps run "bzr --profile-imports lp-login ... 2>x" and pastebin x ?
[17:50] <achiang> jelmer: what plugin provides profile-imports?
[17:50] <jelmer> achiang: sorry, nevermind. it requires a lp:bzr checkout
[17:50] <jelmer> I forgot about that
[17:51] <achiang> ok
[18:14] <Noldorin_> hi folks
[18:16] <jelmer> hi Noldorin_
[18:16] <Noldorin_> jelmer, hey
[18:22] <achiang> jelmer: https://bugs.launchpad.net/bzr/+bug/906452 ; it probably needs to go into the proper bucket, etc.
[18:27] <jelmer> achiang: oh, it doesn't actually let you continue? I thought it just warned
[18:27] <jelmer> achiang: in that case, can you run "BZR_PDB=1 bzr lp-login ..." ?
[18:30] <achiang> jelmer: oh! maybe it does let you continue. i didn't realize that was just a warning
[18:30] <achiang> jelmer: um, except the big huge WARNING on the command line
[18:31] <achiang> not sure why my brain turned off
[18:31] <achiang> jelmer: yes, so it does actually work
[18:31] <jelmer> cool, that warning is still odd though
[18:32] <jelmer> I'll change the title on the bug report though, thanks for filing it
[18:32] <achiang> jelmer: thanks
[19:44] <ggherdov> hi all, how do I run just a single unit test from bzrlib/tests ?
[19:48] <ggherdov> the page http://doc.bazaar.canonical.com/developers/testing.html isn't quite clear about it, it mention testrepository but... well... there is no cut-and-pasteable commands :-)
[19:49] <jelmer> ggherdov: ./bzr selftest <python-path>
[19:49] <jelmer> ggherdov: e.g. ./bzr selftest bzrlib.tests.test_foo
[19:49] <ggherdov> jelmer: thx. trying right away!
[19:53] <ggherdov> jelmer: enigmatic answer, http://pastebin.com/cDmWYfV6
[19:53] <ggherdov> 0 tests ?
[19:53] <ggherdov> can I make it more verbose?
[20:00] <jelmer> ggherdov: verbose in what way?
[20:01] <jelmer> ggherdov: the test you specified doesn't exist
[20:01] <ggherdov> ah.
[20:01] <jelmer> ggherdov: I think you want bzrlib.tests.test_merge.TestPlanMerge.test_plan_merge_tail_ancestors
[20:02] <ggherdov> you are right.
[20:02] <ggherdov> '-.-
[20:23] <Noldorin_> hi wgz
[20:46] <wgz> Noldorin_: didn't mention yesterday, another option is just using the cygwin bzr package: <http://cygwin.com/packages/bzr/>
[20:46] <wgz> ggherdov: use -s too! see `bzr help selftest`
[20:47] <ggherdov> wgz: thank, checking it
[21:01] <poolie> hi jelmer, wgz
[21:01] <wgz> hey poolie!
[21:16] <jelmer> 'evening poolie, wgz
[21:28] <Noldorin_> wgz, lol, nooow you say ;-)
[21:29] <Noldorin_> wgz, that would probably do the job yeah :-)
[21:29] <Noldorin_> cheers
[21:42] <Noldorin_> hi poolie
[21:42] <Noldorin_> haven't seen you around in a while
[21:43] <poolie> hi there
[21:43] <Noldorin_> wgz, i mean, it would do everything i want right? :-)
[21:43] <poolie> i have been taking some holidays
[21:43] <poolie> but i'm back for a few days now
[21:43] <Noldorin_> ah nice
[21:43] <Noldorin_> well deserved i think
[21:43] <Noldorin_> yeah
[21:43] <Noldorin_> before Christmas i suppoe.
[21:45] <Noldorin_> well-timed :-P
[21:54] <iamfuzz> Is there a way in bzr to have it automatically checkout and nest another branch, i.e. submodules (IIRC) in svn?
[21:54] <iamfuzz> we keep our packaging in one branch and code in another, and I was curious if there was a way to have the bzr checkout do such a thing
[21:55] <poolie> iamfuzz, for the specific case of packaging you might like to use bzr builder
[21:55] <poolie> http://doc.bazaar.canonical.com/plugins/en/builder-plugin.html
[21:55] <poolie> which is what we use for ubuntu recipes
[21:55] <poolie> otherwise http://doc.bazaar.canonical.com/plugins/en/scmproj-plugin.html
[21:55] <iamfuzz> many thanks, I'll givem a read
[22:17] <Noldorin_> poolie, so, do you think it would be possible to stage a dev version of launchpad on y win2k8r2 box?
[22:50] <poolie> Noldorin_, hi, do you mean running it natively on windows?
[22:50] <poolie> it might be fairly hard
[22:50] <poolie> there are probably a lot of unix assumptions
[22:50] <poolie> Noldorin_, i would probably run ubuntu in a vm to start with
[22:51] <Noldorin_> poolie, hmm how about cygwin??
[22:52] <poolie> well
[22:52] <poolie> what are you trying to accomplish?
[22:52] <poolie> to be able to fix bugs or add features to lp?
[23:09] <poolie> Noldorin_, so i think i can guarantee it will not just work under cygwin
[23:09] <poolie> the problems might be surmountable
[23:10] <poolie> i think it would be at least days to get everything installed and working
[23:10] <poolie> it depends a bit on whether you want to run just one thing or the whole deal
[23:57] <Noldorin_> poolie, sorry, back now
[23:57] <Noldorin_> poolie, yeah, so by far the easiest would be a Ubuntu VM eh?