[00:00] wallyworld_, wgrant. yes it is my fault https://lpbuildbot.canonical.com/builders/lucid_lp/builds/1647/steps/shell_6/logs/summary [00:01] sinzui: np. i'll fix [00:01] Were the two branches landed in the wrong order? [00:01] wgrant, bingo [00:01] so no fix required, just restat bb? [00:01] restart [00:01] but they are both in place I think, but they were landed independent too [00:01] so it's my fault for messing up the dependencies :-) [00:02] I guess run the tests locally to confirm. [00:02] i had to resubmit both mps due to the first failure [00:02] and something messed up i guess [00:02] wallyworld_, we want to move account status to IPersonPublic... [00:03] sinzui: from iPersonRestrictedView from memory [00:03] this is another case were I considered placing it there since teams do not have accounts, then thought no, I do not want to clutter the interface [00:03] oh for person and team to be separated properly [00:05] wallyworld_, iPersonRestrictedView probably work, I was thinking public based on a from a discussion with flacoste. Public are attrs that are obvious from the knowledge that the team exists. It is as team, it is valid, and it does not have accounts (in this case) [00:05] sinzui: just looked at the stdout - ec2 did indeed flag the tests as failing i think [00:06] sinzui: i agree with the rationale you just outlined. IPersonPublic seems thebest place i think [00:06] yep, I was watching buildbot independent of wgrant since I believed the issue was a cause by the branch landing before its dep [00:07] sinzui, wallyworld_: It needs to public. [00:07] Otherwise traversal to a private team will 403 instead of 404. [00:08] sinzui: so given there's a code change, can i just to a testfix and lp-land, or do i need to rollback and do the ec2 dance again? [00:08] land it as a testfix, but you need to do it after the failure [00:08] please don't make me rollback again :-) [00:08] sure [00:09] buildbot does not notice a pre-emptive testfix :( === Ursinha is now known as Ursinha-lunch [00:09] understood. the wait will give me time to get it prepared [00:09] sinzui: It should notice it. [00:09] wallyworld_, and pqm-submit it === Ursinha-lunch is now known as Ursinha [00:09] sinzui: yes, i just do a bzr lp-land in such cases [00:09] Even if it doesn't, you can just force. [00:09] wgrant, I tried a preemptive fix a few months ago and it did not work [00:10] sinzui: Hmm. [00:10] wgrant: aren't you meant to be awol? [00:10] sinzui: You have to add [no-qa], but it should work. [00:10] wgrant, noted [00:10] wallyworld_: i don't think it's possible to be meant to be awol :) [00:11] mwhudson: semantics! [00:11] wallyworld_: yes! [00:11] (sorry) [00:11] i was being very lose with my use of the english language :-) [00:11] no need to apologise, i'm normally a stickler for that sort of thing [00:12] eg i HATE how the word "decimate" is misused all the time [00:13] wallyworld_, once the tests are fixed, you can do this to skip the 4-6 hours in ec2: http://pastebin.ubuntu.com/768498/ [00:13] sinzui: bzr lp-land does the same thing :-) [00:13] I did not know [00:13] wallyworld_: you are an epicentre of linguistic correctness! [00:13] * mwhudson hides [00:14] * wallyworld_ lols [00:14] anything else I need to know wgrant, wallyworld_. Perhaps something about how to make buildbot complete in 1 hour? [00:14] mwhudson: i bet you can't say that last sentence you just typed 10 times quickly :-D [00:15] sinzui: the parallelisation of the test suite should help :-P [00:15] PS. when I say awesome, Id not not mean as in hotdogs with mustard, I mean god-fearing awe [00:18] noted :-) [00:18] sinzui: Removing 80% of the test suite would get buildbot to an hour. [00:19] i reckon the layer startup/teardown times contribute to a large slice of the time taken too, no? [00:20] over the whole test suite, not so much [00:20] Like 6 minutes of 4+ hours? [00:20] the per-test setup/teardown overheads are pretty large though [00:20] yes :-( [00:23] sinzui: i think account_status_comment should also move, just to keep it with account_status. agree? [00:23] "Total duration of profiled methods 3152.6 seconds." [00:24] So there's only a little under an hour of layer (test)?{setup,teardown} [00:24] DatabaseLayer.testTearDown 13721 calls taking 2051.7s. [00:24] An hour of setup and teardown? Faaaark [00:25] 35 minutes removing and creating databases. Thanks lifeless. [00:25] Not lifeless' fault. [00:25] He only changed the names. [00:25] Aw [00:25] And added an extra template. [00:25] StevenK: that setp/teardown is what i was alluding to earlier [00:46] erm http://blog.launchpad.net/ [02:55] lifeless: private team. i am the owner. i make someone else the owner, but in so doing i cannot see the team anymore. so at the end of the process, the owner has changed but i see a "you are not authorised" page. should we display a one-off "this has succeeded but you cannot see the team anymore" page? [02:57] btw, this is after a change to allow owners to view the private team even if they are not members [03:00] wallyworld_: just show the page normally; same as for bugs [03:00] wallyworld_: erm, or actually, just redirect to launchpad.net/ [03:00] wallyworld_: perhaps with a notification explaining why [03:00] lifeless: right. good idea. thanks [03:06] So I have a private team. I have invited a public team to be a member. That should show up as a pending invitation, should it not? [03:12] StevenK: i would have thought so [03:13] what does it do in actuality? [03:13] bear in mind i've discovered a few things today about team behaviour by reading to code so my knowledge is patchy [03:14] wallyworld_: It doesn't seem to show it at all [03:15] I'm wondering if that is expected before I dive into our security adapter [03:15] It's expected. [03:15] if the private team invites a public team, the private team should be listed on the public teams invitations list. [03:15] Only members, private PPA subscribers and Launchpad admins can see private teams. [03:15] That's changing. [03:16] it won't be showing today, but it it should. :) [03:16] there is a bug for this [03:16] lifeless: But only shown to the public team's admins? [03:16] right [03:16] optional the public teams members too [03:17] but not to the general public [03:17] Right, which is not what you said :) [03:17] (by optionally, I mean whatever falls out of the code cleanest) [03:17] wgrant: EBRAINISTOAST [03:17] Yeah. [03:17] my config change has landed [03:18] \o./ [03:18] ii thought when StevenK said "pending invitation" it mean that the private team would see a list of invitees who had not accepted yet. but is it the other way around? [03:18] But you've seen what happens when one doesn't make completely unambiguous statements about privacy. [03:18] hilarity? [03:18] Pretty much. [03:18] wallyworld_: both directions gain visibility [03:19] ok [03:20] slightly different rules about who sees what [03:20] members can see superteams [03:20] admins can see subteams [03:20] something mumble mumble [03:20] there is a bug [03:23] several perhaps [03:27] wgrant: Okay, so I'm seeing expecting behaviour -- I can test for it, or I can fix it. [03:31] lifeless: ^ [03:32] EPARSE [03:33] lifeless =1 [03:33] +1 [03:34] wgrant: Did you just reassign lifeless? :P [03:34] Also, Morning! [03:34] A regrettable mistake. [03:34] Afternoon. [03:34] wgrant: So, fix it? [03:34] StevenK: I don't understand what you mean. [03:35] wgrant: So, I have two choices. I can test that the current behaviour is correct. Or, I can fix it so that pending private teams are shown to the team admins and write tests for that case. [03:36] Or you can leave the behaviour undefined until we finish defining the complete set of new private team behaviours. [03:36] No test at all? [03:36] Fair enough. [03:37] This branch should fix the Person:+index MixedVisibilityErrors as it stands. [03:43] Guido van Rossum - 11:05 AM (edited) - Public [03:43] Why do Python classes have both _mro_ and mro() ? What was I thinking at the time? Does anyone remember? [03:43] * StevenK laughs. [04:35] * StevenK breaks buildbot into small pieces [05:00] Can haz review? https://code.launchpad.net/~stevenk/launchpad/person-index-mixed-visibility/+merge/85427 [05:36] StevenK: looking now [05:38] StevenK: you should use "if check_permission('launchpad.LimitedView', team)" in your super_teams method [05:39] since this by default delegates to launchpad.View [05:39] and is the required permission to know of a team's existence [05:39] Why LimitedView? [05:39] with LimitedView, a user can know of a team's existence and name, displayname etc [05:39] but not any other private details [05:40] so for bug subscribers etc, i precache launchpad.LimitedView permissions [05:40] But these are super teams -- teams that the team in question is a member of [05:40] ah, ok [05:40] If you can see the team, you can see everything, so .View is the right choice [05:40] yes, sorry. i think you are right [05:41] so what was the issue before your branch? [05:42] wallyworld_: People would see , , , [05:42] When I added MixedVisibilityError, those started raising them [05:42] if the team in question (the one being viewed) is a member of those teams, why weren't they visible? [05:43] The person viewing the team page may not have permission to see the team [05:43] But members of the team view their own page do. [05:44] ok, so the user is viewing a public team that may be a member of a private team? [05:44] and the user may not be able to see that private team [05:44] ? [05:44] so in that case we would render ? [05:45] And raise a MixedVisibilityError, yes. [05:45] if my assertions above are correct, i do think we should be using LimitedView permissions then [05:45] The formatter uses View, and gives a link [05:46] since moving forward, we will be looking to allow a user to view the existence of a private team that is in any public relationship the user can see [05:46] the formatter should change to use limitedview [05:46] And not link them? [05:47] limitedview by default just delegates to view, so it's the same net effect [05:47] they should still be linked [05:47] And the user gets a 404 when they click the link? [05:47] but for now, if a user with just limitedview clicks on the links, they get a 404 [05:47] That's what I'm trying to prevent [05:47] we are yet to solve that one [05:48] there's 2 issues - not rendering , and making the link work [05:48] Besides, the private team isn't in a public position [05:48] It just has a public team as a member [05:48] It doesn't have to be disclosed by that action [05:48] * wallyworld_ thinks [05:49] which is different to a private team subscribing to a bug? yes, perhaps? [05:49] or maybe not, since members of the public team should be able to know who the parent team is? [05:49] It is, yes [05:50] ok, so let's leave it as view for now and we can revisit later if required? [05:51] I'm happy with that [05:51] thought you'd say that :-) [05:51] i thought it better to ask the question though just in case.... [05:51] or clarity 'disclosed' is -always- contextual [05:52] you can disclose to the public, disclose to a team, disclose to project etc [05:52] so here we are possibly disclosing to a team i guess [05:54] anytime in a discussion if someone says 'disclose' unconditionally, you all have to drink. [05:54] * StevenK finishes his glass of water [05:54] Is that what you had in mind? [05:54] lifeless: What time is your flight, out of interest? [05:55] StevenK: tomorrow? [05:55] lifeless: Yah [05:56] 0955 departure [05:56] but I route via akl [05:56] I arrive 1430 [05:56] It's what, 30 minutes to AKL? [05:56] at which point I will be tearing vodafone a new hole amongst other .au business [05:56] ... why? [05:57] because, a year after I closed my postpay account with them and moved countries, they started emailing me invoices [05:57] Haha [05:57] now, 1 month after, I could understand, and would have paid without much thought. [05:57] a year later? WTF. [05:57] actually 14 months or some odd number. [05:57] Anyhow, lots. [05:58] * lifeless is extremely unimpressed [05:58] I woul dhave rung from here, but their phone system is worse than loading a 3d game on a 16Kb spectrum [05:58] I didn't want to use all my skypeout credit for a year while on hold [05:59] StevenK: with the test_private_superteams_shown() test, i'd like to see another team created that would be but is filtered out, since the other tests simply check if the portlet is there or not [06:00] i guess the tales does that though [06:00] ie indirectly tests that code path [06:00] lifeless: When I moved to Parramatta, I called Telstra and cancelled the landline service, as well as getting a new service for the new place. Fast forward two months, and I get a bill for the landline at the old place, filled with calls after I moved out. [06:00] StevenK: win [06:01] lifeless: I rang up and said "Please explain" and was told that they "forgot" to action my cancelation [06:01] As way of apology, they wrote off the entire bill, which had one charge for the new landline on it. [06:02] wallyworld_: So the TALES won't even show the portlet if there are no visible super teams [06:02] StevenK: yes, i came to that conclusion too so i think it's ok [06:03] StevenK: for a "proper" unit test, the super_teams() property on the view object really should be tested [06:04] rather than relying on the template logic to indirectly test it [06:04] wallyworld_: I'm happy to add an assert for that [06:04] self.assertEqual([], view.super_teams) effectivelty [06:04] *effectively [06:04] StevenK: that would be great; hopefully there's an existing unit test for the view object you can add to simply [06:05] ah, yes, that works too [06:06] StevenK: r=me [08:41] wgrant: P-a-s> ah, OK, thanks. Maybe if I get some time over the holidays ... [08:42] cjwatson: That's likely the only way it's going to get fixed unless I get bored, yeah. [08:42] :/ [08:57] good morning === nhandler_ is now known as nhandler [09:10] Mornin; [09:11] oh, I fail at typing [10:14] allenap: ndt deployment request underway. Liam is on it. Thanks for dealing with that branch. [10:15] jtv: Tip top, ta :) === gmb changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: gmb | Critical bugtasks: 3*10^2 [11:36] oh my, I didn't realise that maintenance-check.py relied on http://people.canonical.com/~ubuntu-archive/germinate-output/ [11:37] I think I'll need to convert that to python-germinate as well for sanity and testability [12:30] bigjools: is it possible that r11088 fixed bug 599412? It looks as though it ought to have done [12:30] <_mup_> Bug #599412: populate-archive --component main doesn't work

< https://launchpad.net/bugs/599412 > [12:35] cjwatson: yes, the commit msg says so :) [12:35] * bigjools fixorates [12:36] refers to bug 600165 instead, actually, so unnoticed dup [12:36] <_mup_> Bug #600165: COPY archive creation ignores the specified component

< https://launchpad.net/bugs/600165 > [12:37] yeah [12:37] thanks for noticing [12:37] * cjwatson has been looking through soyuz bugs for things that might improve Ubuntu's life that are accessible to me to fix [12:38] sounds like you need a rotation :) [12:39] the thought has crossed my mind, but I think I want to remain focused on things specifically beneficial to Ubuntu rather than LP as a whole; plus Steve might object :) [12:39] might consider it in a year or so [12:48] cjwatson: I won't object, but I know you don't mean me. :-) [13:11] StevenK: actually I was wondering why you would ever object! [13:11] So a good thing you said it. [13:18] * cjwatson tests germinate 2.3 on mawson and confirms that the only differences are as expected [13:19] so I've followed up to that ticket to say that it's OK to upgrade cocoplum/germanium [13:20] jtv: can https://code.launchpad.net/~cjwatson/launchpad/refactor-cron-germinate/+merge/84624 be Status: Approved as well as having your Approved review? It's still waiting on a buildbot upgrade before we can land it, but apart from that ... [13:24] cjwatson: coming [13:25] cjwatson: done [13:29] I think I need to rollback 3 non-sequential revisions :( [13:30] jtv: ta [13:33] bigjools, wgrant: care to review? https://code.launchpad.net/~jtv/launchpad/bug-903688/+merge/85485 [13:40] jtv: I can [13:40] That'd be great, thanks [13:59] Anyone know why I would get this error during "make schema" on a db-devel branch? duplicate key value violates unique constraint "launchpaddatabaseupdatelog_pkey" [14:03] someone broke something? [14:03] I hope no one broke sampledata. [14:04] nigelb: maybe I did — don't know. [14:04] But I re-generated the updated sampledata based on db-devel sampledata, and it doesn't help. [14:06] benji: hi [14:06] hi jelmer [14:07] benji: Are you still working on bug 808930 ? [14:07] <_mup_> Bug #808930: Timeout running branch scanner job < https://launchpad.net/bugs/808930 > [14:07] I've got a bug fix in that area, and I'd like to make sure our changes don't clash. [14:07] jelmer: gmb has taken the helm of that one [14:07] * benji goes to fix the assignee in LP. [14:07] gmb: Hey! [14:07] benji: thanks [14:08] np [14:08] jelmer: Hi. I'm only just getting up to speed on this bug, so it may well be that I have to tap on benji's shoulder a couple of times. But anyway. [14:09] gmb: ok [14:09] gmb: I've got a fix for the branch scanner which should at least make the bzr part of things no longer O(size-of-branch-history) [14:10] gmb: that should help with the bug, but it will also likely clash with any changes you've already made [14:10] jelmer: Okay. So, I'd be inclined to tell you to get your branch landed; I'm not ready to land anythign yet, so I'm happy to clean up any clashes. [14:11] gmb: Great, thanks. [14:11] Anyone know what would make a "make schema" on a db-devel branch violate unique constraint launchpaddatabaseupdatelog_pkey? [14:13] deryck: Do you think now is the right time to generalize ListingNavigator as we discussed with wallyworld? [14:14] abentley, jumping on call…. give me a minute to think about that. [14:14] deryck: sure. [14:21] abentley, I'm sorry, but I'm blanking on remembering the discussion with wallyworld_. is this an email discussion? [14:22] deryck: Yes. Let me see if I can dig up the subject. [14:22] deryck: "batch navigation question" [14:23] * deryck is looking at email [14:24] abentley, ok, right. I absolutely think now is the time to do that work. [14:24] deryck: cool. [14:26] there are a couple minor bugs we still need to fix, but these are fairly shallow. I may see if rick_h_ can be enlisted for this, to keep you free for this. [14:27] (21:21:48) stub: jtv: Hmm... might need to add a step to reset the sequence. [14:27] (21:22:19) stub: jtv: The value of the sequence would have been set from production with the new baseline? [14:27] (21:24:45) stub: jtv: Although 'make schema' shouldn't care because the table will be empty... [14:27] (21:25:24) stub: jtv: Have you rebuilt sample data and ended up with the contents of launchpaddatabaseupdatelog in it? That would make it explode (and would be a bug - need to exclude that table from sampledata too, along with launchpaddatabaserevision) [14:28] wow. I did guess right. sampledata has some brokeness. [14:30] stub: yes, on two occasions I did “make newsampledata” and both times got 1 record for launchpaddatabaseupdatelog per database. [14:30] I'm about to try it with an unmodified db-devel schema. [14:31] thought the sequence reset magic would take care of it? [14:32] Frankly I can't even find where the table gets created. [14:32] Whoops — the sampledata I build from db-devel is broken. [14:33] jtv: The table is in the db baseline - launchpad-2209-00-0.sql [14:34] Looked there. It's basically empty. [14:34] I figured the guts had moved somewhere else. [14:36] stub: broken baseline? [14:36] I thought the baseline used to be in that patch — but now I don't see that for 2208 either. [14:37] Ah wait — launchpad-2209-00-0.sql. I was looking at patch-2209-00-0.sql. [14:37] If you are on db-devel, 2208 shouldn't exist [14:37] yer [14:39] I was just cross-checking with devel. [14:42] stub: fwiw I also looked for launchapddatabaseupdatelog in the sample data for devel & db-devel and did not find any mention. [14:44] * stub waits for trees to sync [14:53] bigjools: my buildfarm fix has passed soyuz & buildmaster tests. Think that's enough for a landing? [14:53] jtv: yes [14:53] Yee-haw. [14:53] well - code perhaps [14:54] OK, running that too. [15:01] jtv: So with a fresh tree and make schema, I get LaunchpadDatabaseUpdateLog with one entry with id 1 (from patch-2209-00-2.sql) and nextval('launchpaddatabaseupdatelog_id_seq') is 2. [15:02] I get the entry; haven't tried the sequence. [15:02] Presumably that's the part that's wrong. [15:02] But didn't you say that the table shouldn't be in the sample data at all? [15:04] jtv: There is no need for it to be there. [15:04] Then how did it get there? [15:05] jtv: I neglected to add it to the blacklist filter in database/schema/Makefile. [15:05] Is that something you could fix at the moment? [15:05] sure [15:06] jtv: So patches get applied, then we load sampledata. And if the sampledata contains rows they will conflict with any created by upgrade.py [15:06] bac: gary_poster is it time to discuss milestones? === Ursinha is now known as Ursinha-nom [15:07] sinzui: yes, sorry, our call ran long. i'll skype you now [15:07] stub: thanks for working it out. Got branches blocked on this, and tomorrow's my last day for the year. [15:09] http://paste.ubuntu.com/769038/ should be the fix [15:09] jtv: Want me to land that? [15:10] gmb: actually, looking at the only OOPS for bug 808930 that I can find, it seems like that is in the access of the bzr graph [15:10] <_mup_> Bug #808930: Timeout running branch scanner job < https://launchpad.net/bugs/808930 > [15:10] stub: yes please, assuming it's correct. :) [15:10] stub: is the whitespace you removed significant? [15:10] jelmer: benji's theory, AIUI, is that the OOPS is a death-by-SQL problem. [15:11] jtv: You can apply that locally and rebuild your sampledata while waiting to confirm (and even revert the change afterwards - the problem with your branch is the generated sampledata and you can land it without the makefile fix) [15:11] Right. I'll try that. [15:11] jelmer: So I'm not sure whether your fix will help or not... [15:11] gmb: yeah, that seems like the most likely cause indeed.. storing a giant (HUUUUGE) graph in a SQL table seems like a bad idea [15:11] jtv: Seems to be working. I'll do a self approved landing now. [15:12] jelmer: Ssssh, you'll make whoever came up with that idea feel silly.... [15:12] bac: https://launchpad.net/glade/3.10 [15:12] bac: https://launchpad.net/grub/grub2 [15:13] gmb: IIUC it's that way because that's how bzr originally behaved [15:14] Yeah, I think that's the case. [15:15] gmb: I'm sure you've seen https://dev.launchpad.net/Code/BranchRevisions ? [15:16] jelmer: Yes, I had. (I had repressed it) [15:16] hehe [15:16] bac: lifeless reported this https://bugs.launchpad.net/launchpad/+bug/644977 [15:16] <_mup_> Bug #644977: ProjectMilestone is inconsistent, confusing ui, can we just delete it?

< https://launchpad.net/bugs/644977 > [15:18] benji: ping, have some time to do a voice chat on an api bug: https://bugs.launchpad.net/launchpad/+bug/808952 [15:18] <_mup_> Bug #808952: NoCanonicalUrl using api to fetch bug comments < https://launchpad.net/bugs/808952 > [15:18] gmb: Got time for a tiny review? https://code.launchpad.net/~allenap/launchpad/bugnomination-timeout-bug-874250-heat-death/+merge/85497 [15:18] allenap: Sure thing [15:18] Ta [15:18] rick_h_: sure. Skype? [15:19] benji: sure, mitechie is my username [15:19] rick_h_: calling [15:24] gmb: Do you have time to review that avoid-revision-history branch? It should now be up at https://code.launchpad.net/~jelmer/launchpad/avoid-revision-history-2/+merge/85501 [15:25] jelmer: I'll take a look once I've finished with allenap's. [15:29] stub: I seem to have working sample data now, thanks [15:30] np. by branch has landed too. === Ursinha-nom is now known as Ursinha [15:56] bac: https://launchpad.net/launchpad-project/+milestones is a mess [15:56] while your idea is about declaring them to prevent the cruft from appears [16:05] gmb: Merci [16:06] jelmer: De rien. === gmb changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 3*10^2 [16:26] bigjools: lot of blockers on the deployment report tonight. If we're going to get my fix out, looks like we'll have to cowboy. [16:26] sinzui: regarding vouchers, the API they provide is not showing you having anything, which is consistent with the db dump neil provided. so it looks like a problem between the shop and salesforce [16:27] bac: I was replying to that. I was even going to take a screencap of a check out, but I cannot do that at the moment. [16:27] sinzui: i'll buy some too and see if they materialize [16:28] Maybe the ridiculous free gift has broken checkout for users that redeem vouchers [16:47] bigjools: arrrrgh. Broken test in archiveuploader. The ordering of a two-item recipients list on a notification email has changed. :( [16:47] hmmm [16:47] sounds spurious, which is worse [16:48] Oh, yes it is worse: I was accidentally running that one on devel! [16:48] lp.archiveuploader.tests.test_uploadprocessor.TestUploadProcessor.testUploadToFrozenDistro [16:53] yay? [16:56] bigjools: is that the sort of yay that conveys no joy at all? [16:56] jtv: Archeryay [16:57] Ah, _that_ yay [16:57] Absolutely correct. [17:02] deryck: I've gotten this the last two times I tried to land the inline editor stuff: +bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel [17:03] deryck: the test email comes back success, but that's the PQM test email? [17:03] deryck: sorry, bad paste https://pastebin.canonical.com/57048/ [17:03] rick_h_, you need to look at the log file attached to the email from pqm. [17:04] rick_h_, either testfix or merge conflict most likely. [17:04] deryck: my bad, totally missed the attachments [17:04] given buildnot's record, you can guess what you'll get ;) [17:05] ah, actually getting that it doesn't like my commit message. Will check it out then. Thanks, blind today [17:15] rick_h_, can you look into bug 894726? Should be trivial to linkify the tags listed. [17:15] <_mup_> Bug #894726: Tags not linked on bug listing