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