[00:00] <maxb> gah. /me carefully follows the instructions on what to write in the email to contributor-agreement@canonical.com.... and then forgets to actually attach the pdf
[00:01] <mwhudson> thumper: when i was an undergrad, we had a "rashers of bacon consumed" league table in our house for a term
[00:01] <thumper> mwhudson: heh
[00:02] <mwhudson> it got a bit silly
[00:09]  * thumper is making a quadruple bacon egg and cheese muffin, well, two muffins
[00:10] <thumper> the bacon had to be used
[00:10] <thumper> it would be a shame to throw it out
[00:10] <thumper> I only realised after it went in the pan that I _could_ have frozen some
[00:19] <ajmitch> such a thing to regret, having too much bacon
[01:07] <lifeless> Bacon Explosion!
[01:07] <lifeless> DoIt
[01:18] <thumper> wgrant: your announcement method rename fix is landing now
[01:19] <wgrant> thumper: Thanks.
[01:34] <maxb> Is there any good way to produce a summary list of failing tests?
[01:40] <mwhudson> man concurrency is hard :(
[01:41]  * mwhudson gives up on it for now and has lunch instead
[02:07] <wgrant> thumper: Does PQM hate me, or is it still just really slow?
[02:08] <spiv_> PQM is an equal opportunity hater.
[02:19] <spm> wgrant: you've got a branch waiting to land via pqm?
[02:19] <spm> yes.
[02:19] <wgrant> spm: I presume so.
[02:20] <spm> wgrant: pqm is currently stopped due to a CP in progress, sorry. please to be waiting ~ 4 hours.
[02:20] <wgrant> But it's all still private, along with buildbot.
[02:20] <wgrant> spm: Ah, right. Thanks.
[02:21] <maxb> CP ?
[02:21] <wgrant> Cherrypick.
[02:23] <spm> maxb: basically taking a revno that has already landed on one of the trees; merging it into the existing current build; run the full test suite. push that live where appropriate. Is only done for critically broken things.
[02:24] <wgrant> Or forgotten "What's new?" updates. Ehem.
[02:37] <maxb> How can I ask the test system for a list of tests in the order they will actually be executed? I tried --list and it gave me a list, but they don't seem to be executing in that order
[03:29] <maxb> --list-tests
[03:29] <lifeless> maxb: they get sorted to reduce churn on expensive test fixtures
[03:29] <lifeless> maxb: there isn't a defined order, as such.
[03:32]  * maxb crosses fingers and hopes this testrun actually manages to finish
[03:32] <maxb> It's not looking too bad actually (Python 2.5)
[03:35] <sidnei> maxb: glad to hear that!
[03:38] <maxb> 26 failures 19 errors out of some ~17000 tests so far
[03:45] <sidnei> not bad at all. reminds me of my templating branch. which, by the way, i need to bring up again. hopefully tomorrow :)
[04:05] <jtv> Hi folks, everything still running?
[04:06] <wgrant> sidnei: Which templating branch? The Chameleon one?
[04:19] <thumper> crap
[04:19] <thumper> ec2test I started before I ran away failued due to a trunk conflict
[04:19] <thumper> grr
[05:29] <jtv> thumper: buy a faster cloud
[05:32] <thumper> jtv: and why would that help?
[05:33] <jtv> thumper: so you can find out before you run away.
[05:34]  * thumper smacks jtv around for a stupid idea
[05:34]  * thumper is not in a good mood today
[05:34]  * jtv tries to look chipper and supportive, but can't keep the hurt look out of his eyes
[05:34] <thumper> jtv: I have no sense of humour today
[05:35]  * jtv chokes back obvious bad joke about Americans
[05:42] <jtv> mwhudson: the translations-to-bzr script is doing quite nicely...  it just exported translations for 18 productseries, skipped 1, and failed 4 because their branches weren't set up, all in 2 minutes 10 seconds.
[05:42] <jtv> I really ought to start skipping unchanged files, for that order-of-magnitude speed boost.
[05:42] <mwhudson> jtv: hooray
[05:43] <jtv> mwhudson: the dirty little secret there is that ddtp-ubuntu still breaks it because the transaction runs for too long and the database watchdogs kill it.  Fix has landed, but we won't CP it unless it becomes unavoidable.
[05:45] <jtv> mwhudson: would it be very hard, or evil, to create branches that give me "not a branch" errors?
[05:48] <thumper> anyone remember the view attribute for the new page titles?
[05:48] <jtv> thumper: not off the top of my head... but wasn't pagetitles.py also supposed to work?
[05:49] <thumper> yes, but... I'm going to add a comment to the top of pagetitles.py saying "stop bloody using this file!!!"
[05:49] <thumper> and I'd like to be nice and tell them what to use instead
[05:49]  * thumper goes hunting
[05:50] <thumper> hah
[05:50] <sidnei> wgrant: xactly
[05:50] <thumper> page_title
[05:50] <thumper> surprise!
[05:50] <jtv> *gasp*
[05:51] <sidnei> wgrant: looking for someone to pick that up and push forward (hint hint)
[05:53] <mwhudson> jtv-afk: no, not at all
[05:53] <mwhudson> hard, i mean
[05:54] <jtv> mwhudson: I guess though that the user may still have a branch sitting around locally, waiting to be pushed...
[05:55] <jtv> If I created the branch and populated it, and then the user pushed a different branch altogether, would the user's branch "win"?
[05:59] <lifeless> if they use --overwrite yes
[06:00] <jtv> So not an unsafe idea at all to create the branches... How would I do it?  Would be nice if DirectBranchCommit could do it.
[06:02] <mwhudson> jtv: you could create another branch type
[06:03] <mwhudson> jtv: and have them pulled from some known location
[06:03] <mwhudson> (a bit like import branches are now)
[06:03] <jtv> mwhudson: I do require that it be Hosted.  If it's another type, it won't be referenced in this field.
[06:03] <mwhudson> and not let anyone write to them on disk
[06:03] <mwhudson> (don't know if this would make sense)
[06:04]  * wgrant curses replication lag to death.
[06:04] <wgrant> It's particularly bad now that the bug page is AJAXy, as AJAX POSTs and PATCHes don't force further browser requests to the master.
[06:05] <lifeless> wgrant: file a bug
[06:05] <wgrant> There is a bug.
[06:05] <lifeless> jtv: I would hesitate to write to the users branch directl.y
[06:05] <lifeless> jtv: writing to your own branch the user can pull/merge from is conceptually clearer.
[06:05] <lifeless> Personally, I'd model it as: there is a user ~rosetta
[06:05] <jtv> lifeless: I already write to the user's branch, as per the user's wishes.  Question is whether I should create the bzr branch behind the user's "DB branch" if there isn't one.
[06:06] <lifeless> ~rosetta can write to any branch that the user has been given access to
[06:07] <lifeless> well, as long as they tell you the branch to branch from
[06:08] <jtv> They have already created the DB branch and configured it as the one I should write to.  But there isn't necessarily a real branch behind it yet.
[06:08] <lifeless> jtv: if there isn't a real branch, you would have to branch from somewhere
[06:08] <lifeless> jtv: thus my comment
[06:09] <jtv> lifeless: oic... basically an empty "prototype branch"?
[06:09] <lifeless> jtv: that said, I'm strongly inclined to consider a db branch without bzr data in it a configuration error
[06:09] <lifeless> jtv: no, nothing empty
[06:09] <jtv> Okay, near-empty?
[06:10] <jtv> Anyway, isn't a db branch without any bzr data what you get when you register a Hosted branch in LP?  It seems a bit pointless to require that users populate the branch.
[06:10] <jtv> (In this case)
[06:13] <jtv> lifeless: actually, why would I have to branch from somewhere?
[06:14] <lifeless> to get their content
[06:15] <lifeless> jtv: registering 'hosted branches in lp' is a bug, it causes lots of questions and confusion
[06:15] <jtv> In this case it's just what I want though, and if I could just create the bzr directory on the fly if needed, that'd be perfect for me.
[06:15] <lifeless> so whats the use case.
[06:16] <lifeless> I'm not understanding the desire to have a branch the user can't merge from
[06:16] <jtv> I don't understand... Why would the user not be able to merge from it?
[06:16] <lifeless> try this
[06:16] <lifeless> cd /tmp
[06:16] <lifeless> actually
[06:16] <lifeless> cd ~lp-repo
[06:16] <lifeless> bzr init --2a foo
[06:16] <lifeless> cd foo
[06:17] <lifeless> bzr commit -m "first post"
[06:17] <lifeless> bzr merge ../trunk
[06:17] <lifeless> [adjust paths for your environment]
[06:17] <jtv> The commit fails, of course.
[06:18] <lifeless> it shouldn't
[06:18] <jtv> There's no data in there yet.
[06:18] <lifeless> oh, add --unchanged there
[06:19] <jtv> Anyway, what you're trying to tell me is I can't merge branches without common ancestors?
[06:19] <lifeless> yes
[06:19] <lifeless> it goes deeper
[06:19] <lifeless> you can't merge files unless the files started at a common place
[06:19] <Ursinha> jtv, hi! :)
[06:19] <jtv> hi Ursinha!
[06:20] <Ursinha> jtv, do you have a few minutes after your discussion with lifeless?
[06:20] <jtv> Ursinha: very very few.  :)
[06:20] <jtv> Ursinha: if it's about the approval script failures, we're on it.
[06:20] <Ursinha> jtv, :P
[06:21] <Ursinha> jtv, actually no, it's about some weird timeouts
[06:22] <jtv> lifeless: so it'd be good for the user to choose the branch wisely... but in this case afaics having a branch that lives in its own universe is still a lot better than having one that produces nothing at all.
[06:22] <lifeless> jtv: I still don't understand the case
[06:22] <lifeless> what is the use case
[06:22] <jtv> lifeless: this is for daily translations exports.  "Pick a Launchpad-hosted branch and I'll commit daily snapshots of your translations to it."
[06:23] <jtv> lifeless: minimally, bzr is just used as an asynchronous transport here.
[06:24] <jtv> An alternative to ftp, almost.  Merging is slightly more advanced usage, but not everyone will even want that.
[06:24] <lifeless> jtv: thats fine; just check when they select the branch that it has been successfully mirrored once
[06:24] <lifeless> jtv: if they want an empty branch, they do 'bzr init lp:~person/project/trunk
[06:24] <jtv> lifeless: mirrored?  or pulled?  this works for Hosted branches only.
[06:25] <lifeless> jtv: copied from private hosting to http
[06:25] <lifeless> jtv: what I'm saying is: don't special case this in your code. Depend on them making the branch appropriately.
[06:25] <jtv> lifeless: sorry to be thick, but... private to whom?  And to what over http?
[06:25] <lifeless> it is, at worst, one command.
[06:26] <lifeless> jtv: hosted branches get scanned and published inside the server
[06:26] <lifeless> there is a flag written when this succeeds.
[06:26] <lifeless> I'm saying check that this flag has been set
[06:27] <lifeless> as its being set indicate the branch has been real for at least one puller cycle
[06:27] <jtv> lifeless: now I see...  That's good, thanks.  It's another way of avoiding these quiet failures.  I'll file a bug.
[06:31] <jtv> lifeless: I think they call the http-accessible hosting facility the "read-only area."
[06:32] <Ursinha> hi thumper
[06:35] <jtv> lifeless: bug 409686
[06:35] <mup> Bug #409686: Export branch should have real bzr branch attached <Launchpad Translations:Triaged> <https://launchpad.net/bugs/409686>
[06:36] <jtv> thumper: about those timeouts...  we see weirdness all over the place atm and suspect foundational problems.
[06:37] <jtv> sorry, not thumper, Ursinha
[06:37] <jtv> (I wonder how I could've made _that_ mistake...)
[06:39] <Ursinha> jtv, I've asked flacoste earlier today about those, questioning that that could be due to the storm update, but he said that was unlikely, and that we had changes in messaging sharing
[06:40] <Ursinha> and if I asked danilo about that... I don't, so I'm asking you :)
[06:40] <Ursinha> let me find some of the oopses
[06:41] <Ursinha> jtv, OOPS-1309F1091,OOPS-1312C1554,OOPS-1309F1091
[06:42] <Ursinha> the slowest query is select replication_lag(), that according to flacoste should be fast
[06:42]  * Ursinha curses the bot
[06:42] <Ursinha> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1312H1982
[06:42] <Ursinha> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1312C1554
[06:42] <Ursinha> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1309F1091
[06:51] <spm> wgrant: fyi. pqm reopened, so your landing should pass shortly
[06:51] <wgrant> spm: Thanks.
[07:12] <wgrant> spm: It has indeed just landed.
[07:12] <spm> \o/
[07:22] <thumper> I need to go make dinner
[07:22] <thumper> TTFN people
[08:51] <jml> hello
[08:59] <lifeless> hai
[09:00] <lifeless> jml: http://advogato.org/person/robertc/diary/108.html
[09:03] <jml> lifeless, \o/
[09:04] <lifeless> hudson is pretty sext
[09:18] <mrevell> Howdy
[09:19]  * maxb rejoices at running the testsuite all the way through for the first time on python 2.5
[09:20]  * maxb doesn't rejoice about it taking 5 hours though
[09:23] <wgrant> maxb: What are the stats?
[09:29] <noodles775> Great stuff maxb !
[09:29] <maxb> https://dev.launchpad.net/LaunchpadOnKarmic
[09:30] <maxb> wgrant: I've added a test summary ^
[09:30] <maxb> in brief - there's work to be done, but it could have been a lot worse
[09:31] <noodles775> maxb: 1328 tests ran?
[09:31] <noodles775> Hmm... It should be closer to 23k?
[09:31]  * noodles775 checks latest buildbot run.
[09:32] <wgrant> buildbot is still in the exclusive realm of Canonical employees :(
[09:32] <noodles775> 23741 tests.
[09:32] <bigjools> make check will run 23k tests
[09:33] <bigjools> if it doesn't, there's a problem with the tests
[09:33] <wgrant> That's getting close.
[09:34] <jml> wgrant: as in, buildbot visibility?
[09:34] <maxb> 23117 if you sum all the categories
[09:34] <wgrant> jml: Yes.
[09:34] <jml> :(
[09:34] <wgrant> maxb: That's what I got too.
[09:34] <wgrant> So, not too bad.
[09:34] <wgrant> I'm very surprised so many passed.
[09:34] <wgrant> how much of Zope did you have to poke?
[09:35] <maxb> I cherrypicked some upstream changes for zope.proxy and zope.security, and did an almightly bodge in zope.sendmail
[09:35] <wgrant> Ah, I shall check the branch.
[09:36] <maxb> oh, and a cherrypick for zope.app.security too
[09:37] <noodles775> maxb: sounds close (the buildbot run that ran 23741 tests was r9053).
[09:37] <maxb> r9053@devel ?
[09:37] <noodles775> Yep.
[09:38]  * maxb curses bzr's weird idea of revnos
[09:39] <wgrant> What's weird about it?
[09:40] <wgrant> apart from presumably being different to hg's.
[09:40] <jml> BjornT, you around?
[09:40] <BjornT> jml: yes
[09:41] <maxb> The way it bears no meaning whatsoever cross-branch
[09:41] <jml> BjornT, I was wondering about bug-branch linking appearing in the activity log.
[09:42] <jml> BjornT, ISTR you or someone on the bugs team fixing something in the scanner to make the linking appear inline with the bug comments, but that doesn't seem to be what's happening.
[09:43] <maxb> Ah right, so by happy coincidence my testrun was based on devel@r9053 too
[09:43] <BjornT> jml: no, we didn't fix it to appear inline, we just fixed it to actually appear in the activity log.
[09:43] <jml> BjornT, ahh ok.
[09:43] <jml> BjornT, and one doesn't imply the other, I take it.
[09:44] <BjornT> jml: right. we don't want all activity to appear inline, for example subscriptions. however, there are some things that definitely should appear inline, but we didn't have time to implement it.
[09:44] <jml> BjornT, ok, cool.
[09:44] <BjornT> jml: you think it would be useful to have branch linking being inline? there's always the question whether it's actually useful, or if it simply adds noise
[09:45] <noodles775> maxb: but that's your local branch of devel, you can easily check the log to see where you diverged from devel (or did you mean that you'd merged devel@r9053 before doing running tests?)
[09:45] <jml> BjornT, I think so.
[09:45] <jml> BjornT, it doesn't happen often, and means that someone has done some work on the bug.
[09:45] <jml> (a secondary bug is that the bug should probably be marked as in-progress)
[09:46] <maxb> noodles775: I mean I used bzr log -n0 --show-ids to find my last merged rev and then looked up the revid in devel to map it back to a revno
[09:46] <noodles775> maxb: in which case, it's strange that you had a different number of tests. Was that using 'make check'?
[09:46] <maxb> yes, make check
[09:46] <jml> BjornT, we have a bug somewhere on launchpad-code about making it appear in line. I'd like to add some notes to the bug about how to actually do it.
[09:47] <bigjools> maxb: `bzr misssing` not work for you?
[09:47] <wgrant> noodles775: It's not incredible that some test modules would fail to import.
[09:48] <maxb> bigjools: that'd tell me what I didn't have - I wanted to know what I didn't have - oh.... so I should have run bzr missing --this in devel and subtracted one from the lowest shown revno
[09:48] <noodles775> wgrant: no not at all, I'm just surprised that it didn't cause an error if that's the case.
[09:49] <maxb> Is it possible that some of the errors noted in that summary could abort the entire test module, skipping later tests?
[09:49] <jml> BjornT, where should I start looking to add bug/branch linking events to the inline view
[09:49] <wgrant> noodles775: The tests don't exist if the module failed to import.
[09:49] <wgrant> noodles775: There'll just be an exception somewhere back in the log.
[09:49] <bigjools> maxb: yes, that can happen
[09:50] <noodles775> maxb: good question.
[09:50] <bigjools> particularly in doctests
[09:51] <wgrant> I forget exactly how doctests count. Is it one test per block?
[09:51] <BjornT> jml: you should start at BugTaskView.activity_by_date, and adjust the interesting_changes bit to include branch linking
[09:51] <wgrant> Not as in Python syntax block, but doctest block.
[09:51] <BjornT> jml: with some luck, that's all that's needed
[09:51] <jml> BjornT, thanks.
[09:51] <bigjools> wgrant: no idea, it seems random to me :/
[09:51] <noodles775> wgrant: Hmm... if that's the case, then I'd say it's a bug - if 'all tests pass' then it lands (at least, I don't scroll back if all tests passed)
[09:52] <bigjools> if he altered tests then the number of tests could have changed
[09:52] <noodles775> wgrant: so hopefully the difference is due to the failures or altered tests, rather than import failures.
[09:52] <wgrant> noodles775: Hopefully.
[09:53] <jml> BjornT, the string should match the 'whatchanged' key of the activity dict, I assume.
[09:54] <BjornT> jml: yeah. if it doesn't look good, you have to change BugActivityItem to do special things for branch links
[09:55] <lifeless> jml: http://gorf.tangent.org/hudson/job/Drizzle-subunit/ has a test graph now
[09:55] <jml> BjornT, thanks.
[09:57] <maxb> zero altered tests
[09:58] <maxb> (so far)
[09:58] <wgrant> maxb: Did you collect a list of the failed tests to start attacking?
[09:59] <maxb> I have the entire log courtesy of screen, I need to work my way through it turning it into a list of test names and initial notes of probably causes
[09:59] <maxb> *probable
[10:03] <maxb> When I say zero altered tests....
[10:03] <maxb> I did have to alter the harness to wait longer for the librarian to start up
[10:03] <lifeless> I wish lp output in subunit at this point
[10:04] <lifeless> cause then you could do 'subunit-filter log | subunit-ls' and have that list instantly ;)
[10:04] <wgrant> Does a newer zope.testing do subunit?
[10:04] <bigjools> buildbot seems to parse it ok!
[10:04] <lifeless> wgrant: not per se; jml and I did a patch to launchpads test runner use arbitrary TestResult objects
[10:05] <lifeless> which permits subunit; jml was landing that work but I dont know if he had
[10:05] <jml> lifeless, I think I have
[10:05] <lifeless> cool
[10:05] <jml> but it might have rotted a little with recent buildout shenanigans.
[10:06] <lifeless> its a shame buildout != dpkg
[10:06] <wgrant> Indeed...
[10:06] <wgrant> eggs always seemed like a bad direction.
[10:06] <lifeless> its a bit of an awkward halfway-house
[10:06] <lifeless> wgrant: I loathe them. With a passion.
[10:06] <maxb> Does anyone not loathe eggs? :-)
[10:06] <wgrant> lifeless: I noticed! I'm not a fan either.
[10:07] <lifeless> anyhoo... internet dragons to kill
[10:07] <lifeless> jml: theres an xfail support patch up you might like to review; if you have a minute
[10:08] <jml> lifeless, sure. I'd like to dive back into actual Launchpad hacking now that my email kneejerks are done
[10:08] <jml> lifeless, what's the url?
[10:09] <mwhudson> jml: hello, btw
[10:09] <lifeless> https://code.edge.launchpad.net/~lifeless/subunit/xfail/+merge/9748
[10:09] <jml> mwhudson, hi
[10:09] <mwhudson> jml: want to review a branch?
[10:09] <jml> lifeless, ta
[10:09] <jml> mwhudson, is this your race condition branch?
[10:09] <mwhudson> jml: i'm much happier than i was with this stuff than i was yesterday :)
[10:09] <mwhudson> jml: yes
[10:10] <mwhudson> jml: the cover letter will include alan perlis' epigram no. 58
[10:11] <jml> mwhudson, beautiful. I'd love to look at it.
[10:20] <lifeless> jml: have a good day
[10:20]  * lifeless goes to entertain himself
[10:20] <jml> lifeless, good evening
[10:23] <mwhudson> jml: https://code.edge.launchpad.net/~mwhudson/launchpad/more-task-scheduled-bug-408638/+merge/9749
[10:24] <jml> mwhudson, thanks.
[10:26] <jml> I'm wondering if it's worth having a bug tag for "I'll bend over backwards to help you land a patch that fixes this bug"
[10:26] <mwhudson> jml: thanks in advance
[10:26] <jml> mwhudson, np
[10:27] <mwhudson> jml: if you want to ask things about it, sooner is better than later :)
[10:27] <jml> mwhudson, sure.
[10:27] <jml> mwhudson, in context switch mode right nowm.
[10:28] <mwhudson> k
[10:36] <jml> 'if' should be an expression in Python
[10:37] <mwhudson> it is in 2.5!
[10:37] <mwhudson> ish
[10:59] <deryck> Morning.
[11:03] <jml> mwhudson, review done.
[11:04] <jml> but I guess it's pretty late
[11:07] <wgrant> A couple of days ago I did a branch to export IArchiveDependency on the webservice, but I'm not entirely sure about the security bits.
[11:08] <wgrant> At the moment read access is allowed unconditionally, and write access is completely forbidden, but you can't get hold of one with having launchpad.View on the Archive. Should a security adapter be written for IArchiveDependency, or is that sufficient?
[11:11] <jml> I'm not sure.
[11:13] <jml> wgrant: I'd guess 'no', but I don't really have enough domain knowledge to give a full answer.
[11:13] <jml> bigjools, ^^ ?
[11:14] <wgrant> jml: 'no' to which?
[11:14] <bigjools> wgrant: if you're not sure then you haven't written enough tests
[11:15] <wgrant> bigjools: I know I can't get hold of an object, but I wonder if I should make it safer in case another exported method leaks them.
[11:15] <jml> wgrant: "no you don't need to write an adapter"
[11:15] <wgrant> jml: OK.
[11:15] <wgrant> But I think I probably do.
[11:15] <jml> ok.
[11:15] <jml> you'd know better than me, at this point :)
[11:16] <bigjools> wgrant: how do you know write access is forbidden?
[11:17] <wgrant> bigjools: I haven't a test for that yet, but lib/lp/soyuz/configure.zcml strongly suggests that it is.
[11:17] <bigjools> wgrant: if it's not tested then you don't know, by definition :)
[11:17] <wgrant> Right.
[11:18] <wgrant> Although similar tests (eg. ArchivePermission in stories/webservice/xx-archive.txt) don't seem to test that.
[11:19] <bigjools> then they suck
[11:19] <bigjools> :(
[11:19] <bigjools> which is probably my fault
[11:20] <mwhudson> jml: thanks
[11:20] <wgrant> Can somebody point me at a good example?
[11:20] <wgrant> I'm not clear on exactly how thorough the tests should be.
[11:20]  * bigjools looks
[11:22] <bigjools> wgrant: lib/lp/soyuz/stories/webservice/xx-archive.txt "Modifying privacy"
[11:23] <jml> wgrant: lp.code.tests.test_branch has unit tests for branch security
[11:23] <bigjools> jml: I think he explicitly needs webservice tests though
[11:23] <jml> oh right.
[11:24] <bigjools> the existing object is fine as it is, it's not directly exposed until wgrant exports it
[11:24] <jml> bigjools, about verify_acl
[11:24] <bigjools> yep?
[11:24] <jml> bigjools, it doesn't currently check component privileges for existing packages.
[11:24] <jml> is this a feature or a bug?
[11:25] <bigjools> feature
[11:25] <bigjools> deliberate
[11:25] <wgrant> I don't know to what depth I must go -- do I just verify that people can't write to a couple of the fields?
[11:25] <jml> bigjools, what's the reasoning?
[11:26]  * bigjools is trying to remember
[11:26] <bigjools> wgrant: test important fields
[11:26] <bigjools> where it would compromise functionality
[11:27] <jml> because BugTask.canApprove consults component privileges, and IIRC you implied I should check it for the package branch stuff.
[11:27] <wgrant> bigjools: OK, sounds good.
[11:29] <bigjools> jml: there's a comment in the middle of verify_acl that explains it.  I remember putting it there because I kept forgetting why :)
[11:29] <bigjools> it's because of overrides, basically
[11:30] <jml> bigjools, I'm looking at verify_acl & don't see anything that answers my question.
[11:30] <bigjools> oh wait the comment talks about new packages.  in any case, it's because of overrides
[11:30] <jml> ok.
[11:30] <bigjools> so we make sure that the person has an ACL to at least one component
[11:31] <bigjools> then let the overrides work after that
[11:32] <bigjools> jml: ummm wait
[11:33]  * bigjools engages brain
[11:33] <bigjools> why do you think that?
[11:34] <jml> bigjools, why do I think what?
[11:34] <bigjools> jml: "bigjools, it doesn't currently check component privileges for existing packages."
[11:34] <jml> bigjools, it checks it based on the dsc, but not the other thing... gimme a sec to find it.
[11:35] <bigjools> yeah it's at the bottom of verify_acl
[11:35] <jml> latest_published_component
[11:36] <jml> right. so it checks the dsc rather than latest_published_component. why's that?
[11:36]  * bigjools thinks
[11:39] <wgrant> It's already overridden, isn't it?
[11:39] <bigjools> yes, on the files
[11:39] <wgrant> find_and_apply_overrides() is called a few lines before verify_acl
[11:40] <bigjools> I can think of a situation where it might help
[11:40] <bigjools> but I am not sure if it's valid
[11:41] <bigjools> if a package goes universe->main, then a motu can continue to upload it if they target universe
[11:41] <wgrant> That's not reasonable, and I don't see why that would work?
[11:42] <bigjools> because it checks the dsc and not the current component
[11:42] <wgrant> But the dsc component is already overridden with the latest ancestry.
[11:43] <bigjools> ah so it os
[11:43] <bigjools> is
[11:43] <wgrant> That's pretty damn strange.
[11:43] <wgrant> But it works.
[11:43] <bigjools> christ I need more coffee
[11:43] <bigjools> jml: ok so it checks based on the override, just in a roundabout way
[11:43] <wgrant> I smell a missing comment.
[11:44] <jml> and AIUI, the override is not the same as the dsc file is not the same as latest_published_component
[11:44] <jml> is this correct?
[11:44] <bigjools> distroseries.getPublishedReleases()[0] is used
[11:44] <bigjools> which should be the same as latest_published_component
[11:44] <henninge> danilo, jtv: Help!
[11:44] <bigjools> well, its publishing record
[11:44] <jtv> henninge: ?
[11:45] <wgrant> (with the archive, too)
[11:45] <wgrant> latest_published_component doesn't know about the archive.
[11:45] <jtv> henninge: seems danilo's network conked out
[11:45] <wgrant> But I don't see why that would matter in any current situation.
[11:45] <henninge> jtv: oh
[11:45] <bigjools> jml: so, it applies the override first, which changes the component on the DSC
[11:45] <henninge> jtv: I thought it was me
[11:45] <jtv> henninge: and me
[11:45] <jtv> and him :)
[11:45] <henninge> jtv: I don't see you on skype either, though.
[11:45] <jtv> henninge: then I'll just restart to make sure
[11:46] <bigjools> wgrant: it does matter, that's not good
[11:46] <danilo> jtv: ok, back, but don't see you on skype
[11:46] <jml> BugNomination takes the latest_published_component and asks archive.canUpload(person, component)
[11:47] <jtv> danilo: I was just restarting it for luck
[11:47] <jml> is that any different, in effect, from what nascentupload is doing?
[11:47] <danilo> jtv: it's ringing
[11:47] <bigjools> jml: eeek that's wrong, because if a PPA has a more recent publication in main it will use that
[11:47] <wgrant> bigjools: When does it matter?
[11:47] <bigjools> all of these queries need to be archive specific
[11:47] <wgrant> bigjools: Doesn't latest_published_component restrict to distribution_archives?
[11:47]  * wgrant checks.
[11:47] <wgrant> I'm fairly sure it did.
[11:48] <bigjools> ah it does
[11:48] <bigjools> phew
[11:48] <wgrant> It uses _getFirstPublishing or something like that.
[11:48] <bigjools> ok
[11:48] <bigjools> it's kinda gross
[11:48] <wgrant> A little.
[11:48] <wgrant> I imagine it was all better before archive-rework.
[11:49] <wgrant> Nice and simple back then.
[11:49] <bigjools> when we added PPAs, we found a lot of problems in our data model that needed hacks like that
[11:49] <jml> bigjools, so it ought to be 'get_latest_published_component(archive)'?
[11:49] <bigjools> jml: not needed (yet)
[11:49] <bigjools> PPAs are always main
[11:49] <jml> ok.
[11:49] <bigjools> the nascentupload stuff is a remnant of when we used components in PPAs
[11:49] <jml> SEP.
[11:50] <mwhudson> jml: replied
[11:50] <bigjools> jml: so did I answer your question yet? :)
[11:52] <jml> the question is, "is BugNominations component permission check different from nascentupload's in any way that matters?"
[11:52] <jml> the answer so far seems to be "no, and everything is terrible"
[11:52] <jml> mwhudson, thanks.
[11:53]  * mwhudson giggles at wgrant correcting bigjools on soyuz arcana
[11:54] <wgrant> mwhudson: My mind is just freshly scarred with DSP and NascentUpload strangeness.
[11:55] <bigjools> I stepped on too many soyuz mines and lost half of my brain
[11:55] <wgrant> Easy to do.
[11:57] <jml> so, was my answer correct?
[11:57] <bigjools> pretty much
[11:58] <jml> bigjools, ok, thanks.
[11:58] <bigjools> jml: np, sorry it took so long to get there
[11:59] <jml> it's ok. my goal here is to make this kind of conversation unnecessary in future. :)
[11:59]  * bigjools hi-fives jml
[12:00] <wgrant> I have to wonder why the files are overridden, rather than the ACL code explicitly checking the overrides.
[12:12] <danilo> mrevell: hey, btw, what happened to frontpage updates?
[12:13] <mrevell> danilo: I was waiting for flacoste to return to get the CP and didn't want to overwhelm him on his day back, so I'll be asking him later on today.
[12:14] <danilo> mrevell: heh, ok, but kiko-afk is still able to do that for us as well :) fwiw, I already had one CP done
[12:38] <kiko-afk> I am indeed
[12:41] <mrevell> kiko-afk: Hey there. I was hoping to get a CP to update the what's new. I have an MP: https://code.edge.launchpad.net/~matthew.revell/launchpad/whatsnew227/+merge/9576
[12:45] <jml> sidnei, hi
[12:45] <sidnei> hey jml
[12:45] <jml> sidnei, so, in answer to your question, the release finder stuff isn't exposed via the api afaict
[12:45] <jml> sidnei, if you wanted to do so, you'd just have to expose IProductSeries.releasefileglob, I think.
[12:46] <sidnei> jml: sounds easy when you say it that way *wink*
[12:46] <sidnei> jml: i will give it a try
[12:46] <kiko-afk> mrevell, rc=kiko, though normally you'd just ask for a release-critical review on the MP
[12:46] <mrevell> ah thanks kiko-afk
[12:46] <mrevell> noted for future
[12:46] <sidnei> jml: what im trying to figure out is if i could automate setting up the import globs to suck in all the existing zope releases, which there maybe 50 of
[12:47] <jml> sidnei, cool. just ping me if you need help with the patch, or want a review.
[12:47] <sidnei> s/maybe/may be
[12:47] <sidnei> jml: thank you!
[12:59] <sidnei> jml: seems like there's no indication at all in the UI about the status of crawling for new releases
[13:00] <jml> sidnei, that's quite possible.
[13:02] <sidnei> jml: to boot, when you create the series it doesnt save the glob, you have to go back and fill the glob field again
[13:02]  * sidnei files a bug
[13:37] <danilo> beuno: hey
[13:40] <bigjools> beuno: did you knock up any CSS for "Choose a task" ?
[13:44] <noodles775> The CSS should "just work", I'll have a go at adding the template snippet to include it in the sidebar if it's not there already.
[13:59] <jml> hi
[14:08] <flacoste> hi
[14:08] <jml> flacoste, hi
[14:09] <jml> I just filed bug 409846, fwiw,
[14:09] <mup> Bug #409846: Contributors file <Launchpad itself:New> <https://launchpad.net/bugs/409846>
[14:09] <jml> not exactly sure what to put in such a file, right now
[14:18] <flacoste> jml: contributors should list contributors?
[14:18] <maxb> I don't think it necessarily follows that all OSS projects should have a contributors file
[14:19] <jml> maxb, no it doesn't. I think we should have one though.
[14:19]  * jml was a bit lazy filing that bug
[14:19] <jml> flacoste, yeah, but I don't have a complete list to hand
[14:19] <jml> maxb, a Changelog or a NEWS file would satisfy me.
[14:19] <maxb> As a contributor, I don't care. As a committer, I don't want to bother maintaining one or judging how big a contribution gains entry
[14:20] <maxb> A NEWS or CHANGES file is useful, but serves a completely different purpose to a Contributors file
[14:21] <maxb> A Changelog.... hmm, well if everyone just writes decent commit messages
[14:49] <mrevell> sinzui: Does this look like a question for the registry team? Or the code team? https://answers.edge.launchpad.net/launchpad/+question/79261
[14:52] <sinzui> mrevell: code. I think their may be an faq about this. I recall helping someone with the same issues 1 month ago
[14:53] <mrevell> Ah thanks sinzui
[14:53] <mrevell> cprov: Can you help with this PPA question please? https://answers.edge.launchpad.net/launchpad/+question/79246
[14:53] <beuno> danilo, hi
[14:53] <beuno> bigjools, I don't think so
[14:53] <cprov> mrevell: sure, assign it to me, I will reply in a sec
[14:54] <mrevell> thanks cprov
[14:55] <danilo> beuno: anyway, I just wanted to say that I am considering putting henninge on +translate page for the following two months, and we'd like some private time with you to discuss ultimate +translate page next week (to give all of us time to think about what'd be cool to do)
[14:55] <jml> maxb, personally, I like to be credited when I contribute to projects, and I feel a bit awkward committing someone else's contributions without crediting them
[14:55] <sinzui> mrevell: This question looks a lot like a question asked by https://answers.edge.launchpad.net/~basicxp but I think that was a feedback email.
[14:56] <maxb> jml: Yes, but I'd address that in the log msg or bzr commit --author
[14:57] <beuno> danilo, sure. Can we try tomorrow?  today's kind of crazy
[14:57] <danilo> beuno: as I said, next week is best
[14:57] <jml> maxb, I don't think that's enough glory :)
[14:58] <beuno> danilo, even better
[14:58] <danilo> beuno: and if my timezones are correct, we should be in a call in about 2 minutes :)
[14:58] <beuno> danilo, yes, I have my headphones on
[15:02] <mrevell> danilo: Could you take a look at this question please? https://answers.edge.launchpad.net/launchpad/+question/79233
[15:02] <danilo> mrevell: sure I could, but I don't want to
[15:03] <mrevell> heh
[15:03] <mrevell> but you're going to, so that's ok
[15:39] <leonardr> gary_poster: i might as well take care of bug 397903 while i'm touching every lazr package. is creating LICENSE.ZPL the right thing to do?
[15:39] <mup> Bug #397903: ZPL LICENSE not included in source <lazr.restful-client:New> <lazr.uri:New> <https://launchpad.net/bugs/397903>
[15:41] <gary_poster> leonardr: look in _bootstrap.  I believe that bug report is in error
[15:41] <leonardr> gary_poster: indeed
[15:43] <gary_poster> leonardr: so my opinion is mark as Invalid.  You can ask James if the names we have for the files are OK for Ubuntu, I guess, if you want to.  Or just leave it be, maybe, woud be better.
[15:44] <james_w> I don't see a _bootstrap in the branch?
[15:45] <gary_poster> james_w: no?  it is in one I have around (at top of package).  will look at trunk.
[15:45] <leonardr> james_w: what branch are you using?
[15:45] <james_w> lazr.uri at least
[15:45] <james_w> lp:~launchpad-pqm/lazr.uri/trunk/
[15:46] <gary_poster> I have one in my copy of that too.  Actually getting trunk now as promised
[15:46] <leonardr> gary: i do not have _bootstrap in my copy of trunk
[15:47] <gary_poster> I may have been bad and not merged, way back when when I made a PyPI release.  checking.
[15:48] <gary_poster> james_w, leonardr: bzr+ssh://bazaar.launchpad.net/%7Elaunchpad/lazr.uri/1.0.1/ .  We (largely, I) didn't do a great job with getting all of this right in lp at the start.  1.0.1 should be merged with trunk, whatever that is
[15:49] <leonardr> gary_poster: ok, do you want to fix the path while you're at it? then i'll review
[15:49] <jml> cprov, ping
[15:49] <cprov> jml: pong
[15:49] <gary_poster> james_w: lazr.restful does have _bootstrap; it is now part of the lazr.* templates.  I don't think we have any actual releases without the license
[15:49] <gary_poster> fwiw
[15:50] <jml> cprov, I want to write a test for 'if a package is in a component and you have upload rights for that component in the archive then you can upload to that package'
[15:50] <jml> cprov, where 'package in a component' is probably defined by sourcepackage.latest_published_component
[15:50] <gary_poster> leonardr: 1.0.1 is an old branch of what was released as 1.0.1.  I'll branch it, make the path change, and push it to someplace or other...
[15:50] <jml> cprov, how do I populate latest_published_component without actually uploading a package?
[15:51] <matsubara> stub, herb, flacoste, rockstar, bigjools, henninge, sinzui, intellectronica: production meeting in #launchpad-meeting in 9min
[15:51] <leonardr> gary_poster: so we did the release but didn't merge with trunk
[15:51] <cprov> jml: SP.latest_published_component doesn't cope with PPA sources, IIRC
[15:51] <gary_poster> leonardr: right.
[15:51] <jml> cprov, it doesn't have to be PPA
[15:51] <cprov> jml: right, you can create publications with SoyuzTestPublisher()
[15:51]  * jml greps
[15:53] <jml> cprov, I was kind of hoping for something a little more object factory friendly
[15:53] <james_w> gary_poster, leonardr: thanks, if we can get fresh releases with these changes for lazr.restfulclient and lazr.uri that would be great
[15:53] <leonardr> james_w: you should have for lazr.restfulclient now
[15:54] <bigjools> jml: it's a sort of factory itself, but keeps the db relations intact
[15:54] <james_w> thanks leonardr
[15:54] <cprov> jml: we can wrap STP in the factory, but it requires a lot of assumption that are not good for the current callsites.
[15:55] <jml> bigjools, the factory keeps db relations intact though, doesn't it?
[15:55] <gary_poster> leonardr: it would also be fantastic to remove any remaining use of the setuptools_bzr stuff in these packages.  There's a bug for that someplace: it is annoying for *NIX, and apparently outright broken for Windows
[15:57] <gary_poster> leonardr: I'm merging 1.0.1 to trunk now.  (At the time, merging required the whole pqm dance).  That does not include the new path stuff
[15:57] <gary_poster> leonardr: this is the diff of 1.0.1: https://pastebin.canonical.com/20872/
[15:57] <cprov> jml: it's not that difficult to create Factory.makeSourcePublication(...) using STP, but requires some cleanup.
[15:58] <bigjools> it's possible but I question the value
[16:00] <leonardr> gary_poster: r=me on that diff
[16:01] <gary_poster> leonardr: cool thanks.  nevermind about me submitting to trunk.  I thought this was no longer managed by pqm.  Do we still have to trigger a launchpad pqm test in order to land on this branch?  If so, could I toss this back to you?  I'd really, really like to be working on the zope buildout branch
[16:03] <leonardr> gary_poster: it looks like lazr.uri trunk is managed by pqm, but i think i can just change the development focus, like i did for lazr.restful and wadllib. flacoste, is this okay?
[16:04] <flacoste> leonardr: why not simply submit through PQM?
[16:04] <flacoste> we want all of trunks managed by PQM eventually
[16:04] <flacoste> the reason it's not is because it's not set-up to run only the packages tests yet
[16:05] <flacoste> but for lazr.uri, i think it should be fine
[16:05] <flacoste> unless it runs the whole test suite
[16:05] <flacoste> where whole = launchpad
[16:05] <leonardr> why wouldn't it?
[16:31] <leonardr> all right, i'll do lazr.uri after lazr.yourpkg
[16:44] <flacoste> jtv: are you done with your lock on LPS?
[16:44] <flacoste> jtv: wiki lock on LaunchpadProductionStatus
[16:44] <jtv> flacoste: no, I've only had it a minute!
[16:46] <jtv> flacoste: released it for now
[16:51] <rockstar> abentley, ready to chat
[16:52] <abentley> rockstar: 1 sec
[16:52] <rockstar> abentley, just call when you're good to go
[16:52] <allenap> Does anyone know why https://bugs.staging.launchpad.net/openfiler might keep timing out?
[16:52] <allenap> It has consistently timed out on me all day.
[16:53] <jml> it needs the librarian :(
[16:54] <sinzui> Should I publicise  how to register a menu without touching ZCML?
[16:55] <allenap> jml: Was that a response to my question? If so, is the librarian in staging borkened?
[16:58] <allenap> Argh. I started writing borked, decided to use broken instead and somehow ended up with borkened.
[17:12] <Ursinha> hey bigjools, you're using kde, right?
[17:12] <bigjools> yarp
[17:13] <Ursinha> bigjools, my kde acts up sometimes and doesn't allow me to do a rf-get or commit to a branch without asking the the passphrase of a rsa key
[17:13] <Ursinha> but the key has no passphrase,so I'm not able to do what I want
[17:13] <bigjools> that's down to the gpg-agent settings, not KDE
[17:13] <Ursinha> it seems ssh-agent or something is borked.. don't know
[17:14] <bigjools> or ssh-agent!
[17:14] <Ursinha> bigjools, why does it work fine on gnome?
[17:14] <bigjools> no idea :/
[17:14] <Ursinha> bigjools, did you have this problem
[17:14] <Ursinha> ?
[17:14] <bigjools> no, nothing like that
[17:15] <Ursinha> :(
[17:15] <Ursinha> thanks anyway bigjools
[17:15] <bigjools> Ursinha: can you narrow it down to what command causes it?
[17:16] <Ursinha> the error messages or ssh-agent to work on kde?
[17:17] <bigjools> well, you say bzr commit causes it?
[17:17] <Ursinha> yes
[17:17] <Ursinha> and a rf-get
[17:18] <bigjools> have you got sign-commits turned on?
[17:18] <Ursinha> trying to push branches to lp
[17:18] <Ursinha> yes
[17:18] <Ursinha> I do
[17:19] <bigjools> turn that off and commit again, see if it happens
[17:19] <bigjools> wait, committing does it, or pushing?
[17:22] <jml> allenap, no, it wasn't
[17:22] <jml> allenap, The SoyuzTestPublisher needs the librarian :(
[17:22] <allenap> jml: Okay, thanks :)
[17:22] <bigjools> jml: that can be bypassed with a code change if you want
[17:23] <jml> bigjools, ooh, how?
[17:24] <bigjools> jml: add an option so that addPackageUpload isn't called
[17:25] <jml> ok, thanks.
[17:25] <bigjools> that's the part that inserts librarian files
[17:25] <bigjools> but make it default to true :)
[17:27] <danilo> jtv: hey, are you around?
[17:27] <jtv> danilo: barely... get my ping?
[17:28] <danilo> jtv: if it's on internal IRC, no (you get on and off there)
[17:28] <jtv> yeah :(
[17:28] <jtv> "danilo: CP requests are up, all merge cleanly into 2.2.7, and all Translations tests pass (apart from that test_args thing that buildbot doesn't complain about; I didn't touch that).  And I'm done.  :-)"
[17:28] <jml> bigjools, naturally :)
[17:28] <danilo> jtv: just a note about https://code.edge.launchpad.net/~jtv/launchpad/bug-409330/+merge/9760 : it's really ugly to have this option by ID, and I don't want us to schedule a job like that ever
[17:29] <jtv> danilo: a bit late to tell me that!
[17:29] <danilo> jtv: can you prepare a simpler patch to just remove it from the nightly instead?
[17:30] <jtv> danilo: the patch is the same, but the request to the LOSAs is different.
[17:30] <jtv> I Cc'ed you on the email, and there's another link to the same request on LaunchpadProductionStatus.  You can follow up & change if you like.
[17:30] <danilo> jtv: why'd you need to add start-id parameter if we just want to remove it from the nightly?
[17:30] <danilo> jtv: ok, sure
[17:31] <jtv> danilo: this was exactly the solution I described on the call.
[17:32] <jml> :(
[17:33] <danilo> jtv: yeah, sorry, I guess we misunderstood each other :)
[17:34] <danilo> jtv: anyway, don't worry about it, I'll figure something out
[17:34] <danilo> jtv: go home already :)
[17:35] <jml> soyuz folks: why is this test failing?
[17:35] <jtv> danilo: ok, ok!
[17:35]  * bigjools awaits the paste
[17:36] <jml> *ahem* http://paste.ubuntu.com/248735/
[17:36] <barry> leonardr: ping
[17:37] <leonardr> barry, welcome back
[17:37] <bigjools> jml: what is makeComponent?
[17:38] <bigjools> slightly rhetorical Q
[17:38] <jml> bigjools, http://paste.ubuntu.com/248738/
[17:39] <bigjools> jml: check the publishing status
[17:39] <jml> bigjools, it's something I added to the factory, because it seemed useful.
[17:39] <jml> bigjools, ahh, it'll be PENDING
[17:39] <bigjools> jml: I think it's a bit bogus, you should stick to known components
[17:39] <bigjools> jml: exactly :)
[17:40] <bigjools> jml: return "main" by default maybe?
[17:40] <jml> bigjools, well, the point is more to stop tests making implicit assumptions about components
[17:41] <jml> bigjools, if it returned 'main' by default, then that would lead to accidentally tying tests to properties of main.
[17:41] <jml> but it's a small thing.
[17:41] <bigjools> okay
[17:49] <jml> woot. I now have the failing test :)
[18:06] <mrevell> Night all
[18:37] <salgado> beuno!
[18:38] <beuno> salgado!
[18:38] <salgado> I was wondering, what will the breadcrumbs for bugs.lp.net/shipit/+bug/315110 look like?
[18:39] <beuno> salgado, I need to sit down and nail it, but something like "Ship It > Bug Listing > Bug title blah bl..."
[18:40] <salgado> beuno, right, that's what I was expecting. just wanted to make sure
[18:40] <salgado> beuno, what about, say,   https://code.edge.launchpad.net/~spiv/bzr/inventory-delta. do you have any idea what the breadcrumbs will look like?
[18:42] <beuno> salgado, someething line "Bazaar > Branch listing > inventory-delta"
[18:42] <beuno> last breadcrumb is always bold, and not a link
[18:42] <salgado> right
[18:43] <jml> cprov, the code currently in nascentuploader's verify_acl checks permissions for ppa's before doing the binary upload shortcut
[18:44] <jml> cprov, is that meaningful in any way?
[18:45] <salgado> beuno, so, would it be fair to generalize the breadcrumbs for app.launchpad.net/something/sth-else to "lp.net > lp.net/something > app.lp.net/something > app.lp.net/something/sth-else (unlinked)", for a start?
[18:45] <beuno> salgado, lp.net is never the root
[18:46] <beuno> projects are the root
[18:46] <beuno> well, maybe with the few exceptions of launchpad-wide search and such
[18:46] <beuno> so the root is always lp.net/foo
[18:46] <cprov> jml: let me check the code
[18:46] <jml> cprov, thanks.
[18:46] <beuno> salgado, or lp.net/~foo if it's not linked to a project
[18:47] <salgado> beuno, oh, right, I included lp.net because the link to the home page seems to be part of the breadcrumbs
[18:47] <salgado> but it's not
[18:48] <cprov> jml: no, 'if self.binaryful: return' can happen before the ppa check.
[18:48] <beuno> salgado, right. We want to emphazise projects rather than Launchpad
[18:48] <jml> cprov, cool. thanks.
[18:48] <salgado> beuno, so, is that link to the home page going away?
[18:48] <beuno> salgado, yes, unless you're in a context-less page
[18:48] <cprov> jml: as in "binary uploads don't need permission checks"
[18:49] <jml> cprov, sure. but I don't trust comments implicitly :)
[18:49] <rockstar> Holy poo poo, I just used the inline "Request a review" and it's awesome.
[18:50] <cprov> jml: the comment isn't any clear about this aspect, you can amend it if you have a chance.
[18:50] <jml> cprov, will do.
[18:56] <salgado> beuno, ok. I now know enough about breadcrumbs to have an idea of how much work will be involved to tweak them to our needs, so whenever you want to talk more, just let me know
[18:56] <beuno> salgado, how's in 30-40 minutes?
[18:57] <salgado> beuno, wfm
[18:57] <jml> cprov, verify_acl doesn't have any checks to do with the pocket -- why?
[18:57] <beuno> cool
[18:57] <jml> (apologies if I've asked this before)
[18:58] <cprov> jml: because it's done in UploadPolicy.check_upload(), IRC
[18:58] <jml> oh right.
[18:58]  * jml remembers some more stuff
[19:00] <cprov> jml: it would be nice to consolidate both check in one place
[19:00] <jml> cprov, yeah, that's what I'll do.
[19:00] <jml> cprov, but I've got a tested function that does what most of verify_acl does, so I'll slot that in place first before expanding its features
[19:02] <cprov> jml: nice move.
[19:16]  * jml is off for a bit
[20:03] <sinzui> gary_poster: is the https://lpbuildbot.canonical.com/ failure one of your mad-science projects?
[20:04] <gary_poster> sinzui: mthaddon's, with my assistance as possible.  sorry, we are disabling the emails.  this will become the "real" buildbot hopefully within a week though.
[20:04] <beuno> salgado, ready when you are
[20:07] <salgado> beuno, I'm ready
[20:07] <salgado> beuno, calling now
[20:17] <beuno> salgado, https://bugs.edge.launchpad.net/bzr/+bugs?search=Search&field.status=New&field.status=Incomplete&field.status=Confirmed&field.status=Triaged&field.status=In+Progress&field.status=Fix+Committed
[20:17] <beuno> https://bugs.edge.launchpad.net/bzr/
[20:25] <beuno> salgado, https://devpad.canonical.com/~beuno/LP_new_design_Bugs_v3.1.png
[20:31] <beuno> sinzui, did your font size fix land?
[20:31] <beuno> barry!!!
[20:31] <sinzui> beuno: it is in the review queue
[20:32] <beuno> yay
[20:33] <sinzui> beuno: the fix is in the branch that adds the action menu and involvement portlet.
[20:33] <beuno> sinzui, I feel everything coming together
[20:35] <sinzui> beuno: me too. my project page is two branches. I'll have the view changes in review in a few hours
[20:37] <beuno> I'm happy
[20:42] <beuno> salgado, the project group is great
[20:42] <beuno> I don't see any icons to edit things inline
[20:42] <beuno> is that because you can't
[20:42] <beuno> ?
[20:42] <beuno> also, maybe "change details" isn't the best text
[20:42] <beuno> and that should probably be the first option on that list
[20:45] <salgado> beuno, I wasn't sure if the links to +reassign and +edit-maintainer should be inlined there or be the related pages from +edit.  maybe they should be in both?
[20:45] <beuno> salgado, where are those now?
[20:45] <salgado> nowhere
[20:45]  * beuno logs in as the owner of the prokject
[20:45] <salgado> oh, right now they're in the actions menu
[20:45] <beuno> salgado, also, the maintainer doesn't have a person icon
[20:46] <sinzui> salgado: I used Change details to get to one edit page. It has a releated-pages menu of all the other pages. The design of project and project-group should be the same
[20:46] <salgado> beuno, good catch
[20:46] <beuno> salgado, I don't see the reassign link at all
[20:46] <salgado> sinzui, agreed, but should the links to +reassign and +driver be inlined in the project-group's +index page?
[20:47] <salgado> beuno, that's the Change maintainer
[20:47] <salgado> the other is Change driver
[20:47] <beuno> salgado, I don't see that link on the page
[20:47] <salgado> appoint driver
[20:47] <salgado> really?
[20:48] <sinzui> salgado: beuno: this is the same issue that EdwinGrubbs had. These can be dangerous to change. should it be that easy?
[20:48] <salgado> beuno, are you looking at the new page?  in the new page it's not shown
[20:48] <beuno> salgado, https://devpad.canonical.com/~beuno/Screenshot-1.png
[20:48] <beuno> sinzui, ^
[20:48] <salgado> beuno, I thought you were looking at the page on mainline
[20:48] <salgado> a mainline branch, that is
[20:49] <beuno> no no, your branch
[20:49] <salgado> ok, in there it's not shown anywhere
[20:49] <salgado> because I thought they should be the related pages on +edit
[20:49] <sinzui> beuno: salgado: The project summary should be bigger. The .summary class in the the CSS that is in review
[20:51] <beuno> YES
[20:51] <beuno> agreed
[20:51] <beuno> I think they should be inline
[20:51] <beuno> edit icon next to the name
[20:52] <salgado> right
[20:52] <sinzui> salgado: beuno: this is the project screenshot that is going into review https://devpad.canonical.com/~curtis/firefox.png
[20:52] <salgado> beuno, I think it's be nice to have them on the related pages of +edit as well, any objections?
[20:52] <EdwinGrubbs> sinzui, salgado, beuno: I think that it would be nice to have some consistency, so we don't have some edit links on the +index page, some on the +edit page, and some inline on other pages. How do we know where to find an edit link when it is not next to the field we're editing?
[20:52] <sinzui> salgado: I think we want the same titles for external links and move the rdf into the side portlet
[20:52] <beuno> salgado, I think no objections, but we want to aim so that people don't need to go to that page for anything
[20:53] <beuno> EdwinGrubbs, agreed
[20:53] <salgado> beuno, absolutely
[20:53] <sinzui> EdwinGrubbs: We can do that when YUI and lazr.js supports all browsers
[20:53] <beuno> sinzui, we need to chop off long names in the download field
[20:53] <sinzui> beuno: The design does not match reality
[20:54] <EdwinGrubbs> sinzui: you don't need ajax to put an edit link next to a field.
[20:54] <sinzui> beuno: I also do not open my browser to the size of my desktop because I know that is crack
[20:55] <sinzui> EdwinGrubbs: correct that is why we do not need lots of links in the action menu. The reality is that many Change details links will go to a form that has something that is not inline.
[20:55] <sinzui> EdwinGrubbs: we are encourages to move everything in an edit form into the page
[20:57] <sinzui> EdwinGrubbs: Beuno: There is still a usability issue with the edit icon next to an editable value. When I place it next to a title, do I mean I am editing the title or the object?
[20:58] <beuno> sinzui, I think that if we put an edit icon on the title, we should mean you can edit the title
[20:58] <beuno> which means, the branch page needs changing
[20:59] <sinzui> beuno: EdwinGrubbs. So every model object gets a Change details link if has just one filed that is no shown inline.
[20:59]  * sinzui really has to expose the releasefileglob on series.
[20:59] <beuno> salgado, also, I think we should drop the milestone portlet
[20:59] <beuno> and use EdwinGrubbs's graph
[20:59] <beuno> sinzui, yes
[21:00] <sinzui> beuno: that is a rule that I will add to the conversion page
[21:00] <sinzui> beuno: read the bugs about project milestones. Users want them, we need to fix them
[21:01] <salgado> beuno, EdwinGrubbs, can I render it easily for a project group as well?  or do I need to do some work?
[21:01] <beuno> sinzui, I know all about them, they want inheritance
[21:01]  * beuno deflects to EdwinGrubbs 
[21:01] <sinzui> They want to see them and know which project or series they pertain too
[21:01] <beuno> sinzui, yeah, but that portlet is very close to useless
[21:02] <beuno> so we should drop it
[21:02] <beuno> and figure out what people need
[21:03] <sinzui> salgado: look at launchpad project. The list is large. Every project group that I have seen in the past 3 months has more than 5  projects to list. I think we need to recognise the list will be long
[21:04] <EdwinGrubbs> salgado: you would have to add a method like model.Product.getTimeline() to the project group and export it.
[21:06] <sinzui> beuno: Let's separate projects from milestones and relases. The portlets have different users. I think a developer needs to see where development is happening in the project-group. We can show a portlet that represents the +milestones view that summarises the latest five mielstones and releases across all projects
[21:07] <sinzui> Oh bugger, I don't have a structural subscription on the project page.
[21:07] <beuno> sinzui, +1
[21:08] <mwhudson> does someone want to slap the db_lp buider?
[21:08] <mwhudson> (morning, btw)
[21:09] <sinzui> salgado: you can add an edit link to any field value in the template using TALES menu:<facet>/<link_name>/fmt:icon after you render the value.
[21:10] <barry> flacoste: hi!  been talking to leonardr about @error_status in lazr.restful.  it seems like @error_status (or webservice_error()) should register the exception, but i don't think it does
[21:10] <sinzui> We can add them after driver and maintainer. I jut do not want them editable inline until we have a "shoot your self in the foot warning" for the
[21:10] <sinzui> m
[21:11] <salgado> oh, right.  I thought all we were talking about was having the links in the main content area
[21:12] <EdwinGrubbs> sinzui: right now the $team/+edit page has edit links at the bottom of the page that are not available on the +index page. It doesn't seem like I can create an ActionMenu class for it, since it only differentiates based on facet and context, so it would show the same action menu on +edit and +index. Is it right that I should just shove that into the side slot?
[21:12] <flacoste> barry: it simply annotates the exception with the status, it doesn't register anything
[21:12] <salgado> sinzui, anyway, agreed on non-inline editing for these things for now
[21:12] <barry> flacoste: ah.  then maybe this comment in configure.zcml is confusing me:     XXX flacoste 2008/05/09 bug=185958:
[21:12] <barry>     Ideally, we would use webservice_error() to register the view,
[21:12] <barry>     but InvalidBatchSizeError is in lazr.batchnavigator and webservice_error()
[21:12] <barry>     can only be called from within a class definition.
[21:13] <barry> flacoste: so, basically, i need to copy that chunk for my exception i guess
[21:14] <flacoste> barry: hmm, hang on
[21:16] <flacoste> barry: you are right, it does register the exception view
[21:16] <flacoste> barry: so there are two possiblities here
[21:16] <flacoste> 1) webservice_error isn't being processed (is it in a module that is introspected for annotations)
[21:17] <flacoste> 2) (more likely) you're zope integration publication doesn't provide an adequate handleException implementation
[21:17] <flacoste> in Launchpad, we rely on the default ZopePubliation implementation
[21:17] <barry> 1) definitely is because it's in an interface module that has other annotations
[21:18] <flacoste> if you look at our test publiaction, you'll see that we provide a lightweight implementation of handleException that looks up the view
[21:18] <barry> 2) is a possibility.  i should try ripping out my specialized stuff and use leonardr's new wsgi stuff
[21:18] <flacoste> leonardr told me he's having the same problem
[21:18] <flacoste> so it probably wasn't copied over to the wsgi base stuff
[21:19] <barry> interesting
[21:19] <sinzui> salgado: I think we need some easy way to see that pillars used the same portlets. I see you have blueprints and I do not. I have answers, I do not think you do. I created FAQs
[21:20] <barry> flacoste: yep, i see it in lazr/restful/publisher.py.  my publisher is definitely not doing the view lookup.  i'll bet that's it
[21:20]  * barry hacks
[21:20] <EdwinGrubbs> sinzui: the action links on the +edit, +reassign, +branding, +edithomepage, etc. are currently displayed on all the edit pages, which is similar to how it was with the second level tab bar. I assume only the +edit page should have these links from now on.
[21:21] <flacoste> barry: can you reply to your post? sorry i didn't get to it, but i was away from it all
[21:21] <flacoste> for the past two weeks
[21:21] <barry> flacoste: sure; if i get it working :)
[21:22] <sinzui> EdwinGrubbs: right, That is how I know I had to put the NavigationMenu back. Only the edit pages use the menu. I used view/+related-pages to render it. Also I used a mixin for the nav menu and the facet menu to ensure shared links have the same title and icon.
[21:23] <sinzui> EdwinGrubbs: salgado: beuno: We might want a rule where all the links are defined in a mixin and the implementing menu classes just select the links they need.
[21:23]  * sinzui used that rule as the example he sent in the navigation email.
[21:24] <salgado> sinzui, that sounds like a good idea
[21:26] <sinzui> salgado: My next controversial suggest is to create browser/pillar.py  and define common menus and and views.
[21:42] <EdwinGrubbs> sinzui: is the @@+global-actions and @@+related-pages framework in trunk? I assume that those views need to be registered somehow that your example doesn't show.
[21:43] <sinzui> @@+related landed last week. @@+global-actions is in review now. You can review them if you like
[21:44] <sinzui> EdwinGrubbs: My navigation menu email gives more than examples, I divulge how to register a menu without ZCML.
[21:44]  * sinzui has kept that a secret for 14 months
[21:46] <EdwinGrubbs> sinzui: I saw how you registered the menus without using <browser:menus> but doesn't there still need to be a <browser:page name="+global-actions"> somewhere?
[21:46] <sinzui> EdwinGrubbs: it is in the branch in review.
[21:46] <EdwinGrubbs> cool
[21:46]  * sinzui looks for branch
[22:01] <thumper> morning
[22:04] <barry> leonardr, flacoste i just sent an update.  see the two little nits i still have.  but it's pretty much working.  thanks for your help, and i'm off irc now! :)  if you have any insights please respond to the thread.
[22:05] <leonardr> barry, looking forward to it
[22:05] <flacoste> ack
[23:01] <mwhudson> thumper: skype?
[23:01] <thumper> yep
[23:01] <mwhudson> cool
[23:01] <thumper> just getting off with curtis
[23:02] <mwhudson> ah cool
[23:04] <thumper> abentley, rockstar: pign
[23:04] <rockstar> thumper, I see you calling, but I can't answer.
[23:04] <thumper> rockstar: why?
[23:04] <rockstar> thumper, skype sucks?
[23:04] <rockstar> I said can't, not won't.  :)
[23:04] <rockstar> thumper, try again please.
[23:13] <abentley> thumper: Sorry.  Here now.
[23:20] <wgrant> Huh. Somebody just suggested that all the apps should be removed except Bugs, I think.
[23:21] <mwhudson> would make my life easier
[23:21] <mwhudson> maybe?
[23:22] <abentley> thumper: bzr+ssh://bazaar.launchpad.net/~abentley/launchpad/related-bugs
[23:24] <mwhudson> spm: hi, can i get you to cowboy a branch on to tellurium for me?
[23:25] <spm> mwhudson: sure
[23:25] <mwhudson> spm: i really want to test this today, i'll have entirely forgotten how this works in a fortnight :)
[23:25] <mwhudson> spm: what's easiest for you?  a branch url, a diff ?
[23:25] <spm> mwhudson: :-) patch - by far
[23:26] <spm> mwhudson: codehost? or browse?
[23:26] <mwhudson> spm: codehost
[23:27] <mwhudson> spm: http://pastebin.ubuntu.com/248903/
[23:27] <mwhudson> spm: i guess i'd like you to disable the update that would otherwise wipe this out in 30 minutes too :)
[23:29] <spm> mwhudson: aye, done.
[23:29] <mwhudson> spm: thanks
[23:30] <spm> mwhudson: patched and restarted; rewrite hup'd?
[23:30] <mwhudson> spm: nah, it's not in that area
[23:31] <spm> cool
[23:31]  * mwhudson bounces buildbot
[23:46] <mwhudson> spm: can you sync the puller.log file to devpad?
[23:46] <mwhudson> but things seem to be working \o/!
[23:47] <spm> mwhudson: is syncing atm
[23:47] <mwhudson> spm: ta
[23:47] <spm> done
[23:47] <mwhudson> grr, why isn't buildbot building !?
[23:52] <rockstar> thumper, call?
[23:54] <mwhudson> spm: can you see if there's a mirror-branch.py process on tellurium?