[00:03] lifeless,jam: Any idea what could cause BTreeIndex.add_node() to become tediously slow after a while ? It's spending all its time in _spill_mem_keys_and_combine() [00:05] what does this error in launchpad mean: Unexpected form data. [00:05] It appears always, when i try to log in using firefox [00:05] C-S: it means launchpad is broken - i see it too [00:06] Kamping_Kaiser: this is a mess, as it does not work since many weeks. [00:06] Kamping_Kaiser: so, I usually login using opera [00:06] C-S: really? just now is the first time i've seen it [00:06] C-S: i wonder ... [00:07] C-S: it means launchpad requires cookies to log in [00:08] Kamping_Kaiser: But I don't have a cookie when I login for the first time. [00:08] C-S: if i tell FF to allow cookies for launchpad.net i get 3, and can log in. [00:09] 2 for lp.net, and 1 for login.lp.net [00:09] Kamping_Kaiser: let me try this... [00:11] Kamping_Kaiser: does not work. I get the cookies but still the same error as before. [00:11] C-S: hm guess you'll have to ask in #launchpad [00:12] Kamping_Kaiser: thanks so far... [00:13] C-S: i only deal with LP when bzr breaks, so i don't know much about it ;) [00:13] Kamping_Kaiser: don't worry, I don't use LP very often anyway. [00:14] Kamping_Kaiser: you can file via email [00:14] jelmer: it means you have a large index, and its spilling to disk to avoid thrashing; then it combines the disk indices when you finalise. [00:14] lifeless: any idea why it slows down the process so much ? [00:15] serialisation, gz compression [00:15] It's at least a factor 1000 slower than initially [00:15] lifeless: i'll go and check the docs, i can never remember the format LP uses [00:19] lifeless: ^ [00:20] jelmer: yes [00:20] jelmer: there may be something odd going on, but writing the index is a big chunk of the effort involved [00:21] lifeless: I hope there is.. [00:21] lifeless: At first I can process ~30 revisions per second, after that it's more like one revision every minute [00:22] lifeless: it's not just one moment where it's flushing stuff to disk, it appears to be doing it continually [00:22] jelmer: lsprof it [00:22] I'd offer to look at it, but am flat out at the moment [00:22] jelmer: it's meant to flush strips of increasing size [00:22] and recombine them with expontential backoff [00:23] lifeless: No worries, thanks for pointing me in the right direction. [00:36] * Kamping_Kaiser emails in his bug reports [01:02] jelmer: sorry about the dupe report on -rewrite [01:05] Kamping_Kaiser: no worries - any chance you can mark them as such? [01:05] jelmer: sure. === marv1 is now known as marv [03:49] Hi, I trying to use bazaar on Windows and I get this error when dowload a branch: Authentication (publickey) failed. [03:49] bzr: ERROR: Connection error: Unable to authenticate to SSH host as [03:50] I run puttygen and pageant, but it dont work [03:50] and the public key for launchpad says that it is invalid [03:50] I generate my key with ssh-2 RSA [03:50] some help? [03:58] please, I'm stuck with this [04:00] I made! The tutorial on lauchpad is very incomplete. You need put images. I only need copy the open-ssh key from text box. [04:14] how I can have symlinks with bazaar on windows? [05:48] where does bzr-svn identify what it thinks is the first revision of a branch? [07:51] Is there a command that can be used to find out what revision a revisionspec would point to? [07:51] (kind of like rev-parse in git) [08:01] wbruce: 'bzr revision-info ' ? [08:11] mwhudson: thanks! [10:34] mwhudson: its the weeken man :P [10:35] lifeless: and so not the time to be digging in to bzr-hg bugs? [11:10] mwhudson: :) [12:16] luke-jr: it's the revision that created the path that is the root of the branch [13:25] Hai I am Keshav from India. i have a few questions about bzr, specifically grub2 related info [13:27] Any way to stop bzr from tracking the x-bit of files in a repo? [14:01] hello. do test names for plugin tests cases 'def test_xxx' have need to differ in the first N characters or something? [14:01] i find that some of my tests are silently skipped i.e. they don't show up in the count. [14:01] changing the name fixes that. but its difficult to know which tests are ignored without knowing the exact behavior. [14:04] jelmer: yes, I noticed that. I'm looking for where that is calculated/detected so I can fix it. [14:05] luke-jr: What needs to be fixed about it? [14:06] jelmer: our project used projectname/{tags,branches,trunk} and projectname has undergone renames multiple times [14:06] bzr-svn persists in treating the last rename as the initial revision [14:06] currently the structure is projectname/{tags,branches,trunk}/subproject/ [14:07] luke-jr: in that case, was it really a rename ? Not just the revision where projectname/trunk/subproject was actually created? [14:07] but if 'subproject' were followed backward, it would eventually inherit from originalprojectname/trunk [14:07] jelmer: yes, it was renamed from 'armagetron' to 'armagetronad' [14:08] luke-jr: so "svn log" on the same URL you check out with bzr-svn reports the full history? [14:08] bzr-svn works if I create armagetronad{/{tags,branches}} and svn cp each tag/branch/trunk individually [14:08] jelmer: yes [14:08] luke-jr: I'm not sure I follow [14:09] actually, no :( [14:09] luke-jr: the project is private? [14:09] jelmer: no [14:09] https://armagetronad.svn.sourceforge.net/svnroot/armagetronad/armagetronad/trunk is the current trunk [14:09] https://armagetronad.svn.sourceforge.net/svnroot/armagetronad/armagetronad/trunk/armagetronad actually [14:11] if I 'svn log' in *that* checkout, it does successfully go back to svn r1 [14:18] and you're checking out https://armagetronad.svn.sourceforge.net/svnroot/armagetronad/armagetronad/trunk/armagetronad ? [14:35] jelmer: that's what the bzr branch would be based on, yes [14:36] and that's what 'svn log' shows the full history of as well [14:36] luke-jr: see r4609 [14:37] luke-jr: in that revision the branch root is created from scratch [14:38] jelmer: but the branch itself is not [14:39] so the question is, where is bzr-svn making this (incorrect) assumption that it is the first revision? where do I need to modify the code? :P [14:40] luke-jr: I'm looking at what bzr-svn is actually doing.. [14:40] jelmer: where is it actually doing that? :) [14:40] luke-jr: if this has to be modified it can't be merged into bzr-svn itself without a mapping change [14:41] I'm expecting a mapping change as a result of the earlier revisions being processed [14:41] shouldn't affect non-affected branches though afaik [14:42] but it would collide with existing imports [14:42] for affected branches, yes [14:43] I'm expecting to need to write an old-branch upgrade script of some sort [14:43] (would be convenient if we can set some revprops on r1 that tell bzr-svn to use the bzr trunk's fileids when possible, tho) [14:43] luke-jr: how do you mean? [14:44] I mean I understand that fileids are based on the initial revision where bzr-svn sees the file, so making older revisions available will by default change those... [14:44] right [14:44] ideally, we might be able to set a bzr:fileids revprop on r1 or such to preserve the bzr trunk's fileids, but that's not neccessary [14:44] bbiab [14:44] but that's part of a larger problem, all file ids and revision ids would/could change with a new mapping format [14:47] * luke-jr can't even try w/o knowing what part of the code handles that stuff [14:51] it's mostly in revmeta.py === froosch_ is now known as froosch [15:16] luke-jr: Hmm, I actually get an error on that URL when running bzr log against it directly [17:16] jelmer: ok? :P [17:54] jelmer: RevisionMetadataBrowser.do never seems to run? :( [17:55] luke-jr: depends on the situation in which you're running it.. [17:55] branch? === khmarbaise_ is now known as khmarbaise === radoe_ is now known as radoe [20:27] moin [22:10] hello all [22:10] Hi. :D [23:27] morning [23:31] hi igc [23:31] how are you?