[00:19] <cjohnston> Anyone know where the the text that was in http://goo.gl/O4CQ4 went to?
[00:19] <cjohnston> (as in, where I might find it now)
[00:54] <StevenK> wgrant: Hmmm, my pdb isn't firing.
[00:56] <wgrant> StevenK: Where is it and why isn't it firing?
[00:56] <StevenK> wgrant: http://pastebin.ubuntu.com/1203852/
[00:59] <wgrant> StevenK: Oh, right
[00:59] <wgrant> StevenK: That view isn't /+archivesubscriptions/$ID
[00:59] <wgrant> It's ArchiveSubscription:+index or so
[01:01] <StevenK> team_sub, '+index' doesn't fire it either
[01:27] <StevenK> Oh, bah, ArchiveSubscription:+index is the edit view
[01:38] <StevenK> wgrant: I think this is a race.
[01:38] <StevenK> wgrant: They all back onto IArchiveAuthTokenSet.getActiveTokenForArchiveAndPerson()
[01:40] <StevenK> So when the guard checks, self.active_token is an EmptyResultSet, then IArchive.newAuthToken() is called, and when it calls the same method, it returns a token and raises
[01:45] <StevenK> s/an EmptyResultSet/None/
[01:47] <wgrant> StevenK: But it's not a unique violation from the DB, is it?
[01:48] <StevenK> wgrant: No, it's newAuthToken raising it
[01:49] <wgrant> StevenK: Each appserver transaction sees an isolated snapshot of the DB
[01:49] <wgrant> StevenK: If newAuthToken can see it in the DB (and not by a unique constraint violation error), then it's not a race
[01:49] <wgrant> The appservers are not READ COMMITTED
[01:49] <StevenK> wgrant: Both the view's self.active_token and IArchive.getAuthToken() back onto the same method
[01:49] <StevenK> So I don't get how it could return None and then a token
[01:49] <wallyworld__> wgrant: StevenK: sinzui: are we supporting embargoed specs for private projects?
[01:49] <wgrant> wallyworld__: IMO no, but it seems like we are
[01:50] <wallyworld__> i'm reviewing a branch which has them
[01:50] <wgrant> There's already code landed that permits them
[01:50] <wgrant> So don't block this on that
[01:50] <wallyworld__> ok
[01:52] <StevenK> wgrant: Can you think of a scenario? Because I can't, but it happens. :-(
[01:53] <rick_h__> I think it's coming out of the need for Private Projects to have public, embargoed, proprietary options
[01:53] <rick_h__> all of the apps will get default apps that match the project ootb I believe
[01:53] <StevenK> Why? Embargoed is special
[01:53] <StevenK> Public and Proprietary sure, sounds good
[01:53] <wgrant> The debate over whether Embargoed makes sense for a project is still raging
[01:53] <rick_h__> because it's strange to have a new project setup with one option and see something you didn't select somewhere else
[01:53] <rick_h__> right
[01:54] <rick_h__> agreed, so easier to take it into account and remove than to fit back in
[01:54] <wgrant> If Embargoed makes sense for a project, then it makes sense for blueprints
[01:55] <rick_h__> but if you stick to the idea that embargoed imples one day being public while proprietary does not, then it seems there's a niche for it
[01:57] <StevenK> Other way around
[01:58] <lifeless> StevenK: huh ?
[01:59] <wgrant> StevenK: No, rick_h correctly portrays the other side of the argument
[02:00] <wgrant> That Embargoed should also be used for Proprietary stuff that may become public
[02:00] <wgrant> I tend to disagree
[02:03] <wgrant> But there are reasonable arguments both ways
[02:03] <StevenK> wgrant: So I can't think of how to write a test for this issue, and you rejected my current fix.
[02:05] <wgrant> StevenK: can you link me back to an oops?
[02:05] <StevenK> wgrant: https://oops.canonical.com/oops/?oopsid=OOPS-3607c5f44e382d14bd9ff678dbc51097
[02:05] <wgrant> Suppressing an exception when we don't know why it happens is a good reason to reject a fix :)
[02:05] <wgrant> StevenK: Do you have a recent one?
[02:06] <wgrant> Or maybe that URL is just bad
[02:06] <StevenK> That was the most recent one I could find, I can re-grep on neem if you wish
[02:06] <wgrant> Because it's not there any more
[02:06] <StevenK> Oh, sigh
[02:06] <StevenK> I even mentioned it in a bug
[02:07] <StevenK> Yeah, 2012-09-10 has been deleted
[02:08] <lifeless> it shouldn't have pruned then !
[02:08] <StevenK> Well, it did
[02:08] <lifeless> ugh
[02:08] <StevenK> I bloody hope it has turned up again, because that was the only OOPS we had
[02:08] <wgrant> Wait
[02:08] <wgrant> -10?
[02:09] <wgrant> That's not yet 5 days old
[02:09] <wgrant> Is the pruning threshold like 2 days now or something>?
[02:09] <StevenK> drwxr-xr-x 2 oops_tools oops_tools 2.1M Sep 11 10:28 2012-09-06
[02:09] <StevenK> drwxr-xr-x 2 oops_tools oops_tools 704K Sep 14 02:07 2012-09-11
[02:10] <lifeless> didn't we lower it when we had that huge batched?
[02:10] <lifeless> may not have been re-raised
[02:10] <StevenK> In either case, I linked it to a bug and it pruned it
[02:11] <wgrant> StevenK: You may have linked it while the prune was happening
[02:11] <wgrant> It can take a while
[02:11] <StevenK> It worked this morning while I was on the call
[02:13] <wgrant> Mysterious
[02:13] <wgrant> prune.log is modified at 11:41 today
[02:13] <wgrant> The last line in the log:
[02:13] <wgrant> INFO:root:Querying OOPS references on auditorclient from 2012-09-10 01:40:01.689000+00:00 to 2012-09-11 01:40:02.192021+00:00
[02:13] <wgrant> I wonder if it's pruning to -3 days
[02:14] <wgrant> And it also only looks at references up to -3 days
[02:14] <wgrant> Hee hee
[02:14] <wgrant> Yes
[02:14] <wgrant> That explains a bit
[02:14]  * StevenK can't convince his browser to show him the cached copy either
[02:15] <wgrant>     prune_until = datetime.datetime.now(utc) - one_week
[02:15] <wgrant>     references = finder.find_oops_references(
[02:15] <wgrant>         prune_from, prune_until, options.project, options.projectgroup)
[02:15] <wgrant> (I suspect one_week may be cowboyed)
[02:16] <lifeless> right, it only needs to look at references made after the oops was created
[02:16] <StevenK> Right, it pruned the only ArchiveSubscriptionError OOPS we had.
[02:16] <StevenK> Which is just awesome.
[02:16] <wgrant> lifeless: Right, but it also only looks at references made until the pruning threshold
[02:16] <wgrant> lifeless: The start bound is correct
[02:16] <wgrant> The end bound shouldn't exist
[02:17] <lifeless> wgrant: oh, should be now() ?
[02:17] <wgrant> Right
[02:17] <lifeless> wgrant: probably a bad cowboy
[02:17] <lifeless> hloeung: yo
[02:17] <wgrant> lifeless: No, it's in trunk
[02:17] <wgrant> My paste was from trunk
[02:17] <lifeless> hloeung: unping
[02:17] <lifeless> wgrant: dow; can has fix ?
[02:18] <wgrant> Confirmed that neem has one_week cowboyed to be days=3
[02:18] <wgrant> So this explains it
[02:18] <StevenK> I wonder how many other OOPSes have been pruned that were referenced
[02:19] <wgrant> Not too many
[02:19] <wgrant> Anything referenced within 24h should be safe
[02:30] <StevenK> So I'm guessing I should find something else to work on
[02:31] <StevenK> Since we don't understand what caused it, and the only OOPS we had has been deleted.
[02:36] <jtv> Hi StevenK, wgrant — can I bounce a problem & solution for format-imports off you?
[02:36] <StevenK> format-imports doesn't have problems, only bad input
[02:37] <wgrant> Sure
[02:38] <jtv> StevenK: then try "from . import foo"  :)
[02:38] <jtv> Blows up.
[02:38] <StevenK> Use imp for that
[02:38] <jtv> imp?
[02:39] <StevenK> http://docs.python.org/library/imp.html#module-imp
[02:40] <wgrant> Why use imp for that?
[02:40] <jtv> What William said.
[02:41] <StevenK> jtv: Django uses imp in it's manage.py
[02:41] <jtv> Not a reason in itself.  It also doesn't believe in database transactions.  :)
[02:41] <lifeless> well
[02:41] <lifeless> so . is definitely local
[02:41] <lifeless> format-imports just needs to be taught
[02:42] <jtv> That's what I just did.
[02:42] <jtv> In a nutshell: the first level of an import is either an identifier, or a series of dots.
[02:42] <jtv> (Previously: just an identifier)
[02:42] <jtv> And I list "." as one of the known local packages.
[02:43] <jtv> Still leaves ".." wide open, but watch me not care.
[02:45] <jtv> Any objections to that solution?  I'm implementing it in MAAS, but since the script was copied from LP, I'd like to share the fix.
[02:46] <lifeless> seems fine, I'd like that.
[02:46] <bigjools> StevenK: "its"
[02:46] <lifeless> Would MAAS use the script if it was in lp-dev-utils ?
[02:46] <lifeless> or would it still want a local copy ?
[02:47] <jtv> Thank you bigjools :)
[02:47] <bigjools> jtv: I knew you'd be itching after reading it too
[02:47] <jtv> I was so proud of suppressing it.
[02:47] <bigjools> haha
[02:47] <jtv> lifeless: lp-dev-utils sounds like a better place.
[02:48] <lifeless> jtv: is there any delta between the scripts ?
[02:48] <jtv> But maybe that's a separate issue; this is really just a distraction for me so I'm very much looking for a quick fix.
[02:48]  * jtv checks
[02:48] <lifeless> jtv: if so, could it be made into data - a config file or something ?
[02:48] <lifeless> jtv: yes, it is a separate issue.
[02:49] <jtv> There are several isolated changes.  :(
[02:50] <jtv> Changes the MAAS version makes compared to the LP version: http://paste.ubuntu.com/1203983/
[02:51] <jtv> One of those is a typo fix in LP; the rest looks like modernizations in the maas version.
[03:22] <mwhudson> hm, where has Y.lazr.activator.Activator gone
[03:23] <lifeless> lazr is gone gone gone
[03:23] <mwhudson> yeah i saw that commit
[03:24] <mwhudson> it broke my greasemonkey work item editor :)
[03:24] <mwhudson> lp.ui.activator
[05:12] <StevenK> wgrant: Re: bug 966205, do you think it's sensible to delete all logintoken's on merge?
[05:13] <wgrant> Bug #966205
[05:13] <wgrant> Oh right
[05:13] <wgrant> That one
[05:13] <StevenK> Private
[05:14] <wgrant> I'd just delete them all, yeah
[05:22] <lifeless> purple, I have to run, C stuff; perhaps one of you could help #newbie in #bzr
[05:24]  * StevenK tries to find the person merge tests
[05:26] <StevenK> wgrant: https://pastebin.canonical.com/74532/
[05:35] <wgrant> StevenK: There's no action there
[05:36] <StevenK> I thought it POST'd to the same URL
[05:37] <wgrant> Right
[05:37] <wgrant> But I see no POST to the same URL
[05:39] <StevenK> Odd, since there was POST, the OOPS had it.
[05:39] <wgrant> What did you grep for?
[05:40] <StevenK> ~thomas-guest/+archivesubscriptions/39008/+index
[05:40] <wgrant> Why +index?
[05:41] <wgrant> That wouldn't normally be there
[05:41] <StevenK> It obviously was, there was three matches
[05:41] <wgrant> None of which we were looking for
[05:41] <wgrant> So I'd drop the trailing /+index
[05:55] <StevenK> wallyworld__, wgrant: https://code.launchpad.net/~stevenk/launchpad/remove-logintokens-on-merge/+merge/124338
[05:56]  * wallyworld__ sad, conflict ahead
[05:57] <StevenK> wallyworld__: Oh?
[05:58] <wallyworld__> person-merge.txt - it's being nuked for new unit tests
[05:58] <wallyworld__> for a bug i'm ficing
[05:58] <lifeless> yay django
[05:58] <lifeless>   File "/home/robertc/source/launchpad/oops-tools/working/eggs/Django-1.4-py2.6.egg/django/contrib/auth/management/__init__.py", line 85, in get_system_username
[05:58] <lifeless>     return getpass.getuser().decode(locale.getdefaultlocale()[1])
[05:58] <lifeless> TypeError: decode() argument 1 must be string, not None
[05:58] <StevenK> wallyworld__: That's awesome, and sorry
[05:58] <wallyworld__> StevenK: no problem :-)
[05:58] <wallyworld__> no need to apologies
[05:58] <wallyworld__> bah, can't type
[05:59] <StevenK> wallyworld__: You aren't fixing the linked bug?
[06:00] <wallyworld__> no, i checked :-)
[06:00] <wallyworld__> i'm fixing 1019975
[06:00] <wallyworld__> bug 1019975
[06:00] <_mup_> Bug #1019975: AttributeError: 'NoneType' object has no attribute 'displayname'  requesting people merge <merge-deactivate> <oops> <regression> <Launchpad itself:In Progress by wallyworld> < https://launchpad.net/bugs/1019975 >
[06:01] <wallyworld__> fix is easy, but adding a test is a pain until i convert the doctest
[06:03] <StevenK> wgrant: 3 out of 4 appserver logs grepped, waiting for gac
[06:12] <lifeless> grah
[06:13] <lifeless> wgrant: in your lxc travels, did you see lxc choosing POSIX as the locale, no matter what /etc/environment and /etc/default/locale say ?
[06:17] <wgrant> StevenK: Great
[06:17] <wgrant> lifeless: I don't believe so
[06:17] <wgrant> By POSIX you mean C?
[06:17] <lifeless> no
[06:18] <lifeless> robertc@lucid-test-lp:~$ locale
[06:18] <lifeless> LANG=
[06:18] <lifeless> LANGUAGE=
[06:18] <lifeless> LC_CTYPE="POSIX"
[06:18] <lifeless> ...
[06:18] <lifeless> LC_IDENTIFICATION="POSIX"
[06:18] <lifeless> LC_ALL=
[06:18] <wgrant> Well that's odd
[06:18] <lifeless> I have en_AU etc available
[06:18] <lifeless> language pack en base installed
[06:18] <wgrant> I could understand C
[06:18] <wgrant> But POSIX is a bit odd
[06:18] <StevenK> lifeless: Not en_NZ? :-)
[06:19] <lifeless> of course, my environment outside of LXC is latin and klingon
[06:19] <lifeless> StevenK: habits.
[06:19] <StevenK> lifeless: tlh_LA ? :-)
[06:19] <lifeless> robertc@lifeless-64:~$ locale
[06:19] <lifeless> LANG=en_AU.UTF-8
[06:19] <lifeless> LANGUAGE=la_AU:tlh_GB:tlh:en
[06:20] <wgrant> Oh
[06:21] <lifeless> $ LANGUAGE="en_US:en" LANG=en_US.UTF-8 ssh -A -X lucid-test-lp.local
[06:21] <lifeless> Last login: Fri Sep 14 06:21:22 2012 from lifeless-64.local
[06:21] <lifeless> robertc@lucid-test-lp:~$ locale
[06:21] <lifeless> LANG=
[06:21] <lifeless> LANGUAGE=
[06:22] <lifeless> LC_CTYPE="POSIX"
[06:23] <wgrant> lifeless: You haven't changed sshd's AcceptEnv default or something?
[06:23] <lifeless> hah
[06:23] <lifeless> AcceptEnv LANG LC_*
[06:24] <lifeless> *I* did not set that.
[06:24] <wgrant> That's normal
[06:24] <wgrant> The default
[06:24] <StevenK> ... Why is my LANG en_US.UTF-8 ? :-(
[06:25] <wgrant> StevenK: Because you're terrible
[06:25] <wgrant> Mine is correct :)
[06:25] <StevenK> I'm trying to remember where it is set.
[06:26] <wgrant> /etc/default/locale, usually
[06:26] <StevenK> steven@undermined:~% cat /etc/default/locale
[06:26] <StevenK> LANG="en_AU.UTF-8"
[06:26] <StevenK> steven@undermined:~% echo $LANG
[06:26] <StevenK> en_US.UTF-8
[06:26] <lifeless> thats the same kind of FUNK I'm seeing
[06:32] <lifeless> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=330500
[06:32] <lifeless> is looking similar
[06:32] <wgrant> Yeah, but that one's from 2005
[06:32] <wgrant> If it's the one I just looked at
[06:32] <wgrant> And SSH should be overriding that
[06:34] <lifeless> ssh was present in that bug
[06:34] <lifeless> and message 65 says it still happens
[06:34] <wgrant> Hm, true
[06:45] <StevenK> wgrant: https://pastebin.canonical.com/74533/
[06:48] <wgrant> StevenK: Right, that makes a bit more sense
[06:49] <wgrant> Though the +index bits are suspiciously missing now
[06:52] <lifeless> oh charming
[06:52] <lifeless> for some reason I've ended up with django 1.4 in my oops-tools setup
[06:52] <lifeless> rather than 1.3 which I think it was running
[06:53] <StevenK> wgrant: So it doesn't look like a race
[06:53] <lifeless> ImproperlyConfigured at /oops/
[06:53] <lifeless> Error importing template source loader django.template.loaders.filesystem.load_template_source: "'module' object has no attribute 'load_template_source'"
[06:57] <wgrant> StevenK: Right, as expected
[06:58] <wgrant> I knew it couldn't be, but evidence is good :)
[06:59] <StevenK> wgrant: So then I should be able to trigger it with a test case. :-(
[06:59] <wgrant> StevenK: Yes, if it's correctly set up
[07:02] <StevenK> wgrant: But I still don't get it -- both methods back onto IArchiveAuthTokenSet.getActiveTokenForArchiveAndPerson()
[07:08] <StevenK> Hmmm
[07:10] <StevenK> I wonder if there is a value that date_deactivated can be set to that isn't None
[07:20] <czajkowski> morning
[09:02] <adeuring> good morning
[09:58] <dpm> hi adeuring, would you have time to review https://code.launchpad.net/~dpm/launchpad/translations-exporter/+merge/124373 ? Thanks!
[09:58] <adeuring> dpm: sure, I'll look
[09:59] <dpm> excellent, thanks!
[10:56] <StevenK> dpm: You can validate the distroseries by using getUtility(IDistributionSet).getByNameOrVersion()
[10:56] <StevenK> I think.
[10:56] <StevenK> I'm a little fuzzy on the details
[10:56] <dpm> StevenK, ah, great, will look into that, thanks for the feedback!
[10:57] <StevenK> Sorry, getUtility(IDistroSeriesSet).findByName()
[10:57] <StevenK> The first one is for finding distributions
[10:58] <dpm> ok
[11:17] <mpt> hrm
[11:17] <mpt> I know there's a bug report about "Can't search for the absence of a bug tag", but I can't find it
[11:18] <mpt> It's not in <https://bugs.launchpad.net/launchpad/+bugs?field.tag=bugtag>
[11:20] <mpt> oh, it's bug 81575, Fix Released
[11:20] <_mup_> Bug #81575: no way to search for absence of a tag <bugtag> <lp-bugs> <oem-services> <ubuntu-qa> <Launchpad itself:Fix Released by allenap> < https://launchpad.net/bugs/81575 >
[11:20]  * mpt scours the search form again
[11:21] <mpt> aha, "To search for the absence of a particular bug tag, place a minus sign before its name: e.g. -test"
[11:36] <adeuring> dpm: comment sent. Ping me if you have any questions
[11:42] <adeuring> dpm: LP "censored" much of the replay. Use the "download full text" link
[11:43] <dpm> thanks adeuring. I can't see any more text in the downloaded text file than the textbox in LP, though.
[11:44] <adeuring> dpm: weird... But the mail you'll get sould be complete ;)
[11:44] <dpm> adeuring, hm, the mail has exactly the same text as the textbox and the downloaded link, nothing additional
[11:46] <adeuring> dpm: maybe I am too stupid to find all of my own comments in the web browser. WHat I don't see in the web browser is your Python code with some comments from me.
[11:46] <dpm> adeuring, ah, wait, I was missing the inline comments in the diff, sorry, all good, now. Sorry...
[11:46] <adeuring> np ;)
[11:47] <dpm> adeuring, thanks a lot for the detailed review. Who should I best talk to to go past the "thou shalt not increase the LOC count for.." step?
[11:49] <adeuring> dpm:  get some support first (the admins would probably appreciate a cron job, i assume), then talk with flacoste
[11:50] <czajkowski> dpm: do you know who the team leads are?
[11:51] <czajkowski> dpm: bigjools, sinzui gary_poster|away jam gmb
[11:52] <cjwatson> czajkowski,dpm: https://dev.launchpad.net/PolicyAndProcess/MaintenanceCosts says "needs a waiver from the LP Project lead or CDO Technical architect "
[11:52] <cjwatson> i.e. Francis or Robert
[11:52] <czajkowski> cjwatson: nods
[11:54] <lifeless> I'll grant a waiver
[11:54] <lifeless> this code already exists in the wrong place
[11:55] <lifeless> its not adding debt to move it into LP
[11:55] <lifeless> dpm: ^
[11:55] <lifeless> its reducing debt by getting it into the right place.
[11:55] <czajkowski> :)
[11:55] <dpm> thanks lifeless
[11:56] <rick_h__> dammit, buildbot is starting to get on my last nerves.
[12:09] <rick_h__> ok, so how did rev 15954 land when it's got a broken test in it I hit in both of my ec2 test runs? /me is so confused
[12:12] <rick_h__> sinzui: it looks like the doctest cleanup in https://code.launchpad.net/~sinzui/launchpad/mailman-email-addresses/+merge/124273 breaks the doctest because it removes list_four but there's another test using it. Shold that bit just be reinstated ok?
[12:13] <sinzui> damn
[12:13] <sinzui> yes
[12:13] <sinzui> I was going to rewrite that as unittests to day too
[12:13] <sinzui> oh well
[12:14] <rick_h__> how could the change have landed with a broken doctest in there though?
[12:17] <rick_h__> sinzui: ok, added it back in and test passes, going to submit it as a testfix
[12:18] <sinzui> You are a life saver
[12:33] <cjohnston> It looks like LP has changed where it stores text for some pages now, any idea where the text for goo.gl/O4CQ4 might be located now
[12:33] <cjohnston> ?
[12:38] <czajkowski> cjohnston: rather than starting mid sentence, perhaps explainign what you are doing and what is wrong
[12:39] <cjwatson> cjohnston: lib/lp/blueprints/interfaces/specificationsubscription.py
[12:39] <cjohnston> Trying to change the text, it's not there.. Based on the conversation I had on the mailing list in the past
[12:39] <cjwatson> (I grepped for 'Participation essential' and it was the first of a small number of hits)
[12:43] <cjohnston> thanks cjwatson.. I guess grepping half the sentence was what got me. :-/
[12:48] <rick_h__> sinzui: sorry, but I evidently fail. I've tried to submit this with pqm-submit and lp-land and not getting any email/pqm action I can see
[12:48] <rick_h__> sinzui: can you see if you can push https://code.launchpad.net/~rharding/launchpad/testfix_message_holds/+merge/124405 through lp-land as testfix please?
[12:51] <sinzui> okay
[12:51]  * rick_h__ is about to start tossing things out windows gah!
[12:52] <sinzui> rick_h_, I think I have a note about the obscure bzr pqm syntax to submit other peoples branches.
[12:53] <rick_h__> I had thought that  bzr lp-land --testfix --no-qa https://code.launchpad.net/~rharding/launchpad/testfix_message_holds/+merge/124405
[12:53] <rick_h__> would do the thing
[12:53] <rick_h__> but no success or fail email so I'm not even sure I guess that it's getting there
[12:53] <sinzui> rick_h_ try this
[12:54] <sinzui> bzr pqm-submit -m "[testfix][r=sinzui] Revert doctest."
[12:55]  * sinzui is watching https://pqm.launchpad.net/ for old-time sake
[12:56] <sinzui> pqm saw it
[12:57] <sinzui> That it. Today I am taking a torch and pitchfork and raising an angry mob on mailing list doc tests
[13:02] <rick_h__> yay the pqm gods have accepted my offering
[13:02] <nigelb> What sacrifice did you offer? A whale? ;)
[13:03] <sinzui> :)
[13:03] <rick_h__> 10 pqm-submits and a "@$#@$@ you"
[13:03] <nigelb> lol
[13:15] <abentley> adeuring: Here is an example where the web UI cannot protect you from entering disallowed values: https://blueprints.qastaging.launchpad.net/specs/+new
[13:17] <adeuring> abentley: do you mean that "embargoed" might be undesired/invalid? Or that somebody crafts the POST request manually to send USERDATA or whatever else?
[13:18] <abentley> adeuring: I mean that "embargoed" may be undesired/invalid.
[13:18] <adeuring> abentley: anyway, transititonToInformationType() should check that the new value is valid
[13:18] <adeuring> abentley: ok, if EMBAGOED is undesired, we should not present it to the user
[13:19] <abentley> adeuring: We don't know that it's undesired at the time we present it to the user.  Look at the form.  One of the inputs is "target", which is the project or distro.
[13:20] <abentley> adeuring: Where we know it's undesired, we hide it, of course.  This is an example where we cannot do that.
[13:20] <abentley> adeuring: (target is listed as "For: The project for which this proposal is being made."
[13:21] <adeuring> abentley: ah, sure. But we can (1) add a a warning to "Only shared with users permitted to see embargoed information. " that this might not work, and (b) if the value is selected but not usable, we should show an error.
[13:21] <abentley> adeuring: My point is that we are currently showing an error-- an OOPS.
[13:22] <adeuring> abentley: sure, that's bad. But getting undesired data into the DB is bad too
[13:24] <abentley> adeuring: Right, but an assertion due to a missing AccessPolicy is the wrong way to defend against that.
[13:25] <adeuring> abentley: the other artifacts raise a dedicated exception
[13:25] <adeuring> we can do that too
[13:25] <adeuring> for spec
[13:27] <abentley> adeuring: When deryk's code lands, we'll have that.  Until then, I don't know if I can QA my code.
[13:27] <adeuring> abentley: so what should we do?
[13:28] <abentley> adeuring: There's no way to add an access policy on qastaging, right?
[13:28] <adeuring> I don't know
[13:29] <adeuring> My guess is: create a product which uses EMBAGOED for bugs too
[13:29] <abentley> adeuring: Oh, yes, that might work.
[13:31] <deryck> rick_h_96, rick_h__ rick who?  ping for standup.
[13:31] <rick_h__> deryck: I'm in there?
[13:32] <rick_h__> or not...
[14:20] <abentley> deryck, adeuring: private & embargoed blueprints break the front page: https://blueprints.qastaging.launchpad.net/
[14:21] <deryck> abentley, oh, ouch.  that's a bad one.
[14:21] <abentley> deryck: Blocker for the beta?
[14:22] <adeuring> seems that we need to filter properly...
[14:22] <deryck> abentley, yes, we should fix that first.  but let's make that fix the priority.
[14:22] <jcsackett> sinzui: i am looking at bug 808952 and wondering, is there any reason we haven't exposed all Message types on the API?
[14:22] <_mup_> Bug #808952: NoCanonicalUrl using api to fetch bug comments <api> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/808952 >
[14:23] <deryck> abentley, do you want that one next, or shall I?
[14:23] <abentley> deryck: Could you?  I'm still on QA.
[14:23] <deryck> abentley, I absolutely can.  I likewise am not free yet.  Still fixing a couple tests.  But when I get free I can take it next.
[14:24] <sinzui> jcsackett, we only expose those that are needed. I think this case is differnt though
[14:25] <sinzui> jcsackett, Our views can show objects without a canonical url, but the api requires that we define one, and that Lp provide the objects consistently to make the url
[14:26] <jcsackett> so you think we should update the API to handle situations more like our views?
[14:27] <sinzui> no
[14:27] <sinzui> I am saying that comments do not match what we put in the zcml
[14:27] <sinzui>         <browser:url
[14:27] <sinzui>             for="lp.bugs.interfaces.bugmessage.IBugComment"
[14:27] <sinzui>             path_expression="string:comments/${index}"
[14:27] <sinzui>             attribute_to_parent="bugtask"
[14:27] <sinzui>             rootsite="bugs"/>
[14:29] <sinzui> jcsackett, I think bug 210821 might be easier to fix. We know the portlet that shows the active project. I think we can walk backwards to find the code that put there
[14:29] <_mup_> Bug #210821: bug tracker list shows inactive projects <404> <bugwatch> <lp-bugs> <qa-ok> <trivial> <Launchpad itself:Triaged> < https://launchpad.net/bugs/210821 >
[14:30] <jcsackett> sinzui: fair.
[15:00] <abentley> deryck: I'm done QA for now.  Shall I work on the front page query so you can work on the blog post?
[15:01] <deryck> abentley, if you have the bandwidth, I would appreciate that!  I'm still fighting trying to figure out why a test is failing too.
[15:01] <abentley> deryck: Okay.  I'm also filing a bug and adding a card.
[15:02] <deryck> abentley, I added a red card, but didn't file a bug yet.
[15:02] <abentley> deryck: ack
[15:04] <abentley> deryck: What do you think about hiding Proprietary/Embargoed from the front page entirely, even if you have permission to see them?  Would be a simpler fix.
[15:05] <deryck> abentley, I was going to take that approach.  simple and naive for now.
[15:05] <abentley> deryck: Cool.
[15:05] <deryck> abentley, other lists will need more care, but the top-level page can just be public stuff.
[15:05] <deryck> abentley, also we're okay about other lists breaking, it's how we've been releasing this other stuff, and we can fix those later.....
[15:06] <deryck> abentley, this one is a beta blocker because it would affect everyone.
[15:06] <abentley> deryck: Agreed.
[15:06] <deryck> cool
[15:06] <deryck> abentley, while we're chatting... :)  I'd appreciate your second eyes on this test:  http://pastebin.ubuntu.com/1204931/
[15:07] <deryck> abentley, it's breaking for me on line 5.  the match_it is in setUp and looking for field.information_type.....
[15:07] <deryck> abentley, I have no idea what I changed to break it, and looking in the browser manually I see that field.
[15:07] <deryck> abentley, am I understanding what it's trying to test?  Something else I should look at?
[15:08] <abentley> deryck: I thought match_it was for the information type in the privacy banner?  And the privacy banner isn't displayed for PUBLIC.
[15:08] <deryck> abentley, ah, ok.  So maybe a bad test then.
[15:09] <deryck> abentley, the test class is TestNewSpecificationInformationType
[15:09] <deryck> and then goes through each target in a small test like this.
[15:11] <abentley> deryck: No, I was confused.  match_it matches the field, not the banner text.
[15:12] <abentley> deryck: Are you sure the field is displayed?  For a project with only PUBLIC blueprints, it wouldn't be.
[15:13] <deryck> abentley, ah, ok.  I looked wrong.  I had a test project which was proprietary.  Sorry.  I see now....
[15:13] <deryck> I can fix it to test that it's Not match.
[15:14] <abentley> deryck: No, I think the test needs to change so that the Specification policy defaults to public but permits proprietary.
[15:15] <deryck> abentley, ah, gotchas.  ok.
[15:16] <abentley> deryck: And in a later branch, we should add tests to ensure that the rest of the defaults work.  For the "Use sharing policy default for creating specs" card.
[15:17] <deryck> abentley, agreed.  sounds good.
[15:18] <deryck> abentley, thanks for the help!  I can move forward again, yay! :)
[15:19] <abentley> deryck: np.
[15:20] <abentley> deryck: I'm not sure I'll be able to QA this bugfix because the qastaging front page was already timing out.
[15:21] <deryck> abentley, ok.  I guess test as good locally as possible.
[15:21] <deryck> abentley, well, if it times out again though, you can consider it fixed. :)
[15:22] <abentley> deryck: Yes.  Theoretically, I could have added unacceptable delay to the pageload, though.
[15:22] <deryck> oh right
[15:36] <abentley> rick_h__: Does this error look familiar? http://pastebin.ubuntu.com/1204999/
[15:43] <rick_h__> abentley: looking
[15:43] <rick_h__> abentley: yea, that's the testfix from this morning
[15:44] <abentley> rick_h_: So merge and resubmit?
[15:44] <rick_h__> abentley: rgr
[15:44] <abentley> rick_h_: Actually, since that's the only failing test I'm gonna do a straight lp-land once I'm sure it's fixed.
[15:45] <rick_h__> abentley: yea sounds good. It's running through buildout now so should be clear by EOD
[16:02]  * nigelb wonders why gmail thinks mail from francis is spam :P
[17:00] <rick_h__> jcsackett: ping, got a sec?
[17:04] <jcsackett> rick_h__: i think you just pinged me, but could be stale message as my bouncer just reconnected.
[17:39] <abentley> bac: are you OCR today?
[17:41] <abentley> deryck: Could you please review https://code.launchpad.net/~abentley/launchpad/fix-blueprints-home-with-proprietary/+merge/124485 ?
[17:41] <deryck> abentley, sure.
[17:44] <deryck> abentley, looks good, thanks.  r=me.
[18:34] <abentley> deryck: I've determined that with my fix, the search results and "completed" list also behave properly.
[18:34] <abentley> deryck: However, "meetings" are broken by PROPRIETARY specs.  Bug 1051029
[18:34] <_mup_> Bug #1051029: PROPRIETARY specifications break meeting listings <Launchpad itself:Triaged> < https://launchpad.net/bugs/1051029 >
[18:48] <deryck> abentley, ok, thanks for checking all that
[18:48] <deryck> abentley, I think we can live with that bug until we can get to it
[18:49] <abentley> deryck: Agreed.
[18:49] <deryck> cool
[18:49] <abentley> deryck: I suspect we're going to have this issue with Product, ProductSeries, Distribution and DistroSeries, too.
[19:55] <abentley> rick_h__: What's the status of lp:~rharding/launchpad/lp_cache_update into lp:launchpad?  I'd like to use json_dump_information_types.
[19:56] <rick_h__> abentley: it should be coming. I got the ec2 success email just a bit ago
[19:57] <abentley> rick_h_: excellent.
[20:03] <rick_h__> deryck: ping
[20:03] <deryck> hi rick_h__.  sup?
[20:03] <rick_h__> deryck: just fyi, I can't find any reason for the js timeout error. jcsackett couldn't replicate it and I ended up tossing it at ec2 agin
[20:03] <jcsackett> rick_h__: that's a weird one.
[20:03] <rick_h__> if you get a chance to look you'd be another set of eyes, but fyi I did get a second look and nothing seems odd to praying to the ec2 gods
[20:04] <rick_h__> just a heads up while I go run away for EOD
[20:05] <deryck> rick_h__, sorry man.  I looked briefly and didn't see anything.  and spent most of the morning fixing my tests.  meant to come back, but switched to other stuff and forgot.
[20:06] <rick_h_droid> understand, not a problem
[20:06] <deryck> heh
[20:07] <deryck> these are not the rick_h's you seek
[20:08] <abentley> rick_h__: It hasn't landed yet, and the PQM queue is empty.  I don't think it's going to land without further effort.
[20:08] <rick_h__> abentley: looking
[20:15] <rick_h__> abentley: ok, wtf. email says sumitted to pqm, I've got nothing from pqm that says it was/wasn't happy
[20:16] <rick_h__> so going to lp-land it and see what we get I guess
[20:22] <rick_h__> is pqm having issues today? This morning it wasn't responding to my lp-land and looks like it's not again
[20:23] <rick_h__> abentley: ok sorry but I've got to get the boy before the babysitter arrives in 30. I do see it in pqm, so will wait to see if it succeeds/fails for some reason
[20:24] <rick_h__> abentley: but ec2 tests pass and dammit I'll get through pqm/buildbot if I've got to fly to london and throttle some hardware
[20:24] <abentley> rick_h__: I've unblocked myself by making your branch a pipe in my pipeline.
[20:25] <abentley> rick_h__: And of course, now it's merged.
[21:12] <sinzui> rick_h_: use the force...
[21:12] <sinzui> bzr pqm-submit -m "..."