[12:11] So, which is faster at this poiunt [12:11] nuking and starting again, or some magic? === mpt is again reminded of what a feeble brain he has [12:12] mpt: since neither of us is willing to diagnose your situation to determine what is the _really_ fastest (in term of least computation) way to get there [12:12] -> nuking, then [12:13] I strongly suggest you get a local rockefuel mirror (make-archive etc.) and populate it using the rocketsync script you can find in launchpad/utilities, courtesy of yours truly. [12:13] ok [12:14] thanks [12:18] mpt: also, for decent performance, you really want to periodically use abentley's library-relink script, and run "baz diff --link" in your launchpad tree, and make sure your editor is configured right. Hardlinking gives orders of magnitude speed improvements on such a large tree (that does not fit in your disk cache). [12:18] "baz diff --link" speeds up status, diff and commit, library-relink speeds up merges. [12:19] (of course, you need to be aware of the risks involved with having a hardlinked-to-revlib tree) [12:19] I think that "launchpad" on a line by itself in the RFS instructions actually shouldn't be there [12:20] you must be a victim of line wrapping [12:20] oh, that was just wrapping [12:20] yeah [12:21] Maybe add $ signs at the beginning of every shell command [12:21] I tend to do that to avoid ambiguities, but that screw up copy-pasting [12:21] Yes, and $s are already used in the instructions to represent variables [12:21] % then [12:22] Any character commonly used on shell prompts. === mpt [n=mpt@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [12:53] carlos/anyone: I still don't have a working Launchpad tree, and I'm going home. So if you need to fix the Rosetta bar charts urgently, add a semicolon to the end of the "title" attribute assignment in the "Unchanged" section of the bar chart template. [12:53] ddaa: Where is the library-relink script? === mpt [n=mpt@200-171-140-32.dsl.telesp.net.br] has left #launchpad [] [01:12] Merge to rocketfuel@canonical.com/launchpad--devel--0: Add a karma column to the person table and update its value in the foaf-update-karma-cache.py cronscript. r=stub (patch-2267: guilherme.salgado@canonical.com) === mpt_ [n=mpt@200-168-129-20.dsl.telesp.net.br] has joined #launchpad === cprov -> good night all [01:54] carlos: there? [01:58] hmm, any other rosetta/gui people? :-) === Nafallo files a wishlist bug tomorrow ;-) [01:59] bye [01:59] stub: http://mirrors.sourcecontrol.net/aaron.bentley@utoronto.ca--baz/library-relink--devel--1 [01:59] ta [02:03] stub: quick sanity check, are you aware of anything (besides taxi) depending on the changesetfile, changesetfilehash and changesetfilename database tables? [02:05] ddaa: I don't think so. trebuchet, dyson and sourcerer use changeset, but don't go any further. [02:05] Good. [02:06] I'll be preparing a branch to remove the dependent code and tests in taxi and buttress, and a semblance of db patch to drop those tables. [02:06] Mh... maybe I could offload that to somebody. [02:06] spiv: willing to take a shot at importd? [02:07] we need an experienced butcher to hack off one of its extraneous limbs. === spiv starts waking up [02:09] Nafallo, I'm here [02:09] spiv: ping me when you're booted up. [02:29] ddaa: ping [02:29] ddaa: Also, has an importd been hitting Twisted SVN recently? [02:29] hu... don't think so [02:29] can hit it pretty easily though [02:30] Heh, no. [02:30] Ha, yes. [02:30] I have a local dump of the repo on chinstrap for you to play with :P [02:30] We do not like local dumps. [02:30] We had problems with them previously. [02:31] I ask because apparently inetd is throttling SVN connections for Twisted, but that seems to be just because it's popular, rather than because of us. [02:31] Sure. The reason it's there is because the Twisted import breaks atm, so you may as well have a fast-to-access copy to debug against that doesn't eat Twisted's bandwidth (which some poor volunteer pays for!). [02:32] Mh... buildbot sucks... it does not seem any import has been run since a the last time I tried a couple of days ago. But it's hard to be sure. [02:32] Cool, well, it's broken, so no rush to retry ;) [02:33] all the failures I have in the history for twisted are due to 1. too many links in tmp, that bug is fixed 2. connection closed unexpectedly, that's inetd [02:34] If you think that's important, I can try to setup a test environment here to confirm that would pass. [02:34] ddaa: twisted import runs out of memory [02:35] lifeless: you tested it with a local repo? [02:35] ddaa: nothing to do with inetd, its purely to let us debug the svn problem with zope3 & twisted [02:35] ddaa: no, but thats the next step. it takes about a day to run out [02:35] Because the OOM is not apparent in the roomba logs. [02:35] ddaa: look at the end of the cscvs log [02:35] pysvn._pysvn.ClientError: Connection closed unexpectedly [02:35] its just a failure [02:35] prettyl quickly [02:35] older events then [02:36] it *was* running out consistently [02:36] older than that is OSError: [Errno 31] Too many links: '/tmp/tmp74F8Ra' [02:36] yeah I noticed cscvs was being used in launchpad... works well? or a lot of hackery involved? [02:36] at a point we lost history because the buildbot tap crapped out somehow. [02:37] ddaa: too many links means /tmp isn't reaping properly [02:37] Yeah, it was definitely OOMing consistently on Twisted. [02:37] lifeless: old bug, was fixed [02:37] or, the code I fixed wasn't rolled out [02:37] you fixed it [02:37] that's old history [02:37] oh [02:37] anyway, breakfast time [02:37] then I might go for a walk [02:37] spiv: anyway, you said you wanted to help with importd, didn't you? [02:39] (the twisted import will be taken care of at some undeterminate point in the future when mark decided I have enough work) [02:39] ddaa: Well, I want there to be about 99 hours in every day, but sure ;) [02:40] So, I have something blocking importd-archivelocation, that's a big patch I have been working on since I came back from brazil. [02:40] (Anyway, looks like they're about to tweak the inetd conf for Twisted, so that should fix that) [02:41] spiv: in lib/importd/taxi.py, line 172 you have [02:41] db_revision.clone_files(revision.iter_files()) [02:41] that stuff uses pybaz.Revision.iter_files, that is not currently working with URL, only registered names. [02:42] and it's used to populate three tables in the db, that are changesetfile, changesetfilename, and changesetfilehash [02:42] these tables are cruft, I have a green light from sabdfl for dropping them [02:43] they contain a lot of data ATM, but not useful data [02:43] your missing shall you accept it [02:43] * your mission [02:43] would be to produce two feature branches [02:44] ddaa: I've gotten my work for the day out of the way. How can I help you? [02:44] The first one removes that line, an all the buttress cruft and tests that supports clone_files. [02:44] That I will rollout to production at my earliest convenience. [02:44] The second one is a db patch that actually drops the tables. [02:46] You mean clone_files should be removed too? [02:46] Shall you encounter any other dependency on those tables (I'd be surprised, but these dark corners are full of bad surprises), I'd like to be informed. === spiv nods [02:46] spiv: yes, clone_files and all the supporting code [02:46] down to sqlobject classes [02:47] I want all the python code that depends on the tables removed separatedly from the db patch, because importd and launchpad (and the db) are rolled out separatedly. [02:48] spiv: if you feel too busy, you can try offloading to jblack, who's apparently idle ATM :) [02:48] spiv: jblack: any questions? [02:49] Nope. Let me chase down the launchpad instructions. [02:49] Actually, is there something else I can do to help? [02:49] ddaa: I think my first pass will be to offload to jblack :) [02:50] I just remembered that mark told me not long ago that he didn't want me working on launchpad. [02:50] jblack: spiv: don't fall over one another rushing to do it :) [02:50] and I don't mean in a "because you have better things to do" way. [02:51] It would probably be ok if I passed the code through one of you though, so that it got an extra review. [02:51] ddaa: Well, I've got something else to do first today, but if I still have time after that, I'll try to dive into this. [02:51] jblack: that's not _really_ launchpad, that's importd, but I guess that's a technicality :) [02:52] spiv: good, because if I do not fix the python import before yesterday sabdfl will remove my caffeine drip, and THEN I'll be in trouble :) [02:52] Well, I do not mean to rush anybody... [02:53] Oh, no, I'm offering. :) [02:54] Thanks guys. [02:54] We're a team. That's what teams do [03:00] presumably importd is in buildbot... [03:02] no, it's in launchpad/lib/importd now [03:02] most of the code to be removed actually lives in launchpad/lib/canonical/launchpad/database/arch*.py and launchpad/lib/canonical/arch (that's buttress). [03:03] From the way I read this config, its launchpad--devel--0 ? [03:04] must be. Just a little surprised. [03:04] yes, but you'll need the full checkout to run the "check_merge" later (after the db patch) to be sure there are no hidden dependencies [03:04] Yeah. I'm going through the full build stuff. [03:05] use it not hardlinked for a little while, to understand the pain [03:05] that's educative... [03:05] Yeah. I know the pain. I've done this from time to time to keep track [03:42] painnnnn. [03:43] stub: If you maintain https://wiki.launchpad.canonical.com/DatabaseSetup, then heads up. It looks like the instructions don't match cotm ubuntu (I dogfood it) [03:45] If you mean breezy, you are right. I have no idea how badly they are out of kilter though because I haven't got the facilities to run both hoary and breezy (and see no need to risk switching to breezy yet) [03:45] Feel free to update the relevant launchpad scripts and the wiki page though ;) [03:45] Sure. Its just fine except for the locale step. [03:46] The main issue I'm aware of is the postgres-contrib stuff moving, which breaks the fti.py launchpad script. [03:46] Ohhh. more breakage. [03:46] (but that might have been fixed in breezy - I have no idea) [03:46] I'll run a test on it. Do you know if the tests catch the locale problem? [03:47] What actually is the locale problem? [03:47] On that page, there are instructions to nuke the default database and recreate one with the current required locale. [03:48] ok. if your locale is screwed, the tests will fail. There are explicit tests to check this. [03:48] Perfect. [03:48] And you will also get random failures as things are returned in the wrong order elsewhere ;) [03:49] The problem is that the 7.4 in unstable, instead of having hte old fashioned /var/libpostgresql/data, now has /var/lib/postgresql/7.4/main (which is quite similiar to the old data dir) [03:50] I don't have a machine with an older psql, so I can't compare the diffrences to find the perfect match. [03:50] so I'm idly wondering if perhaps they fixed the locale thing. [03:50] I also think I'm going to scavange a machine out of my parts. [03:50] Ok. So the instructions should work if you just fix the paths [03:51] Thats the point. :) [03:51] root@comet:/var/lib/postgresql # find . -name data [03:51] root@comet:/var/lib/postgresql # [03:51] data isn't a magic name - it is just a directory name. Looks like /var/lib/postgresql/data is now /var/lib/postgresql/7.4/main === robitaille [n=daniel@d154-5-117-228.bchsia.telus.net] has joined #launchpad [03:52] /var/lib/postgresql/7.4/main/ looks like the rough equivilant, but I'm not sure (its been awhile since I've jumped into a 7.3 data dir). When I tried blowing that away instead and ran initdb, psql wouldn't even start. clustering complaints. [03:52] If it has a 'base' directory in it, it is the data directory. [03:53] It has a base. [03:53] And blowing it away as per those instructions makes bad things happen. [03:53] Of course, if you just run 'initdb' I have no idea if you are running the 7.4 or 8.0 initdb script ;) [03:53] I'm not asking for support. I'm just giving you a heads up. :) === asgeirf [n=asgeirf@203-173-23-155.dyn.iinet.net.au] has joined #launchpad [03:54] ddaa: ping [03:54] here [03:54] please be quick, I'm on my way to bed [03:56] ok. very quick. can't help you tonight. need to build machine with older ubuntu to help. [03:57] anyone: Do you remember how much the bus fair was between Sao Carlos and Sao Paolo? I think it was about 40 reals ? [03:57] no problem, spiv seems willing to give it a shot tonight, and anyway importd-archivelocation is also blocked by my NMI to fix python import. [03:58] stub: 33 or 35 or something... let me find my receipt. [03:58] I recall 35 [03:59] In fact it was 31.45 === lamont-away is now known as lamont === robitaille [n=daniel@d154-5-117-228.bchsia.telus.net] has joined #launchpad === robitaille [n=daniel@d154-5-117-228.bchsia.telus.net] has joined #launchpad === jblack [i=jblack@static-209-158-45-74.scr.east.verizon.net] has joined #launchpad === camilotelles [n=Camilo@201.32.223.192] has joined #launchpad === spiv [n=andrew@adsl-66-203.swiftdsl.com.au] has joined #launchpad === lifeless [n=robertc@dsl-129.129.240.220.lns02-wick-bne.dsl.comindico.com.au] has joined #launchpad === kiko-zzz [n=kiko@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === sladen [i=paul@starsky.19inch.net] has joined #launchpad === Kinnison [n=dsilvers@haddenham.pepperfish.net] has joined #launchpad === j^ [n=j@195.169.149.104] has joined #launchpad === JanC [N=janc@lugwv/member/JanC] has joined #launchpad === lamont is now known as lamont-away === robitaille [n=daniel@d154-5-117-228.bchsia.telus.net] has joined #launchpad === jblack [i=jblack@static-209-158-45-74.scr.east.verizon.net] has joined #launchpad === camilotelles [n=Camilo@201.32.223.192] has joined #launchpad === spiv [n=andrew@adsl-66-203.swiftdsl.com.au] has joined #launchpad === lifeless [n=robertc@dsl-129.129.240.220.lns02-wick-bne.dsl.comindico.com.au] has joined #launchpad === kiko-zzz [n=kiko@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === sladen [i=paul@starsky.19inch.net] has joined #launchpad === Kinnison [n=dsilvers@haddenham.pepperfish.net] has joined #launchpad === j^ [n=j@195.169.149.104] has joined #launchpad === JanC [N=janc@lugwv/member/JanC] has joined #launchpad === robitaille [n=daniel@d154-5-117-228.bchsia.telus.net] has joined #launchpad === SnakeBite [n=SnakeBit@84.242.143.64] has joined #launchpad === robitaille [n=daniel@d154-5-117-228.bchsia.telus.net] has joined #launchpad === robitaille [n=daniel@d154-5-117-228.bchsia.telus.net] has joined #launchpad [09:53] lifeless: What's the right thing to do about unicode in http urls? Just avoid it? === spiv finds http://www.w3.org/International/O-URL-and-ident [10:04] spiv: its scheme specific [10:04] spiv: the serialised url must meet the abnf in std66 [10:04] lifeless: rfc 2718 seems to suggest utf-8 encode, then escape as usual. [10:05] that will probably be correct for url schemes defined post std66 [10:06] which is what 2718 is about [10:06] spiv: this is pointed to in the link you gave: http://www.w3.org/TR/REC-html40/appendix/notes.html#h-B.2.1 [10:07] jamesh: thats for html url references [10:07] safest is probably to generate ASCII URIs in launchpad, and expect encoded UTF-8 in the librarian [10:07] I thought spiv meant in the http protocol [10:07] Right. This is for the librarian. [10:08] What url should a file named u'Yow\N{INTERROBANG}' be published at in the librarian? :) [10:08] utf8 then % encode is safe always [10:08] (using python literal notation) === spiv nods [10:08] urls will always round trip [10:08] That suits me, I'll do that. [10:08] (already coded it, in fact ;0 [10:08] the problem can occur if someone tries to show it nicely. [10:09] or if someone is trying to guess the url from other data. [10:09] Neither of which are really concerns for the librarian. [10:09] i.e. if I say to you 'home pages are at http:/launchpad.net/people/$person', and $person is non ascii, then I might guess a different approach than you the server do [10:09] i.e. I might do latin-1 [10:10] where the server does utf-8 [10:10] encoded UTF-8 will make the web browsers we care about do the right thing when saving [10:10] (both post % encoded.) [10:10] Thankfully, we have strict constraints on names in launchpad. I think the librarian is fairly unique here among our various systems. [10:10] jamesh: That's good news. [10:10] Ok, thanks to both of you for your help. [10:11] np === ddaa [n=ddaa@ordo.xlii.org] has joined #launchpad === Mez [n=Mez@cpc2-lich4-3-0-cust115.brhm.cable.ntl.com] has joined #launchpad === sabdfl [n=mark@217.205.109.249] has joined #launchpad === carlos [n=carlos@243.Red-83-47-24.pooles.rima-tde.net] has joined #launchpad [11:22] morning [11:22] carlos: morning and ping :-) [11:23] carlos: could we have something in rosetta to show those where suggestions are added? === jayp [n=jp@62.253.252.7] has joined #launchpad [11:23] Nafallo, like show translated, untranslated, needs review, etc...? [11:24] would be easier to approve people based on the quality of their work if you don't have to walk through 14000 translations just to see two strings they've done. [11:24] carlos: yepp :-) [11:25] Nafallo, I suppose it's not a big problem... could you open a bug report about it so we don't forget it? [11:25] carlos: sure. I'll assign it to you? :-) [11:25] I cannot implement it now, but that way we will take care of it later [11:25] Nafallo, as you wish :-) [11:25] hehe [11:26] Hi all, just logged a bug against ethereal in ubuntu, but since ethereal is universe, I'm told I should log it through launchpad. How does this differ from bugzilla? [11:27] jayp, packages in main are not yet migrated to launchpad [11:27] that's all [11:28] carlos, but all ubuntu will go to this launchpad eventually? [11:28] jayp, yes [11:29] I think it will happen with breezy release, perhaps a bit earlier [11:29] camilotelles: #1801, I can't assign it to you. missing privilegies :-( [11:29] hmm [11:29] carlos: ^ ;-) [11:30] Nafallo, don't worry, if it's filed against rosetta, I will take it when I start the implementation. [11:30] thanks [11:30] no problem :-) [11:52] stub, hi, still running the migration script?. Also... did you execute already on production the "fuzzy" one? [11:52] fuzzy script has run on production. The whitespace one is still running - it died due to a deadlock so I had to restart it this morning. === jayp [n=jp@62.253.252.7] has left #launchpad [] [11:56] stubarooney... we'll need an index on Person.karma [11:57] ok [11:57] carlos: are we converging on good langpacks? [11:58] sabdfl, I think we have more or less a detailed procedure for oo and firefox and the language packs should start flying after the white space migration script is executed on production [11:58] sabdfl, I lost my wiki changes for firefox so I need to write them again today (my x server died before saving the changes :-( [12:00] sabdfl, martin did a lanuage pack update manually this month, so I think we have time enough to test and fix any new issue that would appear before next update + firefox and oo support [12:00] stub, ok [12:03] sabdfl, also, I'm waiting for the whitespace script run on production to send the 1.0 announcement but if you don't want to delay it more... I could send it now that breezy is imported [12:04] sabdfl, I keep forgetting to ask you about it, sorry [12:04] sabdfl, what do you want to do? [12:04] carlos: how long will the whitespace script take to run? [12:05] sabdfl, I think a couple of days or so and we are still testing it on staging [12:05] stub, ^^^ ? [12:06] I have no idea - it produces no useful output as to how much has been processed. If we need this soon, I can add some eta estimation and some optimizations. [12:08] stub, if you don't mind... yes. we need it as soon as possible [12:09] stub, and please, send me the patch so I can see your changes and next scripts I write are more optimized so you don't need to do it === Seveas [n=seveas@seveas.demon.nl] has joined #launchpad === Nafallo loves F/OSS :-) [12:11] carlos: You can have a look at the fuzzy migration script - I added statistics output, optimized memory usage by not loading the list of ids into ram, and made it commit every few thousand transactions instead of after every one (which perhaps halved the runtime all up) === WaterSevenUb [n=WaterSev@bl5-49-34.dsl.telepac.pt] has joined #launchpad [12:11] stub, oh, didn't see that you merged those changes back into rocketfuel.. [12:11] stub, thank you! [12:15] stub: i can add the index to 25-12-0.sql if you want [12:15] I've committed it to a local branch already (which I have been trying to land today ;-/) [12:15] ok [12:16] maybe we need a faster / dedicated box for PQM? [12:16] it's taking at least 30 mins per attempt [12:16] We need less fragile tests :-( [12:17] I'm not sure how fast the tests run on a higher powered box - are they CPU bound? [12:19] cpu and io, chinstrap isn't very fast [12:21] The vmstat output during a test run might be interesting to see. [12:32] spiv: are the page tests run through the debug layer, or not? [12:33] Last I saw they were not [12:34] ok, thanks [12:51] hmm... carlos, did mpt not fix the barchart snafu? [12:55] sabdfl, he had to leave and told me how to fix it, I'm merging all my pending branches before merging that fix [01:30] sabdfl: sorry if my reply to your python-import request sounded like a complaint. I was _a bit_ of a coplaint, but I also wanted to give you an idea of what my queue looked like. [01:31] ok [01:31] i'd really like to coordinate on a week of pair programming with you and i, in london [01:31] could you work with cvd to make sure that happens soon, please? [01:31] I'm working on the python problem in priority. I'm trying to get spiv or jblack to do the NukeChangesetFile thing for me, to unblock importd-archivelocation. [01:31] if lifeless can join, great [01:32] what is importd-archivelocation? spec name or url? [01:33] Hu... I'll check with lifeless, I think I'll be able to come sep. 4/5 to 9. [01:34] sabdfl: neither. ATM the work is being done in the (ill-named) branch david.allouche@canonical.com--2004/launchpad--importd-production--1.26 [01:35] Basically, it's the importd side of ddaa@ddaa.net--2004/pybaz--archivelocation--0 [01:37] which was specced on http://wiki.gnuarch.org/PybazArchiveLocation [01:37] something lifeless has been requesting for a long time, so he can drop the old archive registration scheme from baz. [01:38] Merge to rocketfuel@canonical.com/launchpad--devel--0: Implementation of UpstreamMappingForRoseta r=spiv (patch-2268: carlos.perello@canonical.com) === Kinnison glares at pgsql some more === jamesh glares at gpgme [01:40] ERROR: cannot drop sequence binarypackage_id_seq because table binarypackagerelease column id requires it [01:40] yet [01:41] id | integer | not null default nextval('public.binarypackagerelease_id_seq'::text) [01:41] so wtf does psql think it's in use? [01:41] Because the column was created as a serial, and the two are linked. [01:41] Why do you want to drop it? [01:42] Kinnison: pgsql doesn't use the column default value to track the relationship [01:43] stub: I can't find a way to rename a sequence [01:44] ALTER TABLE binarypackagerelease_id_seq RENAME TO foo_id_seq; [01:44] you're kidding? [01:44] (go figure) === Kinnison groans [01:44] Nope [01:44] does that fix up DEFAULT clauses? [01:45] Nope. Then you need to ALTER TABLE Binarypackagerelease ALTER COLUMN id SET DEFAULT nextval('public.foo_id_se'::text) [01:45] so they are linked, but not in a particularly useful way ;) [01:45] thanks [01:46] it links OIDs, iirc [01:47] good morning hackers [01:47] T-13 minutes to meeting [01:48] kiko, morning [01:49] how's sunny spain? [01:51] not so sunny but hot anyway :-D [01:51] heh [01:53] what's up with production, stub? [01:53] Trying 82.211.81.179... [01:53] telnet: Unable to connect to remote host: No route to host [01:53] hmm... must have died [01:53] or is it my network? [01:54] I'm getting a 503 [01:54] T-5 and counting [01:55] does anyone have topics they'd like discussed in this morning's meeting? === mpt [n=mpt@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [01:57] Hmm... uptime 3 minutes. Don't know if the server crashed or elmo rebooted it. [01:57] elmo? [01:57] hey all [01:57] BjornT: did you have a chance to see the way I reimplemented BugTaskAssigneeWidget? [01:58] I was hoping to submit the merge request before the meeting started... [01:58] T-2 and counting, so that means probably not bradb [01:58] bradb: no sorry, not yet. will do that after the meeting. [01:58] ok, thanks [02:00] and it's time === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [02:00] just in time, too [02:00] === Meeting Begins === [02:00] 1. Role Call [02:00] 2. Activity Reports [02:00] 3. Release Announcements [02:00] 4. 3 Phrases [02:00] if anyone has any topics they'd like discussed, just /msg me [02:01] so who's around and awake? [02:01] me [02:01] me === Kinnison waves blearily [02:01] me [02:01] me === mpt bounces up and down [02:01] me === carlos is here [02:01] yo [02:01] me [02:01] mpt the yoga man [02:01] me [02:02] okidok [02:02] no cprov? [02:02] no daf, but that's understood [02:02] I imagine ddaa should be around === salgado heard somebody on the stairs. maybe was cprov [02:02] maybe [02:02] okay let's move on [02:02] hello [02:02] touching base on activity reports [02:03] who is in the same situation as I am? === carlos is a week behind [02:03] (i.e. really bad this week) === Kinnison is not up-to-date but has them almost ready to send (will send after the meeting) === jamesh is not up to date [02:03] up to date! === morgs is up to date, with days worked === salgado is up to date [02:03] I'm up to date (although my hour tracking has been suboptimal) [02:03] I'm up to date === BjornT is up to date === ddaa is up to date unless he missed a day somewhere === bradb is up to date [02:03] Just need to finish yesterday === Seveas [n=seveas@seveas.demon.nl] has joined #launchpad [02:03] you guys rock [02:03] jamesh and me get the dunce hats [02:03] kiko: slacker :P [02:04] too many distractions :-( [02:04] okay [02:04] on release announcements [02:04] mark wants to get the releases underway === cprov [n=cprov@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === ddaa hears canonical ninjas knocking at the door [02:05] I think it's healthy to get these planned sooner rather than laters [02:05] I think we're probably going to do a launchpad registry 1.0 (foaf and doap) [02:05] a rosetta 1.0 [02:05] and a malone 1.0 [02:05] In that order? [02:05] soyuz 1.0 I'm not so sure of the feasibility in the short term [02:06] well [02:06] kiko, rosetta 1.0 is ready to be sent, just waiting for some data migration [02:06] that's a question for everybody [02:06] kiko: soyuz's UI needs a lot more work as we discovered in SC [02:06] Kinnison, yes, I'm aware [02:06] kiko, I mean, the announcement text is ready [02:06] I know the text is ready [02:06] the baz 1.5 one is ready, but should wait until lifeless is back so that he can actually cut the release. :) [02:06] my question is what's missing for rosetta, carlos [02:06] stub: production now runs the database with the valid_version patch in place, yes? [02:06] and for malone [02:07] Kinnison: yes [02:07] kiko, I'm waiting to have the whitespaces fix run on production [02:07] so we stop exporting broken .po files [02:07] stub: Cool, then we're about 95% of the way to being able to deploy gina for imports on production [02:07] kiko, we still miss basic voting for foaf 1.0 [02:07] carlos, the code is landed, so AFAIK this is just a data migration change, right? [02:07] salgado, how much voting is in place? no UI? [02:07] but we can send the annoucement now if you want as the script will take a couple of days to finish [02:07] kiko, right [02:08] kiko, yes. no UI [02:08] carlos, no, we should run the script -- why haven't we done so yet? [02:08] salgado, I /really/ need us to move into shipit, so voting needs to be done nowish [02:08] Merge to rocketfuel@canonical.com/launchpad--devel--0: Cleanup product's code, start using POTemplate.iscurrent field and fixed POTemplate's admin form. r=spiv (patch-2269: carlos.perello@canonical.com) [02:08] morgs, anything that would bother you before calling it registry 1.0? [02:08] kiko: Including the stuff added in Brazil: 1. making +bugs on distro an untriaged bugs page, 2. menus, 3. distrorelease CVE report, 4. MaloneSearchResults, 5. changing the URLs (again), 6. changing the distrorelease bugs report somewhat. [02:09] kiko: no, RDF seems to be humming along [02:09] kiko, that's what I'm doing [02:09] kiko, because we had some errors and takes a while to execute it on staging [02:09] 7. maybe something else [02:09] kiko, it seems to be fixed now, but still running on staging [02:09] bradb, BjornT: that stack is looking pretty dismal [02:09] carlos/stub, when is the ETA for the script finishing? [02:09] kiko: yep, despite the fact that I've landed a ton of stuff this past week [02:10] kiko, stub is working on getting that information already [02:10] okay [02:10] I've used the word "overloaded" a few times, and will be using it again in my three sentences today. :) [02:10] About 24 hours for the staging run [02:10] bradb, take on them one at a time, I guess [02:10] (assuming no more deadlocks) [02:10] yep, I'm working on MaloneSearchResults right now [02:10] stub, so should be just a bit slower for the production run? [02:10] kiko: "doap" is definitely removed from every place in launchpad now, so please don't refer to it in public emails etc. It's dead, Jim! [02:11] bradb, how much of that is on BjornT's plate? [02:11] morgs, I didn't, did I? [02:11] kiko: Dunnu. Production is slower CPU but more RAM. [02:11] stub, I thought it would be slower just because of more contention [02:11] kiko: dunno, because i don't assign these things. [02:11] but whatever [02:11] kiko: I'm not sure if there any current issues with the display of bazaar branches [02:11] kiko: AFAIK he's been doing email UI, bug attachments. [02:12] bradb, surely you coordinate with BjornT to divide work [02:12] and if you don't, start now [02:12] you guys need to work together, no AFAIKs are justified === stub restarts the migration script on staging, since asuka rebooted too... [02:12] kiko: (14:05:16) kiko: I think we're probably going to do a launchpad registry 1.0 (foaf and doap) [02:12]