=== Ursinha is now known as Ursinha-afk
[01:05] <spiv> Good morning.
=== Ursinha-afk is now known as Ursinha
[01:41] <billy> hi folks - i'd like to use bzr for delphi projects but some files are binary - is bzr limited to text only data?
[01:42] <spiv> No, you can commit binary files too.
[01:42] <maxb> Not at all, other than the obvious problem that you can't merge binary files
[01:43] <maxb> But that's a problem with binary file formats, not a problem with bzr :-)
[01:43] <billy> thanks folks
[01:46] <poolie> hi there spiv, maxb
[02:15] <maxb> Hi poolie. I have a question about hydrazine. Shall I do a merge proposal to add lp-promote-ppa, or shall I just push it straight to trunk?
[02:15] <poolie> if you do an mp i'll read it
[02:15] <poolie> then you can merge it yourself
[02:16] <poolie> if i ever stall for too long please nag or circumvent me
[02:19]  * maxb wonders why bzr lp-propose complains of "bzr: ERROR: No reviewer specified
[02:19] <lifeless> bug thingy
[02:26] <poolie> somebody just duped it
[02:32] <lifeless> <-
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
[02:51] <poolie> maxb oh i just saw your mp
[03:01] <poolie> apparently the homepage feeds are failing to revalidate because the datacentre cache isn't revalidating them
[03:02] <billy> maxb: i don't follow your remark about obviously not being able to merge binary data - doesn't bzr generate a diff file - how is that handled?
[03:05] <spiv> billy: internally bzr has a database that can store binary deltas
[03:06] <spiv> billy: for sharing changes with other people you usually just tell them to access your branch directly, but bzr can also generate a "merge directive" that looks somewhat like a diff but copes with changes to binary files (and preserves all the bzr metadata).
[03:07] <ReachingFarr> OK, so I'm in the process of setting up my bzr server.  I currently have it running with the --directory option set to /data/bzr.  First question: should I do a bzr init-repo on /data/bzr?
[03:08] <billy> spiv: that's good - i assume maxb meant merging of branches which i don't need - i'm just tracking changes inn private development
[03:08] <spiv> billy: right
[03:09] <spiv> ReachingFarr: generally you make a repo for every project you are versioning.
[03:10] <ReachingFarr> spiv: OK.  Makes sense.  Next question: There is an option to specify the protocol when using 'bzr serve' but I don't see any list of options.  Are there any?
[03:10] <billy> another question - quite different - a project on sourceforge uses subversion - can i checkout the repository to my system using bzr?
[03:11] <billy> i don't really need every vcs on the planet installed - one is enough
[03:11] <lifeless> yes, install bzr-svn
[03:12] <billy> lifeless: is that a separate package or a plugin?
[03:12] <lifeless> yes
[03:12] <poolie> lifeless: quick squid qn
[03:12] <billy> thanks folks
[03:13] <poolie> the dc squid was always caching feedparser requests
[03:13] <poolie> which is reasonable given the heuristics
[03:13] <lifeless> its also for security
[03:13] <lifeless> known-bug-contact-point
[03:13] <poolie> if i change the client to send an i-m-s and/or etag, will it revalidate?
[03:13] <poolie> you mean having a squid at all is a security measure? yes, that's fine
[03:14] <lifeless> to force revalidation?
[03:14] <poolie> i realize the answer depends on the particular setup
[03:14] <lifeless> or to permit revalidation ?
[03:14] <poolie> at the moment the client sends no cache control headers and it does not revalidate
[03:14] <poolie> if i set pragma: no-cache it respects that
[03:14] <poolie> what i want to know is if i send i-m-s will it probably revalidate?
[03:14] <lifeless> squid will be revalidating internally based on the age heuristic from the upstream
[03:15] <poolie> does i-m-s affect that?
[03:15] <lifeless> a few things do
[03:15] <lifeless> I'm just listing them
[03:15] <ReachingFarr> Also, how do people tend to secure their bzr servers? I'd really like to use the smart server AND have write access.
[03:15] <lifeless> patience ;)
[03:15] <lifeless> ReachingFarr: most folk use bzr+ssh
[03:16] <lifeless> poolie: so, a plain GET requires the objet to be fresh, or squid revlaiadates; IMS IIRC will be exactly the same, but squid can tell you Not-modified if it isn't changed.
[03:16] <lifeless> poolie: if you're trying to trigger revalidation, you should use
[03:16] <lifeless> max-age
[03:17] <lifeless> or similar
[03:17] <poolie> or must-revalidate?
[03:17] <lifeless> right
[03:17] <lifeless> do you have the response headers?
[03:17] <spiv> ReachingFarr: the only options for protocol at the moment are 'bzr' (the default) and 'svn' (if you have the bzr-svn plugin installed), which is still somewhat experimental I think.
[03:17] <lifeless> from a request where squid did not revalidate ?
[03:17] <spiv> ReachingFarr: often people don't need 'bzr serve' at all
[03:18] <lifeless> poolie: and, what are the symptoms/problem you're fixing
[03:18] <spiv> ReachingFarr: if you have bzr and ssh installed on the server then bzr+ssh is usually the simplest and best solution.
[03:18] <spiv> ReachingFarr: so the URLs would look like bzr+ssh://server/data/bzr/...
[03:19] <poolie> lifeless: the symptom is that new feed entries don't show up
[03:19] <lifeless> poolie: at all, or for <time period> ?
[03:19] <poolie> for over a day
[03:19] <lifeless> ok
[03:19] <poolie> the prior change to the feed was in july
[03:19] <poolie> and the returned headers give that as the l-m
[03:19] <lifeless> a response header from squid when it should have updated but hasn't can be very useful
[03:20] <lifeless> squid will include in there the original l-m, and *its* status about age and freshness
[03:20] <poolie> so it's kinda reasonable for it to think it's a slowly-changing resource, but i do want max-age like behaviour
[03:20] <lifeless> poolie: I'd set max-age
[03:20] <poolie> X-nc: HIT ord 20
[03:20] <poolie> Age: 233704
[03:20] <poolie> Content-Length: 40088
[03:20] <poolie> X-Cache: HIT from druzhnaya.canonical.com
[03:20] <poolie> X-Cache-Lookup: HIT from druzhnaya.canonical.com:3128
[03:20] <ReachingFarr> spiv: Is there no way to set a base directory for use with bzr+ssh?  I know it's not much, but I'd like to not have to type /data/bzr
[03:20] <lifeless> whee that is old
[03:21] <poolie> ok
[03:21] <poolie> so feedparser doesn't directly expose a way to set that, or to give arbitrary headers
[03:21] <poolie> but i'm sure there is a way
[03:21] <poolie> that's why i was wondering if something else might get the same behaviour
[03:21] <poolie> but it'd actually be a bit of a kludge, and cache control is better
[03:21] <lifeless> pretty sure neither ims nor etag wil
[03:22] <lifeless> becuase they are all about getting NM back to the client, rather than triggering/avoiding squid doing work
[03:23] <spiv> ReachingFarr: if you use a separate SSH key (and user, if you like) for accessing the server's bzr repo, then you can arrange that via the authorized_keys file and a script from bzr's contrib directory: http://doc.bazaar.canonical.com/bzr.2.2/en/admin-guide/security.html#access-control
[03:23] <spiv> ReachingFarr: although bzr will tend to remember locations for you, so you don't necessarily need the full URL very often
[03:24] <lifeless> or chroot the ssh server
[03:24] <ReachingFarr> spiv: Ya, I was thinking of all of the times I would have to type in the full path... and it turns out it isn't that often.  I have now been convinced to use bzr+ssh instead of messing with this server stuff.
[03:24] <lifeless> run it on a different ip / port
[03:24] <spiv> ReachingFarr: another option is to make a simple client-side plugin to provide a shortcut like "foo:...", e.g. like how bzr comes with the Launchpad plugin which (among other things) provides the "lp:" shortcuts
[03:25] <lifeless> spiv: I think a very useful thing we could do is /etc/bazaar/bazaar.conf
[03:25] <lifeless> spiv: it would let us have a place to configure stuff like this
[03:25] <spiv> lifeless: yes, that would be nice I think
[03:25] <spiv> Or possibly /etc/bazaar/serve.conf?
[03:26] <lifeless> spiv: or both
[03:26] <spiv> Right.
[03:26] <lifeless> spiv: /etc/bazaar/bazaar.conf as an underlay for ~/.bazaar/bazaar.conf would be a nice small self contained patch
[03:27] <lifeless> with benefits immediately
[03:27] <lifeless> ditto ignores
[03:27] <spiv> lifeless: yeah, that's what I was thinking
[03:28] <lifeless> server stuff could be a [server] section
[03:28] <spiv> Well, without necessarily assuming it would be a small self-contained patch ;)
[03:28] <lifeless> or a separate file
[03:28] <spiv> But you're probably right.
[03:30] <poolie> wbn; i filed a bug for this
[03:31] <poolie> sigh, apparently only a monkey can do it
[03:32] <lifeless> poolie: ?
[03:32] <poolie> apparently the only way to get extra headers in is to monkeypatch it
[03:33] <poolie> "it" being feedparser, or urllib2
[03:33] <poolie> oh i guess i could get the rss myself and pass that in
[03:33] <poolie> that would be a bit cleanecr
[03:49] <lifeless> presumably it would be a nice feedparser feature to do this for other folk
[03:50] <poolie> it would be nice, but then i'd need it packaged and deployed to run on escudero
[03:50] <poolie> i guess we could run it from a branch
[03:51] <lifeless> poolie: I can't see a bug for /etc/bazaar/bazaar.conf
[03:51] <lifeless> https://bugs.edge.launchpad.net/bzr/+bug/348640 is related but not it
[03:51] <ubot5> Launchpad bug 348640 in Bazaar "Want a variable to override location of ~/.bazaar etc (affected: 0, heat: 0)" [Low,Confirmed]
[03:52] <poolie> bug 419854
[03:52] <ubot5> Launchpad bug 419854 in Bazaar "should have a system-wide configuration file (affected: 1, heat: 5)" [Medium,Confirmed] https://launchpad.net/bugs/419854
[03:53] <poolie> i think you're right though
[03:53] <poolie> it's possible to patch it in, but it's a bit gross
[03:53] <poolie> i can't believe other people don't want it too
[04:09] <lifeless> poolie: specifically, technically, you want s-max-age, I don't know if thats supported by the squid you're connecting through
[04:11] <poolie> s-maxage
[04:11] <poolie> what do i want about that that max-age won't do?
[04:12] <lifeless> just correctness
[04:12] <lifeless> pedanticness
[04:16] <poolie> feedparser boasting "4000 unit tests" is less impressive if 32 fail in a checkout of tip :)
=== timchen1` is now known as nasloc__
[04:25] <lifeless> _lol_
[04:37] <poolie> though tbf most may be just lack of isolation, like they assume (but don't document) they're run in utc
=== Ursinha is now known as Ursinha-zzz
[05:22] <poolie> hi spiv, what are you up to?
[05:41] <spiv> poolie: I had an idea about deleting some cruft from TestCase, which appears to work although without noticeably speeding tests up.  Just submitting that now.
[05:41] <spiv> poolie: and managed to figure out why the python-profiler package's postinst was failing on my system
[05:41] <poolie> that sounds good
[05:41] <poolie> oh, why?
[05:41] <spiv> I have a /usr/local/bin/python2.7
[05:42] <spiv> So the postinst assumes that because there's a python2.7 on the path that /usr/lib/python2.7/py_compile.py must exist.
[05:42] <lifeless> har har har
[05:43] <poolie> but it was an orphaned binary?
[05:46] <poolie> deleting cruft is always good for its own right i suppose
[05:46] <poolie> i'd like to look at removing some more of the weird testcase subclasses in favor of asking for the resources the test actually needs
[05:46] <poolie> through fixtures or something similar
[05:47] <spiv> Well, I have local installation of python2.7 from the upstream SVN (via bzr) branch, for testing and hacking purposes.
[05:47] <spiv> At the time I started doing that python2.7 wasn't packaged, I think.
[05:48] <spiv> I could install it into my home directory I suppose, but GNU stow has served me well until now...
[05:49] <spiv> +1 on removing clumsy TestCase hierarchies in favour of something like fixtures.
[05:49] <lifeless> lp:python-fixtures. have at it.
[05:54] <poolie> ok
[05:54] <poolie> i'm trying to write a test for the feedparser patch
[05:56] <spiv> Ok, submitted.  I'm going to have a quick stab at https://bugs.edge.launchpad.net/bzr/+bug/619872 because I think it should be easy to do.
[05:56] <ubot5> Launchpad bug 619872 in Bazaar "bzr: ERROR: exceptions.ValueError: tag/value separator not found in line '' reading lockdir info file (affected: 1, heat: 6)" [Medium,Confirmed]
[05:56] <poolie> that would be nice
[05:56] <poolie> if you can work out what case makes it fail
[05:57] <thumper> should this work? bzr cat lp:bzr/trunk/bzrlib/tests/test_log.py
[05:57] <poolie> i'd really like to progress the locking thing this week
[05:57] <poolie> thumper: ought to; i think there's a bug and you need to give -d
[05:57]  * poolie wonders if bicyclerepair works in mavericj
[05:59] <spiv> Well in general we shouldn't traceback just because the lock file has malformed rio
[06:01] <poolie> spiv true
[06:03] <poolie> oh wow
[06:03] <poolie> it registers the tests to run by setattr-ing them onto unittest.TestCase
[06:03] <poolie> that's creative
[06:04] <poolie> sorry, no, onto it's own testcase, that's not so bad
=== jamesh_ is now known as jamesh
[06:54] <poolie> done
[07:19] <poolie> spiv, re the logs, i think i made it a file so that we could more easily redirect external processes into it
[07:29] <vila> hi all !
[07:34] <AfC> How do you do `bzr status` in a specific directory without it recursing down?
[07:34] <AfC> $ bzr status .
[07:34] <AfC> isn't it.
[07:57] <spiv> poolie: I thought so, but AFAICT we aren't using that... external processes will log into the test_home_dir/.bzr.log, which isn't the same as self._test_log_file (which is a mkstemp file with 'testbzr' prefix)
[08:00] <spiv> And nothing outside of TestCase uses the ._log_* attributes, except for the one test_setup test I updated.
[08:03] <johnf1> I'm getting a weird error without much google love - NoSuchRevision: CHKInventoryRepository('bzr+ssh://bzr@bzr/.bzr/repository/') has no revision johnf@inodes.org-20100902070043-0hximuhab4del54e
[08:03] <johnf1> on the remote end I'm using ssh keys to run bzr server in /srv/bzr/foo
[08:04] <johnf1> I have done cd /srv/bzr/foo; mkdir repo
[08:04] <johnf1> cd repo; bzr init-repository .
[08:04] <johnf1> I can then on my laptop create a bzr repor and push it to the server. I can then check it out
[08:04] <johnf1> when I try to commit to the checkout I get an error like the one above
[08:06] <spiv> That rings a bell
[08:09] <spiv> Which versions of bzr?  Any stacking involved?
[08:09] <johnf1> spiv: No stacking and I upgraded both sides to 2.2
[08:09] <johnf1> actually server was alway 2.2 and I just moved client to 2.1
[08:09] <johnf1> didn't make any difference though
[08:10] <spiv> What was the client using?
[08:10] <johnf1> sorry moved client from 2.1 to 2.2
[08:10] <spiv> Ah ok
[08:10] <spiv> pastebin the full traceback?
[08:14] <johnf1> one sec
[08:15] <johnf1> spiv: http://pastie.org/1133240
[08:15] <spiv> Oh hello:   File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/verify_whoami/__init__.py", line 13, in pre_commit_verify_whoami_hook
[08:16] <spiv> That plugin may be tripping over something like https://bugs.edge.launchpad.net/bzr/+bug/574226
[08:16] <ubot5> Launchpad bug 574226 in Bazaar "repository.fetch(same_url_repository, revision_id=revision_added_after_write_lock) fails (affected: 1, heat: 1)" [Wishlist,Confirmed]
[08:16] <johnf1> ahh thanks
[08:17] <johnf1> should have thought to turn off plugins
[08:17] <johnf1> yes, works fine with --no-plugins
[08:19] <spiv> I *think* get_revision(future_revid) is not expected to work during pre_commit
[08:25] <spiv> It'd be kind of nasty, but I am tempted to introspect the traceback when we exit with an error and if any stack frames involve a plugin tell the user to try --no-plugins.
[08:26] <spiv> Although in the case of running hooks we can probably avoid the introspection and at least make it clear that the error occurred while running a $foo hook from $plugin.
[08:26] <maxb> Are there any environment variables which will suppress the extra strictness of requiring 'bzr whoami' in 2.2?
[08:26] <maxb> I am wondering what etckeeper should do
[08:26] <spiv> You can set a value in the branch.conf IIRC
[08:28] <maxb> Would that be overridden by any per user settings?
[08:28] <maxb> etckeeper actually works best if it *does* get a guessed username in there
[08:30] <spiv> Hmm, no, setting email = ... in branch.conf will override the user.
[08:31] <spiv> (And putting an email address in .bzr/branch/email overrides *that*)
[08:34] <maxb> ah, I think I see, etckeeper needs to grow a special case to export BZR_EMAIL in /etc/cron.daily/etckeeper, like it exports HGUSER for hg
[08:49] <spiv> That sounds plausible.
[10:05] <poolie> yay, the homepage feeds finally update correctly
[10:15] <poolie> hi vila
[10:15] <vila> poolie: hello
=== zyga is now known as zyga-afk
[12:12] <ddaa> The bzr-keywords project on lp is owned by Ian Clatworthy.
[12:13] <ddaa> Is there any plan yet about transferring ownership of this?
[13:25] <ddaa> What is the expected release date of bzr 2.3?
[13:34] <vila> ddaa: 2.3 should be released in about 6 months
[13:36] <ddaa> vila: thanks
[13:37] <ddaa> In the help of "bzr tag", I see "Tags are stored in the branch.". I remember when poolie first hacked tag support in, they were a property of the repository, not branches. Was that changed?
[13:38] <ddaa> Or maybe did I misunderstand.
[13:38] <vila> They are stored in .bzr/branch/tags
[13:39] <ddaa> So, that means tags should only refer to revisions in the branch ancestry, right?
[13:40] <vila> I don't know tags very well, I'm not sure they *are* constrained to the branch history
[13:41] <vila> There may be bugs too
[13:41] <ddaa> I would not expect they are constrained by the system.
[13:42] <ddaa> But e.g. if one puts a tag to a diverged release revision into trunk, without merging the actual revision, there would be no guarantee that the tagged revision would be accessible.
[14:40] <jam> vila: about https://code.launchpad.net/~jameinel/bzr/2.3-bzr-connect-ssh/+merge/34331
[14:40] <jam> I think we still disagree about what is going on
[14:40] <jam> and I'd like to sort it out before we land it
[14:41] <jam> (I think the correct thing is to move 'ssh_server' into an attribute with a better name, and move the .join() into the .handle() method
[14:41] <jam> )
[14:43] <vila> I think we should do one event.wait() in verify_request to wait for the key exchange and set an event, wait for this event in handle() and do a join() in finish()
[14:44] <vila> What I suspect is going on is that the thread spawned by paramiko is using the other side of the channel (the unencrypted one) and this should be blocked during th key exchange
[14:45] <vila> joining the connection should occur only when the conversation through the encrypted channel is finished
=== Ursinha-zzz is now known as Ursinha
[14:45] <vila> your fix works, because it does that but it doesn't expose how the things work (or at least how I think they work)
[14:48] <vila> I'm pretty sure there is something similar in paramiko when handling sftp connections
[15:06] <jam> vila: I thought about having a second event, and even did that for a while
[15:06] <jam> but the event only triggers when the run() method exits, which is equivalent to .join()
[15:06] <vila> the run method always exist on Thread
[15:08] <vila> meh, are you saying run == join ???
[15:08] <jam> vila: I'm saying that triggering an event at the very end of run() and waiting on that event is equivalent to waiting on the thread via join
[15:13] <vila> That's unrelated to what I'm talking about then
[15:14] <vila> What I'm saying is that I suspect that the key exchange and the socket use happen in different threads and these threads needs to be sync
[15:28] <jam> vila: are you saying socket or channel?
[15:28] <jam> it all happens in the same thread, it happens *in the same loop*
[15:29] <jam> (partially because a long running ssh connection will need to re-key itself after ~2^30 bytes, so it makes sense to have the check be in the loop)
[15:29] <vila> really ? There could be multiple Channels for the same Transport and I thought the key exchange is shared between the channels so handled by the transport
[15:30] <vila> whereas the "socket" I'm referring to is the unencrypted side of the *channel*
[15:37] <jam> vila: still digging through the code a bit
[15:37] <jam> there is only one thread that processes the communication
[15:37] <jam> (Transport.run())
[15:37] <jam> and things it calls must only be entered via a single thread
[15:37] <jam> however, when spawinng a channel and doing something like 'shell' request
[15:41] <jam> paramiko itself doesn't implement those functions, so it is a bit hard to say for sure. Certainly our implementation spawns a subprocess and 3 threads to pass the bytes from the process back to the channel
[15:42] <jam> the channel itself is threadsafe, in that you can have multiple threads calling 'send()' simultaneously
[15:42] <jam> which, honestly, seems like a bad design
[15:43] <jam> given that you'll fill a single channel with random intermingled content
[15:43] <vila> that's exactly what ssh is about IIUC...
[15:43] <jam> vila: well from what I can tell if you had multiple threads you *should* be putting them into different channels
[15:44] <vila> urgh, where ?
[15:44] <jam> I guess if your messages are small, you might be able to squeeze a full message w/ header into a single send window
[15:44] <jam> vila: you have 1 socket, w/ N channels, and potentially M threads writing to 1 channel
[15:44] <vila> you shouldn't have to care about that but I'm wondering if that may explain some problems with the smart server on lp
[15:45] <vila> oh, one thread one channel, yes, sorry misread transport there
[15:45] <jam> maybe I should say "M threads *per* channel"
[15:45] <jam> so N*M potential threads writing
[15:46] <vila> I think there is always and only 2 threads per channel, the (hidden) paramiko one and the user one
[15:46] <jam> your earlier statement... yes the key exchange is shared between channel
[15:46] <jam> vila: no extra thread for a channel for paramiko
[15:46] <vila> between channelS , one per transport
[15:46] <jam> if you have 1 transport and 10 channels
[15:46] <jam> you have 1 thread from paramiko, and N for the channels from the *user*
[15:47] <jam> vila: we, for example, spawn *3* threads all talking on the same channel
[15:47] <jam> with the extra complexity that you can read, write and write-to-stderr on the same channel
[15:49] <vila> well, one reading, two writing to the same socket propably.. but wow, both closing the same channel..
[15:50] <jam> vila: so what happens is that you have 2 messages you can put on the channel
[15:50] <jam> MSG_CHANNEL_DATA (which is stdout)
[15:50] <jam> and MSG_CHANNEL_EXTENDED_DATA which allows you to prefix it with yet-another identifier
[15:50] <jam> in this case '1' to indicate stderr
[15:51] <vila> right, so Transport and Channel can more or less be seen as the encrypted side and the non encrypted side right ?
[15:56] <jam> vila: transport is the multiplexed controller, I don't know that I would call it the encrypted side, though it probably does do the encryption
[15:57] <vila> because the encrypted bytes goes into it and goes out of it, the channels see only unecrypted bytes
[16:15] <maxb> Hrm. I just emailed the bazaar ML, and got a stupid autoresponse from joe1@assistly.com, as if someone has signed an automated support desk up to the mailing list
[16:20] <jam> vila: so in paramiko terms the 'packetizer' is the one that actually encrypts and decrypts content
[16:20] <jam> however, there is only 1 and it is controlled by the Transport
=== Ursinha is now known as Ursinha-lunch
[16:22] <vila> jam: fits my mental model
[16:22] <vila> jam: So the key exchange happens there right ?
[16:23] <jam> vila: key exchange is controlled by transport
[16:23] <vila> jam: isn't it what I just said ?
[16:23] <jam> (Transport._send_key_init)
[16:23] <jam> vila: a bit unclear where 'there' was, since I listed both Packetizer and Transport
[16:24] <vila> <vila> right, so Transport and Channel can more or less be seen as the encrypted side and the non encrypted side right ?
[16:24] <vila> <jam> vila: transport is the multiplexed controller, I don't know that I would call it the encrypted side, though it probably does do the encryption
[16:24] <vila> <vila> because the encrypted bytes goes into it and goes out of it, the channels see only unecrypted bytes
[16:24] <jam> so actually, *Transport* tends to deal in unencrypted bytes (including the key exchange) and packetizer is the one that encrypts/decrypts it
[16:25] <vila> jam: now you're really playing with words... the initial problem is no know whether we need to sync the thread doing the key exchange and the one doing the smart server stuff
[16:25] <vila> s/no know/to know/
[16:26] <jam> vila: we shouldn't start the smart server until the key exchange has completed
[16:26] <jam> but 'start_server()' is enough to ensure that
[16:26] <jam> and given that 'starting the smart  server' occurs as a 'please spawn the server' request via a channel, we don't have an opportunity to start it earlier
[16:26] <vila> jam: if it was enough join() wouldn't be needed
[16:27] <jam> vila: the reason we have to *join* is because we have to have the StubSSHServer not *stop* until we've actually finished talking
[16:27] <jam> and it stops when the requests have been "handled"
[16:27] <vila> jam: which is why I want to do that in finish()
[16:28] <jam> vila: the way the code is written it doesn't matter, but sure, it does make sense to do it there
[16:28] <jam> I don't think I've ever argued that point
[16:28] <jam> I've argued that adding an event that you wait on before you wait on .join doesn't make sense
[16:28] <vila> But I never said that
[16:29] <jam> vila: you wanted to wait on an event in '.handle' and then 'thread.join' in finish
[16:29] <vila> jam: not *that* event you're talking about
[16:30] <vila> yes, that's a different one
[16:30] <vila> I'd like to have setup only goes until the key exchange is done
[16:30] <jam> what event are you talking about?
[16:30] <jam> sure
[16:30] <vila> handle covers only the smart server stuff
[16:30] <vila> and fiinish only doing join
[16:30] <jam> handle does nothing today, and we don't have a point to interrupt to actually do something
[16:31] <vila> :)
[16:31] <jam> unless you want to .join() in handle, or add an artificial event to wait for
[16:31] <vila> the later
[16:33] <jam> vila: why add an artificial event that only fires when the thread is exiting?
[16:33] <vila> except I'm still not convinced it's so artificial because I think the key exchange and the smart server stuff are in different threads (and by that I mean replacing the subprocess spawn (which takes time) by a direct call to TestingSmartConnectionHandler   which is the inline version
[16:33] <vila> not when it's exiting, when the key exchange has been done
[16:34] <vila> jam: i.e. you had a comment: This blocks until the key exchange has been done
[16:34] <vila> jam: it's a good comment, let's make it true and clear :)
[16:34] <jam> vila: it is true today
[16:36] <jam> vila: regardless the "check_channel_exec..." can only happen once the transport has established the key exchange, since it is an explicit request from the client to the server that it wants us to spawn 'bzr'
[16:37] <jam> vila: I don't really care whether we wait for the key-exchange to finish in 'setup' or in 'handle', but it seems to me that 'setup' is perfectly reasonable
[16:40] <vila> I view setup and finish as responsible for the Transport and handle as responsible for the channel, if you're sure the key exchange has occured once start_server returns, I'm happy
[16:40] <vila> jam: Reading the history of your branch, I got the feeling this wasn't the case, IMBW
[16:41] <vila> jam: the fact that you waited on two events for example... now, if paramiko does it job I'm fine
[16:41] <vila> jam: but I still don't get how the Transport was shut down early (especially since paramiko use daemon threads)
[16:42] <jam> vila: I can create an event pass it in and wait for it, but ssh_server exits when the key exchange has completed. *I* did not realize that until recently
[16:42] <vila> jam: ha, good, one missing bit less
[16:43] <jam> vila: the Transport isn't stopped, the *socket* is closed
[16:43] <jam> http://paste.ubuntu.com/487305/
[16:43] <jam> notice the try/except close_request()
[16:44] <jam> or in the success case: http://paste.ubuntu.com/487306/
[16:44] <vila> on exceptions only
[16:44] <jam> which also calls "close_request()" when the processing completes
[16:45] <vila> right, but handle() is called only after setup() returns
[16:46] <vila> so that rules out these close_request()
[16:48] <jam> vila: no it doesn't
[16:48] <jam> what was happening is that we weren't waiting for paramiko.Transport to finish
[16:48] <jam> which meant that .setup() .handle() .finish() was being called
[16:48] <jam> and then the calling process would then call close_request()
[16:48] <jam> which would close the socket
[16:49] <jam> before Transport was able to finish talking
[16:49] <vila> jam: but now we're calling join(), which means  we are waiting for paramiko.Transport to finish and yet we are able to process the request ?
[16:50] <jam> vila: nothing happens in .handle or .finish, so the request is initialized and finished in .setup()
[16:50] <jam> I don't understand where you are confused
[16:50] <jam> while we are blocking the request thread in waiting for Transport to finish
[16:51] <jam> a request is sent by the client thread, which is then processed by transport, and handled on a given channel
[16:51] <jam> which says "start the smart server" which we spawn a process and 3 more threads
[16:51] <vila> ok, ok, got it, we closed the encrypted side
[16:51] <jam> to ferry_bytes
[16:51] <jam> vila: right
[16:53] <vila> ...and there was one more thread still running on the channel side ?
[16:53] <vila> no, the transport one, but it gounf the socket closed
[16:53] <vila> gounf, interesting, found
[16:53] <vila> one-by-one on qwerty
[16:55] <vila> ok, that was indeed where I was confused, in all the other implementations there is no distinction between the 'request' socket on the one seen by the bzrlib.transport, whereas here, they are different, not wrapped or anything, really different
[16:56] <vila> jam: so, s/ssh_server/ssh_connection/ ?
[16:57] <vila> jam: that would at least make things a bit more inline with the rest of the code base, but less with the paramiko side :-/ Shudder, see ? How can we address your remark about 'server' being overused, now that you've hacked a bit more in the space ?
[16:58] <jam> vila: for example, using 'paramiko_transport' instead of ssh_server, probably
[16:58] <jam> for the rest of the stack
[16:58] <jam> I think using 'connection' or 'request' is nice
[16:58] <jam> we use TestServer
[16:58] <jam> which then spawns a real server
[16:58] <jam> I'm not sure about that
[16:58] <jam> maybe calling it a Resource ?
[17:01] <vila> using 'paramiko_transport' instead of ssh_server +1 (explaining that it's close to an ssh server from a user pov)
[17:02] <vila> s/TestServer/Resouce/ ?
[17:02] <vila> s/TestServer/Resource/ ?
[17:02] <jam> TestServer => TestResource maybe
[17:02] <jam> though I see "Test*" and I think it is a TestCase
[17:02] <vila> a bit vague :-/
[17:02] <vila> ServerProxy ?
[17:02] <vila> pfff
[17:03] <jam> the other thing is where else do these 'servers' act?
[17:03] <jam> the SFTP server, the FTP server, etc
[17:03] <jam> Service versus Server ?
[17:04] <vila> FTPSocketServer and keeping TestServer...
[17:05] <vila> hmm, may be that whole discussion could have been avoid by s/setup/handle/....
[17:31] <manus_> quick question: is there a way to check in a file once, and then tell bzr to ignore any *further* local changes? e.g., a default configuration file is checked in that everyone will change locally, but which should never be recommitted (unless explicitly unignored first)?
=== Ursinha-lunch is now known as Ursinha
[17:36] <manus_> is that even possible?
[17:37] <manus_> I guess this says "not yet": https://bugs.launchpad.net/bzr/+bug/209025
[17:37] <ubot5> Launchpad bug 209025 in Bazaar "ignore local changes (affected: 4, heat: 18)" [Wishlist,Confirmed]
[17:37] <manus_> huh
[17:48] <vila> manus_: the best answer I know of is to have a template file that is copied on install
[17:49] <vila> manus_: a file is either versioned or not versioned, if you have to decide for each change, you may as well use two files, at least it makes the consequences clearer
[17:50] <vila> manus_: when you have interested changes, you can always do 'cp <file> <template>' + edit + commit
=== beuno is now known as beuno-lunch
[17:54] <manus_> true, though it would be nice to have "ignore --local" and "ignore --remote" options
=== manus_ is now known as manus_-lunch
=== manus_-lunch is now known as manus_
=== deryck is now known as deryck[lunch]
=== beuno-lunch is now known as beuno
=== deryck[lunch] is now known as deryck
[20:14] <facundobatista> hello everybody
[20:14] <facundobatista> I have this niiiiiiice error message:
[20:14] <facundobatista> $ bzr merge-upstream ../magicicada_0.2.orig.tar.gz --version=0.2 lp:magicicada
[20:14] <facundobatista> Using distribution maverick
[20:14] <facundobatista> bzr: ERROR: An inconsistent delta was supplied involving u'/COPYING', 'copying-20100604211115-39tdwa0pbzb5kj4b-1'
[20:14] <facundobatista> reason: Attempt to add item at path already occupied by id 'copying-20100608181145-hj2h11vcpksyqwck-36'
[20:14]  * facundobatista is not even understanding it :|
[20:15] <jelmer> facundobatista: Hi
[20:15] <facundobatista> hello jelmer
[20:15] <jelmer> facundobatista: If I remember correctly this is a known bug for which a fix is available.
[20:16] <abentley> jam, I heard something about bzr allowing merging branches with differing file-ids.  Is that something being worked on?
[20:16] <jam> abentley: it isn't something that *I've* been working on
[20:17] <abentley> jam, and not something you've heard about?
[20:17] <jam> I think I've heard about it, but more in the context of something like bzr-builder
[20:18] <abentley> jam, e.g. using the MergeIntoMerger?
[20:18] <jam> abentley: more using by-path merging
[20:19] <abentley> jam, okay, thanks.
[20:20] <facundobatista> jelmer, do you know what that fix would be?
[20:21] <jelmer> facundobatista: Not off the top of my head.
[20:21] <jelmer> facundobatista, I would recommend having a look at bzr-builddeb
[20:21] <jelmer> facundobatista, I would recommend having a look at bzr-builddeb's bug tracker
[20:23] <facundobatista> jelmer, I think this is the one: https://bugs.edge.launchpad.net/bzr-builddeb/+bug/619614
[20:23] <ubot5> Launchpad bug 619614 in bzr-builddeb "InconsistentDelta during merge-upstream (affected: 1, heat: 5)" [Critical,Fix committed]
[20:23]  * facundobatista patches his bzr
[20:29] <facundobatista> jelmer, it worked!!!
[20:29] <facundobatista> jelmer, thank you!
[20:29] <jelmer> facundobatista: great :-)
[20:31] <jelmer> jam: 'morning
[20:32] <jelmer> jam: do you know what happened to bzrlib.tests.TestLoader ?
[20:32] <jelmer> jam: bzr-plugin-info relies on it existing, so I wonder what it should be using instead; NEWS doesn't mention anything.
[20:41] <ReachingFarr1> I currently have a project on my local machine.  I would like to place a copy of it in a shared repository on my server, make that copy the "master", then bind my local copy to it.  What is the correct series of commands to do such a thing?
[20:43] <dash> ReachingFarr1: 'bzr init-repo /path/to/repo' on the server
[20:43] <ReachingFarr1> dash: Got that one done.
[20:43] <dash> 'bzr push bzr+ssh://host/path/to/repo/branchname' on the client
[20:43] <dash> then 'bzr bind bzr+ssh://host/path/to/repo/branchname' on the client
[20:43] <ReachingFarr1> dash: Ok, and that will work because the destination is inside an initialized directory?
[20:44] <dash> right
[20:44] <ReachingFarr1> dash: Ok.  I think that was the problem I was having with push earlier.  Thanks a lot.
[20:46] <ReachingFarr1> dash: So on my server that directory now has a .bzr folder and nothing else.  How would one cause the current version of the files to appear?
[20:47] <dash> ReachingFarr1: 'bzr checkout'
[20:48] <ReachingFarr1> dash: Excellent.  Thanks  again.
[21:01] <jam> jelmer: vincent recently changed tests/__init__.py to only import the module rather than the classes themselves. I'm voting to bring back the old style, but it hasn't gained much traction yet
[21:03] <jam> vila: ^^ care to respond (if you get back online tonight)
[21:06] <lifeless> jam: old style ?
[21:07] <jam> lifeless: from bzrlib.tests import TestLoader, TestCase, TestSuite
[21:07] <jam> or
[21:07] <jam> from bzrlib import tests; tests.TestCase tests.TestLoader, etc.
[21:07] <lifeless> ah yes, several plugins got hit by that
[21:07] <lifeless> +1 on restoring it with a backport :)
[21:07] <jam> lifeless: I thought it only made it into 2.3, is it a 2.2 thing, too?
[21:07] <lifeless> I'm not sure; I'm seeing bug reports on plugins increasing is all
[21:08] <jelmer> jam: Ah, ok
[21:08] <jam> lifeless: yeah, it is just bzr.dev, just happened with Vincent's recent "clean up leaking tests" change
[21:08] <lifeless> I *thought* it would be 2.2 because I saw a release happen
[21:08] <jelmer> jam: For now I've just proposed imports from the TestUtil module directly.
[21:09] <jam> jelmer: I'd rather see TestLoader from tests, as it makes a better model than finding it in bzrlib.tests.TestUtil, but you're right that your method still works across all versions
[21:11] <cody-somerville> Whats the correct way to revert a single revision?
[21:12] <jam> cody-somerville: you mean to reverse the changes created in a given rev?
[21:12] <jam> bzr merge -r REV..REV-1
[21:13] <cody-somerville> aye
[21:13] <cody-somerville> Okay, thanks.
[21:13] <jam> sorry small typo
[21:13] <jam> bzr merge . -r REV..REV-1
[21:13] <cody-somerville> will that work if I have uncommitted changes in my tree?
[21:13] <jam> the '.' is important, since otherwise it reverts the rev from the default merge location
[21:13] <jam> cody-somerville: you can supply --force if you must, depends on whether the changes getting intermixed matters to you
[21:14] <jam> jelmer: do you remember the bug #?
[21:15] <jam> bug #627438
[21:15] <jam> found it
[21:15] <ubot5> Launchpad bug 627438 in Bazaar PQM Plugin "import failure in plugin-info during selftest (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/627438
=== abentley_ is now known as abentley
[21:19] <jam> lifeless: timeout trying to submit the merge proposal... :)
[21:20] <jam> OOPS-1706EC2006
[21:20] <ubot5> https://lp-oops.canonical.com/oops.py/?oopsid=1706EC2006
[21:20] <jam> second submit worked
[21:20] <jam> jelmer: https://code.edge.launchpad.net/~jameinel/bzr/2.3-test-loader/+merge/34481
[21:20] <lifeless> jam: thanks
[21:20] <jelmer> jam: thanks
[21:46] <jelmer> jam: r=me
[21:47] <lifeless> jam:
[21:47] <lifeless> Total time: 13419 ms
[21:47] <lifeless> Statement Count: 34
[21:47] <lifeless> SQL time: 13260 ms
[21:48] <lifeless> jam: timeout on the INSERT INTO - 13 second query. has to be lock contention I think.
[21:48] <lifeless> jam: could you file a bug ?
[21:50] <jam> lifeless: sure, but against what project?
[21:50] <lifeless> jam: launchpad-code
[21:53] <jam> lifeless:  bug #629087
[21:53] <ubot5> Launchpad bug 629087 in Launchpad Bazaar Integration "timeout submitting merge proposal (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/629087
[21:53] <jam> lifeless: on your new "search only grabs 3-out-of-4 hits", would it be possible to remove 'common' words?
[21:54] <jam> I find I rarely get any hits while submitting new bugs now, and while I can chop things out of my summary
[21:54] <jam> it seems like words like "the" "while" etc make for better summaries
[21:54] <jam> but make for bad hits in the db
[21:54] <lifeless> problem is that common is defined in the corpus
[21:54] <lifeless> so that was one of the cuases of timeouts - it analysed the corpus on every reqyest
[21:54] <lifeless> yes, its fixable, not short term.
[22:22] <jam> lifeless: true, though you could hard-code some pretty easily
[22:22] <lifeless> jam: not for 20K projects ;P
[22:22] <lifeless> stop words are eliminated already