[02:31] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Fix for bug # 2374 and bug # 2376, GPG/CoC missapplied messages. (patch-2430: celso.providelo@canonical.com)
[04:09] <stub> lifeless: Don't suppose you have handly the patch levels of sourcerer, cscvs, etc. that I need to use for tomorrows release? Cherry picks on production 1.33 are currently failing due to test failures.
[04:09] <lifeless> stub: latest sourcerer and hct and rf
[04:09] <lifeless> or dont cherry pick after the hct landing to launchpad
[04:21] <stub> lifeless: I think issue is the patch level I need to rollout (production-1.33, devel--0--patch-2420) is from a rather volatile point in the hct landing and I'm going to hard code some patch levels to get the production release stable and tests passing. Otherwise I could roll in a few more features and rollout patch-2422 and skip the hct landing point.
[04:22] <lifeless> stub: rollout hct - 3 and sourcerer -3
[04:22] <lifeless> hct head is good for lp head, hct head - 1 is a rollback of hct head -2. 
[04:22] <stub> - 3 patch levels fromo trunk. Got it.
[04:33] <dilys> Merge to rocketfuel@canonical.com/dists--devel--0: [trivial]  Snapshot 1.32 attempting to fix cherry pick problems (patch-115: stuart.bishop@canonical.com)
[06:04] <dilys> Merge to rocketfuel@canonical.com/launchpad--production--1.32: [trivial]  Specifications patch from Steve, with added 'i' (patch-7: stuart.bishop@canonical.com)
[08:06] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Add needed <malone> section to production configs (patch-2431: stuart.bishop@canonical.com)
[09:12] <dilys> Merge to rocketfuel@canonical.com/launchpad--production--1.32: [trivial]  Add needed <malone> config sections (patch-8: stuart.bishop@canonical.com)
[09:16] <SteveA> hi
[09:41] <dilys> Merge to rocketfuel@canonical.com/dists--devel--0: [trivial]  Snapshot 1.33 attempting to fix cherry pick problems (patch-116: stuart.bishop@canonical.com)
[09:42] <SteveA> hi stub.  how's it all going?
[09:59] <stub> Good enough
[10:08] <sivang> Good Morning all
[10:08] <SteveA> lifeless: my X1 just arrived
[10:08] <SteveA> lifeless: anything i need to know before installing breezy on it?
[10:08] <lifeless> SteveA: nup
[10:08] <lifeless> oh
[10:08] <sivang> SteveA: IBM laptop?
[10:08] <lifeless> you need the 915resolution thingy
[10:08] <lifeless> sivang: better
[10:08] <SteveA> sivang: nope. dell.
[10:09] <SteveA> lifeless: okay.  is there a package, or is it a DIY?
[10:09] <SteveA> or, can i steal it from you, and stick it on a USB key
[10:09] <lifeless> SteveA: DIY, I have source around here.
[10:10] <lifeless> mailed you signed binary
[10:10] <lifeless> uhm, I put it in /etc/acpi/resume.sh and in the gdm init script
[10:10] <lifeless> erm, not resume. hmm somewhere
[10:11] <lifeless>         /usr/local/sbin/915resolution 32 1280 768
[10:11] <lifeless>         /usr/local/sbin/915resolution 43 1280 768
[10:11] <lifeless>         /usr/local/sbin/915resolution 52 1280 768
[10:11] <lifeless> damn, something has removed it from my resume script
[10:11] <lifeless> probably why hibernate resume isn't working :_)
[10:12] <lifeless> I put that after the vbetool state restore line
[10:16] <SteveA> hmm... bad signature from you
[10:16] <SteveA> because the MG2 Works virus scanner added some text to the message
[10:17] <SteveA> and removed the attachment
[10:17] <SteveA> maybe you can send it again, encrypted and signed?
[10:24] <sivang> lifeless: how come it's better? (I want to buy one and want to hear recommendations)
[10:25] <lifeless> SteveA: garh.
[10:26] <SteveA> only complaint so far is the lack of a PC card slot.  i'll need to get a CF to PC card adapter to allow my EDGE card to work
[10:28] <lifeless> SteveA: goddamn evos gpg logic is sucky
[10:30] <stub> Did you get a sane keyboard from DELL, or stuck with Lithuanian or whatever the local variant is?
[10:30] <SteveA> got a british one
[10:30] <SteveA> wanted a US one
[10:31] <SteveA> lifeless: got it, thanks
[10:34] <stub> SteveA: The country selector widget is busted - reload your order page and you find your contry listed as Afganistan
[10:35] <stub> None of the options have selected= set
[10:39] <SteveA> arse. 
[10:40] <SteveA> does it write data properly to the database?
[10:41] <stub> SteveA: Yes - country is being stored correctly
[10:42] <SteveA> okay, so not a showstopper
[10:42] <SteveA> but i can see a cherrypick request occuring tomorrow
[10:43] <stub> SteveA: It means that if people edit their order and don't explicitly set their country back to the correct value, it will nuke that information.
[10:44] <SteveA> oh.  that's not good.
[10:47] <Kinnison> sometimes postgresql can be v. slow
[10:59] <\sh> hmm...can somebody explain how I can search for fixed/rejected bugreports in malone for a specific assigned team/person?
[11:02] <carlos> goooood morning!!!
[11:02] <SteveA> hi carlos
[11:02] <SteveA> welcome back
[11:02] <carlos> thanks
[11:03] <carlos> how's going?
[11:03] <SteveA> things are looking pretty good
[11:03] <SteveA> there's some rosetta stuff that jordi was helping with over the weekend
[11:03] <SteveA> an issue about the wrong version of a pot file being in rosetta
[11:04] <SteveA> and possibly some permissions problems with who can change stuff / upload pot files
[11:04] <carlos> ok
[11:05] <carlos> I hope I will have all changes done so Jordi has all rights in place.
[11:05] <carlos> now that language packs seems to have only minor problems, that should be doable
[11:09] <dilys> Merge to rocketfuel@canonical.com/launchpad--production--1.33: [trivial]  Add needed <malone> config sections (patch-3: stuart.bishop@canonical.com)
[11:14] <Kinnison> stub: how often does gina commit() ?
[11:17] <Kinnison> aah, -c
[11:17] <Kinnison> never mind
[11:19] <sivang> SteveA: I asked Kinnison the other day about a good Zope book, as someone interested in how something like Launchpad is developed. He said you might have some recommendations, being the Zope guru ;-) 
[11:19] <bob2> sivang: I'd recommend "web component development with zope3" because not only does it develop a recipe database, but it includes poetry from SteveA 
[11:21] <sivang> bob2: what's a recipe database ?
[11:21] <bob2> sivang: a database of recipes...
[11:21] <bob2> cooking?
[11:21] <sivang> bob2: Python Poetry ? :-)
[11:22] <bob2> of course
[11:30] <jamesh> stub: ping?
[11:30] <stub> jamesh: pong
[11:31] <jamesh> stub: in the database adapter changes I'm doing to help time out long running requests, I want to make sure a transaction doesn't get committed
[11:32] <SteveA> lifeless: oddly, it won't boot an install CD from the dell external CD drive.  Using a different external CD drive in the USB port on the other side of the machine works.
[11:32] <jamesh> stub: there are two ways I can see to do that: wrap the commit/rollback methods on the connection object to prevent the commit after a timeout, or tell postgres error out the transaction when the timeout is detected (without actually aborting the transaction at that stage)
[11:33] <jamesh> stub: which method do you think would be better?
[11:35] <stub> What problem are you trying to solve? Someone catching the exception (deliberately or accidently) and keeping going? Any other database exception screws up the connection, so I would just screw it up too.
[11:36] <lifeless> SteveA: weird, worked for me
[11:36] <SteveA> also, the install CD just broke
[11:37] <stub> So a quick fix would be to simply abort the transaction or issue a dud command, or just not worrying about this case
[11:37] <lifeless> I'll say
[11:37] <jamesh> stub: okay.  is there an actual command to error out the connection, or do a dud command?
[11:37] <jamesh> aborting the transaction would not stop future queries from being accepted, which is a problem
[11:38] <stub> I don't think there is a 'break this transaction' command ;)
[11:38] <stub> 'break this transaction' is probably a good bet ;)
[11:39] <SteveA> this concept was "dooming a transaction" when discussed with zope before
[11:39] <SteveA> the idea is, a doomed transaction cannot be committed
[11:44] <SteveA> i think hooking commit() and making it raise is the safest bet
[11:59] <ddaa> Yarrrrgl, shit!
[11:59] <ddaa> lifeless: python import failed again because of connection refused in the middle of the import
[11:59] <lifeless> shitfuckdamn
[12:00] <ddaa> Mh...
[12:00] <lifeless> talk to niemeyer
[12:00] <ddaa> I'm not sure that connection refused is actually being retried now.
[12:00] <lifeless> might be working getting an synced copy locally, running up cvs on that
[12:00] <lifeless> then talk locally
[12:00] <ddaa> That could be a pretty trivial fix to enable retrying on connection refused.
[12:01] <ddaa> I did not enable it, because the semantics of that seemed wrong to me.
[12:02] <ddaa> lifeless: mh, I think all the required plumbing is still around
[12:02] <ddaa> lifeless: which one would you prefer?
[12:03] <lifeless> ddaa: shortest path followed by prevent-other-occurences
[12:04] <lifeless> whats fastest to do ?
[12:04] <lifeless> to get python in
[12:04] <lifeless> do that.
[12:04] <lifeless> After doing that, if we still are vulnerable to that code path not retrying, make it retry.
[12:06] <ddaa> In all likelihood, a local cvs repo will yield a quicker import, even though it will require more work
[12:06] <lifeless> go to it...
[12:06] <lifeless> until neimeyer awakes, I suggest starting on the other fix
[12:08] <ddaa> why is neimeyer required for that?
[12:09] <lifeless> well
[12:09] <lifeless> where is it hosted ?
[12:09] <ddaa> sourceforge, of course...
[12:09] <lifeless> oh, easy then :0
[12:12] <lifeless> ddaa: there is none. use our url generators logic
[12:12] <ddaa> ?
[12:12] <lifeless> theres a pattern to the urls
[12:12] <lifeless> we had some code somewhere at one point to calculate it
[12:12] <lifeless> the only folk that get the link are project admins
[12:13] <ddaa> SIGSEV
[12:13] <ddaa> (invalide reference, I mean)
[12:13] <ddaa> I do not recall that.
[12:19] <ddaa> lifeless: I have no clue where that code is/were. I'll wait niemeyer since you suggest he might know something useful.
[12:19] <ddaa> * wait for niemeyer
[12:20] <lifeless> ddaa: look in old emails
[12:20] <lifeless> ddaa: I'm sure we've got a reference handy
[12:22] <ddaa> no idea what you want me to look for, I do not recall ever talking about automatic generation of cvs tarball urls.
[12:23] <ddaa> ha, found something
[12:24] <ddaa> http://cvs.sourceforge.net/cvstarballs/
[12:53] <ddaa> lifeless: WTF?
[12:53] <ddaa> https://macquarie.warthogs.hbd.com/hoover/status/
[12:53] <ddaa> https://macquarie.warthogs.hbd.com/roomba/status/
[12:54] <ddaa> ha, nevermind
[01:25] <ddaa> and blesses test suites for catching his stupid typos
[01:26] <ddaa> or maybe should I curse duck typing
[01:26] <ddaa> okay guys, let's rewrite launchpad in... I dunno... C#?
[01:27] <ddaa> mhh... no, OCaml!
[01:29] <Kinnison> OCaml!
[01:29] <Kinnison> sodding customers
[01:48] <SteveA> stub: i've hacked up another servertest program that totally refuses connections this time
[01:51] <stub> ok
[01:53] <SteveA> stub: send as signed mail.
[01:55] <SteveA> also, i think we'll want to have a different upper and lower boundary of pending tasks, so the socket state doesn't flutter.
[02:09] <mpt> Good morning Launchpad lovers
[02:10] <niemeyer> Morning! :)
[02:11] <SteveA> mpt: morning
[02:11] <Kinnison> heyhi mpt
[02:12] <SteveA> mpt: on my launchpad--Menus--0 branch, i've resolved conflicts with RF, and fixed a bug in one of the summaries you added
[02:12] <mpt> SteveA: Awesome, thanks
[02:12] <mpt> The former was #1 on my to-do list for today (and the latter I didn't know existed)
[02:14] <stub> SteveA: That works better with Pound. It decides that the backend is dead, which will cause all requests to be redirected to another backend. It does cause some annoying spam in the logs ('connection reset by peer'), but no need to fret over that.
[02:15] <SteveA> stub: okay.  so, i'll work this into something for launchpad then.
[02:18] <sivang> morning mpt !
[02:19] <SteveA> hmm.. about those messages in the logs
[02:19] <SteveA> does that mean that existing connections are being killed off?
[02:20] <SteveA> i guess i should try with wget
[02:20] <SteveA> and make sure it actually gets the proper result returned, or gets a connection refused
[02:21] <mpt> hi sivang
[02:26] <stub> SteveA: I expect it is because the connection connection, but was then reset or dropped. Which is different to what it normally expects to see when a backend dies (the connection doesn't connect at all). 
[02:27] <SteveA> that isn't what i want to happen
[02:27] <SteveA> connections that get accepted should to go completion
[02:27] <SteveA> but i'm not sure i can actually make that work all the time
[02:28] <SteveA> i am a bit concerned that all the tasks are essentially being aborted.  so, i'll check that out with a wget script
[02:30] <stub> Just don't waste too much time on it if you have stuff you would rather be playing with - I'm thinking this won't make much different in our production environment (if one server dies like this, all the rest will soon follow)
[02:32] <ddaa> lifeless: in case you're around, I finally got a cvstarfileurl import of python running on roomba. (needed a lot of tweaking because cvstarfileurl support had bitrotten a bit and because the launchpad code on importd is sooo old).
[02:34] <lifeless> ddaa: mm,  if it passes please check by hand against a _real_ python checkout for config problems
[02:35] <ddaa> mh... not sure how to do this check by hand
[02:35] <ddaa> we'll talk about it tomorrow, it's still going to take a while, and I definitely need lunch.
[02:35] <ddaa> and you need sleep
[02:38] <lifeless> ddaa: 'cvs co -D yesterday'; 'diff -x .arch-ids -x {arch} -x CVS'
[03:11] <mpt> lifeless: baz merge gets to "* from archive cached: steve.alexander@canonical.com/launchpad--Menus--0--patch-86", and goes no further
[03:12] <mpt> What's the electronic equivalent of poking it with a stick? :-)
[03:12] <lifeless> mpt: strace it
[03:12] <lifeless> mpt: if lines output, its doing shit
[03:12] <lifeless> night all
[03:12] <mpt> "if lines output"?
[03:13] <mpt> oh, output verb
[03:13] <ddaa> kind of things you really want to do in a genuine xterm
[03:14] <mpt> yah, it's doing lots of read(), occasional write(), and very occasional rt_sigaction(SIGPIPE)
[03:17] <ddaa> maybe it's actually downloading the cachedrev
[03:17] <ddaa> the download code is incredibly slow, and the cachedrevs have grown stupidly huge
[03:17] <mpt> ah, that's quite possible
[03:18] <ddaa> (then there's also the fact that revisions built from cachedrevs are not hardlinked in the revlib, so you will probably want to library-relink a bit after that)
[03:18] <kiko> mpt, you're the one eating up all our bandwidth
[03:19] <mpt> kiko: Oh, that's all right then :-)
[03:19] <ddaa> it's great time we all go bzr, baz warts have become really annoying
[03:29] <sivang> mpt: so there's still work to be done in order to make changes from one reflect on the other I support
[03:29] <sivang> s/support/suppose/
[03:31] <mpt> yes
[03:31] <mpt> I suspect that might be a Malone 1.0.1 task
[03:37] <sivang> Guys, if I have a suggestion and ideas for BOF's related to Launchpad, where should I Put them? (I think we better have a seperate place maybe on the launchpad wiki?)
[03:39] <mpt> sivang: https://wiki.ubuntu.com/UbuntuBelowZero/BOFs, I think
[03:40] <mpt> They're going to need to be scheduled just like the non-LP BoFs
[03:41] <sivang> mpt: I'm sure, but I thought maybe they would be put somewhere else then where the distro team puts their's.
[03:43] <mpt> I doubt it, since some of the same people are involved
[03:44] <kiko> mpt, sivang: AIUI the plan is to schedule the bofs using launchpad
[03:45] <sivang> kiko: I've seen a "spec" manager already available, when will we have access to it?
[03:46] <sivang> s/meetings/BOFs/
[03:49] <sivang> mpt: why does launchapd need a scheduler ? (apart for the calander and events, maybe)
[03:49] <mpt> sivang: for the "Sprint" scheduling app that kiko mentioned
[03:50] <sivang> mpt: ah so UBZ is yet another launchpad sprint from your point of view? :-)
[03:50] <mpt> sivang: No
[03:51] <mpt> sivang: On the contrary, if Launchpad's sprint scheduler was useful only for Launchpad developers, it probably shouldn't be in Launchpad, because of the "huh?" factor
[03:51] <mpt> or more precisely, the "this Launchpad thing obviously isn't for me" factor
[03:53] <sivang> ah I see, so you suggest all of the BOFs should be registered in launchapd and launchapd should use Ubuntu as a test case of it's scheduling capabilities ...?
[03:54] <kiko> sivang, I believe that's the plan, but hold on a bit until we can configm
[03:54] <kiko> confirm, even.
[03:55] <sivang> kiko: sure thing, thanks, and sorry for the noise.
[03:55] <mpt> sivang: No, I'm not suggesting they should be (I'm dubious about the whole "sprint" thing, given the proportion of Free Software projects that are able to afford such meetings)
[03:55] <mpt> but it will be interesting to try, at least.
[03:56] <sivang> very much indeed. As in, I've started writing a spec on the train, would be nice to have launchapd ask me in a stanza form, question to guide me in writing it.
[03:56] <sivang> (altough I would have to have GPRS for that..)
[03:57] <mpt> That wouldn't work unless the train had satellite Internet :-)
[03:58] <mpt> and anyway, Launchpad's spec tracker doesn't actually let you enter specs
[03:58] <kiko> if the route had GPRS support it would probably work
[04:00] <sivang> mpt: so will I be able to at least attach a MoinMoin formatted text file for the spec tracking? or is it just for tracking completiong and status of a spec? (could be as well linked ot it's page on Moin)
[04:01] <mpt> yes, you have to host the spec elsewhere and give Launchpad the URL
[04:02] <ddaa> sivang: I think the "sprint thing" is probably more relevant that you think already, and will become more in the future. All that is required is that the core devels are either 1. close geographically 2. dedicated enough to pay for a yearly trip 3. working for a company where they can have that as a professional expense.
[04:02] <ddaa> I might be a dreamer, but I think 3 is bound to become more widespread in the years to come as companies understand open development processes better.
[04:03] <Kinnison> sivang: You put the spec somewhere and link it from launchpad
[04:03] <Kinnison> sivang: E.g. aranha's specs are on http://wiki.digital-scurf.org/Aranha/Specs
[04:15] <ddaa> rolled out svn directory copying patch, kicked samba and ubuntu-doc
[04:16] <ddaa> elmo: please sacrifice a goat on the import servers, kthxbye
[04:19] <mpt> SteveA: I'm doing Project menus now, scream if I shouldn't be
[04:20] <sivang> ddaa: I sure do hope os :-)
[04:21] <sivang> Kinnison: nice , so I can just start linking my UBZ/BOFS/specX from the spec tracker?
[04:23] <Kinnison> sivang: I think the spec tracker is for the owner of the product
[04:25] <sivang> k, we'll just wait then
[04:25] <kiko> hey carlos, how's it going?
[04:25] <kiko> mpt, you know bug 2117?
[04:25] <kiko> https://launchpad.net/products/malone/+bugs/2117/+edit
[04:26] <kiko> why don't you reassign that to bradb?
[04:26] <carlos> kiko, fine, thanks, cleaning up my mail queue
[04:26] <kiko> carlos, mine is ghastly too
[04:27] <jbailey> Do man pages go into rosetta automatically at this point?
[04:27] <bradb> kiko: that bug is already fixed in the URLs branch, though given that the sab made me remove the "Edit Assignee/Status Details" link, he may tell me to remove the "File Bug on <context>" and "Search <context>" links I added to the actions portlet
[04:27] <carlos> kiko, it's not too bad here...
[04:28] <mpt> kiko: done
[04:28] <bradb> kiko: I also ensured that they're in the same place on the task page too
[04:28] <kiko> bradb, the latest bugs portlet has those links already, no need to put them in the actions portlet, given that..
[04:28] <kiko> but okay
[04:28] <bradb> kiko: I removed it from the latest bugs portlet
[04:28] <bradb> to be a place where it can be seen
[04:29] <kiko> removing it from the latest bugs portlet makes it impossible to file bugs or search bugs from anywhere else the portlet is displayed, doesn't it? product or source package page, for instance..
[04:30] <bradb> kiko: no, those links should simply always be in the actions portlet, imho
[04:31] <bradb> because you can't seem them in the not-actions portlet anyway :)
[04:31] <kiko> even for those other contexs?
[04:31] <bradb> s/seem/see/
[04:31] <kiko> why can't you? :)
[04:31] <kiko> anyway, not such a big deal
[04:31] <bradb> kiko: too much data already shown on the page
[04:31] <bradb> when it lands, you'll see. I'm not too bothered either way, but I think you'll like it.
[04:31] <kiko> yeah, okay
[04:34] <bradb> kiko: btw, can I land the From/Reply-To patch that I sent you?
[04:34] <bradb> BjornT: How's the URL changes review coming along?
[04:36] <BjornT> bradb: just having a lunch break. it shouldn't take too much longer to finish the review, though.
[04:37] <bradb> cool, thanks
[04:38] <kiko> bradb, yeah, let me check. I thought I said r=kiko but I think you missed it.
[04:38] <BjornT> bradb: note that there are a bunch of conflicts now. i'll send a review of the patch level you submitted for review, and then take a quick look at the remaining changes after you've resolved the conflicts.
[04:38] <kiko> bradb, ah, I remembered. I'd ask you to check with Keybuk 
[04:38] <kiko> Keybuk?
[04:38] <jordi> sivang?
[04:39] <Keybuk> kiko: hello
[04:39] <kiko> how's it going
[04:39] <jordi> jblack: ping?
[04:39] <kiko> Keybuk, can you take a look at bradb's proposed change to bugmail headers?
[04:39] <kiko> Keybuk, basically, he's set From: the OP and Reply-To: xxx@bugs.launchpad
[04:41] <Keybuk> URL?
[04:42] <bradb> kiko: are you going to forward him the patch or am i?
[04:42] <Keybuk> ... you mean there's no spec? :)
[04:42] <kiko> there is a spec
[04:43] <kiko> bradb, perhaps update the spec and send both to keybuk?
[04:43] <kiko> you can do it
[04:43] <bradb> ok
[04:45] <sivang> jordi: yeah
[04:45] <sivang> jordi: did I ping you ?
[04:47] <jordi> sivang: we asked you over the weekend
[04:47] <sivang> jordi: ah, re: making yelp display from right to left, I havn't had time to look at the link you sent me , can you please resend it?
[04:48] <jordi> 12:23 < mdke> sivang, yes, we have a problem because yelp displays the persian translation of a document from left to right, instead of right to left
[04:48] <jordi> what was the link?
[04:48] <jordi> I'lve lost my buffer
[04:48] <zyga> hello
[04:48] <sivang> jordi: mdke sent some link to a docteam repor somewhere.
[04:50] <sivang> jordi: let's see if I can find it up
[04:54] <zyga> I need help with squashing one bug down
[04:54] <zyga> could anyone take a look at: http://mateusz.loskot.net/gallery/ubuntu-breezy/edytor_konta_uzytkownika
[04:54] <zyga> and tell me what package contains this configuration utility?
[04:55] <zyga> there is a nasty translation bug there, someone confused 'confirmation' with 'configuration'
[04:56] <WaterSevenUb> zyga, can you make a screenshot in English?:)
[04:57] <zyga> WaterSevenUb: that's not my screenshot and I dont have breezy handy ATM, that's the user configuration utility 
[04:57] <WaterSevenUb> zyga, aah..
[04:57] <zyga> WaterSevenUb: if you look close (near the bottom) it says 'Konfiguracja' which means 'configuration'
[04:57] <zyga> and it should of course say 'configmation'
[04:57] <zyga> WaterSevenUb: hi, by the way :-)
[04:58] <zyga> I requested po downloads from rosetta but I've got no emails yet
[04:58] <ddaa> jamesh: ping
[04:59] <WaterSevenUb> zyga, hi :-)) 
[04:59] <zyga> WaterSevenUb: I think I've got it
[04:59] <zyga> pitti's .tar.bz2 of all .po's sure is handy :)
[05:00] <WaterSevenUb> zyga, users-admin
[05:00] <zyga> WaterSevenUb: hmm...
[05:00] <zyga> WaterSevenUb: it's not here 
[05:00] <zyga> WaterSevenUb: it was not in rosetta either
[05:01] <WaterSevenUb> zyga, gnome-system-tools?
[05:02] <zyga> WaterSevenUb: got it!
[05:05] <bradb> kiko: 
[05:05] <bradb> er
[05:05] <kiko> yes?
[05:06] <SteveA> hi
[05:06] <zyga> WaterSevenUb: btw, how did you know it was supposed to be in gnome-system-tools?
[05:06] <zyga> WaterSevenUb: how did you associate g-s-t and users-admin
[05:06] <bradb> kiko: Just to confirm, is it correct to say that, if foo.bar@canonical.com is subscribed to an ML, and an email is sent to that ML From: foo.bar@canonical.com, Reply-To: somewhere@else.com, the mail will go through even if the list is members only?
[05:07] <carlos> bradb, yes
[05:07] <bradb> carlos: ok, thanks
[05:07] <sivang> zyga: apt-file search users-admin
[05:07] <sivang> gnome-system-tools: usr/bin/users-admin
[05:08] <sivang> zyga: it will give you the package holding a file
[05:09] <zyga> sivang: thanks :)
[05:11] <WaterSevenUb> zyga, in my case... by empirical experience :)
[05:11] <sivang> zyga: my pleasure
[05:11] <sivang> WaterSevenUb: lol
[05:13] <WaterSevenUb> sivang, :-)
[05:15] <bradb> Keybuk: patch sent, with link to updated spec
[05:31] <kiko> sladen?
[06:04] <jordi> jblack: I'll be back.
[06:05] <bradb> ********************************************************
[06:05] <bradb> *  13 conflicted items in this tree. Please            *
[06:05] <bradb> * resolve each conflict with "baz resolved 'filename'" *
[06:05] <bradb> ********************************************************
[06:25] <salgado> BjornT, ping?
[06:29] <BjornT> hi salgado 
[06:32] <salgado> hi BjornT. I'm trying to fix https://launchpad.net/malone/bugs/2411, and I hope you can give me some help, as it involves an auto generated widget
[06:33] <salgado> aparently the problem is because I'm not providing the context to the widget, so it doesn't know where to get the selected value from
[06:34] <salgado> it that's really the problem, how do I pass the context to the widget?
[06:37] <WaterSevenUb> zyga, where did you get the langpack tarball ?:)
[06:37] <WaterSevenUb> zyga, you asked pitti directly?
[06:43] <carlos> jordi, hi, around?
[06:47] <BjornT> salgado: sorry, was on the phone. which view class does the setting up of the widget?
[06:48] <salgado> BjornT, ShipItRequestView. and its context is a shippingrequest
[06:52] <BjornT> salgado: ok. it seems that ShipItRequestView.context is an IShipItApplication, so you need to explicitly pass in the correct context (context=shippingrequest) to setUpWidgets
[06:53] <carlos> SteveA, hi, around?
[06:53] <SteveA> yes
[06:56] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Fix a bug in EmailAddressSet.getByEmail() and another in the reset password form processing. r=kiko (patch-2432: guilherme.salgado@canonical.com)
[07:00] <sladen> kiko-fud: yo?
[07:00] <carlos> SteveA, is the gajim issue solved completely?
[07:01] <carlos> SteveA, should I do anything about it?
[07:01] <Kinnison> What time do people think spiv will get here?
[07:01] <Kinnison> ca. 6h time?
[07:02] <SteveA> carlos: if i recall it all, there's the issue of whether a new pot file will be synced over the one they want translated by some importer script, whether we have a problem with permissions (the irc transcript seemed to show there was a problem with people from a team that ought to be able to do something not being able to)
[07:03] <SteveA> carlos: i think you need to talk with jordi, or with nkour about it
[07:03] <carlos> SteveA, ok
[07:04] <carlos> thanks
[07:07] <salgado> BjornT, IIUC, the context I need to pass is the one which has an attribute named country, right? if so, that would be an IPerson (the logged in user). but that doesn't seem to work
[07:10] <jordi> carlos: not resolved.
[07:10] <jordi> minimised, at most.
[07:10] <carlos> jordi, what's missing?
[07:11] <jordi> carlos: it seems the breezy template was outdated. I am not sure updating by hand is the way to go, but I did that on request of the upstream developer. It seems people were re-translating it there.
[07:11] <jordi> second, the 0.8 branch is wrong (a fuckup by the guy who registered gajim), and should be removed.
[07:11] <carlos> jordi, the template was outdated?
[07:12] <carlos> jordi, did you check that breezy has a new version?
[07:12] <jordi> third, gajim is owned by gajim-devs, to which nkour belongs, but he has no access to perform some admin actions in the product.
[07:12] <jordi> carlos: I checked in packages.u.c yes.
[07:12] <carlos> jordi, I cannot do anything about the 0.8 branch, morgs or stub should help there
[07:12] <BjornT> salgado: yes, that should work. i'll take a quick look again
[07:13] <carlos> jordi, did you check the content of the tarball? if they are not updating the .pot file is not our fault and will require that pitti do some changes on the build process to update it
[07:13] <jordi> didn't check that, no.
[07:13] <jordi> easy enough to do though.
[07:15] <jordi> jblack: ping
[07:25] <BjornT> salgado: hmm, i'd expect passing the context would work, might be a bug somewhere... anyway, passing initial={'country': self.user.country} works
[07:27] <BjornT> salgado: the other option is to use setUpEditWidgets instead, and pass source=self.user
[07:27] <kiko-fud> hey sladen 
[07:28] <salgado> BjornT, what's the preferred option?
[07:32] <BjornT> salgado: i'd say setUpEditWidgets. but i think we'll move away from these functions soon, and use zope.formlib instead.
[07:35] <SteveA> lifeless: if you make the 915 resolution hack run before S05vbesave, then you won't need it in resume.sh
[07:36] <SteveA> salgado: did you take a look at mark's EditView base class?
[07:36] <salgado> SteveA, no, not yet
[07:37] <SteveA> i think now is a good time for you to look
[07:38] <BjornT> SteveA, salgado: by the looks of it, it seems that mark's FormView has the same problem, it uses setUpWidgets with no initial values
[07:38] <SteveA> let
[07:38] <SteveA> let's fix this in the EditView then
[07:39] <BjornT> it's call FormView, btw
[07:39] <salgado> yes, I saw in the email mark sent
[07:40] <salgado> the problem is that all my trees are too old. none of them have launchpad/browser/form.py
[07:44] <SteveA> hmm.. yeah, i guess we should keep this clean for cherrypicking
[07:45] <salgado> yes. I'm going to commit my fix, ask stub to cherrypick it and then I'll look into using FormView
[07:45] <SteveA> cool
[07:45] <SteveA> mpt: ping
[07:47] <elmo> is naieve large file reading known to suck in python?
[07:47] <elmo> i.e. if I open() and .readlines() a 120Mb file isn't going to hurt my machine?
[07:48] <salgado> SteveA, mpt's having pt classess now
[08:06] <salgado> cprov, did you fix https://launchpad.net/malone/bugs/2376 in one of your branches already?
[08:07] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Fix https://launchpad.net/malone/bugs/2314. r=kiko (patch-2433: guilherme.salgado@canonical.com)
[08:08] <kiko> sladen, can you follow up on bug 2249?
[08:08] <kiko> or
[08:09] <kiko> go salgado
[08:09] <cprov> salgado: it's already in RF patch-2340, I've done it during the weekend
[08:09] <cprov> salgado: btw, did you modified the template some time ago ?
[08:10] <salgado> cprov, what's the change you made? according to SteveA's request I was thinking the problem would be in foaf-validategpg.pt, but that template is correct
[08:10] <salgado> cprov, I changed all LoginToken templates some time ago; mainly to add this option so you can be logged in after submitting the form
[08:10] <cprov> salgado: simply removed the not used section in the template you mentioned
[08:11] <salgado> cprov, what's the "not used section"?
[08:11] <cprov> salgado: "keep me logged after reset my password" or something like that
[08:12] <salgado> cprov, but that *is used*. the only problem with that is the text
[08:12] <salgado> it should say "log me in after validating my key" instead of what it says now
[08:13] <cprov> salgado: does the validade_gpg token do that ?
[08:13] <salgado> that's already merged in rocketfuel?
[08:13] <salgado> yes, it does. all LoginTokens do that. 
[08:13] <salgado> kiko, can you access https://launchpad.ubuntu.com/people/svaksha/+editwikinames so I can get to the traceback ?
[08:14] <kiko> sure
[08:14] <kiko> salgado, remember to update bug 2314's status
[08:15] <salgado> thanks to remind me. I had it open here
[08:15] <kiko> salgado, what's the bug # for svaksha's issue?
[08:15] <salgado> https://launchpad.net/malone/bugs/1576
[08:16] <kiko> funny traceback
[08:16] <cprov> salgado: my mistake, the docstring wasn't updated, I'll repair it now
[08:16] <salgado> cprov, don't worry. I'll fix it
[08:17] <salgado> the text needs to be fixed in other templates too
[08:18] <salgado> cprov, are you sure it's patch-2340?
[08:18] <cprov> salgado: ok, PEP-237 compilant docstring for  validateGpg method would be great, can you do it for me too ?
[08:19] <kiko> salgado, actually https://launchpad.net/malone/bugs/2369
[08:19] <cprov> salgado: 2430 ... this weekend
[08:19] <kiko> salgado, posted traceback
[08:20] <salgado> kiko, ta
[08:21] <salgado> cprov, you said 2340 before
[08:21] <kiko> salgado, it's quite an odd one
[08:22] <salgado> kiko, I've never seen something similar
[08:22] <cprov> salgado: yes, yes forgive me sir ;) bug number and changeset are getting fuzzy this time
[08:22] <kiko> oh!
[08:22] <salgado> he doesn't have a ubuntu wiki
[08:22] <SteveA> how about we have changesets the same as bugnumbers?  can bzr do that?
[08:23] <kiko> salgado, found it.
[08:23] <salgado> kiko, you have access to the production database now?
[08:24] <kiko> salgado, read-only, yes.
[08:27] <salgado> kiko, can you run https://chinstrap.ubuntu.com/~dsilvers/paste/fileXKiAOv.html on production for me?
[08:28] <kiko> hmm, actually, elmo hasn't set up my account on gangotri yet. can it be staging?
[08:28] <salgado> I guess so
[08:29] <kiko>  wiki | wikiname 
[08:29] <kiko> ------+----------
[08:29] <kiko> (0 rows)
[08:33] <salgado> kiko, this one https://chinstrap.ubuntu.com/~dsilvers/paste/fileca1O4i.html, now. ;)
[08:34] <kiko> (27 rows)
[08:35] <kiko> including dsilvers and robitaille
[08:35] <kiko> 32167
[08:35] <kiko> this is the highest ID, salgado 
[08:35] <salgado> this is bad
[08:35] <kiko> 247027
[08:35] <salgado> kiko, https://launchpad.net/people/dsilvers/+editwikinames
[08:36] <kiko> that's our highest ID
[08:36] <salgado> you should get the same traceback there
[08:39] <kiko> salgado, same traceback.
[08:39] <kiko> launchpad_staging=> select id from person where name = 'neumann';
[08:39] <kiko>    id   
[08:39] <kiko> --------
[08:39] <kiko>  246887
[08:40] <kiko> salgado, for the record. :)
[08:40] <kiko> (so it probably is a remainder of a bug somewhere, or something that only happens very rarely)
[08:42] <salgado> kiko, I know you're good at that, so maybe you can go to your +editwikinames page and try to get rid of your ubuntu wikiname
[08:42] <kiko> sure
[08:42] <salgado> I tried already but I didn't manage to remove it
[08:56] <salgado> SteveA, ping?
[08:56] <SteveA> hi
[08:56] <kiko> https://launchpad.net/people/kiko/+editwikinames
[08:57] <kiko> salgado, 505 for me too.
[08:57] <kiko> err 500.
[08:57] <salgado> SteveA, have you seen BjornT's questions in his review of my basic-voting branch?
[08:58] <salgado> kiko, did you ever went to that page or changed your wikiname using the old one?
[08:58] <kiko> nope
[08:58] <kiko> never
[08:58] <kiko> or hmmm
[08:58] <kiko> actually
[08:59] <SteveA> salgado: i don't think so.  can you tell me the subject of the emails?
[08:59] <kiko> I once told the ubuntu wiki to disable my account forever
[08:59] <salgado> SteveA, REVIEW: guilherme.salgado@canonical.com/launchpad--basic-voting--1
[09:01] <mpt> SteveA: pong
[09:03] <SteveA> salgado, BjornT: in launchpad, we're deliberately going against what tim peters says about using 'assert' statements.  That's described pretty well in AssertionsInLaunchpad.
[09:05] <kiko> lifeless, ddaa, ping?
[09:06] <salgado> kiko, when you disabled your account in the ubuntu wiki?
[09:06] <kiko> salgado, a month ago +/-
[09:06] <salgado> I disabled mine but I still can see my ubuntu wikiname in launchpad
[09:07] <salgado> I can't login on the ubuntu wiki, though
[09:08] <kiko> I filed that bug on spiv
[09:08] <salgado> what bug #?
[09:11] <SteveA> kiko: send spiv a reminder email to look at his bugs
[09:12] <kiko> will do
[09:18] <sladen> kiko: ack.
[09:19] <kiko> thanks sladen 
[09:20] <sladen> kiko: while you're doing funny things 'mdz' exists and so does 'mdzex'  the form works and the latter doesn't ...depending on the context
[09:20] <kiko> sladen, sorry -- can you rephrase that?
[09:20] <sladen> kiko: /people/mdz /people/mdzex
[09:21] <sladen> kiko: funny things ...with user tables
[09:21] <kiko> how did you find mdzex?
[09:22] <kiko> sladen, I couldn't find mdzex by searching through /people..
[09:22] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Fix https://launchpad.net/malone/bugs/2411. (patch-2434: guilherme.salgado@canonical.com)
[09:24] <sivang> kiko: ah nice, I see that the specification is now being used, can I then go and use it as well?
[09:26] <kiko> sivang, there are some malone specs up -- are you talking about ubz planning?
[09:27] <kiko> sladen?
[09:31] <sivang> kiko: yes
[09:32] <kiko> sivang, sorry, too overwhelmed today, maybe chat tomorrow on the subject
[09:32] <sivang> kiko: sure no prob
[09:32] <sivang> kiko: gazillio thanks whatsoever
[09:33] <kiko> nah, enjoy
[09:33] <kiko> salgado, ask for the cherry-pick
[09:38] <bradb> anyone: with an up-to-date rf tree does http://localhost:8086/products/ubuntu/+bugs appear very screwed up to you?
[09:45] <mpt> bradb: Looks fine for me, but then I've fixed the layout in this branch
[09:45] <mpt> It's not using floats no more
[09:46] <sladen> kiko: https://launchpad.net/people/techboard  the first links to exmdz  (which my brain is telling me /was/ mdzex)
[09:46] <kiko> oh!
[09:46] <sladen> kiko: and following that to https://launchpad.net/people/exmdz goes foobar
[09:47] <kiko> aha
[09:49] <salgado> exmdz is a merged account. it shouldn't never show up on Launchpad. in this case it does because team memberships weren't transfered when mdz merged accounts
[09:49] <kiko> salgado, did we not fix the existing data?
[09:50] <salgado> kiko, no, we didn't
[09:50] <bradb> mpt: Hm, maybe that'll improve what I see: the actions portlet's head is chopped off and the "status" and "target" columns are appearing inside the bug lists portlet
[09:50] <kiko> salgado, possible?
[09:51] <salgado> kiko, yes, it's possible but I'm not sure how hard
[09:52] <sladen> do foaf bugs go under launchpad?
[09:52] <kiko> sladen, yes.
[09:53] <kiko> salgado, file a bug, then, because it's an issue that will persist for a while (since users can't fix it themselves)
[09:53] <mpt> bradb: the rightmost columns have always slid underneath the portlet, but that's now fixed
[09:54] <bradb> here there right inside it. never seen that before
[09:54] <kiko> salgado, interesting thing about bug 1576 is that there is no longer a way to view svaksha's Wiki link anylonger, right?
[09:55] <bradb> s/there/they're/
[09:55] <salgado> kiko, yes. it's the same with yours. you guys have no wikinames in the database
[09:55] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Fix https://launchpad.net/malone/bugs/2376. (patch-2435: guilherme.salgado@canonical.com)
[09:55] <kiko> salgado just keeps landing them
[09:56] <salgado> you said it man
[09:59] <jordi> YOU SAY
[10:01] <mpt> WHAT YOU SAY
[10:30] <bradb> mpt: Can we deboldify messages in portalMessage?
[10:35] <mpt> bradb: please :-)
[10:35] <bradb> i'll tweak it here
[10:35] <bradb> well, just deboldify anyway
[10:36] <bradb> mpt: unless someone specifically said we can't? :)
[10:36] <mpt> Not yet
[10:36] <bradb> ok, cool
[10:36] <mpt> In the "Undo bugs in plone.css" part of launchpad.css, .portalMessage {font-weight: normal;}
[10:36] <lifeless> SteveA: you need it in resume for hibernate, vberestore doesn't restore it AIUI
[10:36] <lifeless> kiko: pong
[10:39] <bradb> mpt: Nice. I feel much less humliated now when Launchpad shows me a notification message. (I changed it here like you said.)
[10:42] <kiko> lifeless, I committed a change together with an RF merge -- mistake or sin?
[10:42] <lifeless> doesn't really matter
[10:42] <kiko> wasn't that considered "bad"?
[10:42] <lifeless> its not ideal
[10:42] <lifeless> and for replay purposes it sucks. 
[10:43] <lifeless> i.e it can't be easily cherry picked to production
[10:43] <kiko> yes, that I imagined.
[10:47] <ddaa> lifeless: ho, still around?
[10:47] <ddaa> samba update: fixed previous bug, found new one.
[10:48] <ddaa> svn allows you to add and (actually copy) and patch a file in the same revision
[10:48] <ddaa>    A /trunk/packaging/Debian/debian-stable (from /branches/SAMBA_3_0/packaging/Debian/debian-stable:731)
[10:48] <ddaa>    M /trunk/packaging/Debian/debian-stable/rules
[10:49] <ddaa> I'm thinking of maintaining a dict of path->(oldpath, oldrev) in ChangesIterator, populated by recursive copying change, and used to tell PatchedFile about a dislocated ancestry if necessary.
[10:50] <ddaa> Also, ubuntu-doc is failed because it contains an "R" change, that is "Replaced".
[10:50] <lifeless> garh
[10:50] <lifeless> good work
[10:50] <lifeless> keep at it
[10:51] <ddaa> any better idea for the dislocated ancestry problem?
[10:51] <lifeless> nup
[10:51] <lifeless> other than taking the freaking svn devs out and shooting them
[10:51] <ddaa> please confirm that ChangesIterator is local to a revision.
[10:51] <lifeless> changesiterator iterates changes within a revision
[10:52] <lifeless> or more precisely from rev N-1 to rev-N
[10:52] <ddaa> lifeless: past experience shows that, although that is a satisfying procedure, it is ineffective to fix bugs in deployed code.
[10:52] <ddaa> * for fixing bugs
[10:52] <lifeless> I liked your first statement more
[10:52] <ddaa> is my Vulcan speak improving :)
[10:53] <ddaa> okay, will add more ga'r to cscvs, then
[11:02] <mpt> kiko: Do you know what's the point of having hackergotchi + emblem for both people and teams, rather than just hackergotchi for people and emblems for teams?
[11:02] <kiko> mpt, isn't there an arcane theory that emblems are special?
[11:04] <mpt> kiko: Yes, I thought they were special to teams
[11:04] <mpt> so if you were a member of a team with an emblem, you got that emblem
[11:04] <kiko> not quite sure
[11:04] <mpt> you couldn't fake it yourself
[11:13] <mpt> ok, I'm homeward
[11:24] <kiko> salgado_sis or salgado_nv? :)
[11:24] <salgado> nv
[11:43] <Kinnison> ciao dudes
[11:56] <sivang> night all
[11:56] <sivang> bye Kinnison 
[12:02] <salgado> BjornT, ping?