| dabreegster | I'm serving a bzr trunk with serve --directory=. and attempting to connect with bzr-explorer. bzr://host:4155 doesnt work, nor /branchname. "This branch has no working tree. Last revision is 106" -- the revision's correct, so I know it's talking to the server. | 00:01 |
|---|---|---|
| lifeless | dabreegster: 'does not work' is a little sketchy on details. | 00:02 |
| dabreegster | The error message "This branch has no working tree" appears, and I fail to see a file listing | 00:03 |
| lifeless | does 'bzr info bzr://localhost/' work ? | 00:03 |
| dabreegster | Probably not.. format unnamed, echoes the location. not the same as doing bzr info actual_dir | 00:04 |
| dabreegster | If I serve over apache, same behavior. Where is my error? | 00:07 |
| dabreegster | bzr info http://... delivers the right format results, but explorer still refuses to read the files | 00:08 |
| lifeless | I suspect a limitation of explorer | 00:11 |
| lifeless | if bzr info reports format unnamed, thats ok | 00:11 |
| lifeless | as long it says 'branch' in the output | 00:11 |
| lifeless | file a bug on bzr-explorer I think | 00:11 |
| dabreegster | Alright | 00:11 |
| dabreegster | I thought this'd be core behavior, letting other people connect to my branch and work | 00:11 |
| lifeless | I'm a CLI user, no comment ;) | 00:12 |
| lifeless | I'd assume bzr explorer has a 'make a branch' feature though, which is where a remote url would be most useful. | 00:12 |
| dabreegster | Likewise, but the other person working with me isnt comfortable with ssh | 00:12 |
| lifeless | the core bzr lib doesn't care whether things are local or remote for accessing history | 00:12 |
| dabreegster | Right | 00:12 |
| lifeless | spiv: run_direct seems to break plugins :( | 03:38 |
| lifeless | spiv: in that, commands needing run_direct called, won't have it called from plugins that override run_argv_with_aliases | 03:39 |
| lifeless | I wish python has aspects | 03:39 |
| spiv | lifeless: :( | 03:45 |
| lifeless | spiv: I'm not sure what you could have done differently, as run_argv called run directly, so there wasn't really an existing 'will not be overridden' place to override | 03:46 |
| lifeless | and run() is hostile to being overriden because it has argv expanded | 03:46 |
| lifeless | I wonder if you can get an lp object by its url | 03:48 |
| spiv | lifeless: yeah | 03:48 |
| spiv | lifeless: hopefully we won't have reason to change such a fundamental part of the Command interface again any time soon | 03:49 |
| lifeless | we need to update loom and other plugins soon though :) | 03:50 |
| lifeless | like, before lucid releases. | 03:50 |
| * lifeless is still seconded | 03:50 | |
| * lifeless complains about lp apis | 03:51 | |
| lifeless | https://edge.launchpad.net/+apidoc/#project | 03:51 |
| lifeless | how, looking just at that, are you meant to figure out that lplib will have a .series attribute on project | 03:51 |
| wgrant | The two mappings are not documented clearly anywhere. This has been complained about before. | 03:52 |
| lifeless | wgrant: hey | 03:58 |
| lifeless | wgrant: do you know how to do 'project.series['trunk'] | 03:58 |
| wgrant | lifeless: project.getSeries('trunk') | 03:58 |
| lifeless | _ugh_ | 03:59 |
| wgrant | series is a sequence. | 03:59 |
| lifeless | let me repeat, _ugh_ | 03:59 |
| * lifeless files a bug | 03:59 | |
| wgrant | Sort of. | 03:59 |
| wgrant | Batching dicts is messy. | 03:59 |
| lifeless | meh | 04:01 |
| lifeless | thats not a very good answer: launchpad.projects["subunit"] works, so either there is an established way, or an established workaround | 04:02 |
| wgrant | Is launchpad.projects iterable? | 04:03 |
| lifeless | don't know, don't care :) | 04:03 |
| * lifeless has his user hat firmly on | 04:03 | |
| lifeless | also, while I'm whinging | 04:03 |
| lifeless | getSeries("trunk") does not work | 04:03 |
| lifeless | bzr: ERROR: exceptions.TypeError: Method must be called with keyword args. | 04:03 |
| wgrant | Oh, right, name="trunk" | 04:04 |
| wgrant | How stupid. | 04:04 |
| lifeless | well the apidoc suggested name_or_version | 04:07 |
| lifeless | so I tried that next; boom | 04:07 |
| lifeless | bzr: ERROR: exceptions.ValueError: No value for required parameter 'name' | 04:07 |
| lifeless | excellent, it works. | 04:07 |
| lifeless | only takes 30 seconds; so it is faster than a web browser. | 04:07 |
| lifeless | wgrant: spiv: thanks for helping and listening :> | 04:08 |
| wgrant | lifeless: You were looking at IDistribution.getSeries. that takes name_or_version. | 04:08 |
| lifeless | wgrant: /sigh | 04:09 |
| lifeless | there is an implicit bug there about how the api docs are presented | 04:09 |
| lifeless | but I don't feel like filing 4 bugs in 10 minutes | 04:09 |
| wgrant | I don't think so. | 04:09 |
| wgrant | You were looking at the wrong part! | 04:09 |
| lifeless | wgrant: it is hard to tell that I am looking at the wrong part | 04:10 |
| wgrant | This is true. | 04:10 |
| lifeless | wgrant: that is the bug | 04:10 |
| lifeless | wgrant: is there some way to avoid traversing the object graph | 04:17 |
| wgrant | lifeless: lp.load('https://api.launchpad.net/api/whatevertheyhavedecidedtoversionthistoday/bzr/trunk') | 04:17 |
| wgrant | whatevertheyhavedecidedtoversionthistoday is 'beta' now, but that will change soon. | 04:18 |
| lifeless | garh | 04:18 |
| wgrant | Although it's possible that lp.load takes a relative path now -- try it. | 04:18 |
| lifeless | I have the /bzr/trunk/ bit | 04:18 |
| lifeless | https://code.edge.launchpad.net/~lifeless/lptools/upstream/+merge/19764 if you're interested in the thing I made | 04:18 |
| lifeless | self.launchpad._root_uri | 04:19 |
| wgrant | Aha. | 04:20 |
| lifeless | print self.launchpad.load(str(self.launchpad._root_uri) + projectname + '/' + seriesname) | 04:21 |
| lifeless | seems to work | 04:21 |
| lifeless | time to see if its faster | 04:21 |
| lifeless | yes, halved the time | 04:22 |
| wgrant | This is unsurprising. | 04:22 |
| wgrant | But patheitc. | 04:22 |
| wgrant | Like my spelling. | 04:22 |
| lifeless | wgrant: couple more questions if you have a minute | 04:25 |
| lifeless | milestone.delete is present | 04:26 |
| lifeless | but what about renames? | 04:26 |
| lifeless | do I just assign to milestone.name ? | 04:26 |
| lifeless | if so, how do I commit the change? | 04:26 |
| wgrant | lifeless: Attribute changes are saved with obj.lp_save() | 04:27 |
| lifeless | thanks | 04:28 |
| wgrant | I'm not sure how well launchpadlib will like you renaming it, but it will work server-side. | 04:28 |
| wgrant | You might just have to watch out for a 404 on the client. | 04:28 |
| wgrant | If lp_save naively tries to refresh it afterwards. | 04:28 |
| lifeless | wgrant: want to hear something funny | 04:48 |
| wgrant | lifeless: Sure. | 04:50 |
| wgrant | I have time while the Launchpad test suite runs :P | 04:50 |
| lifeless | oh, zomg. | 04:50 |
| lifeless | sorry, I assumed milestones were namespaced under series | 04:51 |
| * lifeless is not thrilled by this | 04:51 | |
| wgrant | Everyone thinks that's a bit odd. | 04:51 |
| lifeless | even if they aren't unique | 04:52 |
| lifeless | it would still be nice to alias them | 04:52 |
| lifeless | ah yes | 04:53 |
| lifeless | m.delete() -> 404 | 04:53 |
| lifeless | wgrant: offhand, what module does HTTPError come from | 04:55 |
| wgrant | lifeless: Probably httplib2 | 04:55 |
| wgrant | Hm, maybe not. | 04:55 |
| lifeless | lazr.restfulclient.errors.HTTPError | 04:55 |
| wgrant | yeah, that. | 04:56 |
| lifeless | mapped into launchpad.errors for some reason | 04:56 |
| wgrant | Probably for compatibility. | 04:59 |
| wgrant | From before lazr.restfulclient existed. | 04:59 |
| lifeless | ok, milestone deletion and renaming adding | 05:04 |
| lifeless | .rename handled the change fine | 05:05 |
| lifeless | .delete was the problem | 05:05 |
| wgrant | Interesting. | 05:05 |
| lifeless | few things support delete | 05:05 |
| lifeless | so I suspect rename has been hit and handled generically | 05:06 |
| wgrant | rename might be handled by just reading back the correct self_link from the returned object. | 05:06 |
| wgrant | Proper deletion is implemented in lazr.restful, but not yet lazr.restfulclient. | 05:06 |
| lifeless | for instance, yes. | 05:06 |
| wgrant | (you can expoes a destructor in the interface, but launchpadlib doesn't know how to call it yet) | 05:06 |
| lifeless | anyhow, I filed bugs on every glitch :) | 05:06 |
| wgrant | Great. | 05:07 |
| lifeless | bug 524778 is the delete one | 05:07 |
| ubottu | Launchpad bug 524778 in launchpad "milestone.delete() tries to refresh" [Undecided,New] https://launchpad.net/bugs/524778 | 05:07 |
| * wgrant almost has PPA download counts. | 05:08 | |
| lifeless | cool | 05:09 |
| lifeless | is there a hook point in launchpad lib to allow decorating returned objects? | 05:10 |
| lifeless | so that I can fix bugs like 'making a release wants a date for no good reason' | 05:10 |
| lifeless | (locally fix that is) | 05:10 |
| wgrant | Doesn't that require changing the arguments that you pass to newReleasE? | 05:11 |
| lifeless | yes | 05:12 |
| lifeless | I want to decorate the milestone object | 05:12 |
| lifeless | with one that will take newRelease, and calculate 'now' for me, then pass that to the real milestones newRelease | 05:13 |
| wgrant | Oh, right, I was thinking the method was on ProductSeries. | 05:14 |
| wgrant | What you really want to do is write two lines of code and get it merged into Launchpad and rolled out to edge on Monday or Tuesday. | 05:14 |
| wgrant | I don't know of a way to decorate returned entries. | 05:15 |
| lifeless | wgrant: that would be nice. | 05:17 |
| lifeless | however, I don't have the space on this box | 05:17 |
| wgrant | Ah. | 05:18 |
| lifeless | I'm working towards that, but time ;> | 05:18 |
| lifeless | deleting stuff is harder than it sounds | 05:18 |
| lifeless | hah | 05:18 |
| lifeless | check https://edge.launchpad.net/subunit/trunk | 05:18 |
| lifeless | note the odd time of release | 05:18 |
| wgrant | Yeah, that sort of thing happens through the web UI too. | 05:20 |
| lifeless | still, now I can easily delete subunit/test; create subunit/test; release subunit/test | 05:21 |
| lifeless | oh, no I can't | 05:21 |
| lifeless | because its been released. wt | 05:21 |
| lifeless | f | 05:21 |
| lifeless | well, for now, manual unrelease. | 05:22 |
| wgrant | Also, staging. | 05:22 |
| lifeless | meh, that would mean making this code configurable to use staging. | 05:25 |
| lifeless | its much less effort to tickle a losa to undo the sort of trivial mistake I can cause with what I'm doing | 05:26 |
| wgrant | Heh. | 05:26 |
| lifeless | wgrant: any suggestions on this 5 hour thing? | 05:39 |
| lifeless | wgrant: actually nvm for now | 05:40 |
| wgrant | lifeless: datetime.datetime.now()? | 05:40 |
| lifeless | wgrant: already doing | 05:42 |
| lifeless | yuck, useless | 05:44 |
| wgrant | Hm? | 05:44 |
| lifeless | thats not utc; gmtime ftw | 05:44 |
| lifeless | huh 503'd it | 05:47 |
| wgrant | That's normally a timeout. | 05:47 |
| lifeless | yeah | 05:52 |
| lifeless | so I'm sending | 05:52 |
| lifeless | 2010-02-20-05:47:11 | 05:52 |
| lifeless | and its creating it 5 hours ago | 05:52 |
| wgrant | Awesome. | 05:52 |
| wgrant | You're not just getting a cached/slave version in the web UI? | 05:52 |
| lifeless | which would be Sat Feb 20 00:53:11 2010 UTC | 05:53 |
| lifeless | so I wonder if its ignoring the timestamp | 05:53 |
| lifeless | for some _bizarre_ reason | 05:53 |
| lifeless | could you perhaps have a peek at the code, if you have it handy | 05:54 |
| wgrant | Once the test suite unlags my system. | 05:54 |
| lifeless | and yes, I'm pretty sure | 05:54 |
| wgrant | So you're calling Milestone.createProductRelease? | 05:55 |
| wgrant | lifeless: I can't see anything that would be stripping the timestamp. | 05:57 |
| wgrant | The interface is Datetime, and then it just goes straight into a Storm's SQLObject wrapper __init__, and then into a UtcDateTimeCol. | 05:57 |
| dOxxx | howdy | 05:58 |
| lifeless | wgrant: weird | 06:05 |
| lifeless | let me try fresh, /just/ in case | 06:06 |
| lifeless | so, I sent 2010-02-20-06:07:45 | 06:09 |
| lifeless | https://edge.launchpad.net/subunit/trunk | 06:09 |
| lifeless | it now claims 6 hours ago | 06:09 |
| lifeless | which is consistent with it dropping the minutes | 06:09 |
| lifeless | wgrant: ^ | 06:10 |
| wgrant | lifeless: Interesting. File it, I guess. | 06:11 |
| lifeless | doing so :) | 06:11 |
| zmcgrew | i'm getting an odd error from bzr (2.1.0) when I try and create a new repo with "bzr init" -- UnicodeDecodeError: 'ascii' codec can't decode byte 0xb4 in position 26: ordinal not in range(128) | 06:20 |
| lifeless | usually that means that your locale is not setup correctly | 06:25 |
| lifeless | -and- | 06:26 |
| lifeless | you have a utf8 or whatever encoding you should be using character in the containing path or nearby | 06:26 |
| zmcgrew | encoding: 'UTF-8', fsenc: 'UTF-8', lang: 'en_US.utf8' | 06:26 |
| naoki_ | zmcgrew: Can you paste .bzr.log? | 06:28 |
| zmcgrew | http://devnull.lunar-linux.org/p/1041 | 06:31 |
| zmcgrew | is that of any help, naoki_? | 06:34 |
| naoki_ | Do you have non utf-8 filename in your home or subdirs? | 06:50 |
| zmcgrew | is there a way to find it if I do? | 06:51 |
| naoki_ | $ find . > fsdump | 06:51 |
| fullermd | Probably not the issue, since it's trying to read things in us-ascii. | 06:52 |
| naoki_ | And open fsdump with editor supporting utf-8 | 06:52 |
| lifeless | zmcgrew: run with -Derror, you should get a backtrace | 06:52 |
| lifeless | ah yes | 06:53 |
| naoki_ | Maybe, bzr-init on $HOME is not a good idea. | 06:53 |
| naoki_ | There are many many nonordinal files... | 06:53 |
| naoki_ | bzr do sorted(os.listdir(top)) | 06:54 |
| lifeless | actually | 06:54 |
| lifeless | do BZR_PDB=1 bzr init | 06:54 |
| lifeless | then you can look at what failed with pdb | 06:54 |
| naoki_ | os.listdir(unicode) returns list contains unicode filenames if filename can decode with filesystemencoding | 06:54 |
| naoki_ | But if can't decode, the filename in os.listdir() is byte string. | 06:55 |
| zmcgrew | I tracked it down the BZR_PDB=1 | 06:56 |
| naoki_ | sorted([u"unicode string", "\x99 non ascii byte string"]) result in UnicodeDecodeError | 06:56 |
| zmcgrew | it's failing when it runs through my music library | 06:56 |
| zmcgrew | '02 - Blind Melon - Dear Ol\xb4 Dad.mp3' | 06:57 |
| naoki_ | # BTW, In Python3, os.listdir(unicode) returns list contains all unicode filename. Py3k converts undecodable filename into special unicode. | 06:58 |
| lifeless | naoki_: yes, its terrible. | 06:59 |
| lifeless | naoki_: its going to give us lots of grief. | 06:59 |
| zmcgrew | short of renaming that file and all other files it may encounter, is there a fix? | 07:02 |
| lifeless | zmcgrew: sure | 07:02 |
| lifeless | zmcgrew: bzr init tempdir | 07:02 |
| lifeless | mv tempdir/.bzr . | 07:02 |
| zmcgrew | perfect! I didn't actually want it tracking my music library, I was just going to add my configs | 07:03 |
| lifeless | its a bit of a bug that bzr looks at everything when yo do init | 07:12 |
| lifeless | it doesn't actually add it regardless | 07:13 |
| rocky | jelmer, ping | 15:47 |
| jelmer | rocky: pong | 15:47 |
| rocky | jelmer, ever see something like ... bzr: ERROR: A Subversion remote access command failed: MERGE of '/svn/cluemapper': 200 OK (https://dev.serverzen.com) | 15:47 |
| jelmer | rocky: I've seen a report about it | 15:49 |
| jelmer | rocky: when are yo ugetting this, while pushing? | 15:50 |
| rocky | jelmer, yep, just pushed a new branch int osvn | 15:50 |
| jelmer | rocky: Did the commit actually end up being pushed? | 15:50 |
| jelmer | if so, I wonder if this is a post-commit hook failing | 15:50 |
| rocky | i do have a post-commit hook | 15:51 |
| rocky | jelmer, although it looks to go away with bzr-svn 1.0.2 (i was using 1.0.1) | 15:51 |
| jelmer | can you reproduce the error with 1.0.1 ? | 15:51 |
| rocky | yes | 15:52 |
| jelmer | it's a pity this is a SSL connection, would be nice to look at the contents of the response that the http server is sending back | 15:52 |
| rocky | yeah | 15:53 |
| Peng | Eh? You're +o, jelmer? | 15:55 |
| jelmer | rocky: interesting that you can't reproduce with 1.0.2 | 15:55 |
| jelmer | rocky: if you can at some point it would be interesting to look at the children of that error | 15:55 |
| Jak_o_Shadows | with bazaar and launchpad, is it possible to just get a copy of the code? | 22:50 |
| Jak_o_Shadows | i don't want to commit or push anything yet | 22:50 |
| * Jak_o_Shadows is a git user | 22:51 | |
| lifeless | Jak_o_Shadows: bzr branch lp:projectname | 22:51 |
| Jak_o_Shadows | i get | 22:52 |
| Jak_o_Shadows | You have not informed bzr of your Launchpad ID, and you must do this to | 22:52 |
| Jak_o_Shadows | write to Launchpad or access private data. See "bzr help launchpad-login". | 22:52 |
| lifeless | yes, but as you said you don't want to push yet | 22:52 |
| Jak_o_Shadows | all i did wasbzr branch lp:pymeta | 22:53 |
| Lo-lan-do | You can also do a bzr checkout lightweight, if you don't care about history. | 22:53 |
| Jak_o_Shadows | i probably don't | 22:54 |
| Lo-lan-do | Err, I meant "bzr checkout --lightweight lp:projectname" | 22:54 |
| lifeless | Lo-lan-do: no, don't do tht | 22:55 |
| lifeless | Lo-lan-do: it is bad advice because it performs very slowly | 22:55 |
| lifeless | Jak_o_Shadows: you did fine. 'ls pymeta' should show you the code you wanted | 22:55 |
| Lo-lan-do | Slower than a full branch? | 22:55 |
| lifeless | Lo-lan-do: orders of magnitude slower | 22:55 |
| lifeless | Lo-lan-do: only suitable for LAN and local disk usage | 22:56 |
| Lo-lan-do | Something is rotten in the kingdom of bzrmark… | 22:56 |
| Jak_o_Shadows | oh, i know waht the problem was | 22:56 |
| Jak_o_Shadows | i already had a /pymeta folder | 22:56 |
| Jak_o_Shadows | thanks | 22:56 |
| meoblast001 | i'm going to make a Bazaar plugin for Bazaar servers that notifies my IRC bot when commits are pushed... should i use a network socket or does Bazaar/Python contain some better way to accomplish this? | 23:51 |
| lifeless | there is bzr-dbus | 23:52 |
| lifeless | which broadcasts revision changes | 23:52 |
| meoblast001 | what does it broadcast them to? | 23:53 |
| lifeless | there's also existing irc plugins | 23:53 |
| lifeless | meoblast001: dbus | 23:53 |
| meoblast001 | lifeless: where could those existing plugins be found? | 23:53 |
| mathrick | oh cute, bzr-git trunk requires dulwhich "0.5.0", which hasn't been released yet | 23:54 |
| meoblast001 | do i want to use the hook post_push | 23:54 |
| meoblast001 | this is on the server end, so i'm assuming not | 23:54 |
| lifeless | meoblast001: you need post_branch_tip_change | 23:54 |
| meoblast001 | ok, thanks | 23:54 |
| meoblast001 | then i could simply create a VC-Announce plugin for my bot | 23:55 |
| meoblast001 | lifeless: is there a post_branch_tip_change_result? | 23:56 |
| meoblast001 | oh, there's a list of hooks | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!