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