[06:47] <stub> bug 2162
[06:47] <Ubugtu> Malone bug #2162: front page cached In: launchpad (upstream), Severity: Normal, Assigned to: Stuart Bishop, Status: Accepted https://launchpad.net/bugs/2162
[06:48] <stub> Bug 2162
[06:48] <Ubugtu> Malone bug #2162: front page cached In: launchpad (upstream), Severity: Normal, Assigned to: Stuart Bishop, Status: Accepted https://launchpad.net/bugs/2162
[06:48] <lifeless> bug stub
[06:49] <stub> lifeless, jamesh: Would making launchpad emit an Expires: <current timestamp> header be a bad thing?
[06:49] <lifeless> stub: depends on what you want to achieve
[06:59] <stub> bum
[07:03] <stub> (12:49:11) stub: lifeless, jamesh: Would making launchpad emit an Expires: <current timestamp> header be a bad thing?
[07:08] <lifeless> 16:49 < lifeless> stub: depends on what you want to achieve
[07:08] <lifeless> 16:51 -!- stub [i=stub@sweep.bur.st]  has quit [Remote closed the connection] 
[07:08] <lifeless> I wondered what I had said
[07:09] <stub> 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] <lifeless> then expires is wrong
[07:10] <lifeless> in fact, in general, you can't have it both ways
[07:10] <lifeless> either browers are allowed to cache, or they aren't.
[07:10] <lifeless> OR 
[07:10] <lifeless> you teach them how to know when things have changed.
[07:10] <lifeless> (vary:)
[07:11] <lifeless> read (now) section 14.44 of rfc 2616
[07:14] <stub> I'm not sure how that would help us in the Launchpad situation. 
[07:15] <lifeless> whats the precise situation that we are trying to address ?
[07:15] <stub> 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] <stub> lifeless: People visiting a page for the second time and the information not being up to date
[07:16] <stub> 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] <stub> But the problem exists everywhere - it is just less noticable.
[07:17] <lifeless> then vary: *, as the spac says
[07:18] <lifeless> A Vary field value of "*" implies that
[07:18] <lifeless>    a cache cannot determine from the request headers of a subsequent
[07:18] <lifeless>    request whether this response is the appropriate representation.
[07:18] <lifeless> (browsers must meet the non shared cache requirements)
[07:18] <lifeless> but the front page is *different* because the cookie: header changes when people log in
[07:18] <lifeless> so there is actually a rule we can use there to signal that it should be refreshed.
[07:19] <lifeless> we should try very hard to have cachable pages.
[07:19] <lifeless> not 'cachable by squid', cachable by the client for reasonable times.
[07:19] <lifeless> only some of our pages are infinitely variable over short time frames.
[07:20] <stub> Almost all of them are - it is just the probablility
[07:20] <lifeless> right, and thats what caching is about
[07:20] <stub> and how much we care about the changes
[07:21] <lifeless> until we satisfy If-Matches, we'll perform like a wounded dog if no caching is possible by the client
[07:21] <lifeless> consider that this includes hackergotchi and emblems
[07:21] <lifeless> and the If* matches and revalidation are still waay suboptimal
[07:21] <stub> Nah - librarian stuff is never expires. Images and resources like the css will be cachable
[07:22] <stub> (upload a new hackergotchi and your hackergochi gets a new URL)
[07:22] <lifeless> so I think there are two important cases
[07:22] <lifeless> one is 'Pages change when I change login'. 
[07:22] <lifeless> another is 'dynamic content just changed may not show until I refresh.'
[07:23] <lifeless> (consider that the pathological case is me being on a page already when you change the content behind it)
[07:24] <lifeless> 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] <stub> If I submit a new bug, I expect that bug to show on my 'bugs I care about' list.
[07:25] <stub> I don't know if it is reasonable to expect users to refresh
[07:28] <stub> Which would happen if I emit Vary: Cookie for all HTML pages.
[07:29] <stub> (and nearly all HTML pages change on login, as links disappear and change depending on your rights)
[07:30] <stub> Vary: *  would be correct, but will likely cause browsers to be too aggressive...
[07:32] <lifeless> stub: less aggressive than Expires: <now>
[07:33] <lifeless> Vary: * lets browsers discriminate between 'back' and 'forwards'
[07:33] <lifeless> so as a strawman, listing pages could be '*"
[07:33] <lifeless> queries could be '*, expires: <now>'
[07:34] <lifeless> front page could be 'vary: cookie'
[07:34] <lifeless> 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] <stub> 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.
[08:12] <SteveA> right now i'm concerned mostly about the login case
[08:13] <SteveA> and, i actually have code on a (converted) branch that handles it, as a prototype spike
[08:41] <stub> SteveA: How does that branch handle the login case? Set a Vary: * header or similar as discussed above?
[08:42] <jamesh> Vary: Cookie
[08:43] <jamesh> most pages should be "Vary: Cookie", actually
[08:46] <stub> 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] <stub> (?)
[08:52] <jamesh> stub: no
[08:52] <jamesh> 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] <jamesh> it doesn't say "if the Cookie header remains constant, then the returned content will also be the same"
[08:55] <stub> 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] <stub> Or at least, that will be the effect (just not-ing your first statement)
[08:57] <stub> (not that I have a clue how real browsers interpret it)
[08:57] <jamesh> stub: see the "while the response is fresh" bit
[08:58] <sivang> morning all
[08:58] <spiv> 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] <jamesh> 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] <spiv> s/at the moment with/at the moment without/
[08:59] <jamesh> stub: we'd need to be providing expiry information for browsers to decide whether the resource is fresh
[08:59] <spiv> Stupid fingers :)
[08:59] <stub> Only stuff starting with /++resource or /@@/ can ever be considered fresh We need to add the relevant headers. 
[08:59] <jamesh> or enough information for them to guess: e.g. the Last-Modified header
[09:00] <lifeless> stub: I think you are missing the fact that fresh content is usually not cached for more than a second or two
[09:00] <jamesh> stub: stuff served with the static resource view sends enough information to allow proper caching
[09:00] <SteveA> stub: it sets the Vary header on a special variable cookie that is used only for logging in
[09:01] <jamesh> SteveA: doesn't the Vary header work in terms of other header names rather than cookie values?
[09:01] <jamesh> s/cookie values/cookie names/
[09:02] <stub> 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] <lifeless> jamesh: its a header-value check
[09:02] <Ubugtu> Malone bug #2162: front page cached In: launchpad (upstream), Severity: Normal, Assigned to: Stuart Bishop, Status: Accepted https://launchpad.net/bugs/2162
[09:02] <lifeless> jamesh: for the listed headers, has the value changed? No -> fresh is ok. Yes -> must revalidate/reretrieve
[09:03] <jamesh> lifeless: that's what I thought.  SteveA said he was setting the Vary header on a particular cookie
[09:04] <jamesh> which I don't think is possible
[09:04] <carlos> morning
[09:04] <jamesh> the heavy use of portlets makes it difficult to work out what is cacheable too
[09:05] <SteveA> jamesh: the way the authentication works generally, the cookie never changes
[09:06] <SteveA> jamesh: so i need to add a new cookie to make the cookie header change at all
[09:06] <SteveA> i could change the zope3 session stuff, but this is easier and less tightly coupled too
[09:06] <jamesh> 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] <jamesh> so it's an assertion about all cookies for the site
[09:07] <SteveA> i have one cookie that is used as a change marker
[09:07] <SteveA> the others don't change
[09:08] <SteveA> and an add-on to the Request / Response to say "something has changed"
[09:08] <SteveA> which increments the cookie's value
[09:08] <SteveA> this can be extended to things other than logging in
[09:09] <jamesh> SteveA: I don't think the HTTP Vary header will work at that level for you
[09:09] <SteveA> we can have an event listener or some such that notices when things change, or pages have been visited that deserve variability
[09:09] <SteveA> and changes this cookie
[09:09] <jamesh> 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] <SteveA> the Vary header is always sent
[09:09] <SteveA> exactly
[09:10] <SteveA> there is only one cookie that we change
[09:10] <SteveA> there are two cookies needed: 1. session, 2. change
[09:10] <lifeless> spiv: has your branch for the map generation been merged to rf ?
[09:10] <SteveA> the session cookie never changes
[09:10] <jamesh> okay.  That makes sense
[09:10] <SteveA> the change cookie changes when there's been a change
[09:11] <jamesh> 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] <SteveA> that may be a good thing for portlets, eventually
[09:12] <jamesh> such that we can define the caching characteristics of each page fragment easily
[09:13] <SteveA> there are issues around transactions, though
[09:13] <SteveA> so, we'd probably want to have some portlets rendered inline even then
[09:13] <SteveA> so that the data comes from the same transaction as the main page
[09:13] <lifeless> mmm esi.
[09:13] <lifeless> I loike ESi
[09:14] <SteveA> lifeless: i'll prod 1332 in RT
[09:15] <spiv> lifeless: Not yet.  Give me a moment to take another look over it, and I'll put it up for review.
[09:15] <SteveA> ...when it reaches the launchpad queue
[09:20] <jamesh> a new "msgctxt" directive to go with "msgid" and "msgstr"
[09:34] <sivang> hannosch: just use mutt ;-)
[09:35] <SteveA> hannosch: can you forward me one of the emails?
[09:37] <SteveA> hannosch: steve @ canonical.com
[09:37] <hannosch> SteveA: sure
[09:40] <SteveA> thanks hannosch.  i have the email.  i'll talk with the rosetta team about your suggestion of one email per tarball.
[09:40] <SteveA> do you want to be subscribed to the bug about it?
[09:41] <SteveA> BjornT, stub: henrik had an interesting idea about bug watches
[09:41] <hannosch> SteveA: great. yeah subscribe me please. my account at launchpad is hannosch
[09:41] <SteveA> 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] <SteveA> also, there would be no need to explicitly register the watch in launchpad, perhaps
[09:42] <SteveA> 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] <SteveA> in upstream bugtrackers
[09:44] <BjornT> 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] <sivang> 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] <BjornT> 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] <BjornT> anyway, gotta go now
[09:46] <SteveA>  bugwatch@launchpad.net might do it
[09:46] <SteveA> and just have a magic black box interpret the bug information and route it to the right launchpad bug
[09:48] <carlos> jordi, hi, around?
[09:52] <SteveA> hi carlos 
[09:52] <carlos> SteveA, hi
[09:53] <SteveA> can we make the tarball imports send a single email listing the files, and giving the success or failure of each?
[09:54] <SteveA> the rosetta user hannosch received a large number of emails as a result of importing a tarball
[09:54] <carlos> Hmm, we would need then a way to store the import status 
[09:55] <carlos> every file is imported as a different process
[09:55] <carlos> or perhaps change our script to group the imports by importer....
[09:55] <carlos> yes, this solution is better...
[09:58] <stub> SteveA: Interesting idea. We will need to allow 'anonymous comments' though in Malone (comments from email addresses not registered with Launchpad).
[10:05] <lifeless> reviewwe meeting time!
[10:05] <SteveA> stub: i imagine we would have a special case for bugs from these bugtrackers
[10:05] <lifeless> whos here ?
[10:05] <SteveA> spiv: phone call after the review team meeting?
[10:05] <SteveA> i'm here
[10:05] <lifeless> jamesh:, salgado:, bjornt:, spiv: here ?
[10:06] <stub> 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] <jblack> daf: ping
[10:08] <spiv> I'm here.
[10:08] <spiv> SteveA: Sure.
[10:09] <jblack> daf: unping
[10:09] <carlos> Untriaged  (0)
[10:09] <carlos> Finally!! :-D
[10:09] <jblack> we have a bot here, no? 
[10:09] <lifeless> ok
[10:09] <lifeless> 3's enough to start :)
[10:09] <lifeless> and we're a bit late.
[10:09] <lifeless> agenda:
[10:09] <lifeless> -------
[10:09] <jblack> Wouldn't it be cool if the bot watched pings and unpings? 
[10:10] <lifeless> roll call
[10:10] <lifeless> next meeting
[10:10] <lifeless> any last minute requests ?
[10:10] <jamesh> lifeless: yeah
[10:10] <lifeless> ...
[10:11] <jamesh> (that's yes I'm here, not last minute requests)
[10:11] <lifeless> ok
[10:11] <lifeless> any last minute requests ?
[10:12] <lifeless> ok, meeting over.
[10:12] <lifeless> next meeting, will be jan 4th 0900 UTC
[10:12] <lifeless> thanks for you attention ;)
[10:12] <sivang> lifeless: what meeting was that? :-) (wow that was *quick*)
[10:13] <spiv> lifeless: Not a problem ;)
[10:15] <spiv> SteveA: call time?
[10:16] <lifeless> sivang: ReviewerMeetingAgenda on the wiki
[10:17] <stub> Bug 5814
[10:17] <Ubugtu> 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] <SteveA> spiv: sure, let me find my phone...
[10:20] <spiv> SteveA: my landline is best.
[10:31] <stub> 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] <stub> Ooh... looks like it already does everything I need...
[10:44] <siretart> does lauchpad have a development mailing list?
[10:44] <siretart> please tell me the contact address
[10:44] <jamesh> siretart: yes
[10:45] <daf> BjornT: carlos and I got a bit confused because we were seeing different numbers of open bugs in Malone
[10:45] <daf> BjornT: we worked out that it was because I'm not logged in, and it wasn't counting private bugs for me
[10:45] <daf> BjornT: is that deliberate?
[10:46] <jamesh> siretart: it is currently a closed subscription list
[10:47] <daf> does the launchpad-users list exist yet?
[10:47] <siretart> http://lists.ubuntu.com/mailman/listinfo/launchpad-users
[10:47] <siretart> looks like
[10:47] <siretart> no posts yet, though.
[10:47] <BjornT> 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] <jamesh> siretart: the users list is open subscription, yes
[10:49] <carlos> BjornT, I think that's a good idea
[10:49] <siretart> jamesh: I just CC:ed it
[10:49] <daf> BjornT: hmm, I think that might be an unnecessary complexity
[10:49] <siretart> gnarf
[10:49] <daf> BjornT: is there a security benefit to not giving un-logged-in users the full counts?
[10:50] <siretart> damn semi-moderated mailing lists ;)
[10:51] <carlos> BjornT, we found another UI problem with Malone, I suppose it's a bug...
[10:51] <carlos> BjornT, daf sees https://launchpad.net/products/rosetta/+bug/744 bug as untriaged (that's correct)
[10:51] <daf> daf files a private bug
[10:51] <daf> carlos triages bugs
[10:51] <Ubugtu> Error: I cannot access this bug
[10:52] <carlos> BjornT, but I don't see it
[10:52] <daf> carlos doesn't see the private bug as one that needs triaging
[10:52] <carlos> as untriaged
[10:52] <daf> because he's not subscribed to it
[10:52] <carlos> but I can read the bug report
[10:52] <carlos> so I have access to it
[10:54] <jblack> lifeless: ping
[10:55] <BjornT> 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] <daf> oh, I see
[10:55] <daf> I was only thinking about the portlet with the different numbers in it
[10:57] <BjornT> 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] <BjornT> 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] <daf> mmm
[10:58] <daf> it is a tricky problem
[11:00] <stub> persistent logins won't happen until someone reviews my PostgreSQL sessions branch
[11:05] <BjornT> 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] <BjornT> time to board the plane, see you later
[11:15] <lifeless> jblack: pong
[11:20] <stub> Kinnison: Do you need the staging database in its current state, or can I resync it from production?
[11:21] <jamesh> so gina's going to be run in production sometime soon?
[11:22] <stub> jamesh: It is running now
[11:23] <lifeless> wooyeah
[11:23] <stub> jamesh: So bugzilla migration can happen if you are happy with the scripts
[11:23] <lifeless> elmo: Znarl: either of you ping
[11:25] <jamesh> stub: yay.
[11:25] <jamesh> we'll need to turn off write access to bugzilla before that happens though.
[11:26] <jamesh> also need to check with bradb re: InitialBugContacts
[11:29] <stub> debugs syncing too... 
[11:29] <stub> I wonder if that is still working...
[11:30] <Znarl> lifeless : Pong
[11:31] <lifeless> Znarl: rt 1332
[11:31] <lifeless> Znarl: thats highly urgent please.
[11:31] <stub> 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] <lifeless> Znarl: I realise you've probably just woken up.
[11:31] <lifeless> Znarl: it wasn't quite urgent enough to wake you guys
[11:32] <Znarl> lifeless : My work day started an hour and a half ago.
[11:32] <lifeless> Znarl: oh, oh :)
[11:35] <jblack_> znarl: Cool, you're here. Can I talk to you for a moment? 
[11:35] <Znarl> jblack : Once I deal with lifeless's request, unless it's urgent.
[11:36] <lifeless> jblack_: I need to talk about the other mapping script with you
[11:36] <jamesh> 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] <jblack_> znarl: Lifeless first. I'll talk with lifeless in the meantime. :) 
[11:36] <jamesh> stub: it'll probably need a bit more work to do full comment synching like debzilla did
[11:36] <jamesh> (although it should be possible to do better, since we keep track of message IDs)
[11:38] <jblack_> lifeless: that hash doesnt' look like it breaks up well. 
[11:38] <lifeless> jblack_: its not a hash
[11:38] <lifeless> jblack_: it has high locality of reference, which is desirable
[11:38] <jblack_> Ok. if its wanted.
[11:39] <stub> 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] <jamesh> 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] <jblack> lifeless: hi
[11:46] <lifeless> hi
[11:46] <jblack> I have unchanged this: 
[11:46] <jblack> from /%d/%d/%d/%d to /%d/%d/%d/%d/launchpad id
[11:47] <lifeless> it *was* %d/%d/%d/%d .
[11:47] <lifeless> thats what it should be
[11:47] <jblack> It _is_ that. :) 
[11:47] <lifeless> great.
[11:47] <jblack> I put it back as soon as you said. 
[11:47] <lifeless> That *IS* the launchpad id.
[11:48] <lifeless> thank you.
[11:48] <jblack> I suppose 4 billion products is enough for anyone. :) 
[11:48] <lifeless> well
[11:48] <lifeless> we dont show the launchpad id to the user
[11:48] <lifeless> so we can just update our disk format at 3.99999 billion
[11:48] <jblack> The formula itself will need a change.
[11:48] <jblack> but yeah. 
[11:49] <jblack> I'm reading it now, we're fine for my lifetime. :)
[11:50] <jblack> Actually, even longer than that. It fails gracefully
[11:50] <jblack> I lied. it doesn't.
[11:50] <jblack>     hex = "%08x" % int(branchnum)
[11:51] <lifeless> its fiiiine
[11:51] <jblack> It fails on the hundred millionth exactly.
[11:51] <lifeless> we'll have to adjust postgresql way before then
[11:52] <daf> back in about 90 minutes, I think
[11:52] <lifeless> stub: we have a script that is not yet in rf main that I'd like to roll out today on gangotri
[11:52] <jblack> ok
[11:52] <jblack> I still have a bug when it comes to nonexistant branches that I need to fix.
[11:52] <stub> lifeless: Just a single script, or does it need a full launchpad update?
[11:53] <lifeless> stub: it needs  anew lp branch
[11:53] <jblack> I also think I have one on the lockfile 
[11:53] <lifeless> stub: I'm inclined to do a separate checkout for now
[11:53] <stub> ok
[11:53] <lifeless> stub: is that ok with you?
[11:53] <stub> Sure - seperate directory won't affect production in any way
[11:54] <lifeless> vanessa ?
[11:54] <lifeless> stub: parallel to the production dir ?
[11:55] <stub> lifeless: Yes - /srv/launchpad.net/somethingnew
[11:56] <stub> 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] <Znarl> stub : Mmm..
[11:59] <Znarl> stub : Gandwana?
[12:04] <stub> Yup - looks like it
[12:13] <lifeless> thats appserver 2 ?
[12:17] <jordi> carlos: here
[12:18] <carlos> jordi, don't worry, it was about the tin template request
[12:18] <carlos> I assigned you that bug
[12:18] <jordi> nod
[12:18] <carlos> so feel free to close it if you already fixed it
[12:18] <jordi> not yet
[12:26] <matsubara> good morning!
[12:27] <SteveA> jamesh: bugzilla import: is it importing just open bugs, or all bugs?
[12:27] <jamesh> SteveA: all bugs
[12:28] <sivang> hi matsubara 
[12:28] <stub> 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] <sivang> matsubara: I still didn't manage to attend to that bug, hopefully will do so this evening.
[12:31] <matsubara> sivang: no problem. I'm working on another one instead.
[12:32] <lifeless> stub: ak
[12:32] <lifeless> ack
[12:36] <stub> Yay testdisconnects pqm failures
[12:49] <lifeless> stub: ?
[12:49] <lifeless> stub: is there a stale process as pqm ?
[12:50] <lifeless> spiv: ping
[12:50] <spiv> lifeless: pong
[12:50] <stub> lifeless: Not that I can see
[12:50] <lifeless> stub: weird
[12:50] <lifeless> spiv: should I hack the cronscript to call rsync ?
[12:50] <lifeless> spiv: via 'system' ?
[12:50] <lifeless> spiv: and what frequency do you suggest ?
[12:51] <spiv> 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] <spiv> For frequency, how about 1 hour (to pick a random value :) ?
[12:51] <lifeless> spiv: via && ? ewww
[12:51] <salgado> 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] <spiv> The script should be quick fast, it's database needs are fairly simple.
[12:52] <spiv> s/quick/quite/
[12:53] <spiv> (It could almost certainly be made faster with a single explicit SQL statement rather than the current SQLObject code, if needed).
[12:53] <jblack> lifeless: How do you want to expose via launchpad id to ddaa? A rewrite rule?
[12:53] <lifeless> jblack: there is a rewrite mapping already given to you
[12:53] <jblack> Two, actually. Those two are in
[12:53] <cprov> salgado: yes, they can have those 3 access methods at the same time, unfortunately we can only check HTTP properly
[12:54] <lifeless> jblack: right, I need to know what they look like and what hostname they are on, to answer ddaa's question
[12:54] <lifeless> spiv: the reason to put it in the script is to eliminate the tempfilename issue
[12:54] <jblack> I believe ddaa wants /+branches/lpid
[12:54] <lifeless> spiv: consider it a bug report :)
[12:54] <lifeless> jblack: he doesn't care about the prefix
[12:54] <jamesh> 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] <spiv> lifeless: tempfile(1)
[12:54] <lifeless> jblack: just needs to know
[12:54] <elmo> lifeless: I'm confused you already have a private launchpad port open - can the file not be transferred via that?
[12:54] <jblack> We currently have these two:
[12:54] <jblack>   RewriteRule ^(~[^/] +/[^/] +/[^/] +)/ branches/${branch-list:$1}/
[12:54] <jblack>   RewriteRule ^branches/([[:xdigit:] ] {2})([[:xdigit:] ] {2})([[:xdigit:] ] {2})([[:xdigit:] ] {2})/ branches/$1/$2/$3/$4/
[12:55] <lifeless> spiv: I am so not putting all that in crontab. Which means another script. Which may as well be python
[12:55] <lifeless> elmo: different behaviour, this is conceptually able to be pushed on-demand, the pull behaviour occurs via cron
[12:56] <elmo> lifeless: ok, define high priority - do I need to drop everything else I'm doing or can it wait till this evening?
[12:56] <lifeless> elmo: but yes, we can in theory do that in the future, though I'm not sure it fits the problem well.
[12:56] <lifeless> elmo: I'd *like* to have this working before I go to bed.
[12:56] <elmo> lifeless: well, I'm super not keen on ssh in either direction - will normal rsync do?
[12:56] <lifeless> elmo: it was not 'wake you and znarl up' when we noticed at 11am.
[12:56] <lifeless> rsync is all we need
[12:57] <lifeless> my documentation was in hindsight unclear. Heres a clearer statement
[12:57] <lifeless> rsync outputfile
[12:57] <lifeless> bah
[12:57] <lifeless> rsync afile vostok.ubuntu.com[whateveryouwanthere] :/srv/sm-ng/config/launchpad-lookup.txt
[12:57] <lifeless> ^ if that works from the user launchpad on gangotri, I am happy.
[12:58] <elmo> ok
[12:59] <lifeless> spiv: you have a question in email
[12:59] <spiv> Ok.
[01:00] <lifeless> jblack: that second rule is the interesting one, it seems inactive
[01:00] <lifeless> spiv: ^^
[01:00] <jblack> lifeless: yeah
[01:00] <jblack>   RewriteRule ^branches/([[:xdigit:] ] {2})([[:xdigit:] ] {2})([[:xdigit:] ] {2})([[:xdigit:] ] {2})/ branches/$1/$2/$3/$4/
[01:00] <jblack> I suspect it should be: 
[01:00] <jblack> ^branches/([[:xdigit:] ] {2})([[:xdigit:] ] {2})([[:xdigit:] ] {2})([[:xdigit:] ] {2})/ /$1/$2/$3/$4/
[01:00] <lifeless> ok
[01:00] <lifeless> lets try that 
[01:01] <jblack> k
[01:01] <jblack> mind if I change that to Rewriterule ^\+branches as well? 
[01:02] <lifeless> works for me
[01:02] <lifeless> I'd actually like this on a new VHost if possible
[01:02] <lifeless> so that it does not expose to the outside at all
[01:02] <lifeless> but that can wait for once its all working in whatever form
[01:02] <jblack> Thats no problem to me... what do you want for a hostname? 
[01:02] <jblack> oh, ok
[01:05] <jblack> elmo: how do I reload apache on vostok? 
[01:05] <jblack> You gave me sudo access for it a while back, but I've since forgotten which script it was.
[01:06] <elmo> jblack: I don't think I ever did for  vostok
[01:07] <jblack> ah. mind reloading apache2 on vostok for me?
[01:07] <Znarl> jblack : I checked this a while ago, you can't reload apache I believe.
[01:07] <elmo> jblack: sudo apache2ctl graceful
[01:08] <elmo> jblack: but at some stage (just not today or this week) we may need to revisit this and how slack we/I've gotten WRT permissions on vostok ;)
[01:09] <jblack> Yeah. We need that conversation. I'd like it really soon though, because not having ssh access to the supermirror account is causing heck on rollout.
[01:09] <lifeless> ok,
[01:09] <lifeless> more cron spam
[01:09] <lifeless> spiv: may want to disable the 'info lockfile acquired' :)
[01:24] <lifeless> jblack: how you going with that redirect
[01:24] <jblack> I'm trying.
[01:24] <lifeless> jblack: I get infinite redirect now
[01:24] <jblack> I have this:
[01:24] <jblack>   RewriteRule ^(~[^/] +/[^/] +/[^/] +)/ /\+branches/${branch-list:$1}/
[01:24] <jblack>   RewriteRule ^/\+branches/([[:xdigit:] ] {2})([[:xdigit:] ] {2})([[:xdigit:] ] {2})([[:xdigit:] ] {2})/ /$1/$2/$3/$4/
[01:25] <jblack> which gives me this: [Wed Dec 21 12:25:06 2005]  [error]  [client 209.158.45.78]  File does not exist: /srv/sm-ng/mirrors/+branches
[01:26] <jblack> oh, duh
[01:26] <lifeless> ok
[01:26] <lifeless> ^\+branches
[01:26] <jblack> The first rule gobles up .* 
[01:26] <lifeless> I think is what you want
[01:27] <lifeless> shouldn't
[01:28] <lifeless> it needs ~
[01:28] <lifeless> so the it wonter interact
[01:28] <lifeless> no I think the problem is the leadng /
[01:28] <elmo> lifeless: rsync target is launchpad@bazaar.launchpad.net::config/launchpad-lookup.txt
[01:28] <elmo> lifeless: password is in /srv/launchpad.net/rsync-password
[01:28] <elmo> WFM
[01:29] <elmo> NB: you need to use b.lp.net, not vostok (and that's a feature)
[01:29] <lifeless> ok
[01:29] <elmo> lifeless: also be careful of permissions on vostok, they're delicate, but will do for now
[01:29] <elmo> I'm AFK for a bit, but please shout soon if it's not sufficent as I have to go to the DC
[01:29] <lifeless> elmo: how do I tell rsync the password ?
[01:30] <lifeless> elmo: launchpad:pw@... ?
[01:30] <jblack> Nope, that didn't do it. Nor did ^\\+ 
[01:30] <lifeless> jblack: I know that spiv tested this
[01:30] <elmo> lifeless: RSYNC_PASSWORD or --password-file
[01:30] <lifeless> jblack: so lets reset to what he had.
[01:31] <elmo> lifeless: (btw, I didn't intend that rsync-password file to be final, it's just a temporary thing, if you keep it in a file, please put it somewhere more sane :)
[01:31] <lifeless> elmo: oh, ok
[01:31] <lifeless> uhm crontab safe enough ?
[01:32] <elmo> yeah
[01:36] <lifeless> ok
[01:36] <lifeless> jblack: can you check launchpad-lookup.txt
[01:36] <lifeless> it should be valid now
[01:36] <lifeless> elmo: thank you hugely
[01:36] <jblack> lifeless: Looks like it has useful data
[01:37] <lifeless> jblack: ok
[01:37] <lifeless> jblack: ok, show me your current rewrite rules ?
[01:38] <jblack> I've disabld that one for the moment
[01:38] <lifeless> ok, can we go back to what you had an hour ago ?
[01:38] <lifeless> i.e. both enabled, with spivs values which we know to be wrong ;)
[01:40] <jblack> I'm guessing that you're not aware that I'm talking to spiv
[01:40] <lifeless> I'm not
[01:40] <lifeless> may I suggest this channelo
[01:40] <lifeless> is an appropriate forum
[01:41] <jblack> Ok. I've got progress. ;) 
[01:41] <jblack> Of a sort.
[01:41] <jblack> The / is necesasry.
[01:41] <lifeless> what do you mean 'of a sort' ?
[01:42] <jblack> The rewrite rule is rewriting
[01:42] <jblack> However, its rewriting the wrong thingh
[01:42] <lifeless> show me ?
[01:42] <jblack> 209.158.45.78 - - [21/Dec/2005:12:42:45 +0000]  [bazaar.launchpad.net/sid#80b7f30] [rid#81961e0/initial]  (2) prefixed with document_root to /srv/sm-ng/mirrors/00/00/05/31/
[01:42] <jblack> 209.158.45.78 - - [21/Dec/2005:12:42:45 +0000]  [bazaar.launchpad.net/sid#80b7f30] [rid#81961e0/initial]  (1) go-ahead with /srv/sm-ng/mirrors/00/00/05/31/ [OK] 
[01:43] <lifeless> the rule I meant :)
[01:43] <jblack> oh
[01:43] <jblack>   RewriteRule ^(~[^/] +/[^/] +/[^/] +)/ branches/${branch-list:$1}/
[01:43] <jblack>   RewriteRule ^/branches/([[:xdigit:] ] {2})([[:xdigit:] ] {2})([[:xdigit:] ] {2})([[:xdigit:] ] {2})/ /$1/$2/$3/$4/
[01:44] <jblack> All of the branches sm-mg writes are in /srv/sm-ng/mirrors/00/00/02/...
[01:44] <lifeless> ok
[01:44] <lifeless> the doc root is /src/sm-ng/mirrors to right ?
[01:44] <jblack>  /srv/sm-ng/mirrors actually
[01:45] <lifeless> yhehe
[01:45] <lifeless> thats what I meant
[01:45] <lifeless> ok.
[01:45] <spiv> I'm falling asleep.
[01:45] <lifeless> so its infinitely redirecting
[01:45] <lifeless> which is a two-step problem
[01:45] <jblack> I get 404s
[01:45] <spiv> Good luck :)
[01:46] <lifeless> the first step is that something is issueing 302s
[01:46] <lifeless> spiv: did you have this working ?
[01:46] <spiv> lifeless: On my local system, yes.
[01:46] <lifeless> spiv: differences ?
[01:46] <spiv> My email gave all the information that seemed relevant to me.
[01:46] <jblack> The url needed for launchpad id lookup is  /branches/00000531/ 
[01:46] <spiv> lifeless: Sorry, I'm just too tired to be helpful right now.
[01:46] <lifeless> spiv: ok, np
[01:47] <lifeless> jblack: lets focus on the name mapping first
[01:47] <jblack> sure
[01:47] <lifeless> what does http://bazaar.launchpad.net/~mdz/ltsp/ubuntu-main/ generate for youo, and whats the rewrite rule for it ?
[01:49] <jblack> Heh. Lets slow up for a moment? 
[01:49] <lifeless> jblack: ok
[01:49] <jblack> The problem with the infinit redirect is the two rewrite rules
[01:50] <lifeless> ok. comment out the one for b.l.p/xxxxxxxx
[01:50] <lifeless> (because if that goes on a different vhost anyway, it wont be an issue)
[01:51] <jblack> done
[01:51] <lifeless> ok
[01:51] <lifeless> so whats the other rewrite rulle look like ?
[01:51] <jblack> #  RewriteRule ^\/branches/([[:xdigit:] ] {2})([[:xdigit:] ] {2})([[:xdigit:] ] {2})([[:xdigit:] ] {2})/ /$1/$2/$3/$4/
[01:52] <lifeless> sorry, the uncommented one
[01:52] <jblack>   RewriteRule ^(~[^/] +/[^/] +/[^/] +)/ branches/${branch-list:$1}/
[01:52] <lifeless> ok
[01:52] <lifeless> can you change that to
[01:52] <lifeless> RewriteRule ^(~[^/] +/[^/] +/[^/] +)/ ${branch-list:$1}/
[01:52] <jblack> sure.
[01:53] <jblack> I think its missing a leading /
[01:53] <lifeless> well
[01:53] <jblack> 220.240.131.107 - - [21/Dec/2005:12:53:27 +0000]  [bazaar.launchpad.net/sid#80d1f98] [rid#81cf200/initial]  (1) pass through /~mdz/ltsp/ubuntu-main/
[01:53] <lifeless> ok
[01:53] <lifeless> so lets add
[01:54] <lifeless> RewriteRule ^/(~[^/] +/[^/] +/[^/] +)/ ${branch-list:$1}/
[01:54] <jblack> 209.158.45.78 - - [21/Dec/2005:12:54:03 +0000]  [bazaar.launchpad.net/sid#80c9f78] [rid#81800b0/initial]  (2) local path result: 00/00/02/13/
[01:54] <jblack> Thats not what I did actually
[01:54] <lifeless> what did you do ?
[01:54] <jblack>   RewriteRule ^\/(~[^/] +/[^/] +/[^/] +)/ ${branch-list:$1}/
[01:54] <jblack> but that gave a 400
[01:54] <lifeless> wont work
[01:55] <jblack> Ok. thats close
[01:55] <jblack>   RewriteRule ^/(~[^/] +/[^/] +/[^/] +)/ /${branch-list:$1}/
[01:55] <lifeless> ok
[01:55] <jblack> Its looping still
[01:55] <lifeless> now its directing blarh/ to blarh/index.html
[01:56] <jblack> Yeah
[01:56] <lifeless> and that is missing
[01:56] <lifeless> whats strange is the repeat redirect
[01:56] <lifeless> theres something else in your config causing this
[01:57] <jblack> 209.158.45.78 - - [21/Dec/2005:12:56:50 +0000]  [bazaar.launchpad.net/sid#80b9f38] [rid#8197100/subreq]  (2) prefixed with document_root to /srv/sm-ng/mirrors/00/00/02/13/
[01:57] <jblack> 209.158.45.78 - - [21/Dec/2005:12:56:50 +0000]  [bazaar.launchpad.net/sid#80b9f38] [rid#8197100/subreq]  (1) go-ahead with /srv/sm-ng/mirrors/00/00/02/13/ [OK] 
[01:57] <jblack> I think the redirect is catching again
[01:57] <lifeless> no
[01:57] <lifeless> it cant match, theres no ~
[01:57] <lifeless> its sending replies to the browser
[01:58] <lifeless> I've checked with tethereal
[01:58] <daf> SteveA: around?
[01:59] <jblack> I'll happily paste you the whole virtualhost directive in msg
[01:59] <lifeless> might be in the default section
[01:59] <lifeless> which affects all vhosts
[01:59] <jblack> That'll take elmo. Thats outside of my control
[01:59] <SteveA> daf: yes
[01:59] <lifeless> this is what happens
[01:59] <lifeless> GET /~mdz/ltsp/ubuntu-main/ HTTP/1.1\r\n
[02:00] <lifeless>     HTTP/1.1 301 Moved Permanently\r\n
[02:00] <lifeless> ..
[02:00] <lifeless> Location: http://bazaar.launchpad.net/~mdz/ltsp/ubuntu-main/index.html/\r\n
[02:00] <lifeless> thats a different rule kicking in
[02:00] <lifeless> now
[02:00] <daf> SteveA: carlos and I have triaged all the bugs in Rosetta
[02:01] <lifeless> branch-format is kicking this in too
[02:01] <daf> SteveA: we're left with 106 open bugs
[02:01] <jblack> oh, I may know
[02:01] <lifeless> one sec
[02:01] <lifeless> oh?
[02:01] <daf> SteveA: we're wondering if you had any ideas about how to go about prioritising them
[02:01] <jblack> No.
[02:01] <lifeless> ok
[02:01] <lifeless> paste it to me baby!
[02:01] <jblack> sure
[02:02] <jblack> msg me?
[02:03] <SteveA> stub, jamesh: https://wiki.launchpad.canonical.com/BugzillaImportProcess
[02:04] <lifeless> jblack: done
[02:04] <jblack> you're done with what? 
[02:04] <lifeless> I msged you
[02:04] <jblack> I didn't see anything from you
[02:05] <SteveA> daf: how about you and i do a voice call to talk through the bugs?
[02:05] <lifeless> msged again
[02:05] <stub> ack
[02:05] <SteveA> it would be nice to have carlos involved, but i think three people would make things slower
[02:05] <daf> yes
[02:05] <daf> I agree
[02:05] <SteveA> we can call out to carlos on irc later for tricky questions
[02:06] <daf> and the conferencing stuff doesn't seem to reliable anyhow
[02:06] <daf> * too
[02:06] <SteveA> it wasn't so bad once we got it going
[02:06] <SteveA> although carlos' voice kept breaking up for me
[02:06] <daf> likwise
[02:06] <daf> and getting it going did take some time
[02:07] <SteveA> this is true
[02:07] <SteveA> carlos, daf: is there a bug about sending email once for a whole tarball import?
[02:08] <daf> not that I know of
[02:08] <daf> is that a bug?
[02:08] <SteveA> a user uploading one tarball
[02:08] <SteveA> and later receiving 250 emails
[02:08] <SteveA> is a bug
[02:09] <SteveA> a single action should not result in such a response
[02:09] <daf> oh
[02:09] <daf> I got the impression from what you said that the problem was opposite
[02:09] <daf> yes, that is a bug
[02:09] <SteveA> http://people.ubuntu.com/~fabbione/irclogs/launchpad-current.html
[02:09] <SteveA> see today's log, seach for hannosch
[02:09] <SteveA> hannosch would like to be subscribed to that bug
[02:10] <daf> I think few enough people have tried to use the tarball upload that they haven't complained much
[02:11] <daf> hmm, I was trying to get a list of all 121 open bugs at once by setting batch_start and batch_end by hand
[02:11] <daf> but that doesn't seem to work: it just gives me 20 from batch_start
[02:11] <SteveA> i think there is a malone bug on that
[02:12] <SteveA> there should be a hardcoded absolute limit
[02:12] <SteveA> although, even that isn't needed now
[02:12] <SteveA> because we have timeouts on long queries / expensive pages
[02:12] <daf> indeed
[02:12] <SteveA> so, people should be able to change the batch boundaries
[02:13] <stub> Within limits, or else people are just going to engineer timeouts
[02:14] <SteveA> i don't follow
[02:14] <SteveA> if someone gets a timeout, then the page doesn't work
[02:14] <SteveA> but it still isn't so expensive
[02:14] <stub> Indeed. People set their batch size to 5000, and some pages stop working
[02:14] <daf> if they file a bug, we can say "batch sizes of 5000" are not supported
[02:15] <SteveA> if they're messing with the URL directly...
[02:15] <carlos> Rosetta's translation form has a limit of 100 entries per page
[02:15] <SteveA> then they can expect that
[02:15] <daf> quite
[02:15] <stub> Batch size can be stuffed in the session and used everywhere we batch
[02:15] <SteveA> now, if we have a UI for setting prefered batch size, of course there should be limits
[02:15] <stub> Just a user preference
[02:15] <SteveA> and mpt has said in the past that there are different appropriate sizes for different things
[02:15] <carlos> daf, are you going to file that bug?
[02:15] <carlos> (the one SteveA asked)
[02:16] <daf> yes
[02:16] <daf> just as soon as I've filed this Malone bug
[02:16] <carlos> ok
[02:18] <daf> hmm, isn't there a way to search for bugs across all products?
[02:18] <SteveA> everything in a context
[02:18] <SteveA> we'll want this when we have keywords, though
[02:19] <daf> well, I was thinking that if there was an existing bug about tarballs, it might be filed against Launchpad rather than Rosetta
[02:19] <daf> so I have to search both by hand
[02:19] <SteveA> we should be able to seach within a project, at least
[02:20] <SteveA> but, it is not possible today
[02:20] <SteveA> stub: when's the code on staging going to be updated?
[02:20] <stub> erm... now?
[02:21] <stub> Kinnison: ping
[02:21] <SteveA> oh, cool
[02:21] <SteveA> i want to see how some of the recent PQM landings look
[02:24] <stub> I'll set it up for daily code updates again.
[02:24] <stub> But need to talk to Kinnison about the database
[02:24] <stub> (or is he on leave?)
[02:25] <daf> he is on leave, I believe
[02:26] <SteveA> i updated https://wiki.launchpad.canonical.com/BugzillaImportProcess
[02:27] <SteveA> stub, jamesh: maybe subscribe to it?
[02:27] <stub> ack
[02:28] <stub> Staging updated (up to r2930)
[02:30] <SteveA> hmm, the site map's CSS causes it to shift around a bit when different things are selected
[02:34] <jordi> carlos: so the "can't add people to groups" bug, it's quite important if I'm going to create and manage Translation Project teams
[02:35] <jordi> (for tin, xkbconfig etc)
[02:35] <carlos> jordi, I don't understand the issue there...
[02:35] <carlos> the owner of the team will be able to promote anyone either to member or to admin
[02:36] <jordi> carlos: I'm talking about groups, not teams
[02:36] <jordi> Translation Project, GNU Translators, etc.
[02:36] <carlos> jordi, and for the GNU teams we cannot let anyone to do it... it's a rosetta expert task
[02:36] <carlos> jordi, but there you appoint a team
[02:36] <carlos> no a list of people
[02:36] <carlos> so the owner of the team handle the people
[02:36] <jordi> carlos: ok, but a rosetta expert can't do it yet
[02:36] <jordi> I have no perms
[02:36] <carlos> jordi, ok, you cannot appoint new teams, right
[02:36] <jordi> carlos: still, I can't appoint teams
[02:37] <SteveA> daf: when do you want to do that call?
[02:37] <carlos> but If that's the issue, I think we already have that bug...
[02:37] <jordi> I just filed it
[02:37] <carlos> and it's Rosetta specific
[02:37] <carlos> no, I think it's older than one month
[02:38] <carlos> jordi, https://launchpad.net/products/rosetta/+bug/1882
[02:38] <Ubugtu> Malone bug #1882: Rosetta Experts cannot add members to existing groups In: rosetta (upstream), Severity: Major, Assigned to: Carlos Perell Marn, Status: Accepted https://launchpad.net/bugs/1882
[02:39] <carlos> jordi, so, can I set the other bug as a duplicate of this one?
[02:39] <jordi> so I filed the same bug twice..
[02:39] <carlos> right
[02:39] <carlos> jordi, you suck :-P
[02:39] <jordi> yup
[02:39] <jordi> the second one was more verbose. :)
[02:39] <carlos> ok, I will set the 1882 as the duplicate
[02:41] <daf> SteveA: hmm, not sure
[02:41] <carlos> jordi, done
[02:41] <SteveA> daf: well, i could make some food now, and we can do it in a while
[02:41] <daf> ok, I could eat too
[02:41] <SteveA> daf: how much longer do you have at work today?
[02:42] <daf> about 1:45
[02:42] <SteveA> we could both eat, and then do a couple of hours of bug conversation
[02:43] <daf> ok, sounds good
[02:56] <dilys> Merge to devel/launchpad: Implement http://wiki.launchpad.canonical.com/ProperSignUpWorkflow. r=lifeless (r2931: Guilherme Salgado)
[02:57] <stub> Gina is up to breezy with no ERRORs
[02:58] <SteveA> cool
[03:09] <jblack> elmo: still around? 
[03:10] <lifeless> stub: ping
[03:10] <lifeless> stub: check gangotris crontab -e
[03:10] <lifeless> stub: for that new script entry.
[03:14] <lifeless> SteveA: FYI, branch publication of pulled branches is now live, kudos to jblack, spiv
[03:14] <jblack> partially live.
[03:14] <jblack> its not cronned yet and it breaks if a branch doesn't exist
[03:14] <lifeless> jblack: it publishes successfully pulled branches
[03:15] <lifeless> jblack: cron it man!
[03:15] <lifeless> and I'll do up a test case with you tomorrow
[03:15] <lifeless> first thing when you and I are both around
[03:15] <jblack> it publishes successfully until the first unsuccesfully pulled branch.
[03:15] <jblack> And there's a problem iwth the lockfile in that it doesn't timeout.
[03:15] <lifeless> jblack: one step at a time.
[03:15] <jblack> hit a bad one, dump. won't restart because... 
[03:16] <lbm> i need an admin to help me clean up gnomebaker in launchpad, anyone?
[03:16] <jblack> yeah, one step at a time
[03:16] <lifeless> jblack: its not bug free, but it is live.
[03:16] <lifeless> live != finished
[03:16] <lifeless> you will now get feedback and questions from people, which you could not before
[03:16] <lifeless> anyhow, zzzz for me.
[03:19] <jblack> Anybody want me before I do some christmas shopping?
[03:26] <daf> SteveA: ready when you are
[03:33] <bradb> jblack: How do I unlock a branch with bzr?
[03:36] <bradb> lifeless: The --story code was already approved. The branch has been outstanding for a couple of weeks, and if I'm blocked on adding tests for --story it's unlikely that this code will land before 2006. Can I get your sign-off on landing it, if I open a High priority bug on adding a test for it?
[03:36] <SteveA> daf: hi
[03:37] <daf> SteveA: hi
[03:38] <SteveA> ready?
[03:38] <daf> yes
[04:40] <jordi> carlos: saw my addenum to the groups bug?
[04:41] <carlos> jordi, yes
[04:41] <carlos> jordi, the problem is that the system was not designed to have many translation groups
[04:41] <carlos> but it's just a matter of adding the owner concept
[04:41] <carlos> so it should not be too hard to implement
[04:43] <jordi> carlos: yup. But it's clear we need a few more than what we thought.
[04:43] <jordi> for some people it's completely necessary.
[04:44] <matsubara> salgado, stub: Could you subscribe me to the launchpad-devel mailing list?
[04:48] <carlos> jordi, yeah
[04:48] <carlos> will be back later
[04:49] <carlos> SteveA, daf do you need anything from me now?
[04:49] <carlos> I suppose I will be out for an hour or so
[04:50] <jordi> carlos: if you could answer the OOo question...
[04:50] <carlos> which OOo question?
[04:51] <lbm> carlos: you have a minute?
[04:51] <jordi> carlos: wait
[04:51] <carlos> lbm, is it really urgent? I need to leave for an hour...
[04:51] <jordi> doko answered
[04:51] <carlos> jordi, ok
[04:51] <SteveA> carlos: it's fine
[04:51] <carlos> ok
[04:51] <lbm> carlos: no, just need a little help to clean up gnomebaker in launchpad
[04:51] <lbm> carlos: will you have a minute later tonight?
[04:52] <carlos> lbm, ok
[04:52] <carlos> lbm, sure
[04:52] <carlos> lbm, anyway, talk with jordi just in case he can help you (if he has time)
[04:52] <lbm> carlos: great
[04:52] <carlos> lbm, I will ping you when I'm back
[04:52] <jordi> hey lbm 
[04:52] <carlos> cheers
[04:52] <carlos> see you in an hour
[04:52] <lbm> jordi: hi, maybe you can help me
[04:53] <jordi> lbm: hopefully!
[04:53] <jordi> are you a gnomebaker maintainer?
[04:53] <lbm> well, i'm the translation coordinator for gnomebaker
[04:53] <lbm> i'm a maintainer yes
[04:53] <lbm> but i need to understand this system
[04:54] <jordi> just ask
[04:55] <lbm> it's possible for every user to translate the template in ubuntu packages, right?
[04:55] <jordi> no, only people in the "Ubuntu translators" translator group
[04:56] <jordi> anyone can translate the template in thep roduct, though
[04:56] <jordi> https://launchpad.net/products/gnomebaker/+series/main/+pots/gnomebaker
[04:58] <lbm> jordi: okay, are these translations backported to the packages from time to time?
[04:59] <lbm> and how do people get in the "Ubuntu translators" group?
[05:01] <lbm> nevermind about the last question, i didn't realise all the different i18n groups was linked to "Ubuntu translators"
[05:11] <daf> sivang: are you around?
[05:19] <jordi> lbm: we're working on the "backported" thing. For now, it's responsability of the translators to move them from one branch to the other, but we have a plan to be able to say "put all my translations I'm doing for gnomebaker MAIN in all ubuntu releases"
[05:19] <jordi> etc
[05:24] <SteveA> stub: hello
[05:28] <lbm> jordi: great! so users shouldn't really translate missing strings in the ubuntu package templates?
[05:28] <lbm> yet it is
[05:32] <lbm> since all work essentially aren't used
[05:32] <jordi> lbm: they are used in language packs for ubuntu
[05:32] <jordi> lbm: what they should do, is export their work and import it in the distro
[05:32] <jordi> it'll be a lot easier when we have this feature in place
[05:33] <lbm> okay
[05:34] <lbm> jordi: i see one branch, MAIN, which is fint
[05:35] <lbm> but also two "versions"
[05:35] <lbm> why?
[05:44] <jordi> let me see
[05:45] <jordi> ok
[05:45] <jordi> so you have a branch
[05:45] <jordi> which is your CVS/SVN trunk version
[05:45] <jordi> and, someone has registered two releases coming from that branch.
[05:46] <jordi> so when 0.5.4 releases, you can register that release too
[05:46] <lbm> they shouldn't be there
[05:47] <lbm> and what is the difference between release series and branch? which type is "MAIN" in the product?
[05:48] <lbm> i can't see why other people should be able to create these releases
[05:55] <jordi> hmm.
[05:55] <jordi> They shouldn't be able
[05:56] <jordi> if they are able to, it's a very grave bug
[05:56] <lbm> the former maintainer did one of them, but the other person i don't know
[05:57] <lbm> shouldn't i as the maintainer be able to edit all aspects of the product, such as removing those releases?
[06:03] <jordi> yes, these are current limitations in the system. It's improving, but it takes time.
[06:04] <lbm> okay, could you please delete those releases
[06:04] <lbm> what is the difference between release series and branch? which type is "MAIN" in the product?
[06:12] <LarstiQ> bazaar.launchpad.net isn't reachable for me, should it be?
[06:27] <jordi> lbm: MAIN is a series
[06:27] <jordi> a Branch is a "bazaar branch", nothing to do with the series
[06:29] <lbm> okay, and branch can also contain translations?
[06:32] <lbm> i don't get the idea, really
[06:34] <jordi> no
[06:34] <jordi> forget about branches, you should have in mind there are templates for a given series
[06:34] <jordi> and templates for ubuntu releases
[06:34] <lbm> okay :)
[06:35] <jordi> branches is to register a bazaar branch with gnomebaker code, which isn't your case now.
[06:35] <jordi> aha
[06:35] <lbm> oh, i see
[06:35] <jordi> maybe this helps a little bit, because it explains the difference between the two
[06:36] <jordi> http://wiki.launchpad.canonical.com/RosettaNewImportPolicy
[06:37] <lbm> thanks ;)
[06:38] <jordi> np!
[06:38] <jordi> I know we're missing docs. I'm working on it, but you imagine it's qutie a huge task
[06:38] <jordi> for now, just ask me! :)
[06:39] <jordi> SteveA: I wonder if you have access to removing product releases from a rpoduct page
[06:39] <jordi> if so, can you get rid of those two xqf releases?
[06:40] <lbm> jordi: the two gnomebaker releases in MAIN series also, please
[06:43] <jordi> SteveA: doh
[06:43] <jordi> I said xqf, I meant gnomebaker!
[06:43] <jordi> lbm: oops!
[06:44] <lbm> :)
[06:44] <SteveA> jordi: i can't do that.  only stu can remove things, in general.
[06:44] <jordi> ok.
[06:44] <jordi> I'll mail the list.
[06:46] <jordi> done
[06:46] <jordi> lbm: I expect this to be done in the next few hours.
[06:47] <lbm> jordi: thanks alot
[06:47] <jordi> np!
[06:47] <lbm> jordi: are templates (pot) and translations (po) sync'ed from, in this case, cvs yet?
[06:48] <lbm> i see launchpad have the details already: https://launchpad.net/products/gnomebaker/+series/main
[06:52] <jordi> not yet
[06:52] <jordi> tis "syncing" thing is that it's syncing CVS with the bazaar branch launchpad creates for it.
[06:53] <jordi> lbm: for now, you need to manually upload new templates.
[06:54] <lbm> jordi: okay, i'm close to get a basic understanding :)
[06:54] <jordi> keep the questions coming ;)
[06:55] <lbm> jordi: maybe you guys should write a weekly update and throw it at launchpad-users
[06:58] <dilys> Merge to devel/launchpad: [r=jamesh]  implement InitialBugConctacts and fix a nasty login() bug (r2932: Brad Bollenbach)
[07:01] <marc``> I come to register, but email of confirm don't come yet...
[07:02] <SteveA> hi marc`` 
[07:03] <SteveA> how long have you been waiting?
[07:04] <marc``> 10min
[07:05] <marc``> I hope it's automatic... so normally I would have it :)
[07:05] <lbm> jordi: let's say i edit the danish translation of MAIN locally and another guy do it through rosetta, he saves and i upload my changes, how is this merged?
[07:05] <SteveA> marc``: well, it should have come to you
[07:06] <jordi> lbm: will depend on the kind of upload you do.
[07:06] <SteveA> marc``: can you /msg me the email address you used?
[07:06] <SteveA> i'll try sending you a test message from the server
[07:06] <jordi> if you do a "published upload", the guy will have preference
[07:06] <jordi> if not, you'll have precedence
[07:07] <SteveA> actually, marc``, that might not work
[07:07] <marc``> SteveA: thanks, I will wait yet... 
[07:07] <lbm> jordi: https://launchpad.net/products/gnomebaker/+series/main/+pots/gnomebaker/+upload says nothing about published or not
[07:08] <SteveA> unless you are registered with this irc server
[07:08] <jordi> lbm: a general upload (for a pot + all languages) is always considered a published upload
[07:08] <SteveA> marc``: if you still have problems later, mail me: steve @ canonical.com
[07:09] <jordi> lbm: compare that to this
[07:09] <SteveA> be sure to tell me what email address you use to sign up with
[07:09] <jordi> https://launchpad.net/products/gnomebaker/+series/main/+pots/gnomebaker/ca/+upload
[07:11] <jordi> lbm: see?
[07:14] <lbm> jordi: oh, i see, thanks
[07:24] <carlos> lbm, I'm back. It took me much more time than I expected...
[07:24] <carlos> lbm, did jordi solved all your questions?
[07:25] <jordi> carlos: for now :)
[07:27] <carlos> jordi, cool, thanks!
[07:28] <lbm> :)
[07:33] <jordi> I'm out of office now
[07:47] <sivang> daf: now I am , what's up?
[08:06] <SteveA> bradb: https://wiki.launchpad.canonical.com/BugzillaImportProcess
[08:08] <bradb> SteveA: The status of InitialBugContacts (as per the "To do" item) is that it's landed and ready to go.
[08:09] <SteveA> yep
[08:09] <SteveA> i added that to the notes
[08:09] <SteveA> would you update the notes when the status changes land?
[08:10] <bradb> Sure.
[08:10] <bradb> Do you mind if I remove the todo item about checking the IBC status?
[08:11] <SteveA> bradb: does the import script take account of IBC?
[08:12] <bradb> I specifically added PackageBugContacts beforehand so that jamesh could work with it, so it should. jamesh would have to confirm the default assignee => package bug contact conversion.
[08:12] <SteveA> so, you can change it to specifically confirm this
[08:12] <bradb> ok
[08:14] <bradb> updated
[08:35] <lbm> carlos: around?
[08:35] <carlos> lbm, yes
[08:36] <lbm> carlos: about translation export
[08:36] <carlos> lbm, yes?
[08:37] <lbm> carlos: rosetta doesn't retain the original comments in the top, which is quite bad
[08:37] <lbm> carlos: many groups have word conventions and comments there
[08:38] <carlos> lbm, hmmm, we store them
[08:38] <carlos> lbm, if you don't get them, it's a bug
[08:39] <lbm> carlos: one second, maybe it's my fault
[08:39] <carlos> ok
[08:40] <lbm> carlos: but there should be a way to edit comments in the top and individual string comments
[08:41] <carlos> lbm, yeah, that's a planned feature
[08:41] <lbm> carlos: great, do you have this list on the wiki?
[08:41] <carlos> the list of features?
[08:41] <carlos> well, we have a RosettaWishList
[08:42] <lbm> planned features, yes
[08:42] <carlos> but I think it's a bit outdated
[08:42] <lbm> okay, let me take a look
[08:42] <carlos> wiki.ubuntu.com/RosettaWishList
[08:42] <carlos> lbm, we have also some things at malone
[08:42] <lbm> okay
[08:42] <carlos> but the place where you can see our priorities is at https://launchpad.net/products/rosetta/+specs
[08:43] <carlos> lbm, the ones Approved with Essential or High priority are the features we are going to implement really soon
[08:43] <lbm> great, thanks
[08:44] <SteveA> carlos: did you see the notes on fixing some of the timeout problems in one of the bugs daf and i worked on today?
[08:44] <SteveA> on the suggested / wikimode translations
[08:44] <bradb> Where is the latest and greatest LP tree? I need access to the bleeding edge to resolve conflicts/failing tests in the status changes branch.
[08:44] <bradb> I though it would be in /home/warthogs/archives/rocketfuel/launchpad/devel, but my patch is not there.
[08:45] <SteveA> bradb: maybe jblack can help with that, and add the answer to the bzr-for-launchpad docs
[08:45] <SteveA> bradb: remember about pqm being elsewhere
[08:45] <SteveA> it may take a few minutes for them to sync up
[08:45] <bradb> Yep.
[08:45] <SteveA> but i do not know the details
[08:45] <bradb> I've been waiting for almost two hours, that's why I ask.
[08:46] <SteveA> in a few hours more, lifeless will be around for a definitive answer
[08:46] <carlos> SteveA, yes, I saw them
[08:46] <SteveA> it would be good to get these things documented, though
[08:46] <bradb> indeed
[08:46] <carlos> SteveA, and it's a good start to improve that timeout problem, thanks
[08:46] <SteveA> carlos: i think fixing that would make a huge difference to people using rosetta
[08:47] <carlos> SteveA, ok, I will implement them now, it's one of the most reported bugs we have atm...
[08:47] <SteveA> that's great carlos
[09:02] <lbm> carlos: my fault, comments was exported as well, sorry
[09:03] <carlos> lbm, no worries
[09:07] <lucasvo> is launchpad offering to host a branch of bzr? We need a place to host Edubuntu cookbook
[09:21] <carlos> lucasvo, launchpad mirrors bzr branches, yes (or at least will do it soon) but you still need a public place from where launchpad fetchs it
[09:22] <lucasvo> carlos: ah, ok
[09:23] <salgado> cprov, I added two more questions (the ones at the bottom) to https://wiki.launchpad.canonical.com/MirrorManagement. would you check to see if you know the answer?
[09:24] <lucasvo> carlos: so it is only a mirror, not meant as a place where all the developers merge togehter?
[09:24] <cprov> salgado: sure
[09:26] <carlos> lucasvo, yes, at least now. Perhaps in the near future it would host archives... Anyway, is better if you talk with lifeless, ddaa or jblack about it
[09:26] <carlos> lucasvo, I don't know all the details
[09:26] <lucasvo> ok
[09:50] <highvoltage> hi. any launchpad admins around?
[10:19] <sivang> carlos: I think supermirror is the place where archives will be hosted, and launchpad will just watch them?
[10:21] <carlos> sivang, supermirror is part of launchpad at least I think it will be
[10:21] <carlos> highvoltage, hi, what do you need?
[10:22] <highvoltage> carlos: i need to change the e-mail address my @ubuntu.com forwards to.
[10:22] <sivang> carlos: ah :)
[10:23] <snotling> hello, there's a package in dapper which is not present in malone -- a package for which i'd like to file a 'bug', an update wish that is
[10:24] <carlos> highvoltage, hmmm, I'm not sure I'm able to do that....
[10:24] <highvoltage> carlos: ok, thanks. i'll hang around a bit more.
[10:24] <carlos> highvoltage, what's your current address?
[10:25] <highvoltage> it currently forwards to jonathan@shuttleworthfoundation.org (from jonathan@ubuntu.com)
[10:26] <carlos> highvoltage, I think it does not depends on launchpad (at least now)
[10:26] <carlos> highvoltage, ask Znarl or elmo 
[10:26] <highvoltage> ah, ok.
[10:26] <jordi> carlos: hey I saw the distro info on gnomebaker today
[10:26] <carlos> highvoltage, they are our sysadmin
[10:26] <jordi> that's very cool
[10:26] <highvoltage> carlos: I'll contact them, thanks.
[10:26] <carlos> highvoltage, you are welcome
[10:27] <carlos> jordi, ?
[10:27] <jordi> carlos: I hadn't seen that at all yet
[10:27] <jordi> if you go to gnomebaker/breezy, you have the distro info
[10:28] <carlos> jordi, https://launchpad.net/products/gnomebaker/breezy ?
[10:28] <carlos> it's a 404 page
[10:30] <jordi> carlos: no, in the distros/uubntu tree
[10:31] <carlos> jordi, oh! you mean the distro info
[10:31] <carlos> jordi, gina run ;-)
[10:32] <jordi> yeah
[10:45] <bradb> lifeless: ping
[10:50] <bradb> lifeless: Ah, n/m, I see on launchpad@ that you're working on fixing the chinstrap code synching problem.
[11:03] <mdke> spiv, around?
[11:08] <kjcole> ping any launchpad wizard. ;-)
[11:12] <SteveA> what's up kjcole ?
[11:13] <kjcole> Hi,  I'm looking at launchpad.net and it appears the only way to get a bzr branch there is to import it from something other than bzr. True?
[11:14] <SteveA> kind of
[11:15] <SteveA> this will be changing during next month
[11:15] <SteveA> and you'll be able to sftp push a branch to the supermirror
[11:15] <SteveA> and have it appear in launchpad
[11:16] <lifeless> morning
[11:16] <SteveA> morning lifeless
[11:17] <lifeless> SteveA: kjcole: you can have launchpad.net copy your existing bzr branches today.
[11:18] <SteveA> how does that work?
[11:18] <lifeless> SteveA: login to launchpad, visit your home page, click 'code', click 'add branch'
[11:19] <lifeless> bradb: pong
[11:19] <SteveA> lifeless: how does that copy my existing bzr branch?
[11:20] <lifeless> SteveA: a cron job will copy the branch from the location you give to http://bazaar.launchpad.net/~YOU/product/branchname
[11:22] <SteveA> wow.  advanced tech
[11:22] <bradb> lifeless: Are you still working on the problem of synching the latest Launchpad code onto chinstrap?
[11:23] <lifeless> SteveA: better believe it
[11:23] <kjcole> lifeless, so if I wait, my bzr branch will get picked up?  (I did the "add branch" several weeks ago.)
[11:24] <lifeless> kjcole: yes.
[11:24] <lifeless> kjcole: the statistics wont operate until early jan
[11:25] <lifeless> kjcole: http://bazaar.launchpad.net/~kjcole/edubunto.cookbook/wip is your branch
[11:25] <lifeless> kjcole: thats where it will be published once picked up
[11:25] <kjcole> lifeless, oh goodie. ;-)  
[11:25] <lifeless> bradb: I dont know what you are talking about
[11:26] <bradb> lifeless: The problem BjornT reported to launchpad@: not being able to synch up with the latest revision.
[11:30] <lifeless> bradb: there was something 3 odd days ago now
[11:30] <lifeless> bradb: which was fixed
[11:30] <lifeless> bradb: are you talking about something more recent ?
[11:31] <lifeless> bradb: w.r.t. the story patch, I'm offering to do the tests for it. If it passed the review team without tests before, well - you can of course land it, its not my call to stop it, but I'd much rather that it land with tests.
[11:32] <lifeless> *MUCH*
[11:32] <bradb> lifeless: I thought it was the same problem. The most recent revision is not available at chinstrap:/home/warthogs/archives/rocketfuel/launchpad/devel.
[11:33] <bradb> lifeless: I didn't merge --story with the InitialBugContacts merge. I reversed the patch to avoid blockage.
[11:34] <bradb> lifeless: i.e. this rev is not available in anywhere I'm used to looking: http://lists.canonical.com/mailman/private/arch-commits/2005-December/005132.html
[11:34] <bradb> Not having access to this patch is blocking merging the status changes.
[11:35] <lifeless> bradb: its being pushed up at the moment
[11:35] <lifeless> that takes upwards of 40 minutes or more
[11:35] <bradb> ok. presumably this problem is being fixed then?
[11:35] <lifeless> bradb: there is no specific problem here
[11:36] <lifeless> bradb: just the general performance issues that are in the pipeline
[11:36] <lifeless> bradb: there *was* a problem earlier in the week.
[11:37] <bradb> lifeless: I'm not sure what you mean. I've been waiting to get access to this code for six hours. How is that not a specific problem?
[11:37] <lifeless> bradb: thats how long it can take right now
[11:37] <bradb> oh
[11:37] <bradb> An email to launchpad@ might have helped avoid some head-banging. ;)
[11:38] <lifeless> but thats an extreme case
[11:38] <lifeless> its from you right
[11:38] <lifeless> why dont you just merge sideways ?
[11:38] <bradb> I wasn't sure if I could trust that. If I can, I will.
[11:39] <lifeless> its been merged (the email is only sent out after pqm passes it by policy).
[11:39] <lifeless> it then gets pushed locally on balleny, which is a almost-impossible-to-fail operation
[11:40] <lifeless> it then gets pushed to chinstrap, which was failing because of a stale sftp lock, probably because someone killed pqm. 
[11:40] <lifeless> if the push to chinstrap fails, the local push to balleny is uncommitted.
[11:40] <lifeless> so you cant -trust- it. But it *has* passed the pqm test run successfully.
[11:40] <lifeless> I hope that helps clarify it
[11:42] <bradb> Clearer. Hopefully this won't meet with the same chinstrap push failure next time. I just want to land. ;)
[11:45] <lifeless> if it meets the same failure as earlier this week, pqm will now email you to tell you
[11:47] <bradb> ok. btw, I'm not sure why there's another InitialBugContacts merge request from me in pqm's queue. It seems to have been there for a while now.
[11:47] <lifeless> thats this one
[11:48] <lifeless> until it finishes the mirror to chinstrap its still the active job
[11:48] <lifeless> once that finishes you will get your 'its all ok' confirmation from pqm.
[11:48] <bradb> ah
[12:03] <kjcole> lifeless, thanks for the help.  Between you and ogra, I'm slowly digesting it all... I think. ;-)  I'm going to run now and ponder the great mysteries of bzr/launchpad, etc.