[00:16] <lifeless> mtaylor: hi ?
[00:34] <mtaylor> hi lifeless
[00:41] <lifeless> mtaylor: what can I do for yo u?
[00:42] <mtaylor> lifeless: well, I was going to chat with you about the possibility of having branch links in bugs be able to point to external branches
[00:42] <mtaylor> lifeless: talked with thumper about it a little bit
[00:42] <mtaylor> lifeless: he indicated that it would not be trivial, which I kindof figured
[00:42] <lifeless> well
[00:43] <lifeless> so the key thing is that we currently have two sorts of remote branch
[00:43] <lifeless> 'imports' and 'mirrors'
[00:43] <lifeless> jelmer is -right now- nuking 'mirrors' so we will only have 'imports', which includs just-copy-a-bzr-branch
[00:43] <lifeless> I don't think we want 'a branch we know about but cannot read the data from'
[00:44] <mtaylor> are imports one-time imports?
[00:44] <lifeless> so it should be trivial - register the branch from your gerrit integration scripts, and reference it thereafter
[00:44] <lifeless> mtaylor: no
[00:44] <mtaylor> ok. cool
[00:44] <lifeless> mtaylor: but tuning the import system to deal with branches that get deleted, and or have a way to massively dial back the probing when a branch goes quiet - those are good things in their own right
[00:45] <mtaylor> yes. I imagine that they are - also probably dealing with rebases of those too, if you don't already
[00:45] <lifeless> I need to pop out for a quick grocery trip; will respond to anything more upon my return :)
[00:45] <mtaylor> k. I'm good for now
[00:47]  * wallyworld_ has to go and pick up dog. back soon
[00:48] <lifeless> rebasing should be fine
[00:48] <lifeless> -> gone
[01:20] <lifeless> back
[01:24] <lifeless> mtaylor: oh there is something
[01:24] <mtaylor> lifeless: mmyesss?
[01:25] <lifeless> mtaylor: can you pull in the fd fix for the jenkins bazaar plugin ? I haven't gotten setup on git for that yet...
[01:25] <lifeless> bazaar-plugin/pull/6
[01:25] <lifeless> https://github.com/jenkinsci/bazaar-plugin/pull/6
[01:25] <mtaylor> lifeless: it's already merged - I just need to release it
[01:26] <lifeless> mtaylor: ... Do....It....Please...?
[01:26] <mtaylor> lifeless: a) do you need me to give you push access on that? and b) have you tested the tree sufficiently so that you are satified with me releasing it?
[01:26] <lifeless> mtaylor: there are a couple others there too I think. Or maybe I'm thinking of platformlabeler
[01:26] <mtaylor> lifeless: I also added lightweight checkout support in the tree ...
[01:26] <mtaylor> but haven't tested extensively
[01:27] <lifeless> mtaylor: I don't know if I do/don't have push access there. If I don't, I think I would probably be more useful with it...
[01:27] <lifeless> rbtcollins on github
[02:43] <spm> rbtcollins ?? Robert ... Bloody Terrific Collins?
[02:47] <lifeless> yes, yes indeed
[02:50] <LPCIBot> Project db-devel build #801: STILL FAILING in 6 hr 12 min: https://lpci.wedontsleep.org/job/db-devel/801/
[03:59] <LPCIBot> Project devel build #965: STILL FAILING in 6 hr 29 min: https://lpci.wedontsleep.org/job/devel/965/
[05:07] <StevenK> lifeless: Still getting that oops rubbish
[05:07] <StevenK> lifeless: And wgrant hit it last night too
[05:08] <StevenK> However, my Storm release hit devel and it's stopped whinging about that at least
[05:10] <lifeless> cool
[05:11] <lifeless> the oops thing is bizarre
[05:11] <lifeless> it should be temporary - I hope to have that oops stuff fully removed earliy next week
[05:12] <StevenK> lifeless: Can haz DB patch number?
[05:14] <lifeless> self service!
[05:14] <StevenK> Eh?
[05:14] <StevenK> I can do that?
[05:14] <lifeless> https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess
[05:14] <lifeless> you might like to refresh your memory, cause it has been changed ;)
[05:15] <lifeless> (and announced to tl's who were meant to point everyone at it :P)
[05:15] <lifeless> https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess#Patch ids
[05:15] <lifeless> is the specific bit you need
[05:15] <StevenK> lifeless: Oh, so, should I add some indinces to this patch?
[05:16] <StevenK> lifeless: (I'm adding SPN and BPN to SPPH and BPPH)
[05:18] <lifeless> you'll need two patches
[05:18] <lifeless> see https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess#Background
[05:18] <lifeless> (yes, we will almost certainly need some indices :P)
[05:19] <StevenK> I see that I can't do ALTER TABLE live
[05:19] <lifeless> adding the columns is a cold patch
[05:19] <lifeless> it will go in fastdowntime
[05:19] <lifeless> adding the indices is hot, so will get deployed after the downtime
[05:20] <StevenK> So, I want -1 or something with the ADD COLUMN patch?
[05:20] <lifeless> https://dev.launchpad.net/Database/LivePatching has various bits of gory detail, but is still a work in progress
[05:20] <lifeless> yup, exactly.
[05:21] <lifeless> then we deploy that, then a garbo job to migrate
[05:21] <StevenK> Yes
[05:23] <lifeless> (ok, I'm telling you how to suck eggs... sorry :))
[05:24] <StevenK> I'll worry about indexes later
[05:25] <lifeless> yup
[05:33] <lifeless> meep
[05:33] <lifeless> testPartnerUploadToNonReleaseOrProposedPocket
[05:33] <lifeless> is not generating an oops for me ><
[05:33] <StevenK> Then you broke it
[05:33] <StevenK> :-P
[05:34] <lifeless> prethumably, but I have no idea how
[05:34] <lifeless> I hate how it fails by telling you a completely unrelated oops happened
[05:35] <lifeless> StevenK: this is for my useoops branch - ec2 found some tests [just tests so far] that I'd missed updating
[05:47] <StevenK> lifeless: https://code.launchpad.net/~stevenk/launchpad/denorm-bspph/+merge/71303
[05:47] <lifeless> we didn't test spph - things seemed fast on the source side anyhow
[05:47] <lifeless> (do we need it?)
[05:48] <wgrant> It would be handy for overrides.
[05:48] <wallyworld_> StevenK: do you need to specify that those int columns are foreign keys?
[05:50] <StevenK> *shrug* It could go either way
[05:56] <wallyworld_> StevenK: imho, they should be specified as foreign keys for referential integrity but i'm sure a dba can provide definitive input
[05:57] <wgrant> No reason for them not to be foreign keys, and they should be.
[05:57] <wallyworld_> StevenK: i won't claim the review since there's already 2 highly qualified people on the review list :-)
[05:58] <lifeless> wallyworld_: you couldn't be authoritative anyhow
[05:58] <lifeless> wallyworld_: db patches have a different review rule
[05:58] <lifeless> https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess#Reviews
[05:59] <lifeless> yes, they should be FK's
[06:05] <StevenK> lifeless: Done. So I need to wait until Monday?
[06:05] <StevenK> I suppose it can't land until FDT anyway
[06:05] <lifeless> yes
[06:05] <lifeless> you can land it when its reviewed (on db-devel as all schema patches do)
[06:05] <lifeless> we'll deploy it as soon as we can
[06:06] <StevenK> And then how it does flow back into devel?
[06:10] <lifeless> depends
[06:10] <lifeless> if things are merged up, cherrypick merge.
[06:10] <lifeless> bah
[06:10] <lifeless> are *not* merged up
[06:10] <lifeless> cherrypick merge
[06:10] <lifeless> if they are merged up, a regular merge
[06:10] <lifeless> to be merged up, all that is on db-devel before the thing being deployed must be also deployed.
[06:23] <jelmer> g'morning
[06:27] <spm> heya jelmer
[06:28] <lifeless> ok, tests fixed. \o/
[06:28] <lifeless> StevenK: want to do an incremental review of test fixups ? I would say 'no' if I were you ;)
[06:29] <StevenK> Fine, no :-P
[06:30] <lifeless> woot, lp-land time!
[06:30] <StevenK> Ask wallyworld_ :-P
[06:31] <lifeless> meh, its all the same mechanical stuff you saw before
[06:31] <lifeless> with some do-it-the-easy way stuff for extra credit
[06:31] <lifeless> (actually, I'm ec2 landing, cause i don't want a broken trunk on friday evening, but bah)
[06:34] <lifeless> argh, I want bandwidth. sob.
[06:34] <lifeless> Using saved parent location: bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/
[06:34] <lifeless>    983kB     2kB/s / Fetching revisions:Inserting stream:Estimate 688/1174
[07:44] <adeuring> good morning
[07:54] <jelmer> hi adeuring
[07:54] <adeuring> hi jelmer!
[08:07] <wgrant> 2011-08-11 10:38:53 WARNING public.spn_lookup not in calculated lpmain replication set. Update *_SEED in replication/helpers.py
[08:07] <wgrant> lifeless: ^^ is that you?
[08:07] <wgrant> lifeless: Caused the staging full-update to blow up, although the appserver came back OK.
[08:07] <LPCIBot> Project db-devel build #802: STILL FAILING in 5 hr 17 min: https://lpci.wedontsleep.org/job/db-devel/802/
[08:08] <StevenK> That would be lifeless, yes
[08:10] <lifeless> wgrant: heh, ><
[08:10] <lifeless> wgrant: today?
[08:10] <lifeless> that temp table had hung around
[08:10] <wgrant> lifeless: Around 10am.
[08:10] <wgrant> Maybe more 11am.
[08:11] <wgrant> My time.
[08:11] <lifeless> dropped it now
[08:11] <wgrant> Thanks.
[08:12] <wgrant> We'll see in 16 hours if it worked.
[08:12] <wgrant> Really need to turn off those jobs.
[08:13] <wgrant> The topic is a bit more German than usual.
[08:14] <jelmer> :-)
[08:24] <LPCIBot> Yippie, build fixed!
[08:24] <LPCIBot> Project db-devel build #803: FIXED in 16 min: https://lpci.wedontsleep.org/job/db-devel/803/
[08:26] <StevenK> WHAT?
[08:26]  * StevenK kicks Jenkins. In the face.
[08:27] <lifeless> StevenK: \o/
[08:28] <StevenK> successful: lp.buildmaster.tests.test_manager.TestBuilddManagerScript.testBuilddManagerRuns
[08:28] <StevenK> Killed
[08:28] <StevenK> Hmmmmm
[08:29] <StevenK> [67994.667699] Out of memory: kill process 13032 (xvfb-run) score 198282 or a child
[08:29] <StevenK> Whee
[08:29] <StevenK> Not much I can do about the OOM killer
[08:31] <wgrant> StevenK: How big is the instance?
[08:32] <mrevell> Morning
[08:32] <StevenK> c1.xlarge, 2Gb of RAM
[08:55] <wgrant> jelmer: Did you see the odd failure on https://code.launchpad.net/~doko/gcc/4.6?
[08:59] <jelmer> wgrant, the database one?
[08:59] <wgrant> http://launchpadlibrarian.net/77073020/doko-gcc-4.6.log
[09:00] <wgrant> Says it took an hour, but there's only two minutes and a timeout in the log.
[09:02] <jelmer> hmm, that's odd indeed
[09:13] <bigjools> StevenK, wgrant: did one of you upgrade the schema on DF?
[09:13] <wgrant> Not I.
[09:13] <bigjools> I wanted to do my new patch myself so I could note how long it took.  I guess I can;t now.  >:(
[09:13] <wgrant> DF is invalid. Use staging.
[09:14] <wgrant> Patch number?
[09:14] <bigjools> well also if staging actually told me how long it took that'd be nice
[09:14] <bigjools> DF is not invalid.  It's always slower.
[09:14] <bigjools> 80-1
[09:15] <bigjools> ah it's in the l-d-r table
[09:15] <wgrant> It is.
[09:15] <bigjools> forgot about that, I was hunting logs
[09:16] <wgrant> It's also not on staging yet.
[09:16] <wgrant> Will be in 10ish hours.
[09:16] <wgrant> The last few updates failed because lifeless was a bad person.
[09:16] <bigjools> it is on staging
[09:16] <wgrant> Huh.
[09:16] <bigjools> was on staging yesterday
[09:17] <wgrant> Oh, right, it applies the patches before it crashes.
[09:17] <wgrant> Just doesn't print the times.
[09:17] <bigjools> right
[09:17] <bigjools> which is.... not  useful
[09:17] <wgrant> But you can still get the timing from there, since you have access.
[09:22] <bigjools> yes, but most people can't
[09:24] <bigjools> "Bad magic number" ... I hate pyc files
[09:24] <lifeless> wgrant: was not
[09:24] <lifeless> wgrant: the script considers *temporary* tables
[09:24] <lifeless> wgrant: thats a bug :)
[09:26] <wgrant> lifeless: That was a temp table?
[09:26] <wgrant> Oh, right, I remember we had this problem a while ago.
[09:27] <wgrant> Guess we should check relistemp.
[09:27] <lifeless> wgrant: yes, 'create temp table spn...'
[09:29] <wgrant> Bah, oops fail.
[09:29] <wgrant> Ah, no, unrelated.
[09:36] <wgrant> lifeless: Ah, temp tables were fixed in security.py, but replication.helpers says this:
[09:36] <wgrant>     # Ignore any tables and sequences starting with temp_. These are
[09:36] <wgrant>     # transient and not to be replicated per Bug #778338.
[09:36] <_mup_> Bug #778338: restartable multitablecopier interacts badly with replication and upgrade operations <qa-untestable> <Launchpad itself:Fix Released by stub> < https://launchpad.net/bugs/778338 >
[09:36] <wgrant> It doesn't check properly.
[09:37] <lifeless> yeah
[09:37] <lifeless> win
[09:38] <wgrant> Should probably use the same pg_table_is_visible check that security.py has.
[09:53] <gmb> allenap: Is bug 812583 QAable?
[09:53] <_mup_> Bug #812583: IndexError in add_template_values in loggerhead annotate <loggerhead> <oops> <qa-needstesting> <Launchpad itself:Fix Committed by allenap> <loggerhead:Fix Committed by pr0gg3d> < https://launchpad.net/bugs/812583 >
[09:53]  * allenap looks
[09:54] <allenap> gmb: Yeah, probably :) I'll give it a go now.
[09:57] <gmb> allenap: Thanks
[10:01] <LPCIBot> Project devel build #966: STILL FAILING in 6 hr 2 min: https://lpci.wedontsleep.org/job/devel/966/
[10:03] <allenap> gmb: Do you know how I get a branch into qastaging?
[10:03] <StevenK> allenap: You beg a LOSA
[10:03] <gmb> allenap: Sodomy non sapiens, I'm afraid.
[10:03] <allenap> FFS.
[10:04] <StevenK> Or land it via stable :-)
[10:05] <allenap> StevenK: Ah, oops, I was unclear. I mean, I want a branch to be available in codehosting in qastaging.
[10:05] <StevenK> Oh, that use.
[10:09] <gmb> allenap: Also, does bug 796669 actually need QAing since it's a testing-related issue?
[10:09] <_mup_> Bug #796669: The lp.registry.distroseriesdifferences_details module (javascript) is very hard to test. <derivation> <qa-needstesting> <tech-debt> <Launchpad itself:Fix Committed by rvb> < https://launchpad.net/bugs/796669 >
[10:09] <allenap> rvba: ^
[10:10] <rvba> allenap: gmb I'm on it.
[10:11] <gmb> allenap, rvba: Ah, sorry, yes. I forgot that "person who filed the bug" != "person who fixed it"
[10:11] <allenap> Hehe.
[10:23] <danilos> matsubara, hi, I find that OOPS from bug 690568 doesn't really match up well with what the bug describes — do you have any idea what might be going on?
[10:41] <allenap> Does anyone know how I can create a revision without a commit message? bzr forbids.
[10:48] <StevenK> allenap: -m " " ?
[10:48] <allenap> StevenK: I needed a properly empty revision for QA.
[10:49] <allenap> s/revision/message/
[10:50] <allenap> StevenK: I've done it now; wgrant suggesting bzrlib directly, which was quite straightforward with the help of Google.
[10:50] <StevenK> allenap: Indeed, I saw, since IRC is good like that. :-)
[11:13] <bigjools> StevenK, wgrant: IArchive.getPublishedSources() doesn't use a default status.  This seems dangerous to me, I am tempted to make it default to PUBLISHED.  Thoughts?
[11:38] <danilos> adeuring, hi, I've got a short branch up for review https://code.launchpad.net/~danilo/launchpad/bug-728220/+merge/71343
[11:38] <wgrant> bigjools: PUBLISHED is dangerous.
[11:39] <wgrant> bigjools: [PUBLISHED, PENDING] is necessary but dangerous unless you're sure that you're expecting it.
[11:39] <wgrant> Nothing is safe.
[11:39] <wgrant> So there is no sane default.
[11:39] <bigjools> well with a method called getPublishedSources, you'd expect published sources, no? :)
[11:40] <bigjools> pending is assumed to be returned anyway
[11:40] <wgrant> Published, published, or published?
[11:40] <wgrant> There are three definitions.
[11:40] <wgrant> Currently published.
[11:40] <wgrant> Published.
[11:40] <wgrant> And having been published.
[11:40] <bigjools> I don't expect superseded sources
[11:40] <bigjools> that's the dangerous part
[11:40] <wgrant> Let me guess.
[11:40] <bigjools> heh
[11:41] <wgrant> You initialised a distroseries with the parents' entire history?
[11:41] <bigjools> define "you"
[11:41] <bigjools> but yes
[11:41] <wgrant> Heh.
[11:41] <bigjools> and does explain the IDS script memory usage
[11:41] <bigjools> to some extent anyway
[11:41] <wgrant> Not entirely, but it goes some way.
[11:41] <wgrant> Right.
[11:42] <bigjools> I still think defaulting to (pending, published) is right
[11:45] <wgrant> Possibly.
[11:48] <bigjools> casual users will get a big surprise
[11:50] <adeuring> danilos: I'll look
[11:51] <danilos> adeuring, thanks
[11:52] <bac> hi adeuring -- how goes the battle?
[11:53] <adeuring> morning bac, I must admit that I did not do many reviews this morning
[11:53] <wgrant> henninge-lunch: Considering a deployment today?
[11:53] <jelmer> wow, the deployments are daily now?
[11:53] <wgrant> jelmer: We've been doing around 1.5 a day lately.
[11:53] <jelmer> that's really exciting.
[11:54] <wgrant> We can even deploy codehosting without downtime now, although it's slow so we don't do it normally.
[11:54] <wgrant> This leaves librarian, ftpmaster and poppy as the only downtime services.
[11:54] <wgrant> And librarian will be fixed in a week or two.
[11:55] <wgrant> And we can fix ftpmaster now.
[11:55] <wgrant> So we are just about fully nodowntime.
[11:57] <adeuring> danilos: the branch looks good. Just one question: did you consider to treat something like SELECT 'a''b'? Not really important to fix the bug, I assume, but anyway...
[12:01] <bac> adeuring: i'm starting on jtv's branch
[12:01] <adeuring> bac: ok
[12:04] <danilos> adeuring, I didn't bother spending too much time considering the queries in OOPSes are all very "standard"
[12:05] <danilos> adeuring, I was also thinking about escaped quotes, but they can't show up in what we care about most, so no big deal
[12:05] <adeuring> danilos: right, so r=me.
[12:06] <danilos> adeuring, thanks
[12:07] <danilos> bigjools, wgrant: how do I make a PPA private on staging? (I want to do it for https://qastaging.launchpad.net/~danilo/+archive/epiphany so I can get a fresh OOPS for bug 690568)
[12:20] <henninge> wgrant: had not thought of that yet but sure ;-)
[12:37] <bigjools> danilos: you need to be a commercial admin and you need an empty PPA
[12:38] <henninge> wgrant: requested ;)
[12:38] <bigjools> I can do it for you if you give me an empty one
[12:38] <danilos> bigjools, oh, so a new one needs to be created? sure thing, just a minute
[12:39] <danilos> bigjools, https://qastaging.launchpad.net/~danilo/+archive/empty
[12:40] <bigjools> danilos: done
[12:40] <danilos> bigjools, thanks
[13:00] <StevenK> adeuring, bac: Which of you two wants to review a massive-oversized mostly-scripted branch?
[13:01] <bac> StevenK: wow, you're a salesman at heart
[13:01] <StevenK> Haha
[13:01] <adeuring> StevenK: I'll look
[13:01] <bac> StevenK: i'm in the middle of a mildly oversized branch ATM
[13:01] <adeuring> but let me finish another review first
[13:01] <StevenK> adeuring: I will owe you at least one beer, possibly more. It's 4,701 lines.
[13:01] <bac> StevenK: so you'll be next whichever one of us getst there first
[13:02]  * adeuring runs awy
[13:02] <adeuring> nah, it's fine
[13:02] <bac> StevenK: that is 6 times the limit, so i think you'd owe him at least five beers
[13:02] <StevenK> Haha
[13:03] <StevenK> It's only 5.9 times the limit, so 4.9 :-P
[13:07] <gmb> wgrant: If you're still around: is your fix for bug 824368 QAable?
[13:07] <_mup_> Bug #824368: security.py takes 6 seconds per DB <qa-needstesting> <Launchpad itself:Fix Committed by wgrant> < https://launchpad.net/bugs/824368 >
[13:07] <wgrant> gmb: The next (not current) staging update will do it.
[13:08] <gmb> wgrant: Okay, thanks.
[13:08] <wgrant> But it's on db-devel, so nobody should care...
[13:08] <gmb> Ah, fair point.
[13:08] <gmb> We should have a qa-yeahwhatever tag.
[13:08] <StevenK> You tag it like that and see what the tagger does.
[13:08] <StevenK> It would be amusing.
[13:12] <danilos> wow, we've got 73 bugs that are fix committed in launchpad-project
[13:12] <danilos> (well, bug tasks, but still)
[13:34] <gmb> danilos: Indeed. I'm trying to drive down the QA list to the point where we can roll a bunch of those out.
[13:52] <bigjools> did someone break devel?
[13:52] <matsubara> danilos, for some time we had a duplicationa on oops prefixes and then got oopses with the same oops id
[13:52] <bigjools> s/devel/db-devel/
[14:02] <danilos> bigjools, I believe check-db-revisions is not running anymore, try 'make schema' first
[14:03] <danilos> matsubara, oh, so you think this is just an old one (i.e. no need to worry about them still being overwritten like this)?
[14:05] <matsubara> danilos, I'll double check, but I think it's been fixed and this is one of the old cases
[14:05] <danilos> matsubara, excellent, thanks
[14:06] <bigjools> danilos: it failed in ec2
[14:06] <bigjools> but thanks for reminding me about that :)
[14:07] <LPCIBot> Project devel build #967: STILL FAILING in 4 hr 5 min: https://lpci.wedontsleep.org/job/devel/967/
[14:20] <LPCIBot> Yippie, build fixed!
[14:20] <LPCIBot> Project devel build #968: FIXED in 12 min: https://lpci.wedontsleep.org/job/devel/968/
[14:22] <abentley> adeuring or bac: could you please review https://code.launchpad.net/~abentley/launchpad/push-creates-package/+merge/71366 ?
[14:23] <adeuring> abentley: I need to finish another review; when that is finished, I'll have a look
[14:24] <abentley> adeuring: thanks.
[14:28] <matsubara> danilos, just checked and we have only one config with oops_prefix: C in the configs branch. If I remember correctly that's the generic prefix used and have been changed to the REPORTIFSEEN on loganberry
[14:29] <matsubara> if you spot an oops redirecting to the wrong oops report, let me know
[14:42] <bac> adeuring: i can do abentley's review unless you've already started
[14:42] <adeuring> bac: I was just now going to start it :) I'll do it
[14:42] <bac> adeuring: ok
[14:45] <rvba> matsubara: Hi, looks like my branch (about improving the JS of the reports) made it into db-stable. Just to give you a heads up :).
[14:47] <matsubara> thanks rvba
[14:48] <rvba> np
[14:49] <matsubara> rvba, the ppr branch is now on r10890.
[14:52] <rvba> matsubara: great, do you know how often the report generation script runs?
[14:54] <matsubara> rvba, we have a couple of lines in the crontab. did you change only the ppr or the ppr and the dbr?
[14:55] <matsubara> in any case here's the crontab lines:
[14:55] <matsubara> rvba, https://pastebin.canonical.com/51172/
[14:55] <rvba> Only the ppr.
[14:55] <matsubara> so basically, once a day for the ppr and more often for the dbr
[14:56] <matsubara> I'll kick a run of the ppr script now so you can try things. give a sec
[14:56] <rvba> Thanks a lot!
[15:09] <adeuring> abentley: overall, a nice branch. The only thing that puzzled me was that you had to add the valid_name() call to SourcePackageNameSet.new(). I understand that it is necessary -- but where and how was the validity check done before?
[15:10] <abentley> adeuring: There's a check constraint on the database, but I wanted to get a more specific exception than the database one.
[15:10] <adeuring> abentley: ah, ok. thanks. So, no conflicts, I assume. r=me
[15:11] <abentley> adeuring: thanks.
[15:27] <matsubara> rvba, hey, I didn't forget about you. script is still running. I'll ping you when it finishes
[15:28] <rvba> thanks matsubara
[15:39] <cjwatson> adeuring,bac: can either of you review https://code.launchpad.net/~cjwatson/meta-lp-deps/new-apt/+merge/71386 ?
[15:40] <adeuring> cjwatson: sure, I'll look
[15:47] <cjwatson> I don't know the process for actually getting that into the PPA, although it seems to involve recipes
[15:50] <adeuring> cjwatson: the diff against devel is huge...
[15:51] <adeuring> cjwatson: never mind
[15:55] <adeuring> cjwatson: r=me.
[15:56] <cjwatson> adeuring: thanks.  can you land it?  I don't have access
[15:56] <adeuring> cjwatson: sure
[15:56] <cjwatson> (it'll need to have UNRELEASED replaced with the appropriate series in debian/changelog, of course)
[15:56] <cjwatson> (if you'd like me to do that, tell me which series to use)
[15:59] <bigjools> allenap: ta for the tracer advice
[15:59] <bigjools> I guessed it might be pebkac
[16:01] <allenap> bigjools: That wasn't pebkac. It's hairy code in there; the stuff in checkwatches took a long time to get right.
[16:02] <bigjools> allenap: that points to a bigger problem then
[16:02] <adeuring> cjwatson: i think natty would appropriate
[16:04] <allenap> bigjools: Indeed. But I am not going down there until our feet start punching holes in the floorboards.
[16:04] <bigjools> allenap: or fists in walls :)
[16:05] <allenap> Hehe :)
[16:09] <danilos> adeuring, bac: I've put a branch up for review, I'm leaving but would appreciate a review: https://code.launchpad.net/~danilo/launchpad/bug-690568/+merge/71394
[16:09] <danilos> thanks :)
[16:09] <bigjools> allenap: hah, it's timing out the txn now of course.
[16:10] <adeuring> danilos: I'm quite close to EOD/EOW too ;)
[16:10]  * allenap experiences schadenfreude
[16:36] <mtaylor> how come I have to have direct team membership to have PPA access?
[16:36] <mtaylor> I'd think that being a member of a team that owned a team would give me access to the PPA of that team
[16:36] <mtaylor> team team team
[16:39] <bigjools> mtaylor: that should work, what error are you getting?
[16:39] <bigjools> allenap: yay, trace at last
[16:39] <mtaylor> bigjools: Signer has no upload rights to this PPA.
[16:39] <allenap> bigjools: Woohoo \o/
[16:39] <bigjools> mtaylor: can you confirm it's signed with the right key?
[16:40] <mtaylor> bigjools: to be specific - I am a member of the owning team, and I was also a direct member, and then we deactivated my direct membership  - just in case that has something to do with it
[16:40] <mtaylor> bigjools: yes - when I reactivated my direct membership, it worked again
[16:40] <bigjools> ok
[16:40] <bigjools> you'd better file a bug then
[16:41] <mtaylor> bigjools: okie!
[16:42] <bigjools> matsubara: I have got an OOPS file on dogfood, how do I turn it into a lovely web page that analyses repeated and long queries?
[16:42] <bigjools> mtaylor: sorry man :(
[16:43] <matsubara> bigjools, it should appear in the lp-oops.c.c. isn't that working?
[16:44] <bigjools> matsubara: it's a dogfood oops, so I doubt that :)
[16:44] <matsubara> it's supposed to work. what's the oops id?
[16:44] <SpamapS> Hi! So, I need to have a distribution renamed... apparently this is not doable through LP's admin interface...
[16:46] <matsubara> bigjools, I think we need to ask the losas to sync dogfood oopses to devpad
[16:49] <bigjools> matsubara: or can I just poke the tools on DF and run them there?
[16:49] <bigjools> I only want it for  a single oops
[16:49] <bigjools> or is it not that easy?
[16:49] <bigjools> I don't mind syncing them to devpad
[16:51] <bigjools> SpamapS: it's not
[17:04] <nigelb> German topic?
[17:04] <matsubara> bigjools, not that easy. syncing would be easier and would set things up for the same in the future
[17:05] <bigjools> matsubara: ok, I guess we need an RT
[17:05] <bigjools> matsubara: can you copy this single oops for me for now?
[17:06] <matsubara> bigjools, I'll file the rt. yep, could you copy it to devpad and I'll try to load it into lp-oops.c.c
[17:24] <cjwatson> bac: I've done as adeuring asked above for https://code.launchpad.net/~cjwatson/meta-lp-deps/new-apt/+merge/71386 - would you be able to land it?
[17:25] <bac> cjwatson: sure
[17:25] <cjwatson> excellent, thanks
[17:25] <bac> cjwatson: in just a bit
[17:26] <cjwatson> (and presumably kick off the recipe build or whatever it is)
[17:27] <cjwatson> https://dev.launchpad.net/LaunchpadPpa#launchpad-dependencies looks wrong to me, seeing as recent builds seem to have been done by way of a recipe
[17:30] <cjwatson> https://code.launchpad.net/~launchpad/+recipe/meta-lp-deps-on-demand looks relevant
[17:31] <bac> cjwatson: i'll get the branch landed...the recipe stuff i'll have to figure out
[17:31] <cjwatson> I guess that ought to be triggered on commit?
[17:31] <cjwatson> or daily, anyway
[17:33] <bac> cjwatson: did abel just ask for some changes on IRC?
[17:34] <cjwatson> 16:56 <cjwatson> (it'll need to have UNRELEASED replaced with the appropriate series in debian/changelog, of course)
[17:34] <cjwatson> 16:56 <cjwatson> (if you'd like me to do that, tell me which series to use)
[17:34] <cjwatson> 17:02 <adeuring> cjwatson: i think natty would appropriate
[17:34] <cjwatson> so yeah, I did that
[17:35] <cjwatson> otherwise he just said 16:55 <adeuring> cjwatson: r=me.
[17:35] <bac> cjwatson: ok, thanks, i wasn't sure if that was what you were referring to
[17:47] <bac> cjwatson: were you suggesting the instructions around step 11 of https://dev.launchpad.net/LaunchpadPpa#launchpad-dependencies are incorrect?  with the recipe build, the branch only needs to be pushed up?
[17:52] <bac> hi sinzui, could you tell me if the instructions for uploading to meta-lp-deps as shown here are still correct:  https://dev.launchpad.net/LaunchpadPpa#launchpad-dependencies ?  i see you've done commits to that branch lately.
[18:04] <sinzui> bac: Those instructions look correct, but I see a recipe is setup to build it https://code.launchpad.net/~launchpad/+recipe/meta-lp-deps-on-demand
[18:05] <bac> sinzui: correct.  so due to the recipe, which steps can i skip?
[18:06] <sinzui> bac: 1-12
[18:07] <sinzui> Error you would have seen in steps 1-12 will be sent to you via email
[18:10] <bac> sinzui: so i just push the branch then?  and it gets signed by LP?
[18:11] <bac> sinzui: is it an issue that i'm pushing up a branch for cjwatson and he is listed as the changer in the changelog?
[18:12] <sinzui> bac, no it is not an issue
[18:13] <bac> thanks sinzui.  i'll update that wiki page now.
[18:13] <sinzui> bac: the package is signed by you I believe. I may be mistaken and it is signed by the owner of the ppa
[18:20] <bac> cjwatson: done.  waiting for it to build.
[18:22] <timrc> anyone know off hand how you can express " Use all Ubuntu components available." with the addArchiveDependency API call? it seems that the default behavior (no specifying a component or specifying None) is the equivalent to "Use the same components used for each source in the Ubuntu primary archive."
[18:40] <bac> cjwatson: it *looks* happy: https://code.launchpad.net/~launchpad/+recipe/meta-lp-deps-on-demand
[18:49] <cjwatson> bac: excellent, thank you - I'll update the corresponding RT ticket in a bit
[18:51] <cjwatson> (done)
[19:39] <lifeless> grr race conditions on landing :(
[20:32] <lifeless> anyone around ?
[20:32] <lifeless> I need a sanity check, I think we have a subtley broken test.
[20:33]  * lifeless wishes for a highlight-all facility to ping folk :P
[20:36] <lifeless> sinzui: are you still around ?
[20:44] <sinzui> lifeless, yes
[20:45] <lifeless> sinzui: can you please follow the reproduction instructions on https://bugs.launchpad.net/launchpad/+bug/825486
[20:45] <_mup_> Bug #825486: testPartnerUploadToNonReleaseOrProposedPocket is incorrectly passing <Launchpad itself:New> < https://launchpad.net/bugs/825486 >
[20:51] <sinzui> lifeless, my error is very similar: AttributeError: 'NoneType' object has no attribute 'write'
[20:52] <lifeless> sinzui: great, thanks.
[20:52] <lifeless> test disabling will happen with the landing of my useoops branch (2nd landing)
[20:56] <lifeless> StevenK: you know that test I asked about which you said I must have broken? Nope. Broken in trunk.
[20:59] <abentley> lifeless: I have a change to codehosting that I'll be landing soon.  What the current deployment story?
[20:59] <lifeless> we can do a nearly-no-downtime
[21:00] <lifeless> but its on request, not part of the default nodowntime set
[21:00] <lifeless> because of losa overhead basically - got to wait an hour or so for connections to drop off, and usually have to manually kill the daemon (because of tarmac and similar htings that are holding open persistent connections)
[21:01] <lifeless> bug 819604: reconnect when connection drops
[21:01] <lifeless> bug 795025: allow admins to ask the server to close the connection
[21:01] <lifeless> after it finishes the current request
[21:01] <lifeless> bug 824797: drop connections that have been idle for a while
[21:01] <_mup_> Bug #795025: no way to gracefully disconnect clients and shut down the bzr server <canonical-losa-lp> <hpss> <launchpad> <ssh> <Bazaar:Confirmed> <Launchpad itself:Triaged> < https://launchpad.net/bugs/795025 >
[21:01] <_mup_> Bug #824797: bzr serve doesn't drop idle/dead connections <hpss> <serve> <Bazaar:Confirmed> < https://launchpad.net/bugs/824797 >
[21:01] <_mup_> Bug #819604: when an idle ssh transport is interrupted, bzrlib errors; should reconnect instead <error-reporting> <hpss> <launchpad> <ssh> <Bazaar:Confirmed for mbp> <Bazaar 2.1:Confirmed> <Bazaar 2.2:Confirmed> <Bazaar 2.3:Confirmed> <Bazaar 2.4:Confirmed> < https://launchpad.net/bugs/819604 >
[21:02] <lifeless> abentley: we do have two instances though, so short lived connections - normal operations - are not inconvenienced at all
[21:02] <lifeless> abentley: once a server is in quiesce mode haproxy no longer sends traffic to it
[21:03] <abentley> lifeless: I've updated the internal xmlrpc server to emit a new type of fault in rare circumstances.  Do you think that would break a nodowntime deployment?
[21:03] <lifeless> abentley: I don't know :). What happens if the existing codehosting server runs against the new xmlrpc server ?
[21:04] <lifeless> (and that fault gets emitted)
[21:04] <abentley> lifeless: I think you'll get an ugly error about an unexpected fault.
[21:04] <lifeless> abentley: the new fault only occurs in a subset of situations that would previously fault differently though, right ?
[21:05] <lifeless> abentley: its not 'something that worked now doesn't', its 'something that didn't work fails differently'
[21:05] <abentley> lifeless: Yes.  Specifically, when you try to push to a sourcepackage branch that doesn't exist, using an invalid name.
[21:05] <lifeless> yeah, I thought that was the branch you were referring to
[21:05] <lifeless> so, I wouldn't halt the nodowntime deployment to appservers for this.
[21:06] <lifeless> but I would expedite the deploy of the updated fault handling code to codehosting
[21:06] <abentley> lifeless: okay, so after landing, we can do a low-downtime deployment.
[21:06] <lifeless> yes - land, nodowntime as normal, then a codehosting specific deploy.
[21:11] <abentley> lifeless: btw, the relative import works fine on Canonistack's lucid instance.
[21:11] <lifeless> good to know
[21:12] <lifeless> Got to be some subtle difference between python versions :(
[22:40] <LPCIBot> Project devel build #969: FAILURE in 6 hr 13 min: https://lpci.wedontsleep.org/job/devel/969/