[00:02] <wgrant> Hm, we can toss another 10 appservers on chae without much trouble.
[00:03] <lifeless> ???
[00:04] <lifeless> I wouldn't expect that, unless our SQL/total ratio has changed dramatically
[00:08] <wgrant> https://lpstats.canonical.com/graphs/ChaenomelesCPU/
[00:08] <wgrant> It hit 50% once in the last week.
[00:09] <lifeless> if its seeing less load, thats possible an haproxy config bug
[00:25] <jelmer> it's surprising how much people try to "fork" a branch on launchpad by registering a new code import...
[00:27] <wgrant> Yeah :/
[00:27] <wgrant> People don't understand that in a DVCS you can just branch.
[00:27] <wgrant> Because on GitHub you can't :/
[00:33] <jelmer> wgrant: though we do have a button to allow people to create an *empty* branch, which seems just as pointless
[00:33] <wgrant> Rather.
[01:09] <StevenK> wallyworld_: I added an alert() to that function and it didn't pop up a message box?
[01:09] <wallyworld_> StevenK: did you add it just before the named_post?
[01:11] <StevenK> wallyworld_: Just before the if block
[01:11] <StevenK> (That is just before the named post)
[01:13] <wallyworld_> StevenK: did you make jsbuild and refresh the browser?
[01:13] <StevenK> I just ran make
[01:13] <StevenK> And the alert appears in launchpad.js
[01:13] <wallyworld_> make by itself should be ok but make jsbuild is quicker
[01:14] <wallyworld_> what ui element did you hit? the red sprite or the link?
[01:15] <StevenK> wallyworld_: The link in +subscriptions
[01:16] <wallyworld_> StevenK: we may be looking at the wrong file. i know about the subscription portlet.  there's a structural-subscription.js
[01:16] <wallyworld_> which may be used for the page you are looking at
[01:16] <wallyworld_> line 1205?
[01:17] <wallyworld_> StevenK: lp.registry.javascript.structural-subscription.js
[01:17] <StevenK> Yeah, just found that
[01:18] <wallyworld_> that's the only other place i know of in js that unsubscribes someone
[01:18] <StevenK> The do_io does the actual unsub?
[01:18] <StevenK> What a horrible function name
[01:18] <wallyworld_> yes, looks like it
[01:22] <StevenK> No alert either
[01:22] <wallyworld_> hmmm.
[01:22] <wallyworld_> StevenK: i'll run up a system and have a look.can you paste the url you are looking at
[01:23] <StevenK> wallyworld_: It's a local bug
[01:23] <wallyworld_> StevenK: but i can got to a bug and append +subscriptions i think
[01:24] <StevenK> wallyworld_: So what I did was run make-lp-user stevenk; then jumped into a harness and getUtility(IPersonSet).getByName() and then factory.makeBug(private=True, owner=user)
[01:24] <StevenK> If that makes sense
[01:24] <wallyworld_> ok, so you are editing a private bug. there's one of those in the sample data i can look at
[01:25]  * wallyworld_ waits for make to finish
[01:30] <wallyworld_> StevenK: i think it make be lp.bugs.lavascript.subscription.js line 219
[01:31] <wallyworld_> so there's 3 bits of javascript that are used to unsubscribe
[01:31] <StevenK> lavascript sounds good
[01:31] <wallyworld_> hah
[01:35] <wallyworld_> nope, that's not it either
[01:37] <wallyworld_> StevenK: it's the make_action_lin method
[01:37] <wallyworld_> make_action_link
[01:38] <wallyworld_> line 1012
[01:38] <wallyworld_> my breakpoint just got hit :-)
[01:39] <StevenK> And the on click function is internal to make_action_link
[01:39] <StevenK> Sigh
[01:41] <wallyworld_> at least you know where to start hacking now
[01:42] <StevenK> How do I get at the bug in JS?
[01:48] <wallyworld_> StevenK: what do you mean? the link to the bug?
[01:49] <wallyworld_> there's a json cache entry LP.cache.bug
[01:49] <wallyworld_> from there you have LP.cache.bug.self_link or LP.cache.bug.web_link etc
[01:55] <StevenK> Ah.
[01:55] <StevenK> LP.cache.bug is undefined
[01:57] <wgrant> 30 seconds...
[01:58] <StevenK> wgrant: ?
[01:58] <wgrant> Until the OOPS report of doom.
[01:58] <wgrant> Although it seems to be late, unsurprisingly.
[02:00] <StevenK> It's probably choking on 70,000 OOPS
[02:02] <wallyworld_> StevenK: there's LP.cache.context and LP.cache.context.bug_link. you can view page source and scroll to the end to see what's in the cache
[02:06] <wgrant> 40814 DisconnectionError: could not connect to server: Connection refused Is the server running on host "lp-prod-pgbouncer.canonical.com" and accepting TCP/IP connections on port 5433?
[02:06] <wgrant> Yay
[02:07] <wgrant> 29665 AssertionError: Bug #504291: Store left in a disconnected state.
[02:07] <wgrant> Yay
[02:07] <_mup_> Bug #504291: DisconnectionErrors (already disconnected) happening again <lp-foundations> <oops> <Launchpad itself:Fix Released by stub> <Storm:Invalid> < https://launchpad.net/bugs/504291 >
[02:07] <wgrant>  270 DisconnectionError: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request.
[02:07] <wgrant> Yay
[02:07] <wgrant>   83 Fault: <Fault -1: 'Unexpected Zope exception: DisconnectionError: could not connect to server: Connection refused\\n\\tIs the server running on host "lp-prod-pgbouncer.canonical.com" and accepting\\n\\tTCP/IP connections on port 5433?\\n'>
[02:07] <wgrant> Yay
[02:07] <wgrant> And that's all of them.
[02:08] <StevenK> So we get to look forward to 60,000 OOPSes every time we do fastdowntime?
[02:08] <lifeless> we need to teach oops-tools to know there was a deploy
[02:08] <lifeless> and hide them
[02:08] <wgrant> Those assertionerrors shouldn't happen, though.
[02:08] <lifeless> indeed
[02:08] <wgrant> There is a bug somewhere.
[02:09] <wgrant> Everything else looks pretty sensible.
[02:09] <lifeless> indeed
[02:09] <wgrant> So we are good to go for tonight.
[02:09] <StevenK> Tonight? Seriosuly?
[02:09] <StevenK> *Seriously
[02:09] <wgrant> 1830: upgrade germanium and cocoplum
[02:09] <wgrant> 1831: fastdowntime all the patches
[02:12] <StevenK> Because what could possibly go wrong?
[02:26] <StevenK> wallyworld_: LP.cache.context doesn't have what I want, how is that populated?
[02:28] <benji> StevenK: IJSONRequestCache(view.request).objects['my_thing'] = my_thing
[02:29] <wallyworld_> StevenK: there's 2 ways - automatically with the attrs from the page context, plus one can also instantiate an IJSONRequestCache object
[02:29] <StevenK> So I suspect the bug is LP.cache.context, but I can't see private on there
[02:29] <wallyworld_> StevenK: see expose_user_subscriptions_to_js in lp.bugs.browser.structuralsubscription.py
[02:30] <wallyworld_> StevenK: if context were bug, then all the attrs would be there
[02:30] <wallyworld_> so it's probably something else
[02:34] <StevenK> Lots of context in those views :-/
[02:36] <wallyworld_> yep
[02:41] <StevenK> Looks like ... part of a bug
[02:42] <StevenK> It's a task
[02:43] <StevenK> So LP.cache.context.bug_link is the link to the bug
[02:45]  * wgrant stabs Melbourne.
[02:46] <wgrant> It was nice and cloudless and not freezing yesterday, today it is hailing.
[02:46] <wgrant> It was almost getting springish, now back to mid-winter for a while :(
[02:48] <StevenK> It's raining here
[04:29] <StevenK> JS sucks
[05:58] <jtv> wgrant: it's turning out to be another day of long unexpected phone calls, but here's what we discussed earlier.  Wanna review?  https://code.launchpad.net/~jtv/launchpad/transitional-published/+merge/74720
[05:59] <wgrant> jtv: There you go again, making perfectly good classic Soyuz tests *readable*.
[05:59] <jtv> Sorry.
[06:00] <jtv> I could add some dire but incomprehensible XXX comments in the names of people who have long left the company, if you like.
[06:01] <wgrant> Stuff like kiko's "this is very funny" gina XXX is good, too.
[06:02] <jtv> "XXX kibonzi 2004-03-31: ON NO ACCOUNT should this plearfy the.  If get this wrong, ENTIRE ARXHIVE become problem.  DO NOT CHANGE without asking permission from Celve Alexelo."
[06:02] <wgrant> jtv: For dominate.py, do you know of the store.find(SourcePackagePublishingHistory, archive=series.main_archive, distroseries=series, [...]) Storm shorthand?
[06:02] <jtv> Yes, just don't like it much.
[06:02] <wgrant> Indeed, it makes extension of queries difficult.
[06:03] <jtv> I like the wider spacing and avoidance of ambiguity in the "==" notation.
[06:03] <wgrant> I am normally tempted to use the kwarg notation for stuff like SPPH, but you have taken the probably better alternative of aliasing it.
[06:03] <jtv> Also, I like to think of our database as a relational one.  Which involves so much more than just equality comparisons!
[06:03] <wgrant> Otherwise you end up with 5 line conditions.
[06:03] <jtv> Quite.
[06:04] <jtv> I don't like doing the aliasing very much, but I still prefer it over the kwargs shorthand somehow.
[06:04] <wgrant> Indeed.
[06:04] <jtv> Also, this is transitional code.  It will disappear soon, so I'm not too bothered about it anyway.
[06:04] <wgrant> Yup.
[06:05] <jtv> wgrant: extra points if you can spot everything that's wrong with that XXX I gave earlier.
[06:05] <wgrant> I could be cruel and make you fix gina.txt's lint, but perhaps not.
[06:05] <jtv> Grrrrr
[06:05]  * jtv snaps at wgrant
[06:05] <jtv> I know what island you live on.
[06:06] <wgrant> Better still, I'll make you fix it, and then I will petition to have the standard changed to something else, requiring every line to be reindented again.
[06:06] <jtv> You're getting disturbingly good at this.  I may have to call your mommy.
[06:07] <wgrant> Hey, I'm not the one making scarily plausible XXXs.
[06:08] <jtv> Plausible?  2004-03-31?  Nah, we have code reviews to catch mistakes like that.
[06:08] <wgrant> lol
[06:08] <jtv> (Damn, should have written 2004-04-31 obviously)
[06:08] <wgrant> Heh
[06:09] <jtv> *That* is what we need: an automated checker for XXX dates in PQM, which will fail our branches because PQM thinks the date is in the future.
[06:12]  * wgrant returns to necromancy.
[06:12] <wgrant> Sadly, many of these binaries are being rescued from the pool only so they can be immediately reaped :(
[06:15] <jtv> wgrant: I take it this is not about my branch?
[06:15] <wgrant> No.
[06:16] <jtv> Phew.
[06:16] <wgrant> It's recovery from some different mass publication update queries from years ago :)
[06:17] <jtv> Ah.  And… they're binaries that ought not be reaped?
[06:17] <jtv> rope?
[06:17] <wgrant> They ought to be reaped.
[06:17] <jtv> Is reaped really a regular verb?
[06:17] <jtv> reapt?
[06:17] <wgrant> But they cannot be, because we don't have them in the librarian any more.
[06:17] <wgrant> reapt is too close to crept!
[06:17] <jtv> Ahhh that one.
[06:17] <wgrant> So I must rescue them from the pool back into the librarian, so they can be reaped from the pool, and then the librarian.
[06:17] <wgrant> Sort of.
[06:18] <jtv> Getting the patients all healthy and rosy-cheeked for the executioner, eh?
[06:18] <wgrant> Exactly!
[06:18] <jtv> Thanks for the review BTW.
[06:18] <wgrant> Ah, yes, sorry, got distracted by your XXX abomination.
[06:21] <jtv> Abomination even?  Glad you liked it.
[06:25] <jtv> wgrant: about the multiple-publications-of-same-version issue…  domination orders by (SPR.version, SPPH.datecreated).  I wonder if it shouldn't be something like (SPR.version, SPR.id, SPPH.datecreated).  The issue affects conventional and new domination, really.
[06:25] <jtv> Can there be 2 published SPPHs for the same SPR for the same (Archive, DistroSeries, Pocket, SourcePackageName)?
[06:25] <jtv> (And similar for BPPHs etc.)
[06:26] <jtv> Sorry, for two _different_ SPRs for the same (Archive etc.)
[06:26] <jtv> So two SPRs for the same version of the same package, and each with their own Published SPPH in the same (archive, distroseries, pocket).
[06:27] <jtv> Is that at all possible?  If so, what if the SPRs are ordered differently in time than the SPPHs are?
[06:27] <wgrant> It's not legal to have two SPRs in one archive with the same name and version, because they don't fit on disk.
[06:27] <wgrant> However.
[06:27] <wgrant> That doesn't mean it hasn't happened.
[06:27] <wgrant> It has.
[06:27] <wgrant> But they should never both be published, because they can't both be on disk at once.
[06:28] <jtv> So domination doesn't need to go out of its way to accommodate this situation.
[06:28] <wgrant> Probably not. The publisher will crash before it gets into that situation.
[06:28] <jtv> Why are so many words ending on -ation nowadays?  Used to be different when I was your age, I can tell you.
[06:28] <wgrant> Because it will see the publication marked as Pending, try to write it to disk, then blow up when it sees a different file already there.
[06:28] <wgrant> So the conflict never gets marked as Published.
[06:28] <wgrant> It just OOPSes forever until we SQL it out.
[06:29] <jtv> Good enough for me.
[06:29] <wgrant> Ahem.
[06:30] <jtv> So then, would it be fair to say "if a single live version of a package has multiple Published pub records (within the same archive yadda yadda) then the most recent of those pub records dominates the rest of them, and they should become superseded"?
[06:31] <wgrant> Yup.
[06:31] <jtv> And it specializes neatly to the classic domination algo, so that's all dandy.
[06:31] <wgrant> So... I guess you just sort by SPPH.datecreated, and drop a version from the live set once you see it?
[06:32] <wgrant> Mm, but that's moving the logic into dominatePackage, which is slightly upsetting.
[06:32] <jtv> The details get a bit intimate with the implementation, so step back:
[06:32] <wgrant> But maybe.
[06:32] <wgrant> Yeah.
[06:32] <jtv> dominatePackage goes through a list of SPPHs sorted by descending (SPR.version, SPPH.datecreated).
[06:33] <jtv> It remembers the last live… SPR IIRC that it saw.
[06:33] <jtv> If it encounters a non-live version: supersede by the last-live whatever-it-remembers.
[06:34] <jtv> If it encounters a live version: leave it as it is, but record it as the last live whatever-it-is.
[06:34] <jtv> What I need to add then, I think, is "is this SPPH the same as for the last live version?  If so, supersede it as well."
[06:36] <jtv> (Alternatively I could compare to the last-seen version; same results, assuming the choice of dominant doesn't change, but probably slightly more code)
[06:36] <jtv> Anyway, tests first, then look at the implementation details.
[06:52] <nigelb> wgrant: Is the font fix okay?
[06:54] <wgrant> nigelb: It looks good, but it's not on production yet.
[06:55] <nigelb> wgrant: cool, okay :)
[06:56] <wgrant> Thanks for sorting that out.
[06:57] <nigelb> When I look at https://bugs.launchpad.dev/debian/+source/mozilla-firefox/+bug/3/+activity
[06:57] <_mup_> Bug #3: Custom information for each translation team <feature> <lp-translations> <Launchpad itself:Fix Released> <Ubuntu:Invalid> <mono (Ubuntu):Invalid> < https://launchpad.net/bugs/3 >
[06:57] <nigelb> oh wait, .dev
[06:58] <nigelb> https://bugs.launchpad.net/launchpad/+bug/88545/+activity
[06:58] <_mup_> Bug #88545: Abolish the "statusexplanation" database field <lp-bugs> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/88545 >
[06:58] <nigelb> I see statusexplanation
[06:58] <nigelb> Even though I removed all references to that field in this branch
[06:58] <nigelb> Is that normal?
[06:58] <wgrant> Sounds like you didn't remove all of them.
[07:03] <wgrant> nigelb: Oh.
[07:03] <rvba> Morning.
[07:03] <wgrant> nigelb: Nevermind, that's fine.
[07:04] <wgrant> nigelb: I was misunderstanding.
[07:04] <wgrant> nigelb: If you look at the content of the bugactivity table, you'll see that there are changes with whatchanged == 'statusexplanation'.
[07:04] <wgrant> nigelb: We could delete them too, but there's no need and little benefit.
[07:04] <wgrant> Erasing history is bad :)
[07:06] <nigelb> Excellent
[07:06] <nigelb> wgrant: ah, that's bugactivity table
[07:06] <nigelb> I tried to find the table
[07:07] <nigelb> my psql skills are still not 1337 enough :P
[07:07] <wgrant> \d bug<TAB><TAB>
[07:07] <wgrant> Or not.
[07:07] <wgrant> launchpad_dev=# \d bug
[07:07] <wgrant> Display all 228 possibilities? (y or n)
[07:07] <wgrant> :(
[07:08] <nigelb> I did a \dd
[07:08] <nigelb> and looked in there
[07:08] <nigelb> was that wrong?
[07:08] <wgrant> \dd is more than just relations, so it's far bigger than what you want.
[07:08] <wgrant> \d shows just tables/views/sequences, so is more interesting.
[07:08] <nigelb> ah
[07:10] <nigelb> oh, just missed wallyworld_ :(
[07:10] <nigelb> wgrant: Out of panic, I did the ++profile++show page and looked at the sql queries ;)
[07:11] <wgrant> Heh.
[07:11] <nigelb> hrm, abel isn't in yet.
[07:11] <nigelb> I'll have to ask later for my destroy branch
[07:36] <henninge> wgrant: Hi! ;)
[07:36] <wgrant> This can't be good!
[07:36] <wgrant> Hi.
[07:37] <henninge> wgrant: The process that logs to buildd-manager.log is the buildmaster, i.w. running on build-master host?
[07:37] <wgrant> henninge: The process is buildd-manager, running on cesium, also known as builddmaster or occasionally buildmaster.
[07:37] <henninge> wgrant: and it gets reststarted during a nodowntime rollout, right?
[07:37] <wgrant> Yes.
[07:38] <henninge> ok, just wanted to be sure.
[07:38] <henninge> I added extra logging output at the end of a ttbj (elevated it from debug to info) but I don't see anythting.
[07:39] <wgrant> :(
[07:39] <henninge> Just the "starting templates build j..."
[07:39] <henninge> so these builds must die before they reach the WAITING state.
[07:40] <henninge> I will have to try this out locally or on dogfood.
[07:40] <henninge> thanks wgrant ;)
[07:54] <adeuring> good morning
[08:01] <mrevell> Hello
[08:03] <bigjools> morgen
[08:17] <jtv> hey there mrevell, bigjools
[08:25] <nigelb> Morning mrevell / bigjools :)
[08:26] <nigelb> adeuring: Hi, are you OCR-ing today?
[08:26] <adeuring> nigelb: yes. do you need a reviewß
[08:26] <nigelb> adeuring: Yep - https://code.launchpad.net/~nigelbabu/launchpad/destroy-statusexplanation-88545/+merge/74704
[08:27] <adeuring> nigelb: ok, I'll look
[08:28] <nigelb> thanks!
[08:30] <StevenK> \o/
[08:37] <StevenK> nigelb: One thing to note is to ask your reviewer to land it with the --incremental flag -- the branch doesn't fix the linked bug entirely.
[08:41] <nigelb> StevenK: ah, ok
[08:42] <StevenK> nigelb: The bug is about the existance of the column, you haven't removed it yet. :-)
[08:46] <nigelb> StevenK: AHH, right. That gets completely removed in the next step :)
[08:46] <StevenK> nigelb: Right!
[08:49] <nigelb> StevenK: First time doing such a thing, will remember next time :)
[08:49] <StevenK> nigelb: Which is why I'm helping you :-)
[08:49] <nigelb> \o/
[08:58] <nigelb> StevenK: Do I get a destroyer badge now? :P
[08:59] <StevenK> The destruction isn't nearly wide-spread enough
[09:01] <nigelb> heh
[09:01] <StevenK> steven@liquified:~/launchpad/lp-branches/no-more-staticdiff% bzr di -r 13779..13783 | diffstat -s
[09:01] <StevenK>  21 files changed, 53 insertions(+), 597 deletions(-)
[09:01] <StevenK> Now that is wide-spread destruction.
[09:01] <nigelb> woooooah
[09:01]  * nigelb isn't that invasive
[09:02] <nigelb> (yet)
[09:02] <StevenK> That was a fun branch. Does that look like StaticDiff or something that supports it? Yes, remove it.
[09:02] <nigelb> heh
[09:05] <adeuring> nigelb: a very nice  branch. Just one question: Shouldn't lib/lp/bugs/stories/bugs/xx-bug-activity.txt be changed too? I get the error "psycopg2.OperationalError: fe_sendauth: no password supplied" when I try to run the test. An unrelated problem, but I can't answer this question myself...
[09:05] <rvba> adeuring: see William's recent email to -dev about this.
[09:05] <nigelb> adeuring: Is that the one with the table?
[09:05] <rvba> adeuring: and Hi btw ;)
[09:06] <nigelb> adeuring: No, it doesn't need to be fixed. I asked wgrant earlier about this and he said history is a good thing :)
[09:06] <adeuring> nigelb, wgrant: ok, I'll look. SImply missed the mail
[09:06] <nigelb> That's actually in bugactivity and not entirely related
[09:06] <nigelb> I faced the test trouble too last night :)
[09:09] <adeuring> nigelb: ah, sure, so, r=me.
[09:11] <nigelb> adeuring: \o/ Can you land it for me as well. And as StevenK said, with the --incremental flag ;)
[09:13] <adeuring> nigelb: sure. And your reminder about --incremental may already answer my question: Would you like to work on the remaining usage of statusexplanation too, especially the DB patch?
[09:15] <nigelb> adeuring: Yes, I would
[09:15] <nigelb> In fact, I'll probably be starting on it tonight
[09:16] <adeuring> nigelb: cool, many many thanks1
[09:19] <nigelb> \o/
[09:30] <al-maisan> I am getting errors when uploading a source package to a ppa .. is LP down for maintenance..?
[09:31] <jml> al-maisan: no. Otherwise it would say on identi.ca/launchpadstatus and in the topic here.
[09:32] <al-maisan> these are the errors: http://pastebin.ubuntu.com/685841/ -- and they are persistent
[09:32] <al-maisan> hmm ..
[09:32] <bigjools> wgrant: looks like poppy didn't reconnect?
[09:34] <cjwatson> jtv: are all new Debian SPPHs permanently PUBLISHED from here on out, or will new ones still be created as PENDING for a while?
[09:34] <jtv> cjwatson: all Published.
[09:35] <jtv> Except _maybe_ (I'm not sure about this yet) ones that are copied when creating a new release.
[09:35] <cjwatson> jtv: OK.  The change broke a swathe of ubuntu-dev-tools API scripts that were assuming PENDING, so I'll have to get that changed quickly
[09:35] <jtv> cjwatson: ouch!  I'm sorry, I thought this difference had to be inconsequential since PENDING seemed so pointless.
[09:36] <jtv> In the Launchpad codebase we have a helper variable active_publishing_status that consists of PENDING and PUBLISHED.
[09:36] <cjwatson> we had various getPublishedSources queries that had to be special-cased for Pending before
[09:36] <wgrant> jtv: Aren't they still created as PENDING until the next deployment?
[09:36] <wgrant> cjwatson: Hmm, getPublishedSources should default to PENDING and PUBLISHED.
[09:36] <wgrant> cjwatson: So it should have DTRT.
[09:36] <jtv> wgrant: true, but that's not far off.
[09:36] <cjwatson> wgrant: we were overriding the default :-)
[09:37] <wgrant> cjwatson: Right, but it shouldn't have been necessary :(
[09:37] <cjwatson> but hey, that makes it easier, I'll just delete some code.
[09:37] <jtv> \o/
[09:37] <cjwatson> that will presumably have the side-effect that now we'll notice Ubuntu uploads before the publisher runs
[09:37] <wgrant> bigjools: Argh.
[09:37] <wgrant> bigjools: @read_transaction should have handled that...
[09:39] <jtv> Meanwhile, Soyuz-capable reviewer needed for the next piece of the Gina-the-Dominatrix puzzle: https://code.launchpad.net/~jtv/launchpad/bug-845326/+merge/74741
[09:39] <wgrant> bigjools: Can you arrange for it to be bounced?
[09:40] <wgrant> bigjools: And probably a bug filed for maintenance people to look at.
[09:40] <cjwatson> wgrant: I don't see the getPublishedSources default you mention - can you point me to it?
[09:41] <cjwatson> Oh, and could somebody attempt to land https://code.launchpad.net/~cjwatson/launchpad/multiarch-translations for me?  Yay for fastdowntime at last. :-)
[09:41] <jtv> cjwatson: I'll take it
[09:41] <cjwatson> Hm, that's marked as for merging into db-devel
[09:41] <cjwatson> that should be devel, yes?
[09:42] <stub> yer, superceed the proposal and it lets you retarget it.
[09:42] <wgrant> cjwatson: Ah, distroseries.getPublishedSources has something like that default, but archive doesn't.
[09:42] <wgrant> Wow, those are bad APIs.
[09:42] <cjwatson> wgrant: I guess I can just pass status=('Pending', 'Published') then
[09:43] <jtv> cjwatson: the multiarch-translations are not attached to a bug?
[09:43] <wgrant> cjwatson: Are you using the one on DistroSeries or Archive?
[09:43] <jtv> cjwatson: if you're building this on top of the Launchpad codebase, use active_publishing_status.
[09:43] <wgrant> cjwatson: If Archive, status=['Pending', 'Published'] should work, yeah.
[09:44] <wgrant> And if you are using DistroSeries.getPublishedSources, then stop because it shouldn't exist :)
[09:44] <cjwatson> jtv: bug> no, I never got round to filing one.  Is that a problem?
[09:44] <cjwatson> jtv: active_publishing_status> this is an API script
[09:45] <jtv> cjwatson: a bit—our Q/A process revolves around the associated bug.
[09:45] <cjwatson> I can file one now then, one moment
[09:45] <jtv> (Oh thank you pidgin for telling me _now_ that Colin asked me a question.  Why didn't I just start using Windows so I could get the beta experience all the time?)
[09:46] <jtv> Thanks.
[09:46] <jtv> bigjools: realistically I expect I need either you or william for that review, simple though it be… https://code.launchpad.net/~cjwatson/launchpad/multiarch-translations
[09:46] <jtv> Ahem, not that one
[09:47] <jtv> I mean https://code.launchpad.net/~jtv/launchpad/bug-845326/+merge/74741
[09:49] <cjwatson> jtv: bug 845475
[09:49] <_mup_> Bug #845475: Separate translations out of Packages to reduce download requirements for multiarch clients <Launchpad itself:New> < https://launchpad.net/bugs/845475 >
[09:49] <jtv> thanks cjwatson — I'll attach it if necessary
[09:52] <cjwatson> wgrant: I can't pass status=['Pending', 'Published'] through the API.  It only wants one.
[09:53] <rvba> wgrant: as part of fixing bug #827608, I'm currently chaning _latestSeriesQuery to return SPPHs instead of SPRs. I know I'll have to fix quite a bit of code after that change but I really think this is doable ... do you see a reason why I should not do that?
[09:53] <_mup_> Bug #827608: Sync requester isn't credited with upload <derivation> <Launchpad itself:In Progress by rvb> < https://launchpad.net/bugs/827608 >
[09:53] <jtv> cjwatson: annoying… have you tried both tuple and list?  We have some code that gets finicky about that.
[09:53] <cjwatson> jtv: yep, tried both
[09:53] <wgrant> cjwatson: Hah. The Python API accepts both, but the interface for lazr.restful is declared to only accept one.
[09:53] <cjwatson> wgrant: oh, and this is Archive, yes.
[09:53] <wgrant> cjwatson: That is unpleasant.
[09:54] <jtv> cjwatson: did you just resubmit your merge proposal?
[09:54] <wgrant> al-maisan: The poppy error is just cosmetic, and we're working on upgrading to a fixed version now. Your upload should still have gone through fine.
[09:55] <jtv> and hi al-maisan :)
[09:55] <al-maisan> ah, I see, thanks wgrant !
[09:56] <al-maisan> .. and hello to my favourite fascist reviewer: jtv :)
[09:56] <al-maisan> how are you my friend?
[09:56] <jtv> After calling me a fascist, that sounds as if you're rhetorically asking in what way I am your friend.  :)
[09:57] <jtv> Wonderful here though, thanks.  Hope it's the same for you.
[09:57] <cjwatson> jtv: yes, it's https://code.launchpad.net/~cjwatson/launchpad/multiarch-translations/+merge/74743 now
[09:57] <al-maisan> jtv: I called you a "fascist reviewer" .. please observe the context ;)
[09:58] <jtv> al-maisan: True.  And I must have upset the wrong people because I've been convicted to heaps of Soyuz work.
[09:58] <al-maisan> jtv: yup .. doing great, thanks!
[09:58] <wgrant> al-maisan: (poppy fell victim to our first real test of our new 2-minute-downtime DB patch process -- we're still ironing out the kinks, as you can see)
[09:58] <jtv> cjwatson: so it's for devel now, instead of db-devel?  It has no dependency whatsoever on the db patch?
[09:58] <al-maisan> jtv: uh-oh .. but you are enjoying soyuz .. admit it :)
[09:58] <wgrant> jtv: The DB patch is applied!
[09:59] <al-maisan> wgrant: change is always difficult :P
[09:59] <wgrant> But we can apply DB patches daily now, so all is wonderful.
[09:59] <jtv> al-maisan: http://paste.ubuntu.com/685825/ http://paste.ubuntu.com/685826/
[09:59] <wgrant> ... apart from poppy.
[10:00] <cjwatson> jtv: Yep, I held off asking for a landing until the DB patch got applied.
[10:00] <jtv> wgrant: ah, I wasn't sure about this because it was for db-devel.  Anyway, I'll check the minimum of required boxes & land.
[10:00] <cjwatson> jtv: The new MP is for devel.
[10:00] <wgrant> jtv: I think it's all going to be a bit confusing like that for a month or two while people get used to the new hotness :)
[10:00] <cjwatson> jtv: When I initially prepared this branch, I got caught up in some merge target confusion because the changes to fastdowntime were just starting.
[10:00] <jtv> Yes, spotted it, thanks.  Unfortunately the resubmit also seems to have re-requested reviews.
[10:00] <wgrant> And while we sort out all the pending MPs.
[10:01] <wgrant> cjwatson: I think the process has been redesigned twice since you started the branch.
[10:01] <cjwatson> jtv: I don't think it should actually need those db reviews now
[10:01] <wgrant> You did rather well.
[10:01] <cjwatson> But yes, it would need a normal review
[10:01] <jtv> It's the same review it went through before, no?
[10:01] <jtv> I mean, the code changes had already been approved, right?
[10:02] <jtv> It was an approved MP with pure code changes after all.
[10:02] <cjwatson> Right.
[10:02] <cjwatson> The only change since the code review was a merge from db-devel
[10:02] <jtv> OK.  It's going into EC2.
[10:02] <cjwatson> Thanks.  Let's see how that goes ...
[10:03] <jtv> It's been working for me today.
[10:04] <jtv> Unfortunately the oneiric beta version is causing me some very serious trouble, with minute-long seizures and disappearing emails.  It seems to be related to dbus and X.  The bug for the most immediate symptom seems to be getting attention so let's see what happens.
[10:05] <cjwatson> Restarting compiz occasionally helps.
[10:05] <jtv> (The disappearing emails seem to be from TB being too busy to move emails from one folder to another; they probably turn up somewhere in the end)
[10:05] <cjwatson> (IME)
[10:06] <jtv> How do I restart compiz?  Actually I'm not even sure I'm running it.
[10:06] <jtv> I was on unity2d but in oneiric I can't tell the difference any more.  Which is probably a sign that they're being unified, which is good especially given the name.
[10:07] <wgrant> jtv: When you hover over a launcher icon, is the tooltip black and transparent?
[10:07] <wgrant> Argh, unity 2D's are now transparent too :(
[10:07] <wgrant> But they're a much lighter grey.
[10:08] <wgrant> That's how I distinguish between them.
[10:08] <wgrant> Black = 3D, grey = 2D
[10:08] <jtv> It looks dark-gray and dithered; I can't see anything from the background through it.  Pretty much how it used to look in unity 2d.
[10:08] <cjwatson> pkill -9 compiz (note: will shuffle all your workspaces among windows), or log out and back in.  Although I don't think unity-2d uses compiz; check with 'pgrep compiz'
[10:08] <al-maisan> jtv: ah, I see, you are having too much fun .. they should reduce your wages ;)
[10:08] <wgrant> Also, 'unity' now defaults to restarting everything.
[10:09] <wgrant> And it even works without DISPLAY set, from back in natty when you needed to restart several times a day.
[10:09] <jtv> So I'm still on 2d.  Strange, because I think the new login screen (wonderful, apart perhaps from the delay before the asterisks for my password appear) was telling me I was logging into "ubuntu" as opposed to "ubuntu 2d"
[10:09] <wgrant> So you can just switch to a TTY, log in, and 'unity'
[10:09] <jtv> al-maisan: heck, they even let me train little fascists now!
[10:09] <al-maisan> oh no!
[10:09] <al-maisan> :)
[10:09] <jtv> cjwatson: nope, pgrep compiz returns 1
[10:09] <jml> jtv: https://bugs.launchpad.net/unity-greeter/+bug/838777
[10:09] <_mup_> Bug #838777: Really slow shortly after booting <Unity Greeter:New> < https://launchpad.net/bugs/838777 >
[10:10] <jtv> thanks jml, as always concise and devastatingly accurate!
[10:11] <jtv> al-maisan: I just graduated one, and when the other day I got to do some temporary mentoring for another, nobody wanted a review all of a sudden.  :)
[10:11] <wgrant> jtv: Oh, you're not rvba's permanent mentor? :(
[10:11] <wgrant> I want more clones of you.
[10:11] <jml> jtv: np. I've been spending a lot of time filing bugs against oneiric recently. I've even managed to get some of them fixed.
[10:11] <jtv> *Entire channel stares at wgrant*
[10:11] <wgrant> Heh
[10:11] <jtv> yay for jml
[10:11] <al-maisan> jtv: for some inexplicable reason I can relate to that :)
[10:12]  * jtv laughs
[10:17] <nigelb> wgrant: More clones of jtv? Are you sure?
[10:18] <cjwatson> jtv,wgrant: bug 845487, FYI
[10:18] <_mup_> Bug #845487: Debian source publication checks have broken <ubuntu-dev-tools (Ubuntu):New> < https://launchpad.net/bugs/845487 >
[10:20] <jtv> thanks cjwatson
[10:20] <wgrant> cjwatson: Note that publications will shortly in the next few days be marked Superseded/Deleted as appropriate.
[10:20] <wgrant> s/shortly //
[10:21] <jtv> nigelb: according to my IRC client it took you 5 minutes and 54 seconds to recover enough from wgrant's statement to formulate that question.
[10:22] <nigelb> jtv: I was at lunch :)
[10:22] <rvba> nigelb: quick lunch then ;)
[10:22] <jtv> cjwatson: to be precise: for packages that gina no longer sees in Debian, the last publication of the highest version will become or remain Published and the rest will become superseded.
[10:23] <cjwatson> That's fine
[10:23] <jtv> For packages that it _does_ see in Debian,
[10:23] <nigelb> jtv: But yeah, took a while to recover :D
[10:23] <cjwatson> I'm pretty sure ubuntu-dev-tools only cares about the most current one in a series
[10:23] <jtv> if it only sees a newer version in Debian than in the DB, the publication will become Superseded.
[10:24] <jtv> If there are multiple publications of the same version in the same series/archive/pocket (e.g. because of a component change), the older publications will be superseded.
[10:24] <jtv> The newest publications for remaining versions become/remain Published.
[10:24] <jtv> Any publications of versions that are _newer_ than anything that's currently seen in Debian will become Deleted.
[10:25] <jtv> That's the “transitional” stage of Gina domination.
[10:25] <jtv> Once that has run, we'll get more aggressive: if the package is no longer in Debian, any remaining Published publications become Deleted.
[10:32] <jtv> Soyuz-capable reviewer needed!  https://code.launchpad.net/~jtv/launchpad/bug-845326/+merge/74741
[10:36] <jtv> Coincidence I'm sure.
[10:39] <jtv> cjwatson: I could have a go at bug 845486.  My API knowledge's a bit rusty though.
[10:39] <_mup_> Bug #845486: cannot pass sequence to Archive.getPublishedSources through API <Launchpad itself:New> < https://launchpad.net/bugs/845486 >
[10:42] <cjwatson> mine is more so :-)
[10:44] <jtv> Our API infrastructure really has a very 1990s notion of polymorphism, doesn't it?
[10:45] <jtv> cjwatson: maybe it should accept, as alternatives, a “status” _or_ a sequence of “statuses.”
[10:46] <cjwatson> Oh, yes, good point, breaking existing code that passes a single status would be bad!
[10:47] <jtv> We'll have some callsites in Launchpad that need to be converted, but that's unlikely to pose many problems.
[10:47] <jtv> It's still ugly, of course, but I'm not sure we can do better without breaking API compatibility.
[10:48] <cjwatson> jtv: How so?  The existing LP code already accepts either a status or a sequence of statuses; it's only the API declaration that's less flexible
[10:48] <cjwatson> oh, unless you mean as different parameter names
[10:48] <jtv> Yes, the only proper thing to do would be to convert status=[…] in argument lists to statuses=[…]
[10:48] <jtv> Which is something we've been wanting to do.
[10:49] <jtv> Even nicer, arguably, would be to convert all callsites to use statuses.  But given API compatibility I don't think we can retire the "status" parameter anyway.
[10:50] <cjwatson> Indeed
[10:53] <jml> jtv: I think the status-as-list-or-string pattern is used by searchTasks.
[10:53] <jtv> adeuring: would you perhaps be available for a pre-implementation discussion as a change from regular OCR duty?
[10:53] <jtv> jml: how does the API deal with it there?
[10:53] <jtv> The web-service API I mean?
[10:53]  * jml looks
[10:58] <henninge> Do the builders still run on lucid?
[10:59] <jml> jtv: it's declared as a list, but apparently passing a string goes through ok. There is then a helper that ensures it's returned sanely.
[11:00] <jml> jtv: it's all a bit convoluted.
[11:00] <jtv> jml: convoluted sounds bad.
[11:00] <jml> jtv: but I think the convolution is mostly searchTasks being weird for other reasons.
[11:00] <jml> jtv: rather than to handle this case
[11:01] <jtv> henninge: yes, they run on LTS
[11:01] <henninge> jtv: thanks
[11:02] <jtv> jml: it'd certainly give us an easier fix if this works.  Still a bit misleading though to have a strict type system and then lie about the type.
[11:03] <jml> jtv: agreed. although, as an API user, I'd be mightily irritated by having to spell multiple statuses for bugs differently to multiple statuses for source package publishings.
[11:03] <jtv> jml: what I hear you say is that maybe the strict type system is more to blame here than the lying.  :-)
[11:04] <jml> jtv: well, it's not a strict type system.
[11:04] <jml> jtv: it's a lau(d|gh)able attempt to build one in Python.
[11:04] <jtv> You had me there for a moment.
[11:05] <jtv> Okay, I'll try to get the List trick to work then.
[11:06] <jtv> Although in the past I've been bitten by the two ways to test the API: one was fast and followed very dynamic (and for me, convenient) type rules.  The other was slow but more realistic, and applied WADL's type rules.
[11:06] <jml> IBugTaskSearch.importance (or status) has the 'type declaration'. I think BugTaskSearchParams.fromSearchForm does the string->list stuff, I *think*.
[11:07]  * jtv looks
[11:10] <jtv> jml: any idea where importance could be passed in through the web UI?  Beacuse IBugTaskSearch.importance is an attribute, but I'm looking for a parameter.
[11:10] <jml> jtv: sorry, I don't understand.
[11:11] <jml> jtv: I mean, I don't understand why you care. If I were to figure out the answer, it'd be by grepping for fromSearchForm, since that sounds an awful lot like something used in the UI.
[11:13] <jml> jtv: If you want to see it used as an API parameter, then look for searchTasks.
[11:16] <nigelb> Okay, so I landed a branch that removes the usage of the field that I want to kill.
[11:16] <nigelb> Now how do I proceed?
[11:19] <rvba> nigelb: Create a branch off db-devel with a db patch in it: https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess
[11:21] <nigelb> excellent, thanks!
[11:21] <rvba> welcome
[11:31] <nigelb> Wow, this process looks detailed.
[11:31] <nigelb> I'm going to spend 1 hour trying to read and understand first
[11:31] <bigjools> haha - I just started documenting Soyuz.
[11:32] <jtv> He's gone mad.
[11:32] <jtv> It had to come to this.
[11:36] <nigelb> Hrm, I wonder if the DatabaseSchemaChangesProcess wiki page needs update post the new faster db updates
[11:45] <adeuring> jtv: sure. And sorry for the late answer, was in the other room for lunch
[11:50] <jtv> adeuring: actually we already had some discussions here, sorry
[11:50] <adeuring> np
[11:54] <wgrant> nigelb: I believe it's already up to date.
[11:55] <wgrant> nigelb: The old process was abolished almost two months ago, because fastdowntime was meant to be done 6 weeks ago :)
[11:55] <StevenK> wgrant: Can I put together a patch to drop FKs, then? :-)
[11:57] <wgrant> StevenK: I was going to look at that next week, once we've had a clean run with rvb's patch on Monday night.
[11:57] <wgrant> Since tonight was not entirely smooth, I don't want to go doing anything quite so big just yet.
[11:58] <StevenK> wgrant: I was thinking we do it piecemail, TBH
[11:58] <nigelb> wgrant: Oh. Ok.
[11:58] <wgrant> StevenK: No, it should be one hit.
[11:58] <wgrant> Since we only apply one patch a day.
[11:58] <wgrant> And there's like 32 tables or something.
[11:58] <StevenK> 35
[11:59] <StevenK> wgrant: Do you have a patch already, or shall I look at writing it?
[11:59] <StevenK> I'll make a start on it, anyway
[11:59] <wgrant> I have one that's not quite fastdowntime capable.
[11:59] <wgrant> I will fix it weekend or Monday.
[12:00] <StevenK> It deals with everything, including staticdiff?
[12:00] <wgrant> No, but it's trivial to extend.
[12:00] <StevenK> It's too slow for FDT, or what?
[12:09] <jml> so, did LP actually have a low downtime db patch rollout?
[12:10] <jml> this means fastdowntime from now on?
[12:11] <StevenK> jml: We can only do fastdowntime, lifeless removed the monthly process from us.
[12:11] <jml> StevenK: well yes, but two days ago you couldn't even do fastdowntime.
[12:15] <bac> mrevell: fwiw, i just bought a batch of vouchers and they showed up promptly
[12:16] <mrevell> Cheers bac. Do you have any idea what might have gone wrong for Vadim?
[12:16] <wgrant> jml: Yep, we can do fastdowntime daily now.
[12:16] <wgrant> jml: Not completely smooth, but we know how to avoid the problems that show up.
[12:16] <bac> mrevell: nope.  all i can think of is the proxy was stuck.
[12:16] <bac> or dead
[12:17] <wgrant> jml: Got dozens of DB patches for us yet?
[12:17] <mrevell> bac, Cheers, well, I'll keep an eye out for similar things in future ... if we end up with a couple it might be easier to work out what's going on. Or maybe not.
[12:20] <jml> wgrant: nope :) you put me off, so now I'm doing the data generation stuff locally first and postponing the "Where does the data live?" question.
[12:21] <wgrant> Sounds like a good plan.
[12:21] <bac> adeuring: are you currently working on any reviews?
[12:21] <adeuring> bac: no
[12:21] <wgrant> jml: We have 270 tables... I would personally like to discourage adding more that aren't really too directly relevant.
[12:21] <bac> adeuring: cool.  i'll claim one of rvba's
[12:21] <adeuring> bac: ok
[12:22] <StevenK> wgrant: So tempted to land populate-bprc
[12:22] <jml> wgrant: I'm pretty sympathetic to that line of argument.
[12:22] <wgrant> jml: I can certainly see the convenience.
[12:22] <wgrant> jml: But even LP is discouraged from putting tables in LP's database now.
[12:23] <jml> wgrant: anyway, if I do the scraping & data gathering and just dump to a sqlite db locally for now, that'll help me make progress.
[12:23] <wgrant> Yeah.
[12:23] <wgrant> Maybe we will not be in limbo when you are done :)
[12:24] <jml> The last time I did limbo it was on rollerskates.
[12:25] <wgrant> That sounds inevitably disastrous.
[12:26] <jml> :)
[12:27] <rvba> bac actually, I had to recreate branches from code that was already approved yesterday by jcsackett.
[12:28] <rvba> bac: [...]-spph-creator-code is simply the extraction of the code that was previously in [...]-spph-creator
[12:29] <bac> rvba: so jcsackett approved a combined branch and you pulled them apart?
[12:30] <rvba> bac: exactly.
[12:30] <bac> rvba: good to know.  i'll look at them with one eye tied behind my back
[12:31] <rvba> bac: I had to refactor that due to the fact that we want to separate code change from db changes completely for FDT.
[12:31] <bac> rvba: right
[12:33] <benji> henninge: do you have any answers to my questions on https://bugs.launchpad.net/launchpad/+bug/742662 ?
[12:33] <_mup_> Bug #742662: Mixed new line markers causing OOPS while importing translations <bad-commit-13889> <oops> <qa-bad> <rosetta-imports> <Launchpad itself:In Progress by benji> < https://launchpad.net/bugs/742662 >
[12:34] <henninge> Hi benji!
[12:35] <henninge> benji: There is no oops or similar, we came to that conclusion just by looking at the code.
[12:35] <henninge> benji: https://code.launchpad.net/~benji/launchpad/bug-742662/+merge/74254
[12:35] <henninge> benji: line 302 of the diff
[12:35]  * benji looks.
[12:36] <henninge> benji: you add a call to verifyNewlineConsitency to the importer.
[12:36] <henninge> benji: that will throw an exception
[12:37] <henninge> if the newlines don't match.
[12:37] <henninge> let me go to the code
[12:40] <benji> henninge: true, it will throw an exception, which is caught in POTemplate.importFromQueue and POFile.importFromQueue (it wasn't being thrown before, but the catch has been there for a while)
[12:41] <henninge> benji: I am sorry, I am just realizing that I was wrong
[12:41] <benji> heh
[12:41] <henninge> benji: it *was* being thrown before
[12:43] <benji> henninge: well, it was being thrown, but during imports (only during TTW updates of translations)
[12:43] <benji> (TTW = "through the web")
[12:44] <henninge> benji: well, there is storeTranslationsInDatabase
[12:44] <henninge> benji: which calls sanitize_translations_from_import
[12:46] <henninge> benji: so, that was already throwing the exception
[12:46] <henninge> benji: I may be missing what we gain from your, code though?
[12:46] <henninge> your code, though
[12:47] <benji> henninge: I don't know that you're missing anything, because now I'm confused
[12:47] <henninge> benji: but I am sorry, I did not look far enough to realize that these exceptions are indeed being caught.
[12:48] <henninge> benji: the fact that we have such data in the database is old data that was imported before sanitization was working properly.
[12:49] <benji> ah!  that answers my next question
[12:49] <benji> in that case I'm inclined to add some tests to the already existing code and then figure out how to kill the pre-existing bad imports
[12:53] <henninge> benji: what I find interesing as well is that the bug mentions "importing translations" in the title but refers to web submissions.
[12:54] <henninge> but I guess that is just Diogo getting mixed up with the terms.
[12:54] <benji> could be, or he (like I) assumed that the data was recently added
[12:55] <henninge> but the OOPSes in the bug are not from the imports
[12:55] <benji> true, but the reason we get OOPSes is because bad data got in to start with (or rather, we redefined what bad data was after the fact)
[12:56] <henninge> yes, so we need to live with that fact.
[12:57] <henninge> benji: so, the fix for those OOPSes would be to not check the English string again when submitting translations.
[12:57] <matsubara> henninge, I didn't change the description to include "importing translations". the original bug report only mentioned the mixed newline oops raised.
[12:59] <henninge> matsubara: hm, the bug does not say it's title or description were ever changed.
[13:01] <henninge> benji: ah, I see: the newline style is derived from the English original (it all comes back to me)
[13:01] <matsubara> henninge, isn't it bug 742662? see the change between comments #2 and #3
[13:01] <_mup_> Bug #742662: Mixed new line markers causing OOPS while importing translations <bad-commit-13889> <oops> <qa-bad> <rosetta-imports> <Launchpad itself:In Progress by benji> < https://launchpad.net/bugs/742662 >
[13:01] <henninge> benji: that is when the OOPS gets raised
[13:01] <henninge> matsubara: sorry /me is blind
[13:01] <henninge> matsubara: you are right
[13:02] <benji> :)
[13:02] <henninge> benji: so the fix is the following:
[13:04] <henninge> When sanitizing translations from the web ui, the MixedNewlineMarkersError needs to be caught and cause newlines not to be normalized
[13:04] <deryck> Morning, all.
[13:05] <henninge> because we don't know what the English original uses.
[13:05] <henninge> When sanitizing translations on imports, the exception should be treated as before.
[13:06] <henninge> For bonus points it would be great to not abort the import of the file completely but just report an error for this one string, like is done with other errors. But that is really outside the scope of this bug.
[13:07] <henninge> benji: is that understandable?
[13:07] <benji> that sounds quite reasonable
[13:07] <henninge> Hi deryck! ;)
[13:07] <henninge> benji: cool ;)
[13:13] <henninge> benji: I updated the bug.
[13:14] <benji> henninge: great, thanks!
[13:16] <StevenK> Can haz review https://code.launchpad.net/~stevenk/launchpad/kill-malone.bugmessage_owner/+merge/74775 ?
[13:18] <bac> StevenK: i'll review it next
[13:18] <henninge> bac: too slow... ;-)
[13:18] <henninge> StevenK: r=me
[13:19] <bac> thanks henninge.
[13:19] <henninge> which reminds me ...
[13:19] <StevenK> henninge: Thanks!
[13:20] <henninge> Do we have provisions for community reviewers?
[13:20] <henninge> Another week and I'd be one.
[13:20] <jtv> I don't think that ever really got off the ground.
[13:20] <jtv> Otherwise I would have gotten al-maisan to review my branch today.
[13:21] <StevenK> henninge: You can, but I still think it requires sign-off by a Canonical person
[13:22] <henninge> That's ok, I'll probably be too busy anyway ...
[13:24] <al-maisan> henninge: what is going to happen in a week's time?
[13:26] <henninge> al-maisan: I am leaving Canonical on the 16th.
[13:27] <al-maisan> ah, I see -- good luck with your future endeavours !
[13:27] <al-maisan> s/with/in/
[13:28] <henninge> al-maisan: thank you!
[13:31] <henninge> deryck: Audio problems, rebooting.
[13:42] <henninge> deryck: I just had a great business idea  - "Cake Pieces Online World-wide"
[13:42] <deryck> heh
[13:42] <deryck> For Virtual Going Away Parties Everywhere! :)
[13:43] <henninge> you pick your type of cake online and send a number of persons a piece each with a little note.
[13:43] <StevenK> bigjools: Can you make bug 396097 a dupe of jtv's gina domination bug?
[13:43] <_mup_> Bug #396097: Debian import doesn't remove packages <lp-soyuz> <Launchpad itself:Triaged> < https://launchpad.net/bugs/396097 >
[13:43] <henninge> deryck: exactly ;-)
[13:43] <nigelb> "gina domination" sounds like something that should probaly be not read outo of context
[13:44] <nigelb> henninge: you can sell to Canonical and Mozilla  - two companies with lots of remote teams ;)
[13:44] <bigjools> StevenK: jtv can even do it!
[13:45] <jtv> StevenK: you want it, _you_ do it!
[13:45] <jtv> nigelb: see my merge proposal entitled “Gina the Dominatrix”
[13:45] <nigelb> jtv: srsly?
[13:45] <jtv> srsly.
[13:45] <nigelb> I just googled for it.
[13:46] <StevenK> jtv: I don't know the bug number, sorry
[13:46] <nigelb> I wonder what google now thinks of me.
[13:46] <StevenK> And I thought jtv was EOD'd
[13:46] <flacoste> nigelb: you'll get interesting ad link now ;-)
[13:46] <jtv> StevenK: I guess you want bug 830890
[13:46] <_mup_> Bug #830890: Gina should delete publications if removed from source archive <derivation> <qa-ok> <Launchpad itself:In Progress by jtv> < https://launchpad.net/bugs/830890 >
[13:46] <nigelb> flacoste: Surprisingly, no ads. Noone thought of it!
[13:46] <jtv> StevenK: and I'm trying to be EOD because I'm OD'ed on Soyuz.  But I gave Julian one "end of this week" estimate too many and I want this done.
[13:46] <jtv> My main blocker for today: getting a reviewer.
[13:47] <StevenK> jtv: So marked
[13:47] <flacoste> nigelb: there is a business opportunity there!
[13:47] <nigelb> flacoste: Haha, I thought so too. We could rick roll them into contributing to gina ;)
[13:47] <flacoste> lol
[13:47] <jtv> flacoste: thanks for pointing out the Google angle.  These are after all the people smart enough to charge their customers for showing you "spam recipe" ads in your spam mailbox.
[13:49] <rvba> bac: if you're interested in the follow up branch ;) https://code.launchpad.net/~rvb/launchpad/sync-bug-827608-credit-copy/+merge/74769
[13:49] <bac> rvba: ok
[13:49] <rvba> bac: thanks.
[13:49] <bac> rvba: in your MPs you should list the db branch as a pre-req, no?
[13:50] <rvba> bac: well, the way I understand the new fdt process it's not a pre-req technically is it?
[13:50] <bac> rvba: good question.  you can't run your test without it...
[13:51] <bac> rvba: but in terms of getting a good diff you may be right
[13:51] <nigelb> GRAR. Test failure :(
[13:51] <rvba> bac: True, I've been advised by lifeless to put the sql patch in my tree, unversioned.
[13:52] <adeuring> nigelb: that's what the EC2 tests are for :) The fix shouldn't be difficult
[13:52] <nigelb> No, but I won't be able to get it for another 1 hour at least.
[13:52] <rvba> bac: we will see if I'll be able to put it up for review before I EOD but a final branch is coming up. Then it will be the end of the saga :)
[13:53] <nigelb> Can I work on the followup branch before this one lands?
[13:53] <StevenK> nigelb: You can
[13:54] <nigelb> Yay, not as depressing then
[13:54] <adeuring> nigelb: the follow up branch is the one with the DB patch? If so, sure, continue to work on it. But we should not land it before the other one lands
[13:55] <nigelb> adeuring: AH, ok
[13:57] <deryck> abentley, codehosting runs for me.  on a freshly up to date devel.
[13:57] <deryck> abentley, didn't try that, sorry.  Thought you couldn't get it to run.  Will try now....
[13:58] <abentley> deryck: It ran for me, but I couldn't push to it.
[14:00] <deryck> abentley, what's a local push command?  Don't remember, or haven't done it before.
[14:01] <abentley> deryck: bzr push lp://dev/~mark/+junk/foo
[14:02] <bigjools> is the person picker supposed to time out?
[14:02] <deryck> abentley, literally try that?  Or push to some user I create for myself locally?
[14:03] <abentley> deryck: literally mark.  You should have .ssh/config configured for that user.
[14:03] <jml> lifeless said that Launchpad was growing a table that had same/similar data to Contents.gz
[14:03] <jml> true?
[14:03] <wgrant> jml: Yes.
[14:03] <wgrant> jml: It exists, but is not populated.
[14:03] <wgrant> abentley: Not by default any more: use utilities/make-lp-user instead.
[14:03] <jml> wgrant: ok. ta. Exposed over API?
[14:04] <jml> make-lp-user is the best!
[14:04] <abentley> jml: A table of Contents.gz ?
[14:04] <wgrant> jml: Not at this stage, but that is part of the rationale for having it in LP.
[14:04] <jml> wgrant: cool. thanks.
[14:04] <jml> abentley: not *that* similar.
[14:04] <deryck> abentley, yup, works fine for me.
[14:04] <abentley> deryck: okay, thanks.
[14:05] <jml> also, getPublishedSources doesn't seem to have a date_published filter
[14:05] <deryck> abentley, np.  Sorry it took me so long.
[14:05] <jml> is that by design or simply because no one has wanted one yet?
[14:05] <jml> (or am I silly for wanting one?)
[14:05] <wgrant> jml: created_since_date?
[14:06] <jml> wgrant: Well, that filters on SPPH.datecreated, afaict
[14:06] <wgrant> jml: Do you really care about datepublished?
[14:06] <wgrant> That's usually a mistake.
[14:06] <jml> wgrant: and I don't really know enough to know if I want that or SPPH.datepublished
[14:06] <wgrant> What is your use case?
[14:06] <jml> wgrant: well, I don't know :)
[14:06] <jml> wgrant: things that have been published recently
[14:06] <wgrant> created_since_date=whatever, status='Published'
[14:07] <jml> since I last checked, so I can maintain a local mirror of some of the data in packages.
[14:07] <jml> ok
[14:07] <jml> thanks.
[14:07] <jml> happily, that's what I'm doing now.
[14:07] <wgrant> If you want to be really quick, do a separate lookup for Pending.
[14:07] <jml> why so?
[14:07] <wgrant> Then you can grab the files directly from LP, and have the data before they hit archive.u.c.
[14:10] <jtv> cjwatson: I'm afraid I haven't been able to make much headway with the getPublishedSources status arg.
[14:10] <jml> wgrant: cheers.
[14:11] <cjwatson> jtv: we'll probably just end up using status='Published' across the board for a while.
[14:11] <jtv> cjwatson: it shouldn't be long before Published is the universal answer.
[14:11] <bac> rvba: in the changes for https://code.launchpad.net/~rvb/launchpad/sync-bug-827608-credit-copy/+merge/74769 you've changed the ordering of the results, which will be visible in the on the browser page.  have you verified that doesn't cause confusion?
[14:11] <jml> You know, I think maybe REST isn't such a good idea.
[14:12] <cjwatson> Some of the callers may want to do an extra query for status='Pending' for the same reason wgrant lists above.
[14:12] <wgrant> jml: It's a great idea.
[14:13] <wgrant> jml: It just doesn't really work.
[14:13] <jml> wgrant: +1
[14:13] <jtv> Isn't that what mark said oh, pretty much off the bat years ago?  Me, I still don't know.
[14:14] <bigjools> anything involving xml sucks
[14:15] <wgrant> I am not seeing XML's involvement here...
[14:15] <jtv> I'll tell James next time I see him though.
[14:15] <bigjools> it's a general observation
[14:15] <nigelb> bigjools++
[14:16] <jtv> Not very often these days, but second-to-last time he said "I certainly hope I won't still be using XML in 10 years' time.  That would be kind of depressing."
[14:16] <jcsackett> i have just had to rebuild a system, and i'm getting gnomekeyring.IOError when i try to run ec2 test/land. i seem to recall this being a problem once upon a time -- anyone remember the issue?
[14:16] <nigelb> Has anyone tried Android development? Its Java and XML.
[14:16] <bigjools> xmlsucks.org
[14:16] <jml> jcsackett: not I, sorry.
[14:17] <jtv> nigelb: thanks for pointing that out.  Now I feel even better about my basic old nokia.
[14:17] <nigelb> jtv: I have a basic sony errikson :)
[14:17] <jtv> jcsackett: I've seen that… IIRC it was some package that you're assumed to have installed.
[14:17] <wgrant> jtv: Ah! I am glad it's not just me who doesn't have a smartphone.
[14:18] <jcsackett> jtv: hm. so now i must muddle through to find said package. at least it's a direction to investigate, thanks. :-)
[14:18] <jtv> wgrant: flexispy.com is one strong argument not to have a smartphone
[14:18] <nigelb> wgrant: So, the advantage of smart of being connected all the time. I don't think you stay away from the computer (ZING!)
[14:18] <wgrant> Heh
[14:18] <nigelb> *smartphone
[14:19] <nigelb> Too hasty to make a funny remark
[14:19] <jtv> jcsackett: I can dig up some more probably-unhelpful clues from my memory: it was something gnome and kde had their own packages for, and somehow it was assumed that you'd have it pulled in in one of those two ways.
[14:19] <jcsackett> jtv: so, i know that there's like the wallet and the manager, but i have the full gnome version of that.
[14:19] <jtv> jcsackett: now to find the python package…
[14:20] <jcsackett> aaah. it's not just paramiko, then.
[14:21] <jtv> bigjools: there's not much at xmlsucks.org
[14:21] <jtv> And by the way, nigelb: flexispy is also all Java and XML.
[14:21] <jtv> dumb is fine by me
[14:22] <nigelb> jtv: *stab*
[14:22] <jtv> aiigh!
[14:22] <bigjools> jtv: there used to be more
[14:33] <henninge> So, the launchpad-buildd runs on lucid but it requires bzr-builder >=0.5 which is not package in lucid. How do I solve that?
[14:34] <henninge> jtv: ^ do you have an idea about that?
[14:35] <henninge> I mean it must have been solved for our current builders somehow.
[14:35] <jtv> henninge: one of the bzr people may know.
[14:35] <henninge> yeah, I tried in #bzr ;)
[14:36] <jtv> or lamont may know.
[14:36] <wgrant> jelmer_: ^^
[14:36] <wgrant> Are the cat packages available in a PPA somewhere?
[14:36] <wgrant> There may be a PPA owned by ~launchpad or ~bzr for them.
[14:36] <bigjools> james has one IIRC
[14:36] <henninge> wgrant: yes, that's what I was hoping ;-)
[14:37] <wgrant> henninge: lp-buildd also works fine on maverick/natty, FWIW.
[14:37] <wgrant> And dapper and karmic.
[14:37] <henninge> ;)
[14:37] <henninge> but production buildd's run on lucid, right?
[14:38] <jtv> Oh God I can't take these soap series any more. I think I'll curl up with my kindle.  Have a good weekend, everyone!
[14:38] <wgrant> Uh. It's complicated.
[14:38] <bigjools> o/ jtv
[14:38] <wgrant> I forget what ia64/sparc/powerpc/hppa are running these days.
[14:38] <wgrant> henninge: But the virt builders should all be lucid, yes, and I guess that's all you care about.
[14:38] <henninge> jtv: see you next week
[14:39] <henninge> wgrant: I guess I do, yes. ;-)
[14:39] <henninge> but none of james's ppas has that.
[14:39] <wgrant> https://launchpad.net/~dailydebs-team/+archive/bzr-builder
[14:39] <wgrant> Oh.
[14:39] <wgrant> Actually, the virt builders might still be hardy...
[14:40] <wgrant> But anyway, the series doesn't matter too much.
[14:40] <henninge> wgrant: thanks
[14:40] <wgrant> Because all that's run outside the chroot is bzr-builder, basically.
[14:40] <jelmer_> wgrant: sorry, back now
[14:40] <wgrant> And that is heavily backported
[14:40] <jelmer_> henninge: the newer bzr-builder is in the cat archive
[14:41] <henninge> what is the cat archive?
[14:41] <jelmer_> henninge: and there is an even yet newer bzr-builder/bzr for the buildds which I have backported here and is due to land on the buildds at some point: ppa:canonical-bazaar/cat-proposed
[14:41] <jelmer_> henninge: an internal apt repository used by IS
[14:46] <jelmer_> henninge: ppa:bzr/daily should also have a newer bzr-builder for lucid
[14:47] <cjwatson> henninge: "Canonical Admin Team"
[14:48] <henninge> jelmer_: I feel stupid but where do I see these ppas in the web ui?
[14:48] <henninge> Also, I don't really want the latest, I just want >=0.5 ;)
[14:49] <jelmer_> the canonical-bazaar/cat-proposed PPA is private, the bzr daily PPA is here: http://launchpad.net/~bzr/+archive/daily
[14:51] <henninge> oh, +archive
[14:55] <henninge> jelmer_: I don't see bzr-builder in the ~bzr ppas :(
[14:56] <jelmer_> henninge: you're right - sorry. We don't seem to have a recipe for that, I'll see if I can add one
[15:01] <cjwatson> Can anyone explain http://paste.ubuntu.com/685964/ to me?  I don't understand it, and it doesn't seem to have much to do with my branch
[15:01] <cjwatson> Shouldn't the "..." match "api.launchpad.dev/beta"?
[15:03] <henninge> cjwatson: I think that is noise
[15:03] <henninge> This is probably the real culprit:
[15:03] <henninge>     - suite_names:
[15:03] <henninge>     -     [u'Release', u'Security', u'Updates', u'Proposed', u'Backports']
[15:03] <henninge>     ? ^^^
[15:03] <henninge>     + suite_names: [u'Release', u'Security', u'Updates', u'Proposed', u'Backports']
[15:03] <henninge>     ? ^^^^^^^^^^^^
[15:04] <henninge> No ... involved here.
[15:04] <henninge> Failing doctests suck.
[15:04] <cjwatson> That's odd though, because my branch doesn't touch anything that should change wrapping there AFAICS
[15:05] <cjwatson> I did add a column to distroseries, but why does that change wrapping ...
[15:05] <cjwatson> oh
[15:05] <cjwatson>     + include_long_descriptions: True
[15:06] <cjwatson> I bet *that's* the real culprit
[15:06] <henninge> cjwatson: yes, fooled again ...
[15:07] <henninge> Did I mention that "Failing doctests suck?"
[15:07] <henninge> So easy to miss stuff in all the noise.
[15:08] <jml> Hmm.
[15:08] <jml> I wonder why it does that.
[15:09] <jml> I bet it's because diff reporting doesn't interact with the NORMALIZE_WHITESPACE and ELLIPSIS options.
[15:09] <henninge> It always does that to me: One failure and it complains about all ellipsis in the file.
[15:10] <cjwatson> I suppose I'd better try to test that locally before resending to EC2
[15:10] <nigelb> adeuring: Hi, can you re-land this branch for me? Fixed the test https://code.launchpad.net/~nigelbabu/launchpad/destroy-statusexplanation-88545/+merge/74704
[15:10] <adeuring> nigelb: sure
[15:10] <jml> yeah.
[15:10] <nigelb> thanks!
[15:11] <jml> it just passes expected and observed to difflib
[15:11] <jml> with no processing on expected
[15:13] <jml> Hmm. Shouldn't be *too* hard to fix, actually.
[15:13] <jml> And by 'fix', I mean, "come up with a workaround that doesn't require patching the stdlib"
[15:17] <jelmer_> henninge: there is a daily build in progress now, should hopefully land in ppa:bzr-builder/daily within the hour
[15:19] <adeuring> nigelb: tests are running again
[15:20] <nigelb> adeuring: thanks, I'm branching db-devel :)
[15:20] <adeuring> nigelb: cool!
[15:27] <gary_poster> sinzui or flacoste, do either of you have a quick answer to this question from https://answers.launchpad.net/launchpad/+question/170633 : If someone is subscribed to a blueprint, should they "receive *all* notifications, including the blueprint information changes like the milestone target" or a limited subset?
[15:28] <sinzui> gary_poster, that is the wrong question :(
[15:28] <gary_poster> heh, I don't understand
[15:28] <flacoste> gary_poster: they only receive notifications about changes to the linked page
[15:28] <sinzui> gary_poster, blueprint subscriptions are neither
[15:28] <flacoste> if the linked wiki supports our "notification protocol"
[15:29] <flacoste> which is basically sending emails on update to notifications@blueprints.launchpad.net
[15:29] <flacoste> or something like that
[15:29] <flacoste> in other words, it probably only works for the Ubuntu wiki :-)
[15:29] <salgado> allenap, around?  (you're one of the people asked to review https://code.launchpad.net/~xaav/loggerhead/export-tarball/+merge/66408 that's probably awake now, so I thought I'd ask you).  the Linaro team would benefit from having a way to get the contents of a branch as a tarball, via the API.  we'd be using it for tiny branches (less than a hundred KB), but people might end up trying to use that on large branches and that may be a pro
[15:29] <salgado> blem.  so, my question is whether or not you think this could be accepted in LP
[15:30] <flacoste> salgado: i think ensemble wanted somthing similar
[15:30] <flacoste> salgado: there is a bug for that
[15:30] <gary_poster> flacoste, sinzui, got it.  Thank you
[15:30] <sinzui> gary_poster, The plans to create structural subscriptions never came to fruition, as you recall, they were moved to bug to be only about bugs
[15:30] <gary_poster> sinzui, ah, right got it
[15:30] <salgado> flacoste, the one I found was not about exposing it over the API, but maybe there is.  /me searches
[15:30] <allenap> salgado: I'll have a look.
[15:31] <salgado> flacoste, allenap, bug 515128 is the one I found
[15:31] <_mup_> Bug #515128: Launchpad should make tarballs of branches available for download <lp-code> <Launchpad itself:Triaged> < https://launchpad.net/bugs/515128 >
[15:31] <gary_poster> abentley, do you have any suggestions on how to field https://answers.launchpad.net/launchpad/+question/170639 ?
[15:32] <gary_poster> abentley, fwiw, I verified and what he describes does seem to be what's in the logs
[15:32] <flacoste> salgado: yes, that.s the one
[15:33] <abentley> gary_poster: we recommend using http with sourceforge as it seems a bit more reliable.
[15:33] <gary_poster> abentley, ah, I probably could have found that somewhere; that rings a bell.  sorry to bother & thanks
[15:33] <abentley> gary_poster: no problem.
[15:34] <salgado> thanks allenap!
[15:37] <allenap> salgado: It looks like mbp and wallyworld_ are happy with it. wallyworld_, fancy following up on your threat in https://code.launchpad.net/~xaav/loggerhead/export-tarball/+merge/66408? That is, the last comment, where you said you'd land it :)
[15:38] <jelmer_> abentley: I thought https worked better actually
[15:38] <salgado> allenap, do you think this could be made available on the API?
[15:38] <allenap> salgado: I mean, I don't have any problem with it. If people start downloading huge branches it /should/ time out and we'll get an OOPS report about it. I think that's okay.
[15:39] <allenap> salgado: Ah, okay, I missed that part of your request.
[15:39] <allenap> s/request/question/
[15:40] <salgado> allenap, would we really timeout? I thought we timed out only on long-running DB queries
[15:40] <allenap> salgado: I'm not sure that's a good idea. Perhaps it could be streamed into a librarian file and a reference to that returned.
[15:40] <abentley> jelmer_: I've heard the opposite, but I guess that could be wrong.
[15:42] <salgado> allenap, that would have to happen asynchronously, then?
[15:42] <allenap> salgado: It times out on requests too now, afaik. I'm not the right person to talk about that really; I don't know enough about where those time-outs are applied.
[15:43] <flacoste> salgado, allenap: only DB queries time outs
[15:43] <salgado> allenap, oh, ok, I'll bug flacoste then.  thanks anyway
[15:43] <flacoste> i think we had a few other place where we check the timeout
[15:43] <flacoste> but not through general python processing
[15:44] <salgado> flacoste, do you remember if what ensemble wants is to get the branch content via the API as well?
[15:44] <flacoste> salgado: yes
[15:44] <salgado> for formulas, I assume
[15:44] <flacoste> exactly
[15:44] <flacoste> so that they don't have to use bzr
[15:44] <flacoste> to retrieve the formula
[15:44] <flacoste> but fetch it directly using the API
[15:44] <allenap> flacoste: Ah, okay, so if there's a non-db process taking a long time - like exporting a branch tarball - it would never trip the time-out machinery?
[15:44] <flacoste> allenap: correct
[15:45] <flacoste> allenap: or worse, it would trip it after too long
[15:45] <salgado> flacoste, right. in our case we'd like to avoid bzr for private branches, so that we don't have to send private keys around
[15:45] <flacoste> so process for 2 minutes, then do a DB query (for session or whatever other housekeeping) and then timeout
[15:45] <allenap> flacoste: Are there any time-outs on the ha-proxy or Apache? I.e. if the response is not complete in X seconds it drops the connection?
[15:46] <flacoste> allenap: there is one on apache, but it's much higher
[15:46] <flacoste> which is fine
[15:46] <flacoste> since then the client can decide to take its time
[15:46] <flacoste> but the expansive server thread as been freed up at that time
[15:46] <flacoste> so we don't care
[15:46] <flacoste> or much less
[15:46] <allenap> flacoste: Yeah, but none between Apache/ha-proxy and the app servers?
[15:47] <flacoste> allenap: i don't know off the top of my head, a losa would know, not that it changes anything
[15:47] <flacoste> since zope will happily continue processing
[15:47] <flacoste> we'll know the connetion was close only when we attempt to write to the connection
[15:47] <salgado> flacoste, so, do you think we could make that available over the API now or would we need some way to prevent it from being used to download large branches?
[15:48] <allenap> flacoste: The loggerhead branch that exports tarballs expects to stream, I think, so a time-out on the app server connection would put a bound on that.
[15:48] <flacoste> salgado: we had tons of problem with streaming through the app server, we moved that to the librarian
[15:48] <nigelb> Hi, can I have a patch ID for a db patch?
[15:48] <flacoste> allenap: in that case, yes
[15:48] <flacoste> is this a loggerhead or launchpad patch?
[15:49] <salgado> flacoste, the existing one is loggerhead
[15:49] <gary_poster> abentley, any ideas on https://answers.launchpad.net/launchpad/+question/170658 ?
[15:49] <salgado> flacoste, that may work for ensemble, in fact
[15:49] <salgado> but not for us as we need to get the contents of private branches
[15:50] <allenap> flacoste: D'oh, that's not going to work for salgado. /me headdesks.
[15:50] <flacoste> salgado: why? loggerhead can be used with private branches
[15:50] <abentley> gary_poster: no, at first glance, I'd expect it to be linked.
[15:51] <allenap> flacoste: I think it's the proliferation of credentials that's a problem.
[15:51] <flacoste> how is it different than with API?
[15:51] <salgado> flacoste, yeah, but then I have to give the SSO credentials to my client and make it do OpenID, no?
[15:51] <salgado> with the API I can use OAuth
[15:51] <gary_poster> abentley, ok thanks.
[15:52] <salgado> which was better summarized by allenap. :)
[15:52] <flacoste> salgado: we could teach loggerhead to accept oauth auth
[15:52] <salgado> that could work
[15:52] <flacoste> salgado: or a way to get an api script to get an 'auth token' that will work to make loggerhead reqeuest
[15:53] <salgado> flacoste, loggerhead doesn't have access to LP's DB, right?  I was wondering if it'd be possible to use the LP OAuth credentials to authenticate on loggerhead
[15:54] <salgado> that'd be the ideal way, I think
[15:55] <flacoste> salgado: right, it doesn't have DB access, but the auth glue code might have
[15:55] <flacoste> that's the launchpad_loggerhead thing
[15:55] <salgado> but getting a separate loggerhead auth token via the LP API, although more cumbersome, would still be acceptable, I think
[15:55] <flacoste> i'm not that familiar with it
[15:55] <salgado> ok, I'll have a look at that
[15:56] <salgado> thanks flacoste and allenap!
[15:57] <allenap> salgado: I think there's some support for general one-time tokens in Launchpad already, so half a solution might already be there.
[15:58] <salgado> oh, cool, that's good to know
[15:59] <gary_poster> flacoste, response from that blueprints notifications discussion:
[15:59] <gary_poster> """Could you point me to the people behind the Ubuntu wiki changes (notification protocol support). That's probably something that we would like to have on Linaro's wiki (using moinmoin)."""
[15:59] <gary_poster> flacoste, should I ask them to file a bug, or is there something quic we can do for them?
[16:01] <flacoste> gary_poster: https://help.launchpad.net/Blueprint#Subscribing_to_blueprints
[16:01] <gary_poster> flacoste, fantastic thanks
[16:02] <flacoste> i think that page needs update as it's  likely the email is now  notifications@blueprints.launchpad.net
[16:02] <flacoste> although there is still a MX record for specs.launchpad.net
[16:03] <gary_poster> flacoste, are you confident enough on that that I shuld change the help wiki?
[16:03] <gary_poster> should
[16:03] <flacoste> gary_poster: i'm checking the code :-)
[16:03] <gary_poster> ah, ok :-)
[16:09] <flacoste> gary_poster: no, it's still configured as specs.launchpad.net
[16:09] <flacoste> config value: launchpad/specs_domain
[16:09] <gary_poster> ok cool thanks flacoste
[16:09] <allenap> salgado: What's going to happen next? Are you going to file a bug, or will someone else request this formally? If you're expecting something from me, tell me :)
[16:10] <gary_poster> allenap, so unreasonable :-P
[16:11] <allenap> :)
[16:11] <salgado> allenap, oh, don't worry about that; I'll investigate and see if we're going to pursue this further or just pass SSH keys around
[16:11] <allenap> salgado: Cool, awesome.
[16:13] <gary_poster> abentley, I changed the sourceforge import I mentioned to you before to http, and got a different error: http://launchpadlibrarian.net/79436540/zorba-coders-zorba-sf-trunk.log
[16:13] <gary_poster> does that mean http is not enabled on sourceforge for this branch, or something else?
[16:18] <nigelb> ohai, I asked earlier but didn't get a response. Can someone give me a patch number for a db patch?
[16:18] <gary_poster> nigelb, only stub can AFAIK.  Make a mp against db-devel and ask specifically for his review (Stuart Bishop)
[16:19] <gary_poster> at least...that
[16:19] <gary_poster> 's how it used to work...
[16:19] <nigelb> https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess tells that anyone in ~launchad can do the patch ID thing
[16:19] <nigelb> I can't make an MP without having a file to make changes in.
[16:22] <gary_poster> nigelb, ok, hadn't seen that.  I'll do it for you, gimme a sec
[16:25] <gary_poster> nigelb, I need a comment to describe what the patch does.  Short, like "Add tables for a package symbol database" or "BugMessage.owner NOT NULL"
[16:27] <nigelb> gary_poster: "Deleting the statusexplanation column
[16:27] <nigelb> "
[16:27] <gary_poster> ack nigelb, thx
[16:31] <gary_poster> nigelb, FWIW, the doc I changed had info that seemed like it was geared toward the patch writer.  It is here, if you'd like to take a glance at some advice: http://pastebin.ubuntu.com/685999/ .  Meanwhile, your patch number is 2208-84-1
[16:31] <jml> Hmm.
[16:31] <gary_poster> (I assumed that your patch would be fastdowntime-compatible, and not require a full old-style system outage; if it did, the last digit would be 0, and you would be asked lots of pointy questions :-) )
[16:31] <jml> Actually, it's more annoying than I thought, because the ellipsis can span multiple lines.
[16:31] <jml> Still, you can get something useful.
[16:32] <nigelb> gary_poster: it is fast downtime compatible. I spoke to stub the other day about it
[16:32] <nigelb> gary_poster: Thanks btw :)
[16:33] <gary_poster> welcome :-)
[16:50] <nigelb> mtaylor: Congrats on the OpenStack Policy Board elections :)
[16:56] <mtaylor> nigelb: thanks!
[17:10] <abentley> mtaylor: I've actually been hacking around with canonical's private openstack recently, trying to our test suite faster with parallelization.
[17:11] <mtaylor> abentley: awesome
[17:11] <mtaylor> abentley: how's that been going?
[17:13] <abentley> mtaylor: I've run some tests in parallel, but not gotten the whole suite to run yet.  And I just found out about cloud-init, which I'm hoping will make it easier to set up the instances.
[17:13] <mtaylor> indeed. I haven't used cloud-init myself, but SpamapS tells me it's awesome
[17:16] <abentley> mtaylor: if it does what it says on the tin, it'll allow me to parameterize the worker nodes with the current master's IP address.
[17:19] <mtaylor> that's what I hear
[17:22] <nigelb> Hrm, I don't know how db-devel is supposed to work.
[17:22] <nigelb> make schma asks me to run link-external-sorucecode
[17:23] <nigelb> When I run it, it says
[17:23] <nigelb> link-external-sourcecode: error: Parent branch not specified, and could not be discovered.
[17:23] <abentley> nigelb: you need to specify the branch you want to link the sourcecode from, typically your branch of stable or devel.
[17:23] <nigelb> ah
[17:29] <jml> OK.
[17:29] <jml> So basically doctest is terrible.
[17:37] <abentley> jml: yes.  Yes, it is.
[17:37] <nigelb> kill it with fire? :)
[17:40] <abentley> deryck: So my problem was a stale socket, "/var/run/launchpad_forking_service.sock".  Suggestions on how to deal with this better?
[17:40] <jml> http://code.mumak.net/2011/09/doctest-really-isnt-very-good.html
[17:40] <jml> thoughts and suggestions welcome
[17:40] <jml> disagreement will be dealt with according to its desserts.
[17:46] <deryck> abentley, the code hosting issue was a stale socket?
[17:46] <abentley> deryck: yes.
[17:46] <deryck> abentley, from a crash, I assume, and not left behind from a normal ctrl-c?
[17:46] <nigelb> I need some postgres help :/
[17:46] <nigelb> tsvectorupdate BEFORE INSERT OR UPDATE ON bugtask FOR EACH ROW EXECUTE PROCEDURE ftiupdate('targetnamecache', 'b', 'statusexplanation', 'c')
[17:47] <nigelb> what does that do?
[17:47] <nigelb> Or rather, how do I found out what it does.
[17:47] <abentley> deryck: i assume so.  Possibly a kill -9
[17:48] <cjwatson> Could somebody feed https://code.launchpad.net/~cjwatson/launchpad/multiarch-translations/+merge/74743 to EC2 again?  The doctest that failed last time passes now.
[17:49] <deryck> abentley, if it's a kill -9, not sure.  otherwise, so some sort of exit handler to clean up itself?
[17:49] <deryck> cjwatson, I'll send it off now for you.
[17:49] <cjwatson> thanks!
[17:50] <abentley> deryck: I'd like it to either fail noisily and clearly, or remove the stale socket and succeed.
[17:54] <jml> cjwatson: fwiw, I just spent a chunk of time trying to make those errors more decipherable. It's harder than I thought.
[17:56] <abentley> deryck: or perhaps use a random socket.
[17:56] <deryck> that could work
[18:21] <nigelb> hrm, when I do \d bugtask in psql, I get the table as public.bugtask
[18:22] <nigelb> Does this mean in my db patch I should do alter table public.bugtask and not just bugtask?
[18:43] <flacoste> nigelb: nah
[18:43] <flacoste> public is the default namespace
[18:43] <flacoste> in pgsql
[18:43] <nigelb> aaaaah
[18:43] <nigelb> I need to spend a weekend reading up postgres.
[18:43] <nigelb> I wish there were more hours in a day.
[18:46] <nigelb> flacoste: Is something wrong with Launchpad emails/notifications?
[18:46]  * nigelb sees delays
[18:46] <flacoste> nigelb: not that i know of, what makes you say this?
[18:47] <nigelb> Maybe its PEBKAC, checking :)
[18:53] <nigelb> flacoste: Yep, PEBKAC :D
[18:53] <flacoste> glad that's the case :-)
[18:54] <nigelb> Hrm, really need to be able to batch team additions and deletions.
[18:54] <nigelb> Oh wait. No. I'll end up doing it.
[18:58]  * deryck is switching work locations, back online in 30 minutes
[18:59] <nigelb> gah.
[18:59] <nigelb> I broke something.
[19:00] <nigelb> make newsampledata failed.
[19:34] <sinzui> jcsackett, do you have time to mumble?
[19:44] <nigelb> \o/ Test bassed.
[20:04] <abentley> bac: could you please review https://code.launchpad.net/~abentley/launchpad/simplify-twisted-runner-3/+merge/74868 ?
[20:05] <bac> abentley: sure.  let me wrap up CHR and then i'll get to it.
[20:05] <abentley> bac: thanks.
[20:08] <bac> abentley: done.  thanks.
[20:19] <nigelb> Hrm, are we in testfix?
[20:23] <jcsackett> sinzui: I'm actually on the road; had a half day today. If you want to ring my cell tho I can talk.
[20:23] <sinzui> jcsackett, sorry. I forgot
[20:24] <sinzui> have a nice day
[20:25] <jcsackett> No worries, and thanks. Have a good weekend.
[23:38] <wgrant> abentley: That TwistedJobRunner branch solves the massive NoneType response tracebacks we get sometimes?
[23:50] <nigelb> wgrant: ohai
[23:51] <wgrant> nigelb: Hi.
[23:51] <nigelb> wgrant: I have a doubt for a db patch
[23:52] <nigelb> I ran into trouble with the fti trigger
[23:52] <wgrant> Ah, that searches statusexplanation?
[23:52] <nigelb> tsvectorupdate BEFORE INSERT OR UPDATE ON bugtask FOR EACH ROW EXECUTE PROCEDURE ftiupdate('targetnamecache', 'b', 'statusexplanation', 'c')
[23:52] <nigelb> ^^ that one
[23:53] <wgrant> So, fti is the thing most in limbo right now.
[23:53] <wgrant> The script that maintains it (database/schema/fti.py) is not run any more.
[23:53] <wgrant> Because it has to be done during downtime, but can take too long.
[23:53] <nigelb> oh.
[23:53] <wgrant> So you should talk to stub about this.
[23:53] <nigelb> okay :)
[23:53] <wgrant> We may have to fix fti.py to just maintain the triggers, without actually rebuilding the data.
[23:54] <nigelb> THe "psql launchpad_ftest_playground -f your-patch.sql" step ran into trouble because of this
[23:54] <nigelb> so, not sure how far I'll get
[23:54] <nigelb> But looks like I need to catch stub on Monday.
[23:54] <nigelb> so this branches goes onto hold mode :)
[23:55] <nigelb> wgrant: Also. Are we in testfix?
[23:55] <wgrant> nigelb: We are.
[23:56] <wgrant> But I just got the buildbot slaves cleaned up, and forced the builds.
[23:56] <nigelb> Cool. That explains that.
[23:56] <nigelb> Yay!
[23:56] <wgrant> You've got something that needs landing?
[23:56] <nigelb> Its finished tests
[23:56] <nigelb> so, I guess your buildbot cleaning should fix it.
[23:57] <wgrant> It won't automatically reland.
[23:57] <nigelb> oh.
[23:57] <nigelb> https://code.launchpad.net/~nigelbabu/launchpad/destroy-statusexplanation-88545/+merge/74704
[23:57] <wgrant> Could you forward me the ec2 mail?
[23:58] <nigelb> Done