[01:28] cjwatson: Do you think your seriesless copy change is OK to deploy? [01:29] I'm just trying it out [01:29] If I can bend dogfood to my will [01:29] Heh [01:31] Hum, copying https://dogfood.launchpad.net/~cjwatson/+archive/openssh/+packages to https://dogfood.launchpad.net/~cjwatson/+archive/dogfood-copy-target/+packages not obviously successful [01:32] Oh, maybe copyPackages is just not set up for this to work [01:32] cjwatson: What broke? [01:32] Yeah, it worked as far as it went but from_series=None is useless [01:32] It may uniqueify the sources. [01:32] Ah [01:32] But the to_series=None side of it worked fine [01:32] Let's try +copy-packages then [01:35] https://dogfood.launchpad.net/~cjwatson/+archive/dogfood-copy-target/+packages looks OK to me, libpipeline was copied with +copy-packages [01:36] So it's just the permission bug you spotted, which I think we thought was currently fairly academic because PPAs are all published to main and that's the most restrictive component for Ubuntu? [01:36] Indeed, looks reasonable. [01:37] The only slight awkwardness with qa-oking that is that I attached the other branch to the same bug ... but I guess I can deal with that later [01:38] marked qa-ok for now anyway [01:38] cjwatson: It'll revert to qa-needstesting once the next branch hits qastaging. [01:39] Yeah [01:41] I'll do a bit more testing with the relaxed feature flags on dogfood tomorrow; I want to see whether the cause for soyuz.copypackageppa.enabled being off is still valid [01:42] AFAICS there'd be no reason not to experimentally lower soyuz.derived_series.max_synchronous_syncs after this is deployed, but it will probably only get any meaningful use if we can also switch on soyuz.copypackageppa.enabled [01:42] At least for beta testers [01:43] I can probably get the LibreOffice guys to try it ;-) [01:43] * cjwatson goes back to bed, immediate duty done [01:46] Night cjwatson, thanks. [02:22] Bleh, buildout is still convinced it wants 'django', but it's 'Django' :-( [02:22] o_O LP depends on django now? [02:24] StevenK: i have both Django and django in my versions.cfg :/ [02:26] Hm, I think that actually worked. [02:55] wallyworld_: r=me with a few small picks [02:56] thanks for the updates! [02:56] rick_h_: awesome, thanks for the detailed review [02:57] wallyworld_: yea, sorry for being picky, tring hard to take some ownership of the JS and help improve things so I appreciate the time to make the small improvements [02:57] rick_h_: no need to apologise, our js is poor in many places [02:58] so it's great you are doing this [02:58] rick_h_: many of the things you picked up on were cargo culted so there's a lot to fix [02:59] wallyworld_: yea, trying to do a goold old fashioned line the in sand. :) [02:59] wallyworld_: cool, I know I hate when I get long reviews so and irc isn't the best so want to make sure things come across well [02:59] well, we gotta start fixing somewhere/sometime, now is as good a time as any [03:00] with you and jcsackett and sinzui doing some awesome stuff I'm feeling there's hope [03:01] well, it's getting better slowly, but there's a lot of code to fix, and way too much code without test coverage [03:02] yea, it's scary sometimes, but as long as it's getting better [03:02] and hopefully as things get cleaner they get easier [03:02] Heh [03:02] Bug #800515 and bug #1016454 [03:02] <_mup_> Bug #800515: Enable "NotAutomatic: yes" for -proposed < https://launchpad.net/bugs/800515 > [03:03] Dupes filed a year to the day apart [03:03] having standard templates really helps, but there's still a lot of inconsistancy in terms of patterns etc [03:03] 3 hours off, though :( [03:03] wallyworld_: yea, it is. I've talked with deryck and one of my goals for this next year to try to get a couple of really polished JS modules as the gold standard. [03:03] if you've got a question, refer to these kind of things [03:04] but anway, past my bed time, but I saw your review come up and I wanted to try to unblock you asap. [03:04] rick_h_: we also have way too much code that just adds methods to a namespace instead of using widgets. i used widgets for the sharing stuff and it makes it sooo much easier [03:04] rick_h_: thanks for reviewing and unblocking, i really apprciate it [03:04] right, exactly. Widgets/Plugins, and I'm working on getting YUI 3.5 which adds Views [03:05] \o/or 3.5, can't wait [03:05] so looking forward to doing a real View containing several Widgets [03:05] s/or/for [03:05] yeah, mvc [03:05] yea, gotten through all the code in app/blueprint/bugs and onto the code module [03:05] I'll have an email in the morning with the work/hits so far. [03:05] and probably turning on the combo loader for all this week unless osmeone brings up a blocker [03:06] looking forward to it [03:06] so I'm pushing hard for 3.5 sooner vs later [03:06] anyway, wheee [03:06] night [03:06] awesome [03:06] goofnight [03:18] wgrant: care to update the disklessarchives diagram ? [03:22] lifeless: Have you finished your edits? [03:23] I believe so [03:23] it was slow on saving was all [04:49] wgrant: How do you feel about reviewing https://code.launchpad.net/~stevenk/launchpad/auditor-layer/+merge/112962 ? [04:59] StevenK: That looks pretty vile [04:59] Shouldn't we not be testing against the real thing? [04:59] How is its DB managed? [04:59] etc [05:01] Real thing, as in production auditor? [05:02] As this is an established pattern for at least longpoll [05:02] One pre-SOA service does not an SOA pattern make. [05:04] That ^ was the plan that lifeless and I agreed on at least. [05:09] wgrant: your double negative has confused me, can you rephrase ? [05:09] lifeless: I thought the SOA guidelines said to test against a (network) fake. [05:10] Not the real DB-backed service. [05:10] wgrant: yes, which sqlite is ~= too [05:10] wgrant: in memory sqlite that is [05:10] Not sure if the default config of auditor is in-memory, but that can be fixed. [05:11] wgrant: I agree its not as lean as a reimplementation with no django at all, for instance, but its certainly fitting the spirit of the SOA, that it should be cheap to spin up, config-free etc. [05:12] If it's throw-away SQLite, then sure :) [05:13] lifeless: The reference implementation shouldn't have Django at all either, but I think I lost that argument... [05:13] wgrant: my understanding is that it is, or will be. [05:13] I kindof think that that config should be in the fixture itself, to reduce the window for surprise, but for now its ok, I think. [05:35] wgrant: So it's still vile, or you're refusing to deal with the MP? :-P [06:26] wgrant: https://code.launchpad.net/~stevenk/launchpad/populate-branch-aag/+merge/112264 should be easy to review [07:38] good morning [07:40] can anyone help quickly with a testing question? [07:40] I have a test that does "login('email@address')" and I'd like to change it to use 'with person_logged_in(...)' [07:40] however the context manager takes a user object, not an email. [07:40] how does one get one of those from an email address === jam1 is now known as jam [07:43] jam: there is a test helper module with consants [07:43] jam: there is also a context manager that can deal with emails, I think [07:43] jam: but the specific answer is PersonSet.find(email), IIRC. [07:44] lifeless: there is admin_logged_in, anonymous_* celebrity_* and person_* [07:45] jam: Which test? [07:45] wgrant: I'm converting a doctest to a unittest [07:45] An email address is usually a sign that it's doing something horribly wrong. [07:45] Which address? [07:46] wgrant: https://code.launchpad.net/~jameinel/launchpad/py27-xmlrpc-auth-1019292/+merge/112792 [07:46] wgrant: it is just trying to assert that the XMLRPC api is using a different user than whatever the current context is [07:46] admin_logged_in is correct there. [07:46] Oh [07:46] Hm [07:47] It's using foo.bar, but just as some random user. That's a bit odd. [07:47] fubared [07:47] Since foo.bar is an admin, it's a bit silly to use it to test that it's something arbitrary user [07:47] Just create a new one [07:47] self.factory.makePerson() [07:47] Use that [07:49] jam: general rules of thumb: [07:49] - using existing admins is ok but not brillirant [07:50] wgrant: ObjectFactory has no attribute makePerson [07:50] - using existing persons is generally a bad idea as it ties you to sample data [07:50] - better to bring up just what you need from scratch using the helpers [07:58] jam: on developer LOC credit; the idea is to shrink, not stay static :) [08:01] jam: It does so... [08:02] lifeless: Creating new people frequently has major test suite performance implications, so I introduced admin_logged_in which always uses an existing one. [08:02] perhaps wrong test base class? [08:02] But in this case it's just one, and it's meant to be an arbitrary person, so makePerson is correct. [08:02] wgrant: yes, I know - tis a workaround though. === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [08:09] wgrant: Can I have your attention now? :-) [08:09] morning [08:12] StevenK: Indeed, sorry, let me see [08:13] 64 + branch_to_artifact = dict([(artifact.branch_id, artifact) [08:13] 65 + for artifact in artifacts]) [08:13] tsk [08:13] bad linebreak is bad [08:14] wgrant: What would you recommend? [08:18] StevenK: http://www.python.org/dev/peps/pep-0008/#indentation [08:18] StevenK: Convention is to say: [08:18] dict( [08:18] [(artifact.branch_id, artifact) for artifact in artifacts]) [08:18] branch_to_artifact = dict( [08:18] [(artifact.branch_id, artifact) for artifact in artifacts]) [08:19] That's the one. [08:20] And you can probably drop the square brackets [08:21] It's a list comphresion in a dict() call [08:21] StevenK: A generator expression in a dict() call should work just as well [08:27] wgrant: I've pushed up a change [08:32] StevenK: Thanks, r=me [09:10] https://code.launchpad.net/~laney/launchpad/db-proposed-not-automatic-pre-release/+merge/112134 updated; could somebody review/land? [09:43] jam: using `nohup bin/test -vvv >~/test_out.log 2>~/test_err.log &` seems good [09:49] mgz: testr run :> [09:51] testr was introducing subunit borkédness [09:51] lifeless: that doesn't give any progress feedback (vs tee), etc. And yeah, subunit had some 2.7 issues (skip tests would cause broken stream) [09:52] I think gmb fixed that with a newer zope.testing, though. [09:52] Yep. The dependency update should be landing in LP devel today. [09:53] gmb: I think it already did. At least, ISTR failing to start the test suite because it couldn't find a new enough zope.testing. Though maybe that was an unrelated zope.testing change [09:53] O.o [09:53] jam, devel still has p15, the 2.7 stuff is p16. [09:53] I think [09:53] * gmb checks [09:54] jam, Yes, Still on p15 in devel. [09:54] p16 will be on its way to ec2 shortly [09:58] gmb: probably devel rev 15470 which bumped it to r15. That was about 1.5weeks ago, but the checkout on my desktop was a bit old [10:04] jam: ah, true enough [10:04] jam: subunit itself should be 2.7 safe; been using it for months on 2.7 [10:05] lifeless: yeah, zope.testing didn't handle skips, and in 2.6 unittest didn't support them either. So testtools passed them through as success. [10:05] In 2.7, unittest gets an 'addSkip' which wasn't getting sent on to the subunit stream [10:05] ah [10:05] win ;> [10:05] so you would see the test start [10:05] but not ever finish [10:06] perhaps stopTest should emit some kind of warning if that happens. [10:08] jml: would have probably made tracking down the failure easier === matsubara is now known as matsubara-afk === benji changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: benji | Firefighting: - | Critical bugs: 4.0*10^2 === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [13:31] adeuring: ivory https://plus.google.com/hangouts/_/ef4e3eeb2016cc8910d1dc31949a0597da77f5f0?authuser=0&hl=en-US [14:04] benji: can you take a peek when you get a chance please? https://code.launchpad.net/~rharding/launchpad/code_yui35_one/+merge/113031 [14:04] rick_h_: sure [14:38] hm, test for js stuff hung at: [14:38] write(2, "\n(test:2741): Gdk-CRITICAL **: g"..., 10 [14:39] presumably related to not having X running [14:39] * mgz kills the layer [14:41] mgz: you might want to run inside of xvfb-run [14:42] presumably, will try that when the run completes [14:55] mgz: yea, I had to do that with running tests in lxc [14:57] mgz: lp.translations.tests.test_translationtemplatesbuildbehavior.TestTranslationTemplatesBuildBehavior.test_updateBuild_WAITING_notarballERROR:root:Slave returned no filemap. [14:57] ERROR:root:Build produced no tarball. [14:58] Failure in test lp.soyuz.tests.test_packageupload.PackageUploadTestCase.test_realiseUpload_for_delayed_copies [14:58] mgz: ^^ [15:01] jam: also lp.services.mail.tests.test_stub.test_simple_sendmail [15:02] again email header wrapping [15:02] Failed example: message['X-Generated-By'] [15:02] Expected: 'Launchpad (canonical.com); Revision="1999";\n\tInstance="launchpad-lazr.conf"' [15:02] Got: 'Launchpad (canonical.com); Revision="1999";\n Instance="launchpad-lazr.conf"' [15:03] slightly different doctest issue in lib/lp/services/webapp/doc/test_adapter.txt [15:06] sinzui: could you take a look at this? https://code.launchpad.net/~ivo-kracht/launchpad/bug-1013281/+merge/113062 [15:06] that last one is trivial, is a threading.Event object, and new in Python 2.7 returns the internal flag object rather than None [15:11] thank you ivory. Do you want me to land this? [15:14] sinzui: adeuring will do it but thank you nevertheless [15:16] Total duration of test run 18883.5 seconds. [15:23] benji: Thanks for the review! [15:24] jelmer: my pleasure [15:25] benji: could you help me to land https://code.launchpad.net/~laney/launchpad/db-proposed-not-automatic-pre-release/+merge/112134 please? [15:25] Laney: sure; how can I help? "ec2 land" it? [15:25] I don't know the commands you guys run :P [15:26] I guess that's the one :) [15:27] hmm, given that there is a DB change, I'll have to refresh my memory on the right way to handle that [15:28] ec2 land works for db-devel [15:28] Shouldn't require anything especially special [15:29] (The branch is targeted correctly) [15:30] yep, the target looks good; I'm firing off a job now [15:31] ta [15:41] Laney: the MP needs a commit message and then I'll try again. [15:42] benji: there === Ursinha_ is now known as Guest65630 [15:59] Laney: PQM doesn't like newlines in commit messages. I have removed them and submitted. The EC2 instance is starting now. [16:00] benji: OK. So it's just the "short description" it wants then, for future reference? [16:00] Laney: I don't know of a prescribed guideline. I like your commit message as-is. [16:01] well I usually try to keep the first line under 72ish when writing them === salgado is now known as salgado-lunch === matsubara-afk is now known as matsubara === salgado-lunch is now known as salgado [17:10] benji: I have a couple of split-outs from queue-api up for review to start with; do those look like a more reasonable level of granularity? [17:11] cjwatson: I'll take a look. [17:11] I'm still juggling branches locally to find the next thing to separate [17:13] Probably the read-only bits of the webservice exports [17:27] czajkowski, test-system failures are critical, not low. Lp's mailman installation is brittle, we cannot tolerate missing test coverage [17:31] cjwatson: looking good; the only thing I spotted was some extra parens (details in the comment) [17:46] sinzui: I had some luck poking things with mailman, manually creating parent directories makes tests pass, but then oddly the buildmailman.py in make starts failing from not having any lists [17:46] does buildmailman.py just need fixing to be better about creating needed directories and tolerating different state? [17:47] mgz, I think it needs fixing for the lxc case. Mailman always has at least one list. There is a control list that out code must discount. if it was not created, Mailman goes tits up [17:48] mgz, Other developers have reported problems were /tmp/var/mailman was not created properly, so I think this is an old issue [17:51] did seem odd no one else had run into problems, I'll dig a bit further and see where I get [17:57] gary_poster: indeed [18:29] benji: ta === matsubara is now known as matsubara-afk [20:16] okay, that's all the remaining py27 things I've logged as having issues, though didn't get complete run due to mailman and X issues [21:17] jcsackett: ping, if you remove the renderUI in the extending class does it still work right? You shouldn't need it since it's not doing anything extra? [21:27] jcsackett: r=me with the two notes. === salgado is now known as salgado-afk [22:14] StevenK, wallyworld_, jcsackett https://dev.launchpad.net/Projects/Disclosure [22:21] https://bugs.launchpad.net/launchpad/+bugs?field.tag=disclosure+privacy-transitions&field.tags_combinator=ALL [22:33] https://bugs.launchpad.net/launchpad/+bugs?field.tag=disclosure+information-type&field.tags_combinator=ALL === wgrant is now known as Guest78124 === Guest78124 is now known as wgrant_ [22:36] Grar [22:37] Haha [22:37] This 3G is so slow I'm not actually sure it's 3G at all [22:38] Hahahaha, Optus 3G [22:39] No mobile coverage is very good around here :) === benji changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 4.0*10^2 [23:51] ooh [23:51] flashing lights [23:51] maybe they have fixed it [23:52] wgrant: where are you ? [23:53] lifeless: Some HFC fault took the entire street's phone and Internet out from about 4am until 90 seconds ago. [23:55] wgrant: \o/ [23:56] wgrant: Six hour outage. Pretty short for Optus. [23:56] Apparently their monitoring sucks enough that I was the first to report it, at around 8:10.