[00:30] <wgrant> "Add a proportion of the maximum bug heat to a bug's heat for every day since the bug was created.
[00:30] <wgrant> "
[00:30] <wgrant> Isn't that the opposite of what one would normally want?
[00:35] <thumper> wgrant: :)
[00:35] <thumper> the proportion could be negative
[00:36] <wgrant> That's true.
[00:37] <wgrant> In fact it seems to add a quarter of the max heat divided by the number of days since creation.
[01:24] <lifeless> thumper: ping
[01:39] <thumper> lifeless: pong
[01:39] <lifeless> hey
[01:39] <lifeless> I'm on airport wifi
[01:40] <lifeless> do you have any other issues with the patch ?
[01:40] <lifeless> I realise its not a priority, but i have a plane flight where I can polish it, if more is needed
[01:40] <thumper> I've not looked at it, chasing other issues
[01:40] <lifeless> ok
[01:44] <wgrant> lifeless: Running back already? :P
[01:45] <lifeless> wgrant: speaking at devopsdays tomorrow morning
[01:45] <lifeless> wgrant: then UDS
[01:45]  * wgrant should probably work out what needs doing before UDS.
[01:45] <lifeless> 'stuff'
[01:45] <lifeless> wgrant: are you going to be at UDS ?
[01:45] <wgrant> lifeless: I am.
[01:46] <lifeless> wgrant: cool. And have you applied for the code team job position yet ?
[01:46] <lifeless> :)
[01:46] <wgrant> Heh, no.
[01:51] <lifeless> -> .au - ciao.
[01:59] <persia> .nz -> .au again already?  What it that uninspiring?
[01:59] <wgrant> Heh.
[02:00] <wgrant> Hm, Maverick doesn't exist yet :(
[02:03] <persia> Probably won't until next week, I'd think.  Toolchain stuff is happening in PPAs (fear ye all who plan to run ports during early maverick)
[03:06] <cody-somerville> what have I done wrong? why is this test failing like this? http://pastebin.ubuntu.com/424952/
[03:09] <StevenK> cody-somerville: The test isn't expecting /beta/ in the resource links
[03:09] <wgrant> No.
[03:09] <wgrant> security_contact_link is in the wrong place in the test.
[03:09] <wgrant> It should be before self_link, but you've put it after.
[03:09] <wgrant> The rest of the diff is not real.
[03:10] <StevenK> Oh, that bloody ... versus real-text garbage?
[03:10] <wgrant> Yes.
[03:10] <wgrant> It is worse than stupid.
[03:15] <cody-somerville> wgrant, ty
[03:22] <thumper> wgrant: how do I stop the automatically stated librarian and other thingy?
[03:22] <thumper> wgrant: for tests
[03:23] <wgrant> thumper: bin/kill-test-services
[03:24] <wgrant> But if you want to run the whole test suite, you probably have to unset LP_PERSISTENT_TEST_SERVICES too.
[03:24] <wgrant> I've found some of the Foundations tests check that the librarian shuts down and such, so fail when it's on.
[03:37] <wgrant> Why do most project pages have a warning sign next to "Submit code", which I can do nothing about?
[03:46] <mwhudson> probably because they "do not officially use launchpad for codehosting"
[03:46]  * mwhudson is guessing
[04:16] <thumper> wgrant: I don't know how you work with soyuz
[04:16] <thumper> wgrant: example of warning?
[04:18] <wgrant> thumper: See the involvement portlet on https://edge.launchpad.net/soyuz
[04:18] <wgrant> You may have to be unauthenticated.
[04:18] <wgrant> What is troubling you about Soyuz?
[04:19] <wgrant> It's a whole lot better now than when I first worked it out, when nobody had run much of it locally for years...
[04:49] <wgrant> The sole source on https://dogfood.launchpad.net/~ubuntu-chumby-hackers/+archive/ppa/+packages was a test recipe build, right?
[04:49] <wgrant> I cannot find the log for it anywhere around that time in the librarian.
[04:49] <wgrant> Was it not stored properly?
[05:26] <wgrant> Grgh. There's no solution to http://launchpadlibrarian.net/46467230/wgrant-lintian-master.log, is there?
[05:27] <mwhudson> no, i don't think so :(
[05:27] <mwhudson> well apart from slapping bzr around a bit to be less picky
[05:29] <wgrant> Hmm, I might do that rather than using git.
[05:58] <persia> Should https://dev.launchpad.net/Getting work on lucid now, or would it be better to do it in an older chroot/VM ?
[06:01] <mwhudson> persia: i've been developing on lucid since just after beta1 and not had any real issues
[06:01] <wgrant> It will work fine on Lucid.
[06:02] <wgrant> LP even works fine on Python 2.6 now, although it's not the default.
[06:02] <persia> Thanks.
[06:13] <thumper> I think we should force it to python 2.6
[06:14] <thumper> so we can stop importing with from the future
[06:14] <StevenK> from __future__ import braces
[06:15] <wgrant> thumper: We can't until Lucid is in the DC.
[06:15] <wgrant> But yes, that's the plan.
[06:15] <thumper> ah
[06:16] <thumper> ok
[06:17] <cody-somerville> wtf
[06:17] <wgrant> More doctest diff screwyness?
[06:18] <wgrant> Or something more sinister?
[06:18] <cody-somerville> lets say you have a bugtask that is assigned to a suspended user
[06:18] <cody-somerville> lets say you have a script to generate a report about bugs in a project
[06:19] <wgrant> Yes, you have to catch the 410.
[06:19] <cody-somerville> running said script on project that has a bugtask that has an assignee that is suspended == FAIL
[06:19] <wgrant> Yes, this is probably stupid.
[06:19] <cody-somerville> PLUS I get a nice text/html response
[06:19] <wgrant> Indeed.
[06:38] <wgrant> thumper: So, what was your Soyuz objection?
[06:47] <thumper> wgrant: I was reading tests
[06:47] <wgrant> thumper: Ahahahahahahahahah fool.
[06:48] <wgrant> Big mistake.
[06:48] <thumper> wgrant: I had to fix a test
[06:48] <wgrant> This is Soyuz.
[06:48] <thumper> I wasn't doing it out of choice
[06:49] <wgrant> I occasionally try to rip apart one of the multi-thousand-line doctests.
[06:49] <wgrant> But then I realise that it's all intricately woven together, and removing just one bit will make the whole thing collapse into a steaming pile of Soyuz.
[06:51] <wgrant> What?
[06:51] <wgrant> You're killing off buildd-slavescanner.txt?
[06:51] <wgrant> Really really really bad idea
[06:51]  * wgrant looks.
[06:52] <wgrant> buildd-slavescanner.txt is the main test that tells us that the house of cards is still standing :(
[06:52] <wgrant> What was the failure?
[06:55] <thumper> wgrant: it was a subtle text match failure
[06:55] <thumper> wgrant: which I didn't have time to fix
[06:55] <thumper> I'm not killing it off
[06:55] <thumper> just disabling it briefly
[06:55] <thumper> I expect a soyuz person to fix it
[06:55]  * cody-somerville frowns.
[06:55] <persia> Isn't that the bit that wedges all the buildds every so often?
[06:56] <persia> Or rather, the workaround therefor?
[06:56] <wgrant> persia: It is the thing that does all the talking to the buildds.
[06:56] <wgrant> It tests that builds happen and work.
[06:56] <wgrant> It is about the only test that does so :/
[06:56] <persia> That's what I thought.
[06:58] <cody-somerville> Well, I hope it doesn't mean Soyuz will be broken after the next deployment.
[06:59]  * noodles775 feels he missed an important conversation?
[06:59] <cody-somerville> noodles775, LP #572005
[06:59] <mup> Bug #572005: Disabled test buildd-slavescanner.txt <Soyuz:Triaged> <https://launchpad.net/bugs/572005>
[06:59] <StevenK> cody-somerville: It's a failed test, it doesn't mean the world is ending. And PQM is still open for testfixes
[07:00] <thumper> plz disable soyuz, kthxbye
[07:00]  * thumper EODs (for now at least)
[07:25] <adeuring> good morning
[08:49] <mrevell> Hello
[09:23] <wgrant> bigjools: Morning.
[09:23] <bigjools> g'day
[09:26] <wgrant> bigjools: So, we need a script to populate lots of SPR rows with their changelogs. http://pastebin.ubuntu.com/425094/ is my first pass, and it seems to work OK. But I'm not sure how Storm is going to handle the ResultSet mutating over the several days that it will likely take to run.
[09:27] <bigjools>  /o\
[09:28] <bigjools> wgrant: I suggest you use process_in_batches and partial commits
[09:28] <bigjools> can't hold txn locks for days
[09:28] <wgrant> bigjools: I commit after each SPR.
[09:29] <bigjools> ah ok - I can't read
[09:29] <bigjools> if it bails out half way, will it restart in the right place?
[09:29] <wgrant> I should probably read process_in_batches at some point.
[09:29] <wgrant> Er, yes, if I hadn't omitted a clause from my rewritten query.
[09:30] <wgrant> It was meant to have a changelog=None, so it will skip any that already have it set.
[09:31] <bigjools> :)
[09:31] <bigjools> we should ask stub to take a look
[09:31] <wgrant> Probably.
[09:36] <wgrant> http://pastebin.ubuntu.com/425099/ has the changelog=None.
[09:37] <wgrant> stub: Does that script make you cry?
[09:50] <wgrant> BjornT: A couple of weeks ago, Zopeless email was changed to use raw_sendmail, which appears to use the mail delivery utility, so I think it probably is being used to send email (re. bug #572077)
[09:50] <mup> Bug #572077: Scripts are starting up the queued mail runner <current-rollout-blocker> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/572077>
[09:50] <wgrant> db-devel r9071.2.33, lib/lp/services/mail/sendmail.py
[09:51] <wgrant> Actually, the db-devel r9205 diff for that file is better.
[10:00] <BjornT> wgrant: oh, thanks. it's unclear whether it's it was an intentional change, or if he wanted to change test dev environment only.
[10:01] <wgrant> I was suspicious that exactly this would happen, but I was assured it had been checked, so it might be irrelevant.
[10:05] <BjornT> bigjools: can you take a look at bug 572077, and comment on whether this affects soyuz? at least in the past, soyuz used the fact that mail were sent even if the transaction was aborted.
[10:05] <mup> Bug #572077: Scripts are starting up the queued mail runner <current-rollout-blocker> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/572077>
[10:07] <stub> wgrant: Ideally, it would be using DBLoopTuner to be database friendly etc. This would alleviate concerns with iterating over a huge result set for several hours too
[10:10] <stub> wgrant: Looks fine apart from that. We can stick a time.sleep() to make it db friendlier if you can't be arsed switching it to looptuner format
[10:12] <stub> wgrant: This is a run-once script or is it going to become a cron task?
[10:13] <bigjools> BjornT: that is almost certainly the case
[10:13] <wgrant> stub: Run once.
[10:13] <wgrant> bigjools, BjornT: process-upload.py still relies on it to send rejection emails.
[10:13] <wgrant> stub: New uploads are populated by the upload processor.
[10:16] <bigjools> BjornT, wgrant: see https://bugs.edge.launchpad.net/launchpad-foundations/+bug/29744
[10:16] <mup> Bug #29744: In Zopeless, mails should be sent only when the transaction is commited <email> <infrastructure> <tech-debt> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/29744>
[10:16] <bigjools> and
[10:16] <bigjools> lib/lp/archiveuploader/uploadprocessor.py at line 409
[10:16] <bigjools> BjornT: so basically we will lose upload rejection emails
[10:17] <bigjools> BjornT: the change will have to be backed out
[10:17] <wgrant> The change was only there in the first place to allow testing of email-generating scripts.
[10:17] <wgrant> Which is a really good thing, but not if it breaks this...
[10:17] <wgrant> s/testing/dev testing/
[10:22] <BjornT> bigjools: agreed
[11:03] <deryck> Morning, all.
[13:53] <cody-somerville> who ever manages the launchpad-dependencies package should add postgresql-plpython-8.3 as a dependency.
[13:57] <henninge> wgrant: ping
[14:00] <wgrant> henninge: Hi.
[14:01] <henninge> wgrant: Hi! ;)
[14:01] <henninge> wgrant: I am trying out the build slave locally again, driging it through RPC
[14:01] <henninge> I got as far as this:
[14:01] <henninge> >>> proxy.status()
[14:01] <henninge> ['BuilderStatus.WAITING', 'BuildStatus.OK', '1-1', {'translation-templates.tar.gz': '5e385d8a01320b5f9ee59d68c7e63229a252daed'}, '']
[14:02] <wgrant> The build has completed successfully.
[14:02] <henninge> wgrant: I'd like to actually retrieve the file from the slave now. Any idea how to try that out.
[14:02] <henninge> ?
[14:02] <wgrant> henninge: Try http://localhost:8221/filecache/5e385d8a01320b5f9ee59d68c7e63229a252daed
[14:03] <henninge> oh, that easy ;)
[14:04] <henninge> wgrant: great, that worked. Thanks a lot! ;)
[14:04] <wgrant> Great.
[14:12] <lifeless> cody-somerville: why? we're moving to 8.4 / have moved to 8.4
[14:12] <noodles775> Why does running `make newsampledata` on a fresh db-devel (after make schema) result in an 8000line difference between current.sql and newsampledata.sql?
[14:12] <wgrant> noodles775: Yesterday or the day before, 16000 lines of sampledata reorderings were landed.
[14:13] <wgrant> I do not know why, since the script is meant to order them deterministically.
[14:13] <wgrant> I say clobber.
[14:14] <wgrant> Perhaps somebody dumped them manually.
[14:14] <noodles775> Yeah, I'll create a separate branch that does exactly that so I can see just my diff.
[14:14] <noodles775> Thanks wgrant
[14:14]  * wgrant disappears.
[14:15] <noodles775> Night!
[14:16] <noodles775> Hi abentley! Is there a way I can insert a pipe at the start of my pipeline?
[14:16] <abentley> noodles775, no.
[14:16] <abentley> noodles775, Why isn't it working?
[14:18] <deryck> intellectronica, hi.  Was there a branch for bug 567379?
[14:18] <mup> Bug #567379: Recalculate bug heat more frequently <story-bug-heat> <Launchpad Bugs:In Progress by intellectronica> <https://launchpad.net/bugs/567379>
[14:18] <noodles775> abentley: I'm not sure what you mean... bzr pipeline is working perfectly for me, I just didn't know if there was a way to insert a pipe *before* my first pipe... but I can get around it another way.
[14:18] <abentley> noodles775, use --before
[14:19] <noodles775> abentley: thanks (sorry, I just checked the bzr help pipeline, but forgot to check bzr help add-pipe)
[14:21] <cody-somerville> lifeless, okay, who ever manages the launchpad-dependencies package should add postgresql-plpython-8.4 as a dependency. :P
[14:27] <lifeless> cody-somerville: Isn't it in the production deps list already? [ there are multiple dep packages ]
[14:38] <stub> noodles775, wgrant: You get huge diffs between different PG releases as the dump order changes
[14:41] <noodles775> stub: Ah, thanks... but we should all be using the same PG version right? (I'm still wondering why I see such a big diff for a clean db-devel locally).
[14:51] <stub> noodles775: Some people are on PG 8.4. That process got stalled a bit.
[15:49] <jml> intellectronica, mars: https://code.edge.launchpad.net/~jml/launchpad/still-more-tests-for-ec2/+merge/24503 -- we discussed this the other day
[15:53] <intellectronica> jml: great, thanks for making this change.
[15:53] <jml> intellectronica, np
[15:54] <mars> jml, botched merge, or wrong merge target branch?
[15:56] <jml> mars, Launchpad botched the merge.
[16:05] <allenap> danilo_: I see you replied to the blog post <http://blogs.gnome.org/johannes/2010/04/29/downstream-bug-reports-fail/>. I still get a server error, so I can't post my reply.
[16:42] <jml> mars, intellectronica: the diff is fixed if either of you would like to review it.
[16:43] <mars> ah, much saner +/- numbers
[16:44] <mars> "FlagFallStream", nice object name
[16:44] <jml> thanks. actually, I think I should delete it since it's not being used any more.
[16:45] <intellectronica> mars: so are you picking this up? if not i'm happy to review it later.
[16:46] <mars> intellectronica, to be honest, I would be happier if you reviewed it.  I'm lack confidence at the moment.
[16:46] <mars> apparently I'm also lack grammar
[16:47] <intellectronica> :)
[16:47] <intellectronica> jml: i'll give it a go soon, i just want to finish something first
[16:47] <jml> intellectronica: thanks.
[16:54] <james_w> losa ping, please can we create source package branches for maverick?
[16:57] <james_w> https://lists.launchpad.net/launchpad-dev/msg03227.html for how
[16:57] <james_w> could someone also check the SQL within? Max suggested it was not what we wanted.
[16:58] <Chex> james_w: sure, looking
[17:00] <james_w> thanks
[17:15] <intellectronica> jml: approved
[17:15] <jml> intellectronica: thank you.
[17:16] <jml> oh crap
[17:16] <jml> I'm not allowed to land things, right
[17:17]  * jml sads
[18:17] <jml> g'night all.
[19:33] <deryck> bdmurray, ping
[19:38] <bdmurray> what's up?
[19:44] <bdmurray> deryck: pong
[20:32] <mars> bac, do you think your branch for Adi was eaten by the same ec2 hang bug?
[20:32] <bac> mars: dunno.  probably.  but i have no proof
[20:33] <mars> ok
[20:33] <mars> thanks
[21:13] <sinzui> bac: ping
[21:13] <bac> sinzui: yes?
[21:14] <sinzui> I am trying to make sense of this: https://edge.launchpad.net/ubuntu/maverick 1. I did not link a52dec 4 hours ago. I may have a few days ago
[21:15] <sinzui> bac: I suspect the count of packages is odd because there SPPH will not exist until maverick is fully build
[21:15] <sinzui> built
[21:15] <sinzui> bac: mayby the copy script ran 4 hours ago and I was the last person to link a lucid package?
[21:17] <bac> sinzui: perhaps.  too bad https://edge.launchpad.net/ubuntu/lucid/+source/a52dec doesn't tell you who/when it was linked
[21:17] <sinzui> bac: The data is in the db. I can see it when it gets to staging
[21:18]  * sinzui looks a lucid to see if he is the last user
[21:19] <sinzui> I think the first 20 on +needs-packaging links actually needs project registration too
[21:19] <sinzui> I was not the last user
[21:21] <sinzui> bac: I am going to assume the series setup script was run 4 hours ago and it is a coincidence that my name is in the list.
[21:22] <bac> ok
[21:22] <sinzui> I verified that the last packages linked in lucid are also linked in maverick
[21:22] <sinzui> That was 5 months to verify the script really works in production
[22:28] <flacoste> sinzui: nice blog post about the proposed changes! are you going to send out an email to launchpad-dev pointing to the blog post
[22:28] <flacoste> sinzui: and this will be a very worthwhile enhancement
[22:29] <sinzui> I am on Monday. I see the pics are missing the private bugs toggle