#launchpad-dev 2010-01-04
<jml> 'make schema' is failing for me w/ CSS errors.
<jml> ahh, but it's fixed by a 'make clean'
<spm> make ajax-clean? (har har)
<jml> spm, *snrk*
<rockstar> thumper, around?
<thumper> rockstar: no
<rockstar> thumper, :(
<rockstar> thumper, could you take a look at this really quick?  I made the changes you asked for, but I guess I should have pinged you after I did them.  https://code.edge.launchpad.net/~rockstar/launchpad/branch-scanner-prep/+merge/16260
<thumper> rockstar: not tonight, going to see avatar, I'll look tomorrow morning when I start work
<rockstar> thumper, okay.  I have a branch dependent on it that I was hoping to land.  I'll just blame you for not landing it in tomorrows stand up.  :)
<thumper> ok
<rockstar> thumper, have fun at the movie.
<adeuring> good morning
<al-maisan> Good morning adeuring, alles Gute im neuen Jahr :)
<adeuring> al-maisan: hi al-maisan! auch Dir eine frohes neues Jahr!
<al-maisan> :)
<henninge> adeuring, al-maisan: Auch von mir ein Frohes Neues! ;)
<adeuring> henninge: danke, Dir auch!
<al-maisan> henninge: hallo, Frohes Neues Jahr :-)
<mrevell> Hello all
<deryck> Morning, all.
<adiroiban> hi, in the latest launchpad/devel , if I run the full test suite, 1 test is with errors (lp.translations.tests.test_translationbranchapprover.TestTranslationBranchApprover.test_approveNewSharingTemplate) and there are 53 import errors
<adiroiban> is this ok?
<wgrant> adiroiban: Can you pastebin the full error output?
<wgrant> I only know of one test (xx-sso-resetpassword.txt, or something of the sort) that should be failing for non-Canonical people.
<adiroiban> http://paste.ubuntu.com/351210/
<wgrant> adiroiban: You need to reset your DB permissions.
<wgrant> 'make schema' will do that for you.
<wgrant> (and wipe out the rest of the data, but it's the easiest way)
<wgrant> The import warnings are probably just because jml unbroke the importfascist not long ago. Ignore them.
<jml> or fix them.
<adiroiban> thanks
<adiroiban> jtv: hi. Can you please take a look at the last comment from bug 127171. If everthing is ok I will create a MP
<mup> Bug #127171: Rosetta experts not allowed to "Change translators" <Launchpad Translations:In Progress by adiroiban> <https://launchpad.net/bugs/127171>
<jtv> adiroiban: hi, happy new year!  Looking...
<jtv> adiroiban: I posted a comment
<adiroiban> jtv: thanks. as far as I know, right now translation group owners don't have access to products/projects translations settings? Should I go and implement it, or we need to gather more answers for this new question?
<jtv> adiroiban: my knowledge matches yours.  :)  The only _good_ reason I can think of not to allow this is if we decide to add a bunch of other translations settings to that same page.  Then it might potentially be a bad thing.
<jtv> Technically the translation grou
<jtv> p owner probably shouldn't mess with the access model (open/structured/...)
<jtv> but this is the group owners we're talking about, not a wet-behind-the-ears translator who isn't aware of some special arrangement for the project.
<adiroiban> true
<adiroiban> jtv: can you think of some new translations settings that in the near future can land on this pag
<jtv> not very near future, no... I've been suggesting breaking down _all_ the project/distro settings by app, but we never did get around to that
<jtv> (so you'd have a Settings page with the usual overview/branches/bugs/... tabs, and conversely, each of those pages for the project would have a Settings link
<jtv> )
<jtv> Anything else?  Something related to upstream connections, I guess.  Maybe it's all in the name this page has.
<jtv> You've been playing with giving it a more generic name, but maybe we should consider the opposite.
<jtv> e.g. "+translation-access"
<jtv> that way we definitely wouldn't move anything unrelated onto the page that we don't want to give group owners access to.
<adiroiban> well right now we have +setting (for a product) and +translations-settings (for a product series)
<adiroiban> group owners should not care about +translations-settings
<adiroiban> for a productseries
<jtv> adiroiban: in that case I mis-remembered; I'd better go refresh my recollection
<jtv> I got that the other way around
<jtv> adiroiban: hmm...  I see +changetranslators on the product, which actually sounds just right for what we want here
<kfogel> deryck: morning!
<jtv> hi kfogel!
<kfogel> jtv: hey there, happy new year
<jtv> same to youâhappy 2553
<jtv> BE
<kfogel> jtv: "2553 BE" ?
<jtv> Buddhist Era.
<adiroiban> jtv: true. but last time we talked about this topic, we decided to rename +changetranslators to +settings
<deryck> Morning kfogel!
<jtv> kfogel: and no, I have _no_ idea whether there's a BB as well
<jtv> adiroiban: absolutely right... but what I'm saying is you might have uncovered a reason for not doing that after all
<kfogel> jtv: heh!  never heard that before.
<kfogel> deryck: what time's standup?
<adiroiban> :_
<adiroiban> :)
<adiroiban> jtv: ok. then I will leave +changetranslators
<adiroiban> and allow translation group owners to edit that page for both product and distribution
<jtv> adiroiban: also has the advantage of less work.  :)
<deryck> kfogel, you know we already did it.  We didn't change it yet.  I thought you were unavailable today for some reason.
<kfogel> deryck: whoa -- I forgot it currently started that early.  No problem.
<jtv> adiroiban: I do think this'll spread some unexpected happiness, as group owners gain a bit more control over their relationship with projects
<adiroiban> yep. but appart from Ubuntu and Launchpad Translations groups, I think all other product specific translations groups are owned by the product owner/developer
<jtv> adiroiban: even so, imagine someone assigning an arbitrary, unrelated project-specific translation group to their project.  As things stand, the group owner just goes "wtf" but can't do much.  Now, they can just change the setting.  And they can keep each other happy for days toggling the switch until they decide to talk to each other.  :-)
<adiroiban> :)
<adiroiban> jtv1: i have one more question for bug 127171. Since this is a special edit/admin case, I can not reuse launchpad.Edit or launchpad.TranslationsAdmin permissions. It is ok if I'll create launchpad.ChangeTranslators permission ?
<mup> Bug #127171: Rosetta experts not allowed to "Change translators" <Launchpad Translations:In Progress by adiroiban> <https://launchpad.net/bugs/127171>
<jtv> adiroiban: thin ice for me, so it's worth getting e.g. sinzui (hi sinzui :) into the discussion
<sinzui> adiroiban: yes that is a difficult issue
<jtv> I suppose the alternative would be to have a separate object with regular Edit or Admin rights granted to these groups
<adiroiban> yep
<jtv> but as things stand now, I'd be hard-pressed to answer questions like "then should this be edit or admin," or "if this is Edit, what would Admin mean for that object"
<adiroiban> we already have IHasTranslations
<adiroiban> so IHasTranslators
<adiroiban> can add some confusion
<jtv> confusion adds spice to life
<jtv> but anyway :)
<sinzui> adiroiban: jtv: consider separating the classes, or using a marker interface. You can also create launchpad.Moderate because that is what rosetta-experts does in many cases
<adiroiban> well.. for a IProduct/IProject/IDistribution this is neither Edit or Admin for
<jtv> sinzui: note that in this case, there are 2 additional classes of people that would have these rights
<jtv> âthe owners of the translation group (one side of a relationship) and the owners of the project (other side of the same relationship)
<jtv> sinzui: prima facie this doesn't sound like a case for Moderate, but you do remind me that we can have a look for appropriate existing permissions before we consider adding new ones
<sinzui> jtv: I added marker interfaces to distinguish better Ubuntu and other distros so that they could have different permissions in security.py. It is a pain to add
<jtv> sinzui: interesting approach... not something I would have come up with given my background in static languages
<jtv> sinzui: or wait... are you saying "to better distinguish distributions from e.g. projects," or "to better distinguish Ubuntu from other distributions"?
<jtv> henninge, do you have any suggestions for a launchpad.* permission we might use for setting a project or distro's translation group & access model?
<sinzui> yes: IBaseDistribution and IDerivativeDistribution are added on Distribution.__init__ so that is clear how the instance uses Launchpad.
<sinzui> ^ jtv
<jtv> cool
<henninge> jtv: is launchpad.Moderate already used?
<henninge> jtv: launchpad.Special would be the other option.
<adiroiban> henninge, jtv launchpad.Moderate is not used in translations
<jtv> There was a mailing list thread about Special ages ago, which I probably didn't bother to read
<adiroiban> we have launchpad.TranslationsAdmin for edit/admin translations settings for objects
<jtv> Moderate seems to be used only in Answers
<henninge> jtv: it is now used in registry, too, once my branch is finally landed ...
<jtv> oh?
<adiroiban> whare are the drowback of having launchpad.ChangeTranslators ?
<jtv> adiroiban: just that we should stop and think before multiplying permission types.
<henninge> jtv, adiroiban: And we need special blessings from on high to be allowed to add it .
<jtv> no biggie really, just a checkpoint
<jtv> henninge: oh my, it's been so long since I added one that I'd forgotten that :)
<henninge> there is the man to ask for it ^ ;-)
<jtv> yup :)
<jtv> flacoste: you come at just the right time
<flacoste> morning launchpadders
<jtv> (and hi, btw :)
<flacoste> and happy new year!
<henninge> but I don't think we need to, we can just re-use one of the existing once.
<flacoste> hi jtv
<flacoste> jtv: what can i do?
<henninge> flacoste: and a good one to you, too.
<jtv> flacoste: we're just discussing whether adding a new permission is the right thing to do for a particular case
<flacoste> jtv: it usually is not, but there are exceptions
<adiroiban> flacoste: is related to bug 127171
<mup> Bug #127171: Rosetta experts not allowed to "Change translators" <Launchpad Translations:In Progress by adiroiban> <https://launchpad.net/bugs/127171>
<adiroiban> we have âtranslationgroup translationpermissionâ atrributes for IProduct, IProject and IDistribution
<adiroiban> and we can not reuse launchpad.Edit, launchpad.Admin or launchpad.TranslationsAdmin permission
<adiroiban> as this is a special edit/admin case
<flacoste> adiroiban, jtv: what is it you want to protect?
<flacoste> these two attributes on product, project?
<jtv> flacoste: More generally: a project/distro/project-group can pick one translation group to manage its translations, but we'd like to give 4 classes of users the right to edit this relationship:
<flacoste> and distribution
<adiroiban> yes
<jtv>  * owners of the project/distro/project-group
<jtv>  * owners of the translation group
<jtv>  * rosetta admins
<adiroiban> flacoste: well, in fact we want to protect all the others attributes
<jtv>  * full admins
<flacoste> adiroiban: what other attributes?
<flacoste> adiroiban: i assume those are allrday protected
<jtv> right
<adiroiban> other edit and admin attributes for project/distribution
<adiroiban> flacoste: yes. they are protected
<jtv> I think the confusion is because we're actually talking about un-protecting something :)
<flacoste> adiroiban: instead of defining a new permission, why not refactor these aspects into a separate object? and use launchpad.Edit / launchpad.Admin there
<flacoste> adiroiban, jtv: i don't think these attribuets are really part of the IProduct, IProject, IDistribution interface
<jtv> we were discussing that against the alternative of adding a permission
<flacoste> jtv: i'd rather refactor into separate object instead of adding to permission proliferation
<flacoste> it brings other advantages has it reduce the interface
<adiroiban> ok. then I will use launchpad.Edit on TranslationPermission
<adiroiban> from lp.translations.interfaces.translationgroup
<adiroiban> sorry. IHasTranslationGroup
<jtv> flacoste: this is oddly reminiscent of something we discussed in Dallas... basically a "compound attribute" or "inline object"
<jtv> one thing I'm far too rusty on: can you do this on the interface, as opposed to the object?
<jtv> I mean, is just moving these two attributes into a new interface enough?
<flacoste> adiroiban, jtv: you can declare security on an interface, but you have to have a separate object providing that interface
<flacoste> adiroiban, jtv: if you simply use IHasTranslationGroup and IProduct defines it, the it's kind of undefined which checker will be used to get launchpad.Edit
<flacoste> s/defines it/provides it/
<flacoste> since you'll have a checker for launchpad.Edit on IProduct
<flacoste> and one launchpad.Edit for IHasTranslationGroup
<flacoste> but Product will provide both
<flacoste> which checker should be used for launchpad.Edit on a product?
<jtv> flacoste: so that would be "no" to my question.  Thank God you're here.  :-)
<jtv> flacoste: launchpad.Edit for a Product should stay exactly as it is
<jtv> so yes, we would need to take steps to avoid "polluting" the existing permissions for the existing objects
<jtv> a new class wouldn't really "do" anything though, apart from apply this permissionâyou'd basically have either launchpad.Edit on it or nothing
<adiroiban> jtv, flacoste : what would be you suggestion for solving this problem?
<jtv> I know I'm the one who said "consider a new class before adding a permission," but In this particular case, I don't think it'd pull its weight
<jtv> francis..?
<flacoste> jtv: well, not creating a new permission pulls its weight for me
<flacoste> i'd call it TranslationPolicy
<flacoste> isn't it what it is?
<flacoste> it defines the translation policy for the IHasTranslationGroup?
<adiroiban> is translationpolicy + translationgroup
<flacoste> meaning it's the translationgroup itself?
<jtv> note that there is no IHasTranslationGroup yet; that's just something we're considering as part of an alternative to a new permission
<flacoste> do you have a ITranslationGroup already?
<jtv> yes
<adiroiban> jtv: hm... what is IHasTranslationGroup from lp.translations.interfaces.translationgroup
<adiroiban> ?
<flacoste> i'd say create a ITranslationPolicy
<flacoste> which has permission and group has members
<jtv> adiroiban: oh, we do have one?  oops!
<jtv> the new interface is definitely a nice idea...  I'm more worried about a new implementing class
 * jtv checks out IHasTranslationGroup
<flacoste> you can then define an adapter that will map the attributes to the underlying db object
<flacoste> so to get to the translationgroup or permission for an object you'D use
<flacoste> ITranslationPolicy(product).translationgroup
<jtv> ah, ok, we do have the separate interface already
<flacoste> why do you need IHasTranslationGroup?
<jtv> it turns out that's the interface that these attributes are already in
<flacoste> right, so I'd say rename the interface and use an adapter
<flacoste> because a product wouldn't have a translation group anymore
<flacoste> it could be adapted into one
<flacoste> that'd be another way of doing it actually
<flacoste> move the permission attribute to the translationgroup itself
<flacoste> and adapt directly to ITranslationGroup
<flacoste> that doesn't work if you can change the translation group though
<flacoste> which i think is what you want here
<flacoste> in that case, renaming it has a TranslationPolicy sounds better
<adiroiban> the permissions were moved to IHasTranslationGroup
<flacoste> right
<jtv> flacoste: adapting to ITranslationGroup wouldn't be appropriate here, but adapting to the separate interface does look good
<jtv> And then there'd be a launchpad.Edit on the class that provides the adapter?
<beuno> deryck, hi. I woke up today thinking about Launchpad bugs Q&A
<jtv> flacoste: and I guess setters, to shunt changes back to the actual Product/Project/Distribution
<flacoste> jtv: yes, there'd be a launchpad.Edit checker for ITranslationPolicy
<flacoste> jtv, adiroiban: i'd check if lazr.delegates allow delegating setter also?
<deryck> beuno, ok, cool.  I'm all ears. :-)
 * jtv checks
<flacoste> jtv, adiroiban: declare the adapter as trusted, that way you'll always get an unproxied object has the adpater context (so the raw DB object)
<beuno> deryck, it wasn't a bright idea as much as "that would be very cool"  :)
<beuno> do we know when we're going to sink our teeth into the feature?
<jtv> flacoste: raw model object I understand... but what db object?
<jtv> oh, the contextâsorry
<flacoste> jtv: well, the raw model object is a db object, no
<jtv> flacoste: is there no risk of leaking when we do that?  I would've thought to use rSP() in the setters
<jtv> (although of course that means we lose the convenience of delegating them, if that is possible)
<flacoste> jtv: no, the security framework will proxy it back
<jtv> ah ok
<jtv> so we're really just allowing access for the purpose of delegating
<jtv> I know there was a doctest for delegates _somewhere_...
<jtv> adiroiban: I'm checking whether delegating settings will work
<deryck> beuno, sorry, locked up system.  we'll continue work on q&a when checkwatches work is done.  I'd guess a couple months out.
<deryck> beuno, just a guess though :)
<adiroiban> jtv: OK. Right now I'm lost and I'm looking at the LP code to understand the required changes
<jtv> flacoste: bless your little toes, yes, setters get delegated!
<jtv> adiroiban: instead of making IProduct/IProject/IDistribution inherit from IHasTranslationGroup, you'd give them adapters to IHasTranslationGroup
<jtv> (I'm ignoring the matter of renaming the interface here, since it's entirely orthogonal to the rest of it)
<jtv> adiroiban: the adapted object implements IHasTranslationGroup, but simply by delegating it to self.context using lazr.delegates.
<jtv> so it contains nothing but self.context, which is a reference to the real Project, Product, or Distribution
<adiroiban> jtv: ok. I'll ignore the renaming for now. So one adapter for each attribute
<jtv> adiroiban: no, the adapter produces an object that implements the entire IHasTranslationGroup (so both the TranslationGroup reference and the permissions setting)_
<adiroiban> jtv: can you point me to a similar code that is already implemented in LP.
<jtv> adiroiban: I tried to find back the documentation for delegates that I seem to recall reading, but little luck so far.  :/
<adiroiban> I think an example will help me understand what are these lazr.delegates, why and how should I use them
<jtv> you're very right to ask for it though!
<jtv> (I'm still searching :)
<jtv> adiroiban: ah! it's been turned into a README.txt in lazr.delegates
<adiroiban> jtv: is this an external project? i could not find the README.txt for lazr.delegates
<jtv> adiroiban: right, it's outside of the lp tree; look in lp-sourcedeps/eggs/lazr.delegates*
<adiroiban> thanks
<jtv> meanwhile I'm cooking up a very schematic example
<jtv> of the delegation part
<adiroiban> jtv: yep. reading the documentation...
<adiroiban> jtv: getting back to IHasTranslationGroup
<adiroiban> it should be renamed to ITranslationsPolicy, right?
<jelmer> Does this error look familiar to anyone?
<jelmer>   Getting distribution for 'distribute'.
<jelmer> Error: Couldn't find a distribution for 'distribute'.
<jelmer> That's while running bootstrap.py
<jtv> adiroiban: http://paste.ubuntu.com/351305/
<beuno> flacoste, UI call?
<flacoste> beuno: yep
<beuno> EdwinGrubbs?
<beuno> noodles775?
<beuno> jtv?
<EdwinGrubbs> beuno: I'm dialing in now
<jtv> beuno: same here
<kfogel> adeuring: hey, I think you dropped out on the canonical irc network
<adeuring> kfogel: i should be back.
<adeuring> (that was the daily connection reset from my ISP... Need to disconnect the DSL modem explicitly later this evening)
<kfogel> adeuring: not back yet (at least according my nick completion).  But anyway, no big deal.  I was going to say "call now?", but need to have a quick conversation with my girlfriend Winnie about coordinating travel later today, so let me do that first then ping you.
<adeuring> kfogel: sure, np
<jtv> adiroiban: I'm leaving for the night... what's your impression of Francis' suggestion so far?
<adiroiban> jtv: still reading about delegates
<adiroiban> I don't know if this should be part of the model or the view
<kfogel> adeuring: okay, ready
<kfogel> adeuring: I'm "karl.fogel" on skype
<adeuring> kfogel: ok,. I'll call you
<jtv> adiroiban: did my example help?  One thing beyond the delegates part is that the TranslationPolicy class can serve as an adapter factory (look for "adapter" in lib/lp/translations/configure.zcml) to produce TranslationPolicy objects.
<adiroiban> jtv: right now I don't know how to plug the TranslationPolicy into the current views
<kfogel> adeuring: https://dev.launchpad.net/Bugs/PatchTracking
<adiroiban> jtv: but with more reading I should get my way. Thanks! Have a good evening
<jtv> adiroiban: from a brief look at ProjectChangeTranslatorsView, I'd guess you could use the generic form for TranslationPolicy.
<jtv> whoops... evening?  almost midnight.  See you tomorrow!  :-)
<adiroiban> jtv: :)
<adiroiban> see you tomorrow! ... or in the morning :)
<jtv> gah :)
<bigjools> sinzui: thanks for your bug retargeting work
<sinzui> bigjools: your welcome.
<kfogel> adeuring: https://wiki.ubuntu.com/Specs/LaunchpadUpstreamImprovements
<kfogel> adeuring: https://bugs.edge.launchpad.net/malone/+bug/231023
<mup> Bug #231023: on status change, show new status in Subject: <email> <Launchpad Bugs:Confirmed> <https://launchpad.net/bugs/231023>
<kfogel> adeuring: did you read https://bugs.edge.launchpad.net/malone/+bug/172501/comments/6 and Emmet's followup comment to it?
<mup> Bug #172501: reject non-code patch attachements <patch-tracking> <story-patch-report> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/172501>
<kfogel> adeuring: it seems Matt Z is suggesting that this whole automatic detection of patches plan is bogus, and instead bugsquad should just add "patch" flag manually when they see there's a patch there.
<kfogel> adeuring: to me, that sounds like unnecessary work for bugsquad, and we *should* be able to do better with automatic detection.  But I'm not sure if there's perhaps some history here that I'm not aware of.
<adeuring> kfogel: right. but that perhaps also a hint that we should focus more  on bzr branches than on attachments
<kfogel> adeuring: hmrm.  Okay, adjusting comment accordingly.
<kfogel> adeuring: added comments to bug #298099 and bug #172501 as discussed.  I wish I knew a way to add a shorthand link to a particular comment (e.g., the way "bug #NNN" links to that bug, I want to link to "bug #NNN comment #8", but the only way I can see to do that is to just write out the full URL to that comment).
<mup> Bug #298099: patch flag for attachments not indicated as optional <patch-tracking> <story-patch-report> <ubuntu-qa> <ui> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/298099>
<mup> Bug #172501: reject non-code patch attachements <patch-tracking> <story-patch-report> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/172501>
<adeuring> kfogel: thanks!
<kfogel> adeuring: ah, that's bug #242420
<mup> Bug #242420: should be possible to link to bug comments like 'bug 123' becomes a link <infrastructure> <ui> <Launchpad Bugs:Confirmed> <https://launchpad.net/bugs/242420>
<mrevell-lunch> curses, I've not been on lunch all this time...
 * mrevell --> reboot
<leonardr> bary, i have a python voodoo question
<leonardr> the code is here: http://pastebin.ubuntu.com/351352/
<leonardr> entry_schema has a non-None value in class_dict, but when I create a type for it, the class's entry_schema is None. the attribute is present but its value is None
<leonardr> how can this be happening?
<leonardr> barry -^
<leonardr> the superclass (BaseCollectionAdapter) does not define that attribute, so it's not that the superclass value is taking precedence
<leonardr> barry: i set class_dict['entry_schema'] to the string 'foobar', and that worked
<leonardr> ok, i think i see the problem...
<mrevell> g'night all :)
<leonardr> barry: another voodoo question if you're around
<james_w`> hi leonardr
<leonardr> james_w: hi
<leonardr> barry: http://pastebin.ubuntu.com/351399/
<leonardr> is it possible and zope's BrowserRequest interface does not have a metaclass of 'type'?
<james_w`> leonardr: lazr.restfulclient requires Resource A to be bound to know the Resource type for Resource B where B is a parameter of A. Is that a limitation of WADL, or just the way lazr.restfulclient is coded?
<leonardr> that sounds like a quirk of lazr.restfulclient or wadllib, probably restfulclient
<james_w`> it seems like more use could be made of resource_type references, but is there something that means you don't know exactly which resource type you will get?
<james_w`> e.g. team vs. person?
<james_w`> they would both be Entry, and I think it would be mad to have something which could be either a Collection/Entry, but Collection/CollectionWithKeyBasedLookup would be possible
<mwhudson> good morning
<leonardr> james_w: there are cases where the wadl says you get a generic interface (eg. a pillar or a person) when you'll actually get a more specific type. in those cases you'll have to fetch the real object to see the type
<leonardr> but they would both be entry
<leonardr> they would be different subclasses (sub-interfaces) o f the same generic interface
<james_w`> I'm asking as I'm writing a lazier version which just instantiates dummy objects, it would be good if those dummy objects could at least know whether they should offer e.g. __getitem__ so that you could error earlier
<james_w`> ok, so it sounds like you could at least do the dance around RESOURCE_TYPE_CLASSES and the like, even if you aren't sure exactly which attributes the new Resource will present
<james_w`> morning mwhudson
<james_w`> thanks leonardr, I'll keep looking at this
<leonardr> james_w: yes, unless there are specific client-side classes for Team and Person, which shouldn't happen, you should be able to defer fetch to the moment at which the object's type is actually needed
<leonardr> but for all i know that will end up happening immediately
<barry> leonardr: hi, been on another machine.  still need help?
<barry> leonardr: >>> from zope.publisher.browser import BrowserRequest
<barry> >>> type(BrowserRequest)
<barry> <type 'type'>
<barry>  
<barry> leonardr: >>> from lazr.restful.interfaces import IWebServiceConfiguration
<barry> >>> type(IWebServiceConfiguration)
<barry> <class 'zope.interface.interface.InterfaceClass'>
<barry>  
<mwhudson> crap
<mwhudson> i have 1.5 times as much unread mail as i had this time yesterday
<rockstar> mwhudson, yeah, it's coming in faster than I can read it.
<leonardr> barry: so should i use InterfaceClass instead of type? this is not something i understand well
<thumper> morning
<rockstar> thumper, not-so-subtle-harassment for reviewing https://code.edge.launchpad.net/~rockstar/launchpad/branch-scanner-prep/+merge/16260
<thumper> morning rockstar
<rockstar> thumper, morning.
<rockstar> :)
<barry> leonardr: i think so.  the problem you're having is (iirc) zope's interface metaclass predates inheriting from type.  it's a metaclass defined in C.
 * thumper running for real coffee, bbs
<wgrant> jelmer: I worked around that distribute issue by downgrading python-pkg-resources and python-setuptools to their Karmic versions.
 * mwhudson afk for a bit
<james_w> https://edge.launchpad.net/lazr.restfulclient.tx <- contributions welcome
<jml> oooh.
<jml> james_w, shiny
<jml> james_w, you going to mention it in #twisted?
<james_w> jml: you think I should?
<jml> james_w, maybe. someone might be interested.
<thumper> jml: junk branches biting us in the arse again with branch.product is None
<jml> thumper, I thought I fixed or XXXd all of those
<thumper> jml: when someone fixed the getBranch for revision, it broke the revision karma allocator
<jml> thumper, what was the allocator doing?
<jml> (I bet it wasn't asking for what it actually wanted, but figuring out what it wanted from a bunch of implementation details)
<thumper> jml: the query is broken asking for which revisions
<thumper> jml: and the checker is broken in at least one place
#launchpad-dev 2010-01-05
<thumper> jml: and we don't allocate karma for packages
<jml> thumper, ahh ok.
<thumper> jml: so at least three separate problems
<jml> thumper, where does the allocator live?
<jml> thumper, I'd be interested to figure out why I missed it.
<thumper> we are failing due to revision that are in project branches and package branches
<thumper> and the package branch is found first
<thumper> so being skipped
<thumper> now we are skipping 100 at a time
<thumper> and selecting the same 100 every select
<thumper> lp.code.scripts
<jml> thumper, I guess I mean, where was it a year ago :)
<thumper> jml: probably scripts
 * thumper shrugs
<thumper> jml: branch just got an is_junk attribute
<jml> :(
<thumper> jml: frowny for what?
<jml> thumper, I think it's better to say why you care if it's junk.
<thumper> jml: I say where it is being checked
<thumper> jml: but instead of checking either that the target is the owner, or checking product and distroseries
<jml> thumper, yeah, but you could give it a name in code, separating the fact about whether it belongs to a project from how we count karma.
<jml> thumper, certainly it's a step up from that.
<jml> thumper, why not check if the target provides karma for revisions?
<thumper> mmm...
<jml> it's what we already do for MPs etc.
<thumper> jml: heh
<thumper> jml: BranchTarget already has assignKarma
<thumper> although
<thumper> ...
<thumper> nm
<thumper> :(
<jml> thumper, wassup?
<thumper> test_karmaDateForFutureRevisions passes, but for the wrong reasons
<thumper> the revision karma stuff is a bit of a mess
<jml> thumper, it's good to spot it though, and then also to have the opportunity to fix it there & then :)
<thumper> yeah
<thumper> all this fixing to make the karma revision script run successfully again
<spm> thumper: karma for yak shaving?
<thumper> ââ¹
<spm> I'd say that's a yes then.. :-)
 * jml is off to lunch & errands.
<thumper> phew
<thumper> I think that is the revision karma issue dealt to
<thumper> mwhudson: feel like a review?
<mwhudson> thumper: sure
 * thumper pushing now
<thumper> mwhudson: proposed, email arriving soon
<mwhudson> thumper: looking now
<thumper> mwhudson: thanks for the review
<thumper> mwhudson: I've just finished clearing the code import queue
<thumper> mwhudson: there were a lot of imports that needed tweaking
<thumper> probably 75% of them
<thumper> https -> http
<thumper> and missing /trunk
<thumper> and bad certs
<thumper> invalid locations
<mwhudson> thumper: yeah :(
<mwhudson> wow, the failure mode of the multi-line editor isn't very good
 * thumper afk - bbl
 * mwhudson eods
 * jml errands
<jtv> hi adiroiban!  did you manage to get through the delegates stuff?  :-)
<ArneGoetje> Hi folks! I have a question: I'm looking for the latest translation tarball for cupsys for Hardy on launchpadlibrarian. According to the api it's this one: https://launchpadlibrarian.net/34788059/cupsys_1.3.7-1ubuntu3.6_amd64_translations.tar.gz , but it seems to have been garbage-collected. Isn't the latest version to be kept around? Could someone help me to find out what happened here?
<ArneGoetje> The upload was on 2009-11-09, btw.
<jtv> ArneGoetje: looks like the soyuz folks aren't here yet  :(
<ArneGoetje> jtv: thanks... will try again later
<wgrant> ArneGoetje: I think I know what the problem is.
<wgrant> Those files weren't unembargoed.
<wgrant> So they're still sitting on the restricted librarian.
<ArneGoetje> wgrant: 'unembargoed'?
<wgrant> You could ask a member of the security team to get it for you, if you need it quickly.
<wgrant> ArneGoetje: Security uploads are uploaded to a private PPA first.
<wgrant> They build there.
<wgrant> Then they are copied into RELEASE-security in the public Ubuntu archive, and their files are made public.
<wgrant> (private PPA files are normally stored in a special librarian instance, not accessible to the public)
<wgrant> I'm checking the code now, but I suspect that custom uploads (like translations tarballs) are not moved across.
<ArneGoetje> wgrant: aha... so, they should appear whenever the cupsys package hist hardy-security?
<ArneGoetje> s/hist/hit
<wgrant> ArneGoetje: *should*, yes. But they haven't, because of this bug.
<ArneGoetje> wgrant: bug?
<wgrant> ArneGoetje: Normal sources and binaries are moved from the restricted to the public librarian when a package is copied from the security P3A. But custom upload files are not. This is a bug, which I am filing now.
<wgrant> ArneGoetje: Also, those tarballs aren't expired at all yet -- even really old ones should still be there somewhere.
<ArneGoetje> wgrant: got it. Thanks.
<wgrant> Bug #503258
<mup> Bug #503258: Custom upload file privacy not updated <Soyuz:New> <https://launchpad.net/bugs/503258>
<wgrant> It'll take some refactoring to fix.
<jml> g'night all
<mrevell> Morning
<jtv> oh, hi mrevell, hi henninge!
<henninge> hi jtv!
<adeuring> good morning
<al-maisan> Good morning henninge and adeuring
<al-maisan> hello jtv
<adeuring> hi al-maisan!
<henninge> Hallo al-maisan und adeuring! ;)
<adeuring> hi henninge!
<henninge> jtv: I saw Francis' approach went into a completely different direction than just picking a permission. What did you end up with?
<jtv> hi al-maisan!
<al-maisan> hello jtv!
<jtv> henninge: creating a new object
<jtv> henninge: instead of making IProduct, IProject & IDistribution inherit from IHasTranslationGroup, we'd have an adapter to give access to the translation group reference & access model: IHasTranslationGroup(ubuntu).translationgroup
<jtv> henninge: the object that the adapter produces delegates its two attributes to its context, so it's basically a 3-line class.
<jtv> and then for IHasTranslationGroup we can have Edit permissions
<henninge> jtv: cool, I want to do something like that to add "is_admin" etc.  attributes to persons without blowing up the IPerson interface even further.
<henninge> but I am not sure the blowing up is really an issue here.
<jtv> well, we have ITranslationsPerson now
<jtv> (gah, fsck still not done)
<henninge> jtv: where, has it landed?
<jtv> henninge: ages ago, no?
<henninge> jtv: oh, I was not aware of it. Lemme look what it is.
<jtv> lp.translations.interfaces.translationsperson.ITranslationsPerson
<jtv> just "the Translations aspects of Person"
<jtv> ...and also done as an adapter.
<henninge> jtv: ah, cool
<deryck> Morning, all.
<jtv> hi deryck
<jtv> bigjools: ArneGoetje couldn't find a particular package's translations tarball (in hardy, I think) that we think should be in the librarian.  Can you help?
<henninge> jtv: TranslationsPerson doesn't do the delegation you describe for IHasTranslationGroup. Do you have an example for that?
<jtv> henninge: no, these two things are completely unrelated (apart from the adapters)
<jtv> henninge: TranslationsPerson is "the Translations aspects of Person."
<bigjools> jtv: not right now, can I get back to you later
<wgrant> jtv, bigjools: Bug #503258
<mup> Bug #503258: Custom upload file privacy not updated <Soyuz:New> <https://launchpad.net/bugs/503258>
<jtv> henninge: IHasTranslationGroup is the part where we discussed design with Francis.
<jtv> bigjools: thanks
<henninge> jtv: I am aware of that.
<bigjools> wgrant: groan :(
<wgrant> bigjools: Yeah, it's not a really easy fix.
<jtv> henninge: oh, I misunderstood then... what was the connection supposed to be?
<bigjools> wgrant: why do you say that?
<henninge> jtv: when you say "delegates", I understand that that the object the adapter produces has all the attributes of the original object plus the IHasTranslationGroup attributes, right?
<jtv> ArneGoetje: see wgrant's note... bug 503258 may be related to your problem
<mup> Bug #503258: Custom upload file privacy not updated <Soyuz:Triaged> <https://launchpad.net/bugs/503258>
<jtv> henninge: ah!  no, the object provides only IHasTranslationGroup (with those 2 attrs)
<jtv> it implements _those_ by delegating to its contextâeither Distribution or Product or Project.
<henninge> jtv: ok, so it is a normal adapter
<henninge> I see
<wgrant> bigjools: Things will need to be shuffled around, since the code that does the privacy updating only knows about the [SB]PPH.
<wgrant> So it's not hard, just not as trivial as it would seem from the description.
<bigjools> right
 * bigjools hopes the phone line holds up to the snow here
<bigjools> wgrant: what is the manifestation of this problem?
<bigjools> the publisher will still work fine
<wgrant> bigjools: Translation tarballs for security updates are inaccessible, which makes ArneGoetje sad.
<bigjools> inaccessible by what means?
<wgrant> bigjools: The URLs exposed through the API and +queue.
<bigjools> oh, this is the thing we did recently
<bigjools> the new custom type that only sits in the libraria
<bigjools> n
<wgrant> No, no.
<wgrant> This is boring old raw-translations that has been around for years.
<wgrant> But it also affects the new raw-translations-static, yes.
<bigjools> raw-translations will be in the archive
<wgrant> In a processed form, yes.
<bigjools> er, it doesn't do any processing?
<wgrant> Don't they go into rosetta, which then produces langpacks?
<bigjools> the only place that won't be able to see them is the UI
<bigjools> scripts will be fine
<bigjools> but anything that is uploaded is placed in the archive verbatim
<wgrant> Custom uploads aren't.
<wgrant> DDTP/dist-upgrader/d-i are extracted, normal translations are sent to rosetta, and static translations just live in the librarian.
<wgrant> I'm not sure for what purpose a raw-translations tarball is useful, but raw-translations-static is certainly useful, and regardless this is a bug.
<bigjools> I still don't understand where the problem is
<bigjools> basically because I don't know much about translations
<wgrant> It's a bug regardless of whether there is a use for the translations tarballs. https://edge.launchpad.net/ubuntu/hardy/+queue?queue_state=3&queue_text=redhat-cluster&start=90, expand the bottom upload, and look at the URLs produced for the translations tarballs.
<wgrant> noodles775: Since you seem to be amassing quite a collection of corrupt builds, do you have any idea what happened to the single build on https://edge.launchpad.net/~mudlet-makers/+archive/ppa/+builds?build_state=building?
 * noodles775 looks
<noodles775> wgrant: nope - but it looks dangerous (thinks it's building but doesn't have a builder associated with it's buildq entry.)
<noodles775> The state looks similar to bug 499421 (for which we haven't yet determined the cause)
<mup> Bug #499421: Build farm grinds to a halt with inconsistent build <Soyuz:Triaged by michael.nelson> <https://launchpad.net/bugs/499421>
<wgrant> noodles775: Right, that's why I brought it up.
<wgrant> It's all rather broken :(
<noodles775> I'm guessing that it's date_started is still null (hence not causing the bf to collapse).
<noodles775> Yes, it is... we had some large branches go in last cycle which didn't get enough dogfooding, I think.
<wgrant> It has a date_first_dispatched, but it doesn't look like the Job is accessible through the API.
<noodles775> Nope. I'm looking through retryDepWaiting atm (for bug 499421 - as it seems to be a commonality for those examples of corrupt builds).
<mup> Bug #499421: Build farm grinds to a halt with inconsistent build <Soyuz:Triaged by michael.nelson> <https://launchpad.net/bugs/499421>
<noodles775> erm, 499095, that would be.
<wgrant> noodles775: It doesn't look like any of those three depwaited.
<wgrant> Do you have evidence that they did?
<noodles775> wgrant: the two builders listed on the build page (one is from build.builder, the other from buildqueue.builder).
 * noodles775 rechecks *when* build.builder is set.
 * wgrant is really not a fan of this data model.
<noodles775> The buildqueue entry is only temporary, the build records which builder *built* the package as a permanent record. And yes, it'd be unreal to have the time to refactor a lot of this.
<wgrant> Yep.
<wgrant> noodles775: I find it suspicious that it looks like they all ended up GIVENBACK.
<wgrant> And the response for a GIVENBACK build isn't particularly sane.
<wgrant> Although it does set the status properly :(
<wgrant> Oh.
<wgrant> Maybe not.
<wgrant> Hmm. Two statuses == confusing.
<ArneGoetje> wgrant: the raw-translation tarballs are useful for us Ubuntu Translation Coordinators to figure out why certain templates and .po files have not been imported into Rosetta. Instead of rebuilding the package from source and stripping out the translations by ourselves, we just need to download the raw-translation tarball and get everything like Rosetta sees it.
<wgrant> bigjools: ^^
<noodles775> wgrant: Yeah, we're definitely not setting the job's status properly (afaics), but I hadn't noticed the GIVENBACK - I'll look more closely after lunch (ping me if you find anything more - or add a comment on the bug, thanks!)
<wgrant> noodles775: I'm poking around to work out how this new job stuff works (or doesn't).
<noodles775> great.
<sinzui> HELP: I need help with a branch. I am exposing an wsop parameter over the API, except that my tests show that it does not work--the arguments are ignored.
 * al-maisan wonders what an "wsop parameter" is..?
* mrevell changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 1 of 10.01 | PQM is open | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes
<sinzui> EdwinGrubbs: skype?
<EdwinGrubbs> sinzui: it's on. can you see me now?
<sinzui> EdwinGrubbs: I do see you
<abentley> jtv: TestTranslationsImport.test_handle_serious_error and test_handle_unexpected_exception are leaving a dirty environment-- they're causing errorlog.globalErrorUtility to be reconfigured.
<jtv> abentley: sorry for the trouble... looking it up now, but will have to go soon
<abentley> jtv: I'm motivated to fix it, but I'd like your idea of the best fix.
<abentley> jtv: What
<abentley> jtv: What's happening is the tests are calling main() on a script.
<jtv> abentley: isn't that the right one to invoke?
<abentley> jtv: And scripts, because they expect to run in an empty environment, set the error handling up.
<jtv> ah, I thought that was all nicely isolated in self.logger
<abentley> jtv: You thought the test runner would be resetting the error handling?
<jtv> abentley: no, I thought the script's error handling setup wouldn't mess with global state.  :-(
<abentley> jtv: I think it's reasonable to expect scripts to mess with global state.  But we could patch this one by just doing addCleanup.
<abentley> jtv: I usually run scripts in a subprocess to better mimic the conditions they'll run in.
<jtv> abentley: yes, but I do minimize that because it's incredibly expensive.
<jtv> I once sped up the test suite by several minutes just by reducing the number of script runs in one test.
<abentley> jtv: So I think our options are: 1. run in a subprocess, 2. addCleanup, 3. run something other than main, 4. take the error handling setup out of main
<jtv> abentley: is the setup really done in main though?
<jtv> as opposed to the LaunchpadScript constructor?
<abentley> jtv: po_import.py:142
<jtv> abentley: ahhhh, _that_
<jtv> the oops logging
<jtv> would it be terribly evil to add a "kill switch" that suppresses it in tests?
<jtv> similar to test_args
<abentley> jtv: I could live with that, but I think we can probably stick it into the standard setup.
<jtv> abentley: for all scripts, you mean?  I guess we could just reuse the script name we pass to the LaunchpadScript ctor anyway...
<abentley> jtv: No, I mean that the import script could reimplement LaunchpadScript.run to set up the oops handling first.
<jtv> oic
<jtv> abentley: maybe there is already some appropriate callback in LaunchpadScript to stick this in?
<abentley> jtv: There doesn't seem to be a setUp/tearDown pair, if that's what you're thinking.
<jtv> well we wouldn't even need a teardown if we can elide it altogether
<jtv> something similar to _init_zca and _init_db
<jtv> do you think anybody would do a run() in-process from a test?  If not, run() could also just initialize this regardless
<abentley> jtv: My reading is that there's no setUp -- LaunchpadScript.run serves that purpose.
<abentley> jtv: I think that run() from a test would fail horribly, because it would leave a very dirty environment.
<abentley> jtv: I think it's fine to do it always in run.
<jtv> abentley: iirc I copied all this from one of your scripts in the first place, so that script might be affected as well :-)
<abentley> jtv: With the difference that I didn't *expect* calling main() to work :-)
<jtv> abentley: with this change, future generations will look at _your_ tests and ask "wtf didn't he just call main()?"  :-P
<abentley> jtv: I don't think so.  I have about two integration tests, and the rest are unit tests.
<adiroiban> jtv: is this ok to change the browse/configure.zcml in this way http://paste.ubuntu.com/351825/ ?
<adiroiban> i don't know where to plug the adapters and delegates in the current LP setup
<jtv> adiroiban: a separate IProductTranslationPolicy..?
<adiroiban> jtv: i'm lost
<adiroiban> if I will leave IProduct, how can I check the special permission with launchpad.Edit?
<jtv> ahh
<jtv> unfortunately right now I'm way too tired to think about new problems!
<adiroiban> jtv: ok. np. we can talk tomorrow morning
<jtv> the adapter part is easy: you basically say in zcml that the class is the factory for the objectsâsearch for "adapter"
<jtv> yes, talk tomorrow... but definitely thanks for working on this!
<adiroiban> np
<adiroiban> the adapters should go in lp/translations/adapters.py ?
<Ursinha> bigjools, hello :) happy new year
<adiroiban> there is no adapters.py for translations
<bigjools> Ursinha: Happy new year!
<Ursinha> bigjools, :)
<Ursinha> bigjools, well, I have one oops... :)
<Ursinha> bigjools, https://edge.launchpad.net/~mudlet-makers/+archive/ppa/+build/1376913 is oopsing, seems to be bad data
<bigjools> doesn't surprise me
<adiroiban> jtv: let's leave this for tomorrow
<bigjools> noodles775: ^^
<Ursinha> bigjools, https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1462F51
<jtv> adiroiban: thanks for understanding :-)
<noodles775> bigjools: yes, I saw it earlier (wgrant pointed it out), it's another building build without a bq.builder.
<bigjools> ok thanks
<adiroiban> henninge: can you take a quick look at bug 340664 (screenshots) and tell me is this is how the bug should be fixed ?
<mup> Bug #340664: Add administration page for all POTemplates in ProductSeries or DistroSeries <ui> <Launchpad Translations:In Progress by adiroiban> <https://launchpad.net/bugs/340664>
<henninge> adiroiban: looking
<henninge> adiroiban: it is possible that this book was overlooked when implementing +templates.
<jtv-zzz> abentley: gotta go now... thanks for cleaning up my mess, and repeated apologies for making it!
<adiroiban> henninge: i don't know the story (history) behind +templates
<abentley> jtv-zzz: no problem.
<adiroiban> I just saw this is a high priority bug
<adiroiban> and tried to nail it
<henninge> adiroiban: cool, so you'll just have to add more columns to the table, right?
<adiroiban> I added the one that can we seen in the screenshot
<adiroiban> adding columns is easy...
<henninge> ;)
<Ursinha> bigjools, noodles775, should I open a bug for that oops or there's one already?
<adiroiban> making +templates not die in Ubuntu is the hard part
<adiroiban> but I assume this is another bug
<noodles775> Ursinha: I haven't seen a bug for it yet, so that would be great. Thanks.
<henninge> adiroiban: well, I tried to fix that before but I guess it needs some more work.
<bigjools> Ursinha, noodles775: wait, we have plenty already?
<henninge> adiroiban: anyway, for this but I am just not sure if Priority is really used much. Do you know if people actually use it? Why did you putit to the front?
<henninge> s/but/bug/
<Ursinha> bigjools, not really, I saw one in jan 1st
<EdwinGrubbs> sinzui: you're missing a "d" for created_after and created_before.
<bigjools> what I mean is, we already have bugs covering this issue
<noodles775> bigjools: for that situation? I haven't seen one? (ie. the bq.builder is empty, buildstate is BUILDING but it's not causing 449421 as the date_started (i'm guessing here) is still null).
 * sinzui plants hand in face
<sinzui> EdwinGrubbs: Thank you for pointing my incompetence.
<jtv-zzz> henninge: in my current state I shouldn't comment on bugs, but credits cleanup completed 2009-12-24... if there is still a problem, then that is indeed a new bug
<noodles775> bigjools: But maybe it's an older issue? - I haven't looked further than the 2 current bad build data bugs.
 * henninge whispers in jtv-zzz's ear, so not to wake him but to appear in his dreams:
<sinzui> Why hasn't edge updated in several week?
<henninge> I'll watch it...
<bigjools> noodles775: ok let's check the prod data to see what state it's in
<jtv-zzz> henninge: :)
<henninge> oh how cute, he smiles in his sleep !
<adiroiban> :)
 * sinzui suspects that mrevell is trying to get more karma then sinzui
<mrevell> sinzui, haha, you've discovered my plan :)
<sinzui> mrevell: you can win the karma race by fixing the status and priority of the hundreds of old blueprints that claim to be High and inprogress
<james_w> where would I find the tests for ./scripts/ftpmaster-tools/sync-source.py ?
<bigjools> james_w: hahahaha
<james_w> thought so
<henninge> sinzui: Did you request / start an update for edge? It's become awfully slow for me.
<sinzui> henninge: no. I was asking why edge is more than a week old
 * sinzui cannot do QA testing
<henninge> sinzui: while you are not QAing, do you have a few minute for a pre-imp conversation?
<sinzui> henninge: yes
<henninge> sinzui: cool
<henninge> sinzui: I'd like to implement this: http://paste.ubuntu.com/351849/ as an adapter on IPerson.
<henninge> sinzui: The adapter the adapted object would be passed to the checkAuthenticated methods in security.py as the user paramter (instead of an IPerson).
<sinzui> henninge: I like your proposal
<sinzui> Does it need to be extended to support private bugs and branches?
<henninge> sinzui: I don't understand.
<henninge> ?
<henninge_> sinzui: I don't understand?
<sinzui> henninge: Access control to a private object may require tests like: isBugSupervisor(obj), isBugSubscriber(), isBranchSubscriber()
<henninge_> sinzui: oh, it can be extended for other needs, I don't mind that.
<sinzui> henninge_: I image that this class would be near ILaunchpadCelebrity
<henninge_> sinzui: OTOH the person object remains accessible through the picon attribute
<henninge_> sinzui: yes, I am not sure if it is really part of registry of foundations.
<henninge_> s/of/or/
<henninge_> s/picon/person/
<henninge_> how did that word get inthere ... ;)
<sinzui> henninge_: this object crosses boundaries. We do not want lp/registry person to know about celebrities which is the lp/app.
<sinzui> henninge_: My real concern is not where the code is, but that we need this object synced with LaunchapdCelebrity
<henninge_> sinzui: I see. I was going to put that in the tests.
<henninge_> sinzui: whenever a Person celebrity is added or removed from LPCelebrity, the test fails.
<sinzui> henninge_: I this PersonMembership is too ambiguous. This class is a security helper for celebrities
<henninge_> sinzui: "PersonCelebrityHelpers" ?
<henninge_> sinzui: some automatic relationship to LPCelebrities could be possible, too.
<sinzui> I think IPersonCelebrity will do
<henninge_> sinzui: ok, I am fine with that.
<henninge_> sinzui: although the methods in the interface don't deal with celebrities at all.
<sinzui> I cannot think how to test that a property added to ILaunchapdCelebrity has a counterpart  in IPersonCelebrity
<henninge_> sinzui: there is PersonCelebrityDescriptor that counts Person celebrities in a class attribute.
<sinzui> henninge_: okay
<henninge_> lists them, even.
<henninge> sinzui: I'll file a foundations bug about it, I think.
<sinzui> henninge: the methods are fine for the name, but a better name might be IPersonRoles.
<henninge> good one!
<tsimpson> regarding bug #385517 does this require a (to be) updated version of launchpadlib or can it be used with the current version?
<mup> Bug #385517: launchpadlib users made to authenticate unnecessarily <Launchpad Foundations:Fix Released by leonardr> <https://launchpad.net/bugs/385517>
<henninge> sinzui: but wait, weren't there plans for "roles" in Launchpad?
<sinzui> henninge: I has proposed IRole in the past as a way to mange predefined roles in launchpad, and as a way to let users create arbitrary roles. They include owner and driver, but might also include designer
<henninge> sinzui: oh, so this is going in a very similar direction.
<sinzui> yes
<henninge> sinzui: I am glad you like it. I'll put it in a bug. It should not be too hard to implement. (Famous last words)
<sinzui> Do you have an immediate use?
<henninge> sinzui: I want to get rid of the permission_helpers.py file that I introduced two branches ago before others start accumilating stuff in there ... ;)
<henninge> accumulate?
<sinzui> ah
<henninge> so this really is a tech-debt thing
<henninge> sinzui: cheers, it's bug 503454
<mup> Bug #503454: Make checks for celebrity persons and roles easier <Launchpad Foundations:New> <https://launchpad.net/bugs/503454>
<sinzui> henninge: I tagged the bug with tech-debt to give it more justification to work on now
<henninge> sinzui: thanks, I'll be quick ;)
<james_w> is there no way to tell shhh.py to get out of the way?
<james_w> ah, I can tell make not to use it
<matsubara> I'm getting a sh: apr-1-config: not found error when I run rocketfuel-get, anybody know what can I do to fix it? (pastebin: http://pastebin.ubuntu.com/351886/)
<james_w> matsubara: you probably need to install libapr1-dev
<matsubara> james_w, installing libapr1-dev solved the problem. thanks!
<james_w> np
<mrevell> night all
<rockstar> abentley, hi
<abentley> rockstar: Hi
<rockstar> Have you ever had problems calling create_branch_and_tree twice in the same test?
<abentley> rockstar: I don't think so.
<rockstar> abentley, I'm seeing where it tries to create the tree on top of the already created tree.
<abentley> rockstar: Are you specifying a tree location?
<rockstar> abentley, no, and looking at the code, I 'spose I should.  :)
<abentley> rockstar: I think that would resolve this problem.
<abentley> rockstar: Maybe we should use pseudo-random tree names instead of '.' by default?
<rockstar> abentley, yeah.  I expected it to create its own dir to put the tree in.  Maybe we ought to modify it to do that.
<rockstar> abentley, great minds think alike?
<rockstar> (and then I play catch up?)
<abentley> rockstar: Yeah.  I think I was apeing the Bazaar testing methodology too closely when I did that.
<abentley> rockstar: doing that now may break a lot of tests, but I suppose we can rewrite them easily enough.
<rockstar> abentley, hm, maybe I should re-think that approach then, and just make my test pass.
<abentley> rockstar: rewriting those tests would mean supplying an explicit '.'
<rockstar> abentley, yeah.  :)
<rockstar> abentley, I'm just trying to minimize the changes I make in this branch.
<Ursinha> rockstar, abentley, are you aware that +code-import-list is oopsing?
<rockstar> Ursinha, I am now.
<Ursinha> https://code.edge.launchpad.net/+code-import-list
<rockstar> Ursinha, eep.
<Ursinha> rockstar, care to take a look?
<rockstar> Ursinha, I think I have a good idea.
<rockstar> Ursinha, is there a bug filed?
<Ursinha> rockstar, there is now: bug 503479
<mup> Bug #503479: +code-import-list OOPSing with AssertionError <oops> <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/503479>
 * rockstar locates food
<mwhudson> good morning
<thumper> morning
<abentley> morn
<abentley> mwhudson, thumper, rockstar: are we standupping?
<thumper> sinzui: got a minute?
<thumper> flacoste: are we talking today?
<flacoste> thumper: we should
<sinzui> thumper: yes
<thumper> sinzui: I've made the branch for the product series permissions, but need help with the location for the test
<sinzui> thumper I tend to add a permission checks to the browser/tests or docs/
<thumper> sinzui: suggestions of where to put the test for launchpad.edit for the productseries?
<sinzui> thumper: I see that productseries-views.txt is using check_permission so that is one place
<sinzui> and doc/productseries.txt also uses check_permission to verify objects
 * mwhudson afk for an early lunch
#launchpad-dev 2010-01-06
<jml> thumper, you around?
<jml> or mwhudson?
<mwhudson> jml: hello
<jml> mwhudson, I'd like to talk about expanding the membership of the ~vcs-imports team
<mwhudson> jml: ok
<jml> mwhudson, probably at least to include ~canonical-bazaar
<mwhudson> jml: to "trusted community types" or ... ?
<mwhudson> ah right
<mwhudson> well that would make sense, yes
<jml> mwhudson, and maybe trusted folk interested in ubuntu-distributed-development
<jml> mwhudson, we could do that on a fairly ad hoc basis I think.
<mwhudson> yeah
<mwhudson> so, +1
<mwhudson> what is there to talk about?
<mwhudson> i guess we need to consider the dangers of a member going rogue
<jml> mwhudson, that was it. I just wanted to confirm. :)
<jml> mwhudson, also, I don't have permissions to add members to ~vcs-imports
<mwhudson> thumper is the owner these days, i think?
<mwhudson> oh no, it's lifeless still
<jml> mwhudson, also, what do you think about putting ~canonical-bazaar into ~bazaar-experts?
<mwhudson> jml: i thought you wanted to delete ~bazaar-experts :)
<jml> mwhudson, I do.
<jml> mwhudson, but while it's there... :)
<jml> lifeless, can you please add ~canonical-bazaar to ~vcs-imports?
<jml> mwhudson, is the import approval howto on the public wiki?
<jml> mwhudson, ahh, I see that it isn't. I can move it to the dev wiki and edit the CHR-specific bits if you think that'd be OK.
<mwhudson> jml: sounds like a good idea
<jml> mwhudson, ok.
<jml> mwhudson, I guess the biggest risk in expanding the ~vcs-imports group is that it gives write access to a lot of branches.
 * jml is offline for a while
<lifeless> mwhudson: is that an ack for jml's request?
<mwhudson> lifeless: yes
<lifeless> mwhudson: thumper is an admin
<lifeless> jml: done
<thumper> we are we adding?
<lifeless> thumper: scroll up a half page
<lifeless> thumper: how about we change the vcs-import team owner to be canonical-bazaar
 * thumper looks
<thumper> lifeless: you are the team owner at the moment
<lifeless> I know
<thumper> I don't know if we can change the team owner
<thumper> I can't
<lifeless> I can
<lifeless> its conceptual agreeement to changing it that is needed.
<lifeless> [only team owners & admins can change team owners]
<thumper> lifeless: sure, why not
<thumper> lifeless: we should be able to trust the members of canonical-bazaar
<lifeless> thats my thinking :)
<lifeless> done
<mwhudson> wow the import fascist is sure annoying right now
<thumper> yeay
<thumper> h
<thumper> damn
<thumper> WTF are we supposed to do with questions that obviously are nothing to do with launchpad?
<mwhudson> thumper: i assign them to ubuntu
 * wgrant looks with confusion at the response to https://answers.edge.launchpad.net/launchpad/+question/96334
<mwhudson> wgrant: yay
<spm> ahh. structural subscription.
<wgrant> Yeah.
<wgrant> I have to wonder how so many people manage to do that.
<poolie> hi
<poolie> https://edge.launchpad.net/bzr/+download seems to be persistently (over hours) timing out
<wgrant> poolie: Presumably very related to your bug #499351...
<mup> Bug #499351: product downloads page causes browser hang/unhappiness <Launchpad Registry:Triaged> <https://launchpad.net/bugs/499351>
<poolie> yes
<poolie> i mean they're both basically reflections of the same problem, being that too much stuff is packed onto this page
<thumper> dumb arse ec2 land command
<thumper> yes there are multiple proposals, but one is already merged
<thumper> I obviously mean the other one
 * mwhudson eods
<jml> mwhudson, I've got a branch open to fix it
<jml> mwhudson, the import fascist stuff, that is. Maybe I'll fix it at the airport :)
<mwhudson> jml: as in, up for review?
<jml> mwhudson, no, on my laptop
<mwhudson> jml: i see
<jml> mwhudson, I saw some people complain about the warnings on IRC & email so I thought reducing the number of warnings might be a fun light-weight hacking job
<mwhudson> jml: yeah, i had vaguely similar thoughts
<mwhudson> jml: when are you next in an airport?
<jml> mwhudson, Sunday, I think.
<jml> mwhudson, also, I need to fix all the failures in the 'use-testtools' branch.
<mwhudson> jml: there were failures? how boring
<jml> mwhudson, eh
<jml> mwhudson, I meant to say "heh"
<jml> mwhudson, testtools forces you to upcall setUp and tearDown
<jml> mwhudson, because I was sick of stupid, hard-to-debug, order-dependent test failures.
<mwhudson> ah right
<jml> mwhudson, also, there are some addCleanup tests that I forgot to delete
 * thumper EODs
<adeuring> good morning
<mrevell> Morning
<henninge> Hi mrevell!
<noodles775> wgrant: hi, can you have a scan of the info I've added to bug 503440 and see if you can glean anything out of it? (it's the oopsing build you pointed out yesterday).
<mup> Bug #503440: building build without a bq.builder causing LocationError OOPS <oops> <Soyuz:Triaged> <https://launchpad.net/bugs/503440>
<noodles775> wgrant: actually, the timing looks like it is actually the result of some manual SQL that was run at the time... I'll update the bug.
<bigjools> morning all
<wgrant> noodles775: Is it intentional that the logs in that paste are not in any kind of order?
<noodles775> wgrant: no, I just did grep 1376913 `find . -name 'buildd-manager.log.*'` > ~/build1376913.log
<noodles775> wgrant: new comment added with a most-likely reason.
<wgrant> noodles775: Ah, that's good.
<wgrant> So there's only one known bug remaining.
<noodles775> Seems so :)
<wgrant> Although nothing jumps out to me about that one.
<noodles775> Yeah, me either. And the fact that build 1376913 was dispatched without causing the issue so many times, and then fell over...
<wgrant> noodles775: So it is still happening, without bad SQL being invoked?
<noodles775> wgrant: There are two occurrences of 499421 that I'm aware of, the one linked above on 2009-12-21, and once during the break (on the 2010-01-01, as commented on the bug).
<noodles775> But we don't know the build for that second one yet (I'm just organising to have the losa query updated so that we get the build id when it occurs).
<jtv-afk> jml: just followed up to your db review... are you content with the answer?
<jtv> hi adiroiban!
<adiroiban> jtv: hi
<jtv> adiroiban: sorry for running away from the discussion last night :)
<adiroiban> jtv: don't worry. there is plenty of time to solve the problem this year
<jtv> adiroiban: true... as years go, this one still has a lot of unused days
<jtv> About the notion of an IProductTranslationPolicy: I was thinking that the TranslationPolicy object would give admin permissions to members of self.context.owner, self.context.translationgroup.owner if set, plus of course admins / rosettaadmins.  That way, I thought you wouldn't need to have any specialized I{Product,Project,Distribution}TranslationPolicy.
<jtv> But does that not work?
<adiroiban> jtv: i don't know. I am still new to zope and LP code.
<adiroiban> I don't know how to configure the view
<adiroiban> in order to create vies for TranslationPolicy
<adiroiban> but with different objects
<adiroiban> I know that I can use an adapter to generate TranslationPolicy(IProduct) or TranslationPolicy(IDistribution)
<jtv> adiroiban: you'd have one TranslationPolicy, and one view class, that wouldn't know or care what object it's operating on...  but how to get from "product" to ITranslationPolicy(product)... that's a good question
<jtv> I wonder if you can just register a view for interface ITranslationPolicy but class Product, and get what you want automatically.
<jtv> This is a web framework after all; the whole idea is that you spend days to figure out how to get automatically in a few cryptic lines what you could have coded up in half an hour.  Progress.  :)
<adiroiban> jtv: what do you mean by âregister a view for interface ITranslationPolicy but class Productâ?
<adiroiban> something like this http://paste.ubuntu.com/352254/
<adiroiban> how whould to know know to create a ITranslationPolicy(Product) context ?
<jtv> adiroiban: sorry, page.  Register a page, with class=Product (and similar for Project & Distribution) and interface=ITranslationPolicy
<jelmer> bigjools, http://pastebin.ubuntu.com/352255/
<jtv> adiroiban: ah, no, it doesn't work like that  :)
<adiroiban> true
<adiroiban> what you are sugesting is similar with my patestbin
<adiroiban> I can think of having ITranslationPolicyProduct
<adiroiban> and an adapter to build object for this interface
<jtv> adiroiban: or maybe just having ITranslationsPolicy with a view, and adapters for IProduct etc. plus a single <browser:page> will create the pages you need
 * adiroiban trying that code
<adiroiban> jtv: where I should put this common view in browser/* ?
<jtv> adiroiban: how about under translationgroup?
<jtv> I think that's also, on the interfaces side, where the enumeration for open/structured/... lives
<adiroiban> ok
<adiroiban> but we will rename IHasTranslationsGroup to ITranslationPolicy , right?
<jtv> adiroiban: yes
<Ursinha> bac, hi :) I see you were approving a branch merge from jtv when you got this oops, am I right? https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1466EB1022
<bac> Ursinha: i don't recall getting that oops
<bac> https://code.edge.launchpad.net/%7Ejtv/launchpad/validate-translations-file/+merge/16866/+index
<bac> the MP was claimed and done with no problem.  hmmm.
<Ursinha> bac, I saw that the link works fine, but that error seems odd
<Ursinha> bac, I'll ask a code person, but thanks!
<bac> Ursinha: thanks for asking
<Ursinha> bac, no problem!
<james_w> hi Ursinha, did you ever find my oops yesterday?
<Ursinha> james_w, I'm trying to find a message I sent to the channel yesterday
<Ursinha> james_w, asking you if that was the right oops id, because I couldn't find it
<james_w> oh, sorry I missed it
<Ursinha> james_w, ah, no problem, my connection could be the culprit as well
<Ursinha> james_w, anyway, did you copied/pasted that id?
<james_w> yeah
<Ursinha> james_w, ah, were you doing soyuz related stuff when that happened
<Ursinha> ?
<james_w> correct
<james_w> with the API
<Ursinha> I recall a bug that something in soyuz wasn't recording oopses
<Ursinha> I'm trying to find it
<Ursinha> james_w, bug 499423
<mup> Bug #499423: No oopses recorded for upload processor <Soyuz:Fix Committed by michael.nelson> <https://launchpad.net/bugs/499423>
<Ursinha> james_w, does that relate to what you're doing?
<james_w> I don't think so
<james_w> this was just an API call to get data from the db
<james_w> OOPS-1466EC775 is another from around the same time
<Ursinha> let me check
<Ursinha> matsubara, the oops needs to be processed by the db oops tools to be found at lp-oops.canonical.com/oops.py/?oopsid=OOPS-1466EC775 ?
<matsubara> nope
<matsubara> Ursinha, ^
<Ursinha> james_w, both oopses were generated on 4th?
<james_w> yeah
<Ursinha> that's why then
<james_w> only one is stored per-traceback per-day?
<Ursinha> matsubara, is there a way to see the oopses besides that one?
<Ursinha> james_w, we had an issue with oops-tools yesterday due to an enormous amount of oopses on staging
<Ursinha> james_w, it couldn't process all of them in a reasonable time
<james_w> ah, ok
<matsubara> Ursinha, search the logs on devpad
<james_w> I'm pretty sure the other oops will be the same, so if the reason is known why it disappeared then I don't think we need to look much more
<james_w> are the bugs associated with oopses done manually or automatically?
<Ursinha> james_w, manually in a first place, we add the numbers as we're doing triage
<james_w> because the bug linked to 1466EC775 doesn't sound right to me
<Ursinha> james_w, and  then when oops-tools processes the summaries the next time it considers the linking
<sinzui> Chex: ping
<Ursinha> matsubara, mind explaining how it works in detail to james_w and why the linking isn't that precise?
<Ursinha> matsubara, I'll have to run oops-tools-db to process all the 4th oopses, will suspend cron entries until it's not finished
<matsubara> james_w, we consider the exception type and exception value to generate a signature for an oops. we link a signature to a bug report manually. if later on an oops show up with the same signature it'll show up linked to the bug. problem with timeout errors is that the signature generated is misleading.
<matsubara> we need to consider other things (e.g. like the pageid) into the signature to make the signature -> bug link more reliable.
<matsubara> Ursinha, ok
<james_w> makes sense, thanks
<bigjools> jelmer: ping
<jelmer> bigjools: pong
<bigjools> jelmer: how is that cheery pick branch going?
<bigjools> cherry!
<jelmer> Oh, right! Tests seem to pass so I'll pqm submit.
<sinzui> Chex: mthaddon: ping
<mthaddon> sinzui: losa ping is a much better way to go
<sinzui> mthaddon: I certainly will use that in the future.
<mthaddon> thx
<sinzui> mthaddon: Do you know why edge is not updating?
<^Willie^> hi there
<^Willie^> any idea where i must goto for freenx problems ?
<mrevell> night!
<mwhudson> morning
<bigjools> thumper: around?
<thumper> bigjools: aye
<bigjools> coolio, first, happy new year!
<bigjools> second, how's the build from recipe stuff coming along?
<thumper> bigjools: skype?
<thumper> bigjools: I could put off jml for a few minutes
<thumper> bigjools: since it is your evening :)
<bigjools> I can't, my headphones are in my office outside :)
<bigjools> or you can phone my home number?
<thumper> bigjools: it is coming along, mwhudson is working on it
<thumper> bigjools: I can call your home :)
<mwhudson> slower than i would like but oh well
<james_w> spm: have a few minutes for me?
<james_w> I'd like to ask about graphs
<bac> sinzui: you have a few minutes for a quick pre-imp call?
<sinzui> i do
<bac> sinzui: sorry.  try again?
<sinzui> yes
<mwhudson> yay for forgetting to plug my laptop back in, for power management being busticated so no software noticed and then for fsck
<spm> james_w: sure, shoot
<james_w> spm: I'd like to graph some things about the bzr import service on jubany
<james_w> one of them is an LP db query, but the rest of the info doesn't live in the LP db
<james_w> what do I have to put in an RT request to allow such data to be graphed?
<spm> the 1st is easy - I'll show you where/how to set that up; the latter can be harder.
<james_w> are names of scripts that spit out numbers sufficient?
<spm> start with as much detail as you can. we can work out who does what from there.
<spm> more or less. we prefer the results in cricket format; but can wrapper a converter if needed
<spm> james_w: eg None_localhost_disk_partition_pct_/:17@1226983004 <== name, sensible alpha format for ease of finding == win; value (17) and the timestamp
<james_w> the data lives in sqlite now, which makes it much more accessible than before
<spm> ahh, very helpful
<james_w> I'm not sure what that means, but hopefully cricket does :-)
<james_w> spm: do you have a link on interpreting that format so that I can write a script to output it?
<spm> james_w: hrm. well the fields are: <name>:<value>@<timestamp>
<james_w> ah, easy enough
<spm> just trying to find an example script for you...
<james_w> and can we don multiple lines of that?
<james_w> do, I'm not suggesting you wear the output as an outlandish garment
<spm> hahaha
<spm> yes :-)
<spm> my home dir on chinstrap snmp_stats.tgz should give you a script you can point at any snmp service for the idea
<james_w> thanks
 * jml afk
<james_w> anyone interested in LP apparently giving up in the middle of writing data back to the client?
<james_w> I've caught it in the act with the API
<thumper> :-|
<james_w> it seems to happen frequently with the API, but I don't get it with the webapp that I have noticed
<thumper> james_w: foundations would be
<james_w> it may be an order of magnitude thing
<thumper> james_w: file a bug
<james_w> well, I mean I have the response in pdb
<james_w> so if someone wanted me to get certain data this would be a great chance to do so
<thumper> heh
<thumper> umm...
<thumper> flacoste: ping ^^^
#launchpad-dev 2010-01-07
<james_w> damn, got confused between pdb and ipython and lost it
<james_w> I'll wait for it to happen again
 * mwhudson lunches
 * thumper walks up the road to get real coffee
<poolie> jml/thumper: can i run a possibly weird idea past you
<poolie> that is to do with displaying permissions to users in the web ui
<poolie> there was both a bug and a list post today with people failing to understand what permission is needed to do or change a particular thing
<poolie> now in theory this knowledge is in the lp code in a structured form
<poolie> can it be interrogated so that we could show it as text in some way in the web ui?
<mwhudson> poolie: it's not very structured in the lp code, and it's of the form "can person Y do thing Z"
<poolie> so you can't find out "who can do Z"?
<mwhudson> poolie: there's nothing that can answer "what is the set of the people who can do Z"
<mwhudson> right
<poolie> :/
<poolie> really what you want is
<mwhudson> it would perhaps not be super hard to add
<poolie> "Z can be done by project_owner which is currently ~bzr"
<poolie> etc
<poolie> i don't know if it's the most pressing problem
<poolie> but it does crop up in a lot of places
<mwhudson> launchpad is made of pressing problems :)
<poolie> :)
<mwhudson> the way security works in launchpad is there's a mapping from pairs (interface, permission) to objects which implement a particular interface
<mwhudson> this interface just has two methods (i think) "can the anonymous user do this" "can this particular user do this"
<mwhudson> you could add another method "describe the people who can do this"
<poolie> do the interfaces have names?
<poolie> at least in the code
<mwhudson> and i guess it would mostly be a matter of boring typing to add all this information
<poolie> actually what i mean is, are these all different instances of the same class, or are there different implementations of this interface?
<mwhudson> the interface with the methods is called IAuthorization and there are many many implementations
<mwhudson> in lib/canonical/launchpad/security.py
<mwhudson> (which is a gem of a file)
<poolie> i wonder if you could even just print the repr or classname?
<poolie> as the crudest thing that could possibly help
<mwhudson> http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/annotate/head%3A/lib/canonical/launchpad/security.py
<poolie> mm, i'm looking
<poolie> i have a copy of the code
<mwhudson> i guess you could
<poolie> i realize that would seem a bit messy
<poolie> so you probably wouldn't want to show it in every context
<poolie> but it would actually get people a bit unstuck
<mwhudson> well, you have another fun thing i guess which is that if you can't do something, you don't get shown the link that lets you do it at all
 * jml is behind a crappy internet connection
<mwhudson> jml: how's your use-testtools branch doing?
<jml> mwhudson, it's where it was yesterday.
<mwhudson> jml: :(
<jml> mwhudson, otoh I had a pleasant evening in the company of friends
<thumper> jml: how does "Launchpad - what is it and who uses it?" sound for an overview talk name?
<jml> mwhudson, so it kind of evens out.
<mwhudson> jml: :)
<mwhudson> sodding wifi
<jml> thumper, pretty good, although a little uninspiring
<thumper> jml: so give me something inspiring
<jml> thumper, I'm thinking.
<jml> thumper, "Why Launchpad?"
<thumper> as an overview talk name?
<thumper> sounds OK
<thumper> I'm trying to put together the draft schedule
<thumper> to email out shortly
<thumper> we can tweak talk names
<jml> thumper, +1
 * mwhudson afk for a bit
<jml> fjlacoste, hello.
 * thumper EODs
<jml> I'm getting errors about ampoule not being able to be imported
<jml> "run buildout" is the answer.
<jml> mwhudson, I'm running the use-testtools branch through ec2 test again
<jml> mwhudson, it won't fix all of the errors, but it should have many, many less of them.
<jml> g'night all
<al-maisan> good night jml
<spiv> Hmm, I'm getting 404 for https://edge.launchpad.net/+icing/rev10123/combo.css
<spiv> It's novel looking at LP without CSS...
<mthaddon> spiv: see above - can you help figure out why it's doing that?
<mthaddon> I've reverted to the old CSS for the moment, but there may be subtle breakage
<mthaddon> i.e. we're using CSS from 10081, code from 10123
<noodles775> mthaddon: can we revert the edge rollout for the moment? I'm still trying to find out why pydoc2.4 is being called.
<mthaddon> noodles775: see above - reverting the whole rollout is fairly involved, but I've reverted the CSS
<noodles775> mthaddon: sourcecode/pygettextpo/Makefile
<noodles775> It seems when that makefile is being run, PYTHON_VERSION=2.4?
<mthaddon> noodles775: and why does make static have anything to do with that?
<noodles775> mthaddon: no idea - I was just looking for why that specific error was occurring, but it could be that other things are being run with 2.4 too (but that's just guesswork).
<noodles775> mthaddon: scratch that - I just looked at the actual pygettextpo/Makefile - it's explicitly setting 2.4 for some reason.
<noodles775> mthaddon: so it's actually line 858 where make static is failing...
<mthaddon> noodles775: of which file?
<noodles775> your first paste.
<stub> Doesn't that get overridden on the command line from the sourcecode/Makefile?
<mthaddon> noodles775: yep, I know there's something wrong with "make static" - question is, what
<mthaddon> noodles775: fwiw, it looks like we're getting the same error on all servers - so it seems to be a general problem with make build, not just make static
<mthaddon> noodles775: scratch that, no, I think it's only make static
<noodles775> mthaddon: have you tried running make static on a local checkout? I get: /usr/bin/python2.5: can't open file 'scripts/make-static.py': [Errno 2] No such file or directory
<noodles775> make: *** [static] Error 2
<mthaddon> noodles775: have you done a make build first?
<noodles775> mthaddon: yarp.
<mthaddon> hmm, I don't see a make-static.py either
<mthaddon> but it's definitely in the production branch
<mthaddon> er, edge branch, I mean
<mthaddon> noodles775: er, actually, it's not...
<noodles775> OK, that's progress :)
<mthaddon> yarp
<noodles775> mthaddon: what was the previous version that was running on edge? (just so I know how far back to look)
<mthaddon> noodles775: 10081
<mthaddon> noodles775: making any progress?
<noodles775> mthaddon: I've been through all the commit messages back to 10081 and can't see anything relevant... a new bzr version, but that's it (and I don't see how that would affect this).
<mthaddon> noodles775: can you figure out which revision removed make-static.py?
<noodles775> mthaddon: I'm confused about make-static.py - I can't see it mentioned in the log of scripts...
<noodles775> BjornT: Are you around? If so, you might be able to shed some light on the above?
<mrevell> Morning all
<noodles775> Morning mrevell
<BjornT> noodles775: no, i'm not around, i'm getting ready for the trip to nz. the issue you mention doesn't ring any bells
<noodles775> BjornT: We found the issue, thanks for letting me know, and I'll see you in a few days!
<noodles775> (for anyone interested, the losa's hadn't been notified that the deployment script would need to do a 'make css_combine' instead of the old 'make static', as I understand it.
<james_w> was there an edge rollout last night?
<noodles775> james_w: yes there was, but there were some issues with the css styles, so currently it's using an older stylesheet.
<james_w> I don't care about the stylesheet ;-)
<noodles775> Great :)
<james_w> thanks
<james_w> could someone submit https://code.edge.launchpad.net/~james-w/launchpad/sync-source-negative-versions/+merge/16861 for me please?
<james_w> assuming that it wasn't that gmb did and it was rejected or similar
<mrevell> en/nick mrevell-luncheon
<gmb> james_w: Er... that should have been submitted.
 * gmb really hopes that hasn't been in ec2 for 24 hours...
<gmb> I'll check
<james_w> thanks
<gmb> james_w: Well, it's not running; it just appears to have vanished. I'll run it again.
<james_w> thanks
<gmb> james_w: Running now.
<Ursinha> sinzui, hi! Are the GoneError oopses real oopses or should we remove them from the exception section of the summaries?
<Ursinha> sinzui, https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1467S201 , an example
<sinzui> Ursinha: The are like 404s. They are not application errors. They are people visiting suspended user pages
<Ursinha> sinzui, I thought so, but wanted to confirm. I'll talk to matsubara about it, thanks
<EdwinGrubbs> leonardr: ping
<leonardr> edwingrubbs, hi
<EdwinGrubbs> leonardr: I was wondering if you were familiar with any problem in either launchpadlib or lazr.restful that would cause named operations to be ignored. I've put in a bunch of debug points, and the ws.op exists on the request side but disappears on the server side.
<leonardr> edwingrubbs: does it show up in the wadl document? and what is the response when you invoke the operation?
<EdwinGrubbs> leonardr: I know it shows up in the wadl, since launchpadlib gives me an error when I don't provide the right parameter name. When I run it with the right parameter name, I just get back the json representation of the object.
<leonardr> and on the server side, where does 'ws.op' disappear?
<EdwinGrubbs> leonardr: I'm not sure. It's already gone by do_POST().
<Ursinha> stub, Chex, rockstar, noodles775, jtv, sinzui, allenap: Prod. meeting in 20 mins in #launchpad-meeting @ Freenode
<Ursinha> anyone willing to represent foundations?
<allenap> Ursinha: Gah, I won't be here. I'll ask someone else to represent bugs. intellectronica, would you be able to cover for me?
<intellectronica> allenap, Ursinha: sure
<Ursinha> thanks allenap and intellectronica
<allenap> intellectronica: Thank you :)
<leonardr> edwingrubbs: put a debug point in ReadWriteResource.__call__ and check on self.request.form.get('ws.op') in there
<sinzui> Ursinha: The meeting was moved to 16:00 UTC.
<Ursinha> #*&*$&%
<Ursinha> indeed
<sinzui> Ursinha: The team leads meeting is a 15:00 UTC
<Ursinha> sinzui, thanks
<EdwinGrubbs> leonardr: by the time ReadWriteResource gets the form, it's empty.
<Ursinha> so: stub, Chex, rockstar, noodles775, sinzui, intellectronica: Prod. meeting in 1h10 mins #launchpad-meeting @ Freenode
<EdwinGrubbs> leonardr: I discovered the error. I was trying to call launchpad.me.join(team=guadamen). It works with launchpad.people['no-priv'].join(team=guadamen), so I guess it was losing the args in some sort of redirect.
<leonardr> aha
<intellectronica> Ursinha: thanks for the update. by then allenap might be back. either way one of us will join
<leonardr> edwingrubbs: that's the downside of delayed binding
<EdwinGrubbs> leonardr: do you want me to open a bug for that?
<leonardr> i don't know if there's anything we can do...
<leonardr> the http standard says if you POST and get a redirect, you should not re-POST without user confirmation
<leonardr> but yeah, open a bug and i'll figure it out later
<EdwinGrubbs> ok
<allenap> intellectronica: I'm back so I'll do the meeting. Thanks anyway.
<Ursinha> salgado-lunch, leonardr, I'd appreciate to have a foundations person joining the prod. meeting in 40 minutes, if possible :)
<leonardr> ursinha: i'll join if it's understood that i'll have absolutely no idea what you're talking about
<Ursinha> leonardr, :) there is a weekly production meeting, a contact of each team is supposed to be there to represent it
<salgado> Ursinha, I'm about to start a call with flacoste.  if I finish before the meeting, I could join too
<Ursinha> salgado, the meeting is in 30 mins
<flacoste> salgado: you'll be done, i have a call with IS at that time
<Ursinha> good :)
<leonardr> i think salgado would be a better choice
<Ursinha> leonardr, that's ok, but thanks anyway
<bac> hi leonardr -- i just noticed the cache and credential in ~/.launchpadlib are in different places now (http://pastebin.ubuntu.com/352974/).  was this intended?
<leonardr> let me see
<bac> leonardr: specifically, the cached stuff is no longer in the 'cache' subdirectory
<bac> leonardr: and credentials is now a subdirectory of cache.  very confusing
<bac> leonardr: the layout shown was just created from scratch using the tool version in launchpad devel
<leonardr> that looks like a snafu
<bac> is that worse than a fubar?
<leonardr> no, a fubar would be worse
<bac> ah
<leonardr> i'm looking into it now
<bac> leonardr: thanks!
<salgado> Ursinha, do I have to say anything besides "me" when the meeting starts?
<Ursinha> salgado, no, unless asked :)
<Ursinha> (and you will :P)
<Ursinha> stub, Chex, rockstar, noodles775, sinzui, allenap, salgado: Prod. meeting in 7 mins in #launchpad-meeting @ Freenode
<beuno> thumper, rockstar, abentley, I don't know which of ypou implemented de "related merge proposals" bit in the commit emails, but it's super nice, thank you
<abentley> beuno: You're welcome.
<Ursinha> stub, Chex, rockstar, noodles775, sinzui, allenap, salgado: Prod. meeting now in #launchpad-meeting @ Freenode
<jtv> adiroiban: you still need to create that translations export branch...  I wouldn't wait for us to start doing that automatically.
<adiroiban> jtv: sure. np
<adiroiban> jtv: still strugling with adapters and delegates
<jtv> adiroiban: just registering the adapter didn't create the URLs for you?
<adiroiban> jtv: I don't know how to register it. I have removed the IHasTranslation interface from IProductPublic
<jtv> adiroiban: (sorry for absence; some brush fires)
<jtv> adiroiban: if you look for "adapter" in lib/lp/translations/configure.zcml, you'll see how to register one.  It's pretty simple.
<leonardr> bac, can you tell me launchpadlib.__version__?
<bac> leonardr: 1.5.4
<bac> '/home/bac/canonical/lp-sourcedeps/eggs/launchpadlib-1.5.4-py2.5.egg/launchpadlib/__init__.pyc'
<leonardr> bac: ok, can i also have the code you're using to get credentials?
<bac> leonardr: i'm just using login_with
<jtv> adiroiban: aiui the "factory" is something that gets called to produce an ITranslationPolicy-implementing object from e.g. an IProduct-implementing object.  We use the class itself as the factory, so that just means "construct an object of this class."
<leonardr> bac: i'm asking you seemingly trivial questions because i can't duplicate the problem. what's your login_with call look like?
<jtv> adiroiban: so you'd say something like,
<jtv> <adapter factory="lp.translations.browser.TranslationsPolicy" provides="lp.translations.interfaces.ITranslationsPolicy" for="lp.registry.interfaces.product.IProduct" trusted="yes"/>
<adiroiban> jtv: sorry for the  delay. Right now, I am attenting the Ubuntu translation meeting
<bac> leonardr: lp = Launchpad.login_with('interactive', 'dev')
<jtv> adiroiban: ah, I'm in the launchpad production meeting.  :)
<adiroiban> jtv: i see. thanks! :)
<bac> leonardr: let me investigate some more
<bac> leonardr: i do recall now i made one tiny, "innocuous" change to the launchpadlib.launchpad in that egg to get login_with to work.  seems there was a bug regarding aliased service_roots
<bac> leonardr: i removed the changes i made to launchpadlib's egg and now definitely have the released 1.5.4.
<bac> leonardr: here is a transcript to reproduce the problem: http://pastebin.ubuntu.com/352999/
<adiroiban> jtv: there is already an adapter for lp.registry.interfaces.product.IProduct
<jtv> adiroiban: providing IHasTranslationGroup?
<adiroiban> jtv: no. but right now I don't understand how those configuration are used in Zope/LP
<adiroiban> so I still need to do more reading
<jtv> adiroiban: it's a bit of a black art to me as well, but the zcml basically tells zope how the views, interfaces, and templates combine and what URL goes where.  In principle, I think registering an adapter for IProduct providing IHasTranslationGroup should tell it enough to know that a +changetranslators can go at the end of a URL for a product.
<adiroiban> jtv: as I start I tried to understand these slides http://rhodesmill.org/brandon/adapters/
<adiroiban> do you know other generic documentation/examples
<jtv> adiroiban: only the ones in LP, really
<intellectronica> allenap: call?
<allenap> intellectronica: Yes. Do you have your headset, or shall I ring on the mobile?
<intellectronica> allenap: i have my new fancy headset, so let's try skype
<allenap> intellectronica: Right, I think we covered everything there. Pub?
<adiroiban> jtv: how factory="lp.translations.browser.TranslationsPolicy" should be implemented?
<jtv> adiroiban: well in this case (and afaik for all other adapters we have) the factory is the class!
<adiroiban> jtv: sorry for all these dumb questions. maybe I should leave this bug to be fixed by someone else and then try to understand the solution
<jtv> adiroiban: as I understand the logic, a factory is anything that zope can call, passing in an (in this case) IProduct as a parameter, to get (in this case) an IHasTranslationGroup (or ITranslationPolicy once we rename it).
<jtv> What happens in Python when you get a reference to a class, and you try to "call" it?  You get the constructor.
<jtv> So the factory is simply TranslationPolicy.__init__
<maxb> __init__ isn't really a constructor
<jtv> maybe my C++ background is showing here :)
<maxb> The thing which is callable to create a new instance is the class itself. i.e. TranslationPolicy not TranslationPolicy.__init__
<jtv> maxb: thank you, much clearer than I could say it
<jtv> adiroiban: what that zcml line I showed you says is really, "if you have an IProduct p and you want to create an IHasTranslationGroup, you get it by doing TranslationPolicy(p)"
<jtv> adiroiban: once you have that zcml line, in the code you'll be able to do simply IHasTranslationGroup(p) to get an IHasTranslationGroup that "wraps" p.
<adiroiban> jtv: this is my TranslationPolicy
<adiroiban> http://paste.ubuntu.com/353015/
<jtv> adiroiban: that looks fine... the __init__ you have there implements the "wrapping" of whatever "context" is such that it implements ITranslationPolicy.
<adiroiban> things are more complicated
<adiroiban> http://paste.ubuntu.com/353013/
<adiroiban> this is what I get when trying to access a product
<jtv> argh, I hate zope tracebacks
<jtv> but I think it may not be so complicated in principle...
<jtv> +portlet-translation-groups-and-permission obviously tries to display the product's translation group & access model.
<jtv> But you just took those out of the IProduct interface.
<jtv> ah, it's already working on IHasTranslationGroup
<jtv> adiroiban: I guess this means that we now suddenly have 2 browser:page entries for IHasTranslationGroup
<jtv> Wouldn't expect that to be a problem though...
<jtv> adiroiban: I guess you renamed IHasTranslationGroup to ITranslationPolicy already, even in the zcml?
<adiroiban> yes
<jtv> adiroiban: I could imagine there being a problem because the portlet also wants to access information that's in IProduct but not in ITranslationPolicy (it probably does, come to think of it) but I wouldn't expect the error to look like this.
<jtv> Maybe sinzui knows.
<jtv> sinzui, would you be able to help adi with this?
<sinzui> jtv: adiroiban: I am not very familiar with this error. I agree that this looks like an object has the same named adapter (view) for two interfaces. I think this can be solved by only specifing the name for specific interfaces instead of the general interfaces to ensure there is no overlap
<sinzui> I do not know which interfaces are specific in this case.
<jtv> sinzui: one basic question I wasn't sure about: if we register an adapter from IProduct to IFoo, and we have a page for IFoo with name '+foo', is that enough to create a page <canonical_url(product) + '/+foo' ?
<jtv> adiroiban: btw it may be useful to run "make harness" and ensure that ITranslationPolicy(my_product) gives you a working TranslationPolicy.
<adiroiban> jtv: hm... ITranslationPolicy(my_product) or TranslationPolicy(my_product) ?
<adiroiban> i went for TranslationPolicy(my_product)
<sinzui> https://edge.launchpad.net/people claims there more than 1 million registered users in launchpad. I suspect that is a lie, but cannot prove it
<adiroiban> jtv1: this is what I got http://paste.ubuntu.com/353037/
<jtv1> adiroiban: you should construct it as ITranslationInterface(product), not TranslationInterface(product)
<jtv1> The former goes through your adapter; the latter just goes straight to TranslationPolicy.__init__
<jtv1> (sorry typo; it's Friday here :)
<adiroiban> jtv: tried with ITranslationPolicy ... but same error
<jtv> adiroiban: maybe you also need an implements(ITranslationPolicy) in TranslationPolicy.
<jtv> What surprises me is that TranslationPolicy _is_ getting an unproxied Product (the effect of the trusted="yes" in the zcml, something flacoste suggested) and yet we get this error...  it's not a missing underscore in translationpermission or anything silly like that?
<jtv> I mean, there still is a Product.translationpermission, right?
<jtv> very annoying: nonexistent attributes and non-allowed ones give you the exact same error
<adiroiban> >>> new_product.nonexistentattibute
<adiroiban> Traceback (most recent call last): File "<console>", line 1, in <module>
<adiroiban> AttributeError: 'TranslationPolicy' object has no attribute 'nonexistentattibute'
<jtv> ah, but that's differentâit's not getting delegated to Product
<mrevell> night
<jtv> Someone 5 timezones behind me just said "night" and left.  Maybe I should do the same.
<adiroiban> jtv: that's sign
<jtv> no, 7 timezones
<adiroiban> jtv: don't worry, we can dig into this problem tomorrow
<jtv> adiroiban: you didn't remove Product.translationpermission or anything, did you?
<jtv> owww, ah!
<adiroiban> jtv: well... I removed the interface
<adiroiban> so it is no longer inherited
<jtv> adiroiban: you may need to specify in zcml that ITranslationPolicy is allowed for a Product or something along those lines...
<jtv> no, that doesn't make sense
<adiroiban> jtv: I think that part is implemented. This is the part http://paste.ubuntu.com/353044/
<jtv> lib/lp/translations/configure.zcml may have to say <class class="lp....TranslationPolicy"><allow interface="lp....ITranslationPolicy"></class>
<jtv> so new <class> entry for your new class.
<jtv> (a much simpler version of what you show for Project here)
<jtv> adiroiban: I'm really going now.  Good night, talk to you tomorrow!
<adiroiban> jtv: good night. Thanks for your support!
<jtv> thanks for working on it, hope you'll find it all worthwhile in the end :)
<sinzui> EdwinGrubbs: I thought bac was also working on Bug 451208
<mup> Bug #451208: email address revealed when subscribing someone else to a bug <Launchpad Registry:In Progress by edwin-grubbs> <https://launchpad.net/bugs/451208>
<bac> sinzui: not yet
<bac> sinzui: it was my plan
<bac> but i hadn't claimed it
<sinzui> okay, then all is well because EdwinGrubbs took it
<EdwinGrubbs> sinzui, bac: oops, I haven't done anything, so you can have it if you'd like.
<sinzui> bac: I have been a bad engineer. Instead of making my ubuntu-link-upstream mockups this morning, I suspend about 300 spammers
<bac> EdwinGrubbs: i'm indifferent.  i'll take it if there is something else you'd like to do
<sinzui> EdwinGrubbs: take the bug.
<EdwinGrubbs> I'll keep it
<sinzui> salgado: ping
<salgado> hi sinzui
<sinzui> salgado: does the process that removed shipit users from launchpad keep the person entry in the db?
<salgado> sinzui, that's exactly what it was supposed to remove
<sinzui> salgado:  oh
<sinzui> salgado: /people says we have more than 1 million registered launchpad users. Even though it is included deactivated and suspended accounts, I suppose that number is pretty close.
<salgado> lpmain_staging=> select count(*) from person where teamowner is null;
<salgado>  count
<salgado> --------
<salgado>  987760
<salgado> (1 row)
<sinzui> interesting. you did not discount merged, and you number is much lower than the number on https://edge.launchpad.net/people
<salgado> that's weird.  maybe the spammers are hitting us hard since the last db restore on staging
<sinzui> I considered that, I was investigating, mail.ru which has 1000 registrants in the last 60 days, but they look good
<sinzui> salgado: I do not see a spike in registrants. I think the staging data is older than the code.
<thumper> morning
<flacoste> hi thumper
<thumper> flacoste: hi, just finishing up with the stand up
<thumper> flacoste: yes?
<flacoste> thumper: nothing, was just saying hi :-)
<thumper> hah
<thumper> hi
<Edwin-lunch> sinzui, bac: bug 504446 looks like just another instance of the problem where assertProperty() needs to be changed to waits.forElementProperty() to become less fragile.
<mup> Bug #504446: Spurious failures in test_project_licenses <spurious-test-failure> <Launchpad Registry:Triaged by edwin-grubbs> <https://launchpad.net/bugs/504446>
<sinzui> ^ thumper, rockstar: Edwins's look into the registry bugs may be relevant to your bugs.
<rockstar> Edwin-lunch, that might very well be the issue.
<thumper> sinzui: ah, thanks
<sinzui> Edwin-lunch: bac: I suggest the two of you have a pre-imp call about both windmill tests. Bac can make all the changes and Edwin-lunch can review them. I will be the fixer next time and bac can be the reviewer
<al-maisan> hmm .. I am running "utilities/ec2 test" and at this point I am being prompted for a key:
<al-maisan> ec2test@i-b17a52d9$ bzr branch bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel /var/launchpad/test
<al-maisan> what password/key is required here?
<al-maisan> I tried several ssh key passwords and none would work..
<bac> al-maisan: are you using the option to land the branch?  -s i think?
<al-maisan> bac: yes
<bac> that should be your GPG passphrase
<al-maisan> ah
<al-maisan> will try that
<rockstar> al-maisan, does your ssh key that you use to connect to Launchpad have a passphrase?
<al-maisan> thanks bac
<bac> ec2 has to sign it for you to send to PQM
<rockstar> bac, it looks like he's launched ec2 already.
<al-maisan> rockstar: that's right ec2 is launched already
<rockstar> al-maisan, so it shouldn't be your gpg key.  I'm wondering if it's trying to use an ssh key it got from you.
<al-maisan> rockstar: http://pastebin.ubuntu.com/353116/
<al-maisan> rockstar: what does " it got from you." mean?
<rockstar> al-maisan, I'm wondering if part of the script uploads your private key to the ec2 instance.
<rockstar> al-maisan, it's trying to make an ssh connection to bazaar.launchpad.net
<al-maisan> rockstar: yes, the password it asks for is for a private key
<mwhudson> rockstar: no
<mwhudson> it uses agent forwarding
<al-maisan> that's what the prompt says at least
<rockstar> mwhudson, ah, okay.
<rockstar> mwhudson, so why is it asking for a passphrase?
<mwhudson> al-maisan: there are two ssh auths going on in this line
<mwhudson> al-maisan: the connection to the ec2 instance
<mwhudson> al-maisan: and the connection from there to launchpad
<al-maisan> I see.
<al-maisan> I guess it is the latter that;s at stake here
<mwhudson> maybe
<mwhudson> al-maisan: somewhere not far back in the output it will be saying "you can now use ssh -A ec2test@blah to log in to the instance"
<mwhudson> al-maisan: can you try that line?
<al-maisan> I am being blocked by a modal dialog
<al-maisan> Here's what the latter says: "Title : unlock private key"
<al-maisan> Body: An application wants access to prvate key <whatever> but is locked
<al-maisan> now I am getting one of these: "IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!"
<al-maisan> please see: http://pastebin.ubuntu.com/353122/
 * al-maisan needs to stop and go through the all-important airport security checks now
<al-maisan> Good night!
<mwhudson> al-maisan: good night
<EdwinGrubbs> sinzui: do you know what would prevent getUtility() from applying a security wrapper?
<mwhudson> EdwinGrubbs: is it registered as a securedutility?
<sinzui> EdwinGrubbs: getUtility uses the rules specified in zcml: <utility> or <securedutility>
<EdwinGrubbs> sinzui: it's a vocabulary, and it looks like all vocabularies are registered with <utility> instead of <securedutility>. Is there a reason for that?
<sinzui> EdwinGrubbs: I do not know of one.
<sinzui> EdwinGrubbs: it is in lp/registry/vocabularies.zcml ?
<EdwinGrubbs> sinzui: yes
<sinzui> I Extracted those from the launchpad zcml. It was a simple move operation
<EdwinGrubbs> sinzui: since the picker uses a view which exposes huge vocabularies, I really need them all the be securedutilities. I guess I should send out an email before I do anything that widespread.
<sinzui> EdwinGrubbs: agreed. flacoste, BjornT, and gary may have some insight into the issue
<sinzui> EdwinGrubbs: ValidPerson and ValidTeam are the issue here?
<flacoste> EdwinGrubbs: why do you need a securedutility?
<flacoste> securedutility is a LP addition
<flacoste> which makes sure the utility is security wrapped
<flacoste> in the end, it shouldn't matter much
<sinzui> flacoste: we do not want to to show user email addresses if the user set them hidden
<flacoste> then do it
<EdwinGrubbs> ok
<sinzui> EdwinGrubbs: When I search for barry to assign bugs to him, I expect to see his full name, and <email address hidden>  instead of his email address
<EdwinGrubbs> ok
<EdwinGrubbs> bac: how did you go about hiding the name of private teams?
<sinzui> EdwinGrubbs: if you try to access it, without privilege, it returns <name hidden>
<bac> EdwinGrubbs: look at TeamFormatterAPI
<sinzui> EdwinGrubbs: use team/displayname/fmt:displayname
<EdwinGrubbs> sinzui: hmm, I'm not sure if it would be worthwhile to do something like that for email addresses, since they are displayed that often in templates.
<sinzui> EdwinGrubbs: we do not seem to have a problem anywhere but here and in merge
<EdwinGrubbs> flacoste: do you foresee any problems with using securedutility for all the vocabularies, since the view the picker uses exposes all huge vocabularies?
<flacoste> EdwinGrubbs: no, i don't
<EdwinGrubbs> cool
<flacoste> EdwinGrubbs: well, you might have a few test failures, but nothing serious
<sinzui> EdwinGrubbs: In there profile page, there is an adapter view adapter that determines if th user can see the address and provides the list that can be seeen
<EdwinGrubbs> sinzui: are you just talking about the view.visible_email_addresses attribute? I saw that. I could move that into a real adapter to make it easy to use outside of that view.
<sinzui> EdwinGrubbs: Certainly if it helps to other parts of the code. It may be over engineers for other parts of launchpad. the profile page rules were difficult to test when it was written in tales
 * thumper heading for coffee
<wgrant> Can somebody please copy egenix-mx-base in lucid from wgrant/launchpad to launchpad/ppa? There's a new version in the primary archive that needs to be clobbered.
<mwhudson> jml: hello
<jml> mwhudson, hi
<mwhudson> jml: have a moment for a call?
<mwhudson> sort of mid-imp call i guess
<jml> mwhudson, after my call w/ beuno, sure.
<mwhudson> jml: when is that? ongoing?
<jml> mwhudson, yeah.
<mwhudson> jml: ok, ping me when you're done?
<jml> mwhudson, will do.
<mwhudson> thanks
<jml> mwhudson, ping
<mwhudson> jml: hi
<jml> mwhudson, is now good?
<mwhudson> jml: having said the above
<mwhudson> jml: would 30 mins or so be ok with you?
<jml> mwhudson, yeah, that'd be fine.
<mwhudson> cool
<jml> better even.
 * mwhudson afk to go and shout at dick smith's for sending emma the wrong hard drive
<mwhudson> (sadly, they sent us the $140 one when she paid $220, i guess if it was the other way around...)
<wgrant> That's what you get for buying hardware from such places...
<jml> sql ninjas?
<jml> if I'm doing a query, how can I map the enum integer to a human-readable name?
<thumper> jml: case??
<jml> thumper, got it...
<jml> thumper, http://paste.ubuntu.com/353199/
<thumper> jml: why not use the branch.prefix thingy?
<jml> thumper, branch.prefix thingy?
<thumper> target_suffix
<thumper> instead of product.name or package.name
 * thumper shrugs
<thumper> whatever
<jml> thumper, because I need to get the upstream product corresponding to the sourcepackage anyway
#launchpad-dev 2010-01-08
<mwhudson> jml: hello again
<jml> mwhudson, hi
<mwhudson> jml: call?
<jml> mwhudson, I'll just finish replying to this email
<mwhudson> jml: ok
<mwhudson> i promise not to rush off to shout at incompetent retailers for at least a few minutes
<MTeck-Linux> mwhudson: sounds like fun...
<mwhudson> otoh, i do need to phone my isp today
<wgrant> Hmm. This 410 Gone stuff is killing some of my scripts.
<wgrant> (some uploads by people appear to have deactivated themselves)
<wgrant> s/appear/that appear/
<wgrant> jml: What are your flights to Wellington?
<jml> wgrant, qf 47
<jml> wgrant, I think I'll be arriving some hours before you.
<wgrant> Ah, yes, the early one.
<wgrant> QF117 gets in at something crazy like 2315.
 * thumper goes to pack
<jml> mwhudson, does ec2 land run the script in-process now?
<mwhudson> jml: i haven't done anything in that direction
<jml> maybe I'm just being a bit silly
<mwhudson> jml: hey, use-testtools ping
<jml> mwhudson, progress has been made
<mwhudson> jml: hooray
<jml> mwhudson, I've got a separate branch that fixes all of the upcalls
<jml> mwhudson, I'm just verifying it now.
<spm> jml: for a *very* brief period I read that as "I've got a separate branch that fixes all bugs"<period>. I was briefly elated and then reality kicked in. :-)
<jml> spm, I didn't have that much time over the holidays :)
<spm> jml: shame...
<jml> mwhudson, I'm going to merge in the upcall branch and the fix-import-warnings branch and give the use-testtools branch another spin on the ec2 test wheel
<mwhudson> jml: groovy
<mwhudson> i guess i'm going to stop for the day soon
<jml> mwhudson, thanks for the reviews
<jml> mwhudson, I probably won't need any more.
<mwhudson> jml: cool
<cody-somerville> wgrant, you around?
<jtv> thumper: I'm looking at turning my new build-farm job class into a BranchJob... does it have to live in the same file as the other branchjob types though?  It doesn't seem quite right to me.
<wgrant> cody-somerville: I am now.
 * wgrant loses a battle against reverse-engineering his ACPI DSDT.
<mwhudson> jtv: it probably shouldn't
<jtv> mwhudson: that was my feeling too.  My one qualm is that it breaks with tradition for BranchJobâthe whole hierarchy now is one big file AFAICS and I may have to put more stuff in __all__ to break that open.
 * jml just put a bunch of stuff in __all__ for branch jobs
 * jml afk -- cleaning laptop
<thumper> jtv: I'm fine with stuff being in different modules
<thumper> jtv: and I'm about to turn my laptop off
<thumper> jtv: any other questions before Sunday?
<jtv> thumper: not yet, so it'll have to wait.  :)  Thanks, see you there.
<thumper> ok
<adeuring> good morning
<arnaud> Hi all
<arnaud> I am currently trying to setup launchpad on my Ubuntu 9.04 Desktop
<arnaud> but a problem occured :
<spiv> just one problem? ;)
<arnaud> :)
<arnaud> here is the pastebin :
<arnaud> http://pastebin.com/d4b16a00
<arnaud> while making the: make schema
<spiv> arnaud: random guess is you don't have the 'python-dev' package installed.
<arnaud> spiv: ok, i'll try to setup this package
<spiv> Well, I assume there's a list of required packages somewhere.
<arnaud> in the https://dev.launchpad.net/Getting page, the required packages are setup automatically by the rocketfuel-setup script
<spiv> Ah, hmm.
<spiv> So that installed the 'launchpad-dependencies' package?
<arnaud> don't know
<wgrant> Jaunty is no longer well tested, but it's meant to wokr.
<arnaud> yep
<wgrant> Try to install launchpad-developer-dependencies, and see why it fails.
<arnaud> ok
<arnaud> with python-dev, it's better, i don't have the error anymore
<arnaud> it's building
<spiv> Hmm, launchpad-dependencies package does depend on python2.5-dev, so that's odd.
<mrevell> Morning
<wgrant> arnaud: Is launchpad-developer-dependencies installed?
<wgrant> I suspect not.
<arnaud> wgrant: not yet
<arnaud> wgrant: launchpad-soyuz-dependencies: Depends: dpkg (>= 1.15.4) but 1.14.24ubuntu1 is to be installed
<wgrant> Hm, that's meant to be fixed.
<arnaud> http://pastebin.com/d75ede891
<arnaud> dpkg can not be upgraded
<wgrant> spiv (or anybody else around): Want to copy dpkg from Karmic in https://launchpad.net/~launchpad/+archive/ppa to Jaunty?
<wgrant> Er. From *Hardy* to Jaunty.
<wgrant> arnaud: For now, grab and install https://edge.launchpad.net/~launchpad/+archive/ppa/+files/dpkg_1.15.4ubuntu2~launchpad1~bigjools1_i386.deb
<arnaud> ok
<spiv> wgrant: I've never done that before, and I think 8:20pm on a Friday isn't a good time to start ;)
<wgrant> spiv: Possibly not.
<arnaud> it's 10:20 in France ;)
<arnaud> 10:20 AM
<arnaud> ok, launchpad-developpers-dependencies are now going to be installed
<deryck> Morning, all.
<henninge> jtv: you dropped out on the internal server
<jtv> oh
<jtv> henninge: last thing I got from you was the link to the linux-ng page; did you get any of my answer?
<henninge> jtv: why don't I see the template here? Another bug or  new feature?
<henninge> jtv: yes, I did. I will do it.
<henninge> jtv: I meant this: https://translations.edge.launchpad.net/util-linux-ng/head
<henninge> jtv: there is a template, I can see it on +templates but it does not appear on the productseries page.
<henninge> am I missing something?
<jtv> henninge: looks to me as if the oops is caused by the translation focus... that project has no "trunk" series.  The page tries to present a link to the upload page for the translation focus series, but it ends up adding a +upload-translations to the _project_ page.
<henninge> it's not deactivated.
<jtv> I do see it in the full templates list...
<henninge> jtv: they have a development focus but it's called "head"
<henninge> I guess wemust be assuming "trunk" somwhere?
<jtv> henninge: exactly; I think they ended up with no translation focus at all
<henninge> jtv: the product home page says, "head" is the focus.
<jtv> henninge: that's development focus... didn't we just add a separate translation focus?
<henninge> oh, that is what I might be missing!
<henninge> jtv: right, I remember now ... ;)
<henninge> jtv: maybe the oops and not seeing the template are related to this situation.
<jtv> henninge: that's what I was thinking... I guess what I said about it earlier was lost
<henninge> jtv: bug 504727
<mup> Bug #504727: Translation focus gets confused when the development focus is removed or renamed <oops> <Launchpad Translations:Triaged by henninge> <https://launchpad.net/bugs/504727>
<jtv> henninge: thanks
 * henninge now tries to reproduce this locally
<jtv> yes, first thing to do now is figure out whether any of that supposition is actually true :-)
<henninge> jtv: is the translation focus a database field on productseries or is it an emergent property?
<jtv> henninge: it certainly wouldn't be on productseries!
<henninge> err, on ...
<jtv> product :)
<henninge> oh, right! ;)
<jtv> It's a db field there
<henninge> jtv: Funny, find devel/lib/lp -name "*.py" | xargs grep -i "translation.?focus" returns nothing
<henninge> jtv: is it "translatable_series" ?
<jtv> no focus
<jtv> btw try grep's -r option, plus -I (capital i) to skip binaries.  :-)
<jtv> Looks like we're not using that db field yet in devel... but then how could it be on edge?
<jtv> have a good weekend, everyone!
* bac changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 1 of 10.01 | PQM is open | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | Channel logs: http://irclogs.ubuntu.com/
<bac> hi sinzui
<sinzui> hi bac
<bac> sinzui: i was looking at bug 473917 as something to just knock out quickly.
<mup> Bug #473917: Help for creating mirrored branch on new project is blank page <trivial> <Launchpad Registry:In Progress by bac> <https://launchpad.net/bugs/473917>
<sinzui> bac: that is a good choice.
<bac> sinzui: i have a few questions: 1) why are we assigned it? 2) the URL is wrong but the wiki does a redirect, so do we want to fix it?
<bac> sinzui: i've already made the fix and can easily land it.  it's cleaner to not have to do the redirect.
<bac> sinzui: and 3) can i get an r/rs for http://pastebin.ubuntu.com/353487/
<sinzui> bac: we have a zero trivial bug policy. So when I found it, and knew it only shows on registry pages, I targeted it to this mielstone
<sinzui> rs=me, and you get the karma
<bac> sinzui: how much karma for a free cup of coffee?
<sinzui> I do not know. I can triage a lot of bugs in the time it takes to brew coffee
<bac> sinzui: unless i'm mistaken it only shows up on https://code.launchpad.dev/foofoo -- just want to make sure i haven't missed something
<sinzui> I think that text appears on the series +index
<sinzui> bac: If I am mistaken, then we have stolen a code-team trivial bug, but they had months to fix it
<bac> sinzui: i'll look again but i think it is purely code app
<sinzui> bac: there are 2 other trivials in our bug list
<mars> sinzui, around?
<sinzui> yes
<allenap> bac: I'd like to add an agenda item to https://dev.launchpad.net/ReviewerMeetingAgenda, but it's still got the old stuff there. Can I just replace it?
<bac> allenap: why don't you let me clean it up and then i'll ping you
<arnaud> hi back
<allenap> bac: Brilliant, thank you.
<arnaud> I am trying to setup Launchpad locally
<arnaud> I got this error :
<arnaud> OSError: [Errno 2] No such file or directory: 'sourcecode/mailman'
<mrevell> Does our stylesheet not support unordered lists in the main div?
<arnaud> while executing 'make schema'
<bac> allenap: carry on!
<allenap> bac: Thanks.
<Ursinha> salgado, hi :) re. the missing oopses yesterday, they were deleted by the oops_prune script, that removes unreferenced oopses more than 40 days old
<maxb> In a bzr url like lp-64863440:/// .... what actually is that number?
<salgado> Ursinha, oh, ok.  thanks for investigating that
<Ursinha> salgado, no problem
<bac> allenap: is that your branch that is running on buildbot now?
<allenap> bac: Yeah, along with several others.
<bac> allenap: looks like a major regression.  the shipit tests are failing due to 'mark@hbd.com' addresses, which have been gone for months
 * bac confused
<allenap> bac: Wow.
<bac> salgado: ^^  ??
<salgado> bac, allenap buildbot must have failed to fetch the most recent shipit branch
<salgado> I've seen that a few times already
<allenap> salgado: The first error in https://lpbuildbot.canonical.com/builders/lp/builds/482/steps/shell_7/logs/summary also shows a bzrlib issue.
<bac> allenap: like 'force' buildbot needs a 'euthanize' button
<allenap> bac: Yep, this is a wasted run.
<salgado> shell_6 [pull new sourcecode revisions failed]
<sinzui> is there any chance that ISD reverted code that reintroduced the old address?
<salgado> sinzui, ^
<salgado> failed to pull new sourcecode revisions
<sinzui> okay
<allenap> sinzui: I think it's using the code that's on the buildbot slave image.
<allenap> sinzui: Which is probably pretty old.
<allenap> salgado, bac: I'm sure you've seen this, but the branch it's looking for is missing.
<salgado> really!?
<bac> allenap: i've not seen such a thing before
<allenap> salgado: Yeah, lp:~launchpad/pygettextpo/trunk has dropped off the map.
<salgado> oh, pygettextpo
<allenap> Ah, sounds like someone knows what's happening :)
<salgado> probably the one who's to blame for that
 * salgado goes for the quick and dirty way to fix it
<salgado> allenap, now it exists and the next build should work
<salgado> that will give us time to get the buildbot image updated
<mars> sinzui, do you know how I would go about getting your new findPerson() API parameter using launchpadlib?  Do I have to check out trunk, or write a patch, or something similar?
<sinzui> you may need to delete your local cache. It just works because launchpadlib gets the edge WADL which has the current API
<mars> sinzui, so just use my currently installed launchpadlib version, magic will happen?
<sinzui> mars: yes. I did nothing to start using the new API
<mars> cool :)
<bac> hi sinzui
<bac> EdwinGrubbs: do you know much about the IPickerEntry structure?
<bac> EdwinGrubbs: i just made a change to person_to_pickerentry but i don't know how to test it.  i can't seem to find any existing tests for that set of code.
<bac> EdwinGrubbs: oops, i've got to step out now.  perhaps we can discuss it later.
<mrevell> night!
<sinzui> hi bac
<EdwinGrubbs> bac: I don't remember if I wrote any tests for that besides the tests for +huge-vocabulary. What changes are you making? I am working on that also.
<EdwinGrubbs> gary_poster: ping
<gary_poster> EdwinGrubbs: pong
<EdwinGrubbs> gary_poster: I'm working I making vocabularies secured utilities, and I ran into some issues that I would like your opinion on. Do you have time to look at my abbreviated diff with notes? http://pastebin.ubuntu.com/353566/
<gary_poster> EdwinGrubbs: yes.  Talking with someone else then will move to this.  I expect I'll be able to focus on this in about 30 min.  That OK?
<EdwinGrubbs> gary_poster: that's fine. thanks
<gary_poster> cool np
<EdwinGrubbs> mars: ping
<DaveWhite> Hey all, I've just installed and run launchpad, and then reconfigured it for remote access. When I try to restart apache... got as far as typing that before I figured out where I messed up ;-)
<mars> hi EdwinGrubbs
<EdwinGrubbs> mars: would you like to take a look at the changes I made to the JS reviewer guidelines regarding modules and namespaces. It's not a big deal if not. The only item that didn't come up in the reviewer meeting is that I removed the requirement for @namespace, since that seems redundant, because it should match the module name. https://dev.launchpad.net/JavaScriptReviewNotes
<mars> EdwinGrubbs, ok, I think removing @namespace should be fine.  I do not think our doc tools us it at the moment.
<mars> EdwinGrubbs, that looks like a good change.  I like the explicit examples of the gotcha namespace code.
<EdwinGrubbs> thanks
<bac> hi EdwinGrubbs
<bac> i made the change in this MP https://code.edge.launchpad.net/~bac/launchpad/bug-419930/+merge/17015
<EdwinGrubbs> bac: hello
<bac> EdwinGrubbs: see line 9 of the diff
<bac> EdwinGrubbs: if an email address was hidden there was an uncaught Unauthorized exception which broke the picker and the person wasn't displayed
<bac> EdwinGrubbs: salgado asked for a test for that change but i'm not sure how to test it
<EdwinGrubbs> bac: Yes, that is the same code that I'm working on in the bug that I stole from you yesterday.
<bac> EdwinGrubbs: ok
<bac> EdwinGrubbs: do you want me to back out that change from my branch?
<bac> EdwinGrubbs: it was a drive-by fix WRT the rest of my branch
<EdwinGrubbs> bac: I'm going to change all the vocabulary zcml from using <utility> to <securedutility> so that objects returned from vocabularies are wrapped in security proxies. You won't need to check the hide_email_addresses attribute then.
<bac> EdwinGrubbs: if you have a handle on it i'll just back my changes out.  just be sure hidden email address don't bust it.  sound good?
<EdwinGrubbs> bac: I don't know if that affects the rest of your branch, whether you would need to call canRead() or as gary prefers try/except UnauthorizedError.
<bac> EdwinGrubbs: it has nothing to do with my branch
<bac> EdwinGrubbs: i just noticed the Unauthorized in the server logs and traced it back
<EdwinGrubbs> bac: oh, I didn't notice that removeSecurityProxy() is what is leaking email addresses in your case and not vocabularies that aren't security proxied. I don't think my branch will affect anything except that drive-by like you said.
<bac> EdwinGrubbs: can i chat with you on skype real quick?
#launchpad-dev 2010-01-09
<bfiller> hey there, using launchpadlib python library and trying to figure out how to list the team's that I'm a member of
<bfiller> I want to find the projects related to a particular team that I am a member of. Is this possible?
#launchpad-dev 2010-01-10
<jml> hey
<jml> we're in testfix mode
<jml> I'm forcing a build.
<jml> huh
<jml> so it's actually something deeper than that.
<jml> al-maisan, lp.bugs.model.bugnomination.BugNomination.canApprove
<al-maisan> jml: got it, thanks!
<thumper> morning
<mwhudson> hi
<lifeless> hi
<jml> I'm forcing a build
<jml> maybe it'll help
<jml> failed :(
<mwhudson> hm
<mwhudson> substantiate failed -> master restart
<jml> mwhudson, I thought we just restarted the master?
<mwhudson> jml: well yes
<jml> mwhudson, ahh ok. computers suck.
<jml> noodles775, where can I read about the builder behaviour stuff?
<noodles775> jml, lib/lp/buildmaster/tests/buildfarmjobbehavior.txt
<jml> noodles775, thanks
<jml> noodles775, bigjools: where's the build slave xmlrpc server defined?
<jml> and is there an interface?
#launchpad-dev 2011-01-03
<adeuring> good morning
<LPCIBot> Project devel build (347): STILL FAILING in 3 hr 30 min: https://hudson.wedontsleep.org/job/devel/347/
<LPCIBot> Project db-devel build (261): STILL FAILING in 3 hr 34 min: https://hudson.wedontsleep.org/job/db-devel/261/
<gary_poster> jelmer: ping?
<gary_poster> jelmer: unping
<jelmer> gary_poster: hi :-)
<gary_poster> hi jelmer :-) sorry, I'm chr and didn't know the answer to a soyuz question, but someone else stepped in
<sinzui> jml. sorry for missing our standard meeting time. My computer needed a stern whack.
<lifeless> good morning launchpad
<jkakar> Good morning lifeless, Happy New Year! :)
<lifeless> hi jkakar !
<lifeless> === Top 10 Time Out Counts by Page ID ===
<lifeless>     Hard / Soft  Page ID
<lifeless>       29 / 3980  Archive:+index
<lifeless>       29 /  170  BugTask:+index
<lifeless>       22 /  239  Distribution:+bugs
<lifeless>       12 /  151  POFile:+translate
<lifeless>       10 /   17  DistroSeriesLanguage:+index
<lifeless>        8 /   95  ProjectGroupSet:CollectionResource:#project_groups
<lifeless>        7 /  235  Distribution:+bugtarget-portlet-bugfilters-stats
<lifeless>        6 /    4  ProjectGroup:+milestones
<lifeless>        5 /    5  Archive:+copy-packages
<lifeless>        5 /    2  Product:+filebug-show-similar
<lifeless> sinzui: did you have a good break?
<sinzui> lifeless I suppose so. I have not completed updating gedit-developer-plugins to libpeas and gobject-introspected, but my version is running on my natty alpha one desktop
<sinzui> Once I upgraded to the alpha, making my primary tools work became an imperative. I think this means they will ship with quickly by default by the beta release
<lifeless> flacoste: hi
<lifeless> flacoste: are we talking today ?
<flacoste> hi lifeless!
<flacoste> we are
<lifeless> kk
<flacoste> lifeless: https://lpstats.canonical.com/graphs/PPR/20100104/20110104/
<lifeless> https://lpstats.canonical.com/graphs/PPR/20101228/20110104/
<lifeless> http://newrelic.com/
<lifeless> http://omniti.com/video/noit-oscon-demo ?
<flacoste> lifeless: http://launchpad.leankitkanban.com/Boards/Show/12720553
<jml> sinzui: I'm off all week
<lifeless> jml: doh
<lifeless> jml: I was hoping for a chat
<wgrant> gary_poster: Hi.
<lifeless> flacoste: https://bugs.launchpad.net/launchpad-project/+bugs?field.tag=feature-flags
<jml> lifeless: maybe we can work something out
<gary_poster> wgrant: hi.  (if you are responding to my ping, someone was asking for soyuz help and I was flailing for help since I didn't see bigjools around.  someone else replied at the time.  thank you)
<wgrant> gary_poster: I was actually around a few minutes after that, but decided that 2am wasn't a good time to be working.
<gary_poster> wgrant: lol, I agree
<wgrant> gary_poster: I'm actually wondering if there's any reason I shouldn't copy bzr-pqm and bzr-tarmacland in the PPA to natty.
<wgrant> Because your new launchpad-dependencies is uninstallable.
<gary_poster> wgrant: argh!  should have thought of that.  no, there is no reason not to copy them (with binaries)
 * wgrant does so.
<wgrant> Thanks.
<gary_poster> thank you wgrant
<wgrant> Hmm, although they each have separate lucid and maverick uploads.
<wgrant> Should I use the recipe, or just copy the maverick ones?
<gary_poster> I'm pretty sure copying will work, but Ursinha or matsubara-afk can you offer any insight?
<wgrant> It should work. And if it doesn't, the new version will be newer, so it will be easily fixable.
 * wgrant does it.
<gary_poster> +1
<Ursinha>  not really, I think copying should be enough..
<lifeless> jml: well ping me your morning or something
<lifeless> wgrant: ok, so Archive:+index
<lifeless> its tagged for stub; suggest grabbing him this arvo
<lifeless> I think he looked and said (roughly) 'fugly queries'
<wgrant> Yeah, that's about what I recall.
<wgrant> I will grab him.
<lifeless> it may be worth changing it from prejoin to using DRS and doing a couple of simple serial queries.
<wgrant> sinzui: Hi.
<sinzui> hello
<wgrant> sinzui: I just saw bug #696954.
<_mup_> Bug #696954: Allow persons in project roles to access private bugs <disclosure> <Launchpad itself:Triaged> < https://launchpad.net/bugs/696954 >
<wgrant> Surely embargoed security bugs should not be seen by everyone?
<sinzui> I am not certain of that. But I have said before that we are working on privacy issues, not security issues
<sinzui> wgrant: I do not have a strong opinion about who should see security bugs.
<wgrant> sinzui: Well, at least for Ubuntu the bug supervisor *must not*.
<sinzui> At this time, I think security bugs are only seen by subscribers. There is plenty of opportunity to shoot yourself in the foot by unsubscribing.
<wgrant> Sure.
<wgrant> But that's how it has to be.
<wgrant> Unless you add an implicit security contact subscription.
<wgrant> Which might be OK once we have anti-subscriptions.
<lifeless> we had anti subscriptions
<lifeless> they were removed
<wgrant> Did we?
<sinzui> I believe there are 50 private Lp bugs that we cannot see
<wgrant> I don't recall there ever being anti-subscriptions.
<sinzui> wgrant: I am fine with not showing security bugs to drivers and bug supervisors. I think owners need to see them because the role is rarely delegated
<wgrant> Bug contacts could initially unsubscribe, but that's because there were no implicit subscriptions.
<wgrant> sinzui: For Ubuntu that is probably still a really bad idea.
<lifeless> well
<lifeless> there are some nuances here
<lifeless> firstly, shared namespaces.
<sinzui> We should not trust the owner? maybe we should not report a bug in their project then. I expect owners to fix their work
<lifeless> secondly, CVE legal requirements
<wgrant> sinzui: Embargoes.
<wgrant> As lifeless says.
<wgrant> The security team is to have access to those.
<wgrant> Not ~ubuntu-drivers.
<cody-somerville> What about making it configurable? ie. you could have a matrix, roles vs. bug type
<wgrant> Launchpad seems to hate configurability.
<wgrant> But that would indeed be optimal.
<lifeless> cody-somerville: bite your fingers
<cody-somerville> but that'll hurt :-(
<sinzui> Ubuntu should fix itself or raise their issues as top priority in stakeholders meetings. making a driver team the owner is just wrong. If they are note really owners, them make the real ownes the owner
<wgrant> sinzui: It's arguable that even the project's owners should not know.
<wgrant> Although I guess they can change the security contact anyway.
<wgrant> It would be nice to still have separation.
<cody-somerville> If permission stuff could be changed on the fly instead of hard coded they would probably be more open to trying to get things as intended. right now people are finding all kinds of creative ways to get launchpad to do what they want (or as close to it).
<lifeless> so
<lifeless> we have a requirement from mark to minimise variation between projects in LP
<wgrant> That is going to limit adoption. Because Ubuntu is not other projects.
<lifeless> so that once someone learns *lp* they can predict its behaviour for ubuntu, zope, launchpad itself etc etc etc
<cody-somerville> wgrant, I disagree. There has to be a buck stops here type position that has access to everything. You don't want to get into a scenario where no one can access something anymore because no one with the required role exists anymore.
<lifeless> sinzui: I suggest that 'security team' as a role with implicit subscription is all thats needed, no ?
<sinzui> wgrant: the project owner can *choose* to have full access simply by they control who in in the security  role. Private bugs will only have 1 bug target. So when the owner sees a count of bugs higher than listed, he will cease control
<lifeless> this doesn't help the shared namespace problem
<lifeless> but we were perhaps on crack doing that right from the beginning
<wgrant> sinzui: But changing the security contact is a very explicit action. I don't think that giving them implicit access to the security bugs is a fantastic idea.
<cody-somerville> lifeless, I think the intention there might have been more like not letting them decide the layout of the 'portlets' (or w/e you call them) on the project page and not intentionally cripling the usefulness of Launchpad by always having to have the lowest common denominator when it comes to functionality.
<wgrant> +1
<lifeless> cody-somerville: no, thats not it
<sinzui> I think a user is a security role gets to see all security bugs. The subscription is only needed for email. That is not required though because th security team could have a structural subscription
<wgrant> sinzui: True. One could have a security-only structural subscription.
<lifeless> cody-somerville: this has been discussed a lot previously; its about behaviour not presentation
<wgrant> So all we really need is for structural subscriptions to work for private bugs, detach viewing rights from subscriptions, and allow structural subscriptions based on the security flag.
<lifeless> cody-somerville: our *job* is to make the lcd very powerful and find ways to solve the tensions present
<sinzui> cody-somerville: But I think most of us agree that the project page is designed to be useless for people who need to use it
<cody-somerville> we have to be pragmatic here.
<cody-somerville> The same permission policy for all projects just isn't going to work.
<lifeless> cody-somerville: it has for 6 years and we have plenty of adoption.
 * cody-somerville laughs.
<wgrant> FSVO plenty.
<wgrant> And FSVO adoption.
<lifeless> Look, reframing the problem is one route forward.
<lifeless> I'm not ruling it out - thats for jml, as proxy-mark, to do.
<lifeless> What I am doing is telling you *how* its been communicated to me previously.
<cody-somerville> I understand that.
<lifeless> I will say that just because its hard to do doesn't mean its impossible or unvaluable.
<sinzui> We are being asked to make it clear who does have access, and to make it simple to grant someone access to all of a project. We do not need to concern ourselves with a lot of details to be successful. We can continue to limit who can see the security issues knowing that an owner can always choose to know, and that it will be common knowledge how to choose.
<lifeless> indeed
<lifeless> so - for instance - showing a 'has access' portlet in addition to the subscribers
<lifeless> I *do* think that the security contact should act as an implicit subscription not a template subscription
<cody-somerville> +1
<cody-somerville> btw, is there another web application that does this really well that could be a role model?
<lifeless> not that I've seen
<wgrant> The only template subscription should be the reporter.
<wgrant> That's easy to do once access is separate.
<lifeless> wgrant: it won't be separate
<lifeless> wgrant: subscription will still imply access; it will be additive
<wgrant> Right.
<lifeless> flacoste: we have a lot of sev 0 rt tickets
<lifeless> flacoste: https://dev.launchpad.net/LEP/ReleaseFeaturesWhenTheyAreDone#preview updated
<flacoste> poolie: http://en.opensuse.org/openSUSE:OSC
<flacoste> poolie: http://en.opensuse.org/openSUSE:Build_Service_Collaboration
#launchpad-dev 2011-01-04
<poolie> hi lifeless !
<poolie> happy new year
<lifeless> hi poolie, ditto.
<lifeless> popping out for food, brb
<wgrant> poolie: Did you happen to check if Lucid's python-oauth is fixed too?
<poolie> wgrant, i did not, yet
<poolie> francis's message led me to suspect it was already installed from an egg?
<poolie> that was the next thing i was going to check
<wgrant> Ah, I haven't read the MP.
<wgrant> I'm just interested because I have been trying to remove contrib/ over the past year or so.
<wgrant> Most of it is gone.
<wgrant> lib/contrib/oauth should be easily removable. And we for some reason have a version of BeautifulSoup in the tree too, which should be removable.
 * wgrant lunches.
<StevenK> wgrant: Far too many scripts use contrib.glock :-(
<cody-somerville> wgrant, StevenK: With today's soyuz, how difficult would it be to separate the buildd and job dispatch code into a discrete service?
<lifeless> cody-somerville: what do you mean by that?
<wgrant> Beat me to it.
<lifeless> what operations would be 'buildd but not job dispatch'? And vice verca.
<poolie> wgrant, there is a download-cache/dist/oauth-1.0.tar.gz
<poolie> which i take to mean it's not installed from the distro
<lifeless> no
<poolie> istm it would be better if more stuff was
<lifeless> that just means its in the download cache
<wgrant> I think the "buildd and job dispatch code" is a single entity that cody-somerville wants extracted?
<lifeless> versions.cfg and setup.py are what you need to consult
<cody-somerville> wgrant, aye
<wgrant> poolie: It would make sense for lots of stuff to be installed from the distro, I think.
<wgrant> But Zope disagrees, so we disagree.
<lifeless> poolie: to do more stuff from the distro we need to solve the concurrent version issue I've been harping on about (e.g. see debian-python mails from yesteday)
<lifeless> wgrant: its not about zope
<poolie> what is that, briefly?
<poolie> multiple versions of the same python library?
<lifeless> yes
<poolie> or for multiple interpreters?
<wgrant> lifeless: It is to an extent.
<lifeless> former
<lifeless> wgrant: if you mean not at all
<wgrant> lifeless: Oh?
<poolie> ... because, lp needs some things more recent than in lucid, that cannot be upgraded without breaking other packages?
<wgrant> Zope people use buildout.
<cody-somerville> and actually a more interesting question I have is, how difficult would it be to make the packaging building stuff (exclusively) a service? Ie. I use an API to provide a source package + chroot configuration and I get back the binaries
<wgrant> Some other people are starting to use virtualenv, true, but it's not the way things have mostly worked in the past.
<lifeless> poolie: because we run multiple versions of launchpad concurrently in the same machine
<cody-somerville> *package
<wgrant> cody-somerville: With queueing?
<lifeless> poolie: such as when we're deploying an upgrade
<cody-somerville> wgrant, yes
<poolie> hm
<lifeless> wgrant: I think you're talking about something else, I know what other zope projects do, I'm talking about what we'd need.
<wgrant> cody-somerville: It wouldn't be horrifyingly difficult to write a job to do that. But buildd-manager still depends on most of the rest of Launchpad.
<lifeless> poolie: wgrant: one of the first things I did as TA was analyse what we need from buildout, as part of looking to simplify things.
<wgrant> lifeless: Most projects do not need to be locked to particular versions of libraries.
<poolie> one way to look at this is, probably
<lifeless> the primary thing is having dependency V1 and V2 concurrently installed as we transition
<cody-somerville> wgrant, just the buildd is already separated out, right?
<wgrant> cody-somerville: Right.
<lifeless> wgrant: it only takes one.
<poolie> if launchpad itself was packaged, you couldn't run multiple (closely related) versions concurrently
<wgrant> lifeless: Right.
<poolie> therefore, they should actually be in separate chroots or something
<poolie> generally speaking debian expects you'll have just one version at a time
<lifeless> poolie: huh?
<lifeless> poolie: we're talking deps, you're talking application.
<lifeless> poolie: for deps debian expects many versions in nearly every other language than python.
<lifeless> C, C++, C#, perl (I think), ...
<cody-somerville> wgrant, Does it have a well defined, generic API that would make it easy to just use say amazon's simple queue service and some dispatching glue code?
<wgrant> cody-somerville: Hee hee.
<poolie> mm i agree it would be good to support multiple versions in debian
<lifeless> cody-somerville: we have rabbit, why would we use sqs?
<poolie> just don't know if that should be a dependency for getting more lp dependencies packaged
<lifeless> cody-somerville: perhaps you should talk about what you want to do, now how to do it :) It might be a more effective discussion
<cody-somerville> wgrant, Does it have a well defined, generic API that would make it easy to just use an existing queue solution such as rabbitmq and some dispatching glue code?
<lifeless> poolie: its not a dpeendency for getting them packaged; its a dependency for *using them from packages*
<cody-somerville> lifeless, I am but you're getting hung up on the example I used. :P
<wgrant> cody-somerville: My previous rofling stands.
<poolie> that's what i meant
<cody-somerville> wgrant, seriously? :(
<poolie> anyhow, in this particular case, we could use the packaged version?
<lifeless> poolie: we will be running 30 or more appservers per physical machine, I shudder at the idea of vm's or chroots in the mix.
<wgrant> cody-somerville: It's not impossible.
<wgrant> But probably not terribly easy.
<poolie> or is there a general thing of keeping it in sourcecode because we might want to change it?
<lifeless> poolie: in this case, yes.
<poolie> where is the line?
<lifeless> poolie: if the packaged version matches our version needs, once its remoed from contrib we should just use the package automatically.
<cody-somerville> ffs, why don't people just trust all the books that tell you that people WILL reuse your code :-(
<lifeless> cody-somerville: I'm not hung up on it, I don't get your use case.
<wgrant> cody-somerville: Probably because this was written in 2004 or so :(
<poolie> no, what i meant was, what's the policy on using the packaged version?
<poolie> is it as simple as saying if the distro's own package is adequate, we'll use it, otherwise not?
<lifeless> poolie: there isn't a hard one, its an engineering decision per package.
<lifeless> I wouldn't use a high flux dependency (like bzrlib) from a package today.
<cody-somerville> poolie, thats what we do with OEM's image build system
<cody-somerville> poolie, we create a virtualenv and pip will only install dependencies that aren't already met by the system's site-packages
<poolie> mm i see your point
<poolie> in some ways it seems like a kludge not to update the bzr package and install that
<poolie> of course it would be difficult to do staged testing then
<poolie> i guess also it seems not quite perfectly safe to upgrade packages while they're being used
<cody-somerville> lifeless, I want to be able to use the launchpad buildd farm directly to build source packages. ie. I use API to say I want to build this source package using this chroot configuration and it gives me back the binary packages.
<lifeless> poolie: ignoring the link-unlink bug, the problem is that we want version 1 running while version 2 is prepped and checked
<lifeless> poolie: and during that time, version 1 might restart (log rotation) or import a module it hadn't used before
<poolie> right
<lifeless> poolie: in fact, for cronscript servers, we're continually starting new processes of version1 all the way until version2 is live
<wgrant> cody-somerville: Why?
<lifeless> cody-somerville: ok; so you want to not-publish-into-a-ppa and you want to specify the chroot rather than it being inferred from the target ppa
<lifeless> cody-somerville: we could certainly refactor to have a dedicated layer for that
<poolie> assuming the python multiple version problem is solved, would you use that?
<lifeless> poolie: I'm very keen to use more distro packages of python.
<poolie> it seems unidiomatic to have separate package names at very fine granularity
<wgrant> lifeless: Another requirement is custom sources.list entries.
<poolie> but perhaps we would have stable on bzr2.2.2 and staging on bzr2.2.3
<lifeless> wgrant: right, we'd need complete parameterisation
<wgrant> Which is messy.
<cody-somerville> wgrant, we already can do that
<wgrant> cody-somerville: Not... really.
<lifeless> cody-somerville: we inject those into the chroot, its not a different chroot
<lifeless> cody-somerville: *you* might be willing to run with a different chroot, but lp can't sensibly.
<lifeless> we'd have thousands
<cody-somerville> I don't actually want to use my own chroot with my current use case, just be able to define the sources.list really
<poolie> lifeless, i'd like to have a talk sometime today, or tomorrow
<lifeless> sure
<wgrant> Ideally the build farm would not really be part of LP.
<cody-somerville> wgrant, +10000
<lifeless> wgrant: why?
<cody-somerville> lifeless, makes it easier to reuse the code
<poolie> will just do a couple more chores then ping you
<poolie> if that suits
<lifeless> cody-somerville:  that doesn't really follow :)
<lifeless> poolie: sure
<cody-somerville> lifeless, it currently sounds like I'd have to setup an entire launchpad instance to reuse the code or to deploy my own instance
<cody-somerville> lifeless, plus, the buildd farm stuff really has no need knowing anything about launchpad its self - so why make it? :)
<lifeless> theres a bunch of opportunities we haven't capitalised on
<lifeless> anyhow
<cody-somerville> they can all be done at a higher level
<lifeless> something we'd want to make all this done better would be to have web callbacks for things completing
<wgrant> lifeless: Because Launchpad is really huge and unnecessarily monolithic. The build farm is sensibly reusable, so it is a good target for ripping out.
<lifeless> wgrant: I'm pro that if we sort the interface out properly first
<wgrant> lifeless: That would seem to be a requirement regardless.
<lifeless> wgrant: The worry I have, is that if the goal is 'rip out' then sorting out the interface becomes secondary and 'good enough' often isn't.
<lifeless> wgrant: if the priority is instead 'get a really clean interface and make use of the build farm in better ways' - and if by chance someone can extract it later, thats fine with me.
<wgrant> lifeless: If we do not clean up the interface, there is little direct benefit to ripping it out.
<cody-somerville> So to reveal my master plan, I know that OEM Services isn't going to run our own deployment of launchpad - we don't want to - and I know that launchpad.net isn't going to be able to meet all of OEM Services's needs while meeting everyone elses at the same time which is why I'd like to be able to build custom services that are a perfect fit for us on top of services provided by Launchpad so I don't have to reinvent the wheel o
<cody-somerville> r duplicate resources.
<wgrant> That is a large part of my desire to chop LP into little pieces.
<wgrant> cody-somerville: Why can we not provide all of your needs?
<lifeless> beat me to it this time.
<wgrant> We should be trying to fix LP -- whatever that may entail -- before we try to work around it.
<cody-somerville> wgrant, because you have to have the same behavior across launchpad and the desired behavior for OEM Services, Ubuntu, and upstream projects conflict.
<cody-somerville> Plus some things won't be appropriate in Launchpad at all and you guys would hate us if we made you hack something in and we'd be angry that it wasn't maintained very well and we can't just do it all ourselves as it would duplicate part of something Launchpad does well
<cody-somerville> ugh, not typing very well but that seems readable, yes?
<lifeless> cody-somerville: we need all projects in lp to be consistent, we don't need distros to be the same as projects
<wgrant> lifeless: Yes we dooooooooo.
<wgrant> They should be the same object.
<wgrant> Anything else is just a mess of pain and user confusion.
<lifeless> wgrant: if we sort out project groups, sure.
<wgrant> cody-somerville: What sort of things do you want? Your needs are not terribly unique.
<wgrant> lifeless: Project groups are a bug.
<lifeless> wgrant: one solution to grouping things; one I'm not terribly happy with, but not a bug per se.
<cody-somerville> wgrant, Our needs are considerable unique.
<lifeless> cody-somerville: will you be @ the rally?
<cody-somerville> lifeless, No, sorry.
<wgrant> cody-somerville: Some of your specific needs, sure.
<lifeless> cody-somerville: I'd like to do this on specifics, not on generic statements.
<wgrant> But your need for extensions is not unique.
<cody-somerville> lifeless, Agreed.
<cody-somerville> wgrant, True which is why I think its entirely possible for launchpad to make it really easy for us to build services on top of launchpad services and everyone be happy.
<wgrant> cody-somerville: Exactly.
<lifeless> our generic requirement to find good defaults and unconfusing extensions does not mean 'cannot mean OEM's needs'
<wgrant> Except that you probably shouldn't be trying to run your own instances of every service.
<wgrant> You should probably be able to integrate with Launchpad.net.
<wgrant> (argh, I wish the code had been released as "Rocketfuel" or similar, so we didn't have "Launchpad" vs "Launchpad.net" :()
<cody-somerville> We don't want to. For example, we want to use the launchpad buildd farm but we want to do our own upload processing. Maybe in the future Soyuz will be able to do what we want to do there but it'll be a long time out. Part of the desire to do this is to improve turn around on meeting our needs and not wanting to bloat Launchpad
<cody-somerville> *and also
<wgrant> cody-somerville: Why do you need to do your own upload processing? And is there a good reason to run your own build farm?
<cody-somerville> wgrant, A good example is that we want to have the project name as the target instead of the Ubuntu release name. It would take a lot of work to make that possible in Soyuz right now but in the future, if this was our only requirement, we'd switch to using Soyuz upload processing again when it became possible.
<cody-somerville> wgrant, I can think of no way to justify the cost of hardware for us to set up our own build farm
<wgrant> cody-somerville: Then you probably want to integrate with the Launchpad build farm, rather than set up your own.
<cody-somerville> wgrant, neither could the c-level execs which is why we are now using PPAs to build our packages instead of traditional debian dak buildds
<lifeless> we're /not/ going to run multiple competing control nodes
<cody-somerville> wgrant, Sorry if I haven't been clear. We absolutely want to which is why I was asking my previous questions about refractoring the code.
<wgrant> cody-somerville: But you don't want it split out so you can run your own.
<wgrant> You want to be able to inject your own things into the queue.
<cody-somerville> wgrant, in the future, we may want to supplement our own capacity to build packages using a private farm
<wgrant> cody-somerville: Then we can probably use builder pools.
<wgrant> Which don't exist, but have been devised.
<cody-somerville> wgrant, thats fine too
<cody-somerville> wgrant, basically I just want to be able to use the buildd farm like one can use pbuilder (in terms of input and output, roughly)
<lifeless> so devs will use it directly like that ?
<wgrant> Right.
<cody-somerville> lifeless, No. What I'm envisioning is that our engineers will upload the source package to our upload processor which will handle our unique constraint checks and then use launchpad API to queue it for building with the right sources.list
<cody-somerville> then we'll poll for completed builds, download the binaries, and install them into our archive
<lifeless> cody-somerville: so I think you've spent a bunch of time thinking about this *without us*
<lifeless> and framed the problem as 'how to workaround launchpad'
<lifeless> this isn't helpful :)
<lifeless> cody-somerville: What I'd like to do is just design something that directly adds in what you need; it sounds like the first thing you need is a callback for constraint checking
<cody-somerville> lifeless, I don't think so. I've shared exactly what I wanted out of Soyuz with the soyuz team almost two years ago.
<wgrant> Well, thinking about how to fix Launchpad also isn't entirely helpful.
<wgrant> This may change in January.
<wgrant> When we are actually capable of responding to requirements.
<lifeless> cody-somerville: its not visible to me in my TA role unless it was captured somewhere, which it doesn't seem to have been.
<cody-somerville> lifeless, I even reiterated over it in June with Jono Lange and kiko in Lexington.
<cody-somerville> lifeless, I don't believe you were the TA then
<wgrant> Julian is aware of it.
<wgrant> We are aware of it.
 * cody-somerville nods.
<wgrant> But this is all about to become irrelevant :(
<lifeless> cody-somerville: I wasn't.
<lifeless> cody-somerville: July :)
<lifeless> cody-somerville: so polling is a performance and bandwidth hog
<cody-somerville> lifeless, in the future we'd have web callback
<lifeless> cody-somerville: would a callback from lp @ the constraint checking stage help you today ?
<cody-somerville> lifeless, for some of our requirements, yes
<cody-somerville> lifeless, but we still wouldn't be able to use the project name as the target
<lifeless> cody-somerville: we may need more than one change to meet all your needs.
<wgrant> cody-somerville: Why can't you use separate archives?
<cody-somerville> wgrant, we do currently, one for each project
<cody-somerville> wgrant, the issue is that the target has to be the Ubuntu series
<wgrant> Is this a problem?
<cody-somerville> wgrant, and that'll take a lot of work (pretty much rewriting soyuz) to make that work
<wgrant> The scale of the problem depends on why it is a problem.
<cody-somerville> wgrant, yes. engineers are forever uploading to the wrong series (and then think something is wrong and think soyuz is broken again), its more difficult to track the changes now since we have projects that inherit from other projects, and several times packages have been accidentally uploaded to Ubuntu (but were rejected for other reasons thank goodness).
<wgrant> cody-somerville: It sounds like you want series-restricted PPAs, and probably to remove the default dput target...
<cody-somerville> its not the dput target I'm talking about
<cody-somerville> its the target in the changelog (which is the default value for the Distribution field in the .changes file)
<wgrant> The dput target was for the Ubuntu part.
<wgrant> Also, even now you can put whatever you want in the Distribution field, if you also add the series to the path.
<wgrant> It's not that ingrained.
<cody-somerville> re: series-restricted, sorta but I'd rather think of it like being able to create an archive and be able to configure my own suites
<wgrant> Right. But that's a little harder.
<wgrant> Not *terribly* difficult. But substantially harder.
<cody-somerville> cause thats our biggest barrier to using launchpad for our archive management
<lifeless> === Top 10 Time Out Counts by Page ID ===
<lifeless>     Hard / Soft  Page ID
<lifeless>       92 /  266  BugTask:+index
<lifeless>       91 / 5150  Archive:+index
<lifeless>       41 /  263  Distribution:+bugs
<lifeless>       26 /  114  ProjectGroupSet:CollectionResource:#project_groups
<lifeless>       17 /   37  MailingListApplication:MailingListAPIView
<lifeless>       13 /    4  Product:+filebug-show-similar
<wgrant> !! I am no longer winning :D
<lifeless>       11 /  190  POFile:+translate
<lifeless>       11 /   12  DistroSeriesLanguage:+index
<lifeless>        8 /    2  ProjectGroup:+milestones
<lifeless>        8 /    2  Distribution:+builds
<lifeless> wgrant: so are
<wgrant> Soft timeouts don't count.
<lifeless> yeah, they do.
<wgrant> Shhh
 * wgrant finds a recent oops.
<wgrant> Oh, that's right.
<wgrant> Last time I looked at this I noticed that there were many seconds of Python time which didn't make sense.
<wgrant> Presumably single-threading may eliminate that.
<lifeless> yes
<lifeless> I've mailed flacoste asking him to bump it up now I'm back
<wgrant> It's possible that the view is buggy, but 2.5 seconds after a 100ms query that should only return a few dozen objects seems unlikely.
<poolie> lifeless, hi, how about now?
<lifeless> sure
<StevenK> subunit-filter, you make me sad and I hate you
<lifeless> StevenK: perhaps a more constructive version of same would garner more useful responses than this
<StevenK> lifeless: 'subunit-ls | subunit-filter --no-success' shows me a lot more than the failed tests
<StevenK> But I still hate using subunit since it's obtuse
<lifeless> subunit-ls does not output subunit
<lifeless> you want subunit-filter | subunit-ls
<StevenK> Oh, damn it
<StevenK> The upgrade in the background played with postgres
<StevenK> lifeless: Can I have that tell me which tests failed, without the traceback?
<lifeless> what traceback ?
<StevenK> Oh, it's a frinxing doctest
<adeuring> good morning
<bigjools> morning
<mrevell> Hello!
<al-maisan> Good morning
<mrevell> Hey, I've come back after the holiday and now find that when I try to run make schema in devel I get a message asking me to run link-external-sourcecode. devel is usually the target I link to, though, so I'm a bit confused. Any ideas?
<wgrant> mrevell: Try 'utilities/link-external-sourcecode ../../lp-sourcedeps'
<mrevell> Thanks wgr
<mrevell> ugh
<mrevell> :)
<mrevell> Seems to have done the job, thanks wgrant.
<wgrant> Excellent.
<mrevell> allenap, Around?
<allenap> mrevell: Yep, what's up?
<mrevell> allenap, Remember the egg problem I was having last year? (Couldn't find a distribution for 'testtools==0.9.8-r151'.)  I don't suppose you've got any other ideas on how I can get round it?
<mrevell> allenap, Don't worry if you don't remember :)
<allenap> mrevell: Mmm, I don't really remember the problem. Do you have a paste of it?
<mrevell> allenap, Sure: http://pastebin.ubuntu.com/550154/
<lifeless>  /win 71
<stub> $ ls -al download-cache/dist/testtools-0.9.8-r151.tar.gz
<stub> -rw-r--r-- 1 stub stub 83750 2010-12-07 12:34 download-cache/dist/testtools-0.9.8-r151.tar.gz
<stub> mrevell: Does your tree have that?
 * mrevell checks
<lifeless> stub: hi
<mrevell> stub, No, it doesn't. I've tried rf-setup in the hope that might pull down whatever's missing but it hasn't helped.
<lifeless> stub: wgrant was hoping to talk to you about the archive:+index timeout bug - 400ms queries.
<wgrant> Oh, right, forgot about that.
 * wgrant finds an OOPS.
<lifeless> wgrant: linked in ze bug :)
<stub> mthaddon: cd download-cache; bzr up
<lifeless> s/mthaddon/mrevell :P
<stub> mrevell: ^^^ (sorry mthaddon)
<mthaddon> np
<mrevell> thanks stuv
<mrevell> heh, and I failed to write your name
<stub> mrevell: Update scripts should be doing that for you. Perhaps there is one you are not running?
<wgrant> rocketfuel-setup should run rocketfuel-get which updates download-cache.
<stub> Unless things are misconfigured and it is updating some random location :)
<mrevell> stub, Ah, I'm hitting a repository format error: http://pastebin.ubuntu.com/550164/ ... I'm trying a bzr upgrade
<wgrant> stub: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1817D1186 <- the query count should now be constant, but the remaining queries are being rather slow.
<wgrant> stub: Any suggestions?
<stub> NoScript update thinks Ubuntu SSO is doing XSS.
<wgrant> It probably is.
<stub> wgrant: I think we are going to need to eliminate those big IN (list, of, constants) - they used to benchmark fairly well (years ago) but that seems to be the common factor on the slow queries.
<wgrant> stub: :(
<lifeless> stub: really?
<stub> I don't know - just my spidey sense.
<lifeless> stub: thats going to play havoc with complex datasets
<lifeless> (because prejoining across many tables performs terribly in storm due to deserialisation overheads and cache-replacement-thrashing)
<stub> Some unions in there that look suspicious too
<stub> And those tables have been getting pretty darn big now we have several whole distro releases in there.
<stub> ((seven table join with unnecessary ORDER BY) UNION (five table join with unnecessary ORDER BY)) ORDER BY id
<stub> (query 22 at over 1s)
<lifeless> gnight
<stub> lifeless: We shouldn't have cache replacement issues - the appserver runs with a big cache (10,000). And if that isn't big enough, we can spare some more RAM.
<stub> (storm cache that is - the current config specifies size 10000 and generational cache for the appservers.
<deryck> Morning, all.
<deryck> Happy New Year!
<bigjools> Merry New Year!
<bac> hi deryck
<deryck> hi bac
<bac> deryck: hope you had a good break.
<bac> deryck: i've got a question for you about QA and bug mail
<deryck> bac: indeed, a wonderful break.  Thanks!  and hope your's was good.
<deryck> bac: sure, shoot.
<bac> so i need to qa the fix for bug 579502
<_mup_> Bug #579502: Do not send notifications to registrants (and never if the pillar does not use bugs) <bugjam2010> <lp-bugs> <qa-needstesting> <story-better-bug-notification> <Launchpad itself:Fix Committed by bac> < https://launchpad.net/bugs/579502 >
<bac> but bugmail does not appear to be sent from qastaging
<bac> and, if i remember what sinzui said yesterday, it isn't sent by staging either
<deryck> bac: I thought qastaging mail was sent to the staging mailbox.
<bac> deryck: so can you give me some advice on how to QA a bug mail branch?
<deryck> bac: we usually do some action, have losas run the send bugmail script, and then check the mail in the staging mailbox.
<bac> deryck: really?  sinzui indicated there was a separate qastaging@ mailbox...but the mail sending script wasn't being run
<deryck> mail isn't sent via cron, so you need a losa.
<bac> deryck: ok, so the script is run on demand?
<bac> well, then, that's the missing link
<deryck> bac: right.  and I wasn't aware of a separate mailbox, but maybe that's the case now.
<bac> deryck: thanks.  those are two good pieces of ammo to move forward!
<deryck> bac: np!
<jcsackett> henninge: ping.
<henninge> Hi jcsackett! ;)
<jcsackett> hi, henninge. i was wondering how the qa on recife was going?
<henninge> jcsackett: still ongoing but looks good. ;)
<jcsackett> henninge: cool, thanks. :-)
<bigjools> anyone know if there's a bug filed about the screwy branch diff overlay?
<deryck> bigjools: there's one filed about it being too wide on bug pages
 * gmb EoDs.
<bigjools> deryck: ah I don't think that's the same.  The top of it is off the page for me, and on Chromium it's not even formatted properly.
<bigjools> for the latter, it takes up the whole page
<deryck> bigjools: the bug I'm think of was Chromium specific, so maybe related then.  but nothing about those issues specifically that I recall.
<bigjools> bac: thanks for fixing that has_*_ppa stuff!
<bac> bigjools: np.
<lifeless> flacoste: We're popping into the hospital this morning, in about 2 hrs for $unknown-duration
<lifeless> flacoste: if there's anything more you want to discuss before then would be good :)
<flacoste> lifeless: nope, we are good
<thumper> morning
<maxb> Is there any systematic distinction between lp.code and lp.codehosting ?
<mwhudson> maxb: ish
<maxb> do tell :-)
<mwhudson> i guess you could say that lp.code is the code for the code tab in the webapp
<mwhudson> lp.codehosting is for the stuff that deals in bzr branch data
<lifeless> mwhudson: / thumper: either of you aware of any reason we can't move from internal-xmlrpc to apis for the code* stuff?
<mwhudson> lifeless: there are some that shouldn't be accessible from the wider world
<mwhudson> and it would be nice to do authentication more tidily, but that's a bit orthogonal really
<lifeless> mwhudson: why not?
<lifeless> I mean
<lifeless> should they be limited to some service account
<lifeless> and we simply don't use from outside
<lifeless> or would they be an actual problem if the outside used it even on the service acocunt?
<mwhudson> i think limiting to a service account would be ok
<lifeless> I'd like to get rid of the internal xmlrpc 'cluster'
<lifeless> it requires manual load balancing and complicates haproxy substantially
<poolie> i'd like to change bzr to stop using external xmlrpc too
<lifeless> the anonymous lp-api interface should permit a crafted url with no indirection.
<lifeless> if we bypass all the restful overhead, it should be tolerably fast
<lifeless> sinzui: what teams use polls?
<wgrant> ~ubuntumembers has in the past.
<wgrant> For CC elections.
<lifeless> well, its coming back is all
<wgrant> Recent DMB elections have used an external Condorcet service, though.
<lifeless> yes, I know.
<lifeless> wgrant: I'm asking sinzui because of his MP
<wgrant> It is tempting to restrict them by FF to grandfather them for certain teams.
<wgrant> But that sounds difficult.
<lifeless> pretty easy
<lifeless> however hard to explain
#launchpad-dev 2011-01-05
<maxb> Urgh
<maxb> bzr-tarmacland breaks 'bzr selftest'
<poolie> maxb, as in, it has failing tests, or it breaks it entirely?
<lifeless> popping into supermarket back in a bit
<maxb> as in, it has code in its tests that failed to import, so the entire execution dies
<wgrant> thumper: Are you looking at the buildbot failure too?
<wgrant> It is legit, for once.
<thumper> I wasn't
 * wgrant does.
<thumper> gah, my landing failed due to the non [testfix] nature
 * thumper leaves the devel fix to wgrant
<thumper> wgrant: is it obvious?
<wgrant> thumper: Yes.
<wgrant> thumper: Just running the Bugs tests now.
<wgrant> (the test suite was clearly not run over the problematic branch :/)
<bryceh> running rocketfuel-get just now it fails in mailman:
<bryceh> Compiling /home/bryce/launchpad/lp-branches/devel/lib/mailman/Mailman/i18n.py ...
<bryceh> Compiling /home/bryce/launchpad/lp-branches/devel/lib/mailman/Mailman/versions.py ...
<bryceh> make[1]: Leaving directory `/home/bryce/launchpad/lp-sourcedeps/sourcecode/mailman'
<bryceh> make: *** [compile] Error 2
<bryceh> make: Leaving directory `/home/bryce/launchpad/lp-branches/devel'
<lifeless> yup
<lifeless> use lucid
<lifeless> or fiddle with stuff under the hood as per sinzui's bug about this
<bryceh> $ grep CODENAME /etc/lsb-release
<bryceh> DISTRIB_CODENAME=lucid
<bryceh> bug #?
<lifeless> interesting
<lifeless> hmm, possibly we've broken mailman on lucid by fixing for natty><
<lifeless> sinzui: ^
<StevenK> So we're aiming for Lucid, Maverick and Natty?
<lifeless> we deploy on lucid.
<lifeless> its mandatory until a new LTS is ready
<lifeless> everything else I don't particularly care about :)
<spm> ARGH!
<spm> who made the change that makes it impossible to suspend a user without forcibly resetting their password?
 * spm grumps
<thumper> spm: not me
<wgrant> spm: Wha? LP doesn't have passwords.
<spm> fiik. wouldn't let me suspend them unless I set their password as well.
<spm>  +reviewaccount fwiw. has password fields now
<spm> click the 'change' button and get a "No! Password not set! bad Losa!" error message.
<lifeless> file a bug
<spm> nearly completed. I was ranting here so the bug won't be quite so vitrolic.
<spm> :-)
<lifeless> === Top 10 Time Out Counts by Page ID ===
<lifeless>     Hard / Soft  Page ID
<lifeless>      150 / 5403  Archive:+index
<lifeless>       98 /  385  BugTask:+index
<lifeless>       97 /  126  Archive:EntryResource:getPublishedBinaries
<lifeless>       37 /  332  Distribution:+bugs
<lifeless>       29 /  134  ProjectGroupSet:CollectionResource:#project_groups
<lifeless>       20 /   33  MailingListApplication:MailingListAPIView
<lifeless>       13 /    8  ProjectGroup:+milestones
<lifeless>       10 /   13  DistroSeriesLanguage:+index
<lifeless>        9 /  307  Distribution:+bugtarget-portlet-bugfilters-stats
<lifeless>        7 /   14  NullBugTask:+index
<spm> thumper: do we have any juju to remove comments from merge proposals?
<thumper> spm: no
<thumper> spm: just sql
<thumper> spm: just another of the reasons we should have a singular comment interface
<thumper> (which we don't have)
<spm> I don't spose you have that handy?
<spm> heh
<thumper> spm: sorry, no
<thumper> spm: the table is codereviewcomment
 * spm files another bug ;-)
<lifeless> thumper: it is pretty much a single thing in the data model; what do you see as needed to propogate it higher?
<thumper> bugs handle comments differently
<spm> so do answers fwiw
<thumper> lifeless: bugs store the initial description as the first comment (which is hidden in the UI)
<thumper> lifeless: there are also bug specific fields on the message table
<thumper> lifeless: and the comments pretend to be email messages
<wgrant> And don't even start thinking about attachments...
<thumper> which they aren't always
<lifeless> thumper: there are? I thought those fields were in BugMessage
<thumper> I seem to recall some specific bug thing
<thumper> perhaps it is gone now
<thumper> but the underlying model is quite different
<thumper> and should be normalised
<thumper> and extracted from the message table
<thumper> which is a pile of poo
<thumper> wgrant: how are those tests going?
<lifeless> thumper: what would that leave behind? why isn't it just s/message/comment/ (and thus not very interesting)
<thumper> lifeless: the incoming email processor stores all emails directly in the message / messagechunk tables
<thumper> as well as the librarian
<thumper> it is not a good model for comments
<thumper> the message table doesn't store the text
<thumper> there are one or more message chunks that do that
<thumper> it is just overly messy
<lifeless> yes, thats done to handle ginormous comments
<thumper> well, I don't have the original raisins
<lifeless> it lets us sequence comments without having to deal with a very fat table
<lifeless> so its faster
<wgrant> thumper: Sorry, got distracted with payroll stuff. I'm pretty sure they try to make it as awkward and unintuitive as possible.
 * wgrant creates an MP.
<thumper> wgrant: if it is a testfix, rs=me
<wgrant> thumper: https://code.launchpad.net/~wgrant/launchpad/makeBug-testfix/+merge/45200
<thumper> wgrant: done
<wgrant> thumper: Thanks.
<lifeless> poolie: around?
<poolie> lifeless, hi
<lifeless> poolie: call ?
<poolie> lifeless, hi,  now?
<lifeless> https://dev.launchpad.net/BugTriage
<lifeless> https://bugs.launchpad.net/launchpad-project/+bugs
<lifeless> wgrant: hey
<lifeless> stub: hi
<stub> yo
<lifeless> archive:+index is getting worse daily
<lifeless> any chance you can drill in a bit to get some faster way to answer the questions it needs to ?
<wgrant> dogfood sort of fails to be terribly useful at analysing this sort of query.
<wgrant> Because dogfood is awful.
<lifeless> it succeeds at being terrible
<stub> I'm supposed to be dealing with the test suite leaving garbage db's around, which I guess I should bump in favor of the timeouts.
<lifeless> ah
<stub> Do we have any real slow queries, including the ids in the IN clauses?
<lifeless> only the 500ms ones
<lifeless> (which is pretty slow given the amount of data they are returning)
<lifeless> stub: well, I can't speak for your priorities right now :) - but to me the test suite stuff is important, but unblocking other developers is more important [for you specifically]
<lifeless> I don't know if gary would agree
<stub> I can try to reproduce slow queries using random ids in the IN clause, but genuine data will work better.
<wgrant> I can try to find some genuine data.
<lifeless> wgrant: are you able to generate a representative ready-to-run query ?
<lifeless> jinx!
<wgrant> Not sure how valid it will be, given that DF is from October.
<wgrant> But we'll see.
<lifeless> wgrant: perhaps a template query and a couple of queries to run on prod to populate data like archive ids etc
<lifeless> ok, I need to run for a while to organise dinner
<stub> wgrant: I can run a query on production to generate the list of ids if that helps
<wgrant> stub: Thanks. I'll work one out soonish.
<al-maisan> Good morning !
<wgrant> Morning al-maisan.
<lifeless> bryceh: fwiw bug 697441
<_mup_> Bug #697441: buildmailman fails under python 2.7 (natty) <python-upgrade> <Launchpad itself:Triaged> < https://launchpad.net/bugs/697441 >
<stub> wgrant: When we are doing those 400-1000ms queries with the SourcepackagePublishingHistory.id IN (...) clauses, do we already have the SourcepackagePublishingHistory objects available? I suspect we don't need to actually join with that (big) table in most cases.
<wgrant> stub: We should have them. But that should be fairly cheap regardless, right?
<lifeless> I'm curious what an explain analyze says is up
<stub> Its a big table, and unnecessary joins constrain the planner. And I usually consider 100ms 'fairly cheap', so yes :)
<stub> wgrant: Do you know what the BuildFarmJob.status codes we are selecting for?
<wgrant> stub: Let me see if I can remember which method it is.
<stub> lifeless: http://paste.ubuntu.com/550516/ with random ids and buildfarmjob.status IN (1,2)   (both statuses are fairly large categories)
<lifeless> so its having to generate temp datasets
<lifeless> both of which are being built and sorted rather than delivered from indices
<lifeless> it also looks to be highly correlated
<lifeless> stub: are both halves of the union equally expensive?
<stub> lifeless: roughly
<stub> Unfortunately I can't easily benchmark the variant that eliminates the two unnecessary ORDER BY and SourcePackagePublishingHistory joins, as I end up with about 6 subqueries that make it go slower.
<lifeless> hmm
<lifeless> I see 193 and 749 now that I look closely
<lifeless> so the >< side is the one to focus on
<stub> Where do you see that? I see 1067 and 908
<stub> Oh... actual time. I'm using estimated time. Actual time will be affected because rows will already be in RAM
<lifeless> welll. run it twice ;)
<lifeless> we've seen mismatches between estimate and actual that matter before, haven't we?
<stub> Interesting Gnome lockup...
<stub> Anyway...
<stub> just removing the two unnecessary ORDER BY statements in the subqueries seems to half the runtime by itself. Removing the SourcePackagePublishingHistory table from the joins should be a decent win too.
<adeuring> good morning
<mrevell> Morning
<mpt> Would any kindly Launchpad developer be able to give me a list of the top, say, 50 Launchpad projects by number of blueprints they have?
<wgrant> mpt: https://pastebin.canonical.com/41512/, but it's a couple of months out of date.
<mpt> wgrant, brilliant, thanks.
<deryck> Morning, all.
<wgrant> mpt: Are we?
<mpt> wgrant, are we what?
<wgrant> mpt: Starting to contact the projects that most use blueprints.
<mpt> wgrant, ah, yes, I just talked with mrevell about it
<wgrant> Excellent, excellent news.
<leonardr> gmb, i seem to be using an ec2test image that doesn't have the python-lxml dependency you added around dec. 23
<leonardr> do you know how that could be happening?
<wgrant> Is the branch you're running utilities/ec2 from reasonably up-to-date?
<leonardr> wgrant: i think so, but maybe not
<leonardr> i'm updating now
<leonardr> hopefully that'll fix it
<wgrant> The test run will merge devel before it starts, but you need a recent version locally to have the image whitelisted.
<leonardr> thanks, i'm guessing that was the problem
<leonardr> trying again now
<leonardr> "using machine image version 504"
<wgrant> Looks good.
<bac> abentley, adeuring, allenap , bac, benji, danilo, sinzui, deryck, EdwinGrubbs, flacoste, gary, gmb, henninge, jelmer, jcsackett, jtv, bigjools, leonard, mars, mrevell: Reviewer meeting ping
<gary_poster> thanks
<deryck> yes, thanks
<adeuring> bac: thanks for the reminder!
<gmb> Ta
<jcsackett> henninge: ping.
<henninge> Hi jcsackett!
<jcsackett> hi henninge. is recife still undergoing qa?
<henninge> jcsackett: yup
<jcsackett> do you know when it might be done? i'd like to be able to be sure it will make release. :-)
<henninge> jcsackett: I plan to finish tomorrow around this time. I don't expect any problems atm.
<jcsackett> henninge: that sounds excellent. can you let me know if you run into any hurdles or if there's any way i can help out?
<henninge> jcsackett: sure, I will
<henninge> thanks for offering! ;)
<jcsackett> :-)
<jcsackett> thanks, henninge.
<flacoste> Edwin-afk, sinzui: how is QA of bug 682727 coming along?
<_mup_> Bug #682727: obsolete-junk/+series times out when the user is not anonymous <lp-registry> <qa-needstesting> <timeout> <Launchpad itself:Fix Committed by edwin-grubbs> < https://launchpad.net/bugs/682727 >
<flacoste> jcsackett: can you QA bug 589584?
<_mup_> Bug #589584: merge proposal status is clickable but doesn't show hand cursor <ajax> <bugjam2010> <confusing-ui> <lp-code> <qa-needstesting> <trivial> <Launchpad itself:Fix Committed by jcsackett> < https://launchpad.net/bugs/589584 >
<EdwinGrubbs>  flacoste: it's done, I just marked it now.
<flacoste> thanks EdwinGrubbs!
<jcsackett> flacoste: qaing it now.
<jcsackett> flacoste: i'm having to hunt down another problem--the branch merge proposal page is OOPSing on qastaging on opening diffs, which isn't something i've modified.
<jcsackett> at least, i don't believe it is, and don't see the behavior on launchpad.dev with that branch.
<flacoste> jcsackett: you might ask abentley for help with that problem
<jcsackett> flacoste: thanks.
<jcsackett> abentley: i can't seem to open any branchmergeproposal page on qastaging--its OOPSing on trying to open the diff. thoughts?
<abentley> jcsackett, the librarian is FUBARed with old merge proprosals.  You could create a new one, but if you do, you'll need to manually run the scripts that update diffs.
<abentley> jcsackett, I recommend using staging instead.
<jcsackett> abentley: dig. thanks.
<abentley> jcsackett, because the cron scripts are run automatically.
<jcsackett> abentley: that makes sense.
<jcsackett> good to know it's an issue on qastaging, not with the code.
<flacoste> abentley: what needs to be fixed on qastaging for this to work properly?
<abentley> flacoste, the librarian doesn't fall back to the production data correctly.
<flacoste> abentley: do we have a RT for that?
<flacoste> are the losa aware of this problem
<flacoste> ?
<abentley> flacoste, I don't know, other people discovered this problem.
<abentley> flacoste, I just saw it discussed on IRC.
<flacoste> abentley: do you remember who was discussing it?
<abentley> flacoste, Sorry, no.  It was a while ago.
<flacoste> ok, i'll investigate
<benji> are LEPs meant to be kept up to date after they're implmented or are they simply historical?
<flacoste> benji: historical
<benji> cool, thanks
<rockstar> gary_poster, ping
<gary_poster> rockstar, pong, though I was seconds away from announcing lunchtime :-)
<rockstar> gary_poster, just wondering where your Tarmac mp went.
<gary_poster> rockstar: oh, thanks for following up!  I meant it to go to the lp fork, so I deleted the oe to trunk.  sorry for the noise
<gary_poster> one
<rockstar> gary_poster, does the bug not affect my upstream?
<gary_poster> no rockstar
<rockstar> gary_poster, ah, okay.  It looked like a pretty scary bug, so I was concerned.
<gary_poster> yeah, it was interesting rockstar :-)
<rockstar> gary_poster, thanks.  That's one less thing off my actionable list.
<gary_poster> cool, np
<rockstar> deryck, are you a good person to talk to about lazr-js stuff in Launchpad right now?
<rockstar> Basically, when I take an axe to lazr-js, whose life am I making more difficult?
<deryck> rockstar: I'm probably the best one to do that with, yes.
<rockstar> deryck, okay.  I don't think start of it will affect you too much, as the combo loader will get pulled out first, and you don't use that anyway.
<rockstar> deryck, but the build system will have to become part of Launchpad soon.
<deryck> ah, ok
<deryck> rockstar: sorry, internets are flaky in AL when it storms. ;)
<lifeless> flacoste: what did you think of my triage mail ?
<lifeless> flacoste: also I've forgotten the thing I was to mail you and jml about for consideration
<flacoste> lifeless: i liked it very much! there are a few things i'd like to clarify, but overall i found it very clear
<lifeless> awesome
<flacoste> lifeless: i don't remember what the other email should have been
<lifeless> what would you like to clarify ?
<flacoste> in the triaging guidlines, you didn't specify the bucket to use
<flacoste> i think you did that on purpose
<flacoste> maybe not
<lifeless> yeah, it was
<flacoste> you only say 'in front'
<flacoste> later than
<flacoste> etc
<flacoste> i understand the intent, but i think to be practical, we need to be more explicit
<lifeless> the problem with saying 'bucket x' is that we then have a scale problem: a large number of bugs matching <that rule> will swell <that bucket> without swelling our engineering resources etc
<flacoste> right
<flacoste> but we only have buckets
<flacoste> so 'in front' doesn't really mean anything
<lifeless> I can expand on that
<lifeless> (because it does mean something :))
<flacoste> i know it does :-)
<flacoste> but what it means operationally isn't clear
<lifeless> in that document we're saying that what we want is bugs that are less important than 'the least important in the high bucket' are low
<lifeless> and that queue jumpers only are critical
<lifeless> flacoste: so, we could do an experiment without an explicit rule->bucket mapping for 'high', and see if its hard for folk, or if the results after a week or two are inconsistent with what you'd like to have seen
<flacoste> so a bug escalated by a stakeholder would be marked critical?
<lifeless> flacoste: I think so, when we accept it.
<flacoste> ok
<flacoste> we will need to change our DefinitionOfCritical
<flacoste> well, rename it to DefitionOfAnIncident
<lifeless> flacoste: I think we need to make the definitionofcritical more clearly talk about operational incidents vs code changes
<flacoste> but i think that would be a good change
<flacoste> agreed
<lifeless> hah yes +1
<lifeless> poolie and I had an interesting discussion about 'how many high bugs should we have'
<lifeless> we expect about 1000 bugs closed a year by maintenance team work
<lifeless> tha suggests the critical backlog (https://bugs.launchpad.net/launchpad-project/+bugs?field.tag=timeout,oops) to be cleared in ~ 3 months
<lifeless> and after that ~ 500 bugs in high every 6 months
<lifeless> its possible that having 700 bugs in high (as we do) isn't a problem per se: thats a 9 month queue, yes, but in 9 months most bugs will still sort into the same bucket
<lifeless> flacoste: what do you think?
<flacoste> lifeless: that's my analysis also
<flacoste> and we should have a much shorter queue in a couple of months
<lifeless> flacoste: we'll see some movement, yes.
<lifeless> flacoste: I'd like to try tightening up the 'front' etc stuff in that section before we try making it more fixed
<lifeless> flacoste: because by the july epic we'll be needing to promote medium bugs to high - the goal posts should be shifting
<lifeless> flacoste: at the very least I'd like to do a re-triage of high bugs before writing declarative rules for what should be high
<lifeless> (so that the rules can reasonably match :))
<flacoste> lifeless: doing it like in your proposal would remove the need for a 'escalated' tag -- which i was toying with to mark out the queue jumper in the High bucket
<lifeless> flacoste: we may want such a tag for convenience in recall ('where are the escalated stakeholder bugs')
<flacoste> right
<flacoste> but we wouldn't need to hunt for it
<lifeless> but it wouldn't be needed for 'what do I need to work on next'
<flacoste> they would sort at the top because of their critical priority
<lifeless> right
<lifeless> and the initial critical bucket if we implement my proposal will be ~ 3 months deep
<lifeless> which is good
<lifeless> not brilliant
<lifeless> but a good starting point to clean up from
<flacoste> lifeless: OOPS, timeout and regression -> Critical ?
<lifeless> + escalted
<flacoste> + escalated
<flacoste> works for me though
<lifeless> https://bugs.launchpad.net/launchpad-project/+bugs?field.tag=regression
<lifeless> 6 bugs
<flacoste> 172 oops
<flacoste> and 58 timeout
<lifeless> yeah
<lifeless> flacoste: ok, so IIUC you're actually ok as-is now with a little tightening around the meaning of front etc - perhaps a use case.
<lifeless> flacoste: were there other things in it that you'd like to clarify?
<flacoste> lifeless: no, that was it, really
<flacoste> lifeless: i found the whole rationale very clear
<lifeless> excellent
<henninge> jcsackett: I subscribed you to a bug on staging where our QA is failing. I am investigating.
<henninge> s/on staging//
<jcsackett> henninge: thanks for the heads up.
<thumper> arse
 * thumper wonders how to fix this
<lifeless> flacoste: popping into the doctor with Lynne, back soon
<flacoste> lifeless: ttyl
<thumper> flacoste: I have an issue with recipe builds
<flacoste> thumper: what's the issue?
<flacoste> (/me is on a call)
<thumper> flacoste: an early design decision was to have the recipe builds live under the recipe for the canonical url
<thumper> however the recipe for the build is now optional
<thumper> in order to maintain some traceability
<flacoste> meaning that the recipe can be deleted?
<thumper> which means we have some recipe builds without recipes
<thumper> which are "dead"
<flacoste> right
<thumper> yes, the recipe can be deleted
<thumper> but the builds live on
<flacoste> create a graveyard parent?
<thumper> well...
<flacoste> in canonical_url, pseudo-code:
<thumper> I wanted to have them hang off the ppa
<thumper> like ppa binary builds
<thumper> however both the binary build and the recipe build have exported themselves
<thumper> so in order to keep the wadl stable, we can't really change them
<flacoste> thumper: the URL isn't in the wadl
<thumper> I'd ideally like to move both binary builds and recipe builds to live under the same URL
<thumper> isn't it?
<thumper> that's interesting
<flacoste> it's not
<thumper> ~user/+build/<buildfarmjobid>
<flacoste> only the schema is part of the wadl
<thumper> hmm...
<thumper> so this may well be fine then
<flacoste> the url is part of the documentation
<thumper> ok
<thumper> perhaps I may bug wgrant about this when he is up
<thumper> just to make sure I don't fubar anything important
<abentley> flacoste, wow, really?  We have a RESTful API that doesn't specify the URLs of anything?
<flacoste> abentley: we don't because everything is discoverable
<flacoste> through introspection
<flacoste> _link
<flacoste> you get a resource and then navigate the object graph
<thumper> abentley: lucky us I guess :)
<flacoste> or call methods and get back references
<flacoste> only the service root is a well-known name
<abentley> thumper, kinda.  I'm not sure whether our javascript would handle URL changes gracefully.
<thumper> abentley: what do you mean?
<abentley> thumper, it doesn't use launchpadlib, so it may have hand-crafted URLs in places.
<thumper> I don't think we have many of those...
<thumper> I could be wrong
<abentley> thumper, I'm changing merge proposals so that only recently-used proposal targets are suggested.  Where should I test it?  Test the widget?  Extract a vocabulary and test that?  Test the +register view?  The current tests are pagetests.
<thumper> I think test the widget, or test the code that the widget uses
<flacoste> abentley: we usually don't generate url directly in the JS
<flacoste> well we shouldn't
<flacoste> the LP.client is the launchpadlib analog
<flacoste> or they are generated properly server-side
<elberry> hello, I need some help installing launchpad in a VM.
<elberry> After getting rocketfuel-setup, and running it. I'm prompted for my launchpad username. It doesn't seem to work though. Whenever I type in my lp username and password, I continue to get the password prompt.
<elberry> and I'm unable to get past this point as simply hitting enter after being prompted for my username results in the default username being used.
<leonardr> flacoste: i believe we do generate lots of urls in the js, because the ajax environment doesn't support navigation the way a custom client does
<flacoste> leonardr: right, but usually either server-side, isn't?
<flacoste> by or by using the json dump of the context
<gary_poster> poolie, lifeless, we'd like input from one or both of you on https://bugs.launchpad.net/launchpad/+bug/636193 .  Might be quick reply, might not.
<_mup_> Bug #636193: feature flags need to self document <feature-flags> <lp-foundations> <Launchpad itself:Triaged by benji> < https://launchpad.net/bugs/636193 >
<wgrant> thumper: It should be fine. Just change the PPA +build traversal to use PackageBuild instead of BinaryPackageBuild.
<thumper> wgrant: actually we are considering /+build/<build-farm-job-id>
<thumper> wgrant: for all build farm jobs
<thumper> wgrant: which includes the translation jobs
<wgrant> thumper: Translation jobs don't have an archive.
<thumper> wgrant: so removing the inside part of binary package buids
<thumper> wgrant: exactly
<thumper> no archive
<wgrant> I don't immensely like the sound of that.
<wgrant> But perhaps.
<thumper> wgrant: that way we have a consistent url for all build farm jobs
<wgrant> PackageBuilds are naturally contained within an archive. It makes sense to have the traversal under an archive.
<thumper> wgrant: the question becomes "do we want consistency for all jobs" or "do we want the containment"
<thumper> wgrant: since translation jobs don't have archives
<thumper> wgrant: they are not currently traversable
<wgrant> thumper: Jobs are not primarily jobs.
<thumper> wgrant: but we may well be interested in the state or log files
<wgrant> Jobs exist to serve their assigned tasks.
<wgrant> The assigned task should come first, not the jobness.
<thumper> wgrant: you could argue that the build jobs happened on builders, so that is the natural parent
<thumper> (I'm not saying that I am arguing that)
<thumper> abentley brought up the argument of "why treat translations differently?"
<wgrant> thumper: Jobs don't have builders to start with, so that can't work.
<wgrant> And I think translations jobs probably belong under a branch.
<thumper> good point
<thumper> wgrant: do all binarypackagebuilds now have a buildfarmjob id ?
<thumper> wgrant: through the packagebuild table?
<wgrant> thumper: Yes.
<thumper> wgrant: we could have uniqueness through either the package build id, or the build farm job id
<thumper> wgrant: since there is already a buildfarmjobset that gets jobs through the id, and the specific job method
<thumper> wgrant: I'd be inclined to use that
<wgrant> Probably.
<gary_poster> hey poolie.  We wanted your and/or lifeless' input on https://bugs.launchpad.net/launchpad/+bug/636193
<_mup_> Bug #636193: feature flags need to self document <feature-flags> <lp-foundations> <Launchpad itself:Triaged by benji> < https://launchpad.net/bugs/636193 >
<gary_poster> For one, benji took that.  If you really want it, just let us know. :-)
<poolie> yay benji!
<gary_poster> lol :-)
<gary_poster> For another, we have some implementation questions.  benji put them on the bug, so you can see what the story is there
<poolie> i'm going to the rally tomorrow so i'm not likely to work on it fro the next few weeks
<poolie> i see
<poolie> but perhaps benji and i can pair at the thunderdome? that could be fun
<gary_poster> that could be fun, though we've been asked to bring these tasks to completion so feature flags can be declared "done"
<gary_poster> thunderdome isn't too far away though :-)
<gary_poster> if you can give us some quick direction, please do; otherwise, you can make that request/suggestion :-)
<poolie> i will do that on the bug
<gary_poster> many thanks
<poolie> right now
<gary_poster> even better ;-)
<poolie> he (or you) are welcome to give me a call any reasonable time to talk about things if you want to
<poolie> even if i'm not answering irc
<poolie> between say 08:00 and 19:00 utc+11
<poolie> (not next week of course)
<gary_poster> awesome, thank you
<gary_poster> right :-)
<lifeless> gary_poster: I've commented on the bug FWIW
<gary_poster> oh, lifeless, thanks!  sorry, I didn't see.  I still need to set up my mail rules in some new clever way :-/
<lifeless> gary_poster: oh, I just did now when yo umentioned it
<gary_poster> lol, oh ok, cool
<lifeless> I has a -big- mail backlog
<gary_poster> ;-) gotcha
<lifeless> 10K messages over my holiday
<lifeless> down to 9K as of this morning
<gary_poster> heh, congrats
<gary_poster> need to run.  night all
<bryceh> When I run launchpad via 'make run', and then browse around, each page takes several minutes to load.  In the make run output I see it printing a huge number of apache log messages about transferring language files
<bryceh> e.g. GET /+icing/rev9918/yui/datatype/lang/datatype_zh-Hans.js
<lifeless> tip should be better
<lifeless> be sure to do make jsbuild
<bryceh> lifeless, well I can't get tip because rocketfuel-get fails
<bryceh> on mailman
<lifeless> bryceh: yeah, I linked the bug to you in this channel
<bryceh> lifeless, no, I looked at that bug but is seems to not be relevant.  The files they say are missing, are present, and the versions/names of packages it said to load are already present on the system.
<lifeless> ok
<lifeless> not sure then
<bac> StevenK, thumper, mwhudson, wgrant, lifeless: you all around for a reviewers meeting?
<thumper> I'm around
<bac> top o' the hour?
<thumper> aye
#launchpad-dev 2011-01-06
<bac> StevenK, thumper, mwhudson, wgrant, lifeless: meeting ping
<mwhudson> hi
<thumper> oh FFS
<thumper> something worked in make harness
<thumper> I changed something unrelated
<thumper> and now it doesn't
<thumper> stupid effing python
<thumper> ah...
<thumper> stupid flush
<thumper> object created, but not in DB
<lifeless> man, I hate presentation software
 * wgrant tends to use beamer.
<lifeless> I don't write latex enough to be very efficient in it
<lifeless> I've done a few pressies in it
<lifeless> wgrant: did you see stubs comments on archive:+index?
<spm> presentation s/w is a classic case of (over)features over what you actually need. a *good* presentation will use the barest minimum of the feature set provided by the software.
<spm> text in font/size on a page; add pictures. have > 1 pages. fin.
<wgrant> lifeless: I did.
<wgrant> I've got a few other things to do today, but I will hopefully be able to look at it later.
<lifeless> spm: yes yes; you saw my epic talk yeah?
<wgrant> SO MANY SLIDES
<spm> only your drafts of the presenattion; not the delivery
<lifeless> still, minimal text on a slide
<spm> yup
<lifeless> sadly the subject matter was huge ;(
<spm> :-)
<spm> wgrant: # of slides isn't a problem per-se. so long as you have 1 to 2 messages you want to communicate. the slides are there to reinforce what you're saying.
<wgrant> Sure.
<spm> it's when someone uses the sides as the key part of their speech, that they're sunk.
<mwhudson> spm, lifeless: console-presenter!
<spm> snort
<spm> but yes, agreed :-)
<StevenK> I'm trying to remember what I used to give a talk at Debconf5
<lifeless> mwhudson: still haven't gotten around to looking at it
<lifeless> mwhudson: whats the learning curve?
<StevenK> .. dialog, I think
<mwhudson> lifeless: very short, but setting up a background image is a bit of a fiddle
<mwhudson> it's probably a bit too minimal to be useful, in all honesty
<wgrant> Nice transitions.
<mwhudson> :-)
<mwhudson> i wrote it during a rage at the first epic
<wgrant> My eyes...
<mwhudson> ah yes
<wgrant> The pure uncommented evil at the end of present.py is delicious.
<lifeless> poolie: if you want to talk, now would be best
<poolie> now is great
 * thumper kicks off an ec2 test before moving laptop
<lifeless> poolie: grabbing a drink
<lifeless> === Top 10 Time Out Counts by Page ID ===
<lifeless>     Hard / Soft  Page ID
<lifeless>      108 / 5131  Archive:+index
<lifeless>       79 /  307  BugTask:+index
<lifeless>       52 /  291  Distribution:+bugs
<lifeless>       15 /  121  ProjectGroupSet:CollectionResource:#project_groups
<lifeless>       13 /  349  Distribution:+bugtarget-portlet-bugfilters-stats
<lifeless>       13 /    5  ProjectGroup:+milestones
<lifeless>       11 /    1  Distribution:+builds
<lifeless>        8 /   33  MailingListApplication:MailingListAPIView
<lifeless>        8 /   18  DistroSeriesLanguage:+index
<lifeless>        6 /   12  NullBugTask:+index
<wgrant> StevenK: Are you still on maverick?
<StevenK> wgrant: Yes
<lifeless> poolie: that https://code.launchpad.net/ubuntu/+activereviews is a 404
<wgrant> StevenK: Could you see if the buildbot failure is reproducible?
<wgrant> StevenK: It explodes anyway on natty, so I can't really.
<poolie> https://bugs.edge.launchpad.net/launchpad/+bug/697962
<_mup_> Bug #697962: want view/feed/subscription of all distro mps <udd> <Launchpad itself:New> < https://launchpad.net/bugs/697962 >
<lifeless> thanks
<StevenK> http://pastebin.ubuntu.com/550931/
<StevenK> Wha? I'm confused
<wgrant> StevenK: Same here.
<wgrant> jsbuild was changed yesterday, I believe.
<wgrant> Seems relevant.
<wgrant> StevenK: It seems to work once I blow away lazr-js/build.
<wgrant> Must have had an old YUI.
<wgrant> lifeless: Do we have a reasonable strategy for HA-poppy?
<StevenK> wgrant: I can't even see how to run launchpadlib's doctests ...
<wgrant> StevenK: "bin/test -1cvvvt introduction.txt" should do it.
<lifeless> wgrant: yes, you and I sketched one out
<lifeless> I don't know if it was rt'd
<lifeless> wgrant: I do know I filed bugs on the race condition
<wgrant> lifeless: The race condition makes that strategy unreasonable :(
<wgrant> And I don't think fixing it is easy.
<lifeless> wgrant: things that are worth doing are often not easy
<lifeless> if you want to discuss this again, hop onto skype; I can make time to talk about it, but am a bit over my keyboard at this time of night
<lifeless> the price would be that you write up what we come up with somewhere :)
<StevenK> wgrant: introduction.txt passed. In 31 seconds :-(
<lifeless> wgrant: yes/no ?
<wgrant> lifeless: I should probably discuss with Julian first.
<wgrant> StevenK: Hmm. A forced build may be in order.
<wgrant> Yay...
<lifeless> wgrant: up to you; I have a couple of missing bits of knowledge to describe a solution; you could fill them in for me if you wanted.
<lifeless> wgrant: ok, taking that as 'no' ;)
<lifeless> wgrant: fwiw I don't see why our strategy wouldn't work even with the race. We catered for it in our design IIRC.
<al-maisan> Good morning !
<stub> Anyone happen to know offhand how I land an approved change to launchpadlib? https://code.launchpad.net/~stub/launchpadlib/dynamiclibrarian/+merge/44657
<wgrant> stub: It's pretty boring. Grab trunk, merge into it, update NEWS if relevant, and commit with the right [r=*] etc in the message.
<wgrant> No PQM nastiness.
<stub> wgrant: ta
<wgrant> Actually, it's probably even documented.
<wgrant> Indeed, on https://dev.launchpad.net/HackingLazrLibraries
<wgrant> Hrmph.
<wgrant> buildbot failed again.
<wgrant> Maybe this is lucid-specific :/
<adeuring> good morning
<wgrant> Does anybody still have a Lucid machine which runs LP?
<mrevell> Hello
<lifeless> stub: \o/ librarian landed thank you!
<stub> Cool. Was the only thing left the launchpadlib fix?
<lifeless> I don't know, I just saw it toggle to merged...
<lifeless> or I may be fundamentally confused
<lifeless> confused it most liskely ;)
<bigjools> good morning
<lifeless> stub: ah I was confused; its the launchpadlib fix I just saw
<lifeless> stub: which is great to land, but I don't know if its the be-all
<stub> Its near the end anyway
<jcsackett> wgrant, you wouldn't still be on, would you?
<wgrant> jcsackett: I am, unfortunately.
<wgrant> What's up?
<jcsackett> any chance you could qa your branch related to bug 45270?
<_mup_> Bug #45270: Publisher configuration needs redesign  <lp-soyuz> <qa-needstesting> <soyuz-publish> <tech-debt> <Launchpad itself:Fix Committed by wgrant> < https://launchpad.net/bugs/45270 >
<jcsackett> henninge has encountered a problem on a branch of his earlier in the queue, but now i need to clear out everything else so his fix can land too when we deploy.
<wgrant> jcsackett: oh, sorry. Forgot about the db-stable deployment report.
<jcsackett> wgrant: no worries. it's an easy one to forget if you're not doing the release. :-P
<wgrant> However, that rev is fine.
 * wgrant qa-ok's.
<wgrant> jcsackett: Sorry about that. It's fixed now.
<jcsackett> wgrant: thanks!
<jcsackett> henninge: how are things going?
<henninge> jcsackett: it's a bit complex but getting there
<jcsackett> i'm guessing your earlier estimate of qa by today is shot? how likely does before we need to merge db into devel sound?
<jcsackett> henninge ^
<henninge> jcsackett: not sure but there won't be any db changes, so that would not really be a problem for us.
<jcsackett> henninge: well, but the recife revision needs to be known deployable by then.
<henninge> right
<jcsackett> henninge: i guess i'm asking, will recife be qa-ok in some form by then, or do we need to start talking other options?
<henninge> jcsackett: it will be "qa-ok" in some form, partly because we don't really have any other options.
<jcsackett> henninge: well, there's roll-back and re-land after, but i think we'd both really rather not go down that road. :-)
<henninge> jcsackett: we landed quite a few revisions in db-stable this cycle that depend on recife. Having to back them out would be a greater mess, I expect.
<henninge> jcsackett: no, we don't
<henninge> ;)
<jcsackett> henninge: i see the later bugs on db-stable. do you think someone else can qa those so you can focus on the fix branch you're working on? i'm happy to try qa-ing them if that would help you out.
<henninge> jcsackett: jtv can probably qa those but mostly they will be qa-ok together with recife as it's all the same story.
<jcsackett> henninge: ah. i see. okay. mind if i ping you again at the end of your day to see where things stand?
<henninge> jcsackett: sure
<henninge> jcsackett: thanks for pinging
<jcsackett> henninge: thanks for the update. :-)
<henninge> ;)
<deryck> Morning, all.
<leonardr> jml, i'm figuring out what to say about the buildbot failure, but after that i'd like to talk to you about the web service demo for thunderdome
<allenap> bigjools: Do you know if this is worth pursuing? https://code.launchpad.net/~dhillon-v10/launchpad/fix-bug-410331/+merge/19766
<bigjools> allenap: not really, it was too much like hard work for a tiny gain
<allenap> bigjools: Shall I comment and mark it rejected?
<bigjools> yeah, he didn't reply to the last comment requesting tests
<leonardr> jml, buildbot failure is hopefully resolved. let me know when you have time to talk demo
<abentley> gary_poster, I'm trying to write a unit test for the TargetBranchWidget and having trouble creating an instance of the widget.  Do you know what widgets are supposed to take as their input?
<gary_poster> abentley: on calls
<benji> abentley: I'm looking into your question.
<abentley> benji, I've answered that one with a little pdb.
<benji> cool
<henninge> What's the easiest way to see the query that storm has composed?
<bigjools> LP_DEBUG_SQL
<jcsackett> henninge: it's near your EOD, right? have just a sec for an update on recife?
<henninge> jcsackett: it is but I will be working a little longer.
<henninge> jcsackett: The fix is almost complete. ;)
<jcsackett> henninge: that's what i was hoping. :-)
<jcsackett> henninge: aside from that issue, is recife looking good?
<henninge> jcsackett: always has! ;)
<henninge> jcsackett: it is a very complex change and we are aware that we won't catch all issues beforehand.
<jcsackett> henninge: dig. in the db-stable report i'm seeing what looks like the recife merge holding up revisions. https://devpad.canonical.com/~lpqateam/qa_reports/deployment-db-stable.html
<jcsackett> the bug 611668 is the relevant one; can we mark that qa-ok?
<_mup_> Bug #611668: getPOTMsgSetWithNewSuggestions upstream <lp-translations> <qa-needstesting> <recife> <upstream-translations-sharing> <Launchpad itself:Fix Committed by henninge> < https://launchpad.net/bugs/611668 >
<henninge> jcsackett: done ;)
<jcsackett> henninge: excellent. thanks a lot, and have a good evening. :-)
<henninge> jcsackett: ah sorry, I had to revert that :(
<henninge> jcsackett: I just saw that that revision is linked to the wrong bug.
<henninge> jcsackett: that revision is the main recife merge and that is currently qa-bad until the bug is fixed that I am working on.
<jcsackett> henninge: okay. but you think the bug you are working on will be ready to for review/land soon? i would like this all to make the deadline for when db-stable gets merged.
<jcsackett> otherwise we cannot deploy it, or anything after it.
<henninge> jcsackett: yes, it will be ready for review soon.
<jcsackett> henninge: excellent. :-)
<henninge> the real master bug is bug 681930, I don't know why the revision was tagged with the wrong bug. Probably copy-and-paste error on my side.
<_mup_> Bug #681930: Share translations between Ubuntu and upstream projects <bad-commit-10008> <lp-translations> <qa-needstesting> <upstream-translations-sharing> <Launchpad itself:Fix Committed by henninge> < https://launchpad.net/bugs/681930 >
<jcsackett> that is weird.
<jcsackett> henninge: it's linking to that revision because the revision connected to 681930 was rolled back, i think.
<jcsackett> henninge: honestly, i am not sure how some of the revisions are being determined in the report. very odd.
<henninge> jcsackett: Well, in this case it looks like the wrong bug is mentioned in the commit message.
<henninge> I wrote that message out manually because of all the reviewers and I must have pasted the wrong bug id.
<jcsackett> henninge: ah, okay.
<jcsackett> so even though the actual bug listed in the report is qa-ok, we're marking qa-bad so we don't mark recife as qa-ok. i wonder if there's a way to sort that out...
<jcsackett> okay, i see, we also have the fixes for the actually linked bugs included in that revision. so while the report is misleading, we're basically okay once your fix is landed and we can mark recife and your fix qa-ok.
<lifeless> gary_poster: do you know how to add OOPS prefixes?
<gary_poster> lifeless: vaguely.  I could wing it.  I thought matsubara-afk had done some for you in the past day or two?
<lifeless> gary_poster: he may have, I haven't corresponded with him specifically though
 * lifeless really wants to eliminate all this manual friction
<gary_poster> ah you mean friction of having to specify prefixes
<gary_poster> yes, would be nice
<lifeless> both specifying them in configs for appservers and in the oops reporting toolchain
<lifeless> gary_poster: anyhow
<lifeless> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1832CBB446
<gary_poster> lifeless, matsubara-afk reported in team calls that he had added some prefixes for you.  I don't know anything else--how he knew you needed them, or anything else.  Is there a bug for this?
<lifeless> isn't showing up
<lifeless> I'm guessing CBA isn't either
<lifeless> gary_poster: there is a bug that nothing audits to check we have them all covered
<lifeless> gary_poster: I don't know which are covered, so I can't sensibly file a bug asking for specific prefixes
<lifeless> gary_poster: and I don't know where to check to see which are covered ;)
<gary_poster> lifeless: a Django tool named "South" populates the DB.
<gary_poster> https://bazaar.launchpad.net/%7Elaunchpad-pqm/oops-tools/trunk/files/head%3A/src/oopstools/oops/migrations/ has the updates and https://bazaar.launchpad.net/%7Elaunchpad-pqm/oops-tools/trunk/annotate/head%3A/src/oopstools/oops/migrations/0015_populate_prefix_groups.py is the most recent pertinent data AFAIK.
<gary_poster> I see neither CBB nor CBA.
<lifeless> give me a sec and I'll generate a list of what we have in use
<gary_poster> I have calls and other tasks for the rest of the day and I don't know if we have fixed the "only Diogo can deploy" bug filed just before Christmas break.  I suggest making a bug, and I'll ask Diogo to treat it as his top priority tomorrow morning.
<lifeless> ok
<lifeless> thanks for the help
<gary_poster> np
<micahg> jcsackett: hi, can I chat with you about bug 697685?
<_mup_> Bug #697685: People with PPAs should not be allowed to merge accounts <merge-deactivate> <ppas> <Launchpad itself:Triaged by jcsackett> < https://launchpad.net/bugs/697685 >
<jcsackett> micahg: sure.
<jcsackett> what's up?
<micahg> jcsackett: I was wondering, I assume the issue is due to unique paths for the PPAs, right?  would it be possible to alias both sets of PPAs to both accounts?
<micahg> assuming no name collision
<lifeless> gary_poster: https://bugs.launchpad.net/oops-tools/+bug/698300
<_mup_> Bug #698300: refresh oops prefixes / reports <OOPS Tools:New> < https://launchpad.net/bugs/698300 >
<lifeless> micahg: there are several reasons
<lifeless> micahg: one is that we don't have code to handle renames of the archives on germanium
<lifeless> micahg: another is that the ppa model isn't amenable to merging of content in any trivial fashion
<micahg> lifeless: ok, I'm guessing those bugs have already been filed in some fashion?
<lifeless> I don't know that they have
<lifeless> some of this stuff was envisioned as too-hard and requests marked WONTFIX
<lifeless> I'd be fine having a wishlist item to address the,
<lifeless> but it is a significant chunk of work in various ways - but someone that wanted to make it work would be welcome to contribute patches
<micahg> lifeless: ok, just thought I'd mention it, I can look for a bug later I guess
<lifeless> please do
<micahg> lifeless: thanks
<lifeless> flacoste: ping
<flacoste> hi lifeless
<lifeless> flacoste: whats the protocol for asking mkanat to do stuff
<lifeless> https://bugs.launchpad.net/loggerhead/+bug/698305
<_mup_> Bug #698305: no such revision triggers an OOPS <oops> <loggerhead:Triaged> < https://launchpad.net/bugs/698305 >
<flacoste> lifeless: talk to poolie
<lifeless> flacoste: cool, will do - thanks
<lifeless> poolie: ^
<lifeless> flacoste: do you know whats up with bug 547036 ?
<_mup_> Bug #547036: The buildd code should be removed from the Launchpad tree <canonical-losa-lp> <lp-soyuz> <tech-debt> <Launchpad itself:Triaged> <Launchpad Auto Build System:Triaged> < https://launchpad.net/bugs/547036 >
<lifeless> I don't understand the issue
<flacoste> lifeless: buildd code is in launchpad
<flacoste> but it's deployed independantly
<flacoste> and really has no relationship to the rest of the code
<flacoste> lamont wants it out for easier packaging
<flacoste> and release management
<flacoste> lifeless: if you were wondering about the discussion about what prevents it from being separate at this time, i don't have any idea
<lifeless> flacoste: well, I was looking at it and various test fixture glue got in the way
<flacoste> yep, that's what i read from the bug report
<lifeless> anyhow, the thing for me is that really the code in question shouldn't be in the buildd tree either
<lifeless> its common code
<lifeless> flacoste: what prompted the escalation?
<flacoste> lifeless: IS call
<lifeless> flacoste: it would help me understand whats going on if you can add a comment when escalating things like this - it looks uninteresting otherwise ;)
<flacoste> right
<flacoste> i will
<lifeless> that would be awesome! thank you
<lifeless> flacoste: I would like to know what functional issue they experienced to make this a priority rather than tech-debt
<lifeless> flacoste: as data for things-we-should-fix
<flacoste> lifeless: best to ask lamont direcly
<pcjc2> Are there any bug team devs about?
<lifeless> whats up
<pcjc2> nothing important, was just hoping to get a bug import done
<pcjc2> I've got our SF trackers disabled, so was hoping to get a quick transition
<pcjc2> https://answers.launchpad.net/launchpad/+question/140463
<pcjc2> There was also https://answers.launchpad.net/launchpad/+question/140410 (got assigned to Deryck as he's team lead, but he's not about)
<pcjc2> On reflection I should probably not have filed two questions which appear identical (apart from the filename)!
<lifeless> flacoste: who actually /does/ imports ?
<lifeless> flacoste: losa?
<flacoste> lifeless: yes, i think so
<flacoste> lifeless: deryck had details in his latest state of bugs email
<lifeless> thanks
<pcjc2> flacoste: is that email public / archived, or canonical internal?
<pcjc2> (just curious)
<flacoste> pjdc: launchpad-dev, so public and archived
<lifeless> flacoste: actually it doesn't say who does them
<lifeless> only that its painful
<lifeless> pcjc2: The State of Malone in the launchpad-dev list archives
<pcjc2> https://lists.launchpad.net/launchpad-dev/msg05983.html ?
<pcjc2> "story" is use-case driven development?
<lifeless> roughly
<lifeless> pcjc2: so do you want these imported to staging first, or you're totally ready?
<lifeless> pcjc2: so the sad news is the dude that knows all had a personal emergency today and isn't around
<lifeless> I will try to get the knowledge and have these acted on for you
<pcjc2> hmm - if I say "I'm ready", there will be some issue I spot 5 minutes after the import
<pcjc2> If we go via staging... all will be fine.. and we'll spot an issue 5 minutes after the real import ;)
<pcjc2> It "should" be ok. I've had a round on staging before
<pcjc2> Have tested the imports on my local dev instance too
<lifeless> ok
<lifeless> pcjc2: so testing locally yo ujust run bug-import.py -p pcb
<lifeless> yes?
<pcjc2> indeed
<pcjc2> (already contributed a round of patches which should now be on the production servers ;)
<pcjc2> (had to fix that script up a tiny bit
<lifeless> have we landed your empty comments fix ?
<pcjc2> I think / hope so - bug was marked fix released
<pcjc2> if not, import will have to wait
<lifeless> do you remember the # ?
<pcjc2> checking
<pcjc2> https://bugs.launchpad.net/launchpad/+bug/692951
<_mup_> Bug #692951: Don't show <empty comment> placeholders for imported bug attachments <qa-ok> <Launchpad itself:Fix Released by pcjc2> < https://launchpad.net/bugs/692951 >
<lifeless> yup its live
<lifeless> apparently your webserver is very slow ;)
<pcjc2> which - the www2.eng.cam.ac.uk one?
<lifeless> yes
<lifeless> the sysadmin is having the download from there crawl
<lifeless> or are the files ginormous
<pcjc2> not huge, 5.8M, 10M
<pcjc2> could be the server is struggling I guess, not sure - its one I have access to
<jkakar> henninge: I just left a comment on bug 698344 with a workaround for the issue.
<_mup_> Bug #698344: Storm has no ROW constructor <Storm:New> < https://launchpad.net/bugs/698344 >
<pcjc2> hmm - read the email
<pcjc2> ran the rnv validator - got errors
<pcjc2> will have to get back you when I can get to fixing it, sorry for the noise
<lifeless> oh
<lifeless> thanks
<pcjc2> the geda_export.xml is fine
<pcjc2> the pcb_export.xml one causes problems - I'll note that in the question
<pcjc2> I have to go for now, might be back in a bit, otherwise tomorrow
<lifeless> pcjc2: we're about to do the geda one
<lifeless> I'm curious why you didn't see the errors with pcb in your run on staging ?
<henninge> jkakar: wow, cool. thanks!
<henninge> jkakar: actually, I had worked around it by  using SQL("(t1.c1, t1.c2)") but this is nicer ;)
<jkakar> henninge: Using "SQL" is almost always a hack. :)
<henninge> it is! ;)
<jkakar> henninge: It'd be nice if you created a branch to add a Row expression to Storm. :)
<henninge> jkakar: now that I know how I can do that
<henninge> :)
<jkakar> :)
<lifeless> pcjc2: https://bugs.launchpad.net/geda - still running
<lifeless> hey thumper, hows things?
<lifeless> pcjc2: geda is imported
<jelmer> lifeless: looks like we really need to increase the batch size for git imports
<jelmer> lifeless: fetching a branch, doing 30 seconds of work, then pushing it back and trying again 4 hours later is.. suboptimal
<jelmer> lifeless: argh, nevermind. I thought it was a new import.
<mwhudson> jelmer: it shouldn't wait 4 hours until the build farm is busy
<mwhudson> s/build/import slave/
<mwhudson> s/until/unless/
<mwhudson> sigh
<jelmer> mwhudson: yeah, it's actually an existing import..
<jelmer> mwhudson: :-)
<lifeless> jelmer: ECONTEXT
<jelmer> lifeless: None
<jelmer> lifeless: the geda import, but I was wrong
<jelmer> mwhudson: we should still fix the import batch size, but it's not as bad as I thought.
<lifeless> jelmer: its a bug import ;)
<lifeless> jelmer: not a branch import
<mwhudson> jelmer: well /really/ what would be nice is to import revisions for an hour, then checkpoint somehow
<jelmer> lifeless: argh, so not only did I misinterpret the results, I was looking at the wrong page.
<jelmer> mwhudson: yeah
<lifeless> jelmer: yes, you did :)
<jelmer> mwhudson: I'd really like to move the batch import thing upstream and see mirrors and imports use the same infrastructure.
<mwhudson> jelmer: upstream into bzr you mean?
<mwhudson> and yes, mirrors and imports using the same infrastructure would be nice
<lifeless> that sounds intruiging
<pcjc2> lifeless: Thanks!
<lifeless> pcjc2: so how did pcb work on staging if it had errors?
<pcjc2> well, I've done a LOT to the conversion scripts since the staging round
<pcjc2> had a lot of UTF8 encoding issues from the SF backup XML
<lifeless> ok
<lifeless> so, when you think its good
<pcjc2> It appeared to work fine on my local instance, but the validate fails
<lifeless> what validate was used?
<lifeless> we're updating our docs for this process
<pcjc2> pcb_output.xml:43292:276: error: element https://launchpad.net/xmlns/2006/bugs^milestone not allowed
<pcjc2> http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/annotate/head:/doc/bug-export.rnc
<pcjc2> as described here: https://help.launchpad.net/Bugs/ImportFormat
<pcjc2> ok, fixed the issue
<pcjc2> duplicated a milestone tag accidentally due to some copy+paste error in my convert script
<pcjc2> uploading new pcb_output.xml now
<lifeless> I've updated the ImportFormat page
<lifeless> mbarnett: ^
<lifeless> pcjc2: do you want a new staging import, or are you completely happy to go live?
<pcjc2> give me a minute to just quick-check here locally, then lets go live
<mbarnett> pjdc: same location as the last time?
<lifeless> I suggets a new url
<lifeless> to avoid possibility of FAIL
<mbarnett> that seems like a sane precaution
<lifeless> like ...2.xml or something
<thumper> lifeless: hi, just getting food
<pcjc2> changed URL to http://www2.eng.cam.ac.uk/~pcjc2/pcb_output_v2.xml
<pcjc2> lifeless: What changes did you make on the ImportFormat page?
<mbarnett> grabbing now
<pcjc2> lifeless: never mind.. I figured out how to use the wiki to get the change diff
<lifeless> pcjc2: new answers location, bullet list of the process
<pcjc2> will you enable bugs for the pcb project when the import is done?
<pcjc2> can I do it now?
<pcjc2> or is there a risk of collision?
<mbarnett> i think it makes sense to wait, to avoid any possible hilarity
<pcjc2> sounds sensible
<pcjc2> let me know when I can play ;)
<lifeless> pcjc2: enabling is up to you :)
<lifeless> pcjc2: did the new pcb validate for you?
<pcjc2> just wanted to be sure I didn't collide with the import
<lifeless> naturally
<pcjc2> validated fine once I fixed my double <milestone> tag
<lifeless> kk
<lifeless> mbarnett: ^
<mbarnett> pcjc2: the file as i downloaded it validated locally
<pcjc2> sha1 matches the updated file?
<pcjc2> my original upload failed to validate, but I caught it fairly soon
<pcjc2> perhaps you got the second file?
<mbarnett> 927f92d4efe8cd09f7eb6cbc6dd5a669ba5becab
<pcjc2> that is the fixed one, yes
<mbarnett> perfect
<mbarnett> i'll beging the import then
<pcjc2> please someone ping me next week to split out the cruft from the goodness in my patches to the SF update script
<pcjc2> having run it so many times, I coded up a little bit of sauce to download the attachments and cache them during the export, so when you tweak the script and re-run, you don't have to wait so long for downloads
<pcjc2> I really appreciate your help here - pandering to my impatience ;), and would like to be sure I give back based on the code I had to write to make the process smoother
<pcjc2> See https://bugs.launchpad.net/geda/+bug/698379  when addressed by its alias,  https://bugs.launchpad.net/geda/+bug/sf-1444319 my user account merge is not reflected - stale cache?
<_mup_> Bug #698379: gschem: redraw overlapping objects <gschem> <sf-bugs> <gEDA:Fix Released> < https://launchpad.net/bugs/698379 >
<pcjc2> NM - seems like a local web-browser cache problem. Shows correctly in Firefox (using epiphany until now)
<mbarnett> yay
<pcjc2> got to go now, will enable the bug tracker for PCB tomorrow
<pcjc2> did it work ?
<pcjc2> (can do it now if so ;))
<mbarnett> still processing
<mbarnett> took about 10 minutes for the previous run, so i suspect this will be a while yet.
<pcjc2> more overheads on a production machine than my local one I guess
<pcjc2> still, wasn't quick - the PCB one had ~ 2x as many bugs IIRC
<mbarnett> ooh, just finished.
<wgrant> cStringIO and StringIO's differing Unicode handling makes me cry.
<lifeless> yes
<pcjc2> superb - thanks so much for your help everyone
<pcjc2> wgrant: Did you see this nasty I had to write for an import?
<pcjc2> http://pastebin.ca/2039456
<wgrant> pcjc2: Ow.
<pcjc2> indeed - now, bedtime for me or I'll be in trouble ;)
#launchpad-dev 2011-01-07
<lifeless> off for a bit, back later to talk with bigjools
<thumper> oh FFS
<thumper> anyone else getting make build fail?
<wgrant> thumper: JS issues?
<thumper> OSError: [Errno 4] Interrupted system call
<thumper> writing WADL
<wgrant> Ah, not the same one then.
<wgrant> I've not seen that.
 * thumper is frustrated
 * thumper repulls
<wgrant> Is ec2 land broken for anyone else? NameError: global name 'AuthorizeRequestTokenWithBrowser' is not defined
<thumper> wgrant: I can't even get make build running on devel
<thumper> mwhudson: can you do a 'make clean build' on devel for me?
<thumper> mwhudson: I want to see if it is just me :)
<mwhudson> thumper: i'm running make build now as it happens
<wgrant> Ah, updating just pulled in a new launchpadlib.
<mwhudson> thumper: i want it to work though, so i'm not going to pull/make clean just yet :)
<thumper> it seems that the WADL generation is failing
<wgrant> thumper: WADL build worked on an up-to-date devel.
<thumper> I'm trying to run a test, and it fails too
<thumper> and I don't know why
<wgrant> Although I didn't clean.
<thumper> wgrant: didn't for me :(
 * wgrant cleans.
 * thumper tries yet again
<mwhudson> hm
<mwhudson> OSError: [Errno 2] No such file or directory: './lib/canonical/launchpad/icing/yui/dom/dom-style-ie-min.js'
<wgrant> mwhudson: rm -r lazr-js/build
<mwhudson> the thing i love about launchpad development is the reliable infrastructure
<mwhudson> wgrant: thanks
<wgrant> thumper: A clean devel build worked fine too :(
<thumper> it worked for me now
<thumper> test still failed
<wgrant> Uh.
<wgrant> launchpadlib 1.9.1 is broken.
<wgrant> launchpadlib/launchpad.py:206 references a class that no longer exists...
<mwhudson> nice
<mwhudson> http://www.netsight.co.uk/misc/xkcd-buildout.png/view
<lifeless> \o/
<wgrant> Yup.
<wgrant> I wonder if versions.cfg will like me downgrading launchpadlib to 1.6.5.
<mwhudson> that's quite a big downgrade?
<lifeless> no
<lifeless> the version numbers had quite a big upgrade
<mwhudson> heh ok
<wgrant> Yay, ec2 works again.
<mhall119> can someone tell me why this user is only having their identity URL passed back in the OpeniD response? http://ubuntuone.com/p/X2P/
<maxb> mhall119: LP only gives more than the identity URL to sites it has specifically been told to trust
<Ronnie> maxb: can you explain the differences between these 2 screenshots:
<Ronnie> http://ubuntuone.com/p/X2O/
<Ronnie> http://ubuntuone.com/p/X2P/
<Ronnie> both share the same root site, but got other response from lp
<maxb> huh. no, I cannot explain that
<StevenK> Different account
<StevenK> Look at the top line, "Logged in as"
<maxb> yes... but... why should that influence what data is passed?
<StevenK> maxb: I have no idea, but it's a difference
<Ronnie> maxb, StevenK ill try if i can get the openid request to lp
<Ronnie> this is the form HTML that is submitted to LP: http://paste.ubuntu.com/551335/
<Ronnie> for the user Ronnie
<wgrant> StevenK, maxb: I wonder if that account might not be linked to a Launchpad one.
<wgrant> Not sure how to check.
<maxb> Actually.... how does the login service know about LP team participation at all?
<maxb> Is the crazy cross-replica replication thingy still in place?
<wgrant> maxb: Yeah, it's all a bit nauseating.
<wgrant> We have triggers copying account, person and teamparticipation into lp_account, lp_person and lp_teamparticipation. Those three are replicated to the SSO DB.
<wgrant> I hope to eventually coerce people into doing it via the API instead.
<wgrant> But everyone seems happy enough with this replication madness...
<wgrant> Hm.
<wgrant> Almost bug #700000
 * spm starts filing bugs like a crazy bug filer
<mwhudson> spm: if they're all about loggerhead, no fair
<spm> mwhudson: no worries. I've gotten bored with reporting codebounce bugs anyway.
<rockstar> thumper, keep your own bugs. :) https://bugs.launchpad.net/launchpad/+bug/691563
<_mup_> Bug #691563: bundle merge plugin needs refactoring to improve how it handles errors and send emails <Launchpad itself:New> < https://launchpad.net/bugs/691563 >
<thumper> rockstar: it seemed to me it was a tarmac bug
<thumper> the code was in tarmc
<rockstar> thumper, no, launchpad maintains a fork of tarmac, and the bug is in that fork.
<thumper> ah...
<thumper> why does it have a fork?
<thumper> that seems like bollocks
<rockstar> thumper, because that bundle merge plugin is kind of bollocks.
<rockstar> It's necessary for launchpad because the test suite takes so long.
 * thumper sighs
<thumper> rockstar: shouldn't the plugin be a separate project
<thumper> ?
<thumper> or part of the LP tree?
<rockstar> thumper, no idea.  That's for the maintainer to sort out.
 * thumper sighs again
<rockstar> It might *kinda* be Tarmac's problem since plugins don't seem to play as well with Tarmac as they do with bzrlib.  I need to investigate that.
<mwhudson> wow, 'make build' just takes a ridiculous length of time now
 * thumper gets hit by the friday afternoon bug
<mwhudson> it could hardly be worse if lp was written in c++ :(
<thumper> mwhudson: that it does :(
<rockstar> thumper, yeah, I hit that about noon today.
<rockstar> mwhudson, are you going to the launchpad epic?
<mwhudson> rockstar: no
<mwhudson> going to the rally though
<thumper> mwhudson: ha... you miss out on the beer I was going to buy you
<rockstar> mwhudson, ah, I thought that was this week.
<thumper> rockstar: no, next
<mwhudson> if i'm going to spend 2 weeks away from home for work, it's not going to be in january
<thumper> rockstar: you aren't going either are you?
 * thumper wanders out of the office
<rockstar> thumper, no.  lifeless suggested it, but with U1 web losing a member soon, they won't spare the week for me to go.
<rockstar> I might have pushed harder if it wasn't in Dallas
 * mwhudson imagines that possibly uds-o will be more popular
<mwhudson> wgrant: did you unbreak ec2 land yet?
<wgrant> mwhudson: Probably needs a leonardr.
<mwhudson> ok
<wgrant> mwhudson: I just hacked versions.cfg back to launchpadlib 1.6.5
<wgrant> Then reran buildout.
<wgrant> All works.
 * mwhudson uses ec2 land from db-devel instead
<mwhudson> time for beer
<mwhudson> see some of you in dallas, i guess
<pcjc2> are all the scripts / pre-written sql / .... available in the LP sources?
<pcjc2> I saw mention of LOSA scripts somewhere, and wondered where they lived. (This was for playing with my local dev instance)
<wgrant> Most things should be scripts in the tree.
<wgrant> The LOSAs don't much like running SQL directly.
<pcjc2> thanks
<lifeless> === Top 10 Time Out Counts by Page ID ===
<lifeless>     Hard / Soft  Page ID
<lifeless>       67 /  350  POFile:+translate
<lifeless>       64 /  234  BugTask:+index
<lifeless>       46 /  325  Distribution:+bugs
<lifeless>       20 / 3690  Archive:+index
<lifeless>       20 /  346  Distribution:+bugtarget-portlet-bugfilters-stats
<lifeless>       10 /   81  MaloneApplication:+bugs
<lifeless>        8 /  212  Question:+index
<lifeless>        7 /  116  ProjectGroupSet:CollectionResource:#project_groups
<lifeless>        7 /   11  Archive:+copy-packages
<lifeless>        7 /    4  ProjectGroup:+milestones
<mrevell> Hello
<adeuring> good morning
<lifeless> bigjools: hi
 * bigjools wearily waves to lifeless
<lifeless> you need more sleep?
<bigjools> sleep, drugs, you name it
<lifeless> ugh
<lifeless> hope you're better for the thunderpic
<lifeless> so you wanted to talk realtime; I don't know if its urgent to do so or not, but i've split my day today so we can, nowish, if you want to.
<bigjools> should be ok for the epidome, thanks
<bigjools> lifeless: yeah, it would be useful to talk.  How much longer are you around?
<lifeless> its 10:30 pm now
<bigjools> oh, arse
<lifeless> so I'm here
<lifeless> but not hugely awake, definitely not going to be capable of rational thought for much longer :)
<bigjools> so, let me explain the problem
<lifeless> would voice be better?
<bigjools> and then you can decide if you want to leave it until later
<bigjools> yeah, if you can put up with my blocked-sinuses-voice
<bigjools> I'll just fire up the Quattro
<lifeless> I can
<bigjools> I'm on mumble
<lifeless> skype would be better mumble is still unbearable for me
<bigjools> ok
<lifeless> is that ok?
<bigjools> yup
<bigjools> now if skype would just connect
<lifeless> >-<
<bigjools> it's not connecting :/
<lifeless> I can ring your phone ?
<bigjools> it's finally in
<lifeless> hah, that threat made it connect
<lifeless> bigjools: https://dev.launchpad.net/Foundations/JobSystem
<jcsackett> henninge: i see your branch merged, how's it going?
<henninge> jcsackett: going well, we have not encountered any other problems.
<jcsackett> henninge: cool. can we qa-ok the blocked revision by 1400 UTC (i believe that's 1pm your time)?
<henninge> jcsackett: I was still waiting fot the build to finish - which I just see it has. ;)
<henninge> and it's 3pm my time (GMT+1 in the winter)
<henninge> ;)
<jcsackett> henninge: time zones are hard. :-P
<jtv> henninge: interesting obstacle to Q/Aâ¦ I don't have permission to set Launchpad usage on a test project in staging!
<jtv> Yet I *can* access the form.  Just can't post.
<henninge> jcsackett: technically I'd have to wait for the revision to be available on staging and verify that all is running well. We'll be doing more of that today.
<henninge> jtv: url?
<jtv> henninge: https://translations.staging.launchpad.net/wdiff/+configure-translations
<henninge> ah, danilo just did that. Maybe the permissions issue slipped qa?
<jtv> jcsackett: you worked on the new model for setting LP usage, right?
<jtv> henninge: danilo just did what?
<henninge> jtv: that page
<jtv> Well grr.
<allenap> gmb: I got that weird thing with kwallet yesterday. I purged kdebase-runtime to get rid of it.
<henninge> I reviewed it  ... and did some qa.
<jcsackett> jtv: yeah, some time ago. if you have .Edit permission on that project you should be able to change it.
<gmb> allenap: Ok, Ta. I'll give that a shot
<jtv> jcsackett: I don't, but I have Translation admin privs.
<henninge> jtv: I, too, would have assumed I could do it as a rosetta admin.
<jtv> We used to be able to do it.
<jcsackett> jtv: actually, i think that should do it too.
<jcsackett> jtv: translations were a little odd for the usage stuff (more roles to think about), i believe we went with as permissive a model as possible.
<jtv> And it works partially: I do get to access the form.  Only a POST breaks on me.
<jcsackett> jtv: that does sound like a bug.
<jtv> Rather.
<henninge> jtv: you can set the translation focus
<henninge> and the other stuff on that page
<jtv> Evidently.
<jtv> Just not usage, then.
<henninge> They used to be on different forms.
<henninge> This is not a regression, though. We weren't allowed to do that before either. We don't have Edit rights on projects.
<jtv> I thought we were allowed to set usage though.
<henninge> jtv: it's not "official rosetta" anymore, remember?
<henninge> official_rosetta
<jtv> So?
<jtv> We could set usage.
<jtv> We're being told we can still set usage.
<jtv> We can't set usage.
<jtv> â Bug.
<henninge> ok
<henninge> but then the bug is older than the creation of this new dialog?
<henninge> jtv: you should find a prooject owned by registry admins.
<jtv> â¹
<henninge> jtv: we are part of that team and so have edit rights on the projects
<henninge> I use gedit
<jtv> Thanks.
<henninge> gedit project.
<jtv> That should be in main.  âº
<henninge> ah yes, in main
<bigjools> If I type "launchpad" in the product search popup it says "too many matches" ....
<jcsackett> henninge: can you qa bug 690196 and bug 694703, or does doing so depend on the fix we're waiting on for staging?
<_mup_> Bug #690196: POTMsgSet.singular_text may need to be a method <lp-translations> <qa-needstesting> <Launchpad itself:Fix Committed by henninge> < https://launchpad.net/bugs/690196 >
<_mup_> Bug #694703: Make partial translations exports work for upstream <qa-needstesting> <upstream-translations-sharing> <Launchpad itself:Fix Committed by henninge> < https://launchpad.net/bugs/694703 >
<henninge> jcsackett: looking now.
<bigjools> how the heck can I end up with lib/mailman/Mailman/MemberAdaptor.pyc being owned by root?
<jcsackett> henninge: sorry to keep pestering you, but we're about 50 min from the original time for merge--how's it looking?
<henninge> jcsackett: one qa still missing but I just igned off the big one.
<jcsackett> henninge: fantastic! :-)
<bigjools> jcsackett: when is PQM closing?
<jcsackett> bigjools: i think we're still going with 1400 UTC, as henninge is in a position to qa everything blocking db-stable before then, i think.
<bigjools> ok.  Bugger.
<jcsackett> bigjools: what are you trying to land?
<bigjools> it's a one-liner to fix https://bugs.edge.launchpad.net/launchpad/+bug/699820
<_mup_> Bug #699820: BuildFarmJob.date_finished is set in two places <buildd-manager> <buildfarm> <tech-debt> <Launchpad itself:In Progress by julian-edwards> < https://launchpad.net/bugs/699820 >
<bigjools> I need it so I can do a graph
<bigjools> so not desperately urgent but kinda annoying :)
<jcsackett> bigjools: dig.
<bigjools> I can always ask for RC forgiveness
 * jcsackett nods.
<bigjools> I'll grab you later, thanks
<jcsackett> np. :-)
 * bigjools goes to eat while tests are running
<jcsackett> henninge: if you were able to qa-ok the big one, that implies bug 697845 is good too, right?
<_mup_> Bug #697845: Translations import script on staging fails <oops> <qa-needstesting> <upstream-translations-sharing> <Launchpad itself:Fix Committed by henninge> < https://launchpad.net/bugs/697845 >
<jcsackett> i am looking at it now and can mark it as such if you agree.
<bigjools> having said that, I've got some weird shit
<jcsackett> ?
<bigjools> running "make" or "bin/test" is blocking on opening the KDE wallet (like the gnome keyring)
<bigjools> WTF
<jcsackett> bigjools: the kde wallet is now used by launchpadlib, right? of course, that shouldn't come up in make...
<bigjools> urrrgghhh really?
<bigjools> this Is Bad (TM).
<bigjools> bin/compile_templates does it too
<jcsackett> bigjools: make clean it first, maybe? that seems to be the magic fix from time to time.
<bigjools> I did that :/
<jcsackett> one sec; i'll update my devel and see if i can replicate.
<bigjools> bin/compile_templates
<bigjools> (32547) KWallet::Wallet::openWallet: Pass a valid window to KWallet::Wallet::openWallet().
<bigjools> it works, except when running the tests as the librarian fails to start
<bigjools> re-created it on 2 desktops now :/
<bigjools> yeah, it seems to be launchpadlib
<jcsackett> it didn't replicate on mine, but then i realized i am a fool to think it would--i don't have wallet/keyring.
<bigjools> ah
<bigjools> what do you have?
<jcsackett> sorry, bigjools.
<jcsackett> i use wmii--so nothing.
 * jcsackett likes keyboard controls
<jcsackett> this is for my dev environment--i keep my launchpad stuff all set up in a VM.
<bigjools> I sent an email to -dev
<bigjools> it's caused by the log line above and the librarian layer sees "unclean output"
<jcsackett> henninge: we need qa for bug 694703
<_mup_> Bug #694703: Make partial translations exports work for upstream <qa-needstesting> <upstream-translations-sharing> <Launchpad itself:Fix Committed by henninge> < https://launchpad.net/bugs/694703 >
<pcjc2> hi guys.. have a bit of a problem - trying to setup bugmail to go to our old mailing list (mailman)
<pcjc2> but bugmail appears to originate from the LP account holder, not LP its-self. Is there any known way to make it work without having to accept non-members postings?
<maxb> pcjc2: Can Mailman accept based on the presence of a header? If so, match on an X-Launchpad-Message-Rationale: header being present
<pcjc2> couldn't see it, but will investigate
<pcjc2> maxb: Testing now - there is a spam filter which lets me match on headers
<pcjc2> (and choose to accept a message based on a given match) - but I'm not sure if it will get that far for a non-subscribed user... waiting for bugmail to be sent out, and we'll see ;)
<pcjc2> (Is bugmail a cronjob?)
* jcsackett changed the topic of #launchpad-dev to: Launchpad Development Channel | 11.01 Release Week 3 | PQM in RC for devel | RM: jcsackett | firefighting: - | Get the code: https:/â/âdev.launchpad.net/âGetting
<bigjools> benji: pingaling
<benji> bigjools: heh
<bigjools> benji: francis said you might be able to help with my launchpadlib problem - did you see my email to -dev?
<benji> I don't think so, let me look.
<bigjools> ok, thanks
<benji> bigjools: bummer; let me fire up my KDE VM and see if there's anything I can do about it
<bigjools> benji: the issue is that the stupid piece of crap PyKDE4 library is logging debug output :/
<bigjools> which makes the librarianlayer blow chunks
<benji> yep
<bigjools> though why that layer needs to use launchpadlib is interesting
<bigjools> I am looking at the PyKDE4 module to see if it has any "stop logging" parameters
<benji> +1
<pcjc2> https://launchpad.net/~pcb-bugs
<pcjc2> Is there anyway to make mail sent to that address come _from_ some fixed address, such as noreply@launchpad.net ?
<pcjc2> pcb-bugs@lists.sourceforge.netÂ  is going to bounce any non-subscribed users bug comments, which is not what we want
<bigjools> benji: I can see the problem, it's a bug in the keyring module
<bigjools> it's passing 2 args instead of 3
<bigjools> when calling openWallet
<pcjc2> And I've checked.. it isn't apparently possible to accept mail based on a header at that stage. Can spam filter it by headers... but mails from non-subscribed addresses are dropped into the moderation queue before the spam filter would get a chance to accept them
<benji> if that's the code I think it is, that's intentional (perhaps still a bug, but intentional); let me look at it
<benji> the above was directed toward bigjools
<bigjools> benji: http://api.kde.org/pykde-4.3-api/kdeui/KWallet.Wallet.html#obj188009484
<bigjools> "You can pass 0 if you don't have a window"
 * bigjools haxors
<bigjools> no luck
<benji> bigjools: right, 0 won't reduce the spurious output: http://pastebin.ubuntu.com/551502/
<bigjools> yeah just saw that
<bigjools> http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/kwallet_8cpp_source.html#l00257
<bigjools> it's using the kDebug ostream, there must be a way of changing that
<bigjools> log level
<bigjools> "kdebugdialog"
<bigjools> now, how do we script that
<bigjools> crap, it doesn't actually help
<bigjools> benji: it seems as though it's impossible to turn that output off :/
<bigjools> there's a bug in the logger somewhere
<benji> bigjools: I'm pursuing making a do-nothing window to pass it so it won't log the message
<bigjools> that'll work
<benji> bigjools: will you try this patch to see if it fixes it for you? http://pastebin.ubuntu.com/551508/
<bigjools> yup, one sec
 * benji turns on the coffee pot in the meantime.
<bigjools> benji: success!  I had to use this diff though: http://pastebin.ubuntu.com/551512/
<benji> bigjools: correct me if I'm wrong, but that looks the same sans some whitespace
<benji> (same as my patch)
<bigjools> benji: you were using "kwallet_module"
<bigjools> that's not in my egg's code
<benji> oh, I'm using the trunk which changed that a little, cool
<bigjools> mine was grabbed not so long ago, is it out of date already?
<benji> the current python-keyring trunk hasn't been released; I'll make this change and do a release today
<bigjools> ah ok
<bigjools> you probably want to add a comment about that weird code :)
<bigjools> benji: thanks a million for helping, I am unblocked
#launchpad-dev 2011-01-08
<lifeless> wgrant: hi
<lifeless> wgrant: do you know of any soyuz services that do librarian uploads (directly)
<wgrant> lifeless: process-upload.py, buildd-manager, process-pending-packagediffs.py
<wgrant> There may be more... thinking...
<wgrant> gina
<wgrant> Possibly process-accepted.py, for translations stuff.
<wgrant> Also the mirror prober, although most seem so not think that it's Soyuz.
<lifeless> wgrant: there is an rt needs to know
<wgrant> lifeless: Which ticket?
<lifeless> wgrant: HA librarian upload, in the launchpad queue
<lifeless> wgrant: we need the machines those soyuz things run on added to firewall rules
<wgrant> lifeless: Perhaps the ticket is not visible to warthogs.
<wgrant> I cannot see it.
<lifeless> bah
<lifeless> uhm
<lifeless> it is visible to warthogs
<lifeless> 41379
<lifeless> wgrant: ^
<wgrant> lifeless: Oh, it's using a custom status that's not in the default filter.
<wgrant> lifeless: So: cesium, cocoplum, germanium, iron at least need adding to the list.
<wgrant> I'm also somewhat surprised that loganberry isn't there.
<pcjc2> is there any guide / examples which I could follow for writing a git commit hook to change bug statuses in LP ?
<pcjc2> I'm figuring that I need to setup a LP account for my "commit hook", so it can authenticate as "gpleda.org Commit Hook robot" or something
<pcjc2> The intention is to parse our git commits for "Closes-bug: lp-12345", and turn that into an API request which closes the bug
<pcjc2> I figure it is easiest to have the robot user close the bug, but it would also be possible (in theory at least), to grab the committer / author email from the commit, look them up on LP (or via a mapping table we could maintain locally), then _pretend_ the bug closure was done by that user
<pcjc2> (Although I'm not sure how to go about getting developers to authorise the robot to close bugs on their behalf)
<maxb> to do that, the robot would have to have access to impersonate all your committers. Unlikely they'd accept that
<pcjc2> "they" as in LP, or "they" as in our developers?
<maxb> the rest ought to be pretty trivial with python's launchpadlib
<maxb> b = lp.bugs[12345]; b.status = "Fix Released"; b.lp_save()  ---- or thereabouts
<pcjc2> Getting the robot to authenticate might be an issue, but I've not read into it so much
<pcjc2> maxb: That IS easy.. (easier than I expected) ;)
<maxb> You probably want to add a comment to the bug too
<pcjc2> of course.. with a link to the SHA1 which closed it
<pcjc2> copy the commit message too - whatever
<pcjc2> doesn't the robot / LP-lib client have to log on via OpenID ?
<maxb> No, OAuth
 * pcjc2 reads https://help.launchpad.net/API/SigningRequests
<pcjc2> we could get our developers to opt-in and allow the robot to impersonate them I guess? From the sounds of that
<maxb> well, you'd have to get them to opt-in to allowing your bot to impersonate them for any api action on Launchpad
<maxb> anyone with any sort of security instinct would refuse
<maxb> I would
<maxb> oh, one thing I missed from my pseudo-code is that you need to change status on a bug_task not a bug
<maxb> So you iterate the bug.bug_tasks collection to find the one that is for your project
<pcjc2> got it.
<pcjc2> Stupid question - how should I go about creating a LP user for my bot?
<maxb> Just sign up as a new user, using a dedicated email address for the bot
<pcjc2> (And presumably I can manually go through the steps of authenticating the bot to that user, then store the auth keys in the bot)
<maxb> indeed
<pcjc2> hmm - that is not so good... if I need a dedicated email for the bot
<pcjc2> I don't have one - and I can't think where to set one up which isn't amaturish
<pcjc2> mybot@gmail.com or whatever
<pcjc2> Any way to have a bot without an email address?
<maxb> LP users are always identified by their email address
<wgrant> An active Launchpad account requires an email address, unfortunately.
<pcjc2> Imported users from SF don't always have email addresses - is that a special case?
<wgrant> They're not active.
<pcjc2> I've asked our project admin to set up an email address (If possible) on the domain hosting out git repository
<maxb> pcjc2: Oh, by the way, if you want to track people closing bugs, you might choose to change the assignee of the bug task (if it's not already set) in your robot
<pcjc2> maxb: good idea
<pcjc2> A friend of mine set up an email alias with his domain provider, so... I now have:
<pcjc2> https://launchpad.net/~gpleda-launchpad-robot
<pcjc2> (Now just have to write the code to make it do my bidding ;))
<pcjc2> https://login.launchpad.net/+forgot_password
<pcjc2> Does that require any lp-dev interaction - there are a few of our users who want to do bug triage, but they have forgotten their LP passwords
<pcjc2> apparently they haven't received any email with confirmation code
<pcjc2> anyone about?
<lifeless> hi
<pcjc2> Apparently the email sent by https://launchpad.net/people/+requestmerge?field.dupe_person=djdelorie is not going through for that user
<lifeless> lp no longer stores passwords
<lifeless> thats really an alias to login.ubuntu.com
<pcjc2> I got the wrong end of the stick with the original complaint
<pcjc2> he wants to merge ~djdelorie and ~dj-delorie
<lifeless> ah ok
<pcjc2> (~dj-delorie is the registered on LP account, but he wishes to rename it to ~djdelorie (the one which will be merged), once the merge is done)
<lifeless> sure
<lifeless> so what happens when he merges
<pcjc2> DJ is a smart guy (developer of DJGPP and all that), so I trust him when he says the mail doesn't get through - he's been watching his server logs
<pcjc2> the email alias from the bug import I had is djdelorie@users.sf.net
<pcjc2> but it would appear the confirmation email is getting lost in the process
<lifeless> ok
<lifeless> so possibilities are:
<lifeless>  - our outbound mail is on the blink (low, very reliable service)
<lifeless>  - greylisting is in place at one or more of the mail providers chaining through users.sf.net
<lifeless>  - the mail chain is incorrect and mail to djdelorie@users.sf.net doesn't end up where you'd want it to
<lifeless> AIUI the usual thing is greylisting
<pcjc2> strange thing is my bug export has djdelorie@users.sf.net
<pcjc2> but he says when he tries to claim it, Launchpad says the email is going to djdelorie@users.sourceforge.net
<pcjc2> any chance we can cheat this one, or does that need a LOSA?
<lifeless> there is a link on the page to file support tickets
<lifeless> under 'note:'
<lifeless> also this is a email address search bug
<lifeless> sorry
<lifeless> spam protection bug
<lifeless> shouldn't be able to get the email address for an arbitrary user by requesting a merge
<lifeless> pcjc2: please let him know I clicked through myself to verify, so one of the confirmations he may receive is to merge with me... I advise against doing that :)
<pcjc2> he just got YOUR email lifeless ;)
<pcjc2> but he never got his own
<lifeless> interesting
<lifeless> uhm
<pcjc2> he's going to try again
<lifeless> does he have (in his active account) his email address hidden?
<pcjc2> yes
<lifeless> it can be set to show-always, show-loggedin-users, hide-completely
<lifeless> what From: and sender: did the one he got, have?
<pcjc2> he's now whitelisted the @sf.net email address
<pcjc2> Turns out it liked your email, but not his own
<lifeless> his spam filter?
<lifeless> what From: and sender: did the email from me have?
<pcjc2> yes, apparently
<lifeless> and what ones did the one from him have, if he's gotten one now
<pcjc2> hi gde (@lifeless, gde was the other person who is stuck with the merge)
<lifeless> pcjc2: I'm wondering if mail-confidentiality settings are preventing correct sending of the mail
<gde> lifeless: pcjc2 Hi there
<lifeless> pcjc2: so if you can get those questions answered, that would be great
<pcjc2> lifeless: He got it in the end, but I've asked him for the info
<lifeless> pcjc2: also say, hi, long time no see ;)
<pcjc2> (21:02:03) djgpp: To: djdelorie@users.sf.net
<pcjc2> (21:02:04) djgpp: From: Launchpad Account Merge <noreply@launchpad.net>
<pcjc2> (21:02:10) djgpp: Sender: bounces@canonical.com
<lifeless> pcjc2: thats after he whitelisted?
<lifeless> pcjc2: I'm guessing the one from me had my email address in the from: ?
<pcjc2> All emails came from the same From address
<lifeless> interesting
<pcjc2> and it turns out, were only received after he whitelisted the @sf address
<pcjc2> So the thing which was misleading was the address which LP claimed to be sending email to
<lifeless> how so?
<pcjc2> The lack of merge request was apparently just due to some spam filter / server setting
<lifeless> djgpp: hi, thanks for dropping in
<djgpp> hi
<djgpp> when I tried to recover a lost password on "djdelorie", it said it was sending a confirmation token to djdelorie@users.sourceforge.net
<djgpp> (I still haven't gotten those mails yet though)
<lifeless> thats very odd
<lifeless> when I tried it it said "An email message was sent to djdelorie@users.sf.net. Please follow the instructions on that message to complete the merge."
<pcjc2> ahh.. I guess that is the leak
<djgpp> the two merge requests came through to "To: djdelorie@users.sf.net"
<lifeless> we don't have a dba/sysadmin handing around in the weekends, and our staging copy won't have your data in it yet.
<lifeless> but I can arrange to look next week and see if there are two emails on the ~djdelorie account
<djgpp> and I can get my icon to change...
<djgpp> well, there aren't *now*
<pcjc2> so DJ - what you did was try to login with the old ~djdelorie account (the SF import one), and it leaked out / gave you the wrong address
<lifeless> oh, click - I see
<djgpp> I tried to log in to the *new* ~djdelorie (from the sf import), but yes.
<pcjc2> and presumably, it is a bug for that to leak _any_ email address
<lifeless> so, I think I know where the friction is
<djgpp> dj-delorie was my existing LP account (auto-generated from "DJ Delorie" I suppose)
<lifeless> password recovery is a separate system, separate db - its the openid database
<pcjc2> I'm still curious where it got the incorrect email from
<lifeless> account merge is purely launchpad
<lifeless> the isd folk may know
<pcjc2> should we (or someone) file a bug about the email address being given out for that account?
<djgpp> s/can/can't/ get my icon to change
<lifeless> (Information Services Development)
<lifeless> pcjc2: please file three bugs ...
<lifeless> 1) that the email addresses via the two routes were inconsistent
<lifeless> 2) that the password recovery handed out the email willy-nilly
<lifeless> 3) that the merge form handed out the email
<lifeless> there are some tensions between diagnosing faults and preventing disclosure to spammers
<lifeless> but we should at least take a look at it
<lifeless> gde: you were having trouble too ?
<pcjc2> ok. I bet it confuses them because DJ renamed his existing LP account dj-delorie to djdelorie (the merge one) after the merge ;)
<djgpp> and deleted the SF email from it, too :-)
<lifeless> that will be tricky to diagnose
<pcjc2> sounds like something we should recreate on staging
<lifeless> possibly
<lifeless> possibly not ;)
<pcjc2> (but the OpenID bit is production only, right)
<lifeless> its complicated ;)
<lifeless> I have to finish packing, flying to dallas this afternoon
<lifeless> you're all sorted, right ?
<djgpp> my account seems OK now, although I should log out and back in again...
<pcjc2> gde?
<djgpp> yup, I can log out/in
<djgpp> still doesn't have my icon...
<lifeless> branding?
<djgpp> "change details" mugshot
<lifeless> it hasn't saved it? or its not showing it on some page you're looking at ?
<djgpp> if I go there, it has my photo, but the homepage (/~djdelorie) still has the generic blue-shirt icon.
<djgpp> ah!  That's a branding logo.  GRRR!  That was NOT obvious.
<pcjc2> gde's import was this account https://launchpad.net/~gareth-uk
<pcjc2> I don't know what his actual LP account is
<pcjc2> API couldn't find the email address I have for him
<lifeless> if its hidden api cannot see it
<lifeless> djgpp: yeah, I would like us to auto-resize by default and allow overrides
<lifeless> djgpp: but noone has contributed a patch as yet :)
<pcjc2> lifeless: gde's issue was that he's forgotten his LP login credentials
<pcjc2> but we can't figure out what his proper LP account is called
<lifeless> ask a question on answers.launchpad.net/launchpad
<djgpp> I mean it *says* "that will be displayed on your home page in Launchpad" but it doesn't, and doesn't say that the icon that *is* displayed is set via branding, not details.
<lifeless> will need losa assistance
 * djgpp must get back to other projects...
<pcjc2> I've pointer gde at https://login.launchpad.net/+forgot_password
<pcjc2> So apparently the merge process is confusing for non-logged in, non-regular Launchpad users.
<pcjc2> If you click the "I am <user>?" link when logged out, you get forwarded to the login page, where the "forgot password" option is pretty tempting
<pcjc2> OOPS: (ErrorÂ ID: 1834carambolalaunchpad18)
<pcjc2> That is me playing about, Probably LP shouldn't "Oops!"
<gde> lifeless: that link doesn't work for me - no auth email arrives
<pcjc2> @gde: Check spam folder / whitelist?
<pcjc2> I tried it for my account and the email came from 	Launchpad Login Service <noreply@launchpad.net>
<pcjc2> But to avoid information leaks, it is possible that LP doesn't tell you if you enter an email address it doesn't know of an account for
<pcjc2> it may just silently pretend to have emailed you, and then get on with its business
<pcjc2> (to stop people probing for accounts)
<pcjc2> (lifeless can probably confirm / deny)
<lifeless> pcjc2: thats another bug to file
<pcjc2> (which?)
<pcjc2> the OOPS?
<gde> pcjc2: nothinhg in spam, and it's hosted gmail so there's no explicit whitelisting afaik
<lifeless> 10:29 < pcjc2> If you click the "I am <user>?" link when logged out, you get forwarded to the login page, where the "forgot password" option is pretty tempting
<lifeless> 10:29 < pcjc2> OOPS: (ErrorÂ ID: 1834carambolalaunchpad18)
<pcjc2> ah..
<lifeless> I can't debug now, still packing
<pcjc2> I've no idea what the OOPS was caused by, but I can try to reproduce
<lifeless> just file the bug
<lifeless> we get a backtrace in the oops
<pcjc2> Filing
<lifeless> and request variables etc; its usually enough to figure out the defect
<pcjc2> its not related to https://bugs.launchpad.net/launchpad/+bug/644824 is it?
<_mup_> Bug #644824: User created a second Launchpad account; now gets mixed success/denied to various services <canonical-losa-lp> <defect> <lp-foundations> <Canonical SSO provider:Confirmed> <Launchpad itself:Fix Released by stub> < https://launchpad.net/bugs/644824 >
<lifeless> related yes, dupe no
<pcjc2> Will point you at the bugs I file shortly
<lifeless> no need :)
<lifeless> I have ~ 0 time today
<lifeless> (sorry)
<pcjc2> NP, thanks for helping us!
 * pcjc2 goes back to bug filing and leaning LP API
<gde> lifeless: I think I'm good now- I needed to use an old email address
<gde> lifeless: thanks for the help
<pcjc2> any way to search for all bugs in a project with a remote bug watch?
<pcjc2> (Short of me re-importing our bug data on a local instance and running SQL?)
<pcjc2> The old bug watches auto-added based upon comments are no good because the SF trackers are shut down
<lifeless> so you want third party bug watches? not sf ?
<lifeless> may need a tweak to bugtask.py & the search interface
<lifeless> but we do have a field in the backend thats (IIRC) indexed)
<pcjc2> I just wanted to seek out bugs which had external watches (incorrectly) added, so I could delete the bugwatches
<pcjc2> I've already removed the couple I spotted by hand
<pcjc2> ââ«â, #70048
<_mup_> Bug #70048: Python-crash while using Deluge-Torrent-Client <deluge-torrent (Ubuntu):Invalid> < https://launchpad.net/bugs/70048 >
<pcjc2> Lifeless, 5x Bugs filed against LP, Bug#700483, Bug#700490, Bug#700491, Bug#700493, Bug#700496
<_mup_> Bug #700483: Email address leaked by account merge request <Launchpad itself:New> < https://launchpad.net/bugs/700483 >
<_mup_> Bug #700490: Incorrect email address presented when merging accounts <Launchpad itself:New> < https://launchpad.net/bugs/700490 >
<pcjc2> comeon mup, and the rest?
<pcjc2> Bug#700491, Bug#700493
<pcjc2> Bug#700496
<lifeless> pcjc2: you may wish to file a request for the search you couldn't do
<pcjc2> gah... don't want to make work for you guys
<pcjc2> more appropriate would be a way to disable auto-adding them for imported bugs (no point linking to the tracker you're just about to replace)
<pcjc2> but I have run out of energy for tonight
<pcjc2> https://bugs.launchpad.net/launchpad/+bug/700507
<_mup_> Bug #700507: Feature request: Search for bugs with an external bugwatch <Launchpad itself:New> < https://launchpad.net/bugs/700507 >
<lifeless> pcjc2: polish isn't work ;)
<lifeless> pcjc2: its just polish
#launchpad-dev 2011-01-09
<pcjc2> hello everyone
<wgrant> Is anyone around this week?
<jelmer> wgrant: hi!
<wgrant> Morning jelmer.
<wgrant> jelmer: In Dallas?
<jelmer> wgrant: yep, just arrived
<wgrant> I hear it has been snowing.
<wgrant> Which is odd, given the temperatures last week...
<jelmer> it's quite cold, not much warmer than the temperatures in .nl at the moment
<jelmer> it's not really snow but sleet (?)
#launchpad-dev 2012-01-02
<lifeless> micahg: what system has that limit?
<micahg> lifeless: 1and1
<StevenK> steven@mangled:~% find Maildir -type f | wc -l
<StevenK> 168334
<adeuring> good morning
<rvba> Hello adeuring.
<adeuring> hi rvba!
<wgrant> Morning adeuring, rvba.
<rvba> Hi wgrant!
* rvba changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: rvba | Firefighting: - | Critical bugtasks: 3*10^2
* rvba changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 3*10^2
<huwshimi> Morning all
<wgrant> Morning everyone.
<huwshimi> wgrant: Morning
<StevenK> Morning
<broder> i'm trying to follow the code path for archive uploads to figure out what changes would be needed for https://lists.ubuntu.com/archives/technical-board/2011-November/001137.html - i see the poppy daemon moving uploads into /var/tmp/poppy/incoming once the upload completes, but what actually processes the uploads after that?
<StevenK> process-upload
<StevenK> broder: You probably want NascentUpload under lib/lp/archiveuploader
<broder> StevenK: ok, i'll look there - thx
 * StevenK looks at the failed stable -> db-devel merge
<wgrant> StevenK: There shouldn't really be a conflict.
<wgrant> It's sinzui's test disablement.
<wgrant> Which is just a workaround for there being no webops.
<wgrant> I thought the fix was the same in both.
<wgrant> broder: I've seen people in Ubuntu mention the -backports permission differences over the years, but never seen any code to support the idea that there are any.
<broder> wgrant: ah, good. i was just starting to come to that conclusion, too :)
<StevenK> Isn't it the code that checks the pocket dependant on the series status?
<wgrant> That's unrelated.
<wgrant> That just affects when backports opens for a new series.
<wgrant> It should also be removed, but it's not a problem here yet.
<broder> wait, hmm? that sounds potentially related to my project
<wgrant> Ah, yes, so it is.
<wgrant> Not directly to this issue, though
<wgrant> Currently post-release pockets are only uploadable to when the series is frozen or release.
<wgrant> This seems pretty arbitrary.
<broder> Yeah, I'd want to turn that off for backports at least
<wgrant> See DistroSeries.canUploadToPocket
<wgrant> Seems like it should be turned off for everything, since they all require manual approval anyway.
<wgrant> And we do 0-day SRUs.
<wgrant> It just happens to work now because the series is usually frozen by the time the 0-day SRU is started.
<broder> So permissions on the backports pocket are enforced as they are for any other pocket, and they will always land in UNAPPROVED, but right now non-release uploads will be rejected until the series is frozen? That means that the last bit would be the only thing requiring change for pre-release backports
<wgrant> Yes
<wgrant> I believe so.
<broder> Sweet. I think I can pull that off
<broder> Oh, right. And I need to change the buildd configuration so that builds for backports run with the same component isolation as release/proposed/security
<wgrant> That's in lp.soyuz.adapters.archivedependencies
<wgrant> Should mostly be a matter of deleting 3 lines of code a few tests.
<wgrant> Let me see.
<broder> get_components_for_context
<wgrant> def get_components_for_context(component, pocket):
<wgrant>     if pocket == PackagePublishingPocket.BACKPORTS:
<wgrant>         return component_dependencies['multiverse']
<wgrant>     return component_dependencies[component.name]
<wgrant> Well, that looks easy...
<jelmer> hey launchpadders
<wgrant> Evening jelmer.
#launchpad-dev 2012-01-03
<poolie> hi all
<rick_h__> hey poolie
<cjwatson> wgrant: Yeah, we might want that (post-release restriction) turned off for -proposed anyway at some point because we were thinking of using that for a britney-style workflow
<cjwatson> It'd be pretty harmless to kill it across the board
<wgrant> cjwatson: Yeah, that's what I've been thinking for a while.
<wgrant> It's a pretty pointless restriction.
<cjwatson> Oh, hey, people are around again.  I can has landing attempt of https://code.launchpad.net/~cjwatson/launchpad/new-python-apt/+merge/85649 ?
<wgrant> Bah, sorry, forgot about that.
<wgrant> ec2ing now
<wgrant> Huh
<wgrant> No conflicts.
<wgrant> How did you manage that, after I changed 1200 files on Sunday...
<cjwatson> I merged a couple of times
<cjwatson> Oh, not since that though?
<cjwatson> Dunno then, just lucky I guess
<wgrant> Yeah
<broder> cjwatson: yeah, the patch i have drafted drops the post-release check for all pockets, though i guess i'm not sure whether the restriction is desirable for security
<broder> err, rather, it allows uploads to all pockets pre-release
<cjwatson> I suspect they don't care for similar reasons
<cjwatson> Might be polite to ask, I suppose
<wgrant> Direct security uploads are rejected anyhow.
<wgrant> They use copies.
<wgrant> Which bypass this.
<wgrant> (and a 0-day security upload is not unprecedented)
<broder> Ah, right. I was just thinking that I thought that was the case
<wgrant> I'm pretty sure just dropping that check is the way to go.
<broder> I'm getting rocketfuel setup so I can figure out which tests I'm breaking, then I'll throw up a MP
<wgrant> The whole test suite takes 4-6 hours -- you probably only want to run the soyuz and archiveuploader tests.
<StevenK> wgrant: O hai, Mr OCR -- https://code.launchpad.net/~stevenk/launchpad/bugalsoaffects-packaging-no-series/+merge/87309
<wgrant> Oh right, it's Tuesday.
<StevenK> Bwaha
* wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: wgrant | Firefighting: - | Critical bugtasks: 3*10^2
<wgrant> Hm, 329 criticals
<wgrant> Awesome.
<poolie> winning
<StevenK> FSVO
<wgrant> FSVO
<wgrant> Heh
<cjwatson> wgrant: For values of "not unprecedented" including "ever since the very first Ubuntu release"
<wgrant> cjwatson: Before my time, sadly.
<cjwatson> Actually release candidate, I think.  IIRC https://lists.ubuntu.com/archives/warty-changes/2004-October/001585.html was something like an hour before RC - I remember there being some apache2-related drama, anyway, where the coordinated release date was right on the edge of our planned release schedule
<wgrant> Heh, useful.
<micahg> wgrant: I can almost promise a 0-day security upload for precise :)
 * cjwatson longs for the days when we could turn around an upload plus an entire Ubuntu CD set plus testing in an hour
<wgrant> Heh
<micahg> Firefox 12 releases 2 days before precise :)
<cjwatson> wgrant: Could you have a look at https://code.launchpad.net/~cjwatson/launchpad/germinate-all-dev-series/+merge/86909 when you get a chance?
<wgrant> cjwatson: getComponents seems to no longer exclude partner.
<wgrant> cjwatson: The list comprehension has no condition, so is entirely superfluous.
<cjwatson> Err, oops
<cjwatson> Moved that code around too many times
<wgrant> Heh
<cjwatson> Fixed, thanks
<wgrant> cjwatson: Also, find_operable_series would be 2/5 the size as a list comprehension.
<wgrant> Apart from that it looks good.
<cjwatson> The line breaks get unwieldy to satisfy code style
<wgrant>    return [
<wgrant>        series for series in distribution.series
<wgrant>        if series.status in (SeriesStatus.DEVELOPMENT, SeriesStatus.FROZEN)]
<cjwatson> Hm, maybe not
<wgrant> Isn't that bad...
<wgrant> The last line just fits.
<cjwatson> Yeah, I just got there :)
<wgrant> Hah ha hahha
<wgrant> /tmp/slonikjHv2Ae.sk:27: PGRES_FATAL_ERROR
<wgrant> ALTER TABLE EmailAddress ADD CONSTRAINT valid_account_for_person CHECK (check_email_address_person_account(person, account)); - ERROR:  check constraint "valid_account_for_person" is violated by some row
<cjwatson> Pushed that fix now.
<wgrant> Seems to have taken two minutes as well :/
<StevenK> lifeless: Can you scribble your thoughts on bug 872496?
<_mup_> Bug #872496: All package stats now report zero "Incomplete" bug reports <api> <regression> <Launchpad itself:Triaged> <Ubuntu QA Website:Fix Released by brian-murray> < https://launchpad.net/bugs/872496 >
<cjwatson> wgrant: Doesn't bug 905322 need an ftpmaster rollout?
<_mup_> Bug #905322: Lower required dpkg version for xz-compressed packages <qa-ok> <Launchpad itself:Fix Released by cjwatson> < https://launchpad.net/bugs/905322 >
<StevenK> It ought
<StevenK> Oh, if it's binary, cesium is fine
<wgrant> cjwatson: As StevenK says, it's a binary check, and binary uploads happen on cesium.
<wgrant> In fact, I think I corrected StevenK about this very bug 2 or so weeks ago :)
<cjwatson> I thought cesium was currently cowboyed and out of NDT
<StevenK> We fixed that
<cjwatson> That's what LPS suggests
<StevenK> This morning, in fact
<wgrant> spm mustn't have updated LPS yet.
<spm> I keep getting pinged to do other stuff
<spm> it's about 3rd on my interrupted stack
 * StevenK fixes that too
<spm> :whine:
 * StevenK tries to figure out where canonical_url() went.
<wgrant> StevenK: lp.services.webapp.canonicalurl, should be
<wgrant> Yeah
<StevenK> Yeah, I ran bzr grep after saying :-)
<StevenK> wgrant: bug 897999 == the validator is complete rubbish?
<_mup_> Bug #897999: validate_enabled_restricted_families applies to all non-virtualized archives, not just main archives <regression> <soyuz-core> <Launchpad itself:Triaged> < https://launchpad.net/bugs/897999 >
<wgrant> StevenK: It's always been broken, and is now more broken than ever :)
<StevenK> wgrant: I'm a little unclear how to fix it, without just ripping it all out
<wgrant> StevenK: It should only apply where archive.is_main, rather than not archive.virtualized
<nigelb> Morning!
<StevenK> nigelb: O HAI
<StevenK> wgrant: http://pastebin.ubuntu.com/791232/ plus test fallout?
<wgrant> StevenK: Check the code.
<wgrant> I'm not sure if there is a virt check
<wgrant> Oh, that is the code.
<wgrant> That's not what you want to change.
<wgrant> You need to change validate_enabled_restricted_families to match the check you just changed.
<wgrant> The check that you changed was already correct.
<StevenK> Right, so the validator doesn't match the behaviour in IArchive.
<StevenK> wgrant: So http://pastebin.ubuntu.com/791249/ and related fallout?
<wgrant> StevenK: That would partly fix it for now sort of.
<wgrant> StevenK: But the real issue is that archivearch is entirely ignored for those archives -- there's no point showing the widget at all.
<wgrant> Or if you do, it should have everything checked and should be disabled.
<StevenK> wgrant: Do you like http://pastebin.ubuntu.com/791251/ better?
<wgrant> StevenK: No. Needs the non-virtual check too.
<wgrant> Remember that         if self.is_main and not self.require_virtualized:
<wgrant>             return getUtility(IProcessorFamilySet).getRestricted()
<StevenK> But it needs to backward, right?
<StevenK> if not self.context.is_main and self.context.require_virtualized:
<wgrant> No.
<wgrant> The check is the same.
<wgrant> (self.is_main and not self.require_virtualized) == ignore_archivearch
<StevenK> But you said you wanted to hide it for those archives ...
<wgrant> Er, true.
<wgrant> But you didn't invert it properly.
<wgrant> not self.context.is_main or self.context.require_virtualized
<wgrant> That's more like it.
<StevenK> Right.
<StevenK> Hmmm.
<StevenK> I think ArchiveAdminView might need a axe for this.
 * wgrant deletes EmailAddress.account to see what breaks.
<wgrant> I think that's probably better than lots of triggers to ensure its consistency...
<StevenK> WCPGW
<wgrant> It's been superfluous since ShipIt's demise.
<wgrant> And it's not exported to SSO.
<StevenK> Can you delete shipit.css while you're at it? :-P
<StevenK> I can't even see how to get to ArchiveAdminView for the main archive
<wgrant> /ubuntu/+archive/primary/+admin
<wgrant> But it should also be on /ubuntu/+admin as well, IIRC.
<StevenK> /ubuntu/+admin no worky
<wgrant> Maybe +edit, then.
<wgrant> Some page like that uses that mixin.
<StevenK> wgrant: However, your first link works, and it doesn't show the restricted families widget
<wgrant> DistributionAddView and DistributionEditView
<StevenK> /ubuntu/+edit still shows restricted families
<wgrant> https://dogfood.launchpad.net/ubuntu/+archive/primary/+admin does too...
<wgrant> Down the bottom.
<StevenK> I'm testing locally with my change
<wgrant> Ah
<StevenK> I can cowboy my change onto DF :-P
<wgrant> I am murdering DF at the moment, but it might be doable.
<StevenK> You bad person.
<wgrant> Just attempting to delete the 3 million orphaned accounts.
<StevenK> Won't that cause SSO to go all explode-y?
<wgrant> No.
<wgrant> SSO doesn't care if there's no matching lp_account
<wgrant> It only uses lp_account to find the lp_person.
<StevenK> wgrant: http://pastebin.ubuntu.com/791274/
<wgrant> StevenK: Now try toggling the Virtualized checkbox while the form is open, and cry :)
<StevenK> I should hide that too?
<wgrant> No, it needs to be changble.
<StevenK> wgrant: Since I'm hiding enable_restricted_families, looks okay to me?
<StevenK> I can't actually *submit* the form, but it looks good. :-)
<StevenK> Bleh. I'm no duck on DF
 * StevenK fixes
<StevenK> wgrant: http://pastebin.ubuntu.com/791283/ looks to work
<wgrant> StevenK: But what happens if I want to make an archive virtualized?
<wgrant> How do I select its archs?
<wgrant> Also, lp.registry.model.mailinglist's subscription methods win the award for Most Gratuitous Uses of Outer Joins.
<StevenK> wgrant: Bah
<StevenK> There has to be a way to fix this crap
<wgrant> Ah hm
<wgrant> I think I see how our EmailAddress account vs. person corruption is happening.
<StevenK> Oh?
<wgrant> I'm not sure we handle well the case where someone creates an SSO account with an email address held by an unactivated LP person.
<wgrant> It looks like it will just set emailaddress.account
<wgrant> And create a new person...
<wgrant> But let's see.
<wgrant> Ah
<wgrant> But no, Account.createPerson() steals all the email address for itself.
<wgrant> Although if I then remove that address from my SSO account, and make it the primary address for another...
<wgrant> Huh
<wgrant> So some of our unactivated persons have accounts, and some of them don't.
<wgrant> Depending on just which bit of code created them....
<wgrant> Yay!
 * StevenK tries to work out bug 907840
<_mup_> Bug #907840: Permissions on +nominate are messed up <bugs> <disclosure> <packages> <regression> <series> <Launchpad itself:Triaged> < https://launchpad.net/bugs/907840 >
<lifeless> StevenK: hi
<lifeless> StevenK: done
<StevenK> lifeless: Stating the obvious. :-)
<StevenK> lifeless: What I meant, was do you think Brain's comment that Incomplete should be the sum of the two?
<lifeless> yes, that was the original behaviour, and it wasn't meant to be changed
<lifeless> searching Incomplete should return both sorts of incomplete
<StevenK> Okay, so it should be fixed.
<lifeless> totally
 * wgrant s/2004-2011/2004-2012/
<StevenK> Yes, we should do that.
<StevenK> We even have a script!
<wgrant> Oh, do we?
<wgrant> update-copyright is for updating file copyright notices as you go.
<wgrant> I don't believe it updates the global notices in templates and such.
<StevenK> Oh. I keep doing that by hand.
<StevenK> In fact, I should have done that for the branch I landed today ...
<StevenK> When did 2012 happen, anyway?
<adeuring> good morning
<bigjools> Happy new year all
<lifeless> I wonder if it is possible to have multiple tabs share a long poll connection - e.g does the browser security model permit htis
<lifeless> (when they are on the same domain)
<bigjools> it's possible but given that chrome does separate processes it'd be fun to see how
<lifeless> I assume that that would be abstracted out
<mrevell> Morning
<wgrant> bigjools, lifeless: You can use the HTML5 postMessage API to communicate between tabs, but I don't know if IE supports it.
<wgrant> Firefox/Chromium have for a couple of years, though.
<wgrant> AIUI there's no other way to communicate, unless you poll cookies.
<wgrant> Or poll HTML5 local storage.
<lifeless> so it should be possible to setup one tab as 'master', route new listens and events through it, and use the same idle timeout to detect that tab being closed from other tabs
<adeuring> wgrant: are you still doing reviews?
* wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 3*10^2
<wgrant> No :)
<lifeless> gmb: hi
<adeuring> wgrant: yeah, i assumed that ;) Have a nice evening!
<gmb> lifeless: Howdy
<cjwatson> wgrant: You said on IRC that https://code.launchpad.net/~cjwatson/launchpad/germinate-all-dev-series/+merge/86909 was OK with the fixes you suggested, but I just noticed you don't seem to have left any review feedback on the MP itself?
<cjwatson> rvba: I made the change you suggested to https://code.launchpad.net/~cjwatson/launchpad/stop-publishing-obsolete-series/+merge/86967 .  Do you think you could land it for me, as I don't have PQM access?
<rvba> cjwatson: sure thing.  Thanks for the change ;)
<wgrant> cjwatson: Huh, must have become distracted. Shall I throw it at ec2?
<cjwatson> wgrant: Please
 * cjwatson climbs slowly up the Contributions ladder :-)
<rvba> cjwatson: You're branch stop-publishing-obsolete-series is in ec2.
<cjwatson> rvba: thanks!
<rvba> s/You're/Your/
<rvba> np
<adeuring> gmb: do you have time for a review? https://code.launchpad.net/~adeuring/launchpad/bug-909318/+merge/87322
<gmb> adeuring: Ha, I'd forgotten I was OCR today. Certainly.
<adeuring> gmb: thanks!
<StevenK> gmb: I blame New Years. wgrant had forgotten too.
<gmb> StevenK: New year + the bank holiday means I'm completely screwed this week. I'll be surprised if I actually make it to Budapest.
<bigjools> I am going to savour my last short flight to a sprint
<wgrant> nyahaha
<bigjools> treating the family to premium economy when we leave
<gmb> adeuring: One minor comment, otherwise r=me
<adeuring> gmb: thanks!
* gmb changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: gmb | Firefighting: - | Critical bugtasks: 3*10^2
<cjwatson> gmb: mvo just merged https://code.launchpad.net/~mvo/launchpad/maintenance-check-precise/+merge/82125 up to current devel; do you think you could try landing it, if the QA procedure I outlined is good enough?
 * gmb looks
<gmb> Ooh, timeout on the merge proposal page. That's new.
<gmb> cjwatson: Looks plenty sane to me. I'll get it landed today for you.
<cjwatson> Yay
<gmb> cjwatson: Is there a bug to go with this branch (for the sake of having somewhere to track its QA).
<cjwatson> gmb: I'll ask mvo
<gmb> Ta
<cjwatson> gmb: 11:03 <mvo> bug #911175 - its mostly just copy/paste from the MP text
<_mup_> Bug #911175: Please update maintenance-timeframe.py for ubuntu 12.04 (precise) <Launchpad itself:New> < https://launchpad.net/bugs/911175 >
<gmb> cjwatson: That's perfect, thanks.
<rick_h__> morning everyone
<bigjools> morning
<lifeless> gmb: ah yes - are you actually looking at  https://bugs.launchpad.net/launchpad/+bug/380362 ?
<_mup_> Bug #380362: Launchpad couldn't import several bugs from Debian Bug tracker. <lp-bugs> <Launchpad itself:Triaged by gmb> < https://launchpad.net/bugs/380362 >
<gmb> lifeless: No, I'm not. I'll unassign myself.
<lifeless> ta
<bigjools> lifeless: I debugged the gpgme poppy problem a bit more
<lifeless> \o/
<bigjools> lifeless: I am none the wiser though!
<lifeless>  /o\
<bigjools> basically the error is "general error" and the source of the error is GPG_ERR_SOURCE_GPGME
<bigjools> which is basically fucking useless
<lifeless> WWWWIN
<bigjools> the gpgme code is saying that it has an error but it has no idea what the error is
<bigjools> lifeless: so if you have any bright ideas ...
 * bigjools would like to educate the person who defined GPG_ERR_GENERAL
<lifeless> http://www.gnupg.org/documentation/manuals/gcrypt/Error-Sources.html isn't terribly helpful here
<lifeless> I guess we need to look in the gpgme source code
<bigjools> I guess so
<lifeless> bigjools: I think its a matter of grepping at this point, seeing if anything obvious jumps out, and if not, tweak things in the library to give us more info
<lifeless> it may be something like 'using contexts across threads is a bad idea'
<lifeless> [which with threadpools and deferToThread may be happening]
<bigjools> hmmm there are lots of warnings about thread safe-ness
<bigjools> in fact I am willing to lay a bet this is a threading problem
 * gmb lunches
<StevenK> rvba: Are you right to QA bug 903827 today?
<_mup_> Bug #903827: https://launchpad.net/builders timeout <qa-needstesting> <timeout> <Launchpad itself:Fix Committed by rvb> < https://launchpad.net/bugs/903827 >
<bigjools> lifeless: the gpgme source has *goto* in it .....
<bigjools> this doesn't surprise me a lot
<lifeless> :)
<bigjools> lifeless: I wonder if we should get libgpgme upgraded... the one in oneiric is 1.2 but latest is 1.4 (or even 2.0)
<bigjools> it gets better, someone has mixed tabs and spaces in the source
<lifeless> :)
<lifeless> its C
<lifeless> but yeah, icky
<bigjools> well I used to write C/C++ and never used tabs
<lifeless> an upgrade is possibly a good idea
<bigjools> unless you want your code looking like a dog's dinner
<lifeless> gpg2 is a separate package; perhaps libgpgme for 2 has been done like that too
<lifeless> astyle ftw
<bigjools> oh god, indented braces
<bigjools> when will the horror end
<lifeless> after you mental floss
<cjwatson> goto> there are styles of C in which that's fine as an error-handling mechanism; the Linux kernel uses it well
<bigjools> it's bloody evil
<bigjools> trying to follow code with gotos in it is a nightmare
<cjwatson> with discipline, it can be a good way to avoid duplicating function-exit code all over the place, given the lack of anything like finally
<cjwatson> I have no idea whether the code you're looking at is disciplined
<bigjools> I mostly used "break" instead of goto
<cjwatson> That has its own problems
<bigjools> but far fewer than goto :)
<cjwatson> I don't agree with that as a dogmatic statement ...
<bigjools> well from experience, goto has caused me untold problems, break has never caused me one
<bigjools> *shrug*
<cjwatson> Our experiences differ :-)
<bigjools> but then I mostly wrote C++
<cjwatson> In C++ you generally have better destruction mechanisms available so it's less of an issue
<bigjools> right
<bigjools> 130 line functions don't help
<lifeless> hah, just a baby function :)
<lifeless> bigjools: https://bugs.launchpad.net/launchpad/+bug/408528 - should this be closed? the history looks like it was fixed for soyuz and status lost during the big combine
<_mup_> Bug #408528: Packages build but fail to upload due to email address issue <lp-foundations> <lp-soyuz> <motu> <Launchpad itself:Triaged> < https://launchpad.net/bugs/408528 >
<wgrant> Heh. I deleted the code that fixed that just tonight.
<wgrant> It's not quite fully fixed.
<wgrant> But will be once we clear the personless accounts from the DB.
<lifeless> how do we represent 'unclaimed persons' ?
<wgrant> Two ways.
<wgrant> Person.account IS NULL
<wgrant> Or Person.account.status == NOACCOUNT
<wgrant> (yes, Account.status can have the value NOACCOUNT)
<wgrant> Most are the latter.
<lifeless> ok, and after you change, there will be just the latter
<wgrant> I think only bugimports do the former.
<wgrant> Not my first change.
<wgrant> But the one after that, yes.
<lifeless> kk
<wgrant> I'm just killing EmailAddress.account for now.
<wgrant> To deal with the consistency issue.
<wgrant> And delete like 1500 lines of code.
<wgrant> But this lets us very easily flatten account into person.
<lifeless> be sure to update the sso triggers if you tackle that ;P
<wgrant> Fortunately this bit doesn't touch the mirrored tables.
<wgrant> I was pleasantly surprised to find no lp_emailaddress.
<lifeless> gmb: is https://bugs.launchpad.net/trac-launchpad-migrator/+bug/411394 really triaged, or should it be fix committed / fix released ?
<_mup_> Bug #411394: Bug nickname is always "elisa-$bugno" <trac-launchpad-migrator:Triaged> < https://launchpad.net/bugs/411394 >
<gmb> lifeless: At least Fix committed, I'd think. I'll look into it.
<lifeless> gmb: thanks
<benji> gary_poster: link?
<lifeless> bigjools: q for you on https://bugs.launchpad.net/launchpad/+bug/443071
<_mup_> Bug #443071: can't publish a specific architecture after source is already published <lp-soyuz> <oem-services> <soyuz-security> <Launchpad itself:Triaged> < https://launchpad.net/bugs/443071 >
<bigjools> lifeless: no
<bigjools> it's the same copier
<lifeless> k
<lifeless> bigjools: here is the bug on buildd-manager restarts w/db - https://bugs.launchpad.net/launchpad/+bug/451349 :)
<_mup_> Bug #451349: buildd-manager doesn't deal gracefully with database restart <boobytrap> <canonical-losa-lp> <lp-soyuz> <soyuz-build> <Launchpad itself:Triaged> < https://launchpad.net/bugs/451349 >
<bigjools> lifeless: my elder wand is wearing out
<lifeless> :) - just that you were saying it should work ok a while back
<lifeless> so I thought you might like to close the bug :>
<bigjools> I can't remember what I said this morning, let alone a while back!
<bigjools> lifeless: is it fixed? I dunno
<lifeless> me neither
<deryck> abentley, ping for standup
<deryck> rick_h__, abentley, adeuring -- https://dev.launchpad.net/MaintenanceRotationSchedule
<lifeless> sinzui: I think you mis-read https://bugs.launchpad.net/launchpad/+bug/911189
<_mup_> Bug #911189: Bug page tag links are not properly escaped, thus made useless <bug-importer> <bugtag> <Launchpad itself:Triaged> < https://launchpad.net/bugs/911189 >
<lifeless> sinzui: its a tales / ajax escaping issue
<sinzui> oh, those that cam from the import are now crippled
<lifeless> sinzui: the importer is incidental (and confusing to mention)
<lifeless> yes
<lifeless> bigjools: whats your take on https://bugs.launchpad.net/launchpad/+bug/402935?
<_mup_> Bug #402935: Domination of architecture independent binaries is not restricted to the source publication boundaries <boobytrap> <lp-soyuz> <ppa> <Launchpad itself:Triaged> < https://launchpad.net/bugs/402935 >
<bigjools> looking
<rick_h__> abentley: ~rharding/launchpad/port_inlinehelp_907443
<bigjools> lifeless: struggling with the Portuglish, but got there in the end. Not sure if it's still a bug tbh, it needs verification
<bigjools> there were some substantial changes in domination last year
<deryck> mrevell, ping
<benji> deryck: when you have a second I have a maintenance squad task I'd like to cajole you guys into doing
<mrevell> hey deryck, I'm just about to hop on a call. Should I ping you after that?
<deryck> mrevell, yes, please.
<deryck> benji, cajole away.  Do we need to voice chat about it?
<benji> deryck: voice might make the cajoling more potent
<benji> deryck: do you do the google hangout thing?
<deryck> benji, I do.
<benji> deryck: your hangout or mine?
<deryck> benji, yours.  let me warm my coffeeâ¦. 30 seconds.
<rvba> gmb: could you please have a look at this mp? https://code.launchpad.net/~rvb/launchpad/longpoll-stats-903586/+merge/87372
<gmb> rvba: Certainly.
<rvba> Thanks.
<rick_h__> gmb: have time for a review please? https://code.launchpad.net/~rharding/launchpad/port_inlinehelp_907443/+merge/87384
<gmb> rick_h__: Not for one that size, I expect, but I'll try to get to it before I EoD. If not, I'll ping you.
<rick_h__> gmb: sounds like a plan. Thanks
<gmb> np
<gmb> rick_h__: I didn't get time to get to your branch; apologies.
<rick_h__> gmb: no prob, thanks for the heads up
 * gmb -> evening things
<rick_h__> deryck: or abentley interested in taking a few to review? https://code.launchpad.net/~rharding/launchpad/port_inlinehelp_907443/+merge/87384
<deryck> rick_h__, I can take it.  though I'm about to go offline to travel home.  so it may be tonight before I finish.
<rick_h__> deryck: ok thanks. No rush.
<deryck> rick_h__, ok, cool.  will work on it and reply whenever I'm done.
<lifeless> gary_poster: will everyone be around in 104 minutes from now?
<gary_poster> lifeless, no, the Europeans are gone by now
<gary_poster> and hi
<lifeless> ah
<lifeless> so I have a call at my 10pm tonight
<lifeless> which makes a 7am call unappealing
<gary_poster> lifeless, understood.  (you won't be at team lead call?)  is 8am any better lifeless?
<gary_poster> or sufficiently better, I should say :-)
<lifeless> hmm, I didn't think the team lead call was at 6am
<lifeless> my calendar thinks it is at 8am
<gary_poster> maybe I miscalculated
<gary_poster> I probably did then
<lifeless> my 0800 is 1700Z
<gary_poster> I tend to miss the 12-is-not-10 in my timezone math sometime
<lifeless> erm no
<lifeless> 0800 is 1900Z
<lifeless> yes, thats right
<gary_poster> maybe you do too :-)
<gary_poster> ah right
<gary_poster> ok
<gary_poster> that's the calculation I had done earlier
<lifeless> anyhow, I have a call with mat right after the tl meeting, but I think we're more in sync so I'm sure he will be happy to take a raincheck
<gary_poster> ok lifeless, if I were able to get everyone tomorrow at 2000Z that would work for you?
<gary_poster> oh
<gary_poster> ok
<lifeless> I've sent a calendar invite for then
<gary_poster> cool thanks lifeless.  That's 8 UK/9 Italy so it's not a given, but Francesco already said it is ok.  Thanks!
<lifeless> I think I trust you to relay whatever we chat if gmb can't make it
<lifeless> I'd rather a partial call sooner than a complete call deeper into the project
<gary_poster> lifeless, sounds good
<lifeless> separately, I wanted to talk about the milestones tags thing per the thread in december
<lifeless> who should we rope in for that ? you, me, curtis? more? less?
<lifeless> gary_poster: ^
<gary_poster> oh sorry lifeless.  the full set would be you, me, brad, francesco, and curtis.  I think the only must-haves are you and brad, depending on the outcome.
<lifeless> francesco is in italy yes?
<gary_poster> lifeless, yes.  getting the rest of us for now would be reasonable
<lifeless> my google calendar should be fairly accurate as to availability; would you care to pick a convenient time (You'll know non-calendar preferences better than I) and send it? I have nothing late on thursday, so I can probably do the same time as the tl meeting (or after) on the following dat
<lifeless> *day*
<gary_poster> lifeless, can do.  even better might be today.  I'll look for your schedule now, but if you don't object I'll try that first
<lifeless> gary_poster: oh *frell* and I just remembered, I have a hospital appointment at 1030 on thursday leaving my only 30 minutes post parallel test call to get there
<lifeless> today would be awesome
<lifeless> as I suspect I'm about to have to shuffle the parallel test call :P
<gary_poster> lifeless, heh, ok.  I'll try to arrange the tag call in the next hour or two.  How would parallel testing be for your Friday then?
<gary_poster> Same time
<gary_poster> eh I could look at your calendar... me gets back to that
<lifeless> superb
<gary_poster> lifeless, you can do your Friday, so I'll move parallel testing to then.  I have a call in 1:15 and you have something in :15, right (I ask simply because I don't understand what 1:1 bootstrapping means)?
<gary_poster> Actually I suspect it would be easier for you to move the parallel testing meeting
<gary_poster> otherwise I have to make a new one
<lifeless> I will move it
<lifeless> 1:1 bootstrapping is me getting to grips with the rest of CDO as TA
<gary_poster> ah right
<gary_poster> ok cool
<gary_poster> thanks
<lifeless> one dept at a time
<gary_poster> bac, sinzui, are you available in 13 minutes to have a call with lifeless about milestone tagging?
<bac> gary_poster: yes
<sinzui> yes
<lifeless> gary_poster: sorry was iunclear - that 15 minutes thing is a call with henrik omma
<gary_poster> lifeless, oh!
<gary_poster> sorry, I misunderstood the moving it part
<gary_poster> bac, sinzui, nm, sorry.  I'll propose a call tomorrow afternoon
<gary_poster> sinzui, bac, lifeless, I proposed a call in two hours and two minutes (5PM eastern).  It's in Google calendar.  I can't talk longer than half an hour, so hopefully we can determine what to do by then.
<lifeless> kk
<bac> ok
<sinzui> gary_poster, purple squad have a meeting at 5
<sinzui> I can talk before then
<gary_poster> sinzui, I have a 4 PM :-/
<gary_poster> ...
<gary_poster> oh, is flacoste not here today?
<fjlacoste> gary_poster: i'm here
<fjlacoste> under the wrong nick!
<gary_poster> heh
<gary_poster> flacoste, would you be available for a call at 3:30 rather than 4?
<flacoste> gary_poster: sure
<gary_poster> awesome thanks flacoste
<gary_poster> ok sinzui, bac, lifeless (who is now on the phone), I'm moving the call a half hour earier (4:30 Eastern)
<sinzui> okay, 1h 25m from now
<bac> still good with me
<gary_poster> thanks
<rick_h__> gary_poster: +1 on the pyramid stuff :) big fan (re email to -dev)
<gary_poster> rick_h__, cool :-)
<rick_h__> gary_poster: let me know if you get playing with things. been working on it with my personal app and was working on porting pylons -> pyramid at my last job
<gary_poster> lifeless, when you move the parallel testing appt please add flacoste as participant
<lifeless> kk
<lifeless> gary_poster: it was a simple +24h right ?
<lifeless> ok, popping out for a minute, will be back for the call in 20
<lifeless> and back
<wgrant> Morning
<lifeless> flacoste: should we catch up ?
<flacoste> lifeless: how about tomorrow?
<lifeless> flacoste: hahahahahah :P
<flacoste> lifeless: i've been catching up on the phone all day :-)
<lifeless> yeah, me too
<lifeless> see if there is a slot in my calendar that suits
<sinzui> jcsackett, meeting?
<jcsackett> sinzui: mumble is misbehaving. i'll have it sorted in a sec.
<gary_poster> That since this was tech debt, we will *not* proceed even now.  (My understanding was that we were going into it with our eyes open)
<gary_poster> oops :-)
<jelmer> 'evening
<lifeless> mwhudson: oh hi
<mwhudson> lifeless: hello
<lifeless> mwhudson: you have https://bugs.launchpad.net/~mwhudson/+assignedbugs
<lifeless> also 'affecting bugs' reads oddly
<mwhudson> lifeless: ah yes, i saw your comments on the loggerhead bugs i think
<mwhudson> i'll reply in due course
<lifeless> thank you !
<lifeless> I think the search will catch things I haven't yet scanned across
<lifeless> flacoste: this is a ref for google interpreting javascript - http://searchengineland.com/google-io-new-advances-in-the-searchability-of-javascript-and-flash-but-is-it-enough-19881
<lifeless> 'As of today, theyâre able execute JavaScript onClick events.' ..
#launchpad-dev 2012-01-04
<lifeless> I wonder
<lifeless> are implicitly created accounts subject to the name blacklist ?
<cjwatson> How long does qastaging take to update after a buildbot run finishes?
<wgrant> 40ish minutes
<wgrant> Let's see how it's going.
<wgrant> Bah
<wgrant> buildbot poller missed it.
<wgrant> So it won't start for another 5 minutes.
<wgrant> And it will take 30 minutes to update.
<cjwatson> OK, I can probably get some QA done tonight then
<wgrant> What do you have that's QAable on qastaging?
<cjwatson> It's pretty much all dogfood, but it's easier to wait for qastaging so that the deployment report is up to date ...
<wgrant> Heh
<wgrant> That's what I thought.
<lifeless> gmb: https://bugs.launchpad.net/launchpad/+bug/484712
<_mup_> Bug #484712: Potential synchronisation of comments between Launchpad bugs via remote bug trackers <bugwatch> <lp-bugs> <Launchpad itself:Triaged by gmb> < https://launchpad.net/bugs/484712 >
<lifeless> gmb: would like feedback/status update (if only to unassign yourself and say that it hasn't been tested...)
<cjwatson> wgrant: Speaking of which; can I commandeer mawson in a bit, after I'm done with a couple of chores?  You seem to be the only other person logged in.
<wgrant> cjwatson: Sure, I'm just abusing its database.
<wgrant> Nothing that should affect you.
<cjwatson> That won't get clobbered by a code update?
<wgrant> No.
<cjwatson> Oh, of course, NDT means obviously not
<wgrant> Query count test failures are a little painful now...
<wgrant> They include full tracebacks :)
<lifeless> heh, bad linkificaition on https://bugs.launchpad.net/launchpad/+bug/499438
<_mup_> Bug #499438: Better handling of fatal upload errors <lp-soyuz> <soyuz-upload> <Launchpad itself:Triaged by julian-edwards> < https://launchpad.net/bugs/499438 >
<lifeless> cjwatson: what do you think the reaction would be to disabling anonymous ftp uploads ?
<cjwatson> Hard to say
<cjwatson> from a quick look at cocoplum:~lp_queue/ubuntu-queue/, it looks as though the bulk of our uploads are FTP right now
<lifeless> yes, I would expect that
<cjwatson> lp_archive@cocoplum:~$ grep --count upload-ftp /srv/launchpad.net/production-logs/lp_queue/process-upload.log
<cjwatson> 68268
<cjwatson> ^- unscientific check
<cjwatson> lp_archive@cocoplum:~$ grep --count upload-sftp /srv/launchpad.net/production-logs/lp_queue/process-upload.log
<lifeless> the reason to suggest this is that a lot of the UI poorness around uploads is coupled to depending on good package metadata (including signatures) for error notifications
<cjwatson> 4789
<cjwatson> perhaps we should find out why most people aren't using sftp uploads first
<lifeless> if we knew that 'user foo' did the upload, we could always notify use foo, regardless of the package metadata status
<wgrant> SFTP provides no progress information.
<wgrant> And client support in Ubuntu is recent.
<cjwatson> our current dput.cf defaults to FTP
<cjwatson> I don't think it's reasonable to disable it in LP until and unless that's changed, at the very least, including in stable releases
<lifeless> I think we should simplify our upload processing code for SFTP
<lifeless> and then get Ubuntu to change (or try changing) to SFTP
<cjwatson> wgrant: in principle SFTP supports progress information
<cjwatson> wgrant: what makes you say that?
<wgrant> cjwatson: The current client does not.
<cjwatson> YM dput?
<wgrant> The vast majority of current uploads, both PPA and Ubuntu, are FTP
<wgrant> Yes.
<wgrant> I'm not sure the default dput.cf even has an SFTP PPA section.
<wgrant> Because it requires configuration.
<wgrant> (we rely on username matching, not just key)
<cjwatson> oh, and Debian's dput doesn't have SFTP support yet
<cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505173
<lifeless> does that matter particularly?
<cjwatson> it's another data point, and I'm sure it affects some percentage of users
<wgrant> It would be pretty unpleasant to make it impossible to upload to PPAs except from Ubuntu.
<wgrant> People do use Debian, you know :)
<lifeless> wgrant: it wouldn't be impossible: lftp etc can do it, and folk can apply the patch
<lifeless> https://bugs.launchpad.net/launchpad/+bug/499438 is what sparked these questions
<_mup_> Bug #499438: Better handling of fatal upload errors <lp-soyuz> <soyuz-upload> <Launchpad itself:Triaged by julian-edwards> < https://launchpad.net/bugs/499438 >
<lifeless> cjwatson: whats the right way forward to get Ubuntu to promote SFTP for uploads - I'm primarily concerned with new PPA users, the set of folk most likely to make packaging fubars anyhow
<cjwatson> I doubt I'm capable of thinking of a problem that complex at 1:40
<cjwatson> am
<lifeless> fair enough
<lifeless> I will probably raise it again
<wgrant> lifeless: Initial config is the difficult bit.
<cjwatson> right
<wgrant> We can't provide a default config, so we have to tell people to edit their dput.cf
<wgrant> Like we did 4 years ago :/
<lifeless> or get credentials from lptools, which we use for a bunch of other things too
<cjwatson> unless we're very careful, all we achieve is rearranging the deckchairs on the UI.
<wgrant> lifeless: lptools?
<cjwatson> lptools, which ~nobody has installed
<StevenK> bzr launchpad-login ?
<wgrant> Exactly.
<wgrant> Nobody uses lptools.;
<lifeless> cjwatson: thats true, OTOH deckchairs the user can see are easier to examine than ones they cannot :)
<lifeless> didn't a bunch of ubuntu-dev-tools get shuffled over to lptools ?
<lifeless> I was fairly sure they did, during the last cycle
<cjwatson> ubuntu-dev-tools declares no package relationships on lptools
<cjwatson> so if they did, it was shuffled out of sight
<StevenK> lifeless: All I can see that is doing is having more people ask "Why can't I just upload using dput?"
<lifeless> yeah, I can see
<lifeless> could use ubuntu-dev-tools
<wgrant> Other sites seem to rely on uniqueness of SSH keys.
<lifeless> StevenK: a) experienced folk can, b) new folk follow docs on the wiki, and *then* also mess up
<cjwatson> It's true that a few tools were moved, but they were the sorts of things only pretty LP-aware people used anyway
<cjwatson> lp-get-branches, lp-grab-attachments, lp-project-upload, lp-list-bugs, lp-set-dup, lp-shell
<lifeless> you didn't want to reason about this at 1:40am
<lifeless> so don't :)
<cjwatson> you asked me to come up with a solution :)
<cjwatson> picking holes is easier ;)
<lifeless> heh
<wgrant> cjwatson: qastaging update finished 4 minutes ago, btw.
<cjwatson> thanks.  upgrading mawson
<lifeless> so, as long as we never need to go spelunking on germanium again to determine what went wrong, I will accept nearly any hole you care to poke
<lifeless> I think pushing it back onto the users machine where they can locally diagnose and get up-front errors is a good thing
<cjwatson> I wonder if there's any way to push errors over the FTP session
<wgrant> There is.
<wgrant> We do it already.
<StevenK> Which we don't do for SFTP
<wgrant> But lifeless knows that well, so I assume he a reason to ignore it.
<wgrant> +has
<lifeless> it has limits, and we will happily email the wrong person if the package is a plain copy from e.g. Debian
<lifeless> one of the limits is that core twisted tries very hard to turn such events into OOPSes
<lifeless> (oh no something went wrong, must alert the admin)
<lifeless> thats probably fixable, but even then we still can't notify *anyone else* that the problem occured.
<lifeless> e.g. via upload subscriptions
<cjwatson> I agree in principle that SFTP is a good thing to use; the road to making it mandatory probably isn't short though.
<cjwatson> I guess that's all I'm really saying
<lifeless> making it the default for new users would go a long way
<cjwatson> Yes
<lifeless> we could just say 'try over sftp' to any experienced user with an undiagnosable problem
<lifeless> e.g. deprecate but not disable ftp
<cjwatson> Or if we can't figure out the user's LP login, fall back to FTP
<wgrant> The experienced users aren't going to have trouble :)
<cjwatson> You'd still win if we reduced the incidence of spelunking significantly
<cjwatson> Just not as much
<lifeless> mmm, I'd like something more aggressive than 'if we can't figure it out'
<lifeless> e.g. opt-in to ftp
<cjwatson> "What's your LP login?  Type 'lifeless' to use FTP"
<lifeless> (remember too that we have folk dealing with private packages etc, so the default really wants to be non plaintext
<lifeless> cjwatson: :)
<lifeless> cjwatson: put that in for april 1st please
<cjwatson> I have a better April 1st way ahead of that, which I've been failing to implement for five years :)
<cjwatson> Actually, seriously, interactivity wouldn't be awful
<lifeless> poor andi
<lifeless> still confused by LP's UI.
<wgrant> Again?
<cjwatson> just have /usr/share/dput/sftp.py ask you and save the answer somewhere
<lifeless> 3 imports one project
<lifeless> cjwatson: +1
<cjwatson> enhancement: figure it out automatically without asking.  but that's nice-to-have.
<cjwatson> (I'm assuming sftp.py gets a terminal.)
<cjwatson> And then have sftp.py fall back internally to FTP on abject failure.
<cjwatson> (With loud warnings.)
<StevenK> mwhudson was talking about anonymous-ssh, so we could utilise that too ...
<lifeless> StevenK: not useful here
<cjwatson> Let me not attempt to figure out the confidentiality properties of anonymous SSH
<lifeless> StevenK: the point is knowing the user so we can notify sensibly
<StevenK> cjwatson: Or fall back to trying $USER ?
<lifeless> StevenK: fixes a raft of corner cases that we have today, anonymous-ssh wouldn't do that
<cjwatson> StevenK: *handwave* that kind of thing
<cjwatson> I wonder what the performance difference is for large uploads over SFTP vs. FTP
<StevenK> lifeless: SFTP for uploads still doesn't solve notifications for syncs ...
<lifeless> cjwatson: SFTP should be faster (tcp window already open)
<cjwatson> Syncs will all be API soon enough, so you'll at least have a username
<cjwatson> lifeless: haha my bugmail disagreed last I checked
<lifeless> indeed, and *I'm not talking about syncs* :P
<lifeless> failing to fix problem B doesn't make a solution to problem A better or worse
<lifeless> having a single solution to A and B is nice, of course.
<cjwatson> (the HPN people talk about FTP as a comparator for their none-cipher work)
<lifeless> but you need to demonstrate a link between them for it to be worth considering - whats the link between syncs, where we know all the package data is intact, and uploads, where its all arbitrary
<cjwatson> comparand.  blah.  I keep getting that wrong.
<lifeless> cjwatson: interesting
<cjwatson> Ur, help.  What does http://paste.ubuntu.com/792323/ mean when upgrading dogfood?
<lifeless> you keep both pieces?
<lifeless> the dogfood config has old and deleted config keys
<StevenK> Haha
<wgrant> Ah, yes, let me fix that.
<StevenK> Yeah, wgrant broke it
<wgrant> I don't think it's the DF config that's broken. It's just that the prod configs are out of date.
<wgrant> cjwatson: Should be fixed.
<cjwatson> wgrant: Thanks; should I carry on with the build or did you do that?
<wgrant> cjwatson: I didn't touch it.
<wgrant> Come on, do you think it can build that quickly? :)
<cjwatson> Heh
<mwhudson> inferring username from ssh key is technically easy i guess
<mwhudson> and that UNIQUE constraint on sshkey would have been interesting a few years back :-)
<wgrant> Now that there's more than just a few keys, yeah...
<cjwatson> I thought that's why we added the UNIQUE constraint
<wgrant> There isn't one, AFAIK.
<wgrant> Indeed not.
<cjwatson> Adding one might not be a terrible idea.
<wgrant> There is one key with 19 links, another with 20...
<wgrant> 650ish with 2 links, 40 with more than 2
<cjwatson> :-(
<cjwatson> That doesn't block lifeless' project though; we have the username to work with, not just the key
<wgrant> Yeah
<micahg> lifeless: also, about owners and notifications, some people want to be owners to just administer and not have rights
<lifeless> micahg: yes, thats why we have separate roles, though wgrant is campaiging that this doesn't make sense
<wgrant> lifeless: No.
<wgrant> lifeless: I'm campaigning that the owner special case doesn't make sense.
<wgrant> I am campaigning that admin+membership should be separated.
<wgrant> Currently you have a list of members, and a list of admins who are members, and a single not-quite-admin-but-not-member.
<wgrant> When a list of members and a list of admins who may also be members would work fine.
<lifeless> with the recent change to admins promoting admins, hmm
<lifeless> perhaps
<micahg> that would solve the DMB use case as well
<wgrant> Yup.
<wgrant> Morning jtv.
<jtv> hi there wgrant, happy 2012
<wgrant> Likewise.
<jtv> thank you
* jtv changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jtv | Firefighting: - | Critical bugtasks: 3*10^2
<wgrant> lifeless: So, how do you propose to find transitive dependencies without a resolver? :)
<lifeless> wgrant: I thought you meant something different apparently
<lifeless> jtv:  https://bugs.launchpad.net/launchpad/+bug/506497 - is that more done now?
<_mup_> Bug #506497: import-queue-gardener gives file path a higher priority than a manually assigned template <import-queue> <lp-translations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/506497 >
<lifeless> jtv: also would like your input on https://bugs.launchpad.net/launchpad/+bug/506516
<_mup_> Bug #506516: Failed migration of ubuntu kdeaddons to message-sharing <lp-translations> <message-sharing> <Launchpad itself:Triaged> < https://launchpad.net/bugs/506516 >
<jtv> lifeless: probably not done, but I'm not even sure those tools still work.
<lifeless> jtv: should I invalid it? or incomplete?
<jtv> lifeless: incomplete.
<micahg> lifeless: what would you think of marking bug 529957 invalid since we build translation packages out of the Firefox/Thunderbird sources now?
<_mup_> Bug #529957: XPIPO file uploads should be disabled <lp-translations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/529957 >
<lifeless> micahg: have we ditched the XPIPO support?
<lifeless> micahg: should we drop it?
<lifeless> micahg: (also does that mean thunderbird is not translatable in Ubuntu using LP?)
<micahg> lifeless: I should check with chrisccoulson first, but I think so, at least once the Firefox migration in lucid/maverick is complete which should be some time this month
<micahg> lifeless: thunderbird actually never was IIRC
<lifeless> so I don't think we should invalidate the bug while we have the code it talks about around
<lifeless> but we could change it to be 'this code can be deleted'
<micahg> well, I guess one day if we ever get a way to push translations back upstream, we could import from the source uploads and push changes upstream, but I guess in that scenario, we don't need the xpipo code either
 * StevenK stabs the screwed up security model SPRBs use.
<lifeless> jtv: so, thoughts on bug https://bugs.launchpad.net/launchpad/+bug/509109 and https://bugs.launchpad.net/launchpad/+bug/506516 ?
<_mup_> Bug #509109: Deadlock in message-sharing-merge while migrating brasero <lp-translations> <message-sharing> <Launchpad itself:Triaged> < https://launchpad.net/bugs/509109 >
<_mup_> Bug #506516: Failed migration of ubuntu kdeaddons to message-sharing <lp-translations> <message-sharing> <Launchpad itself:Triaged> < https://launchpad.net/bugs/506516 >
<jtv> âIf they're really a problem, they'll come back.â
<lifeless> jtv: they were both migration stuff; thats done, right ?
<jtv> Yes, though the code may still be in use.
<lifeless> ah
<lifeless> the question is, should the maintenance squad sit down and work on them ?
<jtv> Not based on these reports, no.  I'd just close them.
<jtv> Too much has changed since those bugs were reported.  If they're really a problem, they'll come back.
<lifeless> thanks, done.
<lifeless> hmm, something is seriously odd with multi-project -importance bug sort order
 * StevenK stabs diff generation and/or longpoll
<lifeless> I wonder that noone has hacked https://bugs.launchpad.net/launchpad-buildd/+bug/516208 into the thing already
<_mup_> Bug #516208: disable Automake's silent rules <feature> <Launchpad Auto Build System:Triaged> < https://launchpad.net/bugs/516208 >
<cjwatson> Right, mawson is all ... whoever-cares' again.
<StevenK> cjwatson: Did you QA mvo's rev, or is that his to do?
<StevenK> Launchpad encountered an error during the following operation: generating the diff for a merge proposal.  The source branch has no revisions.
<StevenK> Blink
<cjwatson> StevenK: I did his
<cjwatson> So it's just jelmer's recipe format thing left
<StevenK> Indeed. Thanks.
<StevenK> jtv: O hai. I'd like a review, but the branch scanner has de-pramed its toys while scanning my branch. The diff is at http://pastebin.ubuntu.com/792375/
<jtv> StevenK: working on a long one right now, but you'll be next.
<wgrant> StevenK: Make it rescan?
<StevenK> wgrant: By pushing agai
<StevenK> n?
<wgrant> Yes.
<wgrant> You may have to push -r-2 then push again, I forget.
<StevenK> I thought we worked out that -r-2 doesn't work?
<wgrant> It can't not.
<StevenK> % bzr push -r-2
<StevenK> Using saved push location: lp:~stevenk/launchpad/hide-forbidden-sprbs
<StevenK> No new revisions to push.
<wgrant> --overwrite
<StevenK> And then bzr push quickly?
<wgrant> No need to be quick.
<wgrant> But if you want.
<StevenK> The branch scanner should log branch.unique_name
<wgrant> Yes.
<StevenK> Bleh, job logging is complete crap
<StevenK> You can't get at the logger in the actual job's run() method.
<StevenK> wgrant: Looks like the scanner choked on it again
<wgrant> Yay
<lifeless> StevenK: its not on an attribute? Also why would you need to, thats not the logging API
<StevenK> -        return '%s (ID %d)' % (class_name, ijob_id)
<StevenK> +        return '%s (ID %d) %s' % (class_name, ijob_id, repr(job))
<StevenK> I think that will help
<lifeless> StevenK: wgrant: is  https://bugs.launchpad.net/launchpad/+bug/525749 part of disclosure, do you think ?
<_mup_> Bug #525749: A Branch's visibility setting page contain the word 'visibility' <confusing-ui> <lp-code> <Launchpad itself:Triaged> < https://launchpad.net/bugs/525749 >
<wgrant> lifeless: Probably, yes.
<wgrant> Although the summary seems to be inverted.
<lifeless> indeed
<lifeless> will you fix?
<lifeless> wgrant: is https://bugs.launchpad.net/launchpad/+bug/527550 still ?
<_mup_> Bug #527550: CopyChecker._checkArchiveConflicts erroneously permits copies of sources with failed and unpublished builds <lp-soyuz> <soyuz-core> <Launchpad itself:Triaged> < https://launchpad.net/bugs/527550 >
<wgrant> That hasn't been touched recently.
<wgrant> So yes.
<StevenK> lifeless: So to answer your question, it is not on a attribute. And it would be very useful for say, IDSJ.
<lifeless> StevenK: but why? logger = logging.getLogger('lp.jobs.foo')
<lifeless> done
<lifeless> wgrant: and  https://bugs.launchpad.net/launchpad/+bug/527551?
<_mup_> Bug #527551: Intra-archive copying of a source with a failed build may leave that source uncopyable <lp-soyuz> <soyuz-core> <Launchpad itself:Triaged> < https://launchpad.net/bugs/527551 >
<wgrant> lifeless: Still there.
<lifeless> wgrant: and https://bugs.launchpad.net/launchpad/+bug/528459 ?
<_mup_> Bug #528459: PPA does not delete old packages after new build <lp-soyuz> <ppa> <Launchpad itself:Triaged> < https://launchpad.net/bugs/528459 >
<wgrant> lifeless: Likewise.
<wgrant> NBS
<StevenK> lifeless: Because I prefer it was in the same log as the job runner uses
<lifeless> StevenK: and? thats orthogonal
<lifeless> StevenK: logger objects are not intended to be passed around willynilly
<lifeless> StevenK: fixtures.FakeLogger may help you
<StevenK> jtv: Still dealing with the large review?
<jtv> Yes
<jtv> But the first container of coffee has arrived, which should speed things up.
<jtv> We're slightly hung over (in the non-imbibed sense) from an all-night drive during the holidays.
<jtv> (âThe holidaysâ for us being January 2 & 3)
<micahg> the lpia PPA queue does not seem to be dispatching to the buildd
<wgrant> webops: please stab gold and restart buildd-manager
 * wgrant throws some builders at lpia.
<spm> this is terrible. I can nearly do this from memory.
<micahg> wgrant: I would just give it one, no one should be using lpia anyways
<lifeless> wgrant: so this bug - https://bugs.launchpad.net/launchpad-buildd/+bug/533583
<_mup_> Bug #533583: build fails where no error is present <Launchpad Auto Build System:Triaged> < https://launchpad.net/bugs/533583 >
<lifeless> what is the defect/problem ?
<wgrant> micahg: Since there seem to be about 30 Mozilla builds on the virt builders at the moment, sounds like a good plan.
<micahg> it's that time of day :)
<wgrant> lifeless: sistpoty disagrees with Ubuntu policy.
<wgrant> Needs to be argued with lamont.
<micahg> ISTR another bug to make that not fatal
 * micahg thinks it's a lack of scrolling to the bottom :)
 * lifeless tosses oil on the fire
<micahg> lifeless: you didn't have to toss wgrant in as well :)
<lifeless> he is the oil ?
<micahg> nah, I think he was holding it :)
<lifeless> didn't poolie do this? https://bugs.launchpad.net/launchpad/+bug/547036
<_mup_> Bug #547036: The buildd code should be removed from the Launchpad tree <canonical-losa-lp> <lp-soyuz> <tech-debt> <Launchpad itself:Triaged> <Launchpad Auto Build System:Triaged> < https://launchpad.net/bugs/547036 >
<StevenK> jtv: Just how big is this branch? :-P
<spm> wgrant: btw, that ppa et al reset is done and done
<wgrant> spm: Thanks.
<StevenK> wgrant: Since jtv appears to be AWOL, would you mind reviewing the diff at http://pastebin.ubuntu.com/792375/
<lifeless> wgrant: StevenK: opinions on  bug 547036 ?
<_mup_> Bug #547036: The buildd code should be removed from the Launchpad tree <canonical-losa-lp> <lp-soyuz> <tech-debt> <Launchpad itself:Triaged> <Launchpad Auto Build System:Triaged> < https://launchpad.net/bugs/547036 >
<wgrant> lifeless: poolie fixed it months ago?
<wgrant> StevenK: He might be back now :)
<lifeless> wgrant: thats what I thought, was seeking confirmation
<lifeless> StevenK: see bug https://bugs.launchpad.net/launchpad/+bug/551414
<_mup_> Bug #551414: log messages in jobs are discarded <jobs> <lp-code> <Launchpad itself:Triaged> < https://launchpad.net/bugs/551414 >
<StevenK> jtv1: Still fighting with the large branch? How large is it?
<jtv1> StevenK: it's not the branch, it's the interruptions
<lifeless> boo!
 * StevenK nails wgrant to IRC.
 * wgrant kicks Optus in the face :)
<nigelb> I love that those of us in the 3rd world have better internets.
 * nigelb waves to jtv1 
<jtv1> Hi nigelb
<jtv1> Happy new year etc!  No time to chat further right now, sorry :)
<nigelb> heh
<StevenK> nigelb: What do you call an Indian cricketer with a century next to their name?
<StevenK> nigelb: A bowler.
<lifeless> jtv1: what is 'pottery' ?
<wgrant> We do not speak its name.
<jtv1> lifeless: it's the code for generating POTemplates from branches.  Runs in the build farm.
<lifeless> thanks
<jtv1> wgrant: yes we do.  I just did.  Robert just did.
<wgrant> Bah
<lifeless> LaunchpadTimeoutError: Statement: 'UPDATE Project SET max_bug_heat=(SELECT COALESCE(MAX(heat), 0) FROM
<wgrant> Yes :)
<lifeless> staaaaaaaaab
<wgrant> I've been saying that for well over 18 months now.
<lifeless> is there a better way?
<lifeless> https://bugs.launchpad.net/launchpad/+bug/582805https://bugs.launchpad.net/launchpad/+bug/582805
<_mup_> Bug #582805: On template generation, we should add a log file to the templates tarball as well <lp-translations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/582805 >
<lifeless> https://bugs.launchpad.net/launchpad/+bug/582805
<_mup_> Bug #582805: On template generation, we should add a log file to the templates tarball as well <lp-translations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/582805 >
<_mup_> Bug #582805: On template generation, we should add a log file to the templates tarball as well <lp-translations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/582805 >
<lifeless> 1123 high bugs, and counting
<wgrant> 330 critical bugs
<wgrant> what's your point?
<micahg> lifeless: are you counting up or down?
<wgrant> 330 critical bugs and 4 people, even.
<lifeless> micahg: our bug handling policy says we have three groups of bugs
<lifeless> the great unwashed
<lifeless> 6 months of todo (high)
<lifeless> as much zomg as there is (critical)
<micahg> lifeless: I'm familiar :), just wondering which way you're counting on the 6 month pot :)
<wgrant> lifeless: Huh
<wgrant> How is high 6 months?
<wgrant> Given that we have 4 people...
<wgrant> That's like 10 bugs.
<lifeless> micahg: and that every quarter we'll review the high to keep it trim; its a year overdue. The first one is a doozy
<lifeless> wgrant: yes, I'll be doing a couple of passes I suspect
<micahg> lifeless: ISTR you doing this recently
<lifeless> micahg: that was eliminating mediums
<micahg> ah
<lifeless> micahg: which were stuck in limbo, some were crits, some high, many/most low
<micahg> wgrant: only 4 people on highs now?
<stub> For the next few months at least.
<wgrant> Evening stub.
<wgrant> stub: personless accounts: why do we still have them?
<stub> morning
<stub> Possibly placeholder people generated when we import stuff like translations etc.
<stub> Not sure what does an ensurePerson or whatever the call is any more.
<wgrant> personless accounts, not accountless persons.
<stub> Yer... backwards.
<wgrant> We have 3 million personless accounts.
<wgrant> From SSO
<stub> Didn't I clean them out already?
<wgrant> No.
<wgrant> We cleaned out the people from shipit.
<wgrant> But not the accounts from SSO, or the accounts that were left over from deleted ShipIt people.
<stub> k. more cleanup needed then. They just waste space I think.
 * stub looks for other Account references
<wgrant> openididentifier, emailaddress and person should be all
<wgrant> I have a branch to delete EmailAddress.account, which depends on all those emailaddresses and accounts being gone :)
<stub> Ok.
<stub> So we need to trash emailaddresses and openididentifiers not linked to a person and accounts not linked to a person.
<wgrant> Yep.
<wgrant> Ah, accountpassword too
<wgrant> Not that it's used any more except by tests.
<jtv> StevenK: gasp!  Finally getting to yours now.
<jtv> StevenK: I don't suppose check_permission might do any de-pramming of its own when presented with a None?
<StevenK> jtv: Oh, in initial_values?
<jtv> I think so â name not included in diff context.
<jtv> Line 32 of your diff.
<jtv> (By the way, updating copyrights is easy: just run utilities/update-copyright just like you do utilities/format-new-and-modified-imports.
<StevenK> Which is what I did
<StevenK> :-)
<wgrant> Also, if people don't run format-new-and-modified-imports in all their branches now I will be very upset :)
<wgrant> Since they're all in good order now.
<jtv> So will I, but there is one problem: lp.codehosting.
<wgrant> I fixed most of those.
<wgrant> There's only like 3 places that need it.
<jtv> I thank you.
<wgrant> and they all have FIRST comments now
<wgrant> Which format-imports handles nicely.
<wgrant> I also made it handle _pythonpath properly.
<jtv> Oh, there's a convention for that?  Great.
<wgrant> And then ran it over the whole tree.
<jtv> All wonderful.  I suppose _pythonpath still elicit lint warnings?
<wgrant> An import preceded by a comment starting "# FIRST" will be put after the stdlib imports, but before the third-party ones.
<wgrant> Yes.
<wgrant> Not sure how to suppress those globally.
<jtv> This will also make my megalint branches a bit less mega.  :)
<wgrant> This one touched about 1200 files.
<StevenK> jtv: Does http://pastebin.ubuntu.com/792471/ make you less nervous?
<jtv> StevenK: wasn't saying nervous.  You should see the review I just finished.
<StevenK> jtv: That should make certain check_permission() doesn't get a None.
<jtv> It does make me feel slightly safer, as well as appreciated.  :)  Thanks.
<StevenK> I'm actually more comfortable with how I've written it now.
<jtv> That's good too.
<jtv> You've got my vote, with one additional note.
<StevenK> jtv: If we say something other than "This recipe has not been built yet" we may leak the existance of the private PPA
<StevenK> Pretending the build doesn't exist if they can't see it is safest.
<jtv> And the recipe needs to remain visible?
<jtv> What about "this recipe has not been built yet (or if it has, you are not permitted to see the builds)"?
<StevenK> We do not support private recipes or recipes making use of private branches.
<wgrant> We'd have to add that disclaimer to practically every list in Launchpad.
<jtv> I see.  Nasty problem.
<lifeless> yes the recipe has to stay visible
<jtv> Then again, I suppose it's a bit of a tree falling with no-one to hear.
<lifeless> because it may be owned by e.g. you
<StevenK> jtv: It's a rabbit hole. wgrant, sinzui, wallyworld, jcsakett and I have been arguing about problems like that for months.
<StevenK> lifeless: At the moment, it doesn't. :-)
<StevenK> But sinzui agreed it's a disclosure bug.
<jtv> I suppose the only relevant information to an unprivileged user would be "yes, this recipe can build" and they'll find out eventually if that's not the case.
 * StevenK checks the scanner choked on the branch again.
<StevenK> Pity. It does.
<lifeless> StevenK: doesn't your branch make the recipe stay visible ?
<StevenK> lifeless: Yes. I was making a joke that it doesn't on production.
<lifeless> ah, heh
<stub> How much work did you guys land over the break? New Year branch pulling just keeps going and going...
<StevenK> stub: wgrant and sinzui's fault. They effectively emptied lib/canonical
<wgrant> stub: We moved a couple of hundred thousands lines of lib/canonical remnants, and properly formatted the imports in every file.
<stub> I wonder if you could compile a diff to a regexp search and replace?
<wgrant> Heh
<lifeless> yes, you can
<wgrant> stub: Also, I reverted the EmailAddress.{person,account} consistency patch, as it was going to take 3-4 minutes to apply.
<lifeless> wgrant: do you think https://bugs.launchpad.net/launchpad/+bug/566339 is fixed, or not ?
<_mup_> Bug #566339: Cannot accept package which would notify private email addresses <boobytrap> <lp-soyuz> <Launchpad itself:Triaged> < https://launchpad.net/bugs/566339 >
<stub> wgrant: Really? What was it doing besides adding the triggers?
<wgrant> stub: Not triggers, but check constraints.
<stub> oh... ic. hmm...
<wgrant> Apart from the questionable sensibility of having cross-table functions in check constraints, before pg 9.1 they can't be added without a full scan.
<wgrant> So, instead of turning them into triggers I decided to fix the inconsistencies by dropping EmailAddress.account instead.
<stub> Yes, that would have been my preferred approach but gmb thought this was a quicker fix and wanted the quicker fix.
<StevenK> wgrant: You managed to drop it?
<wgrant> The actual code changes were reasonably shallow. But the tests, oh god the tests.
<wgrant> All fixed now, anyway.
<stub> Main goal being to locate the code generating the inconsistent data.
<wgrant> In a final ec2 run before being split into 4.
<StevenK> wgrant: Four now?
<wgrant> StevenK: Yes.
<wgrant> Mailing list refactorings are being split up separately.
<StevenK> Ah
<wgrant> Because the queries and tests were awful.
<StevenK> s/were/are/ ?
<wgrant> stub: I never tracked down exactly what it was, but I believe it's in the code around reconciling openididentifiers, persons and accounts on login when there are conflicts and the account needs reactivating.
<wgrant> But account has basically had all its functionality ripped out in this branch, so it doesn't matter.
<stub> Need to convince bzr that removing a directory containing nothing but garbage is fine
<wgrant> stub: bzr clean-tree
<wgrant> Will ask you if you want to remove unknown files/directories
<wgrant> It's how I get around these conflicts, and tends to work pretty well.
<stub> yer. I know why the guard is there, but so far it has only been false positives.
<wgrant> Yeah
<wgrant> pyc ftl.
<stub> bzr knows about files to ignore, we could teach it about garbage in a similar fashion.
<stub> I guess it doesn't matter that much
<lifeless> bzr resolve --take-other should clean them up
<stub> Just complaining that it is my responsibility to fix things up that aren't really broken, but bzr isn't intelligent enough to know if this case is potential data loss or noise.
<StevenK> wgrant: r14625 is ready for you to QA.
<lifeless> wgrant: so, can has answer to last two q's?
<StevenK> jelmer: Can haz QA for r14620?
<wgrant> lifeless: What was the one that wasn't bug #566339?
<_mup_> Bug #566339: Cannot accept package which would notify private email addresses <boobytrap> <lp-soyuz> <Launchpad itself:Triaged> < https://launchpad.net/bugs/566339 >
<lifeless> https://bugs.launchpad.net/launchpad/+bug/582805
<wgrant> I don't believe that one is fixed.
<_mup_> Bug #582805: On template generation, we should add a log file to the templates tarball as well <lp-translations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/582805 >
<wgrant> StevenK refactored that code, but didn't change it much.
<StevenK> Let's just delete it instead.
<wgrant> lifeless: Commented and closed.
<lifeless> thanks
<wgrant> stub: So, do you want me to write the SQL to clean up the accounts, or can you do it?
<stub> wgrant: It needs to be a garbo job, and I was going to do it when my branches have synced.
<stub> Unless you want to... just a couple of BulkPruner tasks I think.
<wgrant> Mm, I think the references are few enough that you could do it without garbo.
<wgrant> But I guess it's the same as PersonPruner, really.
<stub> We don't want to block creating new accounts while the SQL runs...
<lifeless> pruners are easy
<stub> bah... launchpaddatabaseupdatelog.end_time isn't being populated :-P
<wgrant> stub: It's also crashing with dupe ids.
<wgrant> On staging restores.
<wgrant> Which is a little bit odd.
<adeuring> good morning
<stub> wgrant: Because it gets populated when we build the database schema, then we attempt to repopulate it by restoring the similar data from production.
<wgrant> Ah!
<stub> hmmm...
<stub> ?
<stub> oh... full updates should work, but code updates can fail like that.
<stub> no..
<stub> hmm...
<stub> need to look over the scripts.
<wgrant> Code updates work, AFAICS.
<wgrant> Hm
<wgrant> Although they've been failing early.
<wgrant> Because of the bad patch.
<wgrant> So maybe not.
<lifeless> stub: remember we're dropping the updatelog
<lifeless> stub: (and trusted.sql etc) - moving to just patch applications
<stub> oh right, so I'll ignore the missing field for now and maybe trash it if it is the best way to fix staging.
<wgrant> stub: Hopefully _new is salvagable.
<wgrant> But I'm not sure.
<stub> wgrant: Any particular reason you decided to drop EmailAddress.account rather than Person.account? You can argue either way.
<danhg> morning
<wgrant> stub: EmailAddress.{account,person} could still be inconsistent, as there can be multiple email addresses.
<stub> I guess we might end up with Person records with no emailaddresses once we start adding other contact mechanisms
<stub> Good point.
<wgrant> And Account is hopefully not long for this world.
<lifeless> wheee
<lifeless> https://bugs.launchpad.net/launchpad/+bug/599377
<_mup_> Bug #599377: FilebugShowSimilarBugsView.show_duplicate_list treats contextUsesMalone as a property but it's a method <dhrb> <dupefinder> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/599377 >
<stub> AssertionError: Can't create a Person for an account which has no email.
<wgrant> stub: Where'd you run into that?
<wgrant> Tests?
<wgrant> I assume that's from Account.createPerson?
<stub> wgrant: Yup. test_garbo
<stub> Think it is on trunk
<stub> test_RevisionAuthorEmailLinker is one of two
<wgrant> What have you changed to trigger that?
<stub> Two new daily jobs. Hmm... might be my change actually. A lot of the tests just run 'all daily jobs', and I might be destroying the data in a way the test does not expect.
<wgrant> Heh, yes.
<wgrant> That sounds likely.
<stub> ok... leave this until after lunch then before wife gets antsy
<wgrant> IIRC test_RevisionAuthorEmailLinker relies on an unlinked Account surviving a garbo run.
<wgrant> For one of its cases.
<wgrant> But that can probably go, since it's no longer a valid data state.
<stub> Has lp hung or my censorwall screwing up?
<stub> oh... there it is
<wgrant> stub: There weren't parens in the original, so I didn't add them. Although I wonder if that's just how it rendered it, as it seems to change whitespace.
<wgrant> I shall fix it, anyway.
<stub> wgrant: They get stripped by PG, which always worries me
<wgrant> Oh, that is rather awful.
<stub> It gets it right, but I know *I* will mess things up without them.
<wgrant> I noted their absence and considered fixing them. But then decided to make minimal changes.
<wgrant> Didn't think it would strip them...
<stub> it is reconsituting the expression that was compiled I think, sans comments etc.
<stub> not sure
<wgrant> Yeah, I was thinking it couldn't do that, but of course this is a view not a function.
<wgrant> Thanks lifeless.
<wgrant> frankban: I'd remove the request for 11239, as it is redundant and likely to confuse.
<wgrant> stub: As for the merged check, the more likely reason for its omission is the preferredemail check.
<wgrant> Since a merged account will never have an email address, let alone a preferred one.
<frankban> wgrant: let me guess, applying 11275 also means applying my patch, am I right?
<wgrant> frankban: Yep.
<frankban> wgrant: ok thanks
<stub> True. Probably me prematurely optimizing.
* jtv changed the topic of #launchpad-dev to:  https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 3*10^2
<wgrant> frankban: That revision will be checked out, and all of the patches in that tree applied if they aren't already applied.
<wgrant> frankban: So all changes from current production to that revision will be applied.
<frankban> wgrant: very clear, request removed
<wgrant> frankban: Looks good, thanks.
<Laney> Remind me about teams: are administrators members?
<wgrant> Laney: At present yes.
<wgrant> Laney: Owners are not.
<Laney> OK, and what can the owner do that administrators cannot and vice-versa?
<wgrant> Today, owners can do everything admins can, plus change the owner, promote members to admins, and change their own expiry date if they are a member.
<Laney> uh, thought I was asking this in #lp, sorry
<wgrant> But this will change tomorrow.
<wgrant> As admins are gaining the ability to promote others to admins, and to change their own expiry date.
<wgrant> So the only things special about the owner are that they aren't necessarily a member, and that they can change the owner.
<wgrant> s/are that/will be that/
<Laney> and that they don't get all of the mail that admins do (#908144 prompted my questions).
<_mup_> Bug #908144: No way to customise receipt (or not) of team membership expiry/join emails <email> <notifications> <Launchpad itself:Triaged> < https://launchpad.net/bugs/908144 >
<wgrant> Ah, yeah, that too.
<wgrant> But that's not meant to be a privilege :P
<Laney> I was trying to figure out if having non-member administrators would be a better fit than subscribing to administrator mails
<Laney> thanks for the info
<wgrant> I would like to remove owners, and instead have non-member administrators.
<wgrant> It is somewhat controversial, however.
<stub> owner is needed as a defence against rogue administrators. We don't want to have to arbitrate in feuds.
<stub> wgrant: https://code.launchpad.net/~stub/launchpad/garbo-bulk-pruner/+merge/87461
<wgrant> stub: Do openididentifier and accountpassword cascade?
<wgrant> Ah, yes.
<wgrant> Handy.
<stub> yes, although looptuner tuning would be more predictable if those rows were purged in separate jobs.
<wgrant> Mmm.
<wgrant> Only slightly.
<wgrant> It should be pretty much 1-1-1
<stub> yer. don't think anyone would notice.
<StevenK> stub: I'm nitpicking, but you should update the copyright years. :-)
<wgrant> stub: What does SELECT COUNT(*) FROM emailaddress JOIN person ON person.id = emailaddress.person WHERE emailaddress.account IS DISTINCT FROM person.account; say on prod?
<wgrant> s/IS DISTINCT FROM/!=/ was 0 yesterday, but this is probably closer to what we actually care about.
<stub> wgrant: 0
<wgrant> Surprising!
 * wgrant approves
<wgrant> Thanks.
<stub> What is the script that does the copyright stuff automagically?
<wgrant> utilities/update-copyright
<stub> wgrant: Long term, I think it would be good to have both Account and Person. I don't like bots and things claiming to be people. We collapsed the concepts unfortunately (along with teams for even more fun).
<wgrant> stub: Possibly.
<wgrant> It's hard to say what we should do.
<wgrant> Person is really Principal.
<wgrant> Or Role.
<stub> Yes, and if we had called it something like that at the time things would be nicer now.
<wgrant> Anyway, we can easily shuffle these things around later on once we don't have a conflict-happy model :)
<benji> hmm, someone is looking for JS injection points: https://answers.launchpad.net/launchpad/+question/183686
<rick_h__> benji: heh, yep
<rick_h__> man, junk ppa and everything
<abentley> rockstar: About bug 911090: I know that Launchpad should be robust against 16 MB code review comments, but I also think tarmac should not be making 16 MB code review comments, because they make code review hard to read.
<_mup_> Bug #911090: merge proposal is broken with consistent timeouts <timeout> <Launchpad itself:Triaged by abentley> <Tarmac:New> < https://launchpad.net/bugs/911090 >
<cr3> odd, launchpad.net/projects seems to be forbidden now :(
<jelmer> cr3: probably something private on that page
<cr3> jelmer: is that expected behavior or should I report a bug against launchpad itself?
<stub> That would be a bug.
<jelmer> cr3: that's a bug
<jelmer> presumably those private items that you're not allowed to view should just be hidden rather than making the entire page inaccessible
<stub> Projects lists 'latest teams', and should be hiding private teams you shouldn't be able to see rather than making the page fail
* abentley changed the topic of #launchpad-dev to:  https://dev.launchpad.net/ | On call reviewer: abentley | Firefighting: - | Critical bugtasks: 3*10^2
<cr3> jelmer, stub: reported bug #911794
<_mup_> Bug #911794: /projects page now returns forbidden <Launchpad itself:New> < https://launchpad.net/bugs/911794 >
<rick_h__> benji: https://bugs.launchpad.net/launchpad/+bug/911632
<benji> rick_h__: I guess he found one.
<rick_h__> yea, checking it out.
<abentley> frankban: Please target your reviews to "canonical-launchpad-reviewers" (which is the default-- you can just leave it blank in the web form) rather than "launchpad"
<frankban> abentley: ok, thank you
<abentley> frankban: Thanks.
<deryck> abentley, is there a bug, either upstream or in lp, about pystache and scoping issues?
<abentley> deryck: I don't think so.
<deryck> abentley, do you mind filing an lp bug at least?  Should be a high bug, but we can work on it on maintenance, to avoid the tech debt in our code.
<flacoste> deryck: from a maintenance point of view, bug 911520 seems really terrible :-/ we should probably disable oops pruning until it's fixed
<_mup_> Bug #911520: Pruning fails to find any references, deleting all OOPSes older than a week <python-oops-tools:Triaged> < https://launchpad.net/bugs/911520 >
<abentley> deryck: However, I did report it to the author of pystache, who agreed it was a bug.
<deryck> abentley, ah, ok.  Do you mind filing the lp bug for us, too?
<deryck> flacoste, ack, I'll add the bug to the backlog and have oops pruning disabled.
<deryck> or the next lane rather.
<flacoste> deryck: thx
<flacoste> deryck, mrevell: when are we releasing bug-columns?
<abentley> deryck: As soon as I make sure it's still present...
<deryck> abentley, ah, ok.  Thanks!
<mrevell> flacoste, danhg is preparing the announcement.
<mrevell> deryck, do you have time for a call?
<flacoste> mrevell: great!
<deryck> mrevell, I do shortly.  give me 10-15 minutes to finish the stuff I'm on.  it's a bit interrupty :)  hard to just drop.
<mrevell> thanks deryck
<flacoste> gary_poster: we did complete the work to make apache serves the wadl right?
<gary_poster> flacoste, yes
<abentley> rick_h__: I'm filing a new bug, and when I start to type in "Further information:", the box gets longer immediately.  Is this fallout from your work?
<rick_h__> abentley: probably
<abentley> rick_h__: This is on Firefox 8.0
<rick_h__> abentley: ok
<abentley> deryck: bug 911840
<_mup_> Bug #911840: Launchpad works around pystache scoping bug <bug-columns> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/911840 >
<deryck> abentley, awesome, thanks!
<deryck> mrevell, we can chat now if you like.
<deryck> mrevell, Skype?
<deryck> rick_h__, and I understand our card titled: "Refactor bug listing ordering history code out of the template file" â¦.
<deryck> rick_h__, this would help prevent any other oops with history handling, if this was moved out to a separate js file, yes?
<rick_h__> deryck: right, it can't be tested like the rest of the JS code because of logic in the .pt files
<deryck> rick_h__, can you file a high bug about that and pass me the bug number then please?
<rick_h__> deryck: so factoring it out into a init or something that's called from the .pt would allow some better testing in JS tests
<rick_h__> deryck: sure thing
<rick_h__> deryck: 911857
<rick_h__> abentley: thanks, I confirm seeing that FF issue. Created a bug for it and will check it out.
<abentley> rick_h__: cool.
<deryck> rick_h__, thanks
<jcsackett> sinzui: have some time to mumble?
<sinzui> yes
<rick_h__> abentley: have a sec for a ?
<abentley> rick_h__: sure.
<rick_h__> so have this bug: https://bugs.launchpad.net/launchpad/+bug/911632 with this mp in progress https://code.launchpad.net/~rharding/launchpad/xss_911632/+merge/87507
<rick_h__> abentley: and looking at how to test this?
<rick_h__> abentley: it looks like I could try to change the dev data's name in the story, but seems a bit much for it
<rick_h__> abentley: so curious if I should try to create a new user with the known xss? Just say this is such a small fix, no new test?
<abentley> rick_h__:  I would test it by creating a person with a bogus name, rendering the relevant view (using getViewBrowser) and asserting that the resulting HTML did not have the unescaped version.
<rick_h__> abentley: ok cool, will check that out
<abentley> rick_h__: I would not touch the doctest.  You are writing a unit test, not documentation.
<rick_h__> abentley: yea, you're right. I was just searching for existing tests to latch onto and hit that
<rick_h__> abentley: thanks!
<abentley> rick_h__: np
<abentley> rick_h__: It would be interesting to change factory.makePerson to generate people with bogus names, but I don't think even that would catch all cases.
<rick_h__> abentley: yea, you have to be checking for the bad output specifically
<rick_h__> abentley: until it renders there's nothing to say <script> is a bad name
<abentley> rick_h__: If the bad characters were a consistent string, we could perhaps tweak some common code to puke if it was present.
<sinzui> flacoste, I would like your opinion of bug 910876. Choosing to remove code to revert to the 2009 rules makes fixing other bugs easy.
<_mup_> Bug #910876: "Remove assignee" no longer shown in bugtask assignee AJAX popup unless logged in user is the assignee <bugs> <person-picker> <Launchpad itself:Triaged> < https://launchpad.net/bugs/910876 >
<sinzui> maybe anyone can unassign a user, but the current rules apply to assigned teams
<nigelb> StevenK: HAHA good one
<flacoste> sinzui: replied, i basically agree with your first comment
<sinzui> thank you
<lifeless> morning
<cjwatson> argh @gina
<cjwatson> it imports dsc_binaries in an invalid format
<rick_h__> abentley: can you peek at https://code.launchpad.net/~rharding/launchpad/xss_911632/+merge/87507 when you get some time please?
<abentley> rick_h__: sure.
<rick_h__> ty
<abentley> rick_h__: why are you using getUserBrowser rather than getViewBrowser?  getViewBrowser already does the canonical_url bit.
<rick_h__> abentley: when I tried getViewBrowser it failed to generate the url as "xxx broke the chain"
<rick_h__> I went off the example from the test above it which was using getUserBrowser
<rick_h__> abentley: but now that you say that it makes sense, since I was sending it the canonical url bit
<abentley> rick_h__: "xxx broke the chain" is emitted by canonical_url.
<rick_h__> abentley: right, makes sense. Basically I copied the test above it.
<rick_h__> abentley: looking back at the getViewBrowser
<abentley> rick_h__: Perhaps you did not specify rootsite?
<rick_h__> abentley: right, I called it wrong. I called it like getUserBrowser
<abentley> rick_h__: Ah.
<rick_h__> abentley: crossing the streams between copying existing test and looking at getViewBrowser
<abentley> rick_h__: I see.
<abentley> rick_h__: r=me.
<rick_h__> abentley: ty
<abentley> rick_h__: However, I don't think the bug is meant to apply only to this issue.
<rick_h__> abentley: well, this guy hammered all over the site and this was the instance he found it.
<rick_h__> abentley: I've tried to think of how best to *auto* test this, but the cause was that someone at some point told zpt to specifically "not" escape this item
<rick_h__> abentley: I could grep through all of the templates looking for structure usage and verify the content is safe
<abentley> rick_h__: Okay.  I think you're right.  "persistent" made me think he was going for a broader issue.
<rick_h__> abentley: but wasn't sure if I should take the time to go through all that or not tbh.
<abentley> rick_h__: Did your second test "self.assertTrue(escapedname in browser.contents)" fail before you changed the template?
<rick_h__> abentley: yes, I put back the structure to verify
<abentley> rick_h__: I have a hunch it would pass because the user name appears elsewhere on the page.
<rick_h__> abentley: the change was in place because I found the issue before finding a good place for the test, but did walk back
<rick_h__> abentley: ah, see what you mean. However the first test fails
<rick_h__> abentley: that's why I check for both, to make sure there is no non-escape <script> and that there is in fact an escaped one
<abentley> rick_h__: I think the second test would not.  Can you check, and if so remove it?
<rick_h__> abentley: you're right that the second test doesn't do much since it's in there 3 places
<rick_h__> abentley: gotcha, will do
<rick_h__> abentley: cool, and got getViewBrowser() to pass and work right
<abentley> rick_h__: Great.
<abentley> rick_h__: alternatively, you could do a more exact match on the error text.
<rick_h__> abentley: right, gotcha
<abentley> rick_h__: Does your branch also fix it if the error message is loaded via AJAX?
<rick_h__> abentley: I'll double check. I believe so since it's a fix of the template used to generate the table view
<cjwatson> Is all the gina code actually in the LP tree?  I can't find any references to ImporterHandler other than its definition.
<cjwatson> But it seems like the main operating class ...
<cjwatson> see also bug 830904
<_mup_> Bug #830904: Is run-newgina.sh dead code? <Launchpad itself:Triaged> < https://launchpad.net/bugs/830904 >
<cjwatson> Never mind, I'm talking nonsense
<lifeless> wgrant: to answer your question '300'
<lifeless> flacoste: did you find a timeslot for us ? :)
<flacoste> lifeless: how about in 20 minutes?
<lifeless> flacoste: thats the parallel testing call
<lifeless> ah no, its not
<lifeless> thats me going into hospital for my once a month allergy shot
<flacoste> lifeless: when are you getting back?
<lifeless> flacoste: its 40m in + 40m back + 30m observation + 15m friction, more or less
<flacoste> lifeless: ping me when you get back, i'll probably still be around
<lifeless> 1030 appointment, so back ~ 1200, which is 2300UTC
<lifeless> flacoste: will do
<flacoste> hmm, i got my calculation wrong then
<flacoste> i thought that was 22UTC
<flacoste> lifeless: if you are back before 23 UTC then ping me, otherwise, we'll have to postpone to tomorrow
<flacoste> lifeless: before the parallel testing call, just ping me when you are online
<lifeless> flacoste: I will ping you; if you are around, \o/ if you are not tomorrow is go
<flacoste> lifeless: great!
<lifeless> sinzui: do we have a general 'lp is hard to read bug' ?
<lifeless> sinzui: I'd like to dupe https://bugs.launchpad.net/loggerhead/+bug/601392 on it
<_mup_> Bug #601392: Loggerhead should have a better text-background contrast with Chromium <css> <ui> <loggerhead:Triaged> < https://launchpad.net/bugs/601392 >
 * sinzui looks for mpt's last font bug
<flacoste> mpt isn't the one who filed it iirc
<flacoste> we won't fix it though
<flacoste> might have been poolie
<sinzui> lifeless, I thought mpt had reported a bug about fonts that was general to the issue. He wrote the Lp is harder to read than other hosting sites
<sinzui> This looks like a WAI issue. Looks like someone removed the the WAI tag I had added
<abentley> rick_h__: BTW, we also have assertIn and assertNotIn.
<rick_h__> abentley: ooh, thanks. Bookmarked the full list.
<lifeless> sinzui: I thought he did too
<lifeless> rick_h__: and assertThat(foo, Contains(bar))
<rick_h__> lifeless: cool, I saw some work with the containsHTML from the soup stuff, but I wasn't creating full tags
<sinzui> lifeless, I ws thinking of bug 883258
<_mup_> Bug #883258: Bug descriptions/comments much harder to read on Launchpad than other hosting services <css> <trivial> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/883258 >
<lifeless> sinzui: thanks, do you think this is a dupe, or that the loggerhead thing is different ?
<lifeless> sinzui: if its a dupe, I will add a loggerhead task to 883258
<sinzui> lifeless, No. I think is a separate bug. It is both a css issue and a WAI comparability issue.
<sinzui> compatibility
<lifeless> WAI ?
<sinzui> lifeless, sorry, I was in another conversation: WAI was established in 1997 to tell web authors to stop messing with users: http://www.w3.org/TR/WCAG/
<lifeless> sinzui: I've gardened the bug a little; if you wanted to add analysis to it that would be the bomb
<sinzui> lifeless,  I tagged a few things WAI last year when Canonical said it was taking accessibility seriously
<jcsackett> sinzui: i'll be a little late to standup; vet just called.
<sinzui> okay
<wgrant> lifeless: 300?
<wgrant> cjwatson: Yes, all of gina is in the tree. Have you grepped scripts/?
<deryck> Later on, all.
* abentley changed the topic of #launchpad-dev to:  https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 3*10^2
<cjwatson> wgrant: Yeah, when I found scripts/gina.py I said "Never mind, I'm talking nonsense" :-)
<lifeless> flacoste: ping
<lifeless> wgrant: '6 months worth of bugs'
<lifeless> wgrant: our rate was 200 commits/month with all squads; *6/4
<wgrant> lifeless: Ah!
<wgrant> lifeless: !!
<wgrant> YAY
<wgrant> kill, crush, destroy
<lifeless> heh, happy new years
<StevenK> Hm?
<lifeless> I just proposed disabling heat aging and max-heat tracking on bug contexts
<lifeless> which means changing heat display to a number not a fraction
<wgrant> Which makes Launchpad fast :)
<lifeless> well, it will remove some causes of slowness
<wgrant> Lies.
<lifeless> hmm?
<wgrant> Destroying bug heat will solve all the world's problems :)
<lifeless> Optimism from you? I'm shocked!
#launchpad-dev 2012-01-05
<StevenK> rick_h__: Your displayname seems to be 'Rick harding'
<StevenK> In Buildbot, at least
<rick_h__> StevenK: hmm, ok. Looking around
<rick_h__> ah, there it is. Thanks StevenK
<jelmer> StevenK: curtis setting a trend perhaps?
<rick_h__> I promise to do better next psm submit
<StevenK> jelmer: That was firstname, not surname. But perhaps.
<rick_h__> pqm...ugh
<StevenK> Haha
<StevenK> wgrant: So the rejection is caused due to the validator on SPR.{creator,maintainer} -- Perhaps we should reject just before we create the SPR?
<wgrant> StevenK: Right.
<StevenK> wgrant: NascentUpload doesn't create the SPR?
<wgrant> It uses createUploadedSourcePackageRelease
<StevenK> Indirectly, it looks like.
<wgrant> Should be direct
<wgrant> in dscfile, probably.
<StevenK> Right
<StevenK> wgrant: You'd prefer dscfile.storeInDatabase() or IDistroSeries.createUploadedSourcePackageRelease() do the rejection?
<wgrant> StevenK: Depends where the error handling tends to be now.
<wgrant> It may want to be even before storeInDatabase.
<wgrant> Where it's mapping the address to a person, perhaps.
<StevenK> That's parseAddress
<StevenK> Right, we grab them there. I can swoop in and do the private bit
<lifeless> bah, hate it when I can't find a bug
<StevenK> Bleh. How hard can it be to create a private team with a contact address? :-(
<wgrant> StevenK: factory.makeTeam(email="foo@bar.com", visibility=PersonVisibility.PRIVATE)?
<StevenK> wgrant: Unauthorized: (<Person at 0xe3ea090 team-name-100003 (Team Name 100003)>, 'setContactAddress', 'launchpad.View')
<wgrant> StevenK: with celebrity_logged_in('admin')
<wgrant> Or fix the factory.
<lifeless> meep
<lifeless> hth is https://bugs.launchpad.net/launchpad/+bug/1293
<_mup_> Bug #1293: Customizing body attributes seems like a very secretive, if not almost impossible thing to do <lp-foundations> <Launchpad itself:Invalid> < https://launchpad.net/bugs/1293 >
<lifeless> on the first page of 'by most recent change' bugs in LP
<lifeless> (with dups shown and all statuses)
<lifeless> brain melting
<lifeless> 1112 to go
<StevenK> wgrant: I'm having a brainfade - does IPerson.inTeam(ITeam) work?
<StevenK> Seems to
<wgrant> StevenK: That's the point of it, so yes :)
<lifeless> StevenK: "
<lifeless> Forbid private teams to be private teams."
<StevenK> Bah
<lifeless> also
<lifeless> this leaks the teams, do we care?
<lifeless> or is changed-by gpg authenticated ?
<StevenK> lifeless: sinzui and I feel it is safe enough. And we aren't expecting this codepath to be hit often at all
<lifeless> using the uploader would be authenticated
<lifeless> rather than the changer
<lifeless> or am I confused about which field is which
<StevenK> lifeless: I can switch to SignableTagFile.signer if you wish
<StevenK> That may leak the team, if the changed-by isn't a member of the team and the uploader is
<lifeless> so, there are two aspects here I think.
<lifeless> who do we tell
<lifeless> what do we tell them
<wgrant> Is that inTeam bit a useful distinction?
<lifeless> if we tell unauthenticated people, then we shouldn't tell them anything
<StevenK> Reject silently?
<wgrant> If someone wants to know that it was a private team, they can just grep for 'Invalid Maintainer'
<lifeless> if we only tell authenticated people then we can tell them more
<lifeless> Well
<lifeless> I think we should accept it but not link to the person object; but thats clearly different.
<wgrant> And clearly breaks everything.
<wgrant> Maintainer and Changed-By are mandatory.
<lifeless> (It is however the logical consequence of allowing user supplied data to be injected into a partially-private system)
<StevenK> lifeless: We can't.
<wgrant> And not linking to the person object still reveals the private team's existence.
<lifeless> arguably yes
<lifeless> though linking and then folk dropping that address from their account is win too
<wgrant> Sure, something like BranchRevision is probably better.
<lifeless> so whats the reason we don't accept this? I mean, why is rejecting it the approach decided on?
<wgrant> Er
<wgrant> RevisionAuthor
<StevenK> lifeless: Because we already do reject, just the message is bong.
<lifeless> ah.
<wgrant> And what else can we do?
<lifeless> so, uhm. I'd be cautious here.
<lifeless> wgrant: we could accept; permit limitedview to the relevant context, tell the user they did this thing and they should delete the package to hide it
<wgrant> lifeless: No.
<lifeless> we do have private archives after all
<wgrant> We can't do stuff like that.
<StevenK> lifeless: And then if the publication is copied to a public archive?
<wgrant> It's the antithesis of the disclosure project.
<lifeless> StevenK: prompt them before permitting it
<lifeless> wgrant: I don't follow
<wgrant> lifeless: We are going to have 100 different unauditable paths to private team visibility.
<StevenK> lifeless: Which the copy architecture doesn't permit either
<wgrant> lifeless: When disclosure is about making visibility less opaque.
<wgrant> And more auditable.
<StevenK> BAAAAH
<lifeless> wgrant: that is something we *can* provide; disclosure is certainly about making it understandable and controllable. Social teams are about making private teams more useful.
<lifeless> so, right here, right now, I would just say invalid maintainer
<wgrant> lifeless: And your proposed social private team design is not understandable or controllable.
<lifeless> make folk that want to probe for private teams work a little
<StevenK> test_sigint_exits_nicely (bzrlib.plugins.lpserve.test_lpserve.TestLPServiceInSubprocess) just failed on buildbot.
<lifeless> wgrant: its certainly controllable, as proposed.
<lifeless> wgrant: and it seems to be quite understandable to everyone I've explained it to.
<wgrant> "Who can see Canonical Supersecret Team: anyone who can see these 1000 bugs, 200 blueprints, 3 projects, 2 milestones, 4 packages, 2 teams, 3 sprints, 1 translationgroup, 10 branches, 9 code review comments, 4 code review votes, 10 bug subscriptions."
<wgrant> Very understandable :)
<lifeless> thats like saying 'who can use LP: anyone that can process http, https and handle a number of forms of crypto, has a working RFC2870...
<lifeless> its bollox to cast it that way, when we have software to deal with abstractions
<wgrant> That can't be significantly abstracted.
<wgrant> Apart from collapsing code review comments and votes into merge proposals.
<lifeless> We will be face to face soon
<lifeless> we can drill into it as much as you want
<lifeless> 'interacts with' seems to be pretty understandable, in my unscientific poll
<lifeless> I *think* you are thinking implementation
<lifeless> which is totally different (but still important)
<wgrant> Hmm?
<wgrant> I manage a team.
<wgrant> Someone has discovered its existence :(
<wgrant> I don't know how.
<lifeless> that was code for 'not now'
<wgrant> I look at the disclosure page.
<wgrant> I see 2000 artifacts that might have leaked it.
<wgrant> I can't see a list of people :(
<wgrant> I am screwed.
<lifeless> IMPLEMENTATION
<wgrant> I disagree, but next week :)
<lifeless> wgrant: if its just been disclosed, the page should show precisely one thing: the disclosing thing (because public disclosure has to list every user ever otherwise)
<lifeless> feel free to help me zerg 75% of the high bugs
<wgrant> disclosed != puiblicly disclosed
<StevenK> lifeless: So I should just raise UploadError('Invalid Maintainer.') ?
<lifeless> so, you're talking teams, disclosure is focused on projects.
<lifeless> StevenK: it avoids any complication about disclosure
<wgrant> lifeless: Sure, but making private teams infinitely worse than they are now is not a good goal to have.
<lifeless> StevenK: I *hate* 'this is wrong but we won't hit it much' cases: they always, eventually, bit.
<lifeless> *bite*
<lifeless> wgrant: if that was the goal, I would agree.
<lifeless> wgrant: you are being very over the top though, which isn't all that nice
<wgrant> I'm not being hugely hyperbolic :)
<lifeless> enough to impede any discussion
<StevenK> wgrant: You forced buildbot again?
<wgrant> I did.
<StevenK> lifeless: diff updated
<lifeless> yay timeouts
<lifeless> how is that even possible
<lifeless> Time: 29.29 secondsID: 2, status: 200 (Ok)
<wgrant> Where?
<lifeless> wgrant: win!https://bugs.launchpad.net/launchpad/+bug/620989
<_mup_> Bug #620989: Package sets can include sets in other series <lp-soyuz> <packagesets> <Launchpad itself:Triaged> < https://launchpad.net/bugs/620989 >
<wgrant> Yeah
<lifeless> didn't we have a policy about tech-debt importance ?
<wgrant> I don't recall.
<lifeless> nigelb: https://bugs.launchpad.net/launchpad/+bug/5283
<_mup_> Bug #5283: "Home page" vs. "Description" is misleading <bad-commit-11051> <easy> <lp-registry> <qa-ok> <tech-debt> <ui> <Launchpad itself:In Progress by nigelbabu> < https://launchpad.net/bugs/5283 >
<lifeless> wow, logintoken is crufty
<lifeless> ahhhha
<lifeless> look at the 'may be notified' portlet on https://bugs.launchpad.net/launchpad/+bug/352000
<_mup_> Bug #352000: javascript errors are hard to read, not informative, and often ugly <Launchpad itself:Triaged> < https://launchpad.net/bugs/352000 >
<wgrant> lifeless: What about it?
<wgrant> It's backwards, but that's been the case for months.
<lifeless> Find the names begininning with A
<lifeless> well, I notice had not
<lifeless> is there a bug ?
<wgrant> Don't thinkso.
<wgrant> It happened in the post-release complete redesign of the subscription UI.
<lifeless> bah, the mine regression bug isn't in the lpbugtags page
<lifeless> tag isn't in..
 * lifeless uses regression
<lifeless> bug 912137
<_mup_> Bug #912137: subscribers portlet sorted in reverse order <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/912137 >
<wgrant> Hm
<wgrant> Bug #911752 is possible relevant
<_mup_> Bug #911752: Bug.getIndirectSubscribers() does not sort using person_sort_key <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/911752 >
<wgrant> possibly
<lifeless> certainly, that will sort it more correctly... in reverse order
<lifeless> sinzui: I think you fixed https://bugs.launchpad.net/launchpad/+bug/153343
<_mup_> Bug #153343: Split out email interface tests <email> <lp-bugs> <tech-debt> <test-system> <Launchpad itself:Triaged> < https://launchpad.net/bugs/153343 >
<lifeless> uhm
<lifeless> where has 'open team' gone ? https://launchpad.net/~maas-developers/+edit
<lifeless> I bet I know, I bet 'subteams' includes 'this' and its a regression
<lifeless> nope, not that simple
<stub> lifeless: Has it been assigned to anything that would block it from being open?
<lifeless> it has a list
<lifeless> but lists are allowed to be open
<lifeless> its not private
<lifeless> its not a member of anything AFAIK
<lifeless> https://launchpad.net/~maas-developers/+participation
<StevenK> lifeless: ITeam.    def checkOpenSubscriptionPolicyAllowed(self, policy='open'):
<StevenK> Bah
<StevenK> lifeless: If it's a pillar owner, security contact, has a PPA, closed super teams or is subscribed to or assigned private bugs
<lifeless> no, no, no, no, shouldn't be yet, shouldn't be yet.
<StevenK> Apparently, the code disagrees.
<lifeless> it fails to say so
<lifeless> it just hides the buttons rather than explaining they are hidden or something
<lifeless> StevenK: you are an owner of maas-developers, give it a go
<lifeless> no bugs in 'all related bugs'
<StevenK> lifeless: Er, it owns maas?
<lifeless> ah
<lifeless> well it shouldn't, its the damn list
<StevenK> https://launchpad.net/maas << meet the pillar
<lifeless> thanks
<lifeless> so
<lifeless> uhm
<wgrant> Is MaaS developers really the list?
<StevenK> However, please file a bug, tagged disclosure. The page should state why Open and Delegated (in this example) are hidden.
<wgrant> Or is it confused?
<StevenK> The maintainer is the team
<wgrant> Yes.
<wgrant> But that doesn't say anything about the intent of the team.
<wgrant> Apart from that it may be confused.
<StevenK> sinzui went through this. Open teams that own projects can allow people to join and subvert the team
<StevenK> Er, subvert the project
<wgrant> I'm not arguing about the LP rules.
<wgrant> I'm arguing that whoever created the team might not know what the team is meant for.
<lifeless> julian made the list :P
<lifeless> yes, its the list.
<wgrant> Since it seems to be pretending to both be a privilege team and a list team.
<StevenK> Oh, right.
<lifeless> I think he forgot to separate.
<wgrant> Which is wrong.
<lifeless> so I've proposed to the cabal in question that we do, ditching the current list and shuffling, to follow the normal naming idioms
<lifeless> StevenK: thanks very much for spotting that. Care to file a bug that its a PITA to spot ?
<StevenK> lifeless: I asked you to three minutes ago. :-P
<wgrant> Open teams are, in general, a Bad Ideaâ¢
<lifeless> StevenK: yes, I'm currnetly review 1K high bugs
<stub> https://bugs.launchpad.net/launchpad/+bug/905044 has a script that needs to be brought in-tree, but the license is incompatible. I should just stick a new license at the top since we wrote it?
<_mup_> Bug #905044: Some script server scripts are not using pgbouncer for DB connections <canonical-losa-lp> <Launchpad itself:Triaged> < https://launchpad.net/bugs/905044 >
<lifeless> stub: yes
<lifeless> StevenK: so my brain is pudding; I'd really appreciate you recording the issue
<nigelb> lifeless: I was stuck on that because of garbo job.
<nigelb> I intend to find some time to clear up bugs I've assigned to myself.
<StevenK> lifeless: bug 912159
<_mup_> Bug #912159: ITeam:+edit does not explain why some subscription policies are hidden <disclosure> <Launchpad itself:Triaged> < https://launchpad.net/bugs/912159 >
<lifeless> thanks
<StevenK> If you wish to subscribe/do whatever
<StevenK> nigelb: 329!!
<lifeless> oh, I am. To /launchpad-project
<lifeless> nigelb: did you need advice or ?
<nigelb> lifeless: 329?
<nigelb> lifeless: I do. On work week + vacation now, will ping when I'm back.
<lifeless> kk
<StevenK> nigelb: You haven't seen the cricket?
<nigelb> StevenK: Nope. 'm on vacation, on a beach. I thought you don't watch cricket?
<StevenK> I like it when Australia are winning :-P
<StevenK> And Clarke hit 329 not out today
<nigelb> ha, so you only troll when australia is winning? :D
<StevenK> Pretty much, yes.
<nigelb> OMGWTBBQ 329!
<nigelb> *and* a 150 from Hussey.
<nigelb> Shame.
<adeuring> good morning
<lifeless> stub: catchup ?
<stub> lifeless: sure
<mrevell> Morning
<nigelb> Hey mrevell
<jtv> Mommy, where do NascentUploads come from?
<wgrant> jtv: process-upload.py
<jtv> wgrant: I suppose it's okay to construct them directly in tests?
<wgrant> jtv: It's reasonable.
<wgrant> Check the existing tests to see what is reasonably distasteful, I suppose :/
<wgrant> None of them are pretty.
<jtv> Thanks.
<bigjools> jtv: what are you needing to test?
<jtv> bigjools: the scenario where we sync a debian source package into ubuntu, and then the resulting binary build in ubuntu fails.
<bigjools> I hate these tests, but ...
<jtv> But?
<bigjools> lib/lp/soyuz/doc/distroseriesqueue-notify.txt
<bigjools> you are checking emails IIRC?
<jtv> Yes.
<bigjools> jtv: you might not need to create a NascentUpload, that's all
<jtv> I figure it's probably simpler than reverse-engineering a suitable path through process-upload.
<bigjools> NU is quite heavyweight
<bigjools> the uploader is so badly written that it's very hard to write short unit tests
<lifeless> flacoste is going to crucify me :)
<jtv> wgrant: any idea why do_reject might be giving me a ForbiddenAttribute on (createQueueEntry, PackagePublishingPocket.RELEASE)?
<wgrant> jtv: w... what?
<wgrant> lifeless: Oh?
<jtv> wgrant: I guess that's a pocket sneaking into the spot that's reserved for a permission?
<lifeless> wgrant: I just found 3? 4? hidden criticals
<wgrant> That looks more like you're trying to call pocket.createQueueEntry, I think
<lifeless> oopses triaged high
<wgrant> lifeless: Ah, yeah
<jtv> wgrant: it's distroseries.createQueueEntry, in do_reject.
<wgrant> jtv: You've probably got the distroseries and pocket args around the wrong way
<jtv> Oooh that might be worth checking, thanks
<bigjools> jtv: sounds also like you are testing in the wrong layer
<jtv> I'm using LaunchpadZopelessLayer; open to suggestions.
<wgrant> That's fine. It's ForbiddenAttribute, not Unauthorized.
<wgrant> (you get Unauthorized in Functional vs Zopeless cases)
<jtv> Found it.  Silly typo.
<wgrant> Phew.
<jtv> Don't worry _too_ much â I'm trying to write a test here, not trying to upload a security fix to Ubuntu.  :)
<cjwatson> Do garbo jobs need to land anywhere special (db-devel?) or do they just land on devel?  Any special deployment runes related to them?
<lifeless> devel.
<lifeless> none.
<cjwatson> rah
<cjwatson> Now all I need is to have some clue how to set chunk sizes
<lifeless> you don't
<cjwatson> maximum_chunk_size at least
<lifeless> shouldn't need to touch that at all, it will start at one and scale until the transactions are a good length.
<stub> Unless the operations are really variable, which can break the tuning :)
<cjwatson> Oh.  All the existing garbo jobs set it though
<lifeless> should really clean that up
<cjwatson> And the docs say "    maximum_chunk_size = None  # Override.
<cjwatson> "
<cjwatson> well, insofar as that's doc
<lifeless> yeah, should cleanup
<lifeless> set it to 1000 or something
<cjwatson> OK
<lifeless> stub: a smoothed average should accomodate pretty noisy durations
<cjwatson> Anything else I need to pre-imp chat about wrt bug 911943?
<_mup_> Bug #911943: gina imports SourcePackageRelease.dsc_binaries incorrectly <Launchpad itself:Triaged> < https://launchpad.net/bugs/911943 >
<lifeless> stub: quadratic mean I mean, I think.
<cjwatson> The bug itself is trivial, it's the cleanup ...
<stub> Its a safety net. If you are trashing stuff from a single table, I'd jump straight to 10000 unless the delete cascades...
<cjwatson> I'm actually doing updates in this case
<stub> lifeless: I'm not sure what jtv's algorithm counts as
<stub> cjwatson: Something lowish then - 1000 should be fine.
<cjwatson> I need to change everything that says "foo bar baz" to "foo, bar, baz" - should I be using postgres regexp_replace, or doing it in Python?
<lifeless> whatever your heart desires
<stub> cjwatson: PostgreSQL's will be optimal as you just issue an UPDATE statement rather than a SELECT followed by an UPDATE
<cjwatson> okie
<lifeless> won't really matter though
<stub> But PG's regexps are special... check the docs
<lifeless> because a select + update would not start taking locks until the updates started flowing
<lifeless> 6/1 1/2 dozen
<cjwatson> "Binary: libmpdclient-dev (>= 2.0.0~git20090929.fc3bae2-0ubuntu1~ripps2~hardy), libmpdclient2"
<cjwatson> *headdesk*
<lifeless> cjwatson: is https://bugs.launchpad.net/launchpad/+bug/669404 still high ?
<_mup_> Bug #669404: support linux-any and similar expansions in Packages-arch-specific <lp-soyuz> <soyuz-build> <soyuz-core> <Launchpad itself:Triaged> < https://launchpad.net/bugs/669404 >
<lifeless> cjwatson: if it hasn't triggered in two cycles...
<cjwatson> lifeless: Probably not; P-a-s has generally been being cut down
<cjwatson> lifeless: I could just fix it and make it moot, I suppose :)
<lifeless> cjwatson: you could; I'm going to triage it down to low anyhow.
 * cjwatson nods
<jtv> bigjools, cjwatson: question about the bug I'm looking at.  If we sync a package from debian into ubuntu, triggering a build, and the build failsâ¦ who should get notified at all?  Definitely not the Debian maintainer, who I gather is also probably also the signer and the author of the last change.  Anyone else?
<jtv> bigjools: and by the way, my test is here: http://bazaar.launchpad.net/~jtv/launchpad/bug-876594/revision/14636
<wgrant> It should only be the person who requested the sync.
<wgrant> I can't see it making sense to email anybody else related to the package.
<jtv> The person who requested the sync is not currently notified AFAICS.
<wgrant> Correct.
<wgrant> Until recently they were not stored anywhere.
<wgrant> And even now they're barely stored.
<wgrant> At present there is probably nobody that you can sensible notify.
<wgrant> sensibly
<jtv> Don't tell me I have to look up the job.
<wgrant> You can potentially look at SPPH.creator, except when you can't.
<jtv> It's not that I mind not notifying anyone per se, it's just that it gets hard to ensure a durably meaningful test if I can only verify that somebody does not get notified.  It'd be much more robust if I could show "X gets notified but Y does not."
<jtv> When can't I look at SPPH.creator?
<jtv> Oh argh, and who's to say I can find the SPPH?
 * jtv rummages
<wgrant> Right, there's not always an SPPH :)
<wgrant> But there should be at least one normally.
<jtv> The unwanted recipient is injected in Upload.notify, and I don't think that has a corresponding SPPH handy.
<wgrant> Certainly not at present, no.
<wgrant> Often because there's no publication to notify about.
<wgrant> eg. if the upload is NEW
<wgrant> or UNAPPROVED
<jtv> Actually that may just undermine our whole solution to this bug.
<jtv> We need the SPR's archive, and the archive that the build was to go into, and compare the two.
<jtv> Can we get those?
<jtv> There's an Upload.archive, and an Archive.sourcepackagerelease.archive.
<wgrant> I'm not sure that's the right thing to do.
<jtv> I take it the two would indeed differ if the upload was for the binary build of a copied SPR?
<wgrant> For example, say I am a clueless user and upload a Debian package verbatim to my PPA.
<wgrant> It will have the Debian maintainer in Changed-By.
<wgrant> This is currently worked around by suppressing Changed-By notifications for PPAs.
<wgrant> But that's pretty terrible.
<jtv> In this particular problem domain, I would argue that with an error margin of Â±3 or so, you are the only non-clueless user.
<wgrant> Hah.
<jtv> I can see how the case you present here is related, but I don't see how the proposed change would affect it.
<jtv> If you upload a Debian package to your PPA, don't you get your own SPR?
<wgrant> You get your own SPR, yes.
<wgrant> And the archive of the SPR and build will match.
<jtv> But the current PPA rule will apply.
<wgrant> Should it?
<jtv> Without that, I think, the maintainer would only be emailed if the upload were unsigned.
<wgrant> It's from back in the days when Ubuntu was the only other thing that existed.
<wgrant> The idea probably has merit for everything.
<jtv> Certainly sounds like it.  I tried to word it that way: uploads the maintainer is not responsible for.
<jtv> In what situation might there be no signer?
<jtv> Ahhh no, there's a bit of nastiness.
<wgrant> assuming that "signer" includes "sync requester"... probably just autosyncs
<wgrant> I would suggest just ignoring Changed-By and only ever using the signer.
<jtv> Why would the signer include the sync requester?
<wgrant> But that doesn't work for sponsored uploads.
* allenap changed the topic of #launchpad-dev to:  https://dev.launchpad.net/ | On call reviewer: allenap | Firefighting: - | Critical bugtasks: 3*10^2
<wgrant> Signer and sync requester serve the same role.
<wgrant> They are the person to blame for putting the package in its current location.
<jtv> The signer isn't the person who signed the last change?
<bigjools> jtv: if there's a job creator or signer, notify them (in that order). If neither, don't notify (although I can't think why we'd have neither).
<bigjools> signer is the uploader
<bigjools> changed-by is the person who signed the dsc, generally
<wgrant> Except in the case of sponsorship
<wgrant> Which is not uncommon
<bigjools> right
<bigjools> well, sponsorship is the uploader being different from the changed-by
<Laney> I thought sync sponsors weren't expressed in the SPPH yet
<jtv> We don't even necessarily have the SPPH in this case, apparently.
<Laney> you can have a build failure without a SPPH?
<jtv> If I understand wgrant correctly.
<wgrant> It's unlikely but possible to not have a current source publication.
<wgrant> And there may be multiple current source publications.
<jtv> What about SPR?
<wgrant> There's always an SPR.
<wgrant> But that's not useful.
<bigjools> if the build finishes before the SPPH is created
<bigjools> best place to look is the job
<wgrant> The build isn't created until after the SPPH.
<wgrant> But the SPPH can go away.
<bigjools> yeah I meant PUBLISHED, thinko
<bigjools> why can it go away?
<wgrant> If the package is superseded or deleted.
<wgrant> Although currently in that case we just crash.
<jtv> #$%@ why do they have a guard in front of the building to tell me that my bike was still there around 6:30 and probably not around 7:30?
<wgrant> When trying to accept the build.
<jtv> Well this is for the rejection case anyway.
<jtv> Also, this being a binary build triggered by a source sync, will I be able to find a job?
<bigjools> it doesn't go away, it changes state
<jtv> Will I be able to find an exact match?
<jtv> Also, will I upset anyone if I redirect the notification stream at different users?
<bigjools> I doubt it
<bigjools> assuming you're talking about build failures
<bigjools> I can't imagine why you can't get hold of the SPPH for the build and grab .creator
<bigjools> if that's None then you need to find the signer on the source upload
<StevenK> Bah, buildbot failed again.
<jtv> It doesn't look like this code knows for sure that it's dealing with a build failure, actually.
<StevenK> jtv: notify()?
<jtv> Althoughâ¦ it's "action" must come from somewhere, right?
<jtv> self.status
<jtv> So we do know whether it's a failure.
<jtv> How would I find the SPPH?
<bigjools> jtv: look it up given the context on the build (archive, distroseries, source package, version)
<jtv> And then take the latest of the matches, I guess.
<bigjools> getPublishedSources()
<jtv> This sounds like a change that we'd want to make for all statuses, not just failures.  Is that right?
<cjwatson> jtv: I agree with wgrant; it should only be the person who requested the sync.  There's a bug about them not being notified.
<jtv> Not the signer?
<cjwatson> The signer's the Debian maintainer, right?  Not them.
<jtv> That's what I thought, but now I'm not sure.
<cjwatson> Imagine you're a Debian maintainer; you do not want to be notified about build failures of your package in each of the 17000 Debian derivatives.
<jtv> That's the bug I'm trying to solve now.  But what I was referring to was the part where the signer was supposed to be the Debian maintainer.
<cjwatson> Well, we don't re-sign syncs
<bigjools> no, the signer is not the maintainer
<bigjools> in soyuz-speak
<bigjools> the signer is the uploader
<cjwatson> OK, but either way
<bigjools> we don't care who signs the dsc
<cjwatson> (yes, you're right, but)
<cjwatson> If I upload a package to Debian, I don't want to hear about build failures from derivatives, only from Debian.
<bigjools> jtv: and no, this should apply just to failures
<jtv> cjwatson: that's where we started.
<jtv> That's exactly what we're trying to solve here, which is difficult enough, but since we're in a hurry to stop the outflow of those messages we're bikeshedding a new notification regime into my last-minute branch.  :)
<jtv> Come to think of it, maybe we shouldn't do that.
<jtv> But there are two reasons for adding these notifications.  Hold on to your seat; this may scare you.
<jtv> One is that it protects my test from quietly becoming meaningless: "X is notified but Y is not" is less susceptible to that than "Y is not notified."
<jtv> The other is that the maintainer specifically gets added to the recipients list if no blamer (in this case, the signer) is given.
<bigjools> we don't need a new notification regime - build failure notifications are a separate code path to the upload ones
<jtv> Oh.  No, I got confused again.  The maintainer gets added if a blamer _is_ given.  Shoot me.
<jtv> Well this is Upload.notify calling notify, is it not?
<bigjools> it depends on whether it's an upload failure or a build failure
<jtv> Looks to my untrained eyes like the problem case could be either.
<bigjools> indeed - since we separated out uploading from the buildd-manager
<bigjools> which I suspect is the cause of this bug
<bigjools> so it might be worth checking the BFN code
<bigjools> and see how it compares to the failure-to-upload notification code
<jtv> BFN... build failure notification?
<bigjools> yes
<bigjools> soyuz has a lot ofg acronyms :)
<bigjools> https://dev.launchpad.net/Soyuz/Glossary
<bigjools> needs adding
<jtv> OFG, ironically, stands for Opportunity For Growth
<Laney> yeah, really /no/ mails should get sent to Debian about anything which happens in Ubuntu, and they should all be sent to the person responsible for the upload â failures to upload and so on too, not just build failures
<bigjools> source uploads are fine, it's just the build uploads
<bigjools> thankfully build upload failures are rarer
<jtv> Where is this BFN code you speak of?
<bigjools> one sec
<Laney> indeed, was just suggesting being more general if possible
<bigjools> jtv: lib/lp/soyuz/model/binarypackagebuild.py, see notify()
<bigjools> Laney: I would love it if that were easy in the existing code :)
<Laney> :-)
<jtv>         if package_was_not_copied and config.builddmaster.notify_owner:
<jtv>             if (self.archive.is_ppa and creator.inTeam(self.archive.owner)
<jtv>                 or
<jtv>                 not self.archive.is_ppa):
<cjwatson> I thought build upload failures were exactly what this bug got filed about
<cjwatson> It certainly came up on debian-devel and I had to do some rapid preemptive damage limitation
<bigjools> cjwatson: it is
<cjwatson> http://lists.debian.org/debian-devel/2011/10/msg00469.html
<bigjools> I am just pointing jtv at the BFN code because it works, and the uploader needs to do the same thing
<jtv> The condition I quited seems to be the only case where the BPB notify code cares about the details; apart from that, in non-PPA case, I think it just notifies the archive owner.
<jtv> s/quited/quoted/
<jtv> package_was_not_copied uses the same logic we proposed.
<jtv> But if the package was copied, and the archive is not a PPA, does anybody (apart from the archive owner) get notified at all?
<bigjools> jtv: bloody hell, it's email buildd_admins!
<bigjools> emailing*
<bigjools> WTAF
<jtv> On the bright side: only if the archive is not a PPA.  How often does that happen?  :)
<bigjools> ...
<bigjools> ok so ignore *that* code :)
<bigjools> but you know what to do now I hope
<jtv> Get drunk?
<bigjools> \o/
<jtv> Seriously, no, if it's not that then I don't.
<bigjools> jtv: as I said above, look up the SPPH.  If there's no creator on it then look up the PackageUpload.signing_key user
<jtv> The latter is what's currently used.
<bigjools> if neither are present, don't email
<bigjools> hmmm
<bigjools> sorry
<bigjools> I can see where the confusion comes from then
<jtv> There is hope in what you say though:
<bigjools> wait - signing_key is right
<jtv> notify() is "clever" enough to ward off any attempt at change through parameter-passing.  If there's a case where we can just skip the call, we win.
<bigjools> it comes from the key used to sign the changes file
<bigjools> but with syncs, it won't be there
<jtv> Upload.signing_key.owner is currently the person notified.
<bigjools> yeah, I suspect it's the changed-by for syncs
<bigjools> anyway, just fix the sync case
<bigjools> and all will be well
<jtv> If there's no signing_key for binary uploads resulting from syncs, then we're probably facing notify() finding an alternate victim.
<jtv> That would be the changer.
<bigjools> correct
<jtv> However, if there _is_ a signing_key, it will target both the changer and the maintainer.
<bigjools> builds don't have signers at all
<bigjools> the signing key is only on the source upload, if it was uploaded not synced
<jtv> And of course notify() will pick on the changer either way.
<bigjools> I think that all you need to do is detect that this is a sync and use SPPH.creator
<bigjools> job done
<jtv> Won't there be a changer?
<bigjools> ignore everything else
<bigjools> SPPH.creator for syncs is what you need
<jtv> Okay, I'll shoot for that then.
 * jtv twiddles
<bigjools> so use IArchive.getPublishedSources()
<bigjools> unless some other code has easy access to the source's publication
<bigjools> not looked in there for ages
<Laney> bigjools: this reminds me, do you have or want a bug for exposing sync sponsors in the spph?
<bigjools> Laney: if there is not one already but I think you or someone already filed it
<Laney> I think I thought we were repurposing the old one for that
<bigjools> we don't usually do that
<Laney> yes, but I was under the impression it was part of the UI fixes
<Laney> no worries
<bigjools> my memory sucks, I can't remember :)
<bigjools> FTR it won't get looked at for a long time unless it gets escalated
<Laney> I have that impression of Launchpad bugs, yes :P
<bigjools> too many bugs, not enough devs :/
<Laney> there we go
<jtv> bigjools: when looking for the SPPH, do I also need to match on component?  Of if I get multiple matches, do I prefer one with a matching component?
<jtv> Grrr it would be nice if my mouse pointer came back at this point.
<cjwatson> Laney: ... or you could submit a branch to fix it - exposing new fields isn't too hard
<bigjools> jtv: build._getLatestPublication() does what you want
<Laney> cjwatson: That has crossed my mind :-)
<jtv> bigjools: can I pick any build from Upload.builds?
<bigjools> jtv: yes, they all come from the same source
<jtv> Are there always builds?
<bigjools> if you have a build upload, yes :)
<jtv> And if not... I guess I revert to the old behaviour anyway.
<cjwatson> Is there a trick for debugging failing garbo jobs?  Something is throwing an exception and I just get SilentLaunchpadScriptFailure
<bac> matsubara: the deployment report seems to be inaccurate
<bac> matsubara: i have a branch merged as r14634 that hasn't been tagged
<matsubara> bac, looking
<jtv> bigjools: how do I attach the build(s) to my NascentUpload?
<matsubara> bac, it seems to be correct. the last successful buildbot run was on r14626
<bac> matsubara: pebcak
<jtv> bigjools: nm, I found a way.  Not one I'm proud of, but...
<jtv> bigjools: running ec2 now, with fingers crossed.  I'm putting the branch up for review, and then I really have to leave.
<jtv> bigjools: Care to review?  https://code.launchpad.net/~jtv/launchpad/bug-876594/+merge/87624
<allenap> jam: Do you have some time to look at https://bugs.launchpad.net/launchpad/+bug/912287?
<_mup_> Bug #912287: test_sigint_exits_cleanly breaks <spurious-test-failure> <Launchpad itself:Triaged> < https://launchpad.net/bugs/912287 >
* jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: allenap, jcsackett | Firefighting: - | Critical bugtasks: 3*10^2
<cjwatson> I could use a review of https://code.launchpad.net/~cjwatson/launchpad/gina-dsc-binaries/+merge/87632 if an OCR feels up to it.
<cjwatson> Please think hard about the SQL since I'm a novice at that :-)
<allenap> cjwatson: I'll have a look.
<rick_h__> adeuring: ping, I'm back if you want to run through that bug sometime
<adeuring> rick_h__: ok, mumble?
<rick_h__> sure thing
<rvba> allenap: jcsackett Could one of you guys have a look at this MP please? https://code.launchpad.net/~rvb/launchpad/builders-timeout-903827-2/+merge/87620
<allenap> rvba: I'm doing another review at the mo, but I'll look when I'm done unless jcsackett gets to it first.
<rvba> Cool.
<jcsackett> irvba: i can take a look now.
<jcsackett> er, rvba. :-P
<rvba> jcsackett: thanks
<jcsackett> rvba: looks like a good improvement. r=me.
<rvba> ta jcsackett.
<adeuring> rick_h__:  #https://pastebin.canonical.com/57786/
<adeuring> rick_h__: class TestMaloneView in lib/lp/bugs/browser/tests/test_bugs,py
<rick_h__> adeuring: ah, thanks.
<adeuring> rick_h__: regarding the sort bug on the page we were talking about: I noticed that the JS code does not issue any HTTP request when a sort button is clicked.
<rick_h__> adeuring: ok cool, yea it might not be binding on that page since it's not loading the normal "bootstrap" code on that view
<adeuring> rick_h__: ah, first step for a fix already!
<deryck> rick_h__, review is done finally.  r=me, with some minor formatting changes and one question.
<rick_h__> deryck: saw that, thank you much. I'll update that
<deryck> rick_h__, np!
<rick_h__> adeuring: still around?
<adeuring> rick_h__: yes
<rick_h__> adeuring: I'm just not able to get a failing test and wondering if I'm just way off base.
<adeuring> rick_h__: my guess would be that you did not enable the feature flag.
<rick_h__> I did, I missed that at first
<rick_h__> and now I get a nice giant json dump in my view.render() when I debug
<adeuring> rick_h__: flags = {u"bugs.dynamic_bug_listings.enabled": u"true"}
<adeuring> with FeatureFixture(flags):
<adeuring> view = create_initialized_view(...)
<rick_h__> but what I can't make 100% sure is that my test view matches the url I'm testing for
<rick_h__> adeuring: right http://paste.mitechie.com/show/488/
<rick_h__> is what I'm working with to start a test out. The context and the view are the right kind of objects for the traceback (IMaloneApp, SimpleViewClass)
<rick_h__> what's the way to check the view for the url? using view.request.getURL() just get's me 127.0.0.1
<adeuring> rick_h__: looks good. I think it is not strictly necessary to check the URL, but you can do that with a call of canonical_url()
<rick_h__> adeuring: yea, I just wanted to sanity check that my html I'm getting is in fact for the route /bugs/+bugs
<rick_h__> and not /bugs/something_not_failing
<adeuring> rick_h__: ah, you need to call view.render() inside the "with"
<rick_h__> oh? all the tests in test_bugtask didn't, and my render() result has the dynamic buglisting in it
<adeuring> rick_h__: well, try it here, I'd bet that the test will pass when you call view.render() without the feature fla setting
<adeuring> well, that view.render() will fail without the fix for MaloneAPp
<rick_h__> adeuring: yea, that threw the exception ok cool.
<adeuring> rick_h__: great. The difference to the other tests may be that you can call assertSomething() outside the !with", but you must call the tested changes within the "with"
 * adeuring has to run to an evening meeting
<rick_h__> adeuring: ok, I gotcha. THanks
<lifeless> and good morning
<rick_h__> party lifeless
<lifeless> gary_poster: hey; you have some high, assigned and probably stale bugs. Can you confirm they are stale, or whatnot? https://bugs.launchpad.net/launchpad/+bug/578854 https://bugs.launchpad.net/launchpad/+bug/588401 so far
<_mup_> Bug #578854: Confusing docs: doc/buildout.txt <lp-foundations> <Launchpad itself:Triaged by gary> < https://launchpad.net/bugs/578854 >
<lifeless> huh, we still have windmill tests in-tree
<lifeless> I wonder if they are being run
<gary_poster> lifeless, will look
<gary_poster> in a few hours :-)
<gary_poster> or maybe tomorrow
<lifeless> sure; they are high, I am doing the review of high bugs :)
<lifeless> flacoste: call?
<gary_poster> lifeless, flacoste, btw, I intend to do our call in 1 hour on Google hangouts.  I'll invite you
<gary_poster> then
<lifeless> cool... I'm robertcollins <> gmail.com, for google plus
<flacoste> gary_poster: fwiw, i wasn't able to get google hangout to work this morning with mrevell his invite never appeared for me
<lifeless> usually spelt with a . actually, but google does address collapsing
<flacoste> gary_poster: i'm francis.lacoste@canonical.com
<gary_poster> ack flacoste and lifeless, hopefully it will work
<rick_h__> abentley: ping, have a sec?
<abentley> rick_h__: sure;.
<rick_h__> abentley: so the JS code on the bugs.lp.net/bugs/+bugs is bombing because there's no content in the LP.cache which seems to get set as part of the LaunchpadView automatically
<flacoste> lifeless: skype me
<rick_h__> abentley: that context is used for the lp.client.load_model stuff to help generate the link and such
<rick_h__> abentley: so debating on if there's something I can do in the getCacheJSON to get a context or if this is something that should be hacked around in this particular view to fake the context enough for lp.client?
<rick_h__> sorry, /content/context
<rick_h__> abentley: ^
<abentley> rick_h__: Ah.
<abentley> So this is a top-level page that you're using to search all bugs in Launchpad?
<rick_h__> abentley: right
<abentley> rick_h__: I don't see it being a quick hack sort of thing.  I assumed our bug listings always had a context.  I'm not sure what violating that assumption does to it.
<rick_h__> abentley: yea, that's where I was heading
<rick_h__> abentley: I *think* the only bad side effect is that lp.client for getting the url of the ajax request
<rick_h__> abentley: but definitely not willing to bet on it
<abentley> rick_h__: So what's actually oopsing here?
<rick_h__> abentley: well the original oops was that BugsBugTask...View didn't implement macro_search_title
<rick_h__> abentley: I've updated that and now that the page doesn't oops, the JS fails to run on any ajax interaction
<rick_h__> abentley: so two different issues, oops is fixed, but the page overall still fails
<abentley> Okay.
<bac> hi jcsackett, could you look at https://code.launchpad.net/~bac/launchpad/904335-export-tags/+merge/87664
<abentley> rick_h__: I think it's valid for context to be null for Y.lp.client.load_model.  Does that give you enough?
<abentley> rick_h__: You'll have to update Y.lp.client.load_model to actually support that.
<abentley> rick_h__: The thing is, that page actually does have a context.
<abentley> rick_h__: It's just not one with a WS url.
<rick_h__> abentley: ok, I'll run with testing the context as null and see how far I get
<abentley> rick_h__: So perhaps it's better to just change ListingNavigator.load_model to use a trimmed version of the current URL.
<rick_h__> abentley: yea, that's what I wasn't sure if there was a better fix to getCacheJSON itself or not
<rick_h__> abentley: ok, will check that out then
<abentley> rick_h__: I don't think getCacheJSON is the issue.  It doesn't provide the context, because there's no sane context to provide.  The page's actual context is something we don't provide in the web service, and probably shouldn't provide in the web service.
<rick_h__> abentley: ok, that's what I was hoping you'd verify.
<abentley> rick_h__: cool.
<deryck> abentley, rick_h__ -- I'm going to work on the open questions now, just so no one works over top of me.
<deryck> abentley, rick_h__ and FYI, since it might take a while. ;)
<rick_h__> deryck: understood, leave some breadcrumbs to get back out of there
<deryck> heh, seriously.
<gary_poster> flacoste, lifeless google hangout waiting for you
<flacoste> gary_poster: lifeless might be a little late, was grabbing food
<flacoste> gary_poster: where should I see your invite?
<flacoste> gary_poster: and are you using your canonical.com account?
<gary_poster> flacoste, was using gmail account.  I sent two invitations to you just in case
<flacoste> hmm
<gary_poster> flacoste search for me
<gary_poster> it will say I'm in a hangout
<gary_poster> click on it
<flacoste> gary_poster: is it the yellow hangout?%
<lifeless> I don't see an invite yet
<lifeless> ahha
<flacoste> lifeless: search for gary and join the yellow hangout
<lifeless> yeah plugin is installing
<flacoste> lifeless: if you have found the invite, please tell me where?
<lifeless> in the 'notifications' drop down from the black bar at the top of the screen
<rick_h__> abentley: working on looking at best tests to add but can you peek at this and see if it's too hacky? https://code.launchpad.net/~rharding/launchpad/oops_912178/+merge/87675
<rick_h__> abentley: doing that change *works* locally
<abentley> rick_h__: You shouldn't need to omit the +bugs if present.
<rick_h__> abentley: ok, but the code that builds the url has that as part of it, sec let me get it
<rick_h__> abentley: it's the "view_name" passed into load_model
<abentley> rick_h__: Right.  But the view name is only needed if you have a context.  Otherwise, it doesn't really make sense.
<rick_h__> abentley: which lp.client.get_view_url uses
<rick_h__> abentley: hmm, right, but I'm basically faking a context so that everything elses passes through. So I still use get_view_url to build the query params, the ++model++ and such
<abentley> rick_h__: Since we're using the URL to get this data some of the time, I recommend using the URL all of the time.
<abentley> rick_h__: and then you can strip all that out.
<rick_h__> abentley: are we the only consumers of lp.client.load_model?
<abentley> rick_h__: No, I believe there's one other call site.
<abentley> rick_h__: lib/lp/translations/javascript/sourcepackage_sharing_details.js
<rick_h__> abentley: ok, so if I change the load_model to use the url vs building it have to check it out over ther eas well
<abentley> rick_h__: Yes, or else you can make a new function that is a callee of load_model, and accepts a URL instead of context+view_name
<lifeless> gary_poster: oh hai?
<gary_poster> lifeless, yeah, trying to get back.  though maybe we should just say....
<gary_poster> thank you lifeless flacoste bac benji gmb frankban !
<gary_poster> bac, I'll be ready for our call as soon as I get back on
<lifeless> gary_poster: thank you
<lifeless> gary_poster: francis says next week, talk about success factors
<gary_poster> cool, sounds good
<abentley> lifeless or gary_poster: I have a question about eager loading BugAttachments.
<lifeless> gmb: You have a number of uhm assigned bugs, wondering if you could unassign or update them ?
<gmb> lifeless: sure thing. I'll do that before I sod off.
<lifeless> abentley: I'm about to go on a call, but if you ask, I will try to answer as time permits
 * gary_poster is going on a call too, and will know less
<abentley> lifeless: Okay.  In the current codebase, BugComment uses cached data from Message, but also has values from bugtask.bug.attachments_unpopulated inserted.  This eager loads the data.
<abentley> lifeless: I'd like to change BugComment so that it delegates to its Message.  I had thought that since bugtask.bug.attachments_unpopulated still runs, it would eager load the data into the Storm cache.
<abentley> lifeless: but in fact, there are extra queries.
<lifeless> what are the extra queries ?
<abentley> lifeless: http://pastebin.ubuntu.com/794224/
<abentley> lifeless: They are per-Message BugAttachment lookups.
<abentley> lifeless: Well, one is.  Another is a similar issue with message chunks.
<bac> thanks for the review jcsackett
<lifeless> abentley: ah, so IIRC bugcomment is an unusual class, its memory only; holds the calculated index
<lifeless> abentley: is that right? and now the index is persisted, it can do away
<lifeless> ?
<lifeless> mmm, possibly not the class I'm thinking of
<abentley> lifeless: The first part, that it's memory-only, is substantially true.
<lifeless> abentley: anyhow, you should have a backtrace of the thing triggering the extra query
<lifeless> last element of the timeline tuple
<abentley> lifeless: I'm pretty sure I know what's triggering the extra query.
<lifeless> abentley: ok; an attribute accesss?
<abentley> Message.bugattachments.
<lifeless> ok
<lifeless> so sqlmultiplejoins will always do queries
<lifeless> they are something we need to purge from the codebase, or at least stop using them
<lifeless> the workaround is to create a @cachedproperty property that can return the bugattachments, and inject the result into the messages from a decoratedresultset
<lifeless> you can replace the attributename - e.g.
<lifeless> _bugattachments = SQLMultipleJoin(...)
<lifeless> @cachedproperty
<lifeless> def bugattachments(...
<lifeless> or you can add a new one and expose in the interface etc etc
<lifeless> you'll then need to make sure the code path instantiating the objects still does the queries you want and so forth
<abentley> lifeless: So to make that work here, I think I'd need to inject the values into the cache in the code that uses bugtask.bug.attachments_unpopulated
<lifeless> sounds plausible yes
<abentley> lifeless: The cachedproperty definition would be something like "return list(self._bugattachments)" ?
<lifeless> abentley: extactly
<abentley> lifeless: How does this look? http://pastebin.ubuntu.com/794262/
<flacoste> gary_poster, lifeless: https://dev.launchpad.net/Projects/ParallelTesting
<gary_poster> thank you flacoste
<lifeless> abentley: looking
<lifeless> abentley: yes, thats the sort of thing
<abentley> lifeless: thanks.
* jcsackett_ changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 3*10^2
<wgrant> Hmm
<wgrant> I think bug #909318 may be bad
<wgrant> Half the sort options have gone missing on qastaging
<wgrant> Oh, nevermind.
<wgrant> Only the shown fields have sort buttons.
<wgrant> StevenK: Is your private maintainer QA imminent, or should we deploy now?
#launchpad-dev 2012-01-06
<StevenK> wgrant: Sorry, was breakfasting
<StevenK> wgrant: Gah, it's been so long since I've updated mawson. bzr pull in devel and then ../rocketfuel-get.sh ?
<wgrant> StevenK: ~/bin/upgrade-dogfood-launchpad or so
<wgrant> Does it all.
<StevenK> 2012-01-06 00:40:09 INFO    Upload was rejected:
<StevenK> 2012-01-06 00:40:09 INFO    	Invalid Maintainer.
<StevenK> wgrant: Shall I put up a NDT?
<jtv> wgrant, maybe you could have a look at this as well?  I feel entirely unqualified to assess or Q/A this, so the more eyes the merrier.  https://code.launchpad.net/~jtv/launchpad/bug-876594/+merge/87624
<wgrant> jtv: What does TestSyncNotification.makeUploader do that Archive.newComponentUploader doesn't?
<wgrant> jtv: I think signingkey should be preferred to SPPH.creator
<wgrant> But it probably doesn't matter too much.
<wgrant> It also looks like it's Changed-By that gets spammed, not Maintainer.
<jtv> Possibly.  And if so, it'll be a lot harder to hammer out of notify() without risking unforeseen consequences.
<wgrant> Hm?
<wgrant> This should suppress Changed-By, not Maintainer.
<wgrant> I don't see how this can suppress Maintainer.
<wgrant>     if blamer is None:
<wgrant>         debug(
<wgrant>             logger, "Changes file is unsigned; adding changer as recipient.")
<wgrant>         candidate_recipients.append(changer)
 * lifeless whispers statemachine
<jtv> Changing notify() terrifies me.
<wgrant> I'm not saying you need to.
<wgrant> I'm saying that the this isn't doing what your test says it does.
<wgrant> The problem may have been misinterpreted, and this will fix it anyway.
<jtv> I think I'll add a changer to the test.
<jtv> wgrant: my eye now falls on a detail that I had hitherto ignored â is_valid_uploader.
<wgrant> jtv: Right.
<wgrant> jtv: That projects the only Maintainer usage that I can see.
<jtv> My branch replaces the paragraph you just quoted with one that also adds the changer, but only if the changer is an uploader.
<wgrant> s/rpojects/protects/
<jtv> No match.
<jtv> :-P
<wgrant> Your branch doesn't seem to touch notifications.py
<jtv> That's right.
<jtv> Who would want to?
<StevenK> Thanks ever so.
<wgrant> The paragraph I quoted is from notifications.py
<wgrant> notification.py, sorry
<wgrant> So if your branch doesn't touch that file, it probably didn't replace the paragraph that I quoted.
<jtv> StevenK: Nothing personal.  For context, I've been saying I don't want to change it because I can't oversee the consequences.
<jtv> StevenK: If I change the logic in notifications.py, it may affect lots of other things.  That's why I don't think anybody would want to touch notifications.py to change just one particular behaviour.
<jtv> wgrant: I didn't mean that my branch replaces it textually; it replaces it dynamically by going through a different code path.
<jtv> wgrant: the bit you quoted is for the case where blamer is None, and it adds changer to the recipients list unconditionally.
<lifeless> hmm, notification looks roughly the right place to build up from to get a clean notification api
<wgrant> jtv: Right, that's what I meant.
<wgrant> jtv: It changes Changed-By from unconditional to conditional.
<jtv> By supplying a non-None blamer, I make it go through a different clause that also adds the changer â but only if the changer is an uploader.
<jtv> Right.
<wgrant> But doesn't change Maintainer unless they are an uploader.
<wgrant> Which in this case they aren't.
<wgrant> So it doesn't change the Maintainer case.
<jtv> Change Maintainer?
<jtv> You mean add?
<wgrant> So either the problem is misstated and your test is wrong, or your fix is wrong.
<wgrant> Right.
<jtv> The maintainer also gets added only if it's an uploader.
<wgrant> Right.
<jtv> But you're right that the test needs re-stating.
<wgrant> Which they're clearly not.
<wgrant> This change can only make it more likely that the maintainer is notified.
<wgrant> It makes it less likely that Changed-By is notified.
<jtv> Yes.  That sucks, but that's where we get into the internals of notification.py.  :(
<lifeless> I realise you don't want to upscope this - but is the basic model I proposed for a notification service useful (even in-app) for trying to make this easier to reason about ?
<wgrant> No.
<wgrant> The problem is not notifying people. It's working out from our terrible data model who to notify and when and how to avoid breaking things.
<wgrant> And rewriting the whole thing is not a good way to not break things :)
<lifeless> I didn't actually suggest that
<lifeless> but, breaking it into two problems - even conceptually:
<lifeless>  - who is involved [build the sets of involved folk, including how they are involved]
<wgrant> That's exactly the problem.
<lifeless>  - notify
<wgrant> That's how it is now.
<lifeless> but it sounds to me that you're examining conditional code that takes the event into account when determining who is involved
<wgrant> I'm not entirely sure how one can determine the involved people without knowing context...
<lifeless> perhaps I misunderstand the issue you're wending your way through
<lifeless> I have to wrap up some stuff, so I will get out of your hair :)
<lifeless> I may come back if you're still bloodying up the wall in a while
<jtv> lifeless: for the record, I started out by strengthening that separation, pulling the "identify recipients" into the call site.  It didn't help this case.
<lifeless> jtv: identify recipients is actually against my point, its not equivalent to identifying roles, if you get my drift (Again, terminology, I probably misunderstand)
<jtv> Potato, potato.
<jtv> wgrant: I suppose the immediate question is whether it's okay to notify changers who are uploaders.
<jtv> Sorry, no: maintainers who are uploaders.
<jtv> wgrant: I don't suppose it's likely to be too problematic for a maintainer or change author to be notified about builds in archives they are uploaders for?
<wgrant> jtv: I would argue that it's pointless. But it has precedent.
<wgrant> And it's not harmful.
<jtv> Looking on the bright side, it's something they're involved in and can do something about, right?
<wgrant> "harmful" for Soyuz is roughly defined as "pissing off Debian developers who aren't involved in Ubuntu"
<jtv> Or its derived distros.
<wgrant> That's not really an issue.
<wgrant> Distros derived from us are less likely to want to kill us.
<jtv> Not meant to annoy you; just wondering if there might be non-obvious scenarios where a Debian maintainer might be made an uploader through indirect membership, or to work around some completely unrelated problem.
<wgrant> It's unlikely.
<wgrant> Ideally we would entirely ignore Maintainer and Changed-By, just notifier signer/requester + sponsoree
<wgrant> But we don't have that modelled sufficiently at present.
<jtv> Clutching at the straws of negativity, any chance that we might generate unacceptable mail volume for someone out there?
<wgrant> Aren't we just returning to the previous behaviour here?
<wgrant> Mm, although Changed-By was changed.
<wgrant> Anyway, I suspect it's Good Enough for Nowâ¢
<jtv> I'm inclined to feel the same, for what little that's worth; but good to have this sanity chat.
<jtv> The Changed-By author is only affected in the direction of less chance of getting notified.
<wgrant> Yes
<jtv> wgrant: soâ¦ shall I just land it then?  I just added the changed-by author to the test (and they do not get notified).
<wgrant> jtv: I'd like to see the test failing with the rest of the code reverted, at least.
<jtv> My word that that's what happened before I wrote the fix is not good enough?  :)
<wgrant> The test was wrong before, so no :)
<jtv> Not wrong; it failed in exactly the expected ways.  It was just incomplete.  Okay, I'll run that.
<wgrant> Hmm, that's shouldn't have failed, though.
<wgrant> Maintainer shouldn't have been notified before.
<jtv> Hmm
<jtv> wgrant: is it because I made the maintainer sign the changes file?
<wgrant> jtv: That sounds bad.
<jtv> Yeah.  The maintainer is no longer notified (by the old code) when I change that.
<wgrant> Hm, does your test actually use a build at all?
<wgrant> If not, it's probably not using your code at all.
<jtv> But then how could it fail without my change and pass with my change?
<wgrant> An extremely good question.
<wgrant> Oh, you hide a build in makeNascentUpload
<wgrant> That makes more sense.
<wgrant> Anyway, I need to wander off for a while and prepare stuff for BUD.
<jtv> Thanks greatly for your help so far.
<wgrant> Thanks for trying to understand and fix this madness :/
<jtv> Understand?  Fix?  Julian told me what to do and we gradually discover how the change works around it.  :)
<lifeless> stub: yo
<lifeless> stub: could you rebuild the bug search indices? If they are bloated (what are the odds... :P)
<stub> k
<stub> And number one on the bloated index list is... bug_fti
<lifeless> I'm shocked.
<stub> Hmmm... wonder if I should try that new script to rebuild indexes live...
<stub> losas have a script from (isd or u1?) that should rebuild any index live
<stub> But not deployed on our boxes yet so I'll use my canned statements
<stub> Master is done
<stub> Sometimes wonder if this should be an automated, daily rebuild like data warehouse sites do. But they don't have to do it live...
<lifeless> heh, uhm, like rebooting windows servers daily.
<lifeless> I sure hope we can do better :)
<lifeless> statik was very keen to hear of your new-db-tech interest btw
<stub> Interesting stuff there is going to be U1 with the primary backend to U1DB
<stub> Stats are saying with current usage we need to rebuild bug_fti every two weeks
<wgrant> May change with bug heat changes, though.
<stub> Yes, but I can schedule myself to check that now :)
<lifeless> stub: are langpack exports in BAD_USERS or whatnot ?
<lifeless> stub: https://bugs.launchpad.net/launchpad/+bug/684664
<lifeless> wgrant: q for you on https://bugs.launchpad.net/launchpad/+bug/685076
<_mup_> Bug #685076: PPA deletion leaves unremoved publications <lp-soyuz> <soyuz-publish> <Launchpad itself:Triaged> < https://launchpad.net/bugs/685076 >
<stub> lifeless: yes, got landed yesterday in fact.
<lifeless> stub: I'm guessing there is a duplicate bug then ?
<stub> lifeless: its a different bug
<lifeless> stub: k
<mrevell> Hey
<lifeless> mrevell: hey, FWIW stub has reset the fti index
<lifeless> mrevell: so, that should help with fti searches
<mrevell> That's good to hear.
<stub> And scheduled a recurring check every two weeks
<lifeless> stub: FYI - work in progress only - bzr+ssh://bazaar.launchpad.net/~lifeless/launchpad/use-lazr-postgresql and bzr+ssh://bazaar.launchpad.net/~canonical-launchpad-branches/lazr-postgresql/trunk/
<adeuring> good morning
<stub> lifeless: I'll have a look next week probably. Ta.
<wgrant> lifeless: Probably very negligible.
<lifeless> anyone have an opinion on ?https://bugs.launchpad.net/launchpad/+bug/668381
<_mup_> Bug #668381: start_codebrowse invokes "make build" unnecessarily <canonical-losa-lp> <lp-code> <Launchpad itself:Triaged> < https://launchpad.net/bugs/668381 >
<wgrant> lifeless: Pretty sure we can just use compile.
<StevenK> allenap: How do you propose to QA r14641, given it has been rolled back three times?
<StevenK> allenap: If you say "Wait until next week and beg myself and wgrant" I may be forced to pack a cricket bat. :-P
<allenap> StevenK: Ha. Hahaha. HAhahahahahfahfahahah.
<wgrant> On the list of bad times to roll out an infamously explosive change, I would rank sprints where the whole team is in a single timezone fairly highly :)
<allenap> StevenK: If you're offering, that would be most kind, thank you.
<StevenK> allenap: Do I look insane? :-P
<allenap> StevenK: Do you really want me to answer that?
<bigjools> do you really need a reply to that?
<rvba> ?
<StevenK> Now I remember why I was happy moving from Red to Teal/Purple. :-P
<wgrant> StevenK: You were never truly Red!
<lifeless> gmb: oh hi; there was a bug - one you unassigned, where in the bug you said 'testing xyz needs to be done' -> I'm curious if you did said testing or not, to aid handoff
<lifeless> ok; haltingish. See you guys in buda
<wgrant> Night lifeless.
<StevenK> lifeless: Have safe flights.
<StevenK> wgrant: And note I said QA. I didn't say anything about deployment. :-)
<adeuring> https://dev.launchpad.net/ | On call reviewer: adeuring | Firefighting: - | Critical bugtasks: 3*10^2
<cjwatson> Bug 911943 - rollback or fix?  (garbo jobs that raise an exception don't actually break anything particularly, but ...)
<_mup_> Bug #911943: gina imports SourcePackageRelease.dsc_binaries incorrectly <qa-bad> <Launchpad itself:Fix Committed by cjwatson> < https://launchpad.net/bugs/911943 >
<cjwatson> If it needs to be rolled back, I'll need somebody to do that for me
<rick_h__> adeuring: can you look this over when you get a chance please? https://code.launchpad.net/~rharding/launchpad/oops_912178/+merge/87675
<adeuring> rick_h__:  sure
<rick_h__> adeuring: ty
<cjwatson> Oh, and can I push the fix to the same branch and remerge, or does it need to be a separate branch?
<wgrant> cjwatson: It's not overly critical, and the fix seems trivial, so might as well just fix it.
<wgrant> Same branch is OK if you want.
<cjwatson> Add "chunk_size = int(chunk_size + 0.5)", yes?
<cjwatson> And I'm going to *document this*
<wgrant> I suppose so :/
<cjwatson> Fixed.  Re-review/landing would be lovely.
 * cjwatson idly notes that there's already a garbo job that shoots itself in the face on dogfood: http://paste.ubuntu.com/794772/
<wgrant> Yeah, but that's just DF being itself :)
<cjwatson> Ah, unique to DF?  OK
<wgrant> cjwatson: Can you create a new MP quickly?
<wgrant> Yeah, that table has existed on prod for a yearish now.
<cjwatson> wgrant: https://code.launchpad.net/~cjwatson/launchpad/gina-dsc-binaries/+merge/87732
<wgrant> timeout ftw
<adeuring> rick_h__: the changes look good. But I think the JS code needs a test
<rick_h__> adeuring: ok
<wgrant> cjwatson: It breaks test_SourcePackageReleaseDscBinariesUpdater_updates_incorrect
<cjwatson> Really?  I ran that test here and didn't see it
<wgrant>   File "/home/wgrant/launchpad/lp-branches/gina-dsc-binaries/lib/lp/scripts/garbo.py", line 1084, in main
<wgrant>     raise SilentLaunchpadScriptFailure(self.failure_count)
<wgrant> SilentLaunchpadScriptFailure: 1
<cjwatson> make schema
<wgrant> Ah, you changed sampledata?
<cjwatson> there's a security.cfg change
<wgrant> Oh
<wgrant> Of course.
<cjwatson> (public.sourcepackagerelease += UPDATE)
<danilos> flacoste, hi, do you happen to have a minute?
* adeuring changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: adeuring | Firefighting: - | Critical bugtasks: 3*10^2
* bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: adeuring, bac | Firefighting: - | Critical bugtasks: 3*10^2
<rick_h__> adeuring: ping, updated with test if you get another look please https://code.launchpad.net/~rharding/launchpad/oops_912178/+merge/87675
<adeuring> rick_h__: cool
<adeuring> rick_h__: r=me thanks for adding the test and the additional changes!
<rick_h__>  adeuring yep, thanks for pushing me on it. :)
<flacoste> hi danilos
<danilos> flacoste, heya, up for short skyping?
<flacoste> danilos: sure, i have another call in 15 mins
<danilos> flacoste, ack, that should be more than enough
 * deryck will be back online shortly, changing work locations
<sinzui> jcsackett, I think you are missing a test
<jcsackett> sinzui: you are correct. i'll add the proposed-membership test and switch to the set-based recommendation.
<jcsackett> thanks.
<sinzui> fab
<abentley> deryck: chat?
<deryck> abentley, 10-15 minutes and I'll be ready.  cool?
<abentley> deryck: sure.
<deryck> abentley, great, thanks!  I'll ping shortly.
<sinzui> bac, will you have time to review https://code.launchpad.net/~sinzui/launchpad/unassign-bugs-0/+merge/87785 today
<jcsackett> sinzui: got sidetracked for a bit with thunderdome prep, but changes have been pushed.
<sinzui> jcsackett, thanks
<sinzui> jcsackett, r=me
<bac> sinzui: i may in a bit
<gary_poster> bac, if you have time, this should be very straightforward (doc changes only): https://code.launchpad.net/~gary/launchpad/bug578854/+merge/87787
<gary_poster> (I see others are ahead of me in line :-) )
<sinzui> gary_poster, I will review your branch
<gary_poster> thank you sinzui!
<gary_poster> sinzui, if bac doesn't get to your branch in a bit, I can take yours.  Trying to wrap a few things up for now, and will take lunch sometime too
<bac> gary_poster, sinzui: i'll be available in a few minutes
<gary_poster> cool
<sinzui> gary_poster, r=me
<gary_poster> thanks sinzui
<bac> sinzui: looking at your branch now.  sorry about the delay.
<sinzui> thats okay
<sinzui> bac, I claimed your branch for review, but is the proposed merge right?
<bac> sinzui: no, it is not
<bac> sinzui:  i forgot to specify the pre-req branch.  let me redo it
<sinzui> oaky
<bac> sinzui: this one should be more better:  https://code.launchpad.net/~bac/launchpad/904335-milestone-edit/+merge/87796
<sinzui> thank you
 * bac afk for a bit
<sinzui> bac r=me with a suggestion
<bac> sinzui: thanks
<bac> sinzui: excellent suggestions, especially the second
<bac> b/c you're right, i always have to scratch my head over the other syntax
* bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: [] | Firefighting: - | Critical bugtasks: 3*10^2
<abentley> deryck: are you up for a review? https://code.launchpad.net/~abentley/launchpad/bugcomment-interface/+merge/87808
<deryck> abentley, I don't mind doing it, but just about to step out for day.  Can I do it through tonight/travel, or do you need it today?
<abentley> deryck: No rush.
<deryck> abentley, ok, cool.  I'll claim it then.
<abentley> deryck: thanks
<deryck> abentley, np!
<lifeless> bdmurray: small request for you; we find it works better for bugs for them to description the situation, not the desire
<lifeless> e.g. "cannot search on bugs 'left_closed_since' via the API"
<bdmurray> lifeless: okay
#launchpad-dev 2012-01-07
<Laney> lifeless: I think your retitling of #648611 narrows the scope a bit much (the comments suggest some extra granularity that is desirable)
<_mup_> Bug #648611: ubuntu-sru either have too much or too little permission as queue admins <lp-soyuz> <queue-page> <rls-mgr-o-tracking> <Launchpad itself:Triaged> < https://launchpad.net/bugs/648611 >
<Laney> perhaps something like "Ubuntu teams are not able to manage upload queues as they need to"
<lifeless> Laney: I think both would be ok; as a problem statement the goal is to frame the problem and aid duplicate finding
<lifeless> feel free to remind me next week; today is frenetic
<rick_h__> lifeless: when the MP is deployed with the bug you commented on get marked fix released as well since I marked it a dupe?
<rick_h__> lifeless: or should I link up the dupe bug to the MP as well?
<lifeless> rick_h__: dupes don't need to be marked fixed released etc
<rick_h__> lifeless: ok thanks
<lifeless> rick_h__: so its all good; thanks for marking it up
<lifeless> I was sure there was a bug :)_
<rick_h__> yep, np
<Laney> apparently I can't edit the LP dev wiki, but https://dev.launchpad.net/Running/LXC could do with an explicit note to enable update in #10
<Laney> -updates
<nigelb> wait, why can't you edit.
<Laney> dunno
<Laney> where should the link be?
<nigelb> you need to login first.
<Laney> yes
 * tumbleweed can't either
<tumbleweed> "You are not allowed to edit this page."
<nigelb> let me try to make a small change.
<nigelb> Laney: what change do you want added?
<nigelb> I can directly try doign that instead of spamming
<Laney> Enable multiverse and -updates
<nigelb> Is that in 1. ?
<nigelb> Laney: changed.
<Laney> n10
<Laney> ta
<nigelb> oh drat
<nigelb> in 10?
 * nigelb fixes
<nigelb> Fixed.
<Laney> Let's say I want to look at #861488 as it seems like it could be doable as a first fix... is there any way I can import some test data into my local instance to help me out? or how would you go about getting the data set up?
<_mup_> Bug #861488: Mention sync requester on package version page <api> <derivation> <Launchpad itself:Triaged> < https://launchpad.net/bugs/861488 >
<stub> Laney: I don't know if anyone has any suitable test data already created for working on that issue. Unfortunately all the people who might know won't be available this weekend.
<Laney> yeah, the weekend effect. Never mind, I'll poke around.
<stub> Laney: Easiest way of creating most test data is just using the webui. Not sure about packaging info though.
#launchpad-dev 2012-01-08
<nigelb> omg.
<nigelb> I just realized jelmer is the co-author of bitblee.
<nigelb> blah
<nigelb> bitlbee
<Laney> what table do I need to fiddle with to make launchpad.dev/builders not show a package as building? Seems marking the build as failed by editing buildfarmjob is not enough.
<wgrant> Laney: buildqueue
<Laney> wgrant: I should delete the row?
<StevenK> wgrant: I thought inlinehelp was the only thing that wanted Mochi in?
<Laney> or unset builder
<wgrant> StevenK: There's apparently a Translations thing too
<wgrant> Laney: Unset builder.
<Laney> got it, that worked. thanks.
<StevenK> wgrant: grepping for Mochi shows some functions that need it in lp-mochi.js and a few other places.
<StevenK> wgrant: I can't see it mentioned by translations, but I haven't gone searching for the functions in lp-mochi.
<StevenK> lib/lp/translations/templates/currenttranslationmessage-translate-one.pt would be it.
<wgrant> StevenK: IIRC translations uses lp-mochi
<wgrant> Not mochi directly.
<wgrant> But that's a project for the morrow.
<StevenK> Oh, why? I was just about to delete half of lp-mochi
<wgrant> Eliminating MochiKit and YI2 is one of the week's projects.
<StevenK> YUI2 I'm not sure about, but it seriously looks like Mochi is one branch. Perhaps two.
<wgrant> Probably, yes.
<StevenK> Oh, it doesn't help that MochiKit.js is over 4,000 lines.
<StevenK> Dear Google. Yes, I may be in Hungary. This does not mean I want Google+ to be in Hungarian. No love, me.
<StevenK> stub: I guess that means you made it here too.
<StevenK> stub: Or you're just confusing us with more proxy madness.
<stub> I is here
<StevenK> wgrant: Is https://code.launchpad.net/~stevenk/launchpad/bpph-supersede/+merge/87875 complete crack?
 * jelmer waves to bdmurray, lifeless
<nigelb> Oh, Epic week?
<mwhudson> y
<nigelb> Nice :-)
<nigelb> How's Budapest in winter? Dark and snowy?
<mwhudson> i
<mwhudson> i'm not there :)
<nigelb> ah
<nigelb> bah, I keep forgetting you're with Linaro now :)
<mwhudson> yeah, sf in feb for me
<mwhudson> which sounds like a better deal than budapest in jan, in most ways
<stub> Its cold, dark but not snowy
<nigelb> heh
<nigelb> stub: got a few mins for a PM?
<stub> a bit. bed time soon.
<spm> Q: we have a sync script for codehost staging; it's recently been failing: from canonical.database.sqlbase import connect <== ImportError: No module named database.sqlbase  <== is this a rename, or something more fundamental?
<mwhudson> rename i suspect
<mwhudson> although hm
<mwhudson> spm: can you paste the traceback?
<spm> Traceback (most recent call last):
<spm>   File "/srv/bazaar.staging.launchpad.net/scripts/codehosting_branch_mirror.py", line 12, in <module>
<spm>     from canonical.database.sqlbase import connect
<spm> ImportError: No module named database.sqlbase
<spm> make: *** [rebuild] Error 1
<spm> not much more than that
<mwhudson> huh
<spm> (debugging why codehost staging doesn't come back after an update. this be why. hello Mr Yak, and what style are we cutting today?)
<mwhudson> spm: is ./lib/canonical/database/sqlbase.py there?
<spm> huh. the entire database directory is not
<mwhudson> spm: hm, i suspect a more recent revision of devel has readded it
<spm> lib/lp/services/database/sqlbase.py mayeb?
<mwhudson> err
<mwhudson> ah
 * mwhudson suspects a bong merge from devel to db-devel
<mwhudson> r14610 of devel was the one that farted around with lib/canonical/database
<mwhudson> but it left something in its place
<mwhudson> ah no
<mwhudson> spm: yeah, just change your script to import from lib/lp/services/database/sqlbase.py
<spm> coolies, ta
<mwhudson> well lp.services.database.sqlbase
<spm> nod
<spm> :-)
<nigelb> spm: yak shaving on a monday morning is awesome, isn't it? ;-)
<mwhudson> good week for it
<spm> nigelb: "awesome" is perhaps NOT the word I'd choose :-)
<nigelb> heh
<spm> mwhudson: (sorry, distracted elsewhere) that's a good fix. all working again. ta mon.
#launchpad-dev 2013-01-02
<StevenK> wgrant: If you remember the duplicated SPPH queries, both are caused deep inside lazr.restful :-(
<wgrant> StevenK: Why does it make them?
<StevenK> wgrant: One of them is due to a call to checkAuthenticated, I don't understand the second
<wgrant> Right
<wgrant> But lazr.restful doesn't magically make DB queries any more than anything else does
<wgrant> The fix is usually the same
<StevenK> wgrant: http://pastebin.ubuntu.com/1486577/ is a diff between the two tracebacks
<wgrant> StevenK: Right, so it's pretty clear what's going on
<wgrant> Do you see it?
<StevenK> wgrant: I wish it was pretty clear to me what's going on. :-(
<wgrant> Well, look at the traceback
<wgrant> It's the launchpad.View adapter for SourcePackageRelease
<StevenK> It calls the security adapter twice to redact fields?
<wgrant> Possibly delegated from elsewehere
<StevenK> Oh, one of them is checkAuthenticated and another is checkUnauthenticated?
<wgrant> No
<wgrant> One's LimitedView, one's View
<wgrant> Probably on different objects
<wgrant> From the traceback we can see that in both cases it's on PackageUpload, which delegates to SourcePackageRelease, which queries the published archives
<StevenK> wgrant: Oh, in which case there isn't much we can do
<StevenK> Without stapling cachedproperties into SPR and fiddling with get_property_cache and friends
<wgrant> But the entire branch is like that
<wgrant> That's sort of the entire point
<wgrant> To eliminate exactly this
<StevenK> Right, but it's one query? :-)
<wgrant> One query per packageupload
<wgrant> O(n) queries
<wgrant> Verboten
<wgrant> You already presumably precache the PUSs and PUBs
<wgrant> The SPPHs shouldn't be that awkward
<StevenK> wgrant: Right, but the SPPH query is coming from the SPR, not the PU
<wgrant> StevenK: Sure
<wgrant> Is that a problem?
<wgrant> You have the SPRs already
<wgrant> Because you preloaded them
<wgrant> So you can additionally preload their published archives
<StevenK> Ahh, but the browser code preloads the SPRs, IPackageUploadSet.getAll() does no such thing.
<wgrant> Huh?
<wgrant> If you're not already preloading the SPRs, then you've missed a step
<wgrant> There must be extra queries before the SPPH queries
<wgrant> To get the SPRs
<wgrant> Which means you've preloaded them, in which case you already have them
<wgrant> Or you haven't preloaded them, in which case you should be preloading them to eliminate O(n) SPR queries
<wgrant> So, if you're looking at the SPPH queries, you have either already preloaded the SPRs or you need to
<StevenK> Blink
<StevenK> 1 PU == 27 queries. 5 PUes == 55
<wgrant> Hmm?
<wgrant> Is that surprising?
<StevenK> I wasn't expecting that large a jump
<StevenK> Another ten maybe, not 28
<wgrant> That's only <5 queries for each
<wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/bug-1095188/+merge/141579
<StevenK> wgrant: Did you have a plan about the test failure?
<wgrant> Oh
<wgrant> I thought you might fix that, given you're in the blamelist
<wgrant> I was just tempted to bump the grace period to 20 years
<StevenK> That sounds a bit harsh
<StevenK> wgrant: I decided I wanted to swap back in my knowledge about the PU branch so I could actually finish it off.
<StevenK> 17	- # I have chosed to use this simple solution for now.
<StevenK> 18	- # -- kiko, 2006-07-11
<StevenK> I'm not sure whether to be scared, horrified or impressed.
<StevenK> wgrant: return None is implied
<wgrant> Sure
<wgrant> But I find it best to be explicit
<StevenK> But it's +8/-16, so I care little
<StevenK> wgrant: r=me
<StevenK> Interesting how it shows r16391 in Unmerged revisions
<wgrant> The scan failed
<wgrant> Because of a cold cache
<wgrant> When I land my testfix in 30s it'll realise r16391 is there
<wgrant> Because I primed the cache
<StevenK> Of your branch or devel?
<wgrant> devel
<StevenK> I'm a little afraid of your testfix diff, TBH
<wgrant> It's going to be less terrifying than reworking archiveuploader'
<wgrant> s datetime usage to be mockable
<StevenK> That's true
<StevenK> wgrant: Oh, it's a doctest change. That's okay, then
<wgrant> Hmm
<wgrant> I am missing some Launchpad email
<wgrant> StevenK: Did you get mail about your +1?
<StevenK> Yeah
<wgrant> Mysterious
<wgrant> Timestamp?
<StevenK> 0303
<wgrant> 0403?
<StevenK> Received by mangled.wedontsleep.org (Postfix, from userid 112) id 5322736BBF; Wed,  2 Jan 2013 15:03:35 +1100 (EST)
<wgrant> Right, 0403 :)
<wgrant> I quite mysterously did not get that
<StevenK> You got the other mail about you proposing it?
<wgrant> Yep
<StevenK> Mail queue on indium?
<StevenK> wgrant: Down from 55 to 34. Still trying to distill out where preloading will still help.
<wgrant> Everywhere
<StevenK> Sorry, let me be more clear.
<StevenK> Still trying to distill out what else should be preloaded to help.
<wgrant> Well
<StevenK> Oh, related archives of the SPRs.
<wgrant> Find things that still make queries
<wgrant> Preload them :)
<StevenK> wgrant: Yes, which requires digging through a ton of scrollback because each query gives a seperate traceback
<StevenK> Anyway, down to 30.
<StevenK> There are five SPPH queries I can't seem to shake
<StevenK> If I load_referencing SPPHs and then load_related the Archive, it still makes the queries
<wgrant> StevenK: eg?
<StevenK> wgrant: An example query?
<wgrant> And where it comes from
<wgrant> And how you are doing the preload
<StevenK> wgrant: The query is coming from ISourcePackageRelease.published_archives, and I'm doing the preload by:
<StevenK> publications = load_referencing(
<StevenK>     SourcePackagePublishingHistory, sprs, ['sourcepackagereleaseID'])
<StevenK> load_related(Archive, publications, ['archiveID'])
<wgrant> You're missing a critical bit there
<wgrant> Remember what we discussed two weeks ago?
<StevenK> wgrant: Setting published_archives to a cachedproperty and using get_property_cache? Or the primary key bit?
<wgrant> Both
<wgrant> Because published_archives is a revert PK lookup, Storm can't cache it automatically
<wgrant> You have to stuff it in manually, with get_property_cache
<wgrant> s/revert/reverse/
<StevenK> Hmmm, so I guess the SPPHs are inconsequtial here. But then I need to map the archives back to the SPR via it
<StevenK> loltpg
<wgrant> Right
<StevenK> Hmm, it may only want the archive id
<wgrant> This is a slightly abnormal case, because it's a straight double reverse lookup
<StevenK> The code isn't very clear
<wgrant> What do you mean?
<StevenK> return sorted(archives, key=operator.attrgetter('id'))
<wgrant> published_archives is a collection of Archive objects
<wgrant> THat returns archives, sorted by id
<StevenK> Oh, it's the sort key is the id
<wgrant> Yes
<StevenK> wgrant: So I can load_related all the archives, but then I need those objects to append using get_property_cache?
<wgrant> StevenK: You'll probably want to load and keep a list of all the relevant publications, then load all their archives
<wgrant> Then you can go through each pub, and append pub.archive to the SPR.published_archives cache
<StevenK> AttributeError: 'DefaultPropertyCache' object has no attribute 'published_archives'
<StevenK> :-(
<StevenK> Hm. If I get_property_cache(pubs[0].packageupload) it has sources, builds and customfiles, but my get_property_cache(publication.sourcepackagerelease) has nothing
<wgrant> StevenK: Do you have it decorated?
<StevenK> wgrant: Which part? published_archives is decorated by @cachedproperty, yes
<wgrant> What statement produced that exception?
<StevenK>         spr = get_property_cache(publication.sourcepackagerelease)
<StevenK>         spr.published_archives.append(publication.archive)
<wgrant> appending to what?
<wgrant> You can't append to a value that doesn't exist :)
<wgrant> You need to set it to something first
<StevenK> spr.published_archives = [] isn't really helpful, since multiple publications might reference the same SPR?
<wgrant> Sure
<wgrant> You'll need to set it to [] only if it doesn't already exist
<wgrant> Or go through and set them all to [] before you start appending anything
<wgrant> The latter might be better
<StevenK> Two loops of publications and get_property_cache makes me sad
<wgrant> Erm why?
<wgrant> One loop of SPRs to initialise the property caches
<wgrant> Then one loop of pubs to populate the SPR caches
<StevenK> wgrant: O HAI, https://code.launchpad.net/~stevenk/launchpad/moar-preload-distroseries-queue/+merge/141581
<wgrant> StevenK: So it's 27 queries regardless of PU count?
<StevenK> wgrant: Yes. Bumping that range(5) to range(6) and running the test still passes.
<StevenK> wgrant: I'm a little tempted to rip prefill_packageupload_caches out to lp.soyuz.adapters.queue or something
<lifeless> how long till you've rewritten all of LP ? :)
<StevenK> lifeless: Shorter if you help.
<lifeless> StevenK: Heh :). Intruiging suggestion.
<StevenK> wgrant: My review is still in progress, or I've scared you off?
<wgrant> #-ops
<wgrant> StevenK: Why'd you move TestLaunchpadSecurityPolicy_getPrincipalsAccessLevel to ZopelessLayer?
<StevenK> wgrant: At a guess, that test has no layer at all
<StevenK> I'm happy to drop that change and the import
<wgrant> Right, don't add things to layers if they don't need to be there :)
<wgrant> Layerless tests are much much faster
<StevenK> wgrant: Still reviewing the packageupload branch, or shall I stop working and move onto rewriting transmission-daemon's postinst in anger?
<wgrant> I'm reviewing
<adeuring> good morning
<czajkowski> adeuring: ello were you working on blueprints there for a while before christmas?
<adeuring> czajkowski: IIRC I did not any serious work on blueprints
<czajkowski> adeuring: ah ok trying to work out what could be happening on a bug
<adeuring> czajkowski: gah, yes, i did some pivacywork on them
<czajkowski> https://bugs.launchpad.net/launchpad/+bug/1095235
<_mup_> Bug #1095235: Bogus dependencies in Blueprint graph <Launchpad itself:New> < https://launchpad.net/bugs/1095235 >
<adeuring> ...disclosure...
<czajkowski> but this isn't disclosure but wonring if it may be a knock on effect
 * adeuring needs a memory upgrade
<czajkowski> adeuring: good holiday :)
<adeuring> czajkowski: ;) anyway, what's the prolem?
<czajkowski> extra dependencies showing up
<adeuring> czajkowski: is there a bug about anywhere or some other discussion?
<czajkowski> adeuring: the one I just posted in here ..
<adeuring> czajkowski: thanks (seems need new eyes too)
<czajkowski> :)
<czajkowski> brb I need to reboot
<czajkowski> back
<czajkowski> adeuring: any ideas?
<adeuring> czajkowski: not really for now. I think that's something for the maintenance team. At first, I'd do an SQL query to see what dependencies really exist in the DB and go on from there.
<czajkowski> nods
<czajkowski> ok thanks adeuring
<StevenK> czajkowski: The blueprint dependency code is a little frightening
<czajkowski> StevenK: aloha and welcome back
* abentley changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: abentley | Firefighting: - | Critical bugs: <150
* abentley changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: - | Firefighting: - | Critical bugs: <150
<StevenK> wgrant: Did you peer at the incremental diff?
<wgrant> StevenK: Looks reasonable
<StevenK> wgrant: Perhaps we shouldn't hardcode -20 in nascentuploadfile.txt
#launchpad-dev 2013-01-03
<StevenK> And I lose buildbot bingo rather spectacularly.
<StevenK> rick_h_: No fair if you force it.
<rick_h_> StevenK: I didn't touch it :P
<StevenK> wgrant: Haha, it takes DF 13 minutes to work out the source size of the primary archive.
<StevenK> I daresay binary size is far worse.
<wgrant> Quite
<wgrant> StevenK: Oh, why didn't you just trivially fix that rev rather than reverting it?
<StevenK> I saw multiple issues in the failures
<wgrant> Wasn't it all just the webservice.py import removals?
<StevenK> I wasn't sure
<StevenK> Quicker to revert and reland
<StevenK> (After checking, if I care)
<StevenK> wgrant: So we can't do the repository size in the request, and we can't do it in a job, and it's too slow for the publisher :-(
<wgrant> Indeed
<StevenK> We could possibly denorm published size onto spph and bpph
<StevenK> And then just traverse that
<wgrant> That would change the definition substantially (and probably fatally), and not be hugely fast anyway
<StevenK> We're running out of places we can do it :-(
<wgrant> It will probably require a redefinition of what an archive's size means, or a (archive, filename)ish denormalised table
<wgrant> Neither of which is easy
<wgrant> Pick another bug :)
<StevenK> Eh, it answers the question you asked last time I bought it up
<wgrant> What was the question?
<wgrant> I'm pretty sure I said it was probably too slow to ever calculate fully in one hit very much
<StevenK> "How long does it take to calculate the size for the primary archive, if we do it in the publisher?"
<StevenK> Or so
<wgrant> Well
<wgrant> If I did pose that question, it was mostly to demonstrate that it was dreadfully slow
<StevenK> Which makes the answer 'an eon or so'
<wgrant> And so your approach was invalid
<StevenK> wgrant: Are you working on the +sharing critical?
<wgrant> No
<wgrant> But it's trivial, so feel free
<wgrant> While you're there you should also check that the unused AP pruner will DTRT in terms of Product.information_type
 * StevenK watches kanban choke his browser
<wgrant> StevenK: That doesn't look very constant...
<lifeless> its slow cause its cold cache IO
<wgrant> Nope
<wgrant> Unless cold cache magically causes 40 repetitions
<lifeless> repo size stuff
<lifeless> back up an hour
<wgrant> Oh, yeah, obviously
<wgrant> There's a lot of rows
<wgrant> Most of which won't be poked much
<lifeless> O(files) will always be slow for that
<wgrant> So the cache will always be slow
<wgrant> s/cache/query/
<lifeless> you need sublinear scaling for that one.
<wgrant> Yes
<wgrant> Of course
<wgrant> That's what i said :)
<wgrant> It needs a complete redesign
<wgrant> hence defer
<lifeless> e.g. event based recalc and a cached value.
<wgrant> Precisely
<wgrant> But it's too slow to even do event-based full recalc in the current model
<wgrant> So it needs to be reworked even further
<lifeless> wgrant: !cite
<lifeless> [its not clear to me that thats the case]
<wgrant> Let's say 20k binaries per DAS
<wgrant> Average of 5 or 6 DASes per series
<wgrant> Maybe 6 published series at a time
<wgrant> + 20k sources per series
<wgrant> So that's >600k pubs for the primary archive
<wgrant> Which isn't huge
<StevenK> And an average of 3 files per publication
<wgrant> But we don't need that hot
<wgrant> So we should keep it cold if we can
<wgrant> StevenK: Not quite, due to binaries it'll be more like 1.5-2 I suspect
<StevenK> wgrant: Then you have things like linux and firefox that build 10,000 binaries
<wgrant> There are better things to keep in wildcherry's cache than millions of Ubuntu rows
<wgrant> When we can relatively easily cache
<wgrant> Similar to branchrevision
<lifeless> how often does the primary archive do deletes (vs updates) ?
<wgrant> Having to keep that hot for anything to work is completely completely stupid
<wgrant> lifeless: > hourly
<wgrant> Since stuff gets superseded
<lifeless> sure
<StevenK> p-d-r is seperate from the publisher
<lifeless> so what I'd be inclined to do is to use something like twitters graph thing to keep this hot
<lifeless> and have a size calculating spout
<wgrant> So
<lifeless> hot as in live in-memory on a small number of machines
<wgrant> Things we can deploy in the next 5 years
<lifeless> heh :)
<wgrant>  - Not a Twitter graph thing
<wgrant> We need a solution to this in the next 12 months
<StevenK> So I think the current query works fine for small PPAs. But it scales horribly
<wgrant> So deploying anything exotic is entirely out of the question
<wgrant> And wildcherry has enough cache issues as it is
<lifeless> you don't need to query wildcherry
<StevenK> wgrant: So we create a proprietary project, set it to public and make certain a PUBLIC AccessPolicy wasn't created?
<wgrant> StevenK: Yes
<wgrant> StevenK: So, more work required on +queue :(
<StevenK> :-(
<StevenK> It still makes too many queries?
<StevenK> DONE precise on qas is 129
<StevenK> Which is like 1/3rd
<wgrant> 24 PackageBuild queries, plus lots of other stuff
<wgrant> https://oops.canonical.com/oops.py/?oopsid=OOPS-566218b1efc27aca3c77c68091a09d83
<StevenK> Yeah, I just read the query log on qas
<StevenK> The lowest hanging fruit is certainly PackageBuild
<StevenK> wgrant: Hm, now I remember. I couldn't get my test cases to make the PB queries so I moved on.
<wgrant> You clearly need more PUBs
<StevenK> 15 isn't enough?
<wgrant> So
<wgrant> Work out where the PB queries come from
<wgrant> Then work out why they aren't appearing in your test
<StevenK> wgrant: However, we can slam the two bugs back to In Progress and qa-ok
<wgrant> Yes
<StevenK> wgrant: Based on my reading of the code, the 16 PUBLIC APs won't be deleted, there are probably APGs holding them in
<wgrant> StevenK: APGs don't hold them
<wgrant> Only APAs and sharing policies do
<wgrant> But the sharing policies will probably keep them
<StevenK> We can fix those up without a code change, though?
<wgrant> Well, we'll delete them manually
<wgrant> _pruneUnusedPolicies keeps anything that's permitted by a sharing policy.
<wgrant> Including any public types that shouldn't have had an AP in the first place.
<StevenK> wgrant: I'm confused, do we need a code change to clean up? Or when you say delete you mean "DELETE FROM" ?
<wgrant> We could switch _pruneUnusedPolicies to always prune policies that are public, but that's pointless because they shouldn't exist in the first place
<wgrant> It would be best to SQL them away manually
<StevenK> 'if not self.obj.archive.private' causes PB lookups? :-(
<wgrant> Sure
<wgrant> Archive is on PB
<StevenK> wgrant: Sure, but from ViewSourcePackageRelease ?
<wgrant> Um
<wgrant> SPR.archive doesn't exist
<wgrant> So no, you're wrong :)
<wgrant> Sounds more like ViewBinaryPackageBuild
<wgrant> Indeed
<StevenK> Right
<StevenK> Perhaps self.factory.makeBuildPackageUpload is missing some bits, then
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/no-public-for-all-projects/+merge/141700
<wgrant> StevenK: _prepare_to_set_sharing_policy already knows how to restrict it to just private types
<wgrant> We shouldn't duplicate that logic.
<StevenK> Let me move into _ensurePolicies then
<StevenK> wgrant: http://pastebin.ubuntu.com/1490688/
<wgrant> Sounds reasonable
<StevenK> wgrant: Actually, http://pastebin.ubuntu.com/1490691/
<wgrant> Indeed
<StevenK> Oh wonderful, I think I've broken diff generation for that MP
<StevenK> Ah, look at that.
<StevenK> wgrant: Can haz +1 now?
<StevenK> MismatchError: queries do not match: 52 != 87
<StevenK> Success
<wgrant> StevenK: Done
<wgrant> What did you eliminate?
<StevenK> I eliminated nothing. I reached into the BPB's BPR and called addFile
<wgrant> Ah
<StevenK> wgrant: And sorry for my OCD forcing +39/-41 on you :-)
<StevenK> Right, preloading PB gets us down to 73
<StevenK> wgrant: http://pastebin.ubuntu.com/1490769/ gets us to 30 queries on the API, and 57 on the web
<StevenK> We don't really need to preload PBs, Components and Sections in getAll(), but it was trival.
<wgrant> getAll should basically only be used by getPackageUploads and +queue, right?
<wgrant> So it's probably not too bad to aggressively preload
<StevenK> Pretty much, yes
<StevenK> I'd like to preload away the PackageDiff stuff, but that doesn't look easy
<wgrant> I thought you already looked at doing that
<wgrant> Oh right, you gave up after I told you your trivial implementation wouldn't work?
<StevenK> I did, yes
<StevenK> wgrant: If you're happy enough with that diff I can put together an MP?
<wgrant> IIRC it just iterates over SPR.package_diffs
<wgrant> Which is going to be relatively easily to cachedpropertyify
 * StevenK peers
<wgrant> It's been a while since I was over there
<wgrant> But I don't see why it would do otherwise
<wgrant> Yeah
<wgrant> wgrant@lplucid:~/launchpad/lp-branches/devel$ bzr grep package_diffs lib/lp/soyuz/templates/
<wgrant> lib/lp/soyuz/templates/distroseries-queue.pt:      <tr tal:define="diffs packageupload/sourcepackagerelease/package_diffs"
<wgrant> lib/lp/soyuz/templates/sourcepackagerelease-diffs.pt:       tal:define="diffs context/package_diffs"
<wgrant> cachedproperty
<wgrant> done
<wgrant> (well, plus a couple of lines here and there to prepopulate and invalidate)
<StevenK> It's a SQLMutlipleJoin, so I can cheat by _package_diffs, or rewrite to something actually using IStore
<StevenK> SQLMultipleJoin, even
<wgrant> It's unlikely that much actually cares that it's an SQLMultipleJoin
<wgrant> It can probably be turned into a simple cachedproperty list, but you'll have to look at the other callsites
<wgrant> Seem to be only 5 non-test callsites
<wgrant> ez
<StevenK> wgrant: Eh, easy enough to copy the pattern that PackageUpload uses with sources vs _sources
<wgrant> As I said in the last MP, that's pretty pointless
<wgrant> If nothing needs a resultset then a resultset need not be exposed at all
<wgrant> Never expose unnecessary interfaces
<wgrant> Or you end up with something like Launchpad :)
<wgrant> (it appears that none of the callsites will notice if you make it a lisT)
<StevenK> +    @cachedproperty
<StevenK> +    def package_diffs(self):
<StevenK> +        return list(self._package_diffs)
<wgrant> Bad StevenK
<StevenK> Ah ha, so you *do* want the destruction of the SQLMultipleJoin
<wgrant> It's pointless to keep it
<wgrant> return list(Store.of(self).find(PackageDiff, to_source=self).order_by(Desc(PackageDiff.date_requested)))
<wgrant> done
<StevenK> Right, which I was in the middle of typing when you said that ...
<StevenK> wgrant: Not sure where to invalidate SPR.package_diffs, but that preloading gets us to 53 queries.
<StevenK> Except that the LFA and LFC preloading helps not at all
<wgrant> DId you preload the correct LFAs and LFCs?
<wgrant> wgrant@lplucid:~/launchpad/lp-branches/devel$ bzr grep '\bPackageDiff\('
<wgrant> lib/lp/soyuz/model/packagediff.py:class PackageDiff(SQLBase):
<wgrant> lib/lp/soyuz/model/sourcepackagerelease.py:        return PackageDiff(
<wgrant> lib/lp/testing/factory.py:            PackageDiff(
<StevenK> Easy
<wgrant> Huh
<wgrant> I just removed all the writable bits of the BuildFarmJob and PackageBuild security configuration
<wgrant> And the only tests that appear to fail are those that test the permissions directly
<lifeless> \o/
<czajkowski> aloha
<adeuring> ood morning
<czajkowski> adeuring: hopefuly not an odd morning either :)
<adeuring> czajkowski: yeah: i need to clean my keayboard from tobacco crumbs...
<adeuring> brb
<czajkowski> rick_h_: http://i.imgur.com/OWtoF.jpg
<rick_h_> czajkowski: I'm sending help, hold on tight!
<sinzui> buildbot is seriously harshing my mellow
<czajkowski> sinzui: I'm going to go with that's not a good mellow
#launchpad-dev 2013-01-04
 * StevenK stabs the error handling for spr.addFile()
<StevenK> bpr.addFile() just checks filename.endswith(), spr.addFile() matches against a regex.
<StevenK> Can I forbid buildout from downloading stuff that isn't in the local cache?
<wgrant> It should be already
<StevenK> Not for LP.
<StevenK> https://pastebin.canonical.com/81106/
<wgrant> install-from-cache = true
<wgrant> Is set in buildout.cfg
<wgrant> So it should already refuse to go to the Internet
<wgrant> Oh
<wgrant> That's not LP
<wgrant> That's auditor, isn't it?
<StevenK> [15:06] < StevenK> Not for LP.
<wgrant> 15:05:50 < wgrant> It should be already
<wgrant> 15:06:01 < StevenK> Not for LP.
<wgrant> :)
<StevenK> And yeah, it's auditor
<cjohnston> Am I mistaking or is bug #517302 a dup of bug #496056
<_mup_> Bug #517302: "1 branch dependent on this one." doesn't link to that branch or a list of them <code-review> <confusing-ui> <easy> <lp-code> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/517302 >
<_mup_> Bug #496056: Dependent branch list is empty <lp-code> <Launchpad itself:Triaged> < https://launchpad.net/bugs/496056 >
<wgrant> Indeed
<wgrant> Done
<StevenK> wgrant: Then I'm confused, since Django is in our download-cache
<cjohnston> :-)
<StevenK> Indeed, 1.3.3 and 1.4
<wgrant> StevenK: Is the flag set in order?
<wgrant> In auditor?
<StevenK> That flag was not set
<StevenK> The order in buildout.cfg matters? :-/
<wgrant> No, I just replaced 'auditor' with 'order' because I'm doing too many things at once :)
<wgrant> As long as it's in the right section it should be fine
<wgrant> AFAIK
<StevenK> wgrant: I've set it locally
<StevenK> Hm, it does indeed try and slurp Django from the net with that flag unset.
<StevenK> It gets 1.4 from the download-cache with it set, and 1.4.3 from the net with it unset.
 * StevenK stabs buildout for being silly.
<wgrant> StevenK: You don't have it locked in versions.cfg?
<StevenK> No versions.cfg
<StevenK> Patches welcome? :-)
<wgrant> Ah, that would be your mistake
<StevenK> wgrant: So it should grow a versions.cfg too?
<wgrant> Probably, or someone'll throw a new Django into download-cache and you'll die
<StevenK> wgrant: So grabbing LP's versions.cfg and putting it on a large diet with head and grep would be fine?
<wgrant> Nope
<wgrant> Set allow-picked-versions = false
<wgrant> Add stuff to versions.cfg until buildout unbreaks
<StevenK> Hmm
<StevenK> Why do we have two versions of setuptools in the cache?
<wgrant> There's only one
<wgrant> Different Python versions
<StevenK> I have a 2.6 and a 2.7 for 0.6c11
<wgrant> Yes
<wgrant> One version
<wgrant> Two Python versions
<wgrant> They're built eggs, not source tarballs
<StevenK> Oh
<StevenK> I see what's happened
<StevenK> My cache has been polluted
<StevenK> -rw-rw-r-- 1 steven steven 326K Jan  4 15:13 setuptools-0.6c12dev_r88846-py2.7.egg
<StevenK> The timestamp is a clue
<wgrant> Ah, yes
<wgrant> bzr st
<StevenK> Yeah, removed them
 * StevenK cleans, since buildout is still attached to the dev release
<StevenK>   Getting distribution for 'setuptools'.
<StevenK> Error: Picked: setuptools = 0.6c11
<StevenK> But setuptools = 0.6c11 is in versions.cfg :-(
<wgrant> Do you have versions.cfg registered in buildout.cfg?
<StevenK> I do now
<wgrant> Does it also work now?
<StevenK> It moved onto zc.buildout, so yay progress?
<wgrant> :)
<StevenK> Generated interpreter '/home/steven/production-auditor/bin/py'.
<StevenK> Fantastic.
<nigelb> Just here to complain about the expiring notices from LP.
<nigelb> I wish I could fix it.
<StevenK> Patches welcome.
<bigjools> lifeless: that android bug made me spit my lunch I laughed so hard
<nigelb> bigjools: the giraffe thing?
<bigjools> yes
<nigelb> :D
<nigelb> Is it a bug/
<bigjools> I even recreated it
<bigjools> well, I wonder
<nigelb> Feels more like a easter egg.
<bigjools> yeah
<lifeless> bigjools: its pretty awesome isn't it :)
<bigjools> ah it is a bug in TTS
<wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/divorce-bfj-and-bfjo/+merge/141856
<StevenK> 159"""See `IBuildFarmJobOld`."""
<StevenK> Oh, you aren't disposing of BFJO yet?
<StevenK> 286	+ # Classes deriving from PackageBuild must provide various
<StevenK> 287	+ # methods.
<StevenK> Does that fit on one line?
<wgrant> Not quite
<wgrant> On both counts
<wgrant> BFJO still serves a purpose, and it won't be directly touched by this refactor
<wgrant> Which is why I want the interfaces to not be arbitrarily interrelated without having any actual overlap :/
<StevenK> wgrant: Minor niggle, but you didn't update the copyright in lib/lp/security.py
<StevenK> Other than that, looks great to me.
<wgrant> Fixed
<wgrant> Thanks
<StevenK> wgrant: To be clear, BFJO is marked for death and will be completly ripped out at some point?
<wgrant> It's been marked for death for about 2.5 years, but it'll be easier after my current work
<wgrant> So it might die within the next few months
<bigjools> \o/
<adeuring> good morning
<dpm> good morning all. I was wondering if someone could help me: in preparation for the phone launch I created a private project to contain the code for the tutorials on developer.ubuntu.com. And then I managed to lock myself out of it, so I cannot access the project anymore. As it does not need to be private anymore after the announcement, could someone with admin superpowers set it as a public project for me? It's https://launchpad.net/ubuntu-app-dev-cook
<dpm> book
<dpm> https://launchpad.net/ubuntu-app-dev-cookbook
<wgrant> dpm: You should be able to see it now
<wgrant> It's still private, but you can make it public
<dpm> wgrant, great, thanks! The same happened to the associated team: https://code.launchpad.net/~ubuntu-app-dev-cooks - can I regain access to it so that I can make it public as well?
<wgrant> dpm: That team's public and you're the owner, a member, and an admin
<wgrant> So I'm not sure what the issue is there
<wgrant> Are you referring to some branches owned by that team, perhaps?
<dpm> wgrant, not sure, either. Before you did the magic with the project, if I went to the team's main page I got a "not allowed here" page. But now I seem to access the team's page, so I guess it's all good
<wgrant> Ah, Person.getAffiliatedPillars doesn't do privacy filtering
<wgrant> So the "Related projects" was causing the 403
<czajkowski> aloha
<wgrant> Bug #1095982
<_mup_> Bug #1095982: Person.getAffiliatedPillars doesn't filter out inaccessible private projects <403> <easy> <private-projects> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1095982 >
<wgrant> Morning czajkowski
<dpm> wgrant, ok, I managed to set the project as public, but I cannot figure out how to make https://code.launchpad.net/~ubuntu-app-dev-cooks/ubuntu-app-dev-cookbook/trunk public. If I click on the "This branch contains Proprietary information" link, the only choice I get on the popup that appears is "Proprietary". Any suggestions on how I can make the branch public?
<wgrant> dpm: https://launchpad.net/ubuntu-app-dev-cookbook/+sharing
<wgrant> You probably want to set bugs, branches and blueprints to public
<wgrant> Then you can make the branch public
<dpm> wgrant, excellent, thanks. I set everything to public now. Do the settings on the table under "Who it's shared with" look sensible for a public project?
<wgrant> dpm: I'd revoke your direct access, but the rest looks sensible (apart from the "{policy_name}" bit, which is a bug that'll be fixed on Monday)
<dpm> wgrant, ok, I'll remove my direct access. Two more questions:
<dpm> 1) I still cannot set the branch to Public: on https://code.launchpad.net/~ubuntu-app-dev-cooks/ubuntu-app-dev-cookbook/trunk if I change it, the change does not get applied
<dpm> i.e. the spinning thing keeps spinning forever
<wgrant> Um, that's a bit odd. What if you click "Change details" and use the old non-AJAX form?
<wgrant> Oh
<dpm> then I only get a Proprietary option
<wgrant> It's because it's stacked on another branch owned by you
<wgrant> https://code.launchpad.net/~dpm/ubuntu-app-dev-cookbook/trunk
<wgrant> I guess you probably want to unstack the team branch, and delete your old personal one?
<dpm> actually, that was my second question. I'd like to delete that branch (https://code.launchpad.net/~dpm/ubuntu-app-dev-cookbook/trunk)
<dpm> how do I unstack the branch?
<wgrant> bzr reconfigure --unstacked lp:ubuntu-app-dev-cookbook
<wgrant> Then wait a minute or so for it to work out it's done, and you'll be able to delete the old branch and make the new one public
<dpm> cool, let me give it a go, thanks
<wgrant> That looks more sensible :)
<dpm> wgrant, that worked well, thanks. I still get two warnings, though: 1) on https://launchpad.net/ubuntu-app-dev-cookbook/+sharing I removed all direct subscriptions (yours and mine) and LP it's telling me "These information types are not shared with anyone: Proprietary". Is this something that can safely ignore? And 2) on the project's front page at (https://launchpad.net/ubuntu-app-dev-cookbook) I get "(Launchpad 30-day trial commercial license)" liste
<dpm> d as a license. I chose it when I made the project private, but I'm no longer using a commercial license. Is there a way to remove it?
<wgrant> dpm: The Proprietary warning should go away a day or so after there are no proprietary bugs or branches left, I think
<wgrant> As for the licence, just edit the project's licence settings to no longer include Other/Proprietary
<wgrant> The subscription will stay there until it expires, but nothing bad will happen when it does
<wgrant> (if the subscription expires and your project is Other/Proprietary, your project will be disabled)
<dpm> yeah, "Other/Proprietary" was already unmarked, but from what you're saying, I should just wait for the subscription to expire
<dpm> thanks wgrant!
<wgrant> I can probably make the subscription expire right now if you really want, but it'll just naturally expire soon enough
<dpm> wgrant, no worries, that's fine if it expires naturally, no need to create extra work
<wgrant> Great
* bac changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: bac | Firefighting: - | Critical bugs: <150
<czajkowski> rick_h_: you about
<rick_h_> czajkowski: yep
<czajkowski> if you are free for a few mins can you pop into #lp please
<rick_h_> czajkowski: sure sec
#launchpad-dev 2013-01-05
<cjohnston> I'm guessing that adding X-Launchpad headers isn't quite as easy as http://paste.ubuntu.com/1497755/ is it?
<cjohnston> uggh.. forgot it was a weekend.. :-/
<cody-somerville> cjohnston: That would cause the test to start failing which is a first good step ;)
<cjohnston> lol
<cjohnston> I don't have a setup to be able to run tests :-/
<lifeless> cjohnston: lxc ftw, you can make one easily :)
<cjohnston> would be nice if lpsetup worked ;-)
<cjohnston> (for something other than 12.04)
<lifeless> cjohnston: There were manual instructions on the wiki last I looked ;)
<lifeless> cjohnston: its only a few steps...
<cjohnston> probably are..
<cjohnston> hrm... lifeless setting up rocket-fuel in lxc is having trouble importing keys :-/
<cjohnston> had to manually add the keys
<cjohnston> When running rocket-fuel I'm getting "ERROR: Unable to create local copy of Rocketfuel trunk" after "Connection Timeout: disconnecting client after 300.0 seconds"... not sure what is going wrong. It seems to branch launchpad, then goes into something else. :-/
#launchpad-dev 2013-01-06
<rick_h_> cjohnston: source-deps? trying to think of what else it pulls from bzr
<cjohnston> rick_h_: I finally got it working.. thanks
<cjohnston> now trying to figure out the email headers
#launchpad-dev 2014-01-02
<stub> Another reason to dislike using HTTP as an RPC mechanism is $http_proxy.
<stub> I need to unset the http_proxy environment variable in the Librarian process, so Swift requests don't go via Squid
<stub> (which would be wasteful, and won't work anyway since the firewall rules won't let it happen)
<stub> Is it OK to hack this in in lp.scripts.runlaunchpad.start_librarian ?
<wgrant> stub: That's rather a reason to dislike mandatory egress HTTP proxies :)
<wgrant> stub: But that might be the least bad solution.
<wgrant> stub: Though, why is the librarian running with http_proxy at all?
<wgrant> Only certain scripts + the appservers should be
<wgrant> And the latter only due to retarded firewall rules.
<lifeless> stub: wgrant: just set no_proxy
<lifeless> no need to unset http_proxy
<stub> wgrant: It is in .bashrc, probably because we didn't think it would be harmful
<stub> lifeless: I don't know that one
<lifeless> no_proxy=hostname
<lifeless> -> requests to hostname won't go via the proxy.
<wgrant> That's an excellent recipe for totally breaking production.
<lifeless> wgrant: howso ?
<wgrant> lifeless: Nobody will think to check for that when changing the swift hostname.
<lifeless> wgrant: you could set that in the librarian code itself.
<wgrant> vom
<lifeless> wgrant: that seems a little shallow a response
<stub> lifeless: I don't think I can set it in process. I will know the Keystone URL, but I don't know the Swift endpoint URLs.
<stub> wgrant: it would work if we are consistently using internal DNS names now... All the keystone/swift stuff is new since we started doing that, so it should be reliable enough.
<wgrant> stub: Heh, you overestimate the sanity of our firewall configs.
<stub> wgrant: Although fixing it in .bashrc would just be a foot gun, so no real difference between unsetting http_proxy and setting no_proxy
<wgrant> We need to use http_proxy in order to connect to some internal hosts.
<stub> wgrant: Yeah. I already checked if staging's upstream librarian is directly connectable ;)
<wgrant> The example that immediately comes to mind is blog.launchpad.net from the appservers, but that's probably not the only one.
<stub> wgrant: productreleasefinder, bug-watcher... there are others.
<lifeless> stub: don't you get the swift urls from keystone?
<stub> lifeless: I don't. The swift library I'm using does.
<lifeless> stub: ah
<replaceafill> hello everybody, i've been trying to fix a couple of 'trivial' bugs and i have questions, can anyone help?
<cjwatson> replaceafill: (I'm only here for about twenty seconds, but) it's usually best to ask questions straight out and then leave your client hanging around for a while - LP devs are on various timezones but should be able to reply eventually
<replaceafill> cjwatson, ah ok understood, thanks!
<wgrant> replaceafill: Hi
<replaceafill> hi wgrant
<wgrant> replaceafill: What questions did you have?
<replaceafill> wgrant, i'm trying to fix this bug: https://bugs.launchpad.net/launchpad/+bug/260677
<_mup_> Bug #260677: Include date with milestones on advanced search page <lp-bugs> <oem-services> <search> <trivial> <ui> <Launchpad itself:Triaged> <https://launchpad.net/bugs/260677>
<replaceafill> let me push my branch
<replaceafill> wgrant, my push is taking way too long :(
<replaceafill> here's the diff though:
<replaceafill> http://pastebin.ubuntu.com/6681167/
<wgrant> replaceafill: Where are you pushing to?
<replaceafill> wgrant, i added a new vocabulary to be used in the "advanced" view
<replaceafill> wgrant, launchpad
<replaceafill> wgrant, my bandwitdh is very limited :(
<wgrant> Ah :(
<wgrant> It should only need to push a few hundred kilobytes.
<replaceafill> it finished!
<replaceafill> https://code.launchpad.net/~replaceafill/launchpad/bug-260677
<replaceafill> now lp is updating :)
<wgrant> So, what's not working?
<replaceafill> basically i'm not sure if my approach is correct
<replaceafill> i followed Curtis Hovey's suggestion about creating a new vocabulary
<replaceafill> the name of the new vocabulary for example MilestoneWithExpectedDateVocabulary
<replaceafill> seems "funny"
<wgrant> It's not too bad.
<replaceafill> ah, ok
<wgrant> It would be nice if Zope let us pass an argument into the vocab constructor, but it does not.
<replaceafill> you mean, so we could pass something to tell the vocabulary to insert the dates, right?
<replaceafill> (in the titles)
<wgrant> replaceafill: Right, that would be nicer than having AWholeNewClassWithAVeryLongName
<wgrant> But it's sadly not possible.
<replaceafill> right
<replaceafill> does this look good enough to you?
<replaceafill> i was also adding a unit test for the new vocabulary
<replaceafill> based on the tests of the existing one
<replaceafill> lp/registry/tests/test_milestone_vocabularies.py
<wgrant> Right, that would be a good idea.
<wgrant> I'd just add two additional tests, I think.
<wgrant> One for a milestone with a date, and one without.
<replaceafill> ah, ok
<replaceafill> in the unit test or the doctest?
<wgrant> The unit test. Doctests are deprecated.
<replaceafill> ah ok
<replaceafill> good to know :)
<replaceafill> can i set you as the reviewer of my branch after i'm done with the test?
<wgrant> Sure
<replaceafill> ok, i will
<replaceafill> thank you wgrant
<wgrant> np, thanks for working on this
<replaceafill> and expect some other nagging questions from me
<replaceafill> i've been working on a couple more :)
<wgrant> I look forward to it.
#launchpad-dev 2014-12-31
<sumanah> Hi! Where can I confirm that 9d:38:3a:63:b1:d5:6f:c4:44:67:53:49:2e:ee:fc:89 is the RSA key fingerprint for bazaar.staging.launchpad.net ?
<sumanah> answered in the Answers - thanks
<cjwatson> stub: Would it be possible to get a new pytz release with https://code.launchpad.net/~cjwatson/pytz/smarter-utcoffset/+merge/245472 or similar soonish, or should I be looking to revert my Launchpad commit that upgraded to 2014.10?
#launchpad-dev 2016-01-07
<xnox> wgrant, may i have something like http://qa.ubuntuwire.com/ftbfs/s390x.html but with xenial-release pocket only (no proposed) cause i really need to see what's left to be built in -release pocket, ignoring the piles of broken things in proposed =)
<wgrant> xnox: That's not really possible.
<xnox> wgrant, ok. fair enough.
<wgrant> xnox: Not all builds exist for release.
<wgrant> So you'd have to correlate builds in both pockets against sources published in release.
<xnox> .... right.
<wgrant> I might see how much work it is.
<xnox> wgrant, whilst incomplete, I think s390x.getBuildRecords(build_state='Failed to build', pocket='Release') is a good start for me.
<xnox> or not. there are more of those than in ftbfs report.
<wgrant> xnox: That's very incomplete.
<wgrant> Anything that's been uploaded since we created s390x will have the build in -proposed instead.
<xnox> right, failed in -proposed, and migrated with the proposed build-record, cause it was not a regression.
<xnox> i could do html parsing surgery with sed on s390x.html page ;-) and just remove full rows that mention proposed, without mentioning release line.
<xnox> maybe tomorrow
<xnox> good night
#launchpad-dev 2016-01-08
<wgrant> xnox: http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/primary-xenial-s390x-release.html
<wgrant> (shows a package only if it has an FTBFS in release, but will also show proposed for the package if it exists)
<wgrant> cjwatson: What is conceptually odd about https://code.launchpad.net/~cjwatson/launchpad/ppa-admins-private/+merge/281647?
<cjwatson> wgrant: just the way I had to use launchpad.Moderate as a spare permission
<cjwatson> wait, that was a different MP
<cjwatson> wgrant: ok, I think I just meant that setting privacy is not quite what I'd originally envisioned PPA admins as doing
<cjwatson> but it seems acceptable
<wgrant> The original idea of ppa-self-admins was that they have commercial-admin privs but only over PPAs they own, so it makes sense to me.
<wgrant> I don't know how I missed the breakage.
<cjwatson> I probably just didn't understand it quite well enough.
<wgrant> cjwatson: Does my comment on https://code.launchpad.net/~wgrant/launchpad/reject-not-accepted/+merge/281435 satisfy you?
<cjwatson> wgrant: Yes - commented
<wgrant> Thanks.
<wgrant> Yeah, the test is weird.
<wgrant> was, rather.
<cjwatson> Thanks for the db-git-recipe review, will look tomorrow.  I have the corresponding code branch nearly done.
<wgrant> "We rely on it to not store, so let's test that it is stored"
<cjwatson> Just need to do matrix branch/gitrepository testing for the existing sourcepackagerecipe tests
<cjwatson> And split it up into reviewable-sized pieces
<cjwatson> (it's about 1300 lines at the moment)
<wgrant> Not too bad.
<wgrant> How much of git-build-recipe is lifted from bzr-builder, or is it a rewrite?
<cjwatson> Initially lifted, with relatively extensive "porting".
<cjwatson> If you look at the structure it's pretty similar, which was because I doubted I'd get it to be compatible otherwise.
<cjwatson> Just as well since I only noticed in the last couple of days that LP expects to be able to use bzr-builder to parse recipes directly.
<cjwatson> But I started by copying it and then mangling until it worked, basically.
<xnox> wgrant, \o/ thank you
#launchpad-dev 2016-01-09
<jblakeman> exit
#launchpad-dev 2017-01-02
<sanjay__> I see huge black borders around my menus, windows and other wizards. How do I fix this?
#launchpad-dev 2018-01-02
<wgrant> cjwatson: Huh, I thought pocketlint caught all the double equals
<cjwatson> wgrant: As far as I can tell it has no double-equals handling
<wgrant> Hm./
<wgrant> cjwatson: Also what's with the new assertDictEqual that requires rSP? Do we need to exempt some new attrs from checks, or is it just type-checking?
<cjwatson> wgrant: What branch is this in, sorry?
<wgrant> cjwatson: https://code.launchpad.net/~cjwatson/launchpad/upgrade-testtools/+merge/335395 sorry
<cjwatson> wgrant: Looking harder I'm actually somewhat confused as to how it worked before.  unittest.TestCase.assertDictEqual does explicit isinstance checks.
 * cjwatson pdbs
<wgrant> We didn't monkeypatch in zope_isinstance, did we?
<wgrant> Doesn't look like it.
<cjwatson> I think it has something to do with our own TestCase.assertIsInstance, but checking why that's no longer used.
<cjwatson> Oh, right
<cjwatson> testtools now prefers unittest2, and that does self.assert_(isinstance(...)) rather than self.assertIsInstance()
<cjwatson> Which is kind of a regression from plain unittest IMO, but at least the impact is small
<wgrant> Ah, fair enough.
<cjwatson> Ah, but it's fixed in newer unittest2
<cjwatson> So maybe the right answer is to upgrade that instead
<wgrant> Aha
<cjwatson> wgrant: Upgrading unittest2 and reverting that change passes the relevant tests; I'll do a full test run, though
<wgrant> cjwatson: Excellent, thanks.
<cjwatson> (https://hg.python.org/unittest2/rev/071e84843744)
<cjwatson> https://hg.python.org/unittest2/rev/2ce0bdfa3bff may mean we actually have to fix some legacy cruft mind you, but we'll see
<cjwatson> That'll be an unfun diff if so
<wgrant> If they've actually been removed since, we should probably just add compat methods to our TestCase
<wgrant> We have a LOT of callsites.
<wgrant> Oh only about 800, not too bad.
<wgrant> Oh they actually removed assertEquals and co, oh dear
<wgrant> That's another 1500 or so
<cjwatson> Been mildly annoying me for about six years, so I might just fix in bulk ...
<cjwatson> I mean completely unreviewable, but
<wgrant> Indeed, a fine idea.
<cjwatson> No obvious DeprecationWarnings showing up yet, so it may just be general cleanup rather than required for this upgrade
<cjwatson> wgrant: Do you have a non-prod Swift setup?  I recall that the last time I tried to set one up I ended up rabbit-holing on it for the better part of a day, and eventually giving up and using Canonistack.
<wgrant> cjwatson: I do. I can give it a run through
<wgrant> Mine's mitaka but the API isn't completely different so should be good enough
<cjwatson> That'd be very welcome, thanks
<cjwatson> Have we done similar staging adjustments before?  I guess we must have done when deploying this in the first place
<wgrant> Not since then.
<wgrant> I've been putting it off for years but I guess we should probably fix it up.
<cjwatson> Oh, in fact unittest2 1.1.0 must be fine - I upgraded it in my twisted-16.5.0 branch.
#launchpad-dev 2018-01-05
<frankban> cjwatson: hey, is it possible to get a buidl to run in lp? https://launchpad.net/~yellow/+archive/ubuntu/theblues-unstable/+build/14218753
<cjwatson> frankban: Is it security-critical?
<frankban> cjwatson: no it's not
<cjwatson> frankban: OK, it would be best for it to wait until we have the build farm back up and running generally then
<cjwatson> sorry for the inconvenience
<frankban> cjwatson: no problem, do you have a date already? 9th?
<cjwatson> frankban: Hopefully earlier but it's hard to say yet
<frankban> cjwatson: ok ty
