[12:31] <mpt> Gooooooooooooooooood afternoon Launchpadders!
[12:32] <ajmitch> hi mpt 
[02:12] <jblack> sivang: Slept in a little. Had a long day yesterday. What's up?
[02:14] <mpt> jblack, you wrote "2005-01-23 * (1h) Met with mpt about bazaar-ng wiki site". I don't remember that ...
[02:16] <jblack> mpt: Remember the discussion about templates, bzr and the wiki?
[02:16] <mpt> no
[02:17] <jblack> You wanted to help, bzr hooked you and I up
[02:17] <mpt> Either I have a really bad memory, or you're confusing me with Henrik or someone else
[02:17] <jblack> Pardon, you wanted to help, lifeless hooked you and I up
[02:17] <mpt> What did I want to help with?
[02:17] <jblack> The wiki. I was planning and had just started the redesign for the site.
[02:18] <mpt> hummm
[02:18] <mpt> That sounds like something I *would* be interested in, if I wasn't so busy
[02:19] <jblack> Check the 24th
[02:19] <mpt> which channel?
[02:20] <mpt> or was it a query?
[02:20] <jblack> I think we were in bzr
[02:20] <mpt> I'm never in bzr
[02:20] <jblack> It could have been the 22nd, 23rd and 24th.
[02:20] <jblack> that's because my workday crosses the natural day boundary
[02:21] <jblack> It would have been 22rd or 23rd I didn't get logging turned back on until the 24th
[02:22] <mpt> The only time I've been in #bzr since the start of the year was 4.5 minutes on the 28th, and nobody said anything during that time
[02:22] <mpt> and I have no memory of that conversation
[02:22] <mpt> It must have been someone else :-)
[02:22] <jblack> check #launchpad and #canonical? 
[02:23] <thierry> every time I try to set a "target fix to release" tonight, I get a timeout error
[02:24] <jblack> A good word to key in on is "template" 
[02:27] <jblack> 20:26 < fullermd> mlh_ on the 23rd?
[02:27] <mpt> jblack, you didn't mention anything related while I was in #launchpad during that time, and I wasn't in #canonical at all because I was on holiday
[02:27] <jblack> mpt: I'm very sorry. It was mlh.
[02:27] <mpt> ok :-)
[02:28] <jblack> I feel a _lot_ better now
[02:28] <mpt> me too, I'm glad I'm not amnesiac or sleepworking
[02:28] <mpt> or being impersonated
[02:28] <jblack> Is this doublechecking stuff or do I need to go back and somehow get the record changed?
[02:29] <mpt> It was mainly for my reassurance, I don't mind what you do now :-)
[02:31] <jblack> Good. Because I just got my new "Matthew Thomas" Gold card.
[02:31] <jblack> Free beer tonight!
[02:31] <mpt> haha
[02:31] <mpt> free-as-in-beer
[02:31] <jblack> free-as-in-fraud
[04:15] <mpt> jblack, what's wrong with this picture:
[04:15] <mpt> cp -a ~/hacking/lp/rocketfuel ~/hacking/lp/$1
[04:16] <mpt> when I do that all the subdirectories are present, but the files at the top level are not
[04:26] <mpt> (where $1 is the name of my new branch)
[04:29] <jblack> Yeah, lets fix that
[04:30] <jblack> where is that?
[04:30] <mpt> huh, I tried it again and it works
[04:30] <jblack> mpt: I can't find where you got that from anyways
[04:31] <mpt> my old new-branch script
[04:31] <jblack> Ohh. I thought you meant the new RocketfulSetup PQMSetup scripts
[04:31] <mpt> no ... sorry for the interruption
[04:32] <jblack> You didn't interrupt me. Thats part of my job. :)
[04:38] <mpt> great, make schema fails
[04:41] <mpt> I guess that gives me an excuse to get back to design work until someone who knows what they're doing arrives ...
[05:08] <lifeless> mpt_: wassup
[05:24] <mpt__> lifeless, after make clean and make build, make schema fails with "psycopg.ProgrammingError: ERROR: relation "poll" already exists"
[05:24] <mpt__> in a brand-new branch
[05:24] <mpt__> while applying patch-25-01-0.sql
[05:25] <lifeless> that is not a new branch
[05:26] <lifeless> patch-25 is ancient, we are in the 40's now
[05:26] <lifeless> the basis schema is launchpad-40 now
[05:30] <mpt__> hmmmmm
[05:31] <mpt__> I updated my rocketfuel copy yesterday
[05:32] <lifeless> ls databases/schema/launchpad*
[05:32] <mpt__> after running pull-rocketfuel again, database/schema/ contains patch-25-00-0.sql through patch-40-08-0.sql
[05:35] <mpt> should it not contain the -25- ones?
[05:35] <jamesh> the -25- ones should be under archive/
[05:36] <mpt> rsync -aP chinstrap:/home/warthogs/archives/rocketfuel-built/ ~/hacking/lp/rocketfuel
[05:36] <mpt> is that correct?
[05:36] <mpt> or has rocketfuel-built been renamed recently?
[05:36] <mpt> (or obsoleted, rather)
[05:36] <lifeless> no, rf-built is still in use
[05:38] <mpt> so why would the destination still contain the obsolete patches?
[05:38] <mpt> -aP looks right...
[05:38] <lifeless> erm
[05:39] <jamesh> mpt: you need --delete or --delete-after
[05:39] <lifeless> why are you working in the rysnced dir ?
[05:39] <jamesh> mpt: otherwise files that have been removed will remain in your local copy
[05:39] <lifeless> I think thats your problem, bzr is not managing your dir, and you'll be wipiing out all your local edits
[05:39] <lifeless> you have to rsync into a *different* dir and use bzr to merge from that
[05:40] <mpt> ~/hacking/lp/rocketfuel is not my working directory
[05:40] <jamesh> that would explain why you still have the patch-25-* patches
[05:40] <mpt> ~/hacking/lp/whatever-branch-name is my working directory
[05:40] <mpt> which is from cp -a of ~/hacking/lp/rocketfuel
[05:41] <jamesh> if you don't pass --delete to rsync, you'll end up with old crap in your tree
[05:57] <mpt_> victory!
[05:57] <mpt_> thanks lifeless and jamesh 
[05:58] <mpt_> (having all my new forthcoming branches be less than half their traditional size is an added bonus)
[06:14] <stub> mpt_: Should searching for "window not responding" match bugs containing the word "window" but not "responding", or bugs containing the words "window", "not" and "responding".
[06:15] <stub> mpt_: If the latter, should we go with google's "window NOT responding" or use our own syntax like "window !responding" to do the 'not' search?
[06:15] <mpt_> stub, the latter, and in MaloneSearch I specced syntax of the form 'window -responding'
[06:16] <mpt_> I didn't know Google did 'NOT foo' as well as -foo
[06:17] <mpt_> ... it doesn't
[06:18] <mpt_> http://www.google.com/search?q=virus+NOT+computer
[06:18] <mpt_> http://www.google.com/search?q=virus%20-computer
[06:19] <ajmitch> heh
[06:20] <stub> ok. ta.
[06:24] <stub> Dealing with Malone as a seperate product is a pita because we don't have any project wide views for specs, bugs etc. :-(
[06:25] <mpt_> stub, that's bug 5584
[06:25] <Ubugtu> malone bug 5584 in malone "Project bugs page needs implementing" [Normal,Confirmed]  http://launchpad.net/bugs/5584
[06:25] <mpt_> at least partly
[06:26] <mpt_> which is one of the things I'm specifying for https://wiki.launchpad.canonical.com/MaloneFrontPages
[06:27] <mpt_> feel free to report bugs about missing project^W product group specs pages, bounties pages, etc
[06:51] <lifeless> spiv: get I make 'module.attribute' run a function ?
[06:52] <spiv> lifeless: The practical answer is no.
[06:52] <spiv> The tasteful answer is also no.
[06:52] <lifeless> I have an attribute I want to deprecate
[06:52] <lifeless> I dont want to break clients
[06:52] <lifeless> but I want them to know that its moving
[06:53] <spiv> I feel your pain.
[06:53] <lifeless> python, why art though guidos child!
[06:53] <spiv> But essentially the answer is no.
[06:53] <lifeless> can pypy help ?
[06:53] <spiv> (you don't really want to hear about the mess required to make it a "yes")
[06:53] <lifeless> I'm guess change the metatype of the module for starters
[06:54] <spiv> Putting non-module objects in sys.modules is probably nicer, relatively speaking.
[06:54] <lifeless> during __init__ sys.modules=MyFakeModule(__module__)
[06:54] <lifeless> ;)
[06:54] <spiv> You're better off making the relevant attribute raise deprecation warnings when used.
[06:54] <lifeless> its a constant
[06:55] <spiv> Make it a smart constant ;)
[06:55] <lifeless> oh ?
[06:55] <lifeless> do tell
[06:55] <spiv> But yeah, I realise this is also not practical all the time.
[06:56] <spiv> Well, e.g. you could replace a string constant with a custom object that implements __str__.  Or perhaps even make it subclass basestring if you have really tight backwards-compat concerns...
[06:56] <spiv> But basically, I think you're stuck with purely documenting and crossing your fingers.
[06:56] <lifeless> holy mother of fuck
[06:57] <lifeless> that would be a mess - __str__, __iter__, __eq__ etc
[06:57] <lifeless> subclassing str would be better
[06:57] <lifeless> I think I'll try that
[06:58] <lifeless> class DeprecatedString coming right up
[07:53] <SteveA> there is i think some code in zope3 to rename and deprecate the old name of something
[07:55] <SteveA> i just checked.  it is for aliasing one module to another.
[07:55] <SteveA> so, not quite what you're looking for.
[07:56] <SteveA> lifeless: you could also implement a proxy that issues a deprecation warning, and then sends messages to the new thing.
[08:01] <lifeless> SteveA: I guess I was thinking of strings as special.
[08:01] <lifeless> I am enlifted now
[08:38] <SteveA> lifeless: strings are somewhat special, but probably not in ways that matter for this particular circumstance
[09:25] <lifeless> problem ?
[09:25] <lifeless> oh, I am guessing the merge of storage broke the bzrtools mainline
[09:25] <lifeless> I have fixes in my plugins/bzrtools/storage dir, or plugins/bzrtools/trunk
[09:27] <jamesh> cool.  I'll look at that
[09:39] <lifeless> fabbione! 
[09:39] <fabbione> hey lifeless 
[09:40] <lifeless> caught up with Mark today, hes talking about 'server profiles'... has he mentioned that to you ?
[09:40] <fabbione> i still need to read my emails
[09:40] <lifeless> okies
[09:40] <fabbione> otherwise i have no idea :)
[09:40] <lifeless> anyway, when you have, ping me
[09:44] <fabbione> lifeless: i have nothing in my inbox from Mark
[09:44] <lifeless> hah
[09:44] <fabbione> lifeless: are you sure i was CC'ed?
[09:44] <lifeless> he did say it was a new idea
[09:45] <lifeless> no, he didn't email me
[09:45] <lifeless> we had lunch
[09:45] <lifeless> so I have *no* idea if he has emailed you or not
[09:45] <fabbione> ok
[09:45] <lifeless> anyway the idea is that the server install would have profiles
[09:46] <lifeless> so you can say 'db server', or 'LAMP profile', or 'LDAP server', or 'Bastion Host'
[09:46] <lifeless> and we offer 4 or 5 really key and common configurations.
[09:46] <fabbione> it's really nothing new about that
[09:46] <lifeless> a profile would come up after the install with a sane default
[09:46] <fabbione> and we did kill it for a reasons a looong time ago
[09:46] <lifeless> heh
[09:47] <fabbione> reintroducing it would be a pain
[09:47] <fabbione> i think
[09:47] <lifeless> hes talking about it during Q&A sessions in the asia tour :) :) :)
[09:47] <lifeless> you may have to talk with him to pin down the details about how its different to what we had before
[09:47] <fabbione> yes
[09:48] <lifeless> what he wanted me to do was chat with you about the 4-5 key profiles that would make sense.
[09:48] <fabbione> also because i don't understand why he want something like that
[09:48] <fabbione> lifeless: i need to understand why he wants that in the first place
[09:48] <lifeless> yah
[09:48] <fabbione> because with the actual CD/status
[09:48] <fabbione> there is only one daemon for each task
[09:48] <fabbione> like apache -> www
[09:48] <fabbione> postfix -> mail
[09:48] <fabbione> etc.
[09:48] <pollo> Hi i want to do kiax package to kubuntu , what i must do ? 
[09:49] <fabbione> so introducing a profile it's kind of pointless
[09:49] <lifeless> I'm guessing here... but my gut feeling is its like having a bunch of very small targeted distros, one for each common task
[09:49] <lifeless> pollo: join #ubuntu-motu
[09:49] <lifeless> pollo: where I think someone is already working on that
[09:49] <pollo> mm ok 
[09:49] <pollo> thanks 
[09:49] <lifeless> fabbione: well, a LAMP profile would for instance know to install mysql and apache, enable both by default, activate mod_python and mod_perl
[09:50] <lifeless> fabbione: or a bastion host would have amavis (or whatever we support) and postfix preconfigured to intercept, scan, and forward email, a squid ready to go, iptables in sane mode for a 192.168.0.0 internal network
[09:50] <fabbione> lifeless: that's so much a NO NO NO
[09:50] <lifeless> fabbione: Mark and I only had literally 2 minutes talking about this
[09:51] <kiko> good morning 
[09:51] <kiko> hey SteveA 
[09:51] <lifeless> fabbione: so, I am really not a great champion of the idea :)
[09:51] <fabbione> we did discuss these options already and we are not going to do stuff like that in a week from feature freeze
[09:51] <lifeless> morning Mr Kiko
[09:51] <kiko> how's everything
[09:51] <lifeless> rocking
[09:51] <kiko> thankful to know that it is rocking somewhere in the globe
[09:51] <lifeless> fabbione: I have no idea what timeframe he was thinking
[10:10] <sivang> morning all
[10:10] <Kinnison> hi sivan
[10:11] <sivang> Kinnison: Hi Daniel :-)
[10:15] <kiko> really
[10:15] <mpt_> a-ha
[10:16] <Kinnison> sivang: did you run "make" at the top level?
[10:17] <mpt_> Kinnison, you've been working on the autobuild stuff, right?
[10:17] <mpt_> along with cprov?
[10:17] <Kinnison> mpt_: yes
[10:17] <mpt_> What's the difference between CHROOTWAIT and CHROOTFAIL?
[10:17] <kiko> hey stub 
[10:17] <stub> kiko: yo
[10:18] <sivang> Kinnison: I recall I did, let me double check that.
[10:18] <Kinnison> mpt_: the latter doesn't exist
[10:18] <mpt_> OH RLY?
[10:18] <Kinnison> mpt_: Or rather, CHROOTFAIL is the build state caused by CHROOTFAIL from the builder
[10:19] <Kinnison> urgh
[10:19] <Kinnison> english -- she is bad today
[10:19] <kiko> stub, we're getting somewhere. we would like to be able to do a production to staging database/librarian (but no code) sync today -- how difficult is it to kick that off when we want to?
[10:19] <Kinnison> mpt_: Or rather, CHROOTWAIT is the build state caused by CHROOTFAIL from the builder
[10:19] <kiko> stub, is it something we can manually trigger?
[10:19] <kiko> (keep in mind we have elmo on our side)
[10:19] <mpt_> Kinnison, ok, thanks
[10:20] <cprov> mpt_: can you fix the UI, it sounds like a typo, use CHROOTWAIT
[10:20] <stub> kiko: You can trigger it if I give you instructions, but it would be better if you can ping me and I kick it off.
[10:20] <mpt_> cprov, next question: database/build.py contains a build_icon() function. Should that be in browser/build.py instead?
[10:20] <stub> I think current time to do a restore is about 2.5 hours now that I've worked around the issue causing slow restores.
[10:21] <cprov> mpt_: uhm, the best should be in formatters, like bug
[10:21] <cprov> mpt_: what do you think ?
[10:21] <mpt_> cprov, that makes more sense, yes
[10:22] <SteveA> hi
[10:22] <cprov> mpt_: good !
[10:22] <kiko> stub, what if it's too late for you -- this may only happen in some 6-8h
[10:23] <stub> kiko: I'll write up the instructions and make sure there is an up to date database dump on asuka
[10:23] <sivang> Kinnison: cd rocketfuel/launchpad && make build is what I did, it uses some python shhh script so I am not sure if I could see errors that bounced out of it.
[10:23] <SteveA> jamesh: hello
[10:24] <sivang> (under 'Build Launchpad' section in RFS)
[10:24] <kiko> stub, so, just to be clear -- I need to be able to say "sync the current (now) production database" 
[10:24] <kiko> I will need to chase people down to add keys and sign CoCs and I don't want to have to redo that on staging
[10:25] <stub> kiko: If you want to do *that*, I need to do it. Or possibly elmo. Because it first involves dumping the production database (about 2 hours), copying the file across to asuka, and then doing the restore.
[10:25] <Kinnison> sivang: And after that, it still ranted about not being about to load the proxy module?
[10:25] <sivang> Kinnison: yep.
[10:25] <Kinnison> sivang: commonly that error indicates that it hasn't built, but the ssshhh program is meant to show you errors, just not bother you if there are no errors
[10:25] <kiko> stub, grumble. what if we schedule a time for it?
[10:25] <stub> kiko: How about I do it first thing tomorrow my morning? It should be ready for you when you start work tomorrow morning London time?
[10:26] <kiko> stub, then the builds can't run overnight and we lose a day
[10:26] <kiko> (one MORE day)
[10:26] <sivang> Kinnison: ah ok then, thx. I'll need to check those errors later on today - is there a way to make sshh more verbose? 
[10:26] <Kinnison> sivang: not sure
[10:27] <sivang> Kinnison: nm, I'll use the source ;-)
[10:28] <stub> kiko: How about we schedule me to do it in 6 hours time? (10:30pm Thailand time). If we do that, you should be able to start the builders in about 11 hours time before collapsing for the night
[10:28] <kiko> that sounds like a plan.;
[10:28] <kiko> stub, so we have 6 hours to prepare for this. that is good.
[10:28] <stub> kiko: Although I can't guarantee that the restore will only take 2.5 hours
[10:28] <kiko> that's okay.
[10:29] <stub> So if you want to get to bed earlier, ping me to start it earlier :-)
[10:32] <kiko> great.
[10:32] <kiko> stub, have you tried using the admin-people-merge stuff matsubara landed?
[10:33] <stub> kiko: Nope. I didn't think I had rolled it out yet?
[10:33] <kiko> it hasn't, no.
[10:34] <stub> I haven't played with it locally anyway.
[10:34] <kiko> I was going to suggest testing on staging but... never mind me :)
[10:37] <kiko> In [5] :re.sub("         ", "\s+", "\t")
[10:37] <kiko> Out[5] :'\t'
[10:38] <SteveA> kiko: don't write code including literals like "          "
[10:38] <SteveA> and dont' allow such code to be written
[10:38] <SteveA> use " " * 30 instead
[10:38] <kiko> sorry, that was actually a wrong example
[10:38] <kiko> In [8] :re.sub("\s+", "\t", "      x     ")
[10:38] <kiko> Out[8] :'\tx\t'
[10:38] <kiko> that's what I meant.
[10:39] <Kinnison> kiko: yep, thanks
[10:39] <Kinnison>                             line = re.sub(r"\s+", "\t", line)
[10:40] <kiko> In [18] :a = "\t   \tfoo\t   \t\tbar\t  \t\txxx\tooo   "
[10:40] <kiko> In [19] :a.split(None, 2)
[10:40] <kiko> Out[19] :['foo', 'bar', 'xxx\tooo   '] 
[10:44] <Kinnison> kiko: https://chinstrap.ubuntu.com/~dsilvers/paste/filevxFpP5.html
[10:46] <SteveA> jamesh: ping
[10:47] <jamesh> SteveA: pong
[10:47] <Kinnison> kiko: the call site is at: https://chinstrap.ubuntu.com/~dsilvers/paste/fileicOoty.html
[10:48] <SteveA> hi jamesh.  do you have a headset for your computer?
[10:49] <jamesh> yeah
[10:50] <SteveA> cool.  can we try some voice stuff out?
[10:50] <jamesh> okay
[10:51] <SteveA> actually, i should wait a few minutes until the vacuum cleaning has finished here
[10:55] <kiko> thanks for using the list SteveA 
[11:00] <lifeless> can you guys keep an eye out at the next oops code
[11:00] <lifeless> see if the login link on it is to localhost
[11:01] <jamesh> https://launchpad.net/foo gives https://launchpad.net/foo/+login as the login link
[11:03] <stub> I've seen localhost as a login link on an oops code, but have not been able to reproduce it :-/
[11:04] <kiko> I haven't either
[11:04] <SteveA> stub: i just sent a test message to system-error@launchpad.ubuntu.com, including Bug in the subject line
[11:05] <SteveA> stub: do you know if it has been received somewhere?
[11:05] <stub> I have no idea
[11:05] <SteveA> it should be on the errors list that you admin
[11:06] <SteveA> i guess it should be in its own topic
[11:06] <stub> It should?
[11:06] <SteveA> yes
[11:06] <SteveA> this is the email address presented on oops pages, when someone can't file a bug
[11:06] <stub> Ok. Someone should ask rt@ to sort out the forwarding then
[11:06] <SteveA> the forwarding should be already arranged
[11:07] <SteveA> elmo wrote a script to accept email only when it has "Bug" in the subject line
[11:07] <SteveA> and forward on to the errors list
[11:07] <SteveA> at least, i think that's where it forwards on to
[11:07] <stub> Nup - that email address has been busted for months and months. In fact, there may already be an rt job or a Malone bug on it.
[11:07] <kiko> I'll talk to elmo about it
[11:07] <SteveA> aw crap
[11:07] <SteveA> it is bullshit having an email address like that, which doesn't work
[11:07] <SteveA> and, the email address should'nt have "ubuntu" in it either
[11:07] <SteveA> thanks kiko
[11:09] <lifeless> jamesh: thats not an oops code
[11:10] <SteveA> lifeless: i can imagine why the problem would occur.  it is possible that the request is in some kind of incomplete state when the oops page is rendered
[11:10] <jamesh> lifeless: not found errors generate oops reports
[11:10] <SteveA> of course, if so, this is a bug
[11:11] <lifeless> jamesh: well they *look* different that the one I saw
[11:11] <jamesh> lifeless: there are separate error pages for 404, timeout and generic oops
[11:12] <lifeless> jamesh: so, it was a generic oops I saw it on
[11:12] <jamesh> lifeless: but the same error report code is executed in each case
[11:12] <lifeless> jamesh: sure, but its not having the same result ;)
[11:13] <stub> There is a quick fix for this, even if we can't reproduce it. There is a launchpad.conf entry config.root_url which we can use to build the link instead of grabbing it from the environment somehow (although this won't work for shipit...)
[11:13] <kiko> SteveA, just explain to me -- where is this email displayed?
[11:14] <SteveA> oops pages
[11:14] <kiko> is it our fault that they are @xxx.ubuntu.com?
[11:16] <SteveA> our fault?
[11:16] <kiko> I mean, is that address hardcoded in our templates, code or config?
[11:17] <SteveA> kiko: i'm on a call with james.
[11:17] <kiko> that's good to know
[11:17] <SteveA> kiko: the address is hard coded in some templates, displayed to users
[11:17] <kiko> ok.
[11:17] <SteveA> jamesh, that is
[11:17] <SteveA> there is no need to have the email address in a config
[11:18] <kiko> Yes, I knew. I'll ask elmo if we can have both @launchpad.net work as well and then we can migrate.
[11:18] <SteveA> i think it was a "@xxx.ubuntu.com" address because it was easier for elmo to set up
[11:18] <kiko> ok.
[11:18] <kiko> say hi to james for me
[11:27] <stub> mpt_: So I assume that searching for 'launchpad-bugs' would be different from searching for 'launchpad -bugs' ? The first being a search for 'launchpadbugs' and the second 'launchpad' and not 'bugs'?
[11:37] <SteveA> ddaa: what time (UTC) is the meeting on monday?
[11:39] <ddaa> 0900 UTC usually
[11:39] <ddaa> man, you dragged me out of bed
[11:40] <mpt_> stub, yes, with the first being a search for launchpad{any or no punctuation}bugs if possible
[11:40] <mpt_> that's what Google does, anyhow
[11:41] <stub> mpt_: Seems sane.
[11:41] <SteveA> ddaa: jamesh will be joining us for the meeting on monday
[11:43] <stub> mpt_: I doubt we will be able to implent MaloneSearching as specced btw in the short term - it pretty much involves writing a full text search engine from the ground up, or glueing something that meets the criteria onto the PostgreSQL backend. Either way, lots of work. But we can still aim towards it.
[11:43] <mpt_> stub, yes, it's not meant to be implemented all at once ;-)
[11:43] <mpt_> but it's generally arranged in order of importance
[11:46] <SteveA> stub: voice call?
[11:46] <stub> Sure
[11:47] <jamesh> stub: I merged a branch into rocketfuel that just missed the last production rollout
[11:48] <jamesh> stub: it changes the oops code numbering going on from February, so I was wondering if it would be possible to get it cherry picked into production
[11:48] <stub> jamesh: I should be doing a rollout later today, and it will go out then
[11:48] <jamesh> stub: that works for me :)
[11:49] <jamesh> stub: it was merged into rocketfuel as r3020
[11:50] <SteveA> jamesh/stub: if it's possible, getting __len__ fixes in this rollout would be good
[11:51] <kiko> SteveA, wouldn't it be better to let that bake a week first?
[11:51] <kiko> I am only asking because, well, __len__ hasn't been removed in RF yet, has it?
[12:10] <stub> kiko: If the system-errors email address is busted because of the script that looks for 'Bugs', I might be able to do this at the mailman end
[12:11] <kiko> I am unable to check up on that, stub, until elmo arrives
[12:11] <kiko> stub, gina isn't running on asuka at the moment, right?
[12:13] <kiko> (meaning -- is it disabled in cron)
[12:15] <stub> kiko: Gina is disabled on asuka
[12:16] <kiko> great.
[12:42] <carlos> back to life!
[12:43] <carlos> kiko: hi
[12:43] <kiko> hey carlos 
[12:43] <kiko> I'll give you a ring in 45 minutes.
[12:43] <carlos> kiko: ok
[12:44] <kiko> hey niemeyer 
[12:44] <niemeyer> Morning!
[12:50] <niemeyer> SteveA: ping
[12:51] <SteveA> hi niemeyer 
[12:51] <niemeyer> Heyho!
[12:51] <niemeyer> Feeling better today? :)
[12:52] <SteveA> it's daytime!
[12:57] <hannosch> carlos: you around?
[12:58] <carlos> hannosch: yes
[12:58] <hannosch> on a recent import one of my po files where associated with the wrong template, jordi couldn't fix it and said you could
[12:58] <stub> carlos: launchpad_carlos is rebuilding at the moment. 
[12:59] <stub> carlos: Should be ready in an hour or two
[12:59] <daf> SteveA: it would be nice if the OOPS page linked to /products/launchpad/+filebug with some fields already filled in
[12:59] <daf> SteveA: it makes it easier for users to file a bug
[12:59] <carlos> stub: ok, thanks. Did you added it to your cronscripts?
[12:59] <daf> SteveA: and the reports we would get would be more consistent and hence easier to triage
[01:00] <hannosch> carlos: could you take a look at https://launchpad.net/products/plonesoftwarecenter/+translations and move the pt_BR file to the right template removing the plonehelpcenter one, would be great ;)
[01:00] <carlos> hannosch: plone?
[01:00] <daf> SteveA: if it was a timeout, it could put "Timeout" in the summary, for instance
[01:00] <carlos> hannosch: no, I cannot fix it
[01:01] <hannosch> carlos: not plone itself, but some add-on module for it
[01:01] <carlos> we need to do some code updates to allow it
[01:01] <carlos> hannosch: yeah, I know. I need some extra info from jordi
[01:01] <carlos> hannosch: reimport the .po file and we will handle the wrong import
[01:01] <hannosch> carlos: ok, great
[01:05] <hannosch> carlos: hhm, I get an error: "Ignored your upload because the file you uploaded was not recognised as a file that can be imported."
[01:07] <carlos> hannosch: it should end with '.po'
[01:08] <hannosch> carlos: it does, poEdit can open it, so I guess the format is right
[01:09] <carlos> that message is related only to the filename
[01:09] <carlos> hannosch: we don't check the content at that point
[01:09] <carlos> hannosch: could you give me the URL where you are trying to upload it and the filename it has?
[01:09] <hannosch> it's pt_BR.po and now I use the one exported from rosetta ;) on https://launchpad.net/products/plonesoftwarecenter/+series/trunk/+pots/plonesoftwarecenter/+upload
[01:12] <hannosch> ah sorry, my mistake this is the template upload ;)
[01:13] <carlos> https://launchpad.net/products/plonesoftwarecenter/+series/trunk/+pots/plonesoftwarecenter/pt_BR/+upload
[01:13] <carlos> yeah
[01:13] <carlos> hannosch: you should use that other url
[01:13] <stub> carlos: I'll cron it if the script I'm using to do the update works happily
[01:15] <hannosch> carlos: thx so much, it worked, I still get confused by the way you have to do this
[01:15] <carlos> hannosch: please, could you explain it a bit more?
[01:15] <carlos> stub: ok, thanks
[01:16] <hannosch> carlos: I always try to go to the template first and upload a new translation for it instead of going to the series
[01:17] <hannosch> especially in this case where the series is really a dummy as there is only a development trunk right now
[01:18] <carlos> hannosch: the problem is that there are other products that have more than one development trunk so we cannot associate it directly with the product...
[01:20] <hannosch> carlos: I understand that, the whole need to have a series is just a bit overhead for the simple case, but I can life with this. The only thing I'm missing is a bit more documentation for the common use-cases ;)
[01:23] <carlos> hannosch: please, talk with jordi about it to suggests the things you think should be better documented
[01:25] <hannosch> carlos: I'll do that, might even help the poor guy ;)
[01:25] <carlos> hannosch: ;-)
[01:28] <hannosch> carlos: sorry to bug you, but there's something wrong here, I uploaded that po file at the url you wrote but it keeps adding it to the wrong template
[01:32] <hannosch> the import queue already gets it wrong in the 'import into' column
[01:37] <kiko> is something happenning on asuka, stub?
[01:38] <stub> kiko: Doing a database restore for carlos
[01:38] <kiko> stub, on the staging database?
[01:38] <stub> kiko: No - launchpad_carlos
[01:38] <kiko> thanks.
[01:39] <carlos> hannosch: let me check...
[01:41] <carlos> I cannot access to launchpad..
[01:52] <stub> Launchpad is going down in 20 minutes, which will put the wikis into read only mode as well. Estimated down time is 10 minutes. This is for the regular weekly code and database update.
[01:53] <kiko> stub, will that affect the staging librarian?
[01:54] <Kinnison> It will, if it needs him to take down production's librarian
[01:54] <stub> actually... maybe. When the production librarian is down, some files will not be found... hmm..
[01:54] <stub> yer
[01:54] <kiko> ah. that's better.
[01:54] <Kinnison> but est. downtime is 10 minutes? that's fine
[01:54] <kiko> well, okay then.
[01:54] <stub> yup.
[02:05] <SteveA> daf: ping
[02:09] <jordi> carlos: what extra info do you need?
[02:10] <carlos> jordi: I sent you an email with some questions about it
[02:18] <carlos> I'm having problems fetching rocketfuel updates
[02:19] <carlos> could anyone confirm that it works so I can know if it's related with my DSL line or not?
[02:21] <jordi> carlos: I'm really busy at work now
[02:21] <jordi> I can't have a look
[02:22] <carlos> jordi: don't worry, I can wait until this afternoon
[02:29] <stub> launchpad is back up for the most part. Librarian is still down due to issues with the disk array that Znarl is looking into
[02:30] <SteveA> carlos: i'm running rocketfuel-get now
[02:30] <SteveA> carlos: what problems are you having?
[02:30] <carlos> SteveA: I get timeouts
[02:31] <carlos> and I'm not able to finish the rsync
[02:32] <carlos> receiving file list ...
[02:32] <carlos> 34273 files to consider
[02:32] <carlos> Disconnecting: Timeout, server not responding.
[02:33] <SteveA> it just worked for me
[02:33] <SteveA> so, i think it is something on your end
[02:33] <carlos> :-(
[02:33] <SteveA> if you just ssh to chinstrap
[02:33] <SteveA> do you get disconnected after a while?
[02:34] <carlos> checking it..
[02:36] <stub> I had flaky ADSL last week - couldn't keep an SSH connection open for more than 2 minutes at a stretch
[02:36] <SteveA> stub: what fixed it?
[02:36] <stub> SteveA: Waiting a day. Often does the trick :-)
[02:37] <Nafallo> file a bug on the isp! :-)
[02:38] <carlos> stub: that's not a good solution for me... but I guess I can fix any conflict tomorrow and follow the development... last update I have is from Friday... It should not be too bad ...
[02:38] <carlos> SteveA: chinstrap ssh session is still working
[02:40] <SteveA> how strange that an rsync over ssh would fail
[02:54] <carlos> kiko: I'm going to have lunch, would we talke when I'm back?
[02:55] <kiko> yes
[02:55] <kiko> ping me
[02:56] <carlos> kiko: ok
[02:56] <kiko> thanks.
[03:00] <kiko> stub, with the production librarian bein' down and all, I wonder, are we hosed?
[03:01] <stub> kiko: Depends on if you need to retrieve files from the production librarian or not. Anything that was uploaded to staging since the last database sync will be retrievable.
[03:01] <kiko> well, I'm more concerned about the sync of production to staging
[03:01] <kiko> without a production librarian...
[03:02] <stub> That won't be affected.
[03:03] <kiko> I see. only operation will be affected.
[03:03] <stub> kiko: What might be of more concern is that I doubt people can sign CoCs at the moment
[03:03] <stub> I think that code stores a copy of the document in the librarian
[03:03] <kiko> maybe, maybe.
[03:03] <stub> Which will give an oops at the moment
[03:04] <kiko> the emblems on launchpad just disappeared when I reloaded!
[03:04] <stub> Yup - hackergotchis and emblems are served by the librarian :)
[03:05] <kiko> yeah, fun stuff.
[03:06] <Kinnison> G-d does not want us to deploy soyuz
[03:06] <SteveA> is G-d a community ubuntu devel?  i don't recognise the name
[03:10] <Kinnison> G-d is in all channels
[03:30] <daf> SteveA: pong
[03:30] <SteveA> hi daf
[03:32] <kiko> stub, I will need an updated version of gina to run on prat today. Are you up for that?
[03:33] <stub> kiko: Sure. Just bringing the librarian back on first - Znarl has got things back online
[03:33] <kiko> really!
[03:33] <kiko> that's great, elmo has left for the DC
[03:33] <kiko> the code isn't even written yet, mind you, cowboy me
[03:34] <stub> Remind me why we are running untested code against production again?
[03:34] <kiko> it will have tests -- I wrote them first.
[03:34] <kiko> hmm, indeed, why are we running this untested code against production.
[03:34] <kiko> okay, let's run it on staging after-the-fact then.
[03:36] <Kinnison> kiko: The instances where it has created debian-installer/ seemingly unexpectedly appear to be because that pocket happens to have di stuff in it
[03:41] <kiko> I see
[03:42] <Kinnison> mdz: We're currently seeing an amusing difference between the katie archive and our own
[03:42] <Kinnison> mdz: We publish debian-installer stuff if it turns up, regardless of where
[03:42] <Kinnison> mdz: So, breezy-updates/main/ has a debian-installer because of nobootloader
[03:43] <Kinnison> mdz: This is a departure from katie which of course doesn't have those in its apt-ftparchive configuration
[03:43] <kiko> and dapper/multiverse/ has an empty debian-installer.
[03:43] <Kinnison> That i'm not so sure about and am investigating
[03:43] <kiko> well
[03:43] <kiko> it's in a release pocket
[03:43] <Kinnison> just whether or not it should have been made to exist
[03:43] <kiko> just a bad pocket in it
[03:43] <kiko> but there are no semantics in the publisher as to what are "bad" pockets.
[03:44] <kiko> components.
[03:44] <kiko> doh.,
[03:44] <Kinnison> Aye
[03:44] <Kinnison> You really confuse us sometimes
[03:44] <kiko> that's ok.
[03:46] <stub> librarian is back up
[03:46] <kiko> rock and roll Znarl!
[03:47] <Kinnison> Our sysadmin team are the bomb
[03:48] <kiko> indeed they are. they blow hardware up
[03:51] <Kinnison> Someone set them up the bomb
[04:01] <stub> kiko: Are we looking ready to dupe the production database to staging?
[04:02] <mdz> Kinnison: I can't think of a way for a spurious debian-installer dir to cause a problem
[04:02] <stub> kiko: btw. restoring production databases onto the staging hardware currently takes three hours (which is how long carlos' database took)
[04:03] <Kinnison> I'm currently still using the staging db
[04:03] <Kinnison> In about 30 minutes I'll be ready to let it go
[04:03] <Kinnison> but I need that much longer to fix a bug in unpublish
[04:09] <kiko> stub, yes.
[04:09] <kiko> stub, go forth and do it.
[04:10] <stub> You confirmed that with Kinnison?
[04:10] <Kinnison> do the snapshot sure, don't reload yet
[04:10] <stub> Ahh.... yes.
[04:14] <stub> Ok. Script is running
[04:14] <stub> Doing backup now, and will destroy and rebuild the staging db when it  is done
[04:14] <kiko> which will be .. when?
[04:16] <stub> Approx 1 hour 15 mins to backup the database, approx 3 hours to restore it.
[04:17] <kiko> ok.
[04:17] <carlos> kiko: ping
[04:17] <carlos> I'm back
[04:17] <kiko> okay. I am in the middle of something but I will call you still today.
[04:17] <carlos> kiko: ok
[04:25] <stub> carlos: your database is all ready
[04:26] <carlos> stub: cool, thanks
[05:02] <SteveA> daf: ping
[05:06] <Kinnison> carlos: are you hammering asuka again?
[05:06] <carlos> Kinnison: don't think so
[05:07] <Kinnison> carlos: Hmm, something else must be making it slow then
[05:07] <carlos> Kinnison: the cronscript is scheduled on Sundays
[05:07] <Kinnison> carlos: aye, thanks
[05:07] <carlos> Kinnison: let me check anyway...
[05:07] <Kinnison> :-)
[05:08] <daf> SteveA: pong
[05:08] <SteveA> hi daf
[05:08] <daf> hi
[05:08] <carlos> Kinnison: no, I don't have anything running on mawson
[05:08] <Kinnison> carlos: s'okay, s'going faster again
[05:08] <carlos> Kinnison: ;-)
[05:16] <ddaa> phew, finished documenting everything but the RCS Importer. (SteveA asked me to document the various components of TheBazaar).
[05:16] <ddaa> If somebody is interested in reviewing this draft, I can put it online before starting on the RCS Importer.
[05:17] <SteveA> ddaa: cool.
[05:18] <SteveA> please put it somewhere that launchpad developers can find it
[05:18] <Kinnison> stub: Okay, I'm finished with the tests I was running. I'm okay for you to reload staging
[05:18] <Kinnison> cprov: can you disable the buildd sequencer? I'll turn off the cronjobs
[05:19] <cprov> Kinnison: sure
[05:19] <Kinnison> thanks
[05:19] <cprov> Kinnison: was already down 
[05:19] <Kinnison> thanks
[05:40] <ddaa> https://chinstrap.warthogs.hbd.com/~david/bzr-launchpad.ps
[05:41] <ddaa> the html export is disappointingly buggy, I can hack something up in Python to do it correctly in a few hours
[05:42] <kiko> ddaa, that work is amazing!
[05:42] <kiko> I will confess I started on an article on the soyuz archive manager today as wel
[05:42] <kiko> l
[05:42] <kiko> it was going to be a surprise but, well, you kicked my ass!
[05:42] <ddaa> it helps to have a word processor that does not get in your way too much
[05:42] <kiko> I am writing LaTeX of course :-P
[05:42] <ddaa> I'm a bit disappointed that nobody appears to have come up with something better than TeXmacs after all this time...
[05:44] <ddaa> kiko: would be nice if you could nudge spiv, jblack and lifeless to give me some feedback.
[05:44] <ddaa> I'm certain important bits are missing and some are probably incorrect.
[05:45] <kiko> ddaa, please use email at this time, I am currently unable to reach for mutt
[05:45] <kiko> when I am back in brazil, certainly
[05:45] <ddaa> kiko: right, EMAIL...
[05:45] <ddaa> I was thinking of nudging them in IRC, since you seem to be watching over the IRC client all day long.
[05:46] <kiko> I actually am, you're right
[05:46] <kiko> but that's because my code doesn't run
[05:46] <ddaa> I do not really want to get too much exposure before getting feedback from the people in the know. I will email privately.
[06:10] <SteveA> i've created a launchpad-infrastructure team
[06:11] <Kinnison> I noticed :-)
[06:11] <Kinnison> daf's been giving it my bugs
[06:11] <SteveA> it can be the assignee for infrastrucuture bugs
[06:11] <SteveA> and all Kinnison's bugs
[06:11] <Kinnison> yay
[06:11] <Kinnison> no more bugs for me
[06:11] <SteveA> i just added a very few people to that team
[06:11] <SteveA> but i know that other people do infrastructure work too
[06:12] <SteveA> so, join the team if you think you should be on the team
[06:12] <SteveA> cprov: you've done good gpg infrastrucuture work, so i think you should be on it 
[06:12] <SteveA> salgado: you've worked on sqlobject and vocabularies
[06:12] <SteveA> BjornT: you've done email infrastructure work
[06:12] <carlos> will be back in a couple of hours
[06:12] <SteveA> and i'm sure there are other cases too
[06:13] <cprov> SteveA: ok, I will
[06:16] <cprov> SteveA: apparently I can't join the team, reporting a bug 
[06:16] <SteveA> interesting.
[06:16] <SteveA> are you a launchpad admin?
[06:17] <salgado> cprov, that's a restricted team, and it says new members can only be added by one of the team admins
[06:19] <salgado> IOW, that's not a bug
[06:19] <cprov> salgado: aha, tell steve, forbidden lp-admin actions utterly obscure 
[06:23] <kiko> oh
[06:23] <kiko> salgado, cprov is a launchpad admin.
[06:23] <SteveA> kiko: so, experimenting with malone and assigning bugs to teams
[06:24] <SteveA> unless we change something about assignment to teams, there's still a need for keywords
[06:24] <SteveA> so, daf's just been assigning infrastructure-related bugs to the new launchpad-infrastructure team
[06:24] <salgado> cprov, then you can go there and add yourself as a team member, you don't need to join that team
[06:24] <SteveA> which is fine, and a good use of a team instead of a keyword, seeing as we have no keywords
[06:24] <SteveA> but what happens when someone from that team takes on the bug?
[06:24] <cprov> salgado: uhm ... right
[06:24] <salgado> I mean, you don't need to ask to join the team, which is what the 'Join' link means
[06:25] <SteveA> we lose the information that it is an infrastructure bug
[06:25] <kiko> right
[06:25] <kiko> you could CC the team to the bug though
[06:25] <SteveA> salgado/cprov: i'll be changing the way that admin privs are granted very soon, as part of some optimisation work
[06:26] <cprov> salgado: it worked, thanks 
[06:26] <SteveA> so all actions will be available to admins automatically, except in some very special cases
[06:26] <SteveA> kiko: i guess we could cc the team to the bug
[06:27] <kiko> SteveA, that would avoid the assignee nuking the bug off the map.
[06:27] <SteveA> yes
[06:27] <cprov> SteveA: I see, it'll be tough
[06:27] <kiko> BjornT, does this latest patch also make sure that reassigning product or package name changes the bug contact?
[06:27] <SteveA> cprov: what will be tough?
[06:28] <cprov> SteveA: fix permission properly 
[06:33] <SteveA> kiko: i've mailed stu and asked him to change the assignments in question to ccs
[06:33] <SteveA> thanks for the idea
[06:35] <kiko> sure, my pleasure
[06:40] <SteveA> matsubara: https://chinstrap.warthogs.hbd.com/~daf/bugs/scrape.py
[06:40] <SteveA> matsubara: do you have access to that page?
[06:40] <matsubara> SteveA: nope
[06:41] <SteveA> ok
[06:41] <kiko> yes jordi?
[06:41] <SteveA> when you do... it is a useful script daf is developing to help triage and organize launchpad bugs
[06:41] <BjornT> kiko: no, reassigning product or package still doesn't subscribe the bug contact. 
[06:42] <daf> SteveA: /home/daf/public_html/bugs is in bzr
[06:43] <kiko> BjornT, okay, we need to fix that.
[06:44] <matsubara> SteveA: ok. bookmarked it and will take a look when I have access. btw, who should I ask for to get an account on chinstrap?
[06:44] <jordi> kiko: nothing, really
[06:44] <jordi> kiko: just a strange "hey dude!" :)
[06:45] <BjornT> kiko: yeah i know, i just didn't want to spend time on that with this patch. if you think it's urgent, i can fix it this week if you want.
[06:45] <SteveA> matsubara: we'll sort all that out tomorrow
[06:46] <matsubara> SteveA: ok, thanks.
[06:46] <ddaa> It's interesting how documenting something helps understanding it...
[06:48] <ddaa> I just remembered how the roomba/hoover system was largely implemented to support the constraints of the Arch namespace...
[06:48] <ddaa> We probably will not need that anymore with bzr.
[06:49] <BjornT> SteveA: can you add me to the infrastructure team? i'm not an admin, so i can't add myself.
[06:49] <SteveA> ok
[06:49] <ddaa> Mh... it would still be useful until we have something that can do better scheduling than buildbot...
[07:04] <kiko> BjornT, I think it should be done -- don't know if it's very important.
[07:12] <carlos> is there anyone else having problems with launchpad?
[07:13] <kiko> carlos, where?
[07:14] <carlos> kiko: I'm not able to load any page
[07:14] <carlos> I'm getting timeouts
[07:14] <carlos> but not from launchpad's but firefox
[07:14] <carlos> it says the page cannot be loaded
[07:15] <carlos> it could be my connection as it's doing weird things since I got it back...
[07:15] <kiko> works for me
[07:15] <carlos> ok
[07:21] <kiko> daf, where's dilys?
[07:21] <daf> oh, good point
[07:22] <daf> muse.19inch.net had an IP change
[07:24] <kiko> great.
[07:24] <kiko> dilys, tell the world about my latest and greatest landing to PQM
[07:25] <Kinnison> < dilys> Kiko has landed a great big pile of poo^Wgina updates.
[07:26] <dilys> it's not that great, really
[07:26] <kiko> ha ha
[07:30] <kiko> paste utility!
[07:30] <kiko-afk> bbabl
[07:33] <dilys> Merge to devel/launchpad/: r=elmo, Add support to Gina for doing publisher overrides when it encounters newer indices with updated information, corresponding to a post-initial-publication change in the archive (such as changing components) (r3050: Christian Reis)
[07:56] <dilys> Merge to devel/launchpad/: [trivial]  paste utility (r3051: Dafydd Harries)
[08:34] <lamont-work> lifeless: what's the chance of bazaar getting it's unaligned loads fixed for dapper???
[08:34] <lamont-work> just curious
[08:45] <lifeless> does the patch work? NMU away
[09:07] <sivang> Kinnison: Keybuk pinged you for core developement member ship on u-m , you around? :)
[09:08] <Kinnison> yes
[09:29] <dilys> Merge to devel/launchpad/: [trivial]  More DB security fixes for Soyuz rollout (r3052: Celso Providelo)
[10:07] <salgado> SteveA, have you seen my reply to your email about the OOPS report on shipit? (it contains the patch with the fix)
[10:24] <zyga> can I ask for admin support?
[10:24] <zyga> alacarte is not available for translation
[10:24] <zyga> https://launchpad.net/products/alacarte/+translations
[10:27] <carlos> zyga: did you imported the files there already?
[10:27] <zyga> carlos: no but the project is there 
[10:27] <zyga> carlos: hello by the way :-)
[10:27] <carlos> zyga: hi
[10:28] <carlos> zyga: the maintainers must agree on using Rosetta before the import is done
[10:28] <zyga> ack
[10:28] <carlos> zyga: and someone should do that import
[10:29] <zyga> I'm asking the upstream author, is that enough?
[10:29] <carlos> zyga: if he/she agrees, yes
[10:29] <carlos> zyga: look at the RosettaFAQ pages
[10:29] <zyga> carlos: he just did in #ubuntu-devel
[10:29] <carlos> there you have what we request
[10:31] <zyga> carlos: so now what?
[10:31] <carlos> zyga: import the .pot and .po files available for that product
[10:31] <carlos> and jordi will handle the request
[10:32] <zyga> carlos: how can I do the former?
[10:32] <carlos> go/create the product series
[10:32] <carlos> and then from the overview menu (will moved soo to the translations one) select 'request import'
[10:33] <zyga> release series?
[10:33] <carlos> yes
[10:33] <zyga> okay
[10:33] <zyga> carlos: so a name like "0.8", with display name "0.8 (dapper)" makes sense/
[10:34] <carlos> 0.8 (dapper) ???
[10:34] <carlos> why dapper?
[10:34] <zyga> okay I misunderstood
[10:35] <zyga> both simply 0.8 and that's fine
[10:35] <carlos> zyga: are you importing it to have it available with dapper?
[10:35] <carlos> that's completely wrong...
[10:35] <zyga> carlos: in the end yes
[10:35] <zyga> ohh...
[10:35] <zyga> :-)
[10:35] <carlos> zyga: dude Ubuntu translations are automatically imported
[10:36] <carlos> dapper, will be open to translate next month
[10:36] <zyga> carlos: I promise to learn about this with my first project available thru rosetta
[10:36] <carlos> i hope in one or two weeks
[10:36] <zyga> carlos: ????
[10:36] <zyga> carlos: we're past the freeze alredy
[10:36] <ajmitch> zyga: string freeze?
[10:37] <zyga> ajmitch: upstream freeze
[10:37] <carlos> zyga: I think we still have 3 months until dapper is released....
[10:37] <ajmitch> yes, but are translations opened at string freeze or UVF?
[10:37] <carlos> zyga: feature freeze != string freeze
[10:37] <carlos> anyway I don't know the exact schedule
[10:38] <zyga> carlos: yes but since translators are always late it doesn't hurt to open early anyway
[10:38] <zyga> carlos: I know about the inequality
[10:38] <carlos> dude, we didn't open it before due technical reasons, not because we didn't want to do it...
[10:39] <zyga> ah
[10:39] <zyga> that makes sense then