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