[00:04] <lifeless> cool
[00:07] <wgrant> lifeless: I'm slightly concerned that the LOC policy is encouraging people to put massive (multi-thousand lines of diff) unrelated changes into a single branch.
[00:07] <lifeless> reviewers should still be pushing back on that
[00:07] <wgrant> eg. spot the real change in http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/revision/15074
[00:07] <lifeless> I presume you have examples?
[00:08] <StevenK> Oh, bloody hell. That was my suggestion.
[00:09] <StevenK> wgrant: archive model changes, but I know the branch :-P
[00:12] <lifeless> so, this is an example of doctests sucking
[00:12] <lifeless> I would have made a new login_person that was better and left the old one for doctest specific usage, myself.
[00:12] <lifeless> landing it separately would have been nice indeed.
[00:13] <lifeless> wgrant: such permutations during review have happened even before the LoC thing
[00:14] <lifeless> wgrant: That specific one doesn't flag the LoC policy per se, for me.
[00:14] <wgrant> Possibly not.
[00:15] <lifeless> its a related change
[00:16] <lifeless> if it was purely unrelated I would definitely feel tweaked
[00:18] <lifeless> anyone know why we special case no-bug-supervisor situations ?
[00:19] <wgrant> In which context?
[00:19] <wgrant> Bug notifications?
[00:20] <lifeless> yah
[00:20] <cjwatson> anyone fancy a quick review of https://code.launchpad.net/~cjwatson/launchpad/remove-services-unicode-csv/+merge/101315 so I can test my landing access?  it's just removing two now-unused files
[00:20] <wgrant> lifeless: Because to do otherwise would not confuse people sufficiently.
[00:20] <lifeless> oh no whatever will we do
[00:20] <lifeless> cjwatson: don't forget to set a commit message and go via ec2 land
[00:21] <cjwatson> Oh yes, commit message.  I was going to use ec2 land, yes.
[00:21] <cjwatson> Thanks, will attempt that now
[00:22] <wgrant> rick_h: Hi, did you get a UI reviewer or Dan to look over the new email notifications?
[00:22] <wgrant> The one you added doesn't respect our normal conventions and has incorrect capitalisation in a number of places.
[00:24] <rick_h> wgrant: yes, dan has sent me some feedback I've got to incorperate
[00:24] <rick_h> I'm working with him on it while I try to get tests passing
[00:24] <rick_h> wgrant: it's not final yet.
[00:24] <wgrant> confused
[00:24] <wgrant> it landed overnight
[00:25] <lifeless> maybe flagged?
[00:25] <rick_h> it shouldn't have landed, tests have been failing nad I just pushed another ec2 run during the day today
[00:25] <rick_h> I've not seen the tests run yet
[00:25] <wgrant> http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/revision/15075
[00:25] <wgrant> [r=gmb][bug=959482] Add event hooks to send a notification email to a user whenever significant changes to their account are taking place.
[00:30] <lifeless> https://bugs.launchpad.net/launchpad/+bug/854405
[00:30] <_mup_> Bug #854405: Private bug subscriptions <disclosure> <Launchpad itself:In Progress by wallyworld> < https://launchpad.net/bugs/854405 >
[00:30] <lifeless> wallyworld: ^ could you perhaps give that a more descriptive subject?
[00:31] <wgrant> rick_h: So, if it wasn't meant to land we should probably unland it.
[00:31] <wallyworld> lifeless: sure. i'm not sure why that one is not marked as released
[00:31] <rick_h> wgrant: email hung and didn't get the notice.
[00:31] <wgrant> heh
[00:32] <rick_h> wgrant: so I screwed up, should have ec2 test vs land. If youcould let me know what's wrong that would be helpful. Dan's notes so far have been more generic
[00:32] <rick_h> wgrant: so I'm not aware of what's not to standard atm.
[00:32] <rick_h> wgrant: I'm getting kicked out of the library here in a couple of min sorry. Going to be afk.
[00:34] <lifeless> wallyworld: thanks!
[00:34] <wgrant> "irc" -> "IRC", "Freenode" -> "freenode", needs general rewording to say "if you didn't make the change" rather than "if you didn't meant to make the change", URLs should be in <> or nothing at all rather than []. I'd check existing templates to see the general style.
[00:35] <wgrant> It also seems slightly odd to not say what the new or removed email address is.
[00:35] <wgrant> And I'd prefer an assertion that there's only one changed field, rather than just dropping everything except the first one, given the security implications.
[00:36] <lifeless> totally
[00:37] <lifeless> or list all the changed fields
[00:38] <wgrant> Sure, but in the current implementation that's stated to be an impossible situation :)
[00:38] <wgrant> So it just takes the first one from the list, ignoring any others that probably aren't there.
[01:09]  * StevenK stabs layers.
[01:09] <StevenK> Awww, a Maverick EOL notice.
[01:14] <wgrant> Oh, right, 10.10.10
[01:14] <wgrant> Wasn't expecting it for a couple more weeks
[01:31] <cjwatson> So how do I go about debugging things when the EC2 instance that 'ec2 land' starts up won't accept SSH connections?
[01:32] <cjwatson> strace shows it sitting in connect()
[01:32] <wgrant> cjwatson: It'll normally retry a couple of times. Takes a while to start
[01:33] <cjwatson> Last time it timed out; this time it looks well on its way to timing out
[01:33] <StevenK> cjwatson: Gasp, you're going to land your own branches
[01:33] <StevenK> ?
[01:34] <cjwatson> If EC2 will ever work for me, yes
[01:34] <StevenK> Heh
[01:34] <StevenK> Can you use ssh to connect to the instance it has started?
[01:35] <cjwatson> No; also hangs in connect()
[01:36] <lifeless> check the ingress rules
[01:36] <lifeless> ec2 land may have misdetected your source ip address
[01:36] <StevenK> Yeah, log into AWS and check your security groups.
[01:38] <cjwatson> ah yes, you're quite right
[01:39] <cjwatson> bogus RFC1918 source addresses
[01:40] <lifeless> I see a patch to ec2 land coming up
[01:42] <cjwatson> not sure it's ec2's fault - why on earth is checkip.amazonaws.com telling me my RFC1918 address?  (how does it even know?)
[01:42] <wgrant> You're not setting an outbound X-Forwarded-For or something like that?
[01:42] <cjwatson> ah, could be a proxy, yeah
[01:43] <cjwatson> works better with http_proxy unset
[01:43] <StevenK> Heh
[01:44] <lifeless> mmm haha
[01:44] <lifeless> cjwatson: I wonder if there is a bug tracker for checkip.amazonaws.com
[01:53] <lifeless> is bug 63000 still true?
[01:53] <_mup_> Bug #63000: IBugTask permissions are not in security.py and are obtuse <lp-bugs> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/63000 >
[01:53] <cjwatson> running now, phew
[01:53] <wgrant> lifeless: Yes
[01:53] <StevenK> wallyworld: I guess https://code.launchpad.net/~wallyworld/launchpad/launchpadlib-services-974139/+merge/101349 is tied to the mail you sent to -dev?
[01:54] <StevenK> cjwatson: \o/
[01:54] <wallyworld> StevenK: yes.
[01:55] <StevenK> wallyworld: Do you want to set it to WIP if you want to wait for the discussion?
[01:55] <wallyworld> right, will do
[02:05]  * StevenK stabs buildbot. Six or seven times.
[02:12] <wgrant> StevenK: rick_h's branch conflicted with jml's.
[02:12] <StevenK> Ah.
[02:12] <StevenK> Handy.
[02:52] <lifeless> does anyone know a reason why we have UNKNOWN *and* UNDECIDED  bug statuses?
[02:54] <StevenK> I think UNKNOWN is for imported bugs?
[02:54] <lifeless> s/status/impostance/
[02:55] <lifeless> StevenK: well, thats what we use it for
[02:55] <lifeless> StevenK: but why do we have it
[02:56] <rick_h> wgrant: sorry, like I was saying, kicked out of library post LUG meeting. Thanks for the notes. Taken down to go over in the morning.
[02:56] <lifeless> we have a rule that says projects which use lp should always use undecided, and ones that don't should always use unknown (because their only bugs hsould be watches)
[02:56] <rick_h> lifeless: it does take from a list of fields, but the event is fired on one of them not all so it 'assumes' the first one. I'll add a check to it to make sure and fail otherwise
[03:04] <lifeless> rick_h: Wouldn't it have been easier to code the notification directly in
[03:07] <rick_h> lifeless: well, I was shown the license change notification stuff in subscribers at the start and took that path.
[03:07] <lifeless> I have two rules of thumbs
[03:07] <lifeless> if an event has only one user it doesn't need to be an event
[03:07] <lifeless> if you have to add special case code because you've lost context it probably shouldn't be an event
[03:07] <lifeless> rick_h: I can eyeball your branch if you like, rather than talking in generalities
[03:07] <rick_h> lifeless: well this does have three users, but you're right in the sense that it probably doesn't have to be an event.
[03:08] <rick_h> lifeless: definitely up for suggestions. It's my first real bit of code on teh zope side so learning more > *
[03:08] <lifeless> url me up
[03:09] <rick_h> lifeless: but I'm finally back from LUG dinner/meeting and it's past my bed time. Can you email me notes for the morning?
[03:09] <rick_h> https://code.launchpad.net/~rharding/launchpad/email_notice_959482
[03:09] <rick_h> lifeless: ^^
[03:16] <lifeless> rick_h: thanks
[03:16]  * wallyworld has an appointment, back in a bit
[03:58] <lifeless> wgrant: StevenK: is bug 250003 still relecant ?
[03:58] <_mup_> Bug #250003: package-cache should be optionally limited by distribution <lp-soyuz> <soyuz-core> <trivial> <Launchpad itself:Triaged> < https://launchpad.net/bugs/250003 >
[04:01] <StevenK> lifeless: If that populates DSPC and other madness -- it could be, yes. wgrant and I want to completly rip all that crap out and have DSP in the DB directly, but ETIME
[04:03] <bigjools> there's that "should" thing in a bug again
[04:03] <StevenK> Indeed.
[04:04] <StevenK> And it mentions hateful things that shouldn't have existed.
[04:05] <lifeless> bigjools: yes, there it is. I hates.
[04:05] <bigjools> the bug does not clearly state the problem
[04:06] <lifeless> indeed
[04:06] <lifeless> this is not uncommon :)
[04:06] <lifeless> I'm trying to find a bug
[04:07] <lifeless> there is a bug about showing folk that are important to a project as such
[04:07] <lifeless> in bug pages and so on
[04:07] <lifeless> there is another bug that also says this
[04:07] <lifeless> I want to dup them
[04:07] <lifeless> I can't find the former bug ><
[04:07] <StevenK> We have lots and lots of bugs. News at 11.
[04:12] <lifeless> wgrant: is bug 372643 fixed by your once-over ?
[04:12] <_mup_> Bug #372643: Import queue error display: IE7 makes it all one line <easy> <ie> <javascript> <lp-translations> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/372643 >
[04:12] <lifeless> also bug 376186 is about the most opaque I've seen today
[04:12] <_mup_> Bug #376186: private bug implicit subscription <disclosure> <lp-bugs> <privacy> <story-better-bug-notification> <ubuntu-qa> <Apport:Won't Fix> <Launchpad itself:Triaged> < https://launchpad.net/bugs/376186 >
[04:12] <lifeless> [the subject I mean]
[04:16] <wgrant> lifeless: That one is pretty transparent.
[04:16] <wgrant> It wants private bug implicit subscriptions
[04:16] <wgrant> (we'll be fixing it with disclosure)
[04:16] <wgrant> lifeless: 372634 needs to be checked in a more recent IE
[04:17] <wgrant> If it works in IE8 it's fine
[04:17] <wgrant> Since IE7 has no reason to exist
[04:18] <wgrant> rick_h: Anyway, we probably need to unland the mistaken landing. Any objections?
[04:20] <lifeless> wgrant: the /subject/ isn't transparent :)
[04:20] <wgrant> I knew immediately from the summary what the problem was
[04:21] <wgrant> Prepending 'No ' would possibly have made it a bit clearer, however.
[04:28] <lifeless> I don't understand the bug, and I've read it
[04:28] <lifeless> it says
[04:28] <lifeless> new apport bugs have u-c-u subscribed, but members of u-c-u don't get notifications.
[04:29] <lifeless> That sounds like 'the system is working but it isn't'
[04:29] <lifeless> perhaps it means 'we have muted u-c-u via an external contact address and we want folk to have to have a different subscription to get notifications, and they want structural subscriptions to work'
[04:30] <wgrant> lifeless: u-c-u deliberately doesn't imply notifications, because that would be insane.
[04:30] <lifeless> so, bug 376186
[04:30] <_mup_> Bug #376186: structural subscriptions to private bugs don't work even when the subscriber has visibility on the bug <disclosure> <lp-bugs> <privacy> <story-better-bug-notification> <ubuntu-qa> <Apport:Won't Fix> <Launchpad itself:Triaged> < https://launchpad.net/bugs/376186 >
[04:30] <wgrant> lifeless: But people who have explicitly opted into the package's bugs (through a structural subscription) don't get notified, even if they have access
[04:30] <lifeless> thats clear.
[04:31] <wgrant> Right, but bug is that private bugs don't have implicit subscriptions.
[04:31] <lifeless> no
[04:31] <lifeless> implicit subscriptions aren't a thing anywhere, they don't exist
[04:31] <lifeless> the bug is that structural subscriptions aren't working with private bugs - they shouldn't grant visibilty, but they should still grant notification.
[04:32] <lifeless> thats even the symptoms described, once you know that u-c-u doesn't imply notification
[04:33] <wgrant> lifeless: Structural subscriptions are one type of implicit subscription
[04:33] <wgrant> Others include subscriptions through duplicates, or for notification by assignment.
[04:33] <lifeless> granted
[04:33] <lifeless> bug 376186
[04:33] <_mup_> Bug #376186: implicit (e.g.structural) subscriptions to private bugs don't work even when the subscriber has visibility on the bug <disclosure> <lp-bugs> <privacy> <story-better-bug-notification> <ubuntu-qa> <Apport:Won't Fix> <Launchpad itself:Triaged> < https://launchpad.net/bugs/376186 >
[04:34] <lifeless> which isn't entirely true
[04:34] <lifeless> because we handle assignment already I think
[04:34] <lifeless> but I accept your precision; do you accept my critique of the prior subject?
[04:34] <wgrant> Assignment is handled by some very inconsistent and non-performant and broken special cases, yes.
[05:22] <lifeless> poolie: bug 660340
[05:22] <_mup_> Bug #660340: [wishlist] Bug report message editor: want some markup to make the text bold/italic <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/660340 >
[05:22] <poolie> hi
[05:23] <poolie> yup, that'd be arguably a dupe
[05:24] <StevenK> wgrant: Hai. https://code.launchpad.net/~stevenk/launchpad/information_type-vocab/+merge/101486 if you please?
[05:27] <wgrant> StevenK: Looking
[05:47] <wgrant> StevenK: Done
[05:49] <StevenK> wgrant: SimpleTerm doesn't seem to take a description, I went pawing through zope.schema
[05:49] <wgrant> StevenK: Perhaps description is of our own invention :(
[06:00] <lifeless> cjwatson: since you're spending some time on publishing things - https://bugs.launchpad.net/launchpad/+bug/616704
[06:00] <_mup_> Bug #616704: security unembargoes leads to security.u.c overload because primary archive does not have a copy of the debs <lp-soyuz> <Launchpad itself:Triaged> < https://launchpad.net/bugs/616704 >
[06:00] <StevenK> wgrant: MatchesStructure() is pretty awesome, first time I've used it.
[06:00] <wgrant> StevenK: That's the point :)
[06:01] <bigjools> we did a test helper in Maas where you can do assertAttributes(model, attr=, attr2= ...) which uses MatchesStructure
[06:07] <wgrant> lifeless: Can I nuke the 'specification' bug search order on the grounds that it's stupid and not used by the UI?
[06:08] <wgrant> (I believe it was added for a (likely false) constraint designed into dynamic bug listings, but never used)
[06:10] <StevenK> wgrant: Sort by blueprint? Oh, that sounds SO useful.
[06:10] <StevenK> s/Sort/Search/
[06:10] <wgrant> It sorts by the alphabetically first linked blueprint name
[06:11] <StevenK> Oh, I can think of ... no use case for that whatsoever. :-)
[06:11] <wgrant> (only slightly less useful than the 'tag' sort order, which sorts by alphabetically first tag)
[06:11] <wgrant> But tag is a bit harder to remove, since it's used by the UI.
[06:11] <StevenK> wgrant: I vote killing it, since it's just sounds dumb.
[06:11] <StevenK> s/'s//
[06:12] <StevenK> wgrant: And in fact, once we drop both feature flags, the entire vocab can just die.
[06:12] <wgrant> StevenK: Ah, true
[06:13]  * StevenK peers at Steam.
[06:14] <StevenK> Now Valve is doing Indie bundles?
[06:14] <wgrant> They do sometimes.
[06:14] <wgrant> There were a lot about 18 months ago
[06:15] <lifeless> wgrant: if it has no search lozenge I see no reason to keep it
[06:15] <lifeless> wgrant: (spec search order specifically)
[06:16] <wgrant> lifeless: Yeah
[06:16] <lifeless> mpt: hey
[06:16] <wgrant> tag does, unfortunately :(
[06:16] <lifeless> mpt: I am convinced that bug 522741 is a dup, but I can't find the other copy
[06:16] <_mup_> Bug #522741: Highlight comments from certain people <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/522741 >
[06:17] <lifeless> wgrant: sort by tag makes no sense to me; is it getting used ?
[06:17] <lifeless> wgrant: (e.g. what do the web logs say)
[06:17] <wgrant> lifeless: Probably only by accident
[06:17] <wgrant> But I could check
[06:17] <wgrant> But it has a lozenge, so it's not trivial to remove
[06:17] <lifeless> data >> nodata
[06:17] <lifeless> right, but you can start a discussion on the list
[06:18] <lifeless> where you can document issues like 'can't use it to find an unknown tag, because it doesn't repeat the row per-tag, just sorts with the alpha-lowest tag'
[06:39] <wgrant> StevenK: You didn't address my concern about duplication with LP.cache.context
[06:40] <wgrant> In other news, 450 line functions irk me
[07:07] <StevenK> wgrant: Bah, sorry.
[07:11] <StevenK> wgrant: I killed it.
[07:11] <StevenK> I'm going to have fun merging devel into my UI branch, given it's 35 revisions behind.
[07:35] <mpt> lifeless, I don't remember that being reported before (though I did think of bug 58670 before seeing that it was already linked)
[07:35] <_mup_> Bug #58670: Highlight comments from the reporter <easy> <feature> <lp-answers> <lp-bugs> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/58670 >
[07:39] <lifeless> mpt: hmm, I was sure there was something, ah well. I have at least cleaned up some more dross in the tracker
[08:01] <czajkowski> aloha
[08:03] <adeuring> good mooriig
[08:03] <adeuring> ...morning
[08:05] <lifeless> I need someone to translate bug 253934 for me
[08:05] <_mup_> Bug #253934: Please bring back the source info to the bug page <feature> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/253934 >
[08:05] <lifeless> what do they mean 'source info'
[08:06] <mpt> lifeless, when a bug page was viewed in the context of a source package it would contain the source package portlet. I removed it as a small step towards (hi wgrant!) making the page the same regardless of what context you were in
[08:07] <lifeless> thanks
[08:07] <wgrant> Heh
[08:08] <wgrant> I think I filed a bug in 2006 or 2007 about it being context-dependent
[08:10] <cjwatson> lifeless: well, mostly, I second comments #1 and #2
[08:10] <cjwatson> lifeless: although it occurs to me that a launchpadlib reimplementation of our current script could do a better job of reacting to -security publications without even needing to touch the security team workflow
[08:11] <cjwatson> maybe
[08:11] <cjwatson> right now it relies on the package being completely published
[08:13] <lifeless> wgrant: is zopeless buried yet ?
[08:14] <wgrant> lifeless: Apart from ZopelessLayer and its derivatives, yes.
[08:14] <wgrant> So unless it's referring to tests, the bug is a lie.
[08:14] <lifeless> bug 781014
[08:14] <_mup_> Bug #781014: View tests should probably not use Zopeless layers <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/781014 >
[08:14] <wgrant> Still present
[08:15] <wgrant> The main reason they shouldn't use it is the main reason it still exists
[08:15] <wgrant> LaunchpadSecurityPolicy vs PermissiveSecurityPolicy
[08:16] <cjwatson> lifeless: anyway, doing *something* with copy-report is on my list, since it needs to be moved off cocoplum
[08:18] <lifeless> cjwatson: I'd like to think LP has all the bits needed for that bug, just a matter of using em differently
[08:19] <cjwatson> I think that's probably true, although the changelog comparison we do in copy-report would be a bit tedious pre-publication
[08:20] <cjwatson> but it can reasonably wait until I reach this particular bit of the grand refactoring of all our tools
[08:20] <cjwatson> (which is, hopefully, resourced for Q, if secure boot doesn't entirely eat my life which would make me sad)
[08:21] <cjwatson> oh, sigh, when EC2Test says you need a publicly accessible SMTP server it really means public, doesn't it
[08:22] <wgrant> cjwatson: Everyone just uses smtp.canonical.com
[08:22] <cjwatson> yeah, changing it according to EmailSetup now
[08:22] <lifeless> wallyworld: should https://bugs.launchpad.net/launchpad/+bug/885503 be F-R?
[08:23] <_mup_> Bug #885503: Its not obvious on the UI how to choose to have all bugs reported against your project marked private by default. <bugtracker> <disclosure> <documentation> <privacy> <qa-ok> <Launchpad itself:Fix Committed by wallyworld> < https://launchpad.net/bugs/885503 >
[08:26] <cjwatson> lifeless: linked from https://wiki.ubuntu.com/FoundationsTeam/ReplaceArchiveAdminShellAccess so I don't forget
[08:27] <lifeless> cjwatson: thanks!
[08:28] <lifeless> mpt: hah - bug 251479
[08:28] <_mup_> Bug #251479: bug pages should list the published versions <feature> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/251479 >
[08:31] <mpt> lifeless, so if people still want that, and while we still have multi-task bug reports, the challenge then would be to work out how to present it sensibly no matter how many packages are there
[08:31] <lifeless> mpt: I've suggested in the bug to have the expander that currently shows the old style form, show details about the context.
[08:31] <mpt> good idea
[08:32] <wgrant> No no no
[08:32] <wgrant> Don't encourage making multi-task bugs more workable
[08:32] <wgrant> Introduce obstructions to their functionality so we can better justify their abolition :)
[08:41] <lifeless> I suspect we could close every bug with 'should' in the title with no degradation of the LP bug tracker
[08:46] <lifeless> wgrant: you might want to check bug 415223 and see if its still broken, after all the subscription rework
[08:46] <_mup_> Bug #415223: "Subscribed by Some Person" tooltip after inline subscription is wrong <lp-bugs> <story-better-bug-notification> <Launchpad itself:Triaged> < https://launchpad.net/bugs/415223 >
[08:46] <wgrant> lifeless: That work never happened :)
[08:56] <nigelb> /ws/ws 20
[09:08] <lifeless> wgrant: did you end up nuking lazr.restfuls representation cache ?
[09:09] <wgrant> lifeless: No, just the LP integration
[09:10] <lifeless> more LoC just hanging around
[09:16] <lifeless> bigjools: why did you keep bug 613642 open given Ubuntu saying 'no never' ?
[09:16] <_mup_> Bug #613642: PPA pages have two different sets of instructions for adding them, rather than providing a button <doc> <lp-soyuz> <ppa> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/613642 >
[09:41] <jml> do I need to take any action to deal with my buildbot rejection?
[09:42] <nigelb> jtv: Everything okay out there?
[09:43] <jml> Hmm.
[09:43] <jml> I see no one has fixed it.
[09:43] <jtv> Hi there nigelb!
[09:43] <jml> So I guess that means "yes".
[09:43] <nigelb> jtv: Ohai. Context of that question - earthquake!
[09:43] <jtv> jml: hi there you too.  Buildbot problems?
[09:43] <jtv> nigelb: Just heard about it.  Didn't notice it.  Mind if I go private?  Don't want to distract the channel from Jono's problem.
[09:43] <nigelb> oh sure
[09:43] <lifeless> rick_h: I have added a review to https://code.launchpad.net/~rharding/launchpad/email_notice_959482/+merge/99995
[09:44] <lifeless> gmb: you may want to read my comment on it too, as you reviewed it initially ^
[09:44] <jml> jtv: yeah, a submtted branch failed. wgrant said earlier it was a conflict, but I can't tell if someone has already addressed the issue.
[09:46] <bigjools> lifeless: I missed your ping earlier and now I switch clients, what did you want?
[09:47] <wgrant> jml: It seems that rick_h inadvertently landed a branch that was not ready
[09:47] <wgrant> jml: And, unrelatedly to that, it conflicted with your ignored = branch
[09:47] <wgrant> Well, not a bzr conflict.
[09:47] <jml> wgrant: yeah, I understand.
[09:47] <wgrant> But some tests that it added are broken
[09:47] <lifeless> bigjools: there is a bug 613642 , but AIUI Ubuntu have said 'we do not want just-a-button for PPAs'
[09:47] <_mup_> Bug #613642: PPA pages have two different sets of instructions for adding them, rather than providing a button <doc> <lp-soyuz> <ppa> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/613642 >
[09:47] <wgrant> I was hoping to talk to rick_h to get that branch reverted
[09:47] <wgrant> But he probably went to sleep
[09:48] <lifeless> bigjools: you said in the bug you were keeping it open because it was clear, but as Ubuntu don't want it, I'm not sure why clarity is a reason to keep it open/.
[09:48] <jml> wgrant: OK. Maybe it's a good idea to fall back to asynchronous communication?
[09:49] <bigjools> lifeless: I'm sure I had a good reason but IBF if I can think of it now
[09:49] <wgrant> jml: I intend to talk to him when he comes online in a couple of hours.
[09:49] <lifeless> bigjools: I'll leave it for now, let your brain sleep on it
[09:49] <bigjools> lifeless: I'd be happy to close it I think
[09:49] <jml> wgrant: ok.
[09:49] <lifeless> bigjools: would you lke me to click the button for you ?
[09:50] <bigjools> lifeless: done :)
[09:51] <lifeless> \o/
[09:51] <lifeless> I've been procrastinating on allhands.c.c with this
[09:59] <jml> procrastination, is the answer, procrastination, doing it later! dig it.
[10:00] <nigelb> Quick question - also probably stupid question - is there a way I can run LP on OS X?
[10:00] <lifeless> virtualbox
[10:01] <nigelb> Aww. ok. that's what I'll do then.
[10:01] <lifeless> in principle you can run it natively, yes
[10:01] <wgrant> It's probably possible to run LP directly on OS X, as long as you have libapt and the like
[10:01] <lifeless> but frankly it would basically be a nontrivial time investment for no reward
[10:01] <wgrant> But it hasn't been done since 2005/2006.
[10:02] <nigelb> lifeless: Yeah, that's what I was not sure about.
[10:02] <nigelb> The good thing is I can let rocketfuel take over the virtualbox.
[10:02] <nigelb> So it should be trivial at that end.
[10:03] <lifeless> I do all my dev in lxc
[10:03] <wgrant> Me too
[10:03] <lifeless> e.g. I don't even run LP on Ubuntu directly
[10:03] <wgrant> LXC probably doesn't run on OS X, though :)
[10:03] <lifeless> some porting required
[10:03] <nigelb> wgrant: Damn. I was hoping it would work.
[10:04] <lifeless> nigelb: how much memory does your machine have?
[10:05] <nigelb> lifeless: 2 GB *cough*
[10:05] <lifeless> nigelb: so, run a server install, no x or display manager
[10:05] <wgrant> i386, not amd64
[10:05] <lifeless> you'll need the X client
[10:05] <lifeless> ssh into the vm to do stuff
[10:06] <lifeless> you can use a native X server if you want to run up firefox etc within the vm
[10:06] <nigelb> I wanted to setup a headless VM
[10:07] <nigelb> and then hit it from outside
[10:07] <nigelb> that probably needs some hacking to get the domains right.
[10:07] <lifeless> its documented on the wiki
[10:07] <nigelb> I have a few LP MP/bugs that I want to close.
[10:07] <nigelb> oh cool. this should be fun.
[10:07] <lifeless> (naturally enough, because thats how everyone developing with LXC gets at their dev instance)
[10:08] <nigelb> Oh right.
[10:08] <lifeless> I really need a 'this will make wgrant happy' template for bugs
[10:08] <nigelb> heh
[10:09] <wgrant> lifeless: Oh?
[10:09] <lifeless> bug 978768
[10:09] <_mup_> Bug #978768: read-only mode code is now dead code <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/978768 >
[10:09] <wgrant> Hah
[10:09] <wgrant> That will make me slightly sad, actually.
[10:09] <lifeless> oh?
[10:09] <wgrant> Although maybe the current implementation is not worth keeping, I guess.
[10:09] <lifeless> the current implementation is not at all what you have advocated for
[10:09] <wgrant> Indeed
[10:10] <wgrant> It's also horribly buggy.
[10:10] <lifeless> so, we should toss it.
[10:11] <lifeless> *if* we go for a restricted, real-time, no-writes-permitted thing, it would need to be a lot leaner and more reliable to be better than FDTW
[10:11] <wgrant> Yep
[10:14] <poolie> lifeless, ok, markdown baby tossed
[10:14] <lifeless> its a bit sad, but perhaps someone will pick it up
[10:15] <poolie> maybe we will finish it saturday
[10:16] <poolie> it's not that much more actual code but it takes some chasing to get it landed and qa'd
[10:19] <poolie> lifeless, gc-ing it after 2 months makes sense
[10:26] <rick_h> wgrant: sorry, yes went to bed. I've got to get hte boy to day care and I can look at the rollback process.
[10:27] <rick_h> lifeless: thanks for the review. I did discuss the code LoC increase with deryck and it was thought that with some previous JS changes and hte fact that this is a hot security issue that getting out faster was better at the moment
[10:28] <wgrant> rick_h: Hm, wasn't expecting you for another 2.5 hours anyway :)
[10:28] <rick_h> wgrant: ok, well should be < 1hr. Sorry about the builtbot blockages
[10:28] <lifeless> rick_h: its the overall thing we look for, but the absence of discussion in the review is a red flag
[10:29] <wgrant> rick_h: Great.
[10:29] <lifeless> rick_h: it either means it was done out of band, which is ok, or wasn't considered, and an external party cannot tell:)
[10:31] <rick_h> lifeless: right, I should have noted the discussion in my MP, sorry about that.
[10:32] <lifeless> rick_h: nevertheless, it can be much smaller ;)
[11:22] <wgrant> :(
[11:22] <wgrant> Someone just registered a few dozen distinct imports under kdemultimedia
[11:24] <wgrant> Ah, only a dozen, just looked like a lot more
[11:25] <jelmer> wgrant: that would be the project neon folks
[11:26] <wgrant> So it seems
[11:26] <wgrant> That is even more worrying
[11:26] <wgrant> As we're pushed for buildd time already
[11:32] <rick_h> wgrant: should this back out be sent through ec2 then? or just pqm submit?
[11:32] <wgrant> rick_h: pqm-submit
[11:33] <rick_h> with [rollback=15075] in the commit message, is there anything else I need to make sure is in there?
[11:33] <wgrant> Nope, just [r=foo][rollback=bar], where foo is usually yourself
[11:34] <rick_h> thanks
[11:35] <czajkowski> wgrant: see over there --->
[11:40] <rick_h> wgrant: oh, need [testfix] as well?
[11:41] <StevenK> rick_h, wgrant: I was about to lp-land my vocab branch. Shall I wait until your rollback lands?
[11:42] <wgrant> rick_h: Ah, yeah, you'll need testfix since buildbot finished with the broken branch
[11:42] <rick_h> is there a web ui view for pqm aside from the deployment report I can monitor for this hitting?}
[11:42] <wgrant> rick_h: pqm.launchpad.net
[11:42] <wgrant> But it'll only be there for ~45seconds
[11:43] <rick_h> wgrant: ah ok
[11:43] <rick_h> I'll keep pushing my email. offlineimap ftw except when you want an email *NOW*
[11:50] <rick_h> bah, testfix has to be the first one, *sigh*
[11:51] <rick_h> ok, rollback success from pqm
[11:51]  * rick_h crosses fingers it works out from here
[11:53] <StevenK> rick_h: You can't really self-review, you're still being mentored. But I think we can let it slide.
[11:53] <rick_h> StevenK: thanks, if it makes you feel better jcsackett has started looking at getting me out of mentorship :)
[11:53]  * StevenK makes a note to fix that on the call tomorrow. :-P
[11:54] <rick_h> doh
[11:54] <StevenK> Haha
[11:54] <nigelb> it's a trap :P
[12:40] <jml> gary_poster: let me know if https://code.launchpad.net/~jml/testtools/forward-current-tags/+merge/101538 addresses your issues with testtools tag support.
[12:49] <gary_poster> jml, cool will review thanks.  benji would also review, as he's been doing a lot of the work in the area, but he has internet connectivity issues today.
[13:02] <gary_poster> jml, that looks very good to me in terms of subunit contract and in terms of the tag context approach.  typo line 477 of diff: restorted. I don't understand meaning of Python27Contract subclass and have not explored, but it implies to me that this the contract will not be expected/maintained for 2.6.  Do I understand correctly?  If so, why would we only want this in 2.7?  testresult.real.ThreadsafeForwardingResult a
[13:02] <gary_poster> lso does not conform to subunit tag contract correctly, but we have work in that direction, as well as another test result implementation, so we can run with your branch once it is landed and hopefully use your testcases to test those test result classes
[13:04] <jml> gary_poster: Python27Contract is the contract for stdlib unittest.TestResult in Python 2.7
[13:04] <jml> gary_poster: and likewise for 2.6
[13:04] <gary_poster> jml, but I thought your MP said that tags were not in 2.7...rereading
[13:04] <jml> gary_poster: the previous tests implied that Python 2.7 unittest.TestResult had tags()
[13:05] <jml> gary_poster: and thus our test double object had tags()
[13:05] <jml> gary_poster: but that was wrong, making it a bad double.
[13:06] <jml> gary_poster: I'm also fairly sure that this branch fixes ThreadsafeForwardingResult to conform to subunit tag contract.
[13:06] <gary_poster> jml, right, ok.  So...TagsContract will be expected to be followed in both 2.6 and 2.7, right?  That's my only concern, really, despite the fact that I'm still in a bit of a fog about the intent of that subclassing (reading more code would help, I suspect(
[13:06] <jml> gary_poster: the subclassing is sort of a kludge for not using testscenarios
[13:07] <gary_poster> Threadsafe...: really!  lemme look again
[13:07] <gary_poster> subclassing: ok
[13:07] <jml> gary_poster: by inserting TagsContract into the tree where we did, that tests against TSFR.
[13:11] <gary_poster> jml, ok cool.  I believe ThreadsafeForwardingResult still has some issues, but perhaps they are mitigated somehow.  benji and/or I will review later.  However, _not_empty_tags is simply wrong AFAWCT (minimally should be boolean or, not boolean and, and arguably should be "bool(tags[0] - tags[1])" from some kind of purity perspective).  Similarly, _add_result_with_semaphore reverts the _global_tags at the end of the
[13:11] <gary_poster> function, which we believe is a typo/thinko
[13:12] <jml> gary_poster: oh right, the forwarding might well be busted. I don't understand it, tbh.
[13:12] <gary_poster> As I said, we've been staring at this for a while, so we'd be happy to review again once this has landed (especially if it lands soon)
[13:12] <gary_poster> (review the forwarding bits I mean)
[13:13] <jml> gary_poster: I was sort of hoping that making TagContext would have helped me understand / get rid of it, but no, not really :\
[13:13] <gary_poster> heh
[13:13] <jml> gary_poster: I should have been more insistent at the code review point.
[13:13] <gary_poster> jml, you can be insistent when we propose some changes to it, and that will help everything along :-)
[13:14] <gary_poster> We'll see if we can use TagContext in there too; I suspect we can.
[13:14] <jml> gary_poster: thanks :)
[13:15] <gary_poster> jml, any idea how soon this will land?  I'll suggest to benji that we work from your branch if it won't be within an hour or so
[13:19] <jml> gary_poster: I'll try to get another testtools person to review
[13:20] <gary_poster> cool jml, thanks
[13:22] <jml> gary_poster: oh. oops. lifeless is the only other person with commit access.
[13:22] <gary_poster> :-)
[13:24] <abentley> rick_h: Your r15075 broke buildbot.  You added login_person calls to doctests, but r15074 makes login_person return a value, which breaks doctests.
[13:25] <rick_h> abentley: it's been rolled back this morning
[13:25] <rick_h> abentley: I replied to the email, I've got work to do on it still. Should hopefully fix soon
[13:25] <abentley> rick_h: Ah, okay.  The mail was more about buildbot failing to notify you.
[13:26] <rick_h> abentley: ok, just grabbed one of the failure emails to reply to this morning.
[13:29] <abentley> rick_h: We're talking about different mails.  I just sent a mail complaining about buildbot blaming *me* for this.
[13:30] <deryck> abentley, adeuring, rick_h -- can one of you paste me the link for the standup hangout?
[13:30] <abentley> deryck: https://plus.google.com/hangouts/_/extras/talk.google.com/orange-standup#
[13:30] <deryck> thanks!
[13:41] <abentley> https://dev.launchpad.net/PolicyAndProcess/MaintenanceCosts
[13:50] <jml> flacoste: btw, it would be great if the MaintenanceCosts doc included or linked to some helpful suggestions on what to do to reduce maint costs to pay for a patch.
[13:51] <flacoste> jml: you mean like a task list?
[13:51] <jml> flacoste: yeah
[13:52] <flacoste> indeed, that's a good idea
[13:52] <jml> flacoste: but not necessarily exhaustive
[13:52] <flacoste> right
[13:52] <jml> e.g.
[13:52] <flacoste> just a getting started
[13:52] <jml> - remove sample data
[13:52] <jml> - convert a doctest to a unittest
[13:52] <jml> that sort of thing
[13:52] <flacoste> ah, so more "principles" based
[13:53] <flacoste> rather than fix bug 12345
[13:53] <_mup_> Bug #12345: isdn does not work, fritz avm (pnp?) <isdnutils (Ubuntu):Fix Released by doko> < https://launchpad.net/bugs/12345 >
[13:53] <flacoste> or bug 123456
[13:53] <james_w> both would be good
[13:53] <_mup_> Bug #123456: podcast crashes amarok <Amarok:Invalid> <xine-lib (Ubuntu):Fix Released> < https://launchpad.net/bugs/123456 >
[13:53] <jml> flacoste: well, that might be nice too.
[13:53] <jml> flacoste: basically, something to get someone started who isn't heavily involved in the code-base and feeling the costs.
[13:54] <nigelb> Er, since when did we have a reduce LoC mission?
[13:54] <cjwatson> Since 2012-02-10.
[13:54] <nigelb> Ah, that's why it felt new.
[13:54] <nigelb> I did wonder, I hadn't heard of this when I was actively writing code.
[13:54] <cjwatson> https://lists.launchpad.net/launchpad-dev/msg08923.html
[13:54] <nigelb> Also. Should learn to scroll. That info was right on the page. :|
[13:55] <abentley> jml: We could also have a list of dead code, but that raises the question "why not just delete it now?"
[13:56] <jml> abentley: well, why not?
[13:56] <cjwatson> https://lists.launchpad.net/launchpad-dev/msg08903.html had some specific suggestions from lifeless
[13:56] <abentley> jml: Because if we save it up, then we don't have to work so hard later to balance a LOC addition :-)
[13:57] <cjwatson> If people start saving things up, the policy is arguably counterproductive ...
[13:57] <jml> right
[13:57] <abentley> cjwatson: Yes, therefore the smiley.
[13:57] <jml> abentley: is there a way to discover dead code?
[13:57] <nigelb> Hrm, I'm curious, as an external contributor, how can I help? Because most of my MPs were adding code. Not deleting them. Not sure I know enough about Lp to delete code.
[13:58] <cjwatson> abentley: fair enough, it can be hard to tell
[13:58] <cjwatson> jml: https://bugs.launchpad.net/launchpad/+bug/420338 ;-)
[13:58] <_mup_> Bug #420338: Tool for identifying dead code <build-infrastructure> <feature> <lp-foundations> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/420338 >
[13:58] <abentley> jml: Nothing foolproof, but checking the coverage of the test suite would give hints.
[13:58] <cjwatson> nigelb: I've been doing a fair bit of deletion as an external contributor
[13:58] <jml> nigelb: yeah, likewise. that's what started off this conversation ;)
[13:59] <abentley> jml: In some cases, though, the test suite is the only caller.
[13:59] <nigelb> cjwatson: *cough* you know more about LP :)
[13:59] <nigelb> jml: Ah!
[13:59] <cjwatson> nigelb: in my case it's just come down to intuition ("hmm, that looks a bit crufty") and grep to confirm
[13:59] <jml> nigelb: the only way to learn is by randomly deleting stuff.
[13:59] <nigelb> jml:  Or turn into StevenK :D
[13:59] <jml> cjwatson describes it better.
[14:00] <jml> nigelb: please don't. one is enough.
[14:00] <nigelb> haha
[14:00] <nigelb> I actually would love to see tagged bugs or something.
[14:00] <nigelb> If there's low hanging fruits
[14:00] <cjwatson> there's the tech-debt tag, which has some useful ideas
[14:00] <cjwatson> although with a wide range of difficulty
[14:01] <jml> oh yeah, that one.
[14:01] <nigelb> I should resucitate my ubuntu laptop to try this out.
[14:04] <sinzui> jcsackett, you make a good point about the Ubuntu bug supervisor
[14:05] <wallyworld> sinzui: hello
[14:05] <wallyworld> bug 978212
[14:05] <_mup_> Bug #978212: Sharing batch navigation shows ugly 404 error. <disclosure> <ui> <Launchpad itself:In Progress by wallyworld> < https://launchpad.net/bugs/978212 >
[14:05]  * jml considers doing a test run with coverage.py
[14:06] <sinzui> jcsackett, The ubuntu bug supervisor is not subscribed when the private bug is created, apport is the only party that can access it. When a user changes the bug to private, the ubuntu bug supervisor is being subscribed?
[14:07] <wallyworld> sinzui: it's caused by the PillarNavigationMixin added for the sharing details page. the mixing processes traversal of xxx/+sharing/name
[14:07] <wallyworld> sinzui: but the batching js sends urls like xxx/+sharing/++model++ and the navigation mixin gets confused
[14:08] <wallyworld> sinzui: i have a fix but i'm not happy with it. i'd rather change the url for the sharing details page to xxx/+sharingdetails/name
[14:08] <jml> sinzui: want to have a call w/ james_w & I today?
[14:08] <sinzui> wallyworld,  I think We want to extend the @stepto. The URL looks natural...if I hack the URL I get a 404
[14:09] <wallyworld> sinzui: the url looks natural but what is sent includes the ++model++
[14:09] <wallyworld> sinzui: my lame fix which does work is https://pastebin.canonical.com/64098/
[14:10] <sinzui> wallyworld, I think that is the correct fix...the application should not dictate the URL
[14:10] <wallyworld> sinzui: the browser location doesn't show the ++model++ even though that's what is sent via the post
[14:11] <sinzui> jml yes. I am available starting at 16:00 UTC
[14:11] <wallyworld> sinzui: so you favour retaining xxx/+sharing/name for the sharing details view url?
[14:11] <sinzui> yes.
[14:12] <jml> sinzui: thanks.
[14:12] <jml> re dead code: http://pypi.python.org/pypi/vulture might be interesting.
[14:13] <wallyworld> sinzui: ok. is my first attempted fix which does work but i know is wrong in the right area at least?
[14:13] <sinzui> wallyworld, The underlying issue is that ++model++ which is an internal mechanism was exposed in the URL is an nasty way
[14:14] <wallyworld> sinzui: that's out of my control - it's what the js batch navigation infrastructure sends through
[14:14] <wallyworld> and it was harmless until we introduced the extra traversal stuff for the details page
[14:15] <wallyworld> i think the idea is that the js batch navigation stuff is simply asking the view to init and populate the json cache
[14:16] <wallyworld> and the ++model++ namespace is used to do this
[14:16] <wallyworld> so it seems an established pattern
[14:16] <sinzui> wallyworld, it was harmless except it was introduced in ignorance that we use @steptrough in a lot of places and we frustrate users try to make that hack work... ~team/+members and ~team/+member/sinzui is bong
[14:16] <wallyworld> sinzui: sorry, i should have typed "harmless"
[14:16] <sinzui> wallyworld, also, try putting to batch navigators on the same page as is also done on +members and you will see it is truly fuxked
[14:17] <wallyworld> sinzui: so seems like we have a form of infrastructure friction here
[14:17] <sinzui> yes
[14:18] <sinzui> wallyworld, I think the real issue is that @stepthough should ignore ++ because it is a special rule
[14:19] <wallyworld> that sounds reasonable i think, but if it ignored it i wonder if the ++model++ contract would still be met
[14:19] <sinzui> wallyworld, consider using ++oops++ on a page with an @stepthrough...it will fail
[14:20] <sinzui> wallyworld, so this issue is not new.
[14:20] <jml> flacoste: thanks!
[14:20] <wallyworld> yes, it would wouldn't it
[14:22] <wallyworld> ok. i'll get myself off to bed and revisit in the morning. thanks for providing the input. i didn't realise the issue was sort of known
[14:22] <sinzui> jml: I cannot meet until 16:30 UTC. I need to get my son from school
[14:22] <jml> sinzui: no worries. can you please ping us when you're back?
[14:23] <sinzui> fab
[14:31] <abentley> jml: Vulture looks interesting.
[14:33] <rick_h> abentley: quick ? so I wanted to pull devel with my branch to keep working on it
[14:33] <rick_h> abentley: except devel has a rollback that undoes my branch
[14:34] <rick_h> abentley: any clue on what I *should* have done?
[14:34] <jml> abentley: yeah. I just ran it. It generates warnings for methods that are part of an exposed API.
[14:34] <rick_h> I'm assuming there's a right order/process to keep my work while getting devel's changes so I can fix the tests/etc.
[14:34] <abentley> rick_h: You want to merge, not pull.  Merge up to the rollback first.
[14:34] <abentley> rick_h: Then merge the rollback, but revert all its changes.
[14:35] <rick_h> abentley: ok
[14:35] <rick_h> ty
[14:36] <abentley> rick_h: So: bzr merge -r 15076; bzr commit; bzr merge -c 15077; bzr revert ".";  bzr commit;
[14:45] <abentley> rick_h: If you've pulled devel, you can reset your branch to its old revision with "bzr pull -r 15010.1.25 --overwrite"
[14:46] <rick_h> abentley: ok, thanks
[14:47] <abentley> rick_h: np.
[14:54] <sinzui> jcsackett, I think your reply to the branch in the review hints that if we make the change I propose, Ubuntu's bug subscription behaviour will change
[14:54] <jcsackett> sinzui: yeah. the current behavior, as regards bug supervisor, wasn't changed; just cleaned up.
[14:54] <jcsackett> mind you, that doesn't mean the behavior is *right*. :-P
[14:55] <sinzui> jcsackett, Canonical noticed the change in behaviour...not ubuntu
[14:56] <jcsackett> sinzui: dig. so ... leave it? i think your right that the current behavior is actually wrong.
[14:57] <sinzui> jcsackett, I think the rules are wrong. wgrant might say the rules are right because the apport is not using the chunks of code we are changing
[14:58] <jcsackett> sinzui: well, i can sit on it till tonight, and we can talk to wgrant.
[14:58] <sinzui> jcsackett, I am going to make the review as needs information, and we can discuss this as a group
[14:58] <jcsackett> sinzui: dig.
[14:58] <adeuring> abentley: could have a look this mp: https://code.launchpad.net/~adeuring/lazr.jobrunner/slow-lane/+merge/101576 ?
[14:58] <jcsackett> i'll leave off changing it then, and not worry about landing it today.
[14:58] <abentley> adeuring: with pleasure.
[14:59] <jcsackett> sinzui: i was thinking of tackling bug 968253 today. any landmines you can think of, or is this a pretty straight forward case of just getting the banner to display?
[14:59] <_mup_> Bug #968253: +archivesubscriptions pages do not clearly state that they contain private information <disclosure> <privacy> <Launchpad itself:Triaged> < https://launchpad.net/bugs/968253 >
[15:00] <sinzui> jcsackett, I think so. You might notice that there is a related bug. the bread crumbs are missing/wrong
[15:01] <jcsackett> sinzui: i did not notice that, but it might explain why the banner isn't showing if its supposed to.
[15:02] <jcsackett> sinzui: oh, or i can take the details closed bugs issue; did y'all come to a decision on that last night?
[15:02] <sinzui> right, without the breadcrumb adapter, lots of things are subtly broken
[15:03] <abentley> adeuring: Did you consider making fallbackToSlowerLane a contextManager?  Then it could re-raise the exception itself if there was no fallback available.
[15:04] <sinzui> jcsackett, that needs research. I see some closed bugs are listed...this issue might also be about the fact that duplicates are often omitted from searchTasks()
[15:04] <jcsackett> sinzui: ah, right.
[15:04] <jcsackett> sinzui: ok, i'll go after the privacy banner/breadcrumb bit first. if that's a relatively quick resolution, i'll pry into the details page issue some.
[15:05] <sinzui> I cannot be certain at the moment but bug search is really mediocre for researching privacy issues, and team leads can not access the staging databases anymore...I have no idea which bug Lp thinks the example user has access to
[15:05] <abentley> adeuring: 119 looks like acccidental whitespace.
[15:07] <adeuring> abentley: fixed. (the whitespace) ANd no, I did not consider to define fallback/oSLowerLane as a context manager.
[15:07] <adeuring> abentley: I think we should keep the exeption handling in one place though, in runJob()
[15:08] <abentley> adeuring: cool.
[15:08] <adeuring> Otherwise, it will be hard to keep an overview that the job status is correctly updated
[15:09] <abentley> adeuring: You don't actually need RunFileJobNoResult.  You can just pass ignore_result=True to apply_async.  This works for most (all?) Task properties.
[15:09] <adeuring> abentley: ah, ok, I'll try that
[15:15] <adeuring> abentley: this does not work. With this change: http://paste.ubuntu.com/924985/ , I get again errors about messages that are stuck in rabbitmq...
[15:17] <abentley> adeuring: Wacky.  Okay, I guess leave it as is for now.
[15:17] <adeuring> yeah...
[15:19] <abentley> adeuring: It might be helpful to distinguish between the noun and verb forms of queue by using "enqueue" for the verb.
[15:19] <adeuring> abentley: yes... where exactly?
[15:19] <abentley> adeuring: I think 147?
[15:19] <adeuring> abentley: ok, I'll fix this
[15:21] <adeuring> abentley: ah, you mean the function name? that would requires more change in the main LP code...
[15:21] <abentley> adeuring: Let me look at this.
[15:23] <abentley> adeuring: My bad.
[15:23] <abentley> adeuring: We might want to change both, but we can't change just one.
[15:24] <adeuring> abentley: right...
[15:25] <adeuring> abentley: to add fun for such a name change: "grep -Ir job.*queue lib/lp" shows this result: lib/lp/answers/notification.py:            self.job = self.enqueue()
[15:30] <abentley> adeuring: why is runJob accepting a callback now?  It could just call reQueue, which would return False if no FALLBACK_QUEUE was configured.
[15:33] <adeuring> abentley: JobRunner does not know about the _task_, it knows only about the job. But reQueue is a task method
[15:33] <abentley> adeuring: Makes sense.
[15:37] <jml> am having trouble firing up an instance with ec2 demo: getting a socket timeout during the ssh connection.
[15:38] <abentley> adeuring: r=me
[15:38] <adeuring> abentley: thanks!
[15:40] <jml> any known gotchas there? anyone else able/unable to use 'ec2 demo'?
[15:41] <jcsackett> jml: i think wallyworld had issues doing ec2 demo as well. there was some discussion of using it (and possible bit-rot?) on the launchpad-dev list. look for wallyworld posting about mockups and best practices.
[15:41] <jml> jcsackett: thanks.
[15:46] <jml> jcsackett: nothing particularly helpful there, I'm afraid. I'll see if I can get 'ec2 test' to work
[15:46] <jcsackett> jml: sorry it wasn't useful.
[15:46] <jml> jcsackett: no worries
[15:46] <jml> jcsackett: I really appreciate getting any response at all
[15:46] <jcsackett> well, we try to not let this channel be completely like shouting into a hole. :-)
[15:51] <abentley> adeuring: Does this change require additional packages?
[15:52] <adeuring> abentley: in theory, no. But the tests require a package like rabbit-management or so, and this is currently not available in precise. the LP PPA needs to be updated...
[15:53] <adeuring> well, it is avaibale, but depends on the wrong version of rabbitmq-serverm IIRC
[15:53] <abentley> adeuring: Could you specify the exact package so I can run the tests, please?
[15:55] <adeuring> abentley: I _think_ it is rabbitmq-management
[15:55] <adeuring> but htere are several broken rabbitmq dependencies...
[15:55] <abentley> adeuring: Okay.
[15:59] <abentley> adeuring: Given the circumstances, I think it makes sense to make the queue check optional.  Otherwise, I won't know if any of the TestCeleryD tests start failing.
[16:00] <adeuring> abentley: like a try/except around the checks in setUp() and tearDown()
[16:00] <abentley> adeuring: Yes.
[16:00] <adeuring> ok, I'll add that
[16:01] <abentley> adeuring: thanks.
[16:03] <jml> so I'm not going to do a coverage run, because I can't launch an ec2 instance for Launchpad.
[16:12] <cjwatson> jml: last night lifeless and others helped me fix a problem I was having with ec2, which turned out to be that ec2 was detecting my IP address via a proxy which caused it to enable a private IP address in the instance's security policy, which didn't work so well.  'env -u http_proxy ec2' fixed it.
[16:13] <jml> cjwatson: interesting. thanks.
[16:13] <cjwatson> jml: you might see what checkip.amazonaws.com says
[16:13] <gary_poster> I'm stumped.  In an sh script, if dir is defined, what is ${dir##*-} ?  I can't find a value for dir that gives anything, and I have not been able to find docs on that syntax
[16:14] <cjwatson> gary_poster: strip the longest segment matching the pattern *- off the start of $dir
[16:14] <cjwatson> gary_poster: man dash, search for "##"
[16:14] <cjwatson> (or bash)
[16:14] <gary_poster> cjwatson, awesome thank you much
[16:14] <cjwatson> (to be clear, that doesn't modify $dir)
[16:15] <gary_poster> cjwatson, ack, thanks.
[16:18] <jml> cjwatson: it's giving me 10.45.43.105, which does look internal (my shell server says I'm connecting from 91.189.88.12)
[16:19] <jml> cjwatson: but http_proxy is unset
[16:22] <cjwatson> there might be a "transparent" proxy in the way I guess; anyway, that's probably the problem
[16:22] <cjwatson> worst case hack ec2 to ignore what checkip says ...
[16:22] <rick_h> anyone else getting 503 from codehosting? https://code.launchpad.net/+loggerhead/~rharding/launchpad/email_notice_959482/diff/15040/15035
[16:24] <jml> cjwatson: yeah, I was just giving that a try  :)
[16:25] <jml> if it works, I'll add an command-line option to override the public IP
[16:27] <sinzui> hi jml.
[16:27] <jml> sinzui: oh hi
[16:27] <jml> sinzui: good timing
[16:27] <jml> sinzui: which voice communication technology works for you?
[16:27] <sinzui> hangout and mumble
[16:28] <jml> sinzui: let it be hangout!
[16:42] <jcsackett> sinzui: are you around? need to bounce an idea off someone.
[16:43] <sinzui> in a meeting at the moment
[16:43] <jcsackett> sinzui: dig.
[17:06] <benji> jml: a quick question: I branched from lp:~jml/testtools/forward-current-tags and added a test (http://paste.ubuntu.com/925149/) and it failed (http://paste.ubuntu.com/925150/).  Should that have suceeded, or am I missing something?
[17:07] <jml> sinzui:         # The software center agent can view commercial archives
[17:07] <jml>         if self.obj.commercial:
[17:07] <jml>             return user.in_software_center_agent
[17:07] <jml> ViewArchive
[17:09] <jml> benji: looking...
[17:09] <jml> benji: TestThreadSafeForwardingResultContract already exists
[17:10] <jml> benji: and is tested with StartTestRunContract, which includes DetailsContract.
[17:10] <jml> benji: what's the failure?
[17:10] <benji> jml: heh, indeed it does; it's slightly different though
[17:10] <benji> http://paste.ubuntu.com/925150/
[17:10] <jml> benji: and it passes.... perhaps that's the difference? :P
[17:10]  * jml looing
[17:10] <jml> looking
[17:12] <benji> jml: ok, I /think/ that the failure is to be expected, test_addUnexpectedSuccess_was_successful is overridden in a subclass and apparently different things are expected in different contexts
[17:13] <jml> benji: ah right. yes, that's it.
[17:13] <jml> benji: sorry about the contract subclass thing. I think it would be clearer if we used testscenarios and each thing listed their contracts explicitly
[17:15] <mpt> oy crikey, Launchpad bug comments contain <table> elements with negative margins
[17:15] <mpt> Why? Why not?
[17:18] <jml> benji: there's also TestThreadSafeForwardingResult, which I think deserves some tests to show that tags are forwarded correctly.
[17:19] <benji> jml: yeah, I'm thinking the same thing, I just removed a bunch of tag-forwarding code from TestThreadSafeForwardingResult (http://paste.ubuntu.com/925170/) and the tests still passed
[17:20] <jml> benji: right. I sort of leaved that untouched because I couldn't quite grasp the intent of what's going on in TSFR
[17:20] <jml> benji: I'm guessing that it's buffering up tags() calls and then playing them back on stopTest() in a way that makes them equivalent for single isolated test.
[17:20] <benji> jml: I think some of what it does is somewhere between broken and unneccesary.
[17:21] <jml> benji: a plausible hypothesis!
[17:21] <benji> jml: that's the spirit of how it works
[17:22] <benji> jml: ok, I'll see about adding some tests for TSFR; I need something much like it and the tests can probably work for both TSFR and my new thing
[17:22] <jml> benji: cool.
[17:22] <jml> benji: what's the thing you need?
[17:24] <jml> benji: btw, as a general thing, please flag any bugs in testtools, subunit, testrepository etc. that are getting in the way or causing friction. I'm happy to work on them, am easily distracted and won't get punished for helping colleagues during work time.
[17:24] <benji> jml: heh, ok
[17:41] <benji> jml: I just noticed that you asked about what I'm working on.  Since we're doing parallel runs, we want all the tests that were run together in a given process to have a unique tag so we can figure out which tests were run together, primarily for debugging test interactions and isolation failures
[17:44] <jml> benji: ah right. and presumably the tagging is easy but when you draw the streams together the tagging info gets lost/mangled?
[17:47] <benji> jml: hmm, well, I suspect you know something I don't.  Why do you presume the tagging is easy?  The easiest way I can find to do it requires tweaking ConcurrentTestSuite to insert the thing I'm making which will add a tag that identifies the worker to the stream.
[17:50] <jml> benji: is anything more than http://paste.ubuntu.com/925211/ necessary?
[17:51] <benji> jml: perhaps that would work; does the fact that the tag is global in process_result translate correctly when the streams are aggrigated?
[17:52] <jml> benji: ahh, I see, probably not. you want to be able to tag each and every test individually.
[17:52] <benji> right
[17:52] <jml> (maybe it should, but that sounds unreasonably difficult)
[17:53] <jml> Hmm.
[17:53] <benji> I would expect that all the global tags would be added to the aggrigates stream.
[17:54] <jml> Actually, tell a lie, such an aggregator would be easier but strictly more work than your approach
[17:54] <jml> s/easier/easy/
[17:56] <jml> benji: the way I'd go about this is to make a TestResult decorator that was given some tags in the constructor and then tagged every test with those tags.
[17:56] <jml> benji: and then tweak ConcurrentTestSuite to have a result_factory or something
[17:57] <jml> benji: but that's only the thing I thought of just then. ymmv.
[17:57] <benji> jml: yep, that's the apprach I'm taking (if you consider TSFR a TestResult decorator, because my thing will be structurally similar)
[17:59] <jml> benji: hmm.
[18:00] <jml> benji: I forgot that there's a thing called TestResultDecorator in subunit/test_result.py (I thought it was in testtools)
[18:00] <jml> it *should* be in testtools, dammit.
[18:15] <jml> and there it is: https://code.launchpad.net/~jml/testtools/test-result-decorator/+merge/101621
[18:31] <jml> I think I've hit on something.
[18:31] <jcsackett> sinzui: out of meetings?
[18:31] <sinzui> jcsackett, yes sorry for not saying so last hour
[18:32] <jcsackett> sinzui: all good, gave me time to investigate some approaches. now i have an idea of what will and won't work, but i'm not sure what's best. :-P
[18:33] <sinzui> hangout?
[18:34] <jml> benji: I hate to be pulling you in different directions, but I've just uploaded https://code.launchpad.net/~jml/testtools/test-by-test-result/+merge/101622. If that and the two other branches were in trunk, I would try rewriting TSFR in terms for TestByTestResult, and would probably consider writing your thing in similar terms
[18:34] <benji> jml: looking
[18:35] <jml> benji: but I'd hate to build a thing on top of three unlanded branches -- too much WIP -- so I'm not going to attempt that until tomorrow.
[18:40] <jml> benji: I'm packing up now. Leaving in another 5m
[18:43] <benji> jml: I think I see how that might be used to do what I want.  I'll see which approach turns out better.
[18:43] <jml> benji: cool.
[18:44] <jml> benji: please be in touch via email if you have any questions.
[18:44] <jml> IRC backlog kind of works but isn't so great.
[18:44] <benji> jml: will do, thanks
[18:57] <abentley> deryck: I'm the OCR, so could you please review my branch? https://code.launchpad.net/~abentley/launchpad/celery-everywhere-3/+merge/101626
[18:57] <deryck> abentley, sure.  I'm finishing reviews today, so it may be a bit before I get to it if that's okay.
[18:58] <abentley> deryck: no problem.
[19:13] <rick_h> lifeless: morning if you get a chance I wonder if you can peek at and possibly sign off on the updated branch from last night? https://code.launchpad.net/~rharding/launchpad/email_notice_959482/+merge/99995
[19:20] <lifeless> rick_h: did you try without events ?
[19:20] <rick_h> lifeless: no, that came up in our discussion, but I went off of the comments in the MP and went for straight code dupe reduction with the current setup.
[19:21] <lifeless> ok, so its definitely a bit leaner - thanks.
[19:21] <lifeless> I'll do a spike today for a no-event version, I want to see how much better (or not) it is
[19:23] <lifeless> rick_h: e.g. lines 406 to 420 in the diff are there to deal with bad events
[19:26] <rick_h> lifeless: right, I can go that route. When it came up was when you mentioned it having '1 call place' when it had 3 so I kep the event bit to trigger.
[19:27] <rick_h> lifeless: but yea, you could probably drop those and a few lines of zcml/import with non-event method
[19:27] <rick_h> lifeless: thanks for poking at it, I'm definitely happier with things overall than I was the other day.
[19:28] <lifeless> cool. If you're not EOD and want to try a non-event version of this, great; if you are, I'll put the effort in to see what it looks like
[19:28] <lifeless> e.g. I don't want to block you, but I do want to see what it looks like before approving it :)(
[19:28] <lifeless> s/(//
[19:28] <rick_h> yea, I've got to run and get the boy from day care, but I'll be at the coffee shop hacking later tonight with friends so can chat for a little bit then if we need to
[19:29] <lifeless> righto, experiment is on me then ;)
[19:56] <abentley> lifeless: Currently, my tests start and stop a celeryd instance for each test.  I'm thinking that I should switch to using a layer, but is that the current best practise?
[20:03] <lifeless> the current general thing to do is to create a Fixture for the daemon
[20:03] <lifeless> and have a layer that brings that up and tears it down
[20:04] <lifeless> you can use the per test calls in the layer to reset the state of the daemon without restarting it, if thats desirable
[20:04] <lifeless> so yes, we still use layers, but we try to have no logic in them
[20:06] <abentley> lifeless: I have a context manager.  Is is easy to create a Fixture for a context manager?
[20:06] <lifeless> yes, Fixtures are context managers
[20:06] <abentley> lifeless: But last I heard, context managers were not fixtures.
[20:06] <lifeless> right
[20:07] <lifeless> I don't think there is an adapter today
[20:07] <lifeless> you could write one, but you might find your context manager is smaller if written as a fixture
[20:08] <abentley> lifeless: I'd be surprised if it could get any smaller.
[20:09] <lifeless> was just a thought :)
[20:11] <abentley> lifeless: I find the contextlib.contextmanager decorator makes for very readable and succinct context managers.
[21:36] <lifeless> deryck:   https://dev.launchpad.net/PolicyAndProcess/MaintenanceCosts#preview updated
[21:36]  * deryck looks
[21:39] <deryck> lifeless, yeah, that's probably good enough.  I can clarify beyond that with my squad in standups.
[21:41] <lifeless> it allows self-history, squad history, whatever
[21:41] <lifeless> I thought about saying 'recent branch'
[21:42] <lifeless> but then we're down into precise definitions
[21:42] <lifeless> I think folk will appreciate that using a 5 year old branch to offset a current LoC increase isn't really kocher
[21:44] <deryck> yeah, I think we need to just have a better sense of our squad state on this, too.  which is on me.
[22:42] <poolie> hi all
[22:44] <lifeless> hi
[22:47] <nigelb> morning
[22:47] <nigelb> this is probably my cue to figure out this sleep thing.
[23:05] <huwshimi> Morning
[23:24] <poolie> o/ huwshimi
[23:51] <timrc> Perhaps a super dumb question, but can you upload to components other than main with a ppa? I have a situation where it would be great to upload to a restricted component :)
[23:51] <bigjools> you can't