[00:06] <LPCIBot> Project parallel-test build (7): STILL FAILING in 2 hr 9 min: https://hudson.wedontsleep.org/job/parallel-test/7/
[00:13] <mars> wgrant, did I hear you say you could reproduce the windmill threading error locally?
[00:13] <mars> or something similar
[00:15] <lifeless> mars: bug 461760
[00:15] <_mup_> Bug #461760: Shouldn't check for left-over threads between Windmill tests <story-windmill-layer> <Launchpad Foundations:Fix Released by bjornt> <https://launchpad.net/bugs/461760>
[00:18] <lifeless> q
[00:20] <mars> lifeless, thaks
[00:20] <mars> thanks
[00:29] <abentley> lifeless: when I have claimed a review, feel free to review it yourself, but please don't set the status "approved" without letting me get my 2 cents in.
[00:30] <lifeless> abentley: ok, can do
[00:30] <lifeless> I thought you had EOD'd
[00:30] <lifeless> and curtis had addressed your point
[00:30] <abentley> lifeless: thanks.
[00:31] <abentley> lifeless: I have EOD'd.  Curtis should have also EOD'd by now.  I would have reviewed it tomorrow, before he clocks in.
[00:32] <lifeless> did you have other unaddressed concerns?
[00:34] <abentley> lifeless: I'm a little worried by what he wrote about the diff being a lot bigger due to alphabetical sorting.
[00:34] <abentley> lifeless: It's a principle thing.  If I claim a review, it means I intend to do it.
[00:34] <wgrant> mars: I have had several EC2 runs fail with a LayerIsolationError after test_slow_threads.
[00:35] <wgrant> mars: It manifests itself as a "make check returned an error code, but no tests failed" sort of thing, which you have to dig through the subunit log for.
[00:35] <lifeless> wgrant: mars: I can trigger that by just running it; OTOH I'm futzing with the infrastructure in my branch, so its not necessarily representative
[00:35] <lifeless> abentley: I've acked your request; I'm sure you were doing the review.
[00:36] <abentley> lifeless: I don't follow.
[00:36] <lifeless> abentley: on the thing you're worried about, I've noticed many imports in lib/canonical were not normalised by edwins script
[00:36] <lifeless> abentley: I've said 'ok, I won't set the status on reviews you've claimed'
[00:38] <wgrant> mars: Now I think about it, my log in bug #661931 might well be that issue.
[00:38] <_mup_> Bug #661931: make check sometimes fails on EC2 without test failures <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/661931>
[00:38]  * wgrant checks.
[00:38] <wgrant> Indeed it is.
[00:38] <abentley> lifeless: you went on to discuss the proposal as if I was concerned about the specific state of the proposal, so I wanted to make it clear that the specific circumstances of the proposal weren't my motivation.
[00:38] <lifeless> abentley: ok; I understood you to be making a generic request.
[00:39] <lifeless> I was also interested if in the specific case I had missed something important to the review.
[00:39] <rockstar> wallyworld__, awesome.
[00:39] <lifeless> e.g. 'could I, if I had been the original reviewer, have missed something important'
[00:40] <wallyworld__> rockstar: i don't know why it fails but the change brings the tests in line with how others have been written. it seems the flakiness on *my* system has been solved at least
[00:40] <rockstar> lifeless, I hate windmill's random failures.
[00:40] <rockstar> wallyworld__, yeah, the flakiness may or may not be fixed for other systems.
[00:41] <abentley> lifeless: Aside from the "this is much bigger than before" thing, I'm not aware of anything more to check.
[00:41] <wallyworld__> rockstar: i'm running it through ec2 to see what happens. consider it an experiment :-) i'll let you know how it goes
[01:11] <lifeless> grrr zcml
[01:54] <LPCIBot> Project devel build (134): STILL FAILING in 3 hr 32 min: https://hudson.wedontsleep.org/job/devel/134/
[01:54] <LPCIBot> * Launchpad Patch Queue Manager: [r=allenap,
[01:54] <LPCIBot> bac][ui=none][no-qa] extract some refactorings from the abandoned
[01:54] <LPCIBot> check-in-wadl branch
[01:54] <LPCIBot> * Launchpad Patch Queue Manager: [r=adeuring][ui=none][bug=126516] Refactor doctest for bugtask status
[01:54] <LPCIBot> changes into separate unit test and documentation.
[01:54] <LPCIBot> * Launchpad Patch Queue Manager: [r=rockstar][ui=none][incr][bug=663436] Automatically determine (and
[01:54] <LPCIBot> actually enforce) the expiration date of an OAuth request token,
[01:54] <LPCIBot> freeing up the expiration_date field to be used for other purposes.
[01:54] <LPCIBot> * Launchpad Patch Queue Manager: [r=gmb][ui=none][bug=636060] Adds latest upstream release version to
[01:54] <LPCIBot> the sourcepackage upstream portlet.
[01:54] <LPCIBot> * Launchpad Patch Queue Manager: [r=rockstar][ui=rockstar][bug=652126] Moves statistic information on
[01:54] <LPCIBot> the product branches view into the main page and out of the
[01:54] <LPCIBot> sidebar, where it didn't really fit.
[01:57] <lifeless> gary_poster: / benji: if either of you are still around
[01:57] <lifeless> I'd love some comment/tip on bug https://bugs.edge.launchpad.net/launchpad-foundations/+bug/663620
[01:57] <_mup_> Bug #663620: generate overrides writes to global state <paralleltest> <Launchpad Foundations:New> <https://launchpad.net/bugs/663620>
[02:00] <lifeless> wgrant: aroud ?
[02:46] <lifeless> hmm
[02:46] <lifeless> file:///var/launchpad/sourcecode/pygettextpo/ needs an upgrade to 2a
[02:54] <mwhudson> on ec2?
[02:55] <lifeless> yeah
[02:56] <lifeless> also
[02:56] <lifeless> Updating bzr-loom to revision 48
[02:56] <lifeless> Doing on-the-fly conversion from RemoteRepositoryFormat(_network_name='Bazaar repository format 2a (needs bzr 1.16 or later)\n') to RepositoryFormatKnitPack1().
[02:56] <lifeless> This may take some time. Upgrade the repositories to the same format for better performance.
[02:56] <lifeless> starting upgrade of file:///var/launchpad/sourcecode/bzr-loom/
[02:56] <lifeless> Updating pygettextpo to revision 24
[02:56] <lifeless> Doing on-the-fly conversion from RemoteRepositoryFormat(_network_name='Bazaar repository format 2a (needs bzr 1.16 or later)\n') to RepositoryFormatKnitPack1().
[02:56] <lifeless> This may take some time. Upgrade the repositories to the same format for better performance.
[02:56] <lifeless> starting upgrade of file:///var/launchpad/sourcecode/pygettextpo/
[02:58] <mwhudson> making a new image with bin/ec2 update-image should work for that
[02:59] <LPCIBot> Project db-devel build (86): STILL FAILING in 3 hr 34 min: https://hudson.wedontsleep.org/job/db-devel/86/
[02:59] <LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 11747
[02:59] <LPCIBot> included.
[03:20] <wgrant> lifeless: Hi.
[03:21] <lifeless> wgrant: hi, I was going to ask if you'd looked into a particular subsystem
[03:22] <lifeless> but I found the damage
[03:22] <lifeless> (tight coupling)
[03:22] <wgrant> What's broken?
[03:23] <lifeless> if you run a unit test that uses TestMailer in a config with an instance name other than testrunner
[03:23] <lifeless> then it uses a real mailer
[03:24] <wgrant> Hah.
[03:36] <wgrant> lifeless: How are you going to deal with tests that touch the FS?
[03:37] <wgrant> Identify all the relevant config values, push a new config overlay, and hope that everything uses the config?
[03:38] <lifeless> wgrant: BaseLayer.config.add_section(...)
[03:38] <lifeless> wgrant: + grep for the existing literal to find things that don't use the config
[03:38] <lifeless> wgrant: its working so far :)
[03:38] <lifeless> wgrant: want to help?
[03:41] <wgrant> lifeless: The publisher currently stores its path config in the DB, but that will be fixed soon.
[03:41] <lifeless> the publisher layer/fixture can just update that config
[03:42] <lifeless> depend on the DatabaseLayer (it should anyhow0
[03:42] <wgrant> True.
[03:42] <lifeless> my databasefixture branch is sufficient for you to experiment with that
[03:50] <lifeless> wgrant: when do you start?
[03:50] <wgrant> lifeless: With Soyuz?
[03:50] <lifeless> yeah, whatever that means :)
[03:50] <wgrant> Heh.
[03:50] <wgrant> Dec 13
[03:52] <lifeless> cool
[03:54] <mars> lifeless, have a moment for a question about testing?
[03:54] <lifeless> of course
[03:54] <lifeless> irc or voice
[03:54] <mars> irc is fine
[03:55] <lifeless> ... :)
[03:55] <mars> lifeless, so - layers are bad, test suite setup and teardown are bad.  How then do I implement a fixture that must run for the duration of a test suite?  Like, for example, rewriting the BaseWindmillLayer.
[03:55] <lifeless> ok
[03:55] <lifeless> so the layers core implementation has some problematic aspects
[03:56] <lifeless> we can get to a tolerable place without replacing it.
[03:56] <mwhudson> fixtures + testresources!
[03:56] <lifeless> I would do this.
[03:56] <lifeless> Write a Fixture
[03:56] <lifeless> have a layer which does
[03:56] <lifeless> cls._fixture = MyFixture()
[03:56] <lifeless> cls._fixture.setUp()
[03:56] <lifeless> ...
[03:56] <lifeless> cls._fixture.cleanUp()
[03:56] <lifeless> at the relevant places
[03:57] <lifeless> you can see this sort of thing emerging in my parallel test branches
[03:57] <lifeless> e.g. lp:~lifeless/launchpad/databasefixture
[03:57] <lifeless> the reset method on a fixture is what you'd call in testSetup
[03:57] <mars> ah
[03:58] <mars> suites can't do that, can they?
[03:58] <mars> testSetup
[03:58] <mars> you would have to use layers
[03:58] <lifeless> testresources can do it
[03:58] <lifeless> but I wouldn't try and mix n match
[03:58] <lifeless> testresources is a complete replacement for layers
[03:59] <lifeless> for bonus points, you could write an adapter from Fixture to Layer as a currying helper
[04:00] <mars> ok, so that makes sense to me - that covers what we have, what is available, and why we do what we do now
[04:00] <mars> cool
[04:00] <lifeless> would you like me to describe this in a more permanent fashion somewhere?
[04:01] <lifeless> I wasn't really going to bother until tackling removal of layers was a feasible do-it-soon kindof project
[04:01] <lifeless> but if you're liking what you're seeing of fixtures, perhaps its worth writing it up earlier
[04:01] <mars> lifeless, a message to the dev list would be permanent enough IMHO. And anyone else interested in test engineering will see it there.
[04:02] <mars> lifeless, you explained it quite concisely
[04:03] <lifeless> heh :)
[04:03] <mars> heck, you could copy-n-paste from 22:55 through 23:00 and be done with it :)
[04:03] <lifeless> the [dis]advantange of a more permanent record is that folk may have less context and desire more exposition
[04:05] <mars> can't help that - people are going to start asking "what are fixtures?" and "why do layers suck?" at some point anyway.
[04:06] <mars> what other question might people ask if they read such a message?
[04:07] <lifeless> does it make coffee?
[04:07] <lifeless> what does it look like in anger ?
[04:07] <mars> that's a good one
[04:08] <lifeless> one thing that fixtures doesn't do well yet is arbitrary object graphs - the delegation to a child fixture can't handle anything other than linear lists (setUp doesn't cleanly skip if already setUp)
[04:10] <lifeless> totally fixable, I just need to port that logic from testresources
[04:12] <mwhudson> lifeless: aaaaaargh, since you created your testtools branch it looks like other branches have landed that import them from lp.testing.matchers :/
[04:12] <mwhudson> s/them/Startswith/
[04:13] <mwhudson> oh maybe only one
[04:14] <lifeless> mwhudson: perhaps I should have left a forwarder in place
[04:15] <lifeless> mwhudson: I hope that folk will get in the habit of contributing straight to testtools and rolling a temp build of it for LP
[04:15] <mwhudson> hard to say
[04:15] <lifeless> ditto storm.
[04:15] <lifeless> and other deps
[04:19] <mwhudson> lifeless: btw, you could consider assigning this bug to yourself: https://bugs.edge.launchpad.net/launchpad-foundations/+bug/107371
[04:19] <_mup_> Bug #107371: Make the test suite able to be run in parallel on a single machine <build-infrastructure> <feature> <test-system> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/107371>
[04:20] <lifeless> mwhudson: heh, I wouldn't want to stop other folk working on it :)
[04:20] <mwhudson> heh heh
[04:20] <jam> mwhudson: I see that the test failed again, but those tests look unrelated to my work. And they are *all* windmill tests.
[04:20] <mwhudson> jam: :(
[04:21] <jam> do you want to just try again?
[04:21] <mwhudson> i'
[04:21] <mwhudson> i'
[04:21] <mwhudson> bah
[04:21] <mwhudson> i'm not sure i WANT to
[04:21] <mwhudson> but i will try :-)
[04:24] <jam> mwhudson: well, if you think they will fail again, you don't have to
[04:24] <jam> I just wonder about windmill, etc
[04:24] <lifeless> mwhudson: trivial changes to the databasefixture branch (I forgot to tell its tests that the librarianlayer now implied db access working)
[04:24] <lifeless> mwhudson: do you care?
[04:25] <mwhudson> lifeless: i'll take a very quick peek i guess
[04:27] <mwhudson> oh, it was jml who reviewed this
[04:28] <lifeless> mwhudson: oh yeah >< :)
[04:31] <mwhudson> lifeless: i guess the comment in what is now testUploadsSucceed is a bit wrong?
[04:32] <lifeless> garh, I thought I updated it
[04:32] <mwhudson> maybe you did
[04:32] <mwhudson> i was looking at the individual diffs
[04:33] <LPCIBot> Project parallel-test build (8): STILL FAILING in 1 hr 32 min: https://hudson.wedontsleep.org/job/parallel-test/8/
[04:33] <LPCIBot> * Robert Collins: Merge unique config improvements.
[04:33] <LPCIBot> * Robert Collins: Fix config key.
[04:35] <lifeless> no, I didn't
[04:35] <lifeless> fixing
[04:39] <mwhudson> lifeless: i think the branch is fine now
[04:40] <lifeless> thanks for looking
[04:53] <lifeless> ok,good news
[04:53] <lifeless> stubs landing was broken, so we can fix windmill easily.
[04:59] <lifeless> is there a bug open for the issue with windmill ?
[05:04] <lifeless> anyone that wants ec2 to behave better, please review https://code.edge.launchpad.net/~lifeless/launchpad/threads/+merge/38908 :)
[05:04] <StevenK> \o/
[05:04] <StevenK> lifeless: Then reply to 'Failures on Hudson' on the -dev list?
[05:05] <lifeless> StevenK: well, after pqm takes it
[05:05] <StevenK> Ah, it's a work-around
[05:05] <StevenK> .. somewhat
[05:06] <lifeless> no
[05:06] <lifeless> its the fix
[05:06] <lifeless> the disable-check code path is currently still checking
[05:07] <StevenK> It is that one-line?
[05:07] <lifeless> yes
[05:07] <StevenK> Oh bloody hell, rs=everyone ?
[05:07] <lifeless> you can try it yourself
[05:07] <lifeless> bin/test -vvt g.tests.test_layer
[05:07] <lifeless> with and without
[05:08]  * StevenK prods thumper towards that MP
[05:09] <lifeless> jtv: ^
[05:09] <StevenK> lifeless: Oh, just to troll for one second: When branching using bzr, when it says Estimate: x/y, it's not fair if both x and y increase at the same rate
[05:10] <jtv> lifeless: ?
[05:10] <lifeless> blame tree structures
[05:10] <lifeless> jtv: one line patch to fix all the windmill thread remaining failures
[05:10] <jtv> oh great thanks
[05:10] <jtv> Need a review?
[05:10] <StevenK> I've added my conditional stamp to it
[05:10] <lifeless> https://code.edge.launchpad.net/~lifeless/launchpad/threads/+merge/38908
[05:10]  * jtv looks
[05:10] <wgrant> Does this mean that Hudson will magically stop spamming the channel?
[05:10] <lifeless> wgrant: hopefully
[05:11] <StevenK> No, it will now say it built sucessfully
[05:11] <StevenK> Hopefully
[05:11] <wgrant> Heh.
[05:13] <StevenK> wgrant: You didn't reply to the thread on -dev about it? :-P
[05:13]  * lifeless polls the page looking for jtv's stamp
[05:14] <wgrant> StevenK: No. I'm glad it spams when it fails.
[05:14]  * StevenK idly wonders how efficent it is for lifeless to loop in select()
[05:15] <wgrant> StevenK: I will also invoke EBUSY in my defence.
[05:15] <jtv> My stamp is there now, but I couldn't set a review type.
[05:16] <lifeless> tossed straight at ec2
[05:17] <StevenK> Awww, not even pqm?
[05:19] <lifeless> sorry, pqm :)
[05:20] <StevenK> Which still says nothing doing
[05:21] <lifeless> ah we're in testfix again
[05:22] <lifeless> fortunately this *is* a testfix.
[05:23] <StevenK> But has lp.translations.windmill.tests.test_pofile_translate.POFileTranslatorAndReviewerWorkingMode.test_pofile_reviewer_mode actually been fixed?
[05:25] <lifeless> that fix might now be, but the regular thread leak one will be :)
[05:27] <LPCIBot> Project devel build (135): STILL FAILING in 3 hr 32 min: https://hudson.wedontsleep.org/job/devel/135/
[05:27] <LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless][ui=none][no-qa] Add support for logging SQL bind values
[05:27] <LPCIBot> * Launchpad Patch Queue Manager: [r=mwhudson][ui=none][bug=624009][incr] Add a
[05:27] <LPCIBot> BranchMergeProposalNeedsReviewEvent but keep the functionality
[05:27] <LPCIBot> the same.
[05:27] <LPCIBot> * Launchpad Patch Queue Manager: [r=mwhudson][ui=none][bug=624009][incr] Rename
[05:27] <LPCIBot> MergeProposalCreatedJob to MergeProposalNeedsReviewEmailJob.
[05:27] <LPCIBot> * Launchpad Patch Queue Manager: [r=rockstar][ui=none][bug=638637] Stop loading the entire ancestry of
[05:27] <LPCIBot> a branch during the scan
[05:27] <LPCIBot> * Launchpad Patch Queue Manager: [r=adeuring][ui=none][no-qa] Change permission name for
[05:27] <LPCIBot> EditDistributionSourcePackage to launchpad.BugSupervisor.
[05:40] <lifeless> wallyworld__:     def __call__(self):
[05:40] <lifeless> +
[05:40] <lifeless> +        result = []
[05:40] <lifeless> is a bit unusual, it separates the function definition and body visually, which makes it harder to read.
[05:40] <wallyworld__> lifeless: ECONTEXT
[05:40] <lifeless> I realise you're experimenting
[05:40] <lifeless> improved-broken-link-handling
[05:41] <wallyworld__> i'm just writing up the description. looks like the email went out as sonn as a changed it from "onhold"
[05:41] <lifeless> yes, it does that :)
[05:41] <lifeless> tim is improving it
[05:41] <wallyworld__> which class was that code from again?
[05:42] <lifeless> fairly early in the diff
[05:42] <lifeless> I've closed it already though - sorry
[05:43] <wallyworld__>  lifeless: oh, you just want some white space added?
[05:45] <lifeless> wallyworld__: removed
[05:46] <lifeless> the blank line
[05:46] <lifeless> this is very surface, I'm just mentioning cause it stood out in a casual glance
[05:46] <lifeless> I'm happy to discuss the deeper stuff you're doing if you like (but not right now, am naffed)
[05:48] <wallyworld__> lifeless: it's not in the diff i'm seeing, nor in the code i have locally unless i've missed something. i'll triple check again. whoever picks up the review can check as well
[05:49] <lifeless> wallyworld__: the diff mailed out may have been stale
[05:50] <wallyworld__> lifeless: could be. go have a beer or something. i'm sure it's past beer o'clock over there :-)
[06:00] <LPCIBot> Project parallel-test build (9): STILL FAILING in 1 hr 27 min: https://hudson.wedontsleep.org/job/parallel-test/9/
[06:00] <LPCIBot> * Robert Collins: With the Librarian depending on the database, having the layer is enough to be useful.
[06:00] <LPCIBot> * Robert Collins: Update Librarian test expectations.
[06:00] <LPCIBot> * Robert Collins: Import BaseLayer at the right place.
[06:02] <wgrant> I like that branch.
[06:02] <wgrant> It doesn't hide the author behind PQM.
[06:03] <StevenK> wgrant: parallel-test looks at branch of lifeless', so they're all going to be him
[06:03] <wgrant> Yeah, I know.
[06:03] <wgrant> But it's better than
[06:03] <wgrant> PQM
[06:03] <wgrant> PQM
[06:03] <wgrant> PQM
[06:03] <wgrant> PQM
[06:03] <wgrant> PQM
[06:23] <rockstar> wgrant, Tarmac sets the author properly, and then sets committer as "Tarmac"
[06:25] <StevenK> rockstar: Does Tarmac work faster than PQM? ;_)
[06:25] <rockstar> StevenK, what's slow about PQM?
[06:25]  * rockstar answers a question with a question
[06:26] <StevenK> rockstar: 30 minutes for an answer back from PQM with "Okay, your branch is merged"
[06:26] <wgrant> rockstar: That sounds like it might not be completely insane.
[06:26] <rockstar> StevenK, yeah, but that's mostly a function of the pre-commit hook it runs.
[06:27] <wgrant> Wasn't buildbot introduced as part of the 5-minute-PQM effort?
[06:27] <wgrant> Did you just give up after reaching half-hour-PQM?
[06:28] <rockstar> wgrant, yeah, PQM still wants to build a tree and such.  It spends most of its time cleaning up after itself, actually.
[06:31] <spm> hrm. it used to be, when I started, that PQM+the entire LP test suite would happen in 90 minutes. it was when that creeped to ~ 2-2.5 hours, that 5 min pqm was introduced.
[06:32] <spm> so I'm not sure the fault lies entirely with pqm here; rather what it's being asked to do, is what's taking so long.
[06:33] <StevenK> spm: I just like digging at pqm since lifeless wrote it
[06:33] <spm> roger roger
[06:33] <spm> I just have to (roundabout) defend him every now and then. afterall, it's easier to stab someone in the back, if you're standing behind them. :-P
[06:35] <rockstar> StevenK, AIUI, lifeless didn't write it, he just performs CPR on it every once in a while.  I think PQM pre-dates baz.
[06:36] <lifeless> StevenK: I didn't write it :)
[06:37] <rockstar> Frankly, I'm surprised that bzr is the only DVCS with something like robotic landings.
[07:28] <LPCIBot> Project parallel-test build (10): STILL FAILING in 1 hr 27 min: https://hudson.wedontsleep.org/job/parallel-test/10/
[07:28] <LPCIBot> Robert Collins: Update missed comment.
[08:50] <adeuring> good morning
[08:53] <gmb> Aaaaaargh.
[08:54] <wgrant> gmb's back!
[08:54] <gmb> :)
[08:58] <gmb> lifeless: Is there some special dance that I have to do to use feature flags in pagetests or has no-one been stupid enough to try doing that yet?
[08:58] <lifeless> gmb: should work fine
[08:58] <gmb> Hmm.
[08:58] <lifeless> be sure to cargo cult something appropriate
[08:59] <gmb> Yeah. I'm working on it :)
[08:59] <lifeless> mars has a branch adding a context manager
[09:00] <gmb> lifeless: Yes, I've got that branch merged. I'll keep prodding things until it works.
[09:00] <lifeless> have you added a rule
[09:00] <gmb> At least I know I'm not (entirely) mad.
[09:00] <lifeless> lib/canonical/launchpad/doc/librarian.txt is an example that I know works.
[09:00] <lifeless> or
[09:00] <gmb> Aha, lemme look...
[09:00] <lifeless> lib/canonical/launchpad/doc/timeout.txt
[09:12] <gmb> lifeless: Yep. Got it working now, thanks.
[09:12] <lifeless> gmb: awesome
[09:13] <lifeless> gmb: if you want feedback on your use, just shout
[09:14] <bigjools> morning
[09:15] <wgrant> Evening.
[09:17]  * thumper waves
[09:17]  * bigjools shivers
[09:18]  * thumper gives bigjools the chills
[09:19] <bigjools> yes, baby
[09:21] <thumper> db-devel failing with lp.translations.windmill.tests.test_serieslanguages.LanguagesSeriesTest.test_serieslanguages_table
[09:23] <wgrant> StevenK: Why would anything except the publisher care about how they're published?
[09:23] <StevenK> wgrant: In relation to my comment?
[09:23] <wgrant> StevenK: Yes.
[09:24] <StevenK> wgrant: Since I can think of at least two other places that would benefit from it
[09:24] <mrevell> Morning
[09:24] <wgrant> Oh?
[09:24] <StevenK> wgrant: IDS for one
[09:24] <wgrant> Hm, I don't see why that would care.
[09:24] <wgrant> Why would it care?
[09:25] <StevenK> Because it copies from PRIMARY and DEBUG
[09:25] <wgrant> But that's just because they're PRIMARY and DEBUG.
[09:25] <wgrant> Not because they're a-f (which is also copy archives).
[09:25] <StevenK> wgrant: If you add one there, the publisher can use and IDS can as well
[09:26] <wgrant> StevenK: But IDS doesn't want this one.
[09:26] <wgrant> It wants (PRIMARY, DEBUG), not (PRIMARY, COPY[, soon DEBUG])
[09:26] <StevenK> Oh, duh
[09:27]  * StevenK should learn to read
[09:27] <wgrant> Heh.
[09:30] <StevenK> wgrant: Oh, and I tried Evolution now that I'm on Maverick. It still hates me.
[09:30] <wgrant> StevenK: Thanks.
[09:30] <wgrant> StevenK: :(
[09:30] <StevenK> However, Thunderbird has gotten scary
[09:31] <wgrant> I haven't used it since 2.0.0.0 was fresh.
[09:31] <StevenK> You type in your e-mail address and it guesses and probes for the IMAP/POP3/SMTP servers it should use.
[09:31] <wgrant> Ah.
[10:02] <StevenK> How do I get the test suite to print out all SQL that gets run?
[10:03] <lifeless> LP_DEBUG_SQL
[10:06]  * StevenK drowns in it
[10:09] <LPCIBot> Project devel build (136): STILL FAILING in 3 hr 58 min: https://hudson.wedontsleep.org/job/devel/136/
[10:10] <StevenK> lifeless: When did your windmill thread fix land?
[10:13] <StevenK> lifeless: Ah ha. #136 contained your fix, but six windmill tests still failed
[10:14] <lifeless> StevenK: with thread errors?
[10:14] <StevenK> lifeless: Yes
[10:14] <lifeless> frell
[10:15] <StevenK> https://hudson.wedontsleep.org/job/devel/lastFailedBuild/testReport/junit/lp.bugs.windmill.tests.test_official_bug_tags_management/TestOfficialBugTags/test_official_bug_tags_management_2/ for example
[10:15] <lifeless> well
[10:15] <lifeless> theres a few possibilities
[10:15] <lifeless> the layer may not be setting the flag correctly
[10:15] <lifeless> something else may be wrong
[10:17] <lifeless> https://hudson.wedontsleep.org/job/devel/lastFailedBuild/consoleFull
[10:17] <lifeless> search for test_official_bug_tags_management
[10:17] <lifeless> raise WindmillTestClientException(result['result'])
[10:17] <lifeless> the _2 is just reporting that there are new threads
[10:17] <lifeless> its not erroring *because* of them
[10:18] <lifeless> however this is an issue
[10:18] <lifeless> test: canonical.testing.tests.test_layers.TestThreadWaiting.test_slow_thread
[10:18] <StevenK> So subunit is masking the failures?
[10:18] <lifeless> successful: canonical.testing.tests.test_layers.TestThreadWaiting.test_slow_thread
[10:18] <lifeless> error: canonical.testing.tests.test_layers.TestThreadWaiting.test_slow_thread [ multipart
[10:18] <lifeless> StevenK: huh, no.
[10:19] <lifeless> https://hudson.wedontsleep.org/job/devel/136/testReport/junit/lp.bugs.windmill.tests.test_official_bug_tags_management/TestOfficialBugTags/test_official_bug_tags_management/
[10:19] <lifeless> thats the failure
[10:19] <bigjools> this broken person-picker is really getting on my tits now
[10:19] <StevenK> I see, it appears twice
[10:19] <lifeless> the subunit fragment I just pasted is a broken api usage in the test environment
[10:19] <lifeless> which is also an issue
[10:19] <StevenK> lifeless: However, it is the only one that does appear twice
[10:19] <lifeless> I'm not sure where to file that one; jml may know
[10:20] <lifeless> successful: lp.bugs.windmill.tests.test_bug_also_affects_new_upstream.TestBugAlsoAffects.test_bug_also_affects_picker
[10:20] <lifeless> test: lp.bugs.windmill.tests.test_bug_also_affects_new_upstream.TestBugAlsoAffects.test_bug_also_affects_picker
[10:20] <lifeless> tags: zope:threads
[10:20] <lifeless> error: lp.bugs.windmill.tests.test_bug_also_affects_new_upstream.TestBugAlsoAffects.test_bug_also_affects_picker [ multipart
[10:20] <lifeless> same issue
[10:20] <lifeless> its a bug in the zope testrunner output glue
[10:20] <lifeless> s/bug/questionable behaviour/
[10:20] <StevenK> Ah
[10:20] <lifeless> see how it reports the same test twice
[10:20] <lifeless> once successful
[10:21] <StevenK> The problem is that subunit/hudson is tripping over it
[10:21] <lifeless> once error with the tag zope:threads
[10:21] <lifeless> yes, needs a fix for sure
[10:23] <lifeless> also
[10:23] <lifeless> \o/ reading-back the ports from the librarian
[10:35] <lifeless> night all
[11:17] <jtv> gary_poster: do we have any concrete plans for getting that storm is_empty fix into zc.buildout?
[11:17]  * jtv wonders vaguely if he's asking the right person
[11:19] <jtv> …and concludes yes, probably
[11:36] <henninge> Does anybody know what's wrong with the icon alignment on (some) Launchpad pages? It seems to be related to the "link" formatter.
[11:37] <henninge> http://people.canonical.com/~henninge/screenshots/icon_misalignment_chromium.png
[11:37] <henninge> It's slightly less in Firefox but still visible.
[11:37] <henninge> http://people.canonical.com/~henninge/screenshots/icon_misalignment_firefox.png
[11:37] <wgrant> It's been a problem since CSS sprites were introduced.
[11:38] <henninge> But this is worse now. Could it be related to the Ubuntu font I am using now?
[11:39] <henninge> Looking at bac's screenshot, I suspect that: http://people.canonical.com/~bac/branchvis/forbidden-with-teams.png
[11:39] <henninge> wgrant: also, the branch icons for "bug" and "merge proposal" now come out on top of each other.
[11:39] <henninge> but that may be a result of the higher line height introduced by the misalignment.
[11:40] <wgrant> henninge: Branch emblems have always been a problem in WebKit. Or does it show up in Gecko now too?
[11:40] <jcsackett> henninge: i just checked a few pages in safari, they appear slightly unaligned, as in bac's screenshot, not as bad as in the screenshots you posted.
[11:40] <wgrant> I think the sprite alignment problem is just because the text height is larger.
[11:40] <jcsackett> safari is definitely *not* using the ubuntu font. :-P
[11:40] <wgrant> So the sprite appears at the top.
[11:40] <henninge> wgrant: so it is related to the new font.
[11:40] <wgrant> Related, but not specific to.
[11:41] <henninge> jcsackett: do you have the new Ubuntu font installed?
[11:42] <jcsackett> henninge: no, and i'm away from my development machine right now. i can install it and let you know if i see an increased problem later today, when i'm home.
[11:42] <jcsackett> probably a bit after 9AM EST?
[11:43] <henninge> jcsackett: yes, that's fine.
[11:43] <jcsackett> henninge: okay, i'll let you know then.
[11:43] <henninge> jcsackett: are you on EST? You are up early!
[11:43] <henninge> Although it's EDT, actually.
[11:43] <henninge> ;-)
[11:44] <jcsackett> :-P
[11:44] <jcsackett> henninge: i usually get up at five to walk my dogs and hit the gym.
[11:45] <henninge> good man! I am glad when I make 6 o'clock ...
[11:45] <jcsackett> it took a fair bit of retraining. i used to be a sleep 10 guy. :-)
[11:45] <jcsackett> sleep till ten, rather.
[11:45] <henninge> luckily I have a family that won't allow me to do that ...
[11:46]  * gmb lunches. 
[11:58] <deryck> Morning, all.
[13:41] <jcsackett> henninge: was able to look at the site with the font; it does look a bit worse.
[13:42] <jcsackett> but the alignment does seem off across browsers, even without the font. just not as bad as with.
[13:44] <salgado> mrevell, when you have a moment, can you have a look at https://code.edge.launchpad.net/~leonardr/launchpad/temporary-integration/+merge/38836 ?
[13:44] <mrevell> certainly salgado
[14:20] <allenap> deryck: Robert Collins gets two entries for Launchpad Suite on https://edge.launchpad.net/malone/+subscribe. Have you seen that before?
[14:20]  * deryck looks
[14:21] <deryck> allenap, no, never seen that.  Odd.
[14:21] <allenap> deryck: That could be a problem with new code. I'll investigate.
[14:22] <deryck> allenap, ok, thanks
[14:23] <abentley> bigjools, chat?
[14:47] <mars> rockstar, ping, the mail you sent yesterday still has not made it through to Gary and I.  Strange.
[14:56] <rockstar> mars, bugger. That means my SMTP server has done its weird "fall over but don't tell anyone" thing that I thought I fixed months ago.
[15:15] <jkakar> Am experiencing more (I think) timeout related issues... can't download a 276kb image from a bug.
[15:15] <jkakar> I appreciate the rationale for ratcheting down timeouts, but it's been *really* annoying.
[15:15] <jkakar> I think it might be too extreme.  Maybe I just have bad luck and most people don't notice.
[15:16] <deryck> jkakar, hi.  what bug and attachment?
[15:17] <jkakar> deryck: https://bugs.edge.launchpad.net/landscape/+bug/663786
[15:17] <jkakar> deryck: The first attachment, called 'Design'.
[15:18] <deryck> jkakar, I can't see it because it's private.  I think this is the private attachments can't be downloaded bug, not timeout related.
[15:18]  * deryck looks for a bug #
[15:18] <jkakar> deryck: Ah, okay.  I was able to download the other attachment on the same bug, though.
[15:18] <deryck> yeah, it's an inconsistent condition.
[15:19] <jkakar> deryck: Ah, fun times. :)
[15:19] <deryck> jkakar, yeah, you could call it that :-)
[15:19] <jkakar> Anyway, sorry for jumping to conclusions about timeouts, but been experiencing them a lot for the last few weeks. :/
[15:21] <deryck> jkakar, I subscribed you to Bug #638054, since it's private.  But I think that's what you might be experiencing.
[15:22] <deryck> jkakar, and yeah, timeouts are also an issue.  In some cases, it's the transition to postgresql 8.4.
[15:23] <jkakar> deryck: Cool, thanks a lot and thanks for listening. :)
[15:23] <deryck> jkakar, np! :-)
[15:30] <mars> henninge, looks like the lucid-db-devel build failure is in translations, so in your court?  https://lpbuildbot.canonical.com/builders/lucid_db_lp/builds/334
[15:30] <mars> henninge, can't remember if that is a known issue - someone was working on it last night IIRC?
[15:30] <mars> so it may be fixed in devel
[15:31] <not-abentley> bigjools: chat?
[15:31] <danilos> mars, I can't remember anything related to that being changed in literally ages, so it's really weird
[15:31] <bigjools> abentley: 'sup?
[15:31] <mars> danilos, ok, not fun
[15:32] <abentley> bigjools: several things.  buildd install issues and a big build queue.
[15:32] <abentley> bigjools: can we chat on mumble or skype?
[15:33] <bigjools> abentley: I'm on mumble
[15:33] <mars> danilos, maybe it was intermittent?
[15:33] <abentley> bigjools: I'm in the Soyuz channel.  Where are you?
[15:35] <danilos> mars, yeah :( I'd even say we haven't changed anything related since the last Epic, and it's the first time I see it
[15:35] <mars> danilos, ok, I'll force a rebuild then, and we'll see
[15:36] <mars> danilos, ah, same failure in lucid_lp, eh?
[15:36] <mars> danilos, https://lpbuildbot.canonical.com/builders/lucid_lp/builds/268
[15:37] <mars> danilos, and the following test on that same builder passed just fine
[15:38] <bigjools> abentley: https://lpstats.canonical.com/graphs/BuildersActiveVirtual/20101019/20101021/
[15:46] <danilos> mars, :( I'll take a look
[15:47] <sinzui> allenap, a I have said in many emails. registry just models user. authentication is launchpad foundation
[15:48] <allenap> sinzui: Sorry. I assume you've re-targeted that bug, but I'll try to remember for future bugs.
[15:48] <sinzui> I have
[15:48] <allenap> sinzui: I saw the bit about merged accounts and jumped to a decision.
[15:48] <sinzui> I am powerless to help with openid issues
[15:49] <danilos> mars, the failing tests are completely different
[15:49] <sinzui> allenap, openid login to a wiki is the issue.
[15:49] <allenap> sinzui: I was hasty :(
[15:50] <mars> danilos, I forced the build anyway, we'll see what happens.
[15:59] <jcsackett> can someone help me out with some weird issues with a method over launchpadlib?
[16:00] <jcsackett> test that brings up the issue is here: https://pastebin.canonical.com/38848/
[16:00] <jcsackett> pdb session showing odd thing happening inside test is here: https://pastebin.canonical.com/38849/
[16:05] <sinzui> jcsackett, I am confused about the issue here.
[16:05] <jcsackett> sinzui: person.join is never actually called in the codebase--i'm getting a return of the raw json dump of the test person as a return.
[16:05] <sinzui> jcsackett, methods() do update the instance (they are transactional)
[16:06] <sinzui> leonardr, ^ ca you help jcsackett with his lplib test?
[16:06] <leonardr> i'll look
[16:07] <jcsackett> leonardr: feel free to interrogate me a lot; this is easier to describe than pastebin an illustrative fashion.
[16:07] <leonardr> ok
[16:08] <sinzui> jcsackett, you use lp_save() when you change a property (eg, commit). You have not changed a property. I do not think it is needed
[16:08] <jcsackett> sinzui: yeah, i wasn't sure. i was experimenting a bit there.
[16:08] <jcsackett> the same scenario occurs regardless of lp_save, so i agree it's unnecessary.
[16:09] <sinzui> jcsackett, regardless of the join behaviour, does the test pass?
[16:10] <jcsackett> sinzui: no, the test is failing, because person.join doesn't seem to actually get called.
[16:10] <jcsackett> so no membership is created. or in the case where i'm trying to catch an exception, the exception isn't raised.
[16:11] <jcsackett> this being lp.registry.model.person.join, not the NamedOperation.
[16:16] <henninge> sinzui: found another one of these: https://edge.launchpad.net/~timstoaster-deactivatedaccount
[16:16] <leonardr> jcsackett: my advice based on zero information is to re-run the test with 'httplib2.debuglevel = 1' and show my the http requests and responses
[16:16] <sinzui> henninge, that is because login/reset is broke
[16:17] <henninge> sinzui: he is appaerently active because he just joined a team.
[16:17] <henninge> yeah, I know.
[16:17] <henninge> Can we not fix that, though?
[16:17] <sinzui> henninge, he is active because her has a preferred email address
[16:17] <henninge> I mean, the account.
[16:17] <sinzui> henninge, the rename rule did not run. that is the only thing wrong. the user does not seem to care
[16:18] <sinzui> https://edge.launchpad.net/~timstoaster-deactivatedaccount/+review
[16:18] <henninge> sinzui: Yes, I just found that.
[16:19] <leonardr> jcsackett: also, tell me lazr.restfulclient.__version__
[16:19] <henninge> sinzui: is it harmless to just rename it?
[16:19] <leonardr> and see if this starts working if you access test_team.name before invoking me.join()
[16:19] <sinzui> henninge, yes, and it should have been renamed
[16:19] <henninge> sinzui: ok, I'll  do that and inform the user.
[16:19] <sinzui> henninge, if there was something like a ppa, the rename field would not appear
[16:19] <henninge> ah, good to know
[16:20] <henninge> sinzui: hm, appearently I cannot do it.
[16:25] <sinzui> henninge, this is the E'FING hidden location bug that bac reported
[16:25] <sinzui> The user can fix it, but we cannot
[16:28] <jcsackett> leonardr: requests/responses are here https://pastebin.canonical.com/38851/
[16:29] <jcsackett> version is 0.10.0
[16:29] <jcsackett> calling test_team.name didn't have any effect.
[16:29] <leonardr> ok, i guess that's good
[16:30] <jcsackett> leonardr: i see a number of 303s around calls involving me; should i try getting the test person out of people['test-person'] instead of using .me?
[16:30] <leonardr> jcsackett: yes, that's the problem. clients aren't allowed to re-submit post information if they get a 303
[16:30] <jcsackett> leonardr: trying that now.
[16:30]  * jcsackett wishes he had thought of httplib2.debuglevel before.
[16:31] <leonardr> it is the general purpose tool
[16:31] <jcsackett> leonardr: that worked, thanks for your help. i'll remember debuglevel next time. :-)
[16:31] <leonardr> great
[17:04] <leonardr> jcsackett: you ran into https://bugs.edge.launchpad.net/launchpadlib/+bug/504297
[17:04] <_mup_> Bug #504297: calling named operation on launchpad.me <launchpadlib :Triaged> <https://launchpad.net/bugs/504297>
[17:05] <jcsackett> leonardr: yup, that's exactly it.
[17:24] <jam> mwhudson: when you wake up. we were down from 4 failing windmill tests to only 1 failing windmill test \o/ for reproducibility. I guess we have an open bug about the windmill tests being unstable? Can we submit anyway?
[17:29] <jam> abentley: I forgot to mention yesterday, but the db is at chinstrap:~jameinel/test.db.bz2 if you want it.
[17:29] <abentley> jam, cool.
[17:58] <lifeless> lamont: hi
[18:11] <lifeless> matsubara: commented
[18:11] <matsubara> thanks lifeless
[18:13] <mars> jam, do you have a copy of the test failure?
[18:14] <jam> mars: when there was 1 failure, or when there were 4 ? :)
[18:14] <jam> lp.code.windmill.tests.test_branchmergeproposal_review.TestReviewCommenting.test_merge_proposal_replying
[18:14] <jam> was the single failure
[18:14] <jam> _StringException: Text attachment: garbage
[18:14] <mars> jam, I mean, what was the failure you were seeing?  Ah, 'garbage threads', Thread-1234, etc.
[18:15] <lamont> morning lifeless
[18:15] <jam> mars: yeah, something like that
[18:15] <jam> I can forward you the email if you want
[18:15] <mars> jam, please do, and I'll tell you if it is intermittent or not
[18:16] <jam> mars: well, I'm pretty sure it is intermittent. As we submitted, and 4 windmill tests fails, we resubmitted without changes, and only 1 failed
[18:16] <jam> (I guess a fix could have landed in the meantime)
[18:16] <jam> mars: I sent you the single failure, and the 4-failure emails
[18:16] <mars> jam, lifeless had a fix, may or may not have worked for that.  In the meantime we are saying "run ec2 test, if it looks good, then bzr lp-land"
[18:17] <mars> thanks
[18:17] <jam> mars: so ignore the failures and land anyway?
[18:17] <mars> jam, from what I see, yes
[18:17] <mars> that is the intermittent failure that everyone has been getting
[18:34] <lifeless> matsubara: the windmill threads thing is fixed
[18:34] <lifeless> bah
[18:34] <lifeless> mars: ^
[18:34] <matsubara> :-)
[18:34] <lifeless> mars: we shouldn't be saying that any more
[18:34] <mars> lifeless, proven fixed?
[18:35] <lifeless> yes, hudson shows errors still because of a defect in zope.testrunner
[18:35] <lifeless> it reports *any* new threads as an 'error:' at the subunit level.
[18:35] <mars> lifeless, and when it comes to fixes for stuff like this, you have to deal with fallout for a week or two after, until everyone is only working on fresh branches of devel.
[18:35] <lifeless> mars: buildbot won't report it as an error
[18:35] <lifeless> mars: no, ec2 merges devel, so everyone gets it immediately
[18:36] <mars> ah, right
[18:37] <mars> jam, so as lifeless says, you can ec2 land it again if you want, it should pass
[18:37] <mars> but since you already ran it by, you can probably just lp-land it
[18:37] <mars> no need to run the suite again
[19:08] <lifeless> lamont: ping
[19:14] <mtaylor> sinzui: I just added information to an incomplete bug report - should _I_ pop the status back to new, or will just adding info be good enough?
[19:15] <sinzui> I get emails. changing the status mean I need to change it back if I still do not see a problem
[19:15] <mtaylor> ok. cool
[19:20] <sinzui> mtaylor, I can see the sorting is working as designed. The common problem here is that this page seems to be designed for no one. Each person sees, tries to change it, then makes other people irrate.
[19:20] <mtaylor> sinzui: really? what is causing cherry to show up first?
[19:20] <sinzui> mtaylor, *who* needs to use this drizzle page
[19:20] <mars> rockstar, the mail went through.  Thanks!
[19:21] <sinzui> mtaylor, The only legitimate use case I have found for this page is for packagers who need the latest package to create an installer
[19:21] <rockstar> mars, awesome.
[19:21] <mtaylor> sinzui: well... I _was_ using it in the debian watch file as per the answer in the question about using launchpad via uscan
[19:21] <mtaylor> sinzui: right. I was using it as part of packaging
[19:21] <sinzui> mtaylor, why do you not release from the focus of development?
[19:22]  * sinzui is search for more evidence that +downloads is so bad is needs to be shot, not fixed
[19:22] <mtaylor> sinzui: oh - well, usually we do - I think we moved dev focus to freemont prematurely
[19:22] <mtaylor> sinzui: well.... actually, I take that back
[19:23] <mtaylor> sinzui: "focus of developement" seems to be slightly more vague than I'd like to it be ... focus of development sets lp:drizzle to something ... which is what our "trunk" branch is - which is where crazier things go, whereas elliot is in beta and thus is the thing we're working on solidifying and releasing
[19:24] <sinzui> understood
[19:25] <mtaylor> sinzui: I have no personal need for +download myself, as long as there is a sensible thing to put in debian/watch :)
[19:25] <sinzui> this is a similar pattern to backporting and releasing to supported series, but +download and the latest release rules do not know how to negotiate that arrangement
[19:26] <mtaylor> sure. nor would I expect them to
[19:26] <mtaylor> but the latest download link on the main project page seems to have gotten it right
[19:26] <mtaylor> why is it that the cherry release comes up as the most recent on +download ?
[19:26] <sinzui> 50% of people think it is wrong :(
[19:27] <mtaylor> and/or why is that 'as designed'
[19:27] <mtaylor> haha
[19:27] <jcsackett> so has anyone gotten an ec2 email back that says every test failed but it's all text attachment: garbage? or am i just especially unlucky today?
[19:27] <sinzui> I honestly this this is unfixable. There are many user and usecases at play here and one very mediocre solution
[19:28] <mtaylor> I think I'm tending to agree with you
[19:28] <sinzui> debian/watch though is a very important use case and I will look into how we can ensure this is supported
[19:28] <mtaylor> sinzui: well, for now it's working for me to use http://launchpad.net/drizzle rather than http://launchpad.net/drizzle/+download
[19:29] <mtaylor> but - if 50% of the people think that http://launchpad.net/drizzle is showing the right thing...
[19:29] <mtaylor> s/right/wrong/
[19:30] <sinzui> I think we need to ensure know one has to guess at which url to use with debian watch. The portlet on the project page could change in a few weeks and there is no test says that debian watch needs the highest version number
[19:30] <mtaylor> gotcha
[19:31] <mtaylor> speaking of - I'd still like to understand what criteria would cause something other than drizzle7-2010.10.01.tar.gz to show up as the latest download... so that I can perhaps manage my meta data differently
[19:31] <sinzui> well, maybe that is what we want and we can do that on the download page. Add a portlet that shows the highest version number release and ensure there is a url for it too
[19:31] <mtaylor> (sorry if I'm being a pest about it, I just can't understand why a release from april would match "latest" under any set of criteria)
[19:32] <sinzui> Since there are no release from trunk, the series are sorted by number high to low, but aphabetically low to high.
[19:33] <sinzui> elliot comes after cherry
[19:33] <mtaylor> ah
[19:34] <mtaylor> ok.  so the series are not sorted by release date
[19:35] <sinzui> We could change the rules to always sort alphabetically. I am not sure how many people would notice. I think most have adopted numbers when they know they are developing for a long time because Lp does that better
[19:35] <mtaylor> but why not use the explicit release date?
[19:35] <sinzui> We do not sort series be release date because people add releases to old series often. The sort we use addressed the last group of users who noted that the listing was unsorted
[19:36] <mtaylor> heh
[19:36] <mtaylor> well, I would personally prefer this page not exist rather than be sorted alphabetically reversed
[19:36] <sinzui> the product-release-finder is also a factor. it add releases to series that may be ancient
[19:37] <leonardr> salgado (or someone), i'm having problems getting testopenid.dev to work on my dev machine. i think this is the first time i've ever actually had to use testopenid.dev. can you help me?
[19:38] <sinzui> mtaylor, your issue is a dup of bug 231797, but I am updating that bug to explain the issues with the project index page and download page
[19:38] <_mup_> Bug #231797: no sensible way to use debian/watch files with launchpad hosted tarballs <Launchpad Registry:Triaged> <devscripts (Ubuntu):Invalid> <https://launchpad.net/bugs/231797>
[19:38] <mtaylor> cool
[19:38] <sinzui> oh, I see you have already comment on the bug
[19:39] <leonardr> salgado (or whoever), my specific error seems to be the lack of a session cookie
[19:42] <leonardr> salgado: got it working, nm
[19:48] <Ursinha> lifeless, hello hello
[19:50] <lifeless> hiya
[19:50] <Ursinha> lifeless, so, bad-commit-xxxxx tag is added by hand, right?
[19:51] <lifeless> yes
[19:51] <lifeless> for now; if you want to add a scrpit to do it, awesome
[19:52] <Ursinha> lifeless, I'm asking because there's a wiki page saying it's done by the script: https://dev.launchpad.net/QAForContinuousRollouts
[19:52] <Ursinha> so I got confused
[19:52] <lifeless> meep
[19:52] <lifeless> well its *read* by the script
[19:52] <lifeless> but the script can't assess good/bad
[19:53] <lifeless> it can only read our decisions
[19:53] <Ursinha> right, I thought so
[19:54] <Ursinha> lifeless, bdmurray landed a fix for bug 347218 but didn't mention the rollback tag
[19:54] <_mup_> Bug #347218: Allow bug supervisors to make tags official <bad-commit-11701> <qa-bad> <story-define-official-tags> <Launchpad Bugs:Fix Committed by brian-murray> <https://launchpad.net/bugs/347218>
[19:54] <Ursinha> I've added the bad-commit tag
[19:55] <lifeless> Ursinha: cool
[19:55] <lifeless> Ursinha: so we need some way to say 'commit X fixes bad commit Y' other than [rollback]
[19:55] <lifeless> and
[19:55] <lifeless> Ursinha: so we need some way to say 'commit X fixes bad commit Y' other than by committing a new revision
[19:56] <lifeless> these are separate but could be fixed in the same way
[19:56] <Ursinha> I guess the tag
[19:56] <Ursinha> if you add the tag, and mentions the bug in both commits
[19:57] <Ursinha> hmm
[19:57] <lifeless> mm
[19:57] <lifeless> so I'm saying 'lets assume people fix by mistake'
[19:57] <Ursinha> lifeless, how would the second work?
[19:57] <lifeless> or thereabouts
[19:57] <lifeless> well, one way would be:
[19:57] <lifeless> bad-commit=xxxx,yyyyy
[19:57] <lifeless> where xxxx is the bad commit
[19:57] <lifeless> and yyyy is the fix for it
[19:57] <lifeless> so the script cannot deploy xxx without yyyy
[20:05] <Ursinha> where are we placing this?
[20:05] <Ursinha> bug tag?
[20:11] <Ursinha> lifeless, ^
[20:12] <lifeless> otp
[20:15] <Ursinha> sure
[20:25] <gary_poster> rockstar, do you have a few min for a tarmac phone call?
[20:25] <rockstar> gary_poster, indeed I do.
[20:25] <gary_poster> awesome, thanks rockstar.  mumble or skype?
[20:25] <gary_poster> I'm on both atm
[20:25] <rockstar> gary_poster, skype please.
[20:26] <abentley> jam: skype?
[20:30] <Ursinha> lifeless, also, could you comment on bug 623239 later, please?
[20:30] <_mup_> Bug #623239: please don't squash qa-untestable tags <qa-tagger:Incomplete> <https://launchpad.net/bugs/623239>
[20:31] <jam> abentley: sure, let me go grab a drink, brb
[20:36] <jam> abentley: back
[20:36] <jam> calling
[20:37] <jam> well, would if you were online :)
[20:46] <rockstar> gary_poster, also, if yous guys have questions, there's also #tarmac
[20:47] <gary_poster> rockstar: ah!  good to know, thanks
[20:47] <lifeless> Ursinha: hi
[20:47] <lifeless> I is back
[20:47] <lifeless> Ursinha: I'm saying we could use the same bug tag
[20:47] <lifeless> bad-commit=12345,12350
[20:48] <lifeless> meaning broken in 12345 fixed in 12350
[20:49] <Ursinha> right
[20:50] <lifeless> commented on the bug, but perhaps we need some realtime discussion
[20:54] <mwhudson> morning
[20:54] <Ursinha> lifeless, want to mumble?
[20:54] <lifeless> I could skype if you like
[20:54] <lifeless> mumble works very badly here
[20:55] <Ursinha> sure, a minute
[20:56] <lifeless> I'm rbtcollins
[20:57] <Ursinha> calling
[20:59] <mwhudson> i wonder why mumble is so terrible from nz
[20:59] <mwhudson> lag?
[21:01] <thumper> mwhudson: I think it is telecom voip traffic shaping
[21:01] <thumper> mwhudson: yet to confirm though
[21:01] <mwhudson> thumper: i'
[21:01] <mwhudson> thumper: i'm not on telecom though
[21:01] <thumper> mwhudson: who are you through?
[21:02] <mwhudson> thumper: voda at home, snap in the office i think
[21:02] <mwhudson> thumper: the international bandwidth is all the same though
[21:02] <mwhudson> i guess?
[21:02] <thumper> mwhudson: how's the office thing working out?
[21:02] <thumper> rockstar: skype?
[21:02] <rockstar> mwhudson, you have an office, huh?
[21:02] <mwhudson> thumper: well
[21:02] <rockstar> thumper, sure.
[21:03] <mwhudson> rockstar: yeah, i'm renting some space about 50m from where lca was
[21:03] <mwhudson> decided some more work/life separation was in order
[21:03] <mwhudson> also being in town regularly is nice
[21:03] <jml> lifeless: when are we going to just split canonical.buildd into its own tree
[21:05] <rockstar> mwhudson, yeah, I tried that, only to realize that I am socially "handicapped."
[21:12] <lifeless> jml: when someone gets a tuit
[21:14] <lifeless> oh yay
[21:14] <lifeless> jml: bug 664107
[21:16] <mwhudson> rockstar: i'm not sure quite what you mean, but there are some pretty socially handicapped people in this office too
[21:17] <jml> lifeless: well, I guess we escalate that to Canonical Legal
[21:17] <lifeless> 'punt'
[21:17] <jml> lifeless: and hope that the amateur discussion is at least entertaining
[21:17] <lifeless> :)
[21:20] <mwhudson> rockstar: hey, when am i going to be able to click "merge this" on a mp?
[21:20] <cr3> can someone recommend a good example of project packaging eggs? I'm not sure where to ask but perhaps launchpad folks might know
[21:20] <lifeless> gary_poster: I'd like a few cycles to talk zcml if you can spare them today
[21:20] <cr3> gary_poster: ^^^ you might know?
[21:20] <lifeless> cr3: what do you mean?
[21:21] <gary_poster> lifeless, sure thing.  about to go another call, then will ping
[21:21] <lifeless> thansk
[21:21] <lifeless> jml: also
[21:21] <lifeless> jml: I have a zope testing question I *know* you know hte answer too
[21:21] <gary_poster> cr3: I know a fair amount about packaging Python things as eggs, not sure what your question is.  Feel fee to ping me later if you like, but swamped atm, and others can probably answer
[21:22] <cr3> lifeless: if a project creates eggs as its build process, they probably need to be packaged as part of the project package itself. I was hoping to find a good exmaple of a project that does something like that
[21:22] <lifeless> jml: on hudson, thread leaks show up as errors with the same test id as the test that passes
[21:22] <lifeless> jml: how do we change that to a skip, or something similar.
[21:22] <cr3> gary_poster: ah, I meant "debian packaging" as opposed to "packaging eggs" :)
[21:22] <jml> lifeless: hmm.
[21:22] <lifeless> jml: or should StevenK filter them with subunit-filter
[21:22] <lifeless> jml: this isn't in our logic - our logic is 'fixed' now.
[21:23] <jml> lifeless: these are errors raised during testTearDown, right?
[21:23] <lifeless> no
[21:23] <LPCIBot> Project devel build (137): STILL FAILING in 3 hr 58 min: https://hudson.wedontsleep.org/job/devel/137/
[21:23] <lifeless> there are two, overlapping, thread checks.
[21:23] <jml> oh, zope's and our own custom one
[21:23] <lifeless> 1) in BaseLayer. Fixed (the disable_thead_check flag was miscoded)
[21:23] <lifeless> 2) in zope.
[21:23] <gary_poster> cr3 ah gotcha.  Played with it.  assume you saw https://wiki.ubuntu.com/PackagingGuide/Python .  now really on call
[21:24] <lifeless> it took 3 months for my last change to zope.testing to get in; I'm not stoked about the idea of trying again :(
[21:24] <cr3> gary_poster: thanks, I didn't know about that guide, I'll certainly have a look
[21:25] <thumper> jml: hi
[21:25] <jml> thumper: hello
[21:25] <jml> lifeless: hm.
[21:25] <thumper> jml: I want you to look at the recipe stuff and let me know what needs to be done to say "we're done"
[21:25] <jml> thumper: I already took a good look today
[21:25] <lifeless> cr3: eggs and python packages are a little odd :)
[21:25] <jml> thumper: writing it up tomorrow. who should I send it to?
[21:25] <lifeless> cr3: the python packaging standard unpacks them on disk.
[21:26] <cr3> how is ez_setup.py generated or where is it copied from? I copied mine from the distribute package but I'm not sure that's right
[21:26] <thumper> jml: at least flacoste, me, abentley, rockstar, and wallyworld
[21:26] <jml> thumper: will do.
[21:26] <lifeless> if that what I think it is, its 'download unsigned code from the net and run it'
[21:26] <thumper> jml: maybe the internal list?
[21:26] <lifeless> so I would avoid it like the plague.
[21:27] <jml> thumper: sure
[21:27] <cr3> lifeless: it seems to be quite prevalent in lazr packages for example
[21:27] <jml> thumper: btw, heard about open build service's "Source services"
[21:27] <thumper> jml: yeah, saw the email
[21:27] <thumper> not looked at it though
[21:27] <lifeless> cr3: no comment ;)
[21:28] <cr3> lifeless: at least the md5sum is checked, for what it's worth
[21:28] <wgrant> cr3: Against what?
[21:28] <wgrant> An HTTP page?
[21:29] <lifeless> wgrant: yes, if they MITM you, they have to change *two* http requests.
[21:29] <jml> thumper: I had a play today
[21:29] <wgrant> lifeless: Awesome!
[21:29] <jml> thumper: there's a lot I admire about OBS – I think they've got a great product.
[21:29] <jml> thumper: but in this area we are still well ahead, I think.
[21:29] <jml> thumper: particularly if we smarten up the UI
[21:30] <thumper> jml: so lets get some good designers to focus on it...
[21:30] <jml> lifeless: http://paste.ubuntu.com/517034/ that's the event. the error is tagged, so subunit-filter ought to be able to filter it, pending a new feature :)
[21:30] <wgrant> Recipe builds would be really useful if they supported non-native packages, and customisable changelogs.
[21:30] <cr3> wgrant: the downloaded setuptools egg
[21:30] <lifeless> jml: Yeah, I'm wondering what we /want/ though
[21:30] <jml> lifeless: oh. I reckon we want to filter out based on tags, probably.
[21:31] <lifeless> ok, I'll file a bug on subunit to permit that
[21:31] <jml> lifeless: or disable zope's checking
[21:31] <jml> but it's pretty... embedded
[21:31] <lifeless> jml: shrug, We're within a few months of dropping the zope testrunner entirely.
[21:31] <jml> lifeless: frabjous day etc
[21:32] <lifeless> let me just ask the bandersnatch for that lovely vorpal sword
[21:38]  * thumper restarts server
[21:40] <jml> I am going to bed. Happy Thursday, future folk.
[21:41] <jam> abentley: I rememebered what I was going to say. The new DVCS "Veracity" has gdfo in its data structures (calling it 'generation')
[21:41] <abentley> jam, ah.  Cool.
[21:41] <jam> abentley: they have some fairly interesting C code for finding LCA, etc, in graphs fairly well documented
[21:42] <jam> I think it comes from whatever their earlier VCS was
[21:42] <jam> they also seem to do something where "merge" will merge multiple tips in one go
[21:47] <LPCIBot> Project db-devel build (87): STILL FAILING in 3 hr 51 min: https://hudson.wedontsleep.org/job/db-devel/87/
[22:02] <flacoste> thumper: udd meeting is starting in #ubuntu-meeting
[22:02] <thumper> :(
[22:02] <thumper> was just about to go and make another coffee
[22:03] <wallyworld> abentley: rockstar: looks like thumper has a meeting now. so our standup will be delayed
[22:04] <thumper> hopefully not for too long
[22:04] <rockstar> wallyworld, want to have a chat about merge queues?
[22:04] <wallyworld> rockstar: ok
[22:12] <mwhudson> hm, is the disable thread check fix in db-devel yet?  if so, that hudson failure is a bit :(
[22:13] <lifeless> mwhudson: hudson lies
[22:13] <mwhudson> heh
[22:13] <lifeless> mwhudson: because the zope->subunit glue reports leaked threads as errors
[22:13] <mwhudson> how so?
[22:13] <mwhudson> oh right
[22:13] <lifeless> mwhudson: we need to filter them out, its separate to the disable_thread_check flag
[22:13] <mwhudson> ok
[22:14] <jcsackett> back
[22:14] <mwhudson> grar, the same issue bounced testtools
[22:14] <lifeless> mwhudson: from ec2?
[22:14] <mwhudson> lifeless: yeah
[22:14] <lifeless> :<
[22:14] <mwhudson> oh no
[22:14] <mwhudson> well
[22:14] <mwhudson> that didn't have your fix in the branch tested
[22:15] <mwhudson> same with lp-service
[22:15] <lifeless> mwhudson: StevenK: https://bugs.edge.launchpad.net/subunit/+bug/664171
[22:15] <_mup_> Bug #664171: support filtering on tags <subunit:New> <https://launchpad.net/bugs/664171>
[22:18] <sinzui> EdwinGrubbs, I think your change broke some menus. This kind of check now fails: self.user.inTeam(self.context)
[22:19] <lifeless> sinzui: if it did, can you mark the bug bad-commit=xxx to stop it deploying? thanks.
[22:19] <sinzui> EdwinGrubbs, the cases look like where we know a user is a member of himself
[22:20] <EdwinGrubbs> sinzui: yes, I fixed that error already and landed a branch for it. Unfortunately, I couldn't get anyone to restart lucid_lp without restarting everything.
[22:20] <lifeless> EdwinGrubbs: did you tag it bad-commit ?
[22:21] <EdwinGrubbs> lifeless: no, I've never heard of bad-commit before.
[22:22] <lifeless> EdwinGrubbs: errata: its been announced on the list repeatedly as part of the RFWTAD workflow.
[22:22] <lifeless> I'm just grabbing the wiki page about it for you
[22:23] <lifeless> https://dev.launchpad.net/QAProcessContinuousRollouts
[22:26] <wgrant> thumper: So WIP MPs will be usable from the next rollout?
[22:27] <thumper> wgrant: hopefully even before that (from edge)
[22:27] <thumper> wgrant: or whatever we are using then...
[22:27] <wgrant> thumper: Hm, aren't they sent by a script?
[22:27] <thumper> wgrant: yes...
[22:27] <thumper> so?
[22:27] <thumper> the job is created by the appserver
[22:27] <wgrant> Or is it the same job, but now repurposed?
[22:28] <thumper> same job
[22:28] <wgrant> Ahh.
[22:28] <thumper> just not triggered on wip
[22:28] <thumper> and triggered on wip -> needs review
[22:29] <rockstar> wallyworld, you keep cutting out.  I can't understand you.
[22:29] <wallyworld> rockstar: i can hear you
[22:29] <lifeless> thumper: wgrant: remember edge deployments are stopping
[22:29] <lifeless> like asap
[22:30] <thumper> lifeless: where does qastaging email go?
[22:30] <lifeless> thumper: same story as staging I hope
[22:30] <thumper> don't hope...
[22:30] <thumper> make sure :-)
[22:30] <lifeless> thumper: well, i can't tell, can I ?
[22:31] <lifeless> thumper: you can try, trigger something on qastaging
[22:31] <lifeless> if you get mail, we need to change stuff
[22:31] <lifeless> http://qastaging.launchpad.net/
[22:32] <thumper> oops 1754QS12 on that
[22:32] <lifeless> https://qastaging.launchpad.net/ worked for me
[22:32] <lifeless> I think it may have been paged out
[22:33] <lifeless> :>
[22:34] <wallyworld> rockstar: you ended the call?
[22:34] <rockstar> wallyworld, headset is gone.
[22:34] <wallyworld> bollocks
[22:35] <thumper> whatever we have behind qastaging seems to be timing out a lot
[22:36] <lifeless> its the same as staging
[22:36] <lifeless> same boxes for everything
[22:37] <rockstar> abentley, stand up?
[22:38] <abentley> rockstar: sure.
[22:38] <abentley> rockstar: who's hosting?
[23:12] <jam> mwhudson: any chance you can lp-land my patch? mars at least approved of doing it. Or you can ec2land it, as they claimed the windmill stuff is fixed in devel
[23:12] <rockstar> wallyworld, https://code.edge.launchpad.net/~rockstar/launchpad/merge-queues-model/+merge/38762
[23:13] <mwhudson> jam: i've just sent it off to ec2 again
[23:15] <jam> mwhudson: thanks
[23:16] <mwhudson> jam: this has been a pretty long drawn out process, i hope your next launchpad branch goes more easily :)
[23:23] <thumper> Loading results failed. for a person search on edge
[23:23] <thumper> has this been fixed or looked at?
[23:24] <lifeless> its the person search
[23:24] <lifeless> edwin has a fix in progress
[23:40] <mars> thumper, I was writing a bug for that same problem - it breaks merge proposals too, you can't request new reviewers
[23:42] <mwhudson> usually middle click will short circuit the js
[23:43] <mars> thumper, bug 664214
[23:43] <_mup_> Bug #664214: "Request another review" search returns "Loading results failed" <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/664214>
[23:44] <mars> mwhudson, oops, doesn't work for MPs
[23:46] <mars> thumper, you are right, the "Subscribe someone else" link on bug reports has stopped working too
[23:46] <mars> I'll file a new bug about it
[23:47]  * thumper nods
[23:48]  * thumper afk for lunch meetup