[00:02] which one? [00:02] I don't understand the top branch, it seems hg and bzr do all his bullet points there anyway. [00:02] *top item [00:03] branches on the brain. [00:05] mgz: those pages are not rational [00:06] bzr does not make it as cheap to branch as git, unless you've preconfigured yourself into a repo + treeless branches + checkout structure, or are using the colo plugin [00:06] i think bzr-colo does that, but [00:06] right, it's not the easy default [00:06] and in particular it's not part of the framework where it can be reached by bzr-git etc [00:06] spiv: very nice post [00:07] if even "not creating new working tree" is what he means by fast, it's seldom actually slow. [00:08] so i'd like to see that finished off [00:08] lifeless, about 2.4? [00:09] about 3 [00:09] and 3to2 etc [00:10] poolie: jelmer said to me yesterday(?) that we should talk about bug 485601; there's been some off-list (and off-bug :/) mails about what precisely bzr's model constrains (i.e. is it valid for bzr-svn to change ie.revision in existing inventories when filling ghosts). [00:10] Launchpad bug 485601 in Bazaar "missing chk node(s) for id_to_entry maps" [Medium,Incomplete] https://launchpad.net/bugs/485601 [00:11] poolie: otherwise hacking sounds great :) [00:11] lifeless: thanks! [00:11] i'll add that to the wiki [00:14] how did we even get onto the topic of 2.4? [00:18] poolie: Hey hey. [00:18] poolie: Since I have Approve on the XSS fix, can I also merge https://code.launchpad.net/~mkanat/loggerhead/raw-controller/+merge/42675 ? [00:19] * poolie looks [00:20] yes, i'll reply [00:21] poolie: Great, thanks. :-) [00:21] just for curiousity [00:21] poolie: That means I can get on to other work! [00:21] poolie: That will start tomorrow. [00:21] how does this work in bugzilla [00:21] poolie: Ah, very similarly, but with more complexity. [00:21] what stops me uploading an attachment that does xss? [00:22] poolie: The long answer is: https://bugzilla.mozilla.org/show_bug.cgi?id=38862 [00:22] poolie: We do something very similar--if you access attachment.cgi with a request to serve a file, you get redirected to a separate domain. [00:23] If the admin hasn't specified a separate domain, Bugzilla defaults to downloading the file instead of displaying it (although admins have an option to override that). [00:23] hm [00:23] poolie: We offer the option to put %bugid% into the attachment domain, so that you can have one attachment per bug. [00:23] poolie: There are also various security situations: [00:23] so that second case is similar to what i was asking for with loggerhead downloads? [00:23] poolie: * Bugs that normal users cannot see, but only special users can see [00:23] ie that if you don't have a separate domain, by default it only downloads? [00:24] poolie: * Attachments that normal users cannot see, but only an even MORE special group of users can see. [00:24] however, perhaps it's different because the normal deployment of loggerhead is readonly [00:24] poolie: Yeah, and doesn't involve auth. [00:24] poolie: Bugzilla involves not only auth, but a lot of high-security stuff. [00:24] poolie: For the secure bugs and the secure attachments, we do tokens, much like lifeless described. [00:24] loggerhead does support --allow-writes :-) [00:25] but without any auth indeed, so don't do that [00:25] poolie: We generate a one-use token, redirect to the URL with that token, and then delete it as soon as the page is viewed. [00:25] poolie: Because the attachment domain can't ever get any cookies--otherwise that would partially defeat the XSS protection that we're going for. [00:25] (Although our auth cookies are already httponly.) [00:26] mwhudson: Yeah, that's like "bzr serve --allow-writes". Bad idea. :-) [00:26] mm [00:26] ok [00:26] poolie: We also have extra complexity involved because there are a lot of other automatic redirects that can happen in Bugzilla, mostly around forcing SSL. [00:27] so, i think you should just mention the feature in readme or whatever [00:27] right [00:27] otherwise it's fine, let's land it [00:27] poolie: Okay, thanks. :-) [00:31] All right, I'm out. Later! [00:38] lifeless, oh you meant the prisoner's dilemma mail? [00:38] i agree [08:20] hi all ! [08:21] * fullermd waves vila around a bit. [11:56] which versions of Python does bzr support? [11:59] all the way back to 2.4 currently === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [12:12] bob2: thanks [12:51] hi guys. Any thoughts on what would cause this? NameError: global name 'readline' is not defined [12:52] just started happening after my system crashed [12:52] ouch. Was there filesystem corruption? Sounds like a python module has disappeared from disk [12:52] well I did an fsck and everything was OK [12:53] What is your OS? [12:53] Ubuntu 10.10 running inside of a VM on Windows 7 [12:56] CaMason: Does the file /usr/lib/python2.6/lib-dynload/readline.so exist? [12:57] erm, nevermind, I misread your initial error message [12:57] it does [12:57] Please re-execute the bzr command that gave you trouble with -Derror, and pastebin the output [12:58] http://pastebin.com/2bZSnnxC [12:59] What is your bzr version? (dpkg -l bzr) [12:59] 2.1.1-1 [13:00] It appears to be a bug which is masking the real error [13:01] Please open /usr/lib/python2.6/dist-packages/bzrlib/pack.py in an editor, go to line 206, and change % (readline, )) to % (result, )) [13:02] done [13:02] bzr: ERROR: short readline in the readvfile hunk: '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' [13:04] something to do with my repo? [13:05] interestingly, `bzr log` works fine on another repo (no error). This error is occuring in `bzr log` (and branch) at a particular commit [13:06] I've opened the repo with qlog, and when I scroll down to r104, I then get the error popping up [13:07] I was working on this branch when the crash happened. I do have a copy of it elsewhere. Should I do a pull? [13:09] CaMason: OK, so it looks like the crash has caused one or more files within a bzr repository to be corrupted by filling it with lots of zero bytes [13:10] oh fie [13:11] Is the problem branch using a shared or standalone repository? [13:11] standalone [13:11] (bzr info if you're not sure) [13:12] OK, if you have a copy elsewhere, fetching that would be the simplest option [13:12] yes I do. [13:12] If you have new revisions locally that are not in the remote, it may work to pull the broken branch into a fresh copy of the remote [13:12] no, fortunately I pushed not so long ago [13:14] shall I just put this down to an epic BSOD failure? [13:28] CaMason: Are you running ext4 on this filesystem? [13:29] Even if you are, this really ought not to happen :-/ [13:29] Is the branch data private? [13:29] it is :( [13:30] It would be necessary to study in exactly which files the corruption was present to try to determine what component was at fault === oubiwann is now known as oubiwann_ === oubiwann_ is now known as oubiwann [15:23] is 'bzr branches' ridiculously slow all the time? [15:24] I'm running it against a local repository with maybe 500 branches in it, and it's taken 15 minutes already [15:50] glyph: It's ridiculously slow if you have bzr-{hg,git,svn} installed === zyga is now known as zyga-food === beuno is now known as beuno-lunch [16:04] maxb: huh? They should only add a single extra stat each, unless you actually have hg, git or svn checkouts [16:04] single stat per dir that is === Ursinha is now known as Ursinha-lunch === beuno-lunch is now known as beuno === Ursinha-lunch is now known as Ursinha === zyga-food is now known as zyga [21:03] mkanat: hi [21:03] https://bugs.launchpad.net/loggerhead/+bug/698305 [21:16] ...whatever that ext4 option that makes it sucks less should be up as a bzr faq [21:16] nearly every time someone reports repo corruption on launchpad or the list, they're running on ext4 [21:29] indeed [21:29] perhaps we should flush by default too [21:29] bye all! [22:34] lifeless: Okay. If that's a high-priority item, you can talk to poolie to have it put on my todo list. It looks pretty minor to me, though. [22:35] mkanat: in LP we have a policy that OOPSes are always high/critical (we're polishing the label atm) [22:35] mkanat: poolie is flying atm [22:35] lifeless: Ah. [22:35] lifeless: I wouldn't say that that's practically critical in this case. [22:35] lifeless: I used to have a similar policy for Bugzilla, but we scrapped it as impractical. [22:35] mkanat: we're seeing 6000 error reports a day [22:35] lifeless: From just that? [22:36] mkanat: possibly, due to some config issues our group-and-analyser isn't running on them at the moment [22:36] sorry, 12K a day - two servers. [22:36] lifeless: From loggerhead alone? [22:36] yes [22:36] Jeez. Okay. [22:36] data is useful :) [22:36] So I can see why it would be at least important to reduce the noise. [22:37] its also important in presenting a pleasant UI to users [22:37] And yeah, that should be a 404. [22:37] lifeless: Yes, although if you hack the URL, presenting a pleasant UI to you is not a high-priority item. [22:37] However, reducing the noise does seem important. [22:40] lifeless: Anyhow, my work list is very very limited right now, I can't add anything without poolie's authorization. [22:41] thats fine [22:41] when you see him next, can you ask him aboot it? [22:43] lifeless: Sure. If you don't hear from me on that bug tomorrow, then feel free to remind me, also. [22:43] Hi everyone, I have a bug with our code that uses bzrlib that I am trying to work through, and I could use a hand figuring out what is happening [22:44] shoot [22:45] lifeless, thanks. Our code does a branch checkout, runs the suite, then a branch push [22:45] lifeless, the push happens ~4 hours after the checkout. I get this error (starts around line 25): http://pastebin.ubuntu.com/551269/ [22:46] lifeless, if I remove the test suite run, then the branch push happens perfectly, as expected [22:46] probably tcp timeout [22:46] establish a new branch object rather than using the same one [22:46] possibly idle ssh session timeout on the codehosting service [22:47] yes, we suspected that too [22:47] I was wondering if there was a way to close out the connection, or copy the Branch object, but I can create a new one too (more invasive to the existing code though) [22:48] thanks lifeless [22:48] b = bzrlib.branch.Branch.open(oldbranch.base) [22:48] will open fresh with no reuse of session/transport [22:49] cool, thank you