[00:00] <LPCIBot> Project db-devel build #764: STILL FAILING in 6 hr 2 min: https://lpci.wedontsleep.org/job/db-devel/764/
[00:17] <wallyworld> jtv: you back on board yet?
[00:56] <poolie> wallyworld: hello, can you review https://code.launchpad.net/~xaav/loggerhead/export-tarball/+merge/66408
[00:57] <poolie> and merge it if appropriate
[00:58] <wallyworld> poolie: sure
[00:58] <wallyworld> that one was marked as needing info for a while i think
[00:59] <poolie> it stalled for a bit
[01:00] <poolie> if people push and don't ask for more review it's easy for things to get stuck
[01:12] <poolie> which is https://bugs.launchpad.net/launchpad/+bug/745469 i guess
[01:12] <_mup_> Bug #745469: please send notifications when merge page has been updated with new revisions <code-review> <Launchpad itself:Triaged> < https://launchpad.net/bugs/745469 >
[01:23] <wallyworld> poolie: in the above case, i normally add a comment to the mp explaining what i did and why and how it relates to any previous request for change
[01:23] <wallyworld> this causes an email to be sent
[01:23] <poolie> yup
[01:23] <poolie> it's not obvious that you ought to do this though
[01:23] <poolie> ought/need
[01:23] <wallyworld> too true
[01:39] <lifeless> fixing up aaron's incremental diff thing will address that - and get sensible incremental diffs with merges from trunk (which the loggerhead based diff thing does not do)
[01:49] <LPCIBot> Project devel build #928: STILL FAILING in 5 hr 37 min: https://lpci.wedontsleep.org/job/devel/928/
[02:28] <wallyworld> lifeless: can you +1 this? i'm not 100% familar with loggerhead etc but it seems reasonable and has had a lot of input already.... https://code.launchpad.net/~xaav/loggerhead/export-tarball/+merge/66408
[02:32] <poolie> thanks wallyworld
[02:33] <poolie> to merge it, when you're ready, you should be able to just merge into lp:loggerhead
[02:33] <poolie> and i guess it would be good to deploy that to lp too
[02:33] <wallyworld> poolie: np. i'll clean up the lint first
[02:34] <wallyworld> poolie: i may need to ask for help deploying - i've had nothing to do with loggerhead so far :-)
[02:46] <poolie> np
[02:46] <poolie> i'm getting "lib/canonical/launchpad/icing/yui/yui/yui.js" in my lp checkout
[02:47] <poolie> oh, a broken symlink or something, isn't it
[02:50] <wallyworld> poolie: likely. a make clean will fix it
[02:50] <wallyworld> will || should
[05:06] <lifeless> are there any tests of the personmerge view other than the doctest ?
[05:41] <LPCIBot> Project db-devel build #765: STILL FAILING in 5 hr 40 min: https://lpci.wedontsleep.org/job/db-devel/765/
[05:49] <lifeless> hahaha
[05:50] <wgrant> ?
[05:50] <lifeless> -> ops
[06:15] <lifeless> wgrant: are there unit tests for person.merge() ?
[06:17] <wgrant> I doubt it. But let's see..
[06:17] <lifeless> I can't see any in test_person
[06:18] <wgrant> There is a _do_merge in test_person.
[06:18] <wgrant> Is that not relevant?
[06:18] <wgrant> I haven't actually seen anything beyond its existence.
[06:18] <lifeless> nothing in there looking for notifications that I can see
[06:18] <lifeless> which is what I'm touching
[06:18] <wgrant> :/
[06:29] <lifeless>  and \o/
[06:33] <lifeless> can has review ?
[06:33] <lifeless> https://code.launchpad.net/~lifeless/launchpad/bug-761874/+merge/69748
[06:44] <lifeless> wgrant: ^ or wallyworld ^
[06:44] <lifeless> wallyworld: I will look at the loggerhead thing monday; it requires some pagination
[06:44] <wallyworld> lifeless: ok, thanks. will look at your mp
[06:44] <lifeless> wallyworld: deployment is the usual thing - update the version we use, and qa that once that commit hits qa-staging
[06:44] <wallyworld> ok
[07:21] <poolie> cheerio wallyworld
[07:21] <poolie> what's the idiomatic way to html-escape things in lp python code?
[07:22] <wgrant> Don't do it.
[07:22] <wallyworld> poolie: i'll do that mp on monday when it gets +1ed
[07:22] <wgrant> poolie: What are you trying to do?
[07:22] <wgrant> Escaping is usually the wrong thing.
[07:22] <wallyworld> wgrant: you want to mentor: ://code.launchpad.net/~lifeless/launchpad/bug-761874/+merge/69748 ?
[07:23] <poolie> wgrant: test_scope_documentation_displayed is checking that the feature scopes are in the browser.contents
[07:23] <poolie> it's failing to find them, i think because the new one i've added contains angle brackets
[07:23] <wgrant> Ah, so this is in a test?
[07:23] <wgrant> Just use cgi.escape.
[07:23] <poolie> heh :) ok
[07:24] <LPCIBot> Project devel build #929: STILL FAILING in 5 hr 34 min: https://lpci.wedontsleep.org/job/devel/929/
[07:24] <poolie> i agree with not having random escaping and unescaping in  production code
[07:35] <adeuring> good morning
[07:42] <poolie> hi abel
[07:42] <poolie> could someone do a review for me, on https://code.launchpad.net/~mbp/launchpad/mail-scope/+merge/60281
[07:52] <adeuring> poolie: I'll look
[07:53] <poolie> thanks
[07:55] <lifeless> wallyworld: still here ?
[07:55] <lifeless> wallyworld: you asked for create to mention delete, but I do that in my patch already.
[07:55] <lifeless> wallyworld: do you mean you want the interface to talk about implementation ?
[07:55]  * lifeless loads the question
[07:57] <adeuring> lifeless: could you have a look at this mp: https://code.launchpad.net/~adeuring/launchpad/bug-739052/+merge/69625
[08:01] <lifeless> adeuring: hahha, on friday night no less.
[08:01] <lifeless> adeuring: great stuff
[08:01] <adeuring> lifeless: thanks!
[08:12] <bigjools> morning
[08:14] <poolie> o/
[08:15] <mrevell> hallo there bigjools
[08:26] <poolie> ok, good night
[08:41] <lifeless> adeuring: reviewed
[08:42] <adeuring> lifeless: thanks!
[08:52] <lifeless> adeuring: no probs
[08:53] <bigjools> wgrant: need a chat with you
[09:05] <bigjools> adeuring: morning!  I have a lovely branch for you if you can take it please?
[09:05] <adeuring> bigjools: sure
[09:06] <bigjools> adeuring: https://code.launchpad.net/~julian-edwards/launchpad/utf-codes-in-emails-bug-817106/+merge/69758
[09:06] <wgrant> bigjools: Not entirely here, but what's up?
[09:07] <bigjools> wgrant: I wanted to talk about the no-builds-in-progress check in the IDSJ, and whether/how we should fix the packagecopier
[09:07] <bigjools> I am very concerned
[09:08] <wgrant> Your concern is well-placed.
[09:09] <bigjools> wgrant: so I'd rather mumble/skype.  If now is bad, next week is ok.
[09:09] <wgrant> bigjools: Next week is probably best, sorry.
[09:09] <bigjools> not a problem
[09:09] <bigjools> thanks
[09:10] <adeuring> bigjools: the diff on the MP page shows a minor merge conflict
[09:12] <bigjools> adeuring: ah I'll fix that, thanks
[09:22] <bigjools> adeuring: conflict fixed, just waiting for the branch scanner
[09:22] <adeuring> bigjools: thanks
[09:38] <adeuring> bigjools: r=me
[09:38] <bigjools> adeuring: thank you sir.  Did the unicode stuff look ok?  I figured you'd have more experience of that than me :)
[09:39] <adeuring> bigjools: as I wrote in the MP, we used something like u'Lo\u2345c' and avoided the "coding: utf-8" line at the top
[09:39] <bigjools> ah ok
[09:39] <adeuring> bigjools: but
[09:39] <adeuring> I thin k we can really switch to the way you did it
[09:40] <bigjools> I took inspiration from a different python file in our tree
[09:40] <adeuring> bigjools: even better then :)
[09:40] <bigjools> Loïc looks better than Lo\u2345c huh? :)
[09:40] <adeuring> there is a small risk that somebody uses an editor which does not understnd utf-8
[09:40] <adeuring> but I am not aware of any such editors...
[09:41] <bigjools> yeah - I had issues with Vim but then it seems all ok with it today :/
[09:41] <adeuring> bigjools: and yeah, this '\u3456' looks really ugly and is sometimes hard to understand
[09:42] <bigjools> indeed
[09:42] <jml> lifeless: can you please merge: lp:~jml/python-fixtures/misc-fixes
[09:43] <adeuring> I think Python supports also something like "LATIN_CAPITAL_A_WITHDIERESIS" with some escape mechanism but that's not much better than \u1234
[09:44] <bigjools> heh
[09:44] <bigjools> it is a total minefield
[09:47] <adeuring> bigjools: not such a big pitfall as some Qt unicode -> string conversion method (can't remember which one exactly) It gave you ISO8859-1 strings by default. Was quite annoying for any language spoken that did not originate in western europe
[09:48] <bigjools> adeuring: nice.
[10:14] <cjwatson> https://dev.launchpad.net/LaunchpadPpa says "The current development series [...] (currently: natty)" and "The current release [...] (currently: maverick)"
[10:15] <cjwatson> should that be changed to oneiric and natty respectively now?
[10:15] <wgrant> Indeed. It does work on oneiric.
[10:17] <cjwatson> launchpad-dependencies has versions 0.95~oneiric1, 0.95~natty1, 0.95~lucid1.  lp:meta-lp-deps only has 0.95.  Is that done by hand?  How do you deal with different versions of dependencies in different releases?
[10:17] <bigjools> jtv: the expander sections on the queue syncs look nicer now
[10:17] <cjwatson> oh, hm, https://code.launchpad.net/~launchpad/+recipe/meta-lp-deps-on-demand
[10:17] <jtv> bigjools: Thanks.  Actually expanding does look more appropriate on an expander, does it not?
[10:18] <bigjools> jtv: generally :)
[10:18] <jtv> BTW it looks like the other expanders don't get the colspan quite right.
[10:19] <jtv> My eye keeps expecting a link where the archive name is.  Is there anything to link to?
[10:19] <wgrant> cjwatson: Right, that recipe is used. The deps are identical between series these days, though, so the series-specific sources are unnecessary.
[10:19] <cjwatson> I guess I can use substvars to force the right versions of apt/python-apt
[10:20] <cjwatson> cleaner than series-specific sources
[10:20] <wgrant> Slightly.
[10:20] <wgrant> maverick doesn't have a sufficient version?
[10:20] <cjwatson> no
[10:21] <wgrant> That is inconvenient.
[10:21] <cjwatson> bigjools has copied stuff into the PPA now (including maverick), but I assume that that won't necessarily get upgraded without forcing versions in lp-deps
[10:21] <wgrant> Sometimes we force it, sometimes we don't...
[10:22] <cjwatson> Should I just not bother?
[10:23] <wgrant> Probably not. Only the two buildbots + cocoplum really need it.
[10:23] <wgrant> And we can ensure that those are correct easily.
[10:23] <wgrant> And it avoids the substvar mess.
[10:24] <cjwatson> it's mildly inconvenient that cocoplum doesn't seem to have the Launchpad PPA in sources.list
[10:24] <wgrant> Right, the DC machines use CAT.
[10:24] <wgrant> We generally import stuff from the PPA into CAT.
[10:24] <cjwatson> so I should RT that?  it's just for apt/lucid
[10:24] <wgrant> Not sure. LOSAs ^^?
[10:25]  * mthaddon catches up
[10:26] <mthaddon> yeah, an RT asking for it to be uploaded to the -cat repos and installed would be good
[10:26] <cjwatson> OK
[10:26] <mthaddon> cjwatson: unf we can't install directly from PPAs on servers in the DC as that would basically mean a compromise of LP would root all DC servers
[10:26] <mthaddon> s/would/could/
[10:26] <wgrant> Erm...
[10:26] <wgrant> You know what controls the Ubuntu archive, yeah? :)
[10:27] <mthaddon> well, that's true, but it's a slightly different case
[10:27] <wgrant> The security of the primary archive is less tested, yes.
[10:29] <cjwatson> I'd normally use the ubuntu-platform@ RT address, but I assume I should use the launchpad@ address in this case ...
[10:31] <cjwatson> wgrant: assuming that the buildbots are up to date or will update, then https://code.launchpad.net/~cjwatson/launchpad/dpkg-xz-support-619152 could be landed now, I believe
[10:32] <wgrant> cjwatson: Has it been through ec2 lately?
[10:33] <cjwatson> No
[10:34] <bigjools> wgrant: can you help the dude in #launchpad?
[10:45] <cjwatson> mthaddon: done, RT#47110
[10:45] <_mup_> Bug #47110: [UNMETDEPS] php4-yaz links against old libmysqlclient <php4-yaz (Ubuntu):Fix Released> < https://launchpad.net/bugs/47110 >
[10:45] <mthaddon> thx
[10:47] <mthaddon> cjwatson: do you know if this has been tested on staging/dogfood?
[11:05] <allenap> adeuring: Would you be able to review a mostly JavaScript branch for me? https://code.launchpad.net/~allenap/launchpad/localpackagediffs-filter-by-person-or-team-bug-798873-ui/+merge/69766
[11:05] <adeuring> allenap: sure
[11:06] <allenap> Thanks :)
[11:06] <allenap> adeuring: I am going to get some lunch now but I'll try to watch for pings. Is that okay? If not, leave it for later when I'm back.
[11:07] <adeuring> allenap: then let me ytart my lunch break too before I start to look at the mp :)
[11:07] <allenap> adeuring: Cool :)
[11:24] <LPCIBot> Project db-devel build #766: STILL FAILING in 5 hr 43 min: https://lpci.wedontsleep.org/job/db-devel/766/
[11:29] <bigjools> """Gina's changelog parser and muncher for great justice"""
[11:53] <jml> am thinking of doing work to address / mitigate https://bugs.launchpad.net/launchpad/+bug/814725
[11:53] <_mup_> Bug #814725: No feedback between upload & acceptance/rejection <Launchpad itself:Triaged> < https://launchpad.net/bugs/814725 >
[11:53] <jml> james_w suggested adding an API method for upload
[11:54] <jml> any thoughts from folk here? bigjools? wgrant? StevenK?
[11:54] <bigjools> jml: it's not a trivial problem
[11:55] <wgrant> Until we have a message queue.
[11:55] <bigjools> an API for upload is not going to work, it'll time out
[11:55] <wgrant> Until then, best not to think about it :)
[11:56] <bigjools> we need to decide what feedback people would be happy with
[11:56] <jml> bigjools: so the timeout starts from 'request received'?
[11:56] <jml> or rather, request started
[11:56] <jml> rather than, say, request finished
[11:57] <wgrant> jml: The processing itself can easily take many seconds.
[11:57] <bigjools> jml: to make sure we're talking about the same thing, is that a webservice API?
[11:57] <bigjools> s/seconds/minutes/
[11:57] <jml> bigjools: yes.
[11:57] <jml> why minutes?
[11:57] <bigjools> jml: ok, that will never work.  we need a different transport
[11:58] <bigjools> jml: the upload processor has to unpack the package
[11:58] <bigjools> that can take a loooong time
[11:58] <jml> why does it need to do that?
[11:58] <bigjools> to verify its contents
[11:58] <wgrant> It should never take minutes, but it can have to un-xz and un-bz2 a few hundred megabytes :/
[11:58] <bigjools> "should" :)
[11:59] <bigjools> jml: at a stretch we could make poppy poke something into the database to say "pending uploads +=1" and then make the upload processor decrement that.  Then the UI can show something.
[12:00] <bigjools> not sure of the ramifications of that though
[12:00] <jml> bigjools: well, there are other checks that are fast to do that the user would be well served to be told about sooner
[12:00] <jml> e.g. permission checks
[12:00] <bigjools> jml: yes, they are all done first
[12:01] <wgrant> I have considered deferring the extraction to a job.
[12:01] <jml> bigjools: yeah, but currently asynchronously
[12:01] <wgrant> We could possibly get away with removing a couple of the pedantic checks on the extracted package.
[12:01] <bigjools> jml: I think it doesn't try to unpack unless all the other stuff passes
[12:01] <jml> I can't see any mention of tarfile in archiveuploader
[12:01] <wgrant> And then do the file retrieval async.
[12:01] <wgrant> jml: Hahah
[12:01] <wgrant> dpkg-source
[12:01] <bigjools> anyway - there's a load of bugs which means it'll just OOPS
[12:01] <wgrant> Not that easy :)
[12:01] <jml> wgrant: ah, ok. got it.
[12:02]  * bigjools has deja vu
[12:02] <wgrant> archiveuploader is a bit special.
[12:02] <wgrant> Not gina-special.
[12:02] <wgrant> But still fairly special.
[12:02]  * bigjools found a horrible bug in gina
[12:02] <bigjools> it doesn't help when the doctest that checks for output format doesn't have a -NORMALIZE_WHITESPACE :/
[12:03] <jml> afaict, the verification here is just for 'single directory', 'changelog' and 'copyright'
[12:03] <jml> I guess dpkg-source might do verification that the code implicitly relies on.
[12:04] <wgrant> bigjools: While you're there, want to fix archiveuploader's changelog_entry generation?
[12:04] <bigjools> what aspect?
[12:04] <wgrant> jml: Right. dpkg-source does a lot of checks.
[12:04] <jml> why not check the first by listing the tarball contents, and get the other two by just extracting those files?
[12:05] <wgrant> jml: But if we accept an invalid package, it will just fail to build, so it's not that bad.
[12:05] <wgrant> Extracting those files how?
[12:05] <wgrant> We'd have to be able to unpack all the source formats.
[12:05] <wgrant> Untar + diff
[12:05] <wgrant> Or untar + untar
[12:05] <wgrant> Or whatever they come up with next.
[12:05] <bigjools> accepting invalid packages to the build farm is nuts, don't do that
[12:06] <wgrant> bigjools: They are rare and will just end up FAILEDTOBUILD. It's not *that* bad.
[12:06] <bigjools> it's build time wasted
[12:06] <jml> wgrant: hmm. I see. I guess you'd have to patch upstream to provide the feature.
[12:06] <bigjools> disk space wasted
[12:06] <bigjools> and crufty
[12:06] <jml> bigjools: every successful check is wasted CPU too
[12:07] <bigjools> reject early, reject often
[12:07] <bigjools> jml: no, it's just getting deferred
[12:10] <bigjools> the later you reject in a pipeline that has a lot of steps, the harder it is to produce a decent error message
[12:11] <jml> Certainly failing early is good.
[12:11] <jml> But if you are doing an expensive check early that is also implicitly done in later steps, you are penalizing successful cases to help the bad ones.
[12:12] <bigjools> in this case I disagree; you're just pushing the penalty to later on
[12:14] <wgrant> Perhaps we should get some data.
[12:14] <jml> but it's actually making it take longer, isn't it? Or is the output of dpkg-source in the upload check saved so that the build farm doesn't need to run it?
[12:15] <wgrant> I suspect it's very rare that dpkg-source fails.
[12:15] <jml> wgrant: yeah, that'd be interesting to see.
[12:15] <jml> funnel graphs
[12:15] <wgrant> No, all the buildds have to rerun it.
[12:15] <bigjools> so assuming most uploads are actually OK, then you're right.  But yeah we need data on that.
[12:16] <bigjools> I still think we need to check this stuff :)
[12:17] <wgrant> I'm also not quite sure on how a webservice API would work here.
[12:17] <bigjools> it wouldn't
[12:17] <wgrant> I guess you'd upload files to the librarian and then fire off an MQ-based job.
[12:17] <wgrant> It's doable, and should be done eventually :)
[12:18] <bigjools> please not the librarian
[12:18] <wgrant> They would have a <24h expiry.
[12:19] <bac> hola abel
[12:19] <jml> still probably need a  MQ though.
[12:19] <bigjools> the way we do it is fine.  We can make poppy send a message to something to kick off processing
[12:19] <bigjools> I'd like to parallelise per archive (up to a max thread count)
[12:20] <wgrant> Indeed.
[12:20] <wgrant> It would be nice if Python did threads :/
[12:20] <bigjools> heh
[12:21] <wgrant> Maybe by the time we have a MQ-based jobrunner we will have moved to PyPy.
[12:21]  * bigjools can't believe this changelog parsing bug has been in Gina so long
[12:21] <jml> well
[12:21] <bigjools> wgrant: haha
[12:22] <jml> we'll see what I actually need to get my thing done.
[12:23] <bigjools> jml: in lieu of a message, another solution would be to have some sort of pending upload indicator in IArchive which poppy increments and the upload processor decremements
[12:23] <wgrant> jml: Recipes!
[12:23] <jml> wgrant: I asked for in-page updates for async jobs for every feature LP did since January 2010.  Including recipes.
[12:23] <bigjools> jml: when we finish DDs, we'll be finishing *that* :)
[12:24] <jml> bigjools: looking forward to it.
[12:24] <bigjools> hellyes
[12:24] <wgrant> Bug #628738
[12:24] <_mup_> Bug #628738: SourcePackageRelease.changelog_entry now incorrectly generated <lp-soyuz> <soyuz-upload> <Launchpad itself:Triaged> < https://launchpad.net/bugs/628738 >
[12:24] <wgrant> bigjools: That's the bug.
[12:25] <wgrant> (also not caught because of NORMALIZE_WHITESPACE, IIRC)
[12:25] <bigjools> yay
[12:25] <bigjools> different problem to the one I am fixing though
[12:25] <wgrant> doctests, yay
[12:25] <wgrant> Yeah.
[12:25] <bigjools> there's nothing like testable documentation
[12:26] <bigjools> and our doctests are nothing like testable documentation
[12:26] <jml> except maybe burgers with turds in them.
[12:26]  * bigjools blinks
[12:28] <adeuring> allenap: r=me
[12:28] <allenap> Thanks adeuring :)
[12:32] <bigjools> wgrant: do you know if iron is in NDT?
[12:32] <wgrant> bigjools: It is.
[12:32] <wgrant> mcmurdo too.
[12:32] <bigjools> good
[12:33] <bigjools> I love the way that someone thought that list.append(string) included a newline
[12:33] <wgrant> ftpmaster, ppa, librarian, librarian2, mailman, codehosting are not in nodowntime.
[12:33] <wgrant> Everything else is.
[12:33] <wgrant> mailman might be as of 12 hours ago. I forget.
[12:34] <wgrant> And codehosting will be on monday.
[12:34] <wgrant> Shall be good.
[12:34] <bigjools> woo
[12:46] <cjwatson> mthaddon: TTBOMK it has not
[12:46] <mthaddon> cjohnston: ok, I've added a note to the ticket that we should do that first, so we'll make it so
[12:46] <cjwatson> great, thanks
[12:47] <jml> cjwatson: that's a new acronym for me.
[12:47] <jml> excellent. no more learning required from me for the rest of the day.
[12:53]  * cjwatson prescribes jml alcohol
[12:53] <cjwatson> mthaddon: do I need to take that backlogged message seriously, or is it automatic irrelevancy?
[12:54] <mthaddon> cjwatson: it basically just means it hasn't been directly assigned to someone yet, but I've given in a priority, and if that needs bumping up it can be done at any time
[12:54] <mthaddon> s/given in/given it/
[12:54] <jml> cjwatson: with prescriptions like that, perhaps there's more to be said for private medical practitioners than I had previously thought!
[12:54] <cjwatson> mthaddon: ok, cool
[13:08] <deryck> Morning, all.
[13:42] <jtv> Hi bac!  Free for a review?  I've got this: https://code.launchpad.net/~jtv/launchpad/bug-818032/+merge/69791
[13:43] <bac> jtv: sure
[13:43] <jtv> Thanks.
[13:45] <bac> jtv: did you have any pre-implementation discussions about this bug and branch?
[13:45] <jtv> bac: yes, hence the "pre-implementation notes" :)
[13:45] <jtv> With Julian, to be precise.
[14:01] <bac> jtv: ok.  since you didn't list any one in that section i wanted to find out.
[14:04] <jtv> bac: in retrospect I see I wasn't very helpful in that section, sorry.
[14:04] <bac> jtv: looks good.  thanks!
[14:04] <jtv> thank you.
[14:27] <abentley> adeuring or bac: could you please review https://code.launchpad.net/~abentley/launchpad/fix-lpviews/+merge/69800 ?
[14:27] <bac> abentley: i will
[14:27] <adeuring> bac: you bebat me :)
[14:27] <abentley> bac: I have fixed the lint.
[14:27] <bac> i did bebat you!
[14:39] <bac> abentley: done.  good catch.
[14:40] <abentley> bac: thanks.
[14:40] <bac> i didn't realize we had pages using the zope default
[15:04] <jcsackett> sinzui: i see that you are working on 800361. i just unassigned myself from that in lp; shall i assign you?
[15:06] <sinzui> jcsackett, I suppose
[15:07] <jcsackett> sinzui: is there a reason i shouldn't? i only unassigned myself b/c i'm not currently working further on it after UI tests and thought someone else might have the time to do it. which seemed to be you.
[15:08] <sinzui> jcsackett, I have been very distracted the last two days and have made no progress. If I am distracted today, I will give up the work to wallyworld. This is critical path work and I not certain I should ever be on the critical path
[15:08] <jcsackett> sinzui: ok. leave it till monday and decide then?
[15:09] <sinzui> jcsackett, I have been working to unblock others. I am participating in the product strategist interviews
[15:09] <jcsackett> sinzui: aaah.
[15:09] <sinzui> jcsackett, do you have time to mumble?
[15:09] <jcsackett> sinzui: sure.
[15:22] <gary_poster> bigjools, is there anyone with a somewhat overlapping timezone to mine whom I can bother about a relatively simple soyuz question (https://answers.launchpad.net/launchpad/+question/166346 fwiw)?  I'm sorry I've been bothering you a lot lately.
[15:23] <bigjools> gary_poster: that doesn't look like a soyuz question
[15:23] <gary_poster> oh
[15:23] <bigjools> project release stuff isn;t it?
[15:23]  * gary_poster feels dumber...
[15:24] <gary_poster> ok
[15:24] <gary_poster> bac...do you have any idea about https://answers.launchpad.net/launchpad/+question/166346 ?
[15:24] <bigjools> gary_poster: oh and I think the answer is "no" anyway :(  You've got 2 Aussies, and me.
[15:25] <gary_poster> bigjools, heh, ok, thanks
[15:47] <bac> sorry, gary your message didn't get highlighted.  maybe my client doesn't like "bac..."
[15:50] <bac> gary_poster: i can't answer that question off the top of my head.  i'm not familiar with how that pattern is used.  i can look into it, though.
[16:14] <gary_poster> thanks bac.  maybe on your CHR rotation.  I'm not pursuing it
[16:28] <jml> mrevell: did you just put Welsh on the Launchpad blog?
[16:50] <dobey> hey guys
[16:51] <dobey> i got OOPS-2036MPJ10 from lp trying to generate a diff for my branch
[16:51] <dobey> i think it might be a bug in bzr or something
[16:56] <jelmer> hi dobey
[16:57] <jelmer> hmm, that OOPS hasn't synced yet
[17:01] <dobey> ok
[17:01] <dobey> jelmer: it probably says something akin to this, anyway: http://pastebin.ubuntu.com/654553/
[17:03] <LPCIBot> Project db-devel build #767: STILL FAILING in 5 hr 38 min: https://lpci.wedontsleep.org/job/db-devel/767/
[17:17] <jelmer> dobey: that's a known bug
[17:17] <jelmer> a 5 digit bug even
[17:17] <jelmer> bug 82555
[17:17] <_mup_> Bug #82555: Merging to an empty branch doesn't work <merge> <Bazaar:Confirmed> < https://launchpad.net/bugs/82555 >
[17:20] <dobey> wow
[17:22] <jelmer> dobey: while you're here... :)
[17:22] <jelmer> dobey: did you see my mps against lptools?
[17:23] <dobey> yeah, but i haven't had time to look at them. i guess poolie hasn't either
[17:24] <jelmer> there's no hurry
[17:29] <dobey> that bug is interestingly odd
[17:29] <dobey> since it is possible to merge to an empty branch, but weird things can happen
[17:30] <dobey> if i just merge to the empty branch and commit straight away, it sort of 'rights' itself
[17:33] <dobey> so, this is interesting...
[17:34] <dobey> jelmer: http://pastebin.ubuntu.com/654630/ <- notice the revnos that are listed as negative :)
[17:35] <dobey> and log -n0 shows them as 1..5
[17:37] <jelmer> dobey: yeah, there seem to be multiple issues here
[17:37] <jelmer> dobey: this sort of thing is tricky because of the way we do revno assignment, as you can see :)
[17:38] <dobey> sure
[17:42] <gmb> bac: I have a branch that needs reviewing, if you've got time: https://code.launchpad.net/~gmb/launchpad/remove-unused-potmsgsets/+merge/69841
[17:43] <bac> gmb: i do have time.
[17:43] <gmb> Thanks
[17:43] <gmb> Woah.
[17:43] <gmb> bac: Hang on. Bad diff.
[17:44] <gmb> bac: Should have submitted against db-devel. https://code.launchpad.net/~gmb/launchpad/remove-unused-potmsgsets/+merge/69842
[18:07] <bac> gmb: review done with a couple of suggestions
[18:08] <gmb> bac: Thanks
[19:00] <deryck> abentley: I'll be ready for our call in about 3 minutes.  Meet you in mumble then?
[19:00] <abentley> deryck: sounds good.
[19:13] <LPCIBot> Project devel build #930: STILL FAILING in 6 hr 1 min: https://lpci.wedontsleep.org/job/devel/930/
[20:07] <abentley> gary_poster: ping
[20:08] <gary_poster> abentley, hi
[20:08] <abentley> gary_poster: I'd like to talk about the jsoncache.  Do you have a couple of minutes?
[20:09] <gary_poster> abentley, sure, in 5 ok?
[20:09] <abentley> gary_poster: sure.
[20:09] <gary_poster> cool, abentley, I'll ping
[20:17] <gary_poster> abentey, thanks, ready
[20:17] <gary_poster> I'd prefer skype
[20:24] <gary_poster> abentley ping :-)
[20:24]  * gary_poster has EoD in 5
[20:24] <abentley> gary_poster: So that the Thunderdome, you expressed concern about the idea of reloading the whole JSONRequestCache as a means of updating pages.
[20:25] <gary_poster> yeah
[20:25] <gary_poster> at least as one to be applied as a blanket approach
[20:25] <abentley> gary_poster: Was the concern about the size of the download or the expense of calculating it server-side?
[20:25] <gary_poster> probably fine in some cases
[20:25] <gary_poster> abentley, expense
[20:26] <abentley> gary_poster: I think you suggested using ETAGs as a remedy to avoid retrieving already-known data?  But wouldn't that still be expensive server-side?
[20:29] <gary_poster> abentley, I don't remember suggesting ETAGs for this problem, but who knows. :-)  My preferred solutions might be long poll pushes, and/or MVC in client-side code (which in isolation would only address part of the "curentness" problem, but would be better than what we have).
[20:32] <abentley> gary_poster: I don't understand how MVC would address it.  The +sharing-details page wants to use it, and IS MVC.
[20:34] <abentley> gary_poster: Anyhow, I guess we can pick this up next week.
[20:36] <gary_poster> abentley, ack.  I'm glad that we have the mechanism, and my concerns/thoughts maybe can go under the category of "future work".
[20:37] <lifeless> gmb: still her e?
[20:37] <abentley> gary_poster: Anything I come up with will be opt-in, at least initially.  But If there opportunities to support other use cases better, I don't want to miss them.
[20:38] <gary_poster> abentley, ack.  You might want to talk to wgrant; he has some thoughts about the long poll that might be nicely integrated in the future
[20:38] <abentley> gary_poster: Yes, we've chatted about that.  He was my roommate at the Thunderdome.
[20:39] <gary_poster> abentley, heh, ok
[20:39] <gary_poster> cool
[20:39]  * gary_poster needs to run
[20:39] <gary_poster> have a good weekend abentley, all
[20:39] <abentley> gary_poster: you too.
[20:42] <abentley> lifeless: IIRC, we have a mechanism for a web client to control what page a form submission redirects us to.  Do you know what it is?
[20:43] <lifeless> I'm not aware of that except in the special case of the login / logout handshakes
[20:43] <abentley> lifeless: cool, thanks.
[20:44] <lifeless> I believe those cases are special-cased by the page being submitted to
[20:48] <abentley> lifeless: XHR automatically follows redirects, so submitting a form via AJAX redirects to a useless page, which is a pointless roundtrip.  I'd like to either avoid the redirect or redirect to a useful page.
[20:50] <lifeless> abentley: is this the new ++ thing, or existing form submissions ?
[20:51] <abentley> lifeless: existing form submissions, but the "useful page" would be the ++model++.
[20:51] <lifeless> can you tell that its an ajax xhr request on the server?
[20:52] <lifeless> abentley: also, if you're tuning this, wouldn't it be better not to redirect at all ?
[20:52] <lifeless> the redirect exists for web clients to end up with nice urls is all.
[20:52] <lifeless> (ah, as you say above 'avoid the redirect') +1
[20:52] <abentley> lifeless: Yes, it would be better to not redirect at all, but that would have to be decided server-side.
[20:53] <abentley> lifeless: Even better would be to return the data we actually want.
[20:54] <abentley> lifeless: I don't know whether there's a generic way to detect an XHR client, but I'm sure we could set a header or something.
[20:59] <lifeless> I think having a 'this is xhr' flag and then calculating and returning -only- the needed data would be ideal.
[21:00] <lifeless> it would avoid the redirect, and avoid the concerns around ++model++ doing too much work on big pages (e.g. BugTask:+index w/bug 1)
[21:00] <_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Confirmed for compscibuntu-bugs> <dylan.NET.Reflection:Invalid> <dylan.NET:Invalid> <EasyPeasy Overview:Invalid by ramvi> <elementary OS:In Progress by elementaryproject> <GenOS:In Progress by gen-os> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <LibreOffice:In Progress by bjoern-michaelsen> <Th
[21:02] <lifeless> http://activitystrea.ms/
[21:04] <abentley> lifeless: "returning -only- the needed data", where that's a subset of the ++model++ would be quite a trick.
[21:05] <lifeless> abentley: are we blocked on deploys until we fix all these views ?
[21:07] <abentley> lifeless: The only known-broken view is fixed in r13560.
[21:08] <lifeless> abentley: I'm a little worried that there are others we don't know about, and we'll find out the hard way.
[21:08] <lifeless> abentley: is it possible to make the code gracefully handle the absence of the method (and perhaps log / write a soft oops) when that happens ?
[21:08] <abentley> lifeless: In the words of Robert Collins, "Untested code is broken code".
[21:09] <abentley> lifeless: Writing a soft oops would be fine with me.
[21:10] <lifeless> I agree that untested code is broken code. We know now that we have (at least) one untested view.
[21:11] <lifeless> If we deploy as-is and find more untested views exist, we'll have to halt all deployments, rollback the deploy - moderately expensive shenanigans
[21:12] <abentley> lifeless: That's not the only way to handle a regression.  You can also just fix it.
[21:13] <abentley> lifeless: these fixes are trivial, e.g. a line of zcml or adding a parent class.
[21:14] <abentley> lifeless: this morning I searched the oopses for any more affected views and didn't find any.  I can search again.
[21:15] <lifeless> reverting the deployment takes minutes; the fixing pipeline takes (minimal) 6 hours
[21:16] <lifeless> doing a cowboy on the spot requires an incidentreport and analysis - its something we want to avoid as much as possible (perhaps too much, but thats a separate discussion)
[21:17] <lifeless> Lynne and I are popping out, so I have to go
[21:17] <lifeless> sorry
[21:19] <abentley> lifeless: I just re-synced qastaging oopses and didn't find any more broken views.