=== visik7|away is now known as visik7 [00:43] lifeless: how hard would it be to add a rename-thread feature to loom? [00:44] jml: trivial - load the dict, alter it, save it, change the current nick (which points into the dict) IF its the same as teh thread breaing renamed [01:05] jml: got a few minutes? [01:05] lifeless: I will in a bit. [01:10] lifeless: ok. what's up? [01:41] * jelmer once again wishes Python did tail recursion properly [03:25] i need a plugin that has an "oh crap, i've been editing in trunk again" command [03:37] hello all [03:37] hello igc! [03:37] hi mwhudson [03:39] igc: i gave my bzr talk at osdc last week [03:39] how did it go? [03:41] alright, i think [03:41] i went for a fairly gentle introduction to dvcs [03:42] most people had used cvs, almost all svn, a few bzr, about the same git, not so many hg [03:42] a good way to start a talk: "how many of you have used branches with subversion?" [03:42] (almost all the hands go up) [03:43] "how many of you enjoyed it?" [03:43] (most hands go down) [03:44] mwhudson: :-) [03:57] mwhudson: that bit was very good :) [03:58] i do think it's worth making the point that most "next gen" vcs tools are just _better_ than svn [03:58] even if you don't do distributed things [04:00] mwhudson, tho people sometimes just don't care :) [04:00] pygi: well yes, but that's fine [04:00] pygi: but some people also say "this is a one man/in house project, the d in dvcs doesn't get me anything" [04:01] mwhudson, right... [04:03] jelmer: congrats on the 0.5.0rc1 ! [04:03] spiv, thanks :-) It took me long enough... [04:04] jelmer, you really never sleep o.O [04:04] isn't it like 5AM for you? o.O [04:05] yeah, I just wanted to get this release out.. [04:05] I do usually sleep at this time of day :-) [04:05] pygi, you're still in CA ? [04:06] jelmer, when was I in CA? :P [04:06] jelmer, I'm in Croatia :P [04:06] pygi, I figured it would be 5 AM for you as well.. [04:06] jelmer, yes, it is 5AM for me too :p [04:06] so I assumed you were at UDS [04:06] pygi, heh, ok [04:07] congrats on the release ;) [04:07] thanks :-) [04:08] * jelmer sees he has another 5 hours left for sleep, might as well use them [04:08] g'night! [04:08] night night :) [04:08] i don't bother thinking about what time it is for someone before pinging them on irc any more [04:53] jelmer: I thought you were sleeping :P === spm_ is now known as spm [06:42] I'm trying to use bzr for a local file that I want to get weekly snapshots for. [06:42] I think I've stuffed the setup stage as I keep getting asked about branches, when I try to add the file to bzr. [06:44] What I want is essentially simple (I thought). But I'm obviously missing something. [06:45] I've used rcs before, but eventually this file will be mirrored on a file server and so bzr seems like a better choice. [07:14] shelagh: you're describing about the simplest use case going [07:14] $ bzr init . [07:14] $ bzr add filename.txt [07:15] $ bzr commit -m "It is 6 o'clock and all is well" [07:15] followed by a commit next week. [07:15] (on the assumption that you want to make . the Bazaar branch) [07:18] hi all === toytoy_ is now known as toytoy [08:09] AfC: thanks for that. [08:09] AfC: so I need to go into the directory that I put into bzr and add the file? [08:09] I need to practice this at home before I try it at work again. [08:40] regardless of how /win 12 [08:41] oops [09:49] Hmmm, I think turning off plugins may have fixed my Loggerhead memory issues. [09:52] I haven't given it much time to confirm it, but it only grew a few KB in 30 minutes. Before, it would've been...10 or 20 MB, maybe? [10:09] Peng_: wild guess... you had bzr-svn installed? [10:12] spiv: Heh, it's always bzr-svn, isn't it? :P [10:13] Since my last update it's been growing a bit, so that may not have fixed it anyway. [11:20] OK, I can say now that disabling plugins definitely seems to have fixed it. [11:23] Peng_: Interesting! [11:39] Is it possible to exclude a specific plugin from being loaded from code, or should I just uninstall it? [11:51] Peng_: echo 'raise ImportError' > ~/.bazaar/plugins/plugin_name.py [11:52] Peng_: Oh, from code :) [11:52] Peng_: You can probably do something like "import sys; sys.modules['bzrlib.plugins.plugin_name'] = None" [11:52] Which IIRC is how sys.modules caches that an import cannot be found. [11:53] So when bzr imports it, it would load the dummy instead of the real module? Huh, neat. [11:54] (if you go with the dummy module that raises ImportError, don't forget to remove the .pyc as well as the .py when you want to remove the dummy) [11:55] The sys.modules hack seems to work. Neato! [11:59] * spiv -> sleep [12:00] Good night. [13:33] What would be the best way to count the number of commits in a repository? === vednis is now known as mars [13:43] Arjen: just a guess but wouldn't bzr log show you the revno? is that the same thing? [13:50] That's only the mainline [13:51] I want the total number of commits [13:52] im trying to get the all-in-one install of bzr for windows to work [13:52] it works fine on one machine but not another [13:53] it is the 1.9 version that i am working with === asac_ is now known as asac [14:29] asac: bzr info -v [14:29] er [14:29] Arjen: ^ [14:44] argh [14:47] finally got my bzr on windows to work [14:48] had to reinstall then do "set BZR_SSH=paramiko" [14:48] * etank is happy now :) [14:50] pingdotfm: finally got my bzr on windows to work. had to reinstall then do "set BZR_SSH=paramiko" to get it to work. [14:50] oops :) [14:50] wait, how did you get your bzr on windows to work? :-P [14:58] Tak: i used the all-in-one installer [15:03] how can i make bzr always use paramiko instead of plink? [15:03] it keeps going back to plink and i get "ssh implementation is Putty's plink." [15:04] hm, I though it uses paramiko by default [15:04] you can set the BZR_SSH variable globally [15:04] Control Panel -> System -> Environment Variables or something like that [15:06] thanks luks that did the trick [15:16] is there an easy way to 'forget' remembered submit branch locations? [15:16] oldman, see .bzr/branch/branch.conf [15:17] you can also get it to remember a new location by using --remember [15:17] excellent, thanks === ja1 is now known as jam [15:21] Good morning to all [15:21] Anyone have experience debugging DNS issues on Windows 2003? [15:21] It seems that there are DNS servers, and doing "nslookup" works, but doing "socket.gethostbyname()" does not. [15:25] jam: maybe flush your dns cache first === ja1 is now known as jam [15:26] I don't know if anyone responded, I seemed to have a network glitch [15:26] jam: maybe flush your dns cache first [15:26] etank: well, I did do "repair" which is supposed to do that, and I've even rebooted that machine [15:27] ipconfig /flushdns [15:27] (It is a virtual host, which we use for the win32 builds) [15:27] I'll try that, I guess [15:28] I found one google result that looked interesting, but it is a "members only" page: http://www.experts-exchange.com/Networking/Unix_Networking/Q_22643954.html [15:29] jam: i have an account there if you want me to look at it for you [15:30] etank: still failing [15:30] etank: that would be nice, though I don't know if it will actually know the answer [15:30] probably worth trying [15:30] btw, do you remember the location of "hosts" and "lmhosts" ? [15:31] c:\windows\system32\drivers\etc [15:31] I never quite understood that. Maybe because the network stack was BSD based? [15:32] jam: here is the "answer" from the ee page http://dpaste.com/97018/ [15:32] may not be of any use though [15:33] ugh [15:33] yeah, not the problem I'm having [15:34] it seems that lmhosts.sam is empty, hosts is almost empty [15:35] thats normal [15:36] the one interesting entry in 'hosts' does indeed resolve for "gethostbyname()" [15:36] should have a "127.0.0.1 localhost" by default and that is it [15:36] It has 2 lines: [15:36] 127.0.0.1 LOCALHOST [15:36] 10.0.10.14 vzsveaddress [15:36] I assume the latter has to do with how the virtual host was set up [15:37] or you wanted it to resolve even if the dns server was not found [15:38] sure, but regardless those are the only ones that "work" on this machine for "gethostbyname()" while "nslookup" seems to do just fine. [15:40] what module does bzr use to read the config? [15:40] ConfigParser? [15:40] ConfigObj [15:40] bzrlib/util/configobj/configobj.py [15:41] similar, but also supports writing [15:41] and has support for some stuff that we don't really use [15:41] like lists [15:41] cool [15:50] interesting, it seems to be "the default gateway is not on the same subnet + subnet mask as the ip address" [15:51] so my guess it is getting confused by that [15:51] ok, really weird [15:51] that sounds about right [15:51] the IP address is a public address [15:51] but the default gateway is a 192.168 addres [15:51] are you natting or bridging the connection? [15:51] I have no idea [15:51] this is a virtual host provided by someone in Australia [15:51] oh [15:52] as I can connect via terminal services and openssh, my first guess would be bridge [15:52] but I don't know yet [15:52] I think it is at the point that we need to escalate to their support, but I think only poolie can do tha [15:52] that [15:55] yeah, I can submit a support request, but it will go to his email address, which makes it hard for me to respond :) [15:55] lifeless: ping [16:31] jam: pong [16:31] just asking if you could give poolie a poke if you see him [16:31] I need him to open a support case with the host of kerguelen [16:31] k [16:31] thanks [16:31] I think he's still to arrive at the venue [16:38] lifeless: it isn't critically urgent, so you don't have to go search for him, but if you do run into him, just let him know [16:38] thanks [16:58] hi [16:59] is there a way to clean the obsolete_packs dir (pack-0.92 format) [17:00] I used bzr pack to save some space but I ended up doubling the space used: X in packs and X+something in obsolete_packs [17:00] gioele: rm .bzr/repository/obsolete_packs/* [17:00] It will clean itself out eventually [17:01] at the next time it goes to pack/autopack [17:01] jam: is that safe to do? [17:01] don't delete the *directory* but you can delete the files [17:01] I would probably run "sync" first [17:02] why are these "obsolete" packs kept around? [17:02] because we don't know if the OS will order things correctly [17:02] and actually write things to disk before the system crashes [17:02] as it is your precious ancestry we are dealing with [17:02] we default to safe [17:03] jam: is it my $HOME backup, almost as precious as my ancestry ;) [17:03] so if you know you have another backup, you know the system won't crash right away, etc [17:03] sync && rm .bzr/repository/obsolete_packs/* [17:03] should be fine [17:04] just make sure to not delete the directory itself [17:04] ok (I have a backup of the backup anyway) [17:04] done [17:15] everything seems fine [17:15] thanks jam [17:15] happy to help [17:18] jam: I suggest mailing him [17:18] I did [17:18] :) [17:19] jam: I intend to read your updated commit-uses-add-by-delta patch, haven't had time to grab a diff vs my branc to see the changes [17:20] I'm pretty sure I summarized the important changes in the email. [17:20] but that doesn't give you a code-level view [17:20] right [17:20] cocneptually I'm cool with it [17:51] i'm converting a smallish svn repo with a couple of branches to bzr [17:51] i'm planning to use "bzr svn-import" [17:51] i'm planning to put it in a shared bzr repo [17:51] i'm using bzr 1.10 [17:52] what repo format should I use (for "bzr init-repo")? --1.9? [17:52] --1.9-rich-root? [17:53] seb_kuzminsky: 1.9-rich-root [17:53] though I think svn-import makes its own repo [17:53] poolie: jam was pinging for you [17:54] thanks lifeless [17:54] lifeless, yep, it does [17:55] so i dont need to init-repo before svn-import? [18:08] i did a 'bzr svn-import' and it gave me a rich-root-pack repo, not 1.9-rich-root [18:08] i have bzr-svn 0.4.16 [18:08] and bzr 1.10rc1 [18:08] seb_kuzminsky, that's correct [18:08] seb_kuzminsky, rich-root-pack should work fine as well [18:08] seb_kuzminsky, and is supported by more older versions of bzr [18:09] going back to 1.0 it says [18:09] seb_kuzminsky, if you would like to use 1.9-rich-root, you can use "bzr upgrade --1.9-rich-root" in that directory [18:09] ok thanks jelmer [18:20] jelmer: it worked :-) [18:21] jelmer: but is there a way (some --schema perhaps) to turn svn's trunk/branches/tags structure into native bzr representations? [18:23] i'll try --scheme=trunk [18:24] the default is "auto", but even with -v, svn-import didnt tell me what it was doing [18:24] and it seems to have used "none" scheme, instead of "trunk" which is what i think i want [18:32] Thanks to that hack to load most plugins but not bzr-svn, it seems bzr-svn is the source of my Loggerhead memory leak.. [18:32] Peng_, that's interesting [18:32] Peng_: which bzr-svn ? [18:32] beuno, does loggerhead use find_branches() at all? [18:33] I guess we should add a --no-plugins to server branches? [18:33] jelmer, no, it shouldn't [18:33] beuno, what about find_bzrdirs() ? [18:34] jelmer: Latest 0.4 branch. [18:34] jelmer, nope [18:34] beuno, how does it find the branches then in serve-branches ? [18:34] Peng_, want to write a patche for --no-plugins? :) [18:34] jelmer, it tries Branch.open() [18:34] beuno: --no-patches. :P [18:34] Peng_, depending on how loggerhead is trying to open branches, 0.5 fixes that issue [18:34] Peng_, also, without bzr-svn, is the memory usage down? [18:35] beuno: Yes, it is. [18:35] Peng_, w00t! by how much aprox? [18:36] beuno, ah, thanks [18:36] Peng_, so, yes, bzr-svn 0.5 should fix the memory usage issue [18:37] poolie, lifeless, james_w ^^^ LH memory usage down, but still blows up on production [18:38] beuno: Oh, right. I forgot about the improvements. I can't really say at this point; all I can say is that disabling bzr-svn stopped it from constantly growing. [18:38] jelmer: You figure 0.5 is usable enough at this point that I can try it safely? [18:38] Hmm, I'm not even sure I ever use bzr-svn on that machine. [18:39] Peng_: Yes, I think so [18:39] Peng_, There was a similar bug a while ago in "bzr multi-pull" [18:40] i did "bzr svn-import --schema=trunk" and still it gave me a single bzr branch with /trunk, /branches, and /tags [18:41] seb_kuzminsky, you want --scheme=trunk0 [18:41] "bzr branches" returns without producing any output, and "bzr heads" shows just one head [18:41] jelmer: oh ok [18:42] hi jam, beuno, lifeless [18:42] hi poolie, how is mountain view? [18:44] seb_kuzminsky, though I think it should yell at you if you use --schema [18:45] (since that is not a valid argument) [18:46] hrm, sorry, i did type --scheme, my bad [18:46] --scheme=trunk resulted in no branches in the bzr repo [18:46] * Peng_ tests bzr-svn 0.5. [18:46] trying --scheme=trunk0 now [18:46] seb_kuzminsky, in that case trunk0 won't help much I think [18:46] seb_kuzminsky, you might want to try 0.5 as well then [18:49] jelmer: yea after "bzr svn-import --scheme=trunk0" i still have no branches [18:49] that's ok, i didnt really want my branches anyway.... [18:50] seb_kuzminsky, you can get the individual branches manually by running "bzr branch /trunk my-trunk" [18:50] morning [18:50] hey mwhudson [18:50] jelmer: right, good idea [18:52] jelmer: i'm doing this on the machine that hosts the svn repo and i'm using file:// urls to the svn repo, might that have anything to do with the problem? [18:53] seb_kuzminsky, no, that shouldn't matter [18:53] seb_kuzminsky, I think it's just a general problem causing bzr-svn to use the guessed scheme rather than the specified one [18:53] ok [18:54] seb_kuzminsky, I think it's fixed in bzr-svn 0.5.0~rc1 [18:56] seb_kuzminsky, looking at the code, I'm sure it's fixed in 0.5 [18:56] seb_kuzminsky, did you only just start using the trunk/, branches/ structure? [18:57] the svn repo was created with that structure [18:57] it has two branches (plus trunk) and no tags yet [18:57] of the two branches, one is about halfway back in history, and the other is very recent [18:59] history is about 300 revs long [19:00] hmm - is pycurl needed for anything under linux? [19:00] because it is not mentioned anywhere - but in the logs there are lots of complaints about not finding it [19:17] Necoro: the only thing I can think of that it possibly adds over plain urllib is ssl certificate checking [19:28] .join #ubuntu-foundations [19:36] LarstiQ: maybe we should only make it the preferred default for https connections, rather than both http and https [19:36] Necoro: we don't need it, we just use it if we find it, and log when we don't find it [19:37] jam: that sounds like an excellent idea. [19:37] vila: what do you think? [19:38] jam: ah ok - the "DependencyNotFound" just sounded quite drastic and I thought whether it could be a reason for some errors ;) === etank is now known as service_desk === service_desk is now known as etank [19:48] LarstiQ: patch submitted, though I want to hear what vila thinks before we switch [19:48] * LarstiQ nods [19:51] hello jam [19:51] hi poolie [19:51] For some reason the login you gave us before isn't working for me now [19:51] trying to follow your support request linke [19:51] link [19:51] ah :/ [19:52] I was able to use it just this morning [19:52] i reset my password because i didn't have it on my laptop :) [19:52] when I wanted to try myself [19:52] can you encrypt it and send it back to me [19:52] plesae [19:52] sure [19:52] please* [19:52] poolie: sent [19:54] ok, it's reset back to that [19:55] so you're welcome to use that to file or comment on support requests [19:55] just login as mbp@canonical [19:55] If http defaults to urllib and https defaults to curl, and an http url redirects to https, will it still switch to curl? [19:59] yes [20:01] :) [20:06] abentley1: mirror stuff: init-branch .; set-stacked(mirror_url);pull (official-source) === Mario__ is now known as pyg === pyg is now known as pygi [20:25] poolie1: the only support ticket I see is the "System is not available as the server is currently stopped" ticket [20:25] which I don't think is the same [20:26] it is the same, i added on to that ticket [20:26] ah, I see it now [20:26] yeah [20:26] because they broke this while trying to fix the first === poolie1 is now known as poolie [20:43] Is it possible to commit when one of the parent revisions is a ghost? [20:45] In particular, what sort of arguments should CommitBuilder.record_entry_contents() receive in that case, since it requires a list of parent inventories. === Hydrogen_ is now known as Wasserstoff [20:48] jelmer: its a little tricky:) [20:49] jelmer: but yes, and its tested for commit.py, in bzr's test suite; I don't recall the exact mapping to CommitBuilder though [20:50] lifeless, thanks, I'll have a look there [21:18] how to update to a specific revision ? [21:18] bzr help update doesn't tell? [23:03] spiv: are you around? [23:05] i've got a rich-root-pack repo on a server running bzr 1.10rc1 [23:05] when i try to checkout using hardy (bzr 1.3.1), it fails because it makes the local repo (on the client) pack-0.92 [23:06] seb_kuzminsky: I believe it is a known bug in older versions of bzr [23:06] fixed somewhere around 1.6 [23:06] thanks jam, that was quick :-) [23:06] hardy backports has only 1.3.1... [23:07] it's easy enough to work around by creating the repo explicitly before doing the checkout [23:07] jam: yep [23:08] spiv: so I was wanting to implement a FIFO cache, similar to our LRUCache [23:08] and basically, on *access* I don't need to do any work [23:08] just on add() do I need to possibly pop things out of the cache [23:08] and I was hoping to have it have minimal overhead [23:09] but if I try to do "self.__getitem__ = self._adict.__getitem__" [23:09] I get a "readonly" attribute error [23:09] Right, __getitem__ is special, because it's an operator. [23:09] So the next thing I tried was to subclass a dict [23:09] (You could do that in a classic-class, but not a new-style class) [23:09] but: TIMEIT -s "x = {10:20}" "x[10]" [23:10] is about 0.07us [23:10] and using the subclass [23:10] it is 0.2 us [23:10] or not quite 5x slower [23:10] * spiv tries [23:10] even worse is doing def __getitem__(self, k): return self._d[k] [23:10] oh right, dict.__getitem__ is special cased in the interpreter look i think [23:10] which is about 0.6us [23:11] or another 2-3x slower than subclassing dict [23:11] loop [23:11] so if I wrote a C class [23:11] which subclasses __dict__ [23:11] would it be possible to get the same performance, mwhudson? [23:11] jam: no [23:12] it checks the type first? [23:12] yes [23:12] not the attribute [23:12] :( [23:12] think so, anyway [23:12] jam: I only see about a 30% speed hit for a subclass [23:12] jam: well, for a trivial dict subclass with no logic [23:12] actually [23:12] maybe i'm lying [23:12] spiv: well, I only special cased __setitem__ [23:13] I'll try without that [23:13] it's list[int] that's special cased, it seems [23:13] I still see 0.06 versus 0.24 [23:13] I'm on win32 [23:14] which makes a difference [23:14] but still [23:14] jam: on, hmm, now I get numbers more like yours, it seems a package upgrade in the background was skewing my timings === visik7_ is now known as saltapozzanghere [23:15] now the 30s I was seeing is more about LRUCache.get() overhead [23:15] which has to record the access for the LRU part [23:15] I'm sure a FIFO would still do a lot better [23:16] I was just hoping to remove all overhead through some sort of magic [23:16] subclassing dict still gives 2:1 benefit versus using a dict [23:16] jam: there's already a collections.deque, btw [23:17] spiv: true, but I want a dict [23:17] not a list [23:17] so I want to use a dict + deque [23:17] and when the dict gets full [23:17] pop things out of the deque [23:17] and remove them from the dict [23:17] Sounds like a weird FIFO :) [23:17] It would only *have* to override __setitem__ [23:17] spiv: FIFOCache [23:18] sorry I wasn't more explicit [23:18] Oh, right. [23:18] versus the LRUCache [23:18] which we have in bzrlib now [23:18] I also wish I could implement it with a list, because I've also seen deque slower than a list === saltapozzanghere is now known as visik7 [23:18] probably because of stuff like mwhudson's inlining of list[int] [23:18] mwhudson: is tuple[int] also inlined? [23:18] lists are pretty quick. [23:18] that would make sense to me [23:19] Also because lists are very simple. [23:19]