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