[00:01] <mkanat> lifeless: A modification to "bzr patch" would probably be the place, yeah?
[00:02] <lifeless> mkanat: yes, that might make sense. or import-patch, a new command.
[00:03] <mkanat> Yeah. Although I'd like to see "patch" do other nice things, too (like understand renames), so it might just make sense to improve it.
[00:20] <bob2> meoblast001: struct module isn't that bad
[00:36] <lifeless> mornink poolie
[00:36] <poolie> hello there
[00:37] <lifeless> mkanat: I think it would surprise people to have 'patch' do a commit ;). I think there are two use cases, but probably we want common code paths internally.
[00:37] <mkanat> lifeless: Well, yeah, doing a commit would be surprising for sure. :-)
[00:37] <lifeless> mkanat: but thats what I want it to do; commit on a temp branch and merge back
[00:37] <mkanat> Ah, okay.
[00:38] <lifeless> mkanat: and you said you'd like that as well :>
[00:38] <meoblast001> bob2: yeah, but how can i guarantee that it's 4 bytes bigendian?
[00:38] <mkanat> lifeless: Yeah, for sure. bzr diffs include date info, so you could even do it automatically.
[00:38] <lifeless> meoblast001: by the format you give it
[00:39] <mkanat> lifeless: If no revno was specified.
[00:39] <meoblast001> ah, ok
[00:39] <lifeless> pydoc struct
[00:45] <lifeless> hmm, functions there have bad docs; you'll want the python online docs.
[00:46] <lifeless> mbarnett: are you around
[00:46] <jml> the pypy people are interested in getting benchmarks from various python projects
[00:47] <lifeless> awesome
[00:47] <jml> does bzr have some benchmark scripts to share?
[00:47] <lifeless> usertest
[00:47] <lifeless> its kindof a plugin
[00:47] <poolie> hello jml
[00:47] <lifeless> it runs bzr against real-worldish scenarios
[00:48] <lifeless> and the 'bzr' it runs can be differnet versions, or run in customised ways
[00:48] <lifeless> so it should be easy to tweak it to say 'pypy bzr' rather than 'bzr'
[00:48] <lifeless> poolie: I've just submitted a 'use subunit' patch to PQM, that spiv reviewed over the weekend.
[00:49] <poolie> ok...
[00:49] <lifeless> poolie: should be no fallout, but if there is its my fault, sic me onto it.
[00:49] <poolie> actually when you mean 'to pqm'
[00:49] <poolie> do you mean changing pqm, or changing bzrlib?
[00:49] <lifeless> pqm.bazaar-vcs.org
[00:50] <lifeless> changing bzrlibs Makefile
[00:50] <poolie> :/
[00:51] <poolie> you know sometimes people say "but i'll give people a chance to object"
[00:51] <lifeless> poolie: I was of the understanding that it was simply tuits missing to do this; so I found somes.
[00:51] <lifeless> poolie: it was up in the queue for over a day; and its easy to back out
[00:51] <lifeless> poolie: I didn't think it was contentious
[00:53] <poolie> i think it's worth a try
[00:53] <poolie> i'm just saying saturday night to monday morning is not really likely to have people see it
[00:53] <poolie> so this makes subunit a hard dependency to run bzr check
[00:54] <poolie> that might be worth documenting
[00:54] <lifeless> 'make check' specifically
[00:54] <poolie> s//make check
[00:54] <lifeless> not selftest, which is what we generally advise.  Yes, good point, I'll add some doc
[00:55] <poolie> i'm pretty sure that pqm's mail stuff is not 8-bit clean therefore it the stream parser will crash
[00:55] <poolie> but we'll see
[00:55] <poolie> istr it reads it as lines and reinserts \ns
[00:55] <poolie> but it may work
[00:56] <lifeless> poolie: I don't think that the weekend should really be specially treated; we only have 24 hours of non-core-people-working coverage regardless; and we more core committers than staff paid to work on bzr [at this point in time]
[00:56] <lifeless> poolie: once it lands I'll send a broken patch through to see how it handles it
[00:57] <poolie> i think there's pretty clearly more activity from both staff and nonstaff developers during the week
[00:59] <poolie> anyhow
[00:59] <poolie> if that works it'll be good
[00:59] <poolie> s/if/when :)
[01:00] <lifeless> we don't have an official quiet-period where things approved get a chance to be looked over by other people at the moment; I don't understand why patches put in in the weekend should get one, and ones in the week not get one.
[01:00] <lifeless> I'm not trying to be difficult, I really don't see the connection
[01:01] <lifeless> we do have a 'use judgment' angle; the flipside to that is that people will
[01:02] <exarkun> I'm noticing some issues with running 'bzr svn-import' against the same repository multiple times concurrently
[01:02] <exarkun> I'm going to file a ticket or two about it I guess
[01:04] <lifeless> poolie: it failed to land anyhow; subunit isn't in the chroot (which is odd because we had it in the chroot a few months back; possibly before we upgraded the chroot though)
[01:04] <poolie> so
[01:04] <poolie> people tend to have comments on changes to infrastructure
[01:04] <poolie> it's just polite to give them a chance to express those opinions
[01:05] <poolie> considering the review concluded at midnight on sunday(!) looks a bit like routing around it
[01:05] <poolie> i think the actual change is fine
[01:06] <lifeless> If I had submitted it at 1am I could understand that perspective; but I submitted it at 11:30am or so
[01:06] <poolie> i expect it will break but it should be fixable, and it's worth fixing
[01:06] <lifeless> very much not avoiding things; everything to do with spiv's sleep schedule :)
[01:07] <lifeless> something about this leaves me unsettled. I need to mull on it I think.
[01:21] <mkanat> mwhudson: Any new crashes?
[01:25] <twb> I'm rolling binary packages from a bzr repository.  I want a way to get a short, monotonically increasing string to describe the repository state.  Bonus points if it is in <last tag name>+<revisions since last tag> format rather than just <number of revisions>.
[01:25] <twb> The git equivalent is "git describe --tags" and the hg equivalent is hg parents --template '{latesttag}+{latesttagdistance}\n'
[01:25] <lifeless> twb: bzr revno
[01:26] <lifeless> you'll want to set the 'is a mainline' flag to stop people pushing altered trunks though
[01:26] <lifeless> append_revisions_only=True
[01:30] <mwhudson> mkanat: no
[01:31] <mkanat> mwhudson: Okay.
[01:34] <twb> v=$(bzr tags | tail -1); v=${v%% *}+$(($(bzr revno) - ${v##* }))
[01:36] <fullermd> That sounds...   unuseful.
[01:36] <fullermd> For one things, tags sorts by the tag name, and for another, they may not be on integral revnos.
[01:37] <twb> You have fractional revnos?
[01:38] <fullermd> Not exactly, but they read that way.
[01:38] <twb> Blergh
[01:38] <twb> These packages aren't important, so I'll use that shitty code until it breaks
[01:40] <twb> Is it just me, or is bzr export REALLY slow on a --lightweight checkout?
[01:40] <fullermd> If the branch is very far away, that wouldn't be surprising.
[01:41] <twb> It's lp:dosage, fwiw
[01:42] <fullermd> Across the internet easily qualifies as "very far away"   :)
[01:44] <twb> I notice that bzr export eats the existing file instead of writing to a temp file and then doing a final move.
[01:44] <twb> i.e. while bzr export is running, or if it is interrupted, the old tarball is bogus
[01:45] <fullermd> Well, it's probably not really designed for its destination to exist already.
[02:25] <meoblast001> lifeless: in the doc for bzrlib.branch.ChangeBranchTipParams, i can't find anything about commit author
[02:30] <lifeless> meoblast001: branch/repository.get_revision(new_revid).authors
[02:30] <meoblast001> ah, ok
[02:30] <meoblast001> uh oh, bazaar choked on my plugin
[02:32] <meoblast001> lifeless: is the bzrlib.branch.ChangeBranchTipParams my branch/repository?
[02:32] <meoblast001> or is that a member of it
[02:32] <meoblast001> or do i just use "branch"
[02:33] <lifeless> meoblast001: it has a branch attribute
[02:33] <lifeless> see the pydoc for i
[02:33] <lifeless> it
[02:33] <meoblast001> ah, ok, i see now
[02:33] <meoblast001> there seems to be a lot of "branch" in Bazaar :P
[02:34] <meoblast001> lifeless: is there a place i could go to see all the members of this branch, that way i can stop nagging you :P
[02:36] <lifeless> meoblast001: pydoc + the source
[02:36] <lifeless> there are apidocs mwhudson publishes somewhere
[02:36] <meoblast001> i tried bzrlib.branch.ChangeBranchTipParams.branch, but got no Python documentation found for 'bzrlib.branch.ChangeBranchTipParams.branch'
[02:37] <meoblast001> but then again, i shouldn't be guessing, as this is my first day ever writing Python code
[02:37] <meoblast001> and i don't even know where the source to those .py files lie
[02:48] <lifeless> meoblast001: just do pydoc bzrlib.branch.ChangeBranchTipParams
[02:48] <lifeless> the branch attribute is a 'bzrlib.branch.Branch'
[02:48] <meoblast001> lifeless: i did that
[02:49] <lifeless> so pydoc bzrlib.branch.Branch
[02:49] <meoblast001> i'm so lost of what derives from what, what already exists
[02:49] <meoblast001> ok, thanks
[02:50] <meoblast001> lifeless: i can't find repository or get_revision
[02:52] <meoblast001> oh yay, i managed to crash pydoc
[03:31] <meoblast001> lifeless: is there an online documentation for this?
[03:31] <meoblast001> it would probably be easier for me
[03:32] <lifeless> yes, mwhudson has apidocs published
[03:32] <lifeless> mwhudson: where are they?
[03:32] <mwhudson> lifeless: python.net/~mwh/bzrlibapi
[03:32] <mwhudson> might be a bit out of date now actually
[03:32] <lifeless> meoblast001: ^
[03:33] <meoblast001> ok, thanks
[03:33] <meoblast001> i hope i can do this >.<
[03:33] <lifeless> you could mail the list and ask for help
[03:33] <lifeless> folk do that quite regularly.
[03:33] <meoblast001> i think my Python knowledge is just horrible
[03:34] <meoblast001> i can't understand if i'm supposed to be using branch.Branch, or branch.repository, or result.branch
[03:35] <meoblast001> probably would be easier for me to write a Git plugin but i don't use Git
[03:35] <lifeless> meoblast001: the params object you're given has a branch attribute
[03:36] <lifeless> that is a branch object
[03:36] <meoblast001> ok
[03:36] <meoblast001> that's what i was wondering
[03:36] <lifeless> meoblast001: it is an instance of bzrlib.branch.Branch
[03:36] <meoblast001> there is no get_revision() function in Branch though, according to the docs
[03:36] <lifeless> meoblast001: thats right. you want branch.repository.get_revision()
[03:37] <lifeless> where branch is the branch object you're starting from
[03:37] <meoblast001> hm, it's not listing a member named repository in the docs
[03:37] <meoblast001> http://python.net/~mwh/bzrlibapi/bzrlib.branch.Branch.repository.html < also does not exist
[03:38] <lifeless> meoblast001: so your function is called with an object. I'm going to call that 'params'
[03:38] <lifeless> 'params.branch' is a Branch instance.
[03:38] <meoblast001> ah, ok
[03:39] <lifeless> Branch instances have a repository attribute. So 'params.branch.repository' is an instance of bzrlib.repository.Repository
[03:39] <lifeless> meoblast001: you can examine this interactively.
[03:39] <meoblast001> what does get_revision(new_revid) return?
[03:39] <lifeless> define your hook function as
[03:39] <lifeless> def myhook(params):
[03:39] <lifeless>     import pdb;pdb.set_trace()
[03:40] <lifeless> now do a pull or something in a test branch
[03:40] <lifeless> you'll drop into pdb
[03:40] <lifeless> you can use 'pp params' to pretty print params
[03:40] <lifeless> dir(params) to see the attributes of params
[03:40] <meoblast001> yay
[03:40] <meoblast001> found the revision object
[03:40] <lifeless> 'vars(params)' to see its variables and their values
[03:41] <meoblast001> hm, can't find a list of its members though
[03:41] <meoblast001> only its member functions
[03:41] <lifeless> the revision object docs are a bit weak
[03:41] <lifeless> however
[03:41] <lifeless> vars(revisionobject)
[03:41] <lifeless> should print something sensible
[03:42] <meoblast001> silly me, // does not comment Python code >.<
[03:42]  * meoblast001 needs to use #
[03:43] <lifeless> using pdb will probably help you explore the system a lot
[03:43] <lifeless> even if it has a little learning curve
[03:43] <meoblast001> yeah, i'm getting no arguments passed to my function
[03:43] <meoblast001> Post_Change_Branch_Tip() takes exactly 1 argument (0 given)
[03:43] <meoblast001> i set it with branch.Branch.hooks.install_named_hook ('post_change_branch_tip', Post_Change_Branch_Tip, 'Announce Commit')
[03:44] <lifeless> show me the definition of Post_Change_Branch_Tip
[03:44] <meoblast001> http://pastebin.com/d79e4cd50
[03:45] <lifeless> line 46 is your problem
[03:45] <lifeless> you are calling your hook; don't do that.
[03:45] <lifeless> once its installed bzr will call it at the right time.
[03:46] <meoblast001> oh >.<
[03:46] <meoblast001> how did i leave that there
[03:46] <meoblast001> i was doing some independent tests without Bazaar for a bit there, must have forgotten to remove that line
[03:46] <lifeless> if you put '  import pdb; pdb.set_trace()' at line 25, then when bzr calls it, you will be put into a debugger.
[03:46] <meoblast001> just to check that my backend could properly process the results
[03:47] <meoblast001> it doesn't actually list the vars
[03:47] <meoblast001> isn't that what vars() is supposed to do?
[03:48] <lifeless> no
[03:48] <lifeless> its a function
[03:48] <lifeless> so you need to print its output
[03:48] <lifeless> if you are in a read-evaluate-print-loop, results are printed automatically
[03:48] <meoblast001> ah, ok
[03:48] <lifeless> which is what pdb would put you in
[03:50] <meoblast001> print vars (result.branch.repository.get_revision (new_revno))
[03:50] <meoblast001> not printing
[03:50] <meoblast001> does vars return a string?
[03:50]  * meoblast001 googles
[03:53] <meoblast001> lifeless: this pdb, is it extremely useful?
[03:54] <lifeless> yes
[03:54] <lifeless> meoblast001: just put this in as your hook function
[03:54] <lifeless> def myhook(params):
[03:54] <lifeless>     import pdb;pdb.set_trace()
[03:55] <lifeless> and then install it as normal - bzrlib.branch.Branch.hooks.install_named_hook('....
[03:56] <meoblast001> still nothing
[03:56] <meoblast001> the only real issue i'm having is here
[03:56] <meoblast001> print vars (result.branch.repository.get_revision (new_revno))
[03:56] <meoblast001> nothing is being printed
[04:00] <meoblast001> i'm going to do a full test on this, see if it all runs well
[04:04] <lifeless> meoblast001: well, by nothing, what do you mean?
[04:04] <lifeless> if you do a pull or ap ush with the little hook I gave you, bzr should put you into a interactive prompt
[04:04] <lifeless> note that you need to do that locally, not on your server
[04:04] <lifeless> because on the server it can't show you the prompt :)
[04:04] <meoblast001> ok
[04:04] <meoblast001> well i'm going to do this one last test, then i'll try that if it does not work
[04:05] <meoblast001> lifeless: aparently new_revid doesn't exist
[04:06] <meoblast001> i'm assuming i need result.new_revid?
[04:06] <lifeless> yes
[04:07] <meoblast001> lifeless: all works except for one thing
[04:08] <meoblast001> i need a way to obtain the branch name
[04:08] <meoblast001> oh, and an integer of the latest revision number
[04:08] <meoblast001> i have a var dump though
[04:13] <lifeless> meoblast001: branch.nick may be what you want; and new_revno from the params object
[04:13] <meoblast001> lifeless: i guess there's always result.branch._last_revision_info_cache[0]?
[04:13] <meoblast001> ah, silly me
[04:13] <lifeless> no, _ prefixes mean 'private' by convention in bzr
[04:13] <meoblast001> new_revno is there
[04:13] <meoblast001> ah, ok
[04:14] <meoblast001> ok, let's fire up the server and see how well this works
[04:15] <meoblast001> oops, forgot to copy over the new version
[04:16] <meoblast001> lifeless: what's bother me is that it's not giving me any information on where the error is
[04:16] <meoblast001> i thought that was the advantage to using an interpreted language
[04:16] <meoblast001> bzr: ERROR: exceptions.TypeError: coercing to Unicode: need string or buffer, int found
[04:16] <meoblast001> that's all i get
[04:16] <lifeless> meoblast001: I have suggested that you test locally
[04:17] <meoblast001> yes, i'm doing that
[04:17] <lifeless> meoblast001: if you are testing on your server, you'll need to check the .bzr.log on the server
[04:17] <meoblast001> this seems to be getting called at every bzr commit and bzr uncommit
[04:17] <meoblast001> so i am getting output
[04:17] <lifeless> meoblast001: if you're testing locally, set BZR_PDB=1
[04:17] <lifeless> e.g.
[04:17] <lifeless> BZR_PDB=1 bzr uncommit
[04:17] <meoblast001> as a shell variable?
[04:18] <lifeless> yes
[04:18] <meoblast001> get the exact same output
[04:18] <meoblast001> is result.new_revno an integer?
[04:18] <lifeless> it should put you into pdb
[04:18] <meoblast001> because i treat it as one
[04:19] <meoblast001> it didn't
[04:19] <lifeless> why did you say 'forgot to copy over the new version' and 'time to fire up the server', if you are testing locally.
[04:20] <meoblast001> ah, that's because this is a networking plugin
[04:20] <meoblast001> the server is a plugin for my IRC bot
[04:20] <meoblast001> it runs in a thread, waiting for signals from version control systems giving it details about the commits made
[04:20] <lifeless> ok
[04:20] <lifeless> and the branch you are testing on is on your local disk
[04:21] <lifeless> and not a bound branch
[04:21] <lifeless> and you're testing by doing a commit in it ?
[04:21] <meoblast001> it's just a random branch i created with bzr init
[04:21] <meoblast001> and it's on my local system
[04:21] <lifeless> ok
[04:21] <meoblast001> i'm testing by doing a commit
[04:21] <lifeless> what bzr version?
[04:22] <lifeless> check ~/.bzr.log, it should have the full backtrace there regardless
[04:22] <meoblast001> Bazaar (bzr) 2.0.2
[04:23] <meoblast001> hm, i wonder if i typed something wrong, it's complaining about no get_revision function
[04:23] <meoblast001> bzr: ERROR: exceptions.AttributeError: 'BzrBranch7' object has no attribute 'get_revision'
[04:23] <meoblast001> and i'm correct ;) i did type something wrong
[04:25] <meoblast001> dang, it just keeps finding problems
[04:25] <meoblast001> bzr: ERROR: exceptions.AttributeError: 'BzrBranch7' object has no attribute 'respository'
[04:25] <lifeless> rep not resp
[04:25] <meoblast001> oh >.<
[04:26] <meoblast001> i've been all out of it today
[04:29] <meoblast001> lifeless: yay, it works now :)
 randproj: Revision Committed by Braden Walters <meoblast@aol.com>: Initial Commit
[04:29] <lifeless> great
[04:29] <meoblast001> now i just need to get the commit number off of it
[04:29] <meoblast001> lifeless: i'd have to bot come in here to show you guys, but i'd probably get kick/banned ;)
[04:32] <lifeless> I think for a commit or two it would be fine
[04:32] <lifeless> is vcannounce generic?
[04:32] <lifeless> like cia?
[04:32] <lifeless> if so you might want to publish your plugin for others to use
[04:34] <meoblast001> lifeless: my bot is a plugin-based bot
[04:34] <meoblast001> written in C
[04:34] <meoblast001> Nitrobot is the name of the bot, VCAnnounce is the name of the plugin i just wrote
[04:35] <meoblast001> and i will be publishing my plugin in the nitrobot-plugins package
[04:35] <meoblast001> i'll connect him now for one test
[04:36] <nitrobot> randproj: Revision 2 Committed by Braden Walters <meoblast@aol.com>: Added file "file"
[04:36] <meoblast001> lifeless: see :)
[04:36] <meoblast001> !quit thepassword
[04:36] <lifeless> grats
[04:37] <meoblast001> thanks
[04:37] <meoblast001> and also thanks for the great amount of help you provided on the Python side
[04:37] <lifeless> de nada
[04:38] <meoblast001> lifeless: once i'm done cleaning up the code (will probably do that tomorrow or later tonight), should i publish a link to where the plugin can be found somewhere?
[04:38] <meoblast001> as you were saying i might want to publish it
[04:38] <lifeless> yes, the bzr plugins wiki page :)
[04:38] <meoblast001> ok, the Bazaar plugin is no good though without the bot and the bot plugin, so i'm assuming a link would be most appropriate?
[04:42] <spiv> lifeless: yes, Command.add_cleanup is in 2.1
[04:42] <meoblast001> hopefully that script will be as useful to others as it will be to me
[04:42] <meoblast001> i hated having 2 bots sitting in my channel at the same time
[04:45] <lifeless> spiv: doh
[04:45] <lifeless> meoblast001: well you'll want a link to the bzr plugin, and a link to your bot
[04:46] <meoblast001> ok, i'll do that tomorrow :)
[04:46] <meoblast001> actually, i only have to do endianness conversions right now really, so i  could finish that up tonight
[04:54] <mwhudson> more up to date api docs at http://people.canonical.com/~mwh/bzrlibapi/ now btw
[04:55] <lifeless> mwhudson: can't use the old api?
[04:56] <mwhudson> lifeless: you mean old server?
[04:56] <lifeless> url
[04:57] <mwhudson> it's not very well maintained these days
[04:57] <lifeless> <- brain has melted
[04:57] <mwhudson> i'll set up a redirect
[04:57] <lifeless> mwhudson: can you delete them at least, so that people don't read only stuff
[04:58] <mwhudson> sure
[05:03] <spiv> lifeless: why doh?  Hmm, well I guess I ought to have listed some of that change in NEWS under API Changes (as well as Improvements, where it is mentioned)
[05:03] <lifeless> spiv: because that makes it harder to rethink the change to be better
[05:04] <spiv> lifeless: *nod*
[05:04] <spiv> lifeless: (I thought that might be what you meant, but wanted to be sure)
[05:04] <spiv> FWIW it landed on Jan 11.
[05:05] <spiv> So, relatively late in the cycle, but still 10 days before rc1.
[05:05] <spiv> And a full month before the final release.
[05:06] <spiv> Ideally that should have been ample time to notice any issues :/
[05:07] <meoblast001> now, time to do a test install on my server
[05:07] <meoblast001> where would i put a plugin if i want it to apply for every user?
[05:09] <lifeless> spiv: I don't think you did anything wrong.
[05:09] <mwhudson> lifeless: redirect in place
[05:10] <lifeless> spiv: its roughly the halting problem to always know in advance.
[05:10] <spiv> lifeless: sure
[05:10] <spiv> lifeless: I'm just wondering aloud if there's a deficiency in our process that we easily improve
[05:11] <spiv> lifeless: nothing is springing to my mind, but then, my mind isn't at work today either :)
[05:11] <lifeless> spiv: poolie and I spent some time today talking about a similar problem.
[05:11] <poolie> hullo
[05:11] <lifeless> I don't think tht the obvious options [more mandatory review time and similar] would help.
[05:11] <lifeless> sorry, woud be a net improvement
[05:11] <spiv> Ah well, I'm happy to have provided another data point then, as well as another feature ;)
[05:11] <spiv> *nod*
[05:12] <poolie> what is the 'it' here?
[05:12] <lifeless> poolie: Command.run not being safe to call anymore.
[05:12] <spiv> The best I can think of is "get more testing from plugin authors and plugin users", but even that's a bit vague.
[05:12] <spiv> (and easier said than done)
[05:12] <lifeless> poolie: which didn't stand out during review; it was obvious to the right eyeballs, but how do you get them on it in time?
[05:13] <spiv> I do think I made a mistake in not writing an API Changes entry for that change.
[05:13] <spiv> I'm not sure that would have brought it to the attention of the right eyeballs, but it might have.
[05:13] <lifeless> I think that if you had thought it was an API change you might have noticed it as being a problem, in fact
[05:14] <spiv> Right, there's also a degree of chicken-and-egg in that statement :)
[05:14] <meoblast001> is there a location for global Bazaar plugins?
[05:14] <spiv> meoblast001: the system-wide bzrlib/plugins dir, IIRC
[05:14] <spiv> meoblast001: (check the location of bzrlib by running 'bzr version')
[05:14] <meoblast001> ok, thanks
[05:23] <lifeless> spiv: perhaps one thing we could say is 'ask yourself, does this change the safety of calling what I changed, or does it stop calling something it once [promised] to call'
[05:23] <lifeless> spiv: as part of the regular 'think about it' part of review
[05:43] <lifeless> EOD; see you tomorrow.
[05:48] <thumper> night lifeless
[06:05] <poolie> spiv, lend me your thoughts on the retrospective
[06:06] <spiv> poolie: basically, +1
[06:08] <spiv> poolie: picking the focus features is the tricky bit
[06:09] <spiv> poolie: that's worked ok for us when we've had a really clear goal for a release, e.g. "2a must be robust and fast before we can declare 2.0"
[06:49] <poolie> spiv, was there anything else you particularly noticed as good or bad this cycle?
[06:50] <spiv> (sorry, was interrupted by baby)
[06:50] <spiv> The motivation for focus features seems harder when they are just "nice to have"
[06:53] <spiv> I think the cycle worked pretty well.  It still seems hard to get plugin authors to reliably notice problematic changes until after a release, though.
[06:53] <spiv> But I think even there we've probably done better than previously.
[07:09] <vila> hi all !
[07:13] <lifeless> spiv: I think the issue with plugins is that many plugin authors don't run trunk, and don't want to
[07:13]  * vila wonders why he's a channel operator....
[07:13] <lifeless> spiv: and the current api churn on trunk makes it even less attractive
[07:13] <spiv> *nod*
[07:13] <lifeless> vila: you have chanserv /nickserv setup to auto op you when it can
[07:13] <vila> lifeless: sure, but why *can* I ? :D
[07:13] <lifeless> spiv: I'd like us to totally reverse the deprecation policy to what we had before; that is a much nicer rid, and conducive to running trunk
[07:13] <lifeless> vila: because you're a core committer
[07:14] <lifeless> vila: please change your setup though, to not op you automatically; helps avoid channel trolls
[07:14] <spiv> lifeless: yeah, abentley at least seems to find the current policy worse
[07:14] <vila> lifeless: but you and spiv and poolie are too .... ha ok
[07:14] <lifeless> vila: yes, see<-
[07:15] <poolie> hello vila, welcome back
[07:15] <vila> hey poolie !
[07:15] <lifeless> spiv: I replied to the thread saying I too find it worse.
[07:15] <poolie> so
[07:15] <spiv> I definitely thinking we need to find a way to encourage plugin authors (and keen plugin users) to track bzr trunk.
[07:16] <poolie> i get discouraged from running plugin tests
[07:16] <poolie> there seem to be too many broken windows
[07:16] <poolie> i don't think the previous policy for apis was good enough
[07:16] <spiv> But I'm not a plugin author, so I'm happy to let those who are make suggestions about what will help.
[07:16] <poolie> there were some cases where people spent half an hour changing something and days working out how to deprecate it
[07:17] <poolie> this is not a good tradeoff
[07:17] <lifeless> poolie: I agree that that is a bad ratio; I've not experienced it myself
[07:17] <poolie> i think this was a patch of vila i had in mind
[07:17] <poolie> yes
[07:18] <spiv> I think in general a plugin cannot rely on something like 'require_api(x.y.z.b3)' until x.y.z.b3 has been released, but this means that trunk is almost always a version that a plugin can't safely rely on.
[07:19] <spiv> But at the same time, we want plugins to be tested with trunk.
[07:19] <lifeless> spiv: that aspect of the current system doesn't bother me so much
[07:19] <lifeless> spiv: its the 'whaaay, lets not deprecate anymore' that bothers me
[07:19] <vila> poolie: the one about SubUnitFeature ?
[07:19] <poolie> i forget
[07:20] <vila> poolie: I didn't spend *days*, merely hours and mainly because the parameter order tricked both of us and led to an infinite recursion IIRC
[07:20] <vila> but I miss the context so...
[07:21]  * vila triages mail
[07:21] <poolie> so
[07:21] <poolie> i think if it's easy to keep something supported we should
[07:21] <poolie> i don't think we should take for granted that doing any large amount of work in bzr is worthwhile
[07:24] <lifeless> poolie: we didn't take that for granted before
[07:24] <lifeless> poolie: I landed lots of patches of the kind 'too hard to deprecate, not doing so'
[07:24] <poolie> ok
[07:25] <lifeless> poolie: we don't seem to be trying at all at the moment
[07:25] <lifeless> and I have two problems with this, as a user/advocate
[07:25] <lifeless> firstly stable release to stable releae should do deprecations where we can
[07:25] <lifeless> we've made these release jumps 6 months of rolled up work
[07:25] <lifeless> so they are much bigger than they were before (in potential delta)
[07:26] <lifeless> that, to me makes the benefit of a deprecation much greater.
[07:26] <lifeless> and the risk of confusion to someone upgrading a plugin larger
[07:27] <lifeless> secondly, deprecations add value to users - they have saved me lots of log grepping in the past, when someone else changed something.
[07:28] <lifeless> and I think this is an experience other authors have had
[07:28] <poolie> i can see how that helps authors but not users
[07:29] <lifeless> when a plugin stops working with no visible indication, the user has to debug this.
[07:29] <lifeless> a deprecation does two things; it keeps the plugin working, and if it fails at doing that, then it at least tells them
[07:37] <poolie> hm
[07:37] <poolie> but it's probably not going to stop with no visible indication
[07:38] <lifeless> compare a Warning + AttributeError vs just an AttributeError
[07:38] <lifeless> anyhow, I said this on the list
[07:38] <lifeless> where everyone can participate  :)
[07:41] <poolie> i'd be ok to reiterate that people should deprecate unless it is too hard
[07:41] <poolie> it seems like there might be some better option though
[07:41] <poolie> or something complementary
[07:45] <Speedy2> www.search2.net
[07:52] <poolie> spam
[07:58] <igc> hi all
[08:04] <lifeless> poolie: I'm disabling autoops
[08:13] <lifeless> igc: can you do '/msg NickServ SET NOOP ON'
[08:13] <lifeless> igc: and then leave and rejoin #bzr? testing fallout from the expanded access lists we did last week
[08:14] <igc> lifeless: done
[08:14] <lifeless> ok great
[08:14] <lifeless> if you need to become operator do this:
[08:14] <lifeless>  /msg chanserv op #bzr
[08:14] <lifeless> an to stop being an operator
[08:14] <lifeless>  /deop igc
[08:17] <lifeless> igc: actually, I think I've found the root cause, youcan undo that if yu want
[08:18] <lifeless> thee instructions to become/drop root still spply
[09:02] <radoe> Are 2 minutes to create a new local branch from an existing branch of bzr-2.1 sources normal?
[09:03] <poolie> radoe, do you have a shared repository locally?
[09:05] <radoe> poolie: no, this test was without a shared repo, so I think it has to copy over the whole history, right?
[09:05] <poolie> yes
[09:05] <poolie> still seems a bit slow
[09:08] <radoe> poolie: yes, I had the same feeling about beeing a tad slow in this local branching case.
[09:11] <radoe> For more than a minute it stays at "Fetching revisions:Get stream source", having one CPU core running at 100%
[09:18] <poolie> radoe, could it be the repositories are in different formats or something?
[09:21] <radoe> poolie: both are "Standalone tree (format: 2a)". Further branching from the just-branched branch takes about the same time.
[09:33] <Coke> Hi! I have a 1.5 version on server and 2.0.4 on my client, it takes like 2 minutes to transfer 62k of data, it does max 1k/s and most of the time even less. This is on a LAN!!! Needless to say, this is getting frustrating, is there a quick fix to mend this problem?
[09:45] <poolie> Coke, so the obvious first step would be to upgrade the server to 2.1 or 2.0
[09:54] <Coke> actually, there's no bzr server
[09:54] <Coke> I use sftp
[09:54] <Coke> My bad.
[09:55] <poolie> ok
[09:55] <Coke> So there's just the 2.0.4 client
[09:55] <poolie> that's still kind of surprising
[09:55] <poolie> what does bzr info show in that branch?
[09:55] <Coke> location, checkout of branch and format pack-0.92
[10:00] <bialix> hi poolie
[10:04] <mathrick> Coke: and you're sure you can get normal sftp transfers at better speeds?
[10:16] <poolie> hi bialix
[10:17] <bialix> poolie: I've made 1.0.0rc2 release of bzr-explorer
[10:17] <poolie> bialix, i saw, that's great
[10:17] <poolie> thanks
[10:18] <bialix> that's minimum I can do for Ian
[10:19] <bialix> I don't know is anybody working on including bzr-explorer to Lucid?
[10:20] <jelmer> bialix: AndrewSB is I think
[10:21] <bialix> ok
[10:21] <bialix> hi jelmer
[10:21] <bialix> have a minute? you've asked about icon
[10:21] <jelmer> bialix: He's the packager of bzr-explorer for Debian and Ubuntu, I'm not sure if he's specifically working on 1.0.0.rc2 though
[10:22] <bialix> jelmer: that's ok
[10:28] <poolie> he'll probably do it if you poke him
[10:28] <poolie> i think ian will be away a bit this week
[10:30] <bialix> poolie: any specific plans for 2.2? does nested trees have a chance?
[10:30] <poolie> bialix, i was just talking to vila about that
[10:30] <poolie> i think we should pick a thing
[10:30] <poolie> Coke, did you work it out?
[10:30]  * bialix waves at vila
[10:31] <poolie> i was saying to vila maybe we should either all get onto merge/conflict, or he should leave it
[10:31] <poolie> it seems a bit slow and he's having trouble getting good reviews
[10:33] <poolie> vila, if you're piloting this week you're going to be busy
[10:34] <vila> http://wiki.bazaar.canonical.com/PatchPilot says jam is the patch pilot this week, I plan to be *next* week
[10:37]  * bialix nods
[10:38] <poolie> oops
[10:38] <poolie> sorry
[10:38] <poolie> must be sleepy
[10:41] <vila> no worries, but go get some sleep :D
[10:42]  * fullermd waves at vila.
[10:43]  * vila waves back to fullermd and bialix enthusiastically
[10:43] <bialix> hi fullermd
[10:44] <fullermd> ... some day, people in my own TZ will get their acts together and be around at the same time as I am...
[10:44] <bialix> :-)
[10:45] <vila> fullermd: why don't you just move where the sun shines during your work hours :) It really helps you know...
[10:45] <fullermd> Sun...   shines?!  But what about my sensitive skin?
[10:46] <poolie> sure shines here, 37C today
[10:46] <vila> Oh, no need for direct exposure, but the light....
[10:46]  * fullermd shudders.
[10:46] <fullermd> It burns us, preciouss!
[10:46] <poolie> bialix, so i would like us to agree on a specific thing for 2.2, but i don't want a thread where everyone names their favourite bug
[10:46]  * vila throws some snow balls at poolie
[10:47] <bialix> poolie: yep
[10:47] <poolie> i recognize there's useful data in it but it just seems likely to cause disappointment if we don't go for whatever is most loudly demanded
[10:47] <poolie> ooh that's nice
[10:48] <bialix> poolie: I'm a bit tired with my scmproj and I have to rewrite big part of it, so I'm asking
[10:48] <bialix> nested trees deferred for ~ 1 year
[10:48] <poolie> so we could try to merge nested trees
[10:48] <poolie> i wonder if it's too intrusive of a way to put it in
[10:48] <poolie> in some ways we should just clear the decks and do it
[10:48] <poolie> i wonder if we can do anything in the core to allow plugins to do this really well
[10:49] <poolie> oh, there are some user questions open on lp if anyone wants to answer them
[10:50] <vila> Ideally we should ad hooks or whatever is needed in core to *allow* a plugin (or several) to implement nested trees
[10:50] <Coke> poolie: no luck
[10:50] <poolie> right, that would be nicer
[10:50] <poolie> ok i'm going to call it a night
[10:50] <poolie> have a good day europe
[10:50] <Coke> still as slow
[10:50] <vila> Doing it via plugins lower the constraints about compatibility while allowing experiments
[10:50] <poolie> right
[10:50] <Coke> nn
[10:50] <vila> poolie: have a nice night
[10:50] <poolie> also, maybe has a cleaner architecture
[10:51] <bialix> today the limit of either scmproj or bzr-externals is lack of snapshots
[10:51] <fullermd> A problem with trials like that is that figuring out just what sorta hooks are needed is the lions share of _doing_ it   :|
[10:51] <bialix> i.e. they don't record revision-ids of entire tree
[10:51] <vila> fullermd: that could be driven by the plugin authors
[10:52] <vila> bialix: revids of nested trees ?
[10:53] <bialix> vila: I'm not sure hooks will help there
[10:53] <fullermd> Yeah.  Has to be, really.  But it risks turning into a long serialized HCF sorta process.
[10:53] <jelmer> vila: they just point at the tip of a branch, not a specific revision
[10:53] <bialix> there is need to run some operations recursively in all trees'
[10:53] <jelmer> whereas nested trees in their current form only support specific revisions, not tip
[10:53] <bialix> fullermd: HCF?
[10:53] <bialix> vila: yes
[10:53] <bialix> jelmer: ?
[10:54] <jelmer> bialix: nested trees as aaron has implemented them only support snapshots
[10:54] <vila> jelmer: ':tip' as a special revid like ':null' ?
[10:54] <jelmer> (If I understand the terminology right)
[10:54] <bialix> jelmer: that's good
[10:55] <vila> urgh, non-sense
[10:55] <bialix> jelmer: one can easily implement: for $each-subtree do bzr pull
[10:55] <fullermd> bialix: "Halt and Catch Fire".  No real relevance, I was just being whimsical.
[10:55] <jelmer> vila: well, the tip of the branch, no matter what revspec you use to describe it :-)
[10:55] <jelmer> vila: tip: would be one way of supporting non-snapshots with the current bzr nested tree storage format
[10:56] <jelmer> bialix: pulling a subtree is a change to the parent tree
[10:56] <vila> jelmer: hmm, I said non-sense because if you want to refer to a particular revision for a tree you don't want the nested tree to change
[10:57] <vila> so, yes, you want some mechanism in place to update or not when you pull, merge, etc
[10:59] <bialix> jelmer: believe me: I have much more problems because of lack of snapshots
[10:59] <bialix> jelmer: I don't understand
[10:59] <bialix> what it means: pulling a subtree is a change to the parent tree?
[11:00] <bialix> if I change subtree I should commit this changes to parent tree, yes, that's right
[11:01] <jelmer> I think I should probably get out of this discussion because I'm only familiar with the nested tree terminology, not with the scmproj terminology.
[11:05] <bialix> I'm not very familiar with nested trees terminology, bad
[11:06] <bialix> how nested trees called the entire saved state of all subtrees?
[11:06] <bialix> in hg they save revids to .hgsubstate
[11:06] <lifeless> bialix: it doesn't have that concept
[11:06] <lifeless> its just part of the inventory
[11:06] <lifeless> and only refers to the immediate children.
[11:07] <lifeless> its recursive, so deeper children are referred to by their containing tree.
[11:07] <bialix> so there should be a way to update inventory for desired revision
[11:08] <lifeless> yes, there is an api call
[11:08] <bialix> IIUC it's similar to textual changes?
[11:09] <lifeless> yes
[11:09] <bialix> but the subtrees all live in separate branches, right? so I should be able to update just specific subtree
[11:10] <bialix> if there is no built-in way, then we can call API in the plugin
[11:12] <lifeless> bialix: I don't understand the question
[11:14] <bialix> lifeless: there is nested by value and by reference
[11:14] <bialix> I'm talking about by reference case
[11:15] <lifeless> yes
[11:15] <lifeless> I guet that
[11:15] <bialix> referenced subtree lives outside main tree IIUC
[11:15] <lifeless> I don't know what you mean by 'update just specific substree'
[11:15] <lifeless> do you mean 'update the referenced revision'
[11:15] <bialix> so if it external than we should be able to pull/push it
[11:15] <lifeless> or 'do an update on the local tree for the subtree'
[11:16] <bialix> I mean cd subtree; bzr pull
[11:16] <lifeless> sure, just do it
[11:16] <lifeless> nothing else needed
[11:16] <lifeless> the next commit in the parent tree will notice and record it
[11:20] <bialix> brilliant
[15:50] <naoki_> Hi, all.
[15:51] <naoki_> https://code.launchpad.net/~songofacandy/bzr/fix-524560/+merge/19737
[15:51] <naoki_> I found 'N' mode on msdn.
[15:51] <naoki_> http://msdn.microsoft.com/en-us/library/yeby3zcb.aspx
[15:52] <naoki_> This mode means open file with os.O_NOINHERIT.
[15:53] <naoki_> And I test the mode on Linux. 'N' is just ignored.
[15:53] <naoki_> Currently, my bugfix branch make osutils.open and use it instead of builtin open.
[15:54] <naoki_> osutils.open adds 'N' on win32, osutils.open is builtin open on Linux.
[15:55] <naoki_> Can I use 'N' on Linux?
[15:55] <naoki_> If I can, I'll remove osutils.open and add 'N' for open() in transport.local
[16:04] <Mez> "secret service operation failed" ...
[16:04] <Mez> doesn't sound good.
[16:04] <Mez> I don't like secrets in my system
[16:10] <vila> Mez: And how is that related to bzr ?
[16:15] <jelmer> naoki_: that sounds reasonable
[16:19] <naoki_> manpage for fopen describe modes.
[16:20] <naoki_> posix modes: r, r+, w, w+, a, a+
[16:20] <naoki_> glibc extension (trailing chars): c, e, m, x
[16:21] <naoki_> I don't know other libc's fopen extension.
[16:23] <naoki_> Using 'N' only on win32 is safe because glibc and other libc can use 'N' for some meaning...
[16:25] <naoki_> BTW, what name is suitable for osutils.open? open_noinherit? open_safe?
[18:38] <chromakode> hey folks, can you give me any suggestions on how to extract all code lines touched by a specific author?
[18:55] <jelmer> chromakode: from Python code or from the command line?
[18:55] <chromakode> either way is fine
[18:56] <jelmer> chromakode: from the command-line the easiest thing to do is probably to loop over all files in the working tree, run "bzr annotate" on them and grep
[18:56] <chromakode> that's a good idea! though it won't include past code
[18:56] <chromakode> I guess you could do it for each revno
[18:57] <Tak> could grep the log for the author, then annotate from there
[18:58] <jelmer> chromakode: from python it should be possible to find all changed lines by using a combination of the log and the annotate code
[19:00] <chromakode> thank you, I can work off that :)
[19:00] <chromakode> if I end up writing a script to do this, I'll post it here.
[19:00] <rubbs> I'd like that ^
[19:43] <_TiN_> Hi, I'm trying server bzr through apache with mod_wsgi, and the "app" return nothing. This is my wsgi script http://dpaste.com/163148/ and the output is a clean list, just []
[19:43] <_TiN_> :-/
[21:04] <poolie> hi jam, shall we talk?
[21:13] <shodan45> what options do I need for bzr to make a .patch file that works with patch?
[21:16] <marienz> none?
[21:17] <marienz> that is: I'm pretty sure I've fed "bzr di" output to patch
[21:17] <marienz> shodan45: ^^^
[21:17] <shodan45> marienz, ok, then what options to patch do I need? none? because it sure doesn't work for me :/
[21:18] <lifeless> shodan45: when you apply it, pass -p0 to patch
[21:18] <lifeless> or is it p1, I think its p0
[21:19] <marienz> shodan45: I think it's -p0 but it might be -p1. I usually need to try both with --dry-run.
[21:19] <marienz> actually it's probably -p1
[21:19] <shodan45> ok, I thought for sure I tried both -p0 and -p1, but -p0 worked
[21:19] <shodan45> thanks :)
[22:11] <_TiN_> Howto disable the comprobation SSL certificates?
[22:11] <_TiN_> bzr push bzr+https://myurl
[22:12] <_TiN_> bzr: ERROR: Connection error: curl connection error (server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none)
[22:14] <_TiN_> /s/comprobation/check
[22:16] <mwhudson> _TiN_: using a https+urllib:// url will work i think
[22:33] <_TiN_> mwhudson: this just work on cloning, when i try push doesn't work because the protocol is bzr+http[s]
[22:34] <bob2> heh
[22:34] <bob2> can you append +urllib to that?
[22:35] <_TiN_> bob2: unsupported protocol
[22:35] <_TiN_> bzr+https+urllib or urllib+bzr+https or bzr+urllib+https
[22:37] <mwhudson> bzr+ shouldn't be necessary
[22:43] <_TiN_> mwhudson: the push doesn't work with http[s]+urllib
[22:43] <_TiN_> mwhudson: in this link say http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/http_smart_server.html?highlight=mod_python#pushing-over-bzr-http
[23:33] <spiv> _TiN_: that doc is out-of-date, or at least misleading.  You can omit the 'bzr+' prefix on http URLs; bzr will automatically probe for a smart server and use it anyway.
[23:34] <spiv> _TiN_: you might be encountering some other problem, of course :(
[23:36] <_TiN_> spiv: noup, whitout bzr+ prefix doesn't work, but uninstall pycurl it's work :-)
[23:36] <_TiN_> thanks verterok ;-)
[23:37] <spiv> _TiN_: and https+urllib didn't work?
[23:37] <spiv> Odd.
[23:37] <verterok> _TiN_: you'r welcome :)
[23:37] <spiv> _TiN_: anyway, please file a bug :)
[23:37] <spiv> _TiN_: we want this stuff to Just Work
[23:38] <verterok> spiv: heya!
[23:38] <verterok> spiv: I can't uninstall pycurl so I'm stuck with this bug ;)
[23:39] <spiv> verterok: maybe you should file it then? :)
[23:39] <spiv> (Or is it already filed?)
[23:39] <verterok> spiv: I can't uninstall pycurl so I'm stuck with this bug ;)
[23:39] <verterok> spiv: I keep getting: bzr: ERROR: Unsupported protocol for url "urllib+https://trac.usla.org.ar/bzr/prueba_bzr"
[23:40] <verterok> spiv: and with reverse order, I get the user/pass prompt but: bzr: ERROR: Not a branch: "https+urllib://trac.usla.org.ar/bzr/prueba_bzr/".
[23:40] <verterok> spiv: I think it's https://bugs.edge.launchpad.net/bzr/+bug/82086
[23:40] <spiv> verterok: right, https+urllib is the correct prefix
[23:40] <spiv> verterok: but the https+urllib variant should work
[23:40] <verterok> spiv: so, it might be a server config issue?
[23:41] <spiv> Possibly!
[23:41] <verterok> _TiN_: ^ :)
[23:41] <spiv> verterok: add -Dhpss to the command line, and maybe -Dhttp too, and pastebin the ~/.bzr.log (after sanitising it for passwords etc), or attach it to a bug
[23:42] <verterok> spiv: ok
[23:44] <spiv> verterok: also, perhaps try installing lp:bzr-ping, and try 'bzr ping URL'
[23:44] <spiv> It fails for me, but I don't know the username and password, so that's unsurprising :)
[23:45] <verterok> spiv: pastebin: http://pastebin.ubuntu.com/381915/
[23:45]  * verterok branching bzr-ping
[23:46] <_TiN_> verterok: this through varnish http, and https pound+varnish
[23:47] <spiv> So, it appears to be talking to the smart server ok via HTTP
[23:47] <spiv> But then it tries to read /bzr/prueba_bzr/.bzr/branch-format
[23:47] <spiv> via regular HTTP
[23:47] <spiv> And that gets a 404
[23:47] <spiv> So, a server config issue, I think, although bzr should give clearer errors in this case.
[23:48] <spiv> (Although perhaps bzr could try falling back to trying to read only via the smart server)
[23:51] <_TiN_> may be with AliasMatch directive
[23:52] <verterok> spiv: oh, nice. thanks for looking to the logs :)
[23:55] <spiv> verterok: cool.  So please file a bug and attach that, because I'm pretty sure that bzr can do better here.  (and because I'm not really here today)
[23:56] <verterok> spiv: oh, ok.
[23:56] <verterok> spiv: will do it