[00:05] wgrant: http://pastebin.ubuntu.com/673437/ === StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: StevenK | Critical bugs: 238 - 0:[#######=]:256 [00:28] https://answers.launchpad.net/launchpad/+question/158269 [00:28] Intriguing. [00:29] People really seem to care about revision numbers matching. [00:30] yes [00:30] we could make bzr handle sparse mainlines ;) [00:30] You are a bad person. [00:31] Still. [00:31] At least not as bad as whoever designed Mercurial revnos. [00:31] I am an awesome person [00:31] solving the world, one line at a time. [00:31] Compared to whoever designed Mercurial revnos, yes. [00:31] Do you know how they work? [00:31] They are really, really useless. [00:31] yes [00:31] they are perfectly useful for the purpose designed [00:32] just extremely local in scsope [00:32] (and sparse on any given branch) [00:39] Grarrr. [00:41] >>> u.newPackagesetUploader(packageset=lp.packagesets.getByName(name='zope', distroseries='/ubuntu/oneiric'), person=lp.people['wgrant']) [00:41] [00:41] newPackagesetUploader is in IArchiveView, so we are qa-bad. [00:41] Yay. [00:41] We will be doing a 60-70 rev deploy tomorrow :D [00:41] oh, assign-me-permissions to anhyone ? [00:41] Yeah. [00:41] win [00:44] This deploy will also have some really risky stuff in it. [00:44] * wgrant dies. [00:44] :( [00:44] anything I can do to help? [00:44] No. [00:45] Apart from declaring devel frozen. [00:45] production is now 57 revisions behind tip :/ [00:45] I guess we should deploy the first 10 that we can do today. [00:47] if its qa ok yeth [00:47] Hm? [00:47] I agree conditional on that being qa-ok :) [00:47] Heh. [00:48] We have 13 deployable. [00:48] Let's do that. [00:54] wallyworld: (Wow, no underscores) WRT https://code.launchpad.net/~wallyworld/launchpad/rename-private-team-795771/+merge/72516 , does that mean that private teams can be renamed or this is just UI gubbins? [01:07] StevenK: just ui [01:08] wallyworld: So you can't use the UI to perform a rename? [01:08] StevenK: you can once the branch lands [01:08] for private teams [01:09] whereas before private teams you couldn't [01:09] wallyworld: Then I'd like a test that actually *tests* that. At the moment your test only checks the widgets on the +edit page [01:09] And the error conditions [01:09] StevenK: that's all the doc tests that were replaced by unit tests ecer did [01:10] the testing checks that the name field is or is not readonly in the right places [01:11] ie it is read only for those situations where the team cannot be renamed [01:11] from there on, when the user hits Save, it's just a normal domain model update operation [01:12] wallyworld: Even so, you (correctly) removed a test that private teams can not be renamed -- I'd still like to see an end-to-end test where you initialize the +edit view, submit it and assert the team name has changed. [01:13] but if the name field is not display only, then existing tests will cover that [01:13] scenario [01:13] all we need to test here is whether the name field is display only or not [01:14] since that's what the previous functionality did for private teams [01:14] seems like we would be duplicating tests [01:15] wallyworld: No, existing tests will not. Since the code was previously written to forbid renaming private teams, I find it highly suspect that there is another test for what I'm asking. [01:16] so you think there is an existng end-end test for private team renaming? there's nothing at the db layer to prevent private teams being renamed (there is for the mailing list restriction though) [01:17] the code that was previously written to forbid private team renaming was just inthe view and alit did was disable the name field [01:18] wallyworld: No, I think there is *not* an existing end-to-end test for private team renaming. [01:19] If you're removing a special case like this, it's probably not immensely beneficial to test the special case that you're removing. [01:19] I'm concerned that something else will pop up during QA [01:20] i can add an end-end test if you insist but it will be a brand new test - afaik we don't normally test simple crud stuff in the view tests? [01:23] so it wouldn't be a view test but a test in the model layer? [01:24] view tests normally just check that the view has rendered correctly and the actions have been wired up? [01:25] anyone up for a simple review ? https://code.launchpad.net/~lifeless/python-oops-wsgi/foru1/+merge/72640 [01:26] * wallyworld has to go pick up kid from school for orthodontist appointment $$$$ :-( [01:29] StevenK: ^ [01:29] Yes, yes, I'm already looking [01:29] thanks [01:29] I couldn't tell [01:30] I'd be worried if you could [01:32] lifeless: So why is there a lone '\' on line 284 of the diff? [01:39] StevenK: that was a test. You pass. [01:41] StevenK: (deleting it ;)) [01:46] hah [01:46] StevenK: I forgot one commit [01:46] to wire it all up ><. Doing that now [01:57] StevenK: rev 18 pushed - should be able to look at it incrementally anytime now [01:59] lifeless: r=me [02:00] I already voted as approve, so meh [02:00] StevenK: thanks! [02:02] jamesh: python-oops-wsgi 0.0.3 (in trunk now) should have everything [02:10] lifeless: looks good. Have you guys looked at things like SQL statement logging yet? (or any other data collection mechanism) [02:10] jamesh: yes, thats handled via the on_create hooks [02:11] adding something to the WSGI environment that could be used to log additional info during the request processing stage could be useful [02:11] jamesh: yes. Another way is thread locals, which is how I'd expect storm glue to be done, given storms global variable tracer implementation [02:12] jamesh: FWIW lp is now running with on_create hooks for its sql gathering [02:12] cool. [02:12] there was code for that in wsgi-oops, but it probably doesn't make sense to put storm-specific stuff in python-oops [02:13] so tracer -> request_timeline and in the on_create there is an attach_timeline which grabs the request_timeline (which ends up being a TLS thing) and snarfs it out into th db_statements variable [02:13] jamesh: right, that was one of the headaches I had when considering generalising wsgi-oops [02:16] jamesh: tarballs of 0.0.3 in lp/pypi and the lp download cache (in a minute) [02:17] and soon in the Ubuntu archive? :) [02:17] in freeze at the moment [02:18] hopefully one this stabilises a little (e.g. some of the key names are noddy) I can talk to pitti about adsorbing some of apport [02:22] jamesh: so for instance, to do the 404 thing: [02:22] set oops_on_status=['404'] in make_app [02:22] and separate [02:22] I read the diff. What you've added looks pretty good. [02:23] add to config.filters a callback to decide which 404's you trapped you actually want. [02:23] that callback might be generic enough with currying that we can put it in -wsgi [02:23] or even (for twisted & zope environments) a common oops-http or even oops itself. [02:24] lifeless: for the WSGI case, one issue is that I might not know what oops config the middleware is using. That is why I was suggesting putting something in the wsgi environment [02:24] jamesh: I don't quite follow how you wouldn't know [02:25] do you suggest storing the config in a global variable somewhere? [02:26] jamesh: perhaps. What bit of code wants to know the config ? [02:26] * jamesh should probably read through the rest of the python-oops code [02:28] http://bazaar.launchpad.net/~canonical-launchpad-branches/python-oops/trunk/view/head:/oops/createhooks.py is the default hooks [02:28] and [02:28] http://bazaar.launchpad.net/~canonical-launchpad-branches/python-oops/trunk/view/head:/oops/config.py [02:28] is the core event notifier [02:30] lifeless: so for example, lets say I want to add the Django user name to my OOPS report. I create a special Django middleware class to run after the auth middleware and read request.user [02:31] where should I stash that so that it makes it into the OOPS report created by python-oops-wsgi? [02:32] ok, so we'd want a on_create hook to grab the data from the context [02:32] stashing the data in the environment would be the easiest thing there [02:32] as an example, if python-oops-wsgi added a "oops.data" value to the wsgi environment as a dictionary that would be merged into the new OOPS, it could be as simple as: request.environ['oops.data']['username'] = request.user.username [02:33] def attach_username(report, context): report['username'] = context.get(wsgi_environ, {}).get('django_user', None) [02:33] I suppose I could do my own hook for that, but it seems like it could be a useful addition as a general purpose way of collecting data. [02:34] sure, i can see that [02:34] with the current rfc822 serializer we're quite limited [02:34] I really want to nuke that, hopefully oops-tools will be using the interface soon and then we're very close to migrating away [02:34] def attach_data(report, context): report.update(context.get(wsgi_environ, {}).get('oops.data', {})) :-) [02:35] I understand that. I'm just saying that the wsgi environment is pretty easily available in Django (and is definitely available if you're doing a plain wsgi app) [02:36] rather than doing N different collection methods, we might be able to provide one that can be used for many simple cases. [02:38] jamesh: yes, I'm in favour of that. [02:38] I would be able to rewrite the hacky traceback capture code U1 is using at the moment to work with that kind of API [02:38] to work without patched Django [02:39] request.environ['oops.data']['exc_info'] = exc_info [02:39] we need to decide if it goes into the oops context, or the report directly. === jtv-afk is now known as jtv [02:39] that exc_info example would make sense for going into the context. === jtv changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: StevenK, jtv | Critical bugs: 238 - 0:[#######=]:256 [02:40] pehraps two variables [02:40] oops.report oops.context [02:40] include a default hook in install_hooks to copy oops.report verbatim [02:40] and do an update of the context from oops.context. [02:41] note that the rfc822 serializer drops anything unknown on the floor :( so need to work within that for the mean time - but you probably already are. [02:41] again, I haven't read all of your new oops code yet. I'd probably be a bit more coherent if I had [02:41] sure [02:42] you're making plenty of sense. [02:43] While arbitrary data collection would be nice (and hopefully we can support it with a new report format), I'd be happy with a simple way to collect the standard data from deep in the request [02:43] yah [02:43] I need to context swtich for a bit [02:43] care to file a bug? [02:43] sure. [03:08] lifeless: filed: https://bugs.launchpad.net/python-oops-wsgi/+bug/832477 [03:08] <_mup_> Bug #832477: Provide a simple way to capture oops info from deep in the request < https://launchpad.net/bugs/832477 > [03:11] thanks [03:49] StevenK: can I bug you for a follow-on ? https://code.launchpad.net/~lifeless/python-oops-wsgi/foru1/+merge/72649 [03:55] Project db-devel build #819: STILL FAILING in 5 hr 55 min: https://lpci.wedontsleep.org/job/db-devel/819/ [04:07] hm, when is next push to production? [04:08] nigelb: wgrant will laugh at you shortly [04:08] nigelb: in seriousness, i think there are quite a stack of revisions due to be deployed [04:08] s/laugh/sob/ [04:09] There's around 60 revisions waiting to be deployed. [04:09] mwhudson: hehe, oh QAblocking? [04:09] Currently held up by the buildbot slaves being contaminated by some nasty substances. [04:09] wow [04:10] wgrant: thats worth noting to the list I think [04:10] lifeless: I was hoping it would be resolved before EOD. [04:10] But if it is not, I might notify the list. [04:11] even if it is [04:11] Ok, timeto find another bug to work on. [04:11] helps folk be aware of what caused grief/headaches [04:11] doesn't need to be a -long- message ;) [04:12] Subject: Deployment blocked by something nasty on buildbot slaves [04:12] :D [04:22] Project devel build #988: STILL FAILING in 5 hr 33 min: https://lpci.wedontsleep.org/job/devel/988/ [04:25] so [04:26] txtacfixture [04:26] mwhudson: ping [04:26] mwhudson: how do you spell 'pick an ephemeral port' for .tac files [04:27] lifeless: specify 0 as the port number maybe? not sure though [04:27] so [04:27] and this will make folk weep [04:27] in the config we specify 0 as the port [04:27] start the service [04:27] then rewrite the config with the real port. Win! [04:28] + parser to get the ports out of the readyservice handler I guess. [04:39] StevenK: hi [04:39] lifeless: Hm? [04:39] Slightly off-topic, but every time I try to subscribe someone to a bug [04:39] report, the first time fails with "() Couldn't get subscriber details [04:39] bah [04:39] 15:49 < lifeless> StevenK: can I bug you for a follow-on ? https://code.launchpad.net/~lifeless/python-oops-wsgi/foru1/+merge/72649 [04:39] lifeless: No. You've reached your branch limit. [04:40] 1 is the limit ? [04:40] I didn't specify the duration [04:41] heh. So are you serious or teasing? [04:41] Seriously teasing? :-P [04:42] lifeless: No real comments, r=me [04:42] thanks! [04:43] * StevenK grumbles at Jenkins faulures [04:43] jamesh: ok, so thats in place. I'm going to hold off releasing for a day or two, let you see what else is needed. [04:44] lifeless: Oh, did you bump the version, or no point? [04:45] StevenK: I didn't [04:45] StevenK: waiting for more feedback from jamesh :) [04:45] Ah [04:46] StevenK: That's interesting. The hg equivalent of those failed with a timeout or something on buildbot this morning. [04:51] Interesting [04:51] I suspect the only failures we're left with are races or other buggy stuff [04:55] Yeah. [05:39] wallyworld: you're approved. [05:39] jtv: excellent, thanks [05:40] StevenK: very simple review? https://code.launchpad.net/~jtv/launchpad/fix-more-utilities/+merge/72666 [05:42] jtv: I'm concerned about the clonePackages() change [05:42] Good. [05:43] StevenK: but taunts aside (sorry), what's the problem with it? [05:44] jtv: It seems I had misremembered -- r=me [05:44] jtv: Please don't land it yet [05:45] Thanks. You were right to be concerned about it, but I think the change I made here isn't the problem. [05:46] Why not land it? [05:47] jtv: Because we have a large amount of revisions to deploy, and wgrant and I would prefer people consider devel "soft-frozen" so we can get into a deployable state. [05:47] Fair enough. [05:48] Let's not try to break the record of 4 interlocked reversions. [05:48] so I shouldn't r=me the upgrade to wsgi-oops 0.0.3 ? [05:48] Or was it 5. [05:48] bah oops-wsgi [05:48] cause you know you want me to [05:48] yes, after all that testing you did on loggerhead :P [05:49] something like that [05:50] wgrant: I think 4 === StevenK changed the topic of #launchpad-dev to: devel "soft-frozen" until we're deployable | https://dev.launchpad.net/ | On call reviewer: StevenK, jtv | Critical bugs: 238 - 0:[#######=]:256 [06:23] wgrant: It looks like DSP.latest_overall_component can die horribly [06:27] Hmmm, that is a surprise. [06:27] That sort of thing is still used a bit, but apparently not that one. [06:28] +0/-8 makes me a little happy [06:34] jtv: Tiny MP for you: https://code.launchpad.net/~stevenk/launchpad/lose-dsp-loc/+merge/72676 [06:36] wgrant: That also removes components from DSP [06:39] StevenK: Ah, most stuff uses latest_overall_publication.component. [06:39] Amusing. [06:39] Haha [06:47] so it turns out [06:47] our keyserver implementation is much more than we use [06:47] it has a human play-with-me interface [06:47] which I doubt anyone has used in 3 years [06:48] jamesh: I dunno if you've had a chance to look at python-oops-wsgi tip, but if you have feedback is solicted ;) [06:49] lifeless: I looked at the merge proposal you attached to the bug report, and it looked pretty good. [06:51] cool === almaisan-away is now known as al-maisan [06:51] jamesh: that djano specific bug, I'm not sure its actionable in python-oops-wsgi, is it ? [06:52] like, if upstream reject it and the log hacking route is still needed, that isn't a generic wsgi glue, its django specific [06:52] lifeless: probably not, after having investigated it. [06:52] how would you feel about marking it invalid in oops-wsgi? [06:53] lifeless: and I think we could do equivalent hacks to what we currently do using the oops.report/oops.context extensions. [06:53] sure. [06:53] unless you want a tracking bug for "python-oops-wsgi should work with django apps" [06:53] I'll leave that up to you though. [06:53] i think it can do that with the upstream task [06:54] uhm [06:55] yeah [06:55] actioned [06:56] jamesh: thanks very much for kicking the tires on this beast === stub1 is now known as stub === al-maisan is now known as almaisan-away [07:31] StevenK: I'm looking at your review—sorry, everybody bothering me at once. [07:32] StevenK: done === danilo_ is now known as danilos === stub1 is now known as stub [07:50] good morning [08:03] hi adeuring [08:03] hi jtv! [08:20] Morning [08:20] Good Morning! [08:25] adeuring, you may be the best person to deal with this: my experimental interfaces checker found one or two small mismatches in HWDB utilities. [08:25] g22 [08:25] gah [08:30] ok, calling it. see you all tomorrow [08:31] wgranted (n): to roll back a bad commit [08:31] adeuring: canonical.launchpad.systemhomes.HWDBApplication does not fully implement lp.hardwaredb.interfaces.hwdb.IHWDBApplication: the title attribute was not provided. [08:31] jtv: argh [08:32] bigjools: (vt) surely [08:32] It's not serious, but it is the sort of thing I want to automate checking against. [08:32] right, i can look into this [08:32] (ahem, I'm talking to adeuring here) [08:32] lifeless: it's too early to think about verbs and nouns and I've only had one sip of coffee [08:32] early hah! [08:33] we can talk early at the TL meeting :) [08:33] adeuring: thanks. The other one was HWSubmissionDeviceSet.create having too many parameters, but if that was a "self" then I've got a fix in EC2. [08:33] 2 hours kip all night, feels like I've not actually been to bed :) [08:33] stub: any word on pgbouncer? [08:33] bigjools: ugh [08:33] bigjools: kids ? [08:33] I wish it were but no [08:34] medical issues ... [08:34] :( [08:34] lifeless: same same. Waiting on the config file rollout, which is really frustrating when I keep seeing these NDT rollouts happening. [08:34] lifeless: Think we need to bump the priority to 90? [08:34] I'm not quite there yet. [08:34] I will ping mthaddon now - he's said its getting worked on this week [08:35] There's still a lot of puppet breakage right now. [08:35] Several hosts failed to roll out. [08:36] :( [08:36] not unexpected tho [08:36] No. [08:36] yeah, there's a puppet branch in progress that should fix it [08:36] Great, thanks. [08:37] Then i guess I should RT the rest of the cronspam. === mpt_ is now known as mpt === almaisan-away is now known as al-maisan [09:30] wgrant: buildbot done, waiting for asuka [09:48] Project devel build #989: STILL FAILING in 5 hr 26 min: https://lpci.wedontsleep.org/job/devel/989/ [10:13] mrevell: i'm glad the bugs page is going to get some love [10:14] i wonder if some of the ones you're retagging may be better off with a task-oriented view rather than getting the user to customize them though [10:23] poolie, Hey there, at the moment I'm tagging anything that could fall in the scope of our "customisable bug search columns" project, which is coming up next. I'm not sure what you mean by a "task-oriented view". Could you help me understand,please? [10:24] sure [10:25] for instance, if i ask about inprogress bugs, the assignee is likely to be relevant [10:25] if i ask about new bugs, the heat is more likely to be relevant [10:25] if i ask for bugs sorted by #affected, the #affected is probably interesting [10:25] Oh, yes, I see. [10:25] i don't know if this actually works but istm it is at least indicated by some of the bugs and comments [10:26] it's a chance to do better than the typical nerdy "you can configure every possible query, why aren't you happy" :) [10:26] it may be too hard to predict what people want to see [10:27] Heh. I like the idea. I think that some user research could come up with some pointers towards what people want to see. [10:27] I was the QA CoP sprint for a day last week and it seems they have some scenarios where they need particular info; they've partially solved that with a Greasemonkey script so far [10:28] were it me, I'd still try to provide the 'customizable columns on advanced search' feature first [10:28] oh [10:28] 'by milestone' is especially poignant because it doesn't show you the milestones [10:30] perhaps adding the generic thing first is better, it's just an idea i was reminded of seeing them go past [10:30] jml, Yeah, agreed, poolie's idea seems to me to build on that. A set of canned customisations, almost ... for want of a better way of describing it. [10:30] configuration plus sensibel defaults [10:31] right [10:32] fwiw, the reason it's been scheduled next is because it was requested by a bunch of stakeholders. it's also the first feature we've had in the feature queue that isn't massive. [10:34] for my part, more than privacy or derived distros or whatever, I think that each week spent on it is another week without, say, a combined issue tracker. [10:34] but maybe it's better to improve the default bug searches [10:34] Mmmm, the last two features didn't need to be massive. [10:34] not my place to say, and I don't really have an thought out opinion. [10:34] They could have been split into several each. [10:35] But I guess they'd been hanging around for three years and needed to be dealt with :/ [10:35] At least they're nearly done now. [10:35] wgrant: basically, I agree with what you just said. :) [10:35] privacy seems not nearly done, but maybe that's just because project pages aren't being updated. [10:35] It's barely started. [10:36] But DDs is nearly done sort of maybe. [10:48] 80% done, 80% to go? [10:48] poolie: before I forget, are you happy for me to land the import of the other three tools from ubuntu-dev-tools in lptools as well? [10:48] yes, thanks! [10:49] i wonder if it ought to be mentioned on u-devel or something [10:49] or perhaps it can be just handled through dpkg dependencies [10:49] to make sure people don't see those tools just disappear [10:50] poolie: We were going to handle it through dependencies (add a Recommends: lptools) [10:50] wfm, thanks [10:50] we'll need a new upload of lptools to Debian as well though (ubuntu-dev-tools is in Debian) [10:50] * jelmer looks at lifeless [10:50] don't rely on mail to humans to do what machines can d [10:51] can i persuade someone to make a release of lp:restfulclient to get the fix for bug 626960 out? [10:51] <_mup_> Bug #626960: Collection dictionary access incorrectly folds all HTTP errors to KeyError < https://launchpad.net/bugs/626960 > === matsubara-afk is now known as matsubara [11:05] what am I doing wrong to get http://paste.ubuntu.com/673718/ from buildmailman.py? [11:05] lib/lp/services/mailman/monkeypatches/defaults.py exists; lib/canonical/launchpad/mailman/monkeypatches/defaults.py doesn't [11:06] cjwatson: you might need to make clean;make [11:06] trying that, thanks [11:06] that's guess, don't shoot me if it doesn't work :) [11:06] * cjwatson nods [11:07] shoot barry instead! [11:09] bigjools, hi :-) [11:10] matsubara: ok so ""Parent series has sources waiting in its upload queues that match your selection, see help text for more information." means that there's stuff in +queue [11:10] the help text doesn't exist - yet :) [11:10] bigjools, right. it's in my notes to file a bug about that help text [11:11] matsubara: we recently added extra checks to make sure that you cannot init from a series that has builds or binaries in +queue that match the sources you're copying [11:11] bigjools, is there any way for me to cancel whatever is in +queue so I can play with the initialization? [11:11] bigjools: excellent, thanks, that seems to have worked [11:11] matsubara: check with rvba, he's doing some QA. Otherwise, pick different packagesets. [11:11] ah, so if I choose different sources that those in the +queue, I should be able to initialize? [11:11] cjwatson: the Windows approach..... [11:11] good. thanks! [11:14] bigjools, I don't see anything here: https://qastaging.launchpad.net/testbuntu/foo/+queue. is it another +queue page? [11:15] I tried all the filters and they return nothing [11:17] jelmer: great stuff btw. [11:27] matsubara: it's the parent's queue [11:30] bigjools, ah right. I tried with natty as the parent and the series initialized successfully. thanks! [11:30] matsubara: do you understand what is happening? [11:31] bigjools, I understood the check, don't know why it's in place though. [11:32] matsubara: that's what we'll explain in the help text :) [11:32] if the parent has the same packagesets queued, it won't allow derived ones to be initialized with the same packages. is that right? [11:32] ah, cool! [11:33] matsubara: it's packages that matter, not packagesets [11:33] but basically if there's a pending build upload or a build in progress, you can't inherit it [11:34] unfortunately I can't see https://qastaging.launchpad.net/ubuntu/oneiric/+queue as it's timing out. [11:34] yes that page is a PITA [11:35] right. is that because would be a waste of resources to initialize from a old, previously built for that parent series, given that we know there's a new build in progress? [11:36] matsubara: not exactly - the problem is that you get complications later because you built your own binaries that will differ from the ones the parent compiled [11:37] bigjools, ok. and could we not schedule the initialization to fire automatically after the in progress ones are finished? or this adds too much complexity to the use case? [11:40] matsubara: way too much :) [11:40] jml: thanks, which stuff? :) [11:40] bigjools, :-) [11:41] jelmer: getting rid of lptools stuff from ubuntu-dev-tools [11:41] jml: ah === henninge is now known as henninge-lunch [11:49] rvba: Will you be able to QA bug #826870 today? [11:49] <_mup_> Bug #826870: native syncs from Debian non-free default to Ubuntu universe

< https://launchpad.net/bugs/826870 > [11:50] We reverted bzr to 2.3 ? Looking at the merge conflict stable -> db-devel [11:50] stub: I believe 2.4 is still only in db-devel. [11:50] For testing on staging. [11:50] stub: no, but db-devel has 2.4 for testing [11:50] jelmer: ^^ [11:50] Heh. [11:50] Ta. I'll keep db-devel on 2.4 then. [11:51] wgrant: for that I would need my changes to make it into db-devel (I need to test that on DF) [11:51] rvba: stub should be arranging that as we speak. [11:51] rvba: But you can always merge devel on DF. [11:52] is there any news on pgbouncer and when staging will be updated? [11:52] jelmer: The next staging update is meant to work. [11:52] If it hasn't disabled itself due to failures... [11:52] Somewhat concerningly, it stopped logging 9 days ago. [11:52] stub: Do you know what's going on there? [11:53] stub: Doesn't look like it's going to retry, so the sudo access isn't much good. [11:53] (looking at https://staging.launchpad.net/successful-updates.txt) [11:53] losa ping: Lock needing to be killed for staging updates to work again? [11:53]