[00:01] <spiv> Good morning.
[00:09] <peitschie> mornin spiv
[00:36] <poolie> jelmer, hi, still awake?
[00:36] <poolie> hi spiv
[00:36] <jelmer> poolie: Hi!
[00:36] <jelmer> poolie: Apparently :-)
[01:34] <spiv> Ooh, I'm patch pilot this week.
[01:35] <spiv> poolie: perhaps you should review https://code.edge.launchpad.net/~gz/bzr/smart_add_former_file_dir_251864/+merge/38676 ?  I think you may have touched that code or near it with your smart_add deprecation patch.
[01:35] <poolie> spiv, actually i was going to propose swapping with you because i'll be away for the next two
[01:36] <poolie> i have, i'd be happy
[01:36] <poolie> to
[01:36] <poolie> (otp)
[01:37] <spiv> So you'd pp this week, and I'd pp the week of Nov 1?  I'm happy to do that.
[02:00] <dOxxx> spiv, pooile: y'all are just afraid to review my monster mergetools mp ;)
[02:00] <dOxxx> poolie^
[02:00] <spiv> Heh
[02:01] <spiv> dOxxx: pfft, I had patch with a 26000 line diff last week ;)
[02:01] <dOxxx> I don't blame you. Took me 3 months.
[02:01] <dOxxx> Automated refactorings don't count! :)
[02:04] <poolie> :)
[02:04] <poolie> spiv of course you can still do reviews this week
[02:15] <poolie> spiv, are you all better? or a bit better?
[02:31] <spiv> poolie: I'm mostly better.
[02:32] <spiv> Well enough to continue looking at https://bugs.edge.launchpad.net/udd/+bug/653307 at least :)
[02:33] <poolie> want a quick catchup call or pm (depending on the state of your voice)?
[02:50] <zamabe> so. debian and bzr
[02:50] <zamabe> i hear they don't mix
[02:50] <zamabe> and i can't exactly download it
[02:52] <poolie> what is 'it'?
[02:52] <spiv> poolie: a catch up would be good, but maybe just after lunch as I'm in the middle of digging through a udd/bzr-builddeb maze right now
[02:52] <poolie> ok, thanks
[02:53] <zamabe> poolie, i've recently decided to download the tarball and build it
[02:53] <zamabe> what i mean by 'it' is this
[02:54] <zamabe> http://wiki.bazaar.canonical.com/DistroDownloads#Debian
[03:50] <poolie> zamabe, you just need 'sudo apt-get install bzr' or the equivalent
[04:08] <jbowtie> FryGuy-, thanks for those branches; I've already merged one and will create patches based on the other two soon.
[04:09] <jbowtie> FryGuy-: I was also surprised to see that it worked with 2010 with such a small change. They actually did pretty well with backwards compatibility.
[04:09] <jbowtie> FryGuy-: unfortunately I can't use the branch directly, need to put in conditional version checks.  ;)
[04:19] <jbowtie> poolie: My "chopping up the file" proposal was based on what ZFS, Dropbox, et al do for versioning large files. Memory usage was a side effect.
[04:19] <jbowtie> poolie: Do you know of any better algorithms I should be looking at, maybe in the literature somewhere?
[04:38] <poolie> i think the basic idea of chopping it up based on a rolling checksum is not too bad
[04:54] <lifeless> it might be nice to just be deterministic
[04:54] <lifeless> every 128K for instance
[04:54] <lifeless> so that we don't have to /diff/ to do it.
[04:54] <lifeless> in fact, thats probably a must-do, not a might-do.
[04:59] <jbowtie> lifeless: Should that apply to large text files as well or just binaries.
[04:59] <jbowtie> ?
[05:11] <poolie> well, rolling checksums are deterministic
[05:11] <poolie> spiv, can you reproduce that bug in bzr alone?
[05:13] <lifeless> poolie: they are, but using them to find the boundary between and old and new version means that partial branches cannot reproduce the result
[05:13] <lifeless> poolie: which is a significant concern
[05:13] <poolie> maybe we're talking about different things?
[05:14] <poolie> i understood jbowtie to be considering using them to chop single large files
[05:16] <jbowtie> Yes, trying to find a way to solve some of the issues around large binaries.
[05:16] <lifeless> that would be fine, I understood him to be using delta logic based on that
[05:16] <lifeless> via the reference to zfs and dropbox
[05:17] <spiv> poolie: no, at least not without intentionally driving the bzrlib APIs to generate two inventories with the same ID but different details.
[05:17] <poolie> jbowtie: so are you saying that dropbox chop the files on boundaries and then apply librsync?
[05:17] <poolie> i know they at least used to use librsync
[05:19] <jbowtie> poolie: AFAICT yes, that lets them do data deduplication as well as versioning.
[05:19] <poolie> mm
[05:21] <poolie> jbowtie: i'm wondering: in which layer should this be done?
[05:22] <poolie> should the repository present the abstraction that you're just dealing with files, some of which may be extremely large?
[05:22] <poolie> or do you want to expose it at a higher level?
[05:22] <poolie> to me it seems pretty clear it should be behind that abstraction if at all possible
[05:23] <poolie> so then we do need to make sure all those interfaces work with iterators of bytes (or some similar convention)
[05:23] <poolie> otherwise we'll just propagate this problem
[05:26] <jbowtie> poolie: I'd like to keep it confined to the repository if possible, but I think I need to spend some time trying to implement it to come up with something workable.
[05:26] <jbowtie> poolie: Figured I'd put together something experimental this week if I can find the free time.
[05:27] <jbowtie> Speaking of which I have to go offline while I travel home; pick up the conversation on the mailing list if necessary.
[05:34] <poolie> i don't really understand the relevance of the xemacs startup to hooks...
[05:34] <poolie> spiv: now?
[05:35] <spiv> poolie: now is good
[07:34] <vila> hi all !
[07:44] <spm> yo vila!
[07:45] <vila> spm: hey !
[07:57] <vila> poolie, spiv: Hmm, did I miss something ? jam and poolie are at UDS next week, so PP should be either me or spiv for week 43 (starting 25 oct)
[07:58] <poolie> that is what i meant to make it
[07:58] <poolie> ... and i got it wrong
[07:58] <poolie> i'll fix it
[07:58] <vila> poolie: done
[07:59] <vila> was doing it in parallel but wanted to give a heads-up
[08:00] <lifeless> spiv: you should get a twitter account ;)
[08:44] <poolie> vila, did you get to talk to charline?
[08:44] <vila> poolie: no, she never ponged, I will try again today
[08:45] <vila> poolie: hmm, she's not online currently though...
[08:45] <vila> poolie: I will mail her
[08:45] <poolie> ah, she might have already gone to the US
[08:45] <poolie> that would be good
[08:45] <vila> argh, goodbye same-TZ-ness
[08:46] <poolie> i thought she wasn't leaving til later this week
[08:47] <vila> and I can't find here on the UDS-N attendees :-? >-/
[08:53] <poolie> vila, ok, i sent her a mail
[08:53] <poolie> you could call later today?
[08:53] <vila> poolie: sure
[08:57] <poolie> what a day
[08:57] <poolie> i'm going to sign off, good night
[09:01] <vila> poolie: night !
[09:13] <thevibe> morning anyone
[09:14] <thevibe> does anyone of you have a post_commit update hook/plugin ?
[09:18] <lifeless> what do you mean?
[09:51] <thevibe> I mean if you have an already running post_commit hook/plugin that does an update on the server
[09:53] <thevibe> lifeless - I'm just at the beginning with python so I don't want to jump over my level with a plugin that needs to serve a development environment
[09:54] <lifeless> oh, I think someone may have written one
[09:54] <lifeless> check the plugins page?
[09:56] <thevibe> lifeless, I checked google up to page xx and I can't find one
[09:56] <lifeless> hmm
[09:56] <thevibe> honestly the problem is that I can't wait till I get a ggod grip of python for this
[09:57] <thevibe> I need it and that's why I am asking for help
[09:57] <lifeless> I'd ask on the list
[09:57] <lifeless> more people see questions there
[09:57] <thevibe> I built the development environment in a semi-decentralized manner
[09:57] <thevibe> and because is the developement server and we have a routine in place
[09:58] <thevibe> an update run after commit will display everything in the broser straight away
[09:58] <thevibe> which is what I want
[09:59] <thevibe> I've sent my question there but not very successful
[09:59] <thevibe> because of that I said I will come here maybe someone has one and maybe will be willing to share it
[10:00] <thevibe> the other problem is that I need to put everything in place to close the gates for svn fans asap
[10:00] <thevibe> :)
[10:24] <GaryvdM> thevibe: Not sure if I understand you correctly, but maybe the bzr-upload plugin will do what you want.
[10:37] <thevibe> bzr-upload will be used to deploy things but I don't think it does what I want
[10:38] <thevibe> I just want an equivalent of an svn post_commit hook that runs an update on the server after any commit
[10:39] <thevibe> it should be in the same category with hooks that send an email after commit or something similar
[10:40] <thevibe> to describe the structure this is how it looks
[10:40] <thevibe> we init a project on the server
[10:40] <GaryvdM> thevibe: What does "runs an update" entail?
[10:41] <thevibe> the developer will checkout a branch which is bound to the main one
[10:41] <thevibe> after any chaneg the developer will commit the changes to the main repo
[10:41] <thevibe> after that cmmit I need a hook that will execute a bzr update
[10:41] <thevibe> so I can see the changes in the browser straight away
[10:42] <thevibe> is being used for web dev mostly
[10:42] <thevibe> GaryvdM, after a commit I need a hook that will execute bzr update on the server
[10:43] <thevibe> it is something like push-and-update but I need commit-and-update
[10:43] <GaryvdM> thevibe: Ok - bzr update needs to be run on the server. Do the devs all have ssh access?
[10:43] <thevibe> everything is run under ssh
[10:43] <thevibe> bzr+ssh
[10:44] <thevibe> so yes they have as the server is inside
[10:44] <thevibe> but I need an automated process
[10:44] <thevibe> I don't want them to login and run the command by themselves
[10:45] <GaryvdM> thevibe: You will want a post tip change hook on the master branch, rather than a post commit hook on the devs branch, so that if they unbind, and push, it still works.
[10:45]  * GaryvdM looks at the push-and-update to see if it can be made to do this
[10:46] <GaryvdM> * push-and-update code...
[10:47] <GaryvdM> thevibe: Note that you can get bzr-upload to do this...
[10:48] <thevibe> as I was saying I am not very advanced with python so I don't want to digg in an area where I can miss things and not understand others
[10:48] <thevibe> GaryvdM, can you give me more details on how bzr-upload can do this
[10:48] <thevibe> ?
[10:49] <thevibe> I trust you about the post tip change hook but the issue is still there: how can I get one of those? :)
[10:51] <GaryvdM> thevibe: step 1: in the master branch  on the server, run bzr remove tree
[10:52] <GaryvdM> thevibe: step 2 : from your pc run bzr upload sftp://server/path-to-branch  -d bzr+ssh://server/path-to-branch --auto
[10:54] <GaryvdM> thevibe: that will get bzr-upload to do a post tip change hook on bzr+ssh://server/path-to-branch to upload to sftp://server/path-to-branch
[10:55] <GaryvdM> thevibe: step 3: make all the devs install bzr-upload.
[10:56] <Glenjamin> s/remove tree/remove-tree/
[10:56] <GaryvdM> Glenjamin: yes - thanks
[11:06] <thevibe> excellent
[11:06] <thevibe> I will do that
[11:06] <thevibe> one more thing
[11:08] <thevibe> some of the are front-end developers or even designers and I suggest them to use bzr explorer as it can be installed on multiple OS's
[11:08] <thevibe> I use Ubuntu, for me it's easy
[11:08] <GaryvdM> Hmm - push-and-update date has a post_push hook, but that limits it to push. It would be much more useful if it used post-tip-changed, like bzr upload..
[11:08] <thevibe> can I create a tool in bzr for this command?
[11:09] <thevibe> you're right and I told you I tried that plugin and is not exactly what I need
[11:09] <thevibe> it has his good parts but probably a post-tip-changed would be much more useful in real-world
[11:10] <thevibe> I think at least
[11:10] <thevibe> :)
[18:21] <mgz> I'm pretty sure using bzr with gunicorn is just a bad idea.
[18:26] <jam> mgz: but... but... unicorns, man
[18:27] <mgz> the problem on the list doesn't look intermittent though, so I won't start yelling about signals just yet.
[18:27] <jam> mgz: signals shmignals, unicorns man, its all about the unicorns
[18:28] <jam> (and the fairy dust, but that is harvested from the unicorns anyway)
[18:28] <mgz> shouldn't animal welfare have something to say about covering a unicorn in green paint?
[18:29] <GaryvdM> Hi mgz, jam
[18:29] <jam> hi GaryvdM
[18:29] <mgz> have you got any smart ideas on bug 663234 Gary?
[18:30] <GaryvdM> He He, was about to ask you....
[18:30] <GaryvdM> * I was...
[18:31] <mgz> well, Alexander might be right, it's hard to tell without more information
[18:31] <mgz> suggesting the guy tries do just do python -c "import PyQt4.QtGui" might help.
[18:31] <GaryvdM> He said that it was working with 2.2.0, so I wonder if he removes the msvcp dlls and manifest, if it will work
[18:32] <mgz> yeah, I wondered if it was something I'd broken, but I'm not even sure which installer he used
[18:32] <GaryvdM> I've been assuming 2.2.1-2, but I may be wrong.
[18:33] <GaryvdM> I looked, and I can't find any window 2000 cd.
[18:33] <mgz> yeah, not sure it's really worth us trying to test it.
[18:34] <mgz> working out some sensible things for him to try might be worth it though.
[18:34] <GaryvdM> I was still in school when win2000 came out - Seems so long ago.
[18:34] <mgz> ehehhe
[18:34] <mgz> I have a box with win98 on it still!
[18:34] <GaryvdM> :-0
[18:35] <mgz> but I was in school when I got it.
[18:36] <GaryvdM> I never used 98 much. I went from 95 -> nt 4
[18:38] <GaryvdM> btw - I got my build host working finally :-) I need to document how I did it with vs express .
[18:38] <mgz> cool.
[18:40] <GaryvdM> And I have built a 64bit python installer, which I need to upload. But I think what people will really be looking for is the standalone 64bit installer.
[18:41] <mgz> I did wonder what people were going on about on the mailing list with 64 bit windows.
[18:41] <mgz> ...if you care that much, just download a 64 bit python and install bzr yourself
[18:42] <GaryvdM> I'm busy in building a 2.2.1-3, with bzr-explorer 1.1.1. 1.1.0 had a bug thats getting alot of heat.
[18:45] <GaryvdM> mgz: Did you see my mail about using build out for the dependences?
[18:45] <mgz> ...no, what list was it sent to?
[18:46] <GaryvdM> mgz: bzr-windows
[18:46] <GaryvdM> Ah - just got jam's reply
[18:47] <jam> GaryvdM: well, I just sent it now, too :)
[18:47] <jam> I like the idea
[18:47] <jam> not sure about the path
[18:47] <jam> I would be fine using a default that fits the build machine
[18:48] <mgz> I'd really like a way of bypassing buildout, but using it for more things is also good.
[18:49] <GaryvdM> jam: I finally managed to create a bundle on ec2, but the name I gave it was not very good. Sorry
[18:54] <mgz> jam: if you have a mo, could I have some input on my worrying in <https://code.launchpad.net/~gz/bzr/require_unicode_committer_614593/+merge/38334> ?
[18:58] <jam> mgz: commented
[19:00] <mgz> thanks!
[19:27] <mtaylor> is there already a bug out there requesting that bzr launchpad-login set bzr whoami based on metainfo on launchpad
[19:28] <mtaylor> I _keep_ having folks who have obviously dong lp-login (since they are pushing) but skip the whoami step because nothing reminds them to
[19:30] <fullermd> Don't recent versions just refuse to commit if you haven't whoamied?
[19:30] <fullermd> (whoami'd?  How do you conjugate that?)
[19:53] <mtaylor> fullermd: not that I can see ... although maybe that's in newer revs than what we have
[19:53] <mtaylor> fullermd: do you mean post-2.2?
[19:53] <fullermd> Looks like it was in 2.2.
[20:08] <mwhudson> jam: hi
[20:18] <jam> hi mwhudson
[20:18] <mwhudson> jam: did you see the lp-service failure?
[20:19] <jam> yes, I wasn't 100% sure about what it was telling me
[20:19] <mwhudson> jam: i think it's an unbound variable 'socket_path'
[20:19] <jam> mwhudson: what I saw was "exited without failures but with nonzero exit code"
[20:21] <mwhudson> $ pyflakes lib/lp/codehosting/tests/test_acceptance.py
[20:21] <mwhudson> lib/lp/codehosting/tests/test_acceptance.py:81: undefined name 'socket_path'
[20:21] <mwhudson> jam: ^
[20:21] <jam> AttributeError: 'TestProtocolClient' object has no attribute '_exc_info_to_unicode'
[20:23] <jam> mwhudson: so it certainly could have failed randomly because of a broken exception handler
[20:23] <jam> but all the test_acceptance tests seemed to pass here
[20:25] <mwhudson> jam: you haven't forgotten to push to lp?
[20:26] <mwhudson> jam: because there's pretty clearly a socket_path that needs to be self.socket_path in the branch i just pulled
[20:27] <jam> it is possible
[20:27] <jam> or I pushed without commit, etc
[20:30] <mwhudson> jam: the deprecationwarnings are probably from the atexit stuff
 AttributeError: 'TestProtocolClient' object has no attribute '_exc_info_to_unicode' <- this is subunit bug 635702 and indicates an old testtools version
[21:13] <jam> mgz: someone should tell launchpad to update their testtools :)
[21:13] <mgz> There's probably an rt on it buried somewhere.
[21:16] <mgz> content filtering hits before diff, right?
[21:17] <mgz> so, content filtering a utf-16 file to utf-8 in the repo would mean you could diff it?
[21:29] <mwhudson> jam: lifeless tried (to update testtools), it uncovered some broken tests
[21:54] <lifeless> mwhudson: I'd be delighted if you wanted to tug on them.
[21:55] <poolie> jam, shall we talk in a bit?
[21:58] <mwhudson> lifeless: two of the tests are really easy to fix, i guess i can look at them in a bit
[22:54] <peitschie> mornin all :)
[23:01] <vila> ouch, now is already tomorrow, night all ;)
[23:03] <peitschie> night vila lol
[23:14] <jelmer> Bonne nuit vila