[00:27] NET||abuse: you said you have a branch on your local machine... is that a branch or a checkout? [00:27] branch [00:34] 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] pull === timchen119 is now known as nasloc__ [03:23] vila: https://bugs.launchpad.net/bzr/+bug/672382 [03:23] Launchpad bug 672382 in Bazaar "bzr config output for list values is ugly (affected: 1, heat: 6)" [Medium,Confirmed] [03:37] hi all [03:43] poolie: hey, welcome back! [03:43] hi there [03:44] it's good to be back; those were not the smoothest flights i ever had [03:44] I imagine Qantas is pretty chaotic atm. [03:58] very [03:58] there were something like 10 staff deadheading on our flight [03:58] 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] poolie: lol - boeing considered a 650seat 747 [04:24] poolie: the 400ER 3-class seats 416 according to http://en.wikipedia.org/wiki/Boeing_747 [04:25] poolie: and the A380 450 [04:25] (from adding the numbers in http://www.seatguru.com/airlines/Qantas_Airways/Qantas_Airways_Airbus_A380.php) [04:26] ok, and the a380 is somewhere around 650? [04:26] ah, so not such a big difference [04:26] i guess the qf a380s have a lot of business class seats [04:26] 72! [04:27] http://www.qantas.com.au/travel/airlines/a380/global/en agrees with the figures [04:28] on my flight across they realocated some business seats to premium class, and some premium seats to economy [04:28] you were scheduled on an a380 flight ? [04:29] on the way back i was meant to be on an a380 from lax-syd [04:29] nice [04:29] i eventually flew on a 747 because all their a380s are grounded [04:30] it was very chaotic [04:30] some people had already been waiting around LA for three days [04:30] http://www.nzherald.co.nz/business/news/article.cfm?c_id=3&objectid=10686109 [04:31] emirates seem to have an excellent deal there [04:31] (if you're paying in that bracket) [04:32] 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] for sure [04:33] as far as I'm concerned its all about the sleeping [04:33] perhaps slightly more considerately, but they still have to stand around in the gate lounge wondering if they will ever leave [04:33] me too [04:33] sleeping and power [04:33] and air NZ have power in economy ;) [04:33] i used points to get premium to sfo on the way across, and ended up getting a business physical seat [04:33] (with premium-grade food etc) [04:33] and that was brilliant [04:33] poolie: -lol- nice [04:34] I'm surprised they bothered splitting your menu our [04:34] out [04:34] poolie: hurrah! [04:34] ok, afkish [04:34] i think they have semipermanently reallocated some rows to other classes [04:34] hugh got a premium seat without technically being upgraded [04:35] anyhow i'm just catching up on bills, mail stuff [04:35] ping me if there's anything urgent [04:35] *nod* [07:00] hi all ! === 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/ [07:02] * KombuchaKip is unsure why his client randomly decided to log himself into #bzr [07:03] hi vila! [07:03] _o/ [07:46] hello vila [07:46] poolie: hey ! [07:50] how are things with you? [07:50] fine ! A large plate for the week but I'm hungry :-P [07:51] pp'ing, releasing 2.3b3, more conflict resolution, bzr config bugs, plenty of fun ahead :) [07:51] cool :) [07:51] i've seen some of this [07:52] the conflict features sound good [07:52] it seesm like it's more in the way of user feedback than bugs as such? [07:53] 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] deep down though, the bug is revealing a hole in the test coverage (big surprise :-) [07:56] 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] Getting lazy in your old age or somethin'? :p [07:57] hehe [07:58] my age always seem to inversely proportional to the fun I have, or something ;) [07:59] Well, at least you spend less on bail money ;) [08:01] 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] that would be kind of nice [08:02] it'd be better if it could get unified with other things that deal with sets of branches, like colo [08:02] i may package that this week, if max and jelmer haven't already [08:04] 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] vila did john tell you anything much about uds? [08:05] it was a good trip [08:05] (well, the travel kinda sucked, but the meetings were good) [08:05] poolie: not that much, he seem pretty busy on other subjects these days... [08:05] Hi all [08:05] when i get my thoughts in order i'll send an update [08:05] poolie: and I couldn't find the time to track UDS [08:05] poolie: cool [08:06] i feel a bit more convinced we should focus together on a smaller set of topics [08:06] GaryvdM: hey ! [08:06] vila: I should be able to build windows installers tonight [08:06] and set them as goals for 2.3 [08:06] hi gary [08:06] GaryvdM: great ! [08:08] poolie: my foci for 2.3 are conflict resolution, config, sphinx, automated installer build, nightlies, I'll stop there ;) [08:09] mwhudson: Did you manage to figure out what was wrong with the twisted branch? [08:09] 'morning vila, poolie, GaryvdM [08:09] Hi jelmer [08:09] 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] jelmer: _o/ [08:10] hi there jelmer [08:10] 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] vila, i think those are all good things (and they're pretty much what i thought you were doing) [08:11] poolie: better ancestry graphs handling is a bit more work but again bzr-gardener would be a good sand box [08:11] but i wonder if we should either get more people onto them too, or set specific targets for 2.3 [08:12] poolie: I agree with the feeling but I haven't yet found the right means :-} [08:12] generally speaking i'm not a big fan of putting time into estimation when you could just spend it doing things, but... [08:12] 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] poolie: yeah, it's even harder if you try to do time estimates if you don't do the work yourself [08:13] meh [08:14] it's even harder to do reliable time estimates for things you don't do yourself [08:21] That's never stopped my clients from telling me how long things should take... [08:23] 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] 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] 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] spiv: oh, you *can* say that before the price is fixed, everybody always agree at this point :) [08:26] 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] Him: After this, I'm going to feel no shame at all about turning in astronomical estimates in the future. [08:26] Me: I said that the last 6 projects. I've learned that I suck at astronomy. [08:27] 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] Oh sure. It's just not the same project anymore :) [08:28] Me: but you said you wanted 'X' not half of the alphabet ! Them: don't start with the details again :) [08:51] poolie: do you have any pending mail for contributor agreements ? [08:52] meaning new submissions? [08:52] yup [08:53] from tzeentch? [08:53] exactly [08:55] ping losa, any news or feedback about rt #41340 ? [08:58] Does anyone know the IRC nick for nmb ? [08:58] aka Neil Martinsen-Burrell [09:02] 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] there is a slight ambiguity there that I fear will come back haunt us later... [09:02] vila, i don't seem to have a mail about that from tzeentch [09:02] i should go soon [09:02] vila: it seems he does use 'nmb' - see http://irclogs.ubuntu.com/2008/08/26/%23bzr.html [09:03] poolie: ok, I'll ping him via the review again then [09:03] GaryvdM: great, thanks [09:04] to me 'check_output' doesn't make it so clear that this is specifically about the handling of blank output [09:04] 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] ok, then how about *empty*_output_matches_anything instead of blank_output_matches_anything [09:06] which is really the itching part [09:07] I still need to implement it for the test-script command anyway so I'm not asking nmb to do it [09:14] so the difference between 'empty' and 'blank' is key? [09:22] 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] true [09:25] ok, so s/blank/empty/ would be fine with me [09:25] or even s//null [09:26] k [09:27] so I'll make a submission with this tweak and implement it for test-script in a superseding submission [09:32] ok [09:32] so it's good night from me... [09:36] Just released bzr-tfs 0.3.0, with TFS 2010 and tfs.codeplex.com support [09:38] jbowtie: \o/ [09:47] Bla - no python2.4/2.5 in lucid/mavrick [09:48] * GaryvdM starts building karmic vm... [09:48] GaryvdM: err, I thought you can still install 2.4/2.5 in lucid no ? [09:49] vila: you can build from source, but you can't apt-get install [09:50] https://launchpad.net/ubuntu/+source/python2.5 - no lucid/maverick [09:50] GaryvdM: my bad, you're right [09:51] GaryvdM: I knew I had a VM for that, just misremember lucid instead of karmic ;) [10:09] All those adjectives sound alike to me ;p [10:14] GaryvdM: https://launchpad.net/~maxb/+archive/preserved may help for 2.5/lucid [10:22] jbowtie: you should make a post in that IronPython vcs thread [10:31] right, I'm off out. [10:32] maxb: Thanks. [10:32] * GaryvdM waves to mgz [10:52] ping losa, any news or feedback about rt #41340 ? [11:03] mgz: rats, I missed you, ping me when you're back [13:01] ping LOSA [14:21] ping losa [14:22] vila: good morning there [14:23] Chex: good morning ! [14:23] Chex: any news or feedback about rt #41340 ? [14:30] vila: I am working on clearing a backlog of LOSA requests, give me a bit and I will get back to you [14:31] Chex: sure [15:39] hey, how do I get a specific branch using bzr-git? [15:39] elmo: hi [15:39] 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] 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] also, ^-- what? [15:40] jelmer: ok [15:40] I don't think i want to import all branches, that'd probably be rude [15:40] elmo: your repository contains git submodules, which can not be mapped to anything in bzr yet [15:40] I guess I'll just have to face the music^Wgit [15:40] elmo: "git clone" will fetch all branches too, so I don't think it would too rude to fetch all branches [15:41] elmo: but yeah, for the moment you don't really have an alternative to using git if there are submodules. === beuno is now known as beuno-lunch === deryck is now known as deryck[lunch] [16:42] vila: are you an ediff expert? [16:45] quicksilver: ask your question, we'll see ;) [16:45] vila: I had a conflict which had more 'regions' that it should have [16:45] vila: two entirely different changes, coincidentally, shared a common line in the middle. [16:45] weird but better than the opposite no ? === beuno-lunch is now known as beuno [16:46] vila: I wanted to tell ediff "treat these two differences as one big difference" [16:46] so that I could then press the button which means 'keep both' [16:46] why don't just you do it twice ? [16:47] quicksilver: you know you can edit the regions too and then ask ediff to keep whatever you want [16:48] ha no, you mean they shouldn't overlap the way they are displayed ? [16:51] vila: takes a moment to explain. [16:51] vila: tree A has "{preA}{common}{postA}"; tree B has "{preB}{common}{postB}" [16:51] vila: correct resolution is "{preA}{common}{postA} {preB}{common}{postB}" [16:52] vila: if I press "keep both" twice, I will get lines all interleave [16:52] "{preA}{preB}{common}{postA}{postB}" [16:52] vila: see? [16:52] yeah, so you need to edit manually then [16:52] if I could say "treat this as one difference" [16:52] then "keep both" would be the right thing. [16:52] * vila nods [16:53] does it occur frequently ? [16:53] in fact {common} was "my $self=shift;" which is a very common line in perl. [16:53] likely to occur at the beginning of many functions. [16:53] yeah, as do '{' and such :-/ [16:53] yes, that would be another obvious example [16:53] (although I've never had it happen with '{' I don't think) [16:53] weak point in the diff algorithm... [16:53] * quicksilver nods [16:54] 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] this is the first time I remember it happening exactly like this. [16:54] pretty rare given the few feedback we get on such cases [16:54] vila: funnily enough I switched from emacs to Apple's Filemerge.app to resolve this one. [16:54] and Filemerge did the right thing anyway. [16:55] no idea why. It must have some heuristics for combining nearby regions. [16:55] but the conflicts were generated by bzr right ? [16:55] yes. [16:55] I gave filemerge all four files file{,.BASE,.OTHER,.THIS} [16:55] and it worked it out. [16:55] so patiencediff, the algo we use, is *generally* better, partly because it found this common line :-/ [16:56] ;) [16:56] so Filemerge certainly use a different algorithm and recalculate the conflicts from scratch ignoring bzr proposals [16:56] I don't think we have an easy way to change the diff algo used by merge [16:57] there are discussions about that though [16:57] * quicksilver nods [16:57] I don't often get conflicts which annoy me [16:57] but then again, we don't often let branches diverge all that far [16:57] this was a particularly long-lived, far-diverged branch. [16:58] you can try 'bzr remerge ' with various options (but keep a copy of your file with your conflict resolution, remerge will destroy them) [17:04] vila ping, but I'm only in for an hour. [17:04] mgz: ok, I wanted to ask about your connection hook mp [17:05] goforit. [17:05] mgz: I think you should put it back in NeedsReview state so we can ping spiv :) [17:06] that sounds reasonable. [17:07] 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] 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] they don't have to have the same signature at least to start with [17:08] sounds like it would work. [17:08] how much are we worried about burdening our future selves with interfaces we don't want any more? [17:09] even if not perfect, that would allow progress in the right direction [17:10] 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] vila: hmm, right. [17:10] vila: "weave" does a better job, for my needs, for this specific case [17:11] vila: what I mean is that 'weave' treats it as one big difference region [17:11] so 'keep both' is the right thing [17:11] quicksilver: honestly no idea, but that the one I would try first [17:11] * quicksilver nods [17:11] thanks [17:11] ah no, it did something odd [17:11] it took into account my local changes already [17:11] hmm [17:11] I think I needed to back out my changes before remerging. [17:12] quicksilver: it is supposed to do a better job for highly diverged branches [17:13] quicksilver: err, what ? remerge redo the merge, it's not supposed to do that on top of your modifications [17:14] vila: I had already resolved the conflict [17:14] it appeared to take advante of my current file [17:15] the stuff in "TREE" contained the lines that, in fact, were never in "TREE" [17:15] (they were only present in OTHER, but they were present in my locally resolved copy of course) [17:17] * vila scratches head [17:19] quicksilver: make a backup, then 'bzr revert ' 'bzr remerge --merge-type weave > [17:21] vila: OK, expected result now. [17:26] vila: amusingly, smerge-ediff then "undoes" that improvment by automatically refining the diff when you enter ediff ;P === deryck[lunch] is now known as deryck [17:26] :) === zyga is now known as zyga-afk [18:52] 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] abentley, is this what was the immediate cause of the rollback of lp-buildd during UDS? [18:54] james_w: it seems likely. [18:54] james_w: Our logging isn't very good, so I can't be sure about the precise cause. [18:55] ok [18:55] 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] abentley, I don't think it's a bzr-builder problem exactly? Just fetching with bzr shows the high memory usage? [18:55] james_w: my direct test showed about 1gb for a "bzr branch" [18:55] it is just a huge branch [18:56] wide and deep [18:56] (lots of files, lots of history) [18:56] james_w: yes, but maybe we can avoid the problem in bzr-builder. [18:56] abentley: we killed the build earlier, not sure what to do right now [18:57] jam: VmPeak: 1487216 kB here. [18:57] abentley: 64bit machine? [18:57] (I was testing on 32) [18:57] jam, no, 32. [18:57] jam, AIUI 1G is the max physical memory we can hope for. [18:58] abentley: anyway it is arguably a bzrlib problem, but we don't have any quick-and-fast answers there [18:58] I cut it in half for bzr 2.2, but large branches still take a lot of memory [18:58] it is mostly the CHK stuff that is the problem [18:58] jam, Okay, I wasn't sure what the status was. Thanks. [18:59] james_w: would it be reasonable to do lightweight checkouts instead of copying the branch? === Meths_ is now known as Meths === yailuj24 is now known as nailuj24 [19:02] abentley, we could if we analyze the recipe to check if we will do a commit as we build it [19:03] james_w: How do we determine whether we'll do a commit? [19:04] abentley, I think commits are just done after merges currently, but I can't remember for sure [19:05] james_w: they are done so that subsequent merges can use the correct parent information? [19:06] abentley, yes [19:06] nest-part as well now [19:06] so pretty much every recipe will commit [19:07] james_w: Okay, maybe stacked branches instead of lightweight checkouts? [19:07] yes, that would work [19:07] will that cut down memory usage in this case? [19:07] james_w: Okay, I'll see if that actually cuts down memory usage. [19:08] heh :-) [19:08] 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] ah [19:09] jam, doh. [19:09] james_w: btw, nest-part is a partial merge, so its parent information should not be recorded. [19:10] abentley, I assume that is taken care of [19:11] james_w: Sorry, what do you mean by "nest-part as well now"? [19:20] abentley, nest-part does a commit after doing the work [19:21] 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] abentley, I don't know === lifeless_ is now known as lifeless [19:51] jelmer: nothing more than was discussed here === zyga-afk is now known as khr === khr is now known as zyga [21:06] 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] you've got a local notrees shared repo [21:09] 'bzr checkout .' will populate a tree on a branch [21:10] mwhudson: sorry about the email spam. I normally don't re-use branches, does it send 1 email per mainline rev? [21:13] jam: it's ok, i can ignore email pretty effectively :) [21:13] and yeah, one mail per rev === Ursinha is now known as Ursinha-afk [21:22] 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] jam: not really, you can send the "signal" 0 to it if you had the pid and interpret the result [21:24] mwhudson: this is for the test suite. the mthaddon [21:24] noted that we needed a pid file [21:24] so that indicated I should be daemonizing [21:24] and I wanted to start and stop such a thing cleanly [21:24] and have the test suite wait for it to exit [21:24] but... not very easy to get right, from what I can tell [21:25] If you rely on PIDs, then there's race conditions [21:25] exarkun: there is, but I'm not worried about spawning 32k processes in the meantime [21:25] If the daemon is listening on a unix socket, then connect attempts to that socket will begin to fail after it exits [21:26] jam: It's not just processes. [21:26] Maybe it's just as unlikely to have a TID collision, but I don't know how TIDs are allocated. [21:40] mwhudson: I don't remember if you're a vim or emacs guy. Any chance you know about pyflakes + vim? [21:41] jam: i've been using emacs for ~one third of my life now :-) [21:41] jam: for the daemons, there is some hair in the launchpad code base for this already [21:42] jam: lifeless has been working on it recently, i think there is a librarianfixture somewhere you could maybe crib from [21:42] mwhudson: I'm not sure if that is a long time or not :) [21:42] although that might be oriented around twisted daemons, come to think of it [21:43] mwhudson: I went with a simple loop around os.kill(..., 0) and trapping ESRCH [21:57] mwhudson: mind if I nominate you to review the updated patch? === zyga is now known as zyga-afk [22:00] jam: no [22:01] mwhudson: https://code.edge.launchpad.net/~jameinel/launchpad/lp-service/+merge/40386 [22:01] I don't know the specific urgency [22:01] I can't deploy to qastaging until that is fixed [22:01] but the l-o-s- [22:01] are out-of-town this week [22:02] so I may not be able to anyway, [22:04] i really hope there's some library code somewhere you could have used rather than writing all that from scratch :/ [22:04] lifeless: hi [22:05] hi [22:05] 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] mornin everybody :) [22:06] lifeless: and see if you know if there is library code for any of this? [22:06] there is in twistd [22:08] yeah [22:08] i guess that's a "no" then really [22:09] mwhudson: well the fork-a-daemon code was taken from a "python daemon" search and tweaked for my use case [22:10] so I didn't have to write it completely manually [22:10] mwhudson: that glue isn't what I've been working on; though I'd certainly want a Fixture wrapping it. [22:10] it would be nice to have bin/run know about it too [22:11] bin/run runs the service already, but not as a daemon [22:12] lifeless: yeah, bin/run and runlaunchpad.py know how to do it, but that isn't how they run things in production [22:13] just one of the pain points for this experiment. [22:17] jam: might it be better to wait for the daemon to respond to hello than to write its pid file? [22:17] mwhudson: I'm not sure i understand [22:18] jam: in TestCaseWithLPForkingServiceDaemon._start_subprocess [22:18] are you saying the service shouldn't write its own pid file until it gets a request? [22:18] jam: no, i'm saying the test helper should wait until a request gets a response [22:20] mwhudson: fair point, anything else? [22:20] hi guys [22:20] can i ask something? [22:20] i've pushed a branch up on an FTP account [22:21] what do i do now? (in bzr explorer) [22:21] mwhudson: I need the pid for other reasons, but I could wait for hello and then check the file [22:21] when i try to checkout - bzr explorer asks me like 3 times about the password [22:21] jam: it just seems that there is a tiny possibility of a race [22:21] with the current code [22:22] millun: I believe the recommendation is to use a full branch and not to use a lightweight checkout for a remote branch [22:22] mwhudson: where? [22:22] I don't doubt it [22:22] you can't use the normal "waitpid()" sort of tools [22:22] jam: just the thing we were talking about already [22:22] the daemon writes this pid before it listens on the socket [22:23] jam, [22:24] jam i thought at first that i need to checkout becAuse branching offered me shared repository while i need colocated [22:24] right? [22:24] 'write pid file' and 'service is ready' aren't quite the same thing. [22:24] millun: if you need collocated, you still want a local branch to checkout [22:25] hi mwhudson, jam [22:25] spiv [22:25] spiv: well, it could be, it depends how I write the code :) [22:25] is collocated already a property of the branch? or it matters from user to user [22:25] millun: layout is a property of the user [22:26] well, location [22:27] Bind new branch to parent location? (should i check this? [22:27] i am using colocated branches in /Var/www/projectname [22:28] 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] 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] hi there GaryvdM [22:32] Hi poolie [22:32] jam: i asked for a couple of small changes [22:34] mwhudson: I was pretty sure that you need setsid() to guarantee you'll disconnect from the terminal [22:35] jam: ok [22:35] mwhudson: http://www.itp.uzh.ch/~dpotter/howto/daemonize [22:35] cool GaryvdM [22:38] 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] btw, hi poolie, nice to you have you back around and online [22:39]