=== Mez [n=Mez@cpc4-lich4-3-0-cust247.brhm.cable.ntl.com] has joined #launchpad === ChrisJ97|food is now known as ChrisJ79 === robitaille [n=robitail@d154-5-117-228.bchsia.telus.net] has joined #launchpad === zyga [n=zyga@chello084010027057.chello.pl] has joined #launchpad === cogumbreiro [n=tiago@81.20.250.82] has left #launchpad [] === Seveaz [n=seveas@seveas.demon.nl] has joined #launchpad [02:31] 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) === spiv [n=andrew@adsl-66-203.swiftdsl.com.au] has joined #launchpad === Seveas [n=seveas@seveas.demon.nl] has joined #launchpad === stub [n=stub@203-214-4-72.dyn.iinet.net.au] has joined #launchpad === Znarl [i=karl@bb-82-108-14-161.ukonline.co.uk] has joined #launchpad [04:09] 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] stub: latest sourcerer and hct and rf [04:09] or dont cherry pick after the hct landing to launchpad === ChrisJ79 is now known as ChrisJ79|away [04:21] 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] stub: rollout hct - 3 and sourcerer -3 [04:22] hct head is good for lp head, hct head - 1 is a rollback of hct head -2. [04:22] - 3 patch levels fromo trunk. Got it. === stub is turning italian === robitaille [n=robitail@d154-5-117-228.bchsia.telus.net] has joined #launchpad [04:33] Merge to rocketfuel@canonical.com/dists--devel--0: [trivial] Snapshot 1.32 attempting to fix cherry pick problems (patch-115: stuart.bishop@canonical.com) === Burgundavia [n=corey@S0106000000cc07fc.gv.shawcable.net] has joined #launchpad [06:04] Merge to rocketfuel@canonical.com/launchpad--production--1.32: [trivial] Specifications patch from Steve, with added 'i' (patch-7: stuart.bishop@canonical.com) === elmo [n=james@83-216-156-21.jamest747.adsl.metronet.co.uk] has joined #launchpad === Lathiat [i=lathiat@gasp.bur.st] has left #launchpad [] === dand [n=dand@gw.datagroup.ro] has joined #launchpad === interalia [n=interali@adsl-60-232.swiftdsl.com.au] has joined #launchpad [08:06] Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] Add needed section to production configs (patch-2431: stuart.bishop@canonical.com) === dand [n=dand@gw.datagroup.ro] has joined #launchpad === _Rappy_ [n=hunt-pre@dsl-253-122.monet.no] has joined #launchpad === mdz [n=mdz@ca-studio-bsr1o-251.vnnyca.adelphia.net] has joined #launchpad === dand [n=dand@gw.datagroup.ro] has joined #launchpad [09:12] Merge to rocketfuel@canonical.com/launchpad--production--1.32: [trivial] Add needed config sections (patch-8: stuart.bishop@canonical.com) [09:16] hi === Mez [n=Mez@cpc4-lich4-3-0-cust247.brhm.cable.ntl.com] has joined #launchpad [09:41] 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] hi stub. how's it all going? [09:59] Good enough [10:08] Good Morning all [10:08] lifeless: my X1 just arrived [10:08] lifeless: anything i need to know before installing breezy on it? [10:08] SteveA: nup [10:08] oh [10:08] SteveA: IBM laptop? [10:08] you need the 915resolution thingy [10:08] sivang: better [10:08] sivang: nope. dell. [10:09] lifeless: okay. is there a package, or is it a DIY? [10:09] or, can i steal it from you, and stick it on a USB key [10:09] SteveA: DIY, I have source around here. [10:10] mailed you signed binary [10:10] uhm, I put it in /etc/acpi/resume.sh and in the gdm init script [10:10] erm, not resume. hmm somewhere [10:11] /usr/local/sbin/915resolution 32 1280 768 [10:11] /usr/local/sbin/915resolution 43 1280 768 [10:11] /usr/local/sbin/915resolution 52 1280 768 [10:11] damn, something has removed it from my resume script [10:11] probably why hibernate resume isn't working :_) [10:12] I put that after the vbetool state restore line [10:16] hmm... bad signature from you [10:16] because the MG2 Works virus scanner added some text to the message [10:17] and removed the attachment [10:17] maybe you can send it again, encrypted and signed? === SteveA pings lifeless [10:24] lifeless: how come it's better? (I want to buy one and want to hear recommendations) [10:25] SteveA: garh. [10:26] 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] SteveA: goddamn evos gpg logic is sucky [10:30] Did you get a sane keyboard from DELL, or stuck with Lithuanian or whatever the local variant is? [10:30] got a british one [10:30] wanted a US one [10:31] lifeless: got it, thanks [10:34] SteveA: The country selector widget is busted - reload your order page and you find your contry listed as Afganistan [10:35] None of the options have selected= set [10:39] arse. [10:40] does it write data properly to the database? [10:41] SteveA: Yes - country is being stored correctly [10:42] okay, so not a showstopper [10:42] but i can see a cherrypick request occuring tomorrow [10:43] 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] oh. that's not good. === Kinnison continues to clean out the dogfood db [10:47] 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? === carlos_ [n=carlos@243.Red-83-47-24.pooles.rima-tde.net] has joined #launchpad [11:02] goooood morning!!! [11:02] hi carlos [11:02] welcome back [11:02] thanks [11:03] how's going? [11:03] things are looking pretty good [11:03] there's some rosetta stuff that jordi was helping with over the weekend [11:03] an issue about the wrong version of a pot file being in rosetta === terrex [n=terrex@84-122-83-29.onocable.ono.com] has joined #launchpad [11:04] and possibly some permissions problems with who can change stuff / upload pot files [11:04] ok [11:05] I hope I will have all changes done so Jordi has all rights in place. === terrex [n=terrex@84-122-83-29.onocable.ono.com] has joined #launchpad [11:05] now that language packs seems to have only minor problems, that should be doable [11:09] Merge to rocketfuel@canonical.com/launchpad--production--1.33: [trivial] Add needed config sections (patch-3: stuart.bishop@canonical.com) === ddaa [n=ddaa@ordo.xlii.org] has joined #launchpad [11:14] stub: how often does gina commit() ? [11:17] aah, -c [11:17] never mind [11:19] 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] 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] bob2: what's a recipe database ? [11:21] sivang: a database of recipes... [11:21] cooking? [11:21] bob2: Python Poetry ? :-) [11:22] of course === sivang looks it up [11:30] stub: ping? [11:30] jamesh: pong [11:31] 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] 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] 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] stub: which method do you think would be better? [11:35] 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] SteveA: weird, worked for me [11:36] also, the install CD just broke === SteveA hopes he hasn't got a flaky laptop [11:37] 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] I'll say [11:37] stub: okay. is there an actual command to error out the connection, or do a dud command? [11:37] aborting the transaction would not stop future queries from being accepted, which is a problem [11:38] I don't think there is a 'break this transaction' command ;) === jamesh wonders what statement has the least chance of becoming valid in a future version of postgres :) [11:38] 'break this transaction' is probably a good bet ;) [11:39] this concept was "dooming a transaction" when discussed with zope before [11:39] the idea is, a doomed transaction cannot be committed [11:44] i think hooking commit() and making it raise is the safest bet === camilotelles [n=Camilo@20132139198.user.veloxzone.com.br] has joined #launchpad === WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad [11:59] Yarrrrgl, shit! [11:59] lifeless: python import failed again because of connection refused in the middle of the import [11:59] shitfuckdamn [12:00] Mh... [12:00] talk to niemeyer === plmxn [n=plmxn@tunnel-43-72.vpn.uib.no] has joined #launchpad [12:00] I'm not sure that connection refused is actually being retried now. [12:00] might be working getting an synced copy locally, running up cvs on that [12:00] then talk locally [12:00] That could be a pretty trivial fix to enable retrying on connection refused. [12:01] I did not enable it, because the semantics of that seemed wrong to me. === ddaa checks [12:02] lifeless: mh, I think all the required plumbing is still around [12:02] lifeless: which one would you prefer? [12:03] ddaa: shortest path followed by prevent-other-occurences === ddaa is not sure how to parse that [12:04] whats fastest to do ? [12:04] to get python in [12:04] do that. [12:04] After doing that, if we still are vulnerable to that code path not retrying, make it retry. [12:06] In all likelihood, a local cvs repo will yield a quicker import, even though it will require more work [12:06] go to it... [12:06] until neimeyer awakes, I suggest starting on the other fix [12:08] why is neimeyer required for that? [12:09] well [12:09] where is it hosted ? [12:09] sourceforge, of course... [12:09] oh, easy then :0 === ddaa is trying to find the "download cvs tarball" link [12:12] ddaa: there is none. use our url generators logic [12:12] ? [12:12] theres a pattern to the urls [12:12] we had some code somewhere at one point to calculate it [12:12] the only folk that get the link are project admins [12:13] SIGSEV [12:13] (invalide reference, I mean) [12:13] I do not recall that. === Keybuk [n=scott@syndicate.netsplit.com] has joined #launchpad [12:19] lifeless: I have no clue where that code is/were. I'll wait niemeyer since you suggest he might know something useful. [12:19] * wait for niemeyer [12:20] ddaa: look in old emails [12:20] ddaa: I'm sure we've got a reference handy [12:22] no idea what you want me to look for, I do not recall ever talking about automatic generation of cvs tarball urls. [12:23] ha, found something [12:24] http://cvs.sourceforge.net/cvstarballs/ === ChanServ [ChanServ@services.] has joined #launchpad [12:53] lifeless: WTF? [12:53] https://macquarie.warthogs.hbd.com/hoover/status/ [12:53] https://macquarie.warthogs.hbd.com/roomba/status/ [12:54] ha, nevermind === carlos [n=carlos@243.Red-83-47-24.pooles.rima-tde.net] has joined #launchpad === Seveas [n=seveas@seveas.demon.nl] has joined #launchpad === ddaa hacks importd so it will actually use cvstarfileurl, again [01:25] and blesses test suites for catching his stupid typos [01:26] or maybe should I curse duck typing [01:26] okay guys, let's rewrite launchpad in... I dunno... C#? [01:27] mhh... no, OCaml! [01:29] OCaml! === Kinnison had to install ocamlweb on his server the other day [01:29] sodding customers === jinty [n=jinty@205.134.224.215] has joined #launchpad === stub [n=stub@203-214-4-72.dyn.iinet.net.au] has joined #launchpad [01:48] stub: i've hacked up another servertest program that totally refuses connections this time [01:51] ok === Seveaz [n=seveas@seveas.demon.nl] has joined #launchpad [01:53] stub: send as signed mail. [01:55] also, i think we'll want to have a different upper and lower boundary of pending tasks, so the socket state doesn't flutter. === niemeyer [n=niemeyer@200.181.175.36] has joined #launchpad === mpt [n=mpt@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [02:09] Good morning Launchpad lovers [02:10] Morning! :) [02:11] mpt: morning [02:11] heyhi mpt [02:12] 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] SteveA: Awesome, thanks [02:12] The former was #1 on my to-do list for today (and the latter I didn't know existed) [02:14] 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] stub: okay. so, i'll work this into something for launchpad then. [02:18] morning mpt ! [02:19] hmm.. about those messages in the logs [02:19] does that mean that existing connections are being killed off? === cprov [n=cprov@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [02:20] i guess i should try with wget [02:20] and make sure it actually gets the proper result returned, or gets a connection refused [02:21] hi sivang === carlos -> lunch [02:26] 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] that isn't what i want to happen [02:27] connections that get accepted should to go completion [02:27] but i'm not sure i can actually make that work all the time [02:28] 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] 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] 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] ddaa: mm, if it passes please check by hand against a _real_ python checkout for config problems [02:35] mh... not sure how to do this check by hand [02:35] we'll talk about it tomorrow, it's still going to take a while, and I definitely need lunch. [02:35] and you need sleep [02:38] ddaa: 'cvs co -D yesterday'; 'diff -x .arch-ids -x {arch} -x CVS' === mpt [n=mpt@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === mpt [n=mpt@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === gneuman [n=guest@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [03:11] lifeless: baz merge gets to "* from archive cached: steve.alexander@canonical.com/launchpad--Menus--0--patch-86", and goes no further [03:12] What's the electronic equivalent of poking it with a stick? :-) [03:12] mpt: strace it [03:12] mpt: if lines output, its doing shit [03:12] night all [03:12] "if lines output"? [03:13] oh, output verb [03:13] kind of things you really want to do in a genuine xterm [03:14] yah, it's doing lots of read(), occasional write(), and very occasional rt_sigaction(SIGPIPE) [03:17] maybe it's actually downloading the cachedrev [03:17] the download code is incredibly slow, and the cachedrevs have grown stupidly huge [03:17] ah, that's quite possible [03:18] (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] mpt, you're the one eating up all our bandwidth [03:19] kiko: Oh, that's all right then :-) [03:19] it's great time we all go bzr, baz warts have become really annoying === plmxn [n=plmxn@tunnel-43-110.vpn.uib.no] has joined #launchpad === SnakeBite [n=SnakeBit@84.242.143.64] has joined #launchpad [03:29] mpt: so there's still work to be done in order to make changes from one reflect on the other I support [03:29] s/support/suppose/ [03:31] yes [03:31] I suspect that might be a Malone 1.0.1 task === rbelem is now known as rbelem-afk === mdke [n=matt@unaffiliated/mdke] has joined #launchpad [03:37] 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] sivang: https://wiki.ubuntu.com/UbuntuBelowZero/BOFs, I think [03:40] They're going to need to be scheduled just like the non-LP BoFs [03:41] mpt: I'm sure, but I thought maybe they would be put somewhere else then where the distro team puts their's. === rbelem-afk is now known as rbelem [03:43] I doubt it, since some of the same people are involved === bradb [n=bradb@modemcable033.209-70-69.mc.videotron.ca] has joined #launchpad [03:44] mpt, sivang: AIUI the plan is to schedule the bofs using launchpad [03:45] kiko: I've seen a "spec" manager already available, when will we have access to it? === rbelem is now known as rbelem-afk === sivang wonders if launchapd shoudl attempt to schedule the meetings by itself using some linear programming algorithm ;-) [03:46] s/meetings/BOFs/ === mpt wonders what algorithm Launchpad's scheduler uses [03:49] mpt: why does launchapd need a scheduler ? (apart for the calander and events, maybe) [03:49] sivang: for the "Sprint" scheduling app that kiko mentioned [03:50] mpt: ah so UBZ is yet another launchpad sprint from your point of view? :-) [03:50] sivang: No [03:51] 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] or more precisely, the "this Launchpad thing obviously isn't for me" factor [03:53] 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] sivang, I believe that's the plan, but hold on a bit until we can configm [03:54] confirm, even. [03:55] kiko: sure thing, thanks, and sorry for the noise. [03:55] 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] but it will be interesting to try, at least. [03:56] 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] (altough I would have to have GPRS for that..) [03:57] That wouldn't work unless the train had satellite Internet :-) [03:58] and anyway, Launchpad's spec tracker doesn't actually let you enter specs [03:58] if the route had GPRS support it would probably work [04:00] 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] yes, you have to host the spec elsewhere and give Launchpad the URL [04:02] 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] 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] sivang: You put the spec somewhere and link it from launchpad [04:03] sivang: E.g. aranha's specs are on http://wiki.digital-scurf.org/Aranha/Specs === ChrisJ79|away is now known as ChrisJ79 [04:15] rolled out svn directory copying patch, kicked samba and ubuntu-doc [04:16] elmo: please sacrifice a goat on the import servers, kthxbye [04:19] SteveA: I'm doing Project menus now, scream if I shouldn't be [04:20] ddaa: I sure do hope os :-) [04:21] Kinnison: nice , so I can just start linking my UBZ/BOFS/specX from the spec tracker? [04:23] sivang: I think the spec tracker is for the owner of the product === Kinnison isn't certain what the rules are yet [04:25] k, we'll just wait then [04:25] hey carlos, how's it going? [04:25] mpt, you know bug 2117? [04:25] https://launchpad.net/products/malone/+bugs/2117/+edit [04:26] why don't you reassign that to bradb? [04:26] kiko, fine, thanks, cleaning up my mail queue [04:26] carlos, mine is ghastly too [04:27] Do man pages go into rosetta automatically at this point? [04:27] 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 " and "Search " links I added to the actions portlet [04:27] kiko, it's not too bad here... [04:28] kiko: done [04:28] kiko: I also ensured that they're in the same place on the task page too [04:28] bradb, the latest bugs portlet has those links already, no need to put them in the actions portlet, given that.. [04:28] but okay === ChrisJ79 is now known as ChrisJ79|food [04:28] kiko: I removed it from the latest bugs portlet [04:28] to be a place where it can be seen [04:29] 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] kiko: no, those links should simply always be in the actions portlet, imho [04:31] because you can't seem them in the not-actions portlet anyway :) [04:31] even for those other contexs? [04:31] s/seem/see/ [04:31] why can't you? :) [04:31] anyway, not such a big deal [04:31] kiko: too much data already shown on the page [04:31] when it lands, you'll see. I'm not too bothered either way, but I think you'll like it. [04:31] yeah, okay [04:34] kiko: btw, can I land the From/Reply-To patch that I sent you? [04:34] BjornT: How's the URL changes review coming along? [04:36] bradb: just having a lunch break. it shouldn't take too much longer to finish the review, though. [04:37] cool, thanks === elmo [n=james@83-216-156-21.jamest747.adsl.metronet.co.uk] has joined #launchpad [04:38] bradb, yeah, let me check. I thought I said r=kiko but I think you missed it. [04:38] 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] bradb, ah, I remembered. I'd ask you to check with Keybuk [04:38] Keybuk? [04:38] sivang? [04:39] kiko: hello [04:39] how's it going [04:39] jblack: ping? [04:39] Keybuk, can you take a look at bradb's proposed change to bugmail headers? [04:39] Keybuk, basically, he's set From: the OP and Reply-To: xxx@bugs.launchpad [04:41] URL? === cprov cprov-out [04:42] kiko: are you going to forward him the patch or am i? [04:42] ... you mean there's no spec? :) [04:42] there is a spec [04:43] bradb, perhaps update the spec and send both to keybuk? [04:43] you can do it [04:43] ok === zyga [n=zyga@chello084010027057.chello.pl] has joined #launchpad [04:45] jordi: yeah [04:45] jordi: did I ping you ? [04:47] sivang: we asked you over the weekend [04:47] 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] 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] what was the link? [04:48] I'lve lost my buffer [04:48] hello [04:48] jordi: mdke sent some link to a docteam repor somewhere. [04:50] jordi: let's see if I can find it up [04:54] I need help with squashing one bug down [04:54] could anyone take a look at: http://mateusz.loskot.net/gallery/ubuntu-breezy/edytor_konta_uzytkownika [04:54] and tell me what package contains this configuration utility? [04:55] there is a nasty translation bug there, someone confused 'confirmation' with 'configuration' [04:56] zyga, can you make a screenshot in English?:) [04:57] WaterSevenUb: that's not my screenshot and I dont have breezy handy ATM, that's the user configuration utility [04:57] zyga, aah.. [04:57] WaterSevenUb: if you look close (near the bottom) it says 'Konfiguracja' which means 'configuration' [04:57] and it should of course say 'configmation' [04:57] WaterSevenUb: hi, by the way :-) [04:58] I requested po downloads from rosetta but I've got no emails yet [04:58] jamesh: ping [04:59] zyga, hi :-)) [04:59] WaterSevenUb: I think I've got it [04:59] pitti's .tar.bz2 of all .po's sure is handy :) [05:00] zyga, users-admin [05:00] WaterSevenUb: hmm... [05:00] WaterSevenUb: it's not here [05:00] WaterSevenUb: it was not in rosetta either [05:01] zyga, gnome-system-tools? [05:02] WaterSevenUb: got it! [05:05] kiko: [05:05] er [05:05] yes? [05:06] hi [05:06] WaterSevenUb: btw, how did you know it was supposed to be in gnome-system-tools? [05:06] WaterSevenUb: how did you associate g-s-t and users-admin [05:06] 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] bradb, yes [05:07] carlos: ok, thanks [05:07] zyga: apt-file search users-admin [05:07] gnome-system-tools: usr/bin/users-admin [05:08] zyga: it will give you the package holding a file [05:09] sivang: thanks :) [05:11] zyga, in my case... by empirical experience :) [05:11] zyga: my pleasure [05:11] WaterSevenUb: lol [05:13] sivang, :-) [05:15] Keybuk: patch sent, with link to updated spec === matsubara [n=guest@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [05:31] sladen? === ChrisJ79|food is now known as ChrisJ79 === matsubara [n=guest@200-171-140-32.dsl.telesp.net.br] has left #launchpad ["Leaving"] === SnakeBite [n=SnakeBit@84.242.143.64] has joined #launchpad [06:04] jblack: I'll be back. [06:05] ******************************************************** [06:05] * 13 conflicted items in this tree. Please * [06:05] * resolve each conflict with "baz resolved 'filename'" * [06:05] ******************************************************** === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === robitaille [n=robitail@p235-083.public.uvic.ca] has joined #launchpad [06:25] BjornT, ping? [06:29] hi salgado [06:32] 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] 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] it that's really the problem, how do I pass the context to the widget? [06:37] zyga, where did you get the langpack tarball ?:) [06:37] zyga, you asked pitti directly? [06:43] jordi, hi, around? [06:47] salgado: sorry, was on the phone. which view class does the setting up of the widget? [06:48] BjornT, ShipItRequestView. and its context is a shippingrequest [06:52] 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] SteveA, hi, around? [06:53] yes [06:56] 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] kiko-fud: yo? [07:00] SteveA, is the gajim issue solved completely? [07:01] SteveA, should I do anything about it? [07:01] What time do people think spiv will get here? [07:01] ca. 6h time? [07:02] 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] carlos: i think you need to talk with jordi, or with nkour about it [07:03] SteveA, ok [07:04] thanks [07:07] 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] carlos: not resolved. [07:10] minimised, at most. [07:10] jordi, what's missing? [07:11] 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] second, the 0.8 branch is wrong (a fuckup by the guy who registered gajim), and should be removed. [07:11] jordi, the template was outdated? [07:12] jordi, did you check that breezy has a new version? [07:12] 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] carlos: I checked in packages.u.c yes. [07:12] jordi, I cannot do anything about the 0.8 branch, morgs or stub should help there [07:12] salgado: yes, that should work. i'll take a quick look again [07:13] 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 === jinty [n=jinty@205.134.224.215] has joined #launchpad [07:13] didn't check that, no. [07:13] easy enough to do though. [07:15] jblack: ping [07:25] 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] salgado: the other option is to use setUpEditWidgets instead, and pass source=self.user [07:27] hey sladen [07:28] BjornT, what's the preferred option? [07:32] salgado: i'd say setUpEditWidgets. but i think we'll move away from these functions soon, and use zope.formlib instead. [07:35] lifeless: if you make the 915 resolution hack run before S05vbesave, then you won't need it in resume.sh [07:36] salgado: did you take a look at mark's EditView base class? [07:36] SteveA, no, not yet [07:37] i think now is a good time for you to look [07:38] 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] let [07:38] let's fix this in the EditView then === salgado looks at it [07:39] it's call FormView, btw [07:39] yes, I saw in the email mark sent [07:40] the problem is that all my trees are too old. none of them have launchpad/browser/form.py [07:44] hmm.. yeah, i guess we should keep this clean for cherrypicking [07:45]