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