[00:04] <maxb> woot, with the tarfile fails cleaned off, it's looking quite good.
[00:12] <maxb> I have a one-liner patch that I'd kind of like landed on devel. Is it appropriate to bother with a branch just for this?:
[00:12] <maxb> -    >>> http = HTTPCaller(host='launchpad.dev')
[00:12] <maxb> +    >>> http = HTTPCaller()
[00:14] <wgrant> maxb: How're you dealing with tarfile? Just fixing the tests in the 2.6 branch?
[00:15] <maxb> yes
[00:15] <maxb> I've pushed that
[00:15] <wgrant> Great.
[00:17] <lifeless> maxb: nothing lands without a branch; but it doesn't have to be yours :P
[00:17] <maxb> I guess my question is: is that too trivial for the reviewer overhead?
[00:19] <lifeless> thats what rs= is for :)
[00:21] <maxb> right :-)
[00:21] <maxb> Hrm. valid_absolute_url('whatever://example.com/blah') ---> False in 2.5, True in 2.6, because of stdlb chanes
[00:21] <maxb> *changes
[00:22]  * maxb wonders what to do about that
[00:24] <wgrant> I was wondering about that one.
[00:24] <wgrant> Does it now ignore the scheme?
[00:24] <wgrant> We already monkeypatch in extra schemes (sftp and bzr+ssh come to mind).
[00:25] <wgrant> This may also cause the DB constraint to be relaxed, which would be seriously seriously bad.
[00:26] <wgrant> OK, yes, it's seriously seriously bad.
[00:27] <wgrant> Oh, wait, that *is* the DB constraint. Oops.
[00:27] <wgrant> Or maybe not. i am confused.
[00:27]  * wgrant reads.
[00:28] <maxb> wtfness
[00:28] <wgrant> I don't know. This seems like a Python bug.
[00:29] <wgrant> Or at least a really dangerous behaviour change.
[00:29] <maxb> py2.6 urlparse disregard the uses_netloc list when parsing urls and treats anything beginning with // as netloc based
[00:29] <wgrant> Yep.
[00:29] <wgrant> WTF
[00:29] <maxb> Which is arguably saner than maintaining a list of specific schemes, but changing behaviour is just stupid
[00:30] <wgrant> Not just stupid -- very dangerous.
[00:31] <wgrant> Should we change both valid_absolute_url implementations to explicitly check the scheme against the monkeypatched uses_netloc?
[00:33] <maxb> It looks to me like the only thing that uses this is c.l.interfaces.validation.validate_url, which already checks against a passed in list of schemes
[00:34] <wgrant> maxb: What about valid_absolute_url in trusted.sql?
[00:35] <maxb> That will suffer the same bug, but is an independent implementation to the one failing the tests
[00:36] <wgrant> maxb: Right. But I would not fix the tested one until we've fixed the other one too, since it appears to be untested.
[00:36] <wgrant> Although i guess it could be tested, but PostgreSQL still uses 2.5.
[00:37] <wgrant> But no, PL/Python is built for 2.6
[00:37] <wgrant> So the DB constraint is untested.
[00:37] <wgrant> Yay.
[00:42] <wgrant> http://bugs.python.org/issue7904
[00:43] <wgrant> It's only a recent change.
[00:43] <wgrant> So they must have decided to change behaviour like that in a stable update.
[00:43] <wgrant> Awesomeness.
[01:01] <maxb> wgrant: Hi, do you have something in the pipeline towards landing for the foreign branch tdb issues?
[01:15] <wgrant> maxb: I don't. I guess I should prepare the two branches.
[01:15] <wgrant> Although I wonder if I'm going to cause bzr-hg test failures by ripping out the TDB thing.
[01:16] <wgrant> Hm, only 8 tests left to fix.
[01:17] <maxb> I'm looking at the initZopelessTwice one
[01:17] <wgrant> I looked at that before.
[01:17] <wgrant> My initial thought was that the method had been renamed.
[01:17] <wgrant> So the monkeypatch didn't work.
[01:17] <wgrant> But it looks fine.
[01:18] <maxb> Close - 2.6 is sending that codepath into a C extension, hence avoiding the monkeypatch
[01:18] <wgrant> I saw that evil down the bottom, but then decided to have breakfast first.
[01:20] <maxb> I'm in good humour, having returned to the computer having spent the evening in the pub :-)
[01:20] <wgrant> AFAICT there are only two remaining issues that are actually mysterious.
[01:20] <wgrant> The leftover thread one, and the _pythonpath one.
[01:21]  * wgrant takes bugs-emailinterface.txt
[01:40] <wgrant> OK, so, bugs-emailinterface.txt tests for the bug that http://bugs.python.org/issue7082 fixed.
[01:40] <wgrant> That test is probably insane.
[01:41]  * wgrant might talk to Bugs about that one tonight.
[01:46] <maxb> hmm, is emailauthentication.txt really just complaining about a wrapped line?
[01:46] <wgrant> maxb: yes.
[01:46] <wgrant> Just looking at that now.
[01:46] <wgrant> The point of the test is to test for whitespace; it tells doctest to not ignore whitespace changes.
[01:47] <wgrant> I'm not sure what the point of the test is.
[01:47] <wgrant> It says that we must be careful, because Python unfolds things.
[01:47] <wgrant> It appears that Python no longer does.
[01:47] <wgrant> I cannot see an obvious entry in NEWS about this.
[01:48] <wgrant> And the test does not make it clear what the implications of it are.
[01:48] <wgrant> Hm, I guess as long as the authenticateEmail succeeds it should be fine.
[01:48] <wgrant> - Issue #1670765: Prevent email.generator.Generator from re-wrapping
[01:48] <wgrant>   headers in multipart/signed MIME parts, which fixes one of the sources of
[01:48] <wgrant>   invalid modifications to such parts by Generator.
[01:52] <mwhudson> argh i hate the puller
[01:52] <mwhudson> i guess i should be happy that i'm deleting chunks of it
[01:52] <wgrant> maxb: Do you think that the carefulness it refers to is the manual boundary handling in lp.services.mail.signedmessage.SignedMessage._getSignatureAndSignedContent?
[01:53] <maxb> that seems plausible
[01:53] <maxb> So perhaps this test failure is inviting us to reconsider whether we still need to do that?
[01:53] <wgrant> I guess I'll delete the special case and rerun the tests in 2.5.
[01:53] <wgrant> I think so.
[01:54] <maxb> Certainly I don't think the failing test has any operational significance
[01:54] <wgrant> Hm, I guess we can't actually remove it.
[01:54] <wgrant> Since only Lucid has the Python fix.
[01:55] <maxb> Oh, is this a 2.6.x fix?
[01:55] <wgrant> So it probably deserves to have the test for broken folding removed, a bug filed, and _getSignatureAndSignedContent XXXd.
[01:55] <wgrant> 2.6.5.
[01:55] <maxb> ugh
[01:55] <wgrant> 2.6.5rc1, to be precise.
[01:56] <maxb> ok, concur with your plaan
[02:02] <mwhudson> biab, again
[02:09]  * maxb wonders what the point of filing a bug for every XXX is
[02:17] <wgrant> maxb: Turns out the bug isn't really fixed.
[02:17] <wgrant> It's just less broken than before.
[02:17] <maxb> :-/
[02:17] <wgrant> as_string() on the entire message preserves folding, but on the part loses it
[02:17] <wgrant> I'll alter the test to look at the part in question, which should work for both.
[02:18]  * maxb is working on tolerance to the apt-ftparchive changes
[02:19] <wgrant> I'm not sure if we want to be tolerant.
[02:19] <wgrant> It's going to change the archive. Probably in a good way, but I'd prefer to disable SHA1 and SHA256 for now.
[02:20] <maxb> hmm
[02:20] <wgrant> But I can't work out how to do that -- it doesn't seem to respect the config options when they are in the apt-ftparchive config.
[02:20] <wgrant> They may have to be in the apt config instead, and I'm not sure if we can pass a custom one into a-f.
[02:20] <wgrant> Mind you, I haven't looked at it for two or three months.
[02:20] <maxb> Interestingly, there's stuff left in the code from when the same issue affected Packages files, edgy->feisty
[02:20] <maxb> So I was thinking we'd handle it the smae
[02:21] <wgrant> What happened there?
[02:21] <wgrant> Just ellipsised out the extra hashes?
[02:21] <maxb> regexed them out, yes
[02:21] <maxb> err, string-maniped them out, rather
[02:23] <maxb> hmm, well, it's actually 2:20am here, so perhaps I should sleep instead :-)
[02:23] <wgrant> Heh, probably.
[02:23] <wgrant> Night.
[02:23] <maxb> I lean towards letting lucid's apt-ftparchive write the extra sums for the production archive
[02:24] <wgrant> If it's been done before, that's fine.
[02:24] <maxb> It looks to have been done that way before for Packages files, we'd now be doing the analogous change for Sources files.
[02:26] <maxb> Hrm, have you noticed that soyuz-upload.txt is now dropping a debian 'changelog' file into the root of the LP tree when run?
[02:27] <wgrant> I hadn't noticed. But so it does.
[03:13] <mwhudson> abentley: around?
[03:13] <abentley> mwhudson, a bit.
[03:14] <mwhudson> abentley: just replying to that merge proposal if you have time to look at that
[03:17] <abentley> mwhudson, looking.
[03:29] <poolie> spm, could you please run http://pastebin.ubuntu.com/414679/ across some of the logs and paste the first few lines of output?
[03:37] <spm> poolie: http://paste.ubuntu.com/414681/
[03:38] <poolie> urk, not quite enough
[03:39] <poolie> i guess it has the refererer url at the end?
[03:40] <poolie> spm how about http://pastebin.ubuntu.com/414683/
[03:41] <spm> poolie: yeah it does: 1.2.3.4 bugs.launchpad.net - [14/Apr/2010:07:00:04 +0100] "GET /ubuntu/lucid/+bugs?field.searchtext=&orderby=-importance&search=Search&field.importance%3Alist=CRITICAL&field.importance%3Alist=HIGH HTTP/1.0" 200 90458 "-" "Python-urllib/1.17"
[03:42] <spm> poolie: http://paste.ubuntu.com/414684/
[03:42] <poolie> ok, and what about the whole thing piped through '|sort|uniq -c' ?
[03:44] <spm> poolie: http://paste.ubuntu.com/414686/ <== might be worth checking for skew from robots. maybe.
[03:44] <poolie> wow
[03:44] <poolie> could you chain it together with your anti-robot filter that you showed the other day?
[03:45] <poolie> though actually i think it's unlikely there will be too many
[03:45] <poolie> because there's only a form linking to this url not (i think) generally an A ilnk
[03:45] <poolie> link*
[03:45] <poolie> that histogram is pretty damn suggestive btw
[03:45] <poolie> i guess that's just over less than a day's data?
[03:47] <spm> poolie: about half of 20 hours worth, for bugs.lp.net; not edge.
[03:47] <spm> 1 of 2 servers
[03:48] <poolie> so something like 10-20% of a day i guess
[03:48] <poolie> i wonder if power users tend to use edge?
[03:48] <poolie> thanks for helping btw
[03:50] <spm> poolie: np; just don't mention it too much eh? I have a rep as a BOFH to live up to. k?
[03:50] <poolie> heh
[03:51] <poolie> so would you mind running that on edge, across several days data, just to be sure it's not skewed?
[03:51] <spm> adding edge - same server/period - doesn't change the number much; sure.
[03:52] <poolie> i mean catting several days of logs into it, if that's possible
[03:52] <poolie> so that we get a few thousand hits altogether
[03:53] <spm> oh yeah - I was 3/4 thru typiing the above. figured I'd finish and then do several days
[03:53] <poolie> oh thanks
[04:04] <spm> poolie: http://paste.ubuntu.com/414692/ about half of nearly 2 weeks worth
[05:21] <wgrant> mwhudson: Hi. Half of the unsolved python2.6 failures are Codehosting threading things.
[05:22] <mwhudson> wgrant: oh goodie
[05:22] <wgrant> lp.codehosting.puller.tests.test_acceptance.TestBranchPuller.test_hosted_branch_stacked_on_mirrored_branch, in particular.
[05:22] <wgrant> If the .join callback is there, it hangs at that point.
[05:22] <wgrant> If it is not there, it leaves a thread behind.
[05:22] <mwhudson> well, the latter isn't really a surprise, that's why the join is there :-)
[05:23] <wgrant> Right.
[05:23] <wgrant> Threads make me sad -- any ideas?
[05:23] <mwhudson> one small one
[05:24] <mwhudson> wgrant: i don't suppose it will make any difference, but if you go to bzrlib/tests/http_server.py:563
[05:24] <mwhudson> wgrant: there's a comment about not having a join in a particular place
[05:24] <mwhudson> does it work if you add the join there?
[05:25] <mwhudson> wgrant: another idea would be to run gc.collect() before calling join
[05:29] <wgrant> mwhudson: Both suggestions hang quite effectively.
[05:32] <mwhudson> wgrant: :(
[05:33] <mwhudson> wgrant: is there an easy ish way i can reproduce this myself?
[05:33] <mwhudson> i have some terrifying gdb hacks lying around i can try to use...
[05:34] <mwhudson> (https://code.edge.launchpad.net/~mwhudson/+junk/pygdb if you want to try to adapt them yourself)
[05:34] <wgrant> mwhudson: https://dev.launchpad.net/PythonMigrationStatus <- just grab the integration branch, follow 'Setup caveats', and revert the patch which comments out the join.
[05:37] <wgrant> Four tests remain broken, two of which we have solutions for. Yay.
[05:41] <mwhudson> not too bad
[05:46] <stub> What do BranchRevision rows with a NULL sequence signify again?
[05:46] <mwhudson> stub: off mainline revisions
[05:54] <wgrant> stub: *Ouch* at that column type change time.
[05:55] <stub> difficult estimate to make though - it will be much faster on the kick arse hardware, but there are more nodes to update
[05:56] <wgrant> It's a bit sad that 99% of that table is probably duplicated dozens to thousands of times.
[05:56] <poolie> wgrant: https://bugs.edge.launchpad.net/malone/+bug/557432/comments/10
[05:56] <mup> Bug #557432: Hot Bugs algorithm works poorly for some projects, making it a bad default listing <story-bug-heat> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/557432>
[05:57] <wgrant> poolie: Yeah, I saw the paste.
[05:57] <wgrant> Rather interesting.
[05:57] <wgrant> We were both right, it seems :/
[05:57] <wgrant> awkward.
[05:57] <wgrant> poolie: Note, however, that since the default view is heat, there is less need to order search results by it.
[06:00] <poolie> tue
[06:00] <poolie> true
[06:00] <poolie> but 42, being about 0.2% of the total, is awfully low
[06:00] <wgrant> But I think the factor of 50 probably outweighs it by a bit.
[06:00] <wgrant> Right.
[06:02] <poolie> anyhow, i hope we can do more measurements like this
[06:02] <poolie> they're not watertight but they bring something beyond just gut feel
[06:02] <wgrant> Indeed. They're much better than guessing.
[06:03]  * mwhudson fills up his hard drive with 2.6 versions of all the eggs
[06:03] <wgrant> mwhudson: Weren't they all in download-cache anyway?
[06:03] <wgrant> Although you may have issues with a missing i386 version of some egg that I forget.
[06:04] <wgrant> The 2.6 i386 meliae egg is missing, that's right.
[06:04] <mwhudson> wgrant: the download-cache mostly contains tarballs
[06:04] <mwhudson> not built eggs
[06:04] <wgrant> Oh, so it does.
[06:06]  * wgrant gives up on checkwatches and leaves the last failure to Bugs.
[06:17] <mwhudson> wgrant: now i can run the test!
[06:17] <mwhudson> i wonder if that took long enough :/
[06:22] <mwhudson> wgrant: the test passes for me :/
[06:23] <mwhudson> wgrant: does it only fail as part of running the whole file or something?
[06:23] <wgrant> mwhudson: Did you revert the commenting-out that is in the branch?
[06:23] <mwhudson> wgrant: yes
[06:23] <wgrant> Argh.
[06:23] <wgrant> bin/test -vvt TestBranchPuller
[06:24] <wgrant> That reproduces it for at least three people.
[06:25] <mwhudson> ./bin/test -vvc  lp.codehosting.puller.tests.test_acceptance
[06:25] <mwhudson> is what i'm running
[06:25] <mwhudson> if using -t makes a difference, i am going to become very angry
[06:27] <mwhudson> Tear down canonical.testing.layers.ZopelessAppServerLayer is hanging for me a _lot_ lately
[06:28] <wgrant> Your machine hangs in the wrong place :(
[06:28] <mwhudson> and not just on this branch
[06:28] <cody-somerville> Whats the fix for the GpgmeError error in the testRepositorySignatureWithSigningKey test?
[06:28] <mwhudson> i guess it's the sort of thing that rebooting, or at least logging out and in again might fix
[06:28] <mwhudson> i may have stray processes
[06:29] <wgrant> cody-somerville: http://paste.ubuntu.com/414737/
[06:29] <cody-somerville> merci
[06:30] <wgrant> mwhudson: With http://paste.ubuntu.com/414739/ on top of lp:~launchpad-committers/launchpad/python2.6, both my -t and your -c invocations hang.
[06:36] <mwhudson> it seems test_mirror_imported_branch might have hung
[06:37] <mwhudson> or is just very very slow
[06:39] <mwhudson> looks pretty hung by now
[06:41] <wgrant> But a different test.
[06:41] <wgrant> Lovely......
[06:42] <mwhudson> woot, i have some tracebacks
[06:42] <wgrant> gdb?
[06:42] <mwhudson> yes
[06:42] <mwhudson> after a fashion
[06:42] <mwhudson> wgrant: this is the hung thread: http://pastebin.ubuntu.com/414743/
[06:44] <wgrant> Doesn't look very stopped to me.
[06:44] <mwhudson>         # Support people who used socket.settimeout() to escape
[06:44] <mwhudson>         # handle_request before self.timeout was available.
[06:44]  * mwhudson is suspicious
[06:44] <wgrant> Where's that?
[06:45] <mwhudson> wgrant: handle_request in SocketServer is at least quite different between 2.5 and 2.6
[06:45] <wgrant> Ah.
[06:47] <mwhudson> i guess that if you're select()ing on a server socket that's shutdown, something different happens than if you're accept()ing on a socket that's shutdown?
[06:48] <mwhudson> because that seems to be the difference
[06:48] <wgrant> Could be, yes.
[06:49] <mwhudson> oh grar
[06:49] <mwhudson> i guess the select() in SocketServer should have self in the error list as well
[06:49] <wgrant> It works if I force the timeout to 10 in SocketServer.
[06:50] <wgrant> Hmmm.
[06:50] <wgrant> Maybe.
[06:52] <wgrant> It also works if self is in all three.
[06:52]  * wgrant tries with it in wlist but not xlist.
[06:53] <wgrant> It doesn't work in just rlist and xlist.
[06:54] <mwhudson> i think this is perhaps the same issue: http://bytes.com/topic/python/answers/851825-socketserver-shutdown-deadlock
[06:57] <wgrant> Similar.
[06:57] <mwhudson> hm
[06:57] <wgrant> So, it works OK with self in rlist, wlist and xlist. But no subset thereof.
[06:57] <mwhudson> i guess it should be fixed in bzr
[06:57] <mwhudson> can probably fix it by hacking in launchpad though
[06:57] <mwhudson> well, it should be fixed in python
[06:57] <mwhudson> but it's a bit late for that
[06:58] <wgrant> Indeed... If you can work out the appropriate Launchpad hack, we can probably have the test suite passing under 2.6 in a few hours. Yay.
[07:06] <mwhudson> wgrant: http://pastebin.ubuntu.com/414750/ maybe
[07:07] <wgrant> mwhudson: Is that actually the right solution, though?
[07:07] <mwhudson> well it doesn't seem to work :(
[07:07] <mwhudson> oh no
[07:08] <mwhudson> confusing slow and hanging tests there
[07:08] <wgrant> mwhudson: http://bugs.python.org/issue2302 seems to be a bug about that shutdown thing you linked to earlier.
[07:09] <mwhudson> wgrant: that seems a bit different
[07:10] <mwhudson> wgrant: the problem that i saw was that the server thread went into a select that will never return
[07:10] <wgrant> Right.
[07:10] <wgrant> So server_forever was indeed running at the time, so it's probably irrelevant.
[07:11] <mwhudson> noi
[07:11] <mwhudson> server_forever is not called
[07:11] <wgrant> Bah.
[07:11] <mwhudson> by bzrlib
[07:11] <wgrant> Anyway, lecture over... I should go home.
[07:11] <mwhudson> haha
[07:12] <mwhudson> wgrant: do you want me to push that patch somewhere, or .. ?
[07:12] <wgrant> mwhudson: If it makes sense to you and probably doesn't just work by accident, I guess push it to the 2.6 branch.
[07:13] <wgrant> At least it's only used in tests; it can't go horribly wrong.
[07:16] <wgrant> OK, now I just have to get approval for one change from Bugs, advice from them on another, and we need to work out the best fix for validate_absolute_url.
[07:16] <wgrant> Then we are DONE.
[07:16] <wgrant> Thanks for fixing that one/
[07:16]  * wgrant wanders off.
[07:22] <mwhudson> hm
[07:22] <mwhudson> not sure the fix is right actually :(
[07:44] <adeuring> good morning
[08:51] <maxb> *blink*
[08:51] <maxb> regexes are really discouraged entirely in launchpad code?!
[08:52] <maxb> is this really true?
[08:53] <lifeless> first I've heard of it
[08:54] <maxb> noodles775 attempted to convince me of this in a code review
[08:55] <noodles775> I can't remember who had mentioned it to me, intellectronica perhaps - as I mentioned on the MP, it's not in the styleguide, so up to you.
[08:55] <lifeless> re is generally faster and more reliable than adhoc stuff
[08:55] <lifeless> so I would say 'whatever is clearer'
[08:56] <maxb> noodles775: Yeah, I'm not implying you're being unreasonable, I'm just experiencing shock at the concept :-)
[08:56] <lifeless> I don't see anything in the reviewer minutes about it either
[08:57] <noodles775> lifeless: I don't even know that it's ever come up... it was just something that I was told for a branch I had ages ago that used a semi-complicated re.
[08:57] <noodles775> lifeless: that's why I said it was up to maxb :)
[08:58] <noodles775> maxb: in which case, do you want me to send it off to land as is?
[09:01] <mrevell> Morning!
[09:11] <maxb> noodles775: yes please, if you're happy with that
[09:13] <noodles775> maxb: Sure. Done.
[09:35] <wgrant> Any Bugs people around? I need advice on what to do with the section of bugs-emailinterface.txt beginning with 'Some mail clients append a filename to the content type of attachments.
[09:35] <wgrant> '
[09:36] <wgrant> It breaks in 2.6, because the behaviour that it says should not occur (extracting a filename from Content-Type, rather than Content-Disposition) now occurs due to a Python bugfix.
[09:37] <wgrant> It appears safe to fix the test to expect that the filename is extracted from Content-Type... but I'm wondering why the broken behaviour was tested in the first place.
[09:45] <intellectronica> wgrant: let me have a look
[09:46] <wgrant> (this is one of the four remaining 2.6 failures)
[09:46] <wgrant> intellectronica: Thanks.
[09:46] <intellectronica> actually, adeuring might know more about this. i remember he did some work in this area lately
[09:47] <maxb> wgrant: sorry, I just added another two in MailmanLayer to the wiki page :-)
[09:47] <wgrant> maxb: Nooooooo.
[09:47] <maxb> well, I added 3 and fixed 1
[09:48] <adeuring> hrmmm, well, there is something....  main problem is my bad memory... let me look at the affected code/tests
[09:48] <wgrant> I was running that just before I headed home, but it disagreed with being suspended for two hours.
[09:48] <intellectronica> adeuring: maybe i'm wrong, this is about headers in mail. i remembered that you worked on attachments in the webapp.
[09:49] <intellectronica> BjornT: do you maybe remember why this was done? ^^^
[09:49] <adeuring> intellectronica: yeah, you are probably right...
[09:50] <intellectronica> wgrant: i'm looking myself at the code, but my guess is as good as yours, which is why i'm looking for someone who might know the history of that code.
[09:51] <lifeless> thumper: back, perchance?
[09:52] <adeuring> wgrant: what breaks in this test?
[09:53]  * maxb has a shocking thought: Python 2.6 for 10.04 == not unachievable
[09:54] <intellectronica> wgrant: so i'm not sure if it's really important to ignore the filename supplied with content-type, as long as it doesn't change the behaviour of signatures, right?
[09:54] <wgrant> adeuring, intellectronica: http://pastebin.ubuntu.com/414824/ is my fix.
[09:55] <wgrant> intellectronica: And the signature depends solely on the MIME representation; not our interpretation of it.
[09:55] <adeuring> wgrant: yes, that sould be fine
[09:55] <wgrant> (well, assuming a lack of Python bugs, which there is not)
[09:55] <intellectronica> wgrant: yes, that looks like the correct fix to me
[09:55] <wgrant> intellectronica, adeuring: Thanks.
[09:55]  * wgrant commits to the integration branch.
[09:57] <wgrant> maxb: Ah, I see you still love the tarfile maintainer.
[09:58] <maxb> :-)
[09:58] <maxb> I suppose I have the consolation that after figuring it out last time, this was a pretty shallow bug
[09:58] <adeuring> wgrant: this failure actually means that LP will process mails from Microsoft Entourage somewhat better, once we switch to Python 2.6
[09:59] <adeuring> (another point is that this program should be banned)
[09:59] <wgrant> adeuring: That is not a feature.
[09:59] <wgrant> Heh, yes.
[09:59] <maxb> lol
[09:59] <adeuring> wgrant: I agree completely ;)
[10:01] <wgrant> maxb: Ah, so the mailman timeouts are normal? I presumed they were from being asleep for hours.
[10:03] <maxb> well, I'm going by Barry's comment on the wiki page that there are spurious failures if you run those tests not individually
[10:03] <maxb> I ran the ones that failed individually and they passed
[10:04] <wgrant> adeuring, intellectronica: Also, there is one other Bugs failure that I haven't got to the bottom of yet. Do you have any ideas about test_bug_496988 on https://dev.launchpad.net/PythonMigrationStatus?
[10:06] <intellectronica> hmmmm ... it's worth asking allenap and gmb about this one, they might have an idea
[10:06]  * gmb looks
[10:06] <wgrant> gmb, intellectronica: Thanks.
[10:07] <intellectronica> maybe the result is that we have to doctor the headers to satisfy the new version of xmlrpclib
[10:07] <gmb> intellectronica, wgrant: Yeah, I think that might well be the case.
[10:10] <wgrant> intellectronica, gmb: Any specific hints, or shall I go digging?
[10:13] <gmb> wgrant, If you give me five minutes I'll have a look at the test. I suspect that some of our testing infrastructure for the XML-RPC tests, which is mostly a looks-like-xmlrpc-but-isn't object isn't playing nice.
[10:13] <BjornT> intellectronica: can i remember why what was done?
[10:15] <gmb> Okay, something weird's going on...
[10:16] <intellectronica> BjornT: why we had a test for the broken behaviour where a filename specified in the content-type header of a mail is ignored. but unless something comes to mind don't worry about it, i think wgrant has a reasonable fix, now that the behaviour of email parsing was fixed in python2.6
[10:17] <gmb> Oh, the test's moved. that's why I couldn't find it.
[10:17] <wgrant> gmb: Yeah, it took me a while too.
[10:18] <gmb> See, this is why we should never, ever refactor things and just keep the whole of LP in launchpad.py
[10:19] <gmb> OH DEAR GOD.
[10:19] <wgrant> Oh dear god?
[10:20] <gmb> wgrant, Badly-written test.
[10:20] <wgrant> gmb: So it *wasn't* just me.
[10:20] <gmb> But, might be indicative of issues we'll ahve in the future when we switch to 2.6 with doing XML-RPC queries to remote trackers; I don't know.
[10:20] <gmb> wgrant, nope.
[10:20] <gmb> wgrant, that test actually tries to contact the gnome bugzilla.
[10:21] <wgrant> gmb: Oh yes, I noticed that when I tried to run it on the train.
[10:21] <wgrant> It was not happy.
[10:21] <BjornT> intellectronica: no, i can't remember why. it seems like an odd test.
[10:21] <gmb> wgrant, I think I wrote it, and once I've worked out how to fix it I'll throw myself on my sword.
[10:21]  * gmb makes a note: buy a sword
[10:21] <wgrant> Heh.
[10:22] <wgrant> Apr 15 14:48:12 2010 (31672) Received these actions: create
[10:22] <wgrant> Apr 15 14:48:12 2010 (31672) List creation error for team: itest-one
[10:22] <wgrant> Apr 15 14:48:12 2010 (31672) An error occurred; the list was not created: itest-one
[10:22] <wgrant> Thankyou, mailman, for your descriptive errors.
[10:30] <gmb> wgrant, Actually, it's not all that bad, because I *think* it might show that we'll have a problem with XML-RPC and bugtrackers when we move to 2.6.
[10:31] <dhastha> wgrant, Is there any tool which using launchpad API? like bzr-eclipse, tarmac, apport, ubuntu-dev-tools, and ilaunchpad-shell
[10:32] <gmb> wgrant, So, one way to fix it is to monkeypatch lp.bugs.externalbugtracker.get_external_bugtracker to return a Bugzilla instance that doesn't try to connect out. See test_updater.py:131 for an example of us doing this.
[10:34] <gmb> wgrant, in this case we want a get_external_bugtracker that returns a subclass of lp.bugs.externalbugtracker.bugzilla.BugzillaAPI whose getExternalBugTrackerToUse() method just returns self rather than contacting the remote server. I *think* that should do the trick.
[10:34] <wgrant> dhastha: What do you mean? Aren't those all tools that use it?
[10:37] <dhastha> wgrant, sorry.  I have to know, is there any application using launchpad api?
[10:41] <wgrant> dhastha: All those examples you gave above do, don't they?
[10:47] <wgrant> maxb: Um, I'm not sure those two mailman tests even pass in 2.5.
[10:47] <wgrant> I get the same errors there.
[10:47] <lifeless> wgrant: bzr-eclipse, tarmac don't
[10:47] <lifeless> wgrant: last I heard, anyhow.
[10:48] <wgrant> (yay for tests that are not run by default?)
[10:48] <wgrant> lifeless: Hm, I'm pretty sure tarmac does.
[10:49] <lifeless> oh, perhaps I mean 'doesn't use my pet feature'
[10:49] <wgrant> lifeless: Merge queues that weren't meant to be exposed? :P
[10:50] <lifeless> wgrant: meh, they are meant to be according to thumper
[10:50] <lifeless> just not finished
[11:03] <deryck> Morning, all.
[11:10] <bigjools> apt-get dist-upgrade on lucid this morning wants to remove launchpad-developer-dependencies :/
[11:19] <bigjools> ah, python-apt got bumped in lucid
[11:27] <lifeless> what would cause
[11:27] <lifeless>     raise HTTPError(response, content)
[11:27] <lifeless> lazr.restfulclient.errors.HTTPError: HTTP Error 414: Request-URI Too Large
[11:27] <wgrant> That's a new one.
[11:27] <lifeless> I'm trying to lookup 126 branches by url at once
[11:28] <wgrant> Ah.
[11:28] <lifeless> squid allows several mb of URI IIRC
[11:28]  * lifeless bugifies
[11:28] <lifeless> launchpadlib, you think?
[11:28] <wgrant> That looks like a server-side error to me.
[11:29] <maxb> bigjools: so it did. uploading....
[11:29] <maxb> I have this down to executing 'lpnochange python-apt' now :-)
[11:30] <bigjools> maxb: :)  thanks
[11:30] <wgrant> maxb: Those two mailman failures are indeed legit bugs in 2.5 as well. I'm fixing them now.
[11:31] <bigjools> I have bigger issues, like the upgrader deciding not to install latest versions of some packages ...
[11:31] <maxb> bigjools: !
[11:31] <wgrant> bigjools: That's normal if there's arch skew.
[11:31] <wgrant> And when the build farm breaks, there will be arch skew.
[11:31] <bigjools> that's probably what it was
[11:31] <bigjools> I need to install the task for the -desktop package
[11:32] <bigjools> it  does explain all the frickin breakage!
[11:33] <mwhudson> wgrant: i didn't seem to fix the http server hang :/
[11:33] <wgrant> mwhudson: :(
[11:33] <mwhudson> i'll look tomorrow when i'm more alert
[11:55] <lifeless> jml: around ?
[11:55] <lifeless> mwhudson: or are you still here ?
[11:55] <lifeless> getByUrls is returning a dict mapping strings -> dicts rather than strings->Entries
[11:57] <wgrant> lifeless: lazr.restful doesn't support it.
[11:58] <wgrant> Well, actually, the WADL implementation doesn't support dicts, so lazr.restfulclient isn't told to interpret them as entries.
[11:59] <lifeless> this is painful
[11:59] <wgrant> Yes.
[11:59] <lifeless> what does it take to fix
[12:00] <wgrant> leonardr: ^^?
[12:00] <lifeless> hes us based
[12:00] <leonardr> i'm here
[12:00] <lifeless> isn't he?
[12:00] <leonardr> yes
[12:00] <wgrant> He is. Eastern USians are around now
[12:01] <wgrant> Some of.
[12:01] <leonardr> i don't think it would be difficult to add support for that but it's also pretty low on my priority list. it's one of the things i'm going to look at for streamlining the web service
[12:02] <wgrant> Or my timezones are wrong. That is more likely.
[12:03] <wgrant> adeuring: The test is probably executed once for each bugtarget implementation.
[12:03] <lifeless> hmm, 10 minutes to do the branch lookups
[12:03] <wgrant> lifeless: This is Launchpad...
[12:03] <lifeless> leonardr: this /really/ hurts. Can you suggest workaruonds.
[12:04] <lifeless> wgrant: its ~ 1 minute with batches
[12:04] <lifeless> wgrant: which I can't use...
[12:04] <leonardr> my usual workaround seems to be the thing that seems to be hurting you--a dict with strings
[12:04] <lifeless> leonardr: right; I want a collection with objects
[12:05] <leonardr> is getByUrls the thing that's published now?
[12:05] <lifeless> yes
[12:06] <lifeless> leonardr: if you could describe how to approach the problem, in a lplib bug, I might take a peek, or get someone I know to take a peek,.
[12:06] <lifeless> leonardr: I think guidance from you is a key step to someone else doing it though
[12:06] <lifeless> leonardr: oh, while you are here
[12:07] <leonardr> so, general steps
[12:07] <lifeless> leonardr: do lplib objects compare == if they have the same canonical url ?
[12:07] <leonardr> yes, as per https://bugs.edge.launchpad.net/launchpadlib/+bug/264098
[12:07] <mup> Bug #264098: launchpadlib should implement __eq__ and __ne__ <launchpadlib :Fix Released by leonardr> <https://launchpad.net/bugs/264098>
[12:08] <lifeless> leonardr: and are they hashable ?
[12:08] <leonardr> i don't know
[12:08] <lifeless> ok
[12:08] <lifeless> what version of lplib is that fix in ?
[12:11] <leonardr> the lazr.restfulclient NEWS.txt says 0.9.10
[12:11] <lifeless> uugh, ok.
[12:11] <lifeless> I'll comapre self_link then
[12:11] <lifeless> (datacentre has 0.2.3)
[12:12] <leonardr> is that even a real version? i don't see it in NEWS
[12:13] <adeuring> wgrant: right
[12:13] <adeuring> wgrant: thanks for the xplataion!
[12:13] <lifeless> leonardr: I may have the number slightly wrong
[12:13] <adeuring> ...explanation...
[12:13] <lifeless> leonardr: probably 0.2~bzr35-0ubuntu1 or something
[12:13] <lifeless> leonardr: its a port to hardy, after all
[12:14] <leonardr> i see
[12:14] <leonardr> maybe 0.9.3
[12:14] <lifeless> no
[12:14] <lifeless> probably one of these:
[12:14] <lifeless> python-launchpadlib | 0.2~bzr25-0ubuntu1 | intrepid/universe | source, all
[12:14] <lifeless> python-launchpadlib | 0.2~bzr35-0ubuntu1 | jaunty/universe | source, all
[12:14] <lifeless> I saw the version a few days back, it was definitely 0.2something
[12:19] <leonardr> it's possible the version numbers were very different before launchpadlib was split into lazr.restfulclient and launchpadlib
[12:19] <leonardr> but pretty much nothing you want will be in there--including sensible support for dicts, which isn't anywhere yet
[12:21]  * wgrant now understands why MailmanLayer isn't in normal test runs...
[12:27] <lifeless> leonardr: sure
[12:27] <lifeless> leonardr: I've filed an RT to get 1.5.1 on pqm
[12:28] <lifeless> leonardr: you were going to describe how to approach supporting a dict of objects as a return value
[12:28] <leonardr> right
[12:28] <leonardr> 1. create @returns_dict_of similar to @returns_collection_of
[12:29] <leonardr> 2. come up with a wadl description of what @returns_dict_of means and put it in the wadl
[12:29] <lifeless> whats the difference between a dict and a collection ?
[12:29] <leonardr> a collection is a list
[12:29] <lifeless> ok
[12:29] <lifeless> if we're using non python names, should we say 'returns_map_of' ? :P
[12:29] <leonardr> 3. have lazr.restful properly serialize a dict to json (this might work already)
[12:30] <leonardr> 'collection' is a term from the atom publishing protocol. there's no corresponding term for 'map' so i don't think it matters much
[12:31] <leonardr> 4. have lazr.restfulclient pick up on @returns_dict_of and handle it properly. old versions won't be able to handle the return value so we should probably do this in a new version of the web service
[12:35] <lifeless> leonardr: I can't see an obvious matching bug on launchpadlib
[12:35] <lifeless> leonardr: should I file one with this conversation?
[12:35] <leonardr> lifeless: https://bugs.edge.launchpad.net/lazr.restful/+bug/481090
[12:35] <mup> Bug #481090: Cannot define a method that returns a dict <lazr.restful:Triaged> <https://launchpad.net/bugs/481090>
[12:36] <lifeless> ah, ok
[13:00] <jml> for this case, you don't want list semantics, you really want dict semantics, I think
[13:00] <jml> .
[13:07] <leonardr> jml, let me ask you this now rather than as part of a conversation later--how happy would it make you if i added this feature vs other features we've discussed?
[13:08] <jml> leonardr: probably there would be a net change of zero to my happiness
[13:09] <jml> leonardr: the stuff you've got scheduled now is more important. this particular bug annoys me though.
[13:11] <leonardr> jml: how about once i get on to streamlining the web service? work on this first, on something else first, or talk to you then?
[13:13]  * jml thinks
[13:14] <jml> leonardr: by streamlining, are you referring to the "publish lazr.restful ops more naturally" task?
[13:14] <leonardr> jml, yes
[13:14] <leonardr> this falls under that task, i think
[13:15] <leonardr> more urgently, i need to talk to you about performance at this point
[13:15] <jml> leonardr: ok.
[13:16] <jml> leonardr: I agree it falls under that task, despite the fact that the end-user benefit is greater perceived performance
[13:16] <leonardr> jml: how much longer will you be around?
[13:17] <leonardr> i wonder if i should talk to you first or clean up the performance wiki page
[13:17] <jml> leonardr: probably another eight hours
[13:17] <leonardr> ok, let me fix up the wiki and we can talk about performance next steps
[13:17] <jml> leonardr: cool.
[13:31] <jml> dammit, where's my hasbean delivery?
[13:46] <leonardr> jml, i've sorted our performance interventions so far:
[13:46] <leonardr> https://dev.launchpad.net/Foundations/Webservice/Performance
[13:57] <wgrant> bigjools: Did you end up filing an RT for the PPA access log parser?
[14:10] <jml> leonardr: regarding "Request service root conditionally", what was launchpadlib doing before your fix?
[14:12] <leonardr> jml: launchpadlib was making a non-conditional request, thus your 'download the wadl every time' problem
[14:12] <jml> leonardr: on every request?
[14:12] <leonardr> jml: no, on every startup
[14:12] <jml> leonardr: ahh, ok.
[14:21] <jml> leonardr: sorry, mega-interrupty day
[14:23] <jml> leonardr: can we talk in about three hours time?
[14:23] <leonardr> jml, sure
[14:23] <jml> leonardr: thanks.
[14:23] <leonardr> or at some point--i have interruptions like doctors appointments today
[14:26] <jml> ok
[15:02] <jml> lifeless, you do know that the last element of an MP url is the db id, right?
[15:02] <lifeless> jml: I know it happens to be
[15:03] <lifeless> jml: I don't know that its guaranteed to stay that way
[15:03] <lifeless> the self_link docs on branch_merge_proposal in the api doc don't claim either point
[15:03] <jml> lifeless, ok. I'm not saying the bug you filed is invalid, just pointing to a potential workaround
[15:03] <lifeless> jml: I put that precise workaround in place before filing it ;)
[15:04] <jml> lifeless, good good
[15:34] <mars> gary_poster, is the current buildbot configuration, specifically the purpose of the various build slaves, documented somewhere?
[15:36] <gary_poster> mars, not to my knowledge but maybe.  This is the closest we have: https://dev.launchpad.net/Trunk/Glue
[15:39] <wgrant> maxb: What do you think we should do about validate_absolute_url and co.?
[15:39] <wgrant> That's about the only thing left.
[15:56] <mars> deryck or gmb, think we can close bug #227824?
[15:56] <mup> Bug #227824: BugPageTwoZero related branches table inline editing <ui> <Launchpad Bugs:Confirmed> <https://launchpad.net/bugs/227824>
[15:56] <gmb> mars, No. You can't edit branches inline.
[15:56] <maxb> wgrant: AFAICS It is not a problem that the valid_absolute_url that is being tested now accepts any scheme. It is only the DB constraint that matters.
[15:57] <mars> gmb, ok.  The "BugPageTwoZero" stuff confused me.  I thought we were a bit beyond that :)
[15:57] <maxb> In respect of the DB constraint, I think it is dodgy for a constraint named validate_absolute_url to secretly imply a limited list of schemes.
[15:57] <gmb> mars, For BugPageTwoZero, read "ThingsWeWantedToDoForTwoZeroButDidntGetRoundTo"
[15:57] <mars> hehe
[15:57] <maxb> I would be in favour of any DB columns which actually need to be scheme restricted growing something more explicit to say so
[15:58] <deryck> and there's this nifty inline title editing on launchpad, too.
[16:58] <Ursinha> Chex, gary_poster, rockstar, bigjools, danilos, sinzui, allenap, production meeting @ #launchpad-meeting in 2 minutes
[16:59] <bigjools> arg
[16:59] <danilos> ack
[16:59] <Ursinha> bigjools, c'mon, be nice
[17:23] <cody-somerville> hmm... has anyone else started to get ImportError: No module named apt_pkg on lucid?
[17:24] <cody-somerville> I'm getting it when trying to run some soyuz tests
[17:24] <jpds> cody-somerville: Installed python-apt from the PPA?
[17:24] <james_w> cody-somerville: did you install the python-apt from lucid and remove the 2.5 version from the PPA?
[17:25] <cody-somerville> 0.7.94.2ubuntu6 superseded the version from the PPA it seems, 0.7.94.2ubuntu5launchpad2
[17:28] <bigjools> maxb said he was going to upload a new one earlier
[17:28] <maxb> grrrr
[17:29] <bigjools> heh :)
[17:29] <bigjools> cody-somerville: what are you using to install updates?  Mine failed because of the broken package.
[17:29] <maxb> Would someone wield their buildd-admin powers and rescore this, please: https://launchpad.net/~launchpad/+archive/ppa/+build/1693771
[17:29] <cody-somerville> I use update-manager
[17:30] <bigjools> maxb: coming up
[17:30] <bigjools> geez lp is slow
[17:30] <cody-somerville> maybe a RBS should be set for that PPA too?
[17:31] <bigjools> maxb: powers wielded
[17:34] <maxb> RBS?
[17:58]  * bigjools broke devel and is fixing it
[17:58] <bigjools> except gpgme is screwed and my broken tests need it...GAH
[18:03] <mrevell> night all
[18:06] <maxb> bigjools: hmm?
[18:06] <bigjools> might be that I didn't update sourcecode....
[18:07] <maxb> If this is the lucid pygpgme problem, just bzr pull in the pygpgme directory
[18:07] <maxb> My branch to actually bump the revno in sourcedeps.conf is stuck in ec2 somewhere
[18:07] <bigjools> ok will try that if rf-get fails
[18:08] <bigjools> I <3 my SSD
[18:09] <maxb> Hrm, I've had 3 branches go through ec2 in ~3h20 today, and the fourth hasn't shown up yet
[18:09] <bigjools> revno 49?
[18:11] <bigjools> maxb: I did a pull and make in the pygpgme dir but no luck, still getting gpg failures in the test
[18:12] <bigjools> the error changed from before though :)
[18:12] <maxb> what is the failure?
[18:12] <bigjools> GpgmeError: (7, 32816, u'Invalid argument')
[18:12] <maxb> hrm
[18:13] <bigjools> if you have a working box do you mind running a few tests for me so I can land my testfix?
[18:13] <maxb> I can try
[18:14] <bigjools> maxb: great thanks, it's here: lp:~julian-edwards/launchpad/ppa-quota-bug-413563
[18:14] <bigjools> bin/test -cvvt TestPPAUploadProcessorQuotaChecks
[18:15] <bigjools> maxb: actually
[18:15] <bigjools> never mind - I did a make clean and it works now
[18:15] <bigjools> thanks
[18:45] <sinzui> barry, ping
[18:47] <jml> leonardr-afk, some stuff came up -- let's talk tomorrow
[19:03] <jml> g'night all
[19:20] <barry> sinzui: pong
[19:21] <sinzui> barry, does the holds on staging queue need a kick from an admin to send things to moderation
[19:21] <sinzui> https://staging.launchpad.net/~launchpad-users/+mailinglist-moderate
[19:22] <sinzui> ^ I sent three messages, expecting 1 to go to the archive (it did), one to go to moderation, and one to be discarded
[19:23] <sinzui> barry, I wonder if both my missing messages were discarded
[19:23] <barry> sinzui: it shouldn't.  i bet they were.  you can check the mailman logs from staging to know for sure
[19:24] <sinzui> barry, the vete?
[19:24] <barry> sinzui: check both vette and xlmrpc
[19:24] <sinzui> thanks
[19:24] <barry> np
[21:24] <maxb> jelmer: Do you remember if your 'update pygpgme to trunk' ever got tested? I'm seeing failures in my python 2.6 environment
[21:51] <mwhudson> good morning
[21:59] <thumper> morning
[21:59] <james_w> morning
[22:18] <leonardr> flacoste, gary and i have a question
[22:18] <leonardr> how reliable are the zope events that tell us that a launchpad object changed?
[22:18] <leonardr> ie. can we be certain that every time an object changes, an event is sent out about it?
[22:19] <flacoste> leonardr: unfortunately, that's not magic
[22:19] <flacoste> it will only be sent out if the call sites, sends the event
[22:19] <flacoste> so not totally reliable
[22:19] <flacoste> although a lot of things break when that doesn't happen
[22:20] <flacoste> unfortunately, things have broken in the past
[22:20] <gary_poster> flacoste: but we rely on them already, yes?
[22:20] <flacoste> yes
[22:20] <flacoste> for notifications
[22:20] <flacoste> and at some points in the API
[22:20] <gary_poster> flacoste: we are intending to rely on them for invalidations of cached webservice representations.  Any reservations?
[22:21] <flacoste> several
[22:21] <gary_poster> heh
[22:21] <flacoste> the first one is that not all objects will send events on modification consistently
[22:21] <flacoste> because we don't rely on them for all objects
[22:21] <flacoste> so the one for which we rely, we spot breakage
[22:22] <flacoste> but for many objects, they don't systematically send events on mutation
[22:22] <flacoste> i'd say the majority even
[22:22] <gary_poster> ah :-(
[22:22] <gary_poster> that's a biggie
[22:27] <leonardr> flacoste: we're considering cache invalidation options
[22:27] <leonardr> is there any amount of cache staleness we're willing to tolerate in the web service?
[22:27] <flacoste> leonardr: i say it can work, but we'll have a lot of fixup to do, that's my opinion
[22:28] <flacoste> i need to run now, ttyl
[22:28] <gary_poster> leonardr, flacoste let's contonue this on email
[22:28] <leonardr> all right
[23:17] <mwhudson> hooray testfix
[23:17] <mwhudson> oh updating sourcecode failed
[23:33] <cody-somerville> mwhudson, does it complain about recursive symlink?
[23:33] <mwhudson> cody-somerville: hm?
[23:33] <cody-somerville> mwhudson, updating the sourcecode
[23:34] <mwhudson> cody-somerville: no
[23:34] <mwhudson> cody-somerville: at least, not in buildbot
[23:34] <cody-somerville> ah
[23:34] <cody-somerville> Does testRepositorySignatureWithSigningKey fail for anybody else on db-devel?
[23:35] <maxb> oh, maybe. What revno of pygpgme do you have, though
[23:35] <cody-somerville> 48
[23:36] <maxb> ok. I did see that fail, but I wasn't sure whether it was part of the rest of the breakage that is r49 of pygpgme
[23:37] <cody-somerville> r49? I just did ./utilities/update-sourcecode and it says 48 is the latest.
[23:38] <mwhudson> failure in the devel buildbot, someone broke lib/lp/soyuz/browser/tests/archive-views.txt
[23:46] <mwhudson> losa ping
[23:55] <mbarnett> heya mwhudson
[23:55] <mwhudson> mbarnett: can you tell me the state of the launchpad tree on strawberry?