[00:00] <mwhudson> if 99.9% requests were really ok though, nagios would be having to making sqillions of requests to trip at all often
[00:01] <lifeless> wgrant: what is hard vis-a-vis shared cache?
[00:02] <wgrant> lifeless: We could go with a shared SQLite DB for now. But that probably introduces concurrency issues, and is clearly harder than None :)
[00:03] <wgrant> It also becomes a lot harder once we de-SPOF guava.
[00:03] <mwhudson> particularly, using sqlite would mean we'd have to remember it when we load balance across machines
[00:03] <lifeless> yes
[00:03] <wgrant> Exactly.
[00:03] <lifeless> a concern for historydb too
[00:03] <wgrant> Does historydb have to be shared?
[00:03] <wgrant> I don't really know how it works.
[00:03] <spm> I heard a rumour that sqlite is webscale?
[00:03] <mwhudson> yes, although that's suboptimal performance vs not working
[00:04] <lifeless> wgrant: sharing is how its faster than the prior cache
[00:04] <mwhudson> lifeless: not really
[00:04] <wgrant> :(
[00:04] <mwhudson> it's mostly faster than the other cache because it can be updated incrementally
[00:05] <lifeless> mwhudson: its faster on additional branches because it can be reused
[00:05] <mwhudson> the caches are already shared between the two instances of loggerhead running on guava
[00:05] <mwhudson> yes
[00:05] <mwhudson> i agree a cache that could be shared across machines would be better
[00:23] <wgrant> Do I want to fix ec2 land to stop adding [ui=none]?
[00:23] <lifeless> yes
[00:25] <wgrant> It's also tempting to fix the formatting of the post-bug-filing alert.
[00:30] <lifeless> I think thats tagged high not critical, though I wouldn't obeject
[00:31] <wgrant> If it were critical I wouldn't be mentioning it to see if you objected :P
[00:34] <lifeless> its really up to curtis to object or not ;)
[00:36] <thumper> StevenK: it is BranchNamespace.renameBranch
[00:36] <thumper> StevenK: it has a param rename_if_necessary
[00:46] <wgrant> lifeless: You define the set of critical bugs, and you are around, so you'll do!
[00:51] <lifeless> hah
[00:52] <lifeless> anyhow, its probably shallow, and would be lovely to have
[00:52] <lifeless> and I'm a strong believer in engineer discretion
[01:11] <wgrant> StevenK: Hi.
[01:21] <StevenK> wgrant: O hai
[01:22] <wgrant> StevenK: I have a quick review for you, if you've got a sec.
[01:22] <wgrant> https://code.launchpad.net/~wgrant/launchpad/bug-711016-no-ui-clause/+merge/48094
[01:22] <StevenK> wgrant: Did you see my earlier prod?
[01:22] <StevenK> [10:11] < StevenK> wgrant: Is http://pastebin.ubuntu.com/560772/ better?
[01:24] <wgrant> StevenK: Completely missed that, sorry.
[01:24] <wgrant> StevenK: That looks good. Did you see my diff?
[01:24] <StevenK> wgrant: Nope, so I went and changed it anyway.
[01:25] <StevenK> wgrant: That MP looks good -- with one proviso -- there's still tests that check ui=blah, right?
[01:26] <wgrant> StevenK: Yup.
[01:27] <StevenK> thumper: https://code.launchpad.net/~wgrant/launchpad/bug-711016-no-ui-clause/+merge/48094 when you can
[01:27] <thumper> StevenK: ack
[01:27] <wallyworld> StevenK: you have time today to take a look at this (after your other stuff is done) ???? https://code.launchpad.net/~wallyworld/launchpad/recipe-find-related-branches/+merge/47367
[01:29] <wallyworld> thumper: what's your verdict about the extra text in the related branches view - as per my comment to your comment :-)
[01:32] <thumper> wallyworld: I don't think the text is accurate, and is likely to be confusing
[01:33] <wallyworld> thumper: ok. i'll get rid of it
[01:40] <StevenK> thumper: I'm preparing a rollback of recipe deletion, are you fine to rs it?
[01:40] <thumper> yep
[01:47] <wgrant> You know, it would be really nice if ec2 phoned home.
[01:47] <wgrant> So we could have a full branch dashboard.
[01:48] <StevenK> Bloody hell, it's not even 1pm and it's already 36degC
[01:50] <wgrant> It's already hit the max (38°C) here.
[01:50] <wallyworld> StevenK: know what you mean. i tempted to go sit in my pool and try not to splash water on the laptop :-)
[01:50] <StevenK> Haha
[01:51] <StevenK> thumper: Bah! It's *moveBranch*
[02:12] <wgrant> lifeless: Thanks.
[02:25] <wgrant> huwshimi: Hi.
[02:26] <huwshimi> wgrant: Hey there
[02:27] <wgrant> huwshimi: I'm currently having some fun with the notification CSS.
[02:28] <huwshimi> wgrant: what kind of fun?
[02:28] <wgrant> huwshimi: I want to put some <p>s in a notification instead of straight text. But then the notification's bottom padding and the <p>'s bottom margin combine to make a huge gap.
[02:28] <lifeless> wgrant: and urls plox ?
[02:28] <huwshimi> wgrant: Ah right
[02:29] <wgrant> huwshimi: I can fix it by adding a .informational > p:last-child {margin-bottom: 0;}, but that seems bad.
[02:29] <wgrant> https://code.launchpad.net/~wgrant/launchpad/bug-654585-linkify-bug-acknowledgement is the branch.
[02:31] <huwshimi> wgrant: so, using last-child is a good thing, but it only works in modern browsers. The usual way around it is to apply a class of "last" to the last <p>.
[02:32] <huwshimi> wgrant: This is also kind of ugly, but it's how we've been solving the the problem for years.
[02:32] <wgrant> huwshimi: Even IE7 supports it, right?
[02:33] <wgrant> We already use last-child somewhere... possibly breadcrumbs.
[02:33] <huwshimi> wgrant: Actually I believe it only works in IE9. But I could be wrong about that
[02:34] <wgrant> You're right.
[02:34] <wgrant> WTF
[02:34] <huwshimi> wgrant: Indeed.
[02:37] <wgrant> Do we care enough about IE<=8 to fix it there too?
[02:40] <wgrant> Oh, IE>=7 support :first-child, but not :last-child. Lovely.
[02:43] <lifeless> sweet
[02:43] <lifeless> === Top 10 Time Out Counts by Page ID ===
[02:43] <lifeless>     Hard / Soft  Page ID
[02:43] <lifeless>      644 / 8052  Archive:+index
[02:44] <lifeless> wgrant: did I just paste three timeouts ?
[02:45] <wgrant> lifeless: Just the one.
[02:45] <StevenK> But three lines.
[02:45] <lifeless> 15:43 < lifeless>      644 / 8052  Archive:+index
[02:45] <lifeless> 15:43 < lifeless>      200 /  410  BugTask:+index
[02:45] <lifeless> 15:43 < lifeless>       91 /  194  Distribution:+bugs
[02:46] <lifeless> Also I hate the latest freenode rev
[02:46] <wgrant> Only got the first of those.
[02:46] <lifeless> *hate*
[02:46] <huwshimi> wgrant: I'm not sure. So I think we should take a time + effort vs  how badly it breaks attitude.
[02:46] <lifeless>       68 /   33  Branch:+index
[02:46] <lifeless>       43 /   14  Archive:+copy-packages
[02:46] <lifeless>       32 /  295  POFile:+translate
[02:46] <lifeless>       24 /  283  Distribution:+bugtarget-portlet-bugfilters-stats
[02:46] <lifeless>       16 /   49  Archive:+packages
[02:46] <lifeless>       11 /   40  Product:+code-index
[02:46] <lifeless>       10 /   16  DistroSeriesLanguage:+index
[02:47] <wgrant> huwshimi: Mm. I suppose I could hack text_to_html to add a class to the last paragraph.
[02:47] <wgrant> But I hate IE.
[02:47] <huwshimi> wgrant: in this case, if the break is aweful and it is easy enough to fix, then do it.
[02:48] <huwshimi> wgrant: I believe we have low numbers of IE users, but enough to be significant.
[02:50]  * thumper heads to coffee
[02:51] <StevenK> Do we have accessible stats of browser usage?
[02:51] <wgrant> Some people have Google Analytics access.
[02:51] <wgrant> sinzui was looking at them during the Thunderdome.
[02:51] <huwshimi> wgrant: I personally have the opinion that it is time to let things break on IE6, because as long as we attempt to make it look half decent, organisations etc. will not bother to upgrade, but once the web experience starts to break then the pressure from users will be enough to make organisations make the upgrade
[02:52] <wgrant> huwshimi: Certainly, disregarding IE6 has been good standard policy for a while.
[02:52] <lifeless> huwshimi: a massive hack attack on it wasn't enough ?
[02:52] <wgrant> lifeless: No.
[02:53] <huwshimi> lifeless: You would think so
[02:54] <huwshimi> infact I think that even if a couple of major websites were broken on IE the pressure would mount (e.g. facebook)
[02:55] <lifeless> but those sites have the most to lose ;)
[02:57] <huwshimi> lifeless: Well facebook is phasing out ie6 support for some of their features already
[02:58] <lifeless> \o/
[02:59] <StevenK> Surely businesses will play the "You shouldn't be viewing Facebook at work anyway" card, and not upgrade anyway? :-)
[03:01] <wgrant> Oh good, just to make it easy the thing that text_to_html iterates over is a generator.
[03:03] <huwshimi> wgrant: Is this so that you can add the last class?
[03:03] <wgrant> huwshimi: Yes.
[03:03] <huwshimi> wgrant: I'm guessing that means it's going to be hard to add the class? Or impossible?
[03:04] <wgrant> huwshimi: Well, I can turn the generator into a function that returns a list instead.
[03:11] <wgrant> Ugh.
[03:12]  * wgrant gives up for a while and lunches.
[03:18] <huwshimi> wgrant: When you get back let me know and we can talk about this again.
[03:18] <StevenK> thumper: So I'm struggling with this rename-recipes-when-merging branch -- do you think I should subclass IBranchNamespace and then call it from the merging code?
[03:22] <wallyworld> if i were to raise a bug to address a performance issue, that would be a Defect rather than an Improvement? Or not?
[03:23] <lifeless> wgrant: we don't really have defect/improvement in our workflow
[03:23] <lifeless> bah
[03:23] <lifeless> wallyworld: ^
[03:24] <wallyworld> sooooo, the verdict?
[03:24] <lifeless> wallyworld: So I don't understand the question
[03:24] <wallyworld> i'm talkin abou the kanban board
[03:24] <wallyworld> sorry, not enough context
[03:24] <wallyworld> i knew what i meant :-)
[03:26] <lifeless> wallyworld: so, you're on the recipe squad right?
[03:26] <lifeless> wallyworld: in principle everything you're working on is improvement
[03:26] <wallyworld> yeah, but it's to fix the +daily-builds performance issue
[03:27] <wallyworld> ok, i'll use improvement, thanks
[03:27] <lifeless> wallyworld: its an improvement :)
[03:28] <wallyworld> lifeless: many times i'm included to consider performance issues as defects :-)
[03:28] <wallyworld> another question too: i've had an ec2 failure email, with no errors attached but instead the message "SMTPError: SMTP error: 552 Message size exceeds maximum permitted"
[03:28] <wallyworld> where do i look to see what happened?
[03:30] <lifeless> blah
[03:30] <lifeless> the compressed subunit log was larger than the mailserver would accept
[03:31] <lifeless> 'someone' should make ec2 test attach that to the branch using the subunit API in launchpad
[03:31] <lifeless> thumper: you've added brand new things to the API before, right ?
[03:32] <lifeless> thumper: new types etc, I mean.
[03:33] <wallyworld> lifeless: in the meantime, how do i get the test log? i guess it's lost when the ec2 instance shuts down?
[03:33] <spm> stub: what's the table/query to see what DB patch a given DB is currently up to?
[03:33] <lifeless> wallyworld: yeah :(
[03:33] <wallyworld> bollocks :-(
[03:34] <stub> select * from launchpaddatabaserevision order by major,minor,patch;
[03:34] <spm> ta
[03:35] <wallyworld> lifeless: it was the recently done sql bind parameters branch. perhaps something failed so spectacularly that the log file got too big?
[03:35] <lifeless> spm: I'm guessing that means we has tree ?
[03:35] <lifeless> wallyworld: thats quite possible
[03:35] <spm> lifeless: no not yet. I was wonder htf qastaging get's it's db patches at all.
[03:36] <lifeless> spm: it doesn't
[03:36] <lifeless> spm: it gets restored to.
[03:36] <lifeless> spm: it *must not* apply db patches because its what we QA our deployments on
[03:37] <spm> yah. and hence was wondering how it managed to maintain some semblance of code/db sync at all.
[03:38] <lifeless> spm: its meant to be restored weekly with staging, and for db deploys it has the patches applied to it.
[03:38] <lifeless> however something seems to be quirky there
[03:38] <spm> yes. hence my questions and htf'ing
[03:39] <lifeless> spm: not functionally quirky, if that makes sense.
[03:39] <spm> :-)
[03:40] <StevenK> wgrant: Do you think I should just force a build to get buildbot/pqm happy again?
[03:54] <lifeless> wallyworld: hi
[03:55] <wallyworld> lifeless: hello
[03:55] <lifeless> wallyworld: we have db transactions, reading twice from the DB is pointless.
[03:55] <lifeless> wallyworld: perhaps I'm misunderstanding something.
[03:55] <wallyworld> you mean in the deleted recipe branch?
[03:55] <lifeless> yes
[03:56] <lifeless> unless you're in two separate transactions (which you may need to be to avoid having long running transactions on big uploads)
[03:56] <wallyworld> i wasn't sure of the transaction boundaries and so was being (overly) cautious
[03:56] <lifeless> if you're in two separate transactions, then I'd just check at the end
[03:56] <wallyworld> just to avoid any possible race conidions
[03:56] <lifeless> wallyworld: well, it raises red flags to me
[03:56] <wallyworld> i didn't want to go to the expense of trying a build if there was no pint, hence the check up front
[03:56] <lifeless> wallyworld: thusly: it makes it more complex, and its either not needed, or it is needed but wasn't clear that it is.
[03:57] <lifeless> wallyworld: I guess I'm asking for more surety that it is/isn't rather than a hopeful statement that doesn't fit with transaction semantics.
[03:58] <lifeless> wallyworld: separately, whats this daily build performance bug you're going to look at? I'm curious.
[03:59] <wallyworld> not so much transaction semantics but where the transaction boundaries are. i'll revisit it though....
[03:59] <wallyworld> https://devpad.canonical.com/~lpqateam/ppr/lpnet/latest-daily-timeout-candidates.html
[03:59] <lifeless> ah, a page dear to my heart
[03:59] <wallyworld> +daily-builds, about 1/2 way down
[03:59] <lifeless> ah yes
[03:59] <lifeless> I was mentioning this to tim the other day
[04:00] <lifeless> never completes in < 5 seconds
[04:00] <lifeless> suggests its doing -way- to much work
[04:00] <wallyworld> yeah :-(
[04:01] <wallyworld> to me that's a defect but.....
[04:01] <wallyworld> ... i've added an improvement card
[04:01] <lifeless> :)
[04:06] <lifeless> spm: can you toss a haproxy status page screeny my way? We're seeing more might-be-GIL stuff, and as we haven't done single-threaded appservers yet, I can't eliminate it...
[04:06] <lifeless> but the queue dpeth stuff often gives decent hints
[04:06] <spm> prod?
[04:07] <lifeless> yeah, servers C,E,H
[04:11] <wgrant> StevenK: Always.
[04:11] <lifeless> hmm is +code-index memcached?
[04:11] <StevenK> Fricken buildbot
[04:13] <lifeless> ok, phew, new bugs for new timeout limit filed
[04:29] <lifeless> wallyworld: https://bugs.launchpad.net/launchpad/+bug/711072 - I've doctored it up to add more info for you
[04:29] <_mup_> Bug #711072: RootObject:+daily-builds times out <timeout> <Launchpad itself:Triaged by wallyworld> < https://launchpad.net/bugs/711072 >
[04:29] <lifeless> wallyworld: I hope that helps
[04:31] <wallyworld> lifeless: thanks, although you've taken all the joy away of me finding that myself :-) i don't mind getting down and dirty with a profiler you know :-)
[04:34] <lifeless> wallyworld: I logged into devpad
[04:34] <lifeless> cd /srv/launchpad.net-logs
[04:34] <lifeless> grep +daily-builds lpnet/*/2011-02-01 -r
[04:35] <lifeless> (I didn't get the joy of profiling either)
[04:35] <wallyworld> lifeless: thanks for the tip
[04:52] <StevenK> buildbot, DIAF. Whoever thought the xmlrpc interface to it is documented is brain-dead
[04:52] <lifeless> StevenK: it was fairly straightforward when I read the code
[04:53] <StevenK> I love how buildbot-poller hard codes lucid_lp and lucid_db_lp in multiple places.
[04:59] <thumper> lifeless: yes in the past I have, but not for ages
[04:59]  * thumper is making dinner
[05:11] <lifeless> wgrant: where are you up to on archive:+index ?
[05:15] <wgrant> lifeless: The OOPSes I've looked a recently have been for a copy archive, and resulted in bug #709717.
[05:15] <_mup_> Bug #709717: ArchiveView.num_pkgs_building can be very slow <lp-soyuz> <oops> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/709717 >
[05:15] <wgrant> I haven't checked the general case since Julian's fixes.
[05:16] <lifeless> wgrant: can you pleae put page ids in titles of such bugs? helps me at least ;)
[05:17] <wgrant> lifeless: Sure, sorry.
[05:17] <lifeless> no need to apologise
[05:17] <lifeless> its informal
[06:13] <huwshimi> Have a good rest of the day people.
[06:26] <lifeless> StevenK: so whats up with Revision 12277 can not be deployed: needstesting
[06:30] <lifeless> wgrant: still around ?
[06:30] <lifeless> wgrant: why in bug 691478 do we need a union ?
[06:30] <_mup_> Bug #691478: Archive:+index timeouts <dba> <qa-ok> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/691478 >
[06:34] <wgrant> lifeless: There are a couple of places we use them.
[06:34] <wgrant> One is to determine the set of builds that we need to consider: we grab those in the archive itself, and union with those that were copied in.
[06:38] <lifeless> I'll be glad when wallyworld's parameter saving patch gets stashed
[06:38] <lifeless> lol
[06:43] <lifeless> ok, I think I need to call it a day
[07:21] <StevenK> lifeless: Sorry, I was picking up Sarah; still here?
[08:03] <lifeless> StevenK: here
[08:32] <StevenK> lifeless: I'm rolling it back and not QA'ing since I don't want users to lose information when they merge if they have recipes.
[08:36]  * wgrant stabs lucid_db_lp.
[08:43] <lifeless> StevenK: ok, nowish ?
[08:44] <StevenK> lifeless: It has been rolled back, it's tip of devel
[08:46] <lifeless> StevenK: sweet
[08:56] <thumper> https://code.launchpad.net/~thumper/lazr-js/multi-line-editor-goodness/+merge/48118 if someone likes looking at styles and javascript
[08:56]  * thumper is really done
[08:56] <bigjools> morning
[08:58]  * thumper claims 6 bug fixes with that merge proposal \\o/
[08:58]  * thumper flees the office
[09:00] <gmb> Low bandwidth good morning.
[09:00] <bigjools> coffee shop or 3g?
[09:01] <adeuring> good moring
[09:03] <gmb> bigjools: Hahaha. 3G round here? To make a hollow laughing. At the moment I'm doing irc and email over GPRS. Coffee shop will happen later when traffic in town has died away.
[09:03] <bigjools> zoiks
[09:04] <gmb> I know. Party like it's 1995.
[09:18] <mrevell> Howdy
[09:28] <bigjools> open id + redirects = FAIL
[09:44] <bigjools> wgrant: around?
[09:54] <wgrant> bigjools: Hi.
[09:54] <wgrant> Did you break mawson?
[09:54] <bigjools> wgrant: no
[09:54] <wgrant> :(
[09:55] <bigjools> but I am testing on it
[09:56] <wgrant> bigjools: What provides bzr lp-land? bzr-pqm?
[09:56] <bigjools> wgrant: yes
[09:57] <bigjools> wgrant: quick question for your consideration:
[09:57] <bigjools> in rescueBuilderIfLost() I want to fail the builder if a nonvirtual builder ends up in ABORTED
[09:57] <bigjools> because we can't be sure abort() worked
[09:57] <bigjools> what do yo uthink?
[09:58] <wgrant> They only end up ABORTED if someone manually kills things. Acting on ABORTING might be more useful.
[09:58] <bigjools> wgrant: the manually killing thing is precisely the situation I am considering
[09:59] <bigjools> and catches the ABORTING stage too
[09:59] <bigjools> see bug 705342
[09:59] <_mup_> Bug #705342: buildlog contains a mix of two different builds <Launchpad itself:In Progress by julian-edwards> < https://launchpad.net/bugs/705342 >
[09:59] <wgrant> Hmm, actually, they will also end up ABORTED once the build finishes.
[09:59] <wgrant> That's the normal case.
[09:59] <wgrant> Sigh.
[10:00] <bigjools> hmmmmn?
[10:00] <bigjools> there's nothing normal about it
[10:00] <wgrant> Builders will eventually recover from ABORTING without manual intervention.
[10:00] <wgrant> Because the build will finish.
[10:00] <wgrant> I wonder how often that happens.
[10:01] <bigjools> well the double build thing happens even when we call cleanSlave after seeing ABORTED
[10:01] <bigjools> there's a plethora of slave bugs here
[10:01] <wgrant> Right. After manual intervention.
[10:01] <bigjools> yes
[10:02] <wgrant> (in other news, a few hundred lines of lpland look remarkably identical to autoland)
[10:02] <wgrant> I wonder if the same diff applies.
[10:02] <bigjools> so if we end up in ABORTED on a nonvirtual slave I am suspicious
[10:02] <bigjools> and therefore want to fail it
[10:02] <bigjools> because it means the admin has pebkac
[10:03] <wgrant> Not always.
[10:03] <bigjools> mostly
[10:03] <wgrant> I do not know the relative frequencies.
[10:03] <wgrant> I suspect that the problematic case is a tiny minority.
[10:03]  * bigjools greps
[10:05] <bigjools> I only see one case
[10:07] <wgrant> OK, I should not be able to take a 154 line diff and apply it to a different project with no conflicts.
[10:07] <bigjools> I am making the change anyway
[10:07] <bigjools> wgrant: :(
[10:07] <wgrant> bigjools: OK.
[10:07] <wgrant> I guess we'll see how it goes.
[10:07] <bigjools> yeah
[10:07] <bigjools> if nothing else it'll prevent serious issues
[10:08] <wgrant> bigjools: Also, as you may be aware, We have an upcoming Debian release.
[10:08] <bigjools> now, to work out why assertFalse doesn't fail for a True value
[10:08] <bigjools> yeah
[10:08] <wgrant> I've landed the config changes already.
[10:08] <bigjools> I saw
[10:08] <wgrant> Do we need to do anything beyond creating the new series and adding the series name to iron's crontab?
[10:09] <bigjools> not entirely sure tbh, it's been a while since we changed gina config!
[10:09] <bigjools> dogfood FTW
[10:09] <wgrant> Indeed.
[10:10] <wgrant> I know this will work. I was mostly wondering if there were any instructions to create the series, or if we should just imitate the previous one.
[10:10] <bigjools> test it on DF
[10:10] <wgrant> k
[10:11] <wgrant> How do I get the Debian archive onto there?
[10:11] <wgrant> Can I sync bits of it from iron or similar?
[10:11] <bigjools> let me know if you want to bring it down/up since I am testing
[10:11] <bigjools> ummm ask Steve, he did something with it recently
[10:11] <wgrant> I can't do it yet, since wheezy doesn't exist.
[10:11] <wgrant> Although I guess I could mangle the squeeze indices to look like wheezy.
[10:12]  * bigjools - > call
[10:33] <jtv> Hi folks how do I make my tests pass in python?  I keep saying "pass" but it doesn't work.
[11:00] <bigjools> can someone take a look at this and guess as to why, although the assertionerror is raised, the test doesn't fail? http://pastebin.ubuntu.com/560674
=== wgrant_ is now known as wgrant
[11:16] <bigjools> jml: around?
[11:20] <LPCIBot> Project devel build (407): FAILURE in 5 hr 38 min: https://hudson.wedontsleep.org/job/devel/407/
[11:21] <jml> bigjools: am now
[11:21]  * gmb returns, via Starbucks.
[11:21] <bigjools> jml: can you check my paste above please
[11:21] <gmb> The coffee blows, but the wifi is oh so sweet.
[11:21] <bigjools> jml: I've got a failure in a twisted test but it's not causing the test to fail
[11:22] <bigjools> dunno where the problem is, trying to debug the test runner ...
[11:22] <bigjools> gmb: compared to the Dallas hotel coffee, Starbucks was great.  :(
[11:22] <jml> bigjools: yuck. can you paste the test & what happens when you run it?
[11:23] <gmb> Well, yeah.
[11:23] <jml> (the full class would be nice, actually)
[11:23] <bigjools> jml: http://pastebin.ubuntu.com/560899/
[11:24] <bigjools> the if 1==2 is to avoid the condition that makes the test pass
[11:28] <jml> bigjools: does the breakpoint get triggered?
[11:31] <bigjools> jml: yes
[11:31] <bigjools> jml: see http://pastebin.ubuntu.com/560674
[11:32] <jml> bigjools: the problem is that the assertion error is being swallowed?
[11:32] <bigjools> jml: that's what it looks like
[11:33] <bigjools> when I debug, I can see it getting recorded as a Failure, then nothing happens when it ends up in fail_if_exception_caught()
[11:33] <jml> bigjools: OK. Let's try to whip up a minimally reproducing example.
[11:33]  * bigjools tries something else
[11:34] <bigjools> jml:
[11:34] <bigjools>     def test_failing_test(self):
[11:34] <bigjools>         self.assertFalse(True)
[11:34] <bigjools> does not fail ...
[11:35] <jml> bigjools: that would be a minimally reproducing example.
[11:35] <bigjools> indeed :)
[11:35] <jml> bigjools: just trying locally, in case it's something in your branch / local config.
[11:35] <bigjools> ok
[11:35] <bigjools> jml: I added that to TestBuilder FWIW
[11:36] <jml> cannot import name BuildNavigationMixin...
[11:37] <bigjools> circ imports :/
[11:37] <jml> I haven't changed anything!
[11:37] <bigjools> if you run with -t it doesn't do it
[11:37] <jml> oh right.
[11:37] <bigjools> only if you specify the module
[11:37] <bigjools> le sigh
[11:38] <bigjools> jml: I've narrowed it down to the presence of this line in the test class:
[11:38] <bigjools> run_tests_with = AsynchronousDeferredRunTest.make_factory(timeout=10)
[11:38] <bigjools> remove that and the simple case fails
[11:38] <bigjools> this is rather worrying :)_
[11:39] <jml> bigjools: that line says "use the reactor when running tests and wait for deferreds to fire"
[11:39] <jml> I expect the bug is in ADRT though.
[11:40] <jml> dammit. I've got to go.
[11:40] <jml> bigjools: please see if you can reproduce it using just testtools.
[11:40] <jml> bigjools: file a bug on testtools and I'll fix it when I get back.
[11:41] <bigjools> jml: I'll dig
[11:41] <bigjools> thanks
[12:06] <deryck> Morning, all.
[12:26] <bigjools> jml: https://bugs.launchpad.net/testtools/+bug/711209
[12:26] <_mup_> Bug #711209: When running Twisted tests, failures are not reported <testtools:New> < https://launchpad.net/bugs/711209 >
[12:34] <wgrant> jelmer: Could you please land that bzr-pqm change? I don't think I have privs.
[12:38] <jelmer> wgrant: sure
[12:41] <jelmer> wgrant: I really think this kind of stuff should live in another plugin, perhaps the same plugin as lpreview_body
[12:41] <jelmer> anyway, not your fault :)
[12:43] <wgrant> jelmer: Yes :(
[13:10] <wgrant> Hmm, recipes are pretty cool.
[13:18] <gary_poster> allenap: ping?
[13:21] <allenap> gary_poster: Hi there.
[13:23] <gary_poster> Hi allenap :-) .  Could I have a second review from you on a branch?  It is a branch that moves the bug_notification_level from structural subscriptions to the filter.  I have one specific question for you, and then I'd appreciate a general review as well.  https://code.launchpad.net/~gary/launchpad/move-events-to-filters/+merge/48069  Can you take the time for that?
[13:23] <gary_poster> it's a big branch :-/
[13:23] <allenap> gary_poster: Sure :)
[13:24] <gary_poster> thank you!
[13:25] <gary_poster> allenap, the specific question is about the delete method on the filter.  I pose the question/concern in the second reply to the MP, about the XXX
[13:26] <allenap> gary_poster: Cool.
[13:26] <gary_poster> thanks again
=== bac changed the topic of #launchpad-dev to: Performance Tuesday | https://€‹dev.launchpad.net/€‹ | PQM is open | firefighting: - | On call reviewer: -  | https://code.launchpad.net/launchpad-project/+activereviews
[14:00] <deryck> abentley, adeuring -- I
[14:00] <deryck> I'm coming :-)
[14:05] <maxb> bac: Um... did you just introduce weird unicode into the topic? :-)
[14:24] <bac> maxb: no, i tried to remove weird unicode
=== bac changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/| PQM is open | firefighting: - | On call reviewer: -  | https://code.launchpad.net/launchpad-project/+activereviews
=== leonardr changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/| PQM is open | firefighting: - | On call reviewer: leonardr  | https://code.launchpad.net/launchpad-project/+activereviews
[14:44] <jml> bigjools: the test doesn't fail when run purely with testtools
[14:44] <jml> as in, it fails correctly
[14:44] <bigjools> jml: :/
[14:45] <bigjools> did you see the bug?
[14:46] <jml> bigjools: yeah, I did.
[14:46] <jml> bigjools: bringing in more of the LP stack now to reproduce
[14:47] <bigjools> jml: I have no clue why it thinks that attribute is not settable
[14:47] <bigjools> trez bizarre
=== matsubara is now known as matsubara-lunch
[14:48] <jml> this would be easier if my laptop wasn't suffering display refresh problems
[14:49]  * jml tries a different runner
[14:50]  * bigjools discovers how hard it is to search for an sql statement containing "except"
[14:50] <jml> hmm.
[14:51] <jml> so w/ ADRT it passes incorrectly
[14:51] <jml> w/ SDRT it gives that stack trace that you supplied in the bug
[14:51] <jml> w/ RT it fails as it ought.
[14:51] <bigjools> hummm
[14:51] <jml> let me eliminate zope.testing
[14:51] <bigjools> thanks for debugging
[14:52] <jml> actually, first, getting rid of LP's base TestCase
[14:52] <jml> bigjools: np.
=== salgado is now known as salgado-lunch
[14:58] <jml> http://paste.ubuntu.com/560985 - huh
[14:58]  * jml tries with just testtools
[15:00] <bigjools> jml: I bet that something is declaring that attribute as a @property when the other classes are not
[15:00] <bigjools> easy to grep for it
[15:00] <jml> which attribute!
[15:00] <bigjools> the one in the traceback
[15:01] <jml> the exception message specifies neither the object nor the attribute name
[15:01] <bigjools> I pdb'd far enough to find it
[15:01] <bigjools> look in the traceback!  last line
[15:02] <jml> f_locals
[15:03] <bigjools> appropriate name
[15:03] <jml> hmm.
[15:03] <bigjools> the other worrying thing is that an except was totally swallowed
[15:03] <bigjools> exception
[15:04] <jml> this is perplexing.
[15:05] <jml> the exact same test behaves correctly (i.e. fails) when run as part of the testtools suite
[15:05] <bigjools> so is the async runner inserting a class into the hierarchy that declares f_locals as a property?
[15:06] <bigjools> sorry, not giving this my full attention
[15:07] <jml> no, it's not.
[15:07] <jml> if it were, it would fail when run as part of the testtools suite
[15:08] <jml> hmm.
[15:09] <abentley> bigjools, I seem to be getting None for this when processing a source package recipe build fails.  Could some of these relationships be waiting for the upload to succeed before they're set? http://pastebin.ubuntu.com/560988/
[15:09] <bigjools> checking
[15:09] <jml> bigjools: also, don't worry about attention. it helps me enough to dump new data in the channel :)
[15:10] <bigjools> abentley: SourcePackageRelease won't exist will it?
[15:10] <bigjools> jml: heh ok :)
[15:12] <abentley> bigjools, I guess not.  Is there another way I can find the sourcepackagerecipebuild for a packageupload?
[15:12] <bigjools> lemme see
[15:12] <jml> ok. I have no idea how I got the behaviour I pasted.
[15:14] <adeuring> danilos: do you have some time to discuss the remove_translations script (bug 705652)?
[15:14] <_mup_> Bug #705652: Make remove_translations side aware. <upstream-translations-sharing> <Launchpad itself:In Progress by adeuring> < https://launchpad.net/bugs/705652 >
[15:15] <danilos> adeuring, sure, in say 30 mins, would that work for you?
[15:15] <adeuring> danilos: sure.
[15:15] <danilos> thanks, adeuring, and feel free to re-ping me in that time :)
[15:16] <adeuring> danilos: ok, will do :)
[15:16] <bigjools> abentley: hmmm I don't understand how there is a packageupload at all if the upload failed
[15:17] <jml> hah
[15:17] <jml> ok
[15:17] <bigjools> at what point are you looking for this data, in the failure code?
[15:17] <jml> I think it's something imported by test_builder that's playing havoc
[15:17] <bigjools> jml: yay....
[15:18] <jml> easy enough to figure out
[15:18] <bigjools> abentley: if there's a failure, you need to fall back to the data in the changes file really, the database will not be intact and is about to get its txn aborted
[15:18]  * jml bisects
[15:18] <bigjools> two jmls!
[15:19] <bigjools> can we put one of you in another timezone?
[15:19] <abentley> bigjools, this is in the archiveuploader, which already uses a PackageUpload object.
[15:19] <bigjools> abentley: right, but I doubt it's committed yet
[15:19] <bigjools> abentley: what are you fixing/doing exactly?
[15:20] <abentley> bigjools, I am fixing the way the PackageUpload object determines whether it's processing a user upload or a build.
[15:20] <abentley> bigjools, until my changes, it used self.builds for that.
[15:20] <bigjools> as in a recipe build
[15:21] <bigjools> abentley: the builds won't be signed
[15:21] <abentley> bigjools, as in a recipe build or binary build.
[15:21] <bigjools> user uploads are always signed
[15:21] <bigjools> abentley: what's the problem you're fixing?
[15:22] <abentley> bigjools, it's sending two emails because part of the code thinks it's doing a user upload and part of the code thinks it's doing a build upload.
[15:22] <bigjools> ok
[15:22] <bigjools> what are the conditions it's checking?
[15:22] <bigjools> and, wtf, why 2 places!
[15:25] <jml> hah
[15:25] <jml> ok.
[15:25] <abentley> bigjools, PackageUpload is now using self.builds and getSourceBuild to determine whether it's doing a build.  UploadProcessor is using its own, very different  self.builds to determine whether it's processing ubilds.
[15:25] <jml> found the offending line in lp.testing.__init__.
[15:26] <jml> now have to figure out why it's there before I kill it with great killing.
[15:26] <abentley> s/ubilds/builds/
[15:26] <jml> (also, implicit global monkey patches of core libraries should always have a comment)
[15:27] <jcsackett> jml: and should maybe be avoided, if possible. :-P
[15:27] <bigjools> abentley: ok, I'll have a looksee
[15:27] <jml> jcsackett: well, I guess.
[15:28] <jml> huh. I reviewed the change.
[15:28] <jcsackett> jml: i mean, you're talking the realm of tests, where monkeypatching is sort of required. but "implicit global monkeypatch" is sort of a frightening prhase, don't you think? :-P
[15:28] <bigjools> abentley: what is calling those, the notify() stuff?
[15:28] <jml> jcsackett: yeah, it is.
[15:28] <bigjools> _Frame.f_locals = property(lambda self: {})
[15:28] <bigjools> wtf!
[15:29] <jml> jcsackett: here it's really a specific instance of "imports should not have side effects"
[15:29] <jml> bigjools: looking into it now
[15:29] <jcsackett> jml: dig.
[15:29] <jml> bigjools: found the bug and the code review
[15:29] <jml> 425113 fwiw
[15:29] <bigjools> excellent
[15:29] <bigjools> bug 425113
[15:29] <_mup_> Bug #425113: Some tests can fail without detection <build-infrastructure> <lp-foundations> <Launchpad itself:Fix Released> <Twisted:New> < https://launchpad.net/bugs/425113 >
[15:29] <abentley> bigjools, yes, PackageUpload.notify
[15:29] <bigjools> oh the irony
[15:29] <bigjools> abentley: right, there's two lots of email that goes out
[15:30] <bigjools> so it makes sense
[15:30] <jml> hmm.
[15:30] <jml> there was a comment in the MP
[15:31] <jml> ahh, it got moved, probably by a zealous import formatter.
[15:31] <abentley> bigjools, I think ultimately it would be good to have polymorphism change the behaviour of PackageUpload.notify depending on whether it's a build or user upload.
[15:31] <bigjools> abentley: so, the code at the top of notify() is clearly wrong for recipe uploads
=== almaisan-away is now known as al-maisan
[15:32] <jml> curse you distribution mirror prober!
[15:32] <bigjools> jml: it'll be fun to see how many tests start failing when you remove that
[15:33] <abentley> bigjools, the test for whether it's SECURITY?
[15:33] <jml> bigjools: thing is, it was added to stop tests from failing silently
[15:33] <bigjools> jml: hence: [15:29:34] <bigjools> oh the irony
[15:33] <jml> yeah
[15:33] <jml> I guess what I mean is, I don't think anything will fail when I remove it
[15:34] <bigjools> abentley: oh actually, scratch that
=== salgado-lunch is now known as salgado
[15:34] <jml> oh
[15:35] <jml> except that maybe some tests are failing silently now
[15:35] <jml> was a bit too focused to get that
[15:35] <bigjools> exactly
[15:36] <jml> the thing here is that testtools doesn't have the bug that trial has
[15:36] <bigjools> abentley: so sending two emails is the right thing in some circumstances
[15:36] <bigjools> abentley: do you have a case where that's wrong?
[15:36] <jml> I'm going to move this monkey-patch into the TwistedLayer, which should do the trick.
[15:37] <bigjools> abentley: actually for PPA uploads it should always be one, I am thinking of the distro case
[15:37] <abentley> bigjools, right.
[15:37] <jml> ffs
[15:38] <jml> how do I change a bugtask against testtools to be targeted against Launchpad? it says "too many matches" when I type "launchpad"
[15:38] <abentley> jml, use the dropdown thingy.
[15:39] <bigjools> abentley: can you point me at the code in the upload processor?
[15:39] <bigjools> it's been 2 years since I delved into the notification code
[15:40] <jml> abentley: ta
[15:41] <abentley> bigjools, lib/lp/archiveuploader/uploadprocessor.py:634
[15:41] <bigjools> abentley: the email bit I mean
[15:41] <bigjools> it's not sending email there?
[15:42] <bigjools> grar, this code is utterly shite
[15:42] <abentley> bigjools, it's invoking self.build.notify there.
[15:42] <abentley> bigjools, and hey! that's my code!
[15:42] <bigjools> lol :)
[15:42] <abentley> bigjools, well, I refactored it, anyhow.
[15:43] <bigjools> ok, so that code there is for BFNs
[15:43] <abentley> BFN=Build Farm Notification?
[15:43] <bigjools> all the routine notification should be done in PU.notify
[15:43] <bigjools> build failure notification
[15:44] <abentley> bigjools, what do we notify about except failure (and success for recipe builds):?
[15:44] <bigjools> uploaders always get an email
[15:45] <bigjools> for source uploads anyway
[15:45] <abentley> bigjools, and we don't permit binary uploads, right?
[15:45] <danilos> adeuring, heya :)
[15:45] <bigjools> abentley: not from user
[15:45] <bigjools> s
[15:45] <adeuring> hi danilos. shall we talk on mumble?
[15:46] <danilos> adeuring, sure thing
[15:46] <bigjools> abentley: process-upload is invoked with --builds in the buildmaster machine and then it knows to allow build uploads
[15:46] <abentley> bigjools, right, that's where UploadProcessor.builds comes from.
[15:47] <bigjools> abentley: if you can, I  would try and poke all your notification code into PU.notify
[15:48] <bigjools> move it away from the build
[15:48] <bigjools> then it will be consistent with the existing processing
[15:49] <bigjools> and you can easily check to see if it's a recipe upload if you want to tweak any text
[15:50] <abentley> bigjools, I can do that, but PU will still be incorrectly detecting that this is a user upload.
=== deryck is now known as deryck[lunch]
[15:50] <bigjools> abentley: check to see if the upload is signed
[15:50] <bigjools> it does that in a couple of places already IIRC
[15:51] <bigjools> self.signing_key
[15:51] <bigjools> abentley: once you move the notification code here, the logic will then be correct for when we start uploading sources from recipe to Ubuntu
[15:52] <abentley> bigjools, actually, in order to move the code into PU.notify, I'd need to pass the build into PU.notify, so I guess I can just check whether it's None.
[15:53] <bigjools> abentley: you don't need to pass the build
[15:53] <abentley> bigjools, I want to do notification by calling self.build.notify, as we do with other build notifications.
[15:53] <bigjools> abentley: no, use PU.notify
[15:53] <abentley> bigjools, I don't want to duplicate the code needed to send a build notification.
[15:54] <bigjools> otherwise it will never work properly
[15:54] <bigjools> this is not a build notification
[15:54] <bigjools> it's a source upload notification
[15:54] <abentley> bigjools, does not compute.
[15:54] <bigjools> you are uploading a source package that has come from a recipe
[15:55] <bigjools> all of the notification logic for that is already there
[15:55] <bigjools> all you need to do is possibly add extra text if you know it's from a recipe (I've not seen the recipe notifications)
[15:55] <abentley> No, it's not.  Users would get a totally different email from what they used to get.
[15:55] <bigjools> doing this as a build notification is wrong
[15:55] <abentley> bigjools, why?
[15:55] <bigjools> I just explained
[15:56] <bigjools> where are the recipe "build" emails?
[15:56] <abentley> I disagree.  I think upload failures should look like other build failures, except they should include the upload log.
[15:57] <abentley> bigjools, this is how we used to do it.
[15:57] <sinzui> I wonder how hard it would be to add a feature to inline help to create self-documentation for enums
[15:57] <bigjools> then they are totally different to normal source upload emails and that is inconsistent
[15:57] <bigjools> we created the source upload format after a LOT of consultation with people
[15:57] <abentley> bigjools, the people who are doing recipe builds are expecting consistency with build failure emails, not source  upload emails.
[15:58] <bigjools> who are they?
=== beuno is now known as beuno-lunch
[15:58] <abentley> bigjools, upstreams.  This is "bridging the gap" work.
[15:58] <bigjools> what about successful uploads?
[15:59] <abentley> For recipes, successful uploads are generating build-style notifications.
=== matsubara-lunch is now known as matsubara
[16:00] <bigjools> I don't think we should be doing that
[16:00] <bigjools> it's inconsistent with source uploads
[16:01] <abentley> bigjools, I think we should, because it's consistent with what we were doing before async uploads were implemented, and because source upload format is not valued by the target audience.
[16:01] <bigjools> this will cause a lot of issues when we start doing recipe builds for ubuntu
[16:01] <bigjools> errr, yes, it is
[16:02] <bigjools> the format is irrelevant anyway, I am telling you where to send the notifications from
[16:02] <bigjools> you can format them how you like
[16:02] <bigjools> or they like
[16:02] <abentley> bigjools, in order to format them how I like, I'm going to pass the build in.  Otherwise, I'd have to omit useful information from the notification.
[16:03] <bigjools> if you do it from the build object, you will end up duplicating all the logic in PU - as you are now discovering
[16:03] <bigjools> ok - you'll need to pass the build in if you can't get hold of it
[16:03] <abentley> bigjools, no, I won't.  the logic is quite different.
[16:03] <bigjools> ok - ignore me
[16:08] <jml> need a review for https://code.launchpad.net/~jml/launchpad/failing-tests-bug-711209/+merge/48184
[16:08] <jml> fix for some tests failing silently
[16:09] <sinzui> hi jml: I will take it
[16:09] <jml> sinzui: thanks.
[16:14] <sinzui> jml: r=me
[16:14] <jml> sinzui: ta
[16:25] <jml> branch now in ec2
[16:25] <jml> I can hardly wait.
[16:29] <sinzui> bigjools: ping
[16:31] <leonardr> reviewer needs some reviews done: https://code.launchpad.net/~leonardr/lazr.restful/web-link/+merge/48052 and https://code.launchpad.net/~leonardr/launchpad/web-link/+merge/47258
[16:31] <bigjools> sinzui: otp, will get back to you
[16:32] <danilos> allenap, hi, you around?
[16:32] <allenap> danilos: Yes, but I need a few minutes.
[16:32] <danilos> allenap, sure thing
[16:33] <leonardr> all unassigned reviews in the review queue are done
[16:33] <leonardr> except mine
[16:36] <bigjools> sinzui: hi, how can I help
[16:37] <sinzui> bigjools: I am reading line 1974 of lib/lp/soyuz/doc/archive.txt. Why is the team OPEN.
[16:38] <abentley> bigjools, I see that isAutoSyncUpload checks both signing_key and contains_build, which suggests that they could vary independently.  Are you sure checking for a signature is a reliable test, or did you mean something else?
[16:38] <bigjools> sinzui: I suspect no reason at all
[16:38] <sinzui> Actually I think I know. Because a MODERATED requires an extra approval step for future tests in the doc
[16:38] <bigjools> sinzui: ah yes, good point
[16:39] <bigjools> that doctest is a nightmare
[16:39] <bigjools> I've watched it grow over 3 years
[16:39] <sinzui> bigjools: so it is. I am going to change the doc to MODERATED and will update another test to use addMember
[16:39] <sinzui> Or I can delete the entire section if I find a unittest for this behaviour
[16:40] <bigjools> sinzui: +1
[16:40] <sinzui> thank bigjools
[16:41] <bigjools> abentley: it's possible in the past that they did, but builds are never signed now
[16:42] <bigjools> abentley: what time do you start work normally?  I want to call you about this tomorrow
[16:42] <abentley> bigjools, I start work at 14:00 UTC.
[16:42] <bigjools> ok, thanks
[16:43] <allenap> danilos: Sorry about that. My son was demanding some toy train time. What's up?
[16:45] <LPCIBot> Project devel build (408): STILL FAILING in 5 hr 24 min: https://hudson.wedontsleep.org/job/devel/408/
[16:45] <LPCIBot> * Launchpad Patch Queue Manager: [r=julian-edwards][ui=none][bug=708785] Fix a trivial speeling mistak
[16:45] <LPCIBot> on the 'bug also affects' popup help text.
[16:45] <LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless,
[16:45] <LPCIBot> stevenk][bug=711016] Stop ec2 land from adding [ui=none] to commit
[16:45] <danilos> allenap, no worries :)
[16:45] <LPCIBot> messages, since PQM no longer requires it.
[16:45] <LPCIBot> * Launchpad Patch Queue Manager: [rs=thumper][bug=683798,
[16:45] <LPCIBot> 669288][rollback=12277] Stop deleting recipes when people/teams are
[16:45] <LPCIBot> merged.
[16:45] <danilos> allenap, so, I have this lovely duty of implementing LIFECYCLE direct subscriptions
[16:46] <danilos> allenap, I've so far implemented the way to figure out what a certain change should be notified on
[16:48] <danilos> allenap, like this: https://code.launchpad.net/~danilo/launchpad/lifecycle-subscription/+merge/48185
[16:49] <danilos> allenap, now, I wonder how to best test for any changes in subscribers/bug.py add_notification where I want to use change.change_level directly
[16:50] <danilos> allenap, also, in add_bug_change_notifications there's a few getRecipients calls which all use METADATA as the level
[16:51] <danilos> allenap, and I am not sure how to best modify this
[16:52] <allenap> danilos: Did you say anything between "I've so far implemented ..." and "and I am not sure ..."?
[16:52] <danilos> allenap, I think I did :)
[16:52] <allenap> danilos: Rats, I got knocked off t'internet and bip didn't give me any scrollback.
[16:52] <allenap> danilos: Can you say it again?
[16:53] <danilos> allenap, pasted privately
[16:53] <danilos> allenap, under the assumption that it was you who got knocked off, and not me :)
[16:53] <allenap> danilos: Cool. Erm, can I look at the branch so far?
[16:54] <danilos> allenap, sure thing, it shouldn't be hard to deduce URL from the WIP MP :)
[16:54] <danilos> allenap, and in the MP, you can also see the diff so far, just to get an idea of what I am doing
[16:55] <allenap> danilos: You're making me work :)
[16:55] <danilos> allenap, there is a diff ready to consume at https://code.launchpad.net/~danilo/launchpad/lifecycle-subscription/+merge/48185 :)
[16:55] <danilos> allenap, and ok, lp:~danilo/launchpad/lifecycle-subscription :)
=== deryck[lunch] is now known as deryck
[16:58] <danilos> allenap, the diff so far has no changes to  add_bug_change_notifications (I first want to understand how best to test this, since it seems to be involve zope event machinery or something, and events are fired "manually" in most tests I've seen)
[17:00] <allenap> danilos: It's taking me a while to swap this back in... :)
[17:00] <danilos> allenap, heh, I can understand that, you probably haven't touched this for a few years (it seems most of this code is from 2009)
[17:01] <allenap> danilos: Yeah, we did a sprint for this when BjornT was the team lead and I think the only thing since then is that it's moved into lp.bugs.
[17:01] <danilos> allenap, I am basically looking for the most minimal way to test that notifications are added properly and for the right group of people, before I go on the changing spree...
[17:02] <danilos> allenap, so, my idea is to basically do something like the following change: http://paste.ubuntu.com/561035/
[17:03] <danilos> allenap, however, without knowing exactly what's going on, and without tests that describe how this is properly used, I don't feel comfortable JFDI
[17:04] <allenap> danilos: Okay. I'll try and figure something out.
[17:04] <danilos> allenap, heh, if you've got to dive into code yourself, I don't want to bother you, since I can do the same thing :)
[17:05] <allenap> danilos: I don't mind, but yes, that's what I'm going to do. I can't remember any of it without reading it again, though it might come back quickly.
=== beuno-lunch is now known as beuno
[17:10] <danilos> allenap, sure, if you can do it quickly and come up with a good attack plan, I'd appreciate it; if not, just set yourself a time limit on when to give up :)
[17:17] <gary_poster> allenap: thank you for the review!  I've been looking at options for the deletion.  I wanted to explore __storm_remove__ hook but I don't see any reference to that (in LP code, storm, or https://storm.canonical.com/Manual#Hooks) or anything similar, to my surprise.  Unless you direct me to something I missed, I'll make "delete" or something like that.
=== al-maisan is now known as almaisan-away
[17:17] <gary_poster> following the pattern on the filters themselves
[17:18] <allenap> gary_poster: Sorry for sending you on a wild horse chase... afaik, __storm_remove__ doesn't exist. I was just thinking about it as an idea.
[17:19] <gary_poster> gotcha, allenap.  A good idea :-)
[17:19] <gary_poster> but understood.  I'll go with delete for now then.
[17:19] <gary_poster> Thank you!
[17:19] <allenap> gary_poster: Welcome :)
[17:31] <allenap> danilos: There are no unit tests of add_bug_change_notifications(). I think I'd start some, and simply check that the right set of recipients have notifications added for them. The notify/subscriber machinery should be tested already. It might be even clearer to stub out bug.addChange() to get the recipient list directly, and no faff around with the database.
[17:32] <allenap> danilos: All you really need to know is that the change_level from the IBugChange class is being used when calculating subscribers, isn't it?
[17:33] <danilos> allenap, yeah, but I also need to understand exactly what's going on inside that method so I don't break it as well :)
[17:33] <danilos> allenap, and I want to be able to state with some authority what kind of emails will people get after my changes :)
[17:40] <danilos> allenap, anyway, thanks for looking into it
[17:41] <allenap> danilos: I don't think you'll break it. For this branch I don't think you need to worry about asserting exactly what the end product looks like; the composition of the messages already tested elsewhere. You just need to check that the correct recipients are chosen.
[17:42] <allenap> danilos: One aside: I don't addChangeNotification() is really being used any more, except in bugnotification-sending.txt. I will throw up a branch to remove it.
[17:46] <bigjools> the branch diff overlay on bugs pages is not removable :/
[17:52] <leonardr> sinzui, shall i review https://code.edge.launchpad.net/~sinzui/launchpad/team-membership-policy-1/+merge/48203 ?
[18:06] <danilos> allenap, thanks
[18:10] <sinzui> leonardr: yes please
[18:11] <leonardr> sinzui, changing the order of the enums doesn't affect which numbers they're given behind the scenes?
[18:15] <leonardr> sinzui: i understand the difference between a delegated team and a moderated team but i don't see what difference it makes. are you going to/have you reduced the powers of people who are indirect members of a delegated team?
[18:18] <leonardr> sinzui: was subscription_policy_description simply not used at all? the only place it's referenced here is when you remove it
[18:19] <sinzui> leonardr: all it really does is place the new members in the proposed state. It is an open team with all the restrictions of an open team
[18:19] <sinzui> subscription_policy_description was not used. It has not been used in 18 months
[18:20] <bigjools> jml: merged your branch into mine and it's all hunkydory now, cheerfs
[18:20] <bigjools> and on that note, dinner time
[18:21] <bigjools> nn all
[18:21] <sinzui> leonardr: locoteams is MODERATED now because they want to prevent people and unapproved teams from joining. They think it is fine if people or teams join at a local level.
[18:21] <leonardr> sinzui: so it's an open team that requires approval for direct memberships but not indirect memberships, and there is no functional difference between a direct and an indirect membership?
[18:21] <sinzui> leonardr: correct
[18:22] <leonardr> sinzui: 96 "contol" => "control"
[18:22] <leonardr> also "polcy"
[18:23] <sinzui> ah
[18:24] <leonardr> 166 "verses" => "versus"
[18:24]  * leonardr is more picky about typos in user-visible text
[18:25] <leonardr> sinzui: i see the answer to my first question. you reordered the enums but you didn't change the numbers
[18:26] <sinzui> damn right I did not change the enums. Those are in the database. making moderated teams into open teams will make 1000's of ppas insecure
[18:27] <leonardr> i was just wondering how you had done that
[18:28] <leonardr> sinzui: your split of the __doc__ on line 264 seems a little hacky to me, but it's ok
[18:28] <sinzui> leonardr: Lp forms layout enums by their sequential order. They are easier to read and understand if the rules are changing along one axis
[18:29] <sinzui> yeah. it is wacky. I do not like it. I could not think how to compose the enum from a title and description so that a common description could be shared.
[18:32] <leonardr> sinzui: maybe TestTeamSubscriptionPolicyChoiceCommon.POLICY should be None?
[18:32] <sinzui> That will break one of the tests that creates a team
[18:33] <leonardr> never mind, i thought it was being used as a base class
[18:33] <sinzui> I could either inline the helper logic, or I could change the helper to failover
[18:34] <sinzui> Maybe inheritance is bad in this case because the test was ambiguous
[18:34] <leonardr> i think it's ok
[18:34] <leonardr> i think what tripped me up was the comment
[18:35] <leonardr> # Any policy can be used in set of tests.
[18:35] <sinzui> leonardr: yuck
[18:35] <leonardr> would it be accurate to say "Any policy will work here, so we'll just pick one"
[18:35] <sinzui> yes, that is better
[18:38] <leonardr> sinzui: a little confused about line 598
[18:38] <leonardr> why is cprov now a team owner?
[18:39] <sinzui> that is not the method sig
[18:39] <sinzui> ITeam.addMember(member, review)
[18:40] <sinzui> The team owner is the reviewer adding cprov
[18:40] <sinzui> The "ignore" is a TeamMembership record for the new membership
[18:41] <leonardr> got it
[18:41] <sinzui> The previous code relied on the auto-approved rule in join() for OPEN teams. The problem is that no OPEN team can own a PPA, so the example documentation will actually fail in most circumstances.
[18:42] <leonardr> i understand now. it's fallout from line 589
[18:42] <leonardr> sinzui: r=me with the minor changes mentioned above
[18:43] <sinzui> thanks. my spelling will need fixing in the enum, the html help, and the wiki page because I pasted from the enums
[18:43] <lifeless> moin
[18:44] <sinzui> The pun never ends
[18:45] <leonardr> sinzui: "polcy" and "contol" are only in the help afaik
[18:45] <leonardr> maybe the wiki as well
[18:47] <leonardr> bigjools, i will review https://code.edge.launchpad.net/~julian-edwards/launchpad/double-build-bug-705342/+merge/48219 now
[18:47] <jtv> hi lifeless
[18:48] <lifeless> hi jtv
[18:50] <jtv> lifeless: I didn't find a good way to run external commands in parallel, so wrote up a simple manager class.  Might be something you want to look at: https://code.launchpad.net/~jtv/launchpad/commandspawner/+merge/48226
[18:50] <jtv> I'm going offline now though to deal with other people's IT problems.
[18:51] <lifeless> jtv: did you look at the existing job system code for doing that? or the various twisted things we have?
[18:51] <lifeless> jtv: we can talk later
[18:52] <leonardr> bigjools: what's the difference between a virtual and a nonvirtual builder?
[18:52] <jtv> lifeless: yes, looked at those.
[18:53] <lifeless> leonardr: a nonvirtual one we don't run kvm/xen on; its just a chroot
[18:53] <lifeless> leonardr: policy around those is we only run trusted builds on nonvirtual builders
[18:53] <leonardr> lifeless: you mean that the only builds run on nonvirtual builders are trusted builds?
[18:54] <lifeless> leonardr: yes (that is, ubuntu archive builds rather than PPA builds)
[18:56] <leonardr> lifeless: thanks. bigjools:r=me
[18:58] <leonardr> jtv, lifeless: do you want me to take a look at https://code.edge.launchpad.net/~jtv/launchpad/commandspawner/+merge/48226 or do you want to talk it over first?
[18:58] <lifeless> leonardr: I think you should just review it
[18:58] <leonardr> ok
[18:58] <jtv> leonardr: thanks
[18:58] <lifeless> leonardr: we certainly don't have a look-alike in-tree
[18:59] <lifeless> there's likely something on pypi we could use
[18:59] <lifeless> but whats written is written
[19:01] <lifeless> jtv: if you had time in the future to either incorporate a pypi module, or to factor this out to a truely standalone thing we can publish on pypi, I think either of those things would be most excellent.
[19:02] <jtv> lifeless: that's a good idea, though it lacks all sorts of things that others might want but we currently don't.
[19:03] <lifeless> jtv: sure; we can accept patches for such things :)
[19:03] <jtv> "the Internet will solve it!"
[19:03] <lifeless> https://github.com/taichino/python_prefork is similar
[19:03] <jtv> Oh, sorry, that's Internet 1.0.  The 2.0 phrase is "we'll crowdsource it."
[19:04]  * jtv mumbles something about not needing not steenkin' github projects
[19:04]  * jtv instantly regrets this as github sends chromium into an unusable state
[19:06] <lifeless> oh oracle
[19:06] <lifeless> you sad cats
[19:07] <jtv> lifeless: ?
[19:07] <lifeless> you know about the hudson trademark thing, right ?
[19:07] <jtv> Not enough, evidently.
[19:07] <lifeless> ok, so oracle buy Sun
[19:08] <jtv> yes me knoooo
[19:08] <jtv> me hold share
[19:08] <jtv> but cats?
[19:08] <lifeless> day one they have the hudson lead developer go from a decent work environment - good sized dual lcd yada yada yada, to a puny single screen in a existing oracle block
[19:09] <lifeless> not long later he walks
[19:09] <lifeless> then this trademark thing brews up
[19:09] <lifeless> community voted - 90
[19:09] <lifeless> 90% wanted to rename to get out from under the trademark.
[19:10] <lifeless> overnight a 'susan duncan' from oracle posted a 'hudson will continue as hudson, we have a team @ oracle, come one come all' kind of email.
[19:10] <lifeless> so rather than following 90% of the devs + users, they are going alone, with -1- person that knows the codebase at all.
[19:10] <lifeless> (and who wrote ~ 1% of it)
[19:11]  * jtv nods attentively
[19:13] <jtv> lifeless: so were you using the word "cats" strictly in the sense of "people"?
[19:13] <lifeless> yes, getting my 70's thang on
[19:14] <jtv> Now I see.
[19:14] <jtv> So yes, sad cats indeed.
[19:15] <jtv> How about we pass the hat around and see how much we can offer Michael to change his name?
[19:15] <lifeless> lol
[19:15] <jtv> The prefork thing looks like it would't do much for our use case by the way, though it's hard to say without documentation.
[19:16] <lifeless> its not a direct fit
[19:16] <lifeless> thats for sure
[19:18] <lifeless> jtv: lol; the first two replies to her message: 'unsubscribe'
[19:18] <jtv> <laugh>
[19:20] <jtv> Now if they could re-do it in python, that'd be different.
[19:21] <lifeless> sonatype are going with hudson
[19:21] <lifeless> cloudbees with jenkins
[19:22] <lifeless> wheee
[19:22] <leonardr> jtv: can you make it clear in line 287 that error 11 *is* "resource temporarily unavailable"? i had to look it up to make sure
[19:22] <jtv> leonardr: oh, I thought I'd done that.  Will fix fortwith.
[19:22] <jtv> forthwith.
[19:22] <leonardr> jtv: it's just a little vauge
[19:24] <jtv> leonardr: You're right.  Found a better spelling: errno.EAGAIN!
[19:27] <jtv> Fix pushed.
[19:33] <jtv> leonardr: you may be wondering why, in communicate(), I didn't extract the loop body into a method.  I did that originally, but that hid the fact that I remove an entry from the dict that the loop iterates over—and therefore the reason to iterate over keys() instead of iterkeys().
[19:34] <leonardr> jtv: do you need to iterate over dead processes once they're dead?
[19:35] <jtv> No, I just don't want to upset the iteration.
[19:35] <leonardr> i don't think it matters much, but do i have it right that it's not necessary?
[19:35] <jtv> Yes, you have it right.
[19:35] <jtv> Maybe I'm just being too conservative.
[19:35] <leonardr> i was wondering about test_communicate_returns_after_event
[19:36] <leonardr> what happens to the sleep process? it just keeps running in the background?
[19:36] <leonardr> would it make sense to tear that down?
[19:36] <leonardr> if it's running in the background it's not a big deal
[19:37] <jtv> It does, but that's why I did the self.addCleanup(spawner.kill).
[19:38] <leonardr> thanks, i was looking for a TestCase style teardown
[19:38] <leonardr> ie an actual teardown method in the class
[19:38] <jtv> Though come to think of it… it'd be neater to do actual wait()s for the child processes wouldn't it?
[19:39] <leonardr> i don't know much about this--is wait() blocking?
[19:40] <jtv> Technically it is, I think, but not for long.
[19:40] <jtv> It's been ages, so I'm vague on the details… wasn't un-wait()ed children how you got zombies?
[19:40] <leonardr> jtv, i am also vague on the details
[19:41] <jtv> I can whip up a quick test to find out.
[19:43] <jtv> Yup, that's a zombie.  Need to wait() for it.
[19:44] <leonardr> jtv: will that cause the test to stall for 10 seconds?
[19:44] <jtv> No
[19:44] <jtv> Just keep a zombie process around.
[19:44] <jtv> Which is basically garbage and not nice,
[19:45] <leonardr> jtv: i mean if you wait() will it cause the test to stall
[19:45] <jtv> No, only if the sub-process catches the terminate signal.  Which doesn't happen in the tests.
[19:50] <thumper> morning
[19:51] <jtv> morning thumper!
[19:51] <thumper> jtv: up late?
[19:51] <jtv> thumper: no, in NL
[19:52] <jtv> leonardr: I'm just pushing a change that does a kill()/complete() on all spawners in the acceptance test.  That oughta take care of any zombie danger.
[19:53] <leonardr> i'm glad i could stumble into an improvement
[19:53]  * thumper goes to look at the vast amount of email in the inbox
[19:54] <jtv> leonardr: so am I—I'm not a big believer in permissive reviews. ☺
[19:56] <leonardr> taking a look at your changes now
[19:56] <lifeless> ~/win 63
[19:58] <jtv> I've heard of win64, but…
[20:01] <leonardr> jtv, r=me
[20:01] <jtv> leonardr: thanks!  I'm adding a docstring note to explain about the zombies, but otherwise, should be good to go.
=== lifeless changed the topic of #launchpad-dev to: https://dev.launchpad.net/| PQM is open | firefighting: - | On call reviewer: leonardr  | https://code.launchpad.net/launchpad-project/+activereviews
[20:02] <leonardr> ok
[20:03] <thumper> deryck: ping
[20:03] <lifeless> flacoste: can you high-pri rt 43756 ?
[20:03] <lifeless> flacoste: I have to run to town with Lynne, back in ~3 hrs
[20:03] <thumper> deryck: https://code.launchpad.net/~thumper/lazr-js/multi-line-editor-goodness/+merge/48118
[20:03]  * leonardr could still use reviews of two of his branches
[20:03] <thumper> leonardr: https://code.launchpad.net/~thumper/lazr.restful/only-traceback-system-errors/+merge/48075
[20:04] <thumper> leonardr: what do you need?
[20:04] <leonardr> thumper: hi there
[20:04] <thumper> leonardr: I started on one
[20:04] <thumper> leonardr: the other was still work in progress
[20:04] <deryck> thumper, I didn't have time to look yet.  You wanting me to review it for you?  Or just see what's up?
[20:04] <thumper> leonardr: although I did look through it
[20:04] <leonardr> yeah, i responded to it. the other one is ready now
[20:04] <thumper> deryck: I'm after a real review :)
[20:04] <leonardr> the other one being https://code.launchpad.net/~leonardr/launchpad/web-link/+merge/47258
[20:04] <thumper> deryck: but pointers to what testing may be needed
[20:04] <leonardr> thumper, looking at your lazr.restful branch now
[20:05] <flacoste> lifeless: no permission to view ticket, did you file using launchpad@rt... ?
[20:05] <thumper> deryck: the only JS thing that has really changed is the stripping of trailing whitespace, and hiding the spinner
[20:05] <deryck> thumper, ok, give me a minute, and I'll try to get it before I EOD.
[20:05] <thumper> deryck: thanks
[20:05] <deryck> np
[20:05] <lifeless> flacoste: jam filed it
[20:05] <lifeless> jam: ^
[20:05] <lifeless> flacoste: gone; back later
[20:07] <leonardr> thumper: r=me
[20:07] <thumper> leonardr: your lp weblink branch looks fine to me
[20:07] <thumper> leonardr: shall I mark it needs review?
[20:07] <jml> g'night.
[20:07] <thumper> night jml
[20:07] <leonardr> thumper: yeah, go ahead. i didn't realize that was what was keeping it
[20:08] <thumper> ok
[20:09] <leonardr> gary, i am reviewing https://code.launchpad.net/~gary/launchpad/bug711362/+merge/48232
[20:12] <gary_poster> thank you leonardr
[20:14] <leonardr> gary, i am confused by lambda: self.subscription.delete instead of self.subscription.delete. what's the difference?
[20:15] <leonardr> is it the very attempt to access the delete attribute that causes the exception?
[20:15] <thumper> hmm... I need to configure my local bits to be able to sumbit to lp:lazr.restful
[20:15] <gary_poster> leonardr: yeah, I tried that first too.  yes, exactly
[20:16] <leonardr> thumper: do a bzr co of trunk, then merge in and bzr commit. that's what i do
[20:16] <thumper> leonardr: it isn't pqm managed?
[20:16] <leonardr> thumper: no
[20:16] <thumper> leonardr: ah... ok
[20:16]  * thumper does that
[20:17] <leonardr> we could maybe make it pqm managed again, but it used to be submitting a change to lazr.restful ran the launchpad test suite for no reason
[20:18] <deryck> thumper, so looks good to me.  I would add a js test that the icons are re-enabled on error.  And some text on the example page to explain that it will error every other attempt would be nice.
[20:18] <deryck> thumper, r=me with those changes.
[20:18] <thumper> deryck: ok
[20:18] <leonardr> gary: what do you mean "The original delete fails if it does not remove the filter first"? i don't see that in the code. do you mean that the only way the filter could not be removed is if the delete failed?
[20:19] <flacoste> leonardr, benji: any news on the packaging of the new desktop integration into natty?
[20:19] <leonardr> flacoste: no, i'll ping barry again
[20:19] <flacoste> leonardr: thx
[20:21] <gary_poster> leonardr: the DB rejects the delete of the structural subscription because the database would then be an inconsistent state
[20:21] <gary_poster> (with the filter record pointing to the structural subscription)
[20:22] <leonardr> ok, in that case i'm not sure what 'the original delete' is
[20:23] <gary_poster> leonardr: it removes the filter first in the delete method.  I think "the original delete" is a bad term at least in part because there is no need to call it "original".  I guess I meant something like this:
[20:23] <thumper> wow... the second buildout of lazr.restful was much faster than the first
[20:23] <leonardr> thumper: that's the cache advantage
[20:25] <gary_poster> "Trying to delete the structural subscription without first deleting the filters, as the "delete" method does, would raise a database IntegrityError.  Therefore, we know that the filter really is gone, but we double check it here anyway."
[20:26] <gary_poster> leonardr: and fwiw, this is the exception you would have gotten:
[20:26] <gary_poster> IntegrityError: update or delete on table "structuralsubscription" violates foreign key constraint "bugsubscriptionfilter_structuralsubscription_fkey" on table "bugsubscriptionfilter"
[20:26] <gary_poster> DETAIL:  Key (id)=(5) is still referenced from table "bugsubscriptionfilter".
[20:26] <thumper> leonardr: lazr.restful branch landed \o/
[20:26] <thumper> leonardr: much faster than PQM :)
[20:26] <gary_poster> "as the delete method does" is still confusing :-/
[20:26] <leonardr> gary: ok, that's what i thought was going on. how about this wording
[20:27] <leonardr> "We know that the filter is gone, because we know the subscription is gone, and the database would have prevented the deletion of a subscription without first deleting the filters"
[20:28] <leonardr> "but let's double check"
[20:28] <gary_poster> yes, leonardr
[20:28] <gary_poster> thank you
[20:28] <leonardr> gary, np
[20:29] <leonardr> gary, r=me
[20:29] <gary_poster> Thanks leonardr.  I'm improving the comment now.
[20:29] <gary_poster> I'll also add a comment about the lambda
[20:30] <leonardr> thumper: once my ec2 test completes i will do a lazr.restful release and land the launchpad branch
[20:30] <thumper> leonardr: sounds great
[20:30] <leonardr> i was able to verify that launchpadlib can access web_link if it's present
[20:30] <thumper> leonardr: my editor work has to wait for that to land first
[20:30] <thumper> great
[20:30] <abentley> thumper, chat?
[20:31] <thumper> abentley: sure
[20:31] <thumper> abentley: mumble?
[20:31] <abentley> thumper, yep
=== matsubara is now known as matsubara-afk
[20:52] <jam> flacoste: I just used rt@admin.canonical.com, was I supposed to do something different?
[20:52] <flacoste> jam: yes, please use launchpad@rt.canonical.com, it puts it in the right queue automatically
[20:53] <jam> flacoste: k
[20:53] <jam> that's the first I've heard of that address
[21:00] <leonardr> thumper: got some test failures. some very minor, one possibly serious
[21:00] <thumper> leonardr: oh?
[21:00] <leonardr> thumper: minor ones are tests that had 'launchpad.net' urls instead of 'bugs.launchpad.net' for cves and so on
[21:01] <thumper> ok
[21:01] <thumper> wallyworld_: https://code.launchpad.net/~thumper/lazr-js/multi-line-editor-goodness/+merge/48118
[21:01] <leonardr> the possibly serious one is a launchpadlib test that systematically checks every _link parameter as though it were a link to another launchpad web service object
[21:01] <leonardr> basically, it sees web_link and thinks there must be a corresponding 'web' property
[21:04] <thumper> hmm...
[21:04] <thumper> if it is just a test, surely we could add an exception
[21:04] <thumper> leonardr: mumble?
[21:04] <thumper> StevenK: mumble ping
[21:04] <leonardr> thumper, sure
[21:05] <StevenK> thumper: Coming, sorry
[21:05] <wallyworld_> sinzui: you around?
[21:06] <sinzui> I am
[21:06] <wallyworld_> sinzui:  are you able to sign off on: https://code.launchpad.net/~wallyworld/launchpad/recipe-find-related-branches/+merge/47367
[21:06] <wallyworld_> pretty please :-)
[21:06] <wallyworld_> ui review
[21:07] <sinzui> wallyworld_: You have my approval
[21:08] <wallyworld_> sinzui: thanks! much appreciated
[21:11] <wgrant> abentley: Did you end up reaching agreement with bigjools about where to do notifications?
[21:12] <abentley> wgrant, no, and I am handing off the project to thumper.
[21:12] <wgrant> abentley: Well, from the snippets I read he argued that PU should do the notification. I am adamant that he is wrong, FWIW.
[21:13] <abentley> wgrant, where do you think it should be done?
[21:14] <wgrant> abentley: Build.notify, as it always has been.
[21:16] <abentley> wgrant, cool.
[21:29] <leonardr> thumper: first off, the test failure
[21:29] <thumper> yep...
[21:29] <leonardr> i believe the correct thing to do is to change lazr.restfulclient to interpret 'web_link' as a scalar value, not a link, when producing lists like lp_attributes and lp_entries
[21:29] <leonardr> that's an easy change to make but it's not easy to test
[21:30] <leonardr> so i suggest we file a bug for it, hack similar behavior into the launchpad tests, and land what we have
[21:31] <thumper> leonardr: I'm not entirely clear on the underlying meaning in lazr.restfulclient with respect to the lp_attributes and lp_entries
[21:31] <thumper> and how the web_link fits into it
[21:31] <thumper> is it that web_link will move from lp_entries to lp_attributes?
[21:31] <leonardr> thumper: yes, to put it slightly more accurately, 'web' will move from lp_entries to lp_attributes and will become 'web_link'
[21:32] <thumper> leonardr: that sounds fine to me
[21:32] <leonardr> lazr.restfulclient thinks that anything ending in 'link' is a link to another object comprehensible by lazr.restfulclient
[21:32] <leonardr> in this case it is a link, but not one comprehensible by lazr.restfulclient
[21:32] <thumper> right
[21:32] <thumper> I think special casing it is fine
[21:32] <leonardr> it doesn't have to be all that special
[21:33] <leonardr> we can distinguish ahead of time between comprehensible links and incomprehensible, we've just never had incomprehensible links before
[21:33] <thumper> how do we determine that it is incomprehensible?
[21:34] <leonardr> thumper: by looking at the wadl. web_link has a <param> tag whose <link> element is empty--it doesn't point elsewhere in the wadl
[21:34] <leonardr> in the words of the test failure error, "Parameter is a link, but not to a resource with a known WADL description."
[21:34] <thumper> ok, is this part of the quick fix of the longer bug fix?
[21:34] <leonardr> no, this is the longer bug fix--the problem is testing it
[21:35] <leonardr> we might be able to fake this, but i believe we need to change lazr.restful so that the example web service publishes web_link (right now web_link only shows up in unit tests)
[21:35] <thumper> so to be clear, we can make the fix quickly, and file a bug for the testing of it?
[21:35] <leonardr> thumper: i was suggesting fixing it in launchpad, but yeah, we can fix it for real pretty easily
[21:36] <thumper> leonardr: does the restfulclient *need* lazr.restful example service to publish web_link?
[21:36] <thumper> I would think that a fake would be better
[21:36] <leonardr> thumper: that's how we do the tests. i would prefer a fake as well, but i don't think we have the infrastructure for it
[21:37] <thumper> ah.. the tests for lazr.restfulclient depend on the lazr.restful example server?
[21:37] <leonardr> yes, they are integration tests making simulated http requests and getting responses
[21:37] <leonardr> we can do unit tests in lazr.restful but not so much in the client, i think
[21:38] <thumper> I'm thinking of a potential solution...
[21:38] <thumper> it may be completely off though
[21:39] <leonardr> let's hear it
[21:39] <thumper> what if, as part of the tests for restfulclient, we had a decorated server, that intercepts the calls to the example restful server and annotates it with a web link?
[21:39] <leonardr> thumper: it would be simpler to make the example server serve a web link for real
[21:40] <thumper> probably
[21:41] <leonardr> actually, i could probably work something up with a fake wadl document
[21:41]  * thumper likes fakes (of a certain kind)
[21:41] <leonardr> that would be closer to a unit test
[21:42] <leonardr> since there is no data going over the wire
[21:42] <leonardr> it's just restfulclient making judgements about the structure of the web service based on the wadl
[21:43] <leonardr> barry: lazr.restfulclient in natty is up-to-date
[21:43] <leonardr> so don't worry about that
[21:46] <StevenK> wgrant: Have we seen the test_404 and one other failures in ec2 before?
[21:46] <leonardr> thumper: two possibilities, your call
[21:46] <wgrant> StevenK: i've seen them once.
[21:46] <wgrant> And they've appeared on Hudson
[21:46] <wgrant> But they only appear often on buildbot.
[21:46]  * thumper nods
[21:46] <leonardr> 1. i'll fix the failing tests in launchpad, get my branch into ec2 land, and fix it in restfulclient tomorrow
[21:46] <leonardr> 2. i'll fix it in restuflclient tomorrow and land everything tomorrow
[21:46] <StevenK> wgrant: What do you think? Resubmit and hope ec2 is kinder?
[21:47] <thumper> leonardr: what breaks if we go for 1 ?
[21:47] <wgrant> StevenK: I'd just go to lp-land if they were the only failures.
[21:47] <thumper> leonardr: just test failures in lazr.restfulclient?
[21:47] <leonardr> thumper: launchpad contains code to work around the problem for a little while
[21:48] <thumper> leonardr: what is the impact of that though?
[21:48] <leonardr> thumper: not much. just "this is hacky"
[21:49] <thumper> leonardr: lets land everything when it is good to work together
[21:49] <leonardr> thumper: ok, that will be my goal for tomorrow
[21:49] <thumper> ok
[21:49] <leonardr> i'd like to hear your suggestions for what to do after that
[21:50] <thumper> leonardr: i was looking at the lazr.restful errors
[21:50] <thumper> well, bugs, not errors
[21:50] <leonardr> right
[21:50] <thumper> bug 619180 is listed as critical, and probably not too much
[21:50] <_mup_> Bug #619180: UnicodeEncodeError creating a team that contains non-ASCII on name via API <api> <lp-foundations> <oops> <lazr.restful:Triaged> < https://launchpad.net/bugs/619180 >
[21:51] <thumper> also, bug 373370 looks like it should be a good to do candidate
[21:51] <_mup_> Bug #373370: Text fields can be made empty via the API, but not via the web UI <api> <lp-foundations> <Launchpad itself:Triaged> <lazr.restful:Triaged> < https://launchpad.net/bugs/373370 >
[21:51] <leonardr> thumper: ok, i'll take a look. may be lazr.restful, may be launchpad
[21:51] <thumper> leonardr: understood
[21:52] <huwshimi> leonardr: Thanks for approving my branch.
[21:52] <leonardr> huwshimi: np
[21:52] <wgrant> Any idea why staging is out of date?
[21:52] <thumper> leonardr: the example given in bug 619180 actually has unicode in the name, which would hit a validation error
[21:52] <_mup_> Bug #619180: UnicodeEncodeError creating a team that contains non-ASCII on name via API <api> <lp-foundations> <oops> <lazr.restful:Triaged> < https://launchpad.net/bugs/619180 >
[21:52] <wgrant> There's nothing in the logs since the last update finished several hours ago.
[21:52] <thumper> leonardr: I wouldn't expect a unicode encode error though
[21:53] <thumper> my guess is that it should be a 400 Bad input type error rather than an oops
[21:53] <wgrant> Hmm. It's possible that it's a Launchpad issue, and the exception's __str__ is trying to do bad things.
[21:54] <thumper> wgrant: could be
[21:54] <leonardr> thumper: that says to me that validation code is not running, since errors during validation are turned into 400s
[21:54] <wgrant> leonardr: This seems to be a UnicodeEncodeError while reporting the validation failure, right?
[21:55] <thumper> leonardr: perhaps with our change several weeks ago, to fix the validation, it may now fail better :)
[21:55] <wgrant> thumper: I reproduced it when I reassigned it.
[21:55] <wgrant> It's still present.
[21:55] <thumper> wgrant: from when?
[21:55] <leonardr> i guess i should have looked more carefully at the traceback
[21:55] <leonardr> yeah, it's an error presenting the validation error
[21:56] <wgrant> thumper: Hm? I reproduced it like 3 days ago.
[21:56] <thumper> could be
=== almaisan-away is now known as al-maisan
[22:06] <StevenK> wgrant: Did you tag the other bug too?
[22:12] <wgrant> StevenK: Yes.
[22:12] <wgrant> To unbreak qa-tagger.
=== al-maisan is now known as almaisan-away
[22:12] <StevenK> wgrant: Yes, I just got the mail, thanks.
[22:12] <wgrant> It needs bad-commit-* for the rollback to be effective.
[22:12] <thumper> abentley: is there a bug for this?
[22:12] <wgrant> I had to read the code to find out why it wasn't working :/
[22:13] <StevenK> wgrant: :-/
[22:13] <StevenK> wgrant: Aside from Henning, it looks like your QA
[22:15] <abentley> thumper, you mean bug #681125?
[22:15] <_mup_> Bug #681125: Async uploader sends recipe mail as if it were source package uploads <lp-code> <qa-ok> <recipe> <Launchpad itself:Triaged> < https://launchpad.net/bugs/681125 >
[22:15] <wgrant> StevenK: Yup.
[22:15] <wgrant> StevenK: But qastaging's codebrowse is either broken or not there, and staging is one rev too old.
[22:15] <thumper> abentley: yep, thanks
[22:16] <StevenK> wgrant: So tempted to reply 'lolwut'
[22:17] <wgrant> abentley: To be clear, your recipe mail changes at the head of the deployment queue are still OK to roll out?
[22:17] <wgrant> Despite the current debate?
[22:17] <abentley> wgrant, yes.  My current changes are deployable, but an incomplete fix.
[22:18] <wgrant> Great, thanks.
=== leonardr changed the topic of #launchpad-dev to: https://dev.launchpad.net/| PQM is open | firefighting: - | On call reviewer: -  | https://code.launchpad.net/launchpad-project/+activereviews
[22:31] <sinzui> wgrant: mumble?
=== StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/| PQM is open | firefighting: - | On call reviewer: StevenK | https://code.launchpad.net/launchpad-project/+activereviews
[22:44] <jcsackett> sinzui: you want to continue on Person:+bugs, or just catch up tomorrow?
[22:45] <huwshimi> wgrant: Your mumble stutters quite a bit for me, but everyone else sounds fine. Is everyone clear for you?
[22:45] <wgrant> huwshimi: Hm... Everyone's clear for me, and I sounded clear enough from the feedback I heard through sinzui's mic.
[22:46] <wgrant> Odd.
[22:46] <huwshimi> wgrant: yeah that is odd
[22:47] <wallyworld_> wgrant: are you testing rev 12290? - it's currently blocking subsequent rollouts
[22:47] <wgrant> sinzui/jcsackett: Was my mumble connection OK?
[22:47] <wgrant> wallyworld_: I am waiting on a LOSA to unbreak qastaging codebrowse. I have a nodowntime rollout request for 12293 in my clipboard :)
=== salgado is now known as salgado-afk
[22:48] <wallyworld_> wgrant: thanks :-) just trying to get ready for pqm closure on friday
[22:52] <jcsackett> wgrant: yeah, you sounded fine.
[23:13] <huwshimi> sinzui: I fixed my css issue
[23:13] <huwshimi> sinzui: How do I go about using the sprites?
[23:55] <sinzui> huwshimi: drop the new image into lib/canonical/launchpad/images . Add a new class to lib/canonical/launchpad/icing/style-3-0.css.in (the comment is required)
[23:58] <sinzui> huwshimi: run make sprite_image then make css_combine to see your change
[23:58] <wgrant> StevenK: Could you review https://code.launchpad.net/~wgrant/launchpad/bug-654585-linkify-bug-acknowledgement/+merge/48254?
[23:58] <StevenK> Can I get bzr di to give more context with it's diffs? The manual page and bzr di --help weren't very helpful
[23:59] <wgrant> StevenK: I don't think it can do it directly, but you could use --diff-options.