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