[01:25]  * mwhudson takes a late lunch break
[03:28] <wgrant> OOPS-1535ED144
[03:29] <wgrant> https://edge.launchpad.net/ubuntu/karmic/i386/cpp-3.4 reproducibly OOPSing -- what's the traceback on that?
[03:32] <lifeless> 10509/lib/lp/soyuz/browser/../templates/distroarchseriesbinarypackage-index.pt object at 0xe60c850>, 'isRedirectInhibited')
[03:32] <lifeless>   Module zope.traversing.adapters, line 52, in traverse
[03:32] <lifeless>    - __traceback_info__: (<zope.browserpage.metaconfigure.SimpleViewClass from /srv/edge.launchpad.net/edge/launchpad-rev-10509/lib/lp/soyuz/browser/../templates/distroarchseriesbinarypackage-index.pt object at 0xe60c850>, 'isRedirectInhibited', [])
[03:32] <lifeless> LocationError: (<zope.browserpage.metaconfigure.SimpleViewClass from /srv/edge.launchpad.net/edge/launchpad-rev-10509/lib/lp/soyuz/browser/../templates/distroarchseriesbinarypackage-index.pt object at 0xe60c850>, 'isRedirectInhibited')
[03:33] <wgrant> Oh, that one.
[03:33] <wgrant> Thanks.
[03:38] <lifeless> wgrant: de nada
[03:38] <lifeless> popping out for a bit
[03:50] <thumper> wgrant: know about that?
[03:50] <thumper> wgrant: I had that on a team page to add a member
[03:52] <wgrant> thumper: General issue with anything that isn't a LaunchpadView.
[03:52] <thumper> ah...
[03:52] <wgrant> I saw discussion about it somewhere.
[03:52] <wgrant> It's known by foundations/registry, at least.
[03:54] <thumper> cool
[06:42] <mwhudson> thumper: i think i've unexpectedly fixed https://bugs.edge.launchpad.net/launchpad-code/+bug/340295
[06:43] <mup> Bug #340295: exceptions.AttributeError: 'NoneType' object has no attribute 'write' <codehosting-ssh> <oops> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/340295>
[07:41] <thumper> mwhudson: cool. How?
[08:15] <adeuring> good morning
[09:05] <mrevell> Morning
[09:46] <mwhudson> thumper: by fixing https://bugs.launchpad.net/bugs/335156
[09:46] <mup> Bug #335156: "not allowed to execute..." message sent over ssh stdout channel <Launchpad Bazaar Integration:In Progress by mwhudson> <https://launchpad.net/bugs/335156>
[10:02] <deryck> Morning, all.
[10:04] <maxb>   File "bootstrap.py", line 151, in <module> PYTHONPATH=ws.find(pkg_resources.Requirement.parse('setuptools')).location)
[10:04] <maxb> AttributeError: 'NoneType' object has no attribute 'location'
[10:04] <maxb> wgrant: ^^^ Is that the python2.6 distribute intermittent error you have mentioned in the past?
[10:05] <wgrant> maxb: That's one aspect of it, yes.
[10:05] <wgrant> It manifests itself in around three different ways.
[10:05] <wgrant> Or none at all.
[10:05] <wgrant> Depending on $UNKNOWN.
[10:07] <maxb> mm. lovely
[10:08] <wgrant> maxb: Oh, 2.6? It happen(s|ed) with 2.5 sometimes too.
[10:16] <maxb> ah. never had that happen to me so ar
[10:16] <maxb> *far
[10:17] <wgrant> I haven't had it happen for a while.
[10:17] <wgrant> So maybe it's fixed now.
[10:17] <maxb> yet I've just had it happen for the first time :-/
[10:18] <wgrant> But 2.6?
[10:37] <henninge> jtv1: while I have you here alive and kicking, can you look at this if it looks sane? Looks almost too simple to me  ...
[10:37] <henninge> http://paste.ubuntu.com/395545/
[10:38] <henninge> jtv: I moved findProductSeries into Branch
[10:39] <henninge> jtv: also, I assume that these imports are *not* published elsewhere and set the branch.owner to be the importer.
[10:40] <jtv> henninge: templates don't have the distinction... effectively they're always published.
[10:40] <henninge> jtv: yes, I was just wondering about that ....
[10:40] <jtv> I'd pass True, but purely as a matter of form.
[10:42] <jtv> But yes, that looks pretty much alright...  assuming "tarball" is the string of contents of the tarball.
[10:42] <henninge> jtv: it is
[10:43] <jtv> henninge: the findProductSeries method isn't currently in IBranch, is it?
[10:48] <henninge> jtv: yes, I moved it there. I found it odd importing the BranchJobSource here and it really is a method if the branch, isn't it?
[10:48] <henninge> jtv: I did the same with ...
[10:48]  * henninge looks it up
[10:49] <henninge> providesTranslationFiles()
[10:49] <jtv> henninge: to me it looks more as if it should be a method of ProductSeriesSet, if there is such a beast.
[10:49] <henninge> jtv: hm, that is the other alternative, I admit
[10:49] <jtv> There is such a beast.
[10:50] <henninge> jtv:  findHasBranch ?
[10:50] <jtv> It's going to be ugly pigeonholing this under one part of LP when it's clearly a bridge between Code and Translations, with one foot in Registry.
[10:50] <henninge> findHasTranslationsBranch and leave out the parameter
[10:50] <jtv> findTranslationImportersForBranch?
[10:51] <henninge> huh?
[10:51] <jtv> findTranslationConsumersForBranch?
[10:51] <henninge> better, Importers has been used too many times
[10:51] <henninge> findRelatedBranch ?
[10:52] <henninge> findRelatedTranslationsImportBranch
[10:54] <jtv> henninge: one part I probably just don't know enough about...  why do you have a seemingly generic function for finding productseries related to a branch, with a parameter saying what behaviour you want?  Is there more than this one use-case that needs to call the same function?
[10:55] <henninge> jtv: not yet, but this is just following a simple database fk relation, so I found it a generic problem plus a filter.
[10:56] <henninge> jtv: oh no, the parameter was there for a different reason!
[10:56] <jtv> ?
[10:56] <henninge> jtv: to enable "force translation imports" behaviour.
[10:57] <jtv> oic
[10:57] <henninge> jtv: we need to look at all series for that, not just those that have translation imports enabled.
[10:57] <jtv> I still say that's the wrong thing to do though.
[10:57] <henninge> and I inverted the meaning of the parameter to make it more general
[10:58] <henninge> what?
[10:58] <henninge> jtv: what is the wrong thing?
[10:58] <jtv> I still say it's the wrong thing to let people request this on the productseries and then force it on any productseries that uses the same branch.
[10:58] <henninge> ah
[10:59] <henninge> hm, not sure it really works that way
[10:59] <jtv> It should be either an action in the branch UI (not my favourite way to do it) or it should force imports only on the productseries you request it on.
[10:59] <jtv> It doesn't currently work that way, and I'm saying that's wrong.
[10:59] <henninge> that does sound wrong and I was not aware of that.
[10:59] <henninge> I thought it did the filtering in code
[10:59] <jtv> We discussed a few weeks back.
[11:00] <jtv> The "force" flag really needs a productseries argument, not a boolean
[11:04] <henninge> jtv: yes, you are right. i don't remember talking about it, though.
[11:04]  * jtv resists temptation to also claim that henning borrowed money from him on that occasion
[11:05] <henninge> lol
[11:05] <jtv> It was weeks ago.
[11:06] <henninge> jtv: ok, I don't want to fix both things in the same branch. I'll just try to avoid making it harder than necessary.
[11:06] <jtv> IIRC a solution could be to make the browser code pass the productseries as an argument when creating the IRosettaUploadJob, have that productseries' id stored in the BranchJob.json_data instead of just the boolean flag, and then if it's present, only upload to the given productseries (regardless of setting)
[11:06] <henninge> jtv: do we have a bug for that?
[11:06] <jtv> I don't think so.
[11:07] <jtv> No wait, I think I would've filed one.
[11:07] <jtv> Hang on.
[11:07] <henninge> yes, I would expect ... ;)
[11:07] <jtv> bug 521095
[11:07] <mup> Bug #521095: One-time import acts on all series for the branch <code-integration> <Launchpad Translations:Triaged> <https://launchpad.net/bugs/521095>
[11:15] <henninge> jtv: so all we need is a method to get all product series that have imports enabled on a specific branch.
[11:15] <jtv> henninge: yup, that's what I thin
[11:15] <jtv> k
[11:15] <henninge> jtv: and I agree, it would fit best on the the set.
[11:16] <jtv> \o/ then we _all_ agree!  :-)
[11:16] <henninge> jtv: I don't like to introduce a new term by using "Consumers"
[11:16] <henninge> though
[11:16] <jtv> there's that.
[11:17] <jtv> findByTranslationsImportBranch?
[11:17] <henninge> cool
[11:17] <henninge> jtv: yup, we'll take that.
[11:18] <henninge> jtv: I'll see if i can fix both bugs after all. I am just wondering about affected tests.
[11:19] <jtv> henninge: if an existing test should break, hopefully all that's needed is to change the import setting on a productseries.
[11:37] <deryck> adeuring, hi.  Since you did the patch sniffing work... is Bug #538219 easy to fix?
[11:38]  * adeuring is looking
[11:39] <adeuring> deryck: yes, that should be easy to fix.
[11:39] <deryck> adeuring, ok.  I'll mark it high and stick on our easy bugs backlog then.
[11:40] <adeuring> deryck: sure, it sould be easy to fix it this cycle
[11:41] <deryck> adeuring, excellent.  thanks.
[11:43] <wgrant> The quick fix is to change a hack in lp.services.mime which overrides .debdiff to text/plain.
[13:14] <kfogel> adeuring: for bug #534736 ("patch attachments portlet should appear above regular attachments portlet on a bug page"), all tests pass without any changes other than the code change itself.  Is this the sort of thing that needs a new test?
[13:14] <mup> Bug #534736: patches portlet should appear above attachment portlet <trivial> <ui> <Launchpad Bugs:In Progress by kfogel> <https://launchpad.net/bugs/534736>
[13:15] <kfogel> adeuring: Also, should I get UI review on an ordering change like this?
[13:16] <kfogel> intellectronica: see above questions to adeuring; if you're there and can answer, please do :-).
[13:20] <adeuring> kfogel: I think a small addition to an existing page test would be good for this change
[13:20] <adeuring> kfogel: and I am not sure if this really requires a UI revoew ;)
[13:20] <kfogel> adeuring: thanks.  I'll look for a test.
[13:28] <kfogel> adeuring: hmmm.  I'm not sure how to test this.  Usually when testing a portlet, we use find_portlet().  But in this case, it's the order in which two portlets appear that we care about.
[13:29] <adeuring> kfogel: something like peint extract_text(browser.contents), then ellipises (?) to skip the unintersting text?
[13:29] <kfogel> adeuring: aaaah.  gotcha, that makes sense.
[13:29] <kfogel> thanks
[13:32] <deryck> gmb, hi.  Have you seen Bug #538097?
[13:32] <mup> Bug #538097: +storeblob fails with "500 Internal server error" on production (works on edge) <apport-collected> <lucid> <Launchpad Bugs:Confirmed> <apport (Ubuntu):Invalid by pitti> <https://launchpad.net/bugs/538097>
[13:33] <kfogel> adeuring: I'm still a little confused about the difference between doc/ tests and stories/ tests.
[13:33] <deryck> gmb, related to the filebug store blob work maybe?
[13:33] <kfogel> adeuring: they appear to be the same kind of thing.  What is the distinction?
[13:34] <adeuring> kfogel: storeis are intended to, well "tell stories from a user's perspective". They are not necessarily comprehensive tests. But we have quite often tests of details there tooo
[13:34] <kfogel> adeuring: oh, so the difference is purely conceptual -- not technical.
[13:35] <adeuring> kfogel: mostly. In doc, you can more easily do also things like run tests with another DB user
[13:35] <gmb> deryck: Ihadn't seen that. I'll look into it.
[13:37] <deryck> gmb, I put a card on the board for you.  Since this is blocking Lucid bug reports we should move it through quickly... if you need help from me, just ping.
[13:37] <gmb> deryck: Righto, thanks
[13:52] <gmb> deryck: Interestingly, all the OOPSes I'm seeing so far for +storeblob today are of this nature: https://lp-oops.canonical.com/oops/?oopsid=OOPS-1535E1487
[13:52] <deryck> gmb, looking....
[13:53] <gmb> deryck: Security machinery gone maaaaaad?
[13:53] <deryck> gmb, interesting.  so apport needs to set referrer header?
[13:53] <gmb> deryck: Well, I can't be sure yet, need to test.
[13:54] <gmb> But that's my working hypothesis, yes.
[13:54] <deryck> gmb, ok.  and I'm curious too why this is an issue for lpnet but not edge?
[13:55] <gmb> deryck: Still investigating whether it actually isn't an issue for edge too.
[13:56] <deryck> gmb, ok, cool.  thanks for looking into it.  sorry to sideline your checkwatches work
[13:57] <gmb> deryck: No worries. I think I might need to get an up-to-date Lucid vm running to test this properly; I'll get that started and go back to CW until it's ready.
[13:57] <deryck> gmb, that works
[14:15] <intellectronica> kfogel: i'm back. do you still need help?
[14:16] <kfogel> intellectronica: no, adeuring helped me.  Thanks.
[14:25] <kfogel> adeuring: having trouble getting this test text to match.  The new test is: http://paste.ubuntu.com/395636/   And the failure is: http://paste.ubuntu.com/395637/
[14:25] <kfogel> adeuring: I'm fiddling with lots of different combinations of whitespace and "..."  but no luck yet.
[14:26] <adeuring> kfogel: did you try to start the expected text with "Bug #11"?
[14:26] <mup> Bug #11: Rosetta says there are untranslated strings, but it isn't <Launchpad Translations:Fix Released by carlos> <https://launchpad.net/bugs/11>
[14:26] <adeuring> i mean; instead of the ellipsis
[14:26] <adeuring> erm, before the ellipsis
[14:28] <henninge> kfogel: what he means is: You cannot start with an ellipsis, there must be some test first.
[14:28] <henninge> adeuring: :-P
[14:29] <kfogel> adeuring, henninge: thank you!
[14:30] <sinzui> didrocks: ping
[14:30] <didrocks> sinzui: hey
[14:31] <sinzui> didrocks: gpgkeys are not visible over anon api.
[14:31] <sinzui> didrocks: Is this intentional?
[14:32] <didrocks> sinzui: no, it's not. as jml finished the change and I was able to see them in +apidoc, I don't know what happened
[14:32] <danilos> kfogel, that initial text can be as simple as "<..." (i.e. opening < of a <html> tag)
[14:32] <kfogel> danilos: *nod*
[14:32] <danilos> (#11 bug mention pinged me :)
[14:32] <kfogel> henninge, adeuring, danilos: test passes now, thanks.
[14:32] <kfogel> danilos: heh
[14:32] <sinzui> didrocks: It needs a anon security function and a 5 line test to verify anon users can access it
[14:33] <didrocks> sinzui: oh, to anynomous gyus you mean?
[14:33] <didrocks> sinzui: but still, I'm logged into LP and https://edge.launchpad.net/+apidoc/ is only has we were anonymous?
[14:34] <didrocks> (I don't see it there)
[14:34] <sinzui> didrocks: I do not think I should have to log in in my script to get a gpgkey that I could get by scraping the web site while not logged in
[14:35] <didrocks> sinzui: I agree, but my question wasn't that one:
[14:35] <didrocks> sinzui: I'm logged into LP, and I don't see the api in +apidoc
[14:35] <didrocks> (the gpg in the api)
[14:36] <didrocks> is it because I'm considered as being anonymous?
[14:36] <sinzui> interesting, I read the api from the page.
[14:36] <didrocks> erf, ctrl + R for the win
[14:37] <sinzui> didrocks: https://edge.launchpad.net/+apidoc/#gpg_key
[14:37] <didrocks> sinzui: right, the cache wasn't refreshed apparently
[14:37] <sinzui> didrocks: you can see the collection listed on https://edge.launchpad.net/+apidoc/#team
[14:37] <didrocks> sinzui: well, I can do that if you point me to the right doc, but I would prefer to have my ssh patch which prevents me release Quickly 0.4 to be reviewed first and not really have the time to fix that before Friday
[14:38] <sinzui> didrocks: I can do it, I just wanted to be certain that the anon was intentionally omited
[14:39] <didrocks> sinzui: no no, it wasn't intentional
[14:39] <didrocks> sinzui: same fix has to be done to the ssh key I guess
[14:41] <sinzui> yes, I think every object that we have to write a browser:url directive for must get an anon security function, because this is the first time the object is published
[14:47] <danilos> jtv, what was the page that describes setting up a local buildfarm for translations?
[14:47] <jtv> danilos: it's linked from dev.launchpad.net/Translations
[14:47] <jtv> under Technical topics
[14:48] <jtv> last entry there
[14:48] <danilos> jtv, https://dev.launchpad.net/Translations/BuildTemplatesOnLocalBuildFarm
[14:48] <danilos> ?
[14:48] <jtv> yup
[14:48] <danilos> jtv, does that integrate any discoveries henning has made? :)
[14:49] <jtv> danilos: I may have copied some small things, but mainly I refer to the page he's written.
[14:50] <jtv> He documented how to get the slave running in a chroot, which imho is infinitely more useful than the local install we used to have.
[14:51] <jtv> danilos: I'm not aware of any inconsistencies between the two
[14:51] <danilos> jtv, cool, thanks
[14:52] <kfogel> deryck: I see bug 538226 and bug 538219 in the backlog; they look like good ones for me to grab, when I get back to coding, so I'll just pick one when ready.
[14:52] <mup> Bug #538226: "What is a patch?" links to wrong help page <help> <trivial> <ui> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/538226>
[14:53] <gmb> deryck: I've just confirmed pitti's reproduction of the bug in https://bugs.edge.launchpad.net/ubuntu/+source/apport/+bug/538097/comments/29
[14:53] <mup> Bug #538097: +storeblob fails with "500 Internal server error" on production (works on edge) <apport-collected> <lucid> <oops> <Launchpad Bugs:Triaged> <apport (Ubuntu):Invalid> <https://launchpad.net/bugs/538097>
[14:53] <gmb> deryck: Doesn't occur on edge.
[14:54] <gmb> deryck: At the moment I've no idea why that is, unless some security gubbins got CP'd to production.
[14:54] <deryck> gmb, hmmm, ok, interesting.
[14:54] <deryck> gmb, we should ask around about recent CPs.
[14:55] <gmb> deryck: Or perhaps there's some redirect happening with request to https://edge.launchpad.net/+storeblob (guessing)
[14:55] <gmb> deryck: Simple work around is to try posting to http://launchpad.net/+storeblob; the http->https redirect adds a referrer header.
[14:55] <gmb> deryck: So we can pretty much confirm that that's the problem.
[14:56] <salgado> gary_poster, ^
[14:56] <gary_poster> reading back...
[14:56] <salgado> looks like the change to not accept POSTs without a referrer broke apport: https://launchpad.net/bugs/538097
[14:56] <mup> Bug #538097: +storeblob fails with "500 Internal server error" on production (works on edge) <apport-collected> <lucid> <oops> <Launchpad Bugs:Triaged> <apport (Ubuntu):Invalid> <https://launchpad.net/bugs/538097>
[14:57] <gary_poster> salgado: ah :-(
[14:57] <salgado> gmb, ^
[14:57] <deryck> hey, at least we know what happened now.
[14:58] <gmb> \0/
[14:58] <deryck> salgado, thanks for pointing this out to us.
[14:58] <sinzui> matsubara: I cannot find the bug that is marked as bad for the registry: http://people.canonical.com/~lpqateam/test-plan-report-10.03.html . I do not see anything related to my team on https://bugs.edge.launchpad.net/launchpad-project/+bugs?field.tag=qa-bad
[14:58] <gmb> (But subdued, becase, hey, bug)
[14:58] <gmb> gary_poster, salgado: I'll update the bug report; want me to re-target to foundations?
[14:58] <gary_poster> gmb: yes, thanks.
[14:59] <gary_poster> gmb: please don't go int ospecifics; this is a security bug after all
[14:59] <gary_poster> '
[14:59] <matsubara> sinzui, it's fix released, that's why it doesn't show up in https://bugs.edge.launchpad.net/launchpad-project/+bugs?field.tag=qa-bad
[14:59] <matsubara> (i.e. default search doesn't show fix released bugs)
[14:59] <gmb> gary_poster: Okay. Should I mark it as such? It' got a lot of subscribers already so there may not be much point.
[14:59] <gary_poster> Although perhaps that's closing the barn door after the animals have all escaped...
[15:00] <gary_poster> gmb: no.  just assign to foundations with no explanation, perhaps.  I'll deal with it...somehow. :-)
[15:00] <gmb> gary_poster: Ok.
[15:01] <deryck> gmb, and ping pitti off list/channel about it, just so he knows what's up
[15:02] <gmb> deryck: I think gary_poster's already taking care of that.
[15:02] <deryck> gmb, ok, cool
[15:02] <deryck> gmb, and let's do our call 15 after.  To give us time to close out some of this.  (and me more coffee ;))
[15:02] <deryck> gmb, cool?
[15:03] <gmb> deryck: Sure. Besides, I need tea.
[15:05] <gary_poster> deryck, gmb: I don't have a reply from pitti on irc.  Is he known to be around-ish (i.e., he will be back soon) or should I just shoot him an email and look for another resource?
[15:06] <gmb> gary_poster: Have you tried on the internal server?
[15:06] <gary_poster> yeah, he just got back thanks
[15:09] <sinzui> ‏‎mars: is this bug still valid bug 435832
[15:09] <mup> Bug #435832: Launchpad email verification uses sso server template <post-3-ui-cleanup> <ui> <launchpad-web:Triaged> <https://launchpad.net/bugs/435832>
[15:09] <adiroiban> EdwinGrubbs, sinzui: do you know what is the revision number where the referrer/next_url mixin was introduced?
[15:10] <sinzui> adiroiban: no, but I think It landed last week
[15:11] <adiroiban> ok. thanks. I will search the log and the code
[15:17] <adiroiban> sinzui: do you have any hints how / where should I look for that mixin?
[15:18] <salgado> adiroiban, tests are passing now; I've submitted your branch again
[15:19] <adiroiban> salgado: thanks! Can you please run the test using screen as some tests were not related to „active” attribute and they were still failing on ec2-test
[15:20] <sinzui> adiroiban: ReturnToReferrerMixin
[15:20] <salgado> adiroiban, too late, but you don't have to worry now -- if there are spurious failures I'll fix them and then land your branch
[15:20] <sinzui> from canonical.launchpad.webapp.launchpadform.ReturnToReferrerMixin
[15:20] <sinzui> ^ adiroiban
[15:21] <adiroiban> sinzui: thanks!
[15:22] <adiroiban> sinzui: ReturnToReferrerMixin is not working for my bug
[15:23] <adiroiban> as the referrer url can be made invalid by the changes from the form
[15:24] <sinzui> :(
[15:26] <adiroiban> also looking at ReturnToReferrerMixin, it looks like it is not checking if the referrer URL is identical with the current URL
[15:26] <adiroiban> and preventing a redirection to the same page
[15:49] <kfogel> adeuring: https://code.edge.launchpad.net/~kfogel/launchpad/534736-patches-portlet-first/+merge/21377  (when you get a chance)
[15:51] <adeuring> kfogel: sure, let me first do some organsational stuff for the mini sprint. I have to use a travel agency that is absolutely unresponsvie to emails ;)
[15:51] <kfogel> adeuring: sure.  You know, I've really found that the travel agencies cost more time than they save.
[15:52] <adeuring> kfogel: you have point there...
[16:04] <adeuring> kfogel: r=me
[16:05] <kfogel> adeuring: thank you
[16:07] <kfogel> adeuring: I'm going to go with ui=none, unless you counsel otherwise.
[16:07] <adeuring> kfogel: I think that's fine.
[16:10] <kfogel> adeuring: I just got a testfix mode failure:
[16:10] <kfogel> Command failed!
[16:10] <kfogel> All lines of log output:'Commit message [[r=abel][bug=534736][ui=none] On a bug page,\n\tlist patches before non-patch attachments.] does not match commit_re [(?is)^\\s*\\[testfix\\]\\s*\\[(?:release-critical=[^\\]]+|rs?=[^\\]]+)\\]]'
[16:11] <kfogel> adeuring: ...from PQM.  Any idea what's up?
[16:11] <adeuring> kfogel: seems that buildbot failed recently
[16:11] <adeuring> that's not related to your branch
[16:42] <jtv> bigjools: I'm solving the UI's inability to deal with non-Soyuz buildfarmjobs by adding some interfaces and templates...  wgrant turned out to be thinking in the same direction, as per our discussions this weekend.  How would you feel if I added browser & templates directories to lib/lp/buildfarm?
[16:43] <bigjools> jtv: I would be against that
[16:43] <bigjools> but you could persuade me
[16:43] <jtv> bigjools: there's not a lot of the stuff now (after some simplification) but it'd be a more appropriate place I think.
[16:44] <bigjools> jtv: we already have lp.buildmaster, or are you talking about a new module?
[16:44] <jtv> bigjools: sorry, lib/lp/buildmaster is what I meant
[16:46] <bigjools> jtv: ok, the /builders and builder-related pages could all be moved there
[16:46] <jtv> phew :)
[16:46] <jtv> Not that I'm looking forward to the job, but the end result seems more desirable.
[16:46] <jtv> This sort of validates my sanity.  :)
[16:46] <bigjools> jtv: I'd like to see this discussed on the mailing list though
[16:46] <bigjools> so I can see more details
[16:46] <jtv> bigjools: sure.  Still waiting for responses to this weekend's design proposal though.
[16:47] <jtv> (hint, hint ;-)
[16:47] <bigjools> ah hrm yes
[16:47] <bigjools> jtv: the refactoring of the "name" stuff is a good plan but I need to re-read your email to get a better handle on things
[16:48] <jtv> I should add that the complexity of the existing design became a bit more explicit with a branch I just landed:
[16:48] <bigjools> jtv: I don't know why that cross check is so complicated either
[16:48] <bigjools> but it's there to protect against builders appearing and disappearing with random builds
[16:48] <jtv> Heretofore it was assumed that one buildfarmjob's "self.build.id" might be completely unrelated to another's, since their self.build objects might be in different db tables.
[16:49] <bigjools> and to prevent the wrong build being assigned to a source
[16:49] <jtv> Well, the buildqueue check would do that—barring determined attack (which would have only a tiny chance of messing things up anyway aiui)
[16:49] <bigjools> well buildqueue will be common
[16:49] <bigjools> I can't remember the current format, it names directories buildid-buildqueue-id-something doesn't it?
[16:50] <bigjools> I suspect it was originally belt and braces as you say
[16:50] <jtv> that, grumble, depends on the fritzin' type of the confounded thing
[16:51] <jtv> No directories are involved that I know of, but Build uses <Build.id>-<BuildQueue.id>
[16:51] <jtv> Sorry, a binary package build uses that.
[16:51] <jtv> Then there's other types that are encouraged to use <BuildBase.id>-<BuildQueue.id>, where BuildBase doesn't really have an id but any of its implementing leaf classes will.
[16:51] <jtv> And then of course there's us folks who don't have a self.build
[16:52] <jtv> ...so we use <Branch.name>-<BuildQueue.id> instead, mainly to help debug.
[16:52] <jtv> I'm suggesting to use <BuildQueue.id>-<hard-to-guess-string>
[16:53] <jtv> ...without going into any specifics of different build-farm jobs at all.
[16:55] <jtv> bigjools: wgrant, bless his toes, said something like "this dates back to the beginning of time, remember."  I would like to state once again for the record that I am not that old.
[16:55] <jtv> I did mention that I could ask barry though.
[16:55] <bigjools> jtv: you really should have a build table
[16:55] <bigjools> for history
[16:55] <bigjools> I talked about this with noodles
[16:56] <bigjools> that doesn't preclude this change though
[16:57] <jtv> well, there's all this talk of different ways we could store history...  what I'm doing with the UI atm will facilitate that, I think.
[16:58] <jtv> I'm using inheritance between interfaces to achieve a kind of polymorphism in displaying things, assuming I'll always get the view for the most-specific applicable interface.  Is that bad?
[17:01] <bigjools> jtv: once your job is finished, there will be no permanent record of it.  You need a build table so we can see the history of a builder.
[17:03] <jtv> bigjools: I know, yes.  But as you say that doesn't preclude the simpler slave build id, and I think the UI work is worthwhile regardless as well because it gives us a base for having specific UI (elements) for different types of build record.
[17:05] <bigjools> jtv: did you discuss that with noodles?
[17:06] <jtv> bigjools: no, not since the weekend
[17:09] <jtv> bigjools: I'm not proposing to implement a full UI here, just taking away breakage from "buildfarm == soyuz" assumptions.
[17:09] <jtv> But it does have useful little things like a link formatter for builds.
[17:10] <jtv> Taking some logic out of the TAL.
[17:11] <jtv> Hmm...  for the record, I did not mean to imply that the TAL needs to be less logical.
[17:12] <bigjools> jtv: it could be more <something> though :)
[17:17] <jtv> bigjools: you mean, less can be more?  :)
[17:18] <bigjools> less is more - it's my favourite pager
[17:38] <rockstar> salgado, hep me! I can't build. http://pastebin.ubuntu.com/395727/
[17:39] <rockstar> Or maybe anyone from foundations can help. ^^
[17:40] <salgado> rockstar, I know absolutely nothing about gpgme. are you on Lucid?
[17:40] <rockstar> salgado, nope,  Karmic.
[17:46] <salgado> rockstar, looks like you don't have launchpad-dependencies installed
[17:47] <rockstar> salgado, Oh, crap.  I wasn't in my development chroot.
[17:47]  * rockstar facepalms.
[17:47]  * rockstar gets up to go on a walk and get re-focused
[18:25] <james_w> how do I run all the tests in lib/lp/code/stories/branches/?
[18:25] <beuno> james_w, ./test -tv code.stories.branches?
[18:26] <beuno> maybe, I don't remember it super well
[18:43] <james_w> beuno: nope, doesn't run any tests
[18:44] <james_w> nor lp.code.stories.branches or lib.lp.code.stories.branches or lib/lp/code/stories/branches/
[18:46]  * james_w tries a more brute-force way
[18:49]  * mwhudson_ watches his other machine fsck
[18:50] <mwhudson> bit odd though, it just rebooted
[19:06] <Ursinha-afk> sinzui: hi
[19:06] <sinzui> hi Ursinha
[19:08] <Ursinha> sinzui: matsubara-afk asked me about that bad item that was showing up in registry count, it seems that the script was considering salgado in registry team, but I've checked the config file and he was in the proper team; I've stopped and started the script again and the bad item is in its right place
[19:09] <sinzui> oh..yes I consider salgado being misclassified, but he wasn't last month so I assumed I was being confused
[19:09] <Ursinha> sinzui: that's weird because I've put him in the same team he was last month
[19:10] <Ursinha> this was spurious
[19:10] <sinzui> okay
[19:12] <Ursinha> mwhudson: hi, is bug 536486 really qa-ok? by your comment it seems it's still not working as it should..
[19:12] <mup> Bug #536486: Svn import of ruby taking 2.7G RSS <qa-ok> <Launchpad Bazaar Integration:Fix Committed by mwhudson> <https://launchpad.net/bugs/536486>
[19:13] <mwhudson> Ursinha: i think i hijacked the bug to link a branch to it inappropriately
[19:13] <mwhudson> (it turns out)
[19:14] <mwhudson> Ursinha: i'll fiddle things around
[19:14] <EdwinGrubbs> sinzui: ping
[19:14] <Ursinha> thanks mwhudson
[19:14] <sinzui> Hi EdwinGrubbs
[19:15] <jml> g'night floks
[19:16] <EdwinGrubbs> sinzui: on the mailing list, interest was expressed in removing the "Register a blueprint" link from the involvement portlet. The official_blueprints boolean appears to only be useful for showing/hiding that one link on the index page. Can I remove it from the form so it's impossible to edit, since "Register a blueprint" is always visible on blueprints.lp.net?
[19:17] <sinzui> EdwinGrubbs: I do not think so. I still think most people were confused by your proposal
[19:18] <sinzui> EdwinGrubbs: That link to enable blueprints is only for the project owner. He cannot find it to enable or disable it
[19:19] <sinzui> EdwinGrubbs: So if we remove the proposal for the owner see how to control blueprints on his project, how will he ever accomplish his task?
[19:19] <sinzui> EdwinGrubbs: I think the confusion is that jml and poolie thought you were going to let any person use that link
[19:20] <jml> sinzui, that's not what I was confused about, I think.
[19:20] <mwhudson> Ursinha: bugs fiddled, i think
[19:21] <EdwinGrubbs> sinzui, jml: it sounded like going to the blueprints tab is the desired place for the "Register a blueprint" link since registering a blueprint is not an important enough activity to be on the index page.
[19:22] <jml> EdwinGrubbs, yeah, that's what I meant.
[19:22] <jml> EdwinGrubbs, it's orthogonal to the other things you were discussing.
[19:22] <sinzui> jml:setting aside my dislike for blueprints, I see that some project like the app, and project owners should not have to hunt through the UI to enable it. conversely, project owners that are disappointed about the app should be able to disable it.
[19:23] <jml> sinzui, I suggest that we make it a little hard to enable blueprints for now.
[19:23] <sinzui> Why is blueprints different from ask a question or register a bug?
[19:23] <sinzui> jml: it is pretty fucking hard right now
[19:23] <jml> sinzui, because the app isn't very good.
[19:23] <jml> sinzui, heh heh
[19:24] <sinzui> In fact only someone who has setup a project before, probably in 2.0 can enable any application
[19:25] <sinzui> jml: EdwinGrubbs: I am looking at https://blueprints.edge.launchpad.net/subunit
[19:26] <EdwinGrubbs> it is odd how "Register a blueprint" appears twice
[19:27] <sinzui> ^ blueprints is not an official app. the Involvment link to register a blueprint be removed from the blueprint page?
[19:28] <sinzui> EdwinGrubbs: yes it is weird. I think is a UI inconsitency. The bugs team replaced the action buttons with involvement links. I updated the other apps to do the same, but I think the action link is more appropriate
[19:29] <sinzui> EdwinGrubbs: The bugs team went farther last month when they removed the entire bugs page if the app is not official
[19:30] <jml> yeah...
[19:30] <jml> sinzui, did you see the registry bugs I filed recently?
[19:30] <sinzui> jml: my email is littered with your email filings. I do not know which one you are referring to
[19:31] <jml> sinzui, me neither :)
[19:31] <jml> sinzui, don't worry about it then.
[19:31] <sinzui> jml: you want to say your project does not have a source package in ubuntu?
[19:32] <sinzui> jml: or The ajax ok/cancel button is rendered poorly when the primary context's title is edited
[19:34] <sinzui> jml: Project description and summary field could explain formatting rules
[19:34] <sinzui> which relates to a markup bug you moved to launchpad-web
[19:34] <jml> sinzui, let me find it. it's none of those. I think it's to do with enabling bugs for a project
[19:35] <sinzui> man, there are really old bugs related to that. I found them in malone
[19:35] <jml> oh wait, that's a malone thing
[19:35]  * sinzui assigned two to himself last week
[19:35] <sinzui> jml: I have a prototype single bug configuration screen
[19:36] <jml> anyway, we have a real inconsistency when it comes to enabling applications for a Launchpad project
[19:36] <jml> it looks and feels really sloppy.
[19:36] <sinzui> single screen that allows you to configure bugtracking
[19:36] <jml> sinzui, that'd be awesome
[19:36] <sinzui> I was very tempted to propose we abandon the bool states last week
[19:37] <jml> sinzui, I'd like more elaboration before you do that, but it sounds like the right line of thinking to me.
[19:37] <sinzui> jml: and it is hard to make apps behave consistently when some apps have lots of community involvement, and by the fact that two of our apps are not owned
[19:38] <jml> sinzui, I'm not sure that's the reason.
[19:39] <sinzui> How do you deal with requests from project owners to disable the branch tab and remove all the branches...including the ones not owned by the owner?
[19:40] <jml> sinzui, now _that's_ a more compelling reason :)
[19:40] <jml> sinzui, the short answer is "say 'no'"
[19:41] <sinzui> That is what we say. The project owner thinks of launchpad has a project hosting service
[19:41] <jml> sinzui, the longer answer is find out why they want it
[19:42] <sinzui> jml: In most cases it is because the owner prefers git or subversion, in fact since he thinks launchpad is a project hosting service, he want the code removed
[19:44] <jml> sinzui, you are saying that they don't actually have a benefit in mind when they ask for it?
[19:44] <sinzui> jml: yes
[19:45] <sinzui> I think some were concerned that launchpad always shows up first in google listing
[19:45] <jml> sinzui, hmm
[19:45] <sinzui> Others were worried about old code confusing users
[19:45] <jml> sinzui, there's a blog post in that.
[19:46] <sinzui> but the latter case is always addressed by switching to an improt
[19:46] <sinzui> import
[19:46] <jml> sinzui, I'm less concerned about the old code reason -- it's easy enough to update trunk to point at the right branch if you are a project owner.
[19:46] <jml> sinzui, right.
[19:50] <sinzui> EdwinGrubbs: I think there are two action regarding blueprints. One, do not add a link to configure blueprints. two I will find the bug about the blueprints tab and update it to include disabling the feature when it is not configured...and provide a link for the owner to enable it
[19:54] <EdwinGrubbs> sinzui: do I move the "enable blueprints" boolean back to the +edit form, or do I just make it inaccessible by removing the "configure blueprints" link?
[19:54] <sinzui> EdwinGrubbs: back to +edit.
[19:55] <EdwinGrubbs> ugh
[19:55] <sinzui> EdwinGrubbs: do you have a separate for for blueprints?
[19:55] <sinzui> separate form?
[19:56] <jml> anyway guys, I'm gone for real
[19:56] <jml> good chatting.
[19:57] <EdwinGrubbs> sinzui: yep, I have a separate form for all the services. Except for bugs, they are just one boolean. Though this is weird, I think it is better than searching through all the +edit fields.
[19:57] <sinzui> EdwinGrubbs: that is fine, great in fact.
[19:58] <EdwinGrubbs> sinzui: so, what do I do about the "configure blueprints" link and field then?
[19:59] <sinzui> EdwinGrubbs: We can add a link to the blueprint app menu for product. Make sure the permissions are launchpad.Edit
[19:59] <sinzui> EdwinGrubbs: It should be the first link in the list
[19:59] <sinzui> EdwinGrubbs: I am looking at my own page: https://blueprints.edge.launchpad.net/gdp
[20:01] <EdwinGrubbs> sinzui: although I am risking running the conversation in circles, it's odd to have the "configure blueprints" link have no effect on blueprints.launchpad.net, but it will show/hide the "Register a blueprint" link in the involvement portlet.
[20:02] <sinzui> EdwinGrubbs: It does have an effect, it make the Register a blueprint link appear in the involvement portlet
[20:02] <sinzui> EdwinGrubbs: And by landing your change, it make it easier to disable the blueprint root page like bugs does.
[20:03] <EdwinGrubbs> sinzui: but only on the index page. The blueprints.lp.net/$project page always shows "Register a blueprint". I haven't done any work on disabling the blueprint root page. Has that already landed? Maybe I just need to merge in RF again.
[20:05] <sinzui> EdwinGrubbs you are definitely confused is said "I" would find the blueprint bug and update it. You are NOT doing anything disabling the root
[20:05] <sinzui> EdwinGrubbs: Do not render the configure link blueprints link in the involvement portlet as jml asks.
[20:06] <sinzui> EdwinGrubbs: Do add the link as the first link the project blueprints menu
[20:06] <sinzui> EdwinGrubbs: If the second point bothers you, you can put the official_blueprints back on +edit
[20:07] <EdwinGrubbs> ok
[20:07] <sinzui> EdwinGrubbs: want to keep the scope of this exception out of your work
[20:08] <sinzui> Someone has to volunteer to change blueprints and maybe answers. We had no volunteers last month
[20:11] <james_w> wow, branch-rewrite.py imports windmill
[20:12] <mwhudson> james_w: launchpad is a tangle :(
[20:12] <EdwinGrubbs> sinzui: was that a request for volunteers?
[20:13] <sinzui> EdwinGrubbs: no, just a statement about the likely hood the blueprints or answers getting changed
[20:24] <wgrant> Are we in testfix?
[20:25] <wgrant> I have two "submitted to PQM" ec2 emails from 5 hours ago.
[20:25] <wgrant> Neither of them have actually landed.
[20:38] <wgrant> james_w: There's a bug for that branch-rewrite.py Windmill PATH issue.
[20:39] <james_w> good
[20:39] <wgrant> gary_poster: Since I guess Launchpad won't have bothered to email you, there is a new comment on https://bugs.edge.launchpad.net/launchpad-foundations/+bug/529348
[20:40] <wgrant> james_w: There is a workaround that I've been using for a while on https://dev.launchpad.net/Translations/BuildTemplatesOnLocalBuildFarm
[20:40] <james_w> I didn't need it to test this change, but thanks
[20:40] <wgrant> Ah.
[20:46] <gary_poster> wgrant: I had not received an email, oddly.  You know, you could have requested a patch.  Thanks for the comments.  The sarcasm is perhaps less warmly received.  :-)  I'll contact you privately, because I'm afraid I don't see how the webservice aspect can be addressed.
[20:47] <wgrant> Yeah, sorry about that. I was pretty displeased.
[20:49] <wgrant> gary_poster: (it's not odd that you haven't received an email; ~launchpad-security emails go through ~launchpad, which redirects all emails to launchpad-bugs@lists.c.c, which nobody reads)
[20:49] <gary_poster> ah :-/
[20:50] <wgrant> Why yes, this does mean that nobody gets automatically notified of new security issues.
[20:52] <NCommander> BjornT: re: raw source changelogs, I don't mind rewritting the code to use librarian, but I fear hitting the librarian to pull it on the fly and stick it in the UI might really put a strain on loading an Soyuz page that needs the raw changelog
[20:53] <lifeless> NCommander: why are you worried about that?
[20:53] <lifeless> NCommander: as in, do you have a metric that says its a concern?
[20:54] <NCommander> lifeless: no, but we keep the debian/copyright in the database. my knowledge of librarian is fairly limited (I'm still getting my around to LP source trees)
[20:54] <lifeless> so the librarian is pretty fast
[20:54] <lifeless> and there is a squid in front of it to boot
[20:54] <NCommander> lifeless: ah. I didn't want to be the one that causes a change to land that causes LP to DOS its own librarian :-)
[20:55] <lifeless> the librarian is just a big disk, with stuff named by hash, and a front end that takes urls in and serves the files from the disk.
[20:55] <lifeless> NCommander: bug attachments, all packages (ever), crashdumps - they all go in the librarian
[20:56] <wgrant> lifeless: But none of those are ever rendered in the UI.
[20:56] <lifeless> wgrant: no, but the load on the librarian is related to use, of which rendering is one
[20:56] <lifeless> the key questions are:
[20:56] <lifeless>  - how many loads per second are you expecting
[20:57] <lifeless>  - how many loads per second the librarian already does.
[20:57] <NCommander> lifeless: well, ideally, the SRP in Soyuz will pull raw source changelog directly.
[20:58] <NCommander> lifeless: we also need it for generating changelog diffs as part of native source sync
[20:58] <lifeless> so source sync is low frequency
[20:59] <lifeless> its (at most) one every 5 seconds - if every package changed every day
[20:59] <dobey> is there a good way to getting bugs for API calls escalated?
[20:59] <lifeless> dobey: the most effective way is to submit a patch
[21:00] <lifeless> failing that try begging, and if that doesn't work, ask your manager :P
[21:00] <dobey> is there good documentation on making changes to the REST API bits? :)
[21:01] <lifeless> dobey: generally you don't need to change the REST API bits at all, just the object definitions. what is your bug?
[21:02] <dobey> lifeless: i haaven't filed the bug yet, as i wanted to understand more process first. but I want date filtering on {person,team}.{getMergeProposals,getRequestedReviews}
[21:02] <lifeless> ok, thats just an object change
[21:03] <lifeless> reflecction is used to export interface defintions to rest
[21:04] <dobey> ok
[21:05] <lifeless> so the bug belongs on the relevant team
[21:05] <dobey> not being a lp developer, i am not familiar with these things :)
[21:05] <lifeless> in this case, launchpad-code
[21:05] <lifeless> dobey: et moi
[21:05] <lifeless> dobey: anyhow, launchpad-code, and if you haven't filed it, I wouldn't even consider escalation yet :P
[21:06] <dobey> lifeless: i'm just wondering what the process is :)
[21:16] <henninge> wgrant: your branches passed ec2 testing but did not land because of testfix. They are in pqm now.
[21:16] <henninge> testfix mode
[21:17] <wgrant> henninge: Ah. Thanks.
[21:17] <elmo> I'm getting unexpected form data trying to update bugs in LP, specifically using +editstatus slider
[21:17] <elmo> is that a  known thing?  this is on prod
[21:18] <wgrant> elmo: You block referers?
[21:19] <elmo> wgrant: yeah
[21:20] <wgrant> elmo: LP now hates you.
[21:20] <wgrant> https://bugs.edge.launchpad.net/launchpad-foundations/+bug/529348
[23:32]  * mwhudson lunches