[00:03] wgrant: mumble? [00:10] wallyworld: bug 707234 [00:10] <_mup_> Bug #707234: Ajax controls disabled on bugs with many tasks due to multiple redundant copies of person picker make_picker function in view-source:https://bugs.launchpad.net/launchpad-project/+bugs?advanced=1

< https://launchpad.net/bugs/707234 > [00:17] wallyworld: jcsackett: StevenK: http://www.markshuttleworth.com/wp-content/uploads/2008/12/link-blueprint_web-version2.swf https://devpad.canonical.com/~beuno/ui_movies/Search%20Packages.1.swf https://devpad.canonical.com/~beuno/ui_movies/Subscribe_create_team_3.swf [00:39] wgrant: ^ [00:40] * wallyworld off to bank to try and get working credit card [00:41] Hah [00:41] poolie: Hi. [00:41] * StevenK attempts to work out when his SSL certificates expired. [00:42] StevenK: Going back to Friday, was DSP the only extra perm required? [00:43] Project windmill-devel build #215: STILL FAILING in 1 hr 13 min: https://lpci.wedontsleep.org/job/windmill-devel/215/ [00:44] wgrant: It seemed to be, yes. [00:44] * wgrant qa-oks [00:50] abentley: Hi. [00:51] abentley: It the 500 on some error cases the only reason bug #776449 is qa-bad? [00:51] <_mup_> Bug #776449: Set Ubuntu dependencies for PPA via API

< https://launchpad.net/bugs/776449 > [00:53] Project parallel-test build #33: STILL FAILING in 1 hr 11 min: https://lpci.wedontsleep.org/job/parallel-test/33/ [01:18] Morning paduans [01:21] Morning jtv. [01:22] hi1 [01:27] Aherm. [01:27] The new picker has a bug. [01:27] Everyone seems to have all IRC nicks. [01:27] I guess the preloading is buggy. [01:28] nicks_by_person = dict((nick.personID, nicks) [01:28] for nick in nicks) [01:28] Oops. [01:29] haha [02:02] Project windmill-db-devel build #387: STILL FAILING in 1 hr 18 min: https://lpci.wedontsleep.org/job/windmill-db-devel/387/ [02:04] Yippie, build fixed! [02:04] Project db-devel build #632: FIXED in 5 hr 53 min: https://lpci.wedontsleep.org/job/db-devel/632/ [02:06] wgrant: what's the problem with the nicks? [02:07] wallyworld: The preloading preloads all of the found nicks into everyone that is found to have a nick. [02:07] So if the batch has two people with nicks, both of them will have all of the nicks. [02:08] Project windmill-devel build #216: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-devel/216/ [02:08] Bug #796889 [02:08] <_mup_> Bug #796889: ValidPersonOrTeamVocabulary preloads all IRC nicks into everybody < https://launchpad.net/bugs/796889 > [02:08] i can't see how? the lines you refer to above set up a dict used by the lines that follow to preload the cache [02:08] wallyworld: (nick.personID, nicks) [02:09] wallyworld: It creates a dict mapping each nick's person to the whole set of nicks. [02:09] ah. shit. [02:09] Heh [02:09] that should be *nuck* [02:09] nick [02:09] without the s [02:09] That won't quite work either. [02:09] Since that will only allow one for each. [02:10] yep. can't argue there. [02:10] something was in the coolaid that day :-( [03:04] Project devel build #801: FAILURE in 5 hr 24 min: https://lpci.wedontsleep.org/job/devel/801/ [03:12] wgrant: yes. [03:13] abentley: Great, thanks. [03:35] hi wgrant, all [03:35] poolie: Hi. Was going to check with you on QA for your librarian email fix, but I think I did it. [03:47] you think you did the qa? [03:48] Yes. [03:48] thanks! [03:48] +filebug seems pretty screwed [03:48] https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1991BA20 [03:48] cannot get throuh at all [03:50] Erk. [03:51] BugSummaryJournal contention. [03:51] lifeless: Have you seen that before? [03:52] A timeout on a BSJ INSERT during a BugTask INSERT. [03:52] (but +filebug worked fine for me earlier) [03:53] But there's no UNIQUE :/ [03:53] Must be a table lock somewhere... [03:54] that's like ~20 failures over 20 minutes [03:54] unless this is just me, i think it's whatevers-above-critical [03:57] It's not just you, and it's not just Ubuntu. [03:57] lifeless: Do you know what was cowboyed? [03:58] lifeless: BugSummaryJournal is somewhat stuck. [03:59] wgrant: how do you mean? [03:59] lifeless: We are seeing dozens of timeouts inserting into BugSummaryJournal. [03:59] wgrant: all of bsj was cowbowed [03:59] lifeless: All *what*? [03:59] Is it exactly what was landed? [03:59] wgrant: except the appserver code to query (read only, always) when doing tag portlets [04:00] the schema, triggers [04:00] 202 timeouts of this kind in the last two hours. [04:00] Three hours. [04:01] thats a problem [04:01] we've done the ndt now right ? [04:01] It doesn't seem to be done yet. [04:01] did this start before the ndt ? [04:01] Ah, the appservers have updated in the last 5 minutes. [04:01] They were not updated when the problem started. [04:01] Let me find the first occurrence. [04:02] There were none yesterday, it seems. [04:02] ok [04:03] chaenomeles/2011-06-14/05755.AR6:Date: 2011-06-14T01:35:55.028700+00:00 [04:03] First occurrence. [04:03] oops id ? [04:04] It's in the path [04:04] AR6 [04:04] Today. [04:04] To OOPS-1991AR6 [04:04] s/To/So [05:05] Project parallel-test build #34: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/parallel-test/34/ [05:12] Does someone feel like reviewing https://code.launchpad.net/~wgrant/launchpad/bug-796889/+merge/64490? [05:14] wgrant: Nice work, r=me [05:17] Thanks. === Ursula is now known as Ursinha [05:34] Project windmill-db-devel build #388: STILL FAILING in 1 hr 5 min: https://lpci.wedontsleep.org/job/windmill-db-devel/388/ === wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 204 - 0:[######=_]:256 [06:13] Project windmill-devel build #217: STILL FAILING in 1 hr 8 min: https://lpci.wedontsleep.org/job/windmill-devel/217/ [06:22] Looks like codeimports have almost caught up. [06:22] And the failure counts are still small. [06:22] This is nice. [06:58] Project windmill-devel build #218: STILL FAILING in 44 min: https://lpci.wedontsleep.org/job/windmill-devel/218/ [07:08] We need a faster test suite. === michaelh1 is now known as michaelh1|away [07:23] wgrant: I'm amazed that that picker passed qa with those seqscans [07:24] can I run my own launchpad in ec2 and talk to it? Purely for testing applications that use launchpad data where I don't want to mess up real launchpad. [07:24] nigelb: ec2 demo [07:24] StevenK: there's a script? [07:25] that may be broken, but yeah thats the idea [07:25] lifeless: I knew it was slow, but decided it might just be qas. And it was behind flags and didn't time out too much. [07:25] or you can mess up qastaging as much as you like [07:25] nigelb: You could also use a local instance, or staging or qastaging. [07:25] nigelb: Sure, bin/ec2 demo from a local branch that is pushed [07:25] wgrant: rule 34: its never just [qa]staging [07:25] lifeless: Sure, but given it was behind flags I decided not to investigate. [07:25] wgrant: I want to set it up so that developers working on the community projects can mess up with the same install. [07:25] oh, I missed that. cool. [07:25] wgrant: nice work teal [07:26] nigelb: *Expensive* [07:26] nigelb: Like, hellishy [07:26] StevenK: Oh. :( [07:26] StevenK: Lp takes a ton of ram? [07:26] ram/cpu cycles [07:26] lifeless: ValidPersonOrTeamVocabulary has three variants now. [07:27] nigelb: We run the LP test suite on c1.xlarge instances. $300+ a month [07:28] Oh :| [07:28] nigelb: I'd point developers at qastaging, personally [07:28] StevenK: I asked jml about that at UDS. [07:28] StevenK: basically, we want to mess up with sprints, which we don't have permissions for. [07:29] And since staging and qastaging data is cleared every few weeks, we'll need to keep asking for permissions in either of them [07:29] staging is every week [07:30] qastaging is ... an interesting question [07:31] I use my own launchpad. I was just wondering if I can run a common install. Apparently not :) [07:31] *launchpad instance [07:31] nigelb: You can, for a few hours [07:31] After that, it gets expensive [07:32] wgrant: 3? [07:32] I guess its just easier to run your own launchpad instance. [07:32] nigelb: That $300+ figure is running an instance in ec2 for the entire month [07:32] nigelb: huh, sprints - create a custom project of your own [07:32] nigelb: on qastaging [07:32] nigelb: then you can fiddle with sprints for it to your hearts content [07:32] lifeless: The affiliation rank stuff is under a second flag, in case we wanted to deploy the other improvements while tweaking this. [07:32] \o/ [07:33] lifeless: Of course the affiliation stuff is fine, it's the rest that's buggy :P [07:35] lifeless: thanks. doh. why didn't I think of this. [07:36] nigelb: so you can run one on ec2 if you really want, though if its public acccess you'd need to rebrand it :( - but yeah, qastaging should meet your needs Just Fine [07:37] lifeless: Oh rebranding. I don't event want to go there, too painful :-) [07:38] wgrant: Up for reviewing a short branch of mine? [07:38] StevenK: Sure. [07:39] Ah, diff there already. [07:39] Handy. [07:39] Sorry, was just linking a bug. [07:40] StevenK: I'm not sure we really want to link to that page. === lifeless changed the topic of #launchpad-dev to: Performance Tuesday ! | https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 204 - 0:[######=_]:256 [07:40] It's pretty crap. [07:40] Particularly for private PPAs, where the technical details section is a bunch of lies. === lifeless changed the topic of #launchpad-dev to: Performance Tuesday ! | https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 202 - 0:[######=_]:256 [07:41] StevenK: We could possibly link to it from +archivesubcriptions. [07:41] lifeless: Huh, where'd those two go? [07:41] wgrant: http://webnumbr.com/launchpad-critical-bugs is what I'm tracking [07:41] Oh. [07:41] Excludes private ones. [07:41] Right. [07:41] yes [07:41] gone [07:42] wgrant: It was the only good solution that occured, and it sucks. [07:43] Bah, no creampie I guess [07:43] erm [07:43] cream pie on the face. [07:44] StevenK: I don't think it's beneficial. [07:44] Do you? [07:45] I don't think the e-mail is beneficial at all, but sladen obviously thinks it adds value. [07:45] A lot of people think that a lot of things add value. [07:57] Project windmill-devel build #219: STILL FAILING in 41 min: https://lpci.wedontsleep.org/job/windmill-devel/219/ [08:00] wgrant: Hi William, I've got an MP that really could use your Soyuz expertise ... could you review it? (If you cannot do it I'll grab someone else ;)) [08:00] https://code.launchpad.net/~rvb/launchpad/init-series-bug-789091-devel/+merge/63676 [08:00] Wow that is large. [08:01] Hmmm, so we now have 'sequence', 'ordering' and 'priority' as different names for the same concept :/ [08:01] rvba: But this MP still doesn't address the second use-case for IDS? [08:02] StevenK: wgrant that's right, the second use case is in a second branch (almost ready) [08:02] StevenK: https://code.launchpad.net/~rvb/launchpad/init-series-bug-789091-previous-series/+merge/64414 [08:03] "will be *derived* from the previous_series' parents." [08:03] StevenK: and the UI fix for the second use case is in a third branch. [08:03] That makes me very nervous. [08:03] It *should* be derived from previous_series. Only. [08:04] StevenK: you're right, it is only the doc that is wrong. [08:08] wgrant: I confess this branch has been a real work for me, so don't hesitate to recommend any fixing you'd like to see. It's a big branch so if you agree to review it, I'd be happy to follow your advices to fix it, even if they are plenty ;) [08:09] rvba: I am reading it. [08:09] wgrant: thanks a lot. [08:09] rvb: "In result, in case the same package exists in multiple parents, the package from the first parent with this package is the one that will end up in the derived series." [08:10] rvba: That's different from the rest of the behaviour. [08:10] Where the highest version tends to win. [08:10] At least for overlays. [08:10] I don't know how it behaves for non-overlays. [08:11] wgrant: right, Julian says it was good enough for now and we could fix this later if we need to .... but that's a good point ... [08:11] I'm not sure we can come up with a solution to take the highest version with simple sql queries though ... [08:12] They'd get fairly nasty, yeah. [08:12] And this initialisation thing already takes a rather long time to run sometimes. [08:13] The advantage of this is that it's pretty simple. [08:17] back [08:27] StevenK: doc fixed. MP needs review ;). [08:34] good morning [08:41] Project db-devel build #633: FAILURE in 6 hr 36 min: https://lpci.wedontsleep.org/job/db-devel/633/ [08:48] rvba: I've made a first attempt at it. [08:49] wgrant: thanks! [08:52] wgrant: Thanks for QAing my stuff over(my)night. And for all the other times you've done it :) [08:55] Project parallel-test build #35: STILL FAILING in 39 min: https://lpci.wedontsleep.org/job/parallel-test/35/ [08:55] Launchpad Patch Queue Manager: [r=benji][bug=746379] Update the "Latest message" column in [08:55] DistroSeries:+localpackagediffs when a comment is added in the [08:55] expander. [08:55] wgrant: Yeah, thanks for that too ;) [09:01] stub: hey, I saw some nice progress towards bugsummary-2 [09:01] Yer. Triggers and functions written. If they worked, that would be great :-) [09:02] stub: I've proposed nuking readonly mode on the list [09:02] upstream bug fixes are not sticking atm. need to look at it today. [09:02] lifeless: I'm just responding. [09:02] cool [09:08] stub: How would we fix having to restart appservers, and the time to rebuild the replica after schema change ? [09:09] Appservers could automatically failover when the master db connection is unavailable, and automatically switch back when it is available. [09:09] I think thats a different thing isn't it? [09:09] At the moment it is a manual switch. [09:10] At the moment we break out the replica from the cluster so we can upgrade the whole cluster. We could leave it in the cluster, but shut down its replication daemon. [09:11] stub: I realised something the other day - the slave rebuild is contributing to our bloat [09:12] If we then had smarter scripts, instead of detecting 'the cluster is in sync' we would detect 'the nodes we care about for now are in sync', we could do the upgrade live. When done, we bring the dead daemon back and the readonly node should then get the updates applied. [09:12] lifeless: Yes, it does. [09:13] stub: so, the core of the proposal I am making is 'lets focus on minimal actual downtime'; if we get buyin on doing that (and so far responses have been positive); and if we decide the best way to do that is to leave the readonly codepaths in the appservers - thats fine with me. === michaelh1|away is now known as michaelh1 [09:14] Right. I'd rather not invest time in making RO mode better if we only care about it as a failover mode, because making the extra complexity reliable will be a lot of work and probably cause downtime as we learn. [09:15] exactly [09:15] stub: I'd like to aim for 4-5 second downtime windows [09:16] stub: if we reconfigure-db-connections; kill all current backends (except slony); apply patches; reconfigure-db-connections again [09:16] Hello! [09:17] stub: based on our previous discussions it seems to me we can get pretty darn close [09:19] We are not a credit card processing system losing thousands of dollars a minute of downtime, and doing real HA is expensive. [09:19] Right. So better to just pause things in HAProxy. [09:19] And deal with an exploded master with real downtime if the master explodes. [09:19] Yer. Appservers need to get more intelligent though and learn to switch themselves over live. [09:19] stub: I wouldn't even pause in haproxy [09:19] stub: its another moving part to change and deal with [09:19] We could possibly pause everything in pgbouncer [09:20] certainly [09:20] thats something we can iterate towards or even do upfront [09:20] I'm kindof of hopeful to be able to start doing this next week [09:20] Sounds excellent since I'm on holiday next week ;) [09:21] bleep [09:21] ok, week after :> [09:21] I'd like you around for the first few times [09:21] I hear there is a sprint on or something [09:21] till we get the quirks out [09:21] My inbox seems to thinki any mail from lifeless is Priority Inbox mail. Interesting. [09:22] good inbox [09:22] After a while of trying to train it, I realized that there is no such thing as priority email ;) [09:22] It works okay for me so far. Mostly. [09:25] * stub runs off to the ATM and to grab blinner [09:25] blinner?! [09:27] I'm guessing he's *really* hungry [09:31] Project windmill-db-devel build #389: STILL FAILING in 49 min: https://lpci.wedontsleep.org/job/windmill-db-devel/389/ [09:44] Yippie, build fixed! [09:44] Project devel build #802: FIXED in 6 hr 40 min: https://lpci.wedontsleep.org/job/devel/802/ [09:54] * bigjools reads lifeless's wall of email [09:57] one more coming up [09:58] lifeless: it might be helpful if you could format the emails into distinct sections, I usually end up re-reading your emails as it's hard to take 'em all in in one go [09:58] bigjools: thats good to know - I do sometimes, but I kindof run into 'is this an email or a wiki page' feeling sometimes too [09:59] lifeless: they do read like a steam of consciousness :) [09:59] stream* [09:59] well, I do edit and shuffle and so on; trying to paint a narrative [09:59] my head is nowhere near as organised === almaisan-away is now known as al-maisan [10:02] lifeless: in any case, I've been wanting to sort out the schema change downtime story for a loooong time [10:02] most schema changes don't involve interdependent code [10:14] gmb: got time for a review? I have two MPs ready including https://code.launchpad.net/~jtv/launchpad/bug-791204/+merge/64390 [10:15] jtv: I'm just working on one for danilos, but I'll take a look when I'm done with that. === gmb changed the topic of #launchpad-dev to: Performance Tuesday ! | https://dev.launchpad.net/ | On call reviewer: gmb | Critical bugs: 202 - 0:[######=_]:256 [10:15] A steaming pile of consciousness [10:15] great, thanks [10:16] A stream of ss [10:17] (Just for the sake of the play on words of course, not my actual opinion!) [10:20] danilos: Accepting your "it is thoroughly tested" assertion, r=me. [10:20] (Although the evidence for that is pretty strong, I'll grant you) [10:20] gmb, heh, thanks :) [10:22] gmb, after you get relaxed a bit with the one from jtv (ha), you can pick the following one from me as well: https://code.launchpad.net/~danilo/launchpad/bug-772754-other-subscribers-loading/+merge/64186 (that one is oversized a bit though, hope you don't mind) [10:22] danilos: hey hey hey, I had _two_! [10:22] danilos: jtv speaks the truth. But I'll try to come to yours early this afternoon. [10:23] This could be a fun exercise in scheduling algorithms [10:23] jtv, hey, I had three but didn't want to take all the available "room" for others to get their code reviewed :) [10:23] jtv, unlike, ahem, some other people [10:23] jtv: the docstrings for match_exact_string etc are misleadning [10:23] jtv: the :return: is incorrect - it returns a storm expression whose result will be True if ... [10:23] danilos: hey, if you leave room for other people, don't get all disappointed when other people use it! [10:24] thanks lifeless — I'll have a look right away. [10:24] jtv: (AIU the code) [10:24] danilos, jtv : http://oo00.eu/ [10:24] Anyway. [10:24] lifeless: ISWM—you're right [10:24] danilos: we've just heard the URL of the banshee. [10:25] Go on, ask for whom the bell tolls: it tolled for chromium! [10:25] It died. [10:26] jtv, gmb: :) [10:26] allenap: hi [10:26] allenap: rabbit: do we reset SIGPIPE when spawning it ? [10:30] lifeless: he's out for a bit, will be back soon [10:31] thanks [10:31] jtv, I've been hitting a lot of webkit crashes with epiphany lately, but just on this computer (even though it's identical arch to my laptop and all the same versions are used) [10:32] jtv, so I just figured out it's probably your fault and learned to live with it (or maybe hardware, but it's so much nicer to blame you again) [10:33] danilos: agreed, it makes perfect sense given that I see the same problem. [10:33] See that everyone? This is why I liked the transition to squads! :-) [10:34] basically the only reason, I am sure :) [10:34] oh yes [10:38] lifeless: I haven't done anything special with signals. [10:39] http://bugs.python.org/issue1652 [10:40] danilos: whatever the problem is, it's probably jtv's fault [10:40] All of a sudden I'm not so sure about this squads thing any more. [10:41] bigjools, glad to hear that, that's how it used to work in the previous team structure as well! [10:50] lifeless: That's a great find. I'll try that simple change. (I'll do it in a separate branch from the subprocess changes I made.) [10:54] cool [11:03] jtv: r=me on your first branch; your tests need some comments though. [11:03] gmb: thanks, will do. I always try writing 'em clear enough that they don't need comments, but after that I don't mind adding them if they're still needed. :) [11:04] jtv: Well, I'm lazy, so I tend to say they all need comments otherwise I need to think. [11:04] I try to encode the whole story in the function name. :) [11:05] jtv: Oh, I know. And that often works. Sometimes though it requires context that I don't have to be able to understand the encoding. [11:06] Right — problem is it's very hard for the person who wrote a text to judge that, so that's where I rely heavily upon the reviewer. [11:14] gmb: I have a short branch for you if you're free. [11:15] StevenK: Sadly, there's a queue at the moment. I may get to it later but I can't promise anything [11:15] That's okay. I will beg bigjools, since he whinged at me about the bug. [11:18] bigjools: https://code.launchpad.net/~stevenk/launchpad/reject-changes-file-no-email/+merge/64523 please [11:50] * gmb -> changing locations. BBIW. === henninge_ is now known as heninge === al-maisan is now known as almaisan-away [12:16] lifeless: ping [12:17] hi [12:17] lifeless: oh hi, was going to ask for a quick chat, but maybe we could do it tomorrow instead [12:17] jml: tonight would be better; tomorrow night leads into thursday morning which is at an uncivilised time [12:17] jml: I need to take recycling out and stuff like that, but in 15-20 I can chat with you [12:18] lifeless: perfect. skype me when you're ready. === heninge is now known as henninge [13:05] hi bigjools [13:06] bac: hey [13:06] bigjools: could i have a mid-imp call with you re: bug 519857 [13:06] <_mup_> Bug #519857: Upload processor OOPSes with bad email addresses

< https://launchpad.net/bugs/519857 > [13:06] bac: stevenk already fixed it. [13:07] ah sorry [13:07] no he didn't [13:07] different bug! [13:07] bac: so [13:07] what needs to happen is that no oops gets thrown, and we send an email to whoever signed the changes file [13:08] I just noticed you said mid-imp... [13:08] bigjools: what did you mean by ' [13:08] 21:02 < bigjools> lifeless: in any case, I've been wanting to sort out the schema change downtime story for a loooong time [13:08] 21:02 < bigjools> most schema changes don't involve interdependent code [13:08] ' [13:08] bigjools: yeah, i was planning to catch the ParseMaintError in process() [13:09] lifeless: we should be able to make schema changes on a live DB [13:10] bac: in this case it's already sending a rejection for another reason [13:10] bac: so we don't really need to do anything other than catch and ignore the error [13:10] bigjools: what do you mean by "in this case"? [13:11] bac: the traceback on the bug [13:11] it's in the middle of processing a rejection [13:11] which I also suspect is because a previous bit of code already noticed the bogus email address [13:12] bigjools: i intended the code change to look something like: http://pastebin.ubuntu.com/626527/ [13:12] bigjools: do you mean that most schema changes don't alter the meaning of existing fields, nor require new fields to be populated by appservers (at least initially) ? [13:12] bigjools: if thats what you mean, I agree :) [13:12] lifeless: yes! [13:12] lifeless: and we should structure all our patches to be like that as much as possible [13:13] bigjools: so there are some slony limits that make applying while truely live impossible today, but we can come close. [13:13] bac: I would not do that [13:13] bigjools: i think the code parts are easy. where i need some guidance is creating new package suite in lib/lp/archiveuploader/tests/data/suite [13:13] bigjools: yes, if this proposal gets off the ground stub and I will start rejecting patches that are /not/ like that [13:13] bigjools: ok [13:15] bac: the code here has changed *significantly* since the bug was filed, because steve re-wrote the notification stuff [13:15] bigjools: yes, that was obvious as nothing matched up [13:15] bigjools: but the problem still exists [13:16] bac: yes - what I would do is catch the error in lib/lp/soyuz/adapters/notification.py - get_recipients () [13:16] and just not add any invalid emails to the recipient list [13:16] benji___: lp:~benji/launchpad/bug-697735 seems to be deleting some db patches. .. [13:17] the changesfile signer will always be valid if we get this far so that's the last-ditch option === benji___ is now known as benji [13:17] lifeless: excellent [13:17] bac: "blamer" in that code is the signer [13:17] lifeless: ooh, that doesn't sound right; thanks, I'll take a look [13:17] benji: === removed file 'database/schema/patch-2208-63-0.sql' [13:18] ... [13:18] bac: so we need a test. For that we make a dodgy package and try to upload it. [13:18] bigjools: yes, *that* is the part that i got hung up on yesterday [13:18] bac: however thinking about it that's overkill for this case, so we could just do a unit test case for get_recipients [13:19] bigjools: when i make a bad email address in the changes file i need to sign it [13:19] bigjools: yes, that may be true now that i'll not be changing process() [13:20] bac: right. fix get_recipients + unit test = simples. [13:20] bigjools: if i did need to create a new test/data/suite are there any instructions on how to create and sign one? [13:20] then we can QA it with an upload that has a dodgy maintainer [13:20] bac: no :( but it's not too hard. [13:20] bigjools: i couldn't find any keys, etc [13:20] there's a private key in the tree [13:20] you need to add it to your local keyring [13:20]