[06:08] hi all ! [06:09] hi there vila [06:10] poolie: _o/ [06:12] * fullermd waves in some vague direction. [06:28] hi md [06:55] morning all [07:03] jam: _o/ [07:04] mgz: welcome on board ! === jpds_ is now known as jpds [07:24] hi, is there a shortcut to remove the working tree from a branch? [07:24] bzr remove-tree [07:25] lifeless: thanks [07:27] lifeless: what about for a shared repo? [07:27] same [07:49] vila, so we agreed we're going to try to release lazr.restful, package it, etc? [07:49] if i don't get to it first you can [07:52] poolie: weren't we going to do the 1:1 today? [07:52] yes, hi [07:53] was (unnecessarily) waiting for you [07:54] poolie: ah, I said hi around 9, but you probably missed it [07:54] I didn't see you talking, so didn't think you were around [07:55] shall we talk here or on the phone? [07:55] poolie: either is fine by me [07:56] ok just busy here for a sec [07:57] np [07:57] I am getting this msg with the emacs repo. How to fix it? http://paste.pound-python.org/show/13019 [08:02] leo2007, 'bzr tag --delete mh-e-8.3' and mh-e-doc-8.3 [08:02] then pull again [08:03] poolie: many thanks. [08:05] morning all. [08:07] I am running Bazaar (bzr) 2.3.1. Is there sth I need to pay attention to when upgrading to 2.4.1 [08:08] some pages look like this on chrome http://imagebin.org/174112 [08:17] leo2007, no, upgrading to 2.4.1 is safe [08:17] leo2007, that's interesting [08:17] i don't think it's connected to bzr [08:17] are you in the middle of upgrading your os, perhaps? [08:19] mgz, hello! [08:19] hi poolie! [08:20] hi there [08:20] welcome [08:20] :) [08:20] hey mgz! Good morning to you! And welcome to the gang :) [08:23] leo2007: If you're upgrading the OS, I've seen some weird bits with rendering and certain Video drivers. It seems launchpad uses a very large image and then pulls sprites out of it. But its never hidden the text, just certain icons for me. [08:23] (all, mgz is joining Canonical starting today, there will be mail in a little bit) [08:23] mgz, when did you plan to typically start your day - around 9? [08:24] yes, planning to do that to start with then if it turns out to be better to do earlier or later will adjust. [08:31] jam: no I am not upgrading os. [08:32] leo2007: the only thing you upgraded was bzr and you started getting weird rendering in Chrome. Seems odd. [08:32] leo2007, suggest we ask in #launchpad [08:34] no, no, I was browsing the bzr website and some of its pages load weirdly [08:40] mgz: |0/ [08:40] oops \o/ I meant :) [08:41] ok, now I am on 2.4.1 ;) [08:46] vila: I should hope that's what you meant. Otherwise, there's something wrong with your head... [08:46] smoke going out mainly [08:46] okay, getting there... [09:32] hi mgz, flapping much? [09:33] just trying to work out what I'm going to do over email :) [10:44] jam: You mentioned making a few updates to your 2.5-soft-hangup MP, but they don't appear to be on lp yet? [10:45] jelmer: I did push, but not commit :) [10:45] should be there now [10:45] heh, thanks [10:45] * jelmer waits for the MP to update [10:46] I'm looking forward to those longpoll changes to launchpad... [11:00] if I have a string of a class's name, how can I instansiate the class? [11:01] I guess something like eval(name)() assuming the class is properly imported, etc [11:01] Riddell: why would you want to though? It's usually a bad idea [11:01] jelmer: because your rewrite plugin lists the commands as strings in the info.py file :) [11:02] Riddell: heh, ok [11:02] Riddell: there is a method for looking up command classes by string [11:03] Riddell: bzrlib.command.get_cmd_object [11:04] jelmer: I don't think that'll work though if the plugin isn't installed [11:04] Riddell: true [11:04] Riddell: what are you trying to do exactly, what do you need? [11:05] exporting the strings from rewrite plugin [11:05] ... without having it installed ? [11:05] I think expecting the plugin to be installed is too much of an assumption [11:07] Riddell: why do you need to look up classes though? [11:07] I need to instansiate the class to pass it to bzrlib.export_pot._write_command_help [11:08] Riddell: if you need to instantiate anything, that requires loading the plugin [11:09] Riddell: that doesn't seem too bad though, it's always possible to use the BZR_PLUGINS_AT env variable [11:09] it works fine to just run cmd_rebase() [11:12] Riddell: that's not guaranteed for any of the other plugins though, which may rely on other code in __init__.py having run [11:15] Riddell: it's odd that just cmd_rebase() would work - did you import anything else, do you have bzr-rewrite installed perhaps? [11:16] jelmer: this is what I have http://paste.kde.org/127417/ [11:17] Riddell: that's only going to work if you have the plugin installed [11:18] Riddell: it also assumes that the commands are living in commands.py, which isn't necessarily true [11:18] okay, I've sent a hello message to the mailing list [11:18] jelmer: I don't have rewrite installed (according to `bzr plugins` [11:18] if someone is free later to try testing out voip things with me, that would be really handy [11:18] jelmer: well this is specific to bzr-rewrite, other plugins would have to adapt [11:18] mgz: ah, you're on a new mailing list, that's exiting :) [11:19] mgz: I've never done voip, how are you setting it up? [11:20] on this machine if at all possible, otherwise I'll just use my phone [11:20] mgz: hello! [11:21] jelmer: hi, nice to meet you! [11:21] Riddell: I'd personally prefer something more generic, even if that somehow requires loading the plugin [11:22] Riddell: importing info and commands is going to load some bits of the plugin anyway, so I don't really see how what it gains us [11:22] mgz: :) [11:23] jelmer: well this way e.g. packagers can run make update-pot and know it'll work, if you have to have the plugin installed it might pick up the wrong version of the plugin or not work at all [11:24] Riddell: This is much more likely to regress because importing commands might require on side-effects from __init__ [11:24] riddell: there are ways to load plugins from specific locations [11:25] vila: ^ [11:25] BZR_PLUGINS_AT ? [11:25] mgz: doesn't a voip account require asking sysadmin for one, or are you not using canonical's server? [11:26] Riddell: I got my VOIP credentials by email automatically on my first day? [11:26] It's a rite of passage. You're supposed to hack into the server and set yourself up... [11:27] jelmer: Not sure I understand the question :-} [11:28] jelmer: if there is anything I can do to make it easier to review my changes, just ask. I'm happy to discuss them line-by-line, etc. [11:28] jam: I'm having another look at them now [11:29] mgz: I've got voip set up if you want to test it, or mumble, or whatever [11:31] vila: I need objects of cmd_rebase etc from the rewrite plugin so I can pass them to export_pot._write_command_help() and get the translations [11:31] Riddell: about your pasted snippet, beware that '-' is translated to '_' between the command name and command class name, get_command_object which should take care of that [11:32] it seems to work fine if I just do foo = cmd_rebase() but that might not be reliable for all commands [11:35] not all plugins use the info.py trick and the ones who do don't necessarily declare bzr_commands :) [11:35] .. and not all of them have their commands living in commands.py [11:35] yeah, so, bzrlib.commands.plugin_cmds may be a better source [11:42] mm [12:04] jam: I'm getting an additional leaked thread from bb.test_serve with your MP [12:05] jelmer: I don't.... [12:05] but let me check another machine [12:05] jam: aren't you missing a call to finish_bzr_subprocess? [12:05] jelmer: could be [12:06] that fixes it for me, fwiw [12:06] http://pastebin.ubuntu.com/697224/ [12:07] jelmer: I'm calling "assertFinishesCleanly" right? [12:07] jam: nope [12:07] hmm, I was [12:08] jam: IIRC assertFinishesCleanly tries to send a SIGINT [12:08] jelmer: so add assertFinshesCleanly [12:08] after the readline [12:08] for the test involved either is fine. [12:08] All I'm testing is that you *can* connect, and that SIGHUP triggers the shutdown code. [12:08] jam: assertFinishesCleanly doesn't work: [12:09] a = 'bzr: interrupted\n' [12:09] b = 'Waiting for 1 client(s) to finish\nbzr: interrupted\n' [12:09] If we want, I can extend that code and make sure it doesn't actually stop [12:09] finish_bzr_subprocess seems fine though [12:09] since it doesn't check stdout [12:09] jelmer: and, TBH, that "waiting for 1 client" is going to be random, depending on timeouts, etc. [12:09] jelmer: let me poke at that one, I actually want to do something like the 1MB tests I was doing elsewhere. [12:10] here's another one I hit: http://pastebin.ubuntu.com/697229/ [12:10] we could certainly leave the test to only make sure that "Requested to stop gracefully" and assume that means everything is hooked up [12:10] jelmer: thx, I've been doing mixed windows and Linux testing. And I changed that line from 'signal.signal.' to signal.getsignal [12:11] but didn't notice because it doesn't run on Windows. [12:11] jelmer: so... What do you think about having a test that writes 1MB to disk? It seems a bit ugly. I want it to be larger than the socket buffer, though. [12:13] jam: is it really writing 1MB to disk? from my reading of the test it seemed like it put 1Mb on a memorytransport [12:13] jelmer: that was the other tests. I'm thinking to adapt the 'bb.test_serve' test to do something similar [12:13] 64kB is probably enough [12:14] (waits for fuller-md to notice :) [12:15] It's not a real test unless it's a prime number. [12:23] jam: It seems pretty well tested at this point, what's the reason you're thinking of having the bb.test_serve test do something similasr? [12:23] *similar [12:23] jelmer: acceptance test [12:23] since it is a 'blackbox' test. [12:23] hmm [12:24] is there a portable way to set the socket buffer size/ [12:24] ? [12:26] jam: if there's no other way to test it, then it doesn't seem too unreasonable. Of course, we shouldn't be doing stuff like this in too many tests.. [12:26] jelmer: there is setsockopt(SO_SNDBUF) [12:26] Though I'm pretty sure 64kB is sufficient, 1MB I would think is quite big [12:27] jelmer: the test passes on devpad at 64kB [12:27] jelmer: if I did it correctly, there is only ~1 new acceptance test is bb.test_server [12:27] I agree that we shouldn't do them for most testing [12:28] jam: that seems perfectly fine to me, fwiw [12:30] jelmer: updated test pushed [12:30] and the fix for signal.getsignal [12:30] well, pushed now. (had to put in ssh key:) [12:30] r6021 [12:30] r6201 [12:36] jam: lo [12:36] jam: sorryu [12:37] argh, my keyboard is acting up [12:37] jam: Anyway, I was going to say that it all looks reasonable to me. The large number of tests is really nice, and actually helped me understand how things are working. [12:40] jelmer: yeah, it helped me to assemble it as well :) [12:40] There were a couple of races in the code (racing against the test suite), but I was able to think them through, and make sure things were changed [12:40] so that there was always communication between the time variables were inspected. [12:41] (make sure to add the item to the list before you talk on the socket, etc.) [12:42] jam: yeah, it seems particularly hard to consider all the corner cases here [13:04] jam: was somebody else still looking at your other in-progress MP? [13:04] okay, had lunch, and am on mumble server [13:04] ...I probably need a better mic though [13:05] can someone spare a moment to come on and tell me how much too quiet I am? [13:08] jelmer: poolie approved it offline [13:08] jam: cool [13:11] * jelmer stumbles onto mumble for a bit too === med_out is now known as medberry [13:18] working mumble in under 5 minutes! [13:18] * jelmer sees progress [13:42] cool, mumble experiment worked [13:43] could somebody suggest 100% working way how to get working bzr fast-export on Fedora? [13:43] I have to do symlinking of fastimport to ~/.local/lib/python27/site-modules and yes I get this backtrace http://fpaste.org/RFaK/ [13:47] mcepl_: do you perhaps also have fastimport in ~/.bazaar/plugins with a different name? [13:47] jelmer: well, I have ... when I don't how is bzr supposed to find it? [13:48] I am sorry, i am not very good with bzr (use fast-export only to get the repository to git so i don't have to bother with bzr anymore ;)) [13:48] mcepl_: bzr will either find it in the standard Python import path at bzrlib.plugins.fastimport [13:49] or you can add the plugin in ~/.bazaar/plugins, e.g. "bzr branch lp:bzr-fastimport ~/.bazaar/plugins/fastimport" [13:49] when I tried to follow http://doc.bazaar.canonical.com/plugins/en/plugin-installation.html [13:49] which doesn't work [13:49] let me give you the error message [13:51] jelmer: http://fpaste.org/PHVY/ [13:51] what am I missing? [13:53] mcepl_: can you pastebin the output of "bzr plugins -v" ? [13:54] no problems there http://fpaste.org/ZmiO/ [13:56] hmm [13:56] mcepl_: did you try to install fastimport any other way perhaps, are there other copies elsewhere on your system? [13:57] it seems that somehow "from fastimport import ..." is loading the bzr plugin rather than the fastimport python module [13:58] I don't think so http://fpaste.org/LiCQ/ [13:58] mcepl: /home/matej/.local/lib/python2.7/site-packages/fastimport [13:58] mcepl_: what's that? [13:58] locate fastimport from whole system [13:59] proof, that there is no other copy of fastimport here [13:59] mcepl_: what kind of link is it? [13:59] oh, that's a dead symlink to [13:59] when i remove that I get [13:59] mitmanek:~ $ bzr selftest fastimport [13:59] bzr: ERROR: No module named fastimport [13:59] You may need to install this Python library separately. [13:59] mitmanek:~ $ [14:00] mcepl_: You need to install the python fastimport module (which is different from the bzr fastimport plugin) [14:00] doh [14:00] where does it grow? [14:01] it's in the cheeseshop, or http://launchpad.net/python-fastimport [14:02] I don't think we have it in Fedora [14:02] (or packaged in Debian/Ubuntu/Arch/Fink/..., but I guess you're on RH ?) [14:02] yeah [14:03] OK, got it [14:04] I accept that this is PEBKAC, but I think there could be something more explicit at somewhere. [14:04] now I have succesful selftest [14:05] mcepl_: yeah, it's a bit unfortunate. the bzr-fastimport commands ("bzr fast-import", etc) give a clearer message but not selftest [14:13] jelmer: any ideas about http://fpaste.org/91vw/ ... (it's bitlbee repo BTW) [14:14] bzr: ERROR: 86daca7b9076381129708faf127820de.iix is not an index of type . [14:16] bazaar 2.4.0, git 1.7.6.2 [14:18] "charis:/tmp/bitlbee.git% bzr fast-export --plain http://code.bitlbee.org/bitlbee | git fast-import" seems to work fine here [14:18] I'll try once more from plain directory [14:20] no error, but [14:20] 16:20:12 WARNING: not creating tag u'1.2.7-1' pointing to non-existent revision wilmer@gaast.net-20100515151824-1bv2apjub0w9c66j [14:21] mcepl_: right, git doesn't support ghosts === Riddell_ is now known as Riddell [15:27] jam: is there extra overhead for a 'def' function in pyrex than a 'cdef' one? I forget. [15:28] mgz: a 'def' function is a regular python func, accessible to other python code [15:28] cdef is a pure C func, not accessible from general python code [15:29] right, and if I want to expose a (currrently) cdef function, should I wrap it in a new def one, or just change it to def? [15:29] I'm looking at dirstate.pack_stat [15:29] mgz: 'it depends' :) If it is critical time, you want a wrapper [15:29] (...which I also have problems benchmarking... the best I've come up with is a big tree and touching every file) [15:30] okay, a wrapper is what I have, will commit [15:30] mgz: you shouldn't have to touch every file, a big tree should be enough [15:30] specifically, pack_stat gets called for each one to compare it to the stored value [15:32] ah right, but I can't then see it in the profile because the pyrex version is called directly from another pyrex function === deryck is now known as deryck[lunch] [16:06] bzr error, , "Cannot create a file when that file already exists" [16:12] hm, can you make your bot use -Derror exarkun? [16:13] 'bzr -Derror checkout ...'? Probably not. [16:16] could set it in bazaar.conf instead? [16:18] if you could find that error in .bzr.log that would do too. [16:19] I can probably find it in .bzr.log [16:20] er, if I can find the directory that file is in. [16:24] ah, there it is. I wonder how to get it off this computer. [16:35] ...I hope you're not typing it across by hand :) [16:41] ... he needs to learn it by heart before he starts typing [16:43] okay, end of day 1 aim, fix two bugs with seven duplicates between them. [16:46] mgz: way to go ! Congrats ! === beuno is now known as beuno-lunch [16:47] first, to write some tests... === deryck[lunch] is now known as deryck [17:09] hi jelmer [17:09] hi Noldorin [17:10] how's it going? [17:10] any much progress? :-) === beuno-lunch is now known as beuno [20:52] Is there a way to force a 'bzr export lp:something' to not use ssh ? [20:58] SpamapS: BZR_HOME=/tmp bzr export ... probably works, for slightly obscure reasons [20:58] SpamapS: why do you want to avoid ssh? [20:58] jelmer: i assume you've seen https://code.launchpad.net/~python-dev/python/trunk and related fun? [21:00] mwhudson: automated test [21:00] mwhudson: in a chroot, so it won't have access to my SSH keys [21:00] ah ok [21:01] actually thats perfect that solves some of my other problems. [21:01] SpamapS: don't set launchpad-login in the chroot? [21:01] I don't [21:01] $HOME is bind mounted.. [21:01] so its picking up anything in there [21:01] oh [21:01] right [21:01] exporting that at key moments to /tmp/sometmpdir will work actually [21:01] then BZR_HOME=/random/stuff [21:02] is probably reasonably appropriate [21:02] (or running as a different user in the chroot, or something) [21:20] mwhudson: yep, working on submitting an updated bzr-svn [21:27] This is relevant to my interests. [21:28] Hehe. I was actually just revisiting bzr today for purposes of comparing bzr-svn and hgsubversion. [21:29] Kilroo: this issue has already been fixed in bzr-svn, it's just because of the snapshot of bzr-svn launchpad is using [21:30] I don't know what issue you mean; I just happened to get home from work and look in here and see you talking about it. I was entertained. [21:30] ah, ok :) [21:31] I think I figured out the shortest sequence of steps to combine bzr-svn and bzr-colo to result in the closest possible analog to what hgsubversion does by default with a TBT svn-layout. [21:33] I'm not sure what hgsubversion does by default - what did you end up with? [21:34] Ah...well, what I actually tested was...I think... bzr colo-init; bzr svn-import .bzr/branches/origin; bzr switch colo:origin/trunk; bzr colo-prune colo:trunk [21:35] I'm actually curious whether bzr init-repo --no-trees; bzr svn-import .bzr/branches/origin; bzr checkout --lightweight colo:origin/trunk would accomplish effectively the same thing. [21:36] you'd definitely need colo-init somewhere in there if you want to use bzr-colo [21:37] ok. That was the part I wasn't sure about, because one of the things I was looking at seemed to imply that switch colo:etcetera would work without it. [21:38] Incidentally, If you have hgsubversion and you hg clone the root of a trunk-based svn repository it just translates it into Mercurial named branches. [21:39] Kilroo: we're making colocated branches a part of core bazaar, so in the future just "bzr clone " would do the same thing [21:39] Yeah, I was reading up on that. [21:40] mwhudson: still there? [21:40] jelmer: hi [21:42] mwhudson: can I trouble you for a quick lp review? It's the update of bzr-svn to fix the tags issue [21:42] jelmer: sure [22:02] I'm using tortise bzr in windows. Can I revert to a previous revision of my code but still keep the changes I'm reverting away from? [22:03] you probably want uncommit then, not revert [22:05] Will this keep my changes in the repository? [22:05] The revision I want is 3 revs back. [22:07] if you want to diff to that revision you can just do that. if you want to create separate working tree on that revision, you can checkout that specific revision [22:07] not sure what you are trying to do [22:08] I guess checking out the specific revsion in another tree will work. [22:09] I am trying to go back to some code I had working, but keep my other changes in case I need them later. A separate tree is probably the best way. [22:09] probably. you can also shelve your changes [22:11] Ah, hadn't seen that command before. Thanks! [23:09] mozmck, ccxCZ, if you want to keep uncommitted changes use shelve [23:09] if you want to leave the committed changes alone but go back to a previous revision, use update [23:21] jelmer: i guess you didn't need me for that review after all? [23:21] mwhudson: sorry, I forgot to mention [23:22] mwhudson: my kernel oopsed and when I rebooted Curtis had already done a review [23:22] jelmer: hahaha [23:22] mwhudson: thanks, though [23:22] don't worry, i haven't been hanging around waiting [23:23] mwhudson: heh [23:23] mwhudson: thanks for *offering* to review that branch :P