[01:22] <torre> Hi
[01:23] <torre> im from Brazil...
[01:23] <torre> Im work in one governation organization
[01:25] <torre> all spleeping?
[01:25] <torre> sorry my bad english
[01:25] <torre> helloooooooooooooooooo
[01:36] <torre> Helloooooooooooooooooooooo
[02:59] <Lord_Athur> hi all
[03:53] <panickedthumb> hey, I'm all signed and everything, email still isn't working
[03:53] <panickedthumb> sorry, to those who are confused, I'm referring to this:
[03:54] <panickedthumb> https://launchpad.net/bugs/53679
[03:54] <Ubugtu> Malone bug 53679 in launchpad "member email" [Untriaged,Rejected]  
[03:54] <panickedthumb> I signed the CoC before Launchpad came around
[03:54] <panickedthumb> was unaware I needed to do it again
[03:54] <panickedthumb> but it's done now
[03:58] <panickedthumb> am I still missing something?
[04:03] <panickedthumb> I'll be idle here, if you want to chime in and let me know. Thanks
[04:04] <stub> panickedthumb: What is your Launchpad username? I can check out the basics and then escalate the problem.
[04:04] <milosz> hey guys, i wish in the package section you would be able to upload packages build for ubuntu (with a repo people can add) since the package menu is kind of frustrating for people who don't have packages in ubuntu
[04:07] <stub> milosz: You might want to file a wishlist bug on Soyuz - the people who work on that (and can understand what you are asking for) are not online yet.
[04:11] <panickedthumb> stub: panickedthumb
[04:12] <cprov> stub: ping
[04:12] <panickedthumb> stub: wikiname is TravisNewman, if that has anything to do with it
[04:15] <stub> panickedthumb: I suspect that this is simply a propagation delay. If it takes more than 24 hours to become active, reassign your bug to james.troup@canonical.com (as he is the only person who can investigate further). If it starts working, you might want to leave the bug open with a comment requesting better documentation about the time delay.
[04:15] <stub> cprov: pong
[04:16] <panickedthumb> good plan stub
[04:16] <panickedthumb> thanks :)
[04:16] <cprov> stub: when do you plan to do the rollout ?
[04:17] <stub> cprov: When do you plan on being awake? I don't think malcc will be here for a few hours yet.
[04:17] <stub> Although I think I can do the rollout anytime, as the database updates will not affect the current soyuz installation
[04:18] <stub> So I just need to update everything except soyuz
[04:19] <cprov> stub: yes, right, you can rsync production into drescher, just don't replace the "current" symlink.
[04:20] <stub> ok. So I will do the rollout as normal, except for keeping the codeline on drescher untouched. I will then leave it to you and Malcolm to change the current symlink at your leisure. 
[04:20] <cprov> I'll be here in, let's say 5 hours, it will be ~ 8:00 AM UK
[04:20] <cprov> stub: perfect, thank you.
[04:39] <lifeless> stub: have you had a chance to look at plitting manifests?
[04:40] <stub> plitting? Oh... splitting. I've looked it over but not started on the db patch. I'll do that today.
[04:41] <stub> lifeless: ^^^
[04:41] <lifeless> thanks!
[04:46] <Mhz_> hi
[04:48] <Mhz_> wow
[04:48] <Mhz_> huge party here
[04:48] <Mhz_> EEEEEEoooooooo
[04:48] <Mhz_> there's echo
[04:49] <Mhz_> hi, my name is matt
[04:49] <Mhz_> I have suggestions regarding launchpad
[04:49] <Mhz_> which is becoming some sort of a crashpad for me
[04:50] <Mhz_> ubuntu
[04:50] <Mhz_> is
[04:50] <Mhz_> great
[04:50] <Mhz_> someone?
[04:50] <Mhz_> plz?
[04:50] <Mhz_> ok
[04:51] <Mhz_> bye
[04:57] <stub> Give the boy a valium
[06:01] <mpt_> Gooooooooooooooood afternoon Launchpadders!
[06:02] <ajmitch> hi mpt_ 
[07:18] <mpt_> spiv, can you ssh to sodium?
[07:20] <spiv> I can, although it doesn't have my ssh key.
[07:21] <mpt_> hrmm, I get no response
[07:22] <mpt_> Spads!
[07:23] <spiv> mpt_: do you have your ssh config setup correctly, as elmo mentioned in his mail to the launchpad list?
[07:23] <mpt_> Yes, I just did that
[07:23] <mpt_> Before I did it, ssh said "sodium: Name or service not known", but now it hangs instead
[07:25] <spiv> What happens if you try "ssh -vv ..."
[07:26] <mpt_> spiv, it gets up to "debug1: Connecting to sodium.ubuntu.com [82.211.81.198]  port 22.", and stays there
[07:27] <spiv> mpt_: that's wrong.
[07:27] <spiv> mpt_: it should be connecting via chinstrap.
[07:27] <spiv> mpt_: so your ssh config must be incorrect somehow -- you're probably missing an ProxyCommand.
[07:28] <mpt_> Should I have a "Host sodium" section in the config, modelled on the "Host chinstrap" section?
[07:28] <mpt_> (that's what I assumed)
[07:29] <spiv> mpt_: if you have the lines elmo included in his recent email, "ssh sodium.ubuntu.com" should work.
[07:29] <spiv> mpt_: if you want "ssh sodium" to work, then you need a "Host sodium" stanza in your ssh config, but it will need an explicit ProxyCommand line.
[07:30] <spiv> mpt_: which is different to chinstrap, because chinstrap is the only externally accessible box.
[07:31] <mpt_> Now it's connecting, and asking me for a password
[07:31] <mpt_> and my SSH passphrase doesn't work
[07:32] <spiv> it'll be your password in the datacentre, assuming you have one.
[07:32] <stub> Your standard ssh key should work - mine just did
[07:32] <spiv> stub: Hmm, mine must be setup differently to yours then.
[07:32] <spiv> I needed to add an authorized_keys file, like I had on chinstrap.
[07:33] <spiv> Probably I need to poke at the internal ldap...
[07:33] <mpt_> ssh asked me to accept sodium.ubuntu.com, is that what you're referring to?
[07:33] <stub> spiv: Maybe the key stored in the ldap server is an old key, possibly from your missing laptop
[07:34] <stub> mpt_: Nope - that is just your local ssh asking if it should trust the remote server key because it hasn't been seen before.
[07:34] <spiv> stub: likely, I suppose.
[07:35] <spiv> mpt_: refer to the MachineOverview page on the internal wiki
[07:36] <spiv> mpt_: It says how to send an email to set your SSH key.
[07:36] <mpt_> ooh, nifty
[07:58] <lifeless> ok, so chinstrap has 200G of source
[07:58] <mpool> hullo
[07:59] <lifeless> hi
[08:00] <mpool> spiv: ping?
[08:00] <stub> lifeless: most of which is just noise I would expect. Perhaps just move the launchpad tree across and developers can push repositories to sodium themselves?
[08:00] <lifeless> stub: rocketfuel is moved
[08:01] <lifeless> stub: I'm generating a list to get elmo to rsync, but yes, we can also have people copy their own across
[08:02] <spiv> mpool: pong
[08:03] <spiv> I'm happy to move mine myself.  I can make sure I put all my old branches into repos as I do, rather than just my new branches.
[08:04] <mpool> spiv, hi
[08:05] <mpool> robert suggested talking to you to change some static text about bazaar on the launchpad.net front page - he says it's hardcoded in the source
[08:05] <mpool> or rather, not editable through the web interface
[08:06] <mpool> i'll send you a mail
[08:06] <spiv> Ok.
[08:08] <mpool> sent; should be pretty trivial
[08:17] <lifeless> stub: its finished
[08:57] <spiv> mpt__: my ssh key change has finally happened, can you connect to sodium now?
[09:10] <mpt__> spiv, no
[09:11] <sivang> morning folkies
[09:12] <spiv> mpt: have you gotten a reply to your change@ email yet?
[09:13] <mpt> yes
[09:13] <mpt> The "Here are the results:" section is empty
[09:13] <spiv> Oh.
[09:13] <mpt> So I guess that wasn't the problem to begin with
[09:14] <spiv> mpt: ah, I'm guessing maybe you have a .ssh/id_dsa.pub file, rather than a .ssh/id_rsa.pub file?
[09:14] <mpt> correct
[09:14] <spiv> (that was true in my case, so I had to adjust the example command line on the wiki page accordingly)
[09:14] <mpt> d'oh
[09:15] <mpt> ok, I'll update the wiki page
[09:15] <spiv> mpt: well, your public key can be in either file, it just depends on what type of key you generate.
[09:15] <spiv> mpt: NewStaffTasks also has that command, btw.
[09:16] <spiv> mpt: You should get back a message quoting back the message you sent (which shouldn't be empty!), and then saying "SSH Keys replaced with ..."
[09:19] <spiv> mpt: the "cat: .ssh/id_rsa.pub: No such file or directory" should have been a hint that something was wrong
[09:20] <mpt> grrrr, it will once I start from the correct directory
[09:25] <mpt> hooray
[09:25] <cprov> good morning 
[09:26] <cprov> stub: how is it going with the rollout ? did you already start ?
[09:28] <mpt> spiv, why is init-repo on sodium better than just copying all my branches over from chinstrap?
[09:32] <mpt> wow, bug 7839 is horrid
[09:32] <Ubugtu> Malone bug 7839 in Ubuntu "Ubuntu bug reporting tools need to point to Ubuntu bug systems" [High,Confirmed]  http://launchpad.net/bugs/7839
[09:36] <mpt> oh, it's better because I wasn't using a repository before
[09:36] <spiv> mpt: if you use init-repo in say mpt/launchpad, then bzr pull your branches into that, then all the common revision data will be stored once, rather than duplicated for each branch.
[09:37] <spiv> (pushing works too)
[09:37] <mpt> ok
[09:37] <spiv> It also means that pushing a new branch to chinstrap without rsync is still reasonably quick.
[09:38] <spiv> er, s/chinstrap/sodium/ :)
[09:43] <mpt> spiv, so to bring a branch into my repository it's just bzr branch chinstrap:/home/warthogs/archives/mpt/launchpad/nameofbranch ./nameofbranch ?
[09:43] <mpt> or bzr pull?
[09:47] <spiv> mpt: "bzr get sftp://chinstrap/home/warthogs/archives/..."
[09:48] <spiv> (or "bzr branch" if you prefer, "get" is just a synonym for "branch")
[09:51] <mpt> grr
[09:52] <mpt> spiv, when I do that and paramiko says "Password:", what password is it referring to?
[09:52] <mpt> My SSH password didn't work
[09:52] <mpt> and neither did the usual chinstrap one
[09:53] <spiv> mpt: oh, right.  your datacentre password, and I guess you don't have one, as per our earlier conversation...
[09:53] <mpt> off to RT, then
[09:53] <spiv> There may be a magic SSH switch to deal with this, just a sec
[09:54] <spiv> mpt: connect to sodium with "ssh -A sodium"
[09:55] <mpt> Name or service not known, ho ho
[09:55] <spiv> mpt: Oh, right.  Well, "ssh -A ..." :)
[09:55] <mpt> yay, stuff is happening
[09:56] <mpt> thanks spiv
[09:56] <spiv> mpt: You can set the ForwardAgent option in .ssh/options to make that permanent.
[09:56] <spiv> er, .ssh/cnofig
[09:56] <spiv> config.
[09:57] <mpt> in the *.ubuntu.com section?
[09:58] <spiv> Somewhere, probably there.
[09:58] <spiv> It's easy to test if it's working ;)
[10:04] <mpt> This will apparently take quite some time
[10:05] <SteveA> hi
[10:06] <spiv> I have set up a new pastebin on sodium: https://sodium.ubuntu.com/~andrew/paste/
[10:08] <spiv> mpt: it'll probably go faster if the first thing you do in the repo is "bzr branch /home/warthogs/archives/rocketfuel/launchpad/devel ./rf"
[10:09] <spiv> mpt: you can even delete ./rf afterwards, but that will get all the revisions from rocketfuel from a local directory, so they won't need to be fetched over sftp.
[10:09] <mpt> Should I cancel the current branching to do that? :-)
[10:10] <spiv> mpt: Also, call your launchpad directory "launchpad" rather than "lp", or else pending reviews won't be happy.
[10:10] <spiv> Yeah, that should be ok, I think.
[10:15] <SteveA> spiv: can we move across old pastes?  and if so, is it worth doing?
[10:15] <carlos> morning
[10:15] <spiv> SteveA: 1) yes, quite easily, 2) not sure.
[10:16] <danilos> carlos: morning ;)
[10:16] <carlos> danilos: hey dude!, long time since last time we meet! ;-)
[10:17] <danilos> carlos: yeah, looking forward to you buying me a beer when we meet again :P
[10:17] <carlos> hmmmm, what's a beer?
[10:17] <carlos> danilos: do I know you?
[10:17] <spiv> SteveA: people generally access pastes by URL, but copying them across won't help the old URLs to find the new pastebin instance.
[10:18] <SteveA> ok
[10:18] <SteveA> so we won't copy them across
[10:18] <SteveA> they'll be accessible on chinstrap again eventually
[10:18] <spiv> Well, they should still be accessible on chinstrap.
[10:18] <spiv> Just that you can't add new ones.
[10:19] <spiv> SteveA: e.g. https://chinstrap.ubuntu.com/~dsilvers/paste/filecrSEwC.html works just fine.
[10:20] <mpt> spiv, have you tried your own paste service?
[10:20] <spiv> mpt: yes.
[10:20] <mpt> Submitting it gives me a blank page, just like Kinnison's one does
[10:20] <mpt> Is there a chinstrap reference lurking in the code somewhere?
[10:20] <spiv> mpt: well, it's Kinnison's code...
[10:21] <spiv> mpt: Hmm, that suggests your browser isn't following the redirect?
[10:21] <spiv> mpt: was your paste "test1"/"test2"?  Posted twice?
[10:22] <spiv> (it's hard to tell, because I just did a "test 1"/"test 2", so it's all a bit confusing ;)
[10:22] <mpt> spiv, yes
[10:22] <spiv> mpt: Basically, all it does is emit this:
[10:22] <spiv> Content-Type: text/plain
[10:22] <spiv> Refresh: 0; URL=https://sodium.ubuntu.com/~andrew/paste/$name
[10:22] <spiv> Which is rather low tech.
[10:22] <SteveA> lifeless: ping
[10:23] <lifeless> pong
[10:23] <carlos> spiv: I think the paste service has an index with the titles of previous pastes there
[10:23] <spiv> It's a dumb CGI that doesn't even set a proper http status code.
[10:23] <mpt> well, it no worky
[10:23] <spiv> carlos: it sure does.
[10:23] <spiv> mpt: what browser?
[10:23] <SteveA> hi lifeless.  we should work out what we want the launchpad developers to do, and send an email out with a fresh subject line explaining it.
[10:23] <carlos> spiv: wouldn't that be used to get old 'pasted' texts ?
[10:23] <lifeless> SteveA: spiv has been working on this, could we ask him to do that ?
[10:24] <SteveA> lifeless: is it clear to you what the plan is -- what people need to do?
[10:24] <SteveA> I've seen two things pass by in the email thread, one from you and one from mark
[10:24] <mpt> spiv, Safari, but Safari *used* to work...
[10:24] <lifeless> SteveA: yes. I replied to Marks but it seems to have awoled
[10:24] <mpt> I see Firefox works
[10:24] <SteveA> lifeless: is spiv clear on what needs to be done, and does he have all required access to do it?
[10:24] <spiv> mpt: well, I haven't changed Kinnison's code except s/chinstrap/sodium/ and s/dsilvers/andrew/
[10:24] <lifeless> SteveA: lets talk with him now
[10:25] <SteveA> mpt, spiv: we can support safari later.
[10:25] <spiv> lifeless, SteveA: hi :)
[10:25] <SteveA> hello andrew
[10:25] <lifeless> spiv: SteveA and I would like to put a new email together with clear TODO instructions
[10:25] <spiv> mpt: I'll put in a simple workaround for you.
[10:25] <spiv> mpt: if you need it.
[10:25] <spiv> mpt: but you can go and find your link on the list.cgi page after pasting.
[10:25] <mpt> no, I don't need it particularly
[10:25] <lifeless> spiv: I like the idea of going to repos for everyone, as Mark suggested.
[10:25] <spiv> mpt: ok, I'll be lazy then :)
[10:25] <mpt> anything interesting I paste is from Ubuntu anyway
[10:25] <spiv> lifeless: sounds good.
[10:26] <spiv> lifeless: you want me to write up the details of how to do this, similar to what I've helped mpt with on this channel?
[10:26] <mpt> spiv, Konqueror downloads the file instead of displaying it in the browser
[10:26] <SteveA> where there are things we can just *do* for everyone, we should do it
[10:27] <mpt> spiv, actually, it downloads an *empty* file that doesn't contain the text I pasted
[10:27] <SteveA> the rest should be in a clear DOIT email
[10:27] <SteveA> actually
[10:27] <SteveA> better is a clear DOIT wiki page
[10:27] <spiv> mpt: fun.
[10:27] <SteveA> because then we can update the instructions
[10:27] <SteveA> without sending multiple emails
[10:27] <lifeless> SteveA: the problem is, that we cannot tell what is relevant or not for each developer
[10:28] <lifeless> SteveA: it *needs* to be documented and done by each developer.
[10:28] <lifeless> spiv: so, are you up for this?
[10:28] <SteveA> I don't think individual developers have all that much data in bzr knit format
[10:28] <lifeless> SteveA: historical data, we can and will do for people
[10:28] <SteveA> it is feasible to say "we copy over just bzr knit trees" ?
[10:28] <spiv> lifeless: I think so, but I want to be sure I understand exactly what I'm meant to do....
[10:30] <spiv> Do you want me to document how to move branches from chinstrap into a repo on sodium?
[10:30] <lifeless> SteveA: I deleted 8Gb of a 9Gb tree I copied over due to cruft
[10:30] <lifeless> SteveA: so just saying that to the developers may be neither clear enough, nor appropriate.
[10:31] <lifeless> spiv: I'd like you to document how to
[10:31] <SteveA> lifeless: my proposal is, *we* determine which are bzr branches in knit format, and copy all those over.
[10:31] <spiv> Why does it matter if they are in knit format?
[10:32] <lifeless>  *) make a shared repo on sodium for each project - one for lp, one for bzr etc - in /home/warthogs/archives/$user/$project
[10:32] <spiv> I'm assuming the vast majority of revisions are merged into rocketfuel.
[10:32] <stub> cprov: haven't started yet - I needed a nap ;)
[10:32] <SteveA> spiv: because those are the only branches that may be currnet
[10:32] <lifeless>  *) pull into that each branch they wish to preserve as a branch 
[10:32] <spiv> So if we use shared repos, there's very little cost to having old branches included.
[10:33] <SteveA> right
[10:33] <lifeless> SteveA: no, we cant do that except as root. permissions will kill you. Also a lot of the wasted space is due to non-repo based branches
[10:33] <spiv> And part of the process of pulling branches into the repo is that all branches would be knits (that are stored in the shared repo).
[10:33] <lifeless> SteveA: which have working trees and other undesirables.
[10:33] <cprov> stub: no worries, ping me when you need 
[10:33] <SteveA> let's do it as root, OR do it as one user, and get the permissions changed as root after we've done it
[10:33] <spiv> The only problem with copying a weave branch is that it would be slower.
[10:34] <SteveA> we can get special things set up just for today
[10:34] <lifeless> spiv: if its going into a repo, and the repo is in knit format, it should be fast as long as the repo has already got most of the data
[10:34] <spiv> lifeless: yeah, that's what I thought.
[10:34] <spiv> lifeless: (hence my intentionally vague use of the term "slower", rather than "much slower" ;)
[10:35] <spiv> But I agree with Steve, I think we could automate this for everyone.
[10:35] <lifeless> SteveA: I can start figuring out how much data is in knit format. I expect most of the 215Gb will be in knit format branches, and if so, then we still cant trivially do it as a batch process
[10:35] <stub> cprov: I think r3819 should be rolled out - you happy with that?
[10:36] <stub> (that is the soyuz patch that landed patch-67-06-0.sql with the pocketroot.chroot not null
[10:36] <cprov> stub: yes, it's exactly what i'd claim.
[10:36] <spiv> We're looking at about ~220Mb per user for launchpad, that's about how big the repo is for rocketfuel's launchpad.
[10:36] <jamesh> spiv: I had a little script to do the "pull lots of branches into a repo" if that'd help
[10:36] <spiv> jamesh: I think I still have it swimming around my desktop somewhere ;)
[10:37] <jamesh> http://people.ubuntu.com/~jamesh/make-bzr-repo.sh
[10:37] <lifeless> if we do the conversion properly, we can get by with 1Gb per user - and that allows lots of users
[10:38] <spiv> lifeless: properly meaning shared repos and no working trees?
[10:38] <lifeless> spiv: yes.
[10:38] <lifeless> on chinstrap rocketfuel was 9Gb, on sodium, I've got it down to 1Gb
[10:39] <spiv> Just making sure I'm not forgetting anything important :)
[10:39] <lifeless> at that size, we could not have migrated everyone at all.
[10:40] <lifeless> SteveA: I replied, did you get my reply?
[10:41] <SteveA> I just received an email from you
[10:41] <lifeless> cool
[10:41] <lifeless> right now on chinstra, your bzr trees take up 7Gb
[10:41] <lifeless> I think its much saner to delegate *deciding* what to keep to each developer.
[10:42] <SteveA> I'm happy with the direction you and spiv are going in.  I just want to ensure you've thought through the different options, as we've had problems when we've asked everyone to follow some particular instructions before
[10:42] <lifeless> as, for instance, I have no idea which of your branches are useful or not.
[10:42] <SteveA> people choose to vary the instructions without being fully informed about why they are as they are 
[10:42] <SteveA> and then other things break
[10:42] <SteveA> for example, people using "launchpad-repository" as their repository directory on chinstrap broke pending-reviews
[10:43] <lifeless> SteveA: ok, in which case, yes, I think we have no better choice than good doco. But we can be very precise about what is user-varyable, and what is not.
[10:43] <SteveA> so, I figure it is worth at least exploring setting up everything for everyone in a consistent way
[10:43] <lifeless> spiv: how is this sounding to you ?
[10:43] <lifeless> SteveA: we can automate the repo initialisation with a little admin chmod love
[10:44] <lifeless> spiv: by that I mean do 'init-repo $user/launchpad && bzr branch rocketfuel/launchpad/devel $user/launchpad/devel && chmod $user $user -R' for each user
[10:44] <lifeless> which will give people a lot less guesswork about where things go
[10:46] <spiv> lifeless: I see no reason why we shouldn't do that.
[10:47] <spiv> It eliminates the entire "Do once" section of the doc I was just sketching out.
[10:48] <SteveA> spiv: I propose that you put your docs up on a wiki page at SodiumSetup on the launchpad wiki.
[10:49] <SteveA> then mail the list and tell people that instructions will appear on that page, and invite people to subscribe to that page if they would like to
[10:49] <spiv> lifeless, SteveA: if we do that, then the migrate procedure becomes a very simple: "ssh -A sodium; cd /home/warthogs/archives/$USER/launchpad; bzr get sftp://chinstrap/home/warthogs/archives/$USER/launchpad/$BRANCH", where $USER and $BRANCH are replaced by the user, of course.
[10:49] <SteveA> then we work on instructions here, and put them on that page when they are done
[10:49] <SteveA> that way, people catching up with the mail thread on the launchapd list will not be so confused
[10:49] <spiv> (and then of course they need to remember to push to the new location, etc)
[10:50] <SteveA> and will have clear direction from us
[10:50] <spiv> SteveA: I'll do that.
[10:50] <spiv> SteveA: but I think it would be great to do what lifeless suggests, to do the common, necessary steps for everyone automatically.
[10:51] <SteveA> I agree wholeheartedly
[10:51] <spiv> SteveA: can you or lifeless make that happen?
[10:51] <SteveA> I'll do it now
[10:51] <spiv> SteveA: excellent
[10:52] <spiv> SteveA: Moin claims you are editing SodiumSetup
[10:52] <SteveA> yes
[10:52] <SteveA> I just said I'd do it now
[10:53] <SteveA> the documentatio should appear there only when the system is prepared too
[10:53] <SteveA> including permissions etc.
[10:53] <spiv> Oh, I thought you said for me to make that page.  Ah, ok.
[10:56] <lifeless> spiv: please dont use bzr get 
[10:56] <spiv> lifeless: "bzr branch", sorry :)
[10:56] <lifeless> spiv: its confusing because it does not do what baz get did, instead use and document 'bzr branch'
[10:56] <spiv> I'm a lazy typist on IRC.
[10:57] <lifeless> lazy good, wrong bad :)
[10:57] <lifeless> brb
[10:57] <spiv> Well, not so lazy that I use all lower-case or omit punctuation... ;)
[10:57] <SteveA> will bzr get be deprecated soon?
[10:58] <spiv> lifeless: arguably, what "bzr branch" does isn't much like what "baz branch" did either ;)
[10:58] <spiv> lifeless: (I'll document bzr branch, of course.)
[10:59] <lifeless> spiv: well, it makes a new bzr branch for you, which is what baz branch did
[10:59] <lifeless> SteveA: it should get turned into an alias for checkout soon, which will make it do what baz get did do when it did do stuff
[10:59] <spiv> Heh, my fingers are trained to follow "sftp://" with "chinstrap".
[11:04] <doko> carlos: ping
[11:04] <carlos> doko: pong
[11:06] <doko> carlos: the OOo po's currently merge translations with the same msgid into one place; unfortunately that is broken in the current translate-toolkit. does rosetta have a problem, if I do not merge the msgid's for the next upload, and then turn merging on again, if translate-toolkit is fixed?
[11:08] <carlos> doko: rosetta will reject those .po files because are not valid
[11:08] <carlos> doko: wait, seems like we have a solution
[11:08] <doko> carlos: which one's are invalid?
[11:08] <carlos> danilos: could you explain him how to do that?
[11:09] <danilos> doko: PO files which have several messages with the same msgid are invalid
[11:09] <danilos> doko: you can fix them using 'msguniq' tool from gettext-tools
[11:10] <danilos> doko: (look at options --use-first and -u)
[11:10] <carlos> doko: so I guess you could use that command as a post processing tool until pootle fixes their code or we finish the native support for OO
[11:11] <doko> but aren't the message identifiers lost? "discard duplicates"
[11:11] <danilos> doko: yes, but I can explain what I did when I translated OOo to Serbian
[11:12] <doko> danilos: I think when you translated that, you did translate the 250 separate files ...
[11:12] <danilos> doko: nope ;-)
[11:12] <doko> danilos: but?
[11:13] <doko> if I discard the message identifiers, how can I convert back to the GSI format?
[11:13] <danilos> doko: I only had like 50 of them: http://prevod.org/programi/openoffice/2.0/osnovno
[11:13] <danilos> doko: well, the trick is to create a new (or several) big PO file and discard identifiers
[11:14] <danilos> doko: I created one per-directory of OOo
[11:14] <danilos> doko: and then used that to fill-in all the 250 of them using msgmerge
[11:14] <doko> ok, so how did you merge back these and generate the GSI file?
[11:15] <spiv> lifeless, SteveA: draft of the migration howto: https://sodium.ubuntu.com/~andrew/paste/fileOmZ7Eu.html
[11:15] <stub> I've disabled the soyuz cronscripts, pending the Launchpad update.
[11:15] <danilos> i.e. 'for i in sw/*.po; do msgmerge -u $i path-to-my-compilation/sw.po; done'
[11:15] <danilos> or something like that, I forgot the msgmerge syntax 
[11:15] <SteveA> spiv: /me looks
[11:15] <lifeless> spiv: please give a concordance of all the user ids
[11:16] <lifeless> spiv: rather than 'want to migrate', perhaps 'want to keep'
[11:17] <lifeless> spiv:    bzr sftp://sodium.ubuntu.com/home/warthogs/archives/$USER/launchpad/$BRANCH
[11:17] <lifeless> is missing a verb
[11:17] <lifeless>     # REPLACE "sqlobject" here with whatever component you need.
[11:17] <lifeless>     mkdir -p /home/warthogs/archives/$USER/
[11:17] <lifeless>     cd /home/warthogs/archives/$USER/sqlobject
[11:17] <lifeless> rather than saying 'REPLACE...'
[11:17] <lifeless> use $PROJECT or $COMPONENT
[11:18] <lifeless> also, init-repo will mkdir for you
[11:18] <spiv> Oh, I didn't know that.
[11:18] <spiv> (about init-repo)
[11:18] <lifeless> so bzr init-repo /home/warthogs/archives/$USER/$PROJECT
[11:18] <danilos> doko: maybe, the thing is that if you want a single PO file to be used, you can then use it as a compendium (-C option to msgmerge) to populate all the other PO files
[11:19] <lifeless> spiv: also, for the 'making other project', do an ls of rocketfuel and list all their names
[11:19] <lifeless> so there is no guesswork involved.
[11:19] <doko> danilos: I'll leave that to the rosetta implementation handling GSI files ;-P
[11:19] <lifeless> other than that, I think it looks good
[11:20] <mpt> wow, this is still taking forever
[11:20] <danilos> doko: well, your choice ;-)
[11:20] <spiv> lifeless: by concordance of all user ids, you mean list the user ids already in use on chinstrap vs. username?
[11:21] <lifeless> spiv: right. what should each user use for $USER
[11:21] <spiv> mpt: hmm, I'm surprised, it was quite fast to copy the few branches I've copied so far.
[11:21] <carlos> doko: the plan is to have such native support implemented in next two months
[11:21] <spiv> lifeless: does that really matter?
[11:21] <carlos> at least that's our timeline
[11:21] <mpt> aha
[11:21] <mpt> spiv, bzr info says this branch is in weave format 6
[11:21] <spiv> lifeless: Oh, I guess if the directories are being pre-made for them...
[11:21] <lifeless> spiv: exactly
[11:22] <spiv> mpt: interesting, lifeless reckoned that wouldn't be much slower.
[11:22] <mpt> at least, the branch is in branch format 4 and the repository is in weave format 6
[11:22] <lifeless> spiv: if most of the data is there
[11:22] <spiv> mpt: yeah, the repo format is the significant factor there.
[11:22] <lifeless> spiv: it is fast-pathed
[11:23] <lifeless> spiv: it will only be slow if it has to convert many revisions
[11:23] <spiv> mpt: it has to convert any revision in the weave not already in the local repo to a knit.
[11:23] <lifeless> spiv: note that 'slow' is relative, of course:)
[11:23] <spiv> mpt: which basically means each revision not yet merged to rocketfuel.
[11:24] <spiv> mpt: but in short, complain to your fellow kiwi ;)
[11:24] <spiv> lifeless: thanks for the feedback
[11:26] <lifeless> np
[11:26] <SteveA> spiv: the doc reads well to me.  well done.
[11:26] <SteveA> sometime later (not this week) I want us to consider moving /home/warthogs/archives/ to perhaps /home/branches or something like that
[11:26] <SteveA> or /home/code
[11:28] <lifeless> damn
[11:28] <lifeless> who sent the last commit through ?
[11:30] <lifeless> :$
[11:31] <lifeless> stub: can you please resubmit
[11:31] <stub> Resubmitting
[11:35] <lifeless> and again please
[11:35] <lifeless> stub: ^^
[11:36] <lifeless> jamesh: can you ask keybuk then ?
[11:36] <jamesh> lifeless: okay
[11:36] <lifeless> danke
[11:39] <stub> lifeless: resubmiting
[11:39] <lifeless> thanks
[11:39] <lifeless> theres a glitch
[11:39] <stub> SteveA: +1
[11:40] <SteveA> lifeless, spiv: we *could* do this now, if it won't complicate matters
[11:40] <lifeless> ok, it should got hrough
[11:40] <lifeless> SteveA: its nearly 8pm here, I'd really rather get everyone working, then plan other smaller transitions
[11:41] <mpt> hrmm
[11:41] <lifeless> mpt: how is that 'slow' branch going ?
[11:41] <mpt> lifeless, it's finished, but
[11:41] <mpt> I thought the idea of a repository was that it just stored the revisions, not a copy of each file in the codebase
[11:42] <mpt> but now I have a copy of each file in the codebase
[11:42] <malcc> mpt: *In* a repository, each *branch* just stores the revision info
[11:42] <malcc> mpt: You swap one copy per branch for one copy overall
[11:42] <lifeless> mpt: oh, I see what happened
[11:42] <lifeless> spiv: tweak/errata
[11:42] <mpt> Is it just because it was the first one I did?
[11:42] <SteveA> lifeless: fine
[11:43] <spiv> lifeless: what's the erratum?  what happened to mpt?
[11:43] <lifeless> spiv: if its a *really old* branch, in 'weave but not metaweave' format, it will preserve the format.
[11:44] <lifeless> spiv: so, the best way to do this is to do 'bzr init $BRANCH && cd $BRANCH && bzr pull chinstrap/....$BRANCH
[11:44] <spiv> lifeless: fix your damn software :P
[11:44] <spiv> Ok.
[11:44] <lifeless> spiv: its by design
[11:44] <mpt> we have boogs
[11:45] <spiv> lifeless: fix your design, then fix your software ;)
[11:45] <lifeless> mpt: can you rm that dir, then do what spiv is about to tell you :)
[11:45] <mpt> haha
[11:46] <mpt> At least I was doing something else, rather than just sitting there waiting for it
[11:46] <spiv> lifeless: would "bzr pull --format=knit" be adequate, or do we really have to do the bzr init/bzr pull dance?
[11:47] <jamesh> lifeless: given that I've got all my branches in a repo now, should I just copy that over to sodium?
[11:47] <lifeless> spiv: pull does not take a format option, neither does branch. *branch should*, *that* is a bug
[11:47] <lifeless> spiv: right now, its init + pull
[11:47] <lifeless> jamesh: yes
[11:47] <spiv> lifeless: damn.
[11:48] <jamesh> spiv: the script I mentioned does init+pull so should get it right
[11:52] <stub> Launchpad will be going down in 15 minutes for its regular code update. Estimated downtime will be 10 mins.
[11:55] <spiv> Latest draft: https://sodium.ubuntu.com/~andrew/paste/fileGtJim7.html
[11:55] <spiv> mpt: the instructions there should work for you.
[11:57] <stub> carlos: Do you think we are going to need to run poimport scripts in parallel in the future, or is the existing single process going to be fine?
[11:58] <mpt> thanks spiv
[11:58] <carlos> stub: well, I think we could try to implement it to do it faster, but that would increase the complexity. It would be interesting when we open a new distrorelease
[11:59] <SteveA> spiv: looks good.
[11:59] <SteveA> Rather than "bzr init" followed by "bzr pull", you can just use "bzr branch
[11:59] <SteveA> sftp://chinstrap/home/warthogs/archives/$USER/launchpad/$BRANCH" if you know
[11:59] <SteveA> that the branch is already in knit or metaweave format.  When in doubt, follow
[11:59] <SteveA> the instructions above.
[11:59] <SteveA> 
[11:59] <carlos> we take a couple of days to handle all imports when a new distribution is open
[11:59] <jamesh> spiv: the pending-reviews page currently doesn't work with sftp://sodium.ubuntu.com/ URLs -- it will continue to work with chinstrap URLs though (using the branches on sodium)
[11:59] <jamesh> spiv: I plan to fix this soon though
[11:59] <stub> carlos: couple of days sounds fine.
[11:59] <SteveA> spiv: that part about "if you know that the branch is already..." is confusing.  say how to find out.
[11:59] <spiv> SteveA: Hmm, I think I'll just remove that paragraph.
[12:00] <carlos> stub: yeah, perhaps when we get 5-10 distroreleases maintained in launchpad or 20 - 30 active products...
[12:00] <SteveA> spiv: okay.  also, james says he's updating the pending reviews stuff now
[12:00] <SteveA> spiv: so, the instructions can stay simple
[12:00] <SteveA> actually, we only need sftp://sodium/home/... on the pending reviews page
[12:00] <carlos> stub: anyway, I think the bottleneck there is the database
[12:00] <spiv> jamesh: Great.  If you can make it be true before I put this on SodiumSetup, that'd be perfect :)
[12:01] <SteveA> no need for the full sodium hostname
[12:01] <carlos> stub: so a single process with a faster DB server would work better ;-)
[12:01] <spiv> Well, it depends on how people have configured their SSH.
[12:01] <SteveA> spiv: depends what "it" is
[12:02] <SteveA> spiv: the pending reviews script will continue to work
[12:02] <stub> carlos: The database server has four cpus
[12:02] <spiv> Well, I guess that "it" depends on how people generate the URLs they add to PendingReviews.
[12:03] <SteveA> spiv: yes.  we should go for consistency and lack of redundancy.
[12:04] <SteveA> we can try symlinking /home/warthogs/archives to /home/code.  lifeless: would that work?
[12:04] <spiv> If they copy-and-paste them from "bzr info", or from their command history where they did the "bzr push sftp://..." (I assume people do one of these), then the URLs may be sftp://sodium/... or sftp://sodium.ubuntu.com/...
[12:04] <SteveA> spiv: would it make sense for you to use just 'soduim' in your doc?
[12:04] <SteveA> or would that be confusing?
[12:05] <carlos> stub: so we can use 3 poimport scripts + launchpad? ;-)
[12:05] <spiv> Well, "sftp://sodium.ubuntu.com/" always works, but for instance I don't think mpt has his system set up so that "sftp://sodium/" would work.
[12:05] <carlos> stub: you should not offer me such amount of resources or I will need more.... :-P
[12:05] <SteveA> spiv: okay.  do what you think will be clearest
[12:06] <lifeless> sodium.ubuntu.com is good
[12:06] <spiv> It's not a great leap to figure out why "sftp://sodium/" fails in that case, but I'm trying to avoid too much "do this, or this, or this, depending".
[12:07] <spiv> I'll fix it so that it consistently uses "sodium.ubuntu.com" rather than "sodium".
[12:07] <stub> carlos: if we need them. We could setup a second right now with no code modifications by running it on both gandwana and gangotri. I was mainly thinking of the 50k queue size jordi mentioned on the mailing list. Just remember if we process the queues faster, you have to fix the bugs faster ;)
[12:07] <mpt> spiv, or just help me get "sodium" working :-)
[12:07] <carlos> ;-)
[12:08] <spiv> mpt: "man ssh_config" ;)
[12:08] <carlos> stub: hmmm, that would be interesting, but I still think we would need some code changes
[12:08] <mpt> hmph :-P
[12:08] <carlos> stub: what happens if both threads take the same file ?
[12:08] <carlos> stub: one of them will trash its work when it tries to commit it
[12:08] <spiv> mpt: basically, if you have a "Host sodium" section, I think you need to duplicate your "Host *.ubuntu.com" section's contents in it, because "sodium" doesn't match "*.ubuntu.com".
[12:09] <carlos> stub: but I guess we could have one to do ubuntu imports and another one to do product imports
[12:09] <mpt> ok
[12:09] <stub> carlos: ok. I wouldn't turn it on unless it is needed anyway.
[12:09] <spiv> mpt: There may be a smarter way to write your .ssh/config, but I haven't discovered it yet...
[12:10] <jamesh> spiv: https://sodium.ubuntu.com/~jamesh/pending-reviews/ <- just done a test riun
[12:12] <spiv> jamesh: what makes some fail and some work?
[12:13] <jamesh> spiv: the branches not being present on sodium yet
[12:13] <spiv> jamesh: Oh?  The log file seems to say it's accessing "sftp://chinstrap/.."
[12:14] <jamesh> spiv: it doesn't access the branches via sftp
[12:14] <jamesh> spiv: it recognises the host prefix and trims it off
[12:14] <spiv> Oh, right, I see.
[12:15] <jamesh> to do otherwise I'd need to give the cron job access to an ssh key or similar
[12:15] <spiv> Right.
[12:15] <carlos> stub: I will take that into account when we 'fight' that queue. I will figure a way to do that faster based on the information you just gave me. Thank you
[12:17] <lifeless> spiv: how do you feel about you me and mpool getting together tomorrow for smart-server hacking ?
[12:17] <spiv> lifeless: sounds good to me.
[12:18] <lifeless> so, we can meet at your place, or mine, or mpools.
[12:18] <spiv> lifeless: I have yoga in North Sydney in the evening, so mpool's place is the most convenient for me.
[12:18] <lifeless> ok, meet @ 10 ?
[12:18] <spiv> Sounds good to me.
[12:18] <spiv> I hope it's ok with mpool ;)
[12:19] <lifeless> it is
[12:20] <spiv> Hmm, the lp-authed wikis are just hanging for me, rather than dropping into read-only mode.
[12:21] <spiv> I guess that means the authserver accepting XML-RPC requests and never answering them because it's waiting for the db that stub is updating.
[12:21] <spiv> Hmm, back now, with full access.
[12:21] <SteveA> spiv: need a so-timeout?
[12:21] <spiv> But it should have dealt with the db outage more gracefully.
[12:21] <stub> yup - just finished. probably was only like that for a few seconds this time.
[12:22] <stub> spiv: It might have been the way I was doing the update - I didn't actually take the db down, so the scripts would have locked various bits and pieces causing the authserver to appear hung.
[12:22] <spiv> SteveA: on the wiki end, as a last resort, yeah.
[12:22] <SteveA> spiv: file a bug :-)
[12:23] <stub> spiv: I'll remember that for next time
[12:23] <spiv> Hmm, thinking about it, the wikis cope well with the authserver being totally down.
[12:23] <spiv> But if it can accept requests, but then not answer them, life is bad.
[12:23] <spiv> SteveA: I'm about to :)
[12:23] <SteveA> awesome
[12:24] <spiv> stub: Yeah, if you think the authserver isn't going to be able to answer requests, then killing it is better than leaving it running.
[12:24] <carlos> Is there anyone using staging atm?
[12:24] <carlos> I'm going to turn it down for about 5 minutes to merge one branch I'm working on for testing purposes
[12:25] <stub> carlos: No problems from my pov
[12:26] <carlos> ok
[12:29] <stub> cprov, malcc: All the rollout is done except for drescher. Want me to push the production branch to codelines/current now?
[12:29] <cprov> stub: yes, please
[12:30] <cprov> stub: in fact, push to another dated directory in codelines, just in case
[12:30] <stub> cprov: too late...
[12:31] <stub> it will all be in bzr somewhere ;)
[12:31] <carlos> stub: hmmm I lost my access to asuka. Is it working for you?
[12:31] <cprov> stub: :(, sorry 
[12:31] <cprov> stub: indeed
[12:32] <stub> carlos: I cannot ssh to asuka. We need elmo or Znarl to have a poke and possibly reset the power if it doesn't respond in 10 mins or so.
[12:33] <stub> cprov: code updated. I'll let you sort out the rest and reenable the cron jobs.
[12:34] <cprov> stub: fine, thank you 
[12:34] <stub> ok. all built too ;)
[12:34] <carlos> stub: I hope my 'sudo -u launchpad -s' didn't broke it.... 
[12:34] <carlos> because that was the last command I typed before it stop respond me
[12:35] <carlos> interesting way to break a server...
[12:35] <carlos> it's back
[12:35] <carlos> stub: we don't need to request any reset
[12:35] <stub> k
[12:36] <cprov> stub: drescher is on 3820, you said 3819, is it ok ?
[12:36] <carlos> **** STAGING is going down for 5 minutes ****
[12:37] <cprov> stub: it's your OOPS to sodium, btw arch-commits didn't get any email
[12:40] <carlos> hmmm, something is wrong there...
[12:54] <carlos> stub: wow... seems like my language packs scripts needs a huge optimization process.... it's causing an overload in asuka... or at least is the only explanation I can find to the 100% usage of asuka cpu by postgres...
[12:54] <mpt__> grrrrr
[12:54] <SteveA> mpt__: irssi
[12:55] <mpt__> SteveA, no, .ssh/config
[12:56] <stub> cprov: 3819 was where it was branched from. Another commit was then made to the production branch, bringing it to 3820
[12:57] <cprov> stub: i saw it later ... tks
[01:10] <spiv> (back)
[01:11] <carlos> staging is back to live
[01:19] <jamesh> the pending-reviews script should be running every 2 hours again on sodium.ubuntu.com now
[01:20] <cprov> stub: ping, do you have access to jubanny logs ?
[01:22] <cprov> stub: of course you have ...  we need to know what query is issue by publisher in the BPP table, is it easy ?
[01:31] <lifeless> jamesh: given this is our box, how about hourly ?
[01:38] <jamesh> lifeless: fair enough
[01:52] <carlos> stub: hi, do you have some time to help me with a query ?
[02:07] <stub> cprov: I'm not logging all statements at the moment. I can switch it on easily enough for short periods of time.
[02:07] <malcc> stub: It's ok, we found another route to debug our problem
[02:07] <cprov> stub: it's ok, already fixed
[02:07] <cprov> stub: thanks
[02:07] <stub> carlos: sure
[02:09] <carlos> stub: I'm doing some debugging already with jamesh, but if you see something obvious...
[02:09] <carlos> stub: https://sodium.ubuntu.com/~andrew/paste/fileTUTin3.html
[02:10] <carlos> stub: I'm trying to copy POFiles from the distrorelease 5 to the distrorelease 6 if there isn't already such pofile in distrorelease 6
[02:10] <carlos> stub: but I'm getting a duplicate error 
[02:11] <carlos> psycopg.IntegrityError: ERROR:  duplicate key violates unique constraint "pofile_template_and_language_idx"
[02:11] <stub> carlos: You need a DISTINCT ?
[02:12] <carlos> stub: why?, if the original distrorelease cannot have duplicates... I should not get duplicates either, right?
[02:12] <carlos> If I get duplicates, the query is wrong
[02:13] <stub> carlos: Only if each of those tables you are joining with has a 1:1 relationship
[02:14] <carlos> stub: that's the case here
[02:14] <stub> You can confirm by doing COUNT(*) on the SELECT both with and without the DISTINCT
[02:14] <carlos> ok, let me try...
[02:19] <carlos> stub: confirmed that's not the problem
[02:19] <carlos> I get the same amount of rows
[02:20] <jamesh> Keybuk: got time for a question about Dyson?
[02:20] <Keybuk> jamesh: sure
[02:21] <jamesh> Keybuk: the bug in question is https://launchpad.net/products/launchpad/+bug/53698
[02:21] <Ubugtu> Malone bug 53698 in launchpad "Dyson dying with invalid version database exception" [Untriaged,Confirmed]  
[02:21] <jamesh> the pattern for grass matched two files: one in the directory given, and one in a subdirectory
[02:21] <Keybuk> what is your question?
[02:22] <jamesh> the file in the subdirectory was not actually a release, which brought up the question of whether we want dyson to be descending sub directories
[02:22] <jamesh> (or matching the patterns in sub directories
[02:24] <Keybuk> did you decide?
[02:24] <jamesh> was there a particular reason why you coded it to descend subdirectories?
[02:24] <Keybuk> nope
[02:24] <Keybuk> no particular reason
[02:24] <Keybuk> or if there was, I don't remember one
[02:25] <jamesh> okay.  We wanted to check if there was some particular use case you had in mind
[02:25] <Keybuk> I wrote it very quickly and haven't thought about it since
[02:26] <jamesh> lifeless also brought up the question of whether the "uscan" tool could have been used for this purpose
[02:38] <stub> carlos: The subquery is returning duplicate rows.
[02:39] <carlos> stub: hmm, the checks I did doesn't show duplicates... what am I missing?
[02:40] <carlos> I get 342 rows on staging
[02:40] <carlos> wither with and without DISTINCT
[02:40] <carlos> s/wither/either/
[02:42] <stub> carlos: https://sodium.ubuntu.com/~andrew/paste/fileuF7ixX.html
[02:44] <stub> carlos: and https://sodium.ubuntu.com/~andrew/paste/fileErZNBo.html
[02:45] <carlos> hmmm I did exactly that query!
[02:45] <carlos> well, obviously... I didn't do it or I would get the same output...
[02:46] <carlos> stub: thank you, I will investigate what's wrong there....
[02:46] <stub> carlos: SELECT DISTINCT ON (pt2.id, pf1.language,pf1.variant) [....]  should work, but I'm not sure if it is *correct*.
[02:47] <stub> carlos: That will only return the first row found with the given pt2.id, language and variant
[02:47] <carlos> well, that would be a workaround to the problem
[02:47] <carlos> I prefer to fix the query so we don't get duplicates...
[02:48] <carlos> but thanks for the suggestion
[02:51] <carlos> stub: we have broken data in our database, that's why we get duplicates...
[02:53] <carlos> hmm or not so broken data...
[02:53] <stub> ok. Does it look like it would be preventable with a database constraint? I suspect not as it would involve cross table constraints.
[02:54] <carlos> no, it implies more than one table
[02:55] <carlos> it's not broken data, it's something we are 'abusing' but I can fix the sql query really easy
[02:59] <carlos> stub: thanks for your help
[03:11] <spiv> salgado, matsubara: you've both put branches on sodium already, but you aren't using a shared repository.
[03:12] <spiv> salgado, matsubara: this may cause problems.
[03:12] <salgado> spiv, yes, I only moved the branches I'm using currently; I will upload my shared repo later today and remove these branches
[03:12] <spiv> salgado, matsubara: anyway, please see Steve's mail to list asking people not to use sodium yet.
[03:13] <salgado> I haven't done so yet because to upload 240MB over a 128K link will take the whole day, so I'll do it at night
[03:13] <spiv> salgado: uploading a shared repo would be the hard way to do it.  It would be better to wait for it to be set up properly.
[03:13] <spiv> Right, because you're being silly ;)
[03:14] <spiv> Please don't upload it, it's not necessary to do it that way.  As the mail to the list says, we're working on setting up a consistent system for everyone.
[03:14] <salgado> hmmm. I can't see that email
[03:15] <spiv> Part of that will involve creating a shared repo for everyone.
[03:15] <spiv> Subject: Important: Sodium Setup  [was: Moving from chinstrap to sodium] 
[03:15] <salgado> the "Moving from chinstrap to sodium" thread has only one email from Steve
[03:17] <salgado> well, this email has not reached my inbox yet, and lifeless proposed everyone copying their own branches
[03:17] <salgado> anyway, I'll remove them and wait
[03:19] <spiv> salgado: something is strange about your mail then; that message is over four hours old according to the headers I've got for it.
[03:19] <spiv> SteveA: do you know how long until the sodium setup is ready?
[03:21] <salgado> indeed. /me checks
[03:32] <SteveA> spiv: what do you mean?
[03:33] <sabdf1> hi folks are the lp-deps packages on chinstrap?
[03:33] <SteveA> spiv: I've just been interviewing, and I'm about to head for lunch
[03:33] <SteveA> sabdf1: they're in dapper universe.  they'll be elsewhere for edgy, in a ppa.  they're now maintained by etienne from canonical support.
[03:34] <sabdf1> i just upgraded to edgy and they're not there - i thought lifeless  volunteered to put them in a PPA?
[03:35] <SteveA> sabdf1: they're not available for edgy right now
[03:35] <SteveA> sabdf1: etienne goyer will be arranging a ppa for them
[03:35] <SteveA> lifeless is no longer maintaining them
[03:35] <sabdf1> ok, thanks
[03:36] <sabdf1> apparently, LP fires up perfectly happily on edgy
[03:37] <SteveA> spiv: the sodium stuff ready as soon as you've published the docs
[04:15] <SteveA> spiv: ping
[04:16] <mdz> cprov: I just got a crash from change-override.py
[04:49] <SteveA> jamesh: https://sodium.ubuntu.com/~andrew/paste/fileGtJim7.html
[04:49] <SteveA> stub: ping
[04:49] <SteveA> salgado: ping
[04:49] <SteveA> mpt: ping
[04:49] <SteveA> matsubara: ping
[04:50] <SteveA> cprov: ping
[04:50] <salgado> SteveA, pong
[04:50] <matsubara> SteveA: pong
[04:50] <SteveA> salgado: hi.  jamesh and I are sorting out the rest of the sodium setup
[04:50] <cprov> SteveA: pong
[04:50] <SteveA> I see you have stuff in /home/warthogs/archives there already
[04:51] <salgado> SteveA, I have only the directory structure. nothing inside them
[04:51] <SteveA> is this important stuff, or can we remove it in the course of setting things up optimally?
[04:51] <SteveA> thanks salgado.  we'll nuke it then.
[04:51] <SteveA> what about for cprov and matsubara ?
[04:51] <matsubara> SteveA: i'm ok with the nuking
[04:52] <SteveA> thanks matsubara 
[04:53] <jamesh> SteveA: cprov has his repo as cprov/repository/launchpad instead of cprov/launchpad.  matsubara and salgado have empty dirs, and the others look like the correct layout
[04:54] <cprov> jamesh: can I simply move directories around and fix my scripts to the correct path or extra actions are required ?
[04:56] <jamesh> cprov: if you move /home/warthogs/archives/cprov/repository/launchpad to /home/warthogs/archives/cprov/launchpad your dir looks fine
[04:59] <cprov> jamesh: okay, fixed then, thanks
[05:30] <stub> SteveA: pong
[05:33] <SteveA> hi stub 
[05:34] <SteveA> I was going to ask you about your code on sodium
[05:34] <SteveA> but, it's all sorted
[05:34] <stub> ok
[05:34] <stub> I think my existing repository matches the spec. It had already been pushed to do merges before you sent your email.
[05:34] <SteveA> yes, it matches
[05:34] <SteveA> it's all good
[05:47] <jamesh> SteveA: https://launchpad.canonical.com/SodiumSetup
[06:00] <jgi> hello everyone
[06:00] <LarstiQ> hello jgi 
[06:02] <jgi> I've uploaded hebrew translation for WengoPhone. The file is named qtwengophone_he.po, but I can't see it in the import queue.
[06:02] <jgi> Is there something wrong with the file?
[06:03] <malcc> I've given drescher a partial rollback, uncherrypicking r3817, due to it being buggered. I also uncherrypicked r3819 at cprov's request, which apparently broke something else. I've emailed the list but it seems to have gone astray.
[06:05] <carlos> jgi: hi, let me check....
[06:07] <carlos> jgi: it failed: https://launchpad.net/rosetta/imports/?target=products&status=FAILED&type=po
[06:08] <carlos> jgi: if you check that file with msgfmt, you can see that it's full of duplicates
[06:08] <carlos> jgi: msgfmt -c -v -o /dev/null yourfile.po
[06:08] <jgi> carlos: I don't see any qtwengophone_he file there
[06:09] <carlos> oh, sorry, I saw the french one and got that one as yours...
[06:09] <jgi> the he one must have duplicates too, I forgot to run it through msguniq
[06:10] <carlos> jgi: anyway, is not normal that we don't have it in our queue. Which URL did you use to do the upload?
[06:11] <jgi> carlos: https://launchpad.net/products/wengophone/trunk/+pots/qtwengophone/+upload
[06:12] <carlos> jgi: oh, that's the problem
[06:13] <jgi> carlos: which URL should I use?
[06:13] <carlos> sorry, it's not a problem, but an explanation why I don't see Hebrew in the list of languages for your application
[06:13] <carlos> ;-)
[06:13] <jgi> :-)
[06:14] <carlos> jgi: that one is fine, but as the filename is not just the language code, we need to approve it first
[06:14] <carlos> jgi: if you want it imported without any kind of approval you should use something like: https://launchpad.net/products/wengophone/trunk/+pots/qtwengophone/hr/+upload
[06:14] <carlos> so you directly specify the language code you are uploading
[06:14] <carlos> either that, or name the .po file as hr.po
[06:14] <jgi> ok
[06:14] <carlos> and use the URL you just gave me
[06:15] <carlos> let me look for the file
[06:15] <jgi> thank you very much, i'll do this
[06:17] <jgi> brb
[06:23] <jgi> ok, now it appears in the import queue \o/
[06:23] <jgi> :-)
[06:26] <Lord_Athur> hi all
[06:32] <carlos> jgi: hi I think the problem is that the previous one was imported as _en.po 
[06:32] <carlos> jgi: http://librarian.launchpad.net/3549123/qtwengophone_en.po
[06:32] <carlos> that's the only one I found
[06:33] <carlos> and the content is not English, it looks like Hebrew, but I don't speak or read Hebrew so I cannot tell you it for sure...
[06:40] <jgi> carlos, ok
[06:41] <jgi> carlos, has this import been canceled?
[06:41] <carlos> jgi: it's pending to be approved, should I remove it?
[06:42] <jgi> carlos, yes, the en one with hebrew inside
[06:42] <jgi> carlos, thank you very much
[06:42] <carlos> you are welcome
[06:42] <jgi> he.po should be fine
[06:42] <carlos> jgi: what about http://librarian.launchpad.net/3524638/qtwengophone_en.po ?
[06:42] <carlos> it looks like French
[06:43] <jgi> you can cancel it too IMHO
[06:46] <salgado> danilos, ping?
[06:48] <carlos> jgi: ok
[06:48] <danilos> salgado: pong
[06:48] <danilos> salgado: hi
[06:49] <salgado> hi danilos. I just wanted to check with you what's the status of your bug-1788 branch; is it ready to be merged?
[06:51] <sabdfl> hey lunchpadders
[06:51] <danilos> salgado: mostly, I'm on a sprint in london, and the last meeting prioritised 44860 over any other stuff I was on; I was planning on implementing your final suggestions (test changes) and going for a merge (didn't actually hurry up because chinstrap was down)
[06:51] <sabdfl> how's the novotel sprint goin?
[06:52] <danilos> sabdfl: it's going great, the food is really tasty :P
[06:52] <danilos> sabdfl: oh, you probably didn't wonder about that ;)
[06:53] <salgado> danilos, ah, okay. I didn't know you where at the sprint
[06:54] <danilos> salgado: no problem; do you want me to email you again when I'm finally done?
[06:54] <danilos> salgado: or should I go for the merge directly?
[06:55] <sabdfl> danilos: lunchpadders love lunch
[06:55] <carlos> sabdfl: would be possible to have the specs for 1.0 that are waiting for approval approved?
[06:55] <salgado> danilos, If it's just those test changes then it should be okay to merge
[06:55] <danilos> salgado: ok, great, I'll see what I'll do
[06:56] <sabdfl> carlos: for rosetta?
[06:56] <carlos> sabdfl: yes
[06:56] <carlos> sabdfl: the one about firefox and oo.org
[06:56] <sabdfl> carlos: none seem to be pending approval
[06:56] <sabdfl> oh, right
[06:56] <sabdfl> approval of the spec, not of the goal :-)
[06:57] <carlos> sabdfl: sorry, it needs to be reviewed by someone else before it can be approved ;-)
[06:57] <carlos> but I'm not sure who should do that 
[07:00] <jgi> carlos, it seems that the current hebrew translation for WengoPhone is indeed the english one
[07:00] <sabdfl> so, do you guys like the spec dependency display?
[07:00] <Lord_Athur> bye
[07:01] <jgi> carlos, that is, there is no text translated. Maybe this will be fix when someone approve the latest hebrew .po file I updated lately?
[07:01] <carlos> jgi: was it already imported?
[07:01] <sabdfl> carlos: does support for GSI interfere with the way we currently split the PO files into large-but-manageable pieces?
[07:01] <carlos> jgi: oh, that
[07:01] <carlos> jgi: it should automatically approved
[07:01] <carlos> jgi: just wait a bit and you should get a confirmation email
[07:01] <jgi> ok, cool
[07:02] <carlos> sabdfl: yes, but we could implement our GSI parser to split it into different potemplates and the export reconstruct the single GSI file from the set of potemplates we have
[07:03] <carlos> we have the path information there
[07:05] <jamesh> sabdfl: looks like we need to match the background colour of the dependency graph to the page background colour
[07:05] <carlos> sabdfl: yeah, the dependency thing looks good
[07:05] <carlos> jamesh: or just do it transparent
[07:05] <sabdfl> jamesh: it was supposed to be transparent
[07:05] <carlos> jamesh: explorer users would upgrade to a real browser ;-)
[07:06] <jamesh> looks very nice (although it does get a bit wide on some pages)
[07:06] <jamesh> carlos: a number of LP pages don't display particularly well on IE right now (I was looking at some at the airport)
[07:07] <jamesh> irrespective of alpha channel PNGs
[07:07] <SteveA> sabdfl: interesting... the code says "transparent".  I wonder if cairo doesn't handle transparency
[07:07] <sabdfl> jamesh: those are 1.0 bugs! could you file bugs on them please? subscribe me and assign to mpt
[07:08] <sabdfl> jamesh: they are also things we must take care of before the python competition hits
[07:09] <SteveA> definitely transparent in production.  it would be interesting to see if transparency returns if the cairo parts are turned off.
[07:10] <jamesh> sabdfl: it was some problems displaying portlets on bug pages (the margins were empty and the portlets displayed below the main content)
[07:11] <jamesh> I can't reproduce them on my laptop since I don't have Windows
[07:16] <jamesh> sabdfl: after a quick search, this sounds like exactly what I saw: https://launchpad.net/products/launchpad/+bug/49471
[07:16] <Ubugtu> Malone bug 49471 in launchpad "Sidebars sometimes go AWOL in Internet Explorer" [High,Confirmed]  
[07:16] <jamesh> and the guy has done a bit more investigation of what conditions trigger the problem
[07:17] <jamesh> oops.  accidentally subscribed you to 30342 :(
[07:19] <jamesh> which is not as big a deal since IE7 is in beta and the rendering bugs may get fixed or changed before final release
[07:36] <dous> when one views his CoC signatures, is it really supposed to look the way it is right now (not preformatted)? or is it a bug? thanks. :)
[07:43] <SteveA> sabdfl: it is cairo.
[07:43] <SteveA> when I remove the graphviz-cairo package, it goes transparent again... and chunky too
[07:43] <SteveA> no sign of an upstream bug on this, so we should get one filed and watched in launchpad
[07:45] <steveire> hey. Roughly how long does it take to ship cds to Germany?
[08:49] <kiko> GMV!
[08:49] <kiko> hello everybody
[08:49] <kiko> how's it going
[08:57] <flacoste> kiko: doing great! you're finally back home?
[08:57] <kiko> yes
[08:57] <kiko> I visited a total of 6 airports yesterday
[08:57] <kiko> in order:
[08:58] <flacoste> six airports: aargh!
[08:58] <kiko> actually, seven. 1. mallorca 2. sevilla 3. lisbon 4. natal 5. fortaleza 6. brasilia 7. campinas
[08:58] <flacoste> that will cost you a lot in greenhouse-reduction tax ;-)
[08:59] <kiko> I was thinking exactly about that
[09:00] <kiko> they need to put together intercontinental elevators
[09:00] <kiko> shoot up, shoot down
[09:00] <flacoste> teleportation is the way to go
[09:08] <flacoste> kiko: http://www.climatecare.org/, that's where you should pay your dues ;-)
[09:25] <Lord_Athur> hi all
[09:26] <Lord_Athur> the icons  of the gnome applications aren't in the list of the kde menu, I've the name of the programs only.
[09:26] <Lord_Athur> is that a bug? can it be reported?
[09:26] <Lord_Athur> what can i do?
[09:28] <Lord_Athur> itdoesn't seem to be important, but I'd like to know what to do :P
[09:32] <kiko> Lord_Athur, is that an #ubuntu issue?
[09:35] <Lord_Athur> no , I asked in launchpad about if it's sth which can be reported to launchpad as an error.
[09:36] <Lord_Athur> as a bug
[09:36] <Lord_Athur> is it kiko 
[09:36] <Lord_Athur> ?
[09:36] <kiko> oh.
[09:36] <kiko> well, if it's an ubuntu bug, then by all means, /distros/ubuntu/+filebug!
[09:37] <Lord_Athur> thanks your help, bye
[09:38] <kiko> SteveA, lifeless: when you have a moment, I'd like the ssh -A bit of SodiumSetup clarified.
[10:28] <kiko> bradb, did you see martin's latest posting to python-dev?
[10:28] <bradb> kiko: nope
[10:28] <kiko> You'll notice that it also lists Trac and Malone, however,
[10:28] <kiko> it seems that there is no progress on importing SF data
[10:28] <kiko> into these
[10:29] <kiko> bradb, might be an idea to reply to him. is SteveA the one coordinating this?
[10:31] <bradb> kiko: hm, who added malone?
[10:31] <kiko> pas moi
[10:32] <bradb> kiko: I emailed infrastructure@ several days ago telling him that we were working on our proposal, and confirming that things would be closed no sooner than Aug 7th. Brett replied that the date would hold.
[10:32] <bradb> i wonder if he added it
[10:33] <kiko> bradb, perhaps. are you subscribed to python-dev? would you like me to reply instead? is it time we disclosed demo.launchpad.net or not yet?
[10:33] <kiko> bradb, have you been able to follow SodiumSetup?
[10:33] <bradb> kiko: i'm not sub'd. i think we can disclose it, letting them know we're ironing out some kinks in the import.
[10:33] <bradb> kiko: i was going through that just now (had been verifying the import earlier)
[10:34] <bradb> so i'll let you know in a few mins :)
[10:34] <kiko> bradb, okay, I'll reply, then.
[10:34] <bradb> kiko: cool, thanks
[10:39] <kiko> bradb, done.
[10:39] <bradb> w00t
[10:39] <kiko> bbias, rebooting.
[10:40] <kiko> bradb, see if your ssh -A works as expected. 
[10:48] <kiko> matsubara, have OOPS reports been moved to sodium yet?
[10:48] <matsubara> kiko: not yet.
[10:48] <kiko> orright.
[10:50] <bradb> kiko: ssh -A seemed to work for me
[10:50] <kiko> hmmm.
[11:27] <cprov> kiko: hey, did you have time for my review ?
[11:32] <kiko> cprov, I'm going to look at it soon, just finishing fixing up my branches
[11:32] <cprov> kiko: good, thank you ;)
[12:00] <jamesh> kiko: nice LP branch names on sodium :)
[12:01] <kiko> you mean trivialities, trivialities-new and trivialities-xx? :)
[12:02] <jamesh> yeah
[12:02] <kiko> well.. it's really a set of random branches I just use to paralelize work.
[12:03] <jamesh> the /home/warthogs/archives directory on sodium is only 6.2GB
[12:03] <jamesh> a lot smaller than the chinstrap one