[12:32] <jamesh> stub: bah.  seems like too many schema changes have been made since launchpad_staging was updated for my script to run :(
[12:32] <stub> jamesh: ok
[12:33] <stub> jamesh: I'm running kiko's branch. When he lands it to rocketfuel that shouldn't be a problem.
[12:33] <stub> kiko: ^^^
[12:35] <jamesh> okay.
[12:35] <kiko> stub, it's in the queue
[12:58] <kiko> carlos, want some comments on TranslationDiffs?
[12:59] <kiko> a) there are no code changes to describe how to generate the diffpage
[12:59] <kiko> b) you talk about word diffs, but we're really discussing intra-string diffs
[12:59] <kiko> c) did you ask mpt on an idea to solve the second issue you point out?
[01:00] <kiko> d) I think this code is going to be fast enough for it not to matter -- I think the main overhead we have is for db queries.
[01:00] <kiko> that is all, but it is a very simple spec and it's good enough IMO
[09:38] <Nafallo> fwiw, I'm getting timeout all the time on Launchpad today
[09:39] <Nafallo> https://launchpad.net/distros/ubuntu/dapper/+source/muine/+pots/muine/sv/+translate
[09:45] <Nafallo> are you guys stresstesting the database or something? :-P
[12:06] <siretart> hey launchpad folks
[12:36] <siretart> hey, is it possible to edit the 'status notes (optional)' via EmailInterface? if yes, how?
[12:51] <siretart> is there any filtering on bugs available in malone yet? 
[12:51] <siretart> e.g. I wannt all bugs assigned to group 'motu' with status 'pending upload'
[03:28] <sabdfl> carlos: ping
[03:35] <kiko_12> elmo, here we go:
[03:35] <kiko_12> 03:24:35 DEBUG   Running dpkg-source -sn -x /srv/archive.ubuntu.com/ubuntu/pool/main/c/clearlooks/clearlooks_0.6.2-1~hoary1.dsc
[03:35] <kiko_12> 03:24:36 DEBUG   > dpkg-source: failure: cannot read /srv/archive.ubuntu.com/ubuntu/pool/main/c/clearlooks/clearlooks_0.6.2.orig.tar.gz: No such file or directory
[03:35] <kiko_12> 03:24:36 DEBUG   > RETURNED: 2
[03:35] <kiko_12> 03:24:47 DEBUG   Running dpkg-source -sn -x /srv/archive.ubuntu.com/ubuntu/pool/main/t/tla/tla_1.3.3-2~hoary1.dsc
[03:35] <kiko_12> 03:24:47 DEBUG   > dpkg-source: failure: cannot read /srv/archive.ubuntu.com/ubuntu/pool/main/t/tla/tla_1.3.3.orig.tar.gz: No such file or directory
[03:35] <kiko_12> 03:24:47 DEBUG   > RETURNED: 2
[03:36] <kiko_12> 03:24:38 DEBUG   Running dpkg-source -sn -x /srv/archive.ubuntu.com/ubuntu/pool/main/g/gtk-sharp2-unstable/gtk-sharp2-unstable_1.9.5-1ubuntu2~hoary1.dsc
[03:36] <kiko_12> 03:24:38 DEBUG   > dpkg-source: failure: cannot read /srv/archive.ubuntu.com/ubuntu/pool/main/g/gtk-sharp2-unstable/gtk-sharp2-unstable_1.9.5.orig.tar.gz: No such file
[03:36] <kiko_12>  or directory
[03:36] <kiko_12> 03:24:38 DEBUG   > RETURNED: 2
[03:36] <kiko_12> 10:11:21 DEBUG   Running dpkg-source -sn -x /srv/archive.ubuntu.com/ubuntu/pool/universe/p/python-qt3/python-qt3_3.14.1-2ubuntu2.dsc
[03:36] <kiko_12> 10:11:22 DEBUG   > dpkg-source: failure: cannot read /srv/archive.ubuntu.com/ubuntu/pool/universe/p/python-qt3/python-qt3_3.14.1.orig.tar.gz: No such file or directory
[03:36] <kiko_12> 10:11:22 DEBUG   > RETURNED: 2
[03:37] <kiko_12> elmo, that's all.
[03:45] <elmo> kiko_12: apparently it only  came in at 6:55 this morning - I have no idea how it missed the two manual syncs I did yesterday evening
[03:45] <elmo> (6:55 local to the DC)
[03:46] <elmo> in any event the symlinks are there now, at least for gtk-sharp and clearlooks, and probably tla.  I'll fix the python-qt3 case now
[03:46] <kiko_12> elmo, weird indeed, but cool
[03:46] <kiko_12> okay, let me know when they are done and I'll do a re-run
[03:47] <sabdfl> salgado: ping
[03:47] <salgado> sabdfl, pong
[03:48] <sabdfl> salgado: do you have a spec in place for that team member proposal deletion?
[03:48] <sabdfl> please have one in place by the time i catch up with you
[03:49] <sabdfl> salgado: also, do you plan to finish LaunchpadRolloutProcedures this week?
[03:50] <salgado> sabdfl, I'm finishing the team member deletion one right now. should I get it through SteveA first?
[03:52] <salgado> sabdfl, we created the LaunchpadReadOnly while discussing the LaunchpadRolloutProcedures. I need to talk with stub and then I think I should be able to get it ready for review today
[04:02] <sabdfl> SteveA: ping
[04:02] <sabdfl> salgado: yes, please get the deletion spec reviewed by stevea, then bring it to me in your session
[04:47] <kiko_12> elmo, yo?
[04:47] <elmo> kiko_12: ?
[04:47] <kiko_12> cprov, spec-ping?
[04:47] <kiko_12> elmo, are we okay to run gina?
[04:48] <elmo> kiko_12: no, I'm still working on the symlink problem
[04:48] <cprov> kiko_12: putz ... new nick 
[04:48] <kiko_12> elmo, okie, thanks.
[04:48] <cprov> kiko_12: https://launchpad.net/products/soyuz/+spec/distro-admin-perms
[04:48] <kiko_12> carlos, did you get my feedback from yesterday?
[04:48] <cprov> kiko_12: https://launchpad.net/products/soyuz/+spec/pushbutton-cd-building
[04:49] <cprov> kiko_12: https://launchpad.net/products/launchpad-buildd/+spec/installer-rebuild
[04:49] <cprov> kiko_12: https://launchpad.net/products/launchpad-buildd/+spec/install-cd-image-generation
[04:51] <carlos> kiko_12, yes, I need to apply it. Thank you
[04:51] <kiko_12> carlos, wonderful, cheers.
[04:51] <salgado> SteveA, ping
[04:54] <cprov> kiko_12: schedule for DistroReleaseFlavours, DerivationAdminUserInterface and Overview and PopulatingPackagingRecords are urgent.
[04:55] <kiko_12> mmmm ok
[04:55] <cprov> kiko_12: thank you.
[04:55] <kiko_12> cprov, are you not assigned to these specs?
[04:58] <cprov> kiko_12: not yet, assign me if you want 
[04:58] <sabdfl> kiko_12, Kinnison, bradb_: subscription consolidation is deferred till dapper+1
[04:59] <sabdfl> the rationale: to do it properly requires a huge amount of work, for undefined benefits.
[04:59] <sabdfl> i am making the irc notification ("dilys on rails") spec essential, so lets focus attention on a simple, straightforward implementation of that
[04:59] <sabdfl> please ack
[05:00] <kiko_12> I still think Steve should design either infrastructure or pattern to make subscriptions implementable in a standard way -- but it's not a massive work and can be done post-UBZ now that we have done a good discussion of requirements and possible models.
[05:00] <kiko_12> but okay
[05:00] <sabdfl> kiko_12: it really is a huge chunk
[05:00] <sabdfl> it requires a retooling of our object model, so that each kind of object knows where it sends events
[05:01] <sabdfl> and classes can then query one another to know what events they might get sent
[05:01] <sabdfl> so you can look at a Distribution *class* and it can tell you what kinds of events it gets from a *SourcePackage*
[05:01] <sabdfl> and what from a DistroReleaseBinaryPackageRelease
[05:01] <sabdfl> when that's all in place, we can support anybody subscribing to any set of things they like
[05:02] <sabdfl> till then, we can only do custom hardcoded hacks
[05:02] <sabdfl> which should be fine for the very basics
[05:02] <kiko_12> I am suggesting standardizing the hack, just that
[05:02] <sabdfl> in other words, we have to push back on some of the distro team requirements ("i'd like to see new bugs on main") in the short term
[05:02] <sabdfl> kiko_12: that's very deep zope fu
[05:02] <sabdfl> think of how long it took to get the menu system in place
[05:02] <sabdfl> and that's lightweight by comparison
[05:03] <kiko_12> the main delay for menus was clarifying requirements
[05:03] <sabdfl> and this will have far more complex requirements
[05:03] <kiko_12> however, requirements are not entirely clear for this either
[05:03] <kiko_12> yeah
[05:03] <sabdfl> the menu's requirements have changed very little since Zermatt (!), and the only changes were simplifications
[05:03] <sabdfl> not additional requirements
[05:06] <kiko_12> that's not how I recall it :)
[05:08] <salgado> stub, is it possible that something went wrong in the rollout? https://staging.ubuntu.com/people/salgado/+reportedbugs is broken in staging, but not in rocketfuel
[05:09] <salgado> s/rollout/rollout of staging/
[05:09] <stub> salgado: Staging is currently running one of Kikos branches, not head. So probably, yes.
[05:09] <salgado> oh, okay
[05:17] <elmo> kiko_12: ok, you should be good to go now
[05:17] <elmo> sorry, took a while to confirm it was in fact only that one last missing orig.tar.gz symlink
[05:23] <elmo> stub: balleny has postgresql-8.0 now; I'm resyncing /home/pqm tho, so don't do anything in there you don'twant overwritten
[05:23] <stub> elmo: Ta
[05:24] <kiko_12> elmo, rock-n-roll I owe you a choc-chipper
[05:24] <kiko_12> stub, can you run breezy and hoary-backports again? just those two will be speedy, otherwise, the whole thing
[05:24] <kiko_12> no need to delete anything
[05:48] <bradb_> sabdfl: right, saw your message about subscription consolidation + DoR.
[05:50] <Nafallo> kiko_12: ehm, are you a respawned copy of kiko or something? :-)
[05:51] <kiko_12> Nafallo, no, I am the new and improved kiko v12.0
[05:52] <Nafallo> kiko_12: ah, how does it feel to die? :-)
[05:53] <kiko_12> I can't remember
[05:53] <kiko_12> niemeyer, you have a new spec and a new spec assignment. essential. kthxbye
[05:53] <Nafallo> :-)
[06:05] <stub> elmo: Is it fine to chown -R postgres:postgres /etc/postgresql on balleny? I need to rebuild this postgres funky cluster thing which involves deleting and recreating the existing configs.
[06:05] <stub> elmo: Or I can get you to run the relevant pgclustercreate commands as root
[06:06] <elmo> stub: chowned - do you need anything done with postgresql-common ?
[06:07] <stub> elmo: I havn't the foggiest yet ;)
[06:07] <elmo> k
[06:08] <stub> Bah. I can't drive these new tools. I'll grab pitti when I'm finished here.
[06:23] <salgado> SteveA, ping, ping
[06:25] <kiko_12> salgado, he's a bit busy, can I help you?
[06:26] <salgado> kiko_12, https://wiki.launchpad.canonical.com/InactiveMembershipDeletion
[06:29] <kiko_12> salgado, can it be with me or stub, I wonder? 
[06:29] <kiko_12> SteveA's more than a bit overloaded
[06:30] <salgado> yes, I guess so
[06:36] <kiko_12> okay, I need to talk to bradb_ and then I'll be over
[06:37] <salgado> kiko_12, great. ta
[07:26] <salgado> kiko_12, have you looked at that spec already?
[07:33] <kiko_12> yes, a bit.
[07:40] <stub> lifeless: 8.0 is setup btw
[07:43] <lifeless> stub: thanks
[07:54] <siretart> https://launchpad.net/sprints/instant/+workload gives me a lp system error
[08:39] <\sh> sabdfl / BjornT :  thx for the really nice email interface to malone 
[08:43] <sabdfl> siretart: ah, bug. only happens when there are no specs approved for the sprint
[08:45] <sabdfl> \sh: you're welcome :-)
[08:46] <mdke> i think it is a bit of a shame not to import closed bugs to malone too
[08:46] <mdke> because (1) people won't be able to reopen em easily and (2) they are useful for searching for bugs when looking for something which may have been fixed in the unstable version
[08:47] <mdke> maybe there are good reasons not to import them that I can't see though
[08:55] <sabdfl> mdke: not a bad idea. jamesh?
[08:57] <jamesh> sabdfl: I'd need to make a few modifications to my import routines first (the main one is duplicate bug handling)
[08:57] <bradb_> I asked mdz about that last night. He didn't think it was a big deal to not import closed bugs.
[08:58] <jamesh> we should be able to import those bugs at a later date if they are important
[08:58] <mdz> it's not important operationally, no
[08:58] <mdz> they are useful data to have online, though, and we shouldn't throw them away
[08:58] <jamesh> since the bug watch records that a bug has been imported
[08:58] <mdz> so we should probably import them before we shut down bugzilla
[08:59] <mdz> but it isn't a blocker for the transition to malone
[08:59] <stub> salgado: Steve said you needed me. Please come and visit if so.
[08:59] <jamesh> mdz: my understanding is that bugzilla would remain in read-only mode (possibly indefinitely)
[08:59] <mdz> 8 clicks and 3 page loads to set the status of a bug...that's a blocker
[08:59] <salgado> stub, that's true. where are you?
[08:59] <mdz> jamesh: sure, but we certainly won't want to maintain it forever
[08:59] <stub> salgado: The other room
[09:00] <bradb_> We might as well import the closed bugs straight away then, IMHO.
[09:00] <stub> salgado: The one with elmo's server in the cupboard
[09:01] <jamesh> it probably won't be too much trouble to process the duplicates table afterwards
[09:01] <jamesh> maybe look at the old Bazaar bugs too
[09:07] <jordi> I hereby declare myself as a launchpad useless. As I can't do many of the stuff I should be able to.
[09:14] <uws> If I view the launchpad page of a team, and I click packages, the pages says: "<team name> developers is not currently recorded as the maintainer of any packages in the Launchpad system."   But when I view the product page, it says "Registrant: <team name>"    Is this a bug?
[09:15] <uws> And if I click "change maintainer" on thr product page, it lists the correct team as "current maintainer"
[09:18] <kiko_12> carlos, dude -- can you get your notes up on DistroTeamOneOnOne like nowish
[09:18] <jamesh> uws: products aren't packages
[09:19] <jamesh> uws: there should be some way to get a list of the maintained products, but there isn't one right now.
[09:19] <jamesh> kiko_12: I made the changes you requested to https://wiki.launchpad.canonical.com/ValidatingSignOnlyGpgKeys
[09:19] <carlos> kiko_12, uuppps, I have them on my laptop... will do it as soon as possible, sorry...
[09:20] <uws> jamesh: Ok. Should I file a bug against rosetta?
[09:21] <kiko_12> thanks carlos 
[09:21] <kiko_12> jamesh, rock and roll
[09:21] <jamesh> uws: the bug should be filed against Launchpad, and the title should be something like "no way to get a list of maintained products"
[09:21] <jamesh> I'm not sure if it has been reported already
[09:22] <jamesh> uws: actually, don't file a bug: https://launchpad.net/products/launchpad/+bug/1135
[09:22] <Ubugtu> Malone bug #1135: No obvious way to get from a person to what projects/products they're involved in Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Guilherme Salgado, Status: Accepted http://launchpad.net/malone/bugs/1135
[09:22] <uws> jamesh: excuse me, s/rosetta/launchpad/ slip of the finger
[09:22] <uws> jamesh: Ok. will leave it
[10:03] <uws> ugh, https://launchpad.net/products/launchpad/+bug/3293 is annoying ;(
[10:03] <Ubugtu> Malone bug #3293: Edit buttons on other people's page should not be visisble Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/malone/bugs/3293
[10:09] <\sh> who wrote ubugtu?
[10:11] <bradb_> \sh: Seveas, I think
[10:11] <\sh> Seveas: ping
[10:11] <Seveas> pong
[10:12] <Seveas> \sh, 
[10:13] <\sh> Seveas: is it possible to have another instance of your bugbot to join ubuntu-motu?
[10:13] <\sh> especially for universe-bugs?
[10:13] <Seveas> I offered that, but there were some objections
[10:13] <Seveas> it's currently in #ubutnu-desktop and here
[10:14] <\sh> i wonder which objections...i'll query u 
[10:14] <Seveas> So if the motu want him now, I'd be happy to make it join
[10:29] <kiko_12> cprov, ping?
[10:29] <cprov> kiko_12: pong
[10:30] <kiko_12> cprov, are you planning on doing mirror management?
[10:31] <cprov> kiko_12: sorting issues ... it's almost ready for review (2nd time)
[10:36] <kiko_12> cprov, can you put up your notes for DistroOneOnOne?
[10:36] <kiko_12> that is still missing and I really need it 
[10:37] <cprov> kiko_12: DistroOneOnOne ? sorry ?
[10:38] <cprov> kiko_12: what is the product target ? I really don't remember that one  
[10:38] <kiko_12> cprov, wiki.launchpad.canonical.com/DistroOneOnOne 
[10:39] <kiko_12> cprov, what product target? mirror management?
[10:39] <cprov> kiko_12: no, DistroOneOnOne
[10:40] <cprov> kiko_12: DistroTeamOneOnOne ...
[10:47] <\sh> sabdfl: to set a status of a bug to fixed with the malone mail interface...do i need the whole affects /products/bla status fixed? or do i only need to send a sign mail to <bugno>@bugs.launchpad.net and write status fixed ?
[10:52] <kiko_12> \sh, you need the affects bla.
[10:52] <\sh> gnarf...
[10:53] <\sh> so i have to write something more
[10:54] <cprov> kiko_12: notes commited in DistroTeamOneOnOne, sorry about the delay 
[10:55] <\sh> kiko_12: more logical would  be to have only status fixed for this, because we have the bugno in the mail header :)
[10:55] <\sh> imho
[10:56] <sabdfl> \sh: what if that bug number affects upstream and the distro?
[10:56] <sabdfl> which task are you saying is fixed?
[10:58] <\sh> right..i need to think the other way around
[10:58] <\sh> not the bugzilla way
[10:59] <bradb_> \sh: A lot of people raised this concern during UBZ. I think we may be able to do better.
[10:59] <bradb_> e.g. if there's one task, it's obvious which one to work on
[11:00] <bradb_> if there's more than one task, it might be obvious which one to work on with a string shorter than "affects /some/url/path/thingy", as long as it's enough information for us to distinguish. if not, we can send a rejection email with the valid options.
[11:01] <bradb_> It's not something I've thought about in great detail, just a possible path for us to explore to help the user out a little bit.
[11:02] <\sh> actually siretart and I are writing a small tool, which is able to send as fast as possible a mail for "new bugs" for "updating bugs" and for closing bugs.
[11:03] <\sh> whereas new bugs needs to have a sourcepackage or product assigned, an update or closed bug doesn't need normally
[11:03] <\sh> but now...thinking again about this problem...a small xmlrpc solution looks much better for this 
[11:04] <bradb_> \sh: Awesome. The other concern that a lot of people raised was GPG signing. IMHO, we may have jumped the gun on that one. Kamion pointed out that no spammer has *ever* managed to guess the debbugs syntax correctly, and I don't see any reason for us to think a spammer would be more likely to write a Malone newbug email.
[11:04] <kiko_12> thanks cprov 
[11:04] <\sh> bradb_: yeah..new bugs and gpg signing was my concern...it should be removed
[11:07] <\sh> we wrote now a small utility to file merge bugs to malone from CLI...via email with gpg signing and LPID...which was now an 1h efford...
[11:07] <\sh> and very quick and dirty
[11:08] <bradb_> Cool. It's nice to see people starting to get creative in the way they use Malone.
[11:09] <\sh> bradb_: u can thank scott, because MoM is not filing any bugs to malone...so we need to do it manually  :) 
[11:10] <bradb_> ah :)
[11:11] <\sh> but now I'm thinking about something like kbugbuster...to have a gui frontend tool for malone
[11:12] <\sh> and for this we would need the ultimate xmlrpc or soap interface
[11:13] <bradb_> Right. We've deprioritized XML-RPC for now, because we've got a lot of fundamental things to get right in the web UI first.
[11:14] <bradb_> And, well, we really need to get Ubuntu main running Malone.
[11:15] <\sh> yepp
[11:22] <uwl> Hello All,  is somebody here?
[11:49] <mdz> Kinnison: 22544 lp_impor  25   0 1718m 1.6g 4832 R 97.9 42.5  12:38.60 python
[11:49] <mdz> ...
[11:55] <Kinnison> finished dude
[11:55] <Kinnison> that was death row
[11:55] <Kinnison> it sucks
[11:55] <Kinnison> I need to fix it
[11:58] <mdz> Kinnison: comparison output in ~mdz/compare
[11:59] <mdz> Kinnison: old versions in Sources
[12:01] <spiv> Kinnison: http://twistedmatrix.com/users/spiv/countrefs.py may help with diagnosing what's eating memory.
[12:02] <Kinnison> spiv: I know *exactly* what's eating memory
[12:02] <Kinnison> sqlobject
[12:02] <spiv> I've probably mentioned that before, now that I think about it.
[12:02] <Kinnison> it's t3h_suxx0r
[12:02] <spiv> Ah.
[12:02] <spiv> Whee.