[00:09] <spiv> mwhudson: regarding python backtraces from gdb, have you seen https://fedoraproject.org/wiki/Features/EasierPythonDebugging ?
[00:09] <RenatoSilva> ok never mind I'm writing a script and I'm cd'ing to the dir anyway
[00:09] <RenatoSilva> thanks all
[00:10] <mwhudson> spiv: no i haven't
[00:11] <mwhudson> spiv: rather a long way away from being supported in the gdb in hardy, i'd expect...
[00:12] <spiv> mwhudson: probably
[00:14] <poolie> spiv, did you see https://code.launchpad.net/~gz/bzr/test_ssh_client_medium_eintr__read_bytes/+merge/19439
[00:22] <spiv> poolie: not yet, will look tomorrow
[00:22] <poolie> cool
[00:22] <poolie> how is V?
[00:23] <spiv> Sleeping at the moment, thankfully.  He was up late last night!
[00:30] <poolie> he looks just like you :-P
[00:47] <Noldorin> can i force a push to a bzr branch on launchpad that has diverged from the local one?
[00:48] <lifeless> yes
[00:48] <bob2> bzr help push -> overwrite, beware the consequences
[00:49] <Noldorin> bob2, yup. i just managed to clobber the launchpad branch, so no worries. thanks
[00:54] <AfC> Noldorin: I think bob2 more means "consequences" more means "if anyone has grabbed the [revisions on the] previous version of the branch, then you'll never be able to get rid of them (should that person subsequently submit a patch to you and/or merge from your new history)"
[00:55] <Noldorin> AfC, oh, fair enough. fortunately i'm the only dev on the project at the moment, and no-one else is submitting patches
[00:55] <Noldorin> but i see the point
[00:55] <fullermd> In those situations I like to use profanity.
[00:55] <Noldorin> fullermd, hehe
[00:57]  * fullermd watches openoffice build all his disk space away.
[00:59] <AfC> I gotta say, I don't miss rebuilding all of oo for a single line patch
[00:59] <poolie> lifeless: does https://bugs.launchpad.net/bugs/522637 ring any bells?
[01:00] <fullermd> Pfft, the warning says it eats 11 gig of space for the build.  But it's barely 10.5; getting me all worried about nothing...
[01:01] <fullermd> And to think, earlier I actually had a momentary thought of "Gee, 6.5 megs...  that seems a big tarball for a VCS"
[01:01] <spiv> poolie: oh hey, that's some of that paranoia I added just before 2.0, I think?  Nice (relatively speaking) to see it catch something :)
[01:02] <lifeless> poolie: yes, isn't there anothe rbug open like that? be great to help the user, figure it out and fix it.
[01:50]  * igc lunch
[04:09] <parthm> Hello, I am trying to understand bzr test infrastructure better in the context of http://old.nabble.com/Re%3A-help-needed-in-fixing-test-failure-%28-138600%29-p27617476.html
[04:09] <parthm> after doing self.make_branch('foobar') I drop into pdb
[04:09] <parthm> doing a system('ls
[04:10] <parthm> doesnt show any directories. I am in test_home_dir. Should I be seeing a foobar dir? how does that work?
[04:13] <mwhudson> parthm: which testcase class did you inherit from?
[04:14] <parthm> TestCaseInTempDir
[04:14] <parthm> I am trying to add the test case to blackbox/test_versioning.py: TestVersioning
[04:15] <mwhudson> parthm: make_branch in that class only writes to a memory-backed transport, not the filesystem
[04:17] <parthm> Ah. OK. Basically what I need to do is create a directory thats not a part of any repo/branch. I need to run 'bzr mkdir abc' there and ensure that dir abc is not created.
[04:17] <parthm> What would be a good way to do that considering that test_home_dir is already a branch
[04:19] <mwhudson> not sure tbh
[04:19] <mwhudson> poolie: can you help parthm >
[04:19] <mwhudson> ?
[04:19] <poolie> hi there
[04:19] <poolie> yes probably
[04:20] <poolie> on the phone, will just be a minute
[04:20] <mwhudson> parthm: if you inherit from TestCaseWithTransport, then self.make_branch _will_ create a directory, which might make things easier to understand
[04:20] <parthm> hi poolie
[04:20] <mwhudson> might not be the right thing to do though
[04:27] <parthm> That seems fine (with my limited understanding). I am looking at blackbox.test_status.BranchStatus.test_tree_status_ignores. Maybe I can do a make_repository('foo', shared=True).
[04:27] <poolie> (back)
[04:27] <poolie> so istm that you have to use a real directory
[04:27] <parthm> If this creates a dir. the mkdir should fail in this case also.
[04:27] <poolie> at the moment wt must go to disk
[04:28] <parthm> Yes.
[04:29] <parthm> The 'init-repo' failcase http://pastebin.com/m6e5397c9
[04:31]  * poolie looks
[04:31] <poolie> ok
[04:31] <poolie> and you're having trouble reproducing that inside a test?
[04:32] <poolie> rebooting, biab
[04:33] <parthm> Yes. The same failure can also be seen on the command line with a simple directory thats not a branch. I am trying to create the test case for https://bugs.launchpad.net/bzr/+bug/138600
[04:33] <poolie> yep
[04:33] <poolie> i saw your mail earlier
[04:33] <poolie> so what happens?
[04:33] <poolie> it still sees the directory even with your fix in place?
[04:34] <parthm> Really? Are you trying this branch https://code.launchpad.net/~parthm/bzr/138600 are are you referring to the pastebin
[04:35] <parthm> The pastebin is bzr 2.0.4
[04:35] <poolie> no, i'm asking where you're getting stuck now
[04:36] <parthm> When I run bzr from the command line the fix seems to work. I am trying to add the test case right now.
[04:36] <poolie> ok
[04:36] <poolie> so i think the approach you described should work
[04:37] <poolie> make a bzr repository, then try bzr mkdir inside that
[04:47] <parthm> OK. The TestCaseWithTransport approach worked. Thanks mwhudson, poolie.
[04:49] <parthm> One more question. Unlike other commands, mkdir doesn't seem to be having blackbox.test_mkdir. All tests are in blackbox.test_versioning.TestVersioning, so should I just add blackbox.test_versioning.TestMkdir or should it be blackbox.test_mkdir.TestMkdir?
[04:49] <parthm> Hi poolie. I was just mentioning that the TestCaseWithTransport approach worked.
[04:49] <poolie> oh ok
[04:49] <poolie> so you're all good now?
[04:50] <parthm> Yes. Just one more question. Unlike other commands, mkdir doesn't seem to be having blackbox.test_mkdir. All tests are in blackbox.test_versioning.TestVersioning, so should I just add blackbox.test_versioning.TestMkdir or should it be blackbox.test_mkdir.TestMkdir?
[04:50] <poolie> probably add a new module for consistency
[04:50] <poolie> but either is fine
[04:50] <parthm> OK.
[04:51] <parthm> I will add the tests and send a merge request for bug 138600.
[04:51] <parthm> Does the NEWS update need to be a part of the merge request or is that a part of the landing process?
[04:54] <poolie> it's a bit better to put it in your proposal so that we can review that too
[04:55] <poolie> also it acts as a good summary of what you think you've changed
[04:55] <parthm> OK. Will do. Thanks.
[04:56] <poolie> wow the review queue is so long
[05:02] <spiv> Yeah wow, lots of reviews.  I guess I know what I'm doing tomorrow then :)
[05:03]  * spiv wanders off again
[05:06] <parthm> Is there a good way to check (and exit) if the current dir is a workingtree? currently I am doing "wt, dd = WorkingTree.open_containing(d)"
[05:08] <poolie> that's probably good
[05:08] <poolie> if you want to know about the specific directory, not just a containing directory, just use WT.open()
[05:08] <poolie> bzrdir may have a method to tell you?
[05:10] <parthm> The problem I am seeing with the current fix is that if we have abc/xyz where abc is versioned and xyz is unknown, if user does 'bzr mkdir ./xyz/foo', 'foo' is created before bzr exists. So I suppose I need to know if the first part of the path is versioned.
[05:12] <poolie> oh i see
[05:12] <poolie> right, that seems like a separate bug
[05:13] <poolie> can you see how to reproduce this?
[05:14] <parthm> Yes. I added a test case where I do os.mkdir('./abc') and chdir('./abc'). run_bzr('mkdir xyz') would create xyz.
[05:15] <poolie> k
[05:15] <poolie> biab
[05:25] <igc> bbiab
[05:25] <poolie> cheerio
[05:49] <parthm> for some reason "print" in builtins.cmd_xxx cause a UnicodeEncodeError while running selftest. If I run bzr from the command like this works ok. I tried this with cmd_status and cmd_mkdir while debugging mkdir. Is this expected?
[05:49] <bob2> printing unicode strings works differently when stdout is not a terminal
[05:49] <bob2> maybe that's what you're encountering
[05:50] <poolie> parthm: yes, the difference is that it's probably going into a stringio
[05:50] <poolie> are you printing something nonascii?
[05:51] <parthm> No. Even "print 'hello'" fails.
[05:51] <poolie> !!
[05:52] <parthm> http://pastebin.com/m51e779bc
[05:52] <parthm> Whats the suggested way to put a debug print?
[05:58] <parthm> Never mind. I will explore some more. Seems to be some issue in my setup. Even modifying an existing outf.write seems to be failing
[05:59] <poolie> hi
[05:59] <poolie> that's strange
[05:59] <poolie> parthm: if you want to get arountd it
[05:59] <poolie> at least for now
[05:59] <poolie> change the note() code to do
[06:00] <poolie> msg.encode(self.stdout.encoding, errors=replace)
[06:00] <poolie> but this is a bit strange
[06:00] <parthm> So I need to put the msg.encode(..) in my run?
[06:14] <poolie> in trace.note
[06:14] <poolie> i'm just testing your permissions patch
[06:14] <poolie> thanks for doing that
[06:15] <poolie> much karma for fixing elmo's bugs :)
[06:21] <poolie> parthm: stuck?
[06:27] <parthm> Thanks :).  I am trying to figure out what might be a good fix for http://pastebin.com/m56f77879 case.  Switching mkdir with open_containing (http://pastebin.com/m2648b1fb) works for the repo case or when user just does a 'mkdir xxx' but this case still fails.
[06:29] <poolie> parthm: i think run_bzr has a parameter to set the cwd so you don't need to manage it yourself
[06:30] <poolie> or use a scriptrunner
[06:30] <parthm> Yes. Will do that.
[06:31] <poolie> this is the thing about making sure it fails if the parent is not versioned?
[06:31] <poolie> can you add it to the inventory before it exists?
[06:31] <poolie> it seems like that would be cleanest
[06:33] <parthm> I don't think I understand. So if user does a mkdir xxx/yyy and xxx is not versioned (unknown) whats a good way to check and fail?
[06:34] <poolie> parthm: what i'm suggesting is that we try to add yyy to the inventory
[06:34] <poolie> ie to the metadata
[06:34] <poolie> before making the directory
[06:34] <poolie> that will fail if xxx is not already in there
[06:34] <poolie> then if that succeeds, mkdir
[06:35] <poolie> the only catch will be if the add-to-inventory code checks it exists on disk
[06:35] <poolie> which would be a bug imo, but maybe a slightly harder one
[06:35] <parthm> Ah. I get it. What API should I look at?
[06:37] <poolie> basically i'm just suggesting moving the mkdir after wt.add
[06:37] <poolie> it may fail horribly
[06:37] <poolie> but it's worth a go
[06:45] <parthm> So this is what my current cmd_mkdir looks like http://pastebin.com/m57cffad5 . unfortunately I hit this painful unicode error http://pastebin.com/m3b815639 . I am using vim which I think handles unicode fine. Wow.
[06:47] <poolie> ouch
[06:47] <poolie> did you try changing note() to print the message with errors='replace' rather than spazzing out?
[06:49] <poolie> i think you need to get unblocked from that to make other changes easer
[06:49] <poolie> i don't know why it's failing there
[06:49] <parthm> Yes. I just did the note change. That worked, thanks.
[06:49] <poolie> it is annoying certainly
[06:50] <parthm> http://pastebin.com/m57cffad5 doesn't seem to work. I may be doing something wrong.
[07:17] <poolie> what happens?
[07:17] <poolie> it's unfortunate you have to add the root
[07:18] <poolie> though that is a bit of a separate issue
[07:21] <parthm> Looks like the msg.encode change didn't work. msg is undefined. http://pastebin.com/m579486a7 Sorry I seem to have more questions than answers :( So is note called by self.outf.write?
[07:24] <parthm> Can wt.has_filename be used for a conditional check on os.path.abspath(base)? We need to use abspath as the user may either do 'bzr mkdir foo/abc' or 'cd foo; bzr mkdir abc
[07:24] <parthm> where foo is unversioned
[07:24] <poolie> no, note should not be called by self.outf.write
[07:25] <poolie> parthm: when you open the wt with open_containing, it gives you back the relative path
[07:25] <poolie> you can then chop off all but the last component of that and check that it's versioned
[07:25] <parthm> Oh OK. That makes sense.
[07:26] <parthm> What do you suggest I do about the prints for now?
[07:32] <poolie> which prints are these?
[07:32] <poolie> just ones you're adding for debugging?
[07:34] <parthm> Yes.
[07:35] <parthm> This is the final version of cmd_mkdir.run http://pastebin.com/m3893f263 All tests are passing, yay!
[07:36] <parthm> These are the three test cases
[07:36] <parthm> http://pastebin.com/m2e37b536
[07:53] <poolie> i think you need better docstrings
[07:54] <poolie> rather than 'invalid' say 'unversioned'
[07:54] <parthm> I agree. Will do that.
[07:54] <parthm> OK.
[07:54] <poolie> and rather than joining the strings, use ['mkdir', newdir]
[07:54] <poolie> thanks for all the patches
[07:54] <parthm> Welcome :)
[07:55] <parthm> I am trying the winepython usage you suggested.
[07:55] <parthm> After installing testtools and paramiko I get "bzr: ERROR: No module named Crypto.Util.randpool"
[07:55] <parthm> Any ideas?
[07:56] <parthm> paramiko installed without any errors.
[08:10] <poolie> blah
[08:10] <poolie> it's some kind of known bug about paramiko
[08:11] <poolie> just run particular tests and avoid paramiko
[08:11] <poolie> it's not very relevant to your bugs
[08:13] <poolie> well, it's time for me to go
[08:13] <poolie> push your branch and we'll rereview it
[08:14] <parthm> OK. Bye.
[08:20] <lvh> where can I see the branch format of a branch on launchpad?
[08:20] <lvh> I just branched something using 2.0.4 and it was hella slow, AFAIK the main cause for that is typically branch format mismatch
[08:20] <lvh> Ack. Why do I always spend 20 minutes looking for something, ask for help, and then find it immediately after? :|
[08:37] <lvh> Sorry, I'm having to deal with a really bad wifi connection
[08:38] <lvh> I've got a format 7 branch off of a format 7 trunk
[08:38] <lvh> the format 7 trunk is synced from svn, it's not actually pushed to
[08:38] <lvh> what are my options for upgrading the local format ?
[09:23] <jderose> lvh: `bzr upgrade` should upgrade to local repo to the 2.0 format
[10:19] <GaryvdM> Hi igc
[10:20] <GaryvdM> igc: I'm trying to find the page that you had the OOo branch on.
[10:20] <igc> hi garyvdm
[10:21] <igc> garyvdm: if you want some large test repos, try http://people.canonical.com/~ianc/benchmarks/repos/bzr/
[10:23] <GaryvdM> Thanks
[10:23] <GaryvdM> Hmm 1.3 gB. That will cost me about R 260 to download :-(
[10:25] <GaryvdM> ok - bye
[10:40] <AntoineLaf> I have a very beginner level question and hopefully someone would be kind enough to point to where I could find some answers: here it goes. I'm trying to make sense of the "markers (not sure if it's the properword)" inserted in a conflicting merged file. I would like to know where I could find an explanation for <<<< TREE and >>>>>> MERGE SOURCE. Thank you.
[10:40] <Kinnison> IIRC what you get is:
[10:40] <Kinnison> <<<< TREE
[10:41] <Kinnison> what you had in your tree
[10:41] <Kinnison> so this is your change
[10:41] <Kinnison> [10:41] <Kinnison> what the merge source had which conflicted
[10:41] <Kinnison> this is what you're trying to merge in from the remote branch
[10:41] <Kinnison> >>>>>> MERGE SOURCE
[10:41] <Kinnison> type thing
[10:41] <Kinnison> does that help?
[10:42] <AntoineLaf> so what is before the [10:43] <AntoineLaf> and under the [10:43] <AntoineLaf> I think it helps, let me have a better look at it again
[10:43]  * Kinnison nods
[10:45] <AntoineLaf> <<<<<<< TREE
[10:45] <AntoineLaf> something
[10:45] <AntoineLaf> [10:45] <AntoineLaf> >>>>>>> MERGE-SOURCE
[10:45] <AntoineLaf> something like that means that the merge tries to remove something?
[10:48] <Kinnison> It means that where the local branch changed <foo> to "something", the merge branch removed it
[10:48] <Kinnison> yes
[10:48] <AntoineLaf> this is starting to make sense...
[10:49] <AntoineLaf> I guess I'll get more scout badges this month...
[10:49] <AntoineLaf> :) thx
[10:49] <Kinnison> :-)
[10:49] <Kinnison> Scouts have a DVCS badge?
[10:50] <AntoineLaf> yes, with 20 levels with different colors...
[10:50] <AntoineLaf> sorry, this is my fantasy world...
[10:51] <AntoineLaf> have to say that bazaar is the first versioning system that I finally had the guts to stick with and learn... I'm from a designer's background... not all that familiar with the thinking behind the tool. anyways.
[11:14] <bialix> what is the new feature in bzr? cmd_foo.run_direct?
[11:39] <igc> night all
[12:17] <radoe> Hm, will there be full releasenotes for 2.1 put online? By now it seems one has to check all 2.1.0bX and 2.1.0.rY together with 2.1.0 to get all incremental changes.
[12:25] <adiroiban> hi. I'm using bzr break-lock , but it tell me that the lock is in used and I can not break it
[12:25] <adiroiban> is there a bzr command to show who is using t he lock?
[12:35] <bialix> adiroiban: break-lock actually show you info about lock holder, do you have different experience?
[12:36] <bialix> this command is interactive: it show you info about lock and then asking for y/n answer
[12:36] <adiroiban> http://paste.ubuntu.com/378311/
[12:36] <adiroiban> this is all I see
[12:36] <adiroiban> no prompt for breaking the lock
[12:37] <adiroiban> or hint about how can I solve this issue :)
[12:40] <bialix> adiroiban: please run again as `bzr -Derror break-lock` and pastebin
[12:41] <bialix> I suspect some application holds OS lock on dirstate file
[12:41] <adiroiban> http://paste.ubuntu.com/378312/
[12:42] <adiroiban> ..maybe, I'm not greping lsof
[12:43] <bialix> most likely some application still has OS lock over file .bzr/checkout/dirstate
[12:43] <bialix> usually you will see different message
[12:44] <bialix> or there is bug
[12:47] <adiroiban> yep. lsof, shows that gedit is using it (I'm using the gedit bzr integration)
[12:47] <adiroiban> I still think it is a bug as bzr should inform me that gedit is messing the repository
[12:50] <bialix> adiroiban: I don't know is there any API for this
[12:50] <bialix> but I think you need to file a bug report
[15:18] <Tak> hmm, should bzr-svn be able to auto-authenticate me over svn+https?
[15:20] <jelmer> Tak: what do you mean by auto-authenticate?
[15:21] <Tak> I mean, use my credentials from authentication.conf
[15:21] <jelmer> Tak: it should be able to use a username/password if one is set in ~/.subversion or ~/.bazaar/authentication.conf
[15:21] <jelmer> but you need a recent version for ~/.bazaar/authentication.conf to work
[15:21] <Tak> ok
[15:21] <Tak> I have bzr 2.0.4 and bzr-svn 1.0.2
[15:22] <jelmer> that should be recent enough
[15:22] <Tak> oh, what should the scheme be?
[15:22] <jelmer> oh actually, authentication.conf perhaps doesn't work for svn+https, only https
[15:22] <Tak> I have svn+https
[15:24] <jelmer> for any particular reason? just https should work..
[15:24] <Tak> it wasn't working for me at some point, with this server
[15:24] <Tak> but that was several versions ago; let me try again
[15:28] <Tak> ok - it looks like it tried to authenticate me that time - are there character restrictions on the passwords in authentication.conf?
[15:32] <jelmer> Tak: it should be a utf8 string
[15:32] <Tak> ok, but it can contain *&^#$^$# ?
[15:34] <Peng> The config parser _might_ get a bit confused. E.g., # denotes comments. Try putting it in quotes?
[15:34] <Peng> It's mostly standard ConfigObj, FYI.
[15:35] <Peng> If you like using the Python prompt, import bzrlib.util.configobj.configobj and check how it parses it.
[15:35] <Tak> hmm, quotes don't help
[15:35]  * Tak do that
[15:40] <Tak> yeah, it's truncating the password at the comment char
[15:42] <Tak> if I single-quote it, it looks ok in the ConfigObj, but the authentication still fails
[15:43] <Tak> is it maybe getting parsed again someplace else?
[16:00] <bialix> http://martinfowler.com/bliki/VersionControlTools.html
[16:00] <bialix> bzr is not mentioned at all
[16:00] <bialix> maybe somebody know why?
[16:03] <ronny> bialix: he write why in the text
[16:03] <ronny> -i+o
[16:04] <bialix> hmm, I've missed it
[16:04] <bialix> ok, found
[18:06] <bjp> i'm seeing this bug: https://bugs.launchpad.net/loggerhead/+bug/518679
[18:06] <bjp> with bzr version 2.1.0dev5
[18:06] <bjp> and loggerhead from bzr reversion 400
[18:07] <bjp> though the second to last comment implies this is already fixed?
[18:44] <RenatoSilva> verterok: http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#timeline
[20:59] <jam> james_w: /wave
[21:00] <james_w> hi jam
[21:00] <jam> james_w: I'm happy to add an enable/disable flag for the lp cache, what would you like the default behavior to be
[21:00] <jam> ?
[21:00] <james_w> I'm happy for it to be disable the cache
[21:01] <james_w> my one concern is that other people may try two in parallel and have it fall over
[21:01] <james_w> with a confusing error
[21:01] <james_w> but I don't see a way to avoid that really
[21:02] <lifeless> james_w: why would it fall over?
[21:03] <james_w> stupid stupid cache implementation
[21:03] <jam> lifeless: https://bugs.edge.launchpad.net/launchpadlib/+bug/459418
[21:03] <jam> the cache is not multi-writer safe, aiui
[21:03] <lifeless> ah
[21:03] <lifeless> closely related to 'stupidly needing a cache'
[21:04]  * lifeless tries for bitter
[21:04] <james_w> lifeless: how would you avoid one?
[21:05] <lifeless> james_w: for lp apis?
[21:05] <james_w> yeah
[21:05] <lifeless> design it differently
[21:05] <lifeless> the amazon EC2 -style- of API's don't need a cache
[21:06] <lifeless> and operate hugely more efficiently
[21:06] <james_w> ah
[21:06] <james_w> ok
[21:06] <lifeless> specific changes are - out of band definition of APIs; a-priori defined calling method; message signing rather than cookie-auth
[21:08] <james_w> is it possible with bzr's Options to have no -- form?
[21:08] <james_w> I only need the short form
[21:08] <lifeless> yes
[21:08] <lifeless> its optparse
[21:09] <lifeless> (not that oauth is strictly cookie based)
[21:11] <james_w> well, it's not possible with Option directly as far as I can see
[21:12] <james_w> I can subclass
[21:16] <lifeless> james_w: oh interesting, its less optparse than I remember
[21:16] <lifeless> james_w: so no, it doesn't look like you can
[21:16] <jam> james_w: yeah, you'd have to override Option.add_option so that it doesn't always add '--%s' % self.name
[21:16] <jam> call it ShortOption, I guess :)
[21:17] <jam> though I'm curious why it would be a problem to have a long option, even if you don't strictly need it
[21:17] <james_w> just overhead
[21:17] <james_w> I'm taking a bunch of arguments that a subprocess takes just so I can pass them through
[21:18] <james_w> and it doesn't have long versions for some things
[21:19] <lifeless> this is for -uc and the like ?
[21:20] <james_w> yeah
[21:20] <james_w> I'm not happy with any alternative I've come with so far
[21:20] <james_w> and I have to override -v for verbose somehow
[21:21] <lifeless> you might want to override run_argv instead
[21:23] <james_w> oh, but I've never actually accepted verbose, so there won't be a behaviour change
[21:23] <jam> james_w: I've pushed an update that adds an '--lp-cache' parameter, which lets you set the lp cache directory (defaulting to None)
[21:23] <jam> It also includes my other small import-scripts tweaks
[21:25] <james_w> your happy that everyone will have to add that option if they want to make use of it in testing?
[21:26] <jam> james_w: well, lp doesn't provide things for you, and I'm not 100% sure where it should go
[21:26] <jam> for example, it could go in ~/.cache/...
[21:26] <jam> which is what bzr's launchpad plugin does
[21:26] <jam> you may or may not want to share it
[21:27] <jam> I think the # of people running it manually is probably low, vs how often it gets run in production :)
[21:27] <jam> :(, it takes 300 seconds to list the PackageToImport for gnome-panel
[21:27] <james_w> yes, but it's easy for me to change it once in production
[21:28] <james_w> jam: first time?
[21:28] <james_w> any quicker second time?
[21:28] <jam> this is the second time
[21:28] <jam> *with* the cache
[21:28] <james_w> ok
[21:28] <jam> there are 218 versions
[21:28] <james_w> well, I was thinking about the Debian cache actually
[21:28] <james_w> those files are larger than the LP wadl
[21:29] <jam> it seems it can be as fast as 100 s
[21:29] <jam> but it still took to 500s to get to "these packages are new"
[21:30] <jam>  /me wonders if --lp-cache isn't actually causing it to be slower for some crazy reason
[21:31] <james_w> well, it still has all the round trips
[21:31] <jam> sure, but I'm wondering if it doubles the round trips
[21:31] <james_w> shouldn't do
[21:31] <jam> like "is this new enough: No", ok give it to me then
[21:31] <jam> I realize it is supposed to be sending the date in the first check
[21:32] <james_w> it's using etags
[21:33] <james_w> "Give me this file unless it matches <this one>, in which case just tell me that and I'll re-use what I have."
[21:33] <james_w> are you using --no-existing?
[21:33] <jam> no
[21:34] <james_w> then it may be opening a bunch of branches on LP too
[21:35] <jam> sure, but
[21:35] <jam> http://paste.ubuntu.com/378636/
[21:35] <jam> it seems to be opening the *same* bzrdir over and over and over again
[21:36] <jam> and it still took 300s before it got the package listing
[21:37] <james_w> not sure why it seems to be repeating
[21:37] <james_w> however, the delay is just LP taking a while for a getPublishedSources call
[21:37] <james_w> which is unsurprising
[21:38] <thumper> how does bzr determine if a file is text or binary?
[21:38] <jam> seems to be from 'get_branch_parts'
[21:38] <jam> thumper: checks for \0 in the first 1024 chars
[21:39] <thumper> jam: is there a bzrlib method I can use?
[21:39] <jam> james_w: I think the issue is that: find_unimported_versions tries to open a branch locally
[21:39] <jam> and then falls back to remote
[21:39] <jam> copying that branch locally
[21:39] <jam> but if the remote branch doesn't exist
[21:39] <jam> then it just spins
[21:40] <jam> because it keeps getting None for the branch
[21:40] <jam> thumper: bzrlib.text_something.check_text_lines
[21:40] <thumper> jam: ta
[21:40] <jam> thumper: bzrlib.textfile.check_text_lines
[21:42] <james_w> jam: I don't think it will spin
[21:42] <james_w> oh, no, I see what you mean
[21:42] <james_w> yeah, that could be optimised
[21:42] <jam> yeah, for each version it tries again
[21:42] <jam> to open a branch that doesn't exist
[21:42] <jam> note that when it *does* exist
[21:42] <mkanat> So, looks like bzr doesn't understand query strings in URLs?
[21:42] <james_w> I thought you mean "while target_branch is None:"
[21:42] <jam> it still tries to open the same branch over and over again
[21:43] <jam> mkanat: I would assume that we just ignore them
[21:43] <lifeless> mkanat: do you mean loggerhead?
[21:43] <mkanat> lifeless: No, I mean bzr.
[21:43] <mkanat> bzr merge https://bugzilla.mozilla.org/attachment.cgi?id=427066 -- doesn't work.
[21:43] <lifeless> hmm, we should preserve them
[21:43] <mkanat> (That's a bundle, at that URL.)
[21:43] <lifeless> mkanat: https://bugzilla.mozilla.org/attachment.cgi?id=427066/
[21:44] <lifeless> mkanat: see the / - we add that, and moz barfs
[21:44] <lifeless> mkanat: there is a bug for this.
[21:44] <mkanat> lifeless: Ahh.
[21:44] <james_w> mkanat: does it escape them or drop them?
[21:44] <jam> james_w: no, we add a trailing slash
[21:44] <lifeless> or we may be dropping them; check a tcpdump to see precisely what happens.
[21:44] <mkanat> lifeless: The page that's getting returned seems to indicate that they're not getting through to Bugzilla at all.
[21:44] <lifeless> for opening bundles etc this is bad.
[21:44] <lifeless> mkanat: tcpdump time
[21:47] <jam> lifeless: get_transport(http+query).base has no query param
[21:47] <lifeless> ok, thats a bug
[21:47] <lifeless> we've no reason to strip query params *until* we go up a dir
[21:49] <jam> lifeless: ConnectedTransport._split_url calls urlutils.parse_url(url)
[21:49] <jam> which returns a 'path' that does not have query parameters
[21:49] <lifeless> sure
[21:49] <lifeless> just saying, that this is a bug IMO
[21:50] <jam> sure
[21:50] <jam> parse_url gets 'query' and just discards it
[21:50] <jam> it also discards "params"
[21:50] <jam> which may be a problem for colocated branches
[21:52] <IslandUsurper> is there a configuration option to control how qbzr highlights syntax? I want it to display files as PHP whose filenames don't end in .php
[21:55] <jam> lifeless: it also appears to be falling back to vfs fetch, any idea why that would be?
[21:55] <jam> both are in 2a format
[21:58] <jam> currently at 100MB downloaded according to progress bar, but only 13MB on disk... :(
[22:16] <lifeless> jam: on bzr+ssh ?
[22:16] <lifeless> jam: if you do ctrl-\ you should be able to get a backtrace; that would help determine why the fallback
[22:16] <lifeless> morning poolie
[22:16] <poolie> hi lifeless
[22:17] <jam> lifeless: not when running via import_package rather than bzr
[22:17] <jam> since it doesn't set up the signal handler
[22:18] <lifeless> jam: oh; then gdb python PID
[22:18] <lifeless> and use the gdb python macros to get a backtrace
[22:18] <jam> of course to do it "for real" requires waiting 5min (300s) for launchpad to finish giving me info...
[22:19] <poolie> jam, jeez, what are you asking it for?
[22:19] <lifeless> jam: you can attach live though :). still - yes, it will be painful
[22:20] <jam> poolie: import_package.py gnome-panel
[22:20] <jam> w/ ~ 218 getPublishedSources
[22:20] <jam> anyway, I need to be off for now
[22:20] <jam> I'll let it sit and spin a while
[22:20] <jam> gnome-control-center isn't really any faster
[22:26] <jam> ugh
[22:27] <jam> fetching "+files" redirects to "%2Bfiles"
[22:27] <jam> so anytime you download stuff from the librarian
[22:27] <jam> it involves a redirect
[22:27] <lifeless> or not 2b?
[22:27] <lifeless> isn't + 2B anyway ?
[22:28] <jam> lifeless: right, but "+" gets interpreted as " "I think
[22:28] <jam> ah wait
[22:28] <jam> I'm wrong
[22:28] <jam> +files/foo redirects to /NUMBER/foo
[22:30] <jam> 687.296  > GET /ubuntu/hoary/%2Bsource/gnome-panel/2.10.0-0ubuntu9/%2Bfiles/gnome-panel_2.10.0.orig.tar.gz
[22:30] <jam> ...
[22:30] <jam> < Location: https://launchpadlibrarian.net/1307193/gnome-panel_2.10.0.orig.tar.gz
[22:30] <lifeless> on the wire, + is 2B anyway, its in the unsafe set
[22:31] <jam> lifeless: yeah, I just read the redirect wrong
[22:32] <fullermd> Yes, I have to manually resolve those redirects every time I update the port   :|
[22:33] <lifeless> fullermd: what, why?
[22:34] <fullermd> For hysterical raisins, the fetch stage of port building doesn't follow HTTP redirects.
[22:34] <fullermd> One reason is various server configs built by geniuses that redirect to an error page rather than returning a 404, and that sort of thing.
[22:35] <lifeless> is there a flag to say 'redirects are part of the spec dumbass' ?
[22:35] <fullermd> "Not found" is a nicer error to show a user than "hey, I downloaded this file [of HTML rather than a tarball] and the size/checksum don't match"
[22:35] <lifeless> fullermd: no easier to resolve when their browser shows the thing fine.
[22:36] <fullermd> I didn't say I entirely _agreed_ with it.  It's just how it works, so either I put in the final URL, or we don't have a bzr port   :p
[22:36] <lifeless> sure
[22:36] <lifeless> jsut asking if there is an override variable
[22:36] <lifeless> there often is in ports IME
[22:37] <fullermd> Potentially, by manually overriding the FETCH_CMD or something.  But there's no ACCEPT_REDIRECTS sort of thing; the fetch(1) args are hardcoded.
[22:37] <lifeless> fullermd: sounds like a worthwhile bugfix: do it once, save time in future.
[22:37] <fullermd> That's more undercover reaching than I wanna do, so I just run a quick GET every update and copy in the new number on librarian.
[22:39] <fullermd> Yeah, it wouldn't be a huge patch to implement.  Pushing through an infrastructure change like that would be more work though; I don't want it THAT much.
[22:40] <fullermd> Anyway, it saves LP having to service a hit every download  :p
[22:40] <lifeless> think of the kittens
[22:44] <jam> james_w: as far as opening lots of branches, it doesn't help that gnome-panel is opening all of {warty,hoary,dapper,breezy,hardy,...}{,-security,-proposed,-updates,-backports,} none of which seem to exist
[22:44] <james_w> correct
[22:45] <james_w> I wasn't sure I wanted to make too many assumptions about which would exist based on others
[22:46] <jam> fortunately it seems to  be a single BzrDir.open() probe, so a single rpc requset
[22:46] <jam> at least once I added a "last_branch" cache
[23:01] <poolie> igc, hi?
[23:43] <spiv> Good morning.