| wgrant | jtv: Are you going to adjust Translations jobs to return a BuildStatus, or the master to not require it? | 00:24 |
|---|---|---|
| jtv | wgrant: my feeling is there'll be all sorts of consequences if I don't provide one... | 00:24 |
| wgrant | Heh, yes. | 00:25 |
| wgrant | It makes sense and is easy to, and it should unbreak lots of stuff, so... | 00:25 |
| jtv | In particular, it'd be nice to know whether it was OK. :-) | 00:25 |
| jtv | btw bigjools ok'ed the idea of verifying slave build ids by re-generating & comparing. | 00:25 |
| jtv | So that pares the whole structure down to 1 method. :) | 00:25 |
| jtv | He didn't like the word "bake" for the cookie though. :( | 00:26 |
| wgrant | What about IS? | 00:26 |
| wgrant | And is there any reason for the cookie? | 00:26 |
| wgrant | BQ + datestarted should be enough. | 00:26 |
| jtv | Well it's a major trust boundary... why _should_ we give it all that info? | 00:27 |
| jtv | So BQ + datestarted would be enough, but I'd like to hash them. | 00:27 |
| wgrant | The build ID is public in logs from the start. | 00:28 |
| jtv | Build is, yes, and afaict that's used as the key. | 00:28 |
| wgrant | If I'm running a build on a builder and break out of the chroot, I can easily grab the ID from the existing real slave before I take over. | 00:28 |
| jtv | But no need to provide starting points for a compromised slave to make well-educated guesses as to the BQ id | 00:28 |
| jtv | aiui the slave knows the build id, but atm only knows the bq id because it happens to be encapsulated in the slave build id, right? | 00:29 |
| wgrant | Right. | 00:29 |
| wgrant | But what's the problem with possessing the BQ ID? | 00:30 |
| jtv | Well I'm assuming it's bad for a slave to impersonate the slave build id of another slave. | 00:30 |
| wgrant | It's not, really. The BQ is associated with the builder in the DB. | 00:30 |
| jtv | wgrant: but is association always checked? | 00:32 |
| wgrant | jtv: The slave ID is going to be checked by comparing the slave's ID with the ID generated from the BuildQueue associated with the slave in the DB, isn't it? | 00:32 |
| jtv | Yes | 00:32 |
| wgrant | So association is always checked. | 00:33 |
| wgrant | There are one or two places on the master that use the slave build ID in logs, but they are non-critical bugs. | 00:33 |
| wgrant | As long as it's not used for anything other than that check, it doesn't matter if somebody can impersonate another slave's build ID. | 00:33 |
| jtv | I meant, is the association between the slave build and the builder always checked? | 00:33 |
| jtv | And could a slave ever impersonate a pending or past job on the same builder? | 00:34 |
| wgrant | jtv: Past jobs don't have BQs. Pending jobs don't have builders assigned. | 00:34 |
| wgrant | there is a unique constraint on BuildQueue.builder. | 00:35 |
| jtv | okay, but keep some elbow room for things like changes in replication (as an example). | 00:36 |
| wgrant | The slave's build ID doesn't decide any behaviour on the master, except that it will compare the string against the one the builder is meant to have. | 00:36 |
| jtv | by the way, scary thought: that all evolves around the build id... what happens when different types of job have the same build ids (but for different BuildBase classes)? | 00:38 |
| wgrant | It doesn't matter. We cannot guard against malice. | 00:38 |
| jtv | This would be accident. | 00:39 |
| wgrant | Er. | 00:39 |
| wgrant | We're not talking about build IDs, are we? | 00:39 |
| wgrant | We're talking about BuildQueue IDs. | 00:39 |
| jtv | Well looking at the code, my impression is that the real identification happens by build id, and buildqueue id is merely a recurring pattern in the slave build ids. | 00:39 |
| wgrant | The current code grabs the BuildQueue ID, and checks that the BQ's build ID matches the one from the slave. | 00:40 |
| wgrant | BQ IDs are not reused. | 00:40 |
| jtv | That's inside verifySlaveBuildID. I'm talking about outside it. But hopefully it's just a wrong impression. | 00:41 |
| wgrant | Where outside it? | 00:41 |
| jtv | Ah, if only I remembered that. :) | 00:41 |
| wgrant | Nothing outside of that should use the slave build ID. | 00:41 |
| jtv | maybe I was just confused by the slave build id being passed as build_id. | 00:42 |
| jtv | It's enough to drive one to glue. | 00:43 |
| wgrant | Yeah, we should rename that. | 00:43 |
| wgrant | jtv: I was confused by this same thing on the day after the open sourcing. It looked like a big hole. | 00:48 |
| wgrant | But a little poking around revealed that the slave build ID wasn't actually used for anything important, despite how it appears. | 00:48 |
| jtv | I'm still hoping to pay a small price in code, in return for having other people worry about all that after I've gutted the code and fled the scene. | 00:49 |
| jtv | In fact I'm sure it's going to be easier to decide when the complexity around it is gone. | 00:50 |
| wgrant | You win a thousand ponies if you can remove all references to the slave build ID except in dispatchBuildToSlave, the thing that will compare it, and the slave itself. | 00:51 |
| wgrant | (not hard. probably mostly grepping and changing log strings.) | 00:51 |
| jtv | Okay, that does sound like a good idea. | 00:52 |
| mwhudson | wow | 03:19 |
| mwhudson | my crazy no-hosted-area hacking seems to work | 03:19 |
| thumper | cool | 03:20 |
| thumper | my 'completely change the way merge proposal email' hacking seems to work too :) | 03:20 |
| thumper | s/email/email is sent/ | 03:20 |
| mwhudson | thumper: hooray for redoing the underpinnings of launchpad | 03:21 |
| thumper | \o/ | 03:21 |
| thumper | we rock! | 03:21 |
| thumper | mwhudson: http://pastebin.ubuntu.com/400341/ | 03:22 |
| thumper | mwhudson: that is the new cron script :) | 03:22 |
| mwhudson | thumper: cool | 03:23 |
| thumper | hmm :( | 03:25 |
| thumper | 887 lines for this pipe without new tests | 03:25 |
| * thumper considers breaking it up more | 03:25 | |
| thumper | mwhudson: if you are after a break, we could have a quick call | 03:27 |
| thumper | mwhudson: I have a few pieces of news | 03:27 |
| mwhudson | thumper: ok | 03:27 |
| mwhudson | grr branch-rewrite.py is broken on lucid | 04:19 |
| wgrant | mwhudson: the PATH issue? | 04:19 |
| mwhudson | for really stupid reasons | 04:19 |
| mwhudson | wgrant: yeah | 04:19 |
| wgrant | I thought that had been around for longer than that. | 04:19 |
| wgrant | I've seen it for more than 6 months, I'm sure. | 04:19 |
| wgrant | A bug was filed a couple of weeks ago against -foundations somewhere. | 04:19 |
| mwhudson | i think it's time to stop for today | 04:45 |
| magcius | Is there a difference in types of code that goes into the canonical.launchpad and lp packages? | 07:01 |
| spm | magcius: no. just the config (obviously, server specific). it all comes from the same place. | 07:02 |
| magcius | spm: is stuff moving from one package gradually moving to the other | 07:03 |
| spm | hrm. I think I may have misunderstood your question and fired from the hip. are you asking if the code that runs launchpad.net is the same as is downloaded from https://code.edge.launchpad.net/~launchpad-pqm eg lp:launchpad/devel ?? | 07:06 |
| thumper | magcius: stuff is moving from canonical.launchpad into lp packages | 07:37 |
| thumper | magcius: we had really big moves early on for the major app bits | 07:37 |
| thumper | magcius: but it has been moving slowly since then | 07:37 |
| magcius | thumper: what's stopping you from just doing a rope rename? | 07:37 |
| thumper | magcius: I don't understand what you mean | 07:38 |
| magcius | thumper: http://rope.sourceforge.net/ | 07:39 |
| thumper | magcius: mostly because we are not sure where we want to move stuff | 07:40 |
| noodles775 | Hey thumper, did you see the conversation re. the url traversal (and the resulting breadcrumbs) on Aaron's MP? | 07:41 |
| thumper | noodles775: no | 07:41 |
| thumper | anything I need to know about right now? | 07:41 |
| noodles775 | thumper: no, it's not urgent, but if you get a chance tomorrow (I'm just wondering if there's a reason we don't put recipes under the (base) branch). | 07:42 |
| thumper | there was a reason | 07:43 |
| thumper | I'm trying to remember it | 07:43 |
| thumper | noodles775: the argument went round about... | 07:43 |
| noodles775 | The only reason I could think of (which Aaron also highlighted) is that it would be fragile if the base branch changes etc., but the original mockups didn't allow you to change the base branch of a recipe. | 07:43 |
| thumper | noodles775: and I picked something | 07:43 |
| noodles775 | thumper: no problem, as long as you guys have thought about it. | 07:44 |
| thumper | noodles775: but what about changing the name of a branch? | 07:44 |
| thumper | noodles775: or changing the owner | 07:44 |
| thumper | noodles775: both of those change the unique name of the branch | 07:44 |
| thumper | noodles775: and since the branch is accessed through the id, the recipe url would chnage | 07:44 |
| thumper | noodles775: also ~user/+recipe/name is short | 07:45 |
| noodles775 | thumper: I see, whereas both of those things wouldn't change the recipe url where it is currently? Great. | 07:45 |
| * thumper nods | 07:45 | |
| noodles775 | thumper: yeah, it just came up because I noticed the breadcrumbs are Person >> Branches >> Recipes | 07:45 |
| thumper | well... | 07:45 |
| thumper | should be: Person >> Branches >> Recipes >> build-my-cool-stuff | 07:46 |
| thumper | :) | 07:46 |
| noodles775 | Yep. | 07:46 |
| thumper | noodles775: I'd love for you to finish the review, it is blocking several branches:) | 07:47 |
| noodles775 | thumper: I'm doing it right now. | 07:47 |
| thumper | noodles775: remember that we can iterate the ui | 07:47 |
| thumper | noodles775: right now it isn't even enabled on edge | 07:47 |
| thumper | or won't be | 07:48 |
| noodles775 | thumper: sure. It's not that I'm seeing things that are blocked, but more that I can't see all the questions you guys have already asked etc., so need to catch up by asking them :/ | 07:48 |
| * thumper nods | 07:48 | |
| thumper | fair enough | 07:48 |
| wgrant | bigjools: Morning. | 08:29 |
| bigjools | morning! | 08:30 |
| * bigjools will disappear in a bit, my power is going out all day | 08:30 | |
| wgrant | Eww. | 08:30 |
| bigjools | I can relocate but my email is on a server at home, so ... | 08:30 |
| wgrant | Well, I've got two slight buildd-manager behaviour changes that are blocking buildmaster->soyuz shuffling that I was hoping you could OK quickly for me. | 08:32 |
| bigjools | if small | 08:32 |
| wgrant | http://bazaar.launchpad.net/~wgrant/launchpad/refactor-slave-architecture-check/revision/10567 <- buildd-manager is about to forget about DASes, so this crack-filled check needs refactoring. I don't think this diff is too bad, considering how wrong the check is. | 08:34 |
| thumper | bigjools: why is your power going out? | 08:34 |
| bigjools | thumper: power co is cutting trees around lines | 08:34 |
| thumper | ah | 08:35 |
| wgrant | bigjools: ... that requires turning the power off? | 08:35 |
| bigjools | apparently | 08:35 |
| * bigjools shrugs | 08:35 | |
| wgrant | How odd. | 08:35 |
| bigjools | not really, if the trees are all over live wires | 08:36 |
| wgrant | Heh, doesn't stop them here. | 08:37 |
| StevenK | Oh yeah, they'll cut back trees if the wires are live or not. | 08:37 |
| persia | Doesn't that have a tendency to cause fires? | 08:40 |
| bigjools | wgrant: that looks hackish and I have to run now, I'll look more later | 08:41 |
| bigjools | maybe noodles775 can look as well | 08:41 |
| noodles775 | Sure | 08:42 |
| * bigjools -> outta here, back in ~30mins | 08:42 | |
| noodles775 | wgrant: might even be worth creating a 'Work in progress' MP? | 08:42 |
| noodles775 | ah nice, getting rid of builder dependency on DAS :) | 08:43 |
| wgrant | It is hackish, yeah, but the current one is probably just as bad. | 08:43 |
| wgrant | (buildd-manager finds all the DASes. buildd-manager collects all buildds with a processor matching the DAS's family. buildd-manager iterates through the builders attached to each DAS, checking their arch tag against the DAS arch tag.) | 08:44 |
| wgrant | The problem is that builders have processors in the DB, but the actual slave has an arch tag. | 08:45 |
| wgrant | Although that check will go away entirely once we have multi-arch builders. | 08:45 |
| wgrant | A branch further along in the series changes the above buildd-manager logic to 'iterate through all of the builders' | 08:46 |
| wgrant | Which seems to make an awful lot more sense. | 08:46 |
| wgrant | And lets me delete 400 lines of code. | 08:46 |
| noodles775 | Nice :) | 08:46 |
| wgrant | So, basically, we can hugely simplify buildd-manager and remove its direct Soyuz dependency, at the cost of a temporary hack in a single Builder method, which will be fixed once we rethink builder arch affinity soon. | 08:48 |
| noodles775 | wgrant: I don't see what's worse about your check, than the one you removed? Both check whether the slave's builder_arch matches a das.architecturetag (only difference being that the das used to be passed in)? | 08:53 |
| noodles775 | So it seems like a good refactoring to me. | 08:53 |
| wgrant | Right. | 08:53 |
| wgrant | Both are making the best of a terrible situation. | 08:53 |
| * wgrant will argue with bigjools when he returns. | 08:53 | |
| noodles775 | wgrant: You're probably planning to anyway, but pls add a bug to that XXX reference at some point :) | 08:54 |
| noodles775 | wgrant: Why not include the processorfamily in the original query rather than as a separate check? | 08:56 |
| wgrant | noodles775: This lets us give a slightly better error. | 08:57 |
| noodles775 | That would make your new code almost identical in functionality? | 08:57 |
| noodles775 | Ah, ok. | 08:57 |
| wgrant | I suppose I could just say 'Mismatched slave architecture tag: foo' | 08:57 |
| wgrant | But the old one gave the correct value too.. | 08:58 |
| wgrant | noodles775: Can you do a quick search for that bug? Lots of that sort of thing are still private. | 08:59 |
| wgrant | There surely is one. | 08:59 |
| noodles775 | OK, I would have thought it would have been included in the XXX if there was noe. Checking now. | 08:59 |
| noodles775 | So just back to your raised exception, you could raise "Mismatched slave architecture, Architecture tag: %s, Processor family: %s"? | 09:01 |
| wgrant | noodles775: I could, true. | 09:01 |
| mrevell | Morgen | 09:03 |
| noodles775 | Hi mrevell | 09:04 |
| noodles775 | wgrant: nope, I can't see anything. Closest was bug 2072. | 09:05 |
| mup | Bug #2072: Processor/ProcessorFamily inconsistency in current DB model <Soyuz:Triaged> <https://launchpad.net/bugs/2072> | 09:05 |
| wgrant | noodles775: OK, thanks. | 09:05 |
| wgrant | We need launchpad-builfarm :( | 09:05 |
| wgrant | The fact that I have not broken any tests by changing the error message concerns me greatly. | 09:21 |
| noodles775 | wgrant: yep, grepping for "Architecture tag mismatch" or "BuildDaemonError" doesn't show any results in tests :/, but it's (yet another) chance to improved the codebase! | 09:25 |
| wgrant | Yep. | 09:25 |
| wgrant | Just working out how to. | 09:25 |
| wgrant | But first, dinner. | 09:25 |
| noodles775 | Enjoy! | 09:25 |
| wgrant | bigjools: https://code.edge.launchpad.net/~wgrant/launchpad/refactor-slave-architecture-check/+merge/22010, now with added tests. | 10:34 |
| wgrant | Also, you disabled soyuz-upload.txt in the apocalypse because it was failing. It now fails for me only because of post-apocalyptic bitrot. | 10:35 |
| wgrant | Should I fix and reenable it? | 10:36 |
| noodles775 | That would be great :) | 10:38 |
| bigjools | wgrant: yes please! | 11:00 |
| bigjools | wgrant: IIRC it failed because either poppy or something else was failing to start | 11:00 |
| bigjools | and it was unobvious as to why | 11:00 |
| wgrant | Seems to work OK now. | 11:01 |
| * wgrant proposed a merge. | 11:01 | |
| bigjools | there's a comment in there about random failures IIRC? | 11:01 |
| wgrant | Doesn't look like it. | 11:03 |
| bigjools | hmmm | 11:04 |
| bigjools | wgrant: there's an XXX from cprov about poppy | 11:05 |
| bigjools | the reason I disabled it was that poppy simply would not start in that test and we had no idea why, since it started ok outside the test. | 11:05 |
| wgrant | That file has enough XXXs... | 11:05 |
| wgrant | Hmm. | 11:06 |
| wgrant | It works fine inside now, though :/ | 11:06 |
| bigjools | the whole test is an XXX | 11:06 |
| bigjools | we had a load of lucid test failures last time I ran the whole suite | 11:07 |
| wgrant | There is only one persistent one. | 11:08 |
| wgrant | The a-f hash changes. | 11:08 |
| bigjools | yes | 11:08 |
| wgrant | Although a strange webservice-marshaller.txt one seems to have shown up recently. | 11:08 |
| wgrant | bigjools: Can you please have a look at that hack at some point so I can get it reviewed? | 11:11 |
| wgrant | noodles775: Thanks. | 11:14 |
| noodles775 | np | 11:14 |
| bigjools | wgrant: yep | 11:17 |
| bigjools | wgrant: can you mark it "needs review" | 11:20 |
| wgrant | bigjools: Oops. | 11:20 |
| bigjools | I want to see if I can test a theory about a bug | 11:20 |
| bigjools | if I click claim review right now, I get a "not allowed here" | 11:20 |
| wgrant | bigjools: 'tis now Needs Review. | 11:21 |
| bigjools | haha - noodles775 already reviewed it | 11:24 |
| bigjools | so that's why claim review didn't work | 11:24 |
| wgrant | Ahh. | 11:25 |
| wgrant | that's an odd response to that situation. | 11:25 |
| bigjools | it's a buggy response :) | 11:25 |
| wgrant | But I guess I can't think of anything better. | 11:25 |
| bigjools | it shoudl redirect back to the page with a notification | 11:25 |
| wgrant | Probably. | 11:25 |
| bigjools | btw we're not doing full ppa deletion in the first cut, to make life easier | 11:26 |
| bigjools | just the repo | 11:26 |
| wgrant | Ah, good. | 11:26 |
| wgrant | Much easier. | 11:26 |
| bigjools | very | 11:26 |
| wgrant | bigjools: Is the review link happier now? | 11:31 |
| bigjools | wgrant: well it was the "claim review" button that I was hitting but it's gone now | 11:35 |
| bigjools | I'm just re-reading it to see what was discussed | 11:35 |
| wgrant | Ah. | 11:35 |
| bigjools | wgrant: so it's kinda yucky I guess but as long as nothing is breaking I am ok with it. As you point out, the multi-arch builders will shake things up somewhat. | 11:40 |
| wgrant | bigjools: There were no tests before, there are now, and it works in practice. | 11:41 |
| wgrant | And it isolates the hack to a single method. | 11:41 |
| bigjools | yep | 11:41 |
| wgrant | Whereas it's currently deeply ingrained embedded in buildd-manager. | 11:41 |
| * bigjools grumbles about "make run" bailing out when there's no process running as per a PID file | 11:42 | |
| bigjools | I also discovered this morning that the local launchpad.dev doesn't work without an internet connection :/ | 11:42 |
| wgrant | Urgh. What goes wrong? | 11:43 |
| bigjools | didn't get far enough to work out why | 11:43 |
| wgrant | I've done it lots of times on the train. | 11:43 |
| bigjools | apache bails out saying it can't resolve | 11:43 |
| bigjools | I've done it before too, but this laptop is a new lucid installation | 11:43 |
| bigjools | so I suspect something has changed that's not part of the upgrade manager | 11:43 |
| wgrant | Hmm. | 11:44 |
| wgrant | bigjools: Thanks for the approval. I suppose you can't test today, so somebody else will have to land it? | 11:45 |
| bigjools | yeah sorry | 11:46 |
| * noodles775 sends it off. | 11:47 | |
| wgrant | noodles775: Thanks. | 11:47 |
| wgrant | bigjools: np | 11:47 |
| noodles775 | wgrant: np, wanna add the commit msg? | 11:48 |
| wgrant | noodles775: Done. | 11:49 |
| === mrevell is now known as mrevell-lunch | ||
| === matsubara-afk is now known as matsubara | ||
| deryck | allenap, hi. Did that CP for checkwatches land? | 13:07 |
| === jamalta_ is now known as jamalta | ||
| === mrevell-lunch is now known as mrevell | ||
| pabelanger | Does launchpad's ppa support building powerpc? | 13:37 |
| noodles775 | Hi pabelanger, the PPA overview has the list of currently supported architecturse: https://help.launchpad.net/Packaging/PPA | 13:42 |
| gary_poster | bac, Google thinks we have reviewer mtg in 9. Is it on Google-Calendar-doesn't-have-a-UTC-timezone crack? | 13:52 |
| bac | gary_poster: the meeting has been moved to 1400UTC, which is at the top of the hour | 13:53 |
| gary_poster | bac, ah, cool thanks | 13:53 |
| bac | gary_poster: is that what you see? | 13:53 |
| gary_poster | bac, yes. btw, if there is not an action item to ask if leonardr has a demo on how to use launchpadlib to test in launchpad, you should add one, and ask him. :-) | 13:54 |
| bac | gary_poster: oh, it is ready? cool! | 13:54 |
| gary_poster | yeah :-) | 13:54 |
| bac | cool | 13:54 |
| leonardr | bac: yes, look at lib/canonical/launchpad/pagetests/webservice/launchpadlib.txt | 13:54 |
| bac | reminder, reviewer's meeting in 2 minutes in #launchpad-meeting | 13:58 |
| allenap | deryck: Yes, and it's in LPS, ready for CP when possible. | 14:00 |
| deryck | allenap, excellent, thanks. | 14:01 |
| deryck | I thought the reviewer meeting was in an hour according to UTC, bac ? if not, I'm late. :-) | 14:02 |
| bac | deryck: recall we had the discussion last week to move to 1400UTC. | 14:03 |
| deryck | ah, ok | 14:03 |
| kfogel | What's our preferred term for The Entity Known Either As A "Person" Or A "Team"? Do we just say IPerson colloquially? | 14:30 |
| kfogel | deryck: ^^ | 14:32 |
| deryck | kfogel, yeah, I think IPerson, Person, or person is the common usage. | 14:32 |
| kfogel | deryck: ok | 14:33 |
| barry | gary_poster, flacoste howdy! what are your thoughts about upgrading lp:lazr.enum to 2a format? | 14:52 |
| flacoste | barry: JFDI | 14:52 |
| barry | flacoste: i like your style! | 14:52 |
| flacoste | barry: you should be able to do that by clicking a button on LP | 14:52 |
| barry | flacoste: /should/ being the operative word. it's failed for me in the past :( | 14:53 |
| * barry has his jfdi hat on today... literally | 14:53 | |
| jml | barry, if it doesn't work, let me know. | 14:53 |
| barry | jml: cool | 14:53 |
| barry | jml: button pushed | 14:53 |
| gary_poster | barry: fwiw, go, go jfdi ;-) | 14:55 |
| barry | gary_poster: rock! thumper asked me to package it for lucid, which i've done and now i want to get it into universe | 14:56 |
| gary_poster | great | 14:56 |
| barry | jml: can you check to see what's going on. the button provides no feedback but the page still shows it in 0.92 format | 15:10 |
| jml | barry, no, I can't. | 15:10 |
| barry | jml: :( | 15:10 |
| jml | barry, it shows 2a for me though | 15:11 |
| barry | jml: it must have *just* finished! yay. thanks | 15:12 |
| jml | barry, np. I'm glad it actually worked. | 15:12 |
| jml | although a little disappointed we still haven't figured out ajax for this sort of thing. | 15:13 |
| sinzui | bac: call? coffee and tea first? | 15:13 |
| bac | sinzui: i require no refreshments. give a ring when you're ready | 15:13 |
| * jml afk for lunch | 15:14 | |
| barry | jml: yeah | 15:16 |
| === salgado is now known as salgado-lunch | ||
| === flacoste is now known as flacoste_lunch | ||
| leonardr | flacoste, i'm going to write a launchpadlib branch that uses 1.0 instead of beta for the web service. i remember agreeing that changing it across the board was a better solution than having edge use devel and everything else use 1.0. (either because it's more consistent or because it's too big a change to launchpadlib to get into post-freeze lucid) | 16:00 |
| leonardr | let me know if you disagree or remember differently | 16:01 |
| jml | so | 16:13 |
| jml | the weird-ass error I was getting trying to update the ec2 image was caused by a bug in openjdk | 16:13 |
| jml | fixed by the wonderful folks at Ubuntu Server | 16:14 |
| === matsubara is now known as matsubara-lunch | ||
| === Ursinha is now known as Ursinha-lunch | ||
| === leonardr is now known as leonardr-lunch | ||
| === beuno is now known as beuno-lunch | ||
| bdmurray | what's the process for chaning a bug from qa-needstesting to qa-ok? | 16:55 |
| bigjools | just edit the tag | 16:55 |
| bdmurray | bigjools: after testing it though right? | 16:55 |
| bigjools | naw just change it :) | 16:56 |
| === salgado-lunch is now known as salgado | ||
| === flacoste_lunch is now known as flacoste | ||
| flacoste | leonardr-lunch: i don't recall that, i don't think using a frozen version on edge makes sense | 17:07 |
| === matsubara-lunch is now known as matsubara | ||
| === beuno-lunch is now known as beuno | ||
| cody-somerville | Does anybody run into this issue when running make? http://pastebin.ubuntu.com/400683/ | 17:44 |
| cody-somerville | bigjools, ^^ | 17:44 |
| bigjools | cody-somerville: first time you've run make? | 17:44 |
| cody-somerville | on this branch? possibly, yes. | 17:45 |
| bigjools | i see it sometimes | 17:45 |
| bigjools | goes away if you make again | 17:45 |
| * bigjools has to run | 17:46 | |
| bigjools | g'night all | 17:46 |
| cody-somerville | bye bye | 17:47 |
| === deryck is now known as deryck[lunch] | ||
| mrevell | G'night all | 17:59 |
| === Ursinha-lunch is now known as Ursinha | ||
| === deryck[lunch] is now known as deryck | ||
| salgado | does anybody know why/how lib/lp/archivepublisher/tests/archive-signing.txt uses lucille as its db user? | 18:21 |
| salgado | as usual, once you ask the question you find the answer: | 18:24 |
| salgado | def archivepublisherSetUp(test): | 18:24 |
| salgado | """Setup the archive publisher script tests.""" | 18:24 |
| salgado | setUp(test) | 18:24 |
| salgado | LaunchpadZopelessLayer.switchDbUser(config.archivepublisher.dbuser) | 18:24 |
| salgado | except that this function is not used anywhere. crap | 18:27 |
| salgado | lp/archivepublisher/tests/test_publisher_documentation.py has a copy of that, and this one's used. nice | 18:29 |
| gary_poster | heh | 18:36 |
| deryck | sinzui, ping | 18:41 |
| sinzui | hi deryck | 18:41 |
| deryck | sinzui, hi. there are 4 unassigned bugs on the 10.03 milestone for malone, which you added. Are these things you and registry are planning to tackle? Or was my team supposed to be looking into them? | 18:42 |
| sinzui | ah, I was looking for those 30 minutes ago | 18:43 |
| sinzui | deryck: There are 5 bugs I think | 18:44 |
| deryck | sinzui, yes. apparently I cannot count. | 18:44 |
| sinzui | deryck: Those look like the one I want to fix by creating a single page to configure bug tracking | 18:44 |
| deryck | oh, I would love that! | 18:44 |
| deryck | We have another bug that could be fixed trivial with that, too. | 18:45 |
| sinzui | deryck: I am moving them to 10.04. My teams needs to complete code configuration before we can start that. | 18:45 |
| deryck | sinzui, ok, cool. thanks for taking on this work! | 18:46 |
| deryck | bug 538053 can be fixed when that work is done, too. | 18:46 |
| mup | Bug #538053: "Enable bug tracking" link takes me to project edit form <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/538053> | 18:46 |
| sinzui | yep, that will be fixed | 18:47 |
| * sinzui has a single form and new url for that, but need a rocking bug tracker widget to make sense of expiration and remote project fields | 18:48 | |
| sinzui | deryck: I assigned all the bug tracker configuration bugs to the registry team. I think that will make it clear what we are doing | 18:56 |
| deryck | sinzui, thanks. | 18:57 |
| jml | sinzui, I'll look at it tomorrow. | 19:00 |
| mars | sinzui, ping: question for you about the <style> definition in base-layout-macros.pt | 19:00 |
| sinzui | hi mars | 19:00 |
| mars | hi sinzui | 19:00 |
| mars | sinzui, was looking at the output of bzr annotate lib/lp/app/templates/base-layout-macros.pt -r 8752.2.1 | 19:00 |
| mars | sinzui, and we pull in the 3.0 stylesheet using an @import directive. Why was that done? | 19:01 |
| sinzui | mars: that is following the beta through 2.0 rules. inheritance and overrides handled better when using that syntax | 19:02 |
| mars | sinzui, "handled better"? | 19:03 |
| sinzui | some rules are ignored using the common loading technique. That instruction was copied from the old template | 19:04 |
| === leonardr-lunch is now known as leonardr | ||
| mars | sinzui, what is the comma loading technique? | 19:04 |
| sinzui | sorry common way of using a href | 19:04 |
| mars | sinzui, so you are saying that browsers ignore some rules if one uses a <link href=""> to load the stylesheet, and that can be avoided by using an @import ? | 19:05 |
| cody-somerville | How do I run a specific unit test? | 19:07 |
| sinzui | mars: There is some historic problems using simple href when rules need to override or set context like media. The import directive also hides the style rules from older or insane browsers | 19:07 |
| mars | cody-somerville, bin/test -t the_specific_unit_test_name | 19:08 |
| sinzui | mars: The use of @import may not be as needed in 2010 as it was in 2005 | 19:08 |
| mars | cody-somerville, be prepared for it to take a bit to load up all the layers. | 19:08 |
| cody-somerville | ah | 19:09 |
| cody-somerville | holy crap | 19:09 |
| cody-somerville | my test passes | 19:09 |
| leonardr | flacoste: ok, i'll make it per-server. any other defaults? how about staging? | 19:09 |
| mars | sinzui, ok. I'm investigating IE caching, and one hypothesis for IE not caching the stylesheet is SSL+@import. So I will look into that. | 19:10 |
| mars | sinzui, the other hypothesis is that IE sucks, and because of SSL, will load the stylesheet regardless of what I tell it. | 19:10 |
| sinzui | mars: Yes, I think you are on the right trail. I do not think we will be hurt if we change our syntax now. I think we only need to verify the !important instruction | 19:11 |
| mars | sinzui, have a page that uses it? | 19:11 |
| mars | sinzui, a test case I can follow? | 19:11 |
| leonardr | flacoste, here's the rationale for making 1.0 the default on staging | 19:12 |
| leonardr | for most people, staging isn't for trying out the new web service | 19:12 |
| leonardr | it's for trying out your new application | 19:12 |
| sinzui | mars I do not have a test case, search the css for the few rules we have. They are probably color rules | 19:12 |
| leonardr | most people will want to just change the service root to switch over to production | 19:12 |
| mars | sinzui, ok, thanks for the guidance. | 19:12 |
| leonardr | if the default for edge is devel and the default for production is 1.0, everyone will have to know that when you develop against staging you need to also specify version 1.0 | 19:13 |
| flacoste | leonardr: are you sure? i would think that the common use case for using staging is to try out the app you are developping, not trying out a new application | 19:13 |
| flacoste | leonardr: which would hint at using the same default than edge | 19:13 |
| mars | sinzui, I would never have guessed as to the reason for the @import technique. browser code pain. | 19:13 |
| leonardr | when i said "trying out a new application" i meant the same thing as you meant when you said "Try out the app you are developing" | 19:14 |
| sinzui | mars: it is easier to hide css rules using @import, and IE is still broken :) | 19:14 |
| leonardr | flacoste: my basic argument is that an app should not break just because you changed root="edge" to root="lpnet" | 19:14 |
| flacoste | leonardr: it won't break | 19:14 |
| flacoste | leonardr: hmm, well it may | 19:14 |
| flacoste | if you are using features that aren't deployed | 19:15 |
| leonardr | yeah | 19:15 |
| flacoste | but that's a problem for the app developer | 19:15 |
| leonardr | sure, but why cause problems for the app developer? | 19:15 |
| flacoste | he's deploying an app for which the server service isn't production ready yet | 19:15 |
| leonardr | he wrote an app thinking that edge and production were the same | 19:15 |
| flacoste | well | 19:15 |
| flacoste | either way the app developer has trouble | 19:16 |
| flacoste | either he needs to switch to using an unfrozen API | 19:16 |
| flacoste | because he wants to use latest features | 19:16 |
| flacoste | hmm | 19:16 |
| leonardr | in that case he at least knows what's going on | 19:17 |
| flacoste | since 1.0 gets all new features eventually anyway | 19:17 |
| flacoste | unless they are backward incompatible | 19:17 |
| flacoste | it's probably safe to use 1.0 across the board | 19:17 |
| flacoste | and opt-in to using devel | 19:17 |
| leonardr | all right | 19:18 |
| deryck | kfogel, can any of your branches move to landed now? I need some room in the bugs lane. ;) | 19:18 |
| kfogel | deryck: I believe they are landed, let me just check | 19:18 |
| mars | sinzui, does this patch look sane? (4 lines changed) list-style-type:none; | 19:20 |
| mars | margin:0 !important; | 19:20 |
| mars | padding-left:0 !important; | 19:20 |
| mars | } | 19:20 |
| mars | argh | 19:20 |
| mars | sinzui, http://pastebin.ubuntu.com/400729/ | 19:20 |
| kfogel | deryck: all landed: bugs <suppressing mup> 78565, 538226, and 481324 | 19:21 |
| deryck | kfogel, thanks. | 19:21 |
| james_w | leonardr: does lib/canonical/launchpad/pagetests/webservice/xx-wadl.txt lie about using canonical/launchpad/apidoc/wadl-testrunner-devel.xml? If not, when is that file generated? | 19:28 |
| leonardr | i thought i got rid of any such claims... | 19:28 |
| james_w | oh, silly me, it's shipped in the source | 19:29 |
| james_w | I just deleted it as there doesn't seem to be an easy way of regenerating just the wadl without a full make clean | 19:29 |
| james_w | and the failure mode of that test when you remove that file is rather unhelpful | 19:29 |
| leonardr | james_w: as of this morning there should no longer be any wadl-testrunner-devel.xml | 19:30 |
| james_w | it just serves you the full development wadl, leading the doctest to print out several hundred lines of CML | 19:30 |
| james_w | XML | 19:30 |
| james_w | ah, I haven't pulled yet today | 19:31 |
| didrocks | kfogel: flacoste: I think I pinged you yesterday about merging my ssh branch, did you have some time to have a look at it so that I can release Quickly 0.4? | 19:32 |
| leonardr | james_w: you'll be happier with that test if you pull | 19:32 |
| james_w | thanks | 19:32 |
| kfogel | didrocks: I don't think I saw that, but let me look now | 19:32 |
| leonardr | james_w: if you just want to regenerate the wadl you can delete apidoc/* and make apidoc | 19:33 |
| james_w | yeah, I can now | 19:34 |
| didrocks | kfogel: https://code.edge.launchpad.net/~didrocks/launchpad/expose-sshkeys-bug-357235/+merge/20995 should do it :) | 19:34 |
| kfogel | didrocks: note I'm not a reviewer, but I can comment | 19:34 |
| didrocks | kfogel: sure, I guess the branch is quite in a good state (and if it can help to get an hack by flacoste or gmb, it will be good :)) | 19:35 |
| kfogel | didrocks: what is the change at @@ -519,8 +520,8 @@ for? It seems to be unrelated to this change. | 19:37 |
| didrocks | kfogel: right, it was when I worked with jml as he liked to have PEP compliant file and it was more than 80 character IIRC :) | 19:39 |
| kfogel | didrocks: well, phooey on jml for introducing unrelated changes, but I suppose he's far away over the water and I can't reach him :-). | 19:39 |
| didrocks | it should be in a separate commit, not sure as it's quite old now :) | 19:40 |
| flacoste | didrocks: we usually refrain from exposing DB id publically (in URL especially) could we use the keyid there instead? | 19:40 |
| kfogel | didrocks: I see you have flacoste now, I cede the floor to him as he's actually competent to review this (witness the above comment). | 19:42 |
| didrocks | flacoste: I didn't find any keyid key in the file, hence exposing the id, what should be exposed? | 19:42 |
| didrocks | kfogel: thanks in any case ;) | 19:42 |
| flacoste | didrocks: there is keyid | 19:45 |
| flacoste | didrocks: and you have IGPGKeySet.get(key_id) | 19:45 |
| flacoste | it will also make the URLs printed in the test stable | 19:46 |
| didrocks | flacoste: I'm starting my VM right now and check again on the file, one sec | 19:46 |
| james_w | didrocks: your tests don't seem to be doing as they state | 19:46 |
| flacoste | didrocks: err | 19:46 |
| james_w | didrocks: it says that the user should have no ssh keys to start with, but they have 1, then it says it is adding an ssh key and adds a GPG key | 19:46 |
| flacoste | didrocks: i'm looking at GPGKey, you are doing SSH! doh! | 19:47 |
| didrocks | flacoste: yes, it's SSH :) | 19:47 |
| james_w | plus, should the collection link be <person>/sshkeys or <person>/+ssh-keys? | 19:47 |
| flacoste | didrocks: yeah, that's fine then | 19:47 |
| flacoste | james_w: it should be sshkeys, collection field have the field name | 19:48 |
| flacoste | use the field names | 19:48 |
| flacoste | it could be renamed though | 19:48 |
| flacoste | the field could be calles ssh_keys | 19:48 |
| james_w | ok, I need to fix code-import then I think | 19:48 |
| flacoste | james_w: does it work? | 19:49 |
| james_w | yes | 19:49 |
| flacoste | hmm | 19:49 |
| flacoste | then it might not be a problem | 19:49 |
| flacoste | i recall that we have special traversal logic to look for a collectionfield | 19:49 |
| didrocks | james_w: right, I have to fix the testsuite so | 19:50 |
| james_w | oh, sorry, code_imports isn't a collection, it's a single object | 19:50 |
| james_w | <branch>/+code-import | 19:50 |
| flacoste | james_w: right | 19:54 |
| flacoste | that's different | 19:54 |
| flacoste | collection field must use the same name | 19:54 |
| flacoste | not even sure exported_as would work here | 19:54 |
| sinzui | mars: That looks good to me | 19:55 |
| flacoste | yeah, it doesn't | 19:56 |
| mars | sinzui, ok, I tried the patch, wasn't the issue. Another hypothesis: the CSS does not come from the same domain as the HTML. | 19:56 |
| * flacoste files a bug | 19:56 | |
| mars | sinzui, and the homepage is caching properly! (where everything does come from the same URL) | 19:56 |
| mars | s/URL/domain/ | 19:56 |
| mars | sinzui, in a template, how do I pull the current vhost? base-layout-macros is pulling the mainsite root domain URL right now. | 19:57 |
| mars | sinzui, looking at line 281, base-layout-macros.pt | 19:57 |
| mars | maybe I could just make the URL relative | 19:59 |
| mars | so use /+icing instead of foo.bar.com/+icing | 19:59 |
| sinzui | mars: I am confused here. when the url is relative the browser always makes the request to the same domain. | 19:59 |
| sinzui | if I load https://launchpad.net/ and am loading https://launchpad.net/+icing/style.css | 20:00 |
| mars | sinzui, looks like base-layout-macros.pt is setting up an absolute URL, not a relative URL. I might be able to change that. | 20:00 |
| sinzui | mars: I understand you caching issue when I am on the bugs vhost, but when I am on the mainsite, there the URLs are the same. | 20:02 |
| mars | sinzui, yep. Experimenting now. I'll let you know how it goes. | 20:03 |
| didrocks | james_w: so, name12 has an ssk key, do you know other users that I can put in the testsuite without one? | 20:06 |
| james_w | didrocks: you could use the factory | 20:07 |
| james_w | person = factory.makePerson(name="ssh-user") | 20:07 |
| didrocks | james_w: thanks, sounds easy to create a user :) | 20:07 |
| flacoste | didrocks: review reply sent | 20:08 |
| flacoste | didrocks: basically I suggest you use another user (no-priv) and use makeSSHKey instead of makeGPGKey in the test (and a couple of related suggestions) | 20:08 |
| didrocks | flacoste: ok, thanks, I'm fixing that | 20:08 |
| didrocks | flacoste: I'm just wondering how we can find the ssh public key id so. is it the keytext? | 20:17 |
| flacoste | didrocks: yes | 20:17 |
| didrocks | flacoste: ok, make sense :) | 20:18 |
| mars | sinzui, gary, it worked! http://www.webpagetest.org/result/100324_68A1/1/details/cached/ | 20:21 |
| gary_poster | mars, heh, awesome :-) | 20:22 |
| mars | still fishy though. Why does Mochikit refuse to die? | 20:22 |
| sinzui | because no one has time to convert the old hide/show js rules to yui... | 20:23 |
| mars | gary_poster, here is what we had before: http://www.webpagetest.org/result/100324_689B/1/details/cached/ | 20:23 |
| mars | strange strange. launchpad.js disappeared all on its own? | 20:23 |
| sinzui | mars: since no one is adding a feature to replace the rules, there is little incentive to update the callsites | 20:23 |
| gary_poster | fewer bytes, but same net time :-/ | 20:24 |
| mars | wow | 20:24 |
| mars | 40%? fewer bytes | 20:24 |
| mars | and two fewer requests. Something really fishy here. | 20:25 |
| mars | see? The request for the lp-gem 64x64 logo disappeared as well | 20:26 |
| mars | and here is what is used to look like. 10 requests, 183KB weight: http://www.webpagetest.org/result/100308_5SEE/1/details/cached/ | 20:26 |
| mars | It shaved 1.2 seconds off the load time at least. | 20:27 |
| mars | Internet Explorer is insane. It is the only rational explanation. | 20:31 |
| gary_poster | mars, you said "here is what we had before: http://www.webpagetest.org/result/100324_689B/1/details/cached/ " and then you said "here is what is used to look like. 10 requests, 183KB weight: http://www.webpagetest.org/result/100308_5SEE/1/details/cached/ " Quick clarification of what is what? | 20:36 |
| sinzui | gary_poster: ping | 20:51 |
| gary_poster | sinzui: pong, but high latency | 20:51 |
| sinzui | gary_poster: I was going to add a simple link to https://login.launchpad.net/ for users to change their password from the person+edit page. But I see the new SSO page, and I wonder if it would be better to add a "Manage your account" to the person profile page (where the Change password link was) | 20:53 |
| gary_poster | sinzui: and where would this link? We are planning to be a true openid consumer sometime this year, so if the link would be to login.launchpad.net, then that would be a problem. | 20:56 |
| sinzui | okay, we have a bigger problem then... | 20:57 |
| sinzui | gary: users do not know how to change their password. We took the link away. | 20:57 |
| mars | gary_poster, the second link, with 10 requests, was recorded at the beginning of the month. The first link you replied with has changed the <style>@import()</style> to a <link>. | 20:57 |
| gary_poster | mars: ah, cool | 20:58 |
| mars | gary_poster, so changing @import to <link> added one cache hit, seemingly without reason. Changing the <link> domain added yet another cache hit. | 20:58 |
| mars | oh, two, actually. | 20:58 |
| gary_poster | sinzui: ok how is this for a plan | 20:59 |
| mars | once again, without reason. | 20:59 |
| gary_poster | sinzui: add a simple link now. | 20:59 |
| sinzui | gary_poster: I can mark the bug as wontfix, and let chr deal the frustrated users, or we provide a link for the user to do this. maybe the answer is that we include a link from the profile page to an faq explaining that the user needs to find the login site and we do not know what that is | 20:59 |
| gary_poster | sinzui: when we switch to random openid, we sniff. if canonical, then we show the link | 21:00 |
| gary_poster | if otherwise, we link to wiki page as you describe | 21:00 |
| sinzui | gary_poster: then maybe we should always link the the faq (we already have one) and the let the user use the link from the faq | 21:00 |
| gary_poster | sinzui: ok, +1, easier | 21:01 |
| didrocks | flacoste: ok, I guess I fixed what needed to be fixed. When you have some time, if you can give it a look, it would be awesome: https://code.edge.launchpad.net/~didrocks/launchpad/expose-sshkeys-bug-357235/+merge/22067 Thanks! (just saw there is a conflict in configure.zcml now, but it's just removing the conflict tag and add the ssh exposal, if you want me to do this, feel free to ping me :)) | 21:07 |
| flacoste | didrocks: just approved it | 21:09 |
| didrocks | flacoste: sweet, thanks! | 21:09 |
| flacoste | didrocks: i'm in the middle of an update and haven't use ec2 land since last month, so i'm not reliable to land this | 21:10 |
| flacoste | didrocks: you can bribe anyone on the team to land it for you though | 21:10 |
| didrocks | flacoste: ok, I'll ping people tomorrow :) I can ping everyone on the LP team or should they be in a particular area of LP? | 21:11 |
| flacoste | didrocks: anyone | 21:14 |
| didrocks | flacoste: ok, thanks a lot :) good luck with your update! | 21:14 |
| flacoste | thanks, it's finishing downloading, i'll know how lucky i am in a few minutes | 21:15 |
| didrocks | heh | 21:15 |
| mwhudson | didrocks: i can land your branch | 21:16 |
| didrocks | mwhudson: great, do you need anything on my side? (the related bug is in the branch name) | 21:16 |
| mwhudson | didrocks: i guess i need you to push the revision that fixes the conflict | 21:17 |
| didrocks | mwhudson: sure, so I merge with ~launchpad-pqm/launchpad/devel/ right? | 21:18 |
| mwhudson | yes | 21:18 |
| mars | sinzui, fixed the JS domains: a 58% speedup overall! \o/ | 21:24 |
| mars | sinzui, http://www.webpagetest.org/result/100324_68B9/1/details/cached/ | 21:24 |
| sinzui | wow | 21:24 |
| mars | from 5.28s to 2.24s | 21:25 |
| mars | now, tea! | 21:26 |
| === salgado is now known as salgado-afk | ||
| === matsubara is now known as matsubara-afk | ||
| didrocks | mwhudson: should be ok now | 21:37 |
| mwhudson | didrocks: i don't see a new revision in the branch | 21:39 |
| didrocks | mwhudson: sorry, the push wasn't finished, my VM is slow :/ it's ok now | 21:41 |
| lifeless | is there a VM suitable for lp development around ? | 21:44 |
| rockstar | lifeless, I have one that I stealed from abentley earlier this year. | 21:46 |
| rockstar | Of course, it's 10GB, and I think that may cost you a lot if you're in a country that charges by data transfer. | 21:46 |
| rockstar | lifeless, I've been working on a script that will shoehorn rocketfuel-setup into a chroot. I've found the chroot is more helpful for what I want. | 21:47 |
| lifeless | cool | 21:48 |
| lifeless | Well, I'll roll my own VM for now, then. | 21:48 |
| * rockstar nods | 21:48 | |
| lifeless | I just got a new laptop | 21:48 |
| lifeless | which should be able to let me do the odd lp thing without excruciating pain | 21:48 |
| rockstar | lifeless, congrats! Boy or girl? Weight? Size? :) | 21:49 |
| lifeless | lenovo x201s, 8G and 128G SSD | 21:49 |
| * rockstar wonders if he can convince his wife he needs a new laptop. | 21:54 | |
| mwhudson | didrocks: argh, it seems you should have merged ~launchpad-pqm/launchpad/db-devel/ not devel :/ | 22:00 |
| didrocks | mwhudson: oh isn't what I wrote above? no pb, can uncommit, revert, remerge and push --overwrite | 22:02 |
| mwhudson | didrocks: that would be better it think, thanks | 22:05 |
| * mwhudson apologizes for launchpad's slightly bonkers development process | 22:05 | |
| didrocks | mwhudson: I'm used to strike with Launchpad when I thought about contributing. That's ok, still happy that my changes can land :) | 22:08 |
| didrocks | mwhudson: seems to be pushed :) | 22:08 |
| mars | lifeless, gary_poster and bigjools both run them. bigjools has instructions that I've been meaning to get from him. | 22:11 |
| lifeless | it would be nice if it was as simple as bzr; I don't think thats on the cards anytime soon :) | 22:12 |
| mars | lifeless, how about "lp-vmbuilder --from-branch=lp:foo" ? | 22:15 |
| mwhudson | didrocks: one last think, can you set a commit message in the merge proposal? | 22:15 |
| mwhudson | thing not think | 22:15 |
| mwhudson | (the diff looks much saner now) | 22:15 |
| mars | lifeless, that is about all you need really, isn't it? vmbuilder to do the bundling, and a script in a bazaar branch to bootstrap the process. | 22:15 |
| didrocks | mwhudson: I don't get the "set a commit message in the merge proposal". On the Launchpad merge proposal page? (don't know where to add that) | 22:16 |
| mwhudson | didrocks: just under "Tis proposal supersedes a proposal from 2010-03-10." on the merge proposal page | 22:17 |
| lifeless | mars: thats today, or as a vision of the future ? | 22:17 |
| mars | lifeless, preferably near future. bigjools and gary know how to do it, we just have to script it and share it. | 22:18 |
| didrocks | mwhudson: oh, never noticed that. sweet :) and done (short but descriptive, I guess) | 22:19 |
| mars | vm-based development was one thing the Lean training came up with as a solution to a number of developer issues. | 22:19 |
| mwhudson | didrocks: thanks! | 22:19 |
| didrocks | mwhudson: thanks to you! | 22:19 |
| lifeless | mars: so, that would be interesting, but its still a much higher barrier than bzr has, even bzr-loggerhead | 22:20 |
| mars | lifeless, yeah, true. It could be improved towards a bzr-like setup, but I think dev's need to fiddle with systems-level things like apache get in the way, too. | 22:23 |
| mars | lifeless, and adding another level of abstraction is so much easier | 22:23 |
| lifeless | mars: all problems in CS can be solved by adding a layer of abstraction, except ... | 22:24 |
| lifeless | having too many layers of abstraction | 22:24 |
| mars | :D | 22:24 |
| jelmer | lifeless: except performance problems :-P | 22:24 |
| lifeless | jelmer: sometimes they can be solved that way, othertimes they are instances of 'too many layers' ;) | 22:24 |
| jelmer | :-) | 22:25 |
| mars | sinzui, oops, my calculations were wrong. Turns out the IE improvements result in a 66% speedup. | 22:25 |
| thumper | someone want to tackle the conflict in stable -> db_devel? | 22:26 |
| mwhudson | some kind of user-local /etc/hosts file would sure help with launchpad | 22:27 |
| mars | lifeless, off the top of my head, some problems with a bzr-like setup for LP dev: It is difficult to see a path to it; Some devs need Apache, Postgres, etc.; It takes longer than just wrapping everything in a VM | 22:27 |
| mars | two problems of perception, one of technique | 22:28 |
| lifeless | mars: so, bzr devs need gcc, pyrex etc too - deps are deps. | 22:29 |
| lifeless | apache, pgsql can be privately configured as regular users - there are even [shudder] buildout recipes I think | 22:29 |
| mars | lifeless, yeah, but isolating Apache for local use by code? I think you would have to ask mwhudson how easy that would be :) | 22:30 |
| lifeless | I think the key thing I'm agitating for is not needing to alter system parameters to do tests - essentially the same isolation we'll want to do concurrent test runs anyway | 22:30 |
| lifeless | mars: its easy | 22:30 |
| mars | build recipes? wow. | 22:30 |
| lifeless | mars: isolating apache is pretty straight forward (if a little verbose). Definitely tractable, and once the code is written, its written. | 22:31 |
| mars | lifeless, I guess the question to ask then is: If the work has always been straight-forward, why haven't we done it? | 22:34 |
| lifeless | mars: people may not have considered it straight forward | 22:34 |
| lifeless | fear-of-the-unknown perhaps | 22:34 |
| mars | Got repeat-view pages times down to 3.6 seconds in China. Much better. | 22:40 |
| mars | And a bit more work can drop that to 2.6 seconds. | 22:41 |
| mars | And if we drop SSL: 1.6 seconds. | 22:42 |
| thumper | mars: can you make it faster in nz too please :) | 22:42 |
| mars | thumper, dropping SSL is your only hope! | 22:43 |
| thumper | :( | 22:43 |
| mwhudson | didrocks: your branch is away in ec2 fwiw | 22:46 |
| didrocks | mwhudson: sweet! Thanks ;-) | 22:47 |
| mars | lifeless, you wouldn't happen to know how Zope serves resources like /@@/product-logo, would you? | 22:54 |
| mars | lifeless, I'm looking to add Cache-control headers to the response | 22:54 |
| mars | lifeless, actually, nevermind. It is probably better to turn them into real image resources coming from +icing, same as every other static resource. | 22:58 |
| thumper | :( | 23:05 |
| mwhudson | oops, i need to merge _stable_ into db-devel | 23:18 |
| mwhudson | not devel | 23:18 |
| === _thumper_ is now known as thumper | ||
| mwhudson | lunch time | 23:22 |
| * thumper is installing lucid for the second time today | 23:32 | |
| thumper | holy crap | 23:32 |
| thumper | 1818M will be downloaded | 23:33 |
| thumper | onto my poor little laptop | 23:33 |
| thumper | that's what you get for having both kubuntu-desktop and ubuntu-desktop installed | 23:33 |
| * thumper goes to get some lunch while it downloads | 23:34 | |
| wgrant | So, I'm guessing that the OCR topic in #launchpad-meeting last night referred mostly to me. | 23:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!