[00:00] Yippie, build fixed! [00:00] Project db-devel build #539: FIXED in 5 hr 15 min: https://lpci.wedontsleep.org/job/db-devel/539/ [00:02] Project windmill-db-devel build #266: STILL FAILING in 2 min 0 sec: https://lpci.wedontsleep.org/job/windmill-db-devel/266/ [00:04] NCommander: SoyuzTestPublisher is deprecated in favour of the factory. [00:04] Project db-devel build #540: FAILURE in 2 min 1 sec: https://lpci.wedontsleep.org/job/db-devel/540/ [00:42] Hmm, db-devel is fairly borked. [02:38] 417 / 66 CodeImportSchedulerApplication:CodeImportSchedulerAPI [02:38] hmm [02:39] Possibly related to the network glitches last night. [02:39] Not sure if we know exactly what happened yet. [02:39] network glitches? [02:40] grrr tsearch2 indices are painful [02:40] We had unexplained high queue depth and 502s, and other rather suspicious unexplained OOPSes. There was suggestion that unknown network issues were the culprit. [02:40] thats the second time in a fortnight [02:48] 4 second queries on codeimportjob [03:01] Right, rabbit sucks. [03:01] I can't get it to start on the Jenkins build slaves [03:02] It should be happy enough as long as it can resolve its local node name. [03:02] Possibly both ways. [03:04] Project windmill-devel build #65: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-devel/65/ [03:07] Forcing the hostname to localhost: [03:07] root@localhost:~# /etc/init.d/rabbitmq-server start [03:07] Starting rabbitmq-server: FAILED - check /var/log/rabbitmq/startup_log, _err [03:07] rabbitmq-server. === Ursinha-afk is now known as Ursinha [04:10] wgrant: Did your distinct on branch of awesome land? [04:11] StevenK: Not yet reviewed by Stormers. [04:11] I thought lifeless self-reviewed his last few storm branches, TBH [04:11] Project windmill-db-devel build #267: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-db-devel/267/ [04:30] StevenK: no [04:30] StevenK: I'm not in the review group for storm [04:30] StevenK: we're running a fork because the patch for WITH is kindof stalled === almaisan-away is now known as al-maisan === cinerama_ is now known as cinerama [05:44] Bah, my evil plan of using sets isn't working [05:45] Oh? [05:46] Oh, bah! [05:46] The overrides return the DAS, but the input is the archtag [05:46] That may or may not be correct. [05:47] You'll note that publishBinaries calculates the DAS itself from the old archtag at the moment. Consider how you are going to refactor that area when you decide what you need to return from the overrides. [06:26] Project devel build #710: STILL FAILING in 5 hr 28 min: https://lpci.wedontsleep.org/job/devel/710/ [06:46] Does a feature flag's default value have to be a string? Or am I dangerously close to suggesting a full type system for feature flags? [06:47] its a string [06:47] they have not defaults [06:47] if not present in the system, you will get back None [06:47] they can be set explicitly to '' [06:47] They have not defaults? [06:48] It'd be nice if I could make more sense of the code + comments. [06:48] There's a suggestion that there are defaults. [06:49] Is the "default value" part of flag_info just documentation of what the code will assume you mean if no value is set then? [06:50] yes [06:50] default behaviour [06:50] not default value [06:50] I see. I'll drop that into the comment then. [06:50] all you need to do is [06:50] value = get_feature_flag('...') [06:51] if not value: value = '100' [06:51] try: [06:51] limit = int(value) [06:51] except ValueError: [06:51] limit = 100 [06:51] Project windmill-db-devel build #268: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-db-devel/268/ [06:51] hmm, can just drop the if not value: value = '100' from my sketch, its not needed. [06:51] lifeless: ironically, I think that is _to the letter_ what I have in my code. [06:52] Ah no, apart from the ValueError because I wasn't sure about None vs. empty string. [06:52] But variable name: check. Flag type: check. Default value: check. All as in my branch. Had you been reading it? [06:52] nope :) [06:52] Heh [06:53] By the way, I _think_ there's no firm guarantee about whether an unset value is an empty string or a None. Or at least, that seems to have been a driving consideration in how boolean checks work. [06:54] int(None) -> TypeError, in fact [06:54] An unset value is None. An empty value is '' [06:54] whereas int('') -> ValueError [06:54] Argh. [06:54] Yes [06:54] I am sorely tempted to make these things typed and build defaults into the descriptor mechanism. [06:55] (By the way, I'm adding an "int" domain) [06:56] I'd rather we didn't. [06:56] this is currently very lean; I'd hate for it to become less lean. [06:57] I'd be fine with helper functions to do 'get me an int with a default for missing or invalid of 100' [06:57] Does the default behaviour document only what the code will do if the flag is not specified? Or what the code will do if the flag is either not specified or given an empty value? [06:57] jtv: not specified [06:57] an empty value is a value [06:57] OK... FWIW: just trying to get the assumptions for my comments right, not mapping out a type system. :) === al-maisan is now known as almaisan-away [07:09] lifeless: would you concur with these documentation updates? https://dev.launchpad.net/FeatureFlags?action=diff [07:16] s/"not specified" / None [07:16] and drop the then redundant Reading the flag's value will then return None. sentence [07:17] jtv: other than that its great [07:18] I wanted to avoid implying that A Flag Has A Value, when actually the relationship is more complex. [07:19] Q: "Are you Johnny (The Fingers) Carlsted" -- A: "Who wants to know?" [07:19] Two tiny reviews, if anyone is interested: https://code.launchpad.net/~wgrant/launchpad/question-api-fixes/+merge/60465 and https://code.launchpad.net/~wgrant/launchpad/bug-348996/+merge/60612 [07:19] wgrant: I'll take the first [07:20] Thanks jtv. [07:20] lifeless: that's right, isn't it? A flag doesn't so much have a value as produce a value from the rules that apply at the moment you're reading it? [07:22] wgrant: by the way there is (was?) a fast way of testing launchpadlib, but it sort of broke down where the type system was concerned. Or rather, it became object-oriented where the WADL prefers the rigid, compiled-language-style class orientation that the world has moved away from. [07:24] jtv: the value in a particular request is a result of a lookup yes [07:24] jtv: but at any point, get_...('..') does evaluate to one and only one value [07:24] which might be None [07:25] lifeless: yes, I'm sure that's correct but I didn't want to imply something that will set the wrong expectations once things get more advanced. [07:25] Thanks lifeless, jtv. [07:25] jtv: I don't see this changing TBH [07:25] lifeless: what changing? [07:26] 'once things get more advanced.' [07:26] the only change I expect to happen vis-a-vis flags is exposing them inernally for codehosting etc to lookup [07:26] (without db access) [07:26] You misunderstand me. [07:26] I mean once the discussion of the topic gets more advanced. [07:26] oh [07:27] I'd aim for directness [07:27] I don't want to sort-of-imply that there is a simple 1:1 relationship between features and flags if you then need to overcome that misleading impression later on. [07:28] flags and values perhaps [07:28] Sorry, yes. [07:28] features and flags is a whole other discussion [07:28] I meant flags and values. === henninge is now known as henninge-bbl [07:35] lifeless: hope I didn't miss anything. Anyway, if I were to say "if the value is not specified," that would slightly confuse the matter of "a value may be specified but not apply." I'm wide open to more direct phrasings, but I like to avoid that sort of subtle accidental misdirection. [07:36] Project db-devel build #541: STILL FAILING in 5 hr 26 min: https://lpci.wedontsleep.org/job/db-devel/541/ [07:37] Project windmill-devel build #66: STILL FAILING in 1 hr 10 min: https://lpci.wedontsleep.org/job/windmill-devel/66/ [07:41] jtv: I don't think thats misdirection [07:41] implicit in any discussion of value is the flag->rules->value mapping [07:41] which should happen first [07:43] lifeless: you're right--I'm describing values right after you introduce that concept, so that's not an issue here. [07:43] wgrant: Ahhh!, now it makes sense, although I'm not seeing a test that uses the factory method [07:45] wgrant: you up for a similarly small review? https://code.launchpad.net/~jtv/launchpad/ff-780319/+merge/60731 [07:45] lifeless: I'll update it. [07:47] jtv: So the flag already exists and has a default of 100? [07:47] wgrant: well... in a branch I'm currently landing. [07:47] Sure. [07:50] jtv: Done. StevenK, could you mentor? [07:50] wgrant: ah, didn't realize you weren't fully hatched yet. Thanks though. [07:51] wgrant: Sure. [07:51] * wgrant is yet to evolve. [07:52] wgrant, jtv: Done [07:52] Thankyou sir. [07:52] Thanks both! [07:53] My comment: "I considered assimilating them, but I don't believe the display of these domain descriptions gives much of a clue so I thought it'd be nice to have just one verbose description in there. Two would have been overkill though." [07:53] Is that acceptable? [07:54] jtv: I wasn't favouring one over the other. Your reasoning is sound, too. [07:54] Thanks. [08:05] good morning from Luton airport. Good job I didn't pack razor blades, I might need to use them on my wrists. [08:06] Oh? [08:07] Luton is the armpit of the world === henninge-bbl is now known as henninge [08:22] Project windmill-devel build #67: STILL FAILING in 45 min: https://lpci.wedontsleep.org/job/windmill-devel/67/ === rvba_ is now known as rvba [08:36] good morning [08:55] Hi adeuring! [08:55] adeuring: there is the UDS session about translation sharing starting in 5. Do you mind to join? [08:56] adeuring: #ubuntu-uds-krudy [08:56] adeuring: audio at http://icecast.ubuntu.com:8000/ [09:01] Goodly morning === almaisan-away is now known as al-maisan [09:46] henninge: sorry, missed your message... [10:29] stub: can we catch up tomorrow? [10:29] lifeless: sure [10:29] cool [10:29] nn folks [10:29] sweet dreams [10:30] afternoon all [10:30] stub: https://dev.launchpad.net/ArchitectureGuide/Services#preview is coming together [10:32] * NCommander is really feeling pretty lost w.r.t. to LaunchpadObjectFactory ... [10:49] Can I do LPCONFIG=testrunner make run to load the database used by tests? I'd like to see the state of the LP database after running through my test [10:53] NCommander: the test db is reset at the end of the test [10:53] lifeless: would sticking stop() in work? [10:53] or preventing cleanup? :-/ [10:55] * NCommander was readinghttps://dev.launchpad.net/Debugging but thats mostly for page tests :-/ === al-maisan is now known as almaisan-away [11:14] NCommander: make harness PGDATABASE=launchpad_ftest_playground works. make run PGDATABASE=launchpad_ftest_playground likely works too. [11:14] stub: I managed to get it working bybreaking into PDB, then running with the same LPCONFIG environment variable used by the test [11:15] (abusing features of libpq) [11:15] * NCommander has a wonderfully generic Distroseries90786 :-) [11:16] stub: thanks though, that's handy for future refernece [11:38] lifeless: wgrant: does this look sane so far? http://paste.ubuntu.com/606461/ [11:38] (it looks correct in the webui) [11:49] Project windmill-devel build #68: STILL FAILING in 1 hr 18 min: https://lpci.wedontsleep.org/job/windmill-devel/68/ [11:53] Yay, we (Fluidinfo) can view milestone pages again. Thanks! :) [11:53] jkakar: You use projectgroup milestones? [11:54] wgrant: Yes. [11:54] wgrant: It's probably the most useful bug-related view for me in Launchpad. [11:56] Actually, I use an lp:kanban based view much more than I use milestones now... in fact, I rarely look at milestone views now. [11:56] I find project milestone views to be very handy. [11:56] But we don't use the project group much any more. [11:56] lp:kanban doesn't provide as much detail as the milestone view in some ways, like bug counts by status, milestone due date and some other bits. [11:57] Since the merge. [11:57] Yeah, makes sense. [11:57] We use milestones as a way to have a view of work we are doing (or want to do) during our 4 week iterations. [11:57] It's just about the closest thing LP has to a dashboard. [11:58] We have 5 or 6 projects in a project group, so the project group milestone view is important for us. [11:58] Right. [11:58] wgrant: Yep, exactly. [11:58] wgrant: I've thought about adding the missing details from the milestone view to lp:kanban but I try to be very careful about what gets added to the board... I want it to be as simple as possible and to avoid clutter. [11:58] NCommander: I'm not sure why you're explicitly creating ProcessorFamilies, but that looks like a good start. === henninge is now known as henninge-lunch [12:00] wgrant: That's how it was handled in some of the other examples, but I've been ripping apart things so I suspect those can die [12:00] wgrant: my next challenge is figuring out how to use NascentUpload to put files into my archive [12:00] NCommander: You don't want to use NascentUpload. [12:00] NCommander: The factory provides methods to create the objects directly. === almaisan-away is now known as al-maisan [12:01] archiveuploader is some of the oldest and least pretty code in LP. Avoid it if at all possible -- and it is completely possible here. [12:01] wgrant: don't tihnk that's going to work the way I want to because I want to have properly arch-all/any dependency info and single source/multiple binaries [12:02] NCommander: NascentUpload is Launchpad code, and it achieves that. Therefore you can do the same thing in a test. [12:02] Without the abomination. [12:02] * NCommander feels the descent into madness [12:03] NCommander: You probably want to makeBinaryPackageBuild, then use makeBinaryPackageRelease to attach your various binaries to it. [12:03] I'm thinking I need to start with a source package in there somewhere [12:04] makeBinaryPackageBuild will create a SourcePackageRelease on which to base the build. [12:04] I'm not sure you care about the source, do you? [12:04] i do [12:04] What about it do you care about? [12:04] I'm caring about dependency relationships here, which is why I want to upload actual packages [12:05] Making sure there's a way to retain the arch-any/arch-all bits when half a package gets superseede [12:05] Why do you think uploading actual packages would be better? [12:05] What does that achieve that you cannot do in Python? [12:06] It means that I can simply get the data from the package itself instead of feeding out the entire relationships in LP functions. ideally, my test case woudl actually parse the resulting binary-* files to make sure teh skew is avoided, but I've been told thats too resource intesive [12:07] End-to-end tests like that are ugly, really slow, difficult to write, difficult to read, difficult to change, unobvious, make the rest of the system inflexible, and provide negligible benefit. [12:09] wgrant: looking at the makeBinary stuff, I don't have a way to make multiple binaries off a source record sanely [12:09] * NCommander is still reading [12:10] NCommander: You can pass one BinaryPackageBuild into multiple makeBinaryPackageRelease calls. [12:10] If you say its difficult to do, I'll default to you, but I generally consider a test invalid unless it tests end to end IMHO [12:11] There need to be some end-to-end tests, but for edge cases like this they are not appropriate. [12:12] fair enough [12:12] * NCommander is not looking forward to setting up soyuz fully locally so I can manually examine the edge case [12:12] er, output [12:12] brain == goo [12:12] lunch time [12:13] NCommander: There's fairly good instructions for that now :) [12:23] Project devel build #711: STILL FAILING in 5 hr 32 min: https://lpci.wedontsleep.org/job/devel/711/ [12:34] allenap: O hai. Are you fine to OCR? [12:35] StevenK: Yes, but I have to go in a few minutes. I can do it when I get back. [12:35] allenap: https://code.launchpad.net/~stevenk/launchpad/generic-overrides/+merge/60730 when you're ready [12:36] StevenK: Cool. [12:53] autTnf-2 === mrevell is now known as mrevell-lunch [13:05] Project db-devel build #542: STILL FAILING in 5 hr 29 min: https://lpci.wedontsleep.org/job/db-devel/542/ [13:05] Project windmill-db-devel build #269: STILL FAILING in 1 hr 15 min: https://lpci.wedontsleep.org/job/windmill-db-devel/269/ [13:27] jcsackett: are you OCR today? [13:31] Project windmill-devel build #69: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-devel/69/ === mrevell-lunch is now known as mrevell === vila is now known as vila-afk [13:55] wow, I won a Macbook Air: https://bugs.launchpad.net/launchpad/+bug/1234 [13:55] <_mup_> Bug #1234: Gina is an unmaintainable mess of command line options, environment variables and shell scripts < https://launchpad.net/bugs/1234 > [13:59] Morning, all. === jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jcsackett | https://code.launchpad.net/launchpad-project/+activereviews [14:01] benji: just went on shift. :-) [14:02] jcsackett: cool, here's a small one to get warmed up: https://code.launchpad.net/~benji/launchpad/fix-generated-html/+merge/60697 [14:09] benji: r=me. shame we need the hack, but at least it's a well done hack. :-) [14:17] Project windmill-devel build #70: STILL FAILING in 45 min: https://lpci.wedontsleep.org/job/windmill-devel/70/ === vila-afk is now known as vila [14:26] allenap: are ou doing reviews today? [14:27] adeuring: Yes, I'll fix the topic. === allenap changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jcsackett, allenap | https://code.launchpad.net/launchpad-project/+activereviews [14:27] allenap: cool, I have a small mp: https://code.launchpad.net/~adeuring/launchpad/bug-739075-2/+merge/60768 could you habe a look at it? [14:28] adeuring: Okay, cool. [14:28] thanks! [14:43] allenap: thanks for your review! [14:43] adeuring: Thank you for an easy one :) === Ursinha is now known as Ursinha-afk [15:01] Project windmill-devel build #71: STILL FAILING in 44 min: https://lpci.wedontsleep.org/job/windmill-devel/71/ [15:09] gah. try to fix one critical js bug and I'm sucked into qa blackhole for subscriptions. [15:12] allenap: can you take a look at https://code.launchpad.net/~jcsackett/launchpad/spam-tech-debt/+merge/60794 ? [15:12] it's quite a bit shorter than the diff implies--mostly code deletes and replaced in one spot. [15:20] deryck: anything I can do to help? [15:20] benji, no, it's my own stupidity. thanks, though. [15:20] benji, if you see bugs against the story about the subscription overlay, it's just me cleaning up my mess. [15:20] ok :) [15:21] I'm really not trying to nosy my way into the Yellow Squad work :-) [15:24] jcsackett: Sure. [15:24] jcsackett: I'm doing a review for StevenK right now, but after that. === fjlacoste is now known as flacoste [15:25] allenap: no rush. it's just simplifying some tests. meant to get it in for review yesterday but completely forgot about it. === al-maisan is now known as almaisan-away [15:41] bigjools: hi? [15:41] poolie: hey [15:42] hi [15:42] i'm trying to fix bug 778437 [15:42] <_mup_> Bug #778437: Recipe build success sends emails, please stop doing that < https://launchpad.net/bugs/778437 > [15:42] ok [15:42] i'm trying to work out how mail gets sent after a successful sprb [15:43] there is an existing test that seems to assert that mail is not sent [15:43] in fact it is sent [15:43] ! [15:43] is the mail as a result of the upload, or the build? [15:44] SourcePackageRecipeBuild._handleStatus_OK [15:44] IYSWIM [15:44] * bigjools looking [15:44] tries to send mail on status=FULLYBUILT [15:44] however [15:45] afaics that method is only ever reached with the packgae in UPLOADING [15:45] istm the mail ought to be sent after the build not the upload [15:45] hm [15:46] no, the example on the bug shows mail is sent on the source upload too [15:48] you could remove the self.notify() in _handleStatus_OK and see what tests break [15:48] I also remember reviewing some code that sent email from the uploads [15:49] nothing breaks :) [15:49] i'd be happy to just delete it, [15:50] but it does seem like there's a gap in test coverage [15:50] and perhaps that won't actually suppress the mail [15:50] hmmm [15:50] but nothing else seems to create that mail template [15:50] the odd thing in the mail this sends is that [15:50] it says "state: successfully built" but the log file is about uploading a source pacakge [16:01] Project windmill-db-devel build #270: STILL FAILING in 45 min: https://lpci.wedontsleep.org/job/windmill-db-devel/270/ [16:04] jcsackett: allenap: Could one of you guys have a look at this MP https://code.launchpad.net/~rvb/launchpad/multi-parent-diff-pages2/+merge/60799 ? [16:04] rvba: sure. [16:04] jcsackett: thanks! [16:10] bigjools: can you give me any clus? [16:11] i'm really puzzled how that code gets hit in production [16:26] jcsackett: mumble? [16:27] Hi, general Python question. [16:27] sinzui: sure. [16:27] I have the feeling I am missing something very obvious or more pyhtonic here. This implementation looks very C-ish. [16:27] http://paste.ubuntu.com/606529/ [16:29] henninge: assuming haystack is a sequence, i think haystack.count(needle) works. [16:29] sinzui: can you hear me? [16:29] jcsackett: a string [16:29] search a string within a string [16:29] * henninge tries that [16:31] jcsackett: thank you, I was not aware of that (obviously) [16:31] henninge: yw. [17:01] Project windmill-devel build #72: STILL FAILING in 45 min: https://lpci.wedontsleep.org/job/windmill-devel/72/ [17:02] jelmer: are you still around? [17:04] poolie, hey [17:04] poolie, yep [17:06] hi, can i find you somewhere? [17:06] i think i need to update your soyuz code [17:06] I'm in Elod, or I can come find you [17:06] Where are you? [17:07] i'm upstairs, i'll work out where elod is [17:13] i guess there's a lesson that things that look trivial in soyuz, aren't [17:14] :) [17:15] I'm going to move towards the area near the front desk [17:25] jcsackett: I don't know if you need me for the review ... but FYI I'll have to EOD in ~20 min. [17:25] rvba: yeah, sorry this is taking so long--pretty big diff. i'll leave all comments on the MP. [17:26] jcsackett: sure, I know the diff is kinda big. === matsubara is now known as matsubara-lunch === deryck is now known as deryck[lunch] [18:46] sinzui: i am finally looking at your project-review MP. [18:47] \o/ [18:47] one question, i see both a license-reviewed and license-approved. shouldn't the first be a project-reviewed widget? === matsubara-lunch is now known as matsubara === deryck[lunch] is now known as deryck [18:51] sinzui ^ [18:52] jcsackett: The field is license_reviewed. We can rename the field to be project_reviewed [18:53] We changed the meaning of the field in 2008 [19:00] sinzui: ah, dig. i don't know that it's necessary, i was just somewhat confused. [19:02] Indeed. engineers think they are approving projects, when they are approving licenses (hence the errors we see when approving a proprietary and I don't know project) [19:02] sinzui: that makes sense. [19:02] r=me, sinzui. and i look forwards to seeing this deployed. :-) [19:03] jcsackett: I can change the field name do you want me to do that? [19:03] I think it is a trivial mechanical change [19:04] sinzui: actually, i think it's good as is. as you said, we're trying to prevent people thinking they're reviewing/judging the project. [19:07] jcsackett: well we do mean review_project [19:08] ah. so i was still confused. :-P [19:08] ok, then yeah, we probably should update the field, if that's not a pain. i would rather get the improved project review in place then quibble about fields tho. :-) [19:09] okay. I will make this last change ans land it. Thank you very much === Ursinha-afk is now known as Ursinha [19:10] thank you, sinzui. [19:10] i must go grab some food, and then i will look at your other branch. [19:43] Project db-devel build #543: STILL FAILING in 6 hr 37 min: https://lpci.wedontsleep.org/job/db-devel/543/ [19:44] Project devel build #712: STILL FAILING in 6 hr 38 min: https://lpci.wedontsleep.org/job/devel/712/ [19:58] * lifeless stretches [20:07] morning gary_poster [20:22] Project windmill-devel build #73: STILL FAILING in 1 hr 8 min: https://lpci.wedontsleep.org/job/windmill-devel/73/ [20:35] Project windmill-db-devel build #271: STILL FAILING in 51 min: https://lpci.wedontsleep.org/job/windmill-db-devel/271/ [20:40] * gary_poster winces at not finishing doc review for lifeless, then runs out the door, to be back soon [21:01] gary_poster: :P [21:22] allenap: hi [21:22] allenap: why is bug 776283 untestable ? [21:22] <_mup_> Bug #776283: PackageCopyJob needs separate archive and series columns for query purposes (db patch)

< https://launchpad.net/bugs/776283 > [21:22] _mup_: you are stale! [21:23] ah, I meant bug 779949 [21:23] <_mup_> Bug #779949: PackageCopyJob needs separate archive and series columns for query purposes

< https://launchpad.net/bugs/779949 > [21:23] nvm [21:27] Project windmill-db-devel build #272: STILL FAILING in 51 min: https://lpci.wedontsleep.org/job/windmill-db-devel/272/ [21:36] jcsackett or allenap: could you please review https://code.launchpad.net/~abentley/launchpad/translation-packaging-resource/+merge/60832 ? [21:49] abentley: sure. [21:51] jcsackett: thanks. [21:52] abentley: that was very to the point. r=me. [21:53] jcsackett: cool, thanks. [21:53] you get today's coveted "shortest diff" award. :-) === jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews [22:16] Project windmill-devel build #74: STILL FAILING in 49 min: https://lpci.wedontsleep.org/job/windmill-devel/74/