[00:11] nigelb: Are you sure that branch fixes it completely? [00:11] nigelb: If you're not pretty sure that's enough to totally fix it, we need to revert your revision. [00:11] wgrant: as embarassing as it sounds, yes. [00:11] I added tests [00:11] *more* tests [00:13] wgrant: Is there more I could do to actually prove it works? [00:13] Is there a test server I could push to? [00:13] without getting it committed that is. [00:14] I'll try merging it on DF. [00:15] DF? [00:15] dogfood.launchpad.net [00:15] Normally used for Soyuz testing. [00:15] Can I visit it? [00:16] i.e., can people not in ~launchpad visit it. [00:16] yes. [00:16] Ok, if you can get it running there, that'd be great. [00:16] Although it's very slow, as everything including the database runs on a machine from 2004. [00:17] I just need to load a bug. [00:18] wow, OOOPs all over the place. [00:21] Ah, yeah, loooks like we might have issues with testing this on DF. [00:21] Because its database is old. [00:21] And doesn't have BugMessage.owner set. [00:22] ah [00:22] argh [00:22] let me try something [00:23] So, I think I need to roll this back, and perhaps you can ask a LOSA to merge it temporarily on (qa)staging next week. [00:23] So you can test it out. [00:24] Is it possible to do a merge on DF? [00:24] i.e. code merge [00:24] Yes, but its DF is crap so that won't be much use. [00:24] Er. [00:24] \o/ [00:24] s/DF/DB/ [00:24] Okay, so I can see a merge [00:25] If you can push the code, I can test it in an MP as well. [00:25] You'll have to create a new MP. [00:25] I created one [00:25] https://code.dogfood.launchpad.net/~summit-hackers/summit/i18n/+merge/60007 [00:27] JS should be updated [00:29] Code's still old. [00:29] Which code? [00:29] linkchecker.py needs to be updated as well [00:30] Hmm, but it should already be running the latest devel revision... [00:30] Its r13954 [00:30] While qastaging is r13978 [00:30] Well, it says that, but it often lies. [00:30] Let's see. [00:31] I know that linkchecker.py doesn't contain my changes, because I'm getting what used to happen earlier. [00:32] I'm guessing you just brought it down [00:33] It's restarting. [00:33] Slowly. [00:33] And it's back. [00:33] Hopefully with the new Python code this time. [00:33] * nigelb does hard refresh [00:35] wgrant: \o/ [00:35] Seems to work! [00:36] Do you have a bug that would be interesting to test? I can fix particular bugs to render on DF> [00:36] one sec [00:37] let me see the one we were testing on qastaging [00:38] bug 755937 [00:38] <_mup_> Bug #755937: phaseshift version 0.40-13.2 failed to build on i386 < https://launchpad.net/bugs/755937 > [00:38] could you fix that on DF? [00:38] It renders now. [00:40] Trying to duplicate [00:41] Gah. [00:41] I'm awesome [00:41] Oh? [00:41] I made the qastaging bug render :p [00:41] Heh [00:41] Now I can't use that to compare [00:42] Works as expected in dogfood. [00:42] let me violate another qastaging bug :P [00:43] ZOMG. [00:43] QAstating did *not* timeout on me. [00:43] This needs celebration. [00:43] (spoke to soon. Damn) [00:49] wgrant: Seems to work like it should [00:52] * wgrant lands. [00:52] wgrant: Sorry about the mess :) [00:52] I think I've made a whole lot of revisions undeployable [00:53] Indeed, but it's by no means the worst we've had recently :) [00:53] HA [00:53] I'm really glad I invested in the time to write javascript tests [00:53] I would never have fixed this on time without those [00:54] Yes, tests are handy :) [00:54] nigelb: Could you set a commit message? [00:54] yeah, sec [00:55] wgrant: done [01:00] wgrant: Oh. No test run? [01:00] nigelb: No point. It's a weekend, and the deployment pipeline is blocked until this is fixed anyway. [01:01] \o/ [01:01] Plus it's a safe change. [01:01] Right. You just ran it in dogfood and I didn't bring it down :-) [01:04] Project devel build #1,083: STILL FAILING in 36 sec: https://lpci.wedontsleep.org/job/devel/1083/ [01:06] ^ Didn't even start [01:16] Project devel build #1,084: STILL FAILING in 1.7 sec: https://lpci.wedontsleep.org/job/devel/1084/ === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [01:31] Project devel build #1,085: STILL FAILING in 1.8 sec: https://lpci.wedontsleep.org/job/devel/1085/ [01:46] Project devel build #1,086: STILL FAILING in 1.7 sec: https://lpci.wedontsleep.org/job/devel/1086/ [02:01] Project devel build #1,087: STILL FAILING in 1.7 sec: https://lpci.wedontsleep.org/job/devel/1087/ [02:16] Project devel build #1,088: STILL FAILING in 1.8 sec: https://lpci.wedontsleep.org/job/devel/1088/ [02:31] Project devel build #1,089: STILL FAILING in 1.7 sec: https://lpci.wedontsleep.org/job/devel/1089/ [02:46] Project devel build #1,090: STILL FAILING in 1.7 sec: https://lpci.wedontsleep.org/job/devel/1090/ [04:54] cjwatson: Is remove-package.py used at all these days? It was superseded by lp-remove-package.py years ago, but never deleted... [05:12] I can not recall remove-package being used while I've been an AA [05:13] I'm waiting for mawson to tell me if anyone has. [05:13] It imports dak_utils for crying out loud [05:13] The last source it was used on was in 2007... binaries I'm still waiting for. [05:13] Yep. [05:13] But then again so does sync-source... [05:13] steven@liquified:~/launchpad/lp-branches/devel% grep -c '^#' scripts/ftpmaster-tools/remove-package.py [05:13] 145 [05:13] But that can hopefully die soon. [05:13] Yes. [05:13] There's a revdep check all commented out in there :/ [05:14] Yes. [05:14] Because removing code is hard, or something. [05:14] An XXX from elmo. Neat. [05:15] That is disgusting, kill it. [05:15] It's already gone. [05:16] Just wanting confirmation. [05:19] * StevenK stares at scripts/_ginalog.py [05:20] Yes, pretty much. [05:20] But it doesn't use initZopeless, so this branch won't delete it. [05:20] Oh, nice, you're killing it already? [05:20] Well, porting most scripts that use it directly to use LaunchpadScript instead. [05:21] And deleting lots of scripts that use it but don't work any more. [05:21] Does that mean canonical.lp dies? [05:21] Hopefully in the next couple of days. [05:21] Still a little bit to go. [05:24] Hmm, untested script written in 2006 and unchanged since then except for compatibility fixes. [05:24] I think it can die. [05:33] Which one? [05:34] scripts/rosetta/check-distroseries-translations-diffs.py [05:40] Nothing seems to reference scripts/_ginalog.py, I'm tempted to just delete it. [05:42] I believe that would be the correct course of action. [05:42] 540KB of accidental addition, I suspect. [05:44] It hasn't changed since it was added around r1149 [05:48] 1 file changed, 15640 deletions(-) [05:48] Heh [05:49] Woah [05:49] With the amount of "die" and "kill" you both use, a casual observer would think you both are professional hitmen. [05:50] I used 'rm' this time! [05:50] ha [05:50] wgrant: Tossed at PQM [05:50] The code with the lowest maintenance cost is code that doesn't exist :) [05:50] +1 to that [05:54] Neat. r13980 [05:55] 20 more revs to r14000. Neat. [06:13] StevenK: Have you read sync-source.py lately? [06:13] def init(): global Blacklisted, Library, Lock, Log, Options [06:13] That's a pretty good summary of its style. [07:23] I don't think I want to. [07:28] 31 files changed, 558 insertions(+), 2198 deletions(-) [07:28] And canonical.lp is dead. [07:29] \o/ [07:29] Have you pushed it? [07:36] The three branches are in ec2. [07:36] Will see how much is broken. [08:49] Ah, this is handy. [08:51] I think our manual escaping stuff might do the wrong thing with postgres 9.1's escaping changes. [08:51] :( [08:54] wgrant: yes, feel free to kill remove-package.py [08:54] cjwatson: Thanks. [08:56] we still need sync-source.py for a while until a few more bugs in the new-style thing are worked out [08:56] Yep. [08:56] particularly sponsorship [08:56] *sigh* must find time to finish writing that autosync API script too [08:58] cjwatson: Are archive-{integrity,override,cruft}-check used? [08:58] cruft is very heavily used. [08:58] Ah, so we still use it for NBS? [08:58] I can't remember about the other two. [08:58] Yes. [08:59] I kind of feel like we ought to use integrity but I haven't done so for ages. [08:59] It also does ASBA, which is a bit odd. [08:59] Yeah, I want to run something like integrity, that basically compares the pool with the DB. [09:00] Because there is heaps of cruft there, and some stuff is probably missing. [09:00] I think this is the first time I've heard of archive-override-check. Exactly what "inconsistences" [sic] does it report on? [09:00] It's the one I don't know about, too. [09:00] Let me read it. [09:02] I think it might check consistency between architectures. [09:02] So like http://people.canonical.com/~ubuntu-archive/architecture-mismatches.txt except unused? :-) [09:02] That report is just done based on Packages and Sources files. [09:03] Indeed, probably. I assumed NBS there was similar -- didn't realise you actually used archive-cruft-check. [09:03] So, OK, it'll miss things with inconsistent overrides that aren't built, but ... [09:03] Yeah, we use it as the first stage of the input [09:03] I wouldn't object to rewriting it at some point [09:04] http://paste.ubuntu.com/692165/ - don't vomit all at once [09:04] I plan to write a new integrity checker in the short term, but have no plans for cruft, apart from the port to LaunchpadScript that I did this afternoon. [09:04] Not bad, not bad. [09:04] That explains why the output was unrecognisable. [09:04] I particularly like the grep '^ *o ' [09:06] Yeah. [09:06] AFAICT archive-cruft-check's ASBA support is unused and doesn't even make sense. [09:06] Perhaps it originated with dak. [09:21] I don't believe I've used it for some time [09:23] If you want to delete that part, that's fine by me; or you could just ignore it until I rewrite cron.NBS and propose a branch that removes the script entirely [09:23] OK, WTF was _ginalog.py about? [09:26] Oh. Wow. ArchiveCruftChecker doesn't even talk to the database except to get the current distroseries and such (and the removal code which we don't use). I could just pull that out wholesale. [09:27] (Perhaps not on a Sunday morning though.) [09:43] cjwatson: Yeah, most of archive-*-checker don't really use the DB for anything useful. [09:44] There's a *lot* of cruft in LP :) [09:53] nigelb: Thanks. [10:16] wgrant: \o/ [10:17] Not my happiest moment. Really. [10:19] Heh :) [11:32] Hehe, even cjwatson comments on _gina log === Pendulum_ is now known as Pendulum [18:11] where do all the translation strings like here come from? Do they come from po/messages.pot file present in branch associated with series which is focus of development? [18:22] Not the best of times. Oceania still hasn't woken up. [21:27] m4n1sh: "like here" ? [21:28] m4n1sh: also, Oceania is at war with East Asia, so that whole thing might get in the way. ;) [21:28] errrr? had too much of whisky? [21:29] :) [21:29] no [21:29] did you miss the 2 minutes hate, brother? [21:30] morning [21:30] m4n1sh: http://en.wikipedia.org/wiki/Nineteen_Eighty-Four#The_War [21:31] ahhh [21:31] got it [21:31] :) [21:32] m4n1sh: anyway, i'm not sure what you mean by 'like here' given you provided no link :) [21:32] yes [21:32] I know [21:32] that was the mistake [21:32] I realized it just now [21:33] it was the http://translations.launchpad.net/pinta [21:33] page [21:33] was trying my hands on gettext and all those, not able to understand many things [21:35] ah; i think translations on a project are imported from the .pot file in the series, if there is one [21:36] ugh [21:36] what the heck is pinta doing [21:36] eww [21:38] dobey: where? [21:39] with translations [21:39] it got a rebirth [21:39] I dont think the translations work properly [21:39] the translations should be named like es.pot, ro.pot etc [21:39] it's doing weird stuff manually with gettext, i presume to try and support windows also [21:39] no [21:39] like locale.pot [21:39] no [21:40] right now it is messages-.pot [21:40] there is only one pot file [21:40] sorry [21:40] no, it's .po [21:40] I mean [21:40] right now it is messages-.po [21:40] it should be just locale.po [21:40] well, a lot of things should be different [21:40] but all the files in pinta repo is named messages-.po [21:40] differnet like? [21:41] it's not clear how to me pinta expects to support windows/osx though [21:41] it does [21:41] well, "messages" is not a proper gettext package name [21:41] m4n1sh: i know it does. i mean in the technical sense [21:42] ie, a single .exe, or does it require cygwin to work, or what [21:42] dobey: it works on windows and osx too [21:42] over mono [21:42] runs over mono for windows [21:42] or probably even .NET [21:42] yes but that doesn't tell me anything [21:42] https://github.com/PintaProject/Pinta/tree/master/po [21:42] check this [21:42] i looked at it [21:42] but it doesn't tell me anything about it, other than it's being done wrong [21:43] lol [21:43] anyway, not an issue with launchpad itself [21:43] I dont think so [21:43] launchpad exports it as .po [21:43] AFAIK [21:43] this messages-foo thing breaks pure gettext based files [21:43] like pinta.desktop.in [21:44] yes, like i said. the way pinta is doing translations is totally broken :) [21:44] I get entries in pinta.desktop as [21:44] Name[messages-ro] = blah blah [21:45] I expect to get [21:45] Name[ro] = blab blah [21:45] eh? [21:45] yes [21:45] after running make I get "Name[messages-ro] = blah blah" in pinta.desktop file [21:45] not what I expect [21:46] i don't see how [21:46] are you building/installing on windows? [21:46] no [21:46] Ubuntu [21:47] is bzr way behind what's in git? or do you have some patch to make it build? [21:47] it looks for all the files in po/ dir and checks for the string I Used in _Name [21:47] so the translation for that string is in messages-ro.po [21:47] so it substitues Name[messages-ro] = fo fo [21:48] dobey: this way is not related to git or bzr [21:48] is there a pinta irc channel? [21:48] yes [21:48] dead [21:48] only me and Laney are there :) [21:48] this gettext thing is done by intltool and autotools [21:49] two highly confusing things [21:49] nothing git or bzr specific [21:49] let's move discussion there [21:49] yes [21:59] :P [22:05] morning lifeless [22:59] hi nigelb [23:00] Sleepless nights are so not fun. [23:01] wallyworld_: \o/ I landed that bug title via XHR that I was working on! After qa-bad twice though :( (wgrant may stab me anytime :P) === _thumper_ is now known as thumper [23:06] nigelb: excellent. well done. i've been fighting with unity this morning :-( [23:06] Ouch, that sounds like a bad way to start a Monday [23:07] yep. been bad for a few days. hopefully beta2 will be better [23:09] lifeless: Are we still forbidden from fastdowntime during beta week? [23:11] wgrant: on some days yes [23:12] lifeless: Wed/Thu I could understand, but it seems like two minutes early in the week shouldn't hurt. [23:12] I guess it depends when they aim to have images, too. [23:13] * wgrant stabs Optus a bit. [23:27] I wouldn't expect a Monday fastdowntime to be a problem. After that I think we'd prefer you held off [23:28] and Friday should be OK, given that the main bit that isn't fast yet is the publisher downtime [23:29] cjwatson: Thanks. [23:56] cjwatson: wgrant: I think kate asked for wed/thu [23:56] skaet: ^ was it those two days you wanted blacklisted, or tuesday as well ? [23:58] Does she realise it means missing a publisher run? [23:58] Although it may be on manual at that point anyway. [23:58] https://code.launchpad.net/~lifeless/launchpad/use-oops-timeline/+merge/75935 [23:58] wgrant: does it ? [23:59] lifeless: It finishes at :26-33 or so, so we disable it an hour before. [23:59] Meaning that the 0802 run doesn't happen.