| mkanat | lifeless: A modification to "bzr patch" would probably be the place, yeah? | 00:01 |
|---|---|---|
| lifeless | mkanat: yes, that might make sense. or import-patch, a new command. | 00:02 |
| 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:03 |
| bob2 | meoblast001: struct module isn't that bad | 00:20 |
| lifeless | mornink poolie | 00:36 |
| poolie | hello there | 00:36 |
| 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:37 |
| 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:38 |
| mkanat | lifeless: If no revno was specified. | 00:39 |
| meoblast001 | ah, ok | 00:39 |
| lifeless | pydoc struct | 00:39 |
| lifeless | hmm, functions there have bad docs; you'll want the python online docs. | 00:45 |
| lifeless | mbarnett: are you around | 00:46 |
| jml | the pypy people are interested in getting benchmarks from various python projects | 00:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| lifeless | changing bzrlibs Makefile | 00:50 |
| poolie | :/ | 00:50 |
| 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:51 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| poolie | i think there's pretty clearly more activity from both staff and nonstaff developers during the week | 00:57 |
| poolie | anyhow | 00:59 |
| poolie | if that works it'll be good | 00:59 |
| poolie | s/if/when :) | 00:59 |
| 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:00 |
| lifeless | we do have a 'use judgment' angle; the flipside to that is that people will | 01:01 |
| 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:02 |
| 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:04 |
| 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:05 |
| 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:06 |
| lifeless | something about this leaves me unsettled. I need to mull on it I think. | 01:07 |
| mkanat | mwhudson: Any new crashes? | 01:21 |
| 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:25 |
| 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:26 |
| mwhudson | mkanat: no | 01:30 |
| mkanat | mwhudson: Okay. | 01:31 |
| twb | v=$(bzr tags | tail -1); v=${v%% *}+$(($(bzr revno) - ${v##* })) | 01:34 |
| 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:36 |
| twb | You have fractional revnos? | 01:37 |
| 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:38 |
| 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:40 |
| twb | It's lp:dosage, fwiw | 01:41 |
| fullermd | Across the internet easily qualifies as "very far away" :) | 01:42 |
| 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:44 |
| fullermd | Well, it's probably not really designed for its destination to exist already. | 01:45 |
| === Adys_ is now known as Adys | ||
| === Adys is now known as 5EXAAEJ3X | ||
| === khmarbaise_ is now known as khmarbaise | ||
| meoblast001 | lifeless: in the doc for bzrlib.branch.ChangeBranchTipParams, i can't find anything about commit author | 02:25 |
| 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:30 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:36 |
| 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:37 |
| 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:48 |
| 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:49 |
| meoblast001 | lifeless: i can't find repository or get_revision | 02:50 |
| meoblast001 | oh yay, i managed to crash pydoc | 02:52 |
| === wgrant_ is now known as wgrant | ||
| meoblast001 | lifeless: is there an online documentation for this? | 03:31 |
| meoblast001 | it would probably be easier for me | 03:31 |
| 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:32 |
| 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:33 |
| meoblast001 | i can't understand if i'm supposed to be using branch.Branch, or branch.repository, or result.branch | 03:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| meoblast001 | silly me, // does not comment Python code >.< | 03:42 |
| * meoblast001 needs to use # | 03:42 | |
| 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:43 |
| lifeless | show me the definition of Post_Change_Branch_Tip | 03:44 |
| meoblast001 | http://pastebin.com/d79e4cd50 | 03:44 |
| 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:45 |
| 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:46 |
| meoblast001 | it doesn't actually list the vars | 03:47 |
| meoblast001 | isn't that what vars() is supposed to do? | 03:47 |
| 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:48 |
| 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:50 | |
| meoblast001 | lifeless: this pdb, is it extremely useful? | 03:53 |
| 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:54 |
| lifeless | and then install it as normal - bzrlib.branch.Branch.hooks.install_named_hook('.... | 03:55 |
| 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 | 03:56 |
| meoblast001 | i'm going to do a full test on this, see if it all runs well | 04:00 |
| 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:04 |
| meoblast001 | lifeless: aparently new_revid doesn't exist | 04:05 |
| meoblast001 | i'm assuming i need result.new_revid? | 04:06 |
| lifeless | yes | 04:06 |
| meoblast001 | lifeless: all works except for one thing | 04:07 |
| 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:08 |
| 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:13 |
| meoblast001 | ok, let's fire up the server and see how well this works | 04:14 |
| meoblast001 | oops, forgot to copy over the new version | 04:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| lifeless | check ~/.bzr.log, it should have the full backtrace there regardless | 04:22 |
| meoblast001 | Bazaar (bzr) 2.0.2 | 04:22 |
| 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:23 |
| 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:25 |
| meoblast001 | i've been all out of it today | 04:26 |
| meoblast001 | lifeless: yay, it works now :) | 04:29 |
| meoblast001 | <nitrobot> 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:29 |
| 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:32 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:42 |
| lifeless | spiv: doh | 04:45 |
| lifeless | meoblast001: well you'll want a link to the bzr plugin, and a link to your bot | 04:45 |
| 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:46 |
| mwhudson | more up to date api docs at http://people.canonical.com/~mwh/bzrlibapi/ now btw | 04:54 |
| lifeless | mwhudson: can't use the old api? | 04:55 |
| mwhudson | lifeless: you mean old server? | 04:56 |
| lifeless | url | 04:56 |
| 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:57 |
| mwhudson | sure | 04:58 |
| 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:03 |
| 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:04 |
| 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:05 |
| spiv | Ideally that should have been ample time to notice any issues :/ | 05:06 |
| 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:07 |
| lifeless | spiv: I don't think you did anything wrong. | 05:09 |
| mwhudson | lifeless: redirect in place | 05:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:23 |
| lifeless | EOD; see you tomorrow. | 05:43 |
| thumper | night lifeless | 05:48 |
| poolie | spiv, lend me your thoughts on the retrospective | 06:05 |
| spiv | poolie: basically, +1 | 06:06 |
| spiv | poolie: picking the focus features is the tricky bit | 06:08 |
| 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:09 |
| poolie | spiv, was there anything else you particularly noticed as good or bad this cycle? | 06:49 |
| spiv | (sorry, was interrupted by baby) | 06:50 |
| spiv | The motivation for focus features seems harder when they are just "nice to have" | 06:50 |
| 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. | 06:53 |
| vila | hi all ! | 07:09 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| * 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:21 |
| 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:24 |
| 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:25 |
| 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:26 |
| lifeless | secondly, deprecations add value to users - they have saved me lots of log grepping in the past, when someone else changed something. | 07:27 |
| 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:28 |
| 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:29 |
| poolie | hm | 07:37 |
| poolie | but it's probably not going to stop with no visible indication | 07:37 |
| 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:38 |
| 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:41 |
| Speedy2 | www.search2.net | 07:45 |
| poolie | spam | 07:52 |
| igc | hi all | 07:58 |
| lifeless | poolie: I'm disabling autoops | 08:04 |
| 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:13 |
| 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:14 |
| lifeless | igc: actually, I think I've found the root cause, youcan undo that if yu want | 08:17 |
| lifeless | thee instructions to become/drop root still spply | 08:18 |
| === jamesh_ is now known as jamesh | ||
| radoe | Are 2 minutes to create a new local branch from an existing branch of bzr-2.1 sources normal? | 09:02 |
| poolie | radoe, do you have a shared repository locally? | 09:03 |
| 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:05 |
| radoe | poolie: yes, I had the same feeling about beeing a tad slow in this local branching case. | 09:08 |
| radoe | For more than a minute it stays at "Fetching revisions:Get stream source", having one CPU core running at 100% | 09:11 |
| poolie | radoe, could it be the repositories are in different formats or something? | 09:18 |
| radoe | poolie: both are "Standalone tree (format: 2a)". Further branching from the just-branched branch takes about the same time. | 09:21 |
| 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:33 |
| poolie | Coke, so the obvious first step would be to upgrade the server to 2.1 or 2.0 | 09:45 |
| Coke | actually, there's no bzr server | 09:54 |
| Coke | I use sftp | 09:54 |
| Coke | My bad. | 09:54 |
| 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 | 09:55 |
| bialix | hi poolie | 10:00 |
| mathrick | Coke: and you're sure you can get normal sftp transfers at better speeds? | 10:04 |
| poolie | hi bialix | 10:16 |
| 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:17 |
| bialix | that's minimum I can do for Ian | 10:18 |
| bialix | I don't know is anybody working on including bzr-explorer to Lucid? | 10:19 |
| jelmer | bialix: AndrewSB is I think | 10:20 |
| 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:21 |
| bialix | jelmer: that's ok | 10:22 |
| poolie | he'll probably do it if you poke him | 10:28 |
| poolie | i think ian will be away a bit this week | 10:28 |
| 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:30 | |
| 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:31 |
| poolie | vila, if you're piloting this week you're going to be busy | 10:33 |
| vila | http://wiki.bazaar.canonical.com/PatchPilot says jam is the patch pilot this week, I plan to be *next* week | 10:34 |
| * bialix nods | 10:37 | |
| poolie | oops | 10:38 |
| poolie | sorry | 10:38 |
| poolie | must be sleepy | 10:38 |
| vila | no worries, but go get some sleep :D | 10:41 |
| * fullermd waves at vila. | 10:42 | |
| * vila waves back to fullermd and bialix enthusiastically | 10:43 | |
| bialix | hi fullermd | 10:43 |
| 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:44 |
| 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:45 |
| 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:46 | |
| 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:47 |
| 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:48 |
| poolie | oh, there are some user questions open on lp if anyone wants to answer them | 10:49 |
| 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:50 |
| 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:51 |
| vila | bialix: revids of nested trees ? | 10:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| vila | so, yes, you want some mechanism in place to update or not when you pull, merge, etc | 10:57 |
| 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? | 10:59 |
| bialix | if I change subtree I should commit this changes to parent tree, yes, that's right | 11:00 |
| 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:01 |
| bialix | I'm not very familiar with nested trees terminology, bad | 11:05 |
| 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:06 |
| 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:07 |
| lifeless | yes, there is an api call | 11:08 |
| bialix | IIUC it's similar to textual changes? | 11:08 |
| 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:09 |
| bialix | if there is no built-in way, then we can call API in the plugin | 11:10 |
| lifeless | bialix: I don't understand the question | 11:12 |
| bialix | lifeless: there is nested by value and by reference | 11:14 |
| bialix | I'm talking about by reference case | 11:14 |
| 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:15 |
| 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:16 |
| bialix | brilliant | 11:20 |
| === mrevell is now known as mrevell-lunch | ||
| === mrevell-lunch is now known as mrevell | ||
| === pickscrape_ is now known as pickscrape | ||
| naoki_ | Hi, all. | 15:50 |
| 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:51 |
| naoki_ | This mode means open file with os.O_NOINHERIT. | 15:52 |
| 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:53 |
| naoki_ | osutils.open adds 'N' on win32, osutils.open is builtin open on Linux. | 15:54 |
| 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 | 15:55 |
| Mez | "secret service operation failed" ... | 16:04 |
| Mez | doesn't sound good. | 16:04 |
| Mez | I don't like secrets in my system | 16:04 |
| vila | Mez: And how is that related to bzr ? | 16:10 |
| jelmer | naoki_: that sounds reasonable | 16:15 |
| naoki_ | manpage for fopen describe modes. | 16:19 |
| naoki_ | posix modes: r, r+, w, w+, a, a+ | 16:20 |
| naoki_ | glibc extension (trailing chars): c, e, m, x | 16:20 |
| naoki_ | I don't know other libc's fopen extension. | 16:21 |
| naoki_ | Using 'N' only on win32 is safe because glibc and other libc can use 'N' for some meaning... | 16:23 |
| naoki_ | BTW, what name is suitable for osutils.open? open_noinherit? open_safe? | 16:25 |
| === mrevell is now known as mrevell-dinner | ||
| chromakode | hey folks, can you give me any suggestions on how to extract all code lines touched by a specific author? | 18:38 |
| jelmer | chromakode: from Python code or from the command line? | 18:55 |
| chromakode | either way is fine | 18:55 |
| 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:56 |
| Tak | could grep the log for the author, then annotate from there | 18:57 |
| jelmer | chromakode: from python it should be possible to find all changed lines by using a combination of the log and the annotate code | 18:58 |
| 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:00 |
| _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_ | :-/ | 19:43 |
| poolie | hi jam, shall we talk? | 21:04 |
| === 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! | ||
| shodan45 | what options do I need for bzr to make a .patch file that works with patch? | 21:13 |
| marienz | none? | 21:16 |
| 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:17 |
| lifeless | shodan45: when you apply it, pass -p0 to patch | 21:18 |
| lifeless | or is it p1, I think its p0 | 21:18 |
| 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 :) | 21:19 |
| _TiN_ | Howto disable the comprobation SSL certificates? | 22:11 |
| _TiN_ | bzr push bzr+https://myurl | 22:11 |
| _TiN_ | bzr: ERROR: Connection error: curl connection error (server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none) | 22:12 |
| _TiN_ | /s/comprobation/check | 22:14 |
| mwhudson | _TiN_: using a https+urllib:// url will work i think | 22:16 |
| _TiN_ | mwhudson: this just work on cloning, when i try push doesn't work because the protocol is bzr+http[s] | 22:33 |
| bob2 | heh | 22:34 |
| bob2 | can you append +urllib to that? | 22:34 |
| _TiN_ | bob2: unsupported protocol | 22:35 |
| _TiN_ | bzr+https+urllib or urllib+bzr+https or bzr+urllib+https | 22:35 |
| mwhudson | bzr+ shouldn't be necessary | 22:37 |
| _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 | 22:43 |
| 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:33 |
| spiv | _TiN_: you might be encountering some other problem, of course :( | 23:34 |
| _TiN_ | spiv: noup, whitout bzr+ prefix doesn't work, but uninstall pycurl it's work :-) | 23:36 |
| _TiN_ | thanks verterok ;-) | 23:36 |
| 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:37 |
| verterok | spiv: heya! | 23:38 |
| verterok | spiv: I can't uninstall pycurl so I'm stuck with this bug ;) | 23:38 |
| 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:39 |
| 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 |
| ubottu | Launchpad bug 82086 in bzr "pycurl transport causes tracebacks if the server's SSL cert cannot be verified." [Medium,Triaged] | 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:40 |
| 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:41 |
| verterok | spiv: ok | 23:42 |
| 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:44 |
| verterok | spiv: pastebin: http://pastebin.ubuntu.com/381915/ | 23:45 |
| * verterok branching bzr-ping | 23:45 | |
| _TiN_ | verterok: this through varnish http, and https pound+varnish | 23:46 |
| 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:47 |
| spiv | (Although perhaps bzr could try falling back to trying to read only via the smart server) | 23:48 |
| _TiN_ | may be with AliasMatch directive | 23:51 |
| verterok | spiv: oh, nice. thanks for looking to the logs :) | 23:52 |
| 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:55 |
| verterok | spiv: oh, ok. | 23:56 |
| verterok | spiv: will do it | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!