[02:17] <lifeless> spiv: is your review load ok ?
[02:17] <lifeless> spiv: I'd like to giveyou stubs pillar
[03:09] <spiv> lifeless: I'm only partway through malcc's branch, and I also need to reply to stub's librarian-layer review reply, so I think I'd prefer if you gave it to somebody else.
[03:11] <lifeless> ok
[03:11] <lifeless> jamesh: hows your load ?
[03:12] <jamesh> lifeless: two branches which I plan to do today.
[03:12] <lifeless> both tiny:0
[03:12] <jamesh> lifeless: I'll be at the sprint next week though
[03:12] <lifeless> ah right
[03:12] <lifeless> also, dyson is approved. Yay.
[05:28] <stub> Does that dyson fix also handle unreachable urls? Or is that still pending.
[06:12] <jamesh> stub: they'll get logged and skipped
[06:12] <jamesh> stub: at least at the level of the HTTP walker code, which now follows os.walk() behaviour closer
[07:02] <mpt_> Gooooooooooooooooooooood evening Launchpadders!
[07:06] <ajmitch> and such a lovely warm evening it is too
[07:07] <jamesh> it'll be warmer once I get to London ...
[07:26] <mpt_> Warm evening?
[07:26] <mpt_> Out of Dunedin again, ajmitch?
[07:29] <ajmitch> mpt_: hardly, I'm trying to keep warm here :)
[08:01] <jamesh> lifeless: any progress on packaging the tickcount extension?
[08:02] <lifeless> jamesh: aw shoot, I forgot.
[08:02] <lifeless> I'll do it Monday
[08:02] <jamesh> thought you might have :)
[08:28] <mpt_> cprov, ping
[08:35] <mpt_> ugh
[08:36] <mpt_> Any test in any branch is failing with "__init__() got an unexpected keyword argument 'prejoins'"
[08:36] <mpt_> spiv, do I need to update sqlobject or something?
[08:36] <mpt_> oh, spiv's away
[08:36] <mpt_> jamesh?
[08:36] <jamesh> mpt_: yeah?
[08:36] <lifeless> update sqlobject yes
[08:36] <mpt_> ok, ta
[08:37] <spiv> mpt_: just got back, actually :)
[08:37] <mpt_> 0 revisions pulled
[08:37] <lifeless> oh :(
[08:37] <mpt_> Is it still sqlobject/0.6/test/ ?
[08:38] <jamesh> mpt_: what do you get if you run "(cd sourcecode/sqlobject; bzr revno)"
[08:38] <jamesh> ?
[08:38] <mpt_> jamesh, 66
[08:39] <spiv> That's the right number.
[08:39] <jamesh> mpt_: are you sure that's the copy of SQLObject that's being used by the tests?
[08:39] <mpt_> No, but I haven't consciously done anything to change it
[08:39] <mpt_> How would I tell?
[08:39] <jamesh> does the lib/sqlobject symlink point to that copy?
[08:40] <spiv> Check the paths in the tracebacks you're getting.
[08:40] <mpt_> sqlobject -> ../sourcecode/sqlobject/sqlobject/
[08:41] <spiv> Mysterious.
[08:42] <mpt_> actually maybe I'm conflating two branches
[08:42] <mpt_> Aha, that branch has revno 55
[08:42] <mpt_> Whereas the recent one has a different error
[08:42] <spiv> Ah :)
[08:43] <mpt_> sorry for the confusion, I'll pastebin the new error
[08:45] <mpt_> spiv, https://chinstrap.canonical.com/~dsilvers/paste/filecrSEwC.html
[08:45] <SteveA> morning
[08:45] <mpt_> hi SteveA 
[08:46] <spiv> mpt_: "make build"
[08:47] <jamesh> mpt_: when you have some time, you might want to look at the new bug page changes from the bug tags branch in case there are some improvements you'd like to make
[08:48] <mpt_> spiv: eh. How anticlimactic. thanks :-)
[08:48] <mpt_> So is that a bug that a doctest fails unless you do a make of some sort first?
[08:49] <mpt_> (
[08:49] <mpt_> (I guess every other time I've done one, it's been after a make run)
[08:51] <spiv> mpt_: you basically can't import any significant amount of launchpad code with running 'make build' first.
[08:51] <spiv> mpt_: Because the security proxy code in Zope is C code, and nearly everything relies on them one way or another.
[08:52] <mpt_> I mean, is it a bug that the test system doesn't do make itself just in case
[08:54] <spiv> I don't think so.  'make check' depends on 'make build' already.  It would be complicated to make test.py invoke make, because then you'd have make invoking test.py invoking make...
[08:54] <spiv> It is arguably a bug that the error you get is so unhelpful.
[08:56] <lifeless> test.py could import zope.interfaces
[08:56] <lifeless> or some other C module
[08:58] <jamesh> SteveA: I'm doing another test import of the SF data on demo.lp.net (with bug tag support now).  I think after this runs successfully, I'd like to get a fresh production dump on demo.lp.net and announce it
[08:58] <spiv> Yeah, it could be done, but it would still be fragile.  I don't the minimal benefit is worth the effort.
[08:59] <lifeless> [trivial]  it; )
[08:59] <jamesh> https://demo.launchpad.net/products/python/+bugs <- tags portlet on the left
[08:59] <spiv> Typing "make build" isn't hard.  For new branches you really need to do "make schema" anyway, in case someone's merged some schema changes, and that already implies "make build".
[09:01] <jamesh> mpt_: you can see the bug page changes here: https://demo.launchpad.net/products/python/+bug/65477 -- a <fieldset> around the description and a list of tags below that
[09:03] <SteveA> jamesh: that's great
[09:19] <jamesh> SteveA: also, do you know of a list of the main Python developers preferred email addresses?
[09:22] <carlos> morning
[09:38] <mpt_> jamesh, thanks for pointing it out, I'll make it a bit lighter
[09:39] <jamesh> mpt_: now all we need is one of those pages with lots of different size fonts and we'll be that much closer to being web 2.0 compatible
[09:50] <mpt_> jamesh, "tag clouds"
[09:51] <mpt_> But we don't have enough gradients yet
[09:58] <stub> lifeless: Any reason you want to link SourcepackageRelease to (revision, branch) instead of just revisionnumber?
[09:58] <lifeless> yup
[09:59] <lifeless> if someone does 'uncommit' the revision will disappear from the branch
[09:59] <lifeless> but SPR must still have a handle to it
[10:00] <lifeless> one way to do that is to have revisionnumber have a field for 'really is present', but a cleaner way is to record that the SPR was 'from this branch and this revision', whereas revisionnumber is saying 'right now, these are the revisions in this branch' with no assertion about what *used* to be in it.
[10:01] <stub> If someone does uncommit, the revision and branch the Sourcepackage was generated from is just noise anyway because it no longer actually exists (?)
[10:01] <lifeless> nope
[10:01] <lifeless> if they do uncommit, we still have a copy of the revision contents.
[10:02] <stub> But what good does that do anyone? Does it serve a purpose besides chewing up space in the DB?
[10:02] <lifeless> (in the supermirror) - though we can be more tightly integrated between the db and what the supermirror contains in the future, to set constraints on revision cleanup
[10:02] <lifeless> it lets us display the diff between the releases
[10:03] <lifeless> even a push --overwrite will remove teh revisionnumber record for the revision from the branch, but still does not invalidate the SPR's reference.
[10:03] <stub> ok. I had assumed you couldn't do operations like that just from the db information.
[10:04] <lifeless> well, we need both the db information and the supermirror
[10:04] <lifeless> if we were to lose the db information we cannot do the operation at all
[10:05] <jamesh> stub: any chance of getting a fresh production dump for the launchpad_demo db?
[10:05] <stub> jamesh: Sure.
[10:07] <stub> lifeless: I  might need to get you to write table comments for these tables - it is difficult for me to work with the model when I have neither documentation nor advanced bzr theory.
[10:07] <lifeless> stub: sure. I've tried to give some comment like text in the spec, but I'll be happy to enlarge on it.
[10:07] <jamesh> stub: thanks.  The SF import script along with one to setup python-dev and python-infrastructure teams should give a good final import
[10:08] <stub> lifeless: I'll check out the spec in more details later and refresh my mind on the related ones. Do you know what timeframe we are looking at for implementation?
[10:09] <lifeless> stub: well, once the db patch is in place, I'll make a branch
[10:09] <lifeless> I'll spend a few hours a week on making tests pass with the new db shape
[10:09] <stub> jamesh: Do you want the same snapshot restored or a fresh production snapshot?
[10:09] <lifeless> once thats done, its implemented :)
[10:10] <stub> lifeless: ok. So nowish is good.
[10:10] <jamesh> stub: a fresh snapshot would save me from having to run the posubmission duplicate removal script, so I'll take that one if it is as easy to do
[10:10] <lifeless> stub: yes please!
[10:12] <jamesh> lifeless: ddaa reports that the branch scanner is running a lot faster now.
[10:12] <lifeless> sweet
[10:12] <jamesh> the next rollout should make it slightly faster still: it was trying to scan never-mirrored branches every run
[10:13] <jamesh> I guess the next area for optimisation is to make the interval at which branches get pulled a bit smarter
[10:13] <jamesh> taking failures and last modified dates into account
[10:14] <lifeless> right
[10:14] <lifeless> we have all the data to do that
[12:30] <elmo> jamesh/stub: ?
[12:31] <jamesh> elmo: yeah?
[12:31] <elmo> jamesh: carbon's running out of disk, is it all right if I take it down to move postgresql to a different array?
[12:32] <stub> Yo
[12:33] <stub> I can clean out a big chunk once this dbrestore is done, or now if it is urgent (I have a spare launchpad database loaded we don't really need).
[12:33] <stub> I wasn't going to bother with disk reorg until after the demo was done
[12:33] <elmo> /dev/cciss/c0d0p1      65G   60G  1.3G  98% /
[12:34] <elmo> that's my only concern ;-)
[12:34] <elmo> I don't mind if it runs out of space, just assumed you would
[12:34] <stub> Sorted now - back to 84% and will drop further in a short while
[12:35] <elmo> ok
[12:35] <stub> (restore is done, ready to swap old db for new db)
[12:35] <jamesh> should I kill the LP instance?
[12:35] <elmo> well, the external array is sat idle, so I'm happy to bring it online for you if you want, to avoid this again
[12:36] <jamesh> if the db restore is done and you want to move things round you may as well 
[12:38] <stub> jamesh: New db is there now
[12:38] <stub> jamesh: You might want to rerun update.py, security.py to ensure it is in sync with your codeline.
[12:39] <jamesh> stub: thanks
[12:39] <stub> elmo: Don't worry about it.
[12:39] <elmo> stub: okay
[01:14] <danilos> hey guys
[01:15] <danilos> if I want to check differences between dir(IPOFile) and dir(DummyPOFile), is there an easy way to do that?
[01:15] <danilos> (I want to see what is missing in DummyPOFile, which "implements IPOFile")
[01:16] <BjornT> danilos: zope.interface.verify.verifyObject(dummy_po, IPOFile)
[01:17] <danilos> BjornT: hum, I want to do that only once, so how do I get all the machinery up to test this and print it at stdout?
[01:17] <SteveA> it's important to verify the object, not the class
[01:17] <SteveA> because it really is the object we care about
[01:18] <danilos> SteveA: yeah, but the thing is that I am implementing a class and need to implement missing methods, as in bug #44860 (if we don't want to wait for the other oopses like that)
[01:18] <Ubugtu> Malone bug 44860 in rosetta "Crash when we try to pass a query string to a POFile that doesn't exist yet." [High,Confirmed]  http://launchpad.net/bugs/44860
[01:18] <SteveA> danilos: yes.  you implement the methods in the class so that the object will have the methods available
[01:18] <danilos> I mean, implementing just the missing stuff for 44860 is simple, and I've did that already
[01:18] <danilos> SteveA: but I just want a list of stuff I am missing, not to have to look at it by hand :)
[01:19] <SteveA> this is a good case for an interface tests, perhaps, like francis did for something recently
[01:19] <SteveA> you can use dir, Interface.names and set operatoins
[01:19] <SteveA> you'll need to remember to get all the names, taking into account parent interfaces
[01:20] <SteveA> BjornT: would you point danilos at the right APIs for this please?
[01:20] <SteveA> I need to go and take part in a meeting now
[01:20] <danilos> ok, where do I look up for interface tests?
[01:20] <danilos> SteveA: ok, thanks
[01:21] <BjornT> danilos: sorry, it should be verifyObject(IPOFile, dummy_po)
[01:22] <danilos> BjornT: ok, but where do I go to put that? do I implement something like a pagetest?
[01:23] <jamesh> BjornT: https://demo.launchpad.net/products/python/+bugs <- bug tags in action
[01:27] <BjornT> danilos: for now, i'd suggest adding it to pofile.txt, or create a new dummypofile.txt which would test DummyPOFile.
[01:28] <danilos> BjornT: ok, will do that then
[01:36] <BjornT-> danilos: for now, i'd suggest adding it to pofile.txt, or create a new dummypofile.txt which would test DummyPOFile.
[01:37] <danilos> BjornT-: yeah, ok, I've seen that bit, I'll do that
[01:38] <BjornT-> jamesh: looks good. how do you generate the tag names? 'core--c-code-' and 'library--lib-' looks a bit strange.
[01:38] <jamesh> BjornT-: convert everything that isn't a valid name character to a dash ...
[01:39] <jamesh> not the best algorithm, but it can be cleaned up later
[01:39] <jamesh> so I think the original text was "Core (C Code)" and "Library (lib)"
[01:45] <mpt> collapse multiple dashes
[02:00] <ddaa> user ask about webspace to host release tarballs on launchpad from time to time
[02:00] <ddaa> or project home pages
[02:01] <ddaa> is that still true that the vocation of Launchpad is to centralise metada and that this sort of bandwidth intensive stuff should be stored somewhere else?
[02:24] <ddaa> Yay! New cscvs/bzr-native branch up for review
[02:24] <ddaa> BjornT: if you could review that before going on leave (I understand you are the guy who always get the bzr-native reviews), I would be grateful.
[02:25] <lifeless> ddaa: hes not
[02:25] <lifeless> ddaa: let the process do its thing
[02:26] <ddaa> yes Mr. Process
[02:28] <ddaa> time to tackle importd/bzr-native :)
[02:28] <ddaa> Mh
[02:36] <elmo> salgado: can groups arbitrarily add other groups to themselves?
[02:36] <carlos> elmo: in launchpad, yes
[02:36] <salgado> elmo, yes, team admins can do that
[02:36] <carlos> but I think you should be admin
[02:36] <carlos> right
[02:38] <elmo> salgado: meep, that's kind of unfortunate
[02:38] <salgado> elmo, why?
[02:38] <elmo> well, I could for example create a group called DEBIAN-Is-T3H-SUCK, and then add ubuntu-members to it
[02:39] <elmo> or, in a real world example, a joke translation group called ubuntu-l10n-en-us-fargo added a non-joke translation group ubuntu-l10n-en-gb to themselves, making the en-gb look like the joke en-us-fargo is
[02:40] <elmo> [and obviously when you visit the en-gb team's page, you see "this team is a member of en-us-fargo"] 
[02:42] <salgado> yeah, I see what you mean. :/
[02:42] <ddaa> From a purely technical/security perspective, team membership has positive value: it does prevent you from doing anything you could do before, it can only add rights.
[02:43] <ddaa> I find it interesting that from a human perspective it can have negative value, in the eye of the beholder.
[02:43] <ddaa> * it does _not_ prevent you
[02:45] <ddaa> I find it somewhat similar to bug 29863 as opposed to bug 41639
[02:45] <Ubug2> Malone bug 29863 in launchpad "Workflow to transfer ownership" [Medium,Confirmed]  http://launchpad.net/bugs/29863
[02:45] <Ubug2> Malone bug 41639 in launchpad "Product owner should be able to reassign ownership to another user." [High,Fix committed]  http://launchpad.net/bugs/41639
[02:46] <ddaa> In that, in general, membership and ownership have a cost.
[02:49] <bradb_> Maybe you should be able to add only teams of which you're a member (directly or indirectly) to other teams.
[02:49] <salgado> so, maybe we should always require the confirmation from an admin of the team that is being added as a member?
[02:49] <ddaa> salgado: see bug 29863
[02:49] <Ubug2> Malone bug 29863 in launchpad "Workflow to transfer ownership" [Medium,Confirmed]  http://launchpad.net/bugs/29863
[02:50] <ddaa> bradb_: that would be a worthwile optimisation
[02:50] <salgado> ddaa, yes, I saw it. that's why I thought of requiring the confirmation
[02:51] <ddaa> when the user has the necessarry rights to both propose and accept the transfer/membership, the validation could be shorted out.
[02:51] <elmo> salgado: sounds good to me
[02:54] <salgado> okay, /me files a bug
[02:55] <ddaa> salgado: maybe just edit bug 29863, I already added comments
[02:55] <Ubug2> Malone bug 29863 in launchpad "Workflow to transfer ownership" [Medium,Confirmed]  http://launchpad.net/bugs/29863
[02:57] <ddaa> bradb_: the new "add attachement" UI in the comment form is nice, but it makes it harder to post a comment. Previously I could just do tab-return to post a comment, now I need to tab across the attachement form...
[02:57] <salgado> ddaa, although we're going to solve both bugs similarly, they're in fact different bugs and will probably not be fixed at the same time, so I'd prefer to have separate bugs. (I'll mention 29863 on the new one, though)
[02:57] <bradb_> ddaa: yeah. i wonder if tab should skip over the attachment form? i wonder what mpt thinks.
[02:58] <ddaa> bradb_: do you need me to file a bug?
[02:58] <bradb_> ddaa: sure
[03:06] <ddaa> bradb_: bug 53635
[03:06] <Ubug2> Malone bug 53635 in malone "attachement form makes it harder to post comment" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/53635
[03:06] <ddaa> Wow! Palindrome post!
[03:18] <bradb_> ddaa: thanks
[04:23] <bradb_> I want to be precise in my API documentation about the default value for a datecreated column. Is it appropriate to reference canonical.database.constants.UTC_NOW in interface documentation?
[04:24] <bradb_> It seems accurate and precise, but I don't see any reference to that constant in any other launchpad interface documentation.
[04:53] <carlos> bradb_: Well, it's a constant.... I guess is ok to do it
[04:56] <bradb_> carlos: Yeah, I think I'll go with it.
[06:02] <Enverex> Does anyone know how the Karma on Launchpad works? Is it automatically given or is it assigned by people?
[06:03] <malcc> It's automatically given
[06:03] <ddaa> It's given automatically
[06:03] <ddaa> Though, you could possibly bribe stub to get a higher karma, if you really wanted to :)
[06:04] <Enverex> lol, awww, I thought it was people showing their appreciation =/
[06:04] <ddaa> The idea of allowing people to donate or substract karma to/from other people has been bounced already.
[06:05] <ddaa> I personally do not care enough about karma to tell you much more.
[06:05] <Enverex> Not really subtract, just add (like answering stuff, etc) but yeah, it normally doesn't work, heh
[06:10] <Kamping_Kaiser> hi all, i just copped ID  OOPS-202C253  trying to jump to a bug. is this me doign somethign wrong or is malone broken?
[06:10] <Ubug2> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/202C253
[06:23] <BjornT> Kamping_Kaiser: it's a bit unclear, but that's a 'not found' page, and means that the bug doesn't exist. you mis-typed the bug number, it contains one digit too much.
[06:23] <BjornT> Kamping_Kaiser: i think there's a bug open on that a nicer page should be shown, saying that the bug doesn't exist.
[06:25] <matsubara> BjornT, Kamping_Kaiser: fwiw, it's bug 6010
[06:25] <Ubugtu> Malone bug 6010 in malone "Custom bug not found page for inexistent bugs." [Medium,Confirmed]  http://launchpad.net/bugs/6010
[06:26] <Kamping_Kaiser>  BjornT thanks, i suppose i must have copied a debian bug into the LP bug number spot... damn shared changelogs
[09:46] <LarstiQ> wuh, karma sure is jumping around a lot lately
[09:59] <BenC> Can someone check OOPS-202B278 and let me know what I did to break lp? :)
[09:59] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/202B278
[10:02] <salgado> BenC, it takes a few minutes for OOPSes to show up. I'll check as soon as it shows up
[10:03] <BenC> thanks
[10:08] <salgado> BenC, that's a known bug, for which a fix is already committed but not yet in production
[10:10] <salgado> BenC, bug 53476
[10:10] <Ubugtu> Malone bug 53476 in malone "OOPS while assigning karma to a person when changing a DistroRelease bugtask status" [Medium,Fix committed]  http://launchpad.net/bugs/53476
[10:11] <BenC> so if I don't set the status, it should work?
[10:12] <BenC> yep, that worked
[10:12] <BenC> thanks
[10:12] <salgado> np
[10:22] <newz2000> is launchpad translated to different languages? I'm writing documentation and was curious if people will see different things depending on their native language.
[10:24] <mdke> newz2000: no, all English afaik
[10:24] <newz2000> ok. Thanks. That actually makes things a little easier for me.
[10:24] <mdke> :)