[00:00] bdmurray, you can override values [00:00] do you have a pastebin or something more tangible? [00:01] beuno: https://pastebin.canonical.com/36841/ unsub-icon uses an absolute position which doesn't really work for me [00:04] 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] beuno: I believe there is some magic javascript that unsub-icon has for unsubscribing from a bug. would that be lost? [00:05] bdmurray, nope, the javascript would still find that class, should be fine [00:06] well, fine if you use the second option, of course :) [00:06] overriding the specific option via CSS rather than creating a new one [00:06] beuno: great, thanks! [00:06] np [00:10] spm: here again ? [00:12] lifeless: yurs; but gettnig handover atm [00:14] when you have that done please ping me [00:15] tracking down this 10second overhead in staging. [00:15] of course, getting stating going again is a precursor === Edwin is now known as Guest66225 [01:35] 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] no [01:36] wallyworld_: just request another with UI specified [01:36] wallyworld_: there is a link 'request another review' [01:36] thumper: np, just wanted to check that i wasn't supposed to be able to just edit the current record [01:36] wallyworld_: well... kinda [01:37] wallyworld_: but not well [01:37] * thumper heading afk === poolie_ is now known as poolie [03:58] zomg Product:EntryResource:get_timeline - 2400 queries [04:05] lifeless: eh? [04:08] lp net oops summary [04:29] that's quite a lot of queries [04:46] lifeless: too late for Performance Tuesday, but you might be interested in bug 632880 [05:03] wgrant: I think it's time I updated the translation templates build stuff [05:09] jtv: To the new schema? [05:09] wgrant: yes [05:09] Yes please. [05:10] One thing that seems needed is a TranslationTemplatesBuild. [05:10] Correct. [05:11] Does that mean I can ditch TranslationTemplatesBuildJob? [05:12] You still need something like it. [05:12] For now. [05:12] Since we're still using the old queue mechanism, until you move across. [05:13] But eventually you can ditch it, yes. [05:14] But first I'll make it refer to a BuildFarmJob instead of a BuildFarmJobOld? [05:14] Or is that just a matter of removing _set_build_farm_job? [05:15] jtv: TranslationTemplatesBuildJob continues to derive from BuildFarmJobOldDerived. [05:16] You then need a new TranslationTemplatesBuild(BuildFarmJobDerived) [05:16] Yes, this sucks, but it wasn't meant to last for more than a few weeks. [05:17] sorry [05:18] Hm, Maverick's not bad. [05:19] wgrant: how will I know that I've got a working new setup, as opposed to still leaning on the old one? [05:21] jtv: At this stage you pretty much just need a BuildFarmJob, I think. [05:21] oh cool [05:22] 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] I'm not entirely sure of Soyuz plans for the next step. noodles did the work, so he might. [05:24] 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] I guess Job also drops completely out of the picture [05:26] Going to be fun cleaning up that forest of job/branchjob/buildqueue cross-references [05:26] I suppose I also need a factory for my new class. [05:26] For the moment, yes, Job is pretty much out of it. [05:27] But once it's completely out of it, most of BuildFarmJob will be replaced with a new Job reference. [05:27] whoopee [05:27] But that's easy to do without attacking BFJ users too much. [05:27] And probably better than having multiple Jobs for each BFJ, as we would if we made that change now. [05:27] Yes [05:28] I can see how it makes sense. [05:28] 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] 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] wgrant: oh, while still wanting to have them for packagebuilds? [05:30] And some were quite attached to BQ at the time. [05:30] mwhudson: Right. [05:30] So we couldn't have a persistent BuildFarmJob. [05:30] So it couldn't replace BuildQueue. [05:30] However, the objections to removing BuildQueue have now evaporated. [05:30] heh [05:30] So we can make everything a BuildFarmJob, and remove BuildQueue. [05:30] And lots of other stuff. [05:31] Which shouldn't really have been there in the first place :) [05:31] sounds a bit like taking the long way around [05:31] but if it results in deleting code, i guess i'm happy [05:32] It certainly is the very, very long way around. [05:32] But opinions now seem different from what they were in Wellington, so the new, sane structure can prevail. [05:33] heh [05:34] Let the record show that I argued violently against sanity in any shape or form. [05:34] Heh. [05:35] wgrant: where and when should I produce TranslationTemplateBuild objects? [05:35] jtv: Wherever you're producing TranslationTemplateBuildJobs now. [05:36] Produce both for the time being? [05:36] jtv: The existing builds have a makeJob method which creates the BuildQueue and *BuildJob. [05:36] Or stop producing TTBJs now? [05:36] So I should mimick that? [05:36] Ah, in fact that's on the interface. [05:36] So, yes. [05:37] OK, this sounds treacherously simple. [05:38] heya jtv, wgrant [05:38] hi spm [05:39] Hi spm. [05:40] Hm, massive downtime for the rollout... does this mean the Lucid upgrade is happening? [05:40] yup [05:40] well. more of it. [05:40] DB? [05:41] no, that'll stay on 8.3 [05:42] :( [05:51] jtv: thanks [05:51] wgrant: SPOF upgrades e.g. librarian to lucid [05:52] jtv: yes, I'd seen that; depending on caching is fragile and undesirable [05:53] lifeless: librarian really shouldn't be a SPOF. But OK. [05:53] wgrant: agreed. And yet, it is. [05:53] wgrant: there are two instances running, but one disk store and one machine. [05:53] Yay. [05:54] 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] 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] 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. === jtv is now known as jtv-eat [06:44] the main thing is to make sure you don't introduce the possibility of accidental DB access in the librarian server. [06:45] other than, sure [07:40] jelmer: In your b-m upload branch, are you deliberately not passing the buildid into the policy any more? [07:41] It should still work, but I'm a little doubtful that activating the guessing logic is a stunning idea. [07:41] I want to remove all that logic RSN, since mixed uploads are gone. [08:02] It is going to let people do some pretty damn confusing stuff if they want to. [08:03] But I don't think it actually opens up any security holes. [08:03] It also won't unset the upload log any more, but that might be done by the retry. [08:05] Well, no major security holes. [08:35] 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 [08:41] ha. landed in pqm 2 minutes later. rofl. [08:42] gmb: yeah, I've got it on the pqm queue again now (it was rejected earlier). [08:42] Ah, great :) [08:42] Still on the queue afaics. [08:45] noodles775, Cool. [08:53] good morning [08:56] Hello [09:11] bigjools: Have recipe builds been tested on DF with the build upload processor branch? [09:11] I don't see how they can work.... [09:19] wgrant: jelmer says yes [09:20] gmb: landed with r9760 [09:20] But the buildid isn't being passed in any more, AFAICS :/ [09:20] * wgrant tries. [09:20] hmmm [09:20] he made it part of the directory leaf name [09:20] Yep. [09:20] But it's not put in the upload policy. [09:25] wgrant, why would it need to be in the upload policy? [09:25] jelmer: Er, options, not policy, sorry. [09:26] jelmer: Binary and source uploads look in options.buildid to work out which build they're working on. === jtv-eat is now known as jtv [09:27] wgrant: If options.builds is set they extract the build id from the directory name, and ignore options.buildid [09:27] jelmer: Binary builds will guess which build to use, and will create one if it's not found (which users can abuse). [09:27] jelmer: Even BinaryUploadFile.findBuild? [09:27] And DSCFile.findBuild? [09:27] DSCFile.findBuild will just not do anything if it's not set. [09:27] Which should result in failedtoupload SPRBs. [09:28] (why yes, this is a completely revolting way of doing things, but that's how it is :/) [09:29] * jelmer investigates [09:29] I'm trying to test locally. [09:29] But Maverick doesn't like me too much. [09:33] some of Aarons leftover sourcerecipebuilds ran through dogfood while this branch was there [09:38] jelmer: I can't see any... are they not under his recipe? [09:44] Ermm. [09:45] I think it may be broken in other ways as well. [09:48] wgrant: How? [09:49] jelmer: It doesn't unset BuildQueue.builder when it sets the status to UPLOADING. [09:49] SO when buildd-manager comes around again, it resets it and starts building it again. [09:49] (because it thinks the builder has forgotten it) [09:49] :( [09:50] So it retries. [09:50] And then the upload is skipped, since the status isn't UPLOADING. [09:50] wgrant: Argh, I see. [09:50] Once I"ve fixed that, process-upload then crashes. [09:50] zope.security.interfaces.ForbiddenAttribute: ('date_finished', ) [09:51] That occurs in the path that's executed if the build isn't FULLYBUILT at the end. [09:51] Which means that it is indeed finding the build properly. [09:51] So, 3 issues: [09:51] 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] 1) b-m needs to dequeue the build somehow, to prevent forgotten build handling from kicking in. [09:52] 2) processBuildUpload needs to set options.buildid, or something to that effect. [09:53] 3) processBuildUpload's date_finished setting falls afoul of security for SPRBs. [09:53] The first two are fatal. [09:53] The third is probably not absolutely critical. [09:54] Um, s/indeed finding/indeed not finding/ a few lines ago. [09:54] noodles775, Thanks (Sorry, completely missed your ping) [09:56] Once I fix date_finished, it fails with a DB perm error when trying to read sourcepackagerecipe to send a failure notification. [09:57] And then it can't delete the SPRBJ. [10:00] Also... what about the upload log? [10:00] That doesn't exist any more. [10:36] 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 [10:37] 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] (not just SPRBs, but OK) [10:38] jelmer, Okay. Realistically, then, is it going to make the PQM deadline (~13:00 UTC)? [10:39] gmb: I doubt it will. :-/ [10:40] 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] 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] 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] (Or rather the bug it fixes is not a blocker) [10:46] 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] jelmer, Okay, thanks. [10:47] 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] jelmer, I'll let you know. [10:47] gmb: Thanks. [10:47] No re-roll freeze this time? Awesome. [10:47] wgrant, Hopefully. We'll see. [10:48] Heh. [11:33] wgrant: spot the oddness: http://pastebin.ubuntu.com/490282/ [11:34] bigjools: superseded by nothing? [11:35] superseded by itself? [11:35] it's gcalctool [11:35] yes to both of those [11:35] and it build in maverick, yet appears in lucid [11:35] built* [11:35] superseded by itself is reasonable. [11:35] Happens on overrides. [11:35] or double-copies. [11:36] we have terrible auditing of these actions :( [11:36] we do. [11:36] But it's normally possible to work out exactly what happened. [11:36] What's the problem here? [11:36] It just looks like someone copied it from Maverick primary to a Lucid PPA, twice. [11:37] I am trying to delete the sparc/ia64 BPRs built in maverick, but they're in lucid too [11:37] a ha ha. [11:37] ah balls, I didn't spot the archive difference [11:39] I hate this data model sometimes [11:39] Howso? [11:39] Apart from making it hard to do evil things like deleting DASes. [11:40] 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

[11:42] 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 [11:42] gmb: didn't we go over this yesterday? [11:42] jtv, Er. Don't think so. [11:43] wgrant: it's not been designed as much as evolved and it makes it too hard to do anything [11:43] Maybe we did and I've forgotten. [11:43] Ah, that was deryck perhaps. [11:43] gmb: anyway, yes, it's either qa-ok or qa-untestable depending on your pov [11:43] wgrant: my main beef is the strife when writing apparently simple queries to get info [11:43] and the lack of auditing [11:43] gmb: if the tests pass, that is the only QA that applies. [11:43] jtv, Call it -ok then. The test suite didn't blow up. [11:43] OK [11:43] I call that a win [11:43] :) [11:44] done [11:44] 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] gmb: sorry, wrong bug. [11:45] gmb: yes, that's fine. [11:45] noodles775, Okay. I'll change it. Thanks. [11:45] noodles775, while I have you: I finally followed up on your review. With apologies for the delay. [11:47] 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] noodles775: no worries [11:47] 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 [11:47] jtv: great, thanks. [11:48] gmb: no, seb's problem is about uploading attachments, while this bug is about accessing existing attachment [11:49] 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] If you don't have time, I'll find someone else for it, it's just that you're here :) [11:49] gmb: no i can do that [11:49] adeuring, Excellent, thanks. [11:55] bigjools: don't you have queries from the hppa/lpia removals? [11:55] only the ones where we set the status to deleted [11:55] Huh. [11:56] but later we had to delete with extreme prejudice because of arch-any uploads [11:56] arch-all, you mean? [11:56] arch-any should be dealt with by the chroot removal. [11:56] maybe, I aways get them confused :/ [11:56] Heh, everyone does. [11:57] 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] basically yes [11:58] * bigjools books another flight to Dallas and sighs heavily [12:00] gmb: the fix for the bug seems to be good [12:01] adeuring, Awesome, thanks [12:01] bigjools, Another flight? How many times are you going? [12:01] Morning, all. [12:01] gmb: once was enough, and now we have to go again [12:02] bigjools, Ah, as in you're booking for t'Epic. [12:05] gmb: yarp [12:06] we need to stop calling it that [12:06] Yes. [12:06] the original 2 week one was *the* epic [12:07] Indeed. [12:07] * gmb wanders off to get some vittles [12:59] \0/ We can has staging! === matsubara-afk is now known as matsubara [13:24] 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] gmb, one is done, one needs both well working staging and perhaps a bit of LOSA help [13:27] henninge, can you qa-ok 597539 please? :) [13:28] ah, there is a working staging now ... [13:28] danilos, henninge: But no working LOSA for another 30 minutes :) [13:28] But thanks anyway; please let me know as soon as everything's qa'd [13:30] LMAO [13:30] * gmb just noticed the Rosetta 10.09 release name. [13:30] ;-) [13:32] It's only fitting seeing Launchpad's release name ... [13:34] \0/ 30 minutes out from the PQM deadline, no branches in the queue and the builds are GREEN. Win. [13:37] 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] bac, is there a process to apply as a UI reviewer for LP? [13:41] salgado: rockstar is the defacto UI reviewer go-to guy. so i'd just ask him and get a mentor [13:42] bac, cool, thanks [13:43] rockstar, so, how do I get a mentor? :) [13:50] danilos: Here is the new code in action: https://translations.edge.launchpad.net/deluge/1.2/+pots/deluge/de/7/+translate [13:50] danilos: compare that with the production version. The external suggestion comes from a different po file. [13:52] henninge, right, I see that, but I am not sure what are you trying to tell me? :) [13:52] ;-) [13:52] Just to see that the new code is working (and not breaking) .... [13:53] danilos: nm, continue what you were doing [13:53] henninge, heh, I already trusted you on that, but thanks :) [13:54] I just thought it was neat to see it at work. [13:58] danilos: just saw this [13:58] https://translations.launchpad.net/bitlord/trunk/+pots/bitlord/de/37/+translate [13:58] not related to my branch as it is on production [13:58] danilos: two "Used in" statements for the same template ... [13:58] argh, nm [13:58] different series [13:59] danilos: but on edge ... :( [13:59] danilos: two "Used in" statements for the same pofile... [14:01] 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] henninge, suggestions code has never been nicely updated for message sharing, so it's just a bunch of hacks [14:03] that's reassuring [14:05] danilos: ah yes, it is diverged: [14:05] https://translations.edge.launchpad.net/deluge/1.1/+pots/deluge/de/+translate?batch=10&show=all&search=Invalid+label === almaisan-away is now known as al-maisan [14:06] 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] danilos: also, we still have a sequence number problem ... the magnifiying glass takes you to messge 21 ... [14:07] I thought that was fixed a year ago or so [14:07] 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] :-) [14:07] henninge, no, we couldn't fix it properly because of the navigation [14:36] gmb: yes, if the new code hits staging we can QA it ourselves. [14:37] noodles775, Okay, I'll try and get it pushed out ASAP. Waiting for a losa now. [14:50] bac, I won't be attending the reviewer's meeting today. [14:51] mars: ok, we'll miss you [15:01] abentley, adeuring, bac, danilo, sinzui, deryck, EdwinGrubbs, flacoste, gary, gmb, henninge, jelmer, jtv, bigjools, leonard, mars, noodles775 [15:01] : reviewer meeting starts now [15:54] noodles775, Staging is up-to-date and restarting now. [15:56] Thanks gmb [16:01] gmb: staging is still showing r9755? [16:01] gmb: ah, but from Chex's comment it is really 9760? [16:02] noodles775: yes. I pulled down 9760, a cowboy, if you will, and restarted [16:03] Thanks Chex [16:03] noodles775: sure [16:04] We should add "But YMMV" after the revno on staging. [16:04] :) === Ursinha is now known as Ursinha-lunch [16:35] benji, pign [16:35] *ping, even [16:36] gmb: 'sup? [16:39] 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

[16:39] 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 [16:40] _mup_, shush. [16:40] 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] benji, Is that a blocker for the rollout, or is it something we can easily fix with a CP? [16:41] I don't see why it would block a rollout; nothing is any worse off than production is currently. [16:41] benji, Okay, thanks. [16:42] np [16:42] thank you benji, gmb [16:42] benji, So yes, for now just mark it qa-bad and we'll proceed as-is. === matsubara is now known as matsubara-lunch [16:52] 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 [16:52] oh [16:52] sorry for misreading [16:54] 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 [16:56] 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

[17:00] gary, i can do it, but i think mars would do it faster [17:01] gmb: Sorry, I haven't gotten to that yet - staging was down last evening; I can have look this evening instead. [17:01] ack leonardr. I'll revisit in a few to see what mars' reply is [17:01] 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] (Though the final decision is at 21:00 UTC) [17:02] 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] gmb: that's ok, it shouldn't take long [17:04] jelmer, Cool, thanks. [17:04] I'm just trying to keep day job and community work separate a bit [17:05] * jelmer puts on his community hat [17:11] jelmer, Thanks. Your willingness to put to one side your millinery separatism is appreciated. [17:11] hah, there's my dictionary word of the day [17:12] ha === beuno is now known as beuno-lunch [17:12] we also appreciate your perspicacity [17:15] Technically it's a noun, not an adjective, but let's adjectify it for the purposes of this discussion. [17:32] jelmer, Thanks for QAing that for me. [17:33] gary_poster, leonardr: I think mars is unavailable; can one of you guys take care of that last outstanding needstesting item please? [17:34] leonardr: please do it then, sorry. EIther that or you can try to guide me in doing it. === salgado is now known as salgado-lunch [17:35] gary, sure, np [17:35] thank you. gmb ^^^ [17:36] gary_poster, leonardr: Thanks. [17:36] leonardr, Please ping me when you're done. === al-maisan is now known as almaisan-away === matsubara-lunch is now known as matsubara [17:54] gmb, verified [17:55]