[12:20] <dilys> Merge to devel/launchpad: Fixed the getPOTemplateByPath method + test added [r=kiko]  (r2974: Carlos Perell Marn)
[12:26] <elmo> emperor should be back
[12:26] <lifeless> thanks
[12:26] <lifeless> lp started
[12:27] <elmo> hmm, how long should it take to come up?
[12:27] <lifeless> less long than it has
[12:27] <lifeless> I'm watching logs
[12:29] <lifeless> so, lp is not connecting
[12:29] <elmo> hmm, authserver is
[12:29] <lifeless> yes
[12:30] <lifeless> I can connect manually
[12:30] <elmo> are the app server instances connecting ok, and maybe pound has just gotten confused?
[12:30] <lifeless> no
[12:30] <lifeless> we had stale app server processes
[12:31] <elmo> sure?  theinstances haven't beent alking to  pound.  If I was pound, I'd be upset too
[12:31] <lifeless> failed to shutdown properly
[12:31] <elmo> hmm, ok
[12:31] <lifeless> there
[12:31] <lifeless> its up
[12:31] <elmo> ok, cool, if you're happy, I'm out of here, need to head back to the office
[12:31] <lifeless> ok
[12:31] <elmo> pls call if it does down again
[12:31] <lifeless> can you spare a sec to say what happened ?
[12:32] <lifeless> ok everybody, lp is back
[12:33] <mpt> A roar of appreciation erupts from the crowd
[12:34] <ajmitch_> wonderful
[02:54] <Notoy> hi
[02:57] <mpt> hello
[04:38] <dilys> Merge to devel/launchpad: [r=jamesh]  Implements LaunchpadCapitalization, fixes bug 3508 (All wording for 'gpg' should be 'OpenPGP' when referring to the proposed standard), bug 5317 (Ubuntite/ubuntero consistency), bug 5436 (bug 'secrecy' is confusing), deletes unused templates, and cleans up some interface text (including a typo in ShipIt). (r2975: Matthew Paul Thomas)
[04:47] <mpt> woohoo
[04:49] <ajmitch> afternoon mpt 
[04:49] <mpt> hi ajmitch 
[04:49] <mpt> will you be at LCA?
[04:49] <ajmitch> I will
[04:49] <mpt> or is that a silly question?
[04:49] <mpt> good good
[04:50] <ajmitch> you will be too, I understand?
[04:50] <mpt> yep
[04:50] <ajmitch> since I saw an email from you on the delegates list
[04:51] <stub> jamesh: Do we have a scheduled time for doing the bugzilla migration?
[04:56] <stub> 'Make your middle column 6% wider!'
[04:56] <mpt> Are women unimpressed by your page layout?
[04:56] <ajmitch> mpt: can I complain about other ui inconsistencies? :)
[04:57] <mpt> No surgery required, CSS comes in pill form!
[04:58] <mpt> ajmitch, as individual bug reports, sure :-)
[04:58] <ajmitch> mpt: of course, I would hate to break the rules I try & lay down for others :)
[06:31] <jblack> ddaa: ping
[06:58] <lifeless> jamesh: ping
[06:59] <jamesh> lifeless: pong
[06:59] <lifeless> can you run the review meeting tonight ?
[06:59] <jamesh> okay
[06:59] <lifeless> thanks
[07:00] <lifeless> only problem with wednesday is debsig & openskills both fall on it
[07:02] <lifeless> I'll try to be online, cant guarantee it
[07:02] <lifeless> thanks again.
[07:02] <lifeless> tchau
[09:39] <carlos> morning
[09:56] <jamesh> reviewers meeting soon?
[09:59] <dilys> Merge to devel/launchpad: [trivial]  Drop Maintainership table and other database tweaks (r2976: Stuart Bishop)
[10:03] <jamesh> spiv, stub, SteveA : reviewer meeting
[10:03] <SteveA> hi jamesh 
[10:04] <jamesh> hi SteveA
[10:04] <stub> Hmmm... I thought you had scheduled it at some crazy hour for me so I didn't have to go :-)
[10:05] <jamesh> well, we may as well start
[10:05] <jamesh>     *
[10:05] <jamesh>       Roll call
[10:05] <jamesh>     *
[10:05] <jamesh>       Agenda
[10:05] <jamesh>     *
[10:05] <jamesh>       Next meeting
[10:05] <jamesh>     *
[10:05] <jamesh>       Queue status, calls for help.
[10:06] <SteveA> jamesh: where's lifeless today?
[10:06] <jamesh> SteveA: he is at an openskills meeting, and asked me to run the meeting
[10:07] <jamesh> is it convenient to hold the next meeting same time next week?
[10:07] <SteveA> ok
[10:07] <daf> morning
[10:08] <SteveA> jamesh: i'll be in a meeting in london, so i may or may not make it
[10:08] <SteveA> but now is as good a time as any
[10:09] <jamesh> How is everyone's review queue?
[10:09] <SteveA> i'm probably not going to get any review done for a while
[10:10] <jamesh> I've got two items that I'm working on (Brad's status-notes-as-comments branch and a soyuz UI cleanup branch from Daf)
[10:10] <jamesh> there are two items on the general queue at the moment
[10:11] <SteveA> so if my queue can be shuffled down a bit, it would help get things done
[10:12] <jamesh> SteveA: Bjorn's TicketTrackerEmailInterface branch?
[10:13] <jamesh> I can take a look at that after the ones on my queue then.
[10:13] <SteveA> ok.  i think bjorn is off this week anyway
[10:14] <jamesh> I guess that is everything then.
[10:14] <SteveA> thanks for running the meeting, jamesh 
[10:14] <jamesh> (the two items on the general queue had been moved off since I reloaded the page)
[10:14] <jamesh> meeting closed.
[10:15] <sivang> morning all
[10:15] <SteveA> hi sivan
[10:17] <sivang> Labas Stevai, already in London?
[10:21] <SteveA> yep
[10:22] <SteveA> jamesh, stub, daf, Keybuk: can i have a quick word with you on #c-m ?
[10:23] <Kinnison> Morning
[10:27] <SteveA> hi Kinnison 
[10:28] <SteveA> Kinnison: can you pop onto #c-m ?
[10:28] <Kinnison> erm yes
[10:28] <SteveA> ta
[10:33] <sabdfl> moin moin
[10:46] <sivang> moins sabdfl 
[11:40] <ddaa> Is there a way to unsubscribe somebody I subscribe to a bug by mistake?
[11:44] <jamesh> daf/SteveA: do you think there is anything that should be added/removed from https://chinstrap.ubuntu.com/~jamesh/bugzilla-migration-announcement.txt before being sent out?
[11:45] <jamesh> I haven't filled in the time for when we'll have a backup though.
[11:45] <jamesh> I mean, when we'd revert if there were problems
[11:46] <Kinnison> ddaa: afaict it's really hard to undo mistakes you make in launchpad
[11:46] <ddaa> from __future__ import timemachine
[11:46] <ddaa> ImportError: no future!
[11:49] <daf> jamesh: nitpick: capitalise "buugzilla" and "launchpad"
[11:50] <daf> I can't think of anything missing
[11:50] <Kinnison> jamesh: ....no later than HHhmm UTC.
[11:50] <Kinnison>                           ^^^^^
[11:51] <Kinnison> "make the transition smoother" => "make the transition go more smoothly"
[11:52] <Kinnison> other than that, and daf's capitalisation, seems good
[11:53] <daf> jamesh: how long will the import take?
[11:54] <jamesh> daf: a previous import took about 3 hours
[11:54] <daf> ok, so perhaps 1800 UTC is a reasonable time to revert by
[11:55] <daf> should things go wrong
[11:57] <jamesh> updated.
[11:57] <daf> great
[11:58] <jamesh> okay, so are we sending it to just u-d-a, or u-a too?
[11:59] <daf> the wiki page had two separate drafts
[12:00] <daf> the u-a one being shorter, with a different tone, and referring to the u-d-a announcement for details
[12:00] <jamesh> there are two mails on the wiki page, but that's one for before and one after
[12:01] <daf> on BugzillaImportProcess, I see headings saying "To ubuntu-announce" and "To ubuntu-devel-announce"
[12:05] <jamesh> daf: yes, and in the "The process" section above, it mentions sending a mail to u-d-a before, and a mail to u-a after.
[12:05] <daf> ah, I see
[12:05] <jamesh> so the question was whether to send the before-migration email to ubuntu-announce too
[12:06] <daf> I would say either (a) only send the before mail to u-d-a or (b) send the u-a mail after the u-d-a mail but before the migration
[12:06] <matsubara> good morning!
[12:06] <daf> bom dia diogo
[12:07] <stub> By revert do you mean switch bugzilla back on, or switch bugzilla back on and restore the production database from backup, or switch bugzilla back on and attempt to delete all the stuff that was created by the import process.
[12:07] <stub> ?
[12:07] <matsubara> daf: :) 
[12:07] <daf> stub: Launchpad will presumably be active in the meantime, so I don't think restoring production from backup is the answer
[12:08] <daf> perhaps the revert plan is under-specified
[12:09] <jamesh> stub: the second, I think (restore production db from backup)
[12:09] <daf> so LP should be down for the migration?
[12:09] <stub> ok. I'll add 'perform a full database backup' to the schedule (we need to allow 1.5 hours for that to run)
[12:10] <stub> To minimize lossage if we decide to revert
[12:10] <daf> we should add "announce LP downtime" to the process list
[12:11] <stub> daf: I don't know if it is worth having shutdown - it is unlikely we will need to revert.
[12:11] <jamesh> given the amount of testing we've done, I don't think it is very likely that a revert will be necessary
[12:11] <daf> well, if translators work on stuff during the migration, and we do have to revert, won't they lose work when we restore?
[12:11] <jamesh> the import can be run incrementally
[12:11] <daf> or are we only planning to restore Malone tables somehow?
[12:12] <stub> Sure, but we have a 100% chance they will be annoying with a 3 hour downtime window and a small chance they will be annoyed with 3 hours of data lossage.
[12:12] <daf> good point
[12:12] <Kinnison> yeah, lp downtime is becoming a severe irritation for people
[12:12] <jamesh> I am pretty sure we'd know we needed to revert before 3 hours too :)
[12:13] <daf> indeed :)
[12:13] <daf> I see little reason to suspect that things won't go smoothly
[12:13] <daf> given our test runs
[12:21] <daf> about step 4 -- the status says "landed, not in production"
[12:21] <daf> does it need to be in production?
[12:21] <daf> perhaps it went live yesterday
[12:25] <stub> Anyone know a page off the top of their head that is pretty likely to timeout?
[12:25] <daf> /people/+index
[12:26] <stub> works for me..
[12:26] <stub> Mmm..
[12:26] <daf> bah
[12:26] <stub> I could engineer one, but that would be rude
[12:27] <daf> https://launchpad.net/distros/ubuntu/breezy/+packaging
[12:30] <sivang> daf: this just timed out for me :)
[12:40] <cprov> morning dudes
[12:41] <SteveA> jamesh: just add the URL to sign up for launchpad-users
[01:00] <Keybuk> Friday 13th
[01:00] <Keybuk> who picked that day
[01:00] <sivang> hehe
[01:00] <Keybuk> you should switch Bugzilla off at 13:13 ;)
[01:00] <Keybuk> for added luck
[01:01] <sivang> how's the switch over looking atm?
[01:01] <daf> sivang: I think we have nothing to do until Friday morning
[01:02] <sivang> ah, I see.
[01:03] <daf> jamesh: did you see what I said about step 4?
[01:04] <daf> jamesh: also, shouldn't steps 10 and 11 be the other way around?
[01:09] <lifeless> hihi
[01:09] <lifeless> thanks jamesh 
[01:09] <jamesh> daf: what about step 4?
[01:09] <jamesh> lifeless: no problem.
[01:11] <daf> jamesh: the stap says "landed and is in production", while the status says "landed, not in production"
[01:11] <daf> jamesh: is that a problem?
[01:12] <daf> or is it just out of date?
[01:12] <jamesh> daf: I just changed it to "done"
[01:12] <daf> ok, thanks
[01:12] <jamesh> daf: it is in as of Monday's rollout
[01:12] <daf> I suspected as much
[01:13] <jamesh> I don't think it matters too much one way or the other about the bugzilla frontpage redirect
[01:13] <daf> fair enough
[01:14] <carlos> stub, hi, around?
[01:19] <ddaa> And thought last year was febrile...
[01:20] <Kinnison> kiko: after I've dealt with the tax office can we have a chat about soyuz production?
[01:21] <kiko> yes. cprov just produced a diagram that explains how the backend works, pretty cool.
[01:23] <ddaa> can we put that on the wiki, next to "Arch is easy, and other lies..." ?
[01:30] <lifeless> ddaa: hey - you said you were talking with sabdfl about the imports ? did you mean irc, or the email thread ?
[01:30] <ddaa> irc
[01:30] <ddaa> I finished explaining the whole issue and my proposal.
[01:30] <ddaa> The only lacking bit is sabdfl actually saying yes/no/maybe/later
[01:31] <ddaa> so I'd like to think I'm actually making progress on that issue
[01:32] <lifeless> heh
[01:33] <ddaa> If I have no answer tomorrow, I'll ask management (that is YOU) to get an answer.
[01:33] <ddaa> If you wish, I can send you the chat log.
[01:34] <kiko> ddaa, what's the problem?
[01:34] <kiko> lifeless, did you find out why the db died yesterday?
[01:34] <ddaa> kiko: obscure details about the bzr log format of rcs imports
[01:34] <ddaa> and how to document the conversion was done by launchpad, without being user-agressive
[01:35] <kiko> I don't know if I understood.
[01:35] <ddaa> The kind of stuff I would like not to bother sabdfl about, but there's an advertisement issue.
[01:35] <kiko> I doubt you should ask mark about that, really
[01:36] <ddaa> He got himself involved before. The asking mark comes from a message from lifeless asking him to approve a format I think is user-hostile.
[01:37] <ddaa> So I got everybody involved to agree on a different format, but I still need to get mark to say yes.
[01:37] <ddaa> making sense?
[01:37] <kiko> by bzr log format do you mean the format of 'bzr log'?
[01:38] <ddaa> Yes. In the Arch imports, Canonical was advertised in the arhive name.
[01:39] <ddaa> There is no such thing in bzr, and sabdfl says "the data should be user-friendly but should subtly but visibly say that Launchpad is involved". So some decision has to be made with his approval.
[01:39] <kiko> because of the user or host, I imagine?
[01:39] <ddaa> yes, it was something like product@bazaar.canonical.com
[01:41] <kiko> ddaa, we could still have the committer be in a similar format, couldn't we?
[01:41] <ddaa> That is undesirable.
[01:41] <ddaa> bug 6648
[01:41] <Ubugtu> Malone bug 6648: "RCS import should set commiter to user@repo" Fix req. for: launchpad (upstream), Severity: Wishlist, Assigned to: David Allouche, Status: Confirmed http://launchpad.net/bugs/6648
[01:42] <kiko> sounds like a similar problem to the malone from: address in a way. 
[01:42] <ddaa> I have a proposal, but it's significantly different from what sabdfl and lifeless agreed on before.
[01:43] <ddaa> It's really user friendly, which means the advertisement is easy to ignore.
[01:43] <kiko> the malone email is directly sent by malone and may contain metadata change information, but a comment is verbatim what the end-user wrote, and the metadata changes are a result of his actions.
[01:43] <kiko> what do you suggest?
[01:43] <lifeless> ddaa: chat log would be useful I think
[01:44] <ddaa> lifeless: will mail to you, it's long, I need to improve my executive summarizing skills.
[01:44] <lifeless> ddaa: np
[01:44] <lifeless> thanks
[01:46] <ddaa> kiko: do not touch the commit message. Do not add a dummy email address in the committer. Add a revision property "converted-by: launchpad.net". Bzr will be modified soon to display revision properties by default. This property can be extended later to contain more useful information (e.g. "converted-by: launchpad.net from cvs.sourceforge.net:/cvsroot/liba52 a52dec MAIN").
[01:47] <kiko> sounds good.
[01:47] <kiko> and is SteveA around?
[01:48] <daf> kiko: SteveA is in meetings in London
[01:49] <daf> kiko: and is generally not around
[01:50] <kiko> I know the first part, and I'm unhappy with the second.
[01:50] <ddaa> sabdfl is asking me to mail him the chat log right now
[01:51] <kiko> daf, did we ever talk about a specific date for the pair-programming sessions?
[01:51] <daf> not that I recall
[01:51] <daf> was there even any mail about it?
[01:51] <kiko> I think there was one message from steve.
[01:52] <daf> on lp@l.c.c?
[01:52] <kiko> yeah
[01:52] <daf> I'll dig for it
[01:53] <daf> aha
[01:53] <daf> Subject: pair programming sessions, mid-late march
[01:53] <daf> "Exact dates will be arranged next month"
[01:54] <daf> (next month being January)
[01:56] <kiko> celso needs to get married in march.
[01:56] <lifeless> just like that ?
[01:56] <kiko> we should kick off discussion of dates
[01:56] <lifeless> ddaa: heh
[01:58] <daf> kiko: presumably we're going to start and end on a weekend
[01:58] <kiko> daf, the question is how many weeks.
[01:58] <bradb> jamesh: Hi. Any news on the status notes as comment review?
[01:59] <daf> Steve's email says "a couple"
[01:59] <daf> == 2
[01:59] <ddaa> did I mention I'd prefer to have the sprint in London?
[02:00] <daf> you did, just now
[02:00] <kiko> ddaa, because it's expensive, polluted, cold and has bad weather, worse food?
[02:01] <ddaa> because it's more central, lively, has better breakfasts, and frankly scares me less than brazil.
[02:01] <daf> f) all of the above
[02:01] <ddaa> I'm sorry, but I just don't feel comfortable in br.
[02:02] <ddaa> But hey, I won't complain (much) either way.
[02:12] <kiko> brazil is scary?
[02:12] <kiko> you should have gone to rio
[02:12] <kiko> better breakfasts than brazil?!
[02:13] <stub> Bangkok is nice that time of year
[02:13] <ddaa> british breakfast are the best in the world, actually that's the only good thing about british cooking :)
[02:14] <stub> carlos: pong
[02:14] <carlos> stub, hi, would be possible to get the new cherrypick and renable the poimport script before you leave today?
[02:14] <stub> I tried the cherry pick, but it failed with a bzr error. I've bounced it to lifeless
[02:15] <carlos> stub, ok
[02:15] <stub> So probably not, unless it is really really urgent in which case I might be able to apply a diff manually or something
[02:15] <carlos> stub, well, we don't have .po imports since last week
[02:15] <carlos> it's urgent but I'm not sure if it's so urgent
[02:16] <carlos> stub, it depends on the time that will take to get it fixed properly
[02:16] <carlos> s/fixed/merged/
[02:16] <stub> I'll sort it tomorrow either way. 
[02:16] <carlos> If you think tomorrow could be done, we can wait
[02:16] <carlos> ok
[02:16] <carlos> stub, thanks
[02:19] <stub> kiko: I emailed the launchpad list with the information I have on the db outage. Emperor threw a disk, rebuilt the array with the hot spare, and dropped dead.
[02:19] <kiko> weird.
[02:19] <stub> panic when the array reported 'everything is fine now'
[02:20] <lifeless> the disk was thrown the day before
[02:20] <lifeless> admins repaired that and triggered the rebuild
[02:20] <Seveas> During the bugzilla migration, will bugzilla entries contribute to a persons karma?
[02:20] <stub> close ;)
[02:21] <kiko> Seveas, that's a question jamesh and the source code could answer.
[02:22] <stub> I think it depends if we fixed it so that scripts don't publish karma events, ever.
[02:22] <stub> I'm not fussed either way. The peoples whos karma will bloat probably deserve it, even if technically they shouldn't get it because it wasn't launchpad usage.
[02:23] <daf> the people whose karma would bloat are going to be the people who get most karma as they start using Launchpad heavilyu
[02:23] <Seveas> indeed
[02:24] <Seveas> I've been quite active in the zilla and will do the same in malone
[02:24] <daf> my karma has bloated a lot since I started using Malone heavily
[02:24] <kiko> I think he reason stub is mostly unfussed is because he doesn't care about karma :)
[02:24] <Seveas> will malone post all bug mails to the ubuntu-bug lists the way bugzilla does it now?
[02:24] <ddaa> who does? I mean, what are the use cases?
[02:25] <Seveas> combined with the malone mail interface that would be very convenient
[02:25] <Seveas> Or is there a way to subscribe a mail address to all bug mails?
[02:25] <daf> I still think the malone mail interface documentation is too hard to find
[02:25] <daf> Seveas: yes, there is, but we don't want all bug mails to go to the list -- only Ubuntu ones
[02:26] <carlos> see you later
[02:26] <Seveas> hmm yeah, that's true...
[02:26] <Seveas> I'd love to have a feature that allows me to subscribe to all ubuntu bugs and support requests
[02:27] <Kinnison> kiko: okay dude, I have a few minutes while I wait for the bank to produce some details I need
[02:27] <Kinnison> kiko: can I grab a bite to eat and then we'll chat?
[02:28] <kiko> I guess
[02:29] <bradb> Seveas: Malone supports a distro-wide bug contact, which could be set up to get all Ubuntu bugmail, which I presume will be set to a team with the ubuntu-bugs@ address.
[02:30] <jordi> carlos: any news on the import queue breakage?
[02:30] <kiko> right
[02:30] <kiko> Seveas, you can also ask to be added as a bug contact
[02:32] <Seveas> whom to ask?
[02:33] <bradb> Seveas: You can only do that per package, currently
[02:33] <kiko> that's a good question. whoever owns Ubuntu, I suspect.
[02:35] <sivang> bradb: so there's no way to get bugspam for an entire distro/product?
[02:35] <sivang> bradb: or rather, product groups
[02:36] <bradb> sivang: Depends on how it's configured.
[02:36] <Seveas> that would be bad
[02:36] <stub> If you want all Ubuntu bugs, you subscribe to the mailing list that the notices get sent to. 
[02:36] <bradb> sivang: I imagine the Ubuntu devs will set the bug contact to a team with the ubuntu-bugs@ email address.
[02:36] <bradb> So, if you're sub'd to u-b@, you'll get all bugmail.
[02:36] <sivang> bradb: ah, right,. that will be ok then
[02:36] <bradb> Same idea with products.
[02:37] <sivang> and product groups ;-)
[02:37] <Seveas> then I'll poke some ubuntu devs whether that'll be setup
[02:37] <Seveas> and for support requests it's the same i guess?
[02:37] <Kinnison> kiko: Right, I've gotta go to the bank during today so what I'll do is skip lunch now, and grab something between returning bob's funeral suit and going to the bank
[02:37] <Kinnison> kiko: so if you have time now, shall we discuss the situation?
[02:37] <bradb> Seveas: I don't know if the same thing exists for support requests.
[02:38] <kiko> Kinnison, sounds okay. what channel?
[02:38] <sivang> Seveas: that would require we setup community-support@ :-)
[02:38] <Kinnison> kiko: soyuz channel?
[02:38] <Seveas> sivang, it would be nice
[02:39] <Seveas> because I like getting support requests in the mail much more than polling for them
[02:40] <bradb> Oh, one other thing about the distro-wide bug contacts: you'll only get bugmail from bugs opened after the moment that the bug contact was set. All bugmail generated by bugs opened before that moment will not be sent to u-b@.
[02:40] <Seveas> hmm
[02:41] <Seveas> can you see whether there xurrently is a distro-wide contact, or hould I be able to see that myself?
[02:41] <kiko> bradb, though we will subscribe u-b@ to all imported bugs during the migration, correct?
[02:41] <daf> bradb: so it's an explicit subscription?
[02:41] <daf> hmm, Malone doesn't have an "unpreproducible" status
[02:41] <bradb> kiko: Not that I know of, but jamesh would have to confirm.
[02:42] <bradb> daf: Yes, explicit.
[02:42] <daf> in a sense, that's the same as "unconfirmed", but I want a status that means "somebody looked at this bug and *tried* to reproduce it, but failed"
[02:43] <daf> I could reject the bug, but I don't really want to do that
[02:43] <sivang> daf: worksforme ?
[02:43] <daf> but I have triaged it, so I don't want to leave it unconfirmed
[02:43] <kiko> daf, thatinvalid
[02:43] <kiko> daf, if you are unable to reproduce, you haven't finished triaging it.
[02:43] <daf> we don't have a worksforme or thatinvalid status either
[02:43] <kiko> you can only say you have reasonably finished triaging if you agree that the said bug is a bug or not.
[02:44] <daf> well, in this case:
[02:44] <daf> I suspect that the page in question timed out due to a cron script running at the same time causing contention
[02:44] <daf> but I can't prove that
[02:44] <daf> even though it may be unlikely that it will happen again for the same page
[02:45] <daf> I can't make the page time out
[02:45] <daf> in fact, it's quite snappy
[02:45] <kiko> you can confirm it based on your suspicion, or you can invalidate it and wait for it to reoccur.
[02:45] <bradb> Seveas: You won't be able to set it. Exposing whether or not one is currently set needs some tweaking. It's current visible from a package's bugmail settings page, e.g., https://launchpad.net/distros/ubuntu/+source/lilypond/+subscribe
[02:45] <daf> invalidate == reject in Maloneland
[02:45] <daf> so, I guess I'll reject with an invitation to reopen
[02:46] <dilys> Merge to devel/launchpad: r=kiko Fixes bug 6571 (No Initial Confirmation Upon Clicking Join ). Patch by Diogo Matsubara <matsubara@async.com.br> (r2977: Diogo Matsubara, kiko)
[02:46] <kiko> right
[02:46] <matsubara> :)
[02:46] <jamesh> kiko: we haven't done so yet.  I can look at setting ubuntu-bugs as the distro contact when I do the migration if no one else has done so yet
[02:46] <kiko> jamesh, well, let me chat with you about this for a while.
[02:46] <Seveas> ok, thanks for all the info, I shall poke a few Ubuntu devs about this, who is the one to ask, mdz perhaps?
[02:47] <kiko> the ubntu-bugs usecase really calls for it being subscribed to all existing bugs
[02:47] <kiko> all existing ubuntu bugs, mind you.
[02:47] <daf> kiko: +1
[02:47] <daf> I think implicit subscription is good in this specific case
[02:47] <kiko> jamesh, depending on how you create these bugs, ubuntu-bugs will be added or not -- and we need to make sure we need to add it.
[02:47] <kiko> daf, maybe, but let's try explicit for now, given it's simple to make it work.
[02:48] <daf> sure -- we can make that refinement in future
[02:48] <daf> it's not blocking us
[02:48] <jamesh> kiko: we can look at subscribing it to the existing bugs post-migration pretty easily
[02:48] <kiko> jamesh, via a database query?
[02:49] <jamesh> kiko: I was thinking of a simple zopeless script, but that's pretty much the same
[02:49] <Seveas> there's one distinction
[02:49] <kiko> jamesh, you don't think it's worth adding the feature to the importer?
[02:49] <Seveas> ubuntu-bugs gets all reports for ubuntu *MAIN*, not universe...
[02:49] <kiko> Seveas, it will get all bugs, period. you can filter using X-Launchpad-Bug and ubuntu-bugs mailman topics.
[02:50] <Seveas> bug reports for universe are the domain of universe-bugs@lists
[02:50] <jamesh> kiko: given that the importer is designed for a one-off conversion, I don't think it matters too much
[02:50] <kiko> jamesh, agreed.. well, just make sure you remember that, because I may forget.
[02:50] <Seveas> kiko, hmm, is the string 'universe' in that header?
[02:50] <jamesh> Seveas: by design, or just because they are in a separate trackers?
[02:50] <jamesh> kiko: could you add a note to BugzillaImportProcess at the bottom?
[02:50] <kiko> Seveas, yes.
[02:50] <kiko> jamesh, sure.
[02:50] <Seveas> kiko, phew :)
[02:51] <Seveas> jamesh, as far as I know by design, since universe is for the MOTU and not for the core devs
[02:51] <Seveas> these two groups are fairly distinct
[02:51] <sivang> indeed :)
[02:51] <jamesh> kiko: I'm going out for a bit now.  If there is any more to discuss, I'll be back later
[02:51] <Seveas> lol@quitmsg :)
[02:52] <kiko> sure.
[02:53] <kiko> there's a way that bradb could fix this easily, allowing people to say "subscribe me to all existing bugs" but that will require code.
[02:53] <bradb> We should probably create the subscriptions for all Launchpad/Rosetta/Malone bugs too
[02:53] <kiko> right.
[02:54] <bradb> kiko: It would be even easier to fix it by using implicit subscriptions.
[02:54] <Seveas> daf, btw: the malone mail interface docs are linked quite visibly from https://launchpad.net/malone, that's not 'too invisible' to me :) 
[02:55] <daf> Seveas: aha, I didn't know that
[02:55] <daf> Seveas: I don't visit the Malone front page much
[02:55] <Seveas> :)
[02:56] <kiko> bradb, no, it wouldn't.
[02:57] <kiko> implicit subscriptions are less clear, more complex to implement, don't allow selective subscription and unsubscription, and are generally less flexible.
[02:58] <bradb> kiko: They're more complex to implement, yes, but the functionality will be much clearer to the user, and yes they allow selective subscription/unsubscription.
[02:58] <kiko> how do I get out of this conversation? You are talking about ressurrecting ignore-subscriptions, a thought that makes me so sick I might close xchat
[02:59] <kiko> stub, lifeless, I have a question about the prebuilt tree
[02:59] <kiko> if I pull it and do a bzr update, do changes in sourcecode/ get updated?
[03:00] <daf> no
[03:00] <kiko> I suspected that.
[03:00] <bradb> kiko: Yes, I'm talking about resurrecting ignore-subscriptions. The user wouldn't know this though. Sub/unsub would look exactly the same whether it was an "explicit" subscription or an "implicit" one.
[03:00] <daf> kiko: I use rsync for rf-built
[03:01] <kiko> bradb, look, I see you're clearly convinced you're right, but I ask you to bear with me, and that you spent this energy on adding a subscribe-to-existing-bugs feature.
[03:02] <kiko> implicit-subs + ignore-subs + UI transparency is more work than that.
[03:04] <daf> for the distro bugs contact use case, I don't see a need for supporting selecting unsubscribe
[03:04] <daf> * selective
[03:05] <kiko> yes, you're right.
[03:05] <kiko> but a distro and package bug contact can be used for more things than ubuntu-bugs.
[03:05] <daf> for package bugs, maybe
[03:06] <kiko> well
[03:06] <daf> but for distros, you're going to be snowed under so many bugs anyway you're not going to bother unsubscribing from a few
[03:06] <kiko> well, a well-implemented triage process has people that try confirming the bugs and then unsubscribing themselves once they are confirmed.
[03:07] <daf> I agree that ignore-subs are evil
[03:07] <kiko> bugzilla has a bug filed on having initial CC lists since 1914
[03:07] <daf> ha
[03:07] <bradb> daf: Presenting an "Ignore" subscription to the user in the UI is cruel, yes.
[03:25] <kiko> ddaa, have you looked at the launchpad-error emails that have been generated by runmirror?
[03:25] <ddaa> yeah, permission problem with my branch
[03:25] <ddaa> fixed now
[03:25] <kiko> no, not all of it
[03:26] <daf> ha, I got bug #6666
[03:26] <ddaa> daf: BASTARD
[03:26] <kiko> rock on daf
[03:26] <kiko> ddaa, some samples:
[03:26] <kiko> a) OSError: [Errno 17]  File exists: '/srv/sm-ng/data/masterlock'
[03:26] <daf> (not intentionally)
[03:26] <kiko> b) AttributeError: BZR_5_6 instance has no attribute 'src'
[03:26] <kiko> c:) @BZR_ERROR:Unknown error
[03:26] <kiko> @BZR_SRC:http://people.ubuntu.com/~mdz/bazaar/ltsp/main/
[03:26] <kiko> @BZR_DEST:/srv/sm-ng/mirrors/00/00/02/13
[03:26] <kiko> exceptions.AttributeError
[03:26] <ddaa> kiko: see the recent lifeless post about the lockfile issues
[03:27] <ddaa> kiko: the b is a bug in jblack error reporting code
[03:27] <ddaa> fixed now, obviously
[03:27] <ddaa> the c) I have no damn clue, but it's jblack problem, I have access neither to the SM system nor to the code.
[03:27] <kiko> d) /srv/sm-ng/bzrs/bzr_5_6/bzrlib/lock.py:64: UserWarning: lock on <open file
[03:27] <kiko> +u'/srv/sm-ng/mirrors/00/00/02/28/.bzr/branch-lock', mode 'wb' at 0xb79137b8> not released
[03:27] <kiko>   warn("lock on %r not released" % self.f)
[03:28] <ddaa> d) ditto
[03:28] <kiko> and e) various errors on http://people.ubuntu.com/~jamesh/bzr.smallfixes http://people.ubuntu.com/~jamesh/bzr.sftp and http://ddaa.net/bazaar/bzr.ddaa
[03:28] <ddaa> errors on bzr.ddaa, bad perms on my branch, fixed now
[03:28] <ddaa> others, well, I have not investigated, jblack would know, probably
[03:28] <ddaa> or the branch owner
[03:29] <kiko> maybe you could make the errors easier to parse -- a simple WARNING for broken perms would suffice
[03:29] <ddaa> I do not have access to the code or the system running it
[03:29] <ddaa> besides, I already have enough fish to fry...
[03:30] <ddaa> jblack is currently writing exception handlers for the common errors found in the wild
[03:30] <ddaa> so they can be reported back to launchpad intelligently when we write the xmlrpc interface to let the SM talk to launchpad.
[03:31] <ddaa> the error spam is intentional, I had to ask for loudly and intentionally, because I want some visibility.
[03:31] <ddaa> kiko: IOW, don't panic, the situation is under control
[03:31] <daf> kiko: bug 2696 -- where would we link from?
[03:31] <ddaa> mostly
[03:31] <Ubugtu> Malone bug 2696: "The launchpad RDF refers its xmlns to a page which doesn't exist" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Diogo Matsubara, Status: Unconfirmed http://launchpad.net/bugs/2696
[03:32] <kiko> ddaa, I'm just suggesting the logs behave more normally like other scripts -- not a major refactoring. but..
[03:32] <ddaa> kiko: I think that would be a good idea. But you are asking the wrong person.
[03:33] <kiko> ddaa, I did not know jblack was responsible for that code
[03:33] <kiko> daf, yeah, it's a good question. I wonder if we can add it to the actual RDF output for a start. perhaps a portlet in the main page? <wince>
[03:33] <ddaa> kiko: here's your rule of thumb: if the supermirro works, it's my fault, if it does not, it's jblack ;)
[03:34] <kiko> ddaa, are you going to fix bug 6603?
[03:34] <daf> kiko: RDF output doesn't have portlets
[03:34] <kiko> daf, I meant to the launchpad main page
[03:34] <kiko> launchpad.net/
[03:34] <ddaa> Ubugtu: bug 6603, pretty please
[03:34] <Ubugtu> Error: 'pretty' is not a valid bug id.
[03:34] <Ubugtu> Malone bug 6603: "Cannot register sftp:// branch url" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: David Allouche, Status: Confirmed http://launchpad.net/bugs/6603
[03:34] <kiko> wtf
[03:34] <kiko> Seveas?
[03:35] <Seveas> ghe
[03:35] <bradb> jamesh: ping
[03:35] <daf> kiko: I don't see a likely place for it there
[03:35] <daf> kiko: maybe on the wiki?
[03:35] <ddaa> kiko: at some point in the future when the sky is no longer falling over around the importd-bzr transition, yes.
[03:35] <Seveas> kiko, bu.g 123, 456 is also a trigger
[03:35] <kiko> ddaa, I'll just ask matsubara to do it.
[03:35] <daf> kiko: if we had a consistent way of organising user documentation, I think the answer might be obvious
[03:36] <ddaa> kiko: by all means
[03:36] <kiko> daf, that's a given. I think the home page portlet might help add some visibility to the fact we did spend considerable effort on RDF export
[03:36] <bradb> SteveA: I responded to your review reply.
[03:37] <daf> kiko: well, if you can get it past mpt :)
[03:38] <kiko> heh
[03:40] <daf> bradb: I wouldn't rely on SteveA getting that message
[03:41] <bradb> I know he's busy in London.
[03:41] <daf> ok, just checking
[03:41] <ddaa> the pull/push slowness is killing my productivity :(
[03:42] <daf> kiko: otoh, that page is not very useful ATM, which weakens the case for a front page link to it
[03:42] <daf> if it had more information about it, perhaps
[03:43] <kiko> it should probably list all the RDF exports we have
[03:43] <kiko> as a central place to find them
[03:43] <kiko> Launchpad RDF central!
[03:43] <daf> er
[03:43] <daf> that could be many many
[03:43] <daf> we'd need batching and searching
[03:44] <daf> every product has an RDF link, yesno?
[03:44] <daf> e.g. https://launchpad.net/products/launchpad/+rdf
[03:44] <kiko> yeah, I was thinking more of listing types of RDF exports we did, perhaps with some example or top links.
[03:45] <daf> ohh
[03:45] <daf> right, yes
[03:45] <daf> so, you could open a new bug "make RDF page more informative"
[03:46] <kiko> I mean, the RDF stuff is pretty invisible today
[03:47] <daf> what use cases do we have for it?
[03:47] <bradb> ddaa: I find doing cp -a ..../rocketfuel-built/launchpad my-branch-name on chinstrap, and then bzr push --overwrite --no-tree to be pretty fast. Do you do that?
[03:47] <daf> should we write some sample tools to use it?
[03:47] <ddaa> bradb: I do
[03:47] <daf> will existing DOAP tools be able to use it?
[03:47] <kiko> daf, it's not something that I think we should spend effort on today, given the current set of fires
[03:47] <bradb> ddaa: Oh :/
[03:47] <kiko> our DOAP is incompatible :-(
[03:48] <LarstiQ> ddaa: sftp/rsync?
[03:48] <LarstiQ> since --no-tree seems to be an rsync option
[03:48] <ddaa> the pain is that I use a local mirror of warthogs/archives/david to push my branches to from my working launchpad, and from where I push to chinstrap and send merge requests
[03:48] <daf> kiko: indeed, it's not high priority
[03:48] <ddaa> And pushing a big rocketfuel merge to such branches take forever
[03:48] <daf> kiko: perhaps we should think about RDF in a more general way in the next LP spec meeting
[03:49] <ddaa> and rsyinc push does not work in that case, unless I want to install a ssh server, which I don't.
[03:49] <kiko> daf, I emailed mpt about it.
[03:49] <kiko> let's see what he thinks
[03:49] <ddaa> What I end up doing is copying or rsyncing the .bzr manually, then cleaning up the tree, but even that takes a looooong time.
[03:49] <LarstiQ> ddaa: in that case, it is indeed rather painful
[03:50] <ddaa> bzr status has been running for 5 mins now on such a tree...
[03:51] <daf> kiko: ok, I'm going to change the title/description of 2696
[03:51] <kiko> cool.
[03:53] <LarstiQ> ddaa: would Denys' patch at r1516 on http://delta.univ-orleans.fr/~duchier/bzr/bzr.call_at_end help?
[03:53] <ddaa> Dunno what that does, but I do not think so. Knit would help. Hugely.
[03:54] <ddaa> Or some C or pyrex for the CPU intensive parts.
[03:54] <LarstiQ> ddaa: it sped up bzr st for him
[03:54] <ddaa> bzr status is not the most painful, it's the multi-hours push and pull
[03:55] <ddaa> besides, what's taking so long here is (I guess) regenerating the statcache on my i/o-challenged ibook.
[03:55] <LarstiQ> ddaa: statcache is the huge factor involved with status
[03:55] <ddaa> mh... no it's cpu...
[03:55] <ddaa> *shrug*
[03:56] <ddaa> The thing is that I do not have time to fiddle with bzr... :(
[03:57] <LarstiQ> we'll see how it works out then
[04:34] <ddaa> matsubara's merge has been running for two hours on pqm...
[04:36] <daf> the status page can sometimes be misleading
[04:36] <daf> in that the first one has sometimes already been done
[04:38] <ddaa> okay, I'll complain again if it has not made visible progress tomorrow
[04:39] <daf> on the other hand, it was showing the same status 2 hours ago, so it may be wedged
[04:39] <ddaa> that's what I'm saying :)
[04:39] <daf> can anyone except lifeless fix it?
[04:40] <ddaa> elmo, pull the plug, please :)
[04:42] <elmo> done
[04:43] <daf> kiko-fud: one of your merges got nuked
[04:56] <bradb> How many production servers is Launchpad being run on now? It seems faster, but maybe I'm just imagining it.
[04:57] <daf> still two as far as I know
[04:58] <bradb> Have they had any hardware upgrades recently?
[04:58] <elmo> it's got two physical frontends, one backend
[04:58] <elmo> the backend hasn't changed; stub only recently brought up the 2nd physical frontend
[04:58] <elmo> and none of them have been upgraded hardware wise
[04:59] <dilys> Merge to devel/launchpad: r=kiko Fixes bug 6571 (No Initial Confirmation Upon Clicking Join ). Patch by Diogo Matsubara <matsubara@async.com.br> (r2978)
[05:00] <bradb> elmo: i.e. A second app server started running on a 2nd machine recently, and there's only one database server?
[05:01] <daf> it can't have been that recently -- we've been getting separate OOPS reports for a wihle now
[05:01] <daf> perhaps the scarcity of cron scripts is making it snappier
[05:02] <bradb> That's what I was thinking. But I do remember seeing some stuff from stub lately mentioning a config change for a machine I hadn't heard of before.
[05:02] <daf> I think librarian/authserver might have been moved around
[05:02] <elmo> daf: no
[05:02] <daf> ok
[05:02] <elmo> bradb: each physical apps server runs 2 launchpad instances
[05:03] <elmo> bradb: so, up until <n> days ago, we had 2 instances running on one box (gangotri)
[05:03] <elmo> bradb: stub recently brought up gandwana as a second apps server, so we now have 4 instances in total
[05:03] <bradb> elmo: Ah, nice, that would explain the extra snappiness. Thanks for the info.
[05:03] <elmo> however, this is all fairly moot, I would WAG that  any speedup is much more likely to do with performance work stub has been doing on the backend
[05:04] <bradb> ok
[05:04] <daf> we did upgrade to Postgres 8 recently
[05:04] <daf> among other things
[05:06] <daf> ddaa: weird: dilys reported kiko's first merge twice, but yours is gone from the queue and never got reported
[05:06] <ddaa> that's intentional
[05:06] <ddaa> I broke the merge by renaming the branch
[05:06] <ddaa> I sent the merge request from the wrong directory
[05:06] <daf> ah
[05:07] <ddaa> I've been bzr wrangling for hours to get the right branch in place...
[05:12] <ddaa> I assert that hiring a intern to write the perf critical parts of bzr in C would actually be a net saving for the company.
[05:13] <daf> I think the problem is that it's a moving target
[05:13] <daf> it might be optimised now, but slow down again as soon as it moves to knits
[05:13] <ddaa> after knits, of course
[05:13] <bradb> stub: ping
[05:13] <daf> when do we get knits?
[05:14] <ddaa> no idea, it has been "soon" for quite a while now
[05:14] <daf> also, I thought a lot of the slowness was due to stat() or other IO, which C is not going to fix
[05:15] <dilys> Merge to devel/launchpad: r=kiko Fix for bug 3293, hiding forbidden action links from personal page. Also fixes bug 3068, ensuring that we properly verify that Poll names are unique instead of blowing up. Fixes by Gabriel Neuman <gneuman@async.com.br> (r2979)
[05:15] <ddaa> here, most of the slowness is cause by CPU usage.
[05:16] <ddaa> elmo: can you install the launchpad deps and baz on escudero, please?
[05:17] <elmo> ddaa: RT it please?
[05:17] <ddaa> already done
[05:18] <ddaa> #945
[05:18] <elmo> oh, I see
[05:22] <ddaa> elmo: and a compiler would help, too :)
[05:24] <sivang> daf: who's knits?
[05:24] <ddaa> new storage format for bzr
[05:28] <daf> the successor to weaves
[05:28] <SteveA> bradb: you're approved!
[05:28] <bradb> SteveA: thanks :)
[05:44] <elmo> ddaa: (done)
[05:44] <ddaa> thank you
[05:46] <ddaa> Before this bzrsyncd and importd2bzr I had no freaking idea how much work it was to roll out a new service...
[05:46] <kiko> if it involves multiple machines..
[05:48] <dilys> Merge to devel/launchpad: r=kiko Fix for bug 3293, hiding forbidden action links from personal page. Also fixes bug 3068, ensuring that we properly verify that Poll names are unique instead of blowing up. Fixes by Gabriel Neuman <gneuman@async.com.br> (r2980)
[05:48] <kiko> hooray empty merges
[05:50] <bradb> Why does this happen?
[05:50] <bradb> bradb@oxygen:~/canonical/malone-smallfixes $ cat .bzr/x-push-data 
[05:50] <bradb> chinstrap:/home/warthogs/archives/bradb/launchpad/malone-smallfixes/
[05:50] <bradb> bradb@oxygen:~/canonical/malone-smallfixes $ bzr push
[05:50] <bradb> bzr: ERROR: No push location known or specified.
[05:50] <ddaa> try with --overwrite
[05:51] <bradb> Same error.
[05:51] <bradb> I updated bzr this morning, so maybe something changed.
[05:51] <ddaa> mh... check in your ~/.bazaar/ dir, there might be some config there
[05:52] <bradb> bradb@oxygen:~/canonical/malone-smallfixes $ bzr push `cat .bzr/x-push-data`
[05:52] <bradb> bzr: ERROR: Parent directory of chinstrap:/home/warthogs/archives/bradb/launchpad/malone-smallfixes/ does not exist.
[05:53] <LarstiQ> there we go again
[05:53] <bradb> I've experienced this problem before.
[05:53] <LarstiQ> bradb: you're using rsync?
[05:53] <bradb> Yeah, just like I did yesterday.
[05:53] <LarstiQ> right, and chinstrap:/home/warthogs/archives/bradb/launchpad/ exists?
[05:53] <bradb> yep
[05:54] <bradb> This all worked just fine yesterday on this branch.
[05:54] <LarstiQ> then you have me stumped
[05:56] <bradb> bzr push sftp://chinstrap.ubuntu.com//home/warthogs/archives/bradb/launchpad/malone-smallfixes/ is doing "get destination ancestry 0/0" right now
[05:57] <kiko> ddaa, is it possible to submit a merge request for a specific version?
[05:57] <Kinnison> urgh, don't use sftp push
[05:57] <LarstiQ> yeah, it is slow
[05:57] <Kinnison> it's so slow
[05:57] <ddaa> kiko: you mean a specific revision?
[05:57] <Kinnison> bradb: install bzrtools and use rsync push
[05:57] <Kinnison> bradb: much much faster
[05:57] <bradb> Kinnison: Slow is faster than no push at all though.
[05:57] <kiko> ddaa, yeah.
[05:58] <bradb> Kinnison: As demonstrated above, rsync push ain't working.
[05:58] <bradb> Interestingly, I just tried "sudo apt-get install bzrtools" (but I should already have that installed), and got:
[05:58] <bradb> The following packages have unmet dependencies:
[05:58] <bradb>   bzrtools: Depends: bzr (= 0.7+200512311044)
[05:59] <bradb> Maybe this morning's bzr update broke something
[05:59] <LarstiQ> bradb: what bzr are you using? tests with bzr.dev have rsync working
[05:59] <ddaa> mh... it used to be possible with Arch... I dunno with bzr. But what you can do with bzr is "bzr branch -r REVNO oldbranch newbranch" to get a branch with the revision you want as head.
[05:59] <Kinnison> bradb: bizarre.
[05:59] <bradb> LarstiQ: 0.7rc1
[05:59] <LarstiQ> bradb: ok, I'll try that one
[05:59] <bradb> I suspect that the bzrtools package was not properly updated.
[06:00] <LarstiQ> that would explain rsync breakage, yes
[06:01] <kiko> ddaa, that doesn't help PQM right now, though
[06:02] <cprov> matsubara: ping
[06:03] <matsubara> cprov: pong
[06:04] <cprov> matsubara: I wonder if you have time to fix a quick bug for me, I'm blocked on tree update and conflicts
[06:05] <matsubara> cprov: which one?
[06:05] <cprov> matsubara: 6635
[06:05] <ddaa> kiko: it allows you to work around the limitation
[06:06] <ddaa> turn a "merge a non-head revision" problem into a "merge a head revision" problem
[06:06] <cprov> matsubara: fix sqlvalues usage and write a quick test for it somewhere in doc, so easy ;) 
[06:07] <matsubara> cprov: ok, I'll start fixing as soon as I re-organize my branches.
[06:07] <stub> bradb: pong
[06:08] <cprov> matsubara: ehe, you too ... I'm in the middle of the same journey.
[06:08] <bradb> stub: Please see "Is Bug.fti being updated?" email.
[06:10] <stub> bradb: a far as I'm aware, the fti indexes are being updated on every search at the moment. I can look into your particular examples in further detail tomorrow.
[06:10] <stub> c/search/insert or update
[06:11] <bradb> stub: Ok, a sanity check on the fti's tomorrow would be great.
[06:11] <stub> I'll make sure I check production in case something weird happened during the PG8 upgrade
[06:11] <stub> Anything else before I crash?
[06:12] <bradb> sounds good, thanks
[06:12] <ddaa> stub: yes
[06:12] <ddaa> didn't you say that the db user could be customised by an environment variable?
[06:13] <kiko> ddaa, is there a special command to retire a branch, or should I just rm my copy of it?
[06:13] <ddaa> rm
[06:14] <stub> ddaa: LP_DBUSER or PGUSER environment variables might do the trick.
[06:14] <ddaa> I set LP_DBHOST and LP_DBUSER, but I get this error
[06:14] <stub> Probably LP_DBUSER - grep for it as launchpad code explicitly checks for it and uses it for an override.
[06:14] <ddaa>  line 90, in initZopeless
[06:14] <ddaa>     if '@' in dbhost or not dbuser:
[06:14] <ddaa> TypeError: iterable argument required
[06:16] <ddaa> which does not make much sense when I look at the rest of the code in lp/__init__.py... should not happen...
[06:16] <stub> It was working last time I saw that code :-/ Stick in a few print statements is my recommendation - that should make things clearer
[06:16] <ddaa> aye aye
[06:17] <stub> ''env LP_DBHOST=emperor LP_DBUSER=launchpad python foo.py' should work last I checked
[06:18] <kiko> bug 6431
[06:18] <Ubugtu> Malone bug 6431: "View Builds causes Oops if empty" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Celso Providelo, Status: Confirmed http://launchpad.net/bugs/6431
[06:24] <ddaa> found it: lib.canonical.launchpad.scripts.db_options prevents overriding of those settings through environment variables, it defines options for that purpose...
[06:24] <bradb> How do I unlock a bzr branch?
[06:24] <bradb> It seems to have remain locked after Ctrl-C'ing an sftp push
[06:24] <ddaa> yes, sftp cannot use os-level locks
[06:24] <ddaa> ask #bzr :)
[06:25] <ddaa> you can probably unlock it by pushing with rsync
[06:26] <bradb> ddaa: I can't do that, as noted earlier. The latest bzrtools package has a broken dep.
[06:29] <ddaa> elmo: one (hopefully) last request on #945
[06:30] <ddaa> I promise, running all that goo on your nice lean webserver was not my idea...
[06:35] <bradb> lifeless: ping
[06:37] <bradb> jblack: ping
[06:37] <jblack> bradb: pong
[06:37] <cprov> matsubara: don't worry about 6635, it requires tests from my uploader-test branch, already fixed it, but the commit will be delayed for a while
[06:37] <bradb> jblack: Hi. How do I unlock a branch?
[06:38] <jblack> pardon? 
[06:38] <jblack> In bzr? 
[06:38] <bradb> Yeah
[06:38] <jblack> Unless the locking code has gone in, you shouldn't need to unlock a branch. 
[06:38] <jblack> Give me a moment? 
[06:38] <bradb> sure
[06:39] <ddaa> jblack: it's an sftp lock
[06:40] <jblack> bradb: sftp to the bzr branch, and look for a file called ".write-lock"
[06:40] <jblack> is this on chinstrap? 
[06:40] <matsubara> cprov: ok.
[06:41] <bradb> jblack: back, sorry, oven was callilng
[06:42] <bradb> jblack: yes, on chinstrap
[06:42] <jblack> which branch? 
[06:42] <bradb> bradb@chinstrap /home/warthogs/archives/bradb/launchpad/malone-smallfixes $ find . -name ".write-lock"
[06:43] <bradb> bradb@chinstrap /home/warthogs/archives/bradb/launchpad/malone-smallfixes $
[06:44] <bradb> I'll give you a push paste with an error message in a sec.
[06:44] <jblack> Ok. found it
[06:44] <bradb> ?
[06:44] <jblack> look in malone-smallfixes/.bzr/
[06:44] <jblack> There's branch-lock and branch-lock.write-lock
[06:45] <bradb> right
[06:45] <jblack> How old is the lock? 
[06:45] <bradb> Should be about half an hour old
[06:45] <jblack> how old is the attempted push.
[06:45] <jblack> Ok. take out branch-lock.write-lock
[06:45] <jblack> That should fix you up
[06:46] <cprov> kiko: can I reassign bug # 6431 (Batch System None awareness) for you ?
[06:46] <kiko> cprov, uhm, ok.
[06:47] <bradb> jblack: that worked, thanks. Elsewhere, bzrtools has a broken dep after I upgraded bzr this morning, in case there's anything you can do about it.
[06:47] <jblack> bradb: I'll make sure people know. What's the dep? 
[06:47] <cprov> kiko: done, thx
[06:48] <kiko> cprov, uhm, look at this code in distroarchreleasebinarypackage.py:
[06:48] <kiko>         releases = sorted(list(bprs), key=lambda item: Version(item.version))
[06:48] <bradb> jblack: bzrtools: Depends: bzr (= 0.7+200512311044) (Looks like bzr was updated but not bzrtools)
[06:48] <kiko> cprov, this won't work for those unparseable versions right?
[06:48] <cprov> kiko: right
[06:48] <jblack> yup. ok
[06:48] <jblack> I'll tell aaron and the packager
[06:49] <kiko> @#@!#@! stupid $##@ code
[06:49] <kiko> thanks
[06:49] <bradb> jblack: thanks dude
[06:50] <cprov> kiko: move back to apt_pkg is a quick solution currently
[06:50] <cprov> kiko: IIRC I did it in other more emminent pieces of code
[06:51] <jblack> ddaa: Ping
[06:52] <cprov> kiko: precisely in archivepublisher/nascentuploads.py
[06:53] <kiko> yeah
[06:53] <kiko> Kinnison, hey?
[06:53] <Kinnison> kiko: yo
[06:54] <jblack> ddaa: unping. I'm going for food and coffee and such
[06:55] <kiko> Kinnison, is it guaranteed that only one package with that name will be PUBLISHED in a certain distroarchrelease?
[06:56] <Kinnison> kiko: Yes, if the publisher is being run
[06:56] <kiko> and if it isn't run?
[06:56] <kiko> is there a race condition?
[06:56] <Kinnison> Well, if it has never been run, nothing will be PUBLISHED
[06:57] <Kinnison> if someone has been doing SQL queries to publish things then god knows what the state will be
[06:57] <kiko> sorry. I was asking if it was /at most/ one package.
[06:57] <kiko> Kinnison, that's a good point, but given we only do a hmmm. no, if we scrub for source packages it is likely this got wrong.
[06:59] <kiko> Kinnison, well, I'm trying to fix DistroArchReleaseBinaryPackage.currentrelease
[07:00] <kiko> which currently orders using Version
[07:00] <kiko> which doesn't work and doesn't scale
[07:00] <kiko> I guess I can use datecreated
[07:01] <kiko> and get the latest one
[07:01] <kiko> but this version ordering is gross!
[07:04] <carlos> Kinnison, when you are done talking with kiko, could we talk about Ubuntu's translations import?
[07:04] <Kinnison> carlos: erm, what do we need to do to finish the job then?
[07:05] <kiko> I'm finished
[07:05] <Kinnison> kiko: I feel that way too. This tax form is huge
[07:05] <carlos> Kinnison, ok, not sure if you were done ;-)
[07:05] <kiko> vlol
[07:06] <kiko> my accountant does my tax for me
[07:06] <Kinnison> kiko: If I had thought it would be this bad, I'd have gotten an accountant
[07:06] <Kinnison> and various knowledge required to complete the forms
[07:06] <cprov> kiko: I feel like 'datecreated ~ binary_version' relation might be violated by gina process ...
[07:06] <kiko> Kinnison, just don't file this year, who cares?
[07:07] <kiko> cprov, sssshh, don't make me cry
[07:07] <Kinnison> kiko: I'll be raped for 10% per month until I file?
[07:07] <kiko> Kinnison, what's 10% rape between friends?
[07:07] <kiko> cprov, but really, this is only inside a single distroarchrelease.. should be okay.
[07:07] <Kinnison> kiko: Erm, by the time the next tax period comes around, on the amount I'm likely to owe, and the cumulative interest/charges for being late.. probably only 10,000 UKP
[07:08] <carlos> Kinnison, ok, I'm not sure if we have all in place to do distribution imports for translations as I don't see any translation file imported into our queue at staging or dogfood and I don't know how to test it
[07:08] <kiko> Kinnison, you can't even have dinner for two in london for that!
[07:08] <Kinnison> kiko: but it goes a long way to helping me move house
[07:08] <cprov> kiko: start to pray now ;)
[07:08] <kiko> really? I thought houses cost millions in the uk
[07:09] <Kinnison> carlos: Right, well I think we have the ends of the system, and a dangly bit in the middle which needs plugging together
[07:09] <Kinnison> kiko: Sell House1, Buy house2, use <X> money to move furniture etc.
[07:09] <kiko> cprov, one package name, one distroarchrelease.. datecreated should be okay. oh, unless we imported security first, which we didn't
[07:09] <Kinnison> kiko: <X> is (I have estimated) likely to be ca. 4,000 UKP for me
[07:09] <Kinnison> carlos: I.E. We can get the tarballs in, and you can process them, we just need to glue them together
[07:10] <kiko> wtf
[07:10] <carlos> Kinnison, ok, is there anything I can do to fix that? I want to test it as soon as possible so we can have dapper's translations in place on time
[07:11] <cprov> kiko: unless a bunch of other conditions related to import ordering, I can't really realise then. Anyway, 'weak' is better than 'wrong package' or 'nothing'
[07:12] <kiko> yeah.
[07:13] <Kinnison> carlos: Right, there is an implementation in publish_ROSETTA_TRANSLATIONS
[07:13] <Kinnison> carlos: so what's left is for the buildds to generate the correct stuff for the uploads
[07:13] <Kinnison> carlos: which, afaict, is a change to the pkgstriptranslations stuff
[07:14] <Kinnison> carlos: I.E. it needs to actually add a file to the changes to be uploaded rather than doing the horrid website hack
[07:14] <carlos> Kinnison, who needs to do that?
[07:14] <carlos> Martin?
[07:14] <Kinnison> carlos: Erm, not sure. pitti perhaps
[07:14] <carlos> ok, let me ask him....
[07:19] <pitti> hey guys
[07:19] <carlos> Kinnison, pitti says he has that code already done
[07:19] <carlos> Kinnison, he just needs to know when it should be uploaded into Ubuntu's archive
[07:19] <pitti> Kinnison: right, I even accidentially uploaded it when dapper opened (since LP migration was announced for that)
[07:19] <carlos> Kinnison, kiko who should coordinate that? (ubuntu movement to launchpad)
[07:20] <pitti> Kinnison: so whenever somebody pokes me, I can upload it
[07:20] <carlos> kiko, I would also ask for some testing for that, not sure if we have a server where we could do that testing before moving into production
[07:22] <Kinnison> pitti: right
[07:22] <Kinnison> carlos: I imagine we can't do it until we migrate
[07:22] <kiko> carlos, we need to wait till feb. at least
[07:22] <Kinnison> carlos: which is scheduled for the end of january IIRC, we have a sprint for it in London
[07:29] <carlos> it's not a very good thing but I understand it, I will try to do all tests at that point then...
[07:29] <Kinnison> cool, thanks carlos
[07:30] <carlos> Kinnison, kiko, pitti thanks for your input
[07:31] <pitti> you're welcome :)
[07:31] <kiko> sorry for not having better news.
[07:57] <bradb> jamesh: ping
[08:05] <dilys> Merge to devel/launchpad: r=SteveA Fix for bug 6431: View Builds causes Oops if empty. Allow batch navigation to accept a list of None (and not just an empty iterable), and adds a test for it (r2982: kiko)
[08:24] <kiko> matsubara, are you interested in bug 6593?
[08:24] <matsubara> kiko: assign it to me
[08:27] <kiko> done
[08:29] <bradb> ddaa: Is it normal for an sftp push to sit at "[[08:30] <Kinnison> bradb: s'probably pushing the inventory
[08:30] <Kinnison> bradb: which is large
[08:31] <bradb> Hm, I wish I were able to tell what was happening. I already Ctrl-C'd it once, and restarting it caused it to start from 0.
[08:47] <OgMaciel> hi... is there a bug with LP when displaying the amount of translations needed for a certain language?
[08:50] <kiko> OgMaciel, a few :) which is the bug you're referring to?
[08:50] <OgMaciel> kiko, hi...  when you see the list of all languages for Dapper for instance
[08:50] <OgMaciel> kiko, I don't think it is displaying the correct figures
[08:51] <kiko> URL?
[08:51] <OgMaciel> kiko, here's one for individual pkgs:  https://launchpad.net/distros/ubuntu/dapper/+lang/pt_BR
[08:52] <OgMaciel> kiko, all languages together
[08:52] <OgMaciel> kiko, https://launchpad.net/distros/ubuntu/dapper/+translations
[08:53] <OgMaciel> kiko, it is a pain having to browse back and fourth between the list and the individual pkgs
[08:53] <OgMaciel> kiko, only to find out that there's nothing left to do
[08:53] <OgMaciel> kiko, don't get me wrong, that is a good sign after all  ;)
[08:54] <ddaa> bradb: yes, end of pull / push takes looooooong with launchpad
[08:54] <dilys> Merge to devel/launchpad: [trivial]  Add a trivial test for a few pages on a distro with no builds, specs or bugs (r2983: kiko)
[08:54] <kiko> OgMaciel, are you referring to the lack of Todo in the first page?
[08:54] <ddaa> though I'd probably not call it "seemingly forever" compared to the geological ages of the rest
[08:54] <bradb> English needs a new word to describe this situation.
[08:55] <ddaa> apparences are misleading
[08:55] <bradb> I've been waiting for a good 30-40 mins so far
[08:55] <OgMaciel> kiko, refering to when you place the mouse over the progress bar (or even the progress bar itself)... the figures don't match the real situation
[08:55] <kiko> OgMaciel, IIRC the statistics are cached and I think the script is disabled for now -- right daf, carlos?
[08:56] <ddaa> there was a lot of progress since baz, there actually community devels submitting performance improvement, with baz you needed a degree in tomlord voodoo.
[08:56] <OgMaciel> kiko, while we await for confirmation on this, is there a reason for turning it off?
[08:56] <ddaa> bradb: 30-40 mins seems very long indeed...
[08:57] <matsubara> ddaa: btw, could you give me some feedback on bug 5573 ?
[08:57] <kiko> OgMaciel, performance, AIUI
[08:57] <ddaa> It would have been faster for you to get bzr and bzrtools source distribs and use rsync...
[08:57] <ddaa> Ubugtu: wake up!
[08:57] <OgMaciel> kiko, hummmm
[08:57] <matsubara> hmm Ubugtu wake up! bug 5573
[08:57] <Ubugtu> Malone bug 5573: "Cannot use sftp URLs for branches" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Diogo Matsubara, Status: Confirmed http://launchpad.net/bugs/5573
[08:58] <OgMaciel> kiko, some of the translators are annoyed about it... and so am I...  hehehe
[08:58] <matsubara> ddaa: which schemes should be allowed on the branch URL field?
[08:58] <ddaa> well...
[08:58] <ddaa> http and sftp should be enough
[08:58] <matsubara> http, https, ftp, sftp, anything else?
[08:59] <ddaa> https, probably
[08:59] <ddaa> ftp... yes, I guess
[08:59] <ddaa> nothing else I can think of
[09:00] <ddaa> matsubara: the immediate requirement is just being able to register chinstrap branches
[09:00] <ddaa> added points for various decorations like username and port
[09:00] <ddaa> more added point for call the user bird names if giving a url with a password
[09:01] <kiko> such as eagle?
[09:01] <ddaa> mega bonus: bzr:// scheme, you'd need to design the smart server to know what you need to support first ;)
[09:02] <kiko> lo
[09:02] <kiko> l
[09:04] <ddaa> another bonus level: getting the sftp url commitee to get back in touch with reality and give us a sensical format for home-relative url. Alternatively ask lifeless and do what he tell, the sftp url committee guys are one crack anyway.
[09:06] <ddaa> matsubara: sorry for not being very much to the point, but I had a long day, and it's been over for two hours now, so I'm unwinding :)
[09:08] <matsubara> ddaa: np, I find your french sense of humor amusing. :)
[09:08] <kiko> or amazing, depending on things
[09:10] <bradb> Damn, bzr, FINISH.
[09:11] <ddaa> I think my sense of humor is not very typically french.
[09:21] <matsubara> kiko: make check finished, now I have the complete error message.
[09:26] <kiko> aha.
[09:26] <kiko> let me finish this test I'm writing
[09:27] <lifeless> bradb: pong
[09:29] <lucasd> is there anyway to get the source code of Launchpad?
[09:29] <bradb> lifeless: Hi. I'm using sftp push, because bzrtools has a missing dep breakage, which I found out after upgrading bzr this morning. bzrtools failed to build from source for me.
[09:30] <kiko> lucasd, not currently -- there's a plan to open source it, but it's not in the short term.
[09:30] <bradb> lifeless: Is it normal for sftp push to sit at: [[09:30] <lifeless> bradb: yes
[09:30] <lucasd> kiko, oh, I see...
[09:30] <lifeless> bradb: this is why we dont use it for launchpad
[09:30] <bradb> ok
[09:31] <lifeless> bradb: its a 400 mb download to check IIRC, so divide 400MB by your link bw and multiply 4K * your RTT
[09:31] <bradb> jblack said he'd pass on the message to the pkg maintainers about the bzrtools breakage.
[09:32] <lifeless> hmm, theres no email on it
[09:32] <lifeless> so - 
[09:32] <lifeless> whats your bzr version?
[09:32] <lucasd> kiko, are you involved in development?
[09:32] <kiko> lucasd, indeed I am. how may I help you?
[09:32] <lifeless> and have you considered using the packages bzrtools ?
[09:32] <bradb> lifeless: bzr (bazaar-ng) 0.7rc1
[09:32] <lifeless> lucasd: we let him code from time to time ;)
[09:32] <lucasd> hahah
[09:33] <bradb> lifeless: I tried building bzrtools from the source package and it raised a Python exception running test.py.
[09:33] <lucasd> does launchpad run with apache's module mod_python ?
[09:34] <lifeless> bradb: ok, I'm trying bzrtools' test with bzr
[09:34] <lucasd> lifeless, do you know that?
[09:34] <lifeless> lucasd: we dont run launchpad under apache no
[09:34] <bradb> lifeless: bzr package version: 0.7+200601110300
[09:35] <lifeless> lucasd: its a zope3 service
[09:35] <lucasd> ahhn..
[09:35] <lucasd> I see..
[09:35] <lifeless> lucasd: so it has its own webserver builtin
[09:37] <lifeless> boom!
[09:37] <lifeless> boom!
[09:37] <lifeless> boom!
[09:37] <lifeless> bradb: tests pass
[09:38] <kiko> why does sqlobject hate me?
[09:38] <kiko> I have done nothing against it
[09:38] <lifeless> its not personal
[09:38] <kiko> not today anyway
[09:38] <bradb> lifeless: Did you update to the latest bzr package?
[09:38] <lifeless> its like onions
[09:38] <bradb> lifeless: When I upgraded, it removed bzrtools, and I can't get it back.
[09:38] <kiko> layers of stuff that makes you cry?
[09:38] <lifeless> kiko: exactly
[09:39] <lifeless> bradb: I have no packages installed - I develop so many branches it would kill me ..
[09:39] <lifeless> bradb: do you have a traceback for the bzrtools ?
[09:39] <bradb> Yes, coming up.
[09:39] <lifeless> (and I'm not clear about bzrtools - jbailey packages it - so why do you need to build it?)
[09:40] <kiko> lifeless, I think bradb's having a broken package problem
[09:40] <lifeless> kiko: yeah, I'm trying to understand though
[09:40] <lifeless> as we dont /have/ a test.py in bzrtools, nor in bzrlib...
[09:41] <bradb> lifeless: https://chinstrap.warthogs.hbd.com/~dsilvers/paste/fileqORkv8.html
[09:42] <lucasd> lifeless, ok.. thanks
[09:42] <bradb> hey, cool, my push finally finished
[09:42] <lucasd> I came because I was having a really hard time tring to use apache's mod_python
[09:44] <lifeless> bradb: cat you cat test.py for me ?
[09:46] <bradb> lifeless: https://chinstrap.warthogs.hbd.com/~dsilvers/paste/fileK7GOOQ.html
[09:50] <MojoDumb> hello
[09:51] <MojoDumb> I've got a problem with uploaded .po files... rosetta dosen't updates fresh translates.
[09:51] <MojoDumb> I can't understand where the problem is :(
[09:51] <kiko> MojoDumb, it takes a while to update -- also, it may be that one of the files failed to import cleanly.
[09:52] <lifeless> bradb: hmm, that looks like an adhoc runner
[09:52] <MojoDumb> kiko, I' checked .po files are not corrupted.. and yesterdays update dosen't work at all :(
[09:52] <lifeless> bradb: it should work, unless bzrtools fails to import
[09:53] <bradb> My guess is that it fails to import.
[09:53] <kiko> MojoDumb, best people to look this up for you are jordi and carlos -- the upload needs to be approved, also.
[09:53] <lifeless> bradb: which, as its using the wrong python namespace will happen
[09:53] <lifeless> bzrtools is bzrlib.plugins.bzrtools
[09:53] <lifeless> not 'bzrtools'
[09:53] <lifeless> that may not be the cause of the problem but its definately wrong
[09:54] <lifeless> there is you see the bzrtools module
[09:54] <MojoDumb> I've done User upload and Published upload too
[09:54] <lifeless> and the bzrtools package
[09:54] <MojoDumb> but nothing works....
[09:54] <lifeless> which contains the bzrtools module
[09:54] <MojoDumb> :/
[09:54] <MojoDumb> output message is Your upload worked. The translation content will appear in Rosetta in a few minutes.
[09:54] <kiko> MojoDumb, what package and language are you uploading?
[09:54] <MojoDumb> Georgian
[09:54] <MojoDumb> BUM (Boot Up Manager) ka.po file
[09:55] <MojoDumb> https://launchpad.net/distros/ubuntu/dapper/+source/bum/+pots/bum/ka/+translate   this one
[09:55] <kiko> what's your launchpad account?
[09:55] <bradb> lifeless: What do I need to do to fix this?
[09:55] <MojoDumb> I#have alredy 100% translated file... but NO updates :(
[09:55] <MojoDumb> Alinux
[09:56] <MojoDumb> https://launchpad.net/people/alinux/ -- tha's me :(
[09:56] <MojoDumb> :)
[09:56] <kiko> Vladimer!
[09:56] <kiko> nice photo
[09:56] <MojoDumb> kiko, yes sir :)
[09:56] <MojoDumb> thank you :)
[09:56] <kiko> all right, I'll forward this to jordi/carlos, they'll get back to you.
[09:57] <MojoDumb> thank you kiko :) a LOT!
[09:57] <kiko> you're most welcome
[09:57] <MojoDumb> 2005 verything worked well
[09:57] <lifeless> bradb: uhm, try changing the import bzrtools to:
[09:57] <lifeless> import bzrlib
[09:57] <MojoDumb> but this period there is some problems I guess...
[09:57] <lifeless> import bzrlib.plugin
[09:57] <kiko> we've changed the way the uploads work
[09:57] <lifeless> bzrlib.plugin.load_plugins()
[09:57] <kiko> it's an improvement, but there may be some glitches
[09:57] <MojoDumb> ah
[09:58] <MojoDumb> kiko, I see...
[09:58] <lifeless> import bzrlib.plugins.bzrtools
[09:58] <lifeless> suite = bzrlib.plugins.bzrtools.test_suite()
[09:58] <MojoDumb> no one of my team can update a file...
[09:58] <MojoDumb> and on line translating is too slow
[09:58] <OgMaciel> kiko, sorry to bother... who should I talk to about the script that updates the translation status in LP?
[09:59] <MojoDumb> kiko, can you understan me?
[09:59] <kiko> MojoDumb, yeah. you'll have an answer shortly 
[09:59] <kiko> OgMaciel, probably carlos or jordi or stub 
[09:59] <MojoDumb> kiko, thank you for preoccupation :)
[09:59] <MojoDumb> and sorry for disturbing.
[10:00] <OgMaciel> kiko, thanks...  what about the karma that keeps dropping?  do you know about this?
[10:00] <MojoDumb> ok, kiko I'll wait for your answer...
[10:00] <MojoDumb> ...ciao..
[10:00] <kiko> OgMaciel, yes, that's by design -- you need to work to keep it up
[10:00] <bradb> lifeless: trying...
[10:00] <kiko> OgMaciel, perhaps the depreciation is happening at a too-fast pace
[10:01] <OgMaciel> kiko, yeah... WAY to fast
[10:01] <kiko> we need to talk to salgado on monday about that
[10:01] <kiko> he's on holidays
[10:01] <sivang> kiko: this happened for me as well :)
[10:01] <bradb> lifeless: 
[10:01] <bradb> Traceback (most recent call last):
[10:01] <bradb>   File "./test.py", line 21, in ?
[10:01] <bradb>     import bzrlib.plugins.bzrtools
[10:01] <bradb> ImportError: No module named bzrtools
[10:02] <OgMaciel> kiko, next Monday with Carlos?
[10:02] <lifeless> bradb: then thats being run in an inconsistent state - neither installed as a plugin, nor in the plugin path
[10:02] <lifeless> bradb: lets grab jbailer
[10:02] <OgMaciel> kiko, I mean, Sa;gado
[10:02] <OgMaciel> kiko, I mean, Salgado
[10:03] <bradb> lifeless: Might be hard to get ahold of him. I tried earlier, but I gather he's busy in London.
[10:03] <lifeless> oh right
[10:03] <lifeless> that would do it.
[10:04] <kiko> OgMaciel, yeah, he'll be back then
[10:04] <bradb> lifeless: Anything else I can do to help get this fixed before I head off?
[10:05] <OgMaciel> kiko, thanks a lot again... ;)
[10:07] <lifeless> bradb: nope
[10:07] <lifeless> thanks
[10:10] <bradb> lifeless: ok, no prob, thanks for the debugging help
[10:32] <OgMaciel> carlos, excuse me... got a minute?
[10:34] <kiko> I think carlos isn't around
[10:34] <OgMaciel> kiko, cool... will try again later  ;)
[10:43] <carlos> OgMaciel, hi
[10:43] <OgMaciel> carlos, hi... can I have a word with you?
[10:43] <OgMaciel> carlos, I want to know about the script that updates the stats for the translations
[10:43] <carlos> OgMaciel, the poimport is disabled due a bug we have. it should be fixed tomorrow
[10:43] <OgMaciel> carlos, ahhhh
[10:44] <carlos> OgMaciel, what happens with the stats?
[10:44] <OgMaciel> carlos, is that a bug # for me to subscribe to?
[10:44] <OgMaciel> carlos, not up to date at all the times
[10:44] <carlos> OgMaciel, the bug is fixed, it's waiting to be applied into production
[10:45] <OgMaciel> carlos, is that a bug # for me to subscribe to?
[10:45] <carlos> OgMaciel, no
[10:46] <carlos> OgMaciel, we detected it and fixed it without opening a bug
[10:46] <OgMaciel> carlos, ok... fair enough
[10:46] <OgMaciel> carlos, so by tomorrow? and with what frequency does it get applied?
[10:46] <carlos> OgMaciel, about the stats, which part of the stats are you talking about?
[10:47] <carlos> OgMaciel, once per week, but sometimes, we do some urgent updates like this one
[10:47] <OgMaciel> carlos, about the stats for the whole translation team... the ones left to do
[10:47] <carlos> OgMaciel, URL?
[10:47] <OgMaciel> carlos, and at one time, the individual stats for pkgs were not up to date
[10:48] <OgMaciel> carlos, that's the darnest thing... it seems to be up to date now...  ;)
[10:48] <carlos> OgMaciel, https://launchpad.net/distros/ubuntu/breezy/+lang/af ?
[10:48] <carlos> those kind of urls?
[10:48] <OgMaciel> yup
[10:49] <carlos> those are updated from time to time
[10:49] <carlos> it's not real time
[10:49] <OgMaciel> there u go
[10:49] <OgMaciel> why not?
[10:49] <carlos> I don't know exactly how often does it happens
[10:49] <carlos> performance issues
[10:49] <OgMaciel> ohhh
[10:49] <OgMaciel> hummm
[10:50] <OgMaciel> is this a separate bug or the same?
[10:50] <carlos> no bug at all
[10:50] <carlos> it's just too expensive
[10:50] <carlos> so we use cached values
[10:50] <OgMaciel> carlos, any chance of prioritizing the frequency?
[10:52] <carlos> OgMaciel, stub is our DBA so I suppose it's something to talk with him as he knows better the database server load
[10:52] <OgMaciel> carlos, thanks... will do that
[10:52] <carlos> OgMaciel, you are welcome
[10:52] <OgMaciel> carlos, would you happen to know which DB is being used?
[10:52] <carlos> OgMaciel, we only have one DB
[10:53] <carlos> the launchpad DB ;-)
[10:53] <OgMaciel> hehehe
[10:53] <carlos> and the stats code is common with all launchpad
[10:53] <OgMaciel> I meant Oracle, MySQL, etc
[10:53] <carlos> so it's not specific for Rosetta
[10:53] <kiko> so
[10:53] <carlos> OgMaciel, Postgresql
[10:53] <OgMaciel> carlos, cool...  thanks again!  ;)
[10:54] <carlos> np
[10:54] <kiko> carlos, can you make the fields on an auto-form change according to permissions?
[10:55] <carlos> show and hide them?
[10:55] <carlos> kiko, yes, I did it once
[10:55] <kiko> can you explain how it works?
[10:55] <kiko> or do you have an example somewhere?
[10:55] <carlos> hmmm
[10:56] <carlos> no, the code is not there anymore
[10:56] <kiko> okay, so explain. :)
[10:56] <carlos> but let me look for the bjorn's email
[10:56] <kiko> la la la la la
[10:56] <jblack> kiko: ping
[10:56] <kiko> hey jblack 
[10:57] <jblack> Hey buddy.
[10:57] <jblack> So, emails bugging you? 
[10:57] <kiko> hey dude
[10:58] <AlinuxOS> he he :)
[10:58] <AlinuxOS> registered nick is better then non registered :)
[10:58] <jblack> Kiko: These emails are intended behaviour. Until we've got rpc-xml tracking ddaa wants a way to know what branches are failing because of things like 404s, broken branches, etc.
[10:58] <AlinuxOS> kiko :)
[10:59] <jblack> kiko: You there? 
[11:00] <dilys> Merge to devel/launchpad: [trivial]  Fix for bug 3516: Broken traversal on Binary package page. Fixes a silly bug in DistroArchReleaseBinaryPackage.__getitem__, adds a test for it, and as an added bonus, fixes a problem that would happen with currentrelease and real-world versions, with test (getting rid of the use of sourcerer's Version class) (r2984: kiko)
[11:00] <AlinuxOS> guys I what is the differencee between "User upload" and "ublished upload"
[11:00] <carlos> kiko, do you see the private messages?
[11:00] <AlinuxOS> and sorry fro my bad english :)
[11:01] <AlinuxOS> hello carlos :)
[11:01] <carlos> AlinuxOS, yes, "published upload" means that the uploaded .po file is already merged into upstream tree
[11:01] <carlos> AlinuxOS, "User upload" is just a way to do offline translations
[11:02] <AlinuxOS> ah
[11:02] <AlinuxOS> I've tryed both
[11:02] <AlinuxOS> but "User upload" doesn't work.
[11:02] <AlinuxOS> for me.
[11:02] <carlos> AlinuxOS, why? 
[11:02] <carlos> how do you know that?
[11:03] <kiko> carlos, yeah
[11:03] <AlinuxOS> "Your upload worked. The translation content will appear in Rosetta in a few minutes."
[11:03] <carlos> AlinuxOS, there is a problem with the imports
[11:03] <carlos> and it's disabled
[11:03] <AlinuxOS> here is a message of sucssessfull upload, ut nothing happens.
[11:03] <carlos> I hope tomorrow they will be enabled again
[11:03] <AlinuxOS> carlos, woow
[11:04] <AlinuxOS> great news!
[11:04] <carlos> AlinuxOS, it's in a queue waiting for being imported
[11:04] <carlos> so it's not lost
[11:04] <carlos> but just not being imported
[11:04] <AlinuxOS> carlos, so I'll wait for tommorow evening.
[11:04] <carlos> AlinuxOS, ok
[11:04] <AlinuxOS> I'll retry an improt.
[11:05] <carlos> no, you don't need to do that
[11:05] <AlinuxOS> ah... so I check it tommorow :)
[11:05] <carlos> AlinuxOS, what's your launchpad login?
[11:06] <AlinuxOS> Alinux
[11:06] <AlinuxOS> https://launchpad.net/people/alinux
[11:06] <AlinuxOS> here I am :)
[11:07] <jblack> kiko: ping. ;)
[11:07] <carlos> ok, just checking something
[11:07] <carlos> AlinuxOS, you should get a confirmation email tomorrow
[11:07] <carlos> when the upload is done
[11:08] <kiko> jblack, oh. well, just make the script output something reasonable instead of a plain exception?
[11:08] <kiko> Another instance of foo is running, exiting..
[11:08] <jblack> kiko: Sure, I can do that. 
[11:08] <kiko> that'd be nicer
[11:08] <kiko> also
[11:08] <kiko> if indeed it's a case of multiple runs
[11:08] <kiko> shouldn't they be further spaced out?
[11:09] <AlinuxOS> carlos, thank you a lot! :=)
[11:09] <jblack> kiko: I don't think so for two reasons.
[11:09] <jblack> The first reason is that launch frequency determines mirror frequency. 
[11:10] <carlos> AlinuxOS, if you don't get any email tomorrow, please ping me back.
[11:10] <jblack> The second reason is that most of the time, there isn't a block there. That just happens if there's a new branch that takes unusually long to run. We got a lot of them over the last day because the supermirror was populating everything.
[11:11] <carlos> night
[11:11] <kiko> jblack, maybe the script shouldn't say anything in that case, then?
[11:12] <jblack> We can do that too.
[11:12] <kiko> spam every 10 minutes on that list is bad
[11:13] <jblack> if there's a single branch that fails, we'll spam the list every ten minutes regardless.
[11:13] <lifeless> kiko: its a temporary workaround until the lp integrated feedback is in place
[11:13] <lifeless> kiko: unsubscribe from that filter
[11:14] <jblack> Thats probably a good idea. 
[11:14] <sivang> hmm, I dist-upgrades with jbailey's sources and can't install bzrtools now..
[11:15] <kiko> I don't use filters
[11:15] <jblack> kiko: You're aware of the filter page on lists.canonical.com?
[11:15] <kiko> yes.
[11:15] <jblack> Its a case of hitting a checkbox and you won't get any more sm mails?
[11:16] <kiko> I don't use them -- part of my job (until I delegate it) is to keep an eye on crap that happens there.
[11:16] <jblack> ddaa and I both get every single one of those, so you can feel comfortable that they're not getting thrown away.
[11:16] <sivang> jblack: are you using bzrtools on a latest dist-upgraded dapper?
[11:17] <jblack> sivang: No sir.
[11:17] <jblack> sivang: I'm guessing you're having dependancy problems with bzrtools? 
[11:17] <sivang> jblack: exactly :)
[11:18] <sivang> jblack: it has a specific dependency (= 0.7+200512311044)
[11:18] <kiko> see scrollback
[11:18] <jblack> Yes. I've mentioned it to the bzrtools maintainer, and I'll make sure that Jbailey knows as well.
[11:18] <sivang> kiko: the bradb issue from before?
[11:21] <kiko> yeah
[11:22] <sivang> or I could just rebuild from source and change this bit on the control file....argh
[11:40] <mpt> oh dear
[11:40] <mpt> I look for bugs about fixed-width fonts in Launchpad, so I search for "fixed", and get 143 results ...
[11:41] <kiko-zzz> that's odd
[11:41] <kiko-zzz> but pester stub, he'll have some information for you, perhaps
[11:41] <mpt> the bug status is being included in the search text