=== niemeyer [n=niemeyer@200.169.124.132] has joined #launchpad === niemeyer [n=niemeyer@200.169.124.132] has joined #launchpad === tambaqui [n=patricia@200-208-53-25-mns.cpe.vivax.com.br] has joined #launchpad === niemeyer [n=niemeyer@200.169.124.134] has joined #launchpad === niemeyer [n=niemeyer@200.169.124.134] has joined #launchpad === stub [i=stub@sweep.bur.st] has joined #launchpad === Mez [n=Mez@ubuntu/member/mez] has joined #launchpad === stub [i=stub@sweep.bur.st] has joined #launchpad === stub [i=stub@sweep.bur.st] has joined #launchpad [06:47] bug 2162 [06:47] Malone bug #2162: front page cached In: launchpad (upstream), Severity: Normal, Assigned to: Stuart Bishop, Status: Accepted https://launchpad.net/bugs/2162 [06:48] Bug 2162 [06:48] Malone bug #2162: front page cached In: launchpad (upstream), Severity: Normal, Assigned to: Stuart Bishop, Status: Accepted https://launchpad.net/bugs/2162 === stub kicks Ubugtu [06:48] bug stub [06:49] lifeless, jamesh: Would making launchpad emit an Expires: header be a bad thing? [06:49] stub: depends on what you want to achieve === stub [n=stub@costello.z3u.com] has joined #launchpad [06:59] bum [07:03] (12:49:11) stub: lifeless, jamesh: Would making launchpad emit an Expires: header be a bad thing? === stub is missing scrollback in case that was already discussed [07:08] 16:49 < lifeless> stub: depends on what you want to achieve [07:08] 16:51 -!- stub [i=stub@sweep.bur.st] has quit [Remote closed the connection] [07:08] I wondered what I had said [07:09] Our pages are dynamically generated, so browsers should always fetch fresh copies. Although I'd rather they didn't if you hit the 'back' button [07:09] then expires is wrong [07:10] in fact, in general, you can't have it both ways [07:10] either browers are allowed to cache, or they aren't. [07:10] OR [07:10] you teach them how to know when things have changed. [07:10] (vary:) [07:11] read (now) section 14.44 of rfc 2616 [07:14] I'm not sure how that would help us in the Launchpad situation. [07:15] whats the precise situation that we are trying to address ? [07:15] Launchpad content should never be cached, because it is dynamic and could change at any time, and if that breaks the back button tough [07:15] lifeless: People visiting a page for the second time and the information not being up to date [07:16] lifeless: Such as people logging in, getting redirected to the front page, and the front page telling them they are not logged in. [07:16] But the problem exists everywhere - it is just less noticable. [07:17] then vary: *, as the spac says [07:18] A Vary field value of "*" implies that [07:18] a cache cannot determine from the request headers of a subsequent [07:18] request whether this response is the appropriate representation. [07:18] (browsers must meet the non shared cache requirements) [07:18] but the front page is *different* because the cookie: header changes when people log in [07:18] so there is actually a rule we can use there to signal that it should be refreshed. [07:19] we should try very hard to have cachable pages. [07:19] not 'cachable by squid', cachable by the client for reasonable times. [07:19] only some of our pages are infinitely variable over short time frames. [07:20] Almost all of them are - it is just the probablility [07:20] right, and thats what caching is about [07:20] and how much we care about the changes [07:21] until we satisfy If-Matches, we'll perform like a wounded dog if no caching is possible by the client [07:21] consider that this includes hackergotchi and emblems [07:21] and the If* matches and revalidation are still waay suboptimal [07:21] Nah - librarian stuff is never expires. Images and resources like the css will be cachable [07:22] (upload a new hackergotchi and your hackergochi gets a new URL) [07:22] so I think there are two important cases [07:22] one is 'Pages change when I change login'. [07:22] another is 'dynamic content just changed may not show until I refresh.' [07:23] (consider that the pathological case is me being on a page already when you change the content behind it) [07:24] fixing the first one (emit vary: Cookie) will solve the user frustation case, as 'refresh' is part of the web user experience and expectations, but 'refresh on login' is not. [07:25] If I submit a new bug, I expect that bug to show on my 'bugs I care about' list. [07:25] I don't know if it is reasonable to expect users to refresh [07:28] Which would happen if I emit Vary: Cookie for all HTML pages. [07:29] (and nearly all HTML pages change on login, as links disappear and change depending on your rights) [07:30] Vary: * would be correct, but will likely cause browsers to be too aggressive... [07:32] stub: less aggressive than Expires: [07:33] Vary: * lets browsers discriminate between 'back' and 'forwards' [07:33] so as a strawman, listing pages could be '*" [07:33] queries could be '*, expires: ' [07:34] front page could be 'vary: cookie' [07:34] its really just a matter of deciding on the refreshness constraints we are happy with. Once *that* is decided, we can craft caching rules to match, including must-revalidate, vary, and expires headers. [07:53] I think we can define 3 or 4 cases (update on login, update always, volatile). I'll talk to SteveA later about how a page registers its preferred caching scheme. We can then make Launchpad emit the headers we define for scheme that is selected, and a default. Although initially we can just hard code 'Vary: *' to fix issues now and tune later. === stub buggers off for a bit [08:12] right now i'm concerned mostly about the login case [08:13] and, i actually have code on a (converted) branch that handles it, as a prototype spike [08:41] SteveA: How does that branch handle the login case? Set a Vary: * header or similar as discussed above? [08:42] Vary: Cookie [08:43] most pages should be "Vary: Cookie", actually [08:46] Vary cookie means that database changes will not be seen. eg. add a bug, go to your bugs screen, and it won't be there because the cookie has not changed since your last view [08:47] (?) [08:52] stub: no [08:52] stub: it just tells a cache that it can't consider its version of a page valid if the request includes a different "Cookie" header [08:52] it doesn't say "if the Cookie header remains constant, then the returned content will also be the same" [08:55] jamesh: No - it says if the cookie header remains constant then you are welcome to use your cached version, which may give the effect I mentioned [08:56] Or at least, that will be the effect (just not-ing your first statement) === JanC [n=janc@lugwv/member/JanC] has joined #launchpad [08:57] (not that I have a clue how real browsers interpret it) [08:57] stub: see the "while the response is fresh" bit [08:58] morning all [08:58] stub: But that's true at the moment with Vary: Cookie too. As far as I can tell, except for the very few static files served by the launchpad webapp, Vary: Cookie would be an improvement on the current situation. [08:58] it is a little immaterial right now, since we don't provide a web browser or cache a way to tell whether a resource is fresh [08:59] s/at the moment with/at the moment without/ [08:59] stub: we'd need to be providing expiry information for browsers to decide whether the resource is fresh [08:59] Stupid fingers :) [08:59] Only stuff starting with /++resource or /@@/ can ever be considered fresh We need to add the relevant headers. [08:59] or enough information for them to guess: e.g. the Last-Modified header [09:00] stub: I think you are missing the fact that fresh content is usually not cached for more than a second or two [09:00] stub: stuff served with the static resource view sends enough information to allow proper caching [09:00] stub: it sets the Vary header on a special variable cookie that is used only for logging in [09:01] SteveA: doesn't the Vary header work in terms of other header names rather than cookie values? [09:01] s/cookie values/cookie names/ [09:02] So what is the suggestion re: Bug 2162 (which is not just the front page, but every dynamically generated page to some extent)? [09:02] jamesh: its a header-value check [09:02] Malone bug #2162: front page cached In: launchpad (upstream), Severity: Normal, Assigned to: Stuart Bishop, Status: Accepted https://launchpad.net/bugs/2162 [09:02] jamesh: for the listed headers, has the value changed? No -> fresh is ok. Yes -> must revalidate/reretrieve === carlos [n=carlos@23.Red-83-55-110.dynamicIP.rima-tde.net] has joined #launchpad [09:03] lifeless: that's what I thought. SteveA said he was setting the Vary header on a particular cookie [09:04] which I don't think is possible [09:04] morning [09:04] the heavy use of portlets makes it difficult to work out what is cacheable too [09:05] jamesh: the way the authentication works generally, the cookie never changes [09:06] jamesh: so i need to add a new cookie to make the cookie header change at all [09:06] i could change the zope3 session stuff, but this is easier and less tightly coupled too [09:06] SteveA: what I am saying is that you'll either be able to say the resource varies if "the cookie header changes" rather than if "a particular cookie changes" [09:07] so it's an assertion about all cookies for the site [09:07] i have one cookie that is used as a change marker [09:07] the others don't change [09:08] and an add-on to the Request / Response to say "something has changed" [09:08] which increments the cookie's value [09:08] this can be extended to things other than logging in [09:09] SteveA: I don't think the HTTP Vary header will work at that level for you [09:09] we can have an event listener or some such that notices when things change, or pages have been visited that deserve variability [09:09] and changes this cookie [09:09] if you put "Vary: Cookie", a cache will think it's copy of the resource is invalid if you change one cookie or all cookies [09:09] the Vary header is always sent [09:09] exactly [09:10] there is only one cookie that we change [09:10] there are two cookies needed: 1. session, 2. change [09:10] spiv: has your branch for the map generation been merged to rf ? [09:10] the session cookie never changes [09:10] okay. That makes sense [09:10] the change cookie changes when there's been a change [09:11] The other way to handle some of this stuff would be to use ESI, to construct the pages outside of the app server [09:11] that may be a good thing for portlets, eventually [09:12] such that we can define the caching characteristics of each page fragment easily [09:13] there are issues around transactions, though [09:13] so, we'd probably want to have some portlets rendered inline even then [09:13] so that the data comes from the same transaction as the main page [09:13] mmm esi. [09:13] I loike ESi [09:14] lifeless: i'll prod 1332 in RT [09:15] lifeless: Not yet. Give me a moment to take another look over it, and I'll put it up for review. [09:15] ...when it reaches the launchpad queue === hannosch [i=hannosch@e176098165.adsl.alicedsl.de] has joined #launchpad === jamesh wonders how rosetta will handle the new .po file extensions in gettext [09:20] a new "msgctxt" directive to go with "msgid" and "msgstr" === hannosch groans at rosetta: spammers! just got 224 mails telling me about successfully imported files ;( [09:34] hannosch: just use mutt ;-) [09:35] hannosch: can you forward me one of the emails? [09:37] hannosch: steve @ canonical.com [09:37] SteveA: sure [09:40] thanks hannosch. i have the email. i'll talk with the rosetta team about your suggestion of one email per tarball. [09:40] do you want to be subscribed to the bug about it? [09:41] BjornT, stub: henrik had an interesting idea about bug watches [09:41] SteveA: great. yeah subscribe me please. my account at launchpad is hannosch [09:41] that is to add a malone email address as a CC to a bug in an external bug tracker, and use this as a "push watch" kind of thing [09:42] also, there would be no need to explicitly register the watch in launchpad, perhaps [09:42] this, along with some kind of keywords, would make the accessibility stuff easier. they want to record the status of a disparate bunch of upstream bugs. [09:42] in upstream bugtrackers [09:44] SteveA: yeah, doko had the same idea. i would think that we still would have to register the bugwatch explictly, though, to make the connection. [09:44] SteveA: sounds nice, then we'd need ot have a list of whitelisted external bugtrackers URLs that lp would be willing to accept emails from ? [09:44] we do have scripts that should update bugwatch status, though, but i'm not sure if they are working or not. we definitely should take a closer look at bug watches soon. [09:45] anyway, gotta go now === BjornT heads off to the airport [09:46] bugwatch@launchpad.net might do it [09:46] and just have a magic black box interpret the bug information and route it to the right launchpad bug [09:48] jordi, hi, around? [09:52] hi carlos [09:52] SteveA, hi [09:53] can we make the tarball imports send a single email listing the files, and giving the success or failure of each? [09:54] the rosetta user hannosch received a large number of emails as a result of importing a tarball [09:54] Hmm, we would need then a way to store the import status [09:55] every file is imported as a different process [09:55] or perhaps change our script to group the imports by importer.... [09:55] yes, this solution is better... === Mez [n=Mez@ubuntu/member/mez] has joined #launchpad [09:58] SteveA: Interesting idea. We will need to allow 'anonymous comments' though in Malone (comments from email addresses not registered with Launchpad). === koke [n=koke@ubuntu/member/koke] has joined #launchpad [10:05] reviewwe meeting time! [10:05] stub: i imagine we would have a special case for bugs from these bugtrackers [10:05] whos here ? [10:05] spiv: phone call after the review team meeting? [10:05] i'm here === hannosch [i=hannosch@e176098165.adsl.alicedsl.de] has left #launchpad ["Quit"] [10:05] jamesh:, salgado:, bjornt:, spiv: here ? [10:06] SteveA: That assume we know what they are - if we just allow anonymous comments coming in, no registration of external bug trackers is needed for it. Just might be a spam problem. [10:07] daf: ping [10:08] I'm here. [10:08] SteveA: Sure. [10:09] daf: unping [10:09] Untriaged (0) [10:09] Finally!! :-D [10:09] we have a bot here, no? [10:09] ok [10:09] 3's enough to start :) [10:09] and we're a bit late. [10:09] agenda: [10:09] ------- [10:09] Wouldn't it be cool if the bot watched pings and unpings? [10:10] roll call [10:10] next meeting [10:10] any last minute requests ? [10:10] lifeless: yeah [10:10] ... [10:11] (that's yes I'm here, not last minute requests) [10:11] ok [10:11] any last minute requests ? [10:12] ok, meeting over. [10:12] next meeting, will be jan 4th 0900 UTC [10:12] thanks for you attention ;) [10:12] lifeless: what meeting was that? :-) (wow that was *quick*) [10:13] lifeless: Not a problem ;) [10:15] SteveA: call time? [10:16] sivang: ReviewerMeetingAgenda on the wiki === stub notices the --top-fifty option to test.py [10:17] Bug 5814 [10:17] Malone bug #5814: want to know breakdown of test run time by area of development In: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: Accepted https://launchpad.net/bugs/5814 [10:18] spiv: sure, let me find my phone... [10:20] SteveA: my landline is best. === lbm [n=lbm@cpe.atm4-0-1301006.0x50a0824e.vgnxx6.customer.tele.dk] has joined #launchpad [10:31] SteveA: Are you looking at Z3.1 this week? I have some stuff to do with the test suite and am wondering if I should put it off until next week. [10:37] Ooh... looks like it already does everything I need... === BjornT [n=bjorn@212.47.97.19] has joined #launchpad [10:44] does lauchpad have a development mailing list? [10:44] please tell me the contact address [10:44] siretart: yes [10:45] BjornT: carlos and I got a bit confused because we were seeing different numbers of open bugs in Malone [10:45] BjornT: we worked out that it was because I'm not logged in, and it wasn't counting private bugs for me [10:45] BjornT: is that deliberate? [10:46] siretart: it is currently a closed subscription list [10:47] does the launchpad-users list exist yet? [10:47] http://lists.ubuntu.com/mailman/listinfo/launchpad-users [10:47] looks like [10:47] no posts yet, though. [10:47] daf: yes, but i agree that it can be confusing. maybe we should list number of public and private separately, so that it's more clear. [10:48] siretart: the users list is open subscription, yes [10:49] BjornT, I think that's a good idea [10:49] jamesh: I just CC:ed it [10:49] BjornT: hmm, I think that might be an unnecessary complexity [10:49] gnarf [10:49] BjornT: is there a security benefit to not giving un-logged-in users the full counts? [10:50] damn semi-moderated mailing lists ;) [10:51] BjornT, we found another UI problem with Malone, I suppose it's a bug... [10:51] BjornT, daf sees https://launchpad.net/products/rosetta/+bug/744 bug as untriaged (that's correct) [10:51] daf files a private bug [10:51] carlos triages bugs [10:51] Error: I cannot access this bug [10:52] BjornT, but I don't see it [10:52] carlos doesn't see the private bug as one that needs triaging [10:52] as untriaged [10:52] because he's not subscribed to it [10:52] but I can read the bug report [10:52] so I have access to it [10:54] lifeless: ping [10:55] daf: well, when i said we should list both counts, i was referring to the bug listings only. it's confusing if it says '1 -> 20 of 369' if you can see all the bugs. then again, that number is dependant of search text, which can be a security issue... [10:55] oh, I see [10:55] I was only thinking about the portlet with the different numbers in it [10:57] yeah, in the portlet it would be ok to list private bugs as well, but it's hard to get it right. both public and private counts take up too much space, and including private bugs that you can't see can be confusing. [10:58] i hope this will be less of a problem when we get more persistent logins, so that you can stay logged in for a longer period of time. [10:58] mmm [10:58] it is a tricky problem [11:00] persistent logins won't happen until someone reviews my PostgreSQL sessions branch [11:05] stub: that branch is currently in salgado's queue. you can nag him about it, and if he hasn't time, he can put in my queue and i'll review it tomorrow. [11:09] time to board the plane, see you later === jblack_ [i=jblack@static-209-158-45-74.scr.east.verizon.net] has joined #launchpad [11:15] jblack: pong [11:20] Kinnison: Do you need the staging database in its current state, or can I resync it from production? [11:21] so gina's going to be run in production sometime soon? [11:22] jamesh: It is running now [11:23] wooyeah [11:23] jamesh: So bugzilla migration can happen if you are happy with the scripts [11:23] elmo: Znarl: either of you ping [11:25] stub: yay. [11:25] we'll need to turn off write access to bugzilla before that happens though. [11:26] also need to check with bradb re: InitialBugContacts [11:29] debugs syncing too... [11:29] I wonder if that is still working... [11:30] lifeless : Pong [11:31] Znarl: rt 1332 [11:31] Znarl: thats highly urgent please. [11:31] jamesh: How is your schedule looking? Someone will need to test out the debugs code to ensure it still does the right thing, and I expect that is either me or you. [11:31] Znarl: I realise you've probably just woken up. [11:31] Znarl: it wasn't quite urgent enough to wake you guys [11:32] lifeless : My work day started an hour and a half ago. [11:32] Znarl: oh, oh :) [11:35] znarl: Cool, you're here. Can I talk to you for a moment? [11:35] jblack : Once I deal with lifeless's request, unless it's urgent. [11:36] jblack_: I need to talk about the other mapping script with you [11:36] stub: when I last looked at that code, it seemed to only handle creating new bugs from deb bugs (only copying the initial debbugs comment), and status synching [11:36] znarl: Lifeless first. I'll talk with lifeless in the meantime. :) [11:36] stub: it'll probably need a bit more work to do full comment synching like debzilla did [11:36] (although it should be possible to do better, since we keep track of message IDs) [11:38] lifeless: that hash doesnt' look like it breaks up well. [11:38] jblack_: its not a hash [11:38] jblack_: it has high locality of reference, which is desirable [11:38] Ok. if its wanted. [11:39] jamesh: Mark was happy with what he is written, so we just need to ensure his code is still working - extra features are later. I'm aware of at least one issue to fix (it is connecting as the wrong db user) [11:43] stub: okay. The first thing to do would probably be to add some tests to make sure it works and doesn't get broken again [11:45] lifeless: hi [11:46] hi [11:46] I have unchanged this: [11:46] from /%d/%d/%d/%d to /%d/%d/%d/%d/launchpad id [11:47] it *was* %d/%d/%d/%d . [11:47] thats what it should be [11:47] It _is_ that. :) [11:47] great. [11:47] I put it back as soon as you said. [11:47] That *IS* the launchpad id. [11:48] thank you. [11:48] I suppose 4 billion products is enough for anyone. :) [11:48] well [11:48] we dont show the launchpad id to the user [11:48] so we can just update our disk format at 3.99999 billion [11:48] The formula itself will need a change. [11:48] but yeah. [11:49] I'm reading it now, we're fine for my lifetime. :) [11:50] Actually, even longer than that. It fails gracefully [11:50] I lied. it doesn't. [11:50] hex = "%08x" % int(branchnum) [11:51] its fiiiine [11:51] It fails on the hundred millionth exactly. [11:51] we'll have to adjust postgresql way before then === daf needs to go out for a bit [11:52] back in about 90 minutes, I think [11:52] stub: we have a script that is not yet in rf main that I'd like to roll out today on gangotri [11:52] ok [11:52] I still have a bug when it comes to nonexistant branches that I need to fix. [11:52] lifeless: Just a single script, or does it need a full launchpad update? [11:53] stub: it needs anew lp branch [11:53] I also think I have one on the lockfile [11:53] stub: I'm inclined to do a separate checkout for now [11:53] ok [11:53] stub: is that ok with you? [11:53] Sure - seperate directory won't affect production in any way === stub tries to remember the name of the new appserver [11:54] vanessa ? [11:54] stub: parallel to the production dir ? [11:55] lifeless: Yes - /srv/launchpad.net/somethingnew [11:56] Znarl: You remember the name of the new Launchpad appserver that we currently arn't using? I think ddaa had bzrsync stuff on there. [11:58] stub : Mmm.. [11:59] stub : Gandwana? [12:04] Yup - looks like it [12:13] thats appserver 2 ? === thisfred [n=thisfred@a80-127-80-154.adsl.xs4all.nl] has joined #launchpad [12:17] carlos: here [12:18] jordi, don't worry, it was about the tin template request [12:18] I assigned you that bug [12:18] nod [12:18] so feel free to close it if you already fixed it [12:18] not yet === cprov [n=cprov@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [12:26] good morning! [12:27] jamesh: bugzilla import: is it importing just open bugs, or all bugs? [12:27] SteveA: all bugs [12:28] hi matsubara [12:28] lifeless: Yes - appserver 2. Running breezy so we are not using it yet. I'll switch it on after staging is happy on breezy. [12:29] matsubara: I still didn't manage to attend to that bug, hopefully will do so this evening. [12:31] sivang: no problem. I'm working on another one instead. [12:32] stub: ak [12:32] ack === jinty [n=jinty@205.134.224.215] has joined #launchpad === Mez [n=Mez@ubuntu/member/mez] has joined #launchpad === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [12:36] Yay testdisconnects pqm failures [12:49] stub: ? [12:49] stub: is there a stale process as pqm ? [12:50] spiv: ping [12:50] lifeless: pong [12:50] lifeless: Not that I can see [12:50] stub: weird [12:50] spiv: should I hack the cronscript to call rsync ? [12:50] spiv: via 'system' ? [12:50] spiv: and what frequency do you suggest ? [12:51] Hmm, I'm not sure what's the best taste for the rsync step. I'd be tempted to make it part of the cron line rather than part of the script. [12:51] For frequency, how about 1 hour (to pick a random value :) ? [12:51] spiv: via && ? ewww [12:51] cprov, Should we allow mirrors to have an httpbaseurl, an ftpbaseurl and an rsyncbaseurl at the same time or are they mutually exclusive? [12:52] The script should be quick fast, it's database needs are fairly simple. [12:52] s/quick/quite/ [12:53] (It could almost certainly be made faster with a single explicit SQL statement rather than the current SQLObject code, if needed). [12:53] lifeless: How do you want to expose via launchpad id to ddaa? A rewrite rule? [12:53] jblack: there is a rewrite mapping already given to you [12:53] Two, actually. Those two are in [12:53] salgado: yes, they can have those 3 access methods at the same time, unfortunately we can only check HTTP properly [12:54] jblack: right, I need to know what they look like and what hostname they are on, to answer ddaa's question [12:54] spiv: the reason to put it in the script is to eliminate the tempfilename issue [12:54] I believe ddaa wants /+branches/lpid [12:54] spiv: consider it a bug report :) [12:54] jblack: he doesn't care about the prefix [12:54] SteveA: one other thing I just thought of w.r.t. bugzilla migration: it might be worth trying to generate an apache mod_rewrite map to redirect show_bug.cgi-style URLs to the corresponding Launchpad page [12:54] lifeless: tempfile(1) [12:54] jblack: just needs to know [12:54] lifeless: I'm confused you already have a private launchpad port open - can the file not be transferred via that? [12:54] We currently have these two: [12:54] RewriteRule ^(~[^/] +/[^/] +/[^/] +)/ branches/${branch-list:$1}/ [12:54] RewriteRule ^branches/([[:xdigit:] ] {2})([[:xdigit:] ] {2})([[:xdigit:] ] {2})([[:xdigit:] ] {2})/ branches/$1/$2/$3/$4/ [12:55] spiv: I am so not putting all that in crontab. Which means another script. Which may as well be python [12:55] elmo: different behaviour, this is conceptually able to be pushed on-demand, the pull behaviour occurs via cron [12:56] lifeless: ok, define high priority - do I need to drop everything else I'm doing or can it wait till this evening? [12:56] elmo: but yes, we can in theory do that in the future, though I'm not sure it fits the problem well. [12:56] elmo: I'd *like* to have this working before I go to bed. [12:56] lifeless: well, I'm super not keen on ssh in either direction - will normal rsync do? [12:56] elmo: it was not 'wake you and znarl up' when we noticed at 11am. [12:56] rsync is all we need [12:57] my documentation was in hindsight unclear. Heres a clearer statement [12:57] rsync outputfile [12:57] bah [12:57] rsync afile vostok.ubuntu.com[whateveryouwanthere] :/srv/sm-ng/config/launchpad-lookup.txt [12:57] ^ if that works from the user launchpad on gangotri, I am happy. [12:58] ok [12:59] spiv: you have a question in email [12:59] Ok. [01:00] jblack: that second rule is the interesting one, it seems inactive [01:00] spiv: ^^ [01:00] lifeless: yeah [01:00] RewriteRule ^branches/([[:xdigit:] ] {2})([[:xdigit:] ] {2})([[:xdigit:] ] {2})([[:xdigit:] ] {2})/ branches/$1/$2/$3/$4/ [01:00] I suspect it should be: [01:00] ^branches/([[:xdigit:] ] {2})([[:xdigit:] ] {2})([[:xdigit:] ] {2})([[:xdigit:] ] {2})/ /$1/$2/$3/$4/ [01:00] ok [01:00] lets try that [01:01] k [01:01] mind if I change that to Rewriterule ^\+branches as well? [01:02] works for me [01:02] I'd actually like this on a new VHost if possible [01:02] so that it does not expose to the outside at all [01:02] but that can wait for once its all working in whatever form [01:02] Thats no problem to me... what do you want for a hostname? [01:02] oh, ok [01:05]