[12:11] <sabdfl> mpt: pls would you help ogra design a less bogn screensaver unlock dialog?
[12:11] <sabdfl> bong, even
[12:12] <mpt> sabdfl: It'd be a pleasure
[12:13] <sabdfl> thanks muchly
[12:13] <mpt> The design isn't the problem, ogra and I both know what's wrong, but apparently even moving a button is a herculean code task
[12:13] <sabdfl> errr... why?
[12:14] <mpt> something to do with the way the xscreensaver code is written, combined with it not using a toolkit, I guess
[12:14] <mpt> ask ogra
[12:16] <Burgundavia> sabdfl, is it worth pouring a lot of money into the xscreensaver dialog when we are likely to drop it for dapper?
[12:19] <Nafallo> gnome-screensaver wfm ;-)
[12:19] <ddaa> omg... svn is so BoOOoong...
[12:20] <ddaa> say you have a branch A with 3 commits, latest revision is 4 (1 is import). Then you create a branch B with one import and one commit (latest revision of B is 6).
[12:21] <ddaa> It _looks like_ when you update A after creating B, then you update it to... revision 6!
[12:21] <ddaa> even though revisions 5 and 6 have nothing to do with A!
[12:27] <lifeless> here
[12:27] <lifeless> looking aete it now
[01:02] <sabdfl> lifeless: be great if i can land stuff tonight
[01:16] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: rollout failed patch (patch-2418)
[01:18] <dilys> Merge to rocketfuel@canonical.com/hct--devel--1: revert failed patch (patch-19)
[01:18] <dilys> Merge to rocketfuel@canonical.com/sourcerer--devel--0: revert failed patch (patch-29)
[01:19] <Nafallo> hmm
[01:19] <Nafallo> looks fun :-P
[01:22] <lifeless> sabdfl: scotts patch is backed out, running check again to be sure
[01:26] <sabdfl> thanks rob
[01:26] <lifeless> no probs
[01:27] <lifeless> no idea how I let it slip through
[01:27] <sabdfl> np
[01:27] <sabdfl> we'll sort it out in the morning
[01:27] <sabdfl> sweet dreams
[01:27] <lifeless> yup
[01:27] <sabdfl> did you have fun this evening?
[01:27] <lifeless> thanks
[01:27] <lifeless> I'll be another 20+ while the final test runs
[01:27] <lifeless> yup, was goo d to catch up. we were as a 'mysociety.org' evening
[01:28] <lifeless> which is some sort of apolitical political hackers group
[01:28] <lifeless> and was interesting in its own right
[01:32] <cprov> lifeless: hi rob, is it solved already ?
[01:32] <lifeless> cprov: I've rolled the patch out
[01:33] <lifeless> but pqm is still disabled while I check tests really do pass again
[01:34] <cprov> lifeless: ok, I can do it later, at home, thank you for come and fix it ;)
[01:35] <lifeless> np
[01:40] <lifeless> ok, pqm is back
[01:40] <lifeless> night all
[01:50] <cprov> night guys
[02:48] <dilys> Merge to rocketfuel@canonical.com/launchpad--production--1.32: Cherry pick patch-2416 into production (patch-5: stuart.bishop@canonical.com, rocketfuel@canonical.com)
[03:15] <dilys> Merge to rocketfuel@canonical.com/launchpad--production--1.32: Executive override on production link style (patch-6: steve.alexander@canonical.com)
[08:07] <sabdfl> morning all
[08:08] <sabdfl> stub: morning - did that landing go ok on production-branch?
[08:22] <lifeless> 10:48 < dilys> Merge to rocketfuel@canonical.com/launchpad--production--1.32: Cherry pick patch-2416 into production (patch-5: stuart.bishop@canonical.com, 
[08:22] <lifeless>                rocketfuel@canonical.com)
[08:22] <sabdfl> i don't think that's it
[08:22] <sabdfl> my code never landed in production
[08:23] <sabdfl> i asked stub to merge directly from my branch
[08:23] <sabdfl> it didn't land because of PQM fuckage last night
[08:23] <sabdfl> stub: please ack?
[08:24] <stub> mark.shuttleworth@canonical.com/launchpad--cverework--0--patch-26 ?
[08:24] <sabdfl> stub: yes
[08:24] <stub> I thought you wanted that in the next production rollout, not cherry picked into current.
[08:24] <sabdfl> stub: i want that in the rollout for tuesday
[08:25] <stub> Yes - it will be.
[08:25] <sabdfl> ok, did it land smoothly?
[08:25] <sabdfl> lifeless: is PQM landing things again now?
[08:25] <stub> Production branch hasn't been created yet - I generally do it on Monday in case plans change re: what needs to be rolled out.
[08:26] <stub> I've got it here in my notes though so it won't be missed
[08:26] <stub> I'll do it now so you won't fret on your break ;)
[08:26] <sabdfl> i'm away from this evening, so perhaps its worth confirming it merges cleanly now?
[08:27] <sabdfl> thanks dude
[08:28] <sivang> morning all
[08:28] <sabdfl> hey sivang
[08:34] <lifeless> sabdfl: yes
[08:49] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=spiv]  script librarian logging (patch-2419: stuart.bishop@canonical.com)
[08:53] <dilys> Merge to rocketfuel@canonical.com/dists--devel--0: [trivial]  Prepare production 1.33 for Tuesday rollout (patch-114: stuart.bishop@canonical.com)
[08:59] <stub> lifeless: Can you please mirror that production branch
[09:02] <SteveA> morning
[09:05] <stub> morning
[09:10] <SteveA> hm... so i need to tell pqm to merge that UI underlines thing...
[09:18] <sabdfl> SteveA: i fear your patch will collide with mine
[09:18] <sabdfl> please drop mpt's bugtask changes
[09:19] <sabdfl> i've made substantial cleanups to bug-headline-tasks and don't want them overridden
[09:19] <stub> So I need to cherry pick the underlines off patch into Tuesdays production release too?
[09:19] <sabdfl> i already did the no-underline thing in the bugtask-headlines work that i did
[09:22] <SteveA> sabdfl: the patch is in pqm's queue.  http://pqm.ubuntu.com/
[09:22] <SteveA> https://chinstrap.ubuntu.com/~dsilvers/paste/filefkv7L3.html
[09:23] <SteveA> that is the diff it is trying to apply
[09:23] <SteveA> i don't think pqm has a "cancel please" command
[09:23] <SteveA> unless you're rob.
[09:24] <spiv> SteveA: It does if it's not at the head of the queue yet... temporarily break your mirror by e.g. moving it.
[09:24] <SteveA> spiv: is that going to break anything else?
[09:24] <spiv> Not exactly elegant, but effective...
[09:24] <spiv> Well, just anyone else trying to use the mirror of your archive.
[09:25] <SteveA> sabdfl: look at http://pqm.ubuntu.com/  is the third thing in the queue from you (launchpad--cverework--0) going to be broken by changes to launchpad.css and bug-headline-tasks.pt ?
[09:25] <spiv> You could narrow the scope by just breaking that bit of the mirror, I guess, but that's more slightly fiddly and thus slightly more likely that user error will cause real problems :)
[09:26] <sabdfl> SteveA: yes
[09:26] <sabdfl> but it will be broken anyway
[09:26] <sabdfl> i sent a prior merge in and it just came back failure
[09:26] <sabdfl> though all tests pass here
[09:26] <spiv> SteveA: Hmm, too late anyway, it's now the head of the queue...
[09:27] <sabdfl> ah fahhhrk
[09:27] <sabdfl> we need a new dependency
[09:27] <sabdfl> how do i do that?
[09:27] <SteveA> as in, from hoary?
[09:27] <sabdfl>     import PIL.Image  ImportError: No module named PIL.Image
[09:28] <spiv> python-imaging?
[09:28] <SteveA> you need to ask elmo to install python-imaging
[09:28] <SteveA> for python 2.4
[09:28] <sabdfl> on which machines?
[09:28] <SteveA> on all the machines we use
[09:28] <sabdfl> elmo: ping
[09:28] <sabdfl> Znarl: ping
[09:28] <SteveA> so, chinstrap, macquarie (perhaps), gangotri, mawson
[09:28] <SteveA> dunno about any others
[09:28] <sabdfl> SteveA: could you kill your merge please?
[09:28] <sabdfl> i want to land this damn branch of mine
[09:29] <sabdfl> i've spent an hour on it already this morning, and don't have much time today before leaving
[09:29] <SteveA> also, it needs to be announced on the list, and docs updating
[09:29] <stub> chinstrap, gangotri, asuka, macquarie, mawson, possibly macaroni and emperor and the importd boxes depending on if they need to import modules that depend on it. 
[09:29] <SteveA> sabdfl: i moved my archive to a different name
[09:29] <sabdfl> SteveA: you're a star. thanks very much.
[09:29] <SteveA> sabdfl: dunno if it screwed pqm's merge in time though
[09:29] <spiv> sabdfl: No-one without pqm privs would be able to stop the current merge, unless Steve got lucky and moved it in time.
[09:29] <sabdfl> lifeless: ping
[09:29] <sabdfl> ^^
[09:30] <stub> I've killed it (by killing PostgreSQL, all the tests will fail)
[09:30] <sabdfl> my kingdome for a revision control system that does a status in less than 8 minutes
[09:31] <sabdfl> thanks stub
[09:31] <spiv> Hmm, it was still doing build-config, so SteveA was probably fast enough.
[09:31] <spiv> s/was/is/
[09:32] <SteveA> be nice to have some pqm admin controls
[09:32] <SteveA> like, changing the queue order
[09:32] <SteveA> cancelling jobs
[09:32] <sabdfl> or stopping a merge
[09:32] <spiv> SteveA: I'm sure lifeless would say patches accepted ;)
[09:32] <SteveA> once bzr gets more "out there" i'm sure there will be improvements forthcoming
[09:32] <SteveA> schooltool want this stuff
[09:33] <SteveA> they're frustrated with svn and its conception of branches, which isn't so useful in practice
[09:33] <SteveA> the whole distributed concept is good when you have teams across continents
[09:33] <spiv> stub: you can restart postgres, steve's job is done.
[09:33] <spiv> (presumably failed)
[09:33] <SteveA> and, they'd like to have tests run pre-commit
[09:33] <SteveA> yet not hold up development
[09:34] <SteveA> okay
[09:34] <spiv> The asynchrony of pqm is interesting... it's both good and bad.
[09:34] <SteveA> my pqm job has finished
[09:34] <SteveA> and failed
[09:34] <SteveA> i'm moving my archive back
[09:34] <SteveA> postgres should be restarted
[09:35] <stub> I was going to make sure my merge failed too since I think sabdfls superseeds it
[09:35] <spiv> Good thing baz gives you a good 5 or so minute window to break things after it starts a job, because of how long the build-config takes ;)
[09:35] <SteveA> the failure message said that it couldn't merge from my mirror, so i was in time
[09:46] <sabdfl> aiui we're basically on pause till elmo or Znarl can install python-imaging
[09:47] <sabdfl> i still have a key to the DC..
[09:48] <SteveA> sabdfl: you could make it a soft dependency on PIL
[09:49] <SteveA> what are you using PIL for anyway?  hackergotchi?
[09:50] <SteveA> graphs?
[09:53] <sabdfl> SteveA: making sure images meet the size requirements
[09:53] <sabdfl> Znarl is handling the sysadmin stuff, should be done in a sec
[09:54] <SteveA> okay.  PIL isn't actually necesarry for that iirc
[09:54] <SteveA> zope3 has some image sizing code
[09:54] <SteveA> that just looks at the minimum necessary for the main image types
[09:54] <sabdfl> SteveA: i'm happy for you to clean that out then
[09:55] <sabdfl> but right now, i just want it landed so i can start work on other bits
[09:55] <SteveA> okay, sure.
[09:59] <sabdfl> well. i got to fix one bug while we wait
[09:59] <sabdfl> check that it's actually an IMAGE before trying to find its size
[10:00] <SteveA> tested with a .py file? ;-)
[10:02] <sabdfl> SteveA: yes, mailnotification.py as it happens ;-)
[10:02] <sabdfl> fuck. so predictable it must be time for a new girlfriend
[10:03] <SteveA> dude, breezy is blode and brunette *at the same time*
[10:05] <sabdfl> she's a brunette with a cold?
[10:06] <SteveA> wow... just got an email that i'll get my new laptop in the middle of next week
[10:07] <SteveA> i've been missing a laptop.  although, working only in the office has a certain discipline
[10:07] <Znarl> sabdfl : Added python-imaging.
[10:07] <SteveA> Znarl: to which machines?
[10:07] <sabdfl> Znarl: much obliged, thanks
[10:07] <Znarl> macquarie, asuka, gangotri, chinstrap and
[10:07] <sabdfl> confirm chinstrap?
[10:07] <Znarl> ... and mawson.
[10:08] <SteveA> stevea@chinstrap:~$ python
[10:08] <SteveA> Python 2.4.1 (#2, Mar 30 2005, 21:51:10)
[10:08] <SteveA> [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)]  on linux2
[10:08] <SteveA> Type "help", "copyright", "credits" or "license" for more information.
[10:08] <SteveA> >>> import PIL
[10:08] <SteveA> >>>
[10:08] <SteveA> cool
[10:10] <SteveA> i'll mail the launchpad list about the new dependency and update the docs.
[10:10] <sabdfl> thanks stevea
[10:14] <sabdfl> stub: there's a new cronscript, can be daily
[10:14] <sabdfl> comes with my landing
[10:14] <sabdfl> cronscripts/update-cve.py
[10:14] <stub> I'll turn it on staging and see what happens
[10:14] <sabdfl> i don't think there's any point in running it more often than daily, i think the db it fetches is a daily update
[10:33] <lifeless> PIL ?
[10:35] <SteveA> pithon imaging library
[10:35] <SteveA> but speled rite
[10:36] <SteveA> rather than john lydon's band
[10:42] <lifeless> heh
[10:50] <dilys> Merge to rocketfuel@canonical.com/launchpad--production--1.33: Cherry pick patch-2416 into production (patch-1: stuart.bishop@canonical.com, rocketfuel@canonical.com)
[10:58] <SteveA> niemeyer: hi.  had another case, in schooltool this time, of why that list() calls __len__ and swallows all exceptions thing was bad.  This time, it was a __len__ implementation that used list(self) and so got a max recursion error.
[10:58] <SteveA> so, major slowdown, and really hard to track down.
[11:01] <bob2> hah
[11:02] <niemeyer> SteveA: Hey
[11:02] <niemeyer> SteveA: Yes, that's really bad indeed :/
[11:03] <SteveA> at least it's been fixed now
[11:03] <SteveA> i haven't looked at the C code that fixes it
[11:04] <SteveA> but from the schooltool report, i'm pretty sure rhettinger made it catch only specific errors like AttributeError and TypeError
[11:06] <niemeyer> SteveA: 
[11:06] <niemeyer>                 if (!PyErr_ExceptionMatches(PyExc_TypeError)  &&
[11:06] <niemeyer>                     !PyErr_ExceptionMatches(PyExc_AttributeError)) {
[11:06] <niemeyer>                         Py_DECREF(it);
[11:06] <niemeyer>                         return NULL;
[11:06] <niemeyer>                 }
[11:06] <SteveA> great
[11:06] <SteveA> thanks gustavo
[11:07] <sabdfl> lifeless: could you get bzr using LP for bugs, specs, support tickets please?
[11:08] <lifeless> sabdfl: sure thing. I'll ring martin today and ensure one of us will set it up on monday
[11:11] <sabdfl> lifeless: what's PQM doing baz merge --two-way scott@canonical.com--2005/launchpad--manifest-hints-and-ancestry--0 for?
[11:12] <lifeless> sabdfl: because I'm doing last nights merge again ?
[11:12] <sabdfl> do you know that i'm trying to land mark.shuttleworth@canonical.com/launchpad--cverework--1?
[11:13] <sabdfl> before i can get cracking on the work i owe daniel?
[11:13] <lifeless> sabdfl: I didn't, sorry.
[11:13] <sabdfl> ok. could you let me merge drop in please?
[11:13] <lifeless> sabdfl: I'll reenable pqm for a bit. can you tell me when I'm clear to kill it again
[11:13] <sabdfl> sure
[11:13] <lifeless> ok, pqm cron is up again
[11:15] <sabdfl> pqm web site still giving bad gateway, lifeless
[11:15] <lifeless> 1 sec
[11:16] <sabdfl> fixed, thanks
[11:17] <lifeless> np
[11:17] <lifeless> ping me when I'm clear, or if you have trouble
[11:18] <SteveA> sabdfl: just seen the trickery in the TicketTargetView class.  eeewwwww :-)
[11:28] <lifeless> I need a favico.ico for pqm
[11:28] <Keybuk> sw
[11:30] <Keybuk> lifeless: 
[11:30] <lifeless> got that as an ico ?
[11:30] <Keybuk> or is it  ?  can never remember which way it goes
[11:33] <sabdfl> SteveA: i have a note to discuss it in UBZ
[11:33] <SteveA> yeah.  i added some notes to the note on my branch.
[11:33] <sabdfl> we need a general approach to "I want a page with a specific set of criteria against a general list"
[11:33] <sabdfl> at least all the hackery is in one place
[11:34] <SteveA> the standard way to do this in zope3 today is to use a base class TicketTargetView, and some tiny subclasses, each implementing self.getTickets() separately.
[11:34] <SteveA> then register in zcml the appropriate subclass.
[11:35] <sabdfl> that would work too
[11:35] <SteveA> another approach would be to have a way of giving "advice" of some sort from zcml
[11:35] <sabdfl> too limiting
[11:35] <stub> I've got a ruber ducky going cheap
[11:35] <stub> rubber even
[11:35] <SteveA> so you'd say <page .... subsetoftickets="created_tickets" />
[11:35] <sabdfl> you've no sooner implemented all the "advice" zcml, when you need to do something totally different
[11:35] <SteveA> and the view class can read that
[11:36] <sabdfl> i prefer the subclasses
[11:36] <SteveA> it is more pythonic, to be sure
[11:36] <SteveA> to use subclasses
[11:36] <sabdfl> actually, i prefer to have it all in one view class, but we can discuss it at UBZ
[11:36] <SteveA> sure
[11:36] <sabdfl> i don't think looking at the URL is evil
[11:36] <sabdfl> it's just looking at the request, right?
[11:37] <SteveA> well... i've added some notes about looking at the request in a more robust way
[11:37] <sabdfl> the current implementation is simplistic, but i think we can improve that
[11:37] <sabdfl> right
[11:37] <sabdfl> how... long... must... i... wait... for.... the.... failure.... message....
[11:37] <SteveA> but the issue is, if i want to rename a page from say +createdtickets to +ticketscreated
[11:37] <SteveA> i need to do it in two places -- the zcml and the view class
[11:37] <SteveA> whereas, i should be able to do it just in zcml
[11:37] <sabdfl> disagree
[11:38] <SteveA> you disagree that i need to do it in two places?
[11:38] <SteveA> or that i should be able to do it in just zcml?
[11:38] <sabdfl> if you want to rename a field (statusexplanation -> whiteboard) you have to do it in 4 places
[11:39] <SteveA> i don't see that fields are the same as pages.  in general, needing to rename things in N-1 places is better than needing to rename it in N places
[11:39] <SteveA> with one being the absolutely best case
[11:39] <SteveA> also, all other pages in the system can be renamed just in zcml.
[11:40] <SteveA> in zope 3 in the future, you won't list templates in zcml.  they will be included in the view classes anyway.
[11:41] <SteveA> so at that point, you can have one view class
[11:41] <bob2> formlib!
[11:41] <SteveA> with 4 (or however many) methods
[11:41] <SteveA> one for each of the variants of the pages -- as the entry point
[11:41] <SteveA> actually, that would work now also, although be a bit less elegant
[11:41] <SteveA> but it would avoid the "programming complexity" and spready-out-ness of subclasses
[11:42] <SteveA> and achieve the goals of having one view class, an obvious flow of control, and needing to change the page name only in zcml.
[11:43] <sabdfl> i think you could fake this now
[11:43] <sabdfl> if you put a hook in the template
[11:43] <sabdfl> that runs a view method at the beginning of the page
[11:43] <sabdfl> and sets up the iterators appropriately
[11:44] <sabdfl> we need this stuff for:
[11:44] <sabdfl>  - lists of bugs (open, closed, search criteria, show rejected, other options)
[11:44] <sabdfl>  - lists of specs and tickets and branches
[11:44] <sabdfl> lots of places
[11:44] <sabdfl> so we need to develop a pattern, and re-use it
[11:45] <SteveA> can you point me at another view class that needs this stuff?  it will help me see the pattern
[11:46] <SteveA> this hook you speak of is something i'm on the hook to do for upstream zope3 sometime.  haven't got around to it yet.  it also fixes the "don't do stuff in __init__" issues.
[11:46] <SteveA> in fact, i wrote in the comment:
[11:46] <SteveA>             #   Either wait for the Zope 3 improvement I'm on the hook to
[11:46] <SteveA>             #   land that makes templates called "template" in view classes,
[11:46] <SteveA>             #   or include it manually like Zope 3 will do in the future.
[11:46] <SteveA>             #   Then, have different methods as entry-points for the different
[11:46] <SteveA>             #   pages.
[11:46] <SteveA>             #     self.createdtickets()
[11:46] <SteveA>             #     self.assignedtickets()
[11:47] <SteveA>             #     self.answeredtickets()
[11:47] <SteveA>             #     self.subscribedtickets()
[11:47] <SteveA>             #     self.tickets()  # everything else.
[11:47] <SteveA>             #   Hook these up in zcml.
[11:47] <SteveA>             #   using the class and attribute style of registing pages.
[11:48] <sabdfl> SteveA: the bug search stuff is a bit of a mess, so don't look there for inspiration
[11:48] <SteveA> okay.
[11:48] <sabdfl> but imagine all the places where you want to slice a set of data up 20 different ways
[11:49] <SteveA> yeah
[11:49] <SteveA> okay.  i'll leave the comment there for now, and mull it over the weekend
[11:49] <sabdfl> SteveA: i have often used 1 view class with different templates, so don't make the binding at a view class level please
[11:50] <SteveA> there's nothing in this that would stop that from working
[11:50] <SteveA> the upstream change is that when you have 'template="..."' in zcml, the template ends up in a standard attribute name 'template'
[11:51] <SteveA> you can use one view class with many template="..." directives, because a new class is generated for each use.
[11:51] <SteveA> it has to be that way to work currently.
[11:52] <SteveA> one of the reasons to deprecate template="..." in zcml, and make the standard way to do things to explicitly name templates in the view classes
[11:52] <SteveA> is to get rid of the "let's generate classes" stuff
[11:52] <SteveA> beacuse it makes the system more obscure if zcml is going around generating classes for you
[11:52] <sabdfl> ah. +1 on that front, then
[11:53] <SteveA> i mean, it's cute... but in a "i want a rifle for bambi" way
[11:54] <sabdfl> srichter?
[11:54] <SteveA> nah, this was in zope3 from the very earliest time
[11:55] <SteveA> the motivation at the very start was to make it the minimum lines of code to write a page template, and some in-python-code logic to help it do its job 
[11:55] <SteveA> because many people wanted the same power as having islands of python code in page templates
[11:55] <SteveA> but others wanted the python code to be testable, and to look like regular python code
[11:55] <SteveA> out of that came the view class + template idiom
[11:56] <SteveA> and the desire to avoid the boilerplate that is so common in zope 2
[11:57] <SteveA> so, generating classes was one way to avoid the boilerplate of using python code to explicitly include a page template, and to avoid the need to say def __init__(self, context, request): self.context = context; self.request = request
[11:57] <SteveA> it achieved the goal of avoiding boilerplate and making it easy to add bits of python code to templates, but at the cost of making the whole "views" system obscure when it didn't need to be so.
[11:58] <SteveA> now it is time to undo that, and make things less magical.
[12:01] <sabdfl> so, will the boilerplate become required?
[12:01] <SteveA> you'll need to provide an __init__ for your view classes, or subclass something that provides a suitable __init__
[12:02] <SteveA> so, in launchpad, we'd end up subclassing LaunchpadView all the time, i expect
[12:02] <SteveA> which is nice and self-documenting anyway
[12:02] <SteveA> class TicketTrackerView(LaunchpadView):
[12:02] <SteveA>  ...
[12:03] <SteveA> so, no particular boilerplate
[12:03] <SteveA> but still understandable -- you look up what LaunchpadView is if you want to see its __init__
[12:03] <SteveA> rather than have to look in the dark corners of zcml implementation
[12:05] <SteveA> stub: did you ever track down the issues with sending mail async in production?
[12:06] <stub> I have not looked - it may well work if I turn it back on.
[12:06] <SteveA> did it fail on staging also?
[12:06] <SteveA> it would be nice to be able to test it on staging first.
[12:07] <stub> Staging doesn't send email yet, so that needs to be sorted first
[12:07] <SteveA> i think sending it all to some list would be nice
[12:07] <SteveA> then people can look at the list to see what staging is sending out
[12:14] <Kinnison> If anyone here wants me to retain the contents of the dogfood database (soyuz tables in particular) speak now, or forever hold your peace
[12:18] <Keybuk> one hopes people will be holding their piece in private
[12:18] <Kinnison> wude.
[12:21] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=jamesh]  rework cve structure, and general polish (patch-2420: mark.shuttleworth@canonical.com, bjorn.tillenius@canonical.com)
[12:22] <bob2> filthmongers!
[12:23] <Kinnison> gah, talk about confusion
[12:23] <Kinnison> I got an arch-pqm success message from *MY* pqm, sat next to a change-to-rocketfuel tla mail-revisions mail
[12:23] <Kinnison> my brain froze for about 10 seconds due to the cognitive dissonance
[12:24] <ddaa> SteveA: okay, I'm looking at the pybaz problem right now.
[12:24] <SteveA> thanks ddaa 
[12:27] <SteveA> stub: when you update the request type in servers.py, you also need to update it in canonical/functional.py
[12:28] <sabdfl> lifeless: k, i'm done. phew. thanks
[12:28] <stub> There a mock request in there or something? ok.
[12:28] <sabdfl> jamesh: please grill me about those extra review points (schemas vs interfaces) in UBZ, ok?
[12:29] <sabdfl> stub: did that branch land ok on your production branch, too?
[12:29] <lifeless> sabdfl: thanks
[12:29] <lifeless> pqm -> down
[12:29] <stub> its in pqm. If it doesn't land, is it ok to cherry pick that one instead?
[12:30] <lifeless> stub: your merge will complete
[12:30] <lifeless> then I'm locking the queue to fight this hct patch
[12:30] <sabdfl> stub: 2420? yes. though it might include a little more rocketfuel than the previous one. there's one little extra fix too, but not critical
[12:31] <stub> ok.
[12:33] <SteveA> sabdfl: when do you leave today?  bjorn's working on a ticket tracker email interface braindump for you to look at? 
[12:34] <SteveA> stub: actually, i see you changed servers.py already.
[12:35] <SteveA> stub: i'll update functional.py because i'm making an improvement there anyway.
[12:35] <sabdfl> SteveA: 6pm uk time
[12:36] <SteveA> stub: ... or did you.  i'm getting confused between Publication and Requests :-/
[12:36] <SteveA> thanks sabdfl 
[01:00] <lifeless> yay
[01:03] <SteveA> lifeless: if i have some changes i've made but not committed on the wrong branch, can i baz switch, baz branch, baz commit?
[01:05] <lifeless> yes
[01:05] <SteveA> great
[01:08] <lifeless> stu	ping
[01:08] <lifeless> doh
[01:08] <lifeless> I wanted stub
[01:18] <lifeless> spiv: meet niemeyer 
[01:18] <lifeless> niemeyer: meet spiv
[01:18] <niemeyer> :)
[01:18] <niemeyer> spiv: Hello :)
[01:18] <lifeless> spiv: niemeyer might like to learn some more about twisted, to get a feel for what writing good twisted code is like
[01:19] <niemeyer> "good twisted code" 8)
[01:20] <spiv> How to freeze Python in a futex beyond the reach of Ctrl-C in one easy step: python -c "from threading import Event; Event().wait()"
[01:21] <bob2> I guess I have only myself to blame for that terminal being fucked now
[01:21] <spiv> niemeyer: G'day
[01:21] <SteveA> spiv: normal kill killed it
[01:21] <Keybuk> bob2: How to freeze your system by making it do lots of disk I/O: sudo rm -rf /
[01:21] <lifeless> ...
[01:22] <bob2> Keybuk: monkey boy.
[01:22] <Keybuk> bob2: get a haircut.
[01:22] <spiv> SteveA: Yeah, so does Ctrl-\  (SIGQUIT).
[01:22] <spiv> Still surprised me.
[01:36] <Keybuk> Kinnison: found another amusing point where my Cymraeg slips out for you ... I pronounce the C type "char" with a hard ch, and not a soft one
[01:56] <BjornT> sabdfl: could you have a quick look at https://wiki.launchpad.canonical.com/TicketTrackerEmailInterface
[01:56] <BjornT> sabdfl: i will improve it later after lunch
[01:58] <sabdfl> BjornT: i'll make some tweaks while you are out
[02:40] <mpt> agh, I thought I'd be smart and leave baz merge running overnight
[02:40] <mpt> but it ran out of memory
[02:41] <Nafallo> hehe
[02:41] <Nafallo> :-)
[02:41] <mpt> Serves me right for having only 1 GB
[03:14] <ddaa> mpt: I have only 1GB too
[03:14] <ddaa> and baz never runs out of mem here...
[03:15] <ddaa> but tend to use --star-merge...
[03:17] <kiko> ddaa, but you have swap
[03:17] <ddaa> Oh yes
[03:17] <kiko> and mpt in particular uses gnome with two browsers, gaim, etc
[03:17] <kiko> so there's only about 600-700mb for baz
[03:17] <ddaa> 953MB of swap
[03:18] <ddaa> and I'm using gnome, with firefox, evolution, gaim, emacs, etc.
[03:19] <ddaa> I'm not sure exactly what is the root cause of the problem, but I found that when resident usage gets too high, I can free much ram by switching with R&R to 800x600 then back to 1600x1200
[03:20] <ddaa> quitting evolution and firefox from time to time (about once a week) also helps.
[03:32] <sabdfl> BjornT: comments submitted
[03:41] <mpt> ddaa: Does /products/foo/+branches show branches for any products yet? (it seems to be empty on the ones I try, though I don't know if that's just because the products aren't using it)
[03:41] <mpt> oh, nm, the file does nothing
[03:42] <ddaa> not yet, the work we did on that during the sprint is blocked by a couple of big-urgent-really-I-mean-urgent tasks.
[03:42] <mpt> ok
[03:42] <ddaa> that is, samba import and fixing importd so the BranchDataStorage db schema changes won't break RCS imports.
[03:43] <Lathiat> Just wanted to stop by and say that malone is looking pretty rocking :)
[03:45] <Kinnison> Keybuk: aye, I know you do. We argued back and forth about the pronounciation of 'char' a few weeks ago IIRC at the BBQ
[03:46] <bradb> Lathiat: glad to hear. feedback is always welcome.
[03:46] <Lathiat> its quite nice having things like cve references, separate tracking for hoary+breezy in the same bug etc
[03:47] <mpt> Kinnison: Depends whether you're talking about characters or about the BBQ :-)
[03:47] <Kinnison> mpt: I always pronounce it with a soft ch
[03:47] <kiko> Lathiat, thanks, we appreciate the feedback -- hard work it is
[03:48] <Lathiat> im sure :) 
[03:49] <Lathiat> 1 question, can i bring up a more advanced bug search page?
[03:49] <Lathiat> e.g. new and assigned to MOTU
[03:50] <mpt> Lathiat: No, but if you go to https://launchpad.net/people/motu/+assignedbugs and click the "Status" column header twice, all the New bugs will be listed first
[03:51] <Lathiat> mpt: ok, will that be added in future?
[03:51] <bradb> Lathiat: fwiw, novemberish is when we'll be diving into making searching in Malone rock.
[03:51] <Lathiat> bradb: ok cool
[03:51] <kiko> Lathiat, you can click on the (Advanced) button, does that help?
[03:51] <Keybuk> Kinnison: ah, it was you I was arguing with then :p
[03:52] <Lathiat> hmm, when sorting by "severity" it should probably sort by severity type rather than alphabetically :)
[03:52] <bradb> Lathiat: i'll file a bug on that, thanks
[03:54] <Lathiat> bradb: cool
[03:58] <bradb> Lathiat: filed #2347 and subscribed you as well
[03:58] <Lathiat> br	cheers
[03:58] <Lathiat> bradb: 
[03:59] <mpt> kiko, what's the shipit admin page url?
[03:59] <kiko> mpt, it's only available to shipit admins
[03:59] <kiko> what should I do?
[03:59] <mpt> I mean, on localhost :-)
[04:00] <mpt> oh, I don't know who's the admin in the sampledata anyway
[04:01] <mpt> oh yes I do
[04:01] <mpt> Ok, I'll shut up now
[04:01] <ctrlsoft> hi
[04:01] <ctrlsoft> Anyway to merge two user accounts?
[04:02] <Kinnison> lifeless: any word on the HCT branches? Have you locked PQM or is it all still running?
[04:02] <lifeless> Kinnison: pqm is still getting its knickers cleaned
[04:03] <Kinnison> mmm laundry day
[04:07] <kiko> mpt :)
[04:09] <SteveA> hi mpt 
[04:09] <bradb> no pqm still eh? hrmph.
[04:11] <Lathiat> pqm?
[04:12] <SteveA> Lathiat: just a sec, i'll get you a description
[04:12] <SteveA> http://mail.python.org/pipermail/python-dev/2005-August/055376.html
[04:12] <SteveA> it's a bit long, but explains about pqm
[04:13] <Lathiat> thanks
[04:14] <bradb> Lathiat: you don't wanna know :)
[04:15] <kiko> good man bradb 
[04:17] <zyga> hello
[04:18] <Lathiat> SteveA: good read, thanks
[04:22] <ddaa> lifeless: [samba]  just put up something that I think might actually be correct. Would you have the time to review it today?
[04:23] <ddaa> (not tested yet, though)
[04:23] <lifeless> ddaa: sure. is there a diff yet ?
[04:24] <ddaa> I'll send you the branch name as soon as it's gone through the test suite and committed.
[04:26] <mpt> hi SteveA
[04:26] <lifeless> ddaa: would like a diff please
[04:26] <ddaa> ok
[04:29] <mdke> jordi, around?
[04:33] <ddaa> lifeless: diff in the pipe
[04:34] <bradb> BjornT: hi. any news on the URL changes review?
[04:35] <Kinnison> Okay, since noone has complained, I'm going to blat at the dogfood DB for a while. dogfood will be offline for the duration.
[04:36] <elmo> stuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuub
[04:37] <BjornT> bradb: well, i've come a long way,  but i postponed it temporarily, since i wanted to create a braindump of the ticket tracker email system for mark to look at
[04:38] <BjornT> bradb: it's not impossible that i still finish the review today, though
[04:38] <bradb> BjornT: ok, I understand that it's a big review, and not the easiest one to do at that. good to hear that it's coming along. thanks.
[04:38] <kiko> Keybuk, it wouldn't help in this case, though.
[04:41] <Lathiat> if i want to mark something as rejected in warty,hoary and leave it as new in breezy, would i first "request a fix in a distro" so that item is created and then change its status?
[04:41] <Kinnison> elmo: When does mawson's copy of the archive get updated?
[04:42] <elmo> 4am
[04:42] <kiko> Lathiat, right.
[04:42] <Kinnison> elmo: is that when it starts, or when it finishes?
[04:42] <elmo> starts
[04:42] <bradb> Lathiat: are there already warty and hoary tasks?
[04:43] <Kinnison> elmo: cool, so 6am will do for starting the import from it
[04:43] <Kinnison> thanks
[04:43] <elmo> Kinnison: easily eyah
[04:43] <Kinnison> coolio.
[04:43] <bradb> Lathiat: or, in human terms, i should have ask that as "is the bug already reported in warty and hoary?"
[04:44] <lifeless> please merge, kthnxbye
[04:44] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: r=bjornt merge support for hints and ancestry of manifests. (patch-2421: scott@canonical.com)
[04:44] <Kinnison> lifeless: I.E. you're ready for PQM to be used again?
[04:44] <dilys> Merge to rocketfuel@canonical.com/hct--devel--1: magic marker upgrade from scotts hct branch (patch-20: scott@canonical.com)
[04:44] <dilys> Merge to rocketfuel@canonical.com/sourcerer--devel--0: magic marker upgrade from scotts sourcerer branch (patch-30: scott@canonical.com)
[04:44] <Lathiat> hrm i cant see a disctinction between distro versions 
[04:44] <Lathiat> yet i see it on lots on bugs
[04:45] <bradb> Lathiat: URL?
[04:45] <Lathiat> https://launchpad.net/malone/bugs/2057
[04:45] <bradb> Lathiat: so, does bug #2057 appear to you to be filed in warty and hoary?
[04:46] <Lathiat> bradb: just "Ubuntu", i want to split out the status to say rejected for warty and hoary, but leave breezy as new
[04:46] <Lathiat> how would i do that?
[04:46] <Lathiat> (is that a sane thing to do?)
[04:46] <bradb> Lathiat: ok, so, you want to target the fix to those releases and then reject the tasks
[04:46] <Lathiat> ohh i see 
[04:47] <kiko> https://launchpad.net/distros/ubuntu/+bugs/2057/+target
[04:47] <bradb> mpt: If i were allowed to make the actions menu useful, you sure would.
[04:47] <kiko> mpt, you can't (at least currently)
[04:47] <Lathiat> mpt: "Request fix: ... in distribution"
[04:47] <mpt> Lathiat: That's what I thought too
[04:48] <Lathiat> and then theres "target release"
[04:48] <mpt> ah, "Target Fix to Releases"
[04:48] <bradb> mpt: I'd put that on the bug page, so you'd have noticed it, but I'm not allowed to do that.
[04:48] <bradb> Same with Edit Assignee/Status Details
[04:50] <bradb> At the moment, assigning a bug is not only hard to discover, it's practically an easter egg.
[04:51] <BjornT> lifeless: can you please add a malone section to the production config? (just copy the section from the default config)
[04:52] <lifeless> BjornT: ?
[04:52] <ddaa> rubber duck egg
[04:53] <mpt> bradb: bah, who needs to assign bugs anyway :-)
[04:53] <bradb> BjornT: There already is a malone config section, no?
[04:53] <BjornT> lifeless: sorry, by config i mean launchpad.conf file
[04:53] <bradb> BjornT: At least, it's being used by the bugmail error sending code
[04:53] <BjornT> bradb: doesn't seem like it
[04:53] <BjornT>     return config.malone.bugmail_error_from_address
[04:53] <BjornT> AttributeError: 'NoneType' object has no attribute 'bugmail_error_from_address'
[04:54] <bradb> BjornT: ah, ok, i thought that's what might have tipped you off to asking for it to be added to the config file :)
[04:56] <bradb> Lathiat: btw, you might not actually need to target-then-reject
[04:58] <Lathiat> bradb: oh?
[04:58] <bradb> Lathiat: by default, an "Ubuntu" bug means that it should be "fixed in the current (development) release". to signal a backport fix request, you use the "Target Fix to Releases" page
[04:58] <Lathiat> bradb: oh ok
[04:59] <bradb> we'll have to think a bit about how to make clearer what a bug filed on "Ubuntu acroread" actually means, perhaps
[05:00] <Lathiat> bradb: altho in this case, the reporter mentioned it was vulnerable in all three
[05:00] <Lathiat> bradb: (but didnt manually click the other two
[05:00] <Lathiat> bradb: also having breezy + "ubuntu" is confusing
[05:00] <Lathiat> and also annoying
[05:01] <Lathiat> however thats not the easiest thing in the world to "transition" when we release, yo udont really want to just mark all bugs as "breezy" at release 
[05:02] <bradb> Lathiat: do you mean that it's confusing to have the bug reported on both "Ubuntu" and on "Ubuntu Breezy"?
[05:02] <Lathiat> bradb: well that too
[05:02] <lifeless> BjornT: done
[05:02] <bradb> Lathiat: i agree, it's confusing
[05:02] <lifeless> I think there is a general issue.
[05:03] <bradb> Lathiat: what did you mean by 'also having breezy + "ubuntu" is confusing', exactly?
[05:03] <BjornT> lifeless: thanks
[05:03] <lifeless> when we have sane defaults, why do we not have a default value if they are not present ?
[05:03] <lifeless> we've had this sort of fuckage before
[05:03] <Keybuk> . o O { why are Bugs on Product and not ProductSeries }
[05:04] <Lathiat> bradb: i meant by that exactly what you just said
[05:04] <kiko> Keybuk, they will be. mpt, why are you waiting to land deactionizing?
[05:04] <kiko> Keybuk, they will be targettable to series, actually.
[05:04] <kiko> lifeless?
[05:04] <kiko> ah, right
[05:04] <bradb> Keybuk: from the backend implementation details, that's an easy one to explain. from a UI perspective, the difference between product vs. product series reports is communicated poorly, it would seem
[05:04] <kiko> thanks BjornT, I was getting spammed like crazy.
[05:05] <mpt> kiko: I've been trying to land it for the past half hour, I'm not waiting :-)
[05:05] <kiko> wow
[05:05] <bradb> Lathiat: ok
[05:05] <Keybuk> bradb: yes, it would be a first for Malone to be really confusing ui wouldn't it O:-)
[05:05] <Lathiat> im impressed how well its doing now, some of the stuff is rather difficult to expose
[05:06] <BjornT> lifeless: would that have helped, though? the value was required, but since the section didn't exist, there was no error. no section, no default value. the malone section could get merged into the launchpad one, though.
[05:06] <Keybuk> WHY CAN'T I FIX THE BUG FROM THE SCREEN WITH ALL THE COMMENTS ON IT, AND WHY CAN'T I VIEW OTHER BUGS IN THE SAME THING FROM THE SAME SCREEN. GNARGH!
[05:06] <bradb> Keybuk: Malone's UI is confusing, but improving.
[05:06] <mpt> Keybuk: +1
[05:07] <lifeless> BjornT: having a default and making the rest optional would definately fix it
[05:07] <bradb> Keybuk: I added a link to allow you do the latter in my URL changes branch (currently being reviewed by bjornt), and haven't yet removed it, but I think sabdfl may want me to, when he sees it.
[05:07] <Keybuk> right now the work flow looks like:
[05:08] <bradb> Keybuk: I also added a link to the bug page to at least make it easy to get to the *screen* where you can "Fix" the bug, but sabdfl told me to get rid of that too, so I did.
[05:08] <test> @find pdf
[05:09] <Keybuk> 1) find bug, 2) read bug, 3) hunt randomly and scream until some helpful person points at the "upstream <product>" link which oh-so-unobviously takes you to the right screen, 4) fix the bug, 5) go back to the task page, 6) add a comment, 7) go back to the bug page, 8) click "other bugs in <product>"
[05:09] <BjornT> lifeless: but in this case a default value wouldn't have helped, since the section didn't exist. i wonder if it's possible to make a section required...
[05:10] <bradb> Keybuk: we want what you want, dude. "upstream <product>" is, practically speaking, *impossible* to figure out to be the place where one goes to fix the bug.
[05:10] <lifeless> BjornT: garh. MAKE THE SECTION OPTIONAL.
[05:11] <bradb> Keybuk: people hate this. people repeatedly complain about it. people should complain about it. i fixed the problem. i had to unfix it yesterday. :/
[05:13] <kiko> Keybuk, like a broken arm, you get used to it after six months
[05:13] <mpt> Keybuk: step (3) didn't used to be necessary, but that was reversed a few months ago too
[05:13] <BjornT> lifeless: if you tell me how to do it in the config system, sure.
[05:14] <lifeless> BjornT: I wasn't saying *you* should do it, rather that *we* have a general issue
[05:14] <BjornT> lifeless: ah, that is true :)
[05:15] <kiko> lifeless, BjornT: the other option is making a mandatory test that validates the config file...
[05:15] <lifeless> kiko: wouldn't help
[05:15] <bradb> fwiw, i added that config option to malone
[05:15] <kiko> lifeless? how now?
[05:15] <bradb> i expected that adding a new config option would Just Work
[05:15] <lifeless> kiko: unless you meanaas a startup-of-launchpad thing
[05:15] <Keybuk> kiko: no, you don't
[05:15] <lifeless> kiko: tests are not run on the production *servers*
[05:16] <Keybuk> kiko: people don't hang around 6 months to get used to a bug tracking system
[05:16] <Keybuk> they take 15 seconds to install bugzilla, which they know
[05:16] <lifeless> bradb: you *HAVE* to tell stub and I about new config entries.
[05:16] <Kinnison> 19697 postgres  25   0  110m  97m  86m R 98.5  2.7  11:40.43 postmaster
[05:16] <Kinnison> yay for postgres
[05:16] <dilys> Merge to rocketfuel@canonical.com/pybaz--devel--0: [trivial]  disable OrderedTestLoader (patch-40: ddaa@ddaa.net)
[05:16] <kiko> lifeless, perhaps an email to launchpad and a poke in the eye to reviewers?
[05:16] <kiko> sladen, https://launchpad.net/malone/bugs/2249
[05:16] <BjornT> kiko: there is some validation done when the config is parsed, but it seems that no sections are required, so it doesn't complain if one section is missing
[05:16] <kiko> right
[05:17] <kiko> that's what I meant
[05:17] <bradb> lifeless: right, sorry, i will next time i make a change
[05:17] <BjornT> there should be some way of making it required
[05:17] <kiko> yeah, agreed -- the instance should bomb out if missing
[05:18] <lifeless> kiko: either vaidation during startup or an email to lp + a poke to stub and I
[05:18] <kiko> lifeless, I meant poking launchpad to say "If you add config sections, tell me or kiko will kill you" and then poking reviewers to watch out for it
[05:19] <lifeless> kiko: heh
[05:26] <mpt> Keybuk: BoF it for UBZ
[05:27] <Keybuk> mpt: no, I want to live
[05:30] <cprov> ********************************************************
[05:30] <cprov> *  51 conflicted items in this tree. Please            *
[05:30] <cprov> * resolve each conflict with "baz resolved 'filename'" *
[05:30] <cprov> ********************************************************
[05:30] <bradb> cprov: those can't be all real (...can they?)
[05:31] <cprov> bradb: even if they are duplicated code, no way to recover the tree, will try with --star-merge 
[05:32] <dilys> Merge to rocketfuel@canonical.com/cscvs--devel--1.0: [trivial]  remove uses of pybaz OrderedTestLoader (patch-110: david.allouche@canonical.com)
[05:32] <ddaa> I think experience shows that mesh-merge does not work satisfactorily, it's really worth the trouble to try avoiding situation that cannot be handled with star-merge and diff3...
[05:36] <bradb> I always use --star-merge these days.
[05:37] <ddaa> I mean something a bit different: avoiding workflow and merge topologies that cannot be handled with star-merge.
[05:39] <cprov> bradb: yeah, i suspect this is the problem, once you rely on --star-merge you can't go back to simple merge 
[05:39] <ddaa> cprov?
[05:41] <cprov> ddaa: sorry ?
[05:41] <Kinnison> cprov: If you're having problems even with star-merge, let me know and I'll have a look
[05:41] <ddaa> You seem to imply that star-merge supercedes mesh-merge, but it's (supposedly) the other way around.
[05:42] <ddaa> star-merge is more limited (and more predictible) and forces you to be more disciplined, which does not prevent using mesh-merge.
[05:42] <cprov> Kinnison: not really star-merge works, but still resulting in wierd failures on merge
[05:43] <Kinnison> Never use mesh merge with launchpad
[05:43] <Kinnison> it's too risky
[05:43] <ddaa> cprov: yup, but when you know the limitation it's often possible to avoid them.
[05:43] <BjornT> lifeless: btw. you don't happen to know where i can find a version of libgetopt++, that can be used to compile config-manager with?
[05:43] <Kinnison> (IME)
[05:49] <lifeless> BjornT: apt-get source config-manager
[05:49] <lifeless> BjornT: or from my barch archive
[05:50] <SteveA> mpt: ping
[05:52] <mpt> SteveA: pong
[05:52] <sabdfl> Kinnison: ping
[05:52] <SteveA> mpt: i want a  div traceback  style to use that puts the text in a smallish monospaced font, and makes the block of traceback distinct from the rest of a standard launchpad page
[05:52] <SteveA> this is to improve the debug views on errors
[05:54] <sabdfl> SteveA: class="highlight" or class="highlighted" will give you boxed, slightly coloured background
[05:54] <sabdfl> you could add the font style, and size, directly
[05:54] <mpt> SteveA: Does it have its own <div>s?
[05:54] <SteveA> yes, it is in a <div class="traceback">
[05:54] <mpt> SteveA: I mean for individual lines
[05:54] <SteveA> i can alter the class etc.
[05:54] <mpt> or is it expecting a <pre>
[05:55] <SteveA> oh, it's got a <ul> with a <li> for each line
[05:55] <BjornT> lifeless: thanks, compiled fine now
[05:55] <SteveA> all inside a <p>
[05:55] <sabdfl> BjornT: see those comments?
[05:56] <SteveA> so, <div class="traceback"><p>some text here <ul><li>line1</li><li>line2</li></ul>more text</p></div>
[05:56] <mpt> SteveA: You're allowed <p> inside <li>, but you're not allowed <ul> inside <p> (yet)
[05:56] <sabdfl> main thing is the closing procedure (not just a simple set-to-closed), and then that i don't think we should allow opening tickets by mail yet, or that we should have a better system than "affects /foo/bar" if we do
[05:56] <SteveA> mpt: i don't have control over that part of the rendering
[05:56] <mpt> SteveA: ok, so if this isn't going to be used anywhere else, <div class="highlight" style="font-family: monospace; font-size: smaller;">
[05:57] <SteveA> end users will never see this.  this is for developers
[05:57] <SteveA> ok
[05:57] <BjornT> sabdfl: yes. i'll adjust how the status command should work, and will remove creation of tickets. i agree that it's probably not worth creating new tickets via email.
[05:58] <Lathiat> another thing thats a little confusing is that the tabs in the top right stay the same but they change meaning through different contexts, a good idea in theory but it can be a little confusing and not easy way to get back to the main "bugs" page or whatever
[05:59] <SteveA> mpt: ah -- class="highlighted"
[05:59] <BjornT> sabdfl: i played around using only the person who created the ticket, so i didn't notice the answered state. i'll make sure that the email system will have the same semantics as the web ui
[05:59] <bradb> Lathiat: Can you give an example of what the unexpected behaviour was that you experienced, WRT the tabs?
[05:59] <bradb> I think I know what you're referring to, but I want to be sure.
[05:59] <mpt> SteveA: right, sorry (I haven't used that yet myself)
[06:00] <Lathiat> bradb: so i goto launchpad.net
[06:00] <Lathiat> bradb: and i click bugs, and see things about bugs
[06:00] <Lathiat> bradb: i then login, and i click on my name and look at my profile
[06:00] <Lathiat> bradb: i think hit bugs, which looks exactly the same
[06:00] <Lathiat> bradb: and it takes me to my personal bugs page instead
[06:01] <Lathiat> and the only way to get back is the breadcrumb in the top left
[06:01] <Lathiat> nifty, but a little confusing
[06:01] <Lathiat> they should at least change colour or something to indicate they are in a different context, and perhaps a button next to the tabs which takes you back up to the top level rather than just the link up in the top left
[06:01] <mpt> Lathiat: yes, we don't do a good job of showing that "the tabs belong to this thing" at the moment
[06:01] <ddaa> lifeless: can you review the patch?
[06:02] <mpt> Lathiat: It used to be better, but not *much* better
[06:02] <ddaa> it seems to be working well with ubuntu-doc, but it's going so slowly that I do not expect that test to complete before I have to leave.
[06:03] <bradb> mpt: Is there currently a plan for what to do about that? (i.e. how to show to what thing the tabs belong?)
[06:03] <mpt> Lathiat: The hierarchy should be better explained when https://wiki.launchpad.canonical.com/LaunchpadHierarchyNavigation, and changing color is part of https://wiki.launchpad.canonical.com/LaunchpadBranding
[06:03] <bradb> heh
[06:03] <mpt> when https://wiki.launchpad.canonical.com/LaunchpadHierarchyNavigation is implemented, I mean
[06:03] <Lathiat> also 
[06:03] <Lathiat> for new packages going into breezy
[06:03] <Lathiat> how do i get them into launchpad
[06:04] <Lathiat> (in my case im upstream, so im interested in a component, and having them assigned to me)
[06:04] <mpt> Lathiat: That should happen automatically, but currently isn't afaik
[06:04] <mpt> anyway, time for me to go to class
[06:05] <Lathiat> "There are currently 1024 products registered in launchpad"
[06:05] <mpt> yes, it's counted from the database
[06:06] <mpt> I implemented that :-)
[06:09] <Kinnison> sabdfl: pong
[06:09] <Kinnison> sabdfl: sorry, was helping cut laminate flooring
[06:10] <bradb> sabdfl: https://launchpad.net/malone/bugs/2353 -- the Specifications tab raises a 404 off the main page.
[06:10] <sabdfl> Kinnison: i'm afraid i'm going to fail to deliver this soyuz rework this evening
[06:10] <sabdfl> it will be done by the time i get back from SA, but that's 2+ weeks from now
[06:11] <sabdfl> i think it only really affects the web UI at this point
[06:11] <Kinnison> sabdfl: right
[06:11] <Kinnison> sabdfl: Don't sweat it too much
[06:11] <sabdfl> bradb: please fix it, i'm packing
[06:11] <bradb> sabdfl: ok
[06:11] <SteveA> bradb: that's supposed to be fixed in production, and in RF
[06:12] <bradb> It's not fixed in production, at least
[06:12] <SteveA> bradb: i'll sort out the spec tab problem -- it's a zcml registration / menus system problem
[06:12] <bradb> ok
[06:12] <SteveA> then the fix was lost
[06:12] <SteveA> it was fixed there before the last update
[06:12] <sabdfl> bradb: it's fixed in staging
[06:12] <SteveA> okay, i'll sort it with stu
[06:12] <sabdfl> Kinnison: anyhow, i;m sorry
[06:13] <Kinnison> sabdfl: Just make sure you don't guilt yourself into doing it instead of relaxing on your holiday
[06:14] <SteveA> bradb: what is /malone/bugs/ supposed to do?
[06:14] <sabdfl> Kinnison: ask no questions, i'll tell ya no lies...
[06:14] <SteveA> bradb: is it supposed to redirect to /malone ?
[06:17] <SteveA> what's another user that works in the sample data other than foo.bar@canonical.com ?
[06:29] <bradb> SteveA: redirect, yeah
[06:29] <SteveA> bradb: thanks.  i was just debugging a problem with infinite redirect recursion on logging out, and was confused by the additional redirect
[06:31] <sabdfl> SteveA: see pagetests/README.txt near the bttom
[06:32] <bradb> SteveA: I'm going to make IBug.id, IBug.private and IBugTask.id always publicly accessible today, btw.
[06:32] <bradb> SteveA: oh, and IBugTask.bug, perhaps?
[06:33] <SteveA> sabdfl: thanks.  i actually wanted to log in interactively, but found a bunch of users clearly marked in the sampledata
[06:33] <SteveA> bradb: the 'id' attributes, sure.  'private', sure, because it makes sense to be able to check if it is private without raising an error
[06:34] <SteveA> IBugTask.bug, sure, because you should always be able to go to a less-specific thing, and get that thing's id
[06:34] <bradb> and be able to do IBugTask.bug.private, etc.
[06:35] <SteveA> now, this is very odd
[06:35] <SteveA> the code for production on gangotri actually has the correct link on the front page for the specs facet
[06:37] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  hide dups from the assigned bugs report; improve the wording and pagetest (patch-2422: brad.bollenbach@canonical.com)
[06:37] <SteveA> lifeless: got a sec?
[06:40] <lifeless> shoot
[06:41] <SteveA> lifeless: so, there's a problem in production.  that is, on the front page, the link on the specs facet goes to '+specs' not 'specs'
[06:41] <SteveA> i have looked on gangotri at the code that ought to be responsible for this.  it is correct, and the link is to 'specs'.  i asked stu to change this code a few days ago, and he did.
[06:42] <SteveA> so, either, i'm totally wrong about what code to change, or launchpad on production has not been restarted since stu made the change.
[06:42] <lifeless> its been restarted
[06:42] <lifeless> twice today
[06:43] <SteveA> okay
[06:43] <SteveA> it is under revision control.  i'll get the tree, and check it out locally
[06:43] <SteveA> ta
[06:44] <lifeless> ddlooks like it might work
[06:44] <lifeless> bah, hes gone
[06:46] <jordi> mdke: here
[06:47] <SteveA> haha, you can tell what pagetests stu wrote
[06:47] <SteveA>   ... Accept-Language: en-au,en-gb;q=0.7,en;q=0.3
[06:49] <sabdfl> cheers guys
[06:49] <sabdfl> lifeless: great work this sprint
[06:49] <sabdfl> thanks
[06:50] <sabdfl> niemeyer: you're off to an excellent start
[07:07] <Kinnison> 19697 postgres  25   0  110m  97m  86m R 99.9  2.7 121:18.99 postmaster
[07:07] <Kinnison> FFS
[07:07] <Kinnison> two hours it has been deleting rows
[07:07] <Kinnison> two sodding hours
[07:14] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=kiko for most, trivial for the rest]  Major cleanup of portlets, minor cleanup of Codes of Conduct and ShipIt; fixes bug 1968 and bug 2103 (patch-2423: mpt@canonical.com)
[07:15] <kiko> finally
[07:32] <mdke> jordi, we have a string called "translator-credits" that should be completed automatically, rosetta doesn't do it (known bug), do you have any advice to work around it?
[07:33] <jordi> mdke: completed automatically how?
[07:34] <mdke> jordi, by inserting the names and emails of the translators who worked on the po
[07:34] <mdke> jordi, bug 116
[07:34] <jordi> oh, right
[07:34] <jordi> no, other than filling it by hand, no other ideas.
[07:37] <mdke> k
[07:41] <mdke> jordi, the other was, some translators have been complaining about having to translate the licences which are in our template because of the use of -e. I mailed danilo asking if there is any way he knows of to exclude such entities but had no response yet, you know anything?
[07:43] <jordi> nope. You could leave the translation out.
[07:43] <jordi> xml2po could easily grow an --exclude option.
[07:44] <mdke> yeah that would be cool
[07:49] <bradb> SteveA: Given an interface IFoo, with a large number of attributes, is there a simple way to say "protect IFoo with permission Bar, but allow attributes x and y to be publically accessible"? Or do I have to <allow> x and y, and then name all the remaining attributes i want to protect in the <require> directive?
[07:51] <SteveA> bradb: no.  it is something i discussed with tres at EP, and have a plan to fix.  but that requires quite a bit of work on the zope component architecture.
[07:51] <bradb> ok
[07:51] <SteveA> once the rest of launchpad is well organized, and menus / ui issues are under control
[07:52] <SteveA> i'll spend some time making the security really rock rather than just get by
[07:56] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=stevea] . make bug notifictions concerning the same bug be part of the same email thread. (patch-2424: bjorn.tillenius@canonical.com)
[08:01] <kiko> BjornT, many congratulations
[08:01] <kiko> rock on
[08:05] <SteveA> kiko: cc-ed you on mail to stu and rob about a one line change needed in production.
[08:11] <kiko> doh!
[08:12] <SteveA> to get the root 'specifications' tab going to the right place
[08:12] <SteveA> i could do it myself, with ssh, vim and the restart script
[08:12] <SteveA> but it's kinda rude
[08:13] <kiko> no tests, tsk tsk.
[08:14] <SteveA> we need link checking tests for that one
[08:14] <SteveA> basically, for every page
[08:14] <SteveA>  - parse out the facet and menu links
[08:14] <SteveA>  - check they all work
[08:14] <SteveA> (or just do so for all links)
[08:15] <kiko> well
[08:15] <kiko> I did a scrubbing of pages for links
[08:15] <kiko> and then added them to xx-notfound-traversals
[08:15] <kiko> manual
[08:15] <kiko> but effective
[08:16] <kiko> there are many 404s in production, though
[08:49] <Kinnison> 220 minutes of CPU time :-(
[08:49] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: r=bjornt greatly improved error pages in pagetests and debug port.  introduced new url for a  debug root page.  fixed bug when redirecting for logging out. (patch-2425: steve.alexander@canonical.com)
[08:51] <cprov> Kinnison: god forbid !
[08:52] <cprov> Kinnison: it requires, indeed, request PQM twice for that ;)
[08:53] <Kinnison> 19697 postgres  25   0  110m  97m  86m R 99.9  2.7 226:56.42 postmaster
[08:53] <Kinnison> see
[08:53] <Kinnison> yeesh
[08:53] <Kinnison> ciao all
[08:53] <cprov> Kinnison: what is that ? the publisher in action ?
[08:53] <Kinnison> cprov: No, that's "DELETE FROM Build;"
[08:54] <cprov> Kinnison: shhhhh, good night
[08:57] <spiv> Kinnison: file:///usr/share/doc/postgresql-doc-7.4/html/sql-truncate.html
[09:12] <sivang> hmmm, so I see now that using launchapd integration, if someone use "Get help..." he is acutally offered to opne a support ticket, is this what we really want to have there?
[09:14] <sivang> I mean, it might be mistaken that way that this is where you report bugs, so I'm thinking we need to also have the report a bug item for lpi in order to distinct the two
[09:25] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Implement Distribution.getDistroReleaseAndPocket() for Keybuk. r=sabdfl (patch-2426: daniel.silverstone@canonical.com)
[09:33] <bradb> SteveA: Hm, it looks like I might have to wait until after the URL changes land to fix the ID/privacy thing. It's now causing 404's to be returned on private bugs for unauthorized users because of trying to access the relevant IBugTask through privacy-aware search APIs ("privacy-aware", as in, if you don't have access to view that task, it isn't returned by the search). I can think of ways to fix this, but I haven't thought of anyt
[09:44] <kiko> sivang, well, we need to consider this rather carefully -- most of the end-users we expect won't know how to use a bugtracker!
[09:45] <kiko> support tickets can  be linked to bugs
[09:45] <sivang> kiko: so the general idea is the users use the issue tracker, and devels us the bugtracker?
[09:49] <sivang> kiko: also, we need to make it easy for a group of users who are subscribed to a specific issues be notified when their underlying bug is fixed, so that they can be protected of the technical deails of the bug, but know when the issue is fixed
[09:52] <bradb> sivang: I'd be surprised if that wasn't the default behaviour (i.e. subscribe to issue != subscribe to bug.)
[09:52] <sivang> bradb: ah ok =) Sorry, I may be out of sync with the developments of the issue tracker 
[09:53] <bradb> sivang: I'm not saying that it actually is/isn't; I haven't looked at it at all really. :) /me takes a peek
[09:58] <sivang> bradb: I'm really interested in working/helping with the support/issue tracking stuff, I take it that the only missing link currently is the buffer application? (I wonder if you recall I mentioned it to you long before)
[09:59] <bradb> sivang: I don't know if there's plans for another application in between those two, but I sure hope not. :P
[10:00] <bradb> sivang: It seems to me that Launchpad itself could glue those two things together sufficiently (without, say, adding YAMT [Yet Another Menu Tab] )
[10:00] <bradb> Disclaimer: IMHO
[10:03] <sivang> heh
[10:03] <sivang> bradb: however, if we don't apply some kind of filtering we will end up with numerous support request that will require much work to sort out, attach to bugs etc
[10:04] <sivang> I forsee so many "my mouse don't work" etc
[10:05] <bradb> sivang: What "filtering" are you referring to exactly?
[10:06] <bradb> e.g. you can relate tickets to various contexts, e.g. distributions or upstreams, which seems like a significant step in filtering to me
[10:10] <sivang> bradb: this is filtering according to responsibility sources, what about filtering according to different parts of the OS, differnt classes of problems etc
[10:10] <kiko> jordi?
[10:11] <bradb> sivang: it appears that you can attach it to a specific sourcepackage as well. i imagine there would be a lot of overlap with the same problems Malone has with that for bugs.
[10:12] <bradb> which, in both cases, keywords may be able to address (i.e. for arbitrary grouping of tickets or bugs)
[10:13] <kiko> JORDI!
[10:34] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=lifeless]  Launchpad Auto Build System User Interface Prototype (buildfarm UI) also minor fixes for buildd infrastructure, still needing mpt love. (patch-2427: celso.providelo@canonical.com, mpt@canonical.com)
[10:34] <cprov> WOW !!! 
[10:37] <kiko> YES!
[10:45] <bradb> kiko: Would you be interested in doing a drive-by review of a fix for #1378? (Ripping out database imports in another module where they shouldn't be.)
[10:45] <kiko> how big?
[10:46] <bradb> kiko: diffing now...probably 50-100 lines max
[10:46] <kiko> sure
[10:47] <bradb> cool, thanks, just bazzing it now...
[11:08] <bradb> hm, it appears that limit doesn't work with selectBy. @#*!!%
[11:09] <kiko> wow, shipit test failures. wonder why.
[11:26] <bradb> kiko: you've got patchmail
[11:27] <mpt> arg
[11:27] <kiko> bradb, fix bug 2361 today
[11:27] <kiko> mpt, where was the error?
[11:27] <mpt> kiko: Unimplemented feature
[11:28] <kiko> blame the bradb
[11:28] <bradb> mpt: You can find dozens of those types of URLs in LP.
[11:28] <bradb> s/URLs/404s/
[11:28] <mpt> bradb: this isn't from a bad link, it's from an overly-consistent (for now) mental model
[11:28] <mpt> kiko: https://wiki.launchpad.canonical.com/MaloneFrontPages
[11:28] <bradb> mpt: Yes, I know :)
[11:29] <bradb> another example would be, say, https://launchpad.net/distros/ubuntu/+sources/mozilla-firefox
[11:29] <mpt> hey, but I can see https://launchpad.net/people/mpt/+assignedbugs now
[11:31] <bradb> kiko: Dude, 2361 has been that way for months. Why is it suddenly urgent at 17:30 Friday night? :)
[11:31] <kiko> because I SAID SO!
[11:32] <kiko> bradb, it's not so urgent, and it's not night, but if you fix it I will love you
[11:32] <kiko> bradb, will you get us mountain bikes to ride while I'm in montreal?
[11:32] <bradb> kiko: sure. how many?
[11:33] <kiko> one for me?
[11:33] <kiko> I'll take my pedals shoes and helmet
[11:33] <kiko> we can go for 6am rides
[11:33] <bradb> yeah, that could be fun
[11:33] <kiko> or freezing
[11:34] <bradb> that too
[11:34] <kiko> what pedals do you have?
[11:34] <bradb> Just the ones that came with the bike.
[11:35] <bradb> i.e. not clipless
[11:35] <bradb> I've been thinking of getting some though
[11:35] <kiko> oh
[11:36] <bradb> yeah, i'm pretty tame atm
[11:36] <bradb> no pedals == sissy riding
[11:37] <kiko> yeah
[11:37] <kiko> johan's been using a spare pair of time atacs I have
[11:38] <bradb> kiko: so, From: <preferredemail>, Reply-To: <bug address>?
[11:38] <kiko> correct
[11:38] <kiko> and the bug address should be
[11:38] <kiko> bug666@bugs.launchpad.net or bug555@launchpad.net
[11:38] <kiko> something like that
[11:40] <bradb> hm
[11:40] <kiko> I mean, others may correct me, but a lot of spamfilters block all-numbers email
[11:45] <bradb> kiko: can i merge the patch i just sent you?
[11:47] <kiko> wait for baz!
[11:48] <bradb> what's the wait for? i waited for baz so that you don't have to!
[11:48] <bradb> and, using mutt, you should have enough RAM left to read that email too
[11:49] <kiko> obviously you've never used baz
[11:49] <bradb> have so! i'm waiting on it right now.
[11:50] <bradb> status before switching
[11:50] <kiko> it's comparing from and to!
[11:50] <bradb> FROM and TO, you mean?
[11:51] <kiko> that too
[11:51] <kiko> --  utilities/lint.sh
[11:52] <bradb> ahhhehhe
[12:01] <kiko> bradb, I like the patch. I'm a bit concerned with orderBy, though
[12:02] <kiko> why am I concerned?