[00:00] yep. sorry, bit slow on the uptake there. brain took a minute to context switch [00:03] wgrant: mumble? [00:10] anyone know if https://bugs.launchpad.net/launchpad/+bug/2810 is actually fixed now ? [00:10] <_mup_> Bug #2810: buildd <-> buildmaster protocol is undocumented

< https://launchpad.net/bugs/2810 > [00:16] Project windmill build #220: STILL FAILING in 1 hr 4 min: https://lpci.wedontsleep.org/job/windmill/220/ [00:22] lifeless: that's a low bug number :) There wasn't anything like that when I was in the Soyuz team, if that's a useful data point. [00:23] jelmer: thanks [00:26] poolie: morning! you might like to do bug https://bugs.launchpad.net/launchpad/+bug/83928 yourself, given you know the ropes :) [00:26] <_mup_> Bug #83928: register launchpad url scheme < https://launchpad.net/bugs/83928 > [00:26] hi lifeless [00:26] is it urgent? [00:27] oh, are you just reassigning tim's things? [00:27] wallyworld: I am back [00:27] sinzui: ok [00:27] poolie: I'm nuking the use of wishlist in the lp bugs db [00:27] benji: thanks for the mail refactoring review [00:27] my pleasure [00:30] good [00:31] NCommander: It will be implemented soon as part of the Derived Distros work. [00:31] wgrant: handy, I was looking at LP and seems a far chunk was implemented since the last time I looked [00:32] Yeah, some progress has been made. [00:37] wgrant: https://bugs.launchpad.net/launchpad/+bug/2810 - has that changed recently? [00:37] <_mup_> Bug #2810: buildd <-> buildmaster protocol is undocumented

< https://launchpad.net/bugs/2810 > [00:37] lifeless: No, it got even worse when I deleted the old docs (which were completely wrong, but still) [00:37] wallyworld: lp:lp-production-crontabs/trunk [00:45] hmm [00:45] odd urlification here - https://bugs.launchpad.net/launchpad/+bug/409665/comments/2 [00:45] <_mup_> Bug #409665: reviews lose commit message context < https://launchpad.net/bugs/409665 > [00:45] see the 'lp)' [00:46] Tags: lp-code [00:46] Martin Pool wrote on 2007-02-08: #1 [00:47] Oops. [00:49] ? [00:49] mispasted? [00:50] Yes. [01:03] StevenK: Does initialise-from-parent still work? [01:03] It ought to. Why? [01:04] Well, we sort of need it tomorrow. [01:04] So it would be nice if it did. [01:04] And a lot of that stuff has changed. [01:07] wgrant: Trial run on DF? [01:08] Might try that. [01:11] wallyworld: ping [01:11] re mp 58410 [01:11] lifeless: hi [01:11] wallyworld: the permissions are per-project [01:11] wallyworld: so I'm wondering why you say they don't need updating [01:13] lifeless: i wasn't aware of that. i'll recheck. i may need to change the xhr call as you said [01:13] wallyworld: on https://bugs.launchpad.net/launchpad-project/+filebug [01:14] lifeless: the sample data used for testing is very limited so it was hard to get a full view as to what was updated when the project changed [01:14] on dtdparser - submit something, expand extra options, no status/importance/assignee etc [01:14] change the dropdown to lp [01:15] same thing, but when extra options is expanded, all the fields are available [01:15] wallyworld: sure, I'm giving you a demo is all [01:15] lifeless: ah, excellent. i really appreciate the input. tha's helps a lot [01:17] sinzui: ^^^^^ based on the above, i have some fixing to do before you finish the review. but you can always take an initial look [02:03] I'm guessing nobody added the new prefixes. [02:03] lifeless: Could you do that, with your newfound superpowers? [02:05] they are already in the system [02:05] We have very few OOPSes. [02:05] Hm. [02:05] \o/ [02:05] Although at least 150 hwdb OOPSes are missing. [02:05] And they're from loganberry... [02:05] Haha. "That's a small number, so it can't be right." [02:05] Or maybe they unbroke checkbox. [02:05] diogo put A-Z into the system a while back [02:06] Ah. [02:06] I checked this yesterday :) [02:06] and just now again to be sure [02:06] wgrant: bug 770107 [02:06] I assumed you would have, but the numbers were implausible. [02:06] <_mup_> Bug #770107: launchpad relies on login.ubuntu.com but does not sync email addresses < https://launchpad.net/bugs/770107 > [02:06] Yes :( [02:06] wgrant: I'm positive there is a bug about user confusion and login.launchpad.net [02:06] neither sinzui nor I could find it yesterday [02:06] There is, but I can never find it. [02:07] grag [02:07] I'm sure I've seen it. [02:07] Has Google always mangled bug page titles? [02:07] I don't recall seeing this before. [02:08] ref ? [02:08] Some of them are now "$SUMMARY - Launchpad Bugs" [02:08] eg search for 'site:bugs.launchpad.net login.launchpad.net' [02:08] Some of the results have the real titles, others don't. [02:09] whee [02:09] (not unreasonable, given our titles suck so much) [02:10] I wonder if that will affect our google-api-search results [02:13] hmm... is it known that if you expand a bug task for editing, the milestone field is set to '(no value)' instead of the milestone the task is currently assigned to if the milestone is deactivated? So if you go and edit a bug assigned to an old, deactivated milestone it'll remove it from the milestone and to fix it you have to go reactivate the milestone. total PITA [02:14] cody-somerville: sounds like a bug [02:18] lifeless: Ahem. [02:18] rs = (store [02:18] .find(FeatureFlag) [02:18] .order_by( [02:18] FeatureFlag.flag, [02:18] FeatureFlag.scope, [02:19] Desc(FeatureFlag.priority))) [02:19] Spot the bug. [02:19] This explains why none of the overrides are working. [02:19] Hah [02:20] So, we are *actually* running with a 9s timeout. [02:20] wgrant: scope should be after priority [02:20] Without exceptions. [02:20] lifeless: Right. [02:20] \o/ [02:20] right, lets clean those out [02:20] leave the rootlogin one behind [02:20] but the rest are clearly tolerable [02:20] I don't trust the OOPS counts, but yeah, we can add them back. [02:27] 11:18:36 < lifeless> MTecknology: runs in a trusted context; not at all easy to change [02:27] Huh? [02:30] * StevenK tries to remember the shell magic for 'show me everything that is in file1 that isn't in file2' [02:30] comm, I guess ... [02:31] Argh, ENOSPONGE [02:32] StevenK: diff ? [02:32] Suppose [02:32] comm did the job, so ... :-) [02:33] And I've not used it for a while, so it's good to dust off the memory [02:36] so.. are recipes and packages not build in the same restrictive manner? [02:37] MTecknology: not identical, no [02:37] MTecknology: They are. [02:37] Well, recipes are run outside the chroot, but that doesn't matter. [02:38] I just assumed they were so I didn't get why allowing recipes to run commands was dangerous - since deb/rules could easily be changed prior to an upload [02:40] It isn't just debian/rules that's an issue [02:42] is debian/rules an issue? [02:44] MTecknology: You just said 'since debian/rules could easily be changed prior to an upload' -- I think there are far more sinister things one could do if running external commands was allowed [02:45] StevenK: I just assumed you guys handle it if someone tried to do something in debian/rules; so I'm not understanding why recipes are different - or.. why they have to be so different that shell commands in there has to be so dangerous [02:45] Recipe builds aren't executed in a fresh VM? [02:45] cody-somerville: They are. [02:46] So I guess I have the same question as MTecknology. [02:53] Hmmmmm. [02:55] lifeless: wgrant@carob:~/logs$ grep -l -r -e 'Exception-Type: $LaunchpadTimeoutError\|RequestTimeout$' */2011-04-26 | wc -l [02:55] 452 [02:55] * 228 Time Outs [02:55] Does not compute. [02:55] wgrant: I have a theory [02:55] wgrant@carob:~/logs$ grep -l -r -e 'Exception-Type: SoftRequestTimeout' */2011-04-26 | wc -l [02:55] 408 [02:55] * 105 Soft Time Outs [02:55] Computes even less. [02:56] wgrant: histogram by machine? [02:56] wgrant@carob:~/logs$ grep -l -r -e 'Exception-Type: SoftRequestTimeout' */2011-04-26 | cut -d/ -f1 | uniq -c [02:56] 55 chaenomeles [02:56] 63 gac [02:56] 134 soybean [02:56] 156 wampee [02:57] (this is also only lpnet, not edge, so the numbers should be *lower*) [02:57] But none of those can be combined to make 105 [02:58] You are correct. [02:58] Maybe with edge, though... [02:58] Let me find the edge logs. [02:58] As my father used to say, "He must have gone to a different school." [03:09] /join #launchpad [03:16] lifeless: /win 55 [03:16] Argh. [03:17] yes? [03:17] lifeless: https://code.launchpad.net/~wgrant/launchpad/bug-770576/+merge/59155 [03:19] wgrant: why is FeatureFlag.scope still there? [03:20] (flag, priority) is a unique [03:20] True. [03:20] Forgot that bit. [03:21] I wish I could understand what makes running commands in recipe builds dangerous... If it's a fresh vm and is basically (from what I can see), a locked down chroot; what makes that more insecure than upload builds where a person could put anything at all in debian/rules (with the exception that those uploads also provide an easy way to download packages [Build-Depends:]) [03:21] Sorry to be such a pain too... I just don't get it. :( [03:22] MTecknology: It isn't dangerous. [03:22] It's forbidden for other reasons. [03:22] That are not entirely clear. [03:23] Is there any way to make those reasons more clear? [03:23] I'm not sure. [03:23] But still, you shouldn't have to run shell commands. [03:23] Why do you want to? [03:23] https://code.launchpad.net/~nginx/+recipe/nginx-nightly [03:24] That seems mildly insane. [03:25] indeed [03:30] lifeless: That's fixed. [03:33] this is the recipe I'd like to use.. http://dpaste.com/536105/ [03:37] the nest-part only used because ..... i'd definitely do that part of the code differently [03:44] MTecknology: that strikes me as a kinda odd thing to want to do [03:45] spiv: changes is generated by hand on every release... about the only non-nest option would be with wget and that'd probably be an ugly option.. [03:45] MTecknology: I'm curious why the lp:nginx/stable branch isn't something that you could simply do a regular merge of, rather than picking just those files. [03:46] * spiv suddenly realises part of what this is trying to do [03:47] spiv: because I want to make this something fully automated so I don't need to do a merge any time a branch changes [03:47] MTecknology: I'm not sure abusing nest-part to copy a file from a branch into a tree of the same branch is something we want to support [03:47] so far, it feels like recipes are pretty much worthless... [03:48] The point of the "merge" directive of recipes is exactly so that you don't need to do a merge yourself! [03:49] Why don't you tell me how I should do this so I set it up once and don't touch it again until a new stable exists? [03:49] MTecknology: Then don't use them? [03:50] If I could just use 'run' then I wouldn't need to do the copy.. [03:51] As in 'run wget' ? [03:51] 'run cp' [03:53] MTecknology: why would you need to do a merge every time the branch changes ? [03:53] MTecknology: Perhaps this is a naïve question, but why not just use the files where they are, rather than cp'ing them? [03:55] when a version is released, there's a whole series of crap that takes place. Part of that is an auto tool that moves stuff around and compiles docs. the README file isn't just docs/text/README, if I could use run, I'd use cat and a redirection to actually build that file correctly. [03:56] but it's also not something the debian packaging should need to accomodate; because when a version is released, that stuff is in place [03:56] * spiv wonders if "nest-part deb lp:foo/debian debian; merge tweak-deb lp:foo/tweaked-debian" works (where lp:foo/tweaked-debian is a branch off lp:foo/debian)… [03:58] So the problem is you want to use the debian packaging info designed for releases, but what you have are branches not releases, and these branches are almost but not quite laid out the same way? [03:59] yup [03:59] I'd probably try making a branch of the debian packaging then that accomodates those differences, and merge that in after the nest-part of the debian packaging branch. [04:00] I'm not sure if that would be too ugly. [04:01] would that work after things change in the packaging? [04:01] I can imagine a 'cp' or 'mv' directive in recipes being reasonable to add, but for this problem in general I don't think those would always be sufficient. [04:02] MTecknology: it should, if the changes inside debian/ don't conflict. [04:02] MTecknology: I'm not sure that it will work, but it ought to :) [04:03] so debian packaging is lp:nginx/debian and no debian/ dir; using nest it fits in just fine; the merge will need to be of the change, with a debian sub directory? [04:03] can I have just the debian/rules file in there? [04:03] is there a sensible bugtracker for our moinmoin sites? https://bugs.launchpad.net/ubuntu/+source/ubuntu-docs/+bug/685482 [04:03] <_mup_> Bug #685482: Error logging in via launchpad openid to edit community wiki

< https://launchpad.net/bugs/685482 > === Ursinha is now known as Ursinha-afk [04:07] spiv: or would that probably not work? [04:10] MTecknology: just a branch of lp:nginx/debian with a change to its rules or whatever to do what you need [04:11] MTecknology: no renames of files in that branch or new directories, unless you really want to rename files in debian/ or make new directories in debian/ in the resulting recipe. [04:12] I meant- I was wondering if that branch could have only the changed files.. but i imagine not [04:12] then it'd be a crappy merge.. [04:13] MTecknology: right, just make the changes you need, and don't worry about the other files you don't need to change. [04:13] heh... [04:14] 'run make misc/GNUmakefile snapshot' [04:14] that'd be enough to replace all of this [04:14] Then your rules file only needs one extra line [04:15] MTecknology: given that make rule does "svn export", probably not :) [04:15] well... I'd still need nest-part to work on files.. [04:15] ah.. missed that [04:15] I don't think "svn export . $(TEMP)/$(NGINX)" will work well in a bzr tree :) [04:16] probably not :P [04:17] ("bzr export . temp-dir" would work alright in an svn tree if you have bzr-svn installed, though ;) [04:17] doesn't that only eliminate the .SVN directories while copying to a new location? [04:19] And only copy versioned files, I'd expect [04:19] Which probably doesn't make a difference in a fresh tree. [04:20] I'm adding the extra stuff... setup: with setup added to .PHONY [04:30] looks like they actually did automate the release process, just too automated for a nightly snapshot liek this.. [04:32] Project windmill build #221: STILL FAILING in 1 hr 5 min: https://lpci.wedontsleep.org/job/windmill/221/ [04:34] now we see if it works.... [04:35] spiv: bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified. [04:36] it doesn't want to merge with the packaging branch, it wants to merge with the source branch [04:40] spiv: I 100% agree that nest-part shouldn't be used to copy files; but in this event, it doesn't seem to be possible [04:40] being unable to use run has kept me from using recipes other places too... === jtv changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: jtv | https://code.launchpad.net/launchpad-project/+activereviews === lifeless changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jtv | https://code.launchpad.net/launchpad-project/+activereviews [04:43] heck... even having to make the series stable is a work around hack that could be avoided by use of run.. [05:01] MTecknology: ah, of course, nest-part doesn't set a parent revision in the tree :( [05:01] MTecknology: I think that bzr-builder could be improved to make that case work [05:01] MTecknology: but that doesn't help you today, of course :/ [05:06] spiv: nah... I already accepted that it's not going to work today [05:06] probably not this week, or next month [05:06] but after that... i can hope :) [05:07] spiv: for a daily build.. this is probably the best option - http://dpaste.com/536138/ [05:12] MTecknology: one question I guess is why does upstream's vcs layout differ from the tarball layout like that. It seems a bit unnecessary. But how recipe builds can cope nicely with packaging designed for release tarballs rather than vcs snapshots is an interesting problem in general. [05:14] spiv: there's a makefil that makes the source ready for a release or snapshot - but it's not really feasible to try to call a makefile inside of a recipe - especially because they require other apps be installed [05:27] MTecknology: oh, one last trick [05:27] MTecknology: to workaround the “Branches have no common ancestor” [05:27] MTecknology: you could try appending something like "-2..-1" to merge line [05:28] hm? [05:28] This is for the "merge in a tweak to the debian/ dir added via nest-part" approach [05:29] what would the line look like for the merge? [05:30] What did you try that gave “Branches have no common ancestor…”? [05:30] I think just append “ -2..-1” for a crude workaround [05:30] (To say just take the changes in the newest revision of that branch) [05:31] So e.g. if you had “merge deb-tweak lp:blah/debian-tweaked" then “merge deb-tweak lp:blah/debian-tweaked -2..-1” [05:33] I had 'lp:nginx' 'nest packaging lp:nginx/debian debian' 'merge tweaks lp:nginx/debian-tweaks' [05:33] something close to that [05:34] Ok, so add ' -2..-1' to that tweaks line [05:34] k- i'll have to try that tomorrow.. it's getting too late for me [05:35] what's that do? [05:35] Only merge changes from the latest revision [05:35] it was complaining about merging lp:nginx/debian-tweaks into lp:nginx [05:36] MTecknology: takes changes from the 2nd-last revision (-2) to the last revision (-1) [05:36] MTecknology: i.e. the changes in the most recent commit [05:36] MTecknology: It's actually merging into a tree, not a branch [05:37] MTecknology: a tree that already has the debian/ dir added [05:37] hm.. are commits made at every step of the recipe? [05:37] No, no commits at all [05:38] It's like using bzr merge --force, which allows doing a merge on a changed-but-uncommitted tree [05:39] oh [05:40] Hmm, you're using nest not nest-part to embed the debian/ dir, so really that merge ought to have just worked. I think I know why it didn't, I'll file a bug. [05:41] thanks, want to subscribe me to it? [05:44] Bug #723417 [05:44] <_mup_> Bug #723417: Further information input area shrunk making it difficult to input and review details < https://launchpad.net/bugs/723417 > [05:44] 5 lines seems a bit short for most description fields. [05:44] I think we should probably bump to 10/15. [05:44] Any objections? [05:44] MTecknology: will do [05:45] jtv: Hi. [05:45] spiv: thanks, i'm gonna try tofall asleep over the noise of my neighbors that need to be murdered.. [05:46] hi wgrant [05:46] jtv: Nice short review for you: https://code.launchpad.net/~wgrant/launchpad/bug-751982/+merge/59162 [05:46] spiv: hopefully I wasn't too much of a pita [05:47] MTecknology: no, not at all [05:48] wgrant: I'm working on a big one, but if this one's short then I'll SJF. [05:50] jtv: Diff against target:31 lines (+11/-0) 2 files modified [05:50] wgrant: that reply actually took longer than it did to read the diff. :) [05:52] wgrant: done [05:52] Thanks. [05:57] MTecknology: oh, I'm being silly, merging into nested branches is already supported: [05:58] MTecknology: you just indent the 'merge' line under the 'nest' line. https://help.launchpad.net/Packaging/SourceBuilds/Recipes#Nesting [05:58] heh... easy [05:58] makes sense too... [05:58] :) [06:00] I'll play with that tomorrow; then when the bug is taken care of, I should be able to make this work :) [06:00] although.. using 'run' would be a better solution to merging changes from another branch [06:01] but either way- it'd work :) [06:01] * MTecknology is going to sleep for real this time [06:31] wgrant: I wonder if maybe you could review my branch for initializing distroseries indexes. The regular reviewer chickened out. [06:32] jtv: So I saw. [06:32] I will have a look. [06:32] Great, thanks. [06:33] He's right though: the reviewer I could otherwise get on my own squad hasn't just returned from two weeks' leave. Somehow that's not helping. :-) [07:06] jtv: Reviewed. [07:06] lifeless: Still around to mentor? [07:07] wgrant: that's fantastic, thanks. Didn't expect it so soon. [07:07] fsvo [07:07] I'm trying to finish these triggers off [07:07] which is tricky [07:07] Ah, right. [07:07] Fun fun. [07:08] so if its non trivial, not tonight. [07:08] Sure. [07:09] lifeless: Bug #771527 [07:09] <_mup_> Bug #771527: 'Answers' link greyed out on Ubuntu nattry translation page < https://launchpad.net/bugs/771527 > [07:09] lifeless: DistroSerieses don't have Answers. [07:11] wgrant: but distros do [07:11] Sure. [07:12] wgrant: so the link can sensibly and trivially go to the distro answers [07:12] The header is already confusing enough :( === almaisan-away is now known as al-maisan [07:46] jtv: https://code.launchpad.net/~stevenk/launchpad/pdsd-cleanup/+merge/59172 when you're able [07:47] StevenK: up to my ears atm... maybe in half an hour? [07:47] jtv: At some point before you EOD is perfectly fine. [07:49] StevenK: got you scribbled down. [07:51] Jotted. That's the word I was looking for. [08:22] lifeless: Hi. [08:31] jtv: I note it's been 45 minutes. [08:32] StevenK: I meant remind me in 30. :) I'll start right now. [08:33] StevenK: "don't have any special fields set" is a bit weird as a requirement... how about "don't have their details filled out"? [08:34] StevenK: reviewed. [08:35] jtv: Thanks for the +1, I'll take your suggested wording [08:35] Cool. [08:36] wgrant: hi [08:37] lifeless: 11634.2.9 [08:37] wgrant: in your review of my branch, you say to say "careful indices mode." I note that the actual script doesn't have such a thing... shall I add the wording to the run_publisher option? [08:37] lib/lp/bugs/model/bug.py [08:37] lifeless: Second hunk of lib/lp/bugs/model/bug.py [08:37] lifeless: Any ideas why you changed that? [08:40] wgrant: isn't that just the bottom of linkAttachment ? [08:41] lifeless: Yes, I am a fool. I mean lib/lp/bugs/browser/bugtarget.py instead. [08:41] wgrant: + :param send_notifications: Control sending of notifications for this [08:41] + attachment. This is disabled when adding attachments from 'extra [08:41] + data' in the filebug form, because that triggered hundreds of DB [08:41] + inserts and thus timeouts. Defaults to sending notifications. [08:42] Well, *that*'s not in the commit message. [08:42] I see. [08:42] wgrant: so I think I had a dirty branch [08:42] jtv: -A is careful indices. [08:43] wgrant: it'd be nice if the script called it that then! [08:43] jtv: -P is careful file publishing, -A is careful index publishing -SOMETHING is careful domination, -C is all of the above. [08:43] wgrant: but yeah the motivation was to stop sending a notification-per-attachment in apport bug filings [08:43] wgrant: if it was a dirty branch this may have only been half realised [08:43] lifeless: We have a critical regression bug on that now :( [08:44] wgrant: the script currently calls it "careful apt" and says it makes the apt-ftparchive run careful. [08:44] wgrant: #? [08:44] lifeless: Bug #667604 [08:44] <_mup_> Bug #667604: new bug reports with attachments added generate blank email instead of including links to attachments < https://launchpad.net/bugs/667604 > [08:44] jtv: Right, and apt-ftparchive generates the indices. [08:44] jtv: (it's still a bit wrong now, since NMAF is also an option) [08:45] NM? [08:45] NoMoreAptFtparchive. [08:45] Native index generation. [08:45] Argh that [08:45] Looks to me like it should be hidden in the publisher TBH [08:45] It is. [08:45] The docs of -A are wrong. [08:45] wgrant: so, sucky fail. [08:46] It will trigger index publication regardless of the used mechanism. [08:46] wgrant: but yes, reverting that would just break apport bug filing [08:46] wgrant: I have no idea what that means, but it's obvious to me that it needs some updating. [08:46] wgrant: you bisected to that rev? [08:46] jtv: Index generation uses either a-f or NMAF. -A will trigger whichever one is appropriate, despite its description referring solely to a-f. [08:47] lifeless: annotated to it. [08:47] wgrant: I don't understand why it doesn't generate a notitifcation with the summary and description [08:47] lifeless: Hm? [08:47] wgrant: this doesn't suppress notifications for the bug/task creation [08:47] wgrant: and is (IIRC) only in the apport bug filing form. [08:48] lifeless: Two emails are sent. [08:48] lifeless: One about the bug filing. [08:48] And one about the subsequent comment and attachments. [08:48] wgrant: oh and a stupid empty one ? [08:48] Except the comment is empty, and the attachment notifications are suppressed. [08:48] Right. [08:48] I guess we could just suppress that email, but it would be nice to unbreak notifications. [08:48] so, two bugs; shouldn't send mail if there is nothing to say. And separately tell folk about the attachments. [08:49] I was intending to aggregate the warnings or something I think [08:49] but the problem is that we use a bloody pub-sub mechanism for sending mail about bugs [08:49] wgrant: thanks for clarifying that. I'll update the help string. What I meant earlier is that the decision which index generation method to call looks as if it should be hidden inside a single method call. [08:49] jtv: It is. [08:49] which is a totally fine system *if* you have enough granular control [08:49] lifeless: Yeah, ideally it would queue subscribers, I guess. [08:49] Or queue the inerts. [08:50] wgrant: IIRC this was when we had 17 second bug filings. [08:50] Yeah. [08:50]