[00:10]  * StevenK stabs the uploadprocessor tests
[00:11] <StevenK> Fill up a bunch of changes files with the same signature and different data and then a new test fails GPG verification
[00:16] <lifeless> can has review ?
[00:16] <lifeless> https://code.launchpad.net/~lifeless/pybars/bug-1040096/+merge/125874
[00:19] <StevenK> And back to fighting with gpg
[00:27] <StevenK> wgrant: The current files specify a DSA key ID that isn't in the keyring
[00:28] <wgrant> StevenK: Which file?
[00:28] <StevenK> wgrant: steven@undermined:.../suite/bar_1.0-4% GNUPGHOME=../.. gpg --verify < bar_1.0-4_source.changes
[00:29] <StevenK> gpg: WARNING: unsafe permissions on homedir `../..'
[00:29] <StevenK> gpg: Signature made Thu 25 Jan 2007 07:02:00 AM EST using DSA key ID 6C64A8C5
[00:31] <wgrant> StevenK: lib/lp/testing/gpgkeys/data/foo.bar@canonical.com.sec
[00:32] <wgrant> sec  1024D/6C64A8C5 2005-04-13 Foo Bar <foo.bar@canonical.com>
[00:33] <wgrant> (passphrase is 'test')
[00:39] <StevenK> wgrant: Ah, thanks.
[00:40] <StevenK> wgrant: GNUPGHOME=. gpg --import < <.sec> and then --clearsign worked
[00:44] <StevenK> wgrant: Ah ha, actual    = 'Unhandled exception processing upload: too many values to unpack'
[00:44] <wgrant> Excellent
[00:49] <StevenK> Haha, yeah, fileline.strip().split() -> ValueError
[00:49] <wgrant> As you'd expect :)
[00:57] <StevenK>  lp.archiveuploader.tests.test_uploadprocessor.TestUploadProcessor.testUploadWithMalformedSectionIsRejected
[00:57] <StevenK>   Ran 1 tests with 0 failures and 0 errors in 2.382 seconds.
[00:59] <wgrant> Do you reject it directly, or just do a split(' ', 4) and let it fail when the filename is malformed?
[01:00] <wgrant> split(' ', 3) actually, I guess
[01:00] <StevenK> I catch the ValueError and yield UploadError
[01:17] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/deal-with-badly-formed-section/+merge/125908
[01:18] <StevenK> wallyworld_: I'd ask you to review that branch, but you'd see 'lib/lp/archiveuploader' in the diff and run screaming. :-)
[01:25] <wgrant> StevenK: Looking
[01:46] <wallyworld_> StevenK: sorry, was buying lunch, otherwise would have looked
[01:47] <StevenK> wallyworld_: It's all good, I was only teasing you
[01:47] <StevenK> I should go and buy part of my lunch
[01:47] <StevenK> Otherwise I'll be having toasted turkey sandwiches with no bread
[02:24] <StevenK> wgrant: Oh haha. I bet I know what is causing bug 899123
[02:24] <_mup_> Bug #899123: IntegrityError raised deleting a series <bugs> <milestones> <oops> <series> <Launchpad itself:Triaged> < https://launchpad.net/bugs/899123 >
[02:28] <wgrant> StevenK: Hm?
[02:28] <wgrant> StevenK: It'
[02:28] <wgrant> s pretty clear what the problem is.
[02:29] <StevenK> wgrant: Oh? My thought is bugtasks that self.user can't see, so don't get returned so the milestone can be cleared
[02:30] <wgrant> StevenK: Exactly
[02:30] <wgrant> The product the series is on gives it away
[02:31] <StevenK> Oh, I read the code to deduce that
[02:31] <StevenK> The fact that the code is in lib/lp/registry/browser/__init__.py makes me sad
[03:12] <mwhudson> wgrant: just because i know you'll understand my pain
[03:12] <mwhudson>  Aggregate  (cost=1996.76..1996.77 rows=1 width=0) (actual time=449033.137..449033.137 rows=1 loops=1)
[03:12] <mwhudson> i suspect this estimate of being slightly inaccurate
[03:12] <wgrant> Heh
[03:13] <wgrant> Django amuses me
[03:13] <wgrant> The schema style it encourages introduces a lot of potential planning issues
[03:17] <mwhudson> fortunately i have already rewritten this query
[03:28] <lifeless> /win 94
[03:49] <wallyworld_> StevenK: wgrant: fancy a quickie? https://code.launchpad.net/~wallyworld/launchpad/bug-sharing-policy-weirdness-1055250/+merge/125916
[03:50] <StevenK> With you?
[03:50] <wallyworld_> yes!
[03:51] <StevenK> wallyworld_: You can't use setB{ug,ranch}SharingPolicy ?
[03:51] <wallyworld_> where? test?
[03:51] <StevenK> Yeah, in the tests
[03:52] <wallyworld_> using setXXX() in the tests errors because it tries to create another commercial subscription and do other things we don't care about
[03:52] <StevenK> Create? I thought it checked them
[03:53] <wallyworld_> creating a project with private sharing policy creates a subscription at the same time
[03:53] <wallyworld_> in the factory
[03:54] <wallyworld_> i guess setXXX() should behave properly if there's already a subscription
[03:54] <StevenK> wallyworld_: setB{ug,ranch}SharingPolicy will work fine if you're tossing in FORBIDDEN, read the code.
[03:55] <wallyworld_> yes, i wonder why i got an error then, i'll retry
[03:57] <StevenK> wgrant: So would user=ILaunchpadCelebrites.admin in RegistryDeleteViewMixin._getBugtasks cause me to get murdered?
[03:58] <wallyworld_> StevenK: i must have been on crack or something. works. changes pushed
[04:00] <wgrant> StevenK: I think so, yeah
[04:00] <StevenK> wgrant: :-(
[04:00] <wgrant> If you have no other choice, then maybe
[04:00] <StevenK> I think my other choice is store.find(BugTask, BugTask.milestone == ...) but conjoined masters foul that up
[04:01] <wgrant> StevenK: Or to give bugtasksearch an option to not do privacy checks
[04:02] <StevenK> wgrant: Which I've not seen in my searching.
[04:03] <wgrant> Right, you probably need to add such a feature
[04:08] <lifeless> we probably should upgrade the oops-tools on lp-oops
[04:08] <lifeless> or give it a quiet death
[04:10] <StevenK> If we can import the oops in lp-oops into oops, then we can shoot it
[04:10] <lifeless> or we could just let them go away
[04:11] <StevenK> Sure, let's make a bunch of criticals more useless, what could possibly go wrong.
[04:15] <lifeless> wel
[04:15] <lifeless> how often do you reference them
[04:15] <lifeless> and how often have they stopped happening entirely?
[04:16] <StevenK> lifeless: There are a large number of critical bugs that include an OOPS and very little else. Some of these OOPSes can not be found at all, and others are only on lp-oops.
[04:17] <StevenK> This OOPS happened once and hasn't occured for two years and yet we have a Critical open with no useful content.
[04:17] <lifeless> so, close the critical
[04:18] <lifeless> if the critical is an oops or timeout
[04:18] <lifeless> the report will tell us if it happens again
[04:19] <StevenK> lifeless: Bug 893576 is a good example
[04:19] <_mup_> Bug #893576:   AttributeError: 'SourcePackageRecipeRequestDailyBuildView' object has no attribute 'index'  <oops> <recipe> <Launchpad itself:Triaged> < https://launchpad.net/bugs/893576 >
[04:24] <lifeless> StevenK: its on neither server?
[04:24] <wallyworld_> wgrant: StevenK: when a commercial voucher is redeemed, i would expect the bug/branch sharing policies to be set to proprietary automatically rather than requiring the maintainer to go to +sharing to update. from what i can tell, this doesn't happen. do we want to fix?
[04:24] <StevenK> lifeless: Right
[04:25] <wgrant> wallyworld_: Not exactly
[04:25] <wgrant> wallyworld_: The normal use case is that someone creates a project as Other/Proprietary
[04:25] <StevenK> lifeless: I'm struggling to find a bug that has an OOPS that is on lp-oops but not oops, but they do exist, and their content level is about the same as that bug.
[04:25] <wgrant> So they automatically get Proprietary
[04:26] <wallyworld_> wgrant: sure, but when the subscription expires and then extended
[04:26] <wallyworld_> is the case i'm talking sbout
[04:26] <lifeless> StevenK: so, I would grep for the error
[04:26] <wallyworld_> we don't reset the policies from forbidden (or public) back to proprietary
[04:26] <wgrant> wallyworld_: That's really rare and easy for them to fix manually, and we can't do it unambiguously, so probably not
[04:26] <lifeless> e.g.
[04:26] <lifeless> oops-amqp/launchpad/production$ grep SourcePackageRecipeRequestDailyBuildView . -r
[04:27] <lifeless> if its not there, close the bug - its not happening enough to worry about for now
[04:27] <wgrant> The bug is still there
[04:27] <wgrant> And it's trivial to reproduce
[04:27] <wallyworld_> wgrant: but it mirrors the concerns about leaking info. if they extend the subscription, they would rightly expect stuff to be private from then on. but it won't be unless they do something
[04:28] <lifeless> wgrant: thats good then, you can fixup the bug
[04:28] <wgrant> wallyworld_: eg. ubuntuone-servers is Other/Proprietary
[04:28] <wgrant> wallyworld_: But the bugs are usually public
[04:28] <wallyworld_> wgrant: or push a branch
[04:28] <lifeless> wgrant: I'm just saying that we have 2K errors a day, stressing about data for something with an incident rate < 1/2 weeks is not worth doing
[04:28] <wgrant> wallyworld_: Sure, and it'll tell them they need to go to +sharing to fix it
[04:28] <StevenK> wgrant: Then please link a proper OOPS to the bug :_0
[04:28] <lifeless> thats 1 every 2 weeks.
[04:29] <wgrant> StevenK: I have
[04:29] <wgrant> But it's literally as trivial as it can get
[04:29] <wgrant> Just go to the pageid referenced in the OOPS
[04:29] <wallyworld_> wgrant: we are now arguing different sides of the same thing we were discussing last week
[04:29] <wgrant> boom
[04:29] <wgrant> wallyworld_: My argument last week was primarily based on the fact that it is dangerous to leak things
[04:29] <wgrant> This won't leak things
[04:29] <wgrant> It will reject them
[04:29] <wallyworld_> yes it will
[04:29] <StevenK> Oh, let me guess +request-daily-build only wants POST
[04:29] <wallyworld_> if they have changed to public
[04:30] <lifeless> wgrant: that oops wasn't readable
[04:30] <wgrant> wallyworld_: If they set it to Public then they probably want it Public...
[04:30] <lifeless> was it ?
[04:30] <wgrant>  AttributeError: 'SourcePackageRecipeRequestDailyBuildView' object has no attribute 'index'
[04:30] <wgrant> ^^ that is the pageid
[04:30] <wallyworld_> wgrant: they will rightly expect getting s new subscription will make things proproetary sgasin
[04:30] <wgrant> Well, no actual pageid
[04:30] <wgrant> But view name
[04:30] <wgrant> wallyworld_: Why?
[04:30] <wallyworld_> why not? i would
[04:30] <wgrant> They explicitly set it to Public after the subscription expired
[04:31] <wallyworld_> sure, asnd then thry buy another subscription
[04:31] <wallyworld_> so they expect things to go back to provate
[04:31] <wgrant> The reactivation page could hint that it hasn't changed your existing settings
[04:31] <wallyworld_> reasonable expectation
[04:31] <wgrant> It probably should do that, in fact, for when projects initially obtain a commercial subscription
[04:31] <wgrant> But we shouldn't just override what they asked us to do 5 minutes ago
[04:31] <bigjools> WTF: bzr: ERROR: Permission denied: "Cannot create 'add-maas-cluster-packaging'. Only Bazaar branches are allowed."
[04:31] <wgrant> bigjools: Your URL is bad
[04:31] <lifeless> wgrant: no orccurences of that oops on neem prod
[04:32] <wallyworld_> wgrant: hmmm. i wonder if we can tell the difference
[04:32] <wallyworld_> i'll raise a bug and we can discuss on the call
[04:32] <wgrant> wallyworld_: Which difference?
[04:32] <bigjools> wgrant: the branch already exists, I am pushing an update
[04:32] <wallyworld_> tomorrow
[04:32] <wgrant> wallyworld_: In neither case do we want to do it automatically.
[04:32] <wgrant> bigjools: What's the URL?
[04:32] <bigjools> oh wait
[04:32] <wallyworld_> wgrant: i disagree
[04:32] <bigjools> fuck sake
[04:32] <wgrant> wallyworld_: The voucher redemption page should certainly point to +sharing
[04:32] <wgrant> But to change it automatically? That's pretty strange.
[04:32] <wallyworld_> the difference between initially getting a subscription and extending one
[04:33] <wallyworld_> why?
[04:33] <bigjools> wgrant: thanks, pebkac, but you pointed me in the right direction
[04:33] <wgrant> Heh
[04:33] <bigjools> hint: moving branches to a subdir confuses bzr :)
[04:33] <wgrant> wallyworld_: Just because my code is proprietary doesn't meant that my bugs are.
[04:33] <wgrant> For ease of setup we do make that policy decision, once, at project creation
[04:34] <wgrant> We never set the sharing policies ourselves ever again, *except* for setting them to Forbidden when a subscription expires
[04:34] <wgrant> In all other situations we do what the project owner asked.
[04:34] <lifeless> StevenK: so - if the oops doesn't exist on eithe rserver, try wgrants heuristic if you have a view, try grepping for the view or its base r something on neem, and then close.
[04:34] <lifeless> StevenK: diminishing returns after that, we're not doing a NASA.
[04:34] <wallyworld_> wgrant: but we can leak info because the project owner would have rightful expectstion thast extending a subscription would make stuff proprietary again
[04:35] <StevenK> lifeless: But if you want to destroy lp-oops and free up CPU time on carob, go ahead
[04:35] <wgrant> wallyworld_: That's extremely debatable if they're previously explicitly set it to Public.
[04:35] <wallyworld_> not to me
[04:35] <wallyworld_> i would expect it
[04:35] <wgrant> wallyworld_: The commercial subscription documentation has always made clear that it doesn't implicitly turn on privacy features
[04:35] <wallyworld_> since it was only set to public to reset the forbidden
[04:35] <wgrant> It just enables you to configure them
[04:35] <wallyworld_> until they got to buy a new subscription
[04:35] <wgrant> wallyworld_: If your stuff is proprietary and you set your policies to public, then you are really really stupid.
[04:36] <wallyworld_> well, i argued the same thing last week
[04:36] <wgrant> Huh?
[04:36] <wgrant> No, last week you argued it was really really stupid and we could do whatever we wanted just because you ignored an expiry email
[04:36] <wgrant> I argued that we couldn't
[04:36] <wgrant> Now I'm arguing that we can respect Public if they project owner set Public.
[04:36] <wgrant> There's no inconsistency in my position.
[04:37] <wallyworld_> fsvo
[04:37] <wallyworld_> it depends on project owner expectations
[04:37] <wgrant> OK
[04:37] <wgrant> Why would you set it to Public?
[04:37] <wallyworld_> mine would be that buying a subscription makes stuff private
[04:37] <wgrant> That's something that has never been true.
[04:38] <wgrant> And we never state that
[04:38] <wgrant> And it doesn't always make sense.
[04:38] <wgrant> We make it clear that you need to configure your project's privacy options.
[04:38] <wallyworld_> hmm. ok. if it's never been true, then i guess no need to change. but i find it strange we do it that way
[04:38] <wgrant> Now, yes, it was pretty strange that the default for a new proprietary project was for everything to public.
[04:38] <wgrant> And we fixed that default.
[04:39] <wallyworld_> i see extending a subscription in the same light
[04:39] <wgrant> I'm Product Strategy
[04:39] <wgrant> I want to have proprietary bugs and branches on Unity so I can perform my nefarious freedom-hating deeds in secret
[04:39] <wgrant> Now, the project is currently listed as GPL
[04:39]  * ajmitch quotes out of context
[04:40] <wgrant> But I need a commercial subscription, so I buy and activate it
[04:40] <wgrant> Now all the random user bugs and branches are Proprietary because Launchpad changed something without asking me :(
[04:40] <wallyworld_> no, that's exactly what i would expect
[04:40] <wallyworld_> as the owner who bought the subscription
[04:41] <wallyworld_> because i was the one who bought the subscription expecting to hsve private stuff
[04:41] <wgrant> Expecting to have private stuff.
[04:41] <wallyworld_> i guess you and i have different expectstions
[04:41] <wgrant> Not expecting everything to be forced private despite me saying yesterday that it was public by default.
[04:41] <wallyworld_> i would have only said that yesterday because i hadn't decided to buy a subscription yet
[04:41] <wgrant> No
[04:42] <wgrant> Unity wants "Public, can be proprietary" for bugs and branches
[04:42] <wallyworld_> but once i make the decison to prchase, i want proproertary
[04:42] <wallyworld_> and even if i didn't it's best to fail closed as you said last week
[04:43] <wallyworld_> easy to make a few things public again than the other way round
[04:43] <wgrant> If we're unilaterally making a change then we have to fail closed.
[04:43] <wgrant> It's far better for everyone if we can avoid making a change at all
[04:43] <wallyworld_> but buying a subscription is a change
[04:43] <wgrant> In general, users will be less surprised if we do what they say
[04:44] <wgrant> "buying commercial subscription" != "making project private"
[04:44] <wallyworld_> yes, and to me, buying a subscription carries certain expectations
[04:44] <wgrant> Then we need to fix the pages to make it clear that those expectations are false.
[04:44] <StevenK> wallyworld_: So, you have a public product with public bugs and branches.
[04:44] <wallyworld_> yes, i but now i want to buy a subscriotion
[04:44] <StevenK> wallyworld_: You buy a subscription since you want to have some work be private until you're ready to release it.
[04:45] <wallyworld_> yes
[04:45] <StevenK> wallyworld_: So now all the current stuff is all private? Does not make sense.
[04:45] <wallyworld_> no, not the existing stuff
[04:45] <wallyworld_> new stuff
[04:45] <StevenK> You don't want new stuff all private too
[04:45] <wallyworld_> stuff i create *after* i buy the subscription
[04:45] <StevenK> Just selected stuff
[04:46] <StevenK> wallyworld_: Since not all new work is going to be on the private work
[04:46] <wallyworld_> yes, but branches need to be proprietary by default
[04:46] <wgrant> Buying a Launchpad commercial subscription means you get to use proprietary features.
[04:46] <StevenK> No, they don't
[04:46] <wgrant> That's all it does.
[04:47] <StevenK> wallyworld_: So, you put up a bug fix branch for the released work. It should be public, why did LP create it as private?
[04:47] <wallyworld_> better to do that than leak info
[04:47] <wallyworld_> this would be easier using voice, let's discuss tomorrow
[04:47] <StevenK> I agree with wgrant, fwiw
[04:47] <wgrant> Sure
[04:48] <wallyworld_> as a customer, i guess my expectations are different to yours
[04:48] <StevenK> wallyworld_: Ask thumper what he would expect
[04:48] <wgrant> thumper wrote branch privacy
[04:48] <wgrant> He's probably not a good person to ask :)
[04:48] <StevenK> Hahah
[04:49] <StevenK> wgrant: So, IntegrityError: update or delete on table "milestone" violates foreign key constraint "bugtask__product__milestone__fk" on table "bugtask"
[04:49] <StevenK> (From a test I wrote)
[04:49] <wgrant> Great.
[04:49] <StevenK> Now to find the user bit in search_bugs again
[04:49] <wgrant> wallyworld_: We certainly need to rewrite the commercial views, emails and documentation to make clear that you probably want to visit +sharing
[04:49] <wgrant> But I don't think making the change automatically is a good idea
[04:50] <wgrant> And it's certainly not mandatory.
[04:50] <wallyworld_> wgrant: but last week your argued that noone reads emails :-P
[04:50] <wgrant> wallyworld_: My company's commercial subscription admin left the company a month after they activated the commercial subscription :(
[04:50] <wgrant> So the expiration email that Launchpad sent to us 11 months later was gone
[04:51] <StevenK> wallyworld_: As an aside, "Public, can be proprietary" means all new stuff should be private?
[04:51] <wallyworld_> yeah, i know the argument. its the same for this new case too
[04:51] <wallyworld_> StevenK: no
[04:51] <wgrant> But the commercial subscription admin didn't leave 30 seconds after activating the subscription, so they were able to see that email, as well as the page confirming that the subscription was active.
[04:52] <StevenK> wallyworld_: But that's what you said?
[04:53] <StevenK> wallyworld_: You said you buy a subscription which allows you to set "Public, can be proprietary" and therefore since you'd bought a subscription all new stuff should be private
[04:53] <wallyworld_> StevenK: no, i said the sharing policy should be changed from forbidden or public to proprietary when a commercial subscription is purchased or extended
[04:53] <wgrant> There's a difference between failing open by a unilateral action from Launchpad 12 months after the other involved party interacted with us, and failing open because Launchpad respected a user's configuration and then hinted that they might want to verify it immediately after an action that could be misunderstood as automatically changing them.
[04:53] <wallyworld_> sort of. human error and all that. fail open sometimes is still fail open
[04:54] <wgrant> Sure
[04:54] <wallyworld_> StevenK: does it make more sense now with the above clarification?
[04:54] <StevenK> wallyworld_: No, but like you said, let's use voice tomorrow
[04:55] <wallyworld_> ok
[04:55] <StevenK> Failing that, I'm sure wgrant and I can fly to Brisbane to beat sense into you.
[04:55] <wgrant> :)
[04:56] <wallyworld_> i can see both sides of the coin
[04:56] <wgrant> As can I
[04:56] <wgrant> And your side has some good arguments
[04:57] <wgrant> But I think it's less surprising if we do nothing and *say* that we've done nothing.
[04:57] <wgrant> Anyway
[04:57] <wgrant> => mumble tomorrow :)
[04:57] <StevenK> wgrant: So, I should add ignore_privacy=False to BugTaskSearchParams
[04:57] <StevenK> And then use that in _build_query
[04:57] <wgrant> StevenK: Something like that
[05:03] <StevenK> _deleteMilestone runs as the user so if we return bugtasks they can't see, they can't change them either. :-(
[05:04] <StevenK> wgrant: I don't really want to add in rSP either
[05:05] <wgrant> StevenK: It might have to
[05:05] <wgrant> StevenK: Like package uploads closing bugs.
[05:05] <StevenK> Yea
[05:05] <StevenK> Pity
[05:28] <StevenK> wallyworld_, wgrant: https://code.launchpad.net/~stevenk/launchpad/delete-milestone-all-bugs/+merge/125924
[05:29] <wallyworld_> rsp :-(
[05:31] <StevenK> wallyworld_: I have little choice
[05:32] <wallyworld_> StevenK: too bad. i guess rsp is used elsewhere as well where it's unavoidable
[05:32] <StevenK> wallyworld_: I don't like it, but if all references aren't scrubbed, we get an OOPS.
[05:32] <wallyworld_> StevenK: are there likely to be many bugtasks in that loop? should we look to do a bulk delete instead?
[05:32] <StevenK> We can't do a bulk delete
[05:32] <StevenK> We aren't deleting them
[05:33] <StevenK> Well, we are if they're conjoined
[05:33] <wallyworld_> s/delete/update
[05:33] <wgrant> Um
[05:33] <wgrant> Hm
[05:33] <wgrant> Deleting tasks like that
[05:33] <wgrant> Ew
[05:33] <wgrant> ew
[05:33] <wgrant> ew
[05:33] <wgrant> It's existing code
[05:33] <wgrant> But ew
[05:34] <StevenK> wgrant: The correct thing to say is 'Conjoined masters. Ew. Ew. Ew. Ew. Ew.'
[05:34] <wgrant> I think that code's probably even wrong
[05:34] <wgrant> How does that make sense?
[05:35] <wgrant> If we do happen to want to delete the conjoined master, the slave is still going to have the milestone set, isn't it?
[05:35] <StevenK> I tend to close my eyes and say "LALALALA" every time someone mentions conjoined bugs
[05:47] <StevenK> wgrant: There is a test for the conjoined master case, but I don't know.
[06:01] <StevenK> wgrant: And I don't get the SourcePackageRecipeRequestDailyBuildView object has no index bug -- I'm guessing we don't want to render it directly
[06:03] <wgrant> StevenK: Presumably it's never meant to try to render the form, right.
[06:04] <StevenK> Well, there is no form
[06:04] <StevenK> On the action, we request a build and redirect away
[06:04] <wgrant> Right.
[06:05] <StevenK> Which I'm guessing it means it was POST'd to, so I should redirect to the recipe in initialize() if it's GET?
[06:06] <wgrant> Or potentially remove the view and replace it with an API call
[06:06] <wgrant> I'm not sure what the view does.
[06:06] <StevenK> Haha
[06:06] <wgrant> Hm?
[06:06] <StevenK> It does AJAX stuff
[06:06] <wgrant> I'm completely serious
[06:06] <wgrant> If it doesn't do anything special, it can probably be an API call.
[06:08] <StevenK> wgrant: There is some JS that POSTs to it directly
[06:08] <wgrant> Clearly.
[06:08] <wgrant> But why is it not an API call?
[06:09] <StevenK> It gets the AJAX stuff back and uses it to update the page
[06:09] <wgrant> Aha
[06:14] <lifeless> don't we have an html representation thingy in the API ?
[06:14] <lifeless> its terrible but it exsists
[06:19] <wgrant> We do
[06:19] <wgrant> I'm not sure it's immensely useful here
[06:19] <wgrant> It probably wants to get the entire build table back
[06:21] <lifeless> hmm
[06:21] <lifeless> if only we had some sort of client side template system
[06:21] <wgrant> Indeed!
[06:22] <StevenK> requestDailyBuild also may raise two exceptions which the view catches and turns into notifications
[06:26] <lifeless> StevenK: so whats the simplest thing you can do here ?
[06:27] <StevenK> lifeless: Add an initialize() method and redirect, like I've done
[06:28] <lifeless> StevenK: cool
[06:33] <StevenK> wallyworld_, wgrant: https://code.launchpad.net/~stevenk/launchpad/no-render-sprrdb/+merge/125930
[06:37] <lifeless> StevenK: btw, multiple tasks referencing one milestone is a model violation
[06:38] <lifeless> StevenK: it only happens because we haven't done onlyseriestasks yet, *and* we don't do non-series milestones.
[06:38] <lifeless> so s/is a model/should be a model/ really
[06:38] <StevenK> lifeless: You have yet to convince people about onlyseriestasks :-)
[06:41] <StevenK> wallyworld_: You have even more QA!
[06:42]  * StevenK upgrades DF, since that will take a few eons
[06:54] <StevenK> I wonder if qas will have updated and the deployment report updated before DF finishes
[07:02] <wallyworld_> yes, indeed
[07:02] <wallyworld_> not used to it being so soon
[07:02] <StevenK> Hahahaha
[07:02] <StevenK> steven@undermined:~/ubuntu% dput dogfood:~stevenk/ppa/ubuntu xserver-xorg-video-ati_6.13.2-1ubuntu3_source.changes
[07:02] <StevenK> Invalid Files line in .changes:
[07:02] <StevenK>   5266cb3d554ecf973e03af8003e24932 2838 x11, foobar optional xserver-xorg-video-ati_6.13.2-1ubuntu3.dsc
[07:04] <wallyworld_> StevenK: and i can just use the project i set up this morning to qa a different bug and which caused me to file and fix this one i'm doing now
[07:05] <wallyworld_> mid you, i did lp-land
[07:05] <wallyworld_> mind
[07:05] <wallyworld_> we do need to put ec2 on steroids
[07:06] <StevenK> wallyworld_: Go on, then. I'll wait here. :-P
[07:06] <wallyworld_> there's a few options isn't there. but we really should pick one and get it done i guess
[07:07] <wallyworld_> i like whatever has no more ec2 bills each month
[07:07] <StevenK> Jenkins with parameterized builds, then
[07:07] <wallyworld_> yes!
[07:08] <StevenK> wallyworld_: Then shake lifeless until that falls out
[07:08] <wallyworld_> i think if we all beat him up that will help
[07:12] <StevenK> There, my QA is done too
[07:12] <wgrant> What is this madness?
[07:12] <wgrant> Bug #1055250
[07:12] <wgrant> qa-ok
[07:12] <_mup_> Bug #1055250: Bug sharing policy weirdness on +sharing page <disclosure> <qa-ok> <sharing> <ui> <Launchpad itself:Fix Committed by wallyworld> < https://launchpad.net/bugs/1055250 >
[07:12] <wgrant>  Reported by Ian Booth 5 hours ago
[07:13] <StevenK> Haha
[07:13] <wallyworld_> i cheated though
[07:13] <wallyworld_> i skipped ec2
[07:13] <StevenK> wallyworld_, wgrant: Can I have a review now? https://code.launchpad.net/~stevenk/launchpad/no-render-sprrdb/+merge/125930
[07:13] <wallyworld_> sure
[07:14] <wallyworld_> StevenK: when do we hit that view via a get?
[07:14] <StevenK> wallyworld_: When people URL hack
[07:14] <wallyworld_> ah, ok
[07:15] <StevenK> It turns up every now and again
[07:15] <wallyworld_> r=me
[07:17] <wallyworld_> sigh. i just ran > 3000 [B|b]ug tests with an AssertionError inserted into some code and the only failure was an artificially constructed doc test.
[07:18] <wgrant> We have some assertions commented out in Soyuz because lots of tests fall afoul of them
[07:18] <wallyworld_> back to the drawing board, may need to use a soft oops to find it in prod
[07:18] <wgrant> What are you asserting?
[07:18] <wgrant> We may be able to neuter the test :)
[07:18] <wallyworld_> i put in the assertion to try and find the cause of the issue
[07:19] <wallyworld_> that the subject of a bug notification contains [Bug 123] and nothing else
[07:19] <_mup_> Bug #123: There's no direct way to see the project info when translating it <lp-translations> <Launchpad itself:Fix Released> < https://launchpad.net/bugs/123 >
[07:19] <wallyworld_> to fix bug 138775
[07:19] <_mup_> Bug #138775: Notification subject included bug number but no summary for 'subscriber of duplicate' bug notifications <email> <lp-bugs> <regression> <story-better-bug-notification> <Launchpad itself:Triaged> < https://launchpad.net/bugs/138775 >
[07:19] <wgrant> I mostly see that with imported comments
[07:20] <wallyworld_> poking around the code doesn't seem to show how we are invoking the notification calls with no subject set
[07:20] <wallyworld_> i'll revisit tomorrow, gotta do a few things now
[07:20] <wgrant> Ahh
[07:20] <wgrant> So
[07:20] <wgrant> I think there's two bugs there
[07:21] <wgrant> The comments this year refer to something different
[07:21] <wgrant> The original one is probably long gone.
[07:21] <wgrant> Oh
[07:21] <wgrant> Except it's not
[07:21] <wgrant> blah
[07:22] <wgrant> Oh no
[07:22] <wgrant> It is all the same issue
[07:23] <wgrant> czajkowski's screenshot is of an email from an imported comment
[07:23] <wgrant> It just happens to also be through a dupe subscription
[07:27] <wallyworld_> ok, so imported comments may be directly related
[07:27] <wgrant> That's the only case we have any recent evidence of
[07:28] <wallyworld_> i'd love to find a test which causes the issue, will try looking for imported comment tests
[07:29] <wgrant> wallyworld_:
[07:30] <wgrant>         return getUtility(IMessageSet).fromText(
[07:30] <wgrant>             owner=poster, subject='', content=comment['text'],
[07:30] <wgrant>             datecreated=comment['time'].replace(tzinfo=pytz.timezone('UTC')))
[07:30] <wgrant> In lib/lp/bugs/externalbugtracker/bugzilla.py
[07:30] <wallyworld_> ok, so if that's the case, then perhaps there's not much we can do
[07:31] <wallyworld_> perhaps the bug is now invalid
[07:32] <wgrant> I don't believe the original bug exists
[07:32] <wgrant> any more
[07:32] <wgrant> The 2012 stuff is separate
[07:32] <wgrant> External comments are imported with an empty subject
[07:33] <wallyworld_> great, i'll mark the bug as such
[07:37] <adeuring> good morning
[07:46] <wgrant> :(
[07:46] <wgrant> buildbot failure
[07:46] <wgrant> Ah, that one
[07:46] <wgrant> FAILURE: lp.buildmaster.tests.test_builder.TestSlave.test_status_after_build
[08:08] <stub1> Spurious test failure with ec2 from frinday: lp.registry.tests.test_product.TestProduct.test_pillar_category
[08:10] <wgrant> stub1: Have you looked at the error message?
[08:10] <wgrant> IIRC that's the one I deliberately broke
[08:10] <wgrant> But the error should be obvious if it is
[08:11] <stub1> Obvious errors are common in test suites :)
[08:11] <wgrant> It was "raise Exception('Nothing to see here.')" or so
[08:12] <stub1> yeah
[08:13] <wgrant> Yeah, that's fixed now
[08:13] <wgrant> Was just testing that the new buildbots picked up failures.
[08:17] <wgrant> stub1: Do you intend to deploy the new pgbouncer during an fdt window soonish?
[08:17] <stub1> wgrant: Yes
[08:18] <wgrant> Great.
[13:18] <adeuring> benji: could you please review this MP: https://code.launchpad.net/~adeuring/launchpad/sharingjob-remove-bp-subscriptions/+merge/126008 ?
[13:19] <cr3> hi folks, is there a reason why Launcphad builders use ascii encoding? I thought the default encoding for Ubuntu, for all languages, was utf-8 but I could be wrong
[13:19] <benji> adeuring: sure
[13:20] <adeuring> benji: thanks. Just noticed that there are merge conflicts..
[13:29] <rick_h_> adeuring: yea, you hit the moving of InformationType and such to lp.app.enums
[13:39] <benji> adeuring: I'm done reviewing https://code.launchpad.net/~adeuring/launchpad/sharingjob-remove-bp-subscriptions/+merge/126008
[13:39] <adeuring> benji: thanks!
[14:30] <rick_h_> benji: for your reading pleasure if you get time https://code.launchpad.net/~rharding/launchpad/regjs/+merge/125780
[14:31] <benji> rick_h_: I am warming up the new browser tab factory as we speak.
[14:32] <rick_h_> benji: ty much, appreciate it
[14:32] <rick_h_> benji: ignore the small yui 3.5.1 one. I'll self review that once we get the productino changes into place. Just holding off until then before moving it forward
[14:32] <benji> k
[14:47] <rick_h_> benji: so yea, that large html swatch was pulled from production. It's generated by the server side Widget stuff and it seemed best just to copy/drop it into place to dupliacte things.
[14:47] <rick_h_> load the page, find the element, "copy as html" from the debug tools. I can note taht in the test .html file as the location for future use?
[14:50] <benji> rick_h_: at a minimum we should include a comment stating why it is there, hints in the tests that failures might mean that the copied HTML needs to be updated, and detailed instructions on how to update it
[14:50] <benji> or we can decouple the tests from the HTML (being more unit-y, I would guess)
[14:50] <rick_h_> benji: ok, I'll doc it up. It just takes a lot to bootstrap the choice widget html and such so I cheated as I didn't think of a good way to generate it manually
[14:51] <rick_h_> benji: no, you're right. Part of this came from debugging was hard. the choicewidget doesn't just update the radio button so I needed a full ChoiceSource instance to test against
[14:52] <rick_h_> I'll look at what I can lose/redo there
[15:02] <tumbleweed> benji: can I prod you to look at https://code.launchpad.net/~stefanor/launchpad/edit-packagesets/+merge/124555 ?
[15:04] <benji> tumbleweed: sure
[15:45] <rick_h_> let's put this fancy new buildbot to work! bwuhahaha
[15:45] <czajkowski> hehe
[15:45] <czajkowski> rick_h_: it sounds evil when you say it
[15:46]  * rick_h_ is feeling very evil genius atm
[15:54] <rick_h_> benji: ping, I cleaned up the sample html. I still need it because I do some ancestor checking and the license is double nested so I want to test that
[15:54] <rick_h_> benji: but I removed all but a single option value from each level so that it's a lot less/cleaned up with a comment up top
[15:55] <benji> cool, I'll taake a look in a minute
[15:55] <rick_h_> benji: ty
[16:32] <rick_h_> die buildbot die...that is all
[17:21] <rick_h_> ok, that is cool I can break and unbreak buildbot over lunch
[17:58] <benji> rick_h_: I'm afraid I'm being difficult re. https://code.launchpad.net/~rharding/launchpad/regjs/+merge/125780 (I wrote the last comment a while ago but forgot to ping you)
[17:58] <rick_h_> benji: yea saw it. I understand. I got sidetracked trying to unbork buildbot
[17:59] <rick_h_> benji: so I'll go back and copy and paste, but yea part of the test is to make sure we manipulate the dom correctly so really just no good way to make sure of that without having it in place there
[17:59] <rick_h_> where we're missing that live state of automated testing against a live running web page
[18:08] <benji> rick_h_: yeah, we're in an odd place there; I think you've struck just about the best balance we can at the moment
[18:19] <cr3> hi folks, is there a reason why Launcphad builders use ascii encoding? I thought the default encoding for Ubuntu, for all languages, was utf-8 but I could be wrong
[18:20] <tumbleweed> only in in a UTF-8 locale
[18:21] <cr3> tumbleweed: not sure I I understand :)
[18:23] <tumbleweed> cr3: the problem you are running into is that the default locale is C, which pre-dates UTF-8. There is a C.UTF-8 locale if you want things to assume UTF-8
[18:25] <cr3> tumbleweed: isn't the default locale on ubuntu something like en_US.UTF-8? the C locale is ancient, I'm just not sure how it's representative of any installation of ubuntu I've encountered so far
[18:26] <tumbleweed> cr3: no. Although it would be in a desktop environment
[18:28] <cr3> tumbleweed: hm, ubuntu server looks like en_US by default which is probably not UTF-8. that would answer my question, thanks!
[18:29] <tumbleweed> cr3: and builds happen in minimal chroots, with no locale specified
[18:30] <lifeless> morning
[18:30] <cr3> tumbleweed: the reason I ask is that it's annoying to have unit tests pass when run locally but fail when run during the build process. do you happen to know if it's common when unit testing to clear the environment?
[18:31] <tumbleweed> cr3: it's a common issue to run into when running unit tests during builds
[18:31] <cr3> tumbleweed: I wonder if it's actually a good indication to improve my test runner though
[18:34] <cr3> I had a quick look at the launchpad bin/test script and it only does some changes to the environment like os.environ['TZ'] = 'Asia/Calcutta', but I wonder if test runners should be wrecking more havok in the environment to avoid some assumptions
[19:00] <tumbleweed> benji: thanks
[19:01] <benji> my pleasure
[19:01] <tumbleweed> should I prod anyone for a DB review?
[19:01] <benji> you can request a DB review on the MP
[19:05] <tumbleweed> what do I need to do to do that?
[19:51] <sinzui> benji, do you have time to review https://code.launchpad.net/~sinzui/launchpad/pageids/+merge/126081
[19:51] <cjwatson> cr3: yes, you ought to improve your test runner here.  The default locale in the absence of indications to the contrary in the environment is C
[19:52] <cjwatson> cr3: depending on the test runner, you might either want to run everything with locale bits cleared from the environment, or you might want to run the tests multiple times in different locales, or you might want to run everything forcing a UTF-8 locale (and in that case C.UTF-8 should be suitable on modern releases)
[19:52] <cr3> cjwatson: agreed, at first it looked like the builders were annoying but making assumptions on a sane environment is ironically insane
[19:53] <cr3> cjwatson: have you ever seen a test runner actually clear all the environment? I've been looking around, mostly at python projects providing a ./test script, and this doesn't seem to be common
[19:53] <cjwatson> Even Ubuntu server is probably UTF-8 by default in general, but there are many contexts where you can end up starting something with a minimal environment
[19:53] <cjwatson> cr3: *shrug* not an expert on test runners
[19:54] <cr3> cjwatson: I checked a fresh install of ubuntu and the LANG was set to en_US, but that might be because of my preseed
[19:54] <cr3> s/ubuntu/ubuntu server/
[19:54] <cjwatson> that's not the default
[19:55] <cr3> cjwatson: hm, thanks for the heads up, I should look into fixing that
[19:55] <cjwatson> we certainly don't use legacy ISO-8859-1 locales by default anywhere
[19:55] <cjwatson> cr3: sbuild will build your package in a cleaned environment
[19:55] <cjwatson> I'm fairly sure it clears the locale
[19:56] <lifeless> sinzui: lp:~sinzui/launchpad/pageids
[19:56] <sinzui> yes
[19:56] <lifeless> sinzui: I think you may have misunderstood the issue; the PPR handles spaces AFAIK
[19:57] <lifeless> sinzui: its having the revisionid in the pageid thats a problem
[19:57] <sinzui> oh,
[19:57] <lifeless> sinzui: because it means we cannot aggregate times across deploys.
[19:57] <sinzui> well I fixed that accidentally
[19:57] <lifeless> great.
[19:58] <cjwatson> cr3: also note that, if you were sshing in, our ssh forwards the locale by default
[19:58] <cr3> cjwatson: fyi, I use the example preseed from the installation-guide-i386 as reference and my template is even very friendly to diff against it, that's where I got the default value for en_US
[19:59] <cr3> cjwatson: I use that package to keep my preseed up to date with latest developments
[19:59] <cjwatson> Mm, probably ought to fix that, although I had a feeling that it was supposed to turn it into the nearest UTF-8 form automatically
[19:59] <cjwatson> Anyway, OT for this channel, feel free to file bugs :)
[20:00] <lifeless> flacoste: hi ?
[20:00] <cr3> cjwatson: will do
[20:01] <benji> sinzui: sure
[20:02] <flacoste> hi lifeless
[20:27] <sinzui> jcsackett, do you have time to talk?
[20:31] <sinzui> benji, thank you for the corrections
[20:31] <benji> my pleasure
[20:38] <jcsackett> sinzui: sure.
[20:40] <sinzui> jcsackett, hangout?
[20:42] <jcsackett> sinzui: started.
[20:58] <rick_h__> hey all, I've got biuldbot broken atm, just pushed a fix (hopefully) and going to be afk for 20min while it runs. I'll be back in when it finishes to hopefully drive this through.
[20:58] <rick_h__> general heads up, I emailed a reply to the buidlbot message as well
[20:58] <lifeless> rick_h__: thanks
[21:03] <mwhudson> \o/ for parallel testing
[21:03] <jelmer> \o/ indeed
[21:25] <mwhudson> huh
[21:25] <mwhudson> make in the launchpad root (which i haven't done in a loooong time, to be fair) failed like this:
[21:25] <mwhudson>     ImportError: /home/mwhudson/canonical/repos/launchpad/devel/lib/gettextpo.so: wrong ELF class: ELFCLASS32
[21:25] <mwhudson> that's ... more exciting than i expected?
[21:28] <cjwatson> Sounds like you last built it in a 32-bit environment, and make doesn't notice that it needs to rebuild them because as far as it's concerned all the timestamps are up to date.
[21:30] <mwhudson> yeah, but that seems pretty unlikely in itself
[21:30] <mwhudson> anyway, make clean && make worked
[21:32] <lifeless> mwhudson: lxc bind mount vs direct access?
[21:33] <mwhudson> lifeless: ah yes, that's probably it
[21:59] <rick_h__> bah, missed a handful of tests. This might still fail
[22:05] <rick_h__> ok, so down to one failing. It was one of the handfull my regex missed so updated and send back to buidbot
[22:05] <rick_h__> <3 the rocking parallel tests
[23:36] <wgrant> wallyworld_: Were you going to comment on bug #138775?
[23:36] <_mup_> Bug #138775: Notification subject included bug number but no summary for 'subscriber of duplicate' bug notifications <email> <lp-bugs> <regression> <story-better-bug-notification> <Launchpad itself:Triaged> < https://launchpad.net/bugs/138775 >
[23:36] <wgrant> And ideally close it
[23:37] <wallyworld_> wgrant: yes, getting to it
[23:37] <wgrant> Great, just checking it hadn't dropped off your radar
[23:37] <wallyworld_> nope
[23:46] <cjwatson> We have a stupidly near deadline for getting signed kernels sorted out in Ubuntu, which requires https://code.launchpad.net/~cjwatson/launchpad/uefi-copy-no-auto-approve/+merge/126128 or something like it - if anyone has time to review that I'd appreciate it
[23:47] <cjwatson> (I know, my lack of planning isn't your emergency)
[23:48] <cjwatson> (Also the branch name is a bit crap, it reflects the first half of the change)
[23:49] <wgrant> Looking
[23:49] <wgrant> I was just about to ask about that, yeah
[23:49] <cjwatson> I only remembered about it after I'd already committed so the later stuff had the existing branch nick all over the metadata
[23:50] <lifeless> wgrant: that bug on legacy mirroring - have we deleted the code?
[23:50] <wgrant> cjwatson: archiveuploader's CustomUploadFile.autoApprove doesn't autoapprove PPA uploads, does it?
[23:51] <lifeless> wgrant: if so, I don't think it should be FR, but perhaps dropped to High. The point was to migrate all the branches behind the scenes.
[23:51] <wgrant> lifeless: No, I think there's another bug for that
[23:51] <cjwatson> wgrant: It doesn't, but there's a higher-level method that does
[23:51] <wgrant> lifeless: No, the point was that legacy mirroring was broken
[23:51] <wgrant> Legacy mirroring is no longer broken, so that bug is fixed :)
[23:51] <cjwatson> wgrant: BuildDaemonUploadPolicy.autoApprove
[23:51] <wgrant> Ah, right
[23:51] <cjwatson> (Should I tweak the comment?)
[23:52] <wgrant> That would be lovely
[23:52] <lifeless> wgrant: the question was about it being broken
[23:52] <lifeless> wgrant: the bug was about it being something folk have to reconfigure to get to
[23:52] <cjwatson> Done
[23:52] <wgrant> [Bug 1051097] Re: legacy bzr mirroring broken
[23:52] <_mup_> Bug #1051097: legacy bzr mirroring broken <code-import> <regression> <Launchpad itself:Fix Released by wgrant> < https://launchpad.net/bugs/1051097 >
[23:56] <wgrant> lifeless: Bug #872312
[23:56] <_mup_> Bug #872312: kill BranchType.MIRRORED <code-import> <lp-code> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/872312 >
[23:56] <lifeless> ok
[23:56] <wgrant> cjwatson: Wow, getTargetArchive was a bit odd
[23:57] <cjwatson> Wasn't it
[23:57] <cjwatson> "Why doesn't this work ... oh"
[23:58] <wgrant> cjwatson: Did you check history to confirm there wasn't a reason for it?
[23:58] <cjwatson> CustomUploadCopier was rather obviously single-goal-oriented to start with; I've been gradually generalising it
[23:58] <wgrant> i can't see one, but you never know..
[23:58] <wgrant> Ah
[23:58] <cjwatson> I didn't explicitly do so, but let me have a quick dig
[23:59] <cjwatson> Well, it dates right back to the original fix for bug 659769, when that file was added
[23:59] <_mup_> Bug #659769: should copy custom uploads to newly-initialised release <derivation> <lp-soyuz> <new-release-cycle-process> <qa-ok> <soyuz-publish> <Launchpad itself:Fix Released by jtv> < https://launchpad.net/bugs/659769 >