[12:11] <mpt> So, which is faster at this poiunt
[12:11] <mpt> nuking and starting again, or some magic?
[12:12] <ddaa> 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] <mpt> -> nuking, then
[12:13] <ddaa> 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] <mpt> ok
[12:14] <mpt> thanks
[12:18] <ddaa> 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] <ddaa> "baz diff --link" speeds up status, diff and commit, library-relink speeds up merges.
[12:19] <ddaa> (of course, you need to be aware of the risks involved with having a hardlinked-to-revlib tree)
[12:19] <mpt> I think that "launchpad" on a line by itself in the RFS instructions actually shouldn't be there
[12:20] <ddaa> you must be a victim of line wrapping
[12:20] <mpt> oh, that was just wrapping
[12:20] <mpt> yeah
[12:21] <ddaa> Maybe add $ signs at the beginning of every shell command
[12:21] <ddaa> I tend to do that to avoid ambiguities, but that screw up copy-pasting
[12:21] <mpt> Yes, and $s are already used in the instructions to represent variables
[12:21] <ddaa> % then
[12:22] <ddaa> Any character commonly used on shell prompts.
[12:53] <mpt> 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] <stub> ddaa: Where is the library-relink script? 
[01:12] <dilys> 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)
[01:54] <Nafallo> carlos: there?
[01:58] <Nafallo> hmm, any other rosetta/gui people? :-)
[01:59] <Nafallo> bye
[01:59] <ddaa> stub: http://mirrors.sourcecontrol.net/aaron.bentley@utoronto.ca--baz/library-relink--devel--1
[01:59] <stub> ta
[02:03] <ddaa> stub: quick sanity check, are you aware of anything (besides taxi) depending on the changesetfile, changesetfilehash and changesetfilename database tables?
[02:05] <stub> ddaa: I don't think so. trebuchet, dyson and sourcerer use changeset, but don't go any further.
[02:05] <ddaa> Good.
[02:06] <ddaa> 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] <ddaa> Mh... maybe I could offload that to somebody.
[02:06] <ddaa> spiv: willing to take a shot at importd?
[02:07] <ddaa> we need an experienced butcher to hack off one of its extraneous limbs.
[02:09] <carlos> Nafallo, I'm here
[02:09] <ddaa> spiv: ping me when you're booted up.
[02:29] <spiv> ddaa: ping
[02:29] <spiv> ddaa: Also, has an importd been hitting Twisted SVN recently?
[02:29] <ddaa> hu... don't think so
[02:29] <ddaa> can hit it pretty easily though
[02:30] <spiv> Heh, no.
[02:30] <ddaa> Ha, yes.
[02:30] <spiv> I have a local dump of the repo on chinstrap for you to play with :P
[02:30] <ddaa> We do not like local dumps.
[02:30] <ddaa> We had problems with them previously.
[02:31] <spiv> 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] <spiv> 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] <ddaa> 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] <spiv> Cool, well, it's broken, so no rush to retry ;)
[02:33] <ddaa> 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] <ddaa> If you think that's important, I can try to setup a test environment here to confirm that would pass.
[02:34] <lifeless> ddaa: twisted import runs out of memory
[02:35] <ddaa> lifeless: you tested it with a local repo?
[02:35] <lifeless> ddaa: nothing to do with inetd, its purely to let us debug the svn problem with zope3 & twisted
[02:35] <lifeless> ddaa: no, but thats the next step. it takes about a day to run out
[02:35] <ddaa> Because the OOM is not apparent in the roomba logs.
[02:35] <lifeless> ddaa: look at the end of the cscvs log
[02:35] <ddaa> pysvn._pysvn.ClientError: Connection closed unexpectedly
[02:35] <lifeless> its just a failure
[02:35] <ddaa> prettyl quickly
[02:35] <lifeless> older events then
[02:36] <lifeless> it *was* running out consistently
[02:36] <ddaa> older than that is OSError: [Errno 31]  Too many links: '/tmp/tmp74F8Ra'
[02:36] <interalia> yeah I noticed cscvs was being used in launchpad... works well?  or a lot of hackery involved?
[02:36] <ddaa> at a point we lost history because the buildbot tap crapped out somehow.
[02:37] <lifeless> ddaa: too many links means /tmp isn't reaping properly
[02:37] <spiv> Yeah, it was definitely OOMing consistently on Twisted.
[02:37] <ddaa> lifeless: old bug, was fixed
[02:37] <lifeless> or, the code I fixed wasn't rolled out
[02:37] <ddaa> you fixed it
[02:37] <ddaa> that's old history
[02:37] <lifeless> oh
[02:37] <lifeless> anyway, breakfast time
[02:37] <lifeless> then I might go for a walk 
[02:37] <ddaa> spiv: anyway, you said you wanted to help with importd, didn't you?
[02:39] <ddaa> (the twisted import will be taken care of at some undeterminate point in the future when mark decided I have enough work)
[02:39] <spiv> ddaa: Well, I want there to be about 99 hours in every day, but sure ;)
[02:40] <ddaa> 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] <spiv> (Anyway, looks like they're about to tweak the inetd conf for Twisted, so that should fix that)
[02:41] <ddaa> spiv: in lib/importd/taxi.py, line 172 you have
[02:41] <ddaa> db_revision.clone_files(revision.iter_files())
[02:41] <ddaa> that stuff uses pybaz.Revision.iter_files, that is not currently working with URL, only registered names.
[02:42] <ddaa> and it's used to populate three tables in the db, that are changesetfile, changesetfilename, and changesetfilehash
[02:42] <ddaa> these tables are cruft, I have a green light from sabdfl for dropping them
[02:43] <ddaa> they contain a lot of data ATM, but not useful data
[02:43] <ddaa> your missing shall you accept it
[02:43] <ddaa> * your mission
[02:43] <ddaa> would be to produce two feature branches
[02:44] <jblack> ddaa: I've gotten my work for the day out of the way. How can I help you? 
[02:44] <ddaa> The first one removes that line, an all the buttress cruft and tests that supports clone_files.
[02:44] <ddaa> That I will rollout to production at my earliest convenience.
[02:44] <ddaa> The second one is a db patch that actually drops the tables.
[02:46] <spiv> You mean clone_files should be removed too?
[02:46] <ddaa> 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.
[02:46] <ddaa> spiv: yes, clone_files and all the supporting code
[02:46] <ddaa> down to sqlobject classes
[02:47] <ddaa> 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] <ddaa> spiv: if you feel too busy, you can try offloading to jblack, who's apparently idle ATM :)
[02:48] <ddaa> spiv: jblack: any questions?
[02:49] <jblack> Nope. Let me chase down the launchpad instructions.
[02:49] <jblack> Actually, is there something else I can do to help? 
[02:49] <spiv> ddaa: I think my first pass will be to offload to jblack :)
[02:50] <jblack> I just remembered that mark told me not long ago that he didn't want me working on launchpad. 
[02:50] <ddaa> jblack: spiv: don't fall over one another rushing to do it :)
[02:50] <jblack> and I don't mean in a "because you have better things to do" way.
[02:51] <jblack> It would probably be ok if I passed the code through one of you though, so that it got an extra review.
[02:51] <spiv> 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] <ddaa> jblack: that's not _really_ launchpad, that's importd, but I guess that's a technicality :)
[02:52] <ddaa> 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] <ddaa> Well, I do not mean to rush anybody...
[02:53] <jblack> Oh, no, I'm offering. :) 
[02:54] <ddaa> Thanks guys.
[02:54] <jblack> We're a team. That's what teams do
[03:00] <jblack> presumably importd is in buildbot...
[03:02] <ddaa> no, it's in launchpad/lib/importd now
[03:02] <ddaa> 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] <jblack> From the way I read this config, its launchpad--devel--0 ? 
[03:04] <jblack> must be. Just a little surprised. 
[03:04] <ddaa> 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] <jblack> Yeah. I'm going through the full build stuff.
[03:05] <ddaa> use it not hardlinked for a little while, to understand the pain
[03:05] <ddaa> that's educative...
[03:05] <jblack> Yeah. I know the pain. I've done this from time to time to keep track
[03:42] <jblack> painnnnn.
[03:43] <jblack> 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] <stub> 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] <stub> Feel free to update the relevant launchpad scripts and the wiki page though ;)
[03:45] <jblack> Sure. Its just fine except for the locale step.
[03:46] <stub> The main issue I'm aware of is the postgres-contrib stuff moving, which breaks the fti.py launchpad script.
[03:46] <jblack> Ohhh. more breakage. 
[03:46] <stub> (but that might have been fixed in breezy - I have no idea)
[03:46] <jblack> I'll run a test on it. Do you know if the tests catch the locale problem? 
[03:47] <stub> What actually is the locale problem?
[03:47] <jblack> On that page, there are instructions to nuke the default database and recreate one with the current required locale. 
[03:48] <stub> ok. if your locale is screwed, the tests will fail. There are explicit tests to check this.
[03:48] <jblack> Perfect.
[03:48] <stub> And you will also get random failures as things are returned in the wrong order elsewhere ;)
[03:49] <jblack> 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] <jblack> I don't have a machine with an older psql, so I can't compare the diffrences to find the perfect match. 
[03:50] <jblack> so I'm idly wondering if perhaps they fixed the locale thing. 
[03:50] <jblack> I also think I'm going to scavange a machine out of my parts. 
[03:50] <stub> Ok. So the instructions should work if you just fix the paths
[03:51] <jblack> Thats the point. :)
[03:51] <jblack> root@comet:/var/lib/postgresql # find . -name data
[03:51] <jblack> root@comet:/var/lib/postgresql #
[03:51] <stub> 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
[03:52] <jblack>  /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] <stub> If it has a 'base' directory in it, it is the data directory.
[03:53] <jblack> It has a base.
[03:53] <jblack> And blowing it away as per those instructions makes bad things happen.
[03:53] <stub> 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] <jblack> I'm not asking for support. I'm just giving you a heads up. :) 
[03:54] <jblack> ddaa: ping
[03:54] <ddaa> here
[03:54] <ddaa> please be quick, I'm on my way to bed
[03:56] <jblack> ok. very quick. can't help you tonight. need to build machine with older ubuntu to help. 
[03:57] <stub> 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] <ddaa> 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] <spiv> stub: 33 or 35 or something... let me find my receipt.
[03:58] <ddaa> I recall 35
[03:59] <spiv> In fact it was 31.45
[09:53] <spiv> lifeless: What's the right thing to do about unicode in http urls?  Just avoid it?
[10:04] <lifeless> spiv: its scheme specific
[10:04] <lifeless> spiv: the serialised url must meet the abnf in std66
[10:04] <spiv> lifeless: rfc 2718 seems to suggest utf-8 encode, then escape as usual.
[10:05] <lifeless> that will probably be correct for url schemes defined post std66
[10:06] <lifeless> which is what 2718 is about
[10:06] <jamesh> 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] <lifeless> jamesh: thats for html url references
[10:07] <jamesh> safest is probably to generate ASCII URIs in launchpad, and expect encoded UTF-8 in the librarian
[10:07] <lifeless> I thought spiv meant in the http protocol
[10:07] <spiv> Right.  This is for the librarian.
[10:08] <spiv> What url should a file named u'Yow\N{INTERROBANG}' be published at in the librarian? :)
[10:08] <lifeless> utf8 then % encode is safe always
[10:08] <spiv> (using python literal notation)
[10:08] <lifeless> urls will always round trip
[10:08] <spiv> That suits me, I'll do that.
[10:08] <spiv> (already coded it, in fact ;0
[10:08] <lifeless> the problem can occur if someone tries to show it nicely.
[10:09] <lifeless> or if someone is trying to guess the url from other data.
[10:09] <spiv> Neither of which are really concerns for the librarian.
[10:09] <lifeless> 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] <lifeless> i.e. I might do latin-1
[10:10] <lifeless> where the server does utf-8 
[10:10] <jamesh> encoded UTF-8 will make the web browsers we care about do the right thing when saving 
[10:10] <lifeless> (both post % encoded.)
[10:10] <spiv> Thankfully, we have strict constraints on names in launchpad.  I think the librarian is fairly unique here among our various systems.
[10:10] <spiv> jamesh: That's good news.
[10:10] <spiv> Ok, thanks to both of you for your help.
[10:11] <lifeless> np
[11:22] <carlos> morning
[11:22] <Nafallo> carlos: morning and ping :-)
[11:23] <Nafallo> carlos: could we have something in rosetta to show those where suggestions are added?
[11:23] <carlos> Nafallo, like show translated, untranslated, needs review, etc...?
[11:24] <Nafallo> 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] <Nafallo> carlos: yepp :-)
[11:25] <carlos> 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] <Nafallo> carlos: sure. I'll assign it to you? :-)
[11:25] <carlos> I cannot implement it now, but that way we will take care of it later
[11:25] <carlos> Nafallo, as you wish :-)
[11:25] <Nafallo> hehe
[11:26] <jayp> 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] <carlos> jayp, packages in main are not yet migrated  to launchpad
[11:27] <carlos> that's all
[11:28] <jayp> carlos, but all ubuntu will go to this launchpad eventually?
[11:28] <carlos> jayp, yes
[11:29] <carlos> I think it will happen with breezy release, perhaps a bit earlier
[11:29] <Nafallo> camilotelles: #1801, I can't assign it to you. missing privilegies :-(
[11:29] <Nafallo> hmm
[11:29] <Nafallo> carlos: ^ ;-)
[11:30] <carlos> Nafallo, don't worry, if it's filed against rosetta, I will take it when I start the implementation.
[11:30] <carlos> thanks
[11:30] <Nafallo> no problem :-)
[11:52] <carlos> stub, hi, still running the migration script?. Also... did you execute already on production the "fuzzy" one?
[11:52] <stub> 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.
[11:56] <sabdfl> stubarooney... we'll need an index on Person.karma
[11:57] <stub> ok
[11:57] <sabdfl> carlos: are we converging on good langpacks?
[11:58] <carlos> 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] <carlos> 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] <carlos> 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] <carlos> stub, ok
[12:03] <carlos> 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] <carlos> sabdfl, I keep forgetting to ask you about it, sorry
[12:04] <carlos> sabdfl, what do you want to do?
[12:04] <sabdfl> carlos: how long will the whitespace script take to run?
[12:05] <carlos> sabdfl, I think a couple of days or so and we are still testing it on staging
[12:05] <carlos> stub, ^^^ ?
[12:06] <stub> 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] <carlos> stub, if you don't mind... yes. we need it as soon as possible
[12:09] <carlos> 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
[12:11] <stub> 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)
[12:11] <carlos> stub, oh, didn't see that you merged those changes back into rocketfuel..
[12:11] <carlos> stub, thank you!
[12:15] <sabdfl> stub: i can add the index to 25-12-0.sql if you want
[12:15] <stub> I've committed it to a local branch already (which I have been trying to land today ;-/)
[12:15] <sabdfl> ok
[12:16] <sabdfl> maybe we need a faster / dedicated box for PQM?
[12:16] <sabdfl> it's taking at least 30 mins per attempt
[12:16] <stub> We need less fragile tests :-(
[12:17] <stub> I'm not sure how fast the tests run on a higher powered box - are they CPU bound?
[12:19] <sabdfl> cpu and io, chinstrap isn't very fast
[12:21] <spiv> The vmstat output during a test run might be interesting to see.
[12:32] <sabdfl> spiv: are the page tests run through the debug layer, or not?
[12:33] <stub> Last I saw they were not
[12:34] <sabdfl> ok, thanks
[12:51] <sabdfl> hmm... carlos, did mpt not fix the barchart snafu?
[12:55] <carlos> 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] <ddaa> 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] <sabdfl> ok
[01:31] <sabdfl> i'd really like to coordinate on a week of pair programming with you and i, in london
[01:31] <sabdfl> could you work with cvd to make sure that happens soon, please?
[01:31] <ddaa> 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] <sabdfl> if lifeless can join, great
[01:32] <sabdfl> what is importd-archivelocation? spec name or url?
[01:33] <ddaa> Hu... I'll check with lifeless, I think I'll be able to come sep. 4/5 to 9.
[01:34] <ddaa> 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] <ddaa> Basically, it's the importd side of ddaa@ddaa.net--2004/pybaz--archivelocation--0
[01:37] <ddaa> which was specced on http://wiki.gnuarch.org/PybazArchiveLocation
[01:37] <ddaa> something lifeless has been requesting for a long time, so he can drop the old archive registration scheme from baz.
[01:38] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Implementation of UpstreamMappingForRoseta r=spiv (patch-2268: carlos.perello@canonical.com)
[01:40] <Kinnison> ERROR:  cannot drop sequence binarypackage_id_seq because table binarypackagerelease column id requires it
[01:40] <Kinnison> yet
[01:41] <Kinnison>  id                   | integer | not null default nextval('public.binarypackagerelease_id_seq'::text)
[01:41] <Kinnison> so wtf does psql think it's in use?
[01:41] <stub> Because the column was created as a serial, and the two are linked.
[01:41] <stub> Why do you want to drop it?
[01:42] <jamesh> Kinnison: pgsql doesn't use the column default value to track the relationship
[01:43] <Kinnison> stub: I can't find a way to rename a sequence
[01:44] <stub> ALTER TABLE binarypackagerelease_id_seq RENAME TO foo_id_seq;
[01:44] <Kinnison> you're kidding?
[01:44] <stub> (go figure)
[01:44] <stub> Nope
[01:44] <Kinnison> does that fix up DEFAULT clauses?
[01:45] <stub> Nope. Then you need to ALTER TABLE Binarypackagerelease ALTER COLUMN id SET DEFAULT nextval('public.foo_id_se'::text)
[01:45] <stub> so they are linked, but not in a particularly useful way ;)
[01:45] <Kinnison> thanks
[01:46] <jamesh> it links OIDs, iirc
[01:47] <kiko-zzz> good morning hackers
[01:47] <kiko> T-13 minutes to meeting
[01:48] <carlos> kiko, morning
[01:49] <kiko> how's sunny spain?
[01:51] <carlos> not so sunny but hot anyway :-D
[01:51] <kiko> heh
[01:53] <kiko> what's up with production, stub?
[01:53] <kiko> Trying 82.211.81.179...
[01:53] <kiko> telnet: Unable to connect to remote host: No route to host
[01:53] <stub> hmm... must have died
[01:53] <kiko> or is it my network?
[01:54] <stub> I'm getting a 503
[01:54] <kiko> T-5 and counting
[01:55] <kiko> does anyone have topics they'd like discussed in this morning's meeting?
[01:57] <stub> Hmm... uptime 3 minutes. Don't know if the server crashed or elmo rebooted it.
[01:57] <kiko> elmo?
[01:57] <bradb> hey all
[01:57] <bradb> BjornT: did you have a chance to see the way I reimplemented BugTaskAssigneeWidget?
[01:58] <bradb> I was hoping to submit the merge request before the meeting started...
[01:58] <kiko> T-2 and counting, so that means probably not bradb 
[01:58] <BjornT> bradb: no sorry, not yet. will do that after the meeting.
[01:58] <bradb> ok, thanks
[02:00] <kiko> and it's time
[02:00] <kiko> just in time, too
[02:00] <kiko> [02:00] <kiko> 1. Role Call
[02:00] <kiko> 2. Activity Reports
[02:00] <kiko> 3. Release Announcements
[02:00] <kiko> 4. 3 Phrases
[02:00] <kiko> if anyone has any topics they'd like discussed, just /msg me
[02:01] <kiko> so who's around and awake?
[02:01] <spiv> me
[02:01] <morgs> me
[02:01] <BjornT> me
[02:01] <jamesh> me
[02:01] <salgado> me
[02:01] <stub> yo
[02:01] <bradb> me
[02:01] <kiko> mpt the yoga man
[02:01] <jblack>  me
[02:02] <kiko> okidok
[02:02] <kiko> no cprov?
[02:02] <kiko> no daf, but that's understood
[02:02] <kiko> I imagine ddaa should be around
[02:02] <kiko> maybe
[02:02] <kiko> okay let's move on
[02:02] <ddaa> hello
[02:02] <kiko> touching base on activity reports
[02:03] <kiko> who is in the same situation as I am?
[02:03] <kiko> (i.e. really bad this week)
[02:03] <mpt> up to date!
[02:03] <spiv> I'm up to date (although my hour tracking has been suboptimal)
[02:03] <stub> I'm up to date
[02:03] <jblack> Just need to finish yesterday
[02:03] <kiko> you guys rock
[02:03] <kiko> jamesh and me get the dunce hats 
[02:03] <spiv> kiko: slacker :P
[02:04] <kiko> too many distractions :-(
[02:04] <kiko> okay
[02:04] <kiko> on release announcements
[02:04] <kiko> mark wants to get the releases underway
[02:05] <kiko> I think it's healthy to get these planned sooner rather than laters
[02:05] <kiko> I think we're probably going to do a launchpad registry 1.0 (foaf and doap)
[02:05] <kiko> a rosetta 1.0
[02:05] <kiko> and a malone 1.0
[02:05] <mpt> In that order?
[02:05] <kiko> soyuz 1.0 I'm not so sure of the feasibility in the short term 
[02:06] <kiko> well
[02:06] <carlos> kiko, rosetta 1.0 is ready to be sent, just waiting for some data migration
[02:06] <kiko> that's a question for everybody
[02:06] <Kinnison> kiko: soyuz's UI needs a lot more work as we discovered in SC
[02:06] <kiko> Kinnison, yes, I'm aware
[02:06] <carlos> kiko, I mean, the announcement text is ready
[02:06] <kiko> I know the text is ready
[02:06] <jblack> the baz 1.5 one is ready, but should wait until lifeless is back so that he can actually cut the release. :)
[02:06] <kiko> my question is what's missing for rosetta, carlos
[02:06] <Kinnison> stub: production now runs the database with the valid_version patch in place, yes?
[02:06] <kiko> and for malone
[02:07] <stub> Kinnison: yes
[02:07] <carlos> kiko, I'm waiting to have the whitespaces fix run on production
[02:07] <carlos> so we stop exporting broken .po files
[02:07] <Kinnison> stub: Cool, then we're about 95% of the way to being able to deploy gina for imports on production
[02:07] <salgado> kiko, we still miss basic voting for foaf 1.0
[02:07] <kiko> carlos, the code is landed, so AFAIK this is just a data migration change, right?
[02:07] <kiko> salgado, how much voting is in place? no UI?
[02:07] <carlos> but we can send the annoucement now if you want as the script will take a couple of days to finish
[02:07] <carlos> kiko, right
[02:08] <salgado> kiko, yes. no UI
[02:08] <kiko> carlos, no, we should run the script -- why haven't we done so yet?
[02:08] <kiko> salgado, I /really/ need us to move into shipit, so voting needs to be done nowish
[02:08] <dilys> 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] <kiko> morgs, anything that would bother you before calling it registry 1.0?
[02:08] <bradb> 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] <morgs> kiko: no, RDF seems to be humming along
[02:09] <salgado> kiko, that's what I'm doing
[02:09] <carlos> kiko, because we had some errors and takes a while to execute it on staging
[02:09] <bradb> 7. maybe something else
[02:09] <carlos> kiko, it seems to be fixed now, but still running on staging
[02:09] <kiko> bradb, BjornT: that stack is looking pretty dismal
[02:09] <kiko> carlos/stub, when is the ETA for the script finishing?
[02:09] <bradb> kiko: yep, despite the fact that I've landed a ton of stuff this past week
[02:10] <carlos> kiko, stub is working on getting that information already 
[02:10] <kiko> okay
[02:10] <bradb> I've used the word "overloaded" a few times, and will be using it again in my three sentences today. :)
[02:10] <stub> About 24 hours for the staging run
[02:10] <kiko> bradb, take on them one at a time, I guess
[02:10] <stub> (assuming no more deadlocks)
[02:10] <bradb> yep, I'm working on MaloneSearchResults right now
[02:10] <kiko> stub, so should be just a bit slower for the production run?
[02:10] <morgs> 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] <kiko> bradb, how much of that is on BjornT's plate?
[02:11] <kiko> morgs, I didn't, did I?
[02:11] <stub> kiko: Dunnu. Production is slower CPU but more RAM.
[02:11] <kiko> stub, I thought it would be slower just because of more contention
[02:11] <bradb> kiko: dunno, because i don't assign these things.
[02:11] <kiko> but whatever
[02:11] <ddaa> kiko: I'm not sure if there any current issues with the display of bazaar branches
[02:11] <bradb> kiko: AFAIK he's been doing email UI, bug attachments.
[02:12] <kiko> bradb, surely you coordinate with BjornT to divide work
[02:12] <kiko> and if you don't, start now
[02:12] <kiko> you guys need to work together, no AFAIKs are justified
[02:12] <morgs> kiko: (14:05:16) kiko: I think we're probably going to do a launchpad registry 1.0 (foaf and doap)
[02:12] <bradb> BjornT: start grabbing dude :)
[02:12] <kiko> bradb, there's more to teamwork than just announcing you have work that others can do.
[02:12] <BjornT> bradb: sure :) let's talk after the meeting to divide the work
[02:13] <kiko> okay
[02:13] <bradb> ok
[02:13] <kiko> the way I see it we should probably do rosetta and registry first,malone next
[02:13] <ddaa> kiko: branch display still sucks donkey balls https://launchpad.net/products/automake
[02:13] <kiko> that's coarse language for 9:13am
[02:14] <mpt> ddaa: That's a one-line fix
[02:14] <ddaa> mpt: thanks for volunteering
[02:14] <mpt> a pleasure
[02:14] <kiko> great
[02:14] <mpt> just as soon as I have a working tree
[02:14] <spiv> ddaa: I believe the correct phrase is "DOIT" :)
[02:14] <mpt> (go baz, go)
[02:15] <kiko> ddaa, if you find any blockers in the next 6 hours, mail the list -- I'm relying on you to tell me that registry is fit for your interpretation of a 1.0
[02:15] <carlos> mpt, I did already the statistics bar fix
[02:15] <kiko> bradb, BjornT: you guys are totally on the hook to get these things either pushed off or finished and landed
[02:15] <mpt> carlos: I didn't see the PQM message for that
[02:15] <carlos> mpt, it's there
[02:15] <mpt> ok, thanks
[02:16] <carlos> mpt, look at the end of the list
[02:16] <carlos> https://chinstrap.ubuntu.com/~dsilvers/pqm.cgi
[02:16] <kiko> carlos, mpt: any further regressions we should be aware of as blocking a 1.0?
[02:16] <ddaa> duh... there's other suckiness left methink. Where is staging?
[02:16] <kiko> carlos, pqm.ubuntu.com
[02:16] <kiko> ddaa, okay, use email
[02:16] <carlos> kiko, oh!, thank you
[02:16] <ddaa> kiko: I will
[02:16] <kiko> clock ticked
[02:16] <kiko> spiv suggested discussing UBZ dates
[02:17] <kiko> I'll talk a bit about UBZ
[02:17] <kiko> we're going to be there for two weeks
[02:17] <jamesh> not 1 week?
[02:17] <kiko> for the first week we're there with the distro team, and our task is to hack changes in for them 
[02:18] <stub> ddaa: staging is back up
[02:18] <kiko> I want the distro team to understand and feel that we work for them
[02:18] <Kinnison> kiko: My grandmother's 90th birthday party is the 22nd and 23rd October
[02:18] <kiko> Kinnison, UBZ will be after that
[02:18] <ddaa> stub: thanks
[02:18] <Kinnison> kiko: Okay, just thought I'd say that I can't fly out of .uk until the 24th at the earliest
[02:19] <kiko> it is most likely that ubz will be first two weeks of november, taking only 2 days of october
[02:19] <stub> I will need to minimize my time there - I was expecting 8 days originally :-(
[02:19] <kiko> stub, you'll have to bring that up with the sab, and you know what I mean
[02:20] <kiko> come on guys, this is 2.5 months advance notice, there's more than enough time to plan and arrange
[02:20] <bradb> i'll supply the bikini-clad girls
[02:20] <kiko> does anyone besides brazilians need visas for canada?
[02:20] <jblack> What dates? 
[02:20] <jamesh> https://wiki.canonical.com/UbuntuDeveloperSummit
[02:20] <kiko> jblack, wake up
[02:20] <Kinnison> kiko: FYI, bits of my year are planned out 12-18 months in advance
[02:20] <jblack> whoops. 
[02:21] <kiko> Kinnison, and then there are the Canonical bits :)
[02:21] <Kinnison> kiko: aye :-)
[02:21] <spiv> kiko: Eh, 2.5 months isn't really that much, particularly when until the dates are set I can't assume that making any personal plans I make are safe. :/
[02:21] <jblack> 30 Oct - 11 Nov ? 
[02:21] <kiko> assume the first two weeks of november
[02:21] <kiko> jblack, don't count on the exact dates (i.e. give or take 2/3 days on each end) but that's the area
[02:22] <stub> kiko: remember that we are currently spending 1 day in 6 overseas - it gets difficult to squeeze in anything else
[02:22] <kiko> don't be anxious, we'll get dates out to each of you early next week
[02:22] <Kinnison> Thanks
[02:22] <kiko> so again
[02:22] <kiko> the plan is to spend one week as hacking serfs for the distro team
[02:22] <kiko> so they feel that they can actually get features coded and landed
[02:23] <kiko> it won't be high-stress -- hopefully -- more like a little fun hacking sprint
[02:23] <Kinnison> That'll be really important for soyuz
[02:23] <morgs> kiko: somebody going to take PQM with to the sprint?
[02:23] <Kinnison> and I'd love for non soyuz hackers to join in on that
[02:23] <kiko> the second week, when we're more or less by ourselves (some distro guys will stay on with us), we'll work on our specs
[02:23] <kiko> morgs, I don't know if that was a real question or not
[02:24] <kiko> stub and I need to figure out what the right approach to updates and QA will be there, since it's a somewhat special case -- what sort of production rollout policy will we use
[02:24] <kiko> anyway
[02:24] <kiko> that's the summary
[02:24] <morgs>  sprint bandwidth tends to suck and there will be contention for PQM - just making an observation
[02:25] <kiko> I hope working with the distro guys will be fun and invigorating -- having users to talk to and satisfy is usually a very positive experience for most 
[02:25] <kiko> morgs, it's canada, so bandwidth should be good, and PQM contention, well, as I said, stub and I will talk about the rollout policy -- so we'll see
[02:25] <bradb> bandwidth should be really good here
[02:25] <kiko> ah
[02:25] <kiko> one final note
[02:26] <kiko> the LTSP guys were having a meeting in maine
[02:26] <kiko> since the dates collided and we really want LTSP to hook up officially with ubuntu
[02:26] <kiko> we've offered them to join conferences
[02:26] <kiko> this means that there will be an extra 15 guys or so for the first week
[02:26] <Kinnison> Should be a really interesting first week
[02:27] <kiko> it's interesting I think because LTSP may give us some derivative-requirements action
[02:27] <Kinnison> indeed
[02:27] <kiko> it'll be fun seeing if they can tackle malone too; I'm not sure how interested they are in rosetta
[02:27] <bradb> i found this: http://www.cic.gc.ca/english/visit/visas.html btw, but it doesn't make a specific mention of the word "business". I notice that Brazil is in the list of countries requiring visa.
[02:27] <kiko> I don't think there's any other UBZ information I know right now
[02:28] <kiko> yeah
[02:28] <kiko> I know brazil needs visas
[02:28] <kiko> I don't know if south africa does
[02:28] <morgs> I think so
[02:28] <kiko> bradb, did you need a visa for anywhere but brazil?
[02:28] <bradb> ZA is listed on that page
[02:29] <bradb> kiko: i imagine so
[02:29] <kiko> chirp chirp
[02:29] <kiko> bradb, /did/ 
[02:29] <kiko> on former conferences
[02:29] <bradb> kiko: oh, but so /far/, no
[02:29] <kiko> okay
[02:29] <kiko> enough of UBZ?
[02:29] <jamesh> I think conferences/meetings count as visiting
[02:30] <carlos> jamesh, visiting like tourist visit ?
[02:30] <kiko> I think so too
[02:30] <bradb> jamesh: i do too :) but i'm not sure if there might be a more strict set of requirement for business visits
[02:30] <kiko> perhaps only in practice
[02:30] <kiko> okay
[02:30] <kiko> time for those 3 phrases of love
[02:30] <kiko> go!
[02:30] <mpt> DONE: Rosetta tweaks, Malone and infrastructure specs
[02:30] <mpt> TODO: unbreak branches, main template crack, TranslationReview
[02:30] <mpt> HINDRANCES: baz crashiness, tiredness, various SteveA magic
[02:31] <spiv> DONE: TeamsInAuthserver, Bug 1785 (+ extra Librarian test coverage), Bug 1659, reviews.
[02:31] <spiv> TODO: Day off tomorrow (Twisted sprint), then TeamLogin & SupermirrorFilesystemHierarchy, try to squeeze in time to help take load off ddaa.  And reviews, as always.
[02:31] <spiv> BLOCKED: No.
[02:31] <Kinnison> DONE: manic database renaming work
[02:31] <Kinnison> TODO: finish rename work
[02:31] <Kinnison> BLOCKED: how long the full test suite takes
[02:31] <jblack> DONE: advocacy, release roadmap
[02:31] <ddaa> DONE: various importd and cscvs cleanups and diagnostics
[02:31] <ddaa> TODO: fix python import, finish importd-archivelocation
[02:31] <ddaa> BLOCKED: NukeChangesetFile (trying to offload)
[02:31] <stub> DONE: Bugfixes
[02:31] <Kinnison> ddaa: "Holy See" == "vatican"
[02:31] <morgs> DONE: Finally get RDF fix into production
[02:31] <morgs> TODO: Clarify tasks and role going forward
[02:31] <morgs> BLOCKED: None
[02:31] <BjornT> DONE: last bits of bug attachment implementation. added some more commands to the email interface and fixed some minor bugs there. work some on threadable emails notification.
[02:31] <jblack> TODO: advocacy, detailed roadmap,supermirror
[02:31] <BjornT> TODO: finish threadable emails notification implementation. reviews. fix email wrapping problem. probably something more, related to malone 1.0
[02:31] <salgado> DONE: BasicVoting, code review, random bug fixes
[02:31] <salgado> TODO: BasicVoting, ShipItNG, code review, random fixes
[02:31] <salgado> BLOCKED: Nothing
[02:31] <BjornT> BLOCKED: no
[02:31] <carlos> DONE: User support, branch merging, language packs
[02:31] <jblack> BLOCKED: no
[02:31] <stub> TODO: linkchecker integration in test suites
[02:31] <stub> BLOCKED: Nope
[02:31] <carlos> TODO: language packs, more branch merges and user support
[02:32] <bradb> DONE: Landed MaloneSourcePackageBugListing. Landed DistroReleaseBugTargeting. PresentingLengthsOfTime (i.e. fmt:approximateduration) on its way to pqm right now. Half way through MaloneSearchResults.
[02:32] <carlos> BLOCKED: Need longer days
[02:32] <bradb> TODO: Finish MaloneSearchResults, land BugTaskAssigneeWidget this morning. Divide up the other work with BjornT, and DO IT.
[02:32] <bradb> BLOCKED: Overloaded. Very, very, overloaded.
[02:32] <kiko> DONE: Brazil Ubuntu/LP promotion, Rosetta POParser study, Malone hacking, planning wiki changes, being distracted
[02:32] <Kinnison> Oh yeah: BLOCKED: baz takes too long to do 'diff' at times
[02:32] <kiko> TODO: wiki migration, roadmaps (including the Bazaar one)
[02:32] <kiko> BLOCKED: SteveA's opinion on some Malone design issues, the usual
[02:32] <cprov> DONE: Bug fixing in GPG and CoC
[02:32] <cprov> TODO: BuilddUI, AutoBuild minor fixes, support also deattached CoC signatures
[02:32] <cprov> BLOCKED: None
[02:32] <Kinnison> kiko: So, the brazil OSS bus looks cool. Did you have a hand in that?
[02:32] <mpt> kiko: "wiki migration"?
[02:33] <kiko> nope, what OSS bus :)
[02:33] <jamesh> DONE: some CalendarAggregation work, some LaunchpadIntegration, pyme key editing support
[02:33] <jamesh> TODO: finish gpg key analyser stuff, CalendarAggregation, code reviews
[02:33] <jamesh> BLOCKED: Steve reviewing my calendar-ui branch
[02:33] <kiko> mpt, did I say wiki migration anywhere?
[02:33] <mpt> kiko: yeah, the "TODO: wiki migration" part
[02:33] <kiko> ah
[02:34] <kiko> that was perhaps wiki roadmap migration
[02:34] <Kinnison> kiko: http://www.ubuntuforums.org/showthread.php?t=56158
[02:34] <cprov> Kinnison: could we talk at ##soyuz ?
[02:35] <kiko> okay
[02:35] <kiko> any parting comments or questions?
[02:35] <mpt> stub: When is the code freeze for the next production rollout?
[02:35] <bradb> kiko: is there a fixed date for Malone 1.0?
[02:36] <stub> I'm thinking tomorrow given the landings that people are pushing through tonight
[02:36] <sabdfl> bradb, bjornt: i'm reworking bounty subscrptions along the lines we discussed for bug subscriptions, if it's useful I'll publish the patch shortly it should be easy to copy for bug subs
[02:36] <kiko> bradb, not yet -- but we need them
[02:36] <kiko> (fixed dates)
[02:37] <stub> Bah - I have all tests bar incomingmail.txt passing in PQM :-/
[02:37] <kiko> I'm going through the stacks
[02:38] <BjornT> stub: hmm, i thought i fixed it :(. could you send me the test failure?
[02:38] <bradb> kiko: so, i imagine that first means that we have to confirm that what we understand to be 1.0 to make sure it lines up with what other people expect for Malone 1.0
[02:38] <kiko> right
[02:38] <kiko> we need to be cheap there though
[02:38] <bradb> when can we do that?
[02:38] <bradb> cheap is good
[02:39] <kiko> bradb, let me go through the wiki and specs 
[02:39] <bradb> ok
[02:39] <kiko> I might fit in some phone calls to triage specs around
[02:39] <kiko> anything else?
[02:39] <kiko> 5
[02:39] <bradb> not all of these things have specs, btw
[02:39] <kiko> bradb, they should have at least stubs or bug #s
[02:39] <kiko> 4
[02:39] <bradb> ok
[02:40] <kiko> 3
[02:40] <kiko> 2
[02:40] <kiko> 1
[02:40] <kiko> thanks guys
[02:40] <carlos> kiko, thanks
[02:40] <bradb> cheers
[02:40] <Kinnison> thanks kiko
[02:40] <Nafallo> kiko: 1.0 in a few days, right? :-)
[02:40] <kiko> Kinnison, carlos and bradb: I'll probably call you today forabout 15 minutes to sort out the spec stacks
[02:41] <Kinnison> kiko: ergh, I've not given them any thought
[02:41] <bradb> ok
[02:41] <carlos> kiko, ok
[02:41] <Kinnison> kiko: so give me 30 mins notice so I can refresh my brain
[02:41] <kiko> bradb, and Kinnison, if you could coordinate to get an idea of the spread of specs
[02:41] <bradb> kiko: i'm populating the wiki with some stubs for the just-do-it bits
[02:41] <kiko> it won't be for at least the next 2h
[02:41] <carlos> kiko, remember that I changed my land phone number 
[02:41] <Kinnison> okay
[02:41] <kiko> carlos, msg me if you like
[02:41] <carlos> kiko, wiki one is the right one
[02:41] <carlos> ok
[03:03] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  add top contributors to home page (patch-2270: mark.shuttleworth@canonical.com)
[03:09] <bradb> kiko: I've added several specs to the wiki that were mentioned for Malone 1.0. Everything that I'm aware of for 1.0 should now be in a spec on the wiki. Once we nail down exactly which specs are mandatory for 1.0, perhaps we can add those to MaloneOneDotZero and divide them up between me and BjornT.
[03:11] <bradb> meantime, shower
[03:12] <elmo> ddaa: I'm upgrading escudero now; it's going to mean some downtime for it's sshd.  if now is a particularly bad time, please shout soon
[03:14] <ddaa> Bah... we have things happening all day long...
[03:14] <elmo> ddaa: ok, I can leave it, if you like
[03:14] <ddaa> elmo: I'll put hoover offline, please tell me when the sshd is back up
[03:15] <ddaa> that sholud minimise disruption and let you do your work.
[03:15] <elmo> ok, thanks
[03:15] <ddaa> lucky, I caught an idle spot :)
[03:16] <ddaa> elmo: btw
[03:17] <ddaa> I know it's bad, evil, etc, but could you _please_ raise the unauth connection limit to, say, 10?
[03:17] <ddaa> Because ATM we do not have a better solution, and hell, that's a dedicated server!
[03:20] <elmo> if you mean maxstartups, it already is 10
[03:20] <elmo> #MaxStartups 10:30:60
[03:20] <elmo> btw, please let me know when hoover is down and I'm good to start
[03:20] <ddaa> It's already offline (that's different from down)
[03:20] <ddaa> that means it won't start any new job.
[03:20] <elmo> ok, thanks
[03:20] <ddaa> I mean somethnig different, lemme check.
[03:22] <ddaa> Ha, right... I mean that, but I mean a different value :)
[03:23] <ddaa> Well, please make it "25:30:60".
[03:23] <ddaa> That should fix my pain for now.
[03:34] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Improvements and added support to select archive components r=spiv (patch-2271: carlos.perello@canonical.com)
[03:42] <sabdfl> morning Keybuk
[03:43] <Keybuk> heyhey, give me half an hour and we'll have that phone chat :)
[03:44] <Keybuk> elmo: prod (re: casey stuff)
[03:49] <Keybuk> sabdfl: batteries seem dead
[03:50] <sabdfl> might need sharpening
[03:50] <sabdfl> i haven't been using it... enough
[04:03] <elmo> ddaa: escudero is back, pls shout if anything is wrong
[04:05] <ddaa> It's asking importd for a password
[04:05] <ddaa> https://macquarie.warthogs.hbd.com/hoover/status/openjade-opensp-main/events/494/log
[04:06] <ddaa> elmo: that _a bit_ too secure.
[04:07] <ddaa> elmo: SHOUT
[04:08] <elmo> cocking badgers
[04:09] <ddaa> I guess that's an ack...
[04:09] <elmo> ddaa: err, hang on, there
[04:09] <elmo> ddaa: err, hang on, there's never been an importd user; it's "hoover" on escudero
[04:10] <kiko> darn
[04:10] <ddaa> elmo: it asks for a password anywoy
[04:10] <ddaa> from galapagos and neumayer
[04:11] <ddaa> (but thanks for reminding me it's hoover@)
[04:11] <elmo> ah, does too
[04:14] <ddaa> darn... lost an autotester
[04:14] <elmo> meep?
[04:14] <ddaa> nevermind, probably just some OOM crash or something
[04:14] <elmo> oh, ok, not hw
[04:14] <elmo> ddaa: pls retry hoover@escudero now
[04:14] <ddaa> it happens from time to time, 
[04:14] <ddaa> workrave
[04:18] <ddaa> hoover@arch.ubuntu.com works
[04:18] <ddaa> thx
[04:18] <ddaa> checking status of autotester now
[04:20] <ddaa> elmo: apparently russkaya and leningradskaya were recently rebooted
[04:21] <ddaa> I'd like if you could drop me a notice when that happens (also true for marambio, neumayer, and galapagos).
[04:23] <elmo> ddaa: yeah, sorry, I only just noticed myself - apparently the electricians we had in managed to knock a power cord or two lose
[04:24] <ddaa> elmo: I'm disappointed, I always thought that your were cybernetically linked to load and status monitor for all your servers.
[04:24] <ddaa> The way high server load seems to give you physical pain...
[04:29] <Keybuk> there are rather a lot of them
[04:29] <Keybuk> have you never had an itch that you've not actually been able to locate?
[04:30] <Keybuk> and had to randomly scratch different bits to try and narrow it down
[04:30] <ddaa> Keybuk: I guess that how an amd64 upload to ftpmaster feels to elmo
[04:34] <ddaa> elmo: pinkfloyd.colorado.edu seems to be unreachable from the DC. I can reach it (and to a svn co) from my laptop.
[04:35] <ddaa> can that be fixed?
[04:35] <ddaa> (if mean the former, I'm happy to reach it from my laptop)
[04:35] <bradb> BjornT: Can I expect to see a response to BugTaskAssigneeWidget in the next hour and a half? Sorry to nag, but I'd really like to land this.
[04:36] <carlos> kiko, we have some 'PartialImplemented' specs, could we add that category?
[04:36] <BjornT> bradb: yeah, i'm looking at it right now
[04:36] <carlos> until we implement those ? 
[04:36] <bradb> cool, thanks
[04:37] <Kinnison> Oh well, I've gone from a couple of test failures to the harness not starting without error
[04:37] <Kinnison> hurrah for fixing bugs
[04:37] <sabdfl> carlos: nup
[04:38] <sabdfl> otherwise everything will end up that way
[04:38] <sabdfl> if the thing needs to be phased, then we need separate specs per phase
[04:38] <sabdfl> done, or not
[04:38] <carlos> I don't think it will happen again, but we have several specs that were half implemented for Hoary support
[04:39] <carlos> and that would help us to track them 
[04:39] <sabdfl> carlos: then they need to be carved to phase2 specs
[04:40] <carlos> instead of just finish the implementation?
[04:49] <sabdfl> either - if it's important to you to reflect the work done, then a second spec, and mark the first one implemented
[04:50] <carlos> It's only a way to track the status, it's not too important
[04:51] <ddaa> elmo: ping
[04:51] <ddaa> From 82.211.81.129 icmp_seq=1 Destination Port Unreachable
[04:52] <Nafallo> hehe, ping and a ping error? ;-)
[04:52] <ddaa> at least somebody gets my humour :)
[04:53] <Nafallo> hehe :-)
[05:00] <elmo> ddaa: ?
[05:01] <ddaa> I cannot seem to ping pinkfloyd.colorado.edu from within the data center, and I cannot do a svn checkout from http://pinkfloyd.colorado.edu:8080/svn/osiris/osiris/trunk
[05:01] <ddaa> The ping error I pasted is the result of "ping pinkfloyd.colorado.edu".
[05:01] <ddaa> from russkaya
[05:02] <ddaa> but I can checkout from my laptop, so I think it might be a network problem with the DC
[05:03] <Keybuk> ddaa: I suspect it's likely an "outbound firewall rules don't let you do that, hahahaha" problem
[05:03] <Keybuk> 8080 isn't in the allowed port list
[05:04] <ddaa> Keybuk: that might be part of the problem. But that does not explain the ping errors...
[05:04] <Keybuk> icmp can be firewalled too
[05:04] <elmo> icmp is firewalled on their end
[05:04] <elmo> (as well as ours)
[05:04] <ddaa> bah
[05:04] <ddaa> okay, ping is dead
[05:04] <ddaa> still, I cannot svn co.
[05:04] <Keybuk> The Ping is Dead!  Long Live the Ping!
[05:05] <elmo> I've added 8080 to the allowed ports for the importd machines
[05:05] <ddaa> elmo: seems to work better
[05:06] <Keybuk> the idea here is that when some pimply 14yo script kiddie hacks our importd machines using carefully crafted cvs or svn packets, and gets root, they still can't do fuck-all with it
[05:06] <Keybuk> except, possibly, read slashdot
[05:07] <ddaa> okay, the test import seems to be going
[05:10] <ddaa> Keybuk: right, right... I can imagine cvs or libsvn getting buffer overflowed by an hostile server.
[05:11] <ddaa> elmo: thanks
[05:13] <ddaa> Just got a phone call from a housing agency, who told me to check their website at "hgiv.fr"... then when I read them the content of the page (that translates to "no website is configured at this address") they told me "www at the beginning, of course, if you don't type the beginning correctly".
[05:14] <elmo> Keybuk: what it is you want from me excactly?  an rsync of archive.u.c ?
[05:14] <elmo> you realize that'll eat a fair whack of your available disk, right?\
[05:24] <Keybuk> is there a way to nfs that?
[05:26] <elmo> mm, I guess, but I don't currently have nfs support enabled in our kernels
[05:27] <Keybuk> how big is the archive at the moment?
[05:27] <bradb> BjornT: Is BasicBugAttachments implemented, or is there more work to do on it to implement it to spec?
[05:28] <elmo> Keybuk: 75Gb
[05:28] <Keybuk> Kinnison: would gina/cap work with a source-only archive?
[05:29] <Kinnison> gina can work source-only, yes
[05:29] <BjornT> bradb: it's implemented
[05:29] <Keybuk> elmo: can you do a source-only archive rsync?
[05:30] <elmo> sure
[05:30] <bradb> BjornT: ok, thanks
[05:31] <Keybuk> that'd be fine; and it can be main-only if possible too ? :p
[05:31] <bradb> BjornT: is CommentBugViaEmail 1. current and 2. implemented?
[05:32] <elmo> sure
[05:32] <Keybuk> ok, if you could stick that as /srv/<something meaningful> that'd be great
[05:32] <Keybuk> also if you could open 4280 to the world, rather than just async, that'd be good.  you can get rid of the hole for dogfood now
[05:34] <elmo> done
[05:34] <BjornT> bradb: 1. yes 2. yes
[05:35] <bradb> thanks
[05:35] <Keybuk> ok, the last thing we need to figure out is
[05:35] <Keybuk> there's going to be a baz archive on casey while distro guys will need to be able to get at
[05:35] <Keybuk> Mark was non-keen on it being HTTP exported
[05:35] <Keybuk> and was heard to mutter something about SFTP
[05:35] <Keybuk> any thoughts?
[05:36] <elmo> spiv has a twisted based sftp server, which we're using for the supermirror, I don't know if it can do anonymous
[05:36] <elmo> I assume mark was muttering about that
[05:37] <Keybuk> that might be useful, I shall talk to him
[05:37] <Keybuk> oh yeah, that rsync'd archive, can you make that get updated daily?
[05:38] <bradb> kiko: how hard would it be to make an rss feed of each wiki application category? (i.e. I want to be able to easily subscribe to the MaloneSpecification RSS feed, so that I can easily bookmark all Malone specs.)
[05:38] <kiko> I have no clue, but I can research
[05:39] <kiko> oh
[05:44] <sabdfl> elmo, keybuk: non-anonymous would be even better
[05:45] <Keybuk> sabdfl: it'd be non-anonymous inherently because you have to go through chinstrap to get there
[05:47] <bradb> BjornT: can you please go through: https://wiki.launchpad.canonical.com/MaloneSpecification and mark any other specs ImplementedSpecification that you've implemented?
[05:50] <elmo> oh, well non-anonymous via chinstrap we can probably do already with 'scponly'
[05:50] <elmo> I assumed tho this was for more than just people with chinstrap access
[05:50] <elmo> Keybuk: /srv/archive.u.c/ubuntu
[05:50] <sabdfl> chinstrap works for me
[05:50] <elmo> lemme know if that's what you need/want and I'll cron it
[05:50] <elmo> (on casey)
[05:51] <bradb> pqm is surrealistically slow this morning
[05:51] <Keybuk> elmo: looks perfect, thanks; cron that once a day
[05:53] <elmo> done
[05:53] <elmo> I'll look at doing the scponly thing when I get home, if that's ok?
[05:53] <Keybuk> one laaaaast thing
[05:53] <Keybuk> an you please copy
[05:53] <Keybuk> emperor:/var/lib/postgres/backups/launchpad_prod.20050816.dump.bz2 or later
[05:53] <Keybuk> onto casey
[05:53] <Keybuk> "You can put it anywhere"
[05:54] <Keybuk> (scponly: yup, that's cool, it'll take a few days to actually populate the archive anyway)
[05:56] <elmo> Keybuk: done to /home/james/
[05:56] <Keybuk> thanks
[05:56] <Keybuk> that's it I think :)
[06:07] <bradb> kiko: btw, I updated the malone specifications (in some cases made small content changes, in other cases status changes). it's just up to BjornT now to update the status of the specs he's worked on.
[06:13] <ddaa> kiko: sent my outsanting registry issues to you, mpt and the launchpad mailing list.
[06:28] <sabdfl> we really need to decide if lp:url is in, or out
[06:32] <BjornT_> bradb, kiko: i've updated the specs i could find, and filed some bugs for some small todos.
[06:32] <bradb> thanks
[06:42] <BjornT_> sabdfl: what is lp:url used (or should be) for?
[06:42] <sabdfl> BjornT_: a long time ago it was a neat idea - to help us produce a listing of all the pages and views we had defined
[06:43] <sabdfl> now we have canonical_url, we could probably do it automatically
[06:43] <sabdfl> i think we should can it
[06:43] <sabdfl> spiv: ?
[06:43] <BjornT_> yeah, i also think we should remove it
[07:01] <Kinnison> can I tell our test runner to stop after the first error?
[07:14] <kiko> thanks BjornT_ 
[07:30] <Kinnison> ciao guys
[07:50] <sabdfl> pqm is wedged, it would seem
[07:54] <sabdfl> salgado: can you unwedge pqm?
[07:54] <sabdfl> lifeless: help ^^
[07:57] <elmo> killed nc
[08:22] <sabdfl> thanks elmo
[08:39] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Applied mpt's fix so the Unchanged statistics bar appears correctly (patch-2272: carlos.perello@canonical.com)
[08:40] <carlos> wow
[08:40] <carlos> pqm took a lot of time to do that merge...
[08:42] <sabdfl> it got wedged
[09:04] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  another go at preventing incomingmail.txt from failing. (patch-2273: bjorn.tillenius@canonical.com)
[09:15] <bradb> BjornT-away: What's the difference between an IBrowserRequest and an IBrowserApplicationRequest?
[09:33] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=spiv]  implement fmt:approximateduration (patch-2274: brad.bollenbach@canonical.com)
[09:34] <BjornT> bradb: i'm not sure really. zope.publisher could probably need some love to make it simpler and easier to understand... or at least some documentation
[10:09] <bradb> BjornT: I followed up to your bugtask widget followup
[10:12] <bradb> salgado: does +packages list both the upstreams and source packages with which a person is associated?
[10:14] <bradb> salgado: i can't figure out anyway to discover that i'm related to Malone, starting from my personal page
[10:16] <bradb> i stumbled onto this problem by trying to find out if David Sugar had registered GNU Telephony in LP. it didn't look so, but as a last-ditch effort, i thought i'd start from his person page and see what's what
[10:23] <cprov> bradb: IIRC that lists only the source packages (by querying the maintainership table)
[10:23] <bradb> that's what i'd expect
[10:32] <kiko> bradb, there's a bug filed on that, ftr
[10:32] <bradb> cool
[10:42] <bradb> BjornT: will you have a chance to look at my followup tonight so that we can bulldoze the assignee widget into rocketfuel?
[10:43] <BjornT> bradb: yes, you'll have mail in 5 minutes. one small issue left, resolve that and you can merge.
[10:45] <bradb> BjornT: thanks
[10:47] <BjornT> bradb: np. email sent.