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:27 |
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 | 00:34 |
=== timchen119 is now known as nasloc__ | ||
spiv | vila: https://bugs.launchpad.net/bzr/+bug/672382 | 03:23 |
ubot5 | Launchpad bug 672382 in Bazaar "bzr config output for list values is ugly (affected: 1, heat: 6)" [Medium,Confirmed] | 03:23 |
poolie | hi all | 03:37 |
spiv | poolie: hey, welcome back! | 03:43 |
poolie | hi there | 03:43 |
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:44 |
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 | 03:58 |
lifeless | poolie: lol - boeing considered a 650seat 747 | 04:23 |
lifeless | poolie: the 400ER 3-class seats 416 according to http://en.wikipedia.org/wiki/Boeing_747 | 04:24 |
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:25 |
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:26 |
lifeless | http://www.qantas.com.au/travel/airlines/a380/global/en agrees with the figures | 04:27 |
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:28 |
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:29 |
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:30 |
lifeless | emirates seem to have an excellent deal there | 04:31 |
lifeless | (if you're paying in that bracket) | 04:31 |
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:32 |
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:33 |
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:34 |
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* | 04:35 |
vila | hi all ! | 07:00 |
=== gthorslund_ is now known as gthorslund | ||
=== vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | Release Manager: vila | 2.3b3 has gone gold, time to build the installers ! | work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/ | ||
* KombuchaKip is unsure why his client randomly decided to log himself into #bzr | 07:02 | |
gthorslund | hi vila! | 07:03 |
vila | _o/ | 07:03 |
poolie | hello vila | 07:46 |
vila | poolie: hey ! | 07:46 |
poolie | how are things with you? | 07:50 |
vila | fine ! A large plate for the week but I'm hungry :-P | 07:50 |
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:51 |
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:52 |
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:53 |
vila | deep down though, the bug is revealing a hole in the test coverage (big surprise :-) | 07:54 |
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:56 |
fullermd | Getting lazy in your old age or somethin'? :p | 07:57 |
vila | hehe | 07:57 |
vila | my age always seem to inversely proportional to the fun I have, or something ;) | 07:58 |
fullermd | Well, at least you spend less on bail money ;) | 07:59 |
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:01 |
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:02 |
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:04 |
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:05 |
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:06 |
vila | poolie: my foci for 2.3 are conflict resolution, config, sphinx, automated installer build, nightlies, I'll stop there ;) | 08:08 |
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:09 |
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:10 |
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:11 |
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:12 |
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:13 |
vila | it's even harder to do reliable time estimates for things you don't do yourself | 08:14 |
fullermd | That's never stopped my clients from telling me how long things should take... | 08:21 |
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:23 |
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:24 |
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:25 |
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:26 |
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:27 |
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:28 |
vila | poolie: do you have any pending mail for contributor agreements ? | 08:51 |
poolie | meaning new submissions? | 08:52 |
vila | yup | 08:52 |
poolie | from tzeentch? | 08:53 |
vila | exactly | 08:53 |
vila | ping losa, any news or feedback about rt #41340 ? | 08:55 |
vila | Does anyone know the IRC nick for nmb ? | 08:58 |
vila | aka Neil Martinsen-Burrell | 08:58 |
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:02 |
vila | poolie: ok, I'll ping him via the review again then | 09:03 |
vila | GaryvdM: great, thanks | 09:03 |
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:04 |
vila | ok, then how about *empty*_output_matches_anything instead of blank_output_matches_anything | 09:05 |
vila | which is really the itching part | 09:06 |
vila | I still need to implement it for the test-script command anyway so I'm not asking nmb to do it | 09:07 |
poolie | so the difference between 'empty' and 'blank' is key? | 09:14 |
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:22 |
poolie | true | 09:25 |
poolie | ok, so s/blank/empty/ would be fine with me | 09:25 |
poolie | or even s//null | 09:25 |
vila | k | 09:26 |
vila | so I'll make a submission with this tweak and implement it for test-script in a superseding submission | 09:27 |
poolie | ok | 09:32 |
poolie | so it's good night from me... | 09:32 |
jbowtie | Just released bzr-tfs 0.3.0, with TFS 2010 and tfs.codeplex.com support | 09:36 |
jelmer | jbowtie: \o/ | 09:38 |
GaryvdM | Bla - no python2.4/2.5 in lucid/mavrick | 09:47 |
* GaryvdM starts building karmic vm... | 09:48 | |
vila | GaryvdM: err, I thought you can still install 2.4/2.5 in lucid no ? | 09:48 |
GaryvdM | vila: you can build from source, but you can't apt-get install | 09:49 |
GaryvdM | https://launchpad.net/ubuntu/+source/python2.5 - no lucid/maverick | 09:50 |
vila | GaryvdM: my bad, you're right | 09:50 |
vila | GaryvdM: I knew I had a VM for that, just misremember lucid instead of karmic ;) | 09:51 |
fullermd | All those adjectives sound alike to me ;p | 10:09 |
maxb | GaryvdM: https://launchpad.net/~maxb/+archive/preserved may help for 2.5/lucid | 10:14 |
mgz | jbowtie: you should make a post in that IronPython vcs thread | 10:22 |
mgz | right, I'm off out. | 10:31 |
GaryvdM | maxb: Thanks. | 10:32 |
* GaryvdM waves to mgz | 10:32 | |
vila | ping losa, any news or feedback about rt #41340 ? | 10:52 |
vila | mgz: rats, I missed you, ping me when you're back | 11:03 |
vila | ping LOSA | 13:01 |
vila | ping losa | 14:21 |
Chex | vila: good morning there | 14:22 |
vila | Chex: good morning ! | 14:23 |
vila | Chex: any news or feedback about rt #41340 ? | 14:23 |
Chex | vila: I am working on clearing a backlog of LOSA requests, give me a bit and I will get back to you | 14:30 |
vila | Chex: sure | 14:31 |
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:39 |
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:40 |
jelmer | elmo: but yeah, for the moment you don't really have an alternative to using git if there are submodules. | 15:41 |
=== beuno is now known as beuno-lunch | ||
=== deryck is now known as deryck[lunch] | ||
quicksilver | vila: are you an ediff expert? | 16:42 |
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:45 |
=== beuno-lunch is now known as beuno | ||
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:46 |
vila | quicksilver: you know you can edit the regions too and then ask ediff to keep whatever you want | 16:47 |
vila | ha no, you mean they shouldn't overlap the way they are displayed ? | 16:48 |
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:51 |
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:52 | |
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:53 | |
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:54 |
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:55 |
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:56 |
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:57 |
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) | 16:58 |
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:04 |
mgz | goforit. | 17:05 |
vila | mgz: I think you should put it back in NeedsReview state so we can ping spiv :) | 17:05 |
mgz | that sounds reasonable. | 17:06 |
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:07 |
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:08 |
vila | even if not perfect, that would allow progress in the right direction | 17:09 |
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:10 |
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:11 |
vila | quicksilver: it is supposed to do a better job for highly diverged branches | 17:12 |
vila | quicksilver: err, what ? remerge redo the merge, it's not supposed to do that on top of your modifications | 17:13 |
quicksilver | vila: I had already resolved the conflict | 17:14 |
quicksilver | it appeared to take advante of my current file | 17:14 |
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:15 |
* vila scratches head | 17:17 | |
vila | quicksilver: make a backup, then 'bzr revert <file>' 'bzr remerge --merge-type weave <file' | 17:19 |
vila | > | 17:19 |
quicksilver | vila: OK, expected result now. | 17:21 |
quicksilver | vila: amusingly, smerge-ediff then "undoes" that improvment by automatically refining the diff when you enter ediff ;P | 17:26 |
=== deryck[lunch] is now known as deryck | ||
vila | :) | 17:26 |
=== zyga is now known as zyga-afk | ||
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:52 |
james_w | abentley, is this what was the immediate cause of the rollback of lp-buildd during UDS? | 18:53 |
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:54 |
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:55 |
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:56 |
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:57 |
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:58 |
abentley | james_w: would it be reasonable to do lightweight checkouts instead of copying the branch? | 18:59 |
=== Meths_ is now known as Meths | ||
=== yailuj24 is now known as nailuj24 | ||
james_w | abentley, we could if we analyze the recipe to check if we will do a commit as we build it | 19:02 |
abentley | james_w: How do we determine whether we'll do a commit? | 19:03 |
james_w | abentley, I think commits are just done after merges currently, but I can't remember for sure | 19:04 |
abentley | james_w: they are done so that subsequent merges can use the correct parent information? | 19:05 |
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:06 |
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:07 |
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:08 |
abentley | jam, doh. | 19:09 |
abentley | james_w: btw, nest-part is a partial merge, so its parent information should not be recorded. | 19:09 |
james_w | abentley, I assume that is taken care of | 19:10 |
abentley | james_w: Sorry, what do you mean by "nest-part as well now"? | 19:11 |
james_w | abentley, nest-part does a commit after doing the work | 19:20 |
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:21 |
james_w | abentley, I don't know | 19:22 |
=== lifeless_ is now known as lifeless | ||
mwhudson | jelmer: nothing more than was discussed here | 19:51 |
=== zyga-afk is now known as khr | ||
=== khr is now known as zyga | ||
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:06 |
lifeless | you've got a local notrees shared repo | 21:09 |
lifeless | 'bzr checkout .' will populate a tree on a branch | 21:09 |
jam | mwhudson: sorry about the email spam. I normally don't re-use branches, does it send 1 email per mainline rev? | 21:10 |
mwhudson | jam: it's ok, i can ignore email pretty effectively :) | 21:13 |
mwhudson | and yeah, one mail per rev | 21:13 |
=== Ursinha is now known as Ursinha-afk | ||
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:22 |
mwhudson | jam: not really, you can send the "signal" 0 to it if you had the pid and interpret the result | 21:23 |
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:24 |
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:25 |
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:26 |
jam | mwhudson: I don't remember if you're a vim or emacs guy. Any chance you know about pyflakes + vim? | 21:40 |
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:41 |
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:42 |
jam | mwhudson: I went with a simple loop around os.kill(..., 0) and trapping ESRCH | 21:43 |
jam | mwhudson: mind if I nominate you to review the updated patch? | 21:57 |
=== zyga is now known as zyga-afk | ||
mwhudson | jam: no | 22:00 |
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:01 |
jam | so I may not be able to anyway, | 22:02 |
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:04 |
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:05 |
mwhudson | lifeless: and see if you know if there is library code for any of this? | 22:06 |
lifeless | there is in twistd | 22:06 |
mwhudson | yeah | 22:08 |
mwhudson | i guess that's a "no" then really | 22:08 |
jam | mwhudson: well the fork-a-daemon code was taken from a "python daemon" search and tweaked for my use case | 22:09 |
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:10 |
mwhudson | bin/run runs the service already, but not as a daemon | 22:11 |
jam | lifeless: yeah, bin/run and runlaunchpad.py know how to do it, but that isn't how they run things in production | 22:12 |
jam | just one of the pain points for this experiment. | 22:13 |
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:17 |
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:18 |
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:20 |
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:21 |
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:22 |
millun | jam, | 22:23 |
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:24 |
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:25 |
jam | well, location | 22:26 |
millun | Bind new branch to parent location? (should i check this? | 22:27 |
millun | i am using colocated branches in /Var/www/projectname | 22:27 |
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:28 |
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:30 |
poolie | hi there GaryvdM | 22:32 |
GaryvdM | Hi poolie | 22:32 |
mwhudson | jam: i asked for a couple of small changes | 22:32 |
jam | mwhudson: I was pretty sure that you need setsid() to guarantee you'll disconnect from the terminal | 22:34 |
mwhudson | jam: ok | 22:35 |
jam | mwhudson: http://www.itp.uzh.ch/~dpotter/howto/daemonize | 22:35 |
millun | cool GaryvdM | 22:35 |
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:38 |
poolie | thanks, it's good to be back | 22:39 |
poolie | we should send some news from uds while it's relatviely fresh | 22:39 |
glyph | Hello! | 22:40 |
millun | does it make any sense? | 22:40 |
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:41 |
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:42 |
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:43 |
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:44 |
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:45 |
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:46 |
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:47 |
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:48 |
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:49 |
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:50 |
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:51 |
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:52 |
mwhudson | radix committed something to trunk with bzr | 22:53 |
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:54 |
mwhudson | and yeah, svn 23001 was it | 22:55 |
* jelmer wonders if he should phase out file property-based bzr-svn metadata | 22:55 | |
GaryvdM | Good night all zzzzzz | 23:25 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!