[00:01] <lazypower> bolthole : well huzzah for random workingness :)
[00:04] <lazypower> bolthole: sorry about the quickstart papercut though :/
[08:41] <apuimedo> jamespage: https://code.launchpad.net/~celebdor/charms/trusty/nova-cloud-controller/liberty/+merge/283709
[08:42] <apuimedo> did you have a chance to look at the merge proposal?
[08:44] <apuimedo> jamespage: I take it that were waiting for after the release to merge them since the branch is probably frozen (don't know if you do that or you make a frozen separate branch)
[08:44] <jamespage> apuimedo, not yet
[08:44] <jamespage> apuimedo, your tomorrows train work :-)
[08:44] <jamespage> so long as things are looking and testing ok I'd hope to land later this week once we unfreeze
[08:45] <apuimedo> you are going to Brussels by train?
[08:45] <apuimedo> I finally decided for plane
[08:45] <jamespage> apuimedo, btw we have plans to move all charm development upstream under openstack - I'm assuming that you might be supportive of that move?
[08:45] <jamespage> apuimedo, eurostar is to easy :-)
[08:45] <apuimedo> jamespage: supportive is not enough. I'm enthusiastic about it
[08:45] <jamespage> apuimedo, planes are ok but I have to transfer Norwich -> Amsterdam -> Brussels
[08:46] <apuimedo> you'll probably have a downstream release branch though, right?
[08:46] <jamespage> apuimedo, I'm hoping to sprint on the last remaining technical blockers thurs/friday so can move forwards
[08:46] <jamespage> apuimedo, nope - all git/gerrit
[08:46] <apuimedo> jamespage: that makes me happy
[08:46] <jamespage> well have some sort of branch strategy for consolidated charm release points
[08:47] <jamespage> apuimedo, charm store is moving away from the bzr based injestion to a direct publish model so that helps...
[08:47] <apuimedo> although having a downstream internal canonical clone for hotfixes makes a lot of sense
[08:47] <jamespage> apuimedo, I'd rather do it all upstream
[08:47] <apuimedo> jamespage: so would I. I'm just speaking in practical terms
[08:47] <jamespage> apuimedo, we're just moving everything we do now in launchpad/bzr to gerrit/git
[08:48] <apuimedo> that is the best news I heard for a while jamespage
[09:34] <D4RKS1D3> Hi, goodmorning
[09:34] <D4RKS1D3> jamespage, to whom sal I connected the juju-info interface required by openvswitch-odl?,  p.s: Could you share with me a juju-status, it would be very appreciated to enable me to explore this information, thanks a lot in advanced.
[09:41] <jamespage> D4RKS1D3, just relate it to nova-compute and neutron-gateway
[09:44] <D4RKS1D3> Thanks jamespage
[11:57] <jamespage> gnuoy, beisner: not sure that neutron-openvswitch got a charm-helpers sync
[11:57]  * jamespage checks
[12:00] <jamespage> beisner, gnuoy: https://code.launchpad.net/~james-page/charms/trusty/neutron-openvswitch/16.01-resync/+merge/283933
[12:57] <marcoceppi> lazypower aisrael
[13:48] <lazypower> marcoceppi
[14:36] <beisner> jamespage, yeah i've been finding onesy-twosey sync misses unfortunately
[14:38] <lazypower> tvansteenburgh: o/ heyo - have you ever seen an issue like this bubble up when attempting ot test a bundle w/ bundletester? http://paste.ubuntu.com/14672009/
[14:38] <tvansteenburgh> lazypower: no
[14:40] <tvansteenburgh> lazypower: pondering...
[14:40] <lazypower> I got this stack trace from anton, a nexenta charmer
[14:40]  * lazypower is trying to reproduce
[14:41] <mbruzek> I have a partner getting an error bootstrapping, "ERROR failed to bootstrap environment: cannot start bootstrap instance: No default VPC for this user (VPCIdNotSpecified". I have never seen this before.  Has anyone in #juju seen this problem?
[14:41] <lazypower> mbruzek: i'm thinking thi sis an account permissions issue
[14:42] <lazypower> but i'm not 100% positive ont hat
[14:42] <mbruzek> lazypower: OK I will ask
[14:42] <lazypower> mbruzek: and i'm referring to the AWS API Credentials being provided to juju
[14:42] <mbruzek> yes I figured that.
[14:43] <lazypower> right on :) I haven't had my coffee this morning, and if this week is anything like last week, i'm already speaking jibberish
[14:43] <mbruzek> lazypower: I had not thought of that, so I thank you for responding.  I will send them an email
[14:43] <tvansteenburgh> it could also be that the aws user is old enough that it predates vpc, and actually doesn't have a default vpc defined - that happened to me once upon a time
[14:45] <mbruzek> thanks tvansteenburgh!  All good things to check.
[14:46] <tvansteenburgh> lazypower: are the nexenta charms in lp?
[14:46] <lazypower> tvansteenburgh they are, 1 sec and i can get you a link
[14:47] <lazypower> tvansteenburgh https://bugs.launchpad.net/charms/+bug/1515717
[14:47] <mup> Bug #1515717: Nexenta Edge Charms to deploy edge cluster <Juju Charms Collection:In Progress by nexenta-systems> <https://launchpad.net/bugs/1515717>
[14:47] <tvansteenburgh> lazypower: ta
[14:57] <lazypower> urulama: are we in the middle of a deploy?
[14:58] <lazypower> urulama: looks like our docs are 404'ing all the way down the url tree
[14:58] <urulama> lazypower: no, no deploy on production going on ...
[14:58] <urulama> lazypower: will look into it
[14:58] <lazypower> i take that back, /stable/ is whats 404'ing
[14:58] <lazypower> looks like /devel/ is still functional
[14:59] <lazypower> and i spoke too soon
[14:59] <urulama> :-/
[14:59] <urulama> weird behaviour!
[14:59]  * lazypower nods
[14:59] <lazypower> Want me to file a bug urulama?
[15:00] <urulama> i'll put a task directly, thanks
[15:00] <lazypower> np, thanks for taking a look
[15:02] <urulama> lazypower: i suspect that was an exact moment when docs got rebuilt ...
[15:02] <tvansteenburgh> lazypower: i couldn't repro using the charm from lp, but, the first thing i would try is to ask him to reinstall bundletester in a venv
[15:02] <lazypower> ok, i've got you cc'd on these emails. incoming update
[16:04] <marcoceppi> cory_fu: I've got a use case for helpers.any_states
[16:04] <marcoceppi> cory_fu: I'd like to add a @hook_any do you think that would work?
[16:05] <marcoceppi> cory_fu: this is what I'm doing currently: http://paste.ubuntu.com/14672561/
[16:11] <cory_fu> marcoceppi: Sorry, meeting.  @hook_any?
[16:11] <cory_fu> Do you mean @when_any?
[16:12] <marcoceppi> @when_any, yes
[16:17] <cory_fu> marcoceppi: Ok, sorry, meeting is done.
[16:18] <cory_fu> Ok, I'm fine with a @when_any in theory, but the issue is that, for states set by relations, you are in a position where a given relation instance might or might not be available, so how do you match up relation instances to handler args?
[16:18] <marcoceppi> cory_fu: are relations keynamed invoked? or just passed as args?
[16:19] <cory_fu> And, more importantly, if a state is not set, you have no way of knowing if it would have been a relation state, so no way to know if it *would* have an instance if it were set vs if it's a non-relation state in which case it would not have a value regardless
[16:20] <marcoceppi> maybe this isn't the best approach
[16:20] <cory_fu> marcoceppi: They are only passed  by position, because you can name the args whatever you want
[16:20] <cory_fu> In the handler
[16:20] <cory_fu> marcoceppi: Really, passing args into the handler is not ideal, because there's already confusion about which states should expect args and which shouldn't.
[16:22] <marcoceppi> cory_fu: yeah, I might need to rethink this a bit
[16:22] <cory_fu> It's definitely a problem, though.  I've run into cases where having @when_any would make the code quite a bit cleaner
[16:23] <cory_fu> marcoceppi: You can always work around it by having multiple handlers, each with their own explicit conditions
[16:23] <cory_fu> But that can make the list of handlers quite cluttered
[16:24] <cory_fu> marcoceppi: For your specific example, it looks like all of those states that you're checking with any_states are really just a way of detecting whether or not you're in an action.  Could you generalize that to a single "in-action" state?
[16:26] <marcoceppi> cory_fu: possibly, but it's only a subset of actions
[16:26] <cory_fu> marcoceppi: Also, if we had https://github.com/juju-solutions/charms.reactive/issues/11 then you could just handle that with an @action decorator with some sort of pattern or wildcard
[16:26] <marcoceppi> cory_fu: sure, but I'm still in a position that I have to mix @action and @when_not
[16:26] <cory_fu> True
[16:26] <marcoceppi> does any_states support wildcard?
[16:26] <cory_fu> Not currently, no
[16:27] <marcoceppi> cory_fu: interesting
[16:27] <cory_fu> marcoceppi: How are those states getting set?  Could the code that sets those states also set a common "action-requires-configured" state?
[16:28] <marcoceppi> cory_fu: :) https://github.com/juju-solutions/vpe-router/tree/master/actions
[16:28] <marcoceppi> cory_fu: so it's possible that we could set that state
[16:28] <marcoceppi> which might be easier
[16:30] <cory_fu> marcoceppi: You could also have the action code check for the vpe.configured state itself and handle the fail instead of doing it in the reactive handler
[16:30] <marcoceppi> cory_fu: yeah, I was trying to avoid too much logic in the action file, wanted to keep it pretty boilerplate
[16:30] <marcoceppi> but that is true
[16:31] <cory_fu> Fair enough
[16:31] <marcoceppi> this is part strawman to see how actions in reactive would work
[16:32] <cory_fu> I do think that @when_any would be worthwhile to figure out, and more generally figuring out a better way to address the ambiguity in what states correspond to what params to a handler
[16:33] <cory_fu> One thought was to always pass in a single "context" arg that has methods for accessing the available instances.  Of course, you can also always call charms.reactive.relations.RelationBase.from_state('state') and we could wrap that in a helper
[16:34] <marcoceppi> cory_fu: kind of like how frameworks send in a single request object?
[16:34] <cory_fu> I had rather liked Whit's charm context proposal before he left, but no one picked that up.
[16:35] <marcoceppi> cory_fu: you still can ;)
[16:35] <cory_fu> I know.  :p
[16:37] <cory_fu> Switching to a single context param would be a pretty significant change to the reactive API, though.  Definitely a 2.0 thing
[16:49] <tertiary> i am currently evaluating juju as a solution, but am unsure of something. we have a use case where our clients would need to install our maas+juju cluster, and ideally i would like this to be done with a simple .deb package. is this possible? would i be able to automate juju in a way that it could autodeploy the services with an installer?
[16:58] <tvansteenburgh> tertiary: i don't see why not. you can automate via the juju cli pretty easily
[16:59] <tertiary> ah theres a cli, thanks
[20:33] <tertiary> trying to install juju on Ubuntu 15.10 Desktop with juju-quickstart, getting the following error: "ERROR there was an issue examining the environment: failure setting config: cannot find address of network-bridge: "lxcbr0": route ip+net: no such network interface". It's strange, this does not happen on Ubuntu 15.10 Server...
[20:35] <lazypower> tertiary did you install the juju-local package? and are you using the 'local' provider?
[20:36] <tertiary> yesyes, just confired juju-local is installed. yes using "local" provider
[20:39] <lazypower> tertiary:  ifconfig lxcbr0  returns nothing?
[20:39] <tertiary> yeah: lxcbr0: error fetching interface information: Device not found
[20:40] <lazypower> one sec, let me boot up a vm and try something before i recommend it
[20:40] <tertiary> k
[20:40] <jrwren> tertiary: try `sudo service lxc-net restart`
[20:41] <jrwren> tertiary: it can't hurt and its easy enough. then see if `ifconfig lxcbr0` returns status instead of error.
[20:41] <tertiary> yeah same error
[20:42] <skay> a very small docs comment: https://jujucharms.com/docs/1.25/authors-hook-debug someone has remapped ctl-b to ctl-a and it's written in to the docs as though ctl-a is hte default
[20:42] <skay> speaking about the tmux session
[20:43] <skay> just noticed it today
[20:43] <lazypower> o/ skay  long time on see :)
[20:43] <skay> lazypower: hiya
[20:43] <lazypower> skay : looks like the same issue was ported over into the devel docs - https://jujucharms.com/docs/devel/developer-debugging#the-'debug-hooks'-command
[20:44] <lazypower> skay can you file a bug? http://github.com/juju/docs/issues/
[20:44] <lazypower> we'll circle back and add a footnote that the default key binding is ctrl-b
[20:44] <skay> lazypower: I myself also remap ctl-b to ctl-a due to muscle memory of screen
[20:44] <skay> change the code to match the docs, ha!
[20:45] <lazypower> :) Thats possible too
[20:45] <lazypower> skay - if you use dhx, you can customize all of that, even upload your own tmux config w/ things like powerline and the like.
[20:46] <tertiary> `service lxc-net status` yields: "dnsmasq: failed to create listening socket for <IP_ADDRESS>: Cannot assign requested address"
[20:46] <lazypower> ahh, this came up the other day
[20:47] <lazypower> dnsmasq is preventing the lxc bridge froms tarting
[20:47] <lazypower> you can stop dnsmasq, start lxc-net, then restart dnsmasq - or reboot.
[20:47] <bdx> mbruzek: http://bazaar.launchpad.net/~charmers/charms/trusty/postgresql/trunk/view/head:/hooks/service.py
[20:48] <bdx> mbruzek: in the configure_sources hook
[20:48] <mbruzek> bdx: What is up?
[20:48] <bdx> mbruzek: it looks to me as if the sources are only added if both conditions are met correct?
[20:49] <bdx> mbruzek: sudo sysctl -w kernel.shmmax=15032385536
[20:49] <bdx> ooops
[20:49] <bdx> my bad
[20:49] <bdx> mbruzek: if config['pgdg'] and config.changed('pgdg'):
[20:49] <tertiary> lazypower: service status looks good after reboot, working now. thank you much sir.
[20:50] <mbruzek> bdx: Yeah it looks OK to me, if pgdg exists and it has changed generate the debian install line.
[20:51] <bdx> mbruzek: all versions of postgres other than 9.3 fail to install the postgresql binary due to sources not being available
[20:52] <bdx> because for any other version other than whats default in the repos the key and source have to be added
[20:53] <bdx> mbruzek: what I'm getting at, is that config.changed('pgdg') shouldn't ever be true
[20:54] <mbruzek> bdx config.changed('pgdg') will be true on first run and if anyone sets something else.
[20:54] <mbruzek> bdx: If it has a value the first time, if it is none the first boolean check will fail
[20:55] <mbruzek> bdx: I often use this pattern when doing configuration values.   if config['key'
[20:56] <mbruzek> ] and config.changed('key'):
[20:57] <bdx> mbruzek: yes, but who wants to modify that config every time the `juju deploy postgresql` ?
[20:57] <lazypower> tertiary glad we got you unblocked :)
[20:58] <bdx> mbruzek: it should be a prerequisite to have to change that param to have postgresql install other versions on install hook
[20:58] <bdx> ?
[20:59] <bdx> mbruzek: because it has no default value?
[20:59] <bdx> mbruzek: so http://paste.ubuntu.com/14674572/
[21:00] <bdx> mbruze: will automaticall make config.changed('dbms') true
[21:00] <bdx> mbruzek: at the time of install hook?
[21:01] <bdx> mbruzek: I see, hmm, ok. thanks for clearifying that
[21:01] <mbruzek> bdx: Still checking, I am very confused thought we were hung up on pgpd parameter.  Let me look at dbmz
[21:01] <bdx> oooh my bad
[21:01] <bdx> mbruze: will automaticall make config.changed('pgdg') true
[21:03] <bdx> typo in the .yaml I pasted you as well
[21:03] <mbruzek> pgdg is a boolean so it _has_ to have a default value (so it will have "changed" on first run) so I would expect `if config('pgdg') and config.changed('pgdg'):` to be true the first run.
[21:04] <mbruzek> I don't know about dbms or the version parameter.
[21:04] <bdx> mbruzek: ok, no worries, thats all I was after
[21:04] <mbruzek> bdx: stub write this charm code, and hangs out in the channel.  If you have specific postgres questions you can ask Stewart.
[21:06] <bdx> mbruzek: my bad, I thought I saw you as the contrib for that, I see now it was stub
[21:06] <lazypower> bdx are you stirring up trouble again ;)
[21:06] <mbruzek> bdx: I am always happy to help, but I had no context what you were asking.
[21:07] <mbruzek> bdx: if you have questions stub knows that code much better than I do.  But again I am always happy to help if you have questions.
[21:09] <bdx> mbruzek, lazypower:  I'm currently replacing our postgres clusters with juju deployed ones, just running into a few issues, thats all
[21:10] <mbruzek> bdx: Sure.
[21:10] <bdx> mbruzek: thanks, totally, I see that now
[21:11] <mbruzek> bdx: postgresql is one of the more complex charms we have I can see that one being hard to debug
[21:39] <bolthole> Hi. I deployed a second mysql instance, and a gitlab instance, through juju-GUI on azure. They werent happy so I tried to delete them. BUt now they wont go away. How can I force them to go away?
[21:39] <bolthole> the gitlab status is currently "error", with message;
[21:39] <lazypower> bolthole if services are in error they will block
[21:39] <bolthole> hook failed: "Db-relation-changed" for mysqlgitlab:db
[21:40] <lazypower> bolthole you have 2 options - 1) to resolve every error (without retry) and just resolve it all the way down until it goes away
[21:40] <lazypower> 2) juju destroy-machine # --force
[21:40] <lazypower> which is a very very angry way to get rid of a service's units, and you can then juju destroy-service {{service}}
[21:41] <bolthole> so basically, the "resolve" button, actually means "shut up I I nkow about it already" ?
[21:41] <lazypower> correct. it will forcibly resolve the error (if you dont choose retry) and it will continue to the next hook in progression
[21:41] <bolthole> that seemed to work. thanks!
[21:42] <lazypower> np bolthole o/
[21:42] <bolthole> while i'm on the subject, how can I make a new instance of something with a different name, through the gui? ...
[21:42] <bolthole> command line of "juju deploy mysql mysqlfoo" works. but cant seem to find equivalent in gui that actually works
[21:42] <lazypower> when it is dragged onto the gui its "staged"
[21:42] <bolthole> I tried going to the Configure option, and changin ghe name, and pressing save... but it doesnt stick?
[21:42] <lazypower> you should be able to change the service name while its got the blue ring
[21:43] <lazypower> but once its committed, its committed. You cant change the name
[21:43] <bolthole> trying again...
[21:43] <bolthole> adding to canvas...
[21:44] <bolthole> Configure -> Serivce name: "Mysql-gitlab" ... Save changes..
[21:44] <bolthole> but when I click on configure again.. service anme is back to "mysql"
[21:44] <bolthole> seems broken
[21:45] <lazypower> bolthole: thats unfortunate :/ would you mind filing a bug? https://bugs.launchpad.net/juju-gui/+filebug
[21:46] <bolthole> okay
[22:00] <cory_fu> lazypower: I don't know if you saw my edit to my comment on https://github.com/juju-solutions/vpe-router/pull/16 that explains more about the try / else construct in Python
[22:00] <lazypower> i did
[22:00] <cory_fu> Ok.  :)
[22:00] <lazypower> that was all new to me, i had no idea python did try/except, and the except is intended to allow further exceptions to not be caught by the diaper
[22:01] <lazypower> #TIL
[22:01] <cory_fu> aisrael: ^ also.  I do think that Exception should be changed to something more specific.
[22:01] <cory_fu> "except Exception" is generally a bad pattern
[22:02] <cory_fu> The only thing worse is a bare "except:"
[22:02] <cory_fu> :)
[22:02] <lazypower> cory_fu: diaper exceptions ftw i guess?
[22:04] <aisrael> I'm indifferent about the Exception; it's just passing a string back to the action handler to call action_fail with
[22:06] <aisrael> ^^ marcoceppi
[22:09] <cory_fu> The main issue is that it will catch pretty much any type of exception, even ones you are not expecting.  E.g., if the ssh raises something, it will be caught and reported as a validation error, potentially robbing you of some useful stacktrace info
[22:21] <marcoceppi> .
[22:22] <marcoceppi> cory_fu: that method raises an Exception, haven't really scoped it yet :)
[22:23] <marcoceppi> cory_fu: I supposed I should create a new Exception class
[22:23] <marcoceppi> aisrael: I think the else can be squashed and set_state just moved to the last line in the try block


[12:38] <knome> balloons, hullo... do you use the stylish extension?
[12:42] <knome> balloons, wakey wakey! :P
[14:43] <elopio> brendand: replied back to you in my serial branch. Please take a look and give me your opinion.
[14:53] <dobey> pitti: hey. any idea why line 18 in this log happens, given the command used on line 1? http://pastebin.ubuntu.com/9902391/
[14:55] <brendand> elopio, yeah i suppose that would be ok
[14:56] <brendand> elopio, approved it
[14:57] <elopio> ping jibel: if there is only one device connected, would you like the sanity script to use it without asking for the serial?
[15:02] <jibel> elopio, ideally yes
[15:05] <jibel> elopio, like adb or the ssh/adb backend of autopkgtest
[15:08] <elopio> jibel: do you want that as part of the card "run sanity while more than one device is connected", or for that card it's ok to always ask the serial, and we should add a different story for the case when only one device is connected?
[15:09] <jibel> elopio, do you need a card for every option?
[15:10] <jibel> elopio, that's part of the "multiple devices support" story. Add a line in the description of this card.
[15:11] <elopio> jibel: we don't need a card for every option. We just need to define better the acceptance criteria, so we write only the minimum amount of code to meet it.
[15:11] <elopio> that case of only  one device connected is something we didn't discuss. We'll make it as part of this card.
[15:20] <pitti> dobey: sorry, was in a meeting
[15:20] <pitti> dobey: not immediately; I mostly tested the session setup script in LXC, although it shouldn't make too much difference (at least with the vivid version of autopkgtest)
[15:21] <pitti> dobey: but /dev/uinput not being available would also totally break it
[15:22] <pitti> dobey: so, bug report appreciated (this needs some more time to investigate, and probably the ubuntu-touch-session script needs to be updated to the current reality)
[15:23] <dobey> pitti: ok
[15:24] <dobey> pitti: also, does anyone actually use the feature of running multiple tests for multiple things with the same command line? i'm pretty sure jenkins doesn't, and i don't know why anyone would do so locally
[15:26] <pitti> dobey: I don't know really; we don't in CI; it's just an ancient CLI which I wouldn't like to break without a good reason
[15:28] <dobey> pitti: well, "nobody uses it and it makes using adt-run, and its code, that much more complex" is a pretty good reason to me :)
[15:28] <pitti> dobey: heh, yes :)
[15:28] <pitti> dobey: when I saw it the first time I was quite stumped, too
[15:29] <dobey> pitti: i don't know if this is a good enough bug report, but here you go: https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/1415514
[15:30] <dobey> pitti: honestly, since i've started trying to add autopilot tests to autopkgtest configs, i've had nothing but problems with both :-/
[15:31] <pitti> dobey: so, one of these days I'd like to create a new CLI called "autopkgtest" which replaces adt-run, and thus get rid of that weird name too :)
[15:32] <dobey> pitti: oh, and btw, https://people.debian.org/~mpitt/autopkgtest/README.running-tests.html mentions "apt-ro" as a setup-command several times, but in reality it's actually "ro-apt" :)
[15:32] <pitti> dobey: yeah, most people just run AP tests on real iron or the emulator; the setup script was quite a hack and doesn't get used/maintained a lot; there is bug 1376423 to put that into a proper place and fix up to be closer to what happens in reality
[15:33] <balloons> ohh.. heh, this floats back to that lovely bug
[15:33] <dobey> ah
[15:33] <pitti> dobey: oh, several? I just see it once (thanks for pointing out, fixing!)
[15:34] <brendand> elopio, none of the existing config tests create a fake config?
[15:34] <balloons> dobey, you should also mention the need to pass args in order, although as I said I believe there is a reason
[15:34] <dobey> pitti: oh, i thought i saw it several times. maybe it's just the once then :)
[15:34] <pitti> dobey: committed
[15:34] <dobey> balloons: yes i already complained about that above :)
[15:34] <dobey> balloons: the reason is "an old feature nobody actually uses" :)
[15:36] <dobey> i'm hoping we can get rid of all the autopilot tests in the click scope at least, now that there is a test harness for scopes api
[15:40] <balloons> dobey, I'm glad you and pitti finally synced up :-)
[15:40] <pitti> dobey: bug good enough> sounds easy enough to reproduce, so should be fine; thanks
[15:41] <dobey> ok, cool
[15:58] <elopio> brendand: fake config contents, yes. Take a look in my branch.
[16:20] <elopio> alesage: brendand: how would you prefer the serial handling? Ask for a serial if more than one device is connected, or ignore the number of devices connected, if the user doesn't provide a serial, assume there's only one.
[16:21] <brendand> elopio, i think it only needs to be as smart as existing tools
[16:21] <alesage> elopio, maybe the first seems better but what do you think?
[16:22] <alesage> elopio, for the second design, which would you run the tests on?
[16:32]  * alesage is not sure if he picked the right answer
[16:37] <elopio> first seems better, maybe too smart as brendand says.
[16:37] <elopio> alesage: I don't get your second question.
[16:37] <brendand> elopio, it's indeed 'better', but do we really need to be smarter than the tools we wrap?
[16:38] <alesage> elopio, I'm going to table my second question
[16:38] <elopio> brendand: not if it is not required by the customer.
[16:38] <brendand> elopio, i say:
[16:38] <brendand> - if one device is attached, use it
[16:39] <brendand> - if more than one is attached, use the specified serial
[16:39] <brendand> - if no serial is specified, exit with an error
[16:40] <alesage> endif
[16:40] <elopio> brendand: I don't like your first bullet, because I might have connected the wrong device. I specify the serial, and I want to run the tests there. If that serial mismatches the connected one, IMO it should exit with an error.
[16:40] <brendand> elopio, i almost typed that - yeah if it's not too hard we could check for that too
[16:41] <elopio> it's actually harder to check for what you want.
[16:41] <elopio> so, specifying no serial should succeed only if there's only one device connected.
[16:41] <alesage> that's fair
[16:41] <alesage> yes that was my q: on which would your run int hat case?
[16:42] <brendand> elopio, do you know about this failure in the wizard test: http://paste.ubuntu.com/9919877/ ?
[16:42] <elopio> brendand: can you get a screenshot out of it?
[16:42] <elopio> I'd say, the pin keyboard did not appear.
[16:43] <brendand> elopio, how do i hack it to just run one test?
[16:45] <brendand> elopio, ah i can modify __all__
[16:45] <elopio> brendand: yup.
[16:46] <brendand> elopio, so to list the tests can't we just print __all__?
[16:46] <brendand> elopio, i suppose there are the imported tests as well
[16:46] <elopio> brendand: no, because there are other tests defined in debian/tests
[16:47] <brendand> elopio, and is it hard to list those?
[16:47] <elopio> brendand: no, just weird.
[16:47] <elopio> we have some tests in our branch, and some other come from the packaging of our branch.
[16:48] <elopio> maybe, we should move the list of external tests out of debian/tests. From there just call a method: get me the tests.
[16:48] <brendand> elopio, i think so
[16:49] <brendand> elopio, there should be one method of finding all the tests to run
[16:49] <elopio> brendand: I think it would be good, also to keep the code in debian/tests as small as possible.
[16:52] <elopio> jibel: there are some cards about checking images and their thumbnails. How would you like to see the checks for those? Simple like checking that the source is an image file and that it's not all black, or some smarter check that the displayed image matches the source with accuracy?
[16:53] <jibel> elopio, check that the thumbnail is not only one color, we don't really care about accuracy, since it's a thumbnail it'll lose information anyway.
[16:54] <elopio> jibel: ack. What about the images opened in the gallery?
[16:56] <jibel> elopio, check it is not black or a single color. That's usually the result when there is a bug in a codec.
[16:56] <jibel> or the thumbnailer
[16:56] <elopio> jibel: ok.
[19:18] <elfy> balloons: so then ... assuming that bug 1325801 sits at triaged till this time next week - what do we regarding info pre the globla jam
[19:18] <elfy> currently we point people at a tool that sometimes works still :)
[19:30] <balloons> elfy, I discovered disks fails in vivid btw
[19:30] <balloons> made a bad image for me.. I used dd
[19:47] <elfy> mmm
[19:48] <elfy> so basically - use a windows tool ...
[19:49] <elfy> balloons: what fail was it - something other than one we've already seen?
[19:51] <balloons> wouldn't go past the boot. I still have it, need to reboot and collect the error
[19:52] <elfy> k
[19:53] <elfy> I've used disks a few times since then in vivid - worked with ubuntu/kubuntu/xubuntu 2 or 3 times and even manjaro
[19:53] <balloons> but yes, I thought we said we would writeup something for disks as the alternative
[19:55] <elfy> perhaps include dd as well - what command to recommend though
[19:58] <elfy> balloons: does it need to be actually on wiki? or would a pad do - what do you think ?
[19:58] <elfy> hopefully it's just a temporary situation
[21:27] <balloons> elfy, it doesn't HAVE to be on the wiki, though I don't see why it can't be


[00:00] <Verterok> heya!
[00:00]  * Verterok waves greetings
[00:00] <Verterok> jfroy: it looks like a bug un setuptools :(
[00:01] <Verterok> jfroy: or an old version
[00:02] <jfroy> Verterok: not part of setuptools, that's part of bdist_mpkg
[00:02] <Peng_> How do you get "bzr: ERROR: No module named tests" when running from source?! :(
[00:02] <Peng_> Ahh! Plugin! Heh
[00:02] <Verterok> jfroy: right, it seems to be fixed in trunk
[00:03] <Peng_> That's what I get for not reading hte traceback first.
[00:03] <jfroy> Verterok: Ah, I see
[00:04] <Verterok> jfroy: the trac instance seems to be down, but you can get it from the svn: "< impl> I didn't realize Aerdan had prioritized the animals he wants to have sex  with"]
[00:04] <Verterok> 19:48 < mxpxpod> jelmer: ok, thanks
[00:04] <Verterok> worng paste :p
[00:04] <Verterok> jfroy: http://svn.pythonmac.org/bdist_mpkg/bdist_mpkg/trunk/
[00:04] <jfroy> yeah I got it :)
[00:04] <Verterok> ok
[00:05] <jfroy> Verterok: seems to work great
[00:06] <Verterok> nice
[00:07] <jam> poolie: can you call back?
[00:07] <poolie> sure
[00:09] <lifeless> hi poolie
[00:09] <jfroy> Verterok: yup, works :)
[00:09] <Verterok> jfroy: yay!
[00:11] <jfroy> It is Very Good™ not to have to type my svn passwords 3 times or more for operations on svn repositories (with my experimental bzr+keychain branch)
[00:11] <jfroy> :)
[00:12] <jfroy> Need to get that out of experimental now :p
[00:13] <lifeless> poolie: sorry, missed it
[00:13] <lifeless> poolie: pls ring again
[00:13] <jfroy> Verterok: It's kind of sucky that you have to maintain two builds to target 1.4 and 1.5
[00:14] <Verterok> jfroy: yeap, don't have an idea of how much I agree on that
[00:14] <jfroy> Tiger is so long ago for me, was svn even bundled with it?
[00:14] <Verterok> jfroy: but I know there are a lot of people still on 1.4.x
[00:14] <Verterok> jfroy: nope, you must install it from "somewhere" (macports, collabnet, etc)
[00:18] <jfroy> Verterok: that's incredibly crappy :/
[00:19] <Verterok> jfroy: yeap, that's the reason I only build it against collebnet binaries :)
[00:19] <jfroy> Honestly, I'd just make 2 packages, one for svn 1.4 and one for svn 1.5, installed in /usr/local/ (e.g. the collabnet binary packages). If they have it elsewhere, I'd just tell them to build bzr-svn from source...
[00:19] <Peng_> Eek, there's a test that builds everything?
[00:20] <Verterok> jfroy: imagine building it for macports, fink, collabnet (all x2 (1.4 amd 1.5)) :p
[00:20] <jfroy> Verterok: no thanks ;p
[00:20] <Verterok> me neigther :)
[00:21] <jfroy> If you wanted to be *reaallly* clever, you could build against 1.4 only in /usr/local, then use an installer script to find the actual install, then muck around the Mach-O headers to change the import paths, and hoping the 1.5 libraries are binary compatible with the 1.4 libraries :p
[00:21] <jfroy> Sounds like a lot of unpleasant installer script work :p
[00:22] <Verterok> indeed :p
[00:23] <jfroy> Verterok: oh, you'd also have to weak import all symbols and modify the bzr-svn source to check for NULL function symbols, in case someone decides to build from source and omit support for https, or keychain, or what have you :p
[00:25] <Verterok> jfroy: that sounds way too complicated :), I'll stick with the script that build both version against collabnet binaries. as far I know, is the more complete dmg for 10.4
[00:26] <Verterok> if someone builds svn from source, I'm pretty sure the 'll be able to build bzr-svn ;)
[00:26] <jfroy> Verterok: I wasn't being serious :p
[00:26] <Verterok> jfroy: I supposed that, but just in case :)
[03:08] <poolie> markh, could you try to build 1.7.1 exes sometime?
[03:08] <poolie> i did not set up that server yet
[03:08] <poolie> i'd like to
[03:09] <markh> poolie: sure - I'll try and do that this afternoon
[03:09] <poolie> thanks
[03:11] <markh> I've been working on porting pywin32 to py3k recently - that is an interestng experience :)
[03:12] <markh> well - more like watching/helping some other person do it :)
[03:12] <markh> I figured I should get a little hands-on experience before the first official release - even if only by a few days
[04:00] <jml> spiv: is there a config option I can use so that -dHPSS is always on?
[04:16] <spiv> jml: "alias bzr='bzr -Dhpss'" in your bashrc ;)
[04:21] <jml> incidentally, MemoryTransport.rename's behaviour varies based on dict ordering.
[04:26] <spiv> jml: that doesn't sound good.
[04:26] <jml> spiv: it doesn't feel good eiter.
[04:27] <mwhudson> in other sucky news
[04:27] <mwhudson> mwh@grond:init-stack-pull$ bzr push
[04:27] <mwhudson> Using saved push location: bzr+ssh://bazaar.launchpad.net/~mwhudson/launchpad/init-stack-pull
[04:27] <mwhudson> bzr: ERROR: Must end write group before releasing write lock on KnitPackRepository('bzr+ssh://bazaar.launchpad.net/%7Emwhudson/launchpad/init-stack-pull/.bzr/repository/')
[04:28] <spiv> mwhudson: pastebin the traceback?
[04:28] <mwhudson> spiv: there is no traceback
[04:29] <spiv> mwhudson: ~/.bzr.log is your traceback-recording friend! :)
[04:29] <mwhudson> hey guess what guys!!!
[04:29] <mwhudson> it was autopacking
[04:29] <spiv> It might be caused by the same sort of situation that has caused TooManyConcurrentRequestErrors in the past.
[04:29] <spiv> Heh.
[04:29] <jml> number one bzr bug
[04:30] <mwhudson> at least it's fixed now
[04:30] <spiv> mwhudson: I'd still like to see the traceback :)
[04:31] <mwhudson> spiv: https://pastebin.canonical.com/9805/
[04:32] <mwhudson> spiv: happens with bzr.dev 3731 too fwiw
[04:32] <spiv> Yeah, I think it does have the same root cause.
[04:32] <spiv> mwhudson: thanks
[04:32] <mwhudson> my bzr.dev may be a little out of date tho
[04:33] <jml> spiv: bug 276972 if you are interested.
[04:39] <spiv> jml: ta
[04:44] <mwhudson> spiv: happens with bzr.dev too, but maybe upgrading the bzr on the server would fix it?  not sure
[04:44] <mwhudson> (as would maybe pushing over sftp i guess)
[04:46] <spiv> mwhudson: depends on what the underlying error that is being masked by the bug in BzrBranch.push is
[04:46] <spiv> mwhudson: I can give you a patch to allow the original exception to propagate
[04:47] <mwhudson> spiv: i am driving several hundred km away in about 20 mins :)
[04:47] <spiv> mwhudson: http://rafb.net/p/4pgIvJ66.html
[04:48] <spiv> mwhudson: but if you go enjoy your road trip instead I'll understand :)
[04:55] <spiv> mwhudson: https://bugs.edge.launchpad.net/bzr/+bug/230902
[05:28] <lifeless> spiv: ping; remind me - subclasses of classes with slots; need the total list of attributes?
[05:28] <spiv> lifeless: IIRC, they just need the list of attributes added by the subclass.
[05:29] <spiv> Hmm, apparently my memory is faulty.
[05:31] <lifeless> spiv: :P
[05:32] <spiv> Ah, no, just my quick 10-second attempt to verify it in the python interpreter was wrong :)
[05:32] <spiv> My memory turns out to be fine :)
[05:35] <spiv> (And the docs in fact say the meaning of defining the same slot twice, i.e. in a class and in a subclass, is "undefined")
[05:43]  * mwhudson off
[05:52] <lifeless> spiv: interesting; see, I want to delete a slot the base class has :P
[05:56] <spiv> lifeless: ah, well... tough :P
[05:58] <lifeless> :->
[06:05] <lifeless> when did I last mention hating doctest?
[06:07] <lifeless> abentley: are you up?
[06:07] <abentley> Yeah
[06:08] <lifeless> serializers are puzzling me
[06:08] <lifeless> I'm hacking on a demand-loading inventory
[06:08] <lifeless> serializer foo currently assumes you *can* serialize an inventory to a single string
[06:08] <lifeless> e.g. bzrlib/tests/per_repository/test_repository.py
[06:08] <lifeless> line 671,
[06:08] <lifeless> test_add_revision_inventory_sha1
[06:09] <lifeless> which checks that the serializer is used and its sha output recorded
[06:10] <lifeless> I *think* I need to make the interface tests not be defined in terms of the serializer object, but I was wondering if you had any thoughts?
[06:10] <abentley> lifeless: by demand-loading, what do you mean?  Segmented so that only some items are loaded at a time?
[06:10] <lifeless> abentley: yes
[06:10] <lifeless> abentley: fragemented into lots of little pieces
[06:11] <abentley> So I would say the serializer abstraction doesn't make sense for these.
[06:11] <lifeless> I figure I can have a serializer object that represents the particular style of splitting
[06:11] <lifeless> and we still have revisions as single objects
[06:12] <abentley> Okay, our *current* serializer abstraction doesn't make sense.
[06:12] <lifeless> :>
[06:12] <lifeless> thanks, I think I have what I need
[06:12] <lifeless> I've posted about this work btw, and its pushed
[06:13] <lifeless> the most recent stuff isn't passing tests yet and I'm closing the gap there hoping to push more to play with tonight
[06:13] <abentley> You'll probably want moral equivalents of most of the single-string serializer tests.
[06:13] <abentley> And I'd imagine the existing tests should be used for existing serializers.
[06:14] <abentley> lifeless: Yeah, I sort of read it.
[06:14] <poolie> lifeless: i don't have a strong opinion that you should do a cache in a CHKInventory now
[06:14] <poolie> it is not very clear from your mail why you'd want to
[06:16] <abentley> I'm not really clear on what CHK stands for, so I can't comment intelligently.
[06:16] <lifeless> abentley: its an abbreviation for content hash key; e.g. "md5:1234123421342" or "sha1:1234135143514645acdef"
[06:18] <lifeless> (this predates git's terminology and is more general, I think its a more useful way to talk about using hashes as keys)
[06:18] <abentley> lifeless: So CHK is a superset of content-addressible filesystem.
[06:19] <lifeless> poolie: there may be code that does lots of repeated lookups of the same fileid
[06:19] <lifeless> poolie: a cache would ameliorate those codepaths (remove repeated-parsing overhead)
[06:19] <poolie> right
[06:20] <poolie> i thought that's what you meant
[06:20] <lifeless> abentley: roughly yeah; not really a file system as packs are transactional etc etc
[06:20] <abentley> lifeless: I mean the CHK terminology, not your work specifically.
[06:21] <lifeless> abentley: the yes, though I think perhaps 'intersecting with' rather than 'superset', but perhaps I'm being overly pedantic
[06:22] <poolie> abentley, i agree, i think HashKeyedInventory or something would be clearer
[06:22] <poolie> or even just HashedInventory
[06:22] <lifeless> SmokingInventory
[06:22] <poolie> mm
[06:23] <poolie> at least it's not scatalogical
[06:23] <abentley> Yeah, HashedInventory is more evocative.
[06:24] <lifeless> its building on CHKMap not on hashing itself; its quite generic code; uhm, I'm sure thenaming can be improved, but perhaps its making the layers clearer that is needed
[06:25] <abentley> This is also a split inventory concept.  Is it splitting on directories or a radix tree?
[06:25] <lifeless> abentley: either
[06:25] <lifeless> abentley: I intend to put together CHKMap subclasses to let use experiment with both both those concepts and the other variations
[06:26] <lifeless> abentley: (which are the parameters I mentioned in my mail from tuesday)
[06:26] <lifeless> s/use/us/
[06:28] <poolie> presumably both of them should be renamed if we think 'CHK' is cryptic
[06:29] <abentley> lifeless: I didn't see that mentioned in the email.
[06:29] <lifeless> poolie: presumably; one more note on naming though - it should be quite specific; 'Hashed' is IMO hopelessly generic, I mean, current Inventory objects are Hashed internally. (self._byid).
[06:30] <spiv> I didn't find "CHK" too cryptic, but perhaps I'm just odd :)
[06:31] <lifeless> abentley: this list:
[06:31] <lifeless> The undecided aspects, which experimentation/modeling is needed on:
[06:31] <lifeless> ...
[06:31] <lifeless> includes the item for how we break up nodes in the tree
[06:34] <abentley> lifeless: It doesn't actually say that, though.  I had to re-read it 3 times to guess that "should we canonicalise nodes by size rules, or (only applies to a name map that doesn't hash keys) by directory membership" was addressingthat.
[06:35] <lifeless> abentley: sorry :)
[06:35] <lifeless> abentley: I'm quite deeply embedded in this now, after some months of lead up; I'll try to be more clear in future
[06:36] <lifeless> abentley: though there is a tradeoff in repeating content from the design work (which is in doc/developers/inventory.txt in bzr.dev)
[06:42] <abentley> lifeless: Yes, there is a balance to be struck.
[06:44] <lifeless> abentley: I just an image of a set of scales being hit repeatedly
[06:44] <lifeless> abentley: :)
[06:53] <markh> poolie: uploaded
[06:56] <poolie> thanks!
[06:57] <poolie> markh, could you send me a brief roadmap of what you'd like to do next on tortoise?
[06:57] <markh> sure
[07:03] <vila> hi all
[07:17] <vila> spiv: any reason you didn't re-vote on 'regression on OSX in TestReadMergeableFromUrl.test_smart_server_connection_reset' ?
[07:25] <lifeless> spiv: ping
[07:25] <lifeless> spiv: I have a wtf moment in check
[07:25] <lifeless> spiv: in repository.py, line 3259 for me is:
[07:26] <lifeless> knit_parents = parent_map[key]
[07:26] <lifeless> this is in a try:except RevisionNotPresent: guard
[07:26] <lifeless> but parent_map is a plain dict ?
[07:26]  * spiv opens it up
[07:27] <spiv> lifeless: sure looks like a wtf
[07:27] <lifeless> spiv: clearly, I'm doing heart surgery here, so I'm seeking option numero duo
[07:27] <lifeless> spiv: ok, so its broken code, and the question is 'why do normal repos not hit it'
[07:27] <lifeless> spiv: thanks
[07:27] <spiv> lifeless: I assume there's a gap in the test coverage :(
[07:28] <lifeless> spiv: possibly not
[07:28] <spiv> lifeless: hmm, actually
[07:28] <lifeless> spiv: possibly its a redundant check that cannot trigger unless something else is broken
[07:28] <lifeless> (as in some other code is broken)
[07:28] <spiv> lifeless: yeah, that's what I'm suspecting
[07:28] <spiv> lifeless: anyway, no need for us both to do the same digging at the same time :)
[07:29] <lifeless> spiv: I'm not digging at that :)
[07:29] <lifeless> spiv: with consensus on the wtf, I'm ignoring it
[07:29] <spiv> Ah.  Well, I still intend not to get side-tracked then :P
[07:29] <lifeless> spiv: good choice :)
[07:30] <spiv> vila: oh, I didn't re-read the new patch carefully, I thought it was just updating == to is.  I see now it also moved it to the right layer.
[07:30] <poolie> lifeless: did you call?
[07:30] <lifeless> poolie: no
[07:31] <spiv> vila: it'd be nice to have a test that reliably fails (on all platforms) without this fix.
[07:33] <spiv> vila: I *think* that's probably feasible using the _DisconnectingTCPServer in test_bundle (i.e. the same way that is triggering test failures for you atm)
[07:33] <vila> spiv: I'll look into that, do you also want it to apply to all SmartMedium classes ?
[07:34] <vila> well, may be not all, the pipe one may not be relevant
[07:34] <spiv> vila: e.g., start a _DisconnectingTCPServer, create a SmartTCPClientMedium pointing at it, and then try client_medium.read_bytes(1)
[07:35] <spiv> Well, it'd be good to have equivalent tests for all SmartMedium classes, but it can't be the exact same test.
[07:35] <spiv> Pipes don't talk to sockets and get socket.errors, after all :)
[07:36] <jdrake> bzr is *sweet*
[07:36] <vila> sure, and socket.error may not be relevant either for http
[07:36] <spiv> Right.
[07:37] <spiv> I certainly wouldn't object to doing that :)
[07:38] <vila> spiv: Ok, I read that as BB:resubmit then :) Thanks
[07:38] <spiv> But I wouldn't hold up landing the fix to this medium while working on unique tests for all medium implementations.
[07:38] <spiv> So, bb:tweak :)
[07:38] <jdrake> I can actually remember how to use some of the commands, unlike cvs
[07:38] <spiv> jdrake: that's because we don't use "update" to do three different operations ;)
[07:39] <jdrake> haha
[07:39] <jdrake> I might actually be able to use bzr to do more than just code with school coming up.
[07:40] <spiv> vila: bb:tweak formally given
[07:42] <vila> spiv: ok, thanks
[07:43] <lifeless> abentley: if you're around, do you remember the precise in-memory difference between a rich-root inv and a non-rich-root ?
[07:43] <lifeless> abentley: actually, nvm, asking that question clued me in to the answer
[07:43] <robsta> hi lifeless
[07:44] <robsta> lifeless: jelmer hinted you might know a workaround for phantom references messing up "diff"
[07:44] <robsta> (bug#275861)
[07:45] <robsta> oh "ghost revisions" it's called
[07:46] <lifeless> robsta: hi; uhm, I don't think I do
[07:46] <lifeless> robsta: did he hint with any more detail ?
[07:46] <lifeless> jelmer: ^ EWHYME?
[07:46] <robsta> lifeless: no; is this specific to svn server-side?
[07:47] <lifeless> robsta: yes, bzr-svn exercises the ghost capabilities most strongly of anything bar 'baz-import' which I think has actually been deleted from bzrtools now
[07:48] <lifeless> robsta: last I heard jelmer was working on changing a bunch of stuff to fit what bzr's core looks for more; I don't know  if he has
[07:49] <lifeless> robsta: BTW, orthogonal thing, you might like to try the 'development2' format in bzr.dev; it uses the btree stuff I was doing back @ guadec; the new compressor isn't finalised yet, but the index stuff helps quite a bit
[07:49] <robsta> lifeless: define "quite a bit"
[07:50] <robsta> lifeless: i tried going back to bzr-playground.gnome.org, but when i merge my svn into the bzr branch there's an error about rich-root
[07:50] <lifeless> robsta: depending on specific workload, up to 10 times faster, or more.
[07:50] <lifeless> robsta: pastebin the rich root error please
[07:51] <robsta> speed is not the problem, the problem is that diff bails on me
[07:51] <lifeless> robsta: right, did I mention orthogonal?
[07:54] <robsta> lifeless: http://pastebin.com/m36aec880
[07:55]  * robsta prefers to stay one-dimensional
[07:55] <lifeless> that would be the whiskey dimension?
[07:55] <lifeless> run bzr info -v locally please
[07:55] <lifeless> specifically on gtk-css-engine-bzr
[07:56] <robsta> http://pastebin.com/m6f95d2bf
[07:57] <lifeless> no idea *how* you got that setup; but its not a bzr-svn compatible local repository
[07:57] <lifeless> back it up, then bzr upgrade --rich-root-pack
[07:57] <lifeless> then try again
[07:58] <robsta> lifeless: yay
[07:58] <robsta> lifeless: so does this still have ghost references, or can i push --overwrite this to the upstream svn?
[07:59] <lifeless> robsta: give it a shot; I disclaim all knowledge of code internals
[07:59] <lifeless> svn is atomic yeah? whats the worst could happen :P
[08:00] <poolie> vila, yeah, let's talk here
[08:00] <vila> Discussing with John, it appears that log.py miss an API with revids (that's the main blocking part for missing)
 either that or some variation where you give the list of revisions you want to show
 roughly speaking, log is designed around revnos with shortcuts to avoid O(history) when only mainline revisions are needed
[08:01] <lifeless> vila: ^ oh yeah, re ghosts, bzr-svn, major user.
[08:01] <vila> lifeless: thanks, sorry, I still need to send that mail :-/
[08:01] <vila> lifeless: but it's not forgotten !
[08:03] <robsta> lifeless: "No new revisions to push." can i force this somehow?
[08:04] <robsta> lifeless: for some reason svn is like 30 revs ahead
[08:04] <vila> I (well jam too :)  think log.py should evolve in a direction where we can calculate revnos on-demand
[08:04] <poolie> vila, i think that idea of jam's that we should show why some revisions are included is interestning
[08:04] <poolie> > the true solution is to be able to get revnos without being O(history)
[08:05] <poolie> right, that would be highly useful
[08:05] <vila> sure, the two are related, but getting revnos without being O(history) is the root
[08:05] <poolie> so as i understand there are two threads towards that - either caching them, or looking for algorithms that let us skip larger parts of the graph
[08:06] <vila> another one being changing the revno definition, but for compatibility I don't want to *start* with that
[08:06] <vila> an intermediate solution is also to use gdfo
[08:07] <vila> gdfo == Greatest Distance From Origin
[08:07] <vila> which could also help spiv case in Batch get_parent_map HPSS calls made from InterRepo._walk_to_common_revisions
[08:08] <vila> I know that but I'm not able to explain it clearly just yet :-/
[08:08] <vila> roughly, we indirectly batches requests when bisecting today, using gdfo can help batching requests in a more controlled way
[08:09] <lifeless> robsta: svn has new content?
[08:09] <lifeless> robsta: or just a higher 'revno' ?
[08:09] <robsta> lifeless: just revno, just pulled everything into the bzr tree
[08:10] <lifeless> robsta: revno is per-branch, so it sounds like no-problem to me, or am I missing something?
[08:10] <poolie> vila, so as far as scheduling it, i'd be looking at: is it likely you'll make progress on it, does it matter to guilhem and other users, and should we be concentrating on something else instead
[08:10] <poolie> i would say the startup overhead for log does matter to people
[08:11] <lifeless> robsta: I have to go now; sorry
[08:11] <lifeless> robsta: uhm, I'd hope jelmer is up soon
[08:11] <vila> I'm surely making progress on it but I need some more time to show results
[08:11] <lifeless> bye poolie
[08:11] <lifeless> and vila etc
[08:11] <robsta> lifeless: will use it, should work, thanks!
[08:11] <vila> the scale being days
[08:11] <poolie> night lifeless
[08:11] <vila> lifeless: cu
[08:11] <vila> the scale being days, several days, but not more than two weeks I'd say
[08:11] <fullermd> Well, on the downside, getting log running IS awfully slow sometimes...
[08:12] <fullermd> But on the sorta-upside, any time I feel like log is too slow, I can just run log -v to jolt myself.
[08:12] <vila> another aspect, thanks fullermd, is to make log really streamed
[08:13] <fullermd> We're storing the revno of HEAD in the branch.  I can't help but feel we're not USING it, though...
[08:13] <vila> another option being to *not* show revnos for people who want really fast log :)
[08:13]  * spiv goes to the shops
[08:13] <vila> fullermd: we use it !
[08:13] <vila> all shortcuts are based on that
[08:13] <poolie> vila, or we could default to log --line, and make sure that it does not compute non-mainline revisions
[08:13] <poolie> i think that may be the easiest in some ways?
[08:13] <vila> poolie: I think we do already
[08:14] <poolie> do you know what's the main thing in the profile of --line?
[08:15] <poolie> hm
[08:15] <fullermd> That's even sadder, then.
[08:15] <poolie> well, perhaps that's beside the point
[08:15] <poolie> fullermd: what is?
[08:16] <fullermd> log --forward --short -r-10.. of bzr.dev (with bzr dev), with all the caches heated up and all, takes like 3 seconds.
[08:16] <vila> I concentrate on higher level stuff so far but plan to measure progress on how things go
[08:16] <fullermd> I assumed at least some of that was eaten up walking back to origin to figure out the revnos.
[08:16] <poolie> hm, it's about 800ms for me...
[08:17] <fullermd> 2.608u 0.223s 0:02.84 99.2%
[08:17] <vila> fullermd: come on, --forward is just asking for slowness :)
[08:17] <vila> at least for now
[08:18] <fullermd> Doesn't make any distinguishable difference   :p
[08:18] <poolie> hm
[08:18] <vila> roughly, actually, log is based on the idea that we built the history we need (the long part) then we issue the formatted text we want for each revision
[08:18] <fullermd> Now, granted, my system isn't the speediest on the planet.  But still, it's fast enough that Firefox is almost usable a good half of the time.
[08:18] <poolie> anyhow
[08:19] <vila> What I'd want to do is make it more streamed: walk the needed graph, filter revisions, display formatted text
[09:09] <luks> jelmer: are you around?
[09:21] <poolie> hi luks
[09:22] <luks> hi
[09:41] <luks> ok, now I'm really confused
[09:41] <luks> I thought `bzr dpush` from bzr-svn was supposed to rebase my branch
[09:42] <luks> but it kept my bzr revision untouched, so I deleted the bzr-svn cache, tried to branch again and I still get the original revision
[10:00] <bob2> hm, so long since I modified a chatscript
[10:00] <bob2> oops
[10:07] <No`> hi bazaarians
[10:15] <jelmer> luks, somewhat
[10:15] <jelmer> luks, it will rebase your *local* branch
[10:15] <jelmer> if necessary
[10:16] <luks> jelmer: yeah, the thing is that it did not
[10:16] <luks> jelmer: at least from what I can see
[10:16] <luks> jelmer: and I don't understand where is the info (revid, etc.) stored, because it's not in SVN
[10:16] <jelmer> luks, it will also not rebase if it didn't have to push anything
[10:17] <luks> jelmer: it pushed one revision, I'll try to branch on a completely clean machine
[10:17] <lifeless> jelmer: robsta has some issues
[10:20] <robsta> lifeless: should i attach the repo tarball to the bug (1.7M bz2) =
[10:20] <lifeless> robsta: sure
[10:21] <lifeless> jelmer: I am not here right now, but all I had robsta do was upgrade to rich root (they weren't, for some ??? reason - don't know how anything had worked before then)
[10:21] <lifeless> jelmer: but now it has a missing text error, I'm suspecting some bzr-svn interaction bug; perhaps you can chat in detail with robsta to figure out exactly what's happened
[10:23] <robsta> #277043, fyi
[10:26] <Se6ast> Hi guys. I do have a small project versioned with bzr (personal version control in the guide), myproj/subprojA. so in subprojA there is a .bzr repo with the full history. However, I am now adding other sub-projects: myproj/subprojB, myproj/subprojC and I would like to have a new bzr repo with everything in myproj. So I cd myproj; bzr init. How can I pull all the versioning history of subprojA into it ? with merge? in myproj if I do bzr merge subproj
[10:27] <jelmer> lifeless, robsta: I don't have time to look into it at the moment, but have a look when I do. Thanks for filing a bug.
[10:30] <robsta> n/p
[10:54] <jml> is there a revisionspec for branch parent?
[11:03] <visik7> I want to checkout django-1.0  with bzr
[11:03] <visik7> bzr get http://code.djangoproject.com/svn/django/trunk django-bzr
[11:03] <visik7> works
[11:03] <visik7> while
[11:04] <visik7>  bzr get http://code.djangoproject.com/svn/django/tags/releases/1.0 django
[11:04] <visik7> doesn't
[11:04] <visik7> the 2 path works with the svn command
[11:22] <lifeless> jml: :parent ?
[11:22] <jml> lifeless: nope. maybe my bzr is too old.
[11:23] <lifeless> oh thats a location alias
[11:23] <lifeless> meh
[12:14] <liw> if I convert my branch to rich-root-pack format, how likely will I make other people suffer? (the main person I collaborate with has that format and that makes it hard for me to currently accept his bundles)
[15:43] <g0nzal0> hi there!
[15:43] <g0nzal0> I'm trying to use bzr-svn
[15:43] <g0nzal0> I installed it using "sudo easy_install bzr-svn"
[15:43] <g0nzal0> but it doesn't seem to be working :(
[15:46] <g0nzal0> http://dpaste.com/81931/
[15:58] <Verterok> g0nzal0: what is the name of the directory were easy_install "installed"?
[15:59] <g0nzal0> /usr/lib/python2.5/site-packages/bzr_svn-0.4.13-py2.5-linux-i686.egg
[15:59] <Verterok> ohh eggs
[16:00] <Verterok> g0nzal0: I'm not sure that bzr  plugins work as eggs at all
[16:00] <g0nzal0> I see, I'll try something else, thanks for the info :)
[16:00] <Verterok> g0nzal0: try installing it using plain old setup.py and avoid egg
[16:00] <g0nzal0> yes, I'm onto it
[16:01] <Verterok> g0nzal0: np
[16:05] <g0nzal0> Verterok: :(
[16:05] <g0nzal0> http://dpaste.com/81935/
[16:12] <Verterok> let's see
[16:12] <Verterok> g0nzal0: run it with -Derror
[16:13] <Verterok> g0nzal0: i.e: bzr -Derror plugins
[16:18] <g0nzal0> Verterok: I had bzr installed with easy_install too
[16:19] <g0nzal0> Verterok: took that away
[16:19] <g0nzal0> Verterok: and reinstalled it from ppa
[16:19] <g0nzal0> Verterok: (I use Ubuntu)
[16:19] <g0nzal0> $ bzr -Derror plugins
[16:19] <g0nzal0> gtk 0.94.0
[16:19] <g0nzal0>     Graphical support for Bazaar using GTK.
[16:19] <g0nzal0> launchpad
[16:19] <g0nzal0>     Launchpad.net integration plugin for Bazaar.
[16:19] <g0nzal0> svn 0.4.13
[16:19] <g0nzal0>     Support for Subversion branches
[16:19] <g0nzal0> :-D
[16:19] <Verterok> g0nzal0: goooood, ppa is goood :)
[16:20] <g0nzal0> didn't know about it, it rocks! :)
[16:23] <vila> la la la, Russian roulette, pqm blocked
[16:23] <g0nzal0> I'm branching django-survey with bzr-branch!!!
[16:27] <jam> vila: *why* does it always happen from *your* submissions?
[16:28] <jam> I'm really quite surprised
[16:28] <jam> I wonder if it is merging from lp: that is causing problems
[16:28] <vila> I had one submission passing without problem from lp earlier
[16:29] <jam> maybe it doesn't like "osx" in names
[16:29] <vila> what surprised me the most is that the submissions are successful while someone is *killing* a process (knowing what process may help though)
[16:30] <jam> vila: I just pinged mthaddon, and he said he got it going again
[16:30] <vila> thanks to him and you, again...
[16:31] <vila> Most probably, bugs are a big family and some vendetta is going on each time I fix a nasty one :)
[18:05] <_MMA_> Command to upload *all* unknown files in a existing branch?
[18:05] <_MMA_> bzr add ?
[18:06] <beuno> yeap
[18:06] <beuno> well
[18:06] <beuno> depends on your definition of *all*
[18:06] <beuno> add won't add ignored files
[18:06] <_MMA_> Anything shown as "unknown".
[18:07] <beuno> yeap
[18:07] <beuno> bzr add
[18:08] <_MMA_> Oh. I thought it had to have something after "add". Like "bzr add all" or something. :)
[18:08] <_MMA_> cool
[18:11] <beuno> nope nope, it's the default
[18:11] <beuno> you have to add something if you *just* want to add one file
[18:12] <_MMA_> I see.
[18:49] <idx_foo> Installing bzr for eclipse, I have bzr, jdk, eclipse and xml plugin of correct versions.
[18:50] <idx_foo> In Window -> Preferences, turning on icon decorators causes "An error has occured. See error log for details"
[18:50] <Verterok> idx_foo: did you configured the bzr executable in Preferences --> Team --> Bazaar?
[18:51] <idx_foo> When trying to share a project, I choose a bzr path, click next, it flashes up a progress dialog very quickly, then does nothing.
[18:51] <idx_foo> Verterok: yes, to /usr/bin/bzr
[18:51] <idx_foo> bzr works fine, and the --xml option does too.
[18:51] <Verterok> idx_foo: which version of bzr-eclipse and xmloutput?
[18:52] <Verterok> also, what is the name of xmloutput plugin folder in .bazaar/plugins ?
[18:52] <idx_foo> bzr_xmloutput_0_8_0
[18:52] <Verterok> (it should be xmloutput)
[18:52] <idx_foo> bzr eclipse 1.1.0
[18:52] <idx_foo> oh
[18:52] <idx_foo> I'll try that
[18:53] <Verterok> idx_foo: rename bzr_xmloutput_0_8_0 to xmloutput :)
[18:54] <idx_foo> nope
[18:54] <idx_foo> Now the error doesn't happen in the pref window
[18:55] <idx_foo> But still can't share the project
[18:55] <idx_foo> I'll be back later
[18:56] <Verterok> idx_foo_away: when you come back, please check the log at <workspace>/.metadata/.log
[19:01] <Stavros> hello
[19:01] <Stavros> my repo is in knit4 format and i need to upgrade, which is a good format to use?
[19:01] <beuno> Stavros, packs 0.92 if you're not into any weird stuff
[19:01] <Stavros> beuno: does sodomy count?
[19:02] <beuno> well, weird is a very dodgy concept
[19:02] <beuno> I'd say, go with packs, and if something doesn't work, you can always change again  :)
[19:02] <Stavros> that doesn't work
[19:02] <Stavros> bzr: ERROR: Cannot convert to format <RepositoryFormatKnitPack1>.  Does not support rich root data.
[19:02] <beuno> ah
[19:02] <beuno> rich root
[19:02] <Stavros> and it broke my repo
[19:02] <Stavros> good thing it made a backup
[19:03] <Stavros> what's rich root?
[19:03] <beuno> bzr makes backups when upgrading
[19:03] <beuno> bzr.backup/
[19:03] <Stavros> i moved it back and it works
[19:03] <Stavros> but no upgrade
[19:03] <Stavros> why do i have this rich root?
[19:03] <beuno> Stavros, I think you have to do bzr upgrade --rich-root-pack
[19:04] <Stavros> ôçáô óååìó ôï çáùå òïñêåä, ôçáíêó
[19:04] <Stavros> ñåñ
[19:04] <Stavros> damn
[19:04] <Stavros> that seems to have worked, thanks
[19:07] <nihilocrat> hello
[19:09] <nihilocrat> I'm having an issue with several of my projects... there are some files that constantly have conflicts (they are binary and necessarily changed every commit)
[19:09] <nihilocrat> I solve them by just copying *.OTHER over the original file and resolving it
[19:09] <nihilocrat> but in some cases I am getting conflicts where it says some file called <filename>.OTHER.OTHER.OTHER<etc> is conflicted
[19:10] <nihilocrat> I have no idea how that happens and how to get it to go back to just being <filename>.OTHER
[19:10] <beuno> nihilocrat, are you running "bzr resolve FILENAME" after you copy the file over the existing one?
[19:11] <nihilocrat> yes
[19:11] <nihilocrat> here's what I usually do:
[19:11] <nihilocrat> mv file.OTHER file
[19:11] <nihilocrat> resolve file
[19:11] <nihilocrat> *bzr resolve
[19:11] <beuno> and then you commit?
[19:11] <nihilocrat> the mv is just normal old mv
[19:12] <nihilocrat> no, I don't commit, usually it's the case where this is a working copy that I'm pushing to
[19:12] <nihilocrat> (web app code)
[19:13] <beuno> I see, the remote branch is the one with .OTHER.OTHER...?
[19:13] <nihilocrat> yeah
[19:14] <nihilocrat> usually I push, and then update
[19:14] <nihilocrat> and then the conflicts appear
[19:14] <beuno> yes, that's happened to me
[19:14] <beuno> I'm not exactly sure why that happens (I should probably look into it)
[19:14] <beuno> but, what I have to do, is resolve them remotely, and commit
[19:14] <nihilocrat> due to annoying firewall configuration that can't be changed, I can't just bind to the master branch and update
[19:14] <nihilocrat> I have to push
[19:14] <nihilocrat> ok
[19:14] <beuno> it only happens sometimes
[19:15] <nihilocrat> hmm
[19:15] <beuno> so, I haven't needed to look into it too much
[19:15] <nihilocrat> I might try resolving, committing, then pulling
[19:15] <beuno> I'd also recommend running "bzr reconcile" on the remote branch
[19:15] <nihilocrat> see if it at least gets rid of OTHER.OTHER.OTHER
[19:15] <nihilocrat> oh
[19:15] <nihilocrat> never heard of that command
[19:15] <nihilocrat> I'll look into it
[19:15] <beuno> nihilocrat, make sure the remote repo is clean and resolved, commit, resolve
[19:16] <beuno> and pull
[19:16] <beuno> should work well from then on
[19:16] <nihilocrat> ok
[19:16] <idx_foo> Ok, so I'm installing bzr eclipse, but when I go to Team > Share Project, at the Select Directory screen, "Finish" pops up a progress bar that dissapeares quickly, and doe not xlose the wizard. The project cannot be shared as a result.
[19:17] <Verterok> idx_foo: go to preferences -> team -> bazaar
[19:17] <idx_foo> yes
[19:18] <idx_foo> done
[19:18] <Verterok> idx_foo: there is textfield to speficy the port of the xmltpc service, and just above it a label that indicate what kind of client was detected
[19:18] <idx_foo> XmlRpcClient
[19:18] <Verterok> so far so good :)
[19:18] <idx_foo> Recheck changes nothing
[19:19] <Verterok> that means that the xmloutput is correctly installed
[19:19] <idx_foo> Btw, before hand to check bzr from the terminal I did "bzr init" and then "bzr add somefolder"
[19:19] <Verterok> idx_foo: np, thanks ok
[19:19] <idx_foo> Successfully, but I don't know how  that will change Eclipse's behaviour
[19:19] <Verterok> idx_foo: please check the log file at <workspace>/.metadata/.log
[19:20] <Verterok> idx_foo: that should not affect eclipse
[19:20] <Verterok> idx_foo: of open the error log view if you have de SDK
[19:20] <idx_foo> what SDK is this
[19:20] <idx_foo> I have .log open in gedit now, rather huge though
[19:21] <idx_foo> I'm getting "java.lang.NoClassDefFoundError: org/eclipse/jface/viewers/BaseLabelProvider"
[19:21] <Verterok> yeap, it grow and grow, until you zap it
[19:21] <Verterok> idx_foo: what version of eclipse?
[19:21] <idx_foo> 3.2.2
[19:21] <idx_foo> On Ubuntu 8.10
[19:21] <idx_foo> 8.04 even
[19:21] <Verterok> bzr-eclipse only works with >= 3.3
[19:21] <idx_foo> Heh
[19:22] <idx_foo> Lets hope there's a deb of 3.3 somewhere
[19:22] <idx_foo> So in other words Ubuntu's repository is rubbish
[19:22] <idx_foo> Sorry about that, must have skimmed over the Eclipse req.
[19:22] <Verterok> idx_foo: I don't think so :(, but installing eclipse is just unzip/untar the archive
[19:23] <Verterok> idx_foo: I think all debian based distros lacks an updated eclipse
[19:23] <Verterok> idx_foo: np :)
[19:24] <Verterok> idx_foo: there is Bug #123064
[19:25] <idx_foo> Any other good IDEs with bazaar integrated?
[19:25] <idx_foo> For Linux that is
[19:28] <Verterok> idx_foo: just download the lastest version from eclipse.org, unzip and run :)
[19:28] <Verterok> idx_foo: I think gedit is integrated with bzr
[19:28] <beuno> idx_foo, https://edge.launchpad.net/bzr-gedit
[19:28] <beuno> hi Verterok
[19:29] <Verterok> idx_foo: also, PIDA for a list of all: http://bazaar-vcs.org/IDEIntegration
[19:29] <Verterok> beuno: hey there!
[19:30] <idx_foo> Working fine now. Thanks for the help Verterok
[19:30] <Verterok> np :)
[19:30] <idx_foo> I just hope this is sufficiently different/better than svn to warrant the switch
[19:31]  * Verterok invites idx_foo to file bugs as he encounter them :)
[19:31] <idx_foo> But is failing miserably when installed on the wrong version of Eclipse a bug, or a deterent? :)
[19:31] <Verterok> idx_foo: bzr-eclipse is under active development, but the basic workflows are covered
[19:33] <Verterok> he left :p
[19:39] <rockstar> jam, want to do TWiB in an hour?
[20:19] <jelmer> rockstar: hi
[20:20] <persia> Hi.  I've started to use bzr a lot lately, and wanted to ask about the chances of a much more stupid algorithm for pulling/pushing/merging to help speed up my use case.
[20:20] <jelmer> hi persia
[20:20] <jelmer> persia: what's your use case?
[20:20] <persia> Hi jelmer.
[20:21] <persia> I've *lots* of bandwidth (gigabit fibre ethernet to the international routers), but also lots of latency (about 150-200ms to launchpad).
[20:21] <persia> For protocols like FTP and HTTP, I get to take advantage of increasing TCP windows, and get lots of packets in flight.
[20:22] <persia> This means I get to use 2-3Mbps of bandwidth at that latency.
[20:22] <persia> For bzr, it seems there are *lots* of little transactions, trying to save me bandwidth, but each one starts with a small TCP window, and with my latency, it makes it *very* slow.
[20:23] <persia> So, what I'd like is some switch I can pass to tell bzr to be stupid, and just grab the entire repo on the other end as one big upload/download, and then process it afterwards.
[20:23] <jelmer> persia: there's a lot of incremental work going on trying to reduce the number of round trips
[20:24] <persia> OK.  That helps some.  Is that related to work to make it push more per trip?
[20:24] <beuno> persia, one thing to make sure is that you're using packs format (you probably are if the repos are new enough)
[20:24] <persia> Unless I'm downloading a few megabytes, I haven't a chance of reaching reasonable transit speeds.
[20:24] <jelmer> persia: for the smart server, yes
[20:25] <jelmer> persia: for FTP and HTTP a flag like the one you describe could indeed help
[20:26] <jelmer> (I'm in the same situation btw, although my latency isn't as bad as yours)
[20:26] <persia> Well, generally, those are just one big file.  websites that have *lots* of little files to try to make it feel faster for people with low bandwidth or low latency are slow for me though.
[20:27] <beuno> persia, the core devs are almost all in australia. That puts their focus on latency quite a lot  :)
[20:27] <persia> Yeah.  My combination of bandwidth and latency seems to be a corner case, and as I've spent 3 hours waiting for bzr to do stuff today, I figured I'd come by and see if I could publicise my use case to make it faster.
[20:28] <beuno> the flag for bigger chunks in http/ftp does sounds interesting
[20:28] <persia> Well yes, but the situation in Australia is different: nobody has much more than maybe 10Mbps there, and the undersea trunks are usually congeste.
[20:28] <persia> s/.$/d./
[20:28] <beuno> true
[20:29] <beuno> persia, feel compelled enough to start a thread in the mailing list?
[20:29] <persia> So they focus on latency, but can't take advantage of TCP windows like here or in Korea.
[20:29] <persia> beuno: I could, if it's likely.  I don't know how many bzr LP users are in Japan or Korea, and I don't think this environment is common anywhere else.
[20:30] <persia> Also, what's the mailing list?
[20:30] <jelmer><EMAIL_ADDRESS>[20:32] <persia> OK.  Is there likely to be space in the development queue that optimising for such a situation is likely, or is it more interesting to focus on other use cases for now, and I should test again with 1.7 or 1.8 and start a thread then?
[20:32] <persia> (feel free to remove any duplicate words when parsing)
[20:36] <beuno> persia, speed is the main focus ATM I believe
[20:36] <beuno> so this sounds entirely appropriate
[20:37] <persia> OK, then adding my use case is probably worthwhile.  I'll send an email during my next pause.  Thanks :)
[20:37] <beuno> :)
[20:46] <pygi> hi hi
[20:49] <AmanicA> I made a super cool linux startup script for loggerhead today. Do markh/beuno think I should make a branch/patch adding it to the mainline?
[20:53] <beuno> AmanicA, merge proposal!
[20:53] <beuno> yes  :)
[20:53] <AmanicA> beuno, like in branch or like in bundle?
[20:54] <beuno> AmanicA, branch
[20:55] <beuno> and file a merge proposal in Launchpad
[20:55] <AmanicA> beuno, atm I call the script loggerheadd  (the double dd is not a typo) and I added it to the root. is that ok?
[20:55] <AmanicA> beuno: cool will do. hope I dont overhelm you guys, but I was itching a lot this week :)
[20:56] <beuno> AmanicA, I'd try and name it something less confusing  :)
[20:56] <beuno> and, the rest you can get from the review
[20:56] <beuno> AmanicA, we *love* contributions
[20:56] <AmanicA> beuno: any ideas?
[20:56] <AmanicA> cool:)
[20:56] <beuno> we sometimes suck on responding in a proper time frame, but we really love 'em
[20:56] <beuno> AmanicA, what does the script do exactly?
[20:57] <AmanicA> its a /etc/init.d script
[20:57] <AmanicA> (and lots of them end in d for daemon)
[20:57] <beuno> I see
[20:57] <beuno> hm, tough call
[20:57] <beuno> I'd say, file it as "noname", and we can go through it during the review
[20:58] <AmanicA> ah, then I can tust leave it like is, and if the reviewer have a bettername, we can update it :P
[20:59] <AmanicA> s/tust/just/
[20:59] <beuno> sure
[21:00] <AmanicA> any idea when launchpad will support stacking properly? as its a bit of overhead to upload branches for single file changes..
[21:00] <beuno> AmanicA, well, it sort-of does now
[21:01] <beuno> if we upgrade the loggerhead branch to 1.6 format
[21:01] <beuno> you should be able to stack
[21:01] <AmanicA> oh, so not ATM :(
[21:01] <beuno> let's wait for mwhudson to come by, and ask him if he's cool with that
[21:01] <AmanicA> no rush, I just wondered
[21:01] <beuno> well, I've stacked things
[21:01] <AmanicA> loggerhead is luckily small
[21:01] <beuno> it has some gotchas
[21:01] <beuno> but it works
[21:02] <beuno> and I'd love to have more people test it
[21:02] <AmanicA> I'm thinking uploading bzr branches could get hecktick
[21:03] <AmanicA> bzr i.e. bzr.dev.my_fix etc.
[21:03] <beuno> yeap yeap
[21:03] <beuno> it's going to be very usable very soon
[21:04] <AmanicA> can hardly wait:)
[21:05] <blueyed> jelmer: about bzr-shell-hooks: do you think it makes sense to chdir() to the branch root, before executing the command?
[21:08] <jelmer> blueyed: sure
[21:09] <blueyed> jelmer: how do I get the directory from branch? (or the other way around: can you just add it? :))
[21:16] <jelmer> blueyed: branch.base IIRC
[21:17] <uws> wow, bzr is quite fast!
[21:17] <uws> committing 2000 new files takes only a few seconds
[21:18] <uws> i now use it for "scratch" version control. putting temp data in bzr, and removing .bzr once in a while if i made sure I didn't screw up :)
[21:20] <blueyed> jelmer: yes. and then, I should probably not use urlutils._posix_local_path_from_url directly?!
[21:21] <rockstar> jelmer, hi back (sorry, went out to eat some lunch)
[21:22] <jelmer> blueyed: branch.transport.local_abspath(".") should work I think
[21:23] <jelmer> rockstar: I've finished exporting the bindings of bzr-svn - https://edge.launchpad.net/subvertpy
[21:23] <rockstar> jelmer, you used the name!  Yippee!
[21:23]  * rockstar feels like he contributed.
[21:25] <blueyed> jelmer: great, it works. I'll add that only for the "local" part, i.e. if branch gets set to "local", not when it gets set to "master".. I suppose the latter is for remote operations?!
[21:25] <jelmer> blueyed: no, it's for checkouts
[21:29] <blueyed> jelmer: ok, so I'll add it for both cases.. however, only when branch.transport is given. Since, on "uncommit" it isn't given..
[21:29] <blueyed> the backtrace then: http://pastebin.com/m6dd9b59e
[21:31] <jelmer> blueyed: try branch.bzrdir.root_transport instead
[21:33] <AmanicA> sheweet, I made the loggerhead top five contributers list!   (without even trying)
[21:37] <rocky> jelmer: now you just need to convert trac to use it ;)
[21:39] <AmanicA> rocky: :) yup (you know Ive made a gforge plugin which uses)
[21:39] <AmanicA> it
[21:39] <rocky> AmanicA: hmmm?
[21:39] <AmanicA> neveermind
[21:41] <blueyed> jelmer: works better. now I'm wondering why 'pre_commit = sh -c "echo \$4 > blogs/inc/_revision.inc.php"' results in 'bzr: ERROR: [Errno 2] No such file or directory'.. something simple like "echo" works..
[21:47] <jelmer> rocky: it can already do that through trac-bzr and bzr-svn ;-)
[21:47] <rocky> boo =P
[21:48] <jelmer> blueyed: not sure if that escaping will work ok
[21:48] <blueyed> jelmer: ok, that's a problem with subprocess.call, which uses the whole command as-is (and it does not exist), would have to pass ["sh", "-c", "..."] + args
[21:49] <blueyed> ..but cannot put that in the config (as list)
[21:57] <blueyed> jelmer: it would work with shell=True for subprocess.call
[22:14] <jam> persia: still around?
[22:14] <jam> There may be a somewhat trivial hack you can do to rebalance one of our algorithms
[22:14] <persia> jam: That's exactly the sort of thing I hoped was true :)
[22:14] <jam> persia: bzrlib/transport/http/__init__.py
[22:15] <jam> around line 344
[22:15] <jam> is "recommended_page_size()"
[22:15] <jam> we currently set it to 64kB
[22:16] <lifeless> persia: we should be keeping one tcp connection open
[22:16] <lifeless> persia: what protocol are you using?
[22:16] <persia> lifeless: No idea.  I do bzr branch lp:... and bzr push lp:...
[22:17] <persia> jam: SO I could just bump that to a couple megabytes, and I'd be happy?
[22:17] <lifeless> persia: if you've authenticated, and you probably have both will be over bzr+ssh
[22:17] <lifeless> persia: so per bzr command the windows should be expanding as normal; modulo ssh window bugs (have been before, bet there will be again)
[22:18] <lifeless> persia: if you're running lots of commands, try setting up a master control connection which may help the windows expand
[22:18] <persia> lifeless: OK.  Then my guess at the cause is probably wrong.  Still takes *way* longer than it ought, and I thought my situation might be odd enough that a hack would help, when it wouldn't help others.
[22:19] <lifeless> persia: it may be right; gather some stats:P
[22:19] <persia> No, I don't run lots of commands.  I branch.  I push.  I forget about it.  A few days later, I delete the cruft.
[22:19] <lifeless> persia: I'm simply noting that we won't, per-command, be connecting many many times; 2 perhaps - directory lookup + ssh for data
[22:21] <persia> lifeless: That's all?  Which version of bzr?  (I use 1.3)
[22:22] <lifeless> persia: should be any for this use case
[22:23] <persia> lifeless: OK.  Thanks.  I'll try jam's hack anyway, and see if it helps me.  Maybe I'm just confused.
[22:24] <jam> persia: well depends how you are connecting. my change won't effect bzr+ssh (as it only effects http)
[22:24] <persia> Oh, and I'm probably usually using bzr+ssh.  Oh well.
[22:25] <jam> You might set the one in "bzrlib/transport/remote.py" though
[22:26] <lifeless> or you could try out a btree repo :P
[22:26] <jam> lifeless: I think btree would actually exacerbate his specific problem, as it doesn't have the concept of minimum request size
[22:26] <jam> we haven't hooked in recommended_page_size() handling
[22:26] <jam> though I think we could do so at logical-block partitions in the Btree index code
[22:26] <jelmer> is there some way to peek at the smart server commands?
[22:26] <jam> which avoids some of the inefficiencies in our current system
[22:27] <lifeless> jam: I don't think he's identified the problem, just assumed that his network configuration implied a specific issue
[22:27] <jelmer> wireshark doesn't work so well at ssh connections?
[22:27] <jam> jelmer: -Dhpss ?
[22:27] <jam> gives a log of every request
[22:27] <jelmer> jam: ah, thanks
[22:27] <lifeless> jam: and as such, any test that expands our knowledge is helpful
[22:28] <jelmer> yeah, the number of roundtrips with hpss is really bad :-(
[22:29] <lifeless> jam: specifically, btree does less roundtrips often just cause of the better fan-out
[22:29] <persia> If someone wants to prepare a test script that does stuff, I'm happy to run it against either hardy or intrepid, and return the results.  On the other hand, I don't understand most of the recent conversation, so wouldn't know how to produce useful test results.
[22:29] <jelmer> it's the limiting factor for me, git seems CPU-bound
[22:33] <jelmer> at least this explains why bzr-svn is faster than bzr+ssh for me
[22:33] <jelmer> bbl
[22:36] <lifeless> persia: don't worry about it; we are testing on high latency stuff at the moment
[22:37] <uws> sftp:// feels faster than bzr+ssh:// for me even
[22:37] <uws> (no numbers to confirm/deny this)
[22:38] <uws> perhaps it's the overhead of starting a python process on my rather slow server
[22:38] <persia> lifeless: OK.  I just fear you're not going to notice throttling with the congestion in the cables down there :)
[22:42] <lifeless> uws: could well be
[22:51] <jam> uws: I know spiv just introduced a patch which patches a hole in the bzr+ssh case for push and pull
[22:51] <jam> basically, while we are inspecting,sftp/http will download some searching for things that aren't there and cache it
[22:51] <jam> bzr+ssh just returns an empty response
[22:51] <uws> jam: care to elaborate on what "patches a hole" means?
[22:52] <jam> uws: "fixes an edge case" ?
[22:52] <uws> oh, I thought "avoid the bzr startup overhead" :)
[22:52] <jam> so for push/pull we have to find out what each side doesn't have
[22:53] <jam> I guess for bzr+ssh if you have 50 new revisions it may actually send 50 requests and not get anything before it starts finding info
[22:53] <jam> while for http and sftp it will be filling in info about the indexes during that time
[22:53] <jam> which makes future correspondence faster
[22:54] <uws> mkay.
[22:54] <jam> basically, you can get 50 round trips with bzr+ssh that don't actually transmit any info
[22:54] <jam> which is a bit naughty
[22:54] <uws> ah, ok.
[22:55] <jam> well, they transmit1 bit of info
[22:55] <jam> "not there"
[22:55] <jam> rather than 64kB of "not there yet, but here is some other info"
[22:56] <jam> I take it back, I reviewed it, but it hasn't landed yet
[22:59] <jam> lifeless: I'll note that Index *bandwidth* is the number one issue right now for me doing "bzr up" in my bzr.dev branch.
[22:59] <jam> (this is specific to my case)
[22:59] <jam> I haven't nailed down all the reasons yet
[22:59] <jam> but I have the feeling we have non-clustered revsion-ids
[22:59] <jam> like "john@" and "pqm@"
[23:00] <jam> so it has to bisect a lot of the index, and it interacts in poor ways with the page expanding algorithm
[23:00] <lifeless> jam: right
[23:00] <jam> right now, if you make a request for 100-200, it expands to 100-64100
[23:00] <jam> but then if you request 50-100, it expands to 50-64050
[23:01] <jam> I'm thinking to not worry about it for GI, and just work on it a bit with the btree code
[23:01] <lifeless> jam: for sure
[23:01] <jam> But it means the expansion needs to occur at the index layer, rather than the Transport layer
[23:01] <lifeless> jam: having figured out that GI couldn't be really fixed without disk changes, I'm not going to touch it again; it will just throw something else out to do so
[23:02] <blueyed> I want to have the revision/revno in a textfile inside the branch and tried the pre_commit hook for this, but the changed file gets not committed. Is this possible after all? (or would I need to do this during deployment and keep it out of the branch)
[23:03] <jam> blueyed: there is a "start_commit" hook which you could use, but you won't have the revision_id
[23:03] <jam> (I think)
[23:04] <jam> I don't know that there is a way to commit a file with the text of the revision_id to come
[23:04] <jam> it is possible in bzr's structure, but I don't think we expose a hook at the right time for it.
[23:04] <lifeless> and we shouldn't
[23:04] <blueyed> jam: start_commit isn't defined with the shell_hooks plugin
[23:05] <lifeless> its incompatible with the minimal contract for foreign branch commit support
[23:05] <jam> lifeless: I agree that not all foreign formats could support it. I don't think that should absolutely prevent us from doing it
[23:06] <lifeless> jam: it should at a minimum make us question very hard
[23:06] <lifeless> jam: I don't think its a good idea regardless of foreign formats
[23:07] <jam> it is similar in concept to $Keyword$ expansion, and has similar benefits and drawbacks
[23:07] <blueyed> lifeless: it would be really handy to provide a $app_revision variable (that's what I was trying to do), or add a suffix like "rXX" to a version number.
[23:07] <jam> I think some people would rather get extra conflicts at certain times
[23:07] <jam> than not have the ability at all
[23:07] <jam> blueyed: you can always run "bzr version-info > my_file.txt" as part of a "build" process
[23:08] <jam> which is certainly the recommended way to do it
[23:08] <blueyed> jam: yes, I know.. that's what I've meant with "deploying".. it's a php app after all and there's no "build" process (and also no "deploying" currently).
[23:09]  * spiv hops on a train
[23:09] <lifeless> blueyed: doing that on tree building - checkout/pull - is much more reliable
[23:09] <blueyed> yes, I see. Thanks.
[23:09] <jam> blueyed: have you looked into what "bzr upload" supports? I haven't poked into that code, but it may be a good place to hook in that sort of work
[23:23] <blueyed> jam: well, I can see no hooks, but it creates a file .bzr-upload.revid, which could be used probably
[23:23] <jam> I'll also mention it is probably easier to get code into a plugin
[23:23] <jam> As it has a smaller system-wide effect
[23:24] <blueyed> sure. It was only a nice-to-have idea, no problem.. :)
[23:24] <beuno> blueyed, it does have a tip-change hook to auto-upload
[23:24] <beuno> provided by james_w in a patch  ;)
[23:28] <jam> blueyed: And on that note, you could use the "post-branch-tip-changed" hook to generate the file after commit
[23:28] <jam> but then the file isn't versioned.
[23:28] <blueyed> beuno: well, looked in the released version (Intrepid) only.. but found it now.. that's different however (and it's hooking, not being hooked AFAICS).. but I get the idea, that a post-upload hook might get added to the plugin. However, the hidden file would be enough in my case
[23:29] <beuno> blueyed, it's in intrepid???  :)
[23:29] <blueyed> yes.. as with pre_commit.. that would be the whole idea however (and is why the upload plugin does not fit really).. I'm fine with it after all..
[23:29] <blueyed> beuno: yes, 0.1.0~bzr44-1
[23:29] <beuno> oh, very cool!
[23:30] <beuno> I didn't know
[23:40] <jam> lifeless: it seems when you landed the btree format repository into bzr.dev, we lost the "convert indexes in place" code.
[23:40] <jam> which is a bit of a shame, as it makes it more difficult to set up a test repository
[23:41] <jam> does the code in the plugin still work?
[23:56] <lifeless> jam: the plugin code needs some adjustments, to use bzr's index logic etc
[23:57] <lifeless> jam: the reason I didn't port that code across is that for gc its not helpful; and I don't plan on suggesting that dev2 become a production format ever
[23:57] <jam> lifeless: sure, it just makes my life easier when trying to test stuff out :)
[23:57] <jam> I'm hacking around it now with a script
[23:59] <lifeless> back shortly, fooding