[00:28] <spm> staging: make: *** No rule to make target `lib/canonical/launchpad/icing/yui/yui/yui-min.js', needed by `lib/canonical/launchpad/icing/build/launchpad.js'.  Stop. <== new problem?
[00:30] <wgrant> spm: See #launchpad-ops' topic.
[00:31] <wgrant> spm: I fixed it last week, but then the fix was reverted, so I refixed on Saturday, but then buildbot decided to sulk.
[00:31] <lifeless> wgrant: I've filed bug 808557 about the TEMP kludge
[00:31] <_mup_> Bug #808557: no way to control hand-off of temporary list files <Testrepository:Triaged> < https://launchpad.net/bugs/808557 >
[00:31] <spm> wgrant: haha
[00:31] <spm> right. no worries. thanks
[00:34] <lifeless> wgrant: I've landed the --subunit --list fi
[00:34] <lifeless> x
[00:59] <wallyworld_> wgrant: there's revsions needing qa which are broken due to longpoll.js not being included in the build. the Makefile should have been updated when the longpol stuff landed. i've done a fix
[01:00] <wallyworld_> wgrant: can you +1 this and i'll lp-land https://code.launchpad.net/~wallyworld/launchpad/fix-js-build-paths/+merge/67473
[01:00] <poolie> hi all
[01:00] <wallyworld_> hello
[01:17] <wgrant> wallyworld_: '*lib/lp/*/javascript/*'
[01:17] <wgrant> wallyworld_: Why the prefixed *?
[01:17] <wallyworld_> wgrant: typo i think
[01:17] <wallyworld_> it works but needn't be there
[01:18] <wallyworld_> i'll remove it and double check
[01:18] <wgrant> So, how does this fix things?
[01:21] <wallyworld_> wgrant: the * is needed since the expression is in a -path parameter instead of as an argument to find itself
[01:21] <wallyworld_> but it should be */lib not *lib
[01:22] <wgrant> wallyworld_: lib is in the cwd.
[01:22] <wallyworld_> this fixes things by being more permissive in the javascript that is included in the concat into launchpad.js
[01:22] <wgrant> More permissive how?
[01:22] <wgrant> It seems to be more restrictive.
[01:22] <wallyworld_> wgrant: lib is in the cwd but it doesn't work without the */
[01:23] <wallyworld_> i'm guessing due to how -path works compared to passing the search dir as an argument to find
[01:23] <wgrant> wallyworld_: ./lib
[01:23] <poolie> lifeless: i was wondering the other day if 'user notifications' would work well as a split out service too
[01:24] <poolie> it seemed like they might
[01:24] <wallyworld_> wgrant: yes, ./lib works too
[01:24] <lifeless> could do yes
[01:24] <wallyworld_> i'll use that
[01:25] <wgrant> wallyworld_: So, the real change here is that -path doesn't treat / specially, I guess. So the * in the middle matches app/longpoll.
[01:25] <wallyworld_> wgrant: more permissive in that lib/lp/app/longpoll/javascript/* is included whereas before it wasn't
[01:25] <wallyworld_> wgrant: yes
[01:26] <wallyworld_> the * in the middle matches app/longpoll
[01:26] <wallyworld_> and a bucnh of other things, hence the extra exclusions
[01:28] <wgrant> wallyworld_: Does lib/lp/services really need to be excluded?
[01:29] <wallyworld_> wgrant: the js files in there were's being packaged previously so i didn't want to include them and risk breaking something
[01:29] <wallyworld_> weren't
[01:30] <wgrant> k
[01:30] <wgrant> inlinehelp.js is evil anyway.
[01:30] <wallyworld_> we can relax that exclusion later if required
[01:30] <wgrant> So, fix those three wildcards and it looks OK.
[01:30] <wallyworld_> three?
[01:30] <wallyworld_> i fixed the ./lib one
[01:31] <wgrant> There's 2x *lib, and a *lp
[01:32] <wallyworld_> wgrant: sure, although that style matches how the other exclusions have been done. but i'll make them both ./lib/...
[01:33] <wgrant> Excessive wildcards are bad.
[01:33] <wgrant> Excluding */tests/* was sane.
[01:33] <wgrant> Because it should match everywhere.
[01:33] <wgrant> But *lp/services/* is not.
[02:15] <lifeless> this ssh thing is weird
[02:15] <lifeless> only affects testr
[02:15] <lifeless> if I run the command being run by hand: ~/bin/lxc-start-aufs lucid-test-lp $PWD xvfb-run $PWD/bin/test --subunit --list
[02:16] <lifeless> it doesn't trigger
[02:16] <lifeless> s/ssh/sudo
[02:25] <lifeless> ahha
[02:25] <lifeless> reproduced
[02:25] <lifeless> cat /dev/null |  ~/bin/lxc-start-aufs lucid-test-lp $PWD xvfb-run $PWD/bin/test --subunit --list
[02:25] <lifeless> triggers it
[02:28] <lifeless> as does
[02:28] <lifeless> cat /dev/null | ~/bin/lxc-start-aufs lucid-test-lp $PWD true
[02:29] <StevenK> ~/bin/lxc-start-aufs lucid-test-lp $PWD true < /dev/null ?
[02:38] <wgrant> lifeless: I guess we want to merge today, don't we?
[02:38]  * StevenK looks at QA for db-stable
[02:39] <wgrant> lol
[02:39] <wgrant> Well, it's actually not that bad.
[02:39] <lifeless> yes we do
[02:39]  * wgrant does his.
[02:39] <wgrant> Oh, blah, staging is still down.
[02:39] <wgrant> Hack time.
[02:39] <wgrant> LOSA ping.
[02:40] <spm> yo
[02:40] <wgrant> spm: can has staging?
[02:40] <wgrant> In particular, is there a staging restore running right now?
[02:40] <StevenK> r10711 and r10766, ignoring wgrant's revision.
[02:40] <lifeless> can you check the db patch application time for stubs dropping unused column patch
[02:41] <spm> there is one running atm, still doing the nightly
[02:41] <lifeless> wgrant: ^
[02:41] <wgrant> lifeless: We are at 15 minutes in total.
[02:41] <wgrant> I looked this morning.
[02:41] <lifeless> ok, thats excellent
[02:41] <wgrant> No, it's awful.
[02:41] <wgrant> But we'll live.
[02:41] <wgrant> spm: Hm, the nightly is running?
[02:41] <StevenK> Haha
[02:41] <lifeless> its excellent that we're below budget
[02:41] <wgrant> spm: The tree build should have exploded...
[02:42] <spm> is from Jul10th, so not sure what's up there
[02:42] <StevenK> lifeless: Yes, but wgrant thinks the DB patch budget should be in seconds, not minutes.
[02:42] <wgrant> lifeless: http://paste.ubuntu.com/641617/
[02:42] <wgrant> spm: Welcome to staging.
[02:42] <wgrant> spm: So, you should see approximately lots of errors.
[02:42] <spm> heh, yes
[02:42] <wgrant> spm: In the earlier tree build steps.
[02:42] <wgrant> Right?
[02:43] <wgrant> And the the appserver failing to start and stuff.
[02:45] <spm> Creating bzr-version-info.py at revno 10767 <== can't see any errors
[02:45]  * spm checks asuka. we may have version mismatch
[02:45] <wgrant> make: *** No rule to make target `lib/canonical/launchpad/icing/yui/yui/yui-min.js', needed by `lib/canonical/launchpad/icing/build/launchpad.js'.  Stop.
[02:45] <wgrant> Should be lots of that.
[02:45] <spm> 10767
[02:46] <spm> same there. wtf.
[02:46] <wgrant> Yes.
[02:46] <wgrant> But the build should have failed.
[02:46] <lifeless> StevenK: I think that as well
[02:46] <lifeless> StevenK: but massive downtime window - which this is - is the old style layout
[02:46] <spm> wgrant: it doesn't seem to be. which is awesome.
[02:47] <lifeless> StevenK: for the -new- style stuff, 15m would be untenable
[02:47] <wgrant> spm: Hmm, I see errors in the logs. The fix is in devel, but it'll be 6ish hours before it hits staging. We manually applied the patch on Saturday to get the full restore working.
[02:47] <spm> wgrant: no I lie. there's one.
[02:47] <StevenK> lifeless: Are we using the downtime window to rip out wildcherry so we can fiddle with its disks?
[02:47] <lifeless> StevenK: yes
[02:48] <lifeless> we have 90 minutes to cutover, restart servers with new config and apply the patches
[02:48] <StevenK> Right, I think stub's revision is qa-ok
[02:48] <wgrant> spm: So, since we need to QA today, please kill the current restore, s@`pwd`@../../../..@ in sourcherry:/srv/code/db-stable/launchpad/buildout.cfg, and then staging_restore.sh quick.
[02:49] <StevenK> Which only leaves us r10711. Which we need staging for.
[02:54] <spm> wgrant: nasty code hack applied; rockin'. but this is r10767 fwiw.
[02:55] <wgrant> spm: That's what I expected, thanks.
[02:55] <wgrant> spm: How up to date is lp:lp-staging-scripts' copy of staging_restore.sh? I suspect that sourcherry has a cowboyed change to CHECK_NEW_CODE
[02:57] <lifeless> wgrant: i suspect its nscd / upstart or similar cross over
[02:57] <wgrant> lifeless: :(
[02:57] <lifeless> wgrant: ssh has been excluded
[02:57] <lifeless> can't reproduce if I comment out the container startup
[03:05] <wgrant> spm: (afaict the CHECK_NEW_CODE path has not been used since early May, so maybe it was changed around then)
[03:11] <spm> wgrant: they're identical afaict
[03:11] <spm> both r40
[03:11] <spm> no cowboys on sourcherry
[03:11] <wgrant> spm: Have you diffed them? :)
[03:11] <wgrant> :(
[03:11] <spm> bzr di/st yeah
[03:12] <wgrant> Then why is neither branch under CHECK_NEW_CODE ever executed...
[03:12] <spm> logic bug maybe
[03:12] <wgrant> (you'll see it logs one of two messages... neither of which have appeared since May)
[03:15] <wgrant> spm: Any chance you could investigate? At present it never doesn't update, which makes updates rather slow.
[03:15] <wgrant> Because the nightly jobs run every time.
[03:15] <wgrant> Even if there are no changes.
[03:15] <spm> hrm
[03:15] <wgrant> Which then blocks the world for 7 hours.
[03:15] <spm> indeed
[03:16] <wgrant> Meanwhile a new rev landed in db-stable an hour into that run.
[03:16] <wgrant> But is ignored for 7 hours because staging is just that sort of guy.
[03:16] <spm> yeah, we know about that nice buglet in our update steps. justhaven't got around to fixing that
[03:17] <wgrant> Which?
[03:18] <wgrant> This all worked fine until two months ago :(
[03:22] <poolie> any opinion on what content-type a tarball download should have?
[03:22] <poolie> the current mp has just app/binary
[03:22] <poolie> perhaps making it actually tarball is better
[03:23] <StevenK> application/x-tar?
[03:23] <poolie> yeah, i think so
[03:23] <poolie> istr specifying the compression is a little tricky if we don't want the browser to try to decompress it
[03:23] <poolie> (and we don't)
[03:24] <lifeless> theres three: content type, content encoding, transfer encoding
[03:24] <lifeless> ce and te are about encoding-for-transfer
[03:25] <lifeless> c-t in your case should bzr application/x-tar-gz IIRC, and ce should be identity
[03:25] <lifeless> (which is the default)
[03:26] <lifeless> what some webservers do is ct: application/x-tar and ce: gz, which leads so the bad behaviour you want to avoid
[03:26] <poolie> yep
[03:26] <poolie> http://code.google.com/p/chromium/issues/detail?id=83292
[03:26] <poolie> ew
[03:27] <poolie> app/x-tgz perhaps
[03:28] <wgrant> lifeless: I really hope no webserver is that stupid.
[03:28] <poolie> it's a common problem
[03:28] <poolie> thus the specific workaround for it in chromium
[03:28] <poolie> and probably other places
[03:28] <poolie> it's easy to misconfigure server configuration to say *.gz => ce:gz
[03:28] <lifeless> wgrant: IIRC apache had it as defaults or something
[03:29] <wgrant> lifeless: WTF
[03:29] <lifeless> wgrant: anyhow, it was -really- widespread in the early naughties
[03:29] <poolie> i think some would say app/binary is safest
[03:29] <poolie> yes
[03:29] <wgrant> poolie: You mean application/octet-stream?
[03:29] <wgrant> That's what I would use.
[03:29] <poolie> yes
[03:29] <poolie> that's what i meant
[03:31] <lifeless> poolie: I suspect x-tar-gz is easier to do programmatically along with x-tar-zip x-tar-lzma etc
[03:31] <lifeless> I don't think application/octect-stream is any safer
[03:32] <wgrant> Anything that's likely to tell the browser to keep its dirty fingers out of the file contents is a good thing...
[03:33] <wgrant> http://webnumbr.com/launchpad-critical-bugs is depressing.
[03:35] <lifeless> stub has landed my work on batchnav
[03:35] <lifeless> which is awesome
[03:35] <wgrant> Has he?
[03:35] <lifeless> we can close some of the silly api things down now
[03:35] <lifeless> yeah
[03:36] <lifeless> rev 13392
[03:56] <lifeless> wgrant: so /tmp doesn't have sudo tickets anyway
[03:57] <lifeless> wgrant: how was that meant to be related ?
[03:57] <wgrant> lifeless: No idea.
[03:57] <wgrant> lifeless: Maybe it was upstart putting stuff there.
[03:57] <lifeless> I suspect its grab-sudo-source time
[03:58] <wgrant> But whatever it was, it was somewhat hiding/invalidating/obscuring/destroying/concealing any valid tickets.
[03:58] <lifeless> madly
[03:58] <wgrant> And not mounting /tmp fixed it.
[03:58] <lifeless> if I run the lxc-start by hand nothing breaks
[03:58] <wgrant> :D
[03:59] <lifeless> but if I comment that + the ip grep & ssh out its fine
[03:59] <lifeless> if I comment the ssh and ip out on their own it still breaks
[03:59] <lifeless> and it only breaks when I cat /dev/null | lxc-start-arufs
[04:03] <poolie_> ** Branch linked: lp:~stevenk/launchpad/kill-bazaar-experts
[04:03] <poolie_> 8-O
[04:03] <StevenK> poolie_: You don't like the branch name, or you're surprised I've done it?
[04:03] <poolie_> i'm glad you did it
[04:03] <poolie_> i'm scared by the branch name ;-)
[04:03] <StevenK> Haha
[04:04] <poolie_> i think we'll have tarball downloads from bzr soon
[04:05] <poolie_> perhaps ready to be proposed to merge today
[04:05] <poolie_> lifeless, do you have any performance type concerns about this?
[04:05] <poolie_> i wonder if it would be worth marking these things as very cacheable
[04:05] <poolie_> ... probably it should just land first
[04:14] <lifeless> poolie: I think I've raised them all already
[04:14] <lifeless>  - we may need additional capacity
[04:14] <lifeless>  - robots.txt coverage
[04:15] <lifeless>  - needs to stream to avoid both buffering, high memory use and haproxy killing active requests
[04:16] <lifeless> poolie: you may have missed some discussion about bzr snapshots though
[04:16] <poolie> this does stream
[04:16] <lifeless> poolie: I'm somewhere betwen moderately and highly uncomfortable running non released bzr's these days
[04:16] <poolie> good point about robots
[04:16] <poolie> when/where was the discussion?
[04:17] <lifeless> capacity isn't a reason not to land this, its just a consideration on the ops side
[04:17] <lifeless> poolie: here, on friday I think
[04:17] <poolie> istr you once telling me that every mainline commit is a release
[04:17] <poolie> or more than once :)
[04:17] <lifeless> poolie: that was before the policy change on deprecations
[04:18] <poolie> hm
[04:18] <poolie> that's true chronologically
[04:18] <lifeless> (and associated expectations)
[04:18] <poolie> anyhow
[04:19] <poolie> i believed that the policy was lp would run the betas
[04:19] <poolie> does that count as released or not?
[04:20] <lifeless> I don't know : perhaps its best if I lay out my concerns
[04:20] <poolie> i don't think our current policy is any more likely to break lp than the old one
[04:20] <poolie> and i think non rigorous data from landing failures supports this
[04:20] <poolie> but, it's a separate matter
[04:20] <poolie> go ahead
[04:20] <lifeless> there are, I think, two facets
[04:20] <lifeless> one is resourcing
[04:21] <lifeless> the other is likelyhood of a failure reaching production
[04:21] <lifeless> on the resourcing side, monthly updates where there are API breaks changes the cost/benefit equation
[04:22] <lifeless> this is more a flacoste thing to assess
[04:22] <lifeless> *if* the bzr team drive landing of betas, I don't have a concern here
[04:23] <poolie> hm
[04:23] <poolie> well, let's work out what has the best cost benefit, rather than who pays the cost
[04:23] <lifeless> the other facet is more difficult to reason about, I think, because failures can be so varied
[04:24] <lifeless> I'm mainly concerned about things like the change to fetch tags (which IIUC isn't in a released bzr yet)
[04:24] <lifeless> but which broke - and is still broken - svn imports
[04:24] <poolie> do you want to go to voice?
[04:24] <lifeless> things which I (perhaps wrongly) expect the beta process to tease out
[04:24] <lifeless> sure
[04:24] <lifeless> let me change rooms
[06:39] <StevenK> 215 !? :-(
[06:39] <StevenK>  /wrists
[07:21] <spiv> danilos: you'll be happy to know I've merged your current expander-anim into my bmp-inline-diffs and resolved conflicts without much trouble
[07:24] <nigelb> StevenK: I share the same sentiment :)
[07:25] <nigelb> stub: Thanks to the world being a small world, I recently had a chat with someone at Mozilla who went to college with you :)
[07:26] <stub> Weird. I've lost contact with nearly everybody I went to uni with :-)
[07:27] <nigelb> heh, being the Ubuntu person on that network, we just compared notes on how many people we knew in common
[07:27] <stub> Oh... I think I know who. Still vaguely in contact with her.
[07:29] <nigelb> :)
[07:40] <jtv> Hi henninge!
[07:41] <henninge> Hey jtv! ;)
[07:41] <jtv> henninge: if you're reviewing today then I have a job for you right off the bat.  :)  https://code.launchpad.net/~jtv/launchpad/bug-806946/+merge/67302
[07:42] <henninge> jtv: wow, how thoughtful of you ... ;-)
[07:42] <jtv> Well, you know me.  :)
[07:43] <henninge> jtv: I have just returned to my desk for the first time since Dublin, so I am not all ready yet but I will look at your branch as soon as I am.
[07:43] <jtv> henninge: oh, I forget that you've been away!
[07:43] <jtv> So never mind, I'll bother someone else.
[07:43] <jtv> Such as stub.
[07:46]  * stub is looking
[07:57] <adeuring> good morning
[08:00] <jtv> hi adeuring!
[08:00] <adeuring> hi jtv!
[08:09] <jtv> hi mrevell
[08:09] <mrevell> Hello friends
[08:10] <jtv> Anyone else getting mailman build failures?
[08:17] <bigjools> morning all
[08:19] <wgrant> Morning bigjools.
[08:19] <bigjools> halp.  email.  halp.
[08:19] <wgrant> :(
[08:20] <jtv> morning bigjools — drowning in email?
[08:20] <jtv> thanks stub
[08:20] <bigjools> jtv: not waving, so I must be
[08:21] <jtv> Look at the bright side.  Your mortgage will be 3 inches longer and you'll have a nice acai-berry rolex.
[08:23] <jtv> And no, unity 2d, "mumble" does not mean "remember that file utils.c?  I'd like to open it in gedit."
[08:53] <jtv> thanks henninge — that was very quick!
[09:14] <gmb> lifeless: Did you get chance to take another look at https://code.launchpad.net/~gmb/launchpad/private-branches-bug-657004/+merge/65639?
[09:29] <lifeless> gmb: I hadn't, no.
[09:32] <gmb> lifeless: I think I've dealt with your concerns; I'll get a review from our fine, upstanding OCR and we'll bounce it back to you if we've any further worries.
[09:32] <gmb> How's that sound?
[09:39] <wgrant> Fail.
[09:39] <wgrant> qa-bad ftw
[09:39] <StevenK> wgrant: Which one?
[09:39] <wgrant> wallyworld's JS build qa-bad fix.
[09:40] <wgrant> It deliberately omits the YUI accordion widget that hideously haunts lib/lp/contrib
[09:40] <wgrant> But it is needed.
[09:41] <lifeless> gmb: I've done an actual review for you
[09:43] <gmb> lifeless: Ah, thankee kindly.
[09:56] <wgrant> rvba: Hi
[09:57] <rvba> wgrant: Hi!
[09:57] <wgrant> rvba: Your longpoll JS produces two "yui: NOT loaded: lang" warnings on load. Is that OK?
[09:58] <rvba> wgrant: mm ... I don't think it's a problem but I'll look into it.
[09:58] <wgrant> rvba: This is blocking a rollback to fix QA for the deployment, so it is critical-critical.
[09:59] <wgrant> It seems OK, though.
[09:59] <rvba> wgrant: yeah, I really think it's OK.
[09:59] <wgrant> I guess lang is probably core?
[10:00] <rvba> I'm not sure ...
[10:01] <wgrant> http://developer.yahoo.com/yui/3/yui/ suggests it is.
[10:01] <wgrant> "
[10:01] <wgrant> All of this functionality is available in the YUI Core:
[10:01] <wgrant> [...] lang
[10:01] <wgrant> "
[10:01] <rvba> Indeed.
[10:01] <wgrant> Hm.
[10:01] <wgrant> But they are listed as modules...
[10:02] <rvba> IIRC It was a separate module in YUI 2
[10:02] <rvba> Perhaps that's the reason why it's not clear ...
[10:03] <rvba> wgrant: How is this blocking you?
[10:03] <wgrant> rvba: The fix to fix the broken longpoll stuff is itself broken, and I don't know if my fix for that fix is good.
[10:04] <wgrant> Because now it's throwing warnings, but otherwise working AFAICT.
[10:04] <wgrant> (bug #808561_
[10:04] <_mup_> Bug #808561: longpoll.js is not included in launchpad.js during make <bad-commit-13401> <qa-bad> <Launchpad itself:Fix Committed by wallyworld> < https://launchpad.net/bugs/808561 >
[10:04] <wgrant> Ah, 13WAAFAXG!
[10:05] <wallyworld> wgrant: saw the qa :-( want me to fix it? i excluded the contrib because i could have sworn the accordian was not in the original lp,js when i check the stdout :-(
[10:05] <wgrant> wallyworld: I have a fix here, but now that longpoll is loading it's throwing warnings about lang not being loaded.
[10:05] <wgrant> I suspect because it's core.
[10:05] <rvba> wgrant: I think you're right.
[10:06] <wgrant> (the only other file differences are two from */testing/*, the omission of which is harmless)
[10:06] <wallyworld> yes, and we don't want those testing files
[10:07] <wgrant> I'll drop lang from the requires.
[10:07] <rvba> wgrant: Yes.
[10:07] <wallyworld> wgrant: from requires in longpoll.js ?
[10:07] <rvba> It will blow up badly if the lang module is not loaded.
[10:07] <wgrant> wallyworld: Yes.
[10:08] <wgrant> http://paste.ubuntu.com/641774/?
[10:08] <wgrant> Just testing now...
[10:09] <rvba> Testing it now too ...
[10:09] <rvba> Does not seem to break the tests ...
[10:09] <rvba> And the warning (I had that turned off :() is gone.
[10:09] <wgrant> And the warnings are gone.
[10:33] <wgrant> Oops.
[10:33] <wgrant> Rolled back with the bug instead of rev.
[10:33] <jml> *blink*
[12:59] <henninge> adeuring: matt asked for some lines about the web service bug we fixed in Dublin.
[12:59] <henninge> adeuring: I saw that you landed it. Thank you very much for that! ;-)
[13:00] <adeuring> henninge: well, it had to be reverted: caused a regression
[13:00] <henninge> adeuring: oh :(
[13:00] <henninge> adeuring: are we fixing that?
[13:00] <henninge> is there  a  bug number?
[13:00] <adeuring> henninge: not yet... for the regression, for example ooops 2013AP64
[13:02] <henninge> adeuring: "not yet" about fixing it or about a bug number?
[13:02] <adeuring> henninge: I haven't done any work yet
[13:04] <henninge> adeuring: the traceback is not very helpful. Any idea what's causing it?
[13:04] <adeuring> henninge: no... wgrant blamed our branch for the oops...
[13:18] <deryck> Morning, all.
[13:18] <abentley> deryck: morning.
[13:20] <jtv> Did we break the makefile?
[13:20] <jtv> When I "make -j2" in a fresh branch, I get
[13:20] <jtv> make: *** No rule to make target `lib/canonical/launchpad/icing/yui/yui/yui.js', needed by `lib/canonical/launchpad/icing/build/launchpad.js'.  Stop.
[13:21] <deryck> jtv, update download-cache maybe?
[13:21] <jtv> I did a rocketfuel-get this morning.
[13:21] <jtv> Repeating the "make" command gets me past the problem.
[13:22] <jtv> So strikes me as a missing dependency in the makefile.
[13:32] <abentley> deryck: I'm having sound difficulties.
[14:45] <cr3> hi folks, I think I understand why bug cannot be assigned to a distroarchseries but I wouldn't mind hearing an explanation :)
[14:45] <cr3> s/bug/bugtask/
[14:55] <abentley> bac: I'd like to touch base about the json cache at some point.
[14:55] <bac> abentley: sounds good
[14:55] <abentley> I guess this is your first day back from vacation.  Any time good for you?
[15:04] <bac> abentley: 2:00 US/East today?
[15:04] <abentley> bac: Sounds good.
[15:52] <bigjools> anyone got any ideas what's up here? http://pastebin.ubuntu.com/641976/
[15:52] <nigelb> What tz is wallyworld?
[15:54] <bigjools> +10
[15:56] <nigelb> ok, this is going to be tricky.
[15:56] <nigelb> I'll have to wake up early to catch him.
[16:22] <cr3> is there something like a source_package in Launchpad but that also refers to the distro arch series, rather than just the distro series like source_package?
[16:45] <cjwatson> Could somebody allocate a database patch number for me for lp:~cjwatson/launchpad/multiarch-translations?  A suitable description might be "DistroSeries.split_long_descriptions"
[16:46]  * cjwatson is reading https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess with some care
[16:52] <bigjools> anyone know if there's a way to determine which version of the API is being used in the method being called?
[16:52] <cjwatson> wgrant: I can't remember if I asked; for backports_not_automatic, how did you go about getting it set to True for oneiric?  I don't see it in the UI or API
[17:08] <wgrant> cjwatson: It was SQL, sadly.
[17:09] <wgrant> cjwatson: You could probably expose this through the API, I guess.
[17:11] <cjwatson> wgrant: it'll only have to be done once, so if people don't mind SQL then that's a smaller code change ...
[17:11] <cjwatson> (I guess that's a question)
[17:11] <wgrant> They do mind SQL.
[17:11] <wgrant> And API exposure is easy.
[17:11] <wgrant> So...
[17:11] <cjwatson> but not for you, clearly :-)
[17:11] <cjwatson> but OK
[17:11] <wgrant> But permissions are a bit awkward.
[17:11] <wgrant> You now have a patch number of 2208-79-0
[17:11] <cjwatson> great, thanks
[17:11] <cjwatson> if you have pointers to stuff I can read for permissions, that'd be good
[17:13] <wgrant> cjwatson: https://dev.launchpad.net/LaunchpadSecurityPolicy is something, but it's not really what you want.
[17:13] <wgrant> cjwatson: lib/canonical/launchpad/security.py defines who has launchpad.Edit/launchpad.View etc. for each interface.
[17:14] <wgrant> And lib/lp/registry/configure.zcml maps from permissions to read/write of attributes.
[17:14] <wgrant> Or to read/write of interfaces, in which case all of the interface's fields are permitted.
[17:29]  * wgrant wanders off.
[17:41] <flacoste> i'm looking for a reviewer for https://code.launchpad.net/~flacoste/launchpad/bug-801233/+merge/67353
[17:41] <flacoste> soyuz-related
[17:41] <flacoste> but probably not critical to have soyuz-fu
[17:42] <flacoste> as it's mainly an api-export one
[17:42] <flacoste> bac you might even be interested in it :-)
[17:42] <flacoste> as it builds on your previous processor export
[17:42] <bac> flacoste: i'll be happy to look at it in a little while.
[17:44] <flacoste> bac, ok thanks
[17:59] <bac> abentley: mumble? skype?
[18:00] <abentley> bac: let's mumble
[18:01] <bac> abentley: trying...
[18:01] <abentley> bac: you don't hear me?
[18:01] <bac> nope
[18:02] <abentley> bac: the lips are turning red, so I think my side's okay.
[18:02] <abentley> bac: yes, I can hear you okay.
[18:03] <abentley> bac: Do you prefer Skype?
[18:03] <bac> abentley: well, it works for me
[18:03] <abentley> bac: Let's do that, then.
[18:04] <bac> abentley: i am brad.crittenden
[18:14] <abentley> bac: bzr+ssh://bazaar.launchpad.net/~abentley/launchpad/json-serialization
[18:14] <abentley> bac: bzr+ssh://bazaar.launchpad.net/~abentley/launchpad/getnewcache
[18:30] <gmb> wgrant: Do you remember how to make the librarian stop serving .tar.gzs as text/html?
[18:32] <gmb> losa ping
[18:33] <mbarnett> heya gmb
[18:34] <gmb> mbarnett: Howdy! For some reason the Librarian is serving http://launchpadlibrarian.net/73387253/testtools-0.9.11.tar.gz as text/html; I know that wgrant mentioned that this was a known bug, but I don't remember if he told me what we need to do stop it. Do you have any ideas?
[18:34] <gmb> (Incidentally, I know it's not normally text/html because it worked fine yesterday)
[18:35] <mbarnett> gmb: not off the top of my head.  Unless getting cached changes how it gets served.  I will have to do some investigation to see what exactly is going on.
[18:35] <gmb> mbarnett: Thanks.
[18:36] <abentley> gmb: I've seen that bug.  Let me see if I can dig it up.
[18:36] <gmb> abentley: Thanks.
[18:36] <abentley> gmb: Is this your bug? https://bugs.launchpad.net/launchpad/+bug/703807
[18:36] <_mup_> Bug #703807: launchpad sometimes serves download files as content-type text/html <regression> <Launchpad itself:Triaged> <pyOpenSSL:New> < https://launchpad.net/bugs/703807 >
[18:37]  * gmb wonders why that didn't come up in his original searches.
[18:37] <gmb> abentley: Thank you. Many eyes make all bugs easy to find...
[18:38] <abentley> gmb: hehe.
[18:38] <cr3> what's the convention in Launchpad when naming attributes? foo_bar or foobar?
[18:38] <gmb> mbarnett: According to that bug ^^ it is a caching problem of some sort: https://bugs.launchpad.net/pyopenssl/+bug/703807/comments/21
[18:38] <_mup_> Bug #703807: launchpad sometimes serves download files as content-type text/html <regression> <Launchpad itself:Triaged> <pyOpenSSL:New> < https://launchpad.net/bugs/703807 >
[18:39] <abentley> cr3: foo_bar
[18:39] <gmb> mbarnett: So I shall now endeavour to remember how the hell to use Curl and report back...
[18:40] <cr3> abentley: thanks!
[18:40] <abentley> np
[18:41] <cr3> abentley: productseries = Choice(... what's the deal with that and lots of other attributes under IBugTask? old convention?
[18:41] <mbarnett> gmb: heh
[18:42] <abentley> cr3: productseries is a bit of a compound word.  And yes, I don't think we've been very strict about it.
[18:44] <gmb> mbarnett, abentley: Cache-control: no-cache fixed it. Weird. I'll add a note to the bug. Also, if anyone sees wgrant around, tell him it happened. If we get him wound up enough he'll either complain until it gets fixed or fix it himself whilst I sleep.
[18:52] <mbarnett> gmb: i'll make a note in my daily report as well, see if the new blood has any ideas off hand.
[18:52] <gmb> Cool.
[18:53]  * gmb -> afk for the evening. Nytol.
[18:58] <bac> flacoste: the docstring for getBuildQueueSizes is confounding the wadl generator
[18:59] <flacoste> bac: really?
[18:59] <bac> flacoste: really!
[18:59]  * flacoste checks
[19:05] <flacoste> bac: how did you get this? make clean && make still works here?
[19:05] <bac> flacoste: make is broken wrt to api generation
[19:05] <flacoste> not for me :-(
[19:06] <bac> flacoste: i mean, it doesn't do anything
[19:06] <bac> flacoste: rm -rf lib/canonical/launchpad/apidoc ; make build
[19:06] <flacoste> ah right
[19:06] <flacoste> ah ok, so how did you get the error?
[19:06] <flacoste> running lp-create-wadl-and-apidoc also works here
[19:06] <bac> by doing the above, and looking at the output.  it won't fall-over fail but does print errors
[19:07] <flacoste> bac: i only get the usual 'Unknown entry url'
[19:08] <flacoste> bac: can you pastebin what you get?
[19:08] <bac> yep
[19:13] <bac> flacoste: http://pastebin.ubuntu.com/642108/
[19:16] <flacoste> bac: thx, i guess i can fix that easily
[19:22] <benji> flacoste: when you get a chance I'd appreciate a look at my 781600 branch: lp:~benji/launchpad/bug-781600
[19:22] <flacoste> benji: ack
[19:43] <bac> flacoste: r=bac
[19:44] <lifeless> moin moin
[20:00] <lifeless> flacoste: hi
[20:00] <flacoste> hi lifeless
[20:00] <flacoste> bac: thanks!
[20:00] <bac> flacoste: np.  did you figure out the docstring weirdness?
[20:02] <flacoste> bac: not yet
[20:17] <gary_poster> wgrant, ping?
[20:19] <sinzui> jcsackett, do you have time to mumble?
[20:19] <gary_poster> lifeless, hi.  Do you happen to know if the code bigjools, wgrant & co did at the thunderdome has a generic LP Rabbit consumer as part of it?
[20:20] <gary_poster> I'm not sure where branch would be
[20:20] <jcsackett> sinzui: 15 min? Don't want to lose the thread of what I'm looking at.
[20:21] <sinzui> jcsackett, okay
[20:21] <lifeless> gary_poster: it doesn't, I'm pretty sure
[20:21] <lifeless> gary_poster: sorry, OTP with flacoste
[20:21] <gary_poster> lifeless, ok np thanks
[20:28] <jcsackett> sinzui: wrapped up a bit faster than i thought. i can mumble now.
[20:35] <sinzui> jcsackett, I will restart
[20:40] <jcsackett> sinzui: i think it may have been me, actually.
[20:41] <sinzui> jcsackett, maybe, but now thunderbird wants 50% if my cpu
[20:54] <wgrant> gary_poster: Hi
[20:54] <gary_poster> flacoste, danilos evaluated escalated bug 775691 and in the last comment said that he thought we ought to lower the priority, and described what needed to happen (migration, essentially, AIUI).  Should I contact David Planella and see if this addresses his concern, or should I regard the migration that danilos described as the escalated task?
[20:54] <_mup_> Bug #775691: Empty translations on one side do not get translated by the other side <escalated> <not-pie-critical> <upstream-translations-sharing> <Launchpad itself:Triaged by yellow> < https://launchpad.net/bugs/775691 >
[20:55] <wgrant> gary_poster: There is a rabbit client in lp.services.messaging.
[20:55] <wgrant> gary_poster: Not sure how suitable it is for you.
[20:55] <gary_poster> hi wgrant.  thanks for ponging.  I was wondering how your long poll work consumed rabbit events on the Launchpad side.  I saw that client and it was only a publishing queue afaict
[20:56] <wgrant> gary_poster: Ah, we don't consume in LP yet.
[20:56] <gary_poster> oh ok
[20:56] <wgrant> gary_poster: That's done by lazr.amqp.
[20:56] <gary_poster> oh?
[20:56] <wgrant> It's an external twisted daemon.
[20:56] <gary_poster> ah!
[20:56] <gary_poster> does it have access to the LP db?
[20:56] <wgrant> Hmm, but the tests should do consuming.
[20:56] <wgrant> Let me see.
[20:56] <wgrant> No!
[20:56] <wgrant> 'tis a microservice.
[20:56] <gary_poster> yeah, that's what I thought
[20:56] <wgrant> gary_poster: RabbitQueue.receive
[20:56] <wgrant> In lp.services.messaging
[20:57] <wgrant> Tests use it.
[20:57] <wgrant> It is not really production-ready.
[20:57] <gary_poster> but I'm not sure how you are able to do what you need without access to the db
[20:57] <wgrant> stub and bigjools couldn't work out how to do timeouts.
[20:57] <wgrant> So they hacked that together.
[20:57] <gary_poster> :-)
[20:57] <gary_poster> k lemme look
[20:57] <wgrant> Improvements welcome!
[20:58] <wgrant> Yay, qastaging works now.
[20:59] <wgrant> And staging is up too.
[20:59] <wgrant> Good news.
[20:59] <gary_poster> wgrant, cool.  ...lazr.amqp does not need db access because the only thing it needs is to convey rabbitmq messages to long poll (browser) clients?
[20:59] <wgrant> gary_poster: Right. It basically bridges Apache and rabbitmq.
[21:00] <gary_poster> gotcha.  ok thanks much wgrant!
[21:00] <wgrant> The browser gives it a queue name to listen for, and it returns any messages that come through it.
[21:00] <gary_poster> gotcha
[21:00] <wgrant> lifeless: Looks like we are green, but I will poke around on qastaging a bit more, given recent happenings.
[21:01] <lifeless> cool!
[21:02]  * gary_poster goes to prepare cooking stuff
[21:02] <gary_poster> night
[21:33] <wgrant> Looks OK to me.
[21:33] <wgrant> lifeless: Any objections to reopening?
[21:41] <lifeless> we're qa-ok ?
[21:41] <lifeless> mm
[21:41] <lifeless> wgrant: lets get the prelude revisions NDT deployed
[21:41] <wgrant> lifeless: We're as far as we can.
[21:41] <lifeless> wgrant: and wait a little for regressions from them
[21:41] <wgrant> 13389 is bad.
[21:42] <wgrant> 13401 fixed it.
[21:42] <wgrant> But was bad.
[21:42] <wgrant> 13402 is the merge.
[21:42] <wgrant> 13403 fixes the bad bad fix.
[21:42] <lifeless> how did 13389 be untestable ?
[21:42] <wgrant> It was landed without a bug.
[21:43] <lifeless> ok
[21:43] <lifeless> just looking
[21:43] <lifeless> trying to assess whether we should expect more cascade qa-fail
[21:43] <wgrant> 13391, 13392 are of some concern to me.
[21:44] <lifeless> I can see that
[21:44] <lifeless> nothing could possibly go wrong with them
[21:45] <lifeless> lets spend some time this morning kicking tires on those on qastaging
[21:45] <wgrant> Yeah
[21:45] <lifeless> has the hwdb api changes been played with ?
[21:45] <wgrant> bac: Hm?
[21:45] <wgrant> lifeless: No.
[21:45] <wgrant> cr3: Around?
[21:45] <lifeless> cr3: ping
[21:45] <lifeless> hah, over to you :)
[21:46] <bac> wgrant: re: the ppa question?  i thought you may be able to answer the user.
[21:46] <wgrant> Probably. But I'm not maintenance any more.
[21:46] <wgrant> But let me see.
[21:46] <bac> wgrant: thx
[21:47] <cr3> lifeless, wgrant: yep, pong, what's up?
[21:47] <wgrant> cr3: Have you tested your change out on qastaging at all?
[21:47] <wgrant> bac: The packages are there AFAICT :/
[21:47] <cr3> wgrant: crap, totally scripped my mind. I'll do it this evening, then I set it to qa-ok, right?
[21:47] <wgrant> cr3: That would be great, thanks.
[21:47] <cr3> skipped my mind even :)
[21:47] <cr3> wgrant: thanks for the reminder!
[21:50] <wgrant> lifeless: What's changed in the new batchnav? Just addition of the memo= arg, with no functional changes for our collectioins yet?
[21:55] <lifeless> wgrant: yeah
[21:55] <lifeless> wgrant: infrastructure and a default adapter that makes things work much as they did before
[21:55] <lifeless> wgrant: urls change slightly
[21:56] <lifeless> wgrant: (consistent ordering of parameters)
[21:56] <lifeless> wgrant: its possible, if someone was manually predicting the urls to use, that things will break
[21:56] <lifeless> but AFAICT nothing did that
[21:57] <wgrant> Well, batchnav does.
[21:57] <wgrant> But it seems to work, AFAICT.
[21:57] <wgrant> s/batchnav/lazr-js/
[22:07] <lifeless> it does?
[22:08] <lifeless> I thought lazr-js read the next_link ?
[22:08] <wgrant> lazr-js pickers provide page number links.
[22:08] <lifeless> yeah
[22:08] <lifeless> the api for that python side generates those batches
[22:08] <lifeless> and queries for their urls
[22:08] <wgrant> Oh, really?
[22:08] <wgrant> Anyway, we own lazr-js now, so we should stop it from doing that.
[22:09] <lifeless> the new batchnav supports start-nonce=XXXX + offset=YYYY
[22:09] <lifeless> so we can do that efficiently without creating the batches
[22:09] <wgrant> Ahh
[22:09] <lifeless> but its not all wired up to do that
[22:09] <wgrant> Still, the numbers are fairly pointless.
[22:10] <lifeless> yes
[22:11] <lifeless> hopefully I'll get a collection converted today
[22:30] <lifeless> sinzui: hi
[22:31] <lifeless> sinzui: just wanted to confirm - is your team picking up the privacy-marker project (changing from ////// borders to the red thing at the top etc) ?
[22:38] <nhandler> 100
[22:39] <sinzui> lifeless, yes
[23:04] <sinzui> wgrant, mumble>
[23:05] <sinzui> StevenK, mumble?
[23:05] <wgrant> sinzui: Sec
[23:40] <StevenK> wgrant: It seems we are deployable?
[23:41] <wgrant> StevenK: Yes, but there are a couple of big changes that lifeless and I would like to do more verification of.
[23:54] <cjwatson> wgrant: https://code.launchpad.net/~cjwatson/launchpad/multiarch-translations/+merge/67640 is ready for review; would you be up for code-reviewing it?
[23:55] <StevenK> Heh, it's even wgrant's turn to be OCR.