[00:01] jelmer: Or never mind. [00:02] Peng_: pong [00:02] Peng_: hmm? [00:04] Hmm, several levels of déjà vu. [00:05] jelmer: I've been having problems with bzr-svn 0.6 and Google Code recently: it asks for HTTP auth on the .bzr control files. But "svn+http" works, so never mind. :D [00:14] Peng_: see the recent thread on the mailing list [00:15] jelmer: Ehh. Which one? [00:15] I'm a week behind on mail, so that'd be great if thre was only one new thread on the entire list, but... :P [00:15] jelmer: Oh, the fork thread? [00:17] Peng_: yeah [00:17] Peng_: the short summary is [00:17] Peng_: bzr sends a POST request to see if the remote server provides a bzr smart server [00:17] Peng_: But GOogle code responds to POSTs with a 401 Auth required reply [00:18] and that triggers a username prompt on the bzr side === bob2 is now known as Guest32269 [00:19] jelmer: Ahh, okay. Thanks. === vxnick is now known as vxnick_ === vxnick_ is now known as vxnick === Guest32269 is now known as bob2 === edcrypt is now known as edcrypt_ [02:08] is it just me or is the bundle-buggy web UI down ? [02:19] SamB: it seems to be down [02:27] * SamB wonders if jelmer will vote for his http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/56734 [03:04] What's the mailing list's message size limit? [03:04] I wonder if that's why my message hasn't gone through. I think. [03:48] does anyone what the url is to mirror a branch thats hosted on sourceforge on to launchpad? [03:51] ub3rst4r: https://code.launchpad.net/+code-imports/+new [03:51] ub3rst4r: Oh, never mind. Ignore me. Go with what you're being told in #launchpad. [06:04] BundleBuggy have troubles tonight? [06:05] BasicOSX: Seems that way. [06:05] figures :-) [06:07] http://downforeveryoneorjustme.com/bundlebuggy.aaronbentley.com [06:09] Going to make confirming merge request for 1.14rc2 fun(?) [06:09] Nice. [07:31] Need some assistance in where do I get a bug fix, when status = "Fix Committed" but no branch is associated with the bug. I'm looking to merge bug 355280 but don't know where the fix is located [07:31] Launchpad bug 355280 in bzr "eol content filters are never loaded and thus never applied" [Critical,Fix committed] https://launchpad.net/bugs/355280 === Kamping_Kaiser is now known as Bambi_BOFH [16:48] hello [16:48] i am trying to unshelve something and get "bzr: ERROR: The file id "magnifyingglass.png-20090417233633-s6z8t2odk0omj4yo-1" is not present in the tree any idea what that's about? i really need my shelved changes back :/ === serg_ is now known as serg [16:56] anyone? [16:56] does bzr just lose data like that? [17:11] can anyone help me recover my lost data? === _SamB_ is now known as SamB [17:56] Stavros: well, I'd save a copy of the directory before proceeding [17:58] SamB: which directory do you mean? [18:07] Stavros: well, any relevant directories that have .bzr subdirectories [18:07] i have nothing to proceed to, so not much danger there [18:07] it just ate my work === abentley1 is now known as abentley [18:45] does anyone know how bzr works and what i can do about it? [18:48] Stavros, what do you mean? :) [18:48] Stavros: that's odd, did you shelve the addition of a directory? [18:48] or any additions for that matter? [18:50] james_w: i think it shelved a file, yes [18:50] ok [18:50] are there confidential things in this project? [18:51] sadly, yes [18:51] i don't need the file [18:51] i need the other changes [18:51] can i override a line of code? [18:51] if you look at .bzr/checkout/shelf/shelf-n [18:51] for the largest n in that dir [18:51] then you will see your changes [18:52] it would have been good if you could attach that to a bug report, but I guess you can't? [18:52] anyway, a bit of surgery should allow you to recover from that file [18:52] i just made some changes (one of which was an added file), shelved them all, and committed a few revisions [18:53] ah hmm, my changes are indeed there [18:54] can i comment out the code that checks for files? [18:54] if it's hard to recover from that, then an alternative would be trying to come up with a way to reproduce in a new branch [18:54] so bzr applies them? [18:54] then we can try and fix the bug [18:54] how do you mean? [18:54] I doubt it's a simple as that [18:54] hmm [18:54] cd /tmp; bzr init test [18:54] then try and do something similar with dummy files, and see if you can trigger the error [18:55] hmm, let me check [18:57] damn, i can't reproduce it [18:58] nope, nothing [18:59] is there a way for me to edit the pack file? [18:59] oh damn, i actually do need the file in there [19:00] oh, there it is [19:00] i did a revert and now it breaks [19:01] the revert breaks? or the revert causes unshelve to break? [19:02] the latter [19:02] so you have a minimal testcase? [19:02] yes [19:02] cool, please open a bug and include it, and I'll take a look [19:08] https://bugs.launchpad.net/bzr/+bug/363444 [19:08] Ubuntu bug 363444 in bzr "unshelve crashes if there is a revert and file shelve." [Undecided,New] [19:08] this should work [19:09] can you take a look and tell me what's going on? i really need those changes :/ [19:10] does it reproduce it for you? [19:13] Stavros: I was more looking for instructions [19:13] I'd like to know the steps that lead up to it, as well as see the final situation [19:14] oh [19:14] let me try again [19:18] try now [19:18] basically, shelve a file add and revert [19:19] unshelve will fail [19:19] "bzr version"? [19:20] 1.14rc1, but even trunk fails [19:21] nice, thanks [19:21] np [19:21] can you see what's wrong with it? [19:21] does it have to be two files shelved? [19:21] james_w: i am not sure, i only tried with two actually [19:22] it seems to work with one file [19:23] yes, it only happens with two [19:23] three? [19:23] shelvaw [19:23] aw [19:24] with three files, revert doesn't work [19:24] it crashes [19:24] not for me [19:24] actually [19:25] bzr init, shelve a file add, revert, crash [19:25] that sounds like a separate bug, would you report that one too? [19:26] sure [19:26] thanks [19:26] any luck on the first bug? :/ [19:26] ok, so it requires two or more file adds shelved, and any sort of revert after crashes it [19:27] ah [19:27] no, just the unshelve after the revert [19:27] doesn't even need a revert [19:27] hmm [19:27] it needed for me [19:28] #!/bin/bash [19:28] set -e [19:28] rm -rf test [19:28] bzr init test [19:29] (cd test && bzr ci -m "Commit." --unchanged && touch test2 test3 && bzr add && bzr shelve --all && bzr unshelve) [19:29] that's my minimal testcase [19:29] not doing the first commit seems to trigger another bug [19:29] ah [19:30] can you see why? [19:30] not yet [19:30] patience please [19:30] okay [19:32] http://paste.ubuntu.com/153608/ [19:32] hmm, what is that? [19:33] that's the difference between a one added file shelve and a two added file shelve [19:33] so it's clearly to do with that line [19:33] unfortunately I have no idea what that line means :-) [19:33] haha [19:34] so basically shelving two files crashes it? [19:34] looks like it [19:34] do you think the shelf is corrupt? [19:34] _id_numberi3e18 [19:35] v.s. _id_numberi2e18 [19:35] then the extra new-239:test3-20090418182952-p5wbhmyzknaaa14q-2e9 [19:36] it seems to be the same error as this https://bugs.launchpad.net/bzr/+bug/253806 [19:36] Ubuntu bug 253806 in bzr "bzr: ERROR: The file id "foo-20080731224042-7ogu3b3hk0bwnpo3-1" is not present in the tree" [Medium,Fix released] [19:36] then something like new-15:test2 [19:36] nah, not really [19:37] the same error message, i mean [19:37] what we're seeing is just a generic "foo is not in bar" error [19:37] ah, yeah, the cause is completely different I bet [19:37] ah [19:38] are you james westby? [19:38] yeah [19:38] so you know about that bug [19:38] yup :-) [19:38] hmm [19:38] i have no idea what could be going on [19:38] i'm not really familiar with the internals... [19:38] so we just seem to have some things repeated in the file, which would be expected [19:39] what you pasted looks normal to me [19:39] if it's saving the file IDs... [19:39] you can look at bzrlib/transform.py if you like [19:39] serialize and deserialize in there will help explain the format of that file [19:40] ah [19:40] ok, so it's bencoded [19:41] the error happens after the second deserialization [19:43] ok, adding debugging prints to serialize and deserialize helps us to see what is going on in there [19:43] http://paste.ubuntu.com/153611/ [19:45] they look identical [19:45] oh, and running bzr with "-Derror" will get you a full traceback so you can see where it is failing [19:46] yeah, I wouldn't expect that the serialization itself was the problem [19:46] it's writing out bad data [19:46] so it tries to merge and doesn't find a file id to merge with? [19:48] an unshelve operation is a merge [19:48] does it store a pack and then merge it? [19:49] it stores a serialized TreeTransform, which is something internally used in merge [19:49] and then tries to apply it by doing a merge [19:49] right right [19:49] it applies the transform on the old tree (hence saving the revision id) to get a new tree, and then merges that new tree with your working tree [19:50] ah [19:50] which stage do you think is failing? [19:50] but it shouldn't be asking the working tree for the kind of these files, as they aren't in the working tree [19:50] true [19:50] well it's crashing in the last stage, but I don't know what's at fault [19:50] hmm [19:53] there aren't many things that would cause it to crash with two files and not with two, i assume... [19:53] err, one [19:53] no [19:55] oops [19:55] test [19:55] hmm [19:55] i should redo my changes, i guess... [19:57] is there an easy way of getting bzr in to a postmortem debug? [19:58] zanaga: depending on what you mean with that, if you `BZR_PDB=1 bzr ` it will drop into pdb on error [19:58] that's exactly what i want =) [19:58] thanks [19:59] ^\ is also useful to break into pdb [20:02] damn, so much work lost... [20:03] Stavros: you should be able to salvage them from the shelf [20:03] LarstiQ: there's a png in there i don't know how to get :/ [20:07] Stavros: in a test with adding a png and then shelving, editing the shelf-1 file gives me back my png [20:07] LarstiQ: how did you edit it? [20:08] i managed to get the other changes [20:08] Stavros: just a sec [20:10] Stavros: it looks roughly like http://rafb.net/p/HaZbYo46.html [20:10] yes [20:10] but won't editing it discard the binary data? [20:10] Stavros: I deleted everything up to and including the 'i 10\n' line [20:10] actually let me open it with a hex editor [20:11] Stavros: then I deleted everything from and including the 'E' at the end [20:11] Stavros: I edited it with vim [20:11] oh good [20:11] let me do that then [20:11] Stavros: and then used hexedit to remove the final newline [20:11] after that, cmp between shelf-1 and the original png I copied reported no differences [20:12] interesting, that looks lke it worked [20:12] i'll reexport in photoshop to make sure [20:12] thank you for your help [20:13] Stavros: np, I hope you got all your data out correctly. [20:13] Stavros: and thanks for reporting the bug, shelve needs some bugsquashing [20:13] looks like it :/ [20:13] most of the data was text so i got it out, looks like this png was the last [20:14] it seems to work fine now, thank you very much! [20:15] should i delete the shelf file? [20:16] Stavros: I'm not entirely sure how that works [20:16] Stavros: but shelve --destroy should work [20:16] ah, thanks [20:16] that tried to shelve changes again [20:16] actually that selectively reverts changs [20:18] Stavros: hokay [20:18] evening lamont [20:22] boo on thunderstorms [20:27] wow [20:27] it does seem to be lost in the serialization [20:27] two files are recorded, but only one comes back out it seems [20:28] that's interesting [20:29] and when you do it with three, still only the first one comes back out [20:29] hmm [20:33] but I must go eat [20:33] Stavros: I assume this isn't urgent anymore, you have recovered the things you needed to? [20:33] james_w: indeed i have, thank you [20:33] excellent === BasicPRO is now known as BasicOSX [21:29] lifeless: ping === weltende is now known as welterde [23:03] ah, it's multiple empty files that mess it up [23:03] when you serialize an empty file addition you get no body, so the reader gets thrown off [23:10] pasky: ? [23:11] bah sorry pasky , tab completion fail [23:11] Peng_: ? [23:19] lifeless: Oh hi. Um. Do you have access to the queue of messages being held for approval by the mailing list software? I think one I sent might be being held. [23:20] for the main list? yes, though right now I can't surf [23:20] small matter of only irc working because its not actually on my machine :) [23:21] everything else is thrashing insanely [23:21] Oh. [23:21] Why? [23:22] writing a full scale test index [23:22] Oh. [23:22] to get a perf trace on index writing [23:22] and its uhm, well [23:22] I wanted to check the mailing list archive again before asking you about this, but Firefox crashed as I was writing. :D [23:22] I have 2G of memory [23:22] its vss is3G [23:22] Ouch. [23:23] Boy, I remember the days when I thought getting 1 GB of RAM felt a little excessive. [23:23] 'room for optimisation' [23:53] Peng_: the index have > 8000000 keys