[12:04] <ddaa> lifeless: does svn_oo support the svn equivalent of module configs?
[12:06] <Keybuk> kikoX: obviously the biggest problem for us is that it means bugs are getting assigned to packages that should not exist, so there's nobody who's bug contact for them, or even looking for them
[12:06] <lifeless> externals ? dont know
[12:06] <Keybuk> so I've been going down the list of packages and trying to look for "bugs on binaries" too
[12:06] <Keybuk> so will see if I find any more examples that prove or disprove that syncs aren't doing it
[12:07] <ddaa> carlos: can you file a bug about that, provided I can stay focused on importd long enough, I will come around to in the medium term
[12:07] <ddaa> (a few months) unless somebody contributes code after we release cscvs
[12:07] <kikoX> Keybuk yeah. this needs to be fixed ASAP
[12:07] <kikoX> cprov is on it
[12:08] <carlos> ddaa: ok, will do
[12:08] <carlos> ddaa: thanks for looking into it
[12:15] <kiko> salgado, what's the RT number?
[12:16] <salgado> kiko, 9143
[12:16] <kiko> thanks salgado 
[12:16] <kiko> hey Znarl 
[12:16] <Znarl> Hello
[12:17] <kiko> sorry to bump you this late
[12:17] <salgado> yeah, sorry for the short notice
[12:17] <kiko> Znarl, salgado filed RT 9143
[12:17] <salgado> it's all my fault
[12:17] <Znarl> It's fine.  How can I help?
[12:17] <lifeless> hi znarl. thanks
[12:17] <kiko> but basically we need to ensure lifeless and you synchronize on flicking the switch for the shipit apache redirect setup 
[12:18] <kiko> it's only really a problem for shipit.ubuntu
[12:18] <Znarl> RT#9143.  
[12:18] <Znarl> ok.
[12:18] <kiko> lifeless, Znarl: perhaps #canonical-meeting?
[12:18] <kiko> Znarl, it's important that it be done more or less in sync with lifeless or else the redirect will break until the rollout happens.
[12:18] <Znarl> Sure.
[12:20] <kiko> salgado, I'll let you handle things on #canonical-meeting :)
[12:21] <Yannig> Hum, problem with the server :(
[12:21] <Yannig> OperationalError
[12:21] <Yannig> A server error occurred.
[12:21] <kiko> Yannig, oops id?
[12:22] <Keybuk> OperationalError
[12:22] <Keybuk> A server error occurred.
[12:22] <Keybuk> heh
[12:22] <Keybuk> ok, somebody beat me
[12:22] <Keybuk> kiko: no oops, just "*BOOM*"
[12:23] <kiko> Keybuk, Yannig: the system is being upgraded, hold on for some turbulence
[12:23] <Keybuk> kiko: it told me 14 minutes not more than 3 minutes ago :p
[12:23] <kiko> apparently lifeless is not wasting a minute
[12:27] <lifeless> Keybuk: sorry, it lied to you
[12:27] <kiko> we normally have a launchpad is down page
[12:27] <kiko> for some reason it's down too
[12:28] <carlos> kiko, lifeless: are you doing the rollout?
[12:28] <kiko> yep
[12:30] <carlos> I didn't finished with mark's branch merge...
[12:30] <kiko> carlos, too late now :)
[12:31] <carlos> I guess..
[12:31] <carlos> anyway, I'm going to merge it tonight as I told SteveA...
[12:31] <carlos> kiko: about https://launchpad.net/bugs/45164
[12:32] <carlos> kiko: mpt told me that we should not add the navigation links to the bottom of the translation form, because people would click on 'Next' instead of submit translations and that would make them lose their translations
[12:32] <carlos> there is already a rejected bug about it
[12:32] <kiko> I see. then dupe it.
[12:33] <carlos> ok
[12:34] <Yannig> The "launchpad is down" page is up :)
[12:48] <Yannig> Any idea when it should be back? Nothing hurrying but I was about to download po file and I'll have to go to bed reasonably early :)
[12:49] <lifeless> 10 minutes 
[12:49] <Yannig> Thanks :)
[01:07] <lifeless> web ui is back
[01:17] <carlos> lifeless: hi, why does my pqm request say: "Request for non-PQM managed branch" at http://pqm.launchpad.net/ ?
[01:18] <salgado> carlos, are you using a bzr repo and the pqm-submit plugin?
[01:19] <carlos> no, I'm using a wave bzr repository and the old bzr-submit-merge script
[01:19] <carlos> it worked this morning
[01:20] <carlos> after the knit migration
[01:21] <salgado> odd
[01:22] <lifeless> I encourage you to switch to pqm-submit
[01:23] <salgado> lifeless, is there a workaround for bug 45306?
[01:23] <Ubugtu> Malone bug 45306 in bzr "LocationConfig should look for options on parent locations when they're not found" [Normal,Unconfirmed]  http://launchpad.net/bugs/45306
[01:24] <salgado> I think that's going to be a problem for people using pqm-submit and not manually rsyncing their branches up
[01:25] <lifeless> salgado: yeah, we should change that
[01:25] <lifeless> I think the workaround is 'write the code'
[01:25] <kbrooks> is the shipit code proprietary?
[01:26] <carlos> lifeless: is it included with bzrtools?
[01:26] <lifeless> SteveA: around ?
[01:27] <lifeless> carlos: no, I think that james's repository use page documents how to get it
[01:27] <salgado> gotta go now. be back in a few minutes
[01:27] <carlos> ok
[01:27] <kbrooks> is the shipit code proprietary?
[01:28] <kbrooks> is the shipit code proprietary?
[01:29] <carlos> kbrooks: yes, it is
[01:29] <kbrooks> carlos: why?
[01:29] <mpt> Gooooooooooooooooooooooooood morning Launchpadders!
[01:30] <kbrooks> hmm, i have a bug?
[01:30] <carlos> kbrooks: https://launchpad.net/faq <- Please, look at "Is Launchpad open source? Will it be?"
[01:30] <carlos> mpt: morning
[01:39] <carlos> lifeless: pqm-submit seems like fixed the issue, but the old request is stalled or at least, looks stalled
[01:40] <carlos> anyway... it's too late already here... and I missed the production update..
[01:40] <kbrooks> um, i have a bug, carlos 
[01:40] <carlos> I will continue tomorrow
[01:40] <carlos> kbrooks: where?
[01:41] <kbrooks> "3 CDs requested in 2006-01-01. 3 CDs approved and sent to the shipping company in 2006-01-03."
[01:41] <kbrooks> but I DID NOT request there cds on january 1, 2006
[01:41] <kbrooks> three*
[01:42] <carlos> kbrooks: please, file a but about it at https://launchpad.net/products/shipit/+bugs
[01:42] <kbrooks> OK.
[01:42] <carlos> kbrooks: thanks
[01:42] <carlos> good night!
[03:12] <stub> lifeless: was jubany acting up?
[03:13] <stub> ahhh - would have been the shipit rollout
[03:14] <lifeless> stub: I found the rollout instructions a little ... sparse.
[03:14] <lifeless> i.e. no db backup in there
[03:14] <lifeless> nor info on bouncing librarian/authserver etc.
[03:15] <lifeless> I've added some info and some nicer ways of doing things
[03:15] <stub> yup. db backup takes over an hour, so we need to rely on dailys now (and pitr when set up)
[03:15] <stub> well... cloneing the db would be faster, but still too slow
[03:15] <lifeless> well, we downed it and just copied the pg dir, took about 15 minutes
[03:16] <elmo> rsync it before and after should be faster tan 15 minutes
[03:17] <lifeless> elmo: sure. we were adhocing it - I woke up to a 'please rollout and stub is sick' email
[03:17] <stub> ahh good - you found push.py (work in progress but useful)
[03:17] <lifeless> stub: :)
[03:17] <lifeless> stub: the notes I have on the rollout page may be useful for commands push could run
[03:17] <stub> yup
[03:27] <Keybuk> kiko: those dups are still definitely getting created by the uploader
[03:27] <Keybuk> s/dups/strange sources/
[03:27] <Keybuk> a package that just added new binaries created them
[03:27] <Keybuk> I had a thought though
[03:27] <Keybuk> could this be a result of overrides?
[03:53] <lifeless> popping out for a bit
[03:54] <salgado> lifeless: is pqm still disabled?
[03:56] <mpt_> "-537 revision(s) pulled."
[03:56] <mpt_> heh
[04:03] <mpt_> !
[04:23] <jamesh> mpt_: your branch history was canonicalised
[04:23] <jamesh> mpt_: leading to a shorter revision history
[04:23] <mpt_> uh oh
[04:24] <mpt_> I just finished all the steps on RocketfuelToKnits
[04:24] <mpt_> And now I've merged rocketfuel into MaloneSimplifications
[04:24] <mpt_> and got a conflict
[04:25] <mpt_> and the conflict's MERGE-SOURCE is something that's from neither rocketfuel *nor* MaloneSimplifications
[04:25] <mpt_> it's from a separate branch
[04:26] <mpt_> spiv?
[04:27] <mpt_> Yes, now MaloneSimplifications branch is full of code from the other branch
[04:27] <mpt_> Is there a missing step 6 in those instructions?
[04:48] <mpt_> jamesh: any ideas?
[04:49] <jamesh> mpt_: what commands did you run exactly?
[04:50] <mpt_> Exactly the commands given on RocketfuelToKnits
[04:50] <mpt_> and then
[04:50] <jamesh> so what command produced the "-537 revision(s) pulled." message?
[04:50] <mpt_> 2006-03-MaloneSimplifications> bzr merge ../rocketfuel/
[04:51] <mpt_> The -537 was a long time beforehand
[04:51] <jamesh> if it was from the "bzr pull --overwrite" command, then that might be expected
[04:51] <mpt_> sure, you explained that
[04:52] <mpt_> I don't think it's related to my problem at all.
[04:52] <jamesh> it basically reports (# of revisions now - # revisions before)
[04:52] <jamesh> so bzr picked a weird merge base
[04:52] <mpt_> My problem is that my copy of rocketfuel now contains stuff from one of my branches.
[04:53] <jamesh> okay.
[04:53] <mpt_> Which doesn't really surprise me, since I used "bzr pull --overwrite" from the branches into rocketfuel
[04:54] <jamesh> when you were upgrading your branches, did you do the "bzr pull --overwrite" stuff onto a copy of rocketfuel-built, or the main copy you use?
[04:54] <mpt_> but when I asked about that yesterday, spiv and lifeless said it was fine
[04:54] <dilys> Merge to devel/launchpad/: [r=bjornt]  Fix bug #36420 (archive-cruft-check redesigned, old script kept for tests), fix bug #41600 (buildd-sequencer crashes, add socket_timeout config option), fix SPR.getBuildByArch() (using selectFirst properly), merge elmo's sync-source fixes. (r3568: Celso Providelo)
[04:54] <Ubugtu> Malone bug 36420 in qprocd "archive-cruft-check broken" [Critical,In progress]  http://launchpad.net/bugs/36420
[04:54] <mpt_> jamesh: I don't understand that distinction
[04:54] <mpt_> I keep one copy of rocketfuel-built to merge from. I don't change it directly.
[04:55] <jamesh> mpt_: when you do "bzr pull --overwrite foo", you are overwriting the branch history of the current branch with the history of "foo"
[04:55] <jamesh> so you'd be modifying rocketfuel-built
[04:55] <mpt_> I know
[04:55] <mpt_> that's why step 2 seems so strange
[04:56] <jamesh> if you've done all the upgrades, just rsync down rocketfuel-built again to get it back to normal
[04:56] <jamesh> step 2 says "Pull your branch into your rocketfuel-built (or a copy of it),"
[04:57] <mpt_> yep
[04:57] <mpt_> and when I went through this yesterday, I pointed out that this would mean that the second branch I did would end up with the history of the first and second branches
[04:58] <mpt_> and that the third branch I did would end up with the history of the first, second, and third branches, and so on
[04:58] <mpt_> and that that seemed strange
[04:58] <jamesh> there are two concepts of "history" here
[04:58] <mpt_> so was it wrong after all?
[04:58] <jamesh> see this picture: http://blogs.gnome.org/attachment/jamesh/2006/04/23/0/bzr-repo.png
[04:58] <jamesh> think of each of the nodes in the graph as a particular state of your source tree
[04:59] <jamesh> the blue line indicates the line of development you've taken in your branch
[05:00] <jamesh> and the collection of all the nodes includes stuff you've merged
[05:00] <jamesh> so with the instructions on the RocketfuelToKnits page, the last branch will contain the history of the other branches in the sense that those nodes will be in the branch's internal repository
[05:01] <jamesh> but it won't contain the history of those branches in the sense of the blue line indicating the line of development for the branch
[05:01] <mpt_> ok
[05:01] <jamesh> does that make things clearer or less clear?
[05:01] <jamesh> :)
[05:01] <mpt_> so the other branches now have records of the changes, but not the changes themselves
[05:02] <jamesh> the changes of your other branches wouldn't be in the linear branch history, no.
[05:02] <jamesh> the reason for the complicated steps on the RocketfuelToKnits page is that converting weave data to knits is expensive
[05:03] <jamesh> the already converted version of rocketfuel contains most of the tree states as your local branches in knit format
[05:03] <mpt_> So, RocketfuelToKnits is missing a final instruction: "When you've converted all your branches, rsync your copy of rocketfuel-built again so that it doesn't contain code from any of your other branches."
[05:03] <mpt_> Is that accurate?
[05:03] <mpt_> "rsync down", even
[05:04] <jamesh> so the "pull --overwrite" command just adds the missing nodes as knit data so it can trace the blue line for that branch
[05:04] <jamesh> which is cheaper
[05:04] <jamesh> that sounds accurate.
[05:12] <mpt_> thanks jamesh
[05:12] <mpt_> ok, next question:
[05:12] <mpt_> "To push a standalone knit branch to chinstrap the first time..."
[05:12] <mpt_> Is that necessary for existing branches, or just newly-created ones?
[05:14] <spiv> mpt_: sorry, was afk for a bit.  You and jamesh are right, I'll update the instructions.
[05:14] <spiv> Oh, someone beat me to it :)
[05:14] <jamesh> mpt_: after having upgraded your branch to knit format, basically all the revision control files have changed
[05:14] <mpt_> :-)
[05:15] <jamesh> mpt_: if you don't mind pushing 200MB+ for each branch, you can ignore it :)
[05:15] <mpt_> oh, so I should do it anyway
[05:15] <jamesh> the idea is to put something similar to the branch in place on chinstrap, so that when you rsync your branch you are only sending the differences
[05:16] <mpt_> assuming that the changes in each of my branches are less than 200 MB :-)
[05:16] <mpt_> right
[05:16] <spiv> mpt_: "bzr push" will preserve the format of an existing branch, so it would push your local knit branch to a remote weave branch if it already existed, which would be massively slow.  So you should do it for every converted branch you want to push.
[05:16] <mpt_> ok
[05:16] <mpt_> so maybe it should be step 6?
[05:16] <jamesh> spiv: good point. Hadn't thought of that ..
[05:17] <spiv> Probably, I only added that note quickly last night before I went to bed.
[05:18] <mpt_> spiv, and it has an error
[05:18] <spiv> Ideally, we'd use repositories...
[05:18] <mpt_> bash: /home/warthogs/archives/rocketfuel.knits/launchpad/devel/: is a directory
[05:18] <mpt_> stray slash?
[05:18] <mpt_> two stray slashes?
[05:18] <jamesh> mpt_: did you do "cp" or "cp -a"?
[05:19] <mpt_> ahaha
[05:19] <mpt_> I did "-a"
[05:19] <spiv> The trailing slash shouldn't matter.
[05:19] <mpt_> Yes, the problem wasn't the missing "-a", it was the missing "cp"
[05:19] <spiv> Oh, right :)
[05:20] <jamesh> mpt_: thanks for cleaning up some of the text on the WokringWithSharedRepositories page
[05:22] <mpt_> Well, lifeless asked me to read it, so I was just practising
[05:30] <mpt_> "bzr: WARNING: This transport does not update the working tree of: sftp://chinstrap.ubuntu.com/home/warthogs/archives/mpt/launchpad/trivial/"
[05:30] <mpt_> Then what *does* it update?
[05:32] <jamesh> the repository data and the branch data
[05:32] <jamesh> i.e. the stuff that pqm cares about
[05:32] <mpt_> ok
[07:01] <mpt__> lifeless: When will PQM be available again?
[08:09] <mpt> "bzr: ERROR: Parent directory of sftp://chinstrap.ubuntu.com/warthogs/archives/mpt/launchpad/2006-03-MaloneSimplifications/ does not exist."
[08:10] <spiv> mpt: That's right.
[08:11] <spiv> mpt: You're missing a /home
[08:11] <mpt> a-ha
[08:12] <spiv> It would be nice if it said which part of the path specifically was causing the problem...
[08:12] <spiv> Although I think that's hard to do 100% correctly, because it optimistically tries the full thing, and the error the SFTP server sends doesn't contain that information.
[08:15] <mpt> spiv: If you're using --overwrite, what's the point of the ssh chinstrap cp... before it?
[08:16] <spiv> mpt: overwrite won't make it push what's already there.
[08:16] <mpt> So how does --overwrite differ from not overwriting?
[08:17] <mpt> "Ignore differences between branches and overwrite unconditionally"
[08:17] <spiv> It just tells it to continue even if the branch you are pushing to has a different history to yours.
[08:17] <mpt> ah
[08:17] <mpt> and knits vs. weaves = different history
[08:18] <spiv> Specifically, if the rocketfuel you cp from is more recent than when your branch branched off rocketfuel, the push would refuse to work without --overwrite.
[08:18] <spiv> Because you would be overwriting revisions that aren't in the branch you're pushing.
[08:18] <spiv> It's not about knits vs. weavs.
[08:19] <spiv> weaves, rather.
[08:19] <mpt> ok
[08:19] <spiv> It's about bzr refusing to overwrite revision 1234 with a different revision 1234 by default.
[08:20] <spiv> The help for --overwrite probably ought to be clearer that it's talking about overwriting revision history, rather than talking about just blinding sending everything.
[08:21] <spiv> s/blinding/blindly/
[08:22] <spiv> Or a repository, I should say...
[08:29] <mpt__> spiv: I lost my Internet connection while pushing, and now I get "bzr: ERROR: Lock error: File 'branch-lock' already locked"
[08:29] <mpt__> Should I just delete that file?
[08:29] <spiv> mpt__: try the "bzr break-lock" command.
[08:30] <spiv> I've never bumped into this myself, though, so I'm just making educated guesses :)
[08:38] <jamesh> spiv: one thing to note: doing an sftp push of a branch inside a shared repository can cause some sections of the ~/.bazaar/branches.conf file to be shadowed (if you use the pqm-submit config I gave on the WorkingWithSharedRepositories page)
[08:39] <BjornT> SteveA: ping
[08:39] <jamesh> it creates an entry for $repository/$branchname giving the push location, and bzr doesn't look at sections for parent directories
[08:41] <SteveA> BjornT: hi
[08:41] <Keybuk> hi guys,
[08:42] <SteveA> hello scott
[08:42] <Keybuk> just to give you an idea of the problem caused by that "sourcepackagenames exist for things that aren't source packages" bug
[08:42] <Keybuk> http://people.ubuntu.com/~scott/reports/unpublished.html
[08:42] <Keybuk> we've got 182 bugs assigned to them at the moment :-/
[08:42] <BjornT> hi SteveA. just wanted to make sure you were awake. i'm leaving my place now, so i'll be at your place in 20 minutes or so depending on traffic.
[08:44] <SteveA> okay, fine
[09:03] <mpt__> hmm, that didn't work
[09:04] <Keybuk> do people in here know about schooltool ?
[09:05] <lifeless> fsvo about
[09:05] <mpt__> bah
[09:06] <Keybuk> lifeless: it's sitting in main, but begging to be moved to universe
[09:06] <lifeless> its python right ;)
[09:07] <lifeless> SteveA is probably the most aware of the circumstances/policy about it
[09:07] <Keybuk> it doesn't appear to be seeded anymore
[09:07] <SteveA> hello scott
[09:07] <Keybuk> don't know if it ever has been
[09:07] <SteveA> i know a little about schooltool
[09:07] <lifeless> its a tool
[09:07] <lifeless> for schools.
[09:07] <lifeless> ^ a little ^
[09:07] <sivang> morning all
[09:08] <Keybuk> hmm, that's odd actually
[09:08] <Keybuk> edubuntu-server depends on it
[09:08] <SteveA> i haven't followed recent development
[09:08] <Keybuk> oh,
[09:08] <Keybuk> school*bell*
[09:08] <Keybuk> what's that one? :p
[09:08] <SteveA> schoolbell is a product based on schooltool, a cut-down version that just does calendaring
[09:09] <jsgotangco> hmm that's odd if ubuntu-server depends on them
[09:09] <SteveA> rather than calendaring + attendance for schools + other schools stuff
[09:09] <Keybuk> ok, it's that that's fallen out
[09:09] <Keybuk> I should probably just seed it somewhere, yes?
[09:10] <Keybuk> it should be in main and not universe?
[09:10] <SteveA> i guess so.
[09:10] <SteveA> ubuntu is the primary distribution channel for schooltool
[09:11] <Keybuk> it looks like schooltool used to depend on schoolbell
[09:11] <SteveA> jinty would know more
[09:14] <SteveA> mpt: hello
[09:15] <stub> Bah - 14kb/s from chinstrap via ssh :-(
[09:15] <Keybuk> yeah chinstrap is poorly today
[09:15] <SteveA> jamesh: we're due to have a call sometime soon, to talk about review processes
[09:16] <Keybuk>  08:15:55 up 89 days, 15:27,  5 users,  load average: 5.58, 4.91, 4.49
[09:16] <SteveA> Keybuk: what's up?
[09:16] <jamesh> SteveA: yeah.
[09:16] <jamesh> Keybuk: we did the knit upgrade yesterday, so I guess everyone's branches are churning
[09:16] <Keybuk> that's what I figured
[09:17] <SteveA> you mean, lots and lots of rsync and disk IO?
[09:17] <SteveA> what does user archvsyn do?
[09:21] <SteveA> jamesh: so, skype call?
[09:22] <jamesh> seems to be rsyncing launchpad logs from gangotri
[09:22] <jamesh> SteveA: okay
[09:24] <lifeless> top shouls 87 % in IO wait
[09:24] <lifeless> *shows*
[09:25] <lifeless> bzr conversions are memory hungry, but there is no python in top-sortyed-by-memory
[09:25] <lifeless> lots of rsyncs though ;)
[09:25] <lifeless> however, I think aide is the culrpit
[09:27] <freeflying> need help. can not sign COC  error:str: The signed text does not match the Code of Conduct. Make sure that you signed the correct text (white space differences are acceptable).
[09:28] <carlos> morning
[09:29] <freeflying> carlos: hi, why can't Isign coc now? thx
[09:30] <carlos> freeflying: I guess your problem could be https://launchpad.net/products/launchpad/+bug/39547
[09:30] <Ubugtu> Malone bug 39547 in launchpad "Code of Conduct 1.0.1 signatures not accepted" [Critical,Confirmed]  
[09:30] <carlos> SteveA: hi, around?
[09:31] <freeflying> carlos: thx, just the same
[09:40] <mpt> hi SteveA 
[10:09] <SteveA> spiv: hello
[10:09] <spiv> SteveA: hi
[10:09] <SteveA> spiv: shall we have a skype call?
[10:09] <spiv> Sure.
[10:13] <carlos> SteveA: mark's branch was rejected (and anyway, I was late for the rollout)
[10:13] <carlos> SteveA: I'm doing the knit migration to merge rocketfuel into that branch and solve any conflict I find
[10:23] <stub> Using sftp, will the 95Mb inventory.knit need to be pushed in entirety?
[10:24] <lifeless> stub: no
[10:24] <lifeless> stub: the 2M index is downloaded, the new data calculated, and then appended to the inventory.knit and new index entries appended to the index.
[10:25] <stub> But can you do that on push with sftp?
[10:25] <lifeless> I'm describing what sftp push with knits does.
[10:25] <lifeless> What are you asking?
[10:27] <stub> I didn't think you could append with sftp. I'm wondering if I bzr push an updated branch to update a previous push, using sftp, if the entire inventory.knit will need to be shoved up ?
[10:28] <lifeless> sftp supports append
[10:28] <stub> ok
[10:28] <lifeless> what will happen is that the 2M index is downloaded, the new data calculated, and then appended to the inventory.knit and new index entries appended to the index.
[10:29] <carlos> stub: hmmm, I see my branch with the needs-reply status... but I didn't get any email with the review
[10:30] <stub> I'll resend
[10:30] <carlos> could you resend it, please?
[10:30] <carlos> thanks
[10:30] <carlos> stub: are you working today, or still sick?
[10:30] <stub> working
[10:31] <carlos> ok, could you take a look to my email about the DELETE SQL commands?
[10:31] <carlos> stub: we should run all those SQL commands as soon as possible to close that issue with Kurdish
[10:31] <stub> resent
[10:34] <carlos> stub: got it, thanks
[10:35] <Yannig> Hello everybody :)
[10:36] <carlos> stub: btw, I sent you an email to have a meeting to talk about the RSS feature that will use that new API
[10:36] <carlos> stub: when would you have time to have such meeting?
[10:36] <stub> carlos: I have two patches from you, one with a number of updates and a single delete. And another with just deletes. Both need to run?
[10:37] <carlos> that will answer some of your questions raised on that review email
[10:37] <stub> carlos: Now if you like.
[10:37] <carlos> stub: the second on with deletes is a modification of the single DELETE in the first patch
[10:37] <carlos> s/on/one/
[10:37] <stub> ok. So only run the updates from the first patch, and all the deletes from the second
[10:38] <carlos> stub: well, you can just execute the first one
[10:38] <carlos> stub: but the delete is really, really slow
[10:38] <carlos> I rewrote it with 25 differente deletes to reduce the amount of time we would have the table locked
[10:38] <carlos> but it's still too slow
[10:39] <carlos> if you could give me a hint to reduce its execution time...
[10:39] <carlos> SteveA: do you have time now to talk about the RSS feature with stub?
[10:39] <stub> It will be slow - it is a big table.
[10:39] <carlos> Yannig: hi
[10:39] <carlos> stub: will that lock Rosetta?
[10:39] <stub> Maybe
[10:40] <SteveA> even if you run it with no isolation?
[10:40] <SteveA> oh, you're not talking about the RSS output being slow
[10:40] <stub> SteveA: The individual queries will each take a few minutes.
[10:41] <SteveA> you're talking about the update sql patch thing being slow
[10:41] <carlos> SteveA: no, sorry, talking about data migration too
[10:42] <SteveA> i can talk about RSS now
[10:42] <carlos> ok
[10:42] <stub> So I said we need a mockup of the RSS feed we are after, and then I could review the appropriateness of the API.
[10:43] <carlos> stub: the idea is to prepare an RSS feed with latest updated POTemplate
[10:43] <stub> I'm not sure what sort of an RSS feed people wanted by reverse engineering the API changes
[10:43] <carlos> that way, translators would subscribe to it to know when new strings appear
[10:44] <stub> That is vague. We need a mockup. Just .txt will do
[10:44] <SteveA> carlos: so, can you prepare a short amount of text, in a chinstrap pastebin
[10:44] <SteveA> that explains what you want to see in an RSS reader?
[10:44] <SteveA> like 
[10:44] <carlos> so the RSS feed would use IPOTemplate.title as its title and the URL canonical_URL(potemplate)
[10:44] <SteveA> --------
[10:44] <carlos> sure
[10:44] <SteveA> 11 July 2006: Foo uploaded whatever <--- link to http:///.....
[10:44] <SteveA> By John Smith
[10:44] <SteveA> Whatever
[10:44] <SteveA> --------
[10:44] <SteveA> etc.
[10:47] <carlos> SteveA, stub: https://chinstrap.ubuntu.com/~dsilvers/paste/fileA8eN9F.html
[10:48] <carlos> I guess it would be more or less that way
[10:48] <carlos> all that information is stored inside the POTemplate object
[10:48] <carlos> and the API I added is returning a list of all POTemplates we have
[10:49] <stub> So we will have an RSS feed per (distribition, sourcepackage), or is it just coincidence that your mockup only contains one sourcepackage?
[10:49] <carlos> leaving to the RSS feed code the decision of the amount of potemplates to show
[10:50] <ddaa> hello
[10:50] <carlos> stub: well, I wrote it so we could have an RSS feed for the whole system and others specific to a distrorelease, a productseries or a distrorelease and sourcepackagename
[10:50] <carlos> stub: it depends on the context object we use, IPOTemplateSet or IPOTempalteSubset
[10:51] <carlos> ddaa: hi
[10:52] <stub> I'll need to go over your code and estimate how expensive it is doing these queries on request. I suspect we will need to refactor it to use events and a message store similar to what was specced for RSS feeds in Brazil.
[10:54] <carlos> stub: I added the new field to the POTemplate object so we only need to use one table to get the information and reduce the query time
[10:54] <carlos> the new field is a cached value with the last date when it was updated
[10:54] <carlos> so I guess it depends on the amount of potemplates we have in our database
[10:58] <SteveA> stub: this is meant to be a quick fix for a communication problem we have right now
[10:58] <SteveA> so, if it will work, i'd like to get something out without refactoring, then refactor later
[10:59] <stub> What does 'updated template' actually mean might have happened?
[10:59] <SteveA> (that is, assuming that refactoring is time consuming)
[11:00] <carlos> stub: we got a .pot upload into the system
[11:01] <carlos> stub: that is newer than the previous upload
[11:01] <carlos> so we accepted it to be imported into the system
[11:01] <stub> A pot upload will not delete the previous pot? The old one is still there?
[11:02] <carlos> well, not delete but update
[11:02] <carlos> will add/remove strings from the previous one
[11:03] <stub> I'm more interested in what a user sees if their RSS reader is polling every 60 minutes, and several uploads of the same potemplate were made during that period.
[11:04] <carlos> only the latest one will appear
[11:04] <carlos> so yes, it's a removal from that point of view
[11:07] <stub> Will the new POTemplate get a new id?
[11:07] <carlos> no
[11:08] <stub> This is making the RSS feed generator much more complex, and only applicable to this particular feed - it will need rewriting for future feeds.
[11:09] <stub> Each article will need a unique, unchanging id. We can't use the id's we have in the database, as they are mutating. And we also have to store publication dates and such too.
[11:09] <SteveA> stub: so, you think using an events-table would be simpler?
[11:10] <stub> An events table will mean the feed generator will work on anything that can fill in a similar structure, and the table will also be usable for emailing noifications, or pushing notifications out via other means such as IRC or Jabber.
[11:10] <carlos> stub: I don't understand this... you say that we need a unique ID
[11:10] <stub> We need an events table anyway to store the information the RSS feed needs to be stable (article ids etc)
[11:10] <carlos> and we have such unique IDs
[11:11] <carlos> but you also say that they will be mutating... why?
[11:11] <carlos> potemplate.id will not change at all
[11:11] <stub> Each article in an rss feed has a publication date, an id, title, and content. The id can't change. The publication date can't change (there is a different field for last changed).
[11:12] <stub> So if you upload a potemplate 3 times, each article generated needs a stable and unique id and publication date.
[11:12] <carlos> we have that
[11:12] <carlos> potemplate.datecreated could be used as publication date
[11:13] <carlos> and then potemplate.date_last_updated as the last changed
[11:13] <carlos> would that be enough?
[11:13] <carlos> ony date_last_updated will be changed with every update
[11:14] <stub> That might work. It depends on if the readers support last changed well.
[11:14] <stub> I'll go over the RSS2.0 spec again quickly...
[11:15] <carlos> ok
[11:15] <stub> What you are suggesting is we only ever publish a single feed item per potemplate, but update the information on each upload.
[11:16] <carlos> if that's possible, yes
[11:16] <carlos> I know nothing about RSS details
[11:16] <carlos> so I'm not sure if that's possible or not
[11:22] <stub> Hmm... no date changed in RSS. That must be Atom I was thinking of.
[11:23] <stub> It might be possible to generate a guid using the POTemplate.id and last_changed - that should cover things.
[11:25] <carlos> stub: could I do anything to help there?
[11:27] <stub> Nah.
[11:29] <carlos> ok
[11:30] <carlos> I will apply your review changes
[11:30] <stub> Just need to figure out caching of the feed, so it only gets regenerated evey 30 mins or so.
[11:34] <stub> So we don't want to generate the feed on the fly, or we reward people who set their refresh time to tiny amounts.
[11:34] <stub> We can't pregenerate the feeds and serve them of the filesystem via Apache as there are too many of them.
[11:34] <stub> We could use Squid to serve and cache the RSS feeds, but that adds another moving part to the Launchpad production environment.
[11:35] <stub> Probably the best option is to cache in the main PostgreSQL database.
[11:37] <stub> I'm still leaning towards maintaining an events table as described in https://wiki.launchpad.net/RssFeeds personally
[11:37] <SteveA> we can cache rss in apache
[11:38] <SteveA> but...
[11:38] <SteveA> stub: if you want to implement RssFeeds, it looked mostly fine to me.  it needs a little updating though.
[11:40] <uws> rss feeds are pretty straightforward to implement most of the time (i've done in several webapps)
[11:53] <SteveA> ANNOUNCEMENT: launchpad development meeting in 2 hours.
[11:53] <SteveA> now is a good time to ensure your activity reports are up to date.
[11:53] <stub> carlos: The code is setting potemplate.last_update_date instead of potemplate.date_last_updated
[11:54] <carlos> stub: really? hmmm, I wonder if I forgot to run tests after that change...
[11:54] <stub> carlos: I'm curious as to why we are setting it in the getLastTranslator method (a hidden side effect), and setting it to whatever was specified in the templates headers instead of the current time.
[11:55] <carlos> stub: it's not done inside getLastTranslator...
[11:55] <carlos> stub: it's done inside import_po
[11:55] <stub> Yer - misreading diffs.
[11:56] <carlos> stub: about the value... that date is the actual date when the pot file was generated
[11:56] <carlos> there could be a newer version with a newer date
[11:56] <stub> But we can't rely on it because it is user input. Or at least we can't rely on it to be the actual time it was last modified.
[11:57] <carlos> well, it's supposed to be updated on .pot generation time
[11:57] <carlos> not manually handled by the user
[11:57] <carlos> but gettext
[11:58] <stub> We are still trusting the remote environment and people to work the way you expect them to (rather than the way they want to, which might be different)
[11:58] <carlos> the user handled field is for .po files not .pot files
[11:58] <carlos> stub: right
[11:58] <carlos> stub: so you think we should use current time instead?
[11:59] <carlos> ok, I see your point and is a good concern
[11:59] <carlos> will do it that way
[11:59] <stub> It all depends on what you want date_last_updated to store. If you want it to store the value from that header, it probably should be renamed and I can't rely on it for RSS feed generation (so we will still need a date_last_updated set to CURRENT_TIMESTAMP anyway)
[12:00] <stub> We definitely want a limit argument passed into the new methods, which is propagated through to the select() calls.
[12:01] <stub> Which I guess means the methods should also be renamed, removing the 'All'
[12:02] <ddaa> carlos: re users-don't-read
[12:02] <ddaa> carlos: maybe the default for that selector should be "I don't know", then
[12:04] <stub> Or If I do foo.select(blah)[:200] , does that issue the SQL with a LIMIT command? 
[12:05] <stub> c/command/clause/
[12:06] <stub> Geez... my rocketfuel-built rsync is still syncing. 3 hours!
[12:07] <ddaa> yowzer, it would probably have been faster for you to download it as a tarball
[12:08] <ddaa> interesting
[12:08] <ddaa> just compared rsync and nested-pull (a trivial script that does pull on every nested tree) for rocketfuel built
[12:08] <ddaa> rsync ran in 1 min 30s
[12:08] <ddaa> pull ran in 1 min 20s
[12:09] <ddaa> (wallclock time)
[12:10] <carlos> stub: it should, yes
[12:11] <carlos> stub: I'm returning a selectresult
[12:11] <stub> carlos: No need for the limit argument - slicing the select results issues the SQL with the LIMIT
[12:11] <stub> ok
[12:11] <carlos> stub: about the date field, I will do what you suggest, that field is specific for the RSS feature
[12:11] <carlos> no need to have the header value parsed
[12:12] <stub> ok. Will it get updated if someone uploads an identical potemplate?
[12:12] <carlos> ddaa: it's already the default
[12:12] <ddaa> hehe hehe hehe
[12:12] <stub> The TranslationSubscriptions spec was using a checksum to detect rather than a timestamp.
[12:12] <ddaa> carlos: okay, that why this quote is funny
[12:12] <carlos> stub: yes, it will be updated
[12:12] <ddaa> it's not obvious from just the quote
[12:12] <carlos> ddaa: ;-)
[12:13] <carlos> ddaa: ok, I will update it to show that fact
[12:13] <carlos> ;-)
[12:13] <stub> carlos: Do we care if we tell users that the template was updated when it actually hasn't been modified at all in this particular case? I suspect it wouldn't happen often?
[12:14] <stub> Will we ever be doing bulk potemplate uploads that could cause this case?
[12:14] <carlos> stub: I think is ok to do it that way until we implement the checksum thing you noted
[12:14] <stub> ok
[12:15] <stub> carlos: I think we can run with what we have after you have fixed the naming of the column and the typo I mentioned earlier. If we want to make the feed richer though (eg. '44 new message id's added, 12 removed' etc.) we will need to refactor.
[12:16] <carlos> yeah, I know
[12:16] <carlos> but the idea is to provide a basic functionality, so it's ok to go with what we have atm
[12:17] <stub> SteveA: Are you sure our Apache is capable of caching?
[12:18] <SteveA> i'm sure it can be made so by the admins
[12:18] <SteveA> they've done it for the wiki sites
[12:18] <stub> Cool. If they are doing the wikis, a few thousand RSS feeds shouldn't be a burden.
[12:18] <lifeless> if apache can't, we can always stuff squid in front
[12:19] <lifeless> :)
[12:19] <SteveA> they're doing the ubuntu website, which is a moin wiki
[12:19] <stub> lifeless: This is a quick hack. I've got other plans for doing this properly ;)
[12:19] <lifeless> 2.6 is coming out very soon, with all the rproxy stuff in it. going to rock.
[12:20] <carlos> stub: Could you give me a patch number for my db patch?
[12:20] <carlos> stub: also, I assume that with the two changes you noted, I can request a merge into rocketfuel, right?
[12:21] <stub> The db patch also needs an index added -- CREATE INDEX potemplate__date_last_updated__idx ON POTemplate(date_last_updated);
[12:23] <stub> carlos: patch-40-56-0.sql
[12:23] <carlos> ok
[12:23] <carlos> thanks
[12:23] <stub> r=stub
[12:23] <jamesh> mpt: have you seen this? http://code.google.com/webtoolkit/
[12:23] <stub> carlos: And file a bug for the RSS feeds so it doesn't get dropped
[12:24] <carlos> stub: ok
[12:24] <carlos> thanks
[12:25] <SteveA> jamesh: hah -- they implemented menus
[12:25] <jamesh> SteveA: among other things, it lets you write code in Java and it translates it to javascript
[12:25] <stub> Sounds similar to mochikit, but in Java.
[12:25] <jamesh> SteveA: letting you use Java development tools to debug/test the code
[12:27] <SteveA> i see
[12:35] <SteveA> BjornT: lunch?  ili pica across the road is quick and kinda edible
[12:36] <BjornT> SteveA: sure, sounds good.
[12:41] <ddaa> stub: is there a config for the recently rolled out code?
[12:42] <lifeless> ddaa: I did not update any configs.
[12:42] <ddaa> the branch-scanner config has been broken since the last rollout, but the last time I fixed it in place because there was not a production config and because merging anything was way too much pain anyway
[12:42] <lifeless> ddaa: was not in the RolloutProcedure
[12:43] <ddaa> I'll add it then.
[12:49] <ddaa> lifeless: updating the config should happen when creating the production branch
[12:50] <ddaa> but the "create the new production branch" step is not in LaunchpadRollout
[12:50] <ddaa> so I cannot add the "update the config" step
[12:51] <lifeless> ddaa: so add both!
[12:51] <ddaa> mh, thought that "create the production branch" bit was somewhere else
[01:15] <cprov> good morning, guys
[01:18] <carlos> cprov: hey!
[01:19] <cprov> carlos: yo, how is it going ?
[01:19] <carlos> burning my hard drive and my DSL line with the knits migration ;-)
[01:22] <cprov> carlos: it's worth, I would not think twice, it's much faster 
[01:22] <carlos> yeah
[01:22] <ddaa> I'm sure we'll find something to bitch about, in time
[01:22] <carlos> I'm converting branches as soon as I need to merge from rocketfuel
[01:22] <ddaa> but right now, it feels great
[01:22] <carlos> ddaa: but not now ;-)
[01:35] <Yannig> I don't if you saw it when I told it last night but the Untranslated strings number does not change anymore since the server update (example: https://launchpad.net/distros/ubuntu/dapper/+lang/oc/)
[01:36] <Yannig> (only the general one: the counter for each template works fine)
[01:36] <carlos> Yannig: those values are cached ones and I think they are updated once per day
[01:37] <carlos> so don't expect to get real time updates for it
[01:38] <Yannig> Fair enough :)
[01:39] <Yannig> So I'll stick to 99,62 % untranslated today :D
[01:40] <SteveA> launchpad meeting in 18 mins
[01:41] <carlos> Yannig: I guess... not sure if it's executed more often
[01:41] <carlos> stub: ?
[01:41] <carlos> stub: talking about the cron job that update the cached statistics
[01:41] <stub> eh?
[01:41] <carlos> I don't remember how often is it executed
[01:41] <Yannig> carlos> I thought it was done at once befoce yesterday, that's why (but I don't really mind, it's just stats :))
[01:41] <stub> daily
[01:42] <carlos> Yannig: perhaps yesterday's update was not executed due the production update
[01:43] <Yannig> I should be able to survive :)
[01:43] <carlos> Yannig: no, the update was executed today "They were last generated on 2006-05-18 at 07:20:57 CEST."
[01:44] <carlos> Yannig: you can see it at https://launchpad.net/rosetta on the left portlet
[01:44] <Yannig> OK
[01:44] <Yannig> Thanks a lot :)
[01:50] <cprov> stub: ping
[01:50] <stub> pong
[01:51] <cprov> stub: could you, please, copy a new production backup to mawson ?  don't override the current launchpad_dogfood DB right now
[01:51] <SteveA> meeting in 7 mins
[01:51] <stub> ok
[01:51] <SteveA> i'm going to take a workrave
[01:51] <cprov> stub: thank you 
[01:54] <cprov> stub: btw, could you double check the indexes are correcly installed, I suspect the last copy hasn't proper index, because the performance on publisher was much lower than production. I didn't have time to investigate it properly, though.
[01:55] <stub> You would have seen errors when restoring from the backup. Most likely, it is because production is running on 4 fast dual core AMD 64's with 32GB of RAM, and mawson isn't.
[01:57] <cprov> stub: yes, propably (with sarcasm :)
[01:57] <carlos> stub: hmm what are you going to do with the SQL commands to migrate data that I gave you?
[01:57] <carlos> are you going to execute it on production?
[01:58] <stub> carlos: run them ;) I'll kick it off in a tick and we can see if rosetta is affected.
[01:59] <carlos> lifeless: I cannot believe it... did you added the Hackergotchi images to pqm.launchpad.net? dude!! that's sooo sweet (well, the links are broken, but I love the idea :-P)
[01:59] <carlos> stub: ok, thanks
[01:59] <lifeless> looks like a quoting bug
[01:59] <lifeless> its just test output
[01:59] <SteveA> hello
[01:59] <lifeless> probably failing tests
[02:00] <SteveA> LAUNCHPAD DEVELOPERS MEETING
[02:00] <carlos> lifeless: ooh... well, it's a good idea anyway ;-)
[02:00] <SteveA> welcome to this week's launchpad development meeting
[02:00] <SteveA> starting at 3.01pm sharp, vilnius time
[02:00] <SteveA> who is here today?
[02:00] <mpt> me
[02:00] <malcc> me
[02:00] <bradb> me
[02:00] <ddaa> me
[02:00] <carlos> me
[02:00] <BjornT> me
[02:00] <lifeless> oi oi oi
[02:01] <cprov> me
[02:01] <spiv> me
[02:01] <stub> me
[02:01] <jamesh> me
[02:01] <salgado> me
[02:01] <Yannig> I'm here too, but I may not be necessary :p
[02:01] <kiko> me
[02:02] <matsubara> me
[02:02] <SteveA> jordi: ?
[02:02] <kiko> how is everyone?
[02:02] <malcc> I tried to switch on my brain this morning, it said: No swap space
[02:02] <stub> sore
[02:02] <malcc> Other than that, fine :)
[02:02] <mpt> I made the mistake of having a nap, and I started dreaming about Launchpad
[02:03] <SteveA> never the second clown, don't you?
[02:03] <SteveA> == Agenda ==
[02:03] <SteveA>  * Roll call
[02:03] <SteveA>  * Agenda
[02:03] <SteveA>  * Next meeting
[02:03] <SteveA>  * Activity reports
[02:03] <SteveA>  * Actions from last meeting
[02:03] <SteveA>  * Launchpad oops milestone report
[02:03] <SteveA>  * Outstanding sysadmin requests
[02:03] <SteveA>  * Production and staging (stub)
[02:03] <SteveA> ----
[02:03] <SteveA>  * Are we all using bzr and bzrtools from dapper (kiko)
[02:03] <SteveA>  * Status of bugwatches work (bjorn)
[02:03] <SteveA>  * Result of converting to knits (steve)
[02:03] <SteveA> ----
[02:03] <SteveA>  * Keep, Bag, Change
[02:03] <SteveA>  * Three sentences
[02:03] <SteveA> 
[02:03] <SteveA> next meeting, same time next week
[02:04] <kiko> let's have it at midnight UTC!!11!
[02:04] <kiko> ok let's have it at the same time as usual then
[02:04] <SteveA> it is done
[02:04] <jamesh> mpt: that's like midday for you
[02:05] <SteveA>  * activity reports
[02:05] <mpt> up to date
[02:05] <ddaa> uptodate
[02:05] <kiko> as usual
[02:05] <BjornT> up to date
[02:05] <salgado> up to date
[02:05] <bradb> up to date
[02:05] <cprov> up to date
[02:05] <jamesh> sent a summary for this week
[02:05] <matsubara> up to date
[02:05] <spiv> up to date
[02:05] <lifeless> up to date
[02:05] <SteveA> i sent a summary of my activity this week, so if i send today's i'll be back on the straight and narrow
[02:05] <malcc> up to date
[02:05] <stub> up to date
[02:05] <carlos> up to date
[02:06] <malcc> Yay woo, go us, we rock, etc.
[02:06] <SteveA> is that a full house (allowing for summaries?)
[02:06] <SteveA> cool
[02:06] <SteveA> well done everyone
[02:06] <carlos> jordi: up to date
[02:06] <SteveA> jamesh: be sure to send in today's activity report
[02:06] <SteveA> thanks carlos 
[02:07] <SteveA>  * Actions from last meeting
[02:07] <SteveA>  * '''kiko''' to talk to bzrtools and bzr packagers to sort out this nonsense
[02:07] <kiko> it's been done as you saw via email
[02:07] <SteveA> do we have consistent compatible bzr and bzrtools in dapper now?
[02:07] <SteveA> yay
[02:07] <kiko> has everyone upgraded to bzr-in-dapper?
[02:07] <SteveA>  * Launchpad oops milestone report
[02:07] <SteveA> matsubara: take the floor!
[02:07] <kiko> oops jumped the gun
[02:07] <matsubara> We're seeing bugs like 1887 and 44834 (Out of order SQL queries). stub, spiv?
[02:08] <SteveA> bug 1887
[02:08] <SteveA> bug 44834
[02:08] <matsubara> where's ubugtu when we need it?
[02:08] <spiv> I wish I had even half a clue about how that happens.
[02:08] <matsubara> both a private
[02:08] <matsubara> s/a/are
[02:08] <SteveA> I'd like Ubugtu to give the bug URL nonetheless, in these cases 
[02:08] <stub> Haven't looked further into this. As far as we can tell, it is impossible. It has not been reproduced in a controlled environment.
[02:09] <matsubara> so, I should just ignore it when it hits the oops report?
[02:09] <SteveA> would having the value of locals up the stack be any help diagnosing this from oopses?
[02:09] <SteveA> or any other particular diagnostic data?
[02:09] <kiko> could it be server overload?
[02:09] <matsubara> what can I do that might help?
[02:09] <salgado> can't this be the same issue with the merge people test that is failing randomly?
[02:09] <stub> I'm at a bit of a loss on what we can do to debug this further.
[02:09] <stub> salgado: Yes - quite likely.
[02:10] <SteveA> kiko: i don't think so.  it seems like a correctness issue.
[02:10] <SteveA> correctness shouldn't suffer when the server gets loaded
[02:10] <spiv> kiko: I'd say only if postgres has extremely wierd and subtle bugs.
[02:10] <SteveA> although, perhaps it could be that python does more gc when memory is tight
[02:10] <kiko> mmmm. yeah, but maybe it happens only when there is pressure on the server. random guess, anyway
[02:10] <SteveA> not sure about that though
[02:10] <SteveA> or if there's more blocking on IO
[02:10] <SteveA> so more time to do gc
[02:11] <kiko> having the loadavg would be ideal in the OOPS report
[02:11] <kiko> it's clear that out
[02:11] <spiv> It's interesting that it only tends to affect certain pages, rather than randomly victimising everything.
[02:11] <jamesh> IIRC, the Python GC is only triggered by creating/deleting objects
[02:11] <kiko> of course, having  the loadavg of the /database box/ may be even more useful
[02:11] <kiko> spiv, well, the pages which are used the most, it appears, no? standard statistical spread?
[02:11] <spiv> jamesh: And calling gc.collect(), but otherwise that's my understanding too :)
[02:11] <SteveA> i don't think it is a database box issue -- i think it is more likely that sqlobject makes things less correct
[02:11] <SteveA> than we have a correctness problem in postgres
[02:12] <stub> kiko: loadavg will not be interesting. cpu utilization maybe, but my gut feeling is that this isn't a client issue.
[02:12] <jamesh> Given the way the SQL statement log is recorded, it can't be a multithreading issue
[02:12] <SteveA> stub: isn't a client issue?
[02:12] <jamesh> it only records statements from one thread
[02:12] <spiv> kiko: Hmm, I don't think so, there isn't enough randomness to the victims.
[02:12] <kiko> spiv, +translate is the usual victim, no?
[02:12] <stub> SteveA: Unless our logging is screwed - IIRC when I checked, the queries were being sent correctly to the server.
[02:12] <kiko> which is by far the most hit page
[02:12] <kiko> which does writes anyway
[02:12] <SteveA> stub: i'd like to have a voice call with you about this after the meeting
[02:13] <matsubara> kiko: yes, but it happened too in +editstatus
[02:13] <stub> ok
[02:13] <SteveA> ok
[02:13] <SteveA> time to move on
[02:13] <matsubara> moving on
[02:13] <kiko> matsubara, second page most hit I suspect
[02:13] <kiko> yes let's
[02:13] <SteveA> matsubara: anything else on the oops report?
[02:13] <matsubara> Retry Exceptions still happening and bug 31479 would help diagnose the real problem. spiv?
[02:13] <Ubugtu> Malone bug 31479 in launchpad "Retry exceptions should include information about the original query" [Normal,Confirmed]  http://launchpad.net/bugs/31479
[02:13] <matsubara> yes lots of things
[02:13] <jordi> hi
[02:13] <SteveA> hi jordi.
[02:13] <matsubara> Steve's patch to tickcount. Steve asked me to test it, but I don't know C enough to understand what the patch does, so I'm not sure if I'm the right person to do it.
[02:13] <SteveA> ordi: carlos said you're up to date with activity reports
[02:13] <matsubara> Outstanding Timeouts (bugs 2497, 3991, 6459) all assigned to kiko.
[02:13] <jordi> sorry I'm late, I was in some other nmeeting
[02:13] <Ubugtu> Malone bug 3991 in rosetta "Timeout error on translation page (+translate)" [Normal,Confirmed]  http://launchpad.net/bugs/3991
[02:13] <Ubugtu> Malone bug 6459 in rosetta "SoftTimeout error on distribution release language page" [Normal,Confirmed]  http://launchpad.net/bugs/6459
[02:14] <jordi> SteveA: I'm up to date.
[02:14] <kiko> matsubara, this week I'll have some coding time, fingers crossed
[02:14] <SteveA> matsubara: i spoke with kiko, and you have other things to do.  i'll get someone else to do it.
[02:14] <matsubara> From the QA side, while triaging I noticed bug 43263. Rosetta can't handle Dapper Universe packages, so is it difficult to add some page that tell people to not report bugs asking to add the templates? Currently users end up in a page that tells them to ask the inclusion of the template via Rosetta list or reporting a bug.
[02:14] <matsubara> I'd like to suggest that malcc be assigned to bug 44914, since he's working on soyuz and he could do that while getting confortable with the code.
[02:14] <Ubugtu> Malone bug 43263 in rosetta "No translatable templates for Dapper Universe packages" [Normal,Rejected]  http://launchpad.net/bugs/43263
[02:14] <spiv> matsubara: 31479 is on my todo list, but I'm unlikely to get to it until late next week.
[02:14] <Ubugtu> Malone bug 44914 in soyuz "Updade soyuz tests to use Zope 3.2 style " [Normal,Confirmed]  http://launchpad.net/bugs/44914
[02:14] <malcc> I'm happy to take 44914
[02:15] <kiko> matsubara, great suggestion!
[02:15] <kiko> carlos, what do you say about dapper/universe?
[02:15] <kiko> malcc, thanks!
[02:15] <carlos> matsubara: well, the thing is that edgy will have universe imported
[02:16] <carlos> matsubara: we are going to add a feature to solve the problem that prevented us to import universe
[02:16] <SteveA> bug 31479
[02:16] <Ubugtu> Malone bug 31479 in launchpad "Retry exceptions should include information about the original query" [Normal,Confirmed]  http://launchpad.net/bugs/31479
[02:16] <carlos> I'm preparing an announcement about dapper translations, I will add there an explanation about it anyway and jordi should add an entry to our FAQ explaining it
[02:17] <carlos> jordi: ^^^ 
[02:17] <jordi> explaining wghat?
[02:17] <jordi> oh I see
[02:17] <jordi> that dapper has no universe in rosetta
[02:17] <jordi> okie dokie
[02:17] <carlos> right
[02:17] <matsubara> carlos: great. shouldn't be a problem then. and edgy will open soon, right?
[02:17] <carlos> jordi: thanks
[02:17] <carlos> matsubara: as soon as dapper is released
[02:18] <jordi> yeah, we hope the edgy process will be smooth from the beginning
[02:18] <kiko> okay then.
[02:18] <SteveA> matsubara: anything else?
[02:18] <matsubara> I'm done SteveA , thanks
[02:18] <SteveA> thank you matsubara 
[02:18] <cprov> malcc: glad you assume 44914, i can help, since there is a lot and I need to learn more about new test style
[02:18] <SteveA>  * Outstanding sysadmin requests
[02:19] <SteveA> 6
[02:19] <SteveA> 5
[02:19] <SteveA> 4
[02:19] <SteveA> 3
[02:19] <stub> shipit urls
[02:19] <SteveA> 2
[02:19] <SteveA> stub: what's that?
[02:19] <stub> Which is new, but I suspect urgent
[02:19] <SteveA> got an RT number?
[02:19] <stub> No - lifeless CC'd it. 
[02:19] <spiv> pushsftp log file access (rt #8372)
[02:19] <stub> And I can't mention details in public
[02:20] <SteveA> stub: i saw that karl fixed some vhost thing recently.  is that it?
[02:20] <kiko> stub, hasn't it been handled yet?
[02:20] <spiv> It's progressed slightly since last week, but it's still outstanding.
[02:20] <SteveA> spiv: when do you want rt 8372 to be done by?
[02:20] <stub> Oh... seems to be working now.
[02:20] <spiv> SteveA: sooner rather than later ;)
[02:21] <SteveA> spiv: when will you start work on that stuff?
[02:21] <SteveA> like, monday, tuesday?
[02:21] <spiv> SteveA: early next week would be great.
[02:21] <stub> shipit seems to be ready to announce then.
[02:21] <SteveA> okay
[02:21] <SteveA> MeetingAction: stevea to ask admins about rt 8372 to see if they can finish it before tuesday
[02:21] <SteveA>  * Production and staging (stub)
[02:22] <stub> Production was updated to HEAD about 10 hours ago by lifeless. This was primarily to get shipit-for-dapper landed. I believe we are still waiting for new DNS changes and Apache rewrites done before we can announce it is open and the new surprises.
[02:22] <stub> Staging is currently not being updated daily for shipit testing. Please let me know if I can switch the updates back on.
[02:22] <stub> Erm... ignore the 'still waiting' but
[02:22] <stub> bit
[02:22] <salgado> stub, yes, you can swith the updates back
[02:22] <stub> ta
[02:22] <kiko> yeah, shipit's already live
[02:22] <SteveA> on all hosts?
[02:22] <SteveA> all domains rather
[02:22] <salgado> all
[02:22] <kiko> yes
[02:22] <salgado> we even have requests from different domains
[02:23] <SteveA> cool
[02:23] <kiko> amazing
[02:23] <kiko> lifeless, Znarl, salgado: outstanding work
[02:23] <SteveA> carlos: you have the translation priority stuff that needs landing still
[02:23] <carlos> SteveA: it's on PQM again
[02:23] <kiko> SteveA, I think that could wait till next tuesday?
[02:24] <SteveA> okay.  so, we'll want that cherrypicked when it lands
[02:24] <kiko> I mean, we will have updates to go in by then
[02:24] <carlos> SteveA: lifeless offered to cherry pick it
[02:24] <SteveA> great
[02:24] <SteveA> kiko: please talk with me about that after the meeting
[02:24] <SteveA>  * Are we all using bzr and bzrtools from dapper (kiko)
[02:24] <kiko> so, Are We?
[02:24] <kiko> I am
[02:24] <bradb> yar
[02:25] <carlos> I am
[02:25] <BjornT> me too
[02:25] <mpt> me
[02:25] <stub> yer
[02:25] <malcc> Yup
[02:25] <spiv> yep
[02:25] <jamesh> yeah
[02:25] <SteveA> ii  bzr            0.8-0ubuntu1   bazaar-ng, the next-generation distributed v
[02:25] <SteveA> ii  bzrtools       0.8.1-0ubuntu1 Collection of tools for bzr
[02:25] <ddaa> yup
[02:25] <ddaa> well
[02:25] <kiko> I know salgado and matsubara aren't but we will move them to dapper this week.
[02:25] <ddaa> not bzrtools
[02:25] <salgado> not the most recent one, but I'll upgrade right away
[02:25] <SteveA> (I ran:  dpkg -l bzr bzrtools  )
[02:25] <salgado> we're using a two weeks old version, or something like that
[02:26] <SteveA> kiko: done?
[02:26] <kiko> SteveA, yeah.
[02:26] <SteveA> thanks kiko
[02:26] <SteveA>  * Status of bugwatches work (bjorn)
[02:27] <BjornT> ok
[02:27] <BjornT> One branch (bugwatches-rework) I haven't been able to merge due to test failures in 30-mergepeople.txt. With that branch, a branch which is up for review, the bug watches work as according to the discussion in "Re: Immutable upstream task".
[02:27] <BjornT> When everything is merged i'm going to ask mpt to take a look at the UI, i'm sure it can be improved.
[02:27] <BjornT> kiko: btw, you were going to fix bug 42573, how's that going?
[02:27] <Ubugtu> Malone bug 42573 in malone "Look in the debbugs archive when syncing bug watches" [Critical,Confirmed]  http://launchpad.net/bugs/42573
[02:27] <kiko> BjornT, I'll have time for coding this week, previous weeks have been very busy
[02:27] <BjornT> cool
[02:27] <kiko> BjornT, one question is: did you unconflict and attempt to remerge again?
[02:28] <BjornT> kiko: i'm resolving conflicts now, i'll try to merge again soon.
[02:28] <SteveA> BjornT: if 30-mergepeople.txt fails again, please discuss it right away with me/stub
[02:28] <BjornT> will do
[02:28] <kiko> BjornT, okay. I'd like to know if 30-mergie fails again
[02:28] <SteveA> i may need to put some tasks aside and do some sqlobject spelunking
[02:29] <SteveA>  * Result of converting to knits (steve)
[02:29] <SteveA> any feedback on using bzr now that we've converted to knits?
[02:29] <kiko> knits are the future!
[02:29] <bradb> the speed improvements have so far been very encouraging
[02:29] <cprov> bradb: +1
[02:30] <ddaa> got a rsync-like performance on a test I ran this morning
[02:30] <kiko> ddaa, for push you mean?
[02:30] <ddaa> (daily update of rocketfuel-built)
[02:30] <ddaa> kiko: for pull
[02:30] <kiko> rspush worked for me -- push did not
[02:30] <salgado> push did work for me
[02:30] <bradb> m etoo
[02:30] <spiv> kiko: interesting, someone should talk with you after the meeting and figure out why.
[02:30] <mpt> Can someone help me push after the meeting? (I'm not strong enough)
[02:30] <jamesh> working fine for me
[02:31] <carlos> I guess we could do a bzr merge against rocketfuel instead of getting a local branch first, right?
[02:31] <cprov> yes, me too. progress bar still a bit obscure
[02:31] <ddaa> carlos: ?
[02:31] <mpt> there's a progress bar??
[02:31] <carlos> ddaa: instead of fetching rocketfuel-build
[02:31] <carlos> s/build/built/
[02:32] <SteveA> who will help mpt after the meeting?
[02:32] <carlos> ddaa: we could do a merge using sftp now, right?
[02:32] <ddaa> carlos: ha, yes
[02:32] <ddaa> carlos: looks like it would perform reasonably
[02:32] <kiko> I think it's very fast
[02:32] <ddaa> though I still find rocketfuel-built useful for keeping in touch with config changes
[02:32] <lifeless> ddaa: for those of you in europe. latency will still make the brazilians and australians cry
[02:33] <ddaa> carlos: looks like it would perform reasonably for us who live on the right continent
[02:33] <carlos> ok
[02:33] <kiko> ha ha
[02:33] <SteveA> moving on...
[02:33] <SteveA>  * Keep, Bag, Change
[02:33] <ddaa> got one
[02:34] <ddaa> CHANGE: remove the redundant cruft from the launchpad configs. Only keep config entries for the machines where a system is deployed.
[02:34] <mpt> CHANGE: stop mailing me translation import statistics every day
[02:34] <mpt> It's interesting information, but it should be on Launchpad (/distros/ubuntu/+translations), so non-Launchpadders can read it and Launchpadders don't have to
[02:34] <kiko> KEEP: translation import statistics! I definitely want to have that logged daily
[02:35] <kiko> it is vital information for keeping track of how the Dapper import/export process is working
[02:35] <SteveA> change: use topics for the launchpad list
[02:35] <mpt> So, why not on Launchpad?
[02:35] <carlos> mpt: it will not make sense when all things are done
[02:35] <kiko> mpt, it's a little more complicated than that. if you are curious /msg carlos after the meeting.
[02:35] <mpt> ok
[02:35] <ddaa> KEEP: fast review
[02:35] <slux> how am I supposed to add comments to bugs on launchpad? clicking the link at the end of the page just jumps to the beginning...
[02:35] <SteveA> 8
[02:36] <SteveA> 7
[02:36] <ddaa> posted a cscvs review request yesterday, got a replay today. Still one outstanding though :)
[02:36] <SteveA> 6
[02:36] <kiko> slux, what browser? javascript on or off?
[02:36] <SteveA> 5
[02:36] <SteveA> 4
[02:36] <SteveA> 3
[02:36] <ddaa> BAG: sourcecode/ breakage AGAN
[02:36] <SteveA> 2
[02:36] <lifeless> ddaa: bjornt just woke up ;)
[02:36] <SteveA> 1
[02:36] <slux> kiko, Firefox 1.0.8
[02:36] <SteveA> done.
[02:36] <slux> breezy's latest
[02:36] <kiko> slux, JS off by any chance?
[02:36] <SteveA> kiko, slux: the channel is about to become *very* noisy
[02:36] <SteveA> you may want to continue elsewhere
[02:37] <SteveA>  * Three sentences
[02:37] <SteveA> go ahead, state your sentences
[02:37] <mpt> DONE: MaloneSimplifications fixes, PageHeadings spec, bugfixes, knits
[02:37] <mpt> TODO: land MaloneSimplifications(!!!), portlet trimming, menus, specs
[02:37] <mpt> BLOCKED: no
[02:37] <stub> TODO: text searching, unless preempted by basic Rosetta RSS or impossible-sql-query-problem
[02:37] <ddaa> DONE: switched to importd/cscvs coding
[02:37] <ddaa> TODO: bugfixes to seamlessly handle CVS repo migrations, a ton of cscvs cleanups, bzr-native imports
[02:37] <ddaa> BLOCKED: bzr test failures blocks sourcecode/ merges _AGAIN_
[02:37] <stub> DONE: Mainly production stuff and did something nasty to my wrist
[02:37] <stub> BLOCKED: Nope
[02:37] <salgado> DONE: ShipItForDapper, some small changes on the mirror prober
[02:37] <slux> kiko, it's on
[02:37] <salgado> TODO: Finish the new custom-request page for shipit and get it on production
[02:37] <salgado> BLOCKED: No
[02:37] <jamesh> DONE: supermirror pull list stuff, sprint scheduler work, convert to knits, WorkingWithSharedRepositories documentation, code reviews
[02:37] <jamesh> TODO: finish sprint scheduler work, code reviews
[02:37] <jamesh> BLOCKED: no
[02:37] <BjornT> DONE: improved the bug watch widgets. bug fixes. reviews.
[02:37] <BjornT> TODO: Work on my assigned bugs list, fixing the most important ones.
[02:37] <BjornT> BLOCKED: can't merge bugwatches-rework branch due to 30-mergepeople.txt failure.
[02:37] <matsubara> DONE: oops report analysis, bug triage, oops bugs
[02:37] <matsubara> TODO: more of the same
[02:37] <matsubara> BLOCKED: no
[02:37] <carlos> DONE: PoMsgSetPage, API to add potemplate RSS, import queue review, bugs #35631, #38472, #44529, #37078, #41071, debugged and fixed a bug with the batching code while using it with POMsgSetPage
[02:37] <carlos> TODO: Fix tests after the migration of POMsgSetPage to the standard batching code, finish #35631 and a set of easy to fix bugs noted at https://wiki.launchpad.canonical.com/CarlosPerelloMarin, migrate translations from breezy to dapper
[02:37] <carlos> BLOCKED: No
[02:37] <Ubugtu> Malone bug 35631 in rosetta "Karma handling on Rosetta is broken" [Major,In progress]  http://launchpad.net/bugs/35631
[02:37] <Ubugtu> Malone bug 38472 in amarok "Korean instead of Kurdish imported into Rosetta" [Normal,Unconfirmed]  http://launchpad.net/bugs/38472
[02:37] <Ubugtu> Malone bug 44529 in rosetta "Translation import queue query needs validation." [Normal,Rejected]  http://launchpad.net/bugs/44529
[02:37] <malcc> DONE: Learnt more, fixed some bugs, finished startup admin
[02:37] <Ubugtu> Malone bug 37078 in rosetta "+admin page for IPOTemplate is not working for Rosetta experts" [Major,Fix committed]  http://launchpad.net/bugs/37078
[02:37] <Ubugtu> Malone bug 41071 in openoffice.org "All ooo-translations are overridden by the English originals" [Normal,Fix released]  http://launchpad.net/bugs/41071
[02:37] <lifeless> DONE: knit rf upgrade, various bzr tweaks and improvements.
[02:37] <lifeless> TODO: travel finalisating, europython talk abstract
[02:37] <lifeless> BLOCKED: No
[02:37] <jamesh> kiko: with JS turned off, the form would never get hidden
[02:37] <bradb> DONE: Laptop died. Various bug fixes. Spent some time on implicit subscriptions.
[02:37] <bradb> TODO: Land implicit subs. Fix OOPS bugs as they appear.
[02:37] <bradb> BLOCKED: No.
[02:37] <malcc> TODO: Learn more, fix more bugs, sprint with cprov next week
[02:37] <kiko> DONE: finished perf reviews, helped ShipIt definitions and rollout, upgrade trees, production report, architecting. 
[02:38] <malcc> BLOCKED: No.
[02:38] <jordi> DONE: list Email, imports of new templates
[02:38] <spiv> DONE: bug 44182, bug 44183, worked on bug 41414, reviews, knit upgrade, started ubuntu wiki stuff.
[02:38] <spiv> TODO: ubuntu wiki stuff, make importd tests (and thus check_merge) pass with bzr 0.8, sftp server bugs.
[02:38] <spiv> BLOCKED: No.
[02:38] <Ubugtu> Malone bug 44182 in launchpad-bazaar "supermirror branch puller leaves empty branch when initial mirroring fails" [Major,Fix committed]  http://launchpad.net/bugs/44182
[02:38] <kiko> TODO: coding! some minor reviews and assist shipit post-rollout, catch up with team activity
[02:38] <Ubugtu> Malone bug 44183 in launchpad-bazaar "supermirror branch puller does not preserve source branch format" [Major,Confirmed]  http://launchpad.net/bugs/44183
[02:38] <Ubugtu> Malone bug 41414 in launchpad-bazaar "supermirror-branch-puller ignores format changes" [Major,Confirmed]  http://launchpad.net/bugs/41414
[02:38] <SteveA> DONE: management, menus, review
[02:38] <SteveA> TODO: menus, management, various
[02:38] <SteveA> BLOCKED: no
[02:38] <jordi> TODO: clear Needs_Review in the queue, pending teams creations
[02:38] <kiko> BLOCKED: various email responses by stub, SteveA, cprov and others
[02:38] <jordi> BLOCKED: no
[02:38] <kiko> BLOCKED: on jamesh updating the error reports cron-runner too
[02:39] <cprov> DONE:archive-cruft-check redesign, queue-ui, various pending fixes in buildd-UI
[02:39] <cprov> TODO: sprint with malcolm, PPA design consolidation
[02:39] <cprov> BLOCKED: none
[02:40] <SteveA> kiko: please state your blocked issues in more detail
[02:40] <stub> I haven't got any kikograms flagged for response
[02:40] <jamesh> kiko: I'll look at getting the weekly report thingee done tonight
[02:41] <kiko> SteveA, I can't remember all of them, but off the top of my head: experimental server, database removal analysis for source package names, some database optimization queries I sent in...
[02:41] <stub> Oh - bogus sourcepackage stuff
[02:41] <kiko> there are other things, I need to look at my sent-mail
[02:41] <kiko> yeah
[02:41] <kiko> stub, that's sore because the distro guys are very inconvenienced by this
[02:41] <stub> I responded to experimental server
[02:41] <kiko> only you
[02:42] <kiko> - write access to staging
[02:42] <kiko> - milestones and upstreams
[02:42] <salgado> mpt, can you have a quick look at bug 5812? (I'm sure you'll know what I can use to avoid the issue I mentioned in the last comment)
[02:42] <salgado> https://launchpad.net/bugs/5812
[02:43] <stub> I never wanted the sourcepackagename table in the first place ;)
[02:43] <kiko> heh
[02:43] <kiko> - ppa-ng tables
[02:43] <SteveA> it's almost meeting ending time
[02:43] <kiko> (please please help with that)
[02:43] <kiko> (it is my coffin)
[02:44] <SteveA> okay, that's it
[02:44] <SteveA> not even time for a countdown-of-dooom
[02:44] <kiko> okidokie
[02:44] <SteveA> MEETING ENDS
[02:44] <SteveA> thanks everyone
[02:44] <SteveA> mpt: will you do the meeting summary again this week?
[02:44] <mpt> naturally
[02:44] <ddaa> lifeless: you might have noticed that the bzr test suite fails in pqm
[02:44] <SteveA> thanks mpt
[02:44] <ddaa> that is blocking the cscvs merges, AGAIN
[02:45] <lifeless> ddaa: well, as bzr.dev is managed by pqm, I haven't noticed that.
[02:45] <SteveA> spiv, jamesh, ddaa, lifeless: would one of you please help mpt with bzr push
[02:45] <jamesh> SteveA: okay
[02:45] <cprov> stub: would be nice if you can comment the sql view solution proposed by kiko for ppa-ng, is it feasible ?
[02:45] <SteveA> thanks jamesh 
[02:45] <lifeless> ddaa: spiv and I are working on this. I have some branches to publish for him.
[02:45] <ddaa> lifeless: I'll forward you the failure
[02:45] <kiko> cprov, I'm trying to avoid our funeral earlier!
[02:45] <stub> kiko: I only have the sourcepackagename query from you. I don't have a record of ppa-ng (or even know what the abbeviation stands for)
[02:45] <ddaa> mpt: SteveA: I need to have lunch now
[02:46] <kiko> stub, you got email on it though: Subject: REVIEW: cprov/ppa-ng
[02:46] <SteveA> stub: i have a phone call to make, but can we talk on skype after that about the data disordering issue?
[02:46] <jamesh> stub: personal package archive - next generation
[02:46] <stub> SteveA: ok
[02:46] <kiko> stub, the email starts by saying
[02:46] <SteveA> ta
[02:46] <kiko> Daniel, Stuart, I need some advice from you below on how we can reduce
[02:46] <kiko> the impact of this change. Full diff:
[02:46] <slux> hm, the firefox should be pretty much stock, only unusual thing about it is that it's locked down for public access
[02:46] <mpt> brb
[02:47] <stub> found ppa-ng message
[02:47] <kiko> slux, it's odd because it appears that javascript is broken. can you check the javascript console, clear it, and reload the page?
[02:47] <kiko> stub, do you filter stuff that is directly To: you?
[02:47] <stub> kiko: No - just gives me duplicates and makes my life hard
[02:48] <kiko> stub, when I add you to the To: it's because I expect you to read it as directed to you
[02:48] <cprov> stub: good, looking forward to your comments, maybe we can sort this out easily exploring SQL views
[02:48] <kiko> otherwise I'd just leave the standard CC:s
[02:48] <kiko> because I know you subscribe to everything
[02:49] <kiko> stub, is there another technique I should use? forward you emails?
[02:49] <stub> kiko: No - I read them. I don't always respond - most of the time I'm CC'd other people answer queries or I'm not actually needed.
[02:50] <kiko> stub, your opinion is one that I highly value, so I usually hang on waiting for an answer from you
[02:52] <mpt> Can anyone help me with bzr push?
[02:52] <kiko> mpt, what happens?
[02:52] <jamesh> mpt: what did you try, and what error did you get?
[02:52] <LarstiQ> only with non-launchpad specific issues
[02:54] <mpt> jamesh: I lost my Internet connection part-way through pushing. When I try again I get "bzr: ERROR: Lock error: File 'branch-lock' already locked", even after "bzr break-lock" (which produces no output).
[02:54] <lifeless> mpt: do bzr break-lock URLYOUWEREPUSHINGTO
[02:56] <slux> kiko, if using the chrome url to access the console is acceptable, I didn't get anything in there when reloading the page...
[02:56] <mpt> that seems to be working, thanks lifeless
[02:56] <mpt> Is it a bug that break-lock doesn't return a proper error?
[02:56] <kiko> slux, yeah, it's accessible. and you say javascript is running? what happens when you click on a status line in the table at the top of the page?
[02:57] <jamesh> mpt: if you ran "bzr break-lock" without an argument, it would have operated on your local branch
[02:57] <jamesh> mpt: it then successfully broke the stale locks on that tree (all zero of them)
[02:57] <mpt> ok, now it's stopped again
[02:57] <mpt> with exactly the same error
[02:58] <mpt> bzr: WARNING: This transport does not update the working tree of: sftp://chinstrap.ubuntu.com/home/warthogs/archives/mpt/launchpad/2006-03-MaloneSimplifications/
[02:58] <mpt> bzr: ERROR: Lock error: File 'branch-lock' already locked
[02:58] <jamesh> mpt: try ssh'ing into chinstrap, and change to the branch directory
[02:58] <stub> kiko: I don't see why your a) option requires yet another layer of views (securepackagepublishinghistory becomes a view, I think you suggested), when we could just update the existing views on securepackagepublishinghistory
[02:58] <mpt> jamesh: done
[02:59] <jamesh> mpt: does "ls .bzr/branch-lock/" show anything?
[02:59] <kiko> stub, some of the queries are directly on SSPPH and SBPPH.
[02:59] <mpt> mpt@chinstrap:/home/warthogs/archives/mpt/launchpad/2006-03-MaloneSimplifications/.bzr $ ls branch-lock
[02:59] <mpt> branch-lock
[02:59] <mpt> that's all
[02:59] <lifeless> mpt: 'ls' please
[03:00] <kiko> stub, and those queries would still need to be band-aided
[03:00] <stub> kiko: The fallout from doing it would be a pain anyway, as any updates would need to be refactored to use the underlying table (unless I went sick on table rules, which I'd rather not)
[03:00] <mpt> mpt@chinstrap:/home/warthogs/archives/mpt/launchpad/2006-03-MaloneSimplifications/.bzr $ ls -l | grep lock
[03:00] <mpt> -rw-rw-r--    1 mpt warthogs         0 May 14 09:55 branch-lock
[03:00] <mpt> -rw-r--r--    1 mpt warthogs         0 May 18 07:12 branch-lock.write-lock
[03:00] <slux> kiko, if you mean clicking on the link under "Affects", a form for changing the bug details appears on the page
[03:00] <stub> Cause we don't have updatable views
[03:00] <lifeless> mpt: this branch is in 0.7 firmat
[03:00] <lifeless> *format*
[03:00] <lifeless> mpt: you need to perform the same upgrade procedure you did on your devel machine, on chinstrap
[03:00] <kiko> stub, no, we'd change all queries to use the view, and leave inserts inserting into the right table
[03:00] <lifeless> then it will all work better
[03:00] <mpt> oh, foo
[03:00] <kiko> stub, as it works today for other views.
[03:01] <lifeless> right now, you should rm branch-lock.write-lock
[03:01] <kiko> stub, the main difference being that the SSPPH and SBPPH table queries would be done on the views.
[03:01] <jamesh> mpt: okay.  try this: change to the /home/warthogs/archives/mpt/launchpad directory and move 2006-03-MaloneSimplifications out of the way
[03:01] <slux> clicking the link at the end of the page makes "Virhe: icon.getAttribute("src") has no properties
[03:01] <slux> Lhdetiedosto: https://launchpad.net/@@/launchpad.js
[03:01] <jamesh> mpt: then "cp -a /home/warthogs/archives/rocketfuel.knit/launchpad/devel 2006-03-MaloneSimplifications"
[03:02] <slux> " appear (sorry for the newlines)
[03:02] <jamesh> mpt: that'll give you a rocketfuel branch at the right location
[03:02] <lifeless> jamesh: wrong tree
[03:02] <jamesh> lifeless: oh?
[03:02] <lifeless> jamesh: /home/warthogs/archives/rocketfuel/launchpad/devel
[03:02] <lifeless> that .knit one is going to be deleted RSN
[03:02] <jamesh> lifeless: well, the "cp" trick won't work for that one because it is in a repo (last I checked)
[03:03] <lifeless> jamesh: true. So use branch!
[03:03] <mpt> cancel the cp?
[03:03] <lifeless> mpt: no need, it will work ok.
[03:03] <lifeless> its just out of date now
[03:04] <jamesh> mpt: nah.
[03:04] <jamesh> lifeless: it is close enough though
[03:04] <mpt> ok
[03:04] <kiko> stub, can you consider that and follow-up via email?
[03:04] <kiko> slux, how odd. 
[03:04] <jamesh> mpt: now on your local machine, run "bzr push --overwrite sftp://chinstrap.ubuntu.com/home/..."
[03:05] <stub> kiko: I'm seeing a choice between complicating the data model or complicating the code. I'm leaning towards complicating the code, because the data model in this area is already too complex. The existing views were justified because the queries were just getting too complex and because grabbing wrong rows would be a security hole (with embargod stuff).
[03:05] <slux> "https://launchpad.net/@@/launchpad.js" is the source of that error
[03:05] <stub> kiko: Splitting the tables might be an option
[03:05] <slux> Line 155
[03:06] <jamesh> slux: is there any other earlier errors?
[03:06] <kiko> stub, complicating the code.. seems to be a non-option. did you look at the diff?
[03:08] <kiko> stub, the risk and potential for us missing or getting a callsite wrong is /very/ large
[03:08] <kiko> stub, this code is not unit-tested.
[03:08] <kiko> (and yes, that is being addressed, but more slowly than ppa-ng is going it appears)
[03:08] <stub> What is the risk?
[03:08] <cprov> kiko: yes, I agree with you on this point, code is already enough complicated & untested.
[03:08] <slux> jamesh, I'm getting some uncaught exceptions, NS_ERROR_XPC_BAD_CONVERT_JS in the console, it's not just that page though
[03:09] <kiko> stub, did you /read/ the patch?
[03:09] <stub> ie. What could happen if code thought a personal package archive was not personal? Something that shouldn't getting rolled out into the official release?
[03:09] <stub> I'm reading it
[03:09] <jamesh> slux: try this: open the JS console and clear all the messages.  Then reload the bug page and try to expand the comment box
[03:09] <cprov> stub: system break down, data model corruption andso on 
[03:09] <jamesh> slux: that way you'll only have the messages from the LP bug page
[03:10] <salgado> BjornT, around?
[03:10] <slux> jamesh: what should expand the comment box? the link that jumps to the start of the page and is labeled "add comment to this bug"? :P
[03:10] <kiko> stub, getting something wrong could range from disaster to bad
[03:10] <kiko> slux, yes. that link shouldn't behave that way, though.
[03:11] <jamesh> slux: yeah.
[03:11] <slux> jamesh: doing that results in the first icon.getattribute error and that exception
[03:11] <jamesh> slux: I'm wondering if the javascript run when the page loads is failing
[03:11] <jamesh> slux: are there any other messages?
[03:11] <slux> jamesh: nope
[03:11] <cprov> stub: a noise in the current publication system has extremelly bad consequences over the distro team, mirrors, etc and it's hard to detect in the model (remember dup librarian filenames took 3 days to debug)
[03:12] <jamesh> slux: that's weird.  the img element it is looking up is created in the onload handler
[03:12] <stub> Do personal package archives need all that embargo and security stuff?
[03:12] <stub> cprov, kiko: ^^
[03:12] <kiko> stub, probably not.
[03:12] <jamesh> slux: do you see a little arrow next to the "Add comment to this bug" link?
[03:12] <cprov> stub: no, it's not strictly necessary 
[03:13] <stub> Might it be necessary? I'm thinking about the pros and cons of splitting the personal stuff from the .... erm... impersonal?
[03:13] <slux> jamesh, just the text
[03:13] <kiko> stub, it might be a nice-to-have feature but is not really necessary
[03:14] <kiko> given the fact that embargo only really makes sense for stuff that is going through a security process
[03:14] <kiko-afk> I need to skip out for 30m for an appointment, but email is appreciated
[03:14] <malcc> If we stick with one table, can we reduce the risk of old-school queries by implementing PPA with an existing field, eg having a new distrorelease name for my personal version of dapper?
[03:14] <kiko-afk> or cprov can keep it
[03:14] <malcc> We already know the code doesn't muddle up different distros
[03:15] <jamesh> slux: there is meant to be an arrow pointing to the right next to the link, that changes to a down arrow when the form gets expanded
[03:15] <kiko-afk> malcc, mmmm. it would mean a new distrorelease entry, which is dangerous.
[03:15] <SteveA> stub: call in 15 mins?
[03:15] <stub> SteveA: ok
[03:15] <cprov> stub: by being personal we can also model it _private_ and it will reach some level of security 
[03:15] <kiko-afk> well, not dangerous per se, but certainly causes the data model to become weaker in semantic
[03:16] <malcc> kiko-afk: That seems to be the underlying tradeoff here, to choose a different data model than the most semantically clear one, to try to mitigate the risks from the code change
[03:16] <slux> jamesh, right. the only thing between the comment boxes and the footer is the link that reads "Add comment to this bug", there's nothing but whitespace on either side of it or between footer/comment boxes and it
[03:16] <cprov> malcc: kiko is right, since even PPA packages are target to an existent distrorelease
[03:16] <kiko-afk> malcc, yes, you're right. I'm mainly proposing using views to try and mitigate the risk, but...
[03:17] <slux> so I guess I'm not seeing all I should be for some reason..
[03:17] <kiko-afk> slux, can we see a screenshot?
[03:17] <kiko-afk> anyway, bbiab
[03:17] <malcc> cprov: Yes, it would effectively mean giving distroreleases parents which are other distroreleases, so my personal dapper becomes semantically a child of the main dapper
[03:18] <malcc> Anyway I less than half have a clue about this data model so I'm just making stuff up here
[03:18] <malcc> Although the advantage of implementing PPA as a tree in distrorelease would be I could make a personal version of your personal version of dapper...
[03:18] <mpt> heh
[03:19] <mpt> jamesh: bzr: ERROR: No repository present: 'sftp://chinstrap.ubuntu.com/home/warthogs/archives/mpt/launchpad/2006-03-MaloneSimplifications/'
[03:19] <cprov> malcc: that's the derivation model, which overkill for PPA, since includes specifics semantics for archive publication, domination and etc, that are not necessary for PPA.
[03:20] <BjornT> hi salgado 
[03:20] <slux> jamesh, kiko: http://lib2.vaasa.fi/shot.png
[03:20] <malcc> cprov: Hmm, ok, but if we need that model anyway, we can turn bits of it off for PPA and only have to implement one model
[03:21] <malcc> cprov: Otherwise we implement two systems, one for distro derivation the big way, and one for distro derivation on a small scale for PPA
[03:22] <cprov> malcc: and also improve things we don't like from the current publication model but we can't experiment in the main publication tables (like apt-ftparchive dependency and filesystem based archive)
[03:23] <mpt> lifeless: --^
[03:23] <carlos> later
[03:23] <mpt> Any idea about fixing that error?
[03:24] <cprov> malcc: yes, having two system for the same issue freaks me out, fixing bugs twice would be utterly distressing
[03:24] <ddaa> bah, dapper bzrtools does not have my switch plugin
[03:24] <malcc> cprov: I need to read around this issue more, I'm just starting. But all my instincts are telling me PPA is a special case of derivation and we should implement this once only
[03:26] <cprov> malcc: after pondering a lot, I'm really inclined to use the SQL view approach and deal with complex DB arreangement instead of be in risk of break the code or having two models for the same feature
[03:27] <cprov> malcc: I'm glad that you interested and aware of this topic, I think it'll be the main topic of our sprint. Would you like to face this problem with me ?
[03:27] <malcc> cprov: Yes, I think this is the ideal problem for us to work on together
[03:27] <SteveA> stub: i'm running skype
[03:28] <mpt> lifeless / spiv: By the way, if rocketfuel.knits is going away RSN, the "To push a standalone knit branch to chinstrap the first time" instructions on RocketfuelToKnits should be updated
[03:29] <lifeless> jamesh: can you finish helping mpt out ?
[03:29] <lifeless> jamesh: its 2330 for me
[03:29] <ddaa> mpt: why use standalone branches at all?
[03:29] <ddaa> at least for lauchpad
[03:29] <mpt> ddaa: Because I haven't had repositories fully explained to me yet, and I'm doing one thing at a time
[03:30] <cprov> malcc: great, I'll do some reserch on writable SQL views, but first of all, we needs to reorganize the spread queries on SSPPH/SBPPH, currently it's awkward how we do this.
[03:30] <ddaa> mpt: let's go to #bzr, and I'll give you as full an explanation as you wish
[03:30] <spiv> mpt: fixed, thanks.
[03:31] <mpt> ddaa: ok, how about tomorrow? It's 1.30am, and I just want to push this branch while people are here
[03:31] <ddaa> if you prefer
[03:32] <mpt> In my current state, if you explained repositories to me I'd have forgotten by tomorrow anyway :-)
[03:32] <ddaa> there's really not much to understand
[03:38] <Who_> kiko-afk: are you around?
[03:43] <ddaa> heya, somebody up for a quick review? Got a branch fixing the annoying logging in the importd test suite.
[03:44] <ddaa> mh, gotta admit sftp push is not terribly fast yet
[03:44] <kiko-afk> Who_!
[03:45] <ddaa> ha, my rocketfuel repo was still weave :)
[03:46] <Who_> kiko: did you get my email?
[03:46] <kiko> Who_, I did, I need to tackle my inbox shortl
[03:46] <kiko> y
[03:47] <Who_> yea, that's fine - I had to get the email address off Launchpad and wasn't 100% certain I'd got you :P
[03:47] <kiko> you got me!
[03:48] <Who_> well I'll wait my turn for your time then. Thanks very much :)
[03:48] <kiko> thanks
[03:55] <slux> oh well, ended up adding the comment on a different system that had ffox 1.5
[03:56] <kiko> slux, that actually worked?
[03:57] <slux> kiko, yeah
[03:58] <slux> wonder if it does on a stock breezy badger with 1.0.8... this one should be rather close to that...
[03:59] <kiko> slux, we use breezy here and no problems, so I don't think so
[03:59] <slux> kiko, it's really strange then.. the only customization I've done to this one is a firefox.js that has some of the prefs set as locked
[04:00] <kiko> any prefs that are worth mentioning?
[04:04] <slux> kiko, I don't know really... the only javascript related stuff is the firefox javascript popup prevention etc.
[04:05] <spiv> slux: hmm, maybe it's possible that popup prevention interferes with some onload javascript that page depends on...
[04:06] <dilys> Merge to devel/launchpad/: [r=salgado]  make bugtasks editable if they don't have a bugwatch. some other fixes as well. (r3569: Bjorn Tillenius)
[04:07] <kiko> yes!
[04:07] <kiko> yes!
[04:07] <kiko> yes!
[04:07] <kiko> my patch is a winner :)
[04:08] <kiko> slux, how about trying that firefox.js in the newer version and seeing if it also breaks?
[04:08] <kiko> SteveA, so it appears my patch may have helped the 30-mergie
[04:12] <slux> kiko, now that I found the correct lockdown file and removed it for a test I found what disables it
[04:13] <slux> kiko, it's simply preventing javascript from changing images (the last checkbox in the js permission ffox preferences)
[04:13] <kiko> aha
[04:13] <kiko> slux, would you be able to file a bug on that, explaining how to reproduce?
[04:15] <SteveA> kiko: so, you added some gc stuff
[04:16] <kiko> I did indeed
[04:16] <SteveA> kiko: so i reckon it may be an sqlobject/sqlos object's connection issue
[04:16] <kiko> even more than the recommended amount
[04:16] <kiko> it went well over the RDA
[04:16] <SteveA> ODed on OJ
[04:17] <slux> sure, if that's needed... quite straightforward though, 5 clicks or so :P
[04:17] <kiko> slux, thanks -- we are ODing on tasks right now
[04:20] <mpt> eh
[04:21] <mpt> What should .bzr/parent contain for Launchpad branches?
[04:22] <kiko> mpt, sftp://chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/launchpad/devel
[04:23] <ddaa> without trailing newline
[04:23] <ddaa> actually
[04:23] <mpt> thanks
[04:23] <lifeless> mpt: .bzr/branch/parent
[04:23] <ddaa> on knit branches it's not there anymore
[04:23] <lifeless> mpt: .bzr/parent is not used nomore
[04:23] <lifeless> goodnight all
[04:23] <mpt> So the error message is out of date?
[04:23] <ddaa> as lifeless said, except if your branch is a light checkout is actually removed one more level
[04:23] <mpt> "Please identify where you want submitted merges to occur in .bzr/parent (or use bzr pull --remember)"
[04:24] <ddaa> hu?
[04:24] <ddaa> Where does that come from?
[04:24] <mpt> oh, never mind
[04:24] <mpt> that's from the publish script, not part of bzr
[04:26] <mpt> ok, now I'm cooking
[04:26] <ddaa> what's the dessert?
[04:26] <ddaa> boys'n berries ice cream?
[04:31] <mpt> Dessert is PQM
[04:31] <mpt> It's berry-colored at the moment
[04:32] <mpt> http://pqm.launchpad.net/
[04:34] <mpt> Is that bug 42866?
[04:34] <Ubugtu> Malone bug 42866 in pqm "Web UI dies with NotImplementedError if a "patch" command is in the queue" [Normal,Unconfirmed]  http://launchpad.net/bugs/42866
[04:34] <stub> carlos: That first DELETE is being really slow because you are joining with the Person table in the subquery, but the Person table isn't in the WHERE clause (or being used). So the subquery is returning several orders of magnitude more rows than it needs to.
[04:35] <carlos> stub: really?
[04:35] <carlos> :-(
[04:35] <spiv> mpt: It looks like the same traceback as 42886, anyway.
[04:35] <carlos> could you fix it or should I do it and send you it back?
[04:35] <mpt> bug 42886
[04:35] <Ubugtu> Malone bug 42886 in hotkey-setup "ibm-acpi volume control unpredictable" [Normal,Unconfirmed]  http://launchpad.net/bugs/42886
[04:35] <spiv> mpt: er, 42866 :)
[04:35] <stub> carlos: Yup. Nasty bug because there is no warning ;)
[04:36] <mpt> So now I can't tell whether MaloneSimplifications is in the queue or not
[04:37] <mpt> anyway, bedtime
[04:37] <spiv> mpt: damn.
[04:38] <spiv> Well, for the record, PQM is processing a branch from carlos, and has two more in the queue, then a mystery command that breaks PQM.
[04:39] <kiko> spiv, it just breaks the HTTP. it's not a big deal
[04:39] <ddaa> or mock, or some or other mock-object implementation
[04:39] <spiv> Which means mpt's merge isn't in the queue.
[04:39] <ddaa> kiko: what would you think of that?
[04:39] <spiv> Or, if his is the mystery command, it may as well not be because the odds of mpt meaning anything other than star-merge are low :)
[04:40] <kiko> ddaa, you mean, something better than Snapshot?
[04:40] <ddaa> snapshot?
[04:41] <ddaa> kiko: I mean something that provides a mock-object implementation
[04:41] <SteveA> ddaa: what is this mock-object stuff for?
[04:41] <stub> carlos: Delete took 10 seconds with it removed ;)
[04:41] <ddaa> so we would not have to implement our own half-assed mock objects everytime we need it
[04:41] <SteveA> what do you mean by "mock object" exactly?
[04:41] <ddaa> SteveA: it's for unit testing
[04:42] <SteveA> is there a project you can point me at to look at these?
[04:42] <carlos> stub: wow....
[04:43] <malcc> SteveA: Put mock objects into google, a lot has been written about them (mostly in the Java world)
[04:43] <ddaa> http://c2.com/cgi/wiki?MockObject
[04:43] <SteveA> ddaa: i mean, a specific implementation you think we should consider
[04:43] <ddaa> I have experience with no specific implementation so far
[04:44] <SteveA> ok
[04:44] <ddaa> a couple of candidates could be http://pmock.sourceforge.net/ and http://python-mock.sourceforge.net/
[04:44] <SteveA> i have discussed with bjorn and (i think) stub in the past about using our interfaces to create mock objects
[04:44] <SteveA> the interfaces describe the boundaries of units
[04:44] <ddaa> SteveA: I have a lot of uses for mock objects in non zopy stuff, too
[04:45] <SteveA> and so by using interfaces, we can get reasonable mock behaviour, without needing to say a great amount
[04:45] <ddaa> now that I'm starting to grok unit testing, I'm finding uses for them in cscvs and importd
[04:45] <SteveA> ddaa: you may use interfaces to describe any python systems you like
[04:45] <SteveA> it is a descriptive idea, not something that a system must conform to in order for you to use this approach
[04:46] <ddaa> I'm very far form convinced that interface are sufficient, and that it's worth adding them just for mock object testing purposes
[04:47] <ddaa> actually, except for security wrapping purposes, I am not yet convinced of the usefulness of interfaces except in some very spethial applications (zope and twisted have a lot of implementations and adapters, so that make sense there)
[04:47] <ddaa> even in launchpad, I see we use interfaces for two purposes: security wrapping and automatic form generation
[04:47] <LarstiQ> mock objects aren't only good
[04:48] <ddaa> and I'd rather have the automatic form generation stuff in the content or browser classes
[04:48] <malcc> Zope interfaces aren't interfaces in the conventional sense, they provide behaviour as well as describing API
[04:48] <stub> carlos: Does https://chinstrap.ubuntu.com/~dsilvers/paste/fileAXE2I7.html look sane?
[04:49] <ddaa> malcc: also, I'm not really convinced of the interface for the sake of defining interfaces in general python programming
[04:49] <ddaa> looks to me like an attempt to force some kind of static type checking onto python
[04:49] <carlos> stub: hmm, it's a bit difficult to see it, more or less, yes, I don't see any high number that should not be there
[04:49] <carlos> stub: if you are 100% sure that only translations from rosetta-admins were removed... go ahead
[04:49] <carlos> removed == DELETE ...
[04:50] <SteveA> malcc: how do you mean "they provide behaviour" ?
[04:50] <ddaa> SteveA: well, the next time the issue pops up, I'd really like a mock object implementation that integrates usefully with unittest
[04:50] <malcc> SteveA: Just yesterday I made a change to how one of our forms validated. I did so by editing an interface class, but my change made no change to any APIs, it just changed the behaviour of some objects
[04:51] <SteveA> ddaa: file a spec on launchpad
[04:51] <malcc> SteveA: As in a certain type of database object changed how it validated its fields
[04:52] <SteveA> that's interesting.  i wouldn't call the constraint in a schema "behaviour"
[04:52] <carlos> stub: thank you for your help
[04:52] <SteveA> certainly changing an interface can change the behaviour of parts of the system that look to that interface to inform how they should behave
[04:52] <SteveA> this is the same as in other systems that allow introspection of interfaces
[04:53] <SteveA> for example, removing an attribute from an interface may have the effect in the whole application of removing a field from a form
[04:53] <malcc> SteveA: Yes, most systems with interfaces allow this kind of thing, eg in Java you can include constants in interfaces if you choose, and then make code elsewhere conditional on them
[04:53] <SteveA> you can make java code conditional on the API of an interface too
[04:53] <malcc> SteveA: Many coding guidelines call for not doing this, as it's not what interfaces are "supposed to be for"
[04:54] <SteveA> although, because of compile time type-checking, this is less common except on systems that allow very dynamic assembly of parts
[04:54] <malcc> SteveA: I think this is another one for over-a-beer
[04:54] <carlos> jordi: around?
[04:54] <ddaa> SteveA: too much meta-work
[04:54] <SteveA> i don't think this is a property of interfaces as such
[04:54] <SteveA> but more a property of the system that makes use of them
[04:55] <malcc> Hmm, interesting statement!
[04:55] <SteveA> so i would not say "an interface provides behaviour".  i would say "an interface specifies or constrains the behaviour of other parts of the system"
[04:55] <malcc> Surely interfaces are given their properties by how they fit into the system around them?
[04:56] <SteveA> i don't know what you're saying, so i'll leave this for the beer.
[04:57] <SteveA> i'll note that one thing i'll be doing on launchpad very soon is making it so that we don't need to duplicate method signatures and attributes between implementation and interfaces
[04:57] <SteveA> yet, we'll still have interfaces
[04:57] <ddaa> okay, so that's a very different sort of interface than in java
[04:58] <malcc> Interesting. How will the implementing class indicate which method in the interface it is providing the implementation for, without duplicating the signature?
[04:58] <carlos> SteveA, kiko-fud: Now that I fixed the bug that required me to be a Launchpad admin, I just removed myself from that team
[04:58] <SteveA> ok
[04:58] <SteveA> thanks
[04:59] <carlos> np
[04:59] <SteveA> ddaa: i agree that there are some differences than in java.  but i think my statement holds true for java too.
[05:00] <carlos> lifeless: http://pqm.launchpad.net/ is broken atm
[05:01] <SteveA> malcc: this margin is not large enough for the full explanation.
[05:01] <SteveA> malcc: so, it's either when the code lands, or over a beer...
[05:04] <malcc> SteveA: Cool
[05:14] <spiv> carlos: It'll right itself as soon as it processes the request that's breaking the web UI.
[05:15] <carlos> spiv: it's already fixed
[05:15] <carlos> spiv: so it's a problem with test output?
[05:15] <spiv> Oh, so it is.
[05:15] <spiv> Interesting.
[05:16] <spiv> carlos: Did you get a big colourful traceback?
[05:16] <carlos> yes
[05:16] <spiv> I doubt it's the test output then :)
[05:27] <stub> cprov: ~stub/launchpad_prod.20060518.dump on mawson
[05:29] <cprov> stub: great, could you paste the restore cmdline if it is special ? (don't remember if simply pg_restore will work appropriately) 
[05:30] <stub> cprov: pg_restore --no-acl --no-owner --dbname=whatever ~stub/launchpad_prod.20060518.dump
[05:30] <stub> Then upgrade.py, fti.py and security.py as normal
[05:31] <cprov> stub: ahh --no-acl --no-owner, remeber now, thanks
[05:47] <malcc> I'm using this: python test.py -vvf canonical pagetests/soyuz to run pagetests, and also editing them at the same time, as it takes a while. The test runner is choking on the .#... files emacs leaves lying around. Is there an easy fix? Pls don't say vi.
[05:48] <SteveA> there is code in the test runner that attempts to find stuff while ignoring junk files
[05:48] <SteveA> so it would be a reasonable patch in our test runner and upstream in zope to make it ignore those files too
[05:49] <SteveA> i think you can also configure emacs to leave the turds in a different place
[05:49] <carlos> bradb, BjornT: How could I know why rosetta-admins is subscribed to https://launchpad.net/distros/ubuntu/+source/xfce4-terminal/+bug/41791 ?
[05:49] <Ubugtu> Malone bug 41791 in xfce "Xubuntu-Dapper Drake (AMD64): Missing Terminal RC File" [Unknown,Unknown]  
[05:49] <malcc> SteveA: Thanks
[05:50] <carlos> the activity log does not show anything...
[05:51] <bradb> carlos: indeed, hm, that's a bit curious
[05:51] <carlos> I'm not completely sure, but I think this is not the first time it happens
[05:51] <bradb> oh, it's because you are the upstream registrant
[05:52] <SteveA> malcc: although actually... maybe it is just our test runner
[05:52] <bradb> carlos: https://launchpad.net/products/xfce/
[05:52] <carlos> bradb: ?
[05:52] <carlos> I see
[05:52] <carlos> that's confusing...
[05:52] <SteveA> malcc: because the way we do pagetests is not how they're done in zope
[05:52] <bradb> you, i.e., the rosetta admins
[05:52] <carlos> anyway, I will change the ownership to the register team
[05:52] <carlos> thanks for checking it
[05:52] <malcc> SteveA: Thanks, I found the emacs turd-moving recipe and I'm going to go that route
[05:52] <bradb> no prob
[05:55] <spiv> malcc, SteveA: the file to look at is lib/canonical/launchpad/ftests/test_pages.py
[05:55] <spiv> It just filters a listdir with "filename.lower().endswith('.txt')".
[05:56] <spiv> So if emacs is just prefixing its backup files and not suffixing, then I can see how that would confuse it.
[05:56] <carlos> see you!
[06:02] <dilys> Merge to devel/launchpad/: [r=kiko]  Implemented POTemplate priorities to help our users to know what's more important to get translated. This feature has been implemented by Mark (r3570: Carlos Perello Marin, Mark Shuttleworth, Carlos Perell Marn)
[06:22] <spiv> Good grief.  "bzr viz" is about 3000 pixels wide for launchpad...
[06:24] <kiko> spiv, that's hard work. :)
[06:24] <kiko> BjornT, you got lucky :)
[06:26] <BjornT> kiko: yeah :) hard to tell if it was your fix that did it, or something else, though.
[06:27] <kiko> BjornT, what are you talking about? it is OBVIOUS that my fix is PERFECT!!1
[06:29] <kiko> no it contains advanced gc.collect() calls too
[06:30] <kiko> ddaa, ping?
[06:31] <kiko> ddaa, vostok's loadavg is high. check it out
[06:32] <Znarl> ddaa : CRITICAL - load average: 161.65, 160.64, 159.85 
[06:32] <ddaa> wow :)
[06:33] <ddaa> Znarl: I can have a look, but your judgement is a good as mine. I do not own the code that runs there (spiv and salgado do) and I do not have any priv to manage it.
[06:33] <jordi> carlos: here
[06:33] <ddaa> kiko: I know what it is
[06:33] <ddaa> I bet that a new bzrlib was rolled out
[06:33] <ddaa> *sigh*
[06:33] <kiko> rock and rollit
[06:34] <ddaa> there's a couple of bugs that cause it to mirror a bunch of knit branches as weave
[06:34] <ddaa> thus doing knit->weave conversion
[06:34] <ddaa> which is a bad idea
[06:34] <ddaa> thus meltdown
[06:34] <ddaa> I made noises about not rolling out the new bzr before that was fixed
[06:35] <ddaa> a think that can be done to help is put down the branch puller now and downgrade bzrlib until the problems are fixed
[06:36] <ddaa> https://launchpad.net/products/launchpad-bazaar/+bug/44183
[06:36] <Ubugtu> Malone bug 44183 in launchpad-bazaar "supermirror branch puller does not preserve source branch format" [Major,Confirmed]  
[06:36] <kiko> ddaa, is that something znarl can do?
[06:37] <ddaa> https://launchpad.net/products/launchpad-bazaar/+bug/44182
[06:37] <Ubugtu> Malone bug 44182 in launchpad-bazaar "supermirror branch puller leaves empty branch when initial mirroring fails" [Major,Fix committed]  
[06:37] <ddaa> https://launchpad.net/products/launchpad-bazaar/+bug/41414
[06:37] <Ubugtu> Malone bug 41414 in launchpad-bazaar "supermirror-branch-puller ignores format changes" [Major,Confirmed]  
[06:37] <ddaa> kiko: whatever, it's not going to break it anymore...
[06:38] <ddaa> kiko: combine these three bugs, and do a careless rollout of the new bzr, and you get the current situation
[06:38] <ddaa> kiko: though stub or lifeless would be best qualified to do it
[06:40] <ddaa> lifeless was aware of the problem, but we disagreed on the seriousness of the issue
[06:41] <spiv> ddaa: Are you sure that's the issue?  The new bzr isn't in rocketfuel yet.
[06:41] <kiko> ddaa, are you sure that's what's up?
[06:41] <ddaa> not absolutely sure
[06:41] <kiko> walk the mile
[06:41] <ddaa> spiv: but the pqm failure I got  when trying to merge cscvs the last time suggest the new bzr is in rocketfuel
[06:41] <spiv> So a "careless rollout" is unlikely to have changed the bzr in use.
[06:41] <spiv> ddaa: It isn't.
[06:42] <spiv> ddaa: I suspect the testsuite of the old bzr in rocketfuel is unfortunately senstive to the *system* bzr being upgraded.
[06:42] <ddaa> mh
[06:43] <ddaa> kiko: okay, so I'm probably wrong
[06:43] <ddaa> and then I've no clue
[06:43] <kiko> well, I did say walk the mile :)
[06:43] <ddaa> what does that mean?
[06:43] <kiko> go the distance to debug what is wrong
[06:43] <dilys> Merge to devel/launchpad/: [rs=kiko]  Improved security adapters for DistroReleaseQueue and view/template code (r3571: Celso Providelo)
[06:43] <ddaa> I'm not going to have the time.
[06:43] <kiko> rock on cprov
[06:43] <kiko> ddaa, the loadavg is blowing up /now/ though
[06:43] <ddaa> I about to leave for a school reunion
[06:44] <kiko> well, what should znarl do meanwhile
[06:44] <spiv> ddaa: As soon as bzr in rf is upgraded, I will be merging a bugfix for 44183, the code part of 44182 is already in rf, and I have already half-done the fix for 41414.  You can relax :)
[06:45] <ddaa> spiv: if you can land the fix for 41414 before rollout, there should be no need for manual fixup, that would help my peace of mind a lot
[06:45] <spiv> (well, assuming reviews don't get in the way, but I don't expect that to be a significant impediment)
[06:46] <kiko> cprov-lunch, we will need to make fixing up the source package name creation a priority today
[06:46] <spiv> It's my bedtime... g'night.
[06:46] <kiko> night spiv 
[06:47] <kiko> cprov, I am doing some research as we speak
[06:47] <cprov> kiko: did you discovered something new ?
[06:48] <ddaa> Znarl: there seems to be a crazy moin load there
[06:48] <cprov> s/discovered/discover
[06:48] <kiko> cprov, well, stub cleared out the DB, and I am going to snapshot the list of bogus SPNs now and in 2 hours
[06:48] <kiko> cprov, are there uploads being processed in the next two hours?
[06:49] <cprov> kiko: sure, do you want to stop it ?
[06:49] <ddaa> Znarl: any clue what could be causing that?
[06:49] <kiko> cprov, no, let them run
[06:49] <ddaa> spiv: what does the listbranches script do?
[06:49] <kiko> cprov, we have a log of everything processed, right?
[06:49] <Znarl> ddaa : Checking.
[06:50] <spiv> ddaa: I don't think I've heard of that one.
[06:50] <cprov> kiko: yes, in lp_archive mailbox in drescher
[06:50] <kiko> cprov, that's perfect. let's wait for now.
[06:50] <ddaa> spiv: there's also seem to be a very busy sftp server
[06:50] <ddaa> spiv: I have no idea what could be the cause
[06:50] <cprov> kiko: understood, i'm going to office soon 
[06:51] <kiko> cprov, okay, awaiting your arrival, I already have the data I needed.
[06:51] <ddaa> spiv: listbranches seems to be old supermirror
[06:51] <spiv> ddaa: That's interesting.  Neither do I at the moment, but I should be getting access to the logfiles soon, which may tell me something.
[06:51] <spiv> ddaa: jblack code then?  I know nothing of it.
[06:51] <ddaa> I think we are just being brutaly DOSed
[06:51] <cprov> kiko: how do you mean ? did you identify the bogus spn creation ?
[06:52] <ddaa> Znarl: if you have a network activity log somewhere, it might tell something interesting
[06:52] <kiko> cprov, I have at least times and names that were created
[06:52] <kiko> that should allow us to debug better
[06:52] <ddaa> maybe a spam harvester run amok
[06:53] <cprov> kiko: right
[06:53] <Znarl> ddaa : Restarting apache will kill off all these old moin processes.
[06:53] <ddaa> oh, right, the moin thingies have completely crazy cpu times
[06:54] <ddaa> up to 99 mins
[06:54] <Znarl> Yes, moin is running as part of wiki.gnuarch.org.
[06:55] <ddaa> Znarl: is that regular cgi?
[06:55] <ddaa> because 99 mins cpu time for a regular one-off moin.cgi process is a caracterised DOS
[06:57] <Znarl> ddaa : Yes, I've never seen moin do this before.  
[06:58] <ddaa> Znarl: okay, now that we have that one out of the way, it looks like old supermirror is burning
[06:59] <ddaa> it looks like something is wrong the the cron
[07:00] <ddaa> there are two cron.daily runs atm
[07:00] <ddaa> and large number of listbranches cronjobs too
[07:00] <ddaa> should probably be safe to kill all the listbranches
[07:01] <Znarl> ddaa : You'd like me to kill off the listbranches?
[07:01] <ddaa> mh
[07:01] <ddaa> maybe not necessary
[07:02] <ddaa> I know that jblack stuff is designed to work in massively parallel fashion
[07:02] <ddaa> so the "thundering herd of cronscripts" thing is probably normal
[07:02] <ddaa> Znarl: though you probably want to disable updatedb from the cron.daily
[07:03] <ddaa> especially because the old supermirror involves an insane filesystem hierarchy
[07:03] <cprov> Znarl: RT #9209, let me know when it's done, thank you
[07:04] <ddaa> Znarl: I think the load should decrease to something reasonable now
[07:05] <Znarl> ddaa : OK, lets leave it for a few hours and see if it recovers instead of killing? 
[07:05] <ddaa> yup
[07:05] <Znarl> Load seems to be staying around 85 presently.
[07:05] <ddaa> now, it's steadily decreasing
[07:07] <ddaa> Znarl: please disable updatedb too
[07:07] <ddaa> it's a waste of i/o bandwidth on this system
[07:08] <Znarl> ddaa : OK, good idea.
[07:10] <Znarl> ddaa, kiko : Thanks for your help.
[07:10] <Kamion> I'm getting timeouts on all my attempts to fetch translations at the moment; is this known?
[07:10] <Kamion> (OOPS-138C492 e.g.)
[07:10] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/138C492
[07:11] <Kamion> it's rather urgent as I need to finalise translations before distro RC freeze
[07:11] <kiko> let's see
[07:15] <kiko> Kamion, the language table is locked, apparently.
[07:15] <kiko> Kamion, have you retried since and obtained a more recent OOPS?
[07:15] <kiko> Kamion, what are you trying to do, btw?
[07:16] <kiko> view the desktop pots?
[07:16] <Kamion> I retried a few times ...
[07:16] <Kamion> fetch https://launchpad.net/distros/ubuntu/dapper/+source/ubiquity/+pots/desktop and https://launchpad.net/distros/ubuntu/dapper/+source/debian-installer/+pots/debian-installer which aren't subject to language packs, I need to integrate them into the packaging
[07:16] <Kamion> OOPS-138A573
[07:16] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/138A573
[07:16] <kiko> Kamion, so basically download those translations?
[07:16] <Kamion> yes
[07:16] <kiko> yes, language table locked. how strange.
[07:23] <kiko> Kamion, so far no luck. I'm a bit confused because a lock could not hold on to this table for so long, I thought
[07:23] <kiko> carlos, stub: ping?
[07:27] <stub> yo
[07:28] <kiko> stub, can you check up on kamion's oops? Language table seems to be locked... 
[07:28] <kiko> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-05-18/C492
[07:28] <kiko> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-05-18/A573
[07:28] <kiko> been locked for at least 20 minutes, stub 
[07:28] <stub> Try again - I was dropping a large index
[07:29] <salgado> kiko, http://shipit.async.com.br/requests
[07:30] <kiko> salgado, connection refused.
[07:30] <salgado> had to restart, sorry. 
[07:31] <kiko> stub, works now, thanks.
[07:31] <salgado> it's up again
[07:31] <kiko> Kamion, should be working, sorry
[07:32] <kiko> s/All/Any
[07:32] <kiko> oh mmm
[07:32] <Znarl> ddaa : CRITICAL - load average: 26.02, 41.00, 70.44 
[07:32] <ddaa> looks like it's returning to normal
[07:33] <Kamion> kiko,stub: works now. thanks!
[07:33] <kiko> Kamion, sorry bout that
[07:33] <kiko> ddaa, good work
[07:33] <Kamion> no problem
[08:07] <Kamion> hmm, publisher blowing up now
[08:07] <Kamion> http://librarian.launchpad.net/2735165/u65u22gL5U0AUkGbYhKvKVa4gGS.txt
[08:07] <Kamion> I think I might just retry that, looks like it could be transient
[08:12] <kiko> Kamion, yes, just retry.
[08:12] <kiko> somebody's working on the importqueue
[08:15] <Kamion> it's running now and apparently working
[08:15] <Kamion> sorry to be are-we-there-yet, it's a rather stressful day in distro-land
[08:59] <kiko> Kamion, no worries, help as I can
[09:47] <cprov> kiko: miscreated spn bug reproduced, do you want do discuss the fix ?
[09:47] <kiko> yep
[09:47] <kiko> I have the fix I think
[09:47] <kiko> come on down
[09:50] <cprov> kiko: yup
[10:40] <mdke> spiv: around?
[10:41] <bradb> kiko: do you have time for a drive-by for bug 33882? it's a bug mark pointed out the other day.
[10:41] <Ubugtu> Malone bug 33882 in malone "Critical bugs are listed as 8 in the side bar, but there actually aren't any" [Normal,In progress]  http://launchpad.net/bugs/33882
[10:49] <kiko> bradb, yes I do.
[10:51] <bradb> kiko: cool, https://chinstrap.ubuntu.com/~dsilvers/paste/filec9m2wg.html
[10:53] <kiko> bradb, can we convert getSearchFilterUrl to have explicit params instead of the **?
[10:53] <kiko> the ** is what let the bug appear.
[10:53] <kiko> that's my main reservation.
[10:53] <bradb> Hm? The bug appeared because some URLs and some search count queries were just wrong.
[10:54] <kiko> -            unassigned='on')
[10:54] <kiko> bradb, is unassigned='on' still valid? see what I mean?
[10:54] <sistpoty> hi folks
[10:56] <bradb> kiko: Ok. Is it sufficient to define enough of the API to work for what it's currently being used for? (i.e. just status, assignee, etc.)
[10:56] <kiko> bradb, just do it all!
[10:56] <kiko> what difference should it may?
[10:56] <kiko> make
[10:57] <bradb> just seems to be adding unneeded code
[10:57] <kiko> hmm
[10:57] <kiko> do you understand what I'm suggesting?
[10:58] <kiko> removing **extra_params
[10:58] <bradb> yep
[10:58] <bradb> replacing it with explicit kw args
[10:58] <kiko> right
[10:58] <bradb> I'm just wondering if we need to define all the possible filter args, even though this few only uses like three or four of them
[10:59] <bradb> s/this few/this view/
[10:59] <kiko> let's see
[11:00] <kiko> oh
[11:00] <kiko> ISWYM
[11:00] <kiko> is there a place where we can read the standard form schema from?
[11:02] <bradb> this portlet doesn't have a form. can you elaborate on what you have in mind?
[11:02] <kiko> well
[11:02] <kiko> I would like us to be able to determine which options are valid
[11:02] <kiko> instead of supplying anything via **extra_params
[11:02] <kiko> if you have a set of fixed options
[11:02] <kiko> you could validate
[11:03] <kiko> to see if an extra_param had been supplied which you did not expect
[11:03] <bradb> i'm suggesting something like def getSearchFilterURL(self, assignee, status, ...):
[11:03] <kiko> bradb, okay. so what are you asking, then? :)
[11:04] <bradb> if doing the above for *just the params we use* is ok, or if you want it to be def getSearchFilterURL(self, assignee, status, every, other, possible, param, that, exists, even, though, we, dont, use, them, here):
[11:04] <kiko> oh!
[11:04] <kiko> no, just the params we use of course
[11:04] <bradb> ok :)
[11:04] <kiko> if you wanted to do the complete solution
[11:05] <kiko> you could try and obtain a list of such params
[11:05] <kiko> and then, well, use kwargs and validate the kwargs with them. but that's fluff.
[11:05] <kiko> good work
[11:05] <kiko> bbiab
[11:05] <bradb> cheers
[11:51] <dilys> Merge to devel/launchpad/: [r=kiko]  Fix bug 33882 (Critical bugs are listed as 8 in the side bar, but there actually aren't any) (r3572: Brad Bollenbach)
[11:51] <Ubugtu> Malone bug 33882 in malone "Critical bugs are listed as 8 in the side bar, but there actually aren't any" [Normal,In progress]  http://launchpad.net/bugs/33882
[11:54] <marienz> I'm probably just being daft, but why does launchpad.net/people/marienz/ tell me "Ubuntero:  Not yet"? What's an ubuntero?
[11:54] <LarstiQ> marienz: someone who has agreed to and signed the code of conduct
[11:55] <marienz> ahhh
[11:55] <LarstiQ> marienz: btw, you're not at SANE, are you?
[11:55] <marienz> err
[11:55] <marienz> what's a SANE? :)
[11:56] <LarstiQ> marienz: sane.nl
[11:56] <LarstiQ> sane2006 is taking place this week in Delft
[11:56] <marienz> ahh, nope