[00:01] <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:02] <lifeless> dabreegster: 'does not work' is a little sketchy on details.
[00:03] <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:04] <dabreegster> Probably not.. format unnamed, echoes the location. not the same as doing bzr info actual_dir
[00:07] <dabreegster> If I serve over apache, same behavior. Where is my error?
[00:08] <dabreegster> bzr info http://... delivers the right format results, but explorer still refuses to read the files
[00:11] <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:12] <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
[03:38] <lifeless> spiv: run_direct seems to break plugins :(
[03:39] <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:45] <spiv> lifeless: :(
[03:46] <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:48] <lifeless> I wonder if you can get an lp object by its url
[03:48] <spiv> lifeless: yeah
[03:49] <spiv> lifeless: hopefully we won't have reason to change such a fundamental part of the Command interface again any time soon
[03:50] <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:51]  * 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:52] <wgrant> The two mappings are not documented clearly anywhere. This has been complained about before.
[03:58] <lifeless> wgrant: hey
[03:58] <lifeless> wgrant: do you know how to do 'project.series['trunk']
[03:58] <wgrant> lifeless: project.getSeries('trunk')
[03:59] <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.
[04:01] <lifeless> meh
[04:02] <lifeless> thats not a very good answer: launchpad.projects["subunit"] works, so either there is an established way, or an established workaround
[04:03] <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:04] <wgrant> Oh, right, name="trunk"
[04:04] <wgrant> How stupid.
[04:07] <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:08] <lifeless> wgrant: spiv: thanks for helping and listening :>
[04:08] <wgrant> lifeless: You were looking at IDistribution.getSeries. that takes name_or_version.
[04:09] <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:10] <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:17] <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:18] <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:19] <lifeless> self.launchpad._root_uri
[04:20] <wgrant> Aha.
[04:21] <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:22] <lifeless> yes, halved the time
[04:22] <wgrant> This is unsurprising.
[04:22] <wgrant> But patheitc.
[04:22] <wgrant> Like my spelling.
[04:25] <lifeless> wgrant: couple more questions if you have a minute
[04:26] <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:27] <wgrant> lifeless: Attribute changes are saved with obj.lp_save()
[04:28] <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:48] <lifeless> wgrant: want to hear something funny
[04:50] <wgrant> lifeless: Sure.
[04:50] <wgrant> I have time while the Launchpad test suite runs :P
[04:50] <lifeless> oh, zomg.
[04:51] <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:52] <lifeless> even if they aren't unique
[04:52] <lifeless> it would still be nice to alias them
[04:53] <lifeless> ah yes
[04:53] <lifeless> m.delete() -> 404
[04:55] <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:56] <wgrant> yeah, that.
[04:56] <lifeless> mapped into launchpad.errors for some reason
[04:59] <wgrant> Probably for compatibility.
[04:59] <wgrant> From before lazr.restfulclient existed.
[05:04] <lifeless> ok, milestone deletion and renaming adding
[05:05] <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:06] <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:07] <wgrant> Great.
[05:07] <lifeless> bug 524778 is the delete one
[05:08]  * wgrant almost has PPA download counts.
[05:09] <lifeless> cool
[05:10] <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:11] <wgrant> Doesn't that require changing the arguments that you pass to newReleasE?
[05:12] <lifeless> yes
[05:12] <lifeless> I want to decorate the milestone object
[05:13] <lifeless> with one that will take newRelease, and calculate 'now' for me, then pass that to the real milestones newRelease
[05:14] <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:15] <wgrant> I don't know of a way to decorate returned entries.
[05:17] <lifeless> wgrant: that would be nice.
[05:17] <lifeless> however, I don't have the space on this box
[05:18] <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:20] <wgrant> Yeah, that sort of thing happens through the web UI too.
[05:21] <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:22] <lifeless> well, for now, manual unrelease.
[05:22] <wgrant> Also, staging.
[05:25] <lifeless> meh, that would mean making this code configurable to use staging.
[05:26] <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:39] <lifeless> wgrant: any suggestions on this 5 hour thing?
[05:40] <lifeless> wgrant: actually nvm for now
[05:40] <wgrant> lifeless: datetime.datetime.now()?
[05:42] <lifeless> wgrant: already doing
[05:44] <lifeless> yuck, useless
[05:44] <wgrant> Hm?
[05:44] <lifeless> thats not utc; gmtime ftw
[05:47] <lifeless> huh 503'd it
[05:47] <wgrant> That's normally a timeout.
[05:52] <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:53] <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:54] <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:55] <wgrant> So you're calling Milestone.createProductRelease?
[05:57] <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:58] <dOxxx> howdy
[06:05] <lifeless> wgrant: weird
[06:06] <lifeless> let me try fresh, /just/ in case
[06:09] <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:10] <lifeless> wgrant: ^
[06:11] <wgrant> lifeless: Interesting. File it, I guess.
[06:11] <lifeless> doing so :)
[06:20] <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:25] <lifeless> usually that means that your locale is not setup correctly
[06:26] <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:28] <naoki_> zmcgrew: Can you paste .bzr.log?
[06:31] <zmcgrew> http://devnull.lunar-linux.org/p/1041
[06:34] <zmcgrew> is that of any help, naoki_?
[06:50] <naoki_> Do you have non utf-8 filename in your home or subdirs?
[06:51] <zmcgrew> is there a way to find it if I do?
[06:51] <naoki_> $ find . > fsdump
[06:52] <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:53] <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:54] <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:55] <naoki_> But if can't decode, the filename in os.listdir() is byte string.
[06:56] <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:57] <zmcgrew> '02 - Blind Melon - Dear Ol\xb4 Dad.mp3'
[06:58] <naoki_> # BTW, In Python3, os.listdir(unicode) returns list contains all unicode filename. Py3k converts undecodable filename into special unicode.
[06:59] <lifeless> naoki_: yes, its terrible.
[06:59] <lifeless> naoki_: its going to give us lots of grief.
[07:02] <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:03] <zmcgrew> perfect! I didn't actually want it tracking my music library, I was just going to add my configs
[07:12] <lifeless> its a bit of a bug that bzr looks at everything when yo do init
[07:13] <lifeless> it doesn't actually add it regardless
[15:47] <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:49] <jelmer> rocky: I've seen a report about it
[15:50] <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:51] <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:52] <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:53] <rocky> yeah
[15:55] <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
[22:50] <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:51]  * Jak_o_Shadows is a git user
[22:51] <lifeless> Jak_o_Shadows: bzr branch lp:projectname
[22:52] <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:53] <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:54] <Jak_o_Shadows> i probably don't
[22:54] <Lo-lan-do> Err, I meant "bzr checkout --lightweight lp:projectname"
[22:55] <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:56] <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
[23:51] <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:52] <lifeless> there is bzr-dbus
[23:52] <lifeless> which broadcasts revision changes
[23:53] <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:54] <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:55] <meoblast001> then i could simply create a VC-Announce plugin for my bot
[23:56] <meoblast001> lifeless: is there a post_branch_tip_change_result?
[23:59] <meoblast001> oh, there's a list of hooks