[01:03] <mpt_> Gooooooooooooooood morning Launchpadders!
[01:03] <mpt_> It's a lovely morning, but there's nowhere to park the car
[02:45] <mpt> Ok, now there's a hailstorm
[04:57] <mpt> ugh
[06:32] <abentley-gaim> I've uploaded my SSH (DSA) public key to launchpad, but I still can't sftp to bazaar.launchpad.net.  I get "Permission denied (publickey)"
[06:33] <spiv> abentley-gaim: using your launchpad username?
[06:34] <abentley-gaim> Ah, maybe not.
[06:34] <spiv> abentley-gaim: there's no delay between uploading your key and the sftp server using that key.
[06:34] <jamesh> abentley-gaim: you can configure your ~/.ssh/config file to automatically use your LP user name
[06:35] <jamesh> abentley-gaim: add a stanza like "Host bazaar.launchpad.net\nUser aaron-bentley"
[06:35] <spiv> abentley-gaim: I suppose I *could* make the sftp server try every single key in launchpad ;)
[06:35] <abentley-gaim> Okay, great.  I'd almost forgotten ssh used usernames, because they're always the same.
[06:35] <jamesh> spiv: but what if two people are using the same key? :)] 
[06:36] <spiv> jamesh: give the user access to both home directories, obviously ;)
[06:36] <jamesh> you could try changing your LP username to match your local user name (assuming it hasn't been taken)
[06:37] <jamesh> spiv: I suppose we could do the same for logging into the website
[06:37] <jamesh> so people don't need to remember their email address
[06:37] <abentley-gaim> jamesh: thanks for the config file tip.
[06:37] <jamesh> abentley-gaim: I also use the config file to pick different ssh keys for different sets of hosts (quite useful)
[06:39] <abentley-gaim> I think my all-time favourite was how auffield used it to force a particular umask for Arch uploads.
[06:42] <abentley-gaim> Thanks, guys.  I'm out.
[07:42] <stub> spiv: Before the disabled flag on Person lands, we also need to update the ValidPersonOrTeamCache materialized view to know about the new field. Punt a branch over to me and I'll handle it (unless you feel like playing with PostgreSQL triggers)
[07:43] <spiv> stub: Ah, right.  I'll finish up my work on that branch tonight and then punt it to you.
[07:44] <spiv> stub: Hmm.
[07:44] <spiv> stub: Should the authserver be using that cache to check that user is valid, rather than replicating the checks itself?
[08:08] <stub> spiv: I think that would be best - centralize the logic in one place. There is a Person.is_valid method that does it this way, or just join on the table.
[08:44] <SteveA> good morning
[08:49] <SteveA> mpt: ping
[08:49] <mpt> SteveA, pong
[11:32] <carlos> stub: hi, do you know if there is any problem with staging?
[11:33] <stub> carlos: I think it is down - mandatory config items changes landed without changes being made to staging/launchpad.conf
[11:33] <carlos> stub: the database is also broken
[11:33] <carlos> launchpad_staging=> SELECT * from distribution;
[11:33] <carlos> ERROR:  permission denied for relation distribution
[11:34] <stub> Yer. If the code rollout fails it is stuffed, as we need to run code to complete the restoration.
[11:34] <stub> I assume this is a round about way of asking me to fix it? :)
[11:36] <carlos> stub: pretty please....
[11:36] <carlos> :-P
[11:41] <Yannig> Hello everybody :)
[11:42] <LarstiQ> hallo Yannig 
[12:13] <stub> carlos: Hmm... failing on the rosetta db patch. Would that be because the data migration script needs to be run first?
[12:14] <stub> failed attempting to make POSubmission(potranslation, pomsgset, pluralform) UNIQUE
[12:16] <Keybuk> the bigger the "Build Score", is it more or less likely to get built?
[12:17] <Keybuk> so...
[12:17] <Keybuk> the higher the "build score", is it more or less likely to be built?
[12:18] <Kinnison> erm, more
[12:18] <Kinnison> IIRC
[12:26] <stub> carlos: Up except for that patch, which will likely break some stuff. Let me know re: data migration.
[12:26] <Keybuk> yes, that worked
[12:26] <Keybuk> Kinnison: thanks
[12:27] <Kinnison> Keybuk: y'welcome
[12:27] <Keybuk> we now have tzdata for edgy
[12:27] <Kinnison> yay
[12:27] <Kinnison> Anyone would think you actually wanted a working distribution
[12:27] <Kinnison> You slacker
[12:27] <sladen> how do I get the audit trail on a support-request to see what it was previously:  https://launchpad.net/products/launchpad/+ticket/1085 
[12:27] <Keybuk> we still need to sync the locales from Debian for the glibc ABI change
[12:27] <Keybuk> meh
[03:23] <SteveA> carlos: ping
[03:36] <MrE-n-sweet> hello
[03:38] <MrE-n-sweet> hmmm guess not
[03:41] <SteveA> MrElf1961: lots of people are awake.   many are at the ubuntu summit in paris.
[03:42] <MrElf1961> ah, ok, SteveA. thanks
[04:26] <SteveA> matsubara: 
[04:26] <matsubara> SteveA: I'll call him
[04:29] <matsubara> SteveA: he's calling
[04:55] <lifeless> SteveA: ping
[04:55] <SteveA> lifeless: 
[05:29] <claude> matsubara: thanks for your mail about #1020
[05:30] <claude> but i'm still stuck :(
[05:30] <claude> i cannot see my old key
[05:30] <claude> and when I try to import it again, i see:
[05:31] <claude> OpenPGP key F24EB7813A533EC055E191D89566ACA516946297 already imported
[05:31] <matsubara> Hi claude 
[05:32] <claude> would you be able to delete it from launchpad?
[05:32] <claude> so I may be able to reimport it again?
[05:33] <matsubara> claude: I can't delete it myself, but I can ask an admin to do it.
[05:33] <Kinnison> That key is registered to the launchpad user 'paroz'
[05:34] <claude> yes, but in the meantime, it has expired
[05:34] <claude> i i extended the validity on the key server
[05:34] <Kinnison> So you want to reactivate it
[05:34] <Kinnison> I see
[05:34] <matsubara> claude: do you still see the message  'The key 16946297 cannot be validated because it has expired.' when you try to revalidate it?
[05:34] <Kinnison> That's an interesting situation
[05:35] <Kinnison> matsubara: who was it who wrote the UI for the gpgkey stuff?
[05:35] <Kinnison> matsubara: I think it may have been cprov 
[05:35] <claude> matsubara: no, because i even don't get to activation screen
[05:36] <claude> the key don't appear on the "Details" screen
[05:36] <matsubara> Kinnison: I'm not sure. I thought it was jamesh
[05:36] <Kinnison> matsubara: Hmm, might have been
[05:36] <Kinnison> claude: Right, I am looking now
[05:36] <claude> good :-)
[05:38] <Kinnison> Okay, so this is a UI workflow bug
[05:38] <Kinnison> It should be possible to reactivate a deactivated key
[05:38] <Kinnison> I don't seem to have access to do that for you
[05:38] <Kinnison> Can you please email launchpad-users with the details of the key and ask for it to be reactivated?
[05:39] <claude> ok, i'll do it
[05:40] <matsubara> Kinnison: there's already a open support request on the issue.
[05:40] <Kinnison> matsubara: link it to bug 50578 then
[05:40] <Ubugtu> Malone bug 50578 in launchpad "Unable to reactivate a gpg key" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/50578
[05:44] <matsubara> Kinnison: the workflow you described it's already possible with the current code.
[05:45] <Kinnison> matsubara: right, so it just needs the UI changing to allow it
[05:47] <matsubara> Kinnison: I mean, it's already possible in the UI. At least using sample data I was able to deactivate foo.bar key and revalidate it and receive a token email
[05:47] <Kinnison> matsubara: odd, then what is stopping claude doing the same?
[05:47] <claude> maybe it was because mine had expired
[05:48] <matsubara> I thought it could be related  to bug 3052
[05:48] <Ubugtu> Malone bug 3052 in launchpad "GPG upload of newly-changed key fails because we cache the old key" [Medium,Confirmed]  http://launchpad.net/bugs/3052
[05:48] <matsubara> but you can see what we already tried here: https://launchpad.net/products/launchpad/+ticket/1020
[05:48] <matsubara> Kinnison: ^^
[05:48] <cprov> matsubara: key caching was kind of sorted entirely by new jamesh gpg backend
[05:51] <matsubara> cprov: Why is #3052 still open? When the james' gpg backend landed?
[05:52] <matsubara> claude: so, when you visit the launchpad.net/people/paroz/+editpgpkeys there's no option to revalidate key16946297?  
[06:06] <cprov> matsubara: because we suck, basically. Could you request info on that, from requester and from james ?
[06:53] <bradb> stub: ping?
[06:53] <stub> bradb: pong
[07:26] <carlos> stub: the answer to your question about the migration script, yes, we need to execute data migration before the db patch can be executed
[07:26] <carlos> stub: the db patch adds a unique restriction
[07:26] <carlos> hmm
[07:26] <carlos> I see that you already fixed it :-P
[07:26] <carlos> stub: thanks
[07:27] <stub> carlos: Ta. Just wanted to confirm. I'll run it on production tomorrow morning, which should keep staging happy
[07:27] <stub> (staging is currently running without that db patch applied)
[07:27] <carlos> stub: unless someone does some translations with suggestion approvals....
[07:27] <carlos> which will produce duplicate entries again
[07:28] <carlos> the branch includes code changes to prevent those code duplicates
[07:28] <carlos> s/code/rows/ 
[07:28] <carlos> s/code duplicates/rows duplicates/ 
[07:29] <carlos> dinner time
[07:29] <carlos> see you later
[08:29] <kiko> matsubara, what is this lookuperrror when viewing the bug?
[08:30] <matsubara> kiko: I'm not sure yet. seems related to the importance_widget. the bug is currently assigned to brad.
[08:30] <matsubara> kiko: bug 49899
[08:30] <Ubugtu> Malone bug 49899 in malone "Lookup error on bug page" [High,In progress]  http://launchpad.net/bugs/49899
[08:34] <kiko> matsubara, brad's in paris, perhaps you could look it up?
[08:38] <matsubara> kiko: I think he's already working on it. He changed the status to in progress yesterday
[08:38] <kiko> mmm ok.
[08:39] <kiko> and the inTeam() one?
[08:41] <matsubara> kiko: bradb already fix committed it.
[08:42] <kiko> ah cool
[09:08] <jordi> kiko!
[09:08] <kiko> hello lil jordi 
[09:12] <SteveA> kiko: it's a goddamn rollback!
[09:12] <kiko> yeah
[09:13] <kiko> I'm writing up a comment
[09:15] <kiko> SteveA, were rollbacks not being logged before, then?
[09:15] <kiko> hmmm
[09:15] <SteveA> it was something stu added after he and i discussed the issue on voip
[09:15] <SteveA> we guessed that the problem was due to either
[09:15] <SteveA> 1. spurious rollbacks
[09:16] <SteveA> 2. more than one connection
[09:16] <SteveA> so, the logging code was specifically designed to find out if it was one of those possibilities, or something else
[09:16] <SteveA> i'm glad it is one of those, otherwise we'd have a serious mystery
[09:16] <kiko> thanks for the rationale
[09:17] <SteveA> making a stack trace on a ROLLBACK, and logging that, will be easy
[09:17] <SteveA> there are actually 2 rollbacks in that oops report
[09:17] <SteveA> it is strange
[09:17] <jordi> SteveA: I will need help from you guys to answer this licensing stuff
[09:17] <SteveA> jordi: have you been asked a direct question about it?
[09:18] <jordi> I think MJR did
[09:18] <jordi> I'll have to check tomoorow
[09:18] <kiko> SteveA, there are 4 rollbacks in that report.
[09:18] <jordi> I need to go run now
[09:18] <SteveA> kiko: 5
[09:18] <SteveA> two in the body, three at the end
[09:18] <kiko> who in the body where?
[09:18] <SteveA> just search in the page for ROLLBACK
[09:19] <SteveA> you'll see them
[09:19] <kiko> the first one is a dupe
[09:19] <kiko> it's in the repeated sql statements section.
[09:19] <SteveA> oh, okay
[09:19] <kiko> it even says "reps 4" :)
[09:19] <SteveA> shit
[09:19] <SteveA> there it is
[09:20] <SteveA> if there are any widgets errors, using an editform
[09:20] <SteveA> we get a transaction.abort()
[09:20] <SteveA> see lib/zope/app/form/browser/editview.py
[09:20] <kiko> who does that?
[09:20] <kiko> sheesh.
[09:20] <kiko> these people are crazy
[09:21] <kiko> so we don't do validation before starting to change the database, SteveA?
[09:21] <SteveA> i don't understand what you're saying
[09:22] <kiko> well, what's a widget error?
[09:22] <SteveA> i'm speculating that in the overriding of the edit view code
[09:22] <SteveA> or some similar code
[09:22] <SteveA> our translation form edit view makes some changes
[09:22] <SteveA> then hits a codepath in the overridden code that causes a transaction.abort() to be called
[09:23] <SteveA> there is a transaction.abort() in both lib/zope/app/form/browser/formview.py and lib/zope/app/form/browser/editview.py
[09:23] <SteveA> it is likely that one of these is to blame
[09:25] <SteveA> i think i'm wrong though
[09:25] <SteveA> the +translate page doesn't appear to use zope forms at all
[09:26] <SteveA> generalform does an abort
[09:26] <SteveA> so we must watch out for that
[09:27] <SteveA> if anything, it should be dooming the transaction rather than aborting as such
[09:29] <SteveA> so... this is a clear problem with implicitly starting a new transaction after an abort
[09:39] <kiko> okay
[09:39] <kiko> incoming email processing also calls abort()
[09:40] <kiko> and so does SQLObjectEditView
[09:45] <tortho> Hi, is there any rosetta experts here, wich know if there is possible to get the dictionary wich is used to make the suggestions for translations.... (in text/db format of some kind..)
[09:49] <kiko> tortho, AFAIK the suggestions come from submissions from other versions or instances of the translation.
[09:49] <kiko> the database is not downloadable
[09:50] <tortho> that was what i was looking for.. there is a dictionary project upcomming, and that would be a great plece to keep the translation the same... (To get all the words, and submit them for proofreading...)
[09:52] <kiko> oh!
[09:52] <kiko> that's something different
[09:53] <tortho> :-) yes, and then it would be nice to have those as a starting point... it would benefit both the translation project, and ubuntu in giving more precisely translations..
[09:54] <tortho> so, if ii understand correct, there is no way it is possible to extract those translations? (the one word ones..)
[09:55] <kiko> no, but that is a planned feature.
[09:58] <tortho> okay, thanks, I'll try again in a while :-)
[10:06] <mpt> ... Gooooooooooooooooooood morning Launchpadders!
[10:06] <mpt> It's a horribly icy morning, stay inside
[11:48] <mungewell> Hi all.  What status should I set a bug to if the behaviour is noted as 'usual' (for particular circumstances) and won't be fixed?
[11:48] <mpt> mungewell, "Rejected"
[11:48] <mungewell> Thanks.
[11:48] <mpt> Eventually we'll split that into "Not a Bug" and "Not For Us"