[12:04] <daf> right, source packages are magic
[12:04] <kiko>     def __init__(self, sourcepackagename, distrorelease=None,
[12:04] <kiko>                  distribution=None):
[12:04] <daf> but that magic stops at a certain level
[12:05] <daf> what's that from?
[12:05] <daf> SourcePackage?
[12:05] <kiko> yes
[12:05] <kiko> that's my point
[12:05] <daf> the difference is that we actually have a DB table called BinaryPackage, n'est pas?
[12:06] <kiko> yes, that's true
[12:06] <kiko> so you're proposing a BinaryPackageSubSet?
[12:06] <kiko> hmmm
[12:06] <daf> maybe
[12:06] <daf> these things are a bit odd
[12:06] <kiko> BinaryPackageSetInDistroRelease
[12:06] <kiko> yeah
[12:06] <daf> so best avoided if possible
[12:06] <kiko> making pages without nice content objects is a bit sucky though
[12:06] <daf> yeah, something like that might be better
[12:07] <daf> right
[12:07] <kiko> would you support renaming database/ content/
[12:07] <daf> hmmmm
[12:07] <kiko> given SourcePackage and other non-DB cruft accumulating there? :-)
[12:07] <daf> the "database" code does a lot more than just DB access
[12:07] <daf> so "content" is more accurate, I guess
[12:08] <kiko> I thought so too
[12:08] <kiko> we'd call them domain/ at Async
[12:09] <daf> the other option is to have both database/ and content/ and have the DB layer kept very thin
[12:09] <daf> this was the original plan about a year back, I think
[12:09] <daf> but it never worked out that way
[12:10] <kiko> the sab was against it 
[12:10] <daf> and I think it might be tricky to keep them separate
[12:10] <kiko> it was a lot of glue code, too 
[12:10] <daf> we have moved stuff out of database/ before
[12:10] <daf> hmm
[12:11] <daf> then again, I can't think of an example
[12:11] <daf> unless the traversal code used to live in there
[12:12] <daf> you can make the DB code lighter if you use adapters
[12:12] <daf> but the sab isn't too keen on those either
[12:13] <kiko> indeed
[12:13] <daf> anyhow
[12:13] <daf> the source package stuff should be easy
[12:13] <daf> the binary package URL code should be easy
[12:13] <daf> the binary package fetching code is a bit more mysterious
[12:14] <kiko> yeah
[12:14] <kiko> hmmm
[12:14] <lifeless> morning all
[12:16] <kiko> lifeless!
[12:16] <kiko> how goes it?
[12:16] <lifeless> ask me in an hour ;)
[12:16] <lifeless> neither caffeine nor food have touched me yet
[12:18] <kiko> lifeless, my merge failed, any change you can do a 0-minute look into it?
[12:18] <kiko> I'd like to run home soonish..
[12:21] <lifeless> kiko: sure
[12:21] <lifeless> kiko: what error did you get ?
=== sabdfl [~mark@host217-37-231-22.in-addr.btopenworld.com]  has joined #launchpad
[12:25] <lifeless> ddaa: how goes it ?
[12:25] <ddaa> lifeless: grrrr I just sent my activity report, you're making me work off-hours ;)
[12:26] <ddaa> Talked with Keybuk. I think I finally understand what ftp details are all about.
[12:26] <kiko> lifeless, you got email!
[12:26] <ddaa> We can be much more liberal with creating series than I first thought.
[12:26] <ddaa> Also, I understand http ftp details
[12:27] <lifeless> good
[12:27] <lifeless> kiko: I do ?
[12:27] <kiko> lifeless, you should have received 2 mails I sent to you earlier
[12:28] <kiko> if you didn't, let me know
[12:30] <ddaa> sabdfl: I understood you were interested in funding a bounty for a subethaedit-like editor.
[12:30] <sabdfl> ddaa: yes
[12:30] <ddaa> So, I think I should let you know...
[12:30] <ddaa> I've been working on such a thing on my spare time for a few weeks.
[12:30] <ddaa> It's not yet release though.
[12:31] <sabdfl> ddaa: ok, thanks for letting me know
[12:31] <sabdfl> in general i want bounties to bring new people into the project though ;-)
[12:32] <ddaa> I'll mail you, jdub and a couple of potentially interested guys once I release it (it just needs a few refactorings before that).
[12:34] <ddaa> I'm sure you're going to love the technology :) Python, Twisted, GTK, lotsa test cases etc.
[12:35] <lifeless> kiko: helps when I don't delete a random digit from the fingerprint
[12:35] <lifeless> kiko: try now
=== kiko laughs
[12:39] <lifeless> hey, proved the security works, no ?
=== mpt [~mpt@203-167-186-120.dsl.clear.net.nz]  has joined #launchpad
[12:40] <kiko> I lost my commit message
=== kiko cries
[12:40] <lifeless> 'history'
[12:40] <kiko> it's gone
[12:40] <kiko> sent again
[12:40] <lifeless> mail queue ?
=== kiko crosses fingers
=== stub [~stub@203-217-37-199.dyn.iinet.net.au]  has joined #launchpad
[12:42] <kiko-zzz> lifeless, let me know if it looks bad
[12:43] <lifeless> kiko-zzz: it will mail you directly
[12:46] <kiko-zzz> I know
[12:47] <sabdfl> hey stub
[12:47] <stub> Morning
[12:47] <lifeless> omg
[12:48] <lifeless> stub in the morning!!!
[12:48] <kiko-zzz> heh
[12:48] <lifeless> stub: dude, any day to work from here is fine
[12:48] <stub> Kiko gets to see me grumpy-before my-coffee instead of grumpy-im-up-too-late
[12:49] <stub> lifeless: I won't be coming up - need to look after the sick wifey (and I might be contagious too)
[12:49] <ddaa> stub: janitorial db request
[12:50] <lifeless> stub: ok
[12:50] <ddaa> please wipe out all productseries in the "unassigned" and "duplicates" productseries. You can nuke the the "unassigned" and "duplicates" products and the "do-not-use-info-import" project while you are at it.
[12:50] <sabdfl> stub: after coffee, could you check out shift-potemplates-to-branches patch-74 please?
=== mdke [~matt@mdke.user]  has left #launchpad [] 
[12:54] <lifeless> sabdfl: I've found the dragons btw.
[12:55] <lifeless> sabdfl: ... in the libarch codebase. This last set of code has been very hard slogging - I feel like I've melted my brain down.
[12:56] <sabdfl> lifeless: the snakepit
[12:56] <lifeless> yes
[01:02] <lifeless> haha. my current patch size:
[01:02] <lifeless> 287 files changed, 16926 insertions(+), 3513 deletions(-)
[01:03] <lifeless> mm, take out 5K adds for patch logs.
[01:03] <lifeless> 10000 insertions
[01:06] <sabdfl> lifeless: it would be nice to be able to get something out of baz that can sanely be fed to diffstat
[01:07] <lifeless> sabdfl: absolutely. Its on the todo. I wonder if Matthieu would like to do it, its right up his alley.
[01:08] <sabdfl> stub: hope the wifey recovers smoothly
[01:09] <kiko-zzz> lifeless, how's my merge going?
[01:10] <lifeless> kiko-zzz: its building baz now, so I'd say your merge did its thing and you should have mail
[01:10] <lifeless> actually, you are in the queue still
=== kiko-zzz waahs
[01:11] <kiko-zzz> I'm going home!
[01:13] <sabdfl> night kiko-zzz
[01:13] <sabdfl> lifeless: i ran out of disk space today
[01:13] <ddaa> kiko-zzz: I did not know you where hacking on baz now :)
[01:13] <sabdfl> 9.3g of .arch-revlib
[01:13] <lifeless> sabdfl: yup
[01:13] <sabdfl> what's the plan to make baz less wasteful again?
[01:14] <lifeless> sabdfl: the win32friendlyformat library will store one and only one copy of each text, regardless of order of add
[01:14] <lifeless> Win32FriendlyFormats on the arch wiki.
[01:14] <ddaa> sabdfl: did you give library-relink a try, in the meantime it's handy (and has other added bonuses)
[01:14] <lifeless> sabdfl: it can be built when I've finished the current set of work - all its dependencies should be in place.
[01:14] <sabdfl> stub: ok, all tests pass, just waiting for a HALT or a db patchnum from you
=== stub fires off baz switch
[01:15] <sabdfl> ddaa: you mean rm -rf ~/.arch-revlib/*.com* ?
[01:15] <dilys> New Malone bug 1230 filed on product Bazaar by Robert Collins: baz diff <other branch> output is useless for diffstat
[01:15] <dilys> https://launchpad.ubuntu.com/malone/bugs/1230
[01:16] <lifeless> sabdfl: there is a python script that ddaa is referring to that ensures you are optimally using the revlib
[01:16] <lifeless> sabdfl: it can give very significant savings
[01:16] <sabdfl> lifeless: where's that at?
[01:16] <lifeless> ddaa: do you have the coordinates ?
[01:17] <ddaa> sabdfl: http://push.sourcecontrol.net/archives/aaron.bentley@utoronto.ca--baz/library-relink--devel--1
[01:17] <lifeless> sabdfl: not sure offhand, if ddaa isn't either I'll ... there you og
[01:17] <ddaa> I was just assembling them :)
[01:17] <ddaa> You can expect a 50% shrink in your revlib disk usage with that.
[01:18] <ddaa> And it also makes merges faster.
[01:18] <stub> sabdfl: Landing that patch will break staging until we sort the production data
[01:18] <ddaa> use hardlinked source trees to make working on launchpad actually bearable.
[01:18] <sabdfl> stub: is there any production data that will break this?
[01:18] <sabdfl> daf couldn't find any
[01:18] <ddaa> (when working on launchpad, here baz is cpu bound, since I switched to hardlinked trees and a well-linked revlib)
[01:19] <stub> sabdfl: Two productseries
[01:19] <sabdfl> stub: which ones?
[01:19] <stub> (21:42:29) stub: sabdfl: There are only two
[01:19] <stub> (21:42:31) stub:  ddtp-ubuntu | ubuntu
[01:19] <stub> (21:42:31) stub:  drupal      | main
[01:19] <stub> (21:42:45) stub: (product.name | productseries.name )
[01:19] <sabdfl> stub: nup
[01:19] <sabdfl> both of those are fine
[01:20] <sabdfl> they have multiple templates, but all on the same release
[01:20] <stub> ok. I'll run it against staging once my switch has finished
[01:20] <sabdfl> so they will all map nicely to a single productseries
[01:21] <stub> They do? 
=== stub looks at his query again
[01:22] <stub> oh get stuffed no space on device
[01:24] <kiko-zzz> heh
[01:25] <kiko-zzz> staging server shutdown Tue Jul 5 00:21:56 BST 2005
[01:25] <kiko-zzz> Traceback (most recent call last):
[01:25] <kiko-zzz>   File "scripts/pgmassacre.py", line 57, in ?
[01:25] <kiko-zzz>     os.kill(pid, signal)                     
[01:25] <kiko-zzz> OSError: [Errno 3]  No such process
[01:25] <kiko-zzz> Failed to destroy existing launchpad_staging database
[01:26] <kiko-zzz> lifeless, ddaa: what do I do when I get a bunch of
[01:26] <kiko-zzz> kiko@lozenge:~/devel/rocketfuel/launchpad/sourcecode/pygettextpo$ baz status --lint
[01:26] <kiko-zzz> Duplicated ids among each group of files listed here:
[01:26] <kiko-zzz> [...] 
[01:27] <kiko-zzz> it's on pygettextpo, which I don't ever commit to
[01:27] <ddaa> you try to make sense of it and you remove the offending files/ids
=== kiko-zzz will remove IDs and pray
[01:27] <ddaa> anyway, you had a bad mrege
[01:28] <ddaa> it breaks that way when it has conflicting file additions
[01:28] <kiko-zzz> but I only do updates on that tree..
[01:28] <ddaa> sounds unlikely...
[01:28] <sabdfl> i've had that before
[01:29] <kiko-zzz> it's a pygettextpo tree
[01:30] <kiko-zzz> rocketfuel@canonical.com/pygettextpo--devel--0
[01:30] <kiko-zzz> stub, heads up on nightly.sh error outputs
[01:31] <kiko-zzz> now update gives me conflicts, whee
[01:31] <lifeless> kiko-zzz: wowzers
[01:31] <lifeless> kiko-zzz: do an undo -n
[01:32] <kiko-zzz> yeah, doin
[01:32] <sabdfl> what's -n?
[01:33] <lifeless> dont save the output
[01:33] <lifeless> '--no-output'
[01:35] <stub> kiko-zzz: Yup. I'll have to fix pgmassacre.py - it is supposed to be bulletproof.
[01:35] <kiko-zzz> stub, also the failure for the linkchecker
[01:36] <lifeless> going to greasy spoon for brekkie and more changeset brain surgery.
[01:36] <lifeless> bbiab
[01:37] <stub> Ahh... I think there were too updates running simultanously ;-/ 
[01:37] <kiko-zzz> how can that have been?
[01:38] <ddaa> night guys
[01:39] <stub> LinkChecker locking or running 24hours+ - I've been tweaking it but might be making things worse rather than better.
[01:39] <kiko-zzz> weird.
[01:53] <sabdfl> stub: patch ok?
[01:53] <sabdfl> keen to crash, it's late-ish
[01:54] <stub> sabdfl: My revlib is repopulating
[01:54] <sabdfl> stub: ok
[02:09] <jamesh> sabdfl: I've marked your debbugs branch as merge-conditional, so if you've addressed the issues in my last review you can submit the merge
[02:10] <sabdfl> jamesh: last review?
[02:11] <jamesh> sabdfl: mostly the stuff you already replied to.  I just sent a reply to that clarifying the linkMessage() issue I mentioned
[02:11] <stub> Almost there.... stay on target...
[02:18] <cprov> jamesh: hi, there, don't forget gpg-ng, let's merge it tomorrow ... I'm back to buildd which is also in your queue, maybe tomorrow (ohh), but this is a very long and hard review, prepare yourself. I need to go, thank you for care and patience. 
[02:18] <jamesh> I sent a review for it yesterday
[02:19] <jamesh> disapeared :(
[02:19] <sabdfl> jamesh: looks good i'll update the implementation
=== asgeirf [~asgeirf@203-206-229-169.dyn.iinet.net.au]  has joined #launchpad
[02:41] <sabdfl> stub: i'm packing it in, will be up again in a few hours and land it then after your comments
[02:42] <stub> sabdfl: ok. 
=== sabdfl [~mark@sabdfl.silver.supporter.pdpc]  has left #launchpad [] 
[04:14] <dilys> New Malone bug 1231 filed on product The Launchpad by Matthew Paul Thomas: http://launchpad.net/ goes to the wrong place
[04:14] <dilys> https://launchpad.ubuntu.com/malone/bugs/1231
[04:22] <dilys> New Malone bug 1232 filed on product The Launchpad by Matthew Paul Thomas: Can't log in to launchpad.net
[04:22] <dilys> https://launchpad.ubuntu.com/malone/bugs/1232
[05:43] <dilys> Merge to rocketfuel@canonical.com/dists--devel--0: [trivial]  New production config (patch-94: stuart.bishop@canonical.com)
[05:53] <stub> lifeless: tag of production--1.24 hasn't taken - mirror not mirroring I suspect.
[05:58] <dilys> New Malone bug 1233 filed on product Malone by Matthew Paul Thomas: CVE reference editing page has bad title
[05:58] <dilys> https://launchpad.ubuntu.com/malone/bugs/1233
[06:07] <lifeless> stub: done
[06:14] <mpt> yow, chinstrap.ubuntu.com hits the trifecta of Things That Can Be Wrong With a Security Certificate
[06:15] <mpt> * expired
[06:15] <mpt> * unknown CA
[06:15] <mpt> * wrong host
[06:16] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  linkreport.py tweaks (patch-2011: stuart.bishop@canonical.com)
[06:50] <jamesh> mpt: unknown CA isn't necessarily a sign that something is wrong
[06:50] <jamesh> of course, we could install a "Canonical" CA cert with Ubuntu :)
[07:14] <jamesh> stub: do you mind if I leave the "start date" column in the calendar as "dtstart"?
[07:14] <jamesh> stub: that's the name used in the iCalendar spec
[07:15] <stub> jamesh: If it matches the iCalendar spec, yes. I only changed it because it better matches our existing column names.
[07:19] <jamesh> stub: also, my code currently treats a NULL timezone name as UTC.  Would you prefer that I make the column NOT NULL, and set the column to 'UTC' for existing data?
[07:21] <stub> jamesh: Probably better keeping it NULL for now - this way we can tell apart users who have set their timezone to UTC, and users who haven't set their timezone.
[07:25] <stub> lifeless: I'll rollout the next production release now
[07:29] <lifeless> k
[07:30] <mpt> jamesh: confirmation alert == wrong :-)
[07:30] <jamesh> mpt: so we should fix our mozilla-firefox packages not to display the alert?
[07:30] <mpt> perhaps
[07:30] <mpt> the whole SSL trust model is daft
[07:31] <jamesh> mpt: the hostname issue is a real problem: https://bugzilla.ubuntu.com/show_bug.cgi?id=1278
=== mpt wonders why "Log Out" isn't working
[07:31] <jamesh> the certs need to have a subjectAltName field listing the additional DNS names used by each server
=== mpt [~mpt@203-167-186-120.dsl.clear.net.nz]  has joined #launchpad
[07:35] <mpt> well, that didn't work
[08:02] <stub> http://bazaar.canonical.com/packages/debs/./Release: Unable to find expected entry  Sources in Meta-index file (malformed Release file?)
[08:19] <SteveA> morning
[08:35] <SteveA> why can't i mark this bug fixed? https://launchpad.ubuntu.com/products/launchpad/+bugs/1193/+edit
[08:35] <SteveA> i get a system error when i try
[08:54] <jamesh> SteveA: by the way, your launchpad--unittest-authentication--0 branch has been sitting unmerged for a while.
[08:55] <stub> SteveA: Try again - I still had rollout stuff to finish off
[08:56] <SteveA> jamesh: yeah, i discovered that it probably isn't needed.
[08:56] <jamesh> oh?
[08:56] <SteveA> there may be an equivalent facility already available in the unit testing machinery.
[08:56] <SteveA> but, i need to check this out.
[08:56] <SteveA> thanks for the reminder anyway
[08:57] <SteveA> stub: hmm... a problem
[08:59] <stub> SteveA: Hmm.... an unhelpful hmm....
=== SteveA gets a screenshot
[09:00] <SteveA> https://chinstrap.ubuntu.com/~stevea/malone.png
[09:01] <SteveA> I have a [save changes]  button, but no means to make any changes
[09:01] <SteveA> seems to be a regression from just before that roll-out
[09:01] <SteveA> BjornT, mpt: is that how it is supposed to look?
[09:02] <mpt> no
=== mpt blames kiko-zzz because he's asleep
[09:03] <mpt> and also because he's the only one who touched the task page recently, afaik
[09:03] <SteveA> well, it's screwed, and i can't close bugs
[09:03] <stub> A regression from Friday you mean
[09:04] <mpt> SteveA: oh, you're logged in but you can't edit?
[09:04] <mpt> that's bad
[09:04] <SteveA> yeah, look at the screen shot
[09:04] <SteveA> stub: a regression from production 1 hour ago
[09:04] <stub> Yup, which was tagged from Friday's code
[09:05] <stub> Heh... *I* can edit it ;)
[09:05] <SteveA> WTF would it give me a [save changes]  button, but nothig to change?
[09:05] <stub> And I don't know why - you are an administrator of both the launchpad and the admins teams, just like me
[09:05] <mpt> because someone put the button outside a tal:block by mistake
[09:05] <mpt> possibly
=== mpt looks
[09:06] <stub> Argh - I take that back
=== stub gets a system error submitting
[09:08] <mpt> <div class="actions" tal:condition="context/required:launchpad.Edit"><input type="submit" ... value="Save Changes" ...>
[09:08] <stub> Ahh... but I know about that and can fix
=== stub inserts the KarmaAction data
[09:09] <stub> ok - I can happily close that bug
=== BjornT could edit it
[09:10] <SteveA> aha
[09:10] <mpt> I can't, but I still get the button
[09:11] <SteveA> i see what is happening
[09:11] <SteveA> https://launchpad.ubuntu.com/products/launchpad/+bugs/1193
[09:11] <SteveA> note the URL
[09:11] <SteveA> i get a [save changes]  button
[09:11] <SteveA> but no opportunity to make changes
[09:11] <SteveA> https://launchpad.ubuntu.com/products/launchpad/+bugs/1193/+edit
[09:11] <SteveA> I can edit
[09:11] <SteveA> looks like the default view was changed to "viewing" not "editing", but someone left a button in there
[09:11] <mpt> so that tal:condition is wrong
[09:12] <SteveA> also, when i press "save changes", nothing *appears* to happen
[09:12] <SteveA> that is, the page re-renders exactly the same as before
[09:12] <SteveA> i'd expect to be taken to a "view" page
[09:12] <SteveA> where i can see the effects of my changes
[09:12] <jamesh> possibly it is using required:launchpad.AnyPerson instead of required:launchpad.Edit
[09:12] <SteveA> or at least have a message saying "your changes have been made"
[09:12] <BjornT> yeah, i noticed that as well
[09:13] <mpt> jamesh: no, see above
[09:13] <BjornT> SteveA: did change it to fixed?
[09:14] <SteveA> yes
[09:14] <SteveA> and i received an email about it
[09:14] <BjornT> i got an mail saying that stub changed it to fixed, so it could be that we edited it at the same time :)
[09:15] <BjornT> yeah, now when i edited it i got a message saying so
[09:15] <stub> I changed it to fixed
[09:15] <stub> (and was first)
[09:16] <SteveA> https://launchpad.ubuntu.com/products/launchpad/+bugs
[09:16] <SteveA> this table is odd
[09:16] <SteveA> it looks as if the id of bugs is a checkbox
[09:16] <SteveA> and the severity is a number
[09:17] <SteveA> mpt: is this wrong for you too?
[09:17] <SteveA> the title column is small
[09:17] <SteveA> ah --
[09:17] <mpt> yes, that's wrong
[09:17] <SteveA> basically, the checkbox column is not reflected in the table heading
[09:17] <SteveA> so it's screwed
[09:17] <mpt> The checkbox column isn't supposed to have a heading
[09:18] <mpt> Any heading it could possibly have would make the column far too wide
[09:18] <mpt> That's why I combined the heading for the checkbox column and the next column
[09:18] <mpt> and now someone's busted it
[09:19] <SteveA> nbsp ?
[09:19] <SteveA> https://launchpad.ubuntu.com/products/launchpad/+bugs
[09:19] <SteveA> usability problems here
[09:19] <SteveA> it was not immediately clear to me that i was seeing only one batch of bugs
[09:20] <SteveA> because at the end of the table, it just ends
[09:20] <SteveA> it has no indication that there are more
[09:20] <mpt> yes, the navigation should be at the end of the table
[09:20] <SteveA> a "see next N bugs" link at the bottom of the table would help a lot
[09:20] <mpt> rather than at the beginning
[09:20] <SteveA> also, i want to see all 60 open bugs
[09:20] <mpt> I keep telling bradb-away to do that
[09:20] <SteveA> but even if i change the batch_end in the URL query, i can't see them
[09:21] <mpt> but he won't because sabdfl says no
[09:21] <SteveA> says no to what?
[09:21] <SteveA> being able to change the batch_end ?
[09:21] <SteveA> being able to view all bugs?
[09:21] <mpt> being able to view all bugs
[09:21] <SteveA> i'd be happy with a batch size of 200 or so
=== sabdfl [~mark@host217-37-231-22.in-addr.btopenworld.com]  has joined #launchpad
[09:21] <mpt> (actually, being able to view 500 of them, which is much the same thing in most cases)
[09:22] <SteveA> so, i don't need to see *ALL* bugs
[09:22] <BjornT> mpt: setting batch_end manually should still work, otherwise it shouldn't be in the url
[09:22] <SteveA> just a reasonable number
[09:22] <mpt> BjornT: Agreed, that's a bug
[09:22] <SteveA> 20 is just far too few
[09:22] <dilys> New Malone bug 1234 filed on product The Launchpad by Stuart Bishop: Gina is an unmaintainable mess of command line options, environment variables and shell scripts
[09:22] <dilys> https://launchpad.ubuntu.com/malone/bugs/1234
[09:22] <SteveA> morning sabdfl 
[09:22] <SteveA> is it right that you object to showing more than 20 bugs in /products/launchpad/+bugs  ?
[09:23] <sabdfl> morning guys
[09:23] <SteveA> i'm finding the current page very frustrating for triaging my bugs, and going into them to change status. 
[09:23] <sabdfl> stubarooney,, any joyous news?
[09:23] <SteveA> far too much mousing around to get the work done.
[09:23] <Burgundavia> mpt, what did you think of the idea of moving the bug type links into tabs?
[09:24] <mpt> Burgundavia: "did"?
[09:24] <Burgundavia> mpt, do
[09:24] <mpt> I don't like the idea of nested tabs
[09:24] <Burgundavia> how would they be nested?
[09:25] <mpt> and tabs in Malone are scheduled to be used for (for example)  "Firefox Bugs", "Report a Bug", "Show Reports", "Admin"
[09:25] <Burgundavia> ah, ok
[09:25] <stub> sabdfl: if you mean that db patch, it is reviewed and fine. Check your email.
[09:25] <Burgundavia> the other idea was to move those links to the bottom of the page
[09:25] <Burgundavia> the reason I suggested tabs, as it makes ajax-ing the thing easy
[09:26] <mpt> Burgundavia: we could also do that with a <select>
[09:26] <Burgundavia> yes
[09:26] <SteveA> BjornT: https://launchpad.ubuntu.com/products/launchpad/+bugs/+index?batch_start=60&batch_end=61
[09:26] <SteveA> gets me a system error
[09:27] <SteveA> this was produced by clicking "next" from https://launchpad.ubuntu.com/products/launchpad/+bugs/+index?batch_start=40&batch_end=60
[09:27] <SteveA> ah, okay
[09:27] <SteveA> here's what happened
[09:27] <SteveA> i was using that bugs page in one tab, and opening bugs in a new tab
[09:27] <Burgundavia> mpt, basically, that view is current too wide
[09:27] <SteveA> i marked one of these as fixed
[09:27] <mpt> Burgundavia: too wide, or too narrow?
[09:27] <SteveA> then i went back to the list, and asked to go to the next batch
[09:27] <Burgundavia> mpt, I mentioned all this to bradb
[09:27] <Burgundavia> mpt, the page as a total is too wide
[09:28] <SteveA> however, on this request, there were fewer bugs in the results
[09:28] <Burgundavia> bug list + actions portlet
[09:28] <sabdfl> stub: rock, thanks
[09:28] <mpt> Burgundavia: oh, right
[09:28] <SteveA> so, the system asked itself to go to a non-existent batch
[09:28] <SteveA> so i got a system error
[09:28] <Burgundavia> mpt, I have 1280x1024 and it fills my screen
[09:28] <mpt> Burgundavia: agreed, I'd like the table to take up the whole width
[09:28] <SteveA> what should happen, is i get a normal batch navigation thing saying "no more results" instead of an error
[09:28] <Burgundavia> and move the actions portlet to inline?
[09:28] <mpt> Burgundavia: yes
[09:28] <Burgundavia> ok
[09:29] <Burgundavia> glad we are thinking along the same paths
[09:29] <sabdfl> SteveA: if that was your landing that neatened up the make check display, then THANK YOU!
[09:29] <SteveA> sabdfl:  the fascist output?  yeah
[09:29] <SteveA> it was annoying me too much
[09:29] <mpt> Burgundavia: https://launchpad.ubuntu.com/malone/bugs/936
[09:30] <BjornT> SteveA: can you file a bug about it? you can assign it to me
[09:30] <SteveA> BjornT: okay
[09:30] <SteveA> mpt: in the box on that bug list, "file a bug" is not underlined, but the links under "bug statistics" are.
[09:30] <SteveA> it meant that I had to hunt around for a "file a bug" link
[09:34] <dilys> New Malone bug 1235 filed on product The Launchpad by Steve Alexander: Reaching the end of a batch of bugs gives a System Error
[09:34] <dilys> https://launchpad.ubuntu.com/malone/bugs/1235
[09:35] <SteveA> how do i assign someone to work on a bug?
[09:35] <SteveA> i cannot find this in the UI
[09:35] <SteveA> oh, i found it
[09:36] <SteveA> there's this box saying "The Launchpad" and various things, with a blank space for an "assignee".  I have to click on "The Launchpad", and then I'm taken to a page where i can change it.
[09:36] <SteveA> that's not entirely obvious
[09:36] <SteveA> and, i'm *sure* i've done this before, but somehow managed to forget that's what i'm supposed to do.
[09:38] <SteveA> mpt: i'm on this page: https://launchpad.ubuntu.com/products/launchpad/+bugs/1235/+edit
[09:38] <SteveA> In the "bug status" box, there's a link saying "The Launchpad".  When I click on it, I don't get to "The Launchpad" product.  I get back to where I already am.
[09:39] <dilys> New Malone bug 1236 filed on product Malone by Matthew Paul Thomas: Malone column headings are all wrong
[09:39] <dilys> https://launchpad.ubuntu.com/malone/bugs/1236
[09:39] <BjornT> SteveA: i think kiko-zzz fixed that one
[09:40] <SteveA> cool
[09:42] <dilys> New Malone bug 1237 filed on product The Launchpad by Steve Alexander: Batches of bugs are way too short
[09:42] <dilys> https://launchpad.ubuntu.com/malone/bugs/1237
[09:44] <mpt> SteveA: Yes, that portlet seems rather pointless to me
[09:45] <sabdfl> SteveA: wait for my landing in 5 mins
[09:45] <mpt> SteveA: The reporter and date can go at the top like they do on the bug page, and the rest of it is redundant
[09:47] <sabdfl> stub: i wonder if it would be possible to feed linkchecker some URL templates, and have it analyse the site for errors, GROUP BY those templates?
[09:47] <sabdfl> so, for example, we could feed it /products/$Product.name/ and it would then COUNT the number of times the same error happened on pages matching that URL, and report that number
[09:48] <stub> sabdfl: We get the output of linkchecker in a csv - we can do whatever we like with it. We just need to know what and spend the time doing it.
[09:48] <sabdfl> stub: cool - this would allow us to find the "topcrashers" quite easily
[09:49] <stub> sabdfl: I've started hacking up linkreport.py, now in rocketfuel, which is designed to be a daily report but is probably too noisy
[09:50] <stub> It is only a start, but a starting point if anyone wants to do some more serious reporting
[09:50] <sabdfl> excellent, thanks stub!
[09:51] <SteveA> stub: do you think we'll be able to get to the stage where a failing page on staging is a major event, and can cause an angry email to the list?
[09:51] <stub> I personally think the goal should be to fix all the broken pages so complex reports aren't required ;)
[09:51] <dilys> New Malone bug 1238 filed on product Malone by Matthew Paul Thomas: Can't subscribe someone after reporting a bug
[09:51] <dilys> https://launchpad.ubuntu.com/malone/bugs/1238
[09:52] <stub> SteveA: Yes - linkreport.py will do that, but it might be a bit noisy (you will get a rather long angry email if your stuffup breaks 5000 URLs...)
[09:52] <SteveA> a simple email saying "5000 URLs broken, see http://xxxx" would do
[09:53] <SteveA> but then again, what's 5000 lines on a development mailing list?
[09:53] <stub> We have to get the notifications working - there are a number of broken pages that have been broken *since linkchecker has been running* that have not been fixed, including some that look like pretty trivial ZCML stuffups.
[09:53] <SteveA> there are a bunch that are due to a bug in the login machinery
[09:53] <SteveA> where a link with ?foo=1&foo=2  will cause a system error
[09:53] <stub> So people either aren't taking resposibility for broken pages, or it isn't clear to people that their pages are broken
[09:54] <SteveA> i'll fix that today, and it should greatly reduce the number of failed links.
[09:54] <stub> SteveA: I'm talking about some links  where '{context}' has leaked into the URL - probably a forgotten $ or something
[09:54] <SteveA> stub: can you grep those out?
[09:54] <stub> But it might just be lost in the noise
[09:54] <SteveA> and send a mail to the list with just those in it?
[09:56] <SteveA> I did a grep for "[^$] [{] "
[09:56] <SteveA> and didn't find anything significant
[09:57] <stub> Against what? The current linkchecker report is stuffed (problem running last night - there is another run going on now)
[09:58] <SteveA> okay
[09:59] <SteveA> i did a grep against .pt and .zcml files
[09:59] <SteveA> in launchpad
[10:13] <stub> So far running 4.7 hours and still no end in sight (todo list growing rather than shrinking) ;-( I've tried optimizing memory usage,  but I think I'll need to scrap that work and put together a PostgreSQL backend for memory usage problems. Hopefully we can continue doing a full daily scan for a while longer.
[10:23] <sabdfl> stub: what's the trick to getting the db working on breezy?
[10:23] <sabdfl> i added plpython
[10:23] <stub> sabdfl: I don't know - I haven't used breezy.
[10:23] <sabdfl> IOError: [Errno 2]  No such file or directory: '/usr/share/postgresql/contrib/tsearch2.sql'
[10:24] <stub> sabdfl: I believe that some of the files have moved location, so some of the db setup scripts are broken. I think Keybuk was playing with this, but I don't know if he tweaked anything or gave it up as a bad job.
[10:25] <sabdfl> that looks like it, yes
=== carlos [~carlos@69.Red-80-33-181.pooles.rima-tde.net]  has joined #launchpad
[10:27] <stub> It might be a simple case of sticking some if statements in fti.py to cope with the possible locations of tsearch2.sql. Also, fti.py runs a patch to tsearch2 (stored in database/schema) -- this patch is not necessary under 8.0.
[10:28] <carlos> morning
[10:36] <sabdfl> stub: would it be possible to store some locations in the config?
[10:37] <sabdfl> is anybody else seeing foaf test failures on chinstrap that do not show up on te local machine?
[10:38] <sabdfl> make check gives me a clean bill of health, but pqm is complaining of test failures in mege-people and delete-email tests
[10:38] <sabdfl> SteveA: is there any way to run just one "story", like the foaf page tests?
[10:38] <stub> sabdfl: I'd rather just hard code some locations in fti.py with some 'if os.path.exists(..)' statements in there. We only have two different systems to support, and we still have to have 7.4 and 8.0 specific branching in the code to cope with the tsearch2 patch I mentioned.
[10:39] <sabdfl> stub: i was thinking we could grow the config system to allow local prefs on a per-machine basis (outside of revision control)
[10:39] <sabdfl> that could then deal with the 8.0 and 7.4 issues
[10:39] <sabdfl> as well as the breezy / hoary issues
[10:40] <SteveA> sabdfl: no.  you can run all of the page tests, or a single page test .txt file, but not one story.
[10:40] <SteveA> to run all of the page tests, python test.py -f canonical.launchpad.ftests.test_pages
[10:40] <sabdfl> SteveA: does the matching not support globs, like --test="foaf/*"
[10:41] <SteveA> the 'foaf/' part of it isn't used in the name
[10:41] <SteveA> just the name of the file
[10:42] <sabdfl> SteveA: any idea what could be behind these mysterious test failures on chinstrap that don't show up here?
[10:42] <SteveA> i don't know anything about test failures on chinstrap
[10:42] <SteveA> my recent merges all worked.
[10:42] <SteveA> can you forward me a rejection email from pqm?
[10:42] <sabdfl> it appears that the server gets an internal server error
[10:43] <sabdfl> but since i can't see the traceback...
[10:43] <stub> sabdfl: I don't see what we gain, except for an extra knob for people to break and more documentation for people to read. We don't need to support arbitrary operating systems and installation directories - just two.
[10:44] <sabdfl> well, two releases (current and dev) and soon two version of pg (7.4 and 8.0)
[10:44] <SteveA> stub: i want a way to say that "chunky diff is turned off in general, but can be turned on on an individual developer's machine, and won't be committed"
[10:44] <SteveA> sabdfl: turn chunky diff off in your launchpad.conf, commit it, mirror, and try to merge in pqm again
[10:44] <SteveA> the chunky diff will be off for the tests, so the output you'll get back will have the full traceback in it
[10:45] <stub> SteveA: You can do that now by creating your own config
[10:45] <stub> SteveA: The comments in configs/default/launchpad.conf describe this I think
[10:45] <SteveA> stub: does that involve changing any files that might be committed ?
[10:45] <sabdfl> SteveA: all that will do is tell... oh. perfect. ok!
[10:45] <stub> SteveA: No - You create a configs/+myconfig directory containing whatever config you like, then make run LPCONFIG=+myconfig 
[10:46] <stub> SteveA: We could streamline this, but the mechanics are all there
[10:46] <SteveA> a 'make myconfig' option would help
[10:46] <SteveA> that sets it up based on launchpad.conf, but with chunkydiff turned off
[10:46] <SteveA> um, on
[10:46] <SteveA> make developer-config
[10:46] <SteveA> then , when launchpad.conf changes, these can just be nuked
[10:47] <SteveA> make +developerconfig be used in preference to the default, when it is present
[10:47] <stub> I think we want some sort of inheritance in there, which would be useful for production rollouts and stuff, but that involves migrating from ZConfig to something custom I think.
[10:47] <sabdfl> errr... stub, that's what i was just suggesting, and you said it was a terrible idea three minutes ago :-)
[10:47] <SteveA> can you not just read in one base zconfig file, process it, and then read in another, and allow the other to override / add values?
[10:48] <SteveA> that would be a minor change to what we have already
[10:48] <stub> sabdfl: You were suggesting putting the os/tsearch2 specific settings in the config, wern't you?
[10:48] <stub> SteveA: I have no idea ;)
[10:49] <sabdfl> stub: i was suggesting allowing that, and allowing a non-RCS override config file, which would inherit the default conf
[10:49] <SteveA> stub: DOIT ;-)
=== stub goes on a quick shopping run for 'icky wife
[10:49] <sabdfl> so people can turn of chunkydiff locally, or on, wihtout fear of comttting that
[10:49] <sabdfl> and pqm can always have chunkydiff off
[10:49] <sabdfl> so we see tracebacks
[10:49] <SteveA> we could make test_on_merge force chunkydiff to be off
[10:50] <SteveA> um... i think...
[10:50] <stub> SteveA: In my Copious Spare Time (tm). We don't *need* it and there are higher priority things to do right now.
[10:50] <stub> SteveA: Yup - that would work. Or even hardcode 'If I am chinstrap' in there.
[10:50] <SteveA> at least, file a bug about it so we don't have to have this discussion again.
=== stub runs off on a quick shopping trip for 'icky wife
[10:51] <sabdfl> a test failure on pqm SHOULD have chunkydiff off, because it's unlikely and you want the max info back
=== sabdfl heads to the office
=== sabdfl [~mark@sabdfl.silver.supporter.pdpc]  has left #launchpad [] 
[11:03] <dilys> New Malone bug 1239 filed on product Bazaar by Bjorn Tillenius: baz: uncaught exception: -1:(conflict applying patch in arch_build_revision)
[11:03] <dilys> https://launchpad.ubuntu.com/malone/bugs/1239
=== stub [~stub@203-217-37-199.dyn.iinet.net.au]  has left #launchpad [] 
=== stub [~stub@203-217-37-199.dyn.iinet.net.au]  has joined #launchpad
=== sabdfl [~mark@217.205.109.249]  has joined #launchpad
[11:44] <daf> jamesh: around?
[11:44] <jamesh> daf: yeah
[11:44] <daf> jamesh: did you get my mail about the imports branch?
[11:44] <jamesh> daf: yeah.  I haven't done the followup review
[11:44] <daf> ok
[11:45] <daf> in retrospect, I should probably have made those later changes on another branch
[11:49] <sabdfl> BjornT: interesting thought: attachments are bug-wide, but patches are possibly context-specific
[11:50] <sabdfl> so it seems to me that an attachment should be linked to Bug, and if it's a patch for a context, that should be recorded on BugTask
[11:50] <sabdfl> maybe
[11:51] <BjornT> yeah maybe. seems complicated, though
[11:54] <sabdfl> BjornT: i would also like to retain the BugAttachment.message link
[11:54] <sabdfl> so in the web UI, when you display the message, you can include a link to the attachment from that message
[11:54] <sabdfl> so say i'm scrolling through the messages, and i read about an attachment, there's a link right there to it
[11:55] <sabdfl> i'll mark up the spec
[12:00] <BjornT> sabdfl: so, when you add an attachment, you have to add a comment as well? kiko threatened to add "." as a comment in that case :)
[12:01] <BjornT> we could interleave the attachments with the comments, even without linking to a message, if we'd include datecreated, or improved the bug activity
[12:05] <dilys> Merge to rocketfuel@canonical.com/launchpad--production--1.24: Multi-backend production configs (patch-1: stuart.bishop@canonical.com)
[12:27] <daf> SteveA: hello
[12:28] <SteveA> yes
[12:29] <daf> I think I may have found a bug in the menus
[12:29] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Multi-backend production configs (patch-2012: stuart.bishop@canonical.com, rocketfuel@canonical.com)
[12:29] <daf> so I tried to access the +debug-menus page
[12:29] <daf> but got a zope.publisher.interfaces.NotFound
[12:30] <SteveA> give me the url you tried
[12:30] <daf> http://localhost:8086/distros/ubuntu/hoary/+sources/evolution/+pots/evolution-2.2/af/+translate/+debug-menus
[12:30] <SteveA> is +translate a view ?
[12:31] <SteveA> is it a page?
[12:31] <daf> yes
[12:31] <SteveA> then you need to replace that with +debug-menus
[12:31] <daf> ah
[12:32] <daf> hmmmmm
[12:32] <daf> this is an interesting one
=== daf tries to explain
[12:34] <daf> well, the symptom is this:
[12:34] <daf> when I'm looking at /evolution-2.2/af/, the Translations faces is selected but not linked
[12:34] <daf> when I'm looking at /evolution-2.2/af/+translation, the Translations facet is selected and linked
[12:36] <SteveA> daf: i'm busy with the import fascist.  can you file me a bug?
[12:36] <daf> certainly
[12:39] <dilys> New Malone bug 1240 filed on product The Launchpad by Dafydd Harries: selected facet menu being linked or not linked in a confusing manner
[12:39] <dilys> https://launchpad.ubuntu.com/malone/bugs/1240
[12:43] <daf> hmm, that's interesting
[12:43] <daf> http://localhost:8086/products/evolution/+bugs doesn't have facet menus
[12:47] <carlos> BjornT, hi, around?
[12:47] <BjornT> carlos: hi
[12:47] <carlos> BjornT, about your question if POTemplate should be launchpad.Public or not
[12:47] <carlos> BjornT, that part is the normal view 
[12:48] <carlos> the +edit for that lets you change a POTemplate is under Launchpad.Edit permission
[12:48] <carlos>  s/for//
[12:49] <daf> jamesh: a quick suggestion for the pending reviews page -- could it link to the wiki page?
[12:49] <daf> jamesh: it would make switching between the two a bit easier :)
[12:52] <daf> carlos: do you know what the problem is with SchoolTool in Rosetta?
[12:52] <carlos> daf, I didn't see at it 
[12:52] <daf> https://launchpad.ubuntu.com/products/schooltool/+translations
[12:52] <carlos> wasn't it fixed with mark's changes?
[12:52] <BjornT> carlos: i asked, since generally you shouldn't rely on web ui permissions. why can't edits of POTemplate be restricted by launchpad.Edit? (this issue won't block the merge, though)
[12:53] <carlos> BjornT, I think I don't get you
[12:53] <daf> carlos: see that link
[12:53] <carlos> BjornT, If I change it to launchpad.Edit, the users will not be able to view the potemplates, right?
[12:54] <carlos> daf, that's a broken .pot upload
[12:54] <daf> ok
[12:54] <daf> do we have the .pot file?
[12:54] <carlos> daf, we should not show anything until the .pot file is imported
[12:54] <carlos> daf, don't know, just ask for it now that we export it :-D
[12:55] <daf> heh
[12:55] <daf> do we have notifications for broken PO template uploads?
[12:56] <carlos> not yet
[12:56] <carlos> daf, we talked about it already on Friday...
[12:56] <daf> that seems like something the PO import script should do
[12:56] <daf> we did?
[12:57] <carlos> daf, if it was not friday, it was last week
[12:57] <daf> mkay
[12:58] <SteveA> https://chinstrap.ubuntu.com/~dsilvers/paste/filesp6IpR.html
[12:58] <SteveA> That's the output from the new import fascist
[12:58] <SteveA> daf, carlos: there seem to be only one or two violations in Rosetta code.  Well done.
[12:58] <daf> thanks, Steve
[12:58] <daf> I believe I've fixed some of that browser code already
[12:58] <daf> on my --import-fascism-- branch
[12:59] <carlos> daf, good work
[12:59] <SteveA> i want to get people fixing this stuff before i merge the fascist.
[01:00] <BjornT> carlos: you can have one <allow attributes=[attributes to be viewable]  /> and one <require permission="launchpad.Edit" set_attributes=[editable attributes]  />
[01:00] <daf> I didn't get much response when I last brought it up on the list
[01:00] <SteveA> daf: is there anything stopping your merging your fascism branch?
[01:00] <BjornT> carlos: although, since you have IEditPOTemplate, maybe you want <require... set_schema="IEditPOTemplate" /> instead
[01:00] <SteveA> daf: are there items in that pasted text that you can add to your fascism branch?
[01:00] <daf> I'm awaiting a review from jamesh 
[01:01] <daf> I expect there are
[01:01] <carlos> BjornT, hmm, not sure if it changed, but without the set_attributes I'm not able to read those attributes either
[01:01] <carlos> BjornT, I want to remove the IEditPOTemplate difference (need to talk with daf first)
[01:01] <carlos> BjornT, it's confusing, and we are the only ones using it atm (as far as I know)
[01:02] <carlos> so we are mixing edit and readonly methods between both interfaces
[01:02] <carlos> and it's a mess
[01:02] <SteveA> daf: it says "needs reply"
[01:03] <daf> SteveA: I've updated it on the PendingReviews page to "needs review"
[01:03] <daf> SteveA: it would be nice if I could run the new fascist here to see which ones I haven't fixed yet
[01:03] <SteveA> carlos: i did some design work with tres at europython.  we'll be getting rid of IReadXXX and IEditXXX interfaces in the nearish future.
=== ddaa [~ddaa@marvin.xlii.org]  has joined #launchpad
[01:04] <carlos> SteveA, get rid == remove or use it 
[01:04] <SteveA> daf: steve.alexander@canonical.com--z8/launchpad--trivial--0, mirroring now
[01:04] <daf> get rid of == to remove
[01:04] <BjornT> carlos: yeah, it's confusing. but then you should be able to do <allow interface="IPOTemplate" /> and <require permission="launchpad.Edit" set_schema="IPOTemplate" />
[01:04] <daf> SteveA: excellent, thanks
[01:04] <SteveA> carlos: use a cleaner mechanism to specify which parts of an interface are for reading and which are for writing
[01:04] <ddaa> sabdfl: why do you want to remove the +sourceadmin links from the product pages?
[01:05] <SteveA> daf: mirrored
[01:05] <carlos> SteveA, should we wait then or could I merge IPOTemplate with IEditPOTemplate and fix it with the new design later?
[01:05] <SteveA> don't wait
[01:05] <SteveA> fix stuff that you need to fix now
[01:05] <carlos> SteveA, ok
[01:05] <daf> SteveA: all traversal functions should be in browser/traversers.py, yes?
[01:05] <SteveA> daf: no
[01:06] <SteveA> i'm doing some work on that kinda right now
[01:06] <SteveA> best not to move traversers around
[01:06] <carlos> BjornT, will that let me access all fields as readonly from the view?
[01:06] <SteveA> so you won't conflict with me
[01:06] <daf> ok
[01:06] <BjornT> carlos: yes, if the user doesn't have launchpad.Edit, they will be readonly
[01:07] <carlos> ok
[01:07] <carlos> BjornT, thanks
[01:08] <daf> carlos: can we kill TranslationEffort dead dead dead?
[01:08] <BjornT> np
[01:09] <carlos> daf, sure
[01:09] <daf> hurrah
[01:09] <carlos> daf, is the DB table still there? sabdfl, can we remove it too?
[01:11] <daf> yep, the table's still there
[01:11] <carlos> mpt, dude, the new launchpad look is cool! :-)
=== SteveA wonders where all the brazillians are
[01:11] <mpt> thanks carlos
[01:12] <daf> mpt: yep, it looks very nice
[01:13] <SteveA> daf: https://launchpad.ubuntu.com/malone/bugs/1240
[01:13] <SteveA> daf: you didn't include the output of +debug-menus
[01:13] <daf> oops, right
[01:15] <daf> I've pasted it there
[01:17] <SteveA> daf: is the translate link the DefaultLink?
[01:17] <daf> the interfaces code seems to have a huge amount of cargo-culted imports
[01:17] <daf> SteveA: hmm, the debug output doesn't tell you that?
[01:18] <SteveA> no, i need to improve it to tell me that
[01:18] <daf> ok
[01:18] <SteveA> i should also improve it to say where the menus are defined
[01:18] <daf> the translations facet is default, yes
[01:18] <daf> and the overview item is the default in the app menu
[01:19] <SteveA> but, there is no problem with the app menu
[01:21] <SteveA> daf:  can i review your import fascism ?
[01:23] <daf> if it's ok with James, it's fine by me
[01:25] <jamesh> daf/SteveA: I don't mind.
[01:26] <SteveA> * Applying 1 revisions (in reverse): . done.
[01:26] <SteveA> hahaha
[01:26] <jamesh> it is applying the reverse of the patch
[01:26] <jamesh> not applying one patch in reverse order
[01:26] <SteveA> it sounds very funny
=== jamesh thinks signedcocs sounds funny
[01:29] <SteveA> daf: approved
[01:33] <daf> SteveA: thanks
[01:33] <daf> SteveA: I'm have a few more changes I'm about to commit
[01:34] <daf> SteveA: based on the new fascist
[01:34] <SteveA> if they're just cleaning up imports, formatting of imports, __all__ etc. then they're trivial
[01:34] <daf> yep, they are
[01:34] <SteveA> so, my fascist says 21 database, 91 imports without __all__, 27 imports of names not in __all__
[01:34] <daf> trivial changes in large quantities :)
[01:35] <SteveA> what does yours say now?
[01:35] <daf> just a second...
[01:35] <SteveA> i got a quick value, from --test=menus.txt
[01:35] <daf> yes, that's a good way to do it
[01:35] <daf> well, an easy way to do it
[01:36] <daf> just pulling in your fascist
[01:37] <daf> SteveA: I've just mailed you about the pyflakes harness
[01:37] <SteveA> ok
[01:41] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: PoTemplateAdmin changes r=spiv,bjornt (patch-2013: carlos.perello@canonical.com)
[01:41] <daf> oh, bother, this is not a full launchpad tree, so I can't run tests here
[01:41] <daf> just a moment
[01:43] <carlos> finally....
[01:43] <daf> carlos: congratulations :)
[01:43] <carlos> daf, thanks
[01:43] <carlos> daf, did you fixed the missing import kiko told us on Friday?
=== cprov [~cprov@200-171-140-32.dsl.telesp.net.br]  has joined #launchpad
[01:44] <carlos> daf, I'm looking into it atm but it's there....
[01:44] <carlos> kiko-zzz, ?
[01:44] <daf> what missing import?
[01:44] <SteveA> cprov: hi
[01:45] <cprov> SteveA: hi, morning ..
[01:45] <SteveA> cprov: https://chinstrap.ubuntu.com/~dsilvers/paste/filesp6IpR.html
[01:45] <SteveA> that's the latest import fascist output 
[01:45] <SteveA> daf is about to merge some fixes to this
[01:45] <SteveA> after daf has merged, it would be good to get the areas of code you're involved in fixed up
[01:45] <SteveA> mostly it's a matter of making sure there's an __all__ in interfaces, database, and browser code
[01:46] <SteveA> and that the __all__ is complete
[01:46] <carlos> daf, IPersonSet
[01:46] <daf> well, it may be that the __all__ is complete and other modules are importing code they shouldn't
[01:46] <daf> carlos: which file?
[01:46] <SteveA> daf: that is true
[01:46] <cprov> SteveA: sure, I think it's already solved in my branches pending review, but I'll ensure, tks
[01:47] <SteveA> cprov: note that the fascist has become more facist today
[01:47] <SteveA> i haven't merged the new fascist yet
[01:47] <SteveA> because it produces a lot of output right now
=== cprov noted and imagine where it'll stop ;)
[01:48] <SteveA> depending on how much daf's branch fixes, i'll merge it later today
[01:48] <SteveA> cprov: well, we'll have the fascist raising exceptions before long
[01:49] <cprov> SteveA: just joking, having facist test suite is good, reduce the future pain caused my silly mistakes 
[01:50] <SteveA> after the exceptions, we'll have the facsist administering electric shocks through your hkeyboard
[01:51] <daf> SteveA: 5 DB import violations, 70 from * without __all__, 21 imports of names not in __all__
[01:51] <SteveA> down from  21 database, 91 imports without __all__, 27 imports of names not in __all__
[01:52] <SteveA> nice work on the database ones
[01:52] <SteveA> those are by far the most significant
[01:52] <daf> I'm pleasantly surprised by that, actually
[01:52] <SteveA> and the ones i want raising exceptions soonest
[01:53] <daf> these are the remaining offenders:
[01:53] <SteveA> what are the five remaining database violations?
[01:53] <daf>     canonical.launchpad.browser.binarypackagename
[01:53] <daf>     canonical.launchpad.browser.bounty
[01:53] <daf>     canonical.launchpad.browser.bugtracker
[01:53] <daf>     canonical.launchpad.browser.codeofconduct
[01:53] <daf>     canonical.launchpad.browser.distribution
[01:55] <daf> apart from bugracker, these are all related to use of CustomWidgetFactory
[01:55] <daf> right, merge submitted
=== debonzi [~debonzi@200-161-81-234.dsl.telesp.net.br]  has joined #launchpad
[02:04] <daf> https://chinstrap.ubuntu.com/~dsilvers/paste/fileopNfjH.html
[02:04] <daf> morgs: ^^
[02:04] <daf> missing import in browser/project.py?
[02:05] <daf> debonzi: ^^
[02:05] <daf> some missing imports in browser/{distribution,distrorelease}.py?
[02:05] <daf> who owns addview.py?
[02:06] <carlos> daf, infrastructure team?
[02:06] <daf> I guess so
[02:06] <daf> is that spiv and Steve?
[02:07] <carlos> both?
[02:07] <carlos>  :-)
[02:08] <daf> wow, 196 unused imports in the interface code
[02:14] <carlos> daf, *only*?
[02:14] <carlos> :-)
[02:14] <morgs> daf: thx
[02:15] <daf> carlos: ha
[02:15] <daf> morgs: no problem
=== salgado [~salgado@200-171-140-32.dsl.telesp.net.br]  has joined #launchpad
[02:26] <carlos> stub, is it possible to get the patchsets I just sent you merged into production today? (+ one that is waiting for PQM)
[02:27] <carlos> lifeless, ^^^
[02:28] <stub> Ping me when the third one is through - I'll merge them all at once to save PQM time
[02:28] <lifeless> carlos: I don't have an account on gangotri yet AFAIK.
[02:29] <carlos> stub, ok, thank you (btw, seems like I will need a fourth one)
[02:29] <carlos> lifeless, do we have production in a new server?
[02:29] <daf> carlos: what's the fourth one?
[02:29] <lifeless> carlos: yes, we're scaling up to load balancing
[02:29] <carlos> daf, I need some help testing the .py cronscript execution
[02:30] <carlos> lifeless, cool
[02:30] <lifeless> carlos: and to give gina breathing room
[02:30] <carlos> daf, see the error log output
[02:31] <daf> huh?
[02:32] <carlos> daf, https://chinstrap.ubuntu.com/~dsilvers/paste/fileqbsUIo.html
[02:32] <carlos> daf, you should read from time to time the cronscripts output ;-)
[02:33] <daf> gna
[02:33] <daf> stub had some ideas for testing these, I think
[02:34] <carlos> daf, oh, I thought you tried them already
[02:34] <daf> nope
[02:34] <carlos> that's what I asked you for help :-P
[02:34] <carlos> ok, I have stub's ideas in my logs, will try to apply them when possible (the attach script is a bit difficult)
[02:35] <daf> the attach script is hard
[02:35] <daf> unless you use twisted to creeate a fake HTTP server
[02:36] <carlos> daf, I think I will add a small check to be sure the imports and the argument parsing works
[02:36] <carlos> daf, and will think about the twisted fake HTTP server later...
[02:37] <daf> I haven't written a HTTP server before
[02:37] <daf> so I'm not sure how hard it is
[02:37] <jamesh> daf/carlos: if you are doing a fake HTTP server for testing purposes, you can probably do more realistic tests by making it a fake HTTP proxy
[02:37] <sabdfl> SteveA: i turned chunkydiff off and all i got back was a three line failure message
[02:38] <jamesh> that way you can have the script think it is talking to the production URLs
[02:38] <daf> jamesh: how would that work?
[02:38] <daf> oh, I see
[02:38] <sabdfl> SteveA: erk
[02:38] <SteveA> sabdfl: please forward it to me
[02:38] <sabdfl> sorry
[02:38] <jamesh> daf: set the http_proxy environment variable
[02:38] <sabdfl> my bad
[02:38] <carlos> jamesh, yeah, I have that in my logs too, you told us the same last time we talked about this problem :-P
[02:38] <daf> jamesh: right, got you now
[02:38] <sabdfl> i forgot to say r=stevea :-)
[02:38] <SteveA> aha
[02:38] <jamesh> daf: the script will do "GET http://hostname/..." rather than "GET /..."
=== SteveA doesn
=== SteveA doesn't remember approving something recently
[02:38] <daf> jamesh: the script takes a parameter telling it the address to look at, so I'm not sure if it would make much difference
[02:39] <carlos> btw, are we moving from launchpad.ubuntu.com to launchpad.net?
[02:39] <SteveA> yes
[02:39] <SteveA> stub and elmo are sorting out the finer details
[02:39] <carlos> SteveA, will the old one die?
[02:39] <SteveA> i suppose elmo can set up a general redirect
[02:39] <daf> mpt: yo?
[02:40] <carlos> ok
[02:41] <jamesh> daf: I suppose it might not be too much more useful than the command line arg.  It does have the benefit that you only need to set an environment variable to point the script at the fake server
[02:41] <stub> SteveA: I need to make canonical.launchpad.scripts.log a global. This global will be set when command line options are passed. Scripts using it will do so using 'from canonical.launchpad.scripts import log'. This means that scripts will be using the value of 'log' at import time, rather than the correct instance. So solve this, does canonical.launchpad.scripts.log need to be a wrapper?
[02:42] <carlos> https://chinstrap.ubuntu.com/~dsilvers/paste/file1cXpPc.html
[02:42] <daf> stub: what's the benefit of it being a global?
[02:43] <SteveA> stub: that makes sense.  or, you make people import get_log, and say log = get_log.
[02:43] <SteveA> stub: a wrapper would be easier for clients to use. 
[02:43] <stub> daf: I can retrofit it to gina without rewriting the damn thing
[02:43] <carlos> daf, ^^^ Is normal that I get angry when people says 'pootle is actively developed....'
[02:43] <carlos> ?
[02:43] <carlos> daf, I mean, I get the impresion as Rosetta is stalled and without being developed....
[02:43] <lifeless> stub: why not a utility ?
[02:44] <lifeless> stub: and the gina compatability thing a shim to the utility ?
[02:44] <daf> carlos: well, if it's implying that Rosetta is not actively developed...
[02:44] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Added missing import + test rs=kiko (patch-2014: carlos.perello@canonical.com)
[02:44] <jamesh> stub: if it is just the root logger, do you need a wrapper?
[02:44] <jamesh> stub: can't you just have the global variable, and then configure it other modules import it?
[02:44] <SteveA> i think you want a logger to be a module-level thing 
[02:45] <SteveA> it's an import ordering thing
[02:45] <SteveA> you need to set up the global variable before it is imported by other code
[02:45] <lifeless> singletons are good at that ;0
[02:45] <stub> jamesh: Probably - it would mean the root logger is being reconfigured, which might not be a good thing (?)
[02:45] <SteveA> because cpython doesn't have a 'become()' operation to change the object to a different one.
[02:45] <SteveA> so, you need a wrapper
[02:45] <jamesh> yes, but to set up the logger you generally do: "log = logging.getLogger()", then do some work to configure "log"
[02:46] <jamesh> you can do the first bit during module scripts.py's initialisation, and the second part after passing command line args
[02:46] <daf> carlos: is that the third merge there?
[02:46] <daf> carlos: should stub wait for the fourth or update production now?
[02:46] <jamesh> that way it is the same object before and after
[02:47] <carlos> I'm still getting errors in my local tree but PQM does nto get them...: https://chinstrap.ubuntu.com/~dsilvers/paste/fileul09Zc.html
[02:47] <jamesh> stub: just leave it unconfigured until you pass command line args
[02:47] <carlos> daf, yes, that's the third one
[02:47] <stub> jamesh: It would work, but I'm a bit uncomfortable about things using the root logger (even scripts), as it makes it difficult to control if we start combinging bits. Might be YAGNI though.
[02:47] <carlos> daf, the fourth one is in its way to rocketfuel
[02:47] <daf> carlos: ok
[02:47] <jamesh> stub: fair enough
[02:48] <SteveA> well, we could do logging by module name, or something like that
[02:48] <jamesh> stub: one other useful thing: set the converter attribute of the logging.Formatter instance to time.gmtime -- it will cause log messages to be formatted in UTC rather than local time
[02:49] <jamesh> (which is +0100 in the data center at the moment)
[02:49] <lifeless> nothing should use the root logger
[02:49] <lifeless> its really quite important to have a child and use that IME
[02:51] <stub> jamesh: Ta
[02:51] <daf> stub: if you use  %(levelname)-8s, the columns line up nicely
=== daf -> lunch
[02:54] <jamesh> lifeless: your robert.collins@canonical.com/cscvs--devel--1.0--patch-350 branch has been sitting in merge-conditional state for quite a while.  Do you plan to merge it at some point?
[02:55] <lifeless> jamesh: definately.
[02:55] <jamesh> okay.  Just checking up on it.
[02:55] <lifeless> thanks for reminding me;_)
[02:58] <kiko> womp womp womp
[02:58] <kiko> hey carlos my man
[02:58] <kiko> yo lifeless 
[02:58] <kiko> my merge almost worked
[02:58] <kiko> 2 test failures :-P
[02:58] <carlos> kiko, morning :-)
[02:58] <salgado> stub, gina doesn't have access to the production db anymore?
[02:59] <stub> salgado: You are running it? I thought it needed to be setup?
[03:00] <ddaa> duh... aspell-br is...
[03:00] <ddaa> Breton...
[03:00] <stub> I updated the access today because I was under the impression it was no longer used
[03:00] <salgado> stub, no, I'm not. I just wanted to connect to the db to do a query
[03:02] <salgado> stub, the gina script is not going to be run with the gina db user?
[03:02] <stub> salgado: Sorry - your backdoor is closed.
[03:03] <kiko> stub!
[03:03] <stub> salgado: yes but it needs to be tested against staging first
[03:04] <salgado> stub, you can be sure I'd never run it in production without testing it (thousands of times) against staging
[03:05] <stub> salgado: I'm very confused. I was under the impression that I was having to run Gina now.
[03:05] <lifeless> night guys
[03:05] <cprov> stub: do you have a minute to discuss the renameing of GPGKeys.revoked ?
[03:06] <lifeless> ddaa: you and jblack on on similar tz right now, can you sync up with him and see how its going for him ? I'll then sync with whichever of you is around in my morning
[03:06] <ddaa> "similar tz right now"?
[03:06] <lifeless> waking/sleeping pattern
[03:06] <stub> debonzi: I'm doing Gina config stuff atm, so you might want to avoid playing with it for a bit until you can review my changes
[03:07] <debonzi> stub, cool.. no problem
[03:07] <stub> cprov: Sure
[03:07] <ddaa> lifeless: not anymore, I'm waking up earlier now.
[03:08] <ddaa> anyway, I'll sync with him whener he shows up.
[03:10] <cprov> stub: nice, the sane way should be renaming "revoke" to "inactive" (we keep the existent logic)  but other tables have "active" would it be a problem looking to the whole DB ? do you have a opinion about that ?
[03:10] <kiko> disabled is another option
[03:11] <stub> I don't have a major problem with inactive, although I don't see why you can't use 'not active; in the code (I guess that would be more than simple cut&paste?)
[03:12] <salgado> daf, carlos, seen this -> https://launchpad.ubuntu.com/errors/showEntry.html?id=1120548526.070.171839082334 ?
[03:12] <sabdfl> daf, carlos: why have you added productrelease, distrorelease and sourcepackagename to the POTEmplate edit page?
=== stub is trying to work out why he doesn't have a major problem with it, when he has in other cases
[03:12] <cprov> kiko: right , "disable" is also a name alternative, but the logic still different 
[03:12] <sabdfl> that's absolutely an admin requirement - it will KILL us if people start doing that
[03:12] <sabdfl> there used to be a +admin page with those on it
[03:13] <kiko> sabdfl, aren't the links restricted to admin-only?
[03:13] <sabdfl> kiko: no
[03:13] <cprov> stub: the point is the existent data migration ... if we change from "revoked" to "active" we need to change all false to true ...is it ok for you ? 
[03:13] <sabdfl> there used to be a +edit and a +admin
[03:14] <sabdfl> and someone helpfully collapsed them
[03:14] <sabdfl> daf, carlos: please ack
[03:14] <stub> cprov: Can you call the database column 'active', and add an 'inactive' property to the GPGKey database class that returns 'not self.active' ?
[03:14] <sabdfl> i need you to understand why we cannot have normal users re-linking templates from product to distro
[03:14] <bradb> morning all
[03:14] <stub> cprov: Data migration is fine - I just updated a few million rows today. A couple of dozen/hundred GPGKeys isn't a problem ;)
[03:14] <sabdfl> hey bradb
[03:15] <carlos> sabdfl, I have a fix since Friday that I had to modify and got merged this morning, waiting for another fix to get it merged into production
[03:15] <bradb> hey sabdfl 
[03:15] <cprov> stub: sure I can, but it looks like a workarround, and since we are developing, not repairing, there is no need for workarrounds ;)
[03:15] <carlos> sabdfl, only admins will see it, that way we can move POTemplates from the web page without asking stuart to do it by hand
[03:15] <sabdfl> rf is currently the problem, not the solution
[03:15] <stub> cprov: Cool. Drop the property idea.
[03:15] <sabdfl> and this is launchpad.Edit, not launchpad.Admin
[03:15] <sabdfl> also, owners often get Admin, don't they?
[03:16] <sabdfl> that would be a problem
[03:16] <carlos> sabdfl, hmm, no I don't have a fix for that error
[03:16] <carlos> sabdfl, I thought it was related with +edit
[03:16] <sabdfl> AFAICS the latest RF has only a +edit, which is launchpad.Edit, and which allows editing EVERYTHING
[03:16] <sabdfl> carlos: do you understand that there needs to be:
[03:16] <sabdfl>  +edit, which lets you change basic details
[03:16] <sabdfl>  +admin, which lets you link differently to upstream or distrorelease and edit stuff hte normal user SHOULD NOT SEE
[03:17] <carlos> sabdfl, the browser code does the admin/normal owner difference
[03:17] <carlos> sabdfl, I had +edit and +admin, but kiko asked me to collapse both
[03:17] <sabdfl> carlos: it appears to be broken
[03:17] <kiko> carlos, whoa
[03:17] <carlos> sabdfl, I have tests
[03:17] <kiko> carlos, I said collapse them /if/ you restrict the links/controls accordingly
[03:17] <carlos> kiko, it's done that way
[03:17] <cprov> stub: fine, May I move the branch with the DB patch to your queue ? ... another DB patch code dependant ...
[03:17] <kiko> that's not what sabdfl is saying
[03:18] <sabdfl> this is still wrong, carlos, daf, we have separate +admin and _edit pages wherever possible, and don't depend on browser code for the distinction
[03:18] <carlos> grrrrr
[03:18] <carlos> kiko, sabdfl please coordinate a bit more :-(
[03:18] <stub> cprov: Sure
[03:18] <kiko> sabdfl, the only reason I suggested it was to avoid the extra work
[03:18] <cprov> stub: thanks, have fun later
[03:19] <SteveA> we should not over-use the permission query namespace
[03:19] <kiko> carlos, steve's slapping my wrist too, so I'll just say sorry on this one. 
[03:19] <SteveA> if we over-use it, this will make things really hard to maintain
[03:20] <SteveA> in general, a page requires a permission to access it
[03:20] <SteveA> sometimes, we want to do cute things, especially in portlets / menus
[03:20] <SteveA> taking permissions into account
[03:20] <SteveA> but, if a page has lots of permission query stuff in it, it will make it hard to understand
[03:20] <SteveA> and hard to maintain
[03:21] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Merge in calendar code, r=salgado,stub (patch-2015: james.henstridge@canonical.com, marius.gedminas@canonical.com, stuart.bishop@canonical.com)
[03:21] <carlos> well, we will get the final fix merged into production and I will undo the changes to be merged with next production update....
[03:22] <sabdfl> kiko: extra work?
[03:22] <sabdfl> it's two zcml statements!
[03:22] <sabdfl> i'll fix it now, and land
[03:23] <kiko> I appear to me in the middle of some misunderstanding.
[03:25] <lifeless> ok, goodnight for real, tests passing, me crashing
[03:25] <carlos> lifeless, night
=== carlos wishes pqm were faster
[03:26] <salgado> carlos, have you seen the error report I pasted here for you?
[03:26] <carlos> salgado, no, sorry
[03:26] <carlos> I think I missed it
[03:27] <salgado> carlos, https://launchpad.ubuntu.com/errors/showEntry.html?id=1120548526.070.171839082334
[03:27] <carlos> oh
[03:27] <carlos> sorry, I mixed it with sabdfl's comments
[03:27] <carlos> salgado, yeah, I saw it
[03:27] <carlos> salgado, daf was working on that, I will give him the trace as soon as he's back
[03:28] <salgado> carlos, just need to add addLanguage() and removeLanguage() to IPerson
[03:28] <kiko> carlos, daf: this parse_options() things makes me want to cry
[03:28] <carlos> in case he can fix it faster
[03:28] <kiko> stub, any chance we can get a torpedo fix in to get rosetta-poimport running again?
[03:28] <carlos> salgado, ?, those comes from SQLObject directly...
[03:28] <carlos> salgado, at least that's the way it was when I implemented it some months ago...
[03:28] <carlos> kiko, pqm has a fix
[03:28] <salgado> carlos, exactly. then you just need to add them to the interface. no need to implement
[03:29] <kiko> stub, any chance you can pull that patch from pqm when it's through with a pretty-pretty-please?
[03:29] <salgado> carlos, if you don't add them to the interface the security proxy won't allow you to use them
[03:29] <carlos> kiko, stub is waiting for it to cherry pick the fix
[03:29] <kiko> ah
[03:29] <kiko> carlos, how come we get this sort of basic error happening repeatedly? :-(
[03:30] <carlos> salgado, hmmm, but those methods are there since long ago, I mean I'm using them since long ago, not sure if daf changed anything so we get that error now....
[03:30] <carlos> kiko, because we are not checking the cronscript execution
[03:30] <sabdfl> carlos: are you merging another sampledata change now?
[03:31] <sabdfl> i've been trying to land something for two days
[03:31] <carlos> kiko, we talked about it, test for that is a bit difficult but I'm going to work on it this week
[03:31] <kiko> carlos, even pyflakes or pylint would catch that one..
[03:31] <carlos> sabdfl, no, I didn't change any sampledata this week
[03:31] <salgado> carlos, for me it looks like the code which uses this method is not tested, because any call to person.addLanguage() will not work
[03:31] <sabdfl> carlos: someone changed the owner of a potemplate in a merge today
[03:31] <sabdfl> and conflicted with me
[03:32] <carlos> kiko, I need to get used to those tools, still trying to get uptodate after the exams, give me sometime...
[03:32] <kiko> sabdfl, I meant extra work for the end-user.
[03:32] <carlos> sabdfl, oh, I changed it on Friday but was not merged until today, sorry
[03:32] <carlos> sabdfl, forgot that one
[03:33] <carlos> sabdfl, I had to change it to add a test 
[03:33] <carlos> salgado, could be, let me ask daf when he's back It's long ago since last time I touched that code and he should be able to answer it easily
[03:37] <kiko> carlos, apologies, btw -- only pychecker would have caught this error.
[03:38] <kiko> still, just running it once manually would have caught it...
[03:38] <carlos> kiko, isn't pychecker broken with sqlobject classes?
[03:38] <kiko> I don't know, I just ran it on this file and it worked fine
[03:38] <SteveA> kiko: i can appreciate the "extra work for the end user" side of things.  it is also important to give the end-user a consistent model that they can understand.
[03:39] <SteveA> if we use +edit and +admin pages consistently, that forms part of the model
[03:39] <kiko> does the +admin page have all the fields the +edit page has?
[03:39] <carlos> kiko, yes, the only difference was the readonly 'name' field
[03:40] <SteveA> if we're requiring extra page changes for frequently undertaken tasks, then that's a good time to look at doing something to fix that, but that doesn't particuarly disrupt the overall model.
[03:40] <carlos> kiko, because the +admin one has potemplatename as read/write
[03:40] <carlos> that it's a kind of alias
[03:42] <kiko> and can +edit and +alias use the same zpt?
[03:42] <carlos> +alias?
[03:42] <carlos> +admin ;-)
[03:42] <carlos> kiko, they could, yes
[03:43] <kiko> aiee
[03:43] <carlos> as it's an autogenerated form
[03:43] <kiko> ah
[03:43] <kiko> and if it wasn't?
[03:43] <SteveA> aw screw.  when i run page tests in isolation, all pass
[03:43] <kiko> not without using PQNS, I suspect
[03:43] <SteveA> when i run all tests, a foaf test fails
[03:43] <sabdfl> SteveA: 30-mergepeople..?
[03:43] <carlos> kiko, with tal conditionals we could solve that, I suppose, but then it's the same problem with the current merge, right?
[03:43] <SteveA> sabdfl: yeah
[03:43] <carlos> kiko, as the security code is inside the .pt file
[03:43] <kiko> carlos, right.
[03:44] <sabdfl> i'm trying to debug that too
[03:44] <sabdfl> on my machine, all tests pass
[03:44] <carlos> SteveA, same here, but with malone tests
[03:44] <SteveA> carlos: there is a feature called "usage" that allows you to use one page template under different circumstances.
[03:44] <sabdfl> i've spent all day on this, and am about to ban anyone else from emailing pqm till i get it landed :-)
[03:44] <SteveA> carlos: we're not using it at present, though.
[03:44] <carlos> SteveA, isn't it the same problem we have now?
[03:44] <SteveA> sabdfl: maybe i should take a look at it, as it is failing on my machine.
[03:44] <sabdfl> carlos, SteveA: this is a very simple situation, that does not call for fancy zope3 stuff
[03:44] <carlos> SteveA, some fields will appear as launchpad.Admin and others as launchpad.Edit
[03:45] <sabdfl> it requires two zcml directives, one for the +edit page, which many people will use to edit the description and potemplatename, and one for the +admin page, which only hard-core admins and rosetta-exports will use
[03:45] <carlos> sabdfl, I know, I solved it that way first time I implemented it
[03:45] <sabdfl> carlos: i do not want forms that are sometimes editable and sometimes not
[03:45] <sabdfl> i've spent days shitting on bradb for that in malone, let's not do it in rosetta, please
[03:45] <kiko> right, the zcml is simple, but the page templates are my question
[03:46] <sabdfl> kiko: they are all autogenerated, first, and second, you WANT different templates because you likely want different additional details on them
[03:46] <kiko> I didn't think that was the case here -- simply one field that would be editable or not.
[03:47] <kiko> anyway, I am overruled
=== seb128 [~seb128@ANancy-151-1-4-223.w83-194.abo.wanadoo.fr]  has joined #launchpad
[03:48] <seb128> hi
[03:49] <seb128> can we get gnome-menus on arch.u.c? :)
[03:49] <carlos> stub, are you ready?
[03:49] <carlos> stub, my changes are ready
[03:49] <SteveA> sabdfl: i've tracked down the bug
[03:49] <ddaa> seb128: sure
[03:49] <ddaa> seb128: here are the required steps
[03:50] <sabdfl> carlos: i don't have time to sort this out properly, i'm just going to delete those test. best make backups if you want them
[03:50] <ddaa> seb128: look for the product on launchpad. In that case it's alredy there: https://launchpad.ubuntu.com/products/gnome-menus
[03:50] <seb128> k
[03:50] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Added missing security declaration + typos (patch-2016: carlos.perello@canonical.com)
[03:50] <sabdfl> SteveA: what's the fix?
[03:51] <SteveA> sabdfl: it's some strange case of equality on sqlobjects.  the deep fix, i'll have to look into.
[03:51] <SteveA> i can give you a quick fix
[03:51] <sabdfl> SteveA: please
[03:51] <SteveA> i'm just going to test it -- don't want to waste your time with a bogus fix
[03:51] <carlos> sabdfl, delete those tests?
[03:51] <carlos> sabdfl, because the conflict?
[03:51] <sabdfl> i had also done a assert email.person == self, 'Wrong person! %r %r' % (email.person, self)
[03:52] <sabdfl> to try to get to the bottom of it
[03:52] <sabdfl> but since it didn't show on my machine i've had to keep submitting
[03:52] <sabdfl> and everyone else gets ahead in the queue
[03:52] <ddaa> seb128: since it has only dummy descriptions and such, I have it to you. Please make a good description, and enter cvs and ftp details in the ill-named head branch.
[03:52] <ddaa> * I have assigned it to you
[03:52] <sabdfl> and then there are conflicts so the tests aren't run by pqm...
[03:52] <seb128> ddaa: ok
[03:52] <carlos> sabdfl, ok, merge it and I will redo the sampledata change 
[03:52] <carlos> sabdfl, and reactivate the test
[03:52] <sabdfl> carlos: the sampledata is fine, i have fixed that
[03:52] <carlos> sabdfl, ok?
[03:52] <carlos> sabdfl, then=?
[03:53] <sabdfl> it's the edit-*.txt tests
[03:53] <stub> carlos: patch-2016?
=== ddaa goes out to rename "head" to "main"
[03:53] <sabdfl> all of which test the forms i will remove
[03:53] <carlos> stub, I just sent you an email with the extra ones to add to the previous email
[03:53] <sabdfl> i don't have time to recreate those tests on the admin pages
[03:53] <ddaa> seb128: wait a min...
[03:53] <sabdfl> ddaa: why not add a recommendation that "main" be the name of any new series being created for a prodct has has no series?
[03:54] <seb128> ddaa: k
[03:54] <carlos> sabdfl, as long as you leave the edit ones, that's enough
[03:54] <sabdfl> you could add that direct to the web pages
[03:54] <sabdfl> carlos: there's nothing left to edit, beyond the description
[03:54] <ddaa> sabdfl: probably because I have not asked for it clearly enough.
[03:54] <carlos> sabdfl, I will add the +admin ones
[03:54] <sabdfl> nothing else is safe for ordinary users
[03:54] <carlos> sabdfl, the owner
[03:54] <ddaa> sabdfl: anyway, those are automatically created products and branches.
[03:54] <carlos> sabdfl, aren't they supposed to change the owner of a potemplate?
[03:54] <sabdfl> ddaa: what i'm saying is, if there is a behaviour of LP users you want to avoid, the thing to do is nudge the pages that induce that behaviour in the directin you want
[03:55] <sabdfl> carlos: that's object reassignment, check with salgado on the best practice there
[03:55] <carlos> sabdfl, ok
[03:55] <ddaa> sabdfl: yes, we complained several time that the text was wrong, but I think we never went around filing a formal bug.
[03:55] <carlos> sabdfl, anyway, the test checks that only the right values are tehre
[03:55] <ddaa> Though I'm not even sure of that. I'll check once I'm done with seb128.
[03:55] <carlos> sabdfl, so that test should reappear
[03:55] <carlos> sabdfl, but don't worry, I will take care of it
=== carlos -> lunch
[03:56] <sabdfl> ddaa: just fix it yourself, if it is just text it will be a quick review
[03:56] <sabdfl> ddaa: you should get comfortable with the code behind those pages, and improve it to suit your purposes
[03:56] <sabdfl> every now and then you'll do something that's not perfect, but it will get sorted out
[03:56] <sabdfl> and we'll find a better way to achieve what you want
[03:57] <SteveA> sabdfl: the thing is, they're the same person.  just, a different object.  __eq__ is supposed to work.  i don't yet know why it doesn't.  I shall find out after some lunch.
[03:57] <carlos> stub, do you need anything from me or could I leave to have lunch?
[03:57] <SteveA> sabdfl:         assert email.person.id == self.id
[03:57] <sabdfl> but it is much better if you treat LP as open source for your needs :-)
[03:57] <SteveA> sabdfl: all my tests pass when that line is changed.
[03:57] <ddaa> sabdfl: I'll do it when I can get around to it.
[03:57] <stub> carlos: have lunch
[03:57] <carlos> ok
[03:57] <carlos> later
[03:57] <SteveA> sabdfl: but, please add an XXX comment owned by me, that this is so because of an sqlobject oddity
[03:57] <ddaa> seb128: about gnome things in general
[03:58] <ddaa> seb128: you need to set up a 'main' series for the MAIN branch on the CVS.
=== SteveA --> lunch
[03:59] <ddaa> seb128: and additional series for release branches like gnome-2-10 that are actually packaged
[03:59] <seb128> ok
[03:59] <ddaa> mh...
[03:59] <ddaa> actually, since you are packaging 2.11...
[04:00] <seb128> hoary has 2.10
[04:00] <ddaa> If you care about 2.10, then you should enter the cvs details for the release _branch_ on the CVS.
[04:01] <ddaa> in the 2.10 series you'll give ftp details with ftproot=ftp://ftp.gnome.org/pub/gnome/sources/gnome-menus/2.10/
[04:01] <ddaa> and if you are interested about hct support for packaging 2.11 you should also create a 2.11 series. Since it does not have a cvs branch, just enter ftp details on that one.
[04:01] <ddaa> seb128: you get the idea?
[04:02] <seb128> yep
[04:02] <seb128> I don't really care about 2.10 atm, main is fine
=== seb128 updates the descriptions
[04:03] <sabdfl> oh, gosh, darn, sampledata conflicts again
[04:03] <ddaa> well, I guess you care about 2.11, at least we're going to have to put ftp details there, so I'd like distro people to enters details about what they are packaging in breezy.
[04:04] <ddaa> (otherwise someone else here will have to do it)
[04:04] <sabdfl> stub: the calendar merge has made my life difficult
[04:05] <sabdfl> was any new sampledata added?
[04:05] <sabdfl> or was it just a structural change?
[04:05] <ddaa> seb128: I'm not clear on whether 2.11 should be a separate series or just put the ftp details for that on MAIN, and change them regularly... I guess it's a matter of taste...
[04:05] <seb128> ddaa: I prefer to have MAIN, and to create gnome-2-12 later
[04:06] <stub> sabdfl: IIRC sample data changes were in there
[04:06] <ddaa> seb128: that's your choice. As long as the ftp details for the latest releases are _somewhere_ meaningful, HCT will be happy.
[04:06] <sabdfl> stub: pity, there goes a few useful hours :-/
[04:06] <ddaa> (and as a consequence, you will be happy, sabdfl will be happy, and will be happy)
[04:07] <seb128> ddaa: I've updated the page for MAIN
[04:07] <seb128> ddaa: k
[04:08] <ddaa> seb128: I see no cvs or ftp details in the series
[04:09] <sabdfl> stub: what was the db patch number that added the db structures for calendars?
=== jdahlin [~jdahlin@200-171-140-32.dsl.telesp.net.br]  has joined #launchpad
[04:09] <ddaa> About the product description. You should leave blank lines instead of the "dot line" format of control files.
[04:09] <stub> sabdfl: patch-17-38-0.sql
[04:10] <seb128> ddaa: I've update the serie, fixing the main
[04:11] <ddaa> seb128: the Download URL field of the product description is _not_ the place to tell HCT where to retrieve tarballs. Actually, it's used nowhere yet so it can be safely ignored. The place to input that data is the "edit series details" page.
[04:11] <seb128> ddaa: main updated too
[04:11] <seb128> ddaa: I've figured that after editing the serie :)
[04:11] <ddaa> seb128: what is the page of what you call the "series"?
[04:11] <seb128> https://launchpad.ubuntu.com/products/gnome-menus/+series/main/+edit
[04:12] <ddaa> Hu...
[04:12] <ddaa> That's the edit page for the main series yes.
[04:12] <ddaa> So, I guess that what you call the "main" is: https://launchpad.ubuntu.com/products/gnome-menus
[04:12] <ddaa> That is the product.
[04:13] <ddaa> For launchpad entry purposes, "main" is just a series among equals.
[04:13] <seb128> right
[04:13] <seb128> so I've update the product information, and put the right ftp etc for the main serie
[04:13] <seb128> s/update/updated/
=== ddaa ties the product to the gnome project, since it follows the gnome release cycle
[04:14] <sabdfl> ddaa: are svn imports syncing? lifeless?
[04:14] <ddaa> sabdfl: last I heard of it, there was a bug with svn update not actually updating.
[04:14] <sabdfl> lifeless: ?
[04:14] <ddaa> he's sleeping
[04:15] <ddaa> seb128: still no cvs details on the series. Can you enter them, please?
[04:16] <seb128> oh, that's "edit source"
[04:16] <seb128> doing it now
[04:17] <seb128> ddaa: should I specify a branch for HEAD?
[04:17] <ddaa> yes, MAIN is the branch.
[04:17] <ddaa> HEAD is some sort of autocrackful tag.
[04:17] <seb128> updated
[04:18] <ddaa> Looks good.
[04:19] <ddaa> seb128: autotest import running, I'll tell you when it's up on arch.ubuntu.com or if there is problem preventing that.
[04:19] <seb128> ddaa: thanks
[04:22] <stub> debonzi: Can you have a look at stuart.bishop@canonical.com/launchpad--gina--0 ? I have ripped out the command line, replaced it with entries in launchpad.conf, and changed all the print statements to use the Python logging system (probably with badly chosen log levels). I also have not tested it ;)
[04:23] <debonzi> stub, man.. its so cool.. :) Sure I can.. do you want me to do some tests too?
[04:24] <stub> debonzi: tests? Of course ;) You probably want to review the levels I'm logging stuff at. In general, I think it will run with '-q' so only WARNINGS and above are printed. I might have made some INFO that should be WARNING or ERROR and have almost certainly mixed up some INFO and DEBUG statements.
[04:26] <stub> debonzi: Note I have *not* tested - the modules might not import at the moment, but I gotta do this production merge.
[04:27] <sabdfl> stub: founds quite a quick way to deal with this smapledata conflict
[04:27] <debonzi> stub, right.. I will take a look on it and try to make some runs localy..
[04:27] <sabdfl> mv the newer patches out the way, make the db with old sampledata, apply patches, make newsampledata, mv patches back, mv newsampledata to current, make
[04:28] <debonzi> stub, I *have* to go buy some food now... I will be looking to it right after lunch ... 
=== debonzi -> FOOD
[04:29] <stub> debonzi: No problem. I'm going to bed after this rollout anyway ;) If I have broken anything majorly, we can keep running with the command line stuff for the time being.
[04:29] <debonzi> stub, cool... Thanks dude
[04:32] <sabdfl> who just asked for a landing?
[04:32] <sabdfl> and is it big?
[04:36] <bradb> i just sent a merge request. it's only about 3 lines.
[04:37] <sabdfl> ok
[04:41] <kiko> bradb, is it a fix for the odd error that steve reported today?
[04:42] <bradb> no, it's a fix for the header when viewing the upstream bug listing as the upstream maintainer
[04:42] <bradb> i noticed that bug that SteveA couldn't mark as fixed is marked fixed
[04:42] <bradb> SteveA: what's the story on that one?
[04:43] <kiko> bradb, look up the system error in the error logs
[04:43] <kiko> https://launchpad.ubuntu.com/products/launchpad/+bugs/1193/+edit
[04:43] <kiko> shouldn't be hard to find
[04:43] <stub> bradb: The view page has a save button on it was the major cause
[04:44] <stub> bradb: (so Steve thought he was on the edit page)
[04:45] <bradb> it does? i thought i fixed that more than a week ago.
=== bradb waits for a merge from rf to finish to look at what's happening
[04:45] <kiko> stub, are you talking about the error-reports bug steve reported?
[04:45] <kiko> or some other issue?
[04:46] <stub> kiko: Brad Bollenbach: i noticed that bug that SteveA couldn't mark as fixed is marked fixed
[04:47] <kiko> stub, oh, I see
[04:48] <kiko> so he misreported?
[04:48] <kiko> I changed the 'status' to fixed.
[04:48] <kiko> that's what he said
[04:48] <kiko> and more interesting, I don't seem to have write access to that page
[04:49] <bradb> kiko: how did you change the status to fixed?
[04:49] <kiko> I didn't
[04:49] <bradb> oh, "that's what he said", ok
[04:50] <kiko> bradb, I just emailed to the list and to you summarizing
[04:50] <bradb> ok, thanks, taking a look while my ctags rebuild
[04:51] <mpt> kiko: Is https://launchpad.ubuntu.com/malone/bugs/1236 yours?
[04:51] <ddaa> seb128: gnome@arch.ubuntu.com/gnome-menus--MAIN--0
[04:52] <seb128> ddaa: thanks
[04:52] <sabdfl> bradb: is that to fix the integrityerror in bugtask.txt?
[04:53] <bradb> sabdfl: the merge request i did? it's a fix so that the "select" column header is rendered when looking at the bugs as an upstream maintainer of a thing.
[04:53] <sabdfl> ok
[04:54] <bradb> i haven't yet given any thought as to how to reset the db connection in the middle of a doctest, to recover from an IntegrityError
[04:57] <kiko> mpt, let me see
[04:59] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  small header fix in the bug listing (patch-2017: brad.bollenbach@canonical.com)
[04:59] <kiko> mpt, nope
[05:00] <mpt> heh, good timing
[05:00] <kiko> I can fix it if you like, but I think you're the man for it :-P
[05:00] <mpt> bradb: How did you fix it?
[05:01] <kiko> bradb, is that patch a fix for bug 1236?
[05:01] <bradb> kiko: yeah
[05:01] <kiko> sabdfl, is the tree closed for merges?
[05:01] <kiko> aha
[05:01] <bradb> mpt: just added three lines of html to show the select table header when it should
[05:02] <mpt> bradb: Does the header contain any text?
[05:02] <bradb> just the word "select"
=== mpt cries
[05:04] <mpt> ok, I'll fix it later
=== Keybuk [~scott@descent.netsplit.com]  has joined #launchpad
[05:05] <kiko> mpt, I'll let you close the bug then
[05:05] <mpt> bradb: Did you move the title column to the right?
[05:06] <bradb> mpt: yes
[05:06] <bradb> bugzilla style
[05:06] <mpt> why?
[05:06] <mpt> I'm sure there's a good reason :-)
[05:06] <mpt> but "bugzilla style" isn't ...
[05:08] <bradb> well, it helps for some use cases, but it's less useful for others
[05:08] <bradb> mpt: let's say you're jblack 
[05:08] <bradb> and lifeless has assigned a bunch of bugs to you
[05:08] <bradb> so, you have a "todo" list now
[05:08] <mpt> hmm, I remember jblack saying something about column ordering, yes
[05:08] <bradb> some of those bugs are important, some of them are less important
[05:09] <bradb> so, you're going through your todo list...what kinds of things are the most important to be able to scan quickly when going through this todo list?
[05:09] <bradb> (and why?)
[05:09] <mpt> the checkboxes, and the summaries
[05:10] <mpt> so I can check a bunch of them and click the menu at the bottom of the list to change the selected bugs to High priority
[05:10] <mpt> or target them for 1.6
[05:10] <bradb> mpt: that's what lifeless already did for you
[05:11] <mpt> lifeless set priorities for jblack's bugs?
[05:11] <mpt> That would make sense for bugtracker.somebigcorporation.com
[05:11] <bradb> AFAIU, it's not jblack who decides, for example, that a bug is targeted for a specific release
[05:12] <mpt> I don't think it's the usual case for projects where the people collaborating aren't usually in a contractual relationship
[05:12] <bradb> maybe i misunderstood, but that would be all the more confusing, considering jblack suggested these column ordering changes ;)
[05:13] <bradb> mpt: what do you think needs to be changed from the way it currently looks?
[05:13] <bradb> (and why?)
[05:13] <mpt> I accept that's what jblack would like, I just don't think it's the usual case
[05:14] <mpt> The usual case is:
[05:14] <mpt> * people haven't bothered to set priority
[05:14] <mpt> * people haven't bothered to set severity
[05:14] <mpt> * for a lot of the bugs you're looking at, there is no assignee yet
[05:14] <mpt> * reporter isn't that interesting
[05:15] <morgs> SteveA: test.py runs in python2.3, but uses set() which is not supported?
[05:15] <kiko> reporter is rarely interesting
[05:15] <bradb> mpt: "the usual case" for which type of user?
[05:15] <bradb> it sounds like you're talking about the triager use case now
[05:16] <mpt> not really
[05:16] <mpt> Even Launchpadders don't bother to set severities and priorities on their bugs!
[05:16] <mpt> (most of the time)
[05:17] <bradb> does BMO have a triagers guide?
[05:17] <mpt> I'm pretty sure it does
[05:17] <bradb> for example, GNOME does. the first paragraph of the GNOME triagers guide says that triaging involves setting the severity/priority on a bug (among other things)
[05:18] <mpt> where's that?
[05:18] <bradb> BMO's triage guide mentions setting Severity as "Optional, but helpful"
[05:19] <bradb> mpt: http://developer.gnome.org/projects/bugsquad/triage/
[05:19] <mpt> In b.m.o, if you dare set the priority on a bug that isn't assigned to you, you'll probably get yelled at
[05:19] <kiko> severity is most of the time only settable by the reporter
[05:19] <kiko> priority is most of the time only settable by the project manager
[05:20] <kiko> (or the developer if he is allowed to prioritize his work)
=== jdahlin is now known as jd-fud
[05:20] <mpt> "As stated in the Bugzilla Etiquette you MUST NOT CHANGE the Target Milestone and Priority fields. These fields are reserved for the developers. Bugs      with Target Milestones in the past are NOT EXCEPTED."
[05:21] <mpt> http://www.mozilla.org/quality/help/bugzilla-privilege-guide.html#editbugs
[05:21] <bradb> KDE's triager guide also mentions setting the severity, at least
=== lifeless [~robertc@dsl-211.17.240.220.rns02-kent-syd.dsl.comindico.com.au]  has joined #launchpad
[05:22] <bradb> mpt: sure, that makes sense. it seems logical that a triager has no place choosing target or priority. i'm just reporting the information i've found.
[05:23] <mpt> what a weird circumstance that b.g.o and b.m.o practice should be so different
[05:24] <bradb> mpt: might we be at the point now where different "types" of listings need different, well, "types" of listings? :)
[05:24] <SteveA> bradb: i couldn't mark it fixed from the page i was on, because of url changes in the recent production upgrade
[05:24] <mpt> bradb: yeah, but customizability doesn't preclude us from having to choose a default :-P
[05:24] <SteveA> morgs: test.py should be changed, then.  me, I always use "python test.py"
[05:25] <kiko> mpt, I think the GNOME triager's guide is wrong.
[05:26] <mpt> bradb: The other reason having the title as the last column in Bugzilla really annoys me is that I can't see the bug number and the title at the same time
[05:26] <mpt> e.g. https://bugzilla.mozilla.org/duplicates.cgi?sortby=delta&reverse=1&maxrows=100&changedsince=30
[05:27] <mpt> normal buglists are better than that, but not much better.
[05:27] <bradb> mpt: btw, i wasn't talking about "customizability", i was talking about showing a different kind of listing, depending on the view you're looking at (so, a triage view looks somewhat different to the "my todo list" sort of view, etc.)
[05:27] <carlos> hmm
[05:28] <SteveA> right... let's see why email.person != self
[05:28] <bradb> column customizability is somewhere down the line well behind canned searches, IMHO
[05:28] <carlos> sabdfl,  we have two portlets with similar information in the same page: https://launchpad.ubuntu.com/products/ddtp-ubuntu
[05:28] <mpt> bradb: and how would you determine which view to show?
[05:28] <carlos> mpt, ^^^
[05:29] <bradb> mpt: we could create them. +untriaged, +mytodolist, +whatever, etc.
[05:29] <sabdfl> carlos: the title on both portlets suck, i certainly didn't set those :-)_
[05:29] <mpt> kiko: wrong as in badly written, or misguided, or what?
[05:29] <bradb> mpt: and then it's just a matter of "affording" them
[05:30] <sabdfl> errr
[05:30] <sabdfl> sorry
[05:30] <kiko> mpt, misguided
[05:30] <carlos> sabdfl, the title and the content....
[05:30] <sabdfl> that's the product title coming though :-)
[05:30] <mpt> ahh
[05:30] <mpt> I was thinking "huh? is this a Rosetta page?" :-)
[05:31] <carlos> sabdfl, are you fixing it then?
[05:31] <sabdfl> i think the second one is a borked product-PROJECT-details
[05:31] <sabdfl> you sort of need to see both
[05:31] <sabdfl> the product details, and the project details
[05:31] <sabdfl> because, for example, translation permission is the "most restrctive of BOTH"
[05:32] <mpt> there's something a bit broken in the "latest malone bugs" box too
[05:32] <kiko> mpt, what's broken there?
[05:32] <carlos> mpt, yeah, the icon is in the next line
[05:32] <kiko> I changed that portlet in my tree
[05:32] <carlos> sabdfl, I see, then the description should be improved :-)
[05:32] <mpt> kiko: (1) They're not Malone bugs, they're "Package Descriptions for Ubuntu" bugs. (2) There's a stray (i) icon at the bottom.
[05:33] <kiko> mpt, what page is this?
[05:33] <carlos> sabdfl, anyway, that product does not have a project
[05:33] <mpt> kiko: https://launchpad.ubuntu.com/products/ddtp-ubuntu
[05:33] <bradb> SteveA: so, just to be clear, is there a problem with marking the bug fixed, or has the problem magically gone away? i'm not sure if you're saying this was a problem specific to, perhaps, having tried to make this change right in the middle of a prod upgrade.
[05:33] <carlos> so I'm not sure that portlet should appear
[05:33] <kiko> mpt, I changed that to Latest Bugs Reported
[05:34] <kiko> no clue about the dangling icon, let me check.
[05:34] <mpt> bradb: targeted views is an interesting idea, though we seem to have a lot of trouble keeping even one view in good working order :-)
[05:34] <kiko> mpt, I think that's fixed in RF
[05:34] <mpt> good good
[05:35] <kiko> ah, it's not, but I will fix here
[05:35] <kiko> carlos, bradb, sabdfl, mpt: leave the dangling icon and the title to me
[05:35] <mpt> kiko: looks like a <li><div tal:condition> instead of an <li tal:condition>, perhaps
[05:35] <sabdfl> <insert background music>
[05:35] <sabdfl> kiko to the rescue!
[05:35] <carlos> :-D
[05:35] <kiko> exactly
[05:36] <bradb> lp 911
=== mpt croons, "But dangling, leave the last dance to me"
[05:36] <SteveA> bradb: this was specific to using the system during an upgrade.  i subsequently marked it as fixed.
[05:36] <kiko> I'm rescuing that in total selfishness, because I don't want 5000 conflicts on my merge 
[05:36] <bradb> SteveA: ok, cool
[05:36] <ddaa> kiko: there are that many files in launchpad?
[05:38] <sabdfl> SteveA: so the correct form action for self-posting forms is: <form tal:attributes="action request/getURL"> ?
[05:39] <bradb> sabdfl: will you be okay with me splitting bugtask-editform.pt into bugtask-view.pt and bugtask-edit.pt? i want to fix this save-changes-showing-up-on-the-view-form again bug, and keep it simple.
[05:39] <SteveA> that will work well.  i think we established that action="" ought to work according to the RFC, but we should check it in the browsers we wish to support.
[05:40] <SteveA> who is awake and knows sqlobject internals well ?
[05:40] <SteveA> mpt: what do you think of action="" in self-posting forms?
[05:40] <SteveA> sabdfl: in the interests of simplicity, i think we should use action="" until someone reports an error.
[05:41] <mpt> SteveA: I don't know of anything particularly bad about it
[05:41] <sabdfl> bradb: i think so, but is that something that could wait till post-1.0?
[05:41] <sabdfl> SteveA: linkchecker does, for a start
[05:41] <SteveA> linkchecker does not comply with the RFC, then.
[05:41] <SteveA> in which case, what you posted above is right
[05:42] <SteveA> and stub should fix linkchecker sometime
[05:42] <sabdfl> i'm mailing the list, to ask folks to be consistent, should I use the above, or =""?
[05:43] <SteveA> use ="", as we can always do a mass replacement if linkchecker cannot be fixed
[05:43] <SteveA> because there is only one way to spell action="", but multiple ways to spell the TALES version
[05:43] <SteveA> and the right thing to do is to fix linkchecker
[05:44] <mpt> to be fair to linkchecker, the usual meaning of action="" on most sites would be "oops"
[05:44] <mpt> it just so happens that we use it often
[05:44] <daf> action="" is perfectly valid
[05:45] <SteveA> daf: yes.  we checked the RFC last time this topic came up
[05:45] <bradb> sabdfl: it'll take five mins to fix (cp foo bar, vim bar, delete a small snippet, change the ZCML, baz commit -s "[trivial]  ..."). if i don't do this, the save changes button will show on the view-only form when people who have edit privs view the view-only form
=== daf wonders what happened to his merge request
[05:45] <kiko> mpt, what class can I use for some text that will say "No bugs have been filed on this product"?
[05:45] <daf> mpt: hi
[05:45] <mpt> kiko: "discreet"
[05:45] <sabdfl> bradb: ok, go ahead
[05:45] <bradb> cheers
[05:45] <mpt> daf: ho
[05:46] <mpt> ugh, 3.45am :-(
[05:46] <sabdfl> morning mpt :-)
[05:46] <kiko> mpt, should I get rid of this silly bugnavigation table?
[05:46] <kiko> (and use <li> instead?)
[05:46] <daf> mpt: launchpad-editform.pt uses <h3> for the main page title, which is a bit inconsistent
[05:46] <kiko> it's a one-celled table with confusing highlighting...
[05:46] <mpt> kiko: where?
[05:47] <kiko> mpt, in the latest-bugs portlet I said
[05:47] <mpt> daf: I saw that earlier today ... do you have an example URL handy?
[05:47] <carlos> kiko, Before you see it and start crying... the import is failing now because it's missing some DB permissions
[05:47] <carlos> daf, did you see salgado's report about the Rosetta preferences page?
[05:48] <kiko> mpt, for instance localhost:6038/products/malone
[05:48] <carlos> daf, seems like we are missing tests for that part 
[05:48] <daf> carlos: looks like that error page has expired
[05:49] <mpt> kiko: where'd you get that sampledata and port? :-)
[05:49] <mpt> kiko: oh, I see
[05:49] <mpt> yes, use a <ul>
[05:49] <carlos> daf, https://chinstrap.ubuntu.com/~dsilvers/paste/fileSKfjfq.html
[05:49] <kiko> what class, mpt?
[05:49] <mpt> kiko: there isn't one for bugs yet
[05:50] <daf> carlos: hmmm
[05:50] <mpt> daf: Are you suggesting that I should fix it? :-)
[05:50] <mpt> (the <h3>, I mean)
[05:50] <daf> mpt: well...
[05:51] <daf> mpt: either that or tell me how to fix it
[05:51] <BjornT> SteveA: i've had to look at sqlobject's internal several times, wouldn't say i know it well, though. what's your question?
[05:51] <mpt> daf: the heading shouldn't be there at all ... Anything interesting it contains should be in the <h1>
[05:51] <SteveA> i'm trying to work out why i have two person objects that are different objects, but have the same id
[05:52] <daf> mpt: https://launchpad.ubuntu.com/products/plonecompositepack/unknown/+pots/compopack-po/+edit
[05:52] <mpt> daf: but I fear that means altering lots of code at once
[05:52] <daf> ok
[05:52] <mpt> daf: I don't have permission for that page
[05:52] <daf> just making sure you're aware of the issue
[05:52] <daf> bah
[05:52] <daf> why isn't mpt an admin?
[05:52] <mpt> yes, I am
[05:52] <mpt> aware of the issue, I mean
[05:52] <daf> right
[05:52] <mpt> not an admin :-)
[05:54] <BjornT> SteveA: i had that problem a while ago as well. somehow the cache got cleared in the middle of an transaction... talked to spiv about it, but he couldn't neither explain it nor reproduce it
[05:54] <SteveA> okay.  i have a live one.  i'll spend a little while looking into it
[05:55] <daf> ah, I fudged the merge
[05:55] <daf> re-submitted now
[05:55] <kiko> mpt, discrete is doing nothing for me 
[05:56] <SteveA> BjornT: i think i see the code that is causing the problem
[05:56] <kiko> oh
[05:56] <daf> discreet, perchance?
[05:56] <kiko> discreet
[05:56] <BjornT> SteveA: cool. what code is it?
[05:56] <kiko> weird.
[05:57] <SteveA> BjornT: let me actually see if it is the code first ;-)
[05:57] <mpt> kiko: I did *not* come up with the name for that class
[05:57] <BjornT> SteveA: ok :)
[05:58] <kiko> mpt, liar!
[05:58] <mpt> It's from plone.css
[05:58] <mpt> and it's correctly spelled, it's just likely to be misspelled by Brazilians
[05:59] <kiko> Barzilians make no mistakes!
[06:00] <bradb> kiko: LPI meeting in 2, right?
[06:00] <daf> http://www.google.com/search?q=%22discreet+mathematics%22
[06:00] <kiko> bradb, YES!
[06:00] <daf> kiko: I did a bit of work on the source package stuff
[06:00] <bradb> in #canonical-meeting?
[06:00] <kiko> daf, you da man!
[06:00] <daf> let me find that patch...
[06:00] <mpt> daf: http://www.google.com/search?hl=en&lr=&q=%22very+discrete%22
[06:01] <kiko> yeah
=== morgs [~morgan@wblv-146-236-76.telkomadsl.co.za]  has left #launchpad [] 
[06:01] <daf> mpt: :)
[06:03] <carlos> debonzi, when will gina start hoary/warty/breezy imports into production?
[06:03] <debonzi> carlos, not sure.. stub is taking care of it
[06:03] <kiko> debonzi, are you sure? stub seemed to be halted by the gina problems he reported
[06:04] <kiko> Kinnison, I am holding you reponsible for anything that happens or doesn't to gina in the next days :-P
[06:04] <carlos> debonzi, but the idea is that it start running this week, right?
[06:04] <dilys> Merge to rocketfuel@canonical.com/launchpad--production--1.24: [trivial]  Patches for production (patch-2: carlos.perello@canonical.com, stuart.bishop@canonical.com, rocketfuel@canonical.com)
[06:04] <Kinnison> kiko: I see
[06:05] <kiko> seriously
[06:05] <Kinnison> kiko: very well
[06:05] <debonzi> kiko, there was no problem in gina AFAICS.. the problem was that warty was not available on the launchpad db.. I talked with him today.. he has made some improvements that I am about to check
[06:05] <kiko> you guys need to make it happen
[06:05] <debonzi> carlos, yes.. it should happen as soon as possible..
[06:05] <carlos> ok
[06:05] <kiko> no more excuses
[06:05] <Kinnison> kiko: Indeed. I appreciate that. I do my best
[06:05] <kiko> this run has been delayed for way too long
=== koke_ [~koke@adsl229-164.unizar.es]  has joined #launchpad
=== Kinnison nods
[06:06] <carlos> koke_, hi
[06:06] <Kinnison> It is getting out of hand
[06:06] <koke_> hi! :)
[06:09] <kiko> Kinnison, I'm going to talk to debonzi today
=== Kinnison nods
[06:10] <Kinnison> I've just sent an email to stub and debonzi, CCd to you about it
[06:11] <daf> kiko: https://chinstrap.ubuntu.com/~dsilvers/paste/filejhoxSJ.html
[06:11] <daf> kiko: that's what I have so far
[06:11] <daf> kiko: that gets me out of one DB improt into browser code
[06:15] <SteveA> hi koke_ 
[06:15] <kiko> daf, ah, neat
[06:16] <daf> if it looks ok to you, it means I can put my menus stuff up for review
=== jd-fud is now known as jdahlin
=== comadreja [~comadreja@80.224.108.240]  has joined #launchpad
[06:38] <carlos> sabdfl, daf: Until we implement a way to remove POFile and POTemplate objects, I need a product placeholder to move there POTemplate duplicates that should be removed so people doesn't translate them
[06:38] <carlos> sabdfl, daf is it ok to create a product 'deprecated' to store them there?
=== lifeless [~robertc@dsl-211.17.240.220.rns02-kent-syd.dsl.comindico.com.au]  has joined #launchpad
[06:42] <carlos> kiko, ^^^
[06:43] <kiko> I'm busy
[06:43] <kiko> and hmmm, I don't know if I approve
=== carlos waits then until someone decides it while tags the obsolete POTemplates
[06:48] <kiko> carlos, what about templates with translations for languages that should be hidden?
[06:49] <kiko> bradb, how easy is it to produce a link to the person a bug is assigned to?
[06:50] <kiko> and how easy is it to omit a field if it's not relevant (in the read-only display)
[06:50] <carlos> kiko, that's another issue
[06:50] <bradb> kiko: link for a person in ZPT should be (in theory, but untested) person/fmt:url, i think
[06:50] <carlos> kiko, the right fix is to implement a way to merge POFiles and to remove POTemplate and POFiles
[06:51] <carlos> kiko, so we don't lose translations and we can remove them after the merge is done (if needed)
[06:51] <bradb> kiko: for a read-only display...is the template being used for any other reason that the read-only display?
=== jdahlin [~jdahlin@200-171-140-32.dsl.telesp.net.br]  has left #launchpad [""] 
=== Keybuk hugs smerge-mode
[06:52] <carlos> kiko, I'm asking for a way to fix the UI until we implement that feature so we "hide" those pofiles from the users and they don't lose their time with that. Overtime, the potemplate duplication should disappear as our automatic imports is being improved overtime
[06:52] <kiko> carlos, I was just asking if you were also proposing to fix that problem as well.
[06:53] <kiko> bradb, visit the task page in editable and non-editable mode.
[06:53] <carlos> kiko, we already want to fix it
[06:53] <carlos> kiko, we were waiting post 1.0 to write a spec and implement it
[06:53] <kiko> bradb, the issues I see are: 1) "Remote bug details" is usually blank and confusing in the non-editable mode. 2) the person isn't linked to
[06:53] <bradb> kiko: my next merge is about to break it into two separate templates. (first merge request failed because of a bugtask.zcml conflict)
[06:54] <kiko> bradb, /please/ wait for my stuff to land before merging, I will cry blood
[06:54] <kiko> I just submitted my merge request
[06:54] <kiko> aieee
=== kiko prays
[06:54] <bradb> augh, i hate it when these five minute things turn into 2 hour jobs
[06:56] <kiko> carlos, but could this problem also be fixed by using a deprecated product?
[06:56] <kiko> well
[06:56] <carlos> kiko, no, because we move a POTemplate + all its POFiles
[06:56] <kiko> s/fixed/worked around/
[06:56] <kiko> I see.
[06:56] <carlos> kiko, and we don't have a way to move POFiles around
[06:56] <carlos> we could do it using Stuart's DB interface
[06:57] <kiko> bradb, how can I see what PQM is doing?
=== mpt [~mpt@203-167-186-120.dsl.clear.net.nz]  has joined #launchpad
[06:57] <kiko> mpt!
[06:57] <carlos> and could be a bit complicate... I prefer to fix it with the merge solution
[06:57] <kiko> okay.
[06:57] <carlos> kiko, ps aux|grep pqm at chinstrap
[06:57] <bradb> kiko: watch 'ps aux | grep pqm' on chinstrap is the best i can do
[06:57] <kiko> my tests pass
[06:57] <kiko> my merge request has been sent
[07:00] <daf> kiko: so, that diff?
[07:00] <kiko> FUCKING @#@!#@! PQM
[07:00] <kiko> conflicts galore
[07:00] <kiko> should I give up
[07:00] <kiko> should I give up
[07:00] <kiko> should I give up
[07:01] <kiko> man
[07:01] <kiko> 6 conflicts in page templates
[07:02] <kiko> daf, it looks like a start
[07:02] <bradb> welcome to lp development :)
[07:02] <daf> kiko: should I commit it to my menus branch or what?
[07:03] <kiko> daf, I'd rather see it committed directly to RF...
[07:03] <daf> sure
[07:03] <daf> r=kiko?
[07:04] <kiko> daf, what does that change help you with, though?
[07:04] <daf> it means that rather than this:
[07:04] <kiko> are there no existing callsites that use findSourcesByName?
[07:05] <daf> from canonical.launchpad.database import SourcePackageSet
[07:05] <daf>             sp_set = SourcePackageSet(distrorelease=self.context.distrorelease)
[07:05] <daf>             source_package = sp_set[self.context.sourcepackagename.name] 
[07:05] <daf> I can do this:
[07:05] <daf>             source_package = self.context.distrorelease.getSourcePackageByName(
[07:05] <daf>                 self.context.sourcepackagename)
[07:05] <SteveA> any idea why pdb would be ignoring my breakpoints?
[07:05] <daf> kiko: nope, I grepped the whole tree
[07:06] <kiko> daf, the first bit tests to see if we supplied a string, right?
[07:07] <daf> yarr
[07:07] <kiko> that is such a hack
[07:07] <daf> you can pass in a SourcePackageName or a string
[07:07] <daf> mm, it is a bit icky
[07:07] <kiko> docstrings need fixing then
[07:08] <kiko> are you sure that import is non-circular-import-safe?
[07:08] <daf> otherwise, you can have getSourcePackageByName and getSourcePackageBySourcePackageName
[07:08] <bradb> SteveA: maybe try throwing an exception immediately above the breakpoint?
[07:08] <daf> up to you ;)
[07:08] <kiko> daf, I don't think your code is so bad if the docstring clarifies it
[07:08] <daf> ok
[07:08] <SteveA> bradb: the point is to add a breakpoint only when a certain point has been reached
[07:08] <daf> I haven't found any problems with circular imports
[07:08] <kiko> you patch is currently in "ignoring docstrings" mode
[07:09] <daf> yes, that's true
[07:09] <daf> I'll docstring it
[07:09] <kiko> r=kiko with that
[07:09] <kiko> enjoy the ride while it lasts
[07:09] <kiko> 6 conflicts in pagetemplates
[07:09] <bradb> SteveA: ah
[07:25] <kiko-fud> man
[07:26] <ddaa> Keybuk: any reason not to use *.tar.bz2 when they are available from upstream?
[07:26] <Keybuk> nope
[07:26] <ddaa> Cool, let's try and be nice to gnu.org :)
[07:47] <kiko-fud> sabdfl?
[07:48] <sabdfl> hi
[07:49] <kiko-fud> sabdfl, did you by any change remove the Mark this bug as occurring [...]  links?
[07:49] <kiko-fud> (from the -headline.pt portlet)
[07:53] <bradb-lunch> SteveA: how do you write multi-line Attribute docstrings?
[07:53] <bradb-lunch> e.g.
[07:53] <bradb-lunch>     sourcepackagename = Attribute("""A dict like
[07:53] <bradb-lunch>                                      {'old' : ISourcePackageReleaseSet, 'new' : ISourcePackageReleaseSet}
[07:53] <bradb-lunch>                                      or None, if no sourcepackagename was made.""")
[07:53] <bradb-lunch> (er, s/Set/Name/, but anyway)
[07:54] <SteveA> i prefer using less indentation, as it makes things easier to read
[07:54] <SteveA>   sourcepackagename = Attribute(
[07:54] <SteveA>       """yeah...
[07:54] <SteveA>      """)
[07:54] <SteveA> but lining up better
[07:54] <bradb-lunch>     sourcepackagename = Attribute(
[07:54] <bradb-lunch>         """A dict like {'old' : ISourcePackageName, 'new' : ISourcePackageName}
[07:54] <bradb-lunch> ?
[07:54] <bradb-lunch>            or None, if no sourcepackagename was made.""")
[07:55] <bradb-lunch> s/was made/change was made/
[07:55] <SteveA> the first line should be a plain description of what it is for, then say what form it takes.
[07:55] <bradb-lunch> ok
[07:55] <kiko-fud> sabdfl?
[07:55] <SteveA> like "A description of changes to the sourcepackagename of something"
[07:56] <SteveA> also, have you considered using a class with old and new attributes, instead of a dict?
[07:56] <SteveA> it might make things clearer
[07:56] <SteveA> as you can document the old-new stuff in that class
[07:56] <SteveA> class ChangedAttribute:
[07:56] <SteveA>     def __init__(self, old, new):
[07:56] <SteveA> etc.
[07:57] <SteveA> or ChangedValue might be better
[07:57] <SteveA> i dunno.  just a suggestion. 
[07:57] <SteveA> i have't looked at the rest of the code
[07:57] <SteveA> so i can't make a good recommendation
=== SteveA finds a deep bug in sqlos
[07:57] <bradb-lunch> i think it best to stick with what we've got, for now
[07:57] <SteveA> you get what i'm saying thoug?
[07:58] <bradb-lunch> yes
[07:58] <SteveA> cool
=== bradb-lunch & # bbl
=== sabdfl [~mark@sabdfl.silver.supporter.pdpc]  has left #launchpad [] 
=== lamont__ [~lamont@15.238.6.251]  has joined #launchpad
[08:23] <daf> SteveA: you have an XXX in interfaces/general.py
[08:23] <daf> SteveA: do we have a plan for that?
[08:23] <SteveA> daf: i'm kinda busy in the debugger
[08:24] <daf> it's not urgent
[08:24] <daf> but now, while I'm cleaning up interfaces, might be an opportune time to try to fix it
[08:27] <daf> hmm, I'm getting odd failure messages from PQM
=== lifeless_ [~robertc@dsl-211.17.240.220.rns02-kent-syd.dsl.comindico.com.au]  has joined #launchpad
[08:41] <dilys> New Malone bug 1241 filed on source package wings3d by dwbrown: wings3d won't run, missing erlang library
[08:41] <dilys> https://launchpad.ubuntu.com/malone/bugs/1241
=== kiko-fud chants the dilys chant
[08:54] <kiko-fud> BjornT, ping?
[08:54] <carlos> bradb-lunch, BjornT https://launchpad.ubuntu.com/errors/showEntry.html?id=1120589672.070.64057851381
[08:56] <SteveA> kiko-fud: i think i've found out why the staging server consumes a lot of ram.  i think there's connection caches that aren't being properly emptied in sqlobject.
[08:56] <kiko-fud> that is so cool
[08:57] <kiko-fud> sqlos is chock-full-o-bugs
[08:57] <SteveA> yeah, well i'm in its guts now
=== carlos leaves
[09:11] <carlos> see you tomorrow!
[09:11] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=kiko]  IDistroRelease.getSourcePackageByName (patch-2019: daf@canonical.com)
[09:12] <bradb> right, you can't file a bug on a distro release yet (for no other reason than that it isn't implemented yet...and, well, it didn't seem like a good idea to make it simple and obvious to file a bug on a specific release, because then lots of users might start doing that when they don't meant to.)
[09:13] <daf> SteveA: I have a branch where every interface file has an __all__
[09:13] <SteveA> cool
[09:14] <daf> does that need reviewing, or shall I just push it through as [trivial] ?
[09:14] <SteveA> trivial
[09:14] <daf> groovy
[09:14] <daf> it can land with the other import fascism stuff, if PQM stops being weird
[09:15] <kiko-fud> @#@!$@!#
[09:15] <kiko-fud> dilys, accept my changes ffs
[09:15] <daf> kiko-fud: you getting weird CVS errors too?
[09:16] <kiko-fud> nope
[09:16] <kiko-fud> she's just slow
[09:16] <daf> ah
[09:25] <dilys> New Malone bug 1242 filed on product Malone by Brad Bollenbach: BugPriority and BugSeverity vocabs are misnamed
[09:25] <dilys> https://launchpad.ubuntu.com/malone/bugs/1242
[09:35] <SteveA> daf: i just received a discard message from launchpad-error-reports
[09:35] <SteveA> Hello Carlos Perello Marin,
[09:35] <SteveA> Rosetta has finished exporting your requested files.
[09:35] <SteveA> However, problems were encountered exporting the
[09:35] <SteveA> following files:
[09:35] <SteveA>  * es.mo
[09:35] <SteveA>  * es_ES.mo
[09:35] <SteveA>  * ko.mo
[09:35] <SteveA> and so on
[09:37] <daf> discard?
[09:38] <daf> ddaa: around?
[09:43] <SteveA> daf: the error reports list discarded it
[09:43] <daf> do you know why?
[09:43] <SteveA> no
[09:43] <daf> hmm
[09:44] <daf> I thought stub (or maybe somebody else) had whitelisted mail from that address
[09:44] <daf> certainly those mails have gotten through before
[09:44] <SteveA> From:
[09:44] <SteveA> rosetta@canonical.com
[09:45] <daf> yes
[09:45] <daf> hmm:
[09:45] <daf> There were 8 database import violations.
[09:45] <daf> There were 32 imports 'from *' without an __all__.
[09:45] <daf> I wonder how we got back up to 8
=== asmodai [~asmodai@sakko.demon.nl]  has joined #Launchpad
[09:59] <salgado> SteveA, do you have two minutes to talk about a problem I found and am not sure what to do so it won't happen again?
[09:59] <SteveA> ok
[10:00] <salgado> so, someone requests something that needs email validation, we send that person a token, and that token has a type
[10:00] <salgado> when you go to that token page, I get the type and then redirect you to the correct page for that type
[10:01] <salgado> each of these correct pages has a self-posting form
[10:01] <ddaa> daf: pong
=== sabdfl [~mark@host217-37-231-22.in-addr.btopenworld.com]  has joined #launchpad
[10:02] <salgado> no problem up to now. but someone change the action of the form to be action="." and this broke people merge
[10:02] <sabdfl> daf: i have a nice surprise for you and carlos tomorrow ;-)
[10:03] <sabdfl> salgado: that was me, i apologise
[10:03] <salgado> even worst, I can't see how to catch these kind of problems with pagetests
[10:03] <sabdfl> i think i buggered up a few pages like that
[10:03] <daf> sabdfl: ooh!
[10:03] <daf> ddaa: I was cleaning up some of the interface code
[10:03] <daf> ddaa: and encountered some oddities in interfaces/pyarch.py
[10:03] <salgado> sabdfl, don't worry. I think this is good because we need to find a way to catch this kind of problems
[10:03] <ddaa> daf: please nuke all you want
[10:03] <bradb> is there a way to make all string literals in a python module be unicode without prefixing all of them with a u?
[10:04] <daf> ddaa: well...
[10:04] <ddaa> daf: this stuff is essentially all cruft.
[10:04] <salgado> SteveA, are you with me?
[10:04] <daf> ddaa: you import ArchiveNotRegistered, but then define a class by the same name
[10:04] <sabdfl> SteveA: is there a nice way to traverse and consume multiple url path components?
[10:04] <SteveA> salgado: we need to start using ClientForm in order to catch these kinds of problem.  stub's been looking at it.  it will allow us to process the form much like a browser does.
[10:04] <SteveA> bradb: no, use u"literal"
[10:04] <sabdfl> say i want a url like foo/+bar/baz
[10:04] <ddaa> daf: hu... that's a arch.broker oddity... which is also essentially all cruft
[10:04] <sabdfl> and i never want a BarSet
[10:04] <bradb> SteveA: ok
[10:04] <sabdfl> i never want a page like foo/+bar/
[10:04] <sabdfl> i always want a baz
[10:05] <sabdfl> how would you do that?
[10:05] <ddaa> daf: the arch.broker and pyarch interface are two bits that need to be refactored using a hacksaw.
[10:05] <daf> ddaa: is this file 100% nukable?
[10:05] <SteveA> so, in the traversal for a foo, you want to essentially say '+bar/baz' is a name you're interested in
[10:05] <sabdfl> the standard traverser seems to get (object, request, name)
[10:05] <SteveA> you can't just say that though
[10:05] <daf> ddaa: or does it need to be cleaned up by somebody who knows what's going on?
[10:05] <sabdfl> where name would be +bar
[10:05] <SteveA> so you have to use the request itself
[10:05] <sabdfl> i want to "consume" the +bar and the baz
[10:06] <SteveA> yes
[10:06] <SteveA> there's an api on the request to do that
[10:06] <sabdfl> SteveA: ok, i see that this will allow me to peek ahead to the bar
=== Burgundavia [~corey@S0106000000cc07fc.gv.shawcable.net]  has joined #launchpad
[10:06] <sabdfl> but how do i tell zope that i've also used up the baz
[10:06] <SteveA> let me check that API
[10:06] <ddaa> daf: I'm not very conversant with the uses of interfaces in launchpad, but as far as I know it's essentially all nukable. I believe no zope thing use it. But I might be wrong.
[10:07] <daf> ddaa: hmm -- guess I could try nuking it and seeing if the tests still pass
[10:07] <SteveA> you need to use two apis from request
[10:07] <ddaa> daf: there are some specific tests in the canonical.arch stuff that depend on it.
[10:07] <SteveA>   request.getTraversalStack() and request.setTraversalStack()
[10:07] <sabdfl> SteveA: ok, is there an example in LP you can point me at?
[10:07] <ddaa> daf: but that's circular stuff, tests that crufty code implements a crufty interface.
[10:07] <SteveA> you get a list from request.setTraversalStack()
[10:08] <sabdfl> i think we want to avoid FooSubSet's like this
[10:08] <SteveA> inspect / alter this list.  then set back to the request.
[10:08] <daf> ddaa: https://chinstrap.ubuntu.com/~dsilvers/paste/file1CrjuK.html
[10:08] <daf> ddaa: those are my immediate concernts
[10:08] <sabdfl> SteveA: the list is the remaining name items?
[10:08] <SteveA> sabdfl: if we want to do this a lot, then i can write something to make this straightforward.
[10:08] <SteveA> yes, in reverse order iirc
[10:09] <sabdfl> thanks SteveA!
[10:09] <SteveA> i suggest popping into the debugger in your traverse function
[10:09] <SteveA> and inspecting getTraverseStack()
[10:09] <SteveA> to get a feel for what it looks like
[10:10] <SteveA> if you have just +bar and nothing more, return None from your traverse function
[10:10] <SteveA> and that will be a 404
[10:10] <ddaa> daf: I do not know about the first. The second and third one as wrong even in the original intent (it was supposed to define the exceptions only if pyarch was not available), and the last one is probably an offshot of those.
[10:12] <sabdfl> *** AttributeError: 'BrowserRequest' object has no attribute 'getTraverseStack'
[10:12] <sabdfl> SteveA: that's what it looks like ;-)
[10:13] <sabdfl> ah, it's getTraversalStack()
[10:13] <SteveA> yeah
[10:14] <SteveA> i'll add a facility to do this "consuming a path segment" when i land the traversal / urls / breadcrumbs refactor that we discussed.
[10:14] <SteveA> then it will be easy to apply this when we need an extra namespacing thing
[10:18] <SteveA> sabdfl: i have tracked down the cause of the problem we had earlier to do with comparing persons
[10:18] <sabdfl> what was it?
[10:18] <sabdfl> did you have a security proxied object on the one side?
[10:18] <SteveA> i don't yet know how to fix it.  it is to do with a connection's __del__ being called.
[10:18] <SteveA> nothing to do with the security proxies
[10:19] <sabdfl> i've landed with that security proxy weirdness in there
[10:19] <SteveA> the connection's __del__ is removing objects from the cache
[10:19] <sabdfl> as long as nobody adds a /fmt:date we will be fine :-)
[10:19] <SteveA> it isn't the security proxies.  the two person objects were different objects.
[10:19] <SteveA> they're meant to be the same person object
[10:20] <SteveA> the GC is interrupting the flow of the program
[10:20] <SteveA> and doing some collection, including the dbconnection
[10:20] <SteveA> which is removing the cache
[10:20] <SteveA> now, i think that this may be a dbconnection from a different thread
[10:20] <SteveA> or from a previous transaction
[10:21] <bradb> salgado: i just replied to your FBN review. might you have a chance to take a look so that we can try and land this today?
[10:21] <SteveA> in which case, the fix is to make the connection more picky about which cache it empties
[10:21] <SteveA> and i now understand more sqlobject internals than i really wanted to.
[10:23] <bradb> SteveA: is it a good idea for boolean comparisons to rely on cache behaviour?
[10:23] <SteveA> doesn't matter.
[10:23] <SteveA> if the cache is screwed up, then we have more to worry about than just that.
[10:24] <SteveA> it means that you may be changing some state, but still get an old object lying around.
[10:24] <salgado> bradb, cool. I'll try to have a look at it
[10:24] <SteveA> so, a fix to __eq__ would fix this on the surface level
[10:24] <SteveA> but would be hiding some deeper problems
[10:25] <bradb> i agree that broken caching is a bad thing, i was just wondering if writing code the depends on caching behaviour/policy working in a specific way is a reliable coding practice
[10:25] <SteveA> all our code depends on the cache working properly
[10:26] <bradb> salgado: cool, thanks
[10:28] <bradb> kiko-fud: i didn't notice your branch land yet. does this mean i shouldn't merge my branch that splits the task page into view/edit pages?
[10:31] <bradb> ddaa: does baz give me a way yet to show all of my branches that have patches that aren't yet in rf?
[10:32] <SteveA> okay, i think i can fix this.  i still can't explain exactly why it is happening.  i need to look some more at the cache code first.
[10:33] <ddaa> bradb: not really, I have a hack here (idea stolen from fai actually) that shows which patchlogs from the current branch are not present in rocketfuel.
[10:34] <SteveA> so bradb, we should rely on cacheing not being broken.  that's what i'm doing right now.
[10:34] <bradb> i've completely lost track of the branch i had going that made the sidebar into portlets on the search page
[10:35] <bradb> SteveA: ok
[10:37] <bradb> ddaa: any idea if that kind of functionality is intended to appear soon in baz?
[10:39] <ddaa> bradb: it has not been discussed a lot before, and the current focus is on UI tweaks (matthieu moy) and deep reorganisations (rob collins), not new features. So you should rather script something up if you need it.
[10:40] <bradb> ok
[10:41] <SteveA> bradb: add them to the pending reviews page for jamesh's script to deal with <.5 wink>
[10:41] <bradb> heh heh
[10:44] <mpt> bradb!
[10:44] <bradb> mpt!
[10:46] <mpt> bradb: Is cvereference-index.pt used any more? cveref.zcml says it is, but the URL pattern it gives just redirects to the bug page.
[10:46] <bradb> never looked at that page. /me checks.
[10:52] <bradb> mpt: i added a CVE ref to bug #3 in my local data, and went to: http://localhost:8086/malone/bugs/3/cverefs/1. i got a NotFoundError.
[10:52] <bradb> i can't think of any place that we're linking to that page in malone though (and i can't see a huge benefit in having index pages for each and every little thing on a bug), so if you can remove it from the ZCML (and the template), and no tests fail, it should be ok
[10:52] <bradb> unless sabdfl says otherwise
[10:53] <sabdfl> bradb: err... no
[10:54] <sabdfl> we do need a page which shows a cve ref, talks about what they are, and links to the ref on the CVE site
[10:55] <bradb> sabdfl: so, if i understand correctly, you prefer to go the route that each little thing on a bug (a watch, an infestation [some day] , a CVE ref, an external link, etc.) should have an index page of its own?
[10:56] <bradb> (an attachment...)
[10:57] <mpt> bradb: Was your NotFoundError the result of clicking on a link?
[10:57] <SteveA> i can now explain exactly why the cache errors are occuring.
[10:57] <bradb> mpt: no, i'm unaware of any link directly to that page
[10:58] <mpt> bradb: It's strange that cverefs/1/+edit should work while cverefs/1 does not
[10:58] <SteveA> i'm going to bed.  i'll actually fix it tomorrow.  and talk with stub about it, because he needs to know what happened.
[10:59] <bradb> mpt: let's take one step back here: is it good to have to go to a separate page to edit a cve ref? and then another separate page to edit a watch? and then another separate page to edit a ext ref?, etc.
[11:00] <mpt> bradb: If you put edit forms for them all on the bug page, it would become extremely crowded
[11:00] <sabdfl> night SteveA
[11:01] <bradb> mpt: might there be a way that they can be "there", but not necessarily visible, unless the user specifically clicks something?
[11:01] <mpt> bradb: Yes, but even then, there wouldn't really be enough room for editing in a portlet.
[11:02] <bradb> mpt: does this stuff have to be shown in portlets?
[11:03] <mpt> Not necessarily, no
[11:04] <bradb> mpt: in your ideal world, as a malone end-user, would prefer the capacity to change many things at once, and sign off with a comment, or would you prefer to have to visit separate pages to change each one of those things, and not have the option to comment?
[11:04] <mpt> I'd prefer to be able to change many things at once
[11:05] <bradb> sabdfl: what about you?
[11:05] <mpt> though that has to be balanced against clutter
[11:06] <bradb> i agree. i'm not implying that it would be simple to design this interface in a way that normal human beings would understand, but it seems like the right direction to aim at, at least
[11:08] <bradb> mpt: in any case, i guess the answer to your question for now is that we can't remove that cve index form just yet
[11:08] <mpt> ok.
[11:10] <bradb> in other news, i seem to have lost the changes i made to turn the sidebar into portlets again on the search listing page. mpt, are you doing any work on the search listing? if not, were there any ideas you had planned specifically related to the portlets/sidebar layout fu?
[11:11] <bradb> (31 branches and a small brain == a hard life)
[11:11] <mpt> sure, Burgundavia mentioned this yesterday
[11:12] <mpt> I think it would be useful to establish a pattern of "a + sign at the bottom of a list, on the left, means add something to the list"
[11:12] <mpt> (a lot of software already uses that pattern)
[11:12] <mpt> so the "Report a bug" link can go there
[11:13] <Burgundavia> can that be carried into the urls?
[11:13] <Burgundavia> so that +bugs becomes bugs?
[11:13] <mpt> bradb: and the various filters can become a <select> above the list.
[11:13] <salgado> bradb, you got mail
[11:13] <bradb> salgado: awesome thanks
[11:14] <mpt> Burgundavia: No, we need to guard against the possibility that any distro ever calls one of its releases (or any product ever calls one of its branches, etc) "bugs" or "translations" or "calendar" etc
[11:14] <Burgundavia> true
[11:14] <mpt> anyway, I'm off to get my yellow fever vaccine, bbl
=== kiko scratches head
[11:14] <kiko> wtf is pqm dropping my requests
[11:14] <kiko> hey mpt
[11:14] <salgado> bradb, also, can I ask you that you send review replies direct to me (cc:ed launchpad-reviews@, of course), so it'll fall into my inbox and will get high priority?
[11:14] <kiko> good luck
[11:15] <bradb> salgado: sure, no problem
[11:20] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Fix the person's page and move links to reassign product/project/distro/distrorelease to the right portlets. r=kiko (patch-2020: guilherme.salgado@canonical.com)
[11:21] <kiko> FFS
=== kiko kicks dilys 
[11:21] <dilys> ow
[11:39] <kiko> mpt, what's up with the right-aligned <th>s?
[11:39] <kiko> it makes all our tables look totally freaky
[11:40] <daf> kiko: did your merge actually succeed, and dilys is not reporting it, or what?
[11:40] <kiko> daf, it didn't succeed, but pqm didn't return anything to me either
[11:41] <kiko> I say fuck pqm
[11:41] <daf> hmm
[11:41] <daf> did the mail get lost somewhere?
[11:42] <kiko> I don't think so
[11:42] <kiko> I just reset
[11:42] <kiko> reseNt
[11:42] <kiko> and am waiting
[11:43] <bradb> kiko: did you check your mail on chinstrap?
[11:44] <kiko> nope
[11:44] <kiko> will do
[11:44] <daf> how do you do that?
[11:44] <kiko> kiko@chinstrap ~ $ mail
[11:45] <kiko> No mail for kiko
[11:45] <bradb> ouch
[11:45] <kiko> bradb, is there any auto-linkification code present in zope3?
[11:46] <bradb> there might be, but i don't know about it
[11:48] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Unbreak people merge and make IPerson.unvalidatedemails return only emails from tokens of type VALIDATEEMAIL. (patch-2021: guilherme.salgado@canonical.com)
=== asmodai [~asmodai@sakko.demon.nl]  has joined #Launchpad
[11:53] <lifeless_> morning all
=== asgeirf [~asgeirf@203-206-229-169.dyn.iinet.net.au]  has joined #launchpad
[11:55] <kiko> lifeless, PQM seems to have dropped some requests from me -- can you please check?
[11:56] <lifeless> 22:13 mail from you
[11:56] <bradb> salgado: replied to your reply. is this r=salgado, or is there anything else you'd like me to do?
[11:56] <lifeless> 19:20 mail from you
[11:57] <lifeless> kiko - I'm not sure what I'm looking for - I can't see any mails that aren't hter e;
[11:58] <salgado> bradb, cool. I thought I already gave r=salgado, but if not, now you have
[11:58] <bradb> sweet, thanks
[11:59] <kiko> lifeless, and before the 19:20 mail?
[12:00] <kiko> Jul  5 15:15:59 localhost postfix/smtp[7432] : BD1F92553: to=<pqm@pqm.ubuntu.com>, relay=www.async.com.br[200.171.140.32] , delay=1, status=sent (250 2.0.0 j65IGFZo018404 Message accepted for delivery)
[12:00] <lifeless> thats utc ?
[12:01] <kiko> sorry, no
[12:01] <kiko> that's UTC-3
[12:02] <lifeless> did you send another at 15:20 ?
[12:02] <lifeless> nm
[12:02] <lifeless> yes tht was processed
[12:02] <kiko> and what happened?
[12:03] <lifeless> looks like it failed
[12:03] <kiko> okay
[12:03] <kiko> thanks.
[12:03] <lifeless> hang on
[12:03] <kiko> somebody dropped an email between then and now
[12:03] <lifeless> yes, failed
[12:03] <lifeless> it went onto trying dafs
[12:04] <kiko> okay.
[12:04] <lifeless> do you get mail sent to kiko@async.com.br ?
[12:04] <kiko> it's forwarded there eventually, yes