[12:20] New bug: #65577 in malone "Report a bug in current distro release context oopses" [Undecided,Confirmed] http://launchpad.net/bugs/65577 === AlinuxOS [n=alinux@d81-211-245-33.cust.tele2.it] has joined #launchpad === AlinuxOS [n=alinux@d81-211-245-33.cust.tele2.it] has joined #launchpad [01:14] jordi? === AlinuxOS [n=alinux@d81-211-245-33.cust.tele2.it] has joined #launchpad === poolie_ [n=mbp@ppp112-44.static.internode.on.net] has joined #launchpad [01:35] New bug: #65588 in malone "When reporting via email, ignore package specified in "affects" if the package is not found - keep the distro though, and don't reject the submission" [Undecided,Unconfirmed] http://launchpad.net/bugs/65588 [01:40] New bug: #65589 in soyuz "Deathrow processing has dryrun vs. commit backwards" [Critical,In progress] http://launchpad.net/bugs/65589 === Fujitsu [n=Fujitsu@ubuntu/member/fujitsu] has joined #launchpad [01:45] Anyone up for a quick review? [01:45] malcc, sure. [01:45] kiko: https://devpad.canonical.com/~andrew/paste/file6tTyOl.html === danilo[out] [n=danilo@cable-89-216-150-47.dynamic.sbb.co.yu] has joined #launchpad [01:52] malcc, no way -- that bug really existed?!! [01:53] coisa horrvel [01:53] malcc, that needs a test [01:53] kiko: Yeah, you're probably right. What do you think is the best location for a script-launching test? [01:54] kiko: It's a nice thin script, so I'd like to keep the "actually run the script" test nice and small, away from the tests of the module in deathrow.txt [01:54] scripts/ftests [01:54] Cool [01:54] r=kiko if it's tested [01:54] gross error [01:58] and mine too :-( [01:58] kiko: Well I tested it :( [01:58] I guess I just never looked at the db after a functional test, just the deleted files [01:59] yeah [01:59] crackhead developers of doom [01:59] good that you caught it though :) [01:59] anyway, outta here [01:59] Goodnight [01:59] zzz === Fujitsu [n=Fujitsu@ubuntu/member/fujitsu] has joined #launchpad === mpt [n=mpt@121-72-128-69.dsl.telstraclear.net] has joined #launchpad [02:29] Gooooooooooooooooooood afternoon Launchpadders! === Fujitsu [n=Fujitsu@ubuntu/member/fujitsu] has joined #launchpad === elmo [n=james@83-216-156-21.jamest747.adsl.metronet.co.uk] has joined #launchpad === Spads_ [n=spacehob@host-84-9-49-231.bulldogdsl.com] has joined #launchpad === elmo [n=james@83-216-156-21.jamest747.adsl.metronet.co.uk] has joined #launchpad === Spads [n=spacehob@host-84-9-51-167.bulldogdsl.com] has joined #launchpad === Jozo- [i=jozo@viola.uninea.fi] has joined #launchpad === WaterSevenUb [n=WaterSev@c-65-96-188-198.hsd1.ma.comcast.net] has joined #launchpad === Burgundavia [n=corey@ubuntu/member/burgundavia] has joined #launchpad === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad === mholthaus__ [n=mholthau@210.27.76.83.cust.bluewin.ch] has joined #launchpad === indu [n=indu@203.129.255.178] has joined #launchpad [05:51] kiko: hi, good morning === mpt [n=mpt@121-72-128-69.dsl.telstraclear.net] has joined #launchpad === lifeless [n=robertc@ppp245-86.static.internode.on.net] has joined #launchpad === lifeless [n=robertc@ppp245-86.static.internode.on.net] has joined #launchpad === lifeless [n=robertc@ppp245-86.static.internode.on.net] has joined #launchpad [06:17] hi, is there any irc channel for the soyuz product [06:18] lifeless: hi is there any irc channel for the soyuz product [06:19] indu: no, just here [06:20] Burgundavia: then who is the correct person to talk about it [06:21] hmm, no idea === stub [n=stub@ppp-58.8.11.94.revip2.asianet.co.th] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [07:30] indu, either cprov or malcc [07:31] indu, neither of them are here at the moment, but malcc should be here in 5.5 hours or less. [07:47] indu: if you ask your question, we might be able to answer it [07:47] (then again, we might not and you'll have to wait for malcc or cprov) [08:00] mpt: you'll be happy to know that cascading section support in ~/.bazaar/locations.conf landed -- so "bzr push" won't break your "bzr pqm-submit" configuration === Fujitsu [n=Fujitsu@ubuntu/member/fujitsu] has joined #launchpad [08:10] jamesh: sorry, just out of my seat [08:11] jamesh: I want to experiment with soyuz, so that I can decide whether I can proceed with this further [08:11] jamesh: so can any of u please tell me, where can i try this soyuz product [08:12] indu: Soyuz is the distribution management portion of https://launchpad.net [08:12] what aspect are you wanting to test? [08:13] jamesh: I am working for a distribution, its debian based [08:13] jamesh: and now we want to create our own repository with our packages [08:13] jamesh: as ubuntu has recompiled all debian packages into ubuntu packages and renamed them from debian to ubuntu [08:14] and I got the info that ubuntu is using this soyuz product [08:14] jamesh: so i want to know, how far will this be helpfull in our distribution [08:14] iirc the packages with release numbers like *ubuntu* are unes that have been modified by the Ubuntu developers [08:15] rather than being a mechanical rename + recompile [08:16] jamesh: yes I heard that renaming and recompilnig is done using this soyuz product [08:16] I don't think the build daemon code is public yet. We do plan to provide a way for other people to manage small repositories of packages in the future (personal package archives) [08:16] but that is not ready yet [08:17] indu: for clarification, soyuz doesn't rename and upload source packages; individual Ubuntu developers do that. [08:18] crimsun: then what does this soyuz do [08:19] indu: jamesh is explaining that [08:19] jamesh: can i know what this soyuz doea actually [08:20] *does [08:20] indu: it manages the package archive (you can browse it at https://launchpad.net/distros/ubuntu), manages a queue of uploaded source packages, feeding those source packages to build daemons and then adding the resulting binary packages to the archive === mpt [n=mpt@121-72-131-100.dsl.telstraclear.net] has joined #launchpad === Burgundavia [n=corey@ubuntu/member/burgundavia] has joined #launchpad === indu [n=indu@203.129.255.178] has joined #launchpad [08:49] mpt: ping === fabbione [i=fabbione@gordian.fabbione.net] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [08:54] SteveA, pong === BjornT [n=bjorn@clt-84-32-240-183.dtiltas.lt] has joined #launchpad === quail [n=quail@ppp234-49.lns2.adl2.internode.on.net] has joined #launchpad [09:21] mpt: I'm about to leave for mossop st. will you be around in 35 mins ? [09:21] and congrats on getting the DSL sorted! [09:22] if you won't, please send me a fresh email saying about the TraversalError problem on the UI branch. I'll look into it this morning. [09:22] SteveA, I will [09:53] mpt: ping [09:54] pingity pong === malcc [n=malcolm@host86-135-237-55.range86-135.btcentralplus.com] has joined #launchpad === _thumper_ [n=tim@217.205.109.249] has joined #launchpad === Spads [n=spacehob@217.205.109.249] has joined #launchpad === mpt wonders why, now that he's using repositories both locally and on devpad, bzr push is still so horribly slow [10:22] mpt: bzr push will still be doing the same thing [10:24] Is that what the smart server will fix? === mpt reads about it [10:26] jamesh: https://devpad.canonical.com/~jamesh/oops.cgi/2006-07-12/S21 [10:26] mpt: It is quicker to rsync your entire repository [10:27] push: .FORCE [10:27] rsync -avPze ssh --delete-after \ [10:27] ~/.canonical-bzr/ \ [10:27] devpad:/home/warthogs/archives/stub/ [10:27] mpt: the smart server has the potential to reduce the number of round trips needed to push the branch, so yes. [10:27] nifty [10:27] for now rsync is generally faster. [10:28] ok, I'll start using rsync once I've finished importing all my branches [10:28] stub: you can use devpad.canonical.com:/code/stub now [10:28] otherwise some of them will get nuked [10:29] mpt: I have a bzr plugin that can push all the branches in a repository in a single go. It is faster than multiple sftp pushes, but slower than rsync === mpt can't imagine why he'd want to make multiple sftp pushes, unless it was for speed purposes :-) [10:30] mpt: if you have multiple branches to push [10:31] <_thumper_> morning all === jinty [n=jinty@205.Red-83-56-149.dynamicIP.rima-tde.net] has joined #launchpad [10:33] <_thumper_> jamesh: I've been talking with steve and ddaa about a problem with timeouts, and stub commented on the review and brought up the main issue that had been bothering me [10:33] jamesh: That error is an invalid oops, so looks like it is just breaking rather than returning a 404 [10:33] <_thumper_> and that is executing the actual query twice === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad [10:34] <_thumper_> One suggestion is the possibility of pushing the functionality down into sql object and how it processes the queries [10:34] <_thumper_> add the ability to set a low and high water mark for the query [10:34] <_thumper_> if the rowcount hits the low mark, a warning is emmitted [10:34] <_thumper_> at the high mark, an exception is raised [10:35] <_thumper_> jamesh: any comments on how easy this would be to implement? [10:35] _thumper_: so something like the selectOne() routine but more generic? [10:35] <_thumper_> jamesh: not sure on what selectOne does, [10:36] <_thumper_> the idea is that these values are checked before iteration begins [10:36] stub: fixed. [10:36] _thumper_: Best you can do is specify a LIMIT clause in the SQL query. You still either need to retrieve the results to see if the limit has been met, or do a count(). [10:37] <_thumper_> stub: the actual problem is not the actual query timing out [10:37] _thumper_: it is a variant of the sqlobject select() method that you can use for queries that should return 0 or 1 rows [10:37] <_thumper_> but in the processing of the objects, other queries are executed [10:37] <_thumper_> and it is the repeated other queries that are causing the timeouts [10:38] Kiko wrote the prejoin stuff for SQLObject to help with this problem, but it doesn't solve all of the cases [10:38] _thumper_: it issues a "limit 2" query, and raises an exception if it gets two rows back [10:38] <_thumper_> jamesh: ok [10:38] <_thumper_> once the query has been executed, is the rowcount available? [10:38] _thumper_: Only after the rows have been retrieved. [10:39] _thumper_: (because the database might not even know if it is streaming the data as the query executes rather than materializing everything in RAM and sending it after) [10:39] <_thumper_> stub: ok, I get that [10:40] stub: the DB API provides a cursor.rowcount attribute [10:40] does that get set to something meaningful? [10:40] jamesh: Which is undefined until you have selected all the results fom the cursor [10:41] stub: that's now how it is defined to act in the API [10:41] (just like JDBC, PerlDBI and everything else that needs an ODBC backend) [10:41] <_thumper_> so the cursor is moved during the creation of the objects using the iteration functions? [10:41] actually, maybe it does. [10:41] "This read-only attribute specifies the number of rows that the last executeXXX() produced ... or affected" [10:42] The attribute is -1 in case no executeXXX() has been performed on the cursor or the rowcount of the last operation is not determinable by the interface. [7] [10:42] and it says that it can be -1 [10:42] yeah [10:42] Which in practice, unless you are using a toy database, it will be -1 until you have selected all the rows. [10:43] _thumper_: Yes [10:43] <_thumper_> stub: thanks [10:43] <_thumper_> I've got an idea, and will push it to devpad this morning for review [10:43] still not quite sure why batching isn't an option for this [10:44] _thumper_: Unless you hit some code that converts the resultset into a list, which is generally a bug needing to be fixed. [10:44] mpt: FWIW, the smart server today already speeds up pushing a bit: http://bazaar-vcs.org/Performance/0.11 (it's still just file-level operations, but it cuts down on round-trips for certain operations). [10:44] <_thumper_> jamesh: ideally it is, but that is not being persued just now [10:45] <_thumper_> jamesh: what I'd prefer would be a filtered list [10:46] <_thumper_> so instead of batching the results you enter something to produces a reduced result set [10:46] I think the idea of hardcoding limits and raising an exception if there are too many results is just an interim fix when people believe that it will not actually happen on any pages, and if we see OOPS reports for that exception then batching needs to be added to that page. [10:46] mpt: If you have bzr 0.11 locally, you could try "BZR_REMOTE_PATH=/code/rocketfuel-built/launchpad/sourcecode/bzr/bzr bzr push bzr+ssh://devpad/code/..." [10:46] <_thumper_> stub: that's the intention [10:46] mpt: (the BZR_REMOTE_PATH is a hack to workaround bzr 0.11 not being installed system-wide on devpad yet) [10:47] _thumper_: You still need to be able to display the full, unfiltered list though (batched over multiple pages of course), or search engines will not be able to find the information. [10:48] <_thumper_> stub: yes I think that the primary page will be batched [10:48] <_thumper_> and the details page (which is the one causing the problems at the moment) will use a filter [10:48] <_thumper_> the primary listing page at the moment just shows all [10:50] spiv, is there any reason not to upgrade to 0.11, and if not, how do I do so? [10:50] mpt: are you using edgy or dapper? [10:51] bzr 0.11 seems very solid, and it's faster. I can't think of any reason not to use it. [10:51] http://bazaar-vcs.org/DistroDownloads gives a like to a repo with dapper debs. [10:51] a link, rather. [10:54] spiv: should an RT request be filed to get bzr-0.11 installed as default? [10:55] jamesh: Wasn't there already a request for that? [10:55] dunno [10:56] I think I'm thinking of something related, getting bzr 0.11 into a more official repo or something. [10:56] Probably worth filing the RT request anyway. [11:00] I have a request here mentioning "launchpad-dependencies". Is there an official list of dependencies for launchpad somewhere? [11:01] I believe the request is for build-deps, really. [11:01] Spads: There's a package of that name, to make launchpad dependency installation easier [11:02] hmmm, I'm not seeing it in dapper [11:02] Where can I find it? [11:03] Spads: It's in dapper [11:03] Spads: it is in multiverse [11:03] ahhhh [11:04] spiv, is there any reason not to upgrade to Edgy, and if not ... I can work that much out :-) [11:04] Spads: it isn't in edgy at all though. [11:04] i.e. do all the Launchpad dependencies Just Work in Edgy? [11:04] mpt: I'm running edgy, and aside from some X+suspend/resume woes, it seems fine. === spiv -> food [11:05] such woes I already have, so I'll do that this weekend then === philroche [n=chatzill@gateway.maenol.co.uk] has joined #launchpad [12:03] Hi Guys, I am having trouble importing my rpoject into Lanuchpad (from SVN) I get - Invalid source package name - any ideas? === Keybuk [n=scott@quest.netsplit.com] has joined #launchpad === indu [n=indu@203.129.255.178] has joined #launchpad [12:30] hi, kiko, r u there === quail [n=quail@unaffiliated/quaillinux/x-000001] has joined #launchpad === jinty [n=jinty@205.Red-83-56-149.dynamicIP.rima-tde.net] has joined #launchpad === mpt [n=mpt@121-72-131-100.dsl.telstraclear.net] has joined #launchpad === niru [n=niru@203.129.255.178] has joined #launchpad === glatzor [n=sebi@ppp-88-217-2-173.dynamic.mnet-online.de] has joined #launchpad === Keybuk [n=scott@quest.netsplit.com] has joined #launchpad [01:23] ping jordi: is the po file import of Rosetta currently stalled? === danilos [n=danilo@cable-89-216-150-114.dynamic.sbb.co.yu] has joined #launchpad === quail [n=quail@unaffiliated/quaillinux/x-000001] has joined #launchpad [01:26] Anyone fancy reviewing a test? I got r=kiko last night on my main change, on condition I added a test, and the test ended up a lot bigger than the change [01:29] philroche: you can safely ignore that message === cprov [n=cprov@monga.dorianet.com.br] has joined #launchpad === danilos [n=danilo@cable-89-216-150-114.dynamic.sbb.co.yu] has joined #launchpad [01:40] Ahh sod. Launchpad meeting in 20 mins :-P === stub wants a beer [01:41] <_thumper_> stub: SteveA said to bug you about LayerInvariantError when running tests === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad [01:41] <_thumper_> I merged from devpad devel branch yesterday [01:42] When running some particular test or subset? Or the entire suite? [01:42] <_thumper_> I was running a subset canonical.launchpad.webapp [01:42] We have a bug open on it happening in some cases where you run a subset of tests, but it would become more critical if the 'run all tests' started blowing up. [01:43] <_thumper_> ok [01:43] it usually means that some test is doing some setup it shouldn't for its layer, or forgetting to tear something down [01:43] <_thumper_> hmm... ok [01:43] (which might get masked with other tests running after it in the layer) [01:43] jamesh: There is a real bug where the test runner loads the layers in an unexpected order. I think it is our fault. [01:43] ah. [01:44] jamesh: Possibly just too many paranoid checks, or maybe something more nefarious. [01:44] stub: If we stop using initZopeless, I wonder how the layers should be configured/stacked? [01:45] It will need to be the same, as the scripts still load a different .zcml file. [01:45] So unless that changes... [01:46] it would be good to get different db users factored into the layers [01:46] perhaps a LaunchpadZopelessLayer(dbuser) function that would auto-create layers as needed [01:48] There are already some (sucky) APIs for changing the user a test connects as. I can't remember if it is both for Zopeless and Zopeful. It would be easier if I nuke the old FooTestSetup classes. The layer per user could be a good idea, but probably better to implement using standard inheritance (class names leak out into the command line remember) [01:49] And other test runner magic might break - don't know. [01:49] class FooLayer(LaunchpadZopelessLayer): dbuser='bar' is easy enough === MikaT [n=mtapoja@projects.sse.fi] has left #launchpad [] [01:54] hmm [01:54] wish these were called TestLayer not just Layer [01:54] as we've been already using "Layer" for UI layers [01:55] like an onion [01:55] stub: want to do the honours for this meeting? [01:55] ah, wait, mpt has internet! [01:55] I want a beer [01:55] mpt: in celebration of your internet connection [01:55] would you like to chair today's meeting? === bradb [n=bradb@modemcable077.58-130-66.mc.videotron.ca] has joined #launchpad [01:55] I vote that stub gets a beer [01:56] Seconded. I'm outa here! [01:56] I here there are great bars in thailand === stub runs off quickly [01:56] very friendly bars [01:56] Beer tastes better with naked women === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === stub is of course referring to the novelty swizzle sticks you get around here [01:57] me [01:57] fa so la [01:57] me [01:57] SteveA, ok [01:57] thanks mpt [01:57] ./execute fake_meeting_attendance [01:58] just as soon as I remember how to spell "agenda" === flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca] has joined #launchpad [01:59] agenduh. [01:59] haha [02:00] (the singular form is agendumb) [02:00] MEETING TIME! [02:00] Welcome to the weekly Launchpad development meeting [02:00] Who's here? [02:00] me [02:00] me [02:00] me [02:00] <_thumper_> me [02:00] me [02:00] me [02:00] me [02:00] me [02:01] me [02:01] m [02:01] e [02:01] me === ddaa [n=ddaa@217.205.109.249] has joined #launchpad [02:01] me [02:01] hello [02:01] Is that everyone? [02:02] == Agenda == [02:02] * Activity reports [02:02] * Actions from last meeting [02:02] * Oops report (Matsubara) [02:02] * Bug report report (mpt) [02:02] * Production and staging (Stuart) [02:02] * Launchpad 1.0 status reports + updating spec status [02:02] * Sysadmin requests [02:02] * Storing date_created and other dates and people related to state transitions. [02:02] * Keep, Bag, Change [02:02] * Three sentences [02:02] [02:02] If you have things not mentioned there, please /msg me [02:02] == Activity reports == [02:02] mpt, you cleared out my extra items [02:02] kiko: they're in there [02:02] kiko: I added them, I think [02:03] Who's up to date? [02:03] Not me [02:03] not me [02:03] ok [02:03] up to date [02:03] up to date [02:03] not me [02:03] not me [02:03] up to date [02:03] <_thumper_> I've been slightly lax during the sprint [02:03] up to date [02:03] me [02:03] up to date [02:03] Not uptodate but excused because on sprint. Up to date otherwise. [02:03] up to date [02:03] kiko, the only thing I cleared was the template "(other items)" line [02:03] not me [02:03] I want to point out that although we have special guest chairs each week, in general I still set the agenda before the meeting. [02:04] ok [02:04] == Actions from last meeting == [02:04] * SteveA to put up a wiki page for the launchpad project to note disaster scenarios on, and mail the list about it [02:04] I did that. SteveA, want to talk about it? :-) [02:04] mpt: thank you for doing that. [02:04] https://launchpad.canonical.com/DisasterScenarios [02:05] there are some scenarios of a disasterous nature on here [02:05] from my own feeble imagination [02:05] please take a moment to read through them, and think about particular disasters that may befall the area of launchpad you're personally involved in [02:05] and add them to the page using a similar format to the ones mpt started [02:05] I suspect Soyuz will be able to provide some truly disasterous possibilities [02:05] we'll review and refine them later [02:06] thanks SteveA [02:06] aaaaaand secondly [02:06] * SteveA to write up what needs doing to implement __eq__, __ne__, and __hash__ for database objects [02:06] try to describe specific risks and threats [02:06] I'm looking for quality and interesting interactions between use and things [02:06] rather than sheer quantity. [02:06] [02:06] mpt: I still need to put my notes online on that [02:07] ok. We'll nag you again next meeting. [02:07] ta [02:07] == Oops report (Matsubara) == [02:07] Today's oops report is about bugs 65577, 30602 and 2497 [02:07] Malone bug 65577 in malone "Report a bug in current distro release context oopses" [Undecided,Confirmed] http://launchpad.net/bugs/65577 [02:07] Malone bug 30602 in rosetta "Timeout errors in +translate" [Critical,Confirmed] http://launchpad.net/bugs/30602 [02:07] Malone bug 2497 in rosetta "/people/*/+translations times out for prolific translators" [Critical,In progress] http://launchpad.net/bugs/2497 [02:07] bradb, your work on release management will address bug 65577? If not, can you [02:07] fix that one? [02:07] kiko, bugs 30602 and 2497 are up for review for awhile. Any news on it? [02:07] matsubara, 2497 I have a review to reply to, but 30602 still pending jamesh' review [02:08] matsubara: sure, i'll keep an eye out for it. [02:08] well, I'm done then. thanks mpt and congrats to everyone. 0 exceptions today. [02:09] that's great news [02:09] soon, I think we'll be hitting 0 exceptions per day consistently [02:09] ok [02:09] == Bug report report == [02:09] There are 17 known Critical bugs in Launchpad without released fixes. The oldest 8 not already mentioned by matsubara are: [02:09] * Bug 929 [02:09] Malone bug 929 in launchpad "Long words (such as URLs) overflow columns" [Critical,Confirmed] http://launchpad.net/bugs/929 [02:09] Except for _thumper_'s branch that will turn some existing timeouts into exceptions... [02:09] how comes that it says Revision control system: None given but I use bzr for my project? (https://launchpad.net/products/harmony/trunk) [02:10] Is that really critical? jamesh, what say you? [02:10] * bug 4594 [02:10] Malone bug 4594 in malone "Shouldn't be able to add duplicate bug watches" [Critical,Confirmed] http://launchpad.net/bugs/4594 [02:10] mpt: dunno if it is critical, but it can make pages look ugly [02:10] lucasvo: link to the main branch for your project in https://launchpad.net/products/harmony/trunk/+edit [02:10] it's critical for the ui-one-zero [02:11] BjornT, have you looked at that yet? [02:11] mpt: no, haven't had time yet. i'm planning to fix it next week. [02:11] * Bug 38598 [02:11] Malone bug 38598 in launchpad-bazaar "Branch has no datecreated" [Critical,In progress] http://launchpad.net/bugs/38598 [02:11] BjornT, ok [02:11] ddaa: I already did that [02:11] lucasvo: I've overhalled that form recently, so it will be a bit less confusing on next rollout. See https://staging.launchpad.net/products/harmony/trunk/+source for an idea [02:12] ddaa, you don't want to hear the words that sabdfl hurled down my phone line when he discovered that bug this week. Or maybe you already have. Anyway, ETA? :-) [02:12] mpt: I think stub landed a patch to fix 38598 and others [02:12] ah yes, I saw that [02:12] but is it shown in the UI? [02:12] stub: can you confirm that it's fixed [02:12] I suppose it doesn't matter that much if it's not, I can add it [02:12] The DB is fixed [02:12] thanks stub [02:12] mpt: it's not shown in the UI, no plan to add that [02:12] * Bug 44214 [02:12] 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:12] stub: is that fixreleased then? [02:12] So any critical component is done (well... in rocketfuel) [02:13] fixcommitted [02:13] carlos, progress? [02:13] jamesh, ddaa: I am talking about the little box Revision control details in the lower right corner [02:13] jamesh: it's the same on staging [02:13] * bug 44808 [02:13] Malone bug 44808 in rosetta "Some translation templates in dapper don't contain any items" [Critical,Confirmed] http://launchpad.net/bugs/44808 [02:13] lucasvo: please file a bug, we can talk about it after the meeting [02:13] * bug 46982 [02:13] 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:13] oh, carlos isn't here [02:14] never mind [02:14] ok, so one more [02:14] * bug 54241 [02:14] lucasvo: wow, you actually look at the portlets! [02:14] Malone bug 54241 in launchpad "We need a script or tool that prunes OOPS logs from sodium" [Critical,In progress] http://launchpad.net/bugs/54241 [02:14] stub, do I remember you saying that wasn't Critical any more? or was that my imagination? [02:14] ddaa: I am quite a perfectionis. :) let's discuss itafter the meeting. didn't want to interrupt [02:15] mpt: It isn't critical [02:15] Erm... which bug are you talking about? [02:15] lucasvo: there's indeed a display bug [02:15] stub, bug 54241 [02:15] Malone bug 54241 in launchpad "We need a script or tool that prunes OOPS logs from sodium" [Critical,In progress] http://launchpad.net/bugs/54241 [02:15] Fixed committed, still critical. I'll update the bug now. === ddaa looks sideways at _thumper_ [02:15] ok. [02:16] Sorry that took a bit longer than usual. My dirty little secret is that I usually prepare the bug report report during the first part of the meeting. [02:16] == Production and staging (stub) == [02:16] thanks stub [02:16] and now, here's stub! [02:16] Production cherry picks will happen tomorrow === stub wasn't prepared either [02:17] now that the oops pruner is running fine on staging [02:17] So please add any outstanding ones to ProductionLaunchpadStatus now [02:17] Nothing particularly thrilling happening otherwise. [02:18] For those interested, a freshly restored Launchpad database now takes over 30 gig of disk space [02:18] Up from 10 gig a few months ago [02:18] all carlos' fault [02:18] stub: too bad for mawson [02:18] thats pretty much it except for questions [02:18] ok, any questions? [02:18] 5 [02:18] 4 [02:18] 3 [02:19] 2 [02:19] cprov: I know. I will need to start generating subsets of the production data for testing use [02:19] 1.41 [02:19] 1 [02:19] 0 [02:19] thanks stub [02:19] maybe we could drop the non-english langauges from rosetta [02:19] stub: would it possible to cherrypick your datecreated patch in production? [02:19] stub: you'll not be running out of memory soon... :( [02:19] Danilo txted me to say his router has broken, so he's offline. He's working on fixing this. [02:19] stub: that's a good idea, spliting translation would be good [02:19] ddaa: Not without downtime [02:19] == Launchpad 1.0 status reports == [02:19] Support Tracker 1.0 Report [02:19] -------------------------- [02:19] - SupportTrackerWorfklow: still in review [02:19] - SupportTrackerViews: in review, one view is still unimplemented requiring SupportTrackerWorkflow [02:19] - SupportTrackerHelp: started [02:19] go spammers [02:19] - LocalizedSupportRequests: started, good progress. [02:19] Other 1.0 Item [02:20] -------------- [02:20] - DirectPersonRegistration: started [02:20] cprov: hi, [02:20] Malone 1.0 [02:20] ---------- [02:20] upstream-forwarding-workflow: Last part up for review since Monday. [02:20] series-and-distrorelease-mgmt: Discussed ConjoinedBugTasks with jamesh. Agreed on a solution. [02:20] guided-filebug-form: Handed off to kiko for general UI review. [02:20] removing-duplicate-comments: Status changed to implemented (but no new code written). [02:20] malone-essential-docs: No news. [02:20] simple-bug-keywords: No news. [02:20] importd-bzr-native: done. More cleanups planned, but the scope of the spec has been exceeded already. [02:20] supermirror-smart-server: Late, but good progress. Missed the bazaar meeting monday, so did not have spiv's status update. Dunno what's new since last week. [02:20] = Soyuz-1.0 Report = [02:20] * PPA: blocked on ArchiveRework (still). [02:20] * Archive Rework: slow progress, malcc [02:20] * Code quality: slow progress, r=spiv on ftest for queue tool library [02:20] * Openning Feisty in mawson, performance tests [02:20] * Contents generation tests [02:20] * Upgrade of apt-ftparchive in production, cache regeneration [02:20] * General Fixing: #65052, #65589, #64840 [02:20] indu: hey [02:21] interesting exit message... [02:21] cprov: did u understand my requirement clearly yesterday [02:21] So if danilos successfully returns, he can give us a Rosetta 1.0 report [02:21] in the meantime [02:21] == updating spec status == [02:22] kiko, SteveA, was this supposed to be a separate item? [02:22] yes [02:22] yes [02:22] this is a note to everyone to say... [02:22] indu: yes, I think so ... can we talk after the meeting (in 20 minutes or so) ? [02:22] update the status metadata of the specs you just posted about [02:22] (kiko, that's your cue) [02:22] in launchpad [02:22] cprov: ok [02:23] and keep the status of specs up to date when you do some work on it, or reach a milestone with it [02:23] that way, kiko and I have a good overview of how 1.0 work is going [02:23] mark Steve and I use the specs in our discussion of 1.0 progress [02:23] and that makes it possible to discuss the progress well with mark [02:23] anything to add kiko? [02:23]