[12:20] <jordi> LarstiQ: oh well, he's gone
[10:13] <oohlaf> Hi
[10:14] <oohlaf> Launchpad should sync every day it's bzr branch with upstream cvs right?
[10:14] <oohlaf> Or does it take longer?
[10:31] <LarstiQ> jordi: where should he be directed if he wants to talk some more?
[10:32] <LarstiQ> oohlaf: yeah, but there can be kinks in cables
[10:35] <oohlaf> In which timezone does it operate? Yate cvs was updated Mon Mar 13 09:37:56 2006 UTC (24 hours, 19 minutes ago)
[10:35] <oohlaf> Launchpad says Date last sync finished:  2006-03-14
[10:36] <carlos> oohlaf: the servers are on UTC
[10:37] <oohlaf> Maybe add hours to sync finished?
[10:38] <oohlaf> Or sync started, as that would be the time of upstream cvs that is definately included
[10:38] <carlos> oohlaf: where are you looking that date?
[10:39] <oohlaf> https://launchpad.net/products/yate/+series/devel
[10:40] <oohlaf> http://voip.null.ro/cgi-bin/cvsweb.cgi/yate/modules/ysipchan.cpp has the latest upstream revision, but is not in launchpad
[10:42] <carlos> oohlaf: Import status:  Syncing
[10:43] <carlos> oohlaf: it says it's being syncing atm....
[10:44] <oohlaf> Oh, I never saw that status change..everytime I look it says syncing
[10:44] <oohlaf> Or is it really syncing more times a day
[10:45] <carlos> oohlaf: I cannot answer that question, ddaa is your man, but he's busy atm
[10:45] <oohlaf> ok, I'll just wait another couple of hours
[10:46] <oohlaf> enough things to do in the meantime :)
[11:01] <kiko> spiv!
[11:02] <spiv> Me~
[11:03] <spiv> How's your end of the room? ;)
[11:11] <kiko> it is giving me lowercase failures
[11:29] <salgado> stub, around?
[11:29] <kiko> good idea
[11:29] <kiko> where's stub the stud
[11:38] <carlos> spiv: https://launchpad.net/products/bzr/+bug/34166
[11:38] <Ubugtu> malone bug 34166 in bzr "bzr push pushes a nested tree while it didn't in the past" [Normal,Unconfirmed]  
[11:42] <spiv> carlos: thanks
[11:50] <SteveA> stub: ping
[11:58] <seb128> hi
[11:58] <seb128> is anybody working on fixing the build logs page?
[11:58] <kiko> seb128, what's up with that page?
[11:58] <kiko> is there a reported bug? I'm unaware of the issue
[11:58] <seb128> log are 1 month old
[11:58] <kiko> really?
[11:58] <seb128> https://launchpad.net/distros/ubuntu/+builds
[11:58] <seb128> no no, I just come here to make jokes and complain :p
[12:00] <seb128> no, no bug yet, I prefer to ask before filing a bug that's likely to have no reply for some time :)
[12:10] <kiko> stub, ping?
[12:10] <kiko> seb128, I didn't quite get that -- the /logs/ are 1 month old?
[12:10] <kiko> or do you mean there are builds pending for 1 month?
[12:10] <seb128> kiko: no, that page look at the dates listed
[12:11] <kiko> that's because those builds still haven't gone through
[12:11] <kiko> I suspect those builds are superseded
[12:11] <sabdfl> hey lunchpadders
[12:11] <jordi> carlos: what is, briefly, the status of firefox & ooo translationsm for dapper?
[12:11] <sabdfl> how's the sprinting?
[12:11] <kiko> yep
[12:11] <kiko> going well!
[12:12] <jordi> kiko: have you been running?
[12:12] <jordi> don't say yes.
[12:12] <kiko> every day, jordi
[12:12] <jordi> oh man
[12:12] <carlos> jordi: ooo translations are working since breezy (pending to be imported for dapper)
[12:13] <seb128> kiko: how do I see that my GNOME uploads built fine so? And don't tell me to go on 40 differents page for every single package 
[12:13] <carlos> jordi: about firefox... nothing has been done yet after Montreal. Anyway, I guess I will 'fix' that situation during this sprint as it's part of the solid import/exports task
[12:13] <jordi> carlos: what about that bug "untranslated messages are copied in english", is that a non-issue?
[12:13] <jordi> nod
[12:14] <carlos> jordi: as I didn't get any input on that, I don't think it's an issue but a misunderstood of the system
[12:14] <jordi> ok. hopefully
[12:14] <carlos> jordi: are you able to reproduce it?
[12:14] <jordi> carlos: no
[12:14] <jordi> carlos: ah, my other items: any chance you can get ahold of stub today, for both the import fix merge and my akan/breton requests?
[12:15] <kiko> seb128, well, for now, you are better off using https://launchpad.net/distros/ubuntu/+builds?build_state=pending&batch_start=40&batch_end=60
[12:15] <carlos> jordi: import fix merge is not blocked on stub but on weird test failures that we are debugging atm
[12:16] <jordi> oh ok
[12:16] <seb128> kiko: that page has stuff from previous month
[12:16] <kiko> seb128, this is fixed but not rolled out yet -- cprov and Kinnison wrote a new status, SUPERSEDED, that will avoid us trying to rebuild and give-back superseded packages, which is what's causing those first 43 packages to hang around.
[12:16] <carlos> jordi: about the plural forms, yes I will do it today now that our network is stable enough to work
[12:16] <kiko> seb128, those packages are all superseded.
[12:16] <jordi> carlos: I send you my best wishes to get that sorted. :)
[12:16] <seb128> kiko: like is there any way to fail what packages failed to build since yesterday?
[12:16] <jordi> carlos: ok
[12:16] <kiko> seb128, yes, in fact there are
[12:17] <kiko> seb128, https://launchpad.net/distros/ubuntu/+builds?build_state=failed
[12:17] <seb128> s/fail/see
[12:17] <carlos> jordi: well, at least I'm not the only one getting that problem. Kiko got it too with another branch so I'm not alone :-P
[12:17] <seb128> kiko: ah, thank you
[12:17] <seb128> kiko: weird that builds doesn't list them so
[12:18] <seb128> kiko: and is there a way to list by arch? :)
[12:18] <kiko> builds does list them
[12:18] <kiko> you just need to toggle the build state select box
[12:18] <seb128> where is that box?
[12:18] <seb128> ah right
[12:18] <kiko> right
[12:19] <kiko> seb128, there is no way to list by arch. however, there is /people/seb128/+packages which does give you some information, and I've reformatted that page -- it should go live today
[12:19] <seb128> is there any way to sort them by date so?
[12:19] <kiko> in +packages?
[12:19] <seb128> https://launchpad.net/distros/ubuntu/+builds?build_state= list not chronologic stuff
[12:19] <seb128> that's not usable
[12:19] <seb128> like I don't care about stuff one month old
[12:20] <kiko> https://launchpad.net/distros/ubuntu/+builds?build_state=failed is chronological
[12:20] <kiko> the issue with the other listing is that there are packages with builds pending that shouldn't be pending
[12:20] <seb128> ok, that will do for today I guess, thank you
[12:20] <kiko> that will be fixed in the next soyuz rollout
[12:20] <kiko> however
[12:20] <kiko> if you use the link I gave you before:
[12:21] <kiko> https://launchpad.net/distros/ubuntu/+builds?build_state=pending&batch_start=40&batch_end=60
[12:21] <kiko> you'll see any "new" pending builds
[12:21] <seb128> "41   43  of 43 results"
[12:21] <seb128> k, so nothing pending atm?
[12:21] <kiko> seb128, exactly.
[12:21] <seb128> alright
[12:21] <kiko> anything beyond 43 will be pending
[12:21] <kiko> the 43 packages will die
[12:22] <seb128> was not obvious at looking at the page
[12:22] <kiko> they will go to a new SUPERSEDED state
[12:22] <kiko> yes, it's a bug
[12:22] <kiko> they are superseded packages that we keep retrying to build
[12:22] <kiko> which is crack
[12:22] <kiko> they don't need to ever build
[12:22] <seb128> is there a plan to have "build logs for the packages I've uploaded"?
[12:23] <kiko> have you seen https://launchpad.net/people/seb128/+packages --?
[12:23] <kiko> it links to all failed build logs in your uploaded packages
[12:23] <kiko> however, the current organization of the page is suboptimal
[12:23] <kiko> it will be improved in the next rollout, which is scheduled for today, however
[12:25] <anvarprof> hi
[12:25] <anvarprof> is anybody here
[12:25] <seb128> kiko: right, the page is not easy to parse, having a "my uploads which have an issue" page would be nice. Anyway that will be good enough for now, thank you
[12:26] <anvarprof> :(
[12:26] <anvarprof> I need some help...
[12:27] <kiko> seb128, wait till the update -- I think it will give you exactly that information
[12:28] <anvarprof> shit
[12:28] <anvarprof> is anybody here?
[12:28] <seb128> kiko: thank you
[12:29] <anvarprof> can smb help me...
[12:29] <seb128> if you don't ask your question no risk
[12:30] <kiko> that's true
[12:30] <anvarprof> how can I join to Ubuntu translaters group
[12:30] <kiko> talk to jordi anvarprof 
[12:30] <jordi> anvarprof: hello
[12:31] <jordi> anvarprof: what language do you want to work on?
[12:31] <anvarprof> Uzbek
[12:32] <anvarprof> jordi, Is it possible
[12:34] <jordi> anvarprof: give me a minute
[12:35] <anvarprof> ok
[12:35] <jordi> There is no Uzbek team. It seems you'll be a pioneer.
[12:36] <jordi> anvarprof: is it just you, or do you know of more people who want to translate?
[12:36] <anvarprof> jordi, I hope...
[12:36] <anvarprof> I saw it on Launchpad site
[12:36] <jordi> I mean, do you know of more people wanting to translate ubuntu to uzbek right now?
[12:37] <anvarprof> jordi, I'll try to find
[12:37] <anvarprof> jordi righ now? hmm, maybe we can find, but not now
[12:38] <anvarprof> in 2 days it's max
[12:39] <jordi> no, just asking.
[12:39] <jordi> If you want to get started now, I can appoint you as the Uzbek team.
[12:39] <jordi> And when more people join you, you can createa a Ubuntu Uzbek translators team
[12:40] <anvarprof> there is not enough people who knows how to translate it
[12:40] <anvarprof> so 
[12:40] <jordi> you might prefer to search for more people first, or go ahead on your own
[12:40] <jordi> your choice
[12:40] <anvarprof> ok
[12:40] <anvarprof> so I have to register more people on launchpad site?
[12:41] <jordi> any ubuntu  translators needs to have a launchpad account.
[12:41] <jordi> Do you have an account?
[12:41] <anvarprof> yes
[12:41] <anvarprof> I have but my friends haven't
[12:42] <jordi> oh, but your friends will join you in a matter of days, when they get accounts?
[12:42] <jordi> how long will it take for them to get launchpad accounts? If its going to be soon, we might want to wait for them.
[12:43] <anvarprof> they are not here right now
[12:43] <anvarprof> so it is possible in a 2 days
[12:43] <anvarprof> is it possible to open group before and other translators can join later?
[12:44] <jordi> anvarprof: ok. Get them launchpad.net accounts, and create a ubuntu-l10n-uz team.
[12:44] <jordi> yes, if you're absolutely sure they will join you in a few days
[12:44] <jordi> https://launchpad.net/people/+newteam
[12:44] <jordi> you can create a team here.
[12:45] <anvarprof> thanks a lot.
[12:48] <anvarprof> jordi should i create it "open"?
[12:48] <jordi> most of the teams are moderated.
[12:48] <anvarprof> yes
[12:48] <jordi> I advise you moderate it.
[12:49] <anvarprof> but my friends must join my team, so it must be opened?
[12:49] <anvarprof> thanks
[12:49] <jordi> no
[12:49] <jordi> moderated means you'll get a confirmation email whenever someone wants to join
[12:49] <anvarprof> ooh 
[12:49] <jordi> so you'll go into your team page, and accept them on by hand.
[12:49] <anvarprof> thanks a lot
[12:49] <jordi> it's open, but not so open.
[12:49] <anvarprof> ok
[12:50] <anvarprof> jordi, can we talk private
[12:51] <jordi> sure
[01:04] <jordi> hm, launchpad doesn't set a favicon
[01:08] <mpt> yes it does
[01:08] <mpt> <link rel="shortcut icon" href="/@@/launchpad_favicon.png" />, jordi
[01:09] <carlos> jordi: that's your crappy browser :-P
[01:09] <mpt> Though the "shortcut" in that is redundant, since it's noticed only by Internet Explorer for Windows, which doesn't recognize PNG icons anyway
[01:11] <jordi> epiphany is the epiphany
[01:12] <jordi> hmm, lack of ephy extensions...
[01:13] <mpt> jordi, no, if Epiphany is not recognizing *that* kind of icon declaration it's a bug.
[01:13] <carlos> jordi: did you installed the web navigation extension?
[01:13] <carlos> :-P
[01:17] <mvo> G0SUB: jordi told me you are one of the bengali i18n project leaders. there is some discussion about bengali in #ubuntu-l10n
[01:17] <G0SUB> mvo: I am there
[01:17] <carlos> jordi: we already have 12777 entries on the queue... :-(
[01:18] <mvo> G0SUB: thanks!
[01:18] <G0SUB> mvo: heh, soumyadip is my guy ... he went there from #ubuntu-in :)
[01:23] <jordi> carlos: oh great.
[01:23] <jordi> mpt: hm
[01:25] <carlos> jordi: the good news is that today, 1500 entries were imported automatically
[01:26] <jordi> carlos: that's a start :)
[01:32] <mpt> jordi, the Launchpad icon bug is apparently fixed in trunk Epiphany
[01:33] <jordi> mpt: oh I see.
[01:33] <jordi> mpt: did it go in 2.14?
[01:33] <mpt> jordi, sometime between Breezy and Dapper :-)
[01:33] <jordi> ah
[01:33] <jordi> then it's good
[01:39] <stub> So should I do the upgrade now or defer until tomorrow?
[01:39] <kiko> stub, unless the two need to be linked, I'd do the PgSQL 8.1 upgrade today, and then roll out head on thursday
[01:40] <jordi> carlos: https://launchpad.net/people/uzbek
[01:40] <jordi> carlos: I need you to rename this to standard ubuntu-l10n names
[01:40] <kiko> stub, or roll out a previous revision, sorry.
[01:40] <jordi> I told him the exact names, but he didn't follow.
[01:40] <stub> kiko: I need to roll out at least r3243 for PG8.1
[01:41] <carlos> jordi: Remember that I'm not and admin anymore....
[01:41] <carlos> stub: we will need to cherry pick my import queue branch anyway this week if pqm and make check stop breaking the merge...
[01:42] <jordi> carlos: oh, thought you could do that anyway.
[01:42] <carlos> jordi: no, I don't know what's going on with appointing translators, but in the other parts of launchpad, I have the same permissions you have
[01:43] <jordi> ok, so I need stub or SteveA here. https://launchpad.net/people/uzbek <- can you edit to be "ubuntu-l10n-uz" and read "Ubuntu Uzbek Translators"?
[01:43] <jordi> carlos: I still get that perms denied thing.
[01:43] <jordi> are you sure you're only a rosetta-expert?
[01:43] <carlos> jordi: and a launchpad developer
[01:44] <carlos> jordi: that's the only difference
[01:44] <jordi> then there's the bug I guess.
[01:44] <carlos> anyway, I hadn't look at the code to know how is that I have permissions and you don't
[01:44] <carlos> jordi: right
[01:44] <jordi> this should be available to rosetta experts, not developers
[01:44] <stub> jordi: What do you want me to do on that page? I didn't understand your request.
[01:44] <carlos> jordi: I don't remember adding the launchpad developers there
[01:44] <stub> Oh... just change the description
[01:44] <stub> and the name
[01:44] <carlos> stub: go to https://launchpad.net/people/uzbek/+review
[01:45] <carlos> that's it
[01:45] <stub> Shouldn't need +review for that
[01:45] <carlos> stub: I think you need it to rename the team
[01:45] <carlos> stub: only admins can rename people/teams, right?
[01:45] <jordi> stub: yeah, that's it, thanks
[01:46] <stub> All done from +edit
[01:46] <jordi> and now that I've got both of you here, it'd be cool if carlos could give sql magic to stub :)
[01:46] <jordi> stub: thanks dude
[01:47] <carlos> jordi: I don't have it ready, I need to get all information in place...
[01:47] <jordi> I can try to assemble it, and you OK it.
[01:47] <jordi> let me see.
[01:47] <carlos> jordi: sure
[01:47] <carlos> jordi: You have the SQL code that we use to update plural forms
[01:48] <SteveA> stub: ping
[01:49] <stub> SteveA: pong
[01:50] <jordi> yes
[02:02] <jordi> carlos, stub: sent to launchpad@
[02:04] <carlos> jordi: ok, thanks
[02:05] <carlos> jordi: WHERE code IN ('ak', 'br') will need just one line
[02:05] <carlos> stub: r=carlos
[02:06] <carlos> stub: please, execute jordi's SQL commands on production 
[02:06] <kiko> stub, then do them together, I'd say.
[02:06] <jordi> carlos: I'll have that in mind
[02:13] <SteveA> stub: going for lunch now.   can we talk after my lunch about problems getting the test suite to run on bellany, and apparent slowness in the test suite recently?
[02:13] <SteveA> and also about zope3.2 branches?
[02:14] <SteveA> and also about the xmlrpc stuff i'm doing
[03:22] <stub> SteveA: Back?
[03:22] <kiko> stub, yes, we're back -- SteveA's around
[03:26] <carlos> stub: btw, if you do a production rollout, there is already one of my branches merged that needs some data migration
[03:26] <carlos> stub: we already tested it on staging
[03:27] <carlos> stub: how could I note it to you so you don't forget it?
[03:27] <carlos> nothing will break (more than it's already broken) , but we should do it as soon as possible after the code landing so we improve our database content
[03:28] <stub> carlos: Is this carlos-fix-newlines-chars.py ?
[03:28] <carlos> stub: yes
[03:28] <jordi> stub: thanks
[03:28] <stub> carlos: is it to be run just before or after the next rollout?
[03:29] <carlos> stub: the script needs the new code, so I guess after the next rollout
[03:29] <carlos> stub: it doesn't depend on db schema changes
[03:29] <stub> ok. 
[03:30] <carlos> stub: thanks. Remember that the script has a check mode to be sure that the migration was completely done (the -c argument)
[03:34] <jordi> carlos: can you add ubuntu-l10n-br to Ubuntu translators?
[03:34] <kiko> stub, can you do some pqmming for me?
[03:34] <kiko> we're getting an odd failure and we need to get this merged at some point
[03:34] <stub> whussup? Feel like bouncing me the result so I can see?
[03:34] <kiko> stub, yes.
[03:34] <jordi> carlos: again, one person team, but as it's created I don't think it's worth adding him alone
[03:35] <kiko> stub, sent -- it's a test run that takes 3h to run and then fails mysteriously
[03:35] <spiv> kiko: Same error carlos is getting?
[03:36] <kiko> spiv, exact same error. I've bounced to stub
[03:36] <jordi> mpt: ping
[03:37] <stub> kiko: erm.. where is all the output? That pqm response is tiny?
[03:37] <kiko> I'm afraid that's all I got. 
[03:38] <kiko> and carlos' branch has the same failure
[03:38] <kiko> test_on_merge doesn't run with -vv
[03:38] <kiko> and so we don't know where it stopped
[03:38] <kiko> stub, any chance you would like to merge and run that manually?
[03:38] <kiko> it's blocking everybody merging here
[03:39] <stub> test_on_merge used to run with -vv 
[03:39] <kiko> I liked it
[03:39] <stub> Its pretty useless without it
[03:40] <kiko> please re-add it, spiv and I agree
[03:40] <carlos> kiko: I'm waiting much more time than you... my branch should be fixed first... :-P at least before your batch navigation changes ;-)
[03:40] <stub> spiv: I'm going to have to kill your merge
[03:41] <spiv> stub: sure.
[03:41] <stub> Did you know about this yesterday btw? If so, why am I only being told about it now?
[03:42] <spiv> stub: is it possible kiko's test run segfaulted?  does pqm keep corefiles?
[03:42] <carlos> jordi: done
[03:42] <stub> spiv: I have no idea. I know next to nothing about pqm. I just belt it with a hammer occasionally.
[03:42] <kiko> stub, I knew about it since early this morning
[03:42] <carlos> stub: we were debugging it this morning
[03:42] <kiko> I tried to contact you earlier, and SteveA called your sister in .au
[03:43] <stub> Email can be useful.
[03:44] <kiko> good point!
[03:45] <jordi> carlos: cool
[03:47] <kiko> stub, I suck with email when OOO though 
[03:55] <SteveA> hello stub
[03:55] <stub> SteveA: yo
[03:56] <SteveA> stub: various reports of the test suite running extremely slowly, particularly on hardware with less good disk IO
[03:57] <SteveA> maybe since changing to postgres 8.1
[03:57] <kiko> SteveA, no, I'm on 8.0.
[03:57] <kiko> and it is very slow.
[03:57] <stub> I suspect it is since the postgresql session machinery landed
[03:57] <SteveA> also, various problems with the test suite running on balleny, and exiting strangely
[03:57] <stub> This causes the database to be dropped after each story and after each standalone pagetest
[03:57] <spiv> stub: In particular, for carlos it takes about 45 seconds to do the StartStory setup for the page tests.
[03:58] <SteveA> session machinery?
[03:58] <spiv> (on my system, it's more like 8 seconds)
[03:58] <SteveA> as in, web sessions?
[03:59] <stub> SteveA: yes. Although that doesn't have anything to do with StartStory taking 45 seconds. That sounds like a lack of ram, possibly due to 8.1 or possibly due to different default settings with 8.1.
[04:00] <SteveA> i'm wondering whether 8.1 does more sync()ing by default
[04:00] <carlos> stub: 1.5GB of RAM here
[04:00] <SteveA> or something like that
[04:01] <stub> SteveA: Possibly. I don't think createdb performance is something upstream bother to optimize.
[04:01] <stub> In any case, there is nothing we can do about it in the short term except stick with 8.1 on those workstations.
[04:01] <stub> erm... 8.0
[04:02] <kiko> I doubt it's 8.1, again
[04:08] <carlos> kiko: did you timed how many time does it take on your laptop to get the DB SetUp done?
[04:09] <kiko> nope
[04:09] <kiko> it is slow but not 45s
[04:11] <carlos> kiko: that's the point, perhaps with 8.1 it gets worse
[04:12] <stub> Stick an 'import pdb; pdb.set_trace()' in setup routine in test_pages.py and step through it. We will then know what is taking time rather than needing to guess.
[04:16] <carlos> stub: doing it atm...
[04:17] <SteveA> stub: i missed from :
[04:17] <SteveA> SteveA i'm wondering whether 8.1 does more sync()ing by default
[04:17] <SteveA> carlos stub: 1.5GB of RAM here
[04:17] <SteveA> SteveA or something like that
[04:17] <SteveA> * Disconnected ().
[04:17] <SteveA> 
[04:17] <SteveA> kiko is certain that it isn't specific to 8.1, as he sees problems on 8.0
[04:18] <stub> kiko has a different problem
[04:18] <carlos> SteveA: I'm debugging the setup method now to discover where the problem is
[04:18] <mpt> jordi, pong
[04:19] <stub> or at least a scaled down version.
[04:19] <mpt> stub, when you have time, could you query the DB and mail me a list of upstreams that are using Malone?
[04:20] <mpt> (as measured by the "uses Malone" flag)
[04:20] <jordi> mpt: I forgot
[04:20] <jordi> damn, what was it
[04:20] <carlos> stub: FYI, kiko and I have the same computer, the only difference is the amount of memory. He has 512MB and I have 1.5GB. Don't know if that helps
[04:20] <mpt> jordi, it was two minutes after you asked carlos about -br translators
[04:22] <kiko> welll, tbh, I don't care about local test speed right now -- I want PQM!
[04:23] <stub> mpt: https://chinstrap.ubuntu.com/~dsilvers/paste/filevAYwRa.html
[04:24] <stub> carlos: have you stepped through the setup yet?
[04:24] <stub> SteveA: You had other things you wanted to talk about?
[04:24] <carlos> stub: I pressed c instead of n
[04:24] <carlos> sorry...
[04:25] <carlos> LaunchpadFunctionalTestSetup().setUp() is taking most of the time
[04:29] <stub> carlos: I suspect it will actually be PgTestSetup inside there (possibly two more layers down)
[04:29] <carlos> stub: yes, it is
[04:29] <carlos> I'm already there
[04:30] <jordi> mpt: no idea
[04:30] <jordi> mpt: nm :)
[04:32] <carlos> stub: CREATE DATABASE at lib/canonical/ftests/pgsql.py:200 is taking around 30 seconds to be executed
[04:33] <stub> ok. we can't optimize that. If you look at top while that is happening, I think you will find the time is all spend running 'cp'.
[04:34] <carlos> I guess so
[04:34] <carlos> stub: as my hard drive gets crazy while it's being executed
[04:35] <carlos> stub: I get a security warning with make schema and 8.0, that's why I moved to 8.1
[04:35] <stub> carlos: Actually, you might be able to get away with turning fsync off in /etc/postgresql/8.1/main/postgresql.conf. If your laptop powers down unexpectedly you might need to repair your database, but potential dataloss isn't an issue if you are just using PostgreSQL for launchpad development
[04:35] <carlos> stub: do you think if I move back to 8.0 I will be able to develop launchpad or the tree is not working atm with 8.0 ?
[04:36] <carlos> stub: hmm that seems like a good idea...
[04:36] <stub> carlos: Launchpad still works with 8.0 AFIK
[04:37] <carlos> let's try fsync disabled first...
[04:38] <stub> carlos: Make sure you restart PostgreSQL 8.1 after changing the setting
[04:38] <carlos> stub: it's much better now. Only 15 seconds using pdb
[04:39] <stub> carlos: ok. You might want to experiment with just 'cp' on your laptop compared to others. You might have a particularly sucky drive, or some hdparm option needs to be enabled.
[04:39] <carlos> stub: 5 seconds running without pdb
[04:40] <kiko> stub, hdparm doesn't work on our SATA drives
[04:40] <carlos> stub: I have a know issue with hard drive performance
[04:41] <carlos> stub: but it didn't became a big issue until now
[04:41] <carlos> stub: thanks for your help
[04:42] <stub> carlos: feel free to make a note about fsync on the DatabaseSetup wiki page. If your database corrupts (should only be possible if PostgreSQL does not get to shutdown cleanly), recreating the cluster as per that wikipage will get you going again.
[04:43] <carlos> stub: ok
[04:46] <carlos> stub: that would speed up pqm.. I suppose it depends on the way pqm setups the database....
[04:47] <stub> same same.
[04:47] <carlos> so if balleny goes down, pqm gets stalled...
[04:48] <Seveas> Does anyone know when the LP maintenance will be?
[04:52] <mpt> stub, thanks
[04:52] <stub> Seveas: not yet. Any opinions?
[04:53] <stub> carlos: maybe not. PostgreSQL is pretty good at recovering from stuff like that. But it becomes a possibility.
[04:54] <carlos> stub: I would say... let's test it and revert it if we have problems...
[04:54] <Seveas> stub, 2nd dapper meeting is at 18:00 UTC, I'd prefer after that meeting
[04:54] <Seveas> the wiki wa used briefly during the first meeting
[04:54] <stub> Seveas: yup. it won't be today anyway, so no probs.
[04:55] <Seveas> great
[04:55] <Seveas> thanks for taking this into account 
[04:56] <carlos> Seveas: I guess that was a chinese or japanese character, right? It's a wonderful way to do smiles :-P
[04:56] <Seveas> hehe
[04:57] <carlos> stub: can I resubmit my merge request? or should I wait?
[04:57] <stub> carlos: Resubmit away. Might as well get it in the queue.
[05:00] <carlos> stub: done.
[05:06] <stub> kiko: https://chinstrap.ubuntu.com/~dsilvers/paste/fileOGGWrS.html
[05:07] <kiko> stub, I have never seen that before -- is something wrong in the database setup on balleny?
[05:07] <stub> I don't think so. Never seen what?
[05:07] <kiko>     ProgrammingError: ERROR:  permission denied for sequence distroreleasepackagecache_id_seq
[05:08] <kiko> stub, which tree is this? and could you add -vv to test_on_merge?
[05:08] <stub> Something is trying to insert into that table. Which is bad, because the only thing with permission to insert into that table is the statistician.
[05:09] <kiko>     warty.updateCompletePackageCache()
[05:09] <kiko> are you sure about that?
[05:09] <stub> Check security.cfg
[05:10] <stub> What is odd is that the test succeeded at all
[05:10] <kiko> and the other one succeeded as well
[05:10] <kiko> and is now failing
[05:10] <kiko> in all trees
[05:11] <stub> That wasn't the first failure anyway
[05:12] <stub> I suspect that call to updateCompletePackageCache has been succeeding because nothing has actually needed to be done before. But now perhaps it is being victimized by an earlier test.
[05:13] <kiko> yes, that may be possible.
[05:13] <kiko> stub, and so carlos' branch is also failing on a test?
[05:13] <stub> No idea - haven't looked at carlos' branch
[05:13] <carlos> kiko: mine, and mpt's one and spiv's one
[05:13] <kiko> heh
[05:15] <kiko> so it appears that make check is not outputting errors at all 
[05:16] <stub> I'm removing that test anyway - it is pointless (the method is called, but results are not checked. We do more testing of that method in the statistician tests)
[05:17] <kiko> stub, I think the failures there are a red herring
[05:17] <kiko> spiv is pointing out correctly that the tests didn't finish running when being run via pqm
[05:17] <kiko> stub, have you added the -vv flag to the test invocation in PQM?
[05:18] <kiko> oh, sorry, just saw it.
[05:18] <stub> kiko: It will land in my merge, which is first in the queue
[05:18] <stub> kiko: Looks like the earlier test may be relying on ids being the same each run, which we can't actually do.
[05:19] <stub> (or can we? I can't remember if we are resetting sequence id numbers even when we don't destroy the database)
[05:19] <kiko> stub, the earlier test is actually right in failing, because I had added sampledata
[05:19] <stub> kiko: ok.
[05:20] <kiko> stub, if you like I can fix the latter test as well, or, well, you say you have, right?
[05:20] <stub> kiko: I'm just committing and will land it with my merge
[05:22] <carlos> stub: I suppose that means that all merge request will fail until your new branch gets merged, right?
[05:22] <kiko> okay, perfect.
[05:22] <stub> carlos: mine is at the front of the queue
[05:22] <kiko> possibly already merging
[05:22] <stub> nope
[05:22] <stub> pqm is still disabled
[05:22] <kiko> oh you pqm haxor
[05:22] <stub> (from me running your tests)
[05:22] <carlos> stub: I'm talking about the test that you are disabling
[05:22] <carlos> ooh, I see
[05:23] <carlos> stub: dude, you are the king of the cheaters....
[05:23] <carlos> When I grow, I want to be like stub :-P
[05:23] <kiko> every day I wish I was stub at least once
[05:23] <stub> None of you have the follicles for it
[05:24] <kiko> I am working on it
[05:24] <bradb> There's been some follicle follies at this sprint
[05:27] <mpt> Now I remember why I stayed off IRC yesterday :-P
[05:28] <kiko> mpt, because the network was down?
[05:30] <mpt> well, that was one reason
[05:33] <carlos> stub: fsync option added to the wiki
[05:49] <dilys> Merge to devel/launchpad/: [trivial]  test_on_merge.py needs to issue verbose output (r3259: Stuart Bishop)
[05:50] <kiko> thanks stub 
[05:50] <kiko> now for carlos' wait
[05:50] <cprov> stub:  I have a DB patch almost ready, please don't go before look on it, okay ?
[05:51] <stub> Better hurry. It is almost midnight and I might turn into a pumpkin.
[05:53] <carlos> stub: If my merge request works now... I will need it cherry picked
[05:53] <cprov> stub: ehe, sure
[05:53] <carlos> stub: I will send you the details by email to do it tomorrow, don't worry
[05:53] <stub> carlos: Ta
[05:53] <carlos> stub: or well, if you do a production rollout... the cherry pick will not be needed
[05:53] <cprov> stub: bzr push, must work faster here 
[05:54] <carlos> cprov: I think it's my fault... I'm pushing a new branch....
[05:54] <stub> carlos: I'd rather not rollout head
[05:55] <carlos> stub: ok
[05:55] <carlos> stub: kiko asks 'Why not?'
[05:55] <stub> ok. my merge is through. All subsequent merges should get -vv output on failures (unless there is too much output and mailservers refuse the emails...)
[05:56] <carlos> stub: thanks for that
[05:56] <stub> Because most of the time when we rollout head we find nasty bugs that need fixes made and cherry picked in a hurry.
[05:57] <carlos> ok
[06:03] <cprov> stub: it's in PendingReviews, cprov/launchpad/small-fixes, new PPA tables and constraints fixes, patch 98 & 99
[06:07] <carlos> why do we keep getting pyme with rocketfuel-get?
[06:08] <carlos> shouldn't it be removed from the rocketfuel mirror?
[06:11] <jamesh> carlos: I thought I submitted a dists merge to fix that, but I might have forgot
[06:13] <mdz> carlos: your branch landed OK?
[06:15] <carlos> mdz: I guess it didn't as dilys didn't say anything....
[06:16] <mdz> saw it in PQM before and gone now
[06:17] <carlos> mdz: it failed
[06:17] <kiko> jamesh, you didn't then
[06:18] <carlos> mdz: I don't understand why, but seems like a change that is not yet merged affected it :-?
[06:18] <carlos> kiko: dude, I hate your branch!
[06:18] <mdz> carlos: nooooooo
[06:19] <carlos> mdz: at least I get an error now...
[06:19] <carlos> mdz: so I hope it will be merged today
[06:24] <carlos> kiko: ok, It's my fault. Seems like I did a change after the test system started to be completely fucked and thus it was not detected....
[06:25] <jamesh> kiko: I did
[06:25] <kiko> mmm
[06:25] <jamesh> kiko: the problem is that config-manager uses the working tree on chinstrap to build rocketfuel-built
[06:26] <kiko> ah
[06:26] <kiko> that is no good
[06:26] <jamesh> kiko: but when pqm does a merge and push to chinstrap, it just updates the .bzr directory, leaving the working tree as is
[06:27] <Kinnison> So we just need to do a bzr revert in the tree before invoking cm?
[06:28] <jamesh> yeah
[06:28] <jamesh> or checkout the dists tree and work from that
[06:29] <jbailey> Hey'all.
[06:29] <kiko> yo jeff
[06:29] <jbailey> mvo and I are looking at https://launchpad.net/+builds/+build/174707
[06:29] <jamesh> it'd probably be a good idea to get rid of the stale working trees for stuff under /home/warthogs/archives/rocketfuel/
[06:29] <jbailey> I don't see the updated python-vte in breezy-updates for amd64, even though it was built on the 20th.
[06:29] <carlos> jordi: hi, around?
[06:31] <mvo> we are wondering where the python-vte package from that build ended up
[06:31] <mvo> it seems to be not in the archive
[06:32] <kiko> Kinnison, can you take a look at that for us please?
[06:34] <jordi> carlos: yes
[06:35] <carlos> jordi: I told mark about your idea of coming here to work on dappers imports approval
[06:35] <carlos> jordi: he said it's a good idea
[06:35] <jordi> aha
[06:35] <jordi> which day?
[06:36] <carlos> jordi: so I guess if we get my branch merged today, and stub merges it into production tomorrow you could come when you get some free time at the l10n sprint
[06:36] <carlos> jordi: I will confirm If I get my branch merged today
[06:36] <mvo> it's very odd, because the python-vte package is build fine in the buildlog 
[06:41] <jordi> carlos: ok
[06:42] <Kinnison> Okay, so the queue indicates that it's all done
[06:43] <Kinnison> And a quick locate indicates it's in universe
[06:43] <Kinnison> mvo: /srv/launchpad.net/ubuntu-archive/ubuntu/pool/universe/v/vte/python-vte_0.11.15-0ubuntu3_amd64.deb
[06:43] <mvo> Kinnison: thanks. 
[06:44] <Kinnison> mvo: Can you guys check universe before asking in future?
[06:44] <Kinnison> this is about the fourth one of these "Oh my god, where is it?!?!?!?!?!?!" alerts I've investigated and they've all resolved as "it's in universe, ya daft git"
[06:44] <Kinnison> :-)
[06:44] <mvo> Kinnison: I'm very sorry, it is in main in dapper, that caused my cofusion
[06:44] <Kinnison> mvo: s'okay
[06:44] <Kinnison> :-)
[06:46] <mvo> jbailey: hm, this is a problem for the dist-upgrader :/ let's continue talking about this in ubuntu-devel
[06:48] <Kinnison> mvo: We should sort out signing the dist-upgrader tarballs
[06:48] <cprov> Kinnison: good point
[06:48] <jbailey> Kinnison: Since we had made it this far.  I'm wondering if there's a reasonable way to make it clear on this screen that things went to universe.
[06:48] <mvo> Kinnison: yes!
[06:49] <Kinnison> jbailey: "this screen" ?
[06:49] <jbailey> Like, if it's a common question, perhaps we should solve it a different way.
[06:49] <Kinnison> mvo: What do you want signed and where do you want the sigs?
 mvo and I are looking at https://launchpad.net/+builds/+build/174707
[06:49] <jbailey> Kinnison: The resulting binaries are listed to the right.  Perhaps they should have the component listed next to the name in () or something?
[06:50] <Kinnison> jbailey: If you think it needs to be on the build page too, please file a bug
[06:50] <jbailey> Kinnison: I'm hoping for an opinion before I randomly file a bug.
[06:51] <jbailey> mvo: Do you think that would've helped you?
[06:53] <jamesh> mvo: make your browser window wider
[06:53] <Kinnison> :-)
[06:53] <jamesh> content area overlapping with portlets
[06:53] <mvo> jamesh: it's about as width now as my screen can do
[06:53] <jamesh> because of long "build log" url
[06:54] <mvo> if I make it insanely wide (1.5 times my screen) it works
[06:54] <Kinnison> Hmm, perhaps we need to make _s breakable in librarian links
[06:54] <Kinnison> mvo: What size is your screen?
[06:54] <jamesh> mvo: on my computer, the "python-vte ..." link is clickable past the end of the build log URL
[06:54] <mvo> 1024x768 (epiphany)
[06:54] <Kinnison> Do you have insanely huge fonts or something?
[06:55] <jbailey> By "insanely huge", you mean readable ;)
[06:55] <jbailey> But widescreen.  So not an issue here for that problem.
[06:55] <Kinnison> jbailey: do you have your DPI set properly?
[06:55] <jbailey> Kinnison: YEs.  I keep larger fonts so that I don't have to wear reading glasses.
[06:56] <Kinnison> jbailey: heh
[06:56] <jbailey> I'm *old*, remember?
[06:56] <Kinnison> I guess.
[06:56] <jbailey> ;P
[06:56] <mvo> Kinnison: well, if 12pt is  "insanely huge" then yes :P
[06:56] <jamesh> jbailey: maybe you could get laser eye surgery.  Then you could use smaller fonts
[06:56] <Kinnison> zzzzzzzzzzzzap!
[06:56] <jbailey> jamesh: My wife got that done.  She went from -9, -9.5 diopters with an astigmatism in each eye to 20/20
[06:57] <Kinnison> crikey, that was effective
[06:57] <jbailey> jamesh: Mostly my problem is eye strain caused by staring at screens too long and bad florescent lights.
[06:57] <jbailey> jamesh: The simpler solution is to reduce the eye strain. =)
[06:57] <jbailey> (Where too long is.  mm.. 27 years.)
[06:57] <jamesh> jbailey: I'm sure they've got lasers that can fix that these days
[06:58] <jbailey> jamesh: The green ones.  Full intensity.  Never have to worry about eye strain again ;)
[06:58] <jbailey> jamesh: Seriously, I could probably get the -1 corrected, but it doesn't make sense.  I'll wait another 10 years.  My father's vision started to degrade around then, and see if I can get something done.
[06:59] <jbailey> In the meantime, large fonts make for interesting accessibility testing.
[06:59] <jamesh> jbailey: if you want to have fun testing accessibility, find the bsod gnome theme
[06:59] <jamesh> it makes things blue
[07:06] <dilys> Merge to devel/launchpad/: [trivial]  Fix backwards logic in test suite hang detection in test_on_merge.py. (r3260: Andrew Bennetts)
[07:06] <kiko> woohoo!
[07:29] <dilys> Merge to devel/launchpad/: [trivial]  Fix bug 36208: DistroArchReleaseBinaryPackageRelease traversal fails for non-published releases. Allow traversing on DARBRP entries with any status. Also fixes bug 32605: BPPH listing assumes context has been superseded. Fixes this crasher by correctly interpreting data indicating a removal request (r3261: Christian Reis)
[07:52] <dilys> Merge to devel/launchpad/: [r=salgado]  Fixes bug 3002(Malone messes up comment formatting). (r3262: Matthew Paul Thomas)
[07:57] <carlos> jordi: dude, cross your fingers, the import queue fix is the next one on the queue
[07:57] <jordi> hehe
[07:57] <jordi> go dilys 
[08:00] <carlos> jordi: no, go pqm!
[08:01] <jordi> dilys is the messenger.
[08:01] <jordi> if it doesn't go well, we kill dilys
[08:02] <carlos> jordi: also, BjornT just told me how to prefill the forms so it would simplify our work, I will try to have it implemented and reviewed tomorrow
[08:02] <jordi> oh man that's good news for tomorrow
[08:02] <jordi> actually I think that we should get started on that after that's in
[08:02] <jordi> it will make our time a lot more productive
[08:04] <carlos> jordi: I know
[08:04] <carlos> jordi: that's why I'm going to concentrate on it as next task
[08:05] <jordi> cool
[08:15] <dilys> Merge to devel/launchpad/: [r=BjornT]  Import queue reimplementation and many export fixes to close bug #33020. It adds -vv to the test run to debug the problems I'm having to merge this branch (r3263: Carlos Perello Marin)
[08:15] <daf> wooooooooo!
[08:15] <carlos> jordi: you see that???
[08:15] <carlos> finally!
[08:15] <daf> \o/
[08:15] <carlos> mdz: it's done
[08:16] <daf> mdz has left the building
[08:16] <carlos> wrong comment... but finally, it's merged
[08:16] <Martolod> thanks jordi :D
[08:20] <jordi> Martolod: np! :)
[09:02] <jordi> carlos: so, neewd to decide if tomorrow or later
[09:03] <jordi> if that feature will be in on thursday, it might be worth
[09:03] <jordi> waiting
[09:03] <jordi> we gotta go
[09:03] <jordi> laters
[11:31] <carlos> jordi: dude, Akan plural form information was already in our database....
[11:37] <jordi> carlos: it didn't work, for some reason
[11:37] <jordi> I was getting oopses when trying to translate to ak
[11:37] <carlos> jordi: are you sure it didn't work for ak instead of ak_IN?
[11:37] <carlos> jordi: dude, an opps doesn't mean we are missing the plural forms
[11:38] <carlos> that's a bug
[11:38] <carlos> not missing information...
[11:40] <jordi> carlos: try translating to "co"
[11:40] <jordi> https://launchpad.net/products/xqf/+series/main/+pots/xqf/br/+translate
[11:40] <jordi> this was oopsing hours ago
[11:40] <jordi> not now
[11:40] <jordi> https://launchpad.net/products/xqf/+series/main/+pots/xqf/co/+translate
[11:41] <jordi> try that
[11:41] <jordi> no plural forms, oopses
[11:41] <carlos> jordi: ok, the problem was that with the rename of ak to akk the plural form was also moved....
[11:42] <carlos> jordi: I see, I didn't know that bug was produced just loading the page
[11:42] <jordi> i can file a bug
[11:42] <jordi> I found out these days :)
[11:43] <carlos> jordi: we have a bug already for that bug
[11:43] <carlos> hmmm
[11:43] <carlos> change the first 'bug' with 'report'
[11:43] <jordi> oh
[11:43] <jordi> right
[11:43] <jordi> ok