[00:00] <lifeless> pg upstream would probably do pg.bouncer if at all; namespace packages are a pita to package
[00:55] <lifeless> hmm
[00:55] <lifeless> probably want to make the rabbit fixture port allocation logic reusable
[02:10] <wgrant> Bah.
[02:10] <wgrant> The critical deficit is resolved already.
[02:13] <StevenK> wgrant?
[02:13] <wgrant> We were at 239 criticals two checks ago, 237 when I checked this morning, and now 239 :)
[02:33] <thumper> hi
[02:33] <thumper> what's the status of the magic diff updating?
[02:36] <lifeless> magic?
[02:46] <lifeless> db rebulid is good for the soul:  * 266 Time Outs
[02:56] <lifeless> woo
[02:56] <lifeless>  16384 | test_db1 |    2801 |    16385 | user1   | select * from pg_stat_activity; | f       | 2011-07-18 02:55:50.531462+00 | 2011-07-18 02:55:50.531462+00 | 2011-07-18 02:55:31.384875+00 |             |          -1
[02:56] <lifeless> machine setup pgbouncer.
[02:56] <lifeless> now we're bootstrapped, I can move onto more interesting tests.
[02:58] <wgrant> thumper: Waiting on Red Squad being free to fulfill lifeless' deployment requirements.
[03:04]  * thumper nods
[03:05] <wgrant> Mostly needs OOPS integration and metrics now, I think.;
[03:15] <michaelh1> Hey, I just had a play with bzr-git for importing the GDB 7.3 release branch into Launchpad.
[03:16] <michaelh1> It works well, and can track more than one branch - you need to create a remote tracking branch first, but that's cheap
[03:18] <poolie> michaelh1: rocking!
[03:18] <poolie> hopefully soon lp will be able to track multiple branches
[03:18] <michaelh1> yeah, so to my naive eyes it has the support that LP needs.
[03:19] <poolie>  yes, it does
[03:25] <huwshimi> A simple review if someone wants it: https://code.launchpad.net/~huwshimi/launchpad/email-tag-order-645962/+merge/68207
[03:26] <wgrant> michaelh1: A remote tracking branch?
[03:27] <wgrant> huwshimi: Ah, that has bugged me for ages!
[03:27] <huwshimi> wgrant: Yeah, I finally got sick of it this morning :)
[03:27] <michaelh1> wgrant: yeah, bzr-git converts any local branches to bzr branches in refs/branch-name.  It won't do remote branches, but you can set up a local branch that tracks the remote branch
[03:28] <wgrant> michaelh1: Oh, doing an import like that, I see.
[03:28] <wgrant> That's not how Launchpad does it.
[03:28] <wgrant> huwshimi: Excellent. Approved.
[03:28] <huwshimi> wgrant: Thanks mate!
[03:37] <poolie> i was wondering in the shower if lp ought to show 'recently frequently duplicated bugs' as suggestions in +filebug
[03:37] <poolie> and whether they would be better guesses, for some users, than matching on words in the suggestion
[03:37] <poolie> or in fact hot bugs would be close to the same thing
[03:40] <lifeless> well, the dup search should factor that in perhaps
[03:40] <lifeless> OTOH many devs (me included) think offering dup detection is often misguided
[03:44] <poolie> because the person filing the bug is not in a good position to know if it's a dupe?
[03:45] <lifeless> yup
[03:45] <lifeless> and superficial things like the backtrace are often not indicative of dupe-or-not
[03:45] <poolie> i agree
[03:45] <lifeless> sometimes they are, one-size doesn't fit all
[03:46] <poolie> yep
[03:46] <wgrant> That's not very Launchpad of you.
[03:48] <lifeless> wgrant: ok, so you didn't like pgbouncer as a module name
[03:52] <wgrant> lifeless: Correct.
[03:52] <wgrant> Do I have suggestions beyond terribleness like pgbouncerfixture? Nope.
[03:54] <wgrant> Hmm.
[03:54] <wgrant> Let's play "make qastaging update faster".
[03:56] <lifeless> wgrant: so, in the absence of suggestions, I'm going with pgbouncer... we can do a rename dance later if needed
[03:56] <wgrant> Perhaps.
[03:56] <poolie> could someone tell me briefly how lp's debian publication metadata importer works?
[03:56] <wgrant> Perhaps we should make namespace packages not suck.
[03:56] <poolie> or point me to a wiki page or code
[03:56] <wgrant> poolie: grep around for gina
[03:56] <wgrant> poolie: There's no wiki page that I know of.
[03:56] <poolie> how does it get the data?
[03:56] <wgrant> poolie: It is very unLaunchpaddy.
[03:56] <poolie> is that a good thing? :)
[03:57] <wgrant> poolie: debmirror runs on iron to create a local mirror. gina then walks the indices and imports everything it sees.
[03:57] <wgrant> This means it fails at tracking removals etc.
[03:58] <poolie> (for optional context, https://lists.ubuntu.com/archives/ubuntu-distributed-devel/2011-July/000872.html)
[03:59] <wgrant> poolie: Sounds like our imports are badly timed.
[04:00] <wgrant> I believe we import at the same frequency, but perhaps too offset.
[04:00] <lifeless> well
[04:00] <poolie> between the ubuntu imports and debian
[04:00] <wgrant> 52 2,8,14,20 * * * sh /srv/debian-import.launchpad.net/scripts/mirror-update.sh >> /srv/debian-import.launchpad.net/production-logs/mirror-update.log 2>&1
[04:00] <lifeless> folk have been known to upload the same version to both
[04:00] <wgrant> 05 3,9,15,21 * * * LPCONFIG=gina /srv/debian-import.launchpad.net/production/launchpad/scripts/gina.py lenny squeeze sid experimental wheezy >> /srv/debian- import.launchpad.net/production-logs/gina.log 2>&1
[04:01] <poolie> there seems to be a bug that codehosting oopses like https://lp-oops.canonical.com/oops.py/?oopsid=2021BZR207511 don't actually include a traceback
[04:02] <poolie> or is that just a one off?
[04:05] <lifeless> many others do
[04:05] <lifeless> I don't know why that doesn't.
[04:05] <poolie> oh well, bug 812106
[04:05] <_mup_> Bug #812106: codehosting oops doesn't include traceback <codehosting> <oops-infrastructure> <Launchpad itself:Triaged> < https://launchpad.net/bugs/812106 >
[04:06] <poolie> can fix or investigate it if it ever actually gets in the way
[04:07] <lifeless> poolie: please use the code not the URL for oopses - otherwise they get gc'd
[04:07] <poolie> huh
[04:07] <poolie> they get gc'd when there's no open bug that mentions it?
[04:09] <lifeless> yes
[04:09] <poolie> ok lunch
[05:00] <lifeless> ok, EODing
[05:00] <lifeless> till stub is around
[05:03] <StevenK> wgrant: qas is WADLing
[05:03] <wgrant> I sometimes wonder if the name was deliberate.
[05:04] <StevenK> Haha
[05:06]  * StevenK kicks vocabs more
[05:22] <wgrant> StevenK: You don't happen to feel like qa/donotcareing bug #808680, do you?
[05:22] <_mup_> Bug #808680: The initializeddistroseries job fails with "permission denied for relation distributionjob" <derivation> <qa-needstesting> <Launchpad itself:Fix Committed by rvb> < https://launchpad.net/bugs/808680 >
[05:22] <wgrant> It's all that's blocking a 48 revision deployment.
[05:22] <StevenK> qa-untestable
[05:23] <wgrant> It only affects multiparent initialisation, so I'm tempted to donotcare it.
[05:23] <StevenK> Same
[05:23] <StevenK> Doit
[05:23]  * wgrant doesit.
[05:23]  * wgrant makes tea while qa-tagger updates.
[05:23] <StevenK> wgrant: Do you need a hand putting the deployment request together?
[05:23] <StevenK> 48? qatagger says 32
[05:24] <wgrant> 15 ready to deploy, one blocker, 32 behind it.
[05:25] <StevenK> The deployment report should say that
[05:25] <lifeless> patch it up
[05:25] <lifeless> its one of our codebases
[05:27] <StevenK> Oh, sure. In the *oddles* of spare time I have :-P
[05:28] <wgrant> Maybe I will decide I've had enough lazr-js for the day and try to fix it.
[05:30] <StevenK> Besides, we can't. 1) We are not on maintaince. 2) Even if we were, criticals take priority.
[05:31] <wgrant> lifeless: Are you in lpqateam?
[05:31] <wgrant> Yes.
[05:32] <wgrant> lifeless: Could you maybe change the crontab to regenerate lpqateam.canonical.com at 02,12,22,32,42,52, rather than a minute before qa-tagger?
[05:36] <StevenK> Just what I wanted. A 131 line traceback
[05:39] <wgrant> Oh goddammit.
[05:40] <wgrant> There is a third revision involved in the mess.
[05:40] <wgrant> I think it's just missing CSS, though.
[05:41] <StevenK> If you say there is another rollback ...
[05:52] <wgrant> With r13421 reverted, collapsibles created by activate_collapsibles (eg. "Extra options" on +filebug, "Configuration progress" on Product:+index) are no longer green.
[05:52] <wgrant> Not sure we care for a day or so.
[05:53] <StevenK> wgrant: File a critical/high, asign to Danilo, move on?
[06:13] <lifeless> hi stub
[06:13] <lifeless> stub: I have a present for you
[06:14] <stub> Like your cat has a present for you?
[06:14] <lifeless> better
[06:15] <lifeless> https://launchpad.net/python-pgbouncer
[06:20] <lifeless> stub: I wanted to simulate the 'cannot connect behaviour for the builddmaster
[06:21] <lifeless> stub: and realised I had no idea what that meant pgbouncer wise, nor any way of programmatically testing it
[06:21] <stub> I will have the answers to your questions today.
[06:22] <lifeless> stub: so the new module bring up pgbouncer and should (as stands, or with minor tweaks - e.g. a reload() method to run pgbouncer -R) let us drive it programattically
[06:22] <stub> There are two possibilities to what will happen - the connection is accepted by pgbouncer and is blocked, or the connection gets rejected. Depends on how much control pgbouncer gives me.
[06:23] <lifeless> stub: FWICT dropping the user definitions (assuming we're using 'trusted') would block during connection
[06:23] <lifeless> stub: that seems to be the only knob I could find that doesn't talk to the backend
[06:26] <stub> lifeless: http://pgbouncer.projects.postgresql.org/doc/usage.html , in particular PROCESS CONTROLLING COMMANDS
[06:27] <stub> I've tested PAUSE and it seems to do what we want, with inbound connections just blocking. I need to test SUSPEND in case we think it better to reject connections rather than queue them up for when things come back online.
[06:28] <wgrant> stub: Oh, suspend rejects connections? :/
[06:28] <stub> This is easy and reliable for me to control, as I just open a database connection to the internal 'pgbouncer' database and issue commands with psycopg2 or psql - no need to edit or swap config files in place.
[06:29] <stub> wgrant: I don't know about suspend. if we don't want to reject, we use PAUSE.
[06:29] <lifeless> stub: I think it better to reject
[06:29] <lifeless> stub: unless we can guarantee < 5 second application times (because 5 seconds is the hard timeout for new pages)
[06:30] <stub> wgrant: Blocking until the system is back up isn't necessarily the best choice - eg. it might be preferable for appservers to display a 'down for maintenance' message rather than queuing up requests until HAProxy displays a 'down for maintenance' message
[06:30] <wgrant> Right.
[06:31] <stub> lifeless: Yup. Anyway - I'm working on the script today on staging. I should also be able to reliably do 'sudo /etc/init.d/pgbouncer stop' or just kill the pgbouncer processes. That will also reject connections :-)
[06:31] <lifeless> stub: indeed :P
[06:31] <wgrant> I think this whole no-readonly thing is pretty hideous, but if we're going that direction then immediate notification is better than one based on a timeout.
[06:31] <stub> lifeless: If you are playing now, just 'sudo pgctlcluster 8.4 main stop' and see what exception you get trying to connect to a database that is not there at all.
[06:31] <lifeless> stub: anyhow, we can make the pgbouncer python module support the same thing, so we can test how the appserver etc handle it
[06:32] <lifeless> stub: without pgbouncer its OperationalError: connection failure ...
[06:32] <lifeless> stub: I can now play with pgbouncer of course :>
[06:32] <stub> Which will be a subclass of psycopg2.Exception (Error?) - probably best to just catch that on connection attempts.
[06:33] <lifeless> mmm perhaps; probably needs a code read if we want to be broad
[06:34] <stub> Well, we don't really care *why* the connection failed. Unless you want to get into socket exceptions for things like no-route-to-host vs. nothing listening, but there are so many choices there we won't do full coverage.
[06:35] <lifeless> indeed
[06:35] <lifeless> uhm
[06:35] <stub> esp. as they will be coloured by how the firewall rules are (mis)configured
[06:35] <lifeless> I don't know if we do don't.
[06:35] <lifeless> will all depend on the most (fast-and-reliable) way to stop pgbouncer letting stuff through
[06:35] <stub> I think treating all connection failures the same, and monitoring when scripts don't run for extended periods of time, covers us.
[06:36] <stub> The monitoring will catch the stuffups such as users not existing or dud firewall rules etc.
[06:36] <lifeless> sure
[06:37] <lifeless> I guess I have a small worry that we'll be down for 30 seconds or something with a maintenance page before anyone starts actually clicking to there being a problem when we didn't plan to go down
[06:45] <lifeless> anyhow, this is minor and contingent on the actual implementation in pgbouncer anyhow
[06:47] <jtv> Morning folks.  Any objects to my running process-accepted on dogfood?
[06:47] <wgrant> jtv: None, but I think that bug is already QAed...
[06:48] <jtv> You would know — but did you actually Q/A the new feature, or just test that it didn't affect the features we currently rely on?
[06:48] <wgrant> --derived seems to behave as specified.
[06:48] <jtv> That's great — thanks!
[06:49] <wgrant> (I think it's probably dangerous, but we'll see)
[06:49] <jtv> gulp
[06:49] <jtv> Care to explain that?
[06:50] <jtv> If it's dangerous, it may be good to be aware of it before we "see."
[06:50] <wgrant> Given that the primary archive publisher is not meant to be bulletproof and unexploitable, automatically publishing every Ubuntu derivative on one machine seems... potentially unwise.
[06:50] <wgrant> What with the whole running arbitrary shell scripts and stuff thing.
[06:50] <wgrant> With paths configurable in the web UI, albeit only by ~admins at this stage.
[06:50] <jtv> Arbitrary?
[06:52] <wgrant> eg. things like Baltix are derivatives of Ubuntu, but probably don't want to go near bilimbi.
[06:56] <poolie> lifeless: re the postmortem: why not just pop back to the last safe version, rather than landing a reversion?
[06:56] <poolie> or rather than landing a reversion first
[06:57] <lifeless> poolie: I'm talking about things we haven't deployed
[06:57] <StevenK> poolie: If we do that then the deployment pipeline stalls for longer than 5 hours.
[06:57] <poolie> ?
[06:57] <poolie> ah, so it failed to deploy
[06:58] <lifeless> no
[06:58] <lifeless> failed qa
[06:58] <wgrant> It failed QA, was not the head rev so had to be reverted.
[06:58] <wgrant> Was fixed, deployed, broke production, rolled back, reverted. Another 5 hours.
[06:59] <poolie> was it deployed or not?
[06:59] <wgrant> The second time.
[06:59] <wgrant> IIRC it failed QA the first time.
[06:59] <lifeless> poolie: when it does get through to prod, we do just switch to the previously deployed version, but we still also land a rollback (async from fixing prod)
[07:00] <poolie> ok i see
[07:00] <lifeless> switching prod versions takes an hour, and then we're blocked on all deploys till the rollback gets through on trunk *and* we're fully qaed.
[07:00] <lifeless> its a Real Big Deal, but fortunately fairly rare
[07:00] <poolie> the rollback is to get trunk back to a state on which other changes can be landed
[07:01] <wgrant> lifeless: Rolling production back to a previous rev is quick.
[07:01] <wgrant> But still a big pain.
[07:01] <lifeless> wgrant: takes a while to walk the server processes
[07:02] <lifeless> wgrant: we don't have to stage code, buts its still kinda slow
[07:02] <poolie> i guess splitting the test suite here could be good to
[07:02] <poolie> to say that changes to bzr probably don't need all the malone pagetests run
[07:02] <poolie> though, doing that manually would probably be tedious
[07:02] <poolie> ok
[07:02] <wgrant> poolie: Why don't they?
[07:03] <wgrant> You would be unpleasantly surprised :)
[07:03] <poolie> there is a good cost:benefit to running them?
[07:04] <poolie> so is switching production versions "quick" or "an hour" or an hour is quick by lp deployment standards?
[07:04] <lifeless> its a bit less than an hour
[07:04] <wgrant> poolie: It's quicker than an hour, but an hour is quick.
[07:04] <lifeless> buts it not quick
[07:04] <poolie> :)
[07:06] <poolie> so the timeline was:
[07:07] <poolie> committed to devel; rolled out to qas; failed qa; attempted fix; fix rolled out to qas; passed qas(?); rolled out to lpnet; broke production; rolled back on production; reversion merged
[07:07] <poolie> is that correct?
[07:07] <lifeless> no
[07:08] <lifeless> committed to devel, rolled to qa, failed qa, rolled back, recommitted with fix to devel, rolled to qa, passed qa, deployed, broke, production switched to prior version and deploys frozen, rolled back on devel, recommitted with fix to devel, ...
[07:09] <lifeless> deployed to qa, deployed to prod
[07:09] <poolie> ok
[07:13] <poolie> so it seems like catching things on qastaging is only a little cheaper than catching them after that?
[07:13] <poolie> it's still a lot of work but at least there is no production outage?
[07:15] <lifeless> right
[07:16] <lifeless> and we can deploy up to the bad commit
[07:16] <lifeless> which (all too frequently) is useful - its a sign we're closing the queue too slowly
[07:25] <poolie> what was that python docs -> web service jml used?
[07:25] <poolie> rtfm something
[07:25] <nigelb> readthedocs?
[07:26] <spiv> Yeah
[07:26] <poolie> yep thanks
[07:26] <nigelb> poolie: the shortform, rtfd is more entertaining :)
[07:27] <nigelb> oh, that was built in 24 hours o.O
[07:55] <adeuring> good morning
[07:59] <jtv> hi adeuring!
[07:59] <adeuring> hi jtv!
[08:02] <bigjools> morning all
[08:09] <mrevell> Morning
[08:09] <jtv> hi bigjools, hi mrevell!
[08:10] <lifeless> allo allo ukians
[08:11] <bigjools> any ever seen lp.services.job.tests.test_runner.TestTwistedJobRunner.test_memory_hog_job fail in ec2?
[08:11] <bigjools> anyone*
[08:11] <bigjools> I happened to have made changes to IJob in my branch but it passes locally
[08:12] <jtv> I remember seeing _some_ failures in that area… hang on, I'll search.
[08:15] <StevenK> poolie: Are you still around?
[08:15] <poolie> oui
[08:16] <StevenK> poolie: bazaar-experts has had its celebrityness removed in prod, do you think it's worthwhile to delete the team in a few days?
[08:16] <poolie> i do
[08:16] <poolie> thanks for cleaning that up
[08:16] <jtv> bigjools: not much luck so far, and I'm back more than a month.
[08:16] <poolie> you might want to reply on the thread if it's not already clear
[08:16] <bigjools> jtv: oh well
[08:16] <bigjools> could be very spurious.  I'm re-landing.
[08:20] <jtv> danilos: did you see bug 810309?
[08:20] <_mup_> Bug #810309: Translator credits appear duplicated <Launchpad itself:Triaged> < https://launchpad.net/bugs/810309 >
[08:24] <jtv> bigjools: I need to make some config settings for generate-contents-files; wgrant thankfully discovered something I had neglected to take care of.  Are dogfood and ftpmaster-publish the right, and complete, configs to edit?
[08:25] <bigjools> jtv: should be
[08:25] <jtv> OK, then up for review it goes.
[08:25] <bigjools> what did he see?
[08:25] <jtv> I didn't set the content_archive_root setting, which points the new script to where the (now legacy) ubuntu-contents dir is.
[08:25] <bigjools> ah that
[08:26] <wgrant> Apart from that it all looks good and a tad less awful than the shell script :)
[08:26] <jtv> Once we've started using the new script, we can retire that item again; I have a separate bug filed about that.
[08:26] <jtv> Thanks. :)
[08:26] <wgrant> Plus it actually works.
[08:27] <wgrant> jtv: Any reason not to start using the script as soon as it's on cocoplum, given that the old one doesn't work any more?
[08:27] <jtv> Far as I know, only this one last point.
[08:28] <jtv> (Of course there's usually _another_ one last point after that, but we can hope :)
[08:28] <wgrant> heh.
[08:28] <jtv> I'm trying to take it all in stages and be meticulous about filing kanban cards; seriously scared about missing something.
[08:30] <lifeless> StevenK: remind me tomorrow and I'll nuke the team
[08:37] <StevenK> lifeless: I think tomorrow is too early, but if you can do it, excellent
[08:37] <lifeless> I own it now
[08:42] <danilos> jtv, I didn't so far
[08:43] <danilos> jtv, this used to be broken in the past but I believe we fixed it
[08:43] <danilos> jtv, perhaps we only did so for translator-credits messages, and not for KDE messages
[08:44] <jtv> I thought that difference was well-isolated though.
[08:44] <jml> poolie: rtfd.org
[08:44] <poolie> got it thanks
[08:45] <jtv> danilos: I wonder if the sharing has anything to do with it.  It sounds like somebody changed the message's sharing status.
[08:48] <danilos> jtv, well, it seems the "Shared" message is shown even if the message is read-only (there's a read-only icon), so there are a few problems there
[08:48] <danilos> jtv, without looking at the code, I can't really say much else :)
[08:50] <jtv> It'd be nice if we could get a maintenance squad on it soon, but I couldn't bring myself to mark it Critical.
[08:50] <wgrant> I just closed like 9 criticals, so nobody will notice if you bump it :)
[08:51] <jtv> That's quite a pace… the counter in the topic says 237; is that open ones or closed ones?
[08:52] <wgrant> I opted not to update the topic again today; it was back up to 239 before the deploy, but should be down to 230 now.
[08:52] <wgrant> We'll see soon.
[08:52] <wgrant> 231, sorry.
[08:52] <wgrant> Since I just filed a new one.
[08:54] <jtv> Still, probably best to resist the temptation to generate Criticals at a higher rate.  :)
[08:54] <wgrant> :(
[08:57] <lifeless> StevenK: whats the reason for waiting ?
[08:59] <StevenK> lifeless: That we can't revert to a pre-celebrity branch if we need to
[09:11] <lifeless> well, could always recreate the team pretty quickly
[09:11] <lifeless> but sure
[09:11] <lifeless> happy to wait
[09:23] <jtv> StevenK, wgrant: on mawson, I am now planning to (1) put ubuntu-contents back into /srv/launchpad.net, and (2) run generate-contents-files to see that it moves the directory back to where it is now.  Any objections?
[09:28] <lifeless> is IDS in use yet ?
[09:28] <jtv> Informix Dynamic Server?
[09:29] <lifeless> initialise distro series
[09:30] <jtv> It should be somewhere around the phase where it becomes accessible to colin only.
[09:31] <jtv> (AIUI this is all behind the feature flag for the derived distros UI, which is not being enabled for the general public yet)
[09:32] <nigelb> wgrant: 233/256, what is 256?
[09:32] <nigelb> In progress or fix released?
[09:33] <lifeless> countdown
[09:33] <nigelb> countdown?
[09:33] <lifeless> to 0
[09:34] <nigelb> did the countdown reset from a particular date?
[09:35] <nigelb> Essentially, why has the numerator changed while the denominator doesn't seem to change
[09:35] <lifeless> its not a fraction
[09:36] <StevenK> lifeless: Yes, IDS is in use
[09:36] <lifeless> its a scalar and a meter
[09:37] <nigelb> argh, right.
[09:37] <nigelb> Sorry.
[09:37] <StevenK> lifeless: Currently, it's only used for Ubuntu moving to the next release.
[09:38] <wgrant> jtv: Sorry, was eating. Sounds good.
[09:38] <jtv> I figured if nobody's responding, nobody's doing anything vital.  :)
[09:39] <jtv> It's currently running.
[09:40] <wgrant> Heh
[09:40] <wgrant> /srv/launchpad.net/ubuntu-contents is gone, which can only be a good sign.
[09:44]  * danilos tries to get expanders landed again...
[09:46] <lifeless> danilos: the landing isn't the hard bit :)
[09:46] <danilos> lifeless, well, sometimes it is
[09:46] <lifeless> danilos: sure, I mean in this case
[09:47] <StevenK> The landing is easy. Having it *stay* landed is hard :-)
[09:47] <danilos> lifeless, well, the fix would have been landed sometime on Friday if there was not a test testing for the presence of the img tag
[09:47] <danilos> lifeless, and no reversion would have had to happen :)
[09:47] <lifeless> ah true
[09:48] <danilos> of course, running lp.soyuz tests wasn't enough, so it was 5h of testing, and me being away from any computers over the weekend that made it impossible to go through :)
[09:48] <danilos> anyway, this code has gone through ec2/buildbot so many times that it has been well tested by now :)
[10:05] <cjwatson> lifeless: do your comments on https://code.launchpad.net/~cjwatson/launchpad/multiarch-translations-schema/+merge/67992 amount to an approval?
[10:07] <lifeless> preferable for stub to do so
[10:07] <lifeless> if he was on leave, they would.
[10:07] <cjwatson> ah
[10:08] <cjwatson> he did approve the version in https://code.launchpad.net/~cjwatson/launchpad/multiarch-translations/+merge/67640 (admittedly before I renamed the column)
[10:08] <cjwatson> but then I split out that change into a separate branch for the new schema changes process
[10:12] <danilos> huwshimi, Hi, do you perhaps have a minute to discuss CSS sprites issue (bug 812044)?
[10:12] <_mup_> Bug #812044: Expanded suggestions on +filebug leak branch icon <regression> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/812044 >
[10:14] <cjwatson> jtv-eat: if that Colin means me, I hope it'll actually be ~ubuntu-release rather than me personally
[10:14] <cjwatson> otherwise opening p-series will be blocked on me, rather than in practice normally being done by me :-)
[10:26] <huwshimi> danilos: Hey, sure
[10:56] <danilos> huwshimi, if you've got any ideas, please add them to the bug
[11:08] <huwshimi> danilos: Where can I see this bug in action?
[11:08] <huwshimi> danilos: Is it in someone's branch?
[11:09] <danilos> huwshimi, local LP instance (fresh devel), go to bugs.launchpad.dev/firefox/+filebug search for "a"
[11:11] <huwshimi> danilos: Thanks
[11:19] <jtv> cjwatson: don't worry too much — the "we'll let Colin see it" situation was always meant as temporary, for testing.
[11:23] <cjwatson> ok
[11:26] <LPCIBot> Project devel build #895: FAILURE in 5 hr 57 min: https://lpci.wedontsleep.org/job/devel/895/
[11:31] <jtv> Can anyone help me figure out my bzr config for lp-production-configs?
[11:32] <jtv> I'm getting this error from PQM: "Exception processing merge: unknown url type 'bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable'"
[11:32] <jtv> No idea where either the "launchpad" (as opposed to lp-production-configs) and the "stable" come from.
[11:34] <jml> jtv: use one of the debugging options on pqm-submit to figure out what email it's sending. (dry-run or verbose or something)
[11:34] <jtv> thanks
[11:34] <jtv> yup, it's --dry-run
[11:35] <jtv> star-merge bzr+ssh://bazaar.launchpad.net/~jtv/lp-production-configs/config-810986 bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/lp-production-configs/trunk
[11:35] <jtv> That's what PQM produces.
[11:52] <bigjools> jtv: --submit-branch FTW
[11:53] <jtv> bigjools: but then why doesn't the submit_branch setting in my locations.conf do the same?
[12:00] <bigjools> jtv: is the branch in the location you think it is?
[12:01] <jtv> I was wondering whether that mattered, given the incorrect path in the error message.
[12:01] <jtv> I'm trying though.
[12:01] <jtv> "bzr info bzr+ssh://.../config-810986"
[12:01] <jtv> Yup, that works.
[12:02] <jtv> Now trunk: that works as well (apart from some garbage output from bzr)
[12:15] <jtv> Ahh, worked this time.
[13:30] <adeuring> deryck: henninge: microphonde does not today... let try...
[13:32] <deryck> abentley, ping for standup
[13:33] <adeuring> can't even open the audio assistent...
[13:33] <adeuring> no luck...
[13:34] <deryck> adeuring, we're moving to skype, so I'll call you there for the standup/.
[13:34] <adeuring> deryck: ok, just two minutes to strat another machine where skype is installed
[13:35] <deryck> adeuring, ah, ok.  np.
[13:38] <deryck> adeuring, we'll start and dial you in if we can.
[13:38] <adeuring> deryck: I'm online on sykpe
[13:39] <deryck> adeuring, you seem to drop immediately when abentley invites.
[13:39] <abentley> adeuring: Skype says you're not online and it doesn't work when I invite you, either.
[13:39] <adeuring> let me restart skype...
[13:39] <adeuring> done
[13:40] <deryck> adeuring, not working, sorry.
[13:40] <abentley> adeuring: still not working.
[13:40] <deryck> adeuring, we'll come back to you on IRC.
[13:40] <adeuring> ok
[14:03] <allenap> benji: Up for a short JavaScript review? https://code.launchpad.net/~allenap/launchpad/localpackagediffs-filter-by-package-set-bug-809786-refactor/+merge/68233
[14:04] <benji> allenap: sure
[14:04] <allenap> Thanks.
[14:17] <benji> allenap: approved
[14:17] <allenap> benji: Thanks :)
[14:18] <benji> allenap: Invoking Y.use in a loop isn't something I've seen before.  (Not that it's bad, it just surprised me.)
[14:18] <allenap> benji: I hope it works ;)
[14:29] <abentley> henninge: I've merged from stable, but lp:~abentley/launchpad/json-serialization still has failures: http://pastebin.ubuntu.com/646546/
[14:30] <henninge> hm
[14:31] <henninge> let me look a little closer
[14:53] <danilos> henninge, benji: anyone wants to pick up https://code.launchpad.net/~danilo/launchpad/bug-812044/+merge/68263 (60 lines of diff)
[14:54] <henninge> danilos: I am not, sorry. ;)
[14:54] <henninge> abentley: look at this anonymously: https://answers.qastaging.launchpad.net/
[14:54] <danilos> henninge, you bastard! :)
[14:55] <danilos> benji, hi, a very short branch up for review if you can find the time to look at it
[14:55] <henninge> danilos, benji: nm me, I'll take it
[14:56] <benji> k
[14:56] <abentley> henninge: look at the mouseover text of why no "joe@example.com in question"
[14:57] <henninge> abentley: I know ...
[14:57] <henninge> abentley: I wonder why your test passes (or were you fixing that?)
[14:57] <abentley> henninge: What test do you mean?
[14:58] <henninge> abentley: the one from your paste
[14:58] <abentley> henninge: That test fails.
[14:58] <abentley> henninge: for me, anyhow.
[14:58] <abentley> henninge: You mean why does it pass on trunk?
[14:58] <henninge> abentley: oh, sorry, but other tests pass that should fail
[14:59] <abentley> henninge: I have ignored email obfuscation because I knew you were working on that.
[14:59] <henninge> in question-obfuscation.txt
[15:00] <henninge> danilos: why did you not fix the jslint warnings?
[15:01] <danilos> henninge, it's very old code, I just didn't bother, I can though
[15:01] <danilos> henninge, I also wanted to avoid having to QA the file bug form extensively as well
[15:01] <henninge> I think you should, unless it somehow relies on =='s casting behavior
[15:04] <danilos> henninge, sure, I can do it
[15:05] <henninge> danilos: thanks, otherwise it looks fine to me. r=me
[15:05] <danilos> henninge, cool, thanks
[15:21] <henninge> abentley: the test passes in devel. What is different in your branch?
[15:22]  * henninge pulls stable
[15:23] <abentley> henninge: In my branch, the anonymous user can see all cache objects, and the jsoncache rendering is done in LaunchpadView.getCacheJSON
[15:26] <abentley> henninge: my bad, the anonymous user is still restricted to just the context: https://pastebin.canonical.com/49879/
[15:31] <nigelb> mrevell: hi, you around?
[15:34] <henninge> abentley: I am glad that's figured out
[15:35] <mrevell> nigelb, I'm on the phone at the moment
[15:35] <abentley> henninge: nothing is figured out.  I still don't know why the email address is not being obfuscated.
[15:35] <henninge> abentley: oh
[15:35] <henninge> misread you
[15:36] <abentley> henninge: where did you do the obfuscation?
[15:37] <henninge> abentley: in the marshaller
[15:37] <henninge> abentley: maybe your code does not go through that?
[15:38] <abentley> henninge: Does the marshaller not provide ResourceJSONEncoder?
[15:38] <henninge> abentley: don't think so (I never heard of it)
[15:39] <henninge> abentley: the marshaller is for a specific field type
[15:39] <abentley> henninge: The ResourceJSonEncoder is provided by lazr.restful.tales.
[15:49] <abentley> henninge: Okay, so where is the marshaller and how is it used?
[16:01] <henninge> abentley: lib/lp/app/webservice/marshallers.py
[16:01] <henninge> abentley: zcml/override-includes/ws-marshaller-configure.zcml
[16:02] <henninge> abentley: I am sorry, I gotta run now.
[16:02] <abentley> henninge: okay.
[16:04] <henninge> abentley: the lazr-restful code does the apdapter lookup
[16:05] <henninge> abentley: adeuring should know all about that, too
[17:02] <LPCIBot> Yippie, build fixed!
[17:02] <LPCIBot> Project devel build #896: FIXED in 5 hr 35 min: https://lpci.wedontsleep.org/job/devel/896/
[17:46] <jcsackett> sinzui: time to chat?
[17:50] <jcsackett> benji: any time for a review? https://code.launchpad.net/~jcsackett/launchpad/form-macros-frighten-me/+merge/68277
[17:50] <benji> jcsackett: sure thing
[17:50] <jcsackett> thanks!
[17:54] <benji> jcsackett: I take it that there's some sort of quoting issue that neccesitated using \x22 for the double-quote character on line 42 of the diff.
[17:55] <jcsackett> benji: i believe so. almost all that code is as it was written before, just moved out of the template and into a js file.
[17:55] <benji> we'll let sleeping escape sequences lie
[17:59] <benji> jcsackett: add done
[17:59] <jcsackett> thanks, benji.
[18:00] <benji> my pleasure
[18:10] <sinzui> jcsackett, sorry, I did not see you message. I can chat now if you like
[18:10] <jcsackett> sinzui: sure. be on mumble in a moment.
[18:16] <abentley> gary_poster: For anonymous access to the web site, is request.principal None or does it provide IUnauthenicatedPrincipal?
[18:27] <gary_poster> abentley, should provide
[18:27] <gary_poster> abentley, sorry just saw this :-/
[18:28] <abentley> gary_poster: np.
[18:33] <abentley> gary_poster: in doctests such as lib/lp/answers/stories/question-obfuscation.txt, it appears request.user may be None.  Is that a bug?
[18:34] <gary_poster> abentley, I've seen that stuff in out doctests before.  I believe it is a bug in our test infrastructure, yes.
[18:34] <gary_poster> abentley, that, or the test is representing an incomplete state.
[18:35] <gary_poster> that's doubtful to be intentional though
[18:36] <abentley> Should (view.user is None) ==  IUnauthenticatedPrincipal.providedBy(request.principal) ?
[18:37] <gary_poster> mm...
[18:38] <gary_poster> abentley, Zope itself does not have a contract for the view other than __call__.  It has a convention of 'request' and 'context' but they are not required from the perspective of the publishing or security machinery.  I'm not sure what in Launchpad sets up view.user; I expect LaunchpadView.  I'll look there for a moment
[18:39] <gary_poster> abentley, user in LaunchpadView is getUtility(ILaunchBag).user
[18:40] <gary_poster> I'll look there now
[18:41] <gary_poster> abentley, there are multiple implementations of the ILaunchBag, including at least three test stubs, one of them apparently intended to be general purpose (lib/canonical/launchpad/tests/test_helpers.py)
[18:42] <gary_poster> abentley, that one defaults to user=None
[18:43] <gary_poster> abentley, so that is at least one case in which tests would have a user of None.  I'll look at the "real" implementation now...
[18:44] <gary_poster> abentley, yes, it looks like the launchbag's user can be None, it the principal cannot be adapted to IPerson
[18:44] <gary_poster> and I expect we do not have an IPerson implementation for anonymous
[18:44] <gary_poster> abentley, I'm stopping looking now. :-)
[18:44] <abentley> gary_poster: I'm actually experiencing the case where request.user is None, so it doesn't provide IUnauthenicatedUser, which is causing it to be treated as an authenticated user.
[18:45] <abentley> gary_poster: thanks for having a dive into it.
[18:46] <gary_poster> abentley np.  As I said, I suspect that's a test infrastructure unpleasantness.  I'm pretty sure I could find the Zope code that stuffs an unauthenticated principal on the request if you said that would be helpful.
[18:48] <abentley> gary_poster: I'm not sure what the right way to proceed is.  Is IUnauthenticatedPrincipal.providedBy(request.principal) the best way to detect whether the user is authenticated?  I guess I could ask the LaunchBag instead...
[18:49] <gary_poster> abentley, within the context of Launchpad, and Launchpad tests, the LaunchBag would be the path of least resistance, I think, given what you've seen.
[18:49] <gary_poster> and not a horrible one--plenty or precedent
[18:49] <gary_poster> of
[18:53] <abentley> gary_poster: Okay, thanks very much.
[18:53] <gary_poster> np
[18:58] <sinzui> flacoste, ping
[19:15] <lifeless> good morning :)
[19:19] <jkakar> Hiya lifeless. :)
[19:20] <lifeless> hi jkakar
[19:26] <flacoste> hi sinzui
[19:26] <sinzui> flacoste, do you have a few minutes to mumble about bug linking/dependencies?
[19:31] <flacoste> sinzui: i'm on the phone already, will be a long one, i'll ping you afterward
[19:31] <sinzui> thank you
[20:27] <lifeless> sinzui: is that the call you wanted me on ?
[20:29] <sinzui> lifeless, no. I think I know you you and OEM think my team is doing dependencies. There are TWO bug linking features planned in the next 3 months. It is very confusing and they obviously overlap
[20:29] <lifeless> win
[20:37] <wgrant> I guess I should revert that sendbranchmail thing.
[20:39] <wgrant> conflicts :(
[20:49] <wgrant> allenap: I guess we should not deploy anything between r13460 and r13464?
[20:54] <flacoste> lifeless: skype?
[20:55] <lifeless> ringing you
[20:55] <lifeless> (yes)
[20:55] <flacoste> lifeless: yeah, skype crashed
[20:55] <lifeless> \o/
[20:56] <flacoste> lifeless: can you try again?
[21:22] <flacoste> sinzui: can i skype you in with lifeless?
[21:22] <lifeless> sinzui: is your skype working ?
[21:23]  * sinzui thinks so
[21:56] <mwhudson> wgrant: have you spent the week i've been on leaving reverting the same branch over and over again?
[22:03] <wgrant> mwhudson: No, several different ones :(
[22:04] <wgrant> I've never reverted any one more than three times, though.
[22:04] <mwhudson> there's a first time for everything i guess
[22:04] <wgrant> And they only sometimes get ontoproduction and break it in a different way each time :)
[22:05] <mwhudson> i guess that's a bit less terrible than breaking production the same way each time
[22:05] <wgrant> They do that sometimes too.
[22:24] <LPCIBot> Project db-devel build #730: FAILURE in 5 hr 37 min: https://lpci.wedontsleep.org/job/db-devel/730/
[22:40] <LPCIBot> Project devel build #897: FAILURE in 5 hr 37 min: https://lpci.wedontsleep.org/job/devel/897/
[23:01] <sinzui> StevenK, mumble?
[23:13] <poolie> hullo sinzui
[23:13] <sinzui> ahoy oy poolie
[23:15] <poolie> wgrant: hi, following on from yesterday's question
[23:15] <poolie> do you think it would be feasible to change lp so that it always exposes debian publications before it does the derived ubuntu packages?
[23:16] <wgrant> poolie: No.
[23:16] <wgrant> It's impossible to determine.
[23:17] <wgrant> And any approximation would just delay and anger people.
[23:18] <poolie> ... because it will mostly end up delaying the ubuntu package record, and that's often not needed and annoying?
[23:18] <wgrant> Yes.
[23:18] <wgrant> I'm not sure anybody would consider making Launchpad slower to be a feature.
[23:18] <poolie> :)
[23:19] <poolie> if we want to take the course of delaying the ubuntu package, we could do that only in udd where it's needed
[23:19] <wgrant> poolie: We should do two things:
[23:19] <wgrant>  - Get the Debian import to be more up to date.
[23:19] <wgrant>  - Fix UDD.
[23:20] <poolie> so, more up to date means running it more often?
[23:20] <wgrant> Or perhaps merely at more appropriate times.
[23:20] <wgrant> But more often is always good.
[23:20] <wgrant> No reason not to.
[23:20] <poolie> it's not outrageously expensive or slow?
[23:20] <wgrant> debmirror should be trivial if the indices haven't changed, and if they have changed then we want to reimport.
[23:20] <poolie> right
[23:21] <wgrant> And iron doesn't do anything useful.
[23:21] <poolie> do you know how frequent it would be now, or should i ask a losa what's in the cron job
[23:21] <wgrant> I pasted the crontab lines yesterday.
[23:21]  * wgrant finds.
[23:21] <wgrant> 52 2,8,14,20 * * * sh /srv/debian-import.launchpad.net/scripts/mirror-update.sh >> /srv/debian-import.launchpad.net/production-logs/mirror-update.log 2>&1
[23:21] <wgrant> 05 3,9,15,21 * * * LPCONFIG=gina /srv/debian-import.launchpad.net/production/launchpad/scripts/gina.py lenny squeeze sid experimental wheezy >> /srv/debian-import.launchpad.net/production-logs/gina.log 2>&1
[23:22] <poolie> where did you find them?
[23:23] <StevenK> lp-production-crontabs, I daresay
[23:23] <wgrant> Yes.
[23:23] <wgrant> iron-launchpad in lp:lp-production-crontabs
[23:24] <poolie> perhaps eventually it would be good to have something that just runs continuously rather than from cron
[23:24] <poolie> or, continuously with a short pause in between
[23:25] <wgrant> Given what it has to do, that's no better than a */1 cron job.
[23:26] <poolie> i guess so
[23:26] <poolie> because they all have lock files to prevent concurrent runs?
[23:26] <wgrant> No, but they would if we bumped it to */1.
[23:27] <wgrant> The two scripts would run as a single frequent job, with locking, and only executing gina if the mirror changed.
[23:27] <poolie> so if we set it to /1 at the moment they would get into trouble, but if we added a lock file they would cope?
[23:27] <wgrant> Right.
[23:27] <lifeless> poolie: also because folk directly upload sometimes
[23:27] <poolie> ?
[23:28] <wgrant> Occasionally.
[23:28] <lifeless> poolie: ubuntu having a version before debian is a normal, if rare, situation
[23:28] <poolie> right
[23:28] <lifeless> changing how we import debian won't avoid it
[23:32] <poolie> well
[23:32] <poolie> reducing the latency will reduce the number of confusing situations
[23:32] <poolie> it can't totally avoid it
[23:36] <poolie> ok bug 812597
[23:36] <_mup_> Bug #812597: gina imports from debian arrive too slowly <gina> <udd> <Launchpad itself:Triaged> < https://launchpad.net/bugs/812597 >
[23:37] <wgrant> poolie: Are you sure that's the case?
[23:38] <StevenK> poolie: The Debian archive is only published every six hours, whereas Ubuntu is published every hour.
[23:39] <StevenK> *And* we do the possibly of syncing from Debian incoming if we wish.
[23:39] <StevenK> s/do /do have /
[23:51] <wgrant> http://webnumbr.com/launchpad-critical-bugs