[12:14] <matsubara> ajmitch: I don't think that's possible. With 5mb comment/description the form crashed hence bug 61458 :)
[12:14] <Ubugtu> Malone bug 61458 in Ubuntu "Unable to upgrade python (Edgy upgrade using Aptitude)" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61458
[12:15] <matsubara> ugh
[12:15] <matsubara> bug 61548
[12:15] <Ubugtu> Malone bug 61548 in launchpad "Description/comment fields shouldn't crash with insanely large values." [Medium,Confirmed]  http://launchpad.net/bugs/61548
[12:15] <ajmitch> matsubara: maybe it was just over that, but the bug showed up in mutt as [text/plain, base64, utf-8, 7.0M] 
[12:16] <ajmitch> bug 60859 if you want to see how they did it :)
[12:16] <Ubugtu> Malone bug 60859 in ubiquity "Error in installer (crashed) all the times" [Untriaged,Needs info]  http://launchpad.net/bugs/60859
[12:18] <ajmitch> part of it is that it's hard to discover how to attach a file
[12:19] <ajmitch> (when filing, I presume) :)
=== jelmer [n=jelmer@65.91.55.220]  has joined #launchpad
[12:25] <matsubara> ajmitch: bug 30856
[12:25] <Ubugtu> Malone bug 30856 in malone "would like to be able to add attachment(s) while filing the bug" [Low,Confirmed]  http://launchpad.net/bugs/30856
[12:26] <AlinuxOS> hello,is it possible to give owner status to other person in launchpad?
=== flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca]  has left #launchpad ["Bye"] 
[12:26] <AlinuxOS> if yes, how ?
[12:28] <kiko> bradb, another bug with nominations. if I add a new task using +distrotask, it adds it with a nomination (by joe random user, no less) -- try adding an evo bugtask to bug 1.
[12:28] <Ubugtu> Malone bug 1 in ubuntu-meta "Microsoft has a majority market share" [Critical,Confirmed]  http://launchpad.net/bugs/1
=== AlinuxOS [n=alinux@d81-211-249-2.cust.tele2.it]  has joined #launchpad
=== mdz [n=mdz@studiocity-motorola-bsr1-70-36-194-85.vnnyca.adelphia.net]  has joined #launchpad
=== BenC [n=bcollins@72.169.114.90]  has joined #launchpad
=== doko__ [n=doko@dslb-088-073-084-028.pools.arcor-ip.net]  has joined #launchpad
=== Keybuk [n=scott@quest.netsplit.com]  has joined #launchpad
[01:28] <bradb> kiko-zzz: noted
[01:29] <kiko-zzz> bradb, display issue only?
=== LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net]  has joined #launchpad
[01:33] <bradb> kiko-zzz: er. i'm not actually sure what you mean. now that i test it out, e.g., https://staging.launchpad.net/distros/ubuntu/+source/evolution/+bug/35601 , i don't yet see the problem
[01:33] <Ubugtu> Malone bug 35601 in xserver-xorg-video-ati "[X600]  Black screen with DRI" [Critical,Confirmed]  
=== raphink [n=raphink@ubuntu/member/raphink]  has joined #launchpad
[01:39] <kiko-zzz> bradb, https://staging.launchpad.net/distros/ubuntu/+source/firefox/+bug/35601
[01:39] <Ubugtu> Malone bug 35601 in xserver-xorg-video-ati "[X600]  Black screen with DRI" [Critical,Confirmed]  
[01:41] <bradb> kiko-zzz: was it nominated for those releases before you added the new tasks?
[01:41] <kiko-zzz> well
[01:41] <kiko-zzz> there were two tasks
[01:41] <kiko-zzz> I added a nomination
[01:42] <kiko-zzz> nominations were added for both
[01:42] <kiko-zzz> then I added another another task
[01:42] <bradb> kiko-zzz: ok, that's intended
[01:43] <bradb> because the nominations are not specific to packages
[01:43] <bradb> so, the display code displays the nominations for all affected packages
[01:46] <bradb> i suggested that it may be clearer to display nominations right under the task table, instead of mixing them into each task
=== sivang [i=sivan@muse.19inch.net]  has joined #launchpad
=== bradb heads off, later all
=== stub [n=stub@ppp-58.8.3.133.revip2.asianet.co.th]  has joined #launchpad
=== Burgwork [n=corey@ubuntu/member/burgundavia]  has joined #launchpad
=== Burgwork [n=corey@ubuntu/member/burgundavia]  has joined #launchpad
=== LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net]  has joined #launchpad
=== jelmer [n=jelmer@65.91.55.220]  has joined #launchpad
=== AlinuxOS [n=alinux@d81-211-249-2.cust.tele2.it]  has joined #launchpad
=== Kylekf [n=Kyle@61.6.65.122]  has joined #launchpad
=== fabbione [i=fabbione@gordian.fabbione.net]  has joined #launchpad
=== Fujitsu [n=Fujitsu@ubuntu/member/fujitsu]  has joined #launchpad
=== btn [i=vsat@61.94.124.135]  has joined #launchpad
[07:16] <btn> oh
=== Burgundavia [n=corey@ubuntu/member/burgundavia]  has joined #launchpad
=== stub [n=stub@ppp-58.8.15.82.revip2.asianet.co.th]  has joined #launchpad
=== raphink [n=raphink@ubuntu/member/raphink]  has joined #launchpad
[07:40] <Ubugtu> New bug: #61589 in launchpad-bazaar "would be nice if branch listing showed last commit date" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61589
[08:06] <Ubugtu> New bug: #61590 in malone "upstream bugtracker "Inkscape" should be named to "SourceForge"" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61590
[08:10] <Ubugtu> New bug: #61591 in launchpad "add "locale" to user information" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61591
=== sabdfl [n=sabdfl@ubuntu/member/pdpc.silver.sabdfl]  has left #launchpad [] 
=== malcc [n=malcolm@host86-138-251-144.range86-138.btcentralplus.com]  has joined #launchpad
=== Burgwork [n=corey@ubuntu/member/burgundavia]  has joined #launchpad
=== Starting logfile irclogs/launchpad.log
=== ubuntulog [i=ubuntulo@ubuntu/bot/ubuntulog]  has joined #launchpad
=== Topic for #launchpad: Developer meeting: Thu 21 Sep, 1200UTC (wiki:MeetingAgenda) | launchpad-users@lists.canonical.com (wiki:MailingLists) | Channel logs: http://tinyurl.com/72w39
=== Topic (#launchpad): set by matsubara at Thu Sep 14 14:03:44 2006
=== BjornT [n=bjorn@clt-84-32-240-183.dtiltas.lt]  has joined #launchpad
=== raphink [n=raphink@ubuntu/member/raphink]  has joined #launchpad
[09:19] <mpt> SteveA, mailed you about the CSS
[09:22] <carlos> SteveA: hi, around?
[09:22] <SteveA> carlos: yes, I'm around.  But, I need to work with mpt and mpool for the next hour, then I have a conf call for an hour or so.
[09:23] <carlos> SteveA: it will be 5 minutes
[09:23] <carlos> it's about the question you asked me yesterday
[09:23] <SteveA> carlos: ok
[09:23] <SteveA> 5 mins is fine
[09:23] <carlos> SteveA: after talking with danilo
[09:23] <danilo[out] s> carlos: hi ;)
[09:23] <SteveA> hi danilos 
[09:24] <danilos> SteveA: morning
[09:24] <carlos> We think that implementing the changes suggested by kiko would be around 2 days of my work (I will not implement some changes that are related to bug 30602 and that are the complex part)
[09:24] <Ubugtu> Malone bug 30602 in rosetta "Timeout errors in +translate" [Critical,Confirmed]  http://launchpad.net/bugs/30602
[09:25] <carlos> SteveA: for TranslationReview, we will not save any time, just win code readability, but for bug 30602 (it's a priority for 1.0) Danilo thinks that we could save 1 day or so of work
[09:25] <Ubugtu> Malone bug 30602 in rosetta "Timeout errors in +translate" [Critical,Confirmed]  http://launchpad.net/bugs/30602
[09:26] <carlos> hmm did you got the whole sentence? xchat cut it in my side...
[09:26] <danilos> carlos: (I did, try highlighting it in xchat, that usually turns it back up for me ;)
[09:26] <SteveA> "save 1 day or so of work"
[09:26] <SteveA> is the last text I got
[09:27] <carlos> It should start as 'SteveA: for TranslationReview, we will not save any time, just win code readability'
[09:27] <SteveA> yes
[09:27] <carlos> ok
[09:28] <SteveA> I suppose it will be a while before danilo starts on bug 30602
[09:28] <Ubugtu> Malone bug 30602 in rosetta "Timeout errors in +translate" [Critical,Confirmed]  http://launchpad.net/bugs/30602
[09:28] <SteveA> if danilo is working on OOo and firefox now
[09:28] <carlos> right
[09:28] <carlos> in fact, perhaps I will take care of that bug instead of danilo
[09:29] <SteveA> so, I'd say, do TranslationReview first, then look at the refactoring in preparation for bug 30602
[09:29] <carlos> depends on who's more busy
[09:29] <carlos> ok
[09:29] <carlos> SteveA: thanks for your time
[09:30] <SteveA> are you happy with that plan?
[09:30] <carlos> well, it would require to change some things from TranslationReview code, but it's not a big issue
[09:31] <SteveA> right
[09:31] <SteveA> you'd be trading that off against having completed the TranslationReview code earlier
[09:31] <SteveA> and also having more tests to check you're refactoring well
[09:31] <carlos> yeah, that's why I'm not complaining ;-)
[09:31] <SteveA> great
[09:32] <danilos> SteveA, carlos, I'm fine with that myself ;)
[09:32] <SteveA> I appreciate how you and danilo discussed it and then presented the issue clearly.
[09:33] <carlos> np
[09:35] <carlos> danilos: btw, what's the status for bugs #2181 and #3809 ?
[09:35] <Ubugtu> Malone bug 2181 in rosetta "Rosetta automated e-mail should come from @launchpad.net" [Medium,In progress]  http://launchpad.net/bugs/2181
[09:35] <Ubugtu> Malone bug 3809 in rosetta "Abuse of capital letters" [Medium,In progress]  http://launchpad.net/bugs/3809
[09:36] <danilos> carlos: well, I have some code sitting for them, but without tests (those were the ones I started early on)
[09:37] <carlos> danilos: ok, try to expend one hour or so every day to finish them so we don't block bug fixings with new features
=== carlos will try to do the same with his open branches
[09:37] <danilos> carlos: right, as we agreed earlier on
[09:38] <carlos> danilos: thanks
[09:39] <SteveA> mpt: ping?
=== seb128 [n=seb128@ubuntu/member/seb128]  has joined #launchpad
=== jelmer__ [n=jelmer@65.91.54.2]  has joined #launchpad
=== matthewrevell [n=matthew@82-37-192-62.cable.ubr05.wolv.blueyonder.co.uk]  has joined #launchpad
[10:18] <SteveA> mpt: ping
=== Spads [n=spacehob@82.211.81.249]  has joined #launchpad
=== danilos -> breakfast
[10:31] <SteveA> mpt: global.js in icing has 0 length.  is that right?
=== Nafallo [n=nafallo@ubuntu/member/nafallo]  has joined #launchpad
[10:55] <carlos> SteveA: https://launchpad.net/distros/ubuntu/+source/firefox/+bug/61366
[10:55] <Ubugtu> Malone bug 61366 in firefox "[Edgy]  Firefox crashes on sites with Flash if old profile directory is used" [Untriaged,Unconfirmed]  
[10:55] <carlos> SteveA: that bug has the flash plugin attached
[10:55] <carlos> what's our policy about it?
[10:56] <SteveA> what's the problem?  that the attachment is proprietory?
[10:58] <carlos> SteveA: yes
[10:58] <jamesh> I don't think you can distribute the flash plugin without a license, even though it is given away
[10:58] <carlos> jamesh: no, you cannot, I just read their website
[10:59] <jamesh> the library file content can be marked deleted, which will prevent it from being served (and should get garbage collected)
[10:59] <jamesh> I think stub needs to do that though
=== Seveas [n=seveas@ubuntu/member/seveas]  has joined #launchpad
=== lfittl [n=lfittl@194.50.115.210]  has joined #launchpad
[11:42] <SteveA> mpt: ping
[11:47] <stub> jamesh: Have you taken down demo.launchpad.net? elmo just got notified it was down.
[11:48] <jamesh> stub: I did a quick code update for something else I was testing -- it should be up now
[11:49] <stub> ok. Please give a heads up in #canonical-sysadmin - the guys have been told to treat it like other production servers.
[11:49] <stub> (next time)
[11:50] <jamesh> will do.
=== _thumper_ [n=tim@host86-141-71-114.range86-141.btcentralplus.com]  has joined #launchpad
[11:58] <carlos> stub: hi, did you see my comment about flash plugin being attached in a malone bug?
[11:58] <carlos> stub: jamesh said that you could mark it as deleted
[11:59] <carlos> stub: https://launchpad.net/distros/ubuntu/+source/firefox/+bug/61366
[11:59] <Ubugtu> Malone bug 61366 in firefox "[Edgy]  Firefox crashes on sites with Flash if old profile directory is used" [Untriaged,Unconfirmed]  
[12:00] <stub> carlos: You mean http://librarian.launchpad.net/4320107/flash_plugins.tar.gz ?
[12:00] <carlos> stub: yes
[12:04] <stub> Done
[12:06] <carlos> stub: thanks
=== stub [n=stub@ppp-58.8.15.82.revip2.asianet.co.th]  has joined #launchpad
[12:25] <SteveA> carlos: thanks for adding a comment explaining it to the bug.
[12:26] <carlos> np
=== xadf [n=alex@e178073134.adsl.alicedsl.de]  has joined #launchpad
[12:28] <xadf> hi
[12:29] <xadf> how is it that when i subscribe to bugs it is not shown on my profile page in launchpad?
[12:30] <Fujitsu> xadf, make sure you're viewing the `subscribed bugs', the default is `assigned bugs'.
[12:30] <mpt> xadf, by default your Bugs page shows only bugs assigned to you, not bugs you have subscribed to
[12:30] <mpt> snap
[12:30] <mpt> click "Subscribed" in the top left
[12:31] <mpt> SteveA, pong
[12:31] <xadf> mpt: of course, but right there thats what im talkign about
[12:32] <xadf> it doesnt show all the bugs im subscribed to
[12:32] <mpt> xadf, by default, it doesn't include bugs that are fixed or rejected
[12:32] <mpt> To include those, click "Advanced" and check those checkboxes
[12:32] <SteveA> hi mpt.  sent you email.
[12:33] <xadf> mpt: ah thanks
=== xadf [n=alex@e178073134.adsl.alicedsl.de]  has left #launchpad ["Ex-Chat"] 
[12:34] <mpt> SteveA, thanks. Should I land my latest changes into rocketfuel?
[12:34] <jamesh> xadf: it also won't show bugs you are subscribed to but have been marked duplicate (you can use the "Advanced search" link on that page to change this though)
[12:35] <SteveA> mpt: please do (on the appropriate branch in RF, of course).  I already updated the server, so you can take a look there.  Mark will meet usman on monday, so we should prepare a briefing for Mark for that meeting, rather than mail usman.
=== jsgotangco [n=jsg123@ubuntu/member/jsgotangco]  has joined #launchpad
[12:41] <doko_> could somebody enlighten me on https://launchpad.net/+builds/+build/247419 ? it's built, but the binaries don't show up
=== sabdfl [n=sabdfl@ubuntu/member/pdpc.silver.sabdfl]  has joined #launchpad
=== ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net]  has joined #launchpad
[01:14] <jamesh> doko_: maybe cprov can answer your question ...
[01:14] <doko_> jamesh: yeah, hopefully ...
[01:14] <cprov> doko_: jamesh: checking
[01:15] <cprov> doko_: binaries got rejected, need to check drescher log 
[01:16] <cprov> doko_: give me a minute, I will check it for you 
=== Seveas [n=seveas@ubuntu/member/seveas]  has joined #launchpad
[01:25] <cprov> doko_: malcc found it ...
[01:25] <cprov> doko_: 
[01:25] <cprov> 07:50:17 INFO    Rejected:
[01:25] <cprov> 07:50:17 INFO    openoffice.org-common_2.0.4~rc2-1ubuntu3_all.deb uses bzip2 compression but doesn't Pre-Depend on dpkg (>= 1.10.24)
[01:26] <doko_> that's not true ...
[01:26] <cprov> doko_: what kind of fancy stuff do you invoke for OO ? ;)
[01:26] <stub> Launchpad meeting 35 minutes
[01:26] <doko_> that means, that the -l10n build will fail as well :-/
[01:27] <doko_> cprov: there's no chance to save this build?
[01:28] <doko_> dpkg 1.10.24 is ooooold
=== LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net]  has joined #launchpad
[01:28] <cprov> doko_: well, infinity can reprocess it to you, but I think it's hopeless 
[01:29] <cprov> doko_: I mean, soyuz won't accepted if you try to re-upload 
[01:30] <cprov> doko_: I don't know what this problem means precisely, I just know we will detect again in the next run.
[01:30] <doko_> yes, I have to add this pre-dependency ...
[01:33] <doko_> cprov: where is this pre-dependency encoded?
[01:37] <cprov> doko_: dunno, sorry
=== salgado [n=salgado@200-171-140-32.dsl.telesp.net.br]  has joined #launchpad
=== matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br]  has joined #launchpad
[01:46] <jamesh> doko_: the error is about the binary package, so presumably wherever you define other dependencies for that package
[01:47] <doko_> jamesh: it's a packaging error, yes, but that's really the first place I know, where the infrastructure checks for packaging errors
[01:47] <doko_> so the question was: which part of the infrastructure
=== bradb [n=bradb@wnpgmb09dc1-71-199.dynamic.mts.net]  has joined #launchpad
[01:59] <SteveA> today's launchpad development meeting is with special guest chair salgado.
=== flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca]  has joined #launchpad
[02:00] <salgado> it's meeting time, guys!
[02:00] <salgado> who's here?
[02:00] <matsubara> me
[02:00] <flacoste> me
[02:00] <malcc> me
[02:00] <SteveA> me
[02:00] <spiv> me
[02:00] <cprov> me
[02:00] <bradb> me
[02:00] <jamesh> me
[02:00] <mpt> me
[02:00] <spiv> lifeless sends his apologies
[02:00] <salgado> cprov sends his apologies too
=== sidarus [n=chatzill@212.147.91.129]  has joined #launchpad
[02:00] <salgado> BjornT?
[02:00] <spiv> (he needs to be awake early tomorrow, so he's gone to bed.)
[02:00] <carlos> me
[02:00] <salgado> stub?
[02:00] <BjornT> me
[02:01] <stub> me
[02:01] <kiko-zzz> me
[02:01] <malcc> cprov sent apologies? But he's here...
[02:01] <cprov> salgado: oops, what ?
[02:01] <salgado> well, I thought cprov would be offline today.  anyway...
[02:01] <salgado> == Agenda ==
[02:01] <salgado>  * Roll call
[02:01] <salgado>  * Agenda
[02:01] <salgado>  * Next meeting
[02:01] <salgado>  * Activity reports
[02:01] <salgado>  * Actions from last meeting
[02:01] <salgado>  * Oops report (Matsubara)
[02:01] <salgado>  * Bug report report (mpt)
[02:01] <danilos> me
[02:01] <salgado>  * Production and staging (Stuart)
[02:01] <salgado>  * Launchpad 1.0 status reports
[02:01] <salgado>  * Sysadmin requests
[02:01] <salgado> ----
[02:01] <salgado>  * UI 1.0 discussions (Steve, mpt)
[02:01] <salgado>  * (other items)
[02:01] <salgado> ----
[02:02] <salgado>  * Keep, Bag, Change
[02:02] <salgado>  * Three sentences
[02:02] <salgado> next meeting. same time, next week?
[02:02] <salgado> any objections?
[02:02] <SteveA> +1
[02:02] <cprov> +1
=== ..[topic/#launchpad:salgado] : Developer meeting: Thu 28 Sep, 1200UTC (wiki:MeetingAgenda) | launchpad-users@lists.canonical.com (wiki:MailingLists) | Channel logs: http://tinyurl.com/72w39
[02:02] <kiko> none
[02:02] <salgado> activity reports.. who's up to date?
[02:02] <bradb> I have a dentist appt next week, fwiw
[02:02] <kiko> not me :-(
[02:02] <SteveA> out of date
[02:02] <cprov> up to date
[02:02] <danilos> not up to date, repeat offender :(
[02:02] <matsubara> up to date
[02:02] <bradb> up to date
[02:02] <flacoste> up to date
[02:02] <ddaa> here
[02:02] <salgado> up to date
[02:02] <BjornT> up to date
[02:02] <stub> up to date
[02:02] <ddaa> up to date
[02:02] <malcc> up to date
[02:02] <carlos> out of date
[02:03] <jamesh> not up to date :(
[02:03] <sidarus> Is that a launchpad meeting ?
[02:03] <SteveA> hi sidarus 
[02:03] <jordi> ugh
[02:03] <salgado> * Actions from last meeting
[02:03] <salgado> * SteveA to put up a wiki page for the launchpad project to note disaster scenarios on, and mail the list about it
[02:03] <salgado>  * SteveA to write up what needs doing to implement `__eq__`, `__ne__`, and `__hash__` for database objects
[02:03] <spiv> up to date
[02:03] <SteveA> This is the weekly launchpad development meeting
[02:03] <jordi> hello, and missing a report of two weeks ago
[02:03] <sidarus> SteveA: Hi
[02:03] <SteveA> salgado: I'm still on the hook for those two items.
[02:04] <SteveA> salgado: please leave them on the agenda for next week
[02:04] <salgado> okay
[02:04] <malcc> SteveA: Don't forget to incorporate disaster planning for the scenario where a disaster occurs before we've done the disaster planning :)
[02:04] <mpt> I'm up to date
[02:04] <SteveA> malcc: that would be disasterous
[02:04] <mpt> and plannerous
[02:04] <salgado> it's oops report time, then. go matsubara, go
[02:04] <matsubara> Today's oops report is about bugs 61548, 1558, 30602
[02:04] <Ubugtu> Malone bug 61548 in launchpad "Description/comment fields shouldn't crash with insanely large values." [Medium,Confirmed]  http://launchpad.net/bugs/61548
[02:05] <Ubugtu> Malone bug 1558 in rosetta "Export request form should check for uniqueness of entry" [Critical,Confirmed]  http://launchpad.net/bugs/1558
[02:05] <Ubugtu> Malone bug 30602 in rosetta "Timeout errors in +translate" [Critical,Confirmed]  http://launchpad.net/bugs/30602
[02:05] <matsubara> danilos, did you start work on bug 1558? I can take that one if you're too
[02:05] <matsubara> busy.
[02:05] <danilos> oh, two of them mine
[02:05] <danilos> matsubara: I didn't start on it, feel free to take it away
[02:05] <matsubara> Bug 61548 is about large values in comment/description fields. anyone volunteer to take that one?
[02:05] <danilos> matsubara: sorry for holding it back for so long :(
[02:05] <matsubara> danilos: okie.
[02:05] <matsubara> danilos, any progress on bug 30602? This is the top timeout bug.
[02:05] <carlos> matsubara: 30602 is blocked in a translation view restructuring and I think I will take care of that bug (not sure yet)
[02:06] <danilos> matsubara: we've had a lot of discussions on 30602, it's blocked atm
[02:06] <carlos> I will do the restructuring, so it's blocked on me
[02:06] <kiko> danilos, carlos: let's talk about this translation view restructuring after the meeting.
=== bradb_ [n=bradb@wnpgmb09dc1-71-199.dynamic.mts.net]  has joined #launchpad
[02:06] <bradb_> urgh, disconnected
[02:06] <SteveA> matsubara: I want to talk with you separately about 61548
[02:06] <carlos> kiko: SteveA and we already agreed to deferred it after TranslationReview
[02:06] <danilos> kiko: sure, though we already discussed it with SteveA
[02:06] <kiko> carlos, SteveA, danilos: I have an alternative suggestion.
[02:07] <kiko> but we can talk about it after the meeting.
[02:07] <danilos> kiko: fine by me
[02:07] <carlos> ok
[02:07] <salgado> is that all?
[02:07] <matsubara> salgado: yes, thank you. I'm done here
[02:07] <salgado> * Bug report report (mpt)
[02:07] <salgado> your turn, mpt
[02:08] <mpt> There are 10 open Critical bugs in Launchpad. The oldest ones are:
[02:08] <mpt>  * Bug #1558 (Export request form should check for uniqueness of entry), Critical, Confirmed, danilos
[02:08] <mpt>  * Bug #30602 (Timeout errors in +translate), Critical, Confirmed, danilos
[02:08] <Ubugtu> Malone bug 1558 in rosetta "Export request form should check for uniqueness of entry" [Critical,Confirmed]  http://launchpad.net/bugs/1558
[02:08] <Ubugtu> Malone bug 30602 in rosetta "Timeout errors in +translate" [Critical,Confirmed]  http://launchpad.net/bugs/30602
[02:08] <mpt> danilos, will you get to either of those two this week? they've been hanging around for a while
[02:08] <mpt>  * Bug #44214 (We need to add code to prevent POFiles being in the same path), Critical, Confirmed, carlos
[02:08] <mpt>  * Bug #46982 (Rosetta does not accept correct KDE plural forms when there are more than 2), Critical, Confirmed, carlos
[02:08] <kiko> (matsubara, is that the bug we were talking about yesterday?)
[02:08] <Ubugtu> Malone bug 44214 in rosetta "We need to add code to prevent POFiles being in the same path" [Critical,In progress]  http://launchpad.net/bugs/44214
[02:08] <Ubugtu> Malone bug 46982 in rosetta "Rosetta does not accept correct KDE plural forms when there are more than 2" [Critical,Confirmed]  http://launchpad.net/bugs/46982
[02:08] <mpt> carlos, tell us about those two
[02:08] <danilos> mpt: as mentioned previously, matsubara is taking on 1558
[02:09] <matsubara> kiko: yes, it is. validation on +export
[02:09] <kiko> cool.
[02:09] <mpt> ah yes, sorry I missed that bit
[02:09] <mpt>  * Bug #48860 ("Also notified" makes difficult to unsubscribe), Critical, In Progress, bradb
[02:09] <Ubugtu> Malone bug 48860 in malone ""Also notified" makes difficult to unsubscribe" [Critical,In progress]  http://launchpad.net/bugs/48860
[02:09] <carlos> #46982 is blocked on danilos finishing with Fireforx support (we need some infrastructure work added there)
[02:09] <danilos> mpt: as for 30602, low chances of it happening this week (blocked on some view restructuring by carlos)
[02:09] <mpt> bradbdo you have a plan for that yet?
[02:09] <mpt> ~bradb, do
[02:09] <kiko> bradb, I can talk about that one with you after the meeting if you like.
[02:09] <bradb_> kiko: sure
[02:09] <carlos> mpt: #44214 is my next bug fix
[02:09] <mpt> carlos, great
[02:10] <bradb_> mpt: nothing too specific yet
[02:10] <mpt>  * Bug #48948 (dapper indices files still being regenerated but shouldn't be), Critical, Confirmed, malcc
[02:10] <Ubugtu> Malone bug 48948 in soyuz "dapper indices files still being regenerated but shouldn't be" [Critical,Confirmed]  http://launchpad.net/bugs/48948
[02:10] <mpt>  * Bug #58187 (uploads to frozen should land in unapproved, not be rejected), Critical, Confirmed, malcc
[02:10] <mpt>  * Bug #59003 (New override generation code gives MemoryError on real data), Critical, Confirmed, malcc
[02:10] <Ubugtu> Malone bug 58187 in soyuz "uploads to frozen should land in unapproved, not be rejected" [Critical,Fix released]  http://launchpad.net/bugs/58187
[02:10] <Ubugtu> Malone bug 59003 in soyuz "New override generation code gives MemoryError on real data" [Critical,Fix committed]  http://launchpad.net/bugs/59003
[02:10] <mpt> malcc, tell us the good news
[02:10] <malcc> mpt: 58187 is fix released
[02:10] <mpt> wha
[02:10] <mpt> it was open five minutes ago
[02:10] <malcc> mpt: Just updated now
[02:10] <mpt> that is good news then :-P
[02:10] <malcc> mpt: 59003 is fix committed, also just done now; I'm not sure whether to list it as fix released, as the broken code was never actually deployed
[02:10] <malcc> mpt: Either way it's fixed
[02:11] <mpt> and finally
[02:11] <mpt>  * Bug #54241 (We need a script or tool that prunes OOPS logs from sodium), Critical, Confirmed, unassigned
[02:11] <Ubugtu> Malone bug 54241 in launchpad "We need a script or tool that prunes OOPS logs from sodium" [Critical,Confirmed]  http://launchpad.net/bugs/54241
[02:11] <mpt> Who should take that one? jamesh? stub?
[02:11] <malcc> mpt: The bad news, dropped the ball on 48948 this week, need to discuss it with elmo, didn't get to it
[02:11] <mpt> bradb, what's the plan of action for 48860?
[02:11] <stub> either - I can take it if james is full
[02:12] <bradb_> mpt: Like I say, nothing specific yet.
[02:12] <danilos> matsubara: should I reassign 1558 to you?
[02:12] <matsubara> danilos: yes please.
[02:12] <bradb_> mpt: will discuss with kiko after meeting
[02:12] <mpt> bradb, I meant the plan for coming up with something specific
[02:12] <mpt> ok.
[02:12] <jamesh> stub: okay.  I am not sure exactly what criteria we'd have for deciding if a report is referenced
[02:12] <danilos> matsubara: ok, thanks
[02:12] <mpt> There are also 8 Critical bugs marked as Fix Committed. Please remember to verify your fixes after the rollout.
[02:12] <mpt> That's all salgado, thanks
[02:12] <salgado> thanks mpt
[02:12] <salgado> * Production and staging (Stuart)
[02:13] <salgado> stub?
[02:13] <stub> jamesh: Trawling the bug messages looking for Bug\s*\d+
[02:13] <stub> Production systems are scheduled to be updated next Tuesday. I'll be rolling out HEAD as of now unless I hear otherwise.
[02:13] <stub> There have been surprising few cherry pick requests in the last couple of weeks, which is great.
[02:13] <stub> Steve noticed our first day without exceptions on production happened yesterday. Hopefully this was not just a glitch in the OOPS system ;)
[02:13] <stub> Staging is currently running Brad's branch for testing.
[02:13] <ddaa> stub: it would be nice not to have such long delays again, or lower the threshold for cherrypicks
[02:14] <kiko> stub, I had a fix for CVE timeouts that is in final review (nudge BjornT) so if it could make it, it'd be nice.
[02:14] <mpt> How can I make cosmetic fixes to bradb's branch, if it's not HEAD?
[02:14] <malcc> stub: drescher is likely to be ready to be included in the next rollout, we've fixed up rocketfuel-head and re-tested it.
[02:14] <kiko> mpt, branch off it.
[02:14] <malcc> stub: Just one more issue to check up on, which is likely nothing; I'll send you an email if the situation changes
[02:14] <ddaa> it's annoying to have to tell some user "this bug is fixed, but you have to wait three weeks before you can use it"
[02:14] <ddaa> that, or do edge.launcphad.net soon
[02:14] <kiko> ddaa, request a cherrypick.
[02:14] <stub> mpt: Create a branch containing brads work and your own and get me or steve to push it to staging
[02:15] <mpt> ok, thanks
[02:15] <SteveA> ddaa: one purpose for this section of the meetings is for you to raise an issue like "I'd like xxx cherrypicked because of yyy"
[02:15] <ddaa> kiko: it was not blocker bug, in that nothing really depended on being able to do that (set the branch of a series), and it involved a watershed db patch. So it was not eligible for cherrypick imo
[02:15] <stub> ddaa: The threshold gets lowered if the rollouts are infrequent
[02:15] <SteveA> and get some approval as that being important
[02:15] <kiko> ddaa, well, db patches are indeed a problem..
[02:15] <stub> ddaa: But edge.launchpad.net should address this too if it works as we hope
[02:16] <SteveA> ddaa: either bring it up here, request it from stu, or decide it isn't a problem
[02:16] <kiko> stub, not if it includes a db patch, AIUI
[02:16] <SteveA> ddaa: but, don't decide it shouldn't be picked, and then complain about it later.
[02:16] <stub> kiko: correct.
[02:16] <ddaa> SteveA: okay
=== niemeyer [n=niemeyer@201.10.93.152]  has joined #launchpad
[02:16] <salgado> is that all?
[02:17] <salgado> okay, moving on...
[02:17] <salgado> * Launchpad 1.0 status reports
[02:17] <salgado> Question Tracker 1.0
[02:17] <salgado> ---------------------------------
[02:17] <salgado> - SupportTrackerWorklow: Started. Workflow API is completed. Karma integration completed, UI is in progress, email integration and expiration cronscript are pending.
[02:17] <salgado> - SupportTrackerViews: Waiting completion of SupportTrackerWorkflow.
[02:17] <salgado> - SupportTrackerHelp: Waiting completion of SupportTrackerWorkflow.
[02:17] <salgado> - LocalizedSupportRequests: Not yet started
[02:17] <salgado> Random Things 1.0
[02:17] <salgado> -------------------------------
[02:17] <salgado> - PersonCreationRationale is up for review, including a script to guess the creation rationale of existing profiles.
[02:17] <salgado> - DirectPersonRegistration has a tricky issue blocking its implementation, so it needs discussion.
[02:17] <cprov> = Soyuz-1.0 Report =
[02:17] <cprov>  * PPA: blocked on ArchiveRework (still).
[02:17] <cprov>  * Archive Rework: some progress, malcc.
[02:17] <cprov>  * Code quality: following standards for scripts/ftpmaster/queue
[02:17] <cprov>    and setup dedicated ftest (motivated by fix 59291 & 59280, r=spiv).
[02:17] <cprov>    Big win merging the post-sprint fixes/rearrangements in RF.
[02:17] <cprov>  * SoyuzTestSystem: very nearly complete, RF 4079, last run produced
[02:17] <cprov>    small diffs compared to the current codeline (Original-Maintainer
[02:17] <cprov>    and X-Original-Maintainer, also i386 chroot issues)
[02:17] <cprov>  * General Fixing: good progress, queue tool, Soyuz infrastructure,
[02:18] <cprov>    end-to-end publishing cycle fixes
[02:18] <cprov>    * Fix committed: 58144 and 58187 (RF 4066, RF 4063, partially rolled out),
[02:18] <cprov>      60280, 59186, 59147, 59003 (RF 4079)
[02:18] <cprov>    * In Review : 31392, 60440, 59291, 59280
[02:18] <danilos> Rosetta 1.0 weekly report:
[02:18] <danilos> - opening edgy for translation: DONE (some weeks ago)!
[02:18] <danilos> - firefox import/export: import working, export blocked on TranslationImport finish
[02:18] <danilos> - oo import/export: blocked on firefox (TranslationImport stuff)
[02:18] <danilos> - translation review: UI part mostly done, code support restarted after delaying translation view restructuring
[02:18] <danilos> - essential docs: no progress (danilos: RosettaHighlights, needs comments from jordi)
[02:18] <danilos> - search: not started, pre-draft stage
[02:18] <danilos> - checks not to upload wrong language PO file using "too many changes" check: not started
[02:18] <danilos> - ui fixes: not started
[02:18] <danilos> - outstanding issues: none
[02:18] <ddaa> importd-bzr-native: massive code removal done. todo: final cleanups to remove deps on pybaz and gnarly, database patch
[02:18] <ddaa> supermirror-smart-server: spiv reports very good progress, code is being merged to bzr.dev
[02:18] <ddaa> bzr-roundtrip-svn (postponed): mpool is back, waiting for his feedback on the discussion that happened in the past weeks.
[02:18] <bradb> Malone 1.0
[02:18] <bradb> ==========
[02:18] <bradb> series-and-distrorelease-mgmt: Spec'd ConjoinedBugTasks. Reverted in rf. Sandboxing on staging. Firefighting continues.
[02:18] <bradb> keeping-bugs-concise: No news.
[02:18] <bradb> guided-filebug-form: No news.
[02:18] <bradb> malone-essential-docs: No news.
[02:18] <bradb> simple-bug-keywords: No news.
[02:19] <salgado> do we have one for infrastructure? SteveA?
[02:20] <SteveA> I don't have a report for infrastructure
[02:20] <salgado> I guess not
[02:20] <salgado> okay
[02:20] <salgado> * Sysadmin requests
[02:20] <jordi> danilos: hmm, when are we supossed to comment that?
[02:20] <danilos> jordi: well, as soon as I start pushing you ;)
[02:20] <salgado> any pending requests?
=== salgado counts from 5 to 1 without flooding the channel
[02:21] <danilos> jordi: which means when I get more time: we need to discuss and document things like team organization, most important features, etc.
[02:21] <kiko> I filed a bunch of rt requests
[02:21] <kiko> but mostly on behalf of others
[02:21] <jordi> danilos: ok
[02:21] <kiko> so please speak up if you recall a pending RT request I requested for you
[02:21] <salgado> kiko, are they urgent? do you have the #?
[02:21] <danilos> jordi: you can take a look at help.launchpad.net/RosettaHighlights already
[02:22] <kiko> salgado, lookin
[02:22] <kiko> salgado, all done it seems
[02:23] <salgado> cool. next item is...
[02:23] <salgado> * UI 1.0 discussions (Steve, mpt)
[02:23] <SteveA> so, mpt is working on the UI 1.0 stuff
[02:23] <kiko> spiv, I didn't see an answer to matsubara's question about moin.
[02:23] <SteveA> and I'm helping a bit
[02:23] <SteveA> there are aspects of the 1.0 UI that will need to be implemented by people who know about those specific applications
[02:24] <spiv> kiko: I haven't taken a look at what's wrong yet
[02:24] <SteveA> mpt and I will be arranging meetings between mpt and maybe me and launchpad devs who work on applications, over teh next week or two
[02:24] <kiko> spiv, well, please do, this is a pretty old bug..
[02:24] <SteveA> to work out the plan of what pages need work, what portlets need work and if there's anything else to do
[02:24] <SteveA> I don't think it will be a big deal
[02:25] <SteveA> but we need to get this planned, so we know how much there is to do
[02:25] <SteveA> I think that's all.  Any comment mpt?
[02:25] <mpt> Not that I can think of
[02:25] <SteveA> ok, that's it then
[02:26] <SteveA> thanks salgado 
[02:26] <salgado> any other items?
[02:26] <salgado> thanks SteveA!
[02:26] <danilos> thanks SteveA, mpt, looking forward to the mentioned meetings
[02:26] <salgado> guess not
[02:26] <salgado> * Keep, Bag, Change
[02:26] <salgado> Change: No need to include bugs with the "oops" tag in the Bug report report, as they've been mentioned on the Oops report already
[02:27] <mpt> salgado, sorry, I normally exclude them but I wasn't quick enough this morning.
[02:27] <matsubara> we can try to coordinate before the meeting mpt
[02:27] <danilos> keep: meetings around 30 mins ;)
[02:27] <matsubara> what do you say?
[02:27] <salgado> mpt, no worries. I didn't know you were excluding them. thanks
[02:29] <mpt> matsubara, that would be great, just /msg me the bug numbers beforehand
[02:29] <matsubara> mpt: okie
[02:29] <salgado> okay, I guess that's all
[02:29] <ddaa> three sentences?
[02:29] <salgado> * Three sentences
[02:29] <salgado> DONE: Wrote the script to guess the creation rationale of existing profiles, code review, fixed some shipit regressions, code review and other random things
[02:29] <ddaa> DONE: more delete-gnuarch, talking with oscss people, import stuff
[02:29] <ddaa> TODO: finish delete-gnuarch, spec to redesign +source, test and land BatchProgress
[02:29] <ddaa> BLOCKED: no
[02:29] <salgado> TODO: Get person-creation-rationale through review, fix the remaining things on mirror-management in order to make the final announcement, more code review and random things.
[02:29] <salgado> BLOCKED: No
[02:29] <cprov> DONE: bug fixing, code rearrangements guided by spiv,
[02:29] <cprov>       SoyuzTestSystem helping and NoMoreAptFtparchive drafting.
[02:29] <cprov> TODO: more bug fixing, soyuz rollout and ArchiveRework
[02:29] <cprov> BLOCKED: no
[02:29] <stub> TODO: edge.launchpad.net
[02:29] <stub> DONE: sick, public holiday, bug fixes, DBA stuff
[02:29] <stub> BLOCKED: No
[02:29] <danilos> DONE: firefox import, TranslationImport drafting, bug management, discussions
[02:29] <carlos> DONE: Approved a bunch of new .pot files for Edgy, bug #42760 fixed and merged, debugged and filed bug #61096 and #61107, Rosetta copyright doc, Dapper language packs hole debugging and figure a plan to fix it, bunch of meetings about several new features
[02:29] <carlos> TODO: bug #44214, TranslationReview, translation view restructuring
[02:29] <carlos> BLOCKED: No
[02:29] <danilos> TODO: bug 30602, bug 1558, TranslationImport (in progress), bug fixing, rosetta search
[02:29] <danilos> BLOCKED: no
[02:29] <Ubugtu> Malone bug 42760 in rosetta "Exception NameNotAvailable raised while trying to create a new msgset from submitted translation." [Critical,Fix committed]  http://launchpad.net/bugs/42760
[02:29] <BjornT> DONE: code reviews. fix bug tag validation bugs. some work on upstream forwarding workflow.
[02:29] <Ubugtu> Malone bug 61096 in rosetta "Rosetta should allow '\r' and '\r\n' in the same msgid/translation" [Medium,Confirmed]  http://launchpad.net/bugs/61096
[02:29] <Ubugtu> Malone bug 61107 in kdelibs "Some stock strings are not extracted to be translated" [Untriaged,Fix released]  http://launchpad.net/bugs/61107
[02:29] <mpt> DONE: Righteous Rosetta bug fixes, CSS and template work
[02:29] <mpt> TODO: Move house tomorrow, then back to CSS and templates
[02:29] <mpt> BLOCKED: no
[02:29] <BjornT> TODO: code reviews. more work on upstream forwarding workflow.
[02:29] <Ubugtu> Malone bug 44214 in rosetta "We need to add code to prevent POFiles being in the same path" [Critical,In progress]  http://launchpad.net/bugs/44214
[02:29] <bradb> DONE: Release management firefighting. Loads of bug triage.
[02:29] <bradb> TODO: ConjoinedBugTasks.
[02:29] <bradb> BLOCKED: No.
[02:29] <Ubugtu> Malone bug 30602 in rosetta "Timeout errors in +translate" [Critical,Confirmed]  http://launchpad.net/bugs/30602
[02:29] <BjornT> BLOCKED: no
[02:29] <Ubugtu> Malone bug 1558 in rosetta "Export request form should check for uniqueness of entry" [Critical,Confirmed]  http://launchpad.net/bugs/1558
[02:29] <flacoste> DONE: updated karma actions for new support tracker workflow, tunings of the support-tracker workflow spec, refactored some support tracker UI to make room for new workflow UI
[02:29] <matsubara> DONE: paperwork for US visa, fixed #48851, bug triage, oops report analysis
[02:29] <flacoste> TODO: support tracker workflow UI, update support-tracker email interface, expiration script 
[02:29] <matsubara> TODO: oops report analysis, bug triage, add some test for my quick fix of #61428
[02:29] <matsubara> BLOCKED: no
[02:30] <flacoste> BLOCKED: no
[02:30] <jamesh> DONE: code reviews, finish off Product.development_focus branch, product-release-finder stuff, bug export code, URI handling utilities
[02:30] <jamesh> TODO: code reviews, branch puller logging changes, importd default interval changes
[02:30] <jamesh> BLOCKED: no
[02:30] <SteveA> DONE: ui work, management
[02:30] <SteveA> TODO: ui work, management
[02:30] <SteveA> BLOCKED: no
[02:30] <kiko> DONE: various patches and fixes to random bits of LP. /32 phone calls. some management and review
[02:30] <spiv> DONE: reviews, basic bzr smart server merged to bzr.dev, bzr+ssh:// urls, started smart server over HTTP.
[02:30] <malcc> DONE: Finished testing soyuz, landed some branches
[02:30] <malcc> TODO: Deploy Soyuz, ArchiveRework
[02:30] <malcc> BLOCKED: No
[02:30] <spiv> TODO: reviews, finish smart server over HTTP, bzr smart server/supermirror integration.
[02:30] <kiko> TODO: deal with the next set of crisis on my hands
[02:30] <spiv> BLOCKED: no
[02:30] <kiko> BLOCKED: no
[02:31] <danilos> mpt: uhm, remove 1558 from my TODO
[02:31] <SteveA> I see no blockers
[02:31] <jordi> DONE: queue, email
[02:31] <jordi> TODO: KDE email
[02:31] <jordi> BLOCKED: no
[02:31] <salgado> nobody seem to be blocked, indeed
[02:31] <matsubara> mpt: and add it to mine :)
[02:31] <SteveA> excellent!
[02:31] <salgado> I guess we're done, then
[02:31] <mpt> Record time!
[02:32] <salgado> thanks a lot, everybody!
[02:32] <ddaa> jamesh: can you have a look at bug 4557, please?
[02:32] <Ubugtu> Malone bug 4557 in launchpad "launchpad doesn't ask for release date when adding a new product release" [Medium,Confirmed]  http://launchpad.net/bugs/4557
[02:32] <SteveA> Thanks for running the meeting smoothly salgado.
[02:32] <danilos> salgado: thanks ;)
[02:32] <mpt> KEEP: salgado as chair ;-)
[02:32] <malcc> mpt +1
[02:32] <jordi> SALGADO!
[02:32] <salgado> yay!
[02:32] <danilos> mpt: you want to sit on him? :P
[02:32] <salgado> no, please. not that
[02:32] <jamesh> ddaa: sure.  The product-release-finder code doesn't set release dates either, btw
=== SteveA -> lunch
[02:32] <carlos> kiko, danilos: Do you think the meeting will be long? Is lunch time here
[02:33] <jamesh> not sure what the best way to handle that is
[02:33] <danilos> carlos: well, I'd rather delay it for after lunch
[02:33] <kiko> carlos, danilos: no, but let's do it now
[02:33] <carlos> so we can either have right now, or after lunch
[02:33] <ddaa> jamesh: I'm mostly concerned about db pollution: setting incorrect dates to automatically releases
[02:33] <kiko> SteveA, can I have you for 2 minutes?
[02:33] <danilos> kiko, carlos, well, then sure
[02:33] <kiko> danilos, carlos, SteveA: #canonical-meeting
[02:33] <jordi> kiko, should I be there too?
[02:33] <kiko> jordi, if you like -- it's about internals though
[02:33] <ddaa> jamesh: if the current code can cope with NULL dates, just make sure that PRF uses the full power of NULL and please comment on the bug.
[02:34] <jordi> can lurk
[02:35] <ddaa> jamesh: the issues is that +addrelease uses NOW as the release date, which is generally wrong.
[02:35] <SteveA> kiko: yes, in about 5 mins time
[02:35] <kiko> SteveA, now or never..
[02:36] <ddaa> Python import up to 22630 commits
[02:36] <ddaa> and growing
[02:36] <jamesh> ddaa: the database currently has that field set as not null, and seems to treat it as a creation date for the record and for ordering purposes
[02:37] <jamesh> ddaa: would be good to keep it "NOT NULL" if possible, but allow editing the release date
[02:37] <ddaa> jamesh: the issue then is that we cannot distinguish between "automatically set date, when this release object was created" and "date this release was actually made".
[02:38] <jamesh> SteveA: btw, the admins were doing some changes to how the OOPS reports were copied to devpad.canonical.com, which might have been the reason for the "0 Exceptions" count
[02:38] <ddaa> https://launchpad.net/products/bzr says "0.9" Date Release: 2006-09-20
[02:38] <jamesh> yeah
=== Burgwork [n=corey@ubuntu/member/burgundavia]  has joined #launchpad
[02:38] <spiv> ddaa: sweet.  Importing from the repository tarball?
[02:39] <ddaa> spiv: yup, thanks for the hint
[02:39] <spiv> ddaa: fwiw, HEAD is 51948
[02:39] <jamesh> I wonder if looking at the modification dates on the files inside the tarball would be a good way to pick release dates in product-release-finder?
[02:40] <ddaa> jamesh: in my experience upstream does not always have a usefully set system clock
[02:41] <jamesh> kiko: sorry about missing your "bug 60574" patch.  You didn't use my current email address, so my email client didn't highlight it as being addressed to me
[02:41] <Ubugtu> Malone bug 60574 in malone "Comments/Audit trail does not show multiple attachments" [High,Fix committed]  http://launchpad.net/bugs/60574
=== carlos -> lunch
[02:41] <kiko> jamesh, yeah, sorry about that. should I update my mutt_aliases?
[02:41] <jamesh> ddaa: it's better than "now"
[02:41] <jamesh> kiko: yeah.  james@jamesh.id.au is what I've been using for > 2 years now ...
[02:42] <kiko> jamesh, my mutt_aliases file is VERY OLD
[02:42] <kiko> jamesh, I hear there's another james that works at DAA?
[02:42] <ddaa> jamesh: I think it's worth making a distinction between "date_created" and "date_released"
[02:42] <jamesh> kiko: yeah.  They got a replacement James
[02:42] <SteveA> jamesh: hmm, good point.  I guess that needs some looking into
[02:42] <kiko> jamesh, and his email address is something like jamesw@daa? also interested in free software?
[02:43] <kiko> jamesh, it freaked me out when I saw him on $randommailinglist
=== bradb & # shower, bbiab
=== SteveA ->  lunchtime
[02:43] <jamesh> SteveA: the load on devpad has gone right down now, which is good.
[02:43] <jamesh> kiko: he is jamesa@daa.com.au
[02:43] <kiko> yeah
[02:43] <kiko> terrible
[02:43] <kiko> SteveA, GRRRR
[02:43] <jamesh> kiko: he is even doing some Gnome stuff ...
[02:43] <kiko> a real stalker
[02:44] <ddaa> cheap imitation!
[02:44] <jamesh> I wonder if there is some web page directing people to ask for Ubuntu CDs on the launchpad-users list ...
[02:45] <Fujitsu> jamesh, it looks like it.
[02:45] <kiko> jamesh, you mean, one apart from launchpad itself? :)
[02:45] <Fujitsu> jamesh, I've never seen an email requesting them on any other Ubuntu list.
[02:45] <jamesh> kiko: where does it say that??
[02:45] <doko_> carlos: are the language files from openoffice.org 2.0.4~rc2-1ubuntu3 currently be imported into rosetta?
[02:46] <kiko> jamesh, well, it doesn't say that exactly, but it does tell people to subscribe to the list. I get a lot of email to launchpad-users-owner, btw.
=== LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net]  has joined #launchpad
[02:46] <carlos> doko_: not yet, still handling Dapper's one
=== seb128 [n=seb128@ubuntu/member/seb128]  has joined #launchpad
[02:47] <carlos> doko_: why?
[02:47] <doko_> carlos: I just want to know, if these are scheduled. the reason is, that the binaries are rejected, but I don't know about the language data
[02:47] <carlos> oh, let me check it for sure
[02:47] <carlos> I assumed you uploaded them 
=== seb128 [n=seb128@ubuntu/member/seb128]  has joined #launchpad
[02:47] <carlos> I'm not sure whether they are imported in that case...
[02:48] <kiko> BjornT, yo :)
[02:49] <carlos> doko_: seems like we didn't get them
[02:49] <BjornT> hi kiko 
[02:49] <kiko> BjornT, how's the summer?
[02:49] <carlos> cprov: could you confirm it?
[02:49] <carlos> malcc: ^^^
[02:49] <doko_> carlos: ok, so I have to keep the language file export enabled
[02:50] <carlos> doko_: you mean to upload it fixed?
[02:50] <BjornT> kiko: well, i would say it's gone :)
[02:50] <doko_> yes
[02:50] <cprov> doko_: lang-pack should be rejected too
[02:50] <doko_> ok
=== carlos -> lunch (this time is true...)
[02:53] <salgado> cprov, have a minute for a quick question?
[02:53] <cprov> salgado: sure
[02:55] <salgado> cprov, NacentUpload.parse_address() can create person entries... would it be possible to know the package to which the changelog being parsed belongs to at the time we create the person entries?
[02:57] <cprov> salgado: yes, it is, NU is pretty nasty, but its possible
[02:57] <salgado> cprov, cool. how can I do that?
[02:57] <cprov> salgado: let me check the code
=== j-a-meinel [n=j-a-mein@adsl-64-108-200-37.dsl.chcgil.ameritech.net]  has joined #launchpad
=== matthewrevell [n=matthew@82-37-192-62.cable.ubr05.wolv.blueyonder.co.uk]  has joined #launchpad
[03:00] <cprov> salgado: self.changes['source']   contains the source name, version & distribution are availble in the same way 
[03:01] <salgado> cprov, great! thanks a lot, dude
[03:01] <cprov> salgado: glad to help
[03:01] <kiko> salgado, heh. you won't be thanking him much longer..
[03:02] <salgado> hmmm. why's that?
[03:02] <kiko> because nascentupload.py EATS BABIES FOR BREAKFAST
[03:04] <cprov> kiko: It's my fault as much is yours ;) that code really needs urgent attention ... maybe during PPA. No changes in there would pass review procedure at this time
[03:04] <kiko> even looking at that file is known to cause cancer in lab rats
[03:12] <doko_> kiko: why does the archive has to enforce a dpkg version for bzip2 compress binaries, when this dpkg version is in all supported releases?
[03:13] <kiko> doko_, I'm not sure. kamion seemed to think the rejection was valid, though
[03:13] <kiko> bradb, I'm wondering why there is still code for nominations in browser/bugtask.py...
[03:13] <malcc> doko_: Yes, we're neutral on that. If the distro team agree they don't want it, get a bug filed and we'll take it out, or make it a matter of policy and switch it off for ubuntu
[03:15] <doko_> malcc: which component/product?
[03:15] <malcc> doko_: soyuz, we're now using that for everything
[03:16] <Ubugtu> New bug: #61654 in soyuz "overridable rejects would be nice" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61654
[03:20] <kiko> BjornT, is it r=bjornt with that? :)
[03:26] <BjornT> kiko: yeah
[03:26] <kiko> BjornT, I'm a bit suffering with the placement of render_bugtask_status. :-(
[03:26] <kiko> BjornT, let me explain why:
[03:26] <LarstiQ> gosh, is lp timing out on me
[03:27] <kiko> LarstiQ, what page, and what oops?
[03:27] <kiko> kiko@beetle:~/devel/launchpad-randomfixage-20060919/lib/canonical$ grep -rl render_bugtask_status * | grep -v pyc
[03:27] <kiko> launchpad/browser/bugtask.py
[03:27] <kiko> launchpad/browser/cvereport.py
[03:27] <kiko> launchpad/doc/bugtask.txt
[03:27] <kiko> launchpad/doc/displaying-bugs-and-tasks.txt
[03:27] <kiko> BjornT, I don't feel entirely comfortable importing from cvereport.py into bugtask.txt and displaying-bugs-and-tasks.txt
[03:28] <LarstiQ> kiko: multiple, one of them: https://launchpad.net/products/bzr/+calendar/2006-09-18, OOPS-264B461
[03:28] <Ubugtu> https://devpad.canonical.com/~jamesh/oops.cgi/264B461
[03:28] <LarstiQ> kiko: https://launchpad.net/people/larstiq/+calendar is also fun, with a lot of repeated calendars in the subscription list
[03:29] <kiko> LarstiQ, do you actually use the +calendar feature?!
[03:29] <kiko> LarstiQ, and all your timeouts are related to calendar, right?
[03:31] <BjornT> kiko: how is it used in browser/bugtask.py? i thought it was used only in cvereport (and tests)
[03:31] <LarstiQ> kiko: of course
=== bradb returns
[03:32] <kiko> BjornT, it's not used in bugtask.py -- but in bugtask.txt.
[03:32] <kiko> bradb! see above
[03:32] <bradb> kiko: looking now...
[03:32] <kiko> BjornT, it's looking like the best thing to do is to make this into a view.
[03:33] <kiko> BjornT, in the tests I'll do a helper to getView(bugtask, "+status-html").. what do you think?
[03:33] <LarstiQ> kiko: shall I file a bug on the repetition of calendars, or is it hopeless?
[03:33] <bradb> kiko: which code?
[03:33] <BjornT> kiko: if the tests in bugtask.txt are useful, then they probably should be moved to displaying-bugs-and-tasks.txt
[03:33] <kiko> LarstiQ, it's filed, but I should warn you, the calendar is being disabled next tuesday. that you use it actively is a concern to me now!
[03:34] <LarstiQ> well, I wouldn't call it 'actively'. But yes, freeze dats and such are in the bzr calendar.
[03:34] <kiko> BjornT, okay for that part.
[03:34] <kiko> LarstiQ, hmmm. hmmm.
[03:35] <salgado> maybe we should send an announcement to launchpad-users?
[03:35] <salgado> (explaining that the calendar will be disabled)
[03:35] <kiko> that bothers me
[03:35] <kiko> SteveA?
[03:35] <BjornT> kiko: not sure you need a helper. just create a view on test_bugtask. then, instead of calling test_bugtask.statusdisplayhtml, call the view.
=== ajmitch [n=ajmitch@ubuntu/member/ajmitch]  has joined #launchpad
[03:36] <kiko> BjornT, and render(), right?
[03:37] <BjornT> kiko: well, either call the view itself, or call view.render() directly. __call__ will basically do initialize() and render()
[03:37] <kiko> I did not know that. thanks!
[03:38] <bradb> kiko: Which code do you see from release management?
[03:38] <kiko> bradb, maybe I was on crack.. it was the code in BugTaskBackportView but now I see what happened
[03:38] <kiko> neermind
[03:39] <bradb> ok
=== danilos -> lunch
[03:46] <kiko> BjornT, do you have a suggestion for the view url?
[03:47] <ddaa> There's some insane cruft in the db
[03:49] <BjornT> kiko: not really. maybe +cve-report-status?
[03:50] <kiko> BjornT, you and I have the same problem. :) tell me, what was statuselsewhere and displaystatushtml meant to be used for? bradb?
[03:50] <bradb> kiko: the list view
[03:51] <ddaa> archconfig, archconfigentry, branchmessage, branchrelationship, bug*infestation, *label, product*module, and that's only what I figure out to be unused tables.
[03:51] <kiko> bradb, ah! this is why it's now unused!
[03:51] <bradb> :P
[03:52] <ddaa> I figure out that a few of them relate to hct, a few relate to some alternate schema for vcs imports that was never used, some relate to the mytical infestations, and some relate to a mysterious "label" scheme...
[03:53] <ddaa> bradb: care about removing the infestation tables?
[03:53] <ddaa> kiko: any clue what the "label" thing is about?
[03:53] <bradb> ddaa: i think they could be removed
[03:54] <kiko> ddaa, nope. :-(
[03:54] <ddaa> And I have no reply so far to my request about the future of hct...
[03:55] <ddaa> bradb: can you do a little patch for that, I'd rather have everybody clean up in front of his own door.
=== jsgotangco [n=jsg123@ubuntu/member/jsgotangco]  has joined #launchpad
[03:56] <ddaa> I hope that reviewers will prevent the introduction of more YAGNI tables
[03:56] <bradb> ddaa: I will have to confirm with other people first, but sure.
[03:57] <ddaa> the db schema is hard enough without having a dozen of mystery tables
[04:03] <LarstiQ> kiko: is the removal of calendar documented anywhere?
[04:03] <kiko> LarstiQ, no, and that's an oversight and error on our part. 
[04:03] <kiko> LarstiQ, the current plan was disabling it and offering an ICS download of the data
[04:04] <kiko> LarstiQ, if you think that's crack I can get us to reconsider
=== LarstiQ looks up ICS
[04:05] <LarstiQ> hmm
[04:05] <LarstiQ> kiko: I don't really use any other calendar
[04:05] <LarstiQ> kiko: other than that, will launchpad have an interface for adding events, or is that all offloaded?
[04:06] <kiko> LarstiQ, it will be disabled, mainly because that portion of the site needs work and we don't have anybody to work on it before 1.0 :-(
=== LarstiQ understands
[04:08] <kiko> it's really not the quality it needs to be
=== LarstiQ nods
[04:08] <LarstiQ> It does have its use, but I'm not sure how much it will be missed.
=== LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net]  has joined #launchpad
[04:22] <kiko> BjornT, I chickened out and XXXd it. :-(
=== Burgwork [n=corey@ubuntu/member/burgundavia]  has joined #launchpad
[04:35] <j-a-meinel> LarstiQ, kiko: I don't think bzr will miss it. It was nice to have a way to document the upcoming release calendar, but we can do it elsewhere.
[04:35] <j-a-meinel> I can confirm that it had a lot of bugs, though.
[04:35] <kiko> too many
[04:35] <LarstiQ> oh yes, quite.
=== lbm [n=lbm@82.192.173.92]  has joined #launchpad
[04:54] <SteveA> kiko: pong
[04:55] <kiko> SteveA, see email
[04:56] <SteveA> kiko: urgent, or can I get to it in the next 2 hrs?
[04:56] <kiko> SteveA, in the next 2h is fine.
[04:56] <SteveA> ta
[04:57] <jamesh> SteveA/kiko: from what Nick wrote on the RT ticket, the OOPS rsync cron job will only do a full sync of the entire OOPS tree once a day now, and the 5 minute rsyncs will only synchronise the last 2 days of OOPS reports
[04:57] <jamesh> so devpad is sitting with a load average of 0 now, rather than 3 or 4
=== fabbione [n=fabbione@port49.ds1-van.adsl.cybercity.dk]  has joined #launchpad
[04:58] <jamesh> we'll probably see new OOPS reports available in a more timely manner too
[04:58] <kiko> cool
[04:59] <jamesh> this leaves more of the IO bandwidth for things like pushing/pulling your branches :)
[05:01] <SteveA> kiko: no email from you.  is it the email from colin?
[05:02] <kiko> SteveA, no. it's the email about the calendar.
[05:02] <kiko> Sep 21 11:37:16 anthem sm-mta[27739] : k8LEasgx027725: to=<mpt@canonical.com>,<steve@z3u.com>,<launc
[05:02] <kiko> hpad@lists.canonical.com>, ctladdr=<kiko@anthem.async.com.br> (5107/1004), delay=00:00:22, xdelay=0
[05:02] <kiko> 0:00:22, mailer=relay, pri=181011, relay=frodo.hserus.net. [204.74.68.40] , dsn=2.0.0, stat=Sent (OK
[05:02] <kiko>  id=1GQPfr-000NMo-6Q)
[05:02] <kiko> SteveA, should I not use z3u?
[05:02] <SteveA> that will reach me
[05:02] <SteveA> what is the subject line?
[05:02] <kiko> jesus
[05:03] <kiko>   F 6673 Sep 21 To Matthew Thomas   ( 0.4K) Removing calendar announcement on l-u                 
[05:03] <kiko> SteveA, recurring email problems? is this email bonker week or what?
[05:03] <SteveA> what recurring email problems?
[05:03] <SteveA> my email's been fine
[05:04] <kiko> why did you not receive this one then?
[05:04] <SteveA> I'm looking at the mta logs
[05:04] <SteveA> but, one is not recurring
[05:04] <kiko> I have had email trouble all this week
[05:04] <kiko> so for me it is
[05:04] <kiko> at any rate it's hard to say whether you got my email and just ignored it or otherwise :-P
[05:04] <SteveA> the z3u mta didn't receive the email
[05:04] <SteveA> no record of that id
[05:04] <kiko> hmmm
[05:05] <jamesh> kiko: I got that email
[05:05] <kiko> so did everybody else on launchpad
[05:05] <SteveA> oh, here it is
[05:05] <SteveA> weird
[05:05] <SteveA> why didn't I see that earlier?
[05:06] <jamesh> greylisting?
[05:06] <SteveA> no... I had something in the filter box in thunderbird :-/
[05:06] <SteveA> and I was grepping the wrong logs
[05:09] <SteveA> jamesh: can we tell by querying the database who is actively writing to the calendar?
[05:11] <jamesh> SteveA: how do you define actively?
[05:12] <jamesh> we could check which calendars the last few hundred events were created against with a few simple queries
[05:13] <SteveA> ok
[05:13] <SteveA> maybe also a list of the calendars with events in the future
[05:14] <SteveA> and perhaps the number of such events
[05:14] <kiko> salgado, ping?
[05:14] <salgado> kiko, pong
[05:15] <kiko> salgado, can you finish your last sentence in https://launchpad.canonical.com/DirectPersonCreation -- ?
[05:17] <kiko> BjornT, I have a patch for you if you have a moment.
=== oohlaf [i=olaf@deschacht.student.utwente.nl]  has joined #launchpad
[05:17] <BjornT> kiko: is it big?
[05:18] <kiko> BjornT, no, but it's weird. :)
[05:18] <BjornT> kiko: hmm :) what does it do?
[05:18] <kiko> BjornT, removes the XXX I chickened out on. it requires some consideration though.
[05:18] <kiko> and it causes a crash in a certain situation
[05:19] <kiko> BjornT, https://sodium.ubuntu.com/~andrew/paste/fileP9hcYS.html
[05:20] <salgado> kiko, done
[05:20] <kiko> salgado, thanks. I'll direct your question to mark.
[05:20] <salgado> kiko, I've already mailed him
[05:20] <salgado> kiko, and he replied
[05:20] <kiko> salgado, oh. what did he say?
[05:20] <kiko> wow
[05:20] <salgado> Subject: Direct Person Creation
[05:20] <salgado> on launchpad@
[05:21] <kiko> argh.
[05:23] <BjornT> kiko: in what situations does it cause a crash?
[05:23] <kiko> BjornT, http://localhost:8089/products/firefox/+bug/2/+listing-view
[05:23] <SteveA> are you guys talking about an oops, or something more serious?
[05:24] <kiko> BjornT, in that situation, it crashes oddly, with a "self.index" attributeerror
[05:25] <kiko> SteveA, a traceback in webapp code
[05:25] <SteveA> if you get an OOPS report, please call it an "oops" not a "crash".  It's more obvious for users and readers of bug reports if we're consistent
[05:25] <kiko> it's not an oops
[05:25] <kiko> it's not even in production
[05:25] <SteveA> and I'd like to reserve "crash" for something that crashes app servers.
[05:25] <kiko> but nothing crashes app servers
[05:25] <SteveA> ahem
[05:25] <kiko> I tried
[05:26] <SteveA> I wish you were right
[05:32] <kiko> BjornT, what's your take on it?
[05:33] <BjornT> kiko: well, for example, you could make self.index be a method returning u''
[05:33] <kiko> what's self.index? :)
[05:35] <kiko> BjornT, are you in favor of this approach, in any rate?
[05:36] <BjornT> kiko: when you define a page in zcml and specify template="..", the template gets assigned to self.index as a callable, returning the actual page content.
[05:36] <BjornT> kiko: yeah, i think it's fine.
[05:36] <kiko> BjornT, hmmm. can I just define render()?
[05:37] <BjornT> kiko: yeah, actually, that would be better :)
[05:37] <kiko> heh
[05:40] <kiko> BjornT, rs=bjornt then for the whole shebang? it's just updating tests from there on.
[05:41] <kiko> BjornT, note that there is a BugTaskStatusView.. I'm not sure what that's for
=== raphink [n=raphink@ubuntu/member/raphink]  has joined #launchpad
[05:54] <BjornT> kiko: well, better to show me the patch so that i can take a quick look at it, and give you r instead of rs.
[05:54] <kiko> BjornT, goodie.
=== LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net]  has joined #launchpad
[05:54] <BjornT> kiko: BugTaskStatusView is used for +viewstatus. i'm not sure whether we actually use that page, though.
[05:54] <kiko> BjornT, https://sodium.ubuntu.com/~andrew/paste/filespTx0z.html 
[05:58] <BjornT> kiko: ok, r=me. one remark, though. assignee.name should be quoted using urllib.quote, not urllib.quote_plus
[05:59] <bradb> BjornT: we use +viewstatus for non-JS luddites
[06:00] <bradb> speaking of which, the top nav menu is a train wreck without JS turned on
=== bradb checks if a bug is filed
=== LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net]  has joined #launchpad
[06:02] <kiko> BjornT, sure.
[06:03] <kiko> BjornT, should I have imported the view directly from browser/bugtasks instead of using getView() I wonder?
[06:09] <BjornT> kiko: not sure, it doesn't really matter here. getView can be good to use if you need some zcml magic to happen, but in this case you could have imported the view directly. if possible, it's probably better to import the view directly, since it gets easier to see which view class is being used. i'm fine with using getView, though.
[06:10] <kiko> BjornT, it's at least documented in the text. cool
[06:15] <Ubugtu> New bug: #61697 in launchpad "Top navigation bar is messy with JS turned off" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61697
=== raphink [n=raphink@ubuntu/member/raphink]  has joined #launchpad
=== jelmer [n=jelmer@65.91.55.220]  has joined #launchpad
[06:40] <salgado> malcc, around?
[06:40] <kiko-fud> salgado, I have no idea why yet but OOPS-263D218 issues that expensive query twice. do you have an idea why?
[06:40] <Ubugtu> https://devpad.canonical.com/~jamesh/oops.cgi/263D218
[06:41] <kiko-fud> salgado, if you could run a test using LP_DEBUG_SQL_EXTRA and mail me the results I can fix it for you
[06:45] <cprov> salgado: can I help you ? (instead of malcc)
[06:46] <salgado> cprov, maybe. I got some failures on soyuz-set-of-uploads.txt and I thought they could be the same failures that malcc was having last week...
[06:46] <malcc> salgado: Got the traceback?
[06:46] <salgado> I have no clue what changes I've done could have caused them
[06:46] <salgado> sure
[06:46] <salgado> https://devpad.canonical.com/~andrew/paste/fileKKsge3.html
[06:46] <salgado> this is just the first failure
[06:47] <kiko-fud> salgado, don't forget me
[06:47] <salgado> malcc, cprov, https://devpad.canonical.com/~andrew/paste/fileQkBFXs.html includes all failures
[06:48] <salgado> kiko-fud, I won't ever do that!
=== fabbione [n=fabbione@port49.ds1-van.adsl.cybercity.dk]  has joined #launchpad
[06:49] <malcc> salgado: Have you touched any code in nascentupload in this change at all?
[06:49] <salgado> yes
[06:49] <cprov>     + ERROR   Unhandled exception from processing an upload     +  -> http://localhost:58000/66/pxn1SD2Aov3KtB036HV4nZkHSHX.txt ('NascentUpload' object has no attribute 'changes_maintainer')
[06:50] <malcc> cprov: Yes, this test tests the new code which tries to make it a reject, not a fail, when some exceptions happen
[06:50] <salgado> aha!
[06:50] <salgado> okay, I'll make it print the whole exception and then I'll find what's wrong with my code
[06:50] <malcc> So, some change has caused this value not to be available at this time, after this particular strange codepath
[06:51] <salgado> I guess I have something to play with for now. thanks malcc, cprov
[06:51] <cprov> salgado: yup, this code is hell, feel free do make you diff available somewhere so I can try to help you some effectively.
[06:52] <malcc> The first error, which is expected, comes up on line 744 of the unmodified code, but usually, if it gets that far, changes_maintainer will have been set, so the attempt to reject will be ok
[06:53] <salgado> cprov, https://devpad.canonical.com/~andrew/paste/file4KHiTk.html contains my changes to that file
[06:53] <cprov> salgado: k
[06:54] <malcc> salgado: Ok, I suspect the new code here is causing an exception in this case, and hitting the bare except in Soyuz upload processing
[06:54] <salgado> exactly. I've changed the bare except to re-raise
[06:54] <salgado> so I'll see what's wrong
[06:54] <salgado> or rather, the code path that caused self.changes_maintainer to not be set
[06:55] <malcc> The newer tests for upload processing call in behind the bare except to process an individual upload, and therefore give useful errors when they fail
[06:55] <malcc> Eventually they'll all be like that, hopefully
[06:55] <malcc> Except one or two, to test the code with the bare except works :)
=== Burgwork [n=corey@ubuntu/member/burgundavia]  has joined #launchpad
[06:57] <SteveA> rather than use a bare except, use except Exception:
[06:57] <SteveA> then when we switch to python 2.5, that'll allow KeyboardInterrupt through
[06:57] <SteveA> as well as SystemExit
[06:57] <SteveA> but right now, it will have the same effect for you as except:
[06:59] <malcc> SteveA: Cool. At the moment we explicitly re-raise KeyboardInterrupt and SystemExit
[06:59] <SteveA> that's good
[07:00] <SteveA> so, the only change I'd suggest is changing the bare except for except Exception:
=== Kuhrscher [n=jannick@88.134.176.201]  has joined #launchpad
[07:21] <salgado> omg, there were two different places swallowing my exception.  I had to add two "raise"s to be able to see it
[07:22] <salgado> now I can see how much trouble you guys have when working with this code
=== LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net]  has joined #launchpad
[07:26] <salgado> cprov, malcc, so the problem is because I acess self.distrorelease, which in turn raises an UploadError(Unable to find distrorelease: unstable)
[07:27] <cprov> salgado: malcc wants to catch it in UploadProcessor and turn the exception into a rejected upload.
[07:27] <salgado> I guess there are some preconditions in order to use self.distrorelease, and that's why I'm having problems.  but I have no idea what these preconditions are
[07:27] <salgado> eh?
[07:28] <malcc> Yes, the real wtf with the excepts isn't that the upload processing script has to handle unexpected errors, it's that all our testing of it is functional and has to work around the handling
[07:28] <malcc> salgado: Welcome to nascentupload. I'll take a look and try to work it out...
=== LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net]  has joined #launchpad
=== jelmer [n=jelmer@65.91.55.220]  has joined #launchpad
[07:29] <malcc> salgado: Ok, the property for distrorelease looks mostly stable, so the precondition is just that the distrorelease specified in the upload can be found
[07:30] <malcc> Which is why this is only coming up in the test case for an upload to a distrorelease which doesn't exist
[07:32] <salgado> ah, right. so I just need to catch UploadError and use some random string as the release name when the distrorelease is not found, because everything is going to be rolled back in the end, right?
[07:34] <salgado> malcc, can I make the above assumption?
[07:34] <malcc> salgado: Yes, that would work
[07:35] <malcc> salgado: I'm racking my brains for a nicer way, but that's the tragedy of nascentupload - add another slightly smelly hack to get your change working, or try to rebuild the whole thing
[07:38] <salgado> malcc, I could just move the self.changes_maintainer = self.parse_address(changes['maintainer'] ) to after the self.policy.setDistroReleaseAndPocket() one on verify_changes
[07:38] <salgado> with a big comment explaining why it needs to be there
[07:38] <malcc> salgado: No, that'll cause the same error in that test case
[07:39] <salgado> that's right
[07:39] <malcc> Maybe the error handling for a bad upload can be smarter about locating the person. I just tried assuming the nascentupload code would have already located the person, and felt lucky it worked
[07:41] <malcc> Hmm, dinner's ready, I have to run
=== LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net]  has joined #launchpad
=== fabbione [n=fabbione@port49.ds1-van.adsl.cybercity.dk]  has joined #launchpad
=== LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net]  has left #launchpad ["wth] 
[08:12] <kiko> BjornT, is there a "proper" way to get a canonical_url for the bugs facet?
[08:15] <SteveA> kiko: what do you mean "the bugs facet"?
[08:15] <kiko> well /+bugs
[08:15] <SteveA> right now, there is no proper way to get that
[08:16] <kiko> yeah.
[08:16] <kiko> it would be good if there was
[08:16] <kiko> would make it less painful to migrate to bugs.foo later.
[08:16] <SteveA> I'll be adding a proper way for that when we move bugs to bugs.launchpad.net
[08:16] <kiko> SteveA, yeah, but if we added it before.. we'd have less trouble then. anyway, cool.
=== fabbione [n=fabbione@port49.ds1-van.adsl.cybercity.dk]  has joined #launchpad
=== lamont [i=lamont@nat/hp/x-aac6bbd15af6b6df]  has joined #launchpad
[08:26] <lamont> 
[08:28] <kiko> jones
[08:28] <fabbione> consigliere!
[08:30] <lamont> must remember to not hit keyboard when not meaning to
[08:30] <lamont> and must go fetch (sick) kid from school.  back online in a bit
[08:31] <lamont> and will read scroll back then
=== LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net]  has joined #launchpad
=== LeeJunFan [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net]  has left #launchpad ["wth] 
=== bradb [n=bradb@wnpgmb09dc1-71-199.dynamic.mts.net]  has joined #launchpad
=== radix [n=radix@70.91.133.157]  has joined #launchpad
[09:10] <radix> is there a way to see all bugs I've reported on launchpad?
[09:11] <salgado> radix, /people/you/+reportedbugs
[09:11] <radix> cool, thanks. I found a link to +assignedbugs but not to +reportedbugs
[09:12] <salgado> they should all be visible once you're on the bugs facet of your launchpad page. if the +reportedbugs one isn't there it's a bug
[09:12] <kiko> radix, look at the top left corner of your assigned bug pages
[09:12] <kiko> it's there salgado 
[09:12] <kiko> it's just invisible
[09:12] <salgado> then it's a different bug
[09:12] <salgado> :)
[09:13] <kiko> it's in one of them blue boxes
[09:13] <kiko> not the one that lets you make free phone calls
[09:13] <kiko> the other one
[09:13] <radix> kiko: ahhh
[09:13] <kiko> yes that is terrible
[09:13] <kiko> we award medals to people that find it though
[09:14] <radix> kiko: damn, so I lost
=== LarstiQ still hasn't gotten his medal :(
[09:17] <kiko> LarstiQ, what's your mailing address?
[09:17] <kiko> LarstiQ, oh oh wait. aren't you supposed to fix a bug for me?
[09:17] <LarstiQ> kiko: nope!
[09:17] <kiko> hmmm
[09:19] <LarstiQ> as I can't seem to fix it, I've orphaned it
[09:19] <kiko> you can't seem to fix it? snif
[09:19] <kiko> what's the bug # again?
[09:20] <LarstiQ> #30576
[09:21] <kiko> bradb, wanna talk about the unsubscribe issue?
[09:22] <bradb> kiko: I was just about to ask you the same thing, now the seb helped my evo stopped crashing
[09:22] <bradb> poor evo
[09:22] <bradb> i emailed ubuntu-devel earlier today, for more insight
[09:22] <bradb> and talked to BjornT and Kamion for other, related information
[09:23] <bradb> kiko: so, in the longer term, i think unsubscribing from any bug should be allowed
[09:24] <bradb> but, creating situations where people are getting so annoyed from bug spam that they have a desparate urge to unsubscribe is another problem
[09:24] <kiko> bradb, right. in the short term, how about just doing the unsubscribe from dupes issue?
[09:24] <kiko> and not subscribing assignees of dupes
[09:24] <kiko> or other implicit subscribers
[09:24] <bradb> hm, that's not an easy solution
[09:24] <kiko> why not?
[09:25] <bradb> because it's a very incomplete solution, imho, and doing it well enough to be vaguely complete may be almost as difficult as ignore subs
[09:26] <bradb> and, i think we can consider an even simpler first step, possibly. way, way, simpler
[09:26] <kiko> ftr unsubscribing people from dupes should be pretty easy.
[09:27] <radix> hooray, now that I can find all the bugs I've reported I can systematically go through them and add "bump" posts
[09:27] <bradb> kiko: with an ignore subscription yes. without an ignore sub, the best we can do is hackishly solve half the problem.
[09:28] <kiko> without an ignore sub, it's pretty easy.
[09:28] <bradb> i.e. indirect subs on the dupe get left out in the cold
[09:28] <kiko> what is your suggestion, anyway.
[09:28] <kiko> indirect subs on the dupe should not be subscribed to the dupe.
[09:28] <bradb> kiko: i was considering starting by not sending the "that bug is a dupe of this bug" mail to the dupe target subscribers.
[09:29] <bradb> but continuing to generate the "your bug is a dupe of that bug" mail
[09:29] <kiko> there's a bug open on that. I'm kinda okay with that, but it's a hack
[09:29] <kiko> is that the only suggestion you have?
[09:29] <kiko> I mean
[09:29] <kiko> is that the "way way simpler" suggestion?
[09:30] <bradb> yeah, for a first step to ignore subs
[09:30] <bradb> i don't think it's really a hack, fwiw. certainly much less so than unsub from dupes.
[09:31] <bradb> i was also considering not sending dupe bug mail at all, but that's what i'm asking ubuntu-devel about. and also thinking about what kinds of reports we could build, in LP, to help devs assess the dupe triaging effort.
[09:32] <kiko> so I have a pretty different view on this 
[09:32] <kiko> I think that
[09:33] <kiko> a) we should allow people to unsubscribe from dupes semi-transparently
[09:33] <kiko> b) that implicit subscribers of dupes should not be subscribed
[09:33] <kiko> c) that the status table on the dupe bug be omitted
[09:33] <kiko> d) that if that still causes problems, consider doing the mail hack
[09:34] <bradb> a. why only "semi-transparently"?
[09:35] <bradb> why should subscribe/unsubscribe feel any different, for this casE?
[09:35] <kiko> bradb, well, the user would know that he is actually unsubscribing from a dupe.
[09:35] <kiko> because he is subscribed to the dupe, not to the main bug.
[09:35] <kiko> just in the spirit of making the model clear.
=== BjornT [n=bjorn@clt-84-32-240-183.dtiltas.lt]  has joined #launchpad
[09:36] <bradb> kiko: are you considering the other unsubscribing use cases here, like, say, unsubscribing a bug contact?
[09:37] <kiko> <kiko> b) that implicit subscribers of dupes should not be subscribed
[09:37] <kiko> ah
[09:37] <kiko> the bug contact for that bug?
[09:37] <bradb> yeah
[09:37] <kiko> nope.
[09:37] <kiko> he will be unable to subscribe for now.
[09:37] <bradb> I think it's an important consideration
[09:37] <kiko> perhaps. but for now, I think it's okay
[09:38] <kiko> it's not hard to tell a bug contact to drop email from a bug. it's hard to tell the mass of subscribers in the world to do that..
[09:39] <bradb> i agree. i'm just considering that use case though, in thinking about this solution
[09:39] <bradb> and considering another thing, which is that if we're causing so much grief for people that they're begging to unsub, that's indicative of a problem that isn't just sub/unsub; it's about the mail we're sending out
[09:42] <bradb> so far, the only two ubuntu people i've heard from have responded favourably to not generating "X is a dupe of your bug" mail. Colin liked it, for example, though he mentioned that it might cause other problems
[09:42] <salgado> kiko, you got mail
[09:42] <kiko> salgado, cool
[09:43] <bradb> like, the still outstanding issue that often one of the people from the dupes you don't want getting mail is, in fact, a bug contact (like ubuntu-bugs). so what if we considered adding these two solutions together?
[09:43] <bradb> starting by 1. not sending dupe mail to indirect subs and 2. not sending "X is a dupe of your bug" mail?
[09:43] <bradb> er
[09:43] <kiko> bradb, yeah.. I guess I see your point.
[09:44] <kiko> the thing is
[09:44] <kiko> I can totally appreciate that email saying that new dupes of my bugs were filed!
[09:44] <kiko> it helps decide whether or not people are running into it
[09:46] <bradb> hm
[09:47] <bradb> kiko: is it important enough a feature to warrant the spam?
[09:47] <bradb> vs., say, a message at the top of the screen saying "this bug has been reported _14 times_" and/or lists of "most common bugs"?
[09:48] <kiko> the former sounds okay. but where would 14 times link to.
[09:48] <kiko> salgado, I have a question for you.
[09:49] <bradb> kiko: it could be an expander listing the dupes. I was discussing this in a bug report with mpt the other day.
[09:49] <bradb> i think he liked the idea
[09:49] <kiko> bradb, I remember, but I don't remember the expander. I'd be okay with just the text though.
[09:49] <bradb> the idea was that it could allow us to remove the portlet
[09:49] <kiko> so.. I would be fine with doing those three things.
[09:49] <kiko> oh
[09:49] <kiko> you wanna do that?
[09:49] <kiko> hmmm
[09:50] <kiko> I'm not so hot about that change
[09:50] <bradb> why's that?
[09:50] <kiko> dunno.. I think because I'm used to where it is now
[09:50] <bradb> from my perspective, it seems hidden, and not easy to make sense of even if you do see it, as it currently stands
[09:50] <kiko> not sure
[09:50] <kiko> why don't we do that in a separate step?
[09:51] <kiko> could be just that I need a week of adjusting to the change
[09:51] <bradb> sure, i'm not suggesting this should be done all at once, just giving some ideas for future iterations
[09:53] <bradb> i also think the unsub from dupes think isn't so bad if we don't send mail to indirect dupe subs, fwiw. i just can't help wanting to avoid pissing people off to begin with, which is why i got interested in changing the mails we send too.
[09:55] <bradb> kiko: so, between changing the mail, adding a notification bubble to the top of the screen, removing the dupes portlet, unsubing from dupes, etc. what path do you think we should take for implementing this?
[09:56] <bradb> (i'm all for trying 1. not sending dupe mail to dupe targets, 2. 14 times, 3. unsub from dupes, 4. remove dupes portlet, 5. more changes)
[09:57] <bradb> 10. ignore subs
[09:57] <bradb> (maybe)
[09:57] <kiko> well
[09:57] <kiko> what about b) and c) above
[09:59] <bradb> b. i think the would be much less annoyed if 1. were implemented (though, of course, for getting away from flame wars, they'd need unsubbing). and we could even include not mailing indirect subs from dupes in 1.
[10:00] <kiko> if you do b) I think then 1,2,3 is a good choice for a landing.
[10:00] <bradb> ok. re: c. i'm not yet sure, but intuitively, not showing the table doesn't seem quite right.
[10:01] <kiko> maybe
[10:01] <kiko> I like the idea but I'm not sure of the fallout!
=== carlos -> out
[10:02] <carlos> see you!!!
[10:02] <carlos> kiko: btw, did you talked with Steve?
[10:02] <bradb> kiko: bottom of bug 52613 is where i babbled, btw
[10:02] <Ubugtu> Malone bug 52613 in malone ""Duplicate" system is conceptually erroneous" [Untriaged,Confirmed]  http://launchpad.net/bugs/52613
[10:02] <kiko> carlos, yes, he said okay.
[10:02] <carlos> ok
[10:02] <carlos> thanks
[10:02] <kiko> bradb, I've had that bug open for a LONG time now
[10:02] <carlos> see you tomorrow!!!!
[10:04] <kiko> cprov?
[10:04] <bradb> kiko: Should I email launchpad@ then, summarizing the dupes discussion?
[10:04] <kiko> bradb, summarizing the dupes resolution, yes. list possible future work. and get to it! :)
[10:05] <bradb> kiko: right. there is also ConjoinedBugTasks on which to twist my brane today. :/
[10:05] <cprov> kiko: yes
[10:06] <kiko> bradb, jury's still out on that so this may be a welcome rest..
[10:07] <kiko> cprov, did we add that check for bzip2 compression recently?
[10:07] <kiko> the one which caused doko's upload to fail I mean
[10:07] <bradb> kiko: yeah
[10:07] <cprov> kiko: no, it was always there 
=== LaserJock [n=mantha@ubuntu/member/laserjock]  has joined #launchpad
[10:15] <kiko> cprov, thanks. I was curious
[10:16] <cprov> kiko: np, I've never seen this error before (code is entirely inherited from dak)
[10:16] <kiko> cprov, matt was asking if we could pending approval instead of rejecting?
[10:17] <kiko> salgado, xx-shipit-search-for-requests ?
[10:17] <salgado> yep
[10:17] <LaserJock> are the @ubuntu.com email addresses handled by LP?
[10:17] <cprov> kiko: eh, not easily, you know the code.
[10:17] <kiko> LaserJock, not really. what's up?
[10:17] <kiko> salgado, non-browser test.. ARGH
[10:18] <kiko> oh, is it because of the Host: header?
[10:18] <LaserJock> kiko: hmm, well I switched my preferred email and now LP emails go to the new one, but @ubuntu.com email goes to the previous one
[10:18] <LaserJock> kiko: I've switched it before without problem
[10:18] <kiko> LaserJock, what's your Launchpad username?
[10:19] <LaserJock> kiko: mantha
=== erdalronahi [n=erdal@p50875B0F.dip.t-dialin.net]  has joined #launchpad
[10:20] <kiko> LaserJock, I placed an RT request for you, will either be sorted out or will have some feedback by next week.
[10:20] <kiko> salgado, r=salgado on the fix?
[10:20] <LaserJock> kiko: excellent thanks
[10:20] <salgado> kiko, I haven't seen it yet
[10:20] <Ubugtu> New bug: #61735 in malone "Can't sort by column on +reportedbugs, +subscribedbugs" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61735
[10:20] <kiko> salgado, please look at it, I have my finger on the trigger
[10:20] <salgado> you always do
=== LaserJock [n=mantha@ubuntu/member/laserjock]  has left #launchpad [] 
[10:23] <salgado> kiko, I don't quite like the name of the property. maybe current_shipitrequests_batch() or something like that?
[10:24] <salgado> hmmm. the return shortlist( ...) line has a space right after the "(" and more than 80 cols
[10:25] <Ubugtu> New bug: #61737 in launchpad "Users should be able to choose who actually answered their support requests" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61737
[10:28] <kiko> salgado, shipitrequests is fine.. it's only used there.
[10:29] <salgado> kiko, but it's confusing. it may seem that it contains all the requests and not only the current batch
=== Kuhrscher [n=jannick@88.134.176.201]  has joined #launchpad
[10:30] <salgado> kiko, also, request_totals() looks like a method, because request is also a verb
[10:30] <kiko> salgado, but requests_totals() is not english. :)
[10:31] <salgado> kiko, then maybe totals_for_requests()
[10:31] <kiko> okay
[10:32] <kiko> it would have to be totals_for_current_requests following your logic!
[10:32] <kiko> I'm okay with totals_for_requests
[10:32] <kiko> and we can just call the property requests if you like
[10:32] <kiko> current requests is overkill
[10:32] <salgado> requests_batch?
[10:33] <kiko> ah
[10:33] <kiko> why?
[10:33] <salgado> I always try to avoid the name request alone in view code, you know why
[10:33] <kiko> so shipitrequests was fine!
[10:33] <salgado> I prefer current_shipitrequests_batch
[10:33] <kiko> there is no need to say current
[10:33] <kiko> seriously
[10:33] <salgado> it's only used in two places
[10:34] <kiko> I need to rename everything in the template
[10:34] <kiko> and it's really unnecessary
[10:34] <salgado> why not shipitrequests_batch
[10:34] <salgado> ?
[10:34] <salgado> :%s/shipitrequests/shipitrequests_batch/gc
[10:34] <kiko> what does _batch, or current_, give you?
[10:35] <kiko> shipitrequests in no way implies it's all the requests in the world
[10:35] <kiko> it says it is just a collection of shipitrequests
[10:35] <salgado> the _batch helps making it clear that I'm not dealing with all the requests returned by the search() method
=== matsubara_ [n=matsubar@200-171-140-32.dsl.telesp.net.br]  has joined #launchpad
[10:37] <kiko> salgado, the potential for confusion there is approximately zero.
[10:38] <salgado> let's make it zero, then. :)
=== kiko dies
=== shipit [i=kiko@200-171-140-32.dsl.telesp.net.br]  has joined #launchpad
[10:44] <shipit> oh no
[10:44] <shipit> if kiko dies
[10:44] <shipit> who will fix my timeouts
[10:44] <kiko> salgado, you killed kiko!
[10:44] <kiko> you bastard
[10:45] <salgado> hahahah
[10:45] <kiko> hmm, the id line sort of gave it away
[10:45] <LarstiQ> yeah, but still :)
[10:47] <kiko> matsubara, does bug 42749 still happen?
[10:47] <Ubugtu> Malone bug 42749 in launchpad "SoftTimeout error on +source page" [Medium,Confirmed]  http://launchpad.net/bugs/42749
[10:51] <kiko> salgado, have time to review https://sodium.ubuntu.com/~andrew/paste/filemi2BJ5.html before you hit the deck?
[10:51] <kiko> it's important to fix the person timeouts..
[10:52] <salgado> kiko, I'm afraid not. I need to finish reviewing a branch that's on my queue for quite some time already
[11:05] <matsubara> kiko: apparently no. feel free to reject it. I'll re-open if I spot it again.
[11:05] <kiko> thanks matsubara 
=== raphink [n=raphink@ubuntu/member/raphink]  has joined #launchpad
=== bradb heads off, later all
=== Seveas [n=seveas@ubuntu/member/seveas]  has joined #launchpad
=== ryanakca [n=ryan@unaffiliated/ryanakca]  has joined #launchpad
=== ryanakca [n=ryan@unaffiliated/ryanakca]  has joined #launchpad
=== ChanServ [ChanServ@services.]  has joined #launchpad
=== Spads [n=spacehob@host-87-74-54-82.bulldogdsl.com]  has joined #launchpad
=== ryanakca [n=ryan@unaffiliated/ryanakca]  has joined #launchpad
=== Seveas [n=seveas@ubuntu/member/seveas]  has joined #launchpad
=== raphink [n=raphink@ubuntu/member/raphink]  has joined #launchpad
=== BjornT [n=bjorn@clt-84-32-240-183.dtiltas.lt]  has joined #launchpad
=== lamont [i=lamont@nat/hp/x-aac6bbd15af6b6df]  has joined #launchpad
=== Burgwork [n=corey@ubuntu/member/burgundavia]  has joined #launchpad
=== oohlaf [i=olaf@deschacht.student.utwente.nl]  has joined #launchpad
=== lbm [n=lbm@82.192.173.92]  has joined #launchpad
=== ajmitch [n=ajmitch@ubuntu/member/ajmitch]  has joined #launchpad
=== flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca]  has joined #launchpad
=== matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br]  has joined #launchpad
=== salgado [n=salgado@200-171-140-32.dsl.telesp.net.br]  has joined #launchpad
=== Nafallo [n=nafallo@ubuntu/member/nafallo]  has joined #launchpad
=== sivang [i=sivan@muse.19inch.net]  has joined #launchpad
=== mdz [n=mdz@studiocity-motorola-bsr1-70-36-194-85.vnnyca.adelphia.net]  has joined #launchpad
=== jelmer_ [n=jelmer@a62-251-123-16.adsl.xs4all.nl]  has joined #launchpad
=== kiko [n=kiko@200-171-140-32.dsl.telesp.net.br]  has joined #launchpad
=== jkakar [n=jkakar@204.174.36.228]  has joined #launchpad
=== danilos [n=danilo@cable-89-216-150-89.dynamic.sbb.co.yu]  has joined #launchpad
=== andrunko [n=andrunko@200.184.118.132]  has joined #launchpad
=== Ubugtu [n=bugbot@ubuntu/bot/ubugtu]  has joined #launchpad
=== MikaT [n=mtapoja@212.50.150.21]  has joined #launchpad
=== daq4th [n=darkness@netstation-005.cafe.zSeries.org]  has joined #launchpad
=== mpt [n=mpt@203-167-187-52.dsl.clear.net.nz]  has joined #launchpad
=== sevrin [n=sevrin@202.75.186.154]  has joined #launchpad
=== xenru [n=Miranda@85.192.12.132]  has joined #launchpad
=== jml [n=nnnnjml@203-217-8-89.perm.iinet.net.au]  has joined #launchpad
=== Znarl [n=karl@bb-82-108-14-161.ukonline.co.uk]  has joined #launchpad
=== elmo [n=james@83-216-156-21.jamest747.adsl.metronet.co.uk]  has joined #launchpad
=== jordi [n=jordi@115.Red-213-96-69.staticIP.rima-tde.net]  has joined #launchpad
=== lucasvo [n=lucasvo@wservices.ch]  has joined #launchpad
=== siretart [i=siretart@ubuntu/member/siretart]  has joined #launchpad
=== merriam [n=merriam@84-12-84-123.dyn.gotadsl.co.uk]  has joined #launchpad
=== jamesh [n=james@203-59-208-48.dyn.iinet.net.au]  has joined #launchpad
=== sfllaw [i=sfllaw@debian/developer/coleSLAW]  has joined #launchpad
=== spiv [n=andrew@218-214-66-203.people.net.au]  has joined #launchpad
=== mholthaus [n=mholthau@johnny33.dersbach.ch]  has joined #launchpad
=== crimsun [n=crimsun@pdpc/supporter/silver/crimsun]  has joined #launchpad
=== LarstiQ [n=larstiq@cust.7.157.adsl.cistron.nl]  has joined #launchpad
=== SteveA [n=steve@costello.z3u.com]  has joined #launchpad
=== lifeless [n=robertc@ppp245-86.static.internode.on.net]  has joined #launchpad
=== asw [n=asw@134.174.150.46]  has joined #launchpad
=== [PUPPETS] Gonzo [i=gonzo@80.69.47.16]  has joined #launchpad
=== stgraber [i=steph@sgserv.net]  has joined #launchpad
=== Fujitsu [n=Fujitsu@c58-107-60-250.eburwd7.vic.optusnet.com.au]  has joined #launchpad
=== flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca]  has left #launchpad ["Bye"] 
=== boricua [n=illustre@cpe-24-161-35-162.hvc.res.rr.com]  has joined #launchpad
[12:12] <boricua> several  bugs in ubunt in lauchpad but they dont get fixed????
[12:14] <kiko> boricua?
[12:14] <boricua> kiko: you i posted a bug and i see other people with the same problem but no response?
[12:14] <boricua> i meant yeah  not you :-(