[00:27] <peitschie> NET||abuse: you said you have a branch on your local machine... is that a branch or a checkout?
[00:27] <NET||abuse> branch
[00:34] <peitschie> NET||abuse: did you do a pull or merge on your local branch to try and get the changes from the server branch?
[00:34] <NET||abuse> pull
[03:23] <spiv> vila: https://bugs.launchpad.net/bzr/+bug/672382
[03:37] <poolie> hi all
[03:43] <spiv> poolie: hey, welcome back!
[03:43] <poolie> hi there
[03:44] <poolie> it's good to be back; those were not the smoothest flights i ever had
[03:44] <spiv> I imagine Qantas is pretty chaotic atm.
[03:58] <poolie> very
[03:58] <poolie> there were something like 10 staff deadheading on our flight
[03:58] <poolie> i guess they are moving a lot of people and equipment around to try to cope; the a380s probably carry nearly twice what the 747s do
[04:23] <lifeless> poolie: lol - boeing considered a 650seat 747
[04:24] <lifeless> poolie: the 400ER 3-class seats 416 according to  http://en.wikipedia.org/wiki/Boeing_747
[04:25] <lifeless> poolie: and the A380 450
[04:25] <lifeless> (from adding the numbers in http://www.seatguru.com/airlines/Qantas_Airways/Qantas_Airways_Airbus_A380.php)
[04:26] <poolie> ok, and the a380 is somewhere around 650?
[04:26] <poolie> ah, so not such a big difference
[04:26] <poolie> i guess the qf a380s have a lot of business class seats
[04:26] <lifeless> 72!
[04:27] <lifeless> http://www.qantas.com.au/travel/airlines/a380/global/en agrees with the figures
[04:28] <poolie> on my flight across they realocated some business seats to premium class, and some premium seats to economy
[04:28] <lifeless> you were scheduled on an a380 flight ?
[04:29] <poolie> on the way back i was meant to be on an a380 from lax-syd
[04:29] <lifeless> nice
[04:29] <poolie> i eventually flew on a 747 because all their a380s are grounded
[04:30] <poolie> it was very chaotic
[04:30] <poolie> some people had already been waiting around LA for three days
[04:30] <lifeless> http://www.nzherald.co.nz/business/news/article.cfm?c_id=3&objectid=10686109
[04:31] <lifeless> emirates seem to have an excellent deal there
[04:31] <lifeless> (if you're paying in that bracket)
[04:32] <poolie> i think this weekend is a great demonstration that you can pay 5 figures for a 1st class ticket and still be stuffed around for hours
[04:32] <lifeless> for sure
[04:33] <lifeless> as far as I'm concerned its all about the sleeping
[04:33] <poolie> perhaps slightly more considerately, but they still have to stand around in the gate lounge wondering if they will ever leave
[04:33] <poolie> me too
[04:33] <lifeless> sleeping and power
[04:33] <lifeless> and air NZ have power in economy ;)
[04:33] <poolie> i used points to get premium to sfo on the way across, and ended up getting a business physical seat
[04:33] <poolie> (with premium-grade food etc)
[04:33] <poolie> and that was brilliant
[04:33] <lifeless> poolie: -lol- nice
[04:34] <lifeless> I'm surprised they bothered splitting your menu our
[04:34] <lifeless> out
[04:34] <spiv> poolie: hurrah!
[04:34] <lifeless> ok, afkish
[04:34] <poolie> i think they have semipermanently reallocated some rows to other classes
[04:34] <poolie> hugh got a premium seat without technically being upgraded
[04:35] <poolie> anyhow i'm just catching up on bills, mail stuff
[04:35] <poolie> ping me if there's anything urgent
[04:35] <spiv> *nod*
[07:00] <vila> hi all !
[07:02]  * KombuchaKip is unsure why his client randomly decided to log himself into #bzr
[07:03] <gthorslund> hi vila!
[07:03] <vila> _o/
[07:46] <poolie> hello vila
[07:46] <vila> poolie: hey !
[07:50] <poolie> how are things with you?
[07:50] <vila> fine ! A large plate for the week but I'm hungry :-P
[07:51] <vila> pp'ing, releasing 2.3b3, more conflict resolution, bzr config bugs, plenty of fun ahead :)
[07:51] <poolie> cool :)
[07:51] <poolie> i've seen some of this
[07:52] <poolie> the conflict features sound good
[07:52] <poolie> it seesm like it's more in the way of user feedback than bugs as such?
[07:53] <vila> hmm, right, the implementation is incomplete so that first triggered a bug, but that's still incomplete. I think I can implement --prefer-this/--prefer-other/--take-both quite easily now (which is why I didn't implement --take-this/--take-other for text conflicts in the first place)
[07:54] <vila> deep down though, the bug is revealing a hole in the test coverage (big surprise :-)
[07:56] <vila> oh, and I'd like to switch to sphinx for good too (bug I'm not sure I will be able to tackle this one *this* week ;)
[07:57] <fullermd> Getting lazy in your old age or somethin'?   :p
[07:57] <vila> hehe
[07:58] <vila> my age always seem to inversely proportional to the fun I have, or something ;)
[07:59] <fullermd> Well, at least you spend less on bail money  ;)
[08:01] <vila> oh, and I'd like to implement 'bzr gardener pull'  which should allow to mirror a set of branches with a single command
[08:01] <poolie> that would be kind of nice
[08:02] <poolie> it'd be better if it could get unified with other things that deal with sets of branches, like colo
[08:02] <poolie> i may package that this week, if max and jelmer haven't already
[08:04] <vila> well, there are a couple of long term ideas I'd like to implement there (colo and looms support included), so I'd prefer to keep it separated for now
[08:04] <poolie> vila did john tell you anything much about uds?
[08:05] <poolie> it was a good trip
[08:05] <poolie> (well, the travel kinda sucked, but the meetings were good)
[08:05] <vila> poolie: not that much, he seem pretty busy on other subjects these days...
[08:05] <GaryvdM> Hi all
[08:05] <poolie> when i get my thoughts in order i'll send an update
[08:05] <vila> poolie: and I couldn't find the time to track UDS
[08:05] <vila> poolie: cool
[08:06] <poolie> i feel a bit more convinced we should focus together on a smaller set of topics
[08:06] <vila> GaryvdM: hey !
[08:06] <GaryvdM> vila: I should be able to build windows installers tonight
[08:06] <poolie> and set them as goals for 2.3
[08:06] <poolie> hi gary
[08:06] <vila> GaryvdM: great !
[08:08] <vila> poolie: my foci for 2.3 are conflict resolution, config, sphinx, automated installer build, nightlies, I'll stop there ;)
[08:09] <jelmer> mwhudson: Did you manage to figure out what was wrong with the twisted branch?
[08:09] <jelmer> 'morning vila, poolie, GaryvdM
[08:09] <GaryvdM> Hi jelmer
[08:09] <vila> there is certainly work to do on tree transform, in-memory trees for tests for which I may find simple steps to progress
[08:09] <vila> jelmer: _o/
[08:10] <poolie> hi there jelmer
[08:10] <vila> poolie: in-memory trees is something I may start playing with in bzr-gardener where it will be easy to measure performance gains
[08:11] <poolie> vila, i think those are all good things (and they're pretty much what i thought you were doing)
[08:11] <vila> poolie: better ancestry graphs handling is a bit more work but again bzr-gardener would be a good sand box
[08:11] <poolie> but i wonder if we should either get more people onto them too, or set specific targets for 2.3
[08:12] <vila> poolie: I agree with the feeling but I haven't yet found the right means :-}
[08:12] <poolie> generally speaking i'm not a big fan of putting time into estimation when you could just spend it doing things, but...
[08:12] <vila> poolie: I have a bunch of notes about the next generation config I should submit (noted in my TODO) but it's still too much brain dump so far
[08:13] <vila> poolie: yeah, it's even harder if you try to do time estimates if you don't do the work yourself
[08:13] <vila> meh
[08:14] <vila> it's even harder to do reliable time estimates for things you don't do yourself
[08:21] <fullermd> That's never stopped my clients from telling me how long things should take...
[08:23] <vila> hehe, funny, I explained that recently: first you estimate how long it will take, then the sales guy decides how much it will sell it and when the whole price is decided, a new schedule is deduced
[08:24] <vila> somehow the sales guy always shorten the delay instead of the unit price, go figure why most projects are behind schedule after that...
[08:25] <spiv> fullermd: perhaps the deal should be "you can tell me how long it will take if I can then tell you what the 'per-hour' rate will be"
[08:25] <vila> spiv: oh, you *can* say that before the price is fixed, everybody always agree at this point :)
[08:26] <fullermd> I was talking with this guy I work with the other week about our respective current projects, both of which are wildly beyond their original conceptions in every way.
[08:26] <fullermd> Him: After this, I'm going to feel no shame at all about turning in astronomical estimates in the future.
[08:26] <fullermd> Me: I said that the last 6 projects.  I've learned that I suck at astronomy.
[08:27] <vila> fullermd: trivial details we don't want to hear about, what we care is: is is still the same price and the same delay, that's what you signed
[08:28] <fullermd> Oh sure.  It's just not the same project anymore   :)
[08:28] <vila> Me: but you said you wanted 'X' not half of the alphabet ! Them: don't start with the details again :)
[08:51] <vila> poolie: do you have any pending mail for contributor agreements ?
[08:52] <poolie> meaning new submissions?
[08:52] <vila> yup
[08:53] <poolie> from tzeentch?
[08:53] <vila> exactly
[08:55] <vila> ping losa, any news or feedback about rt #41340 ?
[08:58] <vila> Does anyone know the IRC nick for nmb ?
[08:58] <vila> aka Neil Martinsen-Burrell
[09:02] <vila> poolie, nmb: Am I nitpicking too much if I prefer check_output=True over blank_output_matches_anything=False in  https://code.edge.launchpad.net/~nmb/bzr/662509-ignore-blanks/+merge/38889 ?
[09:02] <vila> there is a slight ambiguity there that I fear will come back haunt us later...
[09:02] <poolie> vila, i don't seem to have a mail about that from tzeentch
[09:02] <poolie> i should go soon
[09:02] <GaryvdM> vila: it seems he does use 'nmb' - see http://irclogs.ubuntu.com/2008/08/26/%23bzr.html
[09:03] <vila> poolie: ok, I'll ping him via the review again then
[09:03] <vila> GaryvdM: great, thanks
[09:04] <poolie> to me 'check_output' doesn't make it so clear that this is specifically about the handling of blank output
[09:04] <poolie> also i think generally if there's a varargs option that defaults to off, it's better to have the non-default state be thing=True
[09:05] <vila> ok, then how about *empty*_output_matches_anything instead of blank_output_matches_anything
[09:06] <vila> which is really the itching part
[09:07] <vila> I still need to implement it for the test-script command anyway so I'm not asking nmb to do it
[09:14] <poolie> so the difference between 'empty' and 'blank' is key?
[09:22] <vila> poolie: well, 'key' may be a bit strong, but 'blank' in my mind means that a blank line is allowed which isn't true
[09:25] <poolie> true
[09:25] <poolie> ok, so s/blank/empty/ would be fine with me
[09:25] <poolie> or even s//null
[09:26] <vila> k
[09:27] <vila> so I'll make a submission with this tweak and implement it for test-script in a superseding submission
[09:32] <poolie> ok
[09:32] <poolie> so it's good night from me...
[09:36] <jbowtie> Just released bzr-tfs 0.3.0, with TFS 2010 and tfs.codeplex.com support
[09:38] <jelmer> jbowtie: \o/
[09:47] <GaryvdM> Bla - no python2.4/2.5 in lucid/mavrick
[09:48]  * GaryvdM starts building karmic vm...
[09:48] <vila> GaryvdM: err, I thought you can still install 2.4/2.5 in lucid no ?
[09:49] <GaryvdM> vila: you can build from source, but you can't apt-get install
[09:50] <GaryvdM> https://launchpad.net/ubuntu/+source/python2.5 - no lucid/maverick
[09:50] <vila> GaryvdM: my bad, you're right
[09:51] <vila> GaryvdM: I knew I had a VM for that, just misremember lucid instead of karmic ;)
[10:09] <fullermd> All those adjectives sound alike to me  ;p
[10:14] <maxb> GaryvdM: https://launchpad.net/~maxb/+archive/preserved may help for 2.5/lucid
[10:22] <mgz> jbowtie: you should make a post in that IronPython vcs thread
[10:31] <mgz> right, I'm off out.
[10:32] <GaryvdM> maxb: Thanks.
[10:32]  * GaryvdM waves to mgz
[10:52] <vila> ping losa, any news or feedback about rt #41340 ?
[11:03] <vila> mgz: rats, I missed you, ping me when you're back
[13:01] <vila> ping LOSA
[14:21] <vila> ping losa
[14:22] <Chex> vila: good morning there
[14:23] <vila> Chex: good morning !
[14:23] <vila> Chex:  any news or feedback about rt #41340 ?
[14:30] <Chex> vila: I am working on clearing a backlog of LOSA requests, give me a bit and  I will get back to you
[14:31] <vila> Chex: sure
[15:39] <elmo> hey, how do I get a specific branch using bzr-git?
[15:39] <jelmer> elmo: hi
[15:39] <elmo> bzr: ERROR: The repository you are fetching from contains submodules. To continue, upgrade your Bazaar repository to a format that supports nested trees, such as 'development-subtree'.
[15:39] <jelmer> elmo: there's no way to do that at the moment (bzr lacks the UI to specify non-head branches), although you can import all branches using "bzr git-import"
[15:40] <elmo> also, ^-- what?
[15:40] <elmo> jelmer: ok
[15:40] <elmo> I don't think i want to import all branches, that'd probably be rude
[15:40] <jelmer> elmo: your repository contains git submodules, which can not be mapped to anything in bzr yet
[15:40] <elmo> I guess I'll just have to face the music^Wgit
[15:40] <jelmer> elmo: "git clone" will fetch all branches too, so I don't think it would too rude to fetch all branches
[15:41] <jelmer> elmo: but yeah, for the moment you don't really have an alternative to using git if there are submodules.
[16:42] <quicksilver> vila: are you an ediff expert?
[16:45] <vila> quicksilver: ask your question, we'll see ;)
[16:45] <quicksilver> vila: I had a conflict which had more 'regions' that it should have
[16:45] <quicksilver> vila: two entirely different changes, coincidentally, shared a common line in the middle.
[16:45] <vila> weird but better than the opposite no ?
[16:46] <quicksilver> vila: I wanted to tell ediff "treat these two differences as one big difference"
[16:46] <quicksilver> so that I could then press the button which means 'keep both'
[16:46] <vila> why don't just you do it twice ?
[16:47] <vila> quicksilver: you know you can edit the regions too and then ask ediff to keep whatever you want
[16:48] <vila> ha no, you mean they shouldn't overlap the way they are displayed ?
[16:51] <quicksilver> vila: takes a moment to explain.
[16:51] <quicksilver> vila: tree A has "{preA}{common}{postA}"; tree B has "{preB}{common}{postB}"
[16:51] <quicksilver> vila: correct resolution is "{preA}{common}{postA} {preB}{common}{postB}"
[16:52] <quicksilver> vila: if I press "keep both" twice, I will get lines all interleave
[16:52] <quicksilver> "{preA}{preB}{common}{postA}{postB}"
[16:52] <quicksilver> vila: see?
[16:52] <vila> yeah, so you need to edit manually then
[16:52] <quicksilver> if I could say "treat this as one difference"
[16:52] <quicksilver> then "keep both" would be the right thing.
[16:52]  * vila nods
[16:53] <vila> does it occur frequently ?
[16:53] <quicksilver> in fact {common} was "my $self=shift;" which is a very common line in perl.
[16:53] <quicksilver> likely to occur at the beginning of many functions.
[16:53] <vila> yeah, as do '{' and such :-/
[16:53] <quicksilver> yes, that would be another obvious example
[16:53] <quicksilver> (although I've never had it happen with '{' I don't think)
[16:53] <vila> weak point in the diff algorithm...
[16:53]  * quicksilver nods
[16:54] <LeoNerd> I've often wanted with diff to "pin" two lines, to say that a specific line on each side was the "same" line
[16:54] <quicksilver> this is the first time I remember it happening exactly like this.
[16:54] <vila> pretty rare given the few feedback we get on such cases
[16:54] <quicksilver> vila: funnily enough I switched from emacs to Apple's Filemerge.app to resolve this one.
[16:54] <quicksilver> and Filemerge did the right thing anyway.
[16:55] <quicksilver> no idea why. It must have some heuristics for combining nearby regions.
[16:55] <vila> but the conflicts were generated by bzr right ?
[16:55] <quicksilver> yes.
[16:55] <quicksilver> I gave filemerge all four files file{,.BASE,.OTHER,.THIS}
[16:55] <quicksilver> and it worked it out.
[16:55] <vila> so patiencediff, the algo we use, is *generally* better, partly because it found this common line :-/
[16:56] <quicksilver> ;)
[16:56] <vila> so Filemerge certainly use a different algorithm and recalculate the conflicts from scratch ignoring bzr proposals
[16:56] <vila> I don't think we have an easy way to change the diff algo used by merge
[16:57] <vila> there are discussions about that though
[16:57]  * quicksilver nods
[16:57] <quicksilver> I don't often get conflicts which annoy me
[16:57] <quicksilver> but then again, we don't often let branches diverge all that far
[16:57] <quicksilver> this was a particularly long-lived, far-diverged branch.
[16:58] <vila> you can try 'bzr remerge <file>' with various options (but keep a copy of your file with your conflict resolution, remerge will destroy them)
[17:04] <mgz> vila ping, but I'm only in for an hour.
[17:04] <vila> mgz: ok, I wanted to ask about your connection hook mp
[17:05] <mgz> goforit.
[17:05] <vila> mgz: I think you should put it back in NeedsReview state so we can ping spiv :)
[17:06] <mgz> that sounds reasonable.
[17:07] <vila> I thought about it a bit more and I'm pretty sure we never reconnect because most of the time bzr+ssh is used and ssh never drops connections (or at least *I* never experimented that nor have I heard about such cases)
[17:08] <vila> so until reconnect is implemented for smart mediums, we can have two hooks, one for smart medium and one for the other transports
[17:08] <vila> they don't have to have the same signature at least to start with
[17:08] <mgz> sounds like it would work.
[17:08] <mgz> how much are we worried about burdening our future selves with interfaces we don't want any more?
[17:09] <vila> even if not perfect, that would allow progress in the right direction
[17:10] <vila> well, I don't know, but most probably at connection time you want to know the url and whatever info you can can gather about the client which is not much
[17:10] <quicksilver> vila: hmm, right.
[17:10] <quicksilver> vila: "weave" does a better job, for my needs, for this specific case
[17:11] <quicksilver> vila: what I mean is that 'weave' treats it as one big difference region
[17:11] <quicksilver> so 'keep both' is the right thing
[17:11] <vila> quicksilver: honestly no idea, but that the one I would try first
[17:11]  * quicksilver nods
[17:11] <quicksilver> thanks
[17:11] <quicksilver> ah no, it did something odd
[17:11] <quicksilver> it took into account my local changes already
[17:11] <quicksilver> hmm
[17:11] <quicksilver> I think I needed to back out my changes before remerging.
[17:12] <vila> quicksilver: it is supposed to do a better job for highly diverged branches
[17:13] <vila> quicksilver: err, what ? remerge redo the merge, it's not supposed to do that on top of your modifications
[17:14] <quicksilver> vila: I had already resolved the conflict
[17:14] <quicksilver> it appeared to take advante of my current file
[17:15] <quicksilver> the stuff in "TREE" contained the lines that, in fact, were never in "TREE"
[17:15] <quicksilver> (they were only present in OTHER, but they were present in my locally resolved copy of course)
[17:17]  * vila scratches head
[17:19] <vila> quicksilver: make a backup, then 'bzr revert <file>' 'bzr remerge --merge-type weave <file'
[17:19] <vila> >
[17:21] <quicksilver> vila: OK, expected result now.
[17:26] <quicksilver> vila: amusingly, smerge-ediff then "undoes" that improvment by automatically refining the diff when you enter ediff ;P
[17:26] <vila> :)
[18:52] <abentley> jam, james_w: recipe builds of lp:qtwebkit are causing problems because branching lp:qtwebit is taking lots of memory during the fetch.  My machine is up to 1G so far.
[18:53] <james_w> abentley, is this what was the immediate cause of the rollback of lp-buildd during UDS?
[18:54] <abentley> james_w: it seems likely.
[18:54] <abentley> james_w: Our logging isn't very good, so I can't be sure about the precise cause.
[18:55] <james_w> ok
[18:55] <abentley> bigjools believes that the large memory consumption is causing excessive swapping, which reduces responsiveness, which breaks other builders because we're doing synchronous polling.
[18:55] <james_w> abentley, I don't think it's a bzr-builder problem exactly? Just fetching with bzr shows the high memory usage?
[18:55] <jam> james_w: my direct test showed about 1gb for a "bzr branch"
[18:55] <jam> it is just a huge branch
[18:56] <jam> wide and deep
[18:56] <jam> (lots of files, lots of history)
[18:56] <abentley> james_w: yes, but maybe we can avoid the problem in bzr-builder.
[18:56] <jam> abentley: we killed the build earlier, not sure what to do right now
[18:57] <abentley> jam: VmPeak:	 1487216 kB here.
[18:57] <jam> abentley: 64bit machine?
[18:57] <jam> (I was testing on 32)
[18:57] <abentley> jam, no, 32.
[18:57] <abentley> jam, AIUI 1G is the max physical memory we can hope for.
[18:58] <jam> abentley: anyway it is arguably a bzrlib problem, but we don't have any quick-and-fast answers there
[18:58] <jam> I cut it in half for bzr 2.2, but large branches still take a lot of memory
[18:58] <jam> it is mostly the CHK stuff that is the problem
[18:58] <abentley> jam, Okay, I wasn't sure what the status was.  Thanks.
[18:59] <abentley> james_w: would it be reasonable to do lightweight checkouts instead of copying the branch?
[19:02] <james_w> abentley, we could if we analyze the recipe to check if we will do a commit as we build it
[19:03] <abentley> james_w: How do we determine whether we'll do a commit?
[19:04] <james_w> abentley, I think commits are just done after merges currently, but I can't remember for sure
[19:05] <abentley> james_w: they are done so that subsequent merges can use the correct parent information?
[19:06] <james_w> abentley, yes
[19:06] <james_w> nest-part as well now
[19:06] <james_w> so pretty much every recipe will commit
[19:07] <abentley> james_w: Okay, maybe stacked branches instead of lightweight checkouts?
[19:07] <james_w> yes, that would work
[19:07] <james_w> will that cut down memory usage in this case?
[19:07] <abentley> james_w: Okay, I'll see if that actually cuts down memory usage.
[19:08] <james_w> heh :-)
[19:08] <jam> james_w, abentley: Except for the current bug that we refuse to commit in a stacked branch because of issues with stacking and basis inventories
[19:08] <james_w> ah
[19:09] <abentley> jam, doh.
[19:09] <abentley> james_w: btw, nest-part is a partial merge, so its parent information should not be recorded.
[19:10] <james_w> abentley, I assume that is taken care of
[19:11] <abentley> james_w: Sorry, what do you mean by "nest-part as well now"?
[19:20] <james_w> abentley, nest-part does a commit after doing the work
[19:21] <abentley> james_w: I can understand that merge would do a commit after doing the work in order to allow subsequent merges to use the correct parent information.  Since nest-part cannot introduce parent information, why does it do a commit?
[19:22] <james_w> abentley, I don't know
[19:51] <mwhudson> jelmer: nothing more than was discussed here
[21:06] <BasicOSX> bzr branch remote only gives me the .bzr directory, drawing a blank on how to get the actual files to work on. Anyone help me?
[21:09] <lifeless> you've got a local notrees shared repo
[21:09] <lifeless> 'bzr checkout .' will populate a tree on a branch
[21:10] <jam> mwhudson: sorry about the email spam. I normally don't re-use branches, does it send 1 email per mainline rev?
[21:13] <mwhudson> jam: it's ok, i can ignore email pretty effectively :)
[21:13] <mwhudson> and yeah, one mail per rev
[21:22] <jam> mwhudson: do you know if there is a decent way to check if a daemon has exited? (Namely, something that is not a child so you can't waitpid() on it)
[21:23] <mwhudson> jam: not really, you can send the "signal" 0 to it if you had the pid and interpret the result
[21:24] <jam> mwhudson: this is for the test suite. the mthaddon
[21:24] <jam> noted that we needed a pid file
[21:24] <jam> so that indicated I should be daemonizing
[21:24] <jam> and I wanted to start and stop such a thing cleanly
[21:24] <jam> and have the test suite wait for it to exit
[21:24] <jam> but... not very easy to get right, from what I can tell
[21:25] <exarkun> If you rely on PIDs, then there's race conditions
[21:25] <jam> exarkun: there is, but I'm not worried about spawning 32k processes in the meantime
[21:25] <exarkun> If the daemon is listening on a unix socket, then connect attempts to that socket will begin to fail after it exits
[21:26] <exarkun> jam: It's not just processes.
[21:26] <exarkun> Maybe it's just as unlikely to have a TID collision, but I don't know how TIDs are allocated.
[21:40] <jam> mwhudson: I don't remember if you're a vim or emacs guy. Any chance you know about pyflakes + vim?
[21:41] <mwhudson> jam: i've been using emacs for ~one third of my life now :-)
[21:41] <mwhudson> jam: for the daemons, there is some hair in the launchpad code base for this already
[21:42] <mwhudson> jam: lifeless has been working on it recently, i think there is a librarianfixture somewhere you could maybe crib from
[21:42] <jam> mwhudson: I'm not sure if that is a long time or not :)
[21:42] <mwhudson> although that might be oriented around twisted daemons, come to think of it
[21:43] <jam> mwhudson: I went with a simple loop around os.kill(..., 0) and trapping ESRCH
[21:57] <jam> mwhudson: mind if I nominate you to review the updated patch?
[22:00] <mwhudson> jam: no
[22:01] <jam> mwhudson: https://code.edge.launchpad.net/~jameinel/launchpad/lp-service/+merge/40386
[22:01] <jam> I don't know the specific urgency
[22:01] <jam> I can't deploy to qastaging until that is fixed
[22:01] <jam> but the l-o-s-
[22:01] <jam> are out-of-town this week
[22:02] <jam> so I may not be able to anyway,
[22:04] <mwhudson> i really hope there's some library code somewhere you could have used rather than writing all that from scratch :/
[22:04] <mwhudson> lifeless: hi
[22:05] <lifeless> hi
[22:05] <mwhudson> lifeless: i know you've been working on external process stuff for tests recently, can you look at https://code.edge.launchpad.net/~jameinel/launchpad/lp-service/+merge/40386 ?
[22:05] <peitschie> mornin everybody :)
[22:06] <mwhudson> lifeless: and see if you know if there is library code for any of this?
[22:06] <lifeless> there is in twistd
[22:08] <mwhudson> yeah
[22:08] <mwhudson> i guess that's a "no" then really
[22:09] <jam> mwhudson: well the fork-a-daemon code was taken from a "python daemon" search and tweaked for my use case
[22:10] <jam> so I didn't have to write it completely manually
[22:10] <lifeless> mwhudson: that glue isn't what I've been working on; though I'd certainly want a Fixture wrapping it.
[22:10] <lifeless> it would be nice to have bin/run know about it too
[22:11] <mwhudson> bin/run runs the service already, but not as a daemon
[22:12] <jam> lifeless: yeah, bin/run and runlaunchpad.py know how to do it, but that isn't how they run things in production
[22:13] <jam> just one of the pain points for this experiment.
[22:17] <mwhudson> jam: might it be better to wait for the daemon to respond to hello than to write its pid file?
[22:17] <jam> mwhudson: I'm not sure i understand
[22:18] <mwhudson> jam: in TestCaseWithLPForkingServiceDaemon._start_subprocess
[22:18] <jam> are you saying the service shouldn't write its own pid file until it gets a request?
[22:18] <mwhudson> jam: no, i'm saying the test helper should wait until a request gets a response
[22:20] <jam> mwhudson: fair point, anything else?
[22:20] <millun> hi guys
[22:20] <millun> can i ask something?
[22:20] <millun> i've pushed a branch up on an FTP account
[22:21] <millun> what do i do now? (in bzr explorer)
[22:21] <jam> mwhudson: I need the pid for other reasons, but I could wait for hello and then check the file
[22:21] <millun> when i try to checkout - bzr explorer asks me like 3 times about the password
[22:21] <mwhudson> jam: it just seems that there is a tiny possibility of a race
[22:21] <mwhudson> with the current code
[22:22] <jam> millun: I believe the recommendation is to use a full branch and not to use a lightweight checkout for a remote branch
[22:22] <jam> mwhudson: where?
[22:22] <jam> I don't doubt it
[22:22] <jam> you can't use the normal "waitpid()" sort of tools
[22:22] <mwhudson> jam: just the thing we were talking about already
[22:22] <mwhudson> the daemon writes this pid before it listens on the socket
[22:23] <millun> jam,
[22:24] <millun> jam i thought at first that i need to checkout becAuse branching offered me shared repository while i need colocated
[22:24] <millun> right?
[22:24] <spiv> 'write pid file' and 'service is ready' aren't quite the same thing.
[22:24] <jam> millun: if you need collocated, you still want a local branch to checkout
[22:25] <poolie> hi mwhudson, jam
[22:25] <poolie> spiv
[22:25] <jam> spiv: well, it could be, it depends how I write the code :)
[22:25] <millun> is collocated already a property of the branch? or it matters from user to user
[22:25] <jam> millun: layout is a property of the user
[22:26] <jam> well, location
[22:27] <millun> Bind new branch to parent location? (should i check this?
[22:27] <millun> i am using colocated branches in /Var/www/projectname
[22:28] <GaryvdM> millun: A work arround to the password problem is to put the password in authentication.conf (Settings -> Credentials in bzr explorer) http://doc.bazaar.canonical.com/latest/en/user-reference/configuration-help.html#the-authentication-configuration-file-authentication-conf
[22:30] <GaryvdM> millun: I'm working on making bzr explorer/qbzr keep it connections open, so that it does not have to ask for the password so often, but this is going to take a while...
[22:32] <poolie> hi there GaryvdM
[22:32] <GaryvdM> Hi poolie
[22:32] <mwhudson> jam: i asked for a couple of small changes
[22:34] <jam> mwhudson: I was pretty sure that you need setsid() to guarantee you'll disconnect from the terminal
[22:35] <mwhudson> jam: ok
[22:35] <jam> mwhudson: http://www.itp.uzh.ch/~dpotter/howto/daemonize
[22:35] <millun> cool GaryvdM
[22:38] <millun> jam: so i need to create a shared repo in /var/www/ and branch to /var/www/projectname. instead of /var/www/projectname/trunk
[22:38] <jam> btw, hi poolie, nice to you have you back around and online
[22:39] <poolie> thanks, it's good to be back
[22:39] <poolie> we should send some news from uds while it's relatviely fresh
[22:40] <glyph> Hello!
[22:40] <millun> does it make any sense?
[22:41] <glyph> I have recently discovered that the twistedmatrix.com bzr mirror has some old revisions that were generated with an earlier version of bzr-svn ("v3" in revids, I don't know what version that corresponds to)
[22:41] <glyph> and this causes problems
[22:41] <glyph> I am wondering how I should go about fixing this
[22:41] <glyph> or rather, what the suggested 'best practice' (if there is such a thing) for dealing with data which is similarly not-quite-corrupt-but-still-problematic
[22:42] <jam> millun: I personally don't know the 'colocated' style that bzr-explorer mentions very well.
[22:42] <spiv> glyph: mwhudson looked at this yesterday
[22:42] <GaryvdM> glyph: Hello. I saw in my logs that you were looking at the fonts in qbzr. I've landed a patch in qbzr trunk to have the mono space font defined in one place.
[22:42] <jam> and I'm not sure whether you are saying it is your personal need for where it goes, or whether you are asking if it is how bzr-explorer wants it
[22:43] <glyph> GaryvdM: Yay.  Is it a place where I can customize it? :)
[22:43] <spiv> glyph: it appears to be more that the svn repo itself contains some revisions stamped with v3 revids (on trunk even)
[22:43] <glyph> spiv: oh, crap :(
[22:44] <glyph> wait a second
[22:44] <glyph> is that actually a problem?
[22:44] <GaryvdM> glyph: It now also tries to use "Monospace" before "Courier New"
[22:44] <spiv> glyph: well!
[22:44] <glyph> if they're stamped as such, presumably everyone will agree on the revid and there won't be an issue.
[22:44] <spiv> glyph: so bzr-svn presumably is helpfully preserving the v3-ness of revs before the latest rev stamped that
[22:44] <glyph> GaryvdM: even better
[22:44] <glyph> spiv: except sometimes when it isn't?
[22:44] <spiv> And assuming the better v4 format for later revs
[22:44] <jam> mwhudson: due to layering, I went with "wait for the socket to exist" rather than "wait for a message on the socket". Is that sufficient for you?
[22:45] <jam> at that point you can try to connect at least.
[22:45] <jelmer> glyph: I'm trying to reproduce the issue here, but it's taking a very long time to pull all revisions down
[22:45] <mwhudson> jam: yeah
[22:45] <spiv> glyph: but if you have an old branch from before that point it'll be v3.  Or something.
[22:45] <glyph> jelmer: well, that's the bug, innit ;)
[22:46] <glyph> spiv: Oh.  If I have an old branch from before that point it will pull it down *as v4*, because since there are new stamped revs it will just assume that branch should be the newest, goodest thing.
[22:46] <jelmer> glyph: not necessarily, I'm not sure if there's a good reason one branch is a different mapping than the other
[22:46] <glyph> ahem
[22:46] <spiv> glyph: jelmer is about 100x more of an authority on this than me of course
[22:46] <glyph> _no_ stamped revs
[22:46] <jam> mwhudson: k, pushed, and ready for your re-review
[22:46] <glyph> in that branch's history.
[22:46] <spiv> glyph: btw, r23001 in svn trunk
[22:46] <GaryvdM> glyph: No customization yet   - I would like to have code to get your desktop setting. I cant find a way to do this, so I may end up coding a version for gnone, kde, mac.
[22:46] <jam> mwhudson: my EOD. but I'll respond to anything tonight/tomorrow if you have any more feedback
[22:47] <GaryvdM> * I cant find a way to do this with qt...
[22:47] <jam> I get to take my son to "soccer" practice (for 3yr old) should be a lot of fun
[22:47] <mwhudson> jam: ok, i guess i'll throw it at ec2 land :-)
[22:47] <spiv> glyph: I'm honestly not sure at all
[22:48] <glyph> spiv: That's the behavior I'm seeing.
[22:48] <glyph> Looking at the local bzr log of these branches I've got.
[22:48] <glyph> So, probably the best thing to do practically speaking for this branch would be to destructively rebase the branch using svn ('merge forward') and then just start over
[22:49] <spiv> glyph: my wild guess is... probably?
[22:49] <glyph> it's only got one revision in it anyway, and desperately needs to be updated to be more current with trunk, so there's not a lot to lose :)
[22:50] <glyph> spiv: so, thanks for the explanation of the preserving-the-v3-ness based on revision order in SVN, that was a key clue :)
[22:50] <glyph> exarkun: you may be interested in that discussion in case you do some old twisted branches with bzr
[22:50] <exarkun> I'm less interested in discussion and more interested in tools that work
[22:51] <spiv> glyph: well, thank mwhudson more than me :)
[22:51] <spiv> exarkun: here's the short form, as I understand:
[22:51] <spiv> exarkun: land your branches faster and there'd be no problem :P
[22:51] <glyph> exarkun: oh.  #git, in that case, I guess? :P
[22:51] <exarkun> glyph: oh man.  you said it, not me.
[22:51] <spiv> I'm sure jelmer will figure out how to make it work better, though.
[22:51] <glyph> exarkun: "If you're working with a very old branch, merge it forward in SVN first, to avoid this problem."
[22:52] <glyph> I can be more specific than that, with a precise revision number, but that's a good rule of thumb.  Maybe that's what spiv meant by 'r23001'?
[22:53] <mwhudson> radix committed something to trunk with bzr
[22:54] <radix> what
[22:54] <radix> what
[22:54] <exarkun> radix: why do you always break everything
[22:54] <radix> what
[22:54] <glyph> radix: yeah man what the hell is your problem
[22:54] <radix> did I break something like three years ago
[22:54] <radix> is that what this is about
[22:54] <glyph> radix: don't worry, dash would have broken it if you hadn't.
[22:55] <mwhudson> and yeah, svn 23001 was it
[22:55]  * jelmer wonders if he should phase out file property-based bzr-svn metadata
[23:25] <GaryvdM> Good night all zzzzzz