| jelmer | 'morning poolie, wgz | 00:21 |
|---|---|---|
| jelmer | I'm sure a pangolin is safer than riding an ocelot.. :-) | 00:21 |
| poolie | hi there | 00:21 |
| wgz | Noldorin: bug 906109 | 00:59 |
| ubot5 | Launchpad bug 906109 in Bazaar "LockContention moving directory under symlink path to different volume" [Low,Confirmed] https://launchpad.net/bugs/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 | 00:59 |
| Noldorin | wgz, cheers | 01:02 |
| poolie | vila, hi? | 07:22 |
| vila | hi all ! | 07:33 |
| vila | poolie: hey ! | 07:33 |
| poolie | hi there | 07:33 |
| === yofel_ is now known as yofel | ||
| mgz | morning all! | 09:03 |
| poolie | hi mgz | 09:05 |
| poolie | ok good night | 09:13 |
| mgz | night poolie :) | 09:14 |
| jml | hi | 09:54 |
| jml | I just answered my own question | 09:54 |
| jml | apparently I have to update my bzr plugin. | 09:55 |
| jml | shame on you all! | 09:55 |
| 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:01 |
| jml | vila: I didn't get any visible ones when running oneiric, no. | 10:02 |
| jml | vila: might have been in the log though | 10:03 |
| vila | :-/ | 10:03 |
| mgz | ~_~ | 10:08 |
| jml | anyway, it's been fixed. small enough change. | 10:09 |
| 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 | 10:17 |
| === quicksil1er is now known as quicksilver | ||
| mgz | meh, the locale module is a mess | 11:16 |
| mgz | the osx not being like posix bug is fixed in 2.7 at least | 11:17 |
| jelmer | garr, how do I fix the path used for relative paths when using imp.load_module() ? | 11:58 |
| mgz | why are you using imp.load_module? | 12:01 |
| jelmer | mgz: loading plugins | 12:01 |
| mgz | ah. | 12:02 |
| jelmer | mgz: and because I'm an imp. | 12:02 |
| 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:03 |
| 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:04 |
| mgz | fiddle with sys.path then use __import__? | 12:05 |
| * mgz throws out more bad ideas for bzrlib.plugin | 12:05 | |
| 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:07 |
| mgz | you have a pathname that's relative, and it fails? | 12:09 |
| mgz | (as in, the third argument to load_module) | 12:09 |
| Sarkle | Hello | 12:10 |
| jelmer | mgz: I don't have a relative path name actually | 12:11 |
| jelmer | should it be relative? | 12:11 |
| mgz | I was wondering what the difference between cases that work and cases that don't is. | 12:12 |
| jelmer | I haven't seen cases where it does work yet, but it's an interesting point. | 12:13 |
| jelmer | found it, we were returning the info for the init file rather than the package | 12:30 |
| mgz | cool. | 12:31 |
| jelmer | mgz: thanks for the teddybearing :) | 12:31 |
| 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:35 |
| mgz | bug 570495 | 12:46 |
| ubot5 | Launchpad bug 570495 in Bazaar "bzr should not change sys.platform or should limit it to the affected python versions" [Medium,Confirmed] https://launchpad.net/bugs/570495 | 12:46 |
| === nigelb_ is now known as nigelb | ||
| jelmer | mgz: changing the setlocale behaviour in bzrlib? | 12:56 |
| mgz | jelmer: well, changing some assumptions at least | 13:04 |
| mgz | bah, using DEPRECATED_PARAMETER seems more likely to break things than help | 13:05 |
| 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:23 |
| ubot5 | Launchpad bug 185211 in Bazaar "renaming out of directory with unicode name fails with InconsistentDelta" [High,Confirmed] https://launchpad.net/bugs/185211 | 13:23 |
| 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:24 |
| * mgz giggles a little | 13:25 | |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:30 |
| 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:31 |
| mgz | yeah, we probably want both anyway, so starting with blackbox is not bad. | 13:32 |
| vila | mgz: can you update bug #839461 now that 0.9.8 have been deployed on pqm ? | 13:35 |
| ubot5 | Launchpad bug 839461 in Bazaar "can't run selftest for 2.2 with recent subunit/testtools" [Critical,Confirmed] https://launchpad.net/bugs/839461 | 13:35 |
| lalatenduM | Hi, I want to fix bugs in https://code.launchpad.net/ubuntu/+source/guake | 13:38 |
| 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:39 |
| 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:40 |
| jelmer | lalatenduM: are you trying to check out the packaging branch? | 13:41 |
| 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:42 |
| lalatenduM | thanks | 13:45 |
| lalatenduM | let me try this.. | 13:45 |
| lalatenduM | yes.. | 13:52 |
| lalatenduM | it works | 13:52 |
| lalatenduM | thanks jelmer | 13:56 |
| jelmer | you're welcome | 13:56 |
| 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:09 |
| mgz | and... jelmer has already fixed my docstring complaint on his future import branch | 14:10 |
| mgz | ...which I seem to have not actually posted? | 14:11 |
| jelmer | mgz: you didn't, but I noticed it myself too | 14:11 |
| 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:12 |
| mgz | jelmer: I shall try and explain a little more in the mp :) | 14:47 |
| 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:54 |
| jelmer | lalatenduM: http://code.launchpad.net/ubuntu/+source/guake should have all branches relevant for the guake package | 14:56 |
| 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:57 |
| lalatenduM | but i did something else | 14:58 |
| lalatenduM | i.e. bzr branch ubuntu:guake guake | 14:58 |
| lalatenduM | i am not able to co relate both sysntax' | 14:59 |
| lalatenduM | syntax* | 14:59 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| hrw | jelmer: and I am thinking about doing git tree with both branches as separate ones + merge them in git | 15:11 |
| hrw | jelmer: but git/bzr fails on 'git remote update': http://pastebin.com/WpeT1RGD | 15:13 |
| hrw | jelmer: same for ci-native | 15:13 |
| 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:14 |
| hrw | k | 15:15 |
| 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:17 |
| 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:21 |
| 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:22 |
| jml | you guys are running pkgimport with bzr as a branch dependency, right? | 15:23 |
| 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:25 |
| 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:26 |
| jelmer | hrw: same results you mean? They're definitely different merge algorithms. | 15:27 |
| 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:28 |
| 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:30 |
| 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:31 |
| lalatenduM | bzr push --use-existing lp:~then4way/+junk/guake | 15:32 |
| 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:33 |
| lalatenduM | I have used wincvs, perforce but new to bzr | 15:34 |
| jelmer | lalatenduM: yep | 15:37 |
| lalatenduM | thanks | 15:37 |
| hrw | bug 906370 | 15:40 |
| ubot5 | Launchpad bug 906370 in bzr (Ubuntu) "merging generated conflicts which should be handled" [Undecided,New] https://launchpad.net/bugs/906370 | 15:40 |
| hrw | I do not have better idea for title at the moment | 15:41 |
| === jpds_ is now known as jpds | ||
| 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:45 |
| mgz | ehehe | 15:48 |
| mgz | anyone want to review my "oops, I completely broke windows" branch? | 15:56 |
| mgz | jelmer: I'm also interested in if you have debugging ideas for tracking actual socket connections | 15:57 |
| mgz | as I still need to work out if the gap between transport tracking old and new is real or bogus connections | 15:58 |
| jelmer | mgz: hmm | 16:10 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| mgz | I think I cover that already by using set() | 16:18 |
| mgz | but perhaps not. | 16:19 |
| mgz | hm, no, _reuse_for does get a new instance | 16:19 |
| mgz | so, eg, currently bb.test_branch.TestRemoteBranch.test_branch_local_remote sees 4 _SharedConnection objects | 16:25 |
| mgz | and with the hook the same test has 3 _SharedConnection objects | 16:27 |
| jelmer | hmm | 16:30 |
| jelmer | can you tell what the classes of those connections are? | 16:31 |
| mgz | yup, paramiko.SFTPClient in this case. | 16:32 |
| mgz | and using that as the key gives different results again | 16:33 |
| 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:35 |
| 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:36 |
| 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:37 |
| vila | do we have a disconnect() implemented there ? | 16:38 |
| 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:39 |
| mgz | yup, the hook looks good here | 16:40 |
| 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:41 |
| 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:42 |
| mgz | next, the http case... | 16:44 |
| vila | transport._shared_connection.base ??? What's that used for ? | 16:44 |
| mgz | no idea, I thought I'd print it to see | 16:45 |
| mgz | 's always None in this case | 16:45 |
| 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:48 |
| mgz | ...looks like it's just used by the smart server? | 16:50 |
| vila | it should probably be part of either connection or credentials | 16:51 |
| 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:54 |
| hrw | http://pastebin.com/mLEmqPpr is output and recipe | 16:55 |
| jelmer | hrw: looking... | 17:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| jelmer | if somebody creates a target file in lp:ubuntu/gcc-4.6 then it will (correctly) conflict | 17:12 |
| hrw | jelmer: ah. now I see - had to think a moment | 17:13 |
| 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:22 |
| 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:23 |
| hrw | jelmer: it works - thanks | 17:24 |
| achiang | jelmer: http://pastebin.ubuntu.com/775503/ | 17:24 |
| mgz | vila: okay, I think I'm caught up with your thinking on the post_connect hook | 17:28 |
| jelmer | achiang: hmm, I don't think any of those use gnome-keyring | 17:30 |
| 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:31 |
| * achiang patiently waits for another openstack instance to start up | 17:33 | |
| achiang | jelmer: ok, as a test, i tried natty, and bzr launchpad-login works fine in headless mode | 17:43 |
| hrw | bye | 17:44 |
| achiang | jelmer: shall i file a bug? | 17:44 |
| 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:48 |
| 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:50 |
| achiang | ok | 17:51 |
| Noldorin_ | hi folks | 18:14 |
| jelmer | hi Noldorin_ | 18:16 |
| Noldorin_ | jelmer, hey | 18:16 |
| achiang | jelmer: https://bugs.launchpad.net/bzr/+bug/906452 ; it probably needs to go into the proper bucket, etc. | 18:22 |
| ubot5 | Ubuntu bug 906452 in Bazaar "console launchpad-login broken in Precise" [Undecided,New] | 18:22 |
| 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:27 |
| 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:30 |
| 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:31 |
| jelmer | I'll change the title on the bug report though, thanks for filing it | 18:32 |
| achiang | jelmer: thanks | 18:32 |
| ggherdov | hi all, how do I run just a single unit test from bzrlib/tests ? | 19:44 |
| 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:48 |
| 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:49 |
| ggherdov | jelmer: enigmatic answer, http://pastebin.com/cDmWYfV6 | 19:53 |
| ggherdov | 0 tests ? | 19:53 |
| ggherdov | can I make it more verbose? | 19:53 |
| jelmer | ggherdov: verbose in what way? | 20:00 |
| 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:01 |
| ggherdov | you are right. | 20:02 |
| ggherdov | '-.- | 20:02 |
| Noldorin_ | hi wgz | 20:23 |
| 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:46 |
| ggherdov | wgz: thank, checking it | 20:47 |
| poolie | hi jelmer, wgz | 21:01 |
| wgz | hey poolie! | 21:01 |
| jelmer | 'evening poolie, wgz | 21:16 |
| Noldorin_ | wgz, lol, nooow you say ;-) | 21:28 |
| Noldorin_ | wgz, that would probably do the job yeah :-) | 21:29 |
| Noldorin_ | cheers | 21:29 |
| Noldorin_ | hi poolie | 21:42 |
| Noldorin_ | haven't seen you around in a while | 21:42 |
| 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:43 |
| Noldorin_ | well-timed :-P | 21:45 |
| 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:54 |
| 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 | 21:55 |
| Noldorin_ | poolie, so, do you think it would be possible to stage a dev version of launchpad on y win2k8r2 box? | 22:17 |
| 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:50 |
| Noldorin_ | poolie, hmm how about cygwin?? | 22:51 |
| 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? | 22:52 |
| poolie | Noldorin_, so i think i can guarantee it will not just work under cygwin | 23:09 |
| poolie | the problems might be surmountable | 23:09 |
| 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:10 |
| Noldorin_ | poolie, sorry, back now | 23:57 |
| Noldorin_ | poolie, yeah, so by far the easiest would be a Ubuntu VM eh? | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!