[00:13] <lifeless> sinzui: bug 704662
[00:13] <_mup_> Bug #704662: karma is not updating <Launchpad itself:Triaged> < https://launchpad.net/bugs/704662 >
[01:17] <spiv> james_w`: Awesome: http://package-import.ubuntu.com/status/libbase-openoffice.org.html#2011-01-19%2001:13:13.621831
[01:19] <spiv> In fact it appears the package importer is encountering lots of issues...
[01:24] <LPCIBot> Project db-devel build (313): STILL FAILING in 5 hr 12 min: https://hudson.wedontsleep.org/job/db-devel/313/
[01:58] <kb9vqf> Soo...if my Postgresql database has suddenly sprouted duplicate rows after a disk failure, what is the best way to remove them>
[01:58] <kb9vqf> ?
[01:59] <kb9vqf> ^^^ This is in libraryfilealias
[02:00] <kb9vqf> I had been attempting to use this (gleaned from a repair article online) but execution never terminated: http://ubuntu.pastebin.com/53SXyuBq
[02:01] <kb9vqf> Any help is greately appreciated :-)
[02:01]  * kb9vqf cannot type tonight; sorry
[02:01] <spm> if you've had a disk failure, would you be better off going back to a known good state from backups?
[02:01] <spm> not sure I'd ben keen to trust any database state after a disk failure has corrupted it.
[02:02] <lifeless> kb9vqf: if you have a corrupt db, I'd definitely restore :)
[02:02] <kb9vqf> spm: Yes, if the most recent backups weren't several months old :-P
[02:03] <lifeless> rolling forward is likely to be World Of Pain
[02:03] <kb9vqf> The backup script failed silently
[02:03] <kb9vqf> So far the only table with damage is libraryfilealies
[02:03] <lifeless> well
[02:03] <kb9vqf> And I wonder if the damage is limited to the indecies
[02:03] <lifeless> the only table you can *tell* has damage so far
[02:03] <kb9vqf> Yes
[02:04] <kb9vqf> I've been running this install with the damaged tables for a while and I haven't noticed any malfunctions
[02:04] <kb9vqf> The only thing is that the reindex always fails
[02:04] <kb9vqf> (due to the duplicate rows)
[02:06] <kb9vqf> Is there a way to clear the Postgresql indexes?
[02:06] <lifeless> we're really not postgresql gurus
[02:06] <spm> drop and recreate, but the data being used to generate them is corrupt; so... :-/
[02:06] <lifeless> our approach to such corruption and failure would be a restore
[02:06] <lifeless> #postgresql is much more likely to have folk that can give more sophisticated solutions
[02:07] <kb9vqf> OK, thanks :-)
[02:07] <kb9vqf> I appreciate the pointers
[03:12] <kb9vqf> lifeless: If it comes up here again, the solution is to use pgAdmin III (or other admin tool) to make an SQL dump of the database, then drop the database in single-user mode and reload it with psql
[03:12] <kb9vqf> As long as this is done BEFORE the system tables are reindexed, it will work
[12:52] <maxb> Hmm. I think it would be useful to have another state for code imports
[12:52] <maxb> We currently have Failed Suspended and Invalid
[12:53] <maxb> It would be nice to subdivide Failed into new failures and triaged failures
[12:54] <maxb> Neither fit in Suspended/Invalid, because any user should be able to retry a triaged failed import
[13:20] <thumper> maxb: I think the intent was that triaged failures are suspended
[13:20] <thumper> maxb: and thanks for the continued import help :)
[13:21] <maxb> I guess so - the problem being that having just looked at a couple of imports and found that they are failing because someone's dyndns.org address is currently offline, I don't want to suspend them and bar them from initiating a retry
[13:22] <thumper> ah...
[13:22] <thumper> maxb: can't you just leave it as failed?
[13:23] <maxb> can do. But we're doing pretty well at driving the "Failed" status for bzr-svn/git down to "things we should fix"
[13:58] <lifeless> matsubara: btw lp-oops web ui is a bit gnarly right now
[14:31] <matsubara> lifeless, will look into it after breakfast
[14:51] <poolie> lifeless, i would love to hear your thoughts on my twisted api braindump
[14:54] <lifeless> poolie: where is it?
[14:55] <poolie> on launchpad-dev
[14:55] <poolie> uh "notes towards async api clients"
[15:19] <cody-somerville> poolie, I hope your idea isn't to replace the current launchpadlib with that.
[15:41] <bac> https://docs.google.com/a/canonical.com/document/d/19nOrInYTuwrIFiL5WS7PSqz-GnoStrr5LbBr_avDf-I/edit?hl=en#
[17:01] <LPCIBot> Project db-devel build (316): FAILURE in 5 hr 7 min: https://hudson.wedontsleep.org/job/db-devel/316/
[17:01] <LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12226
[17:01] <LPCIBot> included.
[18:15] <james_w`> mpt, jml: http://people.canonical.com/~jamesw/workitems/natty.old/
[18:17] <matsubara> lifeless, https://lp-oops.canonical.com/oops.py/ works again
[18:21] <lifeless> thanks!
[18:22] <jml> huwshimi: https://dev.launchpad.net/IssueTracker
[18:24] <jcsackett> jml: the issuetracker idea doesn't include answers?
[18:24] <jml> jcsackett: not yet
[18:24] <jcsackett> jml: huh. that's how it keeps being explained to me. was surprised to see it's not part of the entry.
[18:39] <thumper> leonardr: https://code.launchpad.net/~leonardr/lazr.restful/fix-remove-recipe/+merge/24423
[18:39] <thumper> leonardr: https://code.launchpad.net/lazr.restful/+activereviews
[18:46] <leonardr> benji: do you know that https://code.launchpad.net/~benji/lazr.restful/bug-539070/+merge/40003 wasn't merged into lazr.restful?
[18:49] <leonardr> gary: same for you, for https://code.launchpad.net/~gary/lazr.restful/bug691841/+merge/46312
[18:49] <leonardr> i'm happy to merge both of those if you say the word--i'm assuming you're not holding off for some reason
[18:51] <gary_poster> looking leonardr
[18:53] <gary_poster> leonardr: you can land mine, thank you
[18:53] <leonardr> will do
[18:54] <benji> leonardr: I was vacillating between adding a little bit more to it or landing it as is, but it's gone long enough that it should just be landed.  If you feel inclined to land it, I would appreciate it.
[18:55] <lifeless> btw - https://code.launchpad.net/launchpad-project/+activereviews - all our reviews
[18:55] <leonardr> benji: will do
[19:01] <leonardr> benji, gary, you are merged
[19:01] <benji> leonardr: thanks!
[20:00] <lifeless> jam: did you find dendrobates?
[20:00] <jam> lifeless: I did not
[20:00] <lifeless> mtaylor: ping
[20:00] <jam> I found his user name on #ubuntu-devel but no response
[20:18] <gmb> leonardr: I'm having some trouble exposing something in the WS API, do you have a second to let me pick you brain?
[20:19] <leonardr> gmb, sure, i need a minute
[20:19] <leonardr> where are you? i'll come over
[20:19] <gmb> leonardr: Vinoy
[20:19] <gmb> Thanks.
[20:23] <lifeless> hey
[20:23] <soren> o/ again.
[20:23] <lifeless> so the user is 'sleepsonthefloor'
[20:23] <soren> Let me check our Hudson/tarmac box.
[20:23] <soren> Oh.
[20:24] <lifeless> I'm told it looks openstack related
[20:24] <lifeless> its connecting once every 6 seconds or so
[20:24] <soren> Very likely is. sleepsonthefloor is one of the NASA guys.
[20:24] <soren> Crikey.
[20:24] <soren> What's the IP?
[20:25] <lifeless> jam: ^
[20:25] <soren> It's not our Hudson box.
[20:27] <lifeless> soren: thats good to know
[20:27] <soren> lifeless: I'm trying to get a hold of him
[20:27] <lifeless> jam did the investigation, he'll know the ip or where to look; gimme a sec to chase him down
[20:27] <jam> soren: 173.203.89.94
[20:27] <lifeless> ah^ there we go
[20:28] <spiv> lifeless: I chased him down first :P
[20:28] <spiv> lifeless: admittedly he's right next to me so I had a wee bit of a head start...
[20:30] <soren> lifeless, jam: I'll chase down some people.
[20:30] <lifeless> we don't mind being used...
[20:31] <jam> soren: thanks. I don't think it is a problem if there is a real need (many launchpad services connect about 4k times per day)
[20:31] <jam> but it seemed odd to go from about 5 connections per day to 11k for a given user
[20:31] <soren> jam: Oh, these are not 11K open connections?
[20:31] <soren> But 11K over the course of a day?
[20:31] <jam> soren: right
[20:31] <lifeless> soren: serial, yes
[20:31] <soren> Oh, ok.
[20:31] <lifeless> soren: seems like something in a tight loop
[20:31] <jam> I'm not sure if it is strictly serial, vs small concurrency
[20:31] <lifeless> ^
[20:33] <jam> soren: Looking over the logs by eye I don't see concurrent connections yet
[20:34] <soren> Probably not.
[20:34] <soren> It seems it's a build server that polls in a tight loop. They're waiting for sleepsonthefloor to get back from lunch to fix it :)
[20:35] <lifeless> soren: can they tune it down a little? They could subscribe to the branch to get a notification when it changes (so little need to poll at all)
[20:35] <lifeless> would be delighted to talk requirements with them
[20:35] <soren> lifeless: I'm sure it's a mistake.
[20:36] <lifeless> cool
[20:36] <jam> we could give an HTTP url for the branch/last_revision file that you could also monitor, more cheaply than ssh handshaking :)
[20:36] <lifeless> as jam says if its needed, we can figure out how to support it
[20:36] <soren> lifeless: ...but when you say subscribe, you mean subscribe to e-mail notifications? Or something cooler?
[20:36] <lifeless> soren: today sadly I just mean email
[20:36] <lifeless> I *want* to do PSHB
[20:36] <soren> lifeless: Ok :)
[20:36] <soren> lifeless: Yeah.
[20:37] <gary_poster> stub: https://code.launchpad.net/~gary/launchpad/structuralsubscriptions/+merge/46822
[20:58] <bigjools> gary_poster: is ++profile++ working on staging/qastaging?
[20:59] <gary_poster> bigjools: no, only on devel.
[20:59] <bigjools> ok thanks
[20:59] <lifeless> bigjools: future work that gary_poster was mentioning late last week
[20:59] <gary_poster> yeah
[20:59] <gary_poster> not that hard
[20:59] <gary_poster> want to make ++profile++download
[21:00] <gary_poster> but not necessary
[21:01] <bigjools> lifeless, wgrant: have you looked at reducing the query count in the package copier perchance?
[21:02] <lifeless> wgrant was in fact looking around that area
[21:02] <bigjools> I am wondering whether to tackle it now or leave it if someone already started
[21:23] <wgrant> bigjools: I have some ideas.
[21:23] <wgrant> I know roughly what needs to be don.
[21:48] <benji> gary_poster: https://dev.launchpad.net/yellow/Subscriptions
[22:11] <mpt> huwshimi, https://dev.launchpad.net/AlertMessages
[22:11] <LPCIBot> Yippie, build fixed!
[22:11] <LPCIBot> Project db-devel build (317): FIXED in 5 hr 10 min: https://hudson.wedontsleep.org/job/db-devel/317/
[22:12] <LPCIBot> * Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12229,
[22:12] <LPCIBot> 12230 included.
[22:12] <LPCIBot> * Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12227,
[22:12] <LPCIBot> 12228 included.
[22:36] <leonardr> rockstar, do i remember you working on bug 316694 around the time of the prague meeting?
[22:36] <_mup_> Bug #316694: Add web_link property to resources <launchpadlib :Triaged> < https://launchpad.net/bugs/316694 >
[22:37] <leonardr> if so, what happened to it?
[22:38] <rockstar> leonardr, I may still have the branch around here.  I made the change, but it broke a bunch of tests that you said were very low-level, and that's where it died (because the week ended, and I lost "free time")
[22:38] <leonardr> rockstar: ok, we are starting to feel the need again. can you find the branch for me?
[22:39] <rockstar> leonardr, yeah, it's going to be on an old backup unless I've pushed it.  Let me do some mining.
[22:39] <leonardr> rockstar, thanks
[22:39] <leonardr> just knowing where to start would be helpful
[22:45] <mpt> Daviey, are you the one who's maintaining the UDS scheduler tool now?
[22:45] <mpt> Or am I confusing you with someone else/
[22:45] <mpt> ?
[22:46] <lifeless> danilos: ping
[22:46] <lifeless> danilos: could you eyeball bug 705129 and suggest whether its operational or a bug ?
[22:46] <_mup_> Bug #705129: Nightshade import queue don't work <Launchpad itself:New> <Nightshade:New> < https://launchpad.net/bugs/705129 >
[22:48] <danilos> lifeless, it's kinda both... it's a bug that LP doesn't automatically approve the files with the names it exports them with (which are those in the queue), but when people come to us we can fix this quickly through the UI for them (so it's operational as well)
[22:49] <lifeless> danilos: are there docs somewhere for lp devs? (e.g. what should I do here?)
[22:51] <danilos> lifeless, https://help.launchpad.net/Translations/YourProject/ImportPolicy though you might not have permissions to act on it operationally
[22:51] <danilos> lifeless, we can add everyone in LP team to rosetta-admins to solve that though
[22:52] <lifeless> danilos: perhaps add the ~launchpad team itself ?
[22:52] <danilos> lifeless, right, that's what I meant
[22:53] <lifeless> kk
[22:54] <lifeless> danilos: might be nice to describe where the queue is on that wiki page (for admins)
[22:54] <danilos> lifeless, yes, there's still quite some work for the hand-off of this that previous translations team needs to do
[22:56] <lifeless> gmb: danilos: hi
[22:56] <lifeless> please don't use Storm
[22:56] <lifeless> we need the same invalidator SQLBase has.
[22:56] <lifeless> I'm updating the wiki page now.
[22:59] <danilos> lifeless, if we need to use cachedproperties on that object, I'd say yes... if not, I don't think why we should pretend to know what are we going to do with this object; fwiw, it's easier to switch stuff back to SQLBase than it is to switch it to Storm
[23:01] <Daviey> mpt, I am a commiter, but i've been trying to hand over the burden somewhat.
[23:01] <lifeless> I guess I'm worried that folk will use cachedproperty on any model class thinking its safe - becuase it is safe with any SQLBase class
[23:02] <mpt> Daviey, could you give me the URL of the LP project? I've forgotten it since UDS. :-)
[23:02] <lifeless> It would be nice to have it safe for all model classes, which just needs a similar base class to SQLBase, and us to not directly use s.b.Storm
[23:02] <lifeless> OTOH you're right that its unnecessary overhead if we're not using it.
[23:02] <Daviey> mpt, lp.net/summit :)
[23:02] <mpt> ahhhh, summit
[23:02] <mpt> I knew it was summit like thaht
[23:03] <danilos> lifeless, why not have a SafeStorm (stupid name, but you get the idea) which just provides that for any cachedproperties
[23:03] <mpt> thanks Daviey
[23:03] <lifeless> danilos: Do you think folk will remember to look at the base class?
[23:03] <danilos> lifeless, not too sure about that
[23:03] <lifeless> danilos: My *tendancy* would be to have a SafeStorm and use it everywhere by default; using raw Storm if we have a reason to do so.
[23:04] <lifeless> danilos: what do you think?
[23:04] <StevenK> StormBase or ... (bad pun incoming) Cloud
[23:04] <lifeless> StormCloud!
[23:04] <StevenK> I like it!
[23:05] <Daviey> mpt, I bet you have a metric tonne of usability bugs, right? :)
[23:07] <mpt> Daviey, none at all. The biggest annoyance I have with Summit is where people hide the meaningful words in a session title toward the end of the title.
[23:12] <mtaylor> lifeless: pong
[23:14] <danilos> lifeless, yeah, +1 on that
[23:14] <danilos> lifeless, not the Cloud naming though :))
[23:14] <danilos> lifeless, CloudyStorm, perhaps...
[23:18] <sinzui> huwshimi, http://pastebin.ubuntu.com/556006/
[23:18] <leonardr> rockstart: ping, hope you haven't been mining this whole time
[23:18] <leonardr> rockstar -^
[23:19] <rockstar> leonardr, no, but I have been.  I found a bug in Launchpad's search as well.  :)
[23:19] <leonardr> is this it? https://code.launchpad.net/~rockstar/lazr.restful/web_link
[23:19] <rockstar> leonardr, web_link! Yes, that's it.
[23:20] <rockstar> I was looking for a launchpad branch for some reason.
[23:20]  * leonardr just went to your page of lazr.restful branches
[23:20] <rockstar> Of course, it's one of the few lazr.restful branches I've ever had...  :)
[23:21] <leonardr> ok, i'll take a look
[23:23] <leonardr> rockstar: you don't have any _revisions_ to that branch
[23:23] <leonardr> it's just trunk (as of when you pushed it)
[23:23] <StevenK> wgrant: I just noticed something amusing. Remember that bit of the doctest I was asking about?
[23:24] <rockstar> leonardr, okay, lemme get in the backup.
[23:24] <lifeless> danilos: could you perhaps add that in your branch? r=me for it, and then noone else needs to think. I'll happily update the wikipage with whatever name you choose
[23:24] <StevenK> wgrant: It has oldest_spr = publisher.getPubSource(...) -- except that getPubSource() returns an SPPH :-)
[23:24] <lifeless> danilos: I hate to ask you to add this but it makes me nervous is all
[23:24] <lifeless> mtaylor: see discussion w/soren
[23:25] <danilos> lifeless, we have other Storm classes, and I think it'd be better to have a single push to have them all fixed
[23:26] <danilos> lifeless, preferably in the same branch, and definitely not in this one; if I was exactly sure how to achieve what you want, I'd probably do it before we sign off for the day
[23:26] <mtaylor> lifeless: ok.
[23:27] <danilos> lifeless, I'd be happy to be convinced tomorrow to do it, so let's talk tomorrow morning about it
[23:28] <mtaylor> lifeless: well. I certainly support some form of non-email notification... and I'm _still_ trying to get someone to fund someone to write a lpapi java binding so I can use lp-api to check things from hudson (but it seems to keep getting lost in corporate land somewhere)
[23:28] <wgrant> StevenK: Heh.
[23:33] <allenap> mpt: With some help from a friendly DBA, I figured out that the figures in several of those tables are counts of all specifications, not just those in the last year. Would you prefer the all-time counts for the top-50-specs-users-in-the-last-year, or the last-year counts?
[23:34] <mpt> allenap, last-year for everything would be most helpful I think
[23:34] <allenap> mpt: Cool, will have that soon.
[23:34] <mpt> thank you allenap
[23:45] <rockstar> leonardr, just pushed the changes.
[23:47] <leonardr> rockstar, great
[23:53] <leonardr> rockstar: thanks, this looks exactly like what i was writing
[23:53] <leonardr> so, let's see what's the deal w/the tests
[23:53] <rockstar> leonardr, great.
[23:53] <rockstar> leonardr, if you fix this, you'll help us remove a significant amount of code in Tarmac.
[23:55] <leonardr> rockstar: this doesn't look too bad? do you remember anything else i said about the test failures?
[23:55] <rockstar> There are test failures, as I recall.  The failures were caused in tests that were testing at a very low level, I think.
[23:56] <leonardr> i guess webservice.txt is pretty low level
[23:56] <leonardr> but ultimately i think the fix is pretty simple
[23:58] <leonardr> i'll give it a try