[00:03] <lifeless> thnaks
[00:05]  * lifeless whines about BranchCollection more
[00:07] <StevenK> lifeless: I'm chanelling thumper, but "Fix it, dear Elisa" ?
[00:08] <lifeless> StevenK: https://bugs.launchpad.net/launchpad/+bug/745310
[00:08] <_mup_> Bug #745310: Person:+branches timeout <regression> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/745310 >
[00:08] <StevenK> wgrant: http://pastebin.ubuntu.com/587111/ makes me sad. It's obvious what it should be, but why was it the other ...
[00:09] <wgrant> StevenK: blame
[00:09] <StevenK> blame says jelmer and a 10k rev no
[00:10] <StevenK> So it's been like that for a while ...
[00:10] <wgrant> Oh, this is in archivepublisher, not python-debian.
[00:10] <wgrant> Huh.
[00:10] <StevenK> Yes
[00:11] <wgrant> Well, the test docstring is reasonably clear..
[00:11] <StevenK> wgrant: I should commit that change and re-ec2?
[00:11] <lifeless> StevenK: its overly generic
[00:11] <lifeless> StevenK: access patterns for product scope vs person scope are not efficiently reusabke
[00:12] <wgrant> StevenK: It was changed as part of his port to python-debian. So just fix it.
[00:12] <lifeless> but our code structure is so heavily geared for code reuse, I suspect i need to entirely ditch the layers to fix it.
[00:14] <StevenK> wgrant: You think ec2 or it's safe to lp-land? (That was the only failure.)
[00:14]  * StevenK glares at Tasque
[00:15] <wgrant> StevenK: It's already been through ec2? lp-land.
[00:15] <StevenK> Which just SEGV'd. Orsum.
[00:16] <StevenK> wgrant: Yes, so doing so.
[00:17] <wgrant> cjwatson: Your branch failed ec2. The test deb didn't have the necessary Pre-Depends (I've fixed that), but python-apt doesn't support data.tar.xz.
[00:17] <StevenK> Or multiarch ...
[00:37] <wgrant> huwshimi: Have you had a chance to look at my JS suggestions for your branch?
[00:41] <huwshimi> wgrant: I had a quick look at it. I will have a look again in a minute. It is certainly cleaner than what I pushed. Generally this kind of node creation is very resource expensive (hence why people often do it with strings or arrays), but I'm more than happy to merge your changes.
[00:42] <wgrant> huwshimi: Yeah, I imagine it could be slightly more expensive.
[00:42] <huwshimi> wgrant: I'm not sure what it's like with YUI. It might be fine
[00:52] <cjwatson> wgrant: oh blasted thing
[00:52] <cjwatson> wgrant: Debian was going to work around that, IIRC
[00:52] <cjwatson> wgrant: where's the relevant code?
[00:53] <wgrant> cjwatson:                     apt_inst.debExtract(deb_file, tar_checker.callback, file)
[00:53] <wgrant> nascentuploadfile.py, around like 734
[00:53] <wgrant> *line
[00:53] <cjwatson> IIRC that was blocked on adding xz to python
[00:53] <cjwatson> or something joyous like that
[00:54] <cjwatson> though IIRC there was going to be a workaround with a subprocess
[00:54]  * cjwatson hunts down where he saw that
[00:54] <cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=556407
[00:54] <wgrant> Oh, right, I remember something like this.
[00:54] <wgrant> But it was a while ago.
[00:55] <cjwatson> debExtract not working is lame, though.
[00:55] <wgrant> It attempts to gunzip it instead.
[00:55] <wgrant> gzip is the default, I guess.
[00:55] <cjwatson> that really shouldn't be that desperately hard to fix.
[00:55]  * cjwatson goes looking
[00:56] <cjwatson> (though don't expect a solution tonight, it's late)
[00:56] <StevenK> "Early"
[00:56] <wgrant> Sure, thanks.
[00:56] <StevenK> :-)
[00:57] <cjwatson> oh, should be fairly trivial
[00:57] <cjwatson>       else if(strcmp(".lzma", &Chunk[strlen(Chunk)-5]) == 0)
[00:57] <cjwatson>               Comp = "lzma";
[00:57] <cjwatson> that kind of thing
[00:57] <wgrant> Right, but what handles Comp?
[00:58]  * StevenK waits for devel to be repacked
[00:59] <cjwatson> ExtractTar in apt-inst, and it's just a program name
[00:59] <wgrant> Oh, that's easy, then.
[00:59] <cjwatson> actually I think it might need a slight tweak in apt
[01:00] <cjwatson> but still, nothing especially hard
[01:00] <cjwatson> I might make mvo do it
[01:00] <wgrant> Handy having Platform at your disposal :)
[01:00] <cjwatson> he could probably do it twice as quick and once on Sundays
[01:00] <wgrant> Yup.
[01:05] <StevenK> The changes to apt and python-apt will need to be backported to Lucid though, right?
[01:05] <wgrant> Ja.
[01:07] <StevenK>         Updating python-debian to revision 186
[01:07] <StevenK> Text conflict in lib/debian/debian_support.py8ing stream:Estimate 11/41
[01:07] <StevenK> bzr fail.
[01:07] <cjwatson> lucid-cat plus ppa:launchpad, right?
[01:07] <StevenK> But I suspect it's my fault.
[01:08] <StevenK> cjwatson: Yeah, it will need to hit both
[01:35] <lifeless> thumper: btw, select expressions can be used with with now in storm
[01:36] <thumper> oh cool
[01:36] <lifeless> With('name', Select(..)) [or get it from a result set or whatever)
[01:55] <StevenK> Damn it, db-devel, stop failing
[01:56] <StevenK> shell_6 [test no test results failed] [42 seconds]
[01:56] <StevenK> Wheeee
[01:57] <StevenK> Ahh, xfvb, my old nemesis
[02:06] <lifeless> Error 324 (net::ERR_EMPTY_RESPONSE): Unknown error on lpbuildbot :(
[02:07] <StevenK> lifeless: For which page?
[02:07] <lifeless> the build that died
[02:07] <StevenK> Hm. It worked for me
[02:08] <lifeless> >< 117 /   41  Person:+branches
[02:18] <wgrant> lifeless: By the number of soft timeouts I presume it's real.
[02:18] <wgrant> And a regression.
[02:19] <lifeless> wgrant: yes, its the bug I'm bitching about
[02:19] <wgrant> Ahh
[02:19] <lifeless> we use the same code to query for merge proposals in one scope
[02:19] <lifeless> and unscoped for a person
[02:19] <lifeless>  /totally/ different criteria
[02:32] <LPCIBot> Project devel build #589: STILL FAILING in 5 hr 0 min: https://lpci.wedontsleep.org/job/devel/589/
[03:16] <lifeless> can has review https://code.launchpad.net/~lifeless/launchpad/bug-745310/+merge/55459
[04:15] <StevenK> lifeless: It looks good, but is it possible to check in a test that it isn't going to generate a bong query for the general case?
[04:17] <lifeless> StevenK: if we could define the general case, perhaps
[04:17] <StevenK> Person:+branches sounds like a good one
[04:17] <lifeless> its a special case
[04:18] <lifeless> the schema is not optimised for querying
[04:18] <StevenK> lifeless: I'm just concerned that you're fixing a fix, and there is no tests to confirm it isn't noddy.
[04:18] <lifeless> we're going to have to touch this again and again and against
[04:18] <lifeless> StevenK: I'm not sure that it isn't noddy
[04:19] <StevenK> lifeless: Okay, so your general plan is for you or someone to iterate over it?
[04:19] <lifeless> StevenK: without about 100GB of data, I can't prove it one way or another
[04:19] <lifeless> StevenK: thats what we've been doing for all timeout fixes so far; checking that query X is issued is easy, being sure that query X is what we need is hard
[04:19] <StevenK> lifeless: r=me
[04:20] <lifeless> in fact, I can go futher
[04:20] <lifeless> the query here *will* be noddy, just less noddy than the one optimised for product/package scopes
[04:20] <lifeless> StevenK: thanks
[04:20] <StevenK> Oh, sigh
[04:20] <StevenK> I voted on my own MP, not yours
[04:21] <lifeless> StevenK: -lol-
[04:21] <lifeless> StevenK: its still noddy because it unions two querie together that probably are faster done directly.
[04:21] <lifeless> StevenK: which speaks to the heart of why I don't like (having taken my time to think about this) the 'Collection' approach.
[04:22] <lifeless> well, this part of the implementation
[04:23] <lifeless> I'm  not ready to critique the entire thing yet, just speaking out of frustration
[04:24] <StevenK> lifeless: Swap you: https://code.launchpad.net/~stevenk/launchpad/dsd-invalid-versions/+merge/55461
[04:24] <StevenK> It's a little larger than yours, so not quite a fair swap :-)
[04:37] <StevenK> lifeless: Thank you for the review.
[04:40] <jtv> StevenK: which LP configs does cron.publish-ftpmaster run under?  dogfood, staging, qastaging, production, ftpmaster, ftpmaster-publish, …?  I need to add to those configs.
[04:40] <jtv> Possibly only to some.
[04:40] <StevenK> ftpmaster and ppa
[04:40] <StevenK> I think
[04:41] <StevenK> jtv: lp-production-crontabs will help
[04:41] <jtv> Ah, of course.  Thanks.
[04:42] <StevenK> jtv: But certainly dogfood, so that will need fixing too
[04:43] <jtv> StevenK: BTW you mean lp-crontabs, right?
[04:44] <jtv> Oh, it _contains_ a dir lp-production-crontabs.
[04:44] <jtv> Ah no, I am fatally confused.
[04:44] <wgrant> jtv: What do you need to add to those configs?
[04:44] <jtv> The stuff I added in https://code.launchpad.net/~jtv/launchpad/db-bug-55798/+merge/55174
[04:44] <wgrant> jtv: Only ftpmaster runs cron.publish-ftpmaster. Although dogfood *can*, we mostly maintain its config locally.
[04:45] <wgrant> Er, ftpmaster-publish, not ftpmaster.
[04:46] <jtv> Then we may want to set up, configure, and maintain a pair of run-parts directories for publish-ftpmaster runs there.
[04:46] <wgrant> jtv: Those things really don't belong in the tree :/
[04:47] <jtv> That's why it's configurable.
[04:47] <wgrant> Why is one fo them publish-distro.d, and the other finalize.d?
[04:47] <jtv> Better names welcome.
[04:48] <jtv> It's just that I couldn't bring myself to call one pre-publication.d when it runs _after_ publish-distro.
[04:48] <jtv> In fact I rather got the impression (also based on what you said) that that one might properly belong in the publish-distro script itself.
[04:50] <wgrant> Also, PublishFTPMaster is terrible name, but I can't think of anything better since publish-distro is inappropriately taken.
[04:50] <StevenK> PublishDistribution
[04:50] <wgrant> No, too confusing until we fix publish-distro
[04:51] <StevenK> ThePublisherOfDoomDeathAndDestruction is apt
[04:51] <wgrant> Yes.
[04:51] <cody-somerville> hahahahah, apt!
[04:51] <jtv> This does explain why I had such trouble coming up with good names and docstrings, I think.
[04:51] <jtv> StevenK: do I sense a bit of "See I am become Death, the destroyer of Windows" there?
[04:52] <wgrant> jtv: You've a function in PublishFTPMaster to append -distscopy, but you don't seem to use it everywhere.
[04:52] <StevenK> No, I was channeling something
[04:52] <jtv> wgrant: oh, thanks—I'll check
[04:53] <jtv> wgrant: I do see it used
[04:53] <wgrant> jtv: But not everywhere.
[04:53] <jtv> True.  Am fixing.
[04:54] <jtv> Found 1 place that neglected to use it.
[04:54] <wgrant> jtv: Also, ARCHIVE_SUFFIXES is surely duplicating something esle.
[04:55] <jtv> Again, true.
[04:55] <jtv> pocketsuffix, I think.
[04:56] <jtv> Ah, no, that's different of course.
[04:56] <jtv> But highly similar.
[05:20] <StevenK> Wheee.
[05:21] <StevenK> Now buildbot is failing like Jenkins is.
[05:21] <StevenK> Difference: True != False: memcached is live but should not be.
[05:21] <wgrant> Ah, lucid_lp this time.
[05:21] <wgrant> It's because the slave was killed badly when the master was restarted.
[05:21] <wgrant> spm: Hi, lucid_lp needs a memcached massacre.
[05:22] <wgrant> spm: Might as well bounce all the slave bits there.
[05:22] <wgrant> Since the build has failed.
[05:35] <StevenK> lifeless: I note you're up for QA
[05:36] <wgrant> StevenK: Could you review lamont's buildd changelog entry?
[05:36] <wgrant> https://code.launchpad.net/~lamont/launchpad/lp-buildd-76/+merge/55378
[05:36] <StevenK> Ah, thanks
[05:36] <StevenK> Lookink
[05:37] <StevenK> wgrant: All done.
[05:37] <wgrant> Thanks.
[05:38] <wgrant> lifeless/StevenK: Could one of you mentor https://code.launchpad.net/~huwshimi/launchpad/ajax-time/+merge/55257?
[05:43] <poolie> wgrant, re your recent post, did you ever see http://haml-lang.com/
[05:45] <wgrant> Huh, interesting.
[05:51] <huwshimi> Noooooo
[05:51] <poolie> huwshimi, ?
[05:51] <poolie> i don't mean the ruby bit, just the syntax
[05:51] <wgrant> It's an interesting idea.
[05:51] <wgrant> I'm not sure if it's good or not.
[05:51] <spm> wgrant: okidoki
[05:51] <huwshimi> poolie: Oh, I've just had fun times with haml in the past
[05:51] <poolie> fun or 'fun'? :)
[05:51] <poolie> i'm not sure either
[05:52] <poolie> getting away from the specific syntax of xml may be good
[05:52] <StevenK> From The Register: MySQL.com hacked via... SQL injection vuln
[05:52] <spiv> From the URL, I was hoping it would be a programming langauge that was a homage to Mark Hamill.
[05:52] <wgrant> StevenK: Stones, glass houses.
[05:52] <poolie> :)
[05:52] <StevenK> :-(
[05:52] <spiv> So I was already disappointed without trying it!
[05:52] <poolie> :)
[05:53] <spiv> (Not sure how you'd make such a language, but if people can manage to put nearly 3000 toothpicks in their beard and post the video to the internet then surely anything is possible)
[05:53] <huwshimi> poolie: Yes, non-xml templating languages are good
[05:54] <StevenK> Actually, this sounds useful: http://www.theregister.co.uk/2011/03/30/dynatrace_ajax_firefox4_ie/
[05:54] <poolie> it reminds me a bit of latte, which i used years ago
[05:54] <jtv> wgrant: had some network trouble earlier… I unified the ARCHIVE_SUFFIXES across two old modules that did it ad hoc (and removed it from mine which turned out not to need it any more).  Did you say anything after that?
[05:54] <wgrant> jtv: No, that was all I saw with a quick glance.
[05:55] <huwshimi> poolie: I think haml goes to far. It is actually really nice for writing HTML in, but I think it abstracts too far from HTML
[05:58] <jtv> Also, it says "markup haiku."  Don't we normally like our formal languages to avoid the kind of linguistic ambiguity that's the whole point of haikus?
[05:58] <wgrant> It's Ruby, what do you expect? :)
[05:59] <poolie> for the real 60s retro flavour suggested by the theming it ought to be all caps :)
[06:01] <spiv> jtv: it's poetry, so beauty is truth, truth beauty, etc.
[06:02] <jtv> I'll leave that to the test suite, thank you very much :)
[06:02] <spm> wgrant: the entire buildbot whatsit is stabbed. have deliberately not restarted the existing builds, so you'll need to force when ready.
[06:02] <jtv> I'm hungry for Japanese food now.
[06:04] <wgrant> spm: Both slaves are clean?
[06:05] <spm> in that I shut down everything that was running. yes. afaik, we don't do any cleaning beyond that?
[06:05] <wgrant> Well, there's non memcacheds or anything left on either slave?
[06:05] <spm> if we have to, that's a pretty awesome bug given the purpose.
[06:05] <wgrant> s/non/no/
[06:09] <lifeless> spm: you used to have a script for pqm
[06:09] <lifeless> spm: that would kill /every/ process running in a chroot
[06:09] <lifeless> spm: that would be the thing to run
[06:10] <spm> sure. either way, the processes are wiped and restarted.
[06:13] <wgrant> Thanks.
[06:13] <wgrant> Forcing.
[06:13] <wgrant> Hopefully for the last time.
[06:17] <wgrant> StevenK: Hi.
[06:17] <StevenK> wgrant: Hm?
[06:18] <wgrant> i-528A0905 needs killing for the same reason.
[06:18] <wgrant> It was cursed by db-devel build 503.
[06:19] <LPCIBot> Project devel build #590: ABORTED in 3 hr 46 min: https://lpci.wedontsleep.org/job/devel/590/
[06:19] <wgrant> Thanks.
[06:19] <StevenK> And slave killed.
[06:19] <StevenK> Shall I request a build of devel, or something should come along soon?
[06:20] <wgrant> Nothing will be around for at least 4 hours.
[06:20] <wgrant> Please force.
[06:20] <StevenK> Just devel or both it and db-devel?
[06:20] <lifeless> wgrant: can you look at the soyuz ppa +subscribers on qastaging
[06:20] <lifeless> qa for 741092 - I don't admin any private ppas
[06:21] <wgrant> StevenK: I think db-devel is fine, so no need for a build there.
[06:21] <StevenK> lifeless: We have these people called losas, who can fix that for you
[06:21] <lifeless> StevenK: we we're also trying not to interrupt when we don't need to
[06:21] <wgrant> StevenK: Also these people called wgrant, though.
[06:21] <wgrant> 38 queries/external actions issued in 0.43 seconds •
[06:21] <StevenK> wgrant: Okay, devel is waiting for Jenkins to start a build slave.
[06:21] <lifeless> StevenK: because they have a backlog longer than ours per-head
[06:21] <wgrant> 38 queries/external actions issued in 0.30 seconds •
[06:21] <wgrant> StevenK: Thanks.
[06:21] <lifeless> wgrant: nifty
[06:21] <wgrant> lifeless: So, it is too fast.
[06:21] <spm> StevenK: that's a pack of lies. we are not people, and resent being so labelled.
[06:22] <lifeless> ohI'msorry
[06:22] <StevenK> spm: How would you prefer to be addressed?
[06:22] <wgrant> Demigod?
[06:22] <StevenK> Haha
[06:23]  * spm tears up another of wgrant's cake IOU's.
[06:27] <wgrant> StevenK: Could you review https://code.launchpad.net/~wgrant/launchpad/packageset-owner-preservation/+merge/55466?
[06:29] <StevenK> wgrant: r=me
[06:30] <wgrant> StevenK: Thanks.
[06:31]  * StevenK glares at patch-2208-59-0.sql, mawson and lifeless
[06:32] <lifeless> StevenK: why?
[06:32] <StevenK> Because it's taken seven minutes to apply so far
[06:32] <wgrant> It might be a while.
[06:32] <lifeless> is it doing stuff
[06:32] <wgrant> As well as breaking the build several times :P
[06:32] <lifeless> or is it deadlocked because you didn't shut everything down ?
[06:33] <StevenK> Everything ought to be stopped
[06:38] <lifeless> it has to rewrite 250MB
[06:38] <lifeless> so it should be pretty snappy
[06:38] <lifeless> check top, iotop, etc
[06:38] <StevenK> mawson can not be described as snappy
[06:39] <StevenK> It's still running UPDATE
[06:40] <lifeless> which one
[06:40] <StevenK> I have no idea, I'm going by ps output
[06:43] <lifeless> select current_query from pg_stat_activity;
[06:43] <lifeless> should give you exactly 2 rows
[06:43] <lifeless> StevenK: speaking of qa -Revision 12689
[06:45] <StevenK> lifeless: There is only one UPDATE in -59
[06:45] <lifeless> StevenK: this will tell you if anything else is hanging around that could be blocking it
[06:46] <StevenK> lifeless: https://pastebin.canonical.com/45423/
[06:47] <lifeless> StevenK: cool
[06:48] <StevenK> So I just have to wait?
[06:48] <wgrant> And wait.
[06:48] <StevenK> Haha
[06:53] <stub> So the BugTask.heat update is too slow for a standard rollout?
[06:54] <StevenK> stub: This is mawson, so the data means nothing
[06:54] <stub> k
[06:54]  * stub waits for the staging update
[06:54] <lifeless> stub: I missed a bit, then we've had continual buildbot fail
[06:54] <lifeless> and I mean continual
[06:54] <stub> \o/
[06:55] <wgrant> I think four or five db-devel builds have died in various ways so far today.
[06:55] <lifeless> stub: should we try manually, expedite rollback if needed?
[06:55] <lifeless> stub: as in , ask for staging to be quiesced, and you pump it through slon?
[06:56] <stub> If we do it manually, we need two losa interrupts (one to apply, one to rollback). If we do it with the standard update, we may need one (to rollback, if necessary)
[06:57] <lifeless> spm: ^ up for it?
[06:58] <stub> Hmm.... what I *can* do is time how long it takes to do the UPDATE on a slave. I just need to roll it back before I commit and break replication.
[06:58] <spm> yes, but no. currently mid a security update on an LP service and hoping to get the u1 migrtaion actually started in the next hour before I EOD
[06:59] <lifeless> stub: can't do that with out the new column ?
[06:59] <StevenK> 2011-03-30 05:25:26 INFO    Applying /srv/launchpad.net/codelines/trunk/database/schema/patch-2208-59-0.sql
[06:59] <StevenK> 2011-03-30 05:58:54 DEBUG   Committing changes
[06:59] <stub> lifeless: begin; add column; update; rollback
[06:59] <StevenK> 2011-03-30 05:59:00 INFO    2208-59-0 applied just now in 0.0 seconds
[06:59] <StevenK> FAIL
[07:00] <lifeless> so, 25 minutes
[07:00] <stub> on mawson - should be ok.
[07:00] <StevenK> The fail is the 'in 0.0 seconds'
[07:01] <huwshimi> Do we still have sparklines in Launchpad?
[07:01] <lifeless> I doubt it
[07:01] <stub> Dunno why you would get 0.0 on mawson - that code was tricky. Might be an edge case with a single db patch on unreplicated env?
[07:02] <stub> We pulled sparklines
[07:02] <lifeless> huwshimi: ...why
[07:02] <StevenK> stub: Could be.
[07:03] <huwshimi> lifeless: I just found a bug about them and was wondering if I should kill it
[07:03] <huwshimi> lifeless: bug #383924
[07:03] <_mup_> Bug #383924: Sparklines displayed over row below in Opera <lp-code> <ui> <Launchpad itself:Triaged by thumper> < https://launchpad.net/bugs/383924 >
[07:03] <lifeless> kill it
[07:04] <wgrant> They were pulled temporarily in July 2009 due to a bug.
[07:04] <wgrant> They were to be returned within two months.
[07:05] <spiv> wgrant: I guess no-one missed them then ;)
[07:05] <huwshimi> lifeless: https://bugs.launchpad.net/launchpad/+bugs?field.searchtext=sparkline&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_p
[07:05] <huwshimi> atch=&field.has_no_package=
[07:05] <huwshimi> lifeless: Kill them all?
[07:06] <lifeless> bug 284400 seems like a reasonable defect
[07:06] <_mup_> Bug #284400: "Package bugs" page has no indication of how numbers have changed <feature> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/284400 >
[07:06] <lifeless> the others seem to be implementation bugs about the sparklines we had
[07:07] <lifeless> we might want sparklines for 284400, but I doubt it, context doesn't really fir
[07:07] <lifeless> *fit*
[07:08] <lifeless> huwshimi: did you end up getting the url?
[07:09] <huwshimi> lifeless: Nope. I haven't landed the first lot yet
[07:09] <lifeless> please file a bug or something if you need server side changes whipped up for you
[07:10] <huwshimi> lifeless: It feels like getting the url from header is a big hack. I might ask around first
[07:11] <wgrant> It is a big hack, but I don't think you have much choice.
[07:11] <lifeless> http://stackoverflow.com/questions/4230876/re-associate-ajax-call-with-original-url-using-jquery
[07:12] <lifeless> huwshimi: we might already set Location
[07:13] <lifeless> though that can be legitimately different
[07:13] <lifeless> http://forum.jquery.com/topic/jquery-ajax-response-url is relevant
[07:13] <lifeless> 'If it was really important, you could do some voodoo with sending
[07:13] <lifeless> along the current URL as a custom response header'
[07:13] <lifeless> :P
[07:15] <huwshimi> lifeless: OK you win :)
[07:19] <huwshimi> lifeless: What exactly do I need to ask to be done? Is it unhelpful if I just ask for a new header?
[07:19] <lifeless> that would be fine
[07:20] <lifeless> you need 'a sensible url to show in the ajax timeline put in the response sent to every ajax request'
[07:20] <lifeless> and we can probably sensibly say 'api requests on non api domains are ajax requests'
[07:21] <lifeless> the submission url with parameters is probably sensible on all ajax requests
[07:23] <wgrant> D:
[07:24] <wgrant> stub: I see that you found zope.tal about as extensible as I did.
[07:25] <stub> wgrant: I don't remember. I had that part of my brain removed.
[07:25] <stub> Nah nah nah can't hear you...
[07:26] <wgrant> I am glad there is precedent :)
[07:31] <huwshimi> lifeless: Would this be low priority?
[07:31] <wgrant> It's at least High, because it's hindering performance improvements.
[07:31] <wgrant> And it's easy.
[07:32] <huwshimi> wgrant: OK :)
[07:32] <lifeless> huwshimi: I would say high
[07:32] <wgrant> Huh, that monkeypatch worked, and stuff doesn't even OOPS.
[07:32] <wgrant> Incredible.
[07:32] <lifeless> and then suggest you bat your eyelids at wgrant :P
[07:32] <wgrant> lifeless: That was the plan.
[07:32]  * wgrant declares structure obsolete.
[07:33]  * huwshimi bats eyelids at wgrant
[07:33]  * huwshimi is not sure if he's doing it right
[07:37] <huwshimi> OK people, how do I land a branch that has no bug it is addressing? "ec2: ERROR: Branch doesn't have linked bugs and doesn't have no-qa option set."
[07:37] <wgrant> huwshimi: File a bug, or --no-qa
[07:37] <StevenK> Add --no-qa
[07:37] <StevenK> Or file a bug, as wgrant says
[07:37] <wgrant> Depending on how qa-worthy it is.
[07:38] <lifeless> if you want the ability to say 'oh fuck this broke things'
[07:38] <lifeless> file a placeholder bug
[07:38] <huwshimi> ok maybe I'll file a bug
[07:38] <lifeless> if you reckon it doesn't need checking on qastaging, use --no-qa
[07:39] <huwshimi> I don't really want to break things
[07:39] <lifeless> huwshimi: breaking things is a little orthogonal :P
[07:40] <lifeless> wow
[07:40] <lifeless> some folk really do get confused
[07:41] <huwshimi> lifeless: Well this way I can make sure it doesn't go live if it does break things right? Or did I misunderstand?
[07:41] <lifeless> huwshimi: it gives you another set in the process
[07:41] <lifeless> huwshimi: the question is, will you notice something on qastaging that you wouldn't notice on your machine
[07:42] <huwshimi> lifeless: I guess probably not.
[07:43] <huwshimi> lifeless: But if that was the case then what's the point in qastaging?
[07:43] <lifeless> huwshimi: its entirely up to you; we try hard to be able to rollthings back easily
[07:43] <lifeless> huwshimi: many things will only show up on qastaging
[07:44] <lifeless> huwshimi: for instance, db permissions; scaling; icing changes
[07:53] <wgrant> buildbot seems to be happy this time.
[07:53] <wgrant> I guess there'll be a UPS failure in the DC soon.
[07:56] <StevenK> Who's a little ray of sunshine today.
[07:56] <wgrant> Shh
[08:05] <jelmer> Has the timeout been tightened again? I can no longer view my code page, it now consistently times out.
[08:05] <StevenK> jelmer: Known regression.
[08:05] <wgrant> Fix waiting for buildbot.
[08:05] <jelmer> StevenK: Ah - thanks.
[08:31] <stub> jtv: https://code.launchpad.net/~stub/launchpad/drop-branchrevision-id/+merge/55480 is where I got to. Unfortunately, after that patch I end up with a primary key on branchrevision that cannot be dropped because 'constraint does not exist', so I think there are some other links lurking in the schema we haven't tracked down yet.
[08:32] <wgrant> lifeless: Are you checking other callsites before you add preloading?
[08:32] <lifeless> wgrant: briefly yes
[08:32] <wgrant> p-r-f is broken because ProductSet.all_active is trying to access emailaddresses.
[08:32] <lifeless> wgrant: oh gawd
[08:32] <wgrant> Yes.
[08:34] <lifeless> wgrant: I didn't see that call site at all
[08:34] <lifeless> wgrant: is it not under lib/ ?
[08:34] <wgrant> lifeless: I bet it iterates over ProductSet.
[08:34] <lifeless> wgrant: OTOH the +all page loads snappily now
[08:35] <wgrant> Heh
[08:35] <wgrant> Indeed.
[08:35] <lifeless> uhm
[08:35] <wgrant>         products = getUtility(IProductSet)
[08:35] <wgrant>         for product in products:
[08:35] <lifeless> i'm inclined to broaden its access
[08:35] <lifeless> it should
[08:35] <lifeless> bah
[08:36] <lifeless> it should be moved to an API client eventually anyway
[08:36] <wgrant> That will make it load lots, though.
[08:36] <wgrant> Same issue as populate-arcdhive.
[08:36] <lifeless> thats true
[08:36] <lifeless> move it off of __iter__ ?
[08:37] <wgrant> I think all this stuff needs looptunerising or deleting.
[08:37] <lifeless> I'm past EOD and TL meeting is at awful-am
[08:37] <stub> lifeless: How should we handle logging with parallel garbo? I could buffer the output from each task, and emit it when the task is complete. Or I could log to individual log files rather than stdout. Or what?
[08:37] <lifeless> I can JFDI something raw
[08:37] <lifeless> or perhaps you could do it ?
[08:37] <wgrant> lifeless: It can be dead for a couple of days.
[08:37] <wgrant> I am mostly EODed and attempting to stick to it this week.
[08:38] <wgrant> (utterly failing, but attempting)
[08:38] <lifeless> wgrant: ah true; file a bug for me and I'll pay the piper tomorrow
[08:38] <lifeless> wgrant: welcome to canonical
[08:38] <wgrant> Thanks.
[08:38] <stub> You're at work until you shut down your IRC client :)
[08:38] <lifeless> stub: logging is threadsafe; I think using a sublogger with the loop class name will be sufficient
[08:38] <stub> lifeless: I'm talking about making the output readable
[08:39] <lifeless> e.g. logger = somelogger.get(self.__class__.__name__)
[08:39] <stub> Maybe it will be readable with the output interleaved...
[08:39] <lifeless> stub: as long as there is a [prefix] blah goes here
[08:39] <lifeless> it should be tolerable
[08:39] <wgrant> lifeless: Bug #745512
[08:39] <_mup_> Bug #745512: product-release-finder broken <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/745512 >
[08:39] <lifeless> only matters when we actually read it after all
[08:39] <lifeless> wgrant: thanks
[08:39] <wgrant> And now I am gone for at least a while.
[08:39] <stub> Hmm.... prefix could be a quick fix and good enough... yeah.
[08:40] <lifeless> stub: thats what I was suggesting :) - use an outputter that outputs the logger name, and tweak the logger name for the loop when we construct/access the logger
[08:40] <lifeless> stub: I failed to separate what and how though :P
[08:41] <stub> I followed and was rephrasing in my agreement
[08:41] <lifeless> \o/
[08:41] <lifeless> stub: I totally broke code.l.n/~user/ yesterday
[08:42] <lifeless> stub: my clever optimisation for projects with lots of private branches + open merge proposals caused 2xseq scans on Branch for per-user counts
[08:43] <stub> eggs... omlettes...
[08:43] <stub> Mmm.... omlettes....
[08:43]  * stub drools
[08:45] <lifeless> mmmm
[08:54] <adeuring> good morning
[08:54] <jtv> hi adeuring
[08:54] <adeuring> hi jtv!
[08:59] <lifeless> jml: ping
[09:00] <jtv> StevenK: your DSD diff invalidation card is still under Review on the board, but the the branch is merged.
[09:01] <jtv> Thank you :)
[09:01] <jtv> In fact the bug is marked Fix Released.
[09:05] <lifeless> jml: I'm wondering if we can set the hard timeout for pages feature squads are creating/changing to 5 seconds
[09:07] <jtv> wgrant: any other notes about my publish-ftpmaster branch by the way?
[09:07] <wgrant> jtv: I didn't end up having more than a glance through it. I will look at it in depth tomorrow.
[09:08] <jtv> That'd be great, thanks.  I'm emotionally eager to move on to the next similar job, but I'd like to have confidence that my current branch is stable.
[09:08] <wgrant> Indeed. It looks mostly sensible.
[09:09] <rvba> I'm having a strange failure in the test suite: http://paste.ubuntu.com/587260/
[09:09] <rvba> doest it look like a known spurious error?
[09:09] <jtv> wgrant: Also, it seems like rather a lot of change to Q/A and deploy in one cycle.  But waiting won't help with that.
[09:10] <jtv> rvba: hang on, looking
[09:10] <wgrant> rvba: That's not a spurious failure.
[09:11] <wgrant> jtv: Yeah, but I'm not sure we can do much to avoid that :/
[09:11] <jtv> rvba: Did you use unittest.TestCase instead of lp.testing.TestCase maybe?
[09:11] <jtv> wgrant: exactly.
[09:11] <rvba> wgrant: DistroSeriesMissingPackagesFunctionalTestCase is indeed a new class so this looks like a genuine error but "./bin/test -cvv -t translationimportqueue.txt" passes
[09:12] <wgrant> rvba: Could you pastebin/push your changes?
[09:12] <jtv> Did you override setUp and neglect to call the super?
[09:12] <wgrant> TestCase is normally good at warning about that, IIRC.
[09:12] <rvba> jtv: no, just fixed that
[09:12] <wgrant> But that would be the obvious thing.
[09:12] <rvba> wgrant: hang on
[09:12] <wgrant> Maybe only TestCaseWithFactory warns, though.
[09:13] <lifeless> wgrant: the warning is in testtools.TestCase
[09:13] <jtv> True, setUp warns about it.  rvba, I take it you didn't define an __init__ in the test case?
[09:13] <stub> jtv: https://code.launchpad.net/~stub/launchpad/drop-branchrevision-id/+merge/55480 is where I got to. Unfortunately, after that patch I end up with a primary key on branchrevision that cannot be dropped because 'constraint does not exist', so I think there are some other links lurking in the schema we haven't tracked down yet.
[09:13] <rvba> jtv: no
[09:14] <jtv> stub: I wonder if the transplant I worked out is perhaps needlessly complex.
[09:14] <jtv> Instead of using an existing unique index, I think it'd be simpler with an existing unique constraint.  Do we have one?
[09:15] <stub> Yes - two. That was my next issue - I think we end up with a constraint that things it is both a UNIQUE constraint and a PRIMARY KEY constraint :)
[09:15] <jtv> rvba: I haven't used self.oopses in tests yet, personally; did you track through the code to see that it's really supposed to be created?
[09:15] <stub> So if we can swap the revision__revision__branch__key UNIQUE constraint easier, that would be better.
[09:15] <rvba> jtv not sure what you mean ...
[09:16] <jtv> stub: or an index that thinks it belongs to both a PRIMARY KEY constraint and a UNIQUE constraint.
[09:16] <stub> yer. looks messier than I initially suspected anyway.
[09:17] <rvba> wgrant: modifs to tests http://paste.ubuntu.com/587267/
[09:17] <rvba> wgrant: the whole branch https://code.launchpad.net/~rvb/launchpad/dds-add-missingpackages-page
[09:17] <jtv> stub: Yes.  I'd have to get back into the details but IIRC the transplant I documented ran into a dependency relationship that more or less needs to be inverted.  That's probably not the case if we use the unique constraint instead of the unique index.
[09:18] <stub> That sounds promising. I haven't scoured the schema documentation yet, so I just followed your notes for the initial cut.
[09:18] <jtv> stub: I'm on feature rotation now… would it make sense for me to dive back into this after?
[09:19] <stub> jtv: Whoever gets to it first. I've got other things for today. But we are looking at some denormalization and adding a timestamp to BranchRevision, so pulling id and unnecessary indexes would be good to do at the same time so we don't have a disk space problem.
[09:20] <wgrant> +inf
[09:20] <jtv> overflow trap
[09:20] <wgrant> Damn.
[09:23] <jtv> stub: I am somewhat puzzled by the notion of piggybacking the addition of a timestamp column onto the urgent removal of an int column to save disk space.  :)
[09:24] <stub> Its not *that* urgent
[09:29] <jml> lifeless: sure, sounds good, but can we excuse translations & bug subscription for now?
[09:33] <lifeless> jml: yeahm wouldn't be fair to just dump it on existing work.
[09:33] <jml> lifeless: cool.
[09:33] <lifeless> jml: i'll mail the list
[09:33] <jml> lifeless: ta.
[09:37] <jml> wow, we haven't had a successful test run since I stopped last night
[09:38] <lifeless> no, its been bad today
[09:38] <wgrant> We're nearly there.
[09:45] <rvba> wgrant: did you by any chance pick up some obvious mistake in my code?
[09:45] <wgrant> rvba: Nothing obvious, sorry :/
[09:45] <wgrant> Yay, 800/1800 structure keywords removed.
[09:45] <rvba> wgrant: that's allright, I'll keep on investigating :-)
[09:48] <jtv> rvba: did you say it failed intermittently?
[09:49] <rvba> jtv: it's more bizarre than this:
[09:49] <lifeless> night all
[09:49] <jtv> night lifeless!
[09:49] <rvba> it failed when I launched the whole testsuite on ec2
[09:50] <rvba> it failed when I launched testr run --failing
[09:50] <rvba> but ./bin/test -cvv -t translationimportqueue.txt passes
[09:50] <jtv> Oh, I hate those.
[09:50] <jtv> Heisenbug.
[09:51] <rvba> sort of yes
[09:53] <jtv> And this is a custom oops reporting setup, which we've sort of abandoned now AFAIK.  There may easily be something wrong with it.
[09:53] <jtv> Layer setup or isolation issue maybe?
[09:54] <jtv> What layer is the test in?
[09:54] <rvba> LaunchpadFunctionalLayer
[09:54] <jtv> Hmm can't really be anything missing there then can there?
[09:54] <jtv> Drat.
[09:55] <rvba> jtv: here is the diff for this test file http://paste.ubuntu.com/587267/
[10:02] <jtv1> rvba: have to go otp now
[10:29] <henninge> What's the easiest way to render some TAL into a string?
[10:31] <jtv> henninge: don't you __call__ the view?
[10:32] <jtv> rvba: I'm back… my connection went awol after I asked: is there no cleanup for the "set_derived_series_ui_feature_flag"?
[10:33] <jtv> allenap: where do you retrieve the selection of packagesets that a derived distroseries is based on?
[10:33] <rvba> I don't think so
[10:34] <rvba> perhaps I know what's happening ... I'll relaunch the test suite ...
[10:36] <bigjools> jtv, henninge: call .render()
[10:36] <wgrant> bigjools: Is lp-buildd-76's commit message meant to be empty except for the tags?
[10:37] <wgrant> Ah, just on the MP.... hm.
[10:37] <wgrant> Landed with a commit message.
[10:37] <bigjools> wgrant: bug in lp-land :/
[10:41] <henninge> bigjools, jtv: I was wondering if I could do without a view.
[10:42] <henninge> but maybe I can create a simple one for this purpose.
[10:42] <bigjools> henninge: no, templates need views to work
[10:42] <henninge> ok, thanks
[10:43] <bigjools> in the same way they need a context
[10:45] <henninge> well, the view provides the context, doesn't it?
[10:46] <bigjools> henninge: grep dor create_view
[10:46] <bigjools> for*
[10:46] <wgrant> Mm, you could probably grab a PageTemplate manually. But that is bordering on more evil than the problem deserves.
[10:49] <henninge> yes, I was coming to that next. Why is that evel?
[10:49] <henninge> evil, even
[10:50] <wgrant> I don't think it's exactly light-weight, and I'm not sure how well it will work to instantiate one manually.
[10:51] <wgrant> Which bit of inline HTML are you replacing?
[10:51] <henninge> I got the same thing in at least four places
[10:52] <henninge> lp.translations.browser.potemplate.POTemplateUploadView
[10:53] <henninge> around line 492
[10:53] <henninge> It's creating a <ul> of file names.
[10:54] <wgrant> Ugh. We don't use templates for notifications anywhere else, but that just about deserves one :/
[10:54] <wgrant> Could you put them into the page's template?
[10:54] <wgrant> No.
[10:54] <wgrant> Because they need to be in the session.
[10:54] <wgrant> Hmm.
[10:54] <wgrant> Awkward.
[10:56] <henninge> I know it is
[10:56] <henninge> Acutally, I wrote that code in another life ...
[11:12] <jml> allenap: thanks! I didn't know that we had multiple security.py files.
[11:16] <wgrant> jml: Somebody is bound to come along and "s += untrusted_variable", and structured() won't stop that. MarkupSafe does, which is nice.
[11:17] <spiv> jml: so you're more secure than you thought!
[11:17] <jml> wgrant: so it's more that it makes it what variables are being used less obvious
[11:17] <wgrant> jml: Right. And it won't work after next week if my plan goes as I hope.
[11:18] <jml> wgrant: your plan... to use MarkupSafe?
[11:18] <wgrant> jml: Something like that.
[11:20] <wgrant> It remains to be seen how well this is going to work out, but I fixed all the FormatterAPIs up this evening and it seems to be OK.
[11:22] <jml> wgrant: cool.
[11:23] <wgrant> jml: MarkupSafe fixes that sort of thing by escaping any unsafe strings that are concatenated with it.
[11:23] <wgrant> So Markup('<b>') + 'untrusted' + Markup('</b>') does the right thing, if you want to do things like that.
[11:24] <jml> wgrant: as long as it's on the LHS of the operator, I guess.
[11:25] <wgrant> jml: Seems to work either way.
[11:25] <jml> wgrant: I skeptate.
[11:25] <wgrant> >>> Markup('<foo>') + '<bar>'
[11:25] <wgrant> Markup(u'<foo>&lt;bar&gt;')
[11:25] <wgrant> >>> '<bar>' + Markup('<foo>')
[11:25] <wgrant> Markup(u'&lt;bar&gt;<foo>')
[11:26] <jml> Huh. I wonder how that works.
[11:26] <wgrant> As do I.
[11:26] <jml> (incidentally kids, that was the scientific method in action)
[11:27] <wgrant> Ah.,
[11:27] <wgrant> __radd__
[11:28] <wgrant> (it's used by pylons and jinja2 and mako, so it seems to be a reasonable choice)
[11:30] <jml> uh.
[11:30] <wgrant> Oh?
[11:30] <jml> that was a typo for 'huh'
[11:31] <jml> I didn't know about __radd__
[11:31] <wgrant> Ah.
[11:31] <wgrant> I've not seen it used before :/
[11:32] <wgrant> That wasn't meant to happen.
[11:45] <jml> I'm on the conflict, btw.
[11:45] <jml> got distracted waiting for make compile so I could run tests on the resolved code
[11:45] <jml> anyone around who's familiar with test_sharing_information?
[11:50] <bigjools> wow, 3 separate conflicts
[11:52] <jml> yeah.
[11:53] <jml> I guess we've done more work on db-devel recently.
[11:53]  * jml famished
[11:57] <LPCIBot> Yippie, build fixed!
[11:57] <LPCIBot> Project devel build #591: FIXED in 5 hr 25 min: https://lpci.wedontsleep.org/job/devel/591/
[12:00] <bigjools> yeah mostly my squad I think
[12:01] <deryck> Morning, folks.
[12:01] <bigjools> howdy deryck
[13:22] <LPCIBot> Project windmill build #121: STILL FAILING in 1 hr 10 min: https://lpci.wedontsleep.org/job/windmill/121/
[14:00] <deryck> adeuring, henninge, abentley -- I'll be 5 minutes late for standup, sorry.  Compiling notes from another conversation.
[14:01] <abentley> deryck: okay, ping when ready.
[14:05] <deryck> abentley, adeuring, henninge -- ok, ready.  jumping into mumble now.
[14:07] <benji> gary_poster: I guess I'll move the "Get client branch reviewed" card back to one of the WIP spots... but I don't remember which one it was in, feature work 2?
[14:08] <benji> I'll also add a card to move to the right channel.
[14:14] <james_w>         # Create the credentials with no Consumer, then set its .consumer
[14:14] <james_w>         # property directly.
[14:14] <james_w>         credentials = Credentials(None)
[14:14] <james_w>         credentials.consumer = consumer
[14:14] <james_w> the comment should say why!
[14:21] <deryck> henninge: http://developer.yahoo.com/yui/3/
[14:34] <jml> james_w: +1
[14:46] <allenap> danilos: Hello dude, fancy reviewing a few hundred lines of javascript? https://code.launchpad.net/~allenap/launchpad/dd-initseries-bug-727105-form-submission/+merge/55514
[14:46] <danilos> allenap, why of course
[14:47] <allenap> danilos: Thank you very much :)
[14:47] <bigjools> why on earth does LP reject an email review to an MP with no subject line?
[14:58] <danilos> allenap, fwiw, there's a conflict in lib/lp/soyuz/scripts/tests/test_initialise_distroseries.py with devel (it's simple, but just fyi)
[15:00] <jml> umm
[15:01] <jml> didn't that get fixed yesterday or something?
[15:01] <jml> bigjools: don't know, actually.
[15:02] <deryck> henninge: chat in 2?  Running late, as seems my habit lately. :-)
[15:02] <henninge> deryck: ok
[15:02] <danilos> allenap, also, what's the +feature-rules line I need for this particular feature?
[15:07] <allenap> danilos: Oops, looking...
[15:08] <allenap> danilos: soyuz.derived-series-ui.enabled	default	1	true
[15:15] <danilos> allenap, thanks
[15:19] <danilos> allenap, FormActionsWidget looks pretty neat, is this not something that should be used in many of our other forms? do you have plans to factor it out?
[15:20] <allenap> danilos: Yeah, there's a few bits and pieces in that module that could be quite reusable. They're not up to standard for lazr-js I don't think. I intend to refactor as I need them in future branches for the derived distributions feature.
[15:21] <danilos> allenap, sounds good, we've also been doing similar stuff with our feature development and could have benefited from the same work, so it'd be nice to share it on the mailing list as well :)
[15:22] <allenap> danilos: Yeah, good idea. Okay, I'll write something.
[15:22] <danilos> allenap, danke schön :)
[15:28] <danilos> allenap, I wonder about Camel Case On Buttons, is that the recommended UI practice?
[15:29] <allenap> danilos: I don't know, I just carried on merrily :)
[15:32] <jml> it's not.
[15:32] <jml> I think.
[15:32] <jml> gah, I don't know any more
[15:33] <allenap> danilos: Ah, you just mean the words on the button, visible in the UI?
[15:33] <allenap> Sorry, I got mixed up there.
[15:33] <jml> there must be a guide *somewhere*...
[15:33] <jml> https://dev.launchpad.net/UserInterfaceWording
[15:33] <jml> Buttons and tabs should be Headline Case; the last word capitalized, and all other words capitalized except those three letters or fewer that are prepositions, articles, or conjunctions.
[15:35] <allenap> jml: Does Launchpad have tabs in the UI?
[15:35] <allenap> danilos: So, I should change the button wording.
[15:35] <jml> allenap: I guess not any more.
[15:35] <jml> allenap: apart from the component tabs.
[15:41] <allenap> jml: Thanks for digging that page up.
[15:42] <jml> allenap: np
[16:09] <allenap> danilos: Thanks for the review :)
[16:10] <danilos> allenap, you are welcome
[16:11] <danilos> allenap, yeah, jml is right, no need to change the button text it seems
[16:11] <danilos> allenap, anyway, all good I'd say, a very nice, nice branch :)
[16:12] <allenap> danilos: Ah, I did change it, to "Initialize Series".
[16:13] <danilos> allenap, heh, fair enough :)
[16:27] <gmb> losa ping
[16:29] <mbarnett> heya gmb
[16:29] <gmb> Hey mbarnett. Can you run and paste the results of `SELECT * from BugWatch WHERE bug = '710652';` on production for me?
[16:32] <adeuring> abentley: could you have a lok at this mp: https://code.launchpad.net/~adeuring/launchpad/js-translation-2/+merge/55575 ?
[16:32] <abentley> adeuring: sure.
[16:32] <adeuring> thanks
[16:33] <mbarnett> gmb: http://pastebin.ubuntu.com/587408/
[16:33] <gmb> Ta
[16:40] <abentley> adeuring: Could you please use 'complete' rather than 'configured' in the ids, so that it matches the other entries?
[16:40] <adeuring> abentley: ah, right
[16:46] <adeuring> abentley: just noticed that i forgot a few tests, for the upstream sync link...
[16:46] <abentley> adeuring: cool.
[16:50] <jml> https://code.launchpad.net/~jml/launchpad/old-twisted-bugs/+merge/55569
[16:50] <jml> abentley: can you please review that?
[16:50] <abentley> adeuring: in the tests, did you consider using canonical_url to generate the exact expected URLs, rather than using regexes to match?
[16:50] <abentley> jml: sure, I'll look at that next.
[16:51] <adeuring> abentley: right, we can do that
[16:56] <abentley> adeuring: did you consider writing the tests of translation_sync_link_configured etc as view tests rather than browser tests?
[16:56] <abentley> adeuring: i.e. instead of getting the page and parsing it, you'd just inspect the return value of translation_sync_link_configured?
[16:57] <adeuring> abentley: well, that's possible. I don't have a real opinion there...
[16:58] <abentley> adeuring: Well, testing the output HTML is more of an integration test and testing the view is more of a unit test.
[16:58] <adeuring> abentley: ok, i'll change them
[16:59] <jml> abentley: thanks.
[17:02] <abentley> adeuring: Cool.  When I ask questions like this, I'm not necessarily asking for a change, but I do want to understand whether there's a reason you went one way instead of another.
[17:14] <LPCIBot> Project devel build #592: FAILURE in 5 hr 17 min: https://lpci.wedontsleep.org/job/devel/592/
[19:04] <benji> I'm getting NotFound exceptions on icon-sprites; does that ring any bells for anyone?
[19:09] <james_w> could someone help diagnose bug 745801 as it's frustrating testing of one of our projects?
[19:10] <_mup_> Bug #745801: system-based authorization doesn't store useful credentials in gnome-keyring <amd64> <apport-bug> <natty> <launchpadlib :New> <python-launchpadlib (Ubuntu):New> < https://launchpad.net/bugs/745801 >
[19:22] <bac> benji: re: icon sprites, look at rev 12697
[19:23] <benji> bac: thanks
[19:23] <benji> bac: 12697 of devel or something else?
[19:24] <bac> devel
[19:24] <bac> benji: https://code.launchpad.net/~huwshimi/launchpad/private-objects-298152/+merge/53195
[19:24] <bac> of note you'll see that branch removed icon-sprites.  :(
[19:25] <benji> oh!  I wasn't getting the connection between "Changed private bug notifications to be more obvious." and sprites.  So in other words "it's broke".
[19:28] <lifeless> sinzui: bug 745791 is deliberate, no?
[19:28] <_mup_> Bug #745791: participation links are all blue <Launchpad itself:New> < https://launchpad.net/bugs/745791 >
[19:30] <sinzui> lifeless: yes. We have not concluded what they should look like
[19:31] <sinzui> lifeless: I think the bug is legitimate. huwshimi needs to address it, or advice me
[19:31] <lifeless> bigjools: why does queue acceptance read from the librarian?
[19:31] <bigjools> lifeless: because it publishes files
[19:31] <bac> benji: yes.  broken.
[19:31] <bac> benji: i copied icon-sprites from another branch and it is fine
[19:31] <bigjools> lifeless: or are you not talking about process-accepted?
[19:31] <bac> benji: i'll land a fix that restores them
[19:31] <lifeless> bigjools: https://bugs.launchpad.net/launchpad/+bug/745799
[19:31] <_mup_> Bug #745799: Timeout accepting packages <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/745799 >
[19:31] <benji> cool, as long as we know about it
[19:32] <bigjools> lifeless: let me check
[19:33] <lifeless> bigjools: bottom of the summary, or look at the oops directly
[19:36] <bigjools> lifeless: ah it's checking filenames and checksums
[19:37] <bigjools> lifeless: see lib/lp/soyuz/model/queue.py, setAccepted()
[19:40] <bigjools> lifeless: it's also showing packagediffs
[20:00] <jcsackett> anyone else chasing the merge conflicts pqm is nagging about?
[20:02] <lifeless> jcsackett: I don't think so
[20:04] <jcsackett> lifeless: dig. it's vexing me, so i'll kill it.
[20:04] <lifeless> \o/
[20:05] <lifeless> jcsackett: btw, did you see the bug on merge proposal diff popups ?
[20:05] <jcsackett> lifeless: i saw it yes. not sure it's a regression, since technically we're still better than we have been since i started looking at the popup. :-)
[20:05] <lifeless> jcsackett: :)
[20:06] <jcsackett> i may pick that one up soon; depends how much i feel like cursing the javascript gods.
[20:08] <lifeless> jcsackett: no worries, I only mention cause you are now familiar with it :P
[20:08] <jcsackett> lifeless: for a very small value of "familiar" :-P
[20:09] <jcsackett> and i'm not going to be able to easily resolve those merge conflicts after all. this appears non-trivial.
[20:10] <jcsackett> sinzui: i just noticed it's slightly past three. mumble time still good?
[20:12] <sinzui> jcsackett: can we postpone to 4:00. I have to leave early today
[20:13] <jcsackett> sinzui: hm, any chance we can do 4:15?
[20:13] <jcsackett> sinzui: if not, 4 can work, 415 would just be easier.
[20:13] <sinzui> okay
[20:14] <jcsackett> fantastic. thanks. :-)
[20:16] <bac> sinzui: here are the changes i've made to the Makefile:  http://pastebin.ubuntu.com/587496/
[20:16] <bac> unfortunately, the dependency i added to sprite_images is not working and the file is rebuilt whether it exists or not
[20:16] <bac> i thought removing it from .phony would be the trick
[20:16] <bac> my makefile fu is atrophied
[20:19] <lifeless> .phony says 'do not look at disk timestamps', so its certainly a good first step
[20:19] <sinzui> That is tricky. We only want to use create-image when the position file or sprites.css.in has changed.
[20:19] <lifeless> however
[20:19] <lifeless> its transitive
[20:19] <lifeless> if foo depends on bar
[20:19] <bac> lifeless: right, that's why removing it made sense
[20:19] <lifeless> neither foo nor bar can be .phony
[20:19] <bac> there are no phony dependencies
[20:20] <lifeless> ok
[20:20] <bac> i expect 'make sprite_image' to create the file and the next 'make sprite_image' to report nothing to be done
[20:26] <lifeless> sinzui: db-devel conflicts
[20:26] <lifeless> sinzui: you may know; is reassign a new menu entry for distributions?
[20:26] <lifeless> sinzui: or one that was removed
[20:27] <sinzui> lifeless: I believe it is new. We never admitted it could be done in the past
[20:27] <lifeless> ok
[20:27] <lifeless> I think I have a resolution then
[20:28] <lifeless> http://pastebin.com/vBapxE6w
[20:28] <lifeless> ^ can has sanity check
[20:29] <lifeless> \o/ on huw's ajax thingy
[20:30] <lifeless> deryck: ^ - btw the initial version is in devel so you can see what he's working towards with the need for url info
[20:30] <deryck> lifeless: ah, ok.  I'll take a peak then.  Thanks
[20:30] <lifeless> deryck: its controlled by the visible_render_time flag
[20:31] <lifeless> so you can see it on https://bugs.qastaging.launchpad.net/launchpad
[20:31] <deryck> ok
[20:31] <deryck> this is really nice
[20:32] <lifeless> yeah, its pretty cool
[20:32] <lifeless> needs the url to be /really/ useful
[20:35] <lifeless> sinzui: I'll land what I have, i think its no worse
[20:40] <lifeless> sinzui: ping
[20:40] <bac> lifeless, sinzui: i got the makefile to work: http://pastebin.ubuntu.com/587507/
[20:40] <bac> the key is to separate the phony, easy-to-type target from the files
[20:43] <lifeless> bac: looks fine to me
[20:46] <lifeless> sinzui: is bug 162510 actually fix released ?
[20:46] <_mup_> Bug #162510: Person:+delete timeouts : Person merging needs to be done asynchronously <canonical-losa-lp> <chr> <feature> <lp-registry> <merge-deactivate> <qa-untestable> <tech-debt> <timeout> <Launchpad itself:Fix Released by allenap> < https://launchpad.net/bugs/162510 >
[20:47] <lifeless> ah, bug 728471
[20:47] <_mup_> Bug #728471: Person:+delete timeouts : Add sanity checks to mergeAsync <merge-deactivate> <qa-ok> <timeout> <Launchpad itself:Fix Released by sinzui> < https://launchpad.net/bugs/728471 >
[20:50] <jcsackett> can someone tell me if bug 151362 is something we care about? do we support/care about basic given oauth?
[20:50] <_mup_> Bug #151362: Error: Incorrect padding (base64 error) during authentication <lp-foundations> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/151362 >
[20:51] <lifeless> we still support basic auth in dev mode
[20:51] <lifeless> we should either nuke it entirely
[20:51] <lifeless> or have it robust
[20:52] <lifeless> (the test suite depends on this at the moment)
[20:52] <jcsackett> lifeless: dig.
[20:52] <jcsackett> fixing the error seems like the easier to take on in afternoon solution.
[20:52] <jcsackett> vs nuking and removing the need for it.
[20:52] <lifeless> I think we care, but its trivial to fix: catch and return auth required
[20:52] <lifeless> s/return/reraise
[20:53] <jcsackett> lifeless: right on.
[20:53] <lifeless> ah
[20:53] <sinzui> lifeless: hell no. this is vesitigal from the merges of other branches
[20:53] <lifeless> sinzui: context?
[20:53] <sinzui> lifeless: I am pretty confident that bug will not be fixed this week
[20:53] <lifeless> jcsackett: also there are two bugs conflated there
[20:54] <jcsackett> sinzui: you're referring to the merge person stuff, right?
[20:54] <lifeless> sinzui: its marked fix released is all; a user reported a new incident; I haven't duped because I was unsure o fthe status
[20:54] <lifeless> jcsackett: the OOPS at the bottom of the bug you are looking at is for a different occurence of the same exception class
[20:54] <jcsackett> lifeless: ah, thanks.
[20:54] <lifeless> jcsackett: so I suggest you file a new bug for the OOPS (1188C1227)
[20:55] <jcsackett> will do.
[20:55] <sinzui> lifeless: allenap ran out of time (and scope) when working on that bug. we are traking the timeout in another bug because he claimed that one was fixed. His branch provided infrastructure to fix the issue
[20:55] <lifeless> sinzui: yep. the other bug is also closed ;)
[20:55] <jcsackett> sinzui: if you still wanted to chat at 4, the conflict i thought i had has disappeared, so i'm available at your convenience.
[20:56] <sinzui> lifeless: bug 736421 i still open
[20:56] <_mup_> Bug #736421: Person:+delete timeouts : Connect the UI the merge jobs <merge-deactivate> <Launchpad itself:In Progress by sinzui> < https://launchpad.net/bugs/736421 >
[20:56] <sinzui> lifeless: I can finish that bug when I can return to bug 740559
[20:56] <lifeless> sinzui: ahh, its not tagged timeout
[20:56] <_mup_> Bug #740559: Update PersonNotification to support teams <merge-deactivate> <Launchpad itself:In Progress by sinzui> < https://launchpad.net/bugs/740559 >
[20:56]  * lifeless tags it
[21:18] <deryck> Later on, everyone.
[21:32] <lifeless> -> allergy shot, BBIAB
[21:36] <bac> sinzui: you see any reason to keep icon-sprites.positioning in the tree if we have sufficient makefile support to generate it on demand?
[21:40] <sinzui> bac: I think removing that file will make our house of cards topple
[21:40] <bac> i don't think so sinzui
[21:41] <bac> i've removed it and updated the makefile rules and all seems well
[21:41] <sinzui> icon-sprites.positionin + sprites.css.in = sprites.css
[21:41] <bac> right, and as long as create_css dependson i-s.pos then it'll rebuild
[21:42] <sinzui> bac: I stand down. you are correct
[21:42] <bac> sinzui: looky at http://paste.ubuntu.com/587535/
[21:43] <bac> sorry for the distracting boxes
[21:44] <sinzui> that looks correct
[21:47] <bac> great, i'll piggyback it on my next branch
[22:03] <wallyworld> thumper: morning. standup?
[22:03] <thumper> wallyworld: sure
[22:04] <wallyworld> thumper: i can hear you
[22:05] <wallyworld> thumper: my lips are red here
[22:05] <wallyworld> thumper: ffs. try skype?
[22:22] <LPCIBot> Yippie, build fixed!
[22:22] <LPCIBot> Project devel build #593: FIXED in 5 hr 7 min: https://lpci.wedontsleep.org/job/devel/593/
[22:25] <jcsackett> apparently i have been disconnected for some time. hurrah.
[22:28] <sinzui> jcsackett: mumble?
[22:31] <jcsackett> sinzui: sure.
[22:58] <wgrant> Morning.
[22:58] <huwshimi> wgrant: Morning
[23:01] <sinzui> wallyworld: thumper, mumble?
[23:03] <thumper> sinzui: I can't hear you :(
[23:03] <huwshimi> thumper: we can hear you
[23:03] <thumper> damn, same thing happened with wallyworld and me earlier
[23:05]  * wgrant fixes the conflict.
[23:25] <sinzui> wgrant: I neglected to mention that the mhonarc rt was closed. We are running the latest version now
[23:25] <wgrant> sinzui: Great!
[23:51] <wallyworld> sinzui: sorry i missed your ping. i had already had a call with tim after which i was dropping the kid to school and then having breakfast