[08:18] <free> lifeless: for when you get online, I noticed a drawback with load_tests that I can't figure a workaround for
[08:18] <free> lifeless: if I want to run a single test (e.g. ./bin/testpy -m unittest2 txlongpoll.tests.test_frontend.QueueManagerTest.test_retry_after_timeout) I can't find a way to tell unittest2 that I want to use a custom suite (e.g. OptimisingTestSuite)
[08:27] <lifeless> free: I don't know what testpy is
[08:27] <lifeless> free: but the testtools stack supports --load-list
[08:28] <free> lifeless: afaics it's just a buildout-generated script, setting sys.path
[08:28] <wgrant> testpy is just the buildout-generated interpreter with the right sys.path
[08:28] <lifeless> free: so python -m testtools.run --load-list <(echo txlongpoll.tests.test_frontend.QueueManagerTest.test_retry_after_timeout)
[08:28] <lifeless> should do it
[08:28] <free> lifeless: I'd think that --load-list assumes that you can run a single test from the test program?
[08:29] <free> lifeless: and that honors load_tests?
[08:29] <free> --load-list
[08:29]  * free tries
[08:30] <free> lifeless, wgrant: hm stupid testpy wrapper is not happy with --load-list. It forces its own options :/
[08:31] <free> maybe I have to use --
[08:32] <wgrant> free: Does it?
[08:32] <wgrant> Looks like a normal interpreter to me.
[08:32] <free> wgrant: got it working with --
[08:32] <free> lifeless: ^^^ your hit worked, thanks!
[08:32] <free> hit/hint
[08:40] <lifeless> free: but yes, it would be nicer to load everything and then filter
[08:40] <lifeless> free: or load and go through load_tests but permit the single file still somehow
[08:40] <lifeless> free: patches (to the stdlib) sought!
[08:40] <free> lifeless: he
[08:41] <free> lifeless: I guess I'm happy enough for now, I also got everything working with testr (pushed a small fix to .testr.conf in that branch)
[08:47] <free> wgrant: you managed to run the tests with buildout/testpy? re your comment
[08:49] <wgrant> free: I did. A straight make check worked this time.
[08:49] <wgrant> (apart from the OptimisingTestSuite issue)
[08:49] <free> wgrant: okay, lemme test it on a pristine xenial container, I was working on a trusty one
[08:49] <wgrant> I tested precise and xenial.
[08:58] <free> wgrant: did you install twisted as a system package? since I think testtools' async test result is broken for Twisted 16.2.0
[09:01] <wgrant> free: buildout's twisted should be shadowing the system one.
[09:01] <wgrant> The failures I see go away if I hack loader.suiteClass to OptimisingTestSuite, so the inner suites are the right type.
[09:01] <wgrant> I don't think it's anything to do with Twisted.
[09:10] <free> wgrant: weird, I get it alright on a pristine xenial https://pastebin.canonical.com/157204/
[09:10] <free> wgrant: what was your process exactly?
[09:30] <wgrant> free: I didn't use testr, but testr shows the same thing. I don't see how that can work for you...
[09:30] <wgrant> free: If you pdb.set_trace() just before the return in load_tests and inspect result, do you see the same as I posted in the MP? an OptimisingTestSuite wrapping a normal TestSuite.
[09:30] <free> wgrant: yeah using testr or not doesn't matter, both "make check" and testr call bin/testpy -m subunit/run
[09:30] <free> wgrant: lemme try
[09:32] <wgrant> If I add a "loader.suiteClass = OptimisingTestSuite" just before the loader.discover it all works perfectly and quickly.
[09:32] <wgrant> But without it is is slow and explodey.
[09:32] <free> wgrant: fwiw OptimisingTestSuite should flatten all the tests it gets, so it shouldn't matter if some of its tests are wrapped
[09:32] <wgrant> Hmm.
[09:32] <wgrant> Mysterious.
[09:34] <free> wgrant: I'm not getting the tests wrapped, https://pastebin.canonical.com/157205/
[09:35] <wgrant> free: http://paste.ubuntu.com/16675791/ is the relevant snippet of my bin/testpy. Are your versions vaguely similar?
[09:35] <wgrant> I guess a testresources version difference could do this.
[09:36] <free> wgrant: there are differences, I have testtools 2.2.0 for instance
[09:36] <free> wgrant: that testresources is also quite old
[09:36] <free> wgrant: I have eggs/testresources-2.0.0-py2.7.egg
[09:36] <wgrant> I thought I cleaned properly, but maybe not.
[09:36] <wgrant> Right, that could be a problem.
[09:36] <free> wgrant: yeah most probably
[09:37] <wgrant> free: I guess you just pulled latest deps from PyPI?
[09:37] <wgrant> I used LP's download-cache, which is what has classically been used.
[09:37] <free> wgrant: yeah I created a pristine xenial container and went from there
[09:38] <free> wgrant: ah, well I might then check the version of available testresources and use the loader.suiteClass trick for older versions
[09:38] <free> wgrant: so the suite can pass with LP's cache
[09:38] <wgrant> free: Or I couild just throw a newer testresources in that branch :)
[09:39] <free> wgrant: as you want
[09:39] <free> wgrant: I have no problem in putting an if in that load_tests function
[09:41] <wgrant> free: New testresources fixes it. Will land. Thanks.
[09:42] <free> wgrant: cheers, I guess the flattening behavior is not there in 0.2.7
[09:47] <wgrant> free: Merged. Do feel free to poke me after less than six months next time :P
[09:48] <free> wgrant: hehe, I'll do :) it's basically because now I want to do some more (real) work and want the suite to not take 2/3 mins :)
[12:05] <rbasak> Spam: https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1585600
[12:05] <ubot5> Launchpad bug 1585600 in apache2 (Ubuntu) "Local Packers And Movers Barabazar Kolkata | Household Shifting" [Undecided,New]
=== JanC is now known as Guest85398
=== JanC_ is now known as JanC
[12:57] <estan> hi. is it allowed to upload packages to a PPA which installs to /opt/somepackage? that is, which gives dir-or-file-in-opt warnings.
[12:57] <estan> i know that is discouraged and against policy, but will PPA accept such a package?
[12:58] <rbasak> I believe it'll work fine in a PPA.
[12:58] <estan> alright. good to know. thanks.
[13:34] <gQuigs> what's the blocker for enabling 2fa without the beta group? (https://help.ubuntu.com/community/SSO/FAQs/2FA)
[13:35] <gQuigs> getting more interest from customers... and we could just "invite" them to the beta test through an internal article
[13:41] <cjwatson> gQuigs: That's SSO, not Launchpad.
[13:42] <cjwatson> Anyone can easily join the team though.
[13:43] <cjwatson> I don't know what the rationale is for it being team-limited at the moment.
[13:45] <gQuigs> right, oops..  they don't seem to have an obvious public channel.. maybe #ubuntu-website
[13:45] <gQuigs> thanks
[14:05] <cjwatson> gQuigs: #u1-internal on Canonical IRC
[14:06] <cjwatson> rather more likely to get a useful answer.  website folks don't do SSO
[14:06] <gQuigs> cjwatson: yup, just found it :)
[14:12] <gQuigs> thanks!
[18:00] <sidi> A question about multiarch. I have two packages, "f" and "x". They were both mono-arch. x depends on f. f became multiarch (so its headers are now in /usr/include/<arch>/f/f.h). x no longer builds on the PPA because it can't find the includes
[18:01] <sidi> Shouldn't single-architecture packages automatically look for headers in /usr/include *and* /usr/include/<ARCH> when building?
[18:01] <sidi> x is a library, if any relevant.
[18:02] <sidi> https://launchpadlibrarian.net/261464473/buildlog_ubuntu-vivid-amd64.garcon_0.4.0-2ppa9_BUILDING.txt.gz hat is the build log
[19:00] <sidi> right, nevermind, it seems a build dep was previously provided by an existing build-dep, and is now missing. my fault.
[19:24] <dobey> sidi: those types of questions are probably also better asked in #ubuntu-packaging as it's not about launchpad itself, but general packaging issue
[19:30] <sidi> dobey, oh, didnt know there was a specific channel. Fair enough, will go there next time, thanks