[00:00] <beuno> bdmurray, you can override values
[00:00] <beuno> do you have a pastebin or something more tangible?
[00:01] <bdmurray> beuno: https://pastebin.canonical.com/36841/ unsub-icon uses an absolute position which doesn't really work for me
[00:04] <beuno> bdmurray, so you can either create a new class and use that, or add an id in that td, and create a new css entry that does something like:  #new-id .unsub-icon {position:relative;}
[00:05] <bdmurray> beuno: I believe there is some magic javascript that unsub-icon has for unsubscribing from a bug.  would that be lost?
[00:05] <beuno> bdmurray, nope, the javascript would still find that class, should be fine
[00:06] <beuno> well, fine if you use the second option, of course  :)
[00:06] <beuno> overriding the specific option via CSS rather than creating a new one
[00:06] <bdmurray> beuno: great, thanks!
[00:06] <beuno> np
[00:10] <lifeless> spm: here again ?
[00:12] <spm> lifeless: yurs; but gettnig handover atm
[00:14] <lifeless> when you have that done please ping me
[00:15] <lifeless> tracking down this 10second overhead in staging.
[00:15] <lifeless> of course, getting stating going again is a precursor
[01:35] <wallyworld_> thumper: afaict, the only way to change a review type is to delete and re-create the merge proposal? resubmitting doesn't allow review type to be edited
[01:35] <thumper> no
[01:36] <thumper> wallyworld_: just request another with UI specified
[01:36] <thumper> wallyworld_: there is a link 'request another review'
[01:36] <wallyworld_> thumper: np, just wanted to check that i wasn't supposed to be able to just edit the current record
[01:36] <thumper> wallyworld_: well... kinda
[01:37] <thumper> wallyworld_: but not well
[01:37]  * thumper heading afk
[03:58] <lifeless> zomg Product:EntryResource:get_timeline - 2400 queries
[04:05] <thumper> lifeless: eh?
[04:08] <lifeless> lp net oops summary
[04:29] <mwhudson> that's quite a lot of queries
[04:46] <jtv> lifeless: too late for Performance Tuesday, but you might be interested in bug 632880
[05:03] <jtv> wgrant: I think it's time I updated the translation templates build stuff
[05:09] <wgrant> jtv: To the new schema?
[05:09] <jtv> wgrant: yes
[05:09] <wgrant> Yes please.
[05:10] <jtv> One thing that seems needed is a TranslationTemplatesBuild.
[05:10] <wgrant> Correct.
[05:11] <jtv> Does that mean I can ditch TranslationTemplatesBuildJob?
[05:12] <wgrant> You still need something like it.
[05:12] <wgrant> For now.
[05:12] <wgrant> Since we're still using the old queue mechanism, until you move across.
[05:13] <wgrant> But eventually you can ditch it, yes.
[05:14] <jtv> But first I'll make it refer to a BuildFarmJob instead of a BuildFarmJobOld?
[05:14] <jtv> Or is that just a matter of  removing _set_build_farm_job?
[05:15] <wgrant> jtv: TranslationTemplatesBuildJob continues to derive from BuildFarmJobOldDerived.
[05:16] <wgrant> You then need a new TranslationTemplatesBuild(BuildFarmJobDerived)
[05:16] <wgrant> Yes, this sucks, but it wasn't meant to last for more than a few weeks.
[05:17] <jtv> sorry
[05:18] <wgrant> Hm, Maverick's not bad.
[05:19] <jtv> wgrant: how will I know that I've got a working new setup, as opposed to still leaning on the old one?
[05:21] <wgrant> jtv: At this stage you pretty much just need a BuildFarmJob, I think.
[05:21] <jtv> oh cool
[05:22] <wgrant> Then we can migrate the queueing stuff to that, and dismantle the other infrastructure.... and work out what else needs to be moved before we can do that.
[05:22] <wgrant> I'm not entirely sure of Soyuz plans for the next step. noodles did the work, so he might.
[05:24] <wgrant> But the important thing now is that we get all jobs into BuildFarmJob, so we can kill off BuildQueue. Then we no longer need the BQ<->build link objects like TTBJ, SPRBJ and BPJ, and we can destroy them at our leisure.
[05:25] <jtv> I guess Job also drops completely out of the picture
[05:26] <jtv> Going to be fun cleaning up that forest of job/branchjob/buildqueue cross-references
[05:26] <jtv> I suppose I also need a factory for my new class.
[05:26] <wgrant> For the moment, yes, Job is pretty much out of it.
[05:27] <wgrant> But once it's completely out of it, most of BuildFarmJob will be replaced with a new Job reference.
[05:27] <jtv> whoopee
[05:27] <wgrant> But that's easy to do without attacking BFJ users too much.
[05:27] <wgrant> And probably better than having multiple Jobs for each BFJ, as we would if we made that change now.
[05:27] <jtv> Yes
[05:28] <jtv> I can see how it makes sense.
[05:28] <mwhudson> wgrant: how did we end up in the position of needing to kill off BQ now, rather than when we changed everything else?
[05:30] <wgrant> mwhudson: I don't recall exactly. But I think it partly stemmed from not wanting to have persistent objects for some job types (Translations, in particular).
[05:30] <mwhudson> wgrant: oh, while still wanting to have them for packagebuilds?
[05:30] <wgrant> And some were quite attached to BQ at the time.
[05:30] <wgrant> mwhudson: Right.
[05:30] <wgrant> So we couldn't have a persistent BuildFarmJob.
[05:30] <wgrant> So it couldn't replace BuildQueue.
[05:30] <wgrant> However, the objections to removing BuildQueue have now evaporated.
[05:30] <mwhudson> heh
[05:30] <wgrant> So we can make everything a BuildFarmJob, and remove BuildQueue.
[05:30] <wgrant> And lots of other stuff.
[05:31] <wgrant> Which shouldn't really have been there in the first place :)
[05:31] <mwhudson> sounds a bit like taking the long way around
[05:31] <mwhudson> but if it results in deleting code, i guess i'm happy
[05:32] <wgrant> It certainly is the very, very long way around.
[05:32] <wgrant> But opinions now seem different from what they were in Wellington, so the new, sane structure can prevail.
[05:33] <mwhudson> heh
[05:34] <jtv> Let the record show that I argued violently against sanity in any shape or form.
[05:34] <wgrant> Heh.
[05:35] <jtv> wgrant: where and when should I produce TranslationTemplateBuild objects?
[05:35] <wgrant> jtv: Wherever you're producing TranslationTemplateBuildJobs now.
[05:36] <jtv> Produce both for the time being?
[05:36] <wgrant> jtv: The existing builds have a makeJob method which creates the BuildQueue and *BuildJob.
[05:36] <jtv> Or stop producing TTBJs now?
[05:36] <jtv> So I should mimick that?
[05:36] <wgrant> Ah, in fact that's on the interface.
[05:36] <wgrant> So, yes.
[05:37] <jtv> OK, this sounds treacherously simple.
[05:38] <spm> heya jtv, wgrant
[05:38] <jtv> hi spm
[05:39] <wgrant> Hi spm.
[05:40] <wgrant> Hm, massive downtime for the rollout... does this mean the Lucid upgrade is happening?
[05:40] <spm> yup
[05:40] <spm> well. more of it.
[05:40] <wgrant> DB?
[05:41] <spm> no, that'll stay on 8.3
[05:42] <wgrant> :(
[05:51] <lifeless> jtv: thanks
[05:51] <lifeless> wgrant: SPOF upgrades e.g. librarian to lucid
[05:52] <lifeless> jtv: yes, I'd seen that; depending on caching is fragile and undesirable
[05:53] <wgrant> lifeless: librarian really shouldn't be a SPOF. But OK.
[05:53] <lifeless> wgrant: agreed. And yet, it is.
[05:53] <lifeless> wgrant: there are two instances running, but one disk store and one machine.
[05:53] <wgrant> Yay.
[05:54] <jtv> lifeless, re caching: true, though I can't think of anything better we have at the moment…  but would you agree that what I suggest is an improvement?
[05:55] <jtv> There seems to be a pattern in the librarian of dealing with LibraryFileAlias ids where it should probably deal with LibraryFileAlias objects instead.
[05:58] <jtv> Maybe in some cases that could let us avoid querying the objects, in which case it's not necessarily bad.  But again that sort of optimization will be fragile.
[06:44] <lifeless> the main thing is to make sure you don't introduce the possibility of accidental DB access in the librarian server.
[06:45] <lifeless> other than, sure
[07:40] <wgrant> jelmer: In your b-m upload branch, are you deliberately not passing the buildid into the policy any more?
[07:41] <wgrant> It should still work, but I'm a little doubtful that activating the guessing logic is a stunning idea.
[07:41] <wgrant> I want to remove all that logic RSN, since mixed uploads are gone.
[08:02] <wgrant> It is going to let people do some pretty damn confusing stuff if they want to.
[08:03] <wgrant> But I don't think it actually opens up any security holes.
[08:03] <wgrant> It also won't unset the upload log any more, but that might be done by the retry.
[08:05] <wgrant> Well, no major security holes.
[08:35] <gmb> noodles775, Morning. What's the story with your branch for https://bugs.edge.launchpad.net/soyuz/+bug/611568? Can you get it into PQM before 12:00 UTC do you think?
[08:35] <_mup_> Bug #611568: Suppress email notification for SCA P3A subscriptions <software-center> <trivial> <Soyuz:In Progress by michael.nelson> <https://launchpad.net/bugs/611568>
[08:41] <spm> ha. landed in pqm 2 minutes later. rofl.
[08:42] <noodles775> gmb: yeah, I've got it on the pqm queue again now (it was rejected earlier).
[08:42] <noodles775> Ah, great :)
[08:42] <noodles775> Still on the queue afaics.
[08:45] <gmb> noodles775, Cool.
[08:53] <adeuring> good morning
[08:56] <mrevell> Hello
[09:11] <wgrant> bigjools: Have recipe builds been tested on DF with the build upload processor branch?
[09:11] <wgrant> I don't see how they can work....
[09:19] <bigjools> wgrant: jelmer says yes
[09:20] <noodles775> gmb: landed with r9760
[09:20] <wgrant> But the buildid isn't being passed in any more, AFAICS :/
[09:20]  * wgrant tries.
[09:20] <bigjools> hmmm
[09:20] <bigjools> he made it part of the directory leaf name
[09:20] <wgrant> Yep.
[09:20] <wgrant> But it's not put in the upload policy.
[09:25] <jelmer> wgrant, why would it need to be in the upload policy?
[09:25] <wgrant> jelmer: Er, options, not policy, sorry.
[09:26] <wgrant> jelmer: Binary and source uploads look in options.buildid to work out which build they're working on.
[09:27] <jelmer> wgrant: If options.builds is set they extract the build id from the directory name, and ignore options.buildid
[09:27] <wgrant> jelmer: Binary builds will guess which build to use, and will create one if it's not found (which users can abuse).
[09:27] <wgrant> jelmer: Even BinaryUploadFile.findBuild?
[09:27] <wgrant> And DSCFile.findBuild?
[09:27] <wgrant> DSCFile.findBuild will just not do anything if it's not set.
[09:27] <wgrant> Which should result in failedtoupload SPRBs.
[09:28] <wgrant> (why yes, this is a completely revolting way of doing things, but that's how it is :/)
[09:29]  * jelmer investigates
[09:29] <wgrant> I'm trying to test locally.
[09:29] <wgrant> But Maverick doesn't like me too much.
[09:33] <jelmer> some of Aarons leftover sourcerecipebuilds ran through dogfood while this branch was there
[09:38] <wgrant> jelmer: I can't see any... are they not under his recipe?
[09:44] <wgrant> Ermm.
[09:45] <wgrant> I think it may be broken in other ways as well.
[09:48] <jelmer> wgrant: How?
[09:49] <wgrant> jelmer: It doesn't unset BuildQueue.builder when it sets the status to UPLOADING.
[09:49] <wgrant> SO when buildd-manager comes around again, it resets it and starts building it again.
[09:49] <wgrant> (because it thinks the builder has forgotten it)
[09:49] <bigjools> :(
[09:50] <wgrant> So it retries.
[09:50] <wgrant> And then the upload is skipped, since the status isn't UPLOADING.
[09:50] <jelmer> wgrant: Argh, I see.
[09:50] <wgrant> Once I"ve fixed that, process-upload then crashes.
[09:50] <wgrant> zope.security.interfaces.ForbiddenAttribute: ('date_finished', <lp.code.model.sourcepackagerecipebuild.SourcePackageRecipeBuild object at 0xa2d720c>)
[09:51] <wgrant> That occurs in the path that's executed if the build isn't FULLYBUILT at the end.
[09:51] <wgrant> Which means that it is indeed finding the build properly.
[09:51] <wgrant> So, 3 issues:
[09:51] <jelmer> wgrant: I think I know what broke it :-/ I Made some changes friday after tests came back and moved the destroying of the buildqueue record from buildmaster to uploadprocessor.
[09:52] <wgrant>  1) b-m needs to dequeue the build somehow, to prevent forgotten build handling from kicking in.
[09:52] <wgrant>  2) processBuildUpload needs to set options.buildid, or something to that effect.
[09:53] <wgrant>  3) processBuildUpload's date_finished setting falls afoul of security for SPRBs.
[09:53] <wgrant> The first two are fatal.
[09:53] <wgrant> The third is probably not absolutely critical.
[09:54] <wgrant> Um, s/indeed finding/indeed not finding/ a few lines ago.
[09:54] <gmb> noodles775, Thanks (Sorry, completely missed your ping)
[09:56] <wgrant> Once I fix date_finished, it fails with a DB perm error when trying to read sourcepackagerecipe to send a failure notification.
[09:57] <wgrant> And then it can't delete the SPRBJ.
[10:00] <wgrant> Also... what about the upload log?
[10:00] <wgrant> That doesn't exist any more.
[10:36] <gmb> jelmer, What's the situation with your https://bugs.edge.launchpad.net/soyuz/+bug/506256 branch? I know I rc'd it yesterday, but that m-p has disappeared. Does that mean that you're not oging to try and land it before release?
[10:36] <_mup_> Bug #506256: Remove Popen from buildstatus_OK <buildfarm> <Soyuz:Triaged by jelmer> <https://launchpad.net/bugs/506256>
[10:37] <jelmer> gmb: It's gone through ec2 successfully last night but wgrant has pointed out some issues with it wrt sourcepackagerecipebuilds that I'm currently investigating
[10:37] <wgrant> (not just SPRBs, but OK)
[10:38] <gmb> jelmer, Okay. Realistically, then, is it going to make the PQM deadline (~13:00 UTC)?
[10:39] <jelmer> gmb: I doubt it will. :-/
[10:40] <gmb> jelmer, Hmm. How critical is it that it gets rolled out tomorrow morning? Can it wait to be CP'd or re-rolled?
[10:43] <jelmer> gmb: The branch itself or the issues wgrant has found? The issues are definitely blockers for landing it; it should be possible to CP it.
[10:43] <gmb> jelmer, So, just to be absolutely clear: The branch itself is not a rollout blocker per se and can be CP'd instead, yes?
[10:43] <gmb> (Or rather the bug it fixes is not a blocker)
[10:46] <jelmer> gmb: Yes, the bug it fixes is not a blocker though it should land sooner rather than later because it should significantly speed up the builddmanager.
[10:46] <gmb> jelmer, Okay, thanks.
[10:47] <gmb> jelmer, We'll hopefully open PQM up once we've determined which revision to roll out, so you should be able to land this later and then request a CP for it.
[10:47] <gmb> jelmer, I'll let you know.
[10:47] <jelmer> gmb: Thanks.
[10:47] <wgrant> No re-roll freeze this time? Awesome.
[10:47] <gmb> wgrant, Hopefully. We'll see.
[10:48] <wgrant> Heh.
[11:33] <bigjools> wgrant: spot the oddness: http://pastebin.ubuntu.com/490282/
[11:34] <wgrant> bigjools: superseded by nothing?
[11:35] <mwhudson> superseded by itself?
[11:35] <bigjools> it's gcalctool
[11:35] <bigjools> yes to both of those
[11:35] <bigjools> and it build in maverick, yet appears in lucid
[11:35] <bigjools> built*
[11:35] <wgrant> superseded by itself is reasonable.
[11:35] <wgrant> Happens on overrides.
[11:35] <wgrant> or double-copies.
[11:36] <bigjools> we have terrible auditing of these actions :(
[11:36] <wgrant> we do.
[11:36] <wgrant> But it's normally possible to work out exactly what happened.
[11:36] <wgrant> What's the problem here?
[11:36] <wgrant> It just looks like someone copied it from Maverick primary to a Lucid PPA, twice.
[11:37] <bigjools> I am trying to delete the sparc/ia64 BPRs built in maverick, but they're in lucid too
[11:37] <wgrant> a ha ha.
[11:37] <bigjools> ah balls, I didn't spot the archive difference
[11:39] <bigjools> I hate this data model sometimes
[11:39] <wgrant> Howso?
[11:39] <wgrant> Apart from making it hard to do evil things like deleting DASes.
[11:40] <gmb> noodles775, Since https://bugs.edge.launchpad.net/launchpad-foundations/+bug/217644 is on edge and nothing appears to be broken, can it be marked qa-ok?
[11:40] <_mup_> Bug #217644: ResultSet aggregates do not respect distinct option <qa-needstesting> <tech-debt> <Launchpad Foundations:Fix Committed by michael.nelson> <Storm:Fix Released by jamesh> <https://launchpad.net/bugs/217644>
[11:42] <gmb> jtv, Can https://bugs.edge.launchpad.net/launchpad-foundations/+bug/629442 be marked qa-ok since it's a test-suite only thing?
[11:42] <_mup_> Bug #629442: FakeLibrarian: create returns alias.id instead of alias <qa-needstesting> <Launchpad Foundations:Fix Committed by jtv> <https://launchpad.net/bugs/629442>
[11:42] <jtv> gmb: didn't we go over this yesterday?
[11:42] <gmb> jtv, Er. Don't think so.
[11:43] <bigjools> wgrant: it's not been designed as much as evolved and it makes it too hard to do anything
[11:43] <gmb> Maybe we did and I've forgotten.
[11:43] <jtv> Ah, that was deryck perhaps.
[11:43] <jtv> gmb: anyway, yes, it's either qa-ok or qa-untestable depending on your pov
[11:43] <bigjools> wgrant: my main beef is the strife when writing apparently simple queries to get info
[11:43] <bigjools> and the lack of auditing
[11:43] <jtv> gmb: if the tests pass, that is the only QA that applies.
[11:43] <gmb> jtv, Call it -ok then. The test suite didn't blow up.
[11:43] <jtv> OK
[11:43] <gmb> I call that a win
[11:43] <jtv> :)
[11:44] <jtv> done
[11:44] <noodles775> gmb: Sure, I think its safe to mark qa-ok, but we could QA it on staging if/when its ready if necessary.
[11:45] <noodles775> gmb: sorry, wrong bug.
[11:45] <noodles775> gmb: yes, that's fine.
[11:45] <gmb> noodles775, Okay. I'll change it. Thanks.
[11:45] <jtv> noodles775, while I have you: I finally followed up on your review.  With apologies for the delay.
[11:47] <noodles775> jtv: yes, I saw... I was hoping I could leave it for tomorrow when I'm OCR if it's not urgent... is that OK with you?
[11:47] <jtv> noodles775: no worries
[11:47] <gmb> adeuring, I'm looking at https://bugs.edge.launchpad.net/malone/+bug/618849 and whilst it's on edge, ISTR you talking with seb yesterday about timeouts when accessing attachments. Is that anything to do with this bug, do you think?
[11:47] <_mup_> Bug #618849: Timeout accessing bugs' attachments using the API <qa-needstesting> <timeout> <Launchpad Bugs:Fix Committed by lifeless> <https://launchpad.net/bugs/618849>
[11:47] <noodles775> jtv: great, thanks.
[11:48] <adeuring> gmb: no, seb's problem is about uploading attachments, while this bug is about accessing existing attachment
[11:49] <gmb> adeuring, Okay, thanks. Do you think you might be able to take the time to QA that bug against edge (since staging's down)?
[11:49] <gmb> If you don't have time, I'll find someone else for it, it's just that you're here :)
[11:49] <adeuring> gmb: no i can do that
[11:49] <gmb> adeuring, Excellent, thanks.
[11:55] <wgrant> bigjools: don't you have queries from the hppa/lpia removals?
[11:55] <bigjools> only the ones where we set the status to deleted
[11:55] <wgrant> Huh.
[11:56] <bigjools> but later we had to delete with extreme prejudice because of arch-any uploads
[11:56] <wgrant> arch-all, you mean?
[11:56] <wgrant> arch-any should be dealt with by the chroot removal.
[11:56] <bigjools> maybe, I aways get them confused :/
[11:56] <wgrant> Heh, everyone does.
[11:57] <wgrant> So you Delete them, wait for p-dr to kick them out of the archive, DELETE them, then remove the dists tree etc.?
[11:57] <bigjools> basically yes
[11:58]  * bigjools books another flight to Dallas and sighs heavily
[12:00] <adeuring> gmb: the fix for the bug seems to be good
[12:01] <gmb> adeuring, Awesome, thanks
[12:01] <gmb> bigjools, Another flight? How many times are you going?
[12:01] <deryck> Morning, all.
[12:01] <bigjools> gmb: once was enough, and now we have to go again
[12:02] <gmb> bigjools, Ah, as in you're booking for t'Epic.
[12:05] <bigjools> gmb: yarp
[12:06] <bigjools> we need to stop calling it that
[12:06] <gmb> Yes.
[12:06] <bigjools>  the original 2 week one was *the* epic
[12:07] <gmb> Indeed.
[12:07]  * gmb wanders off to get some vittles
[12:59] <gmb> \0/ We can has staging!
[13:24] <gmb> danilos, henninge, I see 2 items still qa-needstesting on Translations. Do they both need LOSA attention? https://bugs.edge.launchpad.net/rosetta/+bugs?field.tag=qa-needstesting
[13:27] <danilos> gmb, one is done, one needs both well working staging and perhaps a bit of LOSA help
[13:27] <danilos> henninge, can you qa-ok 597539 please? :)
[13:28] <henninge> ah, there is a working staging now ...
[13:28] <gmb> danilos, henninge: But no working LOSA for another 30 minutes :)
[13:28] <gmb> But thanks anyway; please let me know as soon as everything's qa'd
[13:30] <gmb> LMAO
[13:30]  * gmb just noticed the Rosetta 10.09 release name.
[13:30] <henninge> ;-)
[13:32] <henninge> It's only fitting seeing Launchpad's release name ...
[13:34] <gmb> \0/ 30 minutes out from the PQM deadline, no branches in the queue and the builds are GREEN. Win.
[13:37] <gmb> noodles775, What will it take to QA your branch now that it's landed? Push the new code to staging, bounce the appserver and then have a LOSA help you poke it?
[13:41] <salgado> bac, is there a process to apply as a UI reviewer for LP?
[13:41] <bac> salgado: rockstar is the defacto UI reviewer go-to guy.  so i'd just ask him and get a mentor
[13:42] <salgado> bac, cool, thanks
[13:43] <salgado> rockstar, so, how do I get a mentor? :)
[13:50] <henninge> danilos: Here is the new code in action: https://translations.edge.launchpad.net/deluge/1.2/+pots/deluge/de/7/+translate
[13:50] <henninge> danilos: compare that with the production version. The external suggestion comes from a different po file.
[13:52] <danilos> henninge, right, I see that, but I am not sure what are you trying to tell me? :)
[13:52] <henninge> ;-)
[13:52] <henninge> Just to see that the new code is working (and not breaking) ....
[13:53] <henninge> danilos: nm, continue what you were doing
[13:53] <danilos> henninge, heh, I already trusted you on that, but thanks :)
[13:54] <henninge> I just thought it was neat to see it at work.
[13:58] <henninge> danilos: just saw this
[13:58] <henninge> https://translations.launchpad.net/bitlord/trunk/+pots/bitlord/de/37/+translate
[13:58] <henninge> not related to my branch as it is on production
[13:58] <henninge> danilos: two "Used in" statements for the same template ...
[13:58] <henninge> argh, nm
[13:58] <henninge> different series
[13:59] <henninge> danilos: but on edge ... :(
[13:59] <henninge> danilos: two "Used in" statements for the same pofile...
[14:01] <danilos> henninge, right, that could be due to is_current flags set and divergences or is_imported messages (they are all listed as just "used in")
[14:01] <danilos> henninge, suggestions code has never been nicely updated for message sharing, so it's just a bunch of hacks
[14:03] <henninge> that's reassuring
[14:05] <henninge> danilos: ah yes, it is diverged:
[14:05] <henninge> https://translations.edge.launchpad.net/deluge/1.1/+pots/deluge/de/+translate?batch=10&show=all&search=Invalid+label
[14:06] <danilos> henninge, yeah, it's not reassuring, but that's why we really need to fix up all the crap that +translate page is behind the scenes :)
[14:06] <henninge> danilos: also, we still have a sequence number problem ... the magnifiying glass takes you to messge 21 ...
[14:07] <henninge> I thought that was fixed a year ago or so
[14:07] <danilos> henninge, yes, we do, we've never fixed it (oh, I think I mentioned how I planned to fix that with the +translate page rework)
[14:07] <henninge> :-)
[14:07] <danilos> henninge, no, we couldn't fix it properly because of the navigation
[14:36] <noodles775> gmb: yes, if the new code hits staging we can QA it ourselves.
[14:37] <gmb> noodles775, Okay, I'll try and get it pushed out ASAP. Waiting for a losa now.
[14:50] <mars> bac, I won't be attending the reviewer's meeting today.
[14:51] <bac> mars: ok, we'll miss you
[15:01] <bac> abentley, adeuring, bac, danilo, sinzui, deryck, EdwinGrubbs, flacoste, gary, gmb, henninge, jelmer, jtv, bigjools, leonard, mars, noodles775
[15:01] <bac> : reviewer meeting starts now
[15:54] <gmb> noodles775, Staging is up-to-date and restarting now.
[15:56] <noodles775> Thanks gmb
[16:01] <noodles775> gmb: staging is still showing r9755?
[16:01] <noodles775> gmb: ah, but from Chex's comment it is really 9760?
[16:02] <Chex> noodles775: yes. I pulled down 9760, a cowboy, if you will, and restarted
[16:03] <noodles775> Thanks Chex
[16:03] <Chex> noodles775: sure
[16:04] <gmb> We should add "But YMMV" after the revno on staging.
[16:04] <noodles775> :)
[16:35] <gmb> benji, pign
[16:35] <gmb> *ping, even
[16:36] <benji> gmb: 'sup?
[16:39] <gmb> benji, https://bugs.edge.launchpad.net/launchpad-foundations/+bug/597324 is assigned to you and is tagged qa-needstesting. Can you take care of QA'ing it please?
[16:39] <_mup_> Bug #597324: Login fails when logging in while accessing URL with query parameters  <openid> <qa-needstesting> <Launchpad Foundations:Fix Committed by benji> <https://launchpad.net/bugs/597324>
[16:39] <gmb> gary_poster, What's the situation with QA for https://bugs.edge.launchpad.net/launchpad-foundations/+bug/308198?
[16:39] <_mup_> Bug #308198: Javascript library doesn't wrap entries within collections <qa-needstesting> <Launchpad Foundations:Fix Committed by foxxtrot> <https://launchpad.net/bugs/308198>
[16:40] <gmb> _mup_, shush.
[16:40] <benji> gmb: I'm working on it a the moment; unfortunately I'm working on it because it's broken (I suppose I should set it to qa-bad, doing that now)
[16:41] <gmb> benji, Is that a blocker for the rollout, or is it something we can easily fix with a CP?
[16:41] <benji> I don't see why it would block a rollout; nothing is any worse off than production is currently.
[16:41] <gmb> benji, Okay, thanks.
[16:42] <benji> np
[16:42] <gary_poster> thank you benji, gmb
[16:42] <gmb> benji, So yes, for now just mark it qa-bad and we'll proceed as-is.
[16:52] <gmb> gary_poster, https://bugs.edge.launchpad.net/launchpad-foundations/+bug/308198 still needs QA; I don't think benji was referring to that one.
[16:52] <_mup_> Bug #308198: Javascript library doesn't wrap entries within collections <qa-needstesting> <Launchpad Foundations:Fix Committed by foxxtrot> <https://launchpad.net/bugs/308198>
[16:52] <gary_poster> oh
[16:52] <gary_poster> sorry for misreading
[16:54] <gary_poster> mars, leonardr, do you all have any idea how to QA the community fix for bug 308198?  (I ask Leonard because he filed it, and mars because he Knows About These Things.)
[16:54] <_mup_> Bug #308198: Javascript library doesn't wrap entries within collections <qa-needstesting> <Launchpad Foundations:Fix Committed by foxxtrot> <https://launchpad.net/bugs/308198>
[16:56] <gmb> Sorry if you've answered this already jelmer, E_TOO_MANY_CHANNELS, but what's the situation with QA on https://bugs.edge.launchpad.net/launchpad-code/+bug/599397?
[16:56] <_mup_> Bug #599397: code imports break when tdb is installed <code-import> <qa-needstesting> <Bazaar Hg Plugin:Triaged> <Launchpad Bazaar Integration:Fix Committed by jelmer> <https://launchpad.net/bugs/599397>
[17:00] <leonardr> gary, i can do it, but i think mars would do it faster
[17:01] <jelmer> gmb: Sorry, I haven't gotten to that yet - staging was down last evening; I can have look this evening instead.
[17:01] <gary_poster> ack leonardr.  I'll revisit in a few to see what mars' reply is
[17:01] <gmb> jelmer, The sooner the better; I'd like to be able to say for sure that we're good to go with the current db-stable revision before I EOD if possible.
[17:01] <gmb> (Though the final decision is at 21:00 UTC)
[17:02] <gmb> jelmer, If you don't have time to do it nowabouts it's no problem; I'll ask someone else to take care of it.
[17:04] <jelmer> gmb: that's ok, it shouldn't take long
[17:04] <gmb> jelmer, Cool, thanks.
[17:04] <jelmer> I'm just trying to keep day job and community work separate a bit
[17:05]  * jelmer puts on his community hat
[17:11] <gmb> jelmer, Thanks. Your willingness to put to one side your millinery separatism is appreciated.
[17:11] <jelmer> hah, there's my dictionary word of the day
[17:12] <bigjools> ha
[17:12] <bigjools> we also appreciate your perspicacity
[17:15] <gmb> Technically it's a noun, not an adjective, but let's adjectify it for the purposes of this discussion.
[17:32] <gmb> jelmer, Thanks for QAing that for me.
[17:33] <gmb> gary_poster, leonardr: I think mars is unavailable; can one of you guys take care of that last outstanding needstesting item please?
[17:34] <gary_poster> leonardr: please do it then, sorry.  EIther that or you can try to guide me in doing it.
[17:35] <leonardr> gary, sure, np
[17:35] <gary_poster> thank you.  gmb ^^^
[17:36] <gmb> gary_poster, leonardr: Thanks.
[17:36] <gmb> leonardr, Please ping me when you're done.
[17:54] <leonardr> gmb, verified
[17:55] <leonardr> gary, if you're curious, here's what i did, from firebug. (it took me a while to remember the javascript stuff)
[17:55] <leonardr> client = new LP.client.Launchpad()
[17:55] <gmb> leonardr, Fab, thanks
[17:55] <gary_poster> thanks, leonardr, looking
[17:55] <leonardr> var people = null;
[17:55] <leonardr> set_people = function(arg) { people=arg; }
[17:56] <leonardr> client.get("/people", {on: {success: set_people}})
[17:56] <leonardr> then i inspected people.entries[0] and made sure it was a 'entry' type object with lp_save etc.
[17:58] <gary_poster> gotcha, leonardr.  I'm inclined to put it up on the wiki, for myself and other LP devs in the future.  Is there something like that already to your knowledge?
[17:58] <leonardr> gary: no, something like 'ajax tips'?
[17:58] <gary_poster> yeah
[17:59] <gary_poster> 'cause that is kind of like being able to mess around with launchpadlib, albeit in a kind of cramped style
[18:00] <leonardr> maybe it could go on some existing ajax page? i'm starting to realize that wikis are more useful to me if they have fewer, larger pages
[18:01] <gary_poster> I don't know where one is.  I'm putting it on the existing Foundations/Webservice page for now.
[18:01] <gary_poster> feel free to adjust
[18:01] <leonardr> ok, that's good too
[19:17] <lifeless> gary_poster: hi
[19:17] <lifeless> gary_poster: on templates & template engines
[19:17] <gary_poster> yes, lifeless
[19:18] <lifeless> gary_poster: I've heard (unmeasured) claims that our current engine is really poor :) - chameleon is better, but, is there a -really good- engine out there?
[19:18] <lifeless> gary_poster: e.g. one where the template processing won't show on our profiles at all
[19:19] <lifeless> as a for instance, rather than compiling to python, one could compile to CPython (hey, if we're going to compile, may as well do it all the way).
[19:20] <lifeless> gary_poster: if there isn't, this might be a challenge to offer the zope community :)
[19:20] <lifeless> losa ping - status on staging please
[19:26] <gary_poster> lifeless, summary: chameleon is the current best there is, and it is good.  Details follow.
[19:26] <gary_poster> I did measurements last year.  I no longer have them, but they were based on ab-style testing of representative pages, rather than actual semi-production usage (e.g., playing back requests). it gave 10 to 20% better overall improvement on the server in my tests (I summarize as "15%" usually).
[19:26] <gary_poster> It uses current "state of the art" for this sort of thing (it compiles to Python byte code, FBOW), and the project claims that it "performs 10-15 times better than the reference implementation" (http://pypi.python.org/pypi/Chameleon).  I think the Zope community would say that a request for a fast template engine is answered.
[19:26] <gary_poster> In my attempt to wrassle with the code, I'd say compilation is not optimized at all, but that's at build time; and rendering seems very nicely optimized.
[19:26] <gary_poster> I spoke briefly to the author of Chameleon about a month ago and he was interested in another version of the engine, but I think that's mad scientist talk ATM.
[19:27] <lifeless> ok
[19:27] <lifeless> for clarity, here's my thoughts on templating:
[19:28] <lifeless>  - tal is ok, but not madly tied to it; if tals definition makes execution slow...
[19:28] <gary_poster> (ab-style: apache bench, not marketing/usability-ab.)
[19:28] <lifeless>  - engine agnostic : transparent/fast/decent memory footprint/fixable when we need to  - these matter to me
[19:29] <gary_poster> tal: it doesn't, especially with Chameleon.  Moreover, if we are interested in mucking about with our template engine, that's what Chameleon is built for.
[19:29] <lifeless>  - sample use case : render a 7000 row table with 15 columns in subsecond time.
[19:29] <gary_poster> (so, for instance, the default Chameleon template interpretation defaults to python syntax, rather than path syntax)
[19:29] <lifeless>    [on our appserver hardware, when 4 threads are doing template rendering at the same time]
[19:30] <lifeless>    [-> 250ms template time to do that]
[19:30] <gary_poster> fast: the claims are that this is close to state of the art, as I said
[19:30] <lifeless> sure; I'm not dissing chameleon
[19:30] <gary_poster> nor did I think you were
[19:30] <lifeless> :)
[19:31] <gary_poster> just trying to clarify my position on your bullet points as you go
[19:31] <gary_poster> maybe unnecessary
[19:31] <lifeless> my points are done, I think.
[19:32] <gary_poster> transparent/decent memory footprint: we'll see.  We are supposed to be able to switch back and forth between reference implementation and chameleon implementation very easily--an env var for make.
[19:32] <lifeless> oh, and once we have data, if this is a speed driver, we should, I think, invest in driving an implementation to where we need
[19:32] <gary_poster> fixable: I'm very interested in that one.  We'll see there too. sidnei has significant experience with this package
[19:33] <gary_poster> byte code generation starts from a bad place for that :-)
[19:33] <gary_poster> but there appear to be debugging hooks.  I don't understand them yet
[19:33] <gary_poster> the code generating the byte code is pretty clean, AFAICT so far
[19:34] <gary_poster> sample use case: dunno.  we can come up with an artificial test to try to get data.
[19:34] <lifeless> there are benchmarks already
[19:34] <lifeless> of course
[19:35] <lifeless> gary_poster: oh, and did I file the bug asking for a repeat construct with a 'did not iterate' code path?
[19:36] <gary_poster> benchmarks: sure.  I suspect if we asked the author about it, or maybe sidnei, he would be able to give us stats.  They are probably on the web somewhere in a blog in fact, but a quick google search did not show.
[19:37] <lifeless> http://blog.penzilla.net/2010/02/python-template-language-performance.html
[19:37] <lifeless> didn't say what the reference test looked like :P
[19:37] <gary_poster> heh
[19:39] <gary_poster> bug for repeat construct: not that I know of, but that's the kind of thing we should be able to do with Chameleon.
[19:39] <lifeless> I'll file a bug on foundations now
[19:39] <gary_poster> we should be able to change tal:content="cache: foo bar" to tal:cache="foo bar" also
[19:39] <lifeless> this will remove some COUNT()s that we don't need
[19:39] <gary_poster> ok
[19:44] <lifeless> https://bugs.edge.launchpad.net/launchpad-foundations/+bug/633429
[19:44] <_mup_> Bug #633429: repeat/not-iterated construct <Launchpad Foundations:New> <https://launchpad.net/bugs/633429>
[19:44] <gary_poster> ok thanks
[19:44] <lifeless> this will make a huge difference to some pages
[19:45] <lifeless> as well as lowering our DB usage more
[19:45] <gary_poster> ok cool
[19:45] <rockstar> salgado, did you end up getting a UI mentor?
[19:46] <salgado> rockstar, yes, sinzui
[19:46] <rockstar> salgado, hurrah!
[19:48] <salgado> rockstar, now I guess I just have to wait for people to ask me for UI reviews?
[19:49] <rockstar> salgado, yes.  henninge hasn't been too busy, but he's had some UI reviews recently.
[19:50] <salgado> rockstar, cool.  are there any guidelines I should read before I start?  I've seen UI/Reviews already
[19:51] <rockstar> salgado, I don't think so.  I feel like UI reviews are less about "review" and more about enforcing people to stop and think about UI, and have a discussion.
[20:25] <cr3> leonardr: in lazr.restful, is there a list of everything that gets exported which is looked up with looking for /api/1.0/foo for example?
[20:26] <leonardr> cr3: yes, everything exported is described in the wadl file. it's a kind of site map
[20:26] <leonardr> for launchpad, you can also see it in human-readable form at /+apidoc
[20:27] <cr3> leonardr: is there a way to hook into lazr.restful to extend the wadl file dynamically?
[20:27] <leonardr> cr3: no, it onyl contains what lazr.restful knows about
[20:27] <cr3> leonardr: for example, when I call an unknown method, I'd like to the webapp to do something depending on the method
[20:29] <cr3> leonardr: I think I see what you mean, the decision is being made client side whether a method exists or not, right?
[20:30] <cr3> that would certainly explain why I'm not seeing a log entry when calling an unknown method on the server side
[20:35] <leonardr> cr3: right
[20:35] <leonardr> unknown methods don't go through--they're not part of the published interface
[20:35] <leonardr> if there are specific methods handled by something other than lazr.restful, i could see adding a hook into the wadl for them, but that's al ittle odd
[20:35] <cr3> leonardr: gotcha, thanks!
[20:35] <cr3> leonardr: I'll try to live with it for now :)
[20:36] <leonardr> ok
[20:50] <lifeless> morning y'all
[20:51] <jelmer> hellow
[20:52] <tyarusso> What on earth...rocketfuel-setup just installed firefox.
[20:53] <tyarusso> Them's some strange dependencies ya got there.
[20:53] <lifeless> used by the test suite
[20:53] <beuno> windmill, etc
[20:53] <tyarusso> lifeless: ah.
[20:54] <lifeless> rocketfuel-setup sets up development environments
[22:46] <dobey> +recipes has quotas now?
[22:49] <jelmer> dobey: Do you mean the max 5 per distroseries per person per day one?
[22:49] <dobey> i guess so, yes.
[22:50] <dobey> You have exceeded your quota for recipe ubuntuone-hackers/client-dailies for distroseries ubuntu maverick
[22:54] <wallyworld_> morning
[22:55] <jelmer> dobey: I think that's always been there, you probably just hadn't hit it before :-)
[22:55] <jelmer> 'morning wallyworld_
[22:56] <dobey> jelmer: it's not documented on the +recipe page or the help page?
[22:59] <jelmer> dobey: You're right, it probably should be.
[23:01] <wgrant> What is the quota's purpose?
[23:01] <wgrant> Nothing else on Launchpad has a quota like that.
[23:01] <dobey> ppas have quotas
[23:01] <dobey> for space anyway
[23:01] <wgrant> Yes, but they're not arbitrary.
[23:07] <dobey> well it certainly makes it harder to debug software that uses the feature :)
[23:07] <dobey> anyway, time for me to go
[23:39] <wallyworld_> rockstar: ok, i can get you one in 15 mins